What to keep in mind when developing your BLE Android app

BLE is native supported on Android from v4.3. It has been continuously improved as Android evolving. It's getting more and more complex with additional features. It's important that a Bluetooth app should work smoothly on all Android versions, from 4.3 to the latest one. One may find it's tricky to keep track of all the issues from earlier Android versions and the changes in BLE APIs of different API levels.

To help you with this, our app developers have provided a note, discussing about most important changes and added features on newer Android version 5 and 6, including some testings we have done on different Android phones regarding BLE performance.

Some interesting topic:

  1. Required permissions for BLE app.

  2. Scanning: different scan mode, report delay, callback type, etc

  3. Connection: autoConnect, connection parameter update, MTU, number packets per connection parameters.

  4. GATT server, advertising, how to set it up.

This document is strongly recommended to whom developing Android apps:

BLE_on_Android_v1.0.1.pdf

(Updated 05Dec2016)

Question and issue, please post as a separated case and post the link here.

Anonymous
  • Excellent! Thanks to Nordic Team. This just comeup at the right time

  • Thanks again Emil! From my side I'll just add that nRF Connect 4.11 is using connectGatt method with 4 parameters (transport set to LE) since v 4.11. I'm using reflections on Android 4.4-5.1, where this method was hidden. On 4.3 it was not accessible.

  • Hi. I found a pretty serious issue that seems to happen quite randomly but very seldom. I've tried to find the cause in Android's source code but haven't yet. I also haven't found a reliable way to reproduce it either...

    What happens is that the normal connectGatt-method with 3 parameters sometimes tries to establish a connection over Bluetooth Classic and not BLE, which of course fails (with status 133). Since Marshmallow there is a new variant of connectGatt with 4 parameters. The last parameter defines the "transport" in case the device is a dual-mode device (according to the documentation). This new parameter can be TRANSPORT_AUTO, TRANSPORT_BREDR or TRANSPORT_LE. Calling the 3-parameter connectGatt method internally uses TRANSPORT_AUTO.

    For some reason I can see in logcat that the Bluetooth stack at some point starts to print "bt_btif_config: btif_get_device_type: Device [xx:xx:xx:xx:xx:xx] type 3" when a connection is started, where 3 means dual mode. It should print 2 (LE), since the advertising flags for this device tells BR/EDR is not supported.

    Some people have wrote about it at issuetracker.google.com/.../37120498 and stackoverflow.com/.../android-could-not-connect-to-bluetooth-device-on-lollipop

    My tip is to simply always use the new connectGatt method and set TRANSPORT_LE. Then this bug doesn't happen.

    And regarding HCI snoop log,

    how do you do that on Nougat phones? I find it almost impossible to access that directory if you're not rooted.

    There is a script at android.googlesource.com/.../ which converts a bug report into a wireshark-openable file. This patch android-review.googlesource.com/ moved the snoop log. I still really don't understand why it was moved, since that makes it much more cumbersome to retrieve the log while developing.

  • As far as i know the snoop log is now available when you do "Take bug report".

  • When you say:

    check Android's Bluetooth HCI snoop log

    how do you do that on Nougat phones? I find it almost impossible to access that directory if you're not rooted.