Стек BLE повторно подключается к периферийному устройству после того, как соединение закрыто и приложение завершено - PullRequest
0 голосов
/ 15 мая 2018

У меня есть приложение, которое открывает недолгое соединение с устройством BLE, выполняет некоторые характерные операции чтения и записи, а затем отключает и закрывает соединение. Приложение использует autoReconnect = false, а устройство не сопряжено и не связано.

Я вижу очень странное поведение Android, которое, кажется, неоднократно и неожиданно переподключается к периферийному устройству, даже после того, как соединение закрыто () d, приложение убито или даже удалено.

Эта проблема ранее была связана с Spotify, вызывающим переподключения (см .: Android BLE неожиданно и неоднократно переподключается к периферийному устройству ), но в моем случае это происходит даже без установки Spotify .

Устройства, на которых это можно надежно воспроизвести:

  • Google Pixel, Android 8.1
  • LG Nexus 5X, Android 7.1.2
  • Samsung Galaxy S7, Android 7.0
  • Samsung Galaxy S6, Андорид 6.0

Соединения кратковременны и длятся около 3 секунд. Я могу убедиться, что соединения установлены, потому что периферийное устройство обеспечивает визуальную индикацию и регистрирует выходы своих соединений.

Я довольно озадачен тем, что может вызвать повторные переподключения, поскольку logcat стека BLE не дает подсказки о том, кто или что вызвало соединение. Выход LogCat службы Bluetooth (com.android.bluetooth) для одного цикла подключения / отключения на Nexus 5X с 7.1.2 выглядит следующим образом:

05-15 10:36:55.428  6397  7029 W bt_smp  : smp_br_connect_callback is called on unexpected transport 2
05-15 10:36:55.428  6397  7029 W bt_btif : bta_dm_acl_change info: 0x0
05-15 10:36:55.428  6397  7029 E bt_btif : bta_gattc_cache_load: can't open GATT cache file /data/misc/bluetooth/gatt_cache_c4be844851e9 for reading, error: No such file or directory
05-15 10:36:55.428  6397  6526 D bt_btif_dm: remote version info [c4:be:84:48:51:e9]: 0, 0, 0
05-15 10:36:55.432  6397  6526 E BluetoothRemoteDevices: state12newState0
05-15 10:36:56.141  6397  7029 W bt_bta_gattc: bta_gattc_explore_srvc no more services found
05-15 10:36:56.141  6397  7029 I bt_bta_dm: bta_dm_gatt_disc_result service_id_uuid_len=2 
05-15 10:36:56.141  6397  7029 I bt_bta_dm: bta_dm_gatt_disc_result service_id_uuid_len=2 
05-15 10:36:56.142  6397  7029 I bt_bta_dm: bta_dm_gatt_disc_result service_id_uuid_len=2 
05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016
05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016
05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=5 connected=0 conn_id=5 reason=0x0016
05-15 10:36:58.185  6397  7029 W bt_btif : bta_gattc_conn_cback() - cif=6 connected=0 conn_id=6 reason=0x0016
05-15 10:36:58.185  6397  7029 I bt_btm_sec: btm_sec_disconnected clearing pending flag handle:5 reason:22
05-15 10:36:58.187  6397  6526 E BluetoothRemoteDevices: state12newState1
05-15 10:36:58.199  6397  6397 D BluetoothMapService: onReceive
05-15 10:36:58.200  6397  6397 D BluetoothMapService: onReceive: android.bluetooth.device.action.ACL_DISCONNECTED

В настоящее время мой основной путь отладки - прошить AOSP на Пикселе и добавить дополнительные операторы журнала в стек BT. Пока что проблема не возникла в AOSP, хотя (конечно), что наводит меня на мысль, что за это может быть ответственна какая-то сторонняя служба или служба Google.

Есть идеи, как отследить это? В настоящее время помогает только велосипедный Bluetooth.

...