IssueTracker

The Bluetooth stack hangs and is not be able to resume background connections for Bluetooth low energy devices when an advertisement packet comes in from a device that is already in the connected state. While this may seem unlikely to happen, it can happen quite often when supervision timeout occurs, as we have noticed ourselves as well as have had customers reporting this issue (which we've verified by looking at their HCI snoop logs). It may also happen with peripherals that support multiple slave connections.

The bug occurs under the following conditions:
- The app has the autoConnect parameter in connectGatt set to true for all BLE connections.
- The BLE connection must be unstable enough to trigger supervision timeout. For example if the device is on the edge of being out of range.
- The Android device's supervision timeout timer times out slightly after the peripheral's times out (which is not strange because they restart their timeout timers when they successfully receive a packet from the other peer). After the peripheral times out, it is configured to immediately restart advertising. The Android device has not yet timed out (it will time out very soon).
- There is also a pending background connection to at least one other BLE device.

In this case, when the peripheral starts advertising, the Android device is still in the connected state to that device, since the supervision timeout has not played out yet. Since that device is currently in the Bluetooth controller's white list and there is a pending connection, the advertising event will be handled and the controller will connect and send a LE Connection Complete HCI event. At this point, Android's Bluetooth stack gets confused since this device is already connected, prints the error "L2CAP got BLE scanner conn_comp in bad state: 4" and then does NOT restart pending connections until Bluetooth is restarted (which leads to angry customers...).

This basically means no BLE connections will work until Bluetooth is restarted (however currently connected devices will work until their connection is lost, but not after that).

Note that disconnecting and then connecting again through the APIs also don't work (it will still never reconnect until you restart Bluetooth). Logcat prints "No such connection need to be cancelled" here.

The same bug will also be triggered if there is a "hacker" setting up a BLE advertiser with the same Bluetooth device address and starts advertising at the same time the device with that BD address is connected, and there is at least one pending connection to another BLE device. Another easy way to trigger the bug is to, when the peripheral is connected, remove the battery of the peripheral, immediately after reinsert it and start advertising (this must happen within the supervision timeout).

Note that this bug will not occur on Android devices with a Broadcom Bluetooth chip, since their firmware behaves in a non-conformant way. What happens there is that if it detects an incoming ADV_IND when a device with that BD address is already connected (if another connection is pending and this device is in the white list), it will immediately tear down the current connection and send a Disconnect event to the host indicating Connection Timeout (0x08), and thereafter send the LE Connection Complete event (for the new connection). Android devices with Qualcomm Bluetooth chips for example are however affected. I've tested and verified the bug both on a Oneplus One device with Marshmallow 6.0.1 (build MHC19Q) as well as an LG G3 with 6.0.1 (build MRA58K). Since Nexus and Samsung phones have Broadcom bluetooth chips, they are not affected.

I've included a hci snoop log. At packet 190, the timeout has occurred for the peripheral and it here restarts advertising and therefore the Android device connects. 10 ms later the Android device gets a "Disconnect complete" event from the controller. From now on nothing works anymore. At packet 297 the Android bluetooth stack by the way tries to cancel the pending connection but it fails with "Command Disallowed (0x0c)" because there is no pending connection to cancel. From that on it never sends any start/stop connection commands until you restart Bluetooth.

A suggested fix is to, when a connection has completed and it should continue searching for other background devices, don't start a pending connection immediately but first remove the just connected device from the white list. When a device has disconnected, stop the pending connection, add it back to the white list and restart the pending connection. Note that there are also upcoming new smarter BLE peripheral devices which can have multiple slave connections, meaning it will continue to advertise even though it is already connected to a master. To not fail with these devices this fix has to be done. Otherwise Android devices with Broadcom chips will just disconnect all the time and for other chips, all available connections will quickly be eaten up.

The bug seems to have been introduced in this commit: https://android.googlesource.com/platform/system/bt/+/444a8da807abaf5f9e813ce70c56a79160495fb3%5E%21/#F20 in function btm_ble_conn_complete where the line "btm_ble_set_conn_st(BLE_CONN_IDLE);" has been removed. As you can see, when btm_ble_update_mode_operation is called right after, in that function it checks the state "if (btm_ble_get_conn_st() == BLE_CONN_IDLE && status != HCI_ERR_HOST_REJECT_RESOURCES && !btm_send_pending_direct_conn()) { btm_ble_resume_bg_conn(); }". Since it's not in BLE_CONN_IDLE state since this commit but still in BLE_BG_CONN state, it never resumes the background connection. Since that commit, the btm state is instead set to BLE_CONN_IDLE in the function l2cble_scanner_conn_comp but ONLY if the current state of the link was LST_CONNECTING. Since it is LST_CONNECTED (when the bug conditions hold), it now fails.

Previously (on Lollipop and below), if it happened that the peripheral started to advertise during it was connected, i.e. usually right before the link was determined lost, no packages will be exchanged during that connection and an App will think the device is disconnected but once it disconnects and reconnects again which will usually happen eventually, it will work as normal again.

I've also included a logcat log where the bug triggers even though I don't think it adds anything important.