When I try to connect and disconnect from a BLE peripheral multiple times one after the other (with a few seconds delay inbetween), my app crashes. On closer inspection it is because the bluetooth service of the device has crashed. Here is the relevant log lines from logcat:
2022-03-21 12:54:08.591 2161-2210/? E/bt_hci: Ctlr H/w error event - code:0x21
2022-03-21 12:54:08.591 2161-2210/? I/bt_stack: [INFO: .cc(323)] clear_l2cap_whitelist: Clearing whitelist from l2cap channel. conn_handle=512 cid=4:4
2022-03-21 12:54:08.591 2161-2210/? W/bt_stack: [WARNING:bta_gattc_act.cc(1043)] bta_gattc_conn_cback: cif=3 connected=0 conn_id=0x0003 reason=0x0003
2022-03-21 12:54:08.591 2161-2210/? W/bt_stack: [WARNING:bta_gattc_act.cc(1043)] bta_gattc_conn_cback: cif=4 connected=0 conn_id=0x0004 reason=0x0003
2022-03-21 12:54:08.591 2161-2210/? W/bt_stack: [WARNING:bta_gattc_act.cc(1043)] bta_gattc_conn_cback: cif=5 connected=0 conn_id=0x0005 reason=0x0003
2022-03-21 12:54:08.591 2161-2210/? W/bt_stack: [WARNING:bta_gattc_act.cc(1043)] bta_gattc_conn_cback: cif=6 connected=0 conn_id=0x0006 reason=0x0003
2022-03-21 12:54:08.592 2161-2210/? W/bt_stack: [WARNING:bta_gattc_act.cc(1043)] bta_gattc_conn_cback: cif=7 connected=0 conn_id=0x0007 reason=0x0003
2022-03-21 12:54:08.592 2161-2210/? W/bt_stack: [WARNING:bta_gattc_act.cc(1043)] bta_gattc_conn_cback: cif=8 connected=0 conn_id=0x0008 reason=0x0003
2022-03-21 12:54:08.593 2161-2743/? I/bt_stack: [INFO:message_loop_thread.cc(175)] Run: message loop starting for thread bt_module_lifecycle_thread
2022-03-21 12:54:08.593 2161-2743/? I/bt_core_module: module_start_up Starting module "controller_module"
2022-03-21 12:54:08.593 2161-2190/? E/bt_btif: Received H/W Error.
2022-03-21 12:54:08.596 2161-2190/? I/bt_stack: [INFO:btif_config.cc(647)] hash_file: Disabled for multi-user
2022-03-21 12:54:08.597 2161-2190/? I/bt_stack: [INFO:btif_config.cc(689)] write_checksum_file: Disabled for multi-user, since config changed removing checksums.
2022-03-21 12:54:08.598 2161-2743/? I/bt_log_fw_log_switch: Start: skip to enable legacy FW log feature
2022-03-21 12:54:08.599 2161-2210/? I/bt_stack: [INFO:btu_hcif.cc(1160)] read_encryption_key_size_complete_after_encryption_change: disconnecting, status: 0x02
2022-03-21 12:54:08.615 2161-2743/? I/bt_core_module: module_start_up Started module "controller_module"
2022-03-21 12:54:08.615 2161-2743/? I/bt_stack: [INFO:message_loop_thread.cc(196)] Run: message loop finished for thread bt_module_lifecycle_thread
2022-03-21 12:54:08.615 2161-2209/? W/bt_btm: btm_decode_ext_features_page: feature page 1 ignored
2022-03-21 12:54:08.616 2161-2209/? W/bt_btm: btm_decode_ext_features_page: feature page 2 ignored
2022-03-21 12:54:08.616 2161-2209/? I/bt_stack: [INFO:message_loop_thread.cc(87)] ShutDown: thread bt_module_lifecycle_thread(-1) is already stopped
2022-03-21 12:54:08.730 395-6284/? E/[email protected]: BluetoothDeathRecipient::serviceDied - Bluetooth service died
This happens on only two devices I have tested (both of them Android 10). It does not occur on a Samsung Android 11 device for example.
By restarting the bluetooth service after a few connection/disconnection cycles, I was not able to get this issue again. However, this workaround is not good for a customer's use as they would lose connection to other BT devices they are currently using.
My question is how to proceed with understanding the root cause for this issue? Is it completely a device hardware issue that I can not do anything about? Or is there something which can be changed in my approach?
If the Bluetooth stack crashes in the phone, then it's most likely a bug in the Bluetooth stack which you can not do anything about, except sending in a bug report to the phone manufacturer.
You could however try to see if you can find out under which circumstances this happens and perform some workaround to avoid this. The hci snoop log in combination with logcat could maybe be a help.
In any case, if you program your app correctly, it should not crash itself just because the Bluetooth stack crashes. You should be able to recover when the Bluetooth stack later restarts. See How to detect Bluetooth state change using a broadcast receiver? how you can get notified of Bluetooth state changes.