The 5.0 BlueZ

The BlueZ project, which provides the official Bluetooth support for Linux, unveiled version 5.0 on December 24, with the new major version number signifying changes in the API — changes found in several places in the Bluetooth stack. Only relatively recent kernels are supported due to reliance on some new kernel interfaces, several multimedia modules have been moved out to GStreamer or into separate projects, and there are new tools and supported profiles. The most significant changes are in the D-Bus API, however. Most (if not all) BlueZ applications will require a bit of porting, but the new interfaces should reduce work in the long run.

Interfaces

Linux 3.4 introduced a new Bluetooth Management kernel interface for interacting with Bluetooth adapters. BlueZ 5.0 now uses the new interface to manage local hardware. The new interface allows the kernel to manage all Host Controller Interface (HCI) traffic, as opposed to the 4.x stack's approach, with the kernel splitting that duty with user-space processes hooking into raw HCI sockets — and all of the synchronization and security problems that followed.

However, a recurring complication in the Bluetooth world is the standard's revisions and extensions. In particular, Bluetooth 4.0 added the Low Energy (LE) protocol designed to work with sensors and other Bluetooth devices capable of running off of small, "coin cell" batteries. Not only is the protocol different, but new adapter hardware is required on the host side as well. Support for Bluetooth LE adapters was not introduced until kernel 3.5; BlueZ 5.0 supports Bluetooth LE functionality only for this and subsequent kernels.

In user space, the most visible changes to working with BlueZ come from the D-Bus API. Version 5.0 has been rewritten to transform a number of previously custom interfaces into their standard D-Bus equivalents. For example, the BlueZ 4.x series provided its own methods for retrieving and setting an object's properties (GetProperties and SetProperty), and the PropertyChanged event to monitor an object for changes. In BlueZ 5.0, the standard D-Bus Properties interface is used instead.

Similarly, the generic D-Bus ObjectManager interface replaces BlueZ 4.x's custom interfaces for the tasks of adding, removing, and managing objects on the BlueZ D-Bus service. For the most part, this migration is simply the removal of duplicate, BlueZ-only methods from the code, however there are some significant changes as well. BlueZ 4.x had a org.bluez.Manager interface that enabled applications to find the attached Bluetooth adapters. BlueZ 5.0 has no equivalent interface, because D-Bus's generic ObjectManager provides an ObjectManager.GetManagedObjects method. This method returns every managed object in the BlueZ service, but, as the BlueZ 5.0 porting guide explains, applications need only scan through the returned objects to find an org.bluez.Adapter1 instance.

The "1" appended to org.bluez.Adapter1 is another change debuting in BlueZ 5.0; it is the version number of the new Adapter interface. All of BlueZ's interfaces now have a version number attached, with the project committing to supporting the two most recent versions of each interface. Unfortunately, this backward-compatibility pledge does not apply retroactively; the BlueZ 4.x interfaces — and their predecessors — have been dropped.

Devices and profiles

The changes outlined above all concern interacting with the locally-attached Bluetooth host adapter. But, as much fun as that is, a single Bluetooth dongle is not particularly useful on its own — users will eventually want to pair or connect to other Bluetooth devices.

BlueZ 5.0 introduces new methods for discovering and connecting to Bluetooth devices, again retiring a number of custom methods in favor of simpler, more general D-Bus APIs. For example, the CreateDevice and CreatePairedDevice methods were used to explicitly instantiate devices in BlueZ 4.x, but they have been removed entirely. Instead, the ObjectManager automatically creates org.bluez.Device1 objects for each device discovered during a scan, and automatically removes unused objects every few minutes.

There is also a new general-purpose Device1.Connect method that applications can call to connect to a discovered device without knowing in advance which Bluetooth profiles the device supports. This simplifies the process considerably, particularly when dealing with devices that support multiple profiles (such as audio devices, which for example could serve as hands-free phone accessories or music headsets).

API changes are not all that the update provides, however. The new release adds support for five new profiles, all of them of the Bluetooth 4.0 LE variety. Cycling speedometers and heart-rate monitors are the newly-supported hardware device profiles, and new functional profiles support Bluetooth LE's alert-notification, scan-parameter, and HID-over-GATT services. The alert notification and scan parameter profiles are precisely what one would guess given a few minutes to brainstorm; the first is a framework for sending alert messages of various types (such as "new message" alerts sent from a computer to a Bluetooth watch), and the second is a framework for servers and wireless sensors to agree on connection and timing settings, which are important for Bluetooth LE's advertised power savings. The HID-over-GATT profile is a way for low-energy devices to serve as human interface devices (HIDs) over Bluetooth LE's Generic Attribute (GATT) profile.

With these additions, BlueZ's supported profiles number more than 25 (the list at the project's site is out of date at the moment, but a more complete list is found in the Bluez git repository). The math can get a little fuzzy because some profiles are layered on top of other profiles, and it may make more sense to implement the higher-level profiles in other applications. For example, a 2011 Google Summer of Code project implemented the Phonebook Access Profile (PBAP) — which runs on top of the generic object exchange (OBEX) profile — in Evolution Data Server. BlueZ 5.0 pushes a few more profiles out of the BlueZ project itself; audio-video elements implementing the A2DP and AVRCP profiles were pushed upstream to GStreamer, and the telephony profiles HFP and HSP were dropped in favor of the external implementations in oFono.

Both the GStreamer and oFono profiles implement BlueZ's new org.bluez.Profile1 interface, which is designed for connecting to external processes that implement a Bluetooth profile. The interface expects some basic information common to all profiles, such as authentication behavior and service discovery protocol (SDP) records, but implementing the rest of the profile's behavior is up to the application. It is not clear how many external profile projects one could reasonably expect to appear, but BlueZ does still have a handful of unimplemented profiles to choose from (such as the blood pressure monitor profile BLP). Furthermore, it is certainly likely that the Bluetooth Special Interest Group (SIG) will come up with more profiles as Bluetooth LE continues to grow in popularity.

The BlueZ project did a bit of refactoring in this release as well, moving its implementation of the Sub-band codec (SBC) into a standalone project, and adding some new tools for testing and monitoring Bluetooth functionality.

For end users, BlueZ 5.0's immediate gains are the LE protocol support and the new profiles. These will enable users to pair and use the latest generation of Bluetooth devices — at least, until the next revision of the Bluetooth specification is turned loose. For application developers, the simplified APIs are no doubt welcome news (particularly removing custom interfaces in favor of standardized D-Bus alternatives).

This is especially helpful when it comes to implementing new device profiles not yet supported by BlueZ itself — because Bluetooth products vary so much and new ones are constantly popping up without warning. One might well argue that Bluetooth's design makes life easier from a hardware maker's perspective by cramming as much intelligence into the protocol and the software stack as possible; Bluetooth devices are cheap, plentiful, and widely interoperable as a result. But the downside is increased complexity required of the operating system and application developer. BlueZ 5.0 manages to simplify things for Linux, which is a significant accomplishment — hopefully one that will bear fruit in the coming months.