OSDN Git Service

Proper handling of AV connection collision
authorAyan Ghosh <abghosh@codeaurora.org>
Fri, 22 Jul 2016 09:41:11 +0000 (15:11 +0530)
committerPavlin Radoslavov <pavlin@google.com>
Wed, 27 Jul 2016 23:16:01 +0000 (16:16 -0700)
commit09d91c0ceb9604c28ff98f524fa775c9a363d59a
tree6b0096476fc47da333a0a4af39f5fbd28181113b
parent6bfe283db7287624b3333fde2a9b48f5bdb913d1
Proper handling of AV connection collision

Use case:
1. Pair to Remote
2. Turn OFF/ON BT on DUT
3. After DUT's BT is turned ON, Remote would reconnect to DUT

Failure:
  Bluetooth settings UI continues to display Connecting when
  BT was Turned OFF and ON.

Root cause:
- This is a connection collision case where remote is not responding
  to DUT initiated SDP attribute fetch request for AV. AV holds outgoing
  connection for sometime and meanwhile remote starts AV connection
  from its end. Then DUT disconnects the SDP channel after a second
  without waiting to fetch requested info, and this confuses DUT's AV
  state machine. The outgoing connection could not proceed as incoming
  AV L2CAP connects, because DUT's AV state machine is not equipped
  with handling this scenario. On incoming connection timer expiry, it
  does not start AV media channel as it finds AV Open has not been done
  from upper layer after incoming L2CAP got connected.

- When the incoming path 2s timer expires, the DUT checks whether Open
  has been called after incoming state is set. This is not the case here,
  because Open was triggered earlier as as part of the outgoing
  connection. As a result, A2DP cannot connect at all.

Fix:
- Properly set collision flags for handling AV connection collision.
- Update BTA AV handle even when BTIF AV state machine is yet to be built.

Bug: 30362987
Change-Id: I02a3adb62479b0f762bc792a5727d06e11eaaa52
bta/av/bta_av_aact.c
bta/av/bta_av_act.c
btif/src/btif_av.cc