nRFToobox on Android not recognizing changes in application type running on Nordic pcb

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Anne van Rossum — Tue, 10 Jan 2017 10:11:34 GMT

Yes, this is the case for the Samsung S5 (running Android 6.0.1). This is also the case for for example the Wiko Lenny 2 (Android 5.1, a very cheap device).

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Aleksander Nowakowski — Tue, 10 Jan 2017 09:58:49 GMT

Interesting finding, I thought all Android devices just cache everything always. So you say Samsung doesn't cache services of untrusted devices... I'll need to look into it.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Anne van Rossum — Mon, 09 Jan 2017 14:26:03 GMT

Exactly. That's not the behavior I observe. On a Samsung S5 the cache will be refreshed even if there is no Service Changed characteristic present. Hence, there is no reliable way across smartphone-manufacturers to have low-latency connections to untrusted devices. There might or might not be a physical discovery process.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Aleksander Nowakowski — Mon, 09 Jan 2017 11:48:07 GMT

Then the device is not allowed to change it's database (services/characteristics/descriptors) at any time. Central device may use cache and may never clean it. Spec 4.2 says: Note: Clients without a trusted relationship must perform service discovery on each connection if the server supports the Service Changed characteristic. (Vol 3, Part G, 2.5.2)

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Anne van Rossum — Mon, 09 Jan 2017 11:21:26 GMT

What should the behavior be for untrusted devices when the Service Changed characteristic is absent?

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Aleksander Nowakowski — Sun, 08 Jan 2017 17:54:21 GMT

Since some version ago nRF Connect doesn't refresh cache automatically for devices running Android 6+. There this option there is gone in the settings. You may however do it manually by menu->Refresh cache after you are connected. The BLE spec clearly states when the cache should be used. For untrusted devices should never be used if Service Changed characteristic is present, like iOS does. Google knows is and works on a solution, but until then, and for all versions before the fix, refreshing using reflections seems to be the only solution.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Anne van Rossum — Sun, 08 Jan 2017 15:44:03 GMT

I don't think the "refresh never" option is available anymore. In our own application with untrusted devices we see the cache being used. In the nRF connect app we see that there is a 1.5 second discovery process run any time we connect to an untrusted device. The latter is according to the Bluetooth specification, but not according to the default behavior represented in code.google.com/.../detail. Only for example Samsung devices invalidate the cache for untrusted devices. (Personally wish: it would have been great from the Specification designers to have left the decision of using cache yes/no to the application developer.)

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Petter Myhre — Tue, 16 Dec 2014 15:27:06 GMT

Np :) For example in ble_app_hrs in SDK 6.1.0 it is in main.c on line 54. You can also search for it, CTRL+F->Find in Files tab.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Paul Russell — Tue, 16 Dec 2014 15:15:04 GMT

I'm sorry but still new to this...

Exactly where in an example would I add/change: IS_SRVC_CHANGED_CHARACT_PRESENT 1?

I searched through SDK6.1 examples but couldn't ind this.

I can't download SDK7 examples as my Nordic demos are older nRF51822-DK and nRF51822-EK whick only go to SDK6.1 on downloads.

Most of my nRF work is in mbed, that is where I really would like to try this.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Petter Myhre — Tue, 16 Dec 2014 14:19:55 GMT

I have been able to reproduce this on Android 4.4.4, and did some investigating.

This is actually a Android bug, not a nRF Toolbox/nRF Master Control Panel bug.

On Android 4.3 the cache was cleared if you restarted Bluetooth, but this does not happen in 4.4 (and 5). I think this modification was on purpose.

Attribute catching is explained in Vol 3, Part G, Section 2.5.2 in the Bluetooth Core Specification 4.2.

If GATT based services on the server cannot be changed during the usable lifetime of the device, the Service Changed characteristic shall not exist on the server and the client does not need to ever perform service discovery after the initial service discovery for that server.

This means that if the Service Changed characteristic doesn't exist, Android can cache the attributes.

For clients that have a trusted relationship (i.e. bond) with the server, the attribute cache is valid across connections. For clients with a trusted relationship and not in a connection when a service change occurs, the server shall send an indication when the client reconnects to the server.

This means that if the devices are bonded Android can cache the attributes.

For clients that do not have a trusted relationship with the server, the attribute cache is valid only during the connection. Clients without a trusted relationship shall receive an indication when the service change occurs only during the current connection.

This means that if the devices are not bonded, Android can cache the attributes, but they must be cleared between every connection. Android do not do this.

When you disconnect from Master Control Panel the cache is manually cleared. But this is not done in nRF Toolbox.

This should only be a problem in development because the DFU procedure also manually clears the cache.

The workaround is to do a disconnect in Master Control Panel if you change apps.

The service changed characteristic is included in the SDK examples by setting IS_SRVC_CHANGED_CHARACT_PRESENT to 1.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Aleksander Nowakowski — Tue, 16 Dec 2014 13:56:48 GMT

Hi,

There are 4 ways to clear the attribute cache on Android:

Using Service Changed characteristic - the proper solution:

a) when not bonded - android should never cache services if such characteristic is present in Generic Attribute service. However it always does - this is the Android bug, reported here: code.google.com/.../detail

b) when bonded - a device may enable CCCD indications on Service Changed char. Whenever Android receives this indication it will perform service rediscovery automatically. When writing Android code make sure that you give ~2 sec after you get onConnectionStateChange(Connected) event before calling gatt.discoverServices() when you expect that the indication may be received. If you call it immediately, inside the onConnStateCh callback, you'll get old services as this callback is called immediately when you connect but before the bond has been re-established and the indication was sent.

When you don't use bonding or you don't want to use Service Changed indications, or when you are flashing your board with different firmwares you may find useful this:

Using Android hack - there is a hidden method refresh() on the Android API. It works since Android 4.3 but it may be removed in any new release. I'm calling it when you disconnect from the DFU in nRF Toolbox and whenever you disconnect from the device in MCP. In the upcomming version MCP 2.1 (release tomorrow(?)) there will be an option to change in MCP settings (connectivity): refresh always (after disconnection), refresh only when not bonded (also only after diconnnecting), refresh never (actually it will refresh when an error occur)
Use different device address when services are different. When you design a firmware that has different modes with different services consider using different device address in every of them. In that case the cache will not be a problem.
On older versions of Android (f.e. 4.3) restarting Bluetooth adapter was also clearing the cache. As we can observe now this no longer works which is OK (cache shouldn't be cleared unless services are changed). This no longer works.

So.. if you want to use different firmware on the same device use the trick with the nRF MCP. As I've written before it refreshes the cache every time it disconnects from the device. If you check the log on DEBUG level you will see the gatt.refresh() method being called.

RE: nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Paul Russell — Wed, 10 Dec 2014 15:12:52 GMT

Possibly:

If not properly disconnect then App data in Android may be confused.
This may be a bug in latest nRF-MCP/nRF-ToolBox for Android (Released ~20141209?)

Try:

Open nRF-MCP in Android, select device, connect, disconnect (Ensure disconnect happens)

Note:

UART device doesn't seem to offer disconnect (nRF51 sample code may need tweak)
May need to load a 3rd sample, disconnect from that, then try new sample.

Still testing. This method of using nRF-MCP to disconnect between sample type changes (HTM, HTM, UART) does appear to be working, consider it a "work around" for now.