Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

オーディオ ポリシーの構成

Android 10 リリースでは、オーディオ ポリシー マネージャーの重要なリファクタリングが含まれており、自動車の複雑なユースケースをサポートするために次のような柔軟性が強化されています。

  • OEM 固有のルーティング ストラテジー
  • 同一のボリューム カーブを使用し、従来のストリーム タイプを持つグループのカスタマイズが可能なボリューム グループ
  • ハード コーディングではなく、オーディオ ポリシー エンジンによってルーティング ストラテジーを宣言
  • ボリューム カーブとグループをオーディオ ポリシー エンジンによって管理
  • 共通コードおよび構成可能なコードの将来的な分割の必要性に備えた内部リファクタリングと、より豊富なオーディオ デバイス管理の提供(たとえば、ポリシールールのプロパティ タイプだけでなく、すべてのデバイス プロパティを使用できます)

Android 7.0 では、オーディオ トポロジを記述するためのオーディオ ポリシー設定ファイル形式(XML)が導入されました。

以前の Android リリースでは、デバイスに存在するオーディオ デバイスの宣言には device/<company>/<device>/audio/audio_policy.conf を使用する必要がありました(このファイルの具体例は、Galaxy Nexus のオーディオ ハードウェアの例を device/samsung/tuna/audio/audio_policy.conf で参照できます)。しかし、CONF はシンプルな上にプロパイエタリ形式であったため、テレビや自動車などの複雑なトポロジを記述するには多くの制約がありました。

Android 7.0 では audio_policy.conf が廃止され、XML ファイル形式を使用してオーディオ トポロジを定義するためのサポートが追加されました。XML ファイル形式は人間が読み取れる形式であり、さまざまな編集および解析ツールが存在します。また、複雑なオーディオ トポロジを記述できる十分な柔軟性を備えています。Android 7.0 では、USE_XML_AUDIO_POLICY_CONF ビルドフラグを使用して構成ファイルの XML 形式を選択します。

XML 形式のメリット

XML ファイルでも、CONF ファイルと同様に、出力および入力ストリーム プロファイルの数やタイプ、再生とキャプチャに使用できるデバイス、オーディオ属性を定義できます。加えて、XML 形式には次のような利点があります。

  • Android 10 では、同時に複数の録音アプリを実行できます。
    • 同時実行が原因で録音開始が拒否されることはありません。
    • registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) コールバックによって、クライアントにキャプチャパスの変更が通知されます。
  • 次の状況では、クライアントはサイレント オーディオ サンプルを取得します。
    • プライバシーに配慮が必要なユースケース(VOICE_COMMUNICATION など)の場合。
    • クライアントにフォアグラウンド サービスまたはフォアグラウンド UI がない場合。
    • このポリシーは特別な役割を識別します。
      • アクセシビリティ サービス: プライバシーに配慮が必要なユースケースの場合でも録音できます。
      • アシスタント: UI が上位にある場合は機密性が高いと見なされます。
  • オーディオ プロファイルは、HDMI シンプル オーディオ記述子に類似した構造を持ち、各オーディオ形式に対して、異なるサンプリング レート / チャンネル マスクのセットを有効化します。
  • デバイスとストリーム間で可能なすべての接続に、明示的な定義が存在します。 以前はルールが明確化されておらず、同じ HAL モジュールに接続されたすべてのデバイスを接続できたため、オーディオ パッチ API でリクエストされた接続をオーディオ ポリシーによって制御できないことがありました。XML 形式では、トポロジの記述によって接続の制限を定義します。
  • 「インクルード」のサポートによって、標準の A2DP、USB の繰り返し、または送信定義の再ルーティングが回避されます。
  • ボリューム カーブはカスタマイズ可能です。以前は、ボリューム テーブルがハード コーディングされていました。XML 形式ではボリューム テーブルを記述するため、カスタマイズが可能です。

frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml のテンプレートには、これらの機能の実際の使用例が示されています。

ファイル形式と場所

新しいオーディオ ポリシー設定ファイルは audio_policy_configuration.xml で、/system/etc にあります。次の例は、XML ファイル形式の単純なオーディオ ポリシー設定を示しています。

最上位の構造にはそれぞれのオーディオ HAL ハードウェア モジュールに対応するモジュールが含まれており、各モジュールは、ミックスポート、デバイスポート、およびルートのリストを持ちます。

  • ミックスポートは、再生およびキャプチャのためにオーディオ HAL で開くことが可能な、ストリーム用の構成プロファイルについて記述します。
  • デバイスポートは、各デバイスタイプで接続可能なデバイスを記述します(必要に応じて、アドレスやオーディオ プロパティも指定できます)。
  • ルートは、ミックスポート記述子とは別に、デバイス対デバイス、ストリーム対デバイスのルートの記述を行います。

ボリューム テーブルとは、UI インデックスから dB にボリュームを変換するための曲線を定義するポイントを含んだ単純なリストです。独立したインクルード ファイルはデフォルトの曲線を持ちますが、特定のユースケースやデバイス カテゴリの各曲線は上書きできます。

ファイルのインクルージョン

XML インクルージョン(XInclude)メソッドを使用して、他の XML ファイルにあるオーディオ ポリシー設定情報をインクルードすることができます。インクルードするすべてのファイルは上記の構造に準拠している必要がありますが、次の制限があります。

  • ファイルには上位レベル要素のみを含めることができます。
  • ファイルに XInclude 要素を含めることはできません。

インクルードを使用して、標準の Android オープンソース プロジェクト(AOSP)のオーディオ HAL モジュールの構成情報を、すべてのオーディオ ポリシー構成ファイルにコピーしないようにします(エラーが発生しやすいため)。標準オーディオ ポリシー設定 XML ファイルは、次のオーディオ HAL 用に用意されています。

  • A2DP: a2dp_audio_policy_configuration.xml
  • サブミックスの再ルーティング: rsubmix_audio_policy_configuration.xml
  • USB: usb_audio_policy_configuration.xml

オーディオ ポリシー コードの構成

AudioPolicyManager.cpp はいくつかのモジュールに分割されているため、メンテナンスや構成が容易です。frameworks/av/services/audiopolicy の構成には、次のモジュールが含まれます。

モジュール 説明
/managerdefault すべてのアプリに共通の一般的なインターフェースと動作の実装が含まれます。エンジン機能と抽象化された共通概念を備える AudioPolicyManager.cpp に類似しています。
/common 基本クラス(入出力オーディオ ストリーム プロファイルのデータ構造、オーディオ デバイス記述子、オーディオ パッチ、オーディオ ポートなど)を定義します。これは、以前は AudioPolicyManager.cpp 内で定義されていました。
/engine

特定のユースケースで使用するデバイスおよびボリュームを定義するルールを実装します。特定のユースケースの再生またはキャプチャに適したデバイスを取得する、接続デバイスまたは外部ステート(強制使用の呼び出し状態)を設定するなど、ルーティング決定の変更を伴い得るような、汎用部分との標準インターフェースを実装します。

構成可能デフォルトの 2 つのバージョンがあります。バージョンの選択方法については、パラメータ フレームワークを使用した構成をご覧ください。

/engineconfigurable パラメータ フレームワーク(下記参照)に依存するポリシー エンジンの実装です。 設定はパラメータ フレームワークに基づいており、ポリシーは XML ファイルで定義されています。
/enginedefault 以前の Android オーディオ ポリシー マネージャーの実装に基づくポリシー エンジンの実装。この実装はデフォルトで、Nexus および AOSP の実装に対応するハード コーディングされたルールが含まれます。
/service フレームワークの他の部分へのインターフェースを備えた、バインダー インターフェース、スレッド化、ロッキングの実装を含みます。

パラメータ フレームワークを使用した構成

オーディオ ポリシー コードは、構成ファイルで完全に定義されたオーディオ ポリシーをサポートすると同時に、理解やメンテナンスがしやすいように編成されています。構成やオーディオ ポリシーの設計は、パラメータを処理するためのプラグインベースおよびルールベースのフレームワークである Intel のパラメータ フレームワークに基づいています。

ベンダー OEM は、設定可能なオーディオ ポリシーを使用して次のことが行えます。

  • システムの構造とそのパラメータを XML で記述する。
  • 記述されたパラメータにアクセスするためのバックエンド(プラグイン)を作成(C++ で)するか、再利用する。
  • パラメータが特定の値を取る必要がある条件やルールを定義(XML またはドメイン固有の言語で)する。

AOSP には、Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml で Parameter Framework を使用するオーディオ ポリシー設定ファイルの例が含まれています。詳細については、パラメータ フレームワークに関する Intel のドキュメントをご覧ください。

Android 10 以前では、ビルド オプション USE_CONFIGURABLE_AUDIO_POLICY を使用して、構成可能なオーディオ ポリシーを選択します。Android 11 以降では、audio_policy_configuration.xml ファイルでオーディオ ポリシー エンジンのバージョンを選択します。構成可能なオーディオ ポリシー エンジンを選択するには、次の例に示すように、globalConfiguration 要素の engine_library 属性の値を configurable に設定します。

<audioPolicyConfiguration>
    <globalConfiguration engine_library="configurable" />
...
</audioPolicyConfiguration>

オーディオ ポリシー ルーティング API

Android 6.0 では、パブリックの列挙および選択 API が導入されました。これは、オーディオ パッチ / オーディオ ポート インフラストラクチャ上にあり、アプリ デベロッパーが、接続されたオーディオ レコードまたはトラックに対して優先すべきデバイス出力または入力を指定できるようになっていました。

Android 7.0 では、列挙および選択 API は CTS テストにより検証され、ネイティブ C/C++(OpenSL ES)オーディオ ストリームのルーティングを含むように拡張されています。 ネイティブ ストリームのルーティングは Java で引き続き実行されますが、AudioTrack クラスと AudioRecord クラスに固有だった明示的なルーティング メソッドを廃止し、これより優先され、これらを統合する AudioRouting インターフェースが追加されています。

列挙および選択 API の詳細については、Android 構成インターフェースおよび OpenSLES_AndroidConfiguration.h をご覧ください。 オーディオ ルーティングの詳細については、AudioRouting をご覧ください。

マルチチャンネル サポート

ハードウェアとドライバで HDMI 経由のマルチチャンネル オーディオがサポートされている場合、オーディオ ストリームをオーディオ ハードウェアに直接出力できます(2 チャンネルにダウンミックスされることのないよう、AudioFlinger ミキサーをバイパスします)。オーディオ HAL で、出力ストリーム プロファイルがマルチチャンネル オーディオ機能をサポートしているかどうかを公開する必要があります。HAL でその機能を公開している場合、デフォルトのポリシー マネージャーによって HDMI 経由のマルチチャンネル再生が許可されます。実装の詳細については、device/samsung/tuna/audio/audio_hw.c をご覧ください。

デバイスにマルチチャンネル オーディオ出力が含まれることを指定するには、オーディオ ポリシー構成ファイルを編集して、デバイスのマルチチャンネル出力を記述します。次の frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml の例は、動的なチャンネル マスクを示しています。ここでいう「動的」とは、オーディオ ポリシー マネージャーが、HDMI シンクがサポートするチャンネル マスクのクエリを接続後に実行することを意味します。

AUDIO_CHANNEL_OUT_5POINT1 などの静的チャンネル マスクを指定することもできます。AudioFlinger のミキサーは、マルチチャンネル オーディオをサポートしていないオーディオ デバイスに送信されると、自動的にコンテンツをステレオにダウンミックスします。

メディア コーデック

ハードウェアとドライバでサポートされているオーディオ コーデックが、デバイスに対して適切に宣言されていることを確認してください。詳細については、フレームワークにコーデックを公開するをご覧ください。