What is…BlueDroid?

BlueDroid

In a nutshell, “BlueDroid” is the Android Bluetooth stack implementation, used by the likes of CSR and other third-parties when they want to take advantage of Android’s native Bluetooth support. It replaced the “Blue Z” implementation (Blue Z being a separate Linux Bluetooth protocol stack).

Why is it important? Because we often take such functionality for granted, when we want – for example – to scan for devices, connect with them and maybe transfer data. In the case of Bluetooth comms, it is the default Android Bluetooth stack that will be doing this.

It enables you to:

• Scan for other Bluetooth devices (including Bluetooth Smart devices)
• Query the local Bluetooth adapter for paired Bluetooth devices
• Establish RFCOMM channels/sockets
• Connect to specified sockets on other devices
• Transfer data to and from other devices
• Communicate with Bluetooth Smart devices, such as proximity sensors, heart rate monitors or fitness devices
• Act as a GATT client or a GATT server (Bluetooth Smart)

Note – the material in this post is largely based on source.android.com information.

Android 4.2

Android 4.2 (Jelly Bean II) saw big changes to Android’s Bluetooth subsystems, with a complete rewrite of the platform’s Bluetooth stack. This was BlueDroid, and it was reportedly based on contributions from Broadcom.

Unlike rival Bluetooth stacks, such as from Texas Instruments, the Broadcom implementation was open sourced, to feed into the Android Open Source Project (AOSP). Speaking at a recent Bluetooth SIG Innovation Training day, the SIG’s Vincent Gao said there was still 95% commonality between the AOSP implementation and Google’s default Android implementation of Bluetooth.

The main difference? The AOSP version allows for the configuration of connection parameters, such as:

• max and min connection intervals, important for power efficiency in handling the radio
• slave latency
• supervision timeout

At first, support for the Bluetooth variant Low Energy wasn’t included, but this would come built-in with v4.3 (Jelly Bean III) in July 2013. Note that Bluetooth Low Energy (BLE) has since been rebranded Bluetooth Smart.

Android 4.4

Android “KitKat” supported up to seven concurrent Bluetooth connections (iOS supports six). Raw packet data was also available for inspection. Possible uses? Apparently, Beacon suppliers use the raw data to implement their own specific meta-protocol.

Android 5.0

With the announcement of the developer preview for Android “L”, at Google I/O 2014 in San Francisco, Android can additionally support BLE Peripheral Mode (which iOS already supported).

Android devices can now function in Bluetooth Low Energy (BLE) peripheral mode. Apps can use this capability to broadcast their presence to nearby devices — for example, you can now build apps that let a device to function as a pedometer or health monitor and transmit data to another BLE device.

Previously, Android 4.4 Bluetooth apps could only work in “Central” mode. Rather confusingly, Bluetooth has the concept of master and slave relationships at the link layer, central and peripheral relationships at the GAP level and client and server relationships at GATT level, all of which can be independent.

BlueDroid Layers

BlueDroid is divided into two layers:

• Bluetooth Embedded System (BTE) for implementing core Bluetooth functionality
• Bluetooth Application Layer (BTA), for communication with Android applications.

For developers, access to the various Bluetooth profiles (Alert Notification Service, Blood Pressure Profile, Phone Alert Status Profile, etc) is actually provided by a Bluetooth system service. This is packaged as an Android app and implements the Bluetooth service and profiles at the Android framework layer.

The Bluetooth system service uses both a Java Native Interface (JNI) programming framework to call into the HAL (hardware abstraction layer), and the Binder inter-process communication system to communicate with other Android apps.

Google provides a diagram (above right, click to enlarge) to show the general structure of the Bluetooth stack:

Bluetooth permissions

It may be stating the obvious, but for an app to take advantage of Bluetooth comms, and access the functionality available via BlueDroid, an application must declare its request for BLUETOOTH permission.

Note that some additional functionality, such as requesting device discovery, also requires the BLUETOOTH_ADMIN permission constant to be used by an app.

Stack customisation

Apparently, it is possible to customise the default BlueDroid stack to a certain extent.

Third-party vendors, for example, could add extra AT commands or device-specific configuration changes by creating a libbt-vendor module.

It is also possible to create another Host Controller Interface (HCI) – for example to help with debug tracing – by creating a libbt-hci module.

Finally, you can even add Custom Bluetooth profiles. There’s a whole range of pre-existing profiles to cater with common situations (see What is… a GATT Service (Bluetooth Smart)) – but if you need to add Bluetooth profiles that do not have HAL (hardware abstraction layer) interfaces provided by Android, you have to do three things:

1. supply an SDK add-on download to make the profile available to app developers
2. make the APIs available in the Bluetooth system process app (packages/apps/Bluetooth)
3. add the APIs to the BlueDroid stack (external/bluetooth/bluedroid)