アンドロイド14
2023 年 11 月 20 日
2. デバイスの種類
リビジョンを参照
ハンドヘルド デバイスの実装が 64 ビット ABI (32 ビット ABI の有無にかかわらず) のサポートを宣言している場合:
リビジョンを参照
- [ 7.5 /H-1-13] 複数の RGB 背面カメラがある場合、プライマリ背面カメラの
LOGICAL_MULTI_CAMERA
機能をサポートしなければなりません。
- [ 7.5 /H-1-13] 複数の RGB 背面カメラがある場合、プライマリ背面カメラの
リビジョンを参照
[ 5.8 /T-0-1] HDMI 出力モードを、外部ディスプレイの 50 Hz または 60 Hz リフレッシュ レートで動作する、選択した SDR または HDR フォーマットの最高解像度に設定しなければなりません。
HDMI 出力モードを設定して、50 Hz または 60 Hz のリフレッシュ レートでサポートできる最大解像度を選択する必要があります。
リビジョンを参照
- [9/W-0-1]
android.hardware.security.model.compatible feature
を宣言しなければなりません。
- [9/W-0-1]
6. 開発者ツールとオプションの互換性
リビジョンを参照
- [C-0-12]
LMK_KILL_OCCURRED_FIELD_NUMBER
アトムを
リビジョンを参照
- [C-0-13] 表示するにはシェル コマンド
dumpsys gpu --gpuwork
を実装しなければなりません
- [C-0-12]
9. セキュリティモデルの互換性
リビジョンを参照
SELinux をサポートできる Linux カーネルを使用するデバイス実装は、次のことを行います。
リビジョンを参照
Linux 以外のカーネルまたは SELinux なしの Linux を使用する場合、デバイス実装は次のようになります。
2023 年 10 月 4 日
2. デバイスの種類
リビジョンを参照
Android デバイス実装は、次の基準をすべて満たす場合、ハンドヘルドとして分類されます。
- 物理的な対角画面サイズが4 インチ
から 3.3 インチ (API レベル 29 以前で出荷されたデバイス実装の場合は 2.5 インチ) ~8 インチの範囲です。
新しい要件を開始する
- タッチスクリーン入力インターフェイスを備えています。
- 物理的な対角画面サイズが4 インチ
リビジョンを参照
ハンドヘルドデバイスの実装:
- [ 7.1 .1.1/H-0-1]
このドキュメントに記載されているすべての要件を満たす Android 互換ディスプレイが少なくとも 1 台必要です。短辺が 2.2 インチ以上、長辺が 3.4 インチ以上のディスプレイ。
ハンドヘルド デバイスの実装がソフトウェア画面の回転をサポートしている場合、次のことが行われます。
- [ 7.1 .1.1/H-1-1]* サードパーティのアプリケーションで利用できる論理画面は、短辺が少なくとも 2 インチ、長辺が 2.7 インチでなければなりません。 Android API レベル 29 以前で出荷されたデバイスは、この要件から免除されてもよい(MAY)。
ハンドヘルド デバイスの実装がソフトウェア画面の回転をサポートしていない場合、次のようになります。
- [ 7.1 .1.1/H-2-1]* サードパーティのアプリケーションで使用できる論理画面は、短辺が少なくとも 2.7 インチでなければなりません。 Android API レベル 29 以前で出荷されたデバイスは、この要件から免除されてもよい(MAY)。
新しい要件を開始する
ハンドヘルド デバイス実装が
android.hardware.audio.output
およびandroid.hardware.microphone
を宣言する場合、次のようになります。[ 5.6 /H-1-1] 次のデータ パス上で、5 回の測定で平均連続往復遅延が300ミリ秒以下、平均絶対偏差が30 ミリ秒未満でなければなりません:「スピーカーからマイク」、3.5 mmループバック アダプター (サポートされている場合)、USB ループバック (サポートされている場合)。
[ 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、CONFI) を実装すべきです。 RM、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()およびcreateWaveform() API の品質評価に従うべきです。
- [ 7.10 /H]* パブリックandroid.os.Vibrator.hasAmplitudeControl() API の結果がバイブレーターの機能を正しく反映していることを検証する必要があります。
- [ 7.10 /H]* アクチュエータの配置は、デバイスが通常手で保持されたり触れたりする場所の近くに配置する必要があります。
ハンドヘルド デバイス実装に少なくとも 1 つの汎用7.10リニア共振アクチュエータが含まれる場合、次のことが行われます。
- [ 7.10 /H] アクチュエータの配置は、デバイスが通常手で保持されたり触れたりする場所の近くに配置すべきです。
- [ 7.10 /H] 触覚アクチュエータをデバイスの自然な
縦方向の X 軸 (左右) に移動すべきです。
ハンドヘルド デバイスの実装に X 軸リニア共振アクチュエータ (LRA) である汎用触覚アクチュエータが搭載されている場合、次のことが行われます。
- [ 7.10 /H] X 軸 LRA の共振周波数は 200 Hz 未満であるべきです。
- [ 7.1 .1.1/H-0-1]
リビジョンを参照
ハンドヘルド デバイスの実装は、次のビデオ エンコード形式をサポートし、サードパーティ アプリケーションで使用できるようにする必要があります。
- [ 5.2 /H-0-3] AV1
ハンドヘルド デバイスの実装は、次のビデオ デコード形式をサポートし、サードパーティ アプリケーションで使用できるようにしなければなりません。
- [ 5.3 /H-0-6] AV1
リビジョンを参照
セクション7.2.3で詳述されているように、最近の機能ナビゲーション キーを含むデバイス実装がインターフェイスを変更する場合、デバイス実装は次のようになります。
- [ 3.8 .3/H-1-1] 画面の固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。
ハンドヘルド デバイス実装に
ControlsProviderService
およびControl
API のサポートが含まれており、サードパーティ アプリケーションによるデバイス コントロールの公開が許可されている場合、ハンドヘルド デバイス実装は次のようになります。- [ 3.8 .16/H-1-6] デバイス実装は、次のようにユーザー アフォーダンスを正確にレンダリングしなければなりません (MUST)。
- デバイスが
config_supportsMultiWindow=true
設定しており、アプリが有効なアクティビティ (API で定義されている) の ComponentName を含むメタデータMETA_DATA_PANEL_ACTIVITY
をControlsProviderService
宣言で宣言している場合、アプリはそのアクティビティをこのユーザー アフォーダンスに埋め込む必要があります。 - アプリがメタデータ
META_DATA_PANEL_ACTIVITY
を宣言していない場合は、ControlsProviderService
API によって提供される指定されたフィールドと、コントロールAPI によって提供される指定されたフィールドをレンダリングしなければなりません。
- デバイスが
- [ 3.8 .16/H-1-7] アプリがメタデータ
META_DATA_PANEL_ACTIVITY
を宣言する場合、埋め込みアクティビティの起動時にEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
を使用して [3.8.16/H-1-5] で定義された設定の値を渡さなければなりません。
リビジョンを参照
ハンドヘルドデバイスの実装:
- [ 8.5 /H-0-1] SDK ドキュメントで説明されているように、アクティブなフォアグラウンド サービスまたはユーザーが開始したジョブのいずれかを備えたすべてのアプリを表示するには、
設定メニューでユーザー アフォーダンスを提供しなければなりません ( SDK ドキュメントで説明されているように、これらのサービスが開始されてからの各サービスの継続時間を含む) 。フォアグラウンド サービスまたはユーザーが開始したジョブを実行しているアプリを停止する機能。SDK ドキュメントで説明されているように、フォアグラウンド サービスを実行しているアプリを停止し、アクティブなフォアグラウンド サービスを持つすべてのアプリと、開始されてからのこれらの各サービスの継続時間を表示する機能を備えています。- 一部のアプリは、 SDK ドキュメントに記載されているようなユーザー アフォーダンスでの停止やリスト表示が免除される場合があります (MAY)。
- [ 8.5 /H-0-1] SDK ドキュメントで説明されているように、アクティブなフォアグラウンド サービスまたはユーザーが開始したジョブのいずれかを備えたすべてのアプリを表示するには、
- [ 8.5 /H-0-2] フォアグラウンド サービスまたはユーザーが開始したジョブを実行しているアプリを停止するためのユーザー アフォーダンスを提供しなければなりません。
リビジョンを参照
デバイス実装がandroid.hardware.telephony
のサポートを宣言する場合、デバイス実装は次のことを行います。
- [ 9.5 /H-1-1]
UserManager.isHeadlessSystemUserMode
をtrue
に設定してはなりません。
デバイス実装に安全なロック画面があり、 TrustAgentService
システム API を実装する 1 つ以上の信頼エージェントが含まれる場合、デバイス実装は次のようになります。
- [ 9.11.1 /H-1-1] 72 時間に 1 回よりも頻繁に、推奨される主要な認証方法 (例: PIN、パターン、パスワード) の 1 つをユーザーに要求しなければなりません。
ハンドヘルド デバイス実装がUserManager.isHeadlessSystemUserMode
をtrue
に設定すると、
ハンドヘルド デバイスの実装が、システム API HotwordDetectionService
またはマイク アクセス表示なしのホットワード検出の別のメカニズムをサポートしている場合、次のようになります。
- [9.8/H-1-1] ホットワード検出サービスが System、
ContentCaptureService
、またはSpeechRecognizer#createOnDeviceSpeechRecognizer()
によって作成されたオンデバイス音声認識サービスにのみデータを送信できることを確認しなければなりません。 - [9.8/H-1-6] 成功したホットワード結果ごとに、100 バイトを超えるデータ(オーディオ ストリームを除く)がホットワード検出サービスから送信されることを許可してはなりません。
- [9.8/H-1-15] 成功したホットワード結果で提供されるオーディオ ストリームが、ホットワード検出サービスから音声対話サービスへ一方向に送信されることを保証しなければなりません。
デバイス実装に、システム API HotwordDetectionService
を使用するアプリケーション、またはマイクの使用状況を示さないホットワード検出の同様のメカニズムが含まれている場合、アプリケーションは次のようになります。
- [9.8/H-2-3]
ContentCaptureService
またはデバイス上の音声認識サービス。
ハンドヘルド デバイスの実装がシステム API VisualQueryDetectionService
またはマイクやカメラのアクセス表示なしのクエリ検出の別のメカニズムをサポートしている場合、ハンドヘルド デバイスの実装は次のようになります。
- [9.8/H-3-1] クエリ検出サービスがシステム、
ContentCaptureService
、またはオンデバイス音声認識サービス (SpeechRecognizer#createOnDeviceSpeechRecognizer()
によって作成される) にのみデータを送信できることを確認しなければなりません。 - [9.8/H-3-2]
VisualQueryDetectionService
またはオンデバイスの音声認識サービスを除き、ContentCaptureService
から音声またはビデオ情報が送信されることを許可してはなりません。 - [9.8/H-3-3] デバイスがデジタル アシスタント アプリケーションに関与するユーザーの意図を検出したとき (たとえば、カメラ経由でユーザーの存在を検出することによって)、システム UI にユーザー通知を表示しなければなりません。
- [9.8/H-3-4] ユーザークエリが検出された直後に、マイクインジケーターを表示し、検出されたユーザークエリを UI に表示しなければなりません。
- [9.8/H-3-5] ユーザーがインストール可能なアプリケーションに視覚的なクエリ検出サービスを提供させてはなりません。
リビジョンを参照
ハンドヘルド デバイス実装が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] 1080p 解像度 @ 30 fps で 3 つのセッションを同時に実行する任意のコーデックの組み合わせで、8 ビット (SDR) ハードウェア ビデオ デコーダ セッション (AVC、HEVC、VP9、AV1 以降) の 6 つのインスタンスをサポートしなければなりません。 AV1 を除く、4k 解像度 @ 30fps で 3 つのセッション。 AV1 コーデックは 1080p 解像度をサポートすることのみが必要ですが、1080p30fps で 6 つのインスタンスをサポートすることも必要です。
- [5.1/H-1-3]
CodecCapabilities.getMaxSupportedInstances()
メソッドとVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア ビデオ エンコーダ セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-4] 1080p 解像度 @ 30 fps で 4 つのセッションを同時に実行する、任意のコーデックの組み合わせで 8 ビット (SDR) ハードウェア ビデオ エンコーダ セッション (AVC、HEVC、VP9、AV1 以降) の 6 つのインスタンスをサポートしなければなりません。 AV1 を除く、4k 解像度 @ 30fps で 2 つのセッション。 AV1 コーデックは 1080p 解像度をサポートすることのみが必要ですが、1080p30fps で 6 つのインスタンスをサポートすることも必要です。
- [5.1/H-1-5]
CodecCapabilities.getMaxSupportedInstances()
およびVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア ビデオ エンコーダおよびデコーダ セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-6] 4K で 3 つのセッションを同時に実行する任意のコーデックの組み合わせで、8 ビット (SDR) ハードウェア ビデオ デコーダーおよびハードウェア ビデオ エンコーダー セッション (AVC、HEVC、VP9、AV1 以降) の 6 つのインスタンスをサポートしなければなりません。 @30fps 解像度 (AV1 を除く)、そのうち最大 2 つはエンコーダー セッション、3 つは 1080p 解像度のセッションです。 AV1 コーデックは 1080p 解像度をサポートすることのみが必要ですが、1080p30fps で 6 つのインスタンスをサポートすることも必要です。
- [5.1/H-1-19] 4K@30fps 解像度で同時に実行される任意のコーデックの組み合わせで、10 ビット (HDR) ハードウェア ビデオ デコーダーとハードウェア ビデオ エンコーダー セッション (AVC、HEVC、VP9、AV1 以降) の 3 つのインスタンスをサポートしなければなりません。 (AV1 を除く) そのうち最大 1 はエンコーダ セッションであり、GL サーフェスを介して RGBA_1010102 入力形式で構成できます。 GL サーフェスからエンコードする場合、エンコーダーによる HDR メタデータの生成は必要ありません。 AV1 コーデック セッションでは、この要件が 4K を必要とする場合でも、1080p 解像度をサポートすることのみが必要です。
- [5.1/H-1-7] 負荷がかかっている場合、すべてのハードウェア ビデオ エンコーダの 1080p 以下のビデオ エンコード セッションのコーデック初期化レイテンシが 40 ミリ秒以下でなければなりません。ここでのロードは、1080p オーディオビデオ記録の初期化とともにハードウェア ビデオ コーデックを使用した、同時の 1080p から 720p ビデオのみのトランスコーディング セッションとして定義されます。ドルビー ビジョン コーデックの場合、コーデックの初期化遅延は 50 ミリ秒以下でなければなりません。
- [5.1/H-1-8] 負荷がかかっている場合、すべてのオーディオ エンコーダの 128 kbps 以下のビットレートのオーディオ エンコード セッションでは、コーデックの初期化レイテンシが 30 ミリ秒以下でなければなりません。ここでのロードは、1080p オーディオビデオ記録の初期化とともにハードウェア ビデオ コーデックを使用した、同時の 1080p から 720p ビデオのみのトランスコーディング セッションとして定義されます。
- [5.1/H-1-9] 8 つのビデオ デコーダー セッション (AVC、HEVC、VP9、AV1 以降) の 2 つのインスタンスを、4k 解像度 @ 30 fps (AV1 を除く) で同時に実行するコーデックの組み合わせでサポートしなければなりません (MUST)。ビット (SDR) および 10 ビット HDR コンテンツ。 AV1 コーデック セッションでは、この要件が 4K を必要とする場合でも、1080p 解像度をサポートすることのみが必要です。
- [5.1/H-1-10] 任意のコーデックで、非セキュア ハードウェア ビデオ デコーダ セッションの 3 インスタンスと、セキュア ハードウェア ビデオ デコーダ セッションの 1 インスタンス (合計 4 インスタンス) (AVC、HEVC、VP9、AV1 以降) をサポートしなければなりません。 4K 解像度 @ 30 fps (AV1 を除く) で 3 つのセッションを同時に実行する組み合わせ。これには、1 つのセキュア デコーダー セッションと 1080p 解像度 @ 30 fps の 1 nn セキュア セッションが含まれます。10 ビット HDR では最大 2 つのセッションが可能です。 AV1 コーデック セッションでは、この要件が 4K を必要とする場合でも、1080p 解像度をサポートすることのみが必要です。
- [5.1/H-1-11] デバイス上のすべてのハードウェア AVC、HEVC、VP9、または AV1 デコーダのセキュア デコーダをサポートしなければなりません。
- [5.1/H-1-12] 負荷がかかっている場合、すべてのハードウェア ビデオ デコーダの 1080p 以下のビデオ デコード セッションのコーデック初期化レイテンシが 40 ミリ秒以下でなければなりません。ここでのロードは、1080p オーディオビデオ再生の初期化とともにハードウェア ビデオ コーデックを使用した、同時の 1080p から 720p ビデオのみのトランスコーディング セッションとして定義されます。ドルビー ビジョン コーデックの場合、コーデックの初期化遅延は 50 ミリ秒以下でなければなりません。
- [5.1/H-1-13] 負荷がかかっている場合、すべてのオーディオ デコーダの 128 kbps 以下のビットレートのオーディオ デコード セッションでは、コーデックの初期化レイテンシが 30 ミリ秒以下でなければなりません。ここでのロードは、1080p オーディオビデオ再生の初期化とともにハードウェア ビデオ コーデックを使用した、同時の 1080p から 720p ビデオのみのトランスコーディング セッションとして定義されます。
- [5.1/H-1-14] AV1 ハードウェア デコーダー Main 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 Verifier のタップツートーン テストを使用して、タップツートーンの遅延が 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 |
1 秒あたりの復号化フレーム数 | 60fps |
- [5.1/H-1-17] AVIF ベースライン プロファイルをサポートするハードウェア イメージ デコーダが少なくとも 1 つ必要です。
- [5.1/H-1-18] 30fps および 1Mbps で最大 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) ハードウェア コンポーザー (HWC) に少なくとも 6 つのハードウェア オーバーレイがなければならず、そのうちの少なくとも 2 つは 10 ビット ビデオ コンテンツを表示できます。
ハンドヘルド デバイス実装がandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してandroid.os.Build.VERSION_CODES.U
を返し、ハードウェア AVC または HEVC エンコーダーのサポートが含まれている場合、次のようになります。
- [5.2/H-2-1] 今後のドキュメントで定義されるように、ハードウェア AVC および HEVC コーデックのビデオ エンコーダのレート歪み曲線によって定義される最低品質目標を満たさなければなりません。
リビジョンを参照
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してandroid.os.Build.VERSION_CODES.U
を返す場合、次のようになります。- [ 7.5 /H-1-1] 4k@30fps でのビデオ キャプチャをサポートする、解像度が少なくとも 12 メガピクセルのプライマリ背面カメラを備えていなければなりません。プライマリ背面カメラは、カメラ ID が最も小さい背面カメラです。
- [ 7.5 /H-1-2] 少なくとも 6 メガピクセルの解像度を持つプライマリ前面カメラを備え、1080p@30fps でのビデオ キャプチャをサポートしなければなりません。プライマリ前面カメラは、カメラ ID が最も小さい前面カメラです。
- [ 7.5 /H-1-3] 両方のプライマリ カメラで、
android.info.supportedHardwareLevel
プロパティを FULL 以上としてサポートしなければなりません。 - [ 7.5 /H-1-4] 両方のプライマリ カメラで
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
をサポートしなければなりません。 - [ 7.5 /H-1-5] 両方のプライマリ カメラの ITS 照明条件 (3000K) で CTS カメラ PerformanceTest で測定した、1080p 解像度のカメラ 2 JPEG キャプチャ レイテンシが 1000
900ミリ秒未満でなければなりません。 - [ 7.5 /H-1-6] 両方のプライマリ カメラの ITS 照明条件 (3000K) での CTS カメラ パフォーマンス テストで測定したカメラ 2 の起動遅延 (カメラを開いて最初のプレビュー フレームまで) が 500 ミリ秒未満でなければなりません。
- [ 7.5 /H-1-8] プライマリ バック カメラの
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
およびandroid.graphics.ImageFormat.RAW_SENSOR
をサポートしなければなりません。 - [ 7.5 /H-1-9] 720p または 1080p @ 240fps をサポートする背面プライマリ カメラが必要です。
- [ 7.5 /H-1-10] 同じ方向を向いたウルトラワイド RGB カメラがある場合、プライマリ カメラの最小 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 拡張機能の両方を介して、
Bokeh &Night モード拡張機能をサポートしなければなりません。 - [ 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 ) をサポートしなければなりません。
リビジョンを参照
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] 平均 1000 nit 以上をサポートする HDR ディスプレイが必要です。
- [7.6.1/H-2-1] 少なくとも 8 GB の物理メモリが必要です。
リビジョンを参照
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してandroid.os.Build.VERSION_CODES.U
を返す場合、次のようになります。- [8.2/H-1-1] 少なくとも 150 MB/秒のシーケンシャル書き込みパフォーマンスを保証しなければなりません。
- [8.2/H-1-2] 少なくとも 10 MB/秒のランダム書き込みパフォーマンスを保証しなければなりません。
- [8.2/H-1-3] 少なくとも 250 MB/s のシーケンシャル読み取りパフォーマンスを保証しなければなりません。
- [8.2/H-1-4] 少なくとも 100 MB/s のランダム読み取りパフォーマンスを保証しなければなりません。
- [8.2/H-1-5] 少なくとも 50 MB/s の 2x 読み取りおよび 1x 書き込みパフォーマンスによる並列シーケンシャル読み取りおよび書き込みパフォーマンスを保証しなければなりません。
リビジョンを参照
テレビ デバイスの実装は、次のビデオ エンコード形式をサポートし、サードパーティ アプリケーションで使用できるようにする必要があります。
- [ 5.2 /T-0-3] AV1
テレビ デバイスの実装は、次のビデオ デコード形式をサポートし、サードパーティ アプリケーションで使用できるようにしなければなりません。
- [ 5.3.2 /T-0-7] AV1
リビジョンを参照
デバイス実装に安全なロック画面があり、 TrustAgentService
システム API を実装する 1 つ以上の信頼エージェントが含まれる場合、デバイス実装は次のようになります。
- [ 9.11.1 /W-1-1] 72 時間に 1 回よりも頻繁に、推奨される主要な認証方法 (例: PIN、パターン、パスワード) の 1 つをユーザーに要求しなければなりません。
リビジョンを参照
デバイス実装に AM/FM ブロードキャスト ラジオのサポートが含まれており、その機能を任意のアプリケーションに公開する場合、デバイス実装は次のようになります。
- [ 7.4
.10/A-0-1]FEATURE_BROADCAST_RADIO
のサポートを宣言しなければなりません。
エクステリア ビュー カメラは、リアビュー カメラと同様に、デバイス実装の外側のシーンを画像化するカメラです。
自動車デバイスの実装:
- 1 つ以上の外部ビュー カメラを含めるべきです。
自動車デバイスの実装に外部ビュー カメラが含まれる場合、そのようなカメラについては、次のことが行われます。
- [ 7.5 /A-1-1] カメラコア要件に準拠しない限り、 Android カメラ 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で説明されている外部カメラをサポートしてもよい (MAY)。
- セクション 7.5.1で説明されているように、背面カメラで利用できる機能 (オートフォーカスなど) を含めてもよい (MAY)。
後向きカメラとは、車両の任意の場所に配置でき、車両キャビンの外側を向いている世界向きのカメラを意味します。つまり、リアビューカメラのように、車体の反対側のシーンを画像化します。
前面カメラとは、車両の任意の場所に配置でき、車両室内に面するユーザーに面したカメラを意味します。つまり、ビデオ会議や同様のアプリケーションなどのユーザーの画像です。
自動車デバイスの実装:
- [7.5/A-SR-1] 1 つ以上の世界に向けたカメラを含めることが強く推奨されます。
- 1 つ以上のユーザー側カメラを含めてもよい。
- [7.5/A-SR-2] 複数のカメラの同時ストリーミングをサポートすることが強く推奨されます。
自動車デバイスの実装に世界を向いたカメラが少なくとも 1 つ含まれている場合、そのようなカメラについては次のようになります。
- [7.5/A-1-1] カメラの長辺が Android 自動車センサー軸の XY 平面と一致するように向ける必要があります。
- [7.5/A-SR-3] 固定焦点または EDOF (拡張被写界深度) ハードウェアのいずれかを使用することが強く推奨されます。
- [7.5/A-1-2] プライマリ世界向けカメラを、最も小さいカメラ ID を持つ世界向けカメラとして持たなければなりません。
自動車デバイス実装にユーザー側のカメラが少なくとも 1 つ含まれる場合、そのようなカメラについては次のようになります。
- [7.5/A-2-1] プライマリのユーザー側カメラは、最も小さいカメラ ID を持つユーザー側カメラでなければなりません。
- カメラの長辺が Android 自動車センサー軸の XY 平面と一致するように向けることができます。
自動車デバイス実装にandroid.hardware.Camera
またはandroid.hardware.camera2
API 経由でアクセスできるカメラが含まれる場合、次のようになります。
- [7.5/A-3-1] セクション 7.5 のコアカメラ要件に準拠しなければなりません。
自動車デバイス実装にandroid.hardware.Camera
または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
またはandroid.hardware.Camera2
API の両方を介してアクセスできる 1 つ以上のカメラが含まれる場合、そのようなカメラについては次のようになります。
- [7.5/A-6-1] 同じカメラ ID を報告しなければなりません。
自動車デバイス実装が独自のカメラ API を提供する場合、次のことが行われます。
- [7.5/A-7-1]
android.hardware.camera2
API または Extended View System API を使用して、このようなカメラ API を実装しなければなりません。
リビジョンを参照
自動車デバイスの実装:
- [ 3.8 /A-0-1] 現在のフォアグラウンド ユーザーではない完全なセカンダリ ユーザーがアクティビティを起動したり、任意のディスプレイ上の UI にアクセスしたりできるようにしてはなりません。
リビジョンを参照
自動車デバイス実装がandroid.hardware.microphone
を宣言する場合、次のようになります。
- [ 9.8.2 /A-1-1] アプリがマイクから音声データにアクセスしている場合はマイク インジケーターを表示しなければなりませんが、マイクが
HotwordDetectionService
、SOURCE_HOTWORD
、ContentCaptureService
またはセクションで説明されている役割を保持しているアプリによってのみアクセスされている場合は表示しません。 CDD 識別子 [C-4-X] を持つ9.1 。 - [ 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]付き。
デバイス実装に安全なロック画面があり、 TrustAgentService
システム API を実装する 1 つ以上の信頼エージェントが含まれる場合、デバイス実装は次のようになります。
- [ 9.11.1 /A-1-1] 336 時間に 1 回よりも頻繁に、推奨される主要な認証方法 (例: PIN、パターン、パスワード) の 1 つをユーザーに要求しなければなりません。
3. ソフトウェア
リビジョンを参照
デバイスの実装:
- [C-0-8] 23 未満の API レベルをターゲットとするアプリケーションのインストールをサポートしてはなりません。
リビジョンを参照
デバイス実装が
android.hardware.nfc.uicc
またはandroid.hardware.nfc.ese
を報告する場合、デバイス実装は:- [C-19-1] NfcAdapter.ACTION_TRANSACTION_DETECTEDインテント API ( GSM Association 技術仕様 TS.26 - NFC ハンドセット要件によって定義される「EVT_TRANSACTION」として) を実装しなければなりません。
リビジョンを参照
デバイスの実装:
- [C-0-12] コア
Vulkan 1.0Vulkan 1.1関数シンボル、およびVK_KHR_surface
、VK_KHR_android_surface
、VK_KHR_swapchain
、VK_KHR_maintenance1
、およびVK_KHR_get_physical_device_properties2
拡張機能の関数シンボルを、libvulkan.so
ライブラリを通じてエクスポートしなければなりません。すべてのシンボルが存在しなければなりませんが、セクション 7.1.4.2 では、対応する各機能の完全な実装が期待される場合の要件について詳しく説明していることに注意してください。
- [C-0-12] コア
リビジョンを参照
デバイス実装に画面またはビデオ出力が含まれる場合、デバイス実装は次のようになります。
- [C-1-5]
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
ドキュメント (android.theme.customization.theme_styles
を参照) に列挙されているカラー テーマ スタイル、つまりTONAL_SPOT
、VIBRANT
、EXPRESSIVE
、SPRITZ
、RAINBOW
、FRUIT_SALAD
、およびMONOCHROMATIC
を使用して、動的なカラー色調パレットを生成しなければなりません。 。
- [C-1-5]
リビジョンを参照
セクション 7.2.3で詳述されているように、最近の機能ナビゲーション キーを含むデバイス実装がインターフェイスを変更する場合、デバイス実装は次のようになります。
- [C-1-2]画面の固定動作を実装し、機能を切り替えるための設定メニューをユーザーに提供しなければなりません。
リビジョンを参照
デバイス実装が
android.software.managed_users
を宣言する場合、デバイス実装は次のことを行います。- [C-1-10] フォーカスがあり (すべてのアクティビティの中でユーザーが最後に操作したウィンドウ) 、仕事用プロファイルに属する
topActivity
ウィンドウでスクリーンショットがキャプチャされた場合、スクリーンショット データが仕事用プロファイル ストレージに保存されることを確認しなければなりません。アプリ。 - [C-1-11] スクリーンショットを仕事用プロファイルに保存するときは、仕事用プロファイル アプリケーションウィンドウを除き、他の画面コンテンツ (システム バー、通知、または個人用プロファイル コンテンツ) をキャプチャしてはなりません (個人用プロファイル データが確実に保存されるようにするため)。仕事用プロファイルには保存されません)。
- [C-1-10] フォーカスがあり (すべてのアクティビティの中でユーザーが最後に操作したウィンドウ) 、仕事用プロファイルに属する
3.9.5 デバイスポリシー解決フレームワーク: 新しいセクション
リビジョンを参照
デバイス実装が
android.software.device_admin
またはandroid.software.managed_users
を報告する場合、デバイス実装は次のことを行います。- [C-1-1] AOSP ドキュメントに記載されているように、デバイス ポリシーの競合を解決しなければなりません。
5. マルチメディア互換性
リビジョンを参照
デバイス実装は、次の画像エンコーディングのエンコーディングをサポートしなければなりません。
- [C-0-4] AVIF
- デバイスは
BITRATE_MODE_CQ
とベースライン プロファイルをサポートする必要があります。
- デバイスは
- [C-0-4] AVIF
リビジョンを参照
デバイス実装は、次の画像エンコーディングのデコードをサポートしなければなりません。
[C-0-7] AVIF(ベースラインプロファイル)
リビジョンを参照
フォーマット/コーデック 詳細 サポートされているファイル タイプ/コンテナ形式 JPEG ベース+プログレッシブ JPEG (.jpg) GIF GIF (.gif) PNG PNG (.png) BMP BMP (.bmp) WebP WebP (.webp) 生 ARW (.arw)、CR2 (.cr2)、DNG (.dng)、NEF (.nef)、NRW (.nrw)、ORF (.orf)、PEF (.pef)、RAF (.raf)、RW2 ( .rw2)、SRW (.srw) ハイフ 画像、画像コレクション、画像シーケンス HEIF (.heif)、HEIC (.heic) AVIF (ベースライン プロファイル) 画像、画像コレクション、画像シーケンス ベースライン プロファイル HEIF コンテナ (.avif) リビジョンを参照
フォーマット/コーデック 詳細 サポートされるファイルタイプ/コンテナフォーマット H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv、デコードのみ)
H.264 AVC 詳細については、セクション 5.2および5.3を参照してください。 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS (.ts、シーク不可)
- Matroska (.mkv、デコードのみ)
H.265 HEVC 詳細についてはセクション 5.3 を参照してください - MPEG-4 (.mp4)
- Matroska (.mkv、デコードのみ)
MPEG-2 主なプロフィール - MPEG2-TS (.ts、シーク不可)
- MPEG-4 (.mp4、デコードのみ)
- Matroska (.mkv、デコードのみ)
MPEG-4 SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska (.mkv、デコードのみ)
VP8 詳細については、セクション 5.2および5.3を参照してください。 - WebM (.webm)
- マトロスカ (.mkv)
VP9 詳細についてはセクション 5.3 を参照してください - WebM (.webm)
- マトロスカ (.mkv)
AV1 詳細については、セクション 5.2およびセクション 5.3を参照してください。 - MPEG-4 (.mp4)
- Matroska (.mkv、デコードのみ)
リビジョンを参照
デバイス実装がビデオ コーデックをサポートしている場合:
- [C-2-1] すべてのビデオ コーデックは、コーデックでサポートされている場合、次のサイズの達成可能なフレーム レート データを公開しなければなりません。
SD(低画質) SD(高画質) HD 720p HD1080p UHD ビデオ解像度 - 176 x 144 ピクセル (H263、MPEG2、MPEG4)
- 352 x 288 ピクセル (MPEG4 エンコーダー、H263、MPEG2)
- 320 x 180 ピクセル (VP8、VP8)
- 320×240ピクセル(その他)
- 704 x 576 ピクセル (H263)
- 640 x 360 ピクセル (VP8、VP9)
- 640 x 480 ピクセル (MPEG4 エンコーダー)
- 720 x 480 ピクセル (その他、 AV1 )
- 1408 x 1152 ピクセル (H263)
- 1280 x 720 ピクセル (その他、 AV1 )
1920×1080ピクセル(MPEG4、 AV1以外) 3840 x 2160 ピクセル (HEVC、VP9、 AV1 ) リビジョンを参照
デバイス実装がビデオ エンコーダーをサポートし、それをサードパーティ アプリで利用できるようにする場合、デバイス実装は次のことを行います。- 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% を超えないようにすることが強く推奨されます。
リビジョンを参照
デバイス実装が H.263 エンコーダをサポートし、それをサードパーティ アプリで利用できるようにする場合、デバイス実装は次のようになります。
- [C-1-1] ベースライン プロファイル レベル 45を使用して QCIF 解像度 (176 x 144)をサポートしなければなりません。SQCIF 解像度はオプションです。
サポートされているエンコーダの動的に構成可能なビットレートをサポートすべきです(SHOULD)。
リビジョンを参照
デバイス実装が H.265 コーデックをサポートする場合、デバイス実装は次のようになります。
- [C-1-1]最大 512 x 512 解像度のメイン プロファイル レベル 3 をサポートしなければなりません。
次の表に示すように、HD エンコード プロファイルをサポートすべきです。- [C-SR-1] は、ハードウェア エンコーダがある場合、次の表に示すように720 x 480 SD プロファイルとHD エンコード プロファイルをサポートすることが強く推奨されます。
5.2.6. AV1 : 新しいセクション
リビジョンを参照
デバイス実装が AV1 コーデックをサポートしている場合、デバイス実装は次のようになります。
- [C-1-1] 8 ビットおよび 10 ビットのコンテンツを含むメイン プロファイルをサポートしなければなりません。
[C-1-2] パフォーマンス データを公開しなければなりません。つまり、以下の表でサポートされている解像度の
getSupportedFrameRatesFor()
またはgetSupportedPerformancePoints()
API を介してパフォーマンス データを報告しなければなりません。[C-1-3] HDR メタデータを受け入れ、ビットストリームに出力しなければなりません
AV1 エンコーダがハードウェア アクセラレーションされている場合、次のようになります。
- [C-2-1] 以下の表の HD1080p エンコード プロファイルまでをサポートしなければなりません。
SD HD 720p HD1080p UHD ビデオ解像度 720×480ピクセル 1280×720ピクセル 1920×1080ピクセル 3840×2160ピクセル ビデオフレームレート 30fps 30fps 30fps 30fps ビデオのビットレート 5Mbps 8Mbps 16Mbps 50Mbps リビジョンを参照
デバイス実装が H.263 デコーダをサポートする場合、デバイス実装は次のようになります。
- [C-1-1] ベースライン プロファイル レベル 30 (CIF、QCIF、および SQCIF 解像度 @ 30fps 384kbps)およびレベル 45 (QCIF および SQCIF 解像度 @ 30fps 128kbps) をサポートしなければなりません。
リビジョンを参照
デバイス実装が 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 HD1080p UHD ビデオ解像度 720×480ピクセル 1280×720ピクセル 1920×1080ピクセル 3840×2160ピクセル ビデオフレームレート 30fps 30fps 30fps 30fps ビデオのビットレート 5Mbps 8Mbps 16Mbps 50Mbps デバイス実装が Media API を通じて HDR プロファイルをサポートする場合、デバイス実装は次のことを行います。
- [C-3-1] ビットストリームおよび/またはコンテナからの HDR メタデータの抽出および出力をサポートしなければなりません。
- [C-3-2] HDR コンテンツをデバイス画面または標準ビデオ出力ポート (HDMI など) に適切に表示しなければなりません。
リビジョンを参照
デバイス実装が
android.hardware.microphone
を宣言すると、次のようになります。- 90 dB の音圧レベル (SPL) (マイクの隣から
30 cm の距離で測定) で再生される 1000 Hz の正弦波音源が 1770 ~ 1770 の範囲内で RMS 2500 の理想的な応答を生み出すようにオーディオ入力感度を設定すべきです。音声認識音源の録音に使用される各マイクの 16 ビット サンプル (または浮動小数点/倍精度サンプルの場合は -22.35 db ±3dB フル スケール) の場合は 3530。
- 90 dB の音圧レベル (SPL) (マイクの隣から
リビジョンを参照
デバイス実装が
android.hardware.audio.output
機能を宣言する場合、デバイス実装は次のことを行います。- [C-1-4] 浮動小数点入力および出力によるオーディオ エフェクトをサポートしなければなりません。
- [C-1-5] オーディオ エフェクトが、FCC_LIMIT とも呼ばれるミキサー チャネル数までの複数のチャネルをサポートしていることを確認しなければなりません。
リビジョンを参照
デバイス実装が
android.hardware.audio.output
を宣言する場合、次の要件を満たすかそれを超えることが強く推奨されます。- [C-SR-4] AudioTrack.getTimestampおよび
AAudioStream_getTimestamp
によって返される出力タイムスタンプは、+/- 1 ミリ秒の精度です。
- [C-SR-4]
AAudioStream_getTimestamp
によって返される入力および出力タイムスタンプに基づいて計算された往復遅延は、スピーカー、有線および無線ヘッドセットのAAUDIO_PERFORMANCE_MODE_NONE
およびAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
で測定された往復遅延の 30 ミリ秒以内であることが強く推奨されます。
- [C-SR-4] AudioTrack.getTimestampおよび
7. ハードウェアの互換性
リビジョンを参照
Android には、サードパーティ アプリケーションが
さまざまなハードウェア構成で適切に動作するように、アプリケーション アセットと UI レイアウトをデバイスに合わせて自動的に調整する機能が含まれています。さまざまなハードウェアの表示と構成。 Android 互換ディスプレイは、Android 開発者 - 画面互換性の概要、このセクション (7.1) およびそのサブセクションで説明されているすべての動作と API、およびセクション 2に記載されている追加のデバイス タイプ固有の動作を実装する表示画面です。このCDD。すべてのサードパーティの Android 互換アプリケーションを実行できる Android 互換ディスプレイでは、デバイス実装は、このセクションで詳述するように、これらの API と動作を適切に実装しなければなりません (MUST)。新しい要件を開始する
デバイスの実装:
- [C-0-1] デフォルトでは、サードパーティのアプリケーションを Android 互換ディスプレイにのみレンダリングしなければなりません。
このセクションの要件で参照される単位は次のように定義されます。
- 物理的な対角サイズ。ディスプレイの照明部分の対向する 2 つの角の間の距離 (インチ単位)。
インチあたりのドット数 (dpi)密度。 1 インチの線形水平または垂直スパンに含まれるピクセル数。インチあたりのピクセル数 (ppi または dpi) で表されます。dpippi と dpi値がリストされている場合、水平 dpi と垂直 dpi の両方がリストされた範囲内に収まる必要があります。- アスペクト比。画面の短い寸法に対する長い寸法のピクセルの比率。たとえば、480x854 ピクセルのディスプレイは 854/480 = 1.779、つまりほぼ「16:9」になります。
- 密度に依存しないピクセル (dp) 。
160 dpiの画面密度 160 に正規化された仮想ピクセル単位。ある密度 d とピクセル数 p の場合、密度に依存しないピクセル数 dp は次のように計算されます。ピクセル = dps * (密度/160)dp = (160 / d) * p 。
リビジョンを参照
UI_MODE_TYPE_NORMAL
サイズ構成が可能な画面をサポートし、これらの画面をレンダリングするために角が丸い物理ディスプレイを使用するAndroid 互換のデバイス実装が含まれる場合、デバイス実装は次のようになります。- [C-1-1]それぞれのディスプレイについて、次の要件の少なくとも 1 つが満たされていることを確認しなければなりません。
- 丸い角の半径は 38 dp 以下です。
15 dp × 15 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 を介して、ヒンジまたは折り畳みの位置、境界、状態をアプリケーションに報告しなければなりません。
デバイス実装に、折りたたみ可能な 1 つ以上の Android 互換表示領域が含まれる場合、または複数の Android 互換表示パネル領域の間に折りたたみヒンジが含まれ、そのような表示領域をアプリケーションで利用できるようにする場合、デバイス実装は次のようになります。
- [C-4-1] 今後のドキュメントで説明されているように、正しいバージョンの Window Manager Extensions API レベルを実装しなければなりません。
7.1.1.2.画面アスペクト比: 削除
リビジョンを参照
デバイスの実装:
- [C-0-1]
デフォルトでは、デバイス実装は、DENSITY_DEVICE_STABLE
APIを介してDisplayMetrics
にリストされている Android フレームワーク密度のうち 1 つだけを報告しなければならず、この値は各物理ディスプレイの静的な値でなければなりません。いつでも変更してはなりません。ただし、デバイスは、初期起動後に設定されたユーザーによるディスプレイ構成の変更 (ディスプレイ サイズなど) に応じて、異なる任意の密度DisplayMetrics.density
を報告してもよい(MAY)。
- デバイス実装は、論理密度によって報告される画面サイズがサポートされる最小値を下回らない限り、画面の物理密度に数値的に最も近い標準 Android フレームワーク密度を定義する必要があります。物理密度に数値的に最も近い標準 Android フレームワーク密度の結果、サポートされている互換性のある最小の画面サイズ (幅 320 dp) よりも画面サイズが小さくなる場合、デバイス実装は次に低い標準 Android フレームワーク密度を報告する必要があります (SHOULD)。
新しい要件を開始する
- 画面の物理密度に数値的に最も近い標準 Android フレームワーク密度、またはハンドヘルド デバイスの同じ同等の角度視野測定値にマッピングされる値を定義すべきです。
デバイス実装がデバイスの表示サイズを変更するアフォーダンスを提供する
場合、デバイス実装は次のことを行います。- [C-1-1]
ディスプレイ サイズをスケーリングしてはなりません。DENSITY_DEVICE_STABLE のDENSITY_DEVICE_STABLE
密度の 1.5 倍を超えてディスプレイをスケーリングしてはなりません。または、320 dp (リソース修飾子 sw320dp に相当) より小さい有効な最小画面サイズを生成してはなりません。どちらか早い方です。 - [C-1-2]
表示サイズをスケーリングしてはなりません。DENSITY_DEVICE_STABLE
のネイティブ密度の 0.85 倍未満に表示をスケーリングしてはなりません。
- [C-0-1]
リビジョンを参照
Vulkan
1.0 以降のサポートがデバイス実装に含まれている場合、デバイス実装は次のようになります。[C-1-3] 列挙された各
VkPhysicalDevice
に対してVulkan 1.0Vulkan 1.1 API を完全に実装しなければなりません。[C-1-5] アプリケーションの
android:debuggable
属性がtrue
に設定されているか、メタデータcom.android.graphics.injectLayers.enable
が設定されていない限り、アプリケーション パッケージの外部のライブラリによって提供されるレイヤーを列挙したり、Vulkan API をトレースまたはインターセプトする他の方法を提供してはなりません。com.android.graphics.injectLayers.enable
をtrue
に設定します。
-
VkPhysicalDeviceProtectedMemoryFeatures
とVK_EXT_global_priority
をサポートすべきです (SHOULD)。
- [C-1-13] Android Baseline 2021 プロファイルで指定された要件を満たさなければなりません。
[C-SR-5]
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
features.protectedMemory およびVK_EXT_global_priority
をサポートすることが強く推奨されます。[C-SR-6] HWUI で
SkiaVk
使用することが強く推奨されます。
デバイス実装に Vulkan 1.1 のサポートが含まれており、ここで説明されているVulkan 機能フラグのいずれかを宣言している場合、デバイス実装は次のようになります。
- [C-SR-7]ここで説明されているように、
VK_KHR_external_fence_fd
拡張機能をサードパーティ アプリケーションで利用できるようにし、アプリケーションが POSIX ファイル記述子にフェンス ペイロードをエクスポートしたり、POSIX ファイル記述子からフェンス ペイロードをインポートできるようにすることが強く推奨されます。
リビジョンを参照
デバイス実装に複数の生体認証センサーがある場合、デバイス実装は次のようになります。
[C-7-1] 生体認証がロックアウト状態(つまり、ユーザーが一次認証でロックを解除するまで生体認証が無効になる)または時間制限付きロックアウト(つまり、ユーザーが一定の時間待機するまで生体認証が一時的に無効になる)の場合は、しなければなりません(MUST)。試行の失敗が多すぎるため、下位の生体認証クラスの他のすべての生体認証もロックアウトされます。期限付きロックアウトの場合、生体認証のバックオフ時間は、期限付きロックアウトにおけるすべての生体認証の最大バックオフ時間でなければなりません。
[C-SR-12] 生体認証がロックアウト状態(つまり、ユーザーが一次認証でロックを解除するまで生体認証が無効になる)または期限付きロックアウト(つまり、ユーザーが一定の時間を待つまで生体認証が一時的に無効になる)の場合は、強く推奨されます。間隔) 試行の失敗が多すぎるため、同じ生体認証クラスの他のすべての生体認証もロックアウトされます。期限付きロックアウトの場合、生体認証のバックオフ時間は、期限付きロックアウトにおけるすべての生体認証の最大バックオフ時間であることが強く推奨されます。
[C-7-2] ロックアウトされている生体認証のロックアウト カウンタをリセットするには、推奨される一次認証 (例: PIN、パターン、パスワード) をユーザーに要求しなければなりません。クラス 3 の生体認証は、同じクラスまたはそれ以下のクラスのロックされた生体認証のロックアウト カウンタをリセットできるようにしてもよい (MAY)。クラス 2またはクラス 1 の生体認証は、いかなる生体認証に対してもリセット ロックアウト操作を完了することを許可してはなりません (MUST NOT)。
デバイス実装が生体認証センサーをクラス 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 (以前はWeak ) として扱いたい場合は、次のようにします。
- [C-SR-15] Android バイオメトリクス テスト プロトコルで測定した、プレゼンテーション攻撃手段 (PAI) 種ごとのスプーフィングおよびなりすまし受理率が 20% 以下であることが強く推奨されます。
- [C-2-3] 生体認証照合は、信頼された実行環境 (TEE) などの、Android ユーザーまたはカーネル空間の外部にある隔離された実行環境、
または隔離された実行環境への安全なチャネルを持つチップ上、または保護された環境で実行しなければなりません。セクション 9.17 の要件を満たす仮想マシン。 - [C-2-4]実装ガイドラインに文書化されているように、分離された実行環境または分離された実行環境への安全なチャネルを持つチップの外でデータを取得、読み取り、または変更できないように、すべての識別可能なデータが暗号化され、暗号的に認証されなければなりません。 Android オープンソース プロジェクト サイト、またはセクション 9.17 の要件を満たすハイパーバイザーによって制御される保護された仮想マシン上で。
- [C-2-5] 生体認証ベースの認証または登録が行われている間のカメラベースの生体認証の場合:
- 隔離された実行環境、または隔離された実行環境への安全なチャネルを持つチップ、またはセクション 9.17 の要件を満たすハイパーバイザーによって制御される保護された仮想マシンの外部でカメラ フレームが読み取られたり変更されたりするのを防ぐモードでカメラを動作させなければなりません。
- RGB シングルカメラ ソリューションの場合、登録のためのプレビューなどの操作をサポートするために、カメラ フレームを分離された実行環境の外で読み取ることができますが、それでも変更できてはなりません。
- [C-2-7]セクションの要件を満たすハイパーバイザーによって制御される TEE または保護された仮想マシンのコンテキスト外のアプリケーション プロセッサに対して、識別可能な生体認証データまたはそこから派生するデータ (埋め込みなど) への暗号化されていないアクセスを許可してはなりません。 9.17 Android バージョン 9 以前で起動されたデバイスのアップグレードは、C-2-7 の対象から除外されません。
デバイス実装が生体センサーをクラス 3 (以前はStrong ) として扱いたい場合は、次のようにします。
- [C-SR-16] Android バイオメトリクス テスト プロトコルで測定した、プレゼンテーション攻撃手段 (PAI) 種ごとのスプーフィングおよびなりすまし受理率が 7% 以下であることが強く推奨されます。
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
: 到来角度 (AoA) データが報告されないことを除き、CONFIG_ID_1
と同じです。 -
CONFIG_ID_4
: P-STS セキュリティ モードが有効であることを除いて、CONFIG_ID_1
と同じです。 -
CONFIG_ID_5
: P-STS セキュリティ モードが有効であることを除いて、CONFIG_ID_2
と同じです。 -
CONFIG_ID_6
: P-STS セキュリティ モードが有効であることを除いて、CONFIG_ID_3
と同じです。 -
CONFIG_ID_7
: P-STS 個別制御対象キー モードが有効であることを除いて、CONFIG_ID_2
と同じです。
-
- [C-1-4] ユーザーが UWB 無線のオン/オフ状態を切り替えられるようにするユーザー アフォーダンスを提供しなければなりません。
- [C-1-5] UWB 無線を使用するアプリが (
NEARBY_DEVICES
権限グループの下で)UWB_RANGING
権限を保持することを強制しなければなりません。
FIRA 、 CCC 、 CSAなどの標準化団体によって定義された関連適合性および認定テストに合格することは、802.1.15.4 が正しく機能することを保証するのに役立ちます。
- [C-1-2] ハードウェア機能フラグ
リビジョンを参照
Android API およびこのドキュメントで使用される「電話」とは、特に、音声通話の発信および SMS メッセージの送信、またはモバイル (GSM、CDMA、LTE、NR など)GSM または CDMA ネットワークを介したモバイル データの確立に関連するハードウェアを指します。 「電話」をサポートするデバイスは、製品に応じて通話、メッセージング、およびデータ サービスの一部またはすべてを提供することを選択できます。
GSM または CDMA ネットワーク経由。これらの音声通話はパケット交換される場合とされない場合がありますが、Android の目的では、同じネットワークを使用して実装されるデータ接続とは独立していると見なされます。言い換えれば、Android の「テレフォニー」機能と API は、特に音声通話と SMS を指します。たとえば、電話をかけたり、SMS メッセージを送受信したりできないデバイス実装は、データ接続にセルラー ネットワークを使用するかどうかに関係なく、テレフォニー デバイスとみなされません。リビジョンを参照
デバイス実装に 802.11 のサポートが含まれており、その機能をサードパーティ アプリケーションに公開する場合、デバイス実装は次のようになります。
- [C-1-4] マルチキャスト DNS (mDNS) をサポートしなければならず、ドロップやこれらのパケットをフィルタリングすることは、ターゲット市場に適用される規制要件によって要求される消費電力の範囲内に収める必要があります。
Android Television デバイスの実装の場合、スタンバイ電源状態であっても。
- [C-1-4] マルチキャスト DNS (mDNS) をサポートしなければならず、ドロップやこれらのパケットをフィルタリングすることは、ターゲット市場に適用される規制要件によって要求される消費電力の範囲内に収める必要があります。
リビジョンを参照
デバイス実装が FEATURE_BLUETOOTH_LE を宣言した場合、次のようになります。
- [C-SR-2]
ADVERTISE_TX_POWER_HIGH
で送信しているリファレンス デバイスから 1 m の距離で BLE RSSI の中央値が -60dBm +/-10 dB であることを確認するために、Rx オフセットを測定して補正することが強く推奨されます。デバイスの向きは次のとおりです。画面が同じ方向を向いた「平行平面」上で。 - [C-SR-3] 1m の距離にある参照デバイスからスキャンし、デバイスの向きが
ADVERTISE_TX_POWER_HIGH
で送信する場合、BLE RSSI の中央値が -60dBm +/-10 dB であることを確認するために、Tx オフセットを測定および補正することが強く推奨されます。それらは、スクリーンが同じ方向を向いた「平行平面」上にあるようにします。
- [C-10-3]
ADVERTISE_TX_POWER_HIGH
で送信しているリファレンス デバイスから 1 m の距離で BLE RSSI 中央値が -55dBm +/-10 dB であることを保証するために、Rx オフセットを測定および補償しなければなりません。 - [C-10-4] 1m の距離にある参照デバイスからスキャンし、
ADVERTISE_TX_POWER_HIGH
で送信する場合、BLE RSSI の中央値が -55dBm +/-10 dB になるように、Tx オフセットを測定および補正しなければなりません。
デバイス実装が Bluetooth バージョン 5.0 をサポートする場合、デバイス実装は次のようになります。
- [C-SR-4] 以下のサポートを提供することが強く推奨されます。
- LE 2M PHY
- LE コーデック PHY
- LE 広告拡張機能
- 定期的な広告
- 少なくとも 10 個の広告セット
- 少なくとも 8 つの LE 同時接続。各接続は、いずれかの接続トポロジの役割に属することができます。
- LE リンク層のプライバシー
- 少なくとも 8 エントリの「解決リスト」サイズ
- [C-SR-2]
リビジョンを参照
- [C-1-7] 基準デバイスから 1m での距離測定値の中央値が [0.75m, 1.25m] 以内であることを保証しなければなりません。グランド トゥルース距離は DUT の上端から測定されます。
顔を上にして持ち、45度傾けます。
- [C-1-7] 基準デバイスから 1m での距離測定値の中央値が [0.75m, 1.25m] 以内であることを保証しなければなりません。グランド トゥルース距離は DUT の上端から測定されます。
リビジョンを参照
背面カメラは、デバイスのディスプレイの反対側にあるカメラです。つまり、従来のカメラのように、デバイスの向こう側のシーンを画像化します。
背面カメラは、従来のカメラと同様に、デバイスの反対側のシーンを画像化する世界に面したカメラです。ハンドヘルド デバイスでは、デバイスのディスプレイの反対側にあるカメラです。
リビジョンを参照
前面カメラは、デバイスのディスプレイと同じ側にあるカメラです。つまり、ビデオ会議や同様の用途などで、ユーザーを撮影するために通常使用されるカメラです。
前面カメラは、ビデオ会議や同様のアプリケーションなど、ユーザーを撮影するために通常使用されるユーザーに面したカメラです。ハンドヘルド デバイスでは、デバイスのディスプレイと同じ側にあるカメラです。
リビジョンを参照
外部カメラは、いつでもデバイス実装に物理的に取り付けたり取り外したりでき、あらゆる方向を向くことができるカメラです。 USBカメラなど。
リビジョンを参照
デバイス実装は、利用可能なすべてのカメラに対して、カメラ関連 API に対して次の動作を実装しなければなりません (MUST)。デバイスの実装:
- [C-SR-1] 複数の RGB カメラが近接して同じ方向を向いているデバイスの場合、その方向を向いているすべての RGB カメラで構成される、機能
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
をリストする論理カメラ デバイスをサポートすることが強く推奨されます。物理サブデバイスとして。
- [C-SR-1] 複数の RGB カメラが近接して同じ方向を向いているデバイスの場合、その方向を向いているすべての RGB カメラで構成される、機能
リビジョンを参照
次の基準をすべて満たすデバイスは、上記の要件から免除されます。
- 自動車デバイスなど、ユーザーが回転できないデバイス実装。
リビジョンを参照
手持ちまたは着用を目的としたデバイスには、着信音、アラーム、通知、一般的なタッチ フィードバックを通じて注意を引くなどの目的でアプリケーションに利用できる汎用触覚アクチュエーターが含まれる場合があります。
このような汎用触覚アクチュエーターがデバイス実装に含まれていない場合、デバイス実装は次のようになります。
- [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()
およびcreateWaveform()
API の品質評価に従うべきです。 - パブリック
android.os.Vibrator.hasAmplitudeControl()
API の結果がバイブレーターの機能を正しく反映していることを検証する必要があります。 -
android.os.Vibrator.hasAmplitudeControl()
を実行して、振幅のスケーラビリティの機能を検証する必要があります。
デバイス実装が触覚定数マッピングに従う場合、デバイス実装は次のようになります。
-
android.os.Vibrator.areAllEffectsSupported()
およびandroid.os.Vibrator.arePrimitivesSupported()
API を実行して、実装ステータスを確認する必要があります。 - 触覚定数の品質評価を実行すべきです。
- 定数の実装ガイダンスで説明されているように、サポートされていないプリミティブのフォールバック構成を検証し、必要に応じて更新する必要があります。
- ここで説明されているように、障害のリスクを軽減するためにフォールバック サポートを提供すべきです。
デバイス固有の要件については、セクション2.2.1を参照してください。
- [7.10/C]
9. セキュリティモデルの互換性
リビジョンを参照
デバイスの実装:
- [C-0-4] 両方のユーザー インターフェイスの実装は 1 つだけでなければなりません。
デバイスの実装が、システムUIインテリジェンス、システムアンビエントオーディオインテリジェンス、システムオーディオインテリジェンス、システム通知インテリジェンス、システムテキストインテリジェンス、またはシステムの視覚インテリジェンスの役割、パッケージを保持するパッケージを事前にインストールする場合:
- [C-4-1]セクション
「9.8.6 Content Capture」のデバイスの実装について概説されているすべての要件を満たす必要があります。
- [c-4-2]は、android.permission.internet許可を持っていてはなりません。これは、セクション9.8.6に記載されている強く推奨されているものよりも厳しいです。
- [C-4-3]は、次のシステムアプリを除き、他のアプリにバインドしてはなりません。Bluetooth、連絡先、メディア、テレフォニー、SystemUI、およびインターネットAPIを提供するコンポーネント。これは、セクション9.8.6に記載されている強く推奨されているものよりも厳しいです。
デバイスの実装に
VoiceInteractionService
をサポートするデフォルトアプリケーションが含まれている場合:- [C-5-1]そのアプリケーションのデフォルトとして
ACCESS_FINE_LOCATION
付与してはなりません。
リビジョンを参照してください
デバイスの実装が上記で説明した追加のユーザープロファイルを作成する場合、彼らは次のとおりです。
- [C-4-5]は、アイコンがユーザーに表示されるときに、デュアルインスタンスアプリケーションアイコンを視覚的に区別する必要があります。
- [C-4-6]は、クローンプロファイル全体のデータを削除するためにユーザー対応を提供する必要があります。
- [C-4-7]は、すべてのクローンアプリをアンインストールし、プライベートアプリデータディレクトリとそのコンテンツを削除し、クローンプロファイルデータを削除する必要があります。ユーザーがクローンプロファイルデータ全体を削除することを選択しました。
- 最後のクローンアプリが削除されたときに、ユーザーにクローンプロファイルデータ全体を削除するように促す必要があります。
- [C-4-8]は、クローンアプリケーションがアンインストールされているときにアプリデータが削除されることをユーザーに通知するか、アプリケーションがデバイスからアンインストールされているときにアプリデータを保持するオプションをユーザーに提供する必要があります。
- [C-4-9]は、ユーザーがアンインストール中にデータを削除することを選択したときに、プライベートアプリデータディレクトリとそのコンテンツを削除する必要があります。
[C-4-1]は、デバイス上のプライマリユーザーのアプリケーションによって、追加のプロファイルに由来する以下の意図を許可する必要があります。
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2]は、デバイスのプライマリユーザーにこの追加のユーザープロファイルに適用されるすべてのデバイスポリシーユーザー制限と選択された非ユーザー制限(以下のリスト)を継承する必要があります。
[C-4-3]は、次の意図を介して、この追加プロファイルからの連絡先の作成のみを許可する必要があります。
[C-4-4]は、この追加のユーザープロファイルで実行されているアプリケーションで実行されている連絡先同期を持たないでください。
- [C-4-14]この追加プロファイルで実行されているアプリケーションに対して、個別の許可とストレージ管理が必要です
- [C-4-5]は、親ユーザープロファイルにすでにアクセス可能な連絡先にアクセスするためのランチャーアクティビティを持つ追加プロファイルのアプリケーションのみを許可する必要があります。
リビジョンを参照してください
メモリセーフティテクノロジーは、
android:memtagMode
マニフェストオプション:- ヒープバッファオーバーフロー
- 無料で使用します
- ダブル無料
- ワイルドフリー(非マロックポインターがない)
デバイスの実装:
- [C-SR-15]は、
ro.arm64.memtag.bootctl_supported
を設定することを強くお勧めします。
デバイスの実装がシステムプロパティを設定した場合、
ro.arm64.memtag.bootctl_supported
exに[C-3-1]システムプロパティ
arm64.memtag.bootctl
次の値のコンマ分離されたリストを受け入れる必要があり、次の後続の再起動に目的の効果が適用されます。-
memtag
:上記で定義したメモリ安全技術が有効になっています memtag-once
:上記で定義したメモリ安全技術は一時的に有効になり、次の再起動で自動的に無効にされますmemtag-off
:上記で定義されているメモリ安全技術が無効になっています
-
[C-3-2]は、シェルユーザーが
arm64.memtag.bootctl
を設定できるようにする必要があります。[C-3-3]は、プロセスが
arm64.memtag.bootctl
を読み取ることを許可する必要があります。[C-3-4]は、
arm64.memtag.bootctl
ブート時に現在要求されている状態に設定する必要があります。また、デバイスの実装でシステムプロパティを変更せずに状態を変更できる場合は、プロパティも更新する必要があります。[C-SR-16]は、MemTag-Onceを設定してデバイスを再起動する開発者設定を表示するために強くお勧めします。互換性のあるブートローダーを使用すると、Androidオープンソースプロジェクトは、 MTEブートローダープロトコルを介して上記の要件を満たしています。
- [C-SR-17]は、ユーザーが
memtag
を有効にできるようにするセキュリティ設定メニューに設定を表示するために強くお勧めします。
リビジョンを参照してください
デバイスの実装:
- [c-0-2]ユーザー警告を表示し、ユーザーの画面に表示される機密情報をキャプチャできるようにする機密情報を許可する
明示的なユーザーの同意を取得する必要があります。画面キャストまたは画面録画は、MediaProjection.createVirtualDisplay()
、VirtualDeviceManager.createVirtualDisplay()
、または独自のAPIを介して開始されます。ユーザーの同意の将来の表示を無効にするために、ユーザーにアフォーダンスを提供してはなりません。
[C-SR-1]は、AOSPで実装されているとまったく同じメッセージであるユーザー警告を表示することを強くお勧めしますが、ユーザーの画面上の機密情報がキャプチャされていることをユーザーに明確に警告する限り変更できます。
[C-0-4]は、ユーザーがAndroid.appと
associate()
ことを許可しているシステムアプリによってセッションが開始されない限り、ユーザーの同意の将来のプロンプトを無効にするためのアフォーデンスをユーザーに提供するためのアフォーダンスを提供してはなりませんandroid.app.role.COMPANION_DEVICE_APP_STREAMING
またはandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
デバイスプロファイル。
- [c-0-2]ユーザー警告を表示し、ユーザーの画面に表示される機密情報をキャプチャできるようにする機密情報を許可する
9.8.6。 OSレベルと周囲のデータ:このセクションは、コンテンツキャプチャとアプリ検索からOSレベルと周囲のデータに変更されました。
リビジョンを参照してください
Androidは、システムを介して、APIS
、ContentCaptureService
、AugmentedAutofillService
、AppSearchGlobalManager.query
、または他の独自の手段によりアプリケーションとユーザーに敏感なデータ間の次のアプリケーションデータの相互作用をキャプチャするためのデバイス実装のメカニズムをサポートします。-
AugmentedAutofillService
を介してシステムに送信された画面またはその他のデータ。 -
Content Capture
APIを介してアクセス可能な画面またはその他のデータ。 -
FieldClassificationService
APIを介してアクセス可能な画面またはその他のデータ AppSearchManager
APIを介してシステムに渡され、AppSearchGlobalManager.query
を介してアクセス可能なアプリケーションデータ。
-
Content Capture
APIまたはAppSearchManager
APIを介してアプリケーションがシステムに提供するその他のイベントは、同様に有能なAndroidおよびProprietary APIです。
-
SpeechRecognizer#onDeviceSpeechRecognizer()
を使用した結果として取得されたオーディオデータ。 -
AudioRecord
、SoundTrigger
、またはその他のオーディオAPIを介してバックグラウンドで(継続的に)取得されたオーディオデータは、ユーザー可視インジケーターになりません - カメラマネーガーまたは他のカメラAPIを介して(継続的に)取得されたカメラデータは、ユーザー可視インジケーターになりません
デバイスの実装が上記のデータをキャプチャした場合、彼らは次のとおりです。
[C-1-3]は、データが共有されるたびに明示的なユーザーの同意がある場合を除き、プライバシーを提供するメカニズムを使用して、そのようなすべてのデータ
とログをデバイスからのみ送信する必要があります。プライバシーを提供するメカニズムは、「個々のユーザーへの登録イベントまたは派生結果の集計および一致を防ぐことを許可するもの」として定義されています。RAPPOR
)。[C-1-5]このようなデータを、現在のセクションで概説した要件に従わない他のOSコンポーネント(9.8.6
Content CaptureOSレベルデータとアンビエントデータ)と共有してはなりません。共有されました。そのような機能がAndroid SDK API(AmbientContext
、HotwordDetectionService
)として構築されていない限り。[C-1-6]は、データがデバイス上に任意の形式で保存されている場合
に実装または独自の手段が収集されるようなデータを消去するためのユーザーアフォーデンスを提供する必要があります。ユーザーがデータの消去を選択した場合、収集されたすべての履歴データを削除する必要があります。ContentCaptureService
- [C-SR-3]は、Android SDK APIまたは同様のOEM所有のオープンソースリポジトリで実装することを強くお勧めします。および /またはサンドボックス化された実装で実行されます(9.8.15サンドボックス化されたAPI実装を参照)。
Android、
SpeechRecognizer#onDeviceSpeechRecognizer()
を介して、ネットワークを伴わずにデバイスで音声認識を実行する機能を提供します。このセクションで概説されているポリシーに従う必要があるデバイス上の音声認知師の実装はすべてに従う必要があります。-
リビジョンを参照してください
デバイスの実装が
android.hardware.telephony
機能フラグを宣言した場合、彼らは次のとおりです。- [C-1-4]
BUGREPORT_MODE_TELEPHONY
を使用して生成されたレポートには、少なくとも次の情報が含まれている必要があります。-
SubscriptionManagerService
ダンプ
-
- [C-1-4]
9.8.15。サンドボックス化されたAPI実装:新しいセクション
リビジョンを参照してください
Androidは、一連のデリゲートAPIを介して、OSレベルと周囲のデータを安全に処理するメカニズムを提供します。このような処理は、特権アクセスとサンドボックス化されたAPI実装として知られる通信機能の削減により、プリインストールされたAPKに委任できます。
サンドボックス化されたAPI実装:
- [C-0-1]は、インターネットの許可を要求してはなりません。
- [C-0-2]は、プライバシーを摂取するメカニズムを使用して、またはAndroid SDK APIを介して間接的に使用して、公開されているオープンソースの実装に裏打ちされた構造化されたAPIを介してのみインターネットにアクセスする必要があります。プライバシーを提供するメカニズムは、「個々のユーザーへのログインしたイベントまたは派生結果の集計のみの分析のみを許可し、一致させることを防止するもの」として定義され、ユーザーごとのデータが内省不可能であることを防ぎます(例えば、差別的なプライバシーテクノロジーを使用して実装されます。ラップ)。
- [C-0-3]以下を除き、他のシステムコンポーネント(たとえば、サービスをバインドしない、またはプロセスIDを共有しない)とは別に保管する必要があります。
- テレフォニー、連絡先、システムUI、およびメディア
- [C-0-4]ユーザーがサービスをユーザーインストール可能なアプリケーションまたはサービスに置き換えることを許可してはなりません
- [C-0-5]は、プリインストールされたサービスのみがそのようなデータをキャプチャすることのみを許可する必要があります。交換機能がAOSPに組み込まれていない限り(デジタルアシスタントアプリの場合)。
- [C-0-6]は、そのようなデータをキャプチャできるように、プリインストールされたサービスメカニズム以外のアプリを許可してはなりません。このようなキャプチャ機能がAndroid SDK APIで実装されていない限り。
- [C-0-7]は、サービスを無効にするためにユーザーアフォーダンスを提供する必要があります。
- [C-0-8]は、セクション9.1で説明されているように、サービスによって保持されているAndroid許可を管理し、Android Permissions Modelに従うためにユーザーアフォーダンスを省略してはなりません。許可。
9.8.16。継続的なオーディオおよびカメラデータ:新しいセクション
リビジョンを参照してください
9.8.2の録音、9.8.6 OSレベルおよび周囲データ、および9.8.15のサンドボックスAPI実装で概説されている要件に加えて、AudioreCord、サウンドトリガー、またはその他のオーディオAPISを介して(継続的に)取得したオーディオデータを使用する実装はまたは、カメラマナジャーまたはその他のカメラAPIを介して(連続的に)取得したカメラデータ:
- [C-0-1]は、対応するインジケーター(セクション9.8.2の記録に従ってカメラおよび/またはマイク)を実施する必要があります。
- このアクセスは、次の役割の1つ以上を保持しているパッケージを介して、サンドボックス化された実装(9.8.15サンドボックスAPI実装を参照)で実行されます:システムUIインテリジェンス、システムアンビエントオーディオインテリジェンス、システム通知インテリジェンス、システムテキストインテリジェンス、またはシステム視覚インテリジェンス。
- アクセスはサンドボックスを介して実行され、AOSPのメカニズムを介して実装および実施されます(
HotwordDetectionService
、WearableSensingService
、VisualQueryDetector
)。 - オーディオアクセスは、デジタルアシスタントアプリケーションによって支援目的で実行され、
SOURCE_HOTWORD
オーディオソースとして提供します。 - アクセスはシステムによって実行され、オープンソースコードで実装されます。
- [C-SR-1]は、そのようなデータを利用するすべての機能に対してユーザーの同意を要求し、デフォルトで無効にすることを強くお勧めします。
- [C-SR-2]は、同じ治療を適用することを強くお勧めします(つまり、9.8.2の記録、9.8.6 OSレベルおよび周囲データ、9.8.15サンドボックスAPI実装、9.8.16連続オーディオおよび9.8.15で概説されている制限に従います。カメラデータ)リモートウェアラブルデバイスからのカメラデータへ。
カメラデータがリモートウェアラブルデバイスから提供され、Android OS、Sandboxed実装、または
WearableSensingManager
によって構築されたサンドボックス化された機能の外側の暗号化されていないフォームでアクセスされる場合、彼らは次のとおりです。- [C-1-1]は、リモートウェアラブルデバイスに追加のインジケータを表示する必要があります。
デバイスが割り当てられたキーワードなしでデジタルアシスタントアプリケーションに関与する機能を提供する場合(一般的なユーザークエリの処理、またはカメラを介したユーザーの存在を分析する):
- [C-2-1]は、
android.app.role.ASSISTANT
役割を保持しているパッケージによって、そのような実装が提供されることを確認する必要があります。 - [C-2-2]そのような実装により、
HotwordDetectionService
および/またはVisualQueryDetectionService
Android APIを使用する必要があります。
- [C-0-1]は、対応するインジケーター(セクション9.8.2の記録に従ってカメラおよび/またはマイク)を実施する必要があります。
9.8.17。テレメトリー:新しいセクション
リビジョンを参照してください
Statslog APIを使用して、Androidはシステムとアプリログを保存します。これらのログは、特権システムアプリケーションで使用できるStatsManager APIを介して管理されます。
Statsmanagerは、プライバシー保存メカニズムを備えたデバイスからプライバシーに敏感に分類されたデータを収集する方法も提供します。特に、
StatsManager::query
APIは、 Statslogで定義された制限されたメトリックカテゴリをクエリする機能を提供します。StatsManagerから制限されたメトリックをクエリと収集する実装:
- [C-0-1]は、デバイス上の唯一のアプリケーション/実装であり、
READ_RESTRICTED_STATS
許可を保持する必要があります。 - [C-0-2]は、プライバシーを提供するメカニズムを使用して、テレメトリーデータとデバイスのログのみを送信する必要があります。プライバシーを提供するメカニズムは、「個々のユーザーへのログインしたイベントまたは派生結果の集計のみの分析のみを許可し、一致させることを防止するもの」として定義され、ユーザーごとのデータが内省不可能であることを防ぎます(例えば、差別的なプライバシーテクノロジーを使用して実装されます。ラップ)。
- [C-0-3]は、そのようなデータをデバイス上のユーザーID(アカウントなど)に関連付けてはなりません。
- [C-0-4]は、現在のセクションで概説されている要件に従わない他のOSコンポーネントとそのようなデータを共有してはなりません(9.8.17 Privacy-Preserving Telemetry)。
- [C-0-5]は、プライバシーを提供するテレメトリの収集、使用、および共有を有効/無効にするために、ユーザーアフォーダンスを提供する必要があります。
- [C-0-6]は、データがデバイス上に任意の形式で保存されている場合、実装が収集するようなデータを消去するためのユーザーアフォーダンスを提供する必要があります。ユーザーがデータを消去することを選択した場合、デバイスに現在保存されているすべてのデータを削除する必要があります。
- [C-0-7]は、オープンソースリポジトリで基本的なプライバシーを提供するプロトコル実装を開示する必要があります。
- [C-0-8]は、このセクションのデータ出力ポリシーを実施して、 Statslogで定義された制限されたメトリックカテゴリのデータの収集をゲートする必要があります。
- [C-0-1]は、デバイス上の唯一のアプリケーション/実装であり、
リビジョンを参照してください
デバイスの実装デバイスの実装がページごとにファイルコンテンツを検証する機能を備えている場合、それらは次のとおりです。
[
C-0-3C-2-1 ]ファイル全体を読み取ることなく、信頼できるキーに対してファイルコンテンツを暗号化するように検証するサポートをサポートします。[
C-0-4C-2-2 ]は、読み取りコンテンツが信頼できるキーに対して検証されない場合、保護されたファイルの読み取り要求が成功することを許可してはなりません。
- [C-2-4]は、有効なファイルの場合はO(1)のファイルチェックサムを返す必要があります。
リビジョンを参照してください
Android Keystoreシステムにより、アプリ開発者は暗号化キーをコンテナに保存し、キーチェーンAPIまたはキーストアAPIを介して暗号化操作でそれらを使用できます。デバイスの実装:
- [C-0-3]は、失敗した一次認証試行の数を制限する必要があります。
- [C-SR-2]は、20のプライマリ認証試行の20の上限を実装することを強くお勧めします。ユーザーが機能に同意してオプトインする場合は、失敗したプライマリ認証試行の制限を超えた後、「工場データリセット」を実行します。
デバイスの実装が認証方法を追加または変更して、既知の秘密に基づいてロック画面のロックを解除し、画面をロックする安全な方法として扱われる新しい認証方法を使用する場合、次のとおりです。
- [C-SR-3]ピンは、少なくとも6桁、または同等に20ビットエントロピーを持つことを強くお勧めします。
- [C-2-1] 6桁未満の長さのピンは、ピンの長さを明らかにしないように、ユーザーインタラクションなしで自動エントリを許可してはなりません。
リビジョンを参照してください
デバイスの実装:
- [C-0-1]は、失敗した一次認証試行の数を制限する必要があります。
- [C-SR-5]は、20のプライマリ認証試行の20の上限を実装するために強くお勧めします。ユーザーが機能に同意してオプトインする場合は、失敗したプライマリ認証試行の制限を超えた後、「工場データリセット」を実行します。
デバイスの実装が推奨プライマリ認証方法として数値ピンを設定した場合、次のとおりです。
- [C-SR-6]ピンは、少なくとも6桁、または同等に20ビットのエントロピーを持つことを強くお勧めします。
- [C-SR-7] 6桁未満の長さのピンは、ピンの長さを明らかにしないように、ユーザーインタラクションなしで自動エントリを許可しないように強くお勧めします。
デバイス実装に安全なロック画面があり、
TrustAgentService
システム API を実装する 1 つ以上の信頼エージェントが含まれる場合、デバイス実装は次のようになります。[c-7-8]ユーザーの安全性(ドライバーの注意散漫など)がない限り、推奨されるプライマリ認証のいずれか(例:PIN、パターン、パスワード)メソッドに少なくとも72時間以内に挑戦する必要があります。懸念。デバイスの実装により、アプリケーションがセカンダリ仮想ディスプレイを作成し、 virualdevicemanagerを介して関連する入力イベントをサポートし、ディスプレイにvirtual_display_flag_secureでマークされていない場合、彼らは次のとおりです。
[C-13-10]は、仮想デバイスから開始されたアプリのインストールを無効にする必要があります。リビジョンを参照してください
デバイスがAndroid Virtualization Framework API(
android.system.virtualmachine.*
)のサポートを実装している場合、Androidホスト:- [C-1-1]
android.system.virtualmachine
パッケージで定義されたすべてのAPIをサポートする必要があります。 - [C-1-2]は、保護された仮想マシン(PVM)の管理のためのAndroid Selinuxと許可モデルを変更してはなりません。
- [C-1-3]は、上流のAndroidオープンソースプロジェクト(AOSP)に提供されるシステム/Sepolicy内に存在するNeverAllowルールを変更、省略、または交換してはなりません。
- [C-1-4]は、プラットフォーム署名されたコードと特権アプリのみを許可する必要があり、
信頼されていないコード(3Pアプリなど)が保護された仮想マシンPVMの作成と実行を許可してはなりません。注:これは、将来のAndroidリリースで変化する可能性があります。
- [C-1-5]は許可してはなりません
保護された仮想マシン工場画像やその更新の一部ではないコードを実行するPVM 。Android検証ブーツ(たとえば、インターネットからダウンロードされたファイルまたはサイドロードされたファイルなど)でカバーされていないものは、保護された仮想マシンで実行することを許可してはなりません。
- [C-1-5]は、特権アプリの更新も含む、非難可能なPVMが工場画像またはそのプラットフォームアップデートからコードを実行できるようにする必要があります。
デバイスがAndroid Virtualization Framework API(
android.system.virtualmachine.*
)のサポートを実装する場合、保護された仮想マシンPVMインスタンス:- [C-2-1]
は、保護された仮想マシンPVMで仮想化頂点で利用可能なすべてのオペレーティングシステムを実行できる必要があります。 - [C-2-2]
は、保護された仮想マシンPVMが、デバイスの実装者またはOSベンダーによって署名されていないオペレーティングシステムを実行できるようにしてはなりません。 - [C-2-3]
保護された仮想マシンPVMがコードとしてデータを実行できるようにしてはなりません(例:Selinux NeverAllow Execmem)。
- [C-2-4]は、アップストリームAndroid Open Source Project(AOSP)に記載されているシステム/Sepolicy/Microdroid内に存在するNeverAllowルールを変更、省略、または交換してはなりません。
- [C-2-5]は、非マイクロドロイドオペレーティングシステムであっても、
保護された仮想マシンPVM防衛メカニズム(PVMのSELINUXなど)を実装する必要があります。 - [C-2-6]は、VMが実行される
最初の画像を確認できない場合、 PVMがファームウェアに失敗することを確認する必要があります。検証はVM内で行う必要があります。 - [C-2-7]は、Instance.imgの整合性が損なわれた場合、 PVMが
ファームウェアに失敗することを確認する必要があります。
デバイスがAndroid仮想化フレームワークAPI(
android.system.virtualmachine.*
)のサポートを実装する場合、ハイパーバイザー:- [C-3-1]は、VM(PVMまたはホストVMのいずれか)が独占的に所有するメモリページが、保護または保護されていない他の仮想マシンではなく、仮想マシン自体またはハイパーバイザーにのみアクセスできることを確認する必要があります。
ページ所有者が明示的に共有しない限り、PVMが別のエンティティ(他のPVMまたはハイパーバイザーなど)に属するページにアクセスできるようにしてはなりません。これには、ホストVMが含まれます。これは、CPUとDMAアクセスの両方に適用されます。 - [C-3-2]は、 PVMによって使用され、ホストに返される前にページを拭く必要があります(例:PVMが破壊されます)。
- [C-
3-3SR-1 ]は、PVMのコードの前にPVMファームウェアがロードおよび実行されることを確認する必要があることを確認するために強くお勧めします。 - [C-3-4]は、各VMが
PVMインスタンスに提供される{boot証明書チェーン(BCC)および化合物デバイス識別子(CDIS)がその特定のVMインスタンスによってのみ導出され、変更することができるVMごとの秘密を導き出すことを保証する必要があります。工場出荷時のリセットとOTA。
デバイスがAndroid Virtualization Framework APIのサポートを実装している場合、すべての領域で次のとおりです。
- [C-4-1]は、AndroidセキュリティモデルをバイパスできるPVMに機能を提供してはなりません。
デバイスがAndroid Virtualization Framework APIのサポートを実装している場合、
- [C-5-1]は、孤立したコンピレーションをサポートできる必要がありますが、
ARTランタイムアップデートのデバイス出荷で孤立したコンピレーション機能を無効にする場合があります。
デバイスがAndroid Virtualization Framework APIのサポートを実装している場合、キー管理のために:
- [C-6-1]は、ロック解除されたデバイスでも、ユーザーが変更できない時点でサイコロチェーンをルート化する必要があります。 (スプーフィングできないことを確認するため)。
- [C- SR-2
6-2]は、VMごとの秘密派生メカニズムとしてサイコロを使用することを強くお勧めします。適切にサイコロをする必要があります。つまり、正しい値を提供します。
- [C-1-1]