This page explains how to implement the audio Hardware Abstraction Layer
(HAL), provides details about configuring an audio policy (file formats, code
organization, preprocessing effects), and describes how to configure the shared
library (creating the
Audio HAL capabilities
The Android 10 release includes the following new capabilities for audio HAL:
HE V1, and
Declare these HAL capabilities in
audio_policy_configuration.xml, so the framework
can use them.
Audio HAL and subsystem requirements
The Android 10 release includes the following requirements for audio HAL and subsystem implementation:
- If separate input stream profiles are declared in
audio_policy_configuration.xml, it must be possible to activate them all simultaneously for any device selection.
- If capture for sound trigger (capture from hotword DSP buffer) is supported by one input profile, the implementation must support a number of active streams on this profile corresponding to the number of concurrent sessions supported by sound trigger HAL.
- Concurrency of DSP hotword detection and capture from the AP.
- Concurrency of voice call TX and capture from the AP.
Implementing audio HAL
The audio HAL is composed of the following interfaces:
hardware/libhardware/include/hardware/audio.hrepresents the main functions of an audio device.
hardware/libhardware/include/hardware/audio_effect.hrepresents effects that can be applied to audio such as downmixing, echo, or noise suppression.
You must implement all interfaces.
Android 11 features stricter enforcement of sound trigger HAL implementations at runtime than lower versions.
This affects implementations of the HIDL interfaces specified under
The specifications of these HAL interfaces aren't specific to:
- When the implementation is allowed to return error codes from operations
- What would be the resulting state of the implementation
- What would be the expected error recovery procedure
Furthermore, due to the opaque nature of the sound trigger subsystem, VTS tests don't provide meaningful coverage for these scenarios.
To ensure a reliable and consistent behavior between driver implementations, in Android 11, we're treating any non-success error codes returned from the HAL as programming errors and attempting to recover from them by restarting the HAL process (and possibly other processes). This is a last-resort recovery strategy and the expectation is that those cases won't occur in a properly working system.
We strongly encourage implementers of the sound trigger HAL to perform rigorous testing as soon as possible of scenarios that could result in error codes being returned and provide feedback regarding this approach. We don't expect any Treble/VTS-related failures due to this change but there could be new system-related failures, which you would need to address early. In the longer term, it ensures more reliable and consistent behavior across platforms.
Audio header files
For a reference of the properties you can define, refer to the audio header files:
- In Android 6.0 and higher, see
- In Android 5.1 and lower, see
For an example, refer to the implementation for the Galaxy Nexus at
In addition to implementing the audio HAL, you must also create an audio policy configuration file that describes your audio topology and package the HAL implementation into a shared library. You can also configure pre-processing effects such as automatic gain control and noise suppression.