diff options
| author | Sharvil Nanavati <sharvil@google.com> | 2016-01-05 16:23:02 -0800 |
|---|---|---|
| committer | Sharvil Nanavati <sharvil@google.com> | 2016-01-06 09:24:32 -0800 |
| commit | b32b3d7c1b99adb760cc7013a545af2140e34dcc (patch) | |
| tree | 5e840599d7f7c4a787a1219c2b17f6afc0ecb056 /utils | |
| parent | bf8d17ddbb64fdc6c252c63f6b9078987f871ba6 (diff) | |
| download | android_system_bt-b32b3d7c1b99adb760cc7013a545af2140e34dcc.tar.gz android_system_bt-b32b3d7c1b99adb760cc7013a545af2140e34dcc.tar.bz2 android_system_bt-b32b3d7c1b99adb760cc7013a545af2140e34dcc.zip | |
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
Diffstat (limited to 'utils')
0 files changed, 0 insertions, 0 deletions