Fix bug where a bonded device could enter BONDING and BONDED states again.

The following sequence of events was observed:
- start bonding with device A
- bond state for A goes from 10 -> 11 -> 12
- everyone's happy
- start bonding with device B
- bond state for B goes from 10 -> 11
- bond state for A goes from 12 -> 11 -> 12

The bond state for A should not have been changed in the last step
since it was not participating in any bonding procedure at the time.

The above sequence can be reproduced if a device D bonds with
A and takes on the slave role and then D bonds with B and switches
to a master role. When D performs the role switch, it receives an
updated link key from A.

Since the link key update procedure is tied in with the pairing flow,
we see spurious bond state changes. This CL checks the pairing control
block to see if D is, in fact, pairing with A and if not, it skips the
bond state updates.

Bug: 25870383
Change-Id: Ic6ff548dbe4e960c965bdc9ef5c50a263b9b3b22

diff --git a/btif/src/btif_dm.c b/btif/src/btif_dm.c
index e6ff7f3..eb5992b 100644 (file)
--- a/btif/src/btif_dm.c
+++ b/btif/src/btif_dm.c
@@ -1090,6 +1090,16 @@ static void btif_dm_auth_cmpl_evt (tBTA_DM_AUTH_CMPL *p_auth_cmpl)
         }
     }
 
+    // We could have received a new link key without going through the pairing flow.
+    // If so, we don't want to perform SDP or any other operations on the authenticated
+    // device.
+    if (!bdaddr_equals(p_auth_cmpl->bd_addr, pairing_cb.bd_addr)) {
+      char address[32];
+      bdaddr_to_string(&p_auth_cmpl->bd_addr, address, sizeof(address));
+      LOG_INFO("%s skipping SDP since we did not initiate pairing to %s.", __func__, address);
+      return;
+    }
+
     // Skip SDP for certain  HID Devices
     if (p_auth_cmpl->success)
     {