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:18:36 +0000 (16:18 -0700)
commitb82a27ed327739ca5de7924cc577f5bfb8b8060b
tree8a693bf280381b4d2c02d0cf0baec9cc1ea020bb
parent292051c271cd1b2584ffdacd1913c6de13a0f6b6
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