Android 6.0 互換性定義

1. はじめに

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

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

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

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

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

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

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

2. デバイスタイプ

Android オープンソースプロジェクトはさまざまなデバイスタイプとフォームファクタの実装で使用されてきましたが、アーキテクチャと互換性要件については、その多くの要素がハンドヘルドデバイス向けに最適化されていました。Android 5.0 以降、Android オープンソースプロジェクトは、このセクションに記載されているような幅広いデバイスタイプに対応することを目指しています。

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

タッチスクリーンがデバイスに埋め込まれていなければなりません。
バッテリーなど、持ち運びを可能にする電源がなければなりません。

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

埋め込み画面があるか、VGA、HDMI、ディスプレイ用ワイヤレスポートなどの動画出力ポートを含まなければなりません。
機能 android.software.leanback と android.hardware.type.television [参考資料、3] を宣言しなければなりません。

Android スマートウォッチデバイスとは、身体（通常は手首）に装着することを目的とした Android デバイス実装を指します。Android スマートウォッチデバイスには、以下の要件が適用されます。

画面の対角長が物理的に 1.1 から 2.5 インチでなければなりません。
機能 android.hardware.type.watch を宣言しなければなりません。
uiMode = UI_MODE_TYPE_WATCH [参考資料、4] をサポートしなければなりません。

Android Automotive 実装とは、システムやインフォテインメント機能の一部または全部について、オペレーティングシステムとして Android を搭載した車両ヘッドユニットを指します。Android Automotive の実装には、以下の要件が適用されます。

機能 android.hardware.type.automotive を宣言しなければなりません。
uiMode = UI_MODE_TYPE_CAR [参考資料、5] をサポートしなければなりません。

上記いずれのデバイスタイプにも当てはまらない Android デバイス実装はすべて、Android 6.0 互換となるにはこのドキュメントに記載されている要件をすべて満たさなければなりません。ただし、上記の特定の Android デバイスタイプにのみ適用できることが明記されている要件は除きます。

2.1 デバイス構成

ここでは、デバイスタイプごとのハードウェア構成の主な違いの概要を示します（空のセルは「しても構わない」を表します）。この表ですべての構成を網羅しているわけではありません。詳しくは該当するハードウェアのセクションをご覧ください。

カテゴリ	機能	セクション	ハンドヘルド	テレビ	スマートウォッチ	自動車	その他
入力	D-pad	7.2.2. タップ以外のナビゲーション		しなければならない
	タッチスクリーン	7.2.4. タッチスクリーン入力	しなければならない		しなければならない		すべきである
	マイク	7.8.1. マイク	しなければならない	すべきである	しなければならない	しなければならない	すべきである
センサー	加速度計	7.3.1 加速度計	すべきである		すべきである		すべきである
センサー	GPS	7.3.3. GPS	すべきである			すべきである
接続	Wi-Fi	7.4.2. IEEE 802.11	すべきである	しなければならない		すべきである	すべきである
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	すべきである	すべきである			すべきである
	Bluetooth	7.4.3. Bluetooth	すべきである	しなければならない	必須	しなければならない	すべきである
	Bluetooth Low Energy	7.4.3. Bluetooth	すべきである	しなければならない	すべきである	すべきである	すべきである
	USB ペリフェラル / ホストモード	7.7. USB	すべきである			すべきである	すべきである
出力	スピーカー、オーディオ出力ポート	7.8.2. オーディオ出力	しなければならない	必須		必須	しなければならない

3. ソフトウェア

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

Dalvik バイトコードによるマネージド実行環境は、Android アプリを実行する際の主要手段です。Android アプリケーションプログラミングインターフェース（API）は、マネージドランタイム環境で動作するアプリに公開される Andoid プラットフォームインターフェースのセットです。デバイス実装は、Android SDK [参考資料、6] で公開されているドキュメント化された API、またはアップストリームの Android ソースコードにおいて @SystemApi マーカーで装飾されている API について、すべてのドキュメント化された動作も含めて、完全な実装を提供しなければなりません。

デバイス実装は、この互換性定義で特に許可される場合を除き、マネージド API の省略、API インターフェースまたは署名の変更、ドキュメント化された動作からの逸脱、NoOps の組み込みを行ってはなりません。

この互換性定義では、Android に API が含まれている一部のタイプのハードウェアについては、デバイス実装で省略することを許可しています。そのような場合であっても、API が存在し、かつ妥当な動作をしなければなりません。このシナリオに固有の要件については、セクション 7 をご覧ください。

3.2. ソフト API の互換性

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

3.2.1. 権限

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

3.2.2. ビルドパラメータ

Android API には、現在のデバイスを記述するための android.os.Build クラス [参考資料、8] の定数がいくつか含まれています。デバイス実装間で一貫した意味のある値を提供するために、デバイス実装が従わなければならない、これらの値の形式に関する追加の制限を下表に示します。

パラメータ	詳細
VERSION.RELEASE	現在実行している Android システムのバージョン（人が読める形式）。このフィールドには、[参考資料、9] で規定されている文字列値のいずれかを指定しなければなりません。
VERSION.SDK	現在実行している Android システムのバージョン（サードパーティアプリコードからアクセスできる形式）。Android 6.0 の場合、このフィールドには整数値 23 を指定しなければなりません。
VERSION.SDK_INT	現在実行している Android システムのバージョン（サードパーティアプリコードからアクセスできる形式）。Android 6.0 の場合、このフィールドには整数値 23 を指定しなければなりません。
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:6.0/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 のセキュリティに関する公開情報を通じて配布されたすべてのセキュリティパッチがビルドに含まれていることを示さなければなりません。Android のセキュリティに関する公開情報の Android セキュリティパッチレベル文字列のいずれかと一致するように、[YYYY-MM-DD] の形式（「2015-11-01」など）にしなければなりません。
BASE_OS	ビルドの FINGERPRINT パラメータを表す値。Android のセキュリティに関する公開情報で提供されているパッチを除き、このビルドと同一です。正しい値を報告しなければならず、そのようなビルドが存在しない場合は空の文字列（""）を報告しなければなりません。

3.2.3. インテントの互換性

デバイス実装では、以下の各セクションに記載されているように、Android の疎結合インテントシステムを尊重しなければなりません。「尊重する」とは、デバイス実装者が、一致するインテントフィルタを指定し、指定されたインテントパターンごとに正しい動作をバインドして実装する Android アクティビティまたはサービスを提供しなければならないことを意味します。

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

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

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

デバイス実装は、必要に応じてコア Android アプリを含むべきですが、これらのコア Android アプリのすべての「パブリック」Activity または Service コンポーネントによって定義される、同じインテントパターンを実装するコンポーネントを含まなければなりません。なお、Activity または Service コンポーネントは、android:exported 属性が存在しないか、値が true の場合、「パブリック」とみなされます。

3.2.3.2. インテントの解決

Android は拡張可能なプラットフォームであるため、デバイス実装は、セクション 3.2.3.1 で参照されている各インテントパターンをサードパーティアプリがオーバーライドできるようにしなければなりません。アップストリームの Android オープンソース実装では、デフォルトでこれが可能です。デバイス実装者は、システムアプリがこれらのインテントパターンを使用することに対し特別な権限を付与したり、サードパーティアプリがこれらのパターンにバインドすることや、それらの制御を引き受けることを妨げたりしてはなりません。これによって禁止される行為には、たとえば、同じインテントパターンを処理する複数のアプリの中からユーザーが特定のアプリを選択することを許可する「選択的」ユーザーインターフェースを無効にすることが含まれますが、これに限定されません。

デバイス実装では、ユーザーがインテントのデフォルトアクティビティを変更できるユーザーインターフェースを搭載しなければなりません。

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

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

アップストリームの Android オープンソースプロジェクトのパッケージマネージャーで実装される、デジタルアセットリンク仕様 [参考資料、141] で規定されている検証手順を実施することで、インテントフィルタの検証を試行しなければなりません。
アプリのインストール中にインテントフィルタの検証を試行し、検証に合格したすべての URI インテントフィルタを、その URI のデフォルトアプリハンドラとして設定しなければなりません。
URI フィルタ候補の一部が検証に合格したがその他の候補が不合格になった場合は、合格した URI インテントフィルタを URI のデフォルトアプリハンドラとして設定しても構いません。デバイス実装がこれを行う場合は、URI ごとの適切なパターンオーバーライドを設定メニューでユーザーに提供しなければなりません。
次のように、アプリごとのアプリリンクコントロールを設定メニューでユーザーに提供しなければなりません。
- ユーザーがアプリのデフォルトのアプリリンク動作（常に開く、常に確認する、常に開かない）を全体的にオーバーライドできなければならず、この動作がすべての URI インテントフィルタ候補に等しく適用されなければなりません。
- ユーザーに、URI インテントフィルタ候補のリストが表示されなければなりません。
- デバイス実装は、インテントフィルタごとに、検証に合格した特定の URI インテントフィルタ候補をオーバーライドする機能をユーザーに提供しても構いません。
- デバイス実装による検証に一部の URI インテントフィルタ候補が合格し、その他の候補が不合格になる可能性がある場合、デバイス実装は、特定の URI インテントフィルタ候補を表示およびオーバーライドする機能をユーザーに提供しなければなりません。

3.2.3.3. インテントの名前空間

デバイス実装は、android.* 名前空間または com.android.* 名前空間に、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャストインテントパターンを尊重する Android コンポーネントを含んではなりません。デバイス実装者は、別の組織に属するパッケージスペースに、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャストインテントパターンを尊重する Android コンポーネントを含めてはなりません。デバイス実装者は、セクション 3.2.3.1 に記載されているコアアプリで使用されるインテントパターンのいずれについても変更または拡張してはなりません。デバイス実装は、組織に明確に関連付けられた名前空間を使用するインテントパターンを含んでも構いません。この制約は、セクション 3.6 の Java 言語クラスに指定された制約と同様のものです。

3.2.3.4. ブロードキャストインテント

サードパーティアプリは、特定のインテントをブロードキャストしてハードウェアまたはソフトウェア環境の変更を通知する際、プラットフォームに依存します。Android 互換デバイスは、該当するシステムイベントに応じてパブリックブロードキャストインテントをブロードキャストしなければなりません。ブロードキャストインテントについては、SDK ドキュメントに記載されています。

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

Android には、ホーム画面や SMS などのデフォルトアプリをユーザーが簡単に選択できるようにする設定があります。そのような状態が合理的な場合、デバイス実装は、同様の設定メニューを提供しなければならず、SDK ドキュメントに記載されているインテントフィルタパターンや API メソッドと下記のように互換性がなければなりません。

デバイス実装は:

デバイス実装が android.software.home_screen を報告する場合、android.settings.HOME_SETTINGS インテントを尊重して、ホーム画面用のデフォルトのアプリ設定メニューを表示しなければなりません [参考資料、10]。
デバイス実装が android.hardware.telephony を報告する場合、android.provider.Telephony.ACTION_CHANGE_DEFAULT インテントを呼び出して、デフォルトの SMS アプリを変更するダイアログを表示する設定メニューを提供しなければなりません [参考資料、11]。
デバイス実装が android.hardware.nfc.hce を報告する場合、android.settings.NFC_PAYMENT_SETTINGS インテントを尊重して、タップ＆ペイ用のデフォルトのアプリ設定メニューを表示しなければなりません [参考資料、10]。

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

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

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

デバイス実装が Android ABI をサポートする場合は、以下の要件が適用されます。

標準の Java Native Interface（JNI）セマンティクスを使用して、ネイティブコードを呼び出すためにマネージド環境で動作するコードのサポートを含まなければなりません。
以下のリストにある各必須ライブラリと、ソース互換（すなわちヘッダー互換）かつバイナリ互換（ABI 向け）でなければなりません。
64 ビット ABI がサポートされている場合は、同等の 32 ビット ABI をサポートしなければなりません。
android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS、および android.os.Build.SUPPORTED_64_BIT_ABIS パラメータ（優先度の高い順に並べられた ABI のカンマ区切りリスト）を介して、デバイスがサポートするネイティブアプリケーションバイナリインターフェース（ABI）を正確に報告しなければなりません。
上記のパラメータを介して、最新バージョンの Android NDK ABI 管理ドキュメント [参考資料、12] に文書化され、記述されている ABI のみを報告しなければならず、高度な SIMD（NEON）[参考資料、13] 拡張機能をサポートしていなければなりません。
アップストリームの Android オープンソースプロジェクトで入手可能なソースコードとヘッダーファイルを使用してビルドするべきです。

ネイティブコードを含むアプリで、次のネイティブコード API が利用可能でなければなりません。

libc（C ライブラリ）
libm（math ライブラリ）
C++ の最小限のサポート
JNI インターフェース
liblog（Android ロギング）
libz（Zlib 圧縮）
libdl（ダイナミックリンカー）
libGLESv1_CM.so（OpenGL ES 1.x）
libGLESv2.so（OpenGL ES 2.0）
libGLESv3.so（OpenGL ES 3.x）
libEGL.so（ネイティブ OpenGL サーフェス管理）
libjnigraphics.so
libOpenSLES.so（OpenSL ES 1.0.1 オーディオサポート）
libOpenMAXAL.so（OpenMAX AL 1.0.1 サポート）
libandroid.so（ネイティブ Android アクティビティサポート）
libmediandk.so（ネイティブメディア API サポート）
以下で説明する OpenGL のサポート

Android NDK の今後のリリースで、追加の ABI のサポートが導入される可能性があります。デバイス実装は、既存の事前定義済み ABI と互換性がない場合、いかなる ABI のサポートも報告してはなりません。

なお、デバイス実装は libGLESv3.so を含まなければならず、libGLESv2.so への symlink（シンボリックリンク）を持たなければなりません。さらに、NDK リリース android-21 で規定されているように、OpenGL ES 3.1 と Android 拡張機能パック [参考資料、14] の関数シンボルをすべてエクスポートしなければなりません。すべてのシンボルが存在しなければなりませんが、完全に実装する必要があるのは、デバイスが実際にサポートする OpenGL ES バージョンと拡張機能に対応する関数のみです。

デバイス実装で、libvulkan.so という名前のネイティブライブラリが含まれる場合、関数シンボルをエクスポートしなければなりません。また、Khronos Group で規定され、Khronos 適合性テストに合格している拡張機能 Vulkan 1.0 API、VK_KHR_surface、VK_KHR_swapchain、VK_KHR_android_surface 実装を提供しなければなりません。

ネイティブコードの互換性は難しい問題です。したがって、デバイス実装者は、アップストリームの Android オープンソースプロジェクトの上記のライブラリの実装を使用することが強く推奨されます。

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

ARMv8 アーキテクチャでは複数の CPU オペレーションが非推奨になっており、その中には既存のネイティブコードで使用されているものもあります。64 ビット ARM デバイスの場合、以下の非推奨のオペレーションが、ネイティブ CPU サポートまたはソフトウェアエミュレーションのいずれかを通じて、32 ビットネイティブ ARM コードで引き続き使用可能でなければなりません。

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

以前のバージョンの Android NDK では、/proc/cpuinfo を使用して 32 ビット ARM ネイティブコードから CPU 機能を検出していました。この NDK を使用してビルドされたアプリとの互換性を維持するため、/proc/cpuinfo が 32 ビット ARM アプリによって読み取られる場合、デバイスは /proc/cpuinfo に以下の行を含まなければなりません。

「Features: 」の後に、デバイスがサポートするオプションの ARMv7 CPU 機能のリストが続く行。
「CPU architecture: 」の後に、デバイスのサポート対象 ARM アーキテクチャの最大バージョンを示す整数（例: ARMv8 デバイスの場合は「8」）が続く行。

上記の要件は、/proc/cpuinfo が 32 ビット ARM アプリによって読み取られる場合にのみ適用されます。/proc/cpuinfo が 64 ビット ARM アプリまたは非 ARM アプリによって読み取られる場合、デバイスは /proc/cpuinfo を変更すべきではありません。

3.4. ウェブの互換性

3.4.1. WebView の互換性

Android スマートウォッチデバイスは android.webkit.Webview API の完全な実装を提供しても構いませんが、他のすべてのデバイス実装はそれを提供しなければなりません。

プラットフォーム機能 android.software.webview は、android.webkit.WebView API の完全な実装を提供するすべてのデバイスで報告されなければならず、この API の完全な実装がないデバイスで報告されてはなりません。Android オープンソース実装は、Chromium プロジェクトのコードを使用して android.webkit.WebView [参考資料、15] を実装しています。ウェブレンダリングシステムの包括的なテストスイートを開発することは現実的でないため、デバイス実装者は、WebView 実装で Chromium の特定のアップストリームビルドを使用しなければなりません。詳細は以下のとおりです。

デバイスの android.webkit.WebView の実装は、Android 6.0 用のアップストリームの Android オープンソースプロジェクトの Chromium ビルドをベースとしていなければなりません。このビルドには、WebView の特定の機能セットとセキュリティ修正 [参考資料、16] が含まれています。
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 仕様 [参考資料、17] を遵守するべきです。

3.4.2. ブラウザの互換性

Android テレビ、Android スマートウォッチ、Android Automotive の実装はブラウザアプリを省略しても構いませんが、セクション 3.2.3.1 に記載されているようにパブリックインテントパターンをサポートしなければなりません。他のすべてのタイプのデバイス実装は、ユーザーの一般的なウェブブラウジング用のスタンドアロンブラウザアプリを含まなければなりません。

スタンドアロンブラウザは、WebKit 以外のブラウザテクノロジーをベースにするものであっても構いません。ただし、代替ブラウザアプリを使用する場合でも、サードパーティアプリに提供する android.webkit.WebView コンポーネントは、セクション 3.4.1 に記載されているように、WebKit をベースにするものでなければなりません。

実装は、スタンドアロンブラウザアプリでカスタムのユーザーエージェント文字列を送信しても構いません。

スタンドアロンブラウザアプリは（アップストリームの WebKit ブラウザアプリとサードパーティの代替アプリのどちらをベースとしているかにかかわらず）、可能な限り HTML5 [参考資料、17] をサポートするべきです。デバイス実装は、少なくとも HTML5 に関連する以下の API をそれぞれサポートしなければなりません。

アプリキャッシュ / オフラインオペレーション [参考資料、18]
<video> タグ [参考資料、19]
位置情報 [参考資料、20]

さらに、デバイス実装は、HTML5/W3C の webstorage API [参考資料、21] をサポートしなければならず、HTML5/W3C の IndexedDB API [参考資料、22] をサポートするべきです。なお、ウェブ開発標準化団体が webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは、IndexedDB が必須コンポーネントになると見込まれます。

3.5. API 動作の互換性

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

デバイスは、標準的なインテントの動作またはセマンティクスを変更してはなりません。
デバイスは、特定の種類のシステムコンポーネント（Service、Activity、ContentProvider など）のライフサイクルまたはライフサイクルセマンティクスを変更してはなりません。
デバイスは、標準的な権限のセマンティクスを変更してはなりません。

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

3.6. API 名前空間

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

java.*
javax.*
sun.*
android.*
com.android.*

次のような変更は禁止されています。

デバイス実装は、メソッドシグネチャかクラスシグネチャを変更することで、またはクラスかクラスフィールドを削除することで、Android プラットフォームで一般公開されている API を変更してはなりません。
デバイス実装者は API の基盤となる実装を変更しても構いませんが、そのような変更は、一般公開されている API の所定の動作と Java 言語シグネチャに影響を及ぼしてはなりません。
デバイス実装者は、一般公開されている要素（クラスまたはインターフェース、既存のクラスまたはインターフェースのフィールドまたはメソッドなど）を上記の API に追加してはなりません。

「一般公開されている要素」とは、アップストリームの Android ソースコードで使用されているような「@hide」マーカーで装飾されていない構成要素です。つまり、デバイス実装者は、上記の名前空間で新しい API を公開したり、既存の API を変更したりしてはなりません。デバイス実装者は内部のみの変更を行っても構いませんが、そのような変更をアドバタイズしたり、別の方法でデベロッパーに公開したりしてはなりません。

デバイス実装者はカスタム API を追加しても構いませんが、そのような API は別の組織が所有または参照している名前空間内に存在してはなりません。たとえば、デバイス実装者は com.google.* またはこれと類似した名前空間に API を追加してはなりません。これを行えるのは Google のみです。同様に、Google は他社の名前空間に API を追加してはなりません。さらに、デバイス実装が標準の Android 名前空間の外部にあるカスタム API を含んでいる場合、そのような API は Android 共有ライブラリにパッケージ化しなければなりません。これは、そのような API を（lt;uses-librarygt; メカニズムを通じて）明示的に使用するアプリのみが、それらの API によるメモリ使用量増加の影響を受けるようにするためです。

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

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

3.7. ランタイムの互換性

デバイス実装は、完全な Dalvik Executable（DEX）形式、Dalvik バイトコード仕様、セマンティクス [参考資料、23] をサポートしなければなりません。デバイス実装は ART を使用するべきです。ART は Dalvik 実行ファイル形式のリファレンスアップストリーム実装であり、リファレンス実装のパッケージ管理システムでもあります。

デバイス実装は、アップストリームの Android プラットフォームに合わせて、以下の表に示すようにメモリが割り当てられるように Dalvik ランタイムを構成しなければなりません（画面サイズと画面密度の定義については、セクション 7.1.1 をご覧ください）。

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

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

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

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

Android はランチャーアプリ（ホーム画面）を含んでおり、デバイスランチャー（ホーム画面）を置き換えるサードパーティアプリをサポートしています。サードパーティアプリにデバイスのホーム画面の置き換えを許可するデバイス実装は、プラットフォーム機能 android.software.home_screen を宣言しなければなりません。

3.8.2. ウィジェット

ウィジェットはすべての Android デバイス実装で任意ですが、Android ハンドヘルドデバイスではサポートするべきです。

Android では、アプリがエンドユーザーに「AppWidget」[参考資料、24] を公開できるようにするコンポーネントタイプとそれに対応する API およびライフサイクルを定義しています。この機能は、ハンドヘルドデバイス実装でサポートすることが強く推奨されます。ホーム画面へのウィジェットの埋め込みをサポートするデバイス実装は、以下の要件を満たすとともに、プラットフォーム機能 android.software.app_widgets のサポートを宣言しなければなりません。

デバイスのランチャーは、AppWidget の組み込みのサポートを含まなければならず、ランチャー内で直接 AppWidget を追加、構成、表示、削除するユーザーインターフェースアフォーダンスを公開しなければなりません。
デバイス実装は、標準グリッドサイズで 4 x 4 のウィジェットをレンダリングできなければなりません。詳細については、Android SDK ドキュメントのアプリウィジェットの設計ガイドライン [参考資料、24] をご覧ください。
ロック画面のサポートを含むデバイス実装は、ロック画面でアプリウィジェットをサポートしても構いません。

3.8.3. 通知

Android には、デベロッパーがデバイスのハードウェア機能とソフトウェア機能を使用して重要なイベントをユーザーに通知 [参考資料、25] するための API が含まれています。

一部の API は、アプリがハードウェア（具体的にはサウンド、バイブレーション、ライト）を使用して通知を行ったりユーザーの注意を引いたりすることを可能にします。デバイス実装は、SDK ドキュメントに記載されているように、デバイス実装ハードウェアで可能な範囲で、ハードウェア機能を使用する通知をサポートしなければなりません。たとえば、デバイス実装がバイブレーターを含む場合、バイブレーション API を正しく実装しなければなりません。デバイス実装にハードウェアがない場合は、対応する API を NoOps として実装しなければなりません。この動作の詳細については、セクション 7 をご覧ください。

さらに、実装は、API またはステータスバー / システムバーのアイコンスタイルガイド [参考資料、27] で提供されるすべてのリソース（アイコンやアニメーションファイルなど）[参考資料、26] を正しくレンダリングしなければなりませんが、Android テレビデバイスの場合は通知を表示しない可能性もあります。デバイス実装者は、通知について、リファレンス Android オープンソース実装で提供されているものと異なる代替ユーザーエクスペリエンスを提供しても構いません。ただし、そのような代替通知システムは、上記のように既存の通知リソースをサポートしなければなりません。

Android は、次のような各種の通知をサポートしています。

リッチ通知。進行中の通知を確認するためのインタラクティブなビュー。
ヘッドアップ通知。現在のアプリから移動することなく、操作または閉じることができるインタラクティブなビュー。
ロック画面通知。ロック画面に表示される通知。表示するかどうかをきめ細かく制御できます。

Android デバイス実装は、そのような通知が表示される際に、リッチ通知とヘッドアップ通知を適切に実行しなければならず、Android API ドキュメント [参考資料、28] に記載されているようにタイトル / 名前、アイコン、テキストを含まなければなりません。

Android には、通知リスナーサービス API が含まれています。これらの API は、通知がポストされたか更新されたときにアプリがすべての通知のコピーを受け取ることを可能にします（ユーザーが明示的に有効にした場合）。デバイス実装は、ユーザーが有効にしたインストール済みのすべてのリスナーサービス（Notification オブジェクトにアタッチされているすべてのメタデータを含む）に対して通知全体を正確かつ迅速に送信しなければなりません。

3.8.4. 検索

Android には、デベロッパーがアプリに検索を組み込み、アプリのデータをグローバルシステム検索に公開するための API [参考資料、29] が含まれています。一般的に、この機能はシステム全体にわたる単一のユーザーインターフェース（ユーザーがクエリを入力でき、入力時には検索候補が示され、検索結果が表示される）で構成されます。Android API を使用すると、デベロッパーは、このインターフェースを再利用して独自のアプリ内で検索を提供でき、共通のグローバル検索ユーザーインターフェースに結果を供給できます。

Android デバイス実装は、ユーザー入力に応じてリアルタイムで検索候補を表示できるような、システム全体にわたる単一の共有検索ユーザーインターフェースであるグローバル検索を含むべきです。デバイス実装は、デベロッパーがこのユーザーインターフェースを再利用して自身のアプリ内で検索を提供できるようにする API を実装すべきです。グローバル検索インターフェースを実装するデバイス実装は、サードパーティアプリがグローバル検索モードで実行されているときに検索候補を検索ボックスに追加できるようにする API を実装しなければなりません。この機能を利用するサードパーティアプリがインストールされていない場合は、デフォルトの動作として、ウェブ検索エンジンの検索結果と検索候補を表示すべきです。

Android デバイス実装は、アシストアクション [参考資料、30] を処理するために、デバイスにアシスタントを実装すべきです。

Android には、現在のコンテキストの情報をデバイスのアシスタント [参考資料、31] とどの程度共有するかをアプリが選択できるようにする Assist API も用意されています。アシストアクションをサポートするデバイス実装は、コンテキストが共有されているときにそれをエンドユーザーに明確に示すため、画面の端付近に白色のライトを表示しなければなりません。この表示は、エンドユーザーから明瞭に見えるように、Android オープンソースプロジェクト実装の表示時間と明るさの要件を満たすか、超えていなければなりません。

3.8.5. トースト

アプリは、「トースト」API を使用して、短時間で消える短い非モーダル文字列をエンドユーザーに表示できます [参考資料、32]。デバイス実装は、アプリからエンドユーザーへのトーストを、なんらかの目立つ方法で表示しなければなりません。

3.8.6. テーマ

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

Android には、アプリデベロッパーが Android SDK で定義されている Holo テーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「Holo」テーマファミリーがあります [参考資料、33]。デバイス実装は、アプリに対して公開されている Holo テーマ属性を一切変更してはなりません [参考資料、34]。

Android には、アプリデベロッパーが幅広い Android デバイスタイプでデザインテーマの外観にマッチさせる場合に使用する定義済みスタイルのセットとして、「Material」テーマファミリーがあります。デバイス実装は「Material」テーマファミリーをサポートしなければならず、アプリに公開される Material テーマ属性またはそのアセットのいずれについても変更してはなりません [参考資料、35]。

Android には、アプリデベロッパーがデバイス実装者によって定義されたデバイステーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「Device Default」テーマファミリーも用意されています。デバイス実装は、アプリに対して公開されている Device Default テーマの属性を変更しても構いません [参考資料、34]。

Android は、半透明のシステムバーを使用する各種のテーマをサポートしています。これにより、アプリデベロッパーは、ステータスバーとナビゲーションバーの背後のエリアをアプリのコンテンツで埋めることができます。この構成でデベロッパーエクスペリエンスに一貫性を持たせるには、さまざまなデバイス実装でステータスバーのアイコンスタイルを維持することが重要です。したがって、Android デバイス実装は、システムステータスアイコン（信号強度やバッテリー残量など）とシステムが発行する通知の色に白を使用しなければなりません。ただし、アイコンが問題のあるステータスを示すか、アプリが SYSTEM_UI_FLAG_LIGHT_STATUS_BAR フラグを使用してライトステータスバーをリクエストする場合は除きます。アプリがライトステータスバーをリクエストする場合、Android デバイス実装はシステムステータスアイコンの色を黒に変更しなければなりません [参考資料、34]。

3.8.7. ライブ壁紙

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

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

上記のようにライブ壁紙を確実に実行できるデバイス実装はライブ壁紙を実装するべきであり、実装する場合はプラットフォーム機能フラグ android.software.live_wallpaper を報告しなければなりません。

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

履歴機能のナビゲーションキーは任意であるため、概要画面の実装要件は、Android テレビデバイスと Android スマートウォッチデバイスでは任意です。

アップストリームの Android ソースコードには、概要画面 [参考資料、37] が含まれます。これは、タスクの切り替えのためのシステムレベルのユーザーインターフェースです。ユーザーが最後にアプリを離れたときのアプリのグラフィック状態のサムネイル画像を使用して、最近アクセスしたアクティビティやタスクを表示することにも使われます。セクション 7.2.3 で詳述するように、履歴機能のナビゲーションキーを含むデバイス実装は、インターフェースを変更しても構いませんが、以下の要件を満たさなければなりません。

一緒に移動するグループとして関連する履歴を表示しなければなりません。
少なくとも 6 件までのアクティビティ表示をサポートしなければなりません。
少なくとも 4 つのアクティビティのタイトルを同時に表示するべきです。
ハイライト表示の色、アイコン、画面タイトルを履歴に表示するべきです。
画面固定動作 [参考資料、38] を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。
閉じるアフォーダンス（「x」）を表示するべきですが、ユーザーが画面を操作するまで遅らせても構いません。

デバイス実装は、概要画面にアップストリームの Android ユーザーインターフェース（またはそれに似たサムネイルベースのインターフェース）を使用することが強く推奨されます。

3.8.9. 入力管理

Android は、入力管理と、サードパーティのインプットメソッドエディタをサポートしています [参考資料、39]。ユーザーがデバイスでサードパーティの入力方法を使用できるようにするデバイス実装は、Android SDK ドキュメントで規定されているように、プラットフォーム機能 android.software.input_methods を宣言し、IME API をサポートしなければなりません。

android.software.input_methods 機能を宣言するデバイス実装は、ユーザーによるアクセスが可能な、サードパーティの入力方法を追加および構成するメカニズムを提供しなければなりません。デバイス実装は、android.settings.INPUT_METHOD_SETTINGS インテントに応じて設定インターフェースを表示しなければなりません。

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

Remote Control Client API は Android 5.0 で非推奨になり、メディアアプリがロック画面 [参考資料、40] にロック画面通知として表示される再生コントロールを統合できるメディア通知テンプレートに置き換えられました。デバイス実装は、セクション 3.8.3 に記載されているロック画面通知の一部としてメディア通知テンプレートを正しくレンダリングしなければなりません。

3.8.11. Dreams

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

3.8.12. 位置情報

デバイスに位置座標を提供できるハードウェアセンサー（GPS など）がある場合は、設定内の位置情報メニューに位置情報モード [参考資料、42] を表示しなければなりません。

3.8.13. Unicode とフォント

Android は、カラー絵文字をサポートしています。Android デバイス実装に IME が含まれる場合、デバイスは、Unicode 6.1 [参考資料、43] で規定された絵文字について、入力方法をユーザーに提供するべきです。すべてのデバイスは、こうした絵文字をカラーグリフでレンダリングできなければなりません。

Android は、さまざまなウェイトの Roboto 2 フォント（sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light）をサポートしています。それらすべてが、デバイスで利用可能な言語、ラテン文字、ギリシャ文字、キリル文字の Unicode 7.0 の全範囲（ラテン文字拡張 A、B、C、D を含む）、および Unicode 7.0 の通貨記号ブロックのすべてのグリフについて含まれていなければなりません。

3.9. デバイス管理

Android には、セキュリティ対応アプリが Android Device Administration API [参考資料、44] を介してシステムレベルでデバイス管理機能（パスワードポリシーの適用やリモートワイプの実施など）を実行できる機能があります。デバイス実装は、DevicePolicyManager クラス [参考資料、45] の実装を提供しなければなりません。PIN（数値）またはパスワード（英数字）に基づくロック画面のサポートを含むデバイス実装は、Android SDK ドキュメントで規定されているデバイス管理ポリシー [参考資料、44] をすべてサポートし、プラットフォーム機能 android.software.device_admin を報告しなければなりません。

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

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

デバイス実装が android.software.device_admin 機能を宣言する場合、初期設定フローでは、Device Policy Controller（DPC）アプリをデバイス所有者アプリ [参考資料、46] として登録できなければなりません。デバイス管理機能を実行するアプリをデバイス実装にプリインストールしても構いませんが、明示的な同意なしで、あるいはデバイスのユーザーまたは管理者からのアクションなしで、そのようなアプリをデバイス所有者アプリとして設定してはなりません。

デバイス所有者のプロビジョニングプロセス（android.app.action.PROVISION_MANAGED_DEVICE [参考資料、47] で開始されるフロー）のユーザーエクスペリエンスは、AOSP 実装に合わせなければなりません。

デバイス実装が android.hardware.nfc を報告する場合、デバイス所有者の NFC プロビジョニング [参考資料、48] を可能にするために、初期設定フロー中であっても、NFC を有効にしなければなりません。

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

デバイス実装が android.software.managed_users を宣言する場合は、Device Policy Controller（DPC）アプリを新しい管理対象プロファイルの所有者 [参考資料、49] として登録できなければなりません。

管理対象プロファイルのプロビジョニングプロセス（android.app.action.PROVISION_MANAGED_PROFILE [参考資料、50] で開始されるフロー）のユーザーエクスペリエンスは、AOSP 実装に合わせなければなりません。

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

管理対象プロファイル対応のデバイスは、次のようなデバイスです。

android.software.device_admin を宣言している（セクション 3.9 デバイス管理を参照）。
低 RAM デバイスではない（セクション 7.6.1 を参照）。
共有ストレージとして内部（非リムーバブル）ストレージを割り当てている（セクション 7.6.2 を参照）。

管理対象プロファイル対応デバイスは、以下の要件を満たさなければなりません。

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

3.10. ユーザー補助

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

デバイス実装には以下の要件が適用されます。

Android Automotive 実装は、デフォルトの Android 実装と整合する Android ユーザー補助フレームワークの実装を提供すべきです。
デバイス実装（Android Automotive を除く）は、デフォルトの Android 実装と整合する Android ユーザー補助フレームワークの実装を提供しなければなりません。
デバイス実装（Android Automotive を除く）は、android.accessibilityservice API [参考資料、52] を介してサードパーティのユーザー補助サービス実装をサポートしなければなりません。
デバイス実装（Android Automotive を除く）は、デフォルトの Android 実装と整合する方法で AccessibilityEvent を生成し、それらのイベントをすべての登録済みの AccessibilityService 実装に配信しなければなりません。
デバイス実装（オーディオ出力がない Android Automotive デバイスと Android スマートウォッチデバイスを除く）は、ユーザーによるアクセスが可能な、ユーザー補助サービスを有効または無効にするメカニズムを提供しなければならず、android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS インテントに応じてこのインターフェースを表示しなければなりません。

さらに、デバイス実装は、デバイスでユーザー補助サービスの実装を提供するべきであり、ユーザーがデバイスのセットアップ中にユーザー補助サービスを有効にするメカニズムを提供するべきです。ユーザー補助サービスのオープンソース実装は、Eyes Free プロジェクト [参考資料、53] から入手できます。

3.11. テキスト読み上げ

Android には、アプリがテキスト読み上げ（TTS）サービスを利用できるようにし、サービスプロバイダが TTS サービスの実装を提供できるようにする API が含まれています [参考資料、54]。機能 android.hardware.audio.output を報告するデバイス実装は、Android TTS フレームワークに関連する次の要件を満たさなければなりません。

Android Automotive の実装には、以下の要件が適用されます。

Android TTS フレームワーク API をサポートしなければなりません。
サードパーティ TTS エンジンのインストールをサポートしても構いません。サポートする場合、パートナーは、システムレベルで使用する TTS エンジンをユーザーが選択できる、ユーザーによるアクセスが可能なインターフェースを提供しなければなりません。

その他のすべてのデバイス実装には、以下の要件が適用されます。

Android TTS フレームワーク API をサポートしなければならず、デバイスで利用できる言語をサポートする TTS エンジンを含むべきです。なお、アップストリームの Android オープンソースソフトウェアには、フル機能の TTS エンジン実装が含まれています。
サードパーティ TTS エンジンのインストールをサポートしなければなりません。
システムレベルで使用する TTS エンジンをユーザーが選択できる、ユーザーによるアクセスが可能なインターフェースを提供しなければなりません。

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

Android テレビ入力フレームワーク（TIF）により、Android テレビデバイスへのライブコンテンツの配信が簡単になります。TIF は、Android テレビデバイスをコントロールする入力モジュールを作成するための標準 API を提供します。Android テレビデバイス実装は、テレビ入力フレームワーク [参考資料、55] をサポートしなければなりません。

TIF をサポートするデバイス実装は、プラットフォーム機能 android.software.live_tv を宣言しなければなりません。

3.12.1. TV アプリ

ライブテレビのサポートを宣言するデバイス実装には、テレビアプリ（TV アプリ）がインストールされていなければなりません。Android オープンソースプロジェクトは、TV アプリの実装を提供しています。

デフォルトの TV アプリでは、インストール済み入力とサードパーティ入力からチャンネルへのアクセスを提供しなければなりません。なお、インストール済み入力には、TIF ベースであるかどうかに関係なく、デフォルトですべての入力を含めます。

TV アプリは、テレビチャンネル [参考資料、56] をインストールして使用する機能を提供し、以下の要件を満たさなければなりません。

デバイス実装は、サードパーティの TIF ベースの入力（サードパーティ入力）[参考資料、57] のインストールと管理を許可しなければなりません。
デバイス実装は、プリインストールされた TIF ベースの入力（インストール済み入力）[参考資料、58] とサードパーティ入力を視覚的に分離しても構いません。
デバイス実装は、TV アプリからのナビゲーションに複数の操作を要するサードパーティ入力を表示（つまり、TV アプリからのサードパーティ入力のリストを拡張）してはなりません。

3.12.1.1. 電子番組ガイド

Android テレビデバイス実装は、情報を提供するインタラクティブなオーバーレイを表示しなければなりません。このオーバーレイは、TvContract.Programs フィールド [参考資料、59] の値から生成される電子番組ガイド（EPG）を含まなければなりません。EPG は以下の要件を満たさなければなりません。

EPG は、すべてのインストール済み入力とサードパーティ入力からの情報を表示しなければなりません。
EPG は、インストール済み入力とサードパーティ入力を視覚的に分離しても構いません。
EPG は、インストール済み入力とサードパーティ入力を同じくらい目立つように表示することが強く推奨されます。EPG は、EPG のインストール済み入力からのナビゲーションに複数の操作を要するサードパーティ入力を表示してはなりません。
チャンネルの変更時に、デバイス実装は現在再生中の番組の EPG データを表示しなければなりません。

3.12.1.2. ナビゲーション

Android テレビデバイス入力デバイス（リモコン、リモートコントロールアプリ、ゲームコントローラなど）では、D-pad を介して画面の操作可能なすべてのセクションへのナビゲーションを許可しなければなりません。画面に操作可能なセクションがない場合、ライブテレビチャンネルを変更するには、D-pad の上下キーを使用しなければなりません。

TV アプリは、CEC を通じて重要なイベントを HDMI 入力に渡すべきです。

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

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

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

デバイス実装は、公式の Android SDK [参考資料、61] に含まれる「aapt」ツールによって生成された Android「.apk」ファイルをインストールして実行しなければなりません。

デバイス実装は、.apk [参考資料、62]、Android マニフェスト [参考資料、49]、Dalvik バイトコード [参考資料、23]、RenderScript バイトコードのいずれの形式も、他の互換デバイスで該当ファイルを正しくインストールおよび実行できなくなるような方法で拡張してはなりません。

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

5.1. メディアコーデック

デバイス実装は、このドキュメントで明示的に許可されている場合を除き、Android SDK ドキュメントで規定されているコアメディア形式 [参考資料、64] をサポートしなければなりません。具体的には、デバイス実装は、以下の表で定義され、MediaCodecList [参考資料、65] を介して報告されるメディア形式、エンコーダ、デコーダ、ファイル形式、コンテナ形式をサポートしなければなりません。また、CamcorderProfile [参考資料、66] で報告されるすべてのプロファイルをデコードできなければならず、エンコードできるすべての形式をデコードできなければなりません。以下のすべてのコーデックは、Android オープンソースプロジェクトの推奨 Android 実装でソフトウェア実装として提供されています。

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

5.1.1. オーディオコーデック

形式 / コーデック	エンコーダ	デコーダ	詳細	サポートされているファイル形式 / コンテナ形式
MPEG-4 AAC プロファイル（AAC LC）	必須¹	必須	標準サンプリングレート 8～48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート²。	3GPP（.3gp） MPEG-4（.mp4、.m4a） ADTS Raw AAC（.aac、Android 3.1 以降でデコード、Android 4.0 以降でエンコード、ADIF はサポート対象外） MPEG-TS（.ts、シーク不可、Android 3.0 以降）
MPEG-4 HE AAC プロファイル（AAC+）	必須¹（Android 4.1 以降）	必須	標準サンプリングレート 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）	必須¹（Android 4.1 以降）	必須（Android 4.1 以降）	標準サンプリングレート 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		必須（Android 3.1 以降）	モノラル / ステレオ（マルチチャンネルはサポート対象外）。サンプルレートは最大 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）	必須⁴ （Android 4.1 以降）	必須	16 ビットのリニア PCM（最大レートはハードウェアの上限値）。デバイスは、Raw PCM 録音のサンプリングレートとして 8,000、11,025、16,000、44,100 Hz の周波数をサポートしなければなりません。	WAVE（.wav）
Opus		必須（Android 5.0 以降）		Matroska（.mkv）

1 android.hardware.microphone を定義するデバイス実装では必須ですが、Android スマートウォッチデバイス実装では任意です。

2 5.0 / 5.1 コンテンツのダウンミックスのみが必須です。2 チャンネルを超える録画またはレンダリングは任意です。

3 Android ハンドヘルドデバイス実装では必須です。

4 android.hardware.microphone を定義するデバイス実装（Android スマートウォッチデバイス実装を含む）では必須です。

5.1.2. 画像コーデック

形式 / コーデック	エンコーダ	デコーダ	詳細	サポートされているファイル形式 / コンテナ形式
JPEG	必須	必須	ベースラインとプログレッシブ	JPEG（.jpg）
GIF		必須		GIF（.gif）
PNG	必須	必須		PNG（.png）
BMP		必須		BMP（.bmp）
WebP	必須	必須		WebP（.webp）

5.1.3. 動画コーデック

形式 / コーデック	エンコーダ	デコーダ	詳細	サポートされているファイル形式 / コンテナ形式
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³	必須² （Android 4.3 以降）	必須² （Android 2.3.3 以降）	詳細についてはセクション 5.2 と 5.3 をご覧ください	WebM（.webm）[参考資料、67] Matroska（.mkv、Android 4.0 以降）⁴
VP9		必須² （Android 4.4 以降）	詳細についてはセクション 5.3 をご覧ください	WebM（.webm）[参考資料、67] Matroska（.mkv、Android 4.0 以降）⁴

1 カメラハードウェアを含み、android.hardware.camera または android.hardware.camera.front を定義するデバイス実装では必須です。

2 Android スマートウォッチデバイス以外のデバイス実装では必須です。

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

4 デバイス実装は、Matroska WebM ファイルの書き込みをサポートするべきです。

5 Android Automotive では強く推奨され、Android スマートウォッチでは任意で、他のすべてのデバイスタイプでは必須です。

6 Android テレビデバイス実装にのみ適用されます。

5.2. 動画のエンコード

Android スマートウォッチデバイス実装では、動画コーデックは任意です。

H.263 エンコーダを含む Android デバイス実装は、ベースラインプロファイルレベル 45 をサポートしなければなりません。

H.264 コーデックをサポートする Android デバイス実装は、ベースラインプロファイルレベル 3 と以下の SD（標準画質）動画エンコードプロファイルをサポートしなければならず、メインプロファイルレベル 4 と以下の HD（高画質）動画エンコードプロファイルをサポートするべきです。Android テレビデバイスは、HD 1080p 動画を 30 fps でエンコードすることが強く推奨されます。

	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

1 ハードウェアでサポートされている場合。ただし、Android テレビデバイスでは強く推奨されます。

VP8 コーデックをサポートする Android デバイス実装は、SD 動画エンコードプロファイルをサポートしなければならず、以下の HD（高画質）動画エンコードプロファイルをサポートすべきです。

	SD（低画質）	SD（高画質）	HD 720p¹	HD 1080p¹
動画の解像度	320 x 180 ピクセル	640 x 360 ピクセル	1,280 x 720 ピクセル	1,920 x 1,080 px
動画のフレームレート	30 fps	30 fps	30 fps	30 fps
動画のビットレート	800 Kbps	2 Mbps	4 Mbps	10 Mbps

1 ハードウェアでサポートされている場合。

5.3. 動画のデコード

Android スマートウォッチデバイス実装では、動画コーデックは任意です。

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

H.263 デコーダを備えた Android デバイス実装は、ベースラインプロファイルレベル 30 をサポートしなければなりません。

MPEG-4 デコーダを備えた Android デバイス実装は、シンプルプロファイルレベル 3 をサポートしなければなりません。

H.264 デコーダを備えた Android デバイス実装は、メインプロファイルレベル 3.1 と、以下の SD 動画デコードプロファイルをサポートしなければならず、HD デコードプロファイルをサポートするべきです。Android テレビデバイスは、ハイプロファイルレベル 4.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

1 Display.getSupportedModes() メソッドによって報告される高さが動画の解像度以上である場合は必須です。

2 Android テレビデバイス実装では必須です。

セクション 5.1.3 に記載されている VP8 コーデックをサポートする場合、Android デバイス実装は、次の SD デコードプロファイルをサポートしなければならず、HD デコードプロファイルをサポートするべきです。Android テレビデバイスは、HD 1080p デコードプロファイルをサポートしなければなりません。

	SD（低画質）	SD（高画質）	HD 720p¹	HD 1080p¹
動画の解像度	320 x 180 ピクセル	640 x 360 ピクセル	1,280 x 720 ピクセル	1,920 x 1,080 px
動画のフレームレート	30 fps	30 fps	30 fps / 60 fps²	30 / 60 fps²
動画のビットレート	800 Kbps	2 Mbps	8 Mbps	20 Mbps

1 Display.getSupportedModes() メソッドによって報告される高さが動画の解像度以上である場合は必須です。

2 Android テレビデバイス実装では必須です。

セクション 5.1.3 に記載されている VP9 コーデックをサポートする場合、Android デバイス実装は、次の SD 動画デコードプロファイルをサポートしなければならず、HD デコードプロファイルをサポートするべきです。Android テレビデバイスは、HD 1080p デコードプロファイルをサポートすることが強く推奨され、UHD デコードプロファイルをサポートするべきです。UHD 動画デコードプロファイルがサポートされている場合は、8 ビット色深度をサポートしなければならず、VP9 プロファイル 2（10 ビット）をサポートするべきです。

	SD（低画質）	SD（高画質）	HD 720p¹	HD 1080p²	UHD²
動画の解像度	320 x 180 ピクセル	640 x 360 ピクセル	1,280 x 720 ピクセル	1,920 x 1,080 px	3,840 x 2,160 px
動画のフレームレート	30 fps	30 fps	30 fps	60 fps	60 fps
動画のビットレート	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 Android テレビデバイス実装では必須ですが、その他のデバイスタイプでは、ハードウェアでサポートされている場合にのみ必須です。

2 ハードウェアでサポートされている場合、既存の Android テレビデバイス実装に強く推奨されます。

セクション 5.1.3 に記載されている H.265 コーデックをサポートする場合、Android デバイス実装は、メインプロファイルレベル 3 メインティアと次の SD 動画デコードプロファイルをサポートしなければならず、HD デコードプロファイルをサポートするべきです。Android テレビデバイスは、UHD デコードプロファイルと HD 1080p デコードプロファイルをサポートすることが強く推奨されます。HD 1080p デコードプロファイルがサポートされている場合は、メインプロファイルレベル 4.1 メインティアをサポートしなければなりません。UHD デコードがサポートされている場合、UHD デコードは、メイン 10 レベル 5 メインティアプロファイルをサポートしなければなりません。

	SD（低画質）	SD（高画質）	HD 720p¹	HD 1080p²	UHD²
動画の解像度	352 x 288 px	640 x 360 ピクセル	1,280 x 720 ピクセル	1,920 x 1,080 px	3,840 x 2,160 px
動画のフレームレート	30 fps	30 fps	30 fps	60 fps²	60 fps
動画のビットレート	600 Kbps	1.6 Mbps	4 Mbps	10 Mbps	20 Mbps

1 Android テレビデバイス実装では必須ですが、その他のデバイスタイプでは、ハードウェアでサポートされている場合にのみ必須です。

2 ハードウェアでサポートされている場合、既存の Android テレビデバイス実装に強く推奨されます。

5.4. 録音

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

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

android.hardware.microphone を宣言するデバイス実装は、次の特性を持つ未加工オーディオコンテンツをキャプチャできるようにしなければなりません。

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

上記のサンプルレートでのキャプチャはアップサンプリングなしで行わなければならず、ダウンサンプリングは適切なアンチエイリアスフィルタを含まなければなりません。

android.hardware.microphone を宣言するデバイス実装は、次の特性を持つ未加工オーディオコンテンツをキャプチャできるようにするべきです。

形式: リニア PCM、16 ビット
サンプリングレート: 22,050、48,000
チャンネル: ステレオ

上記のサンプルレートでのキャプチャをサポートする場合、キャプチャは 16,000:22,050 または 44,100:48,000 を超えるレートでアップサンプリングなしに行わなければなりません。すべてのアップサンプリングまたはダウンサンプリングは、適切なアンチエイリアスフィルタを含まなければなりません。

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

上記の録音仕様に加えて、アプリが android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音源を使用してオーディオストリームの録音を開始したときは、以下の要件が適用されます。

デバイスは、ほぼ平坦な振幅周波数特性（具体的には ±3 dB、100 Hz～4,000 Hz）を示すべきです。
オーディオ入力感度は、1,000 Hz で音圧レベル（SPL）90 dB の音源が 16 ビットサンプルで RMS 2,500 になるように設定すべきです。
PCM 振幅レベルは、マイクでの 90 dB SPL から少なくとも 30 dB（-18 dB～+12 dB）の範囲で入力 SPL の変化を線形的にトラッキングするべきです。
高調波ひずみの合計は、マイクにおける 90 dB SPL の入力レベルで 1 KHz に対して 1% 未満であるべきです。
ノイズリダクション処理が存在する場合は、無効にしなければなりません。
自動ゲインコントロールが存在する場合は、無効にしなければなりません。

プラットフォームが音声認識用に調整されたノイズサプレッション技術をサポートしている場合、その効果は android.media.audiofx.NoiseSuppressor API から制御できなければなりません。さらに、ノイズサプレッサーのエフェクト記述子の UUID フィールドでは、ノイズサプレッション技術の各実装を一意に識別しなければなりません。

5.4.3. 再生のリルート用のキャプチャ

android.media.MediaRecorder.AudioSource クラスには REMOTE_SUBMIX 音源が含まれています。android.hardware.audio.output を宣言するデバイスは、アプリが android.media.AudioRecord API を使用してこの音源から録音を行うときに、下記を除くすべての音声ストリームのミックスをキャプチャできるように、REMOTE_SUBMIX 音源を適切に実装しなければなりません。

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

5.5. オーディオの再生

android.hardware.audio.output を宣言するデバイス実装は、このセクションの要件を満たさなければなりません。

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

デバイスは、次の特性を持つ未加工オーディオコンテンツを再生できるようにしなければなりません。

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

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

サンプリングレート: 24,000、48,000

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

Android は、デバイス実装にオーディオエフェクト用の API [参考資料、69] を提供します。機能 android.hardware.audio.output を宣言するデバイス実装には、以下の要件が適用されます。

AudioEffect サブクラス Equalizer および LoudnessEnhancer を通じて制御できる EFFECT_TYPE_EQUALIZER と EFFECT_TYPE_LOUDNESS_ENHANCER の実装をサポートしなければなりません。
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. オーディオ出力の音量

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

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

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

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

出力レイテンシ。アプリが PCM 符号化データフレームを書き込んでから、対応するサウンドが外部のリスナーに聞こえるかトランスデューサで検知されるまでの間隔。
コールド出力レイテンシ。リクエストの前にオーディオ出力システムがアイドル状態で電源がオフになっていたときの、最初のフレームの出力レイテンシ。
連続出力レイテンシ。デバイスがオーディオを再生した後の、後続フレームの出力レイテンシ。
入力レイテンシ。外部のサウンドがデバイスに渡されてから、アプリが対応する PCM 符号化データフレームを読み取るまでの間隔。
コールド入力レイテンシ。リクエストの前にオーディオ入力システムがアイドル状態で電源がオフになっていたときの、欠損入力時間と最初のフレームの入力レイテンシの合計。
連続入力レイテンシ。デバイスがオーディオをキャプチャしている間の、後続フレームの入力レイテンシ。
コールド出力ジッター。コールド出力レイテンシ値の、個々の測定値間のばらつき。
コールド入力ジッター。コールド入力レイテンシ値の、個々の測定値間のばらつき。
連続ラウンドトリップレイテンシ。連続入力レイテンシ、連続出力レイテンシ、1 バッファ期間の合計。バッファ期間により、アプリの処理時間と、アプリが入出力ストリーム間の位相差を緩和するための時間を確保できます。
OpenSL ES PCM バッファキュー API。Android NDK 内にある PCM 関連の OpenSL ES API のセット。NDK_root/docs/opensles/index.html をご覧ください。

android.hardware.audio.output を宣言するデバイス実装は、下記のオーディオ出力要件を満たすか上回ることが強く推奨されます。

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

デバイス実装は、OpenSL ES PCM バッファキュー API を使用する際の初期キャリブレーションの後でこのセクションの要件を満たす場合、少なくとも 1 つのサポートされているオーディオ出力デバイスの連続出力レイテンシとコールド出力レイテンシについて、android.content.pm.PackageManager クラス [参考資料、70] により機能 android.hardware.audio.low-latency を報告することで、低レイテンシオーディオのサポートを報告することが強く推奨されます。逆に、上記の要件を満たさない場合、デバイス実装は低レイテンシオーディオのサポートを報告してはなりません。

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

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

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

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

RTSP（RTP、SDP）
HTTP(S) プログレッシブストリーミング
HTTP(S) ライブストリーミングドラフトプロトコル、バージョン 3 [参考資料、71]

5.8. セキュアメディア

セキュアな動画出力をサポートし、セキュアサーフェスをサポートできるデバイス実装は、Display.FLAG_SECURE のサポートを宣言しなければなりません。Display.FLAG_SECURE のサポートを宣言するデバイス実装は、ワイヤレスディスプレイプロトコルをサポートする場合、Miracast ワイヤレスディスプレイ用の HDCP 2.x 以降などの暗号強度の高いメカニズムでリンクを保護しなければなりません。同様に、有線外部ディスプレイをサポートする場合、デバイス実装は HDCP 1.2 以降をサポートしなければなりません。Android テレビデバイス実装は、4K 解像度をサポートするデバイスの場合は HDCP 2.2、それより解像度が低いデバイスの場合は HDCP 1.4 以降をサポートしなければなりません。アップストリームの Android オープンソース実装には、この要件を満たすワイヤレス（Miracast）ディスプレイと有線（HDMI）ディスプレイのサポートが含まれています。

5.9. 電子楽器デジタルインターフェース（MIDI）

デバイス実装がアプリ間の MIDI ソフトウェアトランスポート（仮想 MIDI デバイス）をサポートし、一般的な非 MIDI 接続を提供する以下のすべての MIDI 対応ハードウェアトランスポートで MIDI をサポートする場合は、android.content.pm.PackageManager クラス [参考資料、70] を介して機能 android.software.midi のサポートを報告することが強く推奨されます。

MIDI 対応ハードウェアトランスポートは以下のとおりです。

USB ホストモード（セクション 7.7 USB）
USB ペリフェラルモード（セクション 7.7 USB）

これに対して、デバイス実装が上記の特定の MIDI 対応ハードウェアトランスポートを介して一般的な非 MIDI 接続を提供するが、そのハードウェアトランスポートを介して MIDI をサポートしない場合は、機能 android.software.midi のサポートを報告してはなりません。

中心的な役割を担う Bluetooth LE での MIDI（セクション 7.4.3 Bluetooth）は試用版です。デバイス実装は、機能 android.software.midi を報告し、Bluetooth LE で一般的な非 MIDI 接続を提供する場合、Bluetooth LE での MIDI をサポートするべきです。

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

デバイス実装が以下の要件をすべて満たす場合は、android.content.pm.PackageManager クラス [参考資料、70] を介して機能 android.hardware.audio.pro のサポートを報告することが強く推奨されます。

デバイス実装は、機能 android.hardware.audio.low_latency のサポートを報告しなければなりません。
セクション 5.6 オーディオレイテンシで規定しているように、連続ラウンドトリップオーディオレイテンシは 20 ミリ秒以下でなければならず、少なくとも 1 つのサポートされるパスで 10 ミリ秒以下であるべきです。
デバイスが 4 極 3.5 mm オーディオジャックを備えている場合、連続ラウンドトリップオーディオレイテンシはオーディオジャックのパスで 20 ミリ秒以下でなければならず、オーディオジャックのパスで 10 ミリ秒以下であるべきです。
デバイス実装は、USB ホストモードと USB ペリフェラルモードをサポートする USB ポートを備えていなければなりません。
USB ホストモードは、USB オーディオクラスを実装しなければなりません。
デバイスが HDMI ポートを備えている場合、デバイス実装は、ビット深度損失またはリサンプリングなしで、20 ビットまたは 24 ビット深度と 192 kHz のステレオおよび 8 チャンネルの出力をサポートしなければなりません。
デバイス実装は、機能 android.software.midi のサポートを報告しなければなりません。
デバイスが 4 極 3.5 mm オーディオジャックを備えている場合、デバイス実装は、有線オーディオヘッドセット仕様（v1.1）のモバイルデバイス（ジャック）仕様セクションに従うことが強く推奨されます。

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

6.1. デベロッパーツール

デバイス実装は、Android SDK で提供されている Android デベロッパーツールをサポートしなければなりません。Android 互換デバイスは、以下のものと互換性がなければなりません。

Android Debug Bridge（adb）[参考資料、72]

デバイス実装は、Android SDK ドキュメントに記載されているように、adb のすべての機能（dumpsys [参考資料、73] を含む）をサポートしなければなりません。デバイス側の adb デーモンはデフォルトで無効でなければならず、ユーザーによるアクセスが可能な、Android Debug Bridge をオンにするメカニズムが存在しなければなりません。デバイス実装が USB ペリフェラルモードを省略している場合は、ローカルエリアネットワーク（イーサネットや 802.11 など）を介して Android Debug Bridge を実装しなければなりません。

Android は、セキュア adb をサポートしています。セキュア adb は、既知の認証済みホストで adb を有効にします。デバイス実装はセキュア adb をサポートしなければなりません。

Dalvik Debug Monitor Service（ddms）[参考資料、74]

デバイス実装は、Android SDK に記載されているように、ddms のすべての機能をサポートしなければなりません。ddms は adb を使用するので、ddms のサポートはデフォルトで無効にするべきですが、上記のようにユーザーが Android Debug Bridge を有効にした場合は必ずサポートしなければなりません。

Monkey [参考資料、75]

デバイス実装は、Monkey フレームワークを含まなければならず、アプリで使用できるようにしなければなりません。

SysTrace [参考資料、76]

デバイス実装は、Android SDK に記載されているように、systrace ツールをサポートしなければなりません。Systrace はデフォルトで無効でなければならず、Systrace をオンにするユーザーがアクセス可能なメカニズムがなければなりません。

ほとんどの Linux ベースのシステムと Apple Macintosh システムは、追加サポートなしで、標準の Android SDK Tools を使用して Android デバイスを認識します。一方、Microsoft Windows システムは、通常、新しい Android デバイス用のドライバを必要とします（たとえば、新しいベンダー ID や新しいデバイス ID には、Windows システム用のカスタム USB ドライバが必要です）。デバイス実装が標準の Android SDK で提供される adb ツールによって認識されない場合、デバイス実装者は、デベロッパーが adb プロトコルを使用してデバイスに接続するための Windows ドライバを提供しなければなりません。これらのドライバは、32 ビット版と 64 ビット版の両方で、Windows XP、Windows Vista、Windows 7、Windows 8、Windows 10 向けに提供しなければなりません。

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

Android は、デベロッパーがアプリ開発関連の設定を構成することをサポートしています。デバイス実装は、android.settings.APPLICATION_DEVELOPMENT_SETTINGS インテントを尊重して、アプリ開発関連の設定を表示しなければなりません [参考資料、77]。アップストリームの Android 実装では、開発者向けオプションメニューはデフォルトで非表示になっています。ユーザーは [設定] > [デバイス情報] > [ビルド番号] メニューアイテムを 7 回タップすると、開発者向けオプションを起動できます。デバイス実装は、開発者向けオプションについて一貫性のあるエクスペリエンスを提供しなければなりません。具体的には、デバイス実装は、開発者向けオプションをデフォルトで非表示にしなければならず、アップストリームの Android 実装と一貫性がある、開発者向けオプションを有効にするメカニズムを提供しなければなりません。

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

サードパーティデベロッパー向けの対応する API を持つ特定のハードウェアコンポーネントがデバイスに含まれている場合、デバイス実装は、Android SDK ドキュメントに記載されているように、その API を実装しなければなりません。任意であると明記されているハードウェアコンポーネントを SDK の API が操作し、デバイス実装がそのコンポーネントを備えていない場合:

そのような場合でも、コンポーネントの API 用の完全なクラス定義（SDK ドキュメントに記載）が存在しなければなりません。
API の動作は、なんらかの合理的な方法で NoOps として実装しなければなりません。
API メソッドは、SDK ドキュメントで許可されている場合、null 値を返さなければなりません。
API メソッドは、null 値が SDK ドキュメントで許可されていないクラスでは NoOps 実装を返さなければなりません。
API メソッドは、SDK ドキュメントに記載されていない例外をスローしてはなりません。

上記の要件が適用されるシナリオの典型例は、テレフォニー API です。これらの API は、電話以外のデバイスであっても、合理的な NoOps として実装しなければなりません。

デバイス実装は、同じビルドのフィンガープリントについて、android.content.pm.PackageManager クラスの getSystemAvailableFeatures() メソッドと hasSystemFeature(String) メソッドにより、正確なハードウェア構成情報を矛盾なく報告しなければなりません。[参考資料、70]

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

Android には、さまざまなハードウェア構成でサードパーティアプリが適切に動作するように、デバイスに合わせてアプリアセットと UI レイアウトを自動的に調整する機能があります [参考資料、78]。このセクションで詳述するように、デバイスはそのような API と動作を適切に実装しなければなりません。

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

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

7.1.1. 画面構成

7.1.1.1. 画面サイズ

Android スマートウォッチデバイス（セクション 2 で詳述）は、このセクションに記載されているように、画面サイズが小さくても構いません。

Android UI フレームワークはさまざまな画面サイズをサポートしており、アプリは SCREENLAYOUT_SIZE_MASK を使用して android.content.res.Configuration.screenLayout でデバイスの画面サイズ（「画面レイアウト」とも呼ばれます）をクエリできます。デバイス実装は、Android SDK ドキュメント [参考資料、78] で規定されていてアップストリームの Android プラットフォームによって決定される正しい画面サイズを報告しなければなりません。具体的には、デバイス実装は、次の論理密度非依存ピクセル（dp）画面寸法に従って、正しい画面サイズを報告しなければなりません。

デバイスは、画面サイズが少なくとも 426 dp x 320 dp（「小」）でなければなりません。ただし、Android スマートウォッチデバイスは除きます。
画面サイズが「標準」であるとレポートするデバイスは、画面サイズが少なくとも 480 dp x 320 dp でなければなりません。
画面サイズが「大」であるとレポートするデバイスは、画面サイズが少なくとも 640 dp x 480 dp でなければなりません。
画面サイズが「特大」であるとレポートするデバイスは、画面サイズが少なくとも 960 dp x 720 dp でなければなりません。

さらに、

Android スマートウォッチデバイスは、画面の物理的な対角サイズが 1.1～2.5 インチの範囲内になければなりません。
画面が物理的に統合されているその他のタイプの Android デバイス実装は、画面の物理的な対角サイズが少なくとも 2.5 インチでなければなりません。

デバイスは、レポートされた画面サイズをいかなるときも変更してはなりません。

アプリが AndroidManifest.xml ファイルの <supports-screens> 属性を介して、サポートする画面サイズを示すかどうかは任意です。デバイス実装は、Android SDK ドキュメントに記載されているように、小、標準、大、特大の画面についてアプリが表明しているサポートを正しく尊重しなければなりません。

7.1.1.2. 画面のアスペクト比

Android スマートウォッチデバイスは、アスペクト比が 1.0（1:1）であっても構いません。

画面のアスペクト比は 1.3333（4:3）から 1.86（おおよそ 16:9）まででなければなりませんが、Android スマートウォッチデバイスは 1.0（1:1）のアスペクト比であっても構いません。そのようなデバイス実装は、android.content.res.Configuration.uiMode として UI_MODE_TYPE_WATCH を使用するためです。

7.1.1.3. 画面密度

Android UI フレームワークは、アプリデベロッパーがアプリリソースをターゲットにできるように、標準的な論理密度のセットを定義しています。デバイス実装は、android.util.DisplayMetrics API を介して次のいずれかの論理 Android フレームワーク密度をレポートしなければならず、この標準密度でアプリを実行しなければなりません。また、デフォルトディスプレイに関しては、いかなるときにも、この値を変更してはなりません。

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

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

7.1.2. ディスプレイの指標

デバイス実装は、android.util.DisplayMetrics [参考資料、79] で規定されているすべてのディスプレイ指標について正しい値を報告しなければなりません。また、内蔵画面と外部画面のどちらがデフォルトディスプレイとして使用されているかにかかわらず、同じ値を報告しなければなりません。

7.1.3. 画面の向き

デバイスは、サポートする画面の向き（android.hardware.screen.portrait や android.hardware.screen.landscape）を報告しなければならず、サポートされる向きを少なくとも 1 つ報告しなければなりません。たとえば、テレビやノートパソコンなど、固定の横向き画面を備えたデバイスは、android.hardware.screen.landscape のみを報告すべきです。

両方の画面の向きをレポートするデバイスは、アプリによる動的な画面の向き（縦向きまたは横向き）の指定をサポートしなければなりません。つまり、デバイスは、特定の画面の向きに関するアプリのリクエストを尊重しなければなりません。デバイス実装は、縦向きと横向きのいずれかをデフォルトとして選択しても構いません。

デバイスは、android.content.res.Configuration.orientation、android.view.Display.getOrientation()、またはその他の API を介してクエリされた場合は常に、デバイスの現在の画面の向きについて、正しい値をレポートしなければなりません。

デバイスは、向きを変更するときに、報告する画面サイズまたは密度を変更してはなりません。

7.1.4. 2D と 3D のグラフィックアクセラレーション

デバイス実装は、Android SDK ドキュメントで具体的に詳述されているように、OpenGL ES 1.0 と 2.0 の両方をサポートしなければなりません。デバイス実装は、OpenGL ES 3.0 または 3.1 をサポートできるデバイスでは、それをサポートするべきです。デバイス実装は、Android SDK ドキュメント [参考資料、80] で詳述されているとおり、Android RenderScript もサポートしなければなりません。

また、デバイス実装は、OpenGL ES 1.0、OpenGL ES 2.0、OpenGL ES 3.0、または OpenGL 3.1 のサポートを正しく識別しなければなりません。つまり:

マネージド API は（GLES10.getString() メソッドなどにより）OpenGL ES 1.0 と OpenGL ES 2.0 のサポートをレポートしなければなりません。
ネイティブ C/C++ OpenGL API（つまり、libGLES_v1CM.so、libGLES_v2.so、または libEGL.so を介してアプリから使用できる API）は、OpenGL ES 1.0 と OpenGL ES 2.0 のサポートをレポートしなければなりません。
OpenGL ES 3.0 または 3.1 のサポートを宣言するデバイス実装は、対応するマネージド API をサポートするとともに、ネイティブ C/C++ API のサポートを含まなければなりません。OpenGL ES 3.0 または 3.1 のサポートを宣言するデバイス実装では、libGLESv2.so は OpenGL ES 2.0 の関数シンボルに加えて、対応する関数シンボルをエクスポートしなければなりません。

Android は、OpenGL ES 3.1 に加えて、Java インターフェースを備えた拡張機能パック [参考資料、81] と、テッセレーションや ASTC テクスチャ圧縮形式などの高度なグラフィック機能のネイティブサポートを提供しています。Android デバイス実装は、この拡張機能パックをサポートしても構いません。完全に実装されている場合に限り、android.hardware.opengles.aep 機能フラグを通じてサポートを識別しなければなりません。

また、デバイス実装は、任意の OpenGL ES 拡張機能を実装しても構いません。ただしデバイス実装は、OpenGL ES のマネージド API とネイティブ API を介して、サポートする拡張機能の文字列をすべてレポートしなければならず、また逆に、サポートしない拡張機能の文字列をレポートしてはなりません。

なお、Android では、アプリは特定の OpenGL テクスチャ圧縮形式を必要とすることを任意で指定できます。通常、そうした形式はベンダー固有です。Android では、デバイス実装が特定のテクスチャ圧縮形式を実装することは必須ではありません。ただし、OpenGL API の getString() メソッドを介して、サポートするテクスチャ圧縮形式を正確に報告するべきです。

Android には、マニフェストタグ android:hardwareAccelerated または直接 API 呼び出しを使用することで、アプリ、アクティビティ、ウィンドウ、ビューの各レベルで 2D グラフィックのハードウェアアクセラレーションを有効にすることをアプリが宣言するメカニズムがあります [参考資料、82]。

デバイス実装は、ハードウェアアクセラレーションをデフォルトで有効にしなければならず、デベロッパーが android:hardwareAccelerated="false” を設定するか、Android View API を通じてハードウェアアクセラレーションを直接無効にすることでリクエストした場合、ハードウェアアクセラレーションを無効にしなければなりません。

さらに、デバイス実装は、ハードウェアアクセラレーションに関する Android SDK ドキュメント [参考資料、82] の記述と整合する動作を行わなければなりません。

Android には、ハードウェアアクセラレーションの OpenGL ES テクスチャを UI 階層のレンダリングターゲットとしてデベロッパーが直接統合できる、TextureView オブジェクトがあります。デバイス実装は TextureView API をサポートしなければならず、アップストリームの Android 実装と整合する動作を行わなければなりません。

Android には、EGL_ANDROID_RECORDABLE のサポートが含まれています。これは、画像を動画に記録する ANativeWindow へのレンダリングを EGLConfig がサポートするかどうかを示す EGLConfig 属性です。デバイス実装は、EGL_ANDROID_RECORDABLE 拡張機能 [参考資料、83] をサポートしなければなりません。

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

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

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

7.1.6. 画面技術

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

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

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

Android にはセカンダリディスプレイのサポートが含まれており、メディア共有機能と、外部ディスプレイにアクセスするためのデベロッパー API を有効にできます。デバイスが有線、無線、または埋め込み式の追加ディスプレイ接続を介して外部ディスプレイをサポートする場合、デバイス実装は、Android SDK ドキュメントに記載されているように、ディスプレイマネージャー API を実装しなければなりません [参考資料、84]。

7.2. 入力デバイス

デバイスは、タッチスクリーンをサポートするか、7.2.2 に記載されているタップ以外のナビゲーションの要件を満たさなければなりません。

7.2.1. キーボード

Android スマートウォッチ実装と Android Automotive 実装は、ソフトキーボードを実装しても構いません。他のすべてのデバイス実装は、ソフトキーボードを実装しなければならず、さらに以下の要件も適用されます。

デバイス実装は:

http://developer.android.com に詳述されているように、サードパーティデベロッパーがソフトキーボードなどのインプットメソッドエディタを作成できる入力管理フレームワークをサポートしなければなりません。
ハードキーボードが存在するかどうかにかかわらず、少なくとも 1 つのソフトキーボード実装を提供しなければなりません。ただし、画面サイズの観点からソフトキーボードを備えることがあまり合理的でない Android スマートウォッチデバイスは除きます。
追加のソフトキーボード実装を含んでも構いません。
ハードウェアキーボードを含んでも構いません。
android.content.res.Configuration.keyboard [参考資料、85] で規定されている形式（QWERTY キーまたは 12 キー）のいずれかと一致しないハードウェアキーボードを含んではなりません。

7.2.2. タップ以外のナビゲーション

Android テレビデバイスは、D-pad をサポートしなければなりません。

デバイス実装は:

デバイス実装が Android テレビデバイスでない場合は、タップ以外のナビゲーションオプション（トラックボール、D-pad、ホイール）を省略しても構いません。
android.content.res.Configuration.navigation [参考資料、85] について、正しい値を報告しなければなりません。
入力管理エンジンと互換性のある、テキストの選択と編集のための妥当な代替ユーザーインターフェースメカニズムを提供しなければなりません。アップストリームの Android オープンソース実装には、タップ以外のナビゲーション入力がないデバイスでの使用に適した選択メカニズムがあります。

7.2.3. ナビゲーションキー

このセクションで説明しているように、ホーム機能、履歴機能、戻る機能の可用性と表示の要件は、デバイスタイプによって異なります。

ホーム機能、履歴機能、戻る機能（それぞれキーイベント KEYCODE_HOME、KEYCODE_APP_SWITCH、KEYCODE_BACK にマッピングされています）は Android のナビゲーションパラダイムに不可欠であるため、以下の要件が適用されます。

Android ハンドヘルドデバイス実装は、ホーム機能、履歴機能、戻る機能を提供しなければなりません。
Android テレビデバイス実装は、ホーム機能と戻る機能を提供しなければなりません。
Android スマートウォッチデバイス実装は、ユーザーが利用できるホーム機能と、戻る機能（UI_MODE_TYPE_WATCH のときを除く）を備えなければなりません。
Android Automotive 実装は、ホーム機能を提供しなければならず、戻る機能と履歴機能を提供しても構いません。
他のすべてのタイプのデバイス実装は、ホーム機能と戻る機能を提供しなければなりません。

これらの機能は、専用の物理ボタン（機械式または静電容量方式のタッチボタンなど）を介して実装しても構いません。または、画面の区分された部分の専用のソフトウェアキー、ジェスチャー、タッチパネルなどを使用して実装しても構いません。Android は両方の実装をサポートしています。これらの機能はすべて、表示されているときに、単一のアクション（タップ、ダブルクリック、ジェスチャーなど）でアクセスできなければなりません。

履歴機能（提供されている場合）は、全画面モードで他のナビゲーション機能とともに非表示になっている場合を除き、ボタンまたはアイコンを表示しなければなりません。この要件は、ナビゲーション用の物理ボタンがあって履歴キーがない以前の Android バージョンからアップグレードするデバイスには適用されません。

ホーム機能と戻る機能（提供されている場合）は、全画面モードで他のナビゲーション機能とともに非表示になっている場合、または uiMode UI_MODE_TYPE_MASK が UI_MODE_TYPE_WATCH に設定されている場合を除き、それぞれボタンまたはアイコンを表示しなければなりません。

Android 4.0 以降では、メニュー機能が非推奨になり、アクションバーに置き換えられました。そのため、Android 6.0 以降を搭載して出荷される新しいデバイス実装は、メニュー機能専用の物理ボタンを実装してはなりません。それより古いデバイス実装はメニュー機能専用の物理ボタンを実装するべきではありませんが、物理的なメニューボタンが実装されていてデバイスが targetSdkVersion > 10 のアプリを実行する場合、デバイス実装には以下の要件が適用されます。

アクションバーが表示され、その結果表示されるアクションオーバーフローメニューポップアップが空でないときは、アクションバーにアクションオーバーフローボタンを表示しなければなりません。この要件は、Android 4.4 より前にリリースされたが Android 6.0 にアップグレードするデバイス実装の場合は、推奨されます。
アクションバーのオーバーフローボタンを選択することで表示されるアクションオーバーフローポップアップの位置を変更してはなりません。
物理的なメニューボタンを選択することで表示されるときは、アクションオーバーフローポップアップを画面上の変更された位置にレンダリングしても構いません。

下位互換性を確保するため、デバイス実装は、targetSdkVersion が 10 未満のときは、物理ボタン、ソフトウェアキー、ジェスチャーのいずれかによって、メニュー機能をアプリで利用できるようにしなければなりません。このメニュー機能は、他のナビゲーション機能とともに非表示になっている場合を除き、表示すべきです。

アシストアクション [参考資料、30] をサポートする Android デバイス実装では、他のナビゲーションキーが表示されている場合、単一のアクション（タップ、ダブルクリック、ジェスチャーなど）で機能にアクセスできるようにしなければなりません。単一のアクションとしては、ホームボタンの長押しまたはソフトウェアキーの使用が強く推奨されます。

デバイス実装は、ナビゲーションキーを表示するために画面の区分けされた部分を使用しても構いませんが、その場合は以下の要件を満たさなければなりません。

デバイス実装のナビゲーションキーは、画面内のアプリが利用できない区分けされた部分を使用しなければなりません。また、画面内のアプリが利用できる部分を隠したり、その他の方法で利用を妨げたりしてはなりません。
デバイス実装は、セクション 7.1.1 で規定されている要件を満たすアプリがディスプレイの一部を利用できるようにしなければなりません。
アプリがシステム UI モードを指定していない場合、または SYSTEM_UI_FLAG_VISIBLE を指定している場合、デバイス実装はナビゲーションキーを表示しなければなりません。
アプリが SYSTEM_UI_FLAG_LOW_PROFILE を指定している場合、デバイス実装は、ナビゲーションキーを目立たない「ロープロファイル」（例: グレー表示）モードで表示しなければなりません。
アプリが SYSTEM_UI_FLAG_HIDE_NAVIGATION を指定している場合、デバイス実装はナビゲーションキーを非表示にしなければなりません。

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

Android ハンドヘルドデバイスと Android スマートウォッチデバイスは、タッチスクリーン入力をサポートしなければなりません。

デバイス実装は、なんらかのポインタ入力（マウスのような入力またはタップ入力）システムを備えるべきです。ただし、デバイス実装がポインタ入力システムをサポートしていない場合は、android.hardware.touchscreen または android.hardware.faketouch 機能定数をレポートしてはなりません。ポインタ入力システムを含むデバイス実装には、以下の要件が適用されます。

デバイス入力システムが複数のポインタをサポートする場合は、完全に独立してトラッキングされるポインタをサポートするべきです。
デバイス上の特定のタッチスクリーンのタイプに対応する android.content.res.Configuration.touchscreen [参考資料、85] の値を報告しなければなりません。

Android には、さまざまなタッチスクリーン、タッチパッド、疑似タップ入力デバイスのサポートが含まれています。タッチスクリーンベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるディスプレイ [参考資料、86] に関連付けられます。ユーザーが画面に直接触れているので、システムは操作中のオブジェクトを示す追加のアフォーダンスを必要としません。これに対して、疑似タップインターフェースは、タッチスクリーン機能のサブセットに似たユーザー入力システムを提供します。たとえば、画面上のカーソルを操作するマウスまたはリモコンはタップに近いですが、ユーザーは最初にポイントまたはフォーカスしてからクリックする必要があります。マウス、トラックパッド、ジャイロベースのエアマウス、ジャイロポインタ、ジョイスティック、マルチタッチトラックパッドなど、多くの入力デバイスが擬似タップインターフェースをサポートできます。Android には、機能定数 android.hardware.faketouch があります。これは、タップベースの入力を適切にエミュレートできる（そして基本的なジェスチャーをサポートする）マウスやトラックパッドなどの忠実度の高い非タップ式（ポインタベース）の入力デバイスに対応しており、タッチスクリーン機能のエミュレートされたサブセットをデバイスがサポートしていることを示します。疑似タップ機能を宣言するデバイス実装は、セクション 7.2.5 の疑似タップの要件を満たさなければなりません。

デバイス実装は、使用されている入力の種類に対応する正しい機能をレポートしなければなりません。タッチスクリーン（シングルタッチ以上）を含むデバイス実装は、プラットフォーム機能定数 android.hardware.touchscreen をレポートしなければなりません。プラットフォーム機能定数 android.hardware.touchscreen をレポートするデバイス実装は、プラットフォーム機能定数 android.hardware.faketouch もレポートしなければなりません。タッチスクリーンを含まない（そしてポインタデバイスのみに依存する）デバイス実装はタッチスクリーン機能をレポートしてはならず、セクション 7.2.5 の疑似タップの要件を満たす場合は android.hardware.faketouch のみをレポートしなければなりません。

7.2.5. 疑似タップ入力

android.hardware.faketouch のサポートを宣言するデバイス実装には、以下の要件が適用されます。

ポインタ位置の絶対 X 画面位置と絶対 Y 画面位置を報告し、画面にビジュアルポインタを表示しなければなりません [参考資料、87]。
ポインタが画面を上下に移動するときに発生する状態変化を指定するアクションコードで、タッチイベントを報告しなければなりません [参考資料、87]。
ユーザーが画面上のオブジェクトのタップをエミュレートできるように、画面上のオブジェクトでのポインタの上下移動をサポートしなければなりません。
ユーザーが画面上のオブジェクトのダブルタップをエミュレートできるように、時間しきい値内で、画面上のオブジェクトの同じ場所におけるポインタの下移動、ポインタの上移動、ポインタの下移動からの上移動をサポートしなければなりません [参考資料、87]。
ユーザーがタップドラッグをエミュレートできるように、画面上の任意の点におけるポインタの下移動、画面上の他の任意の点へのポインタ移動、その後のポインタの上移動をサポートしなければなりません。
ユーザーが画面上のオブジェクトをフリングできるように、ポインタの下移動をサポートし、ユーザーがオブジェクトを画面上の別の位置にすばやく移動してから画面上でポインタを上移動できるようにしなければなりません。

android.hardware.faketouch.multitouch.distinct のサポートを宣言するデバイスは、上記の疑似タップの要件を満たさなければならず、2 つ以上の独立したポインタ入力の個別のトラッキングもサポートしなければなりません。

7.2.6. ゲームコントローラのサポート

Android テレビデバイス実装は、下記のように、ゲームコントローラのボタンマッピングをサポートしなければなりません。アップストリームの Android 実装には、この要件を満たすゲームコントローラの実装が含まれています。

7.2.6.1. ボタンマッピング

Android テレビデバイス実装は、次のキーマッピングをサポートしなければなりません。

ボタン	HID 使用状況²	Android ボタン
A¹	0x09 0x0001	KEYCODE_BUTTON_A（96）
B¹	0x09 0x0002	KEYCODE_BUTTON_B（97）
X¹	0x09 0x0004	KEYCODE_BUTTON_X（99）
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y（100）
D-pad 上¹ D-pad 下¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad 左1 D-pad 右¹	0x01 0x0039³	AXIS_HAT_X⁴
左ショルダーボタン¹	0x09 0x0007	KEYCODE_BUTTON_L1（102）
右ショルダーボタン¹	0x09 0x0008	KEYCODE_BUTTON_R1（103）
左スティッククリック¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL（106）
右スティッククリック¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR（107）
ホーム¹	0x0c 0x0223	KEYCODE_HOME（3）
戻る¹	0x0c 0x0224	KEYCODE_BACK（4）

1 [参考資料、88]

2 上記の HID 使用状況は、ゲームパッド CA（0x01 0x0005）内で宣言しなければなりません。

3 この使用状況は、論理最小値 0、論理最大値 7、物理最小値 0、物理最大値 315、度単位、レポートサイズ 4 でなければなりません。論理値は、垂直軸から時計回りに定義されます。たとえば、論理値 0 は回転せず上ボタンが押されていることを表し、論理値 1 は 45 度回転し上キーと左キーの両方が押されていることを表します。

4 [参考資料、87]

アナログコントロール¹	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 [参考資料、87]

7.2.7. リモコン

Android テレビデバイス実装は、ユーザーがテレビインターフェースにアクセスできるようにリモコンを提供すべきです。リモコンは、物理的なリモコンでも、スマートフォンまたはタブレットからアクセスできるソフトウェアベースのリモコンでも構いません。リモコンは、下記の要件を満たさなければなりません。

検索アフォーダンス。デバイス実装は、ユーザーが物理リモコンまたはソフトウェアベースのリモコンで音声検索を呼び出したときに、KEYCODE_SEARCH（デバイスがアシスタントをサポートしている場合は KEYCODE_ASSIST）を起動しなければなりません。
ナビゲーション。すべての Android テレビのリモコンは、戻る、ホーム、選択の各ボタンと、D-pad イベントのサポートを含まれなければなりません [参考資料、88]。

7.3. センサー

Android には、さまざまな種類のセンサーにアクセスするための API があります。デバイス実装は、以降のサブセクションに示すとおり、通常、これらのセンサーを省略しても構いません。サードパーティデベロッパー向けの対応する API を持つ特定のセンサータイプがデバイスに含まれる場合、デバイス実装は、センサーに関する Android SDK ドキュメントと Android オープンソースドキュメントに記載されているとおり、その API を実装しなければなりません [参考資料、89]。たとえば、デバイス実装には以下の要件が適用されます。

android.content.pm.PackageManager クラス [参考資料、70] に基づいて、センサーの有無を正確に報告しなければなりません。
SensorManager.getSensorList() や同様のメソッドを介してサポート対象のセンサーの正確なリストを返さなければなりません。
他のすべてのセンサー API について合理的に動作しなければなりません（たとえば、アプリがリスナーの登録を試みたときは適切に true または false を返す、対応するセンサーが存在しないときはセンサーリスナーを呼び出さないなど）。
Android SDK ドキュメントで規定されているセンサータイプごとに、関連する国際単位系（メートル法）の値を使用してすべてのセンサー測定値を報告しなければなりません [参考資料、90]。
Android SDK ドキュメントで規定されているように、ナノ秒単位でイベント時刻を報告するべきです。これは、イベントが発生した時刻を表し、SystemClock.elapsedRealtimeNano() クロックと同期されます。既存と新規の Android デバイスは、これらの要件を満たすことが強く推奨されます。そうすれば、これが必須コンポーネントとなる将来のプラットフォームリリースへのアップグレードが可能になります。同期エラーは 100 ミリ秒未満であるべきです [参考資料、91]。
アプリプロセッサがアクティブであるとき、必須の最小レイテンシが 5 ms + 2 * sample_time のセンサーストリームの場合は、最大レイテンシ 100 ミリ秒 + 2 * sample_time のセンサーデータを報告しなければなりません。この遅延にフィルタリングの遅延は含まれません。
400 ミリ秒 + 2 *（アクティブになっているセンサーの sample_time）以内に最初のセンサーサンプルを報告しなければなりません。このサンプルの正確度は 0 でも許容されます。

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

一部のセンサータイプは複合型です。つまり、1 つ以上の他のセンサーによって提供されるデータから得られることがあります（そうしたセンサーには、方向センサーや直線加速度センサーがあります）。デバイス実装は、[参考資料、92] に記載されているとおり、必須の物理センサーを含む場合、これらのセンサータイプを実装するべきです。複合センサーが含まれる場合、デバイス実装は、複合センサーに関する Android オープンソースのドキュメント [参考資料、92] に記載されているセンサーを実装しなければなりません。

一部の Android センサーは、データを継続的に返す「連続」トリガーモードをサポートします [参考資料、93]。連続センサーであることが Android SDK ドキュメントで示されている API の場合、デバイス実装は、ジッターが 3% 未満であるべき定期データサンプルを継続的に提供しなければなりません（ジッターは、連続するイベント間で報告されるタイムスタンプ値の標準偏差として定義されます）。

なお、センサーイベントストリームは、デバイス CPU がサスペンド状態に入ること、またはサスペンド状態から復帰することを妨げてはならず、デバイス実装はそれを保証しなければなりません。

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

7.3.1. 加速度計

デバイス実装は、3 軸加速度計を含むべきです。Android ハンドヘルドデバイスと Android スマートウォッチデバイスは、このセンサーを含むことが強く推奨されます。3 軸加速度計を含むデバイス実装には、以下の要件が適用されます。

TYPE_ACCELEROMETER センサー [参考資料、94] を実装し、報告しなければなりません。
Android スマートウォッチデバイスでは、比較的厳しい電力制約があるため、周波数が少なくとも 50 Hz までのイベントを報告できなければならず、他のすべてのデバイスタイプでは、100 Hz までのイベントを報告できなければなりません。
少なくとも 200 Hz までのイベントを報告するべきです。
Android API で詳述されているとおり、Android センサー座標系に準拠しなければなりません [参考資料、90]。
どの軸でも、自由落下から重力の 4 倍（4g）以上まで測定できなければなりません。
解像度が少なくとも 12 ビットでなければならず、少なくとも 16 ビットであるべきです。
ライフサイクル中に特性が変化して補正される場合は使用中にキャリブレーションを行うべきであり、デバイスの再起動の間で補正パラメータを保持するべきです。
温度補正すべきです。
標準偏差が 0.05 m/s^ 以下でなければなりません。標準偏差は、最速サンプリングレートで少なくとも 3 秒間にわたって収集されたサンプルについて、軸ごとに計算するべきです。
Android SDK ドキュメントに記載されているように、TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、および TYPE_STEP_COUNTER 複合センサーを実装するべきです。既存と新規の Android デバイスは、TYPE_SIGNIFICANT_MOTION 複合センサーを実装することが強く推奨されます。これらのセンサーのいずれかを実装する場合は、消費電力の合計が常に 4 mW 未満でなければならず、デバイスが動的状態または静的状態にあるときは、それぞれ 2 mW 未満と 0.5 mW 未満であるべきです。
ジャイロスコープセンサーが含まれる場合は、TYPE_GRAVITY および TYPE_LINEAR_ACCELERATION 複合センサーを実装しなければならず、TYPE_GAME_ROTATION_VECTOR 複合センサーを実装するべきです。既存と新規の Android デバイスは、TYPE_GAME_ROTATION_VECTOR センサーを実装することが強く推奨されます。
ジャイロスコープセンサーと磁力計センサーも含まれる場合は、TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

7.3.2. 磁力計

デバイス実装は、3 軸磁力計（コンパス）を含むべきです。3 軸磁力計を含むデバイスには、以下の要件が適用されます。

TYPE_MAGNETIC_FIELD センサーを実装しなければならず、TYPE_MAGNETIC_FIELD_UNCALIBRATED センサーも実装するべきです。既存と新規の Android デバイスは、TYPE_MAGNETIC_FIELD_UNCALIBRATED センサーを実装することが強く推奨されます。
周波数が少なくとも 10 Hz までのイベントを報告できなければならず、少なくとも 50 Hz までのイベントを報告するべきです。
Android API で詳述されているとおり、Android センサー座標系に準拠しなければなりません [参考資料、90]。
飽和する前に各軸で -900 µT～+900 µT を測定できなければなりません。
磁力計を動的（電流誘導）磁場と静的（磁気誘導）磁場から離して配置することで、ハードアイアンオフセット値が 700 µT 未満でなければならず、200 µT 未満であるべきです。
分解能が 0.6 µT 以上でなければならず、0.2 µT 以上であるべきです。
温度補正すべきです。
ハードアイアンバイアスのオンラインのキャリブレーションと補正をサポートし、デバイスの再起動の前後で補正パラメータを保持しなければなりません。
ソフトアイアン補正を適用しなければなりません。キャリブレーションは、デバイスの使用中または製造中に行うことができます。
最速サンプリングレートで少なくとも 3 秒間にわたって収集されたサンプルについて軸ごとに計算された標準偏差が 0.5 µT 以下であるべきです。
加速度センサーとジャイロスコープセンサーも含まれる場合は、TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。
加速度センサーも実装される場合は、TYPE_GEOMAGNETIC_ROTATION_VECTOR センサーを実装しても構いません。ただし、実装するときは、センサーが 10 Hz でバッチモードに登録されている場合、消費電力が 10 mW 未満でなければならず、3 mW 未満であるべきです。

7.3.3. GPS

デバイス実装は、GPS レシーバーを含むべきです。GPS レシーバーが含まれる場合、デバイス実装は、GPS ロックオン時間を最小化するために、なんらかの「アシスト GPS」技術を含むべきです。

7.3.4. ジャイロスコープ

デバイス実装は、ジャイロスコープ（角度変化センサー）を含むべきです。デバイスは、3 軸加速度計も含む場合を除き、ジャイロスコープセンサーを含むべきではありません。デバイス実装がジャイロスコープを含む場合は、以下の要件が適用されます。

TYPE_GYROSCOPE センサーを実装しなければならず、TYPE_GYROSCOPE_UNCALIBRATED センサーも実装するべきです。既存と新規の Android デバイスは、SENSOR_TYPE_GYROSCOPE_UNCALIBRATED センサーを実装することが強く推奨されます。
最大で毎秒 1,000 度の方向変化を測定できなければなりません。
Android スマートウォッチデバイスでは、比較的厳しい電力制約があるため、周波数が少なくとも 50 Hz までのイベントを報告できなければならず、他のすべてのデバイスタイプでは、100 Hz までのイベントを報告できなければなりません。
少なくとも 200 Hz までのイベントをレポートすべきです。
分解能が 12 ビット以上でなければならず、16 ビット以上であるべきです。
温度補正を行わなければなりません。
使用中にキャリブレーションと補正を行い、デバイスの再起動の間で補正パラメータを保持しなければなりません。
分散が Hz あたり 1e-7 rad^2/s^2（Hz あたりの分散、つまり rad^2/s）以下でなければなりません。分散はサンプリングレートによって異なることが許容されますが、この値の制約を受けなければなりません。言い換えると、サンプリングレート 1 Hz でジャイロの分散を測定した場合、その値は 1e-7 rad^2/s^2 以下であるべきです。
加速度計センサーと磁力計センサーも含まれる場合は、TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。
加速度センサーが含まれる場合は、TYPE_GRAVITY および TYPE_LINEAR_ACCELERATION 複合センサーを実装しなければならず、TYPE_GAME_ROTATION_VECTOR 複合センサーを実装するべきです。既存と新規の Android デバイスは、TYPE_GAME_ROTATION_VECTOR センサーを実装することが強く推奨されます。

7.3.5. 気圧計

デバイス実装は、気圧計（大気圧センサー）を含むべきです。デバイス実装が気圧計を含む場合は、以下の要件が適用されます。

TYPE_PRESSURE センサーを実装し、レポートしなければなりません。
5 Hz 以上でイベントを配信できなければなりません。
標高を推定するのに十分な精度がなければなりません。
温度補正しなければなりません。

7.3.6. 温度計

デバイス実装は、周囲温度計（温度センサー）を含んでも構いません。周囲温度計が存在する場合は、SENSOR_TYPE_AMBIENT_TEMPERATURE として定義されなければならず、周囲温度（室温）を摂氏で測定しなければなりません。

デバイス実装は、CPU 温度センサーを含んでも構いませんが、含むべきではありません。存在する場合、SENSOR_TYPE_TEMPERATURE として定義されなければなりません。また、デバイスの CPU の温度を測定しなければならず、それ以外の温度を測定してはなりません。なお、SENSOR_TYPE_TEMPERATURE センサータイプは Android 4.0 で非推奨になりました。

7.3.7. 光度計

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

7.3.8. 近接センサー

デバイス実装は、近接センサーを含んでも構いません。音声通話が可能で、getPhoneType に PHONE_TYPE_NONE 以外の値を示すことができるデバイスは、近接センサーを含むべきです。近接センサーを含むデバイス実装には、以下の要件が適用されます。

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

7.3.9. ハイファイセンサー

このセクションに記載されている要件をすべて満たす、一連の高品質センサーをサポートするデバイス実装は、android.hardware.sensor.hifi_sensors 機能フラグを通じてサポートを識別しなければなりません。

android.hardware.sensor.hifi_sensors を宣言するデバイスは、以下の品質要件を満たすセンサータイプをすべてサポートしなければなりません。

SENSOR_TYPE_ACCELEROMETER
- 測定範囲が少なくとも -8g～+8g でなければなりません。
- 測定解像度が少なくとも 1,024 LSB/G でなければなりません。
- 最小測定周波数が 12.5 Hz 以下でなければなりません。
- 最大測定周波数が 200 Hz 以上でなければなりません。
- 測定雑音が 400 uG/√Hz 以下でなければなりません。
- 少なくとも 3,000 件のセンサーイベントをバッファリングできる、このセンサーの非ウェイクアップフォームを実装しなければなりません。
- 計量消費電力が 3 mW 以下でなければなりません。
SENSOR_TYPE_GYROSCOPE
- 測定範囲が少なくとも -1,000～+1,000 dps でなければなりません。
- 測定解像度が少なくとも 16 LSB/dps でなければなりません。
- 最小測定周波数が 12.5 Hz 以下でなければなりません。
- 最大測定周波数が 200 Hz 以上でなければなりません。
- 測定雑音が 0.014°/s/√Hz 以下でなければなりません。
SENSOR_TYPE_GYROSCOPE と同じ品質要件の SENSOR_TYPE_GYROSCOPE_UNCALIBRATED
SENSOR_TYPE_GEOMAGNETIC_FIELD
- 測定範囲が少なくとも -900～+900 uT でなければなりません。
- 測定解像度が少なくとも 5 LSB/uT でなければなりません。
- 最小測定周波数が 5 Hz 以下でなければなりません。
- 最大測定周波数が 50 Hz 以上でなければなりません。
- 測定雑音が 0.5 uT 以下でなければなりません。
SENSOR_TYPE_GEOMAGNETIC_FIELD と同じ品質要件であることに加え、次の条件を満たす SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED:
- 少なくとも 600 件のセンサーイベントをバッファリングできる、このセンサーの非ウェイクアップフォームを実装しなければなりません。
SENSOR_TYPE_PRESSURE
- 測定範囲が少なくとも 300～1,100 hPa でなければなりません。
- 測定解像度が少なくとも 80 LSB/hPa でなければなりません。
- 最小測定周波数が 1 Hz 以下でなければなりません。
- 最大測定周波数が 10 Hz 以上でなければなりません。
- 測定雑音が 2 Pa/√Hz 以下でなければなりません。
- 少なくとも 300 件のセンサーイベントをバッファリングできる、このセンサーの非ウェイクアップフォームを実装しなければなりません。
- 計量消費電力が 2 mW 以下でなければなりません。
TYPE_GAME_ROTATION_VECTOR
- 少なくとも 300 件のセンサーイベントをバッファリングできる、このセンサーの非ウェイクアップフォームを実装しなければなりません。
- 計量消費電力が 4 mW 以下でなければなりません。
SENSOR_TYPE_SIGNIFICANT_MOTION
- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
SENSOR_TYPE_STEP_DETECTOR
- 少なくとも 100 件のセンサーイベントをバッファリングできる、このセンサーの非ウェイクアップフォームを実装しなければなりません。
- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
- 計量消費電力が 4 mW 以下でなければなりません。
SENSOR_TYPE_STEP_COUNTER
- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
SENSOR_TILT_DETECTOR
- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。

また、そのようなデバイスは、以下のセンサーサブシステム要件を満たさなければなりません。

加速度計、ジャイロスコープセンサー、磁力計が報告する同じ物理イベントのイベントタイムスタンプが、互いに 2.5 ミリ秒以内でなければなりません。
ジャイロスコープセンサーのイベントタイムスタンプは、カメラのサブシステムと同じタイムベースであり、誤差 1 ミリ秒以内でなければなりません。
物理センサーハードウェアでデータが利用可能になってから、サンプルを HAL に配信するまでのレイテンシは、5 ミリ秒未満であるべきです。
以下のセンサーの組み合わせが有効にされているとき、消費電力は、デバイス静止時は 0.5 mW 以下、デバイス移動時は 2.0 mW 以下でなければなりません。
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS

なお、このセクションの消費電力要件はすべて、アプリプロセッサの消費電力を含みません。センサーチェーン全体（センサー、補助回路、専用のセンサー処理システムなど）によって消費される電力が含まれます。

次のセンサータイプは、android.hardware.sensor.hifi_sensors を宣言するデバイス実装でサポートしても構いませんが、これらのセンサータイプが存在する場合、次の最小バッファリング機能要件を満たさなければなりません。

SENSOR_TYPE_PROXIMITY: 100 件のセンサーイベント

7.3.10. 指紋認証センサー

セキュアロック画面を備えたデバイス実装は、指紋認証センサーを含むべきです。デバイス実装が指紋認証センサーを含み、サードパーティデベロッパー向けの対応する API が存在する場合は、以下の要件が適用されます。

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

7.4. データ接続

7.4.1. 電話

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

Android は、電話ハードウェアを含まないデバイスで使用しても構いません。つまり、Android はスマートフォンではないデバイスに対応しています。ただし、デバイス実装に GSM または CDMA の電話が含まれる場合、その技術の API の完全なサポートを実装しなければなりません。電話ハードウェアを含まないデバイス実装は、完全な API を NoOps として実装しなければなりません。

7.4.2. IEEE 802.11（Wi-Fi）

Android テレビデバイス実装は、Wi-Fi サポートを含まなければなりません。

Android テレビデバイス実装は、1 つ以上の形式の 802.11（b/g/a/n など）のサポートを含まなければならず、他のタイプの Android デバイス実装は、1 つ以上の形式の 802.11 のサポートを含むべきです。802.11 のサポートが含まれ、その機能をサードパーティアプリに公開する場合、デバイス実装は、対応する Android API を実装しなければならず、以下の要件も適用されます。

ハードウェア機能フラグ android.hardware.wifi を報告しなければなりません。
SDK ドキュメント [参考資料、97] に記載されているとおり、マルチキャスト API を実装しなければなりません。
マルチキャスト DNS（mDNS）をサポートしなければならず、以下の場合を含むいかなる運用時にも mDNS パケット（224.0.0.251）をフィルタしてはなりません。
- 画面がアクティブ状態でないとき。
- Android テレビデバイス実装の場合、スタンバイ電力状態にあるとき。

7.4.2.1. Wi-Fi Direct

デバイス実装は、Wi-Fi Direct（Wi-Fi ピアツーピア）をサポートするべきです。Wi-Fi Direct をサポートする場合、デバイス実装は、SDK ドキュメント [参考資料、98] に記載されているとおり、対応する Android API を実装しなければなりません。デバイス実装が Wi-Fi Direct のサポートを含む場合は、以下の要件が適用されます。

ハードウェア機能 android.hardware.wifi.direct をレポートしなければなりません。
通常の Wi-Fi 運用をサポートしなければなりません。
Wi-Fi と Wi-Fi Direct の同時使用をサポートすべきです。

7.4.2.2. Wi-Fi Tunneled Direct Link Setup

Android テレビデバイス実装は、Wi-Fi Tunneled Direct Link Setup（TDLS）のサポートを含まなければなりません。

Android テレビデバイス実装は、Wi-Fi Tunneled Direct Link Setup（TDLS）のサポートを含まなければならず、他のタイプの Android デバイス実装は、Android SDK ドキュメント [参考資料、99] に記載されているとおり、Wi-Fi TDLS のサポートを含むべきです。TDLS のサポートが含まれ、WiFiManager API で TDLS が有効になっている場合、デバイス実装には以下の要件が適用されます。

可能かつ有効な場合にのみ、TDLS を使用すべきです。
TDLS のパフォーマンスが Wi-Fi アクセスポイントを通過する場合よりも悪くなる可能性がある場合は、TDLS を使用せず、なんらかのヒューリスティックを使用するべきです。

7.4.3. Bluetooth

Android スマートウォッチ実装と Android Automotive 実装は、Bluetooth をサポートしなければなりません。Android テレビ実装は、Bluetooth と Bluetooth LE をサポートしなければなりません。

Android は、Bluetooth と Bluetooth Low Energy をサポートしています [参考資料、100]。Bluetooth と Bluetooth Low Energy のサポートを含むデバイス実装は、関連するプラットフォーム機能（それぞれ android.hardware.bluetooth と android.hardware.bluetooth_le）を宣言し、そのプラットフォーム API を実装しなければなりません。デバイス実装は、デバイスに応じて、A2DP、AVCP、OBEX など、関連する Bluetooth プロファイルを実装すべきです。Android テレビデバイス実装は、Bluetooth と Bluetooth LE をサポートしなければなりません。

Bluetooth Low Energy のサポートを含むデバイス実装には、以下の要件が適用されます。

ハードウェア機能 android.hardware.bluetooth_le を宣言しなければなりません。
SDK ドキュメントと [参考資料、100] に記載されているとおり、GATT（汎用属性プロファイル）ベースの Bluetooth API を有効にしなければなりません。
ユーザーのプライバシーを保護するために、15 分以下の解決可能なプライベートアドレス（RPA）タイムアウトを実装し、タイムアウト時にアドレスをローテーションすることが強く推奨されます。
ScanFilter API [参考資料、101] を実装するときは、Bluetooth チップセットに対するフィルタリングロジックのオフロードをサポートするべきであり、android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() メソッドを通じてクエリされたときはフィルタリングロジックが実装されている場所の正しい値を常に報告しなければなりません。
Bluetooth チップセットに対するバッチスキャンのオフロードをサポートするべきですが、サポートしない場合、android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() メソッドを通じてクエリされたときは常に「false」を報告しなければなりません。
少なくとも 4 つのスロットでマルチアドバタイズメントをサポートするべきですが、サポートしない場合、android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() メソッドを通じてクエリされたときは常に「false」を報告しなければなりません。

7.4.4. 近距離無線通信

デバイス実装は、近距離無線通信（NFC）用の送受信機と関連ハードウェアを含むべきです。NFC ハードウェアを含み、サードパーティアプリで利用可能にする予定のデバイス実装には、以下の要件が適用されます。

android.content.pm.PackageManager.hasSystemFeature() メソッド [参考資料、70] から android.hardware.nfc 機能を報告しなければなりません。
次の NFC 規格を介して、NDEF メッセージの読み取りと書き込みができなければなりません。
- 次の 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（NFC フォーラムにより定義）
- 次の NFC 規格を介して NDEF メッセージと元データを読み書きできることが強く推奨されます。なお、以下の NFC 規格は「強く推奨される」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。これらの規格は、このバージョンでは任意ですが、今後のバージョンでは必須となります。このバージョンの Android を搭載した既存または新規のデバイスは現在、今後のプラットフォームリリースにアップグレードできるよう、これらの要件を満たすことが極めて強く奨励されています。
  - NfcV（ISO 15693）
- Thinfilm NFC Barcode [参考資料、102] プロダクトのバーコードと URL（エンコードされている場合）の読み取りができるべきです。
- 次のピアツーピア規格とプロトコルを介してデータを送受信できなければなりません。
  - ISO 18092
  - LLCP 1.2（NFC フォーラムにより定義）
  - SDP 1.0（NFC フォーラムにより定義）
  - NDEF プッシュプロトコル [参考資料、103]
  - SNEP 1.0（NFC フォーラムにより定義）
- Android ビーム [参考資料、104] のサポートを含まなければなりません。
  - SNEP デフォルトサーバーを実装しなければなりません。デフォルトの SNEP サーバーが受信した有効な NDEF メッセージは、android.nfc.ACTION_NDEF_DISCOVERED インテントを使用してアプリにディスパッチされなければなりません。設定で Android ビームを無効にすることにより、受信 NDEF メッセージのディスパッチを無効にしてはなりません。
  - android.settings.NFCSHARING_SETTINGS インテントを尊重して、NFC 共有設定 [参考資料、105] を表示しなければなりません。
  - NPP サーバーを実装しなければなりません。NPP サーバーが受信するメッセージは、SNEP のデフォルトサーバーと同じ方法で処理しなければなりません。
  - Android ビームが有効になっているときは、SNEP クライアントを実装し、送信 P2P NDEF のデフォルトの SNEP サーバーへの送信を試行しなければなりません。デフォルトの SNEP サーバーが見つからない場合、クライアントは NPP サーバーへの送信を試行しなければなりません。
  - フォアグラウンドアクティビティが、android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback、android.nfc.NfcAdapter.enableForegroundNdefPush を使用して、送信 P2P NDEF メッセージを設定できるようにしなければなりません。
  - 送信 P2P NDEF メッセージを送信する前に、「タップしてビーム」などのジェスチャーまたは画面上の確認を使用すべきです。
  - Android ビームをデフォルトで有効にすべきであり、別の独自の NFC P2p モードがオンになっていても、Android ビームを使用して送受信ができなければなりません。
  - デバイスが Bluetooth オブジェクトプッシュプロファイルをサポートしている場合は、Bluetooth への NFC 接続ハンドオーバーをサポートしなければなりません。デバイス実装は、android.nfc.NfcAdapter.setBeamPushUris を使用する場合、NFC フォーラムの「Connection Handover バージョン 1.2」仕様 [参考資料、106] と「Bluetooth Secure Simple Pairing Using NFC バージョン 1.0」仕様 [参考資料、107] を実装して、Bluetooth への接続ハンドオーバーをサポートしなければなりません。このような実装では、NFC を介してハンドオーバーリクエスト / 選択レコードを交換するために、サービス名「urn:nfc:sn:handover」を持つハンドオーバー LLCP サービスを実装しなければならず、実際の Bluetooth データ転送には Bluetooth オブジェクトプッシュプロファイルを使用しなければなりません。従来の理由（Android 4.1 デバイスとの互換性を維持する）のために、実装では NFC を介してハンドオーバーリクエスト / 選択レコードを交換するために SNEP GET リクエストを引き続き受け入れるべきです。ただし、実装自体が、接続ハンドオーバーを行うための SNEP GET リクエストを送信すべきではありません。
- NFC 検出モードのときは、サポートされているすべての技術をポーリングしなければなりません。
- 画面がアクティブ、ロック画面がロック解除された状態でデバイスが起動しているときは、NFC 検出モードになっているべきです。

（なお、上記の JIS、ISO、NFC フォーラムの仕様について、一般公開されているリンクはありません）。

Android は、NFC ホストカードエミュレーション（HCE）モードをサポートしています。HCE とアプリケーション ID（AID）ルーティングの機能がある NFC コントローラが含まれる場合、デバイス実装には以下の要件が適用されます。

android.hardware.nfc.hce 機能定数を報告しなければなりません。
Android SDK で定義されているとおり、NFC HCE API をサポートしなければなりません [参考資料、108]。

さらに、デバイス実装は、以下の MIFARE 技術のリーダー / ライターをサポートしても構いません。

MIFARE Classic
MIFARE Ultralight
MIFARE Classic の NDEF

なお、Android には、これらの MIFARE タイプ用の API が含まれています。リーダー / ライターの役割で MIFARE をサポートする場合、デバイス実装には以下の要件が適用されます。

Android SDK ドキュメントに記載されているように、対応する Android API を実装しなければなりません。
android.content.pm.PackageManager.hasSystemFeature() メソッド [参考資料、70] から機能 com.nxp.mifare を報告しなければなりません。なお、これは Android の標準の機能ではないため、android.content.pm.PackageManager クラスの定数としては表示されません。
このセクションに記載されているように、一般的な NFC サポートも実装しない限り、対応する Android API を実装してはならず、com.nxp.mifare 機能を報告してはなりません。

NFC ハードウェアが含まれない場合、デバイス実装は android.content.pm.PackageManager.hasSystemFeature() メソッドから android.hardware.nfc 機能を宣言してはなりません [参考資料、70]。また、Android NFC API を NoOps として実装しなければなりません。

android.nfc.NdefMessage クラスと android.nfc.NdefRecord クラスはプロトコルに依存しないデータ表現形式を表すため、デバイス実装は NFC のサポートを含まない場合または android.hardware.nfc 機能を宣言していない場合でも、これらの API を実装しなければなりません。

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

デバイス実装は、1 つ以上の形式のデータネットワーキングのサポートを含まなければなりません。具体的には、デバイス実装は、200 kbps 以上の能力を持つ、少なくとも 1 つのデータ標準のサポートを含まなければなりません。この要件を満たす技術の例としては、EDGE、HSPA、EV-DO、802.11g、イーサネット、Bluetooth PAN が挙げられます。

物理ネットワーキング標準（イーサネットなど）がプライマリデータ接続になっているデバイス実装は、802.11（Wi-Fi）などの一般的なワイヤレスデータ標準も少なくとも 1 つサポートすべきです。

デバイスは、複数の形式のデータ接続を実装しても構いません。

IPv6 ネットワークスタックを含まなければならず、java.net.Socket や java.net.URLConnection などの管理 API と、AF_INET6 ソケットなどのネイティブ API を使用した IPv6 通信をサポートしなければなりません。必要な IPv6 サポートレベルは、ネットワークの種類に応じて次のように異なります。

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

IPv6 をデフォルトで有効にしなければなりません。

IPv6 通信の信頼性を IPv4 と同等にするため、画面がアクティブな状態でなくても、デバイスに送信されるユニキャスト IPv6 パケットを取りこぼしてはなりません。同じルーターアドバタイズメントが繰り返されるような冗長なマルチキャスト IPv6 パケットは、電力の節約のために必要であれば、ハードウェアまたはファームウェアでレート制限を行っても構いません。そのような場合、少なくとも 180 秒の RA ライフタイムを使用する IPv6 準拠ネットワークで、レート制限によってデバイスの IPv6 接続が失われてはなりません。

IPv6 接続は Doze モードで維持しなければなりません。

7.4.6. 同期設定

デバイス実装は、メソッド getMasterSyncAutomatically() が「true」を返すように、マスター自動同期設定をデフォルトでオンにしなければなりません [参考資料、109]。

7.5. カメラ

デバイス実装は背面カメラを含むべきであり、前面カメラを含んでも構いません。背面カメラとは、デバイスのディスプレイとは反対側に配置されたカメラのことです。つまり、従来のカメラのようにデバイスの向こう側の光景を撮影するものです。前面カメラとは、デバイスのディスプレイと同じ側に配置されたカメラのことです。つまり、通常はビデオ会議や類似のアプリなどでユーザーを撮影するために使用されるカメラです。

少なくとも 1 つのカメラが含まれる場合、デバイス実装は、デバイスの最大解像度のカメラセンサーによって生成された画像のサイズに等しい 3 つのビットマップを、アプリが同時に割り当てられるようにするべきです。

7.5.1. 背面カメラ

デバイス実装は背面カメラを含むべきです。背面カメラが 1 つ以上含まれる場合、デバイス実装は:

機能フラグ android.hardware.camera と android.hardware.camera.any をレポートしなければなりません。
解像度が少なくとも 2 メガピクセルでなければなりません。
カメラドライバでハードウェアオートフォーカスまたはソフトウェアオートフォーカスを実装すべきです（アプリソフトウェアに対して透過的）。
固定フォーカスまたは EDOF（拡張被写界深度）のハードウェアがあっても構いません。
フラッシュを含んでも構いません。カメラがフラッシュを含む場合、android.hardware.Camera.PreviewCallback インスタンスがカメラプレビューサーフェスに登録されている間は、アプリが Camera.Parameters オブジェクトの FLASH_MODE_AUTO 属性または FLASH_MODE_ON 属性を有効にすることによってフラッシュを明示的に有効にしていない限り、フラッシュランプを点灯してはなりません。なお、この制約は、デバイスの内蔵システムカメラアプリには適用されず、Camera.PreviewCallback を使用するサードパーティアプリにのみ適用されます。

7.5.2. 前面カメラ

デバイス実装は前面カメラを含んでも構いません。前面カメラが 1 つ以上含まれる場合、デバイス実装は:

機能フラグ android.hardware.camera.any と android.hardware.camera.front をレポートしなければなりません。
解像度が少なくとも VGA（640x480 ピクセル）でなければなりません。
前面カメラを Camera API のデフォルトとして使用してはなりません。Android の Camera API には前面カメラに対する特定のサポートが含まれており、デバイス実装は、たとえデバイス上の唯一のカメラであったとしても、前面カメラをデフォルトの背面カメラとして扱うように API を構成してはなりません。
セクション 7.5.1 に記載されているとおり、背面カメラで利用できる機能（オートフォーカス、フラッシュなど）を含めても構いません。
次に示すように、カメラプレビューで、アプリによって表示されるストリームを水平方向に反映（つまりミラーリング）しなければなりません。
- デバイス実装がユーザーによる回転（たとえば、加速度計による自動的な回転またはユーザー入力による手動の回転）に対応している場合は、デバイスの現在の向きに対して水平にカメラプレビューをミラーリングしなければなりません。
- 現在のアプリが、android.hardware.Camera.setDisplayOrientation() メソッド [参考資料、110] を呼び出してカメラディスプレイの回転を明示的にリクエストした場合は、アプリが指定した向きに対して水平にカメラプレビューをミラーリングしなければなりません。
- それ以外の場合は、デバイスのデフォルトの水平軸に沿ってプレビューをミラーリングしなければなりません。
カメラプレビューの画像ストリームと同じ方法で、ポストビューで表示される画像をミラーリングしなければなりません。デバイス実装がポストビューをサポートしていない場合、この要件は明確には適用されません。
アプリのコールバックに対して返されたか、メディアストレージに対してコミットされた、キャプチャした最終的な静止画または動画のストリームをミラーリングしてはなりません。

7.5.3. 外部カメラ

USB ホストモードを備えたデバイス実装は、USB ポートに接続する外部カメラのサポートを含んでも構いません。外部カメラのサポートが含まれる場合、デバイスは:

プラットフォーム機能 android.hardware.camera.external と android.hardware camera.any を宣言しなければなりません。
USB 動画クラス（UVC 1.0 以降）をサポートしなければなりません。
複数のカメラをサポートしても構いません。

高品質な未エンコードストリーム（つまり、未加工または個別に圧縮された画像ストリーム）の転送を可能にするために、動画圧縮（MJPEG など）のサポートが推奨されます。カメラベースの動画エンコードをサポートしても構いません。サポートする場合は、同時未エンコード / MJPEG ストリーム（解像度 QVGA 以上）がデバイス実装からアクセス可能でなければなりません。

7.5.4. カメラ API の動作

Android には、カメラにアクセスするための API パケージが 2 つあります。新しい android.hardware.camera2 API は、下位レベルのカメラ制御をアプリに公開します。これには、効率的なゼロコピーバースト / ストリーミングフローと、フレームごとの露出、ゲイン、ホワイトバランスゲイン、色変換、ノイズ除去、シャープニングの制御が含まれます。

古い API パッケージ android.hardware.Camera は Android 5.0 で非推奨としてマークされましたが、引き続きアプリで使用できるべきであるため、Android デバイス実装は、このセクションと Android SDK ドキュメントに記載されているように、この API の継続的なサポートを保証しなければなりません。

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

アプリで android.hardware.Camera.Parameters.setPreviewFormat(int) が一度も呼び出されていない場合、デバイスはアプリのコールバックに提供されるプレビューデータに android.hardware.PixelFormat.YCbCr_420_SP を使用しなければなりません。
アプリが android.hardware.Camera.PreviewCallback インスタンスを登録し、プレビュー形式が YCbCr_420_SP のときに onPreviewFrame() メソッドを呼び出す場合、onPreviewFrame() に渡される byte[] のデータは NV21 エンコード形式でなければなりません。つまり、NV21 がデフォルトでなければなりません。
android.hardware.Camera については、デバイス実装は、前面カメラと背面カメラの両方のカメラプレビュー用に YV12 形式（android.graphics.ImageFormat.YV12 定数で示されます）をサポートしなければなりません（ハードウェア動画エンコーダとカメラは任意のネイティブピクセル形式を使用できますが、デバイス実装は YV12 への変換をサポートしなければなりません）。
android.hardware.camera2 の場合、デバイス実装は、android.media.ImageReader API を介して出力として android.hardware.ImageFormat.YUV_420_888 形式と android.hardware.ImageFormat.JPEG 形式をサポートしなければなりません。

デバイス実装は、デバイスにハードウェアオートフォーカスなどの機能があるかどうかにかかわらず、引き続き Android SDK のドキュメント [参考資料、111] に含まれる Camera API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、（オートフォーカスのないカメラには関係がなくとも）登録された android.hardware.Camera.AutoFocusCallback インスタンスを引き続き呼び出さなければなりません。なお、これは前面カメラに適用されます。たとえば、前面カメラはたいていの場合オートフォーカスをサポートしていませんが、それでも前述のように API コールバックを「偽装」しなければなりません。

デバイス実装は、基盤となるハードウェアがこの機能をサポートしている場合、android.hardware.Camera.Parameters クラスの定数として定義された各パラメータ名を認識し、尊重しなければなりません。デバイスハードウェアが機能をサポートしていない場合、API はドキュメントに記載されているとおりに動作しなければなりません。逆に、デバイス実装は android.hardware.Camera.Parameters で定数として記述されているもの以外の文字列定数が android.hardware.Camera.setParameters() メソッドに渡されても、それを尊重したり認識したりしてはなりません。つまり、デバイス実装は、ハードウェアが許すならば標準的なカメラパラメータをすべてサポートしなければならず、カスタムのカメラパラメータタイプをサポートしてはなりません。たとえば、ハイダイナミックレンジ（HDR）画像処理手法を使用する画像キャプチャをサポートするデバイス実装は、カメラパラメータ Camera.SCENE_MODE_HDR [参考資料、112] をサポートしなければなりません。

すべてのデバイス実装が android.hardware.camera2 API のすべての機能を完全にサポートしているわけではないため、デバイス実装は、Android SDK [参考資料、113] に記載されているとおり、android.info.supportedHardwareLevel プロパティで適切なサポートレベルを報告し、該当するフレームワーク機能フラグ [参考資料、114] を報告しなければなりません。

また、デバイス実装は、android.request.availableCapabilities プロパティを介して android.hardware.camera2 の個々のカメラ機能を宣言し、該当する機能フラグ [参考資料、114] を宣言しなければなりません。装着されているカメラデバイスのいずれかが機能をサポートしている場合は機能フラグを定義しなければなりません。

デバイス実装は、カメラで新しい画像が撮影され、画像のエントリがメディアストアに追加されたときは常に、Camera.ACTION_NEW_PICTURE インテントをブロードキャストしなければなりません。

デバイス実装は、カメラで新しい動画が録画され、画像のエントリがメディアストアに追加されたときは常に、Camera.ACTION_NEW_VIDEO インテントをブロードキャストしなければなりません。

7.5.5. カメラの向き

前面カメラと背面カメラは（存在する場合）、カメラの長辺が画面の長辺と揃うように向きを調整しなければなりません。つまり、デバイスが横向きで保持されている場合、カメラは横向きで画像をキャプチャしなければなりません。これは、デバイスの自然な向きに関係なく適用されます。つまり、横向き主体のデバイスと、縦向き主体のデバイスに適用されます。

7.6. メモリとストレージ

7.6.1. 最小のメモリとストレージ

Android テレビデバイスには、アプリの個人データに使用できる不揮発性ストレージが少なくとも 5 GB 存在しなければなりません。

デバイス実装のカーネルとユーザー空間に使用できるメモリは、次の表で指定される最小値以上でなければなりません（画面サイズと画面密度の定義については、セクション 7.1.1 をご覧ください）。

密度と画面サイズ	32 ビットデバイス	64 ビットデバイス
Android スマートウォッチデバイス（画面が小さいため）	416 MB	該当なし
小 / 標準画面で 280 dpi 以下大画面で mdpi 以下特大画面で ldpi 以下	424 MB	704 MB
小 / 標準画面で xhdpi 以上大画面で hdpi 以上特大画面で mdpi 以上	512 MB	832 MB
小 / 標準画面で 400 dpi 以上大画面で xhdpi 以上特大画面で tvdpi 以上	896 MB	1280 MB
小 / 標準画面で 560 dpi 以上大画面で 400 dpi 以上特大画面で xhdpi 以上	1344 MB	1824 MB

最小メモリ値は、カーネルの制御下にない無線や動画などのハードウェアコンポーネント専用のメモリ空間とは別に設定しなければなりません。

Android スマートウォッチを除き、カーネルとユーザー空間に利用できるメモリが 512 MB 未満のデバイス実装は、ActivityManager.isLowRamDevice() に「true」の値を返さなければなりません。

アプリの個人データに使用できる不揮発性ストレージは、Android テレビデバイスでは少なくとも 5 GB 存在しなければならず、他のデバイス実装では少なくとも 1.5 GB 存在しなければなりません。つまり、/data パーティションは、Android テレビデバイスでは少なくとも 5 GB、他のデバイス実装では少なくとも 1.5 GB でなければなりません。Android を搭載するデバイス実装には、今後のプラットフォームリリースにアップグレードできるよう、アプリの個人データ用に不揮発性ストレージを 3 GB 以上用意することが強く推奨されます。

Android API は、アプリがデータファイルをダウンロードするために使用できるダウンロードマネージャーを備えています [参考資料、115]。ダウンロードマネージャーのデバイス実装は、サイズが 100 MB 以上の個々のファイルをデフォルトの「キャッシュ」場所にダウンロードできなければなりません。

7.6.2. アプリ共有ストレージ

デバイス実装は、アプリ用の共有ストレージ（「共有外部ストレージ」とも呼ばれます）を提供しなければなりません。

デバイス実装は、デフォルトでマウントされる共有ストレージをすぐに使えるように構成しなければなりません。共有ストレージが Linux パス /sdcard にマウントされない場合、デバイスは /sdcard から実際のマウントポイントへの Linux シンボリックリンクを含まなければなりません。

デバイス実装は、セキュアデジタル（SD）カードスロットなど、ユーザーによるアクセスが可能なリムーバブルストレージのハードウェアを備えていても構いません。デバイス実装がこのスロットを使用して共有ストレージ要件を満たす場合は、以下の要件が適用されます。

SD カードがないときにユーザーに警告する、トーストまたはポップアップのユーザーインターフェースを実装しなければなりません。
1 GB 以上の FAT フォーマット済み SD カードを同梱するか、箱や購入時に入手できるその他の資料に、SD カードを別途購入する必要があることを表示しなければなりません。
デフォルトで SD カードをマウントしなければなりません。

あるいは、デバイス実装は、アップストリームの Android オープンソースプロジェクトに含まれているように、アプリ用の共有ストレージとして内部（非リムーバブル）ストレージを割り当てても構いません。デバイス実装は、この構成とソフトウェア実装を使用するべきです。デバイス実装が共有ストレージ要件を満たすために内部（非リムーバブル）ストレージを使用する場合、そのストレージはアプリの個人データとスペースを共有しても構いませんが、少なくとも 1 GB のサイズを持ち、/sdcard にマウントされなければなりません（別の場所にマウントされる場合は、/sdcard がその物理的ロケーションへのシンボリックリンクでなければなりません）。

デバイス実装は、この共有ストレージに対する android.permission.WRITE_EXTERNAL_STORAGE 権限を、ドキュメントに記載されているとおりに適用しなければなりません。そうしない場合、共有ストレージは、その権限を取得するすべてのアプリから書き込み可能でなければなりません。

複数の共有ストレージパス（SD カードスロットと共有内部ストレージの両方など）を含むデバイス実装は、WRITE_EXTERNAL_STORAGE 権限を持つプリインストール済みの特権 Android アプリのみに、セカンダリ外部ストレージへの書き込みを許可しなければなりません。ただし、パッケージ固有のディレクトリに書き込む場合または ACTION_OPEN_DOCUMENT_TREE インテントの呼び出しによって返される URI 内に書き込む場合は除きます。

ただし、デバイス実装は、Android のメディアスキャナサービスと android.provider.MediaStore を通じて、両方のストレージパスからのコンテンツを透過的に公開すべきです。

使用する共有ストレージの形態に関係なく、デバイス実装に USB ペリフェラルモードをサポートする USB ポートがある場合、ホストコンピュータから共有ストレージの内容にアクセスするメカニズムを提供しなければなりません。デバイス実装は USB マスストレージを使用しても構いませんが、メディア転送プロトコルを使用してこの要件を満たすべきです。デバイス実装がメディア転送プロトコルをサポートする場合は、以下の要件が適用されます。

リファレンス Android MTP ホストである Android File Transfer [参考資料、116] と互換性を持つべきです。
USB デバイスクラス 0x00 を報告するべきです。
USB インターフェース名「MTP」をレポートすべきです。

7.6.3. Adoptable Storage

リムーバブルストレージデバイスのポートが、バッテリー収納部やその他の保護カバー内など、長期に安定した場所にある場合、デバイス実装は、Adoptable Storage [参考資料、117] を実装することが強く推奨されます。

テレビなどのデバイス実装は、デバイスがモバイルではなく据え置きであると想定されるため、USB ポートを介した導入を可能にしても構いません。一方、性質上モバイル型であるデバイス実装の場合は、誤って接続解除するとデータの損失や破損が生じるおそれがあるため、長期的に安定している場所に Adoptable Storage を設置することが強く推奨されます。

7.7. USB

デバイス実装は、USB ペリフェラルモードをサポートすべきであり、USB ホストモードをサポートすべきです。

ペリフェラルモードをサポートする USB ポートを備えたデバイス実装には、以下の要件が適用されます。

ポートは、標準の Type-A または Type-C の USB ポートを持つ USB ホストに接続可能でなければなりません。
ポートは、Micro-B、Micro-AB、または Type-C の USB フォームファクタを使用するべきです。既存と新規の Android デバイスは、今後のプラットフォームリリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
ポートは、デバイスのポートが下向きのときディスプレイが正しく描画されるように、（自然な向きに合わせて）デバイスの底部に配置するか、すべてのアプリ（ホーム画面を含む）でソフトウェアの画面回転を可能にすべきです。既存と新規の Android デバイスは、今後のプラットフォームリリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
Android SDK ドキュメントに記載されているように、Android Open Accessory（AOA）の API と仕様を実装するべきであり、Android ハンドヘルドデバイスの場合は AOA API を実装しなければなりません。AOA 仕様を実装するデバイス実装には、以下の要件が適用されます。
- ハードウェア機能 android.hardware.usb.accessory [参考資料、118] のサポートを宣言しなければなりません。
- ユーザーがデフォルトの USB モードを変更しなくても、アクセサリとして機能する USB ホストマシンとの初回接続時に AOA プロトコルベースの通信の確立をサポートしなければなりません。
- Android SDK ドキュメント [参考資料、119] に記載されているとおり USB オーディオクラスを実装しなければなりません。
- また、USB マスストレージクラスは、USB マスストレージのインターフェース記述である iInterface 文字列の末尾に文字列「android」を含まなければなりません。
USB Battery Charging Specification, Revision 1.2 [参考資料、120] で規定されているとおり、HS チャープ、トラフィックの際に 1.5 A の電流を流すためのサポートを実装するべきです。既存と新規の Android デバイスは、今後のプラットフォームリリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
USB 標準デバイス記述子の iSerialNumber の値は、android.os.Build.SERIAL の値と等しくなければなりません。

ホストモードをサポートする USB ポートを備えたデバイス実装には、以下の要件が適用されます。

デバイス実装が USB 3.1 をサポートしていれば、Type-C の USB ポートを使用すべきです。
標準以外のポートフォームファクタを使用しても構いませんが、使用する場合は、ポートを標準の Type-A または Type-C の USB ポートに適合させるケーブルを同梱しなければなりません。
Micro-AB USB ポートを使用しても構いませんが、使用する場合は、ポートを標準の Type-A または Type-C USB ポートに適合させるケーブルを同梱するべきです。
Android SDK ドキュメント [参考資料、119] に記載されているとおり、USB オーディオクラスを実装することが強く推奨されます。
Android SDK に記載されているとおり Android USB ホスト API を実装しなければならず、ハードウェア機能 android.hardware.usb.host のサポートを宣言しなければなりません [参考資料、121]。
ホストモード時の充電をサポートするべきです。USB Type-C コネクタの場合は、USB Type-C Cable and Connector Specification, Revision 1.2 [] の「Termination Parameters」セクションで規定されているとおり 1.5 A 以上のソース電流をアドバタイズし、Micro-AB コネクタの場合は、USB Battery Charging Specification, Revision 1.2 [参考資料、120] で規定されている充電ダウンストリームポート（CDP）の出力電流範囲を使用します。

7.8. オーディオ

7.8.1. マイク

Android ハンドヘルド実装、Android スマートウォッチ実装、Android Automotive 実装は、マイクを含まなければなりません。

デバイス実装は、マイクを省略しても問題ありません。ただし、デバイス実装でマイクを省略する場合、デバイス実装は、android.hardware.microphone 機能定数を報告してはならず、セクション 7 のとおり、音声録音 API を NoOps として実装しなければなりません。逆に、マイクを備えたデバイス実装には、以下の要件が適用されます。

android.hardware.microphone 機能定数を報告しなければなりません。
セクション 5.4 の、録音の要件を満たさなければなりません。
セクション 5.6 の、オーディオレイテンシの要件を満たさなければなりません。
セクション 7.8.3 に記載されているとおり、近超音波の録音をサポートすることが強く推奨されます。

7.8.2. オーディオ出力

Android スマートウォッチデバイスは、オーディオ出力を含んでも構いません。

スピーカーを含むか、ヘッドセットまたは外部スピーカーとしてのオーディオ出力周辺機器用のオーディオ / マルチメディア出力ポートを備えているデバイス実装には、以下の要件が適用されます。

android.hardware.audio.output 機能定数をレポートしなければなりません。
セクション 5.5 の、オーディオの再生の要件を満たさなければなりません。
セクション 5.6 の、オーディオレイテンシの要件を満たさなければなりません。
セクション 7.8.3 に記載されているとおり、近超音波の再生をサポートすることが強く推奨されます。

逆に、デバイス実装にスピーカーまたはオーディオ出力ポートが含まれない場合、デバイス実装は android.hardware.audio 出力機能を報告してはならず、少なくともオーディオ出力関連の API を NoOps として実装しなければなりません。

Android スマートウォッチデバイス実装はオーディオ出力を備えても構いませんが、備えるべきではありません。その他のタイプの Android デバイス実装はオーディオ出力を備えるとともに、android.hardware.audio.output を宣言しなければなりません。

7.8.2.1. アナログオーディオポート

Android エコシステム全体で 3.5 mm オーディオプラグを使用するヘッドセットやその他のオーディオアクセサリ [参考資料、122] との互換性を持たせるために、デバイス実装に 1 つ以上のアナログオーディオポートが含まれる場合、オーディオポートのうち少なくとも 1 つが、4 極 3.5 mm オーディオジャックであるべきです。4 極 3.5 mm オーディオジャックが含まれる場合、デバイス実装には、以下の要件が適用されます。

ステレオヘッドフォンと、マイク付きステレオヘッドセットへのオーディオ再生をサポートしなければならず、マイク付きステレオヘッドセットからの録音をサポートするべきです。
CTIA ピン配列の TRRS オーディオプラグをサポートしなければならず、OMTP ピン配列のオーディオプラグをサポートするべきです。
デバイス実装がマイクをサポートしている場合は、接続したオーディオアクセサリのマイクの検出をサポートしなければならず、エクストラ値 microphone を 1 に設定して android.intent.action.HEADSET_PLUG をブロードキャストしなければなりません。
オーディオプラグのマイク極と接地極の間で、次に示す 3 つの等価インピーダンス範囲について、検出とキーコードへのマッピングをサポートするべきです。
- 70 オーム以下: KEYCODE_HEADSETHOOK
- 210～290 オーム: KEYCODE_VOLUME_UP
- 360～680 オーム: KEYCODE_VOLUME_DOWN
オーディオプラグのマイク極と接地極の間で、次に示す等価インピーダンス範囲について、検出とキーコードへのマッピングをサポートするべきです。
- 110～180 オーム: KEYCODE_VOICE_ASSIST
プラグ挿入時、ACTION_HEADSET_PLUG をトリガーしなければなりません（ただしプラグのすべての接点がジャックの該当セグメントに接した後に限ります）。
スピーカーインピーダンス 32 オームで、少なくとも 150 mV ± 10% の出力電圧で動作できなければなりません。
マイクのバイアス電圧が 1.8 V～2.9 V でなければなりません。

7.8.3. 近超音波

近超音波とは、18.5 kHz から 20 kHz の帯域のことです。デバイス実装は、次のとおり、AudioManager.getProperty API を介して近超音波オーディオ機能のサポートを正しく報告しなければなりません。

PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND が「true」の場合、
- 18.5 kHz から 20 kHz の帯域におけるマイクの平均電力感度は、2 kHz における感度より下に 15 dB 以内でなければなりません。
- -26 dBFS の 19 kHz トーンについて、18.5 kHz から 20 kHz におけるマイクの非加重信号対雑音比（SNR）は、50 dB 以上でなければなりません。
PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND が「true」の場合、18.5 kHz から 20 kHz におけるスピーカーの平均感度は、2 kHz における感度より下に 40 dB 以内でなければなりません。

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

パフォーマンスと電力に関する最低基準は、ユーザーエクスペリエンスにとって重要であり、アプリの開発時にデベロッパーが設定するであろうベースラインの前提条件に影響を与えます。以下の基準を、Android スマートウォッチデバイスは満たすべきであり、他の種類のデバイス実装は満たさなければなりません。

8.1. ユーザーエクスペリエンスの一貫性

デバイス実装は、アプリとゲームでフレームレートと応答時間の一貫性を確保することで、スムーズなユーザーインターフェースを提供しなければなりません。デバイス実装は次の要件を満たさなければなりません。

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

8.2. ファイル I/O アクセスのパフォーマンス

デバイス実装は、読み取りと書き込みのオペレーションについて、内部ストレージのファイルアクセスパフォーマンスの一貫性を確保しなければなりません。

シーケンシャル書き込み。デバイス実装は、256 MB のファイルに対し、10 MB の書き込みバッファを使用して少なくとも 5 MB/s のシーケンシャル書き込みパフォーマンスを保証しなければなりません。
ランダム書き込み。デバイス実装は、256 MB のファイルに対し、4 KB の書き込みバッファを使用して少なくとも 0.5 MB/s のランダム書き込みパフォーマンスを保証しなければなりません。
シーケンシャル読み取り。デバイス実装は、256 MB のファイルに対し、10 MB の書き込みバッファを使用して少なくとも 15 MB/s のシーケンシャル読み取りパフォーマンスを保証しなければなりません。
ランダム読み取り。デバイス実装は、256 MB のファイルに対し、4 KB の書き込みバッファを使用して少なくとも 3.5 MB/s のランダム読み取りパフォーマンスを保証しなければなりません。

8.3. 省電力モード

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

8.4. 消費電力の算出

より正確に消費電力を算出し報告することで、アプリデベロッパーに対し、アプリの電力使用パターンを最適化するためのインセンティブとツールの両方を提供します。したがって、デバイス実装には、以下の要件が適用されます。

ハードウェアコンポーネントの電力使用量をトラッキングし、アプリごとの電力使用量の内訳を特定できなければなりません。具体的には、実装には以下の要件が適用されます。
- Android オープンソースプロジェクトのサイトに記載されているとおり、ハードウェアコンポーネントごとの電流消費値 [参考資料、123] と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
- すべての消費電力値をミリアンペア時（mAh）単位で報告しなければなりません。
- ハードウェアコンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェアコンポーネント自体に帰属されるべきです。
- プロセスの UID ごとの CPU 消費電力を報告しなければなりません。Android オープンソースプロジェクトは、uid_cputime カーネルモジュール実装を通じて要件を満たしています。
この電力使用量を、adb shell dumpsys batterystats シェルコマンド [参考資料、124] を介してアプリデベロッパーが利用できるようにしなければなりません。
android.intent.action.POWER_USAGE_SUMMARY インテントを尊重して、この電力使用量 [参考資料、125] を表示する設定メニューを表示しなければなりません。

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

デバイス実装は、Android デベロッパー向けドキュメントに含まれる API のセキュリティと権限に関するリファレンスドキュメント [参考資料、126] で規定されている Android プラットフォームのセキュリティモデルと整合するセキュリティモデルを実装しなければなりません。デバイス実装は、サードパーティ / 認証局からの追加の許可 / 証明書を必要とせずに、自己署名アプリのインストールをサポートしなければなりません。具体的には、互換性のあるデバイスは、以降のサブセクションに記載されているセキュリティメカニズムをサポートしなければなりません。

9.1. 権限

デバイス実装は、Android デベロッパー向けドキュメント [参考資料、126] で規定されているとおり、Android 権限モデルをサポートしなければなりません。具体的には、実装は SDK ドキュメントで規定されている各権限を適用しなければならず、どの権限も省略、変更、無視することはできません。実装は、新しい権限 ID 文字列が android.* 名前空間になければ、権限を追加しても構いません。

保護レベルが「dangerous」の権限は、ランタイム権限です。targetSdkVersion が 22 を超えるアプリは、実行時にこうした権限をリクエストします。デバイス実装には、以下の要件が適用されます。

リクエストされた実行時の権限を付与するかどうかを決定するための専用インターフェースをユーザーに示し、実行時の権限を管理するためのインターフェースもユーザーに提供しなければなりません。
両方のユーザーインターフェースの実装を 1 つだけ持たなければなりません。
次の場合を除き、プリインストールアプリに実行時の権限を付与してはなりません。
- アプリが使用する前に、ユーザーの同意を得ることができる。
- プリインストールアプリがデフォルトハンドラとして設定されているインテントパターンに、実行時の権限が関連付けられている。

9.2. UID とプロセスの分離

デバイス実装は、各アプリが一意の Unix 形式の UID として個別のプロセスで動作する、Android アプリサンドボックスモデルをサポートしなければなりません。デバイス実装は、セキュリティと権限に関するリファレンス [参考資料、126] の規定に従ってアプリが適切に署名され、構築されている場合は、同じ Linux ユーザー ID での複数のアプリの実行をサポートしなければなりません。

9.3. ファイルシステムの権限

デバイス実装は、セキュリティと権限に関するリファレンス [参考資料、126] で規定されているとおり、Android ファイルアクセス権限モデルをサポートしなければなりません。

9.4. 代替実行環境

デバイス実装は、Dalvik 実行ファイル形式またはネイティブコード以外のソフトウェアまたはテクノロジーを使用してアプリを実行するランタイム環境を含んでも構いません。ただし、このセクションで説明しているように、そのような代替実行環境は、Android セキュリティモデル、またはインストール済みの Android アプリのセキュリティを侵害してはなりません。

代替ランタイムは、それ自体が Android アプリでなければならず、セクション 9 の他の部分に記載されているとおり、標準の Android セキュリティモデルに準拠しければなりません。

代替ランタイムには、<uses-permission> メカニズムを介して、ランタイムの AndroidManifest.xml ファイルでリクエストされていない権限によって保護されたリソースへのアクセス権を付与してはなりません。

代替ランタイムは、システムアプリに制限された Android 権限によって保護された機能の利用を、アプリに許可してはなりません。

代替ランタイムは、Android サンドボックスモデルに準拠しなければなりません。具体的には、代替ランタイムには以下の要件が適用されます。

PackageManager を介してアプリを個別の Android サンドボックス（Linux ユーザー ID など）にインストールすべきです。
代替ランタイムを使用するすべてのアプリで共有される単一の Android サンドボックスを提供しても構いません。
代替ランタイムを使用するインストール済みのアプリは、共有ユーザー ID と署名証明書の標準的な Android メカニズムを使用する場合を除き、デバイスにインストールされている他のアプリのサンドボックスを再利用してはなりません。
他の Android アプリに対応するサンドボックスで起動されてはならず、そのサンドボックスへのアクセス権を付与したり、付与されたりしてはなりません。
スーパーユーザー（root）または他のユーザー ID の特権で起動されてはならず、その特権を付与される、または付与することを回避しなければなりません。

代替ランタイムの .apk ファイルは、デバイス実装のシステムイメージに含まれていても構いませんが、デバイス実装に含まれる他のアプリの署名に使用される鍵とは異なる鍵で署名されなければなりません。

アプリをインストールする際、代替ランタイムは、アプリが使用する Android の権限についてユーザーの同意を得なければなりません。アプリが、対応する Android の権限があるデバイスリソース（カメラ、GPS など）を利用する必要がある場合、代替ランタイムは、アプリがそのリソースにアクセスできることをユーザーに通知しなければなりません。ランタイム環境がこの方法でアプリの機能を記録しない場合、ランタイム環境は、そのランタイムを使用してアプリをインストールするときに、そのランタイムが持つすべての権限をリストしなければなりません。

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

この機能は、すべてのデバイスタイプで任意です。

Android は複数のユーザーのサポートを含んでおり、ユーザーの完全な分離をサポートします [参考資料、127]。デバイス実装は、複数のユーザーを有効にしても構いませんが、有効にしたときはマルチユーザーサポート [参考資料、128] に関連する次の要件を満たさなければなりません。

android.hardware.telephony 機能フラグを宣言しないデバイス実装は、制限付きプロファイル（追加ユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能）をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。
逆に、android.hardware.telephony 機能フラグを宣言するデバイス実装は、制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを有効または無効にするコントロールの AOSP 実装に合わせなければなりません。
デバイス実装は、API のセキュリティと権限に関するリファレンスドキュメント [参考資料、126] で規定されている Android プラットフォームのセキュリティモデルと整合するセキュリティモデルをユーザーごとに実装しなければなりません。
Android デバイス上のユーザーインスタンスごとに、個別の分離された外部ストレージディレクトリが存在しなければなりません。デバイス実装は、複数のユーザーのデータを同じボリュームまたはファイルシステムに保存しても構いません。ただし、デバイス実装は、特定のユーザーが所有し、そのユーザーに代わって実行されるアプリが、他のユーザーが所有するデータを一覧表示 / 読み取り / 書き込みできないようにしなければなりません。SD カードスロットなどのリムーバブルメディアを使用すると、あるユーザーがホストのパソコンを使用して別のユーザーのデータにアクセスできるようになります。したがって、プライマリ外部ストレージ API 用にリムーバブルメディアを使用するデバイス実装は、システムのみがアクセスできる非リムーバブルメディアにのみ保存されるキーを使用してマルチユーザーを有効にする場合、SD カードの内容を暗号化しなければなりません。これによってホスト PC でメディアが読み取れなくなるため、デバイス実装は、MTP またはそれに似たシステムに切り替えて、ホスト PC が現在のユーザーのデータにアクセスできるようにする必要があります。したがって、デバイス実装は、プライマリ外部ストレージについてリムーバブルメディア [参考資料、129] を使用する場合、マルチユーザーを有効にしても構いませんが、そうするべきではありません。

9.6. プレミアム SMS の警告

Android は、プレミアム SMS メッセージ [参考資料、130] の送信についてユーザーに警告することをサポートしています。プレミアム SMS メッセージとは、携帯通信会社に登録されたサービスに送信されるテキストメッセージのことであり、ユーザーに課金される可能性があります。android.hardware.telephony のサポートを宣言するデバイス実装は、デバイスの /data/misc/sms/codes.xml ファイルで定義された正規表現で識別される番号に SMS メッセージを送信する前に、ユーザーに警告しなければなりません。アップストリームの Android オープンソースプロジェクトは、この要件を満たす実装を提供しています。

9.7. カーネルセキュリティ機能

Android サンドボックスには、Security-Enhanced Linux（SELinux）の強制アクセス制御（MAC）システムを使用する機能や Linux カーネルのその他のセキュリティ機能が含まれています。SELinux などのセキュリティ機能（Android フレームワークの下に実装されている場合）は、以下の要件が適用されます。

既存のアプリとの互換性を維持しなければなりません。
セキュリティ違反が検出されて正常にブロックされたときはユーザーインターフェースを表示してはなりませんが、ブロックされないセキュリティ違反が発生して悪用されたときはユーザーインターフェースを表示しても構いません。
ユーザーまたはデベロッパーが構成できるようにするべきではありません。

ポリシーを構成するための API が、別のアプリに影響する可能性のあるアプリ（Device Administration API など）に公開されている場合、API は互換性を破る構成を許可してはなりません。

デバイスは、SELinux を実装するか、Linux 以外のカーネルを使用する場合は同等の強制アクセス制御システムを実装しなければなりません。デバイスは以下の要件も満たさなければなりません（アップストリームの Android オープンソースプロジェクトのリファレンス実装は、これらの要件を満たしています）。

デバイス実装には、以下の要件が適用されます。

SELinux をグローバル enforcing モードに設定しなければなりません。
すべてのドメインを enforcing モードで構成しなければなりません。デバイス / ベンダー固有のドメインを含め、permissive モードのドメインは許可されません。
アップストリームの Android オープンソースプロジェクト（AOSP）で提供されている external/sepolicy フォルダ内に存在する neverallow ルールの変更、省略、または置き換えを行ってはなりません。また、ポリシーは、AOSP SELinux ドメインとデバイス / ベンダー固有のドメインの両方について、neverallow ルールがすべて存在する状態でコンパイルしなければなりません。

デバイス実装は、アップストリームの Android オープンソースプロジェクトの external/sepolicy フォルダで提供されているデフォルトの SELinux ポリシーを保持し、このポリシーへの追加は、独自のデバイス固有の設定についてのみ行うべきです。デバイス実装は、アップストリームの Android オープンソースプロジェクトと互換性がなければなりません。

9.8. プライバシー

画面に表示されたコンテンツをキャプチャする機能や、デバイスで再生されている音声ストリームを録音する機能をデバイスがシステムに実装している場合、この機能が有効になっていてアクティブにキャプチャや録音を行っているときは常に、ユーザーに通知しなければなりません。

デバイス実装に、デフォルトでプロキシサーバーまたは VPN ゲートウェイ経由でネットワークデータトラフィックをルーティングするメカニズムがある場合（例: android.permission.CONTROL_VPN が付与された VPN サービスのプリロード）、デバイス実装はそのメカニズムを有効にする前にユーザーの同意を得なければなりません。

USB ペリフェラルモードをサポートする USB ポートがある場合、デバイス実装は、USB ポートを介した共有ストレージの内容へのアクセスを許可する前に、ユーザーの同意を求めるユーザーインターフェースを提示しなければなりません。

9.9. フルディスク暗号化

ロック画面のない Android デバイス実装では任意です。

デバイス実装が KeyguardManager.isDeviceSecure() [参考資料、131] について「true」を報告するセキュアロック画面をサポートし、ActivityManager.isLowRamDevice() メソッドで報告される制限付きメモリを備えたデバイスではない場合、デバイスは、アプリの個人データ（/data パーティション）のフルディスク暗号化 [参考資料、132] をサポートしなければならず、永続的で取り外し不可能な部品の場合はアプリの共有ストレージパーティション（/sdcard パーティション）のフルディスク暗号化もサポートしなければなりません。

デバイス実装がフルディスク暗号化をサポートし、Advanced Encryption Standard（AES）の暗号パフォーマンスが 50 MiB/秒を超える場合は、ユーザーが開梱時の初期設定を完了した時点で、フルディスク暗号化がデフォルトで有効になっていなければなりません。デバイス実装が、デフォルトでフルディスク暗号化を無効にして以前の Android バージョンでリリースされている場合、そのようなデバイスはシステムソフトウェアアップデートを通じて要件を満たせないため、免除しても構いません。

暗号化では、128 ビット以上の鍵の AES と、ストレージ用に設計されたモード（AES-XTS、AES-CBC-ESSIV など）を使用しなければなりません。いかなるときも暗号鍵を暗号化せずにストレージに書き込んではなりません。アクティブに使用されている場合を除き、暗号鍵は、低速ストレッチングアルゴリズム（PBKDF2 や scrypt など）でストレッチングされたロック画面のパスコードで AES 暗号化すべきです。ユーザーがロック画面パスコードを指定していない場合、または暗号化でパスコードを使用することを無効にしている場合、システムはデフォルトのパスコードを使用して暗号鍵をラップすべきです。デバイスがハードウェア格納型キーストアを提供する場合は、パスワードストレッチングアルゴリズムを、そのキーストアに暗号によってバインドしなければなりません。暗号鍵をデバイスの外部に送信してはなりません（ユーザーのパスコードやハードウェアにバインドされた鍵でラップされている場合も同様です）。アップストリームの Android オープンソースプロジェクトは、Linux カーネル機能 dm-crypt に基づいて、この機能の優先実装を提供しています。

9.10. 確認付きブート

確認付きブートは、デバイスソフトウェアの完全性を保証する機能です。この機能をサポートするデバイス実装には、以下の要件が適用されます。

プラットフォーム機能フラグ android.software.verified_boot を宣言しなければなりません。
ブートシーケンスごとに確認を実施しなければなりません。
ルートオブトラストである不変のハードウェアキーから開始してシステムパーティションに至るまで、確認しなければなりません。
確認の各ステージを実装して、次のステージのバイトすべての完全性と正真性をチェックしてから、次のステージのコードを実行しなければなりません。
ハッシュアルゴリズム（SHA-256）と公開鍵サイズ（RSA-2048）について、NIST による現在の推奨事項と同程度強力な検証アルゴリズムを使用しなければなりません。

アップストリームの Android オープンソースプロジェクトは、Linux カーネル機能 dm-verity に基づいて、この機能の優先実装を提供しています。

Android 6.0 以降、高度暗号化標準（AES）暗号パフォーマンスが 50 MiB/秒を超えるデバイス実装は、デバイスの完全性のために確認付きブートをサポートしなければなりません。確認付きブートがサポートされていない以前の Android バージョンでデバイス実装がすでにリリースされている場合、そのようなデバイスはシステムソフトウェアアップデートを通じてこの機能のサポートを追加することができないため、この要件を免除されます。

9.11. 鍵と認証情報

Android Keystore システム [参考資料、133] を使用すると、アプリデベロッパーは暗号鍵をコンテナに格納し、KeyChain API [参考資料、134] または Keystore API [参考資料、135] を通じて暗号オペレーションで使用できます。

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

生成可能な鍵の数を制限するべきではなく、少なくとも 8,192 個を超える鍵をインポートできるようにしなければなりません。
ロック画面認証は試行をレート制限しなければならず、Android オープンソースプロジェクトで実装するように、指数バックオフアルゴリズムを含むべきです。
デバイス実装がセキュアロック画面をサポートし、高信頼実行環境（TEE）を実装できるセキュアエレメント（SE）などのセキュアなハードウェアがある場合、以下の要件が適用されます。
- セキュアなハードウェアでキーストア実装をバックアップすることが強く推奨されます。アップストリームの Android オープンソースプロジェクトは、使用することでこの要件を満たすことができる Keymaster Hardware Abstraction Layer（HAL）実装を提供しています。
- デバイスにハードウェア格納型のキーストアが実装されている場合、セキュアなハードウェアでロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。アップストリームの Android オープンソースプロジェクトは、使用することでこの要件を満たすことができるゲートキーパー Hardware Abstraction Layer（HAL）[参考資料、136] を提供しています。

上記の TEE 関連の要件は「強く推奨される」と記載されていますが、次の API バージョンの互換性定義では「要求される」に変更される予定です。デバイス実装が、以前の Android バージョンですでにリリースされており、セキュアなハードウェアに信頼できるオペレーティングシステムを実装していない場合、そのようなデバイスは、システムソフトウェアアップデートを通じてこれらの要件を満たせない可能性があります。したがって、TEE を実装することが強く推奨されます。

9.12. データの削除

デバイスは、システムイメージとシステムイメージの一部としてみなされる他のパーティションデータを除く、すべてのデータを論理的かつ物理的に削除できる「データの初期化」を行うメカニズムをユーザーに提供しなければなりません。このメカニズムは、データ削除に関連する業界基準（NIST SP800-88 など）を満たさなければなりません。セクション 3.9 デバイス管理に記載されている wipeData() API（Android Device Administration API の一部）の実装にこのメカニズムを使用しなければなりません。

デバイスは、論理データ消去を行う高速データワイプを提供しても構いません。

10. ソフトウェア互換性テスト

デバイス実装は、このセクションに記載されているすべてのテストに合格しなければなりません。

しかし、完全に包括的なソフトウェアテストパッケージというものはありません。このため、デバイス実装者は、Android オープンソースプロジェクトから入手できる Android のリファレンス実装と優先実装に対して行う変更を可能な限り最小限に抑えることが強く推奨されます。これにより、互換性の問題をもたらすバグが導入され、再作業やデバイスのアップデートが必要となるリスクを最小限に抑えることができます。

10.1. 互換性テストスイート

デバイス実装は、デバイス上の最終出荷ソフトウェアを使用して、Android オープンソースプロジェクトから入手できる Android 互換性テストスイート（CTS）[参考資料、137] に合格しなければなりません。さらに、デバイス実装者は、可能な限り Android オープンソースツリーのリファレンス実装を使用するべきであり、CTS で不明確な点があった場合やリファレンスソースコードの一部を再実装する場合に互換性を確保しなければなりません。

CTS は、実際のデバイスで実行するように設計されています。他のソフトウェアと同様に、CTS 自体にもバグが含まれている可能性があります。CTS はこの互換性定義とは別にバージョニングされるため、Android 6.0 用に CTS の複数のリビジョンがリリースされる可能性があります。デバイス実装は、デバイスソフトウェアが完成した時点で利用可能な最新バージョンの CTS に合格しなければなりません。

10.2. CTS 検証ツール

デバイス実装は、CTS 検証ツールで該当するすべてのケースを正しく実行しなければなりません。CTS 検証ツールは互換性テストスイートに含まれています。これは、カメラとセンサーの正しい動作など、自動システムではテストできない機能をテストするために人間のオペレーターが実行するツールです。

CTS 検証ツールには、オプションのハードウェアを含め、さまざまな種類のハードウェア用のテストがあります。デバイス実装は、搭載しているハードウェア用のすべてのテストに合格しなければなりません。たとえば、デバイスに加速度計が搭載されている場合は、CTS 検証ツールで加速度計のテストケースが正しく実行されなければなりません。この互換性定義ドキュメントで任意とされている機能のテストケースは、スキップまたは省略しても構いません。

前述のとおり、すべてのデバイスとすべてのビルドで、CTS 検証ツールが正しく実行されなければなりません。ただし、ビルドの多くはよく似ているため、デバイス実装者は、わずかな違いしかないビルドで CTS 検証ツールを明示的に実行することは求められていません。具体的には、CTS 検証ツールに合格した実装との違いが、含まれるロケール、ブランディングなどのセットのみであるデバイス実装は、CTS 検証ツールのテストを省略しても構いません。

11. アップデート可能なソフトウェア

デバイス実装は、システムソフトウェア全体を置き換えるメカニズムを含まなければなりません。このメカニズムは、「ライブ」アップグレードを実施する必要はありません。つまり、デバイスの再起動が必要となっても構いません。

デバイスにプリインストールされているソフトウェア全体を置き換えることができるのであれば、どの方法でも使用できます。たとえば、次のどの方法も、この要件を満たします。

再起動によるオフラインアップデートを伴う「無線（OTA）」ダウンロード。
ホスト PC から USB 経由での「テザー」アップデート。
再起動による「オフライン」アップデートとリムーバブルストレージ上のファイルからのアップデート。

ただし、デバイス実装に 802.11 や Bluetooth PAN（パーソナルエリアネットワーク）プロファイルなど、定額制データ接続のサポートが含まれる場合は、以下の要件が適用されます。

Android Automotive 実装は、再起動によるオフラインアップデートを伴う OTA ダウンロードをサポートすべきです。
他のすべてのデバイス実装は、再起動によるオフラインアップデートを伴う OTA ダウンロードをサポートしなければなりません。

使用するアップデートメカニズムは、ユーザーデータをワイプせずにアップデートをサポートしなければなりません。つまりアップデートメカニズムは、アプリの個人データとアプリの共有データを保持しなければなりません。なお、アップストリームの Android ソフトウェアには、この要件を満たすアップデートメカニズムが含まれています。

Android 6.0 以降を搭載してリリースされるデバイス実装の場合、アップデートメカニズムは、システムイメージが OTA の後に想定される結果とバイナリ同一であることの検証をサポートするべきです。Android 5.1 から追加された、アップストリームの Android オープンソースプロジェクトのブロックベース OTA 実装は、この要件を満たしています。

リリース後に、ただし妥当な製品寿命の期間内にデバイス実装でエラーが見つかり、Android 互換性チームとの協議において、サードパーティアプリの互換性に影響を与えると判断された場合、デバイス実装者は前述のメカニズムによって適用できる、利用可能なソフトウェアアップデートを介してエラーを修正しなければなりません。

Android には、デバイス所有者アプリ（存在する場合）でシステムアップデートのインストールを制御できる機能があります。これを容易にするために、android.software.device_admin を報告するデバイスのシステムアップデートサブシステムは、SystemUpdatePolicy クラス [参考資料、138] に記載されている動作を実装しなければなりません。

12. ドキュメントの変更履歴

次の表に、このリリースでの互換性定義に対する変更の概要を示します。

セクション	変更の概要
各種	「奨励される」という言葉を「推奨される」という言葉に変更
2. デバイスタイプ	Android Automotive 実装の更新
3.2.2. ビルドパラメータ	ハードウェアシリアル番号とビルドのセキュリティパッチレベルの追加
3.2.3.2. インテントの解決	セクションの名前を「インテントのオーバーライド」から「インテントの解決」に変更し、正式なデフォルトのアプリリンクに関連する新しい要件を追加
3.3.1. アプリケーションバイナリインターフェース	Android ABI のサポートに関する追加。Vulkan ライブラリ名に関連する変更
3.4.1. WebView の互換性	WebView から報告されるユーザーエージェント文字列の変更
3.7. ランタイムの互換性	メモリ割り当てテーブルの更新
3.8.4. 検索	アシスタントの要件に関する更新
3.8.6. テーマ	SYSTEM_UI_FLAG_LIGHT_STATUS_BAR フラグでリクエストされた場合に、黒色のシステムアイコンをサポートするための要件を追加
3.8.8. アクティビティの切り替え	概要タイトル数に関する要件を緩和
3.8.10. ロック画面のメディアコントロール	3.8.3 でロック画面のメディアコントロールに詳細に言及
3.9.1 デバイスのプロビジョニング	デバイス所有者のプロビジョニングと管理対象プロファイルのプロビジョニングに関する新しいセクションを追加
3.9.2 管理対象プロファイルのサポート	管理対象プロファイル機能のデバイスサポートの要件に関する新しいセクションを追加
3.12.1. TV アプリ	Android テレビデバイス向けの TV アプリの要件を明確にするためのセクションを追加
3.12.1.1. 電子番組ガイド	Android テレビデバイス向けの EPG 要件を明確にするためのセクションを追加
3.12.1.2. ナビゲーション	Android テレビデバイス向けの TV アプリのナビゲーション要件を明確にするためのセクションを追加
3.12.1.3. TV 入力アプリのリンク	Android テレビデバイス向けのテレビ入力アプリリンクのサポート要件を明確にするためのセクションを追加
5.1. メディアコーデック	主要なメディア形式とデコードのサポートに関する更新
5.1.3. 動画コーデック	Android テレビに関連する変更と追加
5.2. 動画のエンコード	エンコーダに関する変更
5.3. 動画のデコード	デコーダに関する変更（動的な動画解像度のサポート、フレームレートの切り替えのサポートなど）
5.4. 録音	音声キャプチャに関する追加
5.6. オーディオレイテンシ	低レイテンシオーディオのサポートの報告に関する更新
5.10. プロフェッショナルオーディオ	プロフェッショナルオーディオサポートに関する一般的な更新。モバイルデバイス（ジャック）の仕様、USB オーディオホストモードの更新など
5.9. 電子楽器デジタルインターフェース（MIDI）	オプションの電子楽器デジタルインターフェース（MIDI）のサポートに関する新しいセクションを追加
6.1. デベロッパーツール	Windows 10 をサポートするドライバに関する更新
7.1.1.3. 画面密度	画面密度に関する更新（Android スマートウォッチ関連など）
7.2.3. ナビゲーションキー	アシストアクションを含むデバイス実装の要件を更新
7.3. センサー（およびサブセクション）	一部のセンサータイプの新しい要件
7.3.9. ハイファイセンサー	ハイファイセンサーをサポートするデバイスの要件に関する新しいセクション
7.3.10. 指紋認証センサー	指紋認証センサーの要件に関する新しいセクション
7.4.2. IEEE 802.11（Wi-Fi）	マルチキャスト DNS（mDNS）のサポートに関する更新
7.4.3. Bluetooth	Bluetooth Low Energy（BLE）の解決可能なプライベートアドレス（RPA）に関する追加
7.4.4. 近距離無線通信	近距離無線通信（NFC）の要件に対する追加
7.4.5. 最低限のネットワーク機能	IPv6 サポートの要件を追加
7.6.3. Adoptable Storage	Adoptable Storage の実装に関する新しいセクション
7.7. USB	AOA 仕様の実装に関する要件
7.8.3. 近超音波	近超音波の録音、再生、音声に関する追加	近超音波マイクの SNR 要件を緩和
8.3. 省電力モード	アプリスタンバイと Doze モードに関する要件を含む新しいセクション
8.4. 消費電力の算出	ハードウェアコンポーネントの電力使用量をトラッキングし、アプリごとの電力使用量の内訳を特定するための要件に関する新しいセクション
9.1. 権限	権限の要件に対する追加
9.7. カーネルセキュリティ機能	SE Linux の更新
9.8. プライバシー	USB ポートを介した共有ストレージへのアクセスに対するユーザーの同意に関する追加
9.9. フルディスク暗号化	フルディスク暗号化に関連する要件
9.10. 確認付きブート	確認付きブートに関する追加の要件
9.11. 鍵と認証情報	鍵と認証情報に関連する新しい要件のセクション
9.12. データの削除	「データの初期化」に関する新しいセクション
11. アップデート可能なソフトウェア	デバイス所有者が設定するシステムアップデートポリシーに関する要件

13. お問い合わせ

android-compatibility フォーラム [参考資料、139] に参加すると、解説を求めたり、このドキュメントがカバーしていないと思われる問題を提起したりできます。

14. 参考資料

1. IETF RFC2119 要件レベル: http://www.ietf.org/rfc/rfc2119.txt

2. Android オープンソースプロジェクト: http://source.android.com/

3. Android テレビの機能: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android スマートウォッチの機能: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

6. API の定義とドキュメント: http://developer.android.com/reference/packages.html

7. Android 権限リファレンス: http://developer.android.com/reference/android/Manifest.permission.html

8. android.os.Build のリファレンス: http://developer.android.com/reference/android/os/Build.html

9. Android 6.0 で許可されているバージョン文字列: http://source.android.com/docs/compatibility/6.0/versions.html

10. Android デベロッパー設定: http://developer.android.com/reference/android/provider/Settings.html

11. テレフォニープロバイダ: http://developer.android.com/reference/android/provider/Telephony.html

12. Android NDK ABI の管理: https://developer.android.com/ndk/guides/abis.html

13. Advanced SIMD アーキテクチャ: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

14. Android 拡張機能パック: http://developer.android.com/guide/topics/graphics/opengl.html#aep

15. android.webkit.WebView クラス: http://developer.android.com/reference/android/webkit/WebView.html

16. WebView の互換性: http://www.chromium.org/

17. HTML5: http://html.spec.whatwg.org/multipage/

18. HTML5 のオフライン機能: http://dev.w3.org/html5/spec/Overview.html#offline

19. HTML5 の video タグ: http://dev.w3.org/html5/spec/Overview.html#video

20. HTML5/W3C の位置情報 API: http://www.w3.org/TR/geolocation-API/

21. HTML5/W3C のウェブストレージ API: http://www.w3.org/TR/webstorage/

22. HTML5/W3C の IndexedDB API: http://www.w3.org/TR/IndexedDB/

23. Dalvik 実行形式とバイトコードの仕様: Android ソースコードの dalvik/docs で利用可能

24. アプリウィジェット: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

25. 通知: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

26. アプリリソース: https://developer.android.com/guide/topics/resources/available-resources.html

27. ステータスバーアイコンのスタイルガイド: http://developer.android.com/design/style/iconography.html

28. 通知リソース: https://developer.android.com/design/patterns/notifications.html

29. 検索マネージャー: http://developer.android.com/reference/android/app/SearchManager.html

30. アクションアシスト: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

31. Android Assist API: https://developer.android.com/reference/android/app/assist/package-summary.html

32. トースト: http://developer.android.com/reference/android/widget/Toast.html

33. テーマ: http://developer.android.com/guide/topics/ui/themes.html

34. R.style クラス: http://developer.android.com/reference/android/R.style.html

35. マテリアルデザイン: http://developer.android.com/reference/android/R.style.html#Theme_Material

36. ライブ壁紙: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

37. 概要画面のリソース: http://developer.android.com/guide/components/recents.html

38. 画面固定: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

39. 入力方法: http://developer.android.com/guide/topics/text/creating-input-method.html

40. メディア通知: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

41. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

42. Settings.Secure の LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

43. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

44. Android デバイス管理: http://developer.android.com/guide/topics/admin/device-admin.html

45. DevicePolicyManager リファレンス: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

46. デバイス所有者アプリ: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Android デバイス所有者のプロビジョニングフロー: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. NFC によるデバイス所有者のプロビジョニング: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Android プロファイル所有者アプリ:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Android の管理対象プロファイルのプロビジョニングフロー: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

51. Android のユーザー補助サービス API: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

52. Android のユーザー補助 API: http://developer.android.com/reference/android/view/accessibility/package-summary.html

53. Eyes Free プロジェクト: http://code.google.com/p/eyes-free

54. テキスト読み上げ API: http://developer.android.com/reference/android/speech/tts/package-summary.html

55. テレビ入力フレームワーク: /devices/tv/index.html

56. TV アプリのチャンネル: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. サードパーティテレビ入力: /devices/tv/index.html#third-party_input_example

58. テレビ入力: /devices/tv/index.html#tv_inputs

59. テレビチャンネルの EPG フィールド: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. テレビ入力アプリリンク: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

61. リファレンスツールのドキュメント（adb、aapt、ddms、systrace）: http://developer.android.com/tools/help/index.html

62. Android apk ファイルの説明: http://developer.android.com/guide/components/fundamentals.html

63. マニフェストファイル: http://developer.android.com/guide/topics/manifest/manifest-intro.html

64. Android のメディア形式: http://developer.android.com/guide/appendix/media-formats.html

65. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

66. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

67. WebM プロジェクト: http://www.webmproject.org/

68. RTC ハードウェアコーディングの要件: http://www.webmproject.org/hardware/rtc-coding-requirements/

69. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

70. Android の android.content.pm.PackageManager クラスとハードウェア機能のリスト: http://developer.android.com/reference/android/content/pm/PackageManager.html

71. HTTP Live Streaming のドラフトプロトコル: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

72. ADB: http://developer.android.com/tools/help/adb.html

73. dumpsys: /devices/input/diagnostics.html

74. DDMS: http://developer.android.com/tools/debugging/ddms.html

75. Monkey テストツール: http://developer.android.com/tools/help/monkey.html

76. SysyTrace ツール: http://developer.android.com/tools/help/systrace.html

77. Android アプリ開発に関連する設定: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

78. 複数画面のサポート: http://developer.android.com/guide/practices/screens_support.html

79. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

80. RenderScript: http://developer.android.com/guide/topics/renderscript/

81. OpenGL ES 用の Android 拡張機能パック: https://developer.android.com/reference/android/opengl/GLES31Ext.html

82. ハードウェアアクセラレーション: http://developer.android.com/guide/topics/graphics/hardware-accel.html

83. EGL 拡張機能 - EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

84. ディスプレイマネージャー: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

85. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

86. タップ入力の構成: http://source.android.com/docs/core/interaction/input/touch-devices

87. モーションイベント API: http://developer.android.com/reference/android/view/MotionEvent.html

88. キーイベント API: http://developer.android.com/reference/android/view/KeyEvent.html

89. Android オープンソースセンサー: http://source.android.com/docs/core/interaction/sensors

90. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

91. タイムスタンプセンサーイベント: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

92. Android オープンソース複合センサー: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. 連続トリガーモード: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. Android フィンガープリント API: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. Android 指紋認証 HAL: /devices/tech/security/authentication/fingerprint-hal.html

97. Wi-Fi マルチキャスト API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

98. Wi-Fi Direct（Wi-Fi P2P）: http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

99. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

100. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

101. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

102. NFC バーコード: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

103. NDEF プッシュプロトコル: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

104. Android ビーム: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

105. Android NFC の共有設定: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

106. NFC 接続ハンドオーバー: http://members.nfc-forum.org/specs/spec_list/#conn_handover

107. NFC を使用する Bluetooth Secure Simple Pairing: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

108. ホストベースのカードエミュレーション: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

109. コンテンツリゾルバ: http://developer.android.com/reference/android/content/ContentResolver.html

110. カメラの向きに関する API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

111. カメラ: http://developer.android.com/reference/android/hardware/Camera.html

112. カメラ: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

113. カメラのハードウェアレベル: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

114. カメラのバージョンのサポート: http://source.android.com/docs/core/camera/versioning

115. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

116. Android File Transfer: http://www.android.com/filetransfer

117. Adoptable Storage: http://source.android.com/docs/core/storage/adoptable

118. Android のオープンアクセサリ: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

119. Android USB オーディオ: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

120. USB Battery Charging specifications, revision 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

121. USB ホスト API: http://developer.android.com/guide/topics/connectivity/usb/host.html

122. 有線オーディオヘッドセット: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

123. 電力プロファイルのコンポーネント: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. 消費電力の概要: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

126. Android のセキュリティと権限に関するリファレンス: http://developer.android.com/guide/topics/security/permissions.html

127. UserManager リファレンス: http://developer.android.com/reference/android/os/UserManager.html

128. 外部ストレージのリファレンス: http://source.android.com/docs/core/storage/traditional

129. 外部ストレージの API: http://developer.android.com/reference/android/os/Environment.html

130. SMS ショートコード: http://en.wikipedia.org/wiki/Short_code

131. セキュアロック画面の報告: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

132. Android オープンソース暗号化: http://source.android.com/docs/security/features/encryption

133. Android Keystore システム: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html

136. Gatekeeper HAL: http://source.android.com/docs/security/features/authentication/gatekeeper

137. Android 互換性プログラムの概要: http://source.android.com/docs/compatibility

138. SystemUpdatePolicy クラス: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

139. Android 互換性フォーラム: https://groups.google.com/forum/#!forum/android-compatibility

140. アプリリンクの処理: https://developer.android.com/training/app-links/index.html

141. Google デジタルアセットリンク: https://developers.google.com/digital-asset-links

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

Android 6.0 互換性定義

目次

1. はじめに

2. デバイスタイプ

2.1 デバイス構成

3. ソフトウェア

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

3.2. ソフト API の互換性

3.2.1. 権限

3.2.2. ビルド パラメータ

3.2.3. インテントの互換性

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

3.2.3.2. インテントの解決

3.2.3.3. インテントの名前空間

3.2.3.4. ブロードキャスト インテント

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

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

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

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

3.4. ウェブの互換性

3.4.1. WebView の互換性

3.4.2. ブラウザの互換性

3.5. API 動作の互換性

3.6. API 名前空間

3.7. ランタイムの互換性

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

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

3.8.2. ウィジェット

3.8.3. 通知

3.8.4. 検索

3.8.5. トースト

3.8.6. テーマ

3.8.7. ライブ壁紙

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

3.8.9. 入力管理

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

3.8.11. Dreams

3.8.12. 位置情報

3.8.13. Unicode とフォント

3.9. デバイス管理

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

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

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

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

3.10. ユーザー補助

3.11. テキスト読み上げ

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

3.12.1. TV アプリ

3.12.1.1. 電子番組ガイド

3.12.1.2. ナビゲーション

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

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

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

5.1. メディア コーデック

5.1.1. オーディオ コーデック

5.1.2. 画像コーデック

5.1.3. 動画コーデック

5.2. 動画のエンコード

5.3. 動画のデコード

5.4. 録音

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

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

5.4.3. 再生のリルート用のキャプチャ

5.5. オーディオの再生

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

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

5.5.3. オーディオ出力の音量

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

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

5.8. セキュア メディア

5.9. 電子楽器デジタル インターフェース（MIDI）

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

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

6.1. デベロッパー ツール

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

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

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

7.1.1. 画面構成

7.1.1.1. 画面サイズ

7.1.1.2. 画面のアスペクト比

3.2.2. ビルドパラメータ

3.2.3.4. ブロードキャストインテント

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

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

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

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

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

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

5.1. メディアコーデック

5.1.1. オーディオコーデック

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

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

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

5.8. セキュアメディア

5.9. 電子楽器デジタルインターフェース（MIDI）

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

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

6.1. デベロッパーツール

7.1.4. 2D と 3D のグラフィックアクセラレーション

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

7.2.3. ナビゲーションキー

7.2.6. ゲームコントローラのサポート

7.2.6.1. ボタンマッピング

7.3.9. ハイファイセンサー

7.8.2.1. アナログオーディオポート

8.1. ユーザーエクスペリエンスの一貫性

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

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

9.7. カーネルセキュリティ機能