Android 兼容性定義文檔變更日誌

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

安卓 13

2022 年 10 月 19 日

2. 設備類型

  • 2.2.3 軟件

    見修訂

    如果手持設備實現未在鎖定任務模式下運行，當內容被複製到剪貼板時，它們：

    • [3.8.17/H-1-1] 必須向用戶提供數據已復製到剪貼板的確認信息（例如，縮略圖或“內容已復制”的警告）。此外，如果剪貼板數據將跨設備同步，請在此處包括指示。

3. 軟件

  • 3.2.3.5。有條件的申請意向

    見修訂

    如果設備實現的設置應用程序使用活動嵌入實現了拆分功能，那麼它們：

    如果設備實現支持VoiceInteractionService並且一次安裝了多個使用此 API 的應用程序，則它們：

  • 3.4.1 網頁視圖兼容性

    見修訂

    • [C-1-4]必須在與實例化 WebView 的應用程序不同的進程中呈現提供的內容或遠程 URL 內容。具體來說，單獨的渲染器進程必須擁有較低的權限，作為單獨的用戶 ID 運行，無法訪問應用程序的數據目錄，無法直接訪問網絡，並且只能通過 Binder 訪問最低要求的系統服務。 WebView 的 AOSP 實現滿足了這個要求。

7. 硬件兼容性

  • 7.4.2 IEEE 802.11（Wi-Fi）

    見修訂

    如果設備實現支持 IEEE 802.11 標準中定義的 Wi-Fi 省電模式，則：

  • 7.4.3 藍牙

    見修訂

    如果設備實現包括對低功耗藍牙 (BLE) 的支持，則它們：

    • [C-3-5] 必須實施不超過 15 分鐘的可解析私有地址 (RPA) 超時，並在超時時輪換地址，以在設備主動使用 BLE 進行掃描或廣告時保護用戶隱私。為了防止定時攻擊，超時間隔也必須在 5 到 15 分鐘之間隨機分配。

  • 7.5.5 相機方向

    見修訂

    如果設備實現具有前置或後置攝像頭，則此類攝像頭：

    • [C-1-1] 必須調整方向，使相機的長尺寸與屏幕的長尺寸對齊。也就是說，當設備以橫向放置時，相機必須以橫向拍攝圖像。無論設備的自然方向如何，這都適用；也就是說，它適用於橫向主設備以及縱向主設備。

    滿足以下所有條件的設備不受上述要求的約束：

    • 該設備採用可變幾何屏幕，例如可折疊或鉸鍊式顯示器。
    • 當設備的折疊或鉸鏈狀態發生變化時，設備會在縱向主要方向和橫向主要方向（或反之亦然）之間切換。

9. 安全模型兼容性

  • 9.11 密鑰和證書

    見修訂

    當設備實現支持安全鎖屏時，它：

    • [C-1-6] 必須支持 IKeymasterDevice 4.0、 IKeymasterDevice 4.1、IKeyMintDevice 版本 1 或 IKeyMintDevice 版本 2。

  • 9.17 安卓虛擬化框架

    見修訂

    如果設備實現了對 Android 虛擬化框架 API ( android.system.virtualmachine.* ) 的支持，則 Android 主機：

    • [C-1-3] 不得修改、省略或替換上游 Android 開源項目 (AOSP) 中提供的系統/sepolicy 中存在的 neverallow 規則，並且該政策必須使用所有存在的 neverallow 規則進行編譯。

    如果設備實現了對 Android 虛擬化框架 API ( android.system.virtualmachine.* ) 的支持，則任何受保護的虛擬機實例：

    • [C-2-4] 不得修改、省略或替換上游 Android 開源項目 (AOSP) 中提供的 system/sepolicy/microdroid 中存在的 neverallow 規則。

    如果設備實現了對 Android 虛擬化框架 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 鄰居感知網絡 (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 個百分位，+/-4 米，40 MHz 帶寬，第 68 個百分位，+/-8 米，20 MHz 帶寬，第 68 個百分位，距離為 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觀察，第 90 個百分位數的帶寬，第 90 個百分位數的 40 MHz 帶寬 +/-4 米，第 90 個百分位數的 20 MHz 帶寬 +/-8 米，距離為 10 厘米。

      強烈建議遵循存在校準要求中指定的測量設置步驟。

    • 音頻延遲：

      見修訂

      如果手持設備實現聲明了android.hardware.audio.output和android.hardware.microphone ，它們：

      • [ 5.6 /H-1-1] 必須具有500的平均連續往返延遲800 5 次測量的毫秒或更少，平均絕對偏差小於50 100 ms，通過以下數據路徑：“揚聲器到麥克風”、3.5 毫米環回適配器（如果支持）、USB 環回（如果支持）。至少一個支持的路徑。

      • [ 5.6 /H-1-1] 在揚聲器到麥克風數據路徑上的至少 5 次測量中，平均點擊音延遲必須為 500 毫秒或更短。

    • 觸覺輸入：

      見修訂

      如果手持設備實現包括至少一個觸覺執行器，則它們：

      • [ 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）和
      • [ 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) （點擊、滴答、LOW_TICK、QUICK_FALL、QUICK_RISE、SLOW_RISE、旋轉、THUD）。這些原語中的一些，例如 LOW_TICK 和 SPIN 可能僅在振動器可以支持相對較低的頻率時才可行。

      • [ 7.10 /H]* 應該使用這些鏈接的觸覺常量映射。

      如果手持設備實現包括至少一個線性諧振執行器，則它們：

      • [ 7.10 /H]* 應在縱向的 X 軸（左右）上移動觸覺致動器。

      • [ 7.10 /H]* 應該驗證並在需要時更新不支持原語的回退配置，如常量實施指南中所述。

      • [7.10/H]* 應提供後備支持以降低此處所述的失敗風險。

  • 2.2.3 軟件：

    • 授權簡單的設備控制：

      見修訂

      • [ 3.8 .16/H-1-5] 必須提供一種方式，讓用戶可以通過ControlsProviderService和Control Control.isAuthRequired API 從第三方應用程序註冊的控件中選擇退出應用程序指定的 auth-trivial 設備控件。

    • 媒體樣式通知：

      見修訂

      如果手持設備實現支持MediaStyle 通知，則它們：

      • [3.8.3.1/H-1-SR] 強烈建議提供從系統 UI 訪問的用戶功能（例如“輸出切換器”），允許用戶在適當的可用媒體路由（例如藍牙設備和提供給MediaRouter2Manager的路由）之間切換當應用發布帶有MediaSession 令牌的MediaStyle 通知時。

  • 2.2.4 性能和功率：對運行前台服務的應用程序的新要求。

    見修訂

    手持設備實現：

    • [ 8.5 /H-0-1] 必須在“設置”菜單中為用戶提供停止正在運行前台服務的應用程序並顯示所有具有活動前台服務的應用程序以及每項服務的持續時間的能力按照SDK 文檔中的描述啟動。
      • 如SDK 文檔中所述，某些應用程序可以免於停止或列在此類用戶可供性中。

  • 2.2.7.1 媒體：手持設備要求媒體部分更新如下：

    見修訂

    如果手持設備實現為android.os.Build.VERSION_CODES.T android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS那麼它們：

    • [5.1/H-1-1] 必須通告可通過CodecCapabilities.getMaxSupportedInstances()和VideoCapabilities.getSupportedPerformancePoints()方法在任何編解碼器組合中同時運行的硬件視頻解碼器會話的最大數量。
    • [5.1/H-1-2] 必須在以 1080p 分辨率@30 fps 同時運行的任何編解碼器組合中支持 6 個硬件視頻解碼器會話實例（AVC、HEVC、VP9、AV1 或更高版本）。
    • [5.1/H-1-3] 必須通告可通過CodecCapabilities.getMaxSupportedInstances()和VideoCapabilities.getSupportedPerformancePoints()方法在任何編解碼器組合中同時運行的硬件視頻編碼器會話的最大數量。
    • [5.1/H-1-4] 必須在以 1080p 分辨率@30fps 同時運行的任何編解碼器組合中支持 6 個硬件視頻編碼器會話實例（AVC、HEVC、VP9、AV1 或更高版本）。
    • [5.1/H-1-5] 必須通告可通過CodecCapabilities.getMaxSupportedInstances()和VideoCapabilities.getSupportedPerformancePoints()方法在任何編解碼器組合中同時運行的硬件視頻編碼器和解碼器會話的最大數量。
    • [5.1/H-1-6] 必須支持以 1080p@30fps 分辨率同時運行的任何編解碼器組合中的 6 個硬件視頻解碼器和硬件視頻編碼器會話實例（AVC、HEVC、VP9、AV1 或更高版本）。
    • [5.1/H-1-7] 在負載下，所有硬件視頻編碼器的 1080p 或更小視頻編碼會話的編解碼器初始化延遲必須不超過 40 毫秒。此處的加載定義為並發的 1080p 到 720p 純視頻轉碼會話，使用硬件視頻編解碼器以及 1080p 音頻-視頻錄製初始化。
    • [5.1/H-1-8] 在負載下，所有音頻編碼器的 128 kbps 或更低比特率音頻編碼會話的編解碼器初始化延遲必須為 30 毫秒或更短。此處的加載定義為並發的 1080p 到 720p 純視頻轉碼會話，使用硬件視頻編解碼器以及 1080p 音頻-視頻錄製初始化。
    • [5.1/H-1-9] 必須在以 1080p 分辨率@30 fps 同時運行的任何編解碼器組合中支持 2 個安全硬件視頻解碼器會話實例（AVC、HEVC、VP9、AV1 或更高版本）。
    • [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 硬件解碼器 Main 10，Level 4.1。
    • [5.1/H-SR] 強烈推薦支持 AV1 硬件解碼器的 Film Grain。
    • [5.1/H-1-15] 必須至少有 1 個支持 4K60 的硬件視頻解碼器。
    • [5.1/H-1-16] 必須至少有 1 個支持 4K60 的硬件視頻編碼器。
    • [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] 在至少一個受支持的數據路徑上，往返音頻延遲必須為 80 毫秒或更短。
    • [5.6/H-1-3] 必須支持 >=24 位音頻，通過 3.5 毫米音頻插孔（如果存在）和 USB 音頻（如果通過整個數據路徑支持低延遲和流式​​傳輸配置）進行立體聲輸出。對於低延遲配置，應用程序應在低延遲回調模式下使用 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 字節
    最小子樣本數 - H264 或 HEVC 32
    最小子樣本數 - VP9 9
    最小子樣本數 - AV1 288
    最小子樣本緩衝區大小1 字節
    最小通用加密緩衝區大小500 KB
    最小並發會話數30
    每個會話的最小密鑰數20
    最小鍵總數（所有會話） 80
    DRM 密鑰的最小總數（所有會話） 6個
    郵件大小16 KB
    每秒解密幀數60 幀/秒

  • 2.2.7.2 相機：更新媒體性能等級相機要求。

    見修訂

    如果手持設備實現為android.os.Build.VERSION_CODES.T android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS那麼它們：

    • [7.5/H-1-1] 必須有一個主後置攝像頭，分辨率至少為 12 兆像素，支持 4k@30fps 的視頻捕獲。主後置攝像頭是攝像頭 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] 對於 1080p 分辨率，兩個主攝像頭在 ITS 照明條件 (3000K) 下通過 CTS 攝像頭性能測試測得的攝像頭 2 JPEG 捕獲延遲必須小於 1000 毫秒。
    • [7.5/H-1-6] 兩個主攝像頭在 ITS 照明條件 (3000K) 下通過 CTS 攝像頭性能測試測得的攝像頭 2 啟動延遲（打開攝像頭到第一個預覽幀）必須小於 500 毫秒。
    • [7.5/H-1-8] 主後置攝像頭必須支持CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW和android.graphics.ImageFormat.RAW_SENSOR 。
    • [7.5/H-1-9] 必須具有支持 720p 或 1080p @ 240fps 的後置主攝像頭。
    • [7.5/H-1-10] 如果超寬 RGB 攝像頭面向同一方向，則主攝像頭的最小 ZOOM_RATIO 必須 < 1.0。
    • [7.5/H-1-11] 必須在主攝像頭上實現並發的前後流。
    • [7.5/H-1-12] 必須支持主前置攝像頭和主後置攝像頭的CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION 。
    • [7.5/H-1-13] 如果有超過 1 個 RGB 相機面向同一方向，則必須支持主相機的LOGICAL_MULTI_CAMERA功能。
    • [7.5/H-1-14] 必須支持主前置攝像頭和主後置攝像頭的STREAM_USE_CASE功能。

  • 2.2.7.3 硬件：更新硬件的媒體性能等級要求。

    見修訂

    如果手持設備實現為android.os.Build.VERSION_CODES.T android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS那麼它們：

    • [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.T android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS那麼它們：

    • [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 硬件：更新三軸加速度計和三軸陀螺儀要求，以及外視攝像頭要求。

    見修訂

    汽車設備實現：

    • [ 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] 強烈建議將陀螺儀的測量範圍配置為 +/-250dps，以盡可能提高分辨率。

    如果汽車設備實現包括 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 同步框架。

    • 可以在相機驅動程序中實現硬件自動對焦或軟件自動對焦。

    如果汽車設備實現包括一個或多個外視攝像頭，並加載外視系統 (EVS) 服務，那麼對於此類攝像頭，它們：

    • [ 7.5 /A-2-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] 為了在設備實現中提供一致、有意義的值，下表包含對這些值的格式的額外限制，設備實現必須遵守這些格式。
    範圍細節
    獲取序列號()必須（是或返回）硬件序列號，該序列號必須在具有相同型號和製造商的設備之間可用且唯一。該字段的值必須可編碼為 7 位 ASCII，並匹配正則表達式“^[a-zA-Z0-9]+$” 。

  • 3.2.3.5 條件應用意圖：更新條件應用意圖的要求。

    見修訂

    如果設備實現包括大型顯示器（通常具有 600dp+ 的顯示寬度和高度）並支持拆分功能，則它們：

  • 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] 必須包含對 AppWidget 的內置支持，並公開用戶界面可供性以添加、配置、查看和刪除 AppWidget直接在啟動器中。

  • 3.8.3.1 通知的呈現：澄清提示通知的定義。

    見修訂

    Heads up notifications 是當它們獨立於用戶所在的表面而出現時呈現給用戶的通知。

  • 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_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] 必須具有 5 或更大的CAM16色度值。

      • 應通過com.android.systemui.monet.ColorScheme#getSeedColors從壁紙派生，它提供多種有效的源顏色以供選擇。

      • 如果提供的顏色均不滿足上述源顏色要求，則應使用值0xFF1B6EF3 。

  • 3.8.17 剪貼板：添加了剪貼板上內容的新要求部分。

    見修訂

    3.8.17.剪貼板

    設備實現：

    • [C-0-1] 不得將剪貼板數據發送到任何組件、活動、服務或通過任何網絡連接，除非有明確的用戶操作（例如，按下疊加層上的按鈕）， 9.8.6 內容中提到的服務除外捕獲和應用程序搜索。

    如果設備實現在將內容複製到任何ClipData項目的剪貼板時生成用戶可見的預覽，其中ClipData.getDescription().getExtras()包含android.content.extra.IS_SENSITIVE ，它們：

    • [C-1-1] 必須遮蓋用戶可見的預覽

    AOSP 參考實現滿足這些剪貼板要求。

  • 3.9.1.1 設備所有者配置：更新設備所有者配置要求。

    見修訂

    如果設備實現聲明了android.software.device_admin ，它們：

    • [C-1-1] 必須支持將 Device Policy Client (DPC) 註冊為Device Owner 應用，如下所述：
      • 當設備實現既沒有配置用戶也沒有配置用戶數據時，它：
        • [C-1-5] 如果設備通過該功能聲明近場通信 (NFC) 支持，則必須將 DPC 應用註冊為設備所有者應用，或者允許 DPC 應用選擇成為設備所有者還是配置文件所有者標記android.hardware.nfc並接收包含 MIME 類型MIME_TYPE_PROVISIONING_NFC的記錄的 NFC 消息。
        • [C-1-8] 必須在觸發設備所有者配置後發送ACTION_GET_PROVISIONING_MODE Intent，以便 DPC 應用可以根據android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES的值選擇是成為設備所有者還是配置文件所有者，除非從上下文可以確定只有一個有效選項。 （例如不支持配置文件所有者配置的基於 NFC 的配置）。
        • [C-1-9] 如果在配置期間建立了設備所有者，則無論使用何種配置方法，都必須將ACTION_ADMIN_POLICY_COMPLIANCE Intent 發送到設備所有者應用。在 Device Owner 應用程序完成之前，用戶不得在設置嚮導中繼續。
      • 當設備實現有用戶或用戶數據時，它：
        • [C-1-7] 不得再將任何 DPC 應用註冊為設備所有者應用。
    • [C-1-2] 必須顯示適當的披露通知（例如 AOSP 中引用的）並在將應用設置為設備所有者之前獲得最終用戶的肯定同意，除非在之前以編程方式將設備配置為零售演示模式屏幕上的最終用戶交互。在配置過程之前或期間需要一些肯定的操作以同意將應用程序設置為設備所有者。可以通過用戶操作或通過某些編程方式表示同意，但必須在設備所有者配置啟動之前顯示適當的披露通知（如 AOSP 中所引用）。此外，（企業）用於設備所有者配置的程序化設備所有者同意機制不得乾擾非企業使用的開箱即用體驗。
    • [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".

  • 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 or android.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:

    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 .

  • 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 the ContactsContracts.Contacts.CONTENT_TYPE and ContactsContract.RawContacts.CONTENT_TYPE by initially selecting the account.

4. Application Packaging Compatibility

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 the android.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 ).

  • 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:

  • 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 less over 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 .

  • 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 return true .

    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 return true .

    • 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 the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

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 and EGL_EXT_protected_content extensions.

  • 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 and VK_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.

  • 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 with android.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 report TYPE_ACCELEROMETER sensor.
    • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [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 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 and TYPE_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 and TYPE_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:

    If device implementations include GSM or CDMA telephony, then:

    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:

    If the device implementations support eUICCs with multiple ports and profiles, they:

  • 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 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:

  • 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 the BluetoothAdapter.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 the BluetoothAdapter.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 the BluetoothAdapter.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.

    強烈建議遵循存在校準要求中指定的測量設置步驟。

    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 the android.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.

    強烈建議遵循存在校準要求中指定的測量設置步驟。

  • 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 of PROTECTION_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 the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 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 or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

  • 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.

  • 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 by DevicePolicyManager.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 the FLAG_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 the TrustState.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.

Back to top