安卓14
2023 年 11 月 20 日
2. 設備類型
查看修訂版
如果手持設備實作聲明支援任何 64 位元 ABI(有或沒有任何 32 位元 ABI):
查看修訂版
- [ 7.5 /H-1-13] 如果有超過 1 個 RGB 後置攝像頭,則必須支援主後置攝像頭的
LOGICAL_MULTI_CAMERA
功能。
- [ 7.5 /H-1-13] 如果有超過 1 個 RGB 後置攝像頭,則必須支援主後置攝像頭的
查看修訂版
[ 5.8 /T-0-1]必須將 HDMI 輸出模式設定為所選 SDR 或 HDR 格式的最高解析度,該格式適用於外部顯示器的 50Hz 或 60Hz 更新率。
必須設定 HDMI 輸出模式以選擇 50Hz 或 60Hz 更新率可支援的最大解析度。
查看修訂版
- [9/W-0-1] 必須聲明
android.hardware.security.model.compatible feature
。
- [9/W-0-1] 必須聲明
6. 開發者工具和選項相容性
查看修訂版
- [C-0-12] 必須將
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom 寫入
查看修訂版
- [C-0-13] 必須執行 shell 指令
dumpsys gpu --gpuwork
才能顯示
- [C-0-12] 必須將
9. 安全模型相容性
查看修訂版
如果裝置實作使用能夠支援 SELinux 的 Linux 內核,則:
查看修訂版
如果裝置實作使用 Linux 以外的核心或不含 SELinux 的 Linux,則:
2023 年 10 月 4 日
2. 設備類型
查看修訂版
如果 Android 裝置實現滿足以下所有條件,則將其歸類為手持裝置:
- 實體對角線螢幕尺寸範圍為4 吋
3.3 吋(對於 API 等級 29 或更早版本的裝置實作為 2.5 吋)到 8 吋。
開始新的要求
- 具有觸控螢幕輸入介面。
- 實體對角線螢幕尺寸範圍為4 吋
查看修訂版
手持設備實現:
- [ 7.1 .1.1/H-0-1] 必須至少有一個
Android 相容顯示器,滿足本文檔中所述的所有要求。顯示器短邊至少為 2.2 英寸,長邊至少為 3.4 英寸。
如果手持裝置實現支援軟體螢幕旋轉,則它們:
- [ 7.1 .1.1/H-1-1]* 必須使可供第三方應用程式使用的邏輯螢幕的短邊至少為 2 英寸,長邊至少為 2.7 英寸。搭載 Android API 等級 29 或更早版本的裝置可能不受此要求的約束。
如果手持裝置實施不支援軟體螢幕旋轉,則:
- [ 7.1 .1.1/H-2-1]* 必須使可供第三方應用程式使用的邏輯螢幕的短邊至少為 2.7 吋。搭載 Android API 等級 29 或更早版本的裝置可能不受此要求的約束。
開始新的要求
如果手持裝置實作聲明
android.hardware.audio.output
和android.hardware.microphone
,它們:[ 5.6 /H-1-1] 在以下資料路徑上,5 次測量的平均連續往返延遲必須為300毫秒或更短,平均絕對偏差小於30 毫秒:“揚聲器到麥克風”,3.5 毫米環回適配器(如果支援)、USB 環回(如果支援)。
[ 5.6 /H-1-2] 在揚聲器到麥克風資料路徑上的至少 5 次測量中,平均點擊音延遲必須為300毫秒或更短。
如果手持設備實施包括至少一個觸覺執行器,則它們:
- [ 7.10 /H]* 不應使用偏心旋轉質量 (ERM) 觸覺致動器(振動器)。
- [ 7.10 /H]* 應在android.view.HapticFeedbackConstants中實現清晰觸覺的所有公共常數,即(CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、KEYBOARD_TAP、MLOUUDMRI_MITA_UUUUotD、TLOA_UUUDDMLOULOUU_BUSB.B.FAV_PR_MIT、AUAND JECT、GESTURE_ START和GESTURE_END )。
- [ 7.10 /H]* 應實作android.os.VibrationEffect中用於清晰觸覺的所有公共常數,即(EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK 和 EFFECT_DOUBLE_CLICK),以及在所有觸覺.os.VibrationEect.os.VibitionEect .公共
PRIMITIVE_*
常數,即(點擊、滴答聲、低滴答聲、快速下降、快速上升、慢速上升、旋轉、轟鳴)。其中一些原語(例如 LOW_TICK 和 SPIN)可能僅在振動器可以支援相對較低的頻率時才可行。 - [7.10/H]* 應遵循將android.view.HapticFeedbackConstants中的公共常數對應到建議的android.os.VibrationEffect常數的指南,並具有相應的幅度關係。
- [ 7.10 /H]* 應遵循createOneShot()和createWaveform() API 的品質評估。
- [ 7.10 /H]* 應驗證公共android.os.Vibrator.hasAmplitudeControl() API 的結果是否正確反映了其振動器的功能。
- [ 7.10 /H]* 應將執行器放置在通常用手握住或觸摸設備的位置附近。
如果手持設備實施包括至少一個通用7.10線性諧振執行器,則它們:
- [ 7.10 /H] 應將執行器放置在通常用手握住或觸摸設備的位置附近。
- [ 7.10 /H] 應在裝置自然
縱向的 X 軸(左右)上移動觸覺致動器。
如果手持裝置實現具有通用觸覺執行器,即 X 軸線性諧振執行器 (LRA),則它們:
- [ 7.10 /H] X 軸 LRA 的諧振頻率應低於 200 Hz。
- [ 7.1 .1.1/H-0-1] 必須至少有一個
查看修訂版
手持設備實作必須支援以下視訊編碼格式並使其可供第三方應用程式使用:
- [ 5.2 /H-0-3] AV1
手持設備實作必須支援以下視訊解碼格式並使其可供第三方應用程式使用:
- [ 5.3 /H-0-6] AV1
查看修訂版
如果手持設備實作包括對
ControlsProviderService
和Control
API 的支援並允許第三方應用程式發佈裝置控件,那麼它們:- [ 3.8 .16/H-1-6] 設備實作必須準確地呈現使用者可供性,如下所示:
- 如果裝置已設定
config_supportsMultiWindow=true
且應用程式在ControlsProviderService
聲明中聲明元資料META_DATA_PANEL_ACTIVITY
,包括有效活動的 ComponentName(由 API 定義),則應用程式必須將所述活動嵌入到此使用者功能中。 - 如果應用程式未宣告元資料
META_DATA_PANEL_ACTIVITY
,則它必須呈現ControlsProviderService
API 提供的指定欄位以及Control API 提供的任何指定欄位。
- 如果裝置已設定
- [ 3.8 .16/H-1-7] 如果應用程式聲明了元資料
META_DATA_PANEL_ACTIVITY
,則在啟動嵌入式活動時,它必須使用EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
傳遞 [3.8.16/H-1-5] 中定義的設定值。
如果設備實現允許用戶撥打任何類型的電話,他們
- [ 7.4.1.2 /H-0-1] 必須聲明功能標誌
android.software.telecom
。 - [ 7.4.1.2/H-0-2 ] 必須實現電信架構。
- [ 3.8 .16/H-1-6] 設備實作必須準確地呈現使用者可供性,如下所示:
查看修訂版
手持設備實現:
- [ 8.5 /H-0-2]必須提供使用者停止正在執行前台服務或使用者啟動作業的應用程式的功能。
查看修訂版
如果裝置實作聲明支援android.hardware.telephony
,則:
- [ 9.5 /H-1-1] 不得將
UserManager.isHeadlessSystemUserMode
設為true
。
如果裝置實作具有安全鎖定畫面並包含一個或多個實作TrustAgentService
系統 API 的信任代理,則它們:
- [ 9.11.1 /H-1-1] 必須以高於每 72 小時一次的頻率向使用者詢問建議的主要驗證方法之一(例如:PIN、圖案、密碼)。
如果手持裝置實作將UserManager.isHeadlessSystemUserMode
設為true
,則它們
如果手持裝置實作支援系統 API HotwordDetectionService
或其他沒有麥克風存取指示的熱字偵測機制,則它們:
- [9.8/H-1-1] 必須確保熱詞偵測服務只能將資料傳輸到 System、
ContentCaptureService
或由SpeechRecognizer#createOnDeviceSpeechRecognizer()
所建立的裝置上語音辨識服務。 - [9.8/H-1-6] 不得允許在每個成功的熱詞結果上從熱詞偵測服務傳輸超過 100 個位元組的資料(不包括音訊串流) 。
- [9.8/H-1-15] 必須確保在成功的熱詞結果上提供的音訊串流從熱詞偵測服務到語音互動服務的單向傳輸。
如果設備實作包括使用系統 API HotwordDetectionService
應用程序,或類似的沒有麥克風使用指示的熱詞檢測機制,則該應用程式:
- [9.8/H-2-3] 不得從熱詞偵測服務傳輸音訊資料、可用於重建(全部或部分)音訊的資料或與熱字本身無關的音訊內容,除了
ContentCaptureService
或裝置上的語音辨識服務。
如果手持裝置實作支援系統 API VisualQueryDetectionService
或其他沒有麥克風和/或攝影機存取指示的查詢偵測機制,則它們:
- [9.8/H-3-1] 必須確保查詢偵測服務只能將資料傳輸到系統、
ContentCaptureService
或裝置上語音辨識服務(由SpeechRecognizer#createOnDeviceSpeechRecognizer()
建立)。 - [9.8/H-3-2] 不得允許從
VisualQueryDetectionService
傳輸任何音訊或視訊訊息,但ContentCaptureService
或裝置上語音辨識服務除外。 - [9.8/H-3-3] 當裝置偵測到使用者意圖與數位助理應用程式互動時(例如,透過攝影機偵測使用者存在),必須在系統 UI 中顯示使用者通知。
- [9.8/H-3-4] 必須顯示麥克風指示器,並在偵測到使用者查詢後立即在 UI 中顯示偵測到的使用者查詢。
- [9.8/H-3-5] 不得允許使用者可安裝的應用程式提供可視化查詢檢測服務。
查看修訂版
如果手持設備實作為android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
返回android.os.Build.VERSION_CODES.T
,那麼它們:
- 必須符合Android 13 CDD 第 2.2.7.1 節中列出的媒體要求。
開始新的要求
如果手持設備實作為android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
返回android.os.Build.VERSION_CODES.U
,那麼它們:- [5.1/H-1-1] 必須透過
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法通告可以在任何編解碼器組合中同時運行的硬體視訊解碼器會話的最大數量。 - [5.1/H-1-2] 必須支援任何編解碼器組合中的6 個8 位元(SDR) 硬體視訊解碼器會話實例(AVC、HEVC、VP9、AV1 或更高版本),並以1080p 分辨率@30 fps 與3 個會話同時運行以及 3 個 4k 解析度@30fps 的會話,除非 AV1。 AV1 編解碼器僅需要支援 1080p 分辨率,但仍需要支援 1080p30fps 的 6 個實例。
- [5.1/H-1-3] 必須透過
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法通告可以在任何編解碼器組合中同時運行的硬體視訊編碼器會話的最大數量。 - [5.1/H-1-4] 必須在任何編解碼器組合中支援6 個8 位元(SDR) 硬體視訊編碼器會話實例(AVC、HEVC、VP9、AV1 或更高版本),並以1080p 分辨率@30 fps 與4 個會話同時運行以及 2 個 4k 解析度@30fps 的會話,除非 AV1。 AV1 編解碼器僅需要支援 1080p 分辨率,但仍需要支援 1080p30fps 的 6 個實例。
- [5.1/H-1-5] 必須透過
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法通告可以在任何編解碼器組合中同時執行的硬體視訊編碼器和解碼器會話的最大數量。 - [5.1/H-1-6] 必須在與3 個4K 會話同時運行的任何編解碼器組合中支援6 個8 位元(SDR) 硬體視訊解碼器和硬體視訊編碼器會話(AVC、HEVC、VP9、 AV1 或更高版本)實例@30fps 解析度(AV1 除外),其中最多 2 個編碼器會話和 3 個 1080p 解析度會話。 AV1 編解碼器僅需要支援 1080p 分辨率,但仍需要支援 1080p30fps 的 6 個實例。
- [5.1/H-1-19] 必須支援以4K@30fps 解析度同時運作的任何編解碼器組合中的3 個10 位元(HDR) 硬體視訊解碼器和硬體視訊編碼器工作階段(AVC、HEVC、VP9 、AV1 或更高版本)實例(除非 AV1)其中最多 1 個是編碼器會話,可以透過 GL 表面以 RGBA_1010102 輸入格式進行設定。如果從 GL 表面進行編碼,則不需要編碼器產生 HDR 元資料。 AV1 編解碼器會話僅需要支援 1080p 分辨率,即使此要求需要 4K。
- [5.1/H-1-7] 在負載下,所有硬體視訊編碼器的 1080p 或更小的視訊編碼會話的編解碼器初始化延遲必須為 40 毫秒或更短。此處的載入被定義為使用硬體視訊編解碼器以及 1080p 音訊視訊錄製初始化的並發 1080p 到 720p 僅視訊轉碼會話。對於杜比視界編解碼器,編解碼器初始化延遲必須為 50 毫秒或更短。
- [5.1/H-1-8] 在負載下,所有音訊編碼器的 128 kbps 或更低位元率音訊編碼會話的編解碼器初始化延遲必須為 30 ms 或更短。此處的載入被定義為使用硬體視訊編解碼器以及 1080p 音訊視訊錄製初始化的並發 1080p 到 720p 僅視訊轉碼會話。
- [5.1/H-1-9] 必須在任何編解碼器組合中支援2 個安全硬體視訊解碼器會話實例(AVC、HEVC、VP9、AV1 或更高版本),同時以4k 解析度@30 fps(除非AV1)運行,適用於8-位元 (SDR) 和 10 位元 HDR 內容。 AV1 編解碼器會話僅需要支援 1080p 分辨率,即使此要求需要 4K。
- [5.1/H-1-10] 必須在任何編解碼器中支援3 個非安全硬體視訊解碼器會話實例以及1 個安全硬體視訊解碼器會話實例(總共4 個實例)(AVC、HEVC、VP9、 AV1 或更高版本)組合同時運行3 個4K 解析度@ 30 fps 的會話(除非AV1),其中包括一個安全解碼器會話和1 個1080p 解析度@ 30 fps 的nn 安全會話,其中最多2 個會話可以採用10 位元HDR。 AV1 編解碼器會話僅需要支援 1080p 分辨率,即使此要求需要 4K。
- [5.1/H-1-11] 必須支援設備上每個硬體 AVC、HEVC、VP9 或 AV1 解碼器的安全解碼器。
- [5.1/H-1-12] 在負載下,所有硬體視訊解碼器的 1080p 或更小的視訊解碼會話的編解碼器初始化延遲必須為 40 ms 或更短。此處的載入被定義為使用硬體視訊編解碼器以及 1080p 音訊視訊播放初始化的並發 1080p 到 720p 僅視訊轉碼會話。對於杜比視界編解碼器,編解碼器初始化延遲必須為 50 毫秒或更短。
- [5.1/H-1-13] 在負載下,所有音訊解碼器的 128 kbps 或更低位元率音訊解碼工作階段的編解碼器初始化延遲必須為 30 ms 或更短。此處的載入被定義為使用硬體視訊編解碼器以及 1080p 音訊視訊播放初始化的並發 1080p 到 720p 僅視訊轉碼會話。
- [5.1/H-1-14] 必須支援 AV1 硬體解碼器 Main 10、Level 4.1 和膠片顆粒。
- [5.1/H-1-15] 必須至少有 1 個支援 4K60 的硬體視訊解碼器。
- [5.1/H-1-16] 必須至少有 1 個支援 4K60 的硬體視訊編碼器。
- [5.3/H-1-1] 對於負載下的 4K 60 fps 視訊會話,不得在 10 秒內遺失超過 1 幀(即幀丟失率低於 0.167%)。
- [5.3/H-1-2] 在 4K 會話負載下的 60 fps 視訊會話中,在視訊解析度變更期間,10 秒內不得丟棄超過 1 幀。
- [5.6/H-1-1] 使用 CTS Verifier 點選音調測試時,點擊音調延遲必須為 80 毫秒或更短。
- [5.6/H-1-2] 在至少一條受支援的資料路徑上,往返音訊延遲必須為 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.6/H-1-9] 必須支援至少 12 個通道混合。這意味著能夠打開具有 7.1.4 通道遮罩的 AudioTrack 並正確地將所有通道空間化或縮混為立體聲。
- [5.6/H-SR] 強烈建議支援 24 通道混合,至少支援 9.1.6 和 22.2 通道遮罩。
- [5.7/H-1-2] 必須支援具有以下內容解密功能的
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
。
最小樣本量 | 4MB |
最小子樣本數 - H264 或 HEVC | 32 |
最小子樣本數 - VP9 | 9 |
最小子樣本數 - AV1 | 288 |
最小子樣本緩衝區大小 | 1 MiB |
最小通用加密緩衝區大小 | 500 KB |
最小並發會話數 | 30 |
每個會話的最小密鑰數量 | 20 |
最小密鑰總數(所有會話) | 80 |
DRM 金鑰的最小總數(所有會話) | 6 |
訊息大小 | 16 KB |
每秒解密影格數 | 60 幀/秒 |
- [5.1/H-1-17] 必須至少有 1 個支援 AVIF 基線設定檔的硬體影像解碼器。
- [5.1/H-1-18] 必須支援 AV1 編碼器,該編碼器可以以 30fps 和 1Mbps 編碼高達 480p 的解析度。
-
[5.12/H-1-1] 必須[5.12/H-SR] 強烈建議支援設備上存在的所有硬體 AV1 和 HEVC 編碼器的Feature_HdrEditing
功能。 - [5.12/H-1-2] 裝置上存在的所有硬體 AV1 和 HEVC 編碼器必須支援 RGBA_1010102 顏色格式。
- [5.12/H-1-3] 必須通告對 EXT_YUV_target 擴展的支持,以從 8 位元和 10 位元的 YUV 紋理中進行取樣。
- [7.1.4/H-1-1] 資料處理單元 (DPU) 硬體編輯器 (HWC) 中必須至少有 6 個硬體覆蓋層,其中至少 2 個能夠顯示 10 位元影片內容。
如果手持設備實作為android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
返回android.os.Build.VERSION_CODES.U
並且它們包含對硬體 AVC 或 HEVC 編碼器的支持,那麼它們:
- [5.2/H-2-1] 必須滿足硬體 AVC 和 HEVC 編解碼器的視訊編碼器率失真曲線定義的最低品質目標,如即將發布的文件中所定義。
查看修訂版
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
返回android.os.Build.VERSION_CODES.U
,那麼它們:- [ 7.5 /H-1-1] 必須有一個主後置鏡頭,解析度至少為 1200 萬像素,支援 4k@30fps 影片拍攝。主後置相機是相機 ID 最低的後置相機。
- [ 7.5 /H-1-2] 必須有一個解析度至少為 600 萬像素的前置主鏡頭,並支援 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 分辨率,相機 2 JPEG 捕獲延遲必須小於 1000
900毫秒(根據 ITS 照明條件 (3000K) 下的 CTS 相機性能測試對兩個主相機進行測量)。 - [ 7.5 /H-1-6] 兩個主相機的攝影機 2 啟動延遲(開啟攝影機到第一個預覽畫面)必須 < 500 毫秒,由 CTS 攝影機效能測試在 ITS 照明條件 (3000K) 下測量。
- [ 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
功能。 - [ 7.5 /H-1-15] 必須透過主相機的 CameraX 和 Camera2 擴充來支援
散景和夜間模式擴充。 - [ 7.5 /H-1-16] 必須支援主相機的 DYNAMIC_RANGE_TEN_BIT 功能。
- [ 7.5 /H-1-17] 必須支援主攝影機的CONTROL_SCENE_MODE_FACE_PRIORITY和人臉偵測( STATISTICS_FACE_DETECT_MODE_SIMPLE或STATISTICS_FACE_DETECT_MODE_FULL )。
查看修訂版
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
返回android.os.Build.VERSION_CODES.U
,那麼它們:- [7.1.1.1/H-2-1] 螢幕解析度必須至少為 1080p。
- [7.1.1.3/H-2-1] 螢幕密度必須至少為 400 dpi。
- [7.1.1.3/H-3-1] 必須具有平均至少支援 1000 尼特的 HDR 顯示器。
- [7.6.1/H-2-1] 必須至少有 8 GB 實體記憶體。
查看修訂版
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
返回android.os.Build.VERSION_CODES.U
,那麼它們:- [8.2/H-1-1] 必須確保至少 150 MB/s 的順序寫入效能。
- [8.2/H-1-2] 必須確保至少 10 MB/s 的隨機寫入效能。
- [8.2/H-1-3] 必須確保至少 250 MB/s 的順序讀取效能。
- [8.2/H-1-4] 必須確保至少 100 MB/s 的隨機讀取效能。
- [8.2/H-1-5] 必須確保並行順序讀取和寫入效能,2 倍讀取和 1 倍寫入效能至少為 50 MB/s。
查看修訂版
電視設備實作必須支援以下視訊編碼格式並使其可供第三方應用程式使用:
- [ 5.2 /T-0-3] AV1
電視設備實作必須支援以下視訊解碼格式並使其可供第三方應用程式使用:
- [ 5.3.2 /T-0-7] AV1
查看修訂版
如果裝置實作具有安全鎖定畫面並包含一個或多個實作TrustAgentService
系統 API 的信任代理,則它們:
- [ 9.11.1 /W-1-1] 必須以高於每 72 小時一次的頻率向使用者詢問建議的主要驗證方法之一(例如:PIN、圖案、密碼)。
查看修訂版
如果設備實作包括對 AM/FM 廣播無線電的支援並將該功能公開給任何應用程序,則它們:
- [ 7.4
.10/A-0-1] 必須聲明對FEATURE_BROADCAST_RADIO
的支持。
外視攝影機是對設備實現外部的場景進行成像的攝像頭,如後視攝像頭。
汽車設備實現:
- 應包括一台或多台外視攝影機。
如果汽車設備實現包括外視攝像頭,對於此類攝像頭,它們:
- [ 7.5 /A-1-1] 不得擁有可透過Android 相機 API存取的外景鏡頭,除非它們符合相機核心要求。
- [ 7.5 /A-SR-1] 強烈建議不要旋轉或水平鏡像相機預覽。
- [ 7.5 /A-SR-2] 強烈建議解析度至少為 1.3 兆像素。
- 應具有定焦或 EDOF(擴展景深)硬體。
- 可在相機驅動程式中實現硬體自動對焦或軟體自動對焦。
如果汽車設備實現包括一個或多個外視攝像頭,並加載外部系統 (EVS) 服務,那麼對於這樣的攝像頭,它們:
- [ 7.5 /A-2-1] 不得旋轉或水平鏡像相機預覽。
汽車設備實現:
- 可能包括一個或多個可供第三方應用程式使用的攝影機。
如果汽車設備實施包括至少一個攝影機並將其提供給第三方應用程序,那麼它們:
後置攝影機是指面向世界的攝像頭,可以位於車輛上的任何位置,並且面向車廂外側;也就是說,它像後視攝影機一樣對車身遠端的場景進行成像。
前置攝影機是指面向使用者的攝影機,可以位於車輛上的任何位置,並且面向車艙內部;也就是說,它為用戶提供圖像,例如用於視訊會議和類似的應用程式。
汽車設備實現:
- [7.5/A-SR-1] 強烈建議包含一台或多檯面向世界的攝影機。
- 可能包括一個或多個面向使用者的攝影機。
- [7.5/A-SR-2] 強烈建議支援多個攝影機的同時串流傳輸。
如果汽車設備實現包括至少一個面向世界的攝像頭,那麼對於這樣的攝像頭,它們:
- [7.5/A-1-1] 必須進行定向,以便相機的長尺寸與 Android 汽車感知器軸的 XY 平面對齊。
- [7.5/A-SR-3] 強烈建議使用定焦或 EDOF(擴展景深)硬體。
- [7.5/A-1-2] 必須將主面向世界的攝影機作為具有最低攝影機 ID 的面向世界的攝影機。
如果汽車設備實現包括至少一個面向用戶的攝像頭,那麼對於這樣的攝像頭:
- [7.5/A-2-1] 主要面向使用者的攝影機必須是具有最低攝影機 ID 的面向使用者的攝影機。
- 可以進行定向,以便攝影機的長尺寸與 Android 汽車感測器軸的 XY 平面對齊。
如果汽車設備實現包括可透過android.hardware.Camera
或android.hardware.camera2
API 存取的攝像頭,那麼它們:
- [7.5/A-3-1] 必須符合第 7.5 節中的核心攝影機要求。
如果汽車設備實現包含無法透過android.hardware.Camera
或android.hardware.camera2
API 存取的攝像頭,那麼它們:
- [7.5/A-4-1] 必須可透過擴充視圖系統服務存取。
如果汽車設備實現包括透過擴展視圖系統服務存取的一個或多個攝像頭,對於此類攝像頭,它們:
- [7.5/A-5-1] 不得旋轉或水平鏡像相機預覽。
- [7.5/A-SR-4] 強烈建議解析度至少為 1.3 兆像素。
如果汽車設備實現包括一個或多個可透過擴展視圖系統服務和android.hardware.Camera
或android.hardware.Camera2
API 存取的攝像頭,那麼對於此類攝像頭,它們:
- [7.5/A-6-1] 必須報告相同的攝影機 ID。
如果汽車設備實作提供專有的相機 API,那麼它們:
- [7.5/A-7-1] 必須使用
android.hardware.camera2
API 或擴充視圖系統 API 實作此類相機 API。
查看修訂版
汽車設備實現:
- [ 3.8 /A-0-1] 不得允許非目前前台使用者的完全二級使用者啟動活動並有權存取任何顯示器上的 UI。
查看修訂版
如果汽車設備實現聲明android.hardware.microphone
,則:
如果汽車設備實作聲明android.hardware.camera.any
,那麼它們:
- [ 9.8.2 /A-2-1] 當應用程式存取即時攝影機資料時,必須顯示攝影機指示器,但當攝影機僅由具有第 9.1 節權限中
定義的角色的應用程式存取時,則必須顯示攝影機指示器帶有 CDD 標識符[C-4-X][C-3-X]。
如果裝置實作具有安全鎖定畫面並包含一個或多個實作TrustAgentService
系統 API 的信任代理,則它們:
- [ 9.11.1 /A-1-1] 必須以高於每 336 小時一次的頻率向使用者詢問建議的主要驗證方法之一(例如:PIN、圖案、密碼)。
3、軟體
查看修訂版
設備實現:
- [C-0-8] 不得支援安裝 API 等級低於 23 的應用程式。
查看修訂版
如果裝置實作報告
android.hardware.nfc.uicc
或android.hardware.nfc.ese
,則:- [C-19-1] 必須實作NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API(如GSM 協會技術規格 TS.26 - NFC 手機要求定義的「EVT_TRANSACTION」) 。
查看修訂版
設備實現:
- [C-0-12] 必須透過
libvulkan.so
函式庫導出核心Vulkan 1.0Vulkan 1.1函數符號的函數符號,以及VK_KHR_surface
、VK_KHR_android_surface
、VK_KHR_swapchain
、VK_KHR_maintenance1
和VK_KHR_get_physical_device_properties2
%。請注意,雖然所有符號都必須存在,但第 7.1.4.2 節更詳細地描述了預期每個相應功能的完整實現的要求。
- [C-0-12] 必須透過
查看修訂版
如果設備實作包括螢幕或視訊輸出,則它們:
- [C-1-5] 必須使用
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
文件VIBRANT
列舉的顏色主題樣式(RAINBOW
參閱android.theme.customization.theme_styles
)EXPRESSIVE
動態色調調色盤,即TONAL_SPOT
、SPRITZ
、FRUIT_SALAD
MONOCHROMATIC
。
- [C-1-5] 必須使用
查看修訂版
如果裝置實作(包括第 7.2.3 節中詳述的最近功能導航鍵)改變了介面,則:
- [C-1-2] 必須實現螢幕固定行為,並提供使用者用於切換該功能的設定選單。
查看修訂版
如果設備實作聲明
android.software.managed_users
,它們:- [C-1-10] MUST ensure that the screenshot data is saved in the work profile storage when a screenshot is captured with a
topActivity
window that has focus (the one the user interacted with last among all activities) and belongs to a work profile應用程式. - [C-1-11] 將螢幕截圖儲存到工作設定檔時,不得擷取除工作設定檔應用程式視窗之外的任何其他螢幕內容(系統列、通知或任何個人設定檔內容)(以確保個人設定文件資料未保存在工作設定檔中)。
- [C-1-10] MUST ensure that the screenshot data is saved in the work profile storage when a screenshot is captured with a
3.9.5 設備策略解析框架:新部分
查看修訂版
如果裝置實作報表
android.software.device_admin
或android.software.managed_users
,那麼它們:- [C-1-1] 必須解決 AOSP 文件中所述的設備策略衝突。
5. 多媒體相容性
查看修訂版
設備實作必須支援以下圖像編碼:
- [C-0-4] AVIF
- 設備必須支援
BITRATE_MODE_CQ
和基線設定檔。
- 設備必須支援
- [C-0-4] AVIF
查看修訂版
設備實作必須支援解碼以下圖像編碼:
[C-0-7] AVIF(基線設定檔)
查看修訂版
格式/編解碼器 細節 支援的文件類型/容器格式 JPEG 基礎+漸進 JPEG (.jpg) 動圖 GIF (.gif) 巴布亞紐幾內亞 PNG (.png) 骨形態發生蛋白 點陣圖 (.bmp) 網路P WebP (.webp) 生的 ARW (.arw)、CR2 (.cr2)、DNG (.dng)、NEF (.nef)、NRW (.nrw)、ORF (.orf)、PEF (.pef)、RAF (.raf)、RW2 ( .rw2)、SRW (.srw) 海伊夫 影像、影像集合、影像序列 HEIF (.heif)、HEIC (.heic) AVIF(基線設定檔) 影像、影像擷取、影像序列基線配置文件 HEIF 容器 (.avif) 查看修訂版
格式/編解碼器 細節 支援的文件類型/容器格式 H.263 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska(.mkv,僅解碼)
H.264AVC 詳細資訊請參閱第 5.2 節和第 5.3節 - 3GPP (.3gp)
- MPEG-4 (.mp4)
- MPEG-2 TS(.ts,不可搜尋)
- Matroska(.mkv,僅解碼)
H.265 HEVC 詳細資訊請參閱第 5.3 節 - MPEG-4 (.mp4)
- Matroska(.mkv,僅解碼)
MPEG-2 主要簡介 - MPEG2-TS(.ts,不可找到)
- MPEG-4(.mp4,僅解碼)
- Matroska(.mkv,僅解碼)
MPEG-4 SP - 3GPP (.3gp)
- MPEG-4 (.mp4)
- Matroska(.mkv,僅解碼)
VP8 詳細資訊請參閱第 5.2 節和第 5.3節 - WebM (.webm)
- 瑪特羅斯卡 (.mkv)
VP9 詳細資訊請參閱第 5.3 節 - WebM (.webm)
- 瑪特羅斯卡 (.mkv)
AV1 詳細資訊請參閱第 5.2 節和第 5.3 節 - MPEG-4 (.mp4)
- Matroska(.mkv,僅解碼)
查看修訂版
如果設備實作支援視訊編解碼器:
- [C-2-1] 所有視訊編解碼器都必須發佈以下大小的可實現的幀速率數據(如果編解碼器支援):
標清(低品質) 標清(高品質) 高清720p 高清1080p 超高畫質 視訊解析度 - 176 x 144 像素(H263、MPEG2、MPEG4)
- 352 x 288 像素(MPEG4 編碼器、H263、MPEG2)
- 320 x 180 像素(VP8、VP8)
- 320 x 240 像素(其他)
- 704 x 576 像素 (H263)
- 640 x 360 像素(VP8、VP9)
- 640 x 480 像素(MPEG4 編碼器)
- 720 x 480 像素(其他, AV1 )
- 1408 x 1152 像素 (H263)
- 1280 x 720 像素(其他, AV1 )
1920 x 1080 像素(MPEG4、 AV1除外) 3840 x 2160 像素(HEVC、VP9、 AV1 ) 查看修訂版
如果設備實現支援任何視訊編碼器並使其可供第三方應用程式使用,則它們:- 在兩個滑動視窗中,幀內(I 幀)間隔之間的位元率不應超過 15%。
- 1 秒滑動視窗內的位元率不應超過 100%。
如果設備實現支援任何視訊編碼器並使其可供第三方應用程式使用,並設置
MediaFormat.KEY_BITRATE_MODE
改為BITRATE_MODE_VBR
,使編碼器工作在可變碼率模式下,那麼,只要不影響最低質量下限,編碼碼率:-
[C-5-1] 在一個滑動視窗內,幀內(I 訊框)間隔之間的位元率不得超過15%。 -
[C-5-2]1 秒滑動視窗內的位元率不得超過 100%。
如果裝置實作支援任何視訊編碼器並使其可供第三方應用程式使用,並將
MediaFormat.KEY_BITRATE_MODE
設定為BITRATE_MODE_CBR
以便編碼器在恆定位元率模式下運行,則編碼位元率:-
[C-6-1] 強烈建議 [C-SR-2]在 1 秒的滑動視窗內不得超過目標位元率 15%。
查看修訂版
如果裝置實作支援 H.263 編碼器並將其提供給第三方應用程序,則它們:
- [C-1-1] 必須支援使用基線設定檔等級 45 的 QCIF 解析度 (176 x 144) 。 SQCIF 解析度是可選的。
應支援所支援的編碼器的動態可配置位元率。
查看修訂版
如果設備實作支援 H.265 編解碼器,則:
- [C-1-1] 必須支援主設定檔等級 3 ,解析度高達 512 x 512 。
應支援下表所示的高清編碼設定檔。- 如果有硬體編碼器,強烈建議 [C-SR-1] 支援720 x 480 SD 設定檔和下表所示的 HD 編碼設定檔。
5.2.6。 AV1 :新部分
查看修訂版
如果設備實作支援 AV1 編解碼器,那麼它們:
- [C-1-1] 必須支援 Main Profile,包括 8 位元和 10 位元內容。
[C-1-2] 必須針對下表中支援的解析度透過
getSupportedFrameRatesFor()
或getSupportedPerformancePoints()
API 發布效能數據,即報告效能數據。[C-1-3] 必須接受 HDR 元資料並將其輸出到位元流
如果 AV1 編碼器是硬體加速的,那麼它:
- [C-2-1] 必須支援最多(含)下表中的 HD1080p 編碼設定檔:
標清 高清720p 高清1080p 超高畫質 視訊解析度 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素 視訊幀率 30 幀/秒 30 幀/秒 30 幀/秒 30 幀/秒 視訊比特率 5Mbps 8Mbps 16Mbps 50Mbps 查看修訂版
如果設備實作支援 H.263 解碼器,則:
- [C-1-1] 必須支援基線設定檔等級 30 (CIF、QCIF 和 SQCIF 解析度@ 30fps 384kbps)和 45 等級(QCIF 和 SQCIF 解析度 @ 30fps 128kbps) 。
查看修訂版
如果裝置實作支援 AV1 編解碼器,則:- [C-1-1] 必須支援 Profile 0,包括 10 位元內容。
如果裝置實作支援 AV1 編解碼器並使其可供第三方應用程式使用,則它們:
- [C-1-1] 必須支援 Main Profile,包括 8 位元和 10 位元內容。
如果設備實現透過硬體加速解碼器提供對 AV1 編解碼器的支持,那麼它們:
- [C-2-1] 當
Display.getSupportedModes()
方法報告的高度等於或大於 720p 時,必須能夠至少解碼下表中的 HD 720p 視訊解碼設定檔。 - [C-2-2] 當
Display.getSupportedModes()
方法報告的高度等於或大於 1080p 時,必須能夠至少解碼下表中的高清 1080p 視訊解碼設定檔。
標清 高清720p 高清1080p 超高畫質 視訊解析度 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素 視訊幀率 30 幀/秒 30 幀/秒 30 幀/秒 30 幀/秒 視訊比特率 5Mbps 8Mbps 16Mbps 50Mbps 如果設備實作透過媒體 API 支援 HDR 設定文件,那麼它們:
- [C-3-1] 必須支援從位元流和/或容器中提取和輸出 HDR 元資料。
- [C-3-2] 必須在裝置螢幕或標準視訊輸出連接埠(例如 HDMI)上正確顯示 HDR 內容。
查看修訂版
如果裝置實作聲明
android.hardware.microphone
,它們:- 應設定音訊輸入靈敏度,以便以 90 dB 聲壓級 (SPL)(在麥克風旁
30 公分的距離處測量) 播放的 1000 Hz 正弦音源在 1770 和 1770 範圍內產生 RMS 2500 的理想響應。 16 位元樣本(或-22.35 db ±3dB 全量程用於浮點/雙精度樣本),用於錄製語音辨識音訊來源的每個麥克風。
- 應設定音訊輸入靈敏度,以便以 90 dB 聲壓級 (SPL)(在麥克風旁
查看修訂版
如果裝置實作聲明了
android.hardware.audio.output
功能,則:- [C-1-4] 必須支援具有浮點輸入和輸出的音訊效果。
- [C-1-5] 必須確保音訊效果支援多個通道,最多可達混音器通道數(也稱為 FCC_LIMIT)。
查看修訂版
如果裝置實作聲明
android.hardware.audio.output
,強烈建議滿足或超過以下要求:- [C-SR-4] AudioTrack.getTimestamp和
AAudioStream_getTimestamp
傳回的輸出時間戳精確到 +/- 1 毫秒。
- [C-SR-4] 強烈建議根據
AAudioStream_getTimestamp
傳回的輸入和輸出時間戳記計算的往返延遲在AAUDIO_PERFORMANCE_MODE_NONE
和AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
揚聲器、有線和無線耳機的測量往返延遲的 30 毫秒內延遲的 30 毫秒內。
- [C-SR-4] AudioTrack.getTimestamp和
7. 硬體相容性
查看修訂版
Android 包含自動調整應用程式資源和適合裝置的 UI 佈局的功能,以確保第三方應用程式在
各種硬體配置上運作良好。各種硬體顯示和配置。 Android 相容顯示器是一個顯示屏,它實現了Android 開發人員 - 螢幕相容性概述、本節 (7.1) 及其小節中描述的所有行為和 API,以及第 2 節中記錄的任何其他裝置類型特定行為。這個CDD。在所有第三方 Android 相容應用程式都可以運行的 Android 相容顯示器上,裝置實作必須正確實作這些 API 和行為,如本節中詳述。開始新的要求
設備實現:
- [C-0-1] 預設情況下,必須僅將第三方應用程式呈現到 Android 相容的顯示器上。
本節要求引用的單位定義如下:
- 物理對角線尺寸。顯示器照明部分的兩個相對角落之間的距離(以英吋為單位)。
每英吋點數 (dpi)密度。 1 英吋的線性水平或垂直跨度所包含的像素數,以每英吋像素數(ppi 或 dpi)表示。在列出dpippi 和 dpi值的地方,水平和垂直 dpi 都必須在列出的範圍內。- 長寬比。螢幕較長尺寸與較短尺寸的像素之比。例如,480x854 像素的顯示器將為 854/480 = 1.779,或大致為「16:9」。
- 與密度無關的像素 (dp) 。虛擬像素
單位歸一化為160 dpi 螢幕,螢幕密度為 160。對於某些密度 d 和像素數量 p,與密度無關的像素數量 dp,計算如下:像素 = dps * (密度/160)dp = (160 / d) * p 。
查看修訂版
如果裝置實作支援具有
UI_MODE_TYPE_NORMAL
尺寸配置的螢幕,並包含與 Android 相容的使用圓角的實體顯示器來渲染這些螢幕,則:- [C-1-1] 必須確保每個此類顯示器至少符合以下要求之一:
- 圓角半徑小於或等於38dp。
當 15 dp x 15 dp 框固定在邏輯顯示的每個角落時,每個框的至少一個像素在螢幕上可見。
應包括使用者切換到帶有矩形角的顯示模式的能力。
開始新的要求
如果裝置實作僅能夠進行
NO_KEYS
鍵盤配置,並且打算報告對UI_MODE_TYPE_NORMAL
ui 模式配置的支持,則它們:- [C-4-1] 佈局尺寸(不包括任何顯示切口)必須至少為 596 dp x 384 dp 或更大。
如果裝置實現包含可折疊的 Android 相容顯示器,或包含多個顯示面板之間的折疊鉸鏈並使此類顯示器可用於呈現第三方應用程序,則它們:
- [C-2-1] 必須實作最新可用的穩定版本的擴充 API或穩定版本的Sidecar API ,以供Window Manager Jetpack函式庫使用。
如果裝置實現包括可折疊的 Android 相容顯示器,或包括多個顯示面板之間的折疊鉸鏈,並且鉸鍊或折疊穿過全螢幕應用程式窗口,則:
- [C-3-1] 必須透過擴充或 Sidecar API 向應用報告鉸鍊或折疊的位置、邊界和狀態。
如果裝置實作包含一個或多個可折疊的 Android 相容顯示區域,或包括多個 Android 相容顯示面板區域之間的折疊鉸鏈並使此類顯示區域可供應用程式使用,則它們:
- [C-4-1] 必須實作視窗管理器擴充 API 層級的正確版本,如即將發布的文件中所述。
7.1.1.2.螢幕長寬比:已刪除
查看修訂版
設備實現:
- [C-0-1]
預設情況下,裝置實作必須僅報告透過DENSITY_DEVICE_STABLE
API在DisplayMetrics
上列出的 Android 框架密度之一,且該值必須是每個實體顯示器的靜態值,且不得隨時變更;但是,設備可能會根據使用者在初始啟動後設定的顯示配置變更(例如,顯示尺寸)報告不同的任意密度DisplayMetrics.density
密度。
- 裝置實現應該定義在數值上最接近螢幕物理密度的標準 Android 框架密度,除非該邏輯密度將報告的螢幕尺寸推至支援的最小值以下。如果在數字上最接近物理密度的標準 Android 框架密度導致螢幕尺寸小於支援的最小相容螢幕尺寸(320 dp 寬度),則裝置實現應該報告下一個最低的標準 Android 框架密度。
開始新的要求
- 應定義在數值上最接近螢幕物理密度的標準 Android 框架密度,或對應到手持裝置的相同等效角度視場測量值的值。
如果設備實作提供了
更改設備顯示尺寸的功能,那麼它們:- [C-1-1]
不得將顯示尺寸縮放為大於DENSITY_DEVICE_STABLE
原生密度的 1.5 倍,或產生小於 320dp(相當於資源限定符 sw320dp)的有效最小螢幕尺寸,以先到者為準。 - [C-1-2]
不得將顯示尺寸縮放為小於DENSITY_DEVICE_STABLE
原生密度0.85 倍。
- [C-0-1]
查看修訂版
如果設備實現包括對 Vulkan
1.0 或更高版本的支持,則:[C-1-3] 必須為每個枚舉的
VkPhysicalDevice
完全實作Vulkan 1.0Vulkan 1.1 API。[C-1-5] 不得列舉應用程式包外部的程式庫提供的層,也不得提供追蹤或攔截 Vulkan API 的其他方式,除非應用程式將
android:debuggable
屬性設為true
或將元資料設為com.android.graphics.injectLayers.enable
設定為true
。
- 應支援
VkPhysicalDeviceProtectedMemoryFeatures
和VK_EXT_global_priority
。
- [C-1-13] 必須符合Android 基準 2021 設定檔指定的要求。
[C-SR-5] 強烈建議支援
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
和VK_EXT_global_priority
。[C-SR-6] 強烈建議將
SkiaVk
與 HWUI 結合使用。
如果設備實現包括對 Vulkan 1.1 的支援並聲明此處描述的任何 Vulkan 功能標誌,則它們:
- [C-SR-7] 強烈建議使
VK_KHR_external_fence_fd
擴充可供第三方應用程式使用,並使應用程式能夠將柵欄負載匯出到 POSIX 檔案描述符以及從 POSIX 檔案描述符匯入柵欄負載,如此處所述。
查看修訂版
如果設備實現有多個生物識別感測器,它們:
[C-7-1] 當生物辨識處於鎖定狀態(即生物辨識已停用,直到使用者透過主要身分驗證解鎖)或有時限鎖定(即生物辨識被暫時停用,直到使用者等待一定時間間隔)時,必須這樣做由於失敗的嘗試太多,還鎖定了較低生物識別類別的所有其他生物識別。在限時鎖定的情況下,生物辨識驗證的退避時間必須是限時鎖定中所有生物辨識的最大退避時間。
[C-SR-12] 強烈建議,當生物識別處於鎖定狀態(即,生物識別被禁用,直到用戶通過主要身份驗證解鎖)或有時間限制的鎖定(即,生物識別被暫時禁用,直到用戶等待一段時間)間隔)由於失敗的嘗試太多,也鎖定同一生物識別類別的所有其他生物識別。在限時鎖定的情況下,強烈建議生物辨識驗證的退避時間為限時鎖定中所有生物辨識的最大退避時間。
[C-7-2] 必須要求使用者進行建議的主要驗證(例如:PIN、圖案、密碼),以重設鎖定生物辨識的鎖定計數器。可以允許3 類生物辨識技術重置相同或較低類別的鎖定生物辨識技術的鎖定計數器。不得允許2 類或1 類生物辨識技術完成任何生物辨識技術的重置鎖定操作。
如果設備實現希望將生物識別感測器視為1 類(以前稱為便利),則:
[C-1-12] 根據Android 生物辨識測試協議的測量,每種演示攻擊工具 (PAI) 的欺騙和冒名頂替者接受率不得高於 40%。
[C-SR-13] 強烈建議按照Android 生物辨識測試協議的測量,每個演示攻擊工具 (PAI) 種類的欺騙和冒名頂替者接受率不高於 30%。
[C-SR-14] 強烈建議揭露生物辨識感測器的生物辨識類別以及啟用該感測器的相應風險。
[C-SR-17] 強烈建議實作新的 AIDL 介面(例如
IFace.aidl
和IFingerprint.aidl
)。
如果設備實現希望將生物識別感測器視為2 類(以前稱為Weak ),則:
- [C-SR-15] 強烈建議按照Android 生物辨識測試協議的測量,每種演示攻擊工具 (PAI) 的欺騙和冒名頂替者接受率不高於 20%。
- [C-2-3] 必須在 Android 使用者或核心空間以外的隔離執行環境(例如可信任執行環境 (TEE))中執行生物辨識匹配,
或在具有通往隔離執行環境的安全通道的晶片上或在受保護的環境中執行生物辨識匹配符合第 9.17 節要求的虛擬機器。 - [C-2-4] 必須對所有可識別資料進行加密和加密身份驗證,以便無法在隔離執行環境或具有通往隔離執行環境的安全通道的晶片之外獲取、讀取或更改這些資料(如實施指南中所述)在 Android 開源專案網站或由虛擬機器管理程式控制的受保護虛擬機器上,符合第 9.17 節中的要求。
- [C-2-5] 對於基於攝影機的生物辨識技術,在進行基於生物辨識的身份驗證或註冊時:
- 必須以某種模式操作相機,以防止相機幀在隔離執行環境或具有到隔離執行環境的安全通道的晶片或由滿足第 9.17 節要求的管理程式控制的受保護虛擬機器之外被讀取或更改。
- 對於 RGB 單鏡頭解決方案,相機幀可以在隔離執行環境之外讀取,以支援註冊預覽等操作,但仍不得更改。
- [C-2-7] 不得允許在 TEE 上下文之外或由滿足第 1 節要求的虛擬機器管理程式控制的受保護虛擬機器中對可識別生物識別資料或從中派生的任何資料(例如嵌入資料)進行未加密的存取9.17 。在 Android 版本 9 或更早版本上啟動的升級裝置無法免除 C-2-7。
如果設備實現希望將生物識別感測器視為3 類(以前稱為Strong ),則:
- [C-SR-16] 強烈建議按照Android 生物辨識測試協議的測量,每種演示攻擊工具 (PAI) 的欺騙和冒名頂替者接受率不高於 7%。
7.3.13. IEEE 802.1.15.4(超寬頻) :
查看修訂版
如果設備實作包括對 802.1.15.4 的支援並向第三方應用程式公開該功能,則它們:
- [C-1-2] 必須報告硬體功能標誌
android.hardware.uwb
。 - [C-1-3] 必須支援 AOSP 實作中定義的所有以下配置集( FIRA UCI參數的預定義組合)。
-
CONFIG_ID_1
:FiRa 定義的單播STATIC STS DS-TWR
測距,延遲模式,測距間隔 240 ms。 -
CONFIG_ID_2
:FiRa 定義的一對多STATIC STS DS-TWR
測距,延遲模式,測距間隔 200 ms。典型用例:智慧型手機與許多智慧型裝置互動。 -
CONFIG_ID_3
:與CONFIG_ID_1
相同,但不報告到達角 (AoA) 資料。 -
CONFIG_ID_4
:與CONFIG_ID_1
相同,但啟用了 P-STS 安全模式。 -
CONFIG_ID_5
:與CONFIG_ID_2
相同,但啟用了 P-STS 安全模式。 -
CONFIG_ID_6
:與CONFIG_ID_3
相同,但啟用了 P-STS 安全模式。 -
CONFIG_ID_7
:與CONFIG_ID_2
相同,但啟用了 P-STS 單獨受控者按鍵模式。
-
- [C-1-4] 必須提供使用者可供性,以允許使用者切換 UWB 無線電的開/關狀態。
- [C-1-5] 必須強制要求使用 UWB 無線電的應用程式持有
UWB_RANGING
權限(位於NEARBY_DEVICES
權限群組下)。
- [C-1-2] 必須報告硬體功能標誌
查看修訂版
Android API 和本文檔中使用的「電話」特別指與撥打語音通話和發送 SMS 訊息或透過行動裝置(例如 GSM、CDMA、LTE、NR)GSM 或 CDMA 網路建立行動資料相關的硬體。支援「電話」的設備可以選擇提供部分或全部適合該產品的通話、訊息和資料服務。
透過 GSM 或 CDMA 網路。雖然這些語音通話可能會或可能不會進行資料包交換,但出於 Android 的目的,它們被視為獨立於可能使用相同網路實現的任何資料連線。換句話說,Android「電話」功能和 API 特指語音通話和簡訊。例如,無法撥打電話或發送/接收 SMS 訊息的設備實作不被視為電話設備,無論它們是否使用蜂窩網路進行數據連接。查看修訂版
如果設備實作包括對 802.11 的支援並向第三方應用程式公開該功能,則它們:
- [C-1-4] 必須支援多重播送 DNS (mDNS),且不得在任何操作時間(包括螢幕不處於活動狀態時)過濾 mDNS 封包(224.0.0.251或 ff02::fb ),除非丟棄或過濾這些資料包對於保持在適用於目標市場的監管要求所要求的功耗範圍內是必要的。
對於 Android TV 裝置實現,即使處於待機電源狀態也是如此。
- [C-1-4] 必須支援多重播送 DNS (mDNS),且不得在任何操作時間(包括螢幕不處於活動狀態時)過濾 mDNS 封包(224.0.0.251或 ff02::fb ),除非丟棄或過濾這些資料包對於保持在適用於目標市場的監管要求所要求的功耗範圍內是必要的。
查看修訂版
如果設備實作宣告 FEATURE_BLUETOOTH_LE,則:
- [C-SR-2] 強烈建議測量和補償 Rx 偏移,以確保距以
ADVERTISE_TX_POWER_HIGH
傳輸的參考設備 1m 距離處的中位數 BLE RSSI 為 -60dBm +/-10 dB,其中設備定向為:在「平行平面」上,螢幕面向同一方向。 - [C-SR-3] 強烈建議測量和補償 Tx 偏移,以確保從位於 1m 距離的參考設備進行掃描並以
ADVERTISE_TX_POWER_HIGH
進行傳輸(其中設備定向)時,中位BLE RSSI 為-60dBm +/- 10 dB這樣它們就位於「平行平面」上,螢幕面向同一方向。
- [C-10-3] 必須測量並補償 Rx 偏移,以確保距離以
ADVERTISE_TX_POWER_HIGH
進行傳輸的參考設備 1m 處,BLE RSSI 中位數為 -55dBm +/-10 dB。 - [C-10-4] 必須測量並補償 Tx 偏移,以確保從位於 1m 距離的參考設備進行掃描並以
ADVERTISE_TX_POWER_HIGH
進行傳輸時,BLE RSSI 中位數為 -55dBm +/-10 dB。
如果裝置實作支援藍牙版本 5.0,那麼它們:
- [C-SR-4] 強烈建議為以下方面提供支持:
- LE 2M 物理層
- LE 編解碼器 PHY
- LE 廣告擴展
- 定期廣告
- 至少10組廣告
- 至少 8 個 LE 並發連線。每個連線都可以處於任一連線拓樸角色中。
- LE 連結層隱私
- 「解析清單」大小至少 8 個條目
- [C-SR-2] 強烈建議測量和補償 Rx 偏移,以確保距以
查看修訂版
- [C-1-7] 必須確保距離參考設備 1m 處的距離測量值的中位數在 [0.75m, 1.25m] 範圍內,其中地面真實距離是從 DUT 的頂部邊緣測量的。
面朝上並傾斜 45 度。
- [C-1-7] 必須確保距離參考設備 1m 處的距離測量值的中位數在 [0.75m, 1.25m] 範圍內,其中地面真實距離是從 DUT 的頂部邊緣測量的。
查看修訂版
後置相機是位於裝置與顯示器相對的一側的攝影機;也就是說,它像傳統相機一樣對設備遠端的場景進行成像。
後置攝像頭是面向世界的攝像頭,可以像傳統攝像頭一樣對設備遠端的場景進行成像;在手持裝置上,這是位於裝置與顯示器相對的一側的攝影機。
查看修訂版
前置相機是與顯示器位於裝置同一側的相機;也就是說,通常用於對使用者進行成像的相機,例如用於視訊會議和類似應用。
前置鏡頭是面向使用者的鏡頭,通常用於對使用者進行成像,例如用於視訊會議和類似應用;在手持裝置上,這是位於裝置與顯示器同一側的攝影機。
查看修訂版
外部攝影機是可以隨時物理連接到設備實現或從設備實現分離並且可以面向任何方向的攝影機;例如USB攝影機。
查看修訂版
設備實作必須為所有可用相機的相機相關 API 實作以下行為。設備實現:
- [C-SR-1] 對於具有多個靠近且面向相同方向的 RGB 攝影機的設備,強烈建議支援列出功能
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
的邏輯攝影機設備,該設備由面向該方向的所有 RGB 攝影機組成作為物理子裝置.
- [C-SR-1] 對於具有多個靠近且面向相同方向的 RGB 攝影機的設備,強烈建議支援列出功能
查看修訂版
符合以下所有標準的設備可免除上述要求:
- 使用者無法旋轉的設備實現,例如汽車設備。
查看修訂版
旨在手持或佩戴的裝置可能包括通用觸覺執行器,可用於包括透過鈴聲、警報、通知以及一般觸控回饋引起注意等目的的應用程式。
如果設備實作不包括此類通用觸覺執行器,則它們:
- [7.10/C] 必須為
Vibrator.hasVibrator()
傳回 false。
如果設備實作確實包含至少一個這樣的通用觸覺執行器,那麼它們:
- [C-1-1] 必須為
Vibrator.hasVibrator()
傳回 true。 - 不應使用偏心旋轉質量 (ERM) 觸覺致動器(振動器)。
- 應在
android.view.HapticFeedbackConstants
TEXT_HANDLE_MOVE
實現清晰觸覺的所有公共常量,即(CLOCK_TICK
、CONTEXT_CLICK
、KEYBOARD_PRESS
、KEYBOARD_RELEASE
、 KEYBOARD_TAP 、 LONG_PRESS 、 KEYBOARD_RELEASE 、KEYBOARD_TAP
、LONG_PRESS
、VIRTUAL_KEY_RELEASE
、REJECT
CONFIRM
VIRTUAL_KEY
GESTURE_START
和GESTURE_END
)。 - 應實作
android.os.VibrationEffect
中用於清晰觸覺的所有公共常數(即EFFECT_TICK
、EFFECT_CLICK
、EFFECT_HEAVY_CLICK
和EFFECT_DOUBLE_CLICK
)CLICK
android.os.VibrationEffect.Composition
中使用豐富觸覺的所有可行用於現有PRIMITIVE_*
TICK
、LOW_TICK
)QUICK_FALL
、QUICK_RISE
、SLOW_RISE
、SPIN
、THUD
)。其中一些原語(例如LOW_TICK
和SPIN
可能僅在振動器可以支援相對較低的頻率時才可行。 - 應遵循將
android.view.HapticFeedbackConstants
中的公共常數映射到建議的android.os.VibrationEffect
常數的指南,並具有相應的幅度關係。 - 應使用這些連結的觸覺常數映射。
- 應遵循
createOneShot()
和createWaveform()
API 的品質評估。 - 應驗證公共
android.os.Vibrator.hasAmplitudeControl()
API 的結果是否正確反映了其振動器的功能。 - 應透過執行
android.os.Vibrator.hasAmplitudeControl()
來驗證幅度可擴展性的功能。
如果設備實現遵循觸覺常量映射,則它們:
- 應透過執行
android.os.Vibrator.areAllEffectsSupported()
和android.os.Vibrator.arePrimitivesSupported()
API 來驗證實作狀態。 - 應該對觸覺常數進行品質評估。
- 如果需要,應該驗證和更新不支援的原語的後備配置,如常量實現指南中所述。
- 應提供後備支援以減輕此處所述的失敗風險。
有關設備特定要求,請參閱第2.2.1節。
- [7.10/C] 必須為
9. 安全模型相容性
查看修訂版
設備實現:
- [C-0-4] 兩個使用者介面必須有且只有一種實作。
如果裝置實作預先安裝了包含任何System UI Intelligence 、 System Ambient Audio Intelligence 、 System Audio Intelligence 、 System notification Intelligence 、 System Text Intelligence或System Visual Intelligence角色的任何套件,則這些套件:
- [C-4-1] 必須滿足
「9.8.6 內容擷取」、「9.8.6 作業系統層級和環境資料以及 9.8.15 沙盒 API 實作」部分中概述的裝置實現的所有要求。
- [C-4-2] 不得擁有 android.permission.INTERNET 權限。這比第 9.8.6 節中列出的強烈建議更嚴格。
- [C-4-3] 不得綁定到其他應用,以下系統應用除外:藍牙、通訊錄、媒體、電話、SystemUI 和提供 Internet API 的元件。這比第 9.8.6 節中列出的強烈建議更嚴格。
如果裝置實作包含支援
VoiceInteractionService
預設應用程序,則它們:- [C-5-1] 不得將
ACCESS_FINE_LOCATION
授予該應用程式的預設值。
查看修訂版
如果設備實作創建了上面討論的附加用戶配置文件,那麼它們:
- [C-4-5] 當雙重實例應用程式圖示呈現給使用者時,必須在視覺上區分這些圖示。
- [C-4-6] 必須提供使用者刪除整個複製設定檔資料的功能。
- [C-4-7] 當使用者選擇刪除整個複製設定檔資料時,必須卸載所有複製應用程式、刪除私有應用程式資料目錄及其內容,並刪除複製設定檔資料。
- 當刪除最後一個克隆應用程式時,應提示使用者刪除整個克隆設定檔資料。
- [C-4-8] 必須通知用戶,卸載複製應用程式時,應用程式資料將被刪除,或向用戶提供一個選項,以在從裝置上卸載應用程式時保留應用程式資料。
- [C-4-9] 當使用者在卸載期間選擇刪除資料時,必須刪除私有應用程式資料目錄及其內容。
[C-4-1] 必須允許裝置上主使用者的應用程式處理源自附加設定檔的以下意圖:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] 必須將套用於裝置主使用者的所有裝置策略使用者限制和選定的非使用者限制(如下所列)繼承至此附加使用者設定檔。
[C-4-3] 必須僅允許透過以下意圖寫入此附加設定檔中的聯絡人:
[C-4-4] 不得為此附加使用者設定檔中執行的應用程式執行聯絡人同步。
- [C-4-14] 在此附加設定檔中運行的應用程式必須具有單獨的權限和儲存管理
- [C-4-5] 必須只允許附加設定檔中具有啟動器活動的應用程式存取父用戶設定檔已可存取的聯絡人。
查看修訂版
記憶體安全技術是一種在使用
android:memtagMode
清單選項的應用程式中以高機率 (> 90%) 至少減少以下幾類錯誤的技術:- 堆疊緩衝區溢出
- 免費後使用
- 雙重免費
- 狂野釋放(沒有非 malloc 指針)
設備實現:
- [C-SR-15] 強烈建議設定
ro.arm64.memtag.bootctl_supported
。
如果裝置實作將系統屬性
ro.arm64.memtag.bootctl_supported
設為 true,則:[C-3-1] 必須允許系統屬性
arm64.memtag.bootctl
接受以下值的逗號分隔列表,並在下次重新啟動時套用所需的效果:-
memtag
:啟用上面定義的記憶體安全技術 memtag-once
:上面定義的記憶體安全技術暫時啟用,並在下次重新啟動時自動停用memtag-off
:停用上面定義的記憶體安全技術
-
[C-3-2] 必須允許 shell 使用者設定
arm64.memtag.bootctl
。[C-3-3] 必須允許任何程序讀取
arm64.memtag.bootctl
。[C-3-4] 必須在啟動時將
arm64.memtag.bootctl
設定為目前要求的狀態,如果裝置實作允許在不變更系統屬性的情況下修改狀態,則也必須更新該屬性。[C-SR-16] 強烈建議顯示設定 memtag-once 並重新啟動設備的開發人員設定。有了相容的引導程序,Android開源專案透過MTE引導程式協定滿足上述要求。
- [C-SR-17] 強烈建議在「安全設定」選單中顯示一項允許使用者啟用
memtag
設定。
查看修訂版
設備實現:
- [C-0-2] 必須顯示使用者警告並獲得明確的使用者同意,以允許捕獲使用者螢幕上顯示的任何敏感資訊(啟用後,每次會話擷取時都
包含與 AOSP 完全相同的訊息)螢幕投射或螢幕錄製是透過MediaProjection.createVirtualDisplay()
、VirtualDeviceManager.createVirtualDisplay()
或專有 API啟動的。不得提供使用者停用未來顯示使用者同意的功能。
[C-SR-1] 強烈建議顯示用戶警告,該警告與 AOSP 中實現的訊息完全相同,但只要該訊息明確警告用戶用戶螢幕上的任何敏感資訊已被捕獲,就可以進行更改。
[C-0-4] 不得提供使用者禁止未來提示使用者同意擷取螢幕的提示,除非會話是由使用者允許與 android.app
associate()
的系統應用程式啟動的android.app.role.COMPANION_DEVICE_APP_STREAMING
或android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
設備設定檔。
- [C-0-2] 必須顯示使用者警告並獲得明確的使用者同意,以允許捕獲使用者螢幕上顯示的任何敏感資訊(啟用後,每次會話擷取時都
9.8.6。作業系統層級和環境資料:此部分已從內容擷取和應用程式搜尋重新命名為作業系統層級和環境資料。
查看修訂版
Android 透過系統 API
,支援裝置實現的機制來擷取ContentCaptureService
、AugmentedAutofillService
、AppSearchGlobalManager.query
或其他專有方式應用程式與使用者敏感資料之間的以下應用程式資料互動:- 透過
AugmentedAutofillService
傳送到系統的任何畫面或其他資料。 - 可透過
Content Capture
API 存取的任何畫面或其他資料。 - 可透過
FieldClassificationService
API 存取的任何畫面或其他數據 - 透過
AppSearchManager
API 傳遞到系統並透過AppSearchGlobalManager.query
存取的任何應用程式資料。
- 應用程式透過
Content Capture
API 或AppSearchManager
API(具有類似功能的 Android 和專有 API)向系統提供的任何其他事件。
- 語音辨識器實作使用
SpeechRecognizer#onDeviceSpeechRecognizer()
獲得的音訊資料。 - 透過
AudioRecord
、SoundTrigger
或其他音訊 API 在後台(連續)獲取音訊數據,並且不會產生用戶可見的指示器 - 透過 CameraManager 或其他相機 API 在後台(連續)取得相機數據,並且不會產生使用者可見的指示器
如果設備實現捕獲上述任何數據,它們:
[C-1-3] 必須僅使用隱私保護機制發送所有此類資料
並登出設備,除非每次共享資料時均獲得使用者明確同意。隱私保護機制被定義為“那些只允許進行聚合分析並防止將記錄的事件或派生結果與單個用戶相匹配的機制”,以防止任何每用戶資料被內省(例如,使用差分隱私技術來實現,例如RAPPOR
)。[C-1-5] 不得與不遵循當前部分(9.8.6
內容捕獲操作系統級別和環境數據)中概述的要求的其他操作系統組件共享此類數據,除非每次都得到用戶的明確同意共享。除非此類功能是作為 Android SDK API 建構的(AmbientContext
、HotwordDetectionService
)。[C-1-6]
如果資料以任何形式儲存在裝置上,則必須讓使用者能夠擦除實作或專有方式收集的資料。如果使用者選擇刪除數據,則必須刪除所有收集的歷史資料。ContentCaptureService
- [C-SR-3] 強烈建議使用 Android SDK API 或類似 OEM 擁有的開源儲存庫來實作;和/或在沙盒實作中執行(請參閱 9.8.15 沙盒 API 實作)。
Android 透過
SpeechRecognizer#onDeviceSpeechRecognizer()
提供了在裝置上執行語音辨識的能力,而無需涉及網路。設備上 SpeechRecognizer 的任何實作都必須遵循本節中概述的策略。- 透過
查看修訂版
如果裝置實作聲明
android.hardware.telephony
功能標誌,則:- [C-1-4] 使用
BUGREPORT_MODE_TELEPHONY
產生的報告必須至少包含以下資訊:-
SubscriptionManagerService
轉儲
-
- [C-1-4] 使用
9.8.14。憑證管理員:已刪除
9.8.15。沙盒 API 實作:新部分
查看修訂版
Android 透過一組委託 API 提供了處理安全作業系統層級和環境資料的機制。此類處理可以委託給具有特權存取權和減少通訊功能的預安裝 apk,稱為沙盒 API 實作。
任何沙盒 API 實作:
- [C-0-1] 不得請求 INTERNET 權限。
- [C-0-2] 只能透過結構化 API 存取互聯網,該 API 由使用隱私保護機制的公開開源實作支持,或透過 Android SDK API 間接存取。隱私保護機制被定義為“那些只允許進行聚合分析並防止將記錄的事件或派生結果與單個用戶相匹配的機制”,以防止任何每用戶資料被內省(例如,使用差分隱私技術來實現,例如拉普爾)。
- [C-0-3] 必須將服務與其他系統元件分開(例如,不綁定服務或共用程序 ID),但下列情況除外:
- 電話、聯絡人、系統 UI 和媒體
- [C-0-4] 不得允許使用者將服務替換為使用者可安裝的應用程式或服務
- [C-0-5] 必須僅允許預先安裝的服務擷取此類資料。除非替換功能內建於 AOSP 中(例如數位助理應用程式)。
- [C-0-6] 不得允許預安裝服務機制以外的任何應用程式能夠擷取此類資料。除非這種捕獲功能是透過 Android SDK API 實現的。
- [C-0-7] 必須讓使用者能夠停用服務。
- [C-0-8] 不得忽略使用者管理服務所持有的 Android 權限的能力,並遵循第 9.1 節所述的 Android 權限模型。允許。
查看修訂版
除了 9.8.2 錄製、9.8.6 作業系統層級和環境資料以及 9.8.15 沙盒 API 實作中概述的要求外,還使用透過 AudioRecord、SoundTrigger 或其他音訊 API 在後台(連續)獲取的音訊資料的實現或透過CameraManager 或其他相機API 在後台(連續)取得的相機資料:
- [C-0-1] 必須強制使用相應的指示器(根據第 9.8.2 節「錄製」規定的攝影機和/或麥克風),除非:
- [C-SR-1] 強烈建議要求使用者同意使用此類資料的每項功能,並預設為停用。
- [C-SR-2] 強烈建議採用相同的處理方式(即遵循9.8.2 錄製、9.8.6 作業系統層級和環境資料、9.8.15 沙盒API 實作以及9.8.16 連續音訊和環境中概述的限制)相機資料)到遠端穿戴裝置的相機資料。
如果相機資料是從遠端可穿戴設備提供的,並以 Android 作業系統、沙盒實現或由
WearableSensingManager
構建的沙盒功能之外的未加密形式訪問,那麼它們:- [C-1-1] 必須指示遠端穿戴裝置在此處顯示附加指示器。
如果裝置提供在沒有指定關鍵字的情況下與數位助理應用程式互動的功能(處理一般使用者查詢,或透過攝影機分析使用者狀態):
- [C-2-1] 必須確保此類實作由持有
android.app.role.ASSISTANT
角色的軟體包提供。 - [C-2-2] 必須確保此類實作利用
HotwordDetectionService
和/或VisualQueryDetectionService
Android API。
9.8.17。遙測:新部分
查看修訂版
Android 使用 StatsLog API 儲存系統和應用程式日誌。這些日誌透過 StatsManager API 進行管理,特權系統應用程式可以使用這些 API。
StatsManager 還提供了一種透過隱私保護機制從設備收集隱私敏感資料的方法。特別是,
StatsManager::query
API 提供了查詢StatsLog 中定義的受限指標類別的功能。任何從 StatsManager 查詢和收集受限指標的實作:
- [C-0-1] 必須是裝置上的唯一應用程式/實現,並擁有
READ_RESTRICTED_STATS
權限。 - [C-0-2] 必須僅使用隱私保護機制發送遙測資料和設備日誌。隱私保護機制被定義為“那些只允許進行聚合分析並防止將記錄的事件或派生結果與單個用戶相匹配的機制”,以防止任何每用戶資料被內省(例如,使用差分隱私技術來實現,例如拉普爾)。
- [C-0-3] 不得將此類資料與裝置上的任何使用者身分(例如Account )相關聯。
- [C-0-4] 不得與不遵循目前部分 (9.8.17 隱私權保護遙測) 中概述的要求的其他作業系統元件共享此類資料。
- [C-0-5] 必須提供使用者啟用/停用保護隱私的遙測收集、使用和共享的功能。
- [C-0-6] 如果資料以任何形式儲存在裝置上,則必須讓使用者能夠擦除該實作收集的此類資料。如果使用者選擇刪除數據,則必須刪除目前儲存在裝置上的所有資料。
- [C-0-7] 必須公開開源儲存庫中的底層隱私保護協定實作。
- [C-0-8]必須強制執行本部分的資料傳出策略,以限制StatsLog 中定義的受限指標類別中的資料收集。
- [C-0-1] 必須是裝置上的唯一應用程式/實現,並擁有
查看修訂版
設備實現如果設備實作能夠在每頁的基礎上驗證文件內容,那麼它們:
[
C-0-3C-2-1 ] 支援根據可信任金鑰以加密方式驗證檔案內容,而無需讀取整個檔案。[
C-0-4C-2-2 ] 當讀取內容未根據上述 [C-2-1] 驗證可信任金鑰時,不得允許對受保護檔案的讀取請求成功。
- [C-2-4] 對於已啟用的文件,必須以 O(1) 的時間返回文件校驗和。
查看修訂版
Android Keystore 系統允許應用程式開發人員將加密金鑰儲存在容器中,並透過KeyChain API或Keystore API在加密操作中使用它們。設備實現:
- [C-0-3] 必須限制主身分驗證嘗試失敗的次數。
- [C-SR-2] 強烈建議實施 20 次失敗的主要身份驗證嘗試的上限,如果用戶同意並選擇加入該功能,請在超過失敗的主要身份驗證嘗試的限制後執行「出廠資料重設」。
如果裝置實作新增或修改基於已知秘密的解鎖鎖定畫面的驗證方法,並使用新的驗證方法被視為鎖定畫面的安全方式,則:
- [C-SR-3] 強烈建議 PIN 至少包含 6 位數字,或等效的 20 位熵。
- [C-2-1] 長度小於 6 位數的 PIN 碼不得允許在沒有使用者互動的情況下自動輸入,以避免洩漏 PIN 碼長度。
查看修訂版
設備實現:
- [C-0-1] 必須限制主身分驗證嘗試失敗的次數。
- [C-SR-5] 強烈建議實施 20 次失敗的主要身份驗證嘗試的上限,如果用戶同意並選擇加入該功能,請在超過失敗的主要身份驗證嘗試的限制後執行「出廠資料重設」。
如果裝置實作將數位 PIN 設定為建議的主要驗證方法,則:
- [C-SR-6] 強烈建議 PIN 至少包含 6 位數字,或等效的 20 位熵。
- [C-SR-7] 強烈建議長度小於 6 位元的 PIN 碼不允許在沒有使用者互動的情況下自動輸入,以避免洩漏 PIN 碼長度。
如果裝置實作具有安全鎖定畫面並包含一個或多個實作
TrustAgentService
系統 API 的信任代理,則它們:[C-7-8] 必須至少每72 小時或更短時間向使用者詢問一次建議的主要身份驗證方法(例如:PIN、圖案、密碼),除非考慮到使用者的安全(例如分散駕駛員注意力) 。憂慮。如果裝置實作允許應用程式建立輔助虛擬顯示器並支援關聯的輸入事件(例如透過VirtualDeviceManager) ,且顯示器未標記為 VIRTUAL_DISPLAY_FLAG_SECURE,則它們:
[C-13-10] 必須禁止安裝從虛擬設備啟動的應用程式。查看修訂版
如果裝置實現了對 Android 虛擬化框架 API (
android.system.virtualmachine.*
) 的支持,則 Android 主機:- [C-1-1] 必須支援
android.system.virtualmachine
套件定義的所有 API。 - [C-1-2] 不得修改 Android SELinux 和用於管理受保護虛擬機器(pVM)的權限模型。
- [C-1-3] 不得修改、省略或替換上游 Android 開源專案 (AOSP) 中提供的系統/sepolicy 中存在的 neverallow 規則,且該策略必須在包含所有存在的 neverallow 規則的情況下進行編譯。
- [C-1-4]必須僅允許平台簽署的程式碼,而特權應用程式
不得允許不受信任的程式碼(例如 3p 應用)建立和執行受保護的虛擬機器pVM 。注意:這可能會在未來的 Android 版本中發生變化。
- [C-1-5] 不得允許
受保護的虛擬機pVM執行不屬於工廠映像或其更新的程式碼。Android 驗證啟動未涵蓋的任何內容(例如從 Internet 下載或旁加載的檔案)都不得允許在受保護的虛擬機器中執行。
- [C-1-5] 必須僅允許不可調試的 pVM 執行來自工廠映像或其平台更新的程式碼,其中還包括對特權應用的任何更新。
如果設備實現了對 Android 虛擬化框架 API (
android.system.virtualmachine.*
) 的支持,則任何受保護的虛擬機器pVM實例:- [C-2-1] 必須能夠在
受保護的虛擬機器pVM中執行虛擬化 APEX 中可用的所有作業系統。 - [C-2-2] 不得允許
受保護虛擬機器pVM運作未經設備實作者或作業系統供應商簽署的作業系統。 - [C-2-3] 不得允許
受保護的虛擬機器pVM將資料作為程式碼執行(例如 SELinux 絕不允許 execmem)。
- [C-2-4] 不得修改、省略或替換上游 Android 開源專案 (AOSP) 提供的 system/sepolicy/microdroid 中存在的 neverallow 規則。
- [C-2-5] 即使對於非 Microdroid 作業系統,也必須實作
受保護虛擬機器pVM深度防禦機制(例如用於 pVM 的 SELinux)。 - [C-2-6] 必須確保,如果 pVM
無法驗證VM 將執行的初始映像,則pVM 失敗韌體將拒絕啟動。驗證必須在虛擬機器內部完成。 - [C-2-7] 必須確保,如果 instance.img 的完整性受到損害, pVM 故障
韌體將拒絕啟動。
如果裝置實現了對 Android 虛擬化框架 API (
android.system.virtualmachine.*
) 的支持,則虛擬機管理程式:- [C-3-1] 必須確保虛擬機器(pVM 或主機虛擬機器)獨佔擁有的記憶體頁面只能由虛擬機器本身或虛擬機器管理程式存取,而不能由其他虛擬機器(無論是受保護還是不受保護)訪問。
不得允許任何 pVM 存取屬於另一個實體(即其他 pVM 或虛擬機器管理程式)的頁面,除非頁面所有者明確共用。這包括主機虛擬機器。這適用於 CPU 和 DMA 存取。 - [C-3-2] 必須在pVM使用頁面之後並將其返回主機之前擦除該頁面(例如,pVM 被銷毀)。
- [C-
3-3SR-1 ]強烈建議確保必須確保pVM 韌體先於 pVM 中的任何程式碼載入和執行。 - [C-3-4] 必須確保每個虛擬機器衍生一個每個虛擬機器的金鑰,該金鑰
{提供給 pVM 執行個體的啟動憑證鏈 (BCC) 和複合設備識別碼 (CDI)只能由該特定虛擬機器實例派生,並根據情況進行更改恢復出廠設定和 OTA。
如果設備實現了對 Android 虛擬化框架 API 的支持,則在所有領域:
- [C-4-1] 不得提供 pVM 允許繞過 Android 安全模型的功能。
如果設備實現了對 Android 虛擬化框架 API 的支持,則:
- [C-5-1] 必須能夠支援隔離編譯,但可能會在
ART 執行時間更新的裝置出貨時停用隔離編譯功能。
如果裝置實現了對 Android 虛擬化框架 API 的支持,則對於金鑰管理:
- [C-6-1] 必須在使用者無法修改的位置根 DICE 鏈,即使在解鎖裝置上也是如此。 (以確保它不會被欺騙)。
- [C- SR-2
6-2]強烈建議使用 DICE 作為每個虛擬機器的秘密衍生機制。必須正確進行 DICE,即提供正確的值。
- [C-1-1] 必須支援