autoConnect stopped working since graduating from pre v1.0 to 1.2 about android-ble-library HOT 18 CLOSED

Hi,

Thanks for the update! I haven't migrated to the beta versions of the library yet, but have been following the progress closely. Will update to beta5 when its available and let you know how I get on.
Great work btw - this library really does make Android BLE much simpler and reliable.

from android-ble-library.

When gatt.connect() was called, then it's up to the Bluetooth chipset to connect. The lib seems to call the method correctly.

from android-ble-library.

Thanks for the quick response. Did a little more investigation and moved back to the old vesion of the library - the problem remained. It was only after clearing the bluetooth cache and restarting my phone it worked again.
Damn Android Bluetooth stack!

I have had a small number of my users in particular Samsung S7-S8 devices have to clear their bluetooth cache and restart their phone to fix a connection which drops out - I'm not 100% sure if this is the same issue, or not though.

Conceptually (i haven't attempted this myself yet, but do intend to), do you think there would be a benefit to implementing a custom autoconnect mode where it only uses autoconnect = false?
I.e. I seem to remember autoconnect set to false tries to connect with different parameters when set to true, but times out after 30 seconds, and defaults to the same parameters as autoconnect set to true (correct me if I'm wrong!) - so was thinking that by setting a repeated timer to go off every 30 seconds I could restart the connection with autoconnect set to false.

from android-ble-library.

An update, in case you're interested.

This problem came back again - restarting the phone and clearing the BLE cache fixes it for a little while before it then breaks again.

I have been able to fix the problem by returning false to shouldAutoConnect(), and restarting the BLEManager in onDeviceDisconnected. I did try simply calling connect.enqueue in onDeviceDisconnected, which looking through the code should be able to reconnect with auto connect set to false - but this wasn't enough to reconnect; I had to completely strip down the BLEManager and reopen it.

@Override
    public void onDeviceDisconnected(BluetoothDevice device) {
        Timber.i("onDeviceDisconnected");
        Logger.e(mLogSession, "onDeviceDisconnected");
        if (!userDisconnected) {
            uiHandler.post(()-> {
                mDuringRideBLEManager.close();
                mDuringRideBLEManager = null;
                Timber.i("Re starting BLEManager");
                Logger.e(mLogSession, "Re starting BLEManager");
                mDuringRideBLEManager = new DuringRideBLEManager(this);
                mDuringRideBLEManager.setGattCallbacks(this);
                mDuringRideBLEManager.setLogger(mLogSession);
                mDuringRideBLEManager.connect(mBluetoothDevice).enqueue();
            });
        }
    }

(i'm now using alpha 5 version of the library)

from android-ble-library.

Hi, any updates on the most recent versions? I'll soon release beta5 with automatic connection retry (if set in the ConnectRequest, disabled by default). I did a lot of tests even on Nexus 4 and I get 100% rate of connections with autoConnect = false (it fails some time with 133, but the lib reconnects automatically now, so it's transparent to the app :) ).

from android-ble-library.

Thanks, great to hear that! Beta 5 is now released. Any feedback or issues are appreciated.

from android-ble-library.

Hi,

Just integrating beta5 now - some feedback: probably worth mentioning in the documentation that the "delay" period of the "retry" Connect Request is in milliseconds (I thought it was in Seconds at first).
It would be good to have a way of retrying the connection for an infinite amount of times (until disconnect is called). Not urgent though, as the max value of Ints is rather large!

BLEManager.connect(mBluetoothDevice).retry(Integer.MAX_VALUE, 10000).useAutoConnect(false).enqueue();

from android-ble-library.

Can't seem to get the retry functionality to work - after issuing the connect request and letting the initial connection timeout, I see "onDeviceDisconnected" triggered, followed by "onError: 133". Then when I turned my BLE device on, no connection is made. If I turn the device on during the initial connection, it connects fine.

I am connecting using the following ConnectRequest:
BLEManager.connect(mBluetoothDevice).retry(Integer.MAX_VALUE).useAutoConnect(false).enqueue();

from android-ble-library.

Yes, that is intended. The retry work with errors other then the timeout (that appear before 20 seconds from connection start). That's to overcome 133 errors caused by packet loss or other reasons, not to keep connecting. This is actually documented there :)

You have to scan and connect when found to achieve what you want.

from android-ble-library.

But that's actually what i could add as well. Scan and connect feature. Because why not.
Would you find it useful? Passing the ScanFilter as a parameter.

from android-ble-library.

Ahh I see, this feature still sounds very useful, and may possibly explain a very rare bug that I've not been able to replicate.

I am actually trying to recreate the behaviour of using autoconnect set to true - but with autoconnect actually always false. I am doing this because I have found that even on some very recent phones (Pixel 2, Samsung S8) autoconnect set to true is not as reliable as I'd like and my use case needs an extremely reliable connection. My device has a private static address, and I don't bond to it.

I have also found that on some phones if bluetooth is turned off, and then turned back on just before trying to connect, it doesn't connect even with autoconnect set to false. I therefore do a dummy scan just before trying to connect - it doesn't even have to find anything, some phones seem to need to go through the motions of scanning before they can connect.

Here is what I currently do, to give the connection reliability I need:

1. Users Scan for their device (using Nordic Scanner Compat Library) in a separate part of the app.

2. The device has a private static address, so when the user has found their device, this static address is saved to the app.

3. Some time later, in a separate part of the app, users select the BLE device they wish to connect to.

4. The app turns Bluetooth on if not already on.

5. The app scans for the private static address (using Scanner Compat Library). The device may or may not be found - it doesn't matter.

6. On scan timeout or if the device has been found, the app tries to connect to the private static address using autoconnect set to false.

7. If onDisconnected is called, try to connect again using autoconnect set to false. (this creates a loop to ensure a new connection attempt whenever the connection drops out).

Do you think this functionality as I've described is worth implementing in the library? Its a little more indepth than just scanning for a device and connecting if found.

from android-ble-library.

Yes, that's complicated. Have a look at this document, where I wrote why it works like that (the part about public and private addresses). Turning off Bluetooth removes the device from the security database, and when you try to connect to a saved Bluetooth address after turning it off (without scanning) it assumes a public type address, so the Connect Req will fail. Scanning is required then. It also helps in general to scan before connecting.

Scanning with autoConnect = false is offloaded to the low-power controller and may take much longer time. But it also uses a lot less power and does not have 30 sec. timeout.

Also, I was thinking about adding this scanning into the lib, and I'm afraid it's not doable. Then I was thinking about implementing scanning with PendingIntent (like one added in Android 8 in BluetoothLeScanner) and emulate it on previous versions, but that would 1) not be equally power efficient, 2) would require scanning in a service, and the service would have to be added to the AndroidManifest.

from android-ble-library.

I'm actually writing v2 of this document since few days. Updating it to match new APIs, etc.

from android-ble-library.

Just read the section of the document you mention briefly - explains all of the weird behaviour I've been seeing! (I have read the document before, but must have missed this section). It's a shame the Android BLE API doesn't allow us to specify the type of address if we know it.

I think moving my app forwards, when I initiate the scan at the start , I'll continue to scan until the device is seen. Not very power efficient, but as it is a fitness tracking app with GPS and BLE, customers expect some power usage. (I thought of passing in a flag if bluetooth is turned on by the app - but unfortunately, I won't know if Bluetooth has been turned off and then back on before my app has been opened).

Thanks again for the help - feel free to close this issue, sounds like these problems are more related to my application than the library.

from android-ble-library.

I would recommend always scanning before connecting. Then you are sure the device is nearby. And when the used has the app opened, scan with low patency. If app is closed, in the pocket, scan with PendingIntent on Oreo or low power on older. And perhaps ignore Android 4.3 and 4.4.x unless you target China, but I may be wrong.

from android-ble-library.

I'm actually writing v2 of this document since few days. Updating it to match new APIs, etc.

Apologies for commenting on a closed ticket. I found your write up incredibly helpful but was unable to locate v2 of it?

from android-ble-library.

Yes, I know. I'm still working on it, I was buried with another tasks. I will try to release it in "near" future, but I can't promise any deadline. Sorry :(

from android-ble-library.

Yes, I know. I'm still working on it, I was buried with another tasks. I will try to release it in "near" future, but I can't promise any deadline. Sorry :(

No worries, I understand how busy things can be. Thanks for the original version, it's been an incredibly helpful reference. I'll eagerly/patiently await v2.

from android-ble-library.