Android BLE出乎意料地反覆重新連接到外圍設備

Question

我正在開發一個與BLE設備接口的Android應用程序，最近偶然發現了一些奇怪的行爲：當應用程序與設備斷開連接時，幾秒鐘後似乎建立了連接。

我正在更充分地描述問題，並一直專注於藍牙MAP和PBAP配置文件;它們出現在問題點附近的日誌中。但我不確定，如果這是根本原因，我也找不到解決方法。

該應用程序支持API 23-25。迄今爲止，我只有SIM卡出現在手機中的問題，這再次指向PBAP，因爲許多手機似乎只能用SIM卡支持此配置文件。我還沒有能夠在API 23上重現，但現在這些測試手機沒有SIM卡。

BLE設備與汽車應用無關，也沒有處理聯繫人或消息的能力。我沒有在應用程序中故意啓用任何此類功能。此外，我的應用程序和設備之間不存在配對/綁定，設備也不支持配對/綁定。

在大多數情況下，嘗試重新連接發生一次，通過應用程序斷開設備幾秒鐘後。應用程序中的後續連接斷開序列具有相同的行爲。不過，我至少在一個例子中看到重新連接（應用程序之外）每隔幾秒就會無限期地繼續。

似乎短期解決問題的唯一方法是在手機上循環藍牙，或強制停止藍牙共享過程。我不認爲重新連接會自行恢復，但通常情況下，一旦用戶連接，它們會重新出現 - 通過我的應用程序與設備斷開連接。

我對PBAP/MAP不是很熟悉，所以我不知道它們是如何啓用的，或者如果可能的話，如何禁用它們。我不確定他們是否是罪魁禍首，但他們在重新連接時出現在日誌中。

以下是圍繞斷開點和隨後重新連接的日誌語句。這裏的接口名稱是「Foo04」，MAC = B0：B4：48：E8：FA：04。

03-31 14:27:44.305 D/RxBle#Radio(14105): STARTED RxBleRadioOperationDisconnect(186827491) 
03-31 14:27:44.319 D/BluetoothManager(14105): getConnectionState() 
03-31 14:27:44.320 D/BluetoothManager(14105): getConnectedDevices 
03-31 14:27:44.332 D/BluetoothGatt(14105): cancelOpen() - device: B0:B4:48:E8:FA:04 
03-31 14:27:44.334 D/BtGatt.GattService(13168): clientDisconnect() - address=B0:B4:48:E8:FA:04, connId=5 
03-31 14:27:44.339 E/bt_btif (13168): bta_gattc_mark_bg_conn unable to find the bg connection mask for: b0:b4:48:e8:fa:04 
03-31 14:27:44.340 D/BtGatt.GattService(13168): onDisconnected() - clientIf=5, connId=5, address=B0:B4:48:E8:FA:04 
03-31 14:27:44.341 D/BluetoothGatt(14105): onClientConnectionState() - status=0 clientIf=5 device=B0:B4:48:E8:FA:04 
03-31 14:27:44.342 D/RxBle#BluetoothGatt(14105): onConnectionStateChange newState=0 status=0 
03-31 14:27:44.345 D/RxBle#Radio(14105): FINISHED RxBleRadioOperationDisconnect(186827491) 
03-31 14:27:44.352 D/BluetoothGatt(14105): close() 
03-31 14:27:44.352 D/BluetoothGatt(14105): unregisterApp() - mClientIf=5 
03-31 14:27:44.354 D/BtGatt.GattService(13168): unregisterClient() - clientIf=5 
03-31 14:27:45.376 W/bt_l2cap(13168): l2cble_process_conn_update_evt: Error status: 22 
03-31 14:27:45.377 W/bt_btif (13168): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016 
03-31 14:27:45.377 W/bt_btif (13168): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016 
03-31 14:27:45.377 I/bt_btm_sec(13168): btm_sec_disconnected clearing pending flag handle:13 reason:22 
03-31 14:27:45.381 E/BluetoothRemoteDevices(13168): state12newState1 
03-31 14:27:45.393 D/BluetoothMapService(13168): onReceive 
03-31 14:27:45.393 D/BluetoothMapService(13168): onReceive: android.bluetooth.device.action.ACL_DISCONNECTED 
03-31 14:27:45.402 D/BluetoothPbapReceiver(13168): PbapReceiver onReceive action = 
03-31 14:27:45.404 D/BluetoothPbapReceiver(13168): Calling start service with action = null 
03-31 14:27:45.405 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth disconnect broadast for Foo04 B0:B4:48:E8:FA:04 
03-31 14:27:46.407 W/bt_smp (13168): smp_br_connect_callback is called on unexpected transport 2 
03-31 14:27:46.408 W/bt_btif (13168): bta_dm_acl_change info: 0x0 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.408 D/bt_btif_dm(13168): remote version info [b0:b4:48:e8:fa:04]: 0, 0, 0 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=16 
03-31 14:27:46.408 I/bt_bta_dm(13168): bta_dm_gatt_disc_result service_id_uuid_len=2 
03-31 14:27:46.412 E/BluetoothRemoteDevices(13168): state12newState0 
03-31 14:27:46.457 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth connect broadast for Foo04 B0:B4:48:E8:FA:04 
03-31 14:27:47.317 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK OFF using UART driver's ioctl() 
03-31 14:27:48.421 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK ON using UART driver's ioctl() 
03-31 14:27:48.483 W/bt_btif (13168): bta_gattc_conn_cback() - cif=3 connected=0 conn_id=3 reason=0x0016 
03-31 14:27:48.483 W/bt_btif (13168): bta_gattc_conn_cback() - cif=4 connected=0 conn_id=4 reason=0x0016 
03-31 14:27:48.483 I/bt_btm_sec(13168): btm_sec_disconnected clearing pending flag handle:14 reason:22 
03-31 14:27:48.488 E/BluetoothRemoteDevices(13168): state12newState1 
03-31 14:27:48.506 D/BluetoothMapService(13168): onReceive 
03-31 14:27:48.506 D/BluetoothMapService(13168): onReceive: android.bluetooth.device.action.ACL_DISCONNECTED 
03-31 14:27:48.524 D/BluetoothPbapReceiver(13168): PbapReceiver onReceive action = android.bluetooth.device.action.ACL_DISCONNECTED 
03-31 14:27:48.527 D/BluetoothPbapReceiver(13168): Calling start service with action = null 
03-31 14:27:48.530 I/TrustAgent.Tracker(15208): [BluetoothConnectionTracker] Bluetooth disconnect broadast for Foo04 B0:B4:48:E8:FA:04 
03-31 14:27:49.430 I/WCNSS_FILTER(13194): ibs_msm_serial_clock_vote: vote UART CLK OFF using UART driver's ioctl() 

進一步調查

我Android BLE ACL_DISCONNECTED sometimes delayed發佈一個相關的問題。

我看到問題的設備之間的一個共同點是存在SIM卡，但另一個是API 24或25.我還沒有能夠在API 23設備上重現，不管版本如何，都沒有物理安裝的SIM卡。

經過更深入的調查，我不太懷疑SIM卡，以及更多的API版本。有幾個優秀的（或最近修復的）具有相關行爲的錯誤，其中一些指向API版本> 23;然而，我後來能夠在API 23上進行復制。

• BLE: Having two pending direct connections and cancelling the second one does not work
• BLE: Disconnecting/closing GATT directly after connect sometimes has no effect due to race conditions
• BLE: Closing gatt object or app does not remove pending connection since Android N
• Race condition in BluetoothGatt when using BluetoothDevice#connectGatt()

我覺得這有一點做與PBAP/MAP配置文件。相反，它們在日誌中的存在僅僅指向這些配置文件在任何BLE斷開的情況下被激活。雖然沒有顯示重新連接行爲，但在與TI SensorTag混淆時，我能夠看到類似的PBAP/MAP激活：這些配置文件再次記錄了任何斷開連接（與我的應用程序無關）。受影響的設備

我已經能夠重現此問題，在不同程度上，對以下設備

列表：

• 三星S6 - API 23
• 三星S7 - API 23
• Samsung S7 Edge - API 24
• Sony Xperia Z5 Compact - API 24
• 摩托羅拉Droid渦輪2 - API 24
• 的Nexus 5X - API 25
• 谷歌像素 - API 25

Answer 1

經過大量調查後，我能夠確定我的問題的根源：Spotify。

在Android設備上安裝Spotify足以證明這種異常行爲;用戶不需要登錄或啓動Spotify應用程序。在所有情況下卸載或強制停止應用程序可以解決問題。

看來，Spotify有一個服務，註冊從任何藍牙外設斷開連接。當系統通知Spotify時，該服務立即連接到剛剛斷開連接的外圍設備---我沒有刻意表徵來自Spotify的通信。約5秒後，連接斷開;但是，由於Spotify會收到藍牙斷開連接事件的通知，該服務會再次嘗試連接外設。這實際上是一個無限循環，只能通過強制停止Spotify或在Android設備上循環使用藍牙才能中止。爲了研究，我開發了一個簡單的應用程序，該應用程序通知並報告藍牙連接和斷開事件（ACL_CONNECTED，ACL_DISCONNECTED）事件。我在Android設備上使用了BLE掃描儀，並通過各種藍牙外圍設備連接/斷開連接。我的測試應用程序將顯示我與外設的初始交互，然後是無限連接流，然後斷開連接事件。再次，這將繼續，直到Spotify被迫停止。

以下是例如日誌...

04-10 19:56:24.109 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED 
04-10 19:56:32.057 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED 
04-10 19:56:34.197 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED 
04-10 19:56:40.396 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED 
04-10 19:56:43.857 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED 
04-10 19:56:49.962 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED 
04-10 19:56:51.130 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED 
04-10 19:57:17.348 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED 
04-10 19:57:17.927 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED 
04-10 19:57:37.621 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED 
04-10 19:57:38.157 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_CONNECTED 
04-10 19:57:44.364 D/BluetoothConnectionMoni: onReceive: deviceName=System05 deviceAddr=B0:B4:48:E8:D7:03 action=ACL_DISCONNECTED 
... 

這是很難確定Spotify的是根源。

我的第一個跡象是通過查看開發者選項 - >運行服務，並定期注意Spotify彈出與外設連接/斷開關聯。最後，它歸結爲消除過程：一旦異常行爲開始，我有選擇地瀏覽已安裝的應用列表，強制停止可能對藍牙有興趣的應用，最終看到問題當我停止Spotify時立即停止。

幾周前我已經向Spotify提供了詳細的錯誤報告，但我還沒有收到他們的回覆。

Answer 2

我也只是碰到這種問題制定藍牙BLE應用跌跌撞撞。我的Android設備是帶有API 24的索尼（http://www.gsmarena.com/sony_xperia_x_performance-7949.php）。它是從API 23升級而來的。從Android 6 - > 7.

它沒有SIM卡，所以我不認爲SIM卡有什麼區別。但它有一個SIM卡插槽，所以也許這就是你的意思。

它配備了BLE芯片版本4.2 - 不確定是否屬於您的問題。我今天將嘗試更多地處理這個問題。

Answer 3

這似乎是固定在Spotify 8.4.19.792開始2017-09-14發佈。