Bluetooth Low Energy Audio

Bluetooth Low Energy Audio (LEA) ensures that users can receive high fidelity audio without sacrificing battery life, and lets them seamlessly switch between different use cases. Android 13 (API level 33) includes built-in support for LEA.

Most LEA headsets will be dual mode until the LEA source device market share grows. Users should be able to pair and set up both transports on their dual mode headsets.

Use cases

You may want to integrate LEA for the following use cases:

  • Sharing audio: Users can simultaneously share multiple audio streams to one or more audio sink devices. Audio is synchronized between the source device and connected devices.

  • Broadcast Audio: Users can broadcast audio to friends and family, while also connecting to public broadcasts for information, entertainment, or accessibility.

  • LC3 audio codec support: This is the default audio codec and replaces the SBC codec used for A2DP (media) and mSBC in HFP (voice). LC3 is more efficient, reconfigurable, and higher quality.

  • Audio sampling improvements: Headsets can maintain high output audio quality when using microphones. Bluetooth classic lowers audio quality when using Bluetooth microphones. With BLE Audio, input and output sampling can reach 32 kHz.

  • Stereo microphone: Hearables can record audio with stereo microphones for spatial audio enhancements.

  • Hearing Aid Profile (HAP) support: HAP offers users greater accessibility and usage than previous ASHA protocols. Users can use their hearing aids for phone calls and VoIP applications.

  • Enhanced Attribute protocol (EATT) support: EATT allows developers to send multiple commands at once to paired hearables.

Key scenarios

There are four main categories of use cases:

  1. Conversational: Dialer and VoIP applications that require low-latency communication routing offer high quality audio and less battery usage.

  2. Gaming: Concurrent microphone and high fidelity playback allows for games to stream high quality audio to hearables. A gaming app can access BLE audio input when a game arms the Bluetooth microphone as ready to use. Then, when a player starts a live conversation with a peer player, the game app can use the microphone data without delay.

  3. Media: Media applications are allowed to set the audio manager's preferred device. The user can override this by changing their preferred device from within the system's settings.

  4. Accessibility: Hearing aids that support BLE Audio can now use the microphone, allowing users to continually use their hearing aids for a call.

BLE Audio APIs and methods

The following APIs and methods are required to support BLE Audio hearables:


  • setCommunicationDevice() selects the audio device that should be used for communication use cases, for instance voice or video calls. This method can be used by voice or video chat applications to select a different audio device other than the one selected by default by the platform. This API replaces the following deprecated APIs: startBluetoothSco(), stopBluetoothSco(), and setSpeakerphoneOn().
  • clearCommunicationDevice is called after your app finishes a call or session to help ensure the user has a great experience when moving between different applications.


Telecom InCall Service

Audio Device Info

Audio Recorder

  • setPreferredDevice() sets the preferred device for audio routing to use. The user can override this in the system settings.

Bluetooth Adapter

Guides based on use case

Below are guidelines for implementing LEA based on specific use cases.

Voice communication applications

Voice communication applications have the choice of managing audio routing and device state by self managing their state or by using the Telecom API which does the audio routing and state logic for you.

Audio recording applications

  • Media Recorder: When recording audio using the Media Recorder, you can now record in stereo if the bluetooth hearable supports LEA. Check out the Audio recording guide.

LE Audio (LEA) headset recommendations

As more LEA headsets are released, we have discovered issues in real-world testing that degrade the user experience. The specification does not cover all of these issues. The following table provides a list of recommendations that LEA headset manufacturers should follow to improve end-to-end experience for Android users.

Description Context
Support Cross Transport Key Derivation (CTKD) for dual-mode headsets:
  • Support key derivation for both Classic-to-LE pairing and LE-to-Classic pairing.
Most new LEA headsets will be dual-mode until the LEA source device market share grows. It's important that users are able to pair their dual-mode headsets seamlessly and to set up both transports. This is also important for Google Fast Pair.

Support Targeted Announcements (TAs) if you want your LEA headsets to reliably reconnect to the source devices.

LE audio earbuds should use TAs to request an incoming connection from the central devices.

Will be added to upcoming BT SIG.

Unlike in BR/EDR's paging model where a connection can be initiated by either the phone or the headset, a connection in LEA must be initiated by the central device. Currently, many headsets do not use TAs, which means that the central device might not be able to reconnect to the peripheral without adding it to an Allowlist. However, an allowlist workaroud might prevent the headset from connecting to a different central device. Therefore, it's important for LEA headsets to support TAs properly so that the central device can reliably reconnect without workarounds that might break multi-point connections.
Optimized discoverability for dual mode earbuds
  • Primary earbud - BR/EDR component should advertise using its public address and enable inquiry and page scan with its name available through EIR, and set LE audio bit 14 to 1 in the Major Service Classes of Class of Device (CoD).
  • Primary earbud - LE component: The primary earbud should perform a Connectable and Discoverable (either Limited or General) advertisement using the same Public Address as the BR/EDR Component, and the same Complete Local Name as the BR/EDR component, with its Appearance Category set as an appropriate Appearance Category that matches the remote device type with the expectation that the central device will use this information to adjust its UI and audio routing policies.
  • Secondary Earbud - LE only: The secondary earbud should perform a Connectable, Non-Discoverable advertisement with its Appearance Category set as an appropriate Appearance Category that matches the remote device type with the expectation that the central device will use this information to adjust its UI and audio routing policies

    The earbuds should dynamically elect a leader from the CSIP group to be the primary device. If the earbud is dual mode, the primary device must be dual mode to ensure that both LE and Classic functionalities work correctly after pairing.

This prevents dual-mode LEA earbuds from appearing as duplicate entries in Bluetooth settings, which might confuse users and compromise the LEA pairing experience.

The dynamic leader election is especially important for dual-mode devices that are paired incrementally. For example, if only one earbud is available at initial pairing, then it should present itself as a dual-mode device. When a user pairs with the second earbud later on, they only need to pair with the LE component, and CSIP will make sure they are grouped together on Android.

Identity address is recommended during pairing because the BR/EDR component already exposes the device's public address to nearby devices.

Support Enhanced Attribute Protocol (EATT). Reduces pairing and connection latency.
Support Robust GATT caching. Reduces connection latency, especially for TWS buds.
Support connection subrating. Allows for more flexible packet scheduling and potential battery savings.
Ensure that during pre- and post-processing for both playback and capture, the signal processing pipeline can operate at 16, 24, 32, and 48 kHz as well as supporting higher frequencies. Takes advantage of the higher sampling rates supported for LEA call or VoIP capture paths and media playback.
Support LE Power Control Better power management

Context Type support

Description Context
Use all of the context types specified in Assigned Numbers 6.12.3 unless the headset explicitly does not support a given context type. For example, if context type "Game" is not supported, then Android will send game sounds. In particular, note that the "Unspecified" context type doesn't mean "any context type", and it doesn't cover unsupported context types.

When the central device interacts with the peripheral device's ASCS, the peripheral must connect to the central device's MCS and TBS.

The central device might not always use LE audio as the streaming route because it might fall back to using A2DP or HFP. The peripheral device can use ASCS interaction as an indication of whether the central device will use LE audio for streaming.

A few examples of ASCS interactions are read, write, and register for notification.