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)
committergitbuildkicker <android-build@google.com>
Thu, 28 Jul 2016 02:23:17 +0000 (19:23 -0700)
commit939fd540855c48a930b20cd99642715d15376a9c
tree8a693bf280381b4d2c02d0cf0baec9cc1ea020bb
parent5ceebeb17b72751fce3e69df50e45e57b5501edd
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
(cherry picked from commit db1e3a5fbb41cd1faf572c5f89ec9212c5ff2986)
bta/av/bta_av_aact.c
bta/av/bta_av_act.c
btif/src/btif_av.c