Disconnecting and closing BLE connection stops classic Blutetooth profile too

I have a setup with two Android devices: an android phone and a custom hardware running Android 10. The latter acts as a BLE Server, which is discoverable always with the same static MAC address. Also when that custom HW is paired with the phone it has access to phone’s contacts and calls history. That HW can also play media (sound) streamed from the phone.

I use RxAndroidBle 1.11.0 library for BLE communication. As soon as I exchange some data via BLE Characteristic I unsubscribe from the RX observable so the library effectively calls: bluetoothGatt.disconnect() then blutetoohGatt.close() (all those inside the DisconnectOperation class).

My problem is the fact that based on my observations, calling blutetoohGatt.disconnect() disconnects the classic BT profile (PBAP) as well.

Is it an expected behaviour?

I have investigated the code of generic Android P framework and it looks that callingbluetoothGatt.disconnect()-> bluetoothGatt.close() completely disconnects the device described by the given MAC Address: BluteoothGatt#disconnect() BlutetoothGatt#close() BlutetoothGatt#unregisterApp()

I would risk a statement that I possibly have quite unusual BLE use-case scenario where the phone (Central/Client) and the peripheral (custom Android HW/Server) are connected simultaneously via Classic BT profile and via BLE. I suspect that disconnecting/closing device using its BT MAC address disconnect both profiles, hence the contacts sharing stops working. Is it possible to disconnect BLE connection only, but not affect the classic BT (SPP/PBAP) connections between the two devices?

[dariuszseweryn]

From what I read in the above mentioned links I see that the hardware is dual-mode i.e. it uses SPP (Classic Bluetooth) and GATT (BLE). Judging from the screens / text and more links they also used different MAC addresses for their BT and BLE functionalities. Anyway — I am glad you resolved the problem. Unfortunately as far as I know the library cannot do anything to help — this is an OS BLE stack problem.

[gary0707]

Thanks for the response and posted links. In those cases, the “duality” seems to be related to fact, that the BT HW can act as a both: master and slave. That is not my case probably. I am still not sure that I have fully resolve my problems, but for sure the order of pairing (BLE first then Classic) is crucial in my case. All in all the topic I have raised in this ticket seems to be resolved hence I have closed it.