Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 0e582522 authored by Archie Pusaka's avatar Archie Pusaka Committed by Archie Pusaka
Browse files

Floss: handle unbonding device doesn't report disconnection to CRAS

In aosp/2685489 we tried to be aggressive to disconnect audio profile
connection attempt from an unbonded device. However, the function
confuses this state with user forgetting the device via BT menu, since
both involves unbonded device and empty task queue. In case of the
latter, we would still try to invoke DisconnectDevice, but at the risk
of not informing CRAS, depending on the order of profile disconnection.

This CL also checks for the media state when determining the two cases
above. To be precise, when the state is FullyConnected, it could only
mean the latter case. On the other hand, if the state is Disconnecting,
it could mean both cases, but when it's the latter case, we can be sure
that CRAS has been informed of the disconnection.

Bug: 358525472
Test: m -j
Test: Using the latest pixel buds, do this multiple times.
      (1) Pair using fast pair
      (2) Verify the device doesn't immediately disconnect
      (3) Forget the device (skipping decive disconnection)
      (4) Sign out and sign in again
Flag: EXEMPT, floss only changes

Change-Id: I80ebb475743e9f902b5a8ecd2bd8021d7793584d
parent 0ed8ea93
Loading
Loading
Loading
Loading
+10 −1
Original line number Diff line number Diff line
@@ -2317,7 +2317,16 @@ impl BluetoothMedia {
                // Ignore unless all profiles are cleared, where we need to do some clean up.
                if !is_profile_cleared {
                    // Unbonded device is special, we need to reject the connection from them.
                    if !self.is_bonded(&addr) {
                    // However, it's rather tricky to distinguish between these two cases:
                    // (1) the unbonded device tries to reconnect some of the profiles.
                    // (2) we just unbond a device, so now the profiles are disconnected one-by-one.
                    // In case of (2), we should not send async_disconnect too soon because doing so
                    // might prevent on_bluetooth_audio_device_removed() from firing, since the conn
                    // state is already "Disconnecting" in notify_critical_profile_disconnected.
                    // Therefore to prevent it, we also check the state is still FullyConnected.
                    if !self.is_bonded(&addr)
                        && states.get(&addr).unwrap() != &DeviceConnectionStates::FullyConnected
                    {
                        let tasks = self.fallback_tasks.clone();
                        let states = self.device_states.clone();
                        let txl = self.tx.clone();