人造人間13号
2022 年 10 月 19 日
2. デバイスの種類
リビジョンを見る
ハンドヘルド デバイスの実装がロック タスク モードで実行されていない場合、コンテンツがクリップボードにコピーされると:
- [3.8.17/H-1-1]データがクリップボードにコピーされたことの確認をユーザーに提示しなければなりません (例: 「コンテンツがコピーされました」というサムネイルまたは警告)。さらに、クリップボードのデータがデバイス間で同期されるかどうかをここに示します。
3. ソフトウェア
リビジョンを見る
アクティビティの埋め込みを使用して分割機能を実装する場合、デバイス実装の設定アプリケーションは:
- [C-17-1] 分割機能がオンの場合、 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITYインテントを処理するアクティビティがなければなりません。アクティビティは
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
で保護する必要があり、 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URIから解析されたインテントのアクティビティを開始する必要があります。
VoiceInteractionService
をサポートし、この API を使用する複数のアプリケーションが同時にインストールされている場合、デバイス実装は:- [C-18-1]
android.settings.ACTION_VOICE_INPUT_SETTINGS
を尊重して、音声入力とアシスト用のデフォルトのアプリ設定メニューを表示しなければなりません。
- [C-17-1] 分割機能がオンの場合、 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITYインテントを処理するアクティビティがなければなりません。アクティビティは
リビジョンを見る
- [C-1-4] WebView をインスタンス化するアプリケーションとは異なるプロセスで、提供されたコンテンツまたはリモート URL コンテンツをレンダリングしなければなりません。具体的には、個別のレンダラー プロセスは、より低い権限を保持し、個別のユーザー ID として実行し、アプリのデータ ディレクトリにアクセスできず、ネットワークに直接アクセスできず、Binder を介して最低限必要なシステム サービスにのみアクセスできる必要があります。 WebView の AOSP 実装は、この要件を満たしています。
7. ハードウェアの互換性
リビジョンを見る
IEEE 802.11 標準で定義されている Wi-Fi 省電力モードのサポートが含まれる場合、デバイス実装は:
[C-3-1] しなければならないアプリがWifiManager.createWifiLock()
およびWifiManager.WifiLock.acquire()
を介してWIFI_MODE_FULL_HIGH_PERF
ロックまたはWIFI_MODE_FULL_LOW_LATENCY
ロックを取得するたびに、Wi-Fi 省電力モードをオフにする必要があります。
リビジョンを見る
Bluetooth Low Energy (BLE) のサポートが含まれる場合、デバイス実装は:
- [C-3-5]デバイスがスキャンまたはアドバタイジングに BLE をアクティブに使用している場合、ユーザーのプライバシーを保護するために、15 分以内の解決可能なプライベート アドレス (RPA) タイムアウトを実装し、タイムアウト時にアドレスをローテーションしなければなりません。タイミング攻撃を防ぐために、タイムアウト間隔も 5 ~ 15 分の間でランダム化する必要があります。
7.5.5 カメラの向き
リビジョンを見る
デバイス実装に前面または背面カメラがある場合、そのようなカメラは:
- [C-1-1] カメラの長い寸法が画面の長い寸法と揃うように方向付けしなければなりません。つまり、デバイスが横向きに保持されている場合、カメラは横向きで画像をキャプチャする必要があります。これは、デバイスの自然な向きに関係なく適用されます。つまり、横向きのプライマリ デバイスと縦向きのプライマリ デバイスに適用されます。
次の基準をすべて満たすデバイスは、上記の要件から除外されます。- このデバイスは、折りたたみ式ディスプレイやヒンジ付きディスプレイなど、可変ジオメトリ スクリーンを実装しています。
- デバイスの折り畳みまたはヒンジの状態が変化すると、デバイスは縦-プライマリから横-プライマリ (またはその逆) の向きに切り替わります。
9. セキュリティ モデルの互換性
リビジョンを見る
デバイス実装が安全なロック画面をサポートする場合、それは:
- [C-1-6] IKeymasterDevice 4.0、 IKeymasterDevice 4.1、IKeyMintDevice バージョン 1、または IKeyMintDevice バージョン 2 をサポートしなければなりません。
リビジョンを見る
デバイスが Android Virtualization Framework API (
android.system.virtualmachine.*
) のサポートを実装している場合、Android ホストは:[C-1-3] アップストリームの Android オープン ソース プロジェクト(AOSP)で提供されるシステム / sepolicy 内に存在する neverallow ルールを変更、省略、または置換してはなりません。ポリシーは、存在するすべての neverallow ルールでコンパイルする必要があります。
デバイスが Android Virtualization Framework API (
android.system.virtualmachine.*
) のサポートを実装している場合、保護された仮想マシン インスタンスは次のようになります。[C-2-4] アップストリームの Android オープン ソース プロジェクト(AOSP)で提供される system/sepolicy/microdroid 内に存在する neverallow ルールを変更、省略、または置換してはなりません。
デバイスが Android Virtualization Framework API のサポートを実装している場合、キー管理は次のようになります。
- [C-6-2] DICE を適切に実行しなければなりません。つまり、正しい値を提供しなければなりません。
しかし、その詳細レベルまで行く必要はないかもしれません。
2022 年 8 月 15 日
2. デバイスの種類
2.2.1 ハードウェア: ハードウェア要件が次のように変更されました。
入力デバイス:
リビジョンを見る
ハンドヘルド デバイスの実装:
- [ 7.2 .3/H-0-5] 戻るジェスチャーが開始されるか、戻るボタン (
KEYCODE_BACK
) が押されたときに、現在フォーカスされているウィンドウでOnBackInvokedCallback.onBackStarted()
を呼び出さなければなりません。 - [ 7.2 .3/H-0-6] バック ジェスチャがコミットされたとき、または [戻る] ボタンが離された (UP) ときに
OnBackInvokedCallback.onBackInvoked()
を呼び出さなければなりません。 - [ 7.2 .3/H-0-7] バック ジェスチャがコミットされていない場合、または
KEYCODE_BACK
イベントがキャンセルされた場合、OnBackInvokedCallback.onBackCancelled()
を呼び出さなければなりません。
PackageManager.FEATURE_WIFI_AWARE
を宣言して WiFi Neighbor Awareness Networking (NAN) プロトコルをサポートし、PackageManager.FEATURE_WIFI_RTT
を宣言して Wi-Fi ロケーション (Wi-Fi ラウンドトリップ時間 — RTT) をサポートする場合、デバイスは:[ 7.4 .2.5/H-1-1] 68 パーセンタイル (累積分布関数で計算) で 160 MHz 帯域幅で ±1 メートル以内、80 MHz 帯域幅で ±2 メートル以内の範囲で範囲を正確に報告しなければなりません。 68 パーセンタイルでは 40 MHz 帯域幅で +/-4 メートル、68 パーセンタイルでは 20 MHz 帯域幅で +/-8 メートル、10 cm、1 m、3 m、および 5 m の距離で、 WifiRttManager#startRanging Android APIを介して観察されます。
[ 7.4 .2.5/H-SR] 範囲を 160 MHz 帯域幅で 90 パーセンタイル (累積分布関数で計算) で +/-1 メートル以内、80 MHz で +/-2 メートル以内に正確に報告することが強く推奨されます。 WifiRttManager#startRanging Android APIを介して観察されるように、10 cm の距離で 90 パーセンタイルで帯域幅、90 パーセンタイルで 40 MHz 帯域幅で +/-4 メートル、90 パーセンタイルで 20 MHz 帯域幅で +/-8 メートル。
Presence Calibration Requirementsで指定された測定セットアップ手順に従うことを強くお勧めします。
- [ 7.2 .3/H-0-5] 戻るジェスチャーが開始されるか、戻るボタン (
オーディオ遅延:
リビジョンを見る
ハンドヘルド デバイスの実装で
android.hardware.audio.output
とandroid.hardware.microphone
を宣言する場合:- [ 5.6 /H-1-1] 平均連続往復遅延が500でなければなりません。
8005 回の測定でミリ秒以下、平均絶対偏差が50未満100ms、次のデータ パスを介して: 「スピーカーからマイク」、3.5 mm ループバック アダプター (サポートされている場合)、USB ループバック (サポートされている場合)。少なくとも 1 つのサポートされているパス。
- [ 5.6 /H-1-1] スピーカーからマイクへのデータ パスでの少なくとも 5 回の測定で、Tap-to-tone レイテンシの平均が 500 ミリ秒以下でなければなりません。
- [ 5.6 /H-1-1] 平均連続往復遅延が500でなければなりません。
触覚入力:
リビジョンを見る
少なくとも 1 つの触覚アクチュエータが含まれる場合、ハンドヘルド デバイス実装は:
- [ 7.10 /H]* 偏心回転質量 (ERM) 触覚アクチュエータ (バイブレータ) を使用すべきではありません。
- [ 7.10 /H]* アクチュエータの配置は、デバイスが通常手で保持または触れる場所の近くに配置する必要があります。
- [ 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_START) で、明確な触覚のすべての公開定数を実装する必要があります。
- [ 7.10 /H]* android.os.VibrationEffectのクリア ハプティクス用のすべてのパブリック定数、つまり (EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK、および EFFECT_DOUBLE_CLICK) と、 android.os.VibrationEffect.Compositionのリッチ ハプティクス用の実行可能なすべてのパブリック
PRIMITIVE_*
定数を実装する必要があります。(PRIMITIVE_CLICK と PRIMITIVE_TICK)(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]* public android.os.Vibrator.hasAmplitudeControl() API の結果がバイブレーターの機能を正しく反映していることを確認する必要があります。
- [ 7.10 /H]* android.os.Vibrator.hasAmplitudeControl()を実行して、振幅スケーラビリティの機能を検証する必要があります。
ハンドヘルド デバイス実装に少なくとも 1 つの線形共振アクチュエータが含まれる場合、それらは:
Auth Trivial Device Controls:
リビジョンを見る
- [ 3.8 .16/H-1-5]
ControlsProviderService
およびControl
Control.isAuthRequired
API を通じてサードパーティ アプリケーションによって登録されたコントロールから、アプリ指定の認証自明なデバイス コントロールをオプトアウトするためのユーザー アフォーダンスを提供しなければなりません。
- [ 3.8 .16/H-1-5]
MediaStyle 通知:
リビジョンを見る
ハンドヘルド デバイス実装がMediaStyle 通知をサポートする場合、それらは:
- [3.8.3.1/H-1-SR] システム UI からアクセスするユーザー アフォーダンス (「出力スイッチャー」など) を提供することを強く推奨アプリがMediaSession トークンを使用して MediaStyle 通知を送信したとき。
2.2.4 パフォーマンスとパワー: フォアグラウンド サービスを実行するアプリの新しい要件。
リビジョンを見る
ハンドヘルド デバイスの実装:
- [ 8.5 /H-0-1] 設定メニューで、フォアグラウンド サービスを実行しているアプリを停止し、アクティブなフォアグラウンド サービスを持つすべてのアプリと、それ以降のこれらの各サービスの期間を表示する機能を備えたユーザー アフォーダンスを提供しなければなりません。 SDK ドキュメントの説明に従って開始されました。
- 一部のアプリは、 SDK ドキュメントで説明されているように、停止されたり、そのようなユーザー アフォーダンスにリストされたりすることを免除される場合があります。
- [ 8.5 /H-0-1] 設定メニューで、フォアグラウンド サービスを実行しているアプリを停止し、アクティブなフォアグラウンド サービスを持つすべてのアプリと、それ以降のこれらの各サービスの期間を表示する機能を備えたユーザー アフォーダンスを提供しなければなりません。 SDK ドキュメントの説明に従って開始されました。
2.2.7.1 メディア: 「ハンドヘルド要件メディア」セクションを次のように更新します。
リビジョンを見る
ハンドヘルド デバイスの実装が
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してandroid.os.Build.VERSION_CODES.T
を返す場合、それらは:- [5.1/H-1-1]
CodecCapabilities.getMaxSupportedInstances()
およびVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア ビデオ デコーダ セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-2] 解像度 1080p@30 fps で同時に実行される任意のコーデックの組み合わせで、ハードウェア ビデオ デコーダ セッション (AVC、HEVC、VP9、AV1 以降) の 6 つのインスタンスをサポートしなければなりません。
- [5.1/H-1-3]
CodecCapabilities.getMaxSupportedInstances()
およびVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア ビデオ エンコーダー セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-4] 解像度 1080p@30fps で同時に実行される任意のコーデックの組み合わせで、ハードウェア ビデオ エンコーダー セッション (AVC、HEVC、VP9、AV1 以降) の 6 つのインスタンスをサポートしなければなりません。
- [5.1/H-1-5]
CodecCapabilities.getMaxSupportedInstances()
およびVideoCapabilities.getSupportedPerformancePoints()
メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア ビデオ エンコーダーおよびデコーダー セッションの最大数をアドバタイズしなければなりません。 - [5.1/H-1-6] 1080p@30fps の解像度で同時に実行される任意のコーデックの組み合わせで、ハードウェア ビデオ デコーダーおよびハードウェア ビデオ エンコーダー セッション (AVC、HEVC、VP9、AV1 以降) の 6 つのインスタンスをサポートしなければなりません。
- [5.1/H-1-7] 負荷がかかっている場合、すべてのハードウェア ビデオ エンコーダーの 1080p 以下のビデオ エンコーディング セッションでは、コーデックの初期化レイテンシが 40 ミリ秒以下でなければなりません。ここでのロードは、1080p オーディオ ビデオ記録の初期化と共にハードウェア ビデオ コーデックを使用する同時 1080p から 720p へのビデオのみのトランスコーディング セッションとして定義されます。
- [5.1/H-1-8] 負荷がかかっている場合、すべてのオーディオ エンコーダーの 128 kbps 以下のビットレート オーディオ エンコーディング セッションでは、コーデックの初期化レイテンシが 30 ミリ秒以下でなければなりません。ここでのロードは、1080p オーディオ ビデオ記録の初期化と共にハードウェア ビデオ コーデックを使用する同時 1080p から 720p へのビデオのみのトランスコーディング セッションとして定義されます。
- [5.1/H-1-9] 1080p 解像度 @30 fps で同時に実行される任意のコーデックの組み合わせで、セキュア ハードウェア ビデオ デコーダ セッション (AVC、HEVC、VP9、AV1 以降) の 2 つのインスタンスをサポートしなければなりません。
- [5.1/H-1-10] 非セキュア ハードウェア ビデオ デコーダー セッションの 3 つのインスタンスと、セキュア ハードウェア ビデオ デコーダー セッションの 1 つのインスタンス (合計 4 つのインスタンス) (AVC、HEVC、VP9、AV1 以降) を任意のコーデックでサポートしなければなりません。 1080p 解像度 @30fps で同時に実行される組み合わせ。
- [5.1/ H-1-11] デバイス上のすべてのハードウェア AVC、HEVC、VP9、または AV1 デコーダーのセキュア デコーダーをサポートしなければなりません。
- [5.1/H-1-12] ビデオ デコーダの初期化レイテンシが 40 ミリ秒以下でなければなりません。
- [5.1/H-1-13] オーディオ デコーダの初期化レイテンシが 30 ミリ秒以下でなければなりません。
- [5.1/H-1-14] AV1 ハードウェア デコーダ メイン 10、レベル 4.1 をサポートしなければなりません。
- [5.1/H-SR] AV1 ハードウェア デコーダのフィルム グレインをサポートすることを強く推奨します。
- [5.1/H-1-15] 4K60 をサポートするハードウェア ビデオ デコーダーが少なくとも 1 つなければなりません。
- [5.1/H-1-16] 4K60 をサポートするハードウェア ビデオ エンコーダーが少なくとも 1 つなければなりません。
- [5.3/H-1-1] 負荷がかかっている 1080p 60 fps ビデオ セッションで、10 秒間に 1 フレームを超えてドロップしてはなりません (つまり、0.167 パーセント未満のフレーム ドロップ)。負荷は、ハードウェア ビデオ コーデックを使用した同時 1080p から 720p へのビデオのみのトランスコーディング セッションと、128 kbps AAC オーディオ再生として定義されます。
- [5.3/H-1-2] 負荷がかかっている 60 fps ビデオ セッションでのビデオ解像度の変更中に、10 秒間に 1 フレームを超えてドロップしてはなりません。負荷は、ハードウェア ビデオ コーデックを使用した同時 1080p から 720p へのビデオのみのトランスコーディング セッションと、128 kbps AAC オーディオ再生として定義されます。
- [5.6/H-1-1] OboeTester のタップトゥトーン テストまたは CTS Verifier のタップトゥトーン テストを使用して、タップトゥトーンのレイテンシが 80 ミリ秒以下でなければなりません。
- [5.6/H-1-2] 少なくとも 1 つのサポートされているデータ パスで、80 ミリ秒以下の往復オーディオ レイテンシがなければなりません。
- [5.6/H-1-3] 3.5 mm オーディオ ジャックを介したステレオ出力用に >=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.7/H-1-2] 以下のコンテンツ復号化機能を備えた
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
をサポートしなければなりません。
最小サンプルサイズ 4 MiB サブサンプルの最小数 - H264 または HEVC 32 サブサンプルの最小数 - VP9 9 サブサンプルの最小数 - AV1 288 最小サブサンプル バッファ サイズ 1 MiB 汎用暗号バッファの最小サイズ 500KiB 同時セッションの最小数 30 セッションあたりのキーの最小数 20 キーの最小総数 (すべてのセッション) 80 DRM キーの最小総数 (すべてのセッション) 6 メッセージサイズ 16KiB 1 秒あたりの復号化フレーム数 60fps - [5.1/H-1-1]
2.2.7.2 カメラ: メディア パフォーマンス クラス カメラ要件の更新。
リビジョンを見る
ハンドヘルド デバイスの実装が
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してandroid.os.Build.VERSION_CODES.T
を返す場合、それらは:- [7.5/H-1-1] 4k@30fps でのビデオ キャプチャをサポートする、少なくとも 12 メガピクセルの解像度を持つ主要な背面カメラがなければなりません。プライマリ背面カメラは、カメラ ID が最も小さい背面カメラです。
- [7.5/H-1-2] 少なくとも 5 メガピクセルの解像度を持ち、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 解像度の camera2 JPEG キャプチャ レイテンシが 1000 ミリ秒未満でなければなりません。
- [7.5/H-1-6] 両方のプライマリ カメラの ITS 照明条件 (3000K) の下で CTS カメラの PerformanceTest によって測定されるように、camera2 の起動レイテンシ (カメラを開いて最初のプレビュー フレームまで) が 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 カメラが複数ある場合、プライマリ カメラの
LOGICAL_MULTI_CAMERA
機能をサポートしなければなりません。 - [7.5/H-1-14] プライマリ フロント カメラとプライマリ バック カメラの両方で
STREAM_USE_CASE
機能をサポートしなければなりません。
2.2.7.3 ハードウェア: ハードウェアのメディア パフォーマンス クラス要件の更新。
リビジョンを見る
ハンドヘルド デバイスの実装が
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
に対してandroid.os.Build.VERSION_CODES.T
を返す場合、それらは:- [7.1.1.1/H-2-1] 少なくとも 1080p の画面解像度がなければなりません。
- [7.1.1.3/H-2-1] 少なくとも 400 dpi の画面密度がなければなりません。
- [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
を返す場合、それらは:- [8.2/H-1-1] 少なくとも 125 MB/秒のシーケンシャル書き込みパフォーマンスを確保しなければなりません。
- [8.2/H-1-2] 少なくとも 10 MB/秒のランダム書き込みパフォーマンスを確保しなければなりません。
- [8.2/H-1-3] 少なくとも 250 MB/秒のシーケンシャル読み取りパフォーマンスを確保しなければなりません。
- [8.2/H-1-4] 少なくとも 40 MB/秒のランダム読み取りパフォーマンスを確保しなければなりません。
2.5.1 ハードウェア: 3 軸加速度計と 3 軸ジャイロスコープの要件、および外部ビュー カメラの要件の更新。
リビジョンを見る
自動車デバイスの実装:
- [ 7.3.1 /A-0-4] Androidカーセンサー座標系に準拠しなければなりません。
- [ 7.3 /A-SR] 3 軸加速度計と 3 軸ジャイロスコープを含めることが強く推奨されます。
- [ 7.3 /A-SR]
TYPE_HEADING
センサーを実装して報告することが強く推奨されます。
加速度計が含まれる場合、自動車デバイス実装は:
- [ 7.3 .1/A-1-1] 少なくとも 100 Hz の周波数までのイベントを報告できなければなりません。
3 軸加速度計が含まれる場合、デバイス実装は:
- [ 7.3 .1/A-SR] 制限された軸の加速度計に複合センサーを実装することが強く推奨されます。
3 軸未満の加速度計が含まれる場合、自動車デバイス実装は:
- [ 7.3 .1/A-1-3]
TYPE_ACCELEROMETER_LIMITED_AXES
センサーを実装して報告しなければなりません。 - [ 7.3 .1/A-1-4]
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
センサーを実装して報告しなければなりません。
ジャイロスコープが含まれる場合、自動車デバイス実装は:
3 軸ジャイロスコープが含まれる場合、自動車デバイス実装は:
- [ 7.3 .4/A-SR] 制限軸ジャイロスコープ用の複合センサーを実装することが強く推奨されます。
3 軸未満のジャイロスコープが含まれる場合、自動車デバイス実装は:
- [ 7.3 .4/A-4-1]
TYPE_GYROSCOPE_LIMITED_AXES
センサーを実装および報告しなければなりません。 - [ 7.3 .4/A-4-2]
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
センサーを実装および報告しなければなりません。
TYPE_HEADING
センサーが含まれる場合、自動車デバイス実装は:外部ビュー カメラは、リアビュー カメラのように、デバイス実装の外側のシーンを撮影するカメラです。
ドライブレコーダー.車載デバイス実装に外部ビュー カメラが含まれる場合、そのようなカメラについて、それらは:
[ 7.5 .5/A-SR] カメラの長い寸法が水平線と一致するように方向付けすることが強く推奨されます。Android 同期フレームワークをサポートする必要があります。カメラ ドライバーにハードウェア オート フォーカスまたはソフトウェア オート フォーカスのいずれかが実装されている場合があります。
自動車デバイスの実装に 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で説明されているように、背面カメラで使用できる機能 (オート フォーカスなど) を含めることができます。
2.5.5 セキュリティ モデル: 自動車デバイスのカメラ許可に関する新しい要件。
リビジョンを見る
Automotive デバイス実装が
android.hardware.camera.any
を宣言する場合、それらは:[ 9.8.2 /A-2-1] アプリがライブ カメラ データにアクセスしている場合はカメラ インジケーターを表示しなければなりませんが、セクション 9.1 CDD によるアクセス許可で説明されているロールを保持しているアプリのみがカメラにアクセスしている場合は表示しません。識別子 [C-3-X]。
[ 9.8.2 /A-2-2] 目に見えるユーザー インターフェースまたは直接的なユーザー操作を備えたシステム アプリのカメラ インジケーターを非表示にしてはなりません。
2.6.1 タブレットの要件 — ハードウェア: タブレットの画面サイズの要件を更新します。
リビジョンを見る
Android タブレット デバイスとは、通常、次のすべての基準を満たす Android デバイスの実装を指します。
- 画面表示サイズが 7 インチ以上 18 インチ未満 (対角線で測定)。
画面サイズ
- [ 7.1 .1.1/Tab-0-1] 7 ~ 18 インチの範囲の画面が必要です。
3. ソフトウェア
3.2.2 ビルド パラメータ:
getSerial()
の ASCII 文字を更新しました。リビジョンを見る
- [C-0-1] デバイス実装間で一貫性のある意味のある値を提供するために、以下の表には、デバイス実装が準拠しなければならないこれらの値の形式に関する追加の制限が含まれています。
パラメータ 詳細 getSerial() ハードウェアのシリアル番号である必要があります (または返す必要があります)。これは、同じ MODEL および MANUFACTURER のデバイス間で使用可能で一意でなければなりません。このフィールドの値は、7 ビット ASCII としてエンコード可能で、正規表現"^[a-zA-Z0-9]+$" と一致する必要があります。 3.2.3.5 条件付きアプリケーション インテント: 条件付きアプリケーション インテントの要件を更新します。
リビジョンを見る
大型ディスプレイ(通常、ディスプレイの幅と高さが 600 dp 以上)が含まれ、分割機能をサポートする場合、デバイス実装は:
- [C-17-1] 分割機能がオンの場合、 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITYインテントを処理するアクティビティがなければなりません。アクティビティは
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
で保護する必要があり、 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URIから解析されたインテントのアクティビティを開始する必要があります。
- [C-17-1] 分割機能がオンの場合、 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITYインテントを処理するアクティビティがなければなりません。アクティビティは
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-9] これらすべての独自の制限イベントを UsageStats 経由で報告しなければなりません。
[C-1-10] 所有権の制限がどのように適用されるかを説明する公開の明確なドキュメントまたはウェブサイトを提供しなければなりません。このドキュメントまたは Web サイトは、Android SDK ドキュメントからリンク可能である必要があり、以下を含める必要があります。
- 所有権制限のトリガー条件。
- アプリを制限できる対象と方法。
- アプリをそのような制限から免除する方法。
- ユーザーがインストールできるアプリに対してそのような免除をサポートしている場合、アプリが独自の制限からの免除を要求する方法。
アプリがデバイスにプリインストールされていて、ユーザーが 30 日以上明示的に使用していない場合、[C-1-3] [C-1-5] は免除されます。
3.8.1 ランチャー (ホーム画面) :
monochrome/adaptive-icon
をサポートするための更新。リビジョンを見る
デバイス実装がモノクロアイコンをサポートしている場合、これらのアイコン:
- [C-6-1] ユーザーが明示的に有効にする場合にのみ使用しなければなりません (例: 設定または壁紙ピッカー メニューを介して)。
3.8.2 ウィジェット: ランチャーでのサードパーティ アプリ ウィジェットの表示を更新しました。
リビジョンを見る
サードパーティ アプリ ウィジェットをサポートする場合、デバイス実装は:
- [C-1-2] AppWidgets の組み込みサポートを含め、AppWidgets を追加、構成、表示、および削除するためのユーザー インターフェース アフォーダンスを公開しなければなりません。
ランチャー内で直接。
- [C-1-2] AppWidgets の組み込みサポートを含め、AppWidgets を追加、構成、表示、および削除するためのユーザー インターフェース アフォーダンスを公開しなければなりません。
3.8.3.1 通知の表示: ヘッドアップ通知の定義を明確にします。
リビジョンを見る
ヘッドアップ通知は、ユーザーがいるサーフェスとは関係なく、ユーザーに表示される通知です。
3.8.3.3 DND (Do Not Disturb) / 優先モード: DND (Do Not Disturb) 要件に優先モードを含めるように更新します。
リビジョンを見る
3.8.3.3. DND (邪魔しないでください) / 優先モード
DND 機能(優先モードとも呼ばれる) をサポートする場合、デバイス実装は:
3.8.6 テーマ: 動的色調パレットの新しい要件。
リビジョンを見る
画面または動画出力が含まれる場合、デバイス実装は:
[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
を使用して、動的な色調パレットを生成しなければなりません。「ソース カラー」は、
android.theme.customization.system_palette
で送信されたときに動的な色調パレットを生成するために使用されます (Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
に記載されています)。[C-1-6]
CAM16
クロマ値が 5 以上でなければなりません。com.android.systemui.monet.ColorScheme#getSeedColors
を介して壁紙から派生する必要があります。これにより、複数の有効なソース カラーから 1 つを選択できます。提供された色のいずれも上記のソース色の要件を満たしていない場合は、値
0xFF1B6EF3
を使用する必要があります。
3.8.17 クリップボード: クリップボードのコンテンツに関する新しい要件セクションが追加されました。
リビジョンを見る
3.8.17.クリップボード
デバイスの実装:
- [C-0-1] 9.8.6 コンテンツで言及されているサービスを除き、明示的なユーザー アクション (オーバーレイ上のボタンを押すなど) なしに、クリップボード データをコンポーネント、アクティビティ、サービス、またはネットワーク接続を介して送信してはなりません。キャプチャとアプリ検索。
ClipData.getDescription().getExtras()
にandroid.content.extra.IS_SENSITIVE
が含まれるClipData
アイテムのクリップボードにコンテンツがコピーされたときに、ユーザーに表示されるプレビューを生成する場合、デバイス実装は:- [C-1-1] ユーザーに表示されるプレビューを編集しなければなりません
AOSP リファレンス実装は、これらのクリップボード要件を満たしています。
3.9.1.1 デバイス所有者のプロビジョニング: デバイス所有者のプロビジョニング要件の更新。
リビジョンを見る
android.software.device_admin
を宣言する場合、デバイス実装は:- [C-1-1] 以下で説明するように、デバイス ポリシー クライアント(DPC)をデバイス所有者アプリとして登録することをサポートしなければなりません。
- デバイス実装にユーザーもユーザー データも構成されていない場合、次のようになります。
- [C-1-5] デバイスが機能を介して近距離無線通信 (NFC) のサポートを宣言している場合、DPC アプリをデバイス オーナー アプリとして登録するか、DPC アプリがデバイス オーナーになるかプロファイル オーナーになるかを選択できるようにしなければなりません
android.hardware.nfc
にフラグを付け、MIME タイプMIME_TYPE_PROVISIONING_NFC
のレコードを含む NFC メッセージを受信します。 - [C-1-8]
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
の値に応じて、 DPC アプリがデバイス オーナーになるかプロファイル オーナーになるかを選択できるように、デバイス オーナーのプロビジョニングがトリガーされた後にACTION_GET_PROVISIONING_MODE インテントを送信しなければなりません。コンテキストから、有効なオプションが 1 つしかないことがわかります。(プロファイル所有者のプロビジョニングがサポートされていない NFC ベースのプロビジョニングなど)。 - [C-1-9] プロビジョニング中にデバイス オーナーが確立された場合、使用されるプロビジョニング方法に関係なく、 ACTION_ADMIN_POLICY_COMPLIANCEインテントをデバイス オーナー アプリに送信しなければなりません。デバイス所有者アプリが終了するまで、ユーザーはセットアップ ウィザードを続行できません。
- [C-1-5] デバイスが機能を介して近距離無線通信 (NFC) のサポートを宣言している場合、DPC アプリをデバイス オーナー アプリとして登録するか、DPC アプリがデバイス オーナーになるかプロファイル オーナーになるかを選択できるようにしなければなりません
- デバイス実装にユーザーまたはユーザー データがある場合、次のようになります。
- [C-1-7] DPC アプリケーションをデバイス オーナー アプリとして登録してはなりません。
- デバイス実装にユーザーもユーザー データも構成されていない場合、次のようになります。
- [C-1-2] アプリをデバイス所有者として設定する前に、適切な開示通知 ( AOSP で参照されているものなど)を表示し、エンド ユーザーから肯定的な同意を得なければなりません。画面上のエンドユーザーとの対話。
プロビジョニング プロセスの前または最中に、アプリがデバイス オーナーとして設定されることに同意するための肯定的なアクションが必要です。同意は、ユーザーの操作または何らかのプログラムによる手段によって行うことができますが、デバイス所有者のプロビジョニングが開始される前に、(AOSP で参照されているように) 適切な開示通知を表示する必要があります。また、デバイス所有者のプロビジョニングに (企業によって) 使用されるプログラムによるデバイス所有者の同意メカニズムは、企業以外で使用する Out-Of-Box Experience を妨げてはなりません。 [C-1-3] 同意をハードコーディングしたり、他のデバイス オーナー アプリの使用を妨げたりしてはなりません。
デバイス実装が
android.software.device_admin
を宣言するが、独自のデバイス所有者デバイス管理ソリューションを提供し、ソリューションで構成されたアプリケーションを、標準の Android DevicePolicyManager API によって認識される標準の「デバイス所有者」に「同等のデバイス所有者」として昇格させるメカニズムを提供し、次のことを行います。- [C-2-1] 宣伝されている特定のアプリが正当なエンタープライズ デバイス管理ソリューションに属し、独自のソリューションで「デバイス所有者」と同等の権利を持つように構成されていることを確認するプロセスを用意しなければなりません。
- [C-2-2] DPC アプリケーションを「デバイス所有者」として登録する前に、
android.app.action.PROVISION_MANAGED_DEVICE
によって開始されたフローと同じ AOSP デバイス所有者の同意開示を示さなければなりません。 - [C-2-3] 同意をハードコーディングしたり、他のデバイス オーナー アプリの使用を妨げたりしてはなりません。
MAY have user data on the device prior to enrolling the DPC application as "Device Owner".
- [C-1-1] 以下で説明するように、デバイス ポリシー クライアント(DPC)をデバイス所有者アプリとして登録することをサポートしなければなりません。
3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.
See revision
3.9.4 Device Policy Management Role Requirements
If device implementations report
android.software.device_admin
orandroid.software.managed_users
, then they:- [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting
config_devicePolicyManagement
to the package name. The package name MUST be followed by:
and the signing certificate unless the application is preloaded.
If a package name is not defined for
config_devicePolicyManagement
as described above:- [C-2-1] Device implementations MUST support provisioning without a device policy management role holder application ( AOSP provides a reference implementation ).
If a package name is defined for
config_devicePolicyManagement
as described above:- [C-3-1] The application MUST be installed on all profiles for a user .
- [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting
config_devicePolicyManagementUpdater
.
If a package name is defined for
config_devicePolicyManagementUpdater
as described above:- [C-4-1] The application MUST be preinstalled on the device.
- [C-4-2] The application MUST implement an intent filter which resolves
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
- [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting
3.18 Contacts : Adding information for new contacts.
See revision
Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.
If device implementations preload a contacts app, then the pre-loaded contacts app:
[C-2-1] MUST handle the intent
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.[C-2-2] MUST honor the default account setting when handling
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
for theContactsContracts.Contacts.CONTENT_TYPE
andContactsContract.RawContacts.CONTENT_TYPE
by initially selecting the account.
4. Application Packaging Compatibility
4. Application Packaging Compatibility : Updates to APK Signature Scheme version.
See revision
Device implementations:
[C-0-2] MUST support verifying “.apk” files using the APK Signature Scheme v3.1 , APK Signature Scheme v3 , APK Signature Scheme v2 and JAR signing .
[C-0-9] MUST support verifying .apk files using the APK Signature Scheme v4 and APK Signature Scheme v4.1 .
5. Multimedia Compatibility
5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.
See revision
If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the
android.media.MediaCodec
API, then the following MUST be supported:- [C-7-1] MUST be able to be configured by the application using the decoding with the key
KEY_MAX_OUTPUT_CHANNEL_COUNT
to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content. - [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the
KEY_CHANNEL_MASK
key, using theandroid.media.AudioFormat
constants (example:CHANNEL_OUT_5POINT1
).
If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:
- [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key
KEY_MAX_OUTPUT_CHANNEL_COUNT
to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content. - [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the
KEY_CHANNEL_MASK
key, using the android.media.AudioFormat constants (example:CHANNEL_OUT_5POINT1
).
- [C-7-1] MUST be able to be configured by the application using the decoding with the key
5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.
See revision
If device implementations declare
android.hardware.microphone
, they:[C-1-1] MUST allow capture of raw audio content with the following characteristics for any
AudioRecord
orAAudio
INPUT stream that is opened successfully. At a minimum, the following characteristics MUST be supported :- Format: Linear PCM, 16-bit
- Sampling rates: 8000, 11025, 16000, 44100, 48000 Hz
- Channels: Mono
- Audio Sources:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, orVOICE_PERFORMANCE
. This also applies to the equivalent Input Presets inAAudio
, for example,AAUDIO_INPUT_PRESET_CAMCORDER
. - [C-1-4] MUST honor the
MicrophoneInfo
API and properly fill in information for the available microphones on device accessible to the third-party applications via theAudioManager.getMicrophones()
API, for active AudioRecord usingMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, orVOICE_PERFORMANCE
.and the currently active microphones which are accessible to the third party applications via theAudioRecord.getActiveMicrophones()
andMediaRecorder.getActiveMicrophones()
APIs.
5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.
See revision
If device implementations declare
android.hardware.microphone
, they:- SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
- SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.
- SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.
See revision
5.4.6. Microphone Gain Levels [Moved to 5.4.2]
If device implementations declare
android.hardware.microphone
, they:- SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
5.5.4 Audio Offload : Updates to the audio offload playback requirements.
See revision
If device implementations support audio offload playback , they:
- [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.
5.6 Audio Latency : Updates to the audio latency requirements.
See revision
For the purposes of this section, use the following definitions:
- cold output jitter . The variability among separate measurements of cold output latency values.
- cold input jitter . The variability among separate measurements of cold input latency values.
If device implementations declare
android.hardware.audio.output
, they MUST meet or exceed the following requirements:- [C-1-2] Cold output latency of 500 milliseconds or less.
- [C-1-3] Opening an output stream using
AAudioStreamBuilder_openStream()
MUST take less than 1000 milliseconds.
If device implementations declare
android.hardware.audio.output
they are STRONGLY RECOMMENDED to meet or exceed the following requirements:- [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path.
Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST. [C-SR] Minimize the cold output jitter.
If device implementations include
android.hardware.microphone
, they MUST meet these input audio requirements:- [C-3-2] Cold input latency of 500 milliseconds or less.
- [C-3-3] Opening an input stream using
AAudioStreamBuilder_openStream()
MUST take less than 1000 milliseconds.
If device implementations include
android.hardware.microphone
, they are STRONGLY RECOMMENDED to meet these input audio requirements:- [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path.
Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.
- [C-SR] Continuous input latency of 30 milliseconds or less.
- [C-SR] Minimize the cold input jitter.
5.10 Professional Audio : Updates to audio latency requirements for professional audio support.
See revision
If device implementations report support for feature
android.hardware.audio.pro
via the android.content.pm.PackageManager class, they:- [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less
and SHOULD be 10 milliseconds or lessover at least one supported path. - [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
- [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.
If device implementations include a 4 conductor 3.5mm audio jack, they:
- [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .
- [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less
5.12 HDR Video : Added a new section for HDR Video requirements.
6. Developer Tools and Options Compatibility
6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.
See revision
If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:
- [C-4-1] MUST have the
AdbManager#isAdbWifiSupported()
method returntrue
.
If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:
- [C-5-1] MUST have the
AdbManager#isAdbWifiQrSupported()
method returntrue
.
GPU work information
Device implementations:
- [C-6-1] MUST implement the shell command
dumpsys gpu --gpuwork
to display the aggregated GPU work data returned by thepower/gpu_work_period
kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation isframeworks/native/services/gpuservice/gpuwork/
.
- [C-6-1] MUST implement the shell command
- [C-4-1] MUST have the
7. Hardware Compatibility
7.1.4.1 OpenGL ES : Update to recommended extensions.
See revision
If device implementations support any of the OpenGL ES versions, they:
- SHOULD support the
EGL_IMG_context_priority
andEGL_EXT_protected_content
extensions.
- SHOULD support the
7.1.4.2 Vulkan : Updates to version supported for Vulkan.
See revision
If device implementations support OpenGL ES 3.1, they:
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
Vulkan 1.1 - MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).
If device implementations include a screen or video output, they:
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
Vulkan 1.1
If device implementations include support for Vulkan 1.0 or higher, they:
- SHOULD support
VkPhysicalDeviceProtectedMemoryFeatures
andVK_EXT_global_priority
. - [C-1-12] MUST NOT enumerate support for the
VK_KHR_performance_query
extension. - [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
7.2.3 Navigation Keys :
See revision
Device implementations:
- [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.
If the back navigation function is provided and the user cancels the Back gesture, then:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
MUST be called. - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
MUST NOT be called. - [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.
If the back navigation function is provided but the foreground application does NOT have an
OnBackInvokedCallback
registered, then:- The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.
If device implementations provide support for the system API
setNavBarMode
to allow any system app withandroid.permission.STATUS_BAR
permission to set the navigation bar mode, then they:- [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.
7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.
See revision
If device implementations include an accelerometer,
a 3-axis accelerometer,they:[C-1-2] MUST implement and reportTYPE_ACCELEROMETER
sensor.[SR] are STRONGLY RECOMMENDED to implement theTYPE_SIGNIFICANT_MOTION
composite sensor.[SR] are STRONGLY RECOMMENDED to implement and reportTYPE_ACCELEROMETER_UNCALIBRATED
sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.SHOULD implement theTYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors as described in the Android SDK document.
If device implementations include a 3-axis accelerometer, they:
- [C-2-1] MUST implement and report
TYPE_ACCELEROMETER
sensor. - [C-SR] Are STRONGLY RECOMMENDED to implement the
TYPE_SIGNIFICANT_MOTION
composite sensor. - [C-SR] Are STRONGLY RECOMMENDED to implement and report
TYPE_ACCELEROMETER_UNCALIBRATED
sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED. - SHOULD implement the
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors as described in the Android SDK document.
If device implementations include an accelerometer with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_ACCELEROMETER_LIMITED_AXES
sensor. - [C-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
sensor.
If device implementations include a 3-axis accelerometer and any of the
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors are implemented:- [C-4-1] The sum of their power consumption MUST always be less than 4 mW.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors.
If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:
- [C-6-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.
See revision
If device implementations include a gyroscope, they:
- [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
- [C-1-4] MUST have a resolution of 12-bits or more.
- [C-1-5] MUST be temperature compensated.
- [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
- [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
- [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
- [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
- SHOULD report events up to at least 200 Hz.
If device implementations include a 3-axis gyroscope, they:
- [C-2-1] MUST implement the
TYPE_GYROSCOPE
sensor.
If device implementations include a gyroscope with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_GYROSCOPE_LIMITED_AXES
sensor. - [C-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
sensor.
If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:
- [C-4-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors.
7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.
See revision
Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 .
Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:
- [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.
If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:
- [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .
If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:
- [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .
7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.
See revision
7.3.13. IEEE 802.1.15.4 (UWB)
If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:
- [C-1-1] MUST implement the corresponding Android API in android.uwb.
- [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
- [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
- [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
- [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
- [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .
7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.
See revision
If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:
- [C-3-1] MUST declare the
android.hardware.telephony.euicc
feature flag.provide a complete implementation of theEuiccManager API
.
If device implementations include GSM or CDMA telephony, then:
- [C-6-1] The
SmsManager#sendTextMessage
andSmsManager#sendMultipartTextMessage
MUST result in corresponding calls toCarrierMessagingService
for providing text messaging functionality.SmsManager#sendMultimediaMessage
andSmsManager#downloadMultimediaMessage
MUST result in corresponding calls toCarrierMessagingService
for providing multimedia messaging functionality. - [C-6-2] The application designated by
android.provider.Telephony.Sms#getDefaultSmsPackage
MUST use SmsManager APIs when sending and receiving SMS and MMS messages. The AOSP reference implementation in packages/apps/Messaging meets this requirement. - [C-6-3] The application which responds to
Intent#ACTION_DIAL
MUST support entry of arbitrary dialer codes formatted as*#*#CODE#*#*
and trigger a correspondingTelephonyManager#ACTION_SECRET_CODE
broadcast. - [C-6-4] The application which responds to
Intent#ACTION_DIAL
MUST useVoicemailContract.Voicemails#TRANSCRIPTION
to display visual voicemail transcription to users if it supports visual voicemail transcriptions. - [C-6-5] MUST represent all SubscriptionInfo with equivalent group UUIDs as a single subscription in all user-visible affordances that display and control SIM card information. Examples of such affordances include settings interfaces that match
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
orEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] MUST NOT display or allow control of any SubscriptionInfo with a non-null group UUID and opportunistic bit in any user-visible affordances that allow configuration or control of SIM card settings.
If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:
- [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
- [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.
If device implementations include GSM or CDMA telephony, then:
- [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
- [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by
TelephonyManager#getCarrierServicePackageName
) automatically or without explicit user confirmation:- Revoke or limit network access
- Revoke permissions
- Restrict background or foreground app execution beyond the existing power management features included in AOSP
- Disable or uninstall the app
If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:
- [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.
If device implementations include GSM telephony but not CDMA telephony, they:
- [C-8-1] MUST NOT declare
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-8-2] MUST throw an
IllegalArgumentException
upon attempts to set any 3GPP2 network types in preferred or allowed network type bitmasks. - [C-8-3] MUST return an empty string from
TelephonyManager#getMeid
.
If the device implementations support eUICCs with multiple ports and profiles, they:
- [C-11-1] MUST declare the
android.hardware.telephony.euicc.mep
feature flag.
- [C-3-1] MUST declare the
7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.
See revision
If device implementations report the
android.hardware.telephony feature
, they:- [C-1-4] MUST NOT write to the platform call log provider for a blocked call.
- [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with
BLOCKED_TYPE
out of the default call log view in the pre-installed dialer app. - SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.
7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.
See revision
7.4.1.3. Cellular NAT-T Keepalive Offload
Device implementations:
- SHOULD include support for Cellular keepalive offload.
If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:
- [C-1-1] MUST support the SocketKeepAlive API.
- [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
- [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
- [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.
If device implementations do not include support for cellular keepalive offload, they:
- [C-2-1] MUST return ERROR_UNSUPPORTED.
7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.
See revision
If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:
- [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
- [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.
See revision
Device implementations:
- SHOULD include support for Wi-Fi keepalive offload.
If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:
- [C-1-1] MUST support the SocketKeepAlive API.
- [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
and at least one keepalive slot over cellular.If device implementations do not include support for Wi-Fi keepalive offload, they:
- [C-2-1] MUST return
ERROR_UNSUPPORTED
.
7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.
See revision
7.4.2.9 Trust On First Use (TOFU)
If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:
- [C-4-1] MUST provide the user an option to select to use TOFU.
7.4.3 Bluetooth : Update to Bluetooth requirements.
See revision
If device implementations support Bluetooth Audio profile, they:
- SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.
If device implementations return
true
for theBluetoothAdapter.isLeAudioSupported()
API, then they:- [C-7-1] MUST support unicast client.
- [C-7-2] MUST support 2M PHY.
- [C-7-3] MUST support LE Extended advertising.
- [C-7-4] MUST support at least 2 CIS connections in a CIG.
- [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
- [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.
If device implementations return
true
for theBluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, then they:- [C-8-1] MUST support at least 2 BIS links in a BIG.
- [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
- [C-8-3] MUST support LE Periodic advertising.
If device implementations return
true
for theBluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, then they:- [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
- [C-9-2] MUST support LE Periodic advertising.
If device implementations declare
FEATURE_BLUETOOTH_LE
, they:- [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
in line of sight environment. - [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
- [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction. - [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
Presence Calibration Requirementsで指定された測定セットアップ手順に従うことを強くお勧めします。
If device implementations support Bluetooth version 5.0, then they:
- [C-SR] Are STRONGLY RECOMMENDED to provide support for:
- LE 2M PHY
- LE Codec PHY
- LE Advertising Extension
- Periodic advertising
- At least 10 advertisement sets
- At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
- LE Link Layer Privacy
- A "resolving list" size of at least 8 entries
7.4.9 UWB : Added a requirements section for UWB hardware.
See revision
7.4.9. UWB
If device implementations report support for feature
android.hardware.uwb
via theandroid.content.pm.PackageManager
class, then they:- [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
- [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.
Presence Calibration Requirementsで指定された測定セットアップ手順に従うことを強くお勧めします。
7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.
See revision
If device implementations support HDR 10-bit output capability, then they:
- [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
- [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
- [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
- [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.
For Logical camera devices which support 10-bit HDR that implement the
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API, they:- [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the
CONTROL_ZOOM_RATIO
control on the logical camera.
7.7.2 USB Host Mode : Revisions for dual role ports.
See revision
If device implementations include a USB port supporting host mode and USB Type-C, they:
- [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.
7.11 Media Performance Class : Updated to include Android T.
See revision
If device implementations return non-zero value for
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, they:- [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .
In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.
See section 2.2.7 for device-specific requirements.
9. Security Model Compatibility
9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.
See revision
- [C-0-2] Permissions with a
protectionLevel
ofPROTECTION_FLAG_PRIVILEGED
MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in theetc/permissions/
path and using thesystem/priv-app
path as the privileged path.
- [C-0-2] Permissions with a
9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.
See revision
Kernel integrity and self-protection features are integral to Android security. Device implementations:
- [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
CONFIG_INIT_STACK_ALL
orCONFIG_INIT_STACK_ALL_ZERO
). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.
- [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.
See revision
Device implementations:
- [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the
ClipboardManager
API) unless the 3rd-party app is the default IME or is the app that currently has focus. - [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.
- [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the
9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.
See revision
When the device implementation supports a secure lock screen, it:
- [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Secure isolation MUST block all potential mechanisms by which kernel or userspace code might access the internal state of the isolated environment, including DMA. The upstream Android Open Source Project (AOSP) meets this requirement by using the Trusty implementation, but another ARM TrustZone-based solution or a third-party reviewed secure implementation of a proper hypervisor-based isolation are alternative options.
9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.
See revision
If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:
- [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.
If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via
VirtualDeviceManager
, they:- [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.
If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:
- [C-10-1] MUST support separate lock states per virtual device
- [C-10-2] MUST disconnect all virtual devices upon idle timeout
- [C-10-3] MUST have an idle timeout
- [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
- [C-10-5] MUST have separate virtual device instances per user
- [C-10-6] MUST disable the creation of associated input events via
VirtualDeviceManager
when indicated byDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
- [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
- [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
- [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See
KeyGenParameterSpec.Builder.setUserAuthentication*
.
When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:
- [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
- [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
- [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.
If device implementations have a secure lock screen and include one or more trust agents, which call the
TrustAgentService.grantTrust()
System API with theFLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
flag they:- [C-12-1] MUST only call
grantTrust()
with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement. - [C-12-2] MUST put the device implementation into the
TrustState.TRUSTABLE
state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement. - [C-12-3] MUST only move the device from
TrustState.TRUSTABLE
to theTrustState.TRUSTED
state if the TrustAgent is still granting trust based on the requirements in C-12-1. - [C-12-4] MUST call
TrustManagerService.revokeTrust()
after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.
If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
- [C-13-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
- [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
- [C-13-10] MUST disable installation of apps initiated from virtual devices.
9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.
See revision
To validate compliance with [C-1-3] through [C-1-9], device implementations:
- [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).
9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.
See revision
The Identity Credential System is defined and achieved by implementing all APIs in the
android.security.identity.*
package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.
9.11.4 ID Attestation : Added a section for ID attestation requirement.
See revision
9.11.4. ID Attestation
Device implementations MUST support ID attestation .
9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.
See revision
9.17. Android Virtualization Framework
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine.*
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines.
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then any Protected Virtual Machine instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
- [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
- [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
- [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
- [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
- [C-3-2] MUST wipe a page after it is used by a VM and before it is returned to the host (eg the pVM is destroyed).
- [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
- [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST support Isolated Compilation of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.
- [C-1-1] MUST support all the APIs defined by the
Android 13
October 19, 2022
2. Device Types
See revision
ハンドヘルド デバイスの実装がロック タスク モードで実行されていない場合、コンテンツがクリップボードにコピーされると:
- [3.8.17/H-1-1] MUST present a confirmation to the user that data has been copied to the clipboard (eg, a thumbnail or alert of “Content copied.”). Additionally, include here an indication if clipboard data will be synced across devices.
3. Software
3.2.3.5. Conditional Application Intents
See revision
If device implementation's Settings application implements a split functionality , using activity embedding, then they:
- [C-17-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
and it MUST start the activity of the Intent parsed from Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI .
If device implementations support the
VoiceInteractionService
and have more than one application using this API installed at a time, they:- [C-18-1] MUST honor the
android.settings.ACTION_VOICE_INPUT_SETTINGS
intent to show a default app settings menu for voice input and assist.
- [C-17-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by
See revision
- [C-1-4] MUST render the' provided content or remote URL content in a process that is distinct from the application that instantiates the WebView. Specifically the separate renderer process MUST hold lower privilege, run as a separate user ID, have no access to the app's data directory, have no direct network access, and only have access to the minimum-required system services over Binder. The AOSP implementation of WebView meets this requirement.
7. Hardware Compatibility
See revision
If device implementations include support for Wi-Fi power save mode as defined in IEEE 802.11 standard, they:
[C-3-1] MUSTSHOULD turn off Wi-Fi power save mode whenever an app acquiresWIFI_MODE_FULL_HIGH_PERF
lock orWIFI_MODE_FULL_LOW_LATENCY
lock viaWifiManager.createWifiLock()
andWifiManager.WifiLock.acquire()
See revision
If device implementations include support for Bluetooth Low Energy (BLE), they:
- [C-3-5] MUST implement a Resolvable Private Address (RPA) timeout no longer than 15 minutes and rotate the address at timeout to protect user privacy when device is actively using BLE for scanning or advertising. To prevent timing attacks, timeout intervals MUST also be randomized between 5 and 15 minutes.
7.5.5 Camera Orientation
See revision
If device implementations have a front- or a rear-facing camera, such camera(s):
- [C-1-1] MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.
Devices that fulfill all of the following criteria are exempt from the requirement above:- The device implements variable-geometry screens, such as foldable or hinged displays.
- When the device's fold or hinge state changes, the device switches between portrait-primary to landscape-primary (or vice-versa) orientations.
9. Security Model Compatibility
See revision
When the device implementation supports a secure lock screen, it:
- [C-1-6] MUST support IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice version 1 or IKeyMintDevice version 2.
9.17 Android Virtualization Framework
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:[C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then any Protected Virtual Machine instance:[C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-2] MUST do DICE properly ie provide the correct values.
But it might not have to go to that level of detail.
August 15, 2022
2. Device Types
2.2.1 Hardware : Changes to hardware requirements as follows.
Input devices:
See revision
ハンドヘルド デバイスの実装:
- [ 7.2 .3/H-0-5] MUST call
OnBackInvokedCallback.onBackStarted()
on the current focused window when the back gesture starts or the back button (KEYCODE_BACK
) is pressed DOWN. - [ 7.2 .3/H-0-6] バック ジェスチャがコミットされたとき、または [戻る] ボタンが離された (UP) ときに
OnBackInvokedCallback.onBackInvoked()
を呼び出さなければなりません。 - [ 7.2 .3/H-0-7] MUST call
OnBackInvokedCallback.onBackCancelled()
when the back gesture is not committed or theKEYCODE_BACK
event is canceled.
PackageManager.FEATURE_WIFI_AWARE
を宣言して WiFi Neighbor Awareness Networking (NAN) プロトコルをサポートし、PackageManager.FEATURE_WIFI_RTT
を宣言して Wi-Fi ロケーション (Wi-Fi ラウンドトリップ時間 — RTT) をサポートする場合、デバイスは:[ 7.4 .2.5/H-1-1] 68 パーセンタイル (累積分布関数で計算) で 160 MHz 帯域幅で ±1 メートル以内、80 MHz 帯域幅で ±2 メートル以内の範囲で範囲を正確に報告しなければなりません。 68 パーセンタイルでは 40 MHz 帯域幅で +/-4 メートル、68 パーセンタイルでは 20 MHz 帯域幅で +/-8 メートル、10 cm、1 m、3 m、および 5 m の距離で、 WifiRttManager#startRanging Android APIを介して観察されます。
[ 7.4 .2.5/H-SR] Are STRONGLY RECOMMENDED to report the range accurately to within +/-1 meter at 160 MHz bandwidth at the 90th percentile (as calculated with the Cumulative Distribution Function), +/-2 meters at 80 MHz bandwidth at the 90th percentile, +/-4 meters at 40 MHz bandwidth at the 90th percentile, and +/-8 meters at 20 MHz bandwidth at the 90th percentile at distances of 10 cm, as observed via the WifiRttManager#startRanging Android API .
Presence Calibration Requirementsで指定された測定セットアップ手順に従うことを強くお勧めします。
- [ 7.2 .3/H-0-5] MUST call
Audio latency:
See revision
ハンドヘルド デバイスの実装で
android.hardware.audio.output
とandroid.hardware.microphone
を宣言する場合:- [ 5.6 /H-1-1] MUST have a Mean Continuous Round-Trip latency of 500
800milliseconds or less over 5 measurements, with a Mean Absolute Deviation less than 50100ms, over the following data paths: "speaker to microphone", 3.5 mm loopback adapter (if supported), USB loopback (if supported).at least one supported path.
- [ 5.6 /H-1-1] MUST have an average Tap-to-tone latency of 500 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
- [ 5.6 /H-1-1] MUST have a Mean Continuous Round-Trip latency of 500
Haptic inputs:
See revision
少なくとも 1 つの触覚アクチュエータが含まれる場合、ハンドヘルド デバイス実装は:
- [ 7.10 /H]* 偏心回転質量 (ERM) 触覚アクチュエータ (バイブレータ) を使用すべきではありません。
- [ 7.10 /H]* アクチュエータの配置は、デバイスが通常手で保持または触れる場所の近くに配置する必要があります。
- [ 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_START) で、明確な触覚のすべての公開定数を実装する必要があります。
- [ 7.10 /H]* SHOULD implement all public constants for clear haptics in android.os.VibrationEffect namely (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK and EFFECT_DOUBLE_CLICK) and all feasible public
PRIMITIVE_*
constants for rich haptics in android.os.VibrationEffect.Composition namely(PRIMITIVE_CLICK and PRIMITIVE_TICK)(CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Some of these primitives, such as LOW_TICK and SPIN may only be feasible if the vibrator can support relatively low frequencies.
- [7.10/H]* android.view.HapticFeedbackConstantsのパブリック定数を推奨されるandroid.os.VibrationEffect定数にマッピングするためのガイダンスに従うべきであり、対応する振幅関係があります。
- [ 7.10 /H]* public android.os.Vibrator.hasAmplitudeControl() API の結果がバイブレーターの機能を正しく反映していることを確認する必要があります。
- [ 7.10 /H]* SHOULD verify the capabilities for amplitude scalability by running android.os.Vibrator.hasAmplitudeControl() .
ハンドヘルド デバイス実装に少なくとも 1 つの線形共振アクチュエータが含まれる場合、それらは:
[ 7.10 /H]* SHOULD move the haptic actuator in the X-axis (left-right) of portrait orientation.
[ 7.10 /H]* SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
[7.10/H]* SHOULD provide fallback support to mitigate the risk of failure as described here .
Auth Trivial Device Cotntrols:
See revision
- [ 3.8 .16/H-1-5] MUST provide a user affordance to opt out of app designated auth-trivial device controls from the controls registered by the third-party applications through the
ControlsProviderService
and theControl
Control.isAuthRequired
API.
- [ 3.8 .16/H-1-5] MUST provide a user affordance to opt out of app designated auth-trivial device controls from the controls registered by the third-party applications through the
MediaStyle Notifications:
See revision
ハンドヘルド デバイス実装がMediaStyle 通知をサポートする場合、それらは:
- [3.8.3.1/H-1-SR] Are STRONGLY RECOMMENDED to provide a user affordance(eg “output switcher”) accessed from system UI that allows users to switch among appropriate available media routes(eg bluetooth devices and routes provided to MediaRouter2Manager ) when an app posts a MediaStyle notification with a MediaSession token .
2.2.4 Performance and Power : New requirement for apps that run foreground services.
See revision
ハンドヘルド デバイスの実装:
- [ 8.5 /H-0-1] MUST provide a user affordance in the Settings menu with the ability to stop an app that is running a foreground service and display all apps that have active foreground services and the duration of each of these services since it started as described in the SDK document .
- Some apps MAY be exempted from being stopped or being listed in such a user affordance as described in the SDK document .
- [ 8.5 /H-0-1] MUST provide a user affordance in the Settings menu with the ability to stop an app that is running a foreground service and display all apps that have active foreground services and the duration of each of these services since it started as described in the SDK document .
2.2.7.1 Media : Updates to the Handheld Requirements Media section as follows:
See revision
If Handheld device implementations return
android.os.Build.VERSION_CODES.T
forandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, then they:- [5.1/H-1-1] MUST advertise the maximum number of hardware video decoder sessions that can be run concurrently in any codec combination via the
CodecCapabilities.getMaxSupportedInstances()
andVideoCapabilities.getSupportedPerformancePoints()
methods. - [5.1/H-1-2] MUST support 6 instances of hardware video decoder sessions (AVC, HEVC, VP9, AV1 or later) in any codec combination running concurrently at 1080p resolution@30 fps.
- [5.1/H-1-3] MUST advertise the maximum number of hardware video encoder sessions that can be run concurrently in any codec combination via the
CodecCapabilities.getMaxSupportedInstances()
andVideoCapabilities.getSupportedPerformancePoints()
methods. - [5.1/H-1-4] MUST support 6 instances of hardware video encoder sessions (AVC, HEVC, VP9, AV1 or later) in any codec combination running concurrently at 1080p resolution@30fps.
- [5.1/H-1-5] MUST advertise the maximum number of hardware video encoder and decoder sessions that can be run concurrently in any codec combination via the
CodecCapabilities.getMaxSupportedInstances()
andVideoCapabilities.getSupportedPerformancePoints()
methods. - [5.1/H-1-6] MUST support 6 instances of hardware video decoder and hardware video encoder sessions (AVC, HEVC, VP9, AV1 or later) in any codec combination running concurrently at 1080p@30fps resolution.
- [5.1/H-1-7] MUST have a codec initialization latency of 40 ms or less for a 1080p or smaller video encoding session for all hardware video encoders when under load. Load here is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs together with the 1080p audio-video recording initialization.
- [5.1/H-1-8] MUST have a codec initialization latency of 30 ms or less for a 128 kbps or lower bitrate audio encoding session for all audio encoders when under load. Load here is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs together with the 1080p audio-video recording initialization.
- [5.1/H-1-9] MUST support 2 instances of secure hardware video decoder sessions (AVC, HEVC, VP9, AV1 or later) in any codec combination running concurrently at 1080p resolution@30 fps.
- [5.1/H-1-10] MUST support 3 instances of non-secure hardware video decoder sessions together with 1 instance of secure hardware video decoder session (4 instances total) (AVC, HEVC, VP9, AV1 or later) in any codec combination running concurrently at 1080p resolution@30fps.
- [5.1/ H-1-11] MUST support a secure decoder for every hardware AVC, HEVC, VP9 or AV1 decoder on the device.
- [5.1/H-1-12] MUST have a video decoder initialization latency of 40 ms or less.
- [5.1/H-1-13] MUST have an audio decoder initialization latency of 30 ms or less.
- [5.1/H-1-14] MUST support AV1 hardware decoder Main 10, Level 4.1.
- [5.1/H-SR] Are Strongly Recommended to support Film Grain for AV1 hardware decoder.
- [5.1/H-1-15] MUST have at least 1 hardware video decoder supporting 4K60.
- [5.1/H-1-16] MUST have at least 1 hardware video encoder supporting 4K60.
- [5.3/H-1-1] MUST NOT drop more than 1 frame in 10 seconds (ie less than 0.167 percent frame drop) for a 1080p 60 fps video session under load. Load is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs, as well as a 128 kbps AAC audio playback.
- [5.3/H-1-2] MUST NOT drop more than 1 frame in 10 seconds during a video resolution change in a 60 fps video session under load. Load is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs, as well as a 128 kbps AAC audio playback.
- [5.6/H-1-1] MUST have a tap-to-tone latency of 80 milliseconds or less using the OboeTester tap-to-tone test or CTS Verifier tap-to-tone test.
- [5.6/H-1-2] MUST have a round-trip audio latency of 80 milliseconds or less over at least one supported data path.
- [5.6/H-1-3] MUST support >=24-bit audio for stereo output over 3.5 mm audio jacks if present and over USB audio if supported through the entire data path for low latency and streaming configurations. For the low latency configuration, AAudio should be used by the app in low-latency callback mode. For the streaming configuration, a Java AudioTrack should be used by the app. In both the low latency and streaming configurations, the HAL output sink should accept either
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
orAUDIO_FORMAT_PCM_FLOAT
for its target output format. - [5.6/H-1-4] MUST support >=4 channel USB audio devices (This is used by DJ controllers for previewing songs.)
- [5.6/H-1-5] MUST support class compliant MIDI devices and declare the MIDI feature flag.
- [5.7/H-1-2] MUST support
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
with the below content decryption capabilities.
Minimum Sample size 4 MiB Minimum Number of Subsamples - H264 or HEVC 32 Minimum Number of Subsamples - VP9 9 Minimum Number of Subsamples - AV1 288 Minimum subsample buffer size 1 MiB Minimum Generic crypto buffer size 500 KiB Minimum Number of concurrent sessions 30 Minimum Number of keys per session 20 Minimum Total Number of Keys (all sessions) 80 Minimum Total Number of DRM Keys (all sessions) 6 Message Size 16 KiB Decrypted Frames per Second 60 fps - [5.1/H-1-1] MUST advertise the maximum number of hardware video decoder sessions that can be run concurrently in any codec combination via the
2.2.7.2 Camera : Updates to the Media Performance Class Camera requirements.
See revision
If Handheld device implementations return
android.os.Build.VERSION_CODES.T
forandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, then they:- [7.5/H-1-1] MUST have a primary rear facing camera with a resolution of at least 12 megapixels supporting video capture at 4k@30fps. The primary rear-facing camera is the rear-facing camera with the lowest camera ID.
- [7.5/H-1-2] MUST have a primary front facing camera with a resolution of at least 5 megapixels and support video capture at 1080p@30fps. The primary front-facing camera is the front-facing camera with the lowest camera ID.
- [7.5/H-1-3] MUST support
android.info.supportedHardwareLevel
property asFULL
or better for both primary cameras. - [7.5/H-1-4] MUST support
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
for both primary cameras. - [7.5/H-1-5] MUST have camera2 JPEG capture latency < 1000 ms for 1080p resolution as measured by the CTS camera PerformanceTest under ITS lighting conditions (3000K) for both primary cameras.
- [7.5/H-1-6] MUST have camera2 startup latency (open camera to first preview frame) < 500 ms as measured by the CTS camera PerformanceTest under ITS lighting conditions (3000K) for both primary cameras.
- [7.5/H-1-8] MUST support
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
andandroid.graphics.ImageFormat.RAW_SENSOR
for the primary back camera. - [7.5/H-1-9] MUST have a rear-facing primary camera supporting 720p or 1080p @ 240fps.
- [7.5/H-1-10] MUST have min ZOOM_RATIO < 1.0 for the primary cameras if there is an ultrawide RGB camera facing the same direction.
- [7.5/H-1-11] MUST implement concurrent front-back streaming on primary cameras.
- [7.5/H-1-12] MUST support
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
for both primary front and primary back camera. - [7.5/H-1-13] MUST support
LOGICAL_MULTI_CAMERA
capability for the primary cameras if there are greater than 1 RGB cameras facing the same direction. - [7.5/H-1-14] MUST support
STREAM_USE_CASE
capability for both primary front and primary back camera.
2.2.7.3 Hardware : Updates to the Media Performance Class requirements for Hardware.
See revision
If Handheld device implementations return
android.os.Build.VERSION_CODES.T
forandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, then they:- [7.1.1.1/H-2-1] MUST have screen resolution of at least 1080p.
- [7.1.1.3/H-2-1] MUST have screen density of at least 400 dpi.
- [7.6.1/H-2-1] MUST have at least 8 GB of physical memory.
2.2.7.4 Performance : Updates to the Media Performance Class for Performance.
See revision
If Handheld device implementations return
android.os.Build.VERSION_CODES.T
forandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, then they:- [8.2/H-1-1] MUST ensure a sequential write performance of at least 125 MB/s.
- [8.2/H-1-2] MUST ensure a random write performance of at least 10 MB/s.
- [8.2/H-1-3] MUST ensure a sequential read performance of at least 250 MB/s.
- [8.2/H-1-4] MUST ensure a random read performance of at least 40 MB/s.
2.5.1 Hardware : Updates to the 3-axis accelerometer and 3-axis gyroscope requirements, as well as the exterior-view camera requirements.
See revision
Automotive device implementations:
- [ 7.3 .1/A-0-4] MUST comply with the Android car sensor coordinate system .
- [ 7.3 /A-SR] Are STRONGLY_RECOMMENDED to include a 3-axis accelerometer and 3-axis gyroscope.
- [ 7.3 /A-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_HEADING
sensor.
If Automotive device implementations include an accelerometer, they:
- [ 7.3 .1/A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
If device implementations include a 3-axis accelerometer, they:
- [ 7.3 .1/A-SR] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes accelerometer.
If Automotive device implementations include an accelerometer with less than 3 axes, they:
- [ 7.3 .1/A-1-3] MUST implement and report
TYPE_ACCELEROMETER_LIMITED_AXES
sensor. - [ 7.3 .1/A-1-4] MUST implement and report
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
sensor.
If Automotive device implementations include a gyroscope, they:
- [ 7.3 .4/A-2-1] MUST be able to report events up to a frequency of at least 100 Hz.
- [ 7.3 .4/A-2-3] MUST be capable of measuring orientation changes up to 250 degrees per second.
- [ 7.3 .4/A-SR] Are STRONGLY RECOMMENDED to configure the gyroscope's measurement range to +/-250dps in order to maximize the resolution possible.
If Automotive device implementations include a 3-axis gyroscope, they:
- [ 7.3 .4/A-SR] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes gyroscope.
If Automotive device implementations include a gyroscope with less than 3-axes, they:
- [ 7.3 .4/A-4-1] MUST implement and report
TYPE_GYROSCOPE_LIMITED_AXES
sensor. - [ 7.3 .4/A-4-2] MUST implement and report
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
sensor.
If automotive device implementations include a
TYPE_HEADING
sensor, they:- [ 7.3 .4/A-4-3] MUST be able to report events up to a frequency of at least 1 Hz.
- [ 7.3 .4/A-SR] STRONGLY_RECOMMENDED to report events up to a frequency of at least 10 Hz.
- SHOULD be in reference to true north.
- SHOULD be available even when the vehicle is still.
- SHOULD have a resolution of at least 1 degree.
An exterior view camera is a camera that images scenes outside of the device implementation, like the rearview camera
a dashcam.If Automotive device implementations include an exterior view camera, for such a camera, they:
[ 7.5 .5/A-SR] Are STRONGLY RECOMMENDED to be oriented so that the long dimension of the camera aligns with the horizon.SHOULD support Android synchronization framework .MAY have either hardware auto-focus or software auto-focus implemented in the camera driver.
If automotive device implementations include one or more exterior view cameras, and load Exterior View System (EVS) service, then for such a camera, they:
- [ 7.5 /A-2-1] MUST NOT rotate or horizontally mirror the camera preview.
Automotive device implementations:
- MAY include one or more cameras that are available to third party applications.
If automotive device implementations include at least one camera and make it available to third party applications then, they:
- [ 7.5 /A-3-1] MUST report the feature flag
android.hardware.camera.any
. - [ 7.5 /A-3-2] MUST not declare the camera as a system camera .
- MAY support external cameras described in section 7.5.3 .
- MAY include features (such as auto-focus, etc.) available to rear-facing cameras as described in section 7.5.1 .
2.5.5 Security Model : New requirements for camera permissions for automotive devices.
See revision
If Automotive device implementations declare
android.hardware.camera.any
, then they:[ 9.8.2 /A-2-1] MUST display the camera indicator when an app is accessing live camera data, but not when the camera is only being accessed by app(s) holding the roles called out in Section 9.1 Permissions with CDD identifier [C-3-X].
[ 9.8.2 /A-2-2] MUST not hide the camera indicator for system apps that have visible user interfaces or direct user interaction.
2.6.1 Tablet Requirements — Hardware : Update to tablet screen size requirements.
See revision
An Android Tablet device refers to an Android device implementation that typically meets all the following criteria:
- Has a screen display size greater than 7” and less than 18", measured diagonally.
Screen Size
- [ 7.1 .1.1/Tab-0-1] MUST have a screen in the range of 7 to 18 inches.
3. Software
3.2.2 Build Parameters : Updated ASCII characters in
getSerial()
.See revision
- [C-0-1] To provide consistent, meaningful values across device implementations, the table below includes additional restrictions on the formats of these values to which device implementations MUST conform.
Parameter Details getSerial() MUST (be or return) a hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9]+$” . 3.2.3.5 Conditional Application Intents : Update to requirements for conditional application intents.
See revision
If device implementations include a large display (generally having display width and height of 600dp+) and supports split functionality , then they:
- [C-17-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
and it MUST start the activity of the Intent parsed from Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI .
- [C-17-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by
3.5.1 Application Restriction : Updates to application restrictions.
See revision
If device implementations implement a proprietary mechanism to restrict apps (eg changing or restricting API behaviors that are described in the SDK) and that mechanism is more restrictive than the Restricted App Standby Bucket , they:
- [C-1-1] MUST allow the user to see the list of restricted apps.
- [C-1-2] MUST provide user affordance to turn on / off all of these proprietary restrictions on each app.
- [C-1-3] MUST not automatically apply these proprietary restrictions without evidence of poor system health behavior, but MAY apply the restrictions on apps upon detection of poor system health behavior like stuck wakelocks, long running services, and other criteria. The criteria MAY be determined by device implementers but MUST be related to the app's impact on the system health. Other criteria that are not purely related to the system health, such as the app's lack of popularity in the market, MUST NOT be used as criteria.
- [C-1-4] MUST not automatically apply these proprietary restrictions for apps when a user has turned off app restrictions manually, and MAY suggest the user to apply these proprietary restrictions.
[C-1-5] MUST inform users if these proprietary restrictions are applied to an app automatically. Such information MUST be provided in the 24-hour period preceding the application of these proprietary restrictions.
[C-1-6] MUST return true for the ActivityManager.isBackgroundRestricted() method for any API calls from an app.
[C-1-7] MUST NOT restrict the top foreground app that is explicitly used by the user.
[C-1-8] MUST suspend these proprietary restrictions on an app whenever a user starts to explicitly use the app, making it the top foreground application.
[C-1-9] MUST report all these proprietary restrictions events via UsageStats.
[C-1-10] MUST provide a public and clear document or website that describes how proprietary restrictions are applied. This document or website MUST be linkable from the Android SDK documents and MUST include:
- Triggering conditions for proprietary restrictions.
- What and how an app can be restricted.
- How an app can be exempted from such restrictions.
- How an app can request an exemption from proprietary restrictions, if they support such an exemption for apps the user can install.
If an app is pre-installed on the device and has never been explicitly used by a user for more than 30 days, [C-1-3] [C-1-5] are exempted.
3.8.1 Launcher (Home Screen) : Updates to support for
monochrome/adaptive-icon
.See revision
If device implementations support monochrome icons, these icons:
- [C-6-1] MUST be used only when a user explicitly enables them (eg via Settings or wallpaper picker menu).
3.8.2 Widgets : Update to third-party app widget presence in the Launcher.
See revision
If device implementations support third-party app widgets, they:
- [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets
directly within the Launcher.
- [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets
3.8.3.1 Presentation of Notifications : Clarifying the definition of heads-up notifications.
See revision
Heads up notifications are notifications that are presented to the user as they come in independently of the surface the user is on.
3.8.3.3 DND (Do not Disturb) / Priority Mode : Update to include Priority Mode in DND (Do Not Disturb) requirements.
See revision
3.8.3.3. DND (Do not Disturb) / Priority Mode
If device implementations support the DND feature (also called Priority Mode), they:
3.8.6 Themes : New requirements for dynamic color tonal palettes.
See revision
If device implementations include a screen or video output, they:
[C-1-4] MUST generate dynamic color tonal palettes as specified in the AOSP documentation of
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(seeandroid.theme.customization.system_palette
andandroid.theme.customization.theme_style
).[C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
documentation (seeandroid.theme.customization.theme_styles
), namelyTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
."Source color" used to generate dynamic color tonal palettes when sent with
android.theme.customization.system_palette
(as documented inSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] MUST have a
CAM16
chroma value of 5 or larger.SHOULD be derived from the wallpaper via
com.android.systemui.monet.ColorScheme#getSeedColors
, which provides multiple valid source colors to pick one from.SHOULD use the value
0xFF1B6EF3
, if none of the provided colors meet the above source color requirement.
3.8.17 Clipboard : Added new requirements section for content on the clipboard.
See revision
3.8.17. Clipboard
Device implementations:
- [C-0-1] MUST NOT send clipboard data to any component, activity, service, or across any network connection, without explicit user action (eg, pressing a button on the overlay), except for services mentioned in 9.8.6 Content Capture and App Search .
If device implementations generate a user-visible preview when content is copied to the clipboard for any
ClipData
item whereClipData.getDescription().getExtras()
containsandroid.content.extra.IS_SENSITIVE
, they:- [C-1-1] MUST redact the user visible preview
The AOSP reference implementation satisfies these clipboard requirements.
3.9.1.1 Device Owner Provisioning : Updates to device owner provisioning requirements.
See revision
If device implementations declare
android.software.device_admin
, they:- [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:
- When the device implementation has neither users nor user data configured, it:
- [C-1-5] MUST enroll the DPC application as the Device Owner app or enable the DPC app to choose whether to become a Device Owner or a Profile Owner, if the device declares Near-Field Communications (NFC) support via the feature flag
android.hardware.nfc
and receives an NFC message containing a record with MIME typeMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] MUST send the ACTION_GET_PROVISIONING_MODE intent after device owner provisioning is triggered so that the DPC app can choose whether to become a Device Owner or a Profile Owner, depending on the values of
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, unless it can be determined from context that there is only one valid option.(such as for NFC based provisioning where Profile Owner provisioning is not supported). - [C-1-9] MUST send the ACTION_ADMIN_POLICY_COMPLIANCE intent to the Device Owner app if a Device Owner is established during provisioning regardless of the provisioning method used. The user must not be able to proceed in the Setup Wizard until the Device Owner app finishes.
- [C-1-5] MUST enroll the DPC application as the Device Owner app or enable the DPC app to choose whether to become a Device Owner or a Profile Owner, if the device declares Near-Field Communications (NFC) support via the feature flag
- When the device implementation has users or user data, it:
- [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.
- When the device implementation has neither users nor user data configured, it:
- [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP ) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for retail demo mode prior to on-screen, end-user interaction.
require some affirmative action before or during the provisioning process to consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use. [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
If device implementations declare
android.software.device_admin
, but also include a proprietaryDevice Ownerdevice management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:- [C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and has been configured in the proprietary solution to have the rights equivalent as a "Device Owner".
- [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by
android.app.action.PROVISION_MANAGED_DEVICE
prior to enrolling the DPC application as "Device Owner". - [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
MAY have user data on the device prior to enrolling the DPC application as "Device Owner".
- [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:
3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.
See revision
3.9.4 Device Policy Management Role Requirements
If device implementations report
android.software.device_admin
orandroid.software.managed_users
, then they:- [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting
config_devicePolicyManagement
to the package name. The package name MUST be followed by:
and the signing certificate unless the application is preloaded.
If a package name is not defined for
config_devicePolicyManagement
as described above:- [C-2-1] Device implementations MUST support provisioning without a device policy management role holder application ( AOSP provides a reference implementation ).
If a package name is defined for
config_devicePolicyManagement
as described above:- [C-3-1] The application MUST be installed on all profiles for a user .
- [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting
config_devicePolicyManagementUpdater
.
If a package name is defined for
config_devicePolicyManagementUpdater
as described above:- [C-4-1] The application MUST be preinstalled on the device.
- [C-4-2] The application MUST implement an intent filter which resolves
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
- [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting
3.18 Contacts : Adding information for new contacts.
See revision
Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.
If device implementations preload a contacts app, then the pre-loaded contacts app:
[C-2-1] MUST handle the intent
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.[C-2-2] MUST honor the default account setting when handling
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
for theContactsContracts.Contacts.CONTENT_TYPE
andContactsContract.RawContacts.CONTENT_TYPE
by initially selecting the account.
4. Application Packaging Compatibility
4. Application Packaging Compatibility : Updates to APK Signature Scheme version.
See revision
Device implementations:
[C-0-2] MUST support verifying “.apk” files using the APK Signature Scheme v3.1 , APK Signature Scheme v3 , APK Signature Scheme v2 and JAR signing .
[C-0-9] MUST support verifying .apk files using the APK Signature Scheme v4 and APK Signature Scheme v4.1 .
5. Multimedia Compatibility
5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.
See revision
If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the
android.media.MediaCodec
API, then the following MUST be supported:- [C-7-1] MUST be able to be configured by the application using the decoding with the key
KEY_MAX_OUTPUT_CHANNEL_COUNT
to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content. - [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the
KEY_CHANNEL_MASK
key, using theandroid.media.AudioFormat
constants (example:CHANNEL_OUT_5POINT1
).
If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:
- [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key
KEY_MAX_OUTPUT_CHANNEL_COUNT
to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content. - [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the
KEY_CHANNEL_MASK
key, using the android.media.AudioFormat constants (example:CHANNEL_OUT_5POINT1
).
- [C-7-1] MUST be able to be configured by the application using the decoding with the key
5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.
See revision
If device implementations declare
android.hardware.microphone
, they:[C-1-1] MUST allow capture of raw audio content with the following characteristics for any
AudioRecord
orAAudio
INPUT stream that is opened successfully. At a minimum, the following characteristics MUST be supported :- Format: Linear PCM, 16-bit
- Sampling rates: 8000, 11025, 16000, 44100, 48000 Hz
- Channels: Mono
- Audio Sources:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, orVOICE_PERFORMANCE
. This also applies to the equivalent Input Presets inAAudio
, for example,AAUDIO_INPUT_PRESET_CAMCORDER
. - [C-1-4] MUST honor the
MicrophoneInfo
API and properly fill in information for the available microphones on device accessible to the third-party applications via theAudioManager.getMicrophones()
API, for active AudioRecord usingMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, orVOICE_PERFORMANCE
.and the currently active microphones which are accessible to the third party applications via theAudioRecord.getActiveMicrophones()
andMediaRecorder.getActiveMicrophones()
APIs.
5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.
See revision
If device implementations declare
android.hardware.microphone
, they:- SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
- SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.
- SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.
See revision
5.4.6. Microphone Gain Levels [Moved to 5.4.2]
If device implementations declare
android.hardware.microphone
, they:- SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
5.5.4 Audio Offload : Updates to the audio offload playback requirements.
See revision
If device implementations support audio offload playback , they:
- [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.
5.6 Audio Latency : Updates to the audio latency requirements.
See revision
For the purposes of this section, use the following definitions:
- cold output jitter . The variability among separate measurements of cold output latency values.
- cold input jitter . The variability among separate measurements of cold input latency values.
If device implementations declare
android.hardware.audio.output
, they MUST meet or exceed the following requirements:- [C-1-2] Cold output latency of 500 milliseconds or less.
- [C-1-3] Opening an output stream using
AAudioStreamBuilder_openStream()
MUST take less than 1000 milliseconds.
If device implementations declare
android.hardware.audio.output
they are STRONGLY RECOMMENDED to meet or exceed the following requirements:- [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path.
Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST. [C-SR] Minimize the cold output jitter.
If device implementations include
android.hardware.microphone
, they MUST meet these input audio requirements:- [C-3-2] Cold input latency of 500 milliseconds or less.
- [C-3-3] Opening an input stream using
AAudioStreamBuilder_openStream()
MUST take less than 1000 milliseconds.
If device implementations include
android.hardware.microphone
, they are STRONGLY RECOMMENDED to meet these input audio requirements:- [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path.
Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.
- [C-SR] Continuous input latency of 30 milliseconds or less.
- [C-SR] Minimize the cold input jitter.
5.10 Professional Audio : Updates to audio latency requirements for professional audio support.
See revision
If device implementations report support for feature
android.hardware.audio.pro
via the android.content.pm.PackageManager class, they:- [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less
and SHOULD be 10 milliseconds or lessover at least one supported path. - [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
- [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.
If device implementations include a 4 conductor 3.5mm audio jack, they:
- [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .
- [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less
5.12 HDR Video : Added a new section for HDR Video requirements.
6. Developer Tools and Options Compatibility
6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.
See revision
If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:
- [C-4-1] MUST have the
AdbManager#isAdbWifiSupported()
method returntrue
.
If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:
- [C-5-1] MUST have the
AdbManager#isAdbWifiQrSupported()
method returntrue
.
GPU work information
Device implementations:
- [C-6-1] MUST implement the shell command
dumpsys gpu --gpuwork
to display the aggregated GPU work data returned by thepower/gpu_work_period
kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation isframeworks/native/services/gpuservice/gpuwork/
.
- [C-6-1] MUST implement the shell command
- [C-4-1] MUST have the
7. Hardware Compatibility
7.1.4.1 OpenGL ES : Update to recommended extensions.
See revision
If device implementations support any of the OpenGL ES versions, they:
- SHOULD support the
EGL_IMG_context_priority
andEGL_EXT_protected_content
extensions.
- SHOULD support the
7.1.4.2 Vulkan : Updates to version supported for Vulkan.
See revision
If device implementations support OpenGL ES 3.1, they:
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
Vulkan 1.1 - MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).
If device implementations include a screen or video output, they:
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
Vulkan 1.1
If device implementations include support for Vulkan 1.0 or higher, they:
- SHOULD support
VkPhysicalDeviceProtectedMemoryFeatures
andVK_EXT_global_priority
. - [C-1-12] MUST NOT enumerate support for the
VK_KHR_performance_query
extension. - [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
7.2.3 Navigation Keys :
See revision
Device implementations:
- [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.
If the back navigation function is provided and the user cancels the Back gesture, then:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
MUST be called. - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
MUST NOT be called. - [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.
If the back navigation function is provided but the foreground application does NOT have an
OnBackInvokedCallback
registered, then:- The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.
If device implementations provide support for the system API
setNavBarMode
to allow any system app withandroid.permission.STATUS_BAR
permission to set the navigation bar mode, then they:- [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.
7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.
See revision
If device implementations include an accelerometer,
a 3-axis accelerometer,they:[C-1-2] MUST implement and reportTYPE_ACCELEROMETER
sensor.[SR] are STRONGLY RECOMMENDED to implement theTYPE_SIGNIFICANT_MOTION
composite sensor.[SR] are STRONGLY RECOMMENDED to implement and reportTYPE_ACCELEROMETER_UNCALIBRATED
sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.SHOULD implement theTYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors as described in the Android SDK document.
If device implementations include a 3-axis accelerometer, they:
- [C-2-1] MUST implement and report
TYPE_ACCELEROMETER
sensor. - [C-SR] Are STRONGLY RECOMMENDED to implement the
TYPE_SIGNIFICANT_MOTION
composite sensor. - [C-SR] Are STRONGLY RECOMMENDED to implement and report
TYPE_ACCELEROMETER_UNCALIBRATED
sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED. - SHOULD implement the
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors as described in the Android SDK document.
If device implementations include an accelerometer with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_ACCELEROMETER_LIMITED_AXES
sensor. - [C-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
sensor.
If device implementations include a 3-axis accelerometer and any of the
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors are implemented:- [C-4-1] The sum of their power consumption MUST always be less than 4 mW.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors.
If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:
- [C-6-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.
See revision
If device implementations include a gyroscope, they:
- [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
- [C-1-4] MUST have a resolution of 12-bits or more.
- [C-1-5] MUST be temperature compensated.
- [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
- [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
- [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
- [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
- SHOULD report events up to at least 200 Hz.
If device implementations include a 3-axis gyroscope, they:
- [C-2-1] MUST implement the
TYPE_GYROSCOPE
sensor.
If device implementations include a gyroscope with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_GYROSCOPE_LIMITED_AXES
sensor. - [C-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
sensor.
If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:
- [C-4-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors.
7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.
See revision
Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 .
Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:
- [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.
If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:
- [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .
If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:
- [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .
7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.
See revision
7.3.13. IEEE 802.1.15.4 (UWB)
If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:
- [C-1-1] MUST implement the corresponding Android API in android.uwb.
- [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
- [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
- [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
- [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
- [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .
7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.
See revision
If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:
- [C-3-1] MUST declare the
android.hardware.telephony.euicc
feature flag.provide a complete implementation of theEuiccManager API
.
If device implementations include GSM or CDMA telephony, then:
- [C-6-1] The
SmsManager#sendTextMessage
andSmsManager#sendMultipartTextMessage
MUST result in corresponding calls toCarrierMessagingService
for providing text messaging functionality.SmsManager#sendMultimediaMessage
andSmsManager#downloadMultimediaMessage
MUST result in corresponding calls toCarrierMessagingService
for providing multimedia messaging functionality. - [C-6-2] The application designated by
android.provider.Telephony.Sms#getDefaultSmsPackage
MUST use SmsManager APIs when sending and receiving SMS and MMS messages. The AOSP reference implementation in packages/apps/Messaging meets this requirement. - [C-6-3] The application which responds to
Intent#ACTION_DIAL
MUST support entry of arbitrary dialer codes formatted as*#*#CODE#*#*
and trigger a correspondingTelephonyManager#ACTION_SECRET_CODE
broadcast. - [C-6-4] The application which responds to
Intent#ACTION_DIAL
MUST useVoicemailContract.Voicemails#TRANSCRIPTION
to display visual voicemail transcription to users if it supports visual voicemail transcriptions. - [C-6-5] MUST represent all SubscriptionInfo with equivalent group UUIDs as a single subscription in all user-visible affordances that display and control SIM card information. Examples of such affordances include settings interfaces that match
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
orEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] MUST NOT display or allow control of any SubscriptionInfo with a non-null group UUID and opportunistic bit in any user-visible affordances that allow configuration or control of SIM card settings.
If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:
- [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
- [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.
If device implementations include GSM or CDMA telephony, then:
- [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
- [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by
TelephonyManager#getCarrierServicePackageName
) automatically or without explicit user confirmation:- Revoke or limit network access
- Revoke permissions
- Restrict background or foreground app execution beyond the existing power management features included in AOSP
- Disable or uninstall the app
If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:
- [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.
If device implementations include GSM telephony but not CDMA telephony, they:
- [C-8-1] MUST NOT declare
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-8-2] MUST throw an
IllegalArgumentException
upon attempts to set any 3GPP2 network types in preferred or allowed network type bitmasks. - [C-8-3] MUST return an empty string from
TelephonyManager#getMeid
.
If the device implementations support eUICCs with multiple ports and profiles, they:
- [C-11-1] MUST declare the
android.hardware.telephony.euicc.mep
feature flag.
- [C-3-1] MUST declare the
7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.
See revision
If device implementations report the
android.hardware.telephony feature
, they:- [C-1-4] MUST NOT write to the platform call log provider for a blocked call.
- [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with
BLOCKED_TYPE
out of the default call log view in the pre-installed dialer app. - SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.
7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.
See revision
7.4.1.3. Cellular NAT-T Keepalive Offload
Device implementations:
- SHOULD include support for Cellular keepalive offload.
If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:
- [C-1-1] MUST support the SocketKeepAlive API.
- [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
- [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
- [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.
If device implementations do not include support for cellular keepalive offload, they:
- [C-2-1] MUST return ERROR_UNSUPPORTED.
7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.
See revision
If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:
- [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
- [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.
See revision
Device implementations:
- SHOULD include support for Wi-Fi keepalive offload.
If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:
- [C-1-1] MUST support the SocketKeepAlive API.
- [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
and at least one keepalive slot over cellular.If device implementations do not include support for Wi-Fi keepalive offload, they:
- [C-2-1] MUST return
ERROR_UNSUPPORTED
.
7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.
See revision
7.4.2.9 Trust On First Use (TOFU)
If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:
- [C-4-1] MUST provide the user an option to select to use TOFU.
7.4.3 Bluetooth : Update to Bluetooth requirements.
See revision
If device implementations support Bluetooth Audio profile, they:
- SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.
If device implementations return
true
for theBluetoothAdapter.isLeAudioSupported()
API, then they:- [C-7-1] MUST support unicast client.
- [C-7-2] MUST support 2M PHY.
- [C-7-3] MUST support LE Extended advertising.
- [C-7-4] MUST support at least 2 CIS connections in a CIG.
- [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
- [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.
If device implementations return
true
for theBluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, then they:- [C-8-1] MUST support at least 2 BIS links in a BIG.
- [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
- [C-8-3] MUST support LE Periodic advertising.
If device implementations return
true
for theBluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, then they:- [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
- [C-9-2] MUST support LE Periodic advertising.
If device implementations declare
FEATURE_BLUETOOTH_LE
, they:- [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
in line of sight environment. - [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
- [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction. - [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
Presence Calibration Requirementsで指定された測定セットアップ手順に従うことを強くお勧めします。
If device implementations support Bluetooth version 5.0, then they:
- [C-SR] Are STRONGLY RECOMMENDED to provide support for:
- LE 2M PHY
- LE Codec PHY
- LE Advertising Extension
- Periodic advertising
- At least 10 advertisement sets
- At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
- LE Link Layer Privacy
- A "resolving list" size of at least 8 entries
7.4.9 UWB : Added a requirements section for UWB hardware.
See revision
7.4.9. UWB
If device implementations report support for feature
android.hardware.uwb
via theandroid.content.pm.PackageManager
class, then they:- [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
- [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.
Presence Calibration Requirementsで指定された測定セットアップ手順に従うことを強くお勧めします。
7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.
See revision
If device implementations support HDR 10-bit output capability, then they:
- [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
- [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
- [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
- [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.
For Logical camera devices which support 10-bit HDR that implement the
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API, they:- [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the
CONTROL_ZOOM_RATIO
control on the logical camera.
7.7.2 USB Host Mode : Revisions for dual role ports.
See revision
If device implementations include a USB port supporting host mode and USB Type-C, they:
- [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.
7.11 Media Performance Class : Updated to include Android T.
See revision
If device implementations return non-zero value for
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, they:- [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .
In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.
See section 2.2.7 for device-specific requirements.
9. Security Model Compatibility
9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.
See revision
- [C-0-2] Permissions with a
protectionLevel
ofPROTECTION_FLAG_PRIVILEGED
MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in theetc/permissions/
path and using thesystem/priv-app
path as the privileged path.
- [C-0-2] Permissions with a
9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.
See revision
Kernel integrity and self-protection features are integral to Android security. Device implementations:
- [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
CONFIG_INIT_STACK_ALL
orCONFIG_INIT_STACK_ALL_ZERO
). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.
- [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.
See revision
Device implementations:
- [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the
ClipboardManager
API) unless the 3rd-party app is the default IME or is the app that currently has focus. - [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.
- [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the
9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.
See revision
When the device implementation supports a secure lock screen, it:
- [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Secure isolation MUST block all potential mechanisms by which kernel or userspace code might access the internal state of the isolated environment, including DMA. The upstream Android Open Source Project (AOSP) meets this requirement by using the Trusty implementation, but another ARM TrustZone-based solution or a third-party reviewed secure implementation of a proper hypervisor-based isolation are alternative options.
9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.
See revision
If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:
- [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.
If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via
VirtualDeviceManager
, they:- [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.
If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:
- [C-10-1] MUST support separate lock states per virtual device
- [C-10-2] MUST disconnect all virtual devices upon idle timeout
- [C-10-3] MUST have an idle timeout
- [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
- [C-10-5] MUST have separate virtual device instances per user
- [C-10-6] MUST disable the creation of associated input events via
VirtualDeviceManager
when indicated byDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
- [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
- [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
- [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See
KeyGenParameterSpec.Builder.setUserAuthentication*
.
When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:
- [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
- [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
- [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.
If device implementations have a secure lock screen and include one or more trust agents, which call the
TrustAgentService.grantTrust()
System API with theFLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
flag they:- [C-12-1] MUST only call
grantTrust()
with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement. - [C-12-2] MUST put the device implementation into the
TrustState.TRUSTABLE
state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement. - [C-12-3] MUST only move the device from
TrustState.TRUSTABLE
to theTrustState.TRUSTED
state if the TrustAgent is still granting trust based on the requirements in C-12-1. - [C-12-4] MUST call
TrustManagerService.revokeTrust()
after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.
If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
- [C-13-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
- [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
- [C-13-10] MUST disable installation of apps initiated from virtual devices.
9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.
See revision
To validate compliance with [C-1-3] through [C-1-9], device implementations:
- [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).
9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.
See revision
The Identity Credential System is defined and achieved by implementing all APIs in the
android.security.identity.*
package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.
9.11.4 ID Attestation : Added a section for ID attestation requirement.
See revision
9.11.4. ID Attestation
Device implementations MUST support ID attestation .
9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.
See revision
9.17. Android Virtualization Framework
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine.*
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines.
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then any Protected Virtual Machine instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
- [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
- [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
- [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
- [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
- [C-3-2] MUST wipe a page after it is used by a VM and before it is returned to the host (eg the pVM is destroyed).
- [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
- [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST support Isolated Compilation of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.
- [C-1-1] MUST support all the APIs defined by the
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2022-12-12 UTC.
[{ "type": "thumb-down", "id": "missingTheInformationINeed", "label":"必要な情報がない" },{ "type": "thumb-down", "id": "tooComplicatedTooManySteps", "label":"複雑すぎる / 手順が多すぎる" },{ "type": "thumb-down", "id": "outOfDate", "label":"最新ではない" },{ "type": "thumb-down", "id": "translationIssue", "label":"翻訳に関する問題" },{ "type": "thumb-down", "id": "samplesCodeIssue", "label":"サンプル / コードに問題がある" },{ "type": "thumb-down", "id": "otherDown", "label":"その他" }] [{ "type": "thumb-up", "id": "easyToUnderstand", "label":"わかりやすい" },{ "type": "thumb-up", "id": "solvedMyProblem", "label":"問題の解決に役立った" },{ "type": "thumb-up", "id": "otherUp", "label":"その他" }] - [C-2-1] MUST return
- [C-2-1] MUST return