Android 互換性定義ドキュメントの変更履歴

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

Android 13

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 を宣言して Wi-Fi Neighbor Awareness Networking(NAN)プロトコルをサポートしている場合や、PackageManager.FEATURE_WIFI_RTT を宣言して Wi-Fi Location(Wi-Fi ラウンドトリップ時間 - RTT)をサポートしている場合、それらのデバイスは:

      • [7.4.2.5/H-1-1] WifiRttManager#startRanging Android API を介して確認した 10 cm、1 m、3 m、5 m の距離における範囲を、累積分布関数で計算し、帯域幅 160 MHz では 68 パーセンタイルで正確度 +/-1 メートル以内、80 MHz 帯域幅では 68 パーセンタイルで正確度 +/-2 メートル以内、40 MHz 帯域幅では 68 パーセンタイルで正確度 +/-4 メートル以内、20 MHz 帯域幅では 68 パーセンタイルで正確度 +/-8 メートル以内でレポートしなければなりません。

      • [7.4.2.5/H-SR] WifiRttManager#startRanging Android API を介して確認した 10 cm の距離における範囲を、累積分布関数で計算し、帯域幅 160 MHz では 90 パーセンタイルで正確度 +/-1 メートル以内、80 MHz 帯域幅では 90 パーセンタイルで正確度 +/-2 メートル以内、40 MHz 帯域幅では 90 パーセンタイルで正確度 +/-4 メートル以内、20 MHz 帯域幅では 90 パーセンタイルで正確度 +/-8 メートル以内でレポートすることが強く推奨されます。

      プレゼンス キャリブレーションの要件で指定されている測定の設定手順に従うことが強く推奨されます。

    • オーディオ レイテンシ:

      改訂を確認する

      android.hardware.audio.outputandroid.hardware.microphone を宣言する場合、ハンドヘルド デバイス実装は:

      • [5.6/H-1-1] 「スピーカーからマイク」、3.5 mm ループバック アダプター(サポートされている場合)、USB ループバック(サポートされている場合)のデータパスにおいて、5 回の測定での平均連続ラウンドトリップ レイテンシが 500 800 ミリ秒以下、平均絶対偏差が 50 100 ミリ秒未満でなければなりません。 少なくとも 1 つのサポート対象パスにおいて

      • [5.6/H-1-1] スピーカーからマイクへのデータパスで、少なくとも 5 回の測定での平均タップツートーン レイテンシが 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_END)をすべて実装すべきです。
      • [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]* これらリンクされたハプティクス定数のマッピングを使用すべきです。

      リニア共振アクチュエータが 1 つ以上含まれる場合、ハンドヘルド デバイス実装は:

      • [7.10/H]* 触覚アクチュエータを縦向き画面の X 軸(左右)で動かすべきです。

      • [7.10/H]* 定数の実装ガイダンスに記載されているとおり、サポートされていないプリミティブのフォールバック構成を検証し、必要に応じて更新すべきです。

      • [7.10/H]* こちらに記載されているとおり、失敗のリスクを軽減するためにフォールバック サポートを提供すべきです。

  • 2.2.3 ソフトウェア:

    • 認証が簡素化されたデバイスのコントロール:

      改訂を確認する

      • [3.8.16/H-1-5] ControlsProviderServiceControl Control.isAuthRequired API を通じてサードパーティ アプリによって登録されたコントロールから、アプリ指定の認証が簡素化されたデバイスのコントロールをオプトアウトするユーザー アフォーダンスを提供しなければなりません。

    • MediaStyle 通知:

      改訂を確認する

      MediaStyle 通知をサポートする場合、ハンドヘルド デバイス実装は:

      • [3.8.3.1/H-1-SR] MediaSession トークンを含む MediaStyle 通知をアプリが送信したときに、使用できる適切なメディアルート間(例: Bluetooth デバイスや MediaRouter2Manager に提供されるルート)での切り替えをユーザーができるようにする、システム UI からアクセスできるユーザー アフォーダンス(「出力スイッチャー」)を提供することが強く推奨されます。

  • 2.2.4 パフォーマンスと電力: フォアグラウンド サービスを実行するアプリの新しい要件。

    改訂を確認する

    ハンドヘルド デバイス実装は:

    • [8.5/H-0-1] SDK のドキュメントに記載されているとおり、設定メニューで、フォアグラウンド サービスを実行しているアプリを停止できるユーザー アフォーダンスを提供しなければなりません。また、アクティブなフォアグラウンド サービスを持つすべてのアプリを、アプリの各サービスが開始されてからの継続期間とともに表示しなければなりません。
      • 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、30 fps で同時に実行される任意のコーデックの組み合わせで、ハードウェア動画エンコーダ セッション(AVC、HEVC、VP9、AV1 以降)の 6 つのインスタンスをサポートしなければなりません。
    • [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() メソッドと VideoCapabilities.getSupportedPerformancePoints() メソッドを介して、任意のコーデックの組み合わせで同時に実行できるハードウェア動画エンコーダ セッションとハードウェア動画デコーダ セッションの最大数をアドバタイズしなければなりません。
    • [5.1/H-1-6] 解像度 1080p、30 fps で同時に実行される任意のコーデックの組み合わせで、ハードウェア動画デコーダ セッションとハードウェア動画エンコーダ セッション(AVC、HEVC、VP9、AV1 以降)の 6 つのインスタンスをサポートしなければなりません。
    • [5.1/H-1-7] 負荷がかかった状態で、すべてのハードウェア動画エンコーダの 1080p 以下の動画エンコード セッションについて、コーデック初期化レイテンシが 40 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像記録の初期化を同時実行することを指します。
    • [5.1/H-1-8] 負荷がかかった状態で、すべての音声エンコーダでのビットレート 128 kbps 以下の音声エンコード セッションについて、コーデック初期化レイテンシが 30 ms 以下でなければなりません。ここでいう負荷とは、ハードウェア動画コーデックを使用した 1080p から 720p への映像のみのコード変換セッションと、1080p の音声映像記録の初期化を同時実行することを指します。
    • [5.1/H-1-9] 解像度 1080p、30 fps で同時に実行されるコーデックの組み合わせで、セキュアなハードウェア動画デコーダ セッション(AVC、HEVC、VP9、AV1 以降)の 2 つのインスタンスをサポートしなければなりません。
    • [5.1/H-1-10] 解像度 1080p、30 fps で同時に実行される任意のコーデックの組み合わせで、セキュアでないハードウェア動画デコーダ セッションの 3 つのインスタンスと、セキュアなハードウェア動画デコーダ セッション(AVC、HEVC、VP9、AV1 以降)の 1 つのインスタンス(合計 4 つのインスタンス)をサポートしなければなりません。
    • [5.1/ H-1-11] デバイス上のすべてのハードウェア AVC、HEVC、VP9、または AV1 デコーダについて、セキュアなデコーダをサポートしなければなりません。
    • [5.1/H-1-12] 動画デコーダの初期化レイテンシが 40 ms 以下でなければなりません。
    • [5.1/H-1-13] オーディオ デコーダの初期化レイテンシが 30 ms 以下でなければなりません。
    • [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 検証ツールのタップツートーン テストを使用して、タップツートーン レイテンシを 80 ミリ秒以下にしなければなりません。
    • [5.6/H-1-2] 少なくとも 1 つのサポート対象データパスで、ラウンドトリップ オーディオ レイテンシを 80 ミリ秒以下にしなければなりません。
    • [5.6/H-1-3] 3.5 mm オーディオ ジャック(存在する場合)および USB オーディオ(サポートされる場合)のステレオ出力については、低レイテンシ構成およびストリーミング構成のデータパス全体を通じて 24 ビット以上をサポートしなければなりません。低レイテンシ構成の場合、アプリは AAudio を低レイテンシ コールバック モードで使用すべきです。ストリーミング構成の場合、アプリは Java AudioTrack を使用すべきです。低レイテンシ構成とストリーミング構成の両方で、HAL 出力シンクはターゲット出力形式として AUDIO_FORMAT_PCM_24_BITAUDIO_FORMAT_PCM_24_BIT_PACKEDAUDIO_FORMAT_PCM_32_BITAUDIO_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
    汎用暗号の最小バッファサイズ 500 KiB
    同時実行セッションの最小数 30
    セッションあたりの鍵の最小数 20
    鍵の最小合計数(すべてのセッション) 80
    DRM 鍵の最小合計数(すべてのセッション) 6
    メッセージ サイズ 16 KiB
    復号されたフレーム/秒 60 fps

  • 2.2.7.2 カメラ: メディア パフォーマンス クラスのカメラの要件を更新。

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS について android.os.Build.VERSION_CODES.T を返す場合、ハンドヘルド デバイス実装は:

    • [7.5/H-1-1] 4K、30 fps での動画キャプチャをサポートする、解像度 12 メガピクセル以上のプライマリ背面カメラがなければなりません。プライマリ背面カメラとは、カメラ ID が最も低い背面カメラのことです。
    • [7.5/H-1-2] 解像度 5 メガピクセル以上のプライマリ前面カメラがなければならず、1080p、30 fps での動画キャプチャをサポートしなければなりません。プライマリ前面カメラとは、カメラ ID が最も低い前面カメラのことです。
    • [7.5/H-1-3] 両方のプライマリ カメラについて、FULL 以上の android.info.supportedHardwareLevel プロパティをサポートしなければなりません。
    • [7.5/H-1-4] 両方のプライマリ カメラについて、CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME をサポートしなければなりません。
    • [7.5/H-1-5] 両方のプライマリ カメラについて、ITS 照明条件(3000K)で CTS カメラの PerformanceTest によって測定したとき、解像度 1080p の camera2 JPEG キャプチャ レイテンシが 1,000 ms 未満でなければなりません。
    • [7.5/H-1-6] 両方のプライマリ カメラについて、ITS 照明条件(3000K)で CTS カメラの PerformanceTest によって測定したとき、camera2 起動レイテンシ(カメラを開いてから最初のプレビュー フレームまで)が 500 ms 未満でなければなりません。
    • [7.5/H-1-8] プライマリ背面カメラについて、CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAWandroid.graphics.ImageFormat.RAW_SENSOR をサポートしなければなりません。
    • [7.5/H-1-9] 720p または 1080p、240 fps をサポートするプライマリ背面カメラがなければなりません。
    • [7.5/H-1-10] 同じ方向を向いたウルトラワイド RGB カメラが 1 つある場合、プライマリ カメラの最小 ZOOM_RATIO は 1.0 未満でなければなりません。
    • [7.5/H-1-11] プライマリ カメラに前面および背面での同時ストリーミングを実装しなければなりません。
    • [7.5/H-1-12] プライマリ前面カメラとプライマリ背面カメラの両方で CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION をサポートしなければなりません。
    • [7.5/H-1-13] 同じ方向を向いた RGB カメラが 1 つ以上ある場合、プライマリ カメラで LOGICAL_MULTI_CAMERA 機能をサポートしなければなりません。
    • [7.5/H-1-14] プライマリ前面カメラとプライマリ背面カメラの両方で STREAM_USE_CASE 機能をサポートしなければなりません。

  • 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/s のシーケンシャル書き込みパフォーマンスを実現しなければなりません。
    • [8.2/H-1-2] 少なくとも 10 MB/s のランダム書き込みパフォーマンスを実現しなければなりません。
    • [8.2/H-1-3] 少なくとも 250 MB/s のシーケンシャル読み取りパフォーマンスを実現しなければなりません。
    • [8.2/H-1-4] 少なくとも 40 MB/s のランダム読み取りパフォーマンスを実現しなければなりません。

  • 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 センサーを実装し、レポートしなければなりません。

    ジャイロスコープが含まれる場合、自動車デバイス実装は:

    • [7.3.4/A-2-1] 少なくとも周波数 100 Hz までのイベントをレポートできなければなりません。
    • [7.3.4/A-2-3] 250 度/秒までの方向変化を測定できなければなりません。
    • [7.3.4/A-SR] 解像度を可能な限り最大化するために、ジャイロスコープの測定範囲を +/-250 dps に設定することが強く推奨されます。

    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.3.4/A-4-3] 少なくとも周波数 1 Hz までのイベントをレポートできなければなりません。
    • [7.3.4/A-SR] 少なくとも周波数 10 Hz までのイベントをレポートすることが強く推奨されます。
    • 真北を指すべきです。
    • 車両が静止している間も利用できるべきです。
    • 解像度が少なくとも 1 度であるべきです。

    外部ビューカメラとは、リアビュー カメラドライブ レコーダーのように、デバイス実装の外部の光景を撮影するカメラのことです。

    外部ビューカメラが含まれる場合、そのようなカメラについて、自動車デバイス実装は:

    • [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 セキュリティ モデル: 自動車デバイスのカメラ権限に関する新しい要件。

    改訂を確認する

    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 以上)が含まれ、分割機能をサポートする場合、デバイス実装は:

  • 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] 独自の制限を適用する方法を説明する明確な公開ドキュメントまたはウェブサイトを提供しなければなりません。このドキュメントまたはウェブサイトは、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 の組み込みのサポートを含まなければならず、ランチャー内で直接 AppWidget を追加、設定、表示、削除するユーザー インターフェース アフォーダンスを公開しなければなりません。

  • 3.8.3.1 通知の表示: ヘッドアップ通知の定義を明確化。

    改訂を確認する

    ヘッドアップ通知は、ユーザーがどの画面を表示しているかに関係なく、発生したときにユーザーに提示される通知です。

  • 3.8.3.3 DND(サイレント モード)/ 優先モード: DND(サイレント モード)の要件に優先モードを含めるよう更新。

    改訂を確認する

    3.8.3.3. DND(サイレント モード)/ 優先モード

    DND 機能(優先モードともいいます)をサポートする場合、デバイス実装は:

  • 3.8.6 テーマ: 動的な色調パレットに関する新しい要件。

    改訂を確認する

    画面または動画出力が含まれる場合、デバイス実装は:

    • [C-1-4] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES の AOSP ドキュメント(android.theme.customization.system_paletteandroid.theme.customization.theme_style を参照)で指定されているとおり、動的な色調パレットを生成しなければなりません。

    • [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ドキュメント(android.theme.customization.theme_styles を参照)に記載されているカラーテーマ スタイル(すなわち TONAL_SPOTVIBRANTEXPRESSIVESPRITZRAINBOWFRUIT_SALAD)を使用して、動的な色調パレットを生成しなければなりません。

      「ソースカラー」は、Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES に記載されているとおり、android.theme.customization.system_palette で送信されるときに動的な色調パレットを生成するために使用されます。

    • [C-1-6] CAM16 彩度の値が 5 以上でなければなりません。

      • com.android.systemui.monet.ColorScheme#getSeedColors を介して壁紙から取得すべきです。これにより、複数の有効なソースカラーが提供され、そこから色を選択できます。

      • 提供された色のいずれも上記のソースカラーの要件を満たしていない場合、値 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] デバイスが機能フラグ android.hardware.nfc を介して近距離無線通信(NFC)のサポートを宣言し、MIME タイプ MIME_TYPE_PROVISIONING_NFC のレコードを含む NFC メッセージを受信した場合、DPC アプリをデバイス所有者アプリとして登録するか、DPC アプリがデバイス所有者とプロファイル所有者のどちらになるかを選択できるようにしなければなりません。
        • [C-1-8] android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES の値に応じて DPC アプリがデバイス所有者とプロファイル所有者のどちらになるかを選択できるように、デバイス所有者のプロビジョニングがトリガーされた後、ACTION_GET_PROVISIONING_MODE インテントを送信しなければなりません。ただし、有効なオプションが 1 つしかないことがコンテキストから判断できる場合(プロファイル所有者のプロビジョニングがサポートされていない NFC ベースのプロビジョニングの場合など)を除きます。
        • [C-1-9] 使用するプロビジョニング方法にかかわらず、プロビジョニング中にデバイス所有者が確定したら、デバイス所有者アプリに ACTION_ADMIN_POLICY_COMPLIANCE インテントを送信しなければなりません。デバイス所有者アプリが終了するまで、ユーザーが設定ウィザードを続行できてはなりません。
      • ユーザーまたはユーザーデータがある場合、デバイス実装は:
        • [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] 同意をハードコードしたり、他のデバイス所有者アプリの使用を妨げたりしてはなりません。
    • DPC アプリを「デバイス所有者」として登録する前に、デバイス上にユーザーデータがあっても構いません。

  • 3.9.4 デバイス管理ロールの要件: デバイス管理ロールの要件に関するセクションを追加。

    改訂を確認する

    3.9.4 デバイス ポリシー管理ロールの要件

    android.software.device_admin または android.software.managed_users をレポートする場合、デバイス実装は:

    • [C-1-1] セクション 9.1 で定義されているとおり、デバイス ポリシー管理のロールをサポートしなければなりません。デバイス ポリシー管理ロールを保持するアプリは、config_devicePolicyManagement をパッケージ名に設定することで定義しても構いません。アプリがプリロードされていない限り、パッケージ名の後に : と署名証明書を付けなければなりません。

    config_devicePolicyManagement のパッケージ名が上記のように定義されていない場合:

    • [C-2-1] デバイス実装は、デバイス ポリシー管理のロールを保持するアプリなしでのプロビジョニングをサポートしなければなりません(AOSP がリファレンス実装を提供)。

    config_devicePolicyManagement のパッケージ名が上記のように定義されている場合:

    • [C-3-1] ユーザーのすべてのプロファイルに、アプリをインストールしなければなりません。
    • [C-3-2] デバイス実装は、config_devicePolicyManagementUpdater を設定することで、プロビジョニング前にデバイス ポリシー管理のロール保持者を更新するアプリを定義しても構いません。

    config_devicePolicyManagementUpdater のパッケージ名が上記のように定義されている場合:

    • [C-4-1] アプリをデバイスにプリインストールしなければなりません。
    • [C-4-2] アプリは、android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER を解決するインテント フィルタを実装しなければなりません。

  • 3.18 連絡先: 新しい連絡先の情報を追加。

    改訂を確認する

    新しい連絡先のデフォルト アカウント: 連絡先プロバイダは、新しい連絡先の作成時にデフォルト アカウントの設定を管理するための API を提供します。

    デバイス実装が連絡帳アプリをプリロードする場合、プリロードされた連絡帳アプリは:

    • [C-2-1] アカウント選択用の UI を起動し、アカウントの選択時に設定を連絡先プロバイダに保存するために、インテント ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT を処理しなければなりません。

    • [C-2-2] 最初にアカウントを選択することで、ContactsContracts.Contacts.CONTENT_TYPEContactsContract.RawContacts.CONTENT_TYPEIntent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT を処理するときに、デフォルトのアカウント設定を使用しなければなりません。

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

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

  • 5.1.2 オーディオ デコード: マルチチャンネル オーディオを出力できるデコーダの新しい要件を追加。

    改訂を確認する

    デバイス実装が、android.media.MediaCodec API のデフォルト AAC オーディオ デコーダを通じて PCM へのマルチチャンネル ストリーム(2 チャンネル以上)の AAC 入力バッファのデコードをサポートする場合、下記をサポートしなければなりません。

    • [C-7-1] コンテンツをステレオにダウンミックスするか(値 2 を使用する場合)ネイティブ チャンネル数を使用して出力するか(その数以上の値を使用する場合)を制御するために、鍵 KEY_MAX_OUTPUT_CHANNEL_COUNT によるデコードを使用してアプリで設定できなければなりません。たとえば、値を 6 以上に設定すると、5.1 のコンテンツを供給する際に 6 つのチャンネルを出力するようにデコーダを設定できます。
    • [C-7-2] デコーダはデコード時に、android.media.AudioFormat 定数(例: CHANNEL_OUT_5POINT1)を使用して、KEY_CHANNEL_MASK 鍵での出力形式で使用されるチャンネル マスクをアドバタイズしなければなりません。

    デバイス実装が、デフォルトの AAC オーディオ デコーダ以外のオーディオ デコーダをサポートし、圧縮されたマルチチャンネル コンテンツを供給する際にマルチチャンネル オーディオ(2 チャンネルを超えるオーディオ)を出力できる場合:

    • [C-SR] デコーダは、コンテンツをステレオにダウンミックスするか(値 2 を使用する場合)ネイティブ チャンネル数を使用して出力するか(その数以上の値を使用する場合)を制御するために、鍵 KEY_MAX_OUTPUT_CHANNEL_COUNT によるデコードを使用してアプリで設定できるようにすることを強く推奨します。たとえば、値を 6 以上に設定すると、5.1 のコンテンツを供給する際に 6 つのチャンネルを出力するようにデコーダを設定できます。
    • [C-SR] デコーダはデコード時に、android.media.AudioFormat 定数(例: CHANNEL_OUT_5POINT1)を使用して、KEY_CHANNEL_MASK 鍵での出力形式で使用されるチャンネル マスクをアドバタイズしなければなりません。

  • 5.4.1 未加工オーディオのキャプチャとマイク情報: オーディオ入力ストリームの、サポートされている音源を更新。

    改訂を確認する

    android.hardware.microphone を宣言する場合、デバイス実装は:

    • [C-1-1] 正常に開かれた AudioRecord または AAudio のすべての入力ストリームについて、次の特性を持つ未加工オーディオ コンテンツをキャプチャできるようにしなければなりません。少なくとも、次の特性をサポートしなければなりません。

  • 5.4.2 音声認識用のキャプチャ: 音声認識のオーディオ ストリームの要件を更新し、マイクのゲインレベルの要件を追加。

    改訂を確認する

    android.hardware.microphone を宣言する場合、デバイス実装は:

    • 振幅周波数特性がほぼ平坦(具体的には ±3 dB、100 Hz~4,000 Hz)になるように、音声認識のオーディオ ストリームを録音すべきです。
    • 1,000 Hz で音圧レベル(SPL)90 dB の音源が 16 ビットサンプルで RMS 2,500 になるように入力感度を設定して、音声認識のオーディオ ストリームを録音すべきです。

    • 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲でほぼ平坦な振幅周波数特性を示すべきです(具体的には ±3 dB、100 Hz~4,000 Hz)。
    • [C-SR] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して低い周波数範囲の振幅レベルを示すことが強く推奨されます(具体的には ±20 dB、30 Hz~100 Hz)。
    • [C-SR] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して高い周波数範囲の振幅レベルを示すことが強く推奨されます(具体的には ±30 dB、4,000 Hz~22 kHz)。
    • 音声認識の音源を録音するために使用する各マイクすべてについて、音圧レベル(SPL)90 dB で再生された 1,000 Hz 正弦波音源(マイクの隣で測定)が、16 ビットサンプルで RMS 1,770~3,530 の範囲のレスポンス(理想的には RMS 2,500)になるように(浮動小数点 / 倍精度サンプルの場合は -22.35 dB ±3dB フルスケール)、オーディオ入力感度を設定すべきです。

  • 5.4.6 マイクのゲインレベル: マイクのゲインレベルの要件がセクション 5.4.2 に移動されました。

    改訂を確認する

    5.4.6. マイクのゲインレベル [5.4.2 に移動]

    android.hardware.microphone を宣言する場合、デバイス実装は:

    • 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲でほぼ平坦な振幅周波数特性を示すべきです(具体的には ±3 dB、100 Hz~4,000 Hz)。
    • [C-SR] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して低い周波数範囲の振幅レベルを示すことが強く推奨されます(具体的には ±20 dB、5 Hz~100 Hz)。
    • [C-SR] 音声認識の音源を録音するために使用する各マイクすべてについて、中間周波数範囲と比較して高い周波数範囲の振幅レベルを示すことが強く推奨されます(具体的には ±30 dB、4,000 Hz~22 kHz)。
    • 音声認識の音源を録音するために使用する各マイクすべてについて、音圧レベル(SPL)90 dB で再生された 1,000 Hz 正弦波音源が、16 ビットサンプルで RMS 2,500 のレスポンスになるように(浮動小数点 / 倍精度サンプルの場合は -22.35 dB フルスケール)、オーディオ入力感度を設定すべきです。

  • 5.5.4 オーディオ オフロード: オーディオ オフロード再生の要件を更新。

    改訂を確認する

    オーディオ オフロード再生をサポートする場合、デバイス実装は:

    • [C-SR] AudioTrack gapless API と MediaPlayer のメディア コンテナで指定されている場合、再生されるギャップレス オーディオ コンテンツを、同じ形式の 2 つのクリップ間でトリミングすることが強く推奨されます。

  • 5.6 オーディオ レイテンシ: オーディオ レイテンシの要件を更新。

    改訂を確認する

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

    • コールド出力ジッター。コールド出力レイテンシ値の、個々の測定値間のばらつき。
    • コールド入力ジッター。コールド入力レイテンシ値の、個々の測定値間のばらつき。

    android.hardware.audio.output を宣言する場合、デバイス実装は、次の要件を満たすか上回らなければなりません。

    • [C-1-2] コールド出力レイテンシが 500 ミリ秒以下。
    • [C-1-3] AAudioStreamBuilder_openStream() を使用して出力ストリームを開くために要する時間が 1,000 ミリ秒未満でなければなりません。

    android.hardware.audio.output を宣言する場合、デバイス実装は、次の要件を満たすか上回ることが強く推奨されます。

    • [C-SR] スピーカー データパスでコールド出力レイテンシが 100 ミリ秒以下。このバージョンの Android を搭載した既存または新規のデバイスは現在、これらの要件を満たすことが極めて強く推奨されています。今後のプラットフォーム リリースでは、「しなければならない」として、コールド出力レイテンシ 200 ms 以下を要求する予定です。
    • [C-SR] コールド出力ジッターを最小限に抑える。

    android.hardware.microphone が含まれる場合、デバイス実装は下記の入力オーディオの要件を満たさなければなりません。

    • [C-3-2] コールド入力レイテンシが 500 ミリ秒以下。
    • [C-3-3] AAudioStreamBuilder_openStream() を使用して入力ストリームを開始するのに要する時間が 1,000 ミリ秒未満でなければなりません。

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

    • [C-SR] マイク データパスでコールド入力レイテンシが 100 ミリ秒以下。このバージョンの Android を搭載した既存または新規のデバイスは現在、これらの要件を満たすことが極めて強く推奨されています。今後のプラットフォーム リリースでは、「しなければならない」として、コールド入力レイテンシ 200 ms 以下を要求する予定です。

    • [C-SR] 連続入力レイテンシが 30 ミリ秒以下。
    • [C-SR] コールド入力ジッターを最小限に抑える。

  • 5.10 プロフェッショナル オーディオ: プロフェッショナル オーディオのサポートに関するオーディオ レイテンシの要件を更新。

    改訂を確認する

    android.content.pm.PackageManager クラスを介して機能 android.hardware.audio.pro のサポートをレポートする場合、デバイス実装は:

    • [C-1-2] セクション 5.6 オーディオ レイテンシで規定しているとおり、少なくとも 1 つのサポート対象パスで、連続ラウンドトリップ オーディオ レイテンシが 25 ミリ秒以下でなければなりません10 ミリ秒以下であるべきです
    • [C-1-5] AAudio ネイティブ オーディオ API AAUDIO_PERFORMANCE_MODE_LOW_LATENCY を使用して、レイテンシと USB オーディオの要件を満たさなければなりません。
    • [C-1-8] スピーカーからマイクのデータパスで、少なくとも 5 回測定して平均タップツートーン レイテンシが 80 ミリ秒以下でなければなりません。
    • [C-SR] オーディオがアクティブで CPU 負荷が変動していても、一貫した CPU パフォーマンス レベルを提供することが強く推奨されます。これは、Android アプリ SynthMark を使用してテストすべきです。SynthMark は、システム パフォーマンスを測定するシミュレート オーディオ フレームワークで動作する、ソフトウェア シンセサイザーを使用します。ベンチマークの説明については、SynthMark のドキュメントをご覧ください。SynthMark アプリは「自動テスト」オプションを使用して実行し、次の結果を得る必要があります。 * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • タップ入力からオーディオ出力までのレイテンシを 40 ms 以下にすべきです。

    4 極 3.5 mm オーディオ ジャックが含まれる場合、デバイス実装は:

  • 5.12 HDR 動画: HDR 動画の要件に関する新しいセクションを追加。

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

  • 6.1 デベロッパー ツール: 接続の要件と GPU カーネルの要件を更新。

    改訂を確認する

    Wi-Fi またはイーサネットを介したホストマシンへの adb 接続をサポートする場合、デバイス実装は:

    • [C-4-1] AdbManager#isAdbWifiSupported() メソッドが true を返さなければなりません。

    Wi-Fi またはイーサネットを介したホストマシンへの adb 接続をサポートし、カメラが 1 つ以上含まれる場合、デバイス実装は:

    • [C-5-1] AdbManager#isAdbWifiQrSupported() メソッドが true を返さなければなりません。

    • GPU 処理に関する情報

      デバイス実装は:

      • [C-6-1] power/gpu_work_period カーネル トレースポイントによって返された GPU 処理の集計データを表示し、トレースポイントがサポートされていない場合はデータを表示しないよう、シェルコマンド dumpsys gpu --gpuwork を実装しなければなりません。AOSP 実装は frameworks/native/services/gpuservice/gpuwork/ です。

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

  • 7.1.4.1 OpenGL ES: 推奨される拡張機能を更新。

    改訂を確認する

    OpenGL ES のいずれかのバージョンをサポートする場合、デバイス実装は:

    • EGL_IMG_context_priority 拡張機能と EGL_EXT_protected_content 拡張機能をサポートすべきです。

  • 7.1.4.2 Vulkan: サポートする Vulkan バージョンを更新。

    改訂を確認する

    OpenGL ES 3.1 をサポートする場合、デバイス実装は:

    • [SR] Vulkan 1.3 Vulkan 1.1 のサポートを含むことが強く推奨されます。
    • Vulkan バリアント バージョンをサポートしてはなりません(Vulkan コアバージョンのバリアント部分はゼロでなければなりません)。

    画面または動画出力が含まれる場合、デバイス実装は:

    • [SR] Vulkan 1.3Vulkan 1.1 のサポートを含むことが強く推奨されます。

    Vulkan 1.0 以降のサポートが含まれる場合、デバイス実装は:

    • VkPhysicalDeviceProtectedMemoryFeaturesVK_EXT_global_priority をサポートすべきです。
    • [C-1-12] 拡張機能 VK_KHR_performance_query のサポートを列挙してはなりません。
    • [C-SR] Android ベースライン 2021 プロファイルで規定されている要件を満たすことが強く推奨されます。

  • 7.2.3 ナビゲーション キー:

    改訂を確認する

    デバイス実装は:

    • [C-SR] すべてのナビゲーション機能をキャンセル可能として提供することが強く推奨されます。「キャンセル可能」とは、スワイプが特定のしきい値を超えても解放されない場合に、ユーザーがナビゲーション機能(「ホーム画面に移動する」、「戻る」など)を実行できないようにする機能を指します。

    「戻る」ナビゲーション機能が提供されており、ユーザーが「戻る」ジェスチャーをキャンセルした場合:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() を呼び出さなければなりません。
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() を呼び出してはなりません。
    • [C-8-3] KEYCODE_BACK イベントをディスパッチしてはなりません。

    「戻る」ナビゲーション機能が提供されているが、フォアグラウンド アプリに OnBackInvokedCallback が登録されていない場合:

    • システムは、AOSP で提供されているように、ユーザーが戻ることを示唆するフォアグラウンド アプリのアニメーションを提供すべきです。

    システム API setNavBarMode のサポートを提供し、それによって android.permission.STATUS_BAR 権限を持つシステムアプリがナビゲーション バーのモードを設定できるようにする場合、デバイス実装は:

    • [C-9-1] AOSP コードで提供されているとおり、子供向けアイコンまたはボタンベースのナビゲーションのサポートを提供しなければなりません。

  • 7.3.1 加速度計: 加速度計のセンサーの要件を更新。

    改訂を確認する

    加速度計3 軸加速度計が含まれる場合、デバイス実装は:

    • [C-1-2] TYPE_ACCELEROMETER センサーを実装し、レポートしなければなりません。
    • [SR] TYPE_SIGNIFICANT_MOTION 複合センサーを実装することが強く推奨されます。
    • [SR] TYPE_ACCELEROMETER_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。Android デバイスは、要求される可能性のある今後のプラットフォーム リリースにアップグレードできるよう、この要件を満たすことが強く推奨されます。
    • Android SDK ドキュメントに記載されているとおり、複合センサー TYPE_SIGNIFICANT_MOTIONTYPE_TILT_DETECTORTYPE_STEP_DETECTORTYPE_STEP_COUNTER を実装すべきです。

    3 軸加速度計が含まれる場合、デバイス実装は:

    • [C-2-1] TYPE_ACCELEROMETER センサーを実装し、レポートしなければなりません。
    • [C-SR] TYPE_SIGNIFICANT_MOTION 複合センサーを実装することが強く推奨されます。
    • [C-SR] TYPE_ACCELEROMETER_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。Android デバイスは、要求される可能性のある今後のプラットフォーム リリースにアップグレードできるよう、この要件を満たすことが強く推奨されます。
    • Android SDK ドキュメントに記載されているとおり、複合センサー TYPE_SIGNIFICANT_MOTIONTYPE_TILT_DETECTORTYPE_STEP_DETECTORTYPE_STEP_COUNTER を実装すべきです。

    3 軸未満の加速度計が含まれる場合、デバイス実装は:

    • [C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES センサーを実装し、レポートしなければなりません。
    • [C-SR] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。

    3 軸加速度計が含まれ、TYPE_SIGNIFICANT_MOTIONTYPE_TILT_DETECTORTYPE_STEP_DETECTORTYPE_STEP_COUNTER いずれかの複合センサーが実装される場合、デバイス実装は:

    • [C-4-1] 消費電力の合計が常に 4 mW 未満でなければなりません。

    3 軸加速度計と 3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:

    • [C-5-1] 複合センサー TYPE_GRAVITYTYPE_LINEAR_ACCELERATION を実装しなければなりません。

    3 軸加速度計、3 軸ジャイロスコープ センサー、磁力計センサーが含まれる場合、デバイス実装は:

    • [C-6-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

  • 7.3.4 ジャイロスコープ: ジャイロスコープのセンサーの要件を更新。

    改訂を確認する

    ジャイロスコープが含まれる場合、デバイス実装は:

    • [C-1-1] 少なくとも周波数 50 Hz までのイベントをレポートできなければなりません。
    • [C-1-4] 解像度が 12 ビット以上でなければなりません。
    • [C-1-5] 温度補正しなければなりません。
    • [C-1-6] 使用中に調整と補正を行わなければならず、デバイスの再起動の間で補正パラメータを保持しなければなりません。
    • [C-1-7] 分散が Hz あたり 1e-7 rad^2 / s^2(Hz あたりの分散または rad^2 / s)以下でなければなりません。分散はサンプリング レートによって異なることが許容されますが、この値の制約を受けなければなりません。つまり、サンプリング レート 1 Hz でジャイロの分散を測定した場合、1e-7 rad^2/s^2 以下であるべきです。
    • [C-SR] 補正誤差は、室温でデバイスが静止しているとき、0.01 rad/s 未満であることが強く推奨されます。
    • [C-SR] 解像度が 16 ビット以上であることが強く推奨されます。
    • 少なくとも 200 Hz までのイベントをレポートすべきです。

    3 軸ジャイロスコープが含まれる場合、デバイス実装は:

    • [C-2-1] TYPE_GYROSCOPE センサーを実装しなければなりません。

    3 軸未満のジャイロスコープが含まれる場合、デバイス実装は:

    • [C-3-1] TYPE_GYROSCOPE_LIMITED_AXES センサーを実装し、レポートしなければなりません。
    • [C-SR] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED センサーを実装し、レポートすることが強く推奨されます。

    3 軸ジャイロスコープ、加速度計センサー、磁力計センサーが含まれる場合、デバイス実装は:

    • [C-4-1] TYPE_ROTATION_VECTOR 複合センサーを実装しなければなりません。

    3 軸加速度計と 3 軸ジャイロスコープ センサーが含まれる場合、デバイス実装は:

    • [C-5-1] 複合センサー TYPE_GRAVITYTYPE_LINEAR_ACCELERATION を実装しなければなりません。

  • 7.3.10 生体認証センサー: 生体認証センサーのセンサーの要件を更新。

    改訂を確認する

    生体認証センサーは、スプーフィング受け入れ率、なりすまし受け入れ率、生体認証パイプラインのセキュリティに基づいて、クラス 3(旧称「」)、クラス 2(旧称「」)、クラス 1(旧称「利便性」)に分類できます。この分類によって、生体認証センサーがプラットフォームやサードパーティ アプリとインターフェースで接続する機能が決まります。センサーをクラス 1クラス 2クラス 3 に分類するには、下記のとおり追加の要件を満たす必要があります。センサーはデフォルトでクラス 1 に分類されます。クラス 2 またはクラス 3 に分類するには、下記のとおり追加の要件を満たす必要があります。クラス 2クラス 3 の生体認証には、下記の追加の機能があります。

    生体認証センサーをクラス 1(旧称「利便性」)として扱う場合、デバイス実装は:

    • [C-1-11] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 30% 以下でなければなりません。具体的には、(1)レベル A のプレゼンテーション攻撃手段(PAI)の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 30% 以下、(2)レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 40% 以下でなければなりません。

    生体認証センサーをクラス 2(旧称「」)として扱う場合、デバイス実装は:

    • [C-2-2] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下でなければなりません。具体的には、(1)レベル A のプレゼンテーション攻撃手段(PAI)の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下、(2)レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 30% 以下でなければなりません。

    生体認証センサーをクラス 3(旧称「」)として扱う場合、デバイス実装は:

    • [C-3-3] Android 生体認証テスト プロトコルによって測定したスプーフィング受け入れ率となりすまし受け入れ率が 7% 以下でなければなりません。具体的には、(1)レベル A のプレゼンテーション攻撃手段(PAI)の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 7% 以下、(2)レベル B の PAI の種類に対するスプーフィング受け入れ率となりすまし受け入れ率が 20% 以下でなければなりません。

  • 7.3.13 IEEE 802.1.15.4(UWB): UWB に関する新しい要件のセクションを追加。

    改訂を確認する

    7.3.13. IEEE 802.1.15.4(UWB)

    802.1.15.4 のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:

    • [C-1-1] 対応する Android API を android.uwb に実装しなければなりません。
    • [C-1-2] ハードウェア機能フラグ android.hardware.uwb をレポートしなければなりません。
    • [C-1-3] Android 実装で定義されている関連する UWB プロファイルをすべてサポートしなければなりません。
    • [C-1-4] ユーザーが UWB 無線のオン / オフの状態を切り替えられるようにするユーザー アフォーダンスを提供しなければなりません。
    • [C-1-5] UWB 無線を使用するアプリが(NEARBY_DEVICES 権限グループの下で)UWB_RANGING 権限を保持するようにしなければなりません。
    • [C-1-6] FIRACCCCSA などの標準化団体によって定義されている、関連する適合性および認証テストに合格することが強く推奨されます。

  • 7.4.1 電話: GSM 電話、CDMA 電話、モバイルデータ使用設定の要件を更新。

    改訂を確認する

    eUICCs または eSIM(埋め込み SIM)をサポートし、eSIM 機能をサードパーティ デベロッパーが利用できるようにする独自のメカニズムが含まれる場合、デバイス実装は:

    デバイス実装に GSM または CDMA 電話が含まれる場合:

    デバイス実装に GSM または CDMA 電話が含まれ、システム ステータスバーが提供される場合:

    • [C-6-7] SIM ステータス情報を提供するアフォーダンスで、特定のグループ UUID の代表的かつアクティブなサブスクリプションを選択し、ユーザーに表示しなければなりません。このようなアフォーダンスの例としては、ステータスバーの電波アイコンやクイック設定タイルなどがあります。
    • [C-SR] デバイスが音声通話中である場合を除き、代表的なサブスクリプションがアクティブなデータ サブスクリプションとして選択されるようにすることが強く推奨されます。デバイスが音声通話中の場合は、代表的なサブスクリプションがアクティブな音声サブスクリプションになるようにすることが強く推奨されます。

    デバイス実装に GSM または CDMA 電話が含まれる場合:

    • [C-6-8] ETSI TS 102 221 に従い、UICC ごとに最大数の論理チャンネル(合計 20 個)を開いて同時に使用できなければなりません。
    • [C-6-10] ユーザーによる明示的な確認なしに、アクティブな携帯通信会社アプリ(TelephonyManager#getCarrierServicePackageName で指定)に以下の動作のいずれかを自動的に適用してはなりません。
      • ネットワーク アクセスを取り消す、または制限する
      • 権限を取り消す
      • バックグラウンドまたはフォアグラウンド アプリの実行を、AOSP に含まれる既存の電源管理機能の範囲を超えて制限する
      • アプリを無効にする、またはアンインストールする

    デバイス実装に GSM または CDMA 電話が含まれ、グループ UUID を共有するすべてのアクティブな非日和見的サブスクリプションが無効にされている場合、デバイスから物理的に削除されている場合、または「日和見的」とマークされている場合、デバイスは:

    • [C-7-1] 同じグループ内の残りのアクティブな日和見的サブスクリプションをすべて自動的に無効にしなければなりません。

    GSM 電話が含まれるが、CDMA 電話は含まれない場合、デバイス実装は:

    • [C-8-1] PackageManager#FEATURE_TELEPHONY_CDMA を宣言してはなりません。
    • [C-8-2] 優先または許可されたネットワーク タイプのビットマスクで 3GPP2 ネットワーク タイプの設定が試みられたときに、IllegalArgumentException をスローしなければなりません。
    • [C-8-3] TelephonyManager#getMeid から空の文字列を返さなければなりません。

    複数のポートとプロファイルを持つ eUICC をサポートする場合、デバイス実装は:

  • 7.4.1.1 番号ブロックの互換性: 番号ブロックの要件を更新。

    改訂を確認する

    android.hardware.telephony feature をレポートする場合、デバイス実装は:

    • [C-1-4] ブロックした通話について、プラットフォーム通話履歴プロバイダに書き込まなければなりません。また、プリインストールされている電話アプリのデフォルトの通話履歴ビューにある通話を、BLOCKED_TYPE でフィルタしなければなりません。
    • プリインストールされている電話アプリにブロックした通話を表示するユーザー アフォーダンスを提供すべきです。

  • 7.4.1.3 モバイル NAT-T キープアライブ オフロード: モバイル NAT-T キープアライブ オフロードに関する新しいセクション。

    改訂を確認する

    7.4.1.3. モバイル NAT-T キープアライブ オフロード

    デバイス実装は:

    • モバイル キープアライブ オフロードのサポートを含むべきです。

    モバイル キープアライブ オフロードのサポートが含まれ、その機能をサードパーティ アプリに公開する場合、デバイス実装は:

    • [C-1-1] SocketKeepAlive API をサポートしなければなりません。
    • [C-1-2] モバイル ネットワークで少なくとも 1 つの同時キープアライブ スロットをサポートしなければなりません。
    • [C-1-3] モバイル Radio HAL でサポートされている数だけ、同時モバイル キープアライブ スロットをサポートしなければなりません。
    • [C-SR] 無線インスタンスごとに少なくとも 3 つのモバイル キープアライブ スロットをサポートすることが強く推奨されます。

    モバイル キープアライブ オフロードのサポートが含まれない場合、デバイス実装は:

    • [C-2-1] ERROR_UNSUPPORTED を返さなければなりません。

  • 7.4.2.5 Wi-Fi Location(Wi-Fi ラウンドトリップ時間 - RTT): Wi-Fi の位置情報の正確度に関する要件を更新。

    改訂を確認する

    Wi-Fi Location のサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:

    • [C-1-4] 累積分布関数で計算して、68 パーセンタイル、80 MHz 帯域幅で、正確度が 2 メートル以内でなければなりません。
    • [C-SR] 累積分布関数で計算して、68 パーセンタイル、80 MHz 帯域幅、正確度 1.5 メートル以内でレポートすることが強く推奨されます。

  • 7.4.2.6 Wi-Fi キープアライブ オフロード: モバイル キープアライブ オフロードの要件を追加するように更新。

    改訂を確認する

    デバイス実装は:

    • Wi-Fi キープアライブ オフロードのサポートを含むべきです。

    Wi-Fi キープアライブ オフロードのサポートが含まれ、機能をサードパーティ アプリに公開する場合、デバイス実装は:

    • [C-1-1] SocketKeepAlive API をサポートしなければなりません。
    • [C-1-2] Wi-Fi で少なくとも 3 つの同時キープアライブ スロット、
      モバイル ネットワークで少なくとも 1 つのキープアライブ スロットをサポートしなければなりません。

    Wi-Fi キープアライブ オフロードのサポートが含まれない場合、デバイス実装は:

  • 7.4.2.9 初回使用時の信頼(TOFU): 初回使用時の信頼に関するセクションを追加。

    改訂を確認する

    7.4.2.9 初回使用時の信頼(TOFU)

    初回使用時の信頼(TOFU)をサポートし、ユーザーが WPA/WPA2/WPA3-Enterprise の設定を定義することを許可している場合、デバイス実装は:

    • [C-4-1] TOFU を使用するオプションをユーザーに提供しなければなりません。

  • 7.4.3 Bluetooth: Bluetooth の要件を更新。

    改訂を確認する

    Bluetooth オーディオ プロファイルをサポートする場合、デバイス実装は:

    • A2DP 対応の Advanced オーディオ コーデックと Bluetooth オーディオ コーデック(LDAC など)をサポートすべきです。

    BluetoothAdapter.isLeAudioSupported() API について true を返す場合、デバイス実装は:

    • [C-7-1] ユニキャスト クライアントをサポートしなければなりません。
    • [C-7-2] 2M PHY をサポートしなければなりません。
    • [C-7-3] LE 拡張アドバタイジングをサポートしなければなりません。
    • [C-7-4] CIG で少なくとも 2 つの CIS 接続をサポートしなければなりません。
    • [C-7-5] BAP ユニキャスト クライアント、CSIP セット コーディネーター、MCP サーバー、VCP コントローラ、CCP サーバーを同時に有効にしなければなりません。
    • [C-SR] HAP ユニキャスト クライアントを有効にすることが強く推奨されます。

    BluetoothAdapter.isLeAudioBroadcastSourceSupported() API について true を返す場合、デバイス実装は:

    • [C-8-1] BIG で少なくとも 2 つの BIS リンクをサポートしなければなりません。
    • [C-8-2] BAP ブロードキャスト ソース、BAP ブロードキャスト アシスタントを同時に有効にしなければなりません。
    • [C-8-3] LE 定期アドバタイジングをサポートしなければなりません。

    BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API について true を返す場合、デバイス実装は:

    • [C-9-1] PAST(Periodic Advertising Sync Transfer)をサポートしなければなりません。
    • [C-9-2] LE 定期アドバタイジングをサポートしなければなりません。

    FEATURE_BLUETOOTH_LE を宣言する場合、デバイス実装は:

    • [C-10-1] 見通せる環境において ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した RSSI の 95% が、+/-9 dB 以内でなければなりません。
    • [C-10-2] 3 つのチャンネルそれぞれのアンテナ(複数使用されている場合)での測定値の 95% が、互いに +/-3 dB 以内になるように、チャンネルごとの偏差を低減するための Rx / Tx 調整を含まなければなりません。
    • [C-SR] ADVERTISE_TX_POWER_HIGH で送信する参照デバイスから 1 m の距離で測定した BLE RSSI の中央値が -60 dBm +/-10 dB になるように、Rx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。
    • [C-SR] 1 m の距離に位置し、ADVERTISE_TX_POWER_HIGH で送信する参照デバイスからスキャンしたときに、BLE RSSI の中央値が -60dBm +/-10 dB になるように、Tx オフセットを測定、補正することが強く推奨されます。その際、各デバイスを「平行面」に配置して、画面を同じ方向に向けるようにします。

    プレゼンス キャリブレーションの要件で指定されている測定の設定手順に従うことが強く推奨されます。

    Bluetooth バージョン 5.0 をサポートする場合、デバイス実装は:

    • [C-SR] 次のサポートを提供することが強く推奨されます:
      • LE 2M PHY
      • LE Coded PHY
      • LE Advertising Extension
      • Periodic advertising
      • 10 個以上の広告セット
      • 8 接続以上の LE 同時接続。各接続は、いずれかの接続トポロジのロールに含めることができます。
      • LE Link Layer Privacy
      • 8 エントリ以上のサイズの「解決リスト」

  • 7.4.9 UWB: UWB ハードウェアに関する要件のセクションを追加。

    改訂を確認する

    7.4.9. UWB

    android.content.pm.PackageManager クラスを介して機能 android.hardware.uwb のサポートをレポートする場合、デバイス実装は:

    • [C-1-1] 見通せる環境において、無反射チャンバー内の 1 m の距離で測定した測定値の 95% で、距離の測定値が +/-15 cm 以内になるようにしなければなりません。
    • [C-1-2] 参照デバイスから 1 m の距離で測定した値の中央値が [0.75 m、1.25 m] 以内になるようにしなければなりません。この場合、グラウンド トゥルースの距離は、上を向けて 45 度傾けた DUT の上端から測定します。

    プレゼンス キャリブレーションの要件で指定されている測定の設定手順に従うことが強く推奨されます。

  • 7.5 カメラ: HDR 10 ビット出力機能の要件を更新。

    改訂を確認する

    HDR 10 ビット出力機能をサポートする場合、デバイス実装は:

    • [C-2-1] 10 ビット出力をサポートするすべてのカメラデバイスで、少なくとも HLG HDR プロファイルをサポートしなければなりません。
    • [C-2-2] プライマリ背面カメラまたはプライマリ前面カメラのいずれかで 10 ビット出力をサポートしなければなりません。
    • [C-SR] 両方のプライマリ カメラで 10 ビット出力をサポートすることが強く推奨されます。
    • [C-2-3] 論理カメラのすべての BACKWARD_COMPATIBLE 対応物理サブカメラと、論理カメラ自体について、同じ HDR プロファイルをサポートしなければなりません。

    android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API を実装する 10 ビット HDR をサポートする論理カメラデバイスは:

    • [C-3-1] 論理カメラの CONTROL_ZOOM_RATIO コントロールを介して、下位互換性のあるすべての物理カメラの切り替えをサポートしなければなりません。

  • 7.7.2 USB ホストモード: デュアルロール ポートの改訂。

    改訂を確認する

    ホストモードと USB Type-C をサポートする USB ポートが含まれる場合、デバイス実装は:

    • [C-4-1] USB Type-C 仕様(セクション 4.5.1.3.3)で規定されているとおり、デュアルロール ポート機能を実装しなければなりません。デュアルロール ポートについて、3.5 mm オーディオ ジャックが含まれるデバイスでは、USB シンク検出(ホストモード)をデフォルトでオフにしても構いませんが、ユーザーが有効にできるようにしなければなりません。

  • 7.11 メディア パフォーマンス クラス: Android T を含むように更新。

    改訂を確認する

    android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS に対してゼロ以外の値が返される場合、デバイス実装は:

    • [C-1-3] セクション 2.2.7 に記載されている「メディア パフォーマンス クラス」のすべての要件を満たさなければなりません。

    言い換えれば、Android T のメディア パフォーマンス クラスは、バージョン T、S、R のハンドヘルド デバイス用にのみ定義されています。

    デバイス固有の要件についてはセクション 2.2.7 をご覧ください。

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

  • 9.1 権限: プリインストール アプリの権限許可リストの承認済みパスを APEX ファイルに拡大。

    改訂を確認する

    • [C-0-2] protectionLevelPROTECTION_FLAG_PRIVILEGED である権限は、システム イメージ(および APEX ファイルの特権パスにプリインストールされたアプリと、各アプリの明示的に許可リスト登録された権限のサブセット内のアプリにのみ、付与しなければなりません。AOSP 実装は、etc/permissions/ パスのファイルから各アプリの許可リスト登録された権限を読み取って使用し、特権パスとして system/priv-app パスを使用することで、この要件を満たしています。

  • 9.7 セキュリティ機能: カーネルの整合性を維持するための初期化の要件を更新。

    改訂を確認する

    カーネルの整合性と自己保護機能は Android のセキュリティに不可欠です。 デバイス実装は:

    • [C-SR] 初期化されていないローカル変数の使用を防ぐために、カーネルでスタック初期化を有効にすることが強く推奨されます(CONFIG_INIT_STACK_ALL または CONFIG_INIT_STACK_ALL_ZERO)。また、デバイス実装は、コンパイラがローカル変数を初期化するために使用する値を仮定すべきではありません。

  • 9.8.7 プライバシー - クリップボードへのアクセス: ユーザーのプライバシーを保護するために、切り取り、コピー、貼り付けを行ってから 60 分後にクリップボード データを自動的に消去。

    改訂を確認する

    デバイス実装は:

    • [C-0-1] サードパーティ アプリがデフォルトの IME であるか、現在フォーカスされているアプリである場合を除き、クリップボードのクリップデータを(たとえば ClipboardManager API を介して)返してはなりません。
    • [C-0-2] クリップボード データがクリップボード内に最後に配置されてから、またはクリップボードから読み取られてから 60 分以内に、クリップボード データを消去しなければなりません。

  • 9.11 鍵と認証情報: 暗号化アルゴリズムへの ECDH と 3DES の追加など、セキュアロック画面の要件を更新。

    改訂を確認する

    セキュアロック画面をサポートする場合、デバイス実装は:

    • [C-1-2] カーネル以上で動作するコードから安全に隔離されたエリアで、Android Keystore システムのサポート対象アルゴリズムを適切にサポートするために、RSA、AES、ECDSA、ECDH(IKeyMintDevice がサポートされている場合)、3DES、HMAC 暗号アルゴリズムと、MD5、SHA1、SHA-2 ファミリー ハッシュ関数の実装を持たなければなりません。安全な隔離では、DMA を含め、隔離された環境の内部状態にカーネルまたはユーザー空間のコードがアクセスする可能性のあるすべてのメカニズムをブロックしなければなりません。アップストリームの Android オープンソース プロジェクト(AOSP)は、Trusty 実装を使用することでこの要件を遵守しています。ただし、別の ARM TrustZone ベースのソリューション、または、サードパーティのレビューによる適切なハイパーバイザ ベースの隔離オプションをセキュアに実装する方法を選択することもできます。

  • 9.11.1 セキュアロック画面、認証、仮想デバイス: 仮想デバイスと認証の転送に関する要件のセクションを追加。

    改訂を確認する

    デバイス実装が、ロック画面をロック解除するための認証方法を追加または変更し、新しい認証方法が物理トークンまたは場所に基づいている場合:

    • [C-6-3] 少なくとも 4 時間以内ごとに 1 回、推奨される第 1 の認証方法(PIN、パターン、パスワードなど)のいずれかをユーザーに求めなければなりません。物理トークンが C-X の TrustAgent 実装の要件を満たしている場合は、代わりに C-9-5 で規定されているタイムアウト制限が適用されます。

    アプリによるセカンダリ仮想ディスプレイの作成を許可し、関連する入力イベント(VirtualDeviceManager 経由など)をサポートしない場合、デバイス実装は:

    • [C-9-1] デバイスのデフォルト ディスプレイがロックされているときはセカンダリ仮想ディスプレイをロックし、デバイスのデフォルト ディスプレイがロック解除されているときはセカンダリ仮想ディスプレイをロック解除しなければなりません。

    アプリによるセカンダリ仮想ディスプレイの作成を許可し、関連する入力イベント(VirtualDeviceManager 経由など)をサポートする場合、デバイス実装は:

    • [C-10-1] 仮想デバイスごとに別々のロック状態をサポートしなければなりません。
    • [C-10-2] アイドル タイムアウト時にすべての仮想デバイスを切断しなければなりません。
    • [C-10-3] アイドル タイムアウトがなければなりません。
    • [C-10-4] ハンドヘルド デバイスに必要なロックダウン ユーザー アフォーダンスなどを介してユーザーがロックダウンを開始したとき、すべてのディスプレイをロックしなければなりません(セクション 2.2.5[9.11/H-1-2] を参照)。
    • [C-10-5] ユーザーごとに個別の仮想デバイス インスタンスがなければなりません。
    • [C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy で示されている場合、VirtualDeviceManager を介した関連する入力イベントの作成を無効にしなければなりません
    • [C-10-7] 仮想デバイスごとに別のクリップボードを使用しなければなりません(または、仮想デバイスのクリップボードを無効にしなければなりません)。
    • [C-10-11] 仮想デバイスの認証 UI(知識要素の入力や生体認証プロンプトなど)を無効にしなければなりません。
    • [C-10-12] 仮想デバイスから開始されたインテントを、同じ仮想デバイスでのみ表示するように制限しなければなりません。
    • [C-10-13] Android Keystore システムでのユーザー認証承認として、仮想デバイスのロック状態を使用してはなりません。KeyGenParameterSpec.Builder.setUserAuthentication* をご覧ください。

    ターゲット デバイスの初期設定の場合など、ユーザーがプライマリ認証の知識要素をソースデバイスからターゲット デバイスに転送できるようにする場合、デバイス実装は:

    • [C-11-1] 知識要素をソースデバイスからターゲット デバイスに転送するときに、Google Cloud Key Vault サービスに記載されているものと同様の保護保証で知識要素を暗号化しなければなりません。これにより、知識要素をリモートで復号したり、知識要素を使用していずれかのデバイスをリモートでロック解除したりできないようにすることができます。
    • [C-11-2] ソースデバイスで、知識要素をターゲット デバイスに転送する前にソースデバイスの知識要素を確認するようユーザーに求めなければなりません。
    • [C-11-3] 第 1 の認証用の知識要素が設定されていないターゲット デバイスで、その知識要素をターゲット デバイスの第 1 の認証用の知識要素に設定する前に、かつソースデバイスから転送されたデータを利用できるようにする前に、ターゲット デバイスで転送された知識要素を確認するようユーザーに求めなければなりません。

    セキュアロック画面があり、FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE フラグを指定して TrustAgentService.grantTrust() システム API を呼び出す信頼エージェントが 1 つ以上含まれる場合、デバイス実装は:

    • [C-12-1] 自身のロック画面を備えた近接する物理デバイスに接続されており、かつユーザーがそのロック画面に対して ID を認証した場合に限り、フラグを指定して grantTrust() を呼び出さなければなりません。近接デバイスは、ユーザーによる 1 回限りのロック解除後に、手首への装着、または持ち運びを検知するメカニズムを使用することで、ユーザー認証の要件を満たすことができます。
    • [C-12-2] ボタンの押下や表示のタイムアウトなどにより画面がオフになり、TrustAgent が信頼を取り消さなかった場合、デバイス実装を TrustState.TRUSTABLE 状態にしなければなりません。AOSP はこの要件を満たしています。
    • [C-12-3] TrustAgent が C-12-1 の要件に基づいて引き続き信頼を付与している場合にのみ、デバイスを TrustState.TRUSTABLE から TrustState.TRUSTED の状態に移行しなければなりません。
    • [C-12-4] 信頼を付与してから最長 24 時間(8 時間のアイドル時間枠)後に、または近接する物理デバイスへの基礎的な接続が失われたときに、TrustManagerService.revokeTrust() を呼び出さなければなりません。

    アプリによるセカンダリ仮想ディスプレイの作成を許可して、関連する入力イベント(VirtualDeviceManager 経由など)をサポートし、ディスプレイに VIRTUAL_DISPLAY_FLAG_SECURE のマークがない場合、デバイス実装は:

    • [C-13-8] 属性 android:canDisplayOnRemoteDevices、またはメタデータ android.activity.can_display_on_remote_devices が false に設定されているアクティビティが、仮想デバイスで開始されないようにブロックしなければなりません。
    • [C-13-9] 明示的にストリーミングを有効にしておらず、SurfaceView#setSecure、FLAG_SECURE、または SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS などを介してデリケートなコンテンツを表示することを示しているアクティビティが、仮想デバイスで開始されないようにブロックしなければなりません。
    • [C-13-10] 仮想デバイスから開始されたアプリのインストールを無効にしなければなりません。

  • 9.11.2 Strongbox: インサイダー攻撃耐性(IAR)を必要要件化。

    改訂を確認する

    [C-1-3] から [C-1-9] の遵守を検証するために、デバイス実装は:

    • [C-SR] インサイダー攻撃耐性(IAR)を提供することが強く推奨されます。つまり、ファームウェア署名鍵にアクセスできるインサイダーが、StrongBox のシークレットの漏洩、機能のセキュリティ要件の回避、またはユーザーの機密データへのアクセスを可能にするファームウェアを生成できないようにします。IAR の実装で推奨される方法は、IAuthSecret HAL を介してプライマリ ユーザー パスワードが提供されたときにのみ、ファームウェアをアップデートできるようにすることです。IAR は、Android U(AOSP 試験運用版)では「しなければならない」要件になります。

  • 9.11.3 ID 認証情報: ID 認証情報システムのリファレンス実装に関する情報を追加。

    改訂を確認する

    ID 認証情報システムは、android.security.identity.* パッケージのすべての API を実装することで定義され、実現されます。これらの API を使用すると、アプリ デベロッパーはユーザー ID ドキュメントの保存と取得を行うことができます。デバイス実装は:

    アップストリームの Android オープンソース プロジェクトは、ID 認証情報システムの実装に使用できる信頼できるアプリ(libeic)のリファレンス実装を提供します。

  • 9.11.4 ID 構成証明: ID 構成証明の要件に関するセクションを追加。

    改訂を確認する

    9.11.4. ID 構成証明

    デバイス実装は、ID 構成証明をサポートしなければなりません。

  • 9.17 Android Virtualization Framework: Android Virtualization Framework の要件に関するセクションを追加。

    改訂を確認する

    9.17. Android Virtualization Framework

    デバイスが Android Virtualization Framework API(android.system.virtualmachine.*)のサポートを実装している場合、Android ホストは:

    • [C-1-1] android.system.virtualmachine.* パッケージで定義されたすべての API をサポートしなければなりません。
    • [C-1-2] 保護された仮想マシンの管理用の Android SELinux と権限モデルを変更してはなりません。
    • [C-1-3] アップストリームの Android オープンソース プロジェクト(AOSP)で提供されている system/sepolicy 内に存在する neverallow ルールの変更、省略、または置き換えを行ってはなりません。また、ポリシーは、neverallow ルールがすべて存在する状態でコンパイルしなければなりません。
    • [C-1-4] 信頼できないコード(サードパーティ アプリなど)が、保護された仮想マシンを作成および実行できるようにしてはなりません。ただし、これは Android の今後のリリースで変更される可能性があります。
    • [C-1-5] 保護された仮想マシンが、ファクトリー イメージまたはアップデートの一部ではないコードを実行できるようにしてはなりません。Android の確認付きブートの対象でないもの(インターネットからダウンロードしたファイルやサイドローディングされたファイルなど)は、保護された仮想マシンで実行できないようにしなければなりません。

    デバイスが Android Virtualization Framework API(android.system.virtualmachine.*)のサポートを実装している場合、保護された仮想マシン インスタンスは:

    • [C-2-1] 保護された仮想マシンの仮想化 APEX で利用可能なすべてのオペレーティング システムを実行できなければなりません。
    • [C-2-2] 保護された仮想マシンが、デバイス実装者または OS ベンダーによって署名されていないオペレーティング システムを実行できるようにしてはなりません。
    • [C-2-3] 保護された仮想マシンがデータをコードとして実行できるようにしてはなりません(SELinux neverallow execmem など)。
    • [C-2-4] アップストリームの Android オープンソース プロジェクト(AOSP)で提供されている system/sepolicy/microdroid 内に存在する neverallow ルールの変更、省略、または置き換えを行ってはなりません。
    • [C-2-5] Microdroid 以外のオペレーティング システムであっても、保護された仮想マシンの多層防御メカニズム(pVM 用の SELinux など)を実装しなければなりません。
    • [C-2-6] 初期イメージを検証できない場合、pVM ファームウェアが起動を拒否するようにしなければなりません。
    • [C-2-7] instance.img の整合性が侵害された場合、pVM ファームウェアが起動を拒否するようにしなければなりません。

    デバイスが Android Virtualization Framework API(android.system.virtualmachine.*)のサポートを実装している場合、ハイパーバイザは:

    • [C-3-1] ページ所有者が明示的に共有していない限り、pVM が別のエンティティ(他の pVM やハイパーバイザ)に属するページにアクセスできるようにしてはなりません。これにはホスト VM が含まれます。また、これは CPU アクセスと DMA アクセスの両方に適用されます。
    • [C-3-2] ページが VM で使用された後、ホストに返す前に、ページをワイプしなければなりません(pVM が破棄された場合など)。
    • [C-3-3] pVM のどのコードよりも前に、pVM ファームウェアが読み込まれて実行されるようにしなければなりません。
    • [C-3-4] pVM インスタンスに提供される BCC と CDI が、その特定のインスタンスによってのみ導出できるようにしなければなりません。

    デバイスが Android Virtualization Framework API のサポートを実装している場合は、すべてのエリアで:

    • [C-4-1] Android セキュリティ モデルをバイパスできる機能を pVM に提供してはなりません。

    Android Virtualization Framework API のサポートを実装している場合、デバイスは:

    • [C-5-1] ART ランタイム アップデートの分離コンパイルをサポートしなければなりません。

    デバイスが Android Virtualization Framework API のサポートを実装している場合、鍵管理について:

    • [C-6-1] ロック解除されたデバイスであっても、ユーザーが変更できないポイントに DICE チェーンのルートを設定しなければなりません(なりすましを防ぐため)。
    • [C-6-2] DICE を適切に行わなければなりません(正しい値を提供しなければなりません)。ただし、それほど詳細なレベルで行う必要はありません。

トップへ戻る