Recommended
Related

What to keep in mind when developing your BLE Android app

Hung Bui

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.

Parents

  • Why do you think public addresses are super rare? Just because Nordic's softdevice defaults to a static random address doesn't mean other stacks do the same ;)

    I just assumed, that if you produce thousands of devices it is much easier to use random addresses then register them. But in fact i have no idea. Maybe for central devices it is better to ensure uniqueness, also don't know.

    And the simple answer to the Google employee's question "how could someone have a random address without scanning?" is simply that for example a static random address may definitely be known beforehand.

    Of course there are a lot of options, like simply saving it in the app from last connection. But from the stack perspective, after resetting Bluetooth, is a new, unknown one. The solution should be to add the address type flag, not assume anything. But for now, until it's fixed, something has to be decided or calculated heuristicaly.

    Very interesting finding about the random address and autoConnect. I'll take a deeper look on Monday. Have a pleasant weekend and thanks again. I feel sorry for those who will read this ;)

Comment

  • Why do you think public addresses are super rare? Just because Nordic's softdevice defaults to a static random address doesn't mean other stacks do the same ;)

    I just assumed, that if you produce thousands of devices it is much easier to use random addresses then register them. But in fact i have no idea. Maybe for central devices it is better to ensure uniqueness, also don't know.

    And the simple answer to the Google employee's question "how could someone have a random address without scanning?" is simply that for example a static random address may definitely be known beforehand.

    Of course there are a lot of options, like simply saving it in the app from last connection. But from the stack perspective, after resetting Bluetooth, is a new, unknown one. The solution should be to add the address type flag, not assume anything. But for now, until it's fixed, something has to be decided or calculated heuristicaly.

    Very interesting finding about the random address and autoConnect. I'll take a deeper look on Monday. Have a pleasant weekend and thanks again. I feel sorry for those who will read this ;)

Children
No Data