Android 8.1 互換性定義

1. はじめに

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

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

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

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

この定義、またはセクション 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 の実装
• 条件 ID
  • 要件が無条件の場合、この ID は 0 と設定されます。
  • 要件が条件付きの場合、最初の条件に対して 1 が割り当てられ、同一セクション、同一デバイスタイプで数字が 1 ずつ増えます。
• 要件 ID
  • この ID は 1 から始まり、同一セクション、同一条件で 1 ずつ増えます。

2. デバイスタイプ

Android オープンソース プロジェクトはさまざまなデバイスタイプやフォーム ファクタに使用できるソフトウェア スタックを提供していますが、アプリの配信エコシステムが比較的確立されたデバイスタイプもいくつかあります。

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

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

2.1 デバイス構成

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

2.2. ハンドヘルドの要件

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

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

• バッテリーなど、持ち運びを可能にする電源がある。
• 物理的な対角画面サイズが 2.5～8 インチの範囲内。

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

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

2.2.1. ハードウェア

画面サイズ（セクション 7.1.1.1）

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

• [H-0-1] 画面の物理的な対角サイズが 2.5 インチ以上でなければなりません。^*

画面密度（セクション 7.1.1.3）

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

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

レガシーアプリの互換モード（セクション 7.1.5）

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

• [H-0-1] アップストリームの Android オープンソース コードで実装されたレガシーアプリ互換モードのサポートを含まなければなりません。つまり、デバイス実装は、互換モードが有効になるトリガーまたはしきい値を変更してはなりません。また、互換モード自体の動作を変更してはなりません。

キーボード（セクション 7.2.1）

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

• [H-0-1] サードパーティのインプット メソッド エディタ（IME）アプリのサポートを含まなければなりません。

ナビゲーション キー（セクション 7.2.3）

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

• [H-0-1] ホーム機能、履歴機能、戻る機能を提供しなければなりません。

• [H-0-2] 戻る機能（KEYCODE_BACK）の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。

タッチスクリーン入力（セクション 7.2.4）

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

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

加速度計（セクション 7.3.1）

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

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

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

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

ジャイロスコープ（セクション 7.3.4）

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

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

近接センサー（セクション 7.3.8）

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

• 近接センサーを含むべきです。

姿勢センサー（セクション 7.3.12）

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

• 6 自由度の姿勢センサーをサポートすることが推奨されます。

Bluetooth（セクション 7.4.3）

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

• Bluetooth と Bluetooth LE のサポートを含むべきです。

データセーバー（セクション 7.4.7）

従量制接続が含まれる場合、ハンドヘルド デバイス実装は:

• [H-1-1] データセーバー モードを提供しなければなりません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アプリ共有ストレージ（セクション 7.6.2）

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

• [H-0-1] アプリ共有ストレージが 1 GiB 未満であってはなりません。

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

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

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

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

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

マイク（セクション 7.8.1）

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

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

オーディオ出力（セクション 7.8.2）

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

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

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

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

• [H-1-1] android.software.vr.mode 機能を宣言しなければなりません。^*

android.software.vr.mode 機能を宣言する場合、デバイス実装は:

• [H-2-1] android.app.Activity#setVrModeEnabled を介して VR アプリで有効にできる android.service.vr.VrListenerService を実装するアプリを含まなければなりません。^*

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

android.hardware.vr.high_performance 機能フラグを宣言するためのすべての要件を満たすことができる場合、ハンドヘルド デバイス実装は:

• [H-1-1] android.hardware.vr.high_performance 機能フラグを宣言しなければなりません。^*

2.2.2. マルチメディア

オーディオ エンコード（セクション 5.1.1）

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

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

オーディオ デコード（セクション 5.1.2）

ハンドヘルド デバイス実装は、次のオーディオ デコードをサポートしなければなりません。

• [H-0-1] AMR-NB
• [H-0-2] AMR-WB

動画のエンコード（セクション 5.2）

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

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

動画のデコード（セクション 5.3）

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

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

2.2.3. ソフトウェア

WebView の互換性（セクション 3.4.1）

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

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

ブラウザの互換性（セクション 3.4.2）

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

• [H-0-1] 一般ユーザーのウェブ ブラウジング用のスタンドアロン ブラウザアプリを含まなければなりません。

ランチャー（セクション 3.8.1）

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

• [H-SR] ショートカットとウィジェットのアプリ内固定をサポートするデフォルト ランチャーを実装することが強く推奨されます。

• [H-SR] ShortcutManager API を介してサードパーティ アプリで提供される追加のショートカットにすばやくアクセスできるようにするデフォルト ランチャーを実装することが強く推奨されます。

• [H-SR] アプリアイコンにバッジを表示するデフォルト ランチャー アプリを含むことが強く推奨されます。

ウィジェット（セクション 3.8.2）

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

• [H-SR] サードパーティ アプリ ウィジェットをサポートすることが強く推奨されます。

通知（セクション 3.8.3）

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

• [H-0-1] API クラス Notification と NotificationManager を介してサードパーティ アプリがユーザーに重要なイベントを通知することを許可しなければなりません。
• [H-0-2] リッチ通知をサポートしなければなりません。
• [H-0-3] ヘッドアップ通知をサポートしなければなりません。
• [H-0-4] AOSP で実装されるように、アクション ボタンやコントロール パネルなどのユーザー アフォーダンスを通じてユーザーが通知を直接コントロール（返信、スヌーズ、拒否、ブロックなど）できるようにする通知シェードを含まなければなりません。

検索（セクション 3.8.4）

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

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

ロック画面のメディア コントロール（セクション 3.8.10）

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

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

デバイス管理（セクション 3.9）

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

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

ユーザー補助（セクション 3.10）

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

• [H-SR] サードパーティのユーザー補助サービスをサポートしなければなりません。

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

Text-to-Speech（セクション 3.11）

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

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

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

クイック設定（セクション 3.13）

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

• [H-SR] クイック設定 UI コンポーネントを含むことが強く推奨されます。

コンパニオン デバイスのペア設定（セクション 3.15）

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

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

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

ユーザー エクスペリエンスの一貫性（セクション 8.1）

ハンドヘルド デバイス実装の場合:

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

ファイル I/O アクセスのパフォーマンス（セクション 8.2）

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

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

省電力モード（セクション 8.3）

ハンドヘルド デバイス実装の場合:

• [H-0-1] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリは、エンドユーザーに表示されなければなりません。
• [H-0-2] トリガー、メンテナンス、ウェイクアップのアルゴリズム、アプリ スタンバイと Doze 省電力モードのグローバル システム設定の使用について、Android オープンソース プロジェクトから逸脱してはなりません。

消費電力の算出（セクション 8.4）

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

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

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

• [H-1-1] android.intent.action.POWER_USAGE_SUMMARY インテントを使用して、この電力使用量を表示する設定メニューを表示しなければなりません。

2.2.5. セキュリティ モデル

権限（セクション 9.1）

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

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

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] ホーム機能と戻る機能を提供しなければなりません。
• [T-0-2] 戻る機能（KEYCODE_BACK）の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。

ボタン マッピング（セクション 7.2.6.1）

テレビデバイス実装は:

• [T-0-1] ゲーム コントローラのサポートを含まなければならず、android.hardware.gamepad 機能フラグを宣言しなければなりません。

リモコン（セクション 7.2.7）

テレビデバイス実装は:

• ユーザーがタップ以外のナビゲーションと主要なナビゲーション キー入力にアクセスできるリモコンを提供すべきです。

ジャイロスコープ（セクション 7.3.4）

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

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

Bluetooth（セクション 7.4.3）

テレビデバイス実装は:

• [T-0-1] Bluetooth と Bluetooth LE をサポートしなければなりません。

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

テレビデバイス実装は:

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

マイク（セクション 7.8.1）

テレビデバイス実装は:

• マイクを含むべきです。

オーディオ出力（セクション 7.8.2）

テレビデバイス実装は:

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

2.3.2. マルチメディア

オーディオ エンコード（セクション 5.1）

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

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

動画のエンコード（セクション 5.2）

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

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

H-264（セクション 5.2.2）

テレビデバイス実装は:

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

動画のデコード（セクション 5.3）

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

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

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

• [T-SR] MPEG-2

H.264（セクション 5.3.4）

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

• [T-1-1] ハイ プロファイル レベル 4.2 と HD 1,080p（60 fps）デコード プロファイルをサポートしなければなりません。
• [T-1-2] 下表に示すとおり、HD プロファイルを有し、ベースライン プロファイル、メイン プロファイル、またはハイ プロファイル レベル 4.2 のいずれかでエンコードされた動画をデコードできなければなりません。

H.265（HEVC）（セクション 5.3.5）

H.265 コーデックと HD 1,080p デコード プロファイルをサポートする場合、テレビデバイス実装は:

• [T-1-1] メイン プロファイル レベル 4.1 メインティアをサポートしなければなりません。
• [T-SR] HD 1,080p で 60 fps の動画フレームレートをサポートすることが強く推奨されます。

H.265 コーデックと UHD デコード プロファイルをサポートする場合、テレビデバイス実装は:

• [T-2-1] コーデックはメイン 10 レベル 5 メインティア プロファイルをサポートしなければなりません。

VP8（セクション 5.3.6）

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

• [T-1-1] HD 1,080p60 デコード プロファイルをサポートしなければなりません。

VP8 コーデックをサポートし、720p をサポートする場合、テレビデバイス実装は:

• [T-2-1] HD 720p60 デコード プロファイルをサポートしなければなりません。

VP9（セクション 5.3.7）

VP9 コーデックと UHD 動画デコードをサポートする場合、テレビデバイス実装は:

• [T-1-1] 8 ビット色深度をサポートしなければならず、VP9 プロファイル 2（10 ビット）をサポートすべきです。

VP9 コーデック、1,080p プロファイル、VP9 ハードウェア デコードをサポートする場合、テレビデバイス実装は:

• [T-2-1] 1,080p で 60 fps をサポートしなければなりません。

セキュア メディア（セクション 5.8）

Android テレビデバイスであり、4K 解像度をサポートする場合、デバイス実装は:

• [T-1-1] すべての有線外部ディスプレイについて、HDCP 2.2 をサポートしなければなりません。

4K 解像度をサポートしない場合、テレビデバイス実装は:

• [T-2-1] すべての有線外部ディスプレイについて、HDCP 1.4 をサポートしなければなりません。

テレビデバイス実装は:

• [T-SR] セキュア ストリームの同時デコードをサポートすることが強く推奨されます。少なくとも、2 つのスチームを同時にデコードすることが強く推奨されます。

出力音量（セクション 5.5.3）

テレビデバイス実装は:

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

2.3.3. ソフトウェア

テレビデバイス実装は:

• [T-0-1] 機能 android.software.leanback と android.hardware.type.television を宣言しなければなりません。

WebView の互換性（セクション 3.4.1）

テレビデバイス実装は:

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

ロック画面のメディア コントロール（セクション 3.8.10）

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

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

マルチウィンドウ（セクション 3.8.14）

テレビデバイス実装は:

• [T-SR] ピクチャー イン ピクチャー（PIP）モードのマルチウィンドウをサポートすることが強く推奨されます。

ユーザー補助（セクション 3.10）

テレビデバイス実装は:

• [T-SR] サードパーティのユーザー補助サービスをサポートしなければなりません。

• [T-SR] Android テレビデバイス実装は、talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack（プリロードされたテキスト読み上げエンジンでサポートされている言語）のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。

Text-to-Speech（セクション 3.11）

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

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

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

TV 入力フレームワーク（セクション 3.12）

テレビデバイス実装は:

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

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

ユーザー エクスペリエンスの一貫性（セクション 8.1）

テレビデバイス実装の場合:

• [T-0-1] 一貫したフレーム レイテンシ。一貫性のないフレーム レイテンシ、またはフレームのレンダリングの遅延は、1 秒間に 5 フレームを超えて発生してはならず、1 秒間に 1 フレーム未満であるべきです。

ファイル I/O アクセスのパフォーマンス（セクション 8.2）

テレビデバイス実装は:

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

省電力モード（セクション 8.3）

テレビデバイス実装の場合:

• [T-0-1] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリは、エンドユーザーに表示されなければなりません。
• [T-0-2] トリガー、メンテナンス、ウェイクアップのアルゴリズム、アプリ スタンバイと Doze 省電力モードのグローバル システム設定の使用について、Android オープンソース プロジェクトから逸脱してはなりません。

消費電力の算出（セクション 8.4）

テレビデバイス実装は:

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

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-2] タッチスクリーン入力をサポートしなければなりません。

加速度計（セクション 7.3.1）

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

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

Bluetooth（セクション 7.4.3）

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

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

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

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

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

マイク（セクション 7.8.1）

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

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

オーディオ出力（セクション 7.8.1）

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

• オーディオ出力があっても構いませんが、あるべきではありません。

2.4.2. マルチメディア

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

2.4.3. ソフトウェア

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

• [W-0-1] 機能 android.hardware.type.watch を宣言しなければなりません。
• [W-0-2] uiMode = UI_MODE_TYPE_WATCH をサポートしなければなりません。

検索（セクション 3.8.4）

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

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

ユーザー補助（セクション 3.10）

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

• [W-1-1] サードパーティのユーザー補助サービスをサポートしなければなりません。

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

Text-to-Speech（セクション 3.11）

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

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

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

2.5. 自動車の要件

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

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

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

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

2.5.1. ハードウェア

画面サイズ（セクション 7.1.1.1）

自動車デバイス実装は:

• [A-0-1] 画面の対角サイズが物理的に少なくとも 6 インチでなければなりません。
• [A-0-2] 画面サイズのレイアウトが少なくとも 750 dp x 480 dp でなければなりません。

ナビゲーション キー（セクション 7.2.3）

自動車デバイス実装は:

• [A-0-1] ホーム機能を提供しなければならず、戻る機能と履歴機能を提供しても構いません。
• [A-0-2] 戻る機能（KEYCODE_BACK）の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。

加速度計（セクション 7.3.1）

自動車デバイス実装は:

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

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

• [A-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
• [A-1-2] Android 自動車センサー座標系を遵守しなければなりません。

GPS（セクション 7.3.3）

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

• [A-1-1] GNSS テクノロジーの生成は、「2017」年以降でなければなりません。

ジャイロスコープ（セクション 7.3.4）

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

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

Android Automotive 専用センサー（セクション 7.3.11） 現在のギア（セクション 7.3.11.1）

自動車デバイス実装は:

• 現在のギアを SENSOR_TYPE_GEAR として提供すべきです。

日中夜間モード（セクション 7.3.11.2）

自動車デバイス実装は:

• [A-0-1] SENSOR_TYPE_NIGHT として定義された日中 / 夜間モードをサポートしなければなりません。
• [A-0-2] SENSOR_TYPE_NIGHT フラグの値は、ダッシュボードの昼間 / 夜間モードと一致しなければならず、周囲光センサー入力に基づくべきです。
• 基になる周囲光センサーは、光度計と同じでも構いません。

運転状況（セクション 7.3.11.3）

自動車デバイス実装は:

• [A-0-1] 車両が完全に停止して駐車したときのデフォルト値は DRIVE_STATUS_UNRESTRICTED であり、SENSOR_TYPE_DRIVING_STATUS として定義された運転状況をサポートしなければなりません。製品が出荷されている市場に適用されるすべての法律および規制を遵守して SENSOR_TYPE_DRIVING_STATUS を構成するのはデバイス メーカーの責任です。

車輪回転速度（セクション 7.3.11.4）

自動車デバイス実装は:

• [A-0-1] SENSOR_TYPE_CAR_SPEED として定義された車両速度を提供しなければなりません。

Bluetooth（セクション 7.4.3）

自動車デバイス実装は:

• [A-0-1] Bluetooth をサポートしなければならず、Bluetooth LE をサポートすべきです。

• [A-0-2] Android Automotive 実装は、次の Bluetooth プロファイルをサポートしなければなりません。

  • Hands-Free Profile（HFP）での通話。
  • Audio Distribution Profile（A2DP）でのメディア再生。
  • Remote Control Profile（AVRCP）でのメディア再生コントロール。
  • Phone Book Access Profile（PBAP）を使用した連絡先の共有。
• Message Access Profile（MAP）をサポートすべきです。

最低限のネットワーク機能（セクション 7.4.5）

自動車デバイス実装は:

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

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

自動車デバイス実装は:

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

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

自動車デバイス実装は:

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

マイク（セクション 7.8.1）

自動車デバイス実装は:

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

オーディオ出力（セクション 7.8.2）

自動車デバイス実装は:

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

2.5.2. マルチメディア

オーディオ エンコード（セクション 5.1）

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

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

動画のエンコード（セクション 5.2）

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

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

動画のデコード（セクション 5.3）

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

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

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

• [A-SR] H.265 HEVC

2.5.3. ソフトウェア

自動車デバイス実装は:

• [A-0-1] 機能 android.hardware.type.automotive を宣言しなければなりません。
• [A-0-2] uiMode = UI_MODE_TYPE_CAR をサポートしなければなりません。
• [A-0-3] Android Automotive 実装は、android.car.* 名前空間のすべての公開 API をサポートしなければなりません。

WebView の互換性（セクション 3.4.1）

自動車デバイス実装は:

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

通知（セクション 3.8.3）

Android Automotive デバイス実装は:

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

検索（セクション 3.8.4）

自動車デバイス実装は:

• [A-0-1] アシスト アクションを処理するために、デバイスにアシスタントを実装しなければなりません。

メディア UI（セクション 3.14）

自動車デバイス実装は:

• [A-0-1] セクション 3.14 に記載されているとおり、メディア API を使用するサードパーティ アプリをサポートするために UI フレームワークを含めなければなりません。

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

省電力モード（セクション 8.3）

自動車デバイス実装の場合:

• [A-0-1] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリは、エンドユーザーに表示されなければなりません。
• [A-0-2] トリガー、メンテナンス、ウェイクアップのアルゴリズム、アプリ スタンバイと Doze 省電力モードのグローバル システム設定の使用について、Android オープンソース プロジェクトから逸脱してはなりません。

消費電力の算出（セクション 8.4）

自動車デバイス実装は:

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

2.2.5. セキュリティ モデル

マルチユーザー サポート（セクション 9.5）

複数のユーザーが含まれる場合、自動車デバイス実装は:

• [A-1-1] ユーザーのログインを必要とせずに車両システムで提供されるすべての機能を許可するゲスト アカウントを含まなければなりません。

自動車の車両システムの分離（セクション 9.14）

自動車デバイス実装は:

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

2.6. タブレットの要件

Android タブレット デバイスとは、一般的に、クラムシェル フォーム ファクタではなく、両手で持って使用する Android デバイス実装を指します。

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

• バッテリーなど、持ち運びを可能にする電源がある。
• 物理的な対角画面サイズが 7～18 インチの範囲内。

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

2.4.1. ハードウェア

画面サイズ（セクション 7.1.1.1）

タブレット デバイス実装は:

• [Ta-0-1] 画面が 7 から 18 インチでなければなりません。

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

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

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

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

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

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

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

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

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 をご覧ください。

3.1.1. Android 拡張機能

Android は、同じ API レベルのバージョンを維持しながらマネージド API を拡張する機能をサポートしています。

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

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 システムのバージョン（人が読める形式）。このフィールドには、8.1 で定義された文字列値のいずれかを指定しなければなりません。
VERSION.SDK	現在実行している Android システムのバージョン（サードパーティ アプリコードからアクセスできる形式）。Android 8.1 の場合、このフィールドには整数値 8.1_INT を指定しなければなりません。
VERSION.SDK_INT	現在実行している Android システムのバージョン（サードパーティ アプリコードからアクセスできる形式）。Android 8.1 の場合、このフィールドには整数値 8.1_INT を指定しなければなりません。
VERSION.INCREMENTAL	現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値（人が読める形式）。この値は、エンドユーザーが利用できる別のビルドに再利用してはなりません。このフィールドは主に、ビルドの生成に使用されたビルド番号またはソース管理変更 ID を示すために使用します。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。
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:8.1/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 または空の文字列（""）であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。
MODEL	エンドユーザーが知っているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが市販されエンドユーザーに販売される際の名前と同じにすべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列（""）であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。
PRODUCT	特定の製品（SKU）の開発名またはコードネームを含む、デバイス実装者が選択した値。同じブランド内で一意でなければなりません。人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。この製品名は、製品の全期間にわたって変更してはなりません。
SERIAL	ハードウェアのシリアル番号。MODEL と MANUFACTURER が同じデバイス間で利用可能かつ一意でなければなりません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^([a-zA-Z0-9]{6,20})$」に一致しなければなりません。
TAGS	ビルドをさらに区別する、デバイス実装者が選択したタグのカンマ区切りのリスト。このフィールドには、典型的な 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._-,]+$」に一致しなければなりません。

3.2.3. インテントの互換性

3.2.3.1. コアアプリのインテント

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

• [C-0-1] デバイス実装は、AOSP の次のコア Android アプリで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。

  • 卓上時計
  • ブラウザ
  • カレンダー
  • 連絡先
  • ギャラリー
  • グローバル検索
  • ランチャー
  • 音楽
  • 設定

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 オープンソース プロジェクトのパッケージ マネージャーで実装される、Digital Asset Links 仕様で規定されている検証手順を実施することで、インテント フィルタの検証を試行しなければなりません。
• [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 と競合しません。

3.2.3.5. デフォルト アプリの設定

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

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

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

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

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

• [C-2-1] android.provider.Telephony.ACTION_CHANGE_DEFAULT インテントを呼び出す設定メニューを提供して、デフォルトの SMS アプリを変更するダイアログを表示しなければなりません。

• [C-2-2] android.telecom.action.CHANGE_DEFAULT_DIALER インテントを使用して、デフォルトの電話アプリをユーザーが変更できるダイアログを表示しなければなりません。

• [C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS インテントを使用して、PhoneAccounts に関連付けられた ConnectionServices と、通信サービス プロバイダが発信を行うために使用するデフォルトの PhoneAccount を構成するユーザー アフォーダンスを提供しなければなりません。AOSP 実装は、「通話」設定メニュー内に「通話アカウント オプション」メニューを含めることで、この要件を満たしています。

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

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

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

• [C-4-1] android.settings.ACTION_VOICE_INPUT_SETTINGS インテントを使用して、音声入力とアシスト用のデフォルトのアプリ設定メニューを表示しなければなりません。

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] ディスプレイ自体のサイズを変更する場合、それに応じて VirtualDisplay 上のすべてのアクティビティのサイズを変更しなければなりません。
• テキスト入力フィールドがセカンダリ ディスプレイにフォーカスされたとき、プライマリ ディスプレイに IME（インプット メソッド エディタ、ユーザーがテキストを入力できるようにするユーザー コントロール）を表示しても構いません。
• タップ入力またはキー入力がサポートされている場合、プライマリ ディスプレイとは別に入力フォーカスをセカンダリ ディスプレイに実装すべきです。
• セカンダリ ディスプレイでアクティビティが起動された場合に、表示、正しい動作、互換性が維持されるように、そのディスプレイに対応する android.content.res.Configuration があるべきです。

セカンダリ ディスプレイで通常の Android アクティビティが起動できるようになっており、プライマリ ディスプレイとセカンダリ ディスプレイで android.util.DisplayMetrics が異なる場合、デバイス実装は:

• [C-2-1] サイズ変更できないアクティビティ（AndroidManifest.xml に resizeableActivity=false があるもの）と、API レベル 23 以下を対象とするアプリをセカンダリ ディスプレイで許可してはなりません。

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

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

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

デバイス実装者は:

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

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

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

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

デバイス実装は:

• [C-0-1] 1 つ以上の定義済み ABI と互換性があり、Android NDK との互換性を実装しなければなりません。
• [C-0-2] 標準の Java Native Interface（JNI）セマンティクスを使用して、ネイティブ コードを呼び出すためにマネージド環境で動作するコードのサポートを含まなければなりません。
• [C-0-3] 下記のリストにある各必須ライブラリと、ソース互換（すなわちヘッダー互換）かつバイナリ互換（ABI 向け）でなければなりません。
• [C-0-4] 64 ビット ABI がサポートされている場合は、同等の 32 ビット 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] 上記のパラメータを介して、最新バージョンの Android NDK ABI 管理ドキュメントに文書化され、記述されている ABI のみをレポートしなければならず、高度な SIMD（NEON）拡張機能をサポートしていなければなりません。

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

  • libaaudio.so（AAudio ネイティブ オーディオ サポート）
  • 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 ライブラリ）
  • 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.0 関数シンボルと拡張機能 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 NDK の今後のリリースで、追加の ABI のサポートが導入される可能性があります。

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

64 ビット ARM デバイスの場合、デバイス実装は:

• [C-1-1] ARMv8 アーキテクチャでは、既存のネイティブ コードで使用されている一部のオペレーションを含む、いくつかの CPU オペレーションが非推奨になっていますが、以下の非推奨のオペレーションは、ネイティブ CPU サポートまたはソフトウェア エミュレーションを通じて、32 ビット ネイティブ ARM コードで引き続き使用できなければなりません。

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

32 ビット ARM ABI が含まれる場合、デバイス実装は:

• [C-2-1] 32 ビット ARM アプリで読み取られる場合、Android NDK の古いバージョンを使用してビルドされたアプリとの互換性を確保するために、/proc/cpuinfo に次の行を配置しなければなりません。

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

• 64 ビット ARM アプリまたは非 ARM アプリで読み取られた場合は、/proc/cpuinfo を変更すべきではありません。

3.4. ウェブの互換性

3.4.1. WebView の互換性

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

• [C-1-1] android.software.webview をレポートしなければなりません。
• [C-1-2] android.webkit.WebView API の実装に、Android 8.1 ブランチのアップストリームの 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) 文字列の値は、android.os.Build.ID の値と同じでなければなりません。
  • $(CHROMIUM_VER) 文字列の値は、アップストリームの Android オープンソース プロジェクトの Chromium バージョンでなければなりません。
  • デバイス実装は、ユーザー エージェント文字列で Mobile を省略しても構いません。

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

3.4.2. ブラウザの互換性

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

• [C-1-1] HTML5 に関連する以下の API をそれぞれサポートしなければなりません。
  • アプリ キャッシュ / オフライン オペレーション
  • <video> タグ
  • 位置情報
• [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 動作の互換性

各 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 以降を対象としている場合、アプリが保持しているウェイクロックをリリースしなければなりません。

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

3.6. API 名前空間

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

• java.*
• javax.*
• sun.*
• android.*
• 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 共有ライブラリにパッケージ化しなければなりません。

デバイス実装者が上記パッケージ名前空間のいずれかの改善（既存の 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）	32MB
	160 dpi（mdpi）
	213 dpi（tvdpi）
	240 dpi（hdpi）	36MB
	280 dpi（280dpi）
	320 dpi（xhdpi）	48 MB
	360 dpi（360dpi）
	400 dpi（400dpi）	56MB
	420 dpi（420dpi）	64 MB
	480 dpi（xxhdpi）	88MB
	560 dpi（560dpi）	112 MB
	640 dpi（xxxhdpi）	154 MB
小 / 標準	120 dpi（ldpi）	32MB
	160 dpi（mdpi）
	213 dpi（tvdpi）	48 MB
	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）	128MB
	560 dpi（560dpi）	192 MB
	640 dpi（xxxhdpi）	256 MB
大	120 dpi（ldpi）	32MB
	160 dpi（mdpi）	48 MB
	213 dpi（tvdpi）	80 MB
	240 dpi（hdpi）
	280 dpi（280dpi）	96 MB
	320 dpi（xhdpi）	128MB
	360 dpi（360dpi）	160 MB
	400 dpi（400dpi）	192 MB
	420 dpi（420dpi）	228 MB
	480 dpi（xxhdpi）	256 MB
	560 dpi（560dpi）	384MB
	640 dpi（xxxhdpi）	512MB
特大	120 dpi（ldpi）	48 MB
	160 dpi（mdpi）	80 MB
	213 dpi（tvdpi）	96 MB
	240 dpi（hdpi）
	280 dpi（280dpi）	144MB
	320 dpi（xhdpi）	192 MB
	360 dpi（360dpi）	240MB
	400 dpi（400dpi）	288 MB
	420 dpi（420dpi）	336 MB
	480 dpi（xxhdpi）	384MB
	560 dpi（560dpi）	576MB
	640 dpi（xxxhdpi）	768MB

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

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

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

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

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

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

• [C-2-1] ShortcutManager.isRequestPinShortcutSupported() の true をレポートしなければなりません。
• [C-2-2] ShortcutManager.requestPinShortcut() API メソッドを介してアプリがリクエストしたショートカットを追加する前にユーザーに確認するユーザー アフォーダンスがなければなりません。
• [C-2-3] アプリのショートカットのページに記載されているとおり、固定ショートカット、動的ショートカット、静的ショートカットをサポートしなければなりません。

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

• [C-3-1] ShortcutManager.isRequestPinShortcutSupported() の false をレポートしなければなりません。

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 を通じて提供されるリソースと値を使用すべきです。

3.8.2. ウィジェット

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

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

• [C-1-1] プラットフォーム機能 android.software.app_widgets のサポートを宣言しなければなりません。
• [C-1-2] AppWidgets の組み込みのサポートを含まなければならず、ランチャー内で直接 AppWidget を追加、設定、表示、削除するユーザー インターフェース アフォーダンスを公開しなければなりません。
• [C-1-3] 標準グリッドサイズで 4 x 4 のウィジェットをレンダリングできなければなりません。詳細については、Android SDK ドキュメントのアプリ ウィジェットのデザイン ガイドラインをご覧ください。
• ロック画面でのアプリ ウィジェットをサポートしても構いません。

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

• [C-2-1] AppWidgetManager.html.isRequestPinAppWidgetSupported() の true をレポートしなければなりません。
• [C-2-2] AppWidgetManager.requestPinAppWidget() API メソッドを介してアプリがリクエストしたショートカットを追加する前にユーザーに確認するユーザー アフォーダンスがなければなりません。

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-2-1] Notification.Style API クラスとそのサブクラスを通じて提供されたとおりのリソースを、提示されたリソース要素に使用しなければなりません。
• Notification.Style API クラスとそのサブクラスで定義された各リソース要素をすべて提示すべきです。

ヘッドアップ通知をサポートする場合、デバイス実装は:

• [C-3-1] ヘッドアップ通知を提示するとき、Notification.Builder API クラスに記載されているとおり、ヘッドアップ通知ビューとリソースを使用しなければなりません。

3.8.3.2. 通知リスナー サービス

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

機能フラグ android.hardware.ram.normal をレポートする場合、デバイス実装は:

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

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

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

3.8.3.3. DND（サイレント モード）

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

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

3.8.4. 検索

Android には、デベロッパーが自身のアプリに検索を組み込み、自身のアプリのデータをグローバル システム検索に公開できる API があります。一般に、この機能は単一でシステム全体にわたるユーザー インターフェースで構成されており、ユーザーがクエリを入力し、その入力に対して候補を示して結果を表示できるようになっています。Android API を使用すると、デベロッパーは、このインターフェースを再利用して独自のアプリ内で検索を提供でき、共通のグローバル検索ユーザー インターフェースに結果を供給できます。

• Android デバイス実装は、ユーザー入力に応じてリアルタイムの提案が可能な、システム全体にわたる単一共有検索ユーザー インターフェースであるグローバル検索を含むべきです。

グローバル検索インターフェースを実装する場合、デバイス実装は:

• [C-1-1] グローバル検索モードで実行されたときにサードパーティ アプリが検索ボックスに候補を追加できる API を実装しなければなりません。

グローバル検索を利用するサードパーティ アプリがインストールされていない場合:

• デフォルトの動作で、ウェブ検索エンジンの結果と候補を表示すべきです。

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

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

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

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 テーマ属性またはそのアセットのいずれについても変更してはなりません。

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

• デバイス実装は、アプリに公開されているデバイスのデフォルトのテーマ属性を変更しても構いません。

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

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

• [C-2-1] アイコンが問題のあるステータスを示すか、アプリが SYSTEM_UI_FLAG_LIGHT_STATUS_BAR フラグを使用してライト ステータスバーをリクエストする場合を除き、システム ステータス アイコン（信号強度やバッテリー残量など）と、システムが発行する通知には、白色を使用しなければなりません。
• [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 つのアプリを素早く切り替えるアクションをトリガーすべきです。
• 履歴機能のキーが長押しされたとき、分割画面のマルチウィンドウ モードをトリガーすべきです（サポートしている場合）。

• 一緒に移動するグループとして関連する履歴を表示しても構いません。

• [SR] 概要画面には、アップストリームの Android ユーザー インターフェース（またはサムネイルベースの同様のインターフェース）を使用することが強く推奨されます。

3.8.9. 入力管理

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

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

• [C-1-1] Android SDK ドキュメントで定義されているとおり、プラットフォーム機能 android.software.input_methods を宣言し、IME API をサポートしなければなりません。
• [C-1-2] android.settings.INPUT_METHOD_SETTINGS インテントに応じてサードパーティの入力方法を追加、構成する、ユーザーがアクセス可能なメカニズムを提供しなければなりません。

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

• [C-2-1] AutofillService API と AutofillManager API を完全に実装し、android.settings.REQUEST_SET_AUTOFILL_SERVICE インテントを使用して、自動入力の有効化 / 無効化とデフォルトの自動入力サービスの変更を行う、デフォルトのアプリ設定メニューをユーザーに表示しなければなりません。

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

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

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

Android は、以前は Dreams と呼ばれていた、インタラクティブ スクリーンセーバーをサポートしています。スクリーン セーバーを使用すると、電源に接続されているデバイスがアイドル状態のとき、または卓上ホルダーにドッキングされているとき、ユーザーがアプリを操作できます。Android スマートウォッチ デバイスはスクリーン セーバーを実装しても構いませんが、他のタイプのデバイス実装は、スクリーン セーバーのサポートを含み、android.settings.DREAM_SETTINGS インテントに応じてユーザーがスクリーン セーバーを構成する設定オプションを提供すべきです。

3.8.12. 位置情報

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

• [C-1-1] 位置情報モードは、[設定] の [位置情報] メニューに表示されなければなりません。

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 の通貨記号ブロックのグリフすべて。
• Unicode Technical Report #51 で規定されているとおり、肌の色と多様な家族の絵文字をサポートすべきです。

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

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

3.8.14. マルチウィンドウ

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

• [C-1-1] Android SDK のマルチウィンドウ モードのサポートに関するドキュメントに記載されているアプリの動作と API に従ってマルチウィンドウ モードを実装し、以下の要件を満たさなければなりません。
• [C-1-2] アプリは、AndroidManifest.xml ファイルでマルチウィンドウ モードで動作可能かどうかを、android:resizeableActivity 属性を true に設定して明示的に、または、targetSdkVersion を 24 より大きくして暗黙的に指定できます。マニフェストでこの属性を false に明示的に設定するアプリは、マルチウィンドウ モードで起動してはなりません。targetSdkVersion が 24 未満で、この android:resizeableActivity 属性を設定していない古いアプリは、マルチウィンドウ モードで起動しても構いませんが、システムはアプリがマルチウィンドウ モードで想定どおりに機能しない可能性があることを警告しなければなりません。
• [C-1-3] 画面の高さが 440 dp 未満、画面の幅が 440 dp 未満の場合、分割画面モードまたはフリーフォーム モードを提供してはなりません。
• 画面サイズが xlarge のデバイス実装は、フリーフォーム モードをサポートすべきです。

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

• [C-2-1] デフォルトとして、サイズ変更可能なランチャーをプリロードしなければなりません。
• [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] PIP ウィンドウの最小の幅と高さは 108 dp、Configuration.uiMode が UI_MODE_TYPE_TELEVISION として構成されている場合は、PIP ウィンドウの最小の幅 240 dp、最小の高さ 135 dp を割り当てなければなりません。

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 に記載されているとおり、デバイス所有者のプロビジョニングをサポートしなければなりません。
• [C-1-3] android.software.managed_users 機能フラグを介して管理対象プロファイルのサポートを宣言しなければなりません。ただし、低 RAM デバイスとして自身をレポートするように、または内部（非リムーバブル）ストレージを共有ストレージとして割り当てるようにデバイスが構成されている場合を除きます。

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

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

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

• [C-1-1] 下記のとおり、デバイス所有者アプリとしてのデバイス ポリシー クライアント（DPC）の登録をサポートしなければなりません。
  • ユーザーデータがまだ構成されていない場合、デバイス実装は:
    • [C-1-3] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) の true をレポートしなければなりません。
    • [C-1-4] インテント アクション android.app.action.PROVISION_MANAGED_DEVICE に応じて、DPC アプリをデバイス所有者アプリとして登録しなければなりません。
    • [C-1-5] デバイスが機能フラグ android.hardware.nfc を介して近距離無線通信（NFC）のサポートを宣言し、MIME タイプ MIME_TYPE_PROVISIONING_NFC のレコードを含む NFC メッセージを受信した場合、DPC アプリをデバイス所有者アプリとして登録しなければなりません。
  • ユーザーデータがある場合、デバイス実装は:
    • [C-1-6] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) の false をレポートしなければなりません。
    • [C-1-7] これ以上、DPC アプリをデバイス所有者アプリとして登録してはなりません。
• [C-1-2] ユーザーまたはデバイスの管理者による明示的な同意または操作なしに、アプリ（プリインストール アプリを含む）をデバイス所有者アプリとして設定してはなりません。

android.software.device_admin を宣言するだけでなく、独自のデバイス所有者管理ソリューションも含み、そのソリューションで構成したアプリを、「デバイス所有者相当」として、標準の Android DevicePolicyManager API で認識される標準の「デバイス所有者」に昇格させるメカニズムを提供する場合、デバイス実装は:

• [C-2-1] 昇格させる特定のアプリが正当な企業デバイス管理ソリューションに属し、独自のソリューションにより「デバイス所有者」と同等の権限を持つようにすでに設定されていることを検証するためのプロセスが定められていなければなりません。
• [C-2-2] DPC アプリを「デバイス所有者」として登録する前に、android.app.action.PROVISION_MANAGED_DEVICE で開始されるフローと同じ AOSP デバイス所有者同意開示を示さなければなりません。
• DPC アプリを「デバイス所有者」として登録する前に、デバイス上にユーザーデータがあっても構いません。

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 で開始されるフロー）のユーザー エクスペリエンスは、AOSP 実装に合わせなければなりません。

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

  • 特定の設定がデバイス管理者によって制限されている場合に表示される、一貫したアイコンまたはその他のユーザー アフォーダンス（たとえば、アップストリームの AOSP 情報のアイコン）。
  • setShortSupportMessage を介してデバイス管理者によって提供される、短い説明メッセージ。
  • 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] 次の要件を満たす個別のロック画面を指定する機能をサポートして、管理対象プロファイルで実行されているアプリへのアクセス権を付与しなければなりません。
  • デバイス実装は、DevicePolicyManager.ACTION_SET_NEW_PASSWORD インテントを使用し、管理対象プロファイルの個別のロック画面認証情報を設定するインターフェースを表示しなければなりません。
  • Android オープンソース プロジェクトのサイトに記載されているとおり、管理対象プロファイルのロック画面認証情報は、親プロファイルと同じ認証情報ストレージと管理メカニズムを使用しなければなりません。
  • DPC パスワード ポリシーは、getParentProfileInstance によって返される DevicePolicyManager インスタンスで呼び出されない限り、管理対象プロファイルのロック画面認証情報にのみ適用しなければなりません。
• 管理対象プロファイルの連絡先が、プリインストールの通話履歴、通話 UI、通話中通知、不在着信通知、連絡先、メッセージ アプリに表示される場合、管理対象プロファイル アプリを示すために使用されるものと同じバッジを付けるべきです。

3.10. ユーザー補助

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

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

• [C-1-1] ユーザー補助 API の SDK ドキュメントに記載されているとおり、Android ユーザー補助フレームワークの実装を提供しなければなりません。
• [C-1-2] SDK に記載されているとおり、ユーザー補助イベントを生成し、登録されているすべての AccessibilityService 実装に、適切な AccessibilityEvent を配信しなければなりません。
• [C-1-3] android.settings.ACCESSIBILITY_SETTINGS インテントを使用して、プリロードされたユーザー補助サービスとともにサードパーティのユーザー補助サービスの有効化と無効化を行う、ユーザーがアクセス可能なメカニズムを提供しなければなりません。
• [C-1-4] 有効になっているユーザー補助サービスが AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON を宣言した場合、ユーザーがユーザー補助サービスをコントロールできるボタンを、システムのナビゲーション バーに追加しなければなりません。なお、この要件はシステム ナビゲーション バーのないデバイス実装には適用されませんが、デバイス実装ではこれらのユーザー補助サービスをコントロールするユーザー アフォーダンスを提供すべきです。

プリロードされたユーザー補助サービスが含まれる場合、デバイス実装は:

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

3.11. テキスト読み上げ

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

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

• [C-1-1] Android TTS フレームワーク API をサポートしなければなりません。

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

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

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

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

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

• [C-1-1] プラットフォーム機能 android.software.live_tv を宣言しなければなりません。
• [C-1-2] TV アプリケーション（TV アプリ）をプリロードし、セクション 3.12.1 に記載されているすべての要件を満たさなければなりません。

3.12.1. TV アプリ

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

• [C-1-1] TV アプリは、テレビ チャンネルをインストールして使用するための機能を備え、次の要件を満たさなければなりません。

android.software.live_tv 機能フラグを宣言する Android デバイス実装に必要な TV アプリは、次の要件を満たさなければなりません。

• デバイス実装は、サードパーティの TIF ベースの入力（サードパーティ入力）のインストールと管理を許可すべきです。
• デバイス実装で、プリインストールされた TIF ベースの入力（インストール済みの入力）とサードパーティの入力間の視覚的な分離を実施しても構いません。
• デバイス実装は、TV アプリからの移動に複数のナビゲーション操作を要するサードパーティ入力を表示する（つまり、TV アプリのサードパーティ入力のリストを拡張する）べきではありません。

Android オープンソース プロジェクトは、上記の要件を満たす TV アプリの実装を実現しています。

3.12.1.1. 電子番組ガイド

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

• [C-1-1] 情報提供を行う、かつインタラクティブなオーバーレイを表示しなければなりません。これには、TvContract.Programs フィールドの値から生成される電子番組ガイド（EPG）を含まなければなりません。
• [C-1-2] チャンネル変更時に、デバイス実装により、現在再生中のプログラムの EPG データを表示しなければなりません。
• [SR] EPG では、インストール済みの入力とサードパーティ入力を同等に目立つように表示することが強く推奨されます。EPG は、EPG にインストールされている入力から移動する際に複数のナビゲーション操作を要するサードパーティ入力を表示すべきではありません。
• EPG には、インストール済みのすべての入力とサードパーティ入力による情報を表示すべきです。
• EPG では、インストール済みの入力とサードパーティ入力間の視覚的な分離を実施しても構いません。

3.12.1.2. ナビゲーション

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

• [C-1-1] Android テレビデバイスの入力デバイス（リモコン、リモート コントロール アプリ、ゲーム コントローラ）の D-pad、「戻る」キー、「ホーム」キーを介して、次の機能のためのナビゲーションを許可しなければなりません。

  • テレビ チャンネルの変更
  • EPG を開く
  • サードパーティの TIF をベースとする入力の構成と構成に合わせた調整（これらの入力がサポートされている場合）
  • 設定メニューを開く

• CEC を通じて鍵イベントを HDMI 入力に渡すべきです。

3.12.1.3. TV 入力アプリのリンク

Android テレビデバイス実装は、テレビ入力アプリリンクをサポートすべきです。これにより、すべての入力が現在のアクティビティから別のアクティビティへのアクティビティ リンク（つまり、ライブ プログラミングから関連コンテンツへのリンク）を表示できます。TV アプリは、提供されている場合、テレビ入力アプリリンクを表示すべきです。

3.12.1.4. タイムシフト

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

• [SR] ユーザーがライブ コンテンツを一時停止して再開できるように、タイムシフトをサポートすることが強く推奨されます。
• 現在再生中の番組でタイムシフトが利用可能な場合は、番組を一時停止して再開する方法をユーザーに提供すべきです。

3.12.1.5. テレビの録画

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

• [SR] テレビの録画をサポートすることが強く推奨されます。
• テレビ入力が録画をサポートしており、番組の録画が禁止されていない場合、EPG は番組を録画する方法を提供しても構いません。

3.13. クイック設定

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

クイック設定 UI コンポーネントが含まれる場合、デバイス実装は:

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

3.14. メディア UI

MediaBrowser と MediaSession に依存するサードパーティ アプリをサポートする UI フレームワークが含まれる場合、デバイス実装は:

• [C-1-1] MediaItem アイコンと通知アイコンを変更せずに表示しなければなりません。
• [C-1-2] MediaSession が記述するアイテム（メタデータ、アイコン、画像など）を表示しなければなりません。
• [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

デバイス実装は次の要件を満たさなければなりません。

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

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

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

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

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

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

デバイス実装は:

• [C-0-1] 公式の Android SDK に含まれる「aapt」ツールによって生成された Android「.apk」ファイルをインストールして実行できなければなりません。
• 上記の要件が難しい場合もあるため、デバイス実装は、AOSP リファレンス実装のパッケージ管理システムのデバイス実装を使用することが推奨されます。
• [C-0-2] APK 署名スキーム v2 と JAR 署名を使用した「.apk」ファイルの検証をサポートしなければなりません。
• [C-0-3] .apk、Android マニフェスト、Dalvik バイトコード、RenderScript バイトコードのいずれの形式を、他の互換デバイスでファイルのインストールと実行が正しく行われないような方法で拡張してはなりません。
• [C-0-4] DELETE_PACKAGE 権限の SDK に記載されているとおり、パッケージの現在の「レコードのインストーラ」以外のアプリが、プロンプトを表示することなくアプリをアンインストールできるようにしてはなりません。例外は、PACKAGE_NEEDS_VERIFICATION インテントを処理するシステム パッケージ検証アプリと、ACTION_MANAGE_STORAGE インテントを処理するストレージ管理アプリです。

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

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

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

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

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-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] 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 キーで定義されているとおりでなければなりません。API 21 で導入された 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 です。

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、シーク不可）
MPEG-4 HE AAC プロファイル（AAC+）	標準サンプリング レート 16～48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。
MPEG-4 HE AACv2 プロファイル（Enhanced AAC+）	標準サンプリング レート 16～48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。
AAC ELD（Enhanced Low Delay AAC）	標準サンプリング レート 16～48 kHz のモノラル / ステレオ コンテンツをサポート。
AMR-NB	8 kHz でサンプリングされた 4.75～12.2 kbps	3GPP（.3gp）
AMR-WB	16 kHz でサンプリングされた、6.60～23.85 kbps の 9 種類のレート。
FLAC	モノラル / ステレオ（マルチチャンネルはサポート対象外）。サンプルレートは最大 48 kHz（ただし、出力が 44.1 kHz のデバイスでは、48 kHz から 44.1 kHz のダウンサンプラーにローパス フィルタが含まれないため、最大 44.1 kHz を推奨）。16 ビットを推奨（24 ビットにはディザが適用されない）。	FLAC（.flac）のみ
MP3	モノラル / ステレオの 8～320 Kbps 固定ビットレート（CBR）または可変ビットレート（VBR）	MP3（.mp3）
MIDI	MIDI タイプ 0 と 1。DLS バージョン 1 と 2。XMF と Mobile XMF。着信音形式 RTTTL/RTX、OTA、iMelody をサポート。	タイプ 0 と 1（.mid、.xmf、.mxmf） RTTTL/RTX（.rtttl、.rtx） OTA（.ota） iMelody（.imy）
Vorbis		Ogg（.ogg） Matroska（.mkv、Android 4.0 以降）
PCM（WAVE）	16 ビットのリニア PCM（最大レートはハードウェアの上限値）。デバイスは、Raw PCM 録音のサンプリング レートとして 8,000、11,025、16,000、44,100 Hz の周波数をサポートしなければなりません。	WAVE（.wav）
Opus		Matroska（.mkv）、Ogg（.ogg）

5.1.4. 画像のエンコード

詳細については、5.1.6. 画像コーデックの詳細をご覧ください。

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

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

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

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）

5.1.7. 動画コーデック

• ウェブ動画ストリーミング サービスとビデオ会議サービスの品質を許容可能なものにするために、デバイス実装は、要件を満たすハードウェア VP8 コーデックを使用すべきです。

デバイス実装に動画デコーダまたはエンコーダが含まれる場合:

• [C-1-1] 動画コーデックは、標準と設定で規定されているとおり、実現可能な最大の圧縮フレームと非圧縮フレームに対応する入出力バイトバッファ サイズをサポートしなければなりませんが、過剰に割り当ててはなりません。

• [C-1-2] 動画エンコーダとデコーダは、YUV420 フレキシブル カラー形式（COLOR_FormatYUV420Flexible）をサポートしなければなりません。

Display.HdrCapabilities を通じて HDR プロファイルのサポートをアドバタイズする場合、デバイス実装は:

• [C-2-1] HDR 静的メタデータの解析と処理をサポートしなければなりません。

MediaCodecInfo.CodecCapabilities クラスの FEATURE_IntraRefresh を通じてイントラ更新のサポートをアドバタイズする場合、デバイス実装は:

• [C-3-1] 更新周期 10～60 フレームをサポートし、構成した更新周期の 20% 以内で正確に動作しなければなりません。

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

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

5.2. 動画のエンコード

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

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

対角長が 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 動画エンコーダをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

• サポート対象のエンコーダの動的に設定可能なビットレートをサポートすべきです。

5.2.1. H.263

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

• [C-1-1] ベースライン プロファイル レベル 45 をサポートしなければなりません。
• サポート対象のエンコーダの動的に設定可能なビットレートをサポートすべきです。

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（高画質）動画エンコード プロファイルをサポートすべきです。
• Matroska WebM ファイルの書き込みをサポートすべきです。
• ウェブ動画配信サービスとビデオ会議サービスの質を許容可能なものにするために、WebM プロジェクトの RTC ハードウェア コーディング要件を満たすハードウェア VP8 コーデックを使用すべきです。

メディア API を通じて解像度が 720p または 1080p である動画の VP8 エンコードのサポートをレポートする場合、デバイス実装は:

• [C-2-1] 下表のエンコード プロファイルをサポートしなければなりません。

	SD（低画質）	SD（高画質）	HD 720p	HD 1080p
動画の解像度	320 x 180 px	640 x 360 px	1,280 x 720 px	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 コーデックをサポートする場合、デバイス実装は:

• Matroska WebM ファイルの書き込みをサポートすべきです。

5.3. 動画のデコード

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

• [C-1-1] VP8、VP9、H.264、H.265 のすべてのコーデックについて、デバイスで各コーデックがサポートする最大解像度まで、同じストリーム内で標準の Android API を通じて、動的な動画解像度とフレームレートの切り替えをサポートしなければなりません。

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

• [C-2-1] ドルビー ビジョン対応エクストラクタを提供しなければなりません。
• [C-2-2] ドルビー ビジョン コンテンツをデバイスの画面または標準の動画出力ポート（例: HDMI）に適切に表示しなければなりません。
• [C-2-3] 下位互換性のあるベースレイヤ（存在する場合）のトラック インデックスを、結合したドルビー ビジョンレイヤのトラック インデックスと同じに設定しなければなりません。

5.3.1. MPEG-2

MPEG-2 デコーダをサポートする場合、デバイス実装は:

• [C-1-1] メイン プロファイル ハイレベルをサポートしなければなりません。

5.3.2. H.263

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

• [C-1-1] ベースライン プロファイル レベル 30 とレベル 45 をサポートしなければなりません。

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 fps^H.265 ハードウェア デコードを備えたテレビ）	60 fps
動画のビットレート	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

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 px	640 x 360 px	1,280 x 720 px	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-2] 下表に示すとおり、HD デコード プロファイルをサポートしなければなりません。

Display.getSupportedModes() メソッドによってレポートされる高さが動画の解像度以上である場合:

• [C-3-1] デバイス実装は、720、1080、UHD プロファイルの VP9 または H.265 デコードのうち少なくとも 1 つをサポートしなければなりません。

	SD（低画質）	SD（高画質）	HD 720p	HD 1080p	UHD
動画の解像度	320 x 180 px	640 x 360 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（60 fps^VP9 ハードウェア デコードを備えたテレビ）	60 fps
動画のビットレート	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.4. 録音

このセクションで概説している一部の要件は、Android 4.3 以降「すべき」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。既存と新規の Android デバイスは、「すべき」として記載されている要件を満たすことが強く推奨されます。満たさなかった場合、今後のバージョンにアップグレードした際に、Android の互換性が得られなくなります。

5.4.1. 未加工オーディオのキャプチャ

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

• [C-1-1] 次の特性を持つ未加工オーディオ コンテンツをキャプチャできるようにしなければなりません。

• 形式: リニア PCM、16 ビット

• サンプリング レート: 8,000、11,025、16,000、44,100 Hz

• チャンネル: モノラル

• [C-1-2] アップサンプリングせずに上記のサンプルレートでキャプチャしなければなりません。

• [C-1-3] 上記のサンプルレートがダウンサンプリングでキャプチャされる場合、適切なアンチエイリアス フィルタを含まなければなりません。

• 未加工オーディオ コンテンツを、AM ラジオと DVD の品質（つまり下記の特性）でキャプチャできるようにすべきです。

• 形式: リニア PCM、16 ビット

• サンプリング レート: 22,050、48,000 Hz
• チャンネル: ステレオ

未加工オーディオ コンテンツを 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] 44100 と 48000 いずれかのサンプリング レートで 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）になるように、音声認識のオーディオ ストリームを録音すべきです。
• 1,000 Hz で音圧レベル（SPL）90 dB の音源が 16 ビットサンプルで RMS 2,500 になるように入力感度を設定して、音声認識のオーディオ ストリームを録音すべきです。
• マイクでの 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.5. オーディオの再生

Android には、セクション 7.8.2 で規定されているとおり、アプリがオーディオ出力周辺機器を通じてオーディオを再生できるようにするサポートが含まれています。

5.5.1. 未加工オーディオの再生

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

• [C-1-1] 次の特性を持つ未加工オーディオ コンテンツを再生できるようにしなければなりません。

  • 形式: リニア PCM、16 ビット
  • サンプリング レート: 8,000、11,025、16,000、22,050、32,000、44,100
  • チャンネル: モノラル、ステレオ

• 次の特性を持つ未加工オーディオ コンテンツを再生できるようにすべきです。

  • サンプリング レート: 24,000、48,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 実装をサポートしなければなりません。
• AudioEffect のサブクラス BassBoost、EnvironmentalReverb、PresetReverb、Virtualizer を通じて制御できる EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB、EFFECT_TYPE_VIRTUALIZER 実装をサポートすべきです。

5.5.3. 出力音量

自動車デバイス実装は:

• AudioAttributes で定義されているコンテンツ タイプまたは用途と、android.car.CarAudioManager で公開で定義されているカーオーディオ用途を使用して、音量をオーディオ ストリームごとに調整できるようにすべきです。

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

オーディオ レイテンシとは、オーディオ信号がシステムを通過する際に発生する遅延時間のことです。アプリのクラスの多くで、リアルタイムのサウンド エフェクトを実現するには、レイテンシが短くなっている必要があります。

このセクションでは、次の定義を使用します。

• 出力レイテンシ。アプリが PCM 符号化データを書き込んでから、対応するサウンドがデバイス上のトランスデューサで環境に提供されるか、信号がポートを介してデバイスから出て外部で確認されるまでの間隔。
• コールド出力レイテンシ。リクエストの前にオーディオ出力システムがアイドル状態になり、電源がオフになった場合の、最初のフレームの出力レイテンシ。
• 連続出力レイテンシ。デバイスがオーディオを再生した後の、後続フレームの出力レイテンシ。
• 入力レイテンシ。サウンドが環境によってデバイス上のトランスデューサでデバイスに提供されるか、信号がポートを介してデバイスに入ってから、PCM 符号化データの対応するフレームをアプリが読み取るまでの間隔。
• 欠損入力。使用または利用できない、入力信号の最初の部分。
• コールド入力レイテンシ。リクエストの前にオーディオ入力システムがアイドル状態になり、電源がオフになった場合の、欠損入力時間の合計と最初のフレームの入力レイテンシ。
• 連続入力レイテンシ。デバイスがオーディオをキャプチャしている間の、後続フレームの入力レイテンシ。
• コールド出力ジッター。コールド出力レイテンシ値の、個々の測定値間のばらつき。
• コールド入力ジッター。コールド入力レイテンシ値の、個々の測定値間のばらつき。
• 連続ラウンドトリップ レイテンシ。連続入力レイテンシ、連続出力レイテンシ、1 バッファ期間の合計。バッファ期間により、アプリが信号を処理するための時間と、アプリが入出力ストリーム間の位相差を緩和するための時間を確保できます。
• OpenSL ES PCM バッファキュー API。Android NDK 内にある、PCM 関連の OpenSL ES API のセット。
• AAudio ネイティブ オーディオ API。Android NDK 内にある、AAudio API のセット。

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

• [SR] コールド出力レイテンシが 100 ミリ秒以下
• [SR] 連続出力レイテンシが 45 ミリ秒以下
• [SR] コールド出力ジッターを最小限に抑える

OpenSL ES PCM バッファキュー API を使用する際の初期キャリブレーションの後で上記の要件を満たした場合に、少なくとも 1 つのサポート対象オーディオ出力デバイスでの連続出力レイテンシとコールド出力レイテンシについて、デバイス実装は:

• [SR] android.hardware.audio.low_latency 機能フラグを宣言することで低レイテンシ オーディオをレポートすることが強く推奨されます。
• [SR] AAudio API を介して低レイテンシのオーディオの要件を満たすことも強く推奨されます。

OpenSL ES PCM バッファキュー API を介して低レイテンシ オーディオの要件を満たさない場合、デバイス実装は:

• [C-1-1] 低レイテンシ オーディオのサポートをレポートしてはなりません。

android.hardware.microphone が含まれる場合、デバイス実装は下記の入力オーディオの要件を満たすことが強く推奨されます。

• [SR] コールド入力レイテンシが 100 ミリ秒以下
• [SR] 連続入力レイテンシが 30 ミリ秒以下
• [SR] 連続ラウンドトリップ レイテンシが 50 ミリ秒以下
• [SR] コールド入力ジッターを最小限に抑える

5.7. ネットワーク プロトコル

デバイス実装は、Android SDK ドキュメントで規定されているとおり、オーディオと動画を再生するためにメディア ネットワーク プロトコルをサポートしなければなりません。

オーディオ デコーダまたは動画デコーダが含まれる場合、デバイス実装は:

• [C-1-1] HTTP(S) で、セクション 5.1 の必要なコーデックとコンテナの形式をすべてサポートしなければなりません。

• [C-1-2] HTTP Live Streaming ドラフト プロトコル バージョン 7 で、下表「メディア セグメント形式」に示すメディア セグメント形式をサポートしなければなりません。

• [C-1-3] 下表「RTSP」に示す RTP オーディオ動画プロファイルと関連コーデックをサポートしなければなりません。例外については、セクション 5.1 の表の脚注をご覧ください。

メディア セグメント形式

セグメント形式	参照	必要なコーデックのサポート
MPEG-2 トランスポート ストリーム	ISO 13818	動画コーデック: H264 AVC MPEG-4 SP MPEG-2 H264 AVC、MPEG2-4 SP、 MPEG-2 の詳細についてはセクション 5.1.3 をご覧ください。 オーディオ コーデック: AAC AAC とそのバリアントの詳細についてはセクション 5.1.1 をご覧ください。
ADTS フレーム処理と ID3 タグを伴う AAC	ISO 13818-7	AAC とそのバリアントの詳細についてはセクション 5.1.1 をご覧ください
WebVTT	WebVTT

RTSP（RTP、SDP）

プロファイル名	参照	必要なコーデックのサポート
H264 AVC	RFC 6184	H264 AVC の詳細についてはセクション 5.1.3 をご覧ください
MP4A-LATM	RFC 6416	AAC とそのバリアントの詳細についてはセクション 5.1.1 をご覧ください
H263-1998	RFC 3551 RFC 4629 RFC 2190	H263 の詳細についてはセクション 5.1.3 をご覧ください
H263-2000	RFC 4629	H263 の詳細についてはセクション 5.1.3 をご覧ください
AMR	RFC 4867	AMR-NB の詳細についてはセクション 5.1.1 をご覧ください
AMR-WB	RFC 4867	AMR-WB の詳細についてはセクション 5.1.1 をご覧ください
MP4V-ES	RFC 6416	MPEG-4 SP の詳細についてはセクション 5.1.3 をご覧ください
mpeg4-generic	RFC 3640	AAC とそのバリアントの詳細についてはセクション 5.1.1 をご覧ください
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 をサポートしなければなりません。ここでいうトランスポートは次のとおりです。

  • USB ホストモード（セクション 7.7）
  • USB ペリフェラル モード（セクション 7.7）
  • 中心的な役割を担う Bluetooth LE での MIDI（セクション 7.4.3）

• [C-1-2] アプリ間 MIDI ソフトウェア トランスポート（仮想 MIDI デバイス）をサポートしなければなりません。

5.10. プロフェッショナル オーディオ

android.content.pm.PackageManager クラスを介して機能 android.hardware.audio.pro のサポートをレポートする場合、デバイス実装は:

• [C-1-1] 機能 android.hardware.audio.low_latency のサポートをレポートしなければなりません。
• [C-1-2] セクション 5.6 オーディオ レイテンシで規定しているとおり、連続ラウンドトリップ オーディオ レイテンシが 20 ミリ秒以下でなければならず、少なくとも 1 つのサポート対象パスで 10 ミリ秒以下であるべきです。
• [C-1-3] USB ホストモードと USB ペリフェラル モードをサポートする USB ポートを含まなければなりません。
• [C-1-4] 機能 android.software.midi のサポートをレポートしなければなりません。
• [C-1-5] OpenSL ES PCM バッファキュー API を使用して、レイテンシと USB オーディオの要件を満たさなければなりません。
• [SR] オーディオがアクティブで CPU 負荷が変動していても、一貫した CPU パフォーマンス レベルを提供することが強く推奨されます。これは、SimpleSynth commit 1bd6391 を使用してテストすべきです。SimpleSynth アプリは以下のパラメータで実行され、10 分後にアンダーランがゼロになるようにする必要があります。
  • ワークサイクル: 200,000
  • 可変負荷: オン（ワークサイクル値の 100% と 10% が 2 秒ごとに切り替わり、CPU ガバナーの動作をテストするように設計されています）
  • 安定した負荷: オフ
• オーディオ クロックの不正確さと標準時間に対するずれを最小限に抑えるべきです。
• 両方ともアクティブな場合、CPU CLOCK_MONOTONIC に対するずれを最小限に抑えるべきです。
• デバイス上のトランスデューサでオーディオ レイテンシを最小限に抑えるべきです。
• USB デジタル オーディオでオーディオ レイテンシを最小限に抑えるべきです。
• すべてのパスでオーディオ レイテンシ測定値を記録すべきです。
• コールバックによる CPU 帯域幅全体の使用可能率に影響するため、オーディオ バッファ完了コールバック エントリ時間のジッターを最小限に抑えるべきです。
• レポートされたレイテンシで、通常の使用におけるオーディオ アンダーラン（出力）またはオーバーラン（入力）をゼロにすべきです。
• チャンネル間のレイテンシ差をゼロにすべきです。
• すべてのトランスポートで MIDI 平均レイテンシを最小限に抑えるべきです。
• すべてのトランスポートで負荷がかかった状態での MIDI レイテンシのばらつき（ジッター）を最小限に抑えるべきです。
• すべてのトランスポートで MIDI タイムスタンプを正確にすべきです。
• コールド スタート直後の期間を含め、デバイス上のトランスデューサでオーディオ信号ノイズを最小限に抑えるべきです。
• 両方ともアクティブな場合、対応するエンドポイントの入力側と出力側でオーディオ クロックの差をゼロにすべきです。対応するエンドポイントの例としては、デバイス上のマイクとスピーカーや、オーディオ ジャックの入出力が挙げられます。
• 両方ともアクティブな場合、同じスレッド上の対応するエンドポイントの入力側と出力側のオーディオ バッファ完了コールバックを処理し、入力コールバックからのリターンの直後に出力コールバックに入るべきです。または、同じスレッド上でコールバックを処理できない場合は、入力コールバックの直後に出力コールバックに入り、アプリが入力側と出力側のタイミングを一貫させられるようにします。
• 対応するエンドポイントの入力側と出力側で、HAL オーディオ バッファの位相差を最小限に抑えるべきです。
• タップ レイテンシを最小限に抑えるべきです。
• 負荷がかかった状態でのタップ レイテンシのばらつき（ジッター）を最小限に抑えるべきです。

上記の要件をすべて満たす場合、デバイス実装は:

• [SR] android.content.pm.PackageManager クラスを介して機能 android.hardware.audio.pro のサポートをレポートすることが強く推奨されます。

OpenSL ES PCM バッファキュー API を介して要件を満たす場合、デバイス実装は:

• [SR] AAudio API を介して同じ要件を満たすことも強く推奨されます。

4 極 3.5 mm オーディオ ジャックが含まれる場合、デバイス実装は:

• [C-2-1] オーディオ ジャックパスで、連続ラウンドトリップ オーディオ レイテンシを 20 ミリ秒以下にしなければなりません。
• [SR] 有線オーディオ ヘッドセット仕様（v1.1）のモバイル デバイス（ジャック）仕様のセクションに準拠することが強く推奨されます。
• オーディオ ジャックパスで、連続ラウンドトリップ オーディオ レイテンシを 10 ミリ秒以下にすべきです。

4 極 3.5 mm オーディオ ジャックを省略し、USB ホストモードをサポートする USB ポートを含める場合、デバイス実装は:

• [C-3-1] USB オーディオ クラスを実装しなければなりません。
• [C-3-2] USB オーディオ クラスを使用して、USB ホストモードで、連続ラウンドトリップ オーディオ レイテンシを 20 ミリ秒以下にしなければなりません。
• USB オーディオ クラスを使用して、USB ホストモードで、連続ラウンドトリップ オーディオ レイテンシを 10 ミリ秒以下にすべきです。

HDMI ポートが含まれる場合、デバイス実装は:

• [C-4-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] レベル乗算器は、パス上にあることが許容されますが、信号パスに遅延またはレイテンシを導入してはなりません。

SPL の測定はすべて、テスト対象のマイクのすぐ隣で直接行います。マイクが複数ある構成では、これらの要件を各マイクに適用します。

android.hardware.microphone を宣言するが、未処理音源をサポートしない場合、デバイス実装は:

• [C-2-1] サポートしていないことを適切に示すために、AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API メソッドについて null を返さなければなりません。
• [SR] そのうえで、未処理録音源の信号パスに関する要件の多くを満たすことが強く推奨されます。

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

6.1. デベロッパー ツール

デバイス実装は:

• [C-0-1] Android SDK で提供されている Android デベロッパー ツールをサポートしなければなりません。

• Android Debug Bridge（adb）

  • [C-0-2] Android SDK に記載されているとおり、dumpsys を含め、adb のすべての機能をサポートしなければなりません。
  • [C-0-3] dumpsys を介してログに記録されるデバイス システム イベント（batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats）の形式またはコンテンツを変更してはなりません。
  • [C-0-4] デバイス側の adb デーモンをデフォルトで無効にしなければならず、Android Debug Bridge をオンにするためのユーザーがアクセス可能なメカニズムがなければなりません。
  • [C-0-5] セキュア adb をサポートしなければなりません。Android は、セキュア adb をサポートしています。セキュア adb は、既知の認証済みホストで adb を有効にします。

  • [C-0-6] adb をホストマシンから接続できるようにするメカニズムを提供しなければなりません。次に例を示します。

    • USB ポートなしでペリフェラル モードをサポートする場合、デバイス実装はローカルエリア ネットワーク（イーサネット、Wi-Fi など）を介して adb を実装しなければなりません。
    • デベロッパーが adb プロトコルを使用してデバイスに接続できるように、Windows 7、9、10 のドライバを提供しなければなりません。

• Dalvik Debug Monitor Service（ddms）

  • [C-0-7] Android SDK に記載されているとおり、ddms 機能をすべてサポートしなければなりません。ddms は adb を使用するため、ddms のサポートはデフォルトで無効にすべきですが、上記のようにユーザーが Android Debug Bridge を有効にした場合は必ずサポートしなければなりません。
• Monkey
  • [C-0-8] Monkey フレームワークを含まなければならず、アプリで使用できるようにしなければなりません。
• SysTrace
  • [C-0-9] Android SDK に記載されているとおり、systrace ツールをサポートしなければなりません。Systrace はデフォルトで無効でなければならず、Systrace をオンにするユーザーがアクセス可能なメカニズムがなければなりません。

6.2. 開発者向けオプション

Android は、デベロッパーがアプリ開発関連の設定を構成することをサポートしています。

デバイス実装は開発者向けオプションに一貫したエクスペリエンスを提供しなければならず、デバイス実装は:

• [C-0-1] android.settings.APPLICATION_DEVELOPMENT_SETTINGS インテントを使用して、アプリ開発関連の設定を表示しなければなりません。アップストリームの Android 実装では、デフォルトで開発者向けオプション メニューが非表示になっており、ユーザーが [設定] > [デバイス情報] > [ビルド番号] メニュー アイテムを 7 回タップすると開発者向けオプションを起動できます。
• [C-0-2] デフォルトで開発者向けオプションを非表示にしなければならず、特別な許可リストを必要とせずに開発者向けオプションを有効にするメカニズムを提供しなければなりません。
• ユーザーの安全性が懸念されるシナリオでは、メニューを非表示または無効にして、開発者向けオプション メニューへのアクセスを一時的に制限しても構いません。

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 レイアウトを自動的に調整する機能があります。このセクションで詳述するように、デバイスはこれらの API と動作を適切に実装しなければなりません。

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

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

7.1.1. 画面構成

7.1.1.1. 画面サイズ

The 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> 属性を通じて、アプリによる規定の画面サイズのサポートを正しく使用しなければなりません。

7.1.1.2. 画面のアスペクト比

物理画面ディスプレイの画面アスペクト比値に制限はありませんが、サードパーティ アプリがレンダリングする、view.Display API と Configuration API を通じてレポートされる高さと幅の値から得られる論理ディスプレイの画面アスペクト比は、次の要件を満たさなければなりません。

• [C-0-1] Configuration.uiMode が UI_MODE_TYPE_NORMAL に設定されたデバイス実装は、次の条件のいずれかを満たすことでアプリをさらに引き伸ばせる場合を除き、アスペクト比の値を 1.3333（4:3）から 1.86（およそ 16:9）の間にしなければなりません。

  • アプリが、android.max_aspect メタデータ値を通じてより大きな画面アスペクト比のサポートを宣言した。
  • アプリが、android:resizeableActivity 属性を介してサイズ変更可能であることを宣言する。
  • アプリが、API レベル 26 以降を対象としており、許可されるアスペクト比を制限する android:MaxAspectRatio を宣言しない。

• [C-0-2] Configuration.uiMode が UI_MODE_TYPE_WATCH に設定されたデバイス実装は、アスペクト比の値を 1.0（1:1）に設定しなければなりません。

7.1.1.3. 画面密度

Android UI フレームワークは、アプリ デベロッパーがアプリリソースをターゲットにできるように、標準的な論理密度のセットを定義しています。

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

  • 120 dpi（ldpi）
  • 160 dpi（mdpi）
  • 213 dpi（tvdpi）
  • 240 dpi（hdpi）
  • 260 dpi（260dpi）
  • 280 dpi（280dpi）
  • 300 dpi（300dpi）
  • 320 dpi（xhdpi）
  • 340 dpi（340dpi）
  • 360 dpi（360dpi）
  • 400 dpi（400dpi）
  • 420 dpi（420dpi）
  • 480 dpi（xxhdpi）
  • 560 dpi（560dpi）
  • 640 dpi（xxxhdpi）

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

デバイスのディスプレイ サイズを変更するアフォーダンスがある場合:

• [C-1-1] ディスプレイ サイズを、ネイティブ密度の 1.5 倍よりも大きく調整したり、320 dp（リソース修飾子 sw320dp と同等）よりも小さい有効最小画面寸法を生成したりしてはなりません。
• [C-1-2] ディスプレイ サイズを、ネイティブ密度の 0.85 倍よりも小さく調整してはなりません。
• 優れたユーザビリティと一貫したフォントサイズを実現するために、上記の制限を遵守しつつ、次に示すネイティブ ディスプレイ オプションの調整を行えるようにすることが推奨されます。
• 小: 0.85 倍
• デフォルト: 1 倍（ネイティブ ディスプレイ スケール）
• 中: 1.15 倍
• 大: 1.3 倍
• 特大 1.45 倍

7.1.2. ディスプレイの指標

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

• [C-1-1] android.util.DisplayMetrics API で定義されたすべてのディスプレイ指標について正しい値をレポートしなければなりません。

埋め込み画面または動画出力が含まれない場合、デバイス実装は:

• [C-2-1] エミュレートされたデフォルトの view.Display の android.util.DisplayMetrics API で定義されたすべてのディスプレイ指標について、妥当な値をレポートしなければなりません。

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.0 と 2.0 を両方ともサポートしなければなりません。
• [SR] OpenGL ES 3.0 をサポートすることが強く推奨されます。
• OpenGL ES 3.1 または 3.2 をサポートすべきです。

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 をサポートしなければなりません。
• [SR] EGL_KHR_partial_update をサポートすることが強く推奨されます。
• getString() メソッドを介して、サポート対象のテクスチャ圧縮形式（通常はベンダー固有）を正確にレポートすべきです。

OpenGL ES 3.0、3.1 または 3.2 のサポートを宣言する場合、デバイス実装は:

• [C-3-1] libGLESv2.so ライブラリの OpenGL ES 2.0 関数シンボルに加え、これらのバージョンについて、対応する関数シンボルをエクスポートしなければなりません。

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.0 または 3.1 をサポートする場合、デバイス実装は:

• [SR] Vulkan 1.0 のサポートを含むことが強く推奨されます。

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

• Vulkan 1.0 のサポートを含むべきです。

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.0 API を完全に実装しなければなりません。
• [C-1-4] Vulkan ネイティブ API vkEnumerateInstanceLayerProperties() と vkEnumerateDeviceLayerProperties() を通じて、アプリ パッケージのネイティブ ライブラリ ディレクトリにある libVkLayer*.so というネイティブ ライブラリに含まれるレイヤを列挙しなければなりません。
• [C-1-5] アプリの android:debuggable 属性が true に設定されている場合を除き、アプリ パッケージ外のライブラリで提供されるレイヤを列挙したり、Vulkan API をトレースまたはインターセプトする他の方法を提供したりしてはなりません。
• [C-1-6] Vulkan ネイティブ API を介してサポートする拡張機能の文字列をすべてレポートしなければならず、また逆に、正しくサポートしない拡張機能の文字列をレポートしてはなりません。

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

• [C-2-1] Vulkan 機能フラグ（例: android.hardware.vulkan.level、android.hardware.vulkan.version）を宣言してはなりません。
• [C-2-2] Vulkan ネイティブ API vkEnumeratePhysicalDevices() について VkPhysicalDevice を列挙してはなりません。

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 広色域ディスプレイ

Display.isWideColorGamut() を通じて広色域ディスプレイのサポートを主張する場合、デバイス実装は:

• [C-1-1] 色調整されたディスプレイがなければなりません。
• [C-1-2] sRGB 色域全体を CIE 1931 xyY 空間でカバーする色域のディスプレイがなければなりません。
• [C-1-3] 色域の面積が CIE 1931 xyY 空間で NTSC 1953 の少なくとも 90% であるディスプレイがなければなりません。
• [C-1-4] OpenGL ES 3.0、3.1 または 3.2 をサポートし、適切にレポートしなければなりません。
• [C-1-5] 拡張機能 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_colorspace_scrgb_linear、EGL_GL_colorspace_display_p3 のサポートをアドバタイズしなければなりません。
• [SR] GL_EXT_sRGB をサポートすることが強く推奨されます。

逆に、広色域ディスプレイをサポートしない場合、デバイス実装は:

• [C-2-1] 画面色域が未定義であっても、CIE 1931 xyY 空間で sRGB の 100% 以上をカバーすべきです。

7.1.5. レガシーアプリの互換モード

Android は、以前の画面サイズに依存しない Andrdoid の旧バージョン用に開発されていないレガシーアプリを活用するために、フレームワークが「normal」画面サイズ相当（幅 320 dp）のモードで動作する「互換モード」を指定します。

7.1.6. 画面技術

Android プラットフォームには、アプリがリッチ グラフィックをディスプレイにレンダリングできるようにする API があります。このドキュメントで特に許可されていない限り、デバイスは、Android SDK で定義されているこれらの API をすべてサポートしなければなりません。

デバイス実装は:

• [C-0-1] 16 ビットカラー グラフィックをレンダリングできるディスプレイをサポートしなければなりません。
• 24 ビットカラー グラフィックに対応したディスプレイをサポートすべきです。
• [C-0-2] アニメーションをレンダリングできるディスプレイをサポートしなければなりません。
• [C-0-3] ピクセル アスペクト比（PAR）が 0.9～1.15 のディスプレイ技術を使用しなければなりません。つまり、ピクセル アスペクト比は、許容差 10～15% でほぼ正方形（1.0）でなければなりません。

7.1.7. セカンダリ ディスプレイ

Android は、セカンダリ ディスプレイをサポートしており、メディア共有機能と、外部ディスプレイにアクセスするためのデベロッパー API が有効になります。

有線、無線、または埋め込み式いずれかの追加のディスプレイ接続を介して外部ディスプレイをサポートする場合、デバイス実装は:

• [C-1-1] Android SDK ドキュメントに記載されているとおり、DisplayManager システム サービスと API を実装しなければなりません。

7.2. 入力デバイス

デバイス実装は:

• [C-0-1] タッチスクリーンまたはタップ以外のナビゲーションなど、UI 要素間を移動するための入力メカニズムを含まなければなりません。

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-0-1] android.content.res.Configuration.navigation について、正しい値をレポートしなければなりません。

タップ以外のナビゲーションがない場合、デバイス実装は:

• [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] どの単一の操作が各機能をトリガーするかの明確な表示を提供しなければなりません。そうした表示の例としては、ボタンにアイコンを表示する、画面のナビゲーション バー部分にソフトウェア アイコンを表示する、開封時の初期設定中にガイド付きの段階的なデモフローを通じてユーザーに説明する、などが挙げられます。

デバイス実装は:

• [SR] Android 4.0 以降、アクションバーが優先されてメニュー機能はサポートが終了しているため、メニュー機能のための入力メカニズムを提供しないことが強く推奨されます。

メニュー機能を提供する場合、デバイス実装は:

• [C-2-1] アクション オーバーフロー メニューのポップアップが空ではなく、アクションバーが表示されているときは常に、アクション オーバーフロー ボタンを表示しなければなりません。
• [C-2-2] アクションバーのオーバーフロー ボタンを選択することで表示されるアクション オーバーフロー ポップアップの位置を変更してはなりませんが、メニュー機能を選択することで表示されるときは、アクション オーバーフロー ポップアップを画面上の変更された位置にレンダリングしても構いません。

メニュー機能を提供しない場合、下位互換性のために、デバイス実装は:

• [C-3-1] targetSdkVersion が 10 未満のときは、物理ボタン、ソフトウェア キー、ジェスチャーのいずれかによって、メニュー機能をアプリで利用できるようにしなければなりません。このメニュー機能は、他のナビゲーション機能とともに非表示になっている場合を除き、アクセス可能にすべきです。

アシスト機能を提供する場合、デバイス実装は:

• [C-4-1] 他のナビゲーション キーがアクセス可能な場合、単一の操作（タップ、ダブルクリック、ジェスチャーなど）によってアシスト機能にアクセスできるようにしなければなりません。
• [SR] この指定操作として、ホーム機能の長押しを使用することが強く推奨されます。

ナビゲーション キーを表示するために画面の区分けされた部分を使用する場合、デバイス実装は:

• [C-5-1] ナビゲーション キーは、アプリでは利用できない、画面の区分けされた部分を使用しなければならず、アプリで利用できる画面部分を隠したり、利用を妨げたりしてはなりません。
• [C-5-2] ディスプレイの一部を、セクション 7.1.1 で規定する要件を満たすアプリで利用できるようにしなければなりません。
• [C-5-3] SDK に記載されているとおり、View.setSystemUiVisibility() API メソッドを通じてアプリが設定したフラグを使用して、この画面の区分けされた部分（ナビゲーション バー）が適切に非表示になるようにしなければなりません。

7.2.4. タッチスクリーン入力

Android は、タッチスクリーン、タッチパッド、疑似タップ入力デバイスなど、さまざまなポインタ入力システムをサポートしています。タッチスクリーンベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるようなディスプレイに関連付けられます。ユーザーが画面に直接触れているため、操作中のオブジェクトを示すアフォーダンスを追加する必要はありません。

デバイス実装は:

• なんらかのポインタ入力システム（マウスのようなもの、またはタップ）があるべきです。
• 完全に独立してトラックされるポインタをサポートすべきです。

タッチスクリーン（シングルタップ以上）が含まれる場合、デバイス実装は:

• [C-1-1] Configuration.touchscreen API フィールドについて TOUCHSCREEN_FINGER をレポートしなければなりません。
• [C-1-2] 機能フラグ android.hardware.touchscreen と android.hardware.faketouch をレポートしなければなりません。

複数のタップをトラックできるタッチスクリーンが含まれる場合、デバイス実装は:

• [C-2-1] デバイス上の具体的なタッチスクリーンの種類に応じた、該当する機能フラグ android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand をレポートしなければなりません。

タッチスクリーンを含まず（かつ、ポインタ デバイスのみに依存）、セクション 7.2.5 の疑似タップの要件を満たしている場合、デバイス実装は:

• [C-3-1] android.hardware.touchscreen で始まる機能フラグをレポートしてはならず、android.hardware.faketouch のみをレポートしなければなりません。

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] ユーザーが画面上のオブジェクトをフリングできるように、ポインタの下移動をサポートし、ユーザーが画面上の別の位置にオブジェクトを素早く移動してから画面上でポインタを上移動できるようにしなければなりません。
• [C-1-7] Configuration.touchscreen API フィールドについて TOUCHSCREEN_NOTOUCH をレポートしなければなりません。

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. ボタン マッピング

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

• [C-1-1] コントローラを埋め込むか、下表に記載されているイベントすべての入力手段を提供する別個のコントローラを同梱しなければなりません。
• [C-1-2] 下表に記載されているとおり、HID イベントを、関連する Android view.InputEvent 定数にマッピングできなければなりません。アップストリームの Android 実装には、この要件を満たすゲーム コントローラの実装が含まれています。

ボタン	HID 使用状況^2	Android ボタン
A^1	0x09 0x0001	KEYCODE_BUTTON_A（96）
B^1	0x09 0x0002	KEYCODE_BUTTON_B（97）
X^1	0x09 0x0004	KEYCODE_BUTTON_X（99）
Y^1	0x09 0x0005	KEYCODE_BUTTON_Y（100）
D-pad 上^1 D-pad 下^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-pad 左1 D-pad 右^1	0x01 0x0039^3	AXIS_HAT_X^4
左ショルダーボタン^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 0x0223	KEYCODE_HOME（3）
戻る^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] 最大レイテンシ 100 ミリ秒のセンサーデータをレポートしなければなりません。
• アプリ プロセッサがアクティブで、必要な最小レイテンシが 5 ms + 2 * sample_time のセンサー ストリームの場合は、2 * sample_time です。この遅延にフィルタリングの遅延は含まれません。
• [C-1-3] センサーがアクティブになっている 400 ミリ秒 + 2 * sample_time 以内に最初のセンサー サンプルをレポートしなければなりません。このサンプルの正確度は 0 でも許容されます。

• [SR] Android SDK ドキュメントで定義されているとおり、ナノ秒単位でイベント時刻をレポートすべきです。これはイベントが発生した時刻を表し、SystemClock.elapsedRealtimeNano() クロックと同期されています。既存と新規の Android デバイスは、これらの要件を満たすことが強く推奨されます。そうすれば、これが必須コンポーネントとなる将来のプラットフォーム リリースへのアップグレードが可能になります。同期エラーは 100 ミリ秒未満であるべきです。

• [C-1-7] 連続センサーであることが Android SDK ドキュメントで示されている API の場合、デバイス実装は、ジッターが 3% 未満であるべき定期データサンプルを継続的に提供しなければなりません（ジッターは、連続するイベント間でレポートされるタイムスタンプ値の標準偏差として定義されます）。

• [C-1-8] デバイス CPU がサスペンド状態に入ること、またはサスペンド状態から復帰することを、センサー イベント ストリームが妨げてはならないということを保証しなければなりません。

• 複数のセンサーが有効になっているとき、消費電力は、個々のセンサーがレポートした消費電力の合計を超えるべきではありません。

上記のリストは包括的なものではありません。センサーに関する Android SDK ドキュメントと Android オープンソース ドキュメントに記載されている動作を、信頼できるものとみなします。

一部のセンサータイプは複合型です。つまり、1 つ以上の他のセンサーによって提供されるデータから得られることがあります（方向センサーや直線加速度センサーなど）。

デバイス実装は:

• センサーの種類に記載されているとおり、必須の物理センサーを含む場合、これらのセンサータイプを実装すべきです。

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

• [C-2-1] 複合センサーに関する Android オープンソース ドキュメントに記載されているとおり、センサーを実装しなければなりません。

7.3.1. 加速度計

• デバイス実装は、3 軸加速度計を含むべきです。

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

• [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
• [C-1-2] TYPE_ACCELEROMETER センサーを実装し、レポートしなければなりません。
• [C-1-3] Android API で詳述されているとおり、Android センサー座標系に準拠しなければなりません。
• [C-1-4] どの軸でも、自由落下から重力の 4 倍（4g）以上まで測定できなければなりません。
• [C-1-5] 解像度が少なくとも 12 ビットでなければなりません。
• [C-1-6] 標準偏差が 0.05 m/s^ 以下でなければなりません。標準偏差は、最速サンプリング レートで少なくとも 3 秒間にわたって収集されたサンプルについて、軸ごとに計算すべきです。
• [SR] TYPE_SIGNIFICANT_MOTION 複合センサーを実装することが強く推奨されます。
• [SR] オンライン加速度計のキャリブレーションが利用可能な場合、TYPE_ACCELEROMETER_UNCALIBRATED センサーを実装することが強く推奨されます。
• Android SDK ドキュメントに記載されているとおり、複合センサー TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER を実装すべきです。
• 少なくとも 200 Hz までのイベントをレポートすべきです。
• 解像度が少なくとも 16 ビットであるべきです。
• ライフサイクル中に特性が変化して補正される場合、使用中に調整すべきであり、デバイスが再起動される間も補正パラメータを保持すべきです。
• 温度補正すべきです。
• TYPE_ACCELEROMETER_UNCALIBRATED センサーも実装すべきです。

3 軸加速度計が含まれ、TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER いずれかの複合センサーが実装される場合、デバイス実装は:

• [C-2-1] 消費電力の合計が常に 4 mW 未満でなければなりません。
• デバイスが動的状態または静的状態にあるとき、それぞれ 2 mW 未満、0.5 mW 未満であるべきです。

3 軸加速度計とジャイロスコープ センサーが含まれる場合、デバイス実装は:

• [C-3-1] 複合センサー TYPE_GRAVITY と TYPE_LINEAR_ACCELERATION を実装しなければなりません。
• TYPE_GAME_ROTATION_VECTOR 複合センサーを実装すべきです。
• [SR] 既存と新規の Android デバイスに TYPE_GAME_ROTATION_VECTOR センサーを実装することが強く推奨されます。

3 軸加速度計、ジャイロスコープ センサー、磁力計センサーが含まれる場合、デバイス実装は:

• [C-4-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

7.3.2. 磁力計

• デバイス実装は、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 以下であるべきです。
• TYPE_MAGNETIC_FIELD_UNCALIBRATED センサーを実装すべきです。
• [SR] 既存と新規の Android デバイスに TYPE_MAGNETIC_FIELD_UNCALIBRATED センサーを実装することが強く推奨されます。

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

デバイス実装は:

• 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 技術を使用することで満たします（支援データには基準時間、基準位置、衛星エフェメリス / クロックが含まれます）。
  • [SR] 前述の位置情報を計算した後、位置情報のリクエストが再開されたとき、初期位置計算から最大 1 時間後まで、後続のリクエストがデータ接続なしで行われたときや、電源をオフにして再度オンにした後であっても、全天条件下で 10 秒以内にデバイスで位置を決定できることが強く推奨されます。

• 位置を決定した後、全天条件下で、静止しながら、または加速度 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-1-5] テスト API「getGnssYearOfHardware」を通じて GNSS テクノロジーの世代をレポートしなければなりません。
  • [SR] 緊急通報の際も、GPS / GNSS 位置情報の通常の出力を継続します。
  • [SR] SBAS を除き、トラックしたすべてのコンステレーションからの GNSS 測定値を（GnssStatus メッセージでレポートされたとおり）レポートします。
  • [SR] AGC と、GNSS 測定の頻度をレポートします。
  • [SR] すべての正確度推定値（方位角、速度、垂直を含む）を、各 GPS 位置情報の一部としてレポートします。
  • [SR] Test API LocationManager.getGnssYearOfHardware() を介して「2016 年」または「2017 年」をレポートするデバイスに関する必須の追加要件から、できる限り多くの要件を満たすことが強く推奨されます。

GPS / GNSS レシーバーが含まれ、android.hardware.location.gps 機能フラグを介してアプリに機能をレポートし、LocationManager.getGnssYearOfHardware() Test API が年「2016」以降をレポートする場合、デバイス実装は:

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

GPS / GNSS レシーバーが含まれ、android.hardware.location.gps 機能フラグを介してアプリに機能をレポートし、LocationManager.getGnssYearOfHardware() Test API が年「2017」以降をレポートする場合、デバイス実装は:

• [C-3-1] 緊急通報の際も、GPS / GNSS 位置情報の通常の出力を継続しなければなりません。
• [C-3-2] SBAS を除き、トラックしたすべてのコンステレーションからの GNSS 測定値を（GnssStatus メッセージでレポートされたとおり）レポートしなければなりません。
• [C-3-3] AGC と、GNSS 測定の頻度をレポートしなければなりません。
• [C-3-4] すべての正確度推定値（方位角、速度、垂直を含む）を、各 GPS 位置情報の一部としてレポートしなければなりません。

7.3.4. ジャイロスコープ

デバイス実装は:

• ジャイロスコープ（角度変化センサー）を含むべきです。
• 3 軸加速度計も含まない限り、ジャイロスコープ センサーを含むべきではありません。

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

• [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
• [C-1-2] TYPE_GYROSCOPE センサーを実装しなければならず、TYPE_GYROSCOPE_UNCALIBRATED センサーも実装すべきです。
• [C-1-3] 1,000 度/秒までの方向変化を測定できなければなりません。
• [C-1-4] 解像度が 12 ビット以上でなければならず、解像度が 16 ビット以上であるべきです。
• [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 以下であるべきです。
• [SR] 既存と新規の Android デバイスに SENSOR_TYPE_GYROSCOPE_UNCALIBRATED センサーを実装することが強く推奨されます。
• [SR] 補正誤差は、室温でデバイスが静止しているとき、0.01 rad/s 未満であることが強く推奨されます。
• 少なくとも 200 Hz までのイベントをレポートすべきです。

ジャイロスコープ、加速度計センサー、磁力計センサーが含まれる場合、デバイス実装は:

• [C-2-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

ジャイロスコープと加速度センサーが含まれる場合、デバイス実装は:

• [C-3-1] 複合センサー TYPE_GRAVITY と TYPE_LINEAR_ACCELERATION を実装しなければなりません。
• [SR] 既存と新規の Android デバイスに TYPE_GAME_ROTATION_VECTOR センサーを実装することが強く推奨されます。
• TYPE_GAME_ROTATION_VECTOR 複合センサーを実装すべきです。

7.3.5. 気圧計

• デバイス実装は気圧計（大気圧センサー）を含むべきです。

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

• [C-1-1] TYPE_PRESSURE センサーを実装し、レポートしなければなりません。
• [C-1-2] 5 Hz 以上でイベントを配信できなければなりません。
• [C-1-3] 温度補正しなければなりません。
• [SR] 300 hPa から 1,100 hPa までの圧力測定値をレポートできることが強く推奨されます。
• 絶対正確度が 1 hPa であるべきです。
• 相対正確度が 20 hPa の範囲で 0.12 hPa であるべきです（海面における ~200 m の変化で正確度 ~1 m に相当）。

7.3.6. 温度計

デバイス実装は、周囲温度計（温度センサー）を含んでも構いません。CPU 温度センサーを含んでいても構いませんが、含むべきではありません。

周囲温度計（温度センサー）が含まれる場合、デバイス実装は:

• [C-1-1] SENSOR_TYPE_AMBIENT_TEMPERATURE として定義されなければならず、ユーザーがデバイスを操作している場所の周囲の温度（室温 / 車内温度）を摂氏で測定しなければなりません。
• [C-1-2] SENSOR_TYPE_TEMPERATURE として定義されなければなりません。
• [C-1-3] デバイスの CPU の温度を測定しなければなりません。
• [C-1-4] 他の温度を測定してはなりません。

Android 4.0 で SENSOR_TYPE_TEMPERATURE センサータイプが非推奨になりました。

7.3.7. 光度計

• デバイス実装は、光度計（周囲光センサー）を含んでも構いません。

7.3.8. 近接センサー

• デバイス実装は、近接センサーを含んでも構いません。

近接センサーが含まれる場合、デバイス実装は:

• [C-1-1] 画面と同じ向きで物体の近接を測定しなければなりません。つまり近接センサーは、画面の近くにある物体を検出するような向きでなければなりません。これは、スマートフォンをユーザーが使用中であることの検出が、この種のセンサーの主な目的であるためです。他の向きの近接センサーを含む場合、デバイス実装は、この API を通じてアクセス可能であってはなりません。
• [C-1-2] 正確度が 1 ビット以上でなければなりません。

7.3.9. ハイファイ センサー

このセクションで規定するとおり、高品質センサーのセットが含まれ、サードパーティ アプリで利用できるようにする場合、デバイス実装は:

• [C-1-1] android.hardware.sensor.hifi_sensors 機能フラグを通じて機能を識別しなければなりません。

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

• [C-2-1] 次の条件を満たす TYPE_ACCELEROMETER センサーがなければなりません。

  • 測定範囲が少なくとも -8g～+8g でなければなりません。
  • 測定解像度が少なくとも 1,024 LSB/G でなければなりません。
  • 最小測定周波数が 12.5 Hz 以下でなければなりません。
  • 最大測定周波数が 400 Hz 以上でなければなりません。
  • 測定雑音が 400 uG/√Hz 以下でなければなりません。
  • 少なくとも 3,000 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
  • 計量消費電力が 3 mW 以下でなければなりません。
  • 24 時間の静的データセットにおける雑音のバイアス値が、15 μg √Hz 未満で安定しているべきです。
  • 温度に対するバイアス変化が +/- 1 mg/°C 以下であるべきです。
  • 最良適合線が非線形で 0.5% 以下、温度に対する感度変化が 0.03%/C° 以下であるべきです。
  • センサーノイズの一貫性が適切に認定されるように、ホワイトノイズ スペクトルがあるべきです。

• [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 以上でなければなりません。
  • 測定雑音が 0.014°/s/√Hz 以下でなければなりません。
  • 24 時間の静的データセットにおけるバイアス値が、0.0002 °/s √Hz 未満で安定しているべきです。
  • 温度に対するバイアス変化が +/- 0.05 °/ s / °C 以下であるべきです。
  • 温度に対する感度変化が 0.02% / °C 以下であるべきです。
  • 最良適合線が非線形で 0.2% 以下であるべきです。
  • 雑音密度が 0.007 °/s/√Hz 以下であるべきです。
  • センサーノイズの一貫性が適切に認定されるように、ホワイトノイズ スペクトルがあるべきです。
  • 静止しているとき、温度範囲 10～40℃ で調整誤差が 0.002 rad/s 未満であるべきです。

• [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED の品質要件が TYPE_GYROSCOPE と同じでなければなりません。

• [C-2-5] 次の条件を満たす TYPE_GEOMAGNETIC_FIELD センサーがなければなりません。
  • 測定範囲が少なくとも -900～+900 uT でなければなりません。
  • 測定解像度が少なくとも 5 LSB/uT でなければなりません。
  • 最小測定周波数が 5 Hz 以下でなければなりません。
  • 最大測定周波数が 50 Hz 以上でなければなりません。
  • 測定雑音が 0.5 uT 以下でなければなりません。
• [C-2-6] TYPE_MAGNETIC_FIELD_UNCALIBRATED の品質要件が TYPE_GEOMAGNETIC_FIELD と同じでなければならず、さらに:
  • 少なくとも 600 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
  • センサーノイズの一貫性が適切に認定されるように、ホワイトノイズ スペクトルがあるべきです。
• [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 センサーがなければなりません。
  • 少なくとも 300 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
  • 計量消費電力が 4 mW 以下でなければなりません。
• [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 ミリ秒以内でなければなりません。
• [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_HARDWARE_BUFFER
• TYPE_MEMORY_FILE
• 次のタイプのプライマリ センサー（非ウェイクアップ バリアント）のセンサー ダイレクト チャネルを通じたイベント レポートをサポートすべきです。
• TYPE_ACCELEROMETER
• TYPE_ACCELEROMETER_UNCALIBRATED
• TYPE_GYROSCOPE
• TYPE_GYROSCOPE_UNCALIBRATED
• TYPE_MAGNETIC_FIELD
• TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 指紋認証センサー

セキュアロック画面が含まれる場合、デバイス実装は:

• 指紋認証センサーを含むべきです。

指紋認証センサーが含まれ、センサーをサードパーティ アプリで利用できるようにする場合、デバイス実装は:

• [C-1-1] android.hardware.fingerprint 機能のサポートを宣言しなければなりません。
• [C-1-2] Android SDK ドキュメントに記載されているとおり、対応する API を完全に実装しなければなりません。
• [C-1-3] 他人受け入れ率が 0.002% 以下でなければなりません。
• [SR] スプーフィング受け入れ率となりすまし受け入れ率が 7% 以下であることが強く推奨されます。
• [C-1-4] このモードが強い PIN、パターン、パスワードよりも安全性が低い可能性があることを開示しなければならず、スプーフィング受け入れ率となりすまし受け入れ率が 7% を超える場合に、このモードを有効にすることのリスクを明確に列挙しなければなりません。
• [C-1-5] 指紋認証を検証するために、偽試行を 5 回行ってから少なくとも 30 秒間、制限試行を評価しなければなりません。
• [C-1-6] ハードウェア格納型キーストアを実装し、高信頼実行環境（TEE）または TEE へのセキュア チャネルを持つチップでフィンガープリント マッチングを実行しなければなりません。
• [C-1-7] Android オープンソース プロジェクトのサイトにある実装ガイドラインに記載されているとおり、識別可能なすべての指紋データを暗号化して、高信頼実行環境（TEE）の外部で取得、読み取り、または変更できないように暗号で認証しなければなりません。
• [C-1-8] 最初に既存のチェーンをユーザーに確認してもらうか、TEE によって保護される新しいデバイス認証情報（PIN / パターン / パスワード）を追加することにより、指紋を追加できないようにしなければなりません。Android オープンソース プロジェクトの実装により、そのためのフレームワークが提供されます。
• [C-1-9] サードパーティ アプリで個々の指紋を区別できるようにしてはなりません。
• [C-1-10] DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT フラグを使用しなければなりません。
• [C-1-11] Android 6.0 より前のバージョンからアップグレードした場合、上述の要件を満たすために、指紋データを安全に移行しなければなりません。
• [SR] デバイスで測定したときの本人拒否率が 10% 未満であることが強く推奨されます。
• [SR] 登録した 1 本の指について、指紋認証センサーがタッチされてから画面がロック解除されるまでのレイテンシが 1 秒未満であることが強く推奨されます。
• Android オープンソース プロジェクトで提供されている Android フィンガープリント アイコンを使用すべきです。

7.3.11. Android Automotive 専用センサー

自動車固有のセンサーは、android.car.CarSensorManager API で定義されます。

7.3.11.1. 現在のギア

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

7.3.11.2. 日中夜間モード

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

7.3.11.3. 運転状況

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

7.3.11.4. 車輪回転速度

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

7.3.12. 姿勢センサー

デバイス実装は:

• 6 自由度の姿勢センサーをサポートしても構いません。

6 自由度の姿勢センサーをサポートする場合、デバイス実装は:

• [C-1-1] TYPE_POSE_6DOF センサーを実装し、レポートしなければなりません。
• [C-1-2] 回転ベクトルのみの場合よりも正確でなければなりません。

7.4. データ接続

7.4.1. 電話

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

• Android は、電話ハードウェアを含まないデバイスで使用しても構いません。つまり、Android はスマートフォンではないデバイスに対応しています。

GSM または CDMA 電話が含まれる場合、デバイス実装は:

• [C-1-1] android.hardware.telephony 機能フラグと、テクノロジーに応じて他のサブ機能フラグを宣言しなければなりません。
• [C-1-2] そのテクノロジー向けの API の完全なサポートを実装しなければなりません。

電話ハードウェアが含まれない場合、デバイス実装は:

• [C-2-1] 完全な API を NoOps として実装しなければなりません。

7.4.1.1. 番号ブロックの互換性

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

• [C-1-1] 番号ブロックのサポートを含まなければなりません。
• [C-1-2] SDK ドキュメントに記載されているとおり、BlockedNumberContract と、対応する API を完全に実装しなければなりません。
• [C-1-3] アプリを操作せずに、「BlockedNumberProvider」の電話番号からの通話とメッセージをすべてブロックしなければなりません。唯一の例外は、SDK ドキュメントに記載されているとおり、番号ブロックが一時的に解除されている場合です。
• [C-1-4] ブロックした通話について、プラットフォーム通話履歴プロバイダに書き込んではなりません。
• [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 をレポートする場合、デバイス実装は:

• [C-SR] android.telecom API について、オーディオ ヘッドセットの KEYCODE_MEDIA_PLAY_PAUSE イベントと KEYCODE_HEADSETHOOK イベントを下記のとおり処理することが強く推奨されます。
  • 通話中に短押しのキーイベントが検出されたら、Connection.onDisconnect() を呼び出す。
  • 着信中に短押しのキーイベントが検出されたら、Connection.onAnswer() を呼び出す。
  • 着信中に長押しのキーイベントが検出されたら、Connection.onReject() を呼び出す。
  • CallAudioState のミュート ステータスを切り替える。

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）をフィルタしてはなりません。:
  • 画面がアクティブ状態でないとき。
  • Android テレビデバイス実装の場合、スタンバイ電力状態にあるとき。
• STA が接続されていないとき、各スキャンの開始時に 1 回、送信元 MAC アドレスと、プローブ リクエスト フレームのシーケンス番号をランダム化すべきです。
  • 1 回のスキャンを構成するプローブ リクエスト フレームの各グループは、一貫した 1 つの MAC アドレスを使用すべきです（スキャンの途中で MAC アドレスをランダム化すべきではありません）。
  • プローブ リクエストのシーケンス番号は、スキャン内のプローブ リクエスト間で通常どおり（順番に）繰り返すべきです。
  • プローブ リクエストのシーケンス番号は、スキャンの最後のプローブ リクエストと後続するスキャンの最初のプローブ リクエストの間でランダム化すべきです。
• STA が接続解除されている間、プローブ リクエスト フレームで次の情報要素のみを許可すべきです。
  • SSID パラメータ セット（0）
  • DS パラメータ セット（3）

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 運用をサポートしなければなりません。
• Wi-Fi と Wi-Fi Direct の運用を同時にサポートすべきです。

7.4.2.2. Wi-Fi Tunneled Direct Link Setup

デバイス実装は:

• Android SDK ドキュメントに記載されているとおり、Wi-Fi Tunneled Direct Link Setup（TDLS）のサポートを含むべきです。

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 のサポートを含むべきです。

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 管理インターフェースのアドレスをランダム化しなければなりません。

7.4.2.4. Wi-Fi Passpoint

デバイス実装は:

• Wi-Fi Passpoint のサポートを含むべきです。

Wi-Fi Passpoint のサポートが含まれる場合、デバイス実装は:

• [C-1-1] SDK ドキュメントに記載されているとおり、Passpoint 関連の WifiManager API を実装しなければなりません。
• [C-1-2] IEEE 802.11u 規格、特に Generic Advertisement Service（GAS）や Access Network Query Protocol（ANQP）など、ネットワークの検出と選択に関連するものをサポートしなければなりません。

逆に、デバイス実装に Wi-Fi Passpoint のサポートが含まれない場合:

• [C-2-1] Passpoint 関連の WifiManager API の実装は、UnsupportedOperationException をスローしなければなりません。

7.4.3. Bluetooth

Bluetooth オーディオ プロファイルをサポートする場合、デバイス実装は:

• Advanced オーディオ コーデックと Bluetooth オーディオ コーデック（LDAC など）をサポートすべきです。

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、AVCP、OBEX など、関連する Bluetooth プロファイルを実装すべきです。

Bluetooth Low Energy のサポートが含まれる場合、デバイス実装は:

• [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() の正しい値をレポートしなければなりません。
• ScanFilter API を実装するとき、Bluetooth チップセットに対するフィルタリング ロジックのオフロードをサポートすべきです。
• Bluetooth チップセットに対するバッチスキャンのオフロードをサポートすべきです。

• 少なくとも 4 スロットのマルチ アドバタイズメントをサポートすべきです。

• [SR] ユーザーのプライバシーを保護するために、15 分以下の解決可能なプライベート アドレス（RPA）タイムアウトを実装し、タイムアウト時にアドレスをローテーションすることが強く推奨されます。

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 フォーラムにより定義）

• [SR] 次の NFC 規格を介して NDEF メッセージと元データを読み書きできることが強く推奨されます。なお、NFC 規格は「強く推奨」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。これらの規格は、このバージョンでは任意ですが、今後のバージョンでは必須となります。このバージョンの Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが極めて強く奨励されています。

• [C-1-3] 次のピアツーピア標準とプロトコルを介してデータを送受信できなければなりません。

• ISO 18092
• LLCP 1.2（NFC フォーラムにより定義）
• SDP 1.0（NFC フォーラムにより定義）
• NDEF プッシュ プロトコル
• SNEP 1.0（NFC フォーラムにより定義）
• [C-1-4] Android ビームのサポートを含まなければならず、デフォルトで Android ビームを有効にするべきです。
• [C-1-5] Android ビームが有効であるか、別の独自の NFC P2p モードがオンになっているとき、Android ビームを使用して送受信できなければなりません。
• [C-1-6] SNEP デフォルト サーバーを実装しなければなりません。デフォルトの SNEP サーバーで受信した有効な NDEF メッセージは、android.nfc.ACTION_NDEF_DISCOVERED インテントを使用してアプリにディスパッチしなければなりません。設定で Android ビームを無効にしたときは、受信した NDEF メッセージのディスパッチを無効にしてはなりません。
• [C-1-7] android.settings.NFCSHARING_SETTINGS インテントを使用して NFC 共有設定を表示しなければなりません。
• [C-1-8] NPP サーバーを実装しなければなりません。NPP サーバーが受信するメッセージは、SNEP デフォルト サーバーと同じ方法で処理されなければなりません。
• [C-1-9] Android ビームが有効になっているときは、SNEP クライアントを実装し、送信 P2P NDEF のデフォルトの SNEP サーバーへの送信を試行しなければなりません。デフォルトの SNEP サーバーが見つからない場合、クライアントは NPP サーバーへの送信を試行しなければなりません。
• [C-1-10] フォアグラウンド アクティビティが、android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback、android.nfc.NfcAdapter.enableForegroundNdefPush を使用して送信 P2P NDEF メッセージを設定できるようにしなければなりません。
• 送信 P2P NDEF メッセージを送信する前に、「タップしてビーム」などのジェスチャーまたは画面上の確認を使用すべきです。
• [C-1-11] デバイスが Bluetooth オブジェクト プッシュ プロファイルをサポートしている場合は、Bluetooth への NFC 接続ハンドオーバーをサポートしなければなりません。
• [C-1-12] android.nfc.NfcAdapter.setBeamPushUris を使用する場合、「接続ハンドオーバー バージョン 1.2」および NFC フォーラムの「NFC を使用した Bluetooth Secure Simple Pairing バージョン 1.0」の仕様を実装して Bluetooth への接続ハンドオーバーをサポートしなければなりません。このような実装では、NFC を介してハンドオーバー リクエスト / 選択レコードを交換するために、サービス名「urn:nfc:sn:handover」を持つハンドオーバー LLCP サービスを実装しなければならず、実際の Bluetooth データ転送には Bluetooth オブジェクト プッシュ プロファイルを使用しなければなりません。実装は、レガシーに関する理由（Android 4.1 デバイスとの互換性の維持）により、NFC を介してハンドオーバーのリクエスト / 選択レコードを交換するために、SNEP GET リクエストを引き続き受け入れるべきです。ただし、実装自体が、接続ハンドオーバーを実行するための SNEP GET リクエストを送信すべきではありません。
• [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 API を実装しなければなりません。
• [C-4-2] android.content.pm.PackageManager.hasSystemFeature() メソッドから com.nxp.mifare 機能をレポートしなければなりません。なお、これは Android の標準の機能ではないため、android.content.pm.PackageManager クラスの定数としては表示されません。

7.4.5. 最低限のネットワーク機能

デバイス実装は:

• [C-0-1] 1 つ以上のデータ ネットワーク形式のサポートを含まなければなりません。具体的には、デバイス実装は、200 Kbit/sec 以上の能力を持つ、少なくとも 1 つのデータ標準のサポートを含まなければなりません。この要件を満たす技術の例としては、EDGE、HSPA、EV-DO、802.11g、イーサネット、Bluetooth PAN が挙げられます。
• [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 接続が失われてはなりません。
• 物理的なネットワーク標準（イーサネットなど）がメインのデータ接続である場合、802.11（Wi-Fi）など、1 つ以上の一般的なワイヤレス データ標準のサポートを含むべきです。
• 複数の形式のデータ接続を実装しても構いません。

必要な IPv6 サポートレベルは、ネットワークの種類に応じて次のように異なります。

Wi-Fi ネットワークをサポートする場合、デバイス実装は:

• [C-1-1] Wi-Fi でのデュアルスタックと IPv6 のみのオペレーションをサポートしなければなりません。

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

• [C-2-1] イーサネットでのデュアルスタック オペレーションをサポートしなければなりません。

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

• [C-3-1] デバイスが同時に複数のネットワークに接続されている（例: Wi-Fi、モバイルデータ）場合は、接続されている各ネットワークについて、これらの要件を同時に満たさなければなりません。
• モバイルデータに対する IPv6 オペレーション（IPv6 のみ、場合によってはデュアルスタック）をサポートすべきです。

7.4.6. 同期設定

デバイス実装は:

• [C-0-1] メソッド getMasterSyncAutomatically() が「true」を返すように、マスター自動同期設定をデフォルトでオンにしなければなりません。

7.4.7. データセーバー

従量制接続が含まれる場合、デバイス実装は:

• [SR] データセーバー モードを提供することが強く推奨されます。

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

• [C-1-1] SDK ドキュメントに記載されているとおり、ConnectivityManager クラスの API をすべてサポートしなければなりません。
• [C-1-2] 設定に Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS インテントを処理するユーザー インターフェースを提供し、ユーザーがアプリを許可リストに登録したり、許可リストから削除したりできるようにしなければなりません。

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

• [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() について値 RESTRICT_BACKGROUND_STATUS_DISABLED を返さなければなりません。
• [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED をブロードキャストしてはなりません。
• [C-2-3] Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS インテントを処理するアクティビティを持たなければなりませんが、NoOps として実装しても構いません。

7.5. カメラ

カメラが 1 つ以上含まれる場合、デバイス実装は:

• [C-1-1] android.hardware.camera.any 機能フラグを宣言しなければなりません。
• [C-1-2] カメラが基本的なプレビューのために開かれ、引き続きキャプチャしているとき、デバイス上の最大解像度のカメラセンサーによって生成された画像のサイズに等しい 3 つの RGBA_8888 ビットマップを、アプリが同時に割り当てることができなければなりません。

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-5] 現在のアプリが android.hardware.Camera.setDisplayOrientation() メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的にリクエストした場合、カメラ プレビューは、アプリが指定した画面の向きに対して水平方向にミラーリングされなければなりません。逆に、現在のアプリが android.hardware.Camera.setDisplayOrientation() メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的にリスエストしなかった場合、カメラ プレビューは、デバイスのデフォルトの水平軸に沿ってミラーリングされなければなりません。
• [C-1-6] アプリのコールバックに対して返されたか、メディア ストレージに対してコミットされた、キャプチャした最終的な静止画または動画のストリームをミラーリングしてはなりません。
• [C-1-7] カメラ プレビューの画像ストリームと同じ方法で、ポストビューで表示される画像をミラーリングしなければなりません。
• セクション 7.5.1 に記載されているとおり、背面カメラで利用できる機能（オートフォーカス、フラッシュなど）を含めても構いません。

デバイス実装が、ユーザーによって回転できる場合（たとえば、加速度計を介して自動的に、またはユーザー入力を介して手動で）:

• [C-2-1] カメラ プレビューは、デバイスの現在の画面の向きに対して水平方向にミラーリングされなければなりません。

7.5.3. 外部カメラ

デバイス実装は:

• 常に接続されているとは限らない外部カメラのサポートを含むべきです。

外部カメラのサポートが含まれる場合、デバイス実装は:

• [C-1-1] プラットフォーム機能フラグ android.hardware.camera.external と android.hardware camera.any を宣言しなければなりません。
• [C-1-2] 外部カメラが USB ポートを通じて接続される場合、USB ビデオクラス（UVC 1.0 以上）をサポートしなければなりません。
• 高品質な未エンコード ストリーム（つまり、未加工または個別に圧縮された画像ストリーム）の転送を可能にするために、MJPEG のような動画圧縮をサポートすべきです。
• 複数のカメラをサポートしても構いません。
• カメラベースの動画エンコードをサポートしても構いません。サポートする場合は、同時未エンコード / MJPEG ストリーム（解像度が QVGA 以上）がデバイス実装からアクセス可能でなければなりません。

7.5.4. Camera API の動作

Android には、カメラにアクセスするための API パッケージが 2 つあります。新しい android.hardware.camera2 API は、下位レベルのカメラ制御をアプリに公開します。これには、効率的なゼロコピー バースト / ストリーミング フローと、フレームごとの露出、ゲイン、ホワイト バランスゲイン、色変換、ノイズ除去、シャープニングなどの制御が含まれます。

古い API パッケージ android.hardware.Camera は、Android 5.0 でサポートが終了しましたが、引き続きアプリでの使用はできるはずです。Android デバイス実装は、このセクションと Android SDK に記載されているとおり、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 ドキュメントに含まれる Camera API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、（オートフォーカスのないカメラには関係がなくとも）登録された android.hardware.Camera.AutoFocusCallback インスタンスを引き続き呼び出す必要があります。なお、これは前面カメラに適用されます。たとえば、前面カメラはたいていの場合オートフォーカスをサポートしていませんが、それでも前述のように API コールバックを「偽装」しなければなりません。
• [C-0-6] android.hardware.Camera.Parameters クラスで定数として定義された各パラメータ名を認識し、使用しなければなりません。逆に、デバイス実装は 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 インテントをブロードキャストしなければなりません。

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] SDK に記載されているとおり、この共有ストレージに android.permission.WRITE_EXTERNAL_STORAGE 権限を適用しなければなりません。共有ストレージは、それ以外の場合、当該権限を取得するアプリであれば誰でも書き込み可能でなければなりません。

デバイス実装は、次のいずれかを使用して上記の要件を満たしても構いません。

• SD カードスロットなど、ユーザーがアクセス可能なリムーバブル ストレージ。
• Android オープンソース プロジェクト（AOSP）で実装されている内部（非リムーバブル）ストレージの一部。

上記の要件を満たすためにリムーバブル ストレージを使用する場合、デバイス実装は:

• [C-1-1] スロットにストレージ メディアが挿入されていないときにユーザーに警告する、トーストまたはポップアップのユーザー インターフェースを実装しなければなりません。
• [C-1-2] FAT フォーマットしたストレージ メディア（SD カードなど）を含むか、ストレージ メディアを別途購入する必要がある旨を箱または購入時に入手可能な他の資料に表示しなければなりません。

上記の要件を満たすために取り外し不可能なストレージの一部を使用する場合、デバイス実装は:

• 内部アプリ共有ストレージの AOSP 実装を使用すべきです。
• 保存容量をアプリの個人データと共有しても構いません。

複数の共有ストレージパス（SD カードスロットと共有内部ストレージの両方など）が含まれる場合、デバイス実装は:

• [C-3-1] セカンダリ外部ストレージへ書き込みするために、プリインストールされ、WRITE_EXTERNAL_STORAGE 権限のある Android の特権アプリのみを許可しなければなりません（パッケージ固有のディレクトリへの書き込みを行う場合や ACTION_OPEN_DOCUMENT_TREE インテントを発行することで返された URI 内を除く）。

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

テレビとは異なり、デバイスにモバイルとしての性質があることが想定される場合、デバイス実装は:

• [SR] 誤って接続解除するとデータの損失 / 破損が生じるおそれがあるため、Adoptable Storage を長期的に安定した場所に実装することが強く推奨されます。

リムーバブル ストレージ デバイスのポートが、電池収納部やその他の保護カバー内など、長期的に安定した場所にある場合、デバイス実装は:

• [SR] Adoptable Storage を実装することが強く推奨されます。

7.7. 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 をサポートする場合はアドバタイズメントの変更を検出しなければなりません。
• [SR] ポートは Micro-B、Micro-A、Type-C の USB フォーム ファクタを使用すべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
• [SR] ポートは、デバイスのポートが下向きのときディスプレイが正しく描画されるように、（自然な向きに合わせて）デバイスの底部に配置するか、すべてのアプリ（ホーム画面を含む）でソフトウェアの画面回転を可能にすべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
• [SR] USB Battery Charging Specification, Revision 1.2 で規定されているとおり、HS チャープ、トラフィックの際に 1.5 A の電流を流すためのサポートを実装すべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
• [SR] 標準の USB Power Delivery の方法をサポートする充電器またはデバイスとの間に相互運用性の問題が生じるおそれがあるため、デフォルト レベルを超えて Vbus 電圧を変更する、またはシンク / ソースの役割を変更する独自の充電方法をサポートしないことが強く推奨されます。これは「強く推奨」となっていますが、今後の Android バージョンでは、標準的な Type-C 充電器との完全な相互運用性をサポートすることが、すべての Type-C デバイスで必須となる可能性があります。
• [SR] 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 ポート（レセプタクル）に変換するアダプターを同梱してはなりません。
• [SR] 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 使用状況テーブルと音声コマンド使用リクエストで規定されている次の 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）で規定されているとおり、デュアルロール ポート機能を実装しなければなりません。
• [SR] DisplayPort をサポートすることが強く推奨され、USB SuperSpeed データ速度をサポートすべきであり、データと電源の役割を入れ替えるために Power Delivery をサポートすることが強く推奨されます。
• [SR] USB Type-C ケーブルおよびコネクタ仕様リリース 1.2 の付録 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 の、オーディオ レイテンシの要件を満たさなければなりません。
• [SR] セクション 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 の、オーディオ レイテンシの要件を満たさなければなりません。
• [SR] セクション 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 つ以上のアナログ オーディオ ポートが含まれる場合、オーディオ ポートのうち少なくとも 1 つが、4 極 3.5 mm オーディオ ジャックであるべきです。

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 でなければなりません。
• [SR] オーディオ プラグのマイク極と接地極の間で、次に示す等価インピーダンス範囲について、検出とキーコードへのマッピングを行うことが強く推奨されます。
  • 110～180 オーム: KEYCODE_VOICE_ASSIST
• OMTP ピン配列のオーディオ プラグをサポートすべきです。
• マイク付きステレオ ヘッドセットからの録音をサポートすべきです。

4 極 3.5 mm オーディオ ジャックがあり、マイクをサポートし、追加値でマイクを 1 に設定して android.intent.action.HEADSET_PLUG をブロードキャストする場合、デバイス実装は:

• [C-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 におけるスピーカーの平均感度は、40 dB 以上、2 kHz における感度以下でなければなりません。

7.9. バーチャル リアリティ

Android には、高品質なモバイル VR 体験を含む「バーチャル リアリティ」（VR）アプリをビルドするための API と機能があります。このセクションで詳述するように、デバイス実装はこれらの API と動作を適切に実装しなければなりません。

7.9.1. バーチャル リアリティ モード

Android は、VR モード（通知の立体画像レンダリングを処理し、ユーザーが VR アプリを注視している間は単眼式のシステム UI コンポーネントを無効にする機能）をサポートしています。

7.9.2. バーチャル リアリティの高パフォーマンス

android.hardware.vr.high_performance 機能フラグを通じて、長時間のユーザーに対する高性能 VR のサポートを識別する場合、デバイス実装は:

• [C-1-1] 物理コアが少なくとも 2 つなければなりません。
• [C-1-2] android.software.vr.mode feature を宣言しなければなりません。
• [C-1-3] パフォーマンス維持モードをサポートしなければなりません。
• [C-1-4] OpenGL ES 3.2 をサポートしなければなりません。
• [C-1-5] Vulkan ハードウェア レベル 0 をサポートしなければならず、Vulkan ハードウェア レベル 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 拡張機能のリストで拡張機能を公開しなければなりません。
• [C-1-7] GPU とディスプレイは、VR のコンテンツを 60 fps で左右の視界それぞれのコンテキストに合わせて交互にレンダリングする場合に、対象が明らかに分かれて表示されることがないように、共有フロント バッファへのアクセスを同期できなければなりません。
• [C-1-8] GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2、GL_OVR_multiview_multisampled_render_to_texture、GL_EXT_protected_textures、GL_EXT_EGL_image_array、GL_EXT_external_buffer を実装し、利用可能な GL 拡張機能のリストで拡張機能を公開しなければなりません。
• [C-1-9] NDK に記載されているとおり、AHardwareBuffer フラグ AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA のサポートを実装しなければなりません。
• [C-1-10] 複数のレイヤを持つ AHardwareBuffers のサポートを実装しなければなりません。
• [C-1-11] 30 fps-40 Mbps で 3,840 x 2,160 以上の H.264 デコードをサポートしなければなりません（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 をサポートしなければならず、30fps-10Mbps で 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] 埋め込み画面がなければならず、その解像度は少なくとも FullHD（1080p）でなければならず、QuadHD（1440p）以上であることが強く推奨されます。
• [C-1-15] ディスプレイは、VR モード中に少なくとも 60 Hz で更新しなければなりません。
• [C-1-16] （グレーからグレー、白から黒、黒から白への切り替えにかかる時間として測定される）ディスプレイ レイテンシが、6 ミリ秒以下でなければなりません。
• [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-1-20] 上記すべてのダイレクト チャンネル タイプについて、TYPE_HARDWARE_BUFFER ダイレクト チャンネル タイプをサポートしなければなりません。
• [SR] android.hardware.sensor.hifi_sensors 機能をサポートすることが強く推奨され、android.hardware.hifi_sensors のジャイロスコープ、加速度計、磁力計関連の要件を満たさなければなりません。
• フォアグラウンド アプリに専用のコアを提供しても構いません。また、トップ フォアグラウンド アプリ専用の CPU コア数を返すために Process.getExclusiveCores API をサポートしても構いません。専用コアがサポートされている場合、そのコアで他のユーザー空間プロセスを実行できるようにしてはなりませんが（アプリで使用するデバイス ドライバを除く）、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。

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. 省電力モード

Android には、アプリ スタンバイと Doze 省電力モードがあり、バッテリー使用量を最適化できます。[SR] これらのモードから除外されたすべてのアプリは、エンドユーザーに表示されることが強く推奨されます。[SR] トリガー、メンテナンス、ウェイクアップのアルゴリズム、およびこれらの省電力モードのグローバル システム設定の使用は、Android オープンソース プロジェクトから逸脱しないことが強く推奨されます。

省電力モードに加えて、Android デバイス実装は、Advanced Configuration and Power Interface（ACPI）で規定された 4 つのスリープ電力状態のいずれか、またはすべてを実装しても構いません。

ACPI で規定されている S3 電源状態と S4 電源状態を実装する場合、デバイス実装は:

• [C-1-1] デバイスに物理的に装着されているふたを閉じるときのみ、この状態に移行しなければなりません。

8.4. 消費電力の算出

より正確に消費電力を算出しレポートすることで、アプリ デベロッパーに対し、アプリの電力使用パターンを最適化するためのインセンティブとツールの両方を提供します。

デバイス実装は:

• [SR] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供することが強く推奨されます。
• [SR] すべての消費電力値をミリアンペア時（mAh）単位でレポートすることが強く推奨されます。
• [SR] プロセスの UID ごとの CPU 電力消費をレポートすることが強く推奨されます。Android オープンソース プロジェクトは、uid_cputime カーネル モジュール実装を通じて要件を満たしています。
• [SR] この電力使用量を、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] アプリが使用するデバイス ドライバを除き、ユーザー空間プロセスを専用コアで実行できるようにしてはなりませんが、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。

専用コアをサポートしない場合、デバイス実装は:

• [C-3-1] Process.getExclusiveCores() API メソッドを通じて空のリストを返さなければなりません。

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

デバイス実装は:

• [C-0-1] Android デベロッパー向けドキュメントの、API のセキュリティと権限に関するリファレンス ドキュメントで規定されているとおり、Android プラットフォームのセキュリティ モデルに合致するセキュリティ モデルを実装しなければなりません。

• [C-0-2] サードパーティ / 認証局からの追加の許可 / 証明書を必要とせずに、自己署名アプリのインストールをサポートしなければなりません。具体的には、互換デバイスは、以降のサブセクションに記載するセキュリティ メカニズムをサポートしなければなりません。

9.1. 権限

デバイス実装は:

• [C-0-1] Android デベロッパー向けドキュメントで規定されているとおり、Android 権限モデルをサポートしなければなりません。具体的には、SDK ドキュメントで規定されているとおり各権限を適用しなければならず、権限を省略、変更、無視することはできません。

• 新しい権限 ID 文字列が android.\* 名前空間にない場合、権限を追加しても構いません。

• [C-0-2] 権限の protectionLevel が PROTECTION_FLAG_PRIVILEGED である場合、その権限を付与するのは、システム イメージの特権パスにプリロードされたアプリと、各アプリについて明示的に許可リスト登録された権限のサブセット内のアプリのみとしなければなりません。AOSP 実装では、etc/permissions/ パスのファイルから各アプリの許可リスト登録された権限を読み取って使用し、特権パスとして system/priv-app パスを使うことで、この要件を満たしています。

保護レベルが「dangerous」の権限は、実行時の権限です。targetSdkVersion が 22 を超えるアプリは、ランタイムにこうした権限をリクエストします。

デバイス実装は:

• [C-0-3] リクエストされたランタイム権限を付与するかどうかを決定するための専用インターフェースをユーザーに示し、ランタイム権限を管理するためのインターフェースもユーザーに提供しなければなりません。
• [C-0-4] 両方のユーザー インターフェースの実装を 1 つだけ持たなければなりません。
• [C-0-5] 次の場合を除き、プリインストール アプリに実行時の権限を付与してはなりません。
• アプリが使用する前に、ユーザーの同意を得ることができる。
• プリインストール アプリがデフォルト ハンドラとして設定されているインテント パターンに、実行時の権限が関連付けられている。

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

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

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

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

9.2. UID とプロセスの分離

デバイス実装は:

• [C-0-1] 各アプリが一意の Unix 形式の UID として個別のプロセスで動作する、Android アプリ サンドボックス モデルをサポートしなければなりません。
• [C-0-2] セキュリティと権限に関するリファレンスで規定されているとおり、アプリが適切に署名され、構築されていることを条件として、同じ Linux ユーザー ID で複数のアプリを実行することをサポートしなければなりません。

9.3. ファイルシステムの権限

デバイス実装は:

• [C-0-1] セキュリティと権限に関するリファレンスで規定されているとおり、Android ファイル アクセス権限モデルをサポートしなければなりません。

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 は、複数のユーザーをサポートし、ユーザーの完全な分離をサポートします。

• デバイス実装は、プライマリ外部ストレージにリムーバブル メディアを使用する場合、マルチユーザーを有効にしても構いませんが、有効にすべきではありません。

複数のユーザーが含まれる場合、デバイス実装は:

• [C-1-1] マルチユーザーのサポートに関連する次の要件を満たさなければなりません。
• [C-1-2] ユーザーごとに、API のセキュリティと権限に関するリファレンス ドキュメントで規定されているとおり、Android プラットフォームのセキュリティ モデルに合致するセキュリティ モデルを実装しなければなりません。
• [C-1-3] ユーザー インスタンスごとに、個別の分離型共有アプリ ストレージ（/sdcard）ディレクトリがなければなりません。
• [C-1-4] あるユーザーの所有でそのユーザーのために実行されているアプリが、他のユーザーのデータと同じボリュームまたはファイルシステムに保存されていたとしても、他のユーザーが所有するファイルをリストしたり、読み書きしたりできないようにしなければなりません。
• [C-1-5] デバイス実装が外部ストレージ API 用にリムーバブル メディアを使用する場合、マルチユーザーが有効になっているときは、システムにしかアクセスできない非リムーバブル メディアにのみ保存されている鍵を使用して、SD カードの内容を暗号化しなければなりません。これにより、ホスト PC でメディアを読み取れなくなるため、デバイス実装は、ホスト PC から現在のユーザーのデータにアクセスできるようにするため、MTP または同様のシステムに切り替える必要があります。

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

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

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

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

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] カーネル スタック バッファ オーバーフロー保護を実装しなければなりません（例: CONFIG_CC_STACKPROTECTOR_STRONG）。
• [C-0-8] 実行可能コードが読み取り専用、読み取り専用データが実行不可能かつ書き込み不可能、書き込み可能データが実行不可能である場合、厳格なカーネルメモリ保護を実装しなければなりません（例: CONFIG_DEBUG_RODATA または CONFIG_STRICT_KERNEL_RWX）。
• [SR] 初期化中にのみ書き込まれるカーネルデータを、初期化後に読み取り専用としてマークして維持することが強く推奨されます（例: __ro_after_init）。
• [SR] ユーザー空間とカーネル空間の間におけるコピーの静的、動的オブジェクト サイズ境界チェックを実装することが強く推奨されます（例: CONFIG_HARDENED_USERCOPY）。
• [SR] カーネルで実行する際にユーザー空間メモリを実行しないことが強く推奨されます（例: ハードウェア PXN、または CONFIG_CPU_SW_DOMAIN_PAN か CONFIG_ARM64_SW_TTBR0_PAN を介してエミュレート）。
• [SR] 通常の usercopy アクセス API の外部でカーネルのユーザー空間メモリの読み書きを行わないことが強く推奨されます（例: ハードウェア PAN、または CONFIG_CPU_SW_DOMAIN_PAN か CONFIG_ARM64_SW_TTBR0_PAN を介してエミュレート）。
• [SR] カーネルコードとメモリのレイアウトをランダム化し、ランダム化を損なうような公開を避けることが強く推奨されます（例: /chosen/kaslr-seed Device Tree node または EFI_RNG_PROTOCOL を介したブートローダー エントロピーによる CONFIG_RANDOMIZE_BASE）。

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 ルールがすべて存在する状態でコンパイルしなければなりません。
• アップストリームの Android オープンソース プロジェクトの system/sepolicy フォルダで提供されているデフォルトの SELinux ポリシーを保持し、このポリシーへの追加は、独自のデバイス固有の設定についてのみ行うべきです。

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

• [C-2-1] SELinux と同等の強制アクセス制御システムを使用しなければなりません。

9.8. プライバシー

9.8.1. 使用履歴

Android は、ユーザーの選択履歴を保存し、UsageStatsManager で履歴を管理します。

デバイス実装は:

• [C-1-1] そのようなユーザー履歴の妥当な保持期間を維持しなければなりません。
• [SR] AOSP 実装でデフォルトで構成されている 14 日間の保持期間を維持することが強く推奨されます。

9.8.2. 録画

画面に表示されているコンテンツをキャプチャする機能や、デバイスで再生されているオーディオ ストリームを録音する機能がシステムに含まれる場合、デバイス実装は:

• [C-1-1] この機能が有効になっており、アクティブにキャプチャや録音を行っているときは常に、進行中の通知をユーザーに示さなければなりません。

周囲音を録音してユーザーのコンテキストについての有用な情報を推測できる、あらかじめ有効になっているコンポーネントが含まれる場合、デバイス実装は:

• [C-2-1] 明示的なユーザーの同意がある場合を除き、録音された未加工オーディオ、または、元のオーディオに戻せるかほぼ複製されたオーディオに変換できる形式のものを、永続的なデバイス上のストレージに保存したり、デバイスから送信したりしてはなりません。

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.9. データ ストレージの暗号化

セクション 9.11.1 に記載されているとおり、セキュアロック画面をサポートする場合、デバイス実装は:

• [C-1-1] アプリの個人データ（/data partition）のデータ ストレージ暗号化をサポートしなければなりません。アプリの共有ストレージ パーティション（/sdcard partition）のデータ ストレージが永続的で取り外し不可能である場合も、データ ストレージの暗号化をサポートしなければなりません。

セクション 9.11.1 に記載されているとおり、セキュアロック画面をサポートし、50 MiB/秒を超える Advanced Encryption Standard（AES）暗号パフォーマンスでデータ ストレージの暗号化をサポートする場合、デバイス実装は:

• [C-2-1] ユーザーが開封時の初期設定を完了した時点で、データ ストレージの暗号化をデフォルトで有効にしなければなりません。デバイス実装が、デフォルトで暗号化を無効にして以前の Android バージョンでリリースされている場合、そのようなデバイスはシステム ソフトウェア アップデートを通じて要件を満たせないため、除外しても構いません。

• ファイルベースの暗号化（FBE）を実装することで、上述のデータ ストレージ暗号化の要件を満たすべきです。

9.9.1. ダイレクト ブート

デバイス実装は:

• [C-0-1] ストレージの暗号化をサポートしない場合でも、ダイレクト ブートモードの API を実装しなければなりません。

• [C-0-2] デバイス暗号化（DE）ストレージと証明書暗号化（CE）ストレージの場所をユーザーが利用できることをダイレクト ブート対応アプリに通知するために、引き続き ACTION_LOCKED_BOOT_COMPLETED インテントと ACTION_USER_UNLOCKED インテントをブロードキャストしなければなりません。

9.9.2. ファイルベースの暗号化

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

• [C-1-1] ユーザーに認証情報を求めずに起動し、ACTION_LOCKED_BOOT_COMPLETED メッセージがブロードキャストされてから、ダイレクト ブート対応アプリでデバイス暗号化（DE）ストレージにアクセスできるようにしなければなりません。
• [C-1-2] ユーザーが認証情報（パスコード、PIN、パターン、指紋など）を提供してロック解除し、ACTION_USER_UNLOCKED メッセージがブロードキャストされて初めて、認証情報暗号化（CE）ストレージにアクセスできるようにしなければなりません。
• [C-1-3] ユーザー指定の認証情報なしで CE 保護ストレージのロック解除方法を提供してはなりません。
• [C-1-4] 確認付きブートをサポートし、DE 鍵がデバイスのハードウェアのルート オブ トラストに暗号的にバインドされるようにしなければなりません。
• [C-1-5] XTS モードの AES による鍵長 256 ビットでのファイル コンテンツの暗号化をサポートしなければなりません。

• [C-1-6] CBC-CTS モードの AES による鍵長 256 ビットでのファイル名の暗号化をサポートしなければなりません。

• CE と DE のストレージ領域を保護する鍵は:

• [C-1-7] ハードウェア格納型キーストアに、暗号化された状態でバインドされなければなりません。

• [C-1-8] CE 鍵は、ユーザーのロック画面認証情報にバインドされなければなりません。
• [C-1-9] CE 鍵は、ユーザーがロック画面認証情報を指定しなかった場合、デフォルトのパスコードにバインドされなければなりません。

• [C-1-10] 一意かつ明確でなければなりません（つまり、ユーザーの CE 鍵または DE 鍵が他のユーザーの CE 鍵または DE 鍵と一致しない）。

• プリロードされた必須アプリ（アラーム、電話、メッセンジャー）をダイレクト ブートに対応させるべきです。

• ファイル コンテンツとファイル名の暗号化の代替暗号、鍵長、モードをサポートしても構いませんが、必須としてデフォルトでサポートされている暗号、鍵長、モードは使用しなければなりません。

アップストリームの Android オープンソース プロジェクトは、Linux カーネルの ext4 暗号化機能に基づくこの機能の優先実装を提供しています。

9.9.3. フルディスク暗号化

フルディスク暗号化（FDE）をサポートする場合、デバイス実装は:

• [C-1-1] 128 ビット以上の鍵の AES と、ストレージ用に設計されたモード（AES-XTS、AES-CBC-ESSIV など）を使用しなければなりません。
• [C-1-2] デフォルトのパスコードを使用して暗号鍵をラップしなければならず、いかなる場合も暗号化せずに暗号鍵をストレージに書き込んではなりません。
• [C-1-3] ユーザーが明示的にオプトアウトしない限り、暗号鍵がアクティブに使用されている場合を除き、低速ストレッチング アルゴリズム（PBKDF2 や scrypt など）を使用してロック画面認証情報をストレッチし、デフォルトで暗号鍵を AES で暗号化しなければなりません。
• [C-1-4] 上述のデフォルトのパスワード ストレッチング アルゴリズムは、ユーザーがロック画面認証情報を指定していないか、暗号化でパスコードを使用することを無効にしており、かつデバイスがハードウェア格納型キーストアを提供している場合、そのキーストアに暗号的にバインドされなければなりません。
• [C-1-5] ユーザーのパスコードやハードウェアにバインドされた鍵でラップされている場合でも、デバイスから暗号鍵を送信してはなりません。

アップストリームの Android オープンソース プロジェクトは、Linux カーネル機能 dm-crypt に基づいて、この機能の優先実装を提供しています。

9.10. デバイスの完全性

次の要件により、デバイスの完全性の状態に透明性が確保されます。デバイス実装は:

• [C-0-1] システム API メソッド PersistentDataBlockManager.getFlashLockState() を通じて、ブートローダーの状態がシステム イメージの書き込みを許可しているかどうかを正しくレポートしなければなりません。FLASH_LOCK_UNKNOWN 状態は、この新しいシステム API メソッドが存在しなかった以前の 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] ユーザーがブートローダーを明示的にロック解除した場合を除き、デバイスの確認済みパーティションを変更できるようにしてはなりません。
• [SR] デバイスにディスクリート チップが複数ある場合、そうしたチップそれぞれのブートプロセスは、ブート時にすべてのステージを確認することが強く推奨されます。
• [SR] ブートローダーのロック解除時に、改ざん検出可能なストレージを使用することが強く推奨されます。改ざん検出可能なストレージとは、HLOS（ハイレベル オペレーティング システム）内からストレージが改ざんされたかどうかをブートローダーが検出できることを意味します。
• [SR] ブートローダー ロックモードからブートローダー ロック解除モードへの移行を許可する前に、デバイスの使用中にユーザーにプロンプトを表示し、物理的な確認を求めることが強く推奨されます。
• [SR] HLOS（ブート、システム パーティションなど）のロールバック保護を実装し、最小許容 OS バージョンの決定に使用するメタデータを格納するために、改ざん検出可能なストレージを使用することが強く推奨されます。
• 永続的なファームウェアを持つコンポーネント（モデム、カメラなど）のためにロールバック保護を実装すべきであり、最小許容バージョンの決定に使用するメタデータを格納するために、改ざん検出可能なストレージを使用すべきです。

アップストリームの Android オープンソース プロジェクトは、external/avb/ リポジトリでこの機能の優先実装を提供しており、Android を読み込むために使用するブートローダーに統合できます。

機能フラグ android.hardware.ram.normal をレポートする場合、デバイス実装は:

• [C-2-1] デバイスの完全性のために確認付きブートをサポートしなければなりません。

以前のバージョンの Android での確認付きブートをサポートせずにデバイス実装がすでにリリースされている場合、そのようなデバイスはシステム ソフトウェア アップデートでこの機能のサポートを追加できないため、要件が免除されます。

9.11. 鍵と認証情報

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

• [C-0-1] 少なくとも 8,192 個を超える鍵をインポートできるようにしなければなりません。
• [C-0-2] ロック画面認証はレート制限を試行しなければならず、指数バックオフ アルゴリズムがなければなりません。失敗した試行が 150 回を超えた場合、遅延は 1 試行あたり少なくとも 24 時間でなければなりません。
• 生成できる鍵の数を制限すべきではありません。

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

• [C-1-1] 安全なハードウェアでキーストア実装をバックアップしなければなりません。
• [C-1-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、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 機能を宣言していない限り、ハードウェア格納型キーストアを必要とする要件が免除されます。

9.11.1. セキュアロック画面

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

• [C-1-1] 画面の自動ロックが延期される、または信頼エージェントによって画面ロックを解除できる状況について、設定とロック画面のユーザー インターフェースでユーザーに示さなければなりません。AOSP は、「自動ロック設定」メニューと「電源ボタンで即座にロックする設定」メニューに関する説明テキストと、ロック画面に区別しやすいアイコンを表示することで、この要件を満たしています。
• [C-1-2] KEYGUARD_DISABLE_TRUST_AGENTS 定数など、DevicePolicyManager クラスのすべての信頼エージェント API を優先し、完全に実装しなければなりません。
• [C-1-3] TrustAgentService.addEscrowToken() 関数を、メインの個人用デバイスとして使用されるデバイス（ハンドヘルドなど）に完全に実装してはなりませんが、通常共有されるデバイス実装に完全に実装しても構いません。
• [C-1-4] TrustAgentService.addEscrowToken() によって追加されたトークンを、デバイスに保存する前に暗号化しなければなりません。
• [C-1-5] 暗号鍵をデバイスに保存してはなりません。
• [C-1-6] エスクロー トークンでデータ ストレージを復号できるようにする前に、セキュリティへの影響についてユーザーに通知しなければなりません。

ロック画面をロック解除するための認証方法を追加または変更する場合は、そのような認証方法が画面をロックするセキュアな方法として扱われるように、デバイス実装は:

• [C-2-1] キー使用を承認するうえでユーザー認証を要求するに記載されているとおりのユーザー認証方法でなければなりません。
• [C-2-2] ユーザーがセキュアロック画面のロックを解除するときに、サードパーティのデベロッパー アプリで使用するすべての鍵のロックを解除しなければなりません。たとえば、createConfirmDeviceCredentialIntent や setUserAuthenticationRequired などの関連する API を介してサードパーティのデベロッパー アプリのすべての鍵を利用できるようにしなければなりません。

ロック画面のロック解除の際の認証方法を、既知のシークレットに基づいて追加または変更し、安全な画面のロック方法として扱う場合、デバイス実装は:

• [C-3-1] 入力の最短許容長のエントロピーが 10 ビットより大きくなければなりません。
• [C-3-2] 可能性のあるすべての入力の最大エントロピーが 18 ビットより大きくなければなりません。
• [C-3-3] AOSP で実装され提供されている既存の認証方法（PIN、パターン、パスワード）を置き換えてはなりません。
• [C-3-4] Device Policy Controller（DPC）アプリが DevicePolicyManager.setPasswordQuality() メソッドを介して、PASSWORD_QUALITY_SOMETHING より制限的な品質定数でパスワード品質ポリシーを設定した場合は、無効にしなければなりません。

ロック画面のロック解除の際の認証方法を、物理トークンまたは位置情報に基づいて追加または変更し、安全な画面のロック方法として扱う場合、デバイス実装は:

• [C-4-1] 既知のシークレットに基づいて、セキュアロック画面として扱われるための要件を満たす、第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければなりません。
• [C-4-2] Device Policy Controller（DPC）アプリが DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) メソッドまたは DevicePolicyManager.setPasswordQuality() メソッドで、PASSWORD_QUALITY_UNSPECIFIED より制限的な品質定数を指定してポリシーを設定した場合、無効にし、第 1 の認証のみで画面のロックを解除できるようにしなければなりません。
• [C-4-3] 少なくとも 72 時間以内ごとに 1 回、第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。

ロック画面のロック解除の際の認証方法を、生体認証に基づいて追加または変更し、安全な画面のロック方法として扱う場合、デバイス実装は:

• [C-5-1] 既知のシークレットに基づいて、セキュアロック画面として扱われるための要件を満たす、第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければなりません。
• [C-5-2] Device Policy Controller（DPC）アプリが DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) メソッドを呼び出して keguard 機能ポリシーを設定した場合、無効にし、第 1 の認証のみで画面をロック解除できるようにしなければなりません。
• [C-5-3] セクション 7.3.10 に記載されているとおり、指紋認証センサーに要求されるレベルと同程度以上の他人受け入れ率が設定されなければなりません。それ以外の場合は無効にしなければならず、Device Policy Controller（DPC）アプリが PASSWORD_QUALITY_BIOMETRIC_WEAK よりも制限的な品質定数を使用した DevicePolicyManager.setPasswordQuality() メソッドを介してパスワード品質ポリシーを設定した場合に、第 1 の認証のみで画面をロック解除できるようにしなければなりません。
• [SR] なりすましとなりすましの受け入れ率が、セクション 7.3.10 に記載されている指紋認証センサーに必要な率と同等かそれ以上であることが強く推奨されます。

セクション 7.3.10 に記載されているように、スプーフィングの受け入れ率となりすましの受け入れ率が指紋認証センサーに必要な値と同等またはそれ以上ではなく、Device Policy Controller（DPC）アプリが DevicePolicyManager.setPasswordQuality() メソッド経由で PASSWORD_QUALITY_BIOMETRIC_WEAK よりも制限の厳しい品質定数でパスワード品質ポリシーを設定している場合:

• [C-6-1] これらの生体認証方法を無効にし、プライマリ認証でのみ画面をロック解除できるようにしなければなりません。
• [C-6-2] 少なくとも 72 時間以内ごとに 1 回、第 1 の認証（PIN、パターン、パスワードなど）をユーザーに求めなければなりません。

ロック画面をロック解除するための認証方法を追加または変更し、そのような認証方法がキーガードのロック解除に使用されるものの、セキュアロック画面としては扱われない場合、デバイス実装は:

• [C-7-1] KeyguardManager.isKeyguardSecure() メソッドと KeyguardManager.isDeviceSecure() メソッドの両方で false を返さなければなりません。
• [C-7-2] Device Policy Controller（DPC）アプリが DevicePolicyManager.setPasswordQuality() メソッドを介してパスワード品質ポリシーを設定した場合は、PASSWORD_QUALITY_UNSPECIFIED より制限的な品質定数で無効にしなければなりません。
• [C-7-3] DevicePolicyManager.setPasswordExpirationTimeout() によって設定されたパスワード有効期限タイマーをリセットしてはなりません。
• [C-7-4] アプリが KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) を呼び出した場合に、キーストアへのアクセスを認証してはなりません。

9.12. データの削除

デバイス実装はすべて:

• [C-0-1] 「データの初期化」を行うメカニズムをユーザーに提供しなければなりません。
• [C-0-2] ユーザー作成データをすべて削除しなければなりません。つまり、以下を除くすべてのデータです。
  • システム イメージ
  • システム イメージが必要とするすべてのオペレーティング システム ファイル
• [C-0-3] NIST SP800-88 など、関連する業界基準を満たす方法でデータを削除しなければなりません。
• [C-0-4] プライマリ ユーザーの Device Policy Controller アプリによって DevicePolicyManager.wipeData() API が呼び出されたとき、上記「データの初期化」プロセスをトリガーしなければなりません。
• 論理データ消去のみを行う高速データワイプ オプションを提供しても構いません。

9.13. セーフブート モード

Android では、セーフブート モードが提供されています。セーフブート モードは、プリインストールのシステムアプリのみが実行可能な起動モードで、他のサードパーティ アプリでは無効にされています。この「セーフブート モード」と呼ばれるモードでは、有害な可能性があるサードパーティ アプリをアンインストールする機能がユーザーに提供されます。

デバイス実装は:

• [SR] セーフブート モードを実装することが強く推奨されます。

セーフブート モードを実装する場合、デバイス実装は:

• [C-1-1] サードパーティ アプリが Device Policy Controller であり、UserManager.DISALLOW_SAFE_BOOT フラグが true に設定されている場合を除き、デバイスにインストールされているサードパーティ アプリから中断できない方法でセーフブート モードに入るオプションをユーザーに提供しなければなりません。

• [C-1-2] セーフモードでサードパーティ アプリをアンインストールする機能をユーザーに提供しなければなりません。

• 通常のブートとは異なるワークフローを使用してブートメニューからセーフブート モードに入るオプションをユーザーに提供しなければなりません。

9.14. 自動車の車両システムの分離

Android 自動車デバイスは、車両 HAL を使用して CAN バスなどの車両ネットワークでメッセージを送受信することで、重要な車両サブシステムとデータを交換することが想定されます。

データ交換は、Android フレームワーク レイヤの下にセキュリティ機能を実装して、これらのサブシステムの悪意ある操作、または意図しない操作を防止することで保護できます。

10. ソフトウェア互換性テスト

デバイス実装は、このセクションに記載されているすべてのテストに合格しなければなりません。

しかし、完全に包括的なソフトウェア テスト パッケージというものはありません。このため、デバイス実装者は、Android オープンソース プロジェクトから入手できる Android のリファレンス実装と優先実装に対して、可能な限り最小限の変更を行うことが強く推奨されます。これにより、互換性の問題をもたらすバグが導入され、再作業やデバイスのアップデートが必要となるリスクを最小限に抑えることができます。

10.1. 互換性テストスイート

デバイス実装は、デバイスの最終出荷ソフトウェアを使用して、Android オープンソース プロジェクトから入手可能な Android 互換性テストスイート（CTS）に合格しなければなりません。さらに、デバイス実装者は可能な限り Android オープンソース ツリーのリファレンス実装を使用するべきであり、CTS で不明確な点があった場合やリファレンス ソースコードのパーツの再実装を行う場合は、互換性を確保しなければなりません。

CTS は、実際のデバイスで実行するように設計されています。他のソフトウェアと同様に、CTS 自体にもバグが含まれている可能性があります。CTS はこの互換性定義とは別にバージョニングされ、Android 8.1 用に CTS の複数のリビジョンがリリースされる可能性があります。デバイス実装は、デバイス ソフトウェアが完成した時点で利用可能な最新バージョンの CTS に合格しなければなりません。

10.2. CTS 検証ツール

デバイス実装は、CTS 検証ツールで該当するすべてのケースを正しく実行しなければなりません。CTS 検証ツールは互換性テストスイートに含まれており、カメラやセンサーの正常な機能など、自動システムではテストできない機能をテストするために、人間のオペレーターが実行するためのものです。

CTS 検証ツールには、オプションのハードウェアを含め、さまざまな種類のハードウェア用のテストがあります。デバイス実装は、搭載しているハードウェア用のすべてのテストに合格しなければなりません。たとえば、デバイスに加速度計が搭載されている場合は、CTS 検証ツールで加速度計のテストケースが正しく実行されなければなりません。この互換性定義ドキュメントで任意とされている機能のテストケースは、スキップまたは省略しても構いません。

前述のとおり、すべてのデバイスとすべてのビルドで、CTS 検証ツールが正しく実行されなければなりません。ただし、ビルドの多くはよく似ているため、デバイス実装者は、わずかな違いしかないビルドで CTS 検証ツールを明示的に実行することは求められていません。具体的には、CTS 検証ツールに合格した実装との違いが、含まれるロケール、ブランディングなどのセットのみであるデバイス実装は、CTS 検証ツールのテストを省略しても構いません。

11. アップデート可能なソフトウェア

デバイス実装は、システム ソフトウェア全体を置き換えるメカニズムを含まなければなりません。このメカニズムは、「ライブ」アップグレードを実施する必要はありません。つまり、デバイスの再起動が必要となっても構いません。

デバイスにプリインストールされているソフトウェア全体を置き換えることができるのであれば、どの方法でも使用できます。たとえば、次のどの方法も、この要件を満たします。

• 再起動によるオフライン アップデートを伴う「無線（OTA）」ダウンロード。
• ホスト PC から USB 経由での「テザー」アップデート。
• 再起動による「オフライン」アップデートとリムーバブル ストレージ上のファイルからのアップデート。

ただし、802.11 や Bluetooth PAN（パーソナル エリア ネットワーク）プロファイルなど、定額制データ接続のサポートが含まれる場合、デバイス実装は、再起動によるオフライン アップデートを使用して OTA ダウンロードをサポートしなければなりません。

使用するアップデート メカニズムは、ユーザーデータをワイプせずにアップデートをサポートしなければなりません。つまりアップデート メカニズムは、アプリの個人データとアプリの共有データを保持しなければなりません。なお、アップストリームの Android ソフトウェアには、この要件を満たすアップデート メカニズムが含まれています。

Android 6.0 以降を搭載してリリースされるデバイス実装の場合、アップデート メカニズムは、システム イメージが OTA の後に想定される結果とバイナリ同一であることの検証をサポートすべきです。Android 5.1 から追加された、アップストリームの Android オープンソース プロジェクトのブロックベース OTA 実装は、この要件を満たしています。

また、デバイス実装は A/B システム アップデートをサポートすべきです。AOSP は、ブート コントロール HAL を使用してこの機能を実装しています。

リリース後に、ただし妥当な製品寿命の期間内にデバイス実装でエラーが見つかり、Android 互換性チームとの協議において、サードパーティ アプリの互換性に影響を与えると判断された場合、デバイス実装者は前述のメカニズムによって適用できる、利用可能なソフトウェア アップデートを介してエラーを修正しなければなりません。

Android には、デバイス所有者アプリ（存在する場合）でシステム アップデートのインストールを制御できる機能があります。これを容易にするために、android.software.device_admin をレポートするデバイスのシステム アップデート サブシステムは、SystemUpdatePolicy クラスに記載されている動作を実装しなければなりません。

12. ドキュメントの変更履歴

このリリースにおける互換性定義に対する変更の概要は次のとおりです。

• ドキュメントの変更履歴

個々のセクションに対する変更の概要は次のとおりです。

1. はじめに
2. デバイスタイプ
3. ソフトウェア
4. アプリのパッケージング
5. マルチメディア
6. デベロッパー ツール、開発者向けオプション
7. ハードウェアの互換性
8. パフォーマンスと電力
9. セキュリティ モデル
10. ソフトウェア互換性テスト
11. アップデート可能なソフトウェア
12. ドキュメントの変更履歴
13. お問い合わせ

12.1. 変更履歴確認のヒント

変更点は次のとおりマークされます。

• CDD
  互換性要件に対する重大な変更。

• Docs
  外観またはビルドに関連する変更。

変更履歴の URL に、URL パラメータ pretty=full と no-merges を追加することをおすすめします。

13. お問い合わせ

android-compatibility フォーラムに参加すると、解説を求めることができます。または、このドキュメントがカバーしていないと思われる問題を提起することもできます。