Android 16부터 AIDL 오디오 HAL 인터페이스가 구성 가능한 오디오 정책 (CAP)을 완전히 지원합니다.
이 페이지에서는 파트너와 SoC 공급업체가 오디오 정책 구성을 이전하는 데 필요한 기술적 배경을 제공합니다.
매개변수 프레임워크
CAP 구현은 Intel 매개변수 프레임워크를 기반으로 합니다. CAP는 Android 6에서 도입되었습니다. 매개변수 프레임워크 (PfW)를 사용하면 매개변수 측면에서 시스템을 설명할 수 있습니다. PfW는 구성 XML 파일을 사용하여 플러그인을 사용하여 매개변수를 작업에 바인딩하고 현재 기준에 따라 매개변수를 변경하기 위한 규칙을 제공합니다.
HIDL을 통해 Android 프레임워크는 공급업체 파티션에서 이러한 XML 파일을 직접 로드할 수 있었습니다. 이는 이러한 XML 파일에 대해 HAL API의 일부로 XSD 스키마가 정의되었기 때문에 허용되었습니다. HIDL HAL의 각 주요 출시에는 상응하는 XSD 스키마가 있었습니다. 이전 버전과의 호환성은 주 출시 버전에서 필요하지 않았습니다.
AIDL의 CAP 구조
AIDL로 전환하면서 HAL API 출시는 하위 호환성을 유지해야 합니다(HIDL 용어로 AIDL HAL의 각 출시는 '마이너' 업데이트임). 스키마의 하위 호환 업데이트를 정의하는 확립된 방법이 없으므로 XSD 스키마는 더 이상 HAL API의 일부로 사용할 수 없습니다. 따라서 이전에 XML 파일에 정의된 구성은 이제 HAL에서 AIDL API를 사용하여 제공해야 합니다. 이를 위해 Android 15의 AIDL 오디오 HAL에 있는 오디오 정책 구성 XML과 마찬가지로 CAP 구성의 구조가 AIDL로 변환됩니다.
AIDL HAL의 기본 구현에는 파트너의 이전을 간소화하기 위해 기존 CAP XML 파일의 콘텐츠를 기반으로 AIDL parcelable을 작성하는 도우미 클래스가 포함되어 있습니다.
이전 시나리오
파트너는 이전에 CAP를 사용하지 않았던 제품을 처음 출시하는지 또는 기존 제품을 이전하는지에 따라 이 섹션에 나열된 옵션을 고려할 수 있습니다.
새 제품
오디오 정책 구현에 CAP를 사용하기 시작하는 새 제품의 경우 OEM은 공급업체 측에서 CAP 구성을 저장하는 데 XML을 사용할 수 있습니다.
XML을 사용하면 상위 수준 설명에서 구성을 생성하는 데 도움이 되는 스크립팅 도구 모음이 있다는 이점이 있습니다.
OEM이 공급업체 파티션에 CAP 구성을 저장하기 위해 XML을 사용하기로 결정한 경우 구성을 AIDL로 변환할 때 XML 파서의 기본 구현을 사용하는 것이 좋습니다.
기존 제품 업데이트
제품이 이미 CAP를 사용하고 있으므로 XML 구성이 있는 경우 HAL의 AIDL 버전과 함께 기존 CAP를 계속 사용할 수 있습니다.
제품 전략의 명명 규칙은 CAP 구성의 HIDL 버전과 AIDL 버전에서 다릅니다. HIDL에서는 기본 제공('레거시') 전략이 media와 같은 소문자 짧은 이름을 사용했지만 AIDL에서는 기본 제공 전략이 STRATEGY_로 시작하는 대문자 이름(예: STRATEGY_MEDIA)을 사용합니다. CapProductStrategies.xml에서 기본 제공 전략 목록을 확인하세요.
동일한 파일은 1000~1039의 숫자로 vx_10xx의 이름 지정 패턴을 따르는 OEM별 전략의 '사전 할당된' ID를 정의합니다.
기존 제품
CAP를 사용하는 제품이 공급업체 파티션을 업데이트하지 않고 HIDL에 계속 있으면 시스템 파티션을 Android 16으로 업데이트할 수 있습니다. 프레임워크는 기존 CAP 구성과 계속 호환됩니다.
구현 예시
파트너가 플랫폼에 CAP를 구현할 수 있도록 AOSP에는 AIDL HAL과 함께 CAP를 사용하는 Cuttlefish 가상 기기의 '자동차' 버전 예시가 있습니다. 기기별 구성은 device/google/cuttlefish/shared/auto/audio/policy/engine에 있으며 lunch 타겟 이름은 aosp_cf_x86_64_auto입니다. Android.bp 파일은 전체 CAP 공급업체 파일 세트를 생성할 때 참조로 사용할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Configurable Audio Policy support in AIDL HAL\n\nStarting with Android 16, the [AIDL Audio\nHAL](/docs/core/audio/aidl-implement) interface fully supports Configurable\nAudio Policy (CAP).\n\nThis page provides necessary technical background to assist partners and SoC\nvendors in the migration of their audio policy configurations.\n\nThe Parameter Framework\n-----------------------\n\nThe implementation of the CAP is based on the [Intel Parameter\nFramework](https://github.com/intel/parameter-framework). The CAP was introduced\nin Android 6. The Parameter Framework (PfW) allows to describe a system in terms\nof *parameters*. By using a configuration XML file, the PfW binds the parameters\nto actions using plugins, and provides rules for changing the parameters\naccording to the current criteria.\n| **Note:** For audio policy, *parameters* may be current input or output devices, and *criteria* are the current operating conditions, such as the phone communication mode, and available physical input or output devices.\n\nStructure of CAP in HIDL\n------------------------\n\nIn HIDL, all the configuration for the CAP was specified in XML. See [Parameter\nFramework](#pfw), and [Configuration using Parameter Framework](/docs/core/audio/implement-policy#policy_config) for more information.\nXML files were used to specify the following:\n\n- Description of the structure of the parameters (that is, the description of the audio domain for the PfW)\n- Definitions for criteria\n- Rules for routing strategies (input and output device selection)\n- Volume tables specification\n\nWith HIDL, the Android framework was able to load these XML files directly from\nthe vendor partition. This was allowed because an XSD schema was defined, as\npart of the HAL API, for these XML files. Each major release of the HIDL HAL had\na corresponding XSD schema. Major releases didn't require backwards\ncompatibility.\n\nStructure of CAP in AIDL\n------------------------\n\nWith the transition to AIDL, HAL API releases must remain backward-compatible\n(in HIDL terms, each release of the AIDL HAL is a \"minor\" update). XSD schemas\ncan't be used anymore as part of HAL APIs as there is no established way of\ndefining backward-compatible updates to the schemas. Hence, the configuration\nthat was previously defined in XML files now needs to be provided by the HAL\nusing AIDL APIs. To facilitate this, the structure of the CAP configuration is\nconverted to AIDL, similar to Audio Policy Configuration XMLs in [AIDL Audio\nHAL](/docs/core/audio/aidl-implement) for Android 15.\n| **Note:** XML files that define the audio domain for the PfW aren't converted to AIDL as they don't change between devices or products. These XML files have been moved to the system partition from which they can be loaded directly by the PfW engine.\n\nData structures for the CAP are added to [Common stable data\ntypes](/docs/core/audio/aidl-implement#common-data-types-aidl-hal) and\ninclude the following parcelables:\n\n- [`AudioHalCapConfiguration.aidl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalCapConfiguration.aidl)\n- [`AudioHalCapCriterionV2.aidl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalCapCriterionV2.aidl)\n- [`AudioHalCapDomain.aidl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalCapDomain.aidl)\n- [`AudioHalCapParameter.aidl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalCapParameter.aidl)\n- [`AudioHalCapRule.aidl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalCapRule.aidl)\n\nThe entry point for the CAP configuration is in the\n[`AudioHalEngineConfig.CapSpecificConfig`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalEngineConfig.aidl)\nstructure. See the comments in\n[`AudioHalCapConfiguration.aidl`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioHalCapConfiguration.aidl)\nfor a diagram of CAP data structures.\n\nThe [default\nimplementation](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/audio/aidl/default/)\nof the AIDL HAL contains [a helper\nclass](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/audio/aidl/default/include/core-impl/CapEngineConfigXmlConverter.h)\nthat fills out the AIDL parcelables based on the contents of legacy CAP XML\nfiles to simplify migration for partners.\n| **Note:** Technically there is no need for partners to store CAP configuration in XML files anymore. The framework only requires that the configuration is provided using AIDL, whereas the source for the data that ends up in AIDL is irrelevant.\n\nMigration scenarios\n-------------------\n\nPartners may consider options as listed in this section, based on whether it's\nthe first launch of a product that wasn't using CAP before, or migration of an\nexisting product.\n\n### New product\n\nFor a new product which starts using CAP for audio policy implementation, the\nOEM can choose to use XML for storing CAP configuration on the vendor side.\n\nThe benefit of using XML is that there exist a set of [scripting\ntools](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/tools/)\nthat facilitate generation of the configuration from a high level description.\n\nIf the OEM decides to use XML for storing CAP configuration on the vendor\npartition, then it is recommended to use the default implementation of the XML\nparser for converting the configuration into AIDL.\n\n### Update for existing product\n\nIf the product already uses CAP and thus has the XML configuration, you can\ncontinue using the existing CAP with the AIDL version of the HAL.\n\nThe naming convention for product strategies differs in the HIDL and AIDL\nversions of the CAP configuration. In HIDL the built-in (\"legacy\") strategies\nused lower case short names like `media` whereas in AIDL, built-in strategies\nuse all-caps names prefixed with `STRATEGY_`, for example `STRATEGY_MEDIA`. See\nthe list of built-in strategies in\n[`CapProductStrategies.xml`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/data/etc/Structure/CapProductStrategies.xml).\nThe same file defines \"pre-allocated\" IDs for OEM-specific strategies which\nfollow the naming pattern of `vx_10xx` with numbers from `1000` to `1039`.\n\n### Legacy product\n\nIf the product which relies on CAP doesn't update its vendor partition and\nremains on HIDL, you can update the system partition to Android\n16. The framework remains compatible with the legacy\nCAP configuration.\n\nExample implementation\n----------------------\n\nTo help partners implement CAP for their platforms, the AOSP has an example of\n\"automotive\" flavor of the Cuttlefish virtual device which uses CAP with AIDL\nHAL. The device-specific configuration is located in\n[device/google/cuttlefish/shared/auto/audio/policy/engine](https://cs.android.com/android/platform/superproject/+/android-latest-release:device/google/cuttlefish/shared/auto/audio/policy/engine/),\nwith the `lunch` target name of `aosp_cf_x86_64_auto`. The `Android.bp` file can\nbe used as a reference for generating the full set of CAP vendor files."]]
