Android 7.0(N)互換性定義

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。
目次

1. はじめに

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

「しなければならない」「してはならない」「要求される」「するものとする」「しないものとする」「すべきである」「すべきではない」「推奨される」「しても構わない」「任意」の使用は、それぞれ、RFC2119 で規定されている IETF 標準の「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」の解釈に従います。

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

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

この定義、またはセクション 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.0 互換となるにはこのドキュメントに記載されている要件をすべて満たさなければなりません。ただし、上記の特定の 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 の互換性

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

3.2.1. 権限

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

3.2.2. ビルド パラメータ

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

パラメータ 詳細
VERSION.RELEASE 現在実行している Android システムのバージョン(人が読める形式)。このフィールドには、7.0 で定義された文字列値のいずれかを指定しなければなりません。
VERSION.SDK 現在実行している Android システムのバージョン(サードパーティ アプリコードからアクセスできる形式)。Android 7.0 の場合、このフィールドには整数値 7.0_INT を指定しなければなりません。
VERSION.SDK_INT 現在実行している Android システムのバージョン(サードパーティ アプリコードからアクセスできる形式)。Android 7.0 の場合、このフィールドには整数値 7.0_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.0/LMYXX/3359:userdebug/test-keys

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

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

3.2.3. インテントの互換性

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

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

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

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

3.2.3.2. インテントの解決

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

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

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

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

  • アップストリームの Android オープンソース プロジェクトのパッケージ マネージャーで実装される、Digital Asset Links 仕様で規定されている検証手順を実施することで、インテント フィルタの検証を試行しなければなりません。
  • アプリのインストール中にインテント フィルタの検証を試行し、検証に合格したすべての 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 インテントを尊重して、ユーザーがデフォルトの電話アプリを変更できるダイアログを表示しなければなりません。

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.sovkEnumerateInstanceLayerPropertiesvkEnumerateDeviceLayerProperties を通じて、アプリ パッケージのネイティブ ライブラリ ディレクトリにある 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 を使用してビルドしたアプリとの互換性を確保するため、デバイスは、32 ビット ARM アプリによって読み取られる場合、/proc/cpuinfo に次の行を含まなければなりません。

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

上記の要件は、/proc/cpuinfo が 32 ビット ARM アプリケーションによって読み取られる場合にのみ適用されます。デバイスは、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.0 用のアップストリームの 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 Automotive の実装は、ブラウザアプリを省略しても構いませんが、セクション 3.2.3.1 に記載されているとおり、公開のインテント パターンをサポートしなければなりません。その他のすべての種類のデバイス実装では、一般ユーザーのウェブ ブラウジング用のスタンドアロン ブラウザアプリを配置しなければなりません。

スタンドアロン ブラウザは、WebKit 以外のブラウザ テクノロジーをベースにするものであっても構いません。ただし、代替ブラウザアプリを使用する場合でも、サードパーティ アプリに提供する android.webkit.WebView コンポーネントは、セクション 3.4.1 に記載されているように、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 バイトコードの仕様とセマンティクスをサポートしなければなりません。デバイス実装は、Dalvik 実行ファイル形式のリファレンス アップストリーム実装であり、リファレンス実装のパッケージ管理システムでもある ART を使用すべきです。

デバイス実装では、アップストリームの 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 を NoOps として実装しなければなりません。この動作の詳細についてはセクション 7 をご覧ください。

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

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

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

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

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

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

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

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

3.8.5. トースト

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

3.8.6. テーマ

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

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

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

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 で詳述するように、履歴機能のナビゲーション キーを含むデバイス実装は、インターフェースを変更しても構いませんが、以下の要件を満たさなければなりません。

  • 少なくとも 6 つまでのアクティビティ表示をサポートしなければなりません。
  • 少なくとも同時に 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 は、障がいのあるユーザーがより簡単にデバイスを操作できるようにするためのユーザー補助レイヤを提供します。また、ユーザー補助サービスの実装によってユーザーとシステム イベントのコールバックを受信し、テキスト読み上げ、触覚フィードバック、トラックボール / D-pad ナビゲーションなどの代替フィードバック メカニズムを生成できるプラットフォーム API を提供します。

デバイス実装には、次の要件が含まれます。

  • Android Automotive 実装は、デフォルトの Android 実装と整合する Android ユーザー補助フレームワークの実装を提供すべきです。
  • デバイス実装(Android Automotive を除く)は、デフォルトの Android 実装と整合する Android ユーザー補助フレームワークの実装を提供しなければなりません。
  • デバイス実装(Android Automotive を除く)は、android.accessibilityservice API を介してサードパーティのユーザー補助サービス実装をサポートしなければなりません。
  • デバイス実装(Android Automotive を除く)は、デフォルトの Android 実装との一貫性を維持するような方法で、AccessibilityEvents を生成し、登録されているすべての 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 があります。これは、サードパーティ アプリで、クイック設定 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 バイトコードのいずれかの形式を、他の互換デバイスでファイルのインストールと実行が正しく行われないような方法で拡張してはなりません。

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.12 コンテンツをサポート。
  • 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.12 コンテンツをサポート。
MPEG-4 HE AACv2
プロファイル(Enhanced AAC+)
必須 標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.12 コンテンツをサポート。
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 デコード プロファイルがサポートされている場合、コーデックは Main10 Level 5 Main Tier のプロファイルをサポートしなければなりません。
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 以降「すべき」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。既存と新規の Android デバイスは、「すべき」として記載されている要件を満たすことが強く推奨されます。満たさなかった場合、今後のバージョンにアップグレードした際に、Android の互換性が得られなくなります。

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

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

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

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

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

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

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

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

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

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

5.5. オーディオの再生

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

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

デバイスは、次の特性を持つ未加工オーディオ コンテンツをキャプチャできなければなりません。

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

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

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

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

Android は、デバイス実装にオーディオ エフェクト用の API を提供します。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 バッファキュー APIAndroid 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)モバイル デバイス(ジャック)の仕様のセクションを遵守することが強く推奨されます。

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

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

  • オーディオがアクティブである間、持続可能な 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 ドキュメントに記載されているとおり、dumpsys を含め、adb のすべての機能をサポートしなければなりません。
    • デバイス側の 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(small)以上でなければなりません。ただし、Android スマートウォッチ デバイスは除きます。
  • 画面サイズが「normal」であるとレポートするデバイスは、画面サイズが 480 dp x 320 dp 以上でなければなりません。
  • 画面サイズ「large」をレポートするデバイスは、640 dp x 480 dp 以上の画面サイズでなければなりません。
  • 画面サイズ「xlarge」をレポートするデバイスは、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 ドキュメントに記載されているように、small、normal、large、xlarge の画面についてアプリが表明しているサポートを正しく尊重しなければなりません。

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

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

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

デバイス実装は、ディスプレイ サイズを変更する設定をユーザーに提供することが強く推奨されます。デバイスのディスプレイ サイズを変更する実装がある場合、その実装は下記の 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 View 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 の旧バージョン用に開発されていないレガシーアプリを活用するために、フレームワークが「normal」画面サイズ相当(幅 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 は両方の実装をサポートしています。これらすべての機能は、表示されているとき、1 つのアクション(タップ、ダブルクリック、ジェスチャーなど)でアクセスできなければなりません。

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

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

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

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

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

Assist アクションVoiceInteractionService の両方または一方をサポートする Android デバイス実装では、他のナビゲーション キーが表示されている場合に 1 回の操作(タップ、ダブルクリック、ジェスチャーなど)でアシストアプリを起動できなければなりません。この操作として、ホームの長押しを使用することが強く推奨されます。指定された操作は、ユーザーが選択するアシストアプリ(つまり、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.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 を起動しなければなりません。
  • ナビゲーション。すべての 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 m/s2 未満で移動している間、以下の要件を満たす必要があります。
    • 少なくとも 95% の時間で、位置を 20 m 以内、速度を 0.5 m/s 以内で決定できなければなりません。
    • 1 つのコンステレーションから少なくとも 8 つの衛星を、GnssStatus.Callback を介して同時に追跡し、レポートしなければなりません。
    • 複数のコンステレーションから少なくとも 24 の衛星を同時にトラックできるべきです(例: GPS と、Glonass、Beidou、Galileo のうち少なくとも 1 つ)。
  • テスト API「getGnssYearOfHardware」を通じて GNSS テクノロジーの生成をレポートしなければなりません。
  • GNSS テクノロジーの世代が「2016 年」以降とレポートされている場合、下記のすべての要件を満たすことが強く推奨され、また満たさなければなりません。
    • GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GPS 測定値が判明したらすぐにレポートしなければなりません。
    • 全天条件下で、位置を特定した後に、静止しているか加速度 0.2 m/s 未満で移動している間、位置 20 m 以内、速度 0.2 m/s 以内、時間 95% 以上を計算するのに十分な、GPS の擬似距離と擬似距離レートをレポートしなければなりません。

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

7.3.4. ジャイロスコープ

デバイス実装には、ジャイロスコープ(角度変化センサー)が含まれるようにするべきです。デバイスは、3 軸加速度計も含まれていない限り、ジャイロスコープ センサーが含まれるようにするべきではありません。ジャイロスコープが含まれる場合、デバイス実装は:

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

7.3.5. 気圧計

デバイス実装は気圧計(大気圧センサー)を含むべきです。気圧計が含まれる場合、デバイス実装は:

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

7.3.6. 温度計

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

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

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 と同じ品質要件の SENSOR_TYPE_GYROSCOPE_UNCALIBRATED

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • 測定範囲が少なくとも -900~+900 uT でなければなりません。
    • 測定解像度が少なくとも 5 LSB/uT でなければなりません。
    • 最小測定周波数が 5 Hz 以下でなければなりません。
    • 最大測定周波数が 50 Hz 以上でなければなりません。
    • 測定雑音が 0.5 uT 以下でなければなりません。
  • SENSOR_TYPE_GEOMAGNETIC_FIELD と同じ品質要件であることに加え、次の条件を満たす SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED:
    • 少なくとも 600 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
  • SENSOR_TYPE_PRESSURE
    • 測定範囲が少なくとも 300~1,100 hPa でなければなりません。
    • 測定解像度が少なくとも 80 LSB/hPa でなければなりません。
    • 最小測定周波数が 1 Hz 以下でなければなりません。
    • 最大測定周波数が 10 Hz 以上でなければなりません。
    • 測定雑音が 2 Pa/√Hz 以下でなければなりません。
    • 少なくとも 300 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
    • 計量消費電力が 2 mW 以下でなければなりません。
  • 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 専用センサー

自動車固有のセンサーは、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 実装は、車両が完全に停止され駐車されているときのデフォルト値を DRIVE_STATUS_UNRESTRICTED とする、SENSOR_TYPE_DRIVING_STATUS と定義された運転状況をサポートしなければなりません。製品が出荷されている市場に適用されるすべての法律および規制に従って、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 のサポートが含まれ、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 を実装しなければなりません。デバイス実装では、デバイスに応じて、A2DP、AVCP、OBEX など、関連する Bluetooth プロファイルを実装するべきです。

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 を有効にしなければなりません。
  • ユーザーのプライバシーを保護するために、15 分以下の解決可能なプライベート アドレス(RPA)タイムアウトを実装し、タイムアウト時にアドレスをローテーションすることが強く推奨されます。
  • 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 規格は「強く推奨」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。これらの規格は、このバージョンでは任意ですが、今後のバージョンでは必須となります。このバージョンの 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 のデフォルト サーバーと同じ方法で処理しなければなりません。
    • Android ビームが有効になっているときは、SNEP クライアントを実装し、デフォルト 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 を使用する場合、「接続ハンドオーバー バージョン 1.2」および NFC フォーラムの「NFC を使用した Bluetooth Secure Simple Pairing バージョン 1.0」の仕様を実装して Bluetooth への接続ハンドオーバーをサポートしなければなりません。このような実装では、NFC を介してハンドオーバー リクエスト / 選択レコードを交換するために、サービス名「urn:nfc:sn:handover」を持つハンドオーバー LLCP サービスを実装しなければならず、実際の Bluetooth データ転送には Bluetooth オブジェクト プッシュ プロファイルを使用しなければなりません。従来の理由(Android 4.1 デバイスとの互換性を維持する)のために、実装では NFC を介してハンドオーバー リクエスト / 選択レコードを交換するために SNEP GET リクエストを引き続き受け入れるべきです。ただし、実装自体が、接続の引き渡しを実行するための SNEP GET リクエストを送信すべきではありません。
    • 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](https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html)を実装しなければなりません。

さらに、デバイス実装では、次の 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/sec 以上の能力を持つ、少なくとも 1 つのデータ規格のサポートを含まなければなりません。この要件を満たす技術の例としては、EDGE、HSPA、EV-DO、802.11g、イーサネット、Bluetooth PAN が挙げられます。

物理ネットワーク規格(イーサネットなど)がプライマリ データ接続であるデバイス実装は、少なくとも 1 つの一般的なワイヤレス データ規格(802.11(Wi-Fi)など)のサポートを含むべきです。

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

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

7.5.3. 外部カメラ

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

  • プラットフォーム機能フラグ android.hardware.camera.externalandroid.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 テレビデバイスは、アプリの個人データ(「/data」パーティション)に利用できる不揮発性ストレージが少なくとも 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

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

Android スマートウォッチを除き、カーネルとユーザー空間に利用できるメモリが 512 MB 未満のデバイス実装は、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 マスストレージまたは Media Transfer Protocol を使用して共有ストレージ ボリュームのコンテンツにアクセスできるようにしなければなりません。
  • Android SDK ドキュメントに記載されているように、Android Open Accessory(AOA)の API と仕様を実装するべきであり、Android ハンドヘルド デバイスの場合は AOA API を実装しなければなりません。AOA 仕様を実装するデバイス実装には、以下の要件が適用されます。
    • ハードウェア機能 android.hardware.usb.accessory のサポートを宣言しなければなりません。
    • Android SDK ドキュメントに記載されているように、USB オーディオ クラスを実装しなければなりません。
    • USB マスストレージ クラスは、USB マスストレージのインターフェース記述 iInterface 文字列の末尾に文字列「android」を含まなければなりません。
  • USB Battery Charging Specification, Revision 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 デバイスは、標準の USB Power Delivery の方法をサポートする充電器またはデバイスとの間に相互運用性の問題が生じるおそれがあるため、デフォルト レベルを超えて Vbus 電圧を変更する、またはシンク / ソースの役割を変更する独自の充電方法をサポートしないことが強く推奨されます。これは「強く推奨」となっていますが、今後の Android バージョンでは、標準的な Type-C 充電器との完全な相互運用性をサポートすることが、すべての Type-C デバイスで必須となる可能性があります。

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 のハンドヘルド、スマートウォッチ、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 出力機能をレポートしてはならず、少なくともオーディオ出力関連の API を NOP として実装しなければなりません。

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

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

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

  • ステレオ ヘッドフォンと、マイク付きステレオ ヘッドセットへのオーディオ再生をサポートしなければならず、マイク付きステレオ ヘッドセットからの録音をサポートすべきです。
  • CTIA ピン配列の TRRS オーディオ プラグをサポートしなければならず、OMTP ピン配列のオーディオ プラグをサポートすべきです。
  • デバイス実装がマイクをサポートしている場合、接続したオーディオ アクセサリのマイクの検出をサポートし、extra 値 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 機能を宣言しなければなりません。この機能を宣言するデバイスは、android.app.Activity#setVrModeEnabled を介して VR アプリで有効にできる 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 拡張機能のリストで公開しなければなりません。
  • デバイス実装は、Secure Texture Video Playback に使用できるように EGL_EXT_protected_content と GL_EXT_protected_textures を実装し、これらの拡張機能を利用可能な EGL 拡張機能と GL 拡張機能のリストで公開しなければなりません。
  • デバイス実装は、30 fps-40 Mbps で 3,840 x 2,160 以上の H.264 デコードをサポートしなければなりません(30 fps-10 Mbps で 1,920 x 1,080 の 4 インスタンス、または 60 fps-20 Mbps で 1,920 x 1,080 の 2 インスタンスに相当)。
  • デバイス実装は、HEVC と VP9 をサポートしなければならず、30fps-10Mbps で 1,920 x 1,080 以上のデコードができなければならず、30 fps-20 Mbps で 3,840 x 2,160 のデコードができるべきです(30 fps-5 Mbps で 1,920 x 1,080 の 4 インスタンスに相当)。
  • デバイス実装は、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 アクセスのパフォーマンス

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

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

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 とプロセスの分離

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

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

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

9.4. 代替実行環境

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

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

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

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

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

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

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

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

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

この機能は、すべてのデバイスタイプで省略可能です。

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

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

9.6. プレミアム SMS の警告

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

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

Android サンドボックスには、Linux カーネルの Security-Enhanced Linux(SELinux)の強制アクセス制御(MAC)システム、seccomp サンドボックス化、その他のセキュリティ機能を使用する機能があります。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 サービスのプリロード)、デバイス実装はそのメカニズムを有効にする前にユーザーの同意を得なければなりません。ただし、その VPN を DevicePolicyManager.setAlwaysOnVpnPackage() を介して Device Policy Controller が有効にしている場合は除きます。その場合、ユーザーが別途同意する必要はありませんが、ユーザーへの通知は行わなければなりません。

デバイス実装は、ユーザーが追加する認証局(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 モードの AES による鍵長 256 ビットでのファイル コンテンツの暗号化をサポートしなければなりません。
  • CBC-CTS モードで鍵長 256 ビットの AES を使用したファイル名の暗号化をサポートしなければなりません。
  • ファイル コンテンツとファイル名の暗号化の代替暗号、鍵長、モードをサポートしても構いませんが、必須としてサポートされている暗号、鍵長、モードは使用しなければなりません。
  • プリロードされた必須アプリ(アラーム、電話、メッセンジャー)をダイレクト ブートに対応させるべきです。

CE と DE のストレージ領域を保護する鍵は:

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

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

9.9.3. フルディスク暗号化

フルディスク暗号化(FDE)をサポートするデバイス実装は、128 ビット以上の鍵の AES と、ストレージ用に設計されたモード(AES-XTS、AES-CBC-ESSIV など)を使用しなければなりません。暗号鍵を暗号化せずにストレージに書き込んではなりません。アクティブに使用されている場合を除き、暗号鍵は、低速ストレッチング アルゴリズム(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 ファミリーのハッシュ関数の実装を持たなければなりません。
    • セキュアなハードウェア内でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。アップストリームの Android オープンソース プロジェクトは、使用することでこの要件を満たすことができるゲートキーパー Hardware Abstraction Layer(HAL)を提供しています。

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

9.11.1. セキュアロック画面

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

  • 既知の秘密情報に基づく認証方法は、次の要件をすべて満たす場合を除き、セキュアロック画面として扱ってはなりません。
    • 入力の最短許容長のエントロピーが 10 ビットより大きくなければなりません。
    • 可能性のあるすべての入力の最大エントロピーが 18 ビットより大きくなければなりません。
    • AOSP で実装され提供されている既存の認証方法(PIN、パターン、パスワード)を置き換えてはなりません。
    • DevicePolicyManager.setPasswordQuality() メソッドを介して、Device Policy Controller(DPC)アプリが PASSWORD_QUALITY_SOMETHING より制限的な品質定数でパスワード品質ポリシーを設定した場合、新しい方法を無効にしなければなりません。
  • 物理的なトークンまたは位置情報に基づく認証方法は、次の要件をすべて満たす場合を除き、セキュアロック画面として扱ってはなりません。
    • 既知のシークレットに基づいて、セキュアロック画面として扱われるための要件を満たす、第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければなりません。
    • 第 1 の認証を無効にし、Device Policy Controller(DPC)アプリが DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) メソッドまたは DevicePolicyManager.setPasswordQuality() メソッドで、PASSWORD_QUALITY_UNSPECIFIED より制限的な品質定数を指定してポリシーを設定した場合にのみ、許可しなければなりません。
  • 生体情報に基づく認証方法は、次の要件をすべて満たす場合を除き、セキュアロック画面として扱ってはなりません。
    • 既知のシークレットに基づいて、セキュアロック画面として扱われるための要件を満たす、第 1 の認証方法のいずれかを使用するためのフォールバック メカニズムがなければなりません。
    • 第 1 の認証を無効にし、Device Policy Controller(DPC)アプリが DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) メソッドを呼び出して keguard 機能ポリシーを設定した場合のみ、第 1 の認証で画面をロック解除できるようにしなければなりません。
    • セクション 7.3.10 に記載されているとおり、指紋認証センサーに要求されるレベルと同程度以上の他人受け入れ率が設定されなければなりません。それ以外の場合は無効にしなければならず、Device Policy Controller(DPC)アプリが PASSWORD_QUALITY_BIOMETRIC_WEAK よりも制限的な品質定数を使用した DevicePolicyManager.setPasswordQuality() メソッドを介してパスワード品質ポリシーを設定した場合にのみ、第 1 の認証で画面をロック解除できるようにしなければなりません。
  • セキュアロック画面として扱うことができない認証方法には、以下の要件が適用されます。
  • 認証方法が物理トークンまたはロケーションに基づいている場合、あるいは生体認証に基づいていて他人受け入れ率が指紋認証センサー要件の最大値(セクション 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. 自動車の車両システムの分離

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.0 用に CTS の複数のリビジョンがリリースされる可能性があります。デバイス実装は、デバイス ソフトウェアが完成した時点で利用可能な最新バージョンの CTS に合格しなければなりません。

10.2. CTS 検証ツール

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

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

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

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

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

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

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

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

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

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

リリース後に、ただし妥当な製品寿命の期間内にデバイス実装でエラーが見つかり、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 フォーラムに参加すると、解説を求めたり、このドキュメントがカバーしていないと思われる問題を提起したりできます。