Bluetooth Low Energy

Bluetooth Low Energy (BLE), available in Android 4.3 and later, creates short connections between devices to transfer bursts of data. BLE remains in sleep mode when not connected. This lets BLE provide lower bandwidth and reduced power consumption compared to Classic Bluetooth. It is ideal for applications such as a heart-rate monitor or a wireless keyboard. To use BLE, devices need to have a chipset that supports BLE.

Implementation

All current BLE application profiles are based on the Generic Attribute Profile (GATT). When an Android device interacts with a BLE device, the device that sends information is the server and the device that receives information is the client. Android includes developer APIs for BLE, including APIs for interactions between GATT servers and GATT clients. To fully leverage the BLE APIs, implement the Android Bluetooth HCI Requirements.

Device modes

When using BLE, an Android device can act as a peripheral device, a central device, or both. Peripheral mode lets devices send advertisement packets. Central mode lets devices scan for advertisements. An Android device acting as both a peripheral and central device can communicate with other BLE peripheral devices while sending advertisements in peripheral mode. Devices supporting Bluetooth 4.1 and earlier can only use BLE in central mode. Older device chipsets may not support BLE peripheral mode.

BLE scanning

An Android device can target and scan for specific Bluetooth devices more efficiently when using BLE. BLE APIs let app developers create filters for finding devices with less involvement from the host controller.

Location scanning

A device's location services can use Bluetooth to detect Bluetooth beacons and provide a more accurate location. This is how users enable the feature:

  1. Go to Settings > Security & Location > Location.
  2. Check that the Location On/Off toggle is in the On position.
  3. Go to Mode.
  4. Select either High accuracy or Battery saving mode.

Individual apps need location permissions to use BLE scanning, even if they are scanning only to find devices to connect to. If the user disables location scanning, or does not give an app location permissions, then the app will not receive any BLE scanning results.

Users can disable system-level Bluetooth background scanning by going to Settings > Security & Location > Location > Scanning and disabling the toggle for Bluetooth scanning. This does not affect BLE scanning for location or local devices.

Filtering scan results

Android 6.0 and later includes BLE scanning and filter-matching on the Bluetooth controller. A device can filter scan results and report found and lost events related to BLE devices to the application processor (AP). Filtering also works for batch scans, which helps save power as BLE scanning is offloaded to the firmware. Batch scans reduce how often the AP wakes up due to BLE scanning for devices or beacons.

The OnFound/OnLost feature is implemented in the Bluetooth controller and then tested to confirm that BLE devices are not missed in scans. This provides power savings, and it can also provide the following benefits:

  • For an OnFound event, the main AP wakes up upon the discovery of a specific device.
  • For an OnLost event, the AP wakes up when a specific device cannot be found.
  • Framework apps get fewer unwanted notifications when a nearby device is in range.
  • Continuous scans enable framework apps to be notified when a device is out of range.

A scan filter can be based on the discovery of a device's advertisements (the OnFound event). The Java layer can specify parameters such as first discovery (or a specified number of advertisements since first discovery). Implement BLE filtering using the Advertising Packet Content Filter HCI command.