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 Android.mk
file).
Audio HAL capabilities
The Android 10 release includes the following new capabilities for audio HAL:
AudioSource
VOICE_PERFORMANCE
ECHO_REFERENCE
AudioFormat
AAC_LATM
(LC
,HE V1
, andV2
)CELT
APTX_ADAPTIVE
LHDC
LHDC_LL
AudioChannelMask
OUT_HAPTIC_A
OUT_HAPTIC_B
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.h
represents the main functions of an audio device.hardware/libhardware/include/hardware/audio_effect.h
represents 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
//hardware/interfaces/soundtrigger/
.
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
system/media/audio/include/system/audio.h
. - In Android 5.1 and lower, see
system/core/include/system/audio.h
.
For an example, refer to the implementation for the Galaxy Nexus at
device/samsung/tuna/audio
.
Next steps
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.