Android 14 互換性定義

1. はじめに

このドキュメントでは、デバイスが Android 14 との互換性を維持するために満たさなければならない要件を列挙しています。

「しなければならない」、「してはならない」、「要求される」、「するものとする」、「しないものとする」、「すべきである」、「すべきではない」、「推奨される」、「しても構わない」、「任意」の使用は、RFC2119 で規定されている IETF 標準に従います。

このドキュメントで使用する「デバイス実装者」および「実装者」という用語は、Android 14 を実行するハードウェア / ソフトウェア ソリューションを開発する人または組織を指します。「デバイス実装」または「実装」とは、そのように開発されたハードウェア / ソフトウェア ソリューションを指します。

Android 14 と互換性があると見なされるには、デバイス実装で、この互換性定義に示された要件（参照により盛り込まれたドキュメントを含む）を満たさなければなりません。

この定義、またはセクション 10 に記載されているソフトウェア テストが、言及されていない、曖昧である、または不完全である場合、既存の実装との互換性を確保することはデバイス実装者の責任です。

このため、Android オープンソース プロジェクトは Android のリファレンス実装であり、優先実装です。デバイス実装者は可能な限り、Android オープンソース プロジェクトから入手できる「アップストリーム」のソースコードに基づいて実装することが強く推奨されます。一部のコンポーネントは仮に別の実装に置き換えることもできますが、ソフトウェア テストの合格が非常に困難になるため、そのような慣例には従わないことが強く推奨されます。互換性テストスイートなどを含む標準的な Android 実装との完全な動作互換性を確保することは、実装者の責任です。なお、このドキュメントでは特定のコンポーネントの置き換えと変更が明示的に禁止されています。

このドキュメントからリンクされているリソースの多くは、Android SDK から直接的または間接的に派生したものであり、その SDK のドキュメントに記載されている情報と機能的にまったく同じです。この互換性定義または互換性テストスイートと SDK ドキュメントの間に相違がある場合、SDK ドキュメントが正式なものであるとみなされます。このドキュメント全体を通し、リンク先のリソースに記載されている技術的な詳細情報はすべて、この互換性定義の一部とみなされます。

1.1 ドキュメント構造

1.1.1. デバイスタイプ別の要件

セクション 2 には、特定のデバイスタイプに適用される要件がすべて記載されています。セクション 2 の各サブセクションは、特定のデバイスタイプのみを対象としています。

あらゆる Android デバイス実装に普遍的に適用されるその他すべての要件については、セクション 2 の後のセクションに記載されています。このドキュメントでは、こうした要件を「コア要件」と呼びます。

1.1.2. 要件 ID

要件 ID は、「しなければならない」要件に割り当てられます。

  • ID は、「しなければならない」要件にのみ割り当てられます。
  • 「強く推奨される」要件は [SR] とマークされますが、ID は割り当てられません。
  • ID は、デバイスタイプ ID - 条件 ID - 要件 ID で構成されます（例: C-0-1）。

各 ID の定義は次のとおりです。

  • デバイスタイプ ID（詳細については 2. デバイスタイプをご覧ください）
    • C: コア（あらゆる Android デバイス実装に適用される要件）
    • H: Android ハンドヘルド デバイス
    • T: Android テレビデバイス
    • A: Android Automotive の実装
    • W: Android スマートウォッチ実装
    • Tab: Android タブレット実装
  • 条件 ID
    • 要件が無条件の場合、この ID は 0 と設定されます。
    • 要件が条件付きの場合、最初の条件に対して 1 が割り当てられ、同一セクション、同一デバイスタイプで数字が 1 ずつ増えます。
  • 要件 ID
    • この ID は 1 から始まり、同一セクション、同一条件で 1 ずつ増えます。

1.1.3. セクション 2 の要件 ID

セクション 2 の要件 ID は 2 つの部分で構成されています。最初の部分は、前述のセクション ID に対応しています。2 つ目の部分は、フォーム ファクタとフォーム ファクタ固有の要件を示します。

セクション ID の後に、要件 ID が続きます。

  • セクション 2 の ID は、セクション ID / デバイスタイプ ID - 条件 ID - 要件 ID で構成されます（例: 7.4.3/A-0-1）。

2. デバイスタイプ

Android オープンソース プロジェクトはさまざまなデバイスタイプやフォーム ファクタに使用できるソフトウェア スタックを提供しています。デバイスのセキュリティをサポートするために、ソフトウェア スタック（代替 OS または代替カーネル実装を含む）は、セクション 9 とこの CDD の他の部分に記載されているとおり、安全な環境で実行することが想定されています。アプリの配信エコシステムが比較的確立されているデバイスタイプもいくつかあります。

このセクションでは、こうしたデバイスタイプと、各デバイスタイプに適用される追加の要件と推奨事項について説明します。

記載されているデバイスタイプのいずれにも当てはまらない Android デバイス実装はすべて、この互換性定義の他のセクションに記載されている要件をすべて満たさなければなりません。

2.1 デバイス構成

デバイスタイプごとのハードウェア構成の主な違いについては、このセクションで後述するデバイス固有の要件をご覧ください。

2.2. ハンドヘルドの要件

Android ハンドヘルド デバイスとは、MP3 プレーヤー、スマートフォン、タブレットなど、通常は手に持って使用する Android デバイス実装を指します。

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

  • バッテリーなど、持ち運びを可能にする電源がある。
  • 物理的な対角画面サイズが 4 インチ 3.3 インチ（API レベル 29 以前で出荷されたデバイス実装の場合は 2.5 インチ）から 8 インチの範囲内。
  • タッチスクリーン入力インターフェースがある。

このセクションでこれ以降記載する追加要件は、Android ハンドヘルド デバイス実装に固有のものです。

注: Android タブレット デバイスに適用されない要件には「*」を付しています。

2.2.1. ハードウェア

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

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

  • [7.1.1.3/H-SR-1] 表示サイズ（画面密度）を変更するアフォーダンスをユーザーに提供することが強く推奨されます。

  • [7.1.1.1/H-0-2] グラフィック バッファが内蔵ディスプレイの最高解像度と同程度以上である GPU 合成をサポートしなければなりません。

新しい要件の開始

  • [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% または実際の対応ディスプレイの物理密度よりも大きく設定しなければなりません。

新しい要件の終了

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

  • [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 以前で出荷されたデバイスについては、この要件を免除しても構いません。

新しい要件の開始

Vulkan のサポートが含まれる場合、ハンドヘルド デバイス実装は:

新しい要件の終了

Configuration.isScreenHdr() を通じてハイ ダイナミック レンジ表示のサポートを主張する場合、ハンドヘルド デバイス実装は:

  • [7.1.4.5/H-1-1] 拡張機能 EGL_EXT_gl_colorspace_bt2020_pq、EGL_EXT_surface_SMPTE2086_metadata、EGL_EXT_surface_CTA861_3_metadata、VK_EXT_swapchain_colorspace、VK_EXT_hdr_metadata のサポートをアドバタイズしなければなりません。

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

  • [7.1.4.6/H-0-1] システム プロパティ graphics.gpu.profiler.support を介して、デバイスが GPU プロファイリングをサポートしているかどうかをレポートしなければなりません。

システム プロパティ graphics.gpu.profiler.support を介してサポートを宣言する場合、ハンドヘルド デバイス実装は:

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

  • [7.1.5/H-0-1] アップストリームの Android オープンソース コードで実装されたレガシーアプリ互換モードのサポートを含まなければなりません。つまり、デバイス実装は、互換モードが有効になるトリガーまたはしきい値を変更してはなりません。また、互換モード自体の動作を変更してはなりません。
  • [7.2.1/H-0-1] サードパーティのインプット メソッド エディタ（IME）アプリのサポートを含まなければなりません。
  • [7.2.3/H-0-2] 戻る機能（KEYCODE_BACK）の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。これらのイベントはシステムで使用してはならず、Android デバイスの外部（Android デバイスに接続された外部ハードウェア キーボードなど）からトリガーできます。
  • [7.2.3/H-0-3] ホーム画面を提供するすべての Android 互換ディスプレイでホーム機能を提供しなければなりません。
  • [7.2.3/H-0-4] すべての Android 互換ディスプレイで戻る機能を提供し、少なくとも 1 つの Android 互換ディスプレイで履歴機能を提供しなければなりません。
  • [7.2.4/H-0-1] タッチスクリーン入力をサポートしなければなりません。
  • [7.2.4/H-SR-1] ユーザー選択のアシストアプリ（つまり VoiceInteractionService を実装するアプリ）を起動すること、あるいは、フォアグラウンド アクティビティが長押しイベントを処理しない場合は KEYCODE_MEDIA_PLAY_PAUSE または KEYCODE_HEADSETHOOK の長押しで ACTION_ASSIST を処理するアクティビティを起動することが強く推奨されます。
  • [7.3.1/H-SR-1] 3 軸加速度計を含むことが強く推奨されます。

3 軸加速度計が含まれる場合、ハンドヘルド デバイス実装は:

  • [7.3.1/H-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。

GPS / GNSS レシーバーが含まれ、android.hardware.location.gps 機能フラグを通じてアプリに機能をレポートする場合、ハンドヘルド デバイス実装は:

  • [7.3.3/H-2-1] GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GNSS 測定値が判明したらすぐにレポートしなければなりません。
  • [7.3.3/H-2-2] 全天条件下で、位置を特定した後に、静止しているか加速度 0.2 m/s 未満で移動している間、位置 20 m 以内、速度 0.2 m/s 以内、時間 95% 以上を計算するのに十分な、GNSS の擬似距離と擬似距離レートをレポートしなければなりません。

3 軸ジャイロスコープが含まれる場合、ハンドヘルド デバイス実装は:

  • [7.3.4/H-3-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
  • [7.3.4/H-3-2] 1,000 度/秒までの方向変化を測定できなければなりません。

音声通話を行い、getPhoneType に PHONE_TYPE_NONE 以外の値を示せるハンドヘルド デバイス実装は:

  • [7.3.8/H] 近接センサーを含むべきです。

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

  • [7.3.11/H-SR-1] 6 自由度の姿勢センサーをサポートすることが強く推奨されます。
  • [7.4.3/H] Bluetooth と Bluetooth LE のサポートを含むべきです。

デバイスが PackageManager.FEATURE_WIFI_AWARE を宣言して Wi-Fi Neighbor Awareness Networking（NAN）プロトコルをサポートしている場合と、PackageManager.FEATURE_WIFI_RTT を宣言して Wi-Fi Location（Wi-Fi ラウンドトリップ時間 - RTT）をサポートしている場合、それらのデバイスは:

  • [7.4.2.5/H-1-1] WifiRttManager#startRanging Android API を介して確認した 10 cm、1 m、3 m、5 m の距離における範囲を、累積分布関数で計算し、帯域幅 160 MHz では 68 パーセンタイルで正確度 +/-1 メートル以内、80 MHz 帯域幅では 68 パーセンタイルで正確度 +/-2 メートル以内、40 MHz 帯域幅では 68 パーセンタイルで正確度 +/-4 メートル以内、20 MHz 帯域幅では 68 パーセンタイルで正確度 +/-8 メートル以内でレポートしなければなりません。

  • [7.4.2.5/H-SR-1] WifiRttManager#startRanging Android API を介して確認した 10 cm の距離における範囲を、累積分布関数で計算し、帯域幅 160 MHz では 90 パーセンタイルで正確度 +/-1 メートル以内、80 MHz 帯域幅では 90 パーセンタイルで正確度 +/-2 メートル以内、40 MHz 帯域幅では 90 パーセンタイルで正確度 +/-4 メートル以内、20 MHz 帯域幅では 90 パーセンタイルで正確度 +/-8 メートル以内でレポートすることが強く推奨されます。

プレゼンス キャリブレーションで指定されている測定のセットアップ手順に沿うことが強く推奨されます。

新しい要件の開始

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 オフセットを測定し補正しなければなりません。

新しい要件の終了

CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA を使用して機能をリストする論理カメラデバイスが含まれる場合、ハンドヘルド デバイス実装は:

  • [7.5.4/H-1-1] デフォルトで通常の視野（FOV）を持たなければならず、50 度から 95 度の間でなければなりません。

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

  • [7.6.1/H-0-1] アプリの個人データ（「/data」パーティション）に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。
  • [7.6.1/H-0-2] カーネルとユーザー空間に利用できるメモリが 1 GB 未満の場合、ActivityManager.isLowRamDevice() について「true」を返さなければなりません。

32 ビット ABI のみのサポートを宣言する場合、ハンドヘルド デバイス実装は:

  • [7.6.1/H-1-1] デフォルト ディスプレイで qHD までのフレームバッファ解像度を使用する場合（例: FWVGA）、カーネルとユーザー空間に利用できるメモリが少なくとも 416 MB でなければなりません。

  • [7.6.1/H-2-1] デフォルト ディスプレイで HD+ までのフレームバッファ解像度を使用する場合（例: HD、WSVGA）、カーネルとユーザー空間に利用できるメモリが少なくとも 592 MB でなければなりません。

  • [7.6.1/H-3-1] デフォルト ディスプレイで FHD までのフレームバッファ解像度を使用する場合（例: WSXGA+）、カーネルとユーザー空間に利用できるメモリが少なくとも 896 MB でなければなりません。

  • [7.6.1/H-4-1] デフォルト ディスプレイで QHD までのフレームバッファ解像度を使用する場合（例: QWXGA）、カーネルとユーザー空間に利用できるメモリが少なくとも 1,344 MB でなければなりません。

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

  • [7.6.1/H-5-1] デフォルト ディスプレイで qHD までのフレームバッファ解像度を使用する場合（例: FWVGA）、カーネルとユーザー空間に利用できるメモリが少なくとも 816 MB でなければなりません。

  • [7.6.1/H-6-1] デフォルト ディスプレイで HD+ までのフレームバッファ解像度を使用する場合（例: HD、WSVGA）、カーネルとユーザー空間に利用できるメモリが少なくとも 944 MB でなければなりません。

  • [7.6.1/H-7-1] デフォルト ディスプレイで FHD までのフレームバッファ解像度を使用する場合（例: WSXGA+）、カーネルとユーザー空間に利用できるメモリが少なくとも 1,280 MB でなければなりません。

  • [7.6.1/H-8-1] デフォルト ディスプレイで QHD までのフレームバッファ解像度を使用する場合（例: QWXGA）、カーネルとユーザー空間に利用できるメモリが少なくとも 1,824 MB でなければなりません。

なお、上記の「カーネルとユーザー空間に利用できるメモリ」とは、デバイス実装でカーネルの制御下にない、無線や動画などのハードウェア コンポーネント専用のメモリに加えて提供されるメモリ空間を指します。

カーネルとユーザー空間に利用できるメモリが 1 GB 以下の場合、ハンドヘルド デバイス実装は:

  • [7.6.1/H-9-1] 機能フラグ android.hardware.ram.low を宣言しなければなりません。
  • [7.6.1/H-9-2] アプリの個人データ（「/data」パーティション）用の不揮発性ストレージが少なくとも 1.1 GB でなければなりません。

カーネルとユーザー空間に利用できるメモリが 1 GB を超える場合、ハンドヘルド デバイス実装は:

  • [7.6.1/H-10-1] アプリの個人データ（「/data」パーティション）に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。
  • 機能フラグ android.hardware.ram.normal を宣言すべきです。

カーネルとユーザー空間に利用できるメモリが 2 GB 以上 4 GB 未満の場合、ハンドヘルド デバイス実装は:

  • [7.6.1/H-SR-1] 32 ビットユーザー空間のみをサポートすることが強く推奨されます（アプリとシステムコードの両方）。

カーネルとユーザー空間に利用できるメモリが 2 GB 未満の場合、ハンドヘルド デバイス実装は:

  • [7.6.1/H-1-1] 1 つの ABI のみ（64 ビットのみ、または 32 ビットのみ）をサポートしなければなりません。

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

  • [7.6.2/H-0-1] アプリ共有ストレージが 1 GiB 未満であってはなりません。
  • [7.7.1/H] ペリフェラル モードをサポートする USB ポートを含むべきです。

ペリフェラル モードをサポートする USB ポートが含まれる場合、ハンドヘルド デバイス実装は:

  • [7.7.1/H-1-1] Android Open Accessory（AOA）API を実装しなければなりません。

ホストモードをサポートする USB ポートが含まれる場合、ハンドヘルド デバイス実装は:

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

  • [7.8.1/H-0-1] マイクを含まなければなりません。
  • [7.8.2/H-0-1] オーディオ出力がなければならず、android.hardware.audio.output を宣言しなければなりません。

VR モードをサポートするためのパフォーマンス要件をすべて満たすことができ、そのサポートが含まれる場合、ハンドヘルド デバイス実装は:

  • [7.9.1/H-1-1] android.hardware.vr.high_performance 機能フラグを宣言しなければなりません。
  • [7.9.1/H-1-2] android.app.Activity#setVrModeEnabled を介して VR アプリで有効にできる android.service.vr.VrListenerService を実装するアプリを含まなければなりません。

ホストモードの USB-C ポートを 1 つ以上含んで実装（USB オーディオ クラス）する場合、セクション 7.7.2 の要件に加え、ハンドヘルド デバイス実装は:

  • [7.8.2.2/H-1-1] 次に示す HID コードのソフトウェア マッピングを提供しなければなりません。
機能 マッピング コンテキスト 動作
A HID 使用ページ: 0x0C
HID 使用: 0x0CD
カーネルキー: KEY_PLAYPAUSE
Android キー: KEYCODE_MEDIA_PLAY_PAUSE		 メディア再生 入力: 短押し
出力: 再生または一時停止
入力: 長押し
出力: 音声コマンドを起動
送信: デバイスがロックされているか画面がオフの場合は android.speech.action.VOICE_SEARCH_HANDS_FREE を、それ以外の場合は android.speech.RecognizerIntent.ACTION_WEB_SEARCH を送信
着信 入力: 短押し
出力: 着信に応答
入力: 長押し
出力: 通話を拒否
通話中 入力: 短押し
出力: 通話を終了
入力: 長押し
出力: マイクをミュートまたはミュート解除
B HID 使用ページ: 0x0C
HID 使用: 0x0E9
カーネルキー: KEY_VOLUMEUP
Android キー: VOLUME_UP		 メディア再生、通話中 入力: 短押しまたは長押し
出力: システムまたはヘッドセットの音量を上げる
C HID 使用ページ: 0x0C
HID 使用: 0x0EA
カーネルキー: KEY_VOLUMEDOWN
Android キー: VOLUME_DOWN		 メディア再生、通話中 入力: 短押しまたは長押し
出力: システムまたはヘッドセットの音量を下げる
D HID 使用ページ: 0x0C
HID 使用: 0x0CF
カーネルキー: KEY_VOICECOMMAND
Android キー: KEYCODE_VOICE_ASSIST		 すべて。任意のインスタンスでトリガー可能。 入力: 短押しまたは長押し
出力: 音声コマンドを起動
  • [7.8.2.2/H-1-2] プラグ挿入時に ACTION_HEADSET_PLUG をトリガーしなければなりません。ただし、接続されている端子のタイプを識別するために USB オーディオ インターフェースとエンドポイントが適切に列挙された後に限ります。

USB オーディオ端子タイプ 0x0302 が検出された場合:

  • [7.8.2.2/H-2-1] 「microphone」エクストラを 0 に設定してインテント ACTION_HEADSET_PLUG をブロードキャストしなければなりません。

USB オーディオ端子タイプ 0x0402 が検出された場合:

  • [7.8.2.2/H-3-1] 「microphone」エクストラを 1 に設定してインテント ACTION_HEADSET_PLUG をブロードキャストしなければなりません。

USB 周辺機器が接続されている間に API AudioManager.getDevices() が呼び出された場合:

  • [7.8.2.2/H-4-1] USB オーディオ端子タイプのフィールドが 0x0302 であれば、タイプ AudioDeviceInfo.TYPE_USB_HEADSET、ロール isSink() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-4-2] USB オーディオ端子タイプのフィールドが 0x0402 であれば、タイプ AudioDeviceInfo.TYPE_USB_HEADSET、ロール isSink() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-4-3] USB オーディオ端子タイプのフィールドが 0x0402 であれば、タイプ AudioDeviceInfo.TYPE_USB_HEADSET、ロール isSource() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-4-4] USB オーディオ端子タイプのフィールドが 0x603 であれば、タイプ udioDeviceInfo.TYPE_USB_DEVICE、ロール isSink() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-4-5] USB オーディオ端子タイプのフィールドが 0x604 であれば、タイプ AudioDeviceInfo.TYPE_USB_DEVICE、ロール isSource() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-4-6] USB オーディオ端子タイプのフィールドが 0x400 であれば、タイプ AudioDeviceInfo.TYPE_USB_DEVICE、ロール isSink() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-4-7] USB オーディオ端子タイプのフィールドが 0x400 であれば、タイプ AudioDeviceInfo.TYPE_USB_DEVICE、ロール isSource() のデバイスをリストしなければなりません。

  • [7.8.2.2/H-SR-1] USB-C オーディオ周辺機器の接続時、USB 記述子の列挙、端子タイプの特定、インテント ACTION_HEADSET_PLUG のブロードキャストを、1,000 ミリ秒未満で実施することが強く推奨されます。

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 つ以上含まれる場合、ハンドヘルド デバイス実装は:

リニア共振アクチュエータ（LRA）は、質点を目的の運動方向に並進させる主共振周波数を持つ、単一のばね質量系です。

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

新しい要件の開始

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

新しい要件の終了

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

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

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

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

2.2.2. マルチメディア

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

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] MPEG-4 AAC プロファイル（AAC LC）
  • [5.1/H-0-4] MPEG-4 HE AAC プロファイル（AAC+）
  • [5.1/H-0-5] AAC ELD（Enhanced Low Delay AAC）

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

  • [5.2/H-0-1] H.264 AVC
  • [5.2/H-0-2] VP8

新しい要件の開始

  • [5.2/H-0-3] AV1

新しい要件の終了

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

  • [5.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9

新しい要件の開始

  • [5.3/H-0-6] AV1

新しい要件の終了

2.2.3. ソフトウェア

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

  • [3.2.3.1/H-0-1] SDK ドキュメントに記載されているとおり、インテント ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE、ACTION_CREATE_DOCUMENT を処理するアプリを持ち、DocumentsProvider API を使用してドキュメント プロバイダ データにアクセスするユーザー アフォーダンスを提供しなければなりません。
  • [3.2.3.1/H-0-2]* こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
  • [3.2.3.1/H-SR-1] インテント ACTION_SENDTO、ACTION_SEND、または ACTION_SEND_MULTIPLE を処理してメールを送信できるメールアプリをプリロードすることが強く推奨されます。
  • [3.4.1/H-0-1] android.webkit.Webview API の完全な実装を提供しなければなりません。
  • [3.4.2/H-0-1] 一般ユーザーのウェブ ブラウジング用のスタンドアロン ブラウザアプリを含まなければなりません。
  • [3.8.1/H-SR-1] ショートカット、ウィジェット、widgetFeatures のアプリ内固定をサポートするデフォルト ランチャーを実装することが強く推奨されます。
  • [3.8.1/H-SR-2] ShortcutManager API を介してサードパーティ アプリで提供される追加のショートカットにすばやくアクセスできるようにするデフォルト ランチャーを実装することが強く推奨されます。
  • [3.8.1/H-SR-3] アプリアイコンにバッジを表示するデフォルト ランチャー アプリを含むことが強く推奨されます。
  • [3.8.2/H-SR-1] サードパーティ アプリ ウィジェットをサポートすることが強く推奨されます。
  • [3.8.3/H-0-1] API クラス Notification と NotificationManager を介してサードパーティ アプリがユーザーに重要なイベントを通知することを許可しなければなりません。
  • [3.8.3/H-0-2] リッチ通知をサポートしなければなりません。
  • [3.8.3/H-0-3] ヘッドアップ通知をサポートしなければなりません。
  • [3.8.3/H-0-4] AOSP で実装されるように、アクション ボタンやコントロール パネルなどのユーザー アフォーダンスを通じてユーザーが通知を直接コントロール（返信、スヌーズ、拒否、ブロックなど）できるようにする通知シェードを含まなければなりません。
  • [3.8.3/H-0-5] RemoteInput.Builder setChoices() を通じて提供する選択肢を通知シェードに表示しなければなりません。
  • [3.8.3/H-SR-1] RemoteInput.Builder setChoices() を通じて提供される最初の選択肢を、追加のユーザー操作なしで通知シェードに表示することが強く推奨されます。
  • [3.8.3/H-SR-2] ユーザーが通知シェード内の通知をすべて開いた際に、RemoteInput.Builder setChoices() を通じて提供されるすべての選択肢を通知シェードに表示することが強く推奨されます。
  • [3.8.3.1/H-SR-1] Notification.Action.Builder.setContextual が true に設定されているアクションを、Notification.Remoteinput.Builder.setChoices によって表示される返信に沿って表示することが強く推奨されます。
  • [3.8.4/H-SR-1] アシスト アクションを処理するために、デバイスにアシスタントを実装することが強く推奨されます。

MediaStyle 通知をサポートする場合、ハンドヘルド デバイス実装は:

  • [3.8.3.1/H-SR-2] MediaSession トークンを含む MediaStyle 通知をアプリが送信したときに、使用できる適切なメディアルート間（例: Bluetooth デバイスや MediaRouter2Manager に提供されるルート）での切り替えをユーザーができるようにする、システム UI からアクセスできるユーザー アフォーダンス（例: 出力の切り替え）を提供することが強く推奨されます。

新しい要件の開始

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

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

新しい要件の終了

アシスト アクションをサポートする場合、ハンドヘルド デバイス実装は:

  • [3.8.4/H-SR-2] セクション 7.2.3 に記載されているとおり、アシストアプリを起動するための指定操作として HOME キーの長押しを使用することが強く推奨されます。ユーザー選択のアシストアプリ（つまり VoiceInteractionService を実装するアプリ）または ACTION_ASSIST インテントを処理するアクティビティを起動しなければなりません。

conversation notifications をサポートし、アラート通知と会話以外のサイレント通知とは別のセクションにグループ化する場合、ハンドヘルド デバイス実装は:

  • [3.8.4/H-1-1]* 進行中のフォアグラウンド サービス通知と importance:high の通知を除き、会話以外の通知より前に会話通知を表示しなければなりません。

ロック画面をサポートする場合、Android ハンドヘルド デバイス実装は:

  • [3.8.10/H-1-1] メディア通知テンプレートを含め、ロック画面通知を表示しなければなりません。

セキュアロック画面をサポートする場合、ハンドヘルド デバイス実装は:

  • [3.9/H-1-1] Android SDK ドキュメントで規定されているすべてのデバイス管理ポリシーを実装しなければなりません。

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

  • [3.8.16/H-1-1] 機能フラグ android.software.controls を宣言し、true に設定しなければなりません。
  • [3.8.16/H-1-2] ControlsProviderService API と Control API を通じてサードパーティ アプリで登録されたコントロールから、ユーザーのお気に入りのデバイス コントロールを追加、編集、選択、操作できるユーザー アフォーダンスを提供しなければなりません。
  • [3.8.16/H-1-3] デフォルト ランチャーから 3 操作以内で、このユーザー アフォーダンスへのアクセスを提供しなければなりません。

  • [3.8.16/H-1-4] このユーザー アフォーダンスに、ControlsProviderService API を介してコントロールを提供する各サードパーティ アプリの名前とアイコン、また Control API で提供される指定のフィールドを、正確にレンダリングしなければなりません。

  • [3.8.16/H-1-5] ControlsProviderService と Control Control.isAuthRequired 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] に定められている設定の値を渡さなければなりません。

新しい要件の終了

逆に、このようなコントロールを実装しない場合、ハンドヘルド デバイス実装は:

ハンドヘルド デバイスがロックタスク モードで動作していないときに、コンテンツがクリップボードにコピーされた場合、ハンドヘルド デバイス実装は:

  • [3.8.17/H-1-1] ユーザーに対して、データがクリップボードにコピーされたことの確認（サムネイルや「コンテンツをコピーしました」など）を表示しなければなりません。さらに、クリップボード データがデバイス間で同期されるかどうかも示します。

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

  • [3.10/H-0-1] サードパーティのユーザー補助サービスをサポートしなければなりません。
  • [3.10/H-SR-1] talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack（プリインストールのテキスト読み上げエンジンでサポートされている言語）のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。
  • [3.11/H-0-1] サードパーティ TTS エンジンのインストールをサポートしなければなりません。
  • [3.11/H-SR-1] デバイスで利用可能な言語をサポートする TTS エンジンを含むことが強く推奨されます。
  • [3.13/H-SR-1] クイック設定 UI コンポーネントを含むことが強く推奨されます。

FEATURE_BLUETOOTH または FEATURE_WIFI のサポートを宣言する場合、Android ハンドヘルド デバイス実装は:

  • [3.16/H-1-1] コンパニオン デバイスのペア設定機能をサポートしなければなりません。

ナビゲーション機能が画面上のジェスチャーベースのアクションとして提供される場合:

  • [7.2.3/H] ホーム機能のためのジェスチャー認識ゾーンは、画面の底部から高さ 32 dp 以下であるべきです。

ナビゲーション機能を画面の左端または右端の任意の場所からのジェスチャーとして提供する場合、ハンドヘルド デバイス実装は:

  • [7.2.3/H-0-1] ナビゲーション機能のジェスチャー エリアは、両側で幅 40 dp 未満でなければなりません。ジェスチャー エリアは、デフォルトで幅 24 dp であるべきです。

セキュアロック画面をサポートし、カーネルとユーザー空間に利用できるメモリが 2 GB 以上の場合、ハンドヘルド デバイス実装は:

  • [3.9/H-1-2] android.software.managed_users 機能フラグを介して管理対象プロファイルのサポートを宣言しなければなりません。

android.hardware.camera.any を介してカメラのサポートを宣言する場合、Android ハンドヘルド デバイス実装は:

アクティビティの埋め込みを使用して、デバイス実装の設定アプリに分割機能を実装する場合、デバイス実装は:

新しい要件の開始

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

新しい要件の終了

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

  • [8.1/H-0-1] 一貫したフレーム レイテンシ。一貫性のないフレーム レイテンシ、またはフレームのレンダリングの遅延は、1 秒間に 5 フレームを超えて発生してはならず、1 秒間に 1 フレーム未満であるべきです。
  • [8.1/H-0-2] ユーザー インターフェースのレイテンシ。デバイス実装は、Android 互換性テストスイート（CTS）で定義された 10,000 リストエントリのリストを 36 秒未満でスクロールすることで、低レイテンシのユーザー エクスペリエンスを実現しなければなりません。
  • [8.1/H-0-3] タスクの切り替え。複数のアプリが起動されている場合、起動後に実行中のアプリを再起動するまでにかかる時間は 1 秒未満でなければなりません。

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

  • [8.2/H-0-1] 少なくとも 5 MB/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
  • [8.2/H-0-2] 少なくとも 0.5 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
  • [8.2/H-0-3] 少なくとも 15 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
  • [8.2/H-0-4] 少なくとも 3.5 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。

AOSP に含まれるデバイス電源管理を改善する機能を含むか、AOSP に含まれる機能を拡張する場合、ハンドヘルド デバイス実装は:

  • [8.3/H-1-1] バッテリー セーバー機能を有効または無効にするユーザー アフォーダンスを提供しなければなりません。
  • [8.3/H-1-2] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供しなければなりません。

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

  • [8.4/H-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
  • [8.4/H-0-2] すべての消費電力値をミリアンペア時（mAh）単位でレポートしなければなりません。
  • [8.4/H-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、uid_cputime カーネル モジュール実装を通じて要件を満たしています。
  • [8.4/H-0-4] この電力使用量を、adb shell dumpsys batterystats シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。
  • [8.4/H] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。

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

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

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

新しい要件の開始

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

新しい要件の終了

2.2.5. セキュリティ モデル

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

  • [9/H-0-1] android.hardware.security.model.compatible 機能を宣言しなければなりません。
  • [9.1/H-0-1] サードパーティ アプリが android.permission.PACKAGE_USAGE_STATS 権限を介して使用統計情報にアクセスできるようにし、android.settings.ACTION_USAGE_ACCESS_SETTINGS インテントに応じて、そのようなアプリへのアクセス権を付与または取り消す、ユーザーがアクセス可能なメカニズムを提供しなければなりません。

新しい要件の開始

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

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

新しい要件の終了

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

  • [9.11/H-0-2] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
  • [9.11/H-0-3] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト（AOSP）は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザベースの隔離オプションをセキュアに実装する方法を選択することもできます。
  • [9.11/H-0-4] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer（HAL）と Trusty を提供しており、これを使用してこの要件を満たすことができます。
  • [9.11/H-0-5] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。

なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint 機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵構成証明をサポートする必要があるという要件を免除されます。

セキュアロック画面をサポートする場合、ハンドヘルド デバイス実装は:

  • [9.11/H-1-1] ユーザーが最短のスリープ タイムアウト（ロック解除状態からロック状態への遷移時間）を 15 秒以下として選択できるようにしなければなりません。
  • [9.11/H-1-2] 通知を非表示にし、9.11.1 セキュアロック画面に記載されている第 1 の認証を除くすべての形式の認証を無効にするユーザー アフォーダンスを提供しなければなりません。AOSP は、ロックダウン モードとしての要件を満たしています。

新しい要件の開始

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

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

新しい要件の終了

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言しない場合、ハンドヘルド デバイス実装は:

  • [9.5/H-2-1] 制限付きプロファイル（追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能）をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言する場合、ハンドヘルド デバイス実装は:

  • [9.5/H-3-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。

新しい要件の開始

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

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

新しい要件の終了

Android はシステム API の VoiceInteractionService を通じて、マイクへのアクセスを示すことなく起動ワードを常時安全に検出するメカニズムをサポートしています。また、マイクまたはカメラへのアクセスを示すことなくクエリを常時検出するメカニズムもサポートしています。

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

  • [9.8/H-1-1] 起動ワード検出サービスがデータを送信できる対象を、システム、ContentCaptureService、または SpeechRecognizer#createOnDeviceSpeechRecognizer() によって作成されたデバイス上の音声認識サービスに限定しなければなりません。
  • [9.8/H-1-2] 起動ワード検出サービスがマイクの音声データまたはその派生データを送信できる対象を、HotwordDetectionService API を通じたシステム サーバーか、ContentCaptureManager API を通じた ContentCaptureService に限定しなければなりません。
  • [9.8/H-1-3] 個々のハードウェアでトリガーされたリクエストについて、30 秒間を超えるマイク音声を起動ワード検出サービスに供給してはなりません。
  • [9.8/H-1-4] 個々のリクエストについて、8 秒間を超えてバッファリングされたマイク音声を起動ワード検出サービスに供給してはなりません。
  • [9.8/H-1-5] 30 秒間を超えてバッファリングされたマイク音声を音声操作サービスまたは同様のエンティティに供給してはなりません。
  • [9.8/H-1-6] 成功した各起動ワード結果について、100 バイトを超えるデータを起動ワード検出サービスから送信できるようにしてはなりません。ただし、HotwordAudioStream を介して渡されたオーディオ データは除きます。
  • [9.8/H-1-7] 否定的な各起動ワード結果について、5 ビットを超えるデータを起動ワード検出サービスから送信できるようにしてはなりません。
  • [9.8/H-1-8] システム サーバーから起動ワード検証リクエストがあった場合にのみ、起動ワード検出サービスからのデータ送信を許可しなければなりません。
  • [9.8/H-1-9] ユーザーによるインストールが可能なアプリが起動ワード検出サービスを提供できるようにしてはなりません。
  • [9.8/H-1-10] 起動ワード検出サービスによるマイクの使用に関する定量的データを UI に表示してはなりません。
  • [9.8/H-1-11] セキュリティ研究者が検査できるように、起動ワード検出サービスからのすべての送信に含まれるバイト数をログに記録しなければなりません。
  • [9.8/H-1-12] セキュリティ研究者が検査できるように、起動ワード検出サービスからのすべての送信の未加工コンテンツをログに記録するデバッグモードをサポートしなければなりません。
  • [9.8/H-1-14] 成功した起動ワード結果が音声操作サービスまたは同様のエンティティに送信された場合に、セクション 9.8.2 で説明されているマイク インジケーターを表示しなければなりません。

新しい要件の開始

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

新しい要件の終了

  • [9.8/H-SR-1] 起動ワード検出サービスのプロバイダとしてアプリを設定する前に、ユーザーに通知することが強く推奨されます。
  • [9.8/H-SR-2] 起動ワード検出サービスからの非構造化データの送信を禁止することが強く推奨されます。
  • [9.8/H-SR-3] 起動ワード検出サービスをホストするプロセスを、少なくとも 1 時間に 1 回、またはハードウェア トリガー イベント 30 回ごとに（どちらか早い方）、再起動することが強く推奨されます。

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

  • [9.8/H-2-1] サポートされている各起動ワードフレーズについて、ユーザーに明示的な通知を提供しなければなりません。
  • [9.8/H-2-2] 起動ワード検出サービスを通じて、未加工音声データまたはその派生データを保持してはなりません。
  • [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] ユーザーがインストール可能なアプリが、ビジュアル クエリ検出サービスを提供できるようにしてはなりません。

新しい要件の終了

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

  • [9.8.2/H-4-1] アプリがマイクからオーディオ データにアクセスしているときはマイク インジケーターを表示しなければなりません。ただし、HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService、またはセクション 9.1 で CDD 識別子 [C-4-X] が割り当てられたロールを持つアプリからのみマイクにアクセスする場合は、この限りではありません。
  • [9.8.2/H-4-2] PermissionManager.getIndicatorAppOpUsageData() から返された、マイクを使用している最近使ったアプリとアクティブなアプリのリストを、関連する属性メッセージとともに表示しなければなりません。

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

  • [9.8.2/H-5-1] アプリがライブ カメラデータにアクセスしているときはカメラ インジケーターを表示しなければなりません。ただし、セクション 9.1 で CDD 識別子 [C-4-X] が割り当てられたロールを持つアプリからのみカメラにアクセスする場合は、この限りではありません。
  • [9.8.2/H-5-2] PermissionManager.getIndicatorAppOpUsageData() から返された、カメラを使用している最近使ったアプリとアクティブなアプリを、関連する属性メッセージとともに表示しなければなりません。

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

ハンドヘルド デバイス実装は（* タブレットには適用されません）:

  • [6.1/H-0-1]* シェルコマンド cmd testharness をサポートしなければなりません。

ハンドヘルド デバイス実装は（* タブレットには適用されません）:

  • Perfetto
    • [6.1/H-0-2]* cmdline で perfetto ドキュメントを遵守しているシェルユーザーに /system/bin/perfetto バイナリを公開しなければなりません。
    • [6.1/H-0-3]* perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れなければなりません。
    • [6.1/H-0-4]* perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込まなければなりません。
    • [6.1/H-0-5]* 少なくとも perfetto ドキュメントで規定されたデータソースを、perfetto バイナリを通じて提供しなければなりません。
    • [6.1/H-0-6]* perfetto traced デーモンは、デフォルトで有効でなければなりません（システム プロパティ persist.traced.enable）。

2.2.7. ハンドヘルドのメディア パフォーマンス クラス

メディア パフォーマンス クラスの定義については、セクション 7.11 をご覧ください。

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）に少なくとも 6 つのハードウェア オーバーレイがなければならず、そのうち 2 つ以上で 10 ビットの動画コンテンツを表示できなければなりません。

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

新しい要件の終了

2.2.7.2. カメラ

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 を返す場合、ハンドヘルド デバイス実装は:

  • [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 プロパティをサポートし、プライマリ前面カメラについては LIMITED 以上の同プロパティをサポートしなければなりません。
  • [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.T を返す場合、ハンドヘルド デバイス実装は:

新しい要件の開始

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.T を返す場合、ハンドヘルド デバイス実装は:

新しい要件の開始

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. テレビの要件

Android テレビデバイスとは、約 10 フィート離れた場所にいるユーザーがデジタル メディア、映画、ゲーム、アプリ、ライブテレビを楽しむためのエンターテイメント インターフェースである Android デバイス実装を指します（「鑑賞モード」または「10 フィート ユーザー インターフェース」）。

次の基準をすべて満たす場合、Android デバイス実装はテレビに分類されます。

  • ユーザーから 10 フィート離れたディスプレイに表示されるユーザー インターフェースをリモコンで操作するためのメカニズムを提供する。
  • 対角長が 24 インチを超える埋め込みスクリーン ディスプレイがある、または、VGA、HDMI、DisplayPort、ディスプレイ用ワイヤレス ポートなどの動画出力ポートがある。

このセクションでこれ以降記載する追加要件は、Android テレビデバイス実装に固有のものです。

2.3.1. ハードウェア

テレビデバイス実装は:

  • [7.2.2/T-0-1] D-pad をサポートしなければなりません。
  • [7.2.3/T-0-1] ホーム機能と戻る機能を提供しなければなりません。
  • [7.2.3/T-0-2] 戻る機能（KEYCODE_BACK）の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。
  • [7.2.6.1/T-0-1] ゲーム コントローラのサポートを含まなければならず、android.hardware.gamepad 機能フラグを宣言しなければなりません。
  • [7.2.7/T] ユーザーがタップ以外のナビゲーションと主要なナビゲーション キー入力にアクセスできるリモコンを提供すべきです。

3 軸ジャイロスコープが含まれる場合、テレビデバイス実装は:

  • [7.3.4/T-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
  • [7.3.4/T-1-2] 1,000 度/秒までの方向変化を測定できなければなりません。

テレビデバイス実装は:

  • [7.4.3/T-0-1] Bluetooth と Bluetooth LE をサポートしなければなりません。
  • [7.6.1/T-0-1] アプリの個人データ（「/data」パーティション）に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。

ホストモードをサポートする USB ポートが含まれる場合、テレビデバイス実装は:

  • [7.5.3/T-1-1] この USB ポートを通じて接続する（ただし常に接続されているとは限らない）外部カメラのサポートを含まなければなりません。

テレビデバイス実装が 32 ビットの場合:

  • [7.6.1/T-1-1] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 896 MB でなければなりません。

    • 小 / 標準画面で 400 dpi 以上
    • 大画面で xhdpi 以上
    • 特大画面で tvdpi 以上

テレビデバイス実装が 64 ビットの場合:

  • [7.6.1/T-2-1] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 1,280 MB でなければなりません。

    • 小 / 標準画面で 400 dpi 以上
    • 大画面で xhdpi 以上
    • 特大画面で tvdpi 以上

なお、上記の「カーネルとユーザー空間に利用できるメモリ」とは、デバイス実装でカーネルの制御下にない、無線や動画などのハードウェア コンポーネント専用のメモリに加えて提供されるメモリ空間を指します。

テレビデバイス実装は:

  • [7.8.1/T] マイクを含むべきです。
  • [7.8.2/T-0-1] オーディオ出力がなければならず、android.hardware.audio.output を宣言しなければなりません。

2.3.2. マルチメディア

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

  • [5.1/T-0-1] MPEG-4 AAC プロファイル（AAC LC）
  • [5.1/T-0-2] MPEG-4 HE AAC プロファイル（AAC+）
  • [5.1/T-0-3] AAC ELD（Enhanced Low Delay AAC）

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

  • [5.2/T-0-1] H.264
  • [5.2/T-0-2] VP8

新しい要件の開始

  • [5.2/T-0-3] AV1

新しい要件の終了

テレビデバイス実装は:

  • [5.2.2/T-SR-1] 30 フレーム/秒で解像度 720p と 1080p の動画の H.264 エンコードをサポートすることが強く推奨されます。

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

新しい要件の開始

新しい要件の終了

テレビデバイス実装は、セクション 5.3.1 で記載のとおり、次に示すもの以下の標準的な動画フレームレートと解像度で MPEG-2 デコードをサポートしなければなりません。

  • [5.3.1/T-1-1] メイン プロファイル ハイレベルで 29.97 フレーム/秒の HD 1080p。
  • [5.3.1/T-1-2] メイン プロファイル ハイレベルで 59.94 フレーム/秒の HD 1080i。インターレース MPEG-2 動画をインターレース解除し、サードパーティ アプリで利用できるようにしなければなりません。

テレビデバイス実装は、セクション 5.3.4 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で H.264 デコードをサポートしなければなりません。

  • [5.3.4/T-1-1] ベースライン プロファイルで 60 フレーム/秒の HD 1080p
  • [5.3.4/T-1-2] メイン プロファイルで 60 フレーム/秒の HD 1080p
  • [5.3.4/T-1-3] ハイ プロファイル レベル 4.2 で 60 フレーム/秒の HD 1080p

H.265 ハードウェア デコーダを備えたテレビデバイス実装は、セクション 5.3.5 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で H.265 デコードをサポートしなければなりません。

  • [5.3.5/T-1-1] メイン プロファイル レベル 4.1 で 60 フレーム/秒の HD 1080p

H.265 デコードと UHD デコード プロファイルをサポートする場合、H.265 ハードウェア デコーダを備えたテレビデバイス実装は:

  • [5.3.5/T-2-1] メイン 10 レベル 5 メイン ティア プロファイルで 60 フレーム/秒の UHD デコード プロファイルをサポートしなければなりません。

テレビデバイス実装は、セクション 5.3.6 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で VP8 デコードをサポートしなければなりません。

  • [5.3.6/T-1-1] 60 フレーム/秒のデコード プロファイルの HD 1080p

VP9 ハードウェア デコーダを備えたテレビデバイス実装は、セクション 5.3.7 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で VP9 デコードをサポートしなければなりません。

  • [5.3.7/T-1-1] プロファイル 0（8 ビット色深度）で 60 フレーム/秒の HD 1080p

VP9 デコードと UHD デコード プロファイルをサポートする場合、VP9 ハードウェア デコーダを備えたテレビデバイス実装は:

  • [5.3.7/T-2-1] プロファイル 0（8 ビット色深度）で 60 フレーム/秒の UHD デコード プロファイルをサポートしなければなりません。
  • [5.3.7/T-SR1] プロファイル 2（10 ビット色深度）で 60 フレーム/秒の UHD デコード プロファイルをサポートすることが強く推奨されます。

テレビデバイス実装は:

  • [5.5/T-0-1] 圧縮オーディオ パススルー出力（デバイスでオーディオ デコードが行われない）を除き、サポート対象の出力で、システムのマスター ボリュームとデジタル オーディオ出力ボリュームの減衰のサポートを含まなければなりません。

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

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

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

  • [5.8/T-1-1] HDCP 2.2 をサポートしなければなりません。

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

  • [5.8/T-2-1] HDCP 1.4 をサポートしなければなりません。

2.3.3. ソフトウェア

テレビデバイス実装は:

  • [3/T-0-1] 機能 android.software.leanback と android.hardware.type.television を宣言しなければなりません。
  • [3.2.3.1/T-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
  • [3.4.1/T-0-1] android.webkit.Webview API の完全な実装を提供しなければなりません。

ロック画面をサポートする場合、Android テレビデバイス実装は:

  • [3.8.10/T-1-1] メディア通知テンプレートを含め、ロック画面通知を表示しなければなりません。

テレビデバイス実装は:

  • [3.8.14/T-SR-1] ピクチャー イン ピクチャー（PIP）モードのマルチウィンドウをサポートすることが強く推奨されます。
  • [3.10/T-0-1] サードパーティのユーザー補助サービスをサポートしなければなりません。
  • [3.10/T-SR-1] talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack（プリインストールのテキスト読み上げエンジンでサポートされている言語）のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。

機能 android.hardware.audio.output をレポートする場合、テレビデバイス実装は:

  • [3.11/T-SR-1] デバイスで利用可能な言語をサポートする TTS エンジンを含むことが強く推奨されます。
  • [3.11/T-1-1] サードパーティ TTS エンジンのインストールをサポートしなければなりません。

テレビデバイス実装は:

  • [3.12/T-0-1] テレビ入力フレームワークをサポートしなければなりません。

2.3.4. パフォーマンスと電力

  • [8.1/T-0-1] 一貫したフレーム レイテンシ。一貫性のないフレーム レイテンシ、またはフレームのレンダリングの遅延は、1 秒間に 5 フレームを超えて発生してはならず、1 秒間に 1 フレーム未満であるべきです。
  • [8.2/T-0-1] 少なくとも 5 MB/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
  • [8.2/T-0-2] 少なくとも 0.5 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
  • [8.2/T-0-3] 少なくとも 15 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
  • [8.2/T-0-4] 少なくとも 3.5 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。

AOSP に含まれるデバイス電源管理を改善する機能を含むか、AOSP に含まれる機能を拡張する場合、テレビデバイス実装は:

  • [8.3/T-1-1] バッテリー セーバー機能を有効または無効にするユーザー アフォーダンスを提供しなければなりません。

バッテリーがない場合、テレビデバイス実装は:

バッテリーがある場合、テレビデバイス実装は:

  • [8.3/T-1-3] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供しなければなりません。

テレビデバイス実装は:

  • [8.4/T-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとのバッテリー消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
  • [8.4/T-0-2] すべての消費電力値をミリアンペア時（mAh）単位でレポートしなければなりません。
  • [8.4/T-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、uid_cputime カーネル モジュール実装を通じて要件を満たしています。
  • [8.4/T] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
  • [8.4/T-0-4] この電力使用量を、adb shell dumpsys batterystats シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。

2.3.5. セキュリティ モデル

テレビデバイス実装は:

  • [9/T-0-1] android.hardware.security.model.compatible 機能を宣言しなければなりません。
  • [9.11/T-0-1] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
  • [9.11/T-0-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト（AOSP）は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザベースの隔離オプションをセキュアに実装する方法を選択することもできます。
  • [9.11/T-0-3] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer（HAL）と Trusty を提供しており、これを使用してこの要件を満たすことができます。
  • [9.11/T-0-4] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。

なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint 機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵構成証明をサポートする必要があるという要件を免除されます。

セキュアロック画面をサポートする場合、テレビデバイス実装は:

  • [9.11/T-1-1] ロック解除状態からロック状態への遷移のためのスリープ タイムアウトを、最小許容タイムアウト 15 秒以下でユーザーが選択できるようにしなければなりません。

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言しない場合、テレビデバイス実装は:

  • [9.5/T-2-1] 制限付きプロファイル（追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能）をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言する場合、テレビデバイス実装は:

  • [9.5/T-3-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。

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

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

android.hardware.camera.any を宣言する場合、テレビデバイス実装は:

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

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

テレビデバイス実装は:

  • Perfetto
    • [6.1/T-0-1] cmdline で perfetto ドキュメントを遵守しているシェルユーザーに /system/bin/perfetto バイナリを公開しなければなりません。
    • [6.1/T-0-2] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れなければなりません。
    • [6.1/T-0-3] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込まなければなりません。
    • [6.1/T-0-4] 少なくとも perfetto ドキュメントで規定されたデータソースを、perfetto バイナリを通じて提供しなければなりません。

2.4. スマートウォッチの要件

Android スマートウォッチ デバイスとは、身体（通常は手首）に装着することを目的とした Android デバイス実装を指します。

次の基準をすべて満たす場合、Android デバイス実装はスマートウォッチに分類されます。

  • 画面の対角長が物理的に 1.1 から 2.5 インチ。
  • 身体に装着するメカニズムを提供する。

このセクションでこれ以降記載する追加要件は、Android スマートウォッチ デバイス実装に固有のものです。

2.4.1. ハードウェア

スマートウォッチ デバイス実装は:

  • [7.1.1.1/W-0-1] 画面の対角サイズが物理的に 1.1 から 2.5 インチでなければなりません。

  • [7.2.3/W-0-1] ユーザーが利用できるホーム機能と、戻る機能（UI_MODE_TYPE_WATCH のときを除く）を備えなければなりません。

  • [7.2.4/W-0-1] タッチスクリーン入力をサポートしなければなりません。

  • [7.3.1/W-SR-1] 3 軸加速度計を含むことが強く推奨されます。

新しい要件の開始

Vulkan のサポートが含まれる場合、スマートウォッチ デバイス実装は:

新しい要件の終了

GPS / GNSS レシーバーが含まれ、android.hardware.location.gps 機能フラグを通じてアプリに機能をレポートする場合、スマートウォッチ デバイス実装は:

  • [7.3.3/W-1-1] GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GNSS 測定値が判明したらすぐにレポートしなければなりません。
  • [7.3.3/W-1-2] 全天条件下で、位置を特定した後に、静止しているか加速度 0.2 m/s2 未満で移動している間、位置 20 m 以内、速度 0.2 m/s 以内、時間 95% 以上を計算するのに十分な、GNSS の擬似距離と擬似距離レートをレポートしなければなりません。

3 軸ジャイロスコープが含まれる場合、スマートウォッチ デバイス実装は:

  • [7.3.4/W-2-1] 1,000 度/秒までの方向変化を測定できなければなりません。

スマートウォッチ デバイス実装は:

  • [7.4.3/W-0-1] Bluetooth をサポートしなければなりません。

  • [7.6.1/W-0-1] アプリの個人データ（「/data」パーティション）に利用できる不揮発性ストレージが少なくとも 1 GB でなければなりません。

  • [7.6.1/W-0-2] カーネルとユーザー空間に利用できるメモリが少なくとも 416 MB でなければなりません。

  • [7.8.1/W-0-1] マイクを含まなければなりません。

  • [7.8.2/W] オーディオ出力があっても構いません。

2.4.2. マルチメディア

追加の要件はありません。

2.4.3. ソフトウェア

スマートウォッチ デバイス実装は:

  • [3/W-0-1] 機能 android.hardware.type.watch を宣言しなければなりません。
  • [3/W-0-2] uiMode = UI_MODE_TYPE_WATCH をサポートしなければなりません。
  • [3.2.3.1/W-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。

スマートウォッチ デバイス実装は:

  • [3.8.4/W-SR-1] アシスト アクションを処理するために、デバイスにアシスタントを実装することが強く推奨されます。

android.hardware.audio.output 機能フラグを宣言するスマートウォッチ デバイス実装は:

  • [3.10/W-1-1] サードパーティのユーザー補助サービスをサポートしなければなりません。
  • [3.10/W-SR-1] talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack（プリインストールのテキスト読み上げエンジンでサポートされている言語）のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。

機能 android.hardware.audio.output をレポートする場合、スマートウォッチ デバイス実装は:

  • [3.11/W-SR-1] デバイスで利用可能な言語をサポートする TTS エンジンを含むことが強く推奨されます。

  • [3.11/W-0-1] サードパーティ TTS エンジンのインストールをサポートしなければなりません。

2.4.4. パフォーマンスと電力

AOSP に含まれるデバイス電源管理を改善する機能を含むか、AOSP に含まれる機能を拡張する場合、スマートウォッチ デバイス実装は:

  • [8.3/W-SR-1] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供することが強く推奨されます。
  • [8.3/W-SR-2] バッテリー セーバー機能を有効または無効にするユーザー アフォーダンスを提供することが強く推奨されます。

スマートウォッチ デバイス実装は:

  • [8.4/W-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
  • [8.4/W-0-2] すべての消費電力値をミリアンペア時（mAh）単位でレポートしなければなりません。
  • [8.4/W-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、uid_cputime カーネル モジュール実装を通じて要件を満たしています。
  • [8.4/W-0-4] この電力使用量を、adb shell dumpsys batterystats シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。
  • [8.4/W] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。

2.4.5. セキュリティ モデル

スマートウォッチ デバイス実装は:

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

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言しない場合、スマートウォッチ デバイス実装は:

  • [9.5/W-1-1] 制限付きプロファイル（追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能）をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言する場合、スマートウォッチ デバイス実装は:

  • [9.5/W-2-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。

新しい要件の開始

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

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

新しい要件の終了

2.5. 自動車の要件

Android Automotive　実装とは、システムやインフォテインメント システムの一部または全部でオペレーティング システムとして Android を搭載した車両ヘッドユニットを指します。

機能 android.hardware.type.automotive を宣言するか次の基準をすべて満たす場合、Android デバイス実装は自動車に分類されます。

  • 自動車の一部として埋め込まれているか、自動車にプラグイン可能。
  • 運転席列の画面をプライマリ ディスプレイとして使用する。

このセクションでこれ以降記載する追加要件は、Android 自動車デバイス実装に固有のものです。

2.5.1. ハードウェア

自動車デバイス実装は:

  • [7.1.1.1/A-0-1] 画面の対角サイズが物理的に少なくとも 6 インチでなければなりません。
  • [7.1.1.1/A-0-2] 画面サイズのレイアウトが少なくとも 750 dp x 480 dp でなければなりません。
  • [7.2.3/A-0-1] ホーム機能を提供しなければならず、戻る機能と履歴機能を提供しても構いません。
  • [7.2.3/A-0-2] 戻る機能（KEYCODE_BACK）の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。
  • [7.3/A-0-1] GEAR_SELECTION、NIGHT_MODE、PERF_VEHICLE_SPEED、PARKING_BRAKE_ON を実装しレポートしなければなりません。
  • [7.3/A-0-2] NIGHT_MODE フラグの値は、ダッシュボードの昼間 / 夜間モードと一致しなければならず、周囲光センサー入力に基づくべきです。基になる周囲光センサーは、光度計と同じでも構いません。
  • [7.3/A-0-3] 提供されるすべてのセンサーについて SensorAdditionalInfo の一部としてセンサー追加情報フィールド TYPE_SENSOR_PLACEMENT を提供しなければなりません。
  • [7.3/A-SR1] GPS/GNSS と追加のセンサーを融合することで、位置情報を推算しても構いません。位置情報を推算する場合、対応するセンサータイプや使用する車両プロパティ ID を実装し、レポートすることが強く推奨されます。

  • [7.3/A-0-4] LocationManager#requestLocationUpdates() を介してリクエストする位置情報は、マップマッチされてはなりません。

  • [7.3.1/A-0-4] Android 自動車センサー座標系に準拠しなければなりません。

  • [7.3/A-SR-1] 3 軸加速度計と 3 軸ジャイロスコープを含むことが強く推奨されます。

  • [7.3/A-SR-2] TYPE_HEADING センサーを実装し、レポートすることが強く推奨されます。

OpenGL ES 3.1 をサポートする場合、自動車デバイス実装は:

  • [7.1.4.1/A-0-1] OpenGL ES 3.1 以降を宣言しなければなりません。
  • [7.1.4.1/A-0-2] Vulkan 1.1 をサポートしなければなりません。
  • [7.1.4.1/A-0-3] Vulkan ローダーを含み、シンボルをすべてエクスポートしなければなりません。

新しい要件の開始

Vulkan のサポートが含まれる場合、自動車デバイス実装は:

新しい要件の終了

加速度計が含まれる場合、自動車デバイス実装は:

  • [7.3.1/A-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。

3 軸加速度計が含まれる場合、デバイス実装は:

  • [7.3.1/A-SR-1] 軸数制限付き加速度計用の複合センサーを実装することが強く推奨されます。

3 軸未満の加速度計が含まれる場合、自動車デバイス実装は:

  • [7.3.1/A-1-3] TYPE_ACCELEROMETER_LIMITED_AXES センサーを実装し、レポートしなければなりません。
  • [7.3.1/A-1-4] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED センサーを実装し、レポートしなければなりません。

ジャイロスコープが含まれる場合、自動車デバイス実装は:

  • [7.3.4/A-2-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
  • [7.3.4/A-2-3] 250 度/秒までの方向変化を測定できなければなりません。
  • [7.3.4/A-SR-1] 解像度を可能な限り最大化するために、ジャイロスコープの測定範囲を +/-250 dps に設定することが強く推奨されます。

3 軸ジャイロスコープが含まれる場合、自動車デバイス実装は:

  • [7.3.4/A-SR-2] 軸数を制限されたジャイロスコープ用の複合センサーを実装することが強く推奨されます。

3 軸未満のジャイロスコープが含まれる場合、自動車デバイス実装は:

  • [7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES センサーを実装し、レポートしなければなりません。
  • [7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED センサーを実装し、レポートしなければなりません。

GPS / GNSS レシーバーが含まれるが、モバイル ネットワーク ベースのデータ接続が含まれない場合、自動車デバイス実装は:

  • [7.3.3/A-3-1] GPS / GNSS レシーバーが初めてオンになったとき、または 4 日以上経過した後、60 秒以内で位置を特定しなければなりません。
  • [7.3.3/A-3-2] 他のすべての位置情報リクエスト（初めてでもなく 4 日以上経過した後でもないリクエスト）について、7.3.3/C-1-2 と 7.3.3/C-1-6 に記載されている初期位置算出時間基準を満たさなければなりません。要件 7.3.3/C-1-2 は通常、モバイル ネットワーク ベースのデータ接続のない車両において、レシーバーで計算した GNSS 軌道予測を使用するか、7.3.3/C-1-3 を満たす位置精度で少なくとも 60 秒間推算する機能とともに最後の既知の車両位置情報を使用することで、または両方を組み合わせることで満たされます。

TYPE_HEADING センサーが含まれる場合、自動車デバイス実装は:

  • [7.3.4/A-4-3] 少なくとも周波数 1 Hz までのイベントをレポートできなければなりません。
  • [7.3.4/A-SR-3] 少なくとも周波数 10 Hz までのイベントをレポートすることが強く推奨されます。
  • 真北を指すべきです。
  • 車両が静止している間も利用できるべきです。
  • 解像度が少なくとも 1 度であるべきです。

自動車デバイス実装は:

  • [7.4.3/A-0-1] Bluetooth をサポートしなければならず、Bluetooth LE をサポートすべきです。
  • [7.4.3/A-0-2] Android Automotive　実装は、次の Bluetooth プロファイルをサポートしなければなりません。
    • Hands-Free Profile（HFP）での通話。
    • Audio Distribution Profile（A2DP）でのメディア再生。
    • Remote Control Profile（AVRCP）でのメディア再生コントロール。
    • Phone Book Access Profile（PBAP）を使用した連絡先の共有。

  • [7.4.3/A-SR-1] Message Access Profile（MAP）をサポートすることが強く推奨されます。

  • [7.4.5/A] モバイル ネットワーク ベースのデータ接続のサポートを含むべきです。

  • [7.4.5/A] システムアプリで利用可能にすべきネットワークについて、システム API の NetworkCapabilities#NET_CAPABILITY_OEM_PAID 定数を使用しても構いません。

新しい要件の開始

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 または拡張ビューシステム API を使用して実装しなければなりません。

新しい要件の終了

自動車デバイス実装は:

  • [7.6.1/A-0-1] アプリの個人データ（「/data」パーティション）に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。

  • [7.6.1/A] たとえば f2fs ファイル システムを使用して、フラッシュ ストレージのパフォーマンスと寿命を改善するために、データ パーティションをフォーマットすべきです。

取り外し不可能な内部ストレージの一部を介して共有外部ストレージを提供する場合、自動車デバイス実装は:

  • [7.6.1/A-SR-1] たとえば SDCardFS を使用して、外部ストレージで行われる操作の I/O オーバーヘッドを削減することが強く推奨されます。

自動車デバイス実装が 64 ビットの場合:

  • [7.6.1/A-2-1] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 816 MB でなければなりません。

    • 小 / 標準画面で 280 dpi 以下
    • 特大画面で ldpi 以下
    • 大画面で mdpi 以下

  • [7.6.1/A-2-2] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 944 MB でなければなりません。

    • 小 / 標準画面で xhdpi 以上
    • 大画面で hdpi 以上
    • 特大画面で mdpi 以上

  • [7.6.1/A-2-3] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 1,280 MB でなければなりません。

    • 小 / 標準画面で 400 dpi 以上
    • 大画面で xhdpi 以上
    • 特大画面で tvdpi 以上

  • [7.6.1/A-2-4] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 1,824 MB でなければなりません。

    • 小 / 標準画面で 560 dpi 以上
    • 大画面で 400 dpi 以上
    • 特大画面で xhdpi 以上

なお、上記の「カーネルとユーザー空間に利用できるメモリ」とは、デバイス実装でカーネルの制御下にない、無線や動画などのハードウェア コンポーネント専用のメモリに加えて提供されるメモリ空間を指します。

自動車デバイス実装は:

  • [7.7.1/A] ペリフェラル モードをサポートする USB ポートを含むべきです。

自動車デバイス実装は:

  • [7.8.1/A-0-1] マイクを含まなければなりません。

自動車デバイス実装は:

  • [7.8.2/A-0-1] オーディオ出力がなければならず、android.hardware.audio.output を宣言しなければなりません。

2.5.2. マルチメディア

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

  • [5.1/A-0-1] MPEG-4 AAC プロファイル（AAC LC）
  • [5.1/A-0-2] MPEG-4 HE AAC プロファイル（AAC+）
  • [5.1/A-0-3] AAC ELD（Enhanced Low Delay AAC）

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

  • [5.2/A-0-1] H.264 AVC
  • [5.2/A-0-2] VP8

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

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

自動車デバイス実装は、次の動画デコードをサポートすることが強く推奨されます。

  • [5.3/A-SR-1] H.265 HEVC

2.5.3. ソフトウェア

自動車デバイス実装は:

  • [3/A-0-1] 機能 android.hardware.type.automotive を宣言しなければなりません。

  • [3/A-0-2] uiMode = UI_MODE_TYPE_CAR をサポートしなければなりません。

  • [3/A-0-3] android.car.* 名前空間のすべての公開 API をサポートしなければなりません。

自動車デバイス実装が android.car.VehiclePropertyIds で android.car.CarPropertyManager を使用する独自の API を提供する場合:

  • [3/A-1-1] システムアプリがこれらのプロパティを使用するための特別な権限を付与したり、サードパーティ アプリによるこれらのプロパティの使用を妨げたりしてはなりません。
  • [3/A-1-2] すでに SDK に存在する車両プロパティをレプリケートしてはなりません。

自動車デバイス実装は:

  • [3.2.1/A-0-1] 自動車の権限に関するリファレンス ページに記載されているすべての権限定数をサポートし、適用しなければなりません。

  • [3.2.3.1/A-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。

  • [3.4.1/A-0-1] android.webkit.Webview API の完全な実装を提供しなければなりません。

新しい要件の開始

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

新しい要件の終了

  • [3.8.3/A-0-1] サードパーティ アプリがリクエストした場合、Notification.CarExtender API を使用する通知を表示しなければなりません。

  • [3.8.4/A-SR-1] アシスト アクションを処理するために、デバイスにアシスタントを実装することが強く推奨されます。

プッシュツートーク ボタンが含まれる場合、自動車デバイス実装は:

  • [3.8.4/A-1-1] ユーザー選択のアシストアプリ（VoiceInteractionService を実装するアプリ）を起動するための指定操作として、プッシュツートーク ボタンの短押しを使用しなければなりません。

自動車デバイス実装は:

  • [3.8.3.1/A-0-1] Notifications on Automotive OS SDK ドキュメントに記載されているとおり、リソースを正しくレンダリングしなければなりません。
  • [3.8.3.1/A-0-2] Notification.Builder.addAction() で提供されるものの代わりに、通知アクションの再生とミュートを表示しなければなりません。
  • [3.8.3.1/A] 通知チャンネルごとのコントロールのような、リッチな管理タスクの使用を制限すべきです。コントロールを減らすためにアプリごとに UI アフォーダンスを使用しても構いません。

ユーザー HAL プロパティをサポートする場合、自動車デバイス実装は:

自動車デバイス実装は:

  • [3.14/A-0-1] セクション 3.14 に記載されているとおり、メディア API を使用するサードパーティ アプリをサポートするために UI フレームワークを含めなければなりません。
  • [3.14/A-0-2] 運転中、ユーザーがメディアアプリを安全に操作できるようにしなければなりません。
  • [3.14/A-0-3] CAR_EXTRA_MEDIA_PACKAGE エクストラで暗黙的インテントのアクション CAR_INTENT_ACTION_MEDIA_TEMPLATE をサポートしなければなりません。
  • [3.14/A-0-4] メディアアプリの設定アクティビティにナビゲートするアフォーダンスを提供しなければなりません。ただし自動車 UX 制限が有効でない場合にのみ、有効にしなければなりません。
  • [3.14/A-0-5] メディアアプリによって設定されたエラー メッセージを表示しなければならず、オプションのエクストラ ERROR_RESOLUTION_ACTION_LABEL と ERROR_RESOLUTION_ACTION_INTENT をサポートしなければなりません。
  • [3.14/A-0-6] 検索をサポートするアプリのためのアプリ内検索アフォーダンスをサポートしなければなりません。
  • [3.14/A-0-7] MediaBrowser 階層を表示するとき、CONTENT_STYLE_BROWSABLE_HINT と CONTENT_STYLE_PLAYABLE_HINT の定義を尊重しなければなりません。

デフォルトのランチャー アプリが含まれる場合、自動車デバイス実装は:

自動車デバイス実装は:

  • [3.8/A] immersive documentation に記載されているように、全画面モードに入るアプリ リクエストを制限しても構いません。
  • [3.8/A] ステータスバーとナビゲーション バーを常に表示し続けても構いません。
  • [3.8/A] システム UI 要素の背後の色を変更するアプリ リクエストを制限して、それらの要素が常に明確に見えるようにしても構いません。

2.5.4. パフォーマンスと電力

自動車デバイス実装は:

  • [8.2/A-0-1] デベロッパーがシステム API android.car.storagemonitoring.CarStorageMonitoringManager を通じて統計情報を利用できるよう、プロセスの UID ごとに、不揮発性ストレージに読み書きされたバイト数をレポートしなければなりません。Android オープンソース プロジェクトは、uid_sys_stats カーネル モジュールを通じて要件を満たしています。
  • [8.3/A-1-3] ガレージモードをサポートしなければなりません。
  • [8.3/A] 次の場合を除き、毎回運転した後、少なくとも 15 分間はガレージモードになるべきです。
    • バッテリーが消耗している。
    • アイドルジョブがスケジュールされていない。
    • 運転者がガレージモードを終了した。
  • [8.4/A-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
  • [8.4/A-0-2] すべての消費電力値をミリアンペア時（mAh）単位でレポートしなければなりません。
  • [8.4/A-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、uid_cputime カーネル モジュール実装を通じて要件を満たしています。
  • [8.4/A] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
  • [8.4/A-0-4] この電力使用量を、adb shell dumpsys batterystats シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。

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-2] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、カメラ インジケーターを非表示にしてはなりません。

新しい要件の開始

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

新しい要件の終了

自動車デバイス実装は:

  • [9/A-0-1] android.hardware.security.model.compatible 機能を宣言しなければなりません。
  • [9.11/A-0-1] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
  • [9.11/A-0-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト（AOSP）は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザベースの隔離オプションをセキュアに実装する方法を選択することもできます。
  • [9.11/A-0-3] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer（HAL）と Trusty を提供しており、これを使用してこの要件を満たすことができます。
  • [9.11/A-0-4] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。

なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint 機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵構成証明をサポートする必要があるという要件を免除されます。

自動車デバイス実装は:

  • [9.14/A-0-1] Android フレームワークの車両サブシステムからのメッセージの送受信を管理しなければなりません（例: 許可されるメッセージ タイプとメッセージ ソースの許可リスト登録）。
  • [9.14/A-0-2] Android フレームワークまたはサードパーティ アプリからのサービス拒否攻撃に対して、ウォッチドッグを設定しなければなりません。これにより、車両サブシステムの誤作動を招くおそれのある、悪意のあるソフトウェアが車両ネットワークにフラッディングを行うことを防ぎます。

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

自動車デバイス実装は:

  • Perfetto
    • [6.1/A-0-1] cmdline が perfetto ドキュメントを遵守しているシェルユーザーに /system/bin/perfetto バイナリを公開しなければなりません。
    • [6.1/A-0-2] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れなければなりません。
    • [6.1/A-0-3] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込まなければなりません。
    • [6.1/A-0-4] 少なくとも perfetto ドキュメントで規定されたデータソースを、perfetto バイナリを通じて提供しなければなりません。

2.6. タブレットの要件

Android タブレット デバイスとは一般に、次の基準をすべて満たす Android デバイス実装を指します。

  • 両手で持って使用する。
  • クラムシェルまたはコンバーチブル構成ではない。
  • 標準的な接続（USB、Bluetooth など）によるデバイス接続で使用する物理キーボードの実装。

  • バッテリーなど、持ち運びを可能にする電源がある。

  • 対角線で測定した画面ディスプレイ サイズが 7 インチより大きく 18 インチより小さい。

タブレット デバイス実装の要件は、ハンドヘルド デバイス実装と同様です。例外は、ハンドヘルド デバイスのセクションでは「*」で示されており、このセクションでは参考用に注記されています。

2.6.1. ハードウェア

ジャイロスコープ

3 軸ジャイロスコープが含まれる場合、タブレット デバイス実装は:

  • [7.3.4/Tab-1-1] 1,000 度/秒までの方向変化を測定できなければなりません。

最小のメモリとストレージ（セクション 7.6.1）

ハンドヘルドの要件で小 / 標準画面についてリストされている画面密度は、タブレットには適用されません。

USB ペリフェラル モード（セクション 7.7.1）

ペリフェラル モードをサポートする USB ポートが含まれる場合、タブレット デバイス実装は:

  • [7.7.1/Tab] Android Open Accessory（AOA）API を実装しても構いません。

バーチャル リアリティ モード（セクション 7.9.1）

バーチャル リアリティ ハイ パフォーマンス（セクション 7.9.2）

バーチャル リアリティ要件はタブレットには適用されません。

2.6.2. セキュリティ モデル

鍵と認証情報（セクション 9.11）

セクション [9.11] をご覧ください。

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言しない場合、デバイス実装は:

  • [9.5/T-1-1] 制限付きプロファイル（追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能）をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。

複数のユーザーが含まれ、android.hardware.telephony 機能フラグを宣言する場合、タブレット デバイス実装は:

  • [9.5/T-2-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。

2.6.2. ソフトウェア

  • [3.2.3.1/Tab-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。

3.ソフトウェア

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

Dalvik バイトコードによるマネージド実行環境は、Android アプリを実行する際の主要手段です。Android アプリケーション プログラミング インターフェース（API）は、マネージド ランタイム環境で動作するアプリに公開される Andoid プラットフォーム インターフェースのセットです。

デバイス実装は:

  • [C-0-1] Android SDK で公開されているドキュメント化された API、またはアップストリームの Android ソースコードにおいて @SystemApi マーカーで装飾されている API について、すべてのドキュメント化された動作も含めて、完全な実装を提供しなければなりません。

  • [C-0-2] TestApi アノテーション（@TestApi）でマークされたすべてのクラス、メソッド、関連要素をサポート / 維持しなければなりません。

  • [C-0-3] この互換性定義で特に許可されている場合を除き、マネージド API の省略、API インターフェースまたは署名の変更、ドキュメント化された動作からの逸脱、NoOps の対象とすることを行ってはなりません。

  • [C-0-4] Android に含まれている API のハードウェア機能のいくつかが省略されている場合でも、API を維持し、妥当な方法で動作させなければなりません。このシナリオに固有の要件については、セクション 7 をご覧ください。

  • [C-0-5] AOSP のブート クラスパスにあり、公開 SDK の一部を形成するわけではない、Java 言語パッケージのメソッドとフィールドとして定義される非 SDK インターフェースを、サードパーティ アプリが使用できるようにしてはなりません。これには、private と package-private のクラスメンバーや、SDK ドキュメントに記載されているとおり、@SystemAPI ではなく @hide アノテーションで装飾されている API が含まれます。

  • [C-0-6] すべての非 SDK インターフェースが、AOSP の該当する API レベルブランチの prebuilts/runtime/appcompat/hiddenapi-flags.csv パスにある provisional フラグと denylist フラグで提供されるものと同じ制限リストに含まれていなければなりません。

  • [C-0-7] AOSP にある既存の公開鍵を使用して、署名設定を APK に埋め込むことにより、非 SDK インターフェースを制限リストから削除できるように、署名設定の動的更新メカニズムをサポートしなければなりません。

    ただし:

    • デバイス実装で非表示 API が存在しないか異なる方法で実装されている場合は、非表示 API を拒否リストに移動するか、すべての制限リストから除外しても構いません。
    • AOSP に非表示 API がまだ存在していない場合は、非表示 API を制限リストに追加しても構いません。

新しい要件の開始

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

新しい要件の終了

3.1.1. Android 拡張機能

Android は、特定の API レベルの拡張機能バージョンを更新することで、その API レベルのマネージド API サーフェスの拡張をサポートします。android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API は、指定された API レベルの拡張機能がある場合、その apiLevel の拡張機能バージョンを返します。

Android デバイス実装は:

  • [C-0-1] 共有ライブラリ ExtShared とサービス ExtServices の両方の AOSP 実装を、API レベルごとに許可された最小バージョン以上のバージョンでプリロードしなければなりません。たとえば、API レベル 24 を搭載した Android 7.0 デバイス実装の場合、少なくともバージョン 1 を含まなければなりません。

  • [C-0-2] AOSP で定義された有効な拡張機能バージョン番号のみを返さなければなりません。

  • [C-0-3] 他のマネージド API のサポートと同様に、セクション 3.1 の要件に従い、android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) が返す拡張機能バージョンで定義されるすべての API をサポートしなければなりません。

3.1.2. Android ライブラリ

Apache HTTP クライアントのサポート終了により、デバイス実装は:

  • [C-0-1] org.apache.http.legacy ライブラリをブート クラスパスに配置してはなりません。
  • [C-0-2] アプリが次のいずれかの条件を満たす場合にのみ、org.apache.http.legacy ライブラリをアプリ クラスパスに追加しなければなりません。
    • API レベル 28 以前をターゲットとする。
    • <uses-library> の android:name 属性を org.apache.http.legacy に設定することで、ライブラリが必要であることをマニフェストで宣言する。

AOSP 実装はこれらの要件を満たしています。

3.2. ソフト API の互換性

セクション 3.1 のマネージド API に加えて、Android には、アプリのコンパイル時には適用できない、Android アプリのインテントや権限などの形式で、重要なランタイム専用の「ソフト」API も含まれています。

3.2.1. 権限

  • [C-0-1] デバイス実装者は、権限に関するリファレンス ページに記載されているすべての権限定数をサポートし、適用しなければなりません。なお、セクション 9 に、Android セキュリティ モデルに関連する追加の要件を記載しています。

3.2.2. ビルド パラメータ

Android API には、現在のデバイスを記述するための android.os.Build クラスの定数がいくつか含まれています。

  • [C-0-1] デバイス実装間で一貫した意味のある値を提供するために、デバイス実装が従わなければならない、これらの値の形式に関する追加の制限を下表に示します。
パラメータ 詳細
VERSION.RELEASE 現在実行している Android システムのバージョン（人が読める形式）。このフィールドには、Android 14 で使用できるバージョン文字列で定義された文字列値のいずれかを指定しなければなりません。
VERSION.SDK 現在実行している Android システムのバージョン（サードパーティ アプリコードからアクセスできる形式）。Android 14 の場合、このフィールドには整数値 14_INT を指定しなければなりません。
VERSION.SDK_INT 現在実行している Android システムのバージョン（サードパーティ アプリコードからアクセスできる形式）。Android 14 の場合、このフィールドには整数値 14_INT を指定しなければなりません。
VERSION.INCREMENTAL 現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値（人が読める形式）。この値は、エンドユーザーが利用できる別のビルドに再利用してはなりません。このフィールドは主に、ビルドの生成に使用されたビルド番号またはソース管理変更 ID を示すために使用します。このフィールドの値は、印刷用の 7 ビット ASCII としてエンコード可能であって、正規表現「^[^ :\/~]+$」に一致しなければなりません。
BOARD デバイスで使用される特定の内部ハードウェアを識別する、デバイス実装者が選択した値（人が読める形式）。このフィールドは、デバイスに電力を供給するボードの特定のリビジョンを示すために使用できます。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。
BRAND エンドユーザーが知っているデバイスに関連付けられたブランド名を反映する値。人が読める形式でなければならず、デバイスのメーカーまたはデバイスを販売する会社のブランドを表すべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。
SUPPORTED_ABIS ネイティブ コードの命令セット（CPU タイプ + ABI 規則）の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。
SUPPORTED_32_BIT_ABIS ネイティブ コードの命令セット（CPU タイプ + ABI 規則）の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。
SUPPORTED_64_BIT_ABIS ネイティブ コードの 2 番目の命令セット（CPU タイプ + ABI 規則）の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。
CPU_ABI ネイティブ コードの命令セット（CPU タイプ + ABI 規則）の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。
CPU_ABI2 ネイティブ コードの 2 番目の命令セット（CPU タイプ + ABI 規則）の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。
DEVICE ハードウェア機能の構成とデバイスの工業デザインを識別する開発名またはコードネームを含む、デバイス実装者が選択した値。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。このデバイス名は、製品の全期間にわたって変更してはなりません。
FINGERPRINT このビルドを一意に識別する文字列。人が読める程度の形式にすべきです。次のテンプレートに従わなければなりません。

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

例:

acme/myproduct/
    mydevice:14/LMYXX/3359:userdebug/test-keys

フィンガープリントには空白文字を含んではなりません。このフィールドの値は 7 ビット ASCII としてエンコード可能でなければなりません。
HARDWARE ハードウェアの名前（カーネル コマンドラインまたは /proc から）。人が読める程度の形式にすべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。
HOST ビルドが構築されたホストを一意に識別する文字列（人が読める形式）。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
ID 特定のリリースを参照するためにデバイス実装者が選択する識別子（人が読める形式）。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じ内容にできますが、エンドユーザーがソフトウェア ビルドを区別できるような意味のある値にすべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+$」に一致しなければなりません。
MANUFACTURER 製品の相手先ブランド製品製造企業（OEM）の商号。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。
SOC_MANUFACTURER 製品で使用しているプライマリ システム オン チップ（SOC）のメーカー名。SOC メーカーが同じデバイスでは、同じ定数値を使用すべきです。使用する正しい定数については、SOC メーカーにお問い合わせください。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^([0-9A-Za-z ]+)」に一致しなければなりません。また、空白文字で開始または終了してはならず、「unknown」であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。
SOC_MODEL 製品で使用しているプライマリ システム オン チップ（SOC）のモデル名。SOC モデルが同じデバイスでは、同じ定数値を使用すべきです。使用する正しい定数については、SOC メーカーにお問い合わせください。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^([0-9A-Za-z ._/+-]+)$」に一致しなければなりません。また、空白文字で開始または終了してはならず、「unknown」であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。
MODEL エンドユーザーが知っているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが市販されエンドユーザーに販売される際の名前と同じにすべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。
PRODUCT 特定の製品（SKU）の開発名またはコードネームを含む、デバイス実装者が選択した値。同じブランド内で一意でなければなりません。人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。この製品名は、製品の全期間にわたって変更してはなりません。
ODM_SKU デバイスの特定の構成（販売時にデバイスに付属する周辺機器など）を追跡するために使用される SKU（最小管理単位）を含む、デバイス実装者が選択した任意の値。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 ^([0-9A-Za-z.,_-]+)$ と一致しなければなりません。
SERIAL 「UNKNOWN」を返さなければなりません。
TAGS ビルドをさらに区別する、デバイス実装者が選択したタグのカンマ区切りのリスト。タグは、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+」に一致しなければなりません。また、典型的な 3 つの Android プラットフォーム署名設定（release-keys、dev-keys、test-keys）に対応する値のいずれかを持たなければなりません。
TIME ビルドが作成されたときのタイムスタンプを表す値。
TYPE ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成（user、userdebug、eng）に対応する値のいずれかを指定しなければなりません。
USER ビルドを生成したユーザー（または自動ユーザー）の名前またはユーザー ID。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
SECURITY_PATCH ビルドのセキュリティ パッチレベルを示す値。指定の Android のセキュリティに関する公開情報で説明されている問題に対して、ビルドがいかなる脆弱性も持たないことを示さなければなりません。「2015-11-01」など、Android のセキュリティに関する公開情報または Android セキュリティ アドバイザリに記載されている定義文字列と一致する、[YYYY-MM-DD] の形式でなければなりません。
BASE_OS ビルドの FINGERPRINT パラメータを表す値。Android のセキュリティに関する公開情報で提供されているパッチを除き、このビルドと同一です。正しい値をレポートしなければならず、そのようなビルドが存在しない場合は空の文字列（""）をレポートしなければなりません。
BOOTLOADER デバイスで使用される特定の内部ブートローダー バージョンを識別する、デバイス実装者が選択した値（人が読める形式）。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+$」に一致しなければなりません。
getRadioVersion() デバイスで使用されている特定の内部無線 / モデム バージョンを識別する、デバイス実装者が選択した値（人が読める形式）でなければなりません。または、そのような値を返さなければなりません。デバイスに内部無線 / モデムがない場合は、NULL を返さなければなりません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-,]+$」に一致しなければなりません。
getSerial() ハードウェア シリアル番号でなければなりません。または、ハードウェア シリアル番号を返さなければなりません。ハードウェア シリアル番号は、MODEL と MANUFACTURER が同じデバイス間で利用可能かつ一意でなければなりません。このフィールドの値は、7 ビットの ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9]+$」に一致しなければなりません。

3.2.3. インテントの互換性

3.2.3.1. 一般的なアプリ インテント

Android インテントによって、アプリ コンポーネントは他の Android コンポーネントの機能をリクエストできます。Android のアップストリーム プロジェクトには、一般的なアクションを行うために複数のインテント パターンを実装するアプリのリストが含まれています。

デバイス実装は:

  • [C-SR-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードし、フルフィルメントを提供する（SDK に記載されているこれら一般的なアプリ インテントに対するデベロッパーの期待に応える）ことが強く推奨されます。

デバイスタイプごとの必須のアプリ インテントについては、セクション 2 をご覧ください。

3.2.3.2. インテントの解決

  • [C-0-1] Android は拡張可能なプラットフォームであるため、デバイス実装は、セクション 3.2.3.1 で参照されている各インテント パターンをサードパーティ アプリでオーバーライドできるようにしなければなりません。アップストリームの Android オープンソース実装では、デフォルトでこれを行えます。

  • [C-0-2] デバイス実装者は、システムアプリがこれらのインテント パターンを使用することに対し特別な権限を付与したり、サードパーティ アプリがこれらのパターンにバインドして制御を引き受けることを妨げたりしてはなりません。同じインテント パターンを処理する複数のアプリ間でユーザーの選択を可能にする「選択用」ユーザー インターフェースを無効にすることなどが特に禁じられます。

  • [C-0-3] デバイス実装は、ユーザーに対し、インテントのデフォルト アクティビティを変更するユーザー インターフェースを提供しなければなりません。

  • ただし、デバイス実装は、デフォルト アクティビティがより具体的な属性を提供する場合、具体的な URI パターン（例: http://play.google.com）用のデフォルト アクティビティを提供しても構いません。たとえば、データ URI「http://www.android.com」を指定するインテント フィルタ パターンは、「http://」に対するブラウザのコアインテント パターンよりも具体的です。

Android には、特定のウェブ URI インテントに対してサードパーティ アプリが正式なデフォルトのアプリリンク動作を宣言するメカニズムも含まれています。このような正式な宣言がアプリのインテント フィルタ パターンで定義されている場合、デバイス実装は:

  • [C-0-4] アップストリームの Android オープンソース プロジェクトのパッケージ マネージャーで実装される、デジタル アセット リンク仕様で規定されている検証手順を実施することで、インテント フィルタの検証を試行しなければなりません。
  • [C-0-5] アプリのインストール中にインテント フィルタの検証を試行し、検証に合格したすべての URI インテント フィルタを、その URI のデフォルト アプリハンドラとして設定しなければなりません。
  • 検証に合格したが、他の URI フィルタ候補が検証に不合格となった場合、具体的な URI インテント フィルタを URI のデフォルト アプリハンドラとして設定しても構いません。デバイス実装でこれを行う場合、設定メニューで、URI ごとの適切なパターン オーバーライドをユーザーに提供しなければなりません。
  • 次のように、設定でアプリごとのアプリリンク コントロールをユーザーに提供しなければなりません。
    • [C-0-6] ユーザーは、すべての URI インテント フィルタ候補に等しく適用しなければならない、デフォルトのアプリリンク動作（アプリを常に開く、常に確認する、開かない）を全体的にオーバーライドできなければなりません。
    • [C-0-7] ユーザーに、URI インテント フィルタ候補のリストが表示されなければなりません。
    • デバイス実装は、インテント フィルタごとに、検証に合格した具体的な URI インテント フィルタ候補をオーバーライドする機能をユーザーに提供しても構いません。
    • [C-0-8] デバイス実装で、ある URI インテント フィルタ候補が検証に合格し、他の候補が不合格になる可能性がある場合、デバイス実装は、特定の URI インテント フィルタ候補を表示しオーバーライドする機能をユーザーに提供しなければなりません。
3.2.3.3. インテントの名前空間
  • [C-0-1] デバイス実装は、android.* 名前空間または com.android.* 名前空間に、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャスト インテント パターンを使用する Android コンポーネントを含んではなりません。
  • [C-0-2] デバイス実装者は、別の組織に属するパッケージ スペースに、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャスト インテント パターンを使用する Android コンポーネントを含めてはなりません。
  • [C-0-3] デバイス実装者は、セクション 3.2.3.1 に記載されているインテント パターンのいずれも変更または拡張してはなりません。
  • デバイス実装は、組織に明確に関連付けられた名前空間を使用するインテント パターンを含んでも構いません。セクション 3.6 の Java 言語クラスに指定された制約と同様のものです。
3.2.3.4. ブロードキャスト インテント

サードパーティ アプリは、特定のインテントをブロードキャストしてハードウェアまたはソフトウェア環境の変更を通知する際、プラットフォームに依存します。

デバイス実装は:

  • [C-0-1] SDK ドキュメントに記載されているとおり、該当するシステム イベントに応じて、こちらに記載されているパブリック ブロードキャスト インテントをブロードキャストしなければなりません。なお、バックグラウンド アプリの制限も SDK ドキュメントに記載されているため、この要件はセクション 3.5 と競合しません。また、特定のブロードキャスト インテントはハードウェアのサポートを条件としており、必要なハードウェアをサポートしている場合、デバイスはインテントをブロードキャストし、SDK ドキュメントに沿った動作を提供しなければなりません。
3.2.3.5. 条件付きアプリ インテント

Android には、ホーム画面や SMS などのデフォルト アプリをユーザーが簡単に選択できるようにする設定があります。

そのような状態が合理的な場合、デバイス実装は、同様の設定メニューを提供しなければならず、SDK ドキュメントに記載されているインテント フィルタ パターンや API メソッドと下記のように互換性がなければなりません。

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

  • [C-1-1] android.settings.HOME_SETTINGS インテントを使用して、ホーム画面用のデフォルトのアプリ設定メニューを表示しなければなりません。

android.hardware.telephony.calling をレポートする場合、デバイス実装は:

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

  • [C-3-1] android.settings.NFC_PAYMENT_SETTINGS インテントを使用して、非接触型決済用のデフォルトのアプリ設定メニューを表示しなければなりません。
  • [C-3-2] SDK に記載されているとおり、android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT インテントを使用して、特定カテゴリのデフォルトのカード エミュレーション サービスの変更についてユーザーに確認するダイアログを開くアクティビティを表示しなければなりません。

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

android.hardware.bluetooth をレポートする場合、デバイス実装は:

DND 機能をサポートする場合、デバイス実装は:

  • [C-6-1] インテント ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS に応答するアクティビティを実装しなければなりません。UI_MODE_TYPE_NORMAL での実装の場合、これは DND ポリシー構成へのアプリアクセスをユーザーが許可または拒否できるアクティビティでなければなりません。

ユーザーがデバイスでサードパーティの入力方法を使用できるようにする場合、デバイス実装は:

  • [C-7-1] android.settings.INPUT_METHOD_SETTINGS インテントに応じてサードパーティの入力方法を追加、構成する、ユーザーがアクセス可能なメカニズムを提供しなければなりません。

サードパーティのユーザー補助サービスをサポートする場合、デバイス実装は:

  • [C-8-1] android.settings.ACCESSIBILITY_SETTINGS インテントを使用して、プリロードされたユーザー補助サービスとともにサードパーティのユーザー補助サービスの有効化と無効化を行う、ユーザーがアクセス可能なメカニズムを提供しなければなりません。

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

データセーバー モードを提供する場合、デバイス実装は:

  • [C-10-1] 設定に、Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS インテントを処理するユーザー インターフェースを提供し、ユーザーがアプリを許可リストに追加したり、許可リストから削除したりできるようにしなければなりません。

データセーバー モードを提供しない場合、デバイス実装は:

android.hardware.camera.any を介してカメラのサポートを宣言する場合、デバイス実装は:

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

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

プリインストール アプリが含まれるか、サードパーティ アプリによる使用統計情報へのアクセスを許可する場合、デバイス実装は:

  • [C-SR-2] android.permission.PACKAGE_USAGE_STATS 権限を宣言するアプリに対する android.settings.ACTION_USAGE_ACCESS_SETTINGS インテントに応じて、使用統計情報へのアクセス権を付与または取り消す、ユーザーがアクセス可能なメカニズムを提供することが強く推奨されます。

プリインストール アプリを含め、いかなるアプリに対しても使用統計情報へのアクセスを許可しないことを意図する場合、デバイス実装は:

  • [C-15-1] 引き続き android.settings.ACTION_USAGE_ACCESS_SETTINGS インテント パターンを処理するアクティビティを持たなければなりませんが、ユーザーがアクセスを拒否されたときと同等の動作をするように NoOps として実装しなければなりません。

設定内の AutofillService_passwordsActivity で指定されたアクティビティへのリンク、または同様のメカニズムを通じてユーザー パスワードへのリンクを表示する場合、デバイス実装は:

  • [C-16-1] インストール済みのすべての自動入力サービスについて、そのようなリンクを表示しなければなりません。

VoiceInteractionService をサポートし、この API を使用する複数のアプリが同時にインストールされている場合、デバイス実装は:

機能 android.hardware.audio.output をレポートする場合、デバイス実装は:

  • [C-SR-3] こちらの SDK に記載されているとおり、インテント android.intent.action.TTS_SERVICE、android.speech.tts.engine.INSTALL_TTS_DATA、android.speech.tts.engine.GET_SAMPLE_TEXT を使用し、これらのインテントに対するフルフィルメントを提供するアクティビティを持つことが強く推奨されます。

Android は、以前は Dreams と呼ばれていた、インタラクティブ スクリーンセーバーをサポートしています。スクリーン セーバーを使用すると、電源に接続されているデバイスがアイドル状態のとき、または卓上ホルダーにドッキングされているとき、ユーザーがアプリを操作できます。デバイス実装は:

  • スクリーン セーバーのサポートを含み、android.settings.DREAM_SETTINGS インテントに応じてユーザーがスクリーン セーバーを構成できる設定オプションを提供すべきです。

新しい要件の開始

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

新しい要件の終了

3.2.4. セカンダリ / 複数ディスプレイでのアクティビティ

複数のディスプレイで通常の Android アクティビティを起動できるようにする場合、デバイス実装は:

  • [C-1-1] android.software.activities_on_secondary_displays 機能フラグを設定しなければなりません。
  • [C-1-2] プライマリ ディスプレイで動作するアクティビティと同様の API 互換性を保証しなければなりません。
  • [C-1-3] ActivityOptions.setLaunchDisplayId() API を介してターゲット ディスプレイを指定せずに新しいアクティビティが起動された場合、新しいアクティビティを起動したアクティビティと同じディスプレイに、新しいアクティビティを配置しなければなりません。
  • [C-1-4] Display.FLAG_PRIVATE フラグを指定したディスプレイが取り外された場合、すべてのアクティビティを破棄しなければなりません。
  • [C-1-5] アプリが Activity#setShowWhenLocked() API を使用してロック画面上に表示されるようにオプトインしない限り、デバイスがセキュアロック画面でロックされている場合、すべての画面のコンテンツを安全に非表示にしなければなりません。
  • セカンダリ ディスプレイでアクティビティが起動された場合に、表示、正しい動作、互換性が維持されるように、そのディスプレイに対応する android.content.res.Configuration を持つべきです。

セカンダリ ディスプレイで通常の Android アクティビティが起動できるようになっており、android.view.Display.FLAG_PRIVATE フラグが指定されている場合、デバイス実装は:

  • [C-3-1] そのディスプレイ、システム、そのディスプレイ上にすでにあるアクティビティの所有者のみが、起動できなければなりません。android.view.Display.FLAG_PUBLIC フラグが指定されているディスプレイは、誰でも起動できます。

3.3. ネイティブ API の互換性

ネイティブ コードの互換性は難しい問題です。そのため、デバイス実装者は:

  • [C-SR-1] アップストリームの Android オープンソース プロジェクトから、下記のライブラリの実装を使用することが強く推奨されます。

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

Dalvik バイトコードによるマネージド実行環境では、アプリの .apk ファイルで提供されるネイティブ コードを、該当するデバイス ハードウェア アーキテクチャ向けにコンパイルされた ELF .so ファイルとして呼び出すことができます。ネイティブ コードは基となるプロセッサ技術に大きく依存するため、Android では、Android NDK に多数のアプリケーション バイナリ インターフェース（ABI）が定義されています。

デバイス実装は:

  • [C-0-1] 1 つ以上の定義済み Android NDK ABI と互換性がなければなりません。
  • [C-0-2] 標準の Java Native Interface（JNI）セマンティクスを使用して、ネイティブ コードを呼び出すためにマネージド環境で動作するコードのサポートを含まなければなりません。
  • [C-0-3] 下記のリストにある各必須ライブラリと、ソース互換（すなわちヘッダー互換）かつバイナリ互換（ABI 向け）でなければなりません。
  • [C-0-5] android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS、android.os.Build.SUPPORTED_64_BIT_ABIS のパラメータ（優先度の高い順にカンマ区切りになっている ABI のリスト）を介して、デバイスがサポートするネイティブ アプリケーション バイナリ インターフェース（ABI）を正確にレポートしなければなりません。

  • [C-0-6] 上記のパラメータを介して、次の ABI リストのサブセットをレポートしなければならず、リストにない ABI はレポートしてはなりません。

  • [C-0-7] ネイティブ API を提供する次のすべてのライブラリを、ネイティブ コードを含むアプリで利用できるようにしなければなりません。

    • libaaudio.so（AAudio ネイティブ オーディオ サポート）
    • libamidi.so（ネイティブ MIDI サポート、機能 android.software.midi がセクション 5.9 の記載のとおりである場合）
    • libandroid.so（ネイティブ Android アクティビティ サポート）
    • libc（C ライブラリ）
    • libcamera2ndk.so
    • libdl（ダイナミック リンカー）
    • libEGL.so（ネイティブ OpenGL サーフェス管理）
    • libGLESv1_CM.so（OpenGL ES 1.x）
    • libGLESv2.so（OpenGL ES 2.0）
    • libGLESv3.so（OpenGL ES 3.x）
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog（Android ロギング）
    • libmediandk.so（ネイティブ メディア API サポート）
    • libm（math ライブラリ）
    • libneuralnetworks.so（Neural Networks API）
    • libOpenMAXAL.so（OpenMAX AL 1.0.1 サポート）
    • libOpenSLES.so（OpenSL ES 1.0.1 オーディオ サポート）
    • libRS.so
    • libstdc++（C++ の最小限のサポート）
    • libvulkan.so（Vulkan）
    • libz（Zlib 圧縮）
    • JNI インターフェース

  • [C-0-8] 上のネイティブ ライブラリのパブリック関数を追加または削除してはなりません。

  • [C-0-9] /vendor/etc/public.libraries.txt でサードパーティ アプリに直接公開される AOSP 以外の追加のライブラリをリストしなければなりません。

  • [C-0-10] AOSP でシステム ライブラリとして実装され提供される他のネイティブ ライブラリを、API レベル 24 以降をターゲットとするサードパーティ アプリに公開してはなりません（予約されているため）。

  • [C-0-11] NDK で定義されているとおり、すべての OpenGL ES 3.1 と Android 拡張機能パックの関数シンボルを、libGLESv3.so ライブラリを介してエクスポートしなければなりません。なお、すべてのシンボルが存在しなければなりませんが、対応する関数それぞれの完全な実装が期待される場合の要件については、セクション 7.1.4.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 に詳しく記載しています。

  • アップストリームの Android オープンソース プロジェクトで入手可能なソースコードとヘッダー ファイルを使用してビルドすべきです。

なお、Android の今後のリリースで、追加の ABI のサポートが導入される可能性があります。

3.3.2. 32 ビット ARM ネイティブ コードの互換性

armeabi ABI のサポートをレポートする場合、デバイス実装は:

  • [C-3-1] armeabi は古いアプリとの下位互換性用でしかないため、armeabi-v7a もサポートし、そのサポートをレポートしなければなりません。

armeabi-v7a ABI のサポートをレポートする場合、この ABI を使用するアプリについて、デバイス実装は:

  • [C-2-1] /proc/cpuinfo に次の行を含まなければならず、他の ABI によって読み取られる場合であっても同じデバイスで値を変更すべきではありません。

    • Features: に続けて、デバイスでサポートされるオプションの ARMv7 CPU 機能のリスト。
    • CPU architecture: に続けて、デバイスでサポートされる最高の ARM アーキテクチャを示す整数（例: ARMv8 デバイスの場合は「8」）。

  • [C-2-2] ABI が ARMv8 アーキテクチャに実装されている場合であっても、ネイティブ CPU サポートを通じて、またはソフトウェア エミュレーションを通じて、常に次のオペレーションを利用できるように維持しなければなりません。

    • SWP 命令と SWPB 命令。
    • CP15ISB、CP15DSB、CP15DMB バリア オペレーション。

  • [C-2-3] Advanced SIMD（NEON）拡張のサポートを含まなければなりません。

3.4. ウェブの互換性

3.4.1. WebView の互換性

android.webkit.Webview API の完全な実装を提供する場合、デバイス実装は:

  • [C-1-1] android.software.webview をレポートしなければなりません。
  • [C-1-2] android.webkit.WebView API の実装に、Android 14 ブランチのアップストリームの Android オープンソース プロジェクトからビルドした Chromium プロジェクトを使用しなければなりません。

  • [C-1-3] WebView がレポートするユーザー エージェント文字列は、次の形式でなければなりません。

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) 文字列の値は、android.os.Build.VERSION.RELEASE の値と同じでなければなりません。
    • $(MODEL) 文字列は空にしても構いませんが、空でない場合は、値が android.os.Build.MODEL と同じでなければなりません。
    • 「Build/$(BUILD)」は省略しても構いませんが、存在する場合、$(BUILD) 文字列は android.os.Build.ID の値と同じでなければなりません。
    • $(CHROMIUM_VER) 文字列の値は、アップストリームの Android オープンソース プロジェクトの Chromium バージョンでなければなりません。
    • デバイス実装は、ユーザー エージェント文字列で Mobile を省略しても構いません。

  • WebView コンポーネントは、可能な限り多くの HTML5 機能をサポートすべきであり、機能をサポートする場合、HTML5 仕様に準拠すべきです。

  • [C-1-4] WebView をインスタンス化するアプリとは異なるプロセスで、提供されたコンテンツまたはリモート URL コンテンツをレンダリングしなければなりません。具体的には、個別のレンダラ プロセスは、より低い権限を持ち、個別のユーザー ID として実行され、アプリのデータ ディレクトリへのアクセス権を持たず、直接ネットワーク アクセス権を持たず、Binder でシステム サービスへの必要最小限のアクセス権のみを持たなければなりません。WebView の AOSP 実装はこの要件を満たしています。

なお、デバイス実装が 32 ビットの場合、または機能フラグ android.hardware.ram.low を宣言する場合、C-1-3 は免除されます。

3.4.2. ブラウザの互換性

通常のウェブ ブラウジング用のスタンドアロン ブラウザアプリが含まれる場合、デバイス実装は:

  • [C-1-1] HTML5 に関連する次の API をそれぞれサポートしなければなりません。
  • [C-1-2] HTML5/W3C webstorage API をサポートしなければならず、HTML5/W3C IndexedDB API をサポートすべきです。なお、ウェブ開発標準化団体が webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは、IndexedDB が必須コンポーネントになると見込まれます。
  • スタンドアロン ブラウザアプリでカスタムのユーザー エージェント文字列を送信しても構いません。
  • アップストリーム WebKit ブラウザアプリに基づくかサードパーティ代替アプリに基づくかにかかわらず、スタンドアロン ブラウザアプリで HTML5 のサポートを可能な限り多く実装すべきです。

ただし、スタンドアロン ブラウザアプリが含まれない場合、デバイス実装は:

  • [C-2-1] セクション 3.2.3.1 に記載されているとおり、パブリック インテント パターンを引き続きサポートしなければなりません。

3.5. API 動作の互換性

デバイス実装は:

  • [C-0-9] セクション 3.5.1 に記載されているように制限されている場合を除き、すべてのインストール済みアプリに API 動作の互換性が適用されるようにしなければなりません。
  • [C-0-10] デバイス実装者が選択したアプリに対してのみ API 動作の互換性を保証する許可リスト登録アプローチを実装してはなりません。

各 API タイプ（マネージド、ソフト、ネイティブ、ウェブ）の動作は、アップストリームの Android オープンソース プロジェクトの優先実装と一貫性がなければなりません。互換性の具体的な内容は次のとおりです。

  • [C-0-1] デバイスは、標準的なインテントの動作またはセマンティクスを変更してはなりません。
  • [C-0-2] デバイスは、特定の種類のシステム コンポーネント（Service、Activity、ContentProvider など）のライフサイクルまたはライフサイクル セマンティクスを変更してはなりません。
  • [C-0-3] デバイスは、標準的な権限のセマンティクスを変更してはなりません。
  • デバイスは、バックグラウンド アプリに適用される制限を変更してはなりません。より具体的には、バックグラウンド アプリについて:
    • [C-0-4] GnssMeasurement と GnssNavigationMessage からの出力を受信するためにアプリが登録するコールバックの実行を停止しなければなりません。
    • [C-0-5] LocationManager API クラスまたは WifiManager.startScan() メソッドを通じてアプリに提供される更新の頻度をレート制限しなければなりません。
    • [C-0-6] アプリが API レベル 25 以降をターゲットとしている場合、ブロードキャスト インテントで "signature" または "signatureOrSystem" protectionLevel 権限を必要とするか、免除リストにある場合を除き、アプリのマニフェストで標準的な Android インテントの暗黙的ブロードキャストのためにブロードキャスト レシーバを登録することを許可してはなりません。
    • [C-0-7] アプリが API レベル 25 以降をターゲットとしている場合、ユーザーに表示されるタスクを処理するためにアプリが一時的に許可リスト登録されている場合を除き、アプリがサービスの stopSelf() メソッドを呼び出したときのように、アプリのバックグラウンド サービスを停止しなければなりません。
    • [C-0-8] アプリが API レベル 25 以降をターゲットとしている場合、アプリが保持しているウェイクロックをリリースしなければなりません。
  • [C-0-11] アプリが insertProviderAt() または removeProvider() を介してリストを変更した場合を除き、デバイスは Security.getProviders() メソッドの最初の 7 つの配列値として、指定した順序、名前（Provider.getName() で返されます）、クラスで、次のセキュリティ プロバイダを返さなければなりません。デバイスは、下記のプロバイダ指定リストの後に、追加のプロバイダを返しても構いません。
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

上記のリストはすべてを網羅しているわけではありません。互換性テストスイート（CTS）は、動作の互換性についてプラットフォームの大部分をテストしますが、すべてではありません。Android オープンソース プロジェクトとの動作の互換性を確保することは、実装者の責任です。このため、デバイス実装者は、システムの重要な部分を再実装するのではなく、可能であれば Android オープンソース プロジェクトを介して入手可能なソースコードを使用すべきです。

3.5.1. アプリの制限

アプリを制限する独自のメカニズム（SDK に記載されている API の動作を変更または制限するなど）を実装していて、そのメカニズムが制限付きアプリ スタンバイ バケットより制限的である場合、デバイス実装は:

  • [C-1-1] 制限付きアプリのリストをユーザーが確認できるようにしなければなりません。
  • [C-1-2] アプリごとにこれらのすべての独自の制限をオン / オフするユーザー アフォーダンスを提供しなければなりません。

  • [C-1-3] システムの健全性に問題があることを示す証拠なしに、制限を自動的に適用してはなりません。ただし、ウェイクロックのスタック、サービスの長時間実行、その他の基準など、システムの健全性に問題があることを検出したときは、アプリに制限を適用しても構いません。基準はデバイス実装者が決定しても構いませんが、システムの健全性に対するアプリの影響に関連していなければなりません。アプリが市場で人気がないなど、システムの健全性に純粋に関係するわけではない他の基準は、基準として使用してはなりません。

  • [C-1-4] ユーザーがアプリの制限を手動でオフにした場合、アプリにこれらの独自の制限を自動的に適用してはなりません。これらの独自の制限を適用するようユーザーに提案することはできます。

  • [C-1-5] これらの独自の制限がアプリに自動的に適用される場合は、ユーザーに通知しなければなりません。このような通知は、これらの独自の制限が適用される 24 時間前までに提供しなければなりません。

  • [C-1-6] アプリからの API 呼び出しについては ActivityManager.isBackgroundRestricted() メソッドで true を返さなければなりません。

  • [C-1-7] ユーザーが明示的に使用しているトップ フォアグラウンド アプリを制限してはなりません。

  • [C-1-8] ユーザーが明示的にアプリの使用を開始する場合は常に、そのアプリがトップ フォアグラウンド アプリになるよう、アプリに対するこれらの独自の制限を停止しなければなりません。

  • [C-1-10] 独自の制限を適用する方法を説明する明確な公開ドキュメントまたはウェブサイトを提供しなければなりません。このドキュメントまたはウェブサイトは、Android SDK ドキュメントからリンクでき、以下を含まなければなりません。

    • 独自の制限についてのトリガー条件。
    • 制限できるアプリの種類と方法。
    • アプリに対しこのような制限を免除する方法。
    • ユーザーがインストールできるアプリの免除などがサポートされている場合に、アプリが独自の制限の適用免除をリクエストする方法。

アプリがデバイスにプリインストールされていて、30 日以上ユーザーが明示的に使用していない場合、[C-1-3]、[C-1-5] は適用されません。

AOSP で実装されるアプリ制限を拡張する場合、デバイス実装は:

  • [C-2-1] こちらのドキュメントに記載されている実装に従わなければなりません。

3.5.2. アプリの休止状態

AOSP に含まれるアプリの休止状態が含まれる場合、または AOSP に含まれる機能を拡張する場合、デバイス実装は:

  • [C-1-1] [C-1-6] と [C-1-3] を除き、セクション 3.5.1 のすべての要件を満たさなければなりません。
  • [C-1-2] ユーザーが一定期間アプリを使用していないという証拠がある場合にのみ、そのユーザーのアプリに対する制限を適用しなければなりません。この期間は 1 か月以上にすることが強く推奨されます。使用状況は、UsageStats#getLastTimeVisible() API を介した明示的なユーザー操作か、サービス バインディング、コンテンツ プロバイダ バインディング、明示的なブロードキャストなど、アプリが強制停止状態を脱する原因となる、なんらかのものによって定義しなければなりません（新しい API UsageStats#getLastTimeAnyComponentUsed() によってトラッキング）。
  • [C-1-3] パッケージがどのユーザーによっても一定期間使用されていないという証拠がある場合にのみ、すべてのデバイス ユーザーに影響する制限を適用しなければなりません。この期間は 1 か月以上にすることが強く推奨されます。
  • [C-1-4] アクティビティ インテント、サービス バインディング、コンテンツ プロバイダのリクエスト、または明示的なブロードキャストにアプリが応答できないようにしてはなりません。

AOSP のアプリの休止状態は、上記の要件を満たしています。

3.6. API 名前空間

Android は、Java プログラミング言語で定義されたパッケージとクラスの名前空間規則に従います。サードパーティ アプリとの互換性を確保するために、デバイス実装者は、次のパッケージ名前空間に対して禁止されている変更（下記参照）を行ってはなりません。

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

つまり:

  • [C-0-1] メソッド シグネチャかクラス シグネチャを変更することで、またはクラスかクラス フィールドを削除することで、Android プラットフォームで一般公開されている API を変更してはなりません。
  • [C-0-2] 一般公開されている要素（クラスまたはインターフェース、既存のクラスまたはインターフェースのフィールドまたはメソッドなど）やテスト API またはシステム API を、上記の名前空間の API に追加してはなりません。「一般公開されている要素」とは、アップストリームの Android ソースコードで使用されている「@hide」マーカーで装飾されていない構成要素のことです。

デバイス実装者は基となる API 実装を変更しても構いませんが、そのような変更は:

  • [C-0-3] 一般公開されている API の、所定の動作と Java 言語シグネチャに影響してはなりません。
  • [C-0-4] アドバタイズされたり、デベロッパーに公開されたりしてはなりません。

ただし、デバイス実装者は標準的な Android 名前空間の外にカスタム API を追加しても構いませんが、カスタム API は:

  • [C-0-5] 別の組織が所有または参照している名前空間にあってはなりません。たとえば、デバイス実装者は、com.google.* などの名前空間に API を追加してはなりません。これを行えるのは Google のみです。同様に、Google は他社の名前空間に API を追加してはなりません。
  • [C-0-6] そのような API のメモリ使用量増加の影響を受けるのが（<uses-library> メカニズムを介して）明示的に Android 共有ライブラリを使用するアプリのみになるように、Android 共有ライブラリにパッケージ化しなければなりません。

デバイス実装者は NDK API の外にネイティブ言語でカスタム API を追加しても構いませんが、そのカスタム API は:

  • [C-1-1] こちらに記載されているとおり、NDK ライブラリまたは別の組織が所有するライブラリにあってはなりません。

デバイス実装者が上記パッケージ名前空間のいずれかの改善（既存の API に便利な新機能を追加する、新しい API を追加するなど）を提案する場合、実装者は source.android.com にアクセスし、サイトに記載されている情報に従って、変更とコードに貢献するプロセスを開始すべきです。

なお、上記の制限は、Java プログラミング言語の標準的な API 命名規則に対応しています。このセクションは、この互換性定義に含めることでそれらの規則を補強し、拘束力を持たせることのみを目的としています。

3.7. ランタイムの互換性

デバイス実装は:

  • [C-0-1] 完全な Dalvik 実行ファイル（DEX）形式、Dalvik バイトコード仕様とセマンティクスをサポートしなければなりません。

  • [C-0-2] Dalvik ランタイムを構成して、アップストリーム Android プラットフォームに合わせて、下表に示すとおり、メモリを割り当てなければなりません（画面サイズと画面密度の定義については、セクション 7.1.1 をご覧ください）。

  • Dalvik 実行ファイル形式のリファレンス アップストリーム実装であり、リファレンス実装のパッケージ管理システムでもある Android ランタイム（ART）を使用すべきです。

  • ランタイムの安定性を確保するために、さまざまな実行モードとターゲット アーキテクチャでファズテストを行うべきです。Android オープンソース プロジェクトのウェブサイトで JFuzz と DexFuzz をご覧ください。

なお、下記のメモリ値は最小値とみなされ、デバイス実装はアプリごとにより多くのメモリを割り当てても構いません。

画面レイアウト 画面密度 最小アプリメモリ
Android スマートウォッチ 120 dpi（ldpi） 32 MB
140 dpi（140dpi）
160 dpi（mdpi）
180 dpi（180dpi）
200 dpi（200dpi）
213 dpi（tvdpi）
220 dpi（220dpi） 36 MB
240 dpi（hdpi）
280 dpi（280dpi）
320 dpi（xhdpi） 48 MB
360 dpi（360dpi）
400 dpi（400dpi） 56 MB
420 dpi（420dpi） 64 MB
480 dpi（xxhdpi） 88 MB
560 dpi（560dpi） 112 MB
640 dpi（xxxhdpi） 154 MB
小 / 標準 120 dpi（ldpi） 32 MB
140 dpi（140dpi）
160 dpi（mdpi）
180 dpi（180dpi） 48 MB
200 dpi（200dpi）
213 dpi（tvdpi）
220 dpi（220dpi）
240 dpi（hdpi）
280 dpi（280dpi）
320 dpi（xhdpi） 80 MB
360 dpi（360dpi）
400 dpi（400dpi） 96 MB
420 dpi（420dpi） 112 MB
480 dpi（xxhdpi） 128 MB
560 dpi（560dpi） 192 MB
640 dpi（xxxhdpi） 256 MB
大 120 dpi（ldpi） 32 MB
140 dpi（140dpi） 48 MB
160 dpi（mdpi）
180 dpi（180dpi） 80 MB
200 dpi（200dpi）
213 dpi（tvdpi）
220 dpi（220dpi）
240 dpi（hdpi）
280 dpi（280dpi） 96 MB
320 dpi（xhdpi） 128 MB
360 dpi（360dpi） 160 MB
400 dpi（400dpi） 192 MB
420 dpi（420dpi） 228 MB
480 dpi（xxhdpi） 256 MB
560 dpi（560dpi） 384 MB
640 dpi（xxxhdpi） 512 MB
特大 120 dpi（ldpi） 48 MB
140 dpi（140dpi） 80 MB
160 dpi（mdpi）
180 dpi（180dpi） 96 MB
200 dpi（200dpi）
213 dpi（tvdpi）
220 dpi（220dpi）
240 dpi（hdpi）
280 dpi（280dpi） 144 MB
320 dpi（xhdpi） 192 MB
360 dpi（360dpi） 240 MB
400 dpi（400dpi） 288 MB
420 dpi（420dpi） 336 MB
480 dpi（xxhdpi） 384 MB
560 dpi（560dpi） 576 MB
640 dpi（xxxhdpi） 768 MB

3.8. ユーザー インターフェースの互換性

3.8.1. ランチャー（ホーム画面）

Android にはランチャー アプリ（ホーム画面）があり、デバイス ランチャー（ホーム画面）を置き換えるサードパーティ アプリをサポートしています。

サードパーティ アプリでデバイスのホーム画面を置き換えられるようにする場合、デバイス実装は:

  • [C-1-1] プラットフォーム機能 android.software.home_screen を宣言しなければなりません。
  • [C-1-2] サードパーティ アプリが <adaptive-icon> タグを使用してアイコンを提供し、アイコンを取得する PackageManager メソッドが呼び出された場合、AdaptiveIconDrawable オブジェクトを返さなければなりません。

ショートカットのアプリ内固定をサポートするデフォルト ランチャーが含まれる場合、デバイス実装は:

逆に、ショートカットのアプリ内固定をサポートしない場合、デバイス実装は:

ShortcutManager API を通じてサードパーティ アプリが提供する追加のショートカットへのクイック アクセスを提供するデフォルト ランチャーを実装する場合、デバイス実装は:

  • [C-4-1] 記載されたすべてのショートカット機能（静的ショートカット、動的ショートカット、固定ショートカットなど）をサポートし、ShortcutManager API クラスの API を完全に実装しなければなりません。

アプリアイコンのバッジを表示するデフォルト ランチャー アプリが含まれる場合、デバイス実装は:

  • [C-5-1] NotificationChannel.setShowBadge() API メソッドを尊重しなければなりません。つまり、値が true に設定されている場合はアプリアイコンに関連付けられたビジュアル アフォーダンスを表示し、アプリの通知チャンネルすべてで値が false に設定されている場合はアプリアイコンのバッジスキームを表示しません。
  • サードパーティ アプリが独自仕様の API を使用して独自仕様のバッジスキームをサポートすることを示している場合、アプリアイコン バッジを独自仕様のバッジスキームでオーバーライドしても構いません。ただし、Notification.Builder.setNumber() API や Notification.Builder.setBadgeIconType() API など、SDK に記載されている通知バッジ API を通じて提供されるリソースと値を使用すべきです。

デバイス実装がモノクロ アイコンをサポートする場合、モノクロ アイコンは:

  • [C-6-1] ユーザーが（設定アプリや壁紙選択ツールのメニューなどから）明示的に有効にした場合のみに使用しなければなりません。

3.8.2. ウィジェット

Android は、アプリが 「AppWidget」をエンドユーザーに公開できるようにするコンポーネント タイプとそれに対応する API、ライフサイクルを定義することで、サードパーティ アプリ ウィジェットをサポートします。

サードパーティ アプリ ウィジェットをサポートする場合、デバイス実装は:

  • [C-1-1] プラットフォーム機能 android.software.app_widgets のサポートを宣言しなければなりません。

  • [C-1-2] AppWidget の組み込みサポートを含まなければならず、AppWidget を追加、設定、表示、削除するユーザー インターフェース アフォーダンスを公開しなければなりません。

  • [C-1-3] 標準グリッドサイズで 4 x 4 のウィジェットをレンダリングできなければなりません。詳細については、Android SDK ドキュメントのアプリ ウィジェットのデザイン ガイドラインをご覧ください。

  • ロック画面でのアプリ ウィジェットをサポートしても構いません。

サードパーティ アプリ ウィジェットと、ショートカットのアプリ内固定をサポートする場合、デバイス実装は:

3.8.3. 通知

Android には Notification API と NotificationManager API があります。これを使用すると、サードパーティ アプリのデベロッパーは、デバイスのハードウェア コンポーネント（通知音、バイブレーション、ライトなど）とソフトウェア機能（通知シェード、システムバーなど）を使用して重要なイベントをユーザーに通知し、ユーザーの注意を引くことができます。

3.8.3.1. 通知の表示

サードパーティ アプリで重要なイベントをユーザーに通知できるようにする場合、デバイス実装は:

  • [C-1-1] SDK ドキュメントに記載されているとおり、デバイス実装ハードウェアで可能な範囲で、ハードウェア機能を使用する通知をサポートしなければなりません。たとえば、デバイス実装がバイブレーターを含む場合、バイブレーション API を正しく実装しなければなりません。デバイス実装にハードウェアがない場合、対応する API を NoOps として実装しなければなりません。この動作の詳細についてはセクション 7 をご覧ください。
  • [C-1-2] API、またはステータス / システムバーのアイコン スタイルガイドで提供されているすべてのリソース（アイコン、アニメーション ファイルなど）を正しくレンダリングしなければなりません。ただし、リファレンス Android オープンソース実装で提供されているものとは別のユーザー エクスペリエンスを通知で提供しても構いません。
  • [C-1-3] API について記述した動作を使用し、適切に実装して、通知を更新、削除、グループ化しなければなりません。
  • [C-1-4] SDK に記載されている NotificationChannel API のすべての動作を提供しなければなりません。
  • [C-1-5] チャンネルごと、アプリ パッケージ レベルごとに、特定のサードパーティ アプリの通知をブロック、変更するユーザー アフォーダンスを提供しなければなりません。
  • [C-1-6] 削除した通知チャンネルを表示するユーザー アフォーダンスも提供しなければなりません。

  • [C-1-7] 追加のユーザー操作なしで、Notification.MessagingStyle を通じて提供されるすべてのリソース（画像、ステッカー、アイコンなど）を、通知テキストとともに正しくレンダリングしなければなりません。たとえば、setGroupConversation を通じて設定されたグループの会話では、android.app.Person を通じて提供されたアイコンを含め、すべてのリソースを表示しなければなりません。

  • [C-SR-1] 通知リスナー権限が付与されたアプリに公開される通知をユーザーが制御するアフォーダンスを提供することが強く推奨されます。粒度は、そのような通知リスナーごとに、そのリスナーにブリッジされる通知タイプをユーザーが制御できるようなものでなければなりません。タイプには、「会話」、「アラート」、「サイレント」、「重要な進行中」の通知が含まれなければなりません。

  • [C-SR-2] ユーザーが特定の通知リスナーへの通知から除外するアプリを指定するアフォーダンスを提供することが強く推奨されます。

  • [C-SR-3] 特定のサードパーティ アプリの通知を、ユーザーがその通知を複数回閉じた後、チャンネルごと、アプリ パッケージ レベルごとにブロックするユーザー アフォーダンスを自動的に表示させることが強く推奨されます。

  • リッチ通知をサポートすべきです。

  • 一部の高優先度の通知をヘッドアップ通知として提示すべきです。

  • 通知をスヌーズするユーザー アフォーダンスがあるべきです。

  • ドライバーの注意散漫などの安全上の問題を軽減するために、サードパーティ アプリが重要なイベントをユーザーに通知できるタイミングと表示のみ、管理しても構いません。

Android 11 では、MessagingStyle を使用した、公開されている個人のショートカット ID を提供する通知である、会話通知のサポートが導入されています。

デバイス実装は:

  • [C-SR-4] 進行中のフォアグラウンド サービス通知と importance:high の通知を除き、会話以外の通知より前に conversation notifications をグループ化して表示することが強く推奨されます。

conversation notifications をサポートし、アプリが bubbles に必要なデータを提供する場合、デバイス実装は:

  • [C-SR-5] この会話をバブルとして表示することが強く推奨されます。AOSP 実装はデフォルトのシステム UI、設定、ランチャーで、この要件を満たしています。

リッチ通知をサポートする場合、デバイス実装は:

  • [C-2-1] Notification.Style API クラスとそのサブクラスを通じて提供されたとおりのリソースを、提示されたリソース要素に使用しなければなりません。
  • Notification.Style API クラスとそのサブクラスで定義された各リソース要素（アイコン、タイトル、概要テキストなど）をすべて提示すべきです。

ヘッドアップ通知とは、ユーザーがどの画面を表示しているかにかかわらず、着信時にユーザーに表示される通知です。ヘッドアップ通知をサポートする場合、デバイス実装は:

  • [C-3-1] ヘッドアップ通知を提示するとき、Notification.Builder API クラスに記載されているとおり、ヘッドアップ通知ビューとリソースを使用しなければなりません。
  • [C-3-2] SDK に記載されているとおり、追加のユーザー操作なしで、Notification.Builder.addAction() を通じて提供されるアクションを通知コンテンツとともに表示しなければなりません。
3.8.3.2. 通知リスナー サービス

Android には、NotificationListenerService API があります。これにより、アプリは通知がポストされたか更新されたときに、全通知のコピーを受け取ることができます（ユーザーが明示的に有効にした場合）。

デバイス実装は:

  • [C-0-1] 通知オブジェクトにアタッチされているすべてのメタデータを含め、インストールされていてユーザーが有効にしたすべてのリスナー サービスで、通知全体を正確かつ迅速に更新しなければなりません。
  • [C-0-2] snoozeNotification() API 呼び出しを尊重し、通知を閉じ、API 呼び出しに設定されたスヌーズ継続時間後にコールバックを行わなければなりません。

通知をスヌーズするユーザー アフォーダンスがある場合、デバイス実装は:

  • [C-1-1] NotificationListenerService.getSnoozedNotifications() などの標準 API を通じて、スヌーズされた通知ステータスを適切に反映しなければなりません。
  • [C-1-2] 永続 / フォアグラウンド サービスからのものでない限り、このユーザー アフォーダンスを、インストールされている各サードパーティー アプリからの通知をスヌーズするために利用できるようにしなければなりません。
3.8.3.3. DND（サイレント モード） / 優先モード

DND 機能（優先モードともいいます）をサポートする場合、デバイス実装は:

  • [C-1-1] サードパーティ アプリに対して DND ポリシー構成へのアクセスを許可または拒否する手段をデバイス実装がユーザーに提供した場合、ユーザーが作成した事前定義済みルールとともに、アプリが作成した自動 DND ルールを表示しなければなりません。
  • [C-1-3] NotificationManager.Policy に沿って渡された suppressedVisualEffects 値を使用しなければならず、アプリが SUPPRESSED_EFFECT_SCREEN_OFF フラグまたは SUPPRESSED_EFFECT_SCREEN_ON フラグのいずれかを設定している場合、DND 設定メニューで視覚効果が抑制されていることをユーザーに示すべきです。

3.8.4. Assist API

Android には、現在のコンテキストの情報をデバイスのアシスタントとどの程度共有するかをアプリが選択できるようにする Assist API が用意されています。

アシスト アクションをサポートする場合、デバイス実装は:

  • [C-2-1] コンテキストが共有される際、次のいずれかによって、エンドユーザーに対し明確に示さなければなりません。
    • アシストアプリがコンテキストにアクセスするたびに、Android オープンソース プロジェクト実装での継続時間、明るさと同等以上の白色光を、画面の端に表示する。
    • プリインストールのアシストアプリでは、デフォルトのオーディオ入力とアシスタント アプリの設定メニューから 2 操作未満でユーザー アフォーダンスを提供し、起動ワードまたはアシスト ナビゲーション キー入力を通じてアシストアプリがユーザーによって明示的に起動された場合にのみコンテキストを共有する。
  • [C-2-2] セクション 7.2.3 に記載されている、アシストアプリを起動する指定操作は、ユーザーが選択したアシストアプリ、つまり VoiceInteractionService を実装したアプリまたは ACTION_ASSIST インテントを処理するアクティビティを起動しなければなりません。

3.8.5. アラートとトースト

アプリは Toast API を使用して、エンドユーザーに対し、短時間で消える短い非モーダル文字列を表示できます。また、TYPE_APPLICATION_OVERLAY ウィンドウ タイプ API を使用して、他のアプリに重ねてアラート ウィンドウを表示できます。

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

  • [C-1-1] TYPE_APPLICATION_OVERLAY を使用するアラート ウィンドウをアプリが表示しないようにブロックするユーザー アフォーダンスを提供しなければなりません。AOSP 実装は通知シェードにコントロールがあることで、この要件を満たしています。

  • [C-1-2] Toast API を使用し、アプリからエンドユーザーへのトーストを、なんらかの目立つ方法で表示しなければなりません。

3.8.6. テーマ

Android は、アプリがアクティビティまたはアプリの全体にわたってスタイルを適用するためのメカニズムとして「テーマ」を提供します。

Android には、アプリ デベロッパーが Android SDK で定義された Holo テーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「Holo」と「Material」があります。

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

  • [C-1-1] アプリに公開されているいずれの Holo テーマ属性も変更してはなりません。
  • [C-1-2] 「Material」テーマ ファミリーをサポートしなければならず、アプリに公開される Material テーマ属性またはそのアセットのいずれについても変更してはなりません。

  • [C-1-3] Roboto がサポートしている言語について「sans-serif」フォント ファミリーを Roboto バージョン 2.x に設定しなければなりません。または、Roboto がサポートしている言語について「sans-serif」フォント ファミリーに使用するフォントを Roboto バージョン 2.x に変更するユーザー アフォーダンスを提供しなければなりません。

  • [C-1-4] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES の AOSP ドキュメント（android.theme.customization.system_palette と android.theme.customization.theme_style を参照）で指定されているとおりに、動的な色調パレットを生成しなければなりません。

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

    「ソースカラー」は、Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES に記載されているとおり、android.theme.customization.system_palette で送信されるときに動的な色調パレットを生成するために使用されます。

  • [C-1-6] CAM16 彩度の値が 5 以上でなければなりません。

    • com.android.systemui.monet.ColorScheme#getSeedColors を介して壁紙から取得すべきです。これにより、複数の有効なソースカラーが提供され、そこから色を選択できます。

    • 提供された色のいずれも上記のソースカラーの要件を満たしていない場合、値 0xFF1B6EF3 を使用すべきです。

Android には、アプリ デベロッパーがデバイス実装者によって定義されたデバイステーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「デバイスのデフォルト」のテーマ ファミリーも用意されています。

Android は、異なる形のテーマとして、半透明のシステムバーを使用したテーマをサポートしています。これにより、アプリ デベロッパーは、ステータスバーとナビゲーション バーの背後のエリア全体にアプリ コンテンツを表示することができます。この構成でデベロッパー エクスペリエンスに一貫性を持たせるには、さまざまなデバイス実装でステータスバーのアイコン スタイルを維持することが重要です。

システム ステータスバーが含まれる場合、デバイス実装は:

  • [C-2-1] アイコンが問題のあるステータスを示すか、アプリが WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS フラグを使用してライト ステータスバーをリクエストする場合を除き、システム ステータス アイコン（信号強度やバッテリー残量など）と、システムが発行する通知には、白色を使用しなければなりません。
  • [C-2-2] Android デバイス実装は、アプリがライト ステータスバーをリクエストしたら、システム ステータス アイコンを黒色に変更しなければなりません（詳細については R.style をご覧ください）。

3.8.7. ライブ壁紙

Android では、アプリがエンドユーザーに 1 つ以上の 「ライブ壁紙」を公開できるようにするためのコンポーネント タイプとそれに対応する API、ライフサイクルを定義しています。ライブ壁紙とは、壁紙として他のアプリの背後に表示される、アニメーション、パターン、または入力機能が制限された同様の画像のことです。

ハードウェアは、他のアプリに悪影響を及ぼさず、妥当なフレームレートで、機能に制限なくすべてのライブ壁紙を実行できる場合、ライブ壁紙を確実に実行できるとみなされます。ハードウェアの制限によって、壁紙やアプリがクラッシュする、誤動作する、CPU やバッテリー電力を過剰に使用する、または許容できない低フレームレートで実行される場合、ハードウェアはライブ壁紙を実行できないとみなされます。たとえば、一部のライブ壁紙は、OpenGL 2.0 または 3.x コンテキストを使用してコンテンツをレンダリングすることがあります。複数の OpenGL コンテキストをサポートしていないハードウェアでは、OpenGL コンテキストを使用するライブ壁紙が、OpenGL コンテキストを使用する他のアプリと競合する可能性があるため、ライブ壁紙を確実には実行できません。

  • 上記のようにライブ壁紙を確実に実行できるデバイス実装は、ライブ壁紙を実装すべきです。

ライブ壁紙を実装する場合、デバイス実装は:

  • [C-1-1] プラットフォーム機能フラグ android.software.live_wallpaper をレポートしなければなりません。

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

アップストリームの Android ソースコードには、概要画面が含まれます。これは、タスクの切り替えのためのシステムレベルのユーザー インターフェースです。ユーザーが最後にアプリを離れたときのアプリのグラフィック状態のサムネイル画像を使用して、最近アクセスしたアクティビティやタスクを表示することにも使われます。

セクション 7.2.3 で詳述するように、履歴機能のナビゲーション キーを含むデバイス実装は、インターフェースを変更しても構いません。

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

  • [C-1-1] 少なくとも 7 つまでのアクティビティ表示をサポートしなければなりません。
  • 少なくとも同時に 4 つのアクティビティのタイトルを表示すべきです。

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

  • ハイライトの色、アイコン、最近の画面タイトルを表示すべきです。
  • 閉じるアフォーダンス（「x」）を表示すべきですが、ユーザーが画面を操作するまで遅らせても構いません。
  • 以前のアクティビティに切り替えやすくするためのショートカットを実装すべきです。
  • 履歴機能のキーが 2 回タップされたとき、直近に使用した 2 つのアプリを素早く切り替えるアクションをトリガーすべきです。
  • 履歴機能のキーが長押しされたとき、分割画面のマルチウィンドウ モードをトリガーすべきです（サポートしている場合）。
  • 一緒に移動するグループとして関連する履歴を表示しても構いません。
  • [C-SR-1] 概要画面には、アップストリームの Android ユーザー インターフェース（またはサムネイルベースの同様のインターフェース）を使用することが強く推奨されます。

3.8.9. 入力管理

Android は、入力管理と、サードパーティのインプット メソッド エディタをサポートしています。

ユーザーがデバイスでサードパーティの入力方法を使用できるようにする場合、デバイス実装は:

  • [C-1-1] Android SDK ドキュメントで定義されているとおり、プラットフォーム機能 android.software.input_methods を宣言し、IME API をサポートしなければなりません。

3.8.10. ロック画面のメディア コントロール

Remote Control Client API のサポートは Android 5.0 で終了し、ロック画面に表示される再生コントロールとメディアアプリを統合できるメディア通知テンプレートに置き換えられました。

3.8.11. スクリーン セーバー（旧 Dreams）

スクリーン セーバーを構成するための設定についてはセクション 3.2.3.5 をご覧ください。

3.8.12. 位置情報

位置座標を提供できるハードウェア センサー（GPS など）が含まれる場合、デバイス実装は:

3.8.13. Unicode とフォント

Android は、Unicode 10.0 で定義されている絵文字をサポートしています。

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

  • [C-1-1] こうした絵文字をカラーグリフでレンダリングできなければなりません。
  • [C-1-2] 次のサポートを含まなければなりません。
    • ウェイトの異なる Roboto 2 フォント - デバイスで利用可能な言語の sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light。
    • ラテン文字拡張 A、B、C、D を含むラテン文字、ギリシャ文字、キリル文字の Unicode 7.0 全範囲、Unicode 7.0 の通貨記号ブロックのグリフすべて。
  • [C-1-3] システム イメージ内の NotoColorEmoji.tff を削除または変更してはなりません（新しい絵文字フォントを追加して NotoColorEmoji.tff の絵文字をオーバーライドすることは可能です）。
  • Unicode Technical Report #51 で規定されているとおり、肌の色と多様な家族の絵文字をサポートすべきです。

IME が含まれる場合、デバイス実装は:

  • これらの絵文字の入力方法をユーザーに提供すべきです。

Android は、ミャンマー フォントのレンダリングをサポートしています。ミャンマーには、ミャンマー語をレンダリングするための Unicode 非準拠のフォントがいくつかあります（一般に「Zawgyi」と呼ばれます）。

ビルマ語のサポートが含まれる場合、デバイス実装は:

  • [C-2-1] デフォルトでは、Unicode 準拠のフォントでテキストをレンダリングしなければなりません。ユーザーが言語選択ツールで選択した場合を除き、Unicode 非準拠のフォントをデフォルト フォントとして設定してはなりません。
  • [C-2-2] デバイスで Unicode 非準拠のフォントがサポートされている場合は、Unicode フォントと Unicode 非準拠のフォントをサポートしなければなりません。Unicode 非準拠のフォントで、Unicode フォントを削除または上書きしてはなりません。
  • [C-2-3] Unicode 非準拠のフォントでテキストをレンダリングしなければならないのは、スクリプト コード Qaag を使用する言語コード（my-Qaag など）が指定されている場合のみです。それ以外の ISO 言語または地域コード（割り当て済みか、未割り当てか、予約済みかを問わず）は、ミャンマー語の Unicode 非準拠フォントを参照するために使用することはできません。アプリ デベロッパーとウェブページ作成者は、他の言語の場合と同じように、指定の言語コードとして my-Qaag を指定できます。

3.8.14. マルチウィンドウ

複数のアクティビティを同時に表示する機能がある場合、デバイス実装は:

  • [C-1-1] Android SDK のマルチウィンドウ モードのサポートに関するドキュメントに記載されているアプリの動作と API に従ってマルチ ウィンドウ モードを実装し、下記の要件を満たさなければなりません。
  • [C-1-2] こちらの SDK に記載されているとおり、AndroidManifest.xml ファイル内の、アプリによって設定された android:resizeableActivity を使用しなければなりません。
  • [C-1-3] 画面の高さが 440 dp 未満、画面の幅が 440 dp 未満の場合、分割画面モードまたはフリーフォーム モードを提供してはなりません。
  • [C-1-4] ピクチャー イン ピクチャー以外のマルチウィンドウ モードで、アクティビティを 220dp 未満にサイズ変更してはなりません。
  • 画面サイズが xlarge のデバイス実装は、フリーフォーム モードをサポートすべきです。

マルチウィンドウ モードと分割画面モードをサポートする場合、デバイス実装は:

  • [C-2-2] 分割画面マルチウィンドウの固定されたアクティビティを切り抜かなければなりませんが、ランチャー アプリがフォーカスされたウィンドウの場合、コンテンツの一部を表示すべきです。
  • [C-2-3] サードパーティ ランチャー アプリの宣言された AndroidManifestLayout_minWidth 値と AndroidManifestLayout_minHeight 値を使用しなければならず、固定されたアクティビティの一部のコンテンツを表示する過程でこれらの値をオーバーライドしてはなりません。

マルチウィンドウ モードとピクチャー イン ピクチャー マルチウィンドウ モードをサポートする場合、デバイス実装は:

  • [C-3-1] アプリが次の場合、アクティビティをピクチャー イン ピクチャー マルチウィンドウ モードで起動しなければなりません: * API レベル 26 以降をターゲットとし、android:supportsPictureInPicture を宣言する場合、* API レベル 25 以前をターゲットとし、android:resizeableActivity と android:supportsPictureInPicture の両方を宣言する場合。
  • [C-3-2] setActions() API を通じて現在の PIP アクティビティで指定されている SystemUI のアクションを公開しなければなりません。
  • [C-3-3] setAspectRatio() API を通じて PIP アクティビティで指定されているとおり、1:2.39 以上 2.39:1 以下のアスペクト比をサポートしなければなりません。
  • [C-3-4] KeyEvent.KEYCODE_WINDOW を使用して PIP ウィンドウをコントロールしなければなりません。PIP モードが実装されていない場合は、キーがフォアグラウンド アクティビティで利用可能でなければなりません。
  • [C-3-5] アプリが PIP モードで表示されないようにブロックするユーザー アフォーダンスを提供しなければなりません。AOSP 実装は通知シェードにコントロールがあることで、この要件を満たしています。

  • [C-3-6] アプリが AndroidManifestLayout_minWidth と AndroidManifestLayout_minHeight の値を宣言しない場合、次に示す PIP ウィンドウの最小の幅と高さを割り当てなければなりません。

    • Configuration.uiMode が UI_MODE_TYPE_TELEVISION 以外に設定されたデバイスは、最小の幅と高さ 108 dp を割り当てなければなりません。
    • Configuration.uiMode が UI_MODE_TYPE_TELEVISION に設定されたデバイスは、最小の幅 240 dp、最小の高さ 135 dp を割り当てなければなりません。

3.8.15. ディスプレイ カットアウト

Android は、SDK ドキュメントに記載されているとおり、ディスプレイ カットアウトをサポートしています。DisplayCutout API は、縁のディスプレイ カットアウトまたは曲面ディスプレイのためにアプリで機能しないことがある、ディスプレイの縁のエリアを定義します。

ディスプレイ カットアウトが含まれる場合、デバイス実装は:

  • [C-1-5] デバイスのアスペクト比が 1.0（1:1）の場合、カットアウトがあってはなりません。
  • [C-1-2] 縁 1 つにつきカットアウトが 1 つを超えてはなりません。
  • [C-1-3] SDK に記載されているとおり、WindowManager.LayoutParams API を通じてアプリが設定したディスプレイ カットアウト フラグを使用しなければなりません。
  • [C-1-4] DisplayCutout API で定義されたすべてのカットアウト指標について正しい値をレポートしなければなりません。

3.8.16. デバイス コントロール

Android には、サードパーティ アプリがユーザーにクイック ステータスとアクションのデバイス コントロールを公開できる、ControlsProviderService API と Control API があります。

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

3.8.17. クリップボード

デバイス実装は:

  • [C-0-1] 9.8.6 コンテンツ キャプチャとアプリ検索に記載されているサービスを除き、ユーザーによる明示的な操作（オーバーレイのボタンを押すなど）なしに、コンポーネント、アクティビティ、サービスに対して、またはネットワーク接続を介して、クリップボード データを送信してはなりません。

ClipData.getDescription().getExtras() に android.content.extra.IS_SENSITIVE を含むいずれかの ClipData アイテムのクリップボードに、コンテンツがコピーされたときにユーザーに表示されるプレビューを生成する場合、デバイス実装は:

  • [C-1-1] ユーザーに表示されるプレビューを編集しなければなりません。

AOSP リファレンス実装は、これらのクリップボードの要件を満たしています。

3.9. デバイス管理

Android には、Android Device Administration API を通じて、セキュリティ対応アプリがシステムレベルでデバイス管理機能（パスワード ポリシーの適用、リモートワイプの実施など）を実行できる機能があります。

Android SDK ドキュメントで規定されているすべてのデバイス管理ポリシーを実装する場合、デバイス実装は:

  • [C-1-1] android.software.device_admin を宣言しなければなりません。
  • [C-1-2] セクション 3.9.1 とセクション 3.9.1.1 に記載されているとおり、デバイス所有者のプロビジョニングをサポートしなければなりません。

3.9.1 デバイスのプロビジョニング

3.9.1.1 デバイス所有者のプロビジョニング

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

  • [C-1-1] 下記のとおり、デバイス所有者アプリとしてのデバイス ポリシー クライアント（DPC）の登録をサポートしなければなりません。
    • ユーザーもユーザーデータも設定されていない場合、デバイス実装は:
      • [C-1-5] デバイスが機能フラグ android.hardware.nfc を介して近距離無線通信（NFC）のサポートを宣言していて、MIME タイプ MIME_TYPE_PROVISIONING_NFC のレコードを含む NFC メッセージを受信する場合は、DPC アプリをデバイス所有者アプリとして登録するか、DPC アプリがデバイス所有者とプロファイル所有者のどちらになるかを選択できるようにしなければなりません。
      • [C-1-8] android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES の値に応じて DPC アプリがデバイス所有者とプロファイル所有者のどちらになるかを選択できるように、デバイス所有者のプロビジョニングがトリガーされた後、ACTION_GET_PROVISIONING_MODE インテントを送信しなければなりません。ただし、有効なオプションが 1 つしかないことがコンテキストから判断できる場合を除きます。
      • [C-1-9] 使用するプロビジョニング方法にかかわらず、プロビジョニング中にデバイス所有者が確定したら、デバイス所有者アプリに ACTION_ADMIN_POLICY_COMPLIANCE インテントを送信しなければなりません。デバイス所有者アプリが終了するまで、ユーザーが設定ウィザードを続行できてはなりません。
    • ユーザーまたはユーザーデータがある場合、デバイス実装は:
      • [C-1-7] これ以上、DPC アプリをデバイス所有者アプリとして登録してはなりません。

  • [C-1-2] 適切な開示通知（AOSP で参照）を示し、アプリがデバイス所有者として設定される前に、エンドユーザーから明示的な同意を得なければなりません。ただし、エンドユーザーによる画面操作の前に、デバイスがプログラムによって販売店デモモードに設定されている場合を除きます。android.software.device_admin を宣言するだけでなく、独自のデバイス管理ソリューションも含んでいて、そのソリューションで「デバイス所有者相当」として構成されたアプリを、標準の Android DevicePolicyManager API によって認識される標準の「デバイス所有者」に昇格させるメカニズムを提供する場合、デバイス実装は:

  • [C-2-1] 昇格された特定のアプリが正当な企業デバイス管理ソリューションに属し、独自のソリューションにより「デバイス所有者」と同等の権限を持つように構成されていることを検証するためのプロセスが定められていなければなりません。

  • [C-2-2] DPC アプリを「デバイス所有者」として登録する前に、android.app.action.PROVISION_MANAGED_DEVICE で開始されるフローと同じ AOSP デバイス所有者同意開示を示さなければなりません。

  • [C-2-3] 同意をハードコードしたり、他のデバイス所有者アプリの使用を妨げたりしてはなりません。

3.9.1.2 管理対象プロファイルのプロビジョニング

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

  • [C-1-1] Device Policy Controller（DPC）アプリを新しい管理対象プロファイルの所有者にできる API を実装しなければなりません。

  • [C-1-2] 管理対象プロファイルのプロビジョニング プロセス（android.app.action.PROVISION_MANAGED_PROFILE を使用して DPC によって開始されるフロー）、同意画面、ユーザー エクスペリエンスは、AOSP 実装に合わせなければなりません。

  • [C-1-3] 特定のシステム機能が Device Policy Controller（DPC）によって無効にされたことをユーザーに示すために、設定内で次のユーザー アフォーダンスを提供しなければなりません。

    • 特定の設定がデバイス管理者によって制限されている場合に表示される、一貫したアイコンまたはその他のユーザー アフォーダンス（たとえば、アップストリームの AOSP の情報アイコン）。
    • setShortSupportMessage を介してデバイス管理者によって提供される、短い説明メッセージ。
    • DPC アプリのアイコン。

  • [C-1-4] android.app.action.PROVISION_MANAGED_PROFILE インテントによってプロビジョニングが開始されたときにプロファイル所有者が確定し、DPC がハンドラを実装していれば、ACTION_PROVISIONING_SUCCESSFUL インテントのハンドラを起動しなければなりません。

  • [C-1-5] android.app.action.PROVISION_MANAGED_PROFILE インテントによってプロビジョニングが開始されたら、ACTION_PROFILE_PROVISIONING_COMPLETE ブロードキャストを仕事用プロファイル DPC に送信しなければなりません。

  • [C-1-6] DPC アプリがデバイス所有者とプロファイル所有者のどちらになるか選択できるように、プロファイル所有者のプロビジョニングがトリガーされた後、ACTION_GET_PROVISIONING_MODE インテントを送信しなければなりません。ただし、インテント android.app.action.PROVISION_MANAGED_PROFILE によってプロビジョニングがトリガーされた場合を除きます。

  • [C-1-7] 使用するプロビジョニング方法にかかわらず、プロビジョニング中にプロファイル所有者が確定したら、ACTION_ADMIN_POLICY_COMPLIANCE インテントを仕事用プロファイルに送信しなければなりません。ただし、インテント android.app.action.PROVISION_MANAGED_PROFILE によってプロビジョニングがトリガーされた場合を除きます。プロファイル所有者アプリが終了するまで、ユーザーが設定ウィザードを続行できてはなりません。

  • [C-1-8] 使用するプロビジョニング方法にかかわらず、プロファイル所有者が確定したら、ACTION_MANAGED_PROFILE_PROVISIONED ブロードキャストを個人用プロファイル DPC に送信しなければなりません。

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

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

  • [C-1-1] android.app.admin.DevicePolicyManager API を介して管理対象プロファイルをサポートしなければなりません。
  • [C-1-2] 管理対象プロファイルを 1 つだけ作成できるようにしなければなりません。
  • [C-1-3] アイコンバッジ（AOSP のアップストリームの仕事用バッジに類似）を使用して、管理対象アプリとウィジェットや、履歴と通知のような他のバッジ付き UI 要素を表さなければなりません。
  • [C-1-4] 通知アイコン（AOSP のアップストリームの仕事用バッジに類似）を表示して、ユーザーが管理対象プロファイル アプリ内にいることを示さなければなりません。
  • [C-1-5] デバイスが復帰（ACTION_USER_PRESENT）し、フォアグラウンド アプリが管理対象プロファイル内にある場合、ユーザーが管理対象プロファイル内にいることを示すトーストを表示しなければなりません。
  • [C-1-6] 管理対象プロファイルが存在する場合、Device Policy Controller によって有効にされていれば、インテントを選択するユーザーにビジュアル アフォーダンスを表示して、ユーザーが管理対象プロファイルからプライマリ ユーザーに（またはその逆に）インテントを転送できるようにしなければなりません。
  • [C-1-7] 管理対象プロファイルが存在する場合、プライマリ ユーザーと管理対象プロファイルの両方について、次のユーザー アフォーダンスを公開しなければなりません。
    • プライマリ ユーザーと管理対象プロファイルの、バッテリー、位置情報、モバイルデータ、ストレージ使用量に関する個別の計算。
    • プライマリ ユーザーまたは管理対象プロファイルにインストールされている VPN アプリの独立した管理。
    • プライマリ ユーザーまたは管理対象プロファイルにインストールされているアプリの独立した管理。
    • プライマリ ユーザーまたは管理対象プロファイル内のアカウントの独立した管理。
  • [C-1-8] Device Policy Controller が許可している場合、プリインストールの電話アプリ、連絡先アプリ、メッセージ アプリが、プライマリ プロファイルからの情報とともに管理対象プロファイル（存在する場合）からの発信者情報を検索できるようにしなければなりません。
  • [C-1-9] 管理対象プロファイルがプライマリ ユーザーに加えて別のユーザーとしてカウントされない場合でも、複数のユーザーが有効になっているデバイスに適用されるセキュリティ要件（セクション 9.5 参照）をすべて満たしていることを確認しなければなりません。

新しい要件の開始

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

新しい要件の終了

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

  • [C-2-1] 次の要件を満たす個別のロック画面を指定する機能をサポートして、管理対象プロファイルのみで実行されているアプリへのアクセス権を付与しなければなりません。
    • デバイス実装は、DevicePolicyManager.ACTION_SET_NEW_PASSWORD インテントを使用し、管理対象プロファイルの個別のロック画面認証情報を設定するインターフェースを表示しなければなりません。
    • Android オープンソース プロジェクトのサイトに記載されているとおり、管理対象プロファイルのロック画面認証情報は、親プロファイルと同じ認証情報ストレージと管理メカニズムを使用しなければなりません。
    • DPC パスワード ポリシーは、getParentProfileInstance によって返される DevicePolicyManager インスタンスで呼び出されない限り、管理対象プロファイルのロック画面認証情報にのみ適用しなければなりません。
  • 管理対象プロファイルの連絡先が、プリインストールの通話履歴、通話 UI、通話中通知、不在着信通知、連絡先、メッセージ アプリに表示される場合、管理対象プロファイル アプリを示すために使用されるものと同じバッジを付けるべきです。

3.9.3 管理対象ユーザーのサポート

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

  • [C-1-1] isLogoutEnabled が true を返す場合、複数ユーザー セッションでは、現在のユーザーからログアウトしてプライマリ ユーザーに切り戻すユーザー アフォーダンスを提供しなければなりません。ユーザー アフォーダンスは、デバイスをロック解除せずにロック画面からアクセスできなければなりません。

android.software.device_admin を宣言し、他のセカンダリ ユーザーを追加するオンデバイス ユーザー アフォーダンスを提供する場合、デバイス実装は:

  • [C-SR-1] 新しいセカンダリ ユーザーにアカウントを追加できるようにする前に、android.app.action.PROVISION_MANAGED_DEVICE によって開始されたフローで示されたものと同じ AOSP デバイス所有者同意開示を示すことが強く推奨されます。これにより、ユーザーはデバイスが管理されていることを把握できます。

3.9.4 デバイス ポリシー管理ロールの要件

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

  • [C-1-1] セクション 9.1 で定義されているとおり、デバイス ポリシー管理のロールをサポートしなければなりません。デバイス ポリシー管理ロールを保持するアプリは、config_devicePolicyManagement をパッケージ名に設定することで定義しても構いません。アプリがプリロードされていない限り、パッケージ名の後に : と署名証明書を付けなければなりません。

config_devicePolicyManagement のパッケージ名が上記のように定義されていない場合:

  • [C-2-1] デバイス実装は、デバイス ポリシー管理のロールを保持するアプリなしでのプロビジョニングをサポートしなければなりません（AOSP がリファレンス実装を提供）。

config_devicePolicyManagement のパッケージ名が上記のように定義されている場合:

  • [C-3-1] ユーザーのすべてのプロファイルに、アプリをインストールしなければなりません。
  • [C-3-2] デバイス実装は、config_devicePolicyManagementUpdater を設定することで、プロビジョニング前にデバイス ポリシー管理のロール保持者を更新するアプリを定義しても構いません。

config_devicePolicyManagementUpdater のパッケージ名が上記のように定義されている場合:

  • [C-4-1] アプリをデバイスにプリインストールしなければなりません。
  • [C-4-2] アプリは、android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER を解決するインテント フィルタを実装しなければなりません。

新しい要件の開始

3.9.5 デバイス ポリシー解決フレームワーク

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

新しい要件の終了

3.10. ユーザー補助

Android は、障がいのあるユーザーがより簡単にデバイスを操作できるようにするためのユーザー補助レイヤを提供します。また、ユーザー補助サービスの実装によってユーザーとシステム イベントのコールバックを受信し、テキスト読み上げ、触覚フィードバック、トラックボール / D-pad ナビゲーションなどの代替フィードバック メカニズムを生成できるプラットフォーム API を提供します。

サードパーティのユーザー補助サービスをサポートする場合、デバイス実装は:

  • [C-1-1] ユーザー補助 API の SDK ドキュメントに記載されているとおり、Android ユーザー補助フレームワークの実装を提供しなければなりません。
  • [C-1-2] SDK に記載されているとおり、ユーザー補助イベントを生成し、登録されているすべての AccessibilityService 実装に、適切な AccessibilityEvent を配信しなければなりません。
  • [C-1-4] AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON を宣言するユーザー補助サービスをコントロールするユーザー アフォーダンスを提供しなければなりません。なお、システム ナビゲーション バーのあるデバイス実装では、システムのナビゲーション バーのボタンで、こうしたサービスをコントロールするオプションをユーザーに認めるべきです。

プリインストールのユーザー補助サービスが含まれる場合、デバイス実装は:

  • [C-2-1] データ ストレージがファイルベースの暗号化（FBE）で暗号化される場合、こうしたプリインストールのユーザー補助サービスをダイレクト ブート対応アプリとして実装しなければなりません。
  • 関連するユーザー補助サービスや、フォントサイズ、ディスプレイ サイズ、拡大操作を調節するオプションをユーザーが有効にする初期設定フロー メカニズムを提供すべきです。

3.11. テキスト読み上げ

Android には、アプリがテキスト読み上げ（TTS）サービスを利用できるようにし、サービス プロバイダが TTS サービスの実装を提供できるようにする API があります。

機能 android.hardware.audio.output をレポートする場合、デバイス実装は:

サードパーティ TTS エンジンのインストールをサポートする場合、デバイス実装は:

  • [C-2-1] システムレベルで使用する TTS エンジンをユーザーが選択できるようにするユーザー アフォーダンスを提供しなければなりません。

3.12. テレビ入力フレームワーク

Android テレビ入力フレームワーク（TIF）により、Android テレビデバイスへのライブ コンテンツの配信が簡単になります。TIF は、Android テレビデバイスをコントロールする入力モジュールを作成するための標準 API を提供します。

TIF をサポートする場合、デバイス実装は:

  • [C-1-1] プラットフォーム機能 android.software.live_tv を宣言しなければなりません。
  • [C-1-2] TIF API とサードパーティの TIF ベースの入力サービスを使用するアプリをデバイスにインストールして使用できるように、すべての TIF API をサポートしなければなりません。

3.13. クイック設定

Android は、よく使用するアクションや緊急に必要なアクションにすばやくアクセスできるクイック設定 UI コンポーネントを提供します。

クイック設定 UI コンポーネントが含まれ、サードパーティのクイック設定をサポートする場合、デバイス実装は:

  • [C-1-1] サードパーティ アプリから quicksettings API を通じて提供されるタイルを、ユーザーが追加または削除できるようにしなければなりません。
  • [C-1-2] タイルをサードパーティ アプリからクイック設定に直接自動的に追加してはなりません。
  • [C-1-3] システム提供のクイック設定タイルとともに、サードパーティ アプリからユーザーが追加したタイルをすべて表示しなければなりません。

3.14. メディア UI

デバイス実装に、MediaBrowser または MediaSession を介してサードパーティ アプリを操作する音声認識以外のアプリが含まれる場合、そのアプリは:

  • [C-1-2] MediaDescription に記載されているとおり、getIconBitmap() または getIconUri() を介して取得したアイコンと、getTitle() を介して取得したタイトルを、明確に表示しなければなりません。安全規則（ドライバーの注意散漫など）を遵守するためにタイトルを短縮しても構いません。

  • [C-1-3] サードパーティ アプリが提供するコンテンツを表示する際、必ずそのサードパーティ アプリのアイコンを表示しなければなりません。

  • [C-1-4] ユーザーが MediaBrowser 階層全体を操作できるようにしなければなりません。安全規則（ドライバーの注意散漫など）を遵守するために階層の一部へのアクセスを制限しても構いませんが、コンテンツまたはコンテンツ プロバイダに基づいて優先的な取り扱いをしてはなりません。

  • [C-1-5] KEYCODE_HEADSETHOOK または KEYCODE_MEDIA_PLAY_PAUSE のダブルタップを MediaSession.Callback#onMediaButtonEvent の KEYCODE_MEDIA_NEXT とみなさなければなりません。

3.15. Instant Apps

デバイス実装は、Instant Apps をサポートする場合、以下の要件を満たさなければなりません。

  • [C-1-1] Instant Apps には、android:protectionLevel が "instant" に設定された権限のみを付与しなければなりません。
  • [C-1-2] Instant Apps は、次のいずれかに該当する場合を除き、暗黙的インテントを介してインストール済みのアプリを操作してはなりません。
    • コンポーネントのインテント パターン フィルタが公開されており、CATEGORY_BROWSABLE が設定されている
    • アクションが、ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE のいずれかである
    • ターゲットが android:visibleToInstantApps で明示的に公開されている
  • [C-1-3] Instant Apps は、コンポーネントが android:visibleToInstantApps を介して公開されている場合を除き、インストール済みのアプリを明示的に操作してはなりません。
  • [C-1-4] インストール済みのアプリは、Instant Apps がインストール済みのアプリに明示的に接続する場合を除き、デバイスの Instant Apps の詳細を表示してはなりません。

  • デバイス実装は、Instant Apps を操作するために次のユーザー アフォーダンスを提供しなければなりません。AOSP はデフォルトのシステム UI、設定、ランチャーで、この要件を満たしています。デバイス実装は:

    • [C-1-5] 個々のアプリ パッケージごとにローカルにキャッシュされた Instant Apps を表示、削除するユーザー アフォーダンスを提供しなければなりません。
    • [C-1-6] Instant App がフォアグラウンドで実行されている間に閉じることができる永続的なユーザー通知を提供しなければなりません。このユーザー通知は、Instant Apps がインストールを必要としないことを含まなければならず、ユーザーを設定のアプリ情報画面に誘導するユーザー アフォーダンスを提供しなければなりません。ウェブ インテントを介して起動された Instant Apps の場合、アクションが Intent.ACTION_VIEW に設定され、「http」または「https」のスキームを持つインテントを使用して定義されていることから、追加のユーザー アフォーダンスでは、ユーザーが Instant App を起動できず、デバイスでブラウザを利用できるのであれば、設定済みのウェブブラウザで関連リンクを起動できるようにすべきです。
    • [C-1-7] デバイスで履歴機能が利用可能な場合、実行中の Instant Apps に履歴機能からアクセスできるようにしなければなりません。

  • [C-1-8] こちらの SDK に記載されているインテントのインテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードし、インテントを Instant Apps で表示しなければなりません。

3.16. コンパニオン デバイスのペア設定

Android では、コンパニオン デバイスのペア設定をサポートしてコンパニオン デバイスとの関連付けを効果的に管理できるようになっており、アプリでこの機能にアクセスするための CompanionDeviceManager API が提供されています。

コンパニオン デバイスのペア設定機能をサポートする場合、デバイス実装は:

  • [C-1-1] FEATURE_COMPANION_DEVICE_SETUP 機能フラグを宣言しなければなりません。
  • [C-1-2] android.companion パッケージの API が完全に実装されるようにしなければなりません。
  • [C-1-3] コンパニオン デバイスがあり動作可能であることをユーザーが選択 / 確認するユーザー アフォーダンスを提供しなければなりません。

3.17. 重いアプリ

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

  • [C-1-1] インストール済みのアプリで cantSaveState が指定されている場合、システムで一度に実行するのは 1 つだけにしなければなりません。ユーザーがそのようなアプリを明示的に終了せずに離れる場合（たとえば、システムにアクティブなアクティビティが残っていない状態で戻るボタンを押すのではなく、システムにアクティブなアクティビティを残したままホームボタンを押すことで離れる場合）、デバイス実装は、フォアグラウンド サービスなど、動作し続けることが想定されるサービスと同様に、そのアプリを RAM 内で優先しなければなりません。そのようなアプリがバックグラウンドにあっても、システムは引き続き、CPU やネットワーク アクセスの制限などの電源管理機能を適用できます。
  • [C-1-2] cantSaveState 属性で宣言された第 2 のアプリをユーザーが起動した後、通常の状態保存 / 復元メカニズムに加わらないアプリを選択する UI アフォーダンスを提供しなければなりません。
  • [C-1-3] CPU パフォーマンスの変更やスケジュール設定の優先順位の変更など、cantSaveState を指定するアプリに対して他のポリシー変更を適用してはなりません。

機能 FEATURE_CANT_SAVE_STATE を宣言しない場合、デバイス実装は:

  • [C-1-1] アプリによって設定された cantSaveState 属性を無視しなければならず、この属性に基づいてアプリの動作を変更してはなりません。

3.18. 連絡先

Android には、デバイスに保存された連絡先情報をアプリが管理できるようにする Contacts Provider API があります。通常、デバイスに直接入力された連絡先データはウェブサービスと同期されますが、データはデバイスにローカルに配置されるだけでも構いません。デバイスに保存されるだけの連絡先のことを、ローカルの連絡先といいます。

ACCOUNT_NAME 列と ACCOUNT_TYPE 列が、アカウントの対応する Account.name フィールドと Account.type フィールドに一致する場合、RawContacts は Account に関連付けられるか、保存されます。

デフォルト ローカル アカウント: デバイスにのみ保存される、AccountManager のアカウントに関連付けられていない未加工連絡先のアカウントであって、ACCOUNT_NAME 列と ACCOUNT_TYPE 列が null 値の場合に作成されるもの。

カスタム ローカル アカウント: デバイスにのみ保存される、AccountManager のアカウントに関連付けられていない未加工連絡先のアカウントであって、ACCOUNT_NAME 列と ACCOUNT_TYPE 列の少なくとも 1 つが非 null 値の場合に作成されるもの。

デバイス実装は:

  • [C-SR-1] カスタム ローカル アカウントを作成しないことが強く推奨されます。

デバイス実装がカスタム ローカル アカウントを使用する場合:

  • [C-1-1] カスタム ローカル アカウントの ACCOUNT_NAME が、ContactsContract.RawContacts.getLocalAccountName によって返さなければなりません。
  • [C-1-2] カスタム ローカル アカウントの ACCOUNT_TYPE が、ContactsContract.RawContacts.getLocalAccountType によって返さなければなりません。
  • [C-1-3] デフォルト ローカル アカウントでサードパーティ アプリによって挿入される（ACCOUNT_NAME と ACCOUNT_TYPE に null 値を設定することで挿入される）未加工連絡先は、カスタム ローカル アカウントに挿入されなければなりません。
  • [C-1-4] カスタム ローカル アカウントに挿入された未加工連絡先は、アカウントが追加または削除されたときに削除されてはなりません。
  • [C-1-5] カスタム ローカル アカウントに対して行われた削除操作では、CALLER\_IS\_SYNCADAPTER パラメータが false に設定されているか指定されていない場合であっても、未加工連絡先がすぐに削除されなければなりません（CALLER_IS_SYNCADAPTER パラメータが true に設定されている場合と同様に削除されなければなりません）。

4. アプリ パッケージの互換性

デバイス実装は:

  • [C-0-1] 公式の Android SDK に含まれる「aapt」ツールによって生成された Android「.apk」ファイルをインストールして実行できなければなりません。

    • 上記の要件が難しい場合もあるため、デバイス実装は、AOSP リファレンス実装のパッケージ管理システムを使用することが推奨されます。

  • [C-0-2] APK 署名スキーム v3.1、APK 署名スキーム v3、APK 署名スキーム v2、JAR 署名を使用した「.apk」ファイルの検証をサポートしなければなりません。

  • [C-0-3] .apk、Android マニフェスト、Dalvik バイトコード、RenderScript バイトコードのいずれかの形式を、他の互換デバイスでファイルのインストールと実行が正しく行われないような方法で拡張してはなりません。

  • [C-0-4] DELETE_PACKAGE 権限の SDK に記載されているとおり、パッケージの現在の「レコードのインストーラ」以外のアプリが、ユーザーの確認なしで通知せずにアプリをアンインストールできるようにしてはなりません。例外は、PACKAGE_NEEDS_VERIFICATION インテントを処理するシステム パッケージ検証アプリと、ACTION_MANAGE_STORAGE インテントを処理するストレージ管理アプリです。

  • [C-0-5] android.settings.MANAGE_UNKNOWN_APP_SOURCES インテントを処理するアクティビティがなければなりません。

  • [C-0-6] インストールをリクエストするアプリが次の要件をすべて満たす場合を除き、提供元不明のアプリ パッケージをインストールしてはなりません。

    • REQUEST_INSTALL_PACKAGES 権限を宣言するか、android:targetSdkVersion を 24 以下に設定しなければなりません。
    • ユーザーによって、提供元不明のアプリをインストールする権限が付与されていなければなりません。

  • 提供元不明のアプリをインストールする権限をアプリごとに付与する / 取り消すユーザー アフォーダンスを提供すべきですが、デバイス実装でユーザーにこの選択を許可しない場合、これを NoOps として実装し、startActivityForResult() について RESULT_CANCELED を返すことにしても構いません。ただし、そのような場合であっても、そうした選択が提示されない理由をユーザーに示すべきです。

  • [C-0-7] システム API PackageManager.setHarmfulAppWarning によって有害な可能性があるとマークされたアプリでアクティビティを起動する前に、同じシステム API PackageManager.setHarmfulAppWarning を通じて提供される警告文字列による警告ダイアログを表示しなければなりません。

  • 警告ダイアログで、アプリをアンインストールするか起動するかを選択するユーザー アフォーダンスを提供すべきです。

  • [C-0-8] こちらに記載されているとおり、増分ファイル システムのサポートを実装しなければなりません。

  • [C-0-9] APK 署名スキーム v4 と APK 署名スキーム v4.1 を使用した .apk ファイルの検証をサポートしなければなりません。

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

デバイス実装は:

  • [C-0-1] MediaCodecList で宣言された各コーデックすべてについて、セクション 5.1 で規定するメディア形式、エンコーダ、デコーダ、ファイル形式、コンテナ形式をサポートしなければなりません。
  • [C-0-2] MediaCodecList を介してサードパーティ アプリが利用できるエンコーダ、デコーダのサポートを宣言し、レポートしなければなりません。
  • [C-0-3] 適切にデコードできなければならず、エンコード可能なすべての形式をサードパーティ アプリが利用できるようにしなければなりません。これには、エンコーダが生成するすべてのビットストリームと、CamcorderProfile でレポートされるプロファイルが含まれます。

デバイス実装は:

  • コーデック遅延を最小限に抑えるべきです。つまり
    • 入力バッファを消費、保存すべきでなく、1 回処理されただけで入力バッファを返すべきではありません。
    • デコードされたバッファを、標準（例: SPS）で指定されているよりも長く保持すべきではありません。
    • エンコードされたバッファを、GOP 構造が必要とするよりも長く保持すべきではありません。

以下のセクションに記載されているコーデックはすべて、Android オープンソース プロジェクトの推奨 Android 実装でソフトウェア実装として提供されています。

Google もオープン ハンドセット アライアンスも、これらのコーデックにサードパーティの特許がないことを表明しているわけではないことにご注意ください。オープンソース ソフトウェアまたはシェアウェアを含め、このソースコードをハードウェアまたはソフトウェア製品で使用する場合は、このコードの実装に関連する特許権者からの特許ライセンスが必要になることがあります。

5.1. メディア コーデック

5.1.1. オーディオ エンコード

詳細については 5.1.3. オーディオ コーデックの詳細をご覧ください。

android.hardware.microphone を宣言する場合、デバイス実装は、次のオーディオ形式のエンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

オーディオ エンコーダはすべて、下記をサポートしなければなりません。

  • [C-3-1] android.media.MediaCodec API を介した PCM 16 ビット ネイティブ バイトオーダーのオーディオ フレーム。

5.1.2. オーディオ デコード

詳細については 5.1.3. オーディオ コーデックの詳細をご覧ください。

android.hardware.audio.output 機能のサポートを宣言する場合、デバイス実装は、次のオーディオ形式のデコードをサポートしなければなりません。

  • [C-1-1] MPEG-4 AAC プロファイル（AAC LC）
  • [C-1-2] MPEG-4 HE AAC プロファイル（AAC+）
  • [C-1-3] MPEG-4 HE AACv2 プロファイル（Enhanced AAC+）
  • [C-1-4] AAC ELD（Enhanced Low Delay AAC）
  • [C-1-11] xHE-AAC（USAC ベースライン プロファイルを含む ISO/IEC 23003-3 Extended HE AAC プロファイル、ISO/IEC 23003-4 Dynamic Range Control プロファイル）
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] 24 ビット、サンプルレート 192 kHz、8 チャンネルまでのハイレゾリューション オーディオ形式を含む、PCM/WAVE。なお、この要件はデコード向けに限られ、デバイスには再生フェーズ中のダウンサンプルとダウンミックスが許可されます。
  • [C-1-10] Opus

デバイス実装が、android.media.MediaCodec API のデフォルト AAC オーディオ デコーダを通じて PCM へのマルチチャンネル ストリーム（2 チャンネル以上）の AAC 入力バッファのデコードをサポートする場合、下記をサポートしなければなりません。

  • [C-2-1] デコードは、ダウンミックスせずに行わなければなりません（たとえば、5.0 AAC ストリームは 5 チャンネルの PCM にデコードされなければならず、5.1 AAC ストリームは 6 チャンネルの PCM にデコードされなければなりません）。
  • [C-2-2] ダイナミック レンジ メタデータは、ISO/IEC 14496-3 の「Dynamic Range Control（DRC）」と、オーディオ デコーダのダイナミック レンジ関連の動作を構成するための android.media.MediaFormat DRC キーで定義されているとおりでなければなりません。AAC DRC キーは KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL、KEY_AAC_ENCODED_TARGET_LEVEL であり、API 21 で導入されました。
  • [C-SR-1] 上記の要件 C-2-1 と C-2-2 を、すべての AAC オーディオ デコーダで満たすことが強く推奨されます。

USAC オーディオをデコードするとき、MPEG-D（ISO/IEC 23003-4）は:

  • [C-3-1] ラウドネスと DRC メタデータは、MPEG-D DRC Dynamic Range Control プロファイル レベル 1 に従って解釈し、適用しなければなりません。
  • [C-3-2] デコーダは、android.media.MediaFormat キー（KEY_AAC_DRC_TARGET_REFERENCE_LEVEL と KEY_AAC_DRC_EFFECT_TYPE）で設定した構成に従って動作しなければなりません。

MPEG-4 AAC、HE AAC、HE AACv2 プロファイルのデコーダは:

  • ISO/IEC 23003-4 Dynamic Range Control プロファイルを使用した、ラウドネスとダイナミック レンジ コントロールをサポートしても構いません。

ISO/IEC 23003-4 がサポートされている場合であって、デコードされたビットストリームに ISO/IEC 23003-4 と ISO/IEC 14496-3 の両方のメタデータが存在する場合:

  • ISO/IEC 23003-4 メタデータが優先されるものとします。

オーディオ デコーダはすべて、次の出力をサポートしなければなりません。

  • [C-6-1] android.media.MediaCodec API を介した PCM 16 ビット ネイティブ バイトオーダーのオーディオ フレーム。

デバイス実装が、android.media.MediaCodec API のデフォルト AAC オーディオ デコーダを通じて PCM へのマルチチャンネル ストリーム（2 チャンネル以上）の AAC 入力バッファのデコードをサポートする場合、下記をサポートしなければなりません。

  • [C-7-1] コンテンツをステレオにダウンミックスするか（値 2 を使用する場合）ネイティブ チャンネル数を使用して出力するか（その数以上の値を使用する場合）を制御するために、鍵 KEY_MAX_OUTPUT_CHANNEL_COUNT によるデコードを使用してアプリで設定できなければなりません。たとえば、値を 6 以上に設定すると、5.1 のコンテンツを供給する際に 6 つのチャンネルを出力するようにデコーダを設定できます。
  • [C-7-2] デコーダはデコード時に、android.media.AudioFormat 定数（例: CHANNEL_OUT_5POINT1）を使用して、KEY_CHANNEL_MASK 鍵での出力形式で使用されるチャンネル マスクをアドバタイズしなければなりません。

デバイス実装が、デフォルトの AAC オーディオ デコーダ以外のオーディオ デコーダをサポートし、圧縮されたマルチチャンネル コンテンツを供給する際にマルチチャンネル オーディオ（2 チャンネルを超えるオーディオ）を出力できる場合:

  • [C-SR-2] デコーダは、コンテンツをステレオにダウンミックスするか（値 2 を使用する場合）ネイティブ チャンネル数を使用して出力するか（その数以上の値を使用する場合）を制御するために、鍵 KEY_MAX_OUTPUT_CHANNEL_COUNT によるデコードを使用してアプリで設定できるようにすることを強く推奨します。たとえば、値を 6 以上に設定すると、5.1 のコンテンツを供給する際に 6 つのチャンネルを出力するようにデコーダを設定できます。
  • [C-SR-3] デコーダはデコード時に、android.media.AudioFormat 定数（例: CHANNEL_OUT_5POINT1）を使用して、KEY_CHANNEL_MASK 鍵での出力形式で使用されるチャンネル マスクをアドバタイズすることが強く推奨されます。

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

形式 / コーデック 詳細 サポートされるファイル形式 / コンテナ形式
MPEG-4 AAC プロファイル
（AAC LC）		 標準サンプリング レート 8～48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。
  • 3GPP（.3gp）
  • MPEG-4（.mp4、.m4a）
  • ADTS raw AAC（.aac、ADIF 非対応）
  • MPEG-TS（.ts、シーク不可、デコードのみ）
  • Matroska（.mkv、デコードのみ）
MPEG-4 HE AAC プロファイル（AAC+） 標準サンプリング レート 16～48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。
  • 3GPP（.3gp）
  • MPEG-4（.mp4、.m4a）
MPEG-4 HE AACv2
プロファイル（Enhanced AAC+）		 標準サンプリング レート 16～48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。
  • 3GPP（.3gp）
  • MPEG-4（.mp4、.m4a）
AAC-ELD（Enhanced Low Delay AAC） 標準サンプリング レート 16～48 kHz のモノラル / ステレオ コンテンツをサポート。
  • 3GPP（.3gp）
  • MPEG-4（.mp4、.m4a）
USAC 標準サンプリング レート 7.35～48 kHz のモノラル / ステレオ コンテンツをサポート。 MPEG-4（.mp4、.m4a）
AMR-NB 8 kHz でサンプリングされた 4.75～12.2 kbps 3GPP（.3gp）
AMR-WB 16 kHz でサンプリングされた、6.60 kbit/s～23.85 kbit/s の 9 種類のレート（AMR-WB、Adaptive Multi-Rate - Wideband Speech Codec で定義） 3GPP（.3gp）
FLAC エンコーダとデコーダの両方について: 少なくともモノラルモードとステレオモードをサポートしなければなりません。192 kHz までのサンプルレートをサポートしなければなりません。16 ビットと 24 ビットの解像度をサポートしなければなりません。FLAC 24 ビット オーディオ データ処理が浮動小数点オーディオ構成で利用できなければなりません。
  • FLAC（.flac）
  • MPEG-4（.mp4、.m4a、デコードのみ）
  • Matroska（.mkv、デコードのみ）
MP3 モノラル / ステレオの 8～320 Kbps 固定ビットレート（CBR）または可変ビットレート（VBR）
  • MP3（.mp3）
  • MPEG-4（.mp4、.m4a、デコードのみ）
  • Matroska（.mkv、デコードのみ）
MIDI MIDI タイプ 0 と 1。DLS バージョン 1 と 2。XMF と Mobile XMF。着信音形式 RTTTL/RTX、OTA、iMelody をサポート。
  • タイプ 0 と 1（.mid、.xmf、.mxmf）
  • RTTTL/RTX（.rtttl、.rtx）
  • iMelody（.imy）
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 のモノラル、ステレオのコンテンツをサポート。
  • Ogg（.ogg）
  • MPEG-4（.mp4、.m4a、デコードのみ）
  • Matroska（.mkv）
  • Webm（.webm）
PCM（WAVE） PCM コーデックは 16 ビットのリニア PCM と 16 ビット浮動小数点をサポートしなければなりません。WAVE エクストラクタは 16 ビット、24 ビット、32 ビットのリニア PCM と 32 ビット浮動小数点をサポートしなければなりません（最大レートはハードウェアの上限値）。サンプリング レートは 8 kHz から 192 kHz までをサポートしなければなりません。 WAVE（.wav）
Opus デコード: サンプリング レート 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 のモノラル、ステレオのコンテンツをサポート。
  • Ogg（.ogg）
  • MPEG-4（.mp4、.m4a、デコードのみ）
  • Matroska（.mkv）
  • Webm（.webm）

5.1.4. 画像のエンコード

詳細については、5.1.6. 画像コーデックの詳細をご覧ください。

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

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

新しい要件の開始

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

新しい要件の終了

メディアタイプ MIMETYPE_IMAGE_ANDROID_HEIC の android.media.MediaCodec を介して HEIC エンコードをサポートする場合、デバイス実装は:

  • [C-1-1] BITRATE_MODE_CQ ビットレート コントロール モード、HEVCProfileMainStill プロファイル、512 x 512 px フレームサイズをサポートするハードウェア アクセラレーテッド HEVC エンコーダ コーデックを提供しなければなりません。

5.1.5. 画像のデコード

詳細については、5.1.6. 画像コーデックの詳細をご覧ください。

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

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Raw
  • [C-0-7] AVIF（ベースライン プロファイル）

HEVC 動画デコードをサポートする場合、デバイス実装は: * [C-1-1] HEIF（HEIC）画像デコードをサポートしなければなりません。

高ビット深度形式（チャンネルあたり 9 ビット以上）をサポートする画像デコーダ

  • [C-2-1] アプリが、たとえば android.graphics.Bitmap の ARGB_8888 設定を介してリクエストする場合、8 ビット相当の形式の出力をサポートしなければなりません。

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）

MediaCodec API を通じて公開される画像エンコーダとデコーダ

  • [C-1-1] CodecCapabilities を通じて YUV420 8:8:8 フレキシブル カラー形式（COLOR_FormatYUV420Flexible）をサポートしなければなりません。

  • [C-SR-1] 入力サーフェス モードで RGB888 カラー形式をサポートすることが強く推奨されます。

  • [C-1-3] 少なくとも Planar または SemiPlanar いずれかの YUV420 8:8:8 カラー形式をサポートしなければなりません: COLOR_FormatYUV420PackedPlanar（COLOR_FormatYUV420Planar 相当）または COLOR_FormatYUV420PackedSemiPlanar（COLOR_FormatYUV420SemiPlanar 相当）。両方をサポートすることが強く推奨されます。

5.1.7. 動画コーデック

  • ウェブ動画ストリーミング サービスとビデオ会議サービスの品質を許容可能なものにするために、デバイス実装は、要件を満たすハードウェア VP8 コーデックを使用すべきです。

デバイス実装に動画デコーダまたはエンコーダが含まれる場合:

  • [C-1-1] 動画コーデックは、標準と設定で規定されているとおり、実現可能な最大の圧縮フレームと非圧縮フレームに対応する入出力バイトバッファ サイズをサポートしなければなりませんが、過剰に割り当ててはなりません。

  • [C-1-2] 動画エンコーダとデコーダは、CodecCapabilities を通じて YUV420 8:8:8 フレキシブル カラー形式（COLOR_FormatYUV420Flexible）をサポートしなければなりません。

  • [C-1-3] 動画エンコーダとデコーダは、少なくとも Planar または SemiPlanar いずれかの YUV420 8:8:8 カラー形式をサポートしなければなりません: COLOR_FormatYUV420PackedPlanar（COLOR_FormatYUV420Planar 相当）または COLOR_FormatYUV420PackedSemiPlanar（COLOR_FormatYUV420SemiPlanar 相当）。両方をサポートすることが強く推奨されます。

  • [C-SR-1] 動画エンコーダとデコーダは、ハードウェアに最適化された少なくとも Planar または SemiPlanar いずれかの YUV420 8:8:8 カラー形式をサポートすることが強く推奨されます（YV12、NV12、NV21、またはベンダーに最適化された同等の形式）。

  • [C-1-5] 高ビット深度形式（チャンネルあたり 9 ビット以上）をサポートする動画デコーダは、アプリがリクエストする場合、8 ビット相当の形式の出力をサポートしなければなりません。これは、android.media.MediaCodecInfo を介して YUV420 8:8:8 カラー形式をサポートすることで反映されなければなりません。

Display.HdrCapabilities を通じて HDR プロファイルのサポートをアドバタイズする場合、デバイス実装は:

  • [C-2-1] HDR 静的メタデータの解析と処理をサポートしなければなりません。

MediaCodecInfo.CodecCapabilities クラスの FEATURE_IntraRefresh を通じてイントラ更新のサポートをアドバタイズする場合、デバイス実装は:

  • [C-3-1] 更新周期 10～60 フレームをサポートし、設定した更新周期の 20% 以内で正確に動作しなければなりません。

アプリが KEY_COLOR_FORMAT 形式キーを使用して別の指定をする場合を除き、動画デコーダ実装は:

  • [C-4-1] サーフェス出力を使用して構成されている場合、デフォルトでハードウェア ディスプレイ用に最適化されたカラー形式にしなければなりません。
  • [C-4-2] サーフェス出力を使用しないように構成されている場合、デフォルトで CPU 読み込み用に最適化された YUV420 8:8:8 カラー形式にしなければなりません。

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.9. メディア コーデックのセキュリティ

デバイス実装は、下記のとおり、メディア コーデックのセキュリティ機能に確実に準拠しなければなりません。

Android は、クロス プラットフォームのマルチメディア アクセラレーション API である OMX と、低オーバーヘッド マルチメディア アクセラレーション API である Codec 2.0 をサポートしています。

マルチメディアをサポートする場合、デバイス実装は:

  • [C-1-1] Android オープンソース プロジェクトにあるように、OMX または Codec 2.0 API のいずれか（あるいは両方）を介してメディア コーデックのサポートを提供しなければならず、セキュリティ保護を無効化または回避してはなりません。具体的には、これはすべてのコーデックが OMX または Codec 2.0 API のいずれかを使用しなければならないということではなく、これらの API の少なくとも 1 つのサポートが利用可能でなければならず、利用可能な API のサポートは、存在するセキュリティ保護を含まなければならないということです。
  • [C-SR-1] Codec 2.0 API のサポートを含むことが強く推奨されます。

Codec 2.0 API をサポートしない場合、デバイス実装は:

  • [C-2-1] デバイスでサポートされているメディア形式とタイプ（エンコーダまたはデコーダ）ごとに、Android オープンソース プロジェクトの対応する OMX ソフトウェア コーデック（利用可能な場合）を含まなければなりません。
  • [C-2-2] 名前が「OMX.google」で始まるコーデックは、Android オープンソース プロジェクトのソースコードに基づいていなければなりません。
  • [C-SR-2] OMX ソフトウェア コーデックを、メモリマッパー以外のハードウェア ドライバにアクセスできないコーデック プロセスで実行することが強く推奨されます。

Codec 2.0 API をサポートする場合、デバイス実装は:

  • [C-3-1] デバイスでサポートされているメディア形式とタイプ（エンコーダまたはデコーダ）ごとに、Android オープンソース プロジェクトの対応する Codec 2.0 ソフトウェア コーデック（利用可能な場合）を含まなければなりません。
  • [C-3-2] Android オープンソース プロジェクトで提供されているように、Codec 2.0 ソフトウェア コーデックをソフトウェア コーデック プロセスに含めて、ソフトウェア コーデックへのアクセス権付与をより狭い範囲で行えるようにしなければなりません。
  • [C-3-3] 名前が「c2.android.」で始まるコーデックは、Android オープンソース プロジェクトのソースコードに基づいていなければなりません。

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

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

  • [C-1-1] MediaCodecInfo API を介して、メディア コーデックの正しい特性値を返さなければなりません。

具体的には、次のとおりです。

  • [C-1-2] 名前が「OMX.」で始まるコーデックは、OMX API を使用し、OMX IL 命名ガイドラインに沿った名前でなければなりません。
  • [C-1-3] 名前が「c2.」で始まるコーデックは、Codec 2.0 API を使用し、Android の Codec 2.0 命名ガイドラインに沿った名前でなければなりません。
  • [C-1-4] 名前が「OMX.google.」または「c2.android.」で始まるコーデックは、ベンダーまたはハードウェア アクセラレーションによるものとされてはなりません。
  • [C-1-5] メモリ アロケータとメモリマッパー以外のハードウェア ドライバにアクセスできるコーデック プロセス（ベンダーまたはシステム）で実行されるコーデックは、ソフトウェアのみとされてはなりません。
  • [C-1-6] Android オープンソース プロジェクトに存在しないか、そのソースコードに基づいていないコーデックは、ベンダーによるものとされなければなりません。
  • [C-1-7] ハードウェア アクセラレーションを利用するコーデックは、ハードウェア アクセラレーションによるものとされなければなりません。
  • [C-1-8] コーデック名は、誤解を招きやすいものであってはなりません。たとえば、名前が「decoders」のコーデックはデコードをサポートしなければならず、名前が「encoders」のコーデックはエンコードをサポートしなければなりません。名前にメディア形式を含むコーデックは、その形式をサポートしなければなりません。

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

  • [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）
  • [C-2-2] ハードウェア アクセラレーションによるものとされた動画コーデックは、パフォーマンス ポイント情報を公開しなければなりません。これらのコーデックは、サポート対象の別の標準パフォーマンス ポイントでカバーされている場合を除き、サポート対象のすべての標準パフォーマンス ポイント（PerformancePoint API に記載）をそれぞれリストしなければなりません。
  • さらに、リストされた標準的なもの以外の持続的な動画パフォーマンスをサポートする場合、拡張パフォーマンス ポイントを公開すべきです。

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% 以上超えないことが強く推奨されます。

新しい要件の終了

対角長が 2.5 インチ以上の埋め込みスクリーン ディスプレイか、動画出力ポートが含まれる場合、または android.hardware.camera.any 機能フラグを介してカメラのサポートを宣言する場合、デバイス実装は:

  • [C-1-1] VP8 または H.264 動画エンコーダのいずれかをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
  • VP8 と H.264 の両方の動画エンコーダをサポートし、サードパーティ アプリで利用できるようにすべきです。

H.264、VP8、VP9、HEVC 動画エンコーダのいずれかをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

  • [C-2-1] 動的に設定可能なビットレートをサポートしなければなりません。
  • 可変フレームレートをサポートすべきです。ここで動画エンコーダは、入力バッファのタイムスタンプに基づいて瞬間的なフレーム持続時間を求め、そのフレーム持続時間に基づいてビットバケットを割り当てるべきです。

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

  • サポート対象のエンコーダの動的に設定可能なビットレートをサポートすべきです。

デバイス実装がハードウェア アクセラレーションの動画エンコーダまたは画像エンコーダを提供し、android.camera API を介して公開される接続されているかプラグイン可能なハードウェア カメラを 1 つ以上サポートする場合:

  • [C-4-1] ハードウェア アクセラレーションの動画エンコーダと画像エンコーダはすべて、ハードウェア カメラからのフレームのエンコードをサポートしなければなりません。
  • すべての動画エンコーダまたは画像エンコーダを通じて、ハードウェア カメラからのフレームのエンコードをサポートすべきです。

HDR エンコードを提供する場合、デバイス実装は:

  • [C-SR-1] HDR 形式から SDR 形式に変換するシームレスなコード変換 API のプラグインを提供することが強く推奨されます。

5.2.1. H.263

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

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

5.2.2. H.264

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

  • [C-1-1] ベースライン プロファイル レベル 3 をサポートしなければなりません。ただし、ASO（Arbitrary Slice Ordering）、FMO（Flexible Macroblock Ordering）、RS（Redundant Slices）のサポートは任意です。さらに、他の Android デバイスとの互換性を維持するために、エンコーダでベースライン プロファイルに ASO、FMO、RS を使用しないことが推奨されます。
  • [C-1-2] 下表の SD（標準画質）動画エンコード プロファイルをサポートしなければなりません。
  • メイン プロファイル レベル 4 をサポートすべきです。
  • 下表に示すとおり、HD（高画質）動画エンコード プロファイルをサポートすべきです。

メディア API を通じて解像度が 720p または 1080p である動画の H.264 エンコードのサポートをレポートする場合、デバイス実装は:

  • [C-2-1] 下表のエンコード プロファイルをサポートしなければなりません。
SD（低画質） SD（高画質） HD 720p HD 1080p
動画の解像度 320 x 240 px 720 x 480 px 1,280 x 720 px 1,920 x 1,080 px
動画のフレームレート 20 fps 30 fps 30 fps 30 fps
動画のビットレート 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

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

  • [C-1-1] SD 動画エンコード プロファイルをサポートしなければなりません。
  • 次の HD（高画質）動画エンコード プロファイルをサポートすべきです。
  • [C-1-2] Matroska WebM ファイルの書き込みをサポートしなければなりません。
  • ウェブ動画配信サービスとビデオ会議サービスの質を許容可能なものにするために、WebM プロジェクトの RTC ハードウェア コーディング要件を満たすハードウェア VP8 コーデックを提供すべきです。

メディア API を通じて解像度が 720p または 1080p である動画の VP8 エンコードのサポートをレポートする場合、デバイス実装は:

  • [C-2-1] 下表のエンコード プロファイルをサポートしなければなりません。
SD（低画質） SD（高画質） HD 720p HD 1080p
動画の解像度 320 x 180 ピクセル 640 x 360 ピクセル 1,280 x 720 ピクセル 1,920 x 1,080 px
動画のフレームレート 30 fps 30 fps 30 fps 30 fps
動画のビットレート 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

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

  • [C-1-2] プロファイル 0 レベル 3 をサポートしなければなりません。
  • [C-1-1] Matroska WebM ファイルの書き込みをサポートしなければなりません。
  • [C-1-3] CodecPrivate データを生成しなければなりません。
  • 下表に示すとおり、HD デコード プロファイルをサポートすべきです。
  • [C-SR-1] ハードウェア エンコーダがある場合、下表に示すとおり、HD デコード プロファイルをサポートすることが強く推奨されます。
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
動画のビットレート 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

メディア API を通じてプロファイル 2 またはプロファイル 3 をサポートすることを主張する場合、デバイス実装は:

  • 12 ビット形式のサポートは任意です。

5.2.5. H.265

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

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

新しい要件の開始

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. 動画のデコード

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

  • [C-1-1] VP8、VP9、H.264、H.265 のすべてのコーデックについて、デバイスで各コーデックがサポートする最大解像度まで、同じストリーム内で標準の Android API を通じて、動的な動画解像度とフレームレートの切り替えをサポートしなければなりません。

5.3.1. MPEG-2

MPEG-2 デコーダをサポートする場合、デバイス実装は:

  • [C-1-1] メイン プロファイル ハイレベルをサポートしなければなりません。

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.3. MPEG-4

MPEG-4 デコーダを備える場合、デバイス実装は:

  • [C-1-1] シンプル プロファイル レベル 3 をサポートしなければなりません。

5.3.4. H.264

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

  • [C-1-1] メイン プロファイル レベル 3.1 とベースライン プロファイルをサポートしなければなりません。ASO（Arbitrary Slice Ordering）、FMO（Flexible Macroblock Ordering）、RS（Redundant Slices）のサポートは任意です。
  • [C-1-2] 下表に記載されている SD（標準画質）プロファイルで動画をデコードでき、ベースライン プロファイルとメイン プロファイル レベル 3.1（720p30 を含む）でエンコードできなければなりません。
  • 下表に示すとおり、HD（高画質）プロファイルで動画をデコードできるべきです。

Display.getSupportedModes() メソッドでレポートされる高さが動画の解像度以上である場合、デバイス実装は:

  • [C-2-1] 下表の HD 720p 動画デコード プロファイルをサポートしなければなりません。
  • [C-2-2] 下表の HD 1080p 動画デコード プロファイルをサポートしなければなりません。
SD（低画質） SD（高画質） HD 720p HD 1080p
動画の解像度 320 x 240 px 720 x 480 px 1,280 x 720 px 1,920 x 1,080 px
動画のフレームレート 30 fps 30 fps 60 fps 30 fps（60 fpsテレビ）
動画のビットレート 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265（HEVC）

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

  • [C-1-1] 下表に示すとおり、メイン プロファイル レベル 3 メインティアと SD 動画エンコード プロファイルをサポートしなければなりません。
  • 下表に示すとおり、HD デコード プロファイルをサポートすべきです。
  • [C-1-2] ハードウェア デコーダがある場合、下表に示すとおり、HD デコード プロファイルをサポートしなければなりません。

Display.getSupportedModes() メソッドによってレポートされる高さが動画の解像度以上である場合:

  • [C-2-1] デバイス実装は、720、1080、UHD プロファイルの H.265 または VP9 デコードのうち少なくとも 1 つをサポートしなければなりません。
SD（低画質） SD（高画質） HD 720p HD 1080p UHD
動画の解像度 352 x 288 px 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 / 60 fps（60 fpsH.265 ハードウェア デコードを備えたテレビ） 60 fps
動画のビットレート 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

  • [C-3-1] デバイス実装は、必要な HDR メタデータをアプリから受け入れ、必要な HDR メタデータをビットストリームやコンテナから抽出、出力することをサポートしなければなりません。
  • [C-3-2] デバイス実装は、HDR コンテンツをデバイスの画面または標準の動画出力ポート（例: HDMI）に適切に表示しなければなりません。

5.3.6. VP8

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

  • [C-1-1] 下表の SD デコード プロファイルをサポートしなければなりません。
  • 要件を満たすハードウェア VP8 コーデックを使用すべきです。
  • 下表の HD デコード プロファイルをサポートすべきです。

Display.getSupportedModes() メソッドによってレポートされる高さが動画の解像度以上である場合:

  • [C-2-1] デバイス実装は下表の 720p プロファイルをサポートしなければなりません。
  • [C-2-2] デバイス実装は下表の 1080p プロファイルをサポートしなければなりません。
SD（低画質） SD（高画質） HD 720p HD 1080p
動画の解像度 320 x 180 ピクセル 640 x 360 ピクセル 1,280 x 720 ピクセル 1,920 x 1,080 px
動画のフレームレート 30 fps 30 fps 30 fps（60 fpsテレビ） 30（60 fpsテレビ）
動画のビットレート 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

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

  • [C-1-1] 下表に示すとおり SD 動画デコード プロファイルをサポートしなければなりません。
  • 下表に示すとおり、HD デコード プロファイルをサポートすべきです。

デバイス実装が VP9 コーデックとハードウェア デコーダをサポートする場合:

  • [C-2-1] 下表に示すとおり、HD デコード プロファイルをサポートしなければなりません。

Display.getSupportedModes() メソッドによってレポートされる高さが動画の解像度以上である場合:

  • [C-3-1] デバイス実装は、720、1080、UHD プロファイルの VP9 または H.265 デコードのうち少なくとも 1 つをサポートしなければなりません。
SD（低画質） SD（高画質） HD 720p HD 1080p UHD
動画の解像度 320 x 180 ピクセル 640 x 360 ピクセル 1,280 x 720 ピクセル 1,920 x 1,080 px 3,840 x 2,160 px
動画のフレームレート 30 fps 30 fps 30 fps 30 fps（60 fpsVP9 ハードウェア デコードを備えたテレビ） 60 fps
動画のビットレート 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

デバイス実装が CodecProfileLevel メディア API を通じて VP9Profile2 または VP9Profile3 のサポートを主張する場合:

  • 12 ビット形式のサポートは任意です。

デバイス実装がメディア API を通じて HDR プロファイル（VP9Profile2HDR、VP9Profile2HDR10Plus、VP9Profile3HDR、VP9Profile3HDR10Plus）のサポートを主張する場合:

  • [C-4-1] デバイス実装は、必要な HDR メタデータ（すべての HDR プロファイルで KEY_HDR_STATIC_INFO、HDR10Plus プロファイルで 'KEY_HDR10_PLUS_INFO'）をアプリから受け入れなければなりません。また、必要な HDR メタデータをビットストリームやコンテナから抽出、出力することをサポートしなければなりません。
  • [C-4-2] デバイス実装は、HDR コンテンツをデバイスの画面または標準の動画出力ポート（例: HDMI）に適切に表示しなければなりません。

5.3.8. ドルビー ビジョン

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

  • [C-1-1] ドルビー ビジョン対応エクストラクタを提供しなければなりません。
  • [C-1-2] ドルビー ビジョン コンテンツをデバイスの画面または標準の動画出力ポート（例: HDMI）に適切に表示しなければなりません。
  • [C-1-3] 下位互換性のあるベースレイヤ（存在する場合）のトラック ID を、結合したドルビー ビジョンレイヤのトラック ID と同じに設定しなければなりません。

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. 録音

このセクションで概説している一部の要件は、Android 4.3 以降「すべき」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。既存と新規の Android デバイスは、「すべき」として記載されている要件を満たすことが強く推奨されます。満たさなかった場合、今後のバージョンにアップグレードした際に、Android の互換性が得られなくなります。

5.4.1. 未加工オーディオのキャプチャとマイク情報

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

  • [C-1-1] 正常にオープンされた AudioRecord または AAudio のすべての入力ストリームについて、未加工オーディオ コンテンツをキャプチャできるようにしなければなりません。少なくとも、次の特性をサポートしなければなりません。

  • 次の特性を持つ未加工オーディオ コンテンツをキャプチャできるようにすべきです。

    • 形式: リニア PCM、16 ビットと 24 ビット
    • サンプリング レート: 8,000、11,025、16,000、22,050、24,000、32,000、44,100、48,000 Hz
    • チャンネル: デバイスのマイクと同じ数のチャンネル

  • [C-1-2] アップサンプリングせずに上記のサンプルレートでキャプチャしなければなりません。

  • [C-1-3] 上記のサンプルレートがダウンサンプリングでキャプチャされる場合、適切なアンチエイリアス フィルタを含まなければなりません。

  • 未加工オーディオ コンテンツを、AM ラジオと DVD の品質（つまり下記の特性）でキャプチャできるようにすべきです。

    • 形式: リニア PCM、16 ビット
    • サンプリング レート: 22,050、48,000 Hz
    • チャンネル: ステレオ

  • [C-1-4] MediaRecorder.AudioSources DEFAULT、MIC、CAMCORDER、VOICE_RECOGNITION、VOICE_COMMUNICATION、UNPROCESSED、または VOICE_PERFORMANCE を使用するアクティブな AudioRecord については、MicrophoneInfo API を尊重し、AudioManager.getMicrophones() API を介してサードパーティ アプリがアクセスできるデバイス上の利用可能なマイクの情報を適切に入力しなければなりません。未加工オーディオ コンテンツを AM ラジオと DVD の品質でキャプチャできるようにする場合、デバイス実装は:

  • [C-2-1] 16,000:22,050 または 44,100:48,000 を超える比率でアップサンプリングせずにキャプチャしなければなりません。

  • [C-2-2] アップサンプリングまたはダウンサンプリングのための適切なアンチエイリアス フィルタを含まなければなりません。

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

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

  • [C-1-1] 44,100 と 48,000 いずれかのサンプリング レートで android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音源をキャプチャしなければなりません。
  • [C-1-2] AudioSource.VOICE_RECOGNITION 音源からのオーディオ ストリームを録音するとき、ノイズ リダクション オーディオ処理をデフォルトで無効にしなければなりません。

  • [C-1-3] AudioSource.VOICE_RECOGNITION 音源からのオーディオ ストリームを録音するとき、自動ゲイン コントロールをデフォルトで無効にしなければなりません。

  • 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲でほぼ平坦な振幅周波数特性を示すべきです（具体的には ±3 dB、100 Hz～4,000 Hz）。

  • [C-SR-1] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して低い周波数範囲の振幅レベルを示すことが強く推奨されます（具体的には ±20 dB、30 Hz～100 Hz）。

  • [C-SR-2] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して高い周波数範囲の振幅レベルを示すことが強く推奨されます（具体的には ±30 dB、4,000 Hz～22 kHz）。

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

  • マイクでの 90 dB SPL から少なくとも 30 dB（-18 dB～+12 dB）の範囲で PCM 振幅レベルが入力 SPL の変化を線形的にトラックするように、音声認識のオーディオ ストリームを録音すべきです。

  • 全高調波歪み（THD）がマイクでの SPL 入力レベル 90 dB で 1 kHz に対して 1% 未満になるように、音声認識のオーディオ ストリームを録音すべきです。

android.hardware.microphone と、音声認識用に調整したノイズ キャンセレーション（リダクション）技術を宣言する場合、デバイス実装は:

  • [C-2-1] このオーディオ エフェクトを android.media.audiofx.NoiseSuppressor API で制御できるようにしなければなりません。
  • [C-2-2] AudioEffect.Descriptor.uuid フィールドを介して各ノイズ キャンセレーション技術実装を一意に識別しなければなりません。

5.4.3. 再生のリルート用のキャプチャ

android.media.MediaRecorder.AudioSource クラスには REMOTE_SUBMIX 音源が含まれています。

android.hardware.audio.output と android.hardware.microphone を両方とも宣言する場合、デバイス実装は:

  • [C-1-1] REMOTE_SUBMIX 音源を適切に実装して、アプリが android.media.AudioRecord API を使用してこの音源から録音するとき、下記を除くすべてのオーディオ ストリームのミックスをキャプチャするようにしなければなりません。

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. 音響エコー キャンセラ

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

  • AudioSource.VOICE_COMMUNICATION を使用してキャプチャするときにキャプチャパスに適用される、音声通信用に調整された音響エコー キャンセラ（AEC）技術を実装すべきです。

AudioSource.VOICE_COMMUNICATION が選択されたときにキャプチャ オーディオパスに挿入される音響エコー キャンセラを提供する場合、デバイス実装は:

5.4.5. 同時キャプチャ

android.hardware.microphone を宣言する場合、デバイス実装は、こちらのドキュメントに記載されているとおり同時キャプチャを実装しなければなりません。具体的には次のとおりです。

  • [C-1-1] AudioSource.VOICE_RECOGNITION でキャプチャするユーザー補助サービスと、任意の AudioSource でキャプチャする少なくとも 1 つのアプリから、マイクに同時アクセスできるようにしなければなりません。
  • [C-1-2] アシスタントのロールを持つプリインストール アプリと、任意の AudioSource（AudioSource.VOICE_COMMUNICATION または AudioSource.CAMCORDER を除く）でキャプチャする少なくとも 1 つのアプリから、マイクに同時アクセスできるようにしなければなりません。
  • [C-1-3] アプリが AudioSource.VOICE_COMMUNICATION または AudioSource.CAMCORDER でキャプチャしている間、ユーザー補助サービスを除き、他のアプリのオーディオ キャプチャを消音しなければなりません。ただし、アプリが AudioSource.VOICE_COMMUNICATION を介してキャプチャしているときは、別のアプリ（権限 CAPTURE_AUDIO_OUTPUT を付与されたプリインストールの特権アプリ）で音声通話をキャプチャできます。
  • [C-1-4] 複数のアプリが同時にキャプチャしていて、どちらのアプリも UI が最上位にない場合、最後にキャプチャを開始したアプリがオーディオを受信します。

5.5. オーディオの再生

Android には、セクション 7.8.2 で規定されているとおり、アプリがオーディオ出力周辺機器を通じてオーディオを再生できるようにするサポートが含まれています。

5.5.1. 未加工オーディオの再生

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

  • [C-1-1] 次の特性を持つ未加工オーディオ コンテンツを再生できるようにしなければなりません。

    • 音源形式: リニア PCM、16 ビット、8 ビット、浮動小数点
    • チャンネル: モノラル、ステレオ、最大 8 チャンネルの有効なマルチチャンネル構成
    • サンプリング レート（Hz）:
      • 上のチャンネル構成で 8,000、11,025、16,000、22,050、24,000、32,000、44,100、48,000
      • モノラルとステレオで 96,000

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

Android は、デバイス実装にオーディオ エフェクト用の API を提供します。

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

  • [C-1-1] AudioEffect のサブクラス Equalizer と LoudnessEnhancer を通じて制御できる EFFECT_TYPE_EQUALIZER 実装と EFFECT_TYPE_LOUDNESS_ENHANCER 実装をサポートしなければなりません。
  • [C-1-2] Visualizer クラスを通じて制御できるビジュアライザ API 実装をサポートしなければなりません。
  • [C-1-3] AudioEffect のサブクラス DynamicsProcessing を通じて制御できる EFFECT_TYPE_DYNAMICS_PROCESSING 実装をサポートしなければなりません。

新しい要件の開始

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

新しい要件の終了

  • AudioEffect のサブクラス BassBoost、EnvironmentalReverb、PresetReverb、Virtualizer を通じて制御できる EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB、EFFECT_TYPE_VIRTUALIZER 実装をサポートすべきです。
  • [C-SR-1] 浮動小数点とマルチチャンネルのエフェクトをサポートすることが強く推奨されます。

5.5.3. 出力音量

自動車デバイス実装は:

  • AudioAttributes で定義されているコンテンツ タイプまたは用途と、android.car.CarAudioManager で公開で定義されているカーオーディオ用途を使用して、音量をオーディオ ストリームごとに調整できるようにすべきです。

5.5.4. オーディオ オフロード

オーディオ オフロード再生をサポートする場合、デバイス実装は:

  • [C-SR-1] AudioTrack gapless API と MediaPlayer のメディア コンテナで指定されている場合、再生されるギャップレス オーディオ コンテンツを、同じ形式の 2 つのクリップ間でトリミングすることが強く推奨されます。

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

オーディオ レイテンシとは、オーディオ信号がシステムを通過する際に発生する遅延時間のことです。アプリのクラスの多くで、リアルタイムのサウンド エフェクトを実現するには、レイテンシが短くなっている必要があります。

このセクションでは、次の定義を使用します。

  • 出力レイテンシ。アプリが PCM 符号化データを書き込んでから、対応するサウンドがデバイス上のトランスデューサで環境に提供されるか、信号がポートを介してデバイスから出て外部で確認されるまでの間隔。
  • コールド出力レイテンシ。リクエストの前にオーディオ出力システムがアイドル状態になり、電源がオフになった場合の、出力ストリームの開始からタイムスタンプに基づく最初のフレームの表示時間までの時間。
  • 連続出力レイテンシ。デバイスがオーディオを再生した後の、後続フレームの出力レイテンシ。
  • 入力レイテンシ。サウンドが環境によってデバイス上のトランスデューサでデバイスに提供されるか、信号がポートを介してデバイスに入ってから、PCM 符号化データの対応するフレームをアプリが読み取るまでの間隔。
  • 欠損入力。使用または利用できない、入力信号の最初の部分。
  • コールド入力レイテンシ。リクエストの前にオーディオ入力システムがアイドル状態になり、電源がオフになった場合の、ストリームの開始から最初の有効なフレームを受信するまでの時間。

  • 連続入力レイテンシ。デバイスがオーディオをキャプチャしている間の、後続フレームの入力レイテンシ。

  • 連続ラウンドトリップ レイテンシ。連続入力レイテンシ、連続出力レイテンシ、1 バッファ期間の合計。バッファ期間により、アプリが信号を処理するための時間と、アプリが入出力ストリーム間の位相差を緩和するための時間を確保できます。

  • OpenSL ES PCM バッファキュー API。Android NDK 内にある、PCM 関連の OpenSL ES API のセット。

  • AAudio ネイティブ オーディオ API。Android NDK 内にある、AAudio API のセット。

  • タイムスタンプ。ストリーム内の相対フレーム位置と、そのフレームが関連エンドポイントのオーディオ処理パイプラインに出入りする推定時間からなるペア。AudioTimestamp もご覧ください。

  • グリッチ。オーディオ信号の一時的な中断または不正なサンプル値。通常は、出力のバッファ アンダーラン、入力のバッファ オーバーラン、他のデジタルまたはアナログノイズ発生源によって発生します。

  • 平均絶対偏差。一連の値の平均からの偏差の絶対値の平均。

  • タップツートーン レイテンシ。画面がタップされてから、そのタップの結果として生成された音がスピーカーから聞こえるまでの時間。

android.hardware.audio.output を宣言する場合、デバイス実装は、次の要件を満たすか上回らなければなりません。

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

  • [C-1-2] コールド出力レイテンシが 500 ミリ秒以下。

  • [C-1-3] AAudioStreamBuilder_openStream() を使用して出力ストリームを開始するのに要する時間が 1,000 ミリ秒未満でなければなりません。

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

  • [C-SR-1] スピーカー データパスでコールド出力レイテンシが 100 ミリ秒以下。
  • [C-SR-2] タップツートーン レイテンシが 80 ミリ秒以下。

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

新しい要件の開始

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

新しい要件の終了

上記の要件を満たす場合、初期キャリブレーションの後、AAudio ネイティブ オーディオ API を使用しているとき、少なくとも 1 つのサポート対象オーディオ出力デバイスでの連続出力レイテンシとコールド出力レイテンシについて、デバイス実装は:

AAudio ネイティブ オーディオ API を介して低レイテンシ オーディオの要件を満たさない場合、デバイス実装は:

  • [C-2-1] 低レイテンシ オーディオのサポートをレポートしてはなりません。

android.hardware.microphone が含まれる場合、デバイス実装は下記の入力オーディオの要件を満たさなければなりません。

  • [C-3-1] AudioRecord.getTimestamp または AAudioStream_getTimestamp が返す入力タイムスタンプの誤差を +/- 2 ms に制限する。ここでいう誤差とは、正しい値からのずれのことです。
  • [C-3-2] コールド入力レイテンシが 500 ミリ秒以下。
  • [C-3-3] AAudioStreamBuilder_openStream() を使用して入力ストリームを開くために要する時間が 1,000 ミリ秒未満でなければなりません。

android.hardware.microphone が含まれる場合、デバイス実装は下記の入力オーディオの要件を満たすことが強く推奨されます。

  • [C-SR-8] マイク データパスでコールド入力レイテンシが 100 ミリ秒以下。

  • [C-SR-11] AudioRecord.getTimestamp または AAudioStream_getTimestamp が返す入力タイムスタンプの誤差を +/- 1 ms に制限する。

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

  • [C-SR-12] 少なくとも 1 つのサポート対象パスで、5 回測定して平均連続ラウンドトリップ レイテンシが 50 ミリ秒以下、平均絶対偏差が 10 ミリ秒未満であることが強く推奨されます。

5.7. ネットワーク プロトコル

デバイス実装は、Android SDK ドキュメントで規定されているとおり、オーディオと動画を再生するためにメディア ネットワーク プロトコルをサポートしなければなりません。

サポートするためにデバイス実装が必要となるコーデックとコンテナ形式ごとに、デバイス実装は:

  • [C-1-1] HTTP と HTTPS でそのコーデックまたはコンテナをサポートしなければなりません。

  • [C-1-2] HTTP Live Streaming ドラフト プロトコル バージョン 7 で、下表「メディア セグメント形式」に示す対応するメディア セグメント形式をサポートしなければなりません。

  • [C-1-3] 下表「RTSP」に示す対応する RTSP ペイロード形式をサポートしなければなりません。例外については、セクション 5.1 の表の脚注をご覧ください。

メディア セグメント形式

セグメント形式 参照 必要なコーデックのサポート
MPEG-2 トランスポート ストリーム ISO 13818 動画コーデック:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
H264 AVC、MPEG2-4 SP、MPEG-2 の詳細についてはセクション 5.1.8 をご覧ください。

オーディオ コーデック:

  • 先進的音響符号化
AAC とそのバリアントの詳細についてはセクション 5.1.3 をご覧ください。
ADTS フレーム処理と ID3 タグを伴う AAC ISO 13818-7 AAC とそのバリアントの詳細についてはセクション 5.1.1 をご覧ください
WebVTT WebVTT

RTSP（RTP、SDP）

プロファイル名 参照 必要なコーデックのサポート
H264 AVC RFC 6184 H264 AVC の詳細についてはセクション 5.1.8 をご覧ください
MP4A-LATM RFC 6416 AAC とそのバリアントの詳細についてはセクション 5.1.3 をご覧ください
H263-1998 RFC 3551
RFC 4629
RFC 2190 		H263 の詳細についてはセクション 5.1.8 をご覧ください
H263-2000 RFC 4629 H263 の詳細についてはセクション 5.1.8 をご覧ください
AMR RFC 4867 AMR-NB の詳細についてはセクション 5.1.3 をご覧ください
AMR-WB RFC 4867 AMR-WB の詳細についてはセクション 5.1.3 をご覧ください
MP4V-ES RFC 6416 MPEG-4 SP の詳細についてはセクション 5.1.8 をご覧ください
mpeg4-generic RFC 3640 AAC とそのバリアントの詳細についてはセクション 5.1.3 をご覧ください
MP2T RFC 2250 詳細については HTTP Live Streaming の下の MPEG-2 トランスポート ストリームをご覧ください

5.8. セキュア メディア

セキュア動画出力をサポートし、セキュア サーフェスをサポートできる場合、デバイス実装は:

  • [C-1-1] Display.FLAG_SECURE のサポートを宣言しなければなりません。

Display.FLAG_SECURE のサポートを宣言し、ワイヤレス ディスプレイ プロトコルをサポートする場合、デバイス実装は:

  • [C-2-1] Miracast のようなワイヤレス プロトコルを通じて接続されたディスプレイについて、HDCP 2.x 以降のような暗号強度の高いメカニズムによって、リンクをセキュアにしなければなりません。

Display.FLAG_SECURE のサポートを宣言し、有線外部ディスプレイをサポートする場合、デバイス実装は:

  • [C-3-1] ユーザーがアクセス可能な有線ポートを介して接続されたすべての外部ディスプレイについて、HDCP 1.2 以降をサポートしなければなりません。

5.9. 電子楽器デジタル インターフェース（MIDI）

android.content.pm.PackageManager クラスを介して機能 android.software.midi のサポートをレポートする場合、デバイス実装は:

  • [C-1-1] 一般的な非 MIDI 接続を提供するすべての MIDI 対応ハードウェア トランスポートで MIDI をサポートしなければなりません。ここでいうトランスポートは次のとおりです。

  • [C-1-2] アプリ間 MIDI ソフトウェア トランスポート（仮想 MIDI デバイス）をサポートしなければなりません。

  • [C-1-3] libamidi.so（ネイティブ MIDI サポート）を含まなければなりません。

  • USB ペリフェラル モードの MIDI をサポートすべきです（セクション 7.7）。

5.10. プロフェッショナル オーディオ

android.content.pm.PackageManager クラスを介して機能 android.hardware.audio.pro のサポートをレポートする場合、デバイス実装は:

  • [C-1-1] 機能 android.hardware.audio.low_latency のサポートをレポートしなければなりません。
  • [C-1-2] セクション 5.6 オーディオ レイテンシで規定しているとおり、少なくとも 1 つのサポート対象パスで連続ラウンドトリップ オーディオ レイテンシが 25 ミリ秒以下でなければなりません。
  • [C-1-3] USB ホストモードと USB ペリフェラル モードをサポートする USB ポートを含まなければなりません。
  • [C-1-4] 機能 android.software.midi のサポートをレポートしなければなりません。
  • [C-1-5] AAudio ネイティブ オーディオ API と AAUDIO_PERFORMANCE_MODE_LOW_LATENCY を使用して、レイテンシと USB オーディオの要件を満たさなければなりません。
  • [C-1-6] コールド出力レイテンシが 200 ミリ秒以下でなければなりません。
  • [C-1-7] コールド入力レイテンシが 200 ミリ秒以下でなければなりません。

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

  • [C-SR-1] セクション 5.6 オーディオ レイテンシで規定されているとおり、スピーカーからマイクのパスで、5 回測定してレイテンシが 20 ミリ秒以下、平均絶対偏差 5 ミリ秒未満を満たすことが強く推奨されます。

  • [C-SR-2] MMAP パスで、AAudio ネイティブ オーディオ API を使用して、連続ラウンドトリップ オーディオ レイテンシ、コールド入力レイテンシ、コールド出力レイテンシの Pro Audio 要件と、USB オーディオ要件を満たすことが強く推奨されます。

  • [C-SR-3] オーディオがアクティブで CPU 負荷が変動していても、一貫した CPU パフォーマンス レベルを提供することが強く推奨されます。これは、Android アプリ SynthMark を使用してテストすべきです。SynthMark は、システム パフォーマンスを測定するシミュレート オーディオ フレームワークで動作する、ソフトウェア シンセサイザーを使用します。ベンチマークの説明については、SynthMark のドキュメントをご覧ください。SynthMark アプリは「自動テスト」オプションを使用して実行し、次の結果を得る必要があります。

    • voicemark.90 >= 32 voices
    • latencymark.fixed.little <= 15 msec
    • latencymark.dynamic.little <= 50 msec

  • オーディオ クロックの不正確さと標準時間に対するずれを最小限に抑えるべきです。

  • 両方ともアクティブな場合、CPU CLOCK_MONOTONIC に対するオーディオ クロックのずれを最小限に抑えるべきです。

  • デバイス上のトランスデューサでオーディオ レイテンシを最小限に抑えるべきです。

  • USB デジタル オーディオでオーディオ レイテンシを最小限に抑えるべきです。

  • すべてのパスでオーディオ レイテンシ測定値を記録すべきです。

  • コールバックによる CPU 帯域幅全体の使用可能率に影響するため、オーディオ バッファ完了コールバック エントリ時間のジッターを最小限に抑えるべきです。

  • レポートされたレイテンシで通常の使用におけるオーディオ グリッチをゼロにすべきです。

  • チャンネル間のレイテンシ差をゼロにすべきです。

  • すべてのトランスポートで MIDI 平均レイテンシを最小限に抑えるべきです。

  • すべてのトランスポートで負荷がかかった状態での MIDI レイテンシのばらつき（ジッター）を最小限に抑えるべきです。

  • すべてのトランスポートで MIDI タイムスタンプを正確にすべきです。

  • コールド スタート直後の期間を含め、デバイス上のトランスデューサでオーディオ信号ノイズを最小限に抑えるべきです。

  • 両方ともアクティブな場合、対応するエンドポイントの入力側と出力側でオーディオ クロックの差をゼロにすべきです。対応するエンドポイントの例としては、デバイス上のマイクとスピーカーや、オーディオ ジャックの入出力が挙げられます。

  • 両方ともアクティブな場合、同じスレッド上の対応するエンドポイントの入力側と出力側のオーディオ バッファ完了コールバックを処理し、入力コールバックからのリターンの直後に出力コールバックに入るべきです。または、同じスレッド上でコールバックを処理できない場合は、入力コールバックの直後に出力コールバックに入り、アプリが入力側と出力側のタイミングを一貫させられるようにします。

  • 対応するエンドポイントの入力側と出力側で、HAL オーディオ バッファの位相差を最小限に抑えるべきです。

  • タップ レイテンシを最小限に抑えるべきです。

  • 負荷がかかった状態でのタップ レイテンシのばらつき（ジッター）を最小限に抑えるべきです。

上記の要件をすべて満たす場合、デバイス実装は:

  • [C-SR-4] android.content.pm.PackageManager クラスを介して機能 android.hardware.audio.pro のサポートをレポートすることが強く推奨されます。

4 極 3.5 mm オーディオ ジャックが含まれる場合、デバイス実装は:

4 極 3.5 mm オーディオ ジャックを省略し、USB ホストモードをサポートする USB ポートを含める場合、デバイス実装は:

  • [C-3-1] USB オーディオ クラスを実装しなければなりません。
  • [C-3-2] USB オーディオ クラスを使用し、USB ホストモード ポートで 5 回測定して、平均連続ラウンドトリップ オーディオ レイテンシが 25 ミリ秒以下、平均絶対偏差 5 ミリ秒未満でなければなりません（これは、USB-3.5 mm アダプターとオーディオ ループバック ドングルを使用して、または入力と出力をパッチケーブルで接続した USB オーディオ インターフェースを使用して測定できます）。
  • [C-SR-6] これらの要件にも対応した USB オーディオ周辺機器で使用する場合、各方向で最大 8 チャンネル、サンプルレート 96 kHz、24 ビットまたは 32 ビット深度の同時 I/O をサポートすることが強く推奨されます。
  • [C-SR-7] MMAP パスで AAudio ネイティブ オーディオ API を使用してこの要件グループを満たすことが強く推奨されます。

HDMI ポートが含まれる場合、デバイス実装は:

  • 少なくとも 1 つの構成で、ビット深度損失やリサンプリングなしで、20 ビットまたは 24 ビット深度、192 kHz のステレオと 8 チャンネルの出力をサポートすべきです。

5.11. 未処理のキャプチャ

Android は、android.media.MediaRecorder.AudioSource.UNPROCESSED 音源を介した未処理オーディオの録音をサポートしています。OpenSL ES では、録音プリセット SL_ANDROID_RECORDING_PRESET_UNPROCESSED でアクセスできます。

未処理音原をサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

  • [C-1-1] android.media.AudioManager プロパティ PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED を通じてサポートをレポートしなければなりません。

  • [C-1-2] 未処理音源の録音に使用する各マイクすべてについて、中間周波数範囲でほぼ平坦な振幅周波数特性を示さなければなりません（具体的には ±10dB、100 Hz～7,000 Hz）。

  • [C-1-3] 未処理音源の録音に使用する各マイクすべてについて、中間周波数範囲と比較して低い周波数範囲の振幅レベルを示さなければなりません（具体的には ±20 dB、5 Hz～100 Hz）。

  • [C-1-4] 未処理音源の録音に使用する各マイクすべてについて、中間周波数範囲と比較して高い周波数範囲の振幅レベルを示さなければなりません（具体的には ±30 dB、7,000 Hz～22 KHz）。

  • [C-1-5] 未処理音源の録音に使用する各マイクすべてについて、音圧レベル（SPL）94 dB で再生された 1,000 Hz 正弦波音源が、16 ビットサンプルで RMS 520 のレスポンスになるように（浮動小数点 / 倍精度サンプルの場合は -36 dB フルスケール）、オーディオ入力感度を設定しなければなりません。

  • [C-1-6] 未処理音源の録音に使用する各マイクすべてについて、信号対雑音比（SNR）を 60 dB にしなければなりません（SNR は、SPL 94 dB と、A 特性自己雑音の等価 SPL の差として測定します）。

  • [C-1-7] 未処理音源の録音に使用する各マイクすべてにおいて、全高調波歪み（THD）を、SPL 入力レベル 90 dB で 1 kHz に対して 1% 未満にしなければなりません。

  • [C-1-8] レベルを目的の範囲にするために、レベル乗算器以外の信号処理（自動ゲイン コントロール、ハイ パスフィルタ、エコー キャンセラなど）があってはなりません。つまり:

    • [C-1-9] なんらかの理由で、なんらかの信号処理がアーキテクチャに存在する場合、無効にしなければならず、ゼロ遅延または余分なレイテンシを信号パスに効果的に導入しなければなりません。
    • [C-1-10] レベル乗算器は、パス上にあることが許容されますが、信号パスに遅延またはレイテンシを導入してはなりません。

SPL の測定はすべて、テスト対象のマイクのすぐ隣で直接行います。マイクが複数ある構成では、これらの要件を各マイクに適用します。

android.hardware.microphone を宣言するが、未処理音源をサポートしない場合、デバイス実装は:

  • [C-2-1] サポートしていないことを適切に示すために、AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API メソッドについて null を返さなければなりません。
  • [C-SR-1] その場合でも、未処理録音源の信号パスに関する要件を可能な限り多く満たすことが強く推奨されます。

5.12. HDR 動画

今後のドキュメントで説明するように、Android 13 は HDR テクノロジーをサポートします。

ピクセルの形式

COLOR_FormatYUVP010 のサポートをアドバタイズしている場合、動画デコーダは:

  • [C-1-1] CPU 読み取り（ImageReader、MediaImage、ByteBuffer）の P010 形式をサポートしなければなりません。Android 13 では P010 が緩和され、Y プレーンと UV プレーンで任意のストライドが可能になりました。

  • [C-1-2] P010 出力バッファを GPU でサンプリングできるようにしなければなりません（GPU_SAMPLING 用途を指定して割り当てる場合）。これにより、アプリによる GPU 合成とカスタムトーン マッピングが可能になります。

COLOR_Format32bitABGR2101010 のサポートをアドバタイズしている場合、動画デコーダは:

  • [C-2-1] 出力サーフェスと CPU 読み取り可能（ByteBuffer の出力）の RGBA_1010102 形式をサポートしなければなりません。

COLOR_FormatYUVP010 のサポートをアドバタイズしている場合、動画エンコーダは:

  • [C-3-1] 入力サーフェスと CPU 書き込み可能（ImageWriter、MediaImage、ByteBuffer の入力）の P010 形式をサポートしなければなりません。

COLOR_Format32bitABGR2101010 のサポートをアドバタイズしている場合、動画エンコーダは:

  • [C-4-1] 入力サーフェスと CPU 書き込み可能（ImageWriter、ByteBuffer の入力）の RGBA_1010102 形式をサポートしなければなりません。注: エンコーダでは、さまざまな転送曲線間の変換は必要ありません。

HDR キャプチャの要件

HDR プロファイルをサポートするすべての動画エンコーダについて、デバイス実装は:

  • [C-5-1] HDR メタデータが正確であると想定してはなりません。たとえば、エンコードされたフレームにピーク輝度レベルを超えるピクセルが含まれる場合や、ヒストグラムが典型的なフレームを表していない場合があります。

  • エンコードされたストリームに適切な HDR 静的メタデータを生成するために、HDR 動的メタデータを集約し、各エンコード セッションの最後に出力すべきです。

CamcorderProfile API を使用した HDR キャプチャをサポートしている場合、デバイス実装は:

  • [C-6-1] Camera2 API を介した HDR キャプチャもサポートしなければなりません。

  • [C-6-2] サポートされる HDR テクノロジーごとに、少なくとも 1 つのハードウェア アクセラレーテッド動画エンコーダをサポートしなければなりません。

  • [C-6-3] （少なくとも）HLG キャプチャをサポートしなければなりません。

  • [C-6-4] キャプチャした動画ファイルへの HDR メタデータ（HDR テクノロジーに適用可能な場合）の書き込みをサポートしなければなりません。AV1、HEVC、DolbyVision の場合、これはエンコードされたビットストリームにメタデータを含めることを意味します。

  • [C-6-5] P010 と COLOR_FormatYUVP010 をサポートしなければなりません。

  • [C-6-6] キャプチャしたプロファイルについては、デフォルトのハードウェア アクセラレーテッド デコーダで、HDR から SDR へのトーン マッピングをサポートしなければなりません。つまり、デバイスが HDR10+ HEVC をキャプチャできる場合、デフォルトの HEVC デコーダは、キャプチャしたストリームを SDR でデコードできなければなりません。

HDR 編集の要件

HDR 編集をサポートする動画エンコーダが含まれる場合、デバイス実装は:

  • HDR メタデータが存在しない場合は、HDR メタデータを生成する際のレイテンシを最小限にすべきです。また、メタデータが存在するフレームと存在しないフレームが混在する状況に適切に対処すべきです。このメタデータは正確であるべきです（たとえば、実際のピーク輝度、フレームのヒストグラムを表すべきです）。

FEATURE_HdrEditing をサポートするコーデックが含まれる場合、デバイス実装は:

  • [C-7-1] 少なくとも 1 つの HDR プロファイルをサポートしなければなりません。

  • [C-7-2] そのコーデックによってアドバタイズされるすべての HDR プロファイルについて、FEATURE_HdrEditing をサポートしなければなりません。つまり、HDR メタデータを使用する、サポートされるすべての HDR プロファイルに HDR メタデータが存在しない場合、HDR メタデータの生成をサポートしなければなりません。

  • [C-7-3] 入力サーフェスと ByteBuffer の両方について、HDR デコード信号を完全に保持する動画エンコーダ入力形式である

    • RGBA_1010102（すでにターゲット転送曲線にある）をサポートしなければならず、COLOR_Format32bitABGR2101010 のサポートをアドバタイズしなければなりません。

FEATURE_HdrEditing をサポートするコーデックが含まれる場合、デバイス実装は:

  • [C-7-4] EXT_YUV_target OpenGL 拡張機能のサポートをアドバタイズしなければなりません。

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

6.1. デベロッパー ツール

デバイス実装は:

  • [C-0-1] Android SDK で提供されている Android デベロッパー ツールをサポートしなければなりません。

  • Android Debug Bridge（adb）

    • [C-0-2] Android SDK に記載されている adb と、アプリ デベロッパーが使用できる、AOSP で提供されるシェルコマンド（dumpsys cmd stats を含む）をサポートしなければなりません。
    • [C-0-11] シェルコマンド cmd testharness をサポートしなければなりません。永続データブロックのない以前の Android バージョンからデバイス実装をアップグレードする場合は、C-0-11 を免除しても構いません。
    • [C-0-3] dumpsys コマンドを介してログに記録されるデバイス システム イベント（batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats）の形式またはコンテンツを変更してはなりません。
    • [C-0-10] 次のイベントを省略せずに記録し、cmd stats シェルコマンドと StatsManager システム API クラスからアクセスして利用できるようにしなければなりません。
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] デバイス側の adb デーモンをデフォルトで無効にしなければならず、Android Debug Bridge をオンにするためのユーザーがアクセス可能なメカニズムがなければなりません。
    • [C-0-5] セキュア adb をサポートしなければなりません。Android は、セキュア adb をサポートしています。セキュア adb は、既知の認証済みホストで adb を有効にします。
    • [C-0-6] adb をホストマシンから接続できるようにするメカニズムを提供しなければなりません。具体的には次のとおりです。

    USB ポートなしでペリフェラル モードをサポートする場合、デバイス実装は:

    • [C-3-1] ローカルエリア ネットワーク（イーサネット、Wi-Fi など）を介して adb を実装しなければなりません。
    • [C-3-2] デベロッパーが adb プロトコルを使用してデバイスに接続できるように、Windows 7、8、10 用のドライバを提供しなければなりません。

    Wi-Fi またはイーサネットを介したホストマシンへの adb 接続をサポートする場合、デバイス実装は:

    • [C-4-1] AdbManager#isAdbWifiSupported() メソッドが true を返さなければなりません。

    Wi-Fi またはイーサネットを介したホストマシンへの adb 接続をサポートし、カメラが 1 つ以上含まれる場合、デバイス実装は:

    • [C-5-1] AdbManager#isAdbWifiQrSupported() メソッドが true を返さなければなりません。

  • Dalvik Debug Monitor Service（ddms）

    • [C-0-7] Android SDK に記載されているとおり、ddms 機能をすべてサポートしなければなりません。ddms は adb を使用するため、ddms のサポートはデフォルトで無効にすべきですが、上記のようにユーザーが Android Debug Bridge を有効にした場合は必ずサポートしなければなりません。

  • SysTrace

    • [C-0-9] Android SDK に記載されているとおり、systrace ツールをサポートしなければなりません。Systrace はデフォルトで無効でなければならず、Systrace をオンにするユーザーがアクセス可能なメカニズムがなければなりません。

  • Perfetto

    • [C-SR-1] cmdline で perfetto ドキュメントを遵守しているシェルユーザーに /system/bin/perfetto バイナリを公開することが強く推奨されます。
    • [C-SR-2] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れることが強く推奨されます。
    • [C-SR-3] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込むことが強く推奨されます。
    • [C-SR-4] perfetto バイナリを通じて、少なくとも perfetto ドキュメントに記載されているデータソースを提供することが強く推奨されます。

  • ローメモリ キラー

    • [C-0-12] アプリがローメモリ キラーによって終了したとき、LMK_KILL_OCCURRED_FIELD_NUMBER Atom を statsd ログに書き込まなければなりません。

  • テストハーネス モード シェルコマンド cmd testharness をサポートし、cmd testharness enable を実行する場合、デバイス実装は:

    • [C-2-1] ActivityManager.isRunningInUserTestHarness() について true を返さなければなりません。
    • [C-2-2] テストハーネス モードのドキュメントに記載されているとおり、テストハーネス モードを実装しなければなりません。

  • GPU 処理に関する情報

    デバイス実装は:

    • [C-0-13] power/gpu_work_period カーネル トレースポイントによって返された GPU 処理の集計データを表示し、トレースポイントがサポートされていない場合はデータを表示しないよう、シェルコマンド dumpsys gpu --gpuwork を実装しなければなりません。AOSP 実装は frameworks/native/services/gpuservice/gpuwork/ です。

android.hardware.vulkan.version 機能フラグを介して Vulkan 1.0 以降のサポートをレポートする場合、デバイス実装は:

  • [C-1-1] GPU デバッグレイヤを有効化 / 無効化するアフォーダンスをアプリ デベロッパーに提供しなければなりません。
  • [C-1-2] GPU デバッグレイヤが有効な場合、API メソッド vkEnumerateInstanceLayerProperties() と vkCreateInstance() をサポートするために、デバッグ可能なアプリのベース ディレクトリにある外部ツール（つまり、プラットフォームまたはアプリ パッケージの一部ではありません）によって提供されるライブラリのレイヤを列挙しなければなりません。

6.2. 開発者向けオプション

Android は、デベロッパーがアプリ開発関連の設定を構成することをサポートしています。

デバイス実装は開発者向けオプションに一貫したエクスペリエンスを提供しなければならず、デバイス実装は:

  • [C-0-1] android.settings.APPLICATION_DEVELOPMENT_SETTINGS インテントを使用して、アプリ開発関連の設定を表示しなければなりません。アップストリームの Android 実装では、デフォルトで開発者向けオプション メニューが非表示になっており、ユーザーが [設定] > [デバイス情報] > [ビルド番号] メニュー アイテムを 7 回タップすると開発者向けオプションを起動できます。
  • [C-0-2] デフォルトで開発者向けオプションを非表示にしなければなりません。
  • [C-0-3] 開発者向けオプションを有効にするために、あるサードパーティ アプリを別のアプリより優先して扱うことのない、明確なメカニズムを提供しなければなりません。開発者向けオプションを有効にする方法を説明する公開ドキュメントまたはウェブサイトを提供しなければなりません。このドキュメントまたはウェブサイトは、Android SDK ドキュメントからリンクできなければなりません。
  • 開発者向けオプションが有効になっており、ユーザーの安全性が懸念されるときは、ユーザーに対して進行中の通知を表示すべきです。
  • ユーザーの安全性が懸念されるシナリオでは、メニューを非表示または無効にして、開発者向けオプション メニューへのアクセスを一時的に制限しても構いません。

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

デバイスに、サードパーティ デベロッパー向けの API を持つ特定のハードウェア コンポーネントが含まれる場合:

  • [C-0-1] デバイス実装は、Android SDK ドキュメントに記載されているとおり、その API を実装しなければなりません。

任意であると明記されているハードウェア コンポーネントを SDK の API が操作し、デバイス実装がそのコンポーネントを備えていない場合:

  • [C-0-2] そのような場合でも、コンポーネント API の完全なクラス定義（SDK に記載）を提示しなければなりません。
  • [C-0-3] API の動作は、なんらかの合理的な方法で NoOps として実装しなければなりません。
  • [C-0-4] API メソッドは、SDK ドキュメントで許可されている場合、null 値を返さなければなりません。
  • [C-0-5] API メソッドは、null 値が SDK ドキュメントで許可されていないクラスの NoOps 実装を返さなければなりません。
  • [C-0-6] API メソッドは、SDK ドキュメントに記載されていない例外をスローしてはなりません。
  • [C-0-7] デバイス実装は、同じビルドのフィンガープリントについて、android.content.pm.PackageManager クラスの getSystemAvailableFeatures() メソッドと hasSystemFeature(String) メソッドを介して正確なハードウェア構成情報を一貫してレポートしなければなりません。

これらの要件が適用されるシナリオの典型例は、テレフォニー API です。電話以外のデバイスであっても、これらの API を妥当な NoOps として実装しなければなりません。

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. 画面構成

7.1.1.1. 画面サイズと形状

Android UI フレームワークはさまざまな論理画面レイアウト サイズをサポートしており、アプリは SCREENLAYOUT_SIZE_MASK と Configuration.smallestScreenWidthDp を使用して、Configuration.screenLayout を介して現在の構成の画面レイアウト サイズをクエリできます。

デバイス実装は:

  • [C-0-1] Android SDK ドキュメントで定義されているとおり、Configuration.screenLayout について、正しいレイアウト サイズをレポートしなければなりません。具体的には、デバイス実装は、下記のとおり正確な論理密度非依存ピクセル（dp）画面寸法をレポートしなければなりません。

    • Configuration.uiMode が UI_MODE_TYPE_WATCH 以外の値に設定され、Configuration.screenLayout について small サイズをレポートするデバイスは、少なくとも 426 dp x 320 dp でなければなりません。
    • Configuration.screenLayout について normal サイズをレポートするデバイスは、少なくとも 480 dp x 320 dp でなければなりません。
    • Configuration.screenLayout について large サイズをレポートするデバイスは、少なくとも 640 dp x 480 dp でなければなりません。
    • Configuration.screenLayout について xlarge サイズをレポートするデバイスは、少なくとも 960 dp x 720 dp でなければなりません。

  • [C-0-2] Android SDK ドキュメントに記載されているとおり、AndroidManifest.xml の <supports-screens> 属性を通じて、アプリによる所定の画面サイズのサポートを正しく使用しなければなりません。

  • 隅の丸い Android 互換ディスプレイであっても構いません。

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

  • [C-1-1] 各ディスプレイで次の要件のうち少なくとも 1 つを満たさなければなりません。

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

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

新しい要件の開始

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

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

新しい要件の終了

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

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

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

サイドカー API または拡張機能 API の正しい実装の詳細については、Window Manager Jetpack の公開ドキュメントをご覧ください。

新しい要件の開始

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

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

新しい要件の終了

7.1.1.2. 画面のアスペクト比

Android 互換ディスプレイの物理ディスプレイのアスペクト比に制限はありませんが、サードパーティ アプリがレンダリングする、view.Display API と Configuration API を通じてレポートされる高さと幅の値から得られる論理ディスプレイのアスペクト比は、次の要件を満たさなければなりません。

  • [C-0-1] Configuration.uiMode が UI_MODE_TYPE_NORMAL に設定されたデバイス実装は、アプリが次の条件のいずれかを満たす場合を除き、アスペクト比の値を 1.86（おおよそ 16:9）以下にしなければなりません。

    • アプリが、android.max_aspect メタデータ値を通じてより大きな画面アスペクト比のサポートを宣言した。
    • アプリが、android:resizeableActivity 属性を介してサイズ変更可能であることを宣言する。
    • アプリが、API レベル 24 以降をターゲットとしており、許可されるアスペクト比を制限する android:maxAspectRatio を宣言しない。

  • [C-0-3] Configuration.uiMode が UI_MODE_TYPE_WATCH に設定されたデバイス実装は、アスペクト比の値を 1.0（1:1）に設定しなければなりません。

7.1.1.3. 画面密度

Android UI フレームワークは、アプリ デベロッパーがアプリリソースをターゲットにできるように、標準的な論理密度のセットを定義しています。

デバイス実装は:

  • [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 倍よりも小さく調整してはなりません。
  • 優れたユーザビリティと一貫したフォントサイズを実現するために、上記の制限を遵守しつつ、次に示すネイティブ ディスプレイ オプションの調整を行えるようにすることが推奨されます。
    • 小: 0.85 倍
    • デフォルト: 1 倍（ネイティブ ディスプレイ スケール）
    • 中: 1.15 倍
    • 大: 1.3 倍
    • 特大 1.45 倍

7.1.2. ディスプレイの指標

Android 互換ディスプレイまたは Android 互換ディスプレイ画面への動画出力が含まれる場合、デバイス実装は:

  • [C-1-1] android.util.DisplayMetrics API で定義されたすべての Android 互換ディスプレイ指標について正しい値をレポートしなければなりません。

埋め込み画面または動画出力が含まれない場合、デバイス実装は:

  • [C-2-1] エミュレートされたデフォルトの view.Display について、android.util.DisplayMetrics API で定義されているとおり、Android 互換ディスプレイの値を正しくレポートしなければなりません。

7.1.3. 画面の向き

デバイス実装は:

  • [C-0-1] サポートする画面の向き（android.hardware.screen.portrait、android.hardware.screen.landscape）をレポートしなければならず、サポート対象の向きのうち少なくとも 1 つをレポートしなければなりません。たとえば、テレビやノートパソコンなど、固定の横向き画面を備えたデバイスは android.hardware.screen.landscape のみをレポートすべきです。
  • [C-0-2] android.content.res.Configuration.orientation、android.view.Display.getOrientation()、またはその他の API を介してクエリされたときは常に、デバイスの現在の画面の向きについて、正しい値をレポートしなければなりません。

画面の向きを両方ともサポートする場合、デバイス実装は:

  • [C-1-1] アプリが画面の向きを動的に横向きまたは縦向きに変更することをサポートしなければなりません。つまりデバイスは、特定の画面の向きに関するアプリからのリクエストを尊重しなければなりません。
  • [C-1-2] 画面の向きを変更するとき、レポート対象の画面サイズまたは密度を変更してはなりません。
  • 横向きまたは縦向きのいずれかをデフォルトとして選択しても構いません。

7.1.4. 2D と 3D のグラフィック アクセラレーション

7.1.4.1 OpenGL ES

デバイス実装は:

  • [C-0-1] マネージド API（GLES10.getString() メソッドなど）とネイティブ API を通じて、サポート対象の OpenGL ES バージョン（1.1、2.0、3.0、3.1、3.2）を正しく識別しなければなりません。
  • [C-0-2] サポート対象として識別されたすべての OpenGL ES バージョンについて、対応するマネージド API とネイティブ API をサポートしなければなりません。

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

  • [C-1-1] Android SDK ドキュメントに盛り込まれ、詳述されているとおり、OpenGL ES 1.1 と 2.0 を両方ともサポートしなければなりません。
  • [C-SR-1] OpenGL ES 3.1 をサポートすることが強く推奨されます。
  • OpenGL ES 3.2 をサポートすべきです。

OpenGL ES dEQP テストはいくつかのテストリストに分割されており、それぞれに日付 / バージョンが関連付けられています。Android ソースツリーの external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt にあります。自己申告レベルで OpenGL ES をサポートするデバイスは、このレベルとそれより前のテストリストすべてで dEQP テストに合格できることを示しています。

OpenGL ES のいずれかのバージョンをサポートする場合、デバイス実装は:

  • [C-2-1] OpenGL ES マネージド API とネイティブ API を介して、実装されている他の OpenGL ES 拡張機能をレポートしなければならず、また逆に、サポートしていない拡張機能の文字列をレポートしてはなりません。
  • [C-2-2] 拡張機能 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、EGL_ANDROID_recordable、EGL_ANDROID_GLES_layers をサポートしなければなりません。
  • [C-2-3] android.software.opengles.deqp.level 機能フラグを介してサポートする OpenGL ES dEQP テストの最大バージョンをレポートしなければなりません。
  • [C-2-4] android.software.opengles.deqp.level 機能フラグでレポートされるとおり、少なくともバージョン 132383489 をサポートしなければなりません（2020 年 3 月 1 日から）。
  • [C-2-5] サポート対象の OpenGL ES バージョンごとに、バージョン 132383489 から android.software.opengles.deqp.level 機能フラグで指定されたバージョンまでのテストリストにある、すべての OpenGL ES dEQP テストに合格しなければなりません。
  • [C-SR-2] 拡張機能 EGL_KHR_partial_update と OES_EGL_image_external をサポートすることが強く推奨されます。

  • getString() メソッドを介して、サポート対象のテクスチャ圧縮形式（通常はベンダー固有）を正確にレポートすべきです。

  • EGL_IMG_context_priority 拡張機能と EGL_EXT_protected_content 拡張機能をサポートすべきです。

OpenGL ES 3.0、3.1 または 3.2 のサポートを宣言する場合、デバイス実装は:

  • [C-3-1] libGLESv2.so ライブラリの OpenGL ES 2.0 関数シンボルに加え、これらのバージョンについて、対応する関数シンボルをエクスポートしなければなりません。
  • [C-SR-3] 拡張機能 OES_EGL_image_external_essl3 をサポートすることが強く推奨されます。

OpenGL ES 3.2 をサポートする場合、デバイス実装は:

  • [C-4-1] OpenGL ES Android 拡張機能パック全体をサポートしなければなりません。

OpenGL ES Android 拡張機能パック全体をサポートする場合、デバイス実装は:

  • [C-5-1] android.hardware.opengles.aep 機能フラグを通じてサポートを識別しなければなりません。

拡張機能 EGL_KHR_mutable_render_buffer のサポートを公開する場合、デバイス実装は:

  • [C-6-1] 拡張機能 EGL_ANDROID_front_buffer_auto_refresh もサポートしなければなりません。
7.1.4.2 Vulkan

Android は、高パフォーマンスの 3D グラフィックを実現する、低オーバーヘッドのクロスプラットフォーム API である Vulkan をサポートしています。

OpenGL ES 3.1 をサポートする場合、デバイス実装は:

  • [C-SR-1] Vulkan 1.3 のサポートを含むことが強く推奨されます。
  • [C-4-1] Vulkan バリアント バージョンをサポートしてはなりません（Vulkan コアバージョンのバリアント部分はゼロでなければなりません）。

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

  • [C-SR-2] Vulkan 1.3 のサポートを含むことが強く推奨されます。

Vulkan dEQP テストはいくつかのテストリストに分割されており、それぞれに日付 / バージョンが関連付けられています。Android ソースツリーの external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt にあります。自己申告レベルで Vulkan をサポートするデバイスは、このレベルとそれより前のテストリストすべてで dEQP テストに合格できることを示しています。

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

  • [C-1-1] 機能フラグ android.hardware.vulkan.level と android.hardware.vulkan.version で正しい整数値をレポートしなければなりません。
  • [C-1-2] Vulkan ネイティブ API vkEnumeratePhysicalDevices() について、VkPhysicalDevice を少なくとも 1 つ列挙しなければなりません。
  • [C-1-3] 列挙した VkPhysicalDevice ごとに Vulkan 1.0Vulkan 1.1 API を完全に実装しなければなりません。
  • [C-1-4] Vulkan ネイティブ API vkEnumerateInstanceLayerProperties() と vkEnumerateDeviceLayerProperties() を通じて、アプリ パッケージのネイティブ ライブラリ ディレクトリにある libVkLayer*.so というネイティブ ライブラリに含まれるレイヤを列挙しなければなりません。
  • [C-1-5] アプリに true として設定された android:debuggable 属性または true に設定されたメタデータ com.android.graphics.injectLayers.enable がある場合を除き、アプリ パッケージ外のライブラリによって提供されるレイヤの列挙、Vulkan API をトレースまたはインターセプトする別の方法の提供をしてはなりません。
  • [C-1-6] Vulkan ネイティブ API を介してサポートする拡張機能の文字列をすべてレポートしなければならず、また逆に、正しくサポートしない拡張機能の文字列をレポートしてはなりません。
  • [C-1-7] 拡張機能 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_incremental_present をサポートしなければなりません。
  • [C-1-8] android.software.vulkan.deqp.level 機能フラグを介してサポートする Vulkan dEQP テストの最大バージョンをレポートしなければなりません。
  • [C-1-9] android.software.vulkan.deqp.level 機能フラグでレポートされるとおり、少なくともバージョン 132317953 をサポートしなければなりません（2019 年 3 月 1 日から）。
  • [C-1-10] バージョン 132317953 と android.software.vulkan.deqp.level 機能フラグで指定されたバージョンの間のテストリストにあるすべての Vulkan dEQP テストに合格しなければなりません。
  • [C-1-11] 拡張機能 VK_KHR_video_queue、VK_KHR_video_decode_queue、または VK_KHR_video_encode_queue のサポートを列挙してはなりません。
  • [C-SR-3] 拡張機能 VK_KHR_driver_properties と VK_GOOGLE_display_timing をサポートすることが強く推奨されます。

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

  • [C-1-12] 拡張機能 VK_KHR_performance_query のサポートを列挙してはなりません。

新しい要件の開始

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

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

新しい要件の終了

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

  • [C-2-1] Vulkan 機能フラグ（例: android.hardware.vulkan.level、android.hardware.vulkan.version）を宣言してはなりません。
  • [C-2-2] Vulkan ネイティブ API vkEnumeratePhysicalDevices() について VkPhysicalDevice を列挙してはなりません。

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

  • [C-3-1] SYNC_FD 外部セマフォ型とハンドル型、VK_ANDROID_external_memory_android_hardware_buffer 拡張機能のサポートを公開しなければなりません。

新しい要件の開始

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

新しい要件の終了

7.1.4.3 RenderScript
  • [C-0-1] デバイス実装は、Android SDK ドキュメントに詳述されているとおり、Android RenderScript をサポートしなければなりません。
7.1.4.4 2D グラフィック アクセラレーション

Android には、マニフェスト タグ android:hardwareAccelerated または直接 API 呼び出しを使用することで、アプリ、アクティビティ、ウィンドウ、ビューのレベルで 2D グラフィックのハードウェア アクセラレーションを有効にすることを、アプリで宣言するメカニズムがあります。

デバイス実装は:

  • [C-0-1] ハードウェア アクセラレーションをデフォルトで有効にしなければならず、デベロッパーが android:hardwareAccelerated="false” を設定するか、Android View API を通じてハードウェア アクセラレーションを直接無効にすることでリクエストした場合、ハードウェア アクセラレーションを無効にしなければなりません。
  • [C-0-2] ハードウェア アクセラレーションに関する Android SDK ドキュメントに合致する動作を示さなければなりません。

Android には、ハードウェア アクセラレーションの OpenGL ES テクスチャを UI 階層のレンダリング ターゲットとしてデベロッパーが直接統合できる、TextureView オブジェクトがあります。

デバイス実装は:

  • [C-0-3] TextureView API をサポートしなければならず、アップストリームの Android 実装と合致する動作を示さなければなりません。
7.1.4.5 広色域ディスプレイ

Configuration.isScreenWideColorGamut() を通じて広色域ディスプレイのサポートを主張する場合、デバイス実装は:

  • [C-1-1] 色調整されたディスプレイがなければなりません。
  • [C-1-2] sRGB 色域全体を CIE 1931 xyY 空間でカバーする色域のディスプレイがなければなりません。
  • [C-1-3] 色域の面積が CIE 1931 xyY 空間で DCI-P3 の少なくとも 90% であるディスプレイがなければなりません。
  • [C-1-4] OpenGL ES 3.1 または 3.2 をサポートし、適切にレポートしなければなりません。
  • [C-1-5] 拡張機能 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、EGL_EXT_gl_colorspace_display_p3、EGL_EXT_gl_colorspace_display_p3_linear、EGL_EXT_gl_colorspace_display_p3_passthrough のサポートをアドバタイズしなければなりません。
  • [C-SR-1] GL_EXT_sRGB をサポートすることが強く推奨されます。

逆に、広色域ディスプレイをサポートしない場合、デバイス実装は:

  • [C-2-1] 画面色域が未定義であっても、CIE 1931 xyY 空間で sRGB の 100% 以上をカバーすべきです。

7.1.5. レガシーアプリの互換モード

Android は、以前の画面サイズに依存しない Andrdoid の旧バージョン用に開発されていないレガシーアプリを活用するために、フレームワークが「標準」画面サイズ相当（幅 320 dp）のモードで動作する「互換モード」を指定します。

7.1.6. 画面技術

Android プラットフォームには、アプリがリッチ グラフィックを Android 互換ディスプレイにレンダリングできるようにする API があります。このドキュメントで特に許可されていない限り、デバイスは、Android SDK で定義されているこれらの API をすべてサポートしなければなりません。

デバイス実装の Android 互換ディスプレイはすべて:

  • [C-0-1] 16 ビットカラー グラフィックをレンダリングできなければなりません。
  • 24 ビットカラー グラフィックに対応したディスプレイをサポートすべきです。
  • [C-0-2] アニメーションをレンダリングできなければなりません。
  • [C-0-3] ピクセル アスペクト比（PAR）が 0.9 から 1.15 の間でなければなりません。つまり、ピクセル アスペクト比は、許容差 10～15% でほぼ正方形（1.0）でなければなりません。

7.1.7. セカンダリ ディスプレイ

Android は、セカンダリ Android 互換ディスプレイをサポートしており、メディア共有機能と、外部ディスプレイにアクセスするためのデベロッパー API が有効になります。

有線、無線、または埋め込み式いずれかの追加のディスプレイ接続を介して外部ディスプレイをサポートする場合、デバイス実装は:

  • [C-1-1] Android SDK ドキュメントに記載されているとおり、DisplayManager システム サービスと API を実装しなければなりません。

7.2. 入力デバイス

デバイス実装は:

7.2.1. キーボード

サードパーティのインプット メソッド エディタ（IME）アプリのサポートが含まれる場合、デバイス実装は:

  • [C-1-1] android.software.input_methods 機能フラグを宣言しなければなりません。
  • [C-1-2] Input Management Framework を完全に実装しなければなりません。
  • [C-1-3] ソフトウェア キーボードをプリインストールしなければなりません。

デバイス実装は:

  • [C-0-1] android.content.res.Configuration.keyboard で指定された形式（QWERTY または 12 キー）のいずれかと一致しないハードウェア キーボードを含んではなりません。
  • 追加のソフトウェア キーボード実装を含むべきです。
  • ハードウェア キーボードを含んでも構いません。

7.2.2. タップ以外のナビゲーション

Android は、タップ以外のナビゲーションのメカニズムとして、D-pad、トラックボール、ホイールをサポートしています。

デバイス実装は:

タップ以外のナビゲーションがない場合、デバイス実装は:

  • [C-1-1] 入力管理エンジンと互換性のある、テキストの選択と編集のための妥当な代替ユーザー インターフェース メカニズムを提供しなければなりません。アップストリームの Android オープンソース実装には、タップ以外のナビゲーション入力がないデバイスでの使用に適した選択メカニズムがあります。

7.2.3. ナビゲーション キー

通常、専用の物理ボタンまたは区分けされたタッチスクリーン部分の操作を介して提供されるホーム機能、履歴機能、戻る機能は、Android ナビゲーション パラダイムに不可欠であり、したがってデバイス実装は:

  • [C-0-1] テレビデバイス実装のために、<intent-filter> が ACTION=MAIN と CATEGORY=LAUNCHER または CATEGORY=LEANBACK_LAUNCHER で設定されたアクティビティを持つインストール済みのアプリを起動するユーザー アフォーダンスを提供しなければなりません。ホーム機能は、このユーザー アフォーダンスのためのメカニズムであるべきです。
  • 履歴機能と戻る機能のためのボタンを提供すべきです。

ホーム機能、履歴機能、または戻る機能が提供される場合、これらの機能は:

  • [C-1-1] いずれかがアクセス可能な場合、単一の操作（タップ、ダブルクリック、ジェスチャーなど）によってアクセス可能でなければなりません。
  • [C-1-2] どの単一の操作が各機能をトリガーするかの明確な表示を提供しなければなりません。そうした表示の例としては、ボタンにアイコンを表示する、画面のナビゲーション バー部分にソフトウェア アイコンを表示する、開封時の初期設定中にガイド付きの段階的なデモフローを通じてユーザーに説明する、などが挙げられます。

デバイス実装は:

  • [C-SR-1] Android 4.0 以降、メニュー機能はサポートが終了してアクションバーに置き換えられたため、メニュー機能のための入力メカニズムを提供しないことが強く推奨されます。

  • [C-SR-2] すべてのナビゲーション機能をキャンセル可能として提供することが強く推奨されます。「キャンセル可能」とは、スワイプが特定のしきい値を超えても解放されない場合に、ユーザーがナビゲーション機能（「ホーム画面に移動する」、「戻る」など）を実行できないようにする機能を指します。

メニュー機能を提供する場合、デバイス実装は:

  • [C-2-1] アクション オーバーフロー メニューのポップアップが空ではなく、アクションバーが表示されているときは常に、アクション オーバーフロー ボタンを表示しなければなりません。
  • [C-2-2] アクションバーのオーバーフロー ボタンを選択することで表示されるアクション オーバーフロー ポップアップの位置を変更してはなりませんが、メニュー機能を選択することで表示されるときは、アクション オーバーフロー ポップアップを画面上の変更された位置にレンダリングしても構いません。

メニュー機能を提供しない場合、下位互換性のために、デバイス実装は: * [C-3-1] targetSdkVersion が 10 未満のときは、物理ボタン、ソフトウェア キー、ジェスチャーのいずれかによって、メニュー機能をアプリで利用できるようにしなければなりません。このメニュー機能は、他のナビゲーション機能とともに非表示になっている場合を除き、アクセス可能にすべきです。

アシスト機能を提供する場合、デバイス実装は:

  • [C-4-1] 他のナビゲーション キーがアクセス可能な場合、単一の操作（タップ、ダブルクリック、ジェスチャーなど）によってアシスト機能にアクセスできるようにしなければなりません。
  • [C-SR-3] この指定操作として、ホーム機能の長押しを使用することが強く推奨されます。

ナビゲーション キーを表示するために画面の区分けされた部分を使用する場合、デバイス実装は:

  • [C-5-1] ナビゲーション キーは、アプリでは利用できない、画面の区分けされた部分を使用しなければならず、アプリで利用できる画面部分を隠したり、利用を妨げたりしてはなりません。
  • [C-5-2] ディスプレイの一部を、セクション 7.1.1 で規定する要件を満たすアプリで利用できるようにしなければなりません。
  • [C-5-3] SDK に記載されているとおり、View.setSystemUiVisibility() API メソッドを通じてアプリが設定したフラグを使用して、この画面の区分けされた部分（ナビゲーション バー）が適切に非表示になるようにしなければなりません。

ナビゲーション機能が画面上のジェスチャーベースのアクションとして提供される場合:

  • [C-6-1] WindowInsets#getMandatorySystemGestureInsets() は、ホーム ジェスチャー認識エリアをレポートするためにのみ使用しなければなりません。
  • [C-6-2] View#setSystemGestureExclusionRects() を介して（WindowInsets#getMandatorySystemGestureInsets() 外で）フォアグラウンド アプリによって提供される除外矩形内で開始されるジェスチャーは、View#setSystemGestureExclusionRects() のドキュメントで規定されているとおり、除外矩形が最大除外制限内で許可されている限り、ナビゲーション機能用にインターセプトしてはなりません。
  • [C-6-3] フォアグラウンド アプリに MotionEvent.ACTION_DOWN イベントが以前に送信されていた場合、タップがシステム ジェスチャー用にインターセプトされ始めたら、フォアグラウンド アプリに MotionEvent.ACTION_CANCEL イベントを送信しなければなりません。
  • [C-6-4] 画面上のボタンベースのナビゲーションに切り替えるユーザー アフォーダンスを（設定などで）提供しなければなりません。
  • 現在の画面の向きで下端から上にスワイプした場合にホーム機能を提供すべきです。
  • ホーム ジェスチャーと同じエリアから上にスワイプし、保持してから指を離した場合に履歴機能を提供すべきです。
  • WindowInsets#getMandatorySystemGestureInsets() 内で開始されるジェスチャーは、View#setSystemGestureExclusionRects() を介してフォアグラウンド アプリによって提供される除外矩形の影響を受けるべきではありません。

ナビゲーション機能が、現在の画面の向きで左右端のどこからでも提供される場合:

  • [C-7-1] ナビゲーション機能は「戻る」でなければならず、現在の画面の向きで左右端からスワイプした場合に提供しなければなりません。
  • [C-7-2] カスタムのスワイプ可能なシステムパネルが左右どちらかの端で提供される場合、ドラッグするとそのパネルが呼び出され、戻る機能は呼び出されないことを明確かつ永続的に表示して、画面の上部 1/3 の範囲内に配置しなければなりません。システムパネルは、画面端の上部 1/3 未満に収まるようにユーザーが設定しても構いませんが、端の 1/3 より長くなってはなりません。
  • [C-7-3] フォアグラウンド アプリに View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT、または WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE のフラグが設定されている場合、端からのスワイプで、SDK に記載されている AOSP の実装どおりに動作しなければなりません。
  • [C-7-4] フォアグラウンド アプリに View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT、または WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE のフラグが設定されている場合、カスタムのスワイプ可能なシステムパネルは、AOSP の実装どおり、ユーザーがシステムバー（ナビゲーション バー、ステータスバー）を表示するか省略表示を解除するまで、非表示にしなければなりません。

「戻る」ナビゲーション機能が提供されていて、ユーザーが「戻る」ジェスチャーをキャンセルした場合:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() を呼び出さなければなりません。
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() を呼び出してはなりません。
  • [C-8-3] KEYCODE_BACK イベントをディスパッチしてはなりません。

「戻る」ナビゲーション機能が提供されているが、フォアグラウンド アプリに OnBackInvokedCallback が登録されていない場合:

  • システムは、AOSP で提供されているように、ユーザーが戻ることを示唆するフォアグラウンド アプリのアニメーションを提供すべきです。

システム API setNavBarMode のサポートを提供し、それによって android.permission.STATUS_BAR 権限を持つシステムアプリがナビゲーション バーのモードを設定できるようにする場合、デバイス実装は:

  • [C-9-1] AOSP コードで提供されているとおり、子供向けアイコンまたはボタンベースのナビゲーションのサポートを提供しなければなりません。

7.2.4. タッチスクリーン入力

Android は、タッチスクリーン、タッチパッド、疑似タップ入力デバイスなど、さまざまなポインタ入力システムをサポートしています。タッチスクリーンベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるディスプレイに関連付けられます。ユーザーが画面に直接触れているため、操作中のオブジェクトを示すアフォーダンスを追加する必要はありません。

デバイス実装は:

  • なんらかのポインタ入力システム（マウスのようなもの、またはタップ）があるべきです。
  • 完全に独立してトラックされるポインタをサポートすべきです。

プライマリ Android 互換ディスプレイ上のタッチスクリーン（シングルタップ以上）が含まれる場合、デバイス実装は:

  • [C-1-1] Configuration.touchscreen API フィールドについて TOUCHSCREEN_FINGER をレポートしなければなりません。
  • [C-1-2] 機能フラグ android.hardware.touchscreen と android.hardware.faketouch をレポートしなければなりません。

プライマリ Android 互換ディスプレイで複数のタップをトラックできるタッチスクリーンが含まれる場合、デバイス実装は:

  • [C-2-1] デバイス上の具体的なタッチスクリーンの種類に応じた、該当する機能フラグ android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand をレポートしなければなりません。

プライマリ Android 互換ディスプレイでの入力についてマウスやトラックボールなどの外部入力デバイスに依存し（つまり画面に直接触れず）、セクション 7.2.5 の疑似タップの要件を満たしている場合、デバイス実装は:

  • [C-3-1] android.hardware.touchscreen で始まる機能フラグをレポートしてはなりません。
  • [C-3-2] android.hardware.faketouch のみをレポートしなければなりません。
  • [C-3-3] Configuration.touchscreen API フィールドについて TOUCHSCREEN_NOTOUCH をレポートしなければなりません。

7.2.5. 疑似タップ入力

疑似タップ インターフェースは、タッチスクリーン機能のサブセットに近いユーザー入力システムを提供します。たとえば、画面上のカーソルを操作するマウスまたはリモコンはタップに似ていますが、ユーザーは最初にポイントするかフォーカスしてからクリックする必要があります。マウス、トラックパッド、ジャイロベースのエアマウス、ジャイロポインタ、ジョイスティック、マルチタッチ トラックパッドなど、多くの入力デバイスが擬似タップ インターフェースをサポートできます。Android には、機能定数 android.hardware.faketouch があります。これは、タッチベースの入力を適切にエミュレートできる（基本的なジェスチャーのサポートを含む）、マウスやトラックパッドなど忠実度の高いタップ以外の（ポインタベースの）入力デバイスに対応し、タッチスクリーン機能のエミュレートされたサブセットをデバイスがサポートしていることを示します。

タッチスクリーンは含まれないが、利用する予定の別のポインタ入力システムが含まれる場合、デバイス実装は:

  • android.hardware.faketouch 機能フラグのサポートを宣言すべきです。

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

  • [C-1-1] ポインタ位置の絶対 X 画面位置と絶対 Y 画面位置をレポートし、画面にビジュアル ポインタを表示しなければなりません。
  • [C-1-2] ポインタが画面上を上下するときに発生する状態変化を指定するアクション コードで、タッチイベントをレポートしなければなりません。
  • [C-1-3] ユーザーが画面上のオブジェクトのタップをエミュレートできるように、画面上のオブジェクトでのポインタの上下移動をサポートしなければなりません。
  • [C-1-4] ユーザーが画面上のオブジェクトのダブルタップをエミュレートできるように、時間しきい値内で、画面上のオブジェクトの同じ場所におけるポインタの下移動、ポインタの上移動、ポインタの下移動からの上移動をサポートしなければなりません。
  • [C-1-5] ユーザーがタップドラッグをエミュレートできるように、画面上の任意の点におけるポインタの下移動、画面上の他の任意の点へのポインタ移動、その後のポインタの上移動をサポートしなければなりません。
  • [C-1-6] ユーザーが画面上のオブジェクトをフリングできるように、ポインタの下移動をサポートし、ユーザーが画面上の別の位置にオブジェクトを素早く移動してから画面上でポインタを上移動できるようにしなければなりません。

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

  • [C-2-1] android.hardware.faketouch のサポートを宣言しなければなりません。
  • [C-2-2] 複数の独立したポインタ入力の個別トラッキングをサポートしなければなりません。

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

  • [C-3-1] android.hardware.faketouch のサポートを宣言しなければなりません。
  • [C-3-2] 5 つ以上のポインタ入力の個別トラッキング（指で手をトラッキング）を完全に独立してサポートしなければなりません。

7.2.6. ゲーム コントローラのサポート

7.2.6.1. ボタン マッピング

デバイス実装は:

  • [C-1-1] 下表に記載されているとおり、HID イベントを、対応する InputEvent 定数にマッピングできなければなりません。アップストリームの Android 実装はこの要件を満たしています。

コントローラを埋め込むか、下表に記載されているイベントすべての入力手段を提供する別個のコントローラを同梱する場合、デバイス実装は:

  • [C-2-1] android.hardware.gamepad 機能フラグを宣言しなければなりません。
ボタン HID 使用状況2 Android ボタン
A1 0x09 0x0001 KEYCODE_BUTTON_A（96）
B1 0x09 0x0002 KEYCODE_BUTTON_B（97）
X1 0x09 0x0004 KEYCODE_BUTTON_X（99）
Y1 0x09 0x0005 KEYCODE_BUTTON_Y（100）
D-pad 上1
D-pad 下1		 0x01 0x00393 AXIS_HAT_Y4
D-pad 左1
D-pad 右1		 0x01 0x00393 AXIS_HAT_X4
左ショルダーボタン1 0x09 0x0007 KEYCODE_BUTTON_L1（102）
右ショルダー ボタン1 0x09 0x0008 KEYCODE_BUTTON_R1（103）
左スティック クリック1 0x09 0x000E KEYCODE_BUTTON_THUMBL（106）
右スティック クリック1 0x09 0x000F KEYCODE_BUTTON_THUMBR（107）
戻る1 0x0c 0x0224 KEYCODE_BACK（4）

1 KeyEvent

2 上記の HID 使用状況は、ゲームパッド CA（0x01 0x0005）内で宣言しなければなりません。

3 この使用状況は、論理最小値 0、論理最大値 7、物理最小値 0、物理最大値 315、度単位、レポートサイズ 4 でなければなりません。論理値は、垂直軸から時計回りに定義されます。たとえば、論理値 0 は回転せず上ボタンが押されていることを表し、論理値 1 は 45 度回転し上キーと左キーの両方が押されていることを表します。

4 MotionEvent

アナログ コントロール1 HID 使用状況 Android ボタン
左トリガー 0x02 0x00C5 AXIS_LTRIGGER
右トリガー 0x02 0x00C4 AXIS_RTRIGGER
左ジョイスティック 0x01 0x0030
0x01 0x0031		 AXIS_X
AXIS_Y
右ジョイスティック 0x01 0x0032
0x01 0x0035		 AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. リモコン

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

7.3. センサー

サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプがデバイス実装に含まれる場合、デバイス実装は、センサーに関する Android SDK ドキュメントと Android オープンソース ドキュメントに記載されているとおり、その API を実装しなければなりません。

デバイス実装は:

  • [C-0-1] android.content.pm.PackageManager クラスごとにセンサーの有無を正確にレポートしなければなりません。
  • [C-0-2] SensorManager.getSensorList() や同様のメソッドを介してサポート対象のセンサーの正確なリストを返さなければなりません。
  • [C-0-3] 他のセンサー API すべてについて合理的に動作しなければなりません（たとえば、アプリがリスナーの登録を試行したとき true または false のうち該当する方を返す、対応するセンサーが存在しないときはセンサー リスナーを呼び出さない、など）。

サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプが含まれる場合、デバイス実装は:

  • [C-1-1] Android SDK ドキュメントで定義されているとおり、センサータイプごとに関連する国際単位系（メートル法）の値を使用して、すべてのセンサー測定値をレポートしなければなりません。
  • [C-1-2] アプリ プロセッサがアクティブなとき、最大要求レイテンシが 0 ms のセンサー ストリームの場合、最大レイテンシ 100 ミリ秒 + 2 * sample_time のセンサーデータをレポートしなければなりません。この遅延にフィルタリングの遅延は含まれません。
  • [C-1-3] センサーがアクティブになっている 400 ミリ秒 + 2 * sample_time 以内に最初のセンサー サンプルをレポートしなければなりません。このサンプルの正確度は 0 でも許容されます。
  • [C-1-4] 連続センサーであることが Android SDK ドキュメントで示されている API の場合、デバイス実装は、ジッターが 3% 未満であるべき定期データサンプルを継続的に提供しなければなりません（ジッターは、連続するイベント間でレポートされるタイムスタンプ値の標準偏差として定義されます）。
  • [C-1-5] デバイス CPU がサスペンド状態に入ること、またはサスペンド状態から復帰することを、センサー イベント ストリームが妨げてはならないということを保証しなければなりません。
  • [C-1-6] Android SDK ドキュメントで定義されているとおり、ナノ秒単位でイベント時刻をレポートしなければなりません。これはイベントが発生した時刻を表し、SystemClock.elapsedRealtimeNano() クロックと同期されています。
  • [C-SR-1] タイムスタンプ同期エラーが 100 ミリ秒未満であることが強く推奨され、タイムスタンプ同期エラーが 1 ミリ秒未満であるべきです。
  • 複数のセンサーが有効になっているとき、消費電力は、個々のセンサーがレポートした消費電力の合計を超えるべきではありません。

上記のリストは包括的なものではありません。センサーに関する Android SDK ドキュメントと Android オープンソース ドキュメントに記載されている動作を、信頼できるものとみなします。

サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプが含まれる場合、デバイス実装は:

  • [C-1-6] すべてのセンサーにゼロ以外の解像度を設定し、Sensor.getResolution() API メソッドを介して値をレポートしなければなりません。

一部のセンサータイプは複合型です。つまり、1 つ以上の他のセンサーによって提供されるデータから得られることがあります（方向センサーや直線加速度センサーなど）。

デバイス実装は:

  • センサータイプに記載されているとおり、必須の物理センサーを含む場合、これらのセンサータイプを実装すべきです。

複合センサーが含まれる場合、デバイス実装は:

  • [C-2-1] 複合センサーに関する Android オープンソース ドキュメントに記載されているとおり、センサーを実装しなければなりません。

サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプが含まれ、センサーが値を 1 つだけレポートする場合、デバイス実装は:

  • [C-3-1] センサーの解像度を 1 に設定し、Sensor.getResolution() API メソッドを介して値をレポートしなければなりません。

SensorAdditionalInfo#TYPE_VEC3_CALIBRATION をサポートする特定のセンサータイプが含まれ、センサーがサードパーティ デベロッパーに公開される場合、デバイス実装は:

  • [C-4-1] 提供されるデータに、出荷時に決定した固定の調整パラメータを含めてはなりません。

3 軸加速度計、3 軸ジャイロスコープ センサー、磁力計センサーの組み合わせが含まれる場合、デバイス実装は:

  • [C-SR-2] 加速度計、ジャイロスコープ、磁力計の相対位置が固定されるようにすることが強く推奨されます。これにより、デバイスが変形可能（折りたたみ式など）な場合、どのような状態に変形する可能性があっても、センサーの軸がセンサー座標系との整合性を保ちます。

7.3.1. 加速度計

デバイス実装は:

  • [C-SR-1] 3 軸加速度計を含めることが強く推奨されます。

加速度計が含まれる場合、デバイス実装は:

  • [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
  • [C-1-3] Android API で詳述されているとおり、Android センサー座標系に準拠しなければなりません。
  • [C-1-4] どの軸でも、自由落下から重力の 4 倍（4g）以上まで測定できなければなりません。
  • [C-1-5] 解像度が少なくとも 12 ビットでなければなりません。
  • [C-1-6] 標準偏差が 0.05 m/s^ 以下でなければなりません。標準偏差は、最速サンプリング レートで少なくとも 3 秒間にわたって収集されたサンプルについて、軸ごとに計算すべきです。
  • 少なくとも 200 Hz までのイベントをレポートすべきです。
  • 解像度が少なくとも 16 ビットであるべきです。
  • ライフサイクル中に特性が変化して補正される場合、使用中に調整すべきであり、デバイスが再起動される間も補正パラメータを保持すべきです。
  • 温度補正をすべきです。

3 軸加速度計が含まれる場合、デバイス実装は:

  • [C-2-1] TYPE_ACCELEROMETER センサーを実装し、レポートしなければなりません。
  • [C-SR-4] TYPE_SIGNIFICANT_MOTION 複合センサーを実装することが強く推奨されます。
  • [C-SR-5] TYPE_ACCELEROMETER_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。Android デバイスは、要求される可能性のある今後のプラットフォーム リリースにアップグレードできるよう、この要件を満たすことが強く推奨されます。
  • Android SDK ドキュメントに記載されているとおり、複合センサー TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER を実装すべきです。

3 軸未満の加速度計が含まれる場合、デバイス実装は:

  • [C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES センサーを実装し、レポートしなければなりません。
  • [C-SR-6] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。

3 軸加速度計が含まれ、TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER のいずれかの複合センサーが実装される場合、デバイス実装は:

  • [C-4-1] 消費電力の合計が常に 4 mW 未満でなければなりません。
  • デバイスが動的状態または静的状態にあるとき、それぞれ 2 mW 未満、0.5 mW 未満であるべきです。

3 軸加速度計と 3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:

  • [C-5-1] 複合センサー TYPE_GRAVITY と TYPE_LINEAR_ACCELERATION を実装しなければなりません。
  • [C-SR-7] TYPE_GAME_ROTATION_VECTOR 複合センサーを実装することが強く推奨されます。

3 軸加速度計、3 軸ジャイロスコープ センサー、磁力計センサーが含まれる場合、デバイス実装は:

  • [C-6-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

7.3.2. 磁力計

デバイス実装は:

  • [C-SR-1] 3 軸磁力計（コンパス）を含むことが強く推奨されます。

3 軸磁力計が含まれる場合、デバイス実装は:

  • [C-1-1] TYPE_MAGNETIC_FIELD センサーを実装しなければなりません。
  • [C-1-2] 少なくとも周波数が 10 Hz までのイベントをレポートできなければならず、少なくとも 50 Hz までのイベントをレポートすべきです。
  • [C-1-3] Android API で詳述されているとおり、Android センサー座標系を遵守しなければなりません。
  • [C-1-4] 飽和する前に各軸で -900 µT～+900 µT を測定できなければなりません。
  • [C-1-5] 磁力計を動的（電流誘導）磁場と静的（磁気誘導）磁場から離して配置することで、ハードアイアン オフセット値が 700 µT 未満でなければならず、200 µT 未満であるべきです。
  • [C-1-6] 解像度が 0.6 µT 以上でなければなりません。
  • [C-1-7] ハードアイアン バイアスのオンラインの調整と補正をサポートしなければならず、デバイスの再起動の間で補正パラメータを保持しなければなりません。
  • [C-1-8] ソフトアイアン補正を適用しなければなりません。調整は、デバイスの使用中または製造中に行うことができます。
  • [C-1-9] 標準偏差が、最速サンプリング レートで少なくとも 3 秒間にわたって収集されたサンプルについて軸ごとに計算して 1.5 µT 以下でなければならず、標準偏差が 0.5 µT 以下であるべきです。
  • [C-1-10] TYPE_MAGNETIC_FIELD_UNCALIBRATED センサーを実装しなければなりません。

3 軸磁力計、加速度計センサー、3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:

  • [C-2-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

3 軸磁力計、加速度計が含まれる場合、デバイス実装は:

  • TYPE_GEOMAGNETIC_ROTATION_VECTOR センサーを実装しても構いません。

3 軸磁力計、加速度計、TYPE_GEOMAGNETIC_ROTATION_VECTOR センサーが含まれる場合、デバイス実装は:

  • [C-3-1] 消費電力が 10 mW 未満でなければなりません。
  • センサーが 10 Hz でバッチモードに登録されている場合、消費電力が 3 mW 未満であるべきです。

7.3.3. GPS

デバイス実装は:

  • [C-SR-1] GPS / GNSS レシーバーを含むことが強く推奨されます。

GPS / GNSS レシーバーが含まれ、android.hardware.location.gps 機能フラグを通じてアプリに機能をレポートする場合、デバイス実装は:

  • [C-1-1] LocationManager#requestLocationUpdate を介してリクエストされたとき、少なくとも 1 Hz のレートでの位置情報出力をサポートしなければなりません。
  • [C-1-2] データ速度が 0.5 Mbps 以上のインターネット接続に接続したとき、全天条件下（信号強度が高く、マルチパスを無視でき、HDOP < 2）で、10 秒以内に位置を決定できなければなりません（初期位置算出時間が短い）。この要件は通常、GPS / GNSS ロックオン時間を最小限に抑えるための、なんらかの形の支援または予測 GPS / GNSS 技術を使用することで満たします（支援データには基準時間、基準位置、衛星エフェメリス / クロックが含まれます）。
    • [C-1-6] このような位置計算を行った後、デバイス実装は、位置情報のリクエストが再開されたとき、初期位置計算から最大 1 時間後まで、後続のリクエストがデータ接続なしで行われたときや、電源をオフにして再度オンにした後であっても、全天条件下で 5 秒以内に位置を決定しなければなりません。

  • 位置を決定した後、全天条件下で、静止しながら、または加速度 1 m/s2 未満で移動しながら:

    • [C-1-3] 少なくとも 95% の時間で、位置を 20 m 以内、速度を 0.5 m/s 以内で決定できなければなりません。
    • [C-1-4] GnssStatus.Callback を介して、1 つのコンステレーションから少なくとも 8 つの衛星を同時にトラック、レポートしなければなりません。
    • 複数のコンステレーションから少なくとも 24 の衛星を同時にトラックできるべきです（例: GPS と、Glonass、Beidou、Galileo のうち少なくとも 1 つ）。

  • [C-SR-2] 緊急通報の際も、GNSS Location Provider API を通じて通常の GPS / GNSS 位置情報出力を引き続き提供することが強く推奨されます。

  • [C-SR-3] SBAS を除き、トラックしたすべてのコンステレーションからの GNSS 測定値を（GnssStatus メッセージでレポートされたとおり）レポートすることが強く推奨されます。

  • [C-SR-4] AGC と、GNSS 測定頻度をレポートすることが強く推奨されます。

  • [C-SR-5] すべての正確度推定値（方位角、速度、垂直を含む）を、各 GPS / GNSS 位置情報の一部としてレポートすることが強く推奨されます。

  • [C-SR-6] GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GNSS 測定値が判明したらすぐにレポートすることが強く推奨されます。

  • [C-SR-7] 位置を決定した後、全天条件下で、静止しているか加速度 0.2 m/s2 未満で移動している間に、少なくとも 95% の時間で 20 m 以内の位置と 0.2 m/s 以内の速度を計算するのに十分な、GNSS の擬似距離と擬似距離レートをレポートすることが強く推奨されます。

7.3.4. ジャイロスコープ

デバイス実装は:

  • [C-SR-1] ジャイロスコープ センサーを含めることが強く推奨されます。

ジャイロスコープが含まれる場合、デバイス実装は:

  • [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
  • [C-1-4] 解像度が 12 ビット以上でなければなりません。
  • [C-1-5] 温度補正しなければなりません。
  • [C-1-6] 使用中に調整と補正を行わなければならず、デバイスの再起動の間で補正パラメータを保持しなければなりません。
  • [C-1-7] 分散が Hz あたり 1e-7 rad^2 / s^2（Hz あたりの分散または rad^2 / s）以下でなければなりません。分散はサンプリング レートによって異なることが許容されますが、この値の制約を受けなければなりません。つまり、サンプリング レート 1 Hz でジャイロの分散を測定した場合、1e-7 rad^2/s^2 以下であるべきです。
  • [C-SR-2] 補正誤差は、室温でデバイスが静止しているとき、0.01 rad/s 未満であることが強く推奨されます。
  • [C-SR-3] 解像度が 16 ビット以上であることが強く推奨されます。
  • 少なくとも 200 Hz までのイベントをレポートすべきです。

3 軸ジャイロスコープが含まれる場合、デバイス実装は:

  • [C-2-1] TYPE_GYROSCOPE センサーを実装しなければなりません。
  • [C-SR-4] TYPE_GYROSCOPE_UNCALIBRATED センサーを実装することが強く推奨されます。

3 軸未満のジャイロスコープが含まれる場合、デバイス実装は:

  • [C-3-1] TYPE_GYROSCOPE_LIMITED_AXES センサーを実装し、レポートしなければなりません。
  • [C-SR-5] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。

3 軸ジャイロスコープ、加速度計センサー、磁力計センサーが含まれる場合、デバイス実装は:

  • [C-4-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

3 軸加速度計と 3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:

  • [C-5-1] 複合センサー TYPE_GRAVITY と TYPE_LINEAR_ACCELERATION を実装しなければなりません。
  • [C-SR-6] TYPE_GAME_ROTATION_VECTOR 複合センサーを実装することが強く推奨されます。

7.3.5. 気圧計

デバイス実装は:

  • [C-SR-1] 気圧計（大気圧センサー）を含むことが強く推奨されます。

気圧計が含まれる場合、デバイス実装は:

  • [C-1-1] TYPE_PRESSURE センサーを実装し、レポートしなければなりません。
  • [C-1-2] 5 Hz 以上でイベントを配信できなければなりません。
  • [C-1-3] 温度補正しなければなりません。
  • [C-SR-2] 300 hPa から 1,100 hPa までの圧力測定値をレポートできることが強く推奨されます。
  • 絶対正確度が 1 hPa であるべきです。
  • 相対正確度が 20 hPa の範囲で 0.12 hPa であるべきです（海面における ~200 m の変化で正確度 ~1 m に相当）。

7.3.6. 温度計

周囲温度計（温度センサー）が含まれる場合、デバイス実装は:

  • [C-1-1] 周囲温度センサーについて SENSOR_TYPE_AMBIENT_TEMPERATURE を定義しなければならず、センサーは、ユーザーがデバイスを操作している場所の周囲温度（室温 / 車内温度）を摂氏で測定しなければなりません。

周囲温度以外の温度（CPU 温度など）を測定する温度計センサーが含まれる場合、デバイス実装は:

皮膚温をモニタリングするためのセンサーが含まれる場合、デバイス実装は:

7.3.7. 光度計

  • デバイス実装は、光度計（周囲光センサー）を含んでも構いません。

7.3.8. 近接センサー

  • デバイス実装は、近接センサーを含んでも構いません。

近接センサーが含まれ、2 成分の「遠」「近」読み取り値のみをレポートする場合、デバイス実装は:

  • [C-1-1] 画面と同じ向きで物体の近接を測定しなければなりません。つまり近接センサーは、画面の近くにある物体を検出するような向きでなければなりません。これは、スマートフォンをユーザーが使用中であることの検出が、この種のセンサーの主な目的であるためです。他の向きの近接センサーを含む場合、デバイス実装は、この API を通じてアクセス可能であってはなりません。
  • [C-1-2] 正確度が 1 ビット以上でなければなりません。
  • [C-1-3] 「近」読み取り値として 0 センチメートル、「遠」読み取り値として 5 センチメートルを使用しなければなりません。
  • [C-1-4] 最大範囲と解像度 5 をレポートしなければなりません。

7.3.9. ハイファイ センサー

このセクションで規定するとおり、高品質センサーのセットが含まれ、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

  • [C-1-1] android.hardware.sensor.hifi_sensors 機能フラグを通じて機能を識別しなければなりません。

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

  • [C-2-1] 次の条件を満たす TYPE_ACCELEROMETER センサーがなければなりません。

    • 測定範囲が少なくとも -8g～+8g でなければならず、測定範囲が少なくとも -16g～+16g であることが強く推奨されます。
    • 測定解像度が少なくとも 2,048 LSB/g でなければなりません。
    • 最小測定周波数が 12.5 Hz 以下でなければなりません。
    • 最大測定周波数が 400 Hz 以上でなければならず、SensorDirectChannel RATE_VERY_FAST をサポートすべきです。
    • 測定雑音が 400 μg/√Hz 以下でなければなりません。
    • 少なくとも 3,000 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • 計量消費電力が 3 mW 以下でなければなりません。
    • [C-SR-1] 3 dB 測定帯域幅がナイキスト周波数の少なくとも 80% であり、ホワイトノイズ スペクトルがこの帯域幅内であることが強く推奨されます。
    • 室温でテストして加速度ランダム ウォークが 30 μg √Hz 未満であるべきです。
    • 温度に対するバイアス変化が +/- 1 mg/°C 以下であるべきです。
    • 最良適合線が非線形で 0.5% 以下、温度に対する感度変化が 0.03%/C° 以下であるべきです。
    • デバイスの動作温度範囲で、直交軸感度が 2.5% 未満、直交軸感度の変動が 0.2% 未満であるべきです。

  • [C-2-2] TYPE_ACCELEROMETER_UNCALIBRATED の品質要件が TYPE_ACCELEROMETER と同じでなければなりません。

  • [C-2-3] 次の条件を満たす TYPE_GYROSCOPE センサーがなければなりません。

    • 測定範囲が少なくとも -1,000～+1,000 dps でなければなりません。
    • 測定解像度が少なくとも 16 LSB/dps でなければなりません。
    • 最小測定周波数が 12.5 Hz 以下でなければなりません。
    • 最大測定周波数が 400 Hz 以上でなければならず、SensorDirectChannel RATE_VERY_FAST をサポートすべきです。
    • 測定雑音が 0.014°/s/√Hz 以下でなければなりません。
    • [C-SR-2] 3 dB 測定帯域幅がナイキスト周波数の少なくとも 80% であり、ホワイトノイズ スペクトルがこの帯域幅内であることが強く推奨されます。
    • 室温でテストしてレートランダム ウォークが 0.001 °/s √Hz 未満であるべきです。
    • 温度に対するバイアス変化が +/- 0.05 °/ s / °C 以下であるべきです。
    • 温度に対する感度変化が 0.02% / °C 以下であるべきです。
    • 最良適合線が非線形で 0.2% 以下であるべきです。
    • 雑音密度が 0.007 °/s/√Hz 以下であるべきです。
    • デバイスが静止しているとき、温度範囲 10～40℃ で調整誤差が 0.002 rad/s 未満であるべきです。
    • 加速度感度が 0.1°/s/g 未満であるべきです。
    • デバイスの動作温度範囲で、直交軸感度が 4.0% 未満、直交軸感度の変動が 0.3% 未満であるべきです。

  • [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED の品質要件が TYPE_GYROSCOPE と同じでなければなりません。

  • [C-2-5] 次の条件を満たす TYPE_GEOMAGNETIC_FIELD センサーがなければなりません。

    • 測定範囲が少なくとも -900～+900 μT でなければなりません。
    • 測定解像度が少なくとも 5 LSB/uT でなければなりません。
    • 最小測定周波数が 5 Hz 以下でなければなりません。
    • 最大測定周波数が 50 Hz 以上でなければなりません。
    • 測定雑音が 0.5 uT 以下でなければなりません。

  • [C-2-6] TYPE_MAGNETIC_FIELD_UNCALIBRATED の品質要件が TYPE_GEOMAGNETIC_FIELD と同じでなければならず、さらに:

    • 少なくとも 600 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • [C-SR-3] レポートレートが 50 Hz 以上のとき、ホワイトノイズ スペクトラムが 1 Hz から少なくとも 10 Hz までであることが強く推奨されます。

  • [C-2-7] 次の条件を満たす TYPE_PRESSURE センサーがなければなりません。

    • 測定範囲が少なくとも 300～1,100 hPa でなければなりません。
    • 測定解像度が少なくとも 80 LSB/hPa でなければなりません。
    • 最小測定周波数が 1 Hz 以下でなければなりません。
    • 最大測定周波数が 10 Hz 以上でなければなりません。
    • 測定雑音が 2 Pa/√Hz 以下でなければなりません。
    • 少なくとも 300 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • 計量消費電力が 2 mW 以下でなければなりません。

  • [C-2-8] TYPE_GAME_ROTATION_VECTOR センサーがなければなりません。

  • [C-2-9] 次の条件を満たす TYPE_SIGNIFICANT_MOTION センサーがなければなりません。

    • 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。

  • [C-2-10] 次の条件を満たす TYPE_STEP_DETECTOR センサーがなければなりません。

    • 少なくとも 100 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
    • 計量消費電力が 4 mW 以下でなければなりません。

  • [C-2-11] 次の条件を満たす TYPE_STEP_COUNTER センサーがなければなりません。

    • 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。

  • [C-2-12] 次の条件を満たす TILT_DETECTOR センサーがなければなりません。

    • 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。

  • [C-2-13] 加速度計、ジャイロスコープ、磁力計がレポートする同じ物理イベントのイベント タイムスタンプが、互いに 2.5 ミリ秒以内でなければなりません。加速度計とジャイロスコープがレポートする同じ物理イベントのイベント タイムスタンプが、互いに 0.25 ミリ秒以内であるべきです。

  • [C-2-14] ジャイロスコープ センサーのイベント タイムスタンプがカメラ サブシステムと同じタイムベースであり、誤差 1 ミリ秒以内でなければなりません。

  • [C-2-15] 上記の物理センサーのいずれかでアプリがデータを利用できるようになった時点から 5 ミリ秒以内に、サンプルをアプリに配信しなければなりません。

  • [C-2-16] 次のセンサーの組み合わせが有効なとき、消費電力が、デバイス静止時は 0.5 mW を超えてはならず、デバイス移動時は 2.0 mW を超えてはなりません。

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] TYPE_PROXIMITY センサーがあっても構いませんが、存在する場合、少なくとも 100 件のセンサー イベントをバッファリングできなければなりません。

なお、このセクションの消費電力要件はすべて、アプリ プロセッサの消費電力を含みません。センサー チェーン全体（センサー、補助回路、専用のセンサー処理システムなど）によって消費される電力が含まれます。

ダイレクト センサー サポートが含まれる場合、デバイス実装は:

  • [C-3-1] isDirectChannelTypeSupported API と getHighestDirectReportRateLevel API を通じて、ダイレクト チャネルタイプとダイレクト レポート レートレベルのサポートを正しく宣言しなければなりません。
  • [C-3-2] センサー ダイレクト チャネルのサポートを宣言するすべてのセンサーについて、2 つのセンサー ダイレクト チャネルタイプのうち少なくとも 1 つをサポートしなければなりません。
  • 次のタイプのプライマリ センサー（非ウェイクアップ バリアント）のセンサー ダイレクト チャネルを通じたイベント レポートをサポートすべきです。
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生体認証センサー

生体認証によるロック解除のセキュリティの測定について詳しくは、生体認証を用いたロック解除のセキュリティ測定をご覧ください。

セキュアロック画面が含まれる場合、デバイス実装は:

  • 生体認証センサーを含むべきです。

生体認証センサーは、スプーフィング受け入れ率、なりすまし受け入れ率、生体認証パイプラインのセキュリティに基づいて、クラス 3（旧称「強」）、クラス 2（旧称「弱」）、クラス 1（旧称「利便性」）に分類できます。この分類によって、生体認証センサーがプラットフォームやサードパーティ アプリとインターフェースで接続する機能が決まります。センサーがクラス 1、クラス 2、クラス 3 に分類されるようにするには、以下のとおり追加の要件を満たす必要があります。クラス 2 とクラス 3 の生体認証には、以下の追加の機能があります。

android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt、android.provider.Settings.ACTION_BIOMETRIC_ENROLL を介してサードパーティ アプリで生体認証センサーを利用できるようにする場合、デバイス実装は:

  • [C-4-1] このドキュメントで規定するとおり、クラス 3 またはクラス 2 の生体認証の要件を満たさなければなりません。
  • [C-4-2] Authenticators クラスで定数として定義された各パラメータ名とそれらの組み合わせを認識し、使用しなければなりません。逆に、Authenticators でパブリック定数として記述されているもの以外の、canAuthenticate(int) メソッドと setAllowedAuthenticators(int) メソッドに渡された整数定数を使用または認識してはなりません。
  • [C-4-3] クラス 3 またはクラス 2 の生体認証を有するデバイスでは、ACTION_BIOMETRIC_ENROLL アクションを実装しなければなりません。このアクションは、クラス 3 またはクラス 2 の生体認証の登録エントリ ポイントのみを提示しなければなりません。

受動的生体認証をサポートする場合、デバイス実装は:

  • [C-5-1] デフォルトで追加の確認ステップ（ボタンの押下など）を要求しなければなりません。
  • [C-SR-1] ユーザーがアプリの設定を上書きできるように設定することが強く推奨され、常に確認ステップを伴うことが要求されます。
  • [C-SR-2] オペレーティング システムやカーネルの不正使用によってスプーフィングできないように、確認アクションをセキュアにすることが強く推奨されます。たとえば、物理ボタンに基づく確認アクションは、物理ボタンの押下以外では動作できないセキュア エレメント（SE）の入力専用の汎用入出力（GPIO）ピンを通じてルーティングされます。
  • [C-5-2] さらに、ログインフローで利用するようにアプリが設定できる、setConfirmationRequired（ブール値）に応じた暗黙的認証フローを実装しなければなりません。

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

新しい要件の開始

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

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

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

新しい要件の終了

  • [C-SR-3] 1 回の認証で確認される生体認証は 1 つのみとすることが強く推奨されます（例: デバイスで指紋センサーと顔センサーの両方が利用可能な場合、どちらかの認証が成功したら onAuthenticationSucceeded が送信されるべきです）。

サードパーティ アプリにキーストアキーへのアクセスを許可するために、デバイス実装は:

  • [C-6-1] このセクションで後述するとおり、クラス 3 の要件を満たさなければなりません。
  • [C-6-2] 認証で BIOMETRIC_STRONG が必要な場合、または認証が CryptoObject によって呼び出された場合は、クラス 3 の生体認証のみ提示しなければなりません。

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

  • [C-1-1] 他人受け入れ率が 0.002% 未満でなければなりません。
  • [C-1-2] このモードが強い PIN、パターン、またはパスワードよりもセキュアでない可能性があることを開示しなければならず、Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% を超える場合、このモードを有効にすることのリスクを明確に列挙しなければなりません。
  • [C-1-9] 生体認証が 20 回（またはそれ以下）失敗した場合、少なくとも 90 秒のバックオフ時間が経過してから、推奨される第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。ここで失敗とは、登録された生体認証に一致しないが、品質には問題がないキャプチャ（BIOMETRIC_ACQUIRED_GOOD）が使用された場合を指します。
  • [C-SR-4] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% を超える場合、[C-1-9] で規定されている、生体認証の失敗の最大回数を減らすことが強く推奨されます。
  • [C-1-3] 生体認証の試行回数をレート制限しなければなりません。ここで失敗とは、登録された生体認証に一致しないが、品質には問題がないキャプチャ（BIOMETRIC_ACQUIRED_GOOD）が使用された場合を指します。
  • [C-SR-5] [C-1-9] で規定されている生体認証の失敗の最大回数について、5 回の失敗の後は、少なくとも 30 秒間、レート制限することが強く推奨されます。ここで失敗とは、登録された生体認証に一致しないが、品質には問題がないキャプチャ（BIOMETRIC_ACQUIRED_GOOD）が使用された場合を指します。
  • [C-SR-6] TEE にすべてのレート制限ロジックがあることが強く推奨されます。

  • [C-1-10] セクション 9.11 の [C-0-2] に記載されているとおり、第 1 の認証のバックオフが初めてトリガーされたら、生体認証を無効にしなければなりません。

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

  • [C-1-4] TEE で保護された、既存のデバイス認証情報をユーザーに確認させることによる、または新しい認証情報（PIN、パターン、パスワード）をユーザーに追加させることによる信頼チェーンの確立を最初に行わずに、新しい生体認証を追加することは避けなければなりません。Android オープンソース プロジェクト実装は、そのためのフレームワークのメカニズムを提供します。

  • [C-1-5] ユーザーのアカウントが削除されたとき（初期状態にリセットした場合を含む）、ユーザーの識別可能なすべての生体認証データを完全に削除しなければなりません。

  • [C-1-6] その生体認証の個々のフラグを使用しなければなりません（例: DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE、DevicePolicymanager.KEYGUARD_DISABLE_IRIS）。

  • [C-1-7] 24 時間以内ごとに 1 回、推奨される第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。注: Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合は、72 時間以内ごとに 1 回、推奨される第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。

  • [C-1-8] 次のいずれかの後、推奨される第 1 の認証（PIN、パターン、パスワードなど）またはクラス 3（強）の生体認証をユーザーに求めなければなりません。

    • 4 時間のアイドル タイムアウト期間、または
    • 生体認証の試行に 3 回失敗。
    • アイドル タイムアウト期間と認証の失敗回数は、デバイス認証情報の確認に成功するとリセットされます。 注: Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合は、C-1-8 を免除しても構いません。

  • [C-SR-7] 新しいデバイスに [C-1-7] と [C-1-8] で規定する制約を適用するために、Android オープンソース プロジェクトで提供するフレームワークのロジックを使用することが強く推奨されます。

  • [C-SR-8] デバイスで測定したときの本人拒否率が 10% 未満であることが強く推奨されます。

  • [C-SR-9] 登録した生体認証ごとに、生体認証が検出されてから画面がロック解除されるまでのレイテンシが 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-2-1] 上記のクラス 1 の要件をすべて満たさなければなりません。

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

新しい要件の開始

  • [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-6] サードパーティ アプリで個々の生体認証登録を区別できるようにしてはなりません。
  • [C-2-7] TEE またはセクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine のコンテキスト外で、識別可能な生体認証データまたはそれから派生したデータ（埋め込みなど）への暗号化されていないアクセスを、アプリ プロセッサに許可してはなりません。Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合、C-2-7 は免除されません。

  • [C-2-8] オペレーティング・システムまたはカーネルの侵害によって、データを直接注入できてしまうことでユーザーとして誤って認証されることのないような、セキュアな処理パイプラインがなければなりません。注: デバイス実装が Android バージョン 9 以前ですでにリリースされており、システム ソフトウェア アップデートを通じて要件 C-2-8 を満たせない場合は、この要件を免除しても構いません。

  • [C-SR-10] すべての生体認証モダリティのための生体検出と、顔による生体認証のための視線検出を含むことが強く推奨されます。

  • [C-2-9] 生体認証センサーをサードパーティ アプリで利用できるようにしなければなりません。

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

  • [C-3-1] 上記のクラス 2 の要件をすべて満たさなければなりません（[C-1-7] と [C-1-8] を除く）。
  • [C-3-2] ハードウェア格納型キーストア実装がなければなりません。
  • [C-3-3] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% 以下でなければなりません。具体的には、（1）レベル A のプレゼンテーション攻撃手段（PAI）の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 7% 以下、（2）レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下でなければなりません。
  • [C-3-4] 72 時間以内ごとに 1 回、推奨される第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。
  • [C-3-5] デバイスでサポートされているすべてのクラス 3 生体認証が再登録された場合、認証システム ID を再生成しなければなりません。
  • [C-3-6] サードパーティ アプリに対し、生体認証によるキーストア鍵を有効にしなければなりません。

新しい要件の開始

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

新しい要件の終了

ディスプレイ内蔵指紋認証センサー（UDFPS）が含まれる場合、デバイス実装は:

  • [C-SR-11] UDFPS のタップ可能エリアが 3 ボタン ナビゲーションの妨げにならないようにすることが強く推奨されます（ユーザー補助で必要とするユーザーがいる可能性があります）。

7.3.11. 姿勢センサー

デバイス実装は:

  • 6 自由度の姿勢センサーをサポートしても構いません。

6 自由度の姿勢センサーをサポートする場合、デバイス実装は:

  • [C-1-1] TYPE_POSE_6DOF センサーを実装し、レポートしなければなりません。
  • [C-1-2] 回転ベクトルのみの場合よりも正確でなければなりません。

7.3.12. ヒンジ角度センサー

ヒンジ角度センサーをサポートする場合、デバイス実装は:

  • [C-1-1] TYPE_HINGLE_ANGLE を実装し、レポートしなければなりません。
  • [C-1-2] 0 度以上 360 度以下（すなわち 0 度と 360 度を含む）の、少なくとも 2 つの読み値をサポートしなければなりません。
  • [C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) について、wakeup センサーを返さなければなりません。

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. データ接続

7.4.1. 電話

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

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

  • Android は、電話ハードウェアを含まないデバイスで使用しても構いません。つまり、Android はスマートフォンではないデバイスに対応しています。

GSM または CDMA 電話が含まれる場合、デバイス実装は:

  • [C-1-1] android.hardware.telephony 機能フラグと、テクノロジーに応じて他のサブ機能フラグを宣言しなければなりません。
  • [C-1-2] そのテクノロジー向けの API の完全なサポートを実装しなければなりません。
  • 緊急通報の際、SetAllowedNetworkTypeBitmap() で設定したネットワークの種類にかかわらず、利用可能なすべてのモバイル サービスタイプ（2G、3G、4G、5G など）を許可すべきです。

電話ハードウェアが含まれない場合、デバイス実装は:

  • [C-2-1] 完全な API を NoOps として実装しなければなりません。

eUICCs または eSIM（埋め込み SIM）をサポートし、eSIM 機能をサードパーティ デベロッパーが利用できるようにする独自のメカニズムが含まれる場合、デバイス実装は:

システム プロパティ ro.telephony.iwlan\_operation\_mode を「legacy」に設定しない場合、デバイス実装は:

マルチメディア テレフォニー サービス（MMTEL）機能と Rich Communication Services（RCS）機能の両方について単一の IP マルチメディア サブシステム（IMS）登録をサポートし、すべての IMS シグナリング トラフィックに単一の IMS 登録を使用することに関する携帯通信会社の要件を遵守することが見込まれる場合、デバイス実装は:

機能 android.hardware.telephony をレポートする場合、デバイス実装は:

機能 android.hardware.telephony をレポートし、システムのステータスバーを提供する場合、デバイス実装は:

  • [C-7-1] SIM ステータス情報を提供するアフォーダンスで、特定のグループ UUID の代表的かつアクティブなサブスクリプションを選択し、ユーザーに表示しなければなりません。このようなアフォーダンスの例としては、ステータスバーの電波アイコンやクイック設定タイルなどがあります。
  • [C-SR-1] デバイスが音声通話中である場合を除き、代表的なサブスクリプションがアクティブなデータ サブスクリプションとして選択されるようにすることが強く推奨されます。デバイスが音声通話中の場合は、代表的なサブスクリプションがアクティブな音声サブスクリプションになるようにすることが強く推奨されます。

機能 android.hardware.telephony をレポートする場合、デバイス実装は:

  • [C-6-7] ETSI TS 102 221 に従い、UICC ごとに最大数の論理チャンネル（合計 20 個）を開いて同時に使用できなければなりません。
  • [C-6-8] ユーザーによる明示的な確認なしに、アクティブな携帯通信会社アプリ（TelephonyManager#getCarrierServicePackageName で指定）に以下の動作のいずれかを自動的に適用してはなりません。
    • ネットワーク アクセスを取り消す、または制限する
    • 権限を取り消す
    • バックグラウンドまたはフォアグラウンド アプリの実行を、AOSP に含まれる既存の電源管理機能の範囲を超えて制限する
    • アプリを無効にする、またはアンインストールする

デバイス実装が機能 android.hardware.telephony をレポートし、グループ UUID を共有するすべてのアクティブな非日和見サブスクリプションが無効にされている場合や、デバイスから物理的に削除されている場合、または「日和見的」とマークされている場合、デバイスは:

  • [C-8-1] 同じグループ内の残りのアクティブな日和見サブスクリプションをすべて自動的に無効にしなければなりません。

GSM 電話が含まれるが、CDMA 電話は含まれない場合、デバイス実装は:

  • [C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA を宣言してはなりません。
  • [C-9-2] 優先または許可されたネットワーク タイプのビットマスクで 3GPP2 ネットワーク タイプの設定が試みられたときに、IllegalArgumentException をスローしなければなりません。
  • [C-9-3] TelephonyManager#getMeid から空の文字列を返さなければなりません。

複数のポートとプロファイルを持つ eUICC をサポートする場合、デバイス実装は:

7.4.1.1. 番号ブロックの互換性

機能 android.hardware.telephony.calling をレポートする場合、デバイス実装は:

  • [C-1-1] 番号ブロックのサポートを含まなければなりません。
  • [C-1-2] SDK ドキュメントに記載されているとおり、BlockedNumberContract と、対応する API を完全に実装しなければなりません。

  • [C-1-3] アプリを操作せずに、「BlockedNumberProvider」の電話番号からの通話とメッセージをすべてブロックしなければなりません。唯一の例外は、SDK ドキュメントに記載されているとおり、番号ブロックが一時的に解除されている場合です。

  • [C-1-4] ブロックした通話について、プラットフォーム通話履歴プロバイダに書き込まなければなりません。また、プリインストールされている電話アプリのデフォルトの通話履歴ビューにある通話を、BLOCKED_TYPE でフィルタしなければなりません。

  • [C-1-5] ブロックしたメッセージについて、電話プロバイダに書き込んではなりません。

  • [C-1-6] TelecomManager.createManageBlockedNumbersIntent() メソッドから返されたインテントで開くブロック番号管理 UI を実装しなければなりません。

  • [C-1-7] Android プラットフォームは、プライマリ ユーザーがデバイスの電話サービス（単一インスタンス）を完全に管理することを前提としているため、デバイスでブロックした番号をセカンダリ ユーザーが表示または編集できるようにしてはなりません。ブロック関連の UI はすべてセカンダリ ユーザーに対して非表示にしなければならず、ブロックリストを引き続き尊重しなければなりません。

  • デバイスを Android 7.0 にアップデートするときは、ブロックした番号をプロバイダに移行すべきです。

  • プリインストールされている電話アプリにブロックした通話を表示するユーザー アフォーダンスを提供すべきです。

7.4.1.2. Telecom API

android.hardware.telephony.calling をレポートする場合、デバイス実装は:

  • [C-1-1] SDK に記載されている ConnectionService API をサポートしなければなりません。
  • [C-1-2] CAPABILITY_SUPPORT_HOLD を介して指定された保留機能をサポートしないサードパーティ アプリによる通話で、ユーザーが通話中のとき、新しい着信を表示し、着信を受け入れるか拒否するユーザー アフォーダンスを提供しなければなりません。
  • [C-1-3] アプリで InCallService を実装しなければなりません。

  • [C-SR-1] 着信に応答すると進行中の通話が途切れる旨をユーザーに通知することが強く推奨されます。

    AOSP 実装は、着信に応答すると他の通話が途切れることをユーザーに示すヘッドアップ通知によって、これらの要件を満たしています。

  • [C-SR-2] サードパーティ アプリが PhoneAccount の EXTRA_LOG_SELF_MANAGED_CALLS エクストラキーを true に設定したとき、通話履歴エントリとサードパーティ アプリ名を通話履歴に表示するデフォルトの電話アプリをプリロードすることが強く推奨されます。

  • [C-SR-3] android.telecom API について、オーディオ ヘッドセットの KEYCODE_MEDIA_PLAY_PAUSE イベントと KEYCODE_HEADSETHOOK イベントを下記のとおり処理することが強く推奨されます。

7.4.1.3. モバイル NAT-T キープアライブ オフロード

デバイス実装は:

  • モバイル キープアライブ オフロードのサポートを含むべきです。

モバイル キープアライブ オフロードのサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:

  • [C-1-1] SocketKeepAlive API をサポートしなければなりません。
  • [C-1-2] モバイル ネットワークで少なくとも 1 つの同時キープアライブ スロットをサポートしなければなりません。
  • [C-1-3] モバイル Radio HAL でサポートされている数だけ、同時モバイル キープアライブ スロットをサポートしなければなりません。
  • [C-SR-1] 無線インスタンスごとに少なくとも 3 つのモバイル キープアライブ スロットをサポートすることが強く推奨されます。

モバイル キープアライブ オフロードのサポートが含まれない場合、デバイス実装は:

  • [C-2-1] ERROR_UNSUPPORTED を返さなければなりません。

7.4.2. IEEE 802.11（Wi-Fi）

デバイス実装は:

  • 1 つ以上の 802.11 形式のサポートを含むべきです。

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

  • [C-1-1] 対応する Android API を実装しなければなりません。
  • [C-1-2] ハードウェア機能フラグ android.hardware.wifi をレポートしなければなりません。
  • [C-1-3] SDK ドキュメントに記載されているとおり、マルチキャスト API を実装しなければなりません。
  • [C-1-4] マルチキャスト DNS（mDNS）をサポートしなければならず、画面がアクティブ状態でないときを含むいかなる運用時にも mDNS パケット（224.0.0.251 または ff02::fb）をフィルタしてはなりません。ただし、ターゲット市場に適用される規制要件で要求されている消費電力の範囲内に収めるために、パケットをドロップまたはフィルタする必要がある場合を除きます。 Android テレビデバイス実装の場合、スタンバイ電力状態にあるとき。
  • [C-1-5] アプリ トラフィックに対してデフォルトで使用され、getActiveNetwork や registerDefaultNetworkCallback などの ConnectivityManager API メソッドによって返される、現在アクティブな Network を切り替えるための十分な指標として WifiManager.enableNetwork() API メソッド呼び出しを扱ってはなりません。つまり、Wi-Fi ネットワークがインターネット アクセスを提供していることが正常に検証された場合にのみ、他のネットワーク プロバイダが提供するインターネット アクセス（モバイルデータなど）を無効にしても構いません。
  • [C-1-6] ConnectivityManager.reportNetworkConnectivity() API メソッドが呼び出されたとき Network のインターネット アクセスを再度評価し、評価で現在の Network がインターネット アクセスを提供していないと判断されたら、インターネット アクセスを提供する他の利用可能なネットワーク（モバイルデータなど）に切り替えることが強く推奨されます。
  • [C-1-7] STA が接続されていないとき、各スキャンの開始時に 1 回、送信元 MAC アドレスと、プローブ リクエスト フレームのシーケンス番号をランダム化しなければなりません。
  • [C-1-8] 一貫した 1 つの MAC アドレスを使用しなければなりません（スキャンの途中で MAC アドレスをランダム化すべきではありません）。
  • [C-1-9] スキャンにおけるプローブ リクエスト間で、プローブ リクエストのシーケンス番号を通常どおり（順次）反復処理しなければなりません。
  • [C-1-10] スキャンの最後のプローブ リクエストと次のスキャンの最初のプローブ リクエストの間で、プローブ リクエストのシーケンス番号をランダム化しなければなりません。
  • [C-SR-1] 関連付け中と関連付け後、アクセス ポイント（AP）に対するすべての STA 通信に使用する送信元 MAC アドレスをランダム化することが強く推奨されます。
    • デバイスは、通信する SSID（Passpoint の FQDN）ごとに異なるランダムな MAC アドレスを使用しなければなりません。
    • デバイスは、ランダム化しないオプションとランダム化するオプションにより、SSID（Passpoint の FQDN）ごとのランダム化を制御するオプションを、ユーザーに提供しなければなりません。また、ランダム化する新しい Wi-Fi 設定のデフォルト モードを設定しなければなりません。
  • [C-SR-2] 作成する AP に、ランダムな BSSID を使用することが強く推奨されます。
    • AP が使用する SSID ごとに MAC アドレスをランダム化し、保持しなければなりません。
    • デバイスは、この機能を無効にするオプションをユーザーに提供しても構いません。このようなオプションを指定する場合は、ランダム化をデフォルトで有効にしなければなりません。

IEEE 802.11 規格で定義されているとおり Wi-Fi 省電力モードのサポートが含まれる場合、デバイス実装は:

  • WifiManager.createWifiLock() API と WifiManager.WifiLock.acquire() API を介してアプリが WIFI_MODE_FULL_HIGH_PERF ロックまたは WIFI_MODE_FULL_LOW_LATENCY ロックを取得し、ロックがアクティブであるときは必ず、Wi-Fi 省電力モードをオフにしなければなりません。
  • [C-3-2] デバイスが Wi-Fi 低レイテンシ ロック（WIFI_MODE_FULL_LOW_LATENCY）モードになっているときの、デバイスとアクセス ポイントの間の平均ラウンドトリップ レイテンシが、Wi-Fi 高パフォーマンス ロック（WIFI_MODE_FULL_HIGH_PERF）モードになっているときのレイテンシよりも小さくなければなりません。
  • [C-SR-3] 低レイテンシ ロック（WIFI_MODE_FULL_LOW_LATENCY）が取得されて有効になるときは必ず、Wi-Fi ラウンドトリップ レイテンシを最小限に抑えることが強く推奨されます。

Wi-Fi をサポートし、位置情報スキャンに Wi-Fi を使用する場合、デバイス実装は:

  • [C-2-1] WifiManager.isScanAlwaysAvailable API メソッドを通じて読み取った値を有効化 / 無効化するユーザー アフォーダンスを提供しなければなりません。
7.4.2.1. Wi-Fi Direct

デバイス実装は:

  • Wi-Fi Direct（Wi-Fi ピアツーピア）のサポートを含むべきです。

Wi-Fi Direct をサポートする場合、デバイス実装は:

  • [C-1-1] SDK ドキュメントに記載されているとおり、対応する Android API を実装しなければなりません。
  • [C-1-2] ハードウェア機能 android.hardware.wifi.direct をレポートしなければなりません。
  • [C-1-3] 通常の Wi-Fi 運用をサポートしなければなりません。
  • [C-1-4] Wi-Fi と Wi-Fi Direct の運用を同時にサポートしなければなりません。
  • [C-SR-1] 新たに形成されるすべての Wi-Fi Direct 接続の送信元 MAC アドレスをランダム化することが強く推奨されます。

デバイス実装は:

TDLS のサポートが含まれ、WiFiManager API で TDLS が有効になっている場合、デバイス実装は:

  • [C-1-1] WifiManager.isTdlsSupported を通じて TDLS のサポートを宣言しなければなりません。
  • 可能かつ有効な場合にのみ、TDLS を使用すべきです。
  • TDLS のパフォーマンスが Wi-Fi アクセス ポイントを通過する場合よりも悪くなる可能性がある場合は、TDLS を使用せず、なんらかのヒューリスティックを使用すべきです。
7.4.2.3. Wi-Fi Aware

デバイス実装は:

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

  • [C-1-1] SDK ドキュメントに記載されているとおり、WifiAwareManager API を実装しなければなりません。
  • [C-1-2] android.hardware.wifi.aware 機能フラグを宣言しなければなりません。
  • [C-1-3] Wi-Fi と Wi-Fi Aware の運用を同時にサポートしなければなりません。
  • [C-1-4] Wi-Fi Aware が有効になっているときは常に、30 分以下の間隔で Wi-Fi Aware 管理インターフェースのアドレスをランダム化しなければなりません。ただし、Aware レンジング オペレーションが進行中であるか、Aware データパスがアクティブである場合を除きます（データパスがアクティブである限り、通常はランダム化は行われません）。

セクション 7.4.2.5 に記載されているとおり Wi-Fi Aware と Wi-Fi Location のサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:

7.4.2.4. Wi-Fi Passpoint

802.11（Wi-Fi）のサポートが含まれる場合、デバイス実装は:

  • [C-1-1] Wi-Fi Passpoint のサポートを含まなければなりません。
  • [C-1-2] SDK ドキュメントに記載されているとおり、Passpoint 関連の WifiManager API を実装しなければなりません。
  • [C-1-3] IEEE 802.11u 規格、特に Generic Advertisement Service（GAS）や Access Network Query Protocol（ANQP）など、ネットワークの検出と選択に関連するものをサポートしなければなりません。
  • [C-1-4] android.hardware.wifi.passpoint 機能フラグを宣言しなければなりません。
  • [C-1-5] AOSP 実装に従い、Passpoint ネットワークを検出、照合、関連付けしなければなりません。
  • [C-1-6] Wi-Fi Alliance Passpoint R2 で規定されているとおり、デバイスのプロビジョニング プロトコルのサブセットのうち、少なくとも EAP-TTLS 認証と SOAP-XML をサポートしなければなりません。
  • [C-1-7] Hotspot 2.0 R3 仕様に記載されているとおり、AAA サーバー証明書を処理しなければなりません。
  • [C-1-8] Wi-Fi 選択ツールを通じたプロビジョニングのユーザー コントロールをサポートしなければなりません。
  • [C-1-9] 再起動後も永続的に Passpoint 設定を維持しなければなりません。
  • [C-SR-1] 利用規約への同意機能をサポートすることが強く推奨されます。
  • [C-SR-2] 場所情報機能をサポートすることが強く推奨されます。

グローバルで Passpoint を無効化するユーザー コントロール スイッチが提供されている場合、実装は:

  • [C-3-1] Passpoint をデフォルトで有効にしなければなりません。
7.4.2.5. Wi-Fi Location（Wi-Fi ラウンドトリップ時間 - RTT）

デバイス実装は:

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

  • [C-1-1] SDK ドキュメントに記載されているとおり、WifiRttManager API を実装しなければなりません。
  • [C-1-2] android.hardware.wifi.rtt 機能フラグを宣言しなければなりません。
  • [C-1-3] RTT が実行されている Wi-Fi インターフェースがアクセス ポイントに関連付けられていない間、実行される RTT バーストごとに、送信元 MAC アドレスをランダム化しなければなりません。
  • [C-1-4] 累積分布関数で計算して、68 パーセンタイル、80 MHz 帯域幅で、正確度が 2 メートル以内でなければなりません。
  • [C-SR-1] 累積分布関数で計算して、68 パーセンタイル、80 MHz 帯域幅で、正確度が 1.5 メートル以内でレポートすることが強く推奨されます。
7.4.2.6. Wi-Fi キープアライブ オフロード

デバイス実装は:

  • Wi-Fi キープアライブ オフロードのサポートを含むべきです。

Wi-Fi キープアライブ オフロードのサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:

  • [C-1-1] SocketKeepAlive API をサポートしなければなりません。
  • [C-1-2] Wi-Fi で少なくとも 3 つの同時キープアライブ スロットをサポートしなければなりません。

Wi-Fi キープアライブ オフロードのサポートが含まれない場合、デバイス実装は:

7.4.2.7. Wi-Fi Easy Connect（デバイス プロビジョニング プロトコル）

デバイス実装は:

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

7.4.2.8. エンタープライズ Wi-Fi サーバー証明書の検証

Wi-Fi サーバー証明書が検証されていない場合、または Wi-Fi サーバー ドメイン名が設定されていない場合、デバイス実装は:

7.4.2.9. 初回使用時の信頼（TOFU）

デバイス実装は、初回使用時の信頼（TOFU）をサポートし、ユーザーが WPA/WPA2/WPA3-Enterprise の設定を定義することを許可している場合:

  • [C-4-1] TOFU の使用を選択するオプションをユーザーに提供しなければなりません。

7.4.3. Bluetooth

Bluetooth オーディオ プロファイルをサポートする場合、デバイス実装は:

  • Advanced オーディオ コーデックと Bluetooth オーディオ コーデック（LDAC など）をサポートすべきです。

HFP、A2DP、AVRCP をサポートする場合、デバイス実装は:

  • 合計で少なくとも 5 つのデバイスの接続をサポートすべきです。

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

  • [C-1-1] Bluetooth 4.2 と Bluetooth LE データ長拡張をサポートしなければなりません。

Android は、Bluetooth と Bluetooth Low Energy をサポートしています。

Bluetooth と Bluetooth Low Energy のサポートが含まれる場合、デバイス実装は:

  • [C-2-1] 関連するプラットフォーム機能（それぞれ android.hardware.bluetooth、android.hardware.bluetooth_le）を宣言し、プラットフォーム API を実装しなければなりません。
  • デバイスに応じて、A2DP、AVRCP、OBEX、HFP など、関連する Bluetooth プロファイルを実装すべきです。

Bluetooth Low Energy（BLE）のサポートが含まれる場合、デバイス実装は:

  • [C-3-1] ハードウェア機能 android.hardware.bluetooth_le を宣言しなければなりません。
  • [C-3-2] SDK ドキュメントと android.bluetooth に記載されているとおり、GATT（汎用属性プロファイル）ベースの Bluetooth API を有効にしなければなりません。
  • [C-3-3] ScanFilter API クラスのフィルタリング ロジックが実装されているかどうかを示す BluetoothAdapter.isOffloadedFilteringSupported() の正しい値をレポートしなければなりません。
  • [C-3-4] Low Energy のアドバタイジングがサポートされているかどうかを示す BluetoothAdapter.isMultipleAdvertisementSupported() の正しい値をレポートしなければなりません。

  • [C-3-5] デバイスがアクティブに BLE を使用してスキャンまたはアドバタイズしている場合は、ユーザーのプライバシーを保護するために、15 分以下の解決可能なプライベート アドレス（RPA）タイムアウトを実装し、タイムアウト時にアドレスをローテーションしなければなりません。タイミング攻撃を防ぐために、タイムアウト間隔も 5 分から 15 分の間でランダム化しなければなりません。

  • ScanFilter API を実装するとき、Bluetooth チップセットに対するフィルタリング ロジックのオフロードをサポートすべきです。

  • Bluetooth チップセットに対するバッチスキャンのオフロードをサポートすべきです。

  • 少なくとも 4 スロットのマルチ アドバタイズメントをサポートすべきです。

Bluetooth LE をサポートし、位置情報スキャンに Bluetooth LE を使用する場合、デバイス実装は:

  • [C-4-1] システム API BluetoothAdapter.isBleScanAlwaysAvailable() を通じて読み取った値を有効化 / 無効化するユーザー アフォーダンスを提供しなければなりません。

Bluetooth LE を使用した補聴器の音声サポートに記載されているとおり、Bluetooth LE と補聴器プロファイルのサポートが含まれる場合、デバイス実装は:

Bluetooth と Bluetooth Low Energy のサポートが含まれる場合、デバイス実装は:

  • [C-6-1] リクエスト元アプリが現在のフォアグラウンド / バックグラウンド状態に基づいて正常に android.permission.ACCESS_FINE_LOCATION 権限チェックに合格する場合を除き、デバイスの位置情報を導出するために使用できる Bluetooth メタデータ（スキャン結果など）へのアクセスを制限しなければなりません。

デバイス実装に Bluetooth または Bluetooth Low Energy のサポートが含まれ、アプリ マニフェストに Bluetooth から位置情報を導出しないというデベロッパー宣言が含まれない場合、デバイス実装は:

BluetoothAdapter.isLeAudioSupported() API について true を返す場合、デバイス実装は:

  • [C-7-1] ユニキャスト クライアントをサポートしなければなりません。
  • [C-7-2] 2M PHY をサポートしなければなりません。
  • [C-7-3] LE 拡張アドバタイジングをサポートしなければなりません。
  • [C-7-4] CIG で少なくとも 2 つの CIS 接続をサポートしなければなりません。
  • [C-7-5] BAP ユニキャスト クライアント、CSIP セット コーディネーター、MCP サーバー、VCP コントローラ、CCP サーバーを同時に有効にしなければなりません。
  • [C-SR-1] HAP ユニキャスト クライアントを有効にすることが強く推奨されます。

BluetoothAdapter.isLeAudioBroadcastSourceSupported() API について true を返す場合、デバイス実装は:

  • [C-8-1] BIG で少なくとも 2 つの BIS リンクをサポートしなければなりません。
  • [C-8-2] BAP ブロードキャスト ソース、BAP ブロードキャスト アシスタントを同時に有効にしなければなりません。
  • [C-8-3] LE 定期アドバタイジングをサポートしなければなりません。

BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API について true を返す場合、デバイス実装は:

  • [C-9-1] PAST（Periodic Advertising Sync Transfer）をサポートしなければなりません。
  • [C-9-2] LE 定期アドバタイジングをサポートしなければなりません。

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

  • [C-10-1] 見通せる環境において ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した RSSI の 95% が、+/-9 dB 以内でなければなりません。

  • [C-10-2] 3 つのチャンネルそれぞれのアンテナ（複数使用されている場合）での測定値の 95% が、互いに +/-3 dB 以内になるように、チャンネルごとの偏差を低減するための Rx / Tx 調整を含まなければなりません。

  • [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 オフセットを測定し補正する必要があります。

プレゼンス キャリブレーションの要件で指定されている測定のセットアップ手順に沿うことが強く推奨されます。

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.4. 近距離無線通信

デバイス実装は:

  • 近距離無線通信（NFC）用の送受信機と関連ハードウェアを含むべきです。
  • [C-0-1] プロトコルに依存しないデータ表現形式をクラスが表すため、NFC のサポートが含まれないか、android.hardware.nfc 機能を宣言する場合であっても、android.nfc.NdefMessage API と android.nfc.NdefRecord API を実装しなければなりません。

NFC ハードウェアが含まれ、サードパーティ アプリで利用できるようにする予定の場合、デバイス実装は:

  • [C-1-1] android.content.pm.PackageManager.hasSystemFeature() メソッドから android.hardware.nfc 機能をレポートしなければなりません。
  • 下記の NFC 規格を介して NDEF メッセージの読み書きができなければなりません。
  • [C-1-2] 次の NFC 規格を介して、NFC フォーラムのリーダー / ライター（NFC フォーラムの技術仕様 NFCForum-TS-DigitalProtocol-1.0 で定義）として動作できなければなりません。
    • NfcA（ISO14443-3A）
    • NfcB（ISO14443-3B）
    • NfcF（JIS X 6319-4）
    • IsoDep（ISO 14443-4）
    • NFC フォーラムのタグタイプ 1、2、3、4、5（NFC フォーラムにより定義）

  • [C-SR-1] 次の NFC 規格を介して NDEF メッセージと元データを読み書きできることが強く推奨されます。なお、NFC 規格は「強く推奨」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。これらの規格は、このバージョンでは任意ですが、今後のバージョンでは必須となります。このバージョンの Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが極めて強く奨励されています。

  • [C-1-13] NFC 検出モードにあるとき、サポートされているすべての技術をポーリングしなければなりません。

  • 画面がアクティブ、ロック画面がロック解除された状態でデバイスが起動しているときは、NFC 検出モードになっているべきです。

  • Thinfilm NFC Barcode プロダクトのバーコードと URL（エンコードされている場合）の読み取りができるべきです。

なお、上記の JIS、ISO、NFC フォーラムの仕様について、一般公開されているリンクはありません。

Android は、NFC ホストカード エミュレーション（HCE）モードをサポートしています。

HCE（NfcA や NfcB） に対応した NFC コントローラ チップセットが含まれ、アプリ ID（AID）ルーティングをサポートする場合、デバイス実装は:

  • [C-2-1] android.hardware.nfc.hce 機能定数をレポートしなければなりません。
  • [C-2-2] Android SDK で定義されているとおり、NFC HCE API をサポートしなければなりません。

NfcF の HCE に対応した NFC コントローラ チップセットが含まれ、サードパーティ アプリ向けの機能を実装する場合、デバイス実装は:

  • [C-3-1] android.hardware.nfc.hcef 機能定数をレポートしなければなりません。
  • [C-3-2] Android SDK で定義されているとおり、NfcF カード エミュレーション API を実装しなければなりません。

このセクションに記載するとおり一般的な NFC サポートが含まれ、リーダー / ライターの役割で MIFARE 技術（MIFARE Classic、MIFARE Ultralight、NDEF on MIFARE Classic）をサポートする場合、デバイス実装は:

  • [C-4-1] Android SDK に記載されているとおり、対応する Android SDK を実装しなければなりません。
  • [C-4-2] android.content.pm.PackageManager.hasSystemFeature() メソッドから com.nxp.mifare 機能をレポートしなければなりません。なお、これは Android の標準の機能ではないため、android.content.pm.PackageManager クラスの定数としては表示されません。

7.4.5. ネットワーキング プロトコルと API

7.4.5.1. 最低限のネットワーク機能

デバイス実装は:

  • [C-0-1] 1 つ以上のデータ ネットワーク形式のサポートを含まなければなりません。具体的には、デバイス実装は、200 Kbit/sec 以上の能力を持つ、少なくとも 1 つのデータ標準のサポートを含まなければなりません。この要件を満たす技術の例としては、EDGE、HSPA、EV-DO、802.11g、イーサネット、Bluetooth PAN が挙げられます。
  • 物理的なネットワーク標準（イーサネットなど）がメインのデータ接続である場合、802.11（Wi-Fi）など、1 つ以上の一般的なワイヤレス データ標準のサポートを含むべきです。
  • 複数の形式のデータ接続を実装しても構いません。
7.4.5.2. IPv6

デバイス実装は:

  • [C-0-2] IPv6 ネットワーク スタックを含まなければならず、java.net.Socket や java.net.URLConnection などのマネージド API と、AF_INET6 ソケットなどのネイティブ API を使用した IPv6 通信をサポートしなければなりません。
  • [C-0-3] IPv6 をデフォルトで有効にしなければなりません。
    • IPv6 通信に IPv4 と同等の信頼性を確保しなければなりません。たとえば:
      • [C-0-4] Doze モードで IPv6 接続を維持しなければなりません。
      • [C-0-5] 少なくとも 180 秒の RA ライフタイムを使用する IPv6 準拠ネットワークで、レート制限によってデバイスの IPv6 接続が失われてはなりません。
  • [C-0-6] IPv6 ネットワークに接続されているときに、デバイスのローカル側でアドレスまたはポート変換を一切行うことなく、サードパーティ アプリに直接 IPv6 接続を提供しなければなりません。Socket#getLocalAddress や Socket#getLocalPort などのマネージド API と、getsockname() や IPV6_PKTINFO などの NDK API はどちらも、ネットワーク上でパケットを送受信するために実際に使用されインターネット（ウェブ）サーバーへの送信元の IP とポートとして認識される、IP アドレスとポートを返さなければなりません。

必要な IPv6 サポートレベルは、次の要件に示すように、ネットワークの種類によって異なります。

Wi-Fi をサポートする場合、デバイス実装は:

  • [C-1-1] Wi-Fi でのデュアルスタックと IPv6 のみのオペレーションをサポートしなければなりません。

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

  • [C-2-1] イーサネットでのデュアルスタックと IPv6 のみのオペレーションをサポートしなければなりません。

モバイルデータをサポートする場合、デバイス実装は:

  • [C-3-1] モバイル ネットワークでの IPv6 オペレーション（IPv6 のみ、場合によってはデュアルスタック）をサポートしなければなりません。

ネットワークの種類を複数サポートする場合（例: Wi-Fi とモバイルデータ）、デバイス実装は:

  • [C-4-1] デバイスが同時に複数の種類のネットワークに接続されているとき、上記の要件を各ネットワークで同時に満たさなければなりません。
7.4.5.3. キャプティブ ポータル

キャプティブ ポータルとは、インターネット アクセスにログインが必要なネットワークのことです。

android.webkit.Webview API の完全な実装を提供する場合、デバイス実装は:

  • [C-1-1] インテント ACTION_CAPTIVE_PORTAL_SIGN_IN を処理し、システム API ConnectivityManager#startCaptivePortalApp(Network, Bundle) の呼び出しでそのインテントを送信することでキャプティブ ポータル ログインページを表示するための、キャプティブ ポータルアプリを提供しなければなりません。
  • [C-1-2] デバイスが、モバイル ネットワーク、Wi-Fi、イーサネット、Bluetooth を含む任意の種類のネットワークに接続されているとき、キャプティブ ポータルの検出を行い、キャプティブ ポータルアプリを通じたログインをサポートしなければなりません。
  • [C-1-3] デバイスがプライベート DNS の厳格モードを使用するように設定されている場合、平文 DNS を使用したキャプティブ ポータルへのログインをサポートしなければなりません。
  • [C-1-4] キャプティブ ポータルと明示的に通信していないすべてのネットワーク トラフィックについて、android.net.LinkProperties.getPrivateDnsServerName と android.net.LinkProperties.isPrivateDnsActive の SDK ドキュメントに従い、暗号化 DNS を使用しなければなりません。
  • [C-1-5] ユーザーがキャプティブ ポータルにログインしている間、アプリが使用するデフォルト ネットワーク（ConnectivityManager.getActiveNetwork、ConnectivityManager.registerDefaultNetworkCallback によって返され、java.net.Socket などの Java ネットワーキング API と、connect() などのネイティブ API がデフォルトで使用）が、インターネット アクセスを提供する他の利用可能なネットワークになるようにしなければなりません（利用可能な場合）。

7.4.6. 同期設定

デバイス実装は:

  • [C-0-1] メソッド getMasterSyncAutomatically() が「true」を返すように、マスター自動同期設定をデフォルトでオンにしなければなりません。

7.4.7. データセーバー

従量制接続が含まれる場合、デバイス実装は:

  • [C-SR-1] データセーバー モードを提供することが強く推奨されます。

データセーバー モードを提供する場合、デバイス実装は:

  • [C-1-1] SDK ドキュメントに記載されているとおり、ConnectivityManager クラスの API をすべてサポートしなければなりません。

データセーバー モードを提供しない場合、デバイス実装は:

  • [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() について値 RESTRICT_BACKGROUND_STATUS_DISABLED を返さなければなりません。
  • [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED をブロードキャストしてはなりません。

7.4.8. セキュア エレメント

Open Mobile API 対応のセキュア エレメントをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

7.4.9. UWB

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

  • [C-1-1] 対応する Android API を android.uwb に実装しなければなりません。
  • [C-1-2] ハードウェア機能フラグ android.hardware.uwb をレポートしなければなりません。
  • [C-1-3] Android 実装で定義されている関連する UWB プロファイルをすべてサポートしなければなりません。
  • [C-1-4] ユーザーが UWB 無線のオン / オフの状態を切り替えられるようにするユーザー アフォーダンスを提供しなければなりません。
  • [C-1-5] UWB 無線を使用するアプリが（NEARBY_DEVICES 権限グループの下で）UWB_RANGING 権限を保持するようにしなければなりません。
  • [C-SR-1] FIRA、CCC、CSA などの標準化団体によって定義されている、関連する適合性および認証テストに合格することが強く推奨されます。
  • [C-1-6] 見通せる環境において、無反射チャンバー内の 1 m の距離で測定した測定値の 95% で、距離の測定値が +/-15 cm 以内になるようにしなければなりません。
  • [C-1-7] 参照デバイスから 1 m の距離で測定した値の中央値が [0.75 m, 1.25 m] 以内になるようにしなければなりません。この場合、グラウンド トゥルースの距離は、上を向けて 45 度傾けた DUT の上端から測定します。
  • [C-SR-2] プレゼンス キャリブレーションの要件で指定されている測定のセットアップ手順に沿うことが強く推奨されます。

7.5. カメラ

カメラが 1 つ以上含まれる場合、デバイス実装は:

  • [C-1-1] android.hardware.camera.any 機能フラグを宣言しなければなりません。
  • [C-1-2] カメラが基本的なプレビューのために開かれ、引き続きキャプチャしているとき、デバイス上の最大解像度のカメラセンサーによって生成された画像のサイズに等しい 3 つの RGBA_8888 ビットマップを、アプリが同時に割り当てることができなければなりません。
  • [C-1-3] 受信アプリに ACCESS_FINE_LOCATION がない場合、インテント MediaStore.ACTION_IMAGE_CAPTURE、MediaStore.ACTION_IMAGE_CAPTURE_SECURE、または MediaStore.ACTION_VIDEO_CAPTURE を処理するプリインストールのデフォルト カメラアプリが、画像メタデータ内のユーザー位置情報を削除してから受信アプリに送信するようにしなければなりません。

HDR 10 ビット出力機能をサポートする場合、デバイス実装は:

  • [C-2-1] 10 ビット出力をサポートするすべてのカメラデバイスで、少なくとも HLG HDR プロファイルをサポートしなければなりません。
  • [C-2-2] プライマリ背面カメラまたはプライマリ前面カメラのいずれかで 10 ビット出力をサポートしなければなりません。
  • [C-SR-1] 両方のプライマリ カメラで 10 ビット出力をサポートすることが強く推奨されます。
  • [C-2-3] 論理カメラのすべての BACKWARD_COMPATIBLE 対応物理サブカメラと、論理カメラ自体について、同じ HDR プロファイルをサポートしなければなりません。

android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API を実装する 10 ビット HDR をサポートする論理カメラデバイスは:

  • [C-3-1] 論理カメラの CONTROL_ZOOM_RATIO コントロールを介して、下位互換性のあるすべての物理カメラの切り替えをサポートしなければなりません。

7.5.1. 背面カメラ

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

新しい要件の開始

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

新しい要件の終了

デバイス実装は:

  • 背面カメラを含むべきです。

背面カメラが 1 つ以上含まれる場合、デバイス実装は:

  • [C-1-1] 機能フラグ android.hardware.camera と android.hardware.camera.any をレポートしなければなりません。
  • [C-1-2] 解像度が少なくとも 2 メガピクセルでなければなりません。
  • カメラドライバでハードウェア オートフォーカスまたはソフトウェア オートフォーカスを実装すべきです（アプリ ソフトウェアに対して透過的）。
  • 固定フォーカスまたは EDOF（拡張被写界深度）のハードウェアがあっても構いません。
  • フラッシュを含んでも構いません。

カメラにフラッシュが含まれる場合:

  • [C-2-1] アプリが Camera.Parameters オブジェクトの FLASH_MODE_AUTO または FLASH_MODE_ON 属性を有効にすることでフラッシュを明示的に有効にしている場合を除き、android.hardware.Camera.PreviewCallback インスタンスがカメラ プレビュー サーフェスに登録されている間は、フラッシュ ランプが点灯してはなりません。なお、この制約は、デバイスの内蔵システム カメラアプリには適用されず、Camera.PreviewCallback を使用するサードパーティ アプリにのみ適用されます。

7.5.2. 前面カメラ

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

新しい要件の開始

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

新しい要件の終了

デバイス実装は:

  • 前面カメラを含んでも構いません。

前面カメラが 1 つ以上含まれる場合、デバイス実装は:

  • [C-1-1] 機能フラグ android.hardware.camera.any と android.hardware.camera.front をレポートしなければなりません。
  • [C-1-2] 解像度が少なくとも VGA（640x480 ピクセル）でなければなりません。
  • [C-1-3] 前面カメラを Camera API のデフォルトとして使用してはならず、たとえデバイス上の唯一のカメラであったとしても、前面カメラをデフォルトの背面カメラとして扱うように API を設定してはなりません。
  • [C-1-4] 現在のアプリが android.hardware.Camera.setDisplayOrientation() メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的にリクエストした場合、カメラ プレビューは、アプリが指定した画面の向きに対して水平方向にミラーリングされなければなりません。逆に、現在のアプリが android.hardware.Camera.setDisplayOrientation() メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的にリスエストしなかった場合、カメラ プレビューは、デバイスのデフォルトの水平軸に沿ってミラーリングされなければなりません。
  • [C-1-5] アプリのコールバックに対して返されたか、メディア ストレージに対してコミットされた、キャプチャした最終的な静止画または動画のストリームをミラーリングしてはなりません。
  • [C-1-6] カメラ プレビューの画像ストリームと同じ方法で、ポストビューで表示される画像をミラーリングしなければなりません。
  • セクション 7.5.1 に記載されているとおり、背面カメラで利用できる機能（オートフォーカス、フラッシュなど）を含めても構いません。

デバイス実装が、ユーザーによって回転できる場合（たとえば、加速度計を介して自動的に、またはユーザー入力を介して手動で）:

  • [C-2-1] カメラ プレビューは、デバイスの現在の画面の向きに対して水平方向にミラーリングされなければなりません。

7.5.3. 外部カメラ

新しい要件の開始

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

新しい要件の終了

デバイス実装は:

  • 常に接続されているとは限らない外部カメラのサポートを含むべきです。

外部カメラのサポートが含まれる場合、デバイス実装は:

  • [C-1-1] プラットフォーム機能フラグ android.hardware.camera.external と android.hardware camera.any を宣言しなければなりません。
  • [C-1-2] 外部カメラが USB ホストポートを通じて接続される場合、USB ビデオクラス（UVC 1.0 以上）をサポートしなければなりません。
  • [C-1-3] 物理的な外部カメラデバイスが接続された状態でカメラ CTS テストに合格しなければなりません。カメラ CTS テストの詳細については、source.android.com をご覧ください。
  • 高品質な未エンコード ストリーム（つまり、未加工または個別に圧縮された画像ストリーム）の転送を可能にするために、MJPEG のような動画圧縮をサポートすべきです。
  • 複数のカメラをサポートしても構いません。
  • カメラベースの動画エンコードをサポートしても構いません。

カメラベースの動画エンコードがサポートされる場合:

  • [C-2-1] 同時未エンコード / MJPEG ストリーム（解像度 QVGA 以上）が、デバイス実装にアクセス可能でなければなりません。

7.5.4. カメラ API の動作

Android には、カメラにアクセスするための API パッケージが 2 つあります。新しい android.hardware.camera2 API は、下位レベルのカメラ制御をアプリに公開します。これには、効率的なゼロコピー バースト / ストリーミング フローと、フレームごとの露出、ゲイン、ホワイト バランスゲイン、色変換、ノイズ除去、シャープニングの制御が含まれます。

古い API パッケージ android.hardware.Camera は、Android 5.0 でサポートが終了しましたが、引き続きアプリでの使用はできるはずです。Android デバイス実装は、このセクションと Android SDK に記載されているとおり、API の継続的なサポートを保証しなければなりません。

サポートが終了した android.hardware.Camera クラスと新しい android.hardware.camera2 パッケージに共通する機能はすべて、両方の API でパフォーマンスと品質が同等でなければなりません。たとえば、同等の設定では、オートフォーカスの速度と正確度が同じでなければならず、キャプチャした画像の品質も同じでなければなりません。2 つの API の異なるセマンティクスに依存する機能は、速度または品質が一致する必要はありませんが、可能な限り近づけるべきです。

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

  • [C-0-1] アプリが android.hardware.Camera.Parameters.setPreviewFormat(int) を一度も呼び出したことがない場合、アプリのコールバックに提供されるプレビュー データに android.hardware.PixelFormat.YCbCr_420_SP を使用しなければなりません。
  • [C-0-2] さらに、アプリが android.hardware.Camera.PreviewCallback インスタンスを登録し、システムが onPreviewFrame() メソッドを呼び出すときは NV21 エンコード形式でなければならず、プレビュー形式は YCbCr_420_SP（onPreviewFrame() に渡される byte[] のデータ）です。つまり、NV21 がデフォルトでなければなりません。
  • [C-0-3] android.hardware.Camera の前面カメラと背面カメラ両方のカメラ プレビュー用に、YV12 形式（android.graphics.ImageFormat.YV12 定数で表されます）をサポートしなければなりません（ハードウェア動画エンコーダとカメラは任意のネイティブ ピクセル形式を使用できますが、デバイス実装は YV12 への変換をサポートしなければなりません）。
  • [C-0-4] android.request.availableCapabilities で REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 機能をアドバタイズする android.hardware.camera2 デバイスについて、android.media.ImageReader API を通じた出力として android.hardware.ImageFormat.YUV_420_888 形式と android.hardware.ImageFormat.JPEG 形式をサポートしなければなりません。
  • [C-0-5] デバイスにハードウェア オートフォーカスなどの機能があるかどうかにかかわらず、引き続き Android SDK ドキュメントに含まれるカメラ API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、（オートフォーカスのないカメラには関係がなくとも）登録された android.hardware.Camera.AutoFocusCallback インスタンスを引き続き呼び出さなければなりません。なお、これは前面カメラに適用されます。たとえば、前面カメラはたいていの場合オートフォーカスをサポートしていませんが、それでも前述のように API コールバックを「偽装」しなければなりません。
  • [C-0-6] android.hardware.Camera.Parameters クラスと android.hardware.camera2.CaptureRequest クラスで定数として定義された各パラメータ名を認識し、使用しなければなりません。逆に、デバイス実装は android.hardware.Camera.Parameters で定数として記述されているもの以外の、android.hardware.Camera.setParameters() メソッドに渡された文字列定数を使用または認識してはなりません。つまりデバイス実装は、ハードウェアが許すならば標準的なカメラ パラメータをすべてサポートしなければならず、カスタムのカメラ パラメータ タイプをサポートしてはなりません。たとえば、ハイ ダイナミック レンジ（HDR）画像処理手法を使用する画像キャプチャをサポートするデバイス実装は、カメラ パラメータ Camera.SCENE_MODE_HDR をサポートしなければなりません。
  • [C-0-7] Android SDK に記載されているとおり、android.info.supportedHardwareLevel プロパティで適切なサポートレベルをレポートし、該当するフレームワーク機能フラグをレポートしなければなりません。
  • [C-0-8] また、android.request.availableCapabilities プロパティを介して android.hardware.camera2 の個々のカメラ機能を宣言し、該当する機能フラグを宣言しなければなりません。装着されているカメラデバイスのいずれかが機能をサポートしている場合は機能フラグを定義しなければなりません。
  • [C-0-9] カメラで新しい画像が撮影され、画像のエントリがメディアストアに追加されたときは常に、Camera.ACTION_NEW_PICTURE インテントをブロードキャストしなければなりません。
  • [C-0-10] カメラで新しい動画が撮影され、画像のエントリがメディアストアに追加されたときは常に、Camera.ACTION_NEW_VIDEO インテントをブロードキャストしなければなりません。
  • [C-0-11] サポートが終了した android.hardware.Camera API を介してアクセス可能なすべてのカメラが、android.hardware.camera2 API を介してもアクセス可能でなければなりません。
  • [C-0-12] 顔の外見が変更されないことを保証しなければなりません。これには、android.hardware.camera2 または android.hardware.Camera API のために、顔の形状、顔の肌の色、顔の肌の滑らかさを変更することが含まれますが、これらに限定されません。
  • [C-SR-1] 複数の RGB カメラが近接していて同じ方向を向いているデバイスでは、物理サブデバイスとしてその方向を向いているすべての RGB カメラで構成された、機能 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA をリストする論理カメラデバイスをサポートすることが強く推奨されます。

カメラ API をサードパーティ アプリに提供する場合、デバイス実装は:

7.5.5. カメラの向き

デバイス実装に前面カメラまたは背面カメラがある場合、そのようなカメラは:

  • [C-1-1] カメラの長辺が画面の長辺と一致するような向きにしなければなりません。つまり、デバイスが横向きで保持されている場合、カメラは横向きで画像をキャプチャしなければなりません。これは、デバイスの自然な向きに関係なく適用されます。つまり、横向き主体のデバイスと、縦向き主体のデバイスに適用されます。

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

  • デバイスは、折りたたみ式ディスプレイやヒンジ式ディスプレイなど、形状が変わる画面を実装している。
  • デバイスの折りたたみ状態やヒンジ状態が変化すると、デバイスは、縦向きメインと横向きメインの画面の向きの間で切り替わる。

新しい要件の開始

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

新しい要件の終了

7.6. メモリとストレージ

7.6.1. 最小のメモリとストレージ

デバイス実装は:

  • [C-0-1] アプリがデータファイルをダウンロードするために使用しても構わないダウンロード マネージャーを含まなければならず、サイズが少なくとも 100 MB である個々のファイルをデフォルトの「キャッシュ」場所にダウンロードできなければなりません。

7.6.2. アプリ共有ストレージ

デバイス実装は:

  • [C-0-1] アプリによって共有されるストレージ（「共有外部ストレージ」、「アプリ共有ストレージ」ともいいます）、またはマウント先の Linux のパス「/sdcard」で共有されるストレージを提供しなければなりません。
  • [C-0-2] ストレージが内部ストレージ コンポーネントに実装されているか、リムーバブル ストレージ メディア（SD カードスロットなど）に実装されているかにかかわらず、デフォルトでマウントされている（つまり「すぐに使える」）共有ストレージを使用して構成しなければなりません。
  • [C-0-3] アプリ共有ストレージを Linux パス sdcard に直接マウントするか、sdcard から実際のマウント ポイントへの Linux シンボリック リンクを含まなければなりません。
  • [C-0-4] 次の状況を除き、API レベル 29 以降をターゲットとするすべてのアプリについて、デフォルトで対象範囲別ストレージを有効にしなければなりません。
    • アプリがマニフェストで android:requestLegacyExternalStorage="true" をリクエストしているとき。
  • [C-0-5] メディア ファイルが MediaStore を通じてアクセスされる場合、ファイルに格納されている GPS Exif タグなどの位置情報メタデータを削除しなければなりません（呼び出し元アプリが ACCESS_MEDIA_LOCATION 権限を保持している場合を除きます）。

デバイス実装は、次のいずれかを使用して上記の要件を満たしても構いません。

  • SD カードスロットなど、ユーザーがアクセス可能なリムーバブル ストレージ。
  • Android オープンソース プロジェクト（AOSP）で実装されている内部（非リムーバブル）ストレージの一部。

上記の要件を満たすためにリムーバブル ストレージを使用する場合、デバイス実装は:

  • [C-1-1] スロットにストレージ メディアが挿入されていないときにユーザーに警告する、トーストまたはポップアップのユーザー インターフェースを実装しなければなりません。
  • [C-1-2] FAT フォーマットしたストレージ メディア（SD カードなど）を含むか、ストレージ メディアを別途購入する必要がある旨を箱または購入時に入手可能な他の資料に表示しなければなりません。

上記の要件を満たすために取り外し不可能なストレージの一部を使用する場合、デバイス実装は:

  • 内部アプリ共有ストレージの AOSP 実装を使用すべきです。
  • 保存容量をアプリの個人データと共有しても構いません。

USB ペリフェラル モードをサポートする USB ポートがある場合、デバイス実装は:

  • [C-3-1] ホスト コンピュータからアプリ共有ストレージのデータにアクセスするためのメカニズムを提供しなければなりません。
  • Android のメディア スキャナ サービスと android.provider.MediaStore を通じて、両方のストレージパスからのコンテンツを透過的に公開すべきです。
  • USB マスストレージを使用しても構いませんが、メディア転送プロトコルを使用してこの要件を満たすべきです。

USB ペリフェラル モードの USB ポートがあり、メディア転送プロトコルをサポートする場合、デバイス実装は:

  • リファレンス Android MTP ホスト Android File Transfer と互換性があるべきです。
  • USB デバイスクラス 0x00 をレポートすべきです。
  • USB インターフェース名「MTP」をレポートすべきです。

7.6.3. Adoptable Storage

テレビとは異なり、デバイスにモバイルとしての性質があることが想定される場合、デバイス実装は:

  • [C-SR-1] 誤って接続解除するとデータの損失 / 破損が生じるおそれがあるため、Adoptable Storage を長期的に安定した場所に実装することが強く推奨されます。

リムーバブル ストレージ デバイスのポートが、バッテリー収納部やその他の保護カバー内など、長期的に安定した場所にある場合、デバイス実装は:

7.7. USB

USB ポートがある場合、デバイス実装は:

  • USB ペリフェラル モードをサポートすべきであり、USB ホストモードをサポートすべきです。
  • USB でのデータ シグナリングの無効化をサポートすべきです。

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

デバイス実装に、ペリフェラル モードをサポートする USB ポートが含まれる場合:

  • [C-1-1] ポートは、標準の Type-A または Type-C の USB ポートを持つ USB ホストに接続可能でなければなりません。
  • [C-1-2] android.os.Build.SERIAL を通じて、USB 標準デバイス記述子で iSerialNumber の正しい値をレポートしなければなりません。
  • [C-1-3] Type-C 抵抗規格に従った 1.5 A と 3.0 A の充電器を検出しなければならず、Type-C USB をサポートする場合はアドバタイズメントの変更を検出しなければなりません。
  • [C-SR-1] ポートは Micro-B、Micro-AB、または Type-C の USB フォーム ファクタを使用すべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
  • [C-SR-2] ポートは、デバイスのポートが下向きのときディスプレイが正しく描画されるように、（自然な向きに合わせて）デバイスの底部に配置するか、すべてのアプリ（ホーム画面を含む）でソフトウェアの画面回転を可能にすべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
  • [C-SR-3] USB Battery Charging Specification, Revision 1.2 で規定されているとおり、HS チャープ、トラフィックの際に 1.5 A の電流を流すためのサポートを実装すべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
  • [C-SR-4] 標準の USB Power Delivery の方法をサポートする充電器またはデバイスとの間に相互運用性の問題が生じるおそれがあるため、デフォルト レベルを超えて Vbus 電圧を変更する、またはシンク / ソースの役割を変更する独自の充電方法をサポートしないことが強く推奨されます。これは「強く推奨」となっていますが、今後の Android バージョンでは、標準的な Type-C 充電器との完全な相互運用性をサポートすることが、すべての Type-C デバイスで必須となる可能性があります。
  • [C-SR-5] Type-C USB と USB ホストモードをサポートしている場合、データと電源の役割を入れ替えるために Power Delivery をサポートすることが強く推奨されます。
  • 高電圧充電のために Power Delivery をサポートし、ディスプレイ出力のような代替モードをサポートすべきです。
  • Android SDK ドキュメントに記載されているとおり、Android Open Accessory（AOA）の API と仕様を実装すべきです。

USB ポートが含まれ、AOA 仕様を実装する場合、デバイス実装は:

  • [C-2-1] ハードウェア機能 android.hardware.usb.accessory のサポートを宣言しなければなりません。
  • [C-2-2] USB マスストレージ クラスは、USB マスストレージのインターフェース記述 iInterface 文字列の末尾に文字列「android」を含まなければなりません。

7.7.2. USB ホストモード

ホストモードをサポートする USB ポートが含まれる場合、デバイス実装は:

  • [C-1-1] Android SDK に記載されているとおり Android USB ホスト API を実装しなければならず、ハードウェア機能 android.hardware.usb.host のサポートを宣言しなければなりません。
  • [C-1-2] 標準的な USB 周辺機器の接続のサポートを実装しなければなりません。つまり下記のいずれかでなければなりません。
    • デバイス上に Type-C ポートを備えるか、デバイス上の専用ポートを標準的な USB Tape-C ポート（USB Type-C デバイス）に適合させるケーブルを同梱する。
    • デバイス上に Type-A ポートを備えるか、デバイス上の専用ポートを標準的な USB Type-A ポートに適合させるケーブルを同梱する。
    • デバイス上に Micro-AB ポートを備える（標準的な Type-A ポートに適合させるケーブルが付属すべきです）。
  • [C-1-3] USB Type-A ポートまたは Micro-AB ポートから Type-C ポート（レセプタクル）に変換するアダプターを同梱してはなりません。
  • [C-SR-1] Android SDK ドキュメントに記載されているとおり、USB オーディオ クラスを実装することが強く推奨されます。
  • ホストモード時に接続されている USB 周辺機器の充電をサポートすべきです。USB Type-C コネクタの場合は、USB Type-C Cable and Connector Specification Revision 1.2 の「Termination Parameters」セクションで規定されているとおり 1.5 A 以上のソース電流をアドバタイズし、Micro-AB コネクタの場合は、USB Battery Charging specifications, revision 1.2 で規定されている充電ダウンストリーム ポート（CDP）の出力電流範囲を使用します。
  • USB Type-C 規格を実装し、サポートすべきです。

ホストモードをサポートする USB ポートと、USB オーディオ クラスが含まれる場合、デバイス実装は:

  • [C-2-1] USB HID クラスをサポートしなければなりません。
  • [C-2-2] USB HID Usage Tables と Voice Command Usage Request で規定されている次の HID データ フィールドの検出と、下記の KeyEvent 定数へのマッピングをサポートしなければなりません。
    • 使用状況ページ（0xC）使用状況 ID（0x0CD）: KEYCODE_MEDIA_PLAY_PAUSE
    • 使用状況ページ（0xC）使用状況 ID（0x0E9）: KEYCODE_VOLUME_UP
    • 使用状況ページ（0xC）使用状況 ID（0x0EA）: KEYCODE_VOLUME_DOWN
    • 使用状況ページ（0xC）使用状況 ID（0x0CF）: KEYCODE_VOICE_ASSIST

ホストモードとストレージ アクセス フレームワーク（SAF）をサポートする USB ポートが含まれる場合、デバイス実装は:

  • [C-3-1] リモート接続された MTP（メディア転送プロトコル）デバイスを認識し、そのコンテンツをインテント ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_CREATE_DOCUMENT を通じてアクセス可能にしなければなりません。

ホストモードと USB Type-C をサポートする USB ポートが含まれる場合、デバイス実装は:

  • [C-4-1] USB Type-C 仕様（セクション 4.5.1.3.3）で規定されているとおり、デュアルロール ポート機能を実装しなければなりません。デュアルロール ポートについて、3.5 mm オーディオ ジャックが含まれるデバイスでは、USB シンク検出（ホストモード）をデフォルトでオフにしても構いませんが、ユーザーが有効にできるようにしなければなりません。
  • [C-SR-2] DisplayPort をサポートすることが強く推奨され、USB SuperSpeed データ速度をサポートすべきであり、データと電源の役割を入れ替えるために Power Delivery をサポートすることが強く推奨されます。
  • [C-SR-3] USB Type-C Cable and Connector Specification Revision 1.2 の「Appendix A」に記載されているオーディオ アダプター アクセサリ モードはサポートしないことが強く推奨されます。
  • デバイス フォーム ファクタに最も適した Try.* モデルを実装すべきです。たとえば、ハンドヘルド デバイスは Try.SNK モデルを実装すべきです。

7.8. オーディオ

7.8.1. マイク

マイクが含まれる場合、デバイス実装は:

  • [C-1-1] android.hardware.microphone 機能定数をレポートしなければなりません。
  • [C-1-2] セクション 5.4 の、録音の要件を満たさなければなりません。
  • [C-1-3] セクション 5.6 の、オーディオ レイテンシの要件を満たさなければなりません。
  • [C-SR-1] セクション 7.8.3 に記載されているとおり、近超音波の録音をサポートすることが強く推奨されます。

マイクを省略する場合、デバイス実装は:

  • [C-2-1] android.hardware.microphone 機能定数をレポートしてはなりません。
  • [C-2-2] セクション 7 に従い、少なくとも NoOps として、録音 API を実装しなければなりません。

7.8.2. オーディオ出力

スピーカーが含まれるか、4 極 3.5 mm オーディオ ジャックや USB オーディオ クラスを使用する USB ホストモード ポートなど、オーディオ出力周辺機器用のオーディオ / マルチメディア出力ポートが含まれる場合、デバイス実装は:

  • [C-1-1] android.hardware.audio.output 機能定数をレポートしなければなりません。
  • [C-1-2] セクション 5.5 の、オーディオの再生の要件を満たさなければなりません。
  • [C-1-3] セクション 5.6 の、オーディオ レイテンシの要件を満たさなければなりません。
  • [C-SR-1] セクション 7.8.3 に記載されているとおり、近超音波の再生をサポートすることが強く推奨されます。

スピーカーまたはオーディオ出力ポートが含まれない場合、デバイス実装は:

  • [C-2-1] android.hardware.audio.output 機能をレポートしてはなりません。
  • [C-2-2] オーディオ出力関連の API を少なくとも NoOps として実装しなければなりません。

このセクションにおいて、「出力ポート」とは、3.5 mm オーディオ ジャック、HDMI、または USB オーディオ クラスの USB ホストモード ポートなどの物理インターフェースのことです。Bluetooth、Wi-Fi、またはモバイル ネットワークなど、無線ベースのプロトコルに基づくオーディオ出力のサポートは、「出力ポート」を含むとはみなされません。

7.8.2.1. アナログ オーディオ ポート

Android エコシステム全体で、3.5 mm オーディオ プラグを使用するヘッドセットや他のオーディオ アクセサリとの互換性を持たせるために、1 つ以上のアナログ オーディオ ポートが含まれる場合、デバイス実装は:

  • [C-SR-1] 4 極 3.5 mm オーディオ ジャックとなるオーディオ ポートを少なくとも 1 つ含むことが強く推奨されます。

4 極 3.5 mm オーディオ ジャックが含まれる場合、デバイス実装は:

  • [C-1-1] ステレオ ヘッドフォンと、マイク付きステレオ ヘッドフォンへのオーディオ再生をサポートしなければなりません。
  • [C-1-2] CTIA ピン配列の TRRS オーディオ プラグをサポートしなければなりません。
  • [C-1-3] オーディオ プラグのマイク極と接地極の間で、次に示す 3 つの等価インピーダンス範囲について、検出とキーコードへのマッピングをサポートしなければなりません。
    • 70 オーム以下: KEYCODE_HEADSETHOOK
    • 210～290 オーム: KEYCODE_VOLUME_UP
    • 360～680 オーム: KEYCODE_VOLUME_DOWN
  • [C-1-4] プラグ挿入時、ACTION_HEADSET_PLUG をトリガーしなければなりません（ただしプラグのすべての接点がジャックの該当セグメントに接した後に限ります）。
  • [C-1-5] スピーカー インピーダンス 32 オームで、少なくとも 150 mV ± 10% の出力電圧で動作できなければなりません。
  • [C-1-6] マイクのバイアス電圧が 1.8 V～2.9 V でなければなりません。
  • [C-1-7] オーディオ プラグのマイク極と接地極の間で、次に示す等価インピーダンス範囲について、検出とキーコードへのマッピングをしなければなりません。
    • 110～180 オーム: KEYCODE_VOICE_ASSIST
  • [C-SR-2] OMTP ピン配列のオーディオ プラグをサポートすることが強く推奨されます。
  • [C-SR-3] マイク付きステレオ ヘッドセットからの録音をサポートすることが強く推奨されます。

4 極 3.5 mm オーディオ ジャックがあり、マイクをサポートし、追加値でマイクを 1 に設定して android.intent.action.HEADSET_PLUG をブロードキャストする場合、デバイス実装は:

  • [C-2-1] 接続したオーディオ アクセサリ上のマイクの検出をサポートしなければなりません。
7.8.2.2. デジタル オーディオ ポート

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

7.8.3. 近超音波

近超音波とは、18.5 kHz から 20 kHz の帯域のことです。

デバイス実装は:

  • 次のとおり、AudioManager.getProperty API を介して近超音波オーディオ機能のサポートを正しくレポートしなければなりません。

PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND が「true」の場合、音源 VOICE_RECOGNITION と UNPROCESSED で次の要件を満たさなければなりません。

  • [C-1-1] 18.5 kHz から 20 kHz の帯域におけるマイクの平均電力感度は、2 kHz における感度より下に 15 dB 以内でなければなりません。
  • [C-1-2] -26 dBFS の 19 kHz トーンについて、18.5 kHz から 20 kHz におけるマイクの非加重信号対雑音比は、50 dB 以上でなければなりません。

PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND が「true」の場合:

  • [C-2-1] 18.5 kHz から 20 kHz におけるスピーカーの平均感度は、2 kHz における感度より下に 40 dB 以内でなければなりません。

7.8.4. 信号品位

デバイス実装は:

  • ハンドヘルド デバイスの入力ストリームと出力ストリームの両方について、グリッチのないオーディオ信号パス（1 パスあたり 1 分間のテストにおいて測定されるグリッチがゼロ）を提供すべきです。OboeTester「自動グリッチテスト」を使用してテストします。

このテストでは、オーディオ ループバック ドングルを、3.5 mm ジャックに直接使用するか、USB-C - 3.5 mm アダプターと組み合わせて使用する必要があります。すべてのオーディオ出力ポートをテストすべきです。

OboeTester は現在 AAudio パスをサポートしているため、AAudio を使用して、グリッチについて次の組み合わせをテストすべきです。

Perf モード 共有 出力サンプルレート 入力チャンネル 出力チャンネル
LOW_LATENCY 限定 不明 1 2
LOW_LATENCY 限定 不明 2 1
LOW_LATENCY 共有 不明 1 2
LOW_LATENCY 共有 不明 2 1
なし 共有 48000 1 2
なし 共有 48000 2 1
なし 共有 44100 1 2
なし 共有 44100 2 1
なし 共有 16000 1 2
なし 共有 16000 2 1

信頼性の高いストリームは、2,000 Hz 正弦波の信号対雑音比（SNR）と全高調波歪み（THD）について、次の基準を満たすべきです。

トランスデューサ THD SNR
メインの内蔵スピーカー（外部のリファレンス マイクを使用して測定） < 3.0% >= 50 dB
メインの内蔵マイク（外部のリファレンス スピーカーを使用して測定） < 3.0% >= 50 dB
内蔵 3.5 mm ジャック（ループバック アダプターを使用してテスト） < 1% >= 60 dB
スマートフォン付属の USB アダプター（ループバック アダプターを使用してテスト） < 1.0% >= 60 dB

7.9. バーチャル リアリティ

Android には、高品質なモバイル VR 体験を含む「バーチャル リアリティ」（VR）アプリをビルドするための API と機能があります。このセクションで詳述するように、デバイス実装はこれらの API と動作を適切に実装しなければなりません。

7.9.1. バーチャル リアリティ モード

Android は、VR モード（通知の立体画像レンダリングを処理し、ユーザーが VR アプリを注視している間は単眼式のシステム UI コンポーネントを無効にする機能）をサポートしています。

7.9.2. バーチャル リアリティ モード - 高パフォーマンス

VR モードをサポートする場合、デバイス実装は:

  • [C-1-1] 物理コアが少なくとも 2 つなければなりません。
  • [C-1-2] android.hardware.vr.high_performance 機能を宣言しなければなりません。
  • [C-1-3] パフォーマンス維持モードをサポートしなければなりません。
  • [C-1-4] OpenGL ES 3.2 をサポートしなければなりません。
  • [C-1-5] android.hardware.vulkan.level 0 をサポートしなければなりません。
  • android.hardware.vulkan.level 1 以上をサポートすべきです。
  • [C-1-6] EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content、EGL_EXT_image_gl_colorspace を実装し、利用可能な EGL 拡張機能のリストで拡張機能を公開しなければなりません。
  • [C-1-8] GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2、GL_EXT_protected_textures を実装し、利用可能な GL 拡張機能のリストで拡張機能を公開しなければなりません。
  • [C-SR-1] GL_EXT_external_buffer、GL_EXT_EGL_image_array、GL_OVR_multiview_multisampled_render_to_texture を実装し、利用可能な GL 拡張機能のリストで拡張機能を公開することが強く推奨されます。
  • [C-SR-2] Vulkan 1.1 をサポートすることが強く推奨されます。
  • [C-SR-3] VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing、VK_KHR_shared_presentable_image を実装し、利用可能な Vulkan 拡張機能のリストで公開することが強く推奨されます。
  • [C-SR-4] flags に VK_QUEUE_GRAPHICS_BIT と VK_QUEUE_COMPUTE_BIT の両方が含まれ queueCount が少なくとも 2 である Vulkan キュー ファミリーを、少なくとも 1 つ公開することが強く推奨されます。
  • [C-1-7] GPU とディスプレイは、2 つのレンダリング コンテキストを使用して VR コンテンツを 60 fps で交互にレンダリングする場合に、対象が明らかに分かれて表示されることがないように、共有フロント バッファへのアクセスを同期できなければなりません。
  • [C-1-9] NDK に記載されているとおり、AHardwareBuffer フラグ AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT のサポートを実装しなければなりません。
  • [C-1-10] 少なくとも AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT の形式について、使用状況フラグ AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT の任意の組み合わせによる AHardwareBuffer のサポートを実装しなければなりません。
  • [C-SR-5] 複数のレイヤ、C-1-10 で指定したフラグと形式による AHardwareBuffer の割り当てをサポートすることが強く推奨されます。
  • [C-1-11] 30 fps で 3,840 x 2,160 以上の H.264 デコード、平均 40 Mbps への圧縮をサポートしなければなりません（30 fps-10 Mbps で 1,920 x 1,080 の 4 インスタンス、または 60 fps-20 Mbps で 1,920 x 1,080 の 2 インスタンスに相当）。
  • [C-1-12] HEVC と VP9 をサポートしなければならず、平均 10 Mbps に圧縮されている場合に 30 fps で 1,920 x 1,080 以上のデコードができなければならず、30 fps-20 Mbps で 3,840 x 2,160 のデコードができるべきです（30 fps-5 Mbps で 1,920 x 1,080 の 4 インスタンスに相当）。
  • [C-1-13] HardwarePropertiesManager.getDeviceTemperatures API をサポートし、皮膚温について正確な値を返さなければなりません。
  • [C-1-14] 埋め込み画面がなければならず、その解像度は少なくとも 1,920 x 1,080 でなければなりません。
  • [C-SR-6] ディスプレイ解像度が少なくとも 2,560 x 1,440 であることが強く推奨されます。
  • [C-1-15] ディスプレイは、VR モード中に少なくとも 60 Hz で更新しなければなりません。
  • [C-1-17] ディスプレイは、持続時間 5 ミリ秒以下の低持続モードをサポートしなければなりません（持続時間は、ピクセルが光を発している時間として定義されます）。
  • [C-1-18] Bluetooth 4.2 と Bluetooth LE データ長拡張機能をサポートしなければなりません（セクション 7.4.3）。
  • [C-1-19] 次のデフォルト センサータイプすべてについて、ダイレクト チャンネル タイプをサポートし、適切にレポートしなければなりません。
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] 上記すべてのダイレクト チャンネル タイプについて、TYPE_HARDWARE_BUFFER ダイレクト チャンネル タイプをサポートすることが強く推奨されます。
  • [C-1-21] セクション 7.3.9 で規定されているとおり、android.hardware.hifi_sensors のジャイロスコープ、加速度計、磁力計関連の要件を満たさなければなりません。
  • [C-SR-8] android.hardware.sensor.hifi_sensors 機能をサポートすることが強く推奨されます。
  • [C-1-22] エンドツーエンドの動作反映レイテンシが 28 ミリ秒以下でなければなりません。
  • [C-SR-9] エンドツーエンドの動作反映レイテンシが 20 ミリ秒以下であることが強く推奨されます。
  • [C-1-23] 第 1 フレーム比（黒から白への遷移後の最初のフレームにおけるピクセルの明るさと、定常状態における白ピクセルの明るさの比率）が、少なくとも 85% でなければなりません。
  • [C-SR-10] 第 1 フレーム比が少なくとも 90% であることが強く推奨されます。
  • フォアグラウンド アプリに専用のコアを提供しても構いません。また、トップ フォアグラウンド アプリ専用の CPU コア数を返すために Process.getExclusiveCores API をサポートしても構いません。

専用コアをサポートする場合、コアは:

  • [C-2-1] 他のユーザー空間プロセスを実行できるようにしてはなりませんが（アプリが使用するデバイス ドライバを除く）、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。

7.10. ハプティクス

新しい要件の開始

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

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

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

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

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

新しい要件の終了

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

7.11. メディア パフォーマンス クラス

デバイス実装のメディア パフォーマンス クラスは、android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API から取得できます。メディア パフォーマンス クラスの要件は、R（バージョン 30）以降の Android バージョンごとに定義されています。特別な値 0 は、デバイスがメディア パフォーマンス クラスではないことを示します。

android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS に対してゼロ以外の値が返される場合、デバイス実装は:

  • [C-1-1] 少なくとも android.os.Build.VERSION_CODES.R の値を返さなければなりません。

  • [C-1-2] ハンドヘルド デバイス実装でなければなりません。

  • [C-1-3] セクション 2.2.7 に記載されている「メディア パフォーマンス クラス」のすべての要件を満たさなければなりません。

言い換えれば、Android T のメディア パフォーマンス クラスは、バージョン T、S、R のハンドヘルド デバイス用にのみ定義されています。

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

8. パフォーマンスと電力

パフォーマンスと電力に関する最低基準は、ユーザー エクスペリエンスにとって重要であり、アプリの開発時にデベロッパーが設定するであろうベースラインの前提条件に影響を与えます。

8.1. ユーザー エクスペリエンスの一貫性

アプリとゲームについて、一貫したフレームレートと応答時間を確保するための一定の最小要件があれば、滑らかなユーザー インターフェースをエンドユーザーに提供できます。デバイス実装には、デバイスタイプに応じて、セクション 2 に記載されているとおり、ユーザー インターフェース レイテンシとタスク切換えについての測定可能な要件があっても構いません。

8.2. ファイル I/O アクセスのパフォーマンス

アプリの個人データ ストレージ（/data パーティション）における一貫したファイル アクセス パフォーマンスについて共通のベースラインを提供することで、アプリ デベロッパーは、ソフトウェア設計に役立つ適切な期待値を設定できます。デバイス実装には、デバイスタイプに応じて、次の読み書き操作についてセクション 2 に記載されている特定の要件があっても構いません。

  • シーケンシャル書き込みパフォーマンス。10 MB の書き込みバッファを使用し、256 MB のファイルを書き込むことで測定。
  • ランダム書き込みパフォーマンス。4 KB の書き込みバッファを使用し、256 MB のファイルを書き込むことで測定。
  • シーケンシャル読み取りパフォーマンス。10 MB の書き込みバッファを使用し、256 MB のファイルを読み取ることで測定。
  • ランダム読み取りパフォーマンス。4 KB の書き込みバッファを使用し、256 MB のファイルを読み取ることで測定。

8.3. 省電力モード

AOSP に含まれるデバイス電源管理を改善する機能（アプリ スタンバイ バケット、Doze など）を含むか、制限付きアプリ スタンバイ バケットより強い制限を適用する機能を拡張する場合、デバイス実装は:

  • [C-1-1] トリガー、メンテナンス、ウェイクアップのアルゴリズムについて、またアプリ スタンバイと Doze 省電力モードのシステム全般設定または DeviceConfig の使用について、AOSP 実装から逸脱してはなりません。
  • [C-1-2] アプリ スタンバイのバケットごとにアプリのジョブ、アラーム、ネットワークのスロットリングを管理するための全般設定または DeviceConfig の使用について、AOSP 実装から逸脱してはなりません。
  • [C-1-3] アプリ スタンバイに使用するアプリ スタンバイ バケットの数について、AOSP 実装から逸脱してはなりません。
  • [C-1-4] 電源管理に記載されているとおり、アプリ スタンバイ バケットと Doze を実装しなければなりません。
  • [C-1-5] デバイスが省電力モードのとき、PowerManager.isPowerSaveMode() について true を返さなければなりません。
  • [C-1-6] アプリ スタンバイと Doze 省電力モードまたはバッテリー最適化から除外されたすべてのアプリを表示するユーザー アフォーダンスを提供しなければなりません。また、ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS インテントを実装して、アプリでバッテリー最適化を無視できるようにするようユーザーに求めなければなりません。
  • [C-SR-1] バッテリー セーバー機能を有効、無効にするユーザー アフォーダンスを提供することが強く推奨されます。
  • [C-SR-2] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供することが強く推奨されます。

デバイス実装が AOSP に含まれる電源管理機能を拡張し、その拡張機能が低頻度アプリ スタンバイ バケットより厳しい制限を適用する場合は、セクション 3.5.1 をご覧ください。

省電力モードに加えて、Android デバイス実装は、Advanced Configuration and Power Interface（ACPI）で規定された 4 つのスリープ電力状態のいずれか、またはすべてを実装しても構いません。

ACPI で規定されている S4 電力状態を実装する場合、デバイス実装は:

  • [C-1-1] ユーザーが明示的な操作（物理的にデバイスの一部である蓋を閉じる、車両またはテレビの電源をオフにするなど）を行ってデバイスを非アクティブ状態にした後、かつ、ユーザーがデバイスを再度アクティブにする（蓋を開く、車両またはテレビの電源を再度オンにするなど）前にのみ、この状態に入らなければなりません。

ACPI で規定されている S3 電力状態を実装する場合、デバイス実装は:

  • [C-2-1] 上記の C-1-1 を満たさなければなりません。または、サードパーティ アプリがシステム リソース（画面、CPU など）を必要としない場合にのみ、S3 状態に入らなければなりません。

    逆に、この SDK に記載されているとおり、サードパーティ アプリがシステム リソースを必要とする場合は、S3 状態を終了しなければなりません。

    たとえば、サードパーティ アプリが FLAG_KEEP_SCREEN_ON を通じて画面をオンにし続けることをリクエストしているか、PARTIAL_WAKE_LOCK を通じて CPU を動作させ続けることをリクエストしているとき、C-1-1 に記載されているとおり、ユーザーがデバイスを非アクティブ状態にする明示的な操作を行っていない限り、デバイスは S3 状態に入ってはなりません。逆に、JobScheduler を通じてサードパーティ アプリが実装するタスクがトリガーされた時点、または Firebase Cloud Messaging がサードパーティ アプリに配信された時点で、ユーザーがデバイスを非アクティブ状態にしていない限り、デバイスは S3 状態を終了しなければなりません。これらは包括的な例ではなく、AOSP は、この状態からの復帰をトリガーする広範な復帰シグナルを実装しています。

8.4. 消費電力の算出

より正確に消費電力を算出しレポートすることで、アプリ デベロッパーに対し、アプリの電力使用パターンを最適化するためのインセンティブとツールの両方を提供します。

デバイス実装は:

  • [C-SR-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供することが強く推奨されます。
  • [C-SR-2] すべての消費電力値をミリアンペア時（mAh）単位でレポートすることが強く推奨されます。
  • [C-SR-3] プロセスの UID ごとの CPU 電力消費をレポートすることが強く推奨されます。Android オープンソース プロジェクトは、uid_cputime カーネル モジュール実装を通じて要件を満たしています。
  • [C-SR-4] この電力使用量を、adb shell dumpsys batterystats シェルコマンドを介してアプリ デベロッパーが利用できるようにすることが強く推奨されます。
  • ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。

8.5. 一貫したパフォーマンス

高パフォーマンスで長時間実行されるアプリでは、バックグラウンドで実行されている他のアプリや、温度制限による CPU スロットリングが原因となって、パフォーマンスが大きく変動することがあります。Android にはプログラマティック インターフェースがあるため、デバイスで使用可能な場合、トップ フォアグラウンド アプリは、このような変動に対処するためにリソースの割り当てを最適化するようシステムにリクエストできます。

デバイス実装は:

  • [C-0-1] PowerManager.isSustainedPerformanceModeSupported() API メソッドを通じてパフォーマンス維持モードのサポートを正確にレポートしなければなりません。

  • パフォーマンス維持モードをサポートすべきです。

パフォーマンス維持モードのサポートをレポートする場合、デバイス実装は:

  • [C-1-1] トップ フォアグラウンド アプリがリクエストした場合、少なくとも 30 分間は一貫したレベルのパフォーマンスを提供しなければなりません。
  • [C-1-2] Window.setSustainedPerformanceMode() API と他の関連 API を使用しなければなりません。

複数の CPU コアが含まれる場合、デバイス実装は:

  • トップ フォアグラウンド アプリが予約できる専用コアを少なくとも 1 つ提供すべきです。

トップ フォアグラウンド アプリ用に専用コアを 1 つ予約することをサポートする場合、デバイス実装は:

  • [C-2-1] Process.getExclusiveCores() API メソッドを通じて、トップ フォアグラウンド アプリが予約できる専用コアの ID 番号をレポートしなければなりません。
  • [C-2-2] アプリが使用するデバイス ドライバを除き、ユーザー空間プロセスを専用コアで実行できるようにしてはなりませんが、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。

専用コアをサポートしない場合、デバイス実装は:

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

デバイス実装は:

  • [C-0-1] Android デベロッパー向けドキュメントの、API のセキュリティと権限に関するリファレンス ドキュメントで規定されているとおり、Android プラットフォームのセキュリティ モデルに合致するセキュリティ モデルを実装しなければなりません。

  • [C-0-2] サードパーティ / 認証局からの追加の許可 / 証明書を必要とせずに、自己署名アプリのインストールをサポートしなければなりません。

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

  • [C-1-1] 以降のサブセクションに記載されている要件をサポートしなければなりません。

9.1. 権限

デバイス実装は:

  • [C-0-1] Android デベロッパー向けドキュメントで規定されているとおり、Android 権限モデルと Android ロールモデルをサポートしなければなりません。具体的には、SDK ドキュメントで規定されているとおり各権限とロールを適用しなければならず、権限とロールを省略、変更、無視することはできません。

  • 新しい権限 ID 文字列が android.\* 名前空間にない場合、権限を追加しても構いません。

  • [C-0-2] protectionLevel が PROTECTION_FLAG_PRIVILEGED である権限は、システム イメージの特権パス（および APEX ファイル）にプリインストールされたアプリと、各アプリの明示的に許可リスト登録された権限のサブセット内のアプリにのみ、付与しなければなりません。AOSP 実装は、etc/permissions/ パスのファイルから各アプリの許可リスト登録された権限を読み取って尊重し、特権パスとして system/priv-app パスを使用することで、この要件を満たしています。

保護レベルが「dangerous」の権限は、実行時の権限です。targetSdkVersion が 22 を超えるアプリは、実行時にこうした権限をリクエストします。

デバイス実装は:

  • [C-0-3] リクエストされた実行時の権限を付与するかどうかをユーザーが決定する専用のインターフェースを表示しなければなりません。また、実行時の権限をユーザーが管理できるインターフェースも提供しなければなりません。

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

  • [C-0-5] 次の場合を除き、アプリに実行時の権限を付与してはなりません。

    • デバイスの出荷時にインストールされる場合、かつ

    • アプリが権限を使用する前に、ユーザーの同意を得ることができる場合。

      または

    • 実行時の権限がデフォルトの権限付与ポリシーによって付与されているか、プラットフォームのロールを保持するために付与されている場合。

  • [C-0-6] android.permission.RECOVER_KEYSTORE 権限は、適切に保護された復旧エージェントを登録するシステムアプリにのみ付与しなければなりません。適切に保護された復旧エージェントは、デバイス外のリモート ストレージと同期するデバイス上のソフトウェア エージェントであって、ロック画面の知識要素に対するブルート フォース アタックを防ぐために、Google Cloud Key Vault サービスに記載されているものと同等以上に保護されたセキュアなハードウェアを備えたものとして定義されています。

デバイス実装は:

  • [C-0-7] アプリが標準の Android API または独自のメカニズムを通じて、位置情報または身体活動データをリクエストする場合、Android の位置情報の利用許可プロパティに従わなければなりません。このようなデータには下記が含まれますが、これらに限定されません。

    • セクション 9.8.8 に記載されているデバイスの位置情報（緯度と経度など）。
    • デバイスの位置を特定または推定するために使用できる情報（SSID、BSSID、セル ID、デバイスが接続しているネットワークの位置情報など）。
    • ユーザーの身体活動、または身体活動の分類。

より具体的には、デバイス実装は:

  • [C-0-8] アプリが位置情報または身体活動データにアクセスできるように、ユーザーの同意を得なければなりません。
  • [C-0-9] SDK に記載されているとおり、十分な権限を保持しているアプリにのみ実行時の権限を付与しなければなりません。たとえば、TelephonyManager#getServiceState に対して android.permission.ACCESS_FINE_LOCATION が必要です。

前述した Android の位置情報の利用許可プロパティに対する唯一の例外は、アプリがユーザーの位置情報を導出または特定するために位置情報にアクセスしない場合です。具体的には次のとおりです。

  • アプリが RADIO_SCAN_WITHOUT_LOCATION 権限を保持している場合。
  • デバイス設定とセットアップのために、システムアプリが NETWORK_SETTINGS 権限または NETWORK_SETUP_WIZARD 権限を保持している場合。

権限には、動作変更への制限ありとマークすることができます。

  • [C-0-10] 次の場合を除き、フラグ hardRestricted でマークされた権限をアプリに付与してはなりません。

    • アプリの APK ファイルがシステム パーティションにある。
    • ユーザーが、hardRestricted 権限に関連付けられたロールをアプリに割り当てている。
    • インストーラが hardRestricted をアプリに付与している。
    • 以前の Android バージョンでアプリが hardRestricted を付与されている。

  • [C-0-11] softRestricted 権限を持つアプリは、制限付きアクセス権のみを取得しなければならず、SDK に記載されているとおり許可リストに登録されるまでフルアクセス権を取得してはなりません。なお、フルアクセス権と制限付きアクセス権は、softRestricted 権限ごとに（たとえば READ_EXTERNAL_STORAGE について）定義されるものです。

  • [C-0-12] setPermissionPolicy API と setPermissionGrantState API で定義された権限の制限をバイパスするために、カスタムの関数や API を提供してはなりません。

  • [C-0-13] AppOpsManager API を使用して、Android のアクティビティとサービスからの、危険な権限で保護されたデータに対するプログラムによるアクセスをすべて記録し、追跡しなければなりません。

  • [C-0-14] ロール要件を満たす機能を持つアプリにのみ、ロールを割り当てなければなりません。

  • [C-0-15] プラットフォームで定義されているロールの重複またはスーパーセット機能であるロールを定義してはなりません。

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

  • [C-1-1] 次の権限が管理者によって暗黙的に付与されてはなりません。
    • 位置情報（ACCESS_BACKGROUND_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_FINE_LOCATION）
    • カメラ（CAMERA）
    • マイク（RECORD_AUDIO）
    • ボディセンサー（BODY_SENSORS）
    • 身体活動（ACTIVITY_RECOGNITION）

ACTION_MANAGE_OVERLAY_PERMISSION インテントを処理するアクティビティで、どのアプリが他のアプリの上に描画できるかを選択するユーザー アフォーダンスを提供する場合、デバイス実装は:

  • [C-2-1] ACTION_MANAGE_OVERLAY_PERMISSION インテントのインテント フィルタを使用するすべてのアクティビティが、開始元のアプリやそこから提供される情報に関係なく、同じ UI 画面を持つようにしなければなりません。

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

  • [C-3-1] 管理者がデバイスにおける権限の制御をオプトアウトしている場合を除き、ユーザーがセットアップを続行するか終了するかのオプションによって、フルマネージド デバイス セットアップ（デバイス所有者セットアップ）の際に、マイク、カメラ、位置情報を含むスマートフォンの設定をアプリで制御することを、IT 管理者が許可できるとする免責条項を表示しなければなりません。

デバイス実装で 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.2. UID とプロセスの分離

デバイス実装は:

  • [C-0-1] 各アプリが一意の Unix 形式の UID として個別のプロセスで動作する、Android アプリ サンドボックス モデルをサポートしなければなりません。
  • [C-0-2] セキュリティと権限に関するリファレンスで規定されているとおり、アプリが適切に署名され、構築されていることを条件として、同じ Linux ユーザー ID で複数のアプリを実行することをサポートしなければなりません。

9.3. ファイルシステムの権限

デバイス実装は:

9.4. 代替実行環境

デバイス実装は、Dalvik 実行ファイル形式またはネイティブ コード以外のソフトウェアまたは技術を使用してアプリを実行するランタイム環境が含まれていたとしても、Android のセキュリティと権限モデルの一貫性を維持しなければなりません。つまり:

  • [C-0-1] 代替ランタイムは、それ自体が Android アプリでなければならず、セクション 9 の他の部分に記載されているとおり、標準の Android セキュリティ モデルに準拠しなければなりません。

  • [C-0-2] 代替ランタイムには、<uses-permission> メカニズムを介して、ランタイムの AndroidManifest.xml ファイルでリクエストされていない権限によって保護されたリソースへのアクセス権を付与してはなりません。

  • [C-0-3] 代替ランタイムは、システムアプリに制限された Android 権限によって保護された機能の利用を、アプリに許可してはなりません。

  • [C-0-4] 代替ランタイムは、Android サンドボックス モデルに準拠しなければならず、代替ランタイムを使用するインストール済みのアプリは、共有ユーザー ID と署名証明書の標準的な Android メカニズムを使用する場合を除き、デバイスにインストールされている他のアプリのサンドボックスを再利用してはなりません。

  • [C-0-5] 代替ランタイムは、他の Android アプリに対応するサンドボックスで起動されてはならず、そのサンドボックスへのアクセス権を付与したり、付与されたりしてはなりません。

  • [C-0-6] 代替ランタイムは、スーパーユーザー（root）または他のユーザー ID の特権で起動されてはならず、その特権を付与されたり、付与したりしてはなりません。

  • [C-0-7] 代替ランタイムの .apk ファイルがデバイス実装のシステム イメージに含まれる場合、デバイス実装に含まれる他のアプリに署名するために使用される鍵とは異なる鍵で署名されなければなりません。

  • [C-0-8] アプリをインストールするとき、代替ランタイムは、アプリが使用する Android の権限についてユーザーの同意を得なければなりません。

  • [C-0-9] アプリが、対応する Android の権限があるデバイス リソース（カメラ、GPS など）を利用する必要がある場合、代替ランタイムは、アプリがそのリソースにアクセスできることをユーザーに通知しなければなりません。

  • [C-0-10] ランタイム環境がこの方法でアプリの機能を記録しない場合、ランタイム環境は、ランタイムを使用してアプリをインストールするときに、そのランタイム自体が持つすべての権限をリストしなければなりません。

  • 代替ランタイムは、PackageManager を介してアプリを個別の Android サンドボックス（Linux ユーザー ID など）にインストールすべきです。

  • 代替ランタイムは、代替ランタイムを使用するすべてのアプリで共有される単一の Android サンドボックスを提供しても構いません。

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

Android は、複数のユーザーをサポートし、ユーザーの完全な分離と、部分分離によるユーザー プロファイルのクローン作成をサポートします（つまり、android.os.usertype.profile.CLONE タイプの単一の追加ユーザー プロファイル）。

  • デバイス実装は、プライマリ外部ストレージにリムーバブル メディアを使用する場合、マルチユーザーを有効にしても構いませんが、有効にすべきではありません。

複数のユーザーのサポートが含まれる場合、デバイス実装は:

  • [C-1-2] ユーザーごとに、API のセキュリティと権限に関するリファレンス ドキュメントで規定されているとおり、Android プラットフォームのセキュリティ モデルに合致するセキュリティ モデルを実装しなければなりません。
  • [C-1-3] ユーザー インスタンスごとに、個別の分離型共有アプリ ストレージ（/sdcard）ディレクトリがなければなりません。
  • [C-1-4] あるユーザーが所有しそのユーザーのために実行されているアプリが、他のユーザーのデータと同じボリュームまたはファイルシステムに保存されていたとしても、他のユーザーが所有するファイルをリストしたり、読み書きしたりできないようにしなければなりません。
  • [C-1-5] デバイス実装が外部ストレージ API 用にリムーバブル メディアを使用する場合、マルチユーザーが有効になっているときは、システムにしかアクセスできない非リムーバブル メディアにのみ保存されている鍵を使用して、SD カードの内容を暗号化しなければなりません。これにより、ホスト PC でメディアを読み取れなくなるため、デバイス実装は、ホスト PC から現在のユーザーのデータにアクセスできるようにするため、MTP または同様のシステムに切り替える必要があります。

複数のユーザーのサポートが含まれる場合、同じアプリのデュアル インスタンスの実行専用に作成されたユーザーを除くすべてのユーザーについて、デバイス実装は:

  • [C-2-1] ユーザー インスタンスごとに、個別の分離された共有アプリ ストレージ（/sdcard）ディレクトリがなければなりません。
  • [C-2-2] あるユーザーが所有しそのユーザーのために実行されているアプリが、他のユーザーのデータと同じボリュームまたはファイルシステムに保存されていたとしても、他のユーザーが所有するファイルをリストしたり、読み書きしたりできないようにしなければなりません。

デバイス実装は、同じアプリのデュアル インスタンスを実行する目的で、プライマリ ユーザーに対して（プライマリ ユーザーに対してのみ）android.os.usertype.profile.CLONE タイプの単一の追加ユーザー プロファイルを作成しても構いません。こうしたデュアル インスタンスは、部分的に分離されたストレージを共有し、ランチャーでエンドユーザーに同時に提示され、同じ「最近」ビューに表示されます。これは、たとえばデュアル SIM デバイスで、1 つのアプリの 2 つのインスタンスをユーザーがインストールすることをサポートする場合に使用できます。

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

  • [C-3-1] すでに親ユーザー プロファイルにアクセス可能であるか、この追加ユーザー プロファイルで直接所有している、ストレージまたはデータへのアクセス権のみを提供しなければなりません。
  • [C-3-2] これを仕事用プロファイルとしてはなりません。
  • [C-3-3] 親ユーザー アカウントからプライベート アプリデータ ディレクトリを分離しなければなりません。
  • [C-3-4] デバイス所有者がプロビジョニングされている場合に（セクション 3.9.1 参照）、追加ユーザー プロファイルを作成できるようにしてはなりません。また、最初に追加ユーザー プロファイルを削除せずにデバイス所有者をプロビジョニングできるようにしてはなりません。

新しい要件の開始

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

  • [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.6. プレミアム SMS の警告

Android は、プレミアム SMS メッセージの送信についてユーザーに警告することをサポートしています。プレミアム SMS メッセージとは、携帯通信会社に登録されたサービスに送信されるテキスト メッセージのことであり、ユーザーに課金される可能性があります。

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

  • [C-1-1] デバイスの /data/misc/sms/codes.xml ファイルで定義された正規表現で識別される番号に SMS メッセージを送信する前に、ユーザーに警告しなければなりません。アップストリームの Android オープンソース プロジェクトは、この要件を満たす実装を提供しています。

9.7. セキュリティ機能

デバイス実装は、下記のとおり、カーネルとプラットフォーム両方のセキュリティ機能に確実に準拠しなければなりません。

Android サンドボックスには、Linux カーネルの Security-Enhanced Linux（SELinux）の強制アクセス制御（MAC）システム、seccomp サンドボックス化、その他のセキュリティ機能を使用する機能があります。デバイス実装は:

  • [C-0-1] SELinux や他のセキュリティ機能が Android フレームワークの下に実装されている場合でも、既存のアプリとの互換性を維持しなければなりません。
  • [C-0-2] Android フレームワークの下に実装されたセキュリティ機能によってセキュリティ違反が検出され、正常にブロックされたときにユーザー インターフェースを表示してはなりませんが、ブロックされないセキュリティ違反が発生したために悪用が行われたときはユーザー インターフェースを表示しても構いません。
  • [C-0-3] Android フレームワークの下に実装されている SELinux や他のセキュリティ機能を、ユーザーまたはアプリ デベロッパーが設定できるようにしてはなりません。
  • [C-0-4] API（Device Administration API など）を通じて別のアプリに影響を与える可能性のあるアプリで、互換性を破るポリシーを設定できるようにしてはなりません。
  • [C-0-5] Android オープンソース プロジェクトのサイトに記載されているとおり、各プロセスへのアクセス権をより絞り込んで付与できるように、メディア フレームワークを複数のプロセスに分割しなければなりません。
  • [C-0-6] マルチスレッド プログラムから設定可能なポリシーを使用してシステムコールをフィルタリングできるようにする、カーネルアプリ サンドボックス化メカニズムを実装しなければなりません。アップストリームの Android オープンソース プロジェクトは、source.android.com のカーネル設定セクションに記載されているとおり、スレッドグループ同期（TSYNC）で seccomp-BPF を有効にすることを通じてこの要件を満たしています。

カーネルの整合性と自己保護機能は Android のセキュリティに不可欠です。デバイス実装は:

  • [C-0-7] カーネル スタック バッファ オーバーフロー保護メカニズムを実装しなければなりません。このようなメカニズムの例としては、CC_STACKPROTECTOR_REGULAR と CONFIG_CC_STACKPROTECTOR_STRONG が挙げられます。
  • [C-0-8] 実行可能コードが読み取り専用、読み取り専用データが実行不可能かつ書き込み不可能、書き込み可能データが実行不可能である場合、厳格なカーネルメモリ保護を実装しなければなりません（例: CONFIG_DEBUG_RODATA または CONFIG_STRICT_KERNEL_RWX）。
  • [C-0-9] API レベル 28 以降を搭載して出荷されたデバイスで、ユーザー空間とカーネル空間の間におけるコピーの静的、動的オブジェクト サイズ境界チェックを実装しなければなりません（例: CONFIG_HARDENED_USERCOPY）。
  • [C-0-10] API レベル 28 以降を搭載して出荷されたデバイスで、カーネルモードで実行するとき、ユーザー空間メモリを実行してはなりません（例: ハードウェア PXN、または CONFIG_CPU_SW_DOMAIN_PAN か CONFIG_ARM64_SW_TTBR0_PAN を介してエミュレート）。
  • [C-0-11] API レベル 28 以降を搭載して出荷されたデバイスで、通常の usercopy アクセス API 外でカーネルのユーザー空間メモリを読み書きしてはなりません（例: ハードウェア PAN、または CONFIG_CPU_SW_DOMAIN_PAN か CONFIG_ARM64_SW_TTBR0_PAN を介してエミュレート）。
  • [C-0-12] API レベル 28 以降を搭載して出荷されたすべてのデバイスで、ハードウェアが CVE-2017-5754 に対して脆弱である場合、カーネルページ テーブル分離を実装しなければなりません（例: CONFIG_PAGE_TABLE_ISOLATION または CONFIG_UNMAP_KERNEL_AT_EL0）。

  • [C-0-13] API レベル 28 以降を搭載して出荷されたすべてのデバイスで、ハードウェアが CVE-2017-5715 に対して脆弱である場合、分岐予測強化を実装しなければなりません（例: CONFIG_HARDEN_BRANCH_PREDICTOR）。

  • [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）。また、デバイス実装は、カーネルがヒープ割り当てを初期化するために使用する値を仮定すべきではありません。

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

  • [C-1-1] SELinux を実装しなければなりません。
  • [C-1-2] SELinux をグローバル enforcing モードに設定しなければなりません。
  • [C-1-3] すべてのドメインを enforcing モードで設定しなければなりません。デバイス / ベンダー固有のドメインを含め、permissive モードのドメインは許可されません。
  • [C-1-4] アップストリームの Android オープンソース プロジェクト（AOSP）で提供されている system/sepolicy フォルダ内に存在する neverallow ルールの変更、省略、または置き換えを行ってはなりません。また、ポリシーは、AOSP SELinux ドメインとデバイス / ベンダー固有のドメインの両方について、neverallow ルールがすべて存在する状態でコンパイルしなければなりません。
  • [C-1-5] API レベル 28 以降をターゲットとするサードパーティ アプリを、各アプリの個人データ ディレクトリにアプリごとの SELinux 制限がある、アプリごとの SELinux サンドボックスで実行しなければなりません。
  • アップストリームの Android オープンソース プロジェクトの system/sepolicy フォルダで提供されているデフォルトの SELinux ポリシーを保持し、このポリシーへの追加は、独自のデバイス固有の設定についてのみ行うべきです。

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

  • [C-2-1] SELinux と同等の強制アクセス制御システムを使用しなければなりません。

DMA 対応の I/O デバイスを使用する場合、デバイス実装は:

  • [C-SR-9] IOMMU（ARM SMMU など）を使用して、DMA 対応の各 I/O デバイスを分離することが強く推奨されます。

Android には、デバイスのセキュリティに不可欠な多層防御機能が複数含まれています。さらに Android は、品質やセキュリティの低下の原因となる一般的なバグの主なクラスを削減することに力を入れています。

メモリのバグを減らすために、デバイス実装は:

  • [C-SR-10] ARMv9 デバイスでは MTE、ARMv8+ デバイスでは HWASan、その他のデバイスタイプでは ASan などのユーザー空間メモリエラー検出ツールを使用してテストすることが強く推奨されます。
  • [C-SR-11] KASAN（ARMv9 デバイスでは CONFIG_KASAN、CONFIG_KASAN_HW_TAGS、ARMv8 デバイスでは CONFIG_KASAN_SW_TAGS、その他のデバイスタイプでは CONFIG_KASAN_GENERIC）などのカーネル メモリエラー検出ツールを使用してテストすることが強く推奨されます。
  • [C-SR-12] 本番環境では MTE、GWP-ASan、KFENCE などのメモリエラー検出ツールを使用することが強く推奨されます。

Arm TrustZone ベースの TEE を使用する場合、デバイス実装は:

  • [C-SR-13] Android と TEE との間で、Armv8-A（FF-A）の Arm ファームウェア フレームワークのような、メモリ共有のための標準プロトコルを使用することが強く推奨されます。
  • [C-SR-14] 信頼できるアプリが、上記のプロトコルを介してアプリと明示的に共有されているメモリにのみアクセスするよう制限することが強く推奨されます。デバイスが Arm S-EL2 例外レベルをサポートしている場合は、これをセキュア パーティション マネージャーによって強制適用すべきです。それ以外の場合は、TEE OS によって強制適用すべきです。

新しい要件の開始

メモリ安全性テクノロジーは、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. プライバシー

9.8.1. 使用履歴

Android は、ユーザーの選択履歴を保存し、UsageStatsManager で履歴を管理します。

デバイス実装は:

  • [C-0-1] そのようなユーザー履歴の妥当な保持期間を維持しなければなりません。
  • [C-SR-1] AOSP 実装でデフォルトで設定されている 14 日間の保持期間を維持することが強く推奨されます。

Android は、StatsLog 識別子を使用してシステム イベントを保存し、StatsManager と IncidentManager システム API を介して履歴を管理します。

デバイス実装は:

  • [C-0-2] システム API クラス IncidentManager で作成されるインシデント レポートに、DEST_AUTOMATIC でマークされたフィールドのみを含まなければなりません。
  • [C-0-3] システム イベント識別子を、StatsLog SDK ドキュメントに記載されているもの以外のイベントをログに記録するために使用してはなりません。追加のシステム イベントがログに記録された場合、100,000 から 200,000 の範囲で別の atom 識別子を使用しても構いません。

9.8.2. 記録

デバイス実装は:

  • [C-0-1] ユーザーの同意、または明確な進行中の通知なしに、ユーザーの個人情報（キーストローク、画面に表示されているテキスト、バグレポートなど）をデバイスから送信するソフトウェア コンポーネントを、プリロードまたは配信してはなりません。
  • [C-0-2] 画面のキャストまたは画面の録画画面のキャプチャ セッションが MediaProjection.createVirtualDisplay()、VirtualDeviceManager.createVirtualDisplay()、または独自の API を介して有効になっている開始されるたびに場合は常に、ユーザー警告と、ユーザーの画面に表示されているすべての機密情報のキャプチャを許可する AOSP とまったく同じメッセージを含む明示的なユーザーの同意に関する表示を行い、同意を得なければなりません。ユーザーの同意の表示を今後無効にするアフォーダンスをユーザーに提供してはなりません。
  • [C-0-3] 画面のキャストまたは画面の録画が有効になっている間は、進行中の通知をユーザーに示さなければなりません。AOSP は進行中の通知アイコンをステータスバーに表示することで、この要件を満たしています。

新しい要件の開始

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

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

    新しい要件の終了

システム API ContentCaptureService を介さずに、画面に表示されているコンテンツをキャプチャする機能や、デバイスで再生されているオーディオ ストリームを録音する機能、またはセクション 9.8.6 OS レベルおよびアンビエント データに記載されている他の独自の方法がシステムに含まれる場合、デバイス実装は:

  • [C-1-1] この機能が有効になっており、アクティブにキャプチャや録音を行っているときは常に、進行中の通知をユーザーに示さなければなりません。

周囲音の録音や、ユーザーのコンテキストについての有用な情報を推測するためにデバイスで再生されているオーディオの録音が可能な、あらかじめ有効になっているコンポーネントが含まれる場合、デバイス実装は:

  • [C-2-1] 明示的なユーザーの同意がある場合を除き、録音された未加工オーディオ、または、元のオーディオもしくはそれに近いものに戻せる形式のものを、永続的なデバイス上のストレージに保存したり、デバイスから送信したりしてはなりません。

「マイク インジケーター」とは、常にユーザーに表示され隠すことができない画面上の表示であって、マイクが使用されていることを固有のテキスト、色、アイコン、またはそれらの組み合わせによってユーザーが把握できるものを指します。

「カメラ インジケーター」とは、常にユーザーに表示され隠すことができない画面上の表示であって、カメラが使用されていることを固有のテキスト、色、アイコン、またはそれらの組み合わせによってユーザーが把握できるものを指します。

最初に 1 秒間表示した後、インジケーターは小さくなるなど、視覚的に変化できます。最初に提示して把握された状態のまま表示する必要はありません。

マイクの使用が開始されたことをテキスト、アイコン、または色でユーザーに示す場合、マイク インジケーターは、アクティブに表示されているカメラ インジケーターと統合しても構いません。

カメラの使用が開始されたことをテキスト、アイコン、または色でユーザーに示す場合、カメラ インジケーターは、アクティブに表示されているマイク インジケーターと統合しても構いません。

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

  • [C-SR-1] アプリがマイクからオーディオ データにアクセスしているときはマイク インジケーターを表示することが強く推奨されます。ただし、HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService、またはセクション 9.1 で CDD 識別子 [C-3-X] が割り当てられたロールを持つアプリからのみマイクにアクセスする場合は、この限りではありません。.
  • [C-SR-2] PermissionManager.getIndicatorAppOpUsageData() から返された、マイクを使用している最近使ったアプリとアクティブなアプリのリストを、関連する属性メッセージとともに表示することが強く推奨されます。
  • [C-SR-3] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、マイク インジケーターを非表示にしないことが強く推奨されます。

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

  • [C-SR-4] アプリがライブ カメラデータにアクセスしているときは、カメラ インジケーターを表示することが強く推奨されます。ただし、セクション 9.1 で CDD 識別子 [C-3-X] が割り当てられたロールを持つアプリからのみカメラにアクセスする場合は、この限りではありません。
  • [C-SR-5] PermissionManager.getIndicatorAppOpUsageData() から返された、カメラを使用している最近使ったアプリとアクティブなアプリを、関連する属性メッセージとともに表示することが強く推奨されます。
  • [C-SR-6] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、カメラ インジケーターを非表示にしないことが強く推奨されます。

9.8.3. 接続

USB ペリフェラル モードをサポートする USB ポートがある場合、デバイス実装は:

  • [C-1-1] USB ポートでの共有ストレージの内容へのアクセスを許可する前に、ユーザーの同意を求めるユーザーインターフェースを提示しなければなりません。

9.8.4. ネットワーク トラフィック

デバイス実装は:

  • [C-0-1] アップストリームの Android オープンソース プロジェクトで提供されているものと同じ、システムが信頼する認証局（CA）ストア用のルート証明書をプリインストールしなければなりません。
  • [C-0-2] 空のユーザールート CA ストアを設定して出荷しなければなりません。
  • [C-0-3] ユーザールート CA ストアが追加された場合、ユーザーに対し、ネットワーク トラフィックがモニターされる可能性があることを示す警告を表示しなければなりません。

デバイスのトラフィックが VPN 経由でルーティングされる場合、デバイス実装は:

  • [C-1-1] ユーザーに対し、下記を示す警告を表示しなければなりません。
    • ネットワーク トラフィックがモニターされる可能性がある。
    • ネットワーク トラフィックが、VPN を提供する特定の VPN アプリを経由してルーティングされている。

プロキシ サーバーまたは VPN ゲートウェイを経由してネットワーク データ トラフィックをルーティングするメカニズムがあり（たとえば、android.permission.CONTROL_VPN が付与されている VPN サービスのプリロード）、デフォルトであらかじめ有効になっている場合、デバイス実装は:

  • [C-2-1] そのメカニズムを有効にする前に、ユーザーの同意を求めなければなりません。ただし、その VPN が DevicePolicyManager.setAlwaysOnVpnPackage() を介して Device Policy Controller によって有効にされている場合を除きます。この場合、ユーザーは別途同意を提供する必要はありませんが、通知だけは受けなければなりません。

サードパーティ VPN アプリの常時接続 VPN 機能を切り替えるユーザー アフォーダンスを実装する場合、デバイス実装は:

  • [C-3-1] 常時接続 VPN サービスをサポートしないアプリについて、AndroidManifest.xml ファイルで SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 属性を false に設定することで、このユーザー アフォーダンスを無効にしなければなりません。

9.8.5. デバイス識別子

デバイス実装は:

  • [C-0-1] 次の要件のいずれかを満たす場合を除き、デバイス シリアル番号や、該当する場合は IMEI / MEID、SIM シリアル番号、International Mobile Subscriber Identity（IMSI）にアプリからアクセスできないようにしなければなりません。
    • デバイス メーカーによって検証された署名付きの携帯通信会社アプリである。
    • READ_PRIVILEGED_PHONE_STATE 権限を付与されている。
    • UICC 携帯通信会社権限で定義された携帯通信会社の権限がある。
    • READ_PHONE_STATE 権限を付与されたデバイス所有者またはプロファイル所有者である。
    • （SIM シリアル番号 / ICCID のみ）アプリで加入者 ID の変更を検出するという現地の規制要件がある。

9.8.6. コンテンツ キャプチャとアプリ検索OS レベルおよびアンビエント データ

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

  • 画面上にレンダリングされるテキストとグラフィック（通知や、AssistStructure API を介したアシストデータを含みますが、これらに限定されません）。
  • デバイスで記録または再生される、オーディオや動画などのメディアデータ。
  • 入力イベント（キー、マウス、ジェスチャー、音声、動画、ユーザー補助など）。

新しい要件の開始

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

新しい要件の終了

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

  • テキストの意味を理解し、テキストに基づいて予想される次のアクションを生成するために、TextClassifier API を介して System TextClassifier（つまりシステム サービス）に送信される、テキストまたは他のデータ。
  • プラットフォーム AppSearch 実装によってインデックス登録されたデータ（テキスト、グラフィック、メディアデータ、その他の同様のデータを含みますが、これらに限定されません）。

新しい要件の開始

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

新しい要件の終了

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

  • [C-1-1] そのようなデータをデバイスに保存する際に、すべて暗号化しなければなりません。この暗号化は、Android のファイルベースの暗号化を使用して行っても、Cipher SDK に API バージョン 26 以降としてリストされている暗号化のいずれかを使用して行っても構いません。
  • [C-1-2] Android のバックアップ方法または他のバックアップ方法を使用して、未加工データまたは暗号化されたデータをバックアップしてはなりません。
  • [C-1-3] そのようなすべてのデータとデバイスのログは、必ずプライバシー保護メカニズムを使用して送信しなければなりません（共有するたびに明示的にユーザーの同意を得る場合を除きます）。プライバシー保護メカニズムは、「集計分析のみを許可し、ログに記録されたイベントまたは派生結果を個々のユーザーにマッチングできないようにするもの」として定義され、ユーザーごとのデータに対してイントロスペクションが可能にならないようにします（たとえば、RAPPOR などの差分プライバシー技術を使用して実装されます）。
  • [C-1-4] そのようなデータをデバイス上のユーザー ID（Account など）と関連付けてはなりません（データを関連付けるたびに明示的にユーザーの同意を得る場合を除きます）。
  • [C-1-5] そのようなデータを、現在のセクション（9.8.6 コンテンツ キャプチャ OS レベルおよびアンビエント データ）で概説している要件に従わない他の OS コンポーネントと共有してはなりません（共有するたびに明示的にユーザーの同意を得る場合を除きます）。これらの機能が Android SDK API（AmbientContext、HotwordDetectionService）としてビルドされていない場合に限ります。
  • [C-1-6] そのようなデータがなんらかの形式でデバイスに保存される場合ときに、ContentCaptureService 実装または独自の方法で収集するデータを削除するユーザー アフォーダンスを提供しなければなりません。ユーザーがデータを消去することを選択した場合は、それまでに収集したすべてのデータを削除しなければなりません。
  • [C-1-7] AppSearch または独自の方法で収集されたデータを Android プラットフォーム（ランチャーなど）に表示しないようにするユーザー アフォーダンスを提供しなければなりません。
  • [C-SR-1] インターネット権限をリクエストしないことが強く推奨されます。
  • [C-SR-2] 公開されているオープンソース実装に基づく構造化 API を通じてのみ、インターネットにアクセスすることが強く推奨されます。

新しい要件の開始

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

新しい要件の終了

システム API ContentCaptureService、AppSearchManager.index を実装するサービス、または上記のとおりデータをキャプチャする独自のサービスが含まれる場合、デバイス実装は:

  • [C-2-1] コンテンツ キャプチャ サービスをユーザーによるインストールが可能なアプリに置き換えられるようにしてはならず、プリインストール サービスのみが、そのようなデータをキャプチャできるようにしなければなりません。
  • [C-2-2] プリインストールのコンテンツ キャプチャ サービス メカニズム以外のアプリでそのようなデータをキャプチャできるようにしてはなりません。
  • [C-2-3] コンテンツ キャプチャ サービスを無効にするユーザー アフォーダンスを提供しなければなりません。
  • [C-2-4] セクション 9.1. 権限に記載されているとおり、コンテンツ キャプチャ サービスが持つ Android の権限を管理し、Android の権限モデルに従うユーザー アフォーダンスを省略してはなりません。

  • [C-SR-3] 下記を除き、サービスを他のシステム コンポーネントから分離しておくこと（サービスをバインドしない、プロセス ID を共有しないなど）が強く推奨されます。

    • 電話、連絡先、システム UI、メディア

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

9.8.7. クリップボードへのアクセス

デバイス実装は:

  • [C-0-1] サードパーティ アプリがデフォルトの IME であるか、現在フォーカスされているアプリである場合を除き、クリップボードのクリップデータを（たとえば ClipboardManager API を介して）返してはなりません。

  • [C-0-2] クリップボード データがクリップボード内に最後に配置されてから、またはクリップボードから読み取られてから 60 分以内に、クリップボード データを消去しなければなりません。

9.8.8. 位置情報

位置情報には、Android 位置情報クラスの情報（緯度、経度、標高など）と、位置情報に変換できる識別子が含まれます。位置情報には、DGPS（差分グローバル ポジショニング システム）のような細かいものから、国レベルの位置情報（国コードの位置情報 - MCC - モバイル カントリー コードなど）のような粗いものまであります。

ユーザーの位置情報を直接導出するか、ユーザーの位置情報に変換できる、位置情報タイプのリストを次に示します。これは包括的なリストではありませんが、位置情報が何から直接的または間接的に導出されるかについての例として使用してください。

  • GPS / GNSS / DGPS / PPP
    • グローバル ポジショニング ソリューション、グローバル ナビゲーション衛星システム、差分グローバル ポジショニング ソリューション
    • これには、未加工の GNSS 測定値と GNSS ステータスも含まれます。
      • 精度の高い位置情報は、未加工の GNSS 測定値から導出できます。
  • 次のような固有の ID を持つワイヤレス技術:
    • Wi-Fi アクセス ポイント（MAC、BSSID、名前、または SSID）
    • Bluetooth / BLE（MAC、BSSID、名前、または SSID）
    • UWB（MAC、BSSID、名前、または SSID）
    • 基地局 ID（3G、4G、5G、一意の ID を持つ将来のセルラー モデム技術を含む）

参考として、ACCESS_FINE_Location 権限または ACCESS_COARSE_Location 権限を必要とする Android API をご覧ください。

デバイス実装は:

  • [C-0-1] 明示的なユーザーの同意またはユーザーの操作なしで、デバイスの位置情報の設定と Wi-Fi / Bluetooth スキャン設定のオン / オフを行ってはなりません。
  • [C-0-2] 位置情報リクエスト履歴、アプリレベルの権限、位置を決定するための Wi-Fi / Bluetooth スキャンの使用状況を含め、位置情報に関連する情報にアクセスするユーザー アフォーダンスを提供しなければなりません。
  • [C-0-3] Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] を使用するアプリが、ユーザーが開始した緊急セッション（911 へのダイヤル、911 へのテキスト メッセージなど）であることを保証しなければなりません。ただし自動車では、衝突 / 事故が検出された場合（eCall の要件を満たすなど）、積極的なユーザー操作なしで車両が緊急セッションを開始しても構いません。
  • [C-0-4] 設定を変更せずにデバイスの位置情報の設定をバイパスする Emergency Location Bypass API の機能を保持しなければなりません。
  • [C-0-5] [ACCESS_BACKGROUND_LOCATION] 権限を使用してバックグラウンドのアプリが位置情報にアクセスした後、ユーザーにリマインドする通知をスケジュール設定しなければなりません。

9.8.9. インストール済みのアプリ

API レベル 30 以降をターゲットとする Androidor アプリは、他のインストール済みのアプリに関する詳細情報をデフォルトでは確認できません（Android SDK ドキュメントのパッケージへのアクセスをご覧ください）。

デバイス実装は:

  • [C-0-1] アプリがすでに、マネージド API を通じて他のインストール済みのアプリに関する詳細情報を確認できる場合を除き、API レベル 30 以降をターゲットとするアプリに対し、他のインストール済みのアプリに関する詳細情報を公開してはなりません。これには、デバイス実装者が追加したカスタムの API によって公開される詳細情報、またはファイルシステムを通じてアクセス可能な詳細情報が含まれますが、これらに限定されません。
  • [C-0-2] 外部ストレージ内の、他のアプリのアプリ専用ディレクトリにあるファイルへの読み書きアクセス権を、どのアプリにも付与してはなりません。例外は次のとおりです。
    • 外部ストレージ プロバイダ オーソリティ（DocumentsUI などのアプリ）。
    • アプリのストレージにファイルをダウンロードするために「ダウンロード」プロバイダ オーソリティを使用するダウンロード プロバイダ。
    • ACCESS_MTP 特権を使用して別のデバイスへのファイル転送を有効にする、プラットフォームで署名されたメディア転送プロトコル（MTP）アプリ。
    • 他のアプリをインストールする、INSTALL_PACKAGES 権限があるアプリは、APK 拡張ファイルの管理を目的として「obb」ディレクトリにのみアクセスできます。

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

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

  • [C-1-1] BugreportManager による BUGREPORT_MODE_TELEPHONY を介した接続バグレポートの生成をサポートしなければなりません。
  • [C-1-2] レポートを生成するために BUGREPORT_MODE_TELEPHONY を使用するたびにユーザーの同意を得なければならず、アプリからの今後のリクエストすべてに対する同意をユーザーに求めてはなりません。
  • [C-1-3] 明示的なユーザーの同意なしに、生成されたレポートをリクエスト元アプリに返してはなりません。
  • [C-1-4] BUGREPORT_MODE_TELEPHONY を使用して生成されたレポートは、少なくとも次の情報を含まれなければなりません。
    • TelephonyDebugService ダンプ
    • TelephonyRegistry ダンプ
    • WifiService ダンプ
    • ConnectivityService ダンプ
    • 呼び出し元パッケージの CarrierService インスタンスのダンプ（バインドされている場合）
    • 無線ログバッファ
    • SubscriptionManagerService ダンプ
  • [C-1-5] 生成するレポートに次の情報を含めてはなりません。
    • 接続のデバッグと直接関係のないあらゆる情報。
    • ユーザーがインストールしたあらゆるアプリのトラフィック ログ、またはユーザーがインストールしたアプリ / パッケージの詳細なプロファイル（UID は可、パッケージ名は不可）。
  • どのユーザー ID にも関連付けられていない追加情報を含んでも構いません（ベンダーログなど）。

バグレポートに追加情報（ベンダーログなど）が含まれ、その情報がプライバシー、セキュリティ、バッテリー、ストレージ、メモリに影響を与える場合、デバイス実装は:

  • [C-SR-1] 開発者向け設定をデフォルトで無効にすることが強く推奨されます。AOSP リファレンス実装は、開発者向け設定において、バグレポートにデバイス固有のベンダーログを追加するための Enable verbose vendor logging オプションを提供することで、これを満たしています。

9.8.11. データ blob の共有

Android では、BlobStoreManager を通じて、アプリがシステムにデータ blob を提供して、選択したアプリセットと共有できます。

SDK ドキュメントに記載されているとおり、共有データ blob をサポートする場合、デバイス実装は:

  • [C-1-1] アプリに属するデータ blob を、許可を意図した範囲を超えて共有してはなりません（つまり、デフォルトのアクセス範囲と、BlobStoreManager.session#allowPackageAccess()、BlobStoreManager.session#allowSameSignatureAccess()、または BlobStoreManager.session#allowPublicAccess() を使用して指定できる他のアクセスモードを変更してはなりません）。AOSP リファレンス実装はこれらの要件を満たしています。
  • [C-1-2] データ blob のセキュア ハッシュ（アクセスを制御するために使用）を、デバイスから送信したり、他のアプリと共有したりしてはなりません。

9.8.12. 楽曲認識

Android は、システム API MusicRecognitionManager を通じて、オーディオ レコードを指定して楽曲認識をリクエストし、MusicRecognitionService API を実装した特権アプリに楽曲認識を委任するメカニズムをサポートしています。

システム API MusicRecognitionManager を実装するサービスや、上記のようにオーディオ データをストリーミングする独自のサービスが含まれる場合、デバイス実装は:

  • [C-1-1] MusicRecognitionManager の呼び出し元が MANAGE_MUSIC_RECOGNITION 権限を保持することを強制しなければなりません。
  • [C-1-2] プリインストールされている単一の楽曲認識アプリが MusicRecognitionService を実装することを強制しなければなりません。
  • [C-1-3] ユーザーが、MusicRecognitionManagerService または MusicRecognitionService を、ユーザーによるインストールが可能なアプリまたはサービスに置き換えられるようにしてはなりません。
  • [C-1-4] MusicRecognitionManagerService がオーディオ レコードにアクセスし、MusicRecognitionService を実装するアプリに転送する際、AppOpsManager.noteOp / startOp の呼び出しを介してオーディオ アクセスが追跡されるようにしなければなりません。

キャプチャしたオーディオ データを保存する場合、MusicRecognitionManagerService または MusicRecognitionService のデバイス実装は:

  • [C-2-1] 未加工のオーディオまたはオーディオ フィンガープリントを、ディスクに一切保存してはならず、メモリに 14 日間を超えて保存してはなりません。
  • [C-2-2] そのようなデータを MusicRecognitionService 以外で共有してはなりません（共有するたびに明示的なユーザーの同意を得る場合を除きます）。

9.8.13. SensorPrivacyManager

デバイス実装のためにカメラやマイクの入力をオフにするソフトウェア アフォーダンスをユーザーに提供する場合、デバイス実装は:

  • [C-1-1] 関連する supportsSensorToggle() API メソッドについて、正確に true を返さなければなりません。
  • [C-1-2] ブロックされているマイクまたはカメラにアプリがアクセスしようとしたとき、センサーがブロックされていることを明確に示し、この要件を満たす AOSP 実装に従ってブロックを続行するかブロックを解除するかの選択を求める、拒否不可能なユーザー アフォーダンスをユーザーに提示しなければなりません。
  • [C-1-3] 空の（または偽の）カメラとオーディオ データのみをアプリに渡さなければならず、上記 [C-1-2] に従い提示されたユーザー アフォーダンスを介してユーザーがカメラまたはマイクをオンにしていないことを理由にエラーコードをレポートしてはなりません。

新しい要件の開始

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.9. データ ストレージの暗号化

デバイスはすべて、セクション 9.9.1. の要件を満たさなければなりません。このドキュメントよりも前の API レベルでリリースされたデバイスは、セクション 9.9.2 と 9.9.3 の要件を免除されます。代わりに、デバイスがリリースされた API レベルに対応する Android 互換性定義ドキュメントのセクション 9.9 の要件を満たさなければなりません。

9.9.1. ダイレクト ブート

デバイス実装は:

  • [C-0-1] ストレージの暗号化をサポートしない場合でも、ダイレクト ブートモードの API を実装しなければなりません。

  • [C-0-2] デバイス暗号化（DE）ストレージと証明書暗号化（CE）ストレージの場所をユーザーが利用できることをダイレクト ブート対応アプリに通知するために、引き続き ACTION_LOCKED_BOOT_COMPLETED インテントと ACTION_USER_UNLOCKED インテントをブロードキャストしなければなりません。

9.9.2. 暗号化の要件

デバイス実装は:

  • [C-0-1] デバイスにあるアプリの個人データ（/data パーティション）とアプリの共有ストレージ パーティション（/sdcard パーティション）が、永続的で取り外し不可能である場合は、暗号化しなければなりません。
  • [C-0-2] ユーザーが開封時の初期設定を完了した時点で、データ ストレージの暗号化をデフォルトで有効にしなければなりません。

  • [C-0-3] 次の 2 つの暗号化方法のいずれかを実装することにより、データ ストレージの暗号化に関する上記の要件を満たさなければなりません。

9.9.3. 暗号化方式

暗号化する場合、デバイス実装は:

  • [C-1-1] ユーザーに認証情報を求めずに起動し、ACTION_LOCKED_BOOT_COMPLETED メッセージがブロードキャストされてから、ダイレクト ブート対応アプリでデバイス暗号化（DE）ストレージにアクセスできるようにしなければなりません。
  • [C-1-2] ユーザーが認証情報（パスコード、PIN、パターン、指紋など）を提供してロック解除し、ACTION_USER_UNLOCKED メッセージがブロードキャストされて初めて、認証情報暗号化（CE）ストレージにアクセスできるようにしなければなりません。
  • [C-1-13] ユーザー提供の認証情報、登録されたエスクローキー、またはセクション 9.9.4 の要件を満たすリジューム オン リブートの実装なしで CE 保護ストレージをロック解除する方法を提供してはなりません。
  • [C-1-4] 確認付きブートを使用しなければなりません。
9.9.3.1. ファイルベースの暗号化とメタデータ暗号化

ファイルベースの暗号化とメタデータ暗号化を使用する場合、デバイス実装は:

  • [C-1-5] AES-256-XTS または Adiantum を使用して、ファイルの内容とファイルシステムのメタデータを暗号化しなければなりません。AES-256-XTS とは、XTS モードで動作する、暗号鍵長が 256 ビットの高度暗号化標準を指します。鍵の全長は 512 ビットです。Adiantum とは、https://github.com/google/adiantum で指定されている Adiantum-XChaCha12-AES を指します。ファイルシステムのメタデータとは、ファイルサイズ、所有権、モード、拡張属性（xattrs）などのデータのことです。
  • [C-1-6] AES-256-CBC-CTS、AES-256-HCTR2、Adiantum を使用して、ファイル名を暗号化しなければなりません。
  • [C-1-12] デバイスに高度暗号化標準（AES）命令（ARM ベースのデバイスでは ARMv8 暗号拡張、x86 ベースのデバイスでは AES-NI など）がある場合、ファイル名、ファイル コンテンツ、ファイルシステムのメタデータの暗号化には、Adiantum ではなく、上記の AES ベースのオプションを使用しなければなりません。
  • [C-1-13] CE 鍵と DE 鍵から必要なサブキー（ファイルごとの鍵など）を導出するために、暗号的に強力かつ非可逆の鍵導出関数（HKDF-SHA512 など）を使用しなければなりません。「暗号的に強力かつ非可逆」とは、鍵導出関数が少なくとも 256 ビットのセキュリティ強度を持ち、入力に対して擬似ランダム関数族として動作することを意味します。
  • [C-1-14] 異なる暗号用途（暗号化と鍵導出の両方、2 つの異なる暗号化アルゴリズムなど）に、同じファイルベースの暗号化（FBE）の鍵またはサブキーを使用してはなりません。
  • [C-1-15] 永続ストレージ上の暗号化ファイル コンテンツの削除されていないすべてのブロックが、ファイルとファイル内のオフセットの両方に依存する暗号鍵と初期化ベクトル（IV）の組み合わせを使用して暗号化されるようにしなければなりません。さらに、32 ビットの IV 長しかサポートしないインライン暗号化ハードウェアを使用して暗号化が行われる場合を除き、そのような組み合わせはすべて別個でなければなりません。
  • [C-1-16] 別個のディレクトリにある永続ストレージ上の削除されていないすべての暗号化ファイル名が、暗号鍵と初期化ベクトル（IV）の別個の組み合わせを使用して暗号化されるようにしなければなりません。

  • [C-1-17] 永続ストレージ上のすべての暗号化ファイル システム メタデータ ブロックが、暗号鍵と初期化ベクトル（IV）の別個の組み合わせを使用して暗号化されるようにしなければなりません。

  • CE および DE ストレージ領域とファイルシステムのメタデータを保護する鍵は:

    • [C-1-7] ハードウェア格納型キーストアに、暗号的にバインドされなければなりません。このキーストアは、確認付きブートと、デバイスのハードウェアのルート オブ トラストにバインドされなければなりません。
    • [C-1-8] CE 鍵は、ユーザーのロック画面認証情報にバインドされなければなりません。
    • [C-1-9] CE 鍵は、ユーザーがロック画面認証情報を指定しなかった場合、デフォルトのパスコードにバインドされなければなりません。
    • [C-1-10] 一意かつ明確でなければなりません（つまり、ユーザーの CE 鍵または DE 鍵が他のユーザーの CE 鍵または DE 鍵と一致しない）。
    • [C-1-11] 必須としてサポートされている暗号、鍵長、モードを使用しなければなりません。
    • [C-1-12] こちらに記載されているとおり、ブートローダーのロック解除とロックの際、安全に消去しなければなりません。

  • プリインストールの必須アプリ（アラーム、電話、メッセンジャー）をダイレクト ブートに対応させるべきです。

アップストリームの Android オープンソース プロジェクトは、Linux カーネルの「fscrypt」暗号化機能に基づくファイルベースの暗号化と、Linux カーネルの「dm-default-key」機能に基づくメタデータ暗号化について、優先的に実装を提供しています。

9.9.3.2. ユーザーごとのブロックレベルの暗号化

ユーザーごとのブロックレベルの暗号化を使用する場合、デバイス実装は:

  • [C-1-1] セクション 9.5 に記載されているとおり、マルチユーザー サポートを有効にしなければなりません。
  • [C-1-2] RAW パーティションまたは論理ボリュームを使用して、ユーザーごとのパーティションを提供しなければなりません。
  • [C-1-3] 基盤となるブロック デバイスの暗号化に、ユーザーごとに一意の別々の暗号鍵を使用しなければなりません。

  • [C-1-4] ユーザー パーティションのブロックレベルの暗号化に、AES-256-XTS を使用しなければなりません。

  • ユーザーごとのブロックレベルの暗号化デバイスを保護する鍵は:

    • [C-1-5] ハードウェア格納型キーストアに、暗号を用いてバインドされなければなりません。 このキーストアは、確認付きブートと、デバイスのハードウェアのルート オブ トラストにバインドされなければなりません。
    • [C-1-6] 対応するユーザーのロック画面認証情報にバインドされなければなりません。

ユーザーごとのブロックレベルの暗号化は、Linux カーネルの「dm-crypt」機能を使用して、ユーザーごとのパーティションで実装できます。

9.9.4. リジューム オン リブート

リジューム オン リブートを使用すると、OTA によって開始された再起動の後、ダイレクト ブートをまだサポートしていないアプリを含め、すべてのアプリの CE ストレージをロック解除できます。ユーザーはこの機能により、再起動後にインストール済みのアプリから通知を受け取ることができます。

リジューム オン リブートの実装では、攻撃者がデバイスを入手した際に、デバイスの電源が入っていて CE ストレージのロックが解除されており、OTA を受け取った後にユーザーがデバイスをロック解除した場合であっても、攻撃者がユーザーの CE 暗号化データを復元することは極めて困難であるということを引き続き保証しなければなりません。インサイダー攻撃耐性については、攻撃者がブロードキャスト暗号署名鍵へのアクセス権を得ることも想定しています。

具体的には次のとおりです。

  • [C-0-1] CE ストレージは、デバイスを物理的に所持し、下記の能力と制限がある攻撃者に対しても、読み取り可能であってはなりません。

    • ベンダーまたは企業の署名鍵を使用して任意のメッセージに署名できる。
    • OTA をデバイスに受信させることができる。
    • 下記を除き、ハードウェア（AP、フラッシュなど）の動作を変更できるが、そのような変更には少なくとも 1 時間の遅延と、RAM の内容を破壊する電源の入れ直しが含まれる。
    • 改ざん防止ハードウェア（Titan M など）の動作を変更できない。
    • ライブデバイスの RAM を読み取れない。
    • ユーザーの認証情報（PIN、パターン、パスワード）を取得できないか、入力させることができない。

たとえば、こちらの記載内容をすべて実装して遵守するデバイス実装は、[C-0-1] を遵守することになります。

9.10. デバイスの完全性

次の要件により、デバイスの完全性の状態に透明性が確保されます。デバイス実装は:

  • [C-0-1] システム API メソッド PersistentDataBlockManager.getFlashLockState() を通じて、ブートローダーの状態がシステム イメージの書き込みを許すかどうかを正しくレポートしなければなりません。

  • [C-0-2] デバイスの完全性のために確認付きブートをサポートしなければなりません。

デバイス実装が、以前の Android バージョンで確認付きブートをサポートせずにすでにリリースされ、システム ソフトウェア アップデートでこの機能のサポートを追加できない場合は、要件を免除しても構いません。

確認付きブートは、デバイス ソフトウェアの完全性を保証する機能です。この機能をサポートする場合、デバイス実装は:

  • [C-1-1] プラットフォーム機能フラグ android.software.verified_boot を宣言しなければなりません。
  • [C-1-2] ブート シーケンスごとに確認を実施しなければなりません。
  • [C-1-3] ルート オブ トラストである不変のハードウェア キーから開始してシステム パーティションに至るまで、確認しなければなりません。
  • [C-1-4] 確認の各ステージを実装して、次のステージのバイトすべての完全性と正真性をチェックしてから、次のステージのコードを実行しなければなりません。
  • [C-1-5] ハッシュ アルゴリズム（SHA-256）と公開鍵サイズ（RSA-2048）について、NIST による現在の推奨事項と同程度強力な検証アルゴリズムを使用しなければなりません。
  • [C-1-6] システムの確認が失敗したときにブートを完了できるようにしてはなりません。ただし、ブートを試行することにユーザーが同意した場合を除きます。その場合、未確認のストレージ ブロックのデータを使用してはなりません。
  • [C-1-7] ユーザーがブートローダーを明示的にロック解除した場合を除き、デバイスの確認済みパーティションを変更できるようにしてはなりません。
  • [C-SR-1] デバイスにディスクリート チップが複数ある場合、そうしたチップそれぞれのブートプロセスは、ブート時にすべてのステージを確認することが強く推奨されます。
  • [C-1-8] ブートローダーがロック解除されているかどうかを格納するために、改ざん検出可能なストレージを使用しなければなりません。改ざん検出可能なストレージとは、Android 内部からストレージが改ざんされたかどうかをブートローダーが検出できることを意味します。
  • [C-1-9] ブートローダー ロックモードからブートローダー ロック解除モードへの移行を許可する前に、デバイスの使用中にプロンプトを表示し、物理的な確認をユーザーに要求しなければなりません。
  • [C-1-10] Android が使用するパーティション（ブート パーティション、システム パーティションなど）のロールバック保護を実装し、最小許容 OS バージョンの決定に使用するメタデータを格納するために、改ざん検出可能なストレージを使用しなければなりません。
  • [C-1-11] 「9.12 データの削除」に従い、ブートローダーのロック解除とロックの際、userdata パーティションと NVRAM スペースを含め、すべてのユーザーデータを安全に消去しなければなりません。
  • [C-SR-2] 確認付きブートで保護された各パーティションを元にした信頼チェーンによって、すべての特権アプリ APK ファイルを確認することが強く推奨されます。
  • [C-SR-3] 特権アプリが APK ファイルの外部から読み込んだ実行可能アーティファクト（動的に読み込んだコードやコンパイルしたコードなど）を、その実行前に確認するか、まったく実行しないことが強く推奨されます。
  • 永続的なファームウェアを持つコンポーネント（モデム、カメラなど）のためにロールバック保護を実装すべきであり、最小許容バージョンの決定に使用するメタデータを格納するために、改ざん検出可能なストレージを使用すべきです。

デバイス実装が、以前の Android バージョンで C-1-8 から C-1-11 をサポートせずにすでにリリースされ、システム ソフトウェア アップデートでこれらの要件のサポートを追加できない場合は、要件を免除しても構いません。

アップストリームの Android オープンソース プロジェクトは、external/avb/ リポジトリでこの機能の優先実装を提供しており、Android を読み込むために使用するブートローダーに統合できます。

デバイス実装

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

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

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

新しい要件の開始

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

新しい要件の終了

デバイス実装が、以前の Android バージョンで信頼できる鍵に対してファイルのコンテンツを確認する機能なくすでにリリースされ、システム ソフトウェア アップデートでこの機能のサポートを追加できない場合は、要件を免除しても構いません。アップストリームの Android オープンソース プロジェクトは、Linux カーネルの fs-verity 機能に基づくこの機能の優先実装を提供しています。

デバイス実装は:

Android Protected の確認 API をサポートする場合、デバイス実装は:

  • [C-3-1] ConfirmationPrompt.isSupported() API について true をレポートしなければなりません。

  • [C-3-2] カーネルを含め、Android OS で実行されているコードが、悪意のあるものかどうかにかかわらず、ユーザーの操作なしで肯定的なレスポンスを生成できないようにしなければなりません。

  • [C-3-3] カーネルを含め、Android OS が不正使用された場合であっても、ユーザーが表示されたメッセージを確認して承認できるようにしなければなりません。

9.11. 鍵と認証情報

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

  • [C-0-1] 少なくとも 8,192 個の鍵をインポートまたは生成できるようにしなければなりません。
  • [C-0-2] ロック画面認証は、失敗した試行間に時間間隔を実装しなければなりません。n を失敗した試行回数として、時間間隔は 9 < n < 30 に対して少なくとも 30 秒でなければなりません。n > 29 の場合、時間間隔の値は 30*2^floor((n-30)/10)) 秒または 24 時間以上のいずれか小さいほうでなければなりません。
  • 生成できる鍵の数を制限すべきではありません。

新しい要件の開始

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

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

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

新しい要件の終了

セキュアロック画面をサポートする場合、デバイス実装は:

  • [C-1-1] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
  • [C-1-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、ECDH（IKeyMintDevice がサポートされている場合）、3DES、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト（AOSP）は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザ ベースの隔離オプションをセキュアに実装する方法を選択することもできます。
  • [C-1-3] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存する必要があります。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer（HAL）と Trusty を提供しており、これを使用してこの要件を満たすことができます。
  • [C-1-4] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。

なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint 機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵証明書をサポートする必要があるという要件を免除されます。

  • [C-1-5] ロック解除状態からロック状態への遷移のためのスリープ タイムアウトを、最小許容タイムアウト 15 秒以下でユーザーが選択できるようにしなければなりません。ヘッドユニットがオフにされるかユーザーが替わると必ず画面をロックする自動車用デバイスには、スリープのタイムアウト設定がなくても構いません。
  • [C-1-6] 次のいずれかをサポートしなければなりません。
    • IKeymasterDevice 3.0、
    • IKeymasterDevice 4.0、
    • IKeymasterDevice 4.1、
    • IKeyMintDevice version 1、または
    • IKeyMintDevice version 2。
  • [C-SR-1] IKeyMintDevice バージョン 1 をサポートすることが強く推奨されます。

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

AOSP 実装は、階層型認証モデル（ナレッジファクトリーに基づく第 1 の認証が、第 2 の高度な生体認証やそれより弱い第 3 のモダリティによって支えられる）に従っています。

デバイス実装は:

  • [C-SR-1] 第 1 の認証方法として、次のいずれか 1 つのみを設定することが強く推奨されます。

    • 数字の PIN
    • 英数字のパスワード

    • 正確に 3x3 ドットのグリッドによるスワイプ パターン

      なお、このドキュメントでは上記の認証方法のことを、推奨される第 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 の桁数がわからないようにすることが強く推奨されます。

新しい要件の終了

デバイス実装が、推奨される第 1 の認証方法を追加または変更し、画面をロックするセキュアな方法として新しい認証方法を使用する場合、新しい認証方法は:

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

  • [C-3-1] 入力の最短許容長のエントロピーが 10 ビットより大きくなければなりません。
  • [C-3-2] 可能性のあるすべての入力の最大エントロピーが 18 ビットより大きくなければなりません。
  • [C-3-3] 新しい認証方法は、AOSP で実装され提供されている、推奨される第 1 の認証方法（PIN、パターン、パスワード）のいずれも置き換えてはなりません。
  • [C-3-4] DevicePolicyManager.setRequiredPasswordComplexity() を介して PASSWORD_COMPLEXITY_NONE より制限的な複雑性定数で、または DevicePolicyManager.setPasswordQuality() を介して PASSWORD_QUALITY_BIOMETRIC_WEAK より制限的な定数で、Device Policy Controller（DPC）アプリがパスワード要件ポリシーを設定した場合、新しい認証方法を無効にしなければなりません。
  • [C-3-5] 新しい認証方法は、72 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワード）にフォールバックするか、データのプライバシーを保護するために一部のデータがバックアップされていないことをユーザーに明確に開示しなければなりません。

デバイス実装が、ロック画面をロック解除するための推奨される第 1 の認証方法を追加または変更し、画面をロックするセキュアな方法として扱われる生体認証に基づく新しい認証方法を使用する場合、新しい方法は:

  • [C-4-1] セクション 7.3.10 に記載されているクラス 1（旧称利便性）の要件をすべて満たさなければなりません。
  • [C-4-2] 既知のシークレットに基づく、推奨される第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければなりません。
  • [C-4-3] Device Policy Controller（DPC）アプリが、関連する生体認証フラグのいずれか（すなわち、KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE、または KEYGUARD_DISABLE_IRIS）を指定してメソッド DevicePolicyManager.setKeyguardDisabledFeatures() を呼び出すことでキーガード機能ポリシーを設定した場合、無効にし、推奨される第 1 の認証のみで画面をロック解除できるようにしなければなりません。

生体認証方法が、セクション 7.3.10 に記載されているクラス 3（旧称強）の要件を満たさない場合:

  • [C-5-1] DevicePolicyManager.setRequiredPasswordComplexity() を介して PASSWORD_COMPLEXITY_LOW より制限的な複雑性バケットで、または DevicePolicyManager.setPasswordQuality() メソッドを使用して PASSWORD_QUALITY_BIOMETRIC_WEAK より制限的な品質定数で、Device Policy Controller（DPC）アプリがパスワード要件品質ポリシーを設定した場合、認証方法を無効にしなければなりません。
  • [C-5-2] セクション 7.3.10 の [C-1-7] と [C-1-8] に記載されているとおり、推奨される第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。
  • [C-5-3] 認証方法は、セキュアロック画面として扱われてはならず、このセクションで後述する、C-8 で始まる要件を満たさなければなりません。

デバイス実装が、ロック画面をロック解除するための認証方法を追加または変更し、新しい認証方法が物理トークンまたは場所に基づいている場合:

  • [C-6-1] 既知のシークレットに基づく、推奨される第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければならず、セキュアロック画面として扱われる要件を満たさなければなりません。
  • [C-6-2] Device Policy Controller（DPC）アプリが次のいずれかでポリシーを設定した場合、新しい方法を無効にし、推奨される第 1 の認証方法のいずれかのみで画面をロック解除できるようにしなければなりません。
  • [C-6-3] 少なくとも 4 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。物理トークンが C-X の TrustAgent 実装の要件を満たしている場合は、代わりに C-9-5 で規定されているタイムアウト制限が適用されます。
  • [C-6-4] 新しい認証方法は、セキュアロック画面として扱われてはならず、C-8 で後述する制約に従わなければなりません。

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

  • [C-7-1] デバイスロックが延期された場合、または信頼エージェントによってロック解除できる場合は、設定メニューとロック画面に明確に示さなければなりません。たとえば、AOSP は、設定メニューに「自動ロック設定」と「電源ボタンですぐにロックする」の説明文を表示し、ロック画面に区別しやすいアイコンを表示することで、この要件を満たしています。
  • [C-7-2] KEYGUARD_DISABLE_TRUST_AGENTS 定数など、DevicePolicyManager クラスのすべての信頼エージェント API を尊重し、完全に実装しなければなりません。
  • [C-7-3] TrustAgentService.addEscrowToken() 関数を、メインの個人用デバイスとして使用されるデバイス（ハンドヘルドなど）に完全に実装してはなりませんが、通常共有されるデバイス実装（Android テレビデバイス、自動車デバイスなど）には完全に実装しても構いません。
  • [C-7-4] TrustAgentService.addEscrowToken() によって追加されたすべての保存済みトークンを暗号化しなければなりません。
  • [C-7-5] 暗号鍵またはエスクロー トークンを、鍵が使用されるのと同じデバイスに保存してはなりません。たとえば、スマートフォンに保存されている鍵でテレビのユーザー アカウントをロック解除できます。自動車デバイスの場合、エスクロー トークンは車両のいかなる部分にも保存できません。
  • [C-7-6] エスクロー トークンでデータ ストレージを復号できるようにする前に、セキュリティへの影響についてユーザーに通知しなければなりません。
  • [C-7-7] 推奨される第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければなりません。
  • [C-7-8] ユーザーの安全が懸念される場合（ドライバーの注意散漫など）を除き、少なくとも 72 時間以内ごとに 1 回、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。
  • [C-7-9] ユーザーの安全が懸念される場合（ドライバーの注意散漫など）を除き、セクション 7.3.10 の [C-1-7] と [C-1-8] に記載されているとおり、推奨される第 1 の認証方法（PIN、パターン、パスワードなど）のいずれかをユーザーに求めなければなりません。
  • [C-7-10] セキュアロック画面として扱われてはならず、C-8 で後述する制約に従わなければなりません。
  • [C-7-11] メインの個人用デバイス（ハンドヘルドなど）の信頼エージェントがデバイスをロック解除できるようにしてはなりません。すでにロック解除されたデバイスを最大 4 時間までロック解除状態に保つためにのみ、使用できます。AOSP の TrustManagerService のデフォルト実装はこの要件を満たしています。
  • [C-7-12] エスクロー トークンをストレージ デバイスからターゲット デバイスに渡すために、暗号的にセキュアな（UKEY2 など）通信チャネルを使用しなければなりません。

デバイス実装が、上記のセキュアなロック画面でないロック画面をロック解除するための認証方法を追加または変更し、キーガードをロック解除するための新しい認証方法を使用する場合:

  • [C-8-1] DevicePolicyManager.setPasswordQuality() メソッドを介して PASSWORD_QUALITY_NONE より制限的な品質定数で、または DevicePolicyManager.setRequiredPasswordComplexity() を介して PASSWORD_COMPLEXITY_NONE より制限的な複雑性定数で、Device Policy Controller（DPC）アプリがパスワード品質ポリシーを設定する場合、新しい認証方法を無効にしなければなりません。
  • [C-8-2] DevicePolicyManager.setPasswordExpirationTimeout() によって設定されたパスワード有効期限タイマーをリセットしてはなりません。
  • [C-8-3] サードパーティ アプリがロック状態を変更するために使用する API を公開してはなりません。

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

  • [C-9-1] デバイスのデフォルト ディスプレイがロックされているときはセカンダリ仮想ディスプレイをロックし、デバイスのデフォルト ディスプレイがロック解除されているときはセカンダリ仮想ディスプレイをロック解除しなければなりません。

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

  • [C-10-1] 仮想デバイスごとに別々のロック状態をサポートしなければなりません。
  • [C-10-2] アイドル タイムアウト時にすべての仮想デバイスを切断しなければなりません。
  • [C-10-3] アイドル タイムアウトがなければなりません。
  • [C-10-4] ハンドヘルド デバイスに必要なロックダウン ユーザー アフォーダンスなどを介してユーザーがロックダウンを開始したとき、すべてのディスプレイをロックしなければなりません（セクション 2.2.5[9.11/H-1-2] を参照）。
  • [C-10-5] ユーザーごとに個別の仮想デバイス インスタンスがなければなりません。
  • [C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy で示されている場合、VirtualDeviceManager を介した関連する入力イベントの作成を無効にしなければなりません
  • [C-10-7] 仮想デバイスごとに別のクリップボードを使用しなければなりません（または、仮想デバイスのクリップボードを無効にしなければなりません）。
  • [C-10-11] 仮想デバイスの認証 UI（知識要素の入力や生体認証プロンプトなど）を無効にしなければなりません。
  • [C-10-12] 仮想デバイスから開始されたインテントを、同じ仮想デバイスでのみ表示するように制限しなければなりません。
  • [C-10-13] Android Keystore システムでのユーザー認証承認として、仮想デバイスのロック状態を使用してはなりません。KeyGenParameterSpec.Builder.setUserAuthentication* をご覧ください。

ターゲット デバイスの初期設定の場合など、ユーザーがプライマリ認証の知識要素をソースデバイスからターゲット デバイスに転送できるようにする場合、デバイス実装は:

  • [C-11-1] 知識要素をソースデバイスからターゲット デバイスに転送するときに、Google Cloud Key Vault サービスに記載されているものと同様の保護保証で知識要素を暗号化しなければなりません。これにより、知識要素をリモートで復号したり、知識要素を使用していずれかのデバイスをリモートでロック解除したりできないようにすることができます。
  • [C-11-2] ソースデバイスで、知識要素をターゲット デバイスに転送する前にソースデバイスの知識要素を確認するようユーザーに求めなければなりません。
  • [C-11-3] 第 1 の認証用の知識要素が設定されていないターゲット デバイスで、その知識要素をターゲット デバイスの第 1 の認証用の知識要素に設定する前に、かつソースデバイスから転送されたデータを利用できるようにする前に、ターゲット デバイスで転送された知識要素を確認するようユーザーに求めなければなりません。

セキュアロック画面があり、FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE フラグを指定して TrustAgentService.grantTrust() システム API を呼び出す信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:

  • [C-12-1] 自身のロック画面を備えた近接する物理デバイスに接続されており、かつユーザーがそのロック画面に対して ID を認証した場合に限り、フラグを指定して grantTrust() を呼び出さなければなりません。近接デバイスは、ユーザーによる 1 回限りのロック解除後に、手首への装着、または持ち運びを検知するメカニズムを使用することで、ユーザー認証の要件を満たすことができます。
  • [C-12-2] ボタンの押下や表示のタイムアウトなどにより画面がオフになり、TrustAgent が信頼を取り消さなかった場合、デバイス実装を TrustState.TRUSTABLE 状態にしなければなりません。AOSP はこの要件を満たしています。
  • [C-12-3] TrustAgent が C-12-1 の要件に基づいて引き続き信頼を付与している場合にのみ、デバイスを TrustState.TRUSTABLE から TrustState.TRUSTED の状態に移行しなければなりません。
  • [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 を使用しなければなりません。

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

  • [C-13-8] 属性 android:canDisplayOnRemoteDevices、またはメタデータ android.activity.can_display_on_remote_devices が false に設定されているアクティビティが、仮想デバイスで開始されないようにブロックしなければなりません。
  • [C-13-9] 明示的にストリーミングを有効にしておらず、SurfaceView#setSecure、FLAG_SECURE、または SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS などを介してデリケートなコンテンツを表示することを示しているアクティビティが、仮想デバイスで開始されないようにブロックしなければなりません。
  • [C-13-10] 仮想デバイスから開始されたアプリのインストールを無効にしなければなりません。

DeviceStateManager を通じて個別のディスプレイ電源状態をサポートし、かつ、KeyguardDisplayManager を通じて個別のディスプレイ ロック状態をサポートする場合、デバイス実装は:

  • [C-SR-2] セクション 9.11.1 で規定されている要件を満たす認証情報、またはセクション 7.3.10 で規定されているクラス 1 以上の仕様を満たす生体認証を利用して、デフォルトのデバイス ディスプレイから独立したロック解除を行えるようにすることが強く推奨されます。
  • [C-SR-3] 定義済みのディスプレイ タイムアウトを介して個別のディスプレイ ロック解除を制限することが強く推奨されます。
  • [C-SR-4] プライマリ ハンドヘルド デバイスからロックダウンを通じて、ユーザーがすべてのディスプレイをグローバルにロックできるようにすることが強く推奨されます。

9.11.2. StrongBox

Android Keystore システムを使用すると、アプリ デベロッパーは暗号鍵を専用のセキュア プロセッサと、前述の隔離された実行環境に保存できます。このような専用のセキュア プロセッサを「StrongBox」と呼びます。下記の要件 C-1-3 から C-1-11 は、デバイスが StrongBox として適格であるために満たさなければならない要件を規定しています。

専用のセキュア プロセッサがあるデバイス実装は:

  • [C-SR-1] StrongBox をサポートすることが強く推奨されます。StrongBox は今後のリリースで要件になる可能性があります。

StrongBox をサポートする場合、デバイス実装は:

  • [C-1-1] FEATURE_STRONGBOX_KEYSTORE を宣言しなければなりません。

  • [C-1-2] キーストアとセキュアなユーザー認証を支えるために使用される専用のセキュア ハードウェアを提供しなければなりません。専用のセキュア ハードウェアは、他の目的にも使用しても構いません。

  • [C-1-3] キャッシュ、DRAM、コプロセッサ、またはその他のコアリソースをアプリ プロセッサ（AP）と共有しない独立した CPU がなければなりません。

  • [C-1-4] AP と共有する周辺機器が、StrongBox 処理を変更したり、StrongBox から情報を取得したりできないようにしなければなりません。AP は、StrongBox へのアクセスを無効化またはブロックしても構いません。

  • [C-1-5] AP による操作の影響を受けない、妥当な正確度（+-10%）の内部クロックがなければなりません。

  • [C-1-6] 一様分布で予測不可能な出力を生成する真正乱数ジェネレータがなければなりません。

  • [C-1-7] 物理的侵入や障害に対する耐性を含む、耐タンパー性がなければなりません。

  • [C-1-8] 電力、タイミング、電磁放射、熱放射のサイドチャネルを介した情報漏えいに対する耐性を含むサイドチャネル耐性がなければなりません。

  • [C-1-9] コンテンツの機密性、完全性、真正性、一貫性、最新性を保証するセキュア ストレージがなければなりません。StrongBox API で許可されている場合を除き、ストレージの読み取りまたは変更ができてはなりません。

  • [C-1-3] から [C-1-9] の遵守を検証するために、デバイス実装は:

    • [C-1-10] Secure IC Protection Profile BSI-CC-PP-0084-2014 について認証されたハードウェア、または Common Criteria Application of Attack Potential to Smartcards による高攻撃性脆弱性評価を盛り込んで国認定の試験機関によって評価されたハードウェアを含まなければなりません。
    • [C-1-11] Common Criteria Application of Attack Potential to Smartcards による高攻撃性脆弱性評価を盛り込んで国認定の試験機関によって評価されたファームウェアを含まなければなりません。
    • [C-SR-2] セキュリティ ターゲット、AVA_VAN.5 で拡張された評価保証レベル（EAL）5 を使用して評価されたハードウェアを含むことが強く推奨されます。EAL 5 認証は今後のリリースで要件になる可能性があります。
    • [C-SR-3] インサイダー攻撃耐性（IAR）を提供することが強く推奨されます。つまり、ファームウェア署名鍵にアクセスできるインサイダーが、StrongBox のシークレットの漏洩、機能のセキュリティ要件の回避、またはユーザーの機密データへのアクセスを可能にするファームウェアを生成できないようにします。IAR の実装で推奨される方法は、IAuthSecret HAL を介してプライマリ ユーザー パスワードが提供されたときにのみ、ファームウェアをアップデートできるようにすることです。

9.11.3. ID 認証情報

ID 認証情報システムは、android.security.identity.* パッケージのすべての API を実装することで定義され、実現されます。これらの API を使用すると、アプリ デベロッパーはユーザー ID ドキュメントの保存と取得を行うことができます。デバイス実装は:

  • [C-SR-1] ID 認証情報システムを実装することが強く推奨されます。

ID 認証情報システムを実装する場合、デバイス実装は:

  • [C-1-1] IdentityCredentialStore#getInstance() メソッドについて非 null を返さなければなりません。

  • [C-1-2] カーネル以上で動作するコードから安全に隔離されたエリアで、信頼できるアプリと通信するコードを備えた ID 認証情報システム（android.security.identity.* API など）を実装しなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。

  • [C-1-3] ID 認証情報システムの実装に必要な暗号オペレーション（android.security.identity.* API など）は、信頼できるアプリで完全に実施しなければならず、秘密鍵のマテリアルは、より高位の API（createEphemeralKeyPair() メソッドなど）で特に要求されない限り、隔離された実行環境から離れてはなりません。

  • [C-1-4] 信頼できるアプリは、Android が誤動作する場合や不正使用される場合であっても、セキュリティ プロパティが影響を受けないように実装されなければなりません（アクセス制御条件が満たされない限り認証情報データを解放しない、任意のデータに対して MAC を生成できないなど）。

アップストリームの Android オープンソース プロジェクトは、ID 認証情報システムの実装に使用できる信頼できるアプリ（libeic）のリファレンス実装を提供します。

9.12. データの削除

デバイス実装はすべて:

  • [C-0-1] 「データの初期化」を行うメカニズムをユーザーに提供しなければなりません。
  • [C-0-2] 「データの初期化」を行う際に userdata ファイルシステムのすべてのデータを削除しなければなりません。
  • [C-0-3] 「データの初期化」を行う際に NIST SP800-88 など、関連する業界基準を満たす方法でデータを削除しなければなりません。
  • [C-0-4] プライマリ ユーザーの Device Policy Controller アプリによって DevicePolicyManager.wipeData() API が呼び出されたとき、上記「データの初期化」プロセスをトリガーしなければなりません。
  • 論理データ消去のみを行う高速データワイプ オプションを提供しても構いません。

9.13. セーフブート モード

Android には、プリインストールのシステムアプリのみ実行を許可し他のサードパーティ アプリは無効にして起動するモードである、セーフブート モードがあります。この「セーフブート モード」と呼ばれるモードでは、有害な可能性があるサードパーティ アプリをアンインストールする機能がユーザーに提供されます。

デバイス実装は:

  • [C-SR-1] セーフブート モードを実装することが強く推奨されます。

セーフブート モードを実装する場合、デバイス実装は:

  • [C-1-1] サードパーティ アプリが Device Policy Controller であり、UserManager.DISALLOW_SAFE_BOOT フラグが true に設定されている場合を除き、デバイスにインストールされているサードパーティ アプリから中断できない方法でセーフブート モードに入るオプションをユーザーに提供しなければなりません。

  • [C-1-2] セーフモードでサードパーティ アプリをアンインストールする機能をユーザーに提供しなければなりません。

  • 通常のブートとは異なるワークフローを使用してブートメニューからセーフブート モードに入るオプションをユーザーに提供すべきです。

9.14. 自動車の車両システムの分離

Android 自動車デバイスは、車両 HAL を使用して CAN バスなどの車両ネットワークでメッセージを送受信することで、重要な車両サブシステムとデータを交換することが想定されます。

データ交換は、Android フレームワーク レイヤの下にセキュリティ機能を実装して、これらのサブシステムの悪意ある、または意図しない操作を防止することで保護できます。

9.15. サブスクリプション プラン

「サブスクリプション プラン」とは、SubscriptionManager.setSubscriptionPlans() を通じて携帯通信会社によって提供される請求関係プランの詳細を指します。

デバイス実装はすべて:

  • [C-0-1] サブスクリプション プランの提供元の携帯通信会社アプリに対してのみ、サブスクリプション プランを返さなければなりません。
  • [C-0-2] サブスクリプション プランをリモートでバックアップまたはアップロードしてはなりません。
  • [C-0-3] SubscriptionManager.setSubscriptionOverrideCongested() など、有効なサブスクリプション プランを現在提供している携帯通信会社アプリからのオーバーライドのみを許可しなければなりません。

9.16. アプリデータの移行

あるデバイスから別のデバイスにデータを移行する機能が含まれ、コピーするアプリデータを、アプリ デベロッパーが android:fullBackupContent 属性を介してマニフェストで設定したものに限らない場合、デバイス実装は:

  • [C-1-1] 9.11.1 セキュアロック画面と認証に記載されているとおり、ユーザーが第 1 の認証を設定していないデバイスから、アプリデータの転送を開始してはなりません。
  • [C-1-2] データを転送する前に、ソースデバイスの第 1 の認証を確実に確認し、ソースデバイスのデータをコピーする意思をユーザーに確認しなければなりません。
  • [C-1-3] デバイス間の移行において、ソースデバイスとターゲット デバイスの両方が正規の Android デバイスであり、ブートローダーがロックされていることを確認するために、セキュリティ キー証明書を使用しなければなりません。
  • [C-1-4] 同じパッケージ名と署名証明書を使用して、ターゲット デバイス上の同じアプリに対してのみ、アプリデータを移行しなければなりません。
  • [C-1-5] デバイス間データ移行によってソースデバイスのデータが移行されたことを、設定メニューに表示しなければなりません。ユーザーがこの表示を削除できるべきではありません。

9.17. Android Virtualization Framework

デバイスが 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 仮想化フレームワーク 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 を適切に行わなければなりません（正しい値を提供しなければなりません）。

10. ソフトウェア互換性テスト

デバイス実装は、このセクションに記載されているすべてのテストに合格しなければなりません。 しかし、完全に包括的なソフトウェア テスト パッケージというものはありません。このためデバイス実装者は、Android オープンソース プロジェクトから入手できる Android のリファレンス実装と優先実装に対して行う変更を可能な限り最小限に抑えることが強く推奨されます。これにより、互換性の問題をもたらすバグが導入され、再作業やデバイスのアップデートが必要となるリスクを最小限に抑えることができます。

10.1. 互換性テストスイート

デバイス実装は:

  • [C-0-1] デバイスの最終出荷ソフトウェアを使用して、Android オープンソース プロジェクトから入手可能な Android 互換性テストスイート（CTS）に合格しなければなりません。

  • [C-0-2] CTS で不明確な点があった場合や、リファレンス ソースコードの部分的な再実装を行う場合は、互換性を確保しなければなりません。

CTS は、実際のデバイスで実行するように設計されています。他のソフトウェアと同様に、CTS 自体にもバグが含まれている可能性があります。CTS はこの互換性定義とは別にバージョニングされ、Android 14 用に CTS の複数のリビジョンがリリースされる可能性があります。

デバイス実装は:

  • [C-0-3] デバイス ソフトウェアが完成した時点で利用可能な最新バージョンの CTS に合格しなければなりません。

  • 可能な限り、Android オープンソース ツリーのリファレンス実装を使用すべきです。

10.2. CTS 検証ツール

CTS 検証ツールは互換性テストスイートに含まれています。カメラやセンサーの正常な機能など、自動システムではテストできない機能をテストするために、人間のオペレーターが実行するためのものです。

デバイス実装は:

  • [C-0-1] CTS 検証ツールで、該当するすべてのケースが正しく実行されなければなりません。

CTS 検証ツールには、オプションのハードウェアを含め、さまざまな種類のハードウェア用のテストがあります。

デバイス実装は:

  • [C-0-2] 搭載しているハードウェア用のすべてのテストに合格しなければなりません。たとえば、デバイスに加速度計が搭載されている場合は、CTS 検証ツールで加速度計のテストケースが正しく実行されなければなりません。

この互換性定義ドキュメントで任意とされている機能のテストケースは、スキップまたは省略しても構いません。

  • [C-0-2] 上記のとおり、すべてのデバイスとすべてのビルドで、CTS 検証ツールが正しく実行されなければなりません。ただし、ビルドの多くはよく似ているため、デバイス実装者は、わずかな違いしかないビルドで CTS 検証ツールを明示的に実行することは求められていません。具体的には、CTS 検証ツールに合格した実装との違いが、含まれるロケール、ブランディングなどのセットのみであるデバイス実装は、CTS 検証ツールのテストを省略しても構いません。

11. アップデート可能なソフトウェア

  • [C-0-1] デバイス実装は、システム ソフトウェア全体を置き換えるメカニズムを備えていなければなりません。このメカニズムは、「ライブ」アップグレードを実施する必要はありません。つまり、デバイスの再起動が必要となっても構いません。デバイスにプリインストールされているソフトウェア全体を置き換えることができるのであれば、どの方法でも使用できます。たとえば、次のどの方法でもこの要件を満たしています。

    • 再起動によるオフライン アップデートを伴う「無線（OTA）」ダウンロード。
    • ホスト PC から USB 経由で行う「テザリング」アップデート。
    • 再起動による「オフライン」アップデートとリムーバブル ストレージ上のファイルからのアップデート。

  • [C-0-2] 使用するアップデート メカニズムは、ユーザーデータをワイプせずにアップデートをサポートしなければなりません。つまりアップデート メカニズムは、アプリの個人データとアプリの共有データを保持しなければなりません。なお、アップストリームの Android ソフトウェアには、この要件を満たすアップデート メカニズムが含まれています。

  • [C-0-3] アップデート全体が署名されていなければならず、デバイス上のアップデート メカニズムは、デバイスに保存された公開鍵に対してアップデートと署名を検証しなければなりません。

  • [C-SR-1] 署名メカニズムは、SHA-256 でアップデートをハッシュし、ECDSA NIST P-256 を使用して公開鍵に対してハッシュを検証することが強く推奨されます。

802.11 や Bluetooth PAN（パーソナル エリア ネットワーク）プロファイルなど、定額制データ接続のサポートが含まれる場合、デバイス実装は:

  • [C-1-1] 再起動によるオフライン アップデートを伴う OTA ダウンロードをサポートしなければなりません。

デバイス実装は、システム イメージが OTA の後に想定される結果とバイナリ同一であることを検証すべきです。Android 5.1 から追加された、アップストリームの Android オープンソース プロジェクトのブロックベース OTA 実装は、この要件を満たしています。

また、デバイス実装は A/B システム アップデートをサポートすべきです。AOSP は、ブート コントロール HAL を使用してこの機能を実装しています。

リリース後であるものの、妥当な製品寿命内にデバイス実装でエラーが見つかり、Android 互換性チームとの協議において、サードパーティ アプリの互換性に影響を与えると判断された場合:

  • [C-2-1] デバイス実装者は、前述のメカニズムに従って適用できる、利用可能なソフトウェア アップデートを介してエラーを修正しなければなりません。

Android には、デバイス所有者アプリ（存在する場合）でシステム アップデートのインストールを制御できる機能があります。デバイスのシステム アップデート サブシステムで android.software.device_admin をレポートする場合、デバイス実装は:

  • [C-3-1] SystemUpdatePolicy クラスに記載されている動作を実装しなければなりません。

12. ドキュメントの変更履歴

このリリースにおける互換性定義に対する変更の概要は次のとおりです。

13. お問い合わせ

android-compatibility フォーラムに参加すると、解説を求めることができます。または、このドキュメントがカバーしていないと思われる問題を提起することもできます。