Android: Catching BLE Connection Fails/Disconnects?

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

1. 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.
   .

2. 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).
   .

3. 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.
   .

4. 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.