I'm trying to create a bond between my Android phone and my device. Before they were connected well by calling device.connectGatt() with my gattCallback. But now as I want to also want to add bonding by calling device.createBond(), my onConnectionStateChange shows an alternate pattern of connected and disconnected with the status code 0 when connected and 8 when disconnected. Here is my snippet of code of how I'm trying to use connectGatt and createBond together.
#Override
public void onScanResult(int callbackType, ScanResult result) {
System.out.println("on scan result");
super.onScanResult(callbackType, result);
BluetoothDevice device = result.getDevice();
synchronized (this) {
if (mBluetoothGatt == null) {
if (device.createBond()) {
System.out.println("create bond success");
mBluetoothGatt = device.connectGatt(mListener.retrieveApplicationContext(), true, mGattCallback);
}
else System.out.println("create bond sb");
}
}
}
Is there anything wrong by calling these two methods in this way? I searched the internet for creating bonds but none of the pages uses createBond and connectGatt together. I only got a hint from this post about how to call these two methods this way: Android BLE onCharacteristicChanged() using notify not triggered
Also, my BroadCastReceiver always shows device bonding as well but never shows device bonded.
The createBond method will internally first connect to the device if not connected using autoConnect set to false. That means the bonding attempt will be aborted after 30 seconds if the device never connects successfully during that time. But you connect using autoConnect set to true, which means no timeout. So if it for some reason takes 31 seconds to connect, the bonding will not happen.
If I were you, I'd first connect the device myself, and when the device has successfully connected and services discovered (and checked that it has the desired services), call createBond, to make sure everything seems right before bonding.
Status code 8 means "Connection Timeout". This means the connection was up and running but dropped unexpectedly on the radio level, which is not a software error, but something that happens naturally as you go out of range but also due to bad hw such as buggy firmware or bad crystal clock frequency.
Related
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.
Background:
I have a BLE peripheral with two modes: "Application" and "Bootloader". In both modes, the device advertises with the same MAC address.
To switch from one mode to the other, the BLE peripheral must reboot itself. In doing so, it has to disconnect any active BLE connection.
The BLE peripheral only stays in Bootloader mode for about 5 seconds. If nobody connects to it within that window, it switches to Application mode.
The Problem:
Android takes a very long time to reconnect to the BLE device, long enough that I'm missing the 5 second window. The raw code has a few layers down to the BluetoothGATT and BluetoothAdapter layers, but the sequence of calls boils down to:
BluetoothGattCharacteristic c = mCharacteristics.get(POWER_STATE_UUID);
c.setValue(SHUTDOWN_VALUE);
mBluetoothGatt.writeCharacteristic(c);
// Signalled by BluetoothGattCallback.onCharacteristicWrite
bleWriteCondition.await();
mBluetoothGatt.disconnect();
// Wait for the underlying layer to confirm we're disconnected
while( mConnectionState != BluetoothProfile.STATE_DISCONNECTED ) {
// Signalled by BluetoothGattCallback.onConnectionStateChange
bleStateCondition.await();
}
mBluetoothGatt.connect();
while (mConnectionState != BluetoothProfile.STATE_CONNECTED) {
// Signalled by BluetoothGattCallback.onConnectionStateChange
bleStateCondition.await();
if (bleStateCondition.stat != 0) {
break;
}
}
Am I going about this entirely the wrong way? I've tried calling close() on the BluetoothGatt instance, then generating a new one with BluetoothDevice.connectGatt, but I get the same extremely slow behavior.
I'm testing on a Samsung Galaxy S4, API level 21.
The problem here is that the gatt connect call issues a background connection request. It can take quite a long time for this call to result in a connection. A description of the two types of connection request is here : Direct vs Background connections
The absolute fastest way to get a connection is to do a scan and upon finding your device issue a direct connection request to it. As the scan has just found it, you know it is there and the connection will complete quickly. This is more complicated than your example code, but will be most effective given your small window. A scan is the most aggressive way to find a device. However, if you already have the device object, you could just call a direct connection request on the device.
Scans are issued using code like this :
scanner = bluetoothAdapter.getBluetoothLeScanner();
settings = new ScanSettings.Builder()
.setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
.build();
filters = new ArrayList<ScanFilter>();
ScanFilter uuidFilter = new ScanFilter.Builder()
.setServiceUuid(YOUR_SERVICE_UUID).build();
filters.add(uuidFilter);
scanner.startScan(filters, settings, myScanCallback);
Upon finding your device (using the scan callback), issue a direct connection request via this method call :
myGatt = myDevice.connectGatt(this, false, myGattCallback);
The key part being the parameter of false. The connection request will time out in around 30s if the device is not found.
Is it possible to automatically connect to Bluetooth Low Energy (BLE) devices?
The Android documentation indicates that the [BluetoothDevice.connectGatt()](https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#connectGatt(android.content.Context, boolean, android.bluetooth.BluetoothGattCallback)) has a autoConnect parameter:
boolean indicating whether to automatically connect to the BLE device
as soon as it becomes available
However, to call this, you need a BluetoothDevice first. AFAIK the only way to get this is by scanning available devices. Setting up a scan every time to connect to a device doesn't seem like a desirable way. Also, I tried using nRF Control Master Panel to connect to my peripheral using the autoConnect = true, but this does not connect to the device. Connecting without the autoConnect however does make it connect, and I've managed to read and write data from and to my peripheral this way with success.
The general way in Bluetooth to have two devices paired. However, searching for my BLE device and using BluetoothDevice.createBond() does not seem to work. In my ACTION_BOND_STATE_CHANGED-callback, the EXTRA_BOND_STATE and EXTRA_PREVIOUS_BOND_STATE just go from BOND_BONDING to BOND_NONE and back. I don't read out an error or anything - so maybe I'm missing something here. Here's the callback:
private final BroadcastReceiver mGattUpdateReceiver = new BroadcastReceiver() {
#Override
public void onReceive(Context context, Intent intent) {
final String action = intent.getAction();
if (BluetoothDevice.ACTION_BOND_STATE_CHANGED.equals(action)) {
final int state = intent.getIntExtra(BluetoothDevice.EXTRA_BOND_STATE, BluetoothDevice.ERROR);
final int prevState = intent.getIntExtra(BluetoothDevice.EXTRA_PREVIOUS_BOND_STATE, BluetoothDevice.ERROR);
Log.e(TAG, "prevState " + prevState + ", state " + state);
}
}
};
So this type of bonding does not seem to work.
My question is: am I doing something wrong for pairing or the autoConnect? Or is how I currently have it working the only correct way? It seems like a real pain (and battery-drain) to have to scan for devices every time, see if the device is there, if so read data and check back tomorrow, otherwise check back in an hour or so. The point of Bluetooth is that it should pair directly whenever it is near, isn't it?
It does work without rescan. You do not need pairing at all. Just call BluetoothGatt.connect() again for gatt object you aquired from first connection.
You will receive onConnectionStateChange event in your BluetoothGattCallback as soon as ble device will be available again. If you use autoconnect option, you don't even need to call BluetoothGatt.connect() method. Just monitor your cllback, and don't forget to close BluetoothGatt with close() if you don't see any connection for too long.
And yes, to obtain first connection you should scan for ble devices with BluetoothAdapter.startLeScan, not the common bluetooth devices scan.
I am develop in Android and BLE. I want the App automatic reconnect to the BLE device after the BLE device disconnect but come back in the range and advertising.
I use the following code to connect to the BLE device:
public void connect(final String address) {
// TODO Auto-generated method stub
Log.w(TAG, "BluetoothLeService Connect function.");
if(mBluetoothAdapter == null || address == null){
Log.w(TAG, "BluetoothAdapter not initialized or unspecified address.");
//return false;
}
final BluetoothDevice device = mBluetoothAdapter.getRemoteDevice(address);
mBluetoothGatt = device.connectGatt(this, true, mGattCallback);
}
I have set the AutoConnect to the true , but it didn't reconnect when the BLE device has disconnect and come back in the range.
Why the App doesn't reconnect to the BLE device when set autoConnect to true in Android?
Did I missing something ?
Thanks in advance.
The auto connect parameter determines whether to actively connect to the remote device (or) rather passively scan and finalize the connection when the remote device is in range.
But this does not mean that a peripheral that's been disconnected for days then reappears will be reconnected.
Generally, the first ever connection to a device should be direct (autoConnect set to false) and subsequent connections to known devices should be invoked with the autoConnect parameter set to true.
Also please note, the auto connect will only work when the device is still broadcasting. If not, then it will not work.
I would prefer that you re-connect manually when the device is disconnected. If in case you do end up following this, you would need a marker to determine whether the device was actually disconnected without the user consent.
If true then unbind/unregister your service/broadcast receiver and connect again using the device address which you must have saved previously.
As per my experimentation with the BLE devices it has different behavior in different builds like Kitkat and Lollipop. Even I have observed, using ScanCallback is not so reliable introduced in API level 24.
For auto connect to work the BLE device must be active.
For me i had to support kitkat and lollipop so while connecting gatt i called as:
if(Build.VERSION.SDK_INT == Build.VERSION_CODES.KITKAT) {
gatt = device.connectGatt(this, true, executor);
} else {
gatt = device.connectGatt(this, false, executor);
}
Now auto connect is working for me in both Lollipop and Kitkat.
using the android 4.4 BLE APIs on my Nexus7, i'm able to successfully interact with a peripheral BLE device -- connect, disconnect, read, write....
if however an active connection breaks for whatever reason (in this case, the peripheral is reset), i observe the following behavior....
my peripheral (by design) begins advertising after any active connection is terminated (for whatever reason); i can see this via my bluetooth packet sniffer....
i receive the onConnectionStateChanged callback as expected in my android app, at which point i invoke close() on my active BluetoothGatt instance; this is the same procedure i follow during a "normal" disconnect initiated from the client...
shortly after this, the android BLE stack tries to re-connect to the same peripheral; through the packet sniffer i can see the BLE connection request going out over the air...
my app, however, did not initiate this re-connection; indeed, i see no information from any bluetooth log suggesting this even happened!!!!
is there some "mode" in the BLE stack where it attempts to re-establish busted connections automatically???
thanks....
This happens on various Android phones whether the autoConnect flag is set to false or true.
Couldn't yet find a complete solution, it seems as the android BLE stack is spontaneously re-initiating the connection once it is getting the advertising signal again, just ignoring that it was the app that disconnected on purpose...
A partial solution may involve not using the BluetoothGatt.connect() method as explained here:
https://stackoverflow.com/a/23749770/4144487
So, a sample connect method can look like:
void connect(Context context) {
if (mGatt != null) {
mGatt.close();
}
mGatt = mDevice.connectGatt(context, false, callback);
}
To explain the importance of this issue, when it happens the peripheral thinks it is connected and my "real" app can't find it any more. At some phones like Galaxy S3 and Redmi note 3 I found that closing the bluetooth switch from the notification bar is "releasing" the peripheral and allowing me to discover the device. At others like Nexus 5x only a phone reboot will do the trick.
I've observed this happening if you use autoConnect=true when calling BluetoothGatt#connectGatt(). Generally I've found that it is best to use autoConnect=false, but with some devices you simply cannot connect unless you use true, so I usually do both. I try false first and if that fails then use true and then the behavior you're describing is something you simply have to work around.