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

[Paul Russell]

Today nRF Toolbox App on my Android 5.0 phone is only recognizing HRM code running on my nRF5182-mkit, not other examples.

• Today nRFToobox and nRFUART2.0 Apps both report "The Device Does not have the required services" when I try anything other than HRM code yesterday and today.

• Two days ago it was allowing me to easily switch between code on the mkit, but then something changed. It was about same time as the latest nRFToolbox update on playstore. Funnily enough it was just after the previous Nordic updates on playstore that this all started working, as two weeks ago it wasn't working with similar issue. Did a fix get undone?

• nRF-MCP App is shows changes in Device Name when I run other sample code on my mkit (Thermometer, UART Loopback, HRM, etc.)

• I tried wiping the cache in the Android 5.0 phone, no effect

• I can capture with nRF-MCP or Sniffer if that will help (just tell me what you need, I'm not very familiar with either of those)

Any help appreciated! Paul

[Aleksander Nowakowski]

Hi,

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

1. 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:

2. 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)

3. 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.

4. 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.

[Anne van Rossum]

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.)

[Aleksander Nowakowski]

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.

[Anne van Rossum]

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

[Aleksander Nowakowski]

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)

[Anne van Rossum]

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.