Play Sound on a tag that is near its owner (owner-connected mode)

[parawanderer]

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 4F860002 over 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 lacks N_HCI.
• A vendor Find My SDK (ble_fmy.c) treats an unencrypted connection as a non-owner and disables 4F860002 for 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 4F860003 at all.

Open questions

1. 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 4F860003 write while subscribed to indications on it, and read the Command_Response.
2. 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

[parawanderer]

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_HCI not 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_Encryption itself when it reconnects to a bonded device. It just only uses keys from its own bond store. So with root:

1. Attach Frida (or similar) to the com.android.bluetooth process.
2. Connect to the accessory normally from an app, so the link exists.
3. Call the stack's own start-encryption path with the captured LTK, zero EDIV and zero Rand, on that connection's handle. In the Fluoride code I know of, btsnd_hcic_ble_start_enc(handle, rand, ediv, ltk) in stack/hcic/hciblecmds.cc sends 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.
4. If the HCI Encryption Change event reports success, write 01 00 02 to 4F860002 and see whether the accessory sounds.

Things that may go wrong:

• The stack sees encryption start on a link it didn't encrypt, and may treat it as a security failure and drop the connection.
• Internal function names and signatures change between Android versions.

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.

Interactively co-authored by Claude Code and @parawanderer