Google is committed to advancing racial equity for Black communities. See how.

Audio Implementation

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, and V2)
    • 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.