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中發布了相關問題， 有時會延遲 。

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

經過進一步的調查 ，我不太喜歡SIM卡，而是更多的API版本。 有幾個有相關行為的突出（或最近修復）錯誤，其中一些指向API版本> 23; 但是，我隨后能夠在API 23上重現。

• BLE：有兩個掛起的直接連接並取消第二個直接連接不起作用
• BLE：連接后直接斷開/關閉GATT有時會因競爭條件而無效
• BLE：關閉gatt對象或應用程序不會刪除自Android N以來的掛起連接
• 使用BluetoothDevice時，BluetoothGatt中的競爭條件#connectGatt（）

我覺得這與PBAP / MAP配置文件沒什么關系。 相反，它們在日志中的存在僅僅指向這些配置文件在任何BLE斷開時被激活。 雖然沒有表現出重新連接行為，但是在弄亂TI SensorTag時我能夠看到類似的PBAP / MAP激活：這些配置文件再次記錄了任何斷開連接（與我的應用程序無關）。

受影響設備列表

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

• 三星S6 - API 23
• 三星S7 - API 23
• 三星S7 Edge - API 24
• 索尼Xperia Z5 Compact - API 24
• 摩托羅拉Droid Turbo 2 - API 24
• Nexus 5x - API 25
• Google Pixel - API 25

Answer 1

經過大量調查，我能夠確定問題的根本原因：Spotify。

在Android設備上安裝Spotify足以表現出這種異常行為; 用戶無需登錄或啟動Spotify應用程序。 在所有情況下卸載或強制停止應用程序可以解決問題。

似乎Spotify有一項服務可以注冊與任何藍牙外設的斷開連接。 當系統通知Spotify時，服務會立即連接到剛斷開連接的外圍設備---我沒有費心去表征Spotify的通信。 大約5秒鍾后連接斷開; 但是，由於Spotify會收到藍牙斷開連接事件的通知，因此該服務再次嘗試連接外圍設備。 這實際上是一個無限循環，只能通過在Android設備上強制停止Spotify或循環藍牙來中止。

為了調查，我開發了一個簡單的應用程序，通知並報告藍牙連接和斷開連接（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

這似乎是從2017-09-14發布的Spotify 8.4.19.792開始修復的。