Today I'd like to talk about the Bluetooth Low Energy (or LE) APIs now available in the Android framework, and show you how easy it is to add some really interesting capabilities to mobile applications using this technology. Bluetooth LE was introduced to the core Android framework in 4.3, or API Level 18. Prior to this, there were several OEM-specific SDKs providing this behavior, but we will not be going into detail on those here.
Bluetooth Low Energy, or Bluetooth Smart, is a part of the Bluetooth v4.0 specification aimed at providing a fast and low-power method of communicating with wireless sensors and peripherals.
There are four primary roles that a device can fulfill in the Bluetooth LE paradigm:
We are going to look at two examples today; first with the Android application acting in the Central role to communicate with a Peripheral device, and second with the Android device acting in an Observer role monitoring data advertisements from several Broadcaster devices.
Bluetooth LE is primarily built around the Generic Attribute profile, or GATT, as it is often called. This profile defines a structured approach to how peripherals expose data to other devices. Peripheral information is organized as a collection of Services that describe logical functions of the device. A specific sensor or feature (such as thermometer or heart rate monitor) would have its own service. Each Service includes a collection of Characteristics to transfer discrete data values between devices. A Characteristic can represent service data (such as the current value of the heart rate) or configuration data (such as whether this peripheral should notify anyone when its value changes).
Characteristics are minimally made up of property flags and a value. The flags describe information about a characteristic's capabilities; such as whether it is readable, writeable, or supports notification. Additionally, they may contain one or more descriptor elements to indicate the value's type and perhaps provide additional configuration that is specific to the given characteristics. If this sounds like a lot of layers to try and follow, fear not. When you see them all put together in a real-world example each of their roles should become clear.
The Bluetooth Special Interest Group does define many standard collections of common services into profiles that commercial devices can implement, in an effort to foster interoperability between communicating devices. For Bluetooth LE, examples of this would include the Heart Rate Profile, Proximity Profile, or the Time Profile. When interacting with a device that claims to implement a certain profile, developers can expect that a certain collection of service and characteristics exist on that device.
However, unlike with many classic Bluetooth profiles, the Android APIs for GATT devices do not currently provide profile-level abstractions. In order to communicate effectively with a Bluetooth LE device from Android, you must determine ahead of time the services and characteristics that you expect on the target remote device. The APIs will then allow you to scan for those specific services, then directly read and write the characteristics that are of interest.
It is also important to note that, at this stage, Android does not support creating an application that will cause the device to act in the Peripheral, or GATT server, role. It is only able to scan for, and connect to, other Peripheral devices.
In our first demo, we have the CC2541 SensorTag from Texas Instruments. This is a device that implements a GATT server in order to provide data from each of its six sensors (temperature, humidity, pressure, accelerometer, gyroscope, and magnetometer). Each sensor is defined by its own service, and each service contains a characteristic to read the given sensor value. Most of the sensor services also contain a characteristic or two for configuring or enabling the sensor data updates.
One really cool feature of Bluetooth LE is this role of a Broadcaster, or a device that does not accept incoming connections, but rather pushes out the data is has inside its device discovery, or advertisement, data. In the previous example, we had to make a connection to the remote device once the scan was complete in order to read and write characteristic data. We then had to go through the process of iterating over all the characteristics we needed to touch in getting the updates set up initially. This takes time, and in an application where devices may just be passing by, we want something simpler.
With a Broadcaster, data is placed directly into the advertisement packets. As an Observer application we can read everything we need from the devices during the LE scanning process without ever making a connection. Each advertisement contains a collection of advertisement data structures, each containing a length, type, and payload. The structure type identifiers are defined by the Bluetooth Special Interest group in the Generic Access Profile, and include elements like control flags, device name, service UUIDs, service data, and transmit power level (which is useful for determining proximity).
There is another significant benefit of Broadcaster applications to the accessory developers. The Bluetooth stack required to implement advertisements only without accepting connections is significantly simpler; which generally lowers both development effort and cost.
In our next demo, we have three connection-less temperature beacons from KS Technologies; a company dedicated to helping developers create some really amazing Bluetooth LE solutions. The beacon tags all contain a temperature sensor, and the value of the current temperature is broadcast as service data inside their advertisement packet. This drastically reduces the code we have to write.
If you're looking to learn more about Android development, check out my upcoming Android Internals training course at ProTech. Save 20% with coupon code: SMART