Xbee3 BLE. How to notify client (smart phone) of "SERVICE CHANGED"?

I have developed an Android app. It scans for all devices. In the scanCallback I call bluetoothDevice.getName() and if it returns “BANANA” or “APPLE” or “MANGO”… you get the drift… I add the device to the bluetoothDeviceAdapter so that it gets displayed in a list of possible devices to connect to. A “BANANA” looks like a banana, an “APPLE” looks like an apple, an so forth.

Using an Xbee3 with factory default Digimesh config, I enable BLE, set bluetooth Identifier ‘BI’ to “BANANA” and configure a password (salt and verifier) corresponding to “BANANA”.

The Xbee3 device appears in the adapter as a banana. Great!
I may open a connection with said banana (stopScan() and xbeeDevice.open()), and configure it to now be a mango, i.e. change its ‘BI’ and password to “MANGO”.

The problem is that the Android device caches device information.

After closing my connection with my newly configured mango, and starting a new scan, results delivered to the scanCallback have cached device information. bluetoothDevice.getName() still returns “BANANA” even though the Xbee3 is now advertising as “MANGO”. The adapter incorrectly displays the device as a banana and if I try to open a connection with it using password “BANANA”, the connection fails because the Xbee3 is really a mango!

After may hours of Google searching, It appears there is no way of clearing or removing a device from an Android’s BLE cache programmatically, from inside the app. Apparently, the only way to do this programmatically, is for the Xbee3 to send a “Service Changed” indication…

The BLE “Service Changed” characteristic (0x2A05) is a specialized, mandatory indication within the Generic Attribute Service (0x1801) that notifies a GATT client (e.g., smartphone) when the server’s attribute table has been modified. It enables clients to flush cached service data and re-discover services, ensuring they do not use outdated handle mappings.

So how do I do that using the Xbee3 API ???

As is so often the case, I will answer my own question.

I was able to get the cache to update every time a new scan was started by adding scan settings to the startScan() call.

ScanSettings scanSettings = new ScanSettings.Builder()
.setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
.setCallbackType(ScanSettings.CALLBACK_TYPE_ALL_MATCHES)
.setMatchMode(ScanSettings.MATCH_MODE_AGGRESSIVE)
.setNumOfMatches(ScanSettings.MATCH_NUM_ONE_ADVERTISEMENT)
.setReportDelay(0L)
.build();*
bluetoothLeScanner*.startScan(null, scanSettings, scanCallback);

Matt, From what I am able to find, a remote device is unable to know the connection process has started until after the CONNECT_IND packet has already been received. At which point, the connection is already in process. This is at the BLE stack level. Now if it is possible to know this from a stack level or at the application level within the Digi firmware, that is another question that at this time, I am not able to answer. It is very possible that Digi may be using a stack that this data is not provided.

Sure. We live in hope. Perhaps Silicon Labs could answer that. Thanks for the reply.