在 RxAndroidBLE 中，RxBleDevice.establishConnection() 方法在 autoConnect=true 时无限阻塞
In RxAndroidBLE, RxBleDevice.establishConnection() method is blocking infinitely when autoConnect=true
我正在使用 RxAndroidBle 库与 BLE 设备通信。目标是执行 BLE 扫描、查找设备并与其建立连接。我正在使用 autoConnect = true 在后台保持连接 运行，但是，我注意到，有时，此方法会被阻止（我有 60 秒的超时时间）并且它会计时出去。此外，当 nRF Connect 在后台 运行 时，似乎连接成功了。这是发生问题时的日志：
2020-07-06 13:22:50.579 ***************** D/BluetoothGatt: connect() - device: 06:05:04:50:D0:84, auto: true
2020-07-06 13:22:50.579 ***************** D/BluetoothGatt: registerApp()
2020-07-06 13:22:50.579 ***************** D/BluetoothGatt: registerApp() - UUID=f5c4a5c2-0655-4585-a430-afce97ba1541
2020-07-06 13:22:50.581 ? D/bt_btif: bta_gattc_register: state 2
2020-07-06 13:22:50.582 ? I/bt_stack: [INFO:gatt_api.cc(949)] GATT_Register417325bf-23e7-e29a-197a-cc3215966959
2020-07-06 13:22:50.582 ? I/bt_stack: [INFO:gatt_api.cc(969)] allocated gatt_if=10
2020-07-06 13:22:50.582 ? I/bt_btif: HAL bt_gatt_callbacks->client->register_client_cb
2020-07-06 13:22:50.582 ***************** D/BluetoothGatt: onClientRegistered() - status=0 clientIf=10
2020-07-06 13:22:50.584 ? D/bt_btif_config: btif_get_address_type: Device [06:05:04:50:d0:84] address type 0
2020-07-06 13:22:50.584 ? D/bt_btif_config: btif_get_device_type: Device [06:05:04:50:d0:84] type 2
2020-07-06 13:22:50.584 ? D/bt_btif: btif_gattc_open_impl Transport=2, device type=2, phy=1
2020-07-06 13:22:50.584 ? I/bt_btif: bta_sys_event: Event 0x112
2020-07-06 13:22:50.584 ? I/bt_btif: bta_dm_sm_execute event:0x12
2020-07-06 13:22:50.584 ? D/bt_btm: BTM_SecAddBleDevice: dev_type=0x2
2020-07-06 13:22:50.584 ? D/bt_btm: InqDb device_type =0x2 addr_type=0x0
2020-07-06 13:22:50.584 ? I/bt_btif: bta_sys_event: Event 0x116
2020-07-06 13:22:50.584 ? I/bt_btif: bta_dm_sm_execute event:0x16
2020-07-06 13:22:50.584 ? I/bt_btm: BTM_BleStartAutoConn
2020-07-06 13:22:50.584 ? I/bt_btif: bta_sys_event: Event 0x1f00
2020-07-06 13:22:50.584 ? I/bt_stack: [INFO:gatt_api.cc(1122)] GATT_Connectgatt_if=10 06:05:04:50:d0:84
2020-07-06 13:22:50.584 ? I/bt_btm: BTM_BleUpdateBgConnDev() add=1
2020-07-06 13:22:50.584 ? I/bt_btm: btm_ble_start_auto_conn start=0
2020-07-06 13:22:50.584 ? D/bt_btm: conn_st = 0, not in auto conn state, cannot stop
2020-07-06 13:22:50.584 ? I/bt_btm: btm_ble_start_auto_conn start=1
2020-07-06 13:22:50.585 ? E/bt_osi_wakelock: wakelock_acquire wakelock acquired
2020-07-06 13:22:50.615 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:22:50.645 ? W/auditd: type=1400 "libwatcher_bina""file-nr""proc"
2020-07-06 13:22:50.880 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:22:50.880 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:22:50.881 ? E/bt_osi_wakelock: wakelock_release wakelock released
2020-07-06 13:22:50.921 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:22:51.585 ? I/vendor.qti.bluetooth@1.0-ibs_handler: DeviceSleep: TX Awake, Sending SLEEP_IND
2020-07-06 13:22:51.585 ? D/vendor.qti.bluetooth@1.0-ibs_handler: SerialClockVote: vote for UART CLK OFF
2020-07-06 13:22:51.736 ? D/vendor.qti.bluetooth@1.0-wake_lock: Release wakelock is released
当我成功连接时，日志如下所示：
2020-07-06 13:13:44.670 ? I/bt_btif: bta_sys_event: Event 0x1f00
2020-07-06 13:13:44.671 ? I/bt_stack: [INFO:gatt_api.cc(1122)] GATT_Connectgatt_if=10 06:05:04:50:d0:84
2020-07-06 13:13:44.671 ? I/bt_btm: BTM_BleUpdateBgConnDev() add=1
2020-07-06 13:13:44.671 ? I/bt_btm: btm_ble_start_auto_conn start=0
2020-07-06 13:13:44.671 ? D/bt_btm: conn_st = 0, not in auto conn state, cannot stop
2020-07-06 13:13:44.671 ? I/bt_btm: btm_ble_start_auto_conn start=1
2020-07-06 13:13:44.822 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:13:44.823 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:13:44.873 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:13:45.566 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:13:45.566 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:13:45.607 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:13:45.834 ? I/vendor.qti.bluetooth@1.0-ibs_handler: DeviceSleep: TX Awake, Sending SLEEP_IND
2020-07-06 13:13:45.834 ? D/vendor.qti.bluetooth@1.0-ibs_handler: SerialClockVote: vote for UART CLK OFF
2020-07-06 13:13:45.985 ? D/vendor.qti.bluetooth@1.0-wake_lock: Release wakelock is released
2020-07-06 13:13:46.103 ? V/ActivityManager: Broadcast sticky: Intent { act=android.intent.action.SIG_STR flg=0x10 (has extras) } ordered=false userid=-1 from pid=2635 uid=1001
2020-07-06 13:13:47.144 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:13:47.144 ? D/vendor.qti.bluetooth@1.0-ibs_handler: SerialClockVote: vote for UART CLK ON
2020-07-06 13:13:47.148 ? D/vendor.qti.bluetooth@1.0-wake_lock: Acquire wakelock is acquired
2020-07-06 13:13:47.148 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:13:47.152 ? I/bt_hci: BLE HCI(id=62) event = 0x0a)
2020-07-06 13:13:47.152 ? I/bt_btm: btm_identity_addr_to_random_pseudo
2020-07-06 13:13:47.152 ? I/bt_btm: btm_ble_connected
2020-07-06 13:13:47.152 ? D/bt_btm: btm_ble_connected sec_flags=0x1080
2020-07-06 13:13:47.153 ? I/bt_btm: btm_find_or_alloc_dev
2020-07-06 13:13:47.153 ? W/bt_btm: btm_acl_created hci_handle=5 link_role=0 transport=2
2020-07-06 13:13:47.153 ? D/bt_btm: btm_bda_to_acl found
2020-07-06 13:13:47.153 ? D/bt_btm: device_type=0x2
2020-07-06 13:13:47.153 ? D/bt_btm: btm_bda_to_acl found
2020-07-06 13:13:47.153 ? I/bt_btm: btm_ble_start_auto_conn start=1
2020-07-06 13:13:47.153 ? D/bt_btm: btm_bda_to_acl found
我试图分析Android蓝牙源代码，试图找出问题所在，但没有成功。
那么，有没有办法从应用程序端改进连接参数，使连接更积极或类似的东西？ nRF Connect 是否做了一些与库不同的事情，所以它使应用程序更快地连接到设备？还是固件方面有问题，也许应用程序正在等待来自 BLE 设备本身的某些事件？
当使用 autoConnect = true 时 Android 使用宽松的初始扫描参数。根据您的移动蓝牙芯片组的稳健程度以及外围设备的广告参数，连接过程可能需要几分钟。
So, is there a way to improve the connection parameters from the app side, to make connection more aggressive or something similar?
是的，使用 autoConnect = false。这使得初始（隐式）扫描更具侵略性，但将其时间限制为 30 秒。这就是 Android 实现它的方式。
Does nRF Connect do something different than what library does, so it makes app connecting faster to device?
如果您在后台打开 nRF Connect — 请注意它会“窃取”BLE 连接。即：
- 您的外设已断开连接
- 打开
nRF Connect
- 将
nRF Connect置于背景
- 打开您的应用程序
- 连接您的外围设备
- 关闭您的应用程序
- 观察你的外围设备是否连接到 phone 直到
nRF Connect 没有被杀死或者你没有手动断开你的外围设备与它的连接
我正在使用 RxAndroidBle 库与 BLE 设备通信。目标是执行 BLE 扫描、查找设备并与其建立连接。我正在使用 autoConnect = true 在后台保持连接 运行，但是，我注意到，有时，此方法会被阻止（我有 60 秒的超时时间）并且它会计时出去。此外，当 nRF Connect 在后台 运行 时，似乎连接成功了。这是发生问题时的日志：
2020-07-06 13:22:50.579 ***************** D/BluetoothGatt: connect() - device: 06:05:04:50:D0:84, auto: true
2020-07-06 13:22:50.579 ***************** D/BluetoothGatt: registerApp()
2020-07-06 13:22:50.579 ***************** D/BluetoothGatt: registerApp() - UUID=f5c4a5c2-0655-4585-a430-afce97ba1541
2020-07-06 13:22:50.581 ? D/bt_btif: bta_gattc_register: state 2
2020-07-06 13:22:50.582 ? I/bt_stack: [INFO:gatt_api.cc(949)] GATT_Register417325bf-23e7-e29a-197a-cc3215966959
2020-07-06 13:22:50.582 ? I/bt_stack: [INFO:gatt_api.cc(969)] allocated gatt_if=10
2020-07-06 13:22:50.582 ? I/bt_btif: HAL bt_gatt_callbacks->client->register_client_cb
2020-07-06 13:22:50.582 ***************** D/BluetoothGatt: onClientRegistered() - status=0 clientIf=10
2020-07-06 13:22:50.584 ? D/bt_btif_config: btif_get_address_type: Device [06:05:04:50:d0:84] address type 0
2020-07-06 13:22:50.584 ? D/bt_btif_config: btif_get_device_type: Device [06:05:04:50:d0:84] type 2
2020-07-06 13:22:50.584 ? D/bt_btif: btif_gattc_open_impl Transport=2, device type=2, phy=1
2020-07-06 13:22:50.584 ? I/bt_btif: bta_sys_event: Event 0x112
2020-07-06 13:22:50.584 ? I/bt_btif: bta_dm_sm_execute event:0x12
2020-07-06 13:22:50.584 ? D/bt_btm: BTM_SecAddBleDevice: dev_type=0x2
2020-07-06 13:22:50.584 ? D/bt_btm: InqDb device_type =0x2 addr_type=0x0
2020-07-06 13:22:50.584 ? I/bt_btif: bta_sys_event: Event 0x116
2020-07-06 13:22:50.584 ? I/bt_btif: bta_dm_sm_execute event:0x16
2020-07-06 13:22:50.584 ? I/bt_btm: BTM_BleStartAutoConn
2020-07-06 13:22:50.584 ? I/bt_btif: bta_sys_event: Event 0x1f00
2020-07-06 13:22:50.584 ? I/bt_stack: [INFO:gatt_api.cc(1122)] GATT_Connectgatt_if=10 06:05:04:50:d0:84
2020-07-06 13:22:50.584 ? I/bt_btm: BTM_BleUpdateBgConnDev() add=1
2020-07-06 13:22:50.584 ? I/bt_btm: btm_ble_start_auto_conn start=0
2020-07-06 13:22:50.584 ? D/bt_btm: conn_st = 0, not in auto conn state, cannot stop
2020-07-06 13:22:50.584 ? I/bt_btm: btm_ble_start_auto_conn start=1
2020-07-06 13:22:50.585 ? E/bt_osi_wakelock: wakelock_acquire wakelock acquired
2020-07-06 13:22:50.615 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:22:50.645 ? W/auditd: type=1400 "libwatcher_bina""file-nr""proc"
2020-07-06 13:22:50.880 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:22:50.880 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:22:50.881 ? E/bt_osi_wakelock: wakelock_release wakelock released
2020-07-06 13:22:50.921 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:22:51.585 ? I/vendor.qti.bluetooth@1.0-ibs_handler: DeviceSleep: TX Awake, Sending SLEEP_IND
2020-07-06 13:22:51.585 ? D/vendor.qti.bluetooth@1.0-ibs_handler: SerialClockVote: vote for UART CLK OFF
2020-07-06 13:22:51.736 ? D/vendor.qti.bluetooth@1.0-wake_lock: Release wakelock is released
当我成功连接时，日志如下所示：
2020-07-06 13:13:44.670 ? I/bt_btif: bta_sys_event: Event 0x1f00
2020-07-06 13:13:44.671 ? I/bt_stack: [INFO:gatt_api.cc(1122)] GATT_Connectgatt_if=10 06:05:04:50:d0:84
2020-07-06 13:13:44.671 ? I/bt_btm: BTM_BleUpdateBgConnDev() add=1
2020-07-06 13:13:44.671 ? I/bt_btm: btm_ble_start_auto_conn start=0
2020-07-06 13:13:44.671 ? D/bt_btm: conn_st = 0, not in auto conn state, cannot stop
2020-07-06 13:13:44.671 ? I/bt_btm: btm_ble_start_auto_conn start=1
2020-07-06 13:13:44.822 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:13:44.823 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:13:44.873 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:13:45.566 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:13:45.566 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:13:45.607 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_SLEEP_IND: 0xFE
2020-07-06 13:13:45.834 ? I/vendor.qti.bluetooth@1.0-ibs_handler: DeviceSleep: TX Awake, Sending SLEEP_IND
2020-07-06 13:13:45.834 ? D/vendor.qti.bluetooth@1.0-ibs_handler: SerialClockVote: vote for UART CLK OFF
2020-07-06 13:13:45.985 ? D/vendor.qti.bluetooth@1.0-wake_lock: Release wakelock is released
2020-07-06 13:13:46.103 ? V/ActivityManager: Broadcast sticky: Intent { act=android.intent.action.SIG_STR flg=0x10 (has extras) } ordered=false userid=-1 from pid=2635 uid=1001
2020-07-06 13:13:47.144 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Received IBS_WAKE_IND: 0xFD
2020-07-06 13:13:47.144 ? D/vendor.qti.bluetooth@1.0-ibs_handler: SerialClockVote: vote for UART CLK ON
2020-07-06 13:13:47.148 ? D/vendor.qti.bluetooth@1.0-wake_lock: Acquire wakelock is acquired
2020-07-06 13:13:47.148 ? I/vendor.qti.bluetooth@1.0-ibs_handler: ProcessIbsCmd: Writing IBS_WAKE_ACK
2020-07-06 13:13:47.152 ? I/bt_hci: BLE HCI(id=62) event = 0x0a)
2020-07-06 13:13:47.152 ? I/bt_btm: btm_identity_addr_to_random_pseudo
2020-07-06 13:13:47.152 ? I/bt_btm: btm_ble_connected
2020-07-06 13:13:47.152 ? D/bt_btm: btm_ble_connected sec_flags=0x1080
2020-07-06 13:13:47.153 ? I/bt_btm: btm_find_or_alloc_dev
2020-07-06 13:13:47.153 ? W/bt_btm: btm_acl_created hci_handle=5 link_role=0 transport=2
2020-07-06 13:13:47.153 ? D/bt_btm: btm_bda_to_acl found
2020-07-06 13:13:47.153 ? D/bt_btm: device_type=0x2
2020-07-06 13:13:47.153 ? D/bt_btm: btm_bda_to_acl found
2020-07-06 13:13:47.153 ? I/bt_btm: btm_ble_start_auto_conn start=1
2020-07-06 13:13:47.153 ? D/bt_btm: btm_bda_to_acl found
我试图分析Android蓝牙源代码，试图找出问题所在，但没有成功。
那么，有没有办法从应用程序端改进连接参数，使连接更积极或类似的东西？ nRF Connect 是否做了一些与库不同的事情，所以它使应用程序更快地连接到设备？还是固件方面有问题，也许应用程序正在等待来自 BLE 设备本身的某些事件？
当使用 autoConnect = true 时 Android 使用宽松的初始扫描参数。根据您的移动蓝牙芯片组的稳健程度以及外围设备的广告参数，连接过程可能需要几分钟。
So, is there a way to improve the connection parameters from the app side, to make connection more aggressive or something similar?
是的，使用 autoConnect = false。这使得初始（隐式）扫描更具侵略性，但将其时间限制为 30 秒。这就是 Android 实现它的方式。
Does nRF Connect do something different than what library does, so it makes app connecting faster to device?
如果您在后台打开 nRF Connect — 请注意它会“窃取”BLE 连接。即：
- 您的外设已断开连接
- 打开
nRF Connect - 将
nRF Connect置于背景 - 打开您的应用程序
- 连接您的外围设备
- 关闭您的应用程序
- 观察你的外围设备是否连接到 phone 直到
nRF Connect没有被杀死或者你没有手动断开你的外围设备与它的连接