Configurable Audio Policy support in AIDL HAL

Starting with Android 16, the AIDL Audio HAL interface fully supports Configurable Audio Policy (CAP).

This page provides necessary technical background to assist partners and SoC vendors in the migration of their audio policy configurations.

The Parameter Framework

The implementation of the CAP is based on the Intel Parameter Framework. The CAP was introduced in Android 6. The Parameter Framework (PfW) allows to describe a system in terms of parameters. By using a configuration XML file, the PfW binds the parameters to actions using plugins, and provides rules for changing the parameters according to the current criteria.

Structure of CAP in HIDL

In HIDL, all the configuration for the CAP was specified in XML. See Parameter Framework, and Configuration using Parameter Framework for more information. XML files were used to specify the following:

  • Description of the structure of the parameters (that is, the description of the audio domain for the PfW)
  • Definitions for criteria
  • Rules for routing strategies (input and output device selection)
  • Volume tables specification

With HIDL, the Android framework was able to load these XML files directly from the vendor partition. This was allowed because an XSD schema was defined, as part of the HAL API, for these XML files. Each major release of the HIDL HAL had a corresponding XSD schema. Major releases didn't require backwards compatibility.

Structure of CAP in AIDL

With the transition to AIDL, HAL API releases must remain backward-compatible (in HIDL terms, each release of the AIDL HAL is a "minor" update). XSD schemas can't be used anymore as part of HAL APIs as there is no established way of defining backward-compatible updates to the schemas. Hence, the configuration that was previously defined in XML files now needs to be provided by the HAL using AIDL APIs. To facilitate this, the structure of the CAP configuration is converted to AIDL, similar to Audio Policy Configuration XMLs in AIDL Audio HAL for Android 15.

Data structures for the CAP are added to Common stable data types and include the following parcelables:

The entry point for the CAP configuration is in the AudioHalEngineConfig.CapSpecificConfig structure. See the comments in AudioHalCapConfiguration.aidl for a diagram of CAP data structures.

The default implementation of the AIDL HAL contains a helper class that fills out the AIDL parcelables based on the contents of legacy CAP XML files to simplify migration for partners.

Migration scenarios

Partners may consider options as listed in this section, based on whether it's the first launch of a product that wasn't using CAP before, or migration of an existing product.

New product

For a new product which starts using CAP for audio policy implementation, the OEM can choose to use XML for storing CAP configuration on the vendor side.

The benefit of using XML is that there exist a set of scripting tools that facilitate generation of the configuration from a high level description.

If the OEM decides to use XML for storing CAP configuration on the vendor partition, then it is recommended to use the default implementation of the XML parser for converting the configuration into AIDL.

Update for existing product

If the product already uses CAP and thus has the XML configuration, you can continue using the existing CAP with the AIDL version of the HAL.

The naming convention for product strategies differs in the HIDL and AIDL versions of the CAP configuration. In HIDL the built-in ("legacy") strategies used lower case short names like media whereas in AIDL, built-in strategies use all-caps names prefixed with STRATEGY_, for example STRATEGY_MEDIA. See the list of built-in strategies in CapProductStrategies.xml. The same file defines "pre-allocated" IDs for OEM-specific strategies which follow the naming pattern of vx_10xx with numbers from 1000 to 1039.

Legacy product

If the product which relies on CAP doesn't update its vendor partition and remains on HIDL, you can update the system partition to Android 16. The framework remains compatible with the legacy CAP configuration.

Example implementation

To help partners implement CAP for their platforms, the AOSP has an example of "automotive" flavor of the Cuttlefish virtual device which uses CAP with AIDL HAL. The device-specific configuration is located in device/google/cuttlefish/shared/auto/audio/policy/engine, with the lunch target name of aosp_cf_x86_64_auto. The Android.bp file can be used as a reference for generating the full set of CAP vendor files.