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 には buildStrategiesStructureFile.py 生成ツールが用意されています。このツールは、利用可能な商品戦略 XML ファイルから情報を生成できます。これは、次のように genrule のデフォルト buildstrategiesstructurerule を介して参照できます。

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

ここで、audio_policy_engine_configuration_files はオーディオポリシーエンジンの構成ファイルです。この自動車向けの例では、automotive フォルダにあるオーディオポリシー構成ファイルを参照しています。その他の例では、デバイスのベンダーパーティションにファイルを push するようにビルドを構成する方法を示しています。

Android 15 以前の CAP 設定ファイル

構造と同様に、パラメータのルールと値を表す設定情報は、ParameterFrameworkConfigurationPolicy.xml ファイルで次のように参照されます。

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

Android には、オーディオポリシーエンジンの構成とパラメータフレームワークファイルを使用してこの情報を生成するビルドツールも用意されています。詳細については、構成をご覧ください。

AIDL オーディオ HAL CAP の初期化

Android 16 以降では、AIDL Audio 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 ファイルを読み取って解析することで、構造情報を取得します。具体的には、構造記述ファイルから情報を取得します。

<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`	単一ドメインファイルのリスト（それぞれに 1 つの <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 仮想デバイスをご覧ください。このデバイスは、必要な構成ファイルを設定するために必要なファイル、ビルドルール、make ファイルを参照できます。これは、デフォルトの AIDL オーディオ HAL で提供されるローダで動作します。

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

新しいデバイスは、vendor パーティションに Android 16 以降のコードを搭載してリリースする必要があります。ただし、OEM には使用可能なデバイス CAP エンジン構成があるため、OEM はそれを開始点として使用（または完全に再利用）する必要があります。AIDL バージョンの CAP 構成は Android 15 以前のバージョンと一部変更されているため、ベンダーは既存の構成を AIDL に変換する必要があります。必要な変更については、Android 16 以前のバージョンと Android 17 の変更点に関するプロダクト戦略の説明をご覧ください。通常、オーディオフレームワークは、シナリオ 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 バージョン