Android Secure DFU and bonds

[BrianK]

We've been having issues getting DFU to complete consistently with Android devices when using a two-step DFU package (BL+SD and App). Some devices seem to have far less trouble than others. The newer Samsung devices tend to work pretty reliably for us, but Pixel devices are particularly bad.

We initate DFU through the DfuServiceInitiator and setKeepBond(true) and are using the SecureDfu implementation.

On all devices we tend to see pretty regular errors: DEVICE DISCONNECTED, GATT INVALID HANDLE, GATT WRITE NOT PERMIT. Often, retrying a couple of times will fix the problem but on the Pixel devices the GATT WRITE NOT PERMIT does not resolve itself. The only way we've been able to successfully fix it is to call the BluetoothDevice.removeBond() function via reflection.

After removing the bond we can pretty consistently initate the DFU of the bootloader. As the device switches from bootloader over to app we often start seeing the GATT WRITE NOT PERMIT errors again. If we removeBonds again

then we are able to successfully complete the DFU.

We also tried forcing a BluetoothGatt.refresh() (through reflection) to see if that resolved the issue but we didn't see any improved behavior. The only thing that lets us successfully DFU is removeBond().

How can we avoid removing the bonds every time we DFU?

We are using DFU library 1.7, and the issue happened with 1.6 as well. We notice that the latest nRF Connect app seems much more stable (often completes with clean logs), is it based on a newer library?

On the firmware side, we see this issue with SDK14 and SDK15, secure buttonless bootloader, with supports-bonds in app, and requires-bonds in bootloader.

Thanks,

Brian

[Hung Bui]

Hi Brian, 

You would need to capture the bonding process (from before bonding to after bonding) so that the sniffer gets the key. 

From the log I can see that the app tried request a service discovery but we don't know if the phone actually did a service discovery or not. The sniffer trace would reveal this. 

From your log, I can see that the app was trying to write to a descriptor (that it thought was a characteristic) and the phone replied with GATT WRITE NOT PERMIT. It's most likely the attributable issue. 

One solution you can think of is to match the bootloader attribute table with your application attribute table (or at least put the DFU services to the top of your application, you still need the DFU buttonless service in addition). So that when you switch between bootloader and application there isn't any different. Then no new service discovery needed. 

[BrianK]

Hi Hung Bui,

After moving the DFU service to the top of the application we're seeing more stable DFU behavior with Android. Thanks for the suggestion. We will test with a number of devices to verify that this is a solution.

We have not tried duplicating the GATT table in the bootloader. We are resistant to that since it seems like more of a workaround for an incorrect central implementation than we'd like to use.

[Hung Bui]

Good to hear Brian.

And you are right, if the central react to service changed indication properly, we wouldn't have to do that. But you never know, especially on Android, many vendors have pretty poor stack implemented.