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