Android 7.0(N)互換性定義

目次

1. はじめに

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

「しなければならない」(「MUST」)、「してはならない」(「MUST NOT」)、「必須」(「REQUIRED」)、(するものとする)(「SHALL」)、「しないものとする」(「SHALL NOT」)、「するべきである」(「SHOULD」)、するべきではない(「SHOULD NOT」)、「推奨される」(「RECOMMENDED」)、「しても構わない」(「MAY」)、「任意」(「OPTIONAL」)の使用は、RFC2119 で定義されている IETF 標準に従っています。

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

デバイス実装が Android 7.1 と互換性があるとみなされるには、この互換性定義(参照先として組み込まれているドキュメントを含む)で示されている要件を満たさなければなりません。

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

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

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

2. デバイスタイプ

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

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

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

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

  • 埋め込み画面を搭載しているか、VGA、HDMI、ディスプレイ用ワイヤレス ポートなどの動画出力ポートを備えていなければなりません。
  • android.software.leanback 機能と android.hardware.type.television 機能を宣言しなければなりません。

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

  • 画面の物理的な対角長が 1.1~2.5 インチでなければなりません。
  • android.hardware.type.watch 機能を宣言しなければなりません。
  • uiMode = UI_MODE_TYPE_WATCH をサポートしなければなりません。

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

  • 画面の物理的な対角長が 6 インチ以上でなければなりません。
  • android.hardware.type.automotive 機能を宣言しなければなりません。
  • uiMode = UI_MODE_TYPE_CAR をサポートしなければなりません。
  • Android Automotive 実装は、android.car.* 名前空間のすべての公開 API をサポートしなければなりません。

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

2.1 デバイス構成

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

カテゴリ 機能 セクション ハンドヘルド テレビ スマートウォッチ Automotive その他
入力 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 するべきである しなければならない するべきである するべきである するべきである
セル無線通信 7.4.5. 最低限のネットワーク機能 するべきである
USB ペリフェラル / ホストモード 7.7. USB するべきである するべきである するべきである
出力 スピーカーおよび / またはオーディオ出力ポート 7.8.2. オーディオ出力 しなければならない しなければならない しなければならない しなければならない

3. ソフトウェア

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

Dalvik バイトコードに基づくマネージド実行環境は、Android アプリを実行するための主要な手段です。Android アプリケーション プログラミング インターフェース(API)は、マネージド ランタイム環境で動作するアプリに公開される Andoid プラットフォーム インターフェースのセットです。デバイス実装は、Android SDK で公開されているすべてのドキュメント化済み API の動作、またはアップストリームの Android ソースコードにおいて「@SystemApi」マーカーで装飾されているすべての API のドキュメント化済みの動作をすべて含む完全な実装を提供しなければなりません。

デバイス実装は、TestApi アノテーション(@TestApi)でマークされたすべてのクラス、メソッド、関連要素をサポート / 保持しなければなりません。

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

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

3.1.1. Android 拡張機能

Android は、同じ API レベルのバージョンを維持しながらマネージド API を拡張することをサポートしています。Android デバイス実装は、共有ライブラリ ExtShared とサービス ExtServices の両方の AOSP 実装を、API レベルごとに許可された最小バージョン以上のバージョンでプリロードしなければなりません。たとえば、API レベル 24 を搭載した Android 7.0 デバイス実装は、少なくともバージョン 1 を含まなければなりません。

3.2. ソフト API の互換性

Android には、セクション 3.1 のマネージド API に加えて、ランタイム専用の重要な「ソフト」API も含まれています。これは、Android アプリのインテント、権限、およびそれらと似た要素の形式を取り、アプリのコンパイル時には適用できない API です。

3.2.1. 権限

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

3.2.2. ビルド パラメータ

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

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

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

次に例を示します。

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

フィンガープリントは空白文字を含んではなりません。上記のテンプレートに含まれる他のフィールドに空白文字がある場合、ビルドのフィンガープリントではアンダースコア(_)などの別の文字に置き換えなければなりません。このフィールドの値は 7 ビット ASCII としてエンコード可能でなければなりません。

HARDWARE ハードウェアの名前(カーネル コマンドラインまたは /proc から)。人が読める程度の形式にすべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。
HOST ビルドが構築されたホストを一意に識別する文字列(人が読める形式)。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
ID 特定のリリースを参照するためにデバイス実装者が選択する識別子(人が読める形式)。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じ内容にできますが、エンドユーザーがソフトウェア ビルドを区別できるような意味のある値にすべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+$」に一致しなければなりません。
MANUFACTURER 製品の相手先ブランド製品製造企業(OEM)の商号。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
MODEL エンドユーザーが知っているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが市販され、エンドユーザーに購入される際の名前と同じにするべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
PRODUCT 特定の製品(SKU)の開発名またはコードネームを含む、デバイス実装者が選択した値。同じブランド内で一意でなければなりません。人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。この製品名は、製品の全期間にわたって変更してはなりません。
SERIAL ハードウェアのシリアル番号。MODEL と MANUFACTURER が同一のデバイスで利用可能かつ一意でなければなりません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^([a-zA-Z0-9]{6,20})$」に一致しなければなりません。
TAGS ビルドをさらに明確に区別する、デバイス実装者が選択したタグのカンマ区切りリスト。このフィールドには、典型的な 3 つの Android プラットフォーム署名設定(release-keys、dev-keys、test-keys)に対応する値のいずれかを指定しなければなりません。
TIME ビルドが作成されたときのタイムスタンプを表す値。
TYPE ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成(user、userdebug、eng)に対応する値のいずれかを指定しなければなりません。
USER ビルドを生成したユーザー(または自動ユーザー)の名前またはユーザー ID。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。
SECURITY_PATCH ビルドのセキュリティ パッチレベルを示す値。この値は、指定された Android のセキュリティに関する公開情報に記載されている問題について、ビルドがいかなる脆弱性も持たないことを示さなければなりません。この値は、Android のセキュリティに関する公開情報または Android セキュリティ アドバイザリに記載されている定義済み文字列と一致する [YYYY-MM-DD] 形式(例:「2015-11-01」)でなければなりません。
BASE_OS ビルドの FINGERPRINT パラメータを表す値。Android のセキュリティに関する公開情報で提供されているパッチを除き、このビルドと同一です。これは正しい値を報告しなければならず、そのようなビルドが存在しない場合は空の文字列("")を報告しなければなりません。

3.2.3. インテントの互換性

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

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

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

デバイス実装は、必要なコア Android アプリを含むか、あるいは、android:exported 属性を通じて暗黙的または明示的に他のアプリに公開されるそれらのコア Android アプリのすべての Activity または Service コンポーネントによって定義された同一のインテント パターンを実装するコンポーネントを含まなければなりません。

3.2.3.2. インテントの解決

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

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

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

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

  • デジタル アセット リンク仕様で規定されている検証手順(アップストリームの Android オープンソース プロジェクトのパッケージ マネージャーによって実装されます)を実施することにより、インテント フィルタの検証を試みなければなりません。
  • アプリのインストール中にインテント フィルタの検証を試行し、検証に合格したすべての 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 インテントを尊重して、ホーム画面用のデフォルト アプリ設定メニューを表示しなければなりません。
  • デバイス実装が android.hardware.telephony を報告する場合は、android.provider.Telephony.ACTION_CHANGE_DEFAULT インテントを呼び出してデフォルトの SMS アプリを変更するダイアログを表示する設定メニューを提供しなければなりません。
  • デバイス実装が android.hardware.nfc.hce を報告する場合、android.settings.NFC_PAYMENT_SETTINGS インテントを尊重して、タップ&ペイ用のデフォルト アプリの設定メニューを表示しなければなりません。
  • デバイス実装が android.hardware.telephony を報告する場合は、android.telecom.action.CHANGE_DEFAULT_DIALER インテントを尊重して、ユーザーがデフォルトの電話アプリを変更できるダイアログを表示しなければなりません。
  • デバイスが VoiceInteractionService をサポートしている場合は android.settings.ACTION_VOICE_INPUT_SETTINGS インテントを尊重して、音声入力と音声アシスト用のデフォルト アプリの設定メニューを表示しなければなりません。

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

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

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 管理ドキュメントの最新版でドキュメント化され、説明されている ABI のみを報告しなければならず、高度な SIMD(NEON)拡張機能をサポートしなければなりません。
  • アップストリームの Android オープンソース プロジェクトで入手可能なソースコードとヘッダー ファイルを使用してビルドするべきです。

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

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

  • libandroid.so(ネイティブ Android アクティビティ サポート)
  • libc(C ライブラリ)
  • libcamera2ndk.so
  • libdl(ダイナミック リンカー)
  • libEGL.so(ネイティブ OpenGL サーフェス管理)
  • libGLESv1_CM.so(OpenGL ES 1.x)
  • libGLESv2.so(OpenGL ES 2.0)
  • libGLESv3.so(OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog(Android ロギング)
  • libmediandk.so(ネイティブ メディア API サポート)
  • libm(math ライブラリ)
  • libOpenMAXAL.so(OpenMAX AL 1.0.1 サポート)
  • libOpenSLES.so(OpenSL ES 1.0.1 オーディオ サポート)
  • libRS.so
  • libstdc++(C++ の最小限のサポート)
  • libvulkan.so(Vulkan)
  • libz(Zlib 圧縮)
  • JNI インターフェース
  • OpenGL のサポート(下記の説明を参照)

上記のネイティブ ライブラリについては、デバイス実装は公開関数を追加または削除してはなりません。

上記のリストにないが AOSP でシステム ライブラリとして実装されて提供されているネイティブ ライブラリは予約済みであり、API レベル 24 以降をターゲットとするサードパーティ アプリに公開してはなりません。

デバイス実装は、AOSP 以外のライブラリを追加して、サードパーティ アプリに API として直接公開しても構いませんが、追加のライブラリは /vendor/lib または /vendor/lib64 に配置するべきであり、/vendor/etc/public.libraries.txt に記載されなければなりません。

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

3.3.1.1. グラフィック ライブラリ

Vulkan は、高パフォーマンスの 3D グラフィックを実現する低オーバーヘッドのクロス プラットフォーム API です。デバイス実装は、Vulkan API のサポートを含んでいない場合でも、下記の要件を満たさなければなりません。

  • コア Vulkan 1.0 API の関数シンボルをエクスポートする libvulkan.so という名前のネイティブ ライブラリと、拡張機能 VK_KHR_surfaceVK_KHR_android_surfaceVK_KHR_swapchain を常に提供しなければなりません。

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

  • vkEnumeratePhysicalDevices 呼び出しを通じて 1 つ以上の VkPhysicalDevices を報告しなければなりません。
  • 列挙された各 VkPhysicalDevices は、Vulkan 1.0 API を完全に実装しなければなりません。
  • 正しい PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL 機能フラグと PackageManager#FEATURE_VULKAN_HARDWARE_VERSION 機能フラグを報告しなければなりません。
  • libvulkan.sovkEnumerateInstanceLayerProperties 関数と vkEnumerateDeviceLayerProperties 関数を通じて、アプリ パッケージのネイティブ ライブラリ ディレクトリにある libVkLayer*.so という名前のネイティブ ライブラリに含まれるレイヤを列挙しなければなりません。
  • アプリに android:debuggable=”true” 属性がある場合を除き、アプリ パッケージ外のライブラリによって提供されるレイヤを列挙したり、Vulkan API をトレースまたはインターセプトする別の方法を提供したりしてはなりません。

Vulkan API のサポートを含まないデバイス実装には、以下の要件が適用されます。

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

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

  • 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 を実装しています。ウェブ レンダリング システムの包括的なテストスイートを開発することは現実的に不可能なので、デバイス実装者は、WebView 実装で Chromium の特定のアップストリーム ビルドを使用しなければなりません。詳細は以下のとおりです。

  • デバイスの android.webkit.WebView 実装は、Android 7.1 用のアップストリームの Android オープンソース プロジェクトに含まれる Chromium ビルドに基づかなければなりません。このビルドには、WebView 用の特定の機能とセキュリティ修正のセットが含まれています。
  • WebView が報告するユーザー エージェント文字列は、次の形式でなければなりません。

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

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

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

3.4.2. ブラウザの互換性

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

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

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

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

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

3.5. API 動作の互換性

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

  • デバイスは、標準的なインテントの動作またはセマンティクスを変更してはなりません。
  • デバイスは、特定のタイプのシステム コンポーネント(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 を(<uses-library> メカニズムを通じて)明示的に使用するアプリのみが、そうした API によるメモリ使用量増加の影響を受けるようにするためです。

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

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

3.7. ランタイムの互換性

デバイス実装は、完全な Dalvik 実行ファイル(DEX)形式と、Dalvik バイトコード仕様およびセマンティクスをサポートしなければなりません。デバイス実装は 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)
320 dpi(xhdpi) 48 MB
360 dpi(360dpi)
400 dpi(400dpi) 56 MB
420 dpi(420dpi) 64 MB
480 dpi(xxhdpi) 88 MB
560 dpi(560dpi) 112 MB
640 dpi(xxxhdpi) 154 MB
小 / 標準 120 dpi(ldpi) 32 MB
160 dpi(mdpi)
213 dpi(tvdpi) 48 MB
240 dpi(hdpi)
280 dpi(280dpi)
320 dpi(xhdpi) 80 MB
360 dpi(360dpi)
400 dpi(400dpi) 96 MB
420 dpi(420dpi) 112 MB
480 dpi(xxhdpi) 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)
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)
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」を公開するためのコンポーネント タイプとそれに対応する API およびライフサイクルが定義されています。ハンドヘルド デバイス実装では、この機能をサポートすることが強く推奨されます。ホーム画面へのウィジェットの埋め込みをサポートするデバイス実装は、以下の要件を満たすとともに、プラットフォーム機能 android.software.app_widgets のサポートを宣言しなければなりません。

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

3.8.3. 通知

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

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

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

Android Automotive 実装は、ドライバーの注意散漫を抑制するために通知の表示とタイミングを管理しても構いませんが、アプリから要求されたときは CarExtender を使用する通知を表示しなければなりません。

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

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

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

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

ハンドヘルド デバイス実装は、このセクションに記載されている、通知に対する更新、削除、応答、バンドル動作をサポートしなければなりません。

また、ハンドヘルド デバイス実装は次のものを提供しなければなりません。

  • 通知シェード内で通知を直接制御する機能。
  • 通知シェード内でコントロール パネルをトリガーするビジュアル アフォーダンス。
  • インライン コントロール パネルと設定アプリの両方で、パッケージからの通知設定をブロック、ミュート、リセットする機能。

SDK ドキュメントに記載されているように、Notification.Style class の 6 つの直接サブクラスをすべてサポートしなければなりません。

DND(サイレント モード)機能をサポートするデバイス実装は、以下の要件を満たさなければなりません。

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

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

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

Android デバイス実装はアシスト アクションを処理するためにデバイスにアシスタントを実装するべきであり、Android Automotive 実装はアシスタントを実装しなければなりません。

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

Assist API と VoiceInteractionService API を使用するプリインストール アプリは、以下の要件をすべて満たしている場合、この表示をデフォルトで無効にしても構いません。

  • ユーザーが次のいずれかの方法でアプリを呼び出し、そのアプリがフォアグラウンドで実行されている場合にのみ、プリインストール アプリはコンテキストの共有をリクエストしなければなりません。

    • 起動ワード呼び出し
    • ASSIST ナビゲーションのキー / ボタン / ジェスチャーの入力
  • デバイス実装は、デフォルトの音声入力とアシスタント アプリの設定メニュー(セクション 3.2.3.5)から 2 回未満のナビゲーションで表示を可能にするアフォーダンスを提供しなければなりません。

3.8.5. トースト

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

3.8.6. テーマ

Android は、アプリがアクティビティ全体またはアプリ全体にスタイルを適用するための仕組みとして「テーマ」を提供しています。

Android には、Android SDK で定義されている Holo テーマの外観にマッチさせたい場合にアプリ デベロッパーが使用できる定義済みスタイルのセットとして、「Holo」テーマ ファミリーが用意されています。デバイス実装は、アプリに公開される Holo テーマ属性のいずれも変更してはなりません。

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

また、Android には、デバイス実装者が定義したデバイステーマの外観にマッチさせたい場合にアプリ デベロッパーが使用できる定義済みスタイルのセットとして、「デバイス デフォルト」テーマ ファミリーが用意されています。デバイス実装は、アプリに公開されるデバイス デフォルト テーマ属性を変更しても構いません。

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

3.8.7. ライブ壁紙

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

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

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

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

履歴機能のナビゲーション キーは任意であるため、概要画面を実装するための要件は Android スマートウォッチ実装と Android Automotive 実装では任意であり、Android テレビデバイスでは推奨されます。Android Automotive 実装では、アクティビティを切り替える手段を残しておくべきです。

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

  • 表示されるアクティビティを少なくとも 20 個サポートしなければなりません。
  • 少なくとも 4 つのアクティビティのタイトルを同時に表示するべきです。
  • 画面固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。
  • ハイライト表示の色、アイコン、画面タイトルを履歴に表示するべきです。
  • 閉じるアフォーダンス(「x」)を表示するべきですが、ユーザーが画面を操作するまで表示を遅らせても構いません。
  • 前のアクティビティに簡単に切り替えられるショートカットを実装するべきです。
  • 関連する履歴を、一緒に移動されるグループとして表示しても構いません。
  • 履歴機能のキーが 2 回タップされたとき、直近に使用した 2 つのアプリをすばやく切り替えるアクションをトリガーするべきです。
  • 履歴機能のキーが長押しされたとき、分割画面のマルチウィンドウ モードをトリガーするべきです(サポートしている場合)。

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

3.8.9. 入力管理

Android には、入力管理のサポートとサードパーティのインプット メソッド エディタのサポートが含まれています。ユーザーがデバイスでサードパーティの入力方法を使用できるようにするデバイス実装は、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 で非推奨になり、メディアアプリがロック画面に表示される再生コントロールを統合できるメディア通知テンプレートに置き換えられました。ロック画面をサポートするデバイス実装は、Android Automotive 実装またはスマートウォッチ実装でない限り、メディア通知テンプレートを含むロック画面通知を表示しなければなりません。

3.8.11. スクリーン セーバー(旧 Dreams)

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

3.8.12. 位置情報

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

3.8.13. Unicode とフォント

Android には、Unicode 9.0 で定義されている絵文字のサポートが含まれています。すべてのデバイス実装は、これらの絵文字をカラーグリフでレンダリングできなければならず、Android デバイス実装に IME が含まれる場合は、これらの絵文字の入力方法をユーザーに提供するべきです。

Android ハンドヘルド デバイスは、Unicode Technical Report #51 で規定されている肌の色合いと多様なファミリー絵文字をサポートするべきです。

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.8.14. マルチウィンドウ

デバイス実装は、マルチ ウィンドウ モードを実装しなくても構いませんが、複数のアクティビティを同時に表示する機能がある場合は、Android SDK のマルチウィンドウ モードのサポートに関するドキュメントに記載されているアプリの動作と API に従ってマルチ ウィンドウ モードを実装し、以下の要件を満たさなければなりません。

  • アプリは、マルチウィンドウ モードで動作できるかどうかを示すことができます。そのためには、AndroidManifest.xml ファイルで、android:resizeableActivity 属性を通じて明示的に指定するか、targetSdkVersion を 24 より大きくして暗黙的に指定します。マニフェストでこの属性を明示的に false に設定しているアプリは、マルチウィンドウ モードで起動してはなりません。マニフェスト ファイルでこの属性を設定していないアプリ(targetSdkVersion < 24)はマルチウィンドウ モードで起動できますが、システムは、マルチウィンドウ モードではアプリが想定どおりに機能しない可能性があることを警告しなければなりません。
  • デバイス実装は、画面の高さと幅の両方が 440 dp 未満の場合、分割画面モードまたはフリーフォーム モードを提供してはなりません。
  • 画面サイズが xlarge のデバイス実装は、フリーフォーム モードをサポートするべきです。
  • Android テレビデバイス実装はピクチャー イン ピクチャー(PIP)モードのマルチウィンドウをサポートしなければならず、PIP がオンのときは PIP マルチウィンドウを右上隅に配置しなければなりません。
  • PIP モードのマルチウィンドウをサポートするデバイス実装は、PIP ウィンドウに少なくとも 240x135 dp を割り当てなければなりません。
  • PIP マルチウィンドウ モードがサポートされている場合は、PIP ウィンドウの制御に KeyEvent.KEYCODE_WINDOW キーを使用しなければなりません。そうでない場合は、フォアグラウンド アクティビティがこのキーを使用できなければなりません。

3.9. デバイス管理

Android には、Android Device Administration API を介して、セキュリティ対応アプリがシステムレベルでデバイス管理機能(パスワード ポリシーの適用やリモートワイプの実施など)を実行できる機能があります。デバイス実装は、DevicePolicyManager クラスの実装を提供しなければなりません。セキュアロック画面をサポートするデバイス実装は、Android SDK ドキュメントで規定されているすべてのデバイス管理ポリシーを実装し、プラットフォーム機能 android.software.device_admin を報告しなければなりません。

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

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

デバイス実装が android.software.device_admin 機能を宣言する場合は、下記のデバイス ポリシー クライアント(DPC)アプリのデバイス所有者アプリのプロビジョニングを実装しなければなりません。

  • ユーザーデータが未構成のデバイス実装には、以下の要件が適用されます。
  • ユーザーデータがあるデバイス実装には、以下の要件が適用されます。

デバイス管理機能を実行するアプリをデバイス実装にプリインストールしても構いませんが、明示的な同意なしで、あるいはデバイスのユーザーまたは管理者からのアクションなしで、そのようなアプリをデバイス所有者アプリとして設定してはなりません。

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

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

管理対象プロファイルのプロビジョニング プロセス(android.app.action.PROVISION_MANAGED_PROFILE で開始されるフロー)のユーザー エクスペリエンスは、AOSP 実装と整合していなければなりません。

デバイス実装は、特定のシステム機能が Device Policy Controller(DPC)によって無効にされたときにそれをユーザーに示すために、設定ユーザー インターフェース内で以下のユーザー アフォーダンスを提供しなければなりません。

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

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

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

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

  • プラットフォーム機能フラグ android.software.managed_users を宣言している。
  • android.app.admin.DevicePolicyManager API を介して管理対象プロファイルをサポートしている。
  • 管理対象プロファイルを 1 つだけ作成できる。
  • アイコンバッジ(AOSP のアップストリームの仕事用バッジに類似)を使用して、管理対象アプリ、ウィジェット、およびその他のバッジ付き UI 要素(履歴と通知など)を表している。
  • 通知アイコン(AOSP のアップストリームの仕事用バッジに似たもの)を表示して、ユーザーが管理対象プロファイル アプリ内にいるときにそのことを示している。
  • デバイスが復帰し(ACTION_USER_PRESENT)、フォアグラウンド アプリが管理対象プロファイル内にある場合に、ユーザーが管理対象プロファイル内にいることを示すトーストを表示する。
  • 管理対象プロファイルが存在する場合、Device Policy Controller によって有効にされていれば、ユーザーが管理対象プロファイルからプライマリ ユーザー(またはその逆)にインテントを転送できるインテント選択ツールにビジュアル アフォーダンスを表示する。
  • 管理対象プロファイルが存在する場合、プライマリ ユーザーと管理対象プロファイルの両方について以下のユーザー アフォーダンスを公開する。
    • プライマリ ユーザーと管理対象プロファイルに関する、バッテリー、位置情報、モバイルデータ、ストレージ使用量の個別の計算。
    • プライマリ ユーザーまたは管理対象プロファイル内にインストールされている VPN アプリの独立した管理。
    • プライマリ ユーザーまたは管理対象プロファイル内にインストールされているアプリの独立した管理。
    • プライマリ ユーザーまたは管理対象プロファイル内のアカウントの独立した管理。
  • Device Policy Controller が許可している場合は、プリインストール済みの電話アプリ、連絡先アプリ、メッセージ アプリが、プライマリ プロファイルからの情報とともに管理対象プロファイル(存在する場合)からの発信者情報を検索できるようにする。管理対象プロファイルの連絡先が、プリインストール済みの通話履歴、通話 UI、通話中通知、不在着信通知、連絡先アプリおよびメッセージ アプリに表示されるときは、管理対象プロファイル アプリを示すために使用されるものと同じバッジをそれらの連絡先に付けるべきです。
  • 管理対象プロファイルがプライマリ ユーザーに加えて別のユーザーとしてカウントされない場合でも、複数のユーザーが有効になっているデバイス(セクション 9.5 を参照)に適用されるセキュリティ要件をすべて満たすことを保証する。
  • 管理対象プロファイルで実行されるアプリへのアクセス権を付与するために、以下の要件を満たす個別のロック画面を指定する機能をサポートする。
    • デバイス実装は、DevicePolicyManager.ACTION_SET_NEW_PASSWORD インテントを尊重して、管理対象プロファイルの個別のロック画面認証情報を構成するインターフェースを表示しなければならない。
    • 管理対象プロファイルのロック画面認証情報は、Android オープンソース プロジェクトのサイトに記載されているように、親プロファイルと同じ認証情報ストレージと管理メカニズムを使用しなければならない。
    • DPC パスワード ポリシーは、getParentProfileInstance が返す DevicePolicyManager インスタンスで呼び出される場合を除き、管理対象プロファイルのロック画面認証情報にのみ適用しなければならない。

3.10. ユーザー補助

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

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

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

  • オーディオ出力を備えた Android デバイス実装は、TalkBack** およびスイッチ アクセスのユーザー補助サービス(https://github.com/google/talkback)と同等以上の機能を持つユーザー補助サービスの実装をデバイスで提供することが強く推奨される。

  • オーディオ出力を備えた Android スマートウォッチ デバイスは、TalkBack ユーザー補助サービス(https://github.com/google/talkback)と同等以上の機能を持つユーザー補助サービスの実装をデバイスで提供するべきである。
  • デバイス実装は、関連するユーザー補助サービスと、フォントサイズ、ディスプレイ サイズ、拡大ジェスチャーを調整するオプションをユーザーが有効にできるメカニズムを初期設定フローで提供するべきである。

** テキスト読み上げでサポートされる言語が対象です。

また、プリロード済みのユーザー補助サービスが存在し、デバイスがファイルベース暗号化(FBE)を使用してストレージを暗号化している場合、そのユーザー補助サービスはダイレクト ブート対応 {directBootAware} アプリでなければなりません。

3.11. テキスト読み上げ

Android には、アプリがテキスト読み上げ(TTS)サービスを利用できるようにするとともに、サービス プロバイダが TTS サービスの実装を提供できるようにする API が含まれています。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 テレビデバイス実装は、テレビ入力フレームワークをサポートしなければなりません。

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

3.12.1. TV アプリ

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

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

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

3.12.1.1. 電子番組ガイド

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

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

3.12.1.2. ナビゲーション

TV アプリは、Android テレビデバイスの入力デバイス(リモコン、リモコンアプリ、ゲーム コントローラ)の D-pad、戻るキー、ホームキーを介して、以下の機能のナビゲーションを実現しなければなりません。

  • テレビ チャンネルを変更する
  • EPG を開く
  • TIF ベースのサードパーティ入力を構成および調整する
  • 設定メニューを開く

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

3.12.1.3. テレビ入力アプリリンク

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

3.12.1.4. タイムシフト

Android テレビデバイス実装は、ユーザーがライブ コンテンツを一時停止および再開できるように、タイムシフトをサポートしなければなりません。デバイス実装は、現在再生中の番組でタイムシフトが利用可能な場合は、番組を一時停止および再開する方法をユーザーに提供しなければなりません。

3.12.1.5. テレビの録画

Android テレビデバイス実装は、テレビの録画をサポートすることが強く推奨されます。テレビ入力が録画をサポートしている場合、その番組の録画が禁止されていなければ、EPG は番組を録画する方法を提供しても構いません。デバイス実装は、録画した番組を再生するユーザー インターフェースを提供するべきです。

3.13. クイック設定

Android デバイス実装は、よく使用するアクションや緊急のアクションにすばやくアクセスできるクイック設定 UI コンポーネントを含むべきです。

Android には quicksettings API が含まれています。この API を使用すると、サードパーティ アプリは、ユーザーが追加できるタイルとシステムが提供するタイルをクイック設定 UI コンポーネントと並べて実装できます。クイック設定 UI コンポーネントを含むデバイス実装には、以下の要件が適用されます。

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

3.14. 車両 UI API

3.14.1. 車両メディア UI

自動車のサポートを宣言するデバイス実装は、MediaBrowser API と MediaSession API を使用するサードパーティ アプリをサポートする UI フレームワークを含まなければなりません。

MediaBrowser と MediaSession に依存するサードパーティ アプリをサポートする UI フレームワークには、以下の視覚的な要件があります。

  • MediaItem アイコンと通知アイコンを変更せずに表示しなければなりません。
  • MediaSession によって記述されるアイテム(メタデータ、アイコン、画像など)を表示しなければなりません。
  • アプリのタイトルを表示しなければなりません。
  • MediaBrowser 階層を提示するドロワーが存在しなければなりません。

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

デバイス実装は、公式の Android SDK に含まれる「aapt」ツールによって生成された Android「.apk」ファイルをインストールして実行しなければなりません。したがって、デバイス実装は、リファレンス実装のパッケージ管理システムを使用するべきです。

パッケージ マネージャーは、APK 署名スキーム v2JAR 署名を使用した「.apk」ファイルの検証をサポートしなければなりません。

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

デバイス実装は、DELETE_PACKAGE 権限の SDK ドキュメントに記載されているように、パッケージの現在の「レコードのインストーラ」以外のアプリが、プロンプトを表示せずにアプリをサイレント アンインストールできるようにしてはなりません。例外は、PACKAGE_NEEDS_VERIFICATION インテントを処理するシステム パッケージ検証アプリと、ACTION_MANAGE_STORAGE インテントを処理するストレージ管理アプリです。

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

5.1. メディア コーデック

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

  • このドキュメントで明示的に許可されている場合を除き、Android SDK ドキュメントで規定されているコアメディア形式をサポートしなければなりません。

  • 下記の表で規定され、MediaCodecList を通じて報告されるメディア形式、エンコーダ、デコーダ、ファイル形式、コンテナ形式をサポートしなければなりません。

  • また、CamcorderProfile で報告されるすべてのプロファイルをデコードできなければなりません。

  • エンコードできるすべての形式をデコードできなければなりません。これには、エンコーダが生成するすべてのビットストリームが含まれます。

コーデックは、コーデック レイテンシを最小限に抑えることを目指すべきです。言い換えると、コーデックには以下の要件が適用されます。

  • 入力バッファを消費、保存すべきでなく、1 回処理されただけの入力バッファを返すべきではありません。
  • デコードされたバッファを、標準(SPS など)で規定されているよりも長く保持するべきではありません。
  • エンコードされたバッファを、GOP 構造が必要とするよりも長く保持するべきではありません。

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

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

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

形式 / コーデック エンコーダ デコーダ 詳細 サポートされているファイル形式 / コンテナ形式
MPEG-4 AAC プロファイル
(AAC LC)
必須1 必須 標準サンプリング レート 8~48 kHz のモノラル / ステレオ / 5.0 / 5.1 2 コンテンツをサポート。
  • 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+) 必須1
(Android 4.1 以降)
必須 標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.1 2 コンテンツをサポート。
MPEG-4 HE AACv2
プロファイル(Enhanced AAC+)
必須 標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.1 2 コンテンツをサポート。
AAC-ELD(Enhanced Low Delay AAC) 必須1
(Android 4.1 以降)
必須
(Android 4.1 以降)
標準サンプリング レート 16~48 kHz のモノラル / ステレオ コンテンツをサポート。
AMR-NB 必須3 必須3 8 kHz でサンプリングされた 4.75~12.2 kbps 3GPP(.3gp)
AMR-WB 必須3 必須3 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) 必須4
(Android 4.1 以降)
必須 16 ビットのリニア PCM(最大レートはハードウェアの上限値)。デバイスは、Raw PCM 録音のサンプリング レートとして、8,000、11,025、16,000、44,100 Hz の周波数をサポートしなければなりません。 WAVE(.wav)
Opus 必須
(Android 5.0 以降)
Matroska(.mkv)、Ogg(.ogg)

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

2 録音または再生をモノラルまたはステレオで行っても構いませんが、android.media.MediaCodec API のデフォルト AAC オーディオ デコーダを通じて、マルチチャンネル ストリーム(つまり、チャンネル数が 2 を超えるもの)の AAC 入力バッファを PCM にデコードする場合は、以下をサポートしなければなりません。

  • デコードがダウンミックスなしで行われること(たとえば、5.0 AAC ストリームは 5 チャンネルの PCM にデコードされなければならず、5.1 AAC ストリームは 6 チャンネルの PCM にデコードされなければなりません)。
  • ISO/IEC 14496-3 の「Dynamic Range Control(DRC)」で定義されているダイナミック レンジ メタデータと、オーディオ デコーダのダイナミック レンジ関連の動作を構成するための android.media.MediaFormat DRC キー。API 21 で導入された AAC DRC キーは、KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL、KEY_AAC_ENCODED_TARGET_LEVEL です。

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)
Raw 必須 ARW(.arw)、CR2(.cr2)、DNG(.dng)、NEF(.nef)、NRW(.nrw)、ORF(.orf)、PEF(.pef)、RAF(.raf)、RW2(.rw2)、SRW(.srw)

5.1.3. ビデオ コーデック

  • HDR プロファイルのサポートをアドバタイズするコーデックは、HDR 静的メタデータの解析と処理をサポートしなければなりません。

  • メディア コーデックがイントラ更新のサポートをアドバタイズする場合は、10~60 フレームの範囲の更新期間をサポートし、構成された更新期間の 20% 以内で正確に動作しなければなりません。

  • ビデオ コーデックは、標準と構成で規定されているように、実現可能な最大圧縮フレームと非圧縮フレームに対応する入出力バイトバッファ サイズをサポートしなければなりませんが、過剰に割り当ててはなりません。

  • 動画のエンコーダとデコーダは、YUV420 フレキシブル カラー形式(COLOR_FormatYUV420Flexible)をサポートしなければなりません。

形式 / コーデック エンコーダ デコーダ 詳細 サポートされているファイル形式 /
コンテナ形式
H.263 しても構わない しても構わない
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
H.264 AVC 必須2 必須2 詳細については、セクション 5.25.3 をご覧ください
  • 3GPP(.3gp)
  • MPEG-4(.mp4)
  • MPEG-2 TS(.ts、AAC オーディオのみ、シーク不可、Android 3.0 以降)
H.265 HEVC 必須5 詳細については、セクション 5.3 をご覧ください MPEG-4(.mp4)
MPEG-2 強く推奨される6 メイン プロファイル MPEG2-TS
MPEG-4 SP 必須2 3GPP(.3gp)
VP8 3 必須2
(Android 4.3 以降)
必須2
(Android 2.3.3 以降)
詳細については、セクション 5.25.3 をご覧ください
VP9 必須2
(Android 4.4 以降)
詳細については、セクション 5.3 をご覧ください

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

2 Android スマートウォッチ デバイスを除くデバイス実装では必須です。

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

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

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

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

5.2. 動画のエンコード

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

H.264、VP8、VP9、HEVC 動画エンコーダには、以下の要件が適用されます。

  • 動的に構成できるビットレートをサポートしなければなりません。
  • 可変フレームレートをサポートするべきです。その場合、動画エンコーダは、入力バッファのタイムスタンプに基づいて瞬間的なフレーム持続時間を決定し、そのフレーム持続時間に基づいてビットバケットを割り当てるべきです。

H.263 および MPEG-4 動画エンコーダは、動的に構成できるビットレートをサポートするべきです。

すべての動画エンコーダは、2 つのスライディング ウィンドウで以下のビットレート目標を達成するべきです。

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

5.2.1. H.263

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

5.2.2. H-264

H.264 コーデックをサポートする Android デバイス実装には、以下の要件が適用されます。

  • ベースライン プロファイル レベル 3 をサポートしなければなりません。
    ただし、ASO(Arbitrary Slice Ordering)、FMO(Flexible Macroblock Ordering)、RS(Redundant Slices)のサポートは任意です。さらに、他の Android デバイスとの互換性を維持するために、エンコーダがベースライン プロファイルに ASO、FMO、RS を使用しないことが推奨されます。
  • 以下の表の SD(標準画質)動画エンコード プロファイルをサポートしなければなりません。
  • メイン プロファイル レベル 4 をサポートするべきです。
  • 以下の表に示すように、HD(高画質)動画エンコード プロファイルをサポートするべきです。
  • さらに、Android テレビデバイスは、HD 1080p 動画を 30 fps でエンコードすることが強く推奨されます。
SD(低画質) SD(高画質) HD 720p 1 HD 1080p 1
動画の解像度 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 テレビデバイスでは強く推奨されます。

5.2.3. VP8

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

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

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

5.3. 動画のデコード

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

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

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

  • ドルビー ビジョン デコーダをサポートする実装には、以下の要件が適用されます。

  • ドルビー ビジョン対応エクストラクタを提供しなければなりません。
  • ドルビー ビジョンのコンテンツを、デバイス画面または標準のビデオ出力ポート(例: HDMI)に適切に表示しなければなりません。

  • ドルビー ビジョン対応エクストラクタを提供する実装は、下位互換性のあるベースレイヤのトラック インデックスを(存在する場合)、統合されたドルビー ビジョン レイヤのトラック インデックスと同じものに設定しなければなりません。

5.3.1. MPEG-2

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

5.3.2. H.263

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

5.3.3. MPEG-4

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

5.3.4. H.264

H.264 デコーダを備えた Android デバイス実装には、以下の要件が適用されます。

  • メイン プロファイル レベル 3.1 とベースライン プロファイルをサポートしなければなりません。
    ASO(Arbitrary Slice Ordering)、FMO(Flexible Macroblock Ordering)、RS(Redundant Slices)のサポートは任意です。
  • 以下の表に示されている SD(標準画質)プロファイルを持ち、ベースライン プロファイルとメイン プロファイル レベル 3.1(720p30 を含む)でエンコードされた動画をデコードできなければなりません。
  • 以下の表に示されている HD(高画質)プロファイルを持つ動画をデコードできるべきです。
  • さらに、Android テレビデバイスには、以下の要件が適用されます。
    • ハイ プロファイル レベル 4.2 と HD 1080p60 デコード プロファイルをサポートしなければなりません。
    • 以下の表に示されている両方の HD プロファイルを持ち、ベースライン プロファイル、メイン プロファイル、ハイ プロファイル レベル 4.2 のいずれかでエンコードされた動画をデコードできなければなりません。
SD(低画質) SD(高画質) HD 720p 1 HD 1080p 1
動画の解像度 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 2
動画のビットレート 800 Kbps 2 Mbps 8 Mbps 20 Mbps

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

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

5.3.5. H.265(HEVC)

セクション 5.1.3 に記載されている H.265 コーデックをサポートする Android デバイス実装には、以下の要件が適用されます。

  • 以下の表に示すように、メイン プロファイル レベル 3 メインティアと SD 動画デコード プロファイルをサポートしなければなりません。
  • 以下の表に示すように、HD デコード プロファイルをサポートするべきです。
  • ハードウェア デコーダが存在する場合は、以下の表に示すように、HD デコード プロファイルをサポートしなければなりません。
  • さらに、Android テレビデバイスには、以下の要件が適用されます。
  • HD 720p デコード プロファイルをサポートしなければなりません。
  • HD 1080p デコード プロファイルをサポートすることが強く推奨されます。HD 1080p デコード プロファイルがサポートされている場合は、メイン プロファイル レベル 4.1 メインティアをサポートしなければなりません。
  • UHD デコード プロファイルをサポートするべきです。UHD デコード プロファイルがサポートされている場合、コーデックはメイン 10 レベル 5 メインティア プロファイルをサポートしなければなりません。
SD(低画質) SD(高画質) HD 720p HD 1080p UHD
動画の解像度 352 x 288 px 720 x 480 px 1,280 x 720 px 1,920 x 1,080 px 3,840 x 2,160 px
動画のフレームレート 30 fps 30 fps 30 fps 30 fps(60 fps 1 60 fps
動画のビットレート 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 H.265 ハードウェア デコードを備えた Android テレビデバイス実装では必須です。

5.3.6. VP8

セクション 5.1.3 に記載されている VP8 コーデックをサポートする Android デバイス実装には、以下の要件が適用されます。

  • 以下の表の SD デコード プロファイルをサポートしなければなりません。
  • 以下の表の HD デコード プロファイルをサポートするべきです。
  • Android テレビデバイスは、HD 1080p60 デコード プロファイルをサポートしなければなりません。
SD(低画質) SD(高画質) HD 720p 1 HD 1080p 1
動画の解像度 320 x 180 px 640 x 360 px 1,280 x 720 px 1,920 x 1,080 px
動画のフレームレート 30 fps 30 fps 30 fps(60 fps 2 30(60 fps 2
動画のビットレート 800 Kbps 2 Mbps 8 Mbps 20 Mbps

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

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

5.3.7. VP9

セクション 5.1.3 に記載されている VP9 コーデックをサポートする Android デバイス実装には、以下の要件が適用されます。

  • 以下の表に示すように、SD 動画デコード プロファイルをサポートしなければなりません。
  • 以下の表に示すように、HD デコード プロファイルをサポートするべきです。
  • ハードウェア デコーダが存在する場合は、以下の表に示すように、HD デコード プロファイルをサポートしなければなりません。
  • さらに、Android テレビデバイスには、以下の要件が適用されます。

    • HD 720p デコード プロファイルをサポートしなければなりません。
    • HD 1080p デコード プロファイルをサポートすることが強く推奨されます。
    • UHD デコード プロファイルをサポートするべきです。UHD 動画デコード プロファイルがサポートされている場合は、8 ビット色深度をサポートしなければならず、VP9 プロファイル 2(10 ビット)をサポートするべきです。
SD(低画質) SD(高画質) HD 720p HD 1080p UHD
動画の解像度 320 x 180 px 640 x 360 px 1,280 x 720 px 1,920 x 1,080 px 3,840 x 2,160 px
動画のフレームレート 30 fps 30 fps 30 fps 30 fps(60 fps 1 60 fps
動画のビットレート 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 VP9 ハードウェア デコードを備えた Android テレビデバイス実装では必須です。

5.4. オーディオ録音

このセクションで概説している要件の一部は、Android 4.3 以降では「するべきである」(「SHOULD」)と記載されていますが、将来のバージョンの互換性定義では「しなければならない」(「MUST」)に変更される予定です。既存と新規の Android デバイスは、「するべきである」(「SHOULD」)と記載されている要件を満たすことが強く推奨されます。そうしないと、将来のバージョンにアップグレードするときに 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 音源は、44,100 または 48,000 のいずれかのサンプリング レートでのキャプチャをサポートしなければなりません。

上記の録音仕様に加えて、アプリが 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 を宣言するデバイスは、REMOTE_SUBMIX 音源を適切に実装して、アプリが android.media.AudioRecord API を使用してこの音源から録音を行うときに、次のものを除くすべての音声ストリームのミックスをキャプチャできるようにしなければなりません。

  • 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 を提供しています。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 テレビデバイス実装は、サポートされる出力で、システムのマスター ボリュームとデジタル オーディオ出力ボリュームの減衰をサポートしなければなりません。ただし、圧縮オーディオ パススルー出力(デバイスでオーディオのデコードが行われない)は除きます。

Android Automotive デバイス実装は、AudioAttributes で定義されているコンテンツ タイプまたは使用方法と、android.car.CarAudioManager で定義され公開されているカーオーディオの使用方法に基づいて、音声ストリームごとにオーディオの音量を個別に調整できるようにするべきです。

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

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

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

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

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

  • 100 ミリ秒以下のコールド出力レイテンシ
  • 45 ミリ秒以下の連続出力レイテンシ
  • 最小限に抑えられたコールド出力ジッター

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

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

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

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

デバイスは、Android SDK ドキュメントで規定されているように、音声と動画を再生するためにメディア ネットワーク プロトコルをサポートしなければなりません。具体的には、デバイスは以下のメディア ネットワーク プロトコルをサポートしなければなりません。

セグメント形式 リファレンス 必要なコーデックのサポート
MPEG-2 トランスポート ストリーム ISO 13818 ビデオ コーデック:
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
H264 AVC、MPEG2-4 SP、MPEG-2 の詳細は
セクション 5.1.3 を参照

オーディオ コーデック:

  • AAC
AAC とそのバリアントの詳細については、セクション 5.1.1 をご覧ください。
ADTS フレーム処理と ID3 タグを伴う AAC ISO 13818-7 AAC とそのバリアントの詳細については、セクション 5.1.1 をご覧ください
WebVTT WebVTT
  • RTSP(RTP、SDP)

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

プロファイル名 リファレンス 必要なコーデックのサポート
H264 AVC RFC 6184 H264 AVC の詳細については、セクション 5.1.3 をご覧ください
MP4A-LATM RFC 6416 AAC とそのバリアントの詳細については、セクション 5.1.1 をご覧ください
H263-1998 RFC 3551
RFC 4629
RFC 2190
H263 の詳細については、セクション 5.1.3 をご覧ください
H263-2000 RFC 4629 H263 の詳細については、セクション 5.1.3 をご覧ください
AMR RFC 4867 AMR-NB の詳細については、セクション 5.1.1 をご覧ください
AMR-WB RFC 4867 AMR-WB の詳細については、セクション 5.1.1 をご覧ください
MP4V-ES RFC 6416 MPEG-4 SP の詳細については、セクション 5.1.3 をご覧ください
mpeg4-generic RFC 3640 AAC とそのバリアントの詳細については、セクション 5.1.1 をご覧ください
MP2T RFC 2250 詳細については、HTTP Live Streaming の下の MPEG-2 トランスポート ストリームをご覧ください

5.8. セキュア メディア

セキュアな動画出力をサポートし、セキュア サーフェスをサポートできるデバイス実装は、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 クラスを通じて android.software.midi 機能のサポートを報告することが強く推奨されます。

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

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

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

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

デバイス実装が以下の要件をすべて満たす場合は、android.content.pm.PackageManager クラスを通じて 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)モバイル デバイス(ジャック)仕様セクションに従うことが強く推奨されます。

OpenSL ES PCM バッファキュー API を使用して、レイテンシと USB オーディオの要件を満たさなければなりません。

さらに、この機能のサポートを報告するデバイス実装は、次のことを行うべきです。

  • オーディオがアクティブである間、サステナブルなレベルの CPU パフォーマンスを実現する。
  • オーディオ クロックの標準時間に対する不正確さとずれを最小限に抑える。
  • オーディオ クロックの CPU CLOCK_MONOTONIC に対するずれを最小限に抑える(両方ともアクティブな場合)。
  • デバイス上のトランスデューサでオーディオ レイテンシを最小限に抑える。
  • USB デジタル オーディオでオーディオ レイテンシを最小限に抑える。
  • すべてのパスでオーディオ レイテンシ測定値を記録する。
  • オーディオ バッファ完了コールバック エントリ時間のジッターはコールバックによる CPU 帯域幅全体の使用可能率に影響するため、最小限に抑える。
  • 報告対象のレイテンシで、通常の使用におけるオーディオ アンダーラン(出力)またはオーディオ オーバーラン(入力)をゼロにする。
  • チャンネル間のレイテンシの差異をゼロにする。
  • すべてのトランスポートで MIDI の平均レイテンシを最小限に抑える。
  • すべてのトランスポートで、負荷がかかった状態での MIDI レイテンシのばらつき(ジッター)を最小限に抑える。
  • すべてのトランスポートで正確な MIDI タイムスタンプを提供する。
  • コールド スタート直後の期間を含め、デバイス上のトランスデューサでオーディオ信号ノイズを最小限に抑える。
  • 対応するエンドポイントの入力側と出力側でオーディオ クロックの差異をゼロにする(両方ともアクティブな場合)。対応するエンドポイントの例としては、デバイス上のマイクとスピーカーや、オーディオ ジャックの入力と出力があります。
  • 同じスレッド上の対応するエンドポイントの入力側と出力側のオーディオ バッファ完了コールバックを処理し(両方ともアクティブな場合)、入力コールバックからのリターンの直後に出力コールバックに入る。または、同じスレッド上でコールバックを処理することが現実的に不可能な場合、入力コールバックに入った直後に出力コールバックに入り、アプリが入力側と出力側のタイミングを合わせられるようにする。
  • 対応するエンドポイントの入力側と出力側で、HAL オーディオ バッファリングの位相差を最小限に抑える。
  • タップ レイテンシを最小限に抑える。
  • 負荷がかかった状態でのタップ レイテンシのばらつき(ジッター)を最小限に抑える。

5.11. 未処理音源のキャプチャ

Android 7.0 以降、新しい録音ソースが追加されました。このソースは android.media.MediaRecorder.AudioSource.UNPROCESSED 音源を使用してアクセスできます。OpenSL ES では、録音プリセット SL_ANDROID_RECORDING_PRESET_UNPROCESSED でアクセスできます。

デバイスは、android.media.AudioManager プロパティ PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED を通じて未処理音源のサポートを報告するため、以下の要件をすべて満たさなければなりません。

  • デバイスは、中域周波数帯でほぼ平坦な振幅周波数特性を示さなければなりません: 具体的には 100 Hz~7,000 Hz で ±10 dB。

  • デバイスは、低域周波数帯で次の振幅レベルを示さなければなりません: 具体的には、中域周波数帯と比較して 5 Hz~100 Hz で ±20 dB。

  • デバイスは、高域周波数帯で次の振幅レベルを示さなければなりません: 具体的には、中域周波数帯と比較して 7,000 Hz~22 KHz で ±30 dB。

  • 音圧レベル(SPL)94 dB で再生された 1,000 Hz の正弦波音源が、16 ビットサンプルで RMS 520(または浮動小数点 / 倍精度サンプルで -36 dB フルスケール)の応答を生じさせるように、オーディオ入力の感度を設定しなければなりません。

  • SNR > 60 dB(94 dB の SPL と A 特性自己雑音の等価 SPL の差異)。

  • 高調波ひずみの合計は、マイクにおける 90 dB SPL の入力レベルで 1 kHz に対して 1% 未満でなければなりません。

  • パスで許可される信号処理は、レベルを目的の範囲内に収めるためのレベル乗算器のみです。このレベル乗算器は、信号パスに遅延またはレイテンシを生じさせてはなりません。

  • パスでは、自動ゲイン コントロール、ハイパス フィルタ、エコー キャンセレーションなどのその他の信号処理は許可されません。なんらかの理由でアーキテクチャになんらかの信号処理が存在する場合は、それを無効にしなければならず、信号パスで生じる遅延または余分なレイテンシを効率的にゼロにしなければなりません。

SPL の測定はすべて、テスト対象のマイクのすぐ隣で直接行います。

マイクが複数ある構成では、これらの要件を各マイクに適用します。

デバイスは、未処理録音ソースの信号パスに関する要件をなるべく多く満たすことが強く推奨されます。ただし、デバイスが未処理音源のサポートを表明する場合は、上記の要件をすべて満たさなければなりません。

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

6.1. デベロッパー ツール

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

  • Android Debug Bridge(adb)
    • デバイス実装は、Android SDK ドキュメントに記載されているように、adb のすべての機能(dumpsys を含む)をサポートしなければなりません。
    • デバイス側の adb デーモンはデフォルトで非アクティブでなければならず、ユーザーによるアクセスが可能な、Android Debug Bridge をオンにするメカニズムが存在しなければなりません。デバイス実装が USB ペリフェラル モードを省略している場合は、ローカルエリア ネットワーク(イーサネットや 802.11 など)を介して Android Debug Bridge を実装しなければなりません。
    • Android は、セキュア adb をサポートしています。セキュア adb は、既知の認証済みホストで adb を有効にします。デバイス実装は、セキュア adb をサポートしなければなりません。
  • Dalvik Debug Monitor Service(ddms)
    • デバイス実装は、Android SDK ドキュメントに記載されているように、ddms のすべての機能をサポートしなければなりません。
    • ddms は adb を使用するので、ddms のサポートはデフォルトで非アクティブにするべきですが、上記のようにユーザーが Android Debug Bridge をアクティブにした場合は必ずサポートしなければなりません。
  • Monkey デバイス実装は、Monkey フレームワークを含まなければならず、アプリで使用できるようにしなければなりません。
  • SysTrace
    • デバイス実装は、Android SDK ドキュメントに記載されているように、systrace ツールをサポートしなければなりません。Systrace はデフォルトで非アクティブでなければならず、ユーザーによるアクセスが可能な、Systrace をオンにするメカニズムが存在しなければなりません。
    • ほとんどの Linux ベースのシステムと Apple Macintosh システムは、標準の Android SDK ツールを使用して、追加のサポートなしで 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 インテントを尊重して、アプリ開発関連の設定を表示しなければなりません。アップストリームの Android 実装では、デフォルトで開発者向けオプション メニューは非表示になっており、ユーザーは [設定] > [デバイス情報] > [ビルド番号] メニュー アイテムを 7 回タップすると、開発者向けオプションを起動できます。デバイス実装は、開発者向けオプションについて一貫性のあるエクスペリエンスを提供しなければなりません。具体的には、デバイス実装は開発者向けオプションをデフォルトで非表示にしなければならず、アップストリームの Android 実装と整合する、開発者向けオプションを有効にするメカニズムを提供しなければなりません。

Android Automotive 実装は、車両の走行中にメニューを視覚的に非表示にするか無効にすることにより、開発者向けオプション メニューへのアクセスを制限しても構いません。

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

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

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

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

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

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

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

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

  • 物理的な対角サイズ: ディスプレイの明るくなる部分の 2 つの相対する隅の間の距離(インチ単位)。
  • 1 インチあたりのドット数(dpi): 長さ 1 インチの水平または垂直の直線で囲まれたピクセルの数。dpi 値が記載されている場合は、水平方向と垂直方向の dpi が両方とも範囲内に収まらなければなりません。
  • アスペクト比: 画面の長辺と短辺のピクセル数の比。たとえば、480x854 ピクセルのディスプレイでは、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 ドキュメントで規定されていてアップストリームの 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 Automotive デバイスは、画面の物理的な対角サイズが 6 インチ以上でなければなりません。
  • Android Automotive デバイスは、画面サイズが少なくとも 750 dp x 480 dp でなければなりません。
  • 画面が物理的に統合されているその他のタイプの Android デバイス実装は、画面の物理的な対角サイズが 2.5 インチ以上でなければなりません。

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

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

7.1.1.2. 画面のアスペクト比

物理画面ディスプレイの画面のアスペクト比の値に制限はありませんが、サードパーティ アプリがレンダリングされるサーフェスの画面アスペクト比(DisplayMetrics を通じて報告される値から導出できます)は、以下の要件を満たさなければなりません。

  • uiMode が UI_MODE_TYPE_WATCH として構成されている場合は、アスペクト比の値を 1.0(1:1)に設定しても構いません。
  • サードパーティ アプリが android:resizeableActivity 属性を通じてサイズ変更が可能であることを示している場合、アスペクト比の値に制限はありません。
  • 上記以外のすべての場合、アスペクト比の値は 1.3333(4:3)から 1.86(およそ 16:9)の間でなければなりません。ただし、アプリが maxAspectRatio メタデータ値を通じて、もっと高い画面アスペクト比をサポートすることを明示的に示している場合は除きます。

7.1.1.3. 画面密度

Android UI フレームワークは、アプリ デベロッパーがアプリリソースをターゲットにできるように、標準の論理密度のセットを定義しています。デフォルトでは、デバイス実装は DENSITY_DEVICE_STABLE API を介して以下の論理 Android フレームワーク密度を 1 つだけ報告しなければならず、いかなるときもこの値を変更してはなりません。ただし、デバイスは、初回起動後にユーザーが行ったディスプレイ構成(ディスプレイ サイズなど)の変更に応じて、任意の異なる密度を報告しても構いません。

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

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

デバイス実装は、ディスプレイ サイズを変更する設定をユーザーに提供することが強く推奨されます。デバイスのディスプレイ サイズを変更する実装がある場合、その実装は下記の AOSP 実装と整合するものでなければなりません。

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

7.1.2. ディスプレイの指標

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

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 または 3.2 をサポートできるデバイスでは、それをサポートするべきです。デバイス実装は、Android SDK ドキュメントで詳述されているように、Android RenderScript もサポートしなければなりません。

また、デバイス実装は、OpenGL ES 1.0、OpenGL ES 2.0、OpenGL ES 3.0、OpenGL 3.1、または OpenGL 3.2 のサポートを正しく表明しなければなりません。これは次のことを意味します。

  • マネージド 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 または 3.2 のサポートを宣言するデバイス実装は、対応するマネージド API をサポートし、ネイティブ C/C++ API のサポートを含まなければなりません。OpenGL ES 3.0、3.1、または 3.2 のサポートを宣言するデバイス実装では、libGLESv2.so は、OpenGL ES 2.0 の関数シンボルに加えて、対応する関数シンボルをエクスポートしなければなりません。

Android は、Java インターフェースを備えた OpenGL ES 拡張機能パックを提供し、テッセレーションや ASTC テクスチャ圧縮形式などの高度なグラフィック機能のネイティブ サポートを提供しています。Android デバイス実装は、デバイスが OpenGL ES 3.2 をサポートしている場合は拡張機能パックをサポートしなければならず、それ以外の場合はサポートしても構いません。拡張機能パック全体がサポートされている場合、デバイスは android.hardware.opengles.aep 機能フラグを通じてサポートを表明しなければなりません。

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

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

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

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

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

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

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

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

Android では、以前の画面サイズに依存しない Andrdoid の旧バージョン用に開発されていないレガシーアプリを活用するために、「標準」画面サイズ相当(幅 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 を実装しなければなりません。

7.2. 入力デバイス

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

7.2.1. キーボード

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

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

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

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

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

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

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

7.2.3. ナビゲーション キー

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

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

  • Android ハンドヘルド デバイス実装は、ホーム機能、履歴機能、戻る機能を提供しなければなりません。
  • Android テレビデバイス実装は、ホーム機能と戻る機能を提供しなければなりません。
  • Android スマートウォッチ デバイス実装は、ユーザーが利用できるホーム機能と、戻る機能(UI_MODE_TYPE_WATCH のときを除く)を備えていなければなりません。
  • Android スマートウォッチ デバイス実装は、キーイベント KEYCODE_BACK で長押しイベントを消費し、それをフォアグラウンド アプリに送信する対象から除外しても構いません。この要件は他の Android デバイスタイプには適用されません。
  • Android Automotive 実装は、ホーム機能を提供しなければならず、戻る機能と履歴機能を提供しても構いません。
  • 他のすべてのタイプのデバイス実装は、ホーム機能と戻る機能を提供しなければなりません。

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

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

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

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

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

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

アシスト アクションおよび / または VoiceInteractionService をサポートする Android デバイス実装は、他のナビゲーション キーが表示されている場合、単一の操作(タップ、ダブルクリック、ジェスチャーなど)でアシストアプリを起動できなければなりません。この操作には、ホームボタンの長押しを使用することが強く推奨されます。指定された操作は、ユーザーが選択するアシストアプリ(つまり、VoiceInteractionService を実装するアプリ)または ACTION_ASSIST インテントを処理するアクティビティを起動しなければなりません。

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

  • デバイス実装のナビゲーション キーは、アプリが利用できない画面内の特に区切られた部分を使用しなければならず、アプリが利用できる画面内の部分を隠したり、その他の方法で利用を妨げたりしてはなりません。
  • デバイス実装は、セクション 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 の値を報告しなければなりません。

Android は、さまざまなタッチスクリーン、タッチパッド、疑似タップ入力デバイスをサポートしています。タッチスクリーン ベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるディスプレイに関連付けられます。ユーザーが画面に直接触れるので、システムは操作中のオブジェクトを示す追加のアフォーダンスを必要としません。これに対して、疑似タップ インターフェースは、タッチスクリーン機能のサブセットに似たユーザー入力システムを提供します。たとえば、画面上のカーソルを操作するマウスまたはリモコンはタップに似ていますが、ユーザーは最初にポイントするかフォーカスしてからクリックする必要があります。擬似タップ操作をサポートできる入力デバイスは、マウス、トラックパッド、ジャイロベースのエアマウス、ジャイロポインタ、ジョイスティック、マルチタッチ トラックパッドなど、数多くあります。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 画面位置を報告し、画面にビジュアル ポインタを表示しなければなりません
  • ポインタが画面を上下に移動するときに発生する状態変化を指定するアクション コードで、タッチイベントを報告しなければなりません。
  • ユーザーが画面上のオブジェクトのタップをエミュレートできるように、画面上のオブジェクトにおけるポインタの上下移動をサポートしなければなりません。
  • ユーザーが画面上のオブジェクトのダブルタップをエミュレートできるように、時間しきい値内で、画面上のオブジェクトの同じ場所におけるポインタの下移動、ポインタの上移動、ポインタの下移動からの上移動をサポートしなければなりません。
  • ユーザーがタップドラッグをエミュレートできるように、画面上の任意の点におけるポインタの下移動、画面上の他の任意の点へのポインタの移動、それに続くポインタの上移動をサポートしなければなりません。
  • ユーザーが画面上のオブジェクトをフリングできるように、ポインタの下移動をサポートし、ユーザーが画面上の別の位置にオブジェクトをすばやく移動してから画面上でポインタを上移動できるようにしなければなりません。

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

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

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

7.2.6.1. ボタン マッピング

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

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

1 KeyEvent

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

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

4 MotionEvent

アナログ コントロール 1 HID 使用状況 Android ボタン
左トリガー 0x02 0x00C5 AXIS_LTRIGGER
右トリガー 0x02 0x00C4 AXIS_RTRIGGER
左ジョイスティック 0x01 0x0030
0x01 0x0031
AXIS_X
AXIS_Y
右ジョイスティック 0x01 0x0032
0x01 0x0035
AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. リモコン

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

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

7.3. センサー

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

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

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

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

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

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

複数のセンサーがアクティブになっているとき、消費電力は、個々のセンサーが報告する消費電力の合計を超えるべきではありません。

7.3.1. 加速度計

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

  • TYPE_ACCELEROMETER センサーを実装し、報告しなければなりません。
  • Android スマートウォッチ デバイスでは、比較的厳しい電力制約があるため少なくとも 50 Hz の周波数でイベントを報告できなければならず、他のすべてのデバイスタイプでは、100 Hz でイベントを報告できなければなりません。
  • 少なくとも 200 Hz でイベントを報告するべきです。
  • Android API で詳述されているように、Android センサー座標系に従わなければなりません。Android Automotive 実装は、Android 自動車センサー座標系に従わなければなりません。
  • どの軸でも、自由落下から重力の 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 センサー座標系に従わなければなりません。
  • 飽和する前に各軸で -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 / GNSS レシーバーを含むべきです。デバイス実装が GPS / GNSS レシーバーを含み、android.hardware.location.gps 機能フラグを通じてアプリに機能を報告する場合は、以下の要件が適用されます。

  • 緊急通報中もデバイスが通常の GPS / GNSS 出力を引き続きアプリに提供し、緊急通報中に位置情報出力がブロックされないことが強く推奨されます。
  • LocationManager#requestLocationUpdate を介してリクエストされたときは、少なくとも 1 Hz のレートで位置情報出力をサポートしなければなりません。
  • データ速度が 0.5 Mbps 以上のインターネット接続が確立されたときに、全天条件下(信号強度が高く、マルチパスを無視でき、HDOP が 2 未満)で 10 秒以内に(短い初期位置計算時間で)現在地を特定できなければなりません。一般的に、この要件を満たすには、なんらかの形のアシスト型または予測型 GPS / GNSS 手法を使用して GPS / GNSS ロックオン時間を最小限に抑えます(アシストデータには、基準時間、基準位置、衛星エフェメリス / クロックが含まれます)。
    • デバイスは、上記の位置情報計算を行った後、位置情報リクエストが再開されたときに、全天条件下で 10 秒以内に現在地を特定できることと、後続のリクエストがデータ接続なしで行われた場合および / または電源をオフにして再度オンにした場合であっても、初期位置情報の計算後 1 時間以内に現在地を特定できることが強く推奨されます。
  • 現在地を特定した後、全天条件下で、静止するか加速度 1 メートル毎秒未満で移動している間、以下の要件を満たす必要があります。
    • 0.5 メートル毎秒以内の速度と少なくとも 95% の時間で 20 メートル以内の位置を特定できなければなりません。
    • GnssStatus.Callback を通じて、1 つの衛星コンステレーションから少なくとも 8 個の衛星を同時にトラッキングして報告しなければなりません。
    • 複数の衛星コンステレーションから少なくとも 24 個の衛星を同時にトラッキングできるべきです(例: GPS に加えて GLONASS、北斗、ガリレオのうち少なくとも 1 つ)。
  • テスト API「getGnssYearOfHardware」を介して GNSS テクノロジーの世代を報告しなければなりません。
  • GNSS テクノロジーの世代が「2016 年」以降と報告される場合は、下記のすべての要件を満たすことが強く推奨され、満たさなければなりません。
    • GPS / GNSS から計算された位置情報がまだ報告されていなくても、GPS 測定値が判明したらすぐに報告しなければなりません。
    • 現在地を特定した後、全天条件下で、静止するか加速度 0.2 メートル毎秒毎秒未満で移動している間、0.2 メートル毎秒以内の速度と少なくとも 95% の時間で 20 メートル以内の位置を計算するのに十分な GPS の擬似距離と擬似距離レートを報告しなければなりません。

上記の GPS 要件の一部は「強く推奨される」(「STRONGLY RECOMMENDED」)と記載されていますが、次のメジャー バージョンの互換性定義では「しなければならない」(「MUST」)に変更される予定です。

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 温度センサーを含んでも構いませんが、含むべきではありません。含む場合は、SESEOR_TYPE_TEMPERATURE として定義しなければならず、デバイスの CPU の温度を測定しなければならず、それ以外の温度を測定してはなりません。なお、SENSOR_TYPE_TEMPERATURE センサータイプは、Android 4.0 で非推奨になりました。

Android Automotive 実装の場合、SENSOR_TYPE_AMBIENT_TEMPERATURE は車内の温度を測定しなければなりません。

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 以下でなければなりません。
    • 最大測定周波数が 400 Hz 以上でなければなりません。
    • 測定ノイズが 400 uG/√Hz 以下でなければなりません。
    • 少なくとも 3,000 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • 計量消費電力が 3 mW 以下でなければなりません。
    • 24 時間の静的データセットにおける定常ノイズのバイアスが 15 μg √Hz 未満で安定しているべきです。
    • 温度に対するバイアスの変化が +/-1 mg/°C 以下であるべきです。
    • 最良適合線が非線形で 0.5% 以下、温度に対する感度の変化が 0.03%/C° 以下であるべきです。
  • SENSOR_TYPE_GYROSCOPE

    • 測定範囲が少なくとも -1,000~+1,000 dps でなければなりません。
    • 測定の分解能が少なくとも 16 LSB/dps でなければなりません。
    • 最小測定周波数が 12.5 Hz 以下でなければなりません。
    • 最大測定周波数が 400 Hz 以上でなければなりません。
    • 測定ノイズが 0.014°/s/√Hz 以下でなければなりません。
    • 24 時間の静的データセットにおける定常ノイズのバイアスが 0.0002°/s √Hz 未満で安定しているべきです。
    • 温度に対するバイアスの変化が +/-0.05°/s/°C 以下であるべきです。
    • 温度に対する感度の変化が 0.02%/°C 以下であるべきです。
    • 最良適合線が非線形で 0.2% 以下であるべきです。
    • ノイズ密度が 0.007°/s/√Hz 以下であるべきです。
  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED には、SENSOR_TYPE_GYROSCOPE と同じ品質要件が適用されます。

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • 測定範囲が少なくとも -900~+900 uT でなければなりません。
    • 測定の分解能が少なくとも 5 LSB/uT でなければなりません。
    • 最小測定周波数が 5 Hz 以下でなければなりません。
    • 最大測定周波数が 50 Hz 以上でなければなりません。
    • 測定ノイズが 0.5 uT 以下でなければなりません。
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED には、SENSOR_TYPE_GEOMAGNETIC_FIELD と同じ品質要件に加えて、次の要件が適用されます。
    • 少なくとも 600 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
  • SENSOR_TYPE_PRESSURE
    • 測定範囲が少なくとも 300~1,100 hPa でなければなりません。
    • 測定の分解能が少なくとも 80 LSB/hPa でなければなりません。
    • 最小測定周波数が 1 Hz 以下でなければなりません。
    • 最大測定周波数が 10 Hz 以上でなければなりません。
    • 測定ノイズが 2 Pa/√Hz 以下でなければなりません。
    • 少なくとも 300 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • 計量消費電力が 2 mW 以下でなければなりません。
  • SENSOR_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 ミリ秒以内でなければなりません。
  • ハイファイ センサーは、物理センサーでデータがアプリからアクセス可能になった時点から 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 ドキュメントに記載されているように、対応する API を完全に実装しなければなりません。
  • 他人受け入れ率が 0.002% 以下でなければなりません。
  • デバイスで測定される本人拒否率が 10% 未満であることが強く推奨されます。
  • 登録した指 1 本につき、指紋認証センサーにタッチしてから画面がロック解除されるまでのレイテンシの測定値が 1 秒未満であることが強く推奨されます。
  • 指紋検証の試行が 5 回失敗した後は、試行を少なくとも 30 秒間レート制限しなければなりません。
  • ハードウェア格納型キーストアを実装し、高信頼実行環境(TEE)または TEE へのセキュア チャネルを持つチップで、指紋マッチングを実施しなければなりません。
  • Android オープンソース プロジェクトのサイトにある実装ガイドラインに記載されているように、本人を識別できるすべての指紋データを暗号化して、高信頼実行環境(TEE)の外部で取得、読み取り、または改変できないように暗号認証を行わなければなりません。
  • ユーザーに既存の信頼チェーンを確認してもらうか、TEE によって保護される新しいデバイス認証情報(PIN / パターン / パスワード)を追加することにより、信頼チェーンを確立する前に指紋が追加されないようにしなければなりません。Android オープンソース プロジェクトの実装は、フレームワークでそのためのメカニズムを提供しています。
  • サードパーティ アプリが個々の指紋を区別できるようにしてはなりません。
  • DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT フラグを尊重しなければなりません。
  • Android 6.0 より前のバージョンからアップグレードする場合は、指紋データが上記の要件を満たすように安全に移行されるか、または削除されるようにしなければなりません。
  • Android オープンソース プロジェクトで提供されている Android 指紋アイコンを使用するべきです。

7.3.11. Android Automotive 専用センサー

Automotive 固有のセンサーは android.car.CarSensorManager API で定義されています。

7.3.11.1. 現在のギア

Android Automotive 実装は、現在のギアを SENSOR_TYPE_GEAR として提供するべきです。

7.3.11.2. 日中 / 夜間モード

Android Automotive 実装は、SENSOR_TYPE_NIGHT として定義される日中モード / 夜間モードをサポートしなければなりません。このフラグの値は、ダッシュボードの日中 / 夜間モードと整合していなければならず、周囲光センサー入力に基づくべきです。基になる周囲光センサーは、光度計と同じでも構いません。

7.3.11.3. 運転状況

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

7.3.11.4. 車輪回転速度

Android Automotive 実装は、SENSOR_TYPE_CAR_SPEED として定義される車両速度を提供しなければなりません。

7.3.12. 姿勢センサー

デバイス実装は、自由度が 6 の姿勢センサーをサポートしても構いません。Android ハンドヘルド デバイスは、このセンサーをサポートすることが推奨されます。自由度が 6 の姿勢センサーをサポートするデバイス実装には、以下の要件が適用されます。

  • TYPE_POSE_6DOF センサーを実装し、報告しなければなりません。
  • 回転ベクトルのみの場合よりも正確でなければなりません。

7.4. データ接続

7.4.1. テレフォニー

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

Android は、テレフォニー ハードウェアを備えていないデバイスで使用しても構いません。つまり、Android はスマートフォンではないデバイスと互換性があります。ただし、デバイス実装が GSM または CDMA テレフォニーを含む場合は、その技術に対応する API の完全なサポートを実装しなければなりません。テレフォニー ハードウェアを備えていないデバイス実装は、完全な API を NOP として実装する必要があります。

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

Android テレフォニー デバイス実装は、番号ブロックのサポートを含まなければなりません。さらに、以下の要件があります。

  • SDK ドキュメントに記載されているように、BlockedNumberContract とそれに対応する API を完全に実装しなければなりません。
  • アプリとやり取りすることなく、「BlockedNumberProvider」の電話番号からの着信とメッセージをすべてブロックしなければなりません。唯一の例外は、SDK ドキュメントに記載されているように、番号ブロックが一時的に解除されている場合です。
  • ブロックした着信について、プラットフォーム通話履歴プロバイダに書き込んではなりません。
  • ブロックしたメッセージについて、テレフォニー プロバイダに書き込んではなりません。
  • TelecomManager.createManageBlockedNumbersIntent() メソッドによって返されたインテントで開かれるブロック番号管理 UI を実装しなければなりません。
  • デバイスでブロックした番号をセカンダリ ユーザーが表示または編集できるようにしてはなりません。Android プラットフォームは、プライマリ ユーザーがデバイス上のテレフォニー サービス(単一インスタンス)を完全に制御すると想定しているからです。ブロック関連のすべての UI をセカンダリ ユーザーに対して非表示にしなければならず、ブロックしたリストを引き続き優先しなければなりません。
  • デバイスが Android 7.0 にアップデートされるときは、ブロックした番号をプロバイダに移行するべきです。

7.4.2. IEEE 802.11(Wi-Fi)

すべての Android デバイス実装は、1 つ以上の 802.11 形式のサポートを含むべきです。802.11 のサポートを含み、その機能をサードパーティ アプリに公開するデバイス実装は、対応する Android API を実装しなければなりません。さらに、以下の要件があります。

  • ハードウェア機能フラグ android.hardware.wifi を報告しなければなりません。
  • SDK ドキュメントに記載されているように、マルチキャスト 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 ドキュメントに記載されているように、対応する Android API を実装しなければなりません。Wi-Fi Direct のサポートを含むデバイス実装には、以下の要件が適用されます。

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

デバイス実装は、Android SDK ドキュメントに記載されているように、Wi-Fi Tunneled Direct Link Setup(TDLS)のサポートを含むべきです。デバイス実装が TDLS のサポートを含み、TDLS が WiFiManager API によって有効になっている場合は、以下の要件が適用されます。

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

7.4.3. Bluetooth

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

android.hardware.vr.high_performance 機能をサポートするデバイス実装は、Bluetooth 4.2 と Bluetooth LE データ長拡張機能をサポートしなければなりません。

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

Android Automotive 実装は、Message Access Profile(MAP)をサポートするべきです。Android Automotive 実装は、以下の Bluetooth プロファイルをサポートしなければなりません。

  • Hands-Free Profile(HFP)を介した通話。
  • Audio Distribution Profile(A2DP)を介したメディア再生。
  • Remote Control Profile(AVRCP)を介したメディア再生コントロール。
  • Phone Book Access Profile(PBAP)を使用した連絡先共有。

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

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

7.4.4. 近距離無線通信

デバイス実装は、近距離無線通信(NFC)用のトランシーバーと関連ハードウェアを含むべきです。NFC ハードウェアを含み、サードパーティ アプリがそれを利用できるようにする予定のデバイス実装には、以下の要件が適用されます。

  • android.content.pm.PackageManager.hasSystemFeature() メソッドを通じて、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 規格は「強く推奨される」(STRONGLY RECOMMENDED)と記載されていますが、将来のバージョンの互換性定義では「しなければならない」(「MUST」)に変更される予定です。これらの規格は、このバージョンでは任意ですが、将来のバージョンでは必須になります。このバージョンの Android を搭載した既存または新規のデバイスは、将来のプラットフォーム リリースにアップグレードできるように、これらの要件を満たすことが非常に強く奨励されます。
      • NfcV(ISO 15693)
    • Thinfilm NFC Barcode プロダクトのバーコードと URL(エンコードされている場合)の読み取りができるべきです。
    • 以下のピアツーピア規格とプロトコルを使用してデータを送受信できなければなりません。
      • ISO 18092
      • LLCP 1.2(NFC フォーラムにより定義)
      • SDP 1.0(NFC フォーラムにより定義)
      • NDEF プッシュ プロトコル
      • SNEP 1.0(NFC フォーラムにより定義)
    • Android ビームのサポートを含まなければなりません。
    • SNEP デフォルト サーバーを実装しなければなりません。デフォルト SNEP サーバーが受信した有効な NDEF メッセージは、android.nfc.ACTION_NDEF_DISCOVERED インテントを使用してアプリにディスパッチされなければなりません。設定で Android ビームを無効にすることにより、受信 NDEF メッセージのディスパッチを無効にしてはなりません。
    • android.settings.NFCSHARING_SETTINGS インテントを尊重して、NFC 共有設定を表示しなければなりません。
    • NPP サーバーを実装しなければなりません。NPP サーバーが受信したメッセージは、SNEP デフォルト サーバーと同じ方法で処理されなければなりません。
    • SNEP クライアントを実装し、Android ビームが有効になっているときはデフォルト SNEP サーバーへのアウトバウンド P2P NDEF の送信を試みなければなりません。デフォルト 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 を使用する場合、「Connection Handover バージョン 1.2」および NFC フォーラムの「Bluetooth Secure Simple Pairing Using NFC バージョン 1.0」の仕様を実装して、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(NfcA や NfcB)に対応した NFC コントローラ チップセットを含み、アプリ ID(AID)ルーティングをサポートする場合は、以下の要件が適用されます。

  • android.hardware.nfc.hce 機能定数を報告しなければなりません。
  • Android SDK で規定されているように、NFC HCE API をサポートしなければなりません。

デバイス実装が NfcF の HCE に対応した NFC コントローラ チップセットを含み、サードパーティ アプリ向けの機能を実装する場合は、以下の要件が適用されます。

  • android.hardware.nfc.hcef 機能定数を報告しなければなりません。
  • Android SDK で定義されているとおり、NfcF カード エミュレーション API を実装しなければなりません。

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

  • MIFARE Classic
  • MIFARE Ultralight
  • MIFARE Classic の NDEF

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

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

デバイス実装は、NFC ハードウェアを含まない場合、android.content.pm.PackageManager.hasSystemFeature() メソッドを通じて android.hardware.nfc 機能を宣言してはならず、Android NFC API を NOP として実装しなければなりません。

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

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

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

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

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

デバイスは、IPv6 ネットワーキング スタックを含まなければならず、java.net.Socketjava.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」を返すようにしなければなりません。

7.4.7. データセーバー

従量制接続を備えたデバイス実装は、データセーバー モードを提供することが強く推奨されます。

データセーバー モードを提供するデバイス実装には、以下の要件が適用されます。

  • SDK ドキュメントに記載されているように、ConnectivityManager クラスの API をすべてサポートしなければなりません。

  • 設定にユーザー インターフェースを提供して、ユーザーがアプリを許可リストに追加または許可リストから削除できるようにしなければなりません。

逆に、データセーバー モードを提供しないデバイス実装には、以下の要件が適用されます。

  • ConnectivityManager.getRestrictBackgroundStatus() に対して値 RESTRICT_BACKGROUND_STATUS_DISABLED を返さなければなりません。

  • ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED をブロードキャストしてはなりません。

  • Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS インテントを処理するアクティビティを含まなければなりませんが、それを NOP として実装しても構いません。

7.5. カメラ

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

少なくとも 1 つのカメラを含むデバイス実装は、デバイスの最大解像度のカメラセンサーによって生成される画像とサイズが等しい 3 つの RGBA_8888 ビットマップをアプリが同時に割り当てることができなければならず、その間もカメラで基本的なプレビューと静止画のキャプチャが可能でなければなりません。

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

7.5.3. 外部カメラ

デバイス実装は、常に接続されるとは限らない外部カメラのサポートを含んでも構いません。外部カメラのサポートを含むデバイスには、以下の要件が適用されます。

  • プラットフォーム機能フラグ android.hardware.camera.external および android.hardware camera.any を宣言しなければなりません。
  • 複数のカメラをサポートしても構いません。
  • 外部カメラが USB ポート経由で接続される場合は、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 ドキュメントに記載されている完全なカメラ API を実装しなければなりません。たとえば、オートフォーカスのないカメラは、登録された任意の android.hardware.Camera.AutoFocusCallback インスタンスを(オートフォーカスのないカメラと無関係であっても)呼び出さなければなりません。なお、これは前面カメラに適用されます。たとえば、ほとんどの前面カメラはオートフォーカスをサポートしませんが、それでも前述のように API コールバックを「偽装」しなければなりません。

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

すべてのデバイス実装が android.hardware.camera2 API のすべての機能を完全にサポートできるわけではないため、デバイス実装は、Android SDK ドキュメントに記載されているように、android.info.supportedHardwareLevel プロパティで適切なサポートレベルを報告し、該当するフレームワーク機能フラグを報告しなければなりません。

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

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

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

7.5.5. カメラの向き

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

7.6. メモリとストレージ

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

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

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

密度と画面サイズ 32 ビットデバイス 64 ビットデバイス
Android スマートウォッチ デバイス(画面が小さいため) 416 MB 該当なし
  • 小 / 標準画面で 280 dpi 以下
  • 大画面で mdpi 以下
  • 特大画面で ldpi 以下
512 MB 816 MB
  • 小 / 標準画面で xhdpi 以上
  • 大画面で hdpi 以上
  • 特大画面で mdpi 以上
608 MB 944 MB
  • 小 / 標準画面で 400 dpi 以上
  • 大画面で xhdpi 以上
  • 特大画面で tvdpi 以上
896 MB 1,280 MB
  • 小 / 標準画面で 560 dpi 以上
  • 大画面で 400 dpi 以上
  • 特大画面で xhdpi 以上
1,344 MB 1,824 MB

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

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

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

Android API には、アプリがデータファイルをダウンロードするために使用しても構わないダウンロード マネージャーが含まれています。ダウンロード マネージャーのデバイス実装は、サイズが 100 MB 以上のファイルを個別にデフォルトの「キャッシュ」ロケーションにダウンロードできなければなりません。

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

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

デバイス実装は、デフォルトでマウントされる共有ストレージをすぐに使えるように構成しなければなりません。共有ストレージが Linuxpath の /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 と互換性を持つべきです。
  • USB デバイスクラス 0x00 を報告するべきです。
  • USB インターフェース名「MTP」を報告するべきです。

7.6.3. Adoptable Storage

リムーバブル ストレージ デバイスのポートが長期的に安定している場所(バッテリー収納部や保護カバーの内側など)にある場合、デバイス実装は Adoptable Storage を実装することが強く推奨されます。

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

7.7. USB

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

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

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

  • ポートは、標準の Type-A または Type-C USB ポートを持つ USB ホストに接続可能でなければなりません。
  • ポートは、Micro-B、Micro-AB、または Type-C の USB フォーム ファクタを使用するべきです。既存と新規の Android デバイスは、将来のプラットフォーム リリースにアップグレードできるように、これらの要件を満たすことが強く推奨されます
  • ポートを(自然な向きに応じて)デバイスの底面に配置するか、すべてのアプリ(ホーム画面を含む)でソフトウェアの画面回転を可能にすることにより、デバイスのポートが底面に来たときにディスプレイが正しく描画されるようにするべきです。既存と新規の Android デバイスは、将来のプラットフォーム リリースにアップグレードできるように、これらの要件を満たすことが強く推奨されます
  • Android デバイスに接続されている USB ホストが、USB マスストレージまたはメディア転送プロトコルを使用して共有ストレージ ボリュームのコンテンツにアクセスできるようにしなければなりません。
  • Android SDK ドキュメントに記載されているように、Android Open Accessory(AOA)の API と仕様を実装するべきであり、Android ハンドヘルド デバイスの場合は AOA API を実装しなければなりません。AOA 仕様を実装するデバイス実装には、以下の要件が適用されます。
    • ハードウェア機能 android.hardware.usb.accessory のサポートを宣言しなければなりません。
    • Android SDK ドキュメントに記載されているように、USB オーディオ クラスを実装しなければなりません。
    • USB マスストレージ クラスは、USB マスストレージのインターフェース記述である iInterface 文字列の末尾に文字列「android」を含まなければなりません。
  • USB バッテリー充電仕様リビジョン 1.2 で規定されているように、HS チャープおよびトラフィックの際に 1.5 A の電流を流すためのサポートを実装するべきです。既存と新規の Android デバイスは、将来のプラットフォーム リリースにアップグレードできるように、これらの要件を満たすことが強く推奨されます
  • Type-C デバイスは、Type-C 抵抗規格に従って 1.5 A と 3.0 A の充電器を検出しなければならず、アドバタイズメントの変更を検出しなければなりません。
  • USB ホストモードもサポートする Type-C デバイスは、データと電源をロールスワップするために Power Delivery をサポートすることが強く推奨されます。
  • Type-C デバイスは、高電圧充電のために Power Delivery をサポートするとともに、ディスプレイ出力などの代替モードをサポートするべきです。
  • USB 標準デバイス記述子の iSerialNumber の値は、android.os.Build.SERIAL の値と等しくなければなりません。
  • Type-C デバイスは、デフォルト レベルを超えて Vbus 電圧を変更するかシンク / ソースの役割を変更する独自の充電方法をサポートしないことが強く推奨されます。サポートすると、標準の USB Power Delivery の方法をサポートする充電器またはデバイスとの相互運用性の問題が生じるおそれがあるからです。ここでは「強く推奨される」(「STRONGLY RECOMMENDED」)と記載されていますが、将来の Android バージョンでは、すべての Type-C デバイスが標準の Type-C 充電器との完全な相互運用性をサポートすることが必須(「REQUIRED」)になる可能性があります。

7.7.2. USB ホストモード

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

  • デバイス実装が USB 3.1 をサポートする場合は、Type-C USB ポートを使用するべきです。
  • 標準以外のポートのフォーム ファクタを使用しても構いませんが、使用する場合は、ポートを標準の Type-A または Type-C USB ポートに適合させるケーブルを同梱しなければなりません。
  • Micro-AB USB ポートを使用しても構いませんが、使用する場合は、ポートを標準の Type-A または Type-C USB ポートに適合させるケーブルを同梱するべきです。
  • Android SDK ドキュメントに記載されているように、USB オーディオ クラスを実装することが強く推奨されます
  • Android SDK に記載されているように Android USB ホスト API を実装しなければならず、ハードウェア機能 android.hardware.usb.host のサポートを宣言しなければなりません。
  • ホストモード時の充電をサポートするべきです。そのためには、USB Type-C コネクタの場合は、[USB Type-C ケーブルおよびコネクタ仕様リビジョン 1.2](http://www.usb.org/developers/docs/usb_31_021517.zip) の停止パラメータ セクションで規定されているように、少なくとも 1.5 A のソース電流をアドバタイズし、Micro-AB コネクタの場合は、USB バッテリー充電仕様リビジョン 1.2 で規定されているように、充電ダウンストリーム ポート(CDP)の出力電流範囲を使用します。
  • USB Type-C デバイスは、DisplayPort をサポートすることが強く推奨され、USB SuperSpeed データ速度をサポートするべきであり、データと電源をロールスワップするために Power Delivery をサポートすることが強く推奨されます。
  • Type-A ポートまたは Type-AB ポートを備えたデバイスは、このポートから Type-C レセプタクルに変換するアダプターを同梱してはなりません。
  • ストレージ アクセス フレームワーク(SAF)がサポートされている場合は、リモート接続された MTP(メディア転送プロトコル)デバイスを認識し、そのコンテンツをインテント ACTION_GET_CONTENTACTION_OPEN_DOCUMENTACTION_CREATE_DOCUMENT を通じてアクセス可能にしなければなりません。
  • Type-C USB ポートを使用し、ペリフェラル モードのサポートを含む場合は、USB Type-C 仕様(セクション 4.5.1.3.3)で規定されているように、デュアルロール ポート機能を実装しなければなりません。
  • デュアルロール ポート機能がサポートされている場合は、デバイスのフォーム ファクタに最も適した Try.* モデルを実装するべきです。たとえば、ハンドヘルド デバイスは Try.SNK モデルを実装するべきです。

7.8. オーディオ

7.8.1. マイク

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

デバイス実装はマイクを省略しても構いません。ただし、デバイス実装がマイクを省略する場合は、android.hardware.microphone 機能定数を報告してはならず、セクション 7 に記載されているように、オーディオ録音 API を少なくとも NOP として実装しなければなりません。逆に、マイクを備えたデバイス実装には、以下の要件が適用されます。

  • 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.output 機能定数を報告してはならず、オーディオ出力関連の API を少なくとも NOP として実装しなければなりません。

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

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

3.5 mm オーディオ プラグを使用するヘッドセットとその他のオーディオ アクセサリとの互換性を Android エコシステム全体で確保するため、デバイス実装が 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」の場合、VOICE_RECOGNITION と UNPROCESSED の音源は以下の要件を満たさなければなりません。
    • 18.5 kHz から 20 kHz の帯域におけるマイクの平均電力感度が、2 kHz における感度より下 15 dB 以内でなければなりません。
    • -26 dBFS の 19 kHz トーンについて、18.5 kHz から 20 kHz におけるマイクの非加重信号対雑音比が 50 dB 以上でなければなりません。
  • PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND が「true」の場合、18.5 kHz から 20 kHz におけるスピーカーの平均感度が、2 kHz における感度より下 40 dB 以内でなければなりません。

7.9. バーチャル リアリティ

Android には、高品質のモバイル VR エクスペリエンスを含む「バーチャル リアリティ」(VR)アプリを構築するための API と機能があります。このセクションで詳述しているように、デバイス実装はこれらの API と動作を適切に実装しなければなりません。

7.9.1. バーチャル リアリティ モード

VR アプリにユーザー フォーカスがある間は通知の立体画像レンダリングを処理して単眼式のシステム UI コンポーネントを無効にするモードを VR アプリでサポートする Android ハンドヘルド デバイス実装は、android.software.vr.mode 機能を宣言しなければなりません。この機能を宣言するデバイスは、VR アプリが android.app.Activity#setVrModeEnabled を使用して有効にできる android.service.vr.VrListenerService を実装するアプリを含まなければなりません。

7.9.2. バーチャル リアリティの高パフォーマンス

Android ハンドヘルド デバイス実装は、android.hardware.vr.high_performance 機能フラグを通じて、長時間使用するユーザーに対する高パフォーマンス バーチャル リアリティのサポートを表明し、以下の要件を満たさなければなりません。

  • デバイス実装は、少なくとも 2 つの物理コアを持たなければなりません。
  • デバイス実装は、android.software.vr.mode 機能を宣言しなければなりません。
  • デバイス実装は、フォアグラウンド アプリに専用コアを提供しても構いません。また、トップ フォアグラウンド アプリ専用の CPU コアの数を返すために Process.getExclusiveCores API をサポートしても構いません。専用コアがサポートされている場合は、そのコアで他のユーザー空間プロセスを実行できるようにしてはなりませんが(アプリが使用するデバイス ドライバを除く)、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。
  • デバイス実装は、パフォーマンス維持モードをサポートしなければなりません。
  • デバイス実装は、OpenGL ES 3.2 をサポートしなければなりません。
  • デバイス実装は、Vulkan ハードウェア レベル 0 をサポートしなければならず、Vulkan ハードウェア レベル 1 をサポートするべきです。
  • デバイス実装は、EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_create_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync を実装し、それらを共有バッファモードで使用できるようにするとともに、利用可能な EGL 拡張機能のリストでこれらの拡張機能を公開しなければなりません。
  • GPU とディスプレイは、2 つのレンダリング コンテキストを使用して VR コンテンツを 60 fps で左右の視界に交互にレンダリングする場合に、対象が明らかに分かれて表示されることがないように、共有フロント バッファへのアクセスを同期できなければなりません。
  • デバイス実装は、EGL_IMG_context_priority を実装し、利用可能な EGL 拡張機能のリストでこの拡張機能を公開しなければなりません。
  • デバイス実装は、GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2、GL_OVR_multiview_multisampled_render_to_texture を実装し、利用可能な GL 拡張機能のリストでこれらの拡張機能を公開しなければなりません。
  • デバイス実装は、セキュア テクスチャ動画再生で使用できるように EGL_EXT_protected_content と GL_EXT_protected_textures を実装し、利用可能な EGL および GL 拡張機能のリストでこれらの拡張機能を公開しなければなりません。
  • デバイス実装は、30 fps~40 Mbps で少なくとも 3,840x2,160 の H.264 デコードをサポートしなければなりません(これは、30 fps~10 Mbps で 1,920x1,080 の 4 インスタンス、または 60 fps~20 Mbps で 1,920x1,080 の 2 インスタンスに相当します)。
  • デバイス実装は HEVC と VP9 をサポートしなければならず、30 fps~10 Mbps で少なくとも 1,920x1,080 のデコードができなければならず、30 fps~20 Mbps で 3,840x2,160 のデコードができるべきです(これは、30 fps~-5 Mbps で 1,920x1,080 の 4 インスタンスに相当します)。
  • デバイス実装は、android.hardware.sensor.hifi_sensors 機能をサポートすることが強く推奨され、ジャイロスコープ、加速度計、磁力計に関連する android.hardware.hifi_sensors の要件を満たさなければなりません。
  • デバイス実装は、HardwarePropertiesManager.getDeviceTemperatures API をサポートし、皮膚温の正確な値を返さなければなりません。
  • デバイス実装は、埋め込み画面を備えていなければなりません。その解像度は少なくとも FullHD(1080p)でなければならず、QuadHD(1440p)以上であることが強く推奨されます。
  • ディスプレイは、対角サイズが 4.7~6 インチでなければなりません。
  • ディスプレイは、VR モードのときは少なくとも 60 Hz で更新されなければなりません。
  • グレーからグレー、白から黒、黒から白への切り替え時間の表示レイテンシが 3 ミリ秒以下でなければなりません。
  • ディスプレイは、持続時間が 5 ミリ秒以下の低持続モードをサポートしなければなりません(持続時間は、ピクセルが発光している時間として定義されます)。
  • デバイス実装は、Bluetooth 4.2 と Bluetooth LE データ長拡張機能をサポートしなければなりません(セクション 7.4.3)。

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

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

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

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

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

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

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

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

8.3. 省電力モード

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

Android デバイス実装は、省電力モードに加えて、Advanced Configuration and Power Interface(ACPI)で定義されている 4 つのスリープ電力状態の一部または全部を実装しても構いませんが、S3 および S4 電力状態を実装する場合は、デバイスの物理的な一部である蓋を閉じたときに限り、それらの状態に移行できます。

8.4. 消費電力の算出

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

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

8.5. 一貫したパフォーマンス

長時間実行される高パフォーマンス アプリは、バックグラウンドで実行されている他のアプリまたは温度制限による CPU スロットリングが原因で、パフォーマンスが大きく変動することがあります。Android にはプログラマティック インターフェースがあるため、デバイスで使用可能な場合、トップ フォアグラウンド アプリは、このような変動に対処するためにリソースの割り当てを最適化するようシステムにリクエストできます。

デバイス実装は、Window.setSustainedPerformanceMode() API メソッドを通じてリクエストされたときに、長時間にわたって一貫したレベルのパフォーマンスをトップ フォアグラウンド アプリに提供できるパフォーマンス維持モードをサポートするべきです。デバイス実装は、PowerManager.isSustainedPerformanceModeSupported() API メソッドを通じてパフォーマンス維持モードのサポートを正確に報告しなければなりません。

2 つ以上の CPU コアを備えたデバイス実装は、トップ フォアグラウンド アプリが予約できる専用コアを少なくとも 1 つ提供するべきです。提供する場合、実装は以下の要件を満たさなければなりません。

  • 実装は、Process.getExclusiveCores() API メソッドを通じて、トップ フォアグラウンド アプリが予約できる専用コアの ID 番号を報告しなければなりません。
  • デバイス実装は、アプリが使用するデバイス ドライバを除くユーザー空間プロセスを専用コアで実行できるようにしてはなりませんが、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。

デバイス実装が専用コアをサポートしない場合は、Process.getExclusiveCores() API メソッドを通じて空のリストを返さなければなりません。

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

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

9.1. 権限

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

protectionLevel'PROTECTION_FLAG_PRIVILEGED' である権限は、システム イメージの許可リストに登録された特権パス(AOSP 実装の system/priv-app パスなど)にプリロードされたアプリにのみ付与しなければなりません。

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

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

9.2. UID とプロセスの分離

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

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

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

9.4. 代替実行環境

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

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

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

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

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

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

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

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

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

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

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

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

9.6. プレミアム SMS の警告

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

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

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

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

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

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

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

  • SELinux をグローバル enforcing モードに設定しなければなりません。
  • すべてのドメインを enforcing モードで構成しなければなりません。デバイス / ベンダー固有のドメインを含め、permissive モードのドメインは許可されません。
  • アップストリームの Android オープンソース プロジェクト(AOSP)で提供されている system/sepolicy フォルダ内に存在する neverallow ルールの変更、省略、または置き換えを行ってはなりません。また、AOSP SELinux ドメインとデバイス / ベンダー固有のドメインの両方について、すべての neverallow ルールが存在する状態でポリシーをコンパイルしなければなりません。
  • Android オープンソース プロジェクトのサイトに記載されているように、メディア フレームワークを複数のプロセスに分割して、より細かく絞り込んだアクセス権を各プロセスに付与できるようにしなければなりません。

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

デバイスは、マルチスレッド プログラムから構成可能なポリシーを使用してシステムコールをフィルタリングできるようにするカーネルアプリ サンドボックス化メカニズムを実装しなければなりません。アップストリームの Android オープンソース プロジェクトは、source.android.com のカーネル構成セクションに記載されているように、スレッドグループ同期(TSYNC)で seccomp-BPF を有効にすることで、この要件を満たしています。

9.8. プライバシー

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

デフォルトでプロキシ サーバーまたは VPN ゲートウェイ経由でネットワーク データ トラフィックをルーティングするメカニズムをデバイス実装が備えている(例: android.permission.CONTROL_VPN が付与された VPN サービスをプリロードする)場合は、そのメカニズムを有効にする前にユーザーの同意を求めなければなりません。ただし、DevicePolicyManager.setAlwaysOnVpnPackage() を介して Device Policy Controller がその VPN を有効にしている場合は除きます。その場合、ユーザーが個別に同意する必要はありませんが、ユーザーへの通知だけは行わなければなりません。

デバイス実装は、ユーザーが追加する認証局(CA)ストアを空にして出荷しなければならず、システムが信頼する CA ストアにはアップストリームの Android オープンソース プロジェクトが提供するものと同じルート証明書をプリインストールしなければなりません。

デバイスが VPN 経由でルーティングされる場合またはユーザーのルート CA がインストールされている場合、実装は、ネットワーク トラフィックが監視される可能性があることをユーザーに伝える警告を表示しなければなりません。

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

9.9. データ ストレージ暗号化

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

デバイス実装がセクション 9.11.1 に記載されているセキュアロック画面をサポートしている場合、デバイスは、アプリの個人データ(/data パーティション)のデータ ストレージ暗号化をサポートしなければならず、デバイスの永続的な非リムーバブル型の部品である場合はアプリの共有ストレージ パーティション(/sdcard パーティション)のデータ ストレージ暗号化もサポートしなければなりません。

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

デバイス実装は、ファイルベース暗号化(FBE)を実装することにより、上記のデータ ストレージ暗号化の要件を満たすべきです。

9.9.1. ダイレクト ブート

すべてのデバイスは、ストレージ暗号化をサポートしない場合でも、ダイレクト ブート モード API を実装しなければなりません。特に、LOCKED_BOOT_COMPLETED インテントと ACTION_USER_UNLOCKED インテントは、デバイス暗号化(DE)ストレージと証明書暗号化(CE)ストレージのロケーションをユーザーが使用できることをダイレクト ブート対応アプリに通知するために、引き続きブロードキャストされなければなりません。

9.9.2. ファイルベース暗号化

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

  • ユーザーに認証情報を求めることなく起動し、LOCKED_BOOT_COMPLETED メッセージがブロードキャストされた後でダイレクト ブート対応アプリがデバイス暗号化(DE)ストレージにアクセスできるようにしなければなりません。
  • ユーザーが認証情報(パスコード、PIN、パターン、指紋など)を指定してデバイスをロック解除し、ACTION_USER_UNLOCKED メッセージがブロードキャストされて初めて、認証情報暗号化(CE)ストレージにアクセスできるようにしなければなりません。デバイス実装は、ユーザーが指定する認証情報なしに CE 保護ストレージをロック解除する方法を提供してはなりません。
  • 確認付きブートをサポートし、DE 鍵がデバイスのハードウェアのルート オブ トラストに暗号を用いてバインドされることを保証しなければなりません。
  • XTS モードで鍵長 256 ビットの AES を使用するファイル コンテンツの暗号化をサポートしなければなりません。
  • CBC-CTS モードで鍵長 256 ビットの AES を使用するファイル名の暗号化をサポートしなければなりません。
  • ファイル コンテンツとファイル名の暗号化について代替の暗号、鍵長、モードをサポートしても構いませんが、デフォルトでは必須としてサポートされている暗号、鍵長、モードを使用しなければなりません。
  • 必須のプリインストール アプリ(アラーム、電話、メッセンジャーなど)は、ダイレクト ブート対応にするべきです。

CE ストレージと DE ストレージの領域を保護する鍵には、以下の要件が適用されます。

  • ハードウェア格納型キーストアに暗号を用いてバインドされなければなりません。CE 鍵は、ユーザーのロック画面認証情報にバインドされなければなりません。ユーザーがロック画面認証情報を指定しなかった場合、CE 鍵はデフォルトのパスコードにバインドされなければなりません。
  • 一意かつ固有でなければなりません(言い換えると、ユーザーの CE 鍵または DE 鍵が他のユーザーの CE 鍵または DE 鍵と一致してはなりません)。

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

9.9.3. フルディスク暗号化

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

9.10. デバイスの完全性

次の要件により、デバイスの完全性の状態に透明性が確保されます。

デバイス実装は、システム API メソッド PersistentDataBlockManager.getFlashLockState() を通じて、ブートローダーの状態がシステム イメージの書き込みを許可するかどうかを正しく報告しなければなりません。FLASH_LOCK_UNKNOWN 状態は、この新しいシステム API メソッドが存在しなかった以前の Android バージョンからアップグレードされるデバイス実装用に予約されています。

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

  • プラットフォーム機能フラグ android.software.verified_boot を宣言しなければなりません。
  • ブート シーケンスごとに確認を実施しなければなりません。
  • ルート オブ トラストである不変のハードウェア キーから始めて、システム パーティションに至るすべてのものを確認しなければなりません。
  • 確認の各ステージを実装し、次のステージのすべてのバイトの完全性と真正性をチェックしてから、次のステージのコードを実行しなければなりません。
  • ハッシュ アルゴリズム(SHA-256)と公開鍵サイズ(RSA-2048)について、NIST による現在の推奨と同程度に強力な確認アルゴリズムを使用しなければなりません。
  • システムの確認が失敗したときに起動の完了を許可してはなりません。ただし、そのようなときでも起動を試行することにユーザーが同意している場合は除きます。その場合は、確認されなかったストレージ ブロックのデータを使用してはなりません。
  • デバイスの確認済みパーティションの変更を許可してはなりません。ただし、ユーザーがブートローダーを明示的にロック解除した場合は除きます。

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

Android 6.0 以降では、Advanced Encryption Standard(AES)暗号パフォーマンスが 50 MiB/秒を超えるデバイス実装は、デバイスの完全性を保証するために確認付きブートをサポートしなければなりません。

確認付きブートがサポートされていない以前の Android バージョンでデバイス実装がすでにリリースされている場合、そのようなデバイスはシステム ソフトウェア アップデートを通じてこの機能のサポートを追加することができないため、この要件を免除されます。

9.11. 鍵と認証情報

Android Keystore システムにより、アプリ デベロッパーは暗号鍵をコンテナに格納し、KeyChain API または Keystore API を介して暗号オペレーションでそれらを使用できます。

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

  • 生成可能な鍵の数を制限するべきではなく、少なくとも 8,192 個を超える鍵をインポートできるようにしなければなりません。
  • ロック画面認証は試行をレート制限しなければならず、指数バックオフ アルゴリズムを備えなければなりません。試行の失敗が 150 回を超えたら、1 回の試行につき少なくとも 24 時間の遅延を行わなければなりません。
  • デバイス実装がセキュアロック画面をサポートする場合は、安全なハードウェアでキーストア実装を支えるとともに、以下の要件を満たさなければなりません。
    • カーネル以上の層で動作するコードから安全に隔離された領域で Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムの実装と MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離により、カーネルまたはユーザー空間のコードが DMA を含む隔離された環境の内部状態にアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト(AOSP)は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューションや、適切なハイパーバイザ ベースの隔離の安全な実装(サードパーティによるレビュー済みのもの)も代替オプションとなります。
    • 隔離された実行環境でロック画面認証を実施しなければならず、認証が成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer(HAL)と Trusty を提供しており、それらを使用してこの要件を満たすことができます。

なお、以前の Android バージョンでデバイス実装がすでにリリースされている場合、そのようなデバイスは、ハードウェア格納型キーストアを要求する android.hardware.fingerprint 機能を宣言していない限り、ハードウェア格納型キーストアを必須とする要件を免除されます。

9.11.1. セキュアロック画面

デバイス実装は、ロック画面をロック解除するための認証方法を追加または変更しても構いませんが、その場合でも以下の要件を満たさなければなりません。

  • 既知のシークレットに基づく認証方法は、以下の要件をすべて満たさない限り、セキュアロック画面として扱ってはなりません。
    • 入力の最短許容長のエントロピーが 10 ビットより大きくなければなりません。
    • すべての可能な入力の最大エントロピーが 18 ビットより大きくなければなりません。
    • AOSP で実装されて提供されている既存の認証方法(PIN、パターン、パスワード)を置き換えてはなりません。
    • Device Policy Controller(DPC)アプリが DevicePolicyManager.setPasswordQuality() メソッドを通じて PASSWORD_QUALITY_SOMETHING より制限が厳しい品質定数でパスワード品質ポリシーを設定した場合は、無効にしなければなりません。
  • 物理トークンまたはロケーションに基づく認証方法は、以下の要件をすべて満たさない限り、セキュアロック画面として扱ってはなりません。
    • 既知のシークレットに基づき、セキュアロック画面として扱われる要件を満たすプライマリ認証方法の 1 つを使用するフォールバック メカニズムを備えていなければなりません。
    • Device Policy Controller(DPC)アプリが DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) メソッドまたは DevicePolicyManager.setPasswordQuality() メソッドを通じて PASSWORD_QUALITY_UNSPECIFIED より制限が厳しい品質定数でポリシーを設定した場合は、無効にしなければならず、プライマリ認証にのみ画面のロック解除を許可しなければなりません。
  • 生体認証に基づく認証方法は、以下の要件をすべて満たさない限り、セキュアロック画面として扱ってはなりません。
    • 既知のシークレットに基づき、セキュアロック画面として扱われる要件を満たすプライマリ認証方法の 1 つを使用するフォールバック メカニズムを備えていなければなりません。
    • Device Policy Controller(DPC)アプリがメソッド DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) を呼び出して keguard 機能ポリシーを設定した場合は、無効にしなければならず、プライマリ認証にのみ画面のロック解除を許可しなければなりません。
    • 他人受け入れ率が指紋認証センサー要件の最大値(セクション 7.3.10 に記載)以下でなければなりません。そうでないときは、Device Policy Controller(DPC)アプリが DevicePolicyManager.setPasswordQuality() メソッドを通じて PASSWORD_QUALITY_BIOMETRIC_WEAK より制限が厳しい品質定数でパスワード品質ポリシーを設定した場合は無効にしなければならず、プライマリ認証にのみ画面のロック解除を許可しなければなりません。
  • セキュアロック画面として扱うことができない認証方法には、以下の要件が適用されます。
  • 認証方法が物理トークンまたはロケーションに基づいている場合、あるいは生体認証に基づいていて他人受け入れ率が指紋認証センサー要件の最大値(セクション 7.3.10 に記載)より高い場合、認証方法には以下の要件が適用されます。

9.12. データの削除

デバイスは、次のものを除くすべてのデータを論理的かつ物理的に削除できる「データの初期化」を行うメカニズムをユーザーに提供しなければなりません。

  • システム イメージ
  • システム イメージが必要とするすべてのオペレーティング システム ファイル

ユーザーが生成したデータはすべて削除しなければなりません。このメカニズムは、データ削除に関連する業界基準(NIST SP800-88 など)を満たさなければなりません。セクション 3.9 デバイス管理に記載されている wipeData() API(Android Device Administration API の一部)の実装にこのメカニズムを使用しなければなりません。

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

9.13. セーフブート モード

Android では、プリインストール済みシステムアプリのみが実行を許可され、すべてのサードパーティ アプリが無効にされた状態で起動できるモードがユーザーに提供されています。この「セーフブート モード」と呼ばれるモードでは、有害な可能性があるサードパーティ アプリをアンインストールする機能がユーザーに提供されます。

Android デバイス実装は、セーフブート モードを実装し、以下の要件を満たすことが強く推奨されます。

  • デバイス実装は、通常の起動とは異なるワークフローでアクセスできる起動メニューからセーフブート モードに入るオプションをユーザーに提供するべきです。

  • デバイス実装は、デバイスにインストールされているサードパーティ アプリから中断できない方法でセーフブート モードに入るオプションをユーザーに提供しなければなりません。ただし、サードパーティ アプリが Device Policy Controller で、UserManager.DISALLOW_SAFE_BOOT フラグを true に設定している場合は除きます。

  • デバイス実装は、セーフモード内でサードパーティ アプリをアンインストールする機能をユーザーに提供しなければなりません。

9.14. Automotive の車両システムの分離

Android Automotive デバイスは、重要な車両サブシステムとデータを交換することが想定されています。そのためには、たとえば車両 HAL を使用して、CAN バスなどの車両ネットワーク経由でメッセージを送受信します。Android Automotive デバイス実装は、Android フレームワークまたはサードパーティ アプリと車両サブシステムの間の悪意のある操作または意図しない操作を防ぐために、Android フレームワーク レイヤの下にセキュリティ機能を実装しなければなりません。そうしたセキュリティ機能には次のものがあります。

  • Android フレームワークの車両サブシステムからのメッセージのゲートキーピング(例: 許可されるメッセージ タイプとメッセージ ソースを許可リストに登録する)。
  • Android フレームワークまたはサードパーティ アプリからのサービス拒否攻撃に対するウォッチドッグ。これは、悪意のあるソフトウェアによる車両ネットワークへのトラフィックのフラッディング(車両サブシステムの誤作動を招くおそれがあります)を防ぎます。

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

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

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

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

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

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

10.2. CTS 検証ツール

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

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

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

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

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

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

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

ただし、802.11 や Bluetooth PAN(パーソナル エリア ネットワーク)プロファイルなど、定額制データ接続のサポートが含まれる場合、デバイス実装は、再起動によるオフライン アップデートを使用して OTA ダウンロードをサポートしなければなりません。

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

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

また、デバイス実装は A/B システム アップデートをサポートするべきです。AOSP は、ブート コントロール HAL を使用してこの機能を実装しています。

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

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

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

このリリースにおける互換性定義に対する変更の概要は次のとおりです。

個々のセクションに対する変更の概要は次のとおりです。

  1. はじめに
  2. デバイスタイプ
  3. ソフトウェア
  4. アプリのパッケージング
  5. マルチメディア
  6. デベロッパー ツールと開発者向けオプション
  7. ハードウェアの互換性
  8. パフォーマンスと電力
  9. セキュリティ モデル
  10. ソフトウェア互換性テスト
  11. アップデート可能なソフトウェア
  12. ドキュメントの変更履歴
  13. お問い合わせ

12.1. 変更履歴を確認する際のヒント

変更は次のようにマークされます。

  • CDD
    互換性の要件に対する重大な変更。

  • Docs
    ドキュメントの外観または構成に関連する変更。

変更履歴の URL に、URL パラメータ pretty=fullno-merges を追加することをおすすめします。

13. お問い合わせ

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