Please add possibility to use hidden metod refresh on BluetoothGatt

[farmazon3000]

Please add possibility to use hidden metod refresh on BluetoothGatt https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth/BluetoothGatt.java:

/**
     * Clears the internal cache and forces a refresh of the services from the
     * remote device.
     * @hide
     */
    public boolean refresh() {
        if (DBG) Log.d(TAG, "refresh() - device: " + mDevice.getAddress());
        if (mService == null || mClientIf == 0) return false;
        try {
            mService.refreshDevice(mClientIf, mDevice.getAddress());
        } catch (RemoteException e) {
            Log.e(TAG,"",e);
            return false;
        }
        return true;
    }

[dariuszseweryn]

Thank you for the suggestion. We will considerate it. Unfortunately we're currently occupied with different things.

You're always welcome to make a Pull Request. :)

[farmazon3000]

This refresh may be the last resort for problems like #49.

[s1155030742]

This refresh is essential for any kind of function that involve change of characteristic during reconnection. I believe the framework can be much more powerful if "refresh" is supported

[dariuszseweryn]

@s1155030742 I did not had a need for using the refresh function. Could you describe or paste link to a place where the usage is described? Should the method be called when the connection is active/disconnected/closed? What exactly the method does?

[kenwdelong]

Use of this method is discussed here: http://stackoverflow.com/questions/22596951/how-to-programmatically-force-bluetooth-low-energy-service-discovery-on-android

Basically, some phones cache the list of services and characteristics between connections. So if the device has changed it's services or characteristics since you last connected, you can have fatal errors. The refresh() method will clear the phone's cached list.

Based on the code samples and how I understand that it works, I think refresh() would have to be called after connection but before service discovery starts.

I just got bit by this this morning, connections are failing left and right. Is there a way to get hold of the native BluetoothGatt so I can implement the fix described in the Stack Overflow until this feature can be implemented?

[dariuszseweryn]

@kenwdelong You could try to use <T> Observable<T> queue(RxBleRadioOperationCustom<T> operation); function.

[kenwdelong]

Yes! Thank you!

[dariuszseweryn]

To all interested people: What is the supposed scenario for calling BluetoothGatt.refresh()?

1. Call it at the beginning of the connection
2. Call it in the middle of the connection
3. Call it at the end of the connection

The last option looks to be the most bulletproof in terms of implementation. The first one seems also to be doable and should not require a big amount of work. The second does look like a pain to implement as some Observables that could have beed created / subscribed before refreshing could stop working properly.

Any information about the use-cases for this is valuable! :)

[Rioner123]

Hi all, just ran into this problem now! The bluetooth connection on my device disables and I cannot re-enable it unless I flush the data/cache of the bluetooth process. The only way to do this is to call BluetoothGatt.refresh();

Problem 1. Bluetooth is currently disabled and I need to be able to run the refresh method first (because I don't have a valid connection)

Regarding best scenario for calling BluetoothGatt.refresh(), I would personally prefer at the beginning of the connection. Reasoning: It's the only predictable place where I can reliably call it.

[kenwdelong]

For us, our device can be in normal "application" mode or in "dfu" (direct firmware upgrade) mode. In dfu mode, the list of services and characteristics is a subset (generally) of what's available in application mode. So, for example, if the device is scanned in dfu mode, and the phone caches the results of service discovery, then even if the device has returned to application mode it can't be accessed because the phone does not believe that the required characteristics exist (and vice versa).

I really don't know when is the best time to refresh. Just after connecting and before service discovery, or just before or after connecting. I doubt that refreshing in the middle of the connection is a good idea.

The Nordic DFU Upgrade library, I think, disconnects but then before it releases the BluetoothGatt object it invokes the refresh() function. That's probably a pretty safe option.