Summary
On the non-root Android build, AirPods Pro 3 press-and-hold can stop responding after the earbuds have been connected for a while and/or after a normal reconnect. The app can still change listening modes directly, and connecting the AirPods to a Mac restores physical stem control.
This is a focused follow-up to #571, where the maintainer noted that initialization packets may race the underlying AACP ACL connection and that force-stopping the app can restore operation.
Environment
- LibrePods
v0.2.9-play / Play Store non-root build
- Pixel 10 Pro
- Android 17 (
CP2A.260605.012)
- AirPods Pro 3, model
A3065
- Native/rootless L2CAP path; no Xposed or root
Reproduction
- Pair the AirPods and connect them to the phone.
- Verify that pressing and holding either stem cycles the configured listening modes.
- Keep the AirPods connected for an extended period and/or put them in the case and reconnect normally.
- Press and hold either stem again.
- Change the listening mode from the LibrePods UI as a control test.
Actual behavior
- The physical press-and-hold action eventually does nothing or no longer follows the configured mode cycle.
- Changing the listening mode from LibrePods still works.
- Force-stopping/restarting LibrePods, re-pairing, or connecting to a Mac can restore press-and-hold behavior.
Expected behavior
Press-and-hold should continue to use the configured listening-mode/stem-action mapping across long-lived connections and ordinary reconnects.
Source-level lead
The repository protocol notes state that the stem configuration is accessory state that must be stored and overwritten when AirPods connect to a new device: Configure Stem Long Press.
AirPodsService.connectToSocket() initializes the AACP session and sends STEM_CONFIG, but the reconnect path should be checked to ensure that the desired LISTENING_MODE_CONFIGS (0x1A) and ALLOW_OFF_OPTION (0x34) state are replayed only after the AACP control socket is actually ready. A stale reader, overlapping initialization job, or write to a replaced socket could leave telemetry working while the physical stem configuration is stale.
The behavior is consistent with the race condition described in #571 and does not look like the historical Android Bluetooth-stack blocker: direct listening-mode writes still work over the existing connection.
Related reports
A candidate implementation is being submitted separately for maintainer review; it is intended as a concrete reproduction-informed reference, not a claim that the Play Store build has already been fixed.
Summary
On the non-root Android build, AirPods Pro 3 press-and-hold can stop responding after the earbuds have been connected for a while and/or after a normal reconnect. The app can still change listening modes directly, and connecting the AirPods to a Mac restores physical stem control.
This is a focused follow-up to #571, where the maintainer noted that initialization packets may race the underlying AACP ACL connection and that force-stopping the app can restore operation.
Environment
v0.2.9-play/ Play Store non-root buildCP2A.260605.012)A3065Reproduction
Actual behavior
Expected behavior
Press-and-hold should continue to use the configured listening-mode/stem-action mapping across long-lived connections and ordinary reconnects.
Source-level lead
The repository protocol notes state that the stem configuration is accessory state that must be stored and overwritten when AirPods connect to a new device: Configure Stem Long Press.
AirPodsService.connectToSocket()initializes the AACP session and sendsSTEM_CONFIG, but the reconnect path should be checked to ensure that the desiredLISTENING_MODE_CONFIGS(0x1A) andALLOW_OFF_OPTION(0x34) state are replayed only after the AACP control socket is actually ready. A stale reader, overlapping initialization job, or write to a replaced socket could leave telemetry working while the physical stem configuration is stale.The behavior is consistent with the race condition described in #571 and does not look like the historical Android Bluetooth-stack blocker: direct listening-mode writes still work over the existing connection.
Related reports
A candidate implementation is being submitted separately for maintainer review; it is intended as a concrete reproduction-informed reference, not a claim that the Play Store build has already been fixed.