Omnipod DASH - adressing race condition on connection startup AAPS 3.3.2.1 Android 16

[vanmegen]

When I switched to my new Phone, a Google Pixel 10 Pro XL, I noticed that the Omnipod DASH did no longer work reliably.

The symptom was a cycle of
connecting -> handshaking -> connecting -> ....

Looking at system logs, I noticed:

11-12 08:20:40.962  2824  3204 I bt_bta_gattc: system/bta/gatt/bta_gattc_act.cc:537 bta_gattc_conn: Connected to xx:xx:xx:xx:8a:d9, robust caching support is 0
11-12 08:20:40.984  2824  3393 W bt_btm_sec: system/stack/btm/btm_sec.cc:874 BTM_SetEncryption: Security Manager: BTM_SetEncryption busy, enqueue request
11-12 08:20:41.043  2824  3204 W smp_act : system/stack/smp/smp_act.cc:2086 smp_link_encrypted: SMP state machine busy so skipping encryption enable:1 device:xx:xx:xx:xx:8a:d9

11-12 08:20:41.058 24799 24933 D PUMPBTCOMM: [binder:24799_4]: [BleCommCallbacks.onConnectionStateChange():42]: OnConnectionStateChange with status/state: 0/2

11-12 08:20:41.123  2824  3393 E bt_btif_gattc: system/btif/src/btif_gatt_client.cc:270 btif_gattc_upstreams_evt: Unhandled event (17)!

Note that
BTA_GATTC_ENC_CMPL_CB_EVT = 17, /* encryption complete callback event */

I.e., the encryption completed log message comes after the bluetooth callback onConnectionStateChange has been called, causing the call to discoverServices() to happen when encryption has not been completely setup.

This PR changes the behavior such to add a small delay in the OnConnectionStateChange handler waiting 1 second so that encryption can complete before discover services is called.

Now, the logs show that there is a 1 second delay before discoverServices is called.

11-12 08:20:42.065 24799 24799 D PUMPBTCOMM: [main]: [BleCommCallbacks$onConnectionStateChange$1.invokeSuspend():49]: OnConnectionStateChange now delivering gattConnected
11-12 08:20:42.070 24799 24970 D PUMPBTCOMM: [RxCachedThreadScheduler-52]: [Connection.connectionState():174]: GATT connection state: 2

FVM now discoverServices IMMEDIATELY AFTER RECEIVING, i.e., less than 100msec later (which could be less than it takes to encrypt the link, see above)
11-12 08:20:42.071 24799 24970 D PUMPBTCOMM: [RxCachedThreadScheduler-52]: [ServiceDiscoverer.discoverServices():28]: Discovering services

With this change, I did not have problems with my last 3 Pods.

Attached is an annotated log with this change:
2025-11-12 previous pod - with paring - sample-event17-delay - working.txt

Could someone with similar issues please verify

[MilosKozak]

Dispatchers.Main is used for UI operation
change to Dispatchers.IO

[vanmegen]

Hi @MilosKozak Updated to Dispatchers.IO

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[nickb24]

Adding a hard-coded 1 second delay might cause the Pod to prematurely disconnect. If the Pod doesn't receive a Bluetooth operation with a certain amount of time it will automatically close the connection on it's own. So this 1 second delay might cause issues for other users on different phones.

What would be better would be to implement a state machine logic where the call to the discover services function only happens after the encryption complete callback. Or maybe consider not calling the discover services function. Android internally calls it automatically and caches the results.

To really understand this issue I think a gatt server log is needed instead of the AAPS logs to understand what is really going on under the hood. I can take a look at the gatt log if provided. I don't think I've seen this race condition before on any logs uploaded so far from people with Dash issues or on my Pixel 7 pro.

[vanmegen]

@nickb24 I attached two gatt logs
2025-11-09-connection-lost-bt-watchdog-not-working.gatt.txt
2025-11-12-previous-pod-with-paring-sample-event17-delay-working.gatt.txt

let me know if you need more processes.

[nickb24]

@vanmegen Sorry I wasn't more clear. The information that would be needed is a "Bluetooth HCI snoop log". To capture this you can follow the steps that Google support detailed in this example: https://issuetracker.google.com/issues/458048110#comment7

However, don't upload these logs publicly. It would contain personal information unless you scrub it first.

[nickb24]

This is an interesting part of the log you provided:

I would be curious to know what device 'xx:xx:xx:xx:04:40' is, but your logs hide the whole mac so I can't do an OUI lookup on it. But in the log is shows that AAPS is attempting to register to the gatt instance connected to that device.

Not sure what this means yet, but this could spark a discussion. Have you already tried disabling the 'nearby device' permission for other apps that could be interfering with AAPS?

[nickb24]

I think I found your issue. Do you have the Dash bond option enabled? Your logs show that AAPS is trying to create a Bond:

If yes, this is known to cause problems on Android 16 and on Discord it has been recommended to turn off the Dash bond option on Android 16.

[vanmegen]

@nickb24

I would be curious to know what device 'xx:xx:xx:xx:04:40' is

The device 04:40 is a withings smartwatch
wednesday-22.1.log:10-22 09:58:08.954 2790 3511 I BluetoothQualityReportNativeInterface: mAddr: C8:67:E2:CD:04:40, mLmpVer: 0x0A, mLmpSubVer: 0x00CA, mManufacturerId: 0x0059, mName: ScanWatch 25, mBluetoothClass: 1f00,

Not sure what this means yet, but this could spark a discussion

I did disable "Android Auto" at some point as it was showing up in the logs. but no difference, so I re-enabled it since.

As a side note, I did try other changes as well:

• disable hardware offloading for BE through the developer settings. - no effect
• disable hardware offloading for bluetooth through developer settings - no effect
• enabling "bt watchdog" in AAPS. that made things actually worse as I had to reboot the phone to get the POD recongnized again (normally, toggling bluetooth off/on in system settings is enough).

[vanmegen]

@nickb24

I think I found your issue. Do you have the Dash bond option enabled? Your logs show that AAPS is trying to create a Bond:

I tried both, with and without bonding and had connectivity issues with both.
The advantage /with/ bonding was that it happens exactly once after pairing. Without bonding it was happening at random times.

With the delay from this PR, it works reliably with and without bonding. (Initially I bonded the pod, but my latest POD is not bonded anymore).

[nickb24]

@nickb24

I think I found your issue. Do you have the Dash bond option enabled? Your logs show that AAPS is trying to create a Bond:

I tried both, with and without bonding and had connectivity issues with both. The advantage /with/ bonding was that it happens exactly once after pairing. Without bonding it was happening at random times.

With the delay from this PR, it works reliably with and without bonding. (Initially I bonded the pod, but my latest POD is not bonded anymore).

Understood. I suggest this PR can be used for people to test, but shouldn't be put into the master branch as is. If this fixes issues for some people, then perhaps logic can be written so that this delay is only added after X failed connection attempts or after detecting the specific scenario race condition scenario.

[zyt]

I noticed that after updating my Pixel 9 Pro XL to Android 16 QPR2 and running v3.3.2.1 without this PR, the issue (connecting -> handshaking -> connecting -> ....) is gone. Would be good if somebody else could also confirm this.

[ttorvela]

I noticed that after updating my Pixel 9 Pro XL to Android 16 QPR2 and running v3.3.2.1 without this PR, the issue (connecting -> handshaking -> connecting -> ....) is gone. Would be good if somebody else could also confirm this.

Thanks for the tip! Seems that my Samsung Galaxy S22 Ultra does bot have this issue anymore either. Also using v3.3.2.1. Second pod in use without this nor any other issues.