Android 互換性定義ドキュメントの変更履歴

Android 14

2024 年 6 月 26 日

2. デバイスタイプ

3. ソフトウェア

  • 3.2.2. ビルド パラメータ:

    ODM_SKU パラメータ:

    改訂を確認する

    このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 ^([0-9A-Za-z.,_-]+)$ と一致しなければなりません。

5. マルチメディアの互換性

  • 5.1.3. オーディオ コーデックの詳細:

    Vorbis 形式 / コーデックの詳細を追加しました。

    改訂を確認する

    デコード: サンプリング レート 8,000、12,000、16,000、24,000、48,000 Hz のモノラル、ステレオ、5.0、5.1 のコンテンツをサポート。
    エンコード: サンプリング レート 8,000、12,000、16,000、24,000、48,000 Hz のモノラル、ステレオのコンテンツをサポート。

7. ハードウェアの互換性

  • 7.1.4.2 Vulkan:

    改訂を確認する

  • 7.7.1. USB ペリフェラル モード:

    削除しました。

    改訂を確認する

    • Android Open Accessory プロトコル 2.0 のドキュメントに記載されている AOAv2 オーディオを実装すべきではありません。AOAv2 オーディオは Android バージョン 8.0（API レベル 26）でサポートが終了しました。

9. セキュリティ モデルの互換性

  • 9.7. セキュリティ機能:

    [C-SR-1] を [C-SR-7] に改番し、内容の重複を解消しました。[C-SR-8] を削除しました。

    改訂を確認する

    • [C-SR-1] 初期化中にのみ書き込まれるカーネルデータを、初期化後に読み取り専用としてマークして維持することが強く推奨されます（例: __ro_after_init）。

    • [C-SR-2] カーネルコードとメモリのレイアウトをランダム化し、ランダム化を損なうような公開を避けることが強く推奨されます（例: /chosen/kaslr-seed Device Tree node または EFI_RNG_PROTOCOL を介したブートローダー エントロピーによる CONFIG_RANDOMIZE_BASE）。

    • [C-SR-3] カーネルで制御フロー整合性（CFI）を有効にして、コード再利用攻撃からの保護を強化することが強く推奨されます（例: CONFIG_CFI_CLANG と CONFIG_SHADOW_CALL_STACK）。

    • [C-SR-4] 制御フロー整合性（CFI）、シャドー コールスタック（SCS）、または整数オーバーフロー サニタイズ（IntSan）を有効にしているコンポーネントでは、無効にしないことが強く推奨されます。

    • [C-SR-5] CFI と IntSan に記載されているとおり、セキュリティに注意を要する追加のユーザー空間コンポーネントのために、CFI、SCS、IntSan を有効にすることが強く推奨されます。

    • [C-SR-6] 初期化されていないローカル変数の使用を防ぐために、カーネルでスタック初期化を有効にすることが強く推奨されます（CONFIG_INIT_STACK_ALL または CONFIG_INIT_STACK_ALL_ZERO）。また、デバイス実装は、コンパイラがローカル変数を初期化するために使用する値を仮定すべきではありません。

    • [C-SR-7] 初期化されていないヒープ割り当ての使用を防ぐために、カーネルでヒープ初期化を有効にすることが強く推奨されます（CONFIG_INIT_ON_ALLOC_DEFAULT_ON）。また、デバイス実装は、カーネルがヒープ割り当てを初期化するために使用する値を仮定すべきではありません。

  • 9.11. 鍵と認証情報:

    改訂を確認する

    • [C-1-6] 次のいずれかをサポートしなければなりません。
      • IKeymasterDevice 3.0、
      • IKeymasterDevice 4.0、
      • IKeymasterDevice 4.1、
      • IKeyMintDevice version 1、または
      • IKeyMintDevice version 2。

  • 9.11.1. セキュアロック画面、認証、仮想デバイス:

    改訂を確認する

    • [C-8-3] サードパーティ アプリがロック状態を変更するために使用する API を公開してはなりません。

    改訂を確認する

    • [C-12-4] TrustManagerService.revokeTrust() を呼び出さなければなりません。
      • 信頼を付与してから最長 24 時間後、
      • 8 時間のアイドル時間枠後、または
      • 近接する物理デバイスへの基礎的な接続が失われたときに、[C-12-5] で定義されている、暗号論的に安全で正確な範囲を実装が使用していない場合。
    • [C-12-5] [C-12-4] の要件を満たすために、安全で正確な範囲に依存している実装は、次のいずれかの解決策を使用しなければなりません。
      • UWB を使用している実装は:
        • 7.4.9 で規定されている、UWB の適合、認証、精度、キャリブレーションに関する要件を満たさなければなりません。
        • 7.4.9 に記載されている、いずれかの P-STS セキュリティ モデルを使用しなければなりません。
      • Wi-Fi Neighborhood Awareness Networking（NAN）を使用する実装は:
        • 2.2.1 [7.4.2.5/H-SR-1] の精度に関する要件を満たし、160 MHz 以上の帯域幅を使用し、かつプレゼンス キャリブレーションで規定されている計測方法のセットアップ手順に沿わなければなりません。
        • IEEE 802.11az で定義されている Secure LTF を使用しなければなりません。

2024 年 4 月 8 日

2. デバイスタイプ

  • 2.2.1. ハードウェア:

    改訂を確認する

    新しい要件の開始

    FEATURE_BLUETOOTH_LE を宣言する場合、ハンドヘルド デバイス実装は:

    • [7.4.3/H-1-3] ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -50 dBm +/-15 dB になるように、Rx オフセットを測定し補正しなければなりません。
    • [7.4.3/H-1-4] 1 m の距離に位置し、ADVERTISE_TX_POWER_HIGH で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -50 dBm +/-15 dB になるように、Tx オフセットを測定し補正しなければなりません。

  • 2.2.5. セキュリティ モデル:

    改訂を確認する

    System API HotwordDetectionService、またはマイクへのアクセスを示さない起動ワード検出の別のメカニズムをサポートする場合、ハンドヘルド デバイス実装は:

    • [9.8/H-1-6] 成功した各起動ワード結果について、100 バイトを超えるデータを起動ワード検出サービスから送信できるようにしてはなりません。ただし、HotwordAudioStream を介して渡されたオーディオ データは除きます。

    改訂を確認する

    [9.8/H-1-13] を以下に変更:

    • [9.8/H-SR-3] 起動ワード検出サービスをホストするプロセスを、少なくとも 1 時間に 1 回、またはハードウェア トリガー イベント 30 回ごとに（どちらか早い方）、再起動することが強く推奨されます。

    改訂を確認する

    [9.8.2/H-4-3]、[9.8.2/H-4-4]、[9.8.2/H-5-3] の要件を削除しました。

  • 2.2.7.2. カメラ:

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.U を返す場合、ハンドヘルド デバイス実装は:

    • [7.5/H-1-3] プライマリ背面カメラについては FULL 以上の android.info.supportedHardwareLevel プロパティをサポートし、プライマリ前面カメラについては LIMITED 以上の同プロパティをサポートしなければなりません。

  • 2.3.2. マルチメディア:

    改訂を確認する

    内蔵ディスプレイはないが、HDMI 経由で接続される外部ディスプレイをサポートする場合、テレビデバイス実装は:

    • [5.8/T-0-1] デバイスが販売されている地域のリフレッシュ レートに応じて、外部ディスプレイが 50 Hz または 60 Hz のリフレッシュ レートで動作する、選択したピクセル フォーマットの最高解像度に HDMI 出力モードを設定しなければなりません。50 Hz または 60 Hz のリフレッシュ レートでサポートできる最大解像度を選択するように HDMI 出力モードを設定しなければなりません。

3. ソフトウェア

5. マルチメディアの互換性

  • 5.3.8. ドルビー ビジョン:

    改訂を確認する

    HDR_TYPE_DOLBY_VISION を通じてドルビー ビジョン デコーダのサポートを宣言する場合、デバイス実装は:

    • [C-1-3] 下位互換性のあるベースレイヤ（存在する場合）のトラック ID を、結合したドルビー ビジョンレイヤのトラック ID と同じに設定しなければなりません。

7. ハードウェアの互換性

  • 7.1.1.1. 画面サイズと形状:

    改訂を確認する

    UI_MODE_TYPE_NORMALサイズ構成が可能な画面をサポートし、隅の丸い物理ディスプレイを使用して画面をレンダリングする場合、デバイス実装は:

    • [C-1-1] 各ディスプレイで次の要件のうち少なくとも 1 つを満たさなければなりません。
      • 1518 dp x 1518 dp のボックスを論理ディスプレイのそれぞれの隅に固定したとき、各ボックスの少なくとも 1 ピクセルが画面に表示される。

  • 7.4.3. Bluetooth:

    改訂を確認する

    次の要件を復活させました。

    FEATURE_BLUETOOTH_LE を宣言する場合、デバイス実装は:

    • [C-SR-2] ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -60 dBm +/-10 dB になるように、Rx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。

    • [C-SR-3] 1 m の距離に位置し、ADVERTISE_TX_POWER_HIGH で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -60dBm +/-10 dB になるように、Tx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。

    改訂を確認する

    要件 [C-10-3]、[C-10-4] を 2.2.1. ハードウェアに移動しました。

    • [C-10-3] ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -55 dBm +/-10 dB になるように、Rx オフセットを測定し補正しなければなりません。
    • [C-10-4] 1 m の距離に位置し、ADVERTISE_TX_POWER_HIGH で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -55 dBm +/-10 dB になるように、Tx オフセットを測定し補正しなければなりません。

2023 年 11 月 20 日

2. デバイスタイプ

  • 2.2.1. ハードウェア:

    改訂を確認する

    （32 ビット ABI の有無にかかわらず）64 ビット ABI のサポートを宣言する場合、ハンドヘルド デバイス実装は:

  • 2.2.7.2. カメラ:

    改訂を確認する

    • [7.5/H-1-13] 背面 RGB カメラが 1 つ以上ある場合、プライマリ背面カメラで LOGICAL_MULTI_CAMERA 機能をサポートしなければなりません。

  • 2.3.2. マルチメディア:

    改訂を確認する

    • [5.8/T-0-1] 外部ディスプレイが 50 Hz または 60 Hz のリフレッシュ レートで動作する、選択した SDR もしくは HDR フォーマットの最高解像度に HDMI 出力モードを設定しなければなりません。

      50 Hz または 60 Hz のリフレッシュ レートでサポートできる最大解像度を選択するように HDMI 出力モードを設定しなければなりません。

  • 2.4.5. セキュリティ モデル:

    改訂を確認する

    • [9/W-0-1] android.hardware.security.model.compatible feature を宣言しなければなりません。

6. デベロッパー ツール、開発者向けオプションの互換性

  • 6.1. デベロッパー ツール:

    改訂を確認する

    • [C-0-12] LMK_KILL_OCCURRED_FIELD_NUMBER Atom を書き込まなければなりません。

    改訂を確認する

    • [C-0-13] 表示するよう、シェルコマンド dumpsys gpu --gpuwork を実装しなければなりません

9. セキュリティ モデルの互換性

  • 9.7. セキュリティ機能:

    改訂を確認する

    SELinux をサポートできる Linux カーネルを使用する場合、デバイス実装は:

    改訂を確認する

    Linux 以外のカーネルもしくは SELinux のない Linux を使用する場合、デバイス実装は:

2023 年 10 月 4 日

2. デバイスタイプ

  • 2.2. ハンドヘルドの要件:

    改訂を確認する

    次の基準をすべて満たす場合、Android デバイス実装はハンドヘルドに分類されます。

    • 物理的な対角画面サイズが 4 インチ 3.3 インチ（API レベル 29 以前で出荷されたデバイス実装の場合は 2.5 インチ）から 8 インチの範囲内。

    新しい要件の開始

    • タッチスクリーン入力インターフェースがある。

  • 2.2.1. ハードウェア:

    改訂を確認する

    ハンドヘルド デバイス実装は:

    • [7.1.1.1/H-0-1] このドキュメントに記載されている要件をすべて満たす Android 互換ディスプレイ少なくとも短辺 2.2 インチ、長辺 3.4 インチのディスプレイを少なくとも 1 つ備えなければなりません。

    ソフトウェアの画面回転をサポートする場合、ハンドヘルド デバイス実装は:

    • [7.1.1.1/H-1-1]* サードパーティ アプリで利用できるようにする論理画面を、少なくとも短辺 2 インチ、長辺 2.7 インチにしなければなりません。Android API レベル 29 以前で出荷されたデバイスについては、この要件を免除しても構いません。

    ソフトウェアの画面回転をサポートしない場合、ハンドヘルド デバイス実装は:

    • [7.1.1.1/H-2-1]* サードパーティ アプリで利用できるようにする論理画面を、少なくとも短辺 2.7 インチにしなければなりません。Android API レベル 29 以前で出荷されたデバイスについては、この要件を免除しても構いません。

    新しい要件の開始

    • [7.1.1.1/H-0-3]* サードパーティ アプリで利用できるようにする各 UI_MODE_NORMAL ディスプレイを、少なくとも短辺 2.2 インチ、長辺 3.4 インチの遮蔽されていない物理的な表示領域内にマッピングしなければなりません。

    • [7.1.1.3/H-0-1]* DENSITY_DEVICE_STABLE の値は、92% または実際の対応ディスプレイの物理密度よりも大きく設定しなければなりません。

    android.hardware.audio.output と android.hardware.microphone を宣言する場合、ハンドヘルド デバイス実装は:

    • [5.6/H-1-1] 「スピーカーからマイク」、3.5 mm ループバック アダプター（サポートされている場合）、USB ループバック（サポートされている場合）のデータパスにおいて、5 回の測定での平均連続ラウンドトリップ レイテンシが 300 ミリ秒以下、平均絶対偏差が 30 ミリ秒未満でなければなりません。

    • [5.6/H-1-2] スピーカーからマイクへのデータパスで、少なくとも 5 回の測定での平均タップツートーン レイテンシが 300 ミリ秒以下でなければなりません。

    触覚アクチュエータが 1 つ以上含まれる場合、ハンドヘルド デバイス実装は:

    少なくとも 1 つの汎用 7.10 リニア共振アクチュエータが含まれる場合、ハンドヘルド デバイス実装は:

    • [7.10/H] デバイスを手で通常持つか触れる場所の近くにアクチュエータを配置すべきです。

    • [7.10/H] 触覚アクチュエータをデバイスの自然な向きの縦向き画面の X 軸（左右）で動かすべきです。

    汎用触覚アクチュエータが含まれていて、それが X 軸のリニア共振アクチュエータ（LRA）である場合、ハンドヘルド デバイス実装は:

    • [7.10/H] X 軸の LRA の共振周波数を 200 Hz 未満にすべきです。

  • 2.2.2. マルチメディア:

    改訂を確認する

    ハンドヘルド デバイス実装は、次の形式の動画エンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。

    • [5.2/H-0-3] AV1

    ハンドヘルド デバイス実装は、次の形式の動画デコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。

    • [5.3/H-0-6] AV1

  • 2.2.3. ソフトウェア:

    改訂を確認する

    セクション 7.2.3 で詳述するように、履歴機能のナビゲーション キーが含まれ、インターフェースを変更する場合、デバイス実装は:

    • [3.8.3/H-1-1] 画面固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。

    ControlsProviderService API と Control API のサポートが含まれ、サードパーティ アプリがデバイス コントロールをパブリッシュできるようにする場合、ハンドヘルド デバイス実装は:

    • [3.8.16/H-1-6] デバイス実装は、次のとおり、ユーザー アフォーダンスを正確にレンダリングしなければなりません。
      • デバイスが config_supportsMultiWindow=true を設定し、アプリが ControlsProviderService 宣言でメタデータ META_DATA_PANEL_ACTIVITY を宣言し、有効なアクティビティの ComponentName を含む場合（API によって定義）、アプリはこのユーザー アフォーダンスに当該アクティビティを埋め込まなければなりません。
      • アプリは、メタデータ META_DATA_PANEL_ACTIVITY を宣言しない場合、ControlsProviderService API で提供される指定のフィールドと、Control API で提供される指定のフィールドをレンダリングしなければなりません。
    • [3.8.16/H-1-7] アプリは、メタデータ META_DATA_PANEL_ACTIVITY を宣言する場合、埋め込んだアクティビティの起動時に EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS を使用して、[3.8.16/H-1-5] に定められている設定の値を渡さなければなりません。

    ユーザーが任意の種類の通話をできるようにする場合、デバイス実装は:

  • 2.2.4. パフォーマンスと電力:

    改訂を確認する

    ハンドヘルド デバイス実装は:

    • [8.5/H-0-1] アクティブなフォアグラウンド サービスまたはユーザーが開始するジョブがあるすべてのアプリを確認するため、設定メニューでユーザー アフォーダンスを提供しなければなりません。これには、SDK のドキュメントに記載されている各サービスが開始してからの経過時間や、フォアグラウンド サービスまたはユーザーが開始するジョブを停止する機能が含まれます。SDK のドキュメントに記載されているとおり、設定メニューで、フォアグラウンド サービスを実行しているアプリを停止できるユーザー アフォーダンスを提供しなければなりません。また、アクティブなフォアグラウンド サービスを持つすべてのアプリを、アプリの各サービスが開始されてからの継続期間とともに表示しなければなりません。
      • SDK ドキュメントに記載されているとおり、一部のアプリはこのようなユーザー アフォーダンスでの停止または表示を免除されることがあります。

    • [8.5/H-0-2] フォアグラウンド サービスまたはユーザーが開始するジョブを実行するアプリを停止するユーザー アフォーダンスを提供しなければなりません。

  • 2.2.5. セキュリティ モデル:

    改訂を確認する

    android.hardware.telephony のサポートを宣言する場合、デバイス実装は:

    • [9.5/H-1-1] UserManager.isHeadlessSystemUserMode を true に設定してはなりません。

    セキュアロック画面があり、TrustAgentService システム API を実装する信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:

    • [9.11.1/H-1-1] 少なくとも 72 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。

    UserManager.isHeadlessSystemUserMode を true に設定している場合、ハンドヘルド デバイス実装は:

    • [9.5/H-4-1] eUICC のサポート、または通話機能のある eSIM のサポートを含めてはなりません。
    • [9.5/H-4-2] android.hardware.telephony のサポートを宣言してはなりません。

    System API HotwordDetectionService、またはマイクへのアクセスを示さない起動ワード検出の別のメカニズムをサポートする場合、ハンドヘルド デバイス実装は:

    • [9.8/H-1-1] 起動ワード検出サービスがデータを送信できる対象を、システム、ContentCaptureService、または SpeechRecognizer#createOnDeviceSpeechRecognizer() によって作成されたデバイス上の音声認識サービスに限定しなければなりません。
    • [9.8/H-1-6] 成功した各起動ワード結果について、100 バイトを超えるデータ（オーディオ ストリームを除く）を起動ワード検出サービスから送信できるようにしてはなりません。

    • [9.8/H-1-15] 成功した起動ワード結果で提供されるオーディオ ストリームが、起動ワード検出サービスから音声操作サービスへの一方向で送信されるようにしなければなりません。

    システム API HotwordDetectionService や、マイクの使用を示さず同様の起動ワード検出メカニズムを使用するアプリがデバイス実装に含まれる場合、そのアプリは:

    • [9.8/H-2-3] 起動ワード検出サービスから、ContentCaptureService、またはデバイス上の音声認識サービスを除き、音声データ、音声の（全体的もしくは部分的）再構築に使用できるデータ、または起動ワード自体とは関係のないオーディオ コンテンツを送信してはなりません。

    システム API VisualQueryDetectionService、または、マイクやカメラへのアクセスを示さないクエリ検出の別のメカニズムをサポートする場合、ハンドヘルド デバイス実装は:

    • [9.8/H-3-1] クエリ検出サービスがデータを送信できる対象を、システム、ContentCaptureService、またはデバイス上の音声認識サービス（SpeechRecognizer#createOnDeviceSpeechRecognizer() によって作成されるサービス）に限定しなければなりません。
    • [9.8/H-3-2] ContentCaptureService またはデバイス上の音声認識サービスを除き、音声情報または動画情報を VisualQueryDetectionService から送信できるようにしてはなりません。
    • [9.8/H-3-3] デジタル アシスタント アプリを使用しようとするユーザーの意図をデバイスが検出したとき（カメラを介してユーザーの存在を検出したときなど）は、システム UI にユーザー通知を表示しなければなりません。
    • [9.8/H-3-4] ユーザークエリが検出された直後に、マイク インジケーターを表示し、検出されたユーザークエリを UI に表示しなければなりません。
    • [9.8/H-3-5] ユーザーがインストール可能なアプリが、ビジュアル クエリ検出サービスを提供できるようにしてはなりません。

  • 2.2.7.1. メディア:

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.T を返す場合、ハンドヘルド デバイス実装は:

    新しい要件の開始

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.U を返す場合、ハンドヘルド デバイス実装は:

    • [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() メソッドと VideoCapabilities.getSupportedPerformancePoints() メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画デコーダ セッションの最大数をアドバタイズしなければなりません。
    • [5.1/H-1-2] 任意のコーデックの組み合わせ（AVC、HEVC、VP9、AV1 以降）の 8 ビット（SDR）ハードウェア動画デコーダ セッションの 6 インスタンスの同時実行を、3 セッションは解像度 1080p、30 fps で、残り 3 セッションは解像度 4K、30 fps でサポートしなければなりません（AV1 を除く）。AV1 コーデックでは、解像度 1080p のサポートのみが必要ですが、解像度 1080p、30 fps で 6 インスタンスをサポートする必要があります。
    • [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() メソッドと VideoCapabilities.getSupportedPerformancePoints() メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画エンコーダ セッションの最大数をアドバタイズしなければなりません。
    • [5.1/H-1-4] 任意のコーデックの組み合わせ（AVC、HEVC、VP9、AV1 以降）の 8 ビット（SDR）ハードウェア動画エンコーダ セッションの 6 インスタンスの同時実行を、4 セッションは解像度 1080p、30 fps で、残り 2 セッションは解像度 4K、30 fps でサポートしなければなりません（AV1 を除く）。AV1 コーデックでは、解像度 1080p のサポートのみが必要ですが、解像度 1080p、30 fps で 6 インスタンスをサポートする必要があります。
    • [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() メソッドと VideoCapabilities.getSupportedPerformancePoints() メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画エンコーダ セッションとハードウェア動画デコーダ セッションの最大数をアドバタイズしなければなりません。
    • [5.1/H-1-6] 任意のコーデックの組み合わせ（AVC、HEVC、VP9、AV1 以降）の 8 ビット（SDR）ハードウェア動画デコーダ セッションとハードウェア動画エンコーダ セッションの 6 インスタンスの同時実行を、3 セッション（そのうちエンコーダ セッションは最大 2 つ）は解像度 4K、30 fps で（AV1 を除く）、残り 3 セッションは解像度 1080p でサポートしなければなりません。AV1 コーデックでは、解像度 1080p のサポートのみが必要ですが、解像度 1080p、30 fps で 6 インスタンスをサポートする必要があります。
    • [5.1/H-1-19] 任意のコーデックの組み合わせ（AVC、HEVC、VP9、AV1 以降）の 10 ビット（HDR）ハードウェア動画デコーダ セッションとハードウェア動画エンコーダ セッションの 3 インスタンスの同時実行を、解像度 4K、30 fps でサポートしなければなりません（AV1 を除く）。そのうちエンコーダ セッションは最大 1 つで、GL サーフェスから RGBA_1010102 入力形式で設定可能です。GL サーフェスからエンコードする場合、エンコーダによる HDR メタデータの生成は不要です。AV1 コーデック セッションでは、要件が解像度 4K であっても、解像度 1080p のサポートのみが必要です。
    • [5.1/H-1-7] 負荷がかかった状態で、すべてのハードウェア動画エンコーダの 1080p 以下の動画エンコード セッションについて、コーデック初期化レイテンシが 40 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像記録の初期化を同時実行することを指します。ドルビー ビジョン コーデックでは、コーデック初期化レイテンシは 50 ms 以下でなければなりません。
    • [5.1/H-1-8] 負荷がかかった状態で、すべての音声エンコーダでのビットレート 128 kbps 以下の音声エンコード セッションについて、コーデック初期化レイテンシが 30 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像記録の初期化を同時実行することを指します。
    • [5.1/H-1-9] 8 ビット（SDR）と 10 ビット HDR の両方のコンテンツについて、解像度 4K、30 fps で（AV1 を除く）同時に実行されるコーデックの組み合わせで、セキュアなハードウェア動画デコーダ セッション（AVC、HEVC、VP9、AV1 以降）の 2 つのインスタンスをサポートしなければなりません。AV1 コーデック セッションでは、要件が解像度 4K であっても、解像度 1080p のサポートのみが必要です。
    • [5.1/H-1-10] 同時に実行される任意のコーデックの組み合わせで、セキュアでないハードウェア動画デコーダ セッションの 3 つのインスタンスと、セキュアなハードウェア動画デコーダ セッションの 1 つのインスタンス（合計 4 つのインスタンス。AVC、HEVC、VP9、AV1 以降）をサポートしなければなりません。3 つのセッション（1 つのセキュアなデコーダ セッションを含む）は解像度 4K、30 fps で（AV1 を除く）、1 つのセキュアでないセッションは解像度 1080p、30 fps です。最大 2 つのセッションを 10 ビット HDR にできます。AV1 コーデック セッションでは、要件が解像度 4K であっても、解像度 1080p のサポートのみが必要です。
    • [5.1/H-1-11] デバイス上のすべてのハードウェア AVC、HEVC、VP9、AV1 デコーダについて、セキュアなデコーダをサポートしなければなりません。
    • [5.1/H-1-12] 負荷がかかった状態で、すべてのハードウェア動画デコーダの 1080p 以下の動画デコード セッションについて、コーデック初期化レイテンシが 40 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像再生の初期化を同時実行することを指します。ドルビー ビジョン コーデックでは、コーデック初期化レイテンシは 50 ms 以下でなければなりません。
    • [5.1/H-1-13] 負荷がかかった状態で、すべての音声デコーダでのビットレート 128 kbps 以下の音声デコード セッションについて、コーデック初期化レイテンシが 30 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像再生の初期化を同時実行することを指します。
    • [5.1/H-1-14] AV1 ハードウェア デコーダのメイン 10、レベル 4.1、フィルム グレインをサポートしなければなりません。
    • [5.1/H-1-15] 4K60 をサポートするハードウェア動画デコーダを少なくとも 1 つ備えなければなりません。
    • [5.1/H-1-16] 4K60 をサポートするハードウェア動画エンコーダを少なくとも 1 つ備えなければなりません。
    • [5.3/H-1-1] 負荷時の 4K 60 fps の動画セッションで、10 秒間に 1 フレームを超えるドロップが発生してはなりません（フレーム ドロップ 0.167% 未満）。
    • [5.3/H-1-2] 4K セッションの負荷時の 60 fps の動画セッションで、動画解像度の変更中、10 秒間に 1 フレームを超えるドロップが発生してはなりません。
    • [5.6/H-1-1] CTS 検証ツールのタップツートーン テストを使用して、タップツートーン レイテンシを 80 ミリ秒以下にしなければなりません。
    • [5.6/H-1-2] 少なくとも 1 つのサポート対象データパスで、ラウンドトリップ オーディオ レイテンシを 80 ミリ秒以下にしなければなりません。
    • [5.6/H-1-3] 3.5 mm オーディオ ジャック（存在する場合）および USB オーディオ（サポートされる場合）のステレオ出力については、低レイテンシ構成およびストリーミング構成のデータパス全体を通じて 24 ビット以上をサポートしなければなりません。低レイテンシ構成の場合、アプリは AAudio を低レイテンシ コールバック モードで使用すべきです。ストリーミング構成の場合、アプリは Java AudioTrack を使用すべきです。低レイテンシ構成とストリーミング構成の両方で、HAL 出力シンクはターゲット出力形式として AUDIO_FORMAT_PCM_24_BIT、AUDIO_FORMAT_PCM_24_BIT_PACKED、AUDIO_FORMAT_PCM_32_BIT、AUDIO_FORMAT_PCM_FLOAT のいずれかを受け入れるべきです。
    • [5.6/H-1-4] 4 チャンネル以上の USB オーディオ デバイスをサポートしなければなりません（曲をプレビューするために DJ コントローラで使用されます）。
    • [5.6/H-1-5] クラス準拠の MIDI デバイスをサポートし、MIDI 機能フラグを宣言しなければなりません。
    • [5.6/H-1-9] 少なくとも 12 チャンネルのミキシングをサポートしなければなりません。これは 7.1.4 チャンネル マスクを使用して AudioTrack を開き、すべてのチャンネルをステレオに適切に空間化またはダウンミックスできることを意味します。
    • [5.6/H-SR] 少なくとも 9.1.6 チャンネル マスクと 22.2 チャンネル マスクに対応している 24 チャンネル ミキシングをサポートすることが強く推奨されます。
    • [5.7/H-1-2] 次のコンテンツ復号機能で、MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL をサポートしなければなりません。
    最小サンプルサイズ 4 MiB
    サブサンプルの最小数 - H264 または HEVC 32
    サブサンプルの最小数 - VP9 9
    サブサンプルの最小数 - AV1 288
    サブサンプルの最小バッファサイズ 1 MiB
    汎用暗号の最小バッファサイズ 500 KiB
    同時実行セッションの最小数 30
    セッションあたりの鍵の最小数 20
    鍵の最小合計数（すべてのセッション） 80
    DRM 鍵の最小合計数（すべてのセッション） 6
    メッセージ サイズ 16 KiB
    復号されたフレーム/秒 60 fps
    • [5.1/H-1-17] AVIF ベースライン プロファイルをサポートする少なくとも 1 つのハードウェア画像デコーダがなければなりません。
    • [5.1/H-1-18] 30 fps と 1 Mbps で最大 480p の解像度をエンコードできる AV1 エンコーダをサポートしなければなりません。
    • [5.12/H-1-1] 必須 [5.12/H-SR] デバイス上にあるすべてのハードウェア AV1 および HEVC エンコーダの Feature_HdrEditing 機能をサポートすることを強く推奨します。
    • [5.12/H-1-2] デバイス上にあるすべてのハードウェア AV1 エンコーダと HEVC エンコーダで RGBA_1010102 カラー形式をサポートしなければなりません。
    • [5.12/H-1-3] 8 ビットと 10 ビットの両方で YUV テクスチャからサンプリングするために、EXT_YUV_target 拡張機能のサポートをアドバタイズしなければなりません。
    • [7.1.4/H-1-1] データ処理ユニット（DPU）Hardware Composer（HWC）に少なくとも 6 つのハードウェア オーバーレイがなければならず、そのうち 2 つ以上で 10 ビットの動画コンテンツを表示できなければなりません。

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.U を返し、ハードウェア AVC または HEVC エンコーダのサポートが含まれる場合、ハンドヘルド デバイス実装は:

    • [5.2/H-2-1] 今後提供されるドキュメントで定義されるように、ハードウェア AVC または HEVC コーデックの動画エンコーダのレート歪み曲線で規定されている最低品質目標を満たさなければなりません。

  • 2.2.7.2. カメラ:

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.U を返す場合、ハンドヘルド デバイス実装は:

    • [7.5/H-1-1] 4K、30 fps での動画キャプチャをサポートする、解像度 12 メガピクセル以上のプライマリ背面カメラがなければなりません。プライマリ背面カメラとは、カメラ ID が最も低い背面カメラのことです。
    • [7.5/H-1-2] 解像度 6 メガピクセル以上のプライマリ前面カメラがなければならず、1080p、30 fps での動画キャプチャをサポートしなければなりません。プライマリ前面カメラとは、カメラ ID が最も低い前面カメラのことです。
    • [7.5/H-1-3] 両方のプライマリ カメラについて、FULL 以上の android.info.supportedHardwareLevel プロパティをサポートしなければなりません。
    • [7.5/H-1-4] 両方のプライマリ カメラについて、CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME をサポートしなければなりません。
    • [7.5/H-1-5] 両方のプライマリ カメラについて、ITS 照明条件（3000K）で CTS カメラの PerformanceTest によって測定したとき、解像度 1080p の camera2 JPEG キャプチャ レイテンシが 1,000 900 ms 未満でなければなりません。
    • [7.5/H-1-6] 両方のプライマリ カメラについて、ITS 照明条件（3000K）で CTS カメラの PerformanceTest によって測定したとき、camera2 起動レイテンシ（カメラを開いてから最初のプレビュー フレームまで）が 500 ms 未満でなければなりません。
    • [7.5/H-1-8] プライマリ背面カメラについて、CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW と android.graphics.ImageFormat.RAW_SENSOR をサポートしなければなりません。
    • [7.5/H-1-9] 720p または 1080p、240 fps をサポートするプライマリ背面カメラがなければなりません。
    • [7.5/H-1-10] 同じ方向を向いたウルトラワイド RGB カメラが 1 つある場合、プライマリ カメラの最小 ZOOM_RATIO は 1.0 未満でなければなりません。
    • [7.5/H-1-11] プライマリ カメラに前面および背面での同時ストリーミングを実装しなければなりません。
    • [7.5/H-1-12] プライマリ前面カメラとプライマリ背面カメラの両方で CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION をサポートしなければなりません。
    • [7.5/H-1-13] 同じ方向を向いた RGB カメラが 1 つ以上ある場合、プライマリ カメラで LOGICAL_MULTI_CAMERA 機能をサポートしなければなりません。
    • [7.5/H-1-14] プライマリ前面カメラとプライマリ背面カメラの両方で STREAM_USE_CASE 機能をサポートしなければなりません。
    • [7.5/H-1-15] プライマリ カメラについて、CameraX 拡張機能と Camera2 拡張機能の両方を介して、ボケ表現拡張機能と夜間モード拡張機能をサポートしなければなりません。
    • [7.5/H-1-16] プライマリ カメラについて DYNAMIC_RANGE_TEN_BIT 機能をサポートしなければなりません。
    • [7.5/H-1-17] プライマリ カメラについて CONTROL_SCENE_MODE_FACE_PRIORITY 機能と顔検出機能（STATISTICS_FACE_DETECT_MODE_SIMPLE または STATISTICS_FACE_DETECT_MODE_FULL）をサポートしなければなりません。

  • 2.2.7.3. ハードウェア:

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.U を返す場合、ハンドヘルド デバイス実装は:

    • [7.1.1.1/H-2-1] 画面の解像度が少なくとも 1080p でなければなりません。
    • [7.1.1.3/H-2-1] 画面密度が少なくとも 400 dpi でなければなりません。
    • [7.1.1.3/H-3-1] 少なくとも平均 1,000 ニトをサポートする HDR ディスプレイがなければなりません。
    • [7.6.1/H-2-1] 物理メモリが少なくとも 8 GB でなければなりません。

  • 2.2.7.4. パフォーマンス:

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.U を返す場合、ハンドヘルド デバイス実装は:

    • [8.2/H-1-1] 少なくとも 150 MB/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
    • [8.2/H-1-2] 少なくとも 10 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
    • [8.2/H-1-3] 少なくとも 250 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
    • [8.2/H-1-4] 少なくとも 100 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。
    • [8.2/H-1-5] 少なくとも 50 MB/s の並列シーケンシャル読み取り / 書き込みパフォーマンス（2 つの読み取りと 1 つの書き込み）を実現しなければなりません。

  • 2.3.2. マルチメディア:

    改訂を確認する

    テレビデバイス実装は、次の形式の動画エンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。

    • [5.2/T-0-3] AV1

    テレビデバイス実装は、次の形式の動画デコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。

  • 2.4.5. セキュリティ モデル:

    改訂を確認する

    セキュアロック画面があり、TrustAgentService システム API を実装する信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:

    • [9.11.1/W-1-1] 少なくとも 72 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。

  • 2.5.1. ハードウェア:

    改訂を確認する

    AM/FM ブロードキャスト ラジオのサポートが含まれ、その機能を任意のアプリに公開する場合、デバイス実装は:

    • [7.4.10/A-0-1] FEATURE_BROADCAST_RADIO のサポートを宣言しなければなりません。

    外部ビューカメラとは、リアビュー カメラのように、デバイス実装の外部の光景を撮影するカメラのことです。

    自動車デバイス実装は:

    • 1 つ以上の外部ビューカメラを含むべきです。

    外部ビューカメラが含まれる場合、そのようなカメラについて、自動車デバイス実装は:

    • [7.5/A-1-1] カメラのコア要件を遵守している場合を除き、Android Camera API を介して外部ビューカメラにアクセス可能であってはなりません。
    • [7.5/A-SR-1] カメラ プレビューを回転または水平にミラーリングしないことが強く推奨されます。
    • [7.5/A-SR-2] 解像度が少なくとも 1.3 メガピクセルであることが強く推奨されます。
    • 固定焦点または EDOF（拡張被写界深度）のハードウェアがあるべきです。
    • ハードウェア オートフォーカス、またはカメラドライバに実装されたソフトウェア オートフォーカスを備えても構いません。

    1 つ以上の外部ビューカメラが含まれ、外部ビューシステム（EVS）サービスを読み込む場合、自動車デバイス実装はそのようなカメラについて:

    • [7.5/A-2-1] カメラ プレビューを回転または水平にミラーリングしてはなりません。

    自動車デバイス実装は:

    • サードパーティ アプリで利用できるカメラを 1 つ以上含んでも構いません。

    自動車デバイス実装は、カメラを少なくとも 1 つ含み、それをサードパーティ アプリで利用できるようにしている場合:

    • [7.5/A-3-1] 機能フラグ android.hardware.camera.any をレポートしなければなりません。
    • [7.5/A-3-2] カメラをシステムカメラとして宣言してはなりません。
    • セクション 7.5.3 に記載されている外部カメラをサポートしても構いません。
    • セクション 7.5.1 に記載されているとおり、背面カメラで利用できる機能（オートフォーカスなど）を含めても構いません。

    背面カメラとは、車両の任意の場所に設置でき、車室の外側に向いているワールド フェイシング カメラのことです。つまり、リアビュー カメラのように車体の向こう側の光景を撮影するものです。

    前面カメラとは、車両の任意の場所に設置でき、車室の内側に向いているユーザー向きカメラのことです。つまり、ビデオ会議や同様のアプリのようにユーザーを撮影するものです。

    自動車デバイス実装は:

    • [7.5/A-SR-1] 1 つ以上のワールド フェイシング カメラを含むことが強く推奨されます。
    • ユーザー向きカメラを 1 つ以上含んでも構いません。
    • [7.5/A-SR-2] 複数のカメラの同時ストリーミングをサポートすることが強く推奨されます。

    ワールド フェイシング カメラが少なくとも 1 つ含まれる場合、当該のカメラについて、自動車デバイス実装は:

    • [7.5/A-1-1] カメラの長辺が Android Automotive センサーの軸の XY 平面に沿うよう向きを合わせなければなりません。
    • [7.5/A-SR-3] 固定焦点または EDOF（拡張被写界深度）のハードウェアを備えることが強く推奨されます。
    • [7.5/A-1-2] プライマリ ワールド フェイシング カメラが、カメラ ID が最も低いワールド フェイシング カメラでなければなりません。

    自動車デバイス実装にユーザー向きカメラが 1 つ以上含まれる場合、当該のカメラについて:

    • [7.5/A-2-1] プライマリ ユーザー向きカメラは、カメラ ID が最も低いユーザー向きカメラでなければなりません。
    • カメラの長辺が Android Automotive センサーの軸の XY 平面と一致するような向きであっても構いません。

    android.hardware.Camera API または android.hardware.camera2 API を介してアクセスできるカメラが含まれる場合、自動車デバイス実装は:

    • [7.5/A-3-1] セクション 7.5 のカメラのコア要件を遵守しなければなりません。

    android.hardware.Camera API または android.hardware.camera2 API を介してアクセスできないカメラが含まれる場合、自動車デバイス実装は:

    • [7.5/A-4-1] 拡張ビューシステム サービスを介してアクセスできなければなりません。

    拡張ビューシステム サービスを介してアクセス可能なカメラが 1 つ以上含まれる場合、そのようなカメラについて、自動車デバイス実装は:

    • [7.5/A-5-1] カメラ プレビューを回転または水平にミラーリングしてはなりません。
    • [7.5/A-SR-4] 解像度が 1.3 メガピクセル以上であることが強く推奨されます。

    拡張ビューシステム サービスと android.hardware.Camera API または android.hardware.Camera2 API を介してアクセス可能なカメラが 1 つ以上含まれる場合、そのようなカメラについて、自動車デバイス実装は:

    • [7.5/A-6-1] 同じカメラ ID をレポートしなければなりません。

    独自のカメラ API を提供する場合、自動車デバイス実装は:

    • [7.5/A-7-1] 当該のカメラ API を android.hardware.camera2 API または Extended View System API を使用して実装しなければなりません。

  • 2.5.3. ソフトウェア:

    改訂を確認する

    自動車デバイス実装は:

    • [3.8/A-0-1] 現在のフォアグラウンド ユーザーではないフルセカンダリ ユーザーによるアクティビティの起動と画面上の UI へのアクセスを許可してはなりません。

  • 2.5.5. セキュリティ モデル:

    改訂を確認する

    android.hardware.microphone を宣言する場合、自動車デバイス実装は:

    • [9.8.2/A-1-1] アプリがマイクからオーディオ データにアクセスしているときはマイク インジケーターを表示しなければなりません。ただし、HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService、またはセクション 9.1 で CDD 識別子 [C-4-X] が割り当てられたロールを持つアプリからのみマイクにアクセスする場合は、この限りではありません。
    • [9.8.2/A-1-2] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、マイク インジケーターを非表示にしてはなりません。
    • [9.8.2/A-1-3] 設定アプリでマイクを切り替えるユーザー アフォーダンスを提供しなければなりません。

    android.hardware.camera.any を宣言する場合、自動車デバイス実装は:

    • [9.8.2/A-2-1] アプリがライブ カメラデータにアクセスしているときはカメラ インジケーターを表示しなければなりません。ただし、セクション 9.1 権限で CDD 識別子 [C-4-X] [C-3-X] が割り当てられたで定義されたロールを持つアプリからのみカメラにアクセスする場合は、この限りではありません。

    • [9.8.2/A-2-3] 設定アプリでカメラの切り替えを行うユーザー アフォーダンスを提供しなければなりません。
    • [9.8.2/A-2-4] PermissionManager.getIndicatorAppOpUsageData() から返された、カメラを使用している最近使ったアプリとアクティブなアプリを、関連する属性メッセージとともに表示しなければなりません。

    セキュアロック画面があり、TrustAgentService システム API を実装する信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:

    • [9.11.1/A-1-1] 少なくとも 336 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。

3. ソフトウェア

  • 3.1. マネージド API の互換性:

    改訂を確認する

    デバイス実装は:

    • [C-0-8] API レベル 23 未満をターゲットとするアプリのインストールをサポートしてはなりません。

  • 3.2.3.5. 条件付きアプリ インテント:

    改訂を確認する

    android.hardware.nfc.uicc または android.hardware.nfc.ese をレポートする場合、デバイス実装は:

  • 3.3.1. アプリケーション バイナリ インターフェース:

    改訂を確認する

    デバイス実装は:

    • [C-0-12] libvulkan.so ライブラリを通じて、主な Vulkan 1.0Vulkan 1.1 関数シンボルと拡張機能 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1、VK_KHR_get_physical_device_properties2 の関数シンボルをエクスポートしなければなりません。なお、すべてのシンボルが存在しなければなりませんが、対応する関数それぞれの完全な実装が期待される場合の要件については、セクション 7.1.4.2 に詳しく記載しています。

  • 3.8.6. テーマ:

    改訂を確認する

    画面または動画出力が含まれる場合、デバイス実装は:

    • [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ドキュメント（android.theme.customization.theme_styles を参照）に記載されているカラーテーマ スタイル（TONAL_SPOT、VIBRANT、EXPRESSIVE、SPRITZ、RAINBOW、FRUIT_SALAD、MONOCHROMATIC）を使用して、動的な色調パレットを生成しなければなりません。

  • 3.8.8. アクティビティの切り替え:

    改訂を確認する

    セクション 7.2.3 で詳述するように、履歴機能のナビゲーション キーが含まれ、インターフェースを変更する場合、デバイス実装は:

    • [C-1-2] 画面固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。

  • 3.9.2 管理対象プロファイルのサポート:

    改訂を確認する

    android.software.managed_users を宣言する場合、デバイス実装は:

    • [C-1-10] スクリーンショットが、フォーカスされた topActivity ウィンドウ（すべてのアクティビティの中でユーザーが最後に操作したウィンドウ）でキャプチャされ、仕事用プロファイル アプリに属する場合、スクリーンショット データが仕事用プロファイル ストレージに保存されることを確認しなければなりません。
    • [C-1-11] 個人用プロファイルのデータが仕事用プロファイルに保存されないようにするため、スクリーンショットを仕事用プロファイルに保存する場合は、仕事用プロファイル アプリのウィンドウを除き、他の画面コンテンツ（システムバー、通知、個人用プロファイルのコンテンツ）をキャプチャしてはなりません。

  • 3.9.5 デバイス ポリシー解決フレームワーク: 新しいセクション

    改訂を確認する

    android.software.device_admin または android.software.managed_users をレポートする場合、デバイス実装は:

    • [C-1-1] AOSP ドキュメントに記載されているようにデバイス ポリシーの競合を解決しなければなりません。

5. マルチメディアの互換性

  • 5.1.4. 画像のエンコード:

    改訂を確認する

    デバイス実装は、次の画像エンコードのエンコードをサポートしなければなりません。

    • [C-0-4] AVIF
      • デバイスは、BITRATE_MODE_CQ とベースライン プロファイルをサポートしなければなりません。

  • 5.1.5. 画像のデコード:

    改訂を確認する

    デバイス実装は、次の画像エンコードのデコードをサポートしなければなりません。

    [C-0-7] AVIF（ベースライン プロファイル）

  • 5.1.6. 画像コーデックの詳細:

    改訂を確認する

    形式 / コーデック 詳細 サポートされているファイル形式 / コンテナ形式
    JPEG ベースラインとプログレッシブ JPEG（.jpg）
    GIF GIF（.gif）
    PNG PNG（.png）
    BMP BMP（.bmp）
    WebP WebP（.webp）
    Raw ARW（.arw）、CR2（.cr2）、DNG（.dng）、NEF（.nef）、NRW（.nrw）、ORF（.orf）、PEF（.pef）、RAF（.raf）、RW2（.rw2）、SRW（.srw）
    HEIF 画像、画像コレクション、画像シーケンス HEIF（.heif）、HEIC（.heic）
    AVIF（ベースライン プロファイル） 画像、画像コレクション、画像シーケンスのベースライン プロファイル HEIF コンテナ（.avif）

  • 5.1.8. 動画コーデックのリスト:

    改訂を確認する

    形式 / コーデック 詳細 サポートされるファイル形式 / コンテナ形式
    H.263
    • 3GPP（.3gp）
    • MPEG-4（.mp4）
    • Matroska（.mkv、デコードのみ）
    H.264 AVC 詳細についてはセクション 5.2 と 5.3 をご覧ください
    • 3GPP（.3gp）
    • MPEG-4（.mp4）
    • MPEG-2-TS（.ts、シーク不可）
    • Matroska（.mkv、デコードのみ）
    H.265 HEVC 詳細についてはセクション 5.3 をご覧ください
    • MPEG-4（.mp4）
    • Matroska（.mkv、デコードのみ）
    MPEG-2 メイン プロファイル
    • MPEG2-TS（.ts、シーク不可）
    • MPEG-4（.mp4、デコードのみ）
    • Matroska（.mkv、デコードのみ）
    MPEG-4 SP
    • 3GPP（.3gp）
    • MPEG-4（.mp4）
    • Matroska（.mkv、デコードのみ）
    VP8 詳細についてはセクション 5.2 と 5.3 をご覧ください
    VP9 詳細についてはセクション 5.3 をご覧ください
    AV1 詳細についてはセクション 5.2 とセクション 5.3 をご覧ください
    • MPEG-4（.mp4）
    • Matroska（.mkv、デコードのみ）

  • 5.1.10. メディア コーデックの特性:

    改訂を確認する

    デバイス実装が動画コーデックをサポートする場合:

    • [C-2-1] 動画コーデックはすべて、コーデックがサポートしている場合、次のサイズの達成可能なフレームレート データを公開しなければなりません。
    SD（低画質） SD（高画質） HD 720p HD 1080p UHD
    動画の解像度
    • 176 x 144 px（H263、MPEG2、MPEG4）
    • 352 x 288 px（MPEG4 エンコーダ、H263、MPEG2）
    • 320 x 180 px（VP8、VP8）
    • 320 x 240 px（その他）
    • 704 x 576 px（H263）
    • 640 x 360 px（VP8、VP9）
    • 640 x 480 px（MPEG4 エンコーダ）
    • 720 x 480 px（その他、AV1）
    • 1,408 x 1,152 px（H263）
    • 1,280 x 720 px（その他、AV1）
    		 1,920 x 1,080 px（MPEG4 以外、AV1） 3,840 x 2,160 px（HEVC、VP9、AV1）

  • 5.2. 動画のエンコード:

    改訂を確認する

    動画エンコーダをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

    • 2 つのスライディング ウィンドウで、イントラフレーム（I フレーム）間隔のビットレートが 15% を超えるべきではありません。
    • 1 秒のスライディング ウィンドウで、ビットレートが 100% を超えるべきではありません。

    デバイス実装が動画エンコーダをサポートし、サードパーティ アプリで利用でき、
    MediaFormat.KEY_BITRATE_MODE を BITRATE_MODE_VBR に設定してエンコーダが可変ビットレート モードで動作する場合、最低限の品質基準に影響しない限り、エンコード結果のビットレートは:

    • [C-5-1] 1 つのスライディング ウィンドウで、イントラフレーム（I フレーム）間隔のビットレートが 15% を超えるべきではありません。
    • [C-5-2] 1 秒のスライディング ウィンドウで、ビットレートが 100% を超えるべきではありません。

    デバイス実装が動画エンコーダをサポートし、サードパーティ アプリで利用でき、MediaFormat.KEY_BITRATE_MODE を BITRATE_MODE_CBR に設定してエンコーダが固定ビットレート モードで動作する場合、エンコード結果のビットレートは:

    • [C-6-1][C-SR-2] 1 秒のスライディング ウィンドウでターゲット ビットレートを 15% 以上超えないことが強く推奨されます。

  • 5.2.1. H.263:

    改訂を確認する

    H.263 エンコーダをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

    • [C-1-1] ベースライン プロファイル レベル 45 を使用して QCIF 解像度（176 x 144）をサポートしなければなりません。SQCIF 解像度は省略可能です。
    • サポート対象のエンコーダの動的に設定可能なビットレートをサポートすべきです。

  • 5.2.5. H.265:

    改訂を確認する

    H.265 コーデックをサポートする場合、デバイス実装は:

    • [C-1-1] メイン プロファイル レベル 3 と最大 512 x 512 の解像度をサポートしなければなりません。
    • 下表に示すとおり、HD エンコード プロファイルをサポートすべきです。
    • [C-SR-1] ハードウェア エンコーダがある場合、下表に示すとおり、720 x 480 SD プロファイルと HD エンコード プロファイルをサポートすることが強く推奨されます。

  • 5.2.6. AV1: 新しいセクション

    改訂を確認する

    AV1 コーデックをサポートする場合、デバイス実装は:

    • [C-1-1] 8 ビットと 10 ビットのコンテンツを含め、メイン プロファイルをサポートしなければなりません。

    • [C-1-2] 下表に示すサポート対象の解像度について、パフォーマンス データを公開、つまり、getSupportedFrameRatesFor() API または getSupportedPerformancePoints() API を介してパフォーマンス データをレポートしなければなりません。

    • [C-1-3] HDR メタデータを受け入れ、ビットストリームに出力しなければなりません。

    ハードウェア アクセラレーションを使用している場合、AV1 エンコーダは:

    • [C-2-1] 下表に示す HD 1080p のエンコード プロファイルまでサポートしなければなりません。
    SD HD 720p HD 1080p UHD
    動画の解像度 720 x 480 px 1,280 x 720 px 1,920 x 1,080 px 3,840 x 2,160 px
    動画のフレームレート 30 fps 30 fps 30 fps 30 fps
    動画のビットレート 5 Mbps 8 Mbps 16 Mbps 50 Mbps

  • 5.3.2. H.263:

    改訂を確認する

    H.263 デコーダをサポートする場合、デバイス実装は:

    • [C-1-1] ベースライン プロファイル レベル 30（CIF、QCIF、SQCIF 解像度、30 fps、384 kbps）とレベル 45（QCIF、SQCIF 解像度、30 fps、128 kbps）をサポートしなければなりません。

  • 5.3.9. AV1:

    改訂を確認する

    AV1 コーデックをサポートする場合、デバイス実装は:

    • [C-1-1] 10 ビット コンテンツを含め、プロファイル 0 をサポートしなければなりません。

    AV1 コーデックをサポートし、サードパーティ アプリで利用可能にする場合、デバイス実装は:

    • [C-1-1] 8 ビットと 10 ビットのコンテンツを含め、メイン プロファイルをサポートしなければなりません。

    ハードウェア アクセラレーテッド デコーダによる AV1 コーデックのサポートを提供する場合、デバイス実装は:

    • [C-2-1] Display.getSupportedModes() メソッドによって報告される高さが 720p 以上である場合、下表から少なくとも HD 720p の動画デコード プロファイルをデコードできなければなりません。
    • [C-2-2] Display.getSupportedModes() メソッドによって報告される高さが 1080p 以上である場合、下表から少なくとも HD 1080p の動画デコード プロファイルをデコードできなければなりません。
    SD HD 720p HD 1080p UHD
    動画の解像度 720 x 480 px 1,280 x 720 px 1,920 x 1,080 px 3,840 x 2,160 px
    動画のフレームレート 30 fps 30 fps 30 fps 30 fps
    動画のビットレート 5 Mbps 8 Mbps 16 Mbps 50 Mbps

    Media API を通じて HDR プロファイルをサポートする場合、デバイス実装は:

    • [C-3-1] ビットストリームとコンテナの両方または一方からの HDR メタデータの抽出と出力をサポートしなければなりません。
    • [C-3-2] HDR コンテンツをデバイスの画面または標準の動画出力ポート（例: HDMI）に適切に表示しなければなりません。

  • 5.4.2. 音声認識用のキャプチャ:

    改訂を確認する

    android.hardware.microphone を宣言する場合、デバイス実装は:

    • 音声認識の音源を録音するために使用する各マイクすべてについて、音圧レベル（SPL）90 dB で再生された 1,000 Hz 正弦波音源（マイクから 30 cm の距離の隣で測定）が、16 ビットサンプルで RMS 1,770～3,530 の範囲のレスポンス（理想的には RMS 2,500）になるように（浮動小数点 / 倍精度サンプルの場合は -22.35 dB ±3 dB フルスケール）、オーディオ入力感度を設定すべきです。

  • 5.5.2. オーディオ エフェクト:

    改訂を確認する

    機能 android.hardware.audio.output を宣言する場合、デバイス実装は:

    • [C-1-4] 浮動小数点入力と出力によるオーディオ エフェクトをサポートしなければなりません。
    • [C-1-5] オーディオ エフェクトが、最大でミキサー チャンネル数（FCC_LIMIT）と同じ数までの複数のチャンネルをサポートするようにしなければなりません。

  • 5.6. オーディオ レイテンシ:

    改訂を確認する

    android.hardware.audio.output を宣言する場合、デバイス実装は、次の要件を満たすか上回ることが強く推奨されます。

    • [C-SR-4] AudioTrack.getTimestamp と AAudioStream_getTimestamp から返される出力タイムスタンプの正確度が +/- 1 ms。

    • [C-SR-4] AAudioStream_getTimestamp によって返される入力タイムスタンプと出力タイムスタンプに基づいて計算されたラウンドトリップ レイテンシと、スピーカー、有線ヘッドセット、ワイヤレス ヘッドセットの AAUDIO_PERFORMANCE_MODE_NONE と AAUDIO_PERFORMANCE_MODE_LOW_LATENCY について測定されたラウンド トリップ レイテンシとの誤差が 30 ミリ秒以内であることが強く推奨されます。

7. ハードウェアの互換性

  • 7.1. ディスプレイとグラフィック:

    改訂を確認する

    Android には、さまざまなハードウェア構成さまざまなハードウェア ディスプレイと構成でサードパーティ アプリが適切に動作するように、デバイスに合わせてアプリアセットと UI レイアウトを自動的に調整する機能があります。Android 互換ディスプレイは、デベロッパー向け Android - 画面互換性の概要、このセクション 7.1 とそのサブセクションに記載されているすべての動作と API、および、この CDD のセクション 2 に記載されているその他すべてのデバイスタイプ固有の動作を実装するディスプレイ画面です。すべてのサードパーティ Android 互換アプリを実行できる Android 互換ディスプレイでは、このセクションで詳述するように、デバイス実装はこれらの API と動作を適切に実装しなければなりません。

    新しい要件の開始

    デバイス実装は:

    • [C-0-1] デフォルトでサードパーティ アプリを Android 互換ディスプレイにのみレンダリングしなければなりません。

    このセクションの要件で言及する単位の定義は次のとおりです。

    • 物理的な対角サイズ。ディスプレイの点灯部分の、2 つの相対する隅の間の距離（インチ単位）。
    • 1 インチあたりのドット数（dpi）密度。1 インチの水平または垂直直線スパンで囲まれるピクセル数。1 インチあたりのピクセル数（ppi または dpi）で表されます。dpi 値 ppi 値と dpi 値が記載されている場合は、水平方向と垂直方向の両方の dpi が記載範囲内に収まらなければなりません。
    • アスペクト比。画面の長辺と短辺のピクセル数の比。たとえば 480x854 ピクセルのディスプレイは 854/480 = 1.779、すなわち約「16:9」となります。
    • 密度非依存ピクセル（dp）。160 dpi の画面密度 160 の画面に正規化された仮想ピクセル単位。密度 d、ピクセル数 p、密度非依存ピクセル数 dp について、ピクセル数 = dps * (密度/160) dp = (160 / d) * p として計算します。

  • 7.1.1.1. 画面サイズと形状:

    改訂を確認する

    UI_MODE_TYPE_NORMAL サイズ構成が可能な画面をサポートし、隅の丸い Android 互換ディスプレイが含まれる物理ディスプレイを使用して画面をレンダリングする場合、デバイス実装は:

    • [C-1-1] 各ディスプレイで次の要件のうち少なくとも 1 つを満たさなければなりません。
    • 丸い隅の半径が 38 dp 以下。

    • 15 dp x 15 dp のボックスを論理ディスプレイのそれぞれの隅に固定したとき、各ボックスの少なくとも 1 ピクセルが画面に表示される。

    • 隅が直角の表示モードに切り替えるユーザー アフォーダンスを含むべきです。

    新しい要件の開始

    NO_KEYS キーボードの構成のみが可能で、UI_MODE_TYPE_NORMAL UI モードの構成のサポートをレポートする場合、デバイス実装は:

    • [C-4-1] ディスプレイ カットアウトを除くレイアウト サイズを 596 dp x 384 dp 以上にしなければなりません。

    折りたたみ式の Android 互換ディスプレイが含まれるか、複数のディスプレイ間の折りたたみヒンジが含まれ、そうしたディスプレイをサードパーティ アプリでレンダリングできるようにする場合、デバイス実装は:

    折りたたみ式の Android 互換ディスプレイが含まれるか、複数のディスプレイ間の折りたたみヒンジが含まれる場合、また全画面アプリ ウィンドウを横切ってヒンジで動くか折りたたまれる場合、デバイス実装は:

    • [C-3-1] 拡張機能 API またはサイドカー API を通じて、ヒンジまたは折りたたみの位置、境界、状態をアプリにレポートしなければなりません。

    1 つ以上の折りたたみ式の Android 互換ディスプレイ領域が含まれるか、複数の Android 互換ディスプレイ パネル領域間の折りたたみヒンジが含まれ、そうしたディスプレイ領域をアプリで利用できるようにする場合、デバイス実装は:

    • [C-4-1] 今後提供されるドキュメントに記載されているとおりに、正しいバージョンの Window Manager Extensions API レベルを実装しなければなりません。

  • 7.1.1.2. 画面のアスペクト比: 削除しました

  • 7.1.1.3. 画面密度:

    改訂を確認する

    デバイス実装は:

    • [C-0-1] デフォルトで、デバイス実装は DENSITY_DEVICE_STABLE API を通じて DisplayMetrics にリストされている論理 Android フレームワーク密度を 1 つだけレポートしなければならず、この値は各物理ディスプレイで静的な値にしなければなりません。いかなるときも変更してはなりません。ただしただし、デバイスは、初回起動後にユーザーが設定したディスプレイ設定（表示サイズなど）の変更に従って、異なる任意の密度 DisplayMetrics.density をレポートしても構いません。

    • デバイス実装は、画面の物理密度に数値的に最も近い標準 Android フレームワーク密度を定義すべきです。ただし、その論理密度によって、レポートされる画面サイズがサポート対象の最小値未満になる場合を除きます。物理密度に数値的に最も近い標準 Android フレームワーク密度が、サポート対象の最小互換画面サイズ（幅 320 dp）よりも小さい画面サイズとなる場合、デバイス実装は、次に近い標準 Android フレームワーク密度をレポートすべきです。

    新しい要件の開始

    • 画面の物理密度に数値的に最も近い標準 Android フレームワーク密度、または同等なハンドヘルド デバイスの画角の測定値に対応する値を定義すべきです。

    デバイスの表示サイズを変更するアフォーダンスがあるを提供する場合、デバイス実装は:

    • [C-1-1] 表示サイズを、ディスプレイを、DENSITY_DEVICE_STABLE ネイティブ密度の 1.5 倍よりも大きく調整したり、320 dp（リソース修飾子 sw320dp と同等）よりも小さい有効最小画面寸法を生成したりしてはなりません。
    • [C-1-2] 表示サイズを、ディスプレイを、DENSITY_DEVICE_STABLE ネイティブ密度の 0.85 倍よりも小さく調整してはなりません。

  • 7.1.4.2 Vulkan:

    改訂を確認する

    Vulkan 1.0 以降のサポートが含まれる場合、デバイス実装は:

    • [C-1-3] 列挙した VkPhysicalDevice ごとに Vulkan 1.0Vulkan 1.1 API を完全に実装しなければなりません。

    • [C-1-5] アプリに true として設定された android:debuggable 属性または true に設定されたメタデータ com.android.graphics.injectLayers.enable がある場合を除き、アプリ パッケージ外のライブラリによって提供されるレイヤの列挙、Vulkan API をトレースまたはインターセプトする別の方法の提供をしてはなりません。

    • VkPhysicalDeviceProtectedMemoryFeatures と VK_EXT_global_priority をサポートすべきです。

    • [C-SR-5] VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory と VK_EXT_global_priority をサポートすることが強く推奨されます。

    • [C-SR-6] HWUI で SkiaVk を使用することが強く推奨されます。

    Vulkan 1.1 のサポートが含まれ、こちらに記載されている Vulkan 機能フラグのいずれかを宣言する場合、デバイス実装は:

    • [C-SR-7] VK_KHR_external_fence_fd 拡張機能をサードパーティ アプリで利用できるようにし、こちらに記載されているとおりに、アプリによる POSIX ファイル記述子へのフェンス ペイロードのエクスポートと、POSIX ファイル記述子からのフェンス ペイロードのインポートを可能にすることが強く推奨されます。

  • 7.3.10. 生体認証センサー:

    改訂を確認する

    生体認証センサーが複数ある場合、デバイス実装は:

    • [C-7-1] 試行に失敗した回数が上限を超えたことにより、生体認証がロックアウトされた場合（ユーザーが第 1 の認証でロック解除するまで生体認証が無効になっている場合）、または期限付きでロックアウトされている場合（ユーザーが一定時間の待機を完了するまでは生体認証が一時的に無効になっている場合）は、下位の生体認証クラスのその他の生体認証もすべてロックアウトしなければなりません。期限付きロックアウトの場合、生体認証検証のバックオフ時間は、期限付きロックアウト中のすべての生体認証の最大バックオフ時間でなければなりません。

    • [C-SR-12] 試行に失敗した回数が上限を超えたことにより、生体認証がロックアウトされた場合（ユーザーが第 1 の認証でロック解除するまで生体認証が無効になっている場合）、または期限付きでロックアウトされている場合（ユーザーが一定時間の待機を完了するまでは生体認証が一時的に無効になっている場合）は、同じ生体認証クラスのその他の生体認証もすべてロックアウトすることが強く推奨されます。期限付きロックアウトの場合、生体認証検証のバックオフ時間は、期限付きロックアウト中のすべての生体認証の最大バックオフ時間とすることが強く推奨されます。

    • [C-7-2] ロックアウト中の生体認証のロックアウト カウンタをリセットするために、推奨される第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。クラス 3 の生体認証では、ロック中の同じまたは下位のクラスの生体認証のロックアウト カウンタをリセットできても構いません。クラス 2 またはクラス 1 の生体認証で、生体認証のリセット ロックアウト オペレーションを完了してはなりません。

    生体認証センサーをクラス 1（旧称「利便性」）として扱う場合、デバイス実装は:

    • [C-1-12] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段（PAI）の種類ごとに 40% 以下でなければなりません。

    • [C-SR-13] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段（PAI）の種類ごとに 30% 以下であることが強く推奨されます。

    • [C-SR-14] 生体認証センサーの生体認証クラスと、それを有効にすることのリスクを開示することが強く推奨されます。

    • [C-SR-17] 新しい AIDL インターフェース（たとえば、IFace.aidl や IFingerprint.aidl）を実装することが強く推奨されます。

    生体認証センサーをクラス 2（旧称「弱」）として扱う場合、デバイス実装は:

    • [C-SR-15] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段（PAI）の種類ごとに 20% 以下であることが強く推奨されます。

    • [C-2-3] 高信頼実行環境（TEE）など、Android のユーザーまたはカーネル空間外の隔離された実行環境内、または隔離された実行環境へのセキュア チャネルがあるチップ上、セクション 9.17 の要件を満たす Protected Virtual Machine 上で、生体認証マッチングを行わなければなりません。
    • [C-2-4] Android オープンソース プロジェクトのサイトの実装ガイドラインに記載されている隔離された実行環境、隔離された実行環境へのセキュア チャネルがあるチップ、セクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine の外部で取得、読み取り、変更できないように、識別可能なすべてのデータを暗号化、暗号認証しなければなりません。
    • [C-2-5] カメラベースの生体認証で、生体認証ベースの認証または登録が行われるとき:
      • 隔離された実行環境または隔離された実行環境へのセキュア チャネルがあるチップ、セクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine の外部では、カメラフレームの読み取りと変更が行われないモードで、カメラを動作させなければなりません。
      • RGB シングルカメラ ソリューションでは、登録のためのプレビューなどの動作をサポートするために、隔離された実行環境の外部でカメラフレームを読み取れても、変更はできないようにしなければなりません。
    • [C-2-7] TEE またはセクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine のコンテキスト外で、識別可能な生体認証データまたはそれから派生したデータ（埋め込みなど）への暗号化されていないアクセスを、アプリ プロセッサに許可してはなりません。Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合、C-2-7 は免除されません。

    生体認証センサーをクラス 3（旧称「強」）として扱う場合、デバイス実装は:

    • [C-SR-16] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段（PAI）の種類ごとに 7% 以下であることが強く推奨されます。

  • 7.3.13. IEEE 802.1.15.4（UWB）:

    改訂を確認する

    802.1.15.4 のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:

    • [C-1-2] ハードウェア機能フラグ android.hardware.uwb をレポートしなければなりません。
    • [C-1-3] AOSP 実装で定義されている次の構成セット（事前定義された FiRa UCI パラメータの組み合わせ）をすべてサポートしなければなりません。
      • CONFIG_ID_1: FiRa で定義されたユニキャスト STATIC STS DS-TWR 距離測定、遅延モード、距離測定時間は 240 ミリ秒。
      • CONFIG_ID_2: FiRa で定義された 1 対多の STATIC STS DS-TWR 距離測定、遅延モード、距離測定時間は 200 ミリ秒（一般的な使用例: 多数のスマート デバイスと連携するスマートフォン）。
      • CONFIG_ID_3: CONFIG_ID_1 と同じですが、到来角（AoA）データはレポートされません。
      • CONFIG_ID_4: CONFIG_ID_1 と同じですが、P-STS セキュリティ モードが有効化されます。
      • CONFIG_ID_5: CONFIG_ID_2 と同じですが、P-STS セキュリティ モードが有効化されます。
      • CONFIG_ID_6: CONFIG_ID_3 と同じですが、P-STS セキュリティ モードが有効化されます。
      • CONFIG_ID_7: CONFIG_ID_2 と同じですが、P-STS 個別コントローリー鍵モードが有効化されます。
    • [C-1-4] ユーザーが UWB 無線のオン / オフの状態を切り替えられるようにするユーザー アフォーダンスを提供しなければなりません。
    • [C-1-5] UWB 無線を使用するアプリが（NEARBY_DEVICES 権限グループの下で）UWB_RANGING 権限を保持するようにしなければなりません。

    FiRa、CCC、CSA などの標準化団体によって定義されている、関連する適合性および認証テストに合格することで、802.1.15.4 が適切に機能するようにできます。

  • 7.4.1. 電話:

    改訂を確認する

    Android API とこのドキュメントで使用する「電話」は、特に、モバイル（たとえば、GSM、CDMA、LTE、NR）GSM または CDMA ネットワークを介して行う音声通話と SMS メッセージの送信、またはモバイルデータの確立に関連するハードウェアのことを指します。「電話」をサポートするデバイスでは、製品に合わせて、通話、メッセージング、データサービスの一部またはすべてを提供することを選択できます。

    GSM または CDMA ネットワークを介して行う音声通話と SMS メッセージの送信に関連するハードウェアのことを指します。こうした音声通話は、パケット交換であってもそうでなくても構いませんが、Android では、同じネットワークを使用して実装されるデータ接続からは独立しているとみなされます。つまり、Android の「電話」機能と API は、特に音声通話と SMS のことを指します。たとえば、通話の発信または SMS メッセージの送受信ができないデバイス実装は、データ接続にモバイル ネットワークを使用するかどうかにかかわらず、電話デバイスとはみなされません。

  • 7.4.2. IEEE 802.11（Wi-Fi）:

    改訂を確認する

    802.11 のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:

    • [C-1-4] マルチキャスト DNS（mDNS）をサポートしなければならず、画面がアクティブ状態でないときを含むいかなる運用時にも mDNS パケット（224.0.0.251 または ff02::fb）をフィルタしてはなりません。ただし、ターゲット市場に適用される規制要件で要求されている消費電力の範囲内に収めるために、パケットをドロップまたはフィルタする必要がある場合を除きます。Android テレビデバイス実装の場合、スタンバイ電力状態にあるとき。

  • 7.4.3. Bluetooth:

    改訂を確認する

    FEATURE_BLUETOOTH_LE を宣言する場合、デバイス実装は:

    • [C-SR-2] ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -60 dBm +/-10 dB になるように、Rx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。
    • [C-SR-3] 1 m の距離に位置し、ADVERTISE_TX_POWER_HIGH で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -60dBm +/-10 dB になるように、Tx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。

    • [C-10-3] ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -55 dBm +/-10 dB になるように、Rx オフセットを測定し補正しなければなりません。
    • [C-10-4] 1 m の距離に位置し、ADVERTISE_TX_POWER_HIGH で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -55 dBm +/-10 dB になるように、Tx オフセットを測定し補正しなければなりません。

    Bluetooth バージョン 5.0 をサポートする場合、デバイス実装は:

    • [C-SR-4] 次のサポートを提供することが強く推奨されます:
    • LE 2M PHY
    • LE Coded PHY
    • LE Advertising Extension
    • Periodic advertising
    • 10 個以上の広告セット
    • 8 接続以上の LE 同時接続。各接続は、いずれかの接続トポロジのロールに含めることができます。
    • LE Link Layer Privacy
    • 8 エントリ以上のサイズの「解決リスト」

  • 7.4.9. UWB:

    改訂を確認する

    • [C-1-7] 参照デバイスから 1 m の距離で測定した値の中央値が [0.75 m, 1.25 m] 以内になるようにしなければなりません。この場合、グラウンド トゥルースの距離は、上を向けて 45 度傾けた DUT の上端から測定します。

  • 7.5.1. 背面カメラ:

    改訂を確認する

    背面カメラとは、デバイスのディスプレイとは反対側に配置されたカメラのことです。つまり、従来のカメラのようにデバイスの向こう側の光景を撮影するものです。

    背面カメラとは、従来のカメラのようにデバイスの向こう側の光景を撮影するワールド フェイシング カメラです。ハンドヘルド デバイスでは、デバイスのディスプレイの反対側に配置されたカメラです。

  • 7.5.2. 前面カメラ:

    改訂を確認する

    前面カメラとは、デバイスのディスプレイと同じ側に配置されたカメラのことです。つまり、通常はビデオ会議や類似のアプリなどでユーザーを撮影するために使用されるカメラです。

    前面カメラとは、ビデオ会議や同様のアプリなどでユーザーを撮影するために一般的な使用されるユーザー向きカメラです。ハンドヘルド デバイスでは、デバイスのディスプレイと同じ側に配置されたカメラを使用します。

  • 7.5.3. 外部カメラ:

    改訂を確認する

    外部カメラとは、デバイス実装にいつでも物理的に取り付けや取り外しができ、任意の方向に向けることができるカメラ（USB カメラなど）です。

  • 7.5.4. カメラ API の動作:

    改訂を確認する

    デバイス実装は、利用可能なカメラすべてについて、カメラ関連の API のために次の動作を実装しなければなりません。デバイス実装は:

    • [C-SR-1] 複数の RGB カメラが近接していて同じ方向を向いているデバイスでは、物理サブデバイスとしてその方向を向いているすべての RGB カメラで構成された、機能 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA をリストする論理カメラデバイスをサポートすることが強く推奨されます。

  • 7.5.5. カメラの向き:

    改訂を確認する

    以下の基準をすべて満たすデバイスは、上記の要件の対象外となります。

    • ユーザーが回転できないデバイス実装（自動車デバイスなど）。

  • 7.10. ハプティクス:

    改訂を確認する

    手で持ったり、身につけたりすることを意図されたデバイスは、一般的なタッチ フィードバックだけでなく、着信音、アラーム、通知によって注意を引くなどの目的でアプリが利用できる汎用触覚アクチュエータを含むことができます。

    そのような汎用触覚アクチュエータを含まない場合、デバイス実装は:

    • [7.10/C] Vibrator.hasVibrator() に対して false を返さなければなりません。

    そのような汎用触覚アクチュエータを 1 つ以上含む場合、デバイス実装は:

    触覚定数マッピングに従う場合、デバイス実装は:

    デバイス固有の要件についてはセクション 2.2.1 をご覧ください。

9. セキュリティ モデルの互換性

  • 9.1. 権限:

    改訂を確認する

    デバイス実装は:

    • [C-0-4] 両方のユーザー インターフェースの実装を 1 つだけ持たなければなりません。

    デバイス実装で System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence、または System Visual Intelligence のいずれかのロールを保持するパッケージがプリインストールされる場合、パッケージは:

    • [C-4-1] セクション「9.8.6 コンテンツ キャプチャ」「9.8.6 OS レベルおよびアンビエント データ」「9.8.15 サンドボックス化された API 実装」でデバイス実装について概説されている要件をすべて満たさなければなりません。

    • [C-4-2] android.permission.INTERNET 権限があってはなりません。これは、セクション 9.8.6 に記載されている「強く推奨」よりも厳格です。
    • [C-4-3] システムアプリ（Bluetooth、連絡先、メディア、電話、システム UI、インター API を提供するコンポーネント）を除き、他のアプリにバインドしてはなりません。これは、セクション 9.8.6 に記載されている「強く推奨」よりも厳格です。

    VoiceInteractionService をサポートするデフォルト アプリを含む場合、デバイス実装は:

    • [C-5-1] アプリに ACCESS_FINE_LOCATION をデフォルトで付与してはなりません。

  • 9.5. マルチユーザー サポート:

    改訂を確認する

    上記の追加のユーザー プロファイルを作成する場合、デバイス実装は:

    • [C-4-5] アイコンがユーザーに表示されるときに、デュアル インスタンス アプリのアイコンを視覚的に区別しなければなりません。
    • [C-4-6] クローン プロファイル データ全体を削除するユーザー アフォーダンスを提供しなければなりません。
    • [C-4-7] ユーザーがクローン プロファイル データ全体の削除を選択した場合、すべてのクローンアプリをアンインストールし、限定公開アプリデータ ディレクトリとそのコンテンツを削除し、クローン プロファイル データを削除しなければなりません。
    • 最後のクローンアプリが削除されたときに、クローン プロファイル データ全体を削除するようにユーザーに促すべきです。
    • [C-4-8] クローンアプリがアンインストールされるとアプリデータが削除されることをユーザーに通知しなければなりません。または、アプリがデバイスをアンインストールされたときにアプリデータを保持するオプションをユーザーに提供しなければなりません。
    • [C-4-9] ユーザーがアンインストール中にデータを削除することを選択した場合、限定公開アプリデータ ディレクトリとそのコンテンツを削除しなければなりません。

    • [C-4-1] 追加のプロファイルからの以下のインテントを、デバイス上のプライマリ ユーザーのアプリが処理できるようにしなければなりません。

      • Intent.ACTION_VIEW
      • Intent.ACTION_SENDTO
      • Intent.ACTION_SEND
      • Intent.ACTION_EDIT
      • Intent.ACTION_INSERT
      • Intent.ACTION_INSERT_OR_EDIT
      • Intent.ACTION_SEND_MULTIPLE
      • Intent.ACTION_PICK
      • Intent.ACTION_GET_CONTENT
      • MediaStore.ACTION_IMAGE_CAPTURE
      • MediaStore.ACTION_VIDEO_CAPTURE

    • [C-4-2] すべてのデバイス ポリシー ユーザー制限と、デバイスのプライマリ ユーザーに適用されるユーザー以外の制限（以下のリストを参照）のうち選択されたものを、この追加のユーザー プロファイルに継承しなければなりません。

    • [C-4-3] この追加プロファイルからの連絡先の書き込みを許可するのは次のインテントを介する場合のみでなければなりません。

    • [C-4-4] この追加のユーザー プロファイルで実行されているアプリについて、連絡先の同期を実行してはなりません。

    • [C-4-14] この追加プロファイルで動作するアプリについて、個別の権限とストレージ管理がなければなりません。

    • [C-4-5] ランチャー アクティビティが設定されている追加のプロファイル内のアプリのみが、親ユーザー プロファイルへのアクセス権をすでに持っている連絡先にアクセスできるようにしなければなりません。

  • 9.7. セキュリティ機能:

    改訂を確認する

    メモリ安全性テクノロジーは、android:memtagMode マニフェスト オプションを使用するアプリにおいて、高確率（90% 超）で少なくとも以下の種類のバグを軽減するテクノロジーです。

    • ヒープのバッファ オーバーフロー
    • 解放後の使用
    • 二重解放
    • 不正な解放（malloc で確保していないポインタの解放）

    デバイス実装は:

    • [C-SR-15] ro.arm64.memtag.bootctl_supported を設定することが強く推奨されます。

    システム プロパティ ro.arm64.memtag.bootctl_supported を true に設定する場合、デバイス実装は:

    • [C-3-1] システム プロパティ arm64.memtag.bootctl に、以下の値のカンマ区切りリストを指定して、次の再起動時に指定された効果を適用できるようにしなければなりません。

      • memtag: 上で定義したメモリ安全性テクノロジーを有効にする
      • memtag-once: 上で定義したメモリ安全性テクノロジーを一時的に有効にし、次回の再起動時に自動的に無効にする
      • memtag-off: 上で定義したメモリ安全性テクノロジーを無効にする

    • [C-3-2] シェルユーザーが arm64.memtag.bootctl を設定できるようにしなければなりません。

    • [C-3-3] 任意のプロセスが arm64.memtag.bootctl の読み取りをできるようにしなければなりません。

    • [C-3-4] デバイス実装でシステム プロパティを変更せずに状態を変更できる場合は、起動時に arm64.memtag.bootctl を現在要求されている状態に設定し、プロパティをアップデートしなければなりません。

    • [C-SR-16] memtag-once を設定してデバイスを再起動するデベロッパー向け設定を表示することが強く推奨されます。互換性のあるブートローダーであれば、Android オープンソース プロジェクトが MTE ブートローダー プロトコルにより上記の要件を満たします。

    • [C-SR-17] セキュリティ設定メニューに、ユーザーが memtag を有効にできる設定を表示することが強く推奨されます。

  • 9.8.2. 記録:

    改訂を確認する

    デバイス実装は:

    • [C-0-2] 画面のキャストまたは画面の録画画面のキャプチャ セッションが MediaProjection.createVirtualDisplay()、VirtualDeviceManager.createVirtualDisplay()、または独自の API を介して有効になっている開始されるたびに場合は常に、ユーザー警告と、ユーザーの画面に表示されているすべての機密情報のキャプチャを許可する AOSP とまったく同じメッセージを含む明示的なユーザーの同意に関する表示を行い、同意を得なければなりません。ユーザーの同意の表示を今後無効にするアフォーダンスをユーザーに提供してはなりません。

    • [C-SR-1] AOSP で実装されているメッセージとまったく同じユーザー警告を表示することが強く推奨されますが、ユーザーの画面上の機密情報がキャプチャされることを明確に警告するメッセージへの変更であれば可能です。

    • [C-0-4] 画面キャプチャへのユーザーの同意の表示を今後無効にするアフォーダンスをユーザーに提供してはなりません。ただし、ユーザーが android.app.role.COMPANION_DEVICE_APP_STREAMING または android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING デバイス プロファイルで associate() を許可したシステムアプリによってセッションが開始される場合を除きます。

  • 9.8.6. OS レベルおよびアンビエント データ: セクション名が、コンテンツ キャプチャとアプリ検索から OS レベルおよびアンビエント データに変更されました。

    改訂を確認する

    Android は、システム API ContentCaptureService、AugmentedAutofillService、AppSearchGlobalManager.query を通じてまたは他の独自の方法によって、次のアプリとユーザーの間におけるアプリデータのやり取りセンシティブ データをデバイス実装がキャプチャするメカニズムをサポートしています。

    • AugmentedAutofillService を介してシステムに送信される任意の画面またはその他のデータ。
    • Content Capture API を介してアクセスできる任意の画面またはその他のデータ。
    • FieldClassificationService API を介してアクセスできる任意の画面またはその他のデータ。
    • AppSearchManager API を介してシステムに渡され、AppSearchGlobalManager.query を介してアクセス可能な任意のアプリデータ。

    • アプリが Content Capture API、AppSearchManager API、または同様の機能を持つ Android や独自の API を介してシステムに提供する、その他のイベント。

    • 音声認識装置の実装により、SpeechRecognizer#onDeviceSpeechRecognizer() を使用して取得される音声データ。
    • AudioRecord、SoundTrigger、またはその他の Audio API を介して、（継続的に）バックグラウンドで取得され、ユーザーに表示されるインジケーターにはならない音声データ。
    • CameraManager、またはその他の Camera API を介して、（継続的に）バックグラウンドで取得され、ユーザーに表示されるインジケーターにはならないカメラデータ。

    上記のデータのいずれかをキャプチャする場合、デバイス実装は:

    • [C-1-3] そのようなすべてのデータとデバイスのログは、必ずプライバシー保護メカニズムを使用して送信しなければなりません（共有するたびに明示的にユーザーの同意を得る場合を除きます）。プライバシー保護メカニズムは、「集計分析のみを許可し、ログに記録されたイベントまたは派生結果を個々のユーザーにマッチングできないようにするもの」として定義され、ユーザーごとのデータに対してイントロスペクションが可能にならないようにします（たとえば、RAPPOR などの差分プライバシー技術を使用して実装されます）。

    • [C-1-5] そのようなデータを、現在のセクション（9.8.6 コンテンツ キャプチャ OS レベルおよびアンビエント データ）で概説している要件に従わない他の OS コンポーネントと共有してはなりません（共有するたびに明示的にユーザーの同意を得る場合を除きます）。これらの機能が Android SDK API（AmbientContext、HotwordDetectionService）としてビルドされていない場合に限ります。

    • [C-1-6] そのようなデータがなんらかの形式でデバイスに保存される場合ときに、ContentCaptureService 実装または独自の方法で収集するデータを削除するユーザー アフォーダンスを提供しなければなりません。ユーザーがデータを消去することを選択した場合は、それまでに収集したすべてのデータを削除しなければなりません。

    • [C-SR-3] Android SDK API または同様の OEM 所有のオープンソース リポジトリで実装することと、サンドボックス化された実装（9.8.15 サンドボックス化された API 実装を参照）で実行することが強く推奨されます。

    Android では、SpeechRecognizer#onDeviceSpeechRecognizer() を通じて、ネットワークを介さずにデバイスで音声認識を行う機能が提供されています。デバイス上の SpeechRecognizer の実装は、このセクションで概説しているポリシーに従わなければなりません。

  • 9.8.10. 接続に関するバグレポート:

    改訂を確認する

    android.hardware.telephony 機能フラグを宣言する場合、デバイス実装は:

    • [C-1-4] BUGREPORT_MODE_TELEPHONY を使用して生成されたレポートは、少なくとも次の情報を含まれなければなりません。
      • SubscriptionManagerService ダンプ

  • 9.8.14. 認証情報マネージャー: 削除しました

  • 9.8.15. サンドボックス化された API 実装: 新しいセクション

    改訂を確認する

    Android は、一連のデリゲート API を介して、安全な OS レベルおよびアンビエント データを処理するメカニズムを提供しています。この処理は、特権アクセス権を持ち、通信機能が制限されているプリインストール APK（サンドボックス化された API 実装）にデリゲートできます。

    サンドボックス化された API 実装は:

    • [C-0-1] インターネット権限をリクエストしてはなりません。
    • [C-0-2] プライバシー保護メカニズムを使用する公開済みのオープンソース実装に基づく構造化 API を通じてインターネットにアクセスするか、Android SDK API を介して間接的にインターネットにアクセスしなければなりません。プライバシー保護メカニズムは、「集計分析のみを許可し、ログに記録されたイベントまたは派生結果を個々のユーザーにマッチングできないようにするもの」として定義され、ユーザーごとのデータに対してイントロスペクションが可能にならないようにします（たとえば、RAPPOR などの差分プライバシー技術を使用して実装されます）。
    • [C-0-3] 下記を除き、サービスを他のシステム コンポーネントから分離しておかなければなりません（サービスをバインドしない、プロセス ID を共有しないなど）。
      • 電話、連絡先、システム UI、メディア
    • [C-0-4] サービスを、ユーザーによるインストールが可能なアプリまたはサービスに置き換えられるようにしてはなりません。
    • [C-0-5] プリインストール サービスのみが、そのようなデータをキャプチャできるようにしなければなりません。置換機能が AOSP に組み込まれている場合を除きます（デジタル アシスタント アプリの場合など）。
    • [C-0-6] プリインストール サービス メカニズム以外のアプリでそのようなデータをキャプチャできるようにしてはなりません。このようなキャプチャ機能が Android SDK API で実装されている場合を除きます。
    • [C-0-7] サービスを無効にするユーザー アフォーダンスを提供しなければなりません。
    • [C-0-8] セクション 9.1. 権限に記載されているとおり、サービスが持つ Android の権限を管理し、Android の権限モデルに従うユーザー アフォーダンスを省略してはなりません。

  • 9.8.16. 連続的な音声およびカメラデータ: 新しいセクション

    改訂を確認する

    9.8.2 記録、9.8.6 OS レベルおよびアンビエント データ、9.8.15 サンドボックス化された API 実装に概説されている要件に加えて、AudioRecord、SoundTrigger、またはその他の Audio API を介してバックグラウンドで（継続的に）取得した音声データを利用する実装、または、CameraManager などの Camera API を介してバックグラウンドで（継続的に）取得したカメラデータを利用する実装の要件は次のとおりです。

    • [C-0-1] 次の場合を除き、対応するインジケーター（セクション 9.8.2 記録の内容に即したカメラやマイク）を適用しなければなりません。
      • このアクセスは、サンドボックス化された実装（9.8.15 サンドボックス化された API 実装を参照）で、System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence、または System Visual Intelligence のうち、1 つ以上のロールを保持するパッケージを介して実行されます。
      • このアクセスは、サンドボックスを介して実行されます。また、AOSP のメカニズム（HotwordDetectionService、WearableSensingService、VisualQueryDetector）を介して実装、適用されます。
      • 音声アクセスは、デジタル アシスタント アプリによって補助目的で実行され、音源として SOURCE_HOTWORD が提供されます。
      • アクセスはシステムによって実行され、オープンソース コードを使用して実装されます。
    • [C-SR-1] そのようなデータを利用するすべての機能は、ユーザーの同意を必要にして、デフォルトでは無効にすることが強く推奨されます。
    • [C-SR-2] 同じ処理（9.8.2 記録、9.8.6 OS レベルおよびアンビエント データ、9.8.15 サンドボックス化された API 実装、9.8.16 連続的な音声およびカメラデータで概説されている制限事項に即した処理）を、リモートのウェアラブル デバイスから取得したカメラデータに適用することが強く推奨されます。

    カメラデータがリモートのウェアラブル デバイスから提供され、Android OS 外、サンドボックス化された実装、または WearableSensingManager でビルドされたサンドボックス機能から暗号化されていない形式でアクセスされる場合、以下の要件が適用されます。

    • [C-1-1] リモートのウェアラブル デバイスに、追加のインジケーターを表示するよう指定しなければなりません。

    デバイスに、割り当てられたキーワードなしでデジタル アシスタント アプリケーションを利用する機能がある場合（一般的なユーザークエリの処理、またはカメラを介したユーザー プレゼンスの分析）、要件は次のとおりです。

    • [C-2-1] android.app.role.ASSISTANT ロールを保持するパッケージによってそのような実装が提供されるようにしなければなりません。
    • [C-2-2] そのような実装が、HotwordDetectionService や VisualQueryDetectionService Android API を利用するようにしなければなりません。

  • 9.8.17. テレメトリー: 新しいセクション

    改訂を確認する

    Android は、StatsLog API を使用してシステムとアプリのログを保存します。これらのログは、特権システムアプリが使用できる StatsManager API を介して管理されます。

    StatsManager には、プライバシー保護メカニズムを含むデバイスから、プライバシーにかかわる機密に分類されるデータを収集する方法も用意されています。特に StatsManager::query API には、StatsLog で定義された制限付きの指標カテゴリを照会できる機能があります。

    StatsManager から制限付きの指標を照会、収集する実装の要件は次のとおりです。

    • [C-0-1] デバイス上の唯一のアプリまたは実装として、READ_RESTRICTED_STATS 権限を保持していなければなりません。
    • [C-0-2] 必ずプライバシー保護メカニズムを使用して、テレメトリー データとデバイスのログを送信しなければなりません。プライバシー保護メカニズムは、「集計分析のみを許可し、ログに記録されたイベントまたは派生結果を個々のユーザーにマッチングできないようにするもの」として定義され、ユーザーごとのデータに対してイントロスペクションが可能にならないようにします（たとえば、RAPPOR などの差分プライバシー技術を使用して実装されます）。
    • [C-0-3] そのようなデータをデバイス上のユーザー ID（アカウントなど）に関連付けてはなりません。
    • [C-0-4] そのようなデータを、現在のセクション（9.8.17 プライバシー保護テレメトリー）で概説している要件に即していない他の OS コンポーネントと共有してはなりません。
    • [C-0-5] プライバシー保護テレメトリーの収集、使用、共有の有効、無効を切り替えるユーザー アフォーダンスを提供しなければなりません。
    • [C-0-6] そのようなデータがなんらかの形式でデバイスに保存される場合、実装によって収集されるデータを削除するユーザー アフォーダンスを提供しなければなりません。ユーザーがデータの消去を選択した場合、デバイスに現在保存されているデータをすべて削除しなければなりません。
    • [C-0-7] オープンソース リポジトリで、基盤になるプライバシー保護プロトコルの実装を開示しなければなりません。
    • [C-0-8] StatsLog で定義された制限付きの指標カテゴリのデータ収集を制御するために、このセクションのデータ出力ポリシーを適用しなければなりません。

  • 9.10. デバイスの完全性:

    改訂を確認する

    デバイス実装

    ファイルのコンテンツをページ単位で検証できる場合、デバイス実装は:

    • [C-0-3C-2-1] ファイル全体を読み取らずに、信頼できる鍵に対してファイルのコンテンツを暗号的に確認することをサポートします。

    • [C-0-4C-2-2] 読み取ったコンテンツが信頼できる鍵に対して確認されない上記の [C-2-1] に沿って確認されない場合、保護されたファイルの読み取りリクエストを許可してはなりません。

    • [C-2-4] 有効にしたファイルについては、O(1) でファイル チェックサムを返さなければなりません。

  • 9.11. 鍵と認証情報:

    改訂を確認する

    Android Keystore システムを使用すると、アプリ デベロッパーは暗号鍵をコンテナに格納し、KeyChain API または Keystore API を通じて暗号オペレーションで使用できます。デバイス実装は:

    • [C-0-3] 第 1 の認証に失敗できる回数を制限しなければなりません。
    • [C-SR-2] 第 1 の認証で失敗できる試行回数の上限として 20 回を実装し、ユーザーがこの機能に同意してオプトインした場合は、第 1 の認証の失敗できる試行回数の上限超過時に「データの初期化」を行うことが強く推奨されます。

    既知のシークレットに基づく場合はロック画面のロックを解除する認証方法を追加または変更し、画面をロックするセキュアな方法として新しい認証方法を使用する場合、デバイス実装は:

    • [C-SR-3] PIN は少なくとも 6 桁、または同等の 20 ビット エントロピーにすることが強く推奨されます。
    • [C-2-1] 6 桁未満の PIN の場合は、ユーザー操作なく自動入力されないようにして、PIN の桁数がわからないようにしなければなりません。

  • 9.11.1. セキュアロック画面、認証、仮想デバイス:

    改訂を確認する

    デバイス実装は:

    • [C-0-1] 第 1 の認証で失敗できる回数を制限しなければなりません。
    • [C-SR-5] 第 1 の認証で失敗できる試行回数の上限として 20 回を実装し、ユーザーがこの機能に同意してオプトインした場合は、第 1 の認証で失敗できる試行回数の上限を超過した際に「データの初期化」を行うことが強く推奨されます。

    デバイス実装で、数字の PIN を推奨の第 1 の認証方法として設定する場合の要件は次のとおりです。

    • [C-SR-6] PIN は少なくとも 6 桁、または同等の 20 ビット エントロピーにすることが強く推奨されます。
    • [C-SR-7] 6 桁未満の PIN の場合は、ユーザー操作なく自動入力されないようにして、PIN の桁数がわからないようにすることが強く推奨されます。

    セキュアロック画面があり、TrustAgentService システム API を実装する信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:

    [C-7-8] ユーザーの安全が懸念される場合（ドライバーの注意散漫など）を除き、少なくとも 72 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。

    アプリによるセカンダリ仮想ディスプレイの作成を許可して、関連する入力イベント（VirtualDeviceManager 経由など）をサポートし、ディスプレイに VIRTUAL_DISPLAY_FLAG_SECURE のマークがない場合、デバイス実装は:

    [C-13-10] 仮想デバイスから開始されたアプリのインストールを無効にしなければなりません。

  • 9.17. Android 仮想化フレームワーク:

    改訂を確認する

    デバイスが Android Virtualization Framework API（android.system.virtualmachine.*）のサポートを実装している場合、Android ホストは:

    • [C-1-1] android.system.virtualmachine パッケージで定義されたすべての API をサポートしなければなりません。
    • [C-1-2] Protected Virtual Machine（pVM）の管理用の Android SELinux と権限モデルを変更してはなりません。

    • [C-1-3] アップストリームの Android オープンソース プロジェクト（AOSP）で提供されている system/sepolicy 内に存在する neverallow ルールの変更、省略、置き換えを行ってはなりません。また、ポリシーは neverallow ルールがすべて存在する状態でコンパイルしなければなりません。

    • [C-1-4] プラットフォーム署名されたコードと特権アプリ以外信頼できないコード（サードパーティ アプリなど）、Protected Virtual MachinepVM を作成および実行できるようにしてはなりません。ただし、これは Android の今後のリリースで変更される可能性があります。

    • [C-1-5] Protected Virtual MachinepVM がファクトリー イメージまたはアップデートの一部ではないコードを実行できるようにしてはなりません。Android の確認付きブートの対象でないもの（インターネットからダウンロードしたファイルやサイドローディングされたファイルなど）は、Protected Virtual Machine で実行できないようにしなければなりません。

    • [C-1-5] デバッグ不可の pVM は、特権アプリへのアップデートを含むファクトリー イメージまたはプラットフォーム アップデートからのコードのみを実行できるようにしなければなりません。

    デバイスが Android Virtualization Framework API（android.system.virtualmachine.*）のサポートを実装している場合、Protected Virtual MachinepVM インスタンスは:

    • [C-2-1] Protected Virtual MachinepVM の仮想化 APEX で利用可能なすべてのオペレーティング システムを実行できなければなりません。
    • [C-2-2] Protected Virtual MachinepVM がデバイス実装者または OS ベンダーによって署名されていないオペレーティング システムを実行できるようにしてはなりません。
    • [C-2-3] Protected Virtual MachinepVM がデータをコードとして実行できるようにしてはなりません（SELinux neverallow execmem など）。

    • [C-2-4] アップストリームの Android オープンソース プロジェクト（AOSP）で提供されている system/sepolicy/microdroid 内に存在する neverallow ルールの変更、省略、置き換えを行ってはなりません。

    • [C-2-5] Microdroid 以外のオペレーティング システムであっても、Protected Virtual MachinepVM の多層防御メカニズム（pVM 用の SELinux など）を実装しなければなりません。
    • [C-2-6] 初期イメージを検証できない場合、VM が実行するイメージを検証できない場合、pVM が起動失敗ファームウェアが起動を拒否するようにしなければなりません。検証は VM 内で行わなければなりません。
    • [C-2-7] instance.img の整合性が侵害された場合、pVM が起動失敗ファームウェアが起動を拒否するようにしなければなりません。

    デバイスが Android Virtualization Framework API（android.system.virtualmachine.*）のサポートを実装している場合、ハイパーバイザは:

    • [C-3-1] VM（pVM またはホスト VM）が排他的に所有するメモリページには、他の仮想マシン（保護されているかどうかを問わず）ではなく、その仮想マシン自体またはハイパーバイザのみがアクセスできるようにしなければなりません。ページ所有者が明示的に共有していない限り、pVM が別のエンティティ（他の pVM やハイパーバイザ）に属するページにアクセスできるようにしてはなりません。これにはホスト VM が含まれます。また、これは CPU アクセスと DMA アクセスの両方に適用されます。
    • [C-3-2] ページが pVM で使用された後、ホストに返す前に、ページをワイプしなければなりません（pVM が破棄された場合など）。
    • [C-3-3SR-1] pVM のどのコードよりも先に、pVM ファームウェアが読み込まれて実行されるようにすることが強く推奨されますしなければなりません。
    • [C-3-4] 各 VM が pVM インスタンスに提供されるブート証明書チェーン（BCC）と複合デバイス識別子（CDI）がその特定の VM インスタンスからのみ取得でき、初期状態へのリセットおよび OTA に際し変更される VM ごとのシークレットを取得するようにしなければなりません。

    デバイスが Android Virtualization Framework API のサポートを実装している場合は、すべてのエリアで:

    • [C-4-1] Android セキュリティ モデルをバイパスできる機能を pVM に提供してはなりません。

    Android Virtualization Framework API のサポートを実装している場合、デバイスは:

    • [C-5-1] ART ランタイム アップデートの分離コンパイルをサポートできるようにしなければなりませんが、デバイス発送時には分離コンパイル機能を無効化しても構いません。

    デバイスが Android Virtualization Framework API のサポートを実装している場合、鍵管理について:

    • [C-6-1] ロック解除されたデバイスであっても、ユーザーが変更できないポイントに DICE チェーンのルートを設定しなければなりません（なりすましを防ぐため）。

    • [C-SR-26-2] VM ごとのシークレット取得メカニズムとして DICE を使用することが強く推奨されます。DICE を適切に行わなければなりません（正しい値を提供しなければなりません）。

トップへ戻る