Repository navigation
Play Sound on a tag that is near its owner (owner-connected mode) #201
Description
Tracking issue for playing a sound on a tag that is near its owner. Ringing a tag that is separated from its owner is #139's job; this issue covers the case that path doesn't reach.
The reading list and what has been tried so far are collected in docs/owner-connected-tags.md.
Two control points
| Characteristic | Used by | Plays sound when |
|---|---|---|
4F860003, non-owner control point |
anyone | the link is unencrypted, and (per the DULT draft) only while the accessory is separated from its owner. Otherwise it answers Invalid_command. |
4F860002, configuration control point |
the owner | the link is encrypted with the bond key the owner's Apple ID holds |
What is known
- Play Sound silently no-ops on a real third-party accessory (RAVEMEN ABF01) - likely needs BLE encryption Android can't provide #193 (@LiamJ74): an iPhone ringing a RAVEMEN ABF01 writes to
4F860002over a link encrypted with a stable LTK. Byte-identical writes from Android, unencrypted, are acknowledged and play nothing. Android's public API cannot encrypt a link with a supplied LTK, and the rooted BlueZ route failed because the kernel lacksN_HCI. - A vendor Find My SDK (
ble_fmy.c) treats an unencrypted connection as a non-owner and disables4F860002for it. Encryption succeeding switches it to owner mode, and a comment there says any phone on the paired Apple ID can encrypt. - stek29 on FindMy.py#88: an AirTag with its owner nearby did not expose
4F860003at all.
Open questions
- Is the non-owner path enough for most users of this app? They usually have no Apple device near the tag, so it should be in separated state. Test: take every device on the Apple ID out of range, then run Find, ring and watch an accessory over direct BLE #139's
4F860003write while subscribed to indications on it, and read the Command_Response. - Where does the owner bond key live, and does anything this app exports contain it? Unknown. Even if it does, stock Android offers no way to use it.
Related: #17, #48, #139, #193.
Interactively co-authored by Claude Code and @parawanderer
Activity
parawanderer commentedon Sep 13, 2026
An untested route for a rooted proof of concept
#193's rooted attempt tried to replace Android's Bluetooth stack with BlueZ, and stopped at the kernel (
N_HCInot built in). Hooking into the running stack avoids that. The stack keeps the radio, and nothing is needed from the kernel.Android's stack already sends
HCI_LE_Start_Encryptionitself when it reconnects to a bonded device. It just only uses keys from its own bond store. So with root:com.android.bluetoothprocess.btsnd_hcic_ble_start_enc(handle, rand, ediv, ltk)instack/hcic/hciblecmds.ccsends the command directly. Check that it still exists, and is callable, on the Android version at hand, since builds are often stripped. The handle is in an HCI snoop log.01 00 02to4F860002and see whether the accessory sounds.Things that may go wrong:
It would settle the #193 question on real hardware with the key @LiamJ74 already has. That tests the mechanism, not a shippable feature: nothing here works on a phone without root.
Longer term, the clean version is a small platform API: encrypt this app's own connection with a supplied key, without bonding or persisting the key, and refuse if another app shares the link. Stock Android has no such API. Its Bluetooth stack ships as a Google-signed Mainline module, so it could only reach phones through AOSP, or a custom ROM carrying the patch.
Record the two Find My control points, from @LiamJ74's parawanderer#193…