1. はじめに
このドキュメントでは、デバイスが Android 14 との互換性を維持するために満たさなければならない要件を列挙しています。
「しなければならない」、「してはならない」、「要求される」、「するものとする」、「しないものとする」、「すべきである」、「すべきではない」、「推奨される」、「しても構わない」、「任意」の使用は、RFC2119 で規定されている IETF 標準に従います。
このドキュメントで使用する「デバイス実装者」および「実装者」という用語は、Android 14 を実行するハードウェア / ソフトウェア ソリューションを開発する人または組織を指します。「デバイス実装」または「実装」とは、そのように開発されたハードウェア / ソフトウェア ソリューションを指します。
Android 14 と互換性があると見なされるには、デバイス実装で、この互換性定義に示された要件(参照により盛り込まれたドキュメントを含む)を満たさなければなりません。
この定義、またはセクション 10 に記載されているソフトウェア テストが、言及されていない、曖昧である、または不完全である場合、既存の実装との互換性を確保することはデバイス実装者の責任です。
このため、Android オープンソース プロジェクトは Android のリファレンス実装であり、優先実装です。デバイス実装者は可能な限り、Android オープンソース プロジェクトから入手できる「アップストリーム」のソースコードに基づいて実装することが強く推奨されます。一部のコンポーネントは仮に別の実装に置き換えることもできますが、ソフトウェア テストの合格が非常に困難になるため、そのような慣例には従わないことが強く推奨されます。互換性テストスイートなどを含む標準的な Android 実装との完全な動作互換性を確保することは、実装者の責任です。なお、このドキュメントでは特定のコンポーネントの置き換えと変更が明示的に禁止されています。
このドキュメントからリンクされているリソースの多くは、Android SDK から直接的または間接的に派生したものであり、その SDK のドキュメントに記載されている情報と機能的にまったく同じです。この互換性定義または互換性テストスイートと SDK ドキュメントの間に相違がある場合、SDK ドキュメントが正式なものであるとみなされます。このドキュメント全体を通し、リンク先のリソースに記載されている技術的な詳細情報はすべて、この互換性定義の一部とみなされます。
1.1 ドキュメント構造
1.1.1. デバイスタイプ別の要件
セクション 2 には、特定のデバイスタイプに適用される要件がすべて記載されています。セクション 2 の各サブセクションは、特定のデバイスタイプのみを対象としています。
あらゆる Android デバイス実装に普遍的に適用されるその他すべての要件については、セクション 2 の後のセクションに記載されています。このドキュメントでは、こうした要件を「コア要件」と呼びます。
1.1.2. 要件 ID
要件 ID は、「しなければならない」要件に割り当てられます。
- ID は、「しなければならない」要件にのみ割り当てられます。
- 「強く推奨される」要件は [SR] とマークされますが、ID は割り当てられません。
- ID は、デバイスタイプ ID - 条件 ID - 要件 ID で構成されます(例: C-0-1)。
各 ID の定義は次のとおりです。
- デバイスタイプ ID(詳細については 2. デバイスタイプをご覧ください)
- C: コア(あらゆる Android デバイス実装に適用される要件)
- H: Android ハンドヘルド デバイス
- T: Android テレビデバイス
- A: Android Automotive の実装
- W: Android スマートウォッチ実装
- Tab: Android タブレット実装
- 条件 ID
- 要件が無条件の場合、この ID は 0 と設定されます。
- 要件が条件付きの場合、最初の条件に対して 1 が割り当てられ、同一セクション、同一デバイスタイプで数字が 1 ずつ増えます。
- 要件 ID
- この ID は 1 から始まり、同一セクション、同一条件で 1 ずつ増えます。
1.1.3. セクション 2 の要件 ID
セクション 2 の要件 ID は 2 つの部分で構成されています。最初の部分は、前述のセクション ID に対応しています。2 つ目の部分は、フォーム ファクタとフォーム ファクタ固有の要件を示します。
セクション ID の後に、要件 ID が続きます。
- セクション 2 の ID は、セクション ID / デバイスタイプ ID - 条件 ID - 要件 ID で構成されます(例: 7.4.3/A-0-1)。
2. デバイスタイプ
Android オープンソース プロジェクトはさまざまなデバイスタイプやフォーム ファクタに使用できるソフトウェア スタックを提供しています。デバイスのセキュリティをサポートするために、ソフトウェア スタック(代替 OS または代替カーネル実装を含む)は、セクション 9 とこの CDD の他の部分に記載されているとおり、安全な環境で実行することが想定されています。アプリの配信エコシステムが比較的確立されているデバイスタイプもいくつかあります。
このセクションでは、こうしたデバイスタイプと、各デバイスタイプに適用される追加の要件と推奨事項について説明します。
記載されているデバイスタイプのいずれにも当てはまらない Android デバイス実装はすべて、この互換性定義の他のセクションに記載されている要件をすべて満たさなければなりません。
2.1 デバイス構成
デバイスタイプごとのハードウェア構成の主な違いについては、このセクションで後述するデバイス固有の要件をご覧ください。
2.2. ハンドヘルドの要件
Android ハンドヘルド デバイスとは、MP3 プレーヤー、スマートフォン、タブレットなど、通常は手に持って使用する Android デバイス実装を指します。
次の基準をすべて満たす場合、Android デバイス実装はハンドヘルドに分類されます。
- バッテリーなど、持ち運びを可能にする電源がある。
- 物理的な対角画面サイズが 4 インチ
3.3 インチ(API レベル 29 以前で出荷されたデバイス実装の場合は 2.5 インチ)から 8 インチの範囲内。 - タッチスクリーン入力インターフェースがある。
このセクションでこれ以降記載する追加要件は、Android ハンドヘルド デバイス実装に固有のものです。
2.2.1. ハードウェア
ハンドヘルド デバイス実装は:
- [7.1.1.1/H-0-1]
このドキュメントに記載されている要件をすべて満たす少なくとも短辺 2.2 インチ、長辺 3.4 インチの Android 互換ディスプレイを少なくとも 1 つ備えなければなりません。 [7.1.1.3/H-SR-1] 表示サイズ(画面密度)を変更するアフォーダンスをユーザーに提供することが強く推奨されます。
[7.1.1.1/H-0-2] グラフィック バッファが内蔵ディスプレイの最高解像度と同程度以上である GPU 合成をサポートしなければなりません。
新しい要件の開始
[7.1.1.1/H-0-3]* サードパーティ アプリで利用できるようにする各
UI_MODE_NORMAL
ディスプレイを、少なくとも短辺 2.2 インチ、長辺 3.4 インチの遮蔽されていない物理的な表示領域内にマッピングしなければなりません。[7.1.1.3/H-0-1]*
DENSITY_DEVICE_STABLE
の値は、92% または実際の対応ディスプレイの物理密度よりも大きく設定しなければなりません。
新しい要件の終了
ソフトウェアの画面回転をサポートする場合、ハンドヘルド デバイス実装は:
- [7.1.1.1/H-1-1]* サードパーティ アプリで利用できるようにする論理画面を、少なくとも短辺 2 インチ、長辺 2.7 インチにしなければなりません。Android API レベル 29 以前で出荷されたデバイスについては、この要件を免除しても構いません。
ソフトウェアの画面回転をサポートしない場合、ハンドヘルド デバイス実装は:
- [7.1.1.1/H-2-1]* サードパーティ アプリで利用できるようにする論理画面を、少なくとも短辺 2.7 インチにしなければなりません。Android API レベル 29 以前で出荷されたデバイスについては、この要件を免除しても構いません。
新しい要件の開始
Vulkan のサポートが含まれる場合、ハンドヘルド デバイス実装は:
- [7.1.4.2/H-1-1] Android ベースライン 2021 プロファイルで規定されている要件を満たさなければなりません。
新しい要件の終了
Configuration.isScreenHdr()
を通じてハイ ダイナミック レンジ表示のサポートを主張する場合、ハンドヘルド デバイス実装は:
- [7.1.4.5/H-1-1] 拡張機能
EGL_EXT_gl_colorspace_bt2020_pq
、EGL_EXT_surface_SMPTE2086_metadata
、EGL_EXT_surface_CTA861_3_metadata
、VK_EXT_swapchain_colorspace
、VK_EXT_hdr_metadata
のサポートをアドバタイズしなければなりません。
ハンドヘルド デバイス実装は:
- [7.1.4.6/H-0-1] システム プロパティ
graphics.gpu.profiler.support
を介して、デバイスが GPU プロファイリングをサポートしているかどうかをレポートしなければなりません。
システム プロパティ graphics.gpu.profiler.support
を介してサポートを宣言する場合、ハンドヘルド デバイス実装は:
- [7.1.4.6/H-1-1] Perfetto ドキュメントで規定されている GPU カウンターと GPU レンダリング ステージのスキーマに準拠する protobuf トレースを出力としてレポートしなければなりません。
- [7.1.4.6/H-1-2] GPU カウンタ トレース パケット proto に従い、デバイスの GPU カウンタに沿う値をレポートしなければなりません。
- [7.1.4.6/H-1-3] レンダリング ステージ トレース パケット proto に従い、デバイスの GPU RenderStage に沿う値をレポートしなければなりません。
- [7.1.4.6/H-1-4] power/gpu_frequency の形式で指定した GPU 周波数トレースポイントをレポートしなければなりません。
ハンドヘルド デバイス実装は:
- [7.1.5/H-0-1] アップストリームの Android オープンソース コードで実装されたレガシーアプリ互換モードのサポートを含まなければなりません。つまり、デバイス実装は、互換モードが有効になるトリガーまたはしきい値を変更してはなりません。また、互換モード自体の動作を変更してはなりません。
- [7.2.1/H-0-1] サードパーティのインプット メソッド エディタ(IME)アプリのサポートを含まなければなりません。
- [7.2.3/H-0-2] 戻る機能(
KEYCODE_BACK
)の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。これらのイベントはシステムで使用してはならず、Android デバイスの外部(Android デバイスに接続された外部ハードウェア キーボードなど)からトリガーできます。 - [7.2.3/H-0-3] ホーム画面を提供するすべての Android 互換ディスプレイでホーム機能を提供しなければなりません。
- [7.2.3/H-0-4] すべての Android 互換ディスプレイで戻る機能を提供し、少なくとも 1 つの Android 互換ディスプレイで履歴機能を提供しなければなりません。
- [7.2.4/H-0-1] タッチスクリーン入力をサポートしなければなりません。
- [7.2.4/H-SR-1] ユーザー選択のアシストアプリ(つまり VoiceInteractionService を実装するアプリ)を起動すること、あるいは、フォアグラウンド アクティビティが長押しイベントを処理しない場合は
KEYCODE_MEDIA_PLAY_PAUSE
またはKEYCODE_HEADSETHOOK
の長押しでACTION_ASSIST
を処理するアクティビティを起動することが強く推奨されます。 - [7.3.1/H-SR-1] 3 軸加速度計を含むことが強く推奨されます。
3 軸加速度計が含まれる場合、ハンドヘルド デバイス実装は:
- [7.3.1/H-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
GPS / GNSS レシーバーが含まれ、android.hardware.location.gps
機能フラグを通じてアプリに機能をレポートする場合、ハンドヘルド デバイス実装は:
- [7.3.3/H-2-1] GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GNSS 測定値が判明したらすぐにレポートしなければなりません。
- [7.3.3/H-2-2] 全天条件下で、位置を特定した後に、静止しているか加速度 0.2 m/s 未満で移動している間、位置 20 m 以内、速度 0.2 m/s 以内、時間 95% 以上を計算するのに十分な、GNSS の擬似距離と擬似距離レートをレポートしなければなりません。
3 軸ジャイロスコープが含まれる場合、ハンドヘルド デバイス実装は:
- [7.3.4/H-3-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
- [7.3.4/H-3-2] 1,000 度/秒までの方向変化を測定できなければなりません。
音声通話を行い、getPhoneType
に PHONE_TYPE_NONE
以外の値を示せるハンドヘルド デバイス実装は:
- [7.3.8/H] 近接センサーを含むべきです。
ハンドヘルド デバイス実装は:
デバイスが PackageManager.FEATURE_WIFI_AWARE
を宣言して Wi-Fi Neighbor Awareness Networking(NAN)プロトコルをサポートしている場合と、PackageManager.FEATURE_WIFI_RTT
を宣言して Wi-Fi Location(Wi-Fi ラウンドトリップ時間 - RTT)をサポートしている場合、それらのデバイスは:
[7.4.2.5/H-1-1] WifiRttManager#startRanging Android API を介して確認した 10 cm、1 m、3 m、5 m の距離における範囲を、累積分布関数で計算し、帯域幅 160 MHz では 68 パーセンタイルで正確度 +/-1 メートル以内、80 MHz 帯域幅では 68 パーセンタイルで正確度 +/-2 メートル以内、40 MHz 帯域幅では 68 パーセンタイルで正確度 +/-4 メートル以内、20 MHz 帯域幅では 68 パーセンタイルで正確度 +/-8 メートル以内でレポートしなければなりません。
[7.4.2.5/H-SR-1] WifiRttManager#startRanging Android API を介して確認した 10 cm の距離における範囲を、累積分布関数で計算し、帯域幅 160 MHz では 90 パーセンタイルで正確度 +/-1 メートル以内、80 MHz 帯域幅では 90 パーセンタイルで正確度 +/-2 メートル以内、40 MHz 帯域幅では 90 パーセンタイルで正確度 +/-4 メートル以内、20 MHz 帯域幅では 90 パーセンタイルで正確度 +/-8 メートル以内でレポートすることが強く推奨されます。
プレゼンス キャリブレーションで指定されている測定のセットアップ手順に沿うことが強く推奨されます。
新しい要件の開始
FEATURE_BLUETOOTH_LE
を宣言する場合、ハンドヘルド デバイス実装は:
- [7.4.3/H-1-3]
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -50 dBm +/-15 dB になるように、Rx オフセットを測定し補正しなければなりません。 - [7.4.3/H-1-4] 1 m の距離に位置し、
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -50 dBm +/-15 dB になるように、Tx オフセットを測定し補正しなければなりません。
新しい要件の終了
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
を使用して機能をリストする論理カメラデバイスが含まれる場合、ハンドヘルド デバイス実装は:
- [7.5.4/H-1-1] デフォルトで通常の視野(FOV)を持たなければならず、50 度から 95 度の間でなければなりません。
ハンドヘルド デバイス実装は:
- [7.6.1/H-0-1] アプリの個人データ(「/data」パーティション)に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。
- [7.6.1/H-0-2] カーネルとユーザー空間に利用できるメモリが 1 GB 未満の場合、
ActivityManager.isLowRamDevice()
について「true」を返さなければなりません。
32 ビット ABI のみのサポートを宣言する場合、ハンドヘルド デバイス実装は:
[7.6.1/H-1-1] デフォルト ディスプレイで qHD までのフレームバッファ解像度を使用する場合(例: FWVGA)、カーネルとユーザー空間に利用できるメモリが少なくとも 416 MB でなければなりません。
[7.6.1/H-2-1] デフォルト ディスプレイで HD+ までのフレームバッファ解像度を使用する場合(例: HD、WSVGA)、カーネルとユーザー空間に利用できるメモリが少なくとも 592 MB でなければなりません。
[7.6.1/H-3-1] デフォルト ディスプレイで FHD までのフレームバッファ解像度を使用する場合(例: WSXGA+)、カーネルとユーザー空間に利用できるメモリが少なくとも 896 MB でなければなりません。
[7.6.1/H-4-1] デフォルト ディスプレイで QHD までのフレームバッファ解像度を使用する場合(例: QWXGA)、カーネルとユーザー空間に利用できるメモリが少なくとも 1,344 MB でなければなりません。
(32 ビット ABI の有無にかかわらず)64 ビット ABI のサポートを宣言する場合、ハンドヘルド デバイス実装は:
[7.6.1/H-5-1] デフォルト ディスプレイで qHD までのフレームバッファ解像度を使用する場合(例: FWVGA)、カーネルとユーザー空間に利用できるメモリが少なくとも 816 MB でなければなりません。
[7.6.1/H-6-1] デフォルト ディスプレイで HD+ までのフレームバッファ解像度を使用する場合(例: HD、WSVGA)、カーネルとユーザー空間に利用できるメモリが少なくとも 944 MB でなければなりません。
[7.6.1/H-7-1] デフォルト ディスプレイで FHD までのフレームバッファ解像度を使用する場合(例: WSXGA+)、カーネルとユーザー空間に利用できるメモリが少なくとも 1,280 MB でなければなりません。
[7.6.1/H-8-1] デフォルト ディスプレイで QHD までのフレームバッファ解像度を使用する場合(例: QWXGA)、カーネルとユーザー空間に利用できるメモリが少なくとも 1,824 MB でなければなりません。
なお、上記の「カーネルとユーザー空間に利用できるメモリ」とは、デバイス実装でカーネルの制御下にない、無線や動画などのハードウェア コンポーネント専用のメモリに加えて提供されるメモリ空間を指します。
カーネルとユーザー空間に利用できるメモリが 1 GB 以下の場合、ハンドヘルド デバイス実装は:
- [7.6.1/H-9-1] 機能フラグ
android.hardware.ram.low
を宣言しなければなりません。 - [7.6.1/H-9-2] アプリの個人データ(「/data」パーティション)用の不揮発性ストレージが少なくとも 1.1 GB でなければなりません。
カーネルとユーザー空間に利用できるメモリが 1 GB を超える場合、ハンドヘルド デバイス実装は:
- [7.6.1/H-10-1] アプリの個人データ(「/data」パーティション)に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。
- 機能フラグ
android.hardware.ram.normal
を宣言すべきです。
カーネルとユーザー空間に利用できるメモリが 2 GB 以上 4 GB 未満の場合、ハンドヘルド デバイス実装は:
- [7.6.1/H-SR-1] 32 ビットユーザー空間のみをサポートすることが強く推奨されます(アプリとシステムコードの両方)。
カーネルとユーザー空間に利用できるメモリが 2 GB 未満の場合、ハンドヘルド デバイス実装は:
- [7.6.1/H-1-1] 1 つの ABI のみ(64 ビットのみ、または 32 ビットのみ)をサポートしなければなりません。
ハンドヘルド デバイス実装は:
ペリフェラル モードをサポートする USB ポートが含まれる場合、ハンドヘルド デバイス実装は:
- [7.7.1/H-1-1] Android Open Accessory(AOA)API を実装しなければなりません。
ホストモードをサポートする USB ポートが含まれる場合、ハンドヘルド デバイス実装は:
- [7.7.2/H-1-1] Android SDK ドキュメントに記載されているとおり USB オーディオ クラスを実装しなければなりません。
ハンドヘルド デバイス実装は:
- [7.8.1/H-0-1] マイクを含まなければなりません。
- [7.8.2/H-0-1] オーディオ出力がなければならず、
android.hardware.audio.output
を宣言しなければなりません。
VR モードをサポートするためのパフォーマンス要件をすべて満たすことができ、そのサポートが含まれる場合、ハンドヘルド デバイス実装は:
- [7.9.1/H-1-1]
android.hardware.vr.high_performance
機能フラグを宣言しなければなりません。 - [7.9.1/H-1-2]
android.app.Activity#setVrModeEnabled
を介して VR アプリで有効にできるandroid.service.vr.VrListenerService
を実装するアプリを含まなければなりません。
ホストモードの USB-C ポートを 1 つ以上含んで実装(USB オーディオ クラス)する場合、セクション 7.7.2 の要件に加え、ハンドヘルド デバイス実装は:
- [7.8.2.2/H-1-1] 次に示す HID コードのソフトウェア マッピングを提供しなければなりません。
機能 | マッピング | コンテキスト | 動作 |
---|---|---|---|
A | HID 使用ページ: 0x0C HID 使用: 0x0CD カーネルキー: KEY_PLAYPAUSE Android キー: KEYCODE_MEDIA_PLAY_PAUSE |
メディア再生 | 入力: 短押し 出力: 再生または一時停止 |
入力: 長押し 出力: 音声コマンドを起動 送信: デバイスがロックされているか画面がオフの場合は android.speech.action.VOICE_SEARCH_HANDS_FREE を、それ以外の場合は android.speech.RecognizerIntent.ACTION_WEB_SEARCH を送信 |
|||
着信 | 入力: 短押し 出力: 着信に応答 |
||
入力: 長押し 出力: 通話を拒否 |
|||
通話中 | 入力: 短押し 出力: 通話を終了 |
||
入力: 長押し 出力: マイクをミュートまたはミュート解除 |
|||
B | HID 使用ページ: 0x0C HID 使用: 0x0E9 カーネルキー: KEY_VOLUMEUP Android キー: VOLUME_UP |
メディア再生、通話中 | 入力: 短押しまたは長押し 出力: システムまたはヘッドセットの音量を上げる |
C | HID 使用ページ: 0x0C HID 使用: 0x0EA カーネルキー: KEY_VOLUMEDOWN Android キー: VOLUME_DOWN |
メディア再生、通話中 | 入力: 短押しまたは長押し 出力: システムまたはヘッドセットの音量を下げる |
D | HID 使用ページ: 0x0C HID 使用: 0x0CF カーネルキー: KEY_VOICECOMMAND Android キー: KEYCODE_VOICE_ASSIST |
すべて。任意のインスタンスでトリガー可能。 | 入力: 短押しまたは長押し 出力: 音声コマンドを起動 |
- [7.8.2.2/H-1-2] プラグ挿入時に ACTION_HEADSET_PLUG をトリガーしなければなりません。ただし、接続されている端子のタイプを識別するために USB オーディオ インターフェースとエンドポイントが適切に列挙された後に限ります。
USB オーディオ端子タイプ 0x0302 が検出された場合:
- [7.8.2.2/H-2-1] 「microphone」エクストラを 0 に設定してインテント ACTION_HEADSET_PLUG をブロードキャストしなければなりません。
USB オーディオ端子タイプ 0x0402 が検出された場合:
- [7.8.2.2/H-3-1] 「microphone」エクストラを 1 に設定してインテント ACTION_HEADSET_PLUG をブロードキャストしなければなりません。
USB 周辺機器が接続されている間に API AudioManager.getDevices() が呼び出された場合:
[7.8.2.2/H-4-1] USB オーディオ端子タイプのフィールドが 0x0302 であれば、タイプ AudioDeviceInfo.TYPE_USB_HEADSET、ロール isSink() のデバイスをリストしなければなりません。
[7.8.2.2/H-4-2] USB オーディオ端子タイプのフィールドが 0x0402 であれば、タイプ AudioDeviceInfo.TYPE_USB_HEADSET、ロール isSink() のデバイスをリストしなければなりません。
[7.8.2.2/H-4-3] USB オーディオ端子タイプのフィールドが 0x0402 であれば、タイプ AudioDeviceInfo.TYPE_USB_HEADSET、ロール isSource() のデバイスをリストしなければなりません。
[7.8.2.2/H-4-4] USB オーディオ端子タイプのフィールドが 0x603 であれば、タイプ udioDeviceInfo.TYPE_USB_DEVICE、ロール isSink() のデバイスをリストしなければなりません。
[7.8.2.2/H-4-5] USB オーディオ端子タイプのフィールドが 0x604 であれば、タイプ AudioDeviceInfo.TYPE_USB_DEVICE、ロール isSource() のデバイスをリストしなければなりません。
[7.8.2.2/H-4-6] USB オーディオ端子タイプのフィールドが 0x400 であれば、タイプ AudioDeviceInfo.TYPE_USB_DEVICE、ロール isSink() のデバイスをリストしなければなりません。
[7.8.2.2/H-4-7] USB オーディオ端子タイプのフィールドが 0x400 であれば、タイプ AudioDeviceInfo.TYPE_USB_DEVICE、ロール isSource() のデバイスをリストしなければなりません。
[7.8.2.2/H-SR-1] USB-C オーディオ周辺機器の接続時、USB 記述子の列挙、端子タイプの特定、インテント ACTION_HEADSET_PLUG のブロードキャストを、1,000 ミリ秒未満で実施することが強く推奨されます。
android.hardware.audio.output
と android.hardware.microphone
を宣言する場合、ハンドヘルド デバイス実装は:
[5.6/H-1-1] 「スピーカーからマイク」、3.5 mm ループバック アダプター(サポートされている場合)、USB ループバック(サポートされている場合)のデータパスにおいて、5 回の測定での平均連続ラウンドトリップ レイテンシが 300 ミリ秒以下、平均絶対偏差が 30 ミリ秒未満でなければなりません。
[5.6/H-1-2] スピーカーからマイクへのデータパスで、少なくとも 5 回の測定での平均タップツートーン レイテンシが 300 ミリ秒以下でなければなりません。
触覚アクチュエータが 1 つ以上含まれる場合、ハンドヘルド デバイス実装は:
- [7.10/H]* 偏心回転質量(ERM)触覚アクチュエータ(バイブレータ)を使用すべきではありません。
- [7.10/H]* android.view.HapticFeedbackConstants にあるクリア ハプティクスのためのパブリック定数(すなわち CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、KEYBOARD_TAP、LONG_PRESS、TEXT_HANDLE_MOVE、VIRTUAL_KEY、VIRTUAL_KEY_RELEASE、CONFIRM、REJECT、GESTURE_START、GESTURE_END)をすべて実装すべきです。
- [7.10/H]* android.os.VibrationEffect にあるクリア ハプティクスのためのパブリック定数(すなわち EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK、EFFECT_DOUBLE_CLICK)をすべて実装し、android.os.VibrationEffect.Composition にあるリッチ ハプティクスのための実現可能なパブリック
PRIMITIVE_*
定数(すなわち CLICK、TICK、LOW_TICK、QUICK_FALL、QUICK_RISE、SLOW_RISE、SPIN、THUD)をすべて実装すべきです。これらのプリミティブの一部(LOW_TICK や SPIN など)は、バイブレーターが比較的低い周波数をサポートできる場合にのみ実現可能です。 - [7.10/H]* パブリック定数のマッピングのガイダンスに従って、android.view.HapticFeedbackConstants にあるパブリック定数を、対応する振幅関係とともに推奨される android.os.VibrationEffect 定数にマッピングすべきです。
- [7.10/H]* createOneShot() API と createWaveform() API の品質評価に従うべきです。
- [7.10/H]* パブリック android.os.Vibrator.hasAmplitudeControl() API の結果にバイブレータの機能が正しく反映されていることを検証すべきです。
- [7.10/H]* デバイスを手で通常持つか触れる場所の近くにアクチュエータを配置すべきです。
リニア共振アクチュエータ(LRA)は、質点を目的の運動方向に並進させる主共振周波数を持つ、単一のばね質量系です。
少なくとも 1 つの汎用 7.10 リニア共振アクチュエータが含まれる場合、ハンドヘルド デバイス実装は:
- [7.10/H] 触覚アクチュエータをデバイスの自然な向きの
縦向き画面の X 軸(左右)で動かすべきです。
汎用触覚アクチュエータが含まれていて、それが X 軸のリニア共振アクチュエータ(LRA)である場合、ハンドヘルド デバイス実装は:
- [7.10/H] X 軸の LRA の共振周波数を 200 Hz 未満にすべきです。
触覚定数マッピングに従う場合、ハンドヘルド デバイス実装は:
- [7.10/H]* android.os.Vibrator.areAllEffectsSupported() API と android.os.Vibrator.arePrimitivesSupported() API を実行して実装ステータス検証すべきです。
[7.10/H]* 定数の実装ガイダンスに記載されているとおり、サポートされていないプリミティブのフォールバック構成を必要に応じて検証して更新すべきです。
2.2.2. マルチメディア
ハンドヘルド デバイス実装は、次の形式のオーディオ エンコードとデコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] MPEG-4 AAC プロファイル(AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC プロファイル(AAC+)
- [5.1/H-0-5] AAC ELD(Enhanced Low Delay AAC)
ハンドヘルド デバイス実装は、次の形式の動画エンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
ハンドヘルド デバイス実装は、次の形式の動画デコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
2.2.3. ソフトウェア
ハンドヘルド デバイス実装は:
- [3.2.3.1/H-0-1] SDK ドキュメントに記載されているとおり、インテント
ACTION_GET_CONTENT
、ACTION_OPEN_DOCUMENT
、ACTION_OPEN_DOCUMENT_TREE
、ACTION_CREATE_DOCUMENT
を処理するアプリを持ち、DocumentsProvider
API を使用してドキュメント プロバイダ データにアクセスするユーザー アフォーダンスを提供しなければなりません。 - [3.2.3.1/H-0-2]* こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
- [3.2.3.1/H-SR-1] インテント ACTION_SENDTO、ACTION_SEND、または ACTION_SEND_MULTIPLE を処理してメールを送信できるメールアプリをプリロードすることが強く推奨されます。
- [3.4.1/H-0-1]
android.webkit.Webview
API の完全な実装を提供しなければなりません。 - [3.4.2/H-0-1] 一般ユーザーのウェブ ブラウジング用のスタンドアロン ブラウザアプリを含まなければなりません。
- [3.8.1/H-SR-1] ショートカット、ウィジェット、widgetFeatures のアプリ内固定をサポートするデフォルト ランチャーを実装することが強く推奨されます。
- [3.8.1/H-SR-2] ShortcutManager API を介してサードパーティ アプリで提供される追加のショートカットにすばやくアクセスできるようにするデフォルト ランチャーを実装することが強く推奨されます。
- [3.8.1/H-SR-3] アプリアイコンにバッジを表示するデフォルト ランチャー アプリを含むことが強く推奨されます。
- [3.8.2/H-SR-1] サードパーティ アプリ ウィジェットをサポートすることが強く推奨されます。
- [3.8.3/H-0-1] API クラス
Notification
とNotificationManager
を介してサードパーティ アプリがユーザーに重要なイベントを通知することを許可しなければなりません。 - [3.8.3/H-0-2] リッチ通知をサポートしなければなりません。
- [3.8.3/H-0-3] ヘッドアップ通知をサポートしなければなりません。
- [3.8.3/H-0-4] AOSP で実装されるように、アクション ボタンやコントロール パネルなどのユーザー アフォーダンスを通じてユーザーが通知を直接コントロール(返信、スヌーズ、拒否、ブロックなど)できるようにする通知シェードを含まなければなりません。
- [3.8.3/H-0-5]
RemoteInput.Builder setChoices()
を通じて提供する選択肢を通知シェードに表示しなければなりません。 - [3.8.3/H-SR-1]
RemoteInput.Builder setChoices()
を通じて提供される最初の選択肢を、追加のユーザー操作なしで通知シェードに表示することが強く推奨されます。 - [3.8.3/H-SR-2] ユーザーが通知シェード内の通知をすべて開いた際に、
RemoteInput.Builder setChoices()
を通じて提供されるすべての選択肢を通知シェードに表示することが強く推奨されます。 - [3.8.3.1/H-SR-1]
Notification.Action.Builder.setContextual
がtrue
に設定されているアクションを、Notification.Remoteinput.Builder.setChoices
によって表示される返信に沿って表示することが強く推奨されます。 - [3.8.4/H-SR-1] アシスト アクションを処理するために、デバイスにアシスタントを実装することが強く推奨されます。
MediaStyle 通知をサポートする場合、ハンドヘルド デバイス実装は:
- [3.8.3.1/H-SR-2]
MediaSession
トークンを含むMediaStyle
通知をアプリが送信したときに、使用できる適切なメディアルート間(例: Bluetooth デバイスやMediaRouter2Manager
に提供されるルート)での切り替えをユーザーができるようにする、システム UI からアクセスできるユーザー アフォーダンス(例: 出力の切り替え)を提供することが強く推奨されます。
新しい要件の開始
セクション 7.2.3 で詳述するように、履歴機能のナビゲーション キーが含まれ、インターフェースを変更する場合、デバイス実装は:
- [3.8.3/H-1-1] 画面固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。
新しい要件の終了
アシスト アクションをサポートする場合、ハンドヘルド デバイス実装は:
- [3.8.4/H-SR-2] セクション 7.2.3 に記載されているとおり、アシストアプリを起動するための指定操作として
HOME
キーの長押しを使用することが強く推奨されます。ユーザー選択のアシストアプリ(つまりVoiceInteractionService
を実装するアプリ)またはACTION_ASSIST
インテントを処理するアクティビティを起動しなければなりません。
conversation notifications
をサポートし、アラート通知と会話以外のサイレント通知とは別のセクションにグループ化する場合、ハンドヘルド デバイス実装は:
- [3.8.4/H-1-1]* 進行中のフォアグラウンド サービス通知と importance:high の通知を除き、会話以外の通知より前に会話通知を表示しなければなりません。
ロック画面をサポートする場合、Android ハンドヘルド デバイス実装は:
- [3.8.10/H-1-1] メディア通知テンプレートを含め、ロック画面通知を表示しなければなりません。
セキュアロック画面をサポートする場合、ハンドヘルド デバイス実装は:
ControlsProviderService
API と Control
API のサポートが含まれ、サードパーティ アプリがデバイス コントロールをパブリッシュできるようにする場合、ハンドヘルド デバイス実装は:
- [3.8.16/H-1-1] 機能フラグ
android.software.controls
を宣言し、true
に設定しなければなりません。 - [3.8.16/H-1-2]
ControlsProviderService
API とControl
API を通じてサードパーティ アプリで登録されたコントロールから、ユーザーのお気に入りのデバイス コントロールを追加、編集、選択、操作できるユーザー アフォーダンスを提供しなければなりません。 - [3.8.16/H-1-3] デフォルト ランチャーから 3 操作以内で、このユーザー アフォーダンスへのアクセスを提供しなければなりません。
[3.8.16/H-1-4] このユーザー アフォーダンスに、
ControlsProviderService
API を介してコントロールを提供する各サードパーティ アプリの名前とアイコン、またControl
API で提供される指定のフィールドを、正確にレンダリングしなければなりません。[3.8.16/H-1-5]
ControlsProviderService
とControl
Control.isAuthRequired
API を通じて、サードパーティ アプリによって登録されたコントロールから、アプリによって指定された認証が簡素化されたデバイス コントロールをオプトアウトするユーザー アフォーダンスを提供しなければなりません。
新しい要件の開始
- [3.8.16/H-1-6] デバイス実装は、次のとおり、ユーザー アフォーダンスを正確にレンダリングしなければなりません。
- デバイスが
config_supportsMultiWindow=true
を設定し、アプリがControlsProviderService
宣言でメタデータMETA_DATA_PANEL_ACTIVITY
を宣言し、有効なアクティビティの ComponentName を含む場合(API によって定義)、アプリはこのユーザー アフォーダンスに当該アクティビティを埋め込まなければなりません。 - アプリは、メタデータ
META_DATA_PANEL_ACTIVITY
を宣言しない場合、ControlsProviderService
API で提供される指定のフィールドと、Control API で提供される指定のフィールドをレンダリングしなければなりません。
- デバイスが
- [3.8.16/H-1-7] アプリは、メタデータ
META_DATA_PANEL_ACTIVITY
を宣言する場合、埋め込んだアクティビティの起動時にEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
を使用して、[3.8.16/H-1-5] に定められている設定の値を渡さなければなりません。
新しい要件の終了
逆に、このようなコントロールを実装しない場合、ハンドヘルド デバイス実装は:
- [3.8.16/H-2-1]
ControlsProviderService
API とControl
API のnull
をレポートしなければなりません。 - [3.8.16/H-2-2] 機能フラグ
android.software.controls
を宣言し、false
に設定しなければなりません。
ハンドヘルド デバイスがロックタスク モードで動作していないときに、コンテンツがクリップボードにコピーされた場合、ハンドヘルド デバイス実装は:
- [3.8.17/H-1-1] ユーザーに対して、データがクリップボードにコピーされたことの確認(サムネイルや「コンテンツをコピーしました」など)を表示しなければなりません。さらに、クリップボード データがデバイス間で同期されるかどうかも示します。
ハンドヘルド デバイス実装は:
- [3.10/H-0-1] サードパーティのユーザー補助サービスをサポートしなければなりません。
- [3.10/H-SR-1] talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack(プリインストールのテキスト読み上げエンジンでサポートされている言語)のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。
- [3.11/H-0-1] サードパーティ TTS エンジンのインストールをサポートしなければなりません。
- [3.11/H-SR-1] デバイスで利用可能な言語をサポートする TTS エンジンを含むことが強く推奨されます。
- [3.13/H-SR-1] クイック設定 UI コンポーネントを含むことが強く推奨されます。
FEATURE_BLUETOOTH
または FEATURE_WIFI
のサポートを宣言する場合、Android ハンドヘルド デバイス実装は:
- [3.16/H-1-1] コンパニオン デバイスのペア設定機能をサポートしなければなりません。
ナビゲーション機能が画面上のジェスチャーベースのアクションとして提供される場合:
- [7.2.3/H] ホーム機能のためのジェスチャー認識ゾーンは、画面の底部から高さ 32 dp 以下であるべきです。
ナビゲーション機能を画面の左端または右端の任意の場所からのジェスチャーとして提供する場合、ハンドヘルド デバイス実装は:
- [7.2.3/H-0-1] ナビゲーション機能のジェスチャー エリアは、両側で幅 40 dp 未満でなければなりません。ジェスチャー エリアは、デフォルトで幅 24 dp であるべきです。
セキュアロック画面をサポートし、カーネルとユーザー空間に利用できるメモリが 2 GB 以上の場合、ハンドヘルド デバイス実装は:
- [3.9/H-1-2]
android.software.managed_users
機能フラグを介して管理対象プロファイルのサポートを宣言しなければなりません。
android.hardware.camera.any
を介してカメラのサポートを宣言する場合、Android ハンドヘルド デバイス実装は:
- [7.5.4/H-1-1] SDK に記載されているとおり、
android.media.action.STILL_IMAGE_CAMERA
インテントとandroid.media.action.STILL_IMAGE_CAMERA_SECURE
インテントを使用して、静止画モードでカメラを起動しなければなりません。 - [7.5.4/H-1-2] SDK に記載されているとおり、
android.media.action.VIDEO_CAMERA
インテントを使用して、動画モードでカメラを起動しなければなりません。
アクティビティの埋め込みを使用して、デバイス実装の設定アプリに分割機能を実装する場合、デバイス実装は:
- [3.2.3.1/ H-1-1] 分割機能がオンの場合に、Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY インテントを処理するアクティビティがなければなりません。アクティビティは
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
で保護しなければならず、Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI から解析したインテントのアクティビティを開始しなければなりません。
新しい要件の開始
ユーザーが任意の種類の通話をできるようにする場合、デバイス実装は:
- [7.4.1.2/H-0-1]
android.software.telecom
機能フラグを宣言しなければなりません。 - [7.4.1.2/H-0-2] 通信フレームワークを実装しなければなりません。
新しい要件の終了
2.2.4. パフォーマンスと電力
- [8.1/H-0-1] 一貫したフレーム レイテンシ。一貫性のないフレーム レイテンシ、またはフレームのレンダリングの遅延は、1 秒間に 5 フレームを超えて発生してはならず、1 秒間に 1 フレーム未満であるべきです。
- [8.1/H-0-2] ユーザー インターフェースのレイテンシ。デバイス実装は、Android 互換性テストスイート(CTS)で定義された 10,000 リストエントリのリストを 36 秒未満でスクロールすることで、低レイテンシのユーザー エクスペリエンスを実現しなければなりません。
- [8.1/H-0-3] タスクの切り替え。複数のアプリが起動されている場合、起動後に実行中のアプリを再起動するまでにかかる時間は 1 秒未満でなければなりません。
ハンドヘルド デバイス実装は:
- [8.2/H-0-1] 少なくとも 5 MB/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
- [8.2/H-0-2] 少なくとも 0.5 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
- [8.2/H-0-3] 少なくとも 15 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
- [8.2/H-0-4] 少なくとも 3.5 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。
AOSP に含まれるデバイス電源管理を改善する機能を含むか、AOSP に含まれる機能を拡張する場合、ハンドヘルド デバイス実装は:
- [8.3/H-1-1] バッテリー セーバー機能を有効または無効にするユーザー アフォーダンスを提供しなければなりません。
- [8.3/H-1-2] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供しなければなりません。
ハンドヘルド デバイス実装は:
- [8.4/H-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
- [8.4/H-0-2] すべての消費電力値をミリアンペア時(mAh)単位でレポートしなければなりません。
- [8.4/H-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、
uid_cputime
カーネル モジュール実装を通じて要件を満たしています。 - [8.4/H-0-4] この電力使用量を、
adb shell dumpsys batterystats
シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。 - [8.4/H] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
画面または動画出力が含まれる場合、ハンドヘルド デバイス実装は:
- [8.4/H-1-1]
android.intent.action.POWER_USAGE_SUMMARY
インテントを尊重し、この電力使用量を表示する設定メニューを表示しなければなりません。
ハンドヘルド デバイス実装は:
- [8.5/H-0-1] アクティブなフォアグラウンド サービスまたはユーザーが開始するジョブがあるすべてのアプリを確認するため、
設定メニューでユーザー アフォーダンスを提供しなければなりません。これには、SDK のドキュメントに記載されている各サービスが開始してからの経過時間や、フォアグラウンド サービスまたはユーザーが開始するジョブを停止する機能が含まれます。SDK のドキュメントに記載されているとおり、設定メニューで、フォアグラウンド サービスを実行しているアプリを停止できるユーザー アフォーダンスを提供しなければなりません。また、アクティブなフォアグラウンド サービスを持つすべてのアプリを、アプリの各サービスが開始されてからの継続期間とともに表示しなければなりません。- SDK ドキュメントに記載されているとおり、一部のアプリはこのようなユーザー アフォーダンスでの停止または表示を免除されることがあります。
2.2.5. セキュリティ モデル
ハンドヘルド デバイス実装は:
- [9/H-0-1]
android.hardware.security.model.compatible
機能を宣言しなければなりません。 - [9.1/H-0-1] サードパーティ アプリが
android.permission.PACKAGE_USAGE_STATS
権限を介して使用統計情報にアクセスできるようにし、android.settings.ACTION_USAGE_ACCESS_SETTINGS
インテントに応じて、そのようなアプリへのアクセス権を付与または取り消す、ユーザーがアクセス可能なメカニズムを提供しなければなりません。
新しい要件の開始
android.hardware.telephony
のサポートを宣言する場合、デバイス実装は:
- [9.5/H-1-1]
UserManager.isHeadlessSystemUserMode
をtrue
に設定してはなりません。
新しい要件の終了
ハンドヘルド デバイス実装は:
- [9.11/H-0-2] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
- [9.11/H-0-3] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト(AOSP)は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザベースの隔離オプションをセキュアに実装する方法を選択することもできます。
- [9.11/H-0-4] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer(HAL)と Trusty を提供しており、これを使用してこの要件を満たすことができます。
- [9.11/H-0-5] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。
なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint
機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵構成証明をサポートする必要があるという要件を免除されます。
セキュアロック画面をサポートする場合、ハンドヘルド デバイス実装は:
- [9.11/H-1-1] ユーザーが最短のスリープ タイムアウト(ロック解除状態からロック状態への遷移時間)を 15 秒以下として選択できるようにしなければなりません。
- [9.11/H-1-2] 通知を非表示にし、9.11.1 セキュアロック画面に記載されている第 1 の認証を除くすべての形式の認証を無効にするユーザー アフォーダンスを提供しなければなりません。AOSP は、ロックダウン モードとしての要件を満たしています。
新しい要件の開始
セキュアロック画面があり、TrustAgentService
システム API を実装する信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:
- [9.11.1/H-1-1] 少なくとも 72 時間以内ごとに 1 回、推奨される第 1 の認証方法(PIN、パターン、パスワードなど)のいずれかをユーザーに求めなければなりません。
新しい要件の終了
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言しない場合、ハンドヘルド デバイス実装は:
- [9.5/H-2-1] 制限付きプロファイル(追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能)をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言する場合、ハンドヘルド デバイス実装は:
- [9.5/H-3-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。
新しい要件の開始
UserManager.isHeadlessSystemUserMode
を true
に設定している場合、ハンドヘルド デバイス実装は:
- [9.5/H-4-1] eUICC のサポート、または通話機能のある eSIM のサポートを含めてはなりません。
- [9.5/H-4-2]
android.hardware.telephony
のサポートを宣言してはなりません。
新しい要件の終了
Android はシステム API の VoiceInteractionService を通じて、マイクへのアクセスを示すことなく起動ワードを常時安全に検出するメカニズムをサポートしています。また、マイクまたはカメラへのアクセスを示すことなくクエリを常時検出するメカニズムもサポートしています。
System API HotwordDetectionService
、またはマイクへのアクセスを示さない起動ワード検出の別のメカニズムをサポートする場合、ハンドヘルド デバイス実装は:
- [9.8/H-1-1] 起動ワード検出サービスがデータを送信できる対象を、システム、
ContentCaptureService
、またはSpeechRecognizer#createOnDeviceSpeechRecognizer()
によって作成されたデバイス上の音声認識サービスに限定しなければなりません。 - [9.8/H-1-2] 起動ワード検出サービスがマイクの音声データまたはその派生データを送信できる対象を、
HotwordDetectionService
API を通じたシステム サーバーか、ContentCaptureManager
API を通じたContentCaptureService
に限定しなければなりません。 - [9.8/H-1-3] 個々のハードウェアでトリガーされたリクエストについて、30 秒間を超えるマイク音声を起動ワード検出サービスに供給してはなりません。
- [9.8/H-1-4] 個々のリクエストについて、8 秒間を超えてバッファリングされたマイク音声を起動ワード検出サービスに供給してはなりません。
- [9.8/H-1-5] 30 秒間を超えてバッファリングされたマイク音声を音声操作サービスまたは同様のエンティティに供給してはなりません。
- [9.8/H-1-6] 成功した各起動ワード結果について、100 バイトを超えるデータを起動ワード検出サービスから送信できるようにしてはなりません。ただし、HotwordAudioStream を介して渡されたオーディオ データは除きます。
- [9.8/H-1-7] 否定的な各起動ワード結果について、5 ビットを超えるデータを起動ワード検出サービスから送信できるようにしてはなりません。
- [9.8/H-1-8] システム サーバーから起動ワード検証リクエストがあった場合にのみ、起動ワード検出サービスからのデータ送信を許可しなければなりません。
- [9.8/H-1-9] ユーザーによるインストールが可能なアプリが起動ワード検出サービスを提供できるようにしてはなりません。
- [9.8/H-1-10] 起動ワード検出サービスによるマイクの使用に関する定量的データを UI に表示してはなりません。
- [9.8/H-1-11] セキュリティ研究者が検査できるように、起動ワード検出サービスからのすべての送信に含まれるバイト数をログに記録しなければなりません。
- [9.8/H-1-12] セキュリティ研究者が検査できるように、起動ワード検出サービスからのすべての送信の未加工コンテンツをログに記録するデバッグモードをサポートしなければなりません。
- [9.8/H-1-14] 成功した起動ワード結果が音声操作サービスまたは同様のエンティティに送信された場合に、セクション 9.8.2 で説明されているマイク インジケーターを表示しなければなりません。
新しい要件の開始
- [9.8/H-1-15] 成功した起動ワード結果で提供されるオーディオ ストリームが、起動ワード検出サービスから音声操作サービスへの一方向で送信されるようにしなければなりません。
新しい要件の終了
- [9.8/H-SR-1] 起動ワード検出サービスのプロバイダとしてアプリを設定する前に、ユーザーに通知することが強く推奨されます。
- [9.8/H-SR-2] 起動ワード検出サービスからの非構造化データの送信を禁止することが強く推奨されます。
- [9.8/H-SR-3] 起動ワード検出サービスをホストするプロセスを、少なくとも 1 時間に 1 回、またはハードウェア トリガー イベント 30 回ごとに(どちらか早い方)、再起動することが強く推奨されます。
システム API HotwordDetectionService
や、マイクの使用を示さず同様の起動ワード検出メカニズムを使用するアプリがデバイス実装に含まれる場合、そのアプリは:
- [9.8/H-2-1] サポートされている各起動ワードフレーズについて、ユーザーに明示的な通知を提供しなければなりません。
- [9.8/H-2-2] 起動ワード検出サービスを通じて、未加工音声データまたはその派生データを保持してはなりません。
- [9.8/H-2-3] 起動ワード検出サービスから、
ContentCaptureService
、またはデバイス上の音声認識サービスを除き、音声データ、音声の(全体的もしくは部分的)再構築に使用できるデータ、または起動ワード自体とは関係のないオーディオ コンテンツを送信してはなりません。
新しい要件の開始
システム API VisualQueryDetectionService
、または、マイクやカメラへのアクセスを示さないクエリ検出の別のメカニズムをサポートする場合、ハンドヘルド デバイス実装は:
- [9.8/H-3-1] クエリ検出サービスがデータを送信できる対象を、システム、
ContentCaptureService
、またはデバイス上の音声認識サービス(SpeechRecognizer#createOnDeviceSpeechRecognizer()
によって作成されるサービス)に限定しなければなりません。 - [9.8/H-3-2]
ContentCaptureService
またはデバイス上の音声認識サービスを除き、音声情報または動画情報をVisualQueryDetectionService
から送信できるようにしてはなりません。 - [9.8/H-3-3] デジタル アシスタント アプリを使用しようとするユーザーの意図をデバイスが検出したとき(カメラを介してユーザーの存在を検出したときなど)は、システム UI にユーザー通知を表示しなければなりません。
- [9.8/H-3-4] ユーザークエリが検出された直後に、マイク インジケーターを表示し、検出されたユーザークエリを UI に表示しなければなりません。
- [9.8/H-3-5] ユーザーがインストール可能なアプリが、ビジュアル クエリ検出サービスを提供できるようにしてはなりません。
新しい要件の終了
android.hardware.microphone
を宣言する場合、ハンドヘルド デバイス実装は:
- [9.8.2/H-4-1] アプリがマイクからオーディオ データにアクセスしているときはマイク インジケーターを表示しなければなりません。ただし、
HotwordDetectionService
、SOURCE_HOTWORD
、ContentCaptureService
、またはセクション 9.1 で CDD 識別子 [C-4-X] が割り当てられたロールを持つアプリからのみマイクにアクセスする場合は、この限りではありません。 - [9.8.2/H-4-2]
PermissionManager.getIndicatorAppOpUsageData()
から返された、マイクを使用している最近使ったアプリとアクティブなアプリのリストを、関連する属性メッセージとともに表示しなければなりません。
android.hardware.camera.any
を宣言する場合、ハンドヘルド デバイス実装は:
- [9.8.2/H-5-1] アプリがライブ カメラデータにアクセスしているときはカメラ インジケーターを表示しなければなりません。ただし、セクション 9.1 で CDD 識別子 [C-4-X] が割り当てられたロールを持つアプリからのみカメラにアクセスする場合は、この限りではありません。
- [9.8.2/H-5-2]
PermissionManager.getIndicatorAppOpUsageData()
から返された、カメラを使用している最近使ったアプリとアクティブなアプリを、関連する属性メッセージとともに表示しなければなりません。
2.2.6. デベロッパー ツール、開発者向けオプションの互換性
ハンドヘルド デバイス実装は(* タブレットには適用されません):
- [6.1/H-0-1]* シェルコマンド
cmd testharness
をサポートしなければなりません。
ハンドヘルド デバイス実装は(* タブレットには適用されません):
- Perfetto
- [6.1/H-0-2]* cmdline で perfetto ドキュメントを遵守しているシェルユーザーに
/system/bin/perfetto
バイナリを公開しなければなりません。 - [6.1/H-0-3]* perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れなければなりません。
- [6.1/H-0-4]* perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込まなければなりません。
- [6.1/H-0-5]* 少なくとも perfetto ドキュメントで規定されたデータソースを、perfetto バイナリを通じて提供しなければなりません。
- [6.1/H-0-6]* perfetto traced デーモンは、デフォルトで有効でなければなりません(システム プロパティ
persist.traced.enable
)。
- [6.1/H-0-2]* cmdline で perfetto ドキュメントを遵守しているシェルユーザーに
2.2.7. ハンドヘルドのメディア パフォーマンス クラス
メディア パフォーマンス クラスの定義については、セクション 7.11 をご覧ください。
2.2.7.1. メディア
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.T
を返す場合、ハンドヘルド デバイス実装は:
- Android 13 CDD セクション 2.2.7.1 に記載されているメディア要件を遵守しなければなりません。
新しい要件の開始
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.U
を返す場合、ハンドヘルド デバイス実装は:
- [5.1/H-1-1]
CodecCapabilities.getMaxSupportedInstances()
メソッドとVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画デコーダ セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-2] 任意のコーデックの組み合わせ(AVC、HEVC、VP9、AV1 以降)の 8 ビット(SDR)ハードウェア動画デコーダ セッションの 6 インスタンスの同時実行を、3 セッションは解像度 1080p、30 fps で、残り 3 セッションは解像度 4K、30 fps でサポートしなければなりません(AV1 を除く)。AV1 コーデックでは、解像度 1080p のサポートのみが必要ですが、解像度 1080p、30 fps で 6 インスタンスをサポートする必要があります。
- [5.1/H-1-3]
CodecCapabilities.getMaxSupportedInstances()
メソッドとVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画エンコーダ セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-4] 任意のコーデックの組み合わせ(AVC、HEVC、VP9、AV1 以降)の 8 ビット(SDR)ハードウェア動画エンコーダ セッションの 6 インスタンスの同時実行を、4 セッションは解像度 1080p、30 fps で、残り 2 セッションは解像度 4K、30 fps でサポートしなければなりません(AV1 を除く)。AV1 コーデックでは、解像度 1080p のサポートのみが必要ですが、解像度 1080p、30 fps で 6 インスタンスをサポートする必要があります。
- [5.1/H-1-5]
CodecCapabilities.getMaxSupportedInstances()
メソッドとVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画エンコーダ セッションとハードウェア動画デコーダ セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-6] 任意のコーデックの組み合わせ(AVC、HEVC、VP9、AV1 以降)の 8 ビット(SDR)ハードウェア動画デコーダ セッションとハードウェア動画エンコーダ セッションの 6 インスタンスの同時実行を、3 セッション(そのうちエンコーダ セッションは最大 2 つ)は解像度 4K、30 fps で(AV1 を除く)、残り 3 セッションは解像度 1080p でサポートしなければなりません。AV1 コーデックでは、解像度 1080p のサポートのみが必要ですが、解像度 1080p、30 fps で 6 インスタンスをサポートする必要があります。
- [5.1/H-1-19] 任意のコーデックの組み合わせ(AVC、HEVC、VP9、AV1 以降)の 10 ビット(HDR)ハードウェア動画デコーダ セッションとハードウェア動画エンコーダ セッションの 3 インスタンスの同時実行を、解像度 4K、30 fps でサポートしなければなりません(AV1 を除く)。そのうちエンコーダ セッションは最大 1 つで、GL サーフェスから RGBA_1010102 入力形式で設定可能です。GL サーフェスからエンコードする場合、エンコーダによる HDR メタデータの生成は不要です。AV1 コーデック セッションでは、要件が解像度 4K であっても、解像度 1080p のサポートのみが必要です。
- [5.1/H-1-7] 負荷がかかった状態で、すべてのハードウェア動画エンコーダの 1080p 以下の動画エンコード セッションについて、コーデック初期化レイテンシが 40 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像記録の初期化を同時実行することを指します。ドルビー ビジョン コーデックでは、コーデック初期化レイテンシは 50 ms 以下でなければなりません。
- [5.1/H-1-8] 負荷がかかった状態で、すべての音声エンコーダでのビットレート 128 kbps 以下の音声エンコード セッションについて、コーデック初期化レイテンシが 30 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像記録の初期化を同時実行することを指します。
- [5.1/H-1-9] 8 ビット(SDR)と 10 ビット HDR の両方のコンテンツについて、解像度 4K、30 fps で(AV1 を除く)同時に実行されるコーデックの組み合わせで、セキュアなハードウェア動画デコーダ セッション(AVC、HEVC、VP9、AV1 以降)の 2 つのインスタンスをサポートしなければなりません。AV1 コーデック セッションでは、要件が解像度 4K であっても、解像度 1080p のサポートのみが必要です。
- [5.1/H-1-10] 同時に実行される任意のコーデックの組み合わせで、セキュアでないハードウェア動画デコーダ セッションの 3 つのインスタンスと、セキュアなハードウェア動画デコーダ セッションの 1 つのインスタンス(合計 4 つのインスタンス。AVC、HEVC、VP9、AV1 以降)をサポートしなければなりません。3 つのセッション(1 つのセキュアなデコーダ セッションを含む)は解像度 4K、30 fps で(AV1 を除く)、1 つのセキュアでないセッションは解像度 1080p、30 fps です。最大 2 つのセッションを 10 ビット HDR にできます。AV1 コーデック セッションでは、要件が解像度 4K であっても、解像度 1080p のサポートのみが必要です。
- [5.1/H-1-11] デバイス上のすべてのハードウェア AVC、HEVC、VP9、AV1 デコーダについて、セキュアなデコーダをサポートしなければなりません。
- [5.1/H-1-12] 負荷がかかった状態で、すべてのハードウェア動画デコーダの 1080p 以下の動画デコード セッションについて、コーデック初期化レイテンシが 40 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像再生の初期化を同時実行することを指します。ドルビー ビジョン コーデックでは、コーデック初期化レイテンシは 50 ms 以下でなければなりません。
- [5.1/H-1-13] 負荷がかかった状態で、すべての音声デコーダでのビットレート 128 kbps 以下の音声デコード セッションについて、コーデック初期化レイテンシが 30 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像再生の初期化を同時実行することを指します。
- [5.1/H-1-14] AV1 ハードウェア デコーダのメイン 10、レベル 4.1、フィルム グレインをサポートしなければなりません。
- [5.1/H-1-15] 4K60 をサポートするハードウェア動画デコーダを少なくとも 1 つ備えなければなりません。
- [5.1/H-1-16] 4K60 をサポートするハードウェア動画エンコーダを少なくとも 1 つ備えなければなりません。
- [5.3/H-1-1] 負荷時の 4K 60 fps の動画セッションで、10 秒間に 1 フレームを超えるドロップが発生してはなりません(フレーム ドロップ 0.167% 未満)。
- [5.3/H-1-2] 4K セッションの負荷時の 60 fps の動画セッションで、動画解像度の変更中、10 秒間に 1 フレームを超えるドロップが発生してはなりません。
- [5.6/H-1-1] CTS 検証ツールのタップツートーン テストを使用して、タップツートーン レイテンシを 80 ミリ秒以下にしなければなりません。
- [5.6/H-1-2] 少なくとも 1 つのサポート対象データパスで、ラウンドトリップ オーディオ レイテンシを 80 ミリ秒以下にしなければなりません。
- [5.6/H-1-3] 3.5 mm オーディオ ジャック(存在する場合)および USB オーディオ(サポートされる場合)のステレオ出力については、低レイテンシ構成およびストリーミング構成のデータパス全体を通じて 24 ビット以上をサポートしなければなりません。低レイテンシ構成の場合、アプリは AAudio を低レイテンシ コールバック モードで使用すべきです。ストリーミング構成の場合、アプリは Java AudioTrack を使用すべきです。低レイテンシ構成とストリーミング構成の両方で、HAL 出力シンクはターゲット出力形式として
AUDIO_FORMAT_PCM_24_BIT
、AUDIO_FORMAT_PCM_24_BIT_PACKED
、AUDIO_FORMAT_PCM_32_BIT
、AUDIO_FORMAT_PCM_FLOAT
のいずれかを受け入れるべきです。 - [5.6/H-1-4] 4 チャンネル以上の USB オーディオ デバイスをサポートしなければなりません(曲をプレビューするために DJ コントローラで使用されます)。
- [5.6/H-1-5] クラス準拠の MIDI デバイスをサポートし、MIDI 機能フラグを宣言しなければなりません。
- [5.6/H-1-9] 少なくとも 12 チャンネルのミキシングをサポートしなければなりません。これは 7.1.4 チャンネル マスクを使用して AudioTrack を開き、すべてのチャンネルをステレオに適切に空間化またはダウンミックスできることを意味します。
- [5.6/H-SR] 少なくとも 9.1.6 チャンネル マスクと 22.2 チャンネル マスクに対応している 24 チャンネル ミキシングをサポートすることが強く推奨されます。
- [5.7/H-1-2] 次のコンテンツ復号機能で、
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
をサポートしなければなりません。
最小サンプルサイズ | 4 MiB |
サブサンプルの最小数 - H264 または HEVC | 32 |
サブサンプルの最小数 - VP9 | 9 |
サブサンプルの最小数 - AV1 | 288 |
サブサンプルの最小バッファサイズ | 1 MiB |
汎用暗号の最小バッファサイズ | 500 KiB |
同時実行セッションの最小数 | 30 |
セッションあたりの鍵の最小数 | 20 |
鍵の最小合計数(すべてのセッション) | 80 |
DRM 鍵の最小合計数(すべてのセッション) | 6 |
メッセージ サイズ | 16 KiB |
復号されたフレーム/秒 | 60 fps |
- [5.1/H-1-17] AVIF ベースライン プロファイルをサポートする少なくとも 1 つのハードウェア画像デコーダがなければなりません。
- [5.1/H-1-18] 30 fps と 1 Mbps で最大 480p の解像度をエンコードできる AV1 エンコーダをサポートしなければなりません。
[5.12/H-1-1] 必須[5.12/H-SR] デバイス上にあるすべてのハードウェア AV1 および HEVC エンコーダのFeature_HdrEditing
機能をサポートすることを強く推奨します。- [5.12/H-1-2] デバイス上にあるすべてのハードウェア AV1 エンコーダと HEVC エンコーダで RGBA_1010102 カラー形式をサポートしなければなりません。
- [5.12/H-1-3] 8 ビットと 10 ビットの両方で YUV テクスチャからサンプリングするために、EXT_YUV_target 拡張機能のサポートをアドバタイズしなければなりません。
- [7.1.4/H-1-1] ディスプレイ処理ユニット(DPU)に少なくとも 6 つのハードウェア オーバーレイがなければならず、そのうち 2 つ以上で 10 ビットの動画コンテンツを表示できなければなりません。
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.U
を返し、ハードウェア AVC または HEVC エンコーダのサポートが含まれる場合、ハンドヘルド デバイス実装は:
- [5.2/H-2-1] パフォーマンス クラス 14(PC14)動画エンコード品質(VEQ)テストの実行で定義されているように、ハードウェア AVC または HEVC コーデックの動画エンコーダのレート歪み曲線で規定されている最低品質目標を満たさなければなりません。
新しい要件の終了
2.2.7.2. カメラ
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.T
を返す場合、ハンドヘルド デバイス実装は:
- Android 13 CDD セクション 2.2.7.2 に記載されているメディア要件を遵守しなければなりません。
新しい要件の開始
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.U
を返す場合、ハンドヘルド デバイス実装は:
- [7.5/H-1-1] 4K、30 fps での動画キャプチャをサポートする、解像度 12 メガピクセル以上のプライマリ背面カメラがなければなりません。プライマリ背面カメラとは、カメラ ID が最も低い背面カメラのことです。
- [7.5/H-1-2] 解像度 6 メガピクセル以上のプライマリ前面カメラがなければならず、1080p、30 fps での動画キャプチャをサポートしなければなりません。プライマリ前面カメラとは、カメラ ID が最も低い前面カメラのことです。
- [7.5/H-1-3] プライマリ背面カメラについては
FULL
以上のandroid.info.supportedHardwareLevel
プロパティをサポートし、プライマリ前面カメラについてはLIMITED
以上の同プロパティをサポートしなければなりません。 - [7.5/H-1-4] 両方のプライマリ カメラについて、
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
をサポートしなければなりません。 - [7.5/H-1-5] 両方のプライマリ カメラについて、ITS 照明条件(3000K)で CTS カメラの PerformanceTest によって測定したとき、解像度 1080p の camera2 JPEG キャプチャ レイテンシが 1,000
900ms 未満でなければなりません。 - [7.5/H-1-6] 両方のプライマリ カメラについて、ITS 照明条件(3000K)で CTS カメラの PerformanceTest によって測定したとき、camera2 起動レイテンシ(カメラを開いてから最初のプレビュー フレームまで)が 500 ms 未満でなければなりません。
- [7.5/H-1-8] プライマリ背面カメラについて、
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
とandroid.graphics.ImageFormat.RAW_SENSOR
をサポートしなければなりません。 - [7.5/H-1-9] 720p または 1080p、240 fps をサポートするプライマリ背面カメラがなければなりません。
- [7.5/H-1-10] 同じ方向を向いたウルトラワイド RGB カメラが 1 つある場合、プライマリ カメラの最小 ZOOM_RATIO は 1.0 未満でなければなりません。
- [7.5/H-1-11] プライマリ カメラに前面および背面での同時ストリーミングを実装しなければなりません。
- [7.5/H-1-12] プライマリ前面カメラとプライマリ背面カメラの両方で
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
をサポートしなければなりません。 - [7.5/H-1-13] 背面 RGB カメラが 1 つ以上ある場合、プライマリ背面カメラで
LOGICAL_MULTI_CAMERA
機能をサポートしなければなりません。 - [7.5/H-1-14] プライマリ前面カメラとプライマリ背面カメラの両方で
STREAM_USE_CASE
機能をサポートしなければなりません。 - [7.5/H-1-15] プライマリ カメラについて、CameraX 拡張機能と Camera2 拡張機能の両方を介して、
ボケ表現拡張機能と夜間モード拡張機能をサポートしなければなりません。 - [7.5/H-1-16] プライマリ カメラについて DYNAMIC_RANGE_TEN_BIT 機能をサポートしなければなりません。
- [7.5/H-1-17] プライマリ カメラについて CONTROL_SCENE_MODE_FACE_PRIORITY 機能と顔検出機能(STATISTICS_FACE_DETECT_MODE_SIMPLE または STATISTICS_FACE_DETECT_MODE_FULL)をサポートしなければなりません。
新しい要件の終了
2.2.7.3. ハードウェア
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.T
を返す場合、ハンドヘルド デバイス実装は:
- Android 13 CDD セクション 2.2.7.3 に記載されているメディア要件を遵守しなければなりません。
新しい要件の開始
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.U
を返す場合、ハンドヘルド デバイス実装は:
- [7.1.1.1/H-2-1] 画面の解像度が少なくとも 1080p でなければなりません。
- [7.1.1.3/H-2-1] 画面密度が少なくとも 400 dpi でなければなりません。
- [7.1.1.3/H-3-1] 少なくとも平均 1,000 ニトをサポートする HDR ディスプレイがなければなりません。
- [7.6.1/H-2-1] 物理メモリが少なくとも 8 GB でなければなりません。
新しい要件の終了
2.2.7.4. パフォーマンス
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.T
を返す場合、ハンドヘルド デバイス実装は:
- Android 13 CDD セクション 2.2.7.4 に記載されているパフォーマンス要件を遵守しなければなりません。
新しい要件の開始
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
について android.os.Build.VERSION_CODES.U
を返す場合、ハンドヘルド デバイス実装は:
- [8.2/H-1-1] 少なくとも 150 MB/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
- [8.2/H-1-2] 少なくとも 10 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
- [8.2/H-1-3] 少なくとも 250 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
- [8.2/H-1-4] 少なくとも 100 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。
- [8.2/H-1-5] 少なくとも 50 MB/s の並列シーケンシャル読み取り / 書き込みパフォーマンス(2 つの読み取りと 1 つの書き込み)を実現しなければなりません。
新しい要件の終了
2.3. テレビの要件
Android テレビデバイスとは、約 10 フィート離れた場所にいるユーザーがデジタル メディア、映画、ゲーム、アプリ、ライブテレビを楽しむためのエンターテイメント インターフェースである Android デバイス実装を指します(「鑑賞モード」または「10 フィート ユーザー インターフェース」)。
次の基準をすべて満たす場合、Android デバイス実装はテレビに分類されます。
- ユーザーから 10 フィート離れたディスプレイに表示されるユーザー インターフェースをリモコンで操作するためのメカニズムを提供する。
- 対角長が 24 インチを超える埋め込みスクリーン ディスプレイがある、または、VGA、HDMI、DisplayPort、ディスプレイ用ワイヤレス ポートなどの動画出力ポートがある。
このセクションでこれ以降記載する追加要件は、Android テレビデバイス実装に固有のものです。
2.3.1. ハードウェア
テレビデバイス実装は:
- [7.2.2/T-0-1] D-pad をサポートしなければなりません。
- [7.2.3/T-0-1] ホーム機能と戻る機能を提供しなければなりません。
- [7.2.3/T-0-2] 戻る機能(
KEYCODE_BACK
)の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。 - [7.2.6.1/T-0-1] ゲーム コントローラのサポートを含まなければならず、
android.hardware.gamepad
機能フラグを宣言しなければなりません。 - [7.2.7/T] ユーザーがタップ以外のナビゲーションと主要なナビゲーション キー入力にアクセスできるリモコンを提供すべきです。
3 軸ジャイロスコープが含まれる場合、テレビデバイス実装は:
- [7.3.4/T-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
- [7.3.4/T-1-2] 1,000 度/秒までの方向変化を測定できなければなりません。
テレビデバイス実装は:
- [7.4.3/T-0-1] Bluetooth と Bluetooth LE をサポートしなければなりません。
- [7.6.1/T-0-1] アプリの個人データ(「/data」パーティション)に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。
ホストモードをサポートする USB ポートが含まれる場合、テレビデバイス実装は:
- [7.5.3/T-1-1] この USB ポートを通じて接続する(ただし常に接続されているとは限らない)外部カメラのサポートを含まなければなりません。
テレビデバイス実装が 32 ビットの場合:
[7.6.1/T-1-1] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 896 MB でなければなりません。
- 小 / 標準画面で 400 dpi 以上
- 大画面で xhdpi 以上
- 特大画面で tvdpi 以上
テレビデバイス実装が 64 ビットの場合:
[7.6.1/T-2-1] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 1,280 MB でなければなりません。
- 小 / 標準画面で 400 dpi 以上
- 大画面で xhdpi 以上
- 特大画面で tvdpi 以上
なお、上記の「カーネルとユーザー空間に利用できるメモリ」とは、デバイス実装でカーネルの制御下にない、無線や動画などのハードウェア コンポーネント専用のメモリに加えて提供されるメモリ空間を指します。
テレビデバイス実装は:
2.3.2. マルチメディア
テレビデバイス実装は、次の形式のオーディオ エンコードとデコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
- [5.1/T-0-1] MPEG-4 AAC プロファイル(AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC プロファイル(AAC+)
- [5.1/T-0-3] AAC ELD(Enhanced Low Delay AAC)
テレビデバイス実装は、次の形式の動画エンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
テレビデバイス実装は:
- [5.2.2/T-SR-1] 30 フレーム/秒で解像度 720p と 1080p の動画の H.264 エンコードをサポートすることが強く推奨されます。
テレビデバイス実装は、次の形式の動画デコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
テレビデバイス実装は、セクション 5.3.1 で記載のとおり、次に示すもの以下の標準的な動画フレームレートと解像度で MPEG-2 デコードをサポートしなければなりません。
- [5.3.1/T-1-1] メイン プロファイル ハイレベルで 29.97 フレーム/秒の HD 1080p。
- [5.3.1/T-1-2] メイン プロファイル ハイレベルで 59.94 フレーム/秒の HD 1080i。インターレース MPEG-2 動画をインターレース解除し、サードパーティ アプリで利用できるようにしなければなりません。
テレビデバイス実装は、セクション 5.3.4 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で H.264 デコードをサポートしなければなりません。
- [5.3.4/T-1-1] ベースライン プロファイルで 60 フレーム/秒の HD 1080p
- [5.3.4/T-1-2] メイン プロファイルで 60 フレーム/秒の HD 1080p
- [5.3.4/T-1-3] ハイ プロファイル レベル 4.2 で 60 フレーム/秒の HD 1080p
H.265 ハードウェア デコーダを備えたテレビデバイス実装は、セクション 5.3.5 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で H.265 デコードをサポートしなければなりません。
- [5.3.5/T-1-1] メイン プロファイル レベル 4.1 で 60 フレーム/秒の HD 1080p
H.265 デコードと UHD デコード プロファイルをサポートする場合、H.265 ハードウェア デコーダを備えたテレビデバイス実装は:
- [5.3.5/T-2-1] メイン 10 レベル 5 メイン ティア プロファイルで 60 フレーム/秒の UHD デコード プロファイルをサポートしなければなりません。
テレビデバイス実装は、セクション 5.3.6 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で VP8 デコードをサポートしなければなりません。
- [5.3.6/T-1-1] 60 フレーム/秒のデコード プロファイルの HD 1080p
VP9 ハードウェア デコーダを備えたテレビデバイス実装は、セクション 5.3.7 で詳述するように、次に示すもの以下の標準的な動画フレームレートと解像度で VP9 デコードをサポートしなければなりません。
- [5.3.7/T-1-1] プロファイル 0(8 ビット色深度)で 60 フレーム/秒の HD 1080p
VP9 デコードと UHD デコード プロファイルをサポートする場合、VP9 ハードウェア デコーダを備えたテレビデバイス実装は:
- [5.3.7/T-2-1] プロファイル 0(8 ビット色深度)で 60 フレーム/秒の UHD デコード プロファイルをサポートしなければなりません。
- [5.3.7/T-SR1] プロファイル 2(10 ビット色深度)で 60 フレーム/秒の UHD デコード プロファイルをサポートすることが強く推奨されます。
テレビデバイス実装は:
- [5.5/T-0-1] 圧縮オーディオ パススルー出力(デバイスでオーディオ デコードが行われない)を除き、サポート対象の出力で、システムのマスター ボリュームとデジタル オーディオ出力ボリュームの減衰のサポートを含まなければなりません。
内蔵ディスプレイはないが、HDMI 経由で接続される外部ディスプレイをサポートする場合、テレビデバイス実装は:
- [5.8/T-0-1] デバイスが販売されている地域のリフレッシュ レートに応じて、外部ディスプレイが 50 Hz または 60 Hz のリフレッシュ レートで動作する、選択したピクセル フォーマットの最高解像度に HDMI 出力モードを設定しなければなりません。
50 Hz または 60 Hz のリフレッシュ レートでサポートできる最大解像度を選択するように HDMI 出力モードを設定しなければなりません。 - [5.8/T-SR-1] ユーザーが構成可能な HDMI リフレッシュ レートセレクタを提供することが強く推奨されます。
- [5.8] デバイスが販売されている地域の動画リフレッシュ レートに応じて、HDMI 出力モードのリフレッシュ レートを 50 Hz または 60 Hz に設定すべきです。
内蔵ディスプレイはないが、HDMI 経由で接続される外部ディスプレイをサポートする場合、テレビデバイス実装は:
- [5.8/T-1-1] HDCP 2.2 をサポートしなければなりません。
UHD デコードはサポートしないが、HDMI 経由で接続される外部ディスプレイをサポートする場合、テレビデバイス実装は:
- [5.8/T-2-1] HDCP 1.4 をサポートしなければなりません。
2.3.3. ソフトウェア
テレビデバイス実装は:
- [3/T-0-1] 機能
android.software.leanback
とandroid.hardware.type.television
を宣言しなければなりません。 - [3.2.3.1/T-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
- [3.4.1/T-0-1]
android.webkit.Webview
API の完全な実装を提供しなければなりません。
ロック画面をサポートする場合、Android テレビデバイス実装は:
- [3.8.10/T-1-1] メディア通知テンプレートを含め、ロック画面通知を表示しなければなりません。
テレビデバイス実装は:
- [3.8.14/T-SR-1] ピクチャー イン ピクチャー(PIP)モードのマルチウィンドウをサポートすることが強く推奨されます。
- [3.10/T-0-1] サードパーティのユーザー補助サービスをサポートしなければなりません。
- [3.10/T-SR-1] talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack(プリインストールのテキスト読み上げエンジンでサポートされている言語)のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。
機能 android.hardware.audio.output
をレポートする場合、テレビデバイス実装は:
- [3.11/T-SR-1] デバイスで利用可能な言語をサポートする TTS エンジンを含むことが強く推奨されます。
- [3.11/T-1-1] サードパーティ TTS エンジンのインストールをサポートしなければなりません。
テレビデバイス実装は:
- [3.12/T-0-1] テレビ入力フレームワークをサポートしなければなりません。
2.3.4. パフォーマンスと電力
- [8.1/T-0-1] 一貫したフレーム レイテンシ。一貫性のないフレーム レイテンシ、またはフレームのレンダリングの遅延は、1 秒間に 5 フレームを超えて発生してはならず、1 秒間に 1 フレーム未満であるべきです。
- [8.2/T-0-1] 少なくとも 5 MB/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
- [8.2/T-0-2] 少なくとも 0.5 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
- [8.2/T-0-3] 少なくとも 15 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
- [8.2/T-0-4] 少なくとも 3.5 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。
AOSP に含まれるデバイス電源管理を改善する機能を含むか、AOSP に含まれる機能を拡張する場合、テレビデバイス実装は:
- [8.3/T-1-1] バッテリー セーバー機能を有効または無効にするユーザー アフォーダンスを提供しなければなりません。
バッテリーがない場合、テレビデバイス実装は:
- [8.3/T-1-2] 電池非搭載デバイスをサポートするに記載されているとおり、デバイスを電池非搭載デバイスとして登録しなければなりません。
バッテリーがある場合、テレビデバイス実装は:
- [8.3/T-1-3] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供しなければなりません。
テレビデバイス実装は:
- [8.4/T-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとのバッテリー消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
- [8.4/T-0-2] すべての消費電力値をミリアンペア時(mAh)単位でレポートしなければなりません。
- [8.4/T-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、
uid_cputime
カーネル モジュール実装を通じて要件を満たしています。 - [8.4/T] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
- [8.4/T-0-4] この電力使用量を、
adb shell dumpsys batterystats
シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。
2.3.5. セキュリティ モデル
テレビデバイス実装は:
- [9/T-0-1]
android.hardware.security.model.compatible
機能を宣言しなければなりません。 - [9.11/T-0-1] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
- [9.11/T-0-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト(AOSP)は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザベースの隔離オプションをセキュアに実装する方法を選択することもできます。
- [9.11/T-0-3] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer(HAL)と Trusty を提供しており、これを使用してこの要件を満たすことができます。
- [9.11/T-0-4] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。
なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint
機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵構成証明をサポートする必要があるという要件を免除されます。
セキュアロック画面をサポートする場合、テレビデバイス実装は:
- [9.11/T-1-1] ロック解除状態からロック状態への遷移のためのスリープ タイムアウトを、最小許容タイムアウト 15 秒以下でユーザーが選択できるようにしなければなりません。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言しない場合、テレビデバイス実装は:
- [9.5/T-2-1] 制限付きプロファイル(追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能)をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言する場合、テレビデバイス実装は:
- [9.5/T-3-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。
android.hardware.microphone
を宣言する場合、テレビデバイス実装は:
- [9.8.2/T-4-1] アプリがマイクからオーディオ データにアクセスしているときはマイク インジケーターを表示しなければなりません。ただし、HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService、またはセクション 9.1 で CDD 識別子 C-3-X が割り当てられたロールを持つアプリからのみマイクにアクセスする場合は、この限りではありません]。
- [9.8.2/T-4-2] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、マイク インジケーターを非表示にしてはなりません。
android.hardware.camera.any
を宣言する場合、テレビデバイス実装は:
- [9.8.2/T-5-1] アプリがライブ カメラデータにアクセスしているときはカメラ インジケーターを表示しなければなりません。ただし、セクション 9.1 で CDD 識別子 [C-3-X] が割り当てられたロールを持つアプリからのみカメラにアクセスする場合は、この限りではありません。
- [9.8.2/T-5-2] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、カメラ インジケーターを非表示にしてはなりません。
2.3.6. デベロッパー ツール、開発者向けオプションの互換性
テレビデバイス実装は:
- Perfetto
- [6.1/T-0-1] cmdline で perfetto ドキュメントを遵守しているシェルユーザーに
/system/bin/perfetto
バイナリを公開しなければなりません。 - [6.1/T-0-2] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れなければなりません。
- [6.1/T-0-3] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込まなければなりません。
- [6.1/T-0-4] 少なくとも perfetto ドキュメントで規定されたデータソースを、perfetto バイナリを通じて提供しなければなりません。
- [6.1/T-0-1] cmdline で perfetto ドキュメントを遵守しているシェルユーザーに
2.4. スマートウォッチの要件
Android スマートウォッチ デバイスとは、身体(通常は手首)に装着することを目的とした Android デバイス実装を指します。
次の基準をすべて満たす場合、Android デバイス実装はスマートウォッチに分類されます。
- 画面の対角長が物理的に 1.1 から 2.5 インチ。
- 身体に装着するメカニズムを提供する。
このセクションでこれ以降記載する追加要件は、Android スマートウォッチ デバイス実装に固有のものです。
2.4.1. ハードウェア
スマートウォッチ デバイス実装は:
[7.1.1.1/W-0-1] 画面の対角サイズが物理的に 1.1 から 2.5 インチでなければなりません。
[7.2.3/W-0-1] ユーザーが利用できるホーム機能と、戻る機能(
UI_MODE_TYPE_WATCH
のときを除く)を備えなければなりません。[7.2.4/W-0-1] タッチスクリーン入力をサポートしなければなりません。
[7.3.1/W-SR-1] 3 軸加速度計を含むことが強く推奨されます。
新しい要件の開始
Vulkan のサポートが含まれる場合、スマートウォッチ デバイス実装は:
- [7.1.4.2/W-1-1] Android ベースライン 2021 プロファイルで規定されている要件を満たさなければなりません。
新しい要件の終了
GPS / GNSS レシーバーが含まれ、android.hardware.location.gps
機能フラグを通じてアプリに機能をレポートする場合、スマートウォッチ デバイス実装は:
- [7.3.3/W-1-1] GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GNSS 測定値が判明したらすぐにレポートしなければなりません。
- [7.3.3/W-1-2] 全天条件下で、位置を特定した後に、静止しているか加速度 0.2 m/s2 未満で移動している間、位置 20 m 以内、速度 0.2 m/s 以内、時間 95% 以上を計算するのに十分な、GNSS の擬似距離と擬似距離レートをレポートしなければなりません。
3 軸ジャイロスコープが含まれる場合、スマートウォッチ デバイス実装は:
- [7.3.4/W-2-1] 1,000 度/秒までの方向変化を測定できなければなりません。
スマートウォッチ デバイス実装は:
[7.4.3/W-0-1] Bluetooth をサポートしなければなりません。
[7.6.1/W-0-1] アプリの個人データ(「/data」パーティション)に利用できる不揮発性ストレージが少なくとも 1 GB でなければなりません。
[7.6.1/W-0-2] カーネルとユーザー空間に利用できるメモリが少なくとも 416 MB でなければなりません。
[7.8.1/W-0-1] マイクを含まなければなりません。
[7.8.2/W] オーディオ出力があっても構いません。
2.4.2. マルチメディア
追加の要件はありません。
2.4.3. ソフトウェア
スマートウォッチ デバイス実装は:
- [3/W-0-1] 機能
android.hardware.type.watch
を宣言しなければなりません。 - [3/W-0-2] uiMode = UI_MODE_TYPE_WATCH をサポートしなければなりません。
- [3.2.3.1/W-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
スマートウォッチ デバイス実装は:
- [3.8.4/W-SR-1] アシスト アクションを処理するために、デバイスにアシスタントを実装することが強く推奨されます。
android.hardware.audio.output
機能フラグを宣言するスマートウォッチ デバイス実装は:
- [3.10/W-1-1] サードパーティのユーザー補助サービスをサポートしなければなりません。
- [3.10/W-SR-1] talkback オープンソース プロジェクトで提供されているスイッチ アクセスと TalkBack(プリインストールのテキスト読み上げエンジンでサポートされている言語)のユーザー補助サービスと同等かそれ以上の機能を持つユーザー補助サービスをデバイスにプリロードすることが強く推奨されます。
機能 android.hardware.audio.output をレポートする場合、スマートウォッチ デバイス実装は:
[3.11/W-SR-1] デバイスで利用可能な言語をサポートする TTS エンジンを含むことが強く推奨されます。
[3.11/W-0-1] サードパーティ TTS エンジンのインストールをサポートしなければなりません。
2.4.4. パフォーマンスと電力
AOSP に含まれるデバイス電源管理を改善する機能を含むか、AOSP に含まれる機能を拡張する場合、スマートウォッチ デバイス実装は:
- [8.3/W-SR-1] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供することが強く推奨されます。
- [8.3/W-SR-2] バッテリー セーバー機能を有効または無効にするユーザー アフォーダンスを提供することが強く推奨されます。
スマートウォッチ デバイス実装は:
- [8.4/W-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
- [8.4/W-0-2] すべての消費電力値をミリアンペア時(mAh)単位でレポートしなければなりません。
- [8.4/W-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、
uid_cputime
カーネル モジュール実装を通じて要件を満たしています。 - [8.4/W-0-4] この電力使用量を、
adb shell dumpsys batterystats
シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。 - [8.4/W] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
2.4.5. セキュリティ モデル
スマートウォッチ デバイス実装は:
- [9/W-0-1]
android.hardware.security.model.compatible
機能を宣言しなければなりません。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言しない場合、スマートウォッチ デバイス実装は:
- [9.5/W-1-1] 制限付きプロファイル(追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能)をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言する場合、スマートウォッチ デバイス実装は:
- [9.5/W-2-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。
新しい要件の開始
セキュアロック画面があり、TrustAgentService
システム API を実装する信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:
- [9.11.1/W-1-1] 少なくとも 72 時間以内ごとに 1 回、推奨される第 1 の認証方法(PIN、パターン、パスワードなど)のいずれかをユーザーに求めなければなりません。
新しい要件の終了
2.5. 自動車の要件
Android Automotive 実装とは、システムやインフォテインメント システムの一部または全部でオペレーティング システムとして Android を搭載した車両ヘッドユニットを指します。
機能 android.hardware.type.automotive
を宣言するか次の基準をすべて満たす場合、Android デバイス実装は自動車に分類されます。
- 自動車の一部として埋め込まれているか、自動車にプラグイン可能。
- 運転席列の画面をプライマリ ディスプレイとして使用する。
このセクションでこれ以降記載する追加要件は、Android 自動車デバイス実装に固有のものです。
2.5.1. ハードウェア
自動車デバイス実装は:
- [7.1.1.1/A-0-1] 画面の対角サイズが物理的に少なくとも 6 インチでなければなりません。
- [7.1.1.1/A-0-2] 画面サイズのレイアウトが少なくとも 750 dp x 480 dp でなければなりません。
- [7.2.3/A-0-1] ホーム機能を提供しなければならず、戻る機能と履歴機能を提供しても構いません。
- [7.2.3/A-0-2] 戻る機能(
KEYCODE_BACK
)の通常イベントと長押しイベントの両方を、フォアグラウンド アプリに送信しなければなりません。 - [7.3/A-0-1]
GEAR_SELECTION
、NIGHT_MODE
、PERF_VEHICLE_SPEED
、PARKING_BRAKE_ON
を実装しレポートしなければなりません。 - [7.3/A-0-2]
NIGHT_MODE
フラグの値は、ダッシュボードの昼間 / 夜間モードと一致しなければならず、周囲光センサー入力に基づくべきです。基になる周囲光センサーは、光度計と同じでも構いません。 - [7.3/A-0-3] 提供されるすべてのセンサーについて SensorAdditionalInfo の一部としてセンサー追加情報フィールド
TYPE_SENSOR_PLACEMENT
を提供しなければなりません。 - [7.3/A-SR1] GPS/GNSS と追加のセンサーを融合することで、位置情報を推算しても構いません。位置情報を推算する場合、対応するセンサータイプや使用する車両プロパティ ID を実装し、レポートすることが強く推奨されます。
[7.3/A-0-4] LocationManager#requestLocationUpdates() を介してリクエストする位置情報は、マップマッチされてはなりません。
[7.3.1/A-0-4] Android 自動車センサー座標系に準拠しなければなりません。
[7.3/A-SR-1] 3 軸加速度計と 3 軸ジャイロスコープを含むことが強く推奨されます。
[7.3/A-SR-2]
TYPE_HEADING
センサーを実装し、レポートすることが強く推奨されます。
OpenGL ES 3.1 をサポートする場合、自動車デバイス実装は:
- [7.1.4.1/A-0-1] OpenGL ES 3.1 以降を宣言しなければなりません。
- [7.1.4.1/A-0-2] Vulkan 1.1 をサポートしなければなりません。
- [7.1.4.1/A-0-3] Vulkan ローダーを含み、シンボルをすべてエクスポートしなければなりません。
新しい要件の開始
Vulkan のサポートが含まれる場合、自動車デバイス実装は:
- [7.1.4.2/A-1-1] Android ベースライン 2021 プロファイルで規定されている要件を満たさなければなりません。
新しい要件の終了
加速度計が含まれる場合、自動車デバイス実装は:
- [7.3.1/A-1-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
3 軸加速度計が含まれる場合、デバイス実装は:
- [7.3.1/A-SR-1] 軸数制限付き加速度計用の複合センサーを実装することが強く推奨されます。
3 軸未満の加速度計が含まれる場合、自動車デバイス実装は:
- [7.3.1/A-1-3]
TYPE_ACCELEROMETER_LIMITED_AXES
センサーを実装し、レポートしなければなりません。 - [7.3.1/A-1-4]
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
センサーを実装し、レポートしなければなりません。
ジャイロスコープが含まれる場合、自動車デバイス実装は:
- [7.3.4/A-2-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
- [7.3.4/A-2-3] 250 度/秒までの方向変化を測定できなければなりません。
- [7.3.4/A-SR-1] 解像度を可能な限り最大化するために、ジャイロスコープの測定範囲を +/-250 dps に設定することが強く推奨されます。
3 軸ジャイロスコープが含まれる場合、自動車デバイス実装は:
- [7.3.4/A-SR-2] 軸数を制限されたジャイロスコープ用の複合センサーを実装することが強く推奨されます。
3 軸未満のジャイロスコープが含まれる場合、自動車デバイス実装は:
- [7.3.4/A-4-1]
TYPE_GYROSCOPE_LIMITED_AXES
センサーを実装し、レポートしなければなりません。 - [7.3.4/A-4-2]
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
センサーを実装し、レポートしなければなりません。
GPS / GNSS レシーバーが含まれるが、モバイル ネットワーク ベースのデータ接続が含まれない場合、自動車デバイス実装は:
- [7.3.3/A-3-1] GPS / GNSS レシーバーが初めてオンになったとき、または 4 日以上経過した後、60 秒以内で位置を特定しなければなりません。
- [7.3.3/A-3-2] 他のすべての位置情報リクエスト(初めてでもなく 4 日以上経過した後でもないリクエスト)について、7.3.3/C-1-2 と 7.3.3/C-1-6 に記載されている初期位置算出時間基準を満たさなければなりません。要件 7.3.3/C-1-2 は通常、モバイル ネットワーク ベースのデータ接続のない車両において、レシーバーで計算した GNSS 軌道予測を使用するか、7.3.3/C-1-3 を満たす位置精度で少なくとも 60 秒間推算する機能とともに最後の既知の車両位置情報を使用することで、または両方を組み合わせることで満たされます。
TYPE_HEADING
センサーが含まれる場合、自動車デバイス実装は:
- [7.3.4/A-4-3] 少なくとも周波数 1 Hz までのイベントをレポートできなければなりません。
- [7.3.4/A-SR-3] 少なくとも周波数 10 Hz までのイベントをレポートすることが強く推奨されます。
- 真北を指すべきです。
- 車両が静止している間も利用できるべきです。
- 解像度が少なくとも 1 度であるべきです。
自動車デバイス実装は:
- [7.4.3/A-0-1] Bluetooth をサポートしなければならず、Bluetooth LE をサポートすべきです。
- [7.4.3/A-0-2] Android Automotive 実装は、次の Bluetooth プロファイルをサポートしなければなりません。
- Hands-Free Profile(HFP)での通話。
- Audio Distribution Profile(A2DP)でのメディア再生。
- Remote Control Profile(AVRCP)でのメディア再生コントロール。
- Phone Book Access Profile(PBAP)を使用した連絡先の共有。
[7.4.3/A-SR-1] Message Access Profile(MAP)をサポートすることが強く推奨されます。
[7.4.5/A] モバイル ネットワーク ベースのデータ接続のサポートを含むべきです。
[7.4.5/A] システムアプリで利用可能にすべきネットワークについて、システム API の
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
定数を使用しても構いません。
新しい要件の開始
AM/FM ブロードキャスト ラジオのサポートが含まれ、その機能を任意のアプリに公開する場合、デバイス実装は:
- [7.4
.10/A-0-1]FEATURE_BROADCAST_RADIO
のサポートを宣言しなければなりません。
新しい要件の終了
外部ビューカメラとは、リアビュー カメラのように、デバイス実装の外部の光景を撮影するカメラのことです。
自動車デバイス実装は:
- 1 つ以上の外部ビューカメラを含むべきです。
外部ビューカメラが含まれる場合、そのようなカメラについて、自動車デバイス実装は:
- [7.5/A-1-1] カメラのコア要件を遵守している場合を除き、Android Camera API を介して外部ビューカメラにアクセス可能であってはなりません。
[7.5/A-SR-1] カメラ プレビューを回転または水平にミラーリングしないことが強く推奨されます。
[7.5/A-SR-2] 解像度が少なくとも 1.3 メガピクセルであることが強く推奨されます。
固定焦点または EDOF(拡張被写界深度)のハードウェアがあるべきです。
ハードウェア オートフォーカス、またはカメラドライバに実装されたソフトウェア オートフォーカスを備えても構いません。
1 つ以上の外部ビューカメラが含まれ、外部ビューシステム(EVS)サービスを読み込む場合、自動車デバイス実装はそのようなカメラについて:
- [7.5/A-2-1] カメラ プレビューを回転または水平にミラーリングしてはなりません。
自動車デバイス実装は:
- サードパーティ アプリで利用できるカメラを 1 つ以上含んでも構いません。
自動車デバイス実装は、カメラを少なくとも 1 つ含み、それをサードパーティ アプリで利用できるようにしている場合:
- [7.5/A-3-1] 機能フラグ
android.hardware.camera.any
をレポートしなければなりません。 - [7.5/A-3-2] カメラをシステムカメラとして宣言してはなりません。
- セクション 7.5.3 に記載されている外部カメラをサポートしても構いません。
- セクション 7.5.1 に記載されているとおり、背面カメラで利用できる機能(オートフォーカスなど)を含めても構いません。
新しい要件の開始
背面カメラとは、車両の任意の場所に設置でき、車室の外側に向いているワールド フェイシング カメラのことです。つまり、リアビュー カメラのように車体の向こう側の光景を撮影するものです。
前面カメラとは、車両の任意の場所に設置でき、車室の内側に向いているユーザー向きカメラのことです。つまり、ビデオ会議や同様のアプリのようにユーザーを撮影するものです。
自動車デバイス実装は:
- [7.5/A-SR-1] 1 つ以上のワールド フェイシング カメラを含むことが強く推奨されます。
- ユーザー向きカメラを 1 つ以上含んでも構いません。
- [7.5/A-SR-2] 複数のカメラの同時ストリーミングをサポートすることが強く推奨されます。
ワールド フェイシング カメラが少なくとも 1 つ含まれる場合、当該のカメラについて、自動車デバイス実装は:
- [7.5/A-1-1] カメラの長辺が Android Automotive センサーの軸の XY 平面に沿うよう向きを合わせなければなりません。
- [7.5/A-SR-3] 固定焦点または EDOF(拡張被写界深度)のハードウェアを備えることが強く推奨されます。
- [7.5/A-1-2] プライマリ ワールド フェイシング カメラが、カメラ ID が最も低いワールド フェイシング カメラでなければなりません。
自動車デバイス実装にユーザー向きカメラが 1 つ以上含まれる場合、当該のカメラについて:
- [7.5/A-2-1] プライマリ ユーザー向きカメラは、カメラ ID が最も低いユーザー向きカメラでなければなりません。
- カメラの長辺が Android Automotive センサーの軸の XY 平面と一致するような向きであっても構いません。
android.hardware.Camera
API または android.hardware.camera2
API を介してアクセスできるカメラが含まれる場合、自動車デバイス実装は:
- [7.5/A-3-1] セクション 7.5 のカメラのコア要件を遵守しなければなりません。
android.hardware.Camera
API または android.hardware.camera2
API を介してアクセスできないカメラが含まれる場合、自動車デバイス実装は:
- [7.5/A-4-1] 拡張ビューシステム サービスを介してアクセスできなければなりません。
拡張ビューシステム サービスを介してアクセス可能なカメラが 1 つ以上含まれる場合、そのようなカメラについて、自動車デバイス実装は:
- [7.5/A-5-1] カメラ プレビューを回転または水平にミラーリングしてはなりません。
- [7.5/A-SR-4] 解像度が 1.3 メガピクセル以上であることが強く推奨されます。
拡張ビューシステム サービスと android.hardware.Camera
API または android.hardware.Camera2
API を介してアクセス可能なカメラが 1 つ以上含まれる場合、そのようなカメラについて、自動車デバイス実装は:
- [7.5/A-6-1] 同じカメラ ID をレポートしなければなりません。
独自のカメラ API を提供する場合、自動車デバイス実装は:
- [7.5/A-7-1] 当該のカメラ API を
android.hardware.camera2
API または拡張ビューシステム API を使用して実装しなければなりません。
新しい要件の終了
自動車デバイス実装は:
[7.6.1/A-0-1] アプリの個人データ(「/data」パーティション)に利用できる不揮発性ストレージが少なくとも 4 GB でなければなりません。
[7.6.1/A] たとえば
f2fs
ファイル システムを使用して、フラッシュ ストレージのパフォーマンスと寿命を改善するために、データ パーティションをフォーマットすべきです。
取り外し不可能な内部ストレージの一部を介して共有外部ストレージを提供する場合、自動車デバイス実装は:
- [7.6.1/A-SR-1] たとえば
SDCardFS
を使用して、外部ストレージで行われる操作の I/O オーバーヘッドを削減することが強く推奨されます。
自動車デバイス実装が 64 ビットの場合:
[7.6.1/A-2-1] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 816 MB でなければなりません。
- 小 / 標準画面で 280 dpi 以下
- 特大画面で ldpi 以下
- 大画面で mdpi 以下
[7.6.1/A-2-2] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 944 MB でなければなりません。
- 小 / 標準画面で xhdpi 以上
- 大画面で hdpi 以上
- 特大画面で mdpi 以上
[7.6.1/A-2-3] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 1,280 MB でなければなりません。
- 小 / 標準画面で 400 dpi 以上
- 大画面で xhdpi 以上
- 特大画面で tvdpi 以上
[7.6.1/A-2-4] 次のいずれかの密度を使用する場合、カーネルとユーザー空間に利用できるメモリが少なくとも 1,824 MB でなければなりません。
- 小 / 標準画面で 560 dpi 以上
- 大画面で 400 dpi 以上
- 特大画面で xhdpi 以上
なお、上記の「カーネルとユーザー空間に利用できるメモリ」とは、デバイス実装でカーネルの制御下にない、無線や動画などのハードウェア コンポーネント専用のメモリに加えて提供されるメモリ空間を指します。
自動車デバイス実装は:
- [7.7.1/A] ペリフェラル モードをサポートする USB ポートを含むべきです。
自動車デバイス実装は:
- [7.8.1/A-0-1] マイクを含まなければなりません。
自動車デバイス実装は:
- [7.8.2/A-0-1] オーディオ出力がなければならず、
android.hardware.audio.output
を宣言しなければなりません。
2.5.2. マルチメディア
自動車デバイス実装は、次の形式のオーディオ エンコードとデコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
- [5.1/A-0-1] MPEG-4 AAC プロファイル(AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC プロファイル(AAC+)
- [5.1/A-0-3] AAC ELD(Enhanced Low Delay AAC)
自動車デバイス実装は、次の形式の動画エンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
自動車デバイス実装は、次の形式の動画デコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
自動車デバイス実装は、次の動画デコードをサポートすることが強く推奨されます。
- [5.3/A-SR-1] H.265 HEVC
2.5.3. ソフトウェア
自動車デバイス実装は:
[3/A-0-1] 機能
android.hardware.type.automotive
を宣言しなければなりません。[3/A-0-2] uiMode =
UI_MODE_TYPE_CAR
をサポートしなければなりません。[3/A-0-3]
android.car.*
名前空間のすべての公開 API をサポートしなければなりません。
自動車デバイス実装が android.car.VehiclePropertyIds
で android.car.CarPropertyManager
を使用する独自の API を提供する場合:
- [3/A-1-1] システムアプリがこれらのプロパティを使用するための特別な権限を付与したり、サードパーティ アプリによるこれらのプロパティの使用を妨げたりしてはなりません。
- [3/A-1-2] すでに SDK に存在する車両プロパティをレプリケートしてはなりません。
自動車デバイス実装は:
[3.2.1/A-0-1] 自動車の権限に関するリファレンス ページに記載されているすべての権限定数をサポートし、適用しなければなりません。
[3.2.3.1/A-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
[3.4.1/A-0-1]
android.webkit.Webview
API の完全な実装を提供しなければなりません。
新しい要件の開始
- [3.8/A-0-1] 現在のフォアグラウンド ユーザーではないフルセカンダリ ユーザーによるアクティビティの起動と画面上の UI へのアクセスを許可してはなりません。
新しい要件の終了
[3.8.3/A-0-1] サードパーティ アプリがリクエストした場合、
Notification.CarExtender
API を使用する通知を表示しなければなりません。[3.8.4/A-SR-1] アシスト アクションを処理するために、デバイスにアシスタントを実装することが強く推奨されます。
プッシュツートーク ボタンが含まれる場合、自動車デバイス実装は:
- [3.8.4/A-1-1] ユーザー選択のアシストアプリ(
VoiceInteractionService
を実装するアプリ)を起動するための指定操作として、プッシュツートーク ボタンの短押しを使用しなければなりません。
自動車デバイス実装は:
- [3.8.3.1/A-0-1]
Notifications on Automotive OS
SDK ドキュメントに記載されているとおり、リソースを正しくレンダリングしなければなりません。 - [3.8.3.1/A-0-2]
Notification.Builder.addAction()
で提供されるものの代わりに、通知アクションの再生とミュートを表示しなければなりません。 - [3.8.3.1/A] 通知チャンネルごとのコントロールのような、リッチな管理タスクの使用を制限すべきです。コントロールを減らすためにアプリごとに UI アフォーダンスを使用しても構いません。
ユーザー HAL プロパティをサポートする場合、自動車デバイス実装は:
- [3.9.3/A-1-1] ユーザー ライフサイクルのプロパティをすべて実装しなければなりません。
INITIAL_USER_INFO
、SWITCH_USER
、CREATE_USER
、REMOVE_USER
。
自動車デバイス実装は:
- [3.14/A-0-1] セクション 3.14 に記載されているとおり、メディア API を使用するサードパーティ アプリをサポートするために UI フレームワークを含めなければなりません。
- [3.14/A-0-2] 運転中、ユーザーがメディアアプリを安全に操作できるようにしなければなりません。
- [3.14/A-0-3]
CAR_EXTRA_MEDIA_PACKAGE
エクストラで暗黙的インテントのアクションCAR_INTENT_ACTION_MEDIA_TEMPLATE
をサポートしなければなりません。 - [3.14/A-0-4] メディアアプリの設定アクティビティにナビゲートするアフォーダンスを提供しなければなりません。ただし自動車 UX 制限が有効でない場合にのみ、有効にしなければなりません。
- [3.14/A-0-5] メディアアプリによって設定されたエラー メッセージを表示しなければならず、オプションのエクストラ
ERROR_RESOLUTION_ACTION_LABEL
とERROR_RESOLUTION_ACTION_INTENT
をサポートしなければなりません。 - [3.14/A-0-6] 検索をサポートするアプリのためのアプリ内検索アフォーダンスをサポートしなければなりません。
- [3.14/A-0-7] MediaBrowser 階層を表示するとき、
CONTENT_STYLE_BROWSABLE_HINT
とCONTENT_STYLE_PLAYABLE_HINT
の定義を尊重しなければなりません。
デフォルトのランチャー アプリが含まれる場合、自動車デバイス実装は:
- [3.14/A-1-1] メディア サービスを含み、
CAR_INTENT_ACTION_MEDIA_TEMPLATE
インテントで開かなければなりません。
自動車デバイス実装は:
- [3.8/A]
immersive documentation
に記載されているように、全画面モードに入るアプリ リクエストを制限しても構いません。 - [3.8/A] ステータスバーとナビゲーション バーを常に表示し続けても構いません。
- [3.8/A] システム UI 要素の背後の色を変更するアプリ リクエストを制限して、それらの要素が常に明確に見えるようにしても構いません。
2.5.4. パフォーマンスと電力
自動車デバイス実装は:
- [8.2/A-0-1] デベロッパーがシステム API
android.car.storagemonitoring.CarStorageMonitoringManager
を通じて統計情報を利用できるよう、プロセスの UID ごとに、不揮発性ストレージに読み書きされたバイト数をレポートしなければなりません。Android オープンソース プロジェクトは、uid_sys_stats
カーネル モジュールを通じて要件を満たしています。 - [8.3/A-1-3] ガレージモードをサポートしなければなりません。
- [8.3/A] 次の場合を除き、毎回運転した後、少なくとも 15 分間はガレージモードになるべきです。
- バッテリーが消耗している。
- アイドルジョブがスケジュールされていない。
- 運転者がガレージモードを終了した。
- [8.4/A-0-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供しなければなりません。
- [8.4/A-0-2] すべての消費電力値をミリアンペア時(mAh)単位でレポートしなければなりません。
- [8.4/A-0-3] プロセスの UID ごとの CPU 消費電力をレポートしなければなりません。Android オープンソース プロジェクトは、
uid_cputime
カーネル モジュール実装を通じて要件を満たしています。 - [8.4/A] ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
- [8.4/A-0-4] この電力使用量を、
adb shell dumpsys batterystats
シェルコマンドを介してアプリ デベロッパーが利用できるようにしなければなりません。
2.5.5. セキュリティ モデル
複数ユーザーをサポートする場合、自動車デバイス実装は:
- [9.5/A-1-1] デバイスのプロビジョニングを除き、ヘッドレス システム ユーザーとのやり取りや切り替えをユーザーに許可してはなりません。
- [9.5/A-1-2]
BOOT_COMPLETED
より前にセカンダリ ユーザーに切り替えなければなりません。 - [9.5/A-1-3] デバイスの最大ユーザー数に達した場合でもゲストユーザーを作成する機能をサポートしなければなりません。
新しい要件の開始
android.hardware.microphone
を宣言する場合、自動車デバイス実装は:
- [9.8.2/A-1-1] アプリがマイクからオーディオ データにアクセスしているときはマイク インジケーターを表示しなければなりません。ただし、
HotwordDetectionService
、SOURCE_HOTWORD
、ContentCaptureService
、またはセクション 9.1 で CDD 識別子 [C-4-X] が割り当てられたロールを持つアプリからのみマイクにアクセスする場合は、この限りではありません。 - [9.8.2/A-1-2] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、マイク インジケーターを非表示にしてはなりません。
- [9.8.2/A-1-3] 設定アプリでマイクを切り替えるユーザー アフォーダンスを提供しなければなりません。
新しい要件の終了
android.hardware.camera.any
を宣言する場合、自動車デバイス実装は:
- [9.8.2/A-2-1] アプリがライブ カメラデータにアクセスしているときはカメラ インジケーターを表示しなければなりません。ただし、セクション 9.1 権限で CDD 識別子 [C-4-X]
[C-3-X]が割り当てられたで定義されたロールを持つアプリからのみカメラにアクセスする場合は、この限りではありません。 - [9.8.2/A-2-2] ユーザー インターフェースが表示されているか直接のユーザー操作があるシステムアプリについて、カメラ インジケーターを非表示にしてはなりません。
新しい要件の開始
- [9.8.2/A-2-3] 設定アプリでカメラの切り替えを行うユーザー アフォーダンスを提供しなければなりません。
- [9.8.2/A-2-4]
PermissionManager.getIndicatorAppOpUsageData()
から返された、カメラを使用している最近使ったアプリとアクティブなアプリを、関連する属性メッセージとともに表示しなければなりません。
新しい要件の終了
自動車デバイス実装は:
- [9/A-0-1]
android.hardware.security.model.compatible
機能を宣言しなければなりません。 - [9.11/A-0-1] 隔離された実行環境でキーストア実装をバックアップしなければなりません。
- [9.11/A-0-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト(AOSP)は、Trusty 実装を使用することでこの要件を満たしています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザベースの隔離オプションをセキュアに実装する方法を選択することもできます。
- [9.11/A-0-3] 隔離された実行環境でロック画面認証を行わなければならず、成功した場合にのみ、認証にバインドされた鍵の使用を許可しなければなりません。ロック画面の認証情報は、隔離された実行環境のみがロック画面認証を行えるように保存しなければなりません。アップストリームの Android オープンソース プロジェクトは、ゲートキーパー Hardware Abstraction Layer(HAL)と Trusty を提供しており、これを使用してこの要件を満たすことができます。
- [9.11/A-0-4] 証明書署名鍵がセキュア ハードウェアによって保護され、署名がセキュア ハードウェアで行われる鍵証明書をサポートしなければなりません。証明書署名鍵は、鍵がデバイス ID として使用されることを防ぐために、十分な数のデバイス間で共有しなければなりません。この要件を満たす方法としては、特定の SKU が少なくとも 100,000 ユニット生成されない限り、同じ証明書鍵を共有することが挙げられます。生成される SKU が 100,000 ユニットを超える場合は、100,000 ユニットごとに異なるキーを使用しても構いません。
なお、デバイス実装が以前のバージョンの Android ですでにリリースされている場合、そのようなデバイスは、隔離された実行環境で動作するキーストアが必要な android.hardware.fingerprint
機能を宣言する場合を除き、隔離された実行環境で動作するキーストアを持ち、鍵構成証明をサポートする必要があるという要件を免除されます。
自動車デバイス実装は:
- [9.14/A-0-1] Android フレームワークの車両サブシステムからのメッセージの送受信を管理しなければなりません(例: 許可されるメッセージ タイプとメッセージ ソースの許可リスト登録)。
- [9.14/A-0-2] Android フレームワークまたはサードパーティ アプリからのサービス拒否攻撃に対して、ウォッチドッグを設定しなければなりません。これにより、車両サブシステムの誤作動を招くおそれのある、悪意のあるソフトウェアが車両ネットワークにフラッディングを行うことを防ぎます。
2.5.6. デベロッパー ツール、開発者向けオプションの互換性
自動車デバイス実装は:
- Perfetto
- [6.1/A-0-1] cmdline が perfetto ドキュメントを遵守しているシェルユーザーに
/system/bin/perfetto
バイナリを公開しなければなりません。 - [6.1/A-0-2] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れなければなりません。
- [6.1/A-0-3] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込まなければなりません。
- [6.1/A-0-4] 少なくとも perfetto ドキュメントで規定されたデータソースを、perfetto バイナリを通じて提供しなければなりません。
- [6.1/A-0-1] cmdline が perfetto ドキュメントを遵守しているシェルユーザーに
2.6. タブレットの要件
Android タブレット デバイスとは一般に、次の基準をすべて満たす Android デバイス実装を指します。
- 両手で持って使用する。
- クラムシェルまたはコンバーチブル構成ではない。
- 標準的な接続(USB、Bluetooth など)によるデバイス接続で使用する物理キーボードの実装。
バッテリーなど、持ち運びを可能にする電源がある。
対角線で測定した画面ディスプレイ サイズが 7 インチより大きく 18 インチより小さい。
タブレット デバイス実装の要件は、ハンドヘルド デバイス実装と同様です。例外は、ハンドヘルド デバイスのセクションでは「*」で示されており、このセクションでは参考用に注記されています。
2.6.1. ハードウェア
ジャイロスコープ
3 軸ジャイロスコープが含まれる場合、タブレット デバイス実装は:
- [7.3.4/Tab-1-1] 1,000 度/秒までの方向変化を測定できなければなりません。
最小のメモリとストレージ(セクション 7.6.1)
ハンドヘルドの要件で小 / 標準画面についてリストされている画面密度は、タブレットには適用されません。
USB ペリフェラル モード(セクション 7.7.1)
ペリフェラル モードをサポートする USB ポートが含まれる場合、タブレット デバイス実装は:
- [7.7.1/Tab] Android Open Accessory(AOA)API を実装しても構いません。
バーチャル リアリティ モード(セクション 7.9.1)
バーチャル リアリティ ハイ パフォーマンス(セクション 7.9.2)
バーチャル リアリティ要件はタブレットには適用されません。
2.6.2. セキュリティ モデル
鍵と認証情報(セクション 9.11)
セクション [9.11] をご覧ください。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言しない場合、デバイス実装は:
- [9.5/T-1-1] 制限付きプロファイル(追加のユーザーと、そのユーザーがデバイス上でできることを、デバイス所有者が管理できるようにする機能)をサポートしなければなりません。制限付きプロファイルにより、デバイス所有者は、追加のユーザーが使用する個別の環境をすばやく設定でき、その環境で利用できるアプリの制限をきめ細かく管理できます。
複数のユーザーが含まれ、android.hardware.telephony
機能フラグを宣言する場合、タブレット デバイス実装は:
- [9.5/T-2-1] 制限付きプロファイルをサポートしてはなりませんが、他のユーザーによる音声通話と SMS へのアクセスを可能 / 不可能にするコントロールの AOSP 実装に合わせなければなりません。
2.6.2. ソフトウェア
- [3.2.3.1/Tab-0-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードしなければなりません。
3.ソフトウェア
3.1. マネージド API の互換性
Dalvik バイトコードによるマネージド実行環境は、Android アプリを実行する際の主要手段です。Android アプリケーション プログラミング インターフェース(API)は、マネージド ランタイム環境で動作するアプリに公開される Andoid プラットフォーム インターフェースのセットです。
デバイス実装は:
[C-0-1] Android SDK で公開されているドキュメント化された API、またはアップストリームの Android ソースコードにおいて @SystemApi マーカーで装飾されている API について、すべてのドキュメント化された動作も含めて、完全な実装を提供しなければなりません。
[C-0-2] TestApi アノテーション(@TestApi)でマークされたすべてのクラス、メソッド、関連要素をサポート / 維持しなければなりません。
[C-0-3] この互換性定義で特に許可されている場合を除き、マネージド API の省略、API インターフェースまたは署名の変更、ドキュメント化された動作からの逸脱、NoOps の対象とすることを行ってはなりません。
[C-0-4] Android に含まれている API のハードウェア機能のいくつかが省略されている場合でも、API を維持し、妥当な方法で動作させなければなりません。このシナリオに固有の要件については、セクション 7 をご覧ください。
[C-0-5] AOSP のブート クラスパスにあり、公開 SDK の一部を形成するわけではない、Java 言語パッケージのメソッドとフィールドとして定義される非 SDK インターフェースを、サードパーティ アプリが使用できるようにしてはなりません。これには、private と package-private のクラスメンバーや、SDK ドキュメントに記載されているとおり、
@SystemAPI
ではなく@hide
アノテーションで装飾されている API が含まれます。[C-0-6] すべての非 SDK インターフェースが、AOSP の該当する API レベルブランチの
prebuilts/runtime/appcompat/hiddenapi-flags.csv
パスにある provisional フラグと denylist フラグで提供されるものと同じ制限リストに含まれていなければなりません。[C-0-7] AOSP にある既存の公開鍵を使用して、署名設定を APK に埋め込むことにより、非 SDK インターフェースを制限リストから削除できるように、署名設定の動的更新メカニズムをサポートしなければなりません。
ただし:
- デバイス実装で非表示 API が存在しないか異なる方法で実装されている場合は、非表示 API を拒否リストに移動するか、すべての制限リストから除外しても構いません。
- AOSP に非表示 API がまだ存在していない場合は、非表示 API を制限リストに追加しても構いません。
新しい要件の開始
- [C-0-8] API レベル 23 未満をターゲットとするアプリのインストールをサポートしてはなりません。
新しい要件の終了
3.1.1. Android 拡張機能
Android は、特定の API レベルの拡張機能バージョンを更新することで、その API レベルのマネージド API サーフェスの拡張をサポートします。android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API は、指定された API レベルの拡張機能がある場合、その apiLevel
の拡張機能バージョンを返します。
Android デバイス実装は:
[C-0-1] 共有ライブラリ
ExtShared
とサービスExtServices
の両方の AOSP 実装を、API レベルごとに許可された最小バージョン以上のバージョンでプリロードしなければなりません。たとえば、API レベル 24 を搭載した Android 7.0 デバイス実装の場合、少なくともバージョン 1 を含まなければなりません。[C-0-2] AOSP で定義された有効な拡張機能バージョン番号のみを返さなければなりません。
[C-0-3] 他のマネージド API のサポートと同様に、セクション 3.1 の要件に従い、
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
が返す拡張機能バージョンで定義されるすべての API をサポートしなければなりません。
3.1.2. Android ライブラリ
Apache HTTP クライアントのサポート終了により、デバイス実装は:
- [C-0-1]
org.apache.http.legacy
ライブラリをブート クラスパスに配置してはなりません。 - [C-0-2] アプリが次のいずれかの条件を満たす場合にのみ、
org.apache.http.legacy
ライブラリをアプリ クラスパスに追加しなければなりません。- API レベル 28 以前をターゲットとする。
<uses-library>
のandroid:name
属性をorg.apache.http.legacy
に設定することで、ライブラリが必要であることをマニフェストで宣言する。
AOSP 実装はこれらの要件を満たしています。
3.2. ソフト API の互換性
セクション 3.1 のマネージド API に加えて、Android には、アプリのコンパイル時には適用できない、Android アプリのインテントや権限などの形式で、重要なランタイム専用の「ソフト」API も含まれています。
3.2.1. 権限
- [C-0-1] デバイス実装者は、権限に関するリファレンス ページに記載されているすべての権限定数をサポートし、適用しなければなりません。なお、セクション 9 に、Android セキュリティ モデルに関連する追加の要件を記載しています。
3.2.2. ビルド パラメータ
Android API には、現在のデバイスを記述するための android.os.Build クラスの定数がいくつか含まれています。
- [C-0-1] デバイス実装間で一貫した意味のある値を提供するために、デバイス実装が従わなければならない、これらの値の形式に関する追加の制限を下表に示します。
パラメータ | 詳細 |
---|---|
VERSION.RELEASE | 現在実行している Android システムのバージョン(人が読める形式)。このフィールドには、Android 14 で使用できるバージョン文字列で定義された文字列値のいずれかを指定しなければなりません。 |
VERSION.SDK | 現在実行している Android システムのバージョン(サードパーティ アプリコードからアクセスできる形式)。Android 14 の場合、このフィールドには整数値 14_INT を指定しなければなりません。 |
VERSION.SDK_INT | 現在実行している Android システムのバージョン(サードパーティ アプリコードからアクセスできる形式)。Android 14 の場合、このフィールドには整数値 14_INT を指定しなければなりません。 |
VERSION.INCREMENTAL | 現在実行している Android システムの特定のビルドを指定する、デバイス実装者が選択した値(人が読める形式)。この値は、エンドユーザーが利用できる別のビルドに再利用してはなりません。このフィールドは主に、ビルドの生成に使用されたビルド番号またはソース管理変更 ID を示すために使用します。このフィールドの値は、印刷用の 7 ビット ASCII としてエンコード可能であって、正規表現「^[^ :\/~]+$」に一致しなければなりません。 |
BOARD | デバイスで使用される特定の内部ハードウェアを識別する、デバイス実装者が選択した値(人が読める形式)。このフィールドは、デバイスに電力を供給するボードの特定のリビジョンを示すために使用できます。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。 |
BRAND | エンドユーザーが知っているデバイスに関連付けられたブランド名を反映する値。人が読める形式でなければならず、デバイスのメーカーまたはデバイスを販売する会社のブランドを表すべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。 |
SUPPORTED_ABIS | ネイティブ コードの命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。 |
SUPPORTED_32_BIT_ABIS | ネイティブ コードの命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。 |
SUPPORTED_64_BIT_ABIS | ネイティブ コードの 2 番目の命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。 |
CPU_ABI | ネイティブ コードの命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。 |
CPU_ABI2 | ネイティブ コードの 2 番目の命令セット(CPU タイプ + ABI 規則)の名前。セクション 3.3 ネイティブ API の互換性をご覧ください。 |
DEVICE | ハードウェア機能の構成とデバイスの工業デザインを識別する開発名またはコードネームを含む、デバイス実装者が選択した値。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。このデバイス名は、製品の全期間にわたって変更してはなりません。 |
FINGERPRINT | このビルドを一意に識別する文字列。人が読める程度の形式にすべきです。次のテンプレートに従わなければなりません。
$(BRAND)/$(PRODUCT)/ 例: acme/myproduct/ フィンガープリントには空白文字を含んではなりません。このフィールドの値は 7 ビット ASCII としてエンコード可能でなければなりません。 |
HARDWARE | ハードウェアの名前(カーネル コマンドラインまたは /proc から)。人が読める程度の形式にすべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。 |
HOST | ビルドが構築されたホストを一意に識別する文字列(人が読める形式)。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。 |
ID | 特定のリリースを参照するためにデバイス実装者が選択する識別子(人が読める形式)。このフィールドは android.os.Build.VERSION.INCREMENTAL と同じ内容にできますが、エンドユーザーがソフトウェア ビルドを区別できるような意味のある値にすべきです。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+$」に一致しなければなりません。 |
MANUFACTURER | 製品の相手先ブランド製品製造企業(OEM)の商号。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。 |
SOC_MANUFACTURER | 製品で使用しているプライマリ システム オン チップ(SOC)のメーカー名。SOC メーカーが同じデバイスでは、同じ定数値を使用すべきです。使用する正しい定数については、SOC メーカーにお問い合わせください。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^([0-9A-Za-z ]+)」に一致しなければなりません。また、空白文字で開始または終了してはならず、「unknown」であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。 |
SOC_MODEL | 製品で使用しているプライマリ システム オン チップ(SOC)のモデル名。SOC モデルが同じデバイスでは、同じ定数値を使用すべきです。使用する正しい定数については、SOC メーカーにお問い合わせください。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^([0-9A-Za-z ._/+-]+)$」に一致しなければなりません。また、空白文字で開始または終了してはならず、「unknown」であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。 |
MODEL | エンドユーザーが知っているデバイスの名前を含む、デバイス実装者が選択した値。これは、デバイスが市販されエンドユーザーに販売される際の名前と同じにすべきです。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。このフィールドは、製品の全期間にわたって変更してはなりません。 |
PRODUCT | 特定の製品(SKU)の開発名またはコードネームを含む、デバイス実装者が選択した値。同じブランド内で一意でなければなりません。人が読める形式でなければなりませんが、必ずしもエンドユーザーに表示することを意図したものではありません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9_-]+$」に一致しなければなりません。この製品名は、製品の全期間にわたって変更してはなりません。 |
ODM_SKU | デバイスの特定の構成(販売時にデバイスに付属する周辺機器など)を追跡するために使用される SKU(最小管理単位)を含む、デバイス実装者が選択した任意の値。このフィールドの値は、7 ビット ASCII としてエンコード可能でなければならず、かつ正規表現 ^([0-9A-Za-z.,_-]+)$ と一致しなければなりません。 |
SERIAL | 「UNKNOWN」を返さなければなりません。 |
TAGS | ビルドをさらに区別する、デバイス実装者が選択したタグのカンマ区切りのリスト。タグは、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+」に一致しなければなりません。また、典型的な 3 つの Android プラットフォーム署名設定(release-keys、dev-keys、test-keys)に対応する値のいずれかを持たなければなりません。 |
TIME | ビルドが作成されたときのタイムスタンプを表す値。 |
TYPE | ビルドのランタイム構成を指定する、デバイス実装者が選択した値。このフィールドには、典型的な 3 つの Android ランタイム構成(user、userdebug、eng)に対応する値のいずれかを指定しなければなりません。 |
USER | ビルドを生成したユーザー(または自動ユーザー)の名前またはユーザー ID。このフィールドの具体的な形式についての要件はありませんが、null または空の文字列("")であってはなりません。 |
SECURITY_PATCH | ビルドのセキュリティ パッチレベルを示す値。指定の Android のセキュリティに関する公開情報で説明されている問題に対して、ビルドがいかなる脆弱性も持たないことを示さなければなりません。「2015-11-01」など、Android のセキュリティに関する公開情報または Android セキュリティ アドバイザリに記載されている定義文字列と一致する、[YYYY-MM-DD] の形式でなければなりません。 |
BASE_OS | ビルドの FINGERPRINT パラメータを表す値。Android のセキュリティに関する公開情報で提供されているパッチを除き、このビルドと同一です。正しい値をレポートしなければならず、そのようなビルドが存在しない場合は空の文字列("")をレポートしなければなりません。 |
BOOTLOADER | デバイスで使用される特定の内部ブートローダー バージョンを識別する、デバイス実装者が選択した値(人が読める形式)。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-]+$」に一致しなければなりません。 |
getRadioVersion() | デバイスで使用されている特定の内部無線 / モデム バージョンを識別する、デバイス実装者が選択した値(人が読める形式)でなければなりません。または、そのような値を返さなければなりません。デバイスに内部無線 / モデムがない場合は、NULL を返さなければなりません。このフィールドの値は、7 ビット ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9._-,]+$」に一致しなければなりません。 |
getSerial() | ハードウェア シリアル番号でなければなりません。または、ハードウェア シリアル番号を返さなければなりません。ハードウェア シリアル番号は、MODEL と MANUFACTURER が同じデバイス間で利用可能かつ一意でなければなりません。このフィールドの値は、7 ビットの ASCII としてエンコード可能であって、正規表現「^[a-zA-Z0-9]+$」に一致しなければなりません。 |
3.2.3. インテントの互換性
3.2.3.1. 一般的なアプリ インテント
Android インテントによって、アプリ コンポーネントは他の Android コンポーネントの機能をリクエストできます。Android のアップストリーム プロジェクトには、一般的なアクションを行うために複数のインテント パターンを実装するアプリのリストが含まれています。
デバイス実装は:
- [C-SR-1] こちらに記載されているアプリ インテントで定義されるすべてのパブリック インテント フィルタ パターンについて、インテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードし、フルフィルメントを提供する(SDK に記載されているこれら一般的なアプリ インテントに対するデベロッパーの期待に応える)ことが強く推奨されます。
デバイスタイプごとの必須のアプリ インテントについては、セクション 2 をご覧ください。
3.2.3.2. インテントの解決
[C-0-1] Android は拡張可能なプラットフォームであるため、デバイス実装は、セクション 3.2.3.1 で参照されている各インテント パターンをサードパーティ アプリでオーバーライドできるようにしなければなりません。アップストリームの Android オープンソース実装では、デフォルトでこれを行えます。
[C-0-2] デバイス実装者は、システムアプリがこれらのインテント パターンを使用することに対し特別な権限を付与したり、サードパーティ アプリがこれらのパターンにバインドして制御を引き受けることを妨げたりしてはなりません。同じインテント パターンを処理する複数のアプリ間でユーザーの選択を可能にする「選択用」ユーザー インターフェースを無効にすることなどが特に禁じられます。
[C-0-3] デバイス実装は、ユーザーに対し、インテントのデフォルト アクティビティを変更するユーザー インターフェースを提供しなければなりません。
ただし、デバイス実装は、デフォルト アクティビティがより具体的な属性を提供する場合、具体的な URI パターン(例: http://play.google.com)用のデフォルト アクティビティを提供しても構いません。たとえば、データ URI「http://www.android.com」を指定するインテント フィルタ パターンは、「http://」に対するブラウザのコアインテント パターンよりも具体的です。
Android には、特定のウェブ URI インテントに対してサードパーティ アプリが正式なデフォルトのアプリリンク動作を宣言するメカニズムも含まれています。このような正式な宣言がアプリのインテント フィルタ パターンで定義されている場合、デバイス実装は:
- [C-0-4] アップストリームの Android オープンソース プロジェクトのパッケージ マネージャーで実装される、デジタル アセット リンク仕様で規定されている検証手順を実施することで、インテント フィルタの検証を試行しなければなりません。
- [C-0-5] アプリのインストール中にインテント フィルタの検証を試行し、検証に合格したすべての URI インテント フィルタを、その URI のデフォルト アプリハンドラとして設定しなければなりません。
- 検証に合格したが、他の URI フィルタ候補が検証に不合格となった場合、具体的な URI インテント フィルタを URI のデフォルト アプリハンドラとして設定しても構いません。デバイス実装でこれを行う場合、設定メニューで、URI ごとの適切なパターン オーバーライドをユーザーに提供しなければなりません。
- 次のように、設定でアプリごとのアプリリンク コントロールをユーザーに提供しなければなりません。
- [C-0-6] ユーザーは、すべての URI インテント フィルタ候補に等しく適用しなければならない、デフォルトのアプリリンク動作(アプリを常に開く、常に確認する、開かない)を全体的にオーバーライドできなければなりません。
- [C-0-7] ユーザーに、URI インテント フィルタ候補のリストが表示されなければなりません。
- デバイス実装は、インテント フィルタごとに、検証に合格した具体的な URI インテント フィルタ候補をオーバーライドする機能をユーザーに提供しても構いません。
- [C-0-8] デバイス実装で、ある URI インテント フィルタ候補が検証に合格し、他の候補が不合格になる可能性がある場合、デバイス実装は、特定の URI インテント フィルタ候補を表示しオーバーライドする機能をユーザーに提供しなければなりません。
3.2.3.3. インテントの名前空間
- [C-0-1] デバイス実装は、android.* 名前空間または com.android.* 名前空間に、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャスト インテント パターンを使用する Android コンポーネントを含んではなりません。
- [C-0-2] デバイス実装者は、別の組織に属するパッケージ スペースに、ACTION、CATEGORY、または他のキー文字列を使用して、新しいインテントまたはブロードキャスト インテント パターンを使用する Android コンポーネントを含めてはなりません。
- [C-0-3] デバイス実装者は、セクション 3.2.3.1 に記載されているインテント パターンのいずれも変更または拡張してはなりません。
- デバイス実装は、組織に明確に関連付けられた名前空間を使用するインテント パターンを含んでも構いません。セクション 3.6 の Java 言語クラスに指定された制約と同様のものです。
3.2.3.4. ブロードキャスト インテント
サードパーティ アプリは、特定のインテントをブロードキャストしてハードウェアまたはソフトウェア環境の変更を通知する際、プラットフォームに依存します。
デバイス実装は:
- [C-0-1] SDK ドキュメントに記載されているとおり、該当するシステム イベントに応じて、こちらに記載されているパブリック ブロードキャスト インテントをブロードキャストしなければなりません。なお、バックグラウンド アプリの制限も SDK ドキュメントに記載されているため、この要件はセクション 3.5 と競合しません。また、特定のブロードキャスト インテントはハードウェアのサポートを条件としており、必要なハードウェアをサポートしている場合、デバイスはインテントをブロードキャストし、SDK ドキュメントに沿った動作を提供しなければなりません。
3.2.3.5. 条件付きアプリ インテント
Android には、ホーム画面や SMS などのデフォルト アプリをユーザーが簡単に選択できるようにする設定があります。
そのような状態が合理的な場合、デバイス実装は、同様の設定メニューを提供しなければならず、SDK ドキュメントに記載されているインテント フィルタ パターンや API メソッドと下記のように互換性がなければなりません。
android.software.home_screen
をレポートする場合、デバイス実装は:
- [C-1-1]
android.settings.HOME_SETTINGS
インテントを使用して、ホーム画面用のデフォルトのアプリ設定メニューを表示しなければなりません。
android.hardware.telephony.calling
をレポートする場合、デバイス実装は:
[C-2-1]
android.provider.Telephony.ACTION_CHANGE_DEFAULT
インテントを呼び出す設定メニューを提供して、デフォルトの SMS アプリを変更するダイアログを表示しなければなりません。[C-2-2]
android.telecom.action.CHANGE_DEFAULT_DIALER
インテントを使用して、デフォルトの電話アプリをユーザーが変更できるダイアログを表示しなければなりません。- プリインストールの電話アプリを使用する緊急通報を除き、着信と発信には、ユーザーが選択したデフォルトの電話アプリの UI を使用しなければなりません。
[C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS インテントを使用して、
PhoneAccounts
に関連付けられたConnectionServices
と、通信サービス プロバイダが発信を行うために使用するデフォルトの PhoneAccount を構成するユーザー アフォーダンスを提供しなければなりません。AOSP 実装は、「通話」設定メニュー内に「通話アカウント オプション」メニューを含めることで、この要件を満たしています。[C-2-4]
android.app.role.CALL_REDIRECTION
ロールを保持するアプリにandroid.telecom.CallRedirectionService
を許可しなければなりません。[C-2-5]
android.app.role.CALL_REDIRECTION
ロールを保持するアプリを選択するユーザー アフォーダンスを提供しなければなりません。[C-2-6] android.intent.action.SENDTO インテントと android.intent.action.VIEW インテントを使用し、SMS メッセージを送信 / 表示するアクティビティを提供しなければなりません。
[C-SR-1] SDK に記載されているとおり、インテント android.intent.action.ANSWER、android.intent.action.CALL、android.intent.action.CALL_BUTTON、android.intent.action.VIEW、android.intent.action.DIAL を処理でき、フルフィルメントを提供できる、プリロードされた電話アプリでこれらのインテントを使用することが強く推奨されます。
android.hardware.nfc.hce
をレポートする場合、デバイス実装は:
- [C-3-1] android.settings.NFC_PAYMENT_SETTINGS インテントを使用して、非接触型決済用のデフォルトのアプリ設定メニューを表示しなければなりません。
- [C-3-2] SDK に記載されているとおり、android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT インテントを使用して、特定カテゴリのデフォルトのカード エミュレーション サービスの変更についてユーザーに確認するダイアログを開くアクティビティを表示しなければなりません。
android.hardware.nfc
をレポートする場合、デバイス実装は:
- [C-4-1] SDK に記載されているとおり、インテント android.nfc.action.NDEF_DISCOVERED、android.nfc.action.TAG_DISCOVERED、android.nfc.action.TECH_DISCOVERED を使用して、これらのインテントに対するデベロッパーの期待を満たすアクティビティを表示しなければなりません。
android.hardware.bluetooth
をレポートする場合、デバイス実装は:
- [C-5-1] android.bluetooth.adapter.action.REQUEST_ENABLE インテントを使用し、ユーザーが Bluetooth をオンにできるシステム アクティビティを表示しなければなりません。
- [C-5-2] android.bluetooth.adapter.action.REQUEST_DISCOVERABLE インテントを使用し、検出可能なモードをリクエストするシステム アクティビティを表示しなければなりません。
DND 機能をサポートする場合、デバイス実装は:
- [C-6-1] インテント
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
に応答するアクティビティを実装しなければなりません。UI_MODE_TYPE_NORMAL での実装の場合、これは DND ポリシー構成へのアプリアクセスをユーザーが許可または拒否できるアクティビティでなければなりません。
ユーザーがデバイスでサードパーティの入力方法を使用できるようにする場合、デバイス実装は:
- [C-7-1]
android.settings.INPUT_METHOD_SETTINGS
インテントに応じてサードパーティの入力方法を追加、構成する、ユーザーがアクセス可能なメカニズムを提供しなければなりません。
サードパーティのユーザー補助サービスをサポートする場合、デバイス実装は:
- [C-8-1]
android.settings.ACCESSIBILITY_SETTINGS
インテントを使用して、プリロードされたユーザー補助サービスとともにサードパーティのユーザー補助サービスの有効化と無効化を行う、ユーザーがアクセス可能なメカニズムを提供しなければなりません。
Wi-Fi Easy Connect のサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-9-1] SDK ドキュメントに記載されているとおり、Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI インテント API を実装しなければなりません。
データセーバー モードを提供する場合、デバイス実装は:
- [C-10-1] 設定に、
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
インテントを処理するユーザー インターフェースを提供し、ユーザーがアプリを許可リストに追加したり、許可リストから削除したりできるようにしなければなりません。
データセーバー モードを提供しない場合、デバイス実装は:
- [C-11-1]
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
インテントを処理するアクティビティを持たなければなりませんが、NoOps として実装しても構いません。
android.hardware.camera.any
を介してカメラのサポートを宣言する場合、デバイス実装は:
- [C-12-3] SDK ドキュメントに記載されているとおり、インテント
MediaStore.ACTION_IMAGE_CAPTURE
、MediaStore.ACTION_IMAGE_CAPTURE_SECURE
、MediaStore.ACTION_VIDEO_CAPTURE
を処理し、プリインストールの Android アプリのみでこれらのインテントを処理できるようにしなければなりません。
android.software.device_admin
をレポートする場合、デバイス実装は:
[C-13-1] インテント
android.app.action.ADD_DEVICE_ADMIN
を使用して、ユーザーがデバイス管理者をシステムに追加する(または拒否する)UI を呼び出さなければなりません。[C-13-2] こちらの SDK に記載されているとおり、インテント android.app.action.PROVISION_MANAGED_PROFILE、android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD、android.app.action.SET_NEW_PASSWORD、android.app.action.START_ENCRYPTION を使用し、これらのインテントに対するフルフィルメントを提供するアクティビティを持たなければなりません。
android.software.autofill
機能フラグを宣言する場合、デバイス実装は:
- [C-14-1]
AutofillService
API とAutofillManager
API を完全に実装し、android.settings.REQUEST_SET_AUTOFILL_SERVICE インテントを使用して、自動入力の有効化 / 無効化とデフォルトの自動入力サービスの変更を行う、デフォルトのアプリ設定メニューをユーザーに表示しなければなりません。
プリインストール アプリが含まれるか、サードパーティ アプリによる使用統計情報へのアクセスを許可する場合、デバイス実装は:
- [C-SR-2]
android.permission.PACKAGE_USAGE_STATS
権限を宣言するアプリに対する android.settings.ACTION_USAGE_ACCESS_SETTINGS インテントに応じて、使用統計情報へのアクセス権を付与または取り消す、ユーザーがアクセス可能なメカニズムを提供することが強く推奨されます。
プリインストール アプリを含め、いかなるアプリに対しても使用統計情報へのアクセスを許可しないことを意図する場合、デバイス実装は:
- [C-15-1] 引き続き android.settings.ACTION_USAGE_ACCESS_SETTINGS インテント パターンを処理するアクティビティを持たなければなりませんが、ユーザーがアクセスを拒否されたときと同等の動作をするように NoOps として実装しなければなりません。
設定内の AutofillService_passwordsActivity で指定されたアクティビティへのリンク、または同様のメカニズムを通じてユーザー パスワードへのリンクを表示する場合、デバイス実装は:
- [C-16-1] インストール済みのすべての自動入力サービスについて、そのようなリンクを表示しなければなりません。
VoiceInteractionService
をサポートし、この API を使用する複数のアプリが同時にインストールされている場合、デバイス実装は:
- [C-18-1]
android.settings.ACTION_VOICE_INPUT_SETTINGS
インテントを使用して、音声入力とアシスト用のデフォルトのアプリ設定メニューを表示しなければなりません。
機能 android.hardware.audio.output
をレポートする場合、デバイス実装は:
- [C-SR-3] こちらの SDK に記載されているとおり、インテント android.intent.action.TTS_SERVICE、android.speech.tts.engine.INSTALL_TTS_DATA、android.speech.tts.engine.GET_SAMPLE_TEXT を使用し、これらのインテントに対するフルフィルメントを提供するアクティビティを持つことが強く推奨されます。
Android は、以前は Dreams と呼ばれていた、インタラクティブ スクリーンセーバーをサポートしています。スクリーン セーバーを使用すると、電源に接続されているデバイスがアイドル状態のとき、または卓上ホルダーにドッキングされているとき、ユーザーがアプリを操作できます。デバイス実装は:
- スクリーン セーバーのサポートを含み、
android.settings.DREAM_SETTINGS
インテントに応じてユーザーがスクリーン セーバーを構成できる設定オプションを提供すべきです。
新しい要件の開始
android.hardware.nfc.uicc
または android.hardware.nfc.ese
をレポートする場合、デバイス実装は:
- [C-19-1] NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API を(GSM Association 技術仕様 TS.26 - NFC Handset Requirements で定義されている "EVT_TRANSACTION" として)実装しなければなりません。
新しい要件の終了
3.2.4. セカンダリ / 複数ディスプレイでのアクティビティ
複数のディスプレイで通常の Android アクティビティを起動できるようにする場合、デバイス実装は:
- [C-1-1]
android.software.activities_on_secondary_displays
機能フラグを設定しなければなりません。 - [C-1-2] プライマリ ディスプレイで動作するアクティビティと同様の API 互換性を保証しなければなりません。
- [C-1-3]
ActivityOptions.setLaunchDisplayId()
API を介してターゲット ディスプレイを指定せずに新しいアクティビティが起動された場合、新しいアクティビティを起動したアクティビティと同じディスプレイに、新しいアクティビティを配置しなければなりません。 - [C-1-4]
Display.FLAG_PRIVATE
フラグを指定したディスプレイが取り外された場合、すべてのアクティビティを破棄しなければなりません。 - [C-1-5] アプリが
Activity#setShowWhenLocked()
API を使用してロック画面上に表示されるようにオプトインしない限り、デバイスがセキュアロック画面でロックされている場合、すべての画面のコンテンツを安全に非表示にしなければなりません。 - セカンダリ ディスプレイでアクティビティが起動された場合に、表示、正しい動作、互換性が維持されるように、そのディスプレイに対応する
android.content.res.Configuration
を持つべきです。
セカンダリ ディスプレイで通常の Android アクティビティが起動できるようになっており、android.view.Display.FLAG_PRIVATE フラグが指定されている場合、デバイス実装は:
- [C-3-1] そのディスプレイ、システム、そのディスプレイ上にすでにあるアクティビティの所有者のみが、起動できなければなりません。android.view.Display.FLAG_PUBLIC フラグが指定されているディスプレイは、誰でも起動できます。
3.3. ネイティブ API の互換性
ネイティブ コードの互換性は難しい問題です。そのため、デバイス実装者は:
- [C-SR-1] アップストリームの Android オープンソース プロジェクトから、下記のライブラリの実装を使用することが強く推奨されます。
3.3.1. アプリケーション バイナリ インターフェース
Dalvik バイトコードによるマネージド実行環境では、アプリの .apk
ファイルで提供されるネイティブ コードを、該当するデバイス ハードウェア アーキテクチャ向けにコンパイルされた ELF .so
ファイルとして呼び出すことができます。ネイティブ コードは基となるプロセッサ技術に大きく依存するため、Android では、Android NDK に多数のアプリケーション バイナリ インターフェース(ABI)が定義されています。
デバイス実装は:
- [C-0-1] 1 つ以上の定義済み Android NDK ABI と互換性がなければなりません。
- [C-0-2] 標準の Java Native Interface(JNI)セマンティクスを使用して、ネイティブ コードを呼び出すためにマネージド環境で動作するコードのサポートを含まなければなりません。
- [C-0-3] 下記のリストにある各必須ライブラリと、ソース互換(すなわちヘッダー互換)かつバイナリ互換(ABI 向け)でなければなりません。
- [C-0-5]
android.os.Build.SUPPORTED_ABIS
、android.os.Build.SUPPORTED_32_BIT_ABIS
、android.os.Build.SUPPORTED_64_BIT_ABIS
のパラメータ(優先度の高い順にカンマ区切りになっている ABI のリスト)を介して、デバイスがサポートするネイティブ アプリケーション バイナリ インターフェース(ABI)を正確にレポートしなければなりません。 [C-0-6] 上記のパラメータを介して、次の ABI リストのサブセットをレポートしなければならず、リストにない ABI はレポートしてはなりません。
armeabi
(NDK にターゲットとしてサポートされなくなりました)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] ネイティブ API を提供する次のすべてのライブラリを、ネイティブ コードを含むアプリで利用できるようにしなければなりません。
- libaaudio.so(AAudio ネイティブ オーディオ サポート)
- libamidi.so(ネイティブ MIDI サポート、機能
android.software.midi
がセクション 5.9 の記載のとおりである場合) - libandroid.so(ネイティブ Android アクティビティ サポート)
- libc(C ライブラリ)
- libcamera2ndk.so
- libdl(ダイナミック リンカー)
- libEGL.so(ネイティブ OpenGL サーフェス管理)
- libGLESv1_CM.so(OpenGL ES 1.x)
- libGLESv2.so(OpenGL ES 2.0)
- libGLESv3.so(OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog(Android ロギング)
- libmediandk.so(ネイティブ メディア API サポート)
- libm(math ライブラリ)
- libneuralnetworks.so(Neural Networks API)
- libOpenMAXAL.so(OpenMAX AL 1.0.1 サポート)
- libOpenSLES.so(OpenSL ES 1.0.1 オーディオ サポート)
- libRS.so
- libstdc++(C++ の最小限のサポート)
- libvulkan.so(Vulkan)
- libz(Zlib 圧縮)
- JNI インターフェース
[C-0-8] 上のネイティブ ライブラリのパブリック関数を追加または削除してはなりません。
[C-0-9]
/vendor/etc/public.libraries.txt
でサードパーティ アプリに直接公開される AOSP 以外の追加のライブラリをリストしなければなりません。[C-0-10] AOSP でシステム ライブラリとして実装され提供される他のネイティブ ライブラリを、API レベル 24 以降をターゲットとするサードパーティ アプリに公開してはなりません(予約されているため)。
[C-0-11] NDK で定義されているとおり、すべての OpenGL ES 3.1 と Android 拡張機能パックの関数シンボルを、
libGLESv3.so
ライブラリを介してエクスポートしなければなりません。なお、すべてのシンボルが存在しなければなりませんが、対応する関数それぞれの完全な実装が期待される場合の要件については、セクション 7.1.4.1 に詳しく記載しています。[C-0-12]
libvulkan.so
ライブラリを通じて、主なVulkan 1.0Vulkan 1.1 関数シンボルと拡張機能VK_KHR_surface
、VK_KHR_android_surface
、VK_KHR_swapchain
、VK_KHR_maintenance1
、VK_KHR_get_physical_device_properties2
の関数シンボルをエクスポートしなければなりません。なお、すべてのシンボルが存在しなければなりませんが、対応する関数それぞれの完全な実装が期待される場合の要件については、セクション 7.1.4.2 に詳しく記載しています。アップストリームの Android オープンソース プロジェクトで入手可能なソースコードとヘッダー ファイルを使用してビルドすべきです。
なお、Android の今後のリリースで、追加の ABI のサポートが導入される可能性があります。
3.3.2. 32 ビット ARM ネイティブ コードの互換性
armeabi
ABI のサポートをレポートする場合、デバイス実装は:
- [C-3-1]
armeabi
は古いアプリとの下位互換性用でしかないため、armeabi-v7a
もサポートし、そのサポートをレポートしなければなりません。
armeabi-v7a
ABI のサポートをレポートする場合、この ABI を使用するアプリについて、デバイス実装は:
[C-2-1]
/proc/cpuinfo
に次の行を含まなければならず、他の ABI によって読み取られる場合であっても同じデバイスで値を変更すべきではありません。Features:
に続けて、デバイスでサポートされるオプションの ARMv7 CPU 機能のリスト。CPU architecture:
に続けて、デバイスでサポートされる最高の ARM アーキテクチャを示す整数(例: ARMv8 デバイスの場合は「8」)。
[C-2-2] ABI が ARMv8 アーキテクチャに実装されている場合であっても、ネイティブ CPU サポートを通じて、またはソフトウェア エミュレーションを通じて、常に次のオペレーションを利用できるように維持しなければなりません。
- SWP 命令と SWPB 命令。
- CP15ISB、CP15DSB、CP15DMB バリア オペレーション。
[C-2-3] Advanced SIMD(NEON)拡張のサポートを含まなければなりません。
3.4. ウェブの互換性
3.4.1. WebView の互換性
android.webkit.Webview
API の完全な実装を提供する場合、デバイス実装は:
- [C-1-1]
android.software.webview
をレポートしなければなりません。 - [C-1-2]
android.webkit.WebView
API の実装に、Android 14 ブランチのアップストリームの Android オープンソース プロジェクトからビルドした Chromium プロジェクトを使用しなければなりません。 [C-1-3] WebView がレポートするユーザー エージェント文字列は、次の形式でなければなりません。
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 文字列の値は、android.os.Build.VERSION.RELEASE の値と同じでなければなりません。
- $(MODEL) 文字列は空にしても構いませんが、空でない場合は、値が android.os.Build.MODEL と同じでなければなりません。
- 「Build/$(BUILD)」は省略しても構いませんが、存在する場合、$(BUILD) 文字列は android.os.Build.ID の値と同じでなければなりません。
- $(CHROMIUM_VER) 文字列の値は、アップストリームの Android オープンソース プロジェクトの Chromium バージョンでなければなりません。
- デバイス実装は、ユーザー エージェント文字列で Mobile を省略しても構いません。
WebView コンポーネントは、可能な限り多くの HTML5 機能をサポートすべきであり、機能をサポートする場合、HTML5 仕様に準拠すべきです。
[C-1-4] WebView をインスタンス化するアプリとは異なるプロセスで、提供されたコンテンツまたはリモート URL コンテンツをレンダリングしなければなりません。具体的には、個別のレンダラ プロセスは、より低い権限を持ち、個別のユーザー ID として実行され、アプリのデータ ディレクトリへのアクセス権を持たず、直接ネットワーク アクセス権を持たず、Binder でシステム サービスへの必要最小限のアクセス権のみを持たなければなりません。WebView の AOSP 実装はこの要件を満たしています。
なお、デバイス実装が 32 ビットの場合、または機能フラグ android.hardware.ram.low
を宣言する場合、C-1-3 は免除されます。
3.4.2. ブラウザの互換性
通常のウェブ ブラウジング用のスタンドアロン ブラウザアプリが含まれる場合、デバイス実装は:
- [C-1-1] HTML5 に関連する次の API をそれぞれサポートしなければなりません。
- [C-1-2] HTML5/W3C webstorage API をサポートしなければならず、HTML5/W3C IndexedDB API をサポートすべきです。なお、ウェブ開発標準化団体が webstorage よりも IndexedDB を優先するようになっているため、今後の Android バージョンでは、IndexedDB が必須コンポーネントになると見込まれます。
- スタンドアロン ブラウザアプリでカスタムのユーザー エージェント文字列を送信しても構いません。
- アップストリーム WebKit ブラウザアプリに基づくかサードパーティ代替アプリに基づくかにかかわらず、スタンドアロン ブラウザアプリで HTML5 のサポートを可能な限り多く実装すべきです。
ただし、スタンドアロン ブラウザアプリが含まれない場合、デバイス実装は:
- [C-2-1] セクション 3.2.3.1 に記載されているとおり、パブリック インテント パターンを引き続きサポートしなければなりません。
3.5. API 動作の互換性
デバイス実装は:
- [C-0-9] セクション 3.5.1 に記載されているように制限されている場合を除き、すべてのインストール済みアプリに API 動作の互換性が適用されるようにしなければなりません。
- [C-0-10] デバイス実装者が選択したアプリに対してのみ API 動作の互換性を保証する許可リスト登録アプローチを実装してはなりません。
各 API タイプ(マネージド、ソフト、ネイティブ、ウェブ)の動作は、アップストリームの Android オープンソース プロジェクトの優先実装と一貫性がなければなりません。互換性の具体的な内容は次のとおりです。
- [C-0-1] デバイスは、標準的なインテントの動作またはセマンティクスを変更してはなりません。
- [C-0-2] デバイスは、特定の種類のシステム コンポーネント(Service、Activity、ContentProvider など)のライフサイクルまたはライフサイクル セマンティクスを変更してはなりません。
- [C-0-3] デバイスは、標準的な権限のセマンティクスを変更してはなりません。
- デバイスは、バックグラウンド アプリに適用される制限を変更してはなりません。より具体的には、バックグラウンド アプリについて:
- [C-0-4]
GnssMeasurement
とGnssNavigationMessage
からの出力を受信するためにアプリが登録するコールバックの実行を停止しなければなりません。 - [C-0-5]
LocationManager
API クラスまたはWifiManager.startScan()
メソッドを通じてアプリに提供される更新の頻度をレート制限しなければなりません。 - [C-0-6] アプリが API レベル 25 以降をターゲットとしている場合、ブロードキャスト インテントで
"signature"
または"signatureOrSystem"
protectionLevel
権限を必要とするか、免除リストにある場合を除き、アプリのマニフェストで標準的な Android インテントの暗黙的ブロードキャストのためにブロードキャスト レシーバを登録することを許可してはなりません。 - [C-0-7] アプリが API レベル 25 以降をターゲットとしている場合、ユーザーに表示されるタスクを処理するためにアプリが一時的に許可リスト登録されている場合を除き、アプリがサービスの
stopSelf()
メソッドを呼び出したときのように、アプリのバックグラウンド サービスを停止しなければなりません。 - [C-0-8] アプリが API レベル 25 以降をターゲットとしている場合、アプリが保持しているウェイクロックをリリースしなければなりません。
- [C-0-4]
- [C-0-11] アプリが
insertProviderAt()
またはremoveProvider()
を介してリストを変更した場合を除き、デバイスはSecurity.getProviders()
メソッドの最初の 7 つの配列値として、指定した順序、名前(Provider.getName()
で返されます)、クラスで、次のセキュリティ プロバイダを返さなければなりません。デバイスは、下記のプロバイダ指定リストの後に、追加のプロバイダを返しても構いません。- AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider -
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP -
上記のリストはすべてを網羅しているわけではありません。互換性テストスイート(CTS)は、動作の互換性についてプラットフォームの大部分をテストしますが、すべてではありません。Android オープンソース プロジェクトとの動作の互換性を確保することは、実装者の責任です。このため、デバイス実装者は、システムの重要な部分を再実装するのではなく、可能であれば Android オープンソース プロジェクトを介して入手可能なソースコードを使用すべきです。
3.5.1. アプリの制限
アプリを制限する独自のメカニズム(SDK に記載されている API の動作を変更または制限するなど)を実装していて、そのメカニズムが制限付きアプリ スタンバイ バケットより制限的である場合、デバイス実装は:
- [C-1-1] 制限付きアプリのリストをユーザーが確認できるようにしなければなりません。
- [C-1-2] アプリごとにこれらのすべての独自の制限をオン / オフするユーザー アフォーダンスを提供しなければなりません。
[C-1-3] システムの健全性に問題があることを示す証拠なしに、制限を自動的に適用してはなりません。ただし、ウェイクロックのスタック、サービスの長時間実行、その他の基準など、システムの健全性に問題があることを検出したときは、アプリに制限を適用しても構いません。基準はデバイス実装者が決定しても構いませんが、システムの健全性に対するアプリの影響に関連していなければなりません。アプリが市場で人気がないなど、システムの健全性に純粋に関係するわけではない他の基準は、基準として使用してはなりません。
[C-1-4] ユーザーがアプリの制限を手動でオフにした場合、アプリにこれらの独自の制限を自動的に適用してはなりません。これらの独自の制限を適用するようユーザーに提案することはできます。
[C-1-5] これらの独自の制限がアプリに自動的に適用される場合は、ユーザーに通知しなければなりません。このような通知は、これらの独自の制限が適用される 24 時間前までに提供しなければなりません。
[C-1-6] アプリからの API 呼び出しについては ActivityManager.isBackgroundRestricted() メソッドで true を返さなければなりません。
[C-1-7] ユーザーが明示的に使用しているトップ フォアグラウンド アプリを制限してはなりません。
[C-1-8] ユーザーが明示的にアプリの使用を開始する場合は常に、そのアプリがトップ フォアグラウンド アプリになるよう、アプリに対するこれらの独自の制限を停止しなければなりません。
[C-1-10] 独自の制限を適用する方法を説明する明確な公開ドキュメントまたはウェブサイトを提供しなければなりません。このドキュメントまたはウェブサイトは、Android SDK ドキュメントからリンクでき、以下を含まなければなりません。
- 独自の制限についてのトリガー条件。
- 制限できるアプリの種類と方法。
- アプリに対しこのような制限を免除する方法。
- ユーザーがインストールできるアプリの免除などがサポートされている場合に、アプリが独自の制限の適用免除をリクエストする方法。
アプリがデバイスにプリインストールされていて、30 日以上ユーザーが明示的に使用していない場合、[C-1-3]、[C-1-5] は適用されません。
AOSP で実装されるアプリ制限を拡張する場合、デバイス実装は:
- [C-2-1] こちらのドキュメントに記載されている実装に従わなければなりません。
3.5.2. アプリの休止状態
AOSP に含まれるアプリの休止状態が含まれる場合、または AOSP に含まれる機能を拡張する場合、デバイス実装は:
- [C-1-1] [C-1-6] と [C-1-3] を除き、セクション 3.5.1 のすべての要件を満たさなければなりません。
- [C-1-2] ユーザーが一定期間アプリを使用していないという証拠がある場合にのみ、そのユーザーのアプリに対する制限を適用しなければなりません。この期間は 1 か月以上にすることが強く推奨されます。使用状況は、UsageStats#getLastTimeVisible() API を介した明示的なユーザー操作か、サービス バインディング、コンテンツ プロバイダ バインディング、明示的なブロードキャストなど、アプリが強制停止状態を脱する原因となる、なんらかのものによって定義しなければなりません(新しい API UsageStats#getLastTimeAnyComponentUsed() によってトラッキング)。
- [C-1-3] パッケージがどのユーザーによっても一定期間使用されていないという証拠がある場合にのみ、すべてのデバイス ユーザーに影響する制限を適用しなければなりません。この期間は 1 か月以上にすることが強く推奨されます。
- [C-1-4] アクティビティ インテント、サービス バインディング、コンテンツ プロバイダのリクエスト、または明示的なブロードキャストにアプリが応答できないようにしてはなりません。
AOSP のアプリの休止状態は、上記の要件を満たしています。
3.6. API 名前空間
Android は、Java プログラミング言語で定義されたパッケージとクラスの名前空間規則に従います。サードパーティ アプリとの互換性を確保するために、デバイス実装者は、次のパッケージ名前空間に対して禁止されている変更(下記参照)を行ってはなりません。
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
つまり:
- [C-0-1] メソッド シグネチャかクラス シグネチャを変更することで、またはクラスかクラス フィールドを削除することで、Android プラットフォームで一般公開されている API を変更してはなりません。
- [C-0-2] 一般公開されている要素(クラスまたはインターフェース、既存のクラスまたはインターフェースのフィールドまたはメソッドなど)やテスト API またはシステム API を、上記の名前空間の API に追加してはなりません。「一般公開されている要素」とは、アップストリームの Android ソースコードで使用されている「@hide」マーカーで装飾されていない構成要素のことです。
デバイス実装者は基となる API 実装を変更しても構いませんが、そのような変更は:
- [C-0-3] 一般公開されている API の、所定の動作と Java 言語シグネチャに影響してはなりません。
- [C-0-4] アドバタイズされたり、デベロッパーに公開されたりしてはなりません。
ただし、デバイス実装者は標準的な Android 名前空間の外にカスタム API を追加しても構いませんが、カスタム API は:
- [C-0-5] 別の組織が所有または参照している名前空間にあってはなりません。たとえば、デバイス実装者は、
com.google.*
などの名前空間に API を追加してはなりません。これを行えるのは Google のみです。同様に、Google は他社の名前空間に API を追加してはなりません。 - [C-0-6] そのような API のメモリ使用量増加の影響を受けるのが(<uses-library> メカニズムを介して)明示的に Android 共有ライブラリを使用するアプリのみになるように、Android 共有ライブラリにパッケージ化しなければなりません。
デバイス実装者は NDK API の外にネイティブ言語でカスタム API を追加しても構いませんが、そのカスタム API は:
- [C-1-1] こちらに記載されているとおり、NDK ライブラリまたは別の組織が所有するライブラリにあってはなりません。
デバイス実装者が上記パッケージ名前空間のいずれかの改善(既存の API に便利な新機能を追加する、新しい API を追加するなど)を提案する場合、実装者は source.android.com にアクセスし、サイトに記載されている情報に従って、変更とコードに貢献するプロセスを開始すべきです。
なお、上記の制限は、Java プログラミング言語の標準的な API 命名規則に対応しています。このセクションは、この互換性定義に含めることでそれらの規則を補強し、拘束力を持たせることのみを目的としています。
3.7. ランタイムの互換性
デバイス実装は:
[C-0-1] 完全な Dalvik 実行ファイル(DEX)形式、Dalvik バイトコード仕様とセマンティクスをサポートしなければなりません。
[C-0-2] Dalvik ランタイムを構成して、アップストリーム Android プラットフォームに合わせて、下表に示すとおり、メモリを割り当てなければなりません(画面サイズと画面密度の定義については、セクション 7.1.1 をご覧ください)。
Dalvik 実行ファイル形式のリファレンス アップストリーム実装であり、リファレンス実装のパッケージ管理システムでもある Android ランタイム(ART)を使用すべきです。
ランタイムの安定性を確保するために、さまざまな実行モードとターゲット アーキテクチャでファズテストを行うべきです。Android オープンソース プロジェクトのウェブサイトで JFuzz と DexFuzz をご覧ください。
なお、下記のメモリ値は最小値とみなされ、デバイス実装はアプリごとにより多くのメモリを割り当てても構いません。
画面レイアウト | 画面密度 | 最小アプリメモリ |
---|---|---|
Android スマートウォッチ | 120 dpi(ldpi) | 32 MB |
140 dpi(140dpi) | ||
160 dpi(mdpi) | ||
180 dpi(180dpi) | ||
200 dpi(200dpi) | ||
213 dpi(tvdpi) | ||
220 dpi(220dpi) | 36 MB | |
240 dpi(hdpi) | ||
280 dpi(280dpi) | ||
320 dpi(xhdpi) | 48 MB | |
360 dpi(360dpi) | ||
400 dpi(400dpi) | 56 MB | |
420 dpi(420dpi) | 64 MB | |
480 dpi(xxhdpi) | 88 MB | |
560 dpi(560dpi) | 112 MB | |
640 dpi(xxxhdpi) | 154 MB | |
小 / 標準 | 120 dpi(ldpi) | 32 MB |
140 dpi(140dpi) | ||
160 dpi(mdpi) | ||
180 dpi(180dpi) | 48 MB | |
200 dpi(200dpi) | ||
213 dpi(tvdpi) | ||
220 dpi(220dpi) | ||
240 dpi(hdpi) | ||
280 dpi(280dpi) | ||
320 dpi(xhdpi) | 80 MB | |
360 dpi(360dpi) | ||
400 dpi(400dpi) | 96 MB | |
420 dpi(420dpi) | 112 MB | |
480 dpi(xxhdpi) | 128 MB | |
560 dpi(560dpi) | 192 MB | |
640 dpi(xxxhdpi) | 256 MB | |
大 | 120 dpi(ldpi) | 32 MB |
140 dpi(140dpi) | 48 MB | |
160 dpi(mdpi) | ||
180 dpi(180dpi) | 80 MB | |
200 dpi(200dpi) | ||
213 dpi(tvdpi) | ||
220 dpi(220dpi) | ||
240 dpi(hdpi) | ||
280 dpi(280dpi) | 96 MB | |
320 dpi(xhdpi) | 128 MB | |
360 dpi(360dpi) | 160 MB | |
400 dpi(400dpi) | 192 MB | |
420 dpi(420dpi) | 228 MB | |
480 dpi(xxhdpi) | 256 MB | |
560 dpi(560dpi) | 384 MB | |
640 dpi(xxxhdpi) | 512 MB | |
特大 | 120 dpi(ldpi) | 48 MB |
140 dpi(140dpi) | 80 MB | |
160 dpi(mdpi) | ||
180 dpi(180dpi) | 96 MB | |
200 dpi(200dpi) | ||
213 dpi(tvdpi) | ||
220 dpi(220dpi) | ||
240 dpi(hdpi) | ||
280 dpi(280dpi) | 144 MB | |
320 dpi(xhdpi) | 192 MB | |
360 dpi(360dpi) | 240 MB | |
400 dpi(400dpi) | 288 MB | |
420 dpi(420dpi) | 336 MB | |
480 dpi(xxhdpi) | 384 MB | |
560 dpi(560dpi) | 576 MB | |
640 dpi(xxxhdpi) | 768 MB |
3.8. ユーザー インターフェースの互換性
3.8.1. ランチャー(ホーム画面)
Android にはランチャー アプリ(ホーム画面)があり、デバイス ランチャー(ホーム画面)を置き換えるサードパーティ アプリをサポートしています。
サードパーティ アプリでデバイスのホーム画面を置き換えられるようにする場合、デバイス実装は:
- [C-1-1] プラットフォーム機能
android.software.home_screen
を宣言しなければなりません。 - [C-1-2] サードパーティ アプリが
<adaptive-icon>
タグを使用してアイコンを提供し、アイコンを取得するPackageManager
メソッドが呼び出された場合、AdaptiveIconDrawable
オブジェクトを返さなければなりません。
ショートカットのアプリ内固定をサポートするデフォルト ランチャーが含まれる場合、デバイス実装は:
- [C-2-1]
ShortcutManager.isRequestPinShortcutSupported()
についてtrue
をレポートしなければなりません。 - [C-2-2]
ShortcutManager.requestPinShortcut()
API メソッドを介してアプリがリクエストしたショートカットを追加する前にユーザーに確認するユーザー アフォーダンスがなければなりません。 - [C-2-3] アプリのショートカットのページに記載されているとおり、固定ショートカット、動的ショートカット、静的ショートカットをサポートしなければなりません。
逆に、ショートカットのアプリ内固定をサポートしない場合、デバイス実装は:
- [C-3-1]
ShortcutManager.isRequestPinShortcutSupported()
についてfalse
をレポートしなければなりません。
ShortcutManager API を通じてサードパーティ アプリが提供する追加のショートカットへのクイック アクセスを提供するデフォルト ランチャーを実装する場合、デバイス実装は:
- [C-4-1] 記載されたすべてのショートカット機能(静的ショートカット、動的ショートカット、固定ショートカットなど)をサポートし、
ShortcutManager
API クラスの API を完全に実装しなければなりません。
アプリアイコンのバッジを表示するデフォルト ランチャー アプリが含まれる場合、デバイス実装は:
- [C-5-1]
NotificationChannel.setShowBadge()
API メソッドを尊重しなければなりません。つまり、値がtrue
に設定されている場合はアプリアイコンに関連付けられたビジュアル アフォーダンスを表示し、アプリの通知チャンネルすべてで値がfalse
に設定されている場合はアプリアイコンのバッジスキームを表示しません。 - サードパーティ アプリが独自仕様の API を使用して独自仕様のバッジスキームをサポートすることを示している場合、アプリアイコン バッジを独自仕様のバッジスキームでオーバーライドしても構いません。ただし、
Notification.Builder.setNumber()
API やNotification.Builder.setBadgeIconType()
API など、SDK に記載されている通知バッジ API を通じて提供されるリソースと値を使用すべきです。
デバイス実装がモノクロ アイコンをサポートする場合、モノクロ アイコンは:
- [C-6-1] ユーザーが(設定アプリや壁紙選択ツールのメニューなどから)明示的に有効にした場合のみに使用しなければなりません。
3.8.2. ウィジェット
Android は、アプリが 「AppWidget」をエンドユーザーに公開できるようにするコンポーネント タイプとそれに対応する API、ライフサイクルを定義することで、サードパーティ アプリ ウィジェットをサポートします。
サードパーティ アプリ ウィジェットをサポートする場合、デバイス実装は:
- [C-1-1] プラットフォーム機能
android.software.app_widgets
のサポートを宣言しなければなりません。 [C-1-2] AppWidget の組み込みサポートを含まなければならず、AppWidget を追加、設定、表示、削除するユーザー インターフェース アフォーダンスを公開しなければなりません。
[C-1-3] 標準グリッドサイズで 4 x 4 のウィジェットをレンダリングできなければなりません。詳細については、Android SDK ドキュメントのアプリ ウィジェットのデザイン ガイドラインをご覧ください。
ロック画面でのアプリ ウィジェットをサポートしても構いません。
サードパーティ アプリ ウィジェットと、ショートカットのアプリ内固定をサポートする場合、デバイス実装は:
- [C-2-1]
AppWidgetManager.html.isRequestPinAppWidgetSupported()
についてtrue
をレポートしなければなりません。 - [C-2-2]
AppWidgetManager.requestPinAppWidget()
API メソッドを介してアプリがリクエストしたショートカットを追加する前にユーザーに確認するユーザー アフォーダンスがなければなりません。
3.8.3. 通知
Android には Notification
API と NotificationManager
API があります。これを使用すると、サードパーティ アプリのデベロッパーは、デバイスのハードウェア コンポーネント(通知音、バイブレーション、ライトなど)とソフトウェア機能(通知シェード、システムバーなど)を使用して重要なイベントをユーザーに通知し、ユーザーの注意を引くことができます。
3.8.3.1. 通知の表示
サードパーティ アプリで重要なイベントをユーザーに通知できるようにする場合、デバイス実装は:
- [C-1-1] SDK ドキュメントに記載されているとおり、デバイス実装ハードウェアで可能な範囲で、ハードウェア機能を使用する通知をサポートしなければなりません。たとえば、デバイス実装がバイブレーターを含む場合、バイブレーション API を正しく実装しなければなりません。デバイス実装にハードウェアがない場合、対応する API を NoOps として実装しなければなりません。この動作の詳細についてはセクション 7 をご覧ください。
- [C-1-2] API、またはステータス / システムバーのアイコン スタイルガイドで提供されているすべてのリソース(アイコン、アニメーション ファイルなど)を正しくレンダリングしなければなりません。ただし、リファレンス Android オープンソース実装で提供されているものとは別のユーザー エクスペリエンスを通知で提供しても構いません。
- [C-1-3] API について記述した動作を使用し、適切に実装して、通知を更新、削除、グループ化しなければなりません。
- [C-1-4] SDK に記載されている NotificationChannel API のすべての動作を提供しなければなりません。
- [C-1-5] チャンネルごと、アプリ パッケージ レベルごとに、特定のサードパーティ アプリの通知をブロック、変更するユーザー アフォーダンスを提供しなければなりません。
- [C-1-6] 削除した通知チャンネルを表示するユーザー アフォーダンスも提供しなければなりません。
[C-1-7] 追加のユーザー操作なしで、Notification.MessagingStyle を通じて提供されるすべてのリソース(画像、ステッカー、アイコンなど)を、通知テキストとともに正しくレンダリングしなければなりません。たとえば、setGroupConversation を通じて設定されたグループの会話では、android.app.Person を通じて提供されたアイコンを含め、すべてのリソースを表示しなければなりません。
[C-SR-1] 通知リスナー権限が付与されたアプリに公開される通知をユーザーが制御するアフォーダンスを提供することが強く推奨されます。粒度は、そのような通知リスナーごとに、そのリスナーにブリッジされる通知タイプをユーザーが制御できるようなものでなければなりません。タイプには、「会話」、「アラート」、「サイレント」、「重要な進行中」の通知が含まれなければなりません。
[C-SR-2] ユーザーが特定の通知リスナーへの通知から除外するアプリを指定するアフォーダンスを提供することが強く推奨されます。
[C-SR-3] 特定のサードパーティ アプリの通知を、ユーザーがその通知を複数回閉じた後、チャンネルごと、アプリ パッケージ レベルごとにブロックするユーザー アフォーダンスを自動的に表示させることが強く推奨されます。
リッチ通知をサポートすべきです。
一部の高優先度の通知をヘッドアップ通知として提示すべきです。
通知をスヌーズするユーザー アフォーダンスがあるべきです。
ドライバーの注意散漫などの安全上の問題を軽減するために、サードパーティ アプリが重要なイベントをユーザーに通知できるタイミングと表示のみ、管理しても構いません。
Android 11 では、MessagingStyle を使用した、公開されている個人のショートカット ID を提供する通知である、会話通知のサポートが導入されています。
デバイス実装は:
- [C-SR-4] 進行中のフォアグラウンド サービス通知と
importance:high
の通知を除き、会話以外の通知より前にconversation notifications
をグループ化して表示することが強く推奨されます。
conversation notifications
をサポートし、アプリが bubbles
に必要なデータを提供する場合、デバイス実装は:
- [C-SR-5] この会話をバブルとして表示することが強く推奨されます。AOSP 実装はデフォルトのシステム UI、設定、ランチャーで、この要件を満たしています。
リッチ通知をサポートする場合、デバイス実装は:
- [C-2-1]
Notification.Style
API クラスとそのサブクラスを通じて提供されたとおりのリソースを、提示されたリソース要素に使用しなければなりません。 Notification.Style
API クラスとそのサブクラスで定義された各リソース要素(アイコン、タイトル、概要テキストなど)をすべて提示すべきです。
ヘッドアップ通知とは、ユーザーがどの画面を表示しているかにかかわらず、着信時にユーザーに表示される通知です。ヘッドアップ通知をサポートする場合、デバイス実装は:
- [C-3-1] ヘッドアップ通知を提示するとき、
Notification.Builder
API クラスに記載されているとおり、ヘッドアップ通知ビューとリソースを使用しなければなりません。 - [C-3-2] SDK に記載されているとおり、追加のユーザー操作なしで、
Notification.Builder.addAction()
を通じて提供されるアクションを通知コンテンツとともに表示しなければなりません。
3.8.3.2. 通知リスナー サービス
Android には、NotificationListenerService
API があります。これにより、アプリは通知がポストされたか更新されたときに、全通知のコピーを受け取ることができます(ユーザーが明示的に有効にした場合)。
デバイス実装は:
- [C-0-1] 通知オブジェクトにアタッチされているすべてのメタデータを含め、インストールされていてユーザーが有効にしたすべてのリスナー サービスで、通知全体を正確かつ迅速に更新しなければなりません。
- [C-0-2]
snoozeNotification()
API 呼び出しを尊重し、通知を閉じ、API 呼び出しに設定されたスヌーズ継続時間後にコールバックを行わなければなりません。
通知をスヌーズするユーザー アフォーダンスがある場合、デバイス実装は:
- [C-1-1]
NotificationListenerService.getSnoozedNotifications()
などの標準 API を通じて、スヌーズされた通知ステータスを適切に反映しなければなりません。 - [C-1-2] 永続 / フォアグラウンド サービスからのものでない限り、このユーザー アフォーダンスを、インストールされている各サードパーティー アプリからの通知をスヌーズするために利用できるようにしなければなりません。
3.8.3.3. DND(サイレント モード) / 優先モード
DND 機能(優先モードともいいます)をサポートする場合、デバイス実装は:
- [C-1-1] サードパーティ アプリに対して DND ポリシー構成へのアクセスを許可または拒否する手段をデバイス実装がユーザーに提供した場合、ユーザーが作成した事前定義済みルールとともに、アプリが作成した自動 DND ルールを表示しなければなりません。
- [C-1-3]
NotificationManager.Policy
に沿って渡されたsuppressedVisualEffects
値を使用しなければならず、アプリが SUPPRESSED_EFFECT_SCREEN_OFF フラグまたは SUPPRESSED_EFFECT_SCREEN_ON フラグのいずれかを設定している場合、DND 設定メニューで視覚効果が抑制されていることをユーザーに示すべきです。
3.8.4. Assist API
Android には、現在のコンテキストの情報をデバイスのアシスタントとどの程度共有するかをアプリが選択できるようにする Assist API が用意されています。
アシスト アクションをサポートする場合、デバイス実装は:
- [C-2-1] コンテキストが共有される際、次のいずれかによって、エンドユーザーに対し明確に示さなければなりません。
- アシストアプリがコンテキストにアクセスするたびに、Android オープンソース プロジェクト実装での継続時間、明るさと同等以上の白色光を、画面の端に表示する。
- プリインストールのアシストアプリでは、デフォルトのオーディオ入力とアシスタント アプリの設定メニューから 2 操作未満でユーザー アフォーダンスを提供し、起動ワードまたはアシスト ナビゲーション キー入力を通じてアシストアプリがユーザーによって明示的に起動された場合にのみコンテキストを共有する。
- [C-2-2] セクション 7.2.3 に記載されている、アシストアプリを起動する指定操作は、ユーザーが選択したアシストアプリ、つまり
VoiceInteractionService
を実装したアプリまたはACTION_ASSIST
インテントを処理するアクティビティを起動しなければなりません。
3.8.5. アラートとトースト
アプリは Toast
API を使用して、エンドユーザーに対し、短時間で消える短い非モーダル文字列を表示できます。また、TYPE_APPLICATION_OVERLAY
ウィンドウ タイプ API を使用して、他のアプリに重ねてアラート ウィンドウを表示できます。
画面または動画出力が含まれる場合、デバイス実装は:
[C-1-1]
TYPE_APPLICATION_OVERLAY
を使用するアラート ウィンドウをアプリが表示しないようにブロックするユーザー アフォーダンスを提供しなければなりません。AOSP 実装は通知シェードにコントロールがあることで、この要件を満たしています。[C-1-2] Toast API を使用し、アプリからエンドユーザーへのトーストを、なんらかの目立つ方法で表示しなければなりません。
3.8.6. テーマ
Android は、アプリがアクティビティまたはアプリの全体にわたってスタイルを適用するためのメカニズムとして「テーマ」を提供します。
Android には、アプリ デベロッパーが Android SDK で定義された Holo テーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「Holo」と「Material」があります。
画面または動画出力が含まれる場合、デバイス実装は:
- [C-1-1] アプリに公開されているいずれの Holo テーマ属性も変更してはなりません。
- [C-1-2] 「Material」テーマ ファミリーをサポートしなければならず、アプリに公開される Material テーマ属性またはそのアセットのいずれについても変更してはなりません。
[C-1-3] Roboto がサポートしている言語について「sans-serif」フォント ファミリーを Roboto バージョン 2.x に設定しなければなりません。または、Roboto がサポートしている言語について「sans-serif」フォント ファミリーに使用するフォントを Roboto バージョン 2.x に変更するユーザー アフォーダンスを提供しなければなりません。
[C-1-4]
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
の AOSP ドキュメント(android.theme.customization.system_palette
とandroid.theme.customization.theme_style
を参照)で指定されているとおりに、動的な色調パレットを生成しなければなりません。[C-1-5]
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
ドキュメント(android.theme.customization.theme_styles
を参照)に記載されているカラーテーマ スタイル(TONAL_SPOT
、VIBRANT
、EXPRESSIVE
、SPRITZ
、RAINBOW
、FRUIT_SALAD
、MONOCHROMATIC
)を使用して、動的な色調パレットを生成しなければなりません。「ソースカラー」は、
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
に記載されているとおり、android.theme.customization.system_palette
で送信されるときに動的な色調パレットを生成するために使用されます。[C-1-6]
CAM16
彩度の値が 5 以上でなければなりません。com.android.systemui.monet.ColorScheme#getSeedColors
を介して壁紙から取得すべきです。これにより、複数の有効なソースカラーが提供され、そこから色を選択できます。提供された色のいずれも上記のソースカラーの要件を満たしていない場合、値
0xFF1B6EF3
を使用すべきです。
Android には、アプリ デベロッパーがデバイス実装者によって定義されたデバイステーマのデザインにマッチさせる場合に使用する定義済みスタイルのセットとして、「デバイスのデフォルト」のテーマ ファミリーも用意されています。
- デバイス実装は、アプリに公開されるデバイスのデフォルトのテーマ属性を変更しても構いません。
Android は、異なる形のテーマとして、半透明のシステムバーを使用したテーマをサポートしています。これにより、アプリ デベロッパーは、ステータスバーとナビゲーション バーの背後のエリア全体にアプリ コンテンツを表示することができます。この構成でデベロッパー エクスペリエンスに一貫性を持たせるには、さまざまなデバイス実装でステータスバーのアイコン スタイルを維持することが重要です。
システム ステータスバーが含まれる場合、デバイス実装は:
- [C-2-1] アイコンが問題のあるステータスを示すか、アプリが WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS フラグを使用してライト ステータスバーをリクエストする場合を除き、システム ステータス アイコン(信号強度やバッテリー残量など)と、システムが発行する通知には、白色を使用しなければなりません。
- [C-2-2] Android デバイス実装は、アプリがライト ステータスバーをリクエストしたら、システム ステータス アイコンを黒色に変更しなければなりません(詳細については R.style をご覧ください)。
3.8.7. ライブ壁紙
Android では、アプリがエンドユーザーに 1 つ以上の 「ライブ壁紙」を公開できるようにするためのコンポーネント タイプとそれに対応する API、ライフサイクルを定義しています。ライブ壁紙とは、壁紙として他のアプリの背後に表示される、アニメーション、パターン、または入力機能が制限された同様の画像のことです。
ハードウェアは、他のアプリに悪影響を及ぼさず、妥当なフレームレートで、機能に制限なくすべてのライブ壁紙を実行できる場合、ライブ壁紙を確実に実行できるとみなされます。ハードウェアの制限によって、壁紙やアプリがクラッシュする、誤動作する、CPU やバッテリー電力を過剰に使用する、または許容できない低フレームレートで実行される場合、ハードウェアはライブ壁紙を実行できないとみなされます。たとえば、一部のライブ壁紙は、OpenGL 2.0 または 3.x コンテキストを使用してコンテンツをレンダリングすることがあります。複数の OpenGL コンテキストをサポートしていないハードウェアでは、OpenGL コンテキストを使用するライブ壁紙が、OpenGL コンテキストを使用する他のアプリと競合する可能性があるため、ライブ壁紙を確実には実行できません。
- 上記のようにライブ壁紙を確実に実行できるデバイス実装は、ライブ壁紙を実装すべきです。
ライブ壁紙を実装する場合、デバイス実装は:
- [C-1-1] プラットフォーム機能フラグ android.software.live_wallpaper をレポートしなければなりません。
3.8.8. アクティビティの切り替え
アップストリームの Android ソースコードには、概要画面が含まれます。これは、タスクの切り替えのためのシステムレベルのユーザー インターフェースです。ユーザーが最後にアプリを離れたときのアプリのグラフィック状態のサムネイル画像を使用して、最近アクセスしたアクティビティやタスクを表示することにも使われます。
セクション 7.2.3 で詳述するように、履歴機能のナビゲーション キーを含むデバイス実装は、インターフェースを変更しても構いません。
セクション 7.2.3 で詳述するように、履歴機能のナビゲーション キーが含まれ、インターフェースを変更する場合、デバイス実装は:
- [C-1-1] 少なくとも 7 つまでのアクティビティ表示をサポートしなければなりません。
- 少なくとも同時に 4 つのアクティビティのタイトルを表示すべきです。
- [C-1-2] 画面固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。
- ハイライトの色、アイコン、最近の画面タイトルを表示すべきです。
- 閉じるアフォーダンス(「x」)を表示すべきですが、ユーザーが画面を操作するまで遅らせても構いません。
- 以前のアクティビティに切り替えやすくするためのショートカットを実装すべきです。
- 履歴機能のキーが 2 回タップされたとき、直近に使用した 2 つのアプリを素早く切り替えるアクションをトリガーすべきです。
- 履歴機能のキーが長押しされたとき、分割画面のマルチウィンドウ モードをトリガーすべきです(サポートしている場合)。
- 一緒に移動するグループとして関連する履歴を表示しても構いません。
- [C-SR-1] 概要画面には、アップストリームの Android ユーザー インターフェース(またはサムネイルベースの同様のインターフェース)を使用することが強く推奨されます。
3.8.9. 入力管理
Android は、入力管理と、サードパーティのインプット メソッド エディタをサポートしています。
ユーザーがデバイスでサードパーティの入力方法を使用できるようにする場合、デバイス実装は:
- [C-1-1] Android SDK ドキュメントで定義されているとおり、プラットフォーム機能 android.software.input_methods を宣言し、IME API をサポートしなければなりません。
3.8.10. ロック画面のメディア コントロール
Remote Control Client API のサポートは Android 5.0 で終了し、ロック画面に表示される再生コントロールとメディアアプリを統合できるメディア通知テンプレートに置き換えられました。
3.8.11. スクリーン セーバー(旧 Dreams)
スクリーン セーバーを構成するための設定についてはセクション 3.2.3.5 をご覧ください。
3.8.12. 位置情報
位置座標を提供できるハードウェア センサー(GPS など)が含まれる場合、デバイス実装は:
- [C-1-2] 設定内の位置情報メニューに位置情報の現在のステータスを表示しなければなりません。
- [C-1-3] 設定内の位置情報メニューに位置情報モードを表示してはなりません。
3.8.13. Unicode とフォント
Android は、Unicode 10.0 で定義されている絵文字をサポートしています。
画面または動画出力が含まれる場合、デバイス実装は:
- [C-1-1] こうした絵文字をカラーグリフでレンダリングできなければなりません。
- [C-1-2] 次のサポートを含まなければなりません。
- ウェイトの異なる Roboto 2 フォント - デバイスで利用可能な言語の sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light。
- ラテン文字拡張 A、B、C、D を含むラテン文字、ギリシャ文字、キリル文字の Unicode 7.0 全範囲、Unicode 7.0 の通貨記号ブロックのグリフすべて。
- [C-1-3] システム イメージ内の NotoColorEmoji.tff を削除または変更してはなりません(新しい絵文字フォントを追加して NotoColorEmoji.tff の絵文字をオーバーライドすることは可能です)。
- Unicode Technical Report #51 で規定されているとおり、肌の色と多様な家族の絵文字をサポートすべきです。
IME が含まれる場合、デバイス実装は:
- これらの絵文字の入力方法をユーザーに提供すべきです。
Android は、ミャンマー フォントのレンダリングをサポートしています。ミャンマーには、ミャンマー語をレンダリングするための Unicode 非準拠のフォントがいくつかあります(一般に「Zawgyi」と呼ばれます)。
ビルマ語のサポートが含まれる場合、デバイス実装は:
- [C-2-1] デフォルトでは、Unicode 準拠のフォントでテキストをレンダリングしなければなりません。ユーザーが言語選択ツールで選択した場合を除き、Unicode 非準拠のフォントをデフォルト フォントとして設定してはなりません。
- [C-2-2] デバイスで Unicode 非準拠のフォントがサポートされている場合は、Unicode フォントと Unicode 非準拠のフォントをサポートしなければなりません。Unicode 非準拠のフォントで、Unicode フォントを削除または上書きしてはなりません。
- [C-2-3] Unicode 非準拠のフォントでテキストをレンダリングしなければならないのは、スクリプト コード Qaag を使用する言語コード(my-Qaag など)が指定されている場合のみです。それ以外の ISO 言語または地域コード(割り当て済みか、未割り当てか、予約済みかを問わず)は、ミャンマー語の Unicode 非準拠フォントを参照するために使用することはできません。アプリ デベロッパーとウェブページ作成者は、他の言語の場合と同じように、指定の言語コードとして my-Qaag を指定できます。
3.8.14. マルチウィンドウ
複数のアクティビティを同時に表示する機能がある場合、デバイス実装は:
- [C-1-1] Android SDK のマルチウィンドウ モードのサポートに関するドキュメントに記載されているアプリの動作と API に従ってマルチ ウィンドウ モードを実装し、下記の要件を満たさなければなりません。
- [C-1-2] こちらの SDK に記載されているとおり、
AndroidManifest.xml
ファイル内の、アプリによって設定されたandroid:resizeableActivity
を使用しなければなりません。 - [C-1-3] 画面の高さが 440 dp 未満、画面の幅が 440 dp 未満の場合、分割画面モードまたはフリーフォーム モードを提供してはなりません。
- [C-1-4] ピクチャー イン ピクチャー以外のマルチウィンドウ モードで、アクティビティを 220dp 未満にサイズ変更してはなりません。
- 画面サイズが
xlarge
のデバイス実装は、フリーフォーム モードをサポートすべきです。
マルチウィンドウ モードと分割画面モードをサポートする場合、デバイス実装は:
- [C-2-2] 分割画面マルチウィンドウの固定されたアクティビティを切り抜かなければなりませんが、ランチャー アプリがフォーカスされたウィンドウの場合、コンテンツの一部を表示すべきです。
- [C-2-3] サードパーティ ランチャー アプリの宣言された
AndroidManifestLayout_minWidth
値とAndroidManifestLayout_minHeight
値を使用しなければならず、固定されたアクティビティの一部のコンテンツを表示する過程でこれらの値をオーバーライドしてはなりません。
マルチウィンドウ モードとピクチャー イン ピクチャー マルチウィンドウ モードをサポートする場合、デバイス実装は:
- [C-3-1] アプリが次の場合、アクティビティをピクチャー イン ピクチャー マルチウィンドウ モードで起動しなければなりません: * API レベル 26 以降をターゲットとし、
android:supportsPictureInPicture
を宣言する場合、* API レベル 25 以前をターゲットとし、android:resizeableActivity
とandroid:supportsPictureInPicture
の両方を宣言する場合。 - [C-3-2]
setActions()
API を通じて現在の PIP アクティビティで指定されている SystemUI のアクションを公開しなければなりません。 - [C-3-3]
setAspectRatio()
API を通じて PIP アクティビティで指定されているとおり、1:2.39 以上 2.39:1 以下のアスペクト比をサポートしなければなりません。 - [C-3-4]
KeyEvent.KEYCODE_WINDOW
を使用して PIP ウィンドウをコントロールしなければなりません。PIP モードが実装されていない場合は、キーがフォアグラウンド アクティビティで利用可能でなければなりません。 - [C-3-5] アプリが PIP モードで表示されないようにブロックするユーザー アフォーダンスを提供しなければなりません。AOSP 実装は通知シェードにコントロールがあることで、この要件を満たしています。
[C-3-6] アプリが
AndroidManifestLayout_minWidth
とAndroidManifestLayout_minHeight
の値を宣言しない場合、次に示す PIP ウィンドウの最小の幅と高さを割り当てなければなりません。- Configuration.uiMode が
UI_MODE_TYPE_TELEVISION
以外に設定されたデバイスは、最小の幅と高さ 108 dp を割り当てなければなりません。 - Configuration.uiMode が
UI_MODE_TYPE_TELEVISION
に設定されたデバイスは、最小の幅 240 dp、最小の高さ 135 dp を割り当てなければなりません。
- Configuration.uiMode が
3.8.15. ディスプレイ カットアウト
Android は、SDK ドキュメントに記載されているとおり、ディスプレイ カットアウトをサポートしています。DisplayCutout
API は、縁のディスプレイ カットアウトまたは曲面ディスプレイのためにアプリで機能しないことがある、ディスプレイの縁のエリアを定義します。
ディスプレイ カットアウトが含まれる場合、デバイス実装は:
- [C-1-5] デバイスのアスペクト比が 1.0(1:1)の場合、カットアウトがあってはなりません。
- [C-1-2] 縁 1 つにつきカットアウトが 1 つを超えてはなりません。
- [C-1-3] SDK に記載されているとおり、
WindowManager.LayoutParams
API を通じてアプリが設定したディスプレイ カットアウト フラグを使用しなければなりません。 - [C-1-4]
DisplayCutout
API で定義されたすべてのカットアウト指標について正しい値をレポートしなければなりません。
3.8.16. デバイス コントロール
Android には、サードパーティ アプリがユーザーにクイック ステータスとアクションのデバイス コントロールを公開できる、ControlsProviderService
API と Control
API があります。
デバイス固有の要件についてはセクション 2_2_3 をご覧ください。
3.8.17. クリップボード
デバイス実装は:
- [C-0-1] 9.8.6 コンテンツ キャプチャとアプリ検索に記載されているサービスを除き、ユーザーによる明示的な操作(オーバーレイのボタンを押すなど)なしに、コンポーネント、アクティビティ、サービスに対して、またはネットワーク接続を介して、クリップボード データを送信してはなりません。
ClipData.getDescription().getExtras()
に android.content.extra.IS_SENSITIVE
を含むいずれかの ClipData
アイテムのクリップボードに、コンテンツがコピーされたときにユーザーに表示されるプレビューを生成する場合、デバイス実装は:
- [C-1-1] ユーザーに表示されるプレビューを編集しなければなりません。
AOSP リファレンス実装は、これらのクリップボードの要件を満たしています。
3.9. デバイス管理
Android には、Android Device Administration API を通じて、セキュリティ対応アプリがシステムレベルでデバイス管理機能(パスワード ポリシーの適用、リモートワイプの実施など)を実行できる機能があります。
Android SDK ドキュメントで規定されているすべてのデバイス管理ポリシーを実装する場合、デバイス実装は:
- [C-1-1]
android.software.device_admin
を宣言しなければなりません。 - [C-1-2] セクション 3.9.1 とセクション 3.9.1.1 に記載されているとおり、デバイス所有者のプロビジョニングをサポートしなければなりません。
3.9.1 デバイスのプロビジョニング
3.9.1.1 デバイス所有者のプロビジョニング
android.software.device_admin
を宣言する場合、デバイス実装は:
- [C-1-1] 下記のとおり、デバイス所有者アプリとしてのデバイス ポリシー クライアント(DPC)の登録をサポートしなければなりません。
- ユーザーもユーザーデータも設定されていない場合、デバイス実装は:
- [C-1-5] デバイスが機能フラグ
android.hardware.nfc
を介して近距離無線通信(NFC)のサポートを宣言していて、MIME タイプMIME_TYPE_PROVISIONING_NFC
のレコードを含む NFC メッセージを受信する場合は、DPC アプリをデバイス所有者アプリとして登録するか、DPC アプリがデバイス所有者とプロファイル所有者のどちらになるかを選択できるようにしなければなりません。 - [C-1-8]
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
の値に応じて DPC アプリがデバイス所有者とプロファイル所有者のどちらになるかを選択できるように、デバイス所有者のプロビジョニングがトリガーされた後、ACTION_GET_PROVISIONING_MODE インテントを送信しなければなりません。ただし、有効なオプションが 1 つしかないことがコンテキストから判断できる場合を除きます。 - [C-1-9] 使用するプロビジョニング方法にかかわらず、プロビジョニング中にデバイス所有者が確定したら、デバイス所有者アプリに ACTION_ADMIN_POLICY_COMPLIANCE インテントを送信しなければなりません。デバイス所有者アプリが終了するまで、ユーザーが設定ウィザードを続行できてはなりません。
- [C-1-5] デバイスが機能フラグ
- ユーザーまたはユーザーデータがある場合、デバイス実装は:
- [C-1-7] これ以上、DPC アプリをデバイス所有者アプリとして登録してはなりません。
- ユーザーもユーザーデータも設定されていない場合、デバイス実装は:
[C-1-2] 適切な開示通知(AOSP で参照)を示し、アプリがデバイス所有者として設定される前に、エンドユーザーから明示的な同意を得なければなりません。ただし、エンドユーザーによる画面操作の前に、デバイスがプログラムによって販売店デモモードに設定されている場合を除きます。
android.software.device_admin
を宣言するだけでなく、独自のデバイス管理ソリューションも含んでいて、そのソリューションで「デバイス所有者相当」として構成されたアプリを、標準の Android DevicePolicyManager API によって認識される標準の「デバイス所有者」に昇格させるメカニズムを提供する場合、デバイス実装は:[C-2-1] 昇格された特定のアプリが正当な企業デバイス管理ソリューションに属し、独自のソリューションにより「デバイス所有者」と同等の権限を持つように構成されていることを検証するためのプロセスが定められていなければなりません。
[C-2-2] DPC アプリを「デバイス所有者」として登録する前に、
android.app.action.PROVISION_MANAGED_DEVICE
で開始されるフローと同じ AOSP デバイス所有者同意開示を示さなければなりません。[C-2-3] 同意をハードコードしたり、他のデバイス所有者アプリの使用を妨げたりしてはなりません。
3.9.1.2 管理対象プロファイルのプロビジョニング
android.software.managed_users
を宣言する場合、デバイス実装は:
[C-1-1] Device Policy Controller(DPC)アプリを新しい管理対象プロファイルの所有者にできる API を実装しなければなりません。
[C-1-2] 管理対象プロファイルのプロビジョニング プロセス(android.app.action.PROVISION_MANAGED_PROFILE を使用して DPC によって開始されるフロー)、同意画面、ユーザー エクスペリエンスは、AOSP 実装に合わせなければなりません。
[C-1-3] 特定のシステム機能が Device Policy Controller(DPC)によって無効にされたことをユーザーに示すために、設定内で次のユーザー アフォーダンスを提供しなければなりません。
- 特定の設定がデバイス管理者によって制限されている場合に表示される、一貫したアイコンまたはその他のユーザー アフォーダンス(たとえば、アップストリームの AOSP の情報アイコン)。
setShortSupportMessage
を介してデバイス管理者によって提供される、短い説明メッセージ。- DPC アプリのアイコン。
[C-1-4] android.app.action.PROVISION_MANAGED_PROFILE インテントによってプロビジョニングが開始されたときにプロファイル所有者が確定し、DPC がハンドラを実装していれば、ACTION_PROVISIONING_SUCCESSFUL インテントのハンドラを起動しなければなりません。
[C-1-5] android.app.action.PROVISION_MANAGED_PROFILE インテントによってプロビジョニングが開始されたら、ACTION_PROFILE_PROVISIONING_COMPLETE ブロードキャストを仕事用プロファイル DPC に送信しなければなりません。
[C-1-6] DPC アプリがデバイス所有者とプロファイル所有者のどちらになるか選択できるように、プロファイル所有者のプロビジョニングがトリガーされた後、ACTION_GET_PROVISIONING_MODE インテントを送信しなければなりません。ただし、インテント android.app.action.PROVISION_MANAGED_PROFILE によってプロビジョニングがトリガーされた場合を除きます。
[C-1-7] 使用するプロビジョニング方法にかかわらず、プロビジョニング中にプロファイル所有者が確定したら、ACTION_ADMIN_POLICY_COMPLIANCE インテントを仕事用プロファイルに送信しなければなりません。ただし、インテント android.app.action.PROVISION_MANAGED_PROFILE によってプロビジョニングがトリガーされた場合を除きます。プロファイル所有者アプリが終了するまで、ユーザーが設定ウィザードを続行できてはなりません。
[C-1-8] 使用するプロビジョニング方法にかかわらず、プロファイル所有者が確定したら、ACTION_MANAGED_PROFILE_PROVISIONED ブロードキャストを個人用プロファイル DPC に送信しなければなりません。
3.9.2 管理対象プロファイルのサポート
android.software.managed_users
を宣言する場合、デバイス実装は:
- [C-1-1]
android.app.admin.DevicePolicyManager
API を介して管理対象プロファイルをサポートしなければなりません。 - [C-1-2] 管理対象プロファイルを 1 つだけ作成できるようにしなければなりません。
- [C-1-3] アイコンバッジ(AOSP のアップストリームの仕事用バッジに類似)を使用して、管理対象アプリとウィジェットや、履歴と通知のような他のバッジ付き UI 要素を表さなければなりません。
- [C-1-4] 通知アイコン(AOSP のアップストリームの仕事用バッジに類似)を表示して、ユーザーが管理対象プロファイル アプリ内にいることを示さなければなりません。
- [C-1-5] デバイスが復帰(ACTION_USER_PRESENT)し、フォアグラウンド アプリが管理対象プロファイル内にある場合、ユーザーが管理対象プロファイル内にいることを示すトーストを表示しなければなりません。
- [C-1-6] 管理対象プロファイルが存在する場合、Device Policy Controller によって有効にされていれば、インテントを選択するユーザーにビジュアル アフォーダンスを表示して、ユーザーが管理対象プロファイルからプライマリ ユーザーに(またはその逆に)インテントを転送できるようにしなければなりません。
- [C-1-7] 管理対象プロファイルが存在する場合、プライマリ ユーザーと管理対象プロファイルの両方について、次のユーザー アフォーダンスを公開しなければなりません。
- プライマリ ユーザーと管理対象プロファイルの、バッテリー、位置情報、モバイルデータ、ストレージ使用量に関する個別の計算。
- プライマリ ユーザーまたは管理対象プロファイルにインストールされている VPN アプリの独立した管理。
- プライマリ ユーザーまたは管理対象プロファイルにインストールされているアプリの独立した管理。
- プライマリ ユーザーまたは管理対象プロファイル内のアカウントの独立した管理。
- [C-1-8] Device Policy Controller が許可している場合、プリインストールの電話アプリ、連絡先アプリ、メッセージ アプリが、プライマリ プロファイルからの情報とともに管理対象プロファイル(存在する場合)からの発信者情報を検索できるようにしなければなりません。
- [C-1-9] 管理対象プロファイルがプライマリ ユーザーに加えて別のユーザーとしてカウントされない場合でも、複数のユーザーが有効になっているデバイスに適用されるセキュリティ要件(セクション 9.5 参照)をすべて満たしていることを確認しなければなりません。
新しい要件の開始
- [C-1-10] スクリーンショットが、フォーカスされた
topActivity
ウィンドウ(すべてのアクティビティの中でユーザーが最後に操作したウィンドウ)でキャプチャされ、仕事用プロファイル アプリに属する場合、スクリーンショット データが仕事用プロファイル ストレージに保存されることを確認しなければなりません。 - [C-1-11] 個人用プロファイルのデータが仕事用プロファイルに保存されないようにするため、スクリーンショットを仕事用プロファイルに保存する場合は、仕事用プロファイル アプリのウィンドウを除き、他の画面コンテンツ(システムバー、通知、個人用プロファイルのコンテンツ)をキャプチャしてはなりません。
新しい要件の終了
android.software.managed_users
と android.software.secure_lock_screen
を宣言する場合、デバイス実装は:
- [C-2-1] 次の要件を満たす個別のロック画面を指定する機能をサポートして、管理対象プロファイルのみで実行されているアプリへのアクセス権を付与しなければなりません。
- デバイス実装は、
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
インテントを使用し、管理対象プロファイルの個別のロック画面認証情報を設定するインターフェースを表示しなければなりません。 - Android オープンソース プロジェクトのサイトに記載されているとおり、管理対象プロファイルのロック画面認証情報は、親プロファイルと同じ認証情報ストレージと管理メカニズムを使用しなければなりません。
- DPC パスワード ポリシーは、getParentProfileInstance によって返される
DevicePolicyManager
インスタンスで呼び出されない限り、管理対象プロファイルのロック画面認証情報にのみ適用しなければなりません。
- デバイス実装は、
- 管理対象プロファイルの連絡先が、プリインストールの通話履歴、通話 UI、通話中通知、不在着信通知、連絡先、メッセージ アプリに表示される場合、管理対象プロファイル アプリを示すために使用されるものと同じバッジを付けるべきです。
3.9.3 管理対象ユーザーのサポート
android.software.managed_users
を宣言する場合、デバイス実装は:
- [C-1-1]
isLogoutEnabled
がtrue
を返す場合、複数ユーザー セッションでは、現在のユーザーからログアウトしてプライマリ ユーザーに切り戻すユーザー アフォーダンスを提供しなければなりません。ユーザー アフォーダンスは、デバイスをロック解除せずにロック画面からアクセスできなければなりません。
android.software.device_admin
を宣言し、他のセカンダリ ユーザーを追加するオンデバイス ユーザー アフォーダンスを提供する場合、デバイス実装は:
- [C-SR-1] 新しいセカンダリ ユーザーにアカウントを追加できるようにする前に、android.app.action.PROVISION_MANAGED_DEVICE によって開始されたフローで示されたものと同じ AOSP デバイス所有者同意開示を示すことが強く推奨されます。これにより、ユーザーはデバイスが管理されていることを把握できます。
3.9.4 デバイス ポリシー管理ロールの要件
android.software.device_admin
または android.software.managed_users
をレポートする場合、デバイス実装は:
- [C-1-1] セクション 9.1 で定義されているとおり、デバイス ポリシー管理のロールをサポートしなければなりません。デバイス ポリシー管理ロールを保持するアプリは、
config_devicePolicyManagement
をパッケージ名に設定することで定義しても構いません。アプリがプリロードされていない限り、パッケージ名の後に:
と署名証明書を付けなければなりません。
config_devicePolicyManagement
のパッケージ名が上記のように定義されていない場合:
- [C-2-1] デバイス実装は、デバイス ポリシー管理のロールを保持するアプリなしでのプロビジョニングをサポートしなければなりません(AOSP がリファレンス実装を提供)。
config_devicePolicyManagement
のパッケージ名が上記のように定義されている場合:
- [C-3-1] ユーザーのすべてのプロファイルに、アプリをインストールしなければなりません。
- [C-3-2] デバイス実装は、
config_devicePolicyManagementUpdater
を設定することで、プロビジョニング前にデバイス ポリシー管理のロール保持者を更新するアプリを定義しても構いません。
config_devicePolicyManagementUpdater
のパッケージ名が上記のように定義されている場合:
- [C-4-1] アプリをデバイスにプリインストールしなければなりません。
- [C-4-2] アプリは、
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
を解決するインテント フィルタを実装しなければなりません。
新しい要件の開始
3.9.5 デバイス ポリシー解決フレームワーク
android.software.device_admin
または android.software.managed_users
をレポートする場合、デバイス実装は:
- [C-1-1] デバイス ポリシー解決フレームワークに記載されているようにデバイス ポリシーの競合を解決しなければなりません。
新しい要件の終了
3.10. ユーザー補助
Android は、障がいのあるユーザーがより簡単にデバイスを操作できるようにするためのユーザー補助レイヤを提供します。また、ユーザー補助サービスの実装によってユーザーとシステム イベントのコールバックを受信し、テキスト読み上げ、触覚フィードバック、トラックボール / D-pad ナビゲーションなどの代替フィードバック メカニズムを生成できるプラットフォーム API を提供します。
サードパーティのユーザー補助サービスをサポートする場合、デバイス実装は:
- [C-1-1] ユーザー補助 API の SDK ドキュメントに記載されているとおり、Android ユーザー補助フレームワークの実装を提供しなければなりません。
- [C-1-2] SDK に記載されているとおり、ユーザー補助イベントを生成し、登録されているすべての
AccessibilityService
実装に、適切なAccessibilityEvent
を配信しなければなりません。 - [C-1-4] AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON を宣言するユーザー補助サービスをコントロールするユーザー アフォーダンスを提供しなければなりません。なお、システム ナビゲーション バーのあるデバイス実装では、システムのナビゲーション バーのボタンで、こうしたサービスをコントロールするオプションをユーザーに認めるべきです。
プリインストールのユーザー補助サービスが含まれる場合、デバイス実装は:
- [C-2-1] データ ストレージがファイルベースの暗号化(FBE)で暗号化される場合、こうしたプリインストールのユーザー補助サービスをダイレクト ブート対応アプリとして実装しなければなりません。
- 関連するユーザー補助サービスや、フォントサイズ、ディスプレイ サイズ、拡大操作を調節するオプションをユーザーが有効にする初期設定フロー メカニズムを提供すべきです。
3.11. テキスト読み上げ
Android には、アプリがテキスト読み上げ(TTS)サービスを利用できるようにし、サービス プロバイダが TTS サービスの実装を提供できるようにする API があります。
機能 android.hardware.audio.output をレポートする場合、デバイス実装は:
- [C-1-1] Android TTS フレームワーク API をサポートしなければなりません。
サードパーティ TTS エンジンのインストールをサポートする場合、デバイス実装は:
- [C-2-1] システムレベルで使用する TTS エンジンをユーザーが選択できるようにするユーザー アフォーダンスを提供しなければなりません。
3.12. テレビ入力フレームワーク
Android テレビ入力フレームワーク(TIF)により、Android テレビデバイスへのライブ コンテンツの配信が簡単になります。TIF は、Android テレビデバイスをコントロールする入力モジュールを作成するための標準 API を提供します。
TIF をサポートする場合、デバイス実装は:
- [C-1-1] プラットフォーム機能
android.software.live_tv
を宣言しなければなりません。 - [C-1-2] TIF API とサードパーティの TIF ベースの入力サービスを使用するアプリをデバイスにインストールして使用できるように、すべての TIF API をサポートしなければなりません。
3.13. クイック設定
Android は、よく使用するアクションや緊急に必要なアクションにすばやくアクセスできるクイック設定 UI コンポーネントを提供します。
クイック設定 UI コンポーネントが含まれ、サードパーティのクイック設定をサポートする場合、デバイス実装は:
- [C-1-1] サードパーティ アプリから
quicksettings
API を通じて提供されるタイルを、ユーザーが追加または削除できるようにしなければなりません。 - [C-1-2] タイルをサードパーティ アプリからクイック設定に直接自動的に追加してはなりません。
- [C-1-3] システム提供のクイック設定タイルとともに、サードパーティ アプリからユーザーが追加したタイルをすべて表示しなければなりません。
3.14. メディア UI
デバイス実装に、MediaBrowser
または MediaSession
を介してサードパーティ アプリを操作する音声認識以外のアプリが含まれる場合、そのアプリは:
[C-1-2]
MediaDescription
に記載されているとおり、getIconBitmap() または getIconUri() を介して取得したアイコンと、getTitle() を介して取得したタイトルを、明確に表示しなければなりません。安全規則(ドライバーの注意散漫など)を遵守するためにタイトルを短縮しても構いません。[C-1-3] サードパーティ アプリが提供するコンテンツを表示する際、必ずそのサードパーティ アプリのアイコンを表示しなければなりません。
[C-1-4] ユーザーが
MediaBrowser
階層全体を操作できるようにしなければなりません。安全規則(ドライバーの注意散漫など)を遵守するために階層の一部へのアクセスを制限しても構いませんが、コンテンツまたはコンテンツ プロバイダに基づいて優先的な取り扱いをしてはなりません。[C-1-5]
KEYCODE_HEADSETHOOK
またはKEYCODE_MEDIA_PLAY_PAUSE
のダブルタップをMediaSession.Callback#onMediaButtonEvent
のKEYCODE_MEDIA_NEXT
とみなさなければなりません。
3.15. Instant Apps
デバイス実装は、Instant Apps をサポートする場合、以下の要件を満たさなければなりません。
- [C-1-1] Instant Apps には、
android:protectionLevel
が"instant"
に設定された権限のみを付与しなければなりません。 - [C-1-2] Instant Apps は、次のいずれかに該当する場合を除き、暗黙的インテントを介してインストール済みのアプリを操作してはなりません。
- コンポーネントのインテント パターン フィルタが公開されており、CATEGORY_BROWSABLE が設定されている
- アクションが、ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE のいずれかである
- ターゲットが android:visibleToInstantApps で明示的に公開されている
- [C-1-3] Instant Apps は、コンポーネントが android:visibleToInstantApps を介して公開されている場合を除き、インストール済みのアプリを明示的に操作してはなりません。
- [C-1-4] インストール済みのアプリは、Instant Apps がインストール済みのアプリに明示的に接続する場合を除き、デバイスの Instant Apps の詳細を表示してはなりません。
デバイス実装は、Instant Apps を操作するために次のユーザー アフォーダンスを提供しなければなりません。AOSP はデフォルトのシステム UI、設定、ランチャーで、この要件を満たしています。デバイス実装は:
- [C-1-5] 個々のアプリ パッケージごとにローカルにキャッシュされた Instant Apps を表示、削除するユーザー アフォーダンスを提供しなければなりません。
- [C-1-6] Instant App がフォアグラウンドで実行されている間に閉じることができる永続的なユーザー通知を提供しなければなりません。このユーザー通知は、Instant Apps がインストールを必要としないことを含まなければならず、ユーザーを設定のアプリ情報画面に誘導するユーザー アフォーダンスを提供しなければなりません。ウェブ インテントを介して起動された Instant Apps の場合、アクションが
Intent.ACTION_VIEW
に設定され、「http」または「https」のスキームを持つインテントを使用して定義されていることから、追加のユーザー アフォーダンスでは、ユーザーが Instant App を起動できず、デバイスでブラウザを利用できるのであれば、設定済みのウェブブラウザで関連リンクを起動できるようにすべきです。 - [C-1-7] デバイスで履歴機能が利用可能な場合、実行中の Instant Apps に履歴機能からアクセスできるようにしなければなりません。
[C-1-8] こちらの SDK に記載されているインテントのインテント ハンドラで 1 つ以上のアプリまたはサービス コンポーネントをプリロードし、インテントを Instant Apps で表示しなければなりません。
3.16. コンパニオン デバイスのペア設定
Android では、コンパニオン デバイスのペア設定をサポートしてコンパニオン デバイスとの関連付けを効果的に管理できるようになっており、アプリでこの機能にアクセスするための CompanionDeviceManager
API が提供されています。
コンパニオン デバイスのペア設定機能をサポートする場合、デバイス実装は:
- [C-1-1]
FEATURE_COMPANION_DEVICE_SETUP
機能フラグを宣言しなければなりません。 - [C-1-2]
android.companion
パッケージの API が完全に実装されるようにしなければなりません。 - [C-1-3] コンパニオン デバイスがあり動作可能であることをユーザーが選択 / 確認するユーザー アフォーダンスを提供しなければなりません。
3.17. 重いアプリ
機能 FEATURE_CANT_SAVE_STATE
を宣言する場合、デバイス実装は:
- [C-1-1] インストール済みのアプリで
cantSaveState
が指定されている場合、システムで一度に実行するのは 1 つだけにしなければなりません。ユーザーがそのようなアプリを明示的に終了せずに離れる場合(たとえば、システムにアクティブなアクティビティが残っていない状態で戻るボタンを押すのではなく、システムにアクティブなアクティビティを残したままホームボタンを押すことで離れる場合)、デバイス実装は、フォアグラウンド サービスなど、動作し続けることが想定されるサービスと同様に、そのアプリを RAM 内で優先しなければなりません。そのようなアプリがバックグラウンドにあっても、システムは引き続き、CPU やネットワーク アクセスの制限などの電源管理機能を適用できます。 - [C-1-2]
cantSaveState
属性で宣言された第 2 のアプリをユーザーが起動した後、通常の状態保存 / 復元メカニズムに加わらないアプリを選択する UI アフォーダンスを提供しなければなりません。 - [C-1-3] CPU パフォーマンスの変更やスケジュール設定の優先順位の変更など、
cantSaveState
を指定するアプリに対して他のポリシー変更を適用してはなりません。
機能 FEATURE_CANT_SAVE_STATE
を宣言しない場合、デバイス実装は:
- [C-1-1] アプリによって設定された
cantSaveState
属性を無視しなければならず、この属性に基づいてアプリの動作を変更してはなりません。
3.18. 連絡先
Android には、デバイスに保存された連絡先情報をアプリが管理できるようにする Contacts Provider
API があります。通常、デバイスに直接入力された連絡先データはウェブサービスと同期されますが、データはデバイスにローカルに配置されるだけでも構いません。デバイスに保存されるだけの連絡先のことを、ローカルの連絡先といいます。
ACCOUNT_NAME
列と ACCOUNT_TYPE
列が、アカウントの対応する Account.name フィールドと Account.type フィールドに一致する場合、RawContacts は Account に関連付けられるか、保存されます。
デフォルト ローカル アカウント: デバイスにのみ保存される、AccountManager のアカウントに関連付けられていない未加工連絡先のアカウントであって、ACCOUNT_NAME
列と ACCOUNT_TYPE
列が null 値の場合に作成されるもの。
カスタム ローカル アカウント: デバイスにのみ保存される、AccountManager のアカウントに関連付けられていない未加工連絡先のアカウントであって、ACCOUNT_NAME
列と ACCOUNT_TYPE
列の少なくとも 1 つが非 null 値の場合に作成されるもの。
デバイス実装は:
- [C-SR-1] カスタム ローカル アカウントを作成しないことが強く推奨されます。
デバイス実装がカスタム ローカル アカウントを使用する場合:
- [C-1-1] カスタム ローカル アカウントの
ACCOUNT_NAME
が、ContactsContract.RawContacts.getLocalAccountName
によって返さなければなりません。 - [C-1-2] カスタム ローカル アカウントの
ACCOUNT_TYPE
が、ContactsContract.RawContacts.getLocalAccountType
によって返さなければなりません。 - [C-1-3] デフォルト ローカル アカウントでサードパーティ アプリによって挿入される(
ACCOUNT_NAME
とACCOUNT_TYPE
に null 値を設定することで挿入される)未加工連絡先は、カスタム ローカル アカウントに挿入されなければなりません。 - [C-1-4] カスタム ローカル アカウントに挿入された未加工連絡先は、アカウントが追加または削除されたときに削除されてはなりません。
- [C-1-5] カスタム ローカル アカウントに対して行われた削除操作では、
CALLER\_IS\_SYNCADAPTER
パラメータが false に設定されているか指定されていない場合であっても、未加工連絡先がすぐに削除されなければなりません(CALLER_IS_SYNCADAPTER
パラメータが true に設定されている場合と同様に削除されなければなりません)。
4. アプリ パッケージの互換性
デバイス実装は:
[C-0-1] 公式の Android SDK に含まれる「aapt」ツールによって生成された Android「.apk」ファイルをインストールして実行できなければなりません。
- 上記の要件が難しい場合もあるため、デバイス実装は、AOSP リファレンス実装のパッケージ管理システムを使用することが推奨されます。
[C-0-2] APK 署名スキーム v3.1、APK 署名スキーム v3、APK 署名スキーム v2、JAR 署名を使用した「.apk」ファイルの検証をサポートしなければなりません。
[C-0-3] .apk、Android マニフェスト、Dalvik バイトコード、RenderScript バイトコードのいずれかの形式を、他の互換デバイスでファイルのインストールと実行が正しく行われないような方法で拡張してはなりません。
[C-0-4]
DELETE_PACKAGE
権限の SDK に記載されているとおり、パッケージの現在の「レコードのインストーラ」以外のアプリが、ユーザーの確認なしで通知せずにアプリをアンインストールできるようにしてはなりません。例外は、PACKAGE_NEEDS_VERIFICATION インテントを処理するシステム パッケージ検証アプリと、ACTION_MANAGE_STORAGE インテントを処理するストレージ管理アプリです。[C-0-5]
android.settings.MANAGE_UNKNOWN_APP_SOURCES
インテントを処理するアクティビティがなければなりません。[C-0-6] インストールをリクエストするアプリが次の要件をすべて満たす場合を除き、提供元不明のアプリ パッケージをインストールしてはなりません。
REQUEST_INSTALL_PACKAGES
権限を宣言するか、android:targetSdkVersion
を 24 以下に設定しなければなりません。- ユーザーによって、提供元不明のアプリをインストールする権限が付与されていなければなりません。
提供元不明のアプリをインストールする権限をアプリごとに付与する / 取り消すユーザー アフォーダンスを提供すべきですが、デバイス実装でユーザーにこの選択を許可しない場合、これを NoOps として実装し、
startActivityForResult()
についてRESULT_CANCELED
を返すことにしても構いません。ただし、そのような場合であっても、そうした選択が提示されない理由をユーザーに示すべきです。[C-0-7] システム API
PackageManager.setHarmfulAppWarning
によって有害な可能性があるとマークされたアプリでアクティビティを起動する前に、同じシステム APIPackageManager.setHarmfulAppWarning
を通じて提供される警告文字列による警告ダイアログを表示しなければなりません。警告ダイアログで、アプリをアンインストールするか起動するかを選択するユーザー アフォーダンスを提供すべきです。
[C-0-8] こちらに記載されているとおり、増分ファイル システムのサポートを実装しなければなりません。
[C-0-9] APK 署名スキーム v4 と APK 署名スキーム v4.1 を使用した .apk ファイルの検証をサポートしなければなりません。
5. マルチメディアの互換性
デバイス実装は:
- [C-0-1]
MediaCodecList
で宣言された各コーデックすべてについて、セクション 5.1 で規定するメディア形式、エンコーダ、デコーダ、ファイル形式、コンテナ形式をサポートしなければなりません。 - [C-0-2]
MediaCodecList
を介してサードパーティ アプリが利用できるエンコーダ、デコーダのサポートを宣言し、レポートしなければなりません。 - [C-0-3] 適切にデコードできなければならず、エンコード可能なすべての形式をサードパーティ アプリが利用できるようにしなければなりません。これには、エンコーダが生成するすべてのビットストリームと、
CamcorderProfile
でレポートされるプロファイルが含まれます。
デバイス実装は:
- コーデック遅延を最小限に抑えるべきです。つまり
- 入力バッファを消費、保存すべきでなく、1 回処理されただけで入力バッファを返すべきではありません。
- デコードされたバッファを、標準(例: SPS)で指定されているよりも長く保持すべきではありません。
- エンコードされたバッファを、GOP 構造が必要とするよりも長く保持すべきではありません。
以下のセクションに記載されているコーデックはすべて、Android オープンソース プロジェクトの推奨 Android 実装でソフトウェア実装として提供されています。
Google もオープン ハンドセット アライアンスも、これらのコーデックにサードパーティの特許がないことを表明しているわけではないことにご注意ください。オープンソース ソフトウェアまたはシェアウェアを含め、このソースコードをハードウェアまたはソフトウェア製品で使用する場合は、このコードの実装に関連する特許権者からの特許ライセンスが必要になることがあります。
5.1. メディア コーデック
5.1.1. オーディオ エンコード
詳細については 5.1.3. オーディオ コーデックの詳細をご覧ください。
android.hardware.microphone
を宣言する場合、デバイス実装は、次のオーディオ形式のエンコードをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
オーディオ エンコーダはすべて、下記をサポートしなければなりません。
- [C-3-1]
android.media.MediaCodec
API を介した PCM 16 ビット ネイティブ バイトオーダーのオーディオ フレーム。
5.1.2. オーディオ デコード
詳細については 5.1.3. オーディオ コーデックの詳細をご覧ください。
android.hardware.audio.output
機能のサポートを宣言する場合、デバイス実装は、次のオーディオ形式のデコードをサポートしなければなりません。
- [C-1-1] MPEG-4 AAC プロファイル(AAC LC)
- [C-1-2] MPEG-4 HE AAC プロファイル(AAC+)
- [C-1-3] MPEG-4 HE AACv2 プロファイル(Enhanced AAC+)
- [C-1-4] AAC ELD(Enhanced Low Delay AAC)
- [C-1-11] xHE-AAC(USAC ベースライン プロファイルを含む ISO/IEC 23003-3 Extended HE AAC プロファイル、ISO/IEC 23003-4 Dynamic Range Control プロファイル)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] 24 ビット、サンプルレート 192 kHz、8 チャンネルまでのハイレゾリューション オーディオ形式を含む、PCM/WAVE。なお、この要件はデコード向けに限られ、デバイスには再生フェーズ中のダウンサンプルとダウンミックスが許可されます。
- [C-1-10] Opus
デバイス実装が、android.media.MediaCodec
API のデフォルト AAC オーディオ デコーダを通じて PCM へのマルチチャンネル ストリーム(2 チャンネル以上)の AAC 入力バッファのデコードをサポートする場合、下記をサポートしなければなりません。
- [C-2-1] デコードは、ダウンミックスせずに行わなければなりません(たとえば、5.0 AAC ストリームは 5 チャンネルの PCM にデコードされなければならず、5.1 AAC ストリームは 6 チャンネルの PCM にデコードされなければなりません)。
- [C-2-2] ダイナミック レンジ メタデータは、ISO/IEC 14496-3 の「Dynamic Range Control(DRC)」と、オーディオ デコーダのダイナミック レンジ関連の動作を構成するための
android.media.MediaFormat
DRC キーで定義されているとおりでなければなりません。AAC DRC キーはKEY_AAC_DRC_ATTENUATION_FACTOR
、KEY_AAC_DRC_BOOST_FACTOR
、KEY_AAC_DRC_HEAVY_COMPRESSION
、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
、KEY_AAC_ENCODED_TARGET_LEVEL
であり、API 21 で導入されました。 - [C-SR-1] 上記の要件 C-2-1 と C-2-2 を、すべての AAC オーディオ デコーダで満たすことが強く推奨されます。
USAC オーディオをデコードするとき、MPEG-D(ISO/IEC 23003-4)は:
- [C-3-1] ラウドネスと DRC メタデータは、MPEG-D DRC Dynamic Range Control プロファイル レベル 1 に従って解釈し、適用しなければなりません。
- [C-3-2] デコーダは、
android.media.MediaFormat
キー(KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
とKEY_AAC_DRC_EFFECT_TYPE
)で設定した構成に従って動作しなければなりません。
MPEG-4 AAC、HE AAC、HE AACv2 プロファイルのデコーダは:
- ISO/IEC 23003-4 Dynamic Range Control プロファイルを使用した、ラウドネスとダイナミック レンジ コントロールをサポートしても構いません。
ISO/IEC 23003-4 がサポートされている場合であって、デコードされたビットストリームに ISO/IEC 23003-4 と ISO/IEC 14496-3 の両方のメタデータが存在する場合:
- ISO/IEC 23003-4 メタデータが優先されるものとします。
オーディオ デコーダはすべて、次の出力をサポートしなければなりません。
- [C-6-1]
android.media.MediaCodec
API を介した PCM 16 ビット ネイティブ バイトオーダーのオーディオ フレーム。
デバイス実装が、android.media.MediaCodec
API のデフォルト AAC オーディオ デコーダを通じて PCM へのマルチチャンネル ストリーム(2 チャンネル以上)の AAC 入力バッファのデコードをサポートする場合、下記をサポートしなければなりません。
- [C-7-1] コンテンツをステレオにダウンミックスするか(値 2 を使用する場合)ネイティブ チャンネル数を使用して出力するか(その数以上の値を使用する場合)を制御するために、鍵
KEY_MAX_OUTPUT_CHANNEL_COUNT
によるデコードを使用してアプリで設定できなければなりません。たとえば、値を 6 以上に設定すると、5.1 のコンテンツを供給する際に 6 つのチャンネルを出力するようにデコーダを設定できます。 - [C-7-2] デコーダはデコード時に、
android.media.AudioFormat
定数(例:CHANNEL_OUT_5POINT1
)を使用して、KEY_CHANNEL_MASK
鍵での出力形式で使用されるチャンネル マスクをアドバタイズしなければなりません。
デバイス実装が、デフォルトの AAC オーディオ デコーダ以外のオーディオ デコーダをサポートし、圧縮されたマルチチャンネル コンテンツを供給する際にマルチチャンネル オーディオ(2 チャンネルを超えるオーディオ)を出力できる場合:
- [C-SR-2] デコーダは、コンテンツをステレオにダウンミックスするか(値 2 を使用する場合)ネイティブ チャンネル数を使用して出力するか(その数以上の値を使用する場合)を制御するために、鍵
KEY_MAX_OUTPUT_CHANNEL_COUNT
によるデコードを使用してアプリで設定できるようにすることを強く推奨します。たとえば、値を 6 以上に設定すると、5.1 のコンテンツを供給する際に 6 つのチャンネルを出力するようにデコーダを設定できます。 - [C-SR-3] デコーダはデコード時に、android.media.AudioFormat 定数(例:
CHANNEL_OUT_5POINT1
)を使用して、KEY_CHANNEL_MASK
鍵での出力形式で使用されるチャンネル マスクをアドバタイズすることが強く推奨されます。
5.1.3. オーディオ コーデックの詳細
形式 / コーデック | 詳細 | サポートされるファイル形式 / コンテナ形式 |
---|---|---|
MPEG-4 AAC プロファイル (AAC LC) |
標準サンプリング レート 8~48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。 |
|
MPEG-4 HE AAC プロファイル(AAC+) | 標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。 |
|
MPEG-4 HE AACv2 プロファイル(Enhanced AAC+) |
標準サンプリング レート 16~48 kHz のモノラル / ステレオ / 5.0 / 5.1 コンテンツをサポート。 |
|
AAC-ELD(Enhanced Low Delay AAC) | 標準サンプリング レート 16~48 kHz のモノラル / ステレオ コンテンツをサポート。 |
|
USAC | 標準サンプリング レート 7.35~48 kHz のモノラル / ステレオ コンテンツをサポート。 | MPEG-4(.mp4、.m4a) |
AMR-NB | 8 kHz でサンプリングされた 4.75~12.2 kbps | 3GPP(.3gp) |
AMR-WB | 16 kHz でサンプリングされた、6.60 kbit/s~23.85 kbit/s の 9 種類のレート(AMR-WB、Adaptive Multi-Rate - Wideband Speech Codec で定義) | 3GPP(.3gp) |
FLAC | エンコーダとデコーダの両方について: 少なくともモノラルモードとステレオモードをサポートしなければなりません。192 kHz までのサンプルレートをサポートしなければなりません。16 ビットと 24 ビットの解像度をサポートしなければなりません。FLAC 24 ビット オーディオ データ処理が浮動小数点オーディオ構成で利用できなければなりません。 |
|
MP3 | モノラル / ステレオの 8~320 Kbps 固定ビットレート(CBR)または可変ビットレート(VBR) |
|
MIDI | MIDI タイプ 0 と 1。DLS バージョン 1 と 2。XMF と Mobile XMF。着信音形式 RTTTL/RTX、OTA、iMelody をサポート。 |
|
Vorbis | デコード: サンプリング レート 8,000、12,000、16,000、24,000、48,000 Hz のモノラル、ステレオ、5.0、5.1 のコンテンツをサポート。 エンコード: サンプリング レート 8,000、12,000、16,000、24,000、48,000 Hz のモノラル、ステレオのコンテンツをサポート。 |
|
PCM(WAVE) | PCM コーデックは 16 ビットのリニア PCM と 16 ビット浮動小数点をサポートしなければなりません。WAVE エクストラクタは 16 ビット、24 ビット、32 ビットのリニア PCM と 32 ビット浮動小数点をサポートしなければなりません(最大レートはハードウェアの上限値)。サンプリング レートは 8 kHz から 192 kHz までをサポートしなければなりません。 | WAVE(.wav) |
Opus | デコード: サンプリング レート 8,000、12,000、16,000、24,000、48,000 Hz のモノラル、ステレオ、5.0、5.1 のコンテンツをサポート。 エンコード: サンプリング レート 8,000、12,000、16,000、24,000、48,000 Hz のモノラル、ステレオのコンテンツをサポート。 |
|
5.1.4. 画像のエンコード
詳細については、5.1.6. 画像コーデックの詳細をご覧ください。
デバイス実装は、次の画像エンコードのエンコードをサポートしなければなりません。
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
新しい要件の開始
- [C-0-4] AVIF
- デバイスは、
BITRATE_MODE_CQ
とベースライン プロファイルをサポートしなければなりません。
- デバイスは、
新しい要件の終了
メディアタイプ MIMETYPE_IMAGE_ANDROID_HEIC
の android.media.MediaCodec
を介して HEIC エンコードをサポートする場合、デバイス実装は:
- [C-1-1]
BITRATE_MODE_CQ
ビットレート コントロール モード、HEVCProfileMainStill
プロファイル、512 x 512 px フレームサイズをサポートするハードウェア アクセラレーテッド HEVC エンコーダ コーデックを提供しなければなりません。
5.1.5. 画像のデコード
詳細については、5.1.6. 画像コーデックの詳細をご覧ください。
デバイス実装は、次の画像エンコードのデコードをサポートしなければなりません。
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] Raw
- [C-0-7] AVIF(ベースライン プロファイル)
HEVC 動画デコードをサポートする場合、デバイス実装は: * [C-1-1] HEIF(HEIC)画像デコードをサポートしなければなりません。
高ビット深度形式(チャンネルあたり 9 ビット以上)をサポートする画像デコーダ
- [C-2-1] アプリが、たとえば
android.graphics.Bitmap
のARGB_8888
設定を介してリクエストする場合、8 ビット相当の形式の出力をサポートしなければなりません。
5.1.6. 画像コーデックの詳細
形式 / コーデック | 詳細 | サポートされているファイル形式 / コンテナ形式 |
---|---|---|
JPEG | ベースラインとプログレッシブ | JPEG(.jpg) |
GIF | GIF(.gif) | |
PNG | PNG(.png) | |
BMP | BMP(.bmp) | |
WebP | WebP(.webp) | |
Raw | ARW(.arw)、CR2(.cr2)、DNG(.dng)、NEF(.nef)、NRW(.nrw)、ORF(.orf)、PEF(.pef)、RAF(.raf)、RW2(.rw2)、SRW(.srw) | |
HEIF | 画像、画像コレクション、画像シーケンス | HEIF(.heif)、HEIC(.heic) |
AVIF(ベースライン プロファイル) | 画像、画像コレクション、画像シーケンスのベースライン プロファイル | HEIF コンテナ(.avif) |
MediaCodec API を通じて公開される画像エンコーダとデコーダ
[C-1-1]
CodecCapabilities
を通じて YUV420 8:8:8 フレキシブル カラー形式(COLOR_FormatYUV420Flexible
)をサポートしなければなりません。[C-SR-1] 入力サーフェス モードで RGB888 カラー形式をサポートすることが強く推奨されます。
[C-1-3] 少なくとも Planar または SemiPlanar いずれかの YUV420 8:8:8 カラー形式をサポートしなければなりません:
COLOR_FormatYUV420PackedPlanar
(COLOR_FormatYUV420Planar
相当)またはCOLOR_FormatYUV420PackedSemiPlanar
(COLOR_FormatYUV420SemiPlanar
相当)。両方をサポートすることが強く推奨されます。
5.1.7. 動画コーデック
- ウェブ動画ストリーミング サービスとビデオ会議サービスの品質を許容可能なものにするために、デバイス実装は、要件を満たすハードウェア VP8 コーデックを使用すべきです。
デバイス実装に動画デコーダまたはエンコーダが含まれる場合:
[C-1-1] 動画コーデックは、標準と設定で規定されているとおり、実現可能な最大の圧縮フレームと非圧縮フレームに対応する入出力バイトバッファ サイズをサポートしなければなりませんが、過剰に割り当ててはなりません。
[C-1-2] 動画エンコーダとデコーダは、
CodecCapabilities
を通じて YUV420 8:8:8 フレキシブル カラー形式(COLOR_FormatYUV420Flexible
)をサポートしなければなりません。[C-1-3] 動画エンコーダとデコーダは、少なくとも Planar または SemiPlanar いずれかの YUV420 8:8:8 カラー形式をサポートしなければなりません:
COLOR_FormatYUV420PackedPlanar
(COLOR_FormatYUV420Planar
相当)またはCOLOR_FormatYUV420PackedSemiPlanar
(COLOR_FormatYUV420SemiPlanar
相当)。両方をサポートすることが強く推奨されます。[C-SR-1] 動画エンコーダとデコーダは、ハードウェアに最適化された少なくとも Planar または SemiPlanar いずれかの YUV420 8:8:8 カラー形式をサポートすることが強く推奨されます(YV12、NV12、NV21、またはベンダーに最適化された同等の形式)。
[C-1-5] 高ビット深度形式(チャンネルあたり 9 ビット以上)をサポートする動画デコーダは、アプリがリクエストする場合、8 ビット相当の形式の出力をサポートしなければなりません。これは、
android.media.MediaCodecInfo
を介して YUV420 8:8:8 カラー形式をサポートすることで反映されなければなりません。
Display.HdrCapabilities
を通じて HDR プロファイルのサポートをアドバタイズする場合、デバイス実装は:
- [C-2-1] HDR 静的メタデータの解析と処理をサポートしなければなりません。
MediaCodecInfo.CodecCapabilities
クラスの FEATURE_IntraRefresh
を通じてイントラ更新のサポートをアドバタイズする場合、デバイス実装は:
- [C-3-1] 更新周期 10~60 フレームをサポートし、設定した更新周期の 20% 以内で正確に動作しなければなりません。
アプリが KEY_COLOR_FORMAT
形式キーを使用して別の指定をする場合を除き、動画デコーダ実装は:
- [C-4-1] サーフェス出力を使用して構成されている場合、デフォルトでハードウェア ディスプレイ用に最適化されたカラー形式にしなければなりません。
- [C-4-2] サーフェス出力を使用しないように構成されている場合、デフォルトで CPU 読み込み用に最適化された YUV420 8:8:8 カラー形式にしなければなりません。
5.1.8. 動画コーデックのリスト
形式 / コーデック | 詳細 | サポートされるファイル形式 / コンテナ形式 |
---|---|---|
H.263 |
|
|
H.264 AVC | 詳細についてはセクション 5.2 と 5.3 をご覧ください |
|
H.265 HEVC | 詳細についてはセクション 5.3 をご覧ください |
|
MPEG-2 | メイン プロファイル |
|
MPEG-4 SP |
|
|
VP8 | 詳細についてはセクション 5.2 と 5.3 をご覧ください |
|
VP9 | 詳細についてはセクション 5.3 をご覧ください |
|
AV1 | 詳細についてはセクション 5.2 とセクション 5.3 をご覧ください |
|
5.1.9. メディア コーデックのセキュリティ
デバイス実装は、下記のとおり、メディア コーデックのセキュリティ機能に確実に準拠しなければなりません。
Android は、クロス プラットフォームのマルチメディア アクセラレーション API である OMX と、低オーバーヘッド マルチメディア アクセラレーション API である Codec 2.0 をサポートしています。
マルチメディアをサポートする場合、デバイス実装は:
- [C-1-1] Android オープンソース プロジェクトにあるように、OMX または Codec 2.0 API のいずれか(あるいは両方)を介してメディア コーデックのサポートを提供しなければならず、セキュリティ保護を無効化または回避してはなりません。具体的には、これはすべてのコーデックが OMX または Codec 2.0 API のいずれかを使用しなければならないということではなく、これらの API の少なくとも 1 つのサポートが利用可能でなければならず、利用可能な API のサポートは、存在するセキュリティ保護を含まなければならないということです。
- [C-SR-1] Codec 2.0 API のサポートを含むことが強く推奨されます。
Codec 2.0 API をサポートしない場合、デバイス実装は:
- [C-2-1] デバイスでサポートされているメディア形式とタイプ(エンコーダまたはデコーダ)ごとに、Android オープンソース プロジェクトの対応する OMX ソフトウェア コーデック(利用可能な場合)を含まなければなりません。
- [C-2-2] 名前が「OMX.google」で始まるコーデックは、Android オープンソース プロジェクトのソースコードに基づいていなければなりません。
- [C-SR-2] OMX ソフトウェア コーデックを、メモリマッパー以外のハードウェア ドライバにアクセスできないコーデック プロセスで実行することが強く推奨されます。
Codec 2.0 API をサポートする場合、デバイス実装は:
- [C-3-1] デバイスでサポートされているメディア形式とタイプ(エンコーダまたはデコーダ)ごとに、Android オープンソース プロジェクトの対応する Codec 2.0 ソフトウェア コーデック(利用可能な場合)を含まなければなりません。
- [C-3-2] Android オープンソース プロジェクトで提供されているように、Codec 2.0 ソフトウェア コーデックをソフトウェア コーデック プロセスに含めて、ソフトウェア コーデックへのアクセス権付与をより狭い範囲で行えるようにしなければなりません。
- [C-3-3] 名前が「c2.android.」で始まるコーデックは、Android オープンソース プロジェクトのソースコードに基づいていなければなりません。
5.1.10. メディア コーデックの特性
メディア コーデックをサポートする場合、デバイス実装は:
- [C-1-1]
MediaCodecInfo
API を介して、メディア コーデックの正しい特性値を返さなければなりません。
具体的には、次のとおりです。
- [C-1-2] 名前が「OMX.」で始まるコーデックは、OMX API を使用し、OMX IL 命名ガイドラインに沿った名前でなければなりません。
- [C-1-3] 名前が「c2.」で始まるコーデックは、Codec 2.0 API を使用し、Android の Codec 2.0 命名ガイドラインに沿った名前でなければなりません。
- [C-1-4] 名前が「OMX.google.」または「c2.android.」で始まるコーデックは、ベンダーまたはハードウェア アクセラレーションによるものとされてはなりません。
- [C-1-5] メモリ アロケータとメモリマッパー以外のハードウェア ドライバにアクセスできるコーデック プロセス(ベンダーまたはシステム)で実行されるコーデックは、ソフトウェアのみとされてはなりません。
- [C-1-6] Android オープンソース プロジェクトに存在しないか、そのソースコードに基づいていないコーデックは、ベンダーによるものとされなければなりません。
- [C-1-7] ハードウェア アクセラレーションを利用するコーデックは、ハードウェア アクセラレーションによるものとされなければなりません。
- [C-1-8] コーデック名は、誤解を招きやすいものであってはなりません。たとえば、名前が「decoders」のコーデックはデコードをサポートしなければならず、名前が「encoders」のコーデックはエンコードをサポートしなければなりません。名前にメディア形式を含むコーデックは、その形式をサポートしなければなりません。
デバイス実装が動画コーデックをサポートする場合:
- [C-2-1] 動画コーデックはすべて、コーデックがサポートしている場合、次のサイズの達成可能なフレームレート データを公開しなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
動画の解像度 |
|
|
|
1,920 x 1,080 px(MPEG4 以外、AV1) | 3,840 x 2,160 px(HEVC、VP9、AV1) |
- [C-2-2] ハードウェア アクセラレーションによるものとされた動画コーデックは、パフォーマンス ポイント情報を公開しなければなりません。これらのコーデックは、サポート対象の別の標準パフォーマンス ポイントでカバーされている場合を除き、サポート対象のすべての標準パフォーマンス ポイント(
PerformancePoint
API に記載)をそれぞれリストしなければなりません。 - さらに、リストされた標準的なもの以外の持続的な動画パフォーマンスをサポートする場合、拡張パフォーマンス ポイントを公開すべきです。
5.2. 動画のエンコード
- 2 つのスライディング ウィンドウで、イントラフレーム(I フレーム)間隔のビットレートが 15% を超えるべきではありません。
- 1 秒のスライディング ウィンドウで、ビットレートが 100% を超えるべきではありません。
新しい要件の開始
デバイス実装が動画エンコーダをサポートし、サードパーティ アプリで利用でき、MediaFormat.KEY_BITRATE_MODE
を BITRATE_MODE_VBR
に設定してエンコーダが可変ビットレート モードで動作する場合、最低限の品質基準に影響しない限り、エンコード結果のビットレートは:
[C-5-1]1 つのスライディング ウィンドウで、イントラフレーム(I フレーム)間隔のビットレートが 15% を超えるべきではありません。[C-5-2]1 秒のスライディング ウィンドウで、ビットレートが 100% を超えるべきではありません。
デバイス実装が動画エンコーダをサポートし、サードパーティ アプリで利用でき、MediaFormat.KEY_BITRATE_MODE
を BITRATE_MODE_CBR
に設定してエンコーダが固定ビットレート モードで動作する場合、エンコード結果のビットレートは:
[C-6-1][C-SR-2] 1 秒のスライディング ウィンドウでターゲット ビットレートを 15% 以上超えないことが強く推奨されます。
新しい要件の終了
対角長が 2.5 インチ以上の埋め込みスクリーン ディスプレイか、動画出力ポートが含まれる場合、または android.hardware.camera.any
機能フラグを介してカメラのサポートを宣言する場合、デバイス実装は:
- [C-1-1] VP8 または H.264 動画エンコーダのいずれかをサポートし、サードパーティ アプリで利用できるようにしなければなりません。
- VP8 と H.264 の両方の動画エンコーダをサポートし、サードパーティ アプリで利用できるようにすべきです。
H.264、VP8、VP9、HEVC 動画エンコーダのいずれかをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:
- [C-2-1] 動的に設定可能なビットレートをサポートしなければなりません。
- 可変フレームレートをサポートすべきです。ここで動画エンコーダは、入力バッファのタイムスタンプに基づいて瞬間的なフレーム持続時間を求め、そのフレーム持続時間に基づいてビットバケットを割り当てるべきです。
MPEG-4 SP 動画エンコーダをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:
- サポート対象のエンコーダの動的に設定可能なビットレートをサポートすべきです。
デバイス実装がハードウェア アクセラレーションの動画エンコーダまたは画像エンコーダを提供し、android.camera
API を介して公開される接続されているかプラグイン可能なハードウェア カメラを 1 つ以上サポートする場合:
- [C-4-1] ハードウェア アクセラレーションの動画エンコーダと画像エンコーダはすべて、ハードウェア カメラからのフレームのエンコードをサポートしなければなりません。
- すべての動画エンコーダまたは画像エンコーダを通じて、ハードウェア カメラからのフレームのエンコードをサポートすべきです。
HDR エンコードを提供する場合、デバイス実装は:
- [C-SR-1] HDR 形式から SDR 形式に変換するシームレスなコード変換 API のプラグインを提供することが強く推奨されます。
5.2.1. H.263
H.263 エンコーダをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:
- [C-1-1] ベースライン プロファイル レベル 45 を使用して QCIF 解像度(176 x 144)をサポートしなければなりません。SQCIF 解像度は省略可能です。
サポート対象のエンコーダの動的に設定可能なビットレートをサポートすべきです。
5.2.2. H.264
H.264 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] ベースライン プロファイル レベル 3 をサポートしなければなりません。ただし、ASO(Arbitrary Slice Ordering)、FMO(Flexible Macroblock Ordering)、RS(Redundant Slices)のサポートは任意です。さらに、他の Android デバイスとの互換性を維持するために、エンコーダでベースライン プロファイルに ASO、FMO、RS を使用しないことが推奨されます。
- [C-1-2] 下表の SD(標準画質)動画エンコード プロファイルをサポートしなければなりません。
- メイン プロファイル レベル 4 をサポートすべきです。
- 下表に示すとおり、HD(高画質)動画エンコード プロファイルをサポートすべきです。
メディア API を通じて解像度が 720p または 1080p である動画の H.264 エンコードのサポートをレポートする場合、デバイス実装は:
- [C-2-1] 下表のエンコード プロファイルをサポートしなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | |
---|---|---|---|---|
動画の解像度 | 320 x 240 px | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px |
動画のフレームレート | 20 fps | 30 fps | 30 fps | 30 fps |
動画のビットレート | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3. VP8
VP8 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] SD 動画エンコード プロファイルをサポートしなければなりません。
- 次の HD(高画質)動画エンコード プロファイルをサポートすべきです。
- [C-1-2] Matroska WebM ファイルの書き込みをサポートしなければなりません。
- ウェブ動画配信サービスとビデオ会議サービスの質を許容可能なものにするために、WebM プロジェクトの RTC ハードウェア コーディング要件を満たすハードウェア VP8 コーデックを提供すべきです。
メディア API を通じて解像度が 720p または 1080p である動画の VP8 エンコードのサポートをレポートする場合、デバイス実装は:
- [C-2-1] 下表のエンコード プロファイルをサポートしなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | |
---|---|---|---|---|
動画の解像度 | 320 x 180 ピクセル | 640 x 360 ピクセル | 1,280 x 720 ピクセル | 1,920 x 1,080 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 fps |
動画のビットレート | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4. VP9
VP9 コーデックをサポートする場合、デバイス実装は:
- [C-1-2] プロファイル 0 レベル 3 をサポートしなければなりません。
- [C-1-1] Matroska WebM ファイルの書き込みをサポートしなければなりません。
- [C-1-3] CodecPrivate データを生成しなければなりません。
- 下表に示すとおり、HD デコード プロファイルをサポートすべきです。
- [C-SR-1] ハードウェア エンコーダがある場合、下表に示すとおり、HD デコード プロファイルをサポートすることが強く推奨されます。
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
動画の解像度 | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px | 3,840 x 2,160 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 fps |
動画のビットレート | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
メディア API を通じてプロファイル 2 またはプロファイル 3 をサポートすることを主張する場合、デバイス実装は:
- 12 ビット形式のサポートは任意です。
5.2.5. H.265
H.265 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] メイン プロファイル レベル 3 と最大 512 x 512 の解像度をサポートしなければなりません。
下表に示すとおり、HD エンコード プロファイルをサポートすべきです。- [C-SR-1] ハードウェア エンコーダがある場合、下表に示すとおり、720 x 480 SD プロファイルと HD エンコード プロファイルをサポートすることが強く推奨されます。
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
動画の解像度 | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px | 3,840 x 2,160 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 fps |
動画のビットレート | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
新しい要件の開始
5.2.6. AV1
AV1 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] 8 ビットと 10 ビットのコンテンツを含め、メイン プロファイルをサポートしなければなりません。
[C-1-2] 下表に示すサポート対象の解像度について、パフォーマンス データを公開、つまり、
getSupportedFrameRatesFor()
API またはgetSupportedPerformancePoints()
API を介してパフォーマンス データをレポートしなければなりません。[C-1-3] HDR メタデータを受け入れ、ビットストリームに出力しなければなりません。
ハードウェア アクセラレーションを使用している場合、AV1 エンコーダは:
- [C-2-1] 下表に示す HD 1080p のエンコード プロファイルまでサポートしなければなりません。
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
動画の解像度 | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px | 3,840 x 2,160 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 fps |
動画のビットレート | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
新しい要件の終了
5.3. 動画のデコード
VP8、VP9、H.264 または H.265 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] VP8、VP9、H.264、H.265 のすべてのコーデックについて、デバイスで各コーデックがサポートする最大解像度まで、同じストリーム内で標準の Android API を通じて、動的な動画解像度とフレームレートの切り替えをサポートしなければなりません。
5.3.1. MPEG-2
MPEG-2 デコーダをサポートする場合、デバイス実装は:
- [C-1-1] メイン プロファイル ハイレベルをサポートしなければなりません。
5.3.2. H.263
H.263 デコーダをサポートする場合、デバイス実装は:
- [C-1-1] ベースライン プロファイル レベル 30(CIF、QCIF、SQCIF 解像度、30 fps、384 kbps)とレベル 45(QCIF、SQCIF 解像度、30 fps、128 kbps)をサポートしなければなりません。
5.3.3. MPEG-4
MPEG-4 デコーダを備える場合、デバイス実装は:
- [C-1-1] シンプル プロファイル レベル 3 をサポートしなければなりません。
5.3.4. H.264
H.264 デコーダをサポートする場合、デバイス実装は:
- [C-1-1] メイン プロファイル レベル 3.1 とベースライン プロファイルをサポートしなければなりません。ASO(Arbitrary Slice Ordering)、FMO(Flexible Macroblock Ordering)、RS(Redundant Slices)のサポートは任意です。
- [C-1-2] 下表に記載されている SD(標準画質)プロファイルで動画をデコードでき、ベースライン プロファイルとメイン プロファイル レベル 3.1(720p30 を含む)でエンコードできなければなりません。
- 下表に示すとおり、HD(高画質)プロファイルで動画をデコードできるべきです。
Display.getSupportedModes()
メソッドでレポートされる高さが動画の解像度以上である場合、デバイス実装は:
- [C-2-1] 下表の HD 720p 動画デコード プロファイルをサポートしなければなりません。
- [C-2-2] 下表の HD 1080p 動画デコード プロファイルをサポートしなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | |
---|---|---|---|---|
動画の解像度 | 320 x 240 px | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px |
動画のフレームレート | 30 fps | 30 fps | 60 fps | 30 fps(60 fpsテレビ) |
動画のビットレート | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5. H.265(HEVC)
H.265 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] 下表に示すとおり、メイン プロファイル レベル 3 メインティアと SD 動画エンコード プロファイルをサポートしなければなりません。
- 下表に示すとおり、HD デコード プロファイルをサポートすべきです。
- [C-1-2] ハードウェア デコーダがある場合、下表に示すとおり、HD デコード プロファイルをサポートしなければなりません。
Display.getSupportedModes()
メソッドによってレポートされる高さが動画の解像度以上である場合:
- [C-2-1] デバイス実装は、720、1080、UHD プロファイルの H.265 または VP9 デコードのうち少なくとも 1 つをサポートしなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
動画の解像度 | 352 x 288 px | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px | 3,840 x 2,160 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 / 60 fps(60 fpsH.265 ハードウェア デコードを備えたテレビ) | 60 fps |
動画のビットレート | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
メディア API を通じて HDR プロファイルのサポートを主張する場合、デバイス実装は:
- [C-3-1] デバイス実装は、必要な HDR メタデータをアプリから受け入れ、必要な HDR メタデータをビットストリームやコンテナから抽出、出力することをサポートしなければなりません。
- [C-3-2] デバイス実装は、HDR コンテンツをデバイスの画面または標準の動画出力ポート(例: HDMI)に適切に表示しなければなりません。
5.3.6. VP8
VP8 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] 下表の SD デコード プロファイルをサポートしなければなりません。
- 要件を満たすハードウェア VP8 コーデックを使用すべきです。
- 下表の HD デコード プロファイルをサポートすべきです。
Display.getSupportedModes()
メソッドによってレポートされる高さが動画の解像度以上である場合:
- [C-2-1] デバイス実装は下表の 720p プロファイルをサポートしなければなりません。
- [C-2-2] デバイス実装は下表の 1080p プロファイルをサポートしなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | |
---|---|---|---|---|
動画の解像度 | 320 x 180 ピクセル | 640 x 360 ピクセル | 1,280 x 720 ピクセル | 1,920 x 1,080 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps(60 fpsテレビ) | 30(60 fpsテレビ) |
動画のビットレート | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7. VP9
VP9 コーデックをサポートする場合、デバイス実装は:
- [C-1-1] 下表に示すとおり SD 動画デコード プロファイルをサポートしなければなりません。
- 下表に示すとおり、HD デコード プロファイルをサポートすべきです。
デバイス実装が VP9 コーデックとハードウェア デコーダをサポートする場合:
- [C-2-1] 下表に示すとおり、HD デコード プロファイルをサポートしなければなりません。
Display.getSupportedModes()
メソッドによってレポートされる高さが動画の解像度以上である場合:
- [C-3-1] デバイス実装は、720、1080、UHD プロファイルの VP9 または H.265 デコードのうち少なくとも 1 つをサポートしなければなりません。
SD(低画質) | SD(高画質) | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|---|
動画の解像度 | 320 x 180 ピクセル | 640 x 360 ピクセル | 1,280 x 720 ピクセル | 1,920 x 1,080 px | 3,840 x 2,160 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 fps(60 fpsVP9 ハードウェア デコードを備えたテレビ) | 60 fps |
動画のビットレート | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
デバイス実装が CodecProfileLevel メディア API を通じて VP9Profile2
または VP9Profile3
のサポートを主張する場合:
- 12 ビット形式のサポートは任意です。
デバイス実装がメディア API を通じて HDR プロファイル(VP9Profile2HDR
、VP9Profile2HDR10Plus
、VP9Profile3HDR
、VP9Profile3HDR10Plus
)のサポートを主張する場合:
- [C-4-1] デバイス実装は、必要な HDR メタデータ(すべての HDR プロファイルで
KEY_HDR_STATIC_INFO
、HDR10Plus プロファイルで 'KEY_HDR10_PLUS_INFO')をアプリから受け入れなければなりません。また、必要な HDR メタデータをビットストリームやコンテナから抽出、出力することをサポートしなければなりません。 - [C-4-2] デバイス実装は、HDR コンテンツをデバイスの画面または標準の動画出力ポート(例: HDMI)に適切に表示しなければなりません。
5.3.8. ドルビー ビジョン
HDR_TYPE_DOLBY_VISION
を通じてドルビー ビジョン デコーダのサポートを宣言する場合、デバイス実装は:
- [C-1-1] ドルビー ビジョン対応エクストラクタを提供しなければなりません。
- [C-1-2] ドルビー ビジョン コンテンツをデバイスの画面または標準の動画出力ポート(例: HDMI)に適切に表示しなければなりません。
- [C-1-3] 下位互換性のあるベースレイヤ(存在する場合)のトラック ID を、結合したドルビー ビジョンレイヤのトラック ID と同じに設定しなければなりません。
5.3.9. AV1
- [C-1-1] 10 ビット コンテンツを含め、プロファイル 0 をサポートしなければなりません。
新しい要件の開始
AV1 コーデックをサポートし、サードパーティ アプリで利用可能にする場合、デバイス実装は:- [C-1-1] 8 ビットと 10 ビットのコンテンツを含め、メイン プロファイルをサポートしなければなりません。
ハードウェア アクセラレーテッド デコーダによる AV1 コーデックのサポートを提供する場合、デバイス実装は:
- [C-2-1]
Display.getSupportedModes()
メソッドによって報告される高さが 720p 以上である場合、下表から少なくとも HD 720p の動画デコード プロファイルをデコードできなければなりません。 - [C-2-2]
Display.getSupportedModes()
メソッドによって報告される高さが 1080p 以上である場合、下表から少なくとも HD 1080p の動画デコード プロファイルをデコードできなければなりません。
SD | HD 720p | HD 1080p | UHD | |
---|---|---|---|---|
動画の解像度 | 720 x 480 px | 1,280 x 720 px | 1,920 x 1,080 px | 3,840 x 2,160 px |
動画のフレームレート | 30 fps | 30 fps | 30 fps | 30 fps |
動画のビットレート | 5 Mbps | 8 Mbps | 16 Mbps | 50 Mbps |
Media API を通じて HDR プロファイルをサポートする場合、デバイス実装は:
- [C-3-1] ビットストリームとコンテナの両方または一方からの HDR メタデータの抽出と出力をサポートしなければなりません。
- [C-3-2] HDR コンテンツをデバイスの画面または標準の動画出力ポート(例: HDMI)に適切に表示しなければなりません。
新しい要件の終了
5.4. 録音
このセクションで概説している一部の要件は、Android 4.3 以降「すべき」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。既存と新規の Android デバイスは、「すべき」として記載されている要件を満たすことが強く推奨されます。満たさなかった場合、今後のバージョンにアップグレードした際に、Android の互換性が得られなくなります。
5.4.1. 未加工オーディオのキャプチャとマイク情報
android.hardware.microphone
を宣言する場合、デバイス実装は:
[C-1-1] 正常にオープンされた
AudioRecord
またはAAudio
のすべての入力ストリームについて、未加工オーディオ コンテンツをキャプチャできるようにしなければなりません。少なくとも、次の特性をサポートしなければなりません。- 形式: リニア PCM、16 ビット
- サンプリング レート: 8,000、11,025、16,000、44,100、48,000 Hz
- チャンネル: モノラル
- 音源:
DEFAULT
、MIC
、CAMCORDER
、VOICE_RECOGNITION
、VOICE_COMMUNICATION
、UNPROCESSED
、またはVOICE_PERFORMANCE
。これは、AAudio
の同等の入力プリセット(AAUDIO_INPUT_PRESET_CAMCORDER
など)にも適用されます。
次の特性を持つ未加工オーディオ コンテンツをキャプチャできるようにすべきです。
- 形式: リニア PCM、16 ビットと 24 ビット
- サンプリング レート: 8,000、11,025、16,000、22,050、24,000、32,000、44,100、48,000 Hz
- チャンネル: デバイスのマイクと同じ数のチャンネル
[C-1-2] アップサンプリングせずに上記のサンプルレートでキャプチャしなければなりません。
[C-1-3] 上記のサンプルレートがダウンサンプリングでキャプチャされる場合、適切なアンチエイリアス フィルタを含まなければなりません。
未加工オーディオ コンテンツを、AM ラジオと DVD の品質(つまり下記の特性)でキャプチャできるようにすべきです。
- 形式: リニア PCM、16 ビット
- サンプリング レート: 22,050、48,000 Hz
- チャンネル: ステレオ
[C-1-4]
MediaRecorder.AudioSources DEFAULT
、MIC
、CAMCORDER
、VOICE_RECOGNITION
、VOICE_COMMUNICATION
、UNPROCESSED
、またはVOICE_PERFORMANCE
を使用するアクティブな AudioRecord については、MicrophoneInfo
API を尊重し、AudioManager.getMicrophones()
API を介してサードパーティ アプリがアクセスできるデバイス上の利用可能なマイクの情報を適切に入力しなければなりません。未加工オーディオ コンテンツを AM ラジオと DVD の品質でキャプチャできるようにする場合、デバイス実装は:[C-2-1] 16,000:22,050 または 44,100:48,000 を超える比率でアップサンプリングせずにキャプチャしなければなりません。
[C-2-2] アップサンプリングまたはダウンサンプリングのための適切なアンチエイリアス フィルタを含まなければなりません。
5.4.2. 音声認識用のキャプチャ
android.hardware.microphone
を宣言する場合、デバイス実装は:
- [C-1-1] 44,100 と 48,000 いずれかのサンプリング レートで
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
音源をキャプチャしなければなりません。 - [C-1-2]
AudioSource.VOICE_RECOGNITION
音源からのオーディオ ストリームを録音するとき、ノイズ リダクション オーディオ処理をデフォルトで無効にしなければなりません。 [C-1-3]
AudioSource.VOICE_RECOGNITION
音源からのオーディオ ストリームを録音するとき、自動ゲイン コントロールをデフォルトで無効にしなければなりません。音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲でほぼ平坦な振幅周波数特性を示すべきです(具体的には ±3 dB、100 Hz~4,000 Hz)。
[C-SR-1] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して低い周波数範囲の振幅レベルを示すことが強く推奨されます(具体的には ±20 dB、30 Hz~100 Hz)。
[C-SR-2] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して高い周波数範囲の振幅レベルを示すことが強く推奨されます(具体的には ±30 dB、4,000 Hz~22 kHz)。
音声認識の音源を録音するために使用する各マイクすべてについて、音圧レベル(SPL)90 dB で再生された 1,000 Hz 正弦波音源(マイク
から 30 cm の距離の隣で測定)が、16 ビットサンプルで RMS 1,770~3,530 の範囲のレスポンス(理想的には RMS 2,500)になるように(浮動小数点 / 倍精度サンプルの場合は -22.35 dB ±3 dB フルスケール)、オーディオ入力感度を設定すべきです。マイクでの 90 dB SPL から少なくとも 30 dB(-18 dB~+12 dB)の範囲で PCM 振幅レベルが入力 SPL の変化を線形的にトラックするように、音声認識のオーディオ ストリームを録音すべきです。
全高調波歪み(THD)がマイクでの SPL 入力レベル 90 dB で 1 kHz に対して 1% 未満になるように、音声認識のオーディオ ストリームを録音すべきです。
android.hardware.microphone
と、音声認識用に調整したノイズ キャンセレーション(リダクション)技術を宣言する場合、デバイス実装は:
- [C-2-1] このオーディオ エフェクトを
android.media.audiofx.NoiseSuppressor
API で制御できるようにしなければなりません。 - [C-2-2]
AudioEffect.Descriptor.uuid
フィールドを介して各ノイズ キャンセレーション技術実装を一意に識別しなければなりません。
5.4.3. 再生のリルート用のキャプチャ
android.media.MediaRecorder.AudioSource
クラスには REMOTE_SUBMIX
音源が含まれています。
android.hardware.audio.output
と android.hardware.microphone
を両方とも宣言する場合、デバイス実装は:
[C-1-1]
REMOTE_SUBMIX
音源を適切に実装して、アプリがandroid.media.AudioRecord
API を使用してこの音源から録音するとき、下記を除くすべてのオーディオ ストリームのミックスをキャプチャするようにしなければなりません。AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. 音響エコー キャンセラ
android.hardware.microphone
を宣言する場合、デバイス実装は:
AudioSource.VOICE_COMMUNICATION
を使用してキャプチャするときにキャプチャパスに適用される、音声通信用に調整された音響エコー キャンセラ(AEC)技術を実装すべきです。
AudioSource.VOICE_COMMUNICATION
が選択されたときにキャプチャ オーディオパスに挿入される音響エコー キャンセラを提供する場合、デバイス実装は:
- [C-SR-1] AcousticEchoCanceler API のメソッド AcousticEchoCanceler.isAvailable() を介してこれを宣言することが強く推奨されます。
- [C-SR-2] このオーディオ エフェクトを AcousticEchoCanceler API で制御できるようにすることが強く推奨されます。
- [C-SR-3] AudioEffect.Descriptor.uuid フィールドを介して各 AEC 技術実装を一意に識別することが強く推奨されます。
5.4.5. 同時キャプチャ
android.hardware.microphone
を宣言する場合、デバイス実装は、こちらのドキュメントに記載されているとおり同時キャプチャを実装しなければなりません。具体的には次のとおりです。
- [C-1-1]
AudioSource.VOICE_RECOGNITION
でキャプチャするユーザー補助サービスと、任意のAudioSource
でキャプチャする少なくとも 1 つのアプリから、マイクに同時アクセスできるようにしなければなりません。 - [C-1-2] アシスタントのロールを持つプリインストール アプリと、任意の
AudioSource
(AudioSource.VOICE_COMMUNICATION
またはAudioSource.CAMCORDER
を除く)でキャプチャする少なくとも 1 つのアプリから、マイクに同時アクセスできるようにしなければなりません。 - [C-1-3] アプリが
AudioSource.VOICE_COMMUNICATION
またはAudioSource.CAMCORDER
でキャプチャしている間、ユーザー補助サービスを除き、他のアプリのオーディオ キャプチャを消音しなければなりません。ただし、アプリがAudioSource.VOICE_COMMUNICATION
を介してキャプチャしているときは、別のアプリ(権限CAPTURE_AUDIO_OUTPUT
を付与されたプリインストールの特権アプリ)で音声通話をキャプチャできます。 - [C-1-4] 複数のアプリが同時にキャプチャしていて、どちらのアプリも UI が最上位にない場合、最後にキャプチャを開始したアプリがオーディオを受信します。
5.5. オーディオの再生
Android には、セクション 7.8.2 で規定されているとおり、アプリがオーディオ出力周辺機器を通じてオーディオを再生できるようにするサポートが含まれています。
5.5.1. 未加工オーディオの再生
android.hardware.audio.output
を宣言する場合、デバイス実装は:
[C-1-1] 次の特性を持つ未加工オーディオ コンテンツを再生できるようにしなければなりません。
- 音源形式: リニア PCM、16 ビット、8 ビット、浮動小数点
- チャンネル: モノラル、ステレオ、最大 8 チャンネルの有効なマルチチャンネル構成
- サンプリング レート(Hz):
- 上のチャンネル構成で 8,000、11,025、16,000、22,050、24,000、32,000、44,100、48,000
- モノラルとステレオで 96,000
5.5.2. オーディオ エフェクト
Android は、デバイス実装にオーディオ エフェクト用の API を提供します。
機能 android.hardware.audio.output
を宣言する場合、デバイス実装は:
- [C-1-1] AudioEffect のサブクラス
Equalizer
とLoudnessEnhancer
を通じて制御できるEFFECT_TYPE_EQUALIZER
実装とEFFECT_TYPE_LOUDNESS_ENHANCER
実装をサポートしなければなりません。 - [C-1-2]
Visualizer
クラスを通じて制御できるビジュアライザ API 実装をサポートしなければなりません。 - [C-1-3] AudioEffect のサブクラス
DynamicsProcessing
を通じて制御できるEFFECT_TYPE_DYNAMICS_PROCESSING
実装をサポートしなければなりません。
新しい要件の開始
- [C-1-4] 浮動小数点入力と出力によるオーディオ エフェクトをサポートしなければなりません。
- [C-1-5] オーディオ エフェクトが、最大でミキサー チャンネル数(FCC_LIMIT)と同じ数までの複数のチャンネルをサポートするようにしなければなりません。
新しい要件の終了
AudioEffect
のサブクラスBassBoost
、EnvironmentalReverb
、PresetReverb
、Virtualizer
を通じて制御できるEFFECT_TYPE_BASS_BOOST
、EFFECT_TYPE_ENV_REVERB
、EFFECT_TYPE_PRESET_REVERB
、EFFECT_TYPE_VIRTUALIZER
実装をサポートすべきです。- [C-SR-1] 浮動小数点とマルチチャンネルのエフェクトをサポートすることが強く推奨されます。
5.5.3. 出力音量
自動車デバイス実装は:
- AudioAttributes で定義されているコンテンツ タイプまたは用途と、
android.car.CarAudioManager
で公開で定義されているカーオーディオ用途を使用して、音量をオーディオ ストリームごとに調整できるようにすべきです。
5.5.4. オーディオ オフロード
オーディオ オフロード再生をサポートする場合、デバイス実装は:
- [C-SR-1] AudioTrack gapless API と MediaPlayer のメディア コンテナで指定されている場合、再生されるギャップレス オーディオ コンテンツを、同じ形式の 2 つのクリップ間でトリミングすることが強く推奨されます。
5.6. オーディオ レイテンシ
オーディオ レイテンシとは、オーディオ信号がシステムを通過する際に発生する遅延時間のことです。アプリのクラスの多くで、リアルタイムのサウンド エフェクトを実現するには、レイテンシが短くなっている必要があります。
このセクションでは、次の定義を使用します。
- 出力レイテンシ。アプリが PCM 符号化データを書き込んでから、対応するサウンドがデバイス上のトランスデューサで環境に提供されるか、信号がポートを介してデバイスから出て外部で確認されるまでの間隔。
- コールド出力レイテンシ。リクエストの前にオーディオ出力システムがアイドル状態になり、電源がオフになった場合の、出力ストリームの開始からタイムスタンプに基づく最初のフレームの表示時間までの時間。
- 連続出力レイテンシ。デバイスがオーディオを再生した後の、後続フレームの出力レイテンシ。
- 入力レイテンシ。サウンドが環境によってデバイス上のトランスデューサでデバイスに提供されるか、信号がポートを介してデバイスに入ってから、PCM 符号化データの対応するフレームをアプリが読み取るまでの間隔。
- 欠損入力。使用または利用できない、入力信号の最初の部分。
- コールド入力レイテンシ。リクエストの前にオーディオ入力システムがアイドル状態になり、電源がオフになった場合の、ストリームの開始から最初の有効なフレームを受信するまでの時間。
連続入力レイテンシ。デバイスがオーディオをキャプチャしている間の、後続フレームの入力レイテンシ。
連続ラウンドトリップ レイテンシ。連続入力レイテンシ、連続出力レイテンシ、1 バッファ期間の合計。バッファ期間により、アプリが信号を処理するための時間と、アプリが入出力ストリーム間の位相差を緩和するための時間を確保できます。
OpenSL ES PCM バッファキュー API。Android NDK 内にある、PCM 関連の OpenSL ES API のセット。
AAudio ネイティブ オーディオ API。Android NDK 内にある、AAudio API のセット。
タイムスタンプ。ストリーム内の相対フレーム位置と、そのフレームが関連エンドポイントのオーディオ処理パイプラインに出入りする推定時間からなるペア。AudioTimestamp もご覧ください。
グリッチ。オーディオ信号の一時的な中断または不正なサンプル値。通常は、出力のバッファ アンダーラン、入力のバッファ オーバーラン、他のデジタルまたはアナログノイズ発生源によって発生します。
平均絶対偏差。一連の値の平均からの偏差の絶対値の平均。
タップツートーン レイテンシ。画面がタップされてから、そのタップの結果として生成された音がスピーカーから聞こえるまでの時間。
android.hardware.audio.output
を宣言する場合、デバイス実装は、次の要件を満たすか上回らなければなりません。
- [C-1-1] AudioTrack.getTimestamp と
AAudioStream_getTimestamp
から返される出力タイムスタンプの正確度が +/- 2 ms。 [C-1-2] コールド出力レイテンシが 500 ミリ秒以下。
[C-1-3]
AAudioStreamBuilder_openStream()
を使用して出力ストリームを開始するのに要する時間が 1,000 ミリ秒未満でなければなりません。
android.hardware.audio.output
を宣言する場合、デバイス実装は、次の要件を満たすか上回ることが強く推奨されます。
- [C-SR-1] スピーカー データパスでコールド出力レイテンシが 100 ミリ秒以下。
- [C-SR-2] タップツートーン レイテンシが 80 ミリ秒以下。
- [C-SR-4] AudioTrack.getTimestamp と
AAudioStream_getTimestamp
から返される出力タイムスタンプの正確度が +/- 1 ms。
新しい要件の開始
- [C-SR-4]
AAudioStream_getTimestamp
によって返される入力タイムスタンプと出力タイムスタンプに基づいて計算されたラウンドトリップ レイテンシと、スピーカー、有線ヘッドセット、ワイヤレス ヘッドセットのAAUDIO_PERFORMANCE_MODE_NONE
とAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
について測定されたラウンド トリップ レイテンシとの誤差が 30 ミリ秒以内であることが強く推奨されます。
新しい要件の終了
上記の要件を満たす場合、初期キャリブレーションの後、AAudio ネイティブ オーディオ API を使用しているとき、少なくとも 1 つのサポート対象オーディオ出力デバイスでの連続出力レイテンシとコールド出力レイテンシについて、デバイス実装は:
- [C-SR-5]
android.hardware.audio.low_latency
機能フラグを宣言することで低レイテンシ オーディオをレポートすることが強く推奨されます。 - [C-SR-6] AAudio API を介して低レイテンシの要件を満たすことが強く推奨されます。
- [C-SR-7]
AAudioStream_getPerformanceMode()
からAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
を返すストリームでは、AAudioStream_getFramesPerBurst()
が返す値が、プロパティキーAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
に対してandroid.media.AudioManager.getProperty(String)
が返す値以下になるようにすることが強く推奨されます。
AAudio ネイティブ オーディオ API を介して低レイテンシ オーディオの要件を満たさない場合、デバイス実装は:
- [C-2-1] 低レイテンシ オーディオのサポートをレポートしてはなりません。
android.hardware.microphone
が含まれる場合、デバイス実装は下記の入力オーディオの要件を満たさなければなりません。
- [C-3-1] AudioRecord.getTimestamp または
AAudioStream_getTimestamp
が返す入力タイムスタンプの誤差を +/- 2 ms に制限する。ここでいう誤差とは、正しい値からのずれのことです。 - [C-3-2] コールド入力レイテンシが 500 ミリ秒以下。
- [C-3-3]
AAudioStreamBuilder_openStream()
を使用して入力ストリームを開くために要する時間が 1,000 ミリ秒未満でなければなりません。
android.hardware.microphone
が含まれる場合、デバイス実装は下記の入力オーディオの要件を満たすことが強く推奨されます。
[C-SR-8] マイク データパスでコールド入力レイテンシが 100 ミリ秒以下。
[C-SR-11] AudioRecord.getTimestamp または
AAudioStream_getTimestamp
が返す入力タイムスタンプの誤差を +/- 1 ms に制限する。
android.hardware.audio.output
と android.hardware.microphone
を宣言する場合、デバイス実装は:
- [C-SR-12] 少なくとも 1 つのサポート対象パスで、5 回測定して平均連続ラウンドトリップ レイテンシが 50 ミリ秒以下、平均絶対偏差が 10 ミリ秒未満であることが強く推奨されます。
5.7. ネットワーク プロトコル
デバイス実装は、Android SDK ドキュメントで規定されているとおり、オーディオと動画を再生するためにメディア ネットワーク プロトコルをサポートしなければなりません。
サポートするためにデバイス実装が必要となるコーデックとコンテナ形式ごとに、デバイス実装は:
[C-1-1] HTTP と HTTPS でそのコーデックまたはコンテナをサポートしなければなりません。
[C-1-2] HTTP Live Streaming ドラフト プロトコル バージョン 7 で、下表「メディア セグメント形式」に示す対応するメディア セグメント形式をサポートしなければなりません。
[C-1-3] 下表「RTSP」に示す対応する RTSP ペイロード形式をサポートしなければなりません。例外については、セクション 5.1 の表の脚注をご覧ください。
メディア セグメント形式
セグメント形式 | 参照 | 必要なコーデックのサポート |
---|---|---|
MPEG-2 トランスポート ストリーム | ISO 13818 |
動画コーデック:
オーディオ コーデック:
|
ADTS フレーム処理と ID3 タグを伴う AAC | ISO 13818-7 | AAC とそのバリアントの詳細についてはセクション 5.1.1 をご覧ください |
WebVTT | WebVTT |
RTSP(RTP、SDP)
プロファイル名 | 参照 | 必要なコーデックのサポート |
---|---|---|
H264 AVC | RFC 6184 | H264 AVC の詳細についてはセクション 5.1.8 をご覧ください |
MP4A-LATM | RFC 6416 | AAC とそのバリアントの詳細についてはセクション 5.1.3 をご覧ください |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
H263 の詳細についてはセクション 5.1.8 をご覧ください |
H263-2000 | RFC 4629 | H263 の詳細についてはセクション 5.1.8 をご覧ください |
AMR | RFC 4867 | AMR-NB の詳細についてはセクション 5.1.3 をご覧ください |
AMR-WB | RFC 4867 | AMR-WB の詳細についてはセクション 5.1.3 をご覧ください |
MP4V-ES | RFC 6416 | MPEG-4 SP の詳細についてはセクション 5.1.8 をご覧ください |
mpeg4-generic | RFC 3640 | AAC とそのバリアントの詳細についてはセクション 5.1.3 をご覧ください |
MP2T | RFC 2250 | 詳細については HTTP Live Streaming の下の MPEG-2 トランスポート ストリームをご覧ください |
5.8. セキュア メディア
セキュア動画出力をサポートし、セキュア サーフェスをサポートできる場合、デバイス実装は:
- [C-1-1]
Display.FLAG_SECURE
のサポートを宣言しなければなりません。
Display.FLAG_SECURE
のサポートを宣言し、ワイヤレス ディスプレイ プロトコルをサポートする場合、デバイス実装は:
- [C-2-1] Miracast のようなワイヤレス プロトコルを通じて接続されたディスプレイについて、HDCP 2.x 以降のような暗号強度の高いメカニズムによって、リンクをセキュアにしなければなりません。
Display.FLAG_SECURE
のサポートを宣言し、有線外部ディスプレイをサポートする場合、デバイス実装は:
- [C-3-1] ユーザーがアクセス可能な有線ポートを介して接続されたすべての外部ディスプレイについて、HDCP 1.2 以降をサポートしなければなりません。
5.9. 電子楽器デジタル インターフェース(MIDI)
android.content.pm.PackageManager
クラスを介して機能 android.software.midi
のサポートをレポートする場合、デバイス実装は:
[C-1-1] 一般的な非 MIDI 接続を提供するすべての MIDI 対応ハードウェア トランスポートで MIDI をサポートしなければなりません。ここでいうトランスポートは次のとおりです。
- USB ホストモード(セクション 7.7)
- 中心的な役割を担う Bluetooth LE での MIDI(セクション 7.4.3)
[C-1-2] アプリ間 MIDI ソフトウェア トランスポート(仮想 MIDI デバイス)をサポートしなければなりません。
[C-1-3] libamidi.so(ネイティブ MIDI サポート)を含まなければなりません。
USB ペリフェラル モードの MIDI をサポートすべきです(セクション 7.7)。
5.10. プロフェッショナル オーディオ
android.content.pm.PackageManager クラスを介して機能 android.hardware.audio.pro
のサポートをレポートする場合、デバイス実装は:
- [C-1-1] 機能
android.hardware.audio.low_latency
のサポートをレポートしなければなりません。 - [C-1-2] セクション 5.6 オーディオ レイテンシで規定しているとおり、少なくとも 1 つのサポート対象パスで連続ラウンドトリップ オーディオ レイテンシが 25 ミリ秒以下でなければなりません。
- [C-1-3] USB ホストモードと USB ペリフェラル モードをサポートする USB ポートを含まなければなりません。
- [C-1-4] 機能
android.software.midi
のサポートをレポートしなければなりません。 - [C-1-5] AAudio ネイティブ オーディオ API と
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
を使用して、レイテンシと USB オーディオの要件を満たさなければなりません。 - [C-1-6] コールド出力レイテンシが 200 ミリ秒以下でなければなりません。
- [C-1-7] コールド入力レイテンシが 200 ミリ秒以下でなければなりません。
[C-1-8] スピーカーからマイクのデータパスで、少なくとも 5 回測定して平均タップツートーン レイテンシが 80 ミリ秒以下でなければなりません。
[C-SR-1] セクション 5.6 オーディオ レイテンシで規定されているとおり、スピーカーからマイクのパスで、5 回測定してレイテンシが 20 ミリ秒以下、平均絶対偏差 5 ミリ秒未満を満たすことが強く推奨されます。
[C-SR-2] MMAP パスで、AAudio ネイティブ オーディオ API を使用して、連続ラウンドトリップ オーディオ レイテンシ、コールド入力レイテンシ、コールド出力レイテンシの Pro Audio 要件と、USB オーディオ要件を満たすことが強く推奨されます。
[C-SR-3] オーディオがアクティブで CPU 負荷が変動していても、一貫した CPU パフォーマンス レベルを提供することが強く推奨されます。これは、Android アプリ SynthMark を使用してテストすべきです。SynthMark は、システム パフォーマンスを測定するシミュレート オーディオ フレームワークで動作する、ソフトウェア シンセサイザーを使用します。ベンチマークの説明については、SynthMark のドキュメントをご覧ください。SynthMark アプリは「自動テスト」オプションを使用して実行し、次の結果を得る必要があります。
- voicemark.90 >= 32 voices
- latencymark.fixed.little <= 15 msec
- latencymark.dynamic.little <= 50 msec
オーディオ クロックの不正確さと標準時間に対するずれを最小限に抑えるべきです。
両方ともアクティブな場合、CPU
CLOCK_MONOTONIC
に対するオーディオ クロックのずれを最小限に抑えるべきです。デバイス上のトランスデューサでオーディオ レイテンシを最小限に抑えるべきです。
USB デジタル オーディオでオーディオ レイテンシを最小限に抑えるべきです。
すべてのパスでオーディオ レイテンシ測定値を記録すべきです。
コールバックによる CPU 帯域幅全体の使用可能率に影響するため、オーディオ バッファ完了コールバック エントリ時間のジッターを最小限に抑えるべきです。
レポートされたレイテンシで通常の使用におけるオーディオ グリッチをゼロにすべきです。
チャンネル間のレイテンシ差をゼロにすべきです。
すべてのトランスポートで MIDI 平均レイテンシを最小限に抑えるべきです。
すべてのトランスポートで負荷がかかった状態での MIDI レイテンシのばらつき(ジッター)を最小限に抑えるべきです。
すべてのトランスポートで MIDI タイムスタンプを正確にすべきです。
コールド スタート直後の期間を含め、デバイス上のトランスデューサでオーディオ信号ノイズを最小限に抑えるべきです。
両方ともアクティブな場合、対応するエンドポイントの入力側と出力側でオーディオ クロックの差をゼロにすべきです。対応するエンドポイントの例としては、デバイス上のマイクとスピーカーや、オーディオ ジャックの入出力が挙げられます。
両方ともアクティブな場合、同じスレッド上の対応するエンドポイントの入力側と出力側のオーディオ バッファ完了コールバックを処理し、入力コールバックからのリターンの直後に出力コールバックに入るべきです。または、同じスレッド上でコールバックを処理できない場合は、入力コールバックの直後に出力コールバックに入り、アプリが入力側と出力側のタイミングを一貫させられるようにします。
対応するエンドポイントの入力側と出力側で、HAL オーディオ バッファの位相差を最小限に抑えるべきです。
タップ レイテンシを最小限に抑えるべきです。
負荷がかかった状態でのタップ レイテンシのばらつき(ジッター)を最小限に抑えるべきです。
上記の要件をすべて満たす場合、デバイス実装は:
- [C-SR-4]
android.content.pm.PackageManager
クラスを介して機能android.hardware.audio.pro
のサポートをレポートすることが強く推奨されます。
4 極 3.5 mm オーディオ ジャックが含まれる場合、デバイス実装は:
[C-2-1] セクション 5.6 オーディオ レイテンシで規定しているとおり、平均連続ラウンドトリップ オーディオ レイテンシが 20 ミリ秒以下でなければならず、5 つの測定値の平均絶対偏差が、オーディオ ループバック ドングルを使用したオーディオ ジャック パスで 5 ミリ秒未満でなければなりません。
[C-SR-5] 有線オーディオ ヘッドセット仕様(v1.1)のモバイル デバイス(ジャック)仕様セクションの要件を満たすことが強く推奨されます。
4 極 3.5 mm オーディオ ジャックを省略し、USB ホストモードをサポートする USB ポートを含める場合、デバイス実装は:
- [C-3-1] USB オーディオ クラスを実装しなければなりません。
- [C-3-2] USB オーディオ クラスを使用し、USB ホストモード ポートで 5 回測定して、平均連続ラウンドトリップ オーディオ レイテンシが 25 ミリ秒以下、平均絶対偏差 5 ミリ秒未満でなければなりません(これは、USB-3.5 mm アダプターとオーディオ ループバック ドングルを使用して、または入力と出力をパッチケーブルで接続した USB オーディオ インターフェースを使用して測定できます)。
- [C-SR-6] これらの要件にも対応した USB オーディオ周辺機器で使用する場合、各方向で最大 8 チャンネル、サンプルレート 96 kHz、24 ビットまたは 32 ビット深度の同時 I/O をサポートすることが強く推奨されます。
- [C-SR-7] MMAP パスで AAudio ネイティブ オーディオ API を使用してこの要件グループを満たすことが強く推奨されます。
HDMI ポートが含まれる場合、デバイス実装は:
- 少なくとも 1 つの構成で、ビット深度損失やリサンプリングなしで、20 ビットまたは 24 ビット深度、192 kHz のステレオと 8 チャンネルの出力をサポートすべきです。
5.11. 未処理のキャプチャ
Android は、android.media.MediaRecorder.AudioSource.UNPROCESSED
音源を介した未処理オーディオの録音をサポートしています。OpenSL ES では、録音プリセット SL_ANDROID_RECORDING_PRESET_UNPROCESSED
でアクセスできます。
未処理音原をサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:
[C-1-1]
android.media.AudioManager
プロパティ PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED を通じてサポートをレポートしなければなりません。[C-1-2] 未処理音源の録音に使用する各マイクすべてについて、中間周波数範囲でほぼ平坦な振幅周波数特性を示さなければなりません(具体的には ±10dB、100 Hz~7,000 Hz)。
[C-1-3] 未処理音源の録音に使用する各マイクすべてについて、中間周波数範囲と比較して低い周波数範囲の振幅レベルを示さなければなりません(具体的には ±20 dB、5 Hz~100 Hz)。
[C-1-4] 未処理音源の録音に使用する各マイクすべてについて、中間周波数範囲と比較して高い周波数範囲の振幅レベルを示さなければなりません(具体的には ±30 dB、7,000 Hz~22 KHz)。
[C-1-5] 未処理音源の録音に使用する各マイクすべてについて、音圧レベル(SPL)94 dB で再生された 1,000 Hz 正弦波音源が、16 ビットサンプルで RMS 520 のレスポンスになるように(浮動小数点 / 倍精度サンプルの場合は -36 dB フルスケール)、オーディオ入力感度を設定しなければなりません。
[C-1-6] 未処理音源の録音に使用する各マイクすべてについて、信号対雑音比(SNR)を 60 dB にしなければなりません(SNR は、SPL 94 dB と、A 特性自己雑音の等価 SPL の差として測定します)。
[C-1-7] 未処理音源の録音に使用する各マイクすべてにおいて、全高調波歪み(THD)を、SPL 入力レベル 90 dB で 1 kHz に対して 1% 未満にしなければなりません。
[C-1-8] レベルを目的の範囲にするために、レベル乗算器以外の信号処理(自動ゲイン コントロール、ハイ パスフィルタ、エコー キャンセラなど)があってはなりません。つまり:
- [C-1-9] なんらかの理由で、なんらかの信号処理がアーキテクチャに存在する場合、無効にしなければならず、ゼロ遅延または余分なレイテンシを信号パスに効果的に導入しなければなりません。
- [C-1-10] レベル乗算器は、パス上にあることが許容されますが、信号パスに遅延またはレイテンシを導入してはなりません。
SPL の測定はすべて、テスト対象のマイクのすぐ隣で直接行います。マイクが複数ある構成では、これらの要件を各マイクに適用します。
android.hardware.microphone
を宣言するが、未処理音源をサポートしない場合、デバイス実装は:
- [C-2-1] サポートしていないことを適切に示すために、
AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API メソッドについてnull
を返さなければなりません。 - [C-SR-1] その場合でも、未処理録音源の信号パスに関する要件を可能な限り多く満たすことが強く推奨されます。
5.12. HDR 動画
今後のドキュメントで説明するように、Android 13 は HDR テクノロジーをサポートします。
ピクセルの形式
COLOR_FormatYUVP010 のサポートをアドバタイズしている場合、動画デコーダは:
[C-1-1] CPU 読み取り(ImageReader、MediaImage、ByteBuffer)の P010 形式をサポートしなければなりません。Android 13 では P010 が緩和され、Y プレーンと UV プレーンで任意のストライドが可能になりました。
[C-1-2] P010 出力バッファを GPU でサンプリングできるようにしなければなりません(GPU_SAMPLING 用途を指定して割り当てる場合)。これにより、アプリによる GPU 合成とカスタムトーン マッピングが可能になります。
COLOR_Format32bitABGR2101010 のサポートをアドバタイズしている場合、動画デコーダは:
- [C-2-1] 出力サーフェスと CPU 読み取り可能(ByteBuffer の出力)の RGBA_1010102 形式をサポートしなければなりません。
COLOR_FormatYUVP010 のサポートをアドバタイズしている場合、動画エンコーダは:
- [C-3-1] 入力サーフェスと CPU 書き込み可能(ImageWriter、MediaImage、ByteBuffer の入力)の P010 形式をサポートしなければなりません。
COLOR_Format32bitABGR2101010 のサポートをアドバタイズしている場合、動画エンコーダは:
- [C-4-1] 入力サーフェスと CPU 書き込み可能(ImageWriter、ByteBuffer の入力)の RGBA_1010102 形式をサポートしなければなりません。注: エンコーダでは、さまざまな転送曲線間の変換は必要ありません。
HDR キャプチャの要件
HDR プロファイルをサポートするすべての動画エンコーダについて、デバイス実装は:
[C-5-1] HDR メタデータが正確であると想定してはなりません。たとえば、エンコードされたフレームにピーク輝度レベルを超えるピクセルが含まれる場合や、ヒストグラムが典型的なフレームを表していない場合があります。
エンコードされたストリームに適切な HDR 静的メタデータを生成するために、HDR 動的メタデータを集約し、各エンコード セッションの最後に出力すべきです。
CamcorderProfile API を使用した HDR キャプチャをサポートしている場合、デバイス実装は:
[C-6-1] Camera2 API を介した HDR キャプチャもサポートしなければなりません。
[C-6-2] サポートされる HDR テクノロジーごとに、少なくとも 1 つのハードウェア アクセラレーテッド動画エンコーダをサポートしなければなりません。
[C-6-3] (少なくとも)HLG キャプチャをサポートしなければなりません。
[C-6-4] キャプチャした動画ファイルへの HDR メタデータ(HDR テクノロジーに適用可能な場合)の書き込みをサポートしなければなりません。AV1、HEVC、DolbyVision の場合、これはエンコードされたビットストリームにメタデータを含めることを意味します。
[C-6-5] P010 と COLOR_FormatYUVP010 をサポートしなければなりません。
[C-6-6] キャプチャしたプロファイルについては、デフォルトのハードウェア アクセラレーテッド デコーダで、HDR から SDR へのトーン マッピングをサポートしなければなりません。つまり、デバイスが HDR10+ HEVC をキャプチャできる場合、デフォルトの HEVC デコーダは、キャプチャしたストリームを SDR でデコードできなければなりません。
HDR 編集の要件
HDR 編集をサポートする動画エンコーダが含まれる場合、デバイス実装は:
- HDR メタデータが存在しない場合は、HDR メタデータを生成する際のレイテンシを最小限にすべきです。また、メタデータが存在するフレームと存在しないフレームが混在する状況に適切に対処すべきです。このメタデータは正確であるべきです(たとえば、実際のピーク輝度、フレームのヒストグラムを表すべきです)。
FEATURE_HdrEditing をサポートするコーデックが含まれる場合、デバイス実装は:
[C-7-1] 少なくとも 1 つの HDR プロファイルをサポートしなければなりません。
[C-7-2] そのコーデックによってアドバタイズされるすべての HDR プロファイルについて、FEATURE_HdrEditing をサポートしなければなりません。つまり、HDR メタデータを使用する、サポートされるすべての HDR プロファイルに HDR メタデータが存在しない場合、HDR メタデータの生成をサポートしなければなりません。
[C-7-3] 入力サーフェスと ByteBuffer の両方について、HDR デコード信号を完全に保持する動画エンコーダ入力形式である
- RGBA_1010102(すでにターゲット転送曲線にある)をサポートしなければならず、COLOR_Format32bitABGR2101010 のサポートをアドバタイズしなければなりません。
FEATURE_HdrEditing をサポートするコーデックが含まれる場合、デバイス実装は:
- [C-7-4] EXT_YUV_target OpenGL 拡張機能のサポートをアドバタイズしなければなりません。
6. デベロッパー ツール、開発者向けオプションの互換性
6.1. デベロッパー ツール
デバイス実装は:
- [C-0-1] Android SDK で提供されている Android デベロッパー ツールをサポートしなければなりません。
-
- [C-0-2] Android SDK に記載されている adb と、アプリ デベロッパーが使用できる、AOSP で提供されるシェルコマンド(
dumpsys
cmd stats
を含む)をサポートしなければなりません。 - [C-0-11] シェルコマンド
cmd testharness
をサポートしなければなりません。永続データブロックのない以前の Android バージョンからデバイス実装をアップグレードする場合は、C-0-11 を免除しても構いません。 - [C-0-3] dumpsys コマンドを介してログに記録されるデバイス システム イベント(batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats)の形式またはコンテンツを変更してはなりません。
- [C-0-10] 次のイベントを省略せずに記録し、
cmd stats
シェルコマンドとStatsManager
システム API クラスからアクセスして利用できるようにしなければなりません。- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] デバイス側の adb デーモンをデフォルトで無効にしなければならず、Android Debug Bridge をオンにするためのユーザーがアクセス可能なメカニズムがなければなりません。
- [C-0-5] セキュア adb をサポートしなければなりません。Android は、セキュア adb をサポートしています。セキュア adb は、既知の認証済みホストで adb を有効にします。
- [C-0-6] adb をホストマシンから接続できるようにするメカニズムを提供しなければなりません。具体的には次のとおりです。
USB ポートなしでペリフェラル モードをサポートする場合、デバイス実装は:
- [C-3-1] ローカルエリア ネットワーク(イーサネット、Wi-Fi など)を介して adb を実装しなければなりません。
- [C-3-2] デベロッパーが adb プロトコルを使用してデバイスに接続できるように、Windows 7、8、10 用のドライバを提供しなければなりません。
Wi-Fi またはイーサネットを介したホストマシンへの adb 接続をサポートする場合、デバイス実装は:
- [C-4-1]
AdbManager#isAdbWifiSupported()
メソッドがtrue
を返さなければなりません。
Wi-Fi またはイーサネットを介したホストマシンへの adb 接続をサポートし、カメラが 1 つ以上含まれる場合、デバイス実装は:
- [C-5-1]
AdbManager#isAdbWifiQrSupported()
メソッドがtrue
を返さなければなりません。
- [C-0-2] Android SDK に記載されている adb と、アプリ デベロッパーが使用できる、AOSP で提供されるシェルコマンド(
Dalvik Debug Monitor Service(ddms)
- [C-0-7] Android SDK に記載されているとおり、ddms 機能をすべてサポートしなければなりません。ddms は adb を使用するため、ddms のサポートはデフォルトで無効にすべきですが、上記のようにユーザーが Android Debug Bridge を有効にした場合は必ずサポートしなければなりません。
-
- [C-0-9] Android SDK に記載されているとおり、systrace ツールをサポートしなければなりません。Systrace はデフォルトで無効でなければならず、Systrace をオンにするユーザーがアクセス可能なメカニズムがなければなりません。
-
- [C-SR-1] cmdline で perfetto ドキュメントを遵守しているシェルユーザーに
/system/bin/perfetto
バイナリを公開することが強く推奨されます。 - [C-SR-2] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf 構成を入力として受け入れることが強く推奨されます。
- [C-SR-3] perfetto バイナリは、perfetto ドキュメントで規定されたスキーマに準拠する protobuf トレースを出力として書き込むことが強く推奨されます。
- [C-SR-4] perfetto バイナリを通じて、少なくとも perfetto ドキュメントに記載されているデータソースを提供することが強く推奨されます。
- [C-SR-1] cmdline で perfetto ドキュメントを遵守しているシェルユーザーに
-
- [C-0-12] アプリがローメモリ キラーによって終了したとき、
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom を statsd ログに書き込まなければなりません。
- [C-0-12] アプリがローメモリ キラーによって終了したとき、
テストハーネス モード シェルコマンド
cmd testharness
をサポートし、cmd testharness enable
を実行する場合、デバイス実装は:- [C-2-1]
ActivityManager.isRunningInUserTestHarness()
についてtrue
を返さなければなりません。 - [C-2-2] テストハーネス モードのドキュメントに記載されているとおり、テストハーネス モードを実装しなければなりません。
- [C-2-1]
GPU 処理に関する情報
デバイス実装は:
- [C-0-13]
power/gpu_work_period
カーネル トレースポイントによって返された GPU 処理の集計データを表示し、トレースポイントがサポートされていない場合はデータを表示しないよう、シェルコマンドdumpsys gpu --gpuwork
を実装しなければなりません。AOSP 実装はframeworks/native/services/gpuservice/gpuwork/
です。
- [C-0-13]
android.hardware.vulkan.version
機能フラグを介して Vulkan 1.0 以降のサポートをレポートする場合、デバイス実装は:
- [C-1-1] GPU デバッグレイヤを有効化 / 無効化するアフォーダンスをアプリ デベロッパーに提供しなければなりません。
- [C-1-2] GPU デバッグレイヤが有効な場合、API メソッド vkEnumerateInstanceLayerProperties() と vkCreateInstance() をサポートするために、デバッグ可能なアプリのベース ディレクトリにある外部ツール(つまり、プラットフォームまたはアプリ パッケージの一部ではありません)によって提供されるライブラリのレイヤを列挙しなければなりません。
6.2. 開発者向けオプション
Android は、デベロッパーがアプリ開発関連の設定を構成することをサポートしています。
デバイス実装は開発者向けオプションに一貫したエクスペリエンスを提供しなければならず、デバイス実装は:
- [C-0-1] android.settings.APPLICATION_DEVELOPMENT_SETTINGS インテントを使用して、アプリ開発関連の設定を表示しなければなりません。アップストリームの Android 実装では、デフォルトで開発者向けオプション メニューが非表示になっており、ユーザーが [設定] > [デバイス情報] > [ビルド番号] メニュー アイテムを 7 回タップすると開発者向けオプションを起動できます。
- [C-0-2] デフォルトで開発者向けオプションを非表示にしなければなりません。
- [C-0-3] 開発者向けオプションを有効にするために、あるサードパーティ アプリを別のアプリより優先して扱うことのない、明確なメカニズムを提供しなければなりません。開発者向けオプションを有効にする方法を説明する公開ドキュメントまたはウェブサイトを提供しなければなりません。このドキュメントまたはウェブサイトは、Android SDK ドキュメントからリンクできなければなりません。
- 開発者向けオプションが有効になっており、ユーザーの安全性が懸念されるときは、ユーザーに対して進行中の通知を表示すべきです。
- ユーザーの安全性が懸念されるシナリオでは、メニューを非表示または無効にして、開発者向けオプション メニューへのアクセスを一時的に制限しても構いません。
7. ハードウェアの互換性
デバイスに、サードパーティ デベロッパー向けの API を持つ特定のハードウェア コンポーネントが含まれる場合:
- [C-0-1] デバイス実装は、Android SDK ドキュメントに記載されているとおり、その API を実装しなければなりません。
任意であると明記されているハードウェア コンポーネントを SDK の API が操作し、デバイス実装がそのコンポーネントを備えていない場合:
- [C-0-2] そのような場合でも、コンポーネント API の完全なクラス定義(SDK に記載)を提示しなければなりません。
- [C-0-3] API の動作は、なんらかの合理的な方法で NoOps として実装しなければなりません。
- [C-0-4] API メソッドは、SDK ドキュメントで許可されている場合、null 値を返さなければなりません。
- [C-0-5] API メソッドは、null 値が SDK ドキュメントで許可されていないクラスの NoOps 実装を返さなければなりません。
- [C-0-6] API メソッドは、SDK ドキュメントに記載されていない例外をスローしてはなりません。
- [C-0-7] デバイス実装は、同じビルドのフィンガープリントについて、android.content.pm.PackageManager クラスの
getSystemAvailableFeatures()
メソッドとhasSystemFeature(String)
メソッドを介して正確なハードウェア構成情報を一貫してレポートしなければなりません。
これらの要件が適用されるシナリオの典型例は、テレフォニー API です。電話以外のデバイスであっても、これらの API を妥当な NoOps として実装しなければなりません。
7.1. ディスプレイとグラフィック
Android には、さまざまなハードウェア構成さまざまなハードウェア ディスプレイと構成でサードパーティ アプリが適切に動作するように、デバイスに合わせてアプリアセットと UI レイアウトを自動的に調整する機能があります。Android 互換ディスプレイは、デベロッパー向け Android - 画面互換性の概要、このセクション 7.1 とそのサブセクションに記載されているすべての動作と API、および、この CDD のセクション 2 に記載されているその他すべてのデバイスタイプ固有の動作を実装するディスプレイ画面です。すべてのサードパーティ Android 互換アプリを実行できる Android 互換ディスプレイでは、このセクションで詳述するように、デバイス実装はこれらの API と動作を適切に実装しなければなりません。
新しい要件の開始
デバイス実装は:
- [C-0-1] デフォルトでサードパーティ アプリを Android 互換ディスプレイにのみレンダリングしなければなりません。
新しい要件の終了
このセクションの要件で言及する単位の定義は次のとおりです。
- 物理的な対角サイズ。ディスプレイの点灯部分の、2 つの相対する隅の間の距離(インチ単位)。
1 インチあたりのドット数(dpi)密度。1 インチの水平または垂直直線スパンで囲まれるピクセル数。1 インチあたりのピクセル数(ppi または dpi)で表されます。dpi 値ppi 値と dpi 値が記載されている場合は、水平方向と垂直方向の両方の dpi が記載範囲内に収まらなければなりません。- アスペクト比。画面の長辺と短辺のピクセル数の比。たとえば 480x854 ピクセルのディスプレイは 854/480 = 1.779、すなわち約「16:9」となります。
- 密度非依存ピクセル(dp)。
160 dpi の画面密度 160 の画面に正規化された仮想ピクセル単位。密度 d、ピクセル数 p、密度非依存ピクセル数 dp について、ピクセル数 = dps * (密度/160)dp = (160 / d) * p として計算します。
7.1.1. 画面構成
7.1.1.1. 画面サイズと形状
Android UI フレームワークはさまざまな論理画面レイアウト サイズをサポートしており、アプリは SCREENLAYOUT_SIZE_MASK
と Configuration.smallestScreenWidthDp
を使用して、Configuration.screenLayout
を介して現在の構成の画面レイアウト サイズをクエリできます。
デバイス実装は:
[C-0-1] Android SDK ドキュメントで定義されているとおり、
Configuration.screenLayout
について、正しいレイアウト サイズをレポートしなければなりません。具体的には、デバイス実装は、下記のとおり正確な論理密度非依存ピクセル(dp)画面寸法をレポートしなければなりません。Configuration.uiMode
が UI_MODE_TYPE_WATCH 以外の値に設定され、Configuration.screenLayout
についてsmall
サイズをレポートするデバイスは、少なくとも 426 dp x 320 dp でなければなりません。Configuration.screenLayout
についてnormal
サイズをレポートするデバイスは、少なくとも 480 dp x 320 dp でなければなりません。Configuration.screenLayout
についてlarge
サイズをレポートするデバイスは、少なくとも 640 dp x 480 dp でなければなりません。Configuration.screenLayout
についてxlarge
サイズをレポートするデバイスは、少なくとも 960 dp x 720 dp でなければなりません。
[C-0-2] Android SDK ドキュメントに記載されているとおり、AndroidManifest.xml の <
supports-screens
> 属性を通じて、アプリによる所定の画面サイズのサポートを正しく使用しなければなりません。隅の丸い Android 互換ディスプレイであっても構いません。
UI_MODE_TYPE_NORMAL
サイズ構成が可能な画面をサポートし、隅の丸い Android 互換ディスプレイが含まれる物理ディスプレイを使用して画面をレンダリングする場合、デバイス実装は:
[C-1-1] 各ディスプレイで次の要件のうち少なくとも 1 つを満たさなければなりません。
- 丸い隅の半径が 38 dp 以下。
1518 dp x1518 dp のボックスを論理ディスプレイのそれぞれの隅に固定したとき、各ボックスの少なくとも 1 ピクセルが画面に表示される。
隅が直角の表示モードに切り替えるユーザー アフォーダンスを含むべきです。
新しい要件の開始
NO_KEYS
キーボードの構成のみが可能で、UI_MODE_TYPE_NORMAL
UI モードの構成のサポートをレポートする場合、デバイス実装は:
- [C-4-1] ディスプレイ カットアウトを除くレイアウト サイズを 596 dp x 384 dp 以上にしなければなりません。
新しい要件の終了
折りたたみ式の Android 互換ディスプレイが含まれるか、複数のディスプレイ間の折りたたみヒンジが含まれ、そうしたディスプレイをサードパーティ アプリでレンダリングできるようにする場合、デバイス実装は:
- [C-2-1] Window Manager Jetpack ライブラリで使用される、拡張機能 API の利用可能な最新安定版またはサイドカー API の安定版を実装しなければなりません。
折りたたみ式の Android 互換ディスプレイが含まれるか、複数のディスプレイ間の折りたたみヒンジが含まれる場合、また全画面アプリ ウィンドウを横切ってヒンジで動くか折りたたまれる場合、デバイス実装は:
- [C-3-1] 拡張機能 API またはサイドカー API を通じて、ヒンジまたは折りたたみの位置、境界、状態をアプリにレポートしなければなりません。
サイドカー API または拡張機能 API の正しい実装の詳細については、Window Manager Jetpack の公開ドキュメントをご覧ください。
新しい要件の開始
1 つ以上の折りたたみ式の Android 互換ディスプレイ領域が含まれるか、複数の Android 互換ディスプレイ パネル領域間の折りたたみヒンジが含まれ、そうしたディスプレイ領域をアプリで利用できるようにする場合、デバイス実装は:
- [C-4-1] WindowManager Extensions に記載されているとおりに、正しいバージョンの Window Manager Extensions API レベルを実装しなければなりません。
新しい要件の終了
7.1.1.2. 画面のアスペクト比
Android 互換ディスプレイの物理ディスプレイのアスペクト比に制限はありませんが、サードパーティ アプリがレンダリングする、view.Display
API と Configuration API を通じてレポートされる高さと幅の値から得られる論理ディスプレイのアスペクト比は、次の要件を満たさなければなりません。
[C-0-1]
Configuration.uiMode
がUI_MODE_TYPE_NORMAL
に設定されたデバイス実装は、アプリが次の条件のいずれかを満たす場合を除き、アスペクト比の値を 1.86(おおよそ 16:9)以下にしなければなりません。- アプリが、
android.max_aspect
メタデータ値を通じてより大きな画面アスペクト比のサポートを宣言した。 - アプリが、android:resizeableActivity 属性を介してサイズ変更可能であることを宣言する。
- アプリが、API レベル 24 以降をターゲットとしており、許可されるアスペクト比を制限する
android:maxAspectRatio
を宣言しない。
- アプリが、
[C-0-3]
Configuration.uiMode
がUI_MODE_TYPE_WATCH
に設定されたデバイス実装は、アスペクト比の値を 1.0(1:1)に設定しなければなりません。
7.1.1.3. 画面密度
Android UI フレームワークは、アプリ デベロッパーがアプリリソースをターゲットにできるように、標準的な論理密度のセットを定義しています。
デバイス実装は:
- [C-0-1]
デフォルトで、デバイス実装はDENSITY_DEVICE_STABLE
API を通じてDisplayMetrics
にリストされている論理 Android フレームワーク密度を 1 つだけレポートしなければならず、この値は各物理ディスプレイで静的な値にしなければなりません。この値はいかなるときも変更してはなりません。ただしデバイスは、初回起動後にユーザーが設定したディスプレイ設定(表示サイズなど)の変更に従って、異なる任意の密度DisplayMetrics.density
をレポートしても構いません。
- デバイス実装は、画面の物理密度に数値的に最も近い標準 Android フレームワーク密度を定義すべきです。ただし、その論理密度によって、レポートされる画面サイズがサポート対象の最小値未満になる場合を除きます。物理密度に数値的に最も近い標準 Android フレームワーク密度が、サポート対象の最小互換画面サイズ(幅 320 dp)よりも小さい画面サイズとなる場合、デバイス実装は、次に近い標準 Android フレームワーク密度をレポートすべきです。
新しい要件の開始
- 画面の物理密度に数値的に最も近い標準 Android フレームワーク密度、または同等なハンドヘルド デバイスの画角の測定値に対応する値を定義すべきです。
新しい要件の終了
デバイスの表示サイズを変更するアフォーダンスがあるを提供する場合、デバイス実装は:
- [C-1-1]
表示サイズを、ディスプレイを、DENSITY_DEVICE_STABLE
ネイティブ密度の 1.5 倍よりも大きく調整したり、320 dp(リソース修飾子 sw320dp と同等)よりも小さい有効最小画面寸法を生成したりしてはなりません。 - [C-1-2]
表示サイズを、ディスプレイを、DENSITY_DEVICE_STABLE
ネイティブ密度の 0.85 倍よりも小さく調整してはなりません。 - 優れたユーザビリティと一貫したフォントサイズを実現するために、上記の制限を遵守しつつ、次に示すネイティブ ディスプレイ オプションの調整を行えるようにすることが推奨されます。
- 小: 0.85 倍
- デフォルト: 1 倍(ネイティブ ディスプレイ スケール)
- 中: 1.15 倍
- 大: 1.3 倍
- 特大 1.45 倍
7.1.2. ディスプレイの指標
Android 互換ディスプレイまたは Android 互換ディスプレイ画面への動画出力が含まれる場合、デバイス実装は:
- [C-1-1]
android.util.DisplayMetrics
API で定義されたすべての Android 互換ディスプレイ指標について正しい値をレポートしなければなりません。
埋め込み画面または動画出力が含まれない場合、デバイス実装は:
- [C-2-1] エミュレートされたデフォルトの
view.Display
について、android.util.DisplayMetrics
API で定義されているとおり、Android 互換ディスプレイの値を正しくレポートしなければなりません。
7.1.3. 画面の向き
デバイス実装は:
- [C-0-1] サポートする画面の向き(
android.hardware.screen.portrait
、android.hardware.screen.landscape
)をレポートしなければならず、サポート対象の向きのうち少なくとも 1 つをレポートしなければなりません。たとえば、テレビやノートパソコンなど、固定の横向き画面を備えたデバイスはandroid.hardware.screen.landscape
のみをレポートすべきです。 - [C-0-2]
android.content.res.Configuration.orientation
、android.view.Display.getOrientation()
、またはその他の API を介してクエリされたときは常に、デバイスの現在の画面の向きについて、正しい値をレポートしなければなりません。
画面の向きを両方ともサポートする場合、デバイス実装は:
- [C-1-1] アプリが画面の向きを動的に横向きまたは縦向きに変更することをサポートしなければなりません。つまりデバイスは、特定の画面の向きに関するアプリからのリクエストを尊重しなければなりません。
- [C-1-2] 画面の向きを変更するとき、レポート対象の画面サイズまたは密度を変更してはなりません。
- 横向きまたは縦向きのいずれかをデフォルトとして選択しても構いません。
7.1.4. 2D と 3D のグラフィック アクセラレーション
7.1.4.1 OpenGL ES
デバイス実装は:
- [C-0-1] マネージド API(
GLES10.getString()
メソッドなど)とネイティブ API を通じて、サポート対象の OpenGL ES バージョン(1.1、2.0、3.0、3.1、3.2)を正しく識別しなければなりません。 - [C-0-2] サポート対象として識別されたすべての OpenGL ES バージョンについて、対応するマネージド API とネイティブ API をサポートしなければなりません。
画面または動画出力が含まれる場合、デバイス実装は:
- [C-1-1] Android SDK ドキュメントに盛り込まれ、詳述されているとおり、OpenGL ES 1.1 と 2.0 を両方ともサポートしなければなりません。
- [C-SR-1] OpenGL ES 3.1 をサポートすることが強く推奨されます。
- OpenGL ES 3.2 をサポートすべきです。
OpenGL ES dEQP テストはいくつかのテストリストに分割されており、それぞれに日付 / バージョンが関連付けられています。Android ソースツリーの external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
にあります。自己申告レベルで OpenGL ES をサポートするデバイスは、このレベルとそれより前のテストリストすべてで dEQP テストに合格できることを示しています。
OpenGL ES のいずれかのバージョンをサポートする場合、デバイス実装は:
- [C-2-1] OpenGL ES マネージド API とネイティブ API を介して、実装されている他の OpenGL ES 拡張機能をレポートしなければならず、また逆に、サポートしていない拡張機能の文字列をレポートしてはなりません。
- [C-2-2] 拡張機能
EGL_KHR_image
、EGL_KHR_image_base
、EGL_ANDROID_image_native_buffer
、EGL_ANDROID_get_native_client_buffer
、EGL_KHR_wait_sync
、EGL_KHR_get_all_proc_addresses
、EGL_ANDROID_presentation_time
、EGL_KHR_swap_buffers_with_damage
、EGL_ANDROID_recordable
、EGL_ANDROID_GLES_layers
をサポートしなければなりません。 - [C-2-3]
android.software.opengles.deqp.level
機能フラグを介してサポートする OpenGL ES dEQP テストの最大バージョンをレポートしなければなりません。 - [C-2-4]
android.software.opengles.deqp.level
機能フラグでレポートされるとおり、少なくともバージョン 132383489 をサポートしなければなりません(2020 年 3 月 1 日から)。 - [C-2-5] サポート対象の OpenGL ES バージョンごとに、バージョン 132383489 から
android.software.opengles.deqp.level
機能フラグで指定されたバージョンまでのテストリストにある、すべての OpenGL ES dEQP テストに合格しなければなりません。 - [C-SR-2] 拡張機能
EGL_KHR_partial_update
とOES_EGL_image_external
をサポートすることが強く推奨されます。 getString()
メソッドを介して、サポート対象のテクスチャ圧縮形式(通常はベンダー固有)を正確にレポートすべきです。EGL_IMG_context_priority
拡張機能とEGL_EXT_protected_content
拡張機能をサポートすべきです。
OpenGL ES 3.0、3.1 または 3.2 のサポートを宣言する場合、デバイス実装は:
- [C-3-1] libGLESv2.so ライブラリの OpenGL ES 2.0 関数シンボルに加え、これらのバージョンについて、対応する関数シンボルをエクスポートしなければなりません。
- [C-SR-3] 拡張機能
OES_EGL_image_external_essl3
をサポートすることが強く推奨されます。
OpenGL ES 3.2 をサポートする場合、デバイス実装は:
- [C-4-1] OpenGL ES Android 拡張機能パック全体をサポートしなければなりません。
OpenGL ES Android 拡張機能パック全体をサポートする場合、デバイス実装は:
- [C-5-1]
android.hardware.opengles.aep
機能フラグを通じてサポートを識別しなければなりません。
拡張機能 EGL_KHR_mutable_render_buffer
のサポートを公開する場合、デバイス実装は:
- [C-6-1] 拡張機能
EGL_ANDROID_front_buffer_auto_refresh
もサポートしなければなりません。
7.1.4.2 Vulkan
Android は、高パフォーマンスの 3D グラフィックを実現する、低オーバーヘッドのクロスプラットフォーム API である Vulkan をサポートしています。
OpenGL ES 3.1 をサポートする場合、デバイス実装は:
- [C-SR-1] Vulkan 1.3 のサポートを含むことが強く推奨されます。
- [C-4-1] Vulkan バリアント バージョンをサポートしてはなりません(Vulkan コアバージョンのバリアント部分はゼロでなければなりません)。
画面または動画出力が含まれる場合、デバイス実装は:
- [C-SR-2] Vulkan 1.3 のサポートを含むことが強く推奨されます。
Vulkan dEQP テストはいくつかのテストリストに分割されており、それぞれに日付 / バージョンが関連付けられています。Android ソースツリーの external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
にあります。自己申告レベルで Vulkan をサポートするデバイスは、このレベルとそれより前のテストリストすべてで dEQP テストに合格できることを示しています。
Vulkan 1.0 以降のサポートが含まれる場合、デバイス実装は:
- [C-1-1] 機能フラグ
android.hardware.vulkan.level
とandroid.hardware.vulkan.version
で正しい整数値をレポートしなければなりません。 - [C-1-2] Vulkan ネイティブ API
vkEnumeratePhysicalDevices()
について、VkPhysicalDevice
を少なくとも 1 つ列挙しなければなりません。 - [C-1-3] 列挙した
VkPhysicalDevice
ごとにVulkan 1.0Vulkan 1.1 API を完全に実装しなければなりません。 - [C-1-4] Vulkan ネイティブ API
vkEnumerateInstanceLayerProperties()
とvkEnumerateDeviceLayerProperties()
を通じて、アプリ パッケージのネイティブ ライブラリ ディレクトリにあるlibVkLayer*.so
というネイティブ ライブラリに含まれるレイヤを列挙しなければなりません。 - [C-1-5] アプリに
true
として設定されたandroid:debuggable
属性またはtrue
に設定されたメタデータcom.android.graphics.injectLayers.enable
がある場合を除き、アプリ パッケージ外のライブラリによって提供されるレイヤの列挙、Vulkan API をトレースまたはインターセプトする別の方法の提供をしてはなりません。 - [C-1-6] Vulkan ネイティブ API を介してサポートする拡張機能の文字列をすべてレポートしなければならず、また逆に、正しくサポートしない拡張機能の文字列をレポートしてはなりません。
- [C-1-7] 拡張機能 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_incremental_present をサポートしなければなりません。
- [C-1-8]
android.software.vulkan.deqp.level
機能フラグを介してサポートする Vulkan dEQP テストの最大バージョンをレポートしなければなりません。 - [C-1-9]
android.software.vulkan.deqp.level
機能フラグでレポートされるとおり、少なくともバージョン132317953
をサポートしなければなりません(2019 年 3 月 1 日から)。 - [C-1-10] バージョン
132317953
とandroid.software.vulkan.deqp.level
機能フラグで指定されたバージョンの間のテストリストにあるすべての Vulkan dEQP テストに合格しなければなりません。 - [C-1-11] 拡張機能 VK_KHR_video_queue、VK_KHR_video_decode_queue、または VK_KHR_video_encode_queue のサポートを列挙してはなりません。
- [C-SR-3] 拡張機能
VK_KHR_driver_properties
とVK_GOOGLE_display_timing
をサポートすることが強く推奨されます。
VkPhysicalDeviceProtectedMemoryFeatures
とVK_EXT_global_priority
をサポートすべきです。
- [C-1-12] 拡張機能 VK_KHR_performance_query のサポートを列挙してはなりません。
- [C-1-13] Android ベースライン 2021 プロファイルで規定されている要件を満たさなければなりません。
- [C-SR-4] Android ベースライン 2022 プロファイルで規定されている要件を満たすことが強く推奨されます。
新しい要件の開始
[C-SR-5]
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
とVK_EXT_global_priority
をサポートすることが強く推奨されます。[C-SR-6] HWUI で
SkiaVk
を使用することが強く推奨されます。
新しい要件の終了
Vulkan 1.0 のサポートが含まれない場合、デバイス実装は:
- [C-2-1] Vulkan 機能フラグ(例:
android.hardware.vulkan.level
、android.hardware.vulkan.version
)を宣言してはなりません。 - [C-2-2] Vulkan ネイティブ API
vkEnumeratePhysicalDevices()
についてVkPhysicalDevice
を列挙してはなりません。
Vulkan 1.1 のサポートが含まれ、こちらに記載されている Vulkan 機能フラグのいずれかを宣言する場合、デバイス実装は:
- [C-3-1]
SYNC_FD
外部セマフォ型とハンドル型、VK_ANDROID_external_memory_android_hardware_buffer
拡張機能のサポートを公開しなければなりません。
新しい要件の開始
- [C-SR-7]
VK_KHR_external_fence_fd
拡張機能をサードパーティ アプリで利用できるようにし、こちらに記載されているとおりに、アプリによる POSIX ファイル記述子へのフェンス ペイロードのエクスポートと、POSIX ファイル記述子からのフェンス ペイロードのインポートを可能にすることが強く推奨されます。
新しい要件の終了
7.1.4.3 RenderScript
- [C-0-1] デバイス実装は、Android SDK ドキュメントに詳述されているとおり、Android RenderScript をサポートしなければなりません。
7.1.4.4 2D グラフィック アクセラレーション
Android には、マニフェスト タグ android:hardwareAccelerated または直接 API 呼び出しを使用することで、アプリ、アクティビティ、ウィンドウ、ビューのレベルで 2D グラフィックのハードウェア アクセラレーションを有効にすることを、アプリで宣言するメカニズムがあります。
デバイス実装は:
- [C-0-1] ハードウェア アクセラレーションをデフォルトで有効にしなければならず、デベロッパーが android:hardwareAccelerated="false” を設定するか、Android View API を通じてハードウェア アクセラレーションを直接無効にすることでリクエストした場合、ハードウェア アクセラレーションを無効にしなければなりません。
- [C-0-2] ハードウェア アクセラレーションに関する Android SDK ドキュメントに合致する動作を示さなければなりません。
Android には、ハードウェア アクセラレーションの OpenGL ES テクスチャを UI 階層のレンダリング ターゲットとしてデベロッパーが直接統合できる、TextureView オブジェクトがあります。
デバイス実装は:
- [C-0-3] TextureView API をサポートしなければならず、アップストリームの Android 実装と合致する動作を示さなければなりません。
7.1.4.5 広色域ディスプレイ
Configuration.isScreenWideColorGamut()
を通じて広色域ディスプレイのサポートを主張する場合、デバイス実装は:
- [C-1-1] 色調整されたディスプレイがなければなりません。
- [C-1-2] sRGB 色域全体を CIE 1931 xyY 空間でカバーする色域のディスプレイがなければなりません。
- [C-1-3] 色域の面積が CIE 1931 xyY 空間で DCI-P3 の少なくとも 90% であるディスプレイがなければなりません。
- [C-1-4] OpenGL ES 3.1 または 3.2 をサポートし、適切にレポートしなければなりません。
- [C-1-5] 拡張機能
EGL_KHR_no_config_context
、EGL_EXT_pixel_format_float
、EGL_KHR_gl_colorspace
、EGL_EXT_gl_colorspace_scrgb
、EGL_EXT_gl_colorspace_scrgb_linear
、EGL_EXT_gl_colorspace_display_p3
、EGL_EXT_gl_colorspace_display_p3_linear
、EGL_EXT_gl_colorspace_display_p3_passthrough
のサポートをアドバタイズしなければなりません。 - [C-SR-1]
GL_EXT_sRGB
をサポートすることが強く推奨されます。
逆に、広色域ディスプレイをサポートしない場合、デバイス実装は:
- [C-2-1] 画面色域が未定義であっても、CIE 1931 xyY 空間で sRGB の 100% 以上をカバーすべきです。
7.1.5. レガシーアプリの互換モード
Android は、以前の画面サイズに依存しない Andrdoid の旧バージョン用に開発されていないレガシーアプリを活用するために、フレームワークが「標準」画面サイズ相当(幅 320 dp)のモードで動作する「互換モード」を指定します。
7.1.6. 画面技術
Android プラットフォームには、アプリがリッチ グラフィックを Android 互換ディスプレイにレンダリングできるようにする API があります。このドキュメントで特に許可されていない限り、デバイスは、Android SDK で定義されているこれらの API をすべてサポートしなければなりません。
デバイス実装の Android 互換ディスプレイはすべて:
- [C-0-1] 16 ビットカラー グラフィックをレンダリングできなければなりません。
- 24 ビットカラー グラフィックに対応したディスプレイをサポートすべきです。
- [C-0-2] アニメーションをレンダリングできなければなりません。
- [C-0-3] ピクセル アスペクト比(PAR)が 0.9 から 1.15 の間でなければなりません。つまり、ピクセル アスペクト比は、許容差 10~15% でほぼ正方形(1.0)でなければなりません。
7.1.7. セカンダリ ディスプレイ
Android は、セカンダリ Android 互換ディスプレイをサポートしており、メディア共有機能と、外部ディスプレイにアクセスするためのデベロッパー API が有効になります。
有線、無線、または埋め込み式いずれかの追加のディスプレイ接続を介して外部ディスプレイをサポートする場合、デバイス実装は:
- [C-1-1] Android SDK ドキュメントに記載されているとおり、
DisplayManager
システム サービスと API を実装しなければなりません。
7.2. 入力デバイス
デバイス実装は:
- [C-0-1] タッチスクリーンまたはタップ以外のナビゲーションなど、UI 要素間を移動するための入力メカニズムを含まなければなりません。
7.2.1. キーボード
サードパーティのインプット メソッド エディタ(IME)アプリのサポートが含まれる場合、デバイス実装は:
- [C-1-1]
android.software.input_methods
機能フラグを宣言しなければなりません。 - [C-1-2]
Input Management Framework
を完全に実装しなければなりません。 - [C-1-3] ソフトウェア キーボードをプリインストールしなければなりません。
デバイス実装は:
- [C-0-1] android.content.res.Configuration.keyboard で指定された形式(QWERTY または 12 キー)のいずれかと一致しないハードウェア キーボードを含んではなりません。
- 追加のソフトウェア キーボード実装を含むべきです。
- ハードウェア キーボードを含んでも構いません。
7.2.2. タップ以外のナビゲーション
Android は、タップ以外のナビゲーションのメカニズムとして、D-pad、トラックボール、ホイールをサポートしています。
デバイス実装は:
- [C-0-1] android.content.res.Configuration.navigation について、正しい値をレポートしなければなりません。
タップ以外のナビゲーションがない場合、デバイス実装は:
- [C-1-1] 入力管理エンジンと互換性のある、テキストの選択と編集のための妥当な代替ユーザー インターフェース メカニズムを提供しなければなりません。アップストリームの Android オープンソース実装には、タップ以外のナビゲーション入力がないデバイスでの使用に適した選択メカニズムがあります。
7.2.3. ナビゲーション キー
通常、専用の物理ボタンまたは区分けされたタッチスクリーン部分の操作を介して提供されるホーム機能、履歴機能、戻る機能は、Android ナビゲーション パラダイムに不可欠であり、したがってデバイス実装は:
- [C-0-1] テレビデバイス実装のために、
<intent-filter>
がACTION=MAIN
とCATEGORY=LAUNCHER
またはCATEGORY=LEANBACK_LAUNCHER
で設定されたアクティビティを持つインストール済みのアプリを起動するユーザー アフォーダンスを提供しなければなりません。ホーム機能は、このユーザー アフォーダンスのためのメカニズムであるべきです。 - 履歴機能と戻る機能のためのボタンを提供すべきです。
ホーム機能、履歴機能、または戻る機能が提供される場合、これらの機能は:
- [C-1-1] いずれかがアクセス可能な場合、単一の操作(タップ、ダブルクリック、ジェスチャーなど)によってアクセス可能でなければなりません。
- [C-1-2] どの単一の操作が各機能をトリガーするかの明確な表示を提供しなければなりません。そうした表示の例としては、ボタンにアイコンを表示する、画面のナビゲーション バー部分にソフトウェア アイコンを表示する、開封時の初期設定中にガイド付きの段階的なデモフローを通じてユーザーに説明する、などが挙げられます。
デバイス実装は:
[C-SR-1] Android 4.0 以降、メニュー機能はサポートが終了してアクションバーに置き換えられたため、メニュー機能のための入力メカニズムを提供しないことが強く推奨されます。
[C-SR-2] すべてのナビゲーション機能をキャンセル可能として提供することが強く推奨されます。「キャンセル可能」とは、スワイプが特定のしきい値を超えても解放されない場合に、ユーザーがナビゲーション機能(「ホーム画面に移動する」、「戻る」など)を実行できないようにする機能を指します。
メニュー機能を提供する場合、デバイス実装は:
- [C-2-1] アクション オーバーフロー メニューのポップアップが空ではなく、アクションバーが表示されているときは常に、アクション オーバーフロー ボタンを表示しなければなりません。
- [C-2-2] アクションバーのオーバーフロー ボタンを選択することで表示されるアクション オーバーフロー ポップアップの位置を変更してはなりませんが、メニュー機能を選択することで表示されるときは、アクション オーバーフロー ポップアップを画面上の変更された位置にレンダリングしても構いません。
メニュー機能を提供しない場合、下位互換性のために、デバイス実装は: * [C-3-1] targetSdkVersion
が 10 未満のときは、物理ボタン、ソフトウェア キー、ジェスチャーのいずれかによって、メニュー機能をアプリで利用できるようにしなければなりません。このメニュー機能は、他のナビゲーション機能とともに非表示になっている場合を除き、アクセス可能にすべきです。
アシスト機能を提供する場合、デバイス実装は:
- [C-4-1] 他のナビゲーション キーがアクセス可能な場合、単一の操作(タップ、ダブルクリック、ジェスチャーなど)によってアシスト機能にアクセスできるようにしなければなりません。
- [C-SR-3] この指定操作として、ホーム機能の長押しを使用することが強く推奨されます。
ナビゲーション キーを表示するために画面の区分けされた部分を使用する場合、デバイス実装は:
- [C-5-1] ナビゲーション キーは、アプリでは利用できない、画面の区分けされた部分を使用しなければならず、アプリで利用できる画面部分を隠したり、利用を妨げたりしてはなりません。
- [C-5-2] ディスプレイの一部を、セクション 7.1.1 で規定する要件を満たすアプリで利用できるようにしなければなりません。
- [C-5-3] SDK に記載されているとおり、
View.setSystemUiVisibility()
API メソッドを通じてアプリが設定したフラグを使用して、この画面の区分けされた部分(ナビゲーション バー)が適切に非表示になるようにしなければなりません。
ナビゲーション機能が画面上のジェスチャーベースのアクションとして提供される場合:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
は、ホーム ジェスチャー認識エリアをレポートするためにのみ使用しなければなりません。 - [C-6-2]
View#setSystemGestureExclusionRects()
を介して(WindowInsets#getMandatorySystemGestureInsets()
外で)フォアグラウンド アプリによって提供される除外矩形内で開始されるジェスチャーは、View#setSystemGestureExclusionRects()
のドキュメントで規定されているとおり、除外矩形が最大除外制限内で許可されている限り、ナビゲーション機能用にインターセプトしてはなりません。 - [C-6-3] フォアグラウンド アプリに
MotionEvent.ACTION_DOWN
イベントが以前に送信されていた場合、タップがシステム ジェスチャー用にインターセプトされ始めたら、フォアグラウンド アプリにMotionEvent.ACTION_CANCEL
イベントを送信しなければなりません。 - [C-6-4] 画面上のボタンベースのナビゲーションに切り替えるユーザー アフォーダンスを(設定などで)提供しなければなりません。
- 現在の画面の向きで下端から上にスワイプした場合にホーム機能を提供すべきです。
- ホーム ジェスチャーと同じエリアから上にスワイプし、保持してから指を離した場合に履歴機能を提供すべきです。
WindowInsets#getMandatorySystemGestureInsets()
内で開始されるジェスチャーは、View#setSystemGestureExclusionRects()
を介してフォアグラウンド アプリによって提供される除外矩形の影響を受けるべきではありません。
ナビゲーション機能が、現在の画面の向きで左右端のどこからでも提供される場合:
- [C-7-1] ナビゲーション機能は「戻る」でなければならず、現在の画面の向きで左右端からスワイプした場合に提供しなければなりません。
- [C-7-2] カスタムのスワイプ可能なシステムパネルが左右どちらかの端で提供される場合、ドラッグするとそのパネルが呼び出され、戻る機能は呼び出されないことを明確かつ永続的に表示して、画面の上部 1/3 の範囲内に配置しなければなりません。システムパネルは、画面端の上部 1/3 未満に収まるようにユーザーが設定しても構いませんが、端の 1/3 より長くなってはなりません。
- [C-7-3] フォアグラウンド アプリに View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT、または WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE のフラグが設定されている場合、端からのスワイプで、SDK に記載されている AOSP の実装どおりに動作しなければなりません。
- [C-7-4] フォアグラウンド アプリに View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT、または WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE のフラグが設定されている場合、カスタムのスワイプ可能なシステムパネルは、AOSP の実装どおり、ユーザーがシステムバー(ナビゲーション バー、ステータスバー)を表示するか省略表示を解除するまで、非表示にしなければなりません。
「戻る」ナビゲーション機能が提供されていて、ユーザーが「戻る」ジェスチャーをキャンセルした場合:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
を呼び出さなければなりません。 - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
を呼び出してはなりません。 - [C-8-3] KEYCODE_BACK イベントをディスパッチしてはなりません。
「戻る」ナビゲーション機能が提供されているが、フォアグラウンド アプリに OnBackInvokedCallback
が登録されていない場合:
- システムは、AOSP で提供されているように、ユーザーが戻ることを示唆するフォアグラウンド アプリのアニメーションを提供すべきです。
システム API setNavBarMode
のサポートを提供し、それによって android.permission.STATUS_BAR
権限を持つシステムアプリがナビゲーション バーのモードを設定できるようにする場合、デバイス実装は:
- [C-9-1] AOSP コードで提供されているとおり、子供向けアイコンまたはボタンベースのナビゲーションのサポートを提供しなければなりません。
7.2.4. タッチスクリーン入力
Android は、タッチスクリーン、タッチパッド、疑似タップ入力デバイスなど、さまざまなポインタ入力システムをサポートしています。タッチスクリーンベースのデバイス実装は、画面上のアイテムを直接操作しているような印象をユーザーに与えるディスプレイに関連付けられます。ユーザーが画面に直接触れているため、操作中のオブジェクトを示すアフォーダンスを追加する必要はありません。
デバイス実装は:
- なんらかのポインタ入力システム(マウスのようなもの、またはタップ)があるべきです。
- 完全に独立してトラックされるポインタをサポートすべきです。
プライマリ Android 互換ディスプレイ上のタッチスクリーン(シングルタップ以上)が含まれる場合、デバイス実装は:
- [C-1-1]
Configuration.touchscreen
API フィールドについてTOUCHSCREEN_FINGER
をレポートしなければなりません。 - [C-1-2] 機能フラグ
android.hardware.touchscreen
とandroid.hardware.faketouch
をレポートしなければなりません。
プライマリ Android 互換ディスプレイで複数のタップをトラックできるタッチスクリーンが含まれる場合、デバイス実装は:
- [C-2-1] デバイス上の具体的なタッチスクリーンの種類に応じた、該当する機能フラグ
android.hardware.touchscreen.multitouch
、android.hardware.touchscreen.multitouch.distinct
、android.hardware.touchscreen.multitouch.jazzhand
をレポートしなければなりません。
プライマリ Android 互換ディスプレイでの入力についてマウスやトラックボールなどの外部入力デバイスに依存し(つまり画面に直接触れず)、セクション 7.2.5 の疑似タップの要件を満たしている場合、デバイス実装は:
- [C-3-1]
android.hardware.touchscreen
で始まる機能フラグをレポートしてはなりません。 - [C-3-2]
android.hardware.faketouch
のみをレポートしなければなりません。 - [C-3-3]
Configuration.touchscreen
API フィールドについてTOUCHSCREEN_NOTOUCH
をレポートしなければなりません。
7.2.5. 疑似タップ入力
疑似タップ インターフェースは、タッチスクリーン機能のサブセットに近いユーザー入力システムを提供します。たとえば、画面上のカーソルを操作するマウスまたはリモコンはタップに似ていますが、ユーザーは最初にポイントするかフォーカスしてからクリックする必要があります。マウス、トラックパッド、ジャイロベースのエアマウス、ジャイロポインタ、ジョイスティック、マルチタッチ トラックパッドなど、多くの入力デバイスが擬似タップ インターフェースをサポートできます。Android には、機能定数 android.hardware.faketouch があります。これは、タッチベースの入力を適切にエミュレートできる(基本的なジェスチャーのサポートを含む)、マウスやトラックパッドなど忠実度の高いタップ以外の(ポインタベースの)入力デバイスに対応し、タッチスクリーン機能のエミュレートされたサブセットをデバイスがサポートしていることを示します。
タッチスクリーンは含まれないが、利用する予定の別のポインタ入力システムが含まれる場合、デバイス実装は:
android.hardware.faketouch
機能フラグのサポートを宣言すべきです。
android.hardware.faketouch
のサポートを宣言する場合、デバイス実装は:
- [C-1-1] ポインタ位置の絶対 X 画面位置と絶対 Y 画面位置をレポートし、画面にビジュアル ポインタを表示しなければなりません。
- [C-1-2] ポインタが画面上を上下するときに発生する状態変化を指定するアクション コードで、タッチイベントをレポートしなければなりません。
- [C-1-3] ユーザーが画面上のオブジェクトのタップをエミュレートできるように、画面上のオブジェクトでのポインタの上下移動をサポートしなければなりません。
- [C-1-4] ユーザーが画面上のオブジェクトのダブルタップをエミュレートできるように、時間しきい値内で、画面上のオブジェクトの同じ場所におけるポインタの下移動、ポインタの上移動、ポインタの下移動からの上移動をサポートしなければなりません。
- [C-1-5] ユーザーがタップドラッグをエミュレートできるように、画面上の任意の点におけるポインタの下移動、画面上の他の任意の点へのポインタ移動、その後のポインタの上移動をサポートしなければなりません。
- [C-1-6] ユーザーが画面上のオブジェクトをフリングできるように、ポインタの下移動をサポートし、ユーザーが画面上の別の位置にオブジェクトを素早く移動してから画面上でポインタを上移動できるようにしなければなりません。
android.hardware.faketouch.multitouch.distinct
のサポートを宣言する場合、デバイス実装は:
- [C-2-1]
android.hardware.faketouch
のサポートを宣言しなければなりません。 - [C-2-2] 複数の独立したポインタ入力の個別トラッキングをサポートしなければなりません。
android.hardware.faketouch.multitouch.jazzhand
のサポートを宣言する場合、デバイス実装は:
- [C-3-1]
android.hardware.faketouch
のサポートを宣言しなければなりません。 - [C-3-2] 5 つ以上のポインタ入力の個別トラッキング(指で手をトラッキング)を完全に独立してサポートしなければなりません。
7.2.6. ゲーム コントローラのサポート
7.2.6.1. ボタン マッピング
デバイス実装は:
- [C-1-1] 下表に記載されているとおり、HID イベントを、対応する
InputEvent
定数にマッピングできなければなりません。アップストリームの Android 実装はこの要件を満たしています。
コントローラを埋め込むか、下表に記載されているイベントすべての入力手段を提供する別個のコントローラを同梱する場合、デバイス実装は:
- [C-2-1]
android.hardware.gamepad
機能フラグを宣言しなければなりません。
ボタン | HID 使用状況2 | Android ボタン |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A(96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B(97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X(99) |
Y1 | 0x09 0x0005 | KEYCODE_BUTTON_Y(100) |
D-pad 上1 D-pad 下1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-pad 左1 D-pad 右1 |
0x01 0x00393 | AXIS_HAT_X4 |
左ショルダーボタン1 | 0x09 0x0007 | KEYCODE_BUTTON_L1(102) |
右ショルダー ボタン1 | 0x09 0x0008 | KEYCODE_BUTTON_R1(103) |
左スティック クリック1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL(106) |
右スティック クリック1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR(107) |
戻る1 | 0x0c 0x0224 | KEYCODE_BACK(4) |
1 KeyEvent
2 上記の HID 使用状況は、ゲームパッド CA(0x01 0x0005)内で宣言しなければなりません。
3 この使用状況は、論理最小値 0、論理最大値 7、物理最小値 0、物理最大値 315、度単位、レポートサイズ 4 でなければなりません。論理値は、垂直軸から時計回りに定義されます。たとえば、論理値 0 は回転せず上ボタンが押されていることを表し、論理値 1 は 45 度回転し上キーと左キーの両方が押されていることを表します。
アナログ コントロール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 |
7.2.7. リモコン
デバイス固有の要件についてはセクション 2.3.1 をご覧ください。
7.3. センサー
サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプがデバイス実装に含まれる場合、デバイス実装は、センサーに関する Android SDK ドキュメントと Android オープンソース ドキュメントに記載されているとおり、その API を実装しなければなりません。
デバイス実装は:
- [C-0-1]
android.content.pm.PackageManager
クラスごとにセンサーの有無を正確にレポートしなければなりません。 - [C-0-2]
SensorManager.getSensorList()
や同様のメソッドを介してサポート対象のセンサーの正確なリストを返さなければなりません。 - [C-0-3] 他のセンサー API すべてについて合理的に動作しなければなりません(たとえば、アプリがリスナーの登録を試行したとき
true
またはfalse
のうち該当する方を返す、対応するセンサーが存在しないときはセンサー リスナーを呼び出さない、など)。
サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプが含まれる場合、デバイス実装は:
- [C-1-1] Android SDK ドキュメントで定義されているとおり、センサータイプごとに関連する国際単位系(メートル法)の値を使用して、すべてのセンサー測定値をレポートしなければなりません。
- [C-1-2] アプリ プロセッサがアクティブなとき、最大要求レイテンシが 0 ms のセンサー ストリームの場合、最大レイテンシ 100 ミリ秒 + 2 * sample_time のセンサーデータをレポートしなければなりません。この遅延にフィルタリングの遅延は含まれません。
- [C-1-3] センサーがアクティブになっている 400 ミリ秒 + 2 * sample_time 以内に最初のセンサー サンプルをレポートしなければなりません。このサンプルの正確度は 0 でも許容されます。
- [C-1-4] 連続センサーであることが Android SDK ドキュメントで示されている API の場合、デバイス実装は、ジッターが 3% 未満であるべき定期データサンプルを継続的に提供しなければなりません(ジッターは、連続するイベント間でレポートされるタイムスタンプ値の標準偏差として定義されます)。
- [C-1-5] デバイス CPU がサスペンド状態に入ること、またはサスペンド状態から復帰することを、センサー イベント ストリームが妨げてはならないということを保証しなければなりません。
- [C-1-6] Android SDK ドキュメントで定義されているとおり、ナノ秒単位でイベント時刻をレポートしなければなりません。これはイベントが発生した時刻を表し、SystemClock.elapsedRealtimeNano() クロックと同期されています。
- [C-SR-1] タイムスタンプ同期エラーが 100 ミリ秒未満であることが強く推奨され、タイムスタンプ同期エラーが 1 ミリ秒未満であるべきです。
- 複数のセンサーが有効になっているとき、消費電力は、個々のセンサーがレポートした消費電力の合計を超えるべきではありません。
上記のリストは包括的なものではありません。センサーに関する Android SDK ドキュメントと Android オープンソース ドキュメントに記載されている動作を、信頼できるものとみなします。
サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプが含まれる場合、デバイス実装は:
- [C-1-6] すべてのセンサーにゼロ以外の解像度を設定し、
Sensor.getResolution()
API メソッドを介して値をレポートしなければなりません。
一部のセンサータイプは複合型です。つまり、1 つ以上の他のセンサーによって提供されるデータから得られることがあります(方向センサーや直線加速度センサーなど)。
デバイス実装は:
- センサータイプに記載されているとおり、必須の物理センサーを含む場合、これらのセンサータイプを実装すべきです。
複合センサーが含まれる場合、デバイス実装は:
- [C-2-1] 複合センサーに関する Android オープンソース ドキュメントに記載されているとおり、センサーを実装しなければなりません。
サードパーティ デベロッパー向けの対応する API を持つ特定のセンサータイプが含まれ、センサーが値を 1 つだけレポートする場合、デバイス実装は:
- [C-3-1] センサーの解像度を 1 に設定し、
Sensor.getResolution()
API メソッドを介して値をレポートしなければなりません。
SensorAdditionalInfo#TYPE_VEC3_CALIBRATION をサポートする特定のセンサータイプが含まれ、センサーがサードパーティ デベロッパーに公開される場合、デバイス実装は:
- [C-4-1] 提供されるデータに、出荷時に決定した固定の調整パラメータを含めてはなりません。
3 軸加速度計、3 軸ジャイロスコープ センサー、磁力計センサーの組み合わせが含まれる場合、デバイス実装は:
- [C-SR-2] 加速度計、ジャイロスコープ、磁力計の相対位置が固定されるようにすることが強く推奨されます。これにより、デバイスが変形可能(折りたたみ式など)な場合、どのような状態に変形する可能性があっても、センサーの軸がセンサー座標系との整合性を保ちます。
7.3.1. 加速度計
デバイス実装は:
- [C-SR-1] 3 軸加速度計を含めることが強く推奨されます。
加速度計が含まれる場合、デバイス実装は:
- [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
- [C-1-3] Android API で詳述されているとおり、Android センサー座標系に準拠しなければなりません。
- [C-1-4] どの軸でも、自由落下から重力の 4 倍(4g)以上まで測定できなければなりません。
- [C-1-5] 解像度が少なくとも 12 ビットでなければなりません。
- [C-1-6] 標準偏差が 0.05 m/s^ 以下でなければなりません。標準偏差は、最速サンプリング レートで少なくとも 3 秒間にわたって収集されたサンプルについて、軸ごとに計算すべきです。
- 少なくとも 200 Hz までのイベントをレポートすべきです。
- 解像度が少なくとも 16 ビットであるべきです。
- ライフサイクル中に特性が変化して補正される場合、使用中に調整すべきであり、デバイスが再起動される間も補正パラメータを保持すべきです。
- 温度補正をすべきです。
3 軸加速度計が含まれる場合、デバイス実装は:
- [C-2-1]
TYPE_ACCELEROMETER
センサーを実装し、レポートしなければなりません。 - [C-SR-4]
TYPE_SIGNIFICANT_MOTION
複合センサーを実装することが強く推奨されます。 - [C-SR-5]
TYPE_ACCELEROMETER_UNCALIBRATED
センサーを実装し、レポートすることが強く推奨されます。Android デバイスは、要求される可能性のある今後のプラットフォーム リリースにアップグレードできるよう、この要件を満たすことが強く推奨されます。 - Android SDK ドキュメントに記載されているとおり、複合センサー
TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
、TYPE_STEP_COUNTER
を実装すべきです。
3 軸未満の加速度計が含まれる場合、デバイス実装は:
- [C-3-1]
TYPE_ACCELEROMETER_LIMITED_AXES
センサーを実装し、レポートしなければなりません。 - [C-SR-6]
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
センサーを実装し、レポートすることが強く推奨されます。
3 軸加速度計が含まれ、TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
、TYPE_STEP_COUNTER
のいずれかの複合センサーが実装される場合、デバイス実装は:
- [C-4-1] 消費電力の合計が常に 4 mW 未満でなければなりません。
- デバイスが動的状態または静的状態にあるとき、それぞれ 2 mW 未満、0.5 mW 未満であるべきです。
3 軸加速度計と 3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:
- [C-5-1] 複合センサー
TYPE_GRAVITY
とTYPE_LINEAR_ACCELERATION
を実装しなければなりません。 - [C-SR-7]
TYPE_GAME_ROTATION_VECTOR
複合センサーを実装することが強く推奨されます。
3 軸加速度計、3 軸ジャイロスコープ センサー、磁力計センサーが含まれる場合、デバイス実装は:
- [C-6-1]
TYPE_ROTATION_VECTOR
複合センサーを実装しなければなりません。
7.3.2. 磁力計
デバイス実装は:
- [C-SR-1] 3 軸磁力計(コンパス)を含むことが強く推奨されます。
3 軸磁力計が含まれる場合、デバイス実装は:
- [C-1-1]
TYPE_MAGNETIC_FIELD
センサーを実装しなければなりません。 - [C-1-2] 少なくとも周波数が 10 Hz までのイベントをレポートできなければならず、少なくとも 50 Hz までのイベントをレポートすべきです。
- [C-1-3] Android API で詳述されているとおり、Android センサー座標系を遵守しなければなりません。
- [C-1-4] 飽和する前に各軸で -900 µT~+900 µT を測定できなければなりません。
- [C-1-5] 磁力計を動的(電流誘導)磁場と静的(磁気誘導)磁場から離して配置することで、ハードアイアン オフセット値が 700 µT 未満でなければならず、200 µT 未満であるべきです。
- [C-1-6] 解像度が 0.6 µT 以上でなければなりません。
- [C-1-7] ハードアイアン バイアスのオンラインの調整と補正をサポートしなければならず、デバイスの再起動の間で補正パラメータを保持しなければなりません。
- [C-1-8] ソフトアイアン補正を適用しなければなりません。調整は、デバイスの使用中または製造中に行うことができます。
- [C-1-9] 標準偏差が、最速サンプリング レートで少なくとも 3 秒間にわたって収集されたサンプルについて軸ごとに計算して 1.5 µT 以下でなければならず、標準偏差が 0.5 µT 以下であるべきです。
- [C-1-10]
TYPE_MAGNETIC_FIELD_UNCALIBRATED
センサーを実装しなければなりません。
3 軸磁力計、加速度計センサー、3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:
- [C-2-1]
TYPE_ROTATION_VECTOR
複合センサーを実装しなければなりません。
3 軸磁力計、加速度計が含まれる場合、デバイス実装は:
TYPE_GEOMAGNETIC_ROTATION_VECTOR
センサーを実装しても構いません。
3 軸磁力計、加速度計、TYPE_GEOMAGNETIC_ROTATION_VECTOR
センサーが含まれる場合、デバイス実装は:
- [C-3-1] 消費電力が 10 mW 未満でなければなりません。
- センサーが 10 Hz でバッチモードに登録されている場合、消費電力が 3 mW 未満であるべきです。
7.3.3. GPS
デバイス実装は:
- [C-SR-1] GPS / GNSS レシーバーを含むことが強く推奨されます。
GPS / GNSS レシーバーが含まれ、android.hardware.location.gps
機能フラグを通じてアプリに機能をレポートする場合、デバイス実装は:
- [C-1-1]
LocationManager#requestLocationUpdate
を介してリクエストされたとき、少なくとも 1 Hz のレートでの位置情報出力をサポートしなければなりません。 - [C-1-2] データ速度が 0.5 Mbps 以上のインターネット接続に接続したとき、全天条件下(信号強度が高く、マルチパスを無視でき、HDOP < 2)で、10 秒以内に位置を決定できなければなりません(初期位置算出時間が短い)。この要件は通常、GPS / GNSS ロックオン時間を最小限に抑えるための、なんらかの形の支援または予測 GPS / GNSS 技術を使用することで満たします(支援データには基準時間、基準位置、衛星エフェメリス / クロックが含まれます)。
- [C-1-6] このような位置計算を行った後、デバイス実装は、位置情報のリクエストが再開されたとき、初期位置計算から最大 1 時間後まで、後続のリクエストがデータ接続なしで行われたときや、電源をオフにして再度オンにした後であっても、全天条件下で 5 秒以内に位置を決定しなければなりません。
位置を決定した後、全天条件下で、静止しながら、または加速度 1 m/s2 未満で移動しながら:
- [C-1-3] 少なくとも 95% の時間で、位置を 20 m 以内、速度を 0.5 m/s 以内で決定できなければなりません。
- [C-1-4]
GnssStatus.Callback
を介して、1 つのコンステレーションから少なくとも 8 つの衛星を同時にトラック、レポートしなければなりません。 - 複数のコンステレーションから少なくとも 24 の衛星を同時にトラックできるべきです(例: GPS と、Glonass、Beidou、Galileo のうち少なくとも 1 つ)。
[C-SR-2] 緊急通報の際も、GNSS Location Provider API を通じて通常の GPS / GNSS 位置情報出力を引き続き提供することが強く推奨されます。
[C-SR-3] SBAS を除き、トラックしたすべてのコンステレーションからの GNSS 測定値を(GnssStatus メッセージでレポートされたとおり)レポートすることが強く推奨されます。
[C-SR-4] AGC と、GNSS 測定頻度をレポートすることが強く推奨されます。
[C-SR-5] すべての正確度推定値(方位角、速度、垂直を含む)を、各 GPS / GNSS 位置情報の一部としてレポートすることが強く推奨されます。
[C-SR-6] GPS / GNSS から計算した位置情報がまだレポートされていない場合であっても、GNSS 測定値が判明したらすぐにレポートすることが強く推奨されます。
[C-SR-7] 位置を決定した後、全天条件下で、静止しているか加速度 0.2 m/s2 未満で移動している間に、少なくとも 95% の時間で 20 m 以内の位置と 0.2 m/s 以内の速度を計算するのに十分な、GNSS の擬似距離と擬似距離レートをレポートすることが強く推奨されます。
7.3.4. ジャイロスコープ
デバイス実装は:
- [C-SR-1] ジャイロスコープ センサーを含めることが強く推奨されます。
ジャイロスコープが含まれる場合、デバイス実装は:
- [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
- [C-1-4] 解像度が 12 ビット以上でなければなりません。
- [C-1-5] 温度補正しなければなりません。
- [C-1-6] 使用中に調整と補正を行わなければならず、デバイスの再起動の間で補正パラメータを保持しなければなりません。
- [C-1-7] 分散が Hz あたり 1e-7 rad^2 / s^2(Hz あたりの分散または rad^2 / s)以下でなければなりません。分散はサンプリング レートによって異なることが許容されますが、この値の制約を受けなければなりません。つまり、サンプリング レート 1 Hz でジャイロの分散を測定した場合、1e-7 rad^2/s^2 以下であるべきです。
- [C-SR-2] 補正誤差は、室温でデバイスが静止しているとき、0.01 rad/s 未満であることが強く推奨されます。
- [C-SR-3] 解像度が 16 ビット以上であることが強く推奨されます。
- 少なくとも 200 Hz までのイベントをレポートすべきです。
3 軸ジャイロスコープが含まれる場合、デバイス実装は:
- [C-2-1]
TYPE_GYROSCOPE
センサーを実装しなければなりません。 - [C-SR-4]
TYPE_GYROSCOPE_UNCALIBRATED
センサーを実装することが強く推奨されます。
3 軸未満のジャイロスコープが含まれる場合、デバイス実装は:
- [C-3-1]
TYPE_GYROSCOPE_LIMITED_AXES
センサーを実装し、レポートしなければなりません。 - [C-SR-5]
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
センサーを実装し、レポートすることが強く推奨されます。
3 軸ジャイロスコープ、加速度計センサー、磁力計センサーが含まれる場合、デバイス実装は:
- [C-4-1]
TYPE_ROTATION_VECTOR
複合センサーを実装しなければなりません。
3 軸加速度計と 3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:
- [C-5-1] 複合センサー
TYPE_GRAVITY
とTYPE_LINEAR_ACCELERATION
を実装しなければなりません。 - [C-SR-6]
TYPE_GAME_ROTATION_VECTOR
複合センサーを実装することが強く推奨されます。
7.3.5. 気圧計
デバイス実装は:
- [C-SR-1] 気圧計(大気圧センサー)を含むことが強く推奨されます。
気圧計が含まれる場合、デバイス実装は:
- [C-1-1]
TYPE_PRESSURE
センサーを実装し、レポートしなければなりません。 - [C-1-2] 5 Hz 以上でイベントを配信できなければなりません。
- [C-1-3] 温度補正しなければなりません。
- [C-SR-2] 300 hPa から 1,100 hPa までの圧力測定値をレポートできることが強く推奨されます。
- 絶対正確度が 1 hPa であるべきです。
- 相対正確度が 20 hPa の範囲で 0.12 hPa であるべきです(海面における ~200 m の変化で正確度 ~1 m に相当)。
7.3.6. 温度計
周囲温度計(温度センサー)が含まれる場合、デバイス実装は:
- [C-1-1] 周囲温度センサーについて
SENSOR_TYPE_AMBIENT_TEMPERATURE
を定義しなければならず、センサーは、ユーザーがデバイスを操作している場所の周囲温度(室温 / 車内温度)を摂氏で測定しなければなりません。
周囲温度以外の温度(CPU 温度など)を測定する温度計センサーが含まれる場合、デバイス実装は:
- [C-2-1] 温度センサーについて
SENSOR_TYPE_AMBIENT_TEMPERATURE
を定義してはなりません。
皮膚温をモニタリングするためのセンサーが含まれる場合、デバイス実装は:
- [C-SR-1] PowerManager.getThermalHeadroom API をサポートすることが強く推奨されます。
7.3.7. 光度計
- デバイス実装は、光度計(周囲光センサー)を含んでも構いません。
7.3.8. 近接センサー
- デバイス実装は、近接センサーを含んでも構いません。
近接センサーが含まれ、2 成分の「遠」「近」読み取り値のみをレポートする場合、デバイス実装は:
- [C-1-1] 画面と同じ向きで物体の近接を測定しなければなりません。つまり近接センサーは、画面の近くにある物体を検出するような向きでなければなりません。これは、スマートフォンをユーザーが使用中であることの検出が、この種のセンサーの主な目的であるためです。他の向きの近接センサーを含む場合、デバイス実装は、この API を通じてアクセス可能であってはなりません。
- [C-1-2] 正確度が 1 ビット以上でなければなりません。
- [C-1-3] 「近」読み取り値として 0 センチメートル、「遠」読み取り値として 5 センチメートルを使用しなければなりません。
- [C-1-4] 最大範囲と解像度 5 をレポートしなければなりません。
7.3.9. ハイファイ センサー
このセクションで規定するとおり、高品質センサーのセットが含まれ、サードパーティ アプリで利用できるようにする場合、デバイス実装は:
- [C-1-1]
android.hardware.sensor.hifi_sensors
機能フラグを通じて機能を識別しなければなりません。
android.hardware.sensor.hifi_sensors
を宣言する場合、デバイス実装は:
[C-2-1] 次の条件を満たす
TYPE_ACCELEROMETER
センサーがなければなりません。- 測定範囲が少なくとも -8g~+8g でなければならず、測定範囲が少なくとも -16g~+16g であることが強く推奨されます。
- 測定解像度が少なくとも 2,048 LSB/g でなければなりません。
- 最小測定周波数が 12.5 Hz 以下でなければなりません。
- 最大測定周波数が 400 Hz 以上でなければならず、SensorDirectChannel
RATE_VERY_FAST
をサポートすべきです。 - 測定雑音が 400 μg/√Hz 以下でなければなりません。
- 少なくとも 3,000 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
- 計量消費電力が 3 mW 以下でなければなりません。
- [C-SR-1] 3 dB 測定帯域幅がナイキスト周波数の少なくとも 80% であり、ホワイトノイズ スペクトルがこの帯域幅内であることが強く推奨されます。
- 室温でテストして加速度ランダム ウォークが 30 μg √Hz 未満であるべきです。
- 温度に対するバイアス変化が +/- 1 mg/°C 以下であるべきです。
- 最良適合線が非線形で 0.5% 以下、温度に対する感度変化が 0.03%/C° 以下であるべきです。
- デバイスの動作温度範囲で、直交軸感度が 2.5% 未満、直交軸感度の変動が 0.2% 未満であるべきです。
[C-2-2]
TYPE_ACCELEROMETER_UNCALIBRATED
の品質要件がTYPE_ACCELEROMETER
と同じでなければなりません。[C-2-3] 次の条件を満たす
TYPE_GYROSCOPE
センサーがなければなりません。- 測定範囲が少なくとも -1,000~+1,000 dps でなければなりません。
- 測定解像度が少なくとも 16 LSB/dps でなければなりません。
- 最小測定周波数が 12.5 Hz 以下でなければなりません。
- 最大測定周波数が 400 Hz 以上でなければならず、SensorDirectChannel
RATE_VERY_FAST
をサポートすべきです。 - 測定雑音が 0.014°/s/√Hz 以下でなければなりません。
- [C-SR-2] 3 dB 測定帯域幅がナイキスト周波数の少なくとも 80% であり、ホワイトノイズ スペクトルがこの帯域幅内であることが強く推奨されます。
- 室温でテストしてレートランダム ウォークが 0.001 °/s √Hz 未満であるべきです。
- 温度に対するバイアス変化が +/- 0.05 °/ s / °C 以下であるべきです。
- 温度に対する感度変化が 0.02% / °C 以下であるべきです。
- 最良適合線が非線形で 0.2% 以下であるべきです。
- 雑音密度が 0.007 °/s/√Hz 以下であるべきです。
- デバイスが静止しているとき、温度範囲 10~40℃ で調整誤差が 0.002 rad/s 未満であるべきです。
- 加速度感度が 0.1°/s/g 未満であるべきです。
- デバイスの動作温度範囲で、直交軸感度が 4.0% 未満、直交軸感度の変動が 0.3% 未満であるべきです。
[C-2-4]
TYPE_GYROSCOPE_UNCALIBRATED
の品質要件がTYPE_GYROSCOPE
と同じでなければなりません。[C-2-5] 次の条件を満たす
TYPE_GEOMAGNETIC_FIELD
センサーがなければなりません。- 測定範囲が少なくとも -900~+900 μT でなければなりません。
- 測定解像度が少なくとも 5 LSB/uT でなければなりません。
- 最小測定周波数が 5 Hz 以下でなければなりません。
- 最大測定周波数が 50 Hz 以上でなければなりません。
- 測定雑音が 0.5 uT 以下でなければなりません。
[C-2-6]
TYPE_MAGNETIC_FIELD_UNCALIBRATED
の品質要件がTYPE_GEOMAGNETIC_FIELD
と同じでなければならず、さらに:- 少なくとも 600 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
- [C-SR-3] レポートレートが 50 Hz 以上のとき、ホワイトノイズ スペクトラムが 1 Hz から少なくとも 10 Hz までであることが強く推奨されます。
[C-2-7] 次の条件を満たす
TYPE_PRESSURE
センサーがなければなりません。- 測定範囲が少なくとも 300~1,100 hPa でなければなりません。
- 測定解像度が少なくとも 80 LSB/hPa でなければなりません。
- 最小測定周波数が 1 Hz 以下でなければなりません。
- 最大測定周波数が 10 Hz 以上でなければなりません。
- 測定雑音が 2 Pa/√Hz 以下でなければなりません。
- 少なくとも 300 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
- 計量消費電力が 2 mW 以下でなければなりません。
[C-2-8]
TYPE_GAME_ROTATION_VECTOR
センサーがなければなりません。[C-2-9] 次の条件を満たす
TYPE_SIGNIFICANT_MOTION
センサーがなければなりません。- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
[C-2-10] 次の条件を満たす
TYPE_STEP_DETECTOR
センサーがなければなりません。- 少なくとも 100 件のセンサー イベントをバッファリングできる、このセンサーの非ウェイクアップ フォームを実装しなければなりません。
- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
- 計量消費電力が 4 mW 以下でなければなりません。
[C-2-11] 次の条件を満たす
TYPE_STEP_COUNTER
センサーがなければなりません。- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
[C-2-12] 次の条件を満たす
TILT_DETECTOR
センサーがなければなりません。- 消費電力が、デバイス静止時は 0.5 mW 以下でなければならず、デバイス移動時は 1.5 mW 以下でなければなりません。
[C-2-13] 加速度計、ジャイロスコープ、磁力計がレポートする同じ物理イベントのイベント タイムスタンプが、互いに 2.5 ミリ秒以内でなければなりません。加速度計とジャイロスコープがレポートする同じ物理イベントのイベント タイムスタンプが、互いに 0.25 ミリ秒以内であるべきです。
[C-2-14] ジャイロスコープ センサーのイベント タイムスタンプがカメラ サブシステムと同じタイムベースであり、誤差 1 ミリ秒以内でなければなりません。
[C-2-15] 上記の物理センサーのいずれかでアプリがデータを利用できるようになった時点から 5 ミリ秒以内に、サンプルをアプリに配信しなければなりません。
[C-2-16] 次のセンサーの組み合わせが有効なとき、消費電力が、デバイス静止時は 0.5 mW を超えてはならず、デバイス移動時は 2.0 mW を超えてはなりません。
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17]
TYPE_PROXIMITY
センサーがあっても構いませんが、存在する場合、少なくとも 100 件のセンサー イベントをバッファリングできなければなりません。
なお、このセクションの消費電力要件はすべて、アプリ プロセッサの消費電力を含みません。センサー チェーン全体(センサー、補助回路、専用のセンサー処理システムなど)によって消費される電力が含まれます。
ダイレクト センサー サポートが含まれる場合、デバイス実装は:
- [C-3-1]
isDirectChannelTypeSupported
API とgetHighestDirectReportRateLevel
API を通じて、ダイレクト チャネルタイプとダイレクト レポート レートレベルのサポートを正しく宣言しなければなりません。 - [C-3-2] センサー ダイレクト チャネルのサポートを宣言するすべてのセンサーについて、2 つのセンサー ダイレクト チャネルタイプのうち少なくとも 1 つをサポートしなければなりません。
- 次のタイプのプライマリ センサー(非ウェイクアップ バリアント)のセンサー ダイレクト チャネルを通じたイベント レポートをサポートすべきです。
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. 生体認証センサー
生体認証によるロック解除のセキュリティの測定について詳しくは、生体認証を用いたロック解除のセキュリティ測定をご覧ください。
セキュアロック画面が含まれる場合、デバイス実装は:
- 生体認証センサーを含むべきです。
生体認証センサーは、スプーフィング受け入れ率、なりすまし受け入れ率、生体認証パイプラインのセキュリティに基づいて、クラス 3(旧称「強」)、クラス 2(旧称「弱」)、クラス 1(旧称「利便性」)に分類できます。この分類によって、生体認証センサーがプラットフォームやサードパーティ アプリとインターフェースで接続する機能が決まります。センサーがクラス 1、クラス 2、クラス 3 に分類されるようにするには、以下のとおり追加の要件を満たす必要があります。クラス 2 とクラス 3 の生体認証には、以下の追加の機能があります。
android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt、android.provider.Settings.ACTION_BIOMETRIC_ENROLL を介してサードパーティ アプリで生体認証センサーを利用できるようにする場合、デバイス実装は:
- [C-4-1] このドキュメントで規定するとおり、クラス 3 またはクラス 2 の生体認証の要件を満たさなければなりません。
- [C-4-2] Authenticators クラスで定数として定義された各パラメータ名とそれらの組み合わせを認識し、使用しなければなりません。逆に、Authenticators でパブリック定数として記述されているもの以外の、canAuthenticate(int) メソッドと setAllowedAuthenticators(int) メソッドに渡された整数定数を使用または認識してはなりません。
- [C-4-3] クラス 3 またはクラス 2 の生体認証を有するデバイスでは、ACTION_BIOMETRIC_ENROLL アクションを実装しなければなりません。このアクションは、クラス 3 またはクラス 2 の生体認証の登録エントリ ポイントのみを提示しなければなりません。
受動的生体認証をサポートする場合、デバイス実装は:
- [C-5-1] デフォルトで追加の確認ステップ(ボタンの押下など)を要求しなければなりません。
- [C-SR-1] ユーザーがアプリの設定を上書きできるように設定することが強く推奨され、常に確認ステップを伴うことが要求されます。
- [C-SR-2] オペレーティング システムやカーネルの不正使用によってスプーフィングできないように、確認アクションをセキュアにすることが強く推奨されます。たとえば、物理ボタンに基づく確認アクションは、物理ボタンの押下以外では動作できないセキュア エレメント(SE)の入力専用の汎用入出力(GPIO)ピンを通じてルーティングされます。
- [C-5-2] さらに、ログインフローで利用するようにアプリが設定できる、setConfirmationRequired(ブール値)に応じた暗黙的認証フローを実装しなければなりません。
生体認証センサーが複数ある場合、デバイス実装は:
新しい要件の開始
[C-7-1] 試行に失敗した回数が上限を超えたことにより、生体認証がロックアウトされた場合(ユーザーが第 1 の認証でロック解除するまで生体認証が無効になっている場合)、または期限付きでロックアウトされている場合(ユーザーが一定時間の待機を完了するまでは生体認証が一時的に無効になっている場合)は、下位の生体認証クラスのその他の生体認証もすべてロックアウトしなければなりません。期限付きロックアウトの場合、生体認証検証のバックオフ時間は、期限付きロックアウト中のすべての生体認証の最大バックオフ時間でなければなりません。
[C-SR-12] 試行に失敗した回数が上限を超えたことにより、生体認証がロックアウトされた場合(ユーザーが第 1 の認証でロック解除するまで生体認証が無効になっている場合)、または期限付きでロックアウトされている場合(ユーザーが一定時間の待機を完了するまでは生体認証が一時的に無効になっている場合)は、同じ生体認証クラスのその他の生体認証もすべてロックアウトすることが強く推奨されます。期限付きロックアウトの場合、生体認証検証のバックオフ時間は、期限付きロックアウト中のすべての生体認証の最大バックオフ時間とすることが強く推奨されます。
[C-7-2] ロックアウト中の生体認証のロックアウト カウンタをリセットするために、推奨される第 1 の認証(PIN、パターン、パスワードなど)をユーザーに求めなければなりません。クラス 3 の生体認証では、ロック中の同じまたは下位のクラスの生体認証のロックアウト カウンタをリセットできても構いません。クラス 2 またはクラス 1 の生体認証で、生体認証のリセット ロックアウト オペレーションを完了してはなりません。
新しい要件の終了
- [C-SR-3] 1 回の認証で確認される生体認証は 1 つのみとすることが強く推奨されます(例: デバイスで指紋センサーと顔センサーの両方が利用可能な場合、どちらかの認証が成功したら onAuthenticationSucceeded が送信されるべきです)。
サードパーティ アプリにキーストアキーへのアクセスを許可するために、デバイス実装は:
- [C-6-1] このセクションで後述するとおり、クラス 3 の要件を満たさなければなりません。
- [C-6-2] 認証で BIOMETRIC_STRONG が必要な場合、または認証が CryptoObject によって呼び出された場合は、クラス 3 の生体認証のみ提示しなければなりません。
生体認証センサーをクラス 1(旧称「利便性」)として扱う場合、デバイス実装は:
- [C-1-1] 他人受け入れ率が 0.002% 未満でなければなりません。
- [C-1-2] このモードが強い PIN、パターン、またはパスワードよりもセキュアでない可能性があることを開示しなければならず、Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% を超える場合、このモードを有効にすることのリスクを明確に列挙しなければなりません。
- [C-1-9] 生体認証が 20 回(またはそれ以下)失敗した場合、少なくとも 90 秒のバックオフ時間が経過してから、推奨される第 1 の認証(PIN、パターン、パスワードなど)をユーザーに求めなければなりません。ここで失敗とは、登録された生体認証に一致しないが、品質には問題がないキャプチャ(BIOMETRIC_ACQUIRED_GOOD)が使用された場合を指します。
- [C-SR-4] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% を超える場合、[C-1-9] で規定されている、生体認証の失敗の最大回数を減らすことが強く推奨されます。
- [C-1-3] 生体認証の試行回数をレート制限しなければなりません。ここで失敗とは、登録された生体認証に一致しないが、品質には問題がないキャプチャ(
BIOMETRIC_ACQUIRED_GOOD
)が使用された場合を指します。 - [C-SR-5] [C-1-9] で規定されている生体認証の失敗の最大回数について、5 回の失敗の後は、少なくとも 30 秒間、レート制限することが強く推奨されます。ここで失敗とは、登録された生体認証に一致しないが、品質には問題がないキャプチャ(BIOMETRIC_ACQUIRED_GOOD)が使用された場合を指します。
- [C-SR-6] TEE にすべてのレート制限ロジックがあることが強く推奨されます。
[C-1-10] セクション 9.11 の [C-0-2] に記載されているとおり、第 1 の認証のバックオフが初めてトリガーされたら、生体認証を無効にしなければなりません。
[C-1-11] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 30% 以下でなければなりません。具体的には、(1)レベル A のプレゼンテーション攻撃手段(PAI)の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 30% 以下、(2)レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 40% 以下でなければなりません。
[C-1-4] TEE で保護された、既存のデバイス認証情報をユーザーに確認させることによる、または新しい認証情報(PIN、パターン、パスワード)をユーザーに追加させることによる信頼チェーンの確立を最初に行わずに、新しい生体認証を追加することは避けなければなりません。Android オープンソース プロジェクト実装は、そのためのフレームワークのメカニズムを提供します。
[C-1-5] ユーザーのアカウントが削除されたとき(初期状態にリセットした場合を含む)、ユーザーの識別可能なすべての生体認証データを完全に削除しなければなりません。
[C-1-6] その生体認証の個々のフラグを使用しなければなりません(例:
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
、DevicePolicymanager.KEYGUARD_DISABLE_FACE
、DevicePolicymanager.KEYGUARD_DISABLE_IRIS
)。[C-1-7] 24 時間以内ごとに 1 回、推奨される第 1 の認証(PIN、パターン、パスワードなど)をユーザーに求めなければなりません。注: Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合は、72 時間以内ごとに 1 回、推奨される第 1 の認証(PIN、パターン、パスワードなど)をユーザーに求めなければなりません。
[C-1-8] 次のいずれかの後、推奨される第 1 の認証(PIN、パターン、パスワードなど)またはクラス 3(強)の生体認証をユーザーに求めなければなりません。
- 4 時間のアイドル タイムアウト期間、または
- 生体認証の試行に 3 回失敗。
- アイドル タイムアウト期間と認証の失敗回数は、デバイス認証情報の確認に成功するとリセットされます。 注: Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合は、C-1-8 を免除しても構いません。
[C-SR-7] 新しいデバイスに [C-1-7] と [C-1-8] で規定する制約を適用するために、Android オープンソース プロジェクトで提供するフレームワークのロジックを使用することが強く推奨されます。
[C-SR-8] デバイスで測定したときの本人拒否率が 10% 未満であることが強く推奨されます。
[C-SR-9] 登録した生体認証ごとに、生体認証が検出されてから画面がロック解除されるまでのレイテンシが 1 秒未満であることが強く推奨されます。
新しい要件の開始
[C-1-12] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段(PAI)の種類ごとに 40% 以下でなければなりません。
[C-SR-13] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段(PAI)の種類ごとに 30% 以下であることが強く推奨されます。
[C-SR-14] 生体認証センサーの生体認証クラスと、それを有効にすることのリスクを開示することが強く推奨されます。
[C-SR-17] 新しい AIDL インターフェース(たとえば、
IFace.aidl
やIFingerprint.aidl
)を実装することが強く推奨されます。
新しい要件の終了
生体認証センサーをクラス 2(旧称「弱」)として扱う場合、デバイス実装は:
[C-2-1] 上記のクラス 1 の要件をすべて満たさなければなりません。
[C-2-2] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下でなければなりません。具体的には、(1)レベル A のプレゼンテーション攻撃手段(PAI)の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下、(2)レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 30% 以下でなければなりません。
新しい要件の開始
- [C-SR-15] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段(PAI)の種類ごとに 20% 以下であることが強く推奨されます。
新しい要件の終了
- [C-2-3] 高信頼実行環境(TEE)など、Android のユーザーまたはカーネル空間外の隔離された実行環境内、
または隔離された実行環境へのセキュア チャネルがあるチップ上、セクション 9.17 の要件を満たす Protected Virtual Machine 上で、生体認証マッチングを行わなければなりません。 - [C-2-4] Android オープンソース プロジェクトのサイトの実装ガイドラインに記載されている隔離された実行環境、隔離された実行環境へのセキュア チャネルがあるチップ、セクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine の外部で取得、読み取り、変更できないように、識別可能なすべてのデータを暗号化、暗号認証しなければなりません。
- [C-2-5] カメラベースの生体認証で、生体認証ベースの認証または登録が行われるとき:
- 隔離された実行環境または隔離された実行環境へのセキュア チャネルがあるチップ、セクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine の外部では、カメラフレームの読み取りと変更が行われないモードで、カメラを動作させなければなりません。
- RGB シングルカメラ ソリューションでは、登録のためのプレビューなどの動作をサポートするために、隔離された実行環境の外部でカメラフレームを読み取れても、変更はできないようにしなければなりません。
- [C-2-6] サードパーティ アプリで個々の生体認証登録を区別できるようにしてはなりません。
- [C-2-7] TEE またはセクション 9.17 の要件を満たすハイパーバイザによって制御されている Protected Virtual Machine のコンテキスト外で、識別可能な生体認証データまたはそれから派生したデータ(埋め込みなど)への暗号化されていないアクセスを、アプリ プロセッサに許可してはなりません。Android バージョン 9 以前でリリースされたデバイスをアップグレードする場合、C-2-7 は免除されません。
[C-2-8] オペレーティング・システムまたはカーネルの侵害によって、データを直接注入できてしまうことでユーザーとして誤って認証されることのないような、セキュアな処理パイプラインがなければなりません。注: デバイス実装が Android バージョン 9 以前ですでにリリースされており、システム ソフトウェア アップデートを通じて要件 C-2-8 を満たせない場合は、この要件を免除しても構いません。
[C-SR-10] すべての生体認証モダリティのための生体検出と、顔による生体認証のための視線検出を含むことが強く推奨されます。
[C-2-9] 生体認証センサーをサードパーティ アプリで利用できるようにしなければなりません。
生体認証センサーをクラス 3(旧称「強」)として扱う場合、デバイス実装は:
- [C-3-1] 上記のクラス 2 の要件をすべて満たさなければなりません([C-1-7] と [C-1-8] を除く)。
- [C-3-2] ハードウェア格納型キーストア実装がなければなりません。
- [C-3-3] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% 以下でなければなりません。具体的には、(1)レベル A のプレゼンテーション攻撃手段(PAI)の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 7% 以下、(2)レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下でなければなりません。
- [C-3-4] 72 時間以内ごとに 1 回、推奨される第 1 の認証(PIN、パターン、パスワードなど)をユーザーに求めなければなりません。
- [C-3-5] デバイスでサポートされているすべてのクラス 3 生体認証が再登録された場合、認証システム ID を再生成しなければなりません。
- [C-3-6] サードパーティ アプリに対し、生体認証によるキーストア鍵を有効にしなければなりません。
新しい要件の開始
- [C-SR-16] Android 生体認証テスト プロトコルによって測定したスプーフィングとなりすましの受け入れ率が、プレゼンテーション攻撃手段(PAI)の種類ごとに 7% 以下であることが強く推奨されます。
新しい要件の終了
ディスプレイ内蔵指紋認証センサー(UDFPS)が含まれる場合、デバイス実装は:
- [C-SR-11] UDFPS のタップ可能エリアが 3 ボタン ナビゲーションの妨げにならないようにすることが強く推奨されます(ユーザー補助で必要とするユーザーがいる可能性があります)。
7.3.11. 姿勢センサー
デバイス実装は:
- 6 自由度の姿勢センサーをサポートしても構いません。
6 自由度の姿勢センサーをサポートする場合、デバイス実装は:
- [C-1-1]
TYPE_POSE_6DOF
センサーを実装し、レポートしなければなりません。 - [C-1-2] 回転ベクトルのみの場合よりも正確でなければなりません。
7.3.12. ヒンジ角度センサー
ヒンジ角度センサーをサポートする場合、デバイス実装は:
- [C-1-1]
TYPE_HINGLE_ANGLE
を実装し、レポートしなければなりません。 - [C-1-2] 0 度以上 360 度以下(すなわち 0 度と 360 度を含む)の、少なくとも 2 つの読み値をサポートしなければなりません。
- [C-1-3]
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
について、wakeup センサーを返さなければなりません。
7.3.13. IEEE 802.1.15.4(UWB)
802.1.15.4 のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:
新しい要件の開始
- [C-1-2] ハードウェア機能フラグ
android.hardware.uwb
をレポートしなければなりません。 - [C-1-3] AOSP 実装で定義されている次の構成セット(事前定義された FiRa UCI パラメータの組み合わせ)をすべてサポートしなければなりません。
CONFIG_ID_1
: FiRa で定義されたユニキャストSTATIC STS DS-TWR
距離測定、遅延モード、距離測定時間は 240 ミリ秒。CONFIG_ID_2
: FiRa で定義された 1 対多のSTATIC STS DS-TWR
距離測定、遅延モード、距離測定時間は 200 ミリ秒(一般的な使用例: 多数のスマート デバイスと連携するスマートフォン)。CONFIG_ID_3
:CONFIG_ID_1
と同じですが、到来角(AoA)データはレポートされません。CONFIG_ID_4
:CONFIG_ID_1
と同じですが、P-STS セキュリティ モードが有効化されます。CONFIG_ID_5
:CONFIG_ID_2
と同じですが、P-STS セキュリティ モードが有効化されます。CONFIG_ID_6
:CONFIG_ID_3
と同じですが、P-STS セキュリティ モードが有効化されます。CONFIG_ID_7
:CONFIG_ID_2
と同じですが、P-STS 個別コントローリー鍵モードが有効化されます。
- [C-1-4] ユーザーが UWB 無線のオン / オフの状態を切り替えられるようにするユーザー アフォーダンスを提供しなければなりません。
- [C-1-5] UWB 無線を使用するアプリが(
NEARBY_DEVICES
権限グループの下で)UWB_RANGING
権限を保持するようにしなければなりません。
FiRa、CCC、CSA などの標準化団体によって定義されている、関連する適合性および認証テストに合格することで、802.1.15.4 が適切に機能するようにできます。
新しい要件の終了
7.4. データ接続
7.4.1. 電話
Android API とこのドキュメントで使用する「電話」は、特に、モバイル(たとえば、GSM、CDMA、LTE、NR)GSM または CDMA ネットワークを介して行う音声通話と SMS メッセージの送信、またはモバイルデータの確立に関連するハードウェアのことを指します。「電話」をサポートするデバイスでは、製品に合わせて、通話、メッセージング、データサービスの一部またはすべてを提供することを選択できます。
GSM または CDMA ネットワークを介して行う音声通話と SMS メッセージの送信に関連するハードウェアのことを指します。こうした音声通話は、パケット交換であってもそうでなくても構いませんが、Android では、同じネットワークを使用して実装されるデータ接続からは独立しているとみなされます。つまり、Android の「電話」機能と API は、特に音声通話と SMS のことを指します。たとえば、通話の発信または SMS メッセージの送受信ができないデバイス実装は、データ接続にモバイル ネットワークを使用するかどうかにかかわらず、電話デバイスとはみなされません。
- Android は、電話ハードウェアを含まないデバイスで使用しても構いません。つまり、Android はスマートフォンではないデバイスに対応しています。
GSM または CDMA 電話が含まれる場合、デバイス実装は:
- [C-1-1]
android.hardware.telephony
機能フラグと、テクノロジーに応じて他のサブ機能フラグを宣言しなければなりません。 - [C-1-2] そのテクノロジー向けの API の完全なサポートを実装しなければなりません。
- 緊急通報の際、
SetAllowedNetworkTypeBitmap()
で設定したネットワークの種類にかかわらず、利用可能なすべてのモバイル サービスタイプ(2G、3G、4G、5G など)を許可すべきです。
電話ハードウェアが含まれない場合、デバイス実装は:
- [C-2-1] 完全な API を NoOps として実装しなければなりません。
eUICCs または eSIM(埋め込み SIM)をサポートし、eSIM 機能をサードパーティ デベロッパーが利用できるようにする独自のメカニズムが含まれる場合、デバイス実装は:
- [C-3-1]
android.hardware.telephony.euicc
機能フラグを宣言しなければなりません。
システム プロパティ ro.telephony.iwlan\_operation\_mode
を「legacy」に設定しない場合、デバイス実装は:
- [C-4-1] 同じ NetworkRegistrationInfo インスタンスについて NetworkRegistrationInfo#getTransportType() が TRANSPORT_TYPE_WWAN としてレポートされているとき、NetworkRegistrationInfo#getAccessNetworkTechnology() を介して NETWORK_TYPE_IWLAN をレポートしてはなりません。
マルチメディア テレフォニー サービス(MMTEL)機能と Rich Communication Services(RCS)機能の両方について単一の IP マルチメディア サブシステム(IMS)登録をサポートし、すべての IMS シグナリング トラフィックに単一の IMS 登録を使用することに関する携帯通信会社の要件を遵守することが見込まれる場合、デバイス実装は:
- [C-5-1]
android.hardware.telephony.ims
機能フラグを宣言し、MMTEL と RCS の両方の User Capability Exchange API について ImsService API の完全な実装を提供しなければなりません。 - [C-5-2]
android.hardware.telephony.ims.singlereg
機能フラグを宣言しなければならず、SipTransport API、GbaService API、IRadio 1.6 HAL を使用した専用ベアラ表示、自動構成サーバー(ACS)または IMS Configuration API を使用したその他の専用プロビジョニング メカニズムを介したプロビジョニングの、完全な実装を提供しなければなりません。
機能 android.hardware.telephony
をレポートする場合、デバイス実装は:
- [C-6-1] テキスト メッセージ機能を提供する場合、
SmsManager#sendTextMessage
とSmsManager#sendMultipartTextMessage
によって、対応するCarrierMessagingService
が呼び出されなければなりません。マルチメディア メッセージ機能を提供する場合、SmsManager#sendMultimediaMessage
とSmsManager#downloadMultimediaMessage
によって、対応するCarrierMessagingService
が呼び出されなければなりません。 - [C-6-2]
android.provider.Telephony.Sms#getDefaultSmsPackage
で指定されたアプリは、SMS および MMS メッセージを送受信するときに SmsManager API を使用しなければなりません。packages/apps/Messaging の AOSP リファレンス実装はこの要件を満たしています。 - [C-6-3]
Intent#ACTION_DIAL
に応答するアプリは、*#*#CODE#*#*
という形式の任意の電話コードの入力をサポートし、対応するTelephonyManager#ACTION_SECRET_CODE
ブロードキャストをトリガーしなければなりません。 - [C-6-4]
Intent#ACTION_DIAL
に応答するアプリは、ビジュアル ボイスメール音声文字変換をサポートしている場合、VoicemailContract.Voicemails#TRANSCRIPTION
を使用して、ユーザーにビジュアル ボイスメール音声文字変換を表示しなければなりません。 - [C-6-5] SIM カード情報を表示、管理するための、ユーザーに表示されるすべてのアフォーダンスでは、同等のグループ UUID を含むすべての SubscriptionInfo を、単一のサブスクリプションとして表現しなければなりません。このようなアフォーダンスの例としては、
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
やEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
に一致する設定インターフェースなどがあります。 - [C-6-6] SIM カードの設定を構成または制御できる、ユーザーに表示されるアフォーダンスで、非 null グループ UUID と日和見ビットを持つ SubscriptionInfo を表示したり、その制御を許可したりしてはなりません。
機能 android.hardware.telephony
をレポートし、システムのステータスバーを提供する場合、デバイス実装は:
- [C-7-1] SIM ステータス情報を提供するアフォーダンスで、特定のグループ UUID の代表的かつアクティブなサブスクリプションを選択し、ユーザーに表示しなければなりません。このようなアフォーダンスの例としては、ステータスバーの電波アイコンやクイック設定タイルなどがあります。
- [C-SR-1] デバイスが音声通話中である場合を除き、代表的なサブスクリプションがアクティブなデータ サブスクリプションとして選択されるようにすることが強く推奨されます。デバイスが音声通話中の場合は、代表的なサブスクリプションがアクティブな音声サブスクリプションになるようにすることが強く推奨されます。
機能 android.hardware.telephony
をレポートする場合、デバイス実装は:
- [C-6-7] ETSI TS 102 221 に従い、UICC ごとに最大数の論理チャンネル(合計 20 個)を開いて同時に使用できなければなりません。
- [C-6-8] ユーザーによる明示的な確認なしに、アクティブな携帯通信会社アプリ(
TelephonyManager#getCarrierServicePackageName
で指定)に以下の動作のいずれかを自動的に適用してはなりません。- ネットワーク アクセスを取り消す、または制限する
- 権限を取り消す
- バックグラウンドまたはフォアグラウンド アプリの実行を、AOSP に含まれる既存の電源管理機能の範囲を超えて制限する
- アプリを無効にする、またはアンインストールする
デバイス実装が機能 android.hardware.telephony
をレポートし、グループ UUID を共有するすべてのアクティブな非日和見サブスクリプションが無効にされている場合や、デバイスから物理的に削除されている場合、または「日和見的」とマークされている場合、デバイスは:
- [C-8-1] 同じグループ内の残りのアクティブな日和見サブスクリプションをすべて自動的に無効にしなければなりません。
GSM 電話が含まれるが、CDMA 電話は含まれない場合、デバイス実装は:
- [C-9-1]
PackageManager#FEATURE_TELEPHONY_CDMA
を宣言してはなりません。 - [C-9-2] 優先または許可されたネットワーク タイプのビットマスクで 3GPP2 ネットワーク タイプの設定が試みられたときに、
IllegalArgumentException
をスローしなければなりません。 - [C-9-3]
TelephonyManager#getMeid
から空の文字列を返さなければなりません。
複数のポートとプロファイルを持つ eUICC をサポートする場合、デバイス実装は:
- [C-10-1]
android.hardware.telephony.euicc.mep
機能フラグを宣言しなければなりません。
7.4.1.1. 番号ブロックの互換性
機能 android.hardware.telephony.calling
をレポートする場合、デバイス実装は:
- [C-1-1] 番号ブロックのサポートを含まなければなりません。
- [C-1-2] SDK ドキュメントに記載されているとおり、
BlockedNumberContract
と、対応する API を完全に実装しなければなりません。 [C-1-3] アプリを操作せずに、「BlockedNumberProvider」の電話番号からの通話とメッセージをすべてブロックしなければなりません。唯一の例外は、SDK ドキュメントに記載されているとおり、番号ブロックが一時的に解除されている場合です。
[C-1-4] ブロックした通話について、プラットフォーム通話履歴プロバイダに書き込まなければなりません。また、プリインストールされている電話アプリのデフォルトの通話履歴ビューにある通話を、
BLOCKED_TYPE
でフィルタしなければなりません。[C-1-5] ブロックしたメッセージについて、電話プロバイダに書き込んではなりません。
[C-1-6]
TelecomManager.createManageBlockedNumbersIntent()
メソッドから返されたインテントで開くブロック番号管理 UI を実装しなければなりません。[C-1-7] Android プラットフォームは、プライマリ ユーザーがデバイスの電話サービス(単一インスタンス)を完全に管理することを前提としているため、デバイスでブロックした番号をセカンダリ ユーザーが表示または編集できるようにしてはなりません。ブロック関連の UI はすべてセカンダリ ユーザーに対して非表示にしなければならず、ブロックリストを引き続き尊重しなければなりません。
デバイスを Android 7.0 にアップデートするときは、ブロックした番号をプロバイダに移行すべきです。
プリインストールされている電話アプリにブロックした通話を表示するユーザー アフォーダンスを提供すべきです。
7.4.1.2. Telecom API
android.hardware.telephony.calling
をレポートする場合、デバイス実装は:
- [C-1-1] SDK に記載されている
ConnectionService
API をサポートしなければなりません。 - [C-1-2]
CAPABILITY_SUPPORT_HOLD
を介して指定された保留機能をサポートしないサードパーティ アプリによる通話で、ユーザーが通話中のとき、新しい着信を表示し、着信を受け入れるか拒否するユーザー アフォーダンスを提供しなければなりません。 - [C-1-3] アプリで InCallService を実装しなければなりません。
[C-SR-1] 着信に応答すると進行中の通話が途切れる旨をユーザーに通知することが強く推奨されます。
AOSP 実装は、着信に応答すると他の通話が途切れることをユーザーに示すヘッドアップ通知によって、これらの要件を満たしています。
[C-SR-2] サードパーティ アプリが
PhoneAccount
のEXTRA_LOG_SELF_MANAGED_CALLS
エクストラキーをtrue
に設定したとき、通話履歴エントリとサードパーティ アプリ名を通話履歴に表示するデフォルトの電話アプリをプリロードすることが強く推奨されます。[C-SR-3]
android.telecom
API について、オーディオ ヘッドセットのKEYCODE_MEDIA_PLAY_PAUSE
イベントとKEYCODE_HEADSETHOOK
イベントを下記のとおり処理することが強く推奨されます。- 通話中に短押しのキーイベントが検出されたら、
Connection.onDisconnect()
を呼び出す。 - 着信中に短押しのキーイベントが検出されたら、
Connection.onAnswer()
を呼び出す。 - 着信中に長押しのキーイベントが検出されたら、
Connection.onReject()
を呼び出す。 CallAudioState
のミュート ステータスを切り替える。
- 通話中に短押しのキーイベントが検出されたら、
7.4.1.3. モバイル NAT-T キープアライブ オフロード
デバイス実装は:
- モバイル キープアライブ オフロードのサポートを含むべきです。
モバイル キープアライブ オフロードのサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] SocketKeepAlive API をサポートしなければなりません。
- [C-1-2] モバイル ネットワークで少なくとも 1 つの同時キープアライブ スロットをサポートしなければなりません。
- [C-1-3] モバイル Radio HAL でサポートされている数だけ、同時モバイル キープアライブ スロットをサポートしなければなりません。
- [C-SR-1] 無線インスタンスごとに少なくとも 3 つのモバイル キープアライブ スロットをサポートすることが強く推奨されます。
モバイル キープアライブ オフロードのサポートが含まれない場合、デバイス実装は:
- [C-2-1] ERROR_UNSUPPORTED を返さなければなりません。
7.4.2. IEEE 802.11(Wi-Fi)
デバイス実装は:
- 1 つ以上の 802.11 形式のサポートを含むべきです。
802.11 のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] 対応する Android API を実装しなければなりません。
- [C-1-2] ハードウェア機能フラグ
android.hardware.wifi
をレポートしなければなりません。 - [C-1-3] SDK ドキュメントに記載されているとおり、マルチキャスト API を実装しなければなりません。
- [C-1-4] マルチキャスト DNS(mDNS)をサポートしなければならず、画面がアクティブ状態でないときを含むいかなる運用時にも mDNS パケット(224.0.0.251 または ff02::fb)をフィルタしてはなりません。ただし、ターゲット市場に適用される規制要件で要求されている消費電力の範囲内に収めるために、パケットをドロップまたはフィルタする必要がある場合を除きます。
Android テレビデバイス実装の場合、スタンバイ電力状態にあるとき。 - [C-1-5] アプリ トラフィックに対してデフォルトで使用され、
getActiveNetwork
やregisterDefaultNetworkCallback
などのConnectivityManager
API メソッドによって返される、現在アクティブなNetwork
を切り替えるための十分な指標としてWifiManager.enableNetwork()
API メソッド呼び出しを扱ってはなりません。つまり、Wi-Fi ネットワークがインターネット アクセスを提供していることが正常に検証された場合にのみ、他のネットワーク プロバイダが提供するインターネット アクセス(モバイルデータなど)を無効にしても構いません。 - [C-1-6]
ConnectivityManager.reportNetworkConnectivity()
API メソッドが呼び出されたときNetwork
のインターネット アクセスを再度評価し、評価で現在のNetwork
がインターネット アクセスを提供していないと判断されたら、インターネット アクセスを提供する他の利用可能なネットワーク(モバイルデータなど)に切り替えることが強く推奨されます。 - [C-1-7] STA が接続されていないとき、各スキャンの開始時に 1 回、送信元 MAC アドレスと、プローブ リクエスト フレームのシーケンス番号をランダム化しなければなりません。
- [C-1-8] 一貫した 1 つの MAC アドレスを使用しなければなりません(スキャンの途中で MAC アドレスをランダム化すべきではありません)。
- [C-1-9] スキャンにおけるプローブ リクエスト間で、プローブ リクエストのシーケンス番号を通常どおり(順次)反復処理しなければなりません。
- [C-1-10] スキャンの最後のプローブ リクエストと次のスキャンの最初のプローブ リクエストの間で、プローブ リクエストのシーケンス番号をランダム化しなければなりません。
- [C-SR-1] 関連付け中と関連付け後、アクセス ポイント(AP)に対するすべての STA 通信に使用する送信元 MAC アドレスをランダム化することが強く推奨されます。
- デバイスは、通信する SSID(Passpoint の FQDN)ごとに異なるランダムな MAC アドレスを使用しなければなりません。
- デバイスは、ランダム化しないオプションとランダム化するオプションにより、SSID(Passpoint の FQDN)ごとのランダム化を制御するオプションを、ユーザーに提供しなければなりません。また、ランダム化する新しい Wi-Fi 設定のデフォルト モードを設定しなければなりません。
- [C-SR-2] 作成する AP に、ランダムな BSSID を使用することが強く推奨されます。
- AP が使用する SSID ごとに MAC アドレスをランダム化し、保持しなければなりません。
- デバイスは、この機能を無効にするオプションをユーザーに提供しても構いません。このようなオプションを指定する場合は、ランダム化をデフォルトで有効にしなければなりません。
IEEE 802.11 規格で定義されているとおり Wi-Fi 省電力モードのサポートが含まれる場合、デバイス実装は:
WifiManager.createWifiLock()
API とWifiManager.WifiLock.acquire()
API を介してアプリがWIFI_MODE_FULL_HIGH_PERF
ロックまたはWIFI_MODE_FULL_LOW_LATENCY
ロックを取得し、ロックがアクティブであるときは必ず、Wi-Fi 省電力モードをオフにしなければなりません。- [C-3-2] デバイスが Wi-Fi 低レイテンシ ロック(
WIFI_MODE_FULL_LOW_LATENCY
)モードになっているときの、デバイスとアクセス ポイントの間の平均ラウンドトリップ レイテンシが、Wi-Fi 高パフォーマンス ロック(WIFI_MODE_FULL_HIGH_PERF
)モードになっているときのレイテンシよりも小さくなければなりません。 - [C-SR-3] 低レイテンシ ロック(
WIFI_MODE_FULL_LOW_LATENCY
)が取得されて有効になるときは必ず、Wi-Fi ラウンドトリップ レイテンシを最小限に抑えることが強く推奨されます。
Wi-Fi をサポートし、位置情報スキャンに Wi-Fi を使用する場合、デバイス実装は:
- [C-2-1]
WifiManager.isScanAlwaysAvailable
API メソッドを通じて読み取った値を有効化 / 無効化するユーザー アフォーダンスを提供しなければなりません。
7.4.2.1. Wi-Fi Direct
デバイス実装は:
- Wi-Fi Direct(Wi-Fi ピアツーピア)のサポートを含むべきです。
Wi-Fi Direct をサポートする場合、デバイス実装は:
- [C-1-1] SDK ドキュメントに記載されているとおり、対応する Android API を実装しなければなりません。
- [C-1-2] ハードウェア機能
android.hardware.wifi.direct
をレポートしなければなりません。 - [C-1-3] 通常の Wi-Fi 運用をサポートしなければなりません。
- [C-1-4] Wi-Fi と Wi-Fi Direct の運用を同時にサポートしなければなりません。
- [C-SR-1] 新たに形成されるすべての Wi-Fi Direct 接続の送信元 MAC アドレスをランダム化することが強く推奨されます。
7.4.2.2. Wi-Fi Tunneled Direct Link Setup
デバイス実装は:
- Android SDK ドキュメントに記載されているとおり、Wi-Fi Tunneled Direct Link Setup(TDLS)のサポートを含むべきです。
TDLS のサポートが含まれ、WiFiManager API で TDLS が有効になっている場合、デバイス実装は:
- [C-1-1]
WifiManager.isTdlsSupported
を通じて TDLS のサポートを宣言しなければなりません。 - 可能かつ有効な場合にのみ、TDLS を使用すべきです。
- TDLS のパフォーマンスが Wi-Fi アクセス ポイントを通過する場合よりも悪くなる可能性がある場合は、TDLS を使用せず、なんらかのヒューリスティックを使用すべきです。
7.4.2.3. Wi-Fi Aware
デバイス実装は:
- Wi-Fi Aware のサポートを含むべきです。
Wi-Fi Aware のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] SDK ドキュメントに記載されているとおり、
WifiAwareManager
API を実装しなければなりません。 - [C-1-2]
android.hardware.wifi.aware
機能フラグを宣言しなければなりません。 - [C-1-3] Wi-Fi と Wi-Fi Aware の運用を同時にサポートしなければなりません。
- [C-1-4] Wi-Fi Aware が有効になっているときは常に、30 分以下の間隔で Wi-Fi Aware 管理インターフェースのアドレスをランダム化しなければなりません。ただし、Aware レンジング オペレーションが進行中であるか、Aware データパスがアクティブである場合を除きます(データパスがアクティブである限り、通常はランダム化は行われません)。
セクション 7.4.2.5 に記載されているとおり Wi-Fi Aware と Wi-Fi Location のサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-2-1] 位置認識検出 API setRangingEnabled、setMinDistanceMm、setMaxDistanceMm、onServiceDiscoveredWithinRange を実装しなければなりません。
7.4.2.4. Wi-Fi Passpoint
802.11(Wi-Fi)のサポートが含まれる場合、デバイス実装は:
- [C-1-1] Wi-Fi Passpoint のサポートを含まなければなりません。
- [C-1-2] SDK ドキュメントに記載されているとおり、Passpoint 関連の
WifiManager
API を実装しなければなりません。 - [C-1-3] IEEE 802.11u 規格、特に Generic Advertisement Service(GAS)や Access Network Query Protocol(ANQP)など、ネットワークの検出と選択に関連するものをサポートしなければなりません。
- [C-1-4]
android.hardware.wifi.passpoint
機能フラグを宣言しなければなりません。 - [C-1-5] AOSP 実装に従い、Passpoint ネットワークを検出、照合、関連付けしなければなりません。
- [C-1-6] Wi-Fi Alliance Passpoint R2 で規定されているとおり、デバイスのプロビジョニング プロトコルのサブセットのうち、少なくとも EAP-TTLS 認証と SOAP-XML をサポートしなければなりません。
- [C-1-7] Hotspot 2.0 R3 仕様に記載されているとおり、AAA サーバー証明書を処理しなければなりません。
- [C-1-8] Wi-Fi 選択ツールを通じたプロビジョニングのユーザー コントロールをサポートしなければなりません。
- [C-1-9] 再起動後も永続的に Passpoint 設定を維持しなければなりません。
- [C-SR-1] 利用規約への同意機能をサポートすることが強く推奨されます。
- [C-SR-2] 場所情報機能をサポートすることが強く推奨されます。
グローバルで Passpoint を無効化するユーザー コントロール スイッチが提供されている場合、実装は:
- [C-3-1] Passpoint をデフォルトで有効にしなければなりません。
7.4.2.5. Wi-Fi Location(Wi-Fi ラウンドトリップ時間 - RTT)
デバイス実装は:
- Wi-Fi Location のサポートを含むべきです。
Wi-Fi Location のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] SDK ドキュメントに記載されているとおり、
WifiRttManager
API を実装しなければなりません。 - [C-1-2]
android.hardware.wifi.rtt
機能フラグを宣言しなければなりません。 - [C-1-3] RTT が実行されている Wi-Fi インターフェースがアクセス ポイントに関連付けられていない間、実行される RTT バーストごとに、送信元 MAC アドレスをランダム化しなければなりません。
- [C-1-4] 累積分布関数で計算して、68 パーセンタイル、80 MHz 帯域幅で、正確度が 2 メートル以内でなければなりません。
- [C-SR-1] 累積分布関数で計算して、68 パーセンタイル、80 MHz 帯域幅で、正確度が 1.5 メートル以内でレポートすることが強く推奨されます。
7.4.2.6. Wi-Fi キープアライブ オフロード
デバイス実装は:
- Wi-Fi キープアライブ オフロードのサポートを含むべきです。
Wi-Fi キープアライブ オフロードのサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] SocketKeepAlive API をサポートしなければなりません。
- [C-1-2] Wi-Fi で少なくとも 3 つの同時キープアライブ スロットをサポートしなければなりません。
Wi-Fi キープアライブ オフロードのサポートが含まれない場合、デバイス実装は:
- [C-2-1]
ERROR_UNSUPPORTED
を返さなければなりません。
7.4.2.7. Wi-Fi Easy Connect(デバイス プロビジョニング プロトコル)
デバイス実装は:
- Wi-Fi Easy Connect(DPP)のサポートを含むべきです。
Wi-Fi Easy Connect のサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] WifiManager#isEasyConnectSupported() メソッドが
true
を返さなければなりません。
7.4.2.8. エンタープライズ Wi-Fi サーバー証明書の検証
Wi-Fi サーバー証明書が検証されていない場合、または Wi-Fi サーバー ドメイン名が設定されていない場合、デバイス実装は:
- [C-SR-1] 設定アプリにエンタープライズ Wi-Fi ネットワークを手動で追加するオプションをユーザーに提供しないことが強く推奨されます。
7.4.2.9. 初回使用時の信頼(TOFU)
デバイス実装は、初回使用時の信頼(TOFU)をサポートし、ユーザーが WPA/WPA2/WPA3-Enterprise の設定を定義することを許可している場合:
- [C-4-1] TOFU の使用を選択するオプションをユーザーに提供しなければなりません。
7.4.3. Bluetooth
Bluetooth オーディオ プロファイルをサポートする場合、デバイス実装は:
- Advanced オーディオ コーデックと Bluetooth オーディオ コーデック(LDAC など)をサポートすべきです。
HFP、A2DP、AVRCP をサポートする場合、デバイス実装は:
- 合計で少なくとも 5 つのデバイスの接続をサポートすべきです。
android.hardware.vr.high_performance
機能を宣言する場合、デバイス実装は:
- [C-1-1] Bluetooth 4.2 と Bluetooth LE データ長拡張をサポートしなければなりません。
Android は、Bluetooth と Bluetooth Low Energy をサポートしています。
Bluetooth と Bluetooth Low Energy のサポートが含まれる場合、デバイス実装は:
- [C-2-1] 関連するプラットフォーム機能(それぞれ
android.hardware.bluetooth
、android.hardware.bluetooth_le
)を宣言し、プラットフォーム API を実装しなければなりません。 - デバイスに応じて、A2DP、AVRCP、OBEX、HFP など、関連する Bluetooth プロファイルを実装すべきです。
Bluetooth Low Energy(BLE)のサポートが含まれる場合、デバイス実装は:
- [C-3-1] ハードウェア機能
android.hardware.bluetooth_le
を宣言しなければなりません。 - [C-3-2] SDK ドキュメントと android.bluetooth に記載されているとおり、GATT(汎用属性プロファイル)ベースの Bluetooth API を有効にしなければなりません。
- [C-3-3] ScanFilter API クラスのフィルタリング ロジックが実装されているかどうかを示す
BluetoothAdapter.isOffloadedFilteringSupported()
の正しい値をレポートしなければなりません。 - [C-3-4] Low Energy のアドバタイジングがサポートされているかどうかを示す
BluetoothAdapter.isMultipleAdvertisementSupported()
の正しい値をレポートしなければなりません。 [C-3-5] デバイスがアクティブに BLE を使用してスキャンまたはアドバタイズしている場合は、ユーザーのプライバシーを保護するために、15 分以下の解決可能なプライベート アドレス(RPA)タイムアウトを実装し、タイムアウト時にアドレスをローテーションしなければなりません。タイミング攻撃を防ぐために、タイムアウト間隔も 5 分から 15 分の間でランダム化しなければなりません。
ScanFilter API を実装するとき、Bluetooth チップセットに対するフィルタリング ロジックのオフロードをサポートすべきです。
Bluetooth チップセットに対するバッチスキャンのオフロードをサポートすべきです。
少なくとも 4 スロットのマルチ アドバタイズメントをサポートすべきです。
Bluetooth LE をサポートし、位置情報スキャンに Bluetooth LE を使用する場合、デバイス実装は:
- [C-4-1] システム API
BluetoothAdapter.isBleScanAlwaysAvailable()
を通じて読み取った値を有効化 / 無効化するユーザー アフォーダンスを提供しなければなりません。
Bluetooth LE を使用した補聴器の音声サポートに記載されているとおり、Bluetooth LE と補聴器プロファイルのサポートが含まれる場合、デバイス実装は:
- [C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) について
true
を返さなければなりません。
Bluetooth と Bluetooth Low Energy のサポートが含まれる場合、デバイス実装は:
- [C-6-1] リクエスト元アプリが現在のフォアグラウンド / バックグラウンド状態に基づいて正常に
android.permission.ACCESS_FINE_LOCATION
権限チェックに合格する場合を除き、デバイスの位置情報を導出するために使用できる Bluetooth メタデータ(スキャン結果など)へのアクセスを制限しなければなりません。
デバイス実装に Bluetooth または Bluetooth Low Energy のサポートが含まれ、アプリ マニフェストに Bluetooth から位置情報を導出しないというデベロッパー宣言が含まれない場合、デバイス実装は:
- [C-6-2]
android.permission.ACCESS_FINE_LOCATION
の背後での Bluetooth アクセスを制限しなければなりません。
BluetoothAdapter.isLeAudioSupported()
API について true
を返す場合、デバイス実装は:
- [C-7-1] ユニキャスト クライアントをサポートしなければなりません。
- [C-7-2] 2M PHY をサポートしなければなりません。
- [C-7-3] LE 拡張アドバタイジングをサポートしなければなりません。
- [C-7-4] CIG で少なくとも 2 つの CIS 接続をサポートしなければなりません。
- [C-7-5] BAP ユニキャスト クライアント、CSIP セット コーディネーター、MCP サーバー、VCP コントローラ、CCP サーバーを同時に有効にしなければなりません。
- [C-SR-1] HAP ユニキャスト クライアントを有効にすることが強く推奨されます。
BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API について true
を返す場合、デバイス実装は:
- [C-8-1] BIG で少なくとも 2 つの BIS リンクをサポートしなければなりません。
- [C-8-2] BAP ブロードキャスト ソース、BAP ブロードキャスト アシスタントを同時に有効にしなければなりません。
- [C-8-3] LE 定期アドバタイジングをサポートしなければなりません。
BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API について true
を返す場合、デバイス実装は:
- [C-9-1] PAST(Periodic Advertising Sync Transfer)をサポートしなければなりません。
- [C-9-2] LE 定期アドバタイジングをサポートしなければなりません。
FEATURE_BLUETOOTH_LE
を宣言する場合、デバイス実装は:
- [C-10-1] 見通せる環境において
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスから 1 m の距離で測定した RSSI の 95% が、+/-9 dB 以内でなければなりません。 [C-10-2] 3 つのチャンネルそれぞれのアンテナ(複数使用されている場合)での測定値の 95% が、互いに +/-3 dB 以内になるように、チャンネルごとの偏差を低減するための Rx / Tx 調整を含まなければなりません。
[C-SR-2]
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -60 dBm +/-10 dB になるように、Rx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。[C-SR-3] 1 m の距離に位置し、
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -60dBm +/-10 dB になるように、Tx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。要件 [C-10-3]、[C-10-4] を 2.2.1. ハードウェアに移動しました。
- [C-10-3]
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -55 dBm +/-10 dB になるように、Rx オフセットを測定し補正しなければなりません。 - [C-10-4] 1 m の距離に位置し、
ADVERTISE_TX_POWER_HIGH
で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -55 dBm +/-10 dB になるように、Tx オフセットを測定し補正する必要があります。
プレゼンス キャリブレーションの要件で指定されている測定のセットアップ手順に沿うことが強く推奨されます。
Bluetooth バージョン 5.0 をサポートする場合、デバイス実装は:
- [C-SR-4] 次のサポートを提供することが強く推奨されます:
- LE 2M PHY
- LE Coded PHY
- LE Advertising Extension
- Periodic advertising
- 10 個以上の広告セット
- 8 接続以上の LE 同時接続。各接続は、いずれかの接続トポロジのロールに含めることができます。
- LE Link Layer Privacy
- 8 エントリ以上のサイズの「解決リスト」
7.4.4. 近距離無線通信
デバイス実装は:
- 近距離無線通信(NFC)用の送受信機と関連ハードウェアを含むべきです。
- [C-0-1] プロトコルに依存しないデータ表現形式をクラスが表すため、NFC のサポートが含まれないか、
android.hardware.nfc
機能を宣言する場合であっても、android.nfc.NdefMessage
API とandroid.nfc.NdefRecord
API を実装しなければなりません。
NFC ハードウェアが含まれ、サードパーティ アプリで利用できるようにする予定の場合、デバイス実装は:
- [C-1-1]
android.content.pm.PackageManager.hasSystemFeature()
メソッドからandroid.hardware.nfc
機能をレポートしなければなりません。 - 下記の NFC 規格を介して NDEF メッセージの読み書きができなければなりません。
- [C-1-2] 次の NFC 規格を介して、NFC フォーラムのリーダー / ライター(NFC フォーラムの技術仕様 NFCForum-TS-DigitalProtocol-1.0 で定義)として動作できなければなりません。
- NfcA(ISO14443-3A)
- NfcB(ISO14443-3B)
- NfcF(JIS X 6319-4)
- IsoDep(ISO 14443-4)
- NFC フォーラムのタグタイプ 1、2、3、4、5(NFC フォーラムにより定義)
[C-SR-1] 次の NFC 規格を介して NDEF メッセージと元データを読み書きできることが強く推奨されます。なお、NFC 規格は「強く推奨」として記載されていますが、今後のバージョンの互換性定義では「しなければならない」に変更される予定です。これらの規格は、このバージョンでは任意ですが、今後のバージョンでは必須となります。このバージョンの Android を搭載した既存または新規のデバイスは現在、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが極めて強く奨励されています。
[C-1-13] NFC 検出モードにあるとき、サポートされているすべての技術をポーリングしなければなりません。
画面がアクティブ、ロック画面がロック解除された状態でデバイスが起動しているときは、NFC 検出モードになっているべきです。
Thinfilm NFC Barcode プロダクトのバーコードと URL(エンコードされている場合)の読み取りができるべきです。
なお、上記の JIS、ISO、NFC フォーラムの仕様について、一般公開されているリンクはありません。
Android は、NFC ホストカード エミュレーション(HCE)モードをサポートしています。
HCE(NfcA や NfcB) に対応した NFC コントローラ チップセットが含まれ、アプリ ID(AID)ルーティングをサポートする場合、デバイス実装は:
- [C-2-1]
android.hardware.nfc.hce
機能定数をレポートしなければなりません。 - [C-2-2] Android SDK で定義されているとおり、NFC HCE API をサポートしなければなりません。
NfcF の HCE に対応した NFC コントローラ チップセットが含まれ、サードパーティ アプリ向けの機能を実装する場合、デバイス実装は:
- [C-3-1]
android.hardware.nfc.hcef
機能定数をレポートしなければなりません。 - [C-3-2] Android SDK で定義されているとおり、NfcF カード エミュレーション API を実装しなければなりません。
このセクションに記載するとおり一般的な NFC サポートが含まれ、リーダー / ライターの役割で MIFARE 技術(MIFARE Classic、MIFARE Ultralight、NDEF on MIFARE Classic)をサポートする場合、デバイス実装は:
- [C-4-1] Android SDK に記載されているとおり、対応する Android SDK を実装しなければなりません。
- [C-4-2]
android.content.pm.PackageManager.hasSystemFeature
() メソッドからcom.nxp.mifare
機能をレポートしなければなりません。なお、これは Android の標準の機能ではないため、android.content.pm.PackageManager
クラスの定数としては表示されません。
7.4.5. ネットワーキング プロトコルと API
7.4.5.1. 最低限のネットワーク機能
デバイス実装は:
- [C-0-1] 1 つ以上のデータ ネットワーク形式のサポートを含まなければなりません。具体的には、デバイス実装は、200 Kbit/sec 以上の能力を持つ、少なくとも 1 つのデータ標準のサポートを含まなければなりません。この要件を満たす技術の例としては、EDGE、HSPA、EV-DO、802.11g、イーサネット、Bluetooth PAN が挙げられます。
- 物理的なネットワーク標準(イーサネットなど)がメインのデータ接続である場合、802.11(Wi-Fi)など、1 つ以上の一般的なワイヤレス データ標準のサポートを含むべきです。
- 複数の形式のデータ接続を実装しても構いません。
7.4.5.2. IPv6
デバイス実装は:
- [C-0-2] IPv6 ネットワーク スタックを含まなければならず、
java.net.Socket
やjava.net.URLConnection
などのマネージド API と、AF_INET6
ソケットなどのネイティブ API を使用した IPv6 通信をサポートしなければなりません。 - [C-0-3] IPv6 をデフォルトで有効にしなければなりません。
- IPv6 通信に IPv4 と同等の信頼性を確保しなければなりません。たとえば:
- [C-0-4] Doze モードで IPv6 接続を維持しなければなりません。
- [C-0-5] 少なくとも 180 秒の RA ライフタイムを使用する IPv6 準拠ネットワークで、レート制限によってデバイスの IPv6 接続が失われてはなりません。
- IPv6 通信に IPv4 と同等の信頼性を確保しなければなりません。たとえば:
- [C-0-6] IPv6 ネットワークに接続されているときに、デバイスのローカル側でアドレスまたはポート変換を一切行うことなく、サードパーティ アプリに直接 IPv6 接続を提供しなければなりません。
Socket#getLocalAddress
やSocket#getLocalPort
などのマネージド API と、getsockname()
やIPV6_PKTINFO
などの NDK API はどちらも、ネットワーク上でパケットを送受信するために実際に使用されインターネット(ウェブ)サーバーへの送信元の IP とポートとして認識される、IP アドレスとポートを返さなければなりません。
必要な IPv6 サポートレベルは、次の要件に示すように、ネットワークの種類によって異なります。
Wi-Fi をサポートする場合、デバイス実装は:
- [C-1-1] Wi-Fi でのデュアルスタックと IPv6 のみのオペレーションをサポートしなければなりません。
イーサネットをサポートする場合、デバイス実装は:
- [C-2-1] イーサネットでのデュアルスタックと IPv6 のみのオペレーションをサポートしなければなりません。
モバイルデータをサポートする場合、デバイス実装は:
- [C-3-1] モバイル ネットワークでの IPv6 オペレーション(IPv6 のみ、場合によってはデュアルスタック)をサポートしなければなりません。
ネットワークの種類を複数サポートする場合(例: Wi-Fi とモバイルデータ)、デバイス実装は:
- [C-4-1] デバイスが同時に複数の種類のネットワークに接続されているとき、上記の要件を各ネットワークで同時に満たさなければなりません。
7.4.5.3. キャプティブ ポータル
キャプティブ ポータルとは、インターネット アクセスにログインが必要なネットワークのことです。
android.webkit.Webview API
の完全な実装を提供する場合、デバイス実装は:
- [C-1-1] インテント
ACTION_CAPTIVE_PORTAL_SIGN_IN
を処理し、システム APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
の呼び出しでそのインテントを送信することでキャプティブ ポータル ログインページを表示するための、キャプティブ ポータルアプリを提供しなければなりません。 - [C-1-2] デバイスが、モバイル ネットワーク、Wi-Fi、イーサネット、Bluetooth を含む任意の種類のネットワークに接続されているとき、キャプティブ ポータルの検出を行い、キャプティブ ポータルアプリを通じたログインをサポートしなければなりません。
- [C-1-3] デバイスがプライベート DNS の厳格モードを使用するように設定されている場合、平文 DNS を使用したキャプティブ ポータルへのログインをサポートしなければなりません。
- [C-1-4] キャプティブ ポータルと明示的に通信していないすべてのネットワーク トラフィックについて、
android.net.LinkProperties.getPrivateDnsServerName
とandroid.net.LinkProperties.isPrivateDnsActive
の SDK ドキュメントに従い、暗号化 DNS を使用しなければなりません。 - [C-1-5] ユーザーがキャプティブ ポータルにログインしている間、アプリが使用するデフォルト ネットワーク(
ConnectivityManager.getActiveNetwork
、ConnectivityManager.registerDefaultNetworkCallback
によって返され、java.net.Socket などの Java ネットワーキング API と、connect() などのネイティブ API がデフォルトで使用)が、インターネット アクセスを提供する他の利用可能なネットワークになるようにしなければなりません(利用可能な場合)。
7.4.6. 同期設定
デバイス実装は:
- [C-0-1] メソッド
getMasterSyncAutomatically()
が「true」を返すように、マスター自動同期設定をデフォルトでオンにしなければなりません。
7.4.7. データセーバー
従量制接続が含まれる場合、デバイス実装は:
- [C-SR-1] データセーバー モードを提供することが強く推奨されます。
データセーバー モードを提供する場合、デバイス実装は:
- [C-1-1] SDK ドキュメントに記載されているとおり、
ConnectivityManager
クラスの API をすべてサポートしなければなりません。
データセーバー モードを提供しない場合、デバイス実装は:
- [C-2-1]
ConnectivityManager.getRestrictBackgroundStatus()
について値RESTRICT_BACKGROUND_STATUS_DISABLED
を返さなければなりません。 - [C-2-2]
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
をブロードキャストしてはなりません。
7.4.8. セキュア エレメント
Open Mobile API 対応のセキュア エレメントをサポートし、サードパーティ アプリで利用できるようにする場合、デバイス実装は:
[C-1-1]
android.se.omapi.SEService.getReaders()
API を介して利用可能なセキュア エレメント リーダーを列挙しなければなりません。[C-1-2] UICC ベースのセキュア エレメントを備えたデバイスについては
android.hardware.se.omapi.uicc
を介して、eSE ベースのセキュア エレメントを備えたデバイスにはandroid.hardware.se.omapi.ese
を介して、SD ベースのセキュア エレメントを備えたデバイスにはandroid.hardware.se.omapi.sd
を介して、正しい機能フラグを宣言しなければなりません。
7.4.9. UWB
802.1.15.4 のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:
- [C-1-1] 対応する Android API を android.uwb に実装しなければなりません。
- [C-1-2] ハードウェア機能フラグ android.hardware.uwb をレポートしなければなりません。
- [C-1-3] Android 実装で定義されている関連する UWB プロファイルをすべてサポートしなければなりません。
- [C-1-4] ユーザーが UWB 無線のオン / オフの状態を切り替えられるようにするユーザー アフォーダンスを提供しなければなりません。
- [C-1-5] UWB 無線を使用するアプリが(NEARBY_DEVICES 権限グループの下で)UWB_RANGING 権限を保持するようにしなければなりません。
- [C-SR-1] FIRA、CCC、CSA などの標準化団体によって定義されている、関連する適合性および認証テストに合格することが強く推奨されます。
- [C-1-6] 見通せる環境において、無反射チャンバー内の 1 m の距離で測定した測定値の 95% で、距離の測定値が +/-15 cm 以内になるようにしなければなりません。
- [C-1-7] 参照デバイスから 1 m の距離で測定した値の中央値が [0.75 m, 1.25 m] 以内になるようにしなければなりません。この場合、グラウンド トゥルースの距離は、
上を向けて 45 度傾けたDUT の上端から測定します。 - [C-SR-2] プレゼンス キャリブレーションの要件で指定されている測定のセットアップ手順に沿うことが強く推奨されます。
7.5. カメラ
カメラが 1 つ以上含まれる場合、デバイス実装は:
- [C-1-1]
android.hardware.camera.any
機能フラグを宣言しなければなりません。 - [C-1-2] カメラが基本的なプレビューのために開かれ、引き続きキャプチャしているとき、デバイス上の最大解像度のカメラセンサーによって生成された画像のサイズに等しい 3 つの RGBA_8888 ビットマップを、アプリが同時に割り当てることができなければなりません。
- [C-1-3] 受信アプリに
ACCESS_FINE_LOCATION
がない場合、インテントMediaStore.ACTION_IMAGE_CAPTURE
、MediaStore.ACTION_IMAGE_CAPTURE_SECURE
、またはMediaStore.ACTION_VIDEO_CAPTURE
を処理するプリインストールのデフォルト カメラアプリが、画像メタデータ内のユーザー位置情報を削除してから受信アプリに送信するようにしなければなりません。
HDR 10 ビット出力機能をサポートする場合、デバイス実装は:
- [C-2-1] 10 ビット出力をサポートするすべてのカメラデバイスで、少なくとも HLG HDR プロファイルをサポートしなければなりません。
- [C-2-2] プライマリ背面カメラまたはプライマリ前面カメラのいずれかで 10 ビット出力をサポートしなければなりません。
- [C-SR-1] 両方のプライマリ カメラで 10 ビット出力をサポートすることが強く推奨されます。
- [C-2-3] 論理カメラのすべての BACKWARD_COMPATIBLE 対応物理サブカメラと、論理カメラ自体について、同じ HDR プロファイルをサポートしなければなりません。
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API を実装する 10 ビット HDR をサポートする論理カメラデバイスは:
- [C-3-1] 論理カメラの
CONTROL_ZOOM_RATIO
コントロールを介して、下位互換性のあるすべての物理カメラの切り替えをサポートしなければなりません。
7.5.1. 背面カメラ
背面カメラとは、デバイスのディスプレイとは反対側に配置されたカメラのことです。つまり、従来のカメラのようにデバイスの向こう側の光景を撮影するものです。
新しい要件の開始
背面カメラとは、従来のカメラのようにデバイスの向こう側の光景を撮影するワールド フェイシング カメラです。ハンドヘルド デバイスでは、デバイスのディスプレイの反対側に配置されたカメラです。
新しい要件の終了
デバイス実装は:
- 背面カメラを含むべきです。
背面カメラが 1 つ以上含まれる場合、デバイス実装は:
- [C-1-1] 機能フラグ
android.hardware.camera
とandroid.hardware.camera.any
をレポートしなければなりません。 - [C-1-2] 解像度が少なくとも 2 メガピクセルでなければなりません。
- カメラドライバでハードウェア オートフォーカスまたはソフトウェア オートフォーカスを実装すべきです(アプリ ソフトウェアに対して透過的)。
- 固定フォーカスまたは EDOF(拡張被写界深度)のハードウェアがあっても構いません。
- フラッシュを含んでも構いません。
カメラにフラッシュが含まれる場合:
- [C-2-1] アプリが
Camera.Parameters
オブジェクトのFLASH_MODE_AUTO
またはFLASH_MODE_ON
属性を有効にすることでフラッシュを明示的に有効にしている場合を除き、android.hardware.Camera.PreviewCallback
インスタンスがカメラ プレビュー サーフェスに登録されている間は、フラッシュ ランプが点灯してはなりません。なお、この制約は、デバイスの内蔵システム カメラアプリには適用されず、Camera.PreviewCallback
を使用するサードパーティ アプリにのみ適用されます。
7.5.2. 前面カメラ
前面カメラとは、デバイスのディスプレイと同じ側に配置されたカメラのことです。つまり、通常はビデオ会議や類似のアプリなどでユーザーを撮影するために使用されるカメラです。
新しい要件の開始
前面カメラとは、ビデオ会議や同様のアプリなどでユーザーを撮影するために一般的な使用されるユーザー向きカメラです。ハンドヘルド デバイスでは、デバイスのディスプレイと同じ側に配置されたカメラを使用します。
新しい要件の終了
デバイス実装は:
- 前面カメラを含んでも構いません。
前面カメラが 1 つ以上含まれる場合、デバイス実装は:
- [C-1-1] 機能フラグ
android.hardware.camera.any
とandroid.hardware.camera.front
をレポートしなければなりません。 - [C-1-2] 解像度が少なくとも VGA(640x480 ピクセル)でなければなりません。
- [C-1-3] 前面カメラを Camera API のデフォルトとして使用してはならず、たとえデバイス上の唯一のカメラであったとしても、前面カメラをデフォルトの背面カメラとして扱うように API を設定してはなりません。
- [C-1-4] 現在のアプリが
android.hardware.Camera.setDisplayOrientation()
メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的にリクエストした場合、カメラ プレビューは、アプリが指定した画面の向きに対して水平方向にミラーリングされなければなりません。逆に、現在のアプリがandroid.hardware.Camera.setDisplayOrientation()
メソッドの呼び出しを介してカメラ ディスプレイの回転を明示的にリスエストしなかった場合、カメラ プレビューは、デバイスのデフォルトの水平軸に沿ってミラーリングされなければなりません。 - [C-1-5] アプリのコールバックに対して返されたか、メディア ストレージに対してコミットされた、キャプチャした最終的な静止画または動画のストリームをミラーリングしてはなりません。
- [C-1-6] カメラ プレビューの画像ストリームと同じ方法で、ポストビューで表示される画像をミラーリングしなければなりません。
- セクション 7.5.1 に記載されているとおり、背面カメラで利用できる機能(オートフォーカス、フラッシュなど)を含めても構いません。
デバイス実装が、ユーザーによって回転できる場合(たとえば、加速度計を介して自動的に、またはユーザー入力を介して手動で):
- [C-2-1] カメラ プレビューは、デバイスの現在の画面の向きに対して水平方向にミラーリングされなければなりません。
7.5.3. 外部カメラ
新しい要件の開始
外部カメラとは、デバイス実装にいつでも物理的に取り付けや取り外しができ、任意の方向に向けることができるカメラ(USB カメラなど)です。
新しい要件の終了
デバイス実装は:
- 常に接続されているとは限らない外部カメラのサポートを含むべきです。
外部カメラのサポートが含まれる場合、デバイス実装は:
- [C-1-1] プラットフォーム機能フラグ
android.hardware.camera.external
とandroid.hardware camera.any
を宣言しなければなりません。 - [C-1-2] 外部カメラが USB ホストポートを通じて接続される場合、USB ビデオクラス(UVC 1.0 以上)をサポートしなければなりません。
- [C-1-3] 物理的な外部カメラデバイスが接続された状態でカメラ CTS テストに合格しなければなりません。カメラ CTS テストの詳細については、source.android.com をご覧ください。
- 高品質な未エンコード ストリーム(つまり、未加工または個別に圧縮された画像ストリーム)の転送を可能にするために、MJPEG のような動画圧縮をサポートすべきです。
- 複数のカメラをサポートしても構いません。
- カメラベースの動画エンコードをサポートしても構いません。
カメラベースの動画エンコードがサポートされる場合:
- [C-2-1] 同時未エンコード / MJPEG ストリーム(解像度 QVGA 以上)が、デバイス実装にアクセス可能でなければなりません。
7.5.4. カメラ API の動作
Android には、カメラにアクセスするための API パッケージが 2 つあります。新しい android.hardware.camera2 API は、下位レベルのカメラ制御をアプリに公開します。これには、効率的なゼロコピー バースト / ストリーミング フローと、フレームごとの露出、ゲイン、ホワイト バランスゲイン、色変換、ノイズ除去、シャープニングの制御が含まれます。
古い API パッケージ android.hardware.Camera
は、Android 5.0 でサポートが終了しましたが、引き続きアプリでの使用はできるはずです。Android デバイス実装は、このセクションと Android SDK に記載されているとおり、API の継続的なサポートを保証しなければなりません。
サポートが終了した android.hardware.Camera クラスと新しい android.hardware.camera2 パッケージに共通する機能はすべて、両方の API でパフォーマンスと品質が同等でなければなりません。たとえば、同等の設定では、オートフォーカスの速度と正確度が同じでなければならず、キャプチャした画像の品質も同じでなければなりません。2 つの API の異なるセマンティクスに依存する機能は、速度または品質が一致する必要はありませんが、可能な限り近づけるべきです。
デバイス実装は、利用可能なカメラすべてについて、カメラ関連の API のために次の動作を実装しなければなりません。デバイス実装は:
- [C-0-1] アプリが
android.hardware.Camera.Parameters.setPreviewFormat(int)
を一度も呼び出したことがない場合、アプリのコールバックに提供されるプレビュー データにandroid.hardware.PixelFormat.YCbCr_420_SP
を使用しなければなりません。 - [C-0-2] さらに、アプリが
android.hardware.Camera.PreviewCallback
インスタンスを登録し、システムがonPreviewFrame()
メソッドを呼び出すときは NV21 エンコード形式でなければならず、プレビュー形式は YCbCr_420_SP(onPreviewFrame()
に渡される byte[] のデータ)です。つまり、NV21 がデフォルトでなければなりません。 - [C-0-3]
android.hardware.Camera
の前面カメラと背面カメラ両方のカメラ プレビュー用に、YV12 形式(android.graphics.ImageFormat.YV12
定数で表されます)をサポートしなければなりません(ハードウェア動画エンコーダとカメラは任意のネイティブ ピクセル形式を使用できますが、デバイス実装は YV12 への変換をサポートしなければなりません)。 - [C-0-4]
android.request.availableCapabilities
でREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
機能をアドバタイズするandroid.hardware.camera2
デバイスについて、android.media.ImageReader
API を通じた出力としてandroid.hardware.ImageFormat.YUV_420_888
形式とandroid.hardware.ImageFormat.JPEG
形式をサポートしなければなりません。 - [C-0-5] デバイスにハードウェア オートフォーカスなどの機能があるかどうかにかかわらず、引き続き Android SDK ドキュメントに含まれるカメラ API を完全に実装しなければなりません。たとえば、オートフォーカスのないカメラは、(オートフォーカスのないカメラには関係がなくとも)登録された
android.hardware.Camera.AutoFocusCallback
インスタンスを引き続き呼び出さなければなりません。なお、これは前面カメラに適用されます。たとえば、前面カメラはたいていの場合オートフォーカスをサポートしていませんが、それでも前述のように API コールバックを「偽装」しなければなりません。 - [C-0-6]
android.hardware.Camera.Parameters
クラスとandroid.hardware.camera2.CaptureRequest
クラスで定数として定義された各パラメータ名を認識し、使用しなければなりません。逆に、デバイス実装はandroid.hardware.Camera.Parameters
で定数として記述されているもの以外の、android.hardware.Camera.setParameters()
メソッドに渡された文字列定数を使用または認識してはなりません。つまりデバイス実装は、ハードウェアが許すならば標準的なカメラ パラメータをすべてサポートしなければならず、カスタムのカメラ パラメータ タイプをサポートしてはなりません。たとえば、ハイ ダイナミック レンジ(HDR)画像処理手法を使用する画像キャプチャをサポートするデバイス実装は、カメラ パラメータCamera.SCENE_MODE_HDR
をサポートしなければなりません。 - [C-0-7] Android SDK に記載されているとおり、
android.info.supportedHardwareLevel
プロパティで適切なサポートレベルをレポートし、該当するフレームワーク機能フラグをレポートしなければなりません。 - [C-0-8] また、
android.request.availableCapabilities
プロパティを介してandroid.hardware.camera2
の個々のカメラ機能を宣言し、該当する機能フラグを宣言しなければなりません。装着されているカメラデバイスのいずれかが機能をサポートしている場合は機能フラグを定義しなければなりません。 - [C-0-9] カメラで新しい画像が撮影され、画像のエントリがメディアストアに追加されたときは常に、
Camera.ACTION_NEW_PICTURE
インテントをブロードキャストしなければなりません。 - [C-0-10] カメラで新しい動画が撮影され、画像のエントリがメディアストアに追加されたときは常に、
Camera.ACTION_NEW_VIDEO
インテントをブロードキャストしなければなりません。 - [C-0-11] サポートが終了した
android.hardware.Camera
API を介してアクセス可能なすべてのカメラが、android.hardware.camera2
API を介してもアクセス可能でなければなりません。 - [C-0-12] 顔の外見が変更されないことを保証しなければなりません。これには、
android.hardware.camera2
またはandroid.hardware.Camera
API のために、顔の形状、顔の肌の色、顔の肌の滑らかさを変更することが含まれますが、これらに限定されません。 - [C-SR-1] 複数の RGB カメラが近接していて同じ方向を向いているデバイスでは、物理サブデバイスとしてその方向を向いているすべての RGB カメラで構成された、機能
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
をリストする論理カメラデバイスをサポートすることが強く推奨されます。
カメラ API をサードパーティ アプリに提供する場合、デバイス実装は:
- [C-1-1]
android.hardware.camera2
API を使用してそのようなカメラ API を実装しなければなりません。 - ベンダータグや
android.hardware.camera2
API の拡張機能を提供しても構いません。
7.5.5. カメラの向き
デバイス実装に前面カメラまたは背面カメラがある場合、そのようなカメラは:
- [C-1-1] カメラの長辺が画面の長辺と一致するような向きにしなければなりません。つまり、デバイスが横向きで保持されている場合、カメラは横向きで画像をキャプチャしなければなりません。これは、デバイスの自然な向きに関係なく適用されます。つまり、横向き主体のデバイスと、縦向き主体のデバイスに適用されます。
以下の基準をすべて満たすデバイスは、上記の要件の対象外となります。
- デバイスは、折りたたみ式ディスプレイやヒンジ式ディスプレイなど、形状が変わる画面を実装している。
- デバイスの折りたたみ状態やヒンジ状態が変化すると、デバイスは、縦向きメインと横向きメインの画面の向きの間で切り替わる。
新しい要件の開始
- ユーザーが回転できないデバイス実装(自動車デバイスなど)。
新しい要件の終了
7.6. メモリとストレージ
7.6.1. 最小のメモリとストレージ
デバイス実装は:
- [C-0-1] アプリがデータファイルをダウンロードするために使用しても構わないダウンロード マネージャーを含まなければならず、サイズが少なくとも 100 MB である個々のファイルをデフォルトの「キャッシュ」場所にダウンロードできなければなりません。
7.6.2. アプリ共有ストレージ
デバイス実装は:
- [C-0-1] アプリによって共有されるストレージ(「共有外部ストレージ」、「アプリ共有ストレージ」ともいいます)、またはマウント先の Linux のパス「/sdcard」で共有されるストレージを提供しなければなりません。
- [C-0-2] ストレージが内部ストレージ コンポーネントに実装されているか、リムーバブル ストレージ メディア(SD カードスロットなど)に実装されているかにかかわらず、デフォルトでマウントされている(つまり「すぐに使える」)共有ストレージを使用して構成しなければなりません。
- [C-0-3] アプリ共有ストレージを Linux パス
sdcard
に直接マウントするか、sdcard
から実際のマウント ポイントへの Linux シンボリック リンクを含まなければなりません。 - [C-0-4] 次の状況を除き、API レベル 29 以降をターゲットとするすべてのアプリについて、デフォルトで対象範囲別ストレージを有効にしなければなりません。
- アプリがマニフェストで
android:requestLegacyExternalStorage="true"
をリクエストしているとき。
- アプリがマニフェストで
- [C-0-5] メディア ファイルが
MediaStore
を通じてアクセスされる場合、ファイルに格納されている GPS Exif タグなどの位置情報メタデータを削除しなければなりません(呼び出し元アプリがACCESS_MEDIA_LOCATION
権限を保持している場合を除きます)。
デバイス実装は、次のいずれかを使用して上記の要件を満たしても構いません。
- SD カードスロットなど、ユーザーがアクセス可能なリムーバブル ストレージ。
- Android オープンソース プロジェクト(AOSP)で実装されている内部(非リムーバブル)ストレージの一部。
上記の要件を満たすためにリムーバブル ストレージを使用する場合、デバイス実装は:
- [C-1-1] スロットにストレージ メディアが挿入されていないときにユーザーに警告する、トーストまたはポップアップのユーザー インターフェースを実装しなければなりません。
- [C-1-2] FAT フォーマットしたストレージ メディア(SD カードなど)を含むか、ストレージ メディアを別途購入する必要がある旨を箱または購入時に入手可能な他の資料に表示しなければなりません。
上記の要件を満たすために取り外し不可能なストレージの一部を使用する場合、デバイス実装は:
- 内部アプリ共有ストレージの AOSP 実装を使用すべきです。
- 保存容量をアプリの個人データと共有しても構いません。
USB ペリフェラル モードをサポートする USB ポートがある場合、デバイス実装は:
- [C-3-1] ホスト コンピュータからアプリ共有ストレージのデータにアクセスするためのメカニズムを提供しなければなりません。
- Android のメディア スキャナ サービスと
android.provider.MediaStore
を通じて、両方のストレージパスからのコンテンツを透過的に公開すべきです。 - USB マスストレージを使用しても構いませんが、メディア転送プロトコルを使用してこの要件を満たすべきです。
USB ペリフェラル モードの USB ポートがあり、メディア転送プロトコルをサポートする場合、デバイス実装は:
- リファレンス Android MTP ホスト Android File Transfer と互換性があるべきです。
- USB デバイスクラス 0x00 をレポートすべきです。
- USB インターフェース名「MTP」をレポートすべきです。
7.6.3. Adoptable Storage
テレビとは異なり、デバイスにモバイルとしての性質があることが想定される場合、デバイス実装は:
- [C-SR-1] 誤って接続解除するとデータの損失 / 破損が生じるおそれがあるため、Adoptable Storage を長期的に安定した場所に実装することが強く推奨されます。
リムーバブル ストレージ デバイスのポートが、バッテリー収納部やその他の保護カバー内など、長期的に安定した場所にある場合、デバイス実装は:
- [C-SR-2] Adoptable Storage を実装することが強く推奨されます。
7.7. USB
USB ポートがある場合、デバイス実装は:
- USB ペリフェラル モードをサポートすべきであり、USB ホストモードをサポートすべきです。
- USB でのデータ シグナリングの無効化をサポートすべきです。
7.7.1. USB ペリフェラル モード
デバイス実装に、ペリフェラル モードをサポートする USB ポートが含まれる場合:
- [C-1-1] ポートは、標準の Type-A または Type-C の USB ポートを持つ USB ホストに接続可能でなければなりません。
- [C-1-2]
android.os.Build.SERIAL
を通じて、USB 標準デバイス記述子でiSerialNumber
の正しい値をレポートしなければなりません。 - [C-1-3] Type-C 抵抗規格に従った 1.5 A と 3.0 A の充電器を検出しなければならず、Type-C USB をサポートする場合はアドバタイズメントの変更を検出しなければなりません。
- [C-SR-1] ポートは Micro-B、Micro-AB、または Type-C の USB フォーム ファクタを使用すべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
- [C-SR-2] ポートは、デバイスのポートが下向きのときディスプレイが正しく描画されるように、(自然な向きに合わせて)デバイスの底部に配置するか、すべてのアプリ(ホーム画面を含む)でソフトウェアの画面回転を可能にすべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
- [C-SR-3] USB Battery Charging Specification, Revision 1.2 で規定されているとおり、HS チャープ、トラフィックの際に 1.5 A の電流を流すためのサポートを実装すべきです。既存と新規の Android デバイスは、今後のプラットフォーム リリースにアップグレードできるよう、これらの要件を満たすことが強く推奨されます。
- [C-SR-4] 標準の USB Power Delivery の方法をサポートする充電器またはデバイスとの間に相互運用性の問題が生じるおそれがあるため、デフォルト レベルを超えて Vbus 電圧を変更する、またはシンク / ソースの役割を変更する独自の充電方法をサポートしないことが強く推奨されます。これは「強く推奨」となっていますが、今後の Android バージョンでは、標準的な Type-C 充電器との完全な相互運用性をサポートすることが、すべての Type-C デバイスで必須となる可能性があります。
- [C-SR-5] Type-C USB と USB ホストモードをサポートしている場合、データと電源の役割を入れ替えるために Power Delivery をサポートすることが強く推奨されます。
- 高電圧充電のために Power Delivery をサポートし、ディスプレイ出力のような代替モードをサポートすべきです。
- Android SDK ドキュメントに記載されているとおり、Android Open Accessory(AOA)の API と仕様を実装すべきです。
USB ポートが含まれ、AOA 仕様を実装する場合、デバイス実装は:
- [C-2-1] ハードウェア機能
android.hardware.usb.accessory
のサポートを宣言しなければなりません。 - [C-2-2] USB マスストレージ クラスは、USB マスストレージのインターフェース記述
iInterface
文字列の末尾に文字列「android」を含まなければなりません。
7.7.2. USB ホストモード
ホストモードをサポートする USB ポートが含まれる場合、デバイス実装は:
- [C-1-1] Android SDK に記載されているとおり Android USB ホスト API を実装しなければならず、ハードウェア機能
android.hardware.usb.host
のサポートを宣言しなければなりません。 - [C-1-2] 標準的な USB 周辺機器の接続のサポートを実装しなければなりません。つまり下記のいずれかでなければなりません。
- デバイス上に Type-C ポートを備えるか、デバイス上の専用ポートを標準的な USB Tape-C ポート(USB Type-C デバイス)に適合させるケーブルを同梱する。
- デバイス上に Type-A ポートを備えるか、デバイス上の専用ポートを標準的な USB Type-A ポートに適合させるケーブルを同梱する。
- デバイス上に Micro-AB ポートを備える(標準的な Type-A ポートに適合させるケーブルが付属すべきです)。
- [C-1-3] USB Type-A ポートまたは Micro-AB ポートから Type-C ポート(レセプタクル)に変換するアダプターを同梱してはなりません。
- [C-SR-1] Android SDK ドキュメントに記載されているとおり、USB オーディオ クラスを実装することが強く推奨されます。
- ホストモード時に接続されている USB 周辺機器の充電をサポートすべきです。USB Type-C コネクタの場合は、USB Type-C Cable and Connector Specification Revision 1.2 の「Termination Parameters」セクションで規定されているとおり 1.5 A 以上のソース電流をアドバタイズし、Micro-AB コネクタの場合は、USB Battery Charging specifications, revision 1.2 で規定されている充電ダウンストリーム ポート(CDP)の出力電流範囲を使用します。
- USB Type-C 規格を実装し、サポートすべきです。
ホストモードをサポートする USB ポートと、USB オーディオ クラスが含まれる場合、デバイス実装は:
- [C-2-1] USB HID クラスをサポートしなければなりません。
- [C-2-2] USB HID Usage Tables と Voice Command Usage Request で規定されている次の HID データ フィールドの検出と、下記の
KeyEvent
定数へのマッピングをサポートしなければなりません。- 使用状況ページ(0xC)使用状況 ID(0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- 使用状況ページ(0xC)使用状況 ID(0x0E9):
KEYCODE_VOLUME_UP
- 使用状況ページ(0xC)使用状況 ID(0x0EA):
KEYCODE_VOLUME_DOWN
- 使用状況ページ(0xC)使用状況 ID(0x0CF):
KEYCODE_VOICE_ASSIST
- 使用状況ページ(0xC)使用状況 ID(0x0CD):
ホストモードとストレージ アクセス フレームワーク(SAF)をサポートする USB ポートが含まれる場合、デバイス実装は:
- [C-3-1] リモート接続された MTP(メディア転送プロトコル)デバイスを認識し、そのコンテンツをインテント
ACTION_GET_CONTENT
、ACTION_OPEN_DOCUMENT
、ACTION_CREATE_DOCUMENT
を通じてアクセス可能にしなければなりません。
ホストモードと USB Type-C をサポートする USB ポートが含まれる場合、デバイス実装は:
- [C-4-1] USB Type-C 仕様(セクション 4.5.1.3.3)で規定されているとおり、デュアルロール ポート機能を実装しなければなりません。デュアルロール ポートについて、3.5 mm オーディオ ジャックが含まれるデバイスでは、USB シンク検出(ホストモード)をデフォルトでオフにしても構いませんが、ユーザーが有効にできるようにしなければなりません。
- [C-SR-2] DisplayPort をサポートすることが強く推奨され、USB SuperSpeed データ速度をサポートすべきであり、データと電源の役割を入れ替えるために Power Delivery をサポートすることが強く推奨されます。
- [C-SR-3] USB Type-C Cable and Connector Specification Revision 1.2 の「Appendix A」に記載されているオーディオ アダプター アクセサリ モードはサポートしないことが強く推奨されます。
- デバイス フォーム ファクタに最も適した Try.* モデルを実装すべきです。たとえば、ハンドヘルド デバイスは Try.SNK モデルを実装すべきです。
7.8. オーディオ
7.8.1. マイク
マイクが含まれる場合、デバイス実装は:
- [C-1-1]
android.hardware.microphone
機能定数をレポートしなければなりません。 - [C-1-2] セクション 5.4 の、録音の要件を満たさなければなりません。
- [C-1-3] セクション 5.6 の、オーディオ レイテンシの要件を満たさなければなりません。
- [C-SR-1] セクション 7.8.3 に記載されているとおり、近超音波の録音をサポートすることが強く推奨されます。
マイクを省略する場合、デバイス実装は:
- [C-2-1]
android.hardware.microphone
機能定数をレポートしてはなりません。 - [C-2-2] セクション 7 に従い、少なくとも NoOps として、録音 API を実装しなければなりません。
7.8.2. オーディオ出力
スピーカーが含まれるか、4 極 3.5 mm オーディオ ジャックや USB オーディオ クラスを使用する USB ホストモード ポートなど、オーディオ出力周辺機器用のオーディオ / マルチメディア出力ポートが含まれる場合、デバイス実装は:
- [C-1-1]
android.hardware.audio.output
機能定数をレポートしなければなりません。 - [C-1-2] セクション 5.5 の、オーディオの再生の要件を満たさなければなりません。
- [C-1-3] セクション 5.6 の、オーディオ レイテンシの要件を満たさなければなりません。
- [C-SR-1] セクション 7.8.3 に記載されているとおり、近超音波の再生をサポートすることが強く推奨されます。
スピーカーまたはオーディオ出力ポートが含まれない場合、デバイス実装は:
- [C-2-1]
android.hardware.audio.output
機能をレポートしてはなりません。 - [C-2-2] オーディオ出力関連の API を少なくとも NoOps として実装しなければなりません。
このセクションにおいて、「出力ポート」とは、3.5 mm オーディオ ジャック、HDMI、または USB オーディオ クラスの USB ホストモード ポートなどの物理インターフェースのことです。Bluetooth、Wi-Fi、またはモバイル ネットワークなど、無線ベースのプロトコルに基づくオーディオ出力のサポートは、「出力ポート」を含むとはみなされません。
7.8.2.1. アナログ オーディオ ポート
Android エコシステム全体で、3.5 mm オーディオ プラグを使用するヘッドセットや他のオーディオ アクセサリとの互換性を持たせるために、1 つ以上のアナログ オーディオ ポートが含まれる場合、デバイス実装は:
- [C-SR-1] 4 極 3.5 mm オーディオ ジャックとなるオーディオ ポートを少なくとも 1 つ含むことが強く推奨されます。
4 極 3.5 mm オーディオ ジャックが含まれる場合、デバイス実装は:
- [C-1-1] ステレオ ヘッドフォンと、マイク付きステレオ ヘッドフォンへのオーディオ再生をサポートしなければなりません。
- [C-1-2] CTIA ピン配列の TRRS オーディオ プラグをサポートしなければなりません。
- [C-1-3] オーディオ プラグのマイク極と接地極の間で、次に示す 3 つの等価インピーダンス範囲について、検出とキーコードへのマッピングをサポートしなければなりません。
- 70 オーム以下:
KEYCODE_HEADSETHOOK
- 210~290 オーム:
KEYCODE_VOLUME_UP
- 360~680 オーム:
KEYCODE_VOLUME_DOWN
- 70 オーム以下:
- [C-1-4] プラグ挿入時、
ACTION_HEADSET_PLUG
をトリガーしなければなりません(ただしプラグのすべての接点がジャックの該当セグメントに接した後に限ります)。 - [C-1-5] スピーカー インピーダンス 32 オームで、少なくとも 150 mV ± 10% の出力電圧で動作できなければなりません。
- [C-1-6] マイクのバイアス電圧が 1.8 V~2.9 V でなければなりません。
- [C-1-7] オーディオ プラグのマイク極と接地極の間で、次に示す等価インピーダンス範囲について、検出とキーコードへのマッピングをしなければなりません。
- 110~180 オーム:
KEYCODE_VOICE_ASSIST
- 110~180 オーム:
- [C-SR-2] OMTP ピン配列のオーディオ プラグをサポートすることが強く推奨されます。
- [C-SR-3] マイク付きステレオ ヘッドセットからの録音をサポートすることが強く推奨されます。
4 極 3.5 mm オーディオ ジャックがあり、マイクをサポートし、追加値でマイクを 1 に設定して android.intent.action.HEADSET_PLUG
をブロードキャストする場合、デバイス実装は:
- [C-2-1] 接続したオーディオ アクセサリ上のマイクの検出をサポートしなければなりません。
7.8.2.2. デジタル オーディオ ポート
デバイス固有の要件についてはセクション 2.2.1 をご覧ください。
7.8.3. 近超音波
近超音波とは、18.5 kHz から 20 kHz の帯域のことです。
デバイス実装は:
- 次のとおり、AudioManager.getProperty API を介して近超音波オーディオ機能のサポートを正しくレポートしなければなりません。
PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
が「true」の場合、音源 VOICE_RECOGNITION
と UNPROCESSED
で次の要件を満たさなければなりません。
- [C-1-1] 18.5 kHz から 20 kHz の帯域におけるマイクの平均電力感度は、2 kHz における感度より下に 15 dB 以内でなければなりません。
- [C-1-2] -26 dBFS の 19 kHz トーンについて、18.5 kHz から 20 kHz におけるマイクの非加重信号対雑音比は、50 dB 以上でなければなりません。
PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
が「true」の場合:
- [C-2-1] 18.5 kHz から 20 kHz におけるスピーカーの平均感度は、2 kHz における感度より下に 40 dB 以内でなければなりません。
7.8.4. 信号品位
デバイス実装は:
- ハンドヘルド デバイスの入力ストリームと出力ストリームの両方について、グリッチのないオーディオ信号パス(1 パスあたり 1 分間のテストにおいて測定されるグリッチがゼロ)を提供すべきです。OboeTester「自動グリッチテスト」を使用してテストします。
このテストでは、オーディオ ループバック ドングルを、3.5 mm ジャックに直接使用するか、USB-C - 3.5 mm アダプターと組み合わせて使用する必要があります。すべてのオーディオ出力ポートをテストすべきです。
OboeTester は現在 AAudio パスをサポートしているため、AAudio を使用して、グリッチについて次の組み合わせをテストすべきです。
Perf モード | 共有 | 出力サンプルレート | 入力チャンネル | 出力チャンネル |
---|---|---|---|---|
LOW_LATENCY | 限定 | 不明 | 1 | 2 |
LOW_LATENCY | 限定 | 不明 | 2 | 1 |
LOW_LATENCY | 共有 | 不明 | 1 | 2 |
LOW_LATENCY | 共有 | 不明 | 2 | 1 |
なし | 共有 | 48000 | 1 | 2 |
なし | 共有 | 48000 | 2 | 1 |
なし | 共有 | 44100 | 1 | 2 |
なし | 共有 | 44100 | 2 | 1 |
なし | 共有 | 16000 | 1 | 2 |
なし | 共有 | 16000 | 2 | 1 |
信頼性の高いストリームは、2,000 Hz 正弦波の信号対雑音比(SNR)と全高調波歪み(THD)について、次の基準を満たすべきです。
トランスデューサ | THD | SNR |
---|---|---|
メインの内蔵スピーカー(外部のリファレンス マイクを使用して測定) | < 3.0% | >= 50 dB |
メインの内蔵マイク(外部のリファレンス スピーカーを使用して測定) | < 3.0% | >= 50 dB |
内蔵 3.5 mm ジャック(ループバック アダプターを使用してテスト) | < 1% | >= 60 dB |
スマートフォン付属の USB アダプター(ループバック アダプターを使用してテスト) | < 1.0% | >= 60 dB |
7.9. バーチャル リアリティ
Android には、高品質なモバイル VR 体験を含む「バーチャル リアリティ」(VR)アプリをビルドするための API と機能があります。このセクションで詳述するように、デバイス実装はこれらの API と動作を適切に実装しなければなりません。
7.9.1. バーチャル リアリティ モード
Android は、VR モード(通知の立体画像レンダリングを処理し、ユーザーが VR アプリを注視している間は単眼式のシステム UI コンポーネントを無効にする機能)をサポートしています。
7.9.2. バーチャル リアリティ モード - 高パフォーマンス
VR モードをサポートする場合、デバイス実装は:
- [C-1-1] 物理コアが少なくとも 2 つなければなりません。
- [C-1-2]
android.hardware.vr.high_performance
機能を宣言しなければなりません。 - [C-1-3] パフォーマンス維持モードをサポートしなければなりません。
- [C-1-4] OpenGL ES 3.2 をサポートしなければなりません。
- [C-1-5]
android.hardware.vulkan.level
0 をサポートしなければなりません。 android.hardware.vulkan.level
1 以上をサポートすべきです。- [C-1-6]
EGL_KHR_mutable_render_buffer
、EGL_ANDROID_front_buffer_auto_refresh
、EGL_ANDROID_get_native_client_buffer
、EGL_KHR_fence_sync
、EGL_KHR_wait_sync
、EGL_IMG_context_priority
、EGL_EXT_protected_content
、EGL_EXT_image_gl_colorspace
を実装し、利用可能な EGL 拡張機能のリストで拡張機能を公開しなければなりません。 - [C-1-8]
GL_EXT_multisampled_render_to_texture2
、GL_OVR_multiview
、GL_OVR_multiview2
、GL_EXT_protected_textures
を実装し、利用可能な GL 拡張機能のリストで拡張機能を公開しなければなりません。 - [C-SR-1]
GL_EXT_external_buffer
、GL_EXT_EGL_image_array
、GL_OVR_multiview_multisampled_render_to_texture
を実装し、利用可能な GL 拡張機能のリストで拡張機能を公開することが強く推奨されます。 - [C-SR-2] Vulkan 1.1 をサポートすることが強く推奨されます。
- [C-SR-3]
VK_ANDROID_external_memory_android_hardware_buffer
、VK_GOOGLE_display_timing
、VK_KHR_shared_presentable_image
を実装し、利用可能な Vulkan 拡張機能のリストで公開することが強く推奨されます。 - [C-SR-4]
flags
にVK_QUEUE_GRAPHICS_BIT
とVK_QUEUE_COMPUTE_BIT
の両方が含まれqueueCount
が少なくとも 2 である Vulkan キュー ファミリーを、少なくとも 1 つ公開することが強く推奨されます。 - [C-1-7] GPU とディスプレイは、2 つのレンダリング コンテキストを使用して VR コンテンツを 60 fps で交互にレンダリングする場合に、対象が明らかに分かれて表示されることがないように、共有フロント バッファへのアクセスを同期できなければなりません。
- [C-1-9] NDK に記載されているとおり、
AHardwareBuffer
フラグAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
のサポートを実装しなければなりません。 - [C-1-10] 少なくとも
AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
の形式について、使用状況フラグAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
の任意の組み合わせによるAHardwareBuffer
のサポートを実装しなければなりません。 - [C-SR-5] 複数のレイヤ、C-1-10 で指定したフラグと形式による
AHardwareBuffer
の割り当てをサポートすることが強く推奨されます。 - [C-1-11] 30 fps で 3,840 x 2,160 以上の H.264 デコード、平均 40 Mbps への圧縮をサポートしなければなりません(30 fps-10 Mbps で 1,920 x 1,080 の 4 インスタンス、または 60 fps-20 Mbps で 1,920 x 1,080 の 2 インスタンスに相当)。
- [C-1-12] HEVC と VP9 をサポートしなければならず、平均 10 Mbps に圧縮されている場合に 30 fps で 1,920 x 1,080 以上のデコードができなければならず、30 fps-20 Mbps で 3,840 x 2,160 のデコードができるべきです(30 fps-5 Mbps で 1,920 x 1,080 の 4 インスタンスに相当)。
- [C-1-13]
HardwarePropertiesManager.getDeviceTemperatures
API をサポートし、皮膚温について正確な値を返さなければなりません。 - [C-1-14] 埋め込み画面がなければならず、その解像度は少なくとも 1,920 x 1,080 でなければなりません。
- [C-SR-6] ディスプレイ解像度が少なくとも 2,560 x 1,440 であることが強く推奨されます。
- [C-1-15] ディスプレイは、VR モード中に少なくとも 60 Hz で更新しなければなりません。
- [C-1-17] ディスプレイは、持続時間 5 ミリ秒以下の低持続モードをサポートしなければなりません(持続時間は、ピクセルが光を発している時間として定義されます)。
- [C-1-18] Bluetooth 4.2 と Bluetooth LE データ長拡張機能をサポートしなければなりません(セクション 7.4.3)。
- [C-1-19] 次のデフォルト センサータイプすべてについて、ダイレクト チャンネル タイプをサポートし、適切にレポートしなければなりません。
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] 上記すべてのダイレクト チャンネル タイプについて、
TYPE_HARDWARE_BUFFER
ダイレクト チャンネル タイプをサポートすることが強く推奨されます。 - [C-1-21] セクション 7.3.9 で規定されているとおり、
android.hardware.hifi_sensors
のジャイロスコープ、加速度計、磁力計関連の要件を満たさなければなりません。 - [C-SR-8]
android.hardware.sensor.hifi_sensors
機能をサポートすることが強く推奨されます。 - [C-1-22] エンドツーエンドの動作反映レイテンシが 28 ミリ秒以下でなければなりません。
- [C-SR-9] エンドツーエンドの動作反映レイテンシが 20 ミリ秒以下であることが強く推奨されます。
- [C-1-23] 第 1 フレーム比(黒から白への遷移後の最初のフレームにおけるピクセルの明るさと、定常状態における白ピクセルの明るさの比率)が、少なくとも 85% でなければなりません。
- [C-SR-10] 第 1 フレーム比が少なくとも 90% であることが強く推奨されます。
- フォアグラウンド アプリに専用のコアを提供しても構いません。また、トップ フォアグラウンド アプリ専用の CPU コア数を返すために
Process.getExclusiveCores
API をサポートしても構いません。
専用コアをサポートする場合、コアは:
- [C-2-1] 他のユーザー空間プロセスを実行できるようにしてはなりませんが(アプリが使用するデバイス ドライバを除く)、必要に応じて一部のカーネル プロセスを実行できるようにしても構いません。
7.10. ハプティクス
新しい要件の開始
手で持ったり、身につけたりすることを意図されたデバイスは、一般的なタッチ フィードバックだけでなく、着信音、アラーム、通知によって注意を引くなどの目的でアプリが利用できる汎用触覚アクチュエータを含むことができます。
そのような汎用触覚アクチュエータを含まない場合、デバイス実装は:
- [7.10/C]
Vibrator.hasVibrator()
に対して false を返さなければなりません。
そのような汎用触覚アクチュエータを 1 つ以上含む場合、デバイス実装は:
- [C-1-1]
Vibrator.hasVibrator()
に対して true を返さなければなりません。 - 偏心回転質量(ERM)触覚アクチュエータ(バイブレータ)を使用すべきではありません。
android.view.HapticFeedbackConstants
にあるクリア ハプティクスのためのパブリック定数(すなわちCLOCK_TICK
、CONTEXT_CLICK
、KEYBOARD_PRESS
、KEYBOARD_RELEASE
、KEYBOARD_TAP
、LONG_PRESS
、TEXT_HANDLE_MOVE
、VIRTUAL_KEY
、VIRTUAL_KEY_RELEASE
、CONFIRM
、REJECT
、GESTURE_START
、GESTURE_END
)をすべて実装すべきです。android.os.VibrationEffect
にあるクリア ハプティクスのためのパブリック定数(すなわちEFFECT_TICK
、EFFECT_CLICK
、EFFECT_HEAVY_CLICK
、EFFECT_DOUBLE_CLICK
)、android.os.VibrationEffect.Composition
にあるリッチ ハプティクスのための実現可能なパブリックPRIMITIVE_*
定数(すなわちCLICK
、TICK
、LOW_TICK
、QUICK_FALL
、QUICK_RISE
、SLOW_RISE
、SPIN
、THUD
)をすべて実装すべきです。これらのプリミティブの一部(LOW_TICK
やSPIN
など)は、バイブレータが比較的低い周波数をサポートできる場合にのみ実現可能です。- パブリック定数のマッピングのガイダンスに従って、
android.view.HapticFeedbackConstants
にあるパブリック定数を、対応する振幅関係とともに推奨されるandroid.os.VibrationEffect
定数にマッピングすべきです。 - これらのリンクされた触覚定数のマッピングを使用すべきです。
createOneShot()
API とcreateWaveform()
API の品質評価に従うべきです。- パブリック
android.os.Vibrator.hasAmplitudeControl()
API の結果にバイブレータの機能が正しく反映されていることを検証すべきです。 android.os.Vibrator.hasAmplitudeControl()
を実行して振幅スケーラビリティの機能を検証すべきです。
触覚定数マッピングに従う場合、デバイス実装は:
android.os.Vibrator.areAllEffectsSupported()
API とandroid.os.Vibrator.arePrimitivesSupported()
API を実行して実装ステータスを検証すべきです。- 触覚定数の品質評価を実施すべきです。
- 定数の実装ガイダンスに記載されているとおり、サポートされていないプリミティブのフォールバック構成を検証し、必要に応じて更新すべきです。
- こちらに記載されているとおり、失敗のリスクを軽減するためにフォールバック サポートを提供すべきです。
新しい要件の終了
デバイス固有の要件についてはセクション 2.2.1 をご覧ください。
7.11. メディア パフォーマンス クラス
デバイス実装のメディア パフォーマンス クラスは、android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
API から取得できます。メディア パフォーマンス クラスの要件は、R(バージョン 30)以降の Android バージョンごとに定義されています。特別な値 0 は、デバイスがメディア パフォーマンス クラスではないことを示します。
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してゼロ以外の値が返される場合、デバイス実装は:
[C-1-1] 少なくとも
android.os.Build.VERSION_CODES.R
の値を返さなければなりません。[C-1-2] ハンドヘルド デバイス実装でなければなりません。
[C-1-3] セクション 2.2.7 に記載されている「メディア パフォーマンス クラス」のすべての要件を満たさなければなりません。
言い換えれば、Android T のメディア パフォーマンス クラスは、バージョン T、S、R のハンドヘルド デバイス用にのみ定義されています。
デバイス固有の要件についてはセクション 2.2.7 をご覧ください。
8. パフォーマンスと電力
パフォーマンスと電力に関する最低基準は、ユーザー エクスペリエンスにとって重要であり、アプリの開発時にデベロッパーが設定するであろうベースラインの前提条件に影響を与えます。
8.1. ユーザー エクスペリエンスの一貫性
アプリとゲームについて、一貫したフレームレートと応答時間を確保するための一定の最小要件があれば、滑らかなユーザー インターフェースをエンドユーザーに提供できます。デバイス実装には、デバイスタイプに応じて、セクション 2 に記載されているとおり、ユーザー インターフェース レイテンシとタスク切換えについての測定可能な要件があっても構いません。
8.2. ファイル I/O アクセスのパフォーマンス
アプリの個人データ ストレージ(/data
パーティション)における一貫したファイル アクセス パフォーマンスについて共通のベースラインを提供することで、アプリ デベロッパーは、ソフトウェア設計に役立つ適切な期待値を設定できます。デバイス実装には、デバイスタイプに応じて、次の読み書き操作についてセクション 2 に記載されている特定の要件があっても構いません。
- シーケンシャル書き込みパフォーマンス。10 MB の書き込みバッファを使用し、256 MB のファイルを書き込むことで測定。
- ランダム書き込みパフォーマンス。4 KB の書き込みバッファを使用し、256 MB のファイルを書き込むことで測定。
- シーケンシャル読み取りパフォーマンス。10 MB の書き込みバッファを使用し、256 MB のファイルを読み取ることで測定。
- ランダム読み取りパフォーマンス。4 KB の書き込みバッファを使用し、256 MB のファイルを読み取ることで測定。
8.3. 省電力モード
AOSP に含まれるデバイス電源管理を改善する機能(アプリ スタンバイ バケット、Doze など)を含むか、制限付きアプリ スタンバイ バケットより強い制限を適用する機能を拡張する場合、デバイス実装は:
- [C-1-1] トリガー、メンテナンス、ウェイクアップのアルゴリズムについて、またアプリ スタンバイと Doze 省電力モードのシステム全般設定または DeviceConfig の使用について、AOSP 実装から逸脱してはなりません。
- [C-1-2] アプリ スタンバイのバケットごとにアプリのジョブ、アラーム、ネットワークのスロットリングを管理するための全般設定または DeviceConfig の使用について、AOSP 実装から逸脱してはなりません。
- [C-1-3] アプリ スタンバイに使用するアプリ スタンバイ バケットの数について、AOSP 実装から逸脱してはなりません。
- [C-1-4] 電源管理に記載されているとおり、アプリ スタンバイ バケットと Doze を実装しなければなりません。
- [C-1-5] デバイスが省電力モードのとき、
PowerManager.isPowerSaveMode()
についてtrue
を返さなければなりません。 - [C-1-6] アプリ スタンバイと Doze 省電力モードまたはバッテリー最適化から除外されたすべてのアプリを表示するユーザー アフォーダンスを提供しなければなりません。また、ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS インテントを実装して、アプリでバッテリー最適化を無視できるようにするようユーザーに求めなければなりません。
- [C-SR-1] バッテリー セーバー機能を有効、無効にするユーザー アフォーダンスを提供することが強く推奨されます。
- [C-SR-2] アプリ スタンバイと Doze 省電力モードから除外されたすべてのアプリを表示するユーザー アフォーダンスを提供することが強く推奨されます。
デバイス実装が AOSP に含まれる電源管理機能を拡張し、その拡張機能が低頻度アプリ スタンバイ バケットより厳しい制限を適用する場合は、セクション 3.5.1 をご覧ください。
省電力モードに加えて、Android デバイス実装は、Advanced Configuration and Power Interface(ACPI)で規定された 4 つのスリープ電力状態のいずれか、またはすべてを実装しても構いません。
ACPI で規定されている S4 電力状態を実装する場合、デバイス実装は:
- [C-1-1] ユーザーが明示的な操作(物理的にデバイスの一部である蓋を閉じる、車両またはテレビの電源をオフにするなど)を行ってデバイスを非アクティブ状態にした後、かつ、ユーザーがデバイスを再度アクティブにする(蓋を開く、車両またはテレビの電源を再度オンにするなど)前にのみ、この状態に入らなければなりません。
ACPI で規定されている S3 電力状態を実装する場合、デバイス実装は:
[C-2-1] 上記の C-1-1 を満たさなければなりません。または、サードパーティ アプリがシステム リソース(画面、CPU など)を必要としない場合にのみ、S3 状態に入らなければなりません。
逆に、この SDK に記載されているとおり、サードパーティ アプリがシステム リソースを必要とする場合は、S3 状態を終了しなければなりません。
たとえば、サードパーティ アプリが
FLAG_KEEP_SCREEN_ON
を通じて画面をオンにし続けることをリクエストしているか、PARTIAL_WAKE_LOCK
を通じて CPU を動作させ続けることをリクエストしているとき、C-1-1 に記載されているとおり、ユーザーがデバイスを非アクティブ状態にする明示的な操作を行っていない限り、デバイスは S3 状態に入ってはなりません。逆に、JobScheduler を通じてサードパーティ アプリが実装するタスクがトリガーされた時点、または Firebase Cloud Messaging がサードパーティ アプリに配信された時点で、ユーザーがデバイスを非アクティブ状態にしていない限り、デバイスは S3 状態を終了しなければなりません。これらは包括的な例ではなく、AOSP は、この状態からの復帰をトリガーする広範な復帰シグナルを実装しています。
8.4. 消費電力の算出
より正確に消費電力を算出しレポートすることで、アプリ デベロッパーに対し、アプリの電力使用パターンを最適化するためのインセンティブとツールの両方を提供します。
デバイス実装は:
- [C-SR-1] Android オープンソース プロジェクトのサイトに記載されているとおり、ハードウェア コンポーネントごとの電流消費値と、時間の経過に伴ってコンポーネントによって発生するおおよそのバッテリー消耗量を定義する、コンポーネントごとの電力プロファイルを提供することが強く推奨されます。
- [C-SR-2] すべての消費電力値をミリアンペア時(mAh)単位でレポートすることが強く推奨されます。
- [C-SR-3] プロセスの UID ごとの CPU 電力消費をレポートすることが強く推奨されます。Android オープンソース プロジェクトは、
uid_cputime
カーネル モジュール実装を通じて要件を満たしています。 - [C-SR-4] この電力使用量を、
adb shell dumpsys batterystats
シェルコマンドを介してアプリ デベロッパーが利用できるようにすることが強く推奨されます。 - ハードウェア コンポーネントの電力使用量をアプリに帰属させられない場合、ハードウェア コンポーネント自体に帰属されるべきです。
8.5. 一貫したパフォーマンス
高パフォーマンスで長時間実行されるアプリでは、バックグラウンドで実行されている他のアプリや、温度制限による CPU スロットリングが原因となって、パフォーマンスが大きく変動することがあります。Android にはプログラマティック インターフェースがあるため、デバイスで使用可能な場合、トップ フォアグラウンド アプリは、このような変動に対処するためにリソースの割り当てを最適化するようシステムにリクエストできます。
デバイス実装は:
[C-0-1]
PowerManager.isSustainedPerformanceModeSupported()
API メソッドを通じてパフォーマンス維持モードのサポートを正確にレポートしなければなりません。パフォーマンス維持モードをサポートすべきです。
パフォーマンス維持モードのサポートをレポートする場合、デバイス実装は:
- [C-1-1] トップ フォアグラウンド アプリがリクエストした場合、少なくとも 30 分間は一貫したレベルのパフォーマンスを提供しなければなりません。
- [C-1-2]
Window.setSustainedPerformanceMode()
API と他の関連 API を使用しなければなりません。
複数の CPU コアが含まれる場合、デバイス実装は:
- トップ フォアグラウンド アプリが予約できる専用コアを少なくとも 1 つ提供すべきです。
トップ フォアグラウンド アプリ用に専用コアを 1 つ予約することをサポートする場合、デバイス実装は:
- [C-2-1]
Process.getExclusiveCores()
API メソッドを通じて、トップ フォアグラウンド アプリが予約できる専用コアの ID 番号をレポー