Expose transport and phy configuration for connection (Android 10 connection issue)

Hey,

Android 10 introduced problems with connecting to multiple BLE devices for me. Linked topics may be related: https://stackoverflow.com/questions/58299507/android-10-ble-connection-issue https://issuetracker.google.com/issues/141188862

I managed to find solution by forcing this config on connection:

bluetoothDevice.connectGatt(
                context,
                false, // auto connect set to false
                connectCallback,
                BluetoothDevice.TRANSPORT_AUTO,
                BluetoothDevice.PHY_LE_CODED
            )

But RxAndroidBle don’t exposes possibility to set transport and phy. Have you considered exposing those settings?

[mtomczynski]

@dariuszseweryn problem has been fixed from the bluetooth device perspective. I think it’s really interesting case. Straight after bonding device didn’t update it’s address type immidiately to correct type (random static) but kept the incorrect (public) one. Address itself was correct.

These are white list operation with bug:

1. Add to white list: type PUBLIC, address true private // First connection after bonding
2. Add to white list: type RANDOM, address true private // All subsequent connections

These are white list operation with fixed address type:

1. Add to white list: type RANDOM, address true private // First connection after bonding
2. Add to white list: type PUBLIC, address current public random address // All subsequent connections

Here’re logs with solution if you’re interested: btsnoop_working.log logcat_highlights.txt

What is most interesting about it, is that this situation is tolerated by all iOS versions and Android version until 10. It appears that they dramatically changed how addresses are handled under the hood.

[dariuszseweryn]

Scanning itself is not full story, if I successfuly scan the devices, then turn off bt for a while and try to connect to them without doing second scan (BluetoothDevice from bonded list), connection is successful.

This is a well-known bug of Android. I have briefly mentioned about it on Wiki

You’re right, the device won’t always pop up in the scans, maybe it’s scanned with true random address and is interpreted by something up in the stack. But still after the scanning it’s added to white list with random type address.

I have been looking on frames between 4531 and 6017. First one is the last moment the peripheral is added to white list with public address type and the second is the first moment the peripheral is added to white list with random address type. I have tried searching for MAC address c5:c1:c4:74:61:88 but have not found it in between. That would suggest that the Android stack has some bug not directly related to this peripheral scan.