I have a question about Android bluetooth LE disconnect(), which behaves differently, depending on the running scenario.
My application connects to an embedded device which runs the GATT server and the communication is working fine. The device is not bonded, pairing process happens every time i connect to it and i disconnect every time the Android activity is closed or paused.
protected void onPause(){
super.onPause();
if(mGattUpdateReceiver != null)
unregisterReceiver(mGattUpdateReceiver);
if (mBluetoothLeService != null)
mBluetoothLeService.disconnect();
}
If the connection is idle (no communication forth and back) then disconnect() works fine and i can see the device receiving disconnect event and everything good.
But when i run a timer on the device sending indications with counting value to android every 750 msec, no disconnect happens when the activity is paused/closed. The device keep sending the counter value and receives HVC confirmations for ever. The only way to stop Android to send HVCs is to disable BT adapter on the phone. Killing the application doesn't help.
I saw this answer here stackoverflow.com/questions/44521828/android-ble-gatt-disconnected-vs-device-disconnected
which is 4 years old. Are we in the same situation now or did I mess it somehow?
Good point!
Yes on a second device it works as expected. As soon as onPause() is hit disconnect is triggered to the remote device, no matter if communication is ongoing or not.
So nothing wrong with Android but something wrong with BT stack on my first device (SGS8)
After connecting to BLE device and discovering its services, I check that a certain characteristic is readable, then, I call readCharacteristic. This call returns true, but the callback onCharacteristicRead is not called.
After merely 30 seconds, the onCharacteristicRead is called with characteristic == null and the onDeviceDisconnected is called with status code equal to 22.
I have tested nRF Connecte to read the same characteristic and it worked fine.
What could possibly be wrong ?
The fact that it timeouts after 30 seconds and disconnects with error 22 (local device terminated the connection) indicates that the peripheral did not respond within 30 seconds, as required by the GATT standard. You should debug the peripheral to find the cause.
The reason it works in nRF Connect might be that the previous GATT sent / received put the peripheral in a different state.
You could check out the HCI log in Android to see all raw packets to maybe figure out what's going on.
So I'm able to connect to a BLE device just fine under normal circumstances. What I want to do is handle abnormal circumstances, like when the connection to a device fails or an established connection is lost (maybe it got thrown off a cliff or hit by a bus)
I'm using a CyPress BLE module to test this, and one of the tests I'm doing is to remove power from the module. However, onConnectionStateChange never gets called! All I ever see it respond to is successful connections. It'll spend hours trying to connect and never give up evidently. I would do a delayed cancellation of the connection attempt, but there is no way to cancel the connection attempt on a Bluetooth device (that I know of)! As far as I can tell it'll keep trying until the battery runs down.
Here's what my onConnectionStateChange looks like right now, inside the Gatt Callback. Note that I'm trying to catch and log ANY kind of callback involving ANY kind of connection state change... which never gets called unless connection success. Note that this is code is not on the activity itself. It's in an object held by a singleton. (I want to maintain connection across multiple activities)
#Override
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
mGatt = gatt;
Logy.CallPrint(LOGY_ENABLE, CLASSNAME, "Status: "+status+ " Newstate: "+newState);
switch(status)
{
case BluetoothGatt.GATT_SUCCESS:
mReconnectAttempts = MAX_ATTEMPTS;
if(newState == BluetoothGatt.STATE_CONNECTED)
{
DispatchEvent(Event.Type.BT_ON_CONNECT);
bIsConnected = true;
gatt.discoverServices();
} else if (newState == BluetoothGatt.STATE_DISCONNECTED)
{
DispatchEvent(Event.Type.BT_ON_DISCONNECT);
bIsConnected = false;
}
break;
default:
if(newState == BluetoothGatt.STATE_DISCONNECTED)
{
bIsConnected = false;
if(mReconnectAttempts > 0)
{ // if we have attempts left, auto attempt to reconnect
DispatchEvent(Event.Type.BT_RECONNECTING);
mReconnectAttempts--;
gatt.connect();
bIsConnected = false;
}
else
{
mReconnectAttempts = MAX_ATTEMPTS;
DispatchEvent(Event.Type.BT_ON_CONNECT_FAIL);
bIsConnected = false;
}
} else {
Logy.CallPrint(LOGY_ENABLE, CLASSNAME, "onConnectionStateChange: Failed?");
}
}
super.onConnectionStateChange(gatt, status, newState);
}
Not being able to detect disconnects is an issue elsewhere in my code, like where I show a Progress Dialog indicating the app is connecting to a BLE device. Well, that dialog never goes away because the event "On Connect Fail" never gets thrown.
I think what you are looking for is Bluetooth Supervision timeout which is according to Bluetooth LE specifications :
a parameter that defines the maximum time between two received Data Packet PDUs before the connection is considered lost
Default Supervision timeoout is set to 20 seconds on Android (depending on Android version & device). For instance, here is the value of Supervision Timeout on Android 5.1.
There is no API to set this parameter, so you will have to wait 20 seconds (depending on your Android version & device) to get onConnectionStateChange callback with status BluetoothGatt.STATE_DISCONNECTED after you power off your BLE module
This answer aligns with the answer from Emil.
I coded up a test App with a single Activity running on Moto G4 Play Android 6.0.1 (Marshmellow: API23) and a Peripheral based on a Laird BL600
I was going to post some logs - but they don't format so well - so I'll just describe the results.
As usual, the Peripheral advertised and the Central scanned, and obtained a device instance.
The question does not state exactly how the first connection is made, but let's assume it is with 'autoconnect' false, of the form
mBluetoothGatt = device.connectGatt(mContext, false, mGattCallback);
(this is the only style of connection used in the test App)
This gives an instance of BluetoothGatt and, as noted in the question, events are then reported asynchronously through the call back,
but there is also an instance of BluetoothGatt on which to call disconnect() even before any connection events have occurred.
The API documentation for disconnect() states - especially the part after the ','
BluetoothGatt.disconnect()
Disconnects an established connection, or cancels a connection attempt currently in progress.
To free up GATT resources, after disconnecting, the test App also then always calls
mBluetoothGatt.close();
Here are some different scenarios
device.connectGatt() -- Peripheral advertising - connection made -- followed by mBluetoothGatt.disconnect() and close().
Result: this is a normal successful connection, followed by Central device closing the connection in code. Call back events are received as expected. When the Central disconnects in the code, the underlying Bluetooth Service disconnects and the Peripheral gets a Disconnection event.
.
device.connectGatt() -- Peripheral advertising - connection made - followed by Peripheral switched off.
Result: this is a normal successful connection, call back events as expected, followed by connection broken by Peripheral. The Peripheral indicates preferred connection supervision timeout in BleGapSvcInit and this is confirmed by Central in a Connection Parameters Update. After Peripheral drops the connection a Disconnection event occurs in Central just after the connection supervision timeout. (Repeated with 8 seconds and 4 seconds supervision timeouts).
.
device.connectGatt() -- but Peripheral has stopped advertising, connection attempt allowed to time out.
Result: (This is a specific scenario of the question) After 30 seconds, probably the connection timeout of the Bluetooth Service on the phone,
there is a an onConnectionStateChange event indicating the new connection state is Disconnected - with (error) status 133.
Must still remember to call mBluetoothGatt.close() else an interface leak occurs and subsequent connection is made on the next client interface.
.
device.connectGatt() -- Peripheral still advertising but connection cancelled after 200ms using mBluetoothGatt.disconnect() and close().
Result: (I found this case the most interesting, if also the most unlikely to happen in a real application) Sometimes, (about 1 in 10)
the underlying Bluetooth Service actually did connect to the Peripheral; which saw a connect, followed by a disconnect; even though the App doesn't see
these events in the call back. Sometimes, even though, as far as the App is concerned, the App is disconnected, the underlying Bluetooth phone service
connected to the Peripheral - and remained connected in my test for a few minutes until I timed out! - and turned the BT service, or the Peripheral, off.
First, if an established connection is dropped you should get a disconnected state change event when the supervision timeout has passed. Otherwise there is some bug in Android.
Now about connection attempts.
Once you create a BluetoothGatt object with connectGatt and specify the auto connect parameter to true OR execute the connect method on an existing BluetoothGatt object, the phone will be in a state where it always and indefinitely tries to connect to the device and reconnect to the device if it disconnects for any reason until you either call disconnect or close on the gatt object.
So if you want to abort the connection after a while, just set up any kind of timer which calls disconnect on the gatt object (or close if you don't need it anymore) when it is triggered.
Also note that the status parameter of the onConnectionStateChange when newState is disconnected is not well-defined. In older Android versions it contains usually 0 or 133 and in newer versions often the Bluetooth standard's error code of the disconnect reason.
Also, if you get a disconnect state change event without previously have got a connected state change event, it usually indicates something has gone wrong in the internal Bluetooth stack (unless you use non-auto connect for which you always get a disconnect state change event after some timeout). Then I'd recommend that you close the gatt object and try again later.
I am developing an Android application to interface with Bluetooth module dual mode.
Due to the module is dual mode, I am confronting the same problems described here.
However I trying to do a workaround, because after first connection the callback onConnectionStateChange() returns status 133. Always in the onStop() method from Main Activity, I close BluetoothGatt object to free resources. Further was added bluetoothGatt.disconnect() before bluetooth.close().
When was called disconnect(), my cellphone get more connections with the module, however after reconnecting sometimes, the callback onConnectionStateChange returns status 22.
I didn't find about status 22 in the BluetoothGatt documentation.
UPDATE
In BLE callbacks are passed status codes that are not in the public API. topic is about status 22 and others.
Thanks
133 error code: Connect timeout or device not found.
22 error code: The bluetooth is closed then device is disconnected.
22 error code: The Connection Terminated By Local Host error code indicates that the local device terminated the connection.
I have a phone app which gets launched on boot and at that point attempts to make a connection to a corresponding app on a wearable device.
However if at that time there isn't a paired wearable then the connection will fail (Wearable.NodeApi.getConnectedNodes won't return anything).
Therefore my app will need to re-attempt the connection at a later time. My question there is this: is there something my code can subscribe to to get a callback when the phone gets paired with a wearable?
the NodeApi.NodeListener as the method onPeerConnected(Node peer), which looks like what you are looking for. It is invoked when a new peer is reachable from the node, where the callback is invoked