android(fix): connection lifecycle — ordering, re-wear audio/calls, read loop spin, heart rate start

[QuerTeal]

Depends on #806. This branch is built on top of it, so until #806 is merged the diff also shows its 6 commits. The 5 commits specific to this PR are the last 5.

Summary

1. Connect after loading cached state, off the main thread

onDeviceConnected() called device.connect() from the Bluetooth broadcast receiver. That is a blocking L2CAP connect on the main thread. Meanwhile, the DB load and observer registration ran concurrently on IO, which caused three problems:

• loadInitialState() could replace state that the first packets had already set.
• The observers could miss those first changes.
• startHr() could run before the socket existed.

The steps now run in order in the IO coroutine:

1. Load the cache.
2. Register the observers.
3. Connect.
4. Start heart rate.

A devicesBeingConnected guard keeps ACL_CONNECTED and ACTION_UUID from setting up the same device twice.

2. Re-wear: reconnect the call profile too, and resume only once A2DP is up

With "Disconnect AirPods when not wearing" enabled, taking both buds out disconnects A2DP and the headset profile. Putting one back in only reconnected A2DP, so calls and the mic stayed on the phone.

Resuming playback was also racy:

• With one bud in, sendPlay() fired before A2DP was back, so the paused media resumed on the phone speaker.
• With both buds in at once, playback only resumed on an A2DP "connected" transition. It therefore never resumed if A2DP was already connected.
• The A2DP receiver was never unregistered if that transition didn't come.

Fix:

• Call connectAudio() (A2DP + headset).
• Resume right away if the AirPods are already an A2DP output (AudioManager.getDevices); otherwise wait for A2DP.
• Drop the waiting receiver after 15 s.

3. Stop the AACP read loop when the socket closes

On EOF, the loop only logged and continued. On a read exception it also continued. Because BluetoothSocket.isConnected can stay true after the remote end closes the channel, the loop busy-spun: I saw about 4,200 identical log lines within milliseconds of a disconnect. It now breaks on EOF and on read errors.

4. Wait for an in-flight connect before starting heart rate

If a connect was already in progress (e.g. started from the device list), the service's connect() returned immediately. It then logged "Device connected" and sent the heart rate request while the socket was still connecting, so the request was lost. The service now waits for the connection state to leave CONNECTING first.

5. Request heart rate again when the AirPods are put in

The sensor only streams while the AirPods are worn. With the heart rate alert enabled, a request sent on connect (buds still in the case) never delivered samples after the buds were put in: 58 s without data. After re-sending the request, samples arrived within 2 s. The request is now re-sent on ear-in when the alert is enabled.

Testing

Galaxy S26 Ultra (One UI 9.0), AirPods Pro 3 (fw 9442752), about 50 minutes of connect, wear, remove, and re-wear cycles.

Verified on device:

• Connection order (1): "Loading device" → "connecting..." → "connected!" happens in that order on every connection.
• Connect guard: when the device list had already started a connect, the service logged connect() ignored, already CONNECTING.
• Re-wear audio (2): the headset connect() is issued on ear-in.
• Resume timing (2): sendPlay() is issued only after A2dpStateMachine enters Connected (6–9 ms later), both when A2DP had to reconnect and when it was already connected.

Built but not yet re-verified on device: 3, 4 and 5 were written from the logs of that test session. I'll update this PR after the next test run.

🤖 Generated with Claude Code