I am developing an Android app (API 23+) that communicates via BLE with a device. There is no pairing / bonding involved.
The happy path of the interaction is that the app connects then sends a message to the device, and the device in turn sends a reply back, then they both disconnect.
While characterizing strange behavior I asked in Android BLE unexpectedly reconnects potentially from PBAP / MAP Bluetooth profiles, I created a simple service to monitor low-level bluetooth connections; it listens for broadcasts of BluetoothDevice.ACTION_ACL_CONNECTED and BluetoothDevice.ACTION_ACL_DISCONNECTED.
While most of the time the connect / disconnect corresponds well between app and device, sometimes the app receives a disconnect notification that can be ~5-20 seconds after both the app and device have closed the connection. I have verified that the device actually closed, and the app logs all show the system properly shutting down the connection.
In these instances, if the app tries to connect again with the device before ACL_DISCONNECTED is broadcast, it will either receive an error or the subsequent connect request is queued and kicked off after the ACL_DISCONNECTED broadcast.
This does not seem to be specific to devices --- I test with a variety of makes and models --- nor the API version (23-25).
- Is this known (expected) behavior?
- Are there ways to mitigate this issue?...to ensure the disconnect indeed happens in a timely manner?
- Is there a more direct way --- e.g., through an API call --- to tell if the connection is still up, as opposed to receiving ACL-related broadcasts?