구성 가능한 오디오 정책 엔진

Android 14에서 Android Automotive Operating System (AAOS)은 기본 오디오 영역 내에서 구성 가능한 오디오 정책 (CAP) 엔진 자동차 오디오 관리를 활용합니다. 특히 CAP 엔진을 사용하면 AAOS가 오디오 라우팅만, 오디오 볼륨만 또는 라우팅과 볼륨을 동시에 제어할 수 있습니다. 다음 플래그를 사용하여 동작을 제어할 수 있습니다.

  • useCoreAudioVolume 플래그를 사용하여 CAP 볼륨 관리를 사용 설정합니다. 이 값이 true이면 자동차 오디오 서비스는 오디오 관리자 API를 사용하여 볼륨 그룹을 관리합니다.

  • useCoreAudioRouting 플래그를 사용하여 CAP 오디오 라우팅 관리를 사용 설정합니다. 이 값이 true이면 자동차 오디오 서비스는 구성 가능한 오디오 정책 라우팅을 사용하여 오디오 라우팅을 관리합니다.

오디오 정책 엔진은 Android에서 기본적으로 기본 오디오 정책 엔진의 형태로 지원됩니다.

배경

CAP 엔진은 매개변수 처리를 위한 플러그인 기반 및 규칙 기반 프레임워크인 Intel의 매개변수 프레임워크를 기반으로 합니다. 특히 Android 오디오 관리의 경우 CAP 엔진은 XML 파일 규칙을 정의하여 다음을 지정하는 기능을 도입했습니다.

  • 오디오 제품 전략
  • 오디오 출력 장치 선택 규칙
  • 오디오 입력 기기 선택 규칙
  • 볼륨 표와 함께 볼륨 및 음소거를 관리하는 규칙

Android 16 이전의 CAP 초기화

다음 그림은 Android 6의 구성 가능한 오디오 정책 엔진 구성 관리에 대한 개요를 보여줍니다.

Android 16 이전의 CAP 엔진 아키텍처

그림 1. Android 6부터 CAP 엔진 구성 관리

그림과 같이 CAP 엔진 구성은 오디오 정책 서비스가 vendor 파티션의 audio_policy_engine_configuration.xml 파일에서 정보를 파싱하여 가져옵니다. CAP 엔진 구성 파일은 audio_policy_engine_configuration.xsd에 정의된 스키마를 사용하여 필요한 정보를 가져옵니다. audio_policy_engine_configuration.xml는 자동차의 예입니다. 다른 폼 팩터의 유사한 예는 frameworks/av/services/audiopolicy/engineconfigurable/config/example/ 폴더에 있습니다.

다음 그림은 구성 가능한 오디오 정책 엔진 정보가 오디오 정책 서비스 내에 로드되는 방식에 관한 자세한 정보를 보여줍니다. 이 경우 매개변수 프레임워크는 XML 파일에서 구조와 설정을 로드합니다.

Android 16 이전의 CAP 엔진 로드 경로

그림 2. 오디오 정책 서비스 내에 로드된 CAP 정보입니다.

Android 15 이하의 CAP 구조 파일

구조와 설정을 가져오기 위해 오디오 정책 서비스는 ParameterFrameworkConfigurationPolicy.xml 파일을 읽습니다. 구조 설명 파일 위치를 통해 구조 정보를 참조합니다.

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

이는 파일의 구조 정보를 가리킵니다.

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

골격 구조는 Android에 제공됩니다. 구조 정보에는 제품 전략 구조 정보가 필요하므로 Android에서는 사용 가능한 제품 전략 XML 파일에서 정보를 생성할 수 있는 buildStrategiesStructureFile.py 생성 도구를 제공합니다. 다음과 같이 genrule default buildstrategiesstructurerule를 통해 참조할 수 있습니다.

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

여기서 audio_policy_engine_configuration_files은 오디오 정책 엔진 구성 파일입니다. 이 자동차용 예는 자동차 폴더의 오디오 정책 구성 파일을 참조합니다. 기타 예시에서는 기기의 공급업체 파티션에 파일을 푸시하도록 빌드를 구성하는 방법을 보여줍니다.

Android 15 이하의 CAP 설정 파일

구조와 마찬가지로 매개변수의 규칙과 값을 나타내는 설정 정보는 ParameterFrameworkConfigurationPolicy.xml 파일에서 다음과 같이 참조됩니다.

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android는 오디오 정책 엔진 구성 및 매개변수 프레임워크 파일을 사용하여 이 정보를 생성하는 빌드 도구도 제공합니다. 자세한 내용은 구성을 참고하세요.

AIDL 오디오 HAL CAP 초기화

Android 16부터 AIDL 오디오 HAL API 정의가 오디오 정책 엔진 구성인 AudioHalCapConfiguration.aidl로 확장됩니다. 다음 그림은 Android 16의 CAP 엔진 구성 관리를 개략적으로 보여줍니다.

CAP 엔진 aidl 아키텍처

그림 3. Android 16의 CAP 엔진 구성 관리

오디오 정책 서비스는 기기의 공급업체 파티션에 있는 XML 파일에서 정보를 파싱하는 대신 AIDL 오디오 HAL API를 직접 사용하여 CAP 엔진 정보를 가져옵니다.

이 구성에서는 매개변수 프레임워크의 구조가 여전히 오디오 서버 측의 CAP 엔진에 의해 로드됩니다.

CAP 엔진 aidl 로드 경로

그림 4. CAP 엔진 구조

모든 경우에 구성은 제품 전략, 볼륨 그룹, 기준과 관련된 정보를 완전히 지정해야 합니다.

다음 그림은 오디오 정책 서비스에서 CAP 엔진 구성을 가져오는 데 사용하는 AIDL 오디오 HAL API의 대략적인 개요를 보여줍니다.

CAP 엔진 AIDL API그림 5. AIDL 오디오 HAL API

이 설정에서 오디오 정책 서비스는 AIDL 오디오 HAL에서 다음 정보를 가져옵니다.

  • 구성
  • 전략
  • 볼륨
  • 기준
  • 설정

기본 AIDL 오디오 HAL 로더

HIDL에서 AIDL로 원활하게 전환하기 위해 기본 오디오 AIDL 오디오 HAL은 XML CAP 엔진 로더를 제공합니다. 공급업체는 기본 오디오 HAL로 오디오 HAL을 확장하거나 libaudioserviceexampleimpl 라이브러리를 참조하여 이 로더를 직접 사용할 수 있습니다.

기본 AIDL 오디오 HAL 로더는 audio_policy_engine_configuration.xml를 사용하여 다음 정보를 가져옵니다.

  • 구성
  • 전략
  • 볼륨
  • 기준

구조 정보는 PolicyConfigurableDomains.xml 파일에서 가져옵니다. 이전 메커니즘과의 주요 차이점은 구조 정보가 오디오 정책 서비스의 매개변수 프레임워크 대신 AIDL 오디오 HAL에서도 가져온다는 점입니다.

공급업체는 domaingeneratorpolicyrule 도구를 사용하여 오디오 정책 엔진 구성의 정보를 사용하여 구성 가능한 도메인을 생성할 수 있습니다. 자동차 Cuttlefish 가상 기기 예시를 참고로 사용할 수 있습니다.

AIDL 구성의 구조

Android 16 이상에서 오디오 정책 서비스는 ParameterFrameworkConfigurationCap.xml 파일을 읽고 파싱하여 구조 정보를 가져옵니다. 특히 구조 설명 파일에서 정보를 가져옵니다.

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

프레임워크는 필요한 파일을 필요한 정보와 함께 /etc/parameter-framework/ 폴더에 배치합니다.

이 구조는 제어해야 하는 매개변수를 나타내므로 구성 또는 도메인에서 참조해야 합니다. 이를 위해 AIDL 엔진 구성은 매개변수에 사전 결정된 이름을 사용해야 합니다. 제품 전략의 경우 구조는 CapProductStrategies.xml에서 구성됩니다.

기본 제품 전략

기본 엔진에 제공된 기본값부터 제품 전략은 STRATEGY_ 접두사로 시작합니다.

  • STRATEGY_PHONE
  • STRATEGY_SONIFICATION
  • STRATEGY_ENFORCED_AUDIBLE
  • STRATEGY_ACCESSIBILITY
  • STRATEGY_SONIFICATION_RESPECTFUL
  • STRATEGY_MEDIA
  • STRATEGY_DTMF
  • STRATEGY_CALL_ASSISTANT
  • STRATEGY_TRANSMITTED_THROUGH_SPEAKER

이 형식은 기본 전략을 사용하는 기기의 HIDL에서 AIDL로의 전환을 완화하기 위해 제공되었습니다. 이 형식 변경은 엔진을 구성하는 데 사용되는 기존 파일 (예: PfW, XML)에 몇 가지 영향을 미칩니다. 특히 모든 제품 전략 참조를 새 이름을 사용하도록 변경해야 합니다. 예를 들면 다음과 같습니다.

AIDL 이외의 구성 매개변수 이름
/Policy/policy/product_strategies/media/device_address
/Policy/policy/product_strategies/media/selected_output_devices/mask
AIDL 구성 매개변수 이름
/Policy/policy/product_strategies/STRATEGY_MEDIA/device_address
/Policy/policy/product_strategies/STRATEGY_MEDIA/selected_output_devices/mask
OEM 정의 제품 전략

구성 가능한 엔진은 OEM이 제품 전략 정의를 변경할 수 있는 기능을 제공합니다. 이를 계속 지원하기 위해 제품 전략 파일 CapProductStrategies.xml은 vx_1000부터 vx_1039까지 40개의 공급업체 확장 가능 제품 전략도 제공합니다. 모든 공급업체 확장 프로그램은 vx_ 접두사로 시작하고 AIDL 오디오 HAL 제품 전략 정의에서 제품 전략 ID를 나타내는 숫자를 따라야 합니다. 나머지 정의(예: 오디오 속성 그룹, 이름)는 오디오 HAL 엔진 구성의 AudioHALProductStrategy 객체에서 가져옵니다.

기본 제품 전략과 마찬가지로 공급업체 정의 OEM 참조도 AIDL이 아닌 구성과 AIDL 구성 간에 조정해야 합니다. 예를 들면 다음과 같습니다.

AIDL 이외의 구성 매개변수 이름
/Policy/policy/product_strategies/oem_extension_strategy/device_address
/Policy/policy/product_strategies/oem_extension_strategy/selected_output_devices/mask
AIDL 구성 매개변수 이름
/Policy/policy/product_strategies/vx_1037/device_address
/Policy/policy/product_strategies/vx_1037/selected_output_devices/mask

제품 전략

제품 전략은 오디오 스트림을 분류하고 그룹화하는 방식을 맞춤설정하는 방법을 제공합니다. 이를 통해 오디오 기기의 라우팅 방식, 볼륨 관리 방식 등 오디오 기기를 보다 유연하게 구성할 수 있습니다. 각 제품 전략에는 해당 제품 전략과 연결해야 하는 스트림을 식별하는 오디오 속성 그룹이 하나 이상 있을 수 있습니다. 이러한 오디오 속성 그룹을 사용하면 오디오를 더 세분화하여 분류할 수 있으며 다음 유형을 혼합하여 사용할 수 있습니다.

  • Usage 유형은 소리가 재생되는 이유 (예: 미디어, 알림, 통화)를 설명합니다.
  • 콘텐츠 유형 유형은 재생 중인 콘텐츠 (예: 음악, 음성, 동영상, 음향화)를 설명합니다.
  • 플래그 유형은 스트림과 관련된 다양한 동작 또는 요청을 정의합니다.
  • 태그 유형은 임의의 공급업체 문자열 값 목록을 지원합니다.
    • 각 문자열은 VX_로 시작하고 영숫자 문자열 (예: VX_OEM, VX_NAVIGATION)이 뒤에 와야 합니다.
<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

이 발췌 부분은 자동차 에뮬레이터에 사용된 제품 전략의 예를 보여줍니다. 오디오 사용 미디어와 게임이 각각 포함된 두 개의 오디오 속성이 포함되어 있습니다. 이 제품 전략은 자동차 오디오 서비스에 사용되는 MUSIC 오디오 컨텍스트와 일치하지만 이러한 일치는 필수사항이 아닙니다. Android와 함께 CAP를 사용하는 OEM의 주요 유틸리티 중 하나는 더 유연한 오디오 그룹 정의입니다.

볼륨 그룹

또한 각 오디오 속성 그룹에는 연결된 볼륨 그룹이 있어야 합니다. 이 볼륨 그룹은 오디오 속성 그룹에 속한 오디오 속성과 일치하는 모든 스트림과 연결됩니다. 제품 전략 섹션의 음악 제품 전략 예시에는 볼륨 그룹 media이 있으며 미디어 볼륨 그룹의 정의는 다음과 같습니다.

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

이 정의에서 볼륨 그룹에는 다음이 포함됩니다.

  • 그룹 이름
  • 그룹 최솟값 색인
  • 그룹 최대 색인
  • 볼륨 그룹 곡선

볼륨 그룹 곡선에는 볼륨 그룹 색인과 볼륨 이득(밀리벨) 간의 포인트별 매핑이 포함됩니다. 제공된 점은 볼륨이 관리될 때 가장 일치하는 이득을 선형으로 보간하는 데 사용됩니다. 각 볼륨 그룹 곡선은 기기 유형 카테고리(예: 헤드셋, 스피커, 외부 미디어)와 연결됩니다.

볼륨 그룹은 오디오 속성 그룹의 일부인 스트림의 볼륨을 관리합니다. 예를 들어 음악 또는 게임이 포함된 오디오 속성이 있는 스트림이 시작되면 미디어 볼륨 그룹에 마지막으로 설정된 볼륨 색인이 사용됩니다. 이 경우 선택한 기기에 따라 해당하는 기기 카테고리 곡선이 선택되고 스트림이 시작될 때 해당 이득이 설정됩니다.

구성

CAP 엔진에서 구성은 오디오의 작동 방식을 결정하는 조건 또는 규칙을 정의하는 데 사용됩니다. 이러한 구성은 런타임에 평가되어 오디오 시스템의 현재 상태에 따라 적용할 적절한 규칙을 선택합니다.

그림 5와 같이 API에는 여러 도메인이 포함되어 있습니다. 각 도메인의 목표는 로직을 더 작은 라우팅 문제 (예: 기기 1, 기기 2)로 분할하여 해결하는 것입니다.

각 도메인에는 구성이 있고 각 구성에는 규칙 집합이 있습니다. 규칙은 AudioPolicyManager에서 제공하는 기준에 따라 설정됩니다.

  • 오디오 모드
  • 사용 가능한 입력 및 출력 장치
  • 사용 가능한 입력 및 출력 장치 주소
  • 사용 용도
    • 미디어
    • 커뮤니케이션
    • 녹화
    • 도크
    • 시스템
    • Hdmi 시스템 오디오
    • 인코딩된 서라운드
    • 벨소리 진동

각 도메인에는 동작에 영향을 미쳐야 하는 규칙을 지정하는 구성이 포함되어 있습니다. 구성 순서가 중요하며 구성이 필요한 순서인지 확인하는 것이 중요합니다. 구성의 규칙이 확인되면 구성이 선택됩니다.

다음 코드는 구성 가능한 도메인을 구성하는 데 필요한 XML 파일을 생성하는 데 사용할 수 있는 매개변수 프레임워크 파일의 발췌 예를 보여줍니다.


supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

도메인 DeviceForProductStrategies는 제품 전략 기기 선택을 처리할 때 여러 규칙을 적용하는 방법을 정의합니다. 파란색 부분은 고려해야 할 규칙을 설명하고 녹색 부분은 적용된 구성입니다. 이 특정 예시에는 다음 구성이 포함됩니다.

  • 음악 제품 전략에 사용할 블루투스 A2DP 기기 선택 (ID 1000, vx_1000)
    • 미디어에 사용되는 경우 A2DP를 제외하지 않음
    • 통신에 사용되는 경우 BT SCO가 아님
    • 사용 가능한 기기인 경우 BT A2DP 포함
  • 버스 기기 선택
    • 버스 기기를 사용할 수 있는 경우
    • 주소가 BUS00_MEDIA인 경우
  • 그렇지 않으면 기본 출력 장치 선택

상응하는 구성 가능한 정책 엔진 XML 파일을 생성하려면 다음 단계에 따라 빌드 규칙을 정의하여 빌드 시스템을 통해 매개변수 프레임워크 (PFW) 파일을 실행합니다.

  1. Android.bp 파일에서 파일의 파일 그룹을 만듭니다.

    filegroup {
    name: ":device_for_product_strategies.pfw",
    srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
}

  2. 다른 PfW 파일 (있는 경우)에 파일을 추가합니다.

    filegroup {
    name: "edd_files",
    srcs: [
        ":device_for_input_source.pfw",
        ":volumes.pfw",
        ":device_for_product_strategyies.pfw",
    ],
}

  3. 상응하는 도메인 생성 규칙을 만듭니다.

    genrule {
    name: "domaingeneratorpolicyrule_gen",
    defaults: ["domaingeneratorpolicyrule"],
    srcs: [
        ":audio_policy_engine_criterion_types",
        ":audio_policy_pfw_structure_files",
        ":audio_policy_pfw_toplevel",
        ":edd_files",
    ],
}

    여기서 domaingeneratorpolicyrule은 PolicyConfigurableDomains.xml 파일을 생성하기 위해 프레임워크에서 제공하는 생성 규칙입니다. 도메인 생성 규칙에 포함된 다른 소스 파일 (scrs)은 다음과 같습니다.

    소스 설명
    audio_policy_pfw_toplevel 최상위 매개변수 프레임워크 구성 파일
    audio_policy_pfw_structure_files 구성 파일을 생성하는 데 사용되는 도메인 생성 구조 파일입니다.
    audio_policy_engine_criterion_types 생성 중에 사용된 기준을 설명하는 기준 유형 XML 파일입니다.
    edd_files 단일 도메인 파일 목록 (각각 하나의 <ConfigurableDomain> 태그 포함)

빌드에서 생성 규칙을 실행하면 모든 도메인과 함께 PolicyConfigurableDomains.xml가 생성됩니다. 다음은 규칙 PfW 예시를 사용하여 생성된 파일에서 발췌한 내용입니다.

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

CAP 디버깅

remote-process를 사용하여 CAP 구성을 덤프할 수 있습니다.

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

여기에는 적용 가능성 조건을 비롯한 모든 도메인과 구성이 표시됩니다. 다음은 블루투스 A2DP, 버스 기기, 기본 구성을 사용하는 Cuttlefish 자동차 기기의 발췌 부분입니다. 구성을 참고하세요.

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

CAP 매개변수 프레임워크를 디버그하는 데 사용할 수 있는 다른 명령어에 관한 자세한 내용은 다음 도구를 사용하세요.

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

이 도구를 사용하려면 OEM 제조업체가 기기에서 튜닝을 허용해야 합니다. 기기에서 조정이 허용되는지 확인하려면 다음 명령어를 사용하세요.

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

Android 15 이하에서는 파일이 다를 수 있으므로 다음 명령어를 사용하세요.

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

파일에는 상응하는 서버 포트와 함께 TuningAllowed="true"가 포함되어야 합니다.

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

이 파일은 빌드 이미지 유형에 따라 자동 생성되며 (또는 기존 빌드의 경우 출시용 파일 또는 디버그용 파일을 사용함) 출시 빌드는 소켓 포트 없이 TuningAllowed를 false로 설정합니다 (출시 빌드에서는 소켓이 금지됨). 엔지니어링 및 userdebug 빌드는 사용된 소켓 포트와 함께 true로 설정합니다. 이는 audio_policy_pfw_toplevel에서 참조하는 파일입니다. 원격 프로세스 도구는 기기의 make 또는 빌드 파일에도 포함되어야 합니다.

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

소켓을 허용하는 상응하는 SELinux 정책도 포함해야 합니다. 이는 출시 모드에서 소켓을 명시적으로 허용하지 않으므로 디버그 모드에서만 작동합니다.

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Android 16의 CAP 이전

AIDL 오디오 HAL CAP 엔진과 이전 버전에서 가져온 주요 변경사항을 고려할 때 고려해야 할 다양한 기기 전환 시나리오가 있습니다. 이 섹션에서는 가장 눈에 띄는 전환 시나리오를 다루고 CAP 엔진 구성을 사용 설정하기 위한 작업에 관한 권장사항을 제공합니다.

시나리오 1: Android 16 이상을 사용하는 새 기기, 기기 CAP 구성의 이전 소스 없음

새 기기는 vendor 파티션에서 Android 16 이상 코드로 실행되어야 합니다. 즉, AIDL 오디오 HAL 인터페이스를 통해 구성 가능한 오디오 정책 엔진 구성을 노출해야 합니다. 기기 CAP 엔진 구성은 예시에서 복사해야 합니다. vendor 파티션에는 PfW CAP 도메인 정의가 없어야 합니다.

기기에 사용되는 시스템 이미지가 Android 16 이상입니다. 오디오 서비스 프레임워크는 AIDL 오디오 HAL 인터페이스를 통해 CAP 구성을 감지하므로 시스템 이미지의 PfW CAP 도메인 정의를 사용하여 PfW를 초기화하고 AIDL을 통해 수신된 기기 CAP 구성을 로드합니다.

예를 들어 이 변경사항에서 도입되었으며 필수 구성 파일을 설정하는 데 필요한 필수 파일, 빌드 규칙, make 파일을 참조할 수 있는 자동차 Cuttlefish 가상 기기를 참고하세요. 이는 기본 AIDL 오디오 HAL에 제공된 로더와 함께 작동합니다.

시나리오 2: CAP를 사용하는 이전 기기에서 Android 16 이상을 사용하는 새 기기로 전환

새 기기는 vendor 파티션에서 Android 16 이상 코드로 실행되어야 합니다. 그러나 OEM에는 사용 가능한 기기 CAP 엔진 구성이 있으므로 이를 시작점으로 사용하거나 완전히 재사용하려고 합니다. CAP 구성의 AIDL 버전은 Android 15 이하 버전과 비교하여 몇 가지 변경사항이 있으므로 공급업체는 기존 구성을 AIDL로 변환해야 합니다. Android 16 이하 버전 간의 변경사항에 필요한 변경사항은 제품 전략의 설명을 참고하세요. 일반적으로 오디오 프레임워크는 시나리오 1과 동일한 방식으로 CAP 구성을 검색하고 로드합니다.

시나리오 3: CAP가 있는 기존 기기에서 시스템 파티션만 Android 16으로 업데이트됨

이 시나리오에서 vendor 파티션에는 Android 15 이하 버전의 기기 CAP 구성과 PfW CAP 도메인 정의가 포함됩니다. vendor 파티션은 손대지 않으므로 여전히 HIDL HAL을 사용합니다. 이 프레임워크는 Android 15 이하 시나리오를 따르며 vendor 파티션에서 모든 CAP 관련 구성을 로드합니다.

시나리오 4: Android 15에서 출시된 기존 기기(CAP 포함)

Android 15의 AIDL에서는 CAP가 지원되지 않았으므로 일부 공급업체는 오디오 프레임워크에서 로드된 AIDL 오디오 HAL 및 CAP가 포함된 새 기기를 출시했습니다. 이 하이브리드 모드는 비공식이었지만 Android 16에 포함되었습니다. 이 모드는 Android 16에서 새 기기를 출시하는 데 사용해서는 안 되며, Android 15 공급업체가 있는 기존 기기를 Android 16 (system 파티션 업데이트)으로 업데이트하는 데 사용해야 합니다.

오디오 프레임워크는 CAP 구성 없이 AIDL 오디오 HAL 오디오 구성을 검색합니다. CAP 구성의 경우 오디오 정책 서비스 (오디오 프레임워크)는 vendor 파티션에서 CAP 구성을 로드하는 것으로 대체됩니다. 이 경우 PfW CAP 도메인 정의와 기기 CAP 구성을 모두 vendor 파티션에서 로드해야 합니다.

CAP 이전 요약

다음 표에는 호환되는 시스템 및 공급업체 구성과 CAP 구성 요구사항이 요약되어 있습니다.

시스템 파티션 시나리오 공급업체 파티션 코드 버전 핵심 오디오 HAL 유형 PfW CAP 도메인 정의 위치 기기 CAP 구성
Android 15 4 Android 14 이하 HIDL vendor HIDL 버전
Android 16 3 Android 14 이하 HIDL vendor HIDL 버전
Android 16 4 Android 15 AIDL vendor HIDL 버전
Android 16 2 Android 16 AIDL system HIDL에서 변환된 AIDL 버전
Android 16 1 Android 16 AIDL system 예시의 AIDL 버전