Android Lollipop: Bluetooth LE Matures

Android Lollipop: Bluetooth LE Matures


In my last video tutorial on Bluetooth LE, we talked about some of the basics that came along with the introduction of this technology to the Android 4.3 APIs. With the release of Android 5.0 late last year, big changes have come to the Bluetooth LE landscape.

In this session, recorded at AnDevCon San Francisco, we see what has changed in the 5.0 release of Android.

A Rocky Start

One of the biggest complaints about the Android Bluetooth LE APIs is that they are unstable and oftentimes they don't support many of the standard communication types. What you may not realize is the underpinning reason for this started with the Android 4.2 release. You see, in early revisions of Android the entire Bluetooth stack was built upon BlueZ, the open source stack used in the Linux kernel. This stack is very mature and stable.

However, in the Android environment BlueZ came with a lot of baggage--the most notable of which is the GPL license that is attached to it. To avoid conflicts with the rest of the Apache-licensed Android stack, BlueZ was required to run in a separate process that interacted with a special daemon (bluetoothd) so it was properly isolated. In addition, BlueZ required an implementation of D-Bus (via dbus-daemon) to be in place for IPC, something Android doesn't otherwise implement. This was a lot of overhead to incur to work around a license problem.

To sidestep all this, in Android 4.2 Google replaced BlueZ in Android with Bluedroid, a completely new stack developed by Broadcom that was licensed under Apache to be more compatible with the rest of the stack. Without going into the major details of the differences between the two, I simply want to reiterate one thing…Bluedroid is a completely new stack, essentially untested in the wild. It has taken some time to bring the level of stability and maturity that Android had before.

…and all this happened just before Bluetooth LE came to the platform APIs.

New Features

Bluedroid continues to mature and stabilize; there were 565 commits to the bluedroid project alone from 4.4 -> 5.0, compared with 52 commits from 4.3 -> 4.4, and 47 commits from 4.2 -> 4.3 [1]. This is an area of heavy activity within AOSP right now.

Along with bug fixes, Google introduced support for LE Peripheral and Broadcaster modes in applications. This comes along with new support for sending LE advertisements. Not all devices will support this new feature with the update, as Google has defined this as a HAL-enabled feature, which means manufacturer's must add a driver for it at the integration level. Developers should first check BluetoothAdapter.isMultipleAdvertisementSupported() on the device.

The APIs for scanning have also been improved. We now have proper builder classes for building scan requests (ScanSettings + ScanFilter) and analyzing scan results (ScanResultScanRecord)…no more parsing byte arrays manually! ScanFilter introduces a more robust filtering API which can filter on any scan parameter instead of just the advertised service UUIDs.

Better Performance

Along with these APIs, improvements have been made to reduce the effect of scanning on the device's battery. Scanning on Android 4.x was an operation that forced the device to stay awake (using a full wake lock), so scanning in the background was pretty much a non-starter. In Android 5.0, new low power settings for your scan allow an application to scan continuously in the background without undue battery drain.

Through use of the new filtering API, you can further reduce device wakeups by limiting the advertisements that get pushed up to the application layer. Scan results can also be batched and delivered in groups when a delay value is set on ScanSettings--again, reducing device wakeups if scanning in the background.

Some of these features (portions of filtering, and scan results batching) are also implemented at the HAL level, so some devices may not be able to take full advantage if the manufacturer didn't provide the driver support. The BluetoothAdapter.isOffloadedFilteringSupported() and BluetoothAdapter.isOffloadedScanBatchingSupported() APIs allow you to determine how power-efficient the device can be with your scan requests.

You can find the sample code demonstrated in the session video on GitHub.



  1. Commit stats determined from

If you're interested in learning more about Android, check out our Android Trainings or sign-up for my upcoming Android Bootcamp course starting April 20th in San Francisco.

About the Author

If you liked this post you'll probably be interested in these:



Alex Sneed Miller | Target
Posted on Mar 21, 2017 (3 days ago)

Is there a way to discover Services by UUID in Android? I only see a way to discover all of the Services, which is a lot slower.

Vitor Sa | CIn
Posted on May 02, 2016 (11 months ago)

Im doing an app that requires real time triangulation and location of an smartphone inside an environment full of BLE scanner devices that can track the smartphone and know the real position. The problem that I'm facing is that the BLE API in Android only supports pre-determined advertisement power and latency, but I need to advertise faster and with Higher power. Anyone has any idea how I can change that?

Tosa Montezuma | Self
Posted on Sep 09, 2015 (2 years ago)

Can a single APK be made that works on 4.4.2+, using the 5.0 API when possible? The code ( shows that there are two files, one for KitKat and one for Lollipop and a boolean flag (in values and values-21) is used to choose between the two for compilation. Does this make two separate APKs?

Dave Smith | NewCircle, Inc.
Posted on Apr 24, 2015 (2 years ago)

Tomek - Yes, a GATT server on an Android device can service multiple connections. It is my understanding (though untested) that the device can support up to 7.

Tomek Ciesielczyk | PUT
Posted on Apr 22, 2015 (2 years ago)

Can multiple devices connect concurrently to a smartphone working in the peripheral mode ?

Dave Smith | NewCircle, Inc.
Posted on Apr 14, 2015 (2 years ago)

JM - Yes, the restriction is whether each device manufacturer has implemented the appropriate drivers underneath 5.0 to support advertisement…not all 5.0+ devices will support the feature. Devices that don't support advertisement (as I mentioned in the video) cannot act as peripherals.

JM Tan | None
Posted on Apr 14, 2015 (2 years ago)

Few more things to clarify, as mentioned above, not all devices will support the new feature of LE advertisement. 1. Does this imply that the only restriction is the device's firmware? 2. Am I correct to say that only the devices that are able to support beacon transmission with 5.0 APIs will be able to implement the HID peripheral application? I found the list of Android device builds that are able to transmit as beacons from: Really thanks a lot for the quick reply! :)

Dave Smith | NewCircle, Inc.
Posted on Apr 13, 2015 (2 years ago)

JM - The framework simply provides the GATT layer functionality to applications, so the application is able to implement any GATT profile on top of that functionality. There are no restrictions in the 5.0 APIs that would preclude you from implementing the HOGP services/characteristics inside a peripheral application.

JM Tan | None
Posted on Apr 13, 2015 (2 years ago)

Great explanation indeed! Just wanted to know, with the added support for LE Peripheral and Broadcaster modes in applications, does it mean that it is possible to implement HOGP device role with certain Android devices (nexus 6/9) now? I am actually trying to implement an app which requires the android phone to act as a HID device (keyboard/mouse), preferably without needing to root the device in order to get it work. And as far as I know, Android 4.4 does support HOGP host role, but I am not too sure about the support for device role.

Jakub Wiszowaty | Home
Posted on Feb 20, 2015 (2 years ago)

Anyone had similar problem with BLE? Thanks for your help in advance!