Android 13 disconnects on first connect attempt to paired device after app restart
xalepo4 opened this issue · 9 comments
Hello,
I'm using the plugin with ionic for connect to an EV charger application. On Android devices < 13 all is fine. On Android 13, I can pair with the device but when I close the app and open it again, always get Peripheral disconnected and I cannot get data from the device.
Any ideas?
Thanks
Hi @xalepo4
How long are you leaving the app between closing and opening again? Are you able to confirm from the peripheral side that the phone is actually disconnecting?
There's been a few reports across both this plugin and others now of peripheral disconnect errors surfacing on Android 13, so clearly something has changed there in the OS.
As a fallback, are you able to retry the connection within the app by calling ble.connect again? In most of the applications I write this is my standard way of dealing with connections, which I find are often unreliable at best.
Oh, if possible, grabbing a copy of the adb logs (e.g., adb logcat > debug.logs) may give us some extra information to work with.
Ok, I collect logs today and I attach it here.
Hello @peitschie , any new about the problem?
@xalepo4 I'm away on a vacation at the moment. It'll be about 1.5 weeks before I have a chance to dig into this further.
@xalepo4 Is it possible to grab an equivalent debug.txt log from the working version?
Just to confirm, when you say "close the app", are you meaning when you swipe it up to kill the app in the background, or merely pushing the app into the background, but leaving it running?
Looking through the logs, there seems to be this reason coming up a lot:
03-16 15:19:45.478 17834 18243 I bt_stack: [INFO:gatt_attr.cc(348)] gatt_connect_cback: remove untrusted client status, bda=80:1f:12:b2:7f:ea
03-16 15:19:45.481 17834 18243 I bluetooth: packages/modules/Bluetooth/system/stack/gap/gap_ble.cc:303 client_connect_cback: No active GAP service found for peer:xx:xx:xx:xx:7f:ea callback:Disconnected
03-16 15:19:45.481 17834 18243 I bt_bta_gattc: packages/modules/Bluetooth/system/bta/gatt/bta_gattc_act.cc:1249 bta_gattc_conn_cback: Disconnected att_id:3 addr:xx:xx:xx:xx:7f:ea, transport:BT_TRANSPORT_LE reason:GATT_CONN_TIMEOUT
03-16 15:19:45.481 17834 18243 I bt_bta_gattc: packages/modules/Bluetooth/system/bta/gatt/bta_gattc_act.cc:1249 bta_gattc_conn_cback: Disconnected att_id:4 addr:xx:xx:xx:xx:7f:ea, transport:BT_TRANSPORT_LE reason:GATT_CONN_TIMEOUT
03-16 15:19:45.481 17834 18243 I bt_bta_gattc: packages/modules/Bluetooth/system/bta/gatt/bta_gattc_act.cc:1249 bta_gattc_conn_cback: Disconnected att_id:5 addr:xx:xx:xx:xx:7f:ea, transport:BT_TRANSPORT_LE reason:GATT_CONN_TIMEOUT
03-16 15:19:45.481 17834 18243 I bt_bta_gattc: packages/modules/Bluetooth/system/bta/gatt/bta_gattc_act.cc:1249 bta_gattc_conn_cback: Disconnected att_id:6 addr:xx:xx:xx:xx:7f:ea, transport:BT_TRANSPORT_LE reason:GATT_CONN_TIMEOUT
03-16 15:19:45.481 17834 18243 I bt_bta_gattc: packages/modules/Bluetooth/system/bta/gatt/bta_gattc_act.cc:1249 bta_gattc_conn_cback: Disconnected att_id:7 addr:xx:xx:xx:xx:7f:ea, transport:BT_TRANSPORT_LE reason:GATT_CONN_TIMEOUT
There is no calls made by the plugin here as far as I can tell to cause the disconnect... it's Android itself deciding the GATT connection has dropped, and I don't really see how the plugin can change this.
I wonder if there's perhaps some difference in the default connection intervals between Android versions. E.g., on connection with this version, we find:
03-16 15:19:55.915 16036 16050 D BluetoothGatt: onConnectionUpdated() - Device=80:1F:12:B2:7F:EA interval=6 latency=0 timeout=500 status=0
These connection parameters control how long a drop-out in packets can be handled before the connection is judged as disconnected.
After testing my application a lot, I discover that the problem occurs by some misterious behaviour in Android 13 when I try to connect with my device and the phone has an smartband paired. It seems that Android use the same handle for the smartband and my device. If no smartband paired, the connection works fine.
That's extremely surprising! Impressive investigating skills 🙂 ... thanks for sharing the discovery.