This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Android phone updates ble write characteristic three times

Hello, I want to develop applications for my Mac and for iOS + Android smartphone. First I created a simple Mac gatt server with apples CoreBluetooth API which has one service and one characteristic (which is write with response). First I wanted to test if everything works with the nRF Connect app. I tested it with an iPhone and an Android phone:

If I write the characteristic on the iPhone and deny it on the Mac server with insufficient authentication, it will return the error in the logs as expected.

If I write the characteristic on the Android phone and deny it, the phone sends the value two more times. Only after the second time I denied the authentication, the error appears in the logs of the phone.

So here is my question: Why sends the Android phone the write characteristic three times and receives the error only after third time denying. Is this the way Android BLE works, is this an issue of the nRF Android app or do I understand something incorrectly? Hope anybody can help me.

Thanks in advance.

  • Hi Bastian,

    nRF mobile apps inherit some behavior and limitations for the OS they are built on. And my guess here is that on Android, the native BLE stack does not give up requesting write access to the characteristic in the first go. I will request the Android app expert to confirm if this is the case. Will be back to you soon.

  • Update:

    Our expert tested this scenario and he confirmed that this is the behavior from the BLE stack of the Android OS on the phone and not coming from the nRF Connect mobile app. Not sure why Android tries 3 times after failure with insufficient auth. The retries also seems to be pretty fast not giving time for anything else to change so that the second or third might have more chance to succeed. But the quick answer is , this is not behavior from the Nordic side

  • Hello,

    Have a look at 2 screen shots:

    Here, the Android tries to write a characteristic and gets Insufficient Authentication error, which triggers automatic bonding procedure. After bonding is complete, Android automatically repeats the request and reports success to the app. This is all transparent to the app, which just just wrote the value once, and got (a bit delayed) response.

    In the second screenshot:

    Android has already been bonded to the device, but with insufficient authentication (legacy MITM, instead of LESC). Android tries to write, gets an error. Without the bond, it would initiate bonding here, but as bond already exist, it considers bonding successful, and repeats as in 1st case. This of course fails, so for some reason it repeats next time. Instead, Android should remember the security level of existing bonding and just fail the request after 1st try, like iOS does.

    Mind, that that was tested on Pixel 5 with Android 12 and other Android phones may behave differently.

Related