android: detect auto-reconnected AirPods without waiting for SDP UUID lookup#570
Draft
thisisAcidic wants to merge 1 commit intokavishdevar:mainfrom
Draft
android: detect auto-reconnected AirPods without waiting for SDP UUID lookup#570thisisAcidic wants to merge 1 commit intokavishdevar:mainfrom
thisisAcidic wants to merge 1 commit intokavishdevar:mainfrom
Conversation
thisisAcidic
force-pushed
the
fix-airpods-autoconnect-detection
branch
from
99c1af3 to
5bf4e00
Compare
…CAP socket connect ACL_CONNECTED only kicks off SDP via fetchUuidsWithSdp; the actual detection broadcast fires from the ACTION_UUID handler, which the system delivers once SDP completes. That is the correct ready-signal instead of polling the cached UUIDs immediately. connectToSocket now retries up to three times with 500 ms backoff when called from the auto-detect path. The L2CAP server on the AirPods sometimes is not ready the first instant the ACL link comes up (also seen when force-connecting from Bluetooth settings while the AirPods were owned by another device). Manual reconnects keep the original behaviour and show the error toast on first failure. Closes kavishdevar#569
thisisAcidic
force-pushed
the
fix-airpods-autoconnect-detection
branch
from
5bf4e00 to
7ec7741
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The ACL_CONNECTED handler in `bluetoothReceiver` was checking `bluetoothDevice.uuids` immediately after calling `fetchUuidsWithSdp()`, but that call is asynchronous (the result arrives later via `ACTION_UUID`), so the immediate check only succeeded if the UUIDs happened to be cached. When the cache was cold the AirPods reconnected silently and the app stayed in the "AirPods not connected" state until the user manually tapped "Reconnect to last connected device".
This PR changes two things:
The actual detection broadcast now fires from a new `ACTION_UUID` handler. `ACL_CONNECTED` either fires detection immediately if UUIDs are already cached, or kicks off `fetchUuidsWithSdp()` and waits. When the system delivers the resulting `ACTION_UUID`, we either match the discovered UUIDs against the Apple AAP UUID, or fall back to matching the saved `mac_address` for known devices. That removes the race against SDP completion without resorting to a hard-coded delay.
`connectToSocket` now retries up to three times with 500 ms backoff when called from the auto-detect path. The L2CAP server on the AirPods sometimes is not yet ready the very instant the ACL link comes up. The same is true when force-connecting from Bluetooth settings while the AirPods were owned by another device. Manual reconnects keep the original behaviour and show the error toast on first failure.
Closes #569