2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。

このページは Cloud Translation API によって翻訳されました。

設定可能なオーディオポリシーエンジン

Android 14 では、Android Automotive オペレーティングシステム（AAOS）は、プライマリオーディオゾーン内の構成可能なオーディオポリシー（CAP）エンジンカーオーディオ管理を活用します。具体的には、CAP エンジンにより、AAOS はオーディオルーティングのみ、オーディオ音量のみ、またはルーティングと音量の両方を同時に制御できます。次のフラグを使用して動作を制御できます。

CAP ボリューム管理を有効にするには、useCoreAudioVolume フラグを使用します。この値が true の場合、カーオーディオサービスはオーディオマネージャー API を使用して音量グループを管理します。
CAP オーディオルーティング管理を有効にするには、useCoreAudioRouting フラグを使用します。この値が 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 のデフォルト 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 Audio 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 [ファイル](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71) を読み取って解析することで、構造情報を取得します。

）。特に、構造記述ファイルから情報を取得します。

<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`

プロダクト戦略

プロダクト戦略を使用すると、音声ストリームの分類とグループ化の方法をカスタマイズできます。これにより、オーディオデバイスのルーティング方法や音量の管理方法など、オーディオデバイスの構成の柔軟性が向上します。各プロダクト戦略には、そのプロダクト戦略に関連付ける必要があるストリームを特定する 1 つ以上のオーディオ属性グループを含めることができます。これらの音声属性グループを使用すると、音声をより細かく分類できます。次のタイプを組み合わせることも可能です。

用途タイプは、音声が再生される理由（メディア、通知、通話など）を表します。
コンテンツタイプは、再生中のコンテンツ（音楽、音声、動画、ソニフィケーションなど）を表します。
フラグタイプは、ストリームに関するさまざまな動作やリクエストを定義します。
タグタイプは、ベンダー文字列値の任意のリストをサポートします。
- 各文字列は 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>

この抜粋は、車載エミュレータで使用されるプロダクト戦略の例を示しています。オーディオ用途がメディアとゲームの 2 つのオーディオ属性が含まれています。このプロダクト戦略は、カーオーディオサービスで使用される MUSIC オーディオコンテキストと一致しますが、このような一致は必須ではありません。Android とともに CAP を使用する OEM の主なユーティリティの 1 つは、より柔軟なオーディオグループ定義を可能にすることです。

音量グループ

また、各オーディオ属性グループには音量グループが関連付けられている必要があります。この音量グループは、オーディオ属性グループに属するオーディオ属性に一致するストリームに関連付けられます。プロダクト戦略セクションの音楽プロダクト戦略の例には、ボリュームグループ 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 は、プロダクト戦略のデバイス選択を処理する際にさまざまなルールを適用する方法を定義します。青色の部分は考慮すべきルールを示し、緑色の部分は適用された構成を示します。この例には、次の構成が含まれています。

音楽プロダクト戦略向け Bluetooth A2DP デバイスを選択（ID 1000、vx_1000）
- メディアに使用される場合、A2DP を除外しない
- 通信に使用される場合、BT SCO ではない
- 利用可能なデバイスの場合、BT A2DP を含める
バスデバイスを選択
- バスデバイスが利用可能な場合
- 住所が BUS00_MEDIA の場合
それ以外の場合はデフォルトの出力デバイスを選択

対応する構成可能なポリシーエンジンの XML ファイルを生成するには、次の手順でビルドルールを定義して、ビルドシステムでパラメータフレームワーク（PFW）ファイルを実行します。

Android.bp ファイルで、ファイルのファイルグループを作成します。

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

他の PfW ファイル（ある場合）にファイルを追加します。

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

対応するドメイン生成ルールを作成します。

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

適用条件を含むすべてのドメインと構成が表示されます。以下は、Bluetooth 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 構成を読み込みます。

例については、この変更で導入された自動車用 Cuttlefish 仮想デバイスをご覧ください。このデバイスは、必要な構成ファイルの設定に必要なファイル、ビルドルール、メイクファイルを参照できます。これは、デフォルトの AIDL オーディオ HAL で提供されるローダーで動作します。

シナリオ 2: Android 16 以降を搭載した新しいデバイスで、CAP を使用する以前のデバイスから移行する場合

新しいデバイスは、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 を搭載した新しいデバイスをリリースしました。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 バージョン