Returning BlueZ to Android

Toward the end of 2012, Google switched the Bluetooth stack in Android—for reasons unknown, though there has always been speculation about licensing—from the GPL-licensed BlueZ to the Apache-licensed BlueDroid. That switch was for the release of Android 4.2 (one of the Jelly Bean releases). Since the switch, though, Intel and the BlueZ project have been working to restore the option of running Android with BlueZ, which provides a whole raft of additional features lacking in BlueDroid. Marcel Holtmann of the Intel Open Source Technology Center reported on the BlueZ option at the Android Builders Summit (ABS) held in San Jose, CA, April 29–May 1.

After the October 2012 Android release with BlueDroid, the initial reviews of the new stack were "not that good", Holtmann said, which is not a huge surprise for a completely new Bluetooth stack. As it turns out, based on Google's February 2014 numbers, 73% of Android devices are actually still running BlueZ because they are running earlier releases. The initial release of Google Glass ran BlueZ as well.

From the perspective of the BlueZ developers, one good thing that came out of the BlueDroid switch was the addition of a Bluetooth hardware abstraction layer (HAL). That meant that Google engineers had to think about and define what features to expose and how to expose them. In the end, Google added a Bluetooth Core HAL and a Profile HAL, he said.

BlueDroid deficiencies

When it was added, BlueDroid was said to be "tiny", but it turns out to be 286K lines of C and C++ code. There are a number of limitations to BlueDroid, Holtmann said. For example, the entire stack, which includes the Bluetooth service, HAL layers, and BlueDroid itself, all runs in a single process.

But there is much more to be concerned about with BlueDroid, according to Holtmann. He had a list of more than a dozen items that are missing or sub-par in BlueDroid. To start with, every new hardware device that will be supported needs to fork the source of BlueDroid. There is build-time configuration for the stack, including which profiles are included and what hardware features are enabled. So there is no single BlueDroid tree with support for multiple hardware platforms. The Android open source project (AOSP) only provides trees for three Nexus devices (4, 5, and 7) which are based on either Broadcom or Qualcomm hardware.

Anything more complicated than supporting the serial (UART) interface to the hardware requires that a kernel shim driver be written, which means that devices connected via USB, PCI, SPI, etc. will require drivers to be written. In addition, the bus power management is done in user space, which we have learned is "not a good idea".

BlueDroid is a lot of new code being introduced into devices, without any kind of known security audit. The Git history for the repository starts in December 2012 and has a grand total of 140 commits. Worse yet, those commits are often huge and don't have commit messages that explain what is being done or why. There is little documentation provided, essentially just the examples, and there are no unit tests.

The stack itself suffers from audio latency problems. Part of that is due to the large number of context switches required for handling every audio frame, host controller interface (HCI) packet, network packet, and other communications. The initial release of BlueDroid had no support for debugging; recompiling was required to get debugging output. Things are a bit better with the Android 4.4 (KitKat) release of BlueDroid, though, he said.

There is no Intel architecture (IA) optimization for the required SBC audio codec, nor support for other Intel-only features, which is obviously a problem for Intel and its customers, he said. The 64-bit support for BlueDroid is unclear as well. Much of it has only been compile-tested on ARM, Holtmann said.

Beyond all of that, BlueDroid is not Bluetooth-certified except for the proprietary Broadcom AirForceBT stack that also uses the Bluetooth HALs. Support for Bluetooth 4.1 is left up to the device makers; BlueDroid only provides code for Bluetooth 4.0.

Given all of that, one might ask why Google switched away from BlueZ (which doesn't have most of the problems identified), as one audience member did. Holtmann said that he has heard rumors about why the switch was made, but that he didn't want to spread them. He is, however, interested in finding out, and suggested that someone from Google should explain the choice. Google attendees were in short supply at ABS; if any were present at the talk, they didn't seem willing (or able) to answer that particular question.

Bringing BlueZ back

There are now two different ways to support BlueZ features on Android devices. The first is a port of BlueDroid to use the existing Linux kernel drivers for Bluetooth. That allows devices to use all of the existing drivers, so Bluetooth is not limited to just the UART interface, as USB, SDIO, PCMCIA (if you can still find such devices), and others are available. There is a "tiny shim layer" of around 100 lines of kernel code that the upper layers of BlueDroid talk to.

That alternative is called "BlueDroid with HCI user channel" and "it works pretty well", Holtmann said. It allows a few of the problems identified with BlueDroid to be crossed off the list (user-space power management, only a few reference devices, new drivers required, limited debugging capabilities), but most of the rest remain. Fixing those problem is the goal of the second alternative: "BlueZ for Android".

BlueZ for Android (BfA) provides a "drop-in replacement" for BlueDroid, which means that apps do not need to change. That is also true for the HCI user channel alternative since it sits below BlueDroid. The D-Bus APIs that BlueZ normally uses have been replaced by integration with the Android Bluetooth HALs. BfA brings Bluetooth 4.1 support, as well as documentation and a wide of range of tests. It supports an even dozen profiles, with the Health Device Profile (HDP) currently being worked on.

It is a low-latency stack that also supports lower-power audio. BlueZ has had 64-bit support for some time now, as well as codecs optimized for the Intel architecture. It also supports Intel's hardware advanced encryption standard (AES) processing and hardware random number generation (RDRAND instruction). The code has been used and tested in a variety of different desktop and mobile platforms over many years, including Android.

The laundry list of BlueDroid deficiencies also dropped to near zero by swapping BlueZ in. There are still too many context switches for human interface device (HID) reports and radio frequency communication (RFCOMM) streams, but the project is working on eliminating those as well. Other than that, everything on the list has been addressed.

In addition, BfA has been developed as part of the open-source BlueZ project. Its Git repository stretches back much further, with many more, well-documented commits. It is also notable that BlueZ is on its way toward switching to the LGPL. Roughly 80% of the code is already licensed that way, with more coming, though it was not clear when that job would be finished.

While it was never said in the presentation, the clear implication of Holtmann's talk was that Google made a poor choice in switching to BlueDroid. The addition of the Bluetooth HALs was good, but BlueDroid itself simply did not have the right architecture or feature set. Unless Google puts a lot of effort into BlueDroid development, it will likely fall further behind, as things like Bluetooth 4.2 are on the horizon. But it would seem that device makers already have an alternative—it will be interesting to see if (and how much) it gets used.