安卓14
2024 年 4 月 8 日
2. 設備類型
查看修訂版
查看修訂版
如果手持裝置實作支援系統 API
HotwordDetectionService
或其他沒有麥克風存取指示的熱字偵測機制,則它們:- [9.8/H-1-6] 不得允許在每個成功的熱詞結果上從熱詞檢測服務傳輸超過 100 位元組的數據,透過HotwordAudioStream傳遞的音訊數據除外。
查看修訂版
將 [9.8/H-1-13] 改為:
- [9.8/H-SR-3] 強烈建議至少每小時或每 30 個硬體觸發事件(以先到者為準)重新啟動託管熱詞偵測服務的進程。
查看修訂版
刪除了要求 [9.8.2/H-4-3]、[9.8.2/H-4-4]、[9.8.2/H-5-3]。
查看修訂版
如果手持設備實作為
android.os.Build.VERSION_CODES.U
返回android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,那麼它們:- [ 7.5 /H-1-3] 必須支援
android.info.supportedHardwareLevel
屬性為FULL
或更好的後主相機和LIMITED
或更好的前置主相機。
- [ 7.5 /H-1-3] 必須支援
查看修訂版
如果電視設備實現沒有內建顯示器,而是支援透過 HDMI 連接的外部顯示器,則:
- [ 5.8 /T-0-1]必須將 HDMI 輸出模式設定為所選像素格式的最高解析度,此像素格式適用於外部顯示器的 50Hz 或 60Hz 更新率,取決於裝置銷售區域的視訊更新率必須
設定HDMI 輸出模式以選擇50Hz 或60Hz 更新率可支援的最大解析度。
- [ 5.8 /T-0-1]必須將 HDMI 輸出模式設定為所選像素格式的最高解析度,此像素格式適用於外部顯示器的 50Hz 或 60Hz 更新率,取決於裝置銷售區域的視訊更新率必須
3、軟體
查看修訂版
- 刪除了要求 [C-1-9]
5. 多媒體相容性
查看修訂版
如果裝置實作透過
HDR_TYPE_DOLBY_VISION
聲明支援杜比視界解碼器,則:- [C-1-3] 必須將向後相容的基礎層(如果存在)的軌道 ID設定為與組合杜比視界層的軌道 ID 相同。
7. 硬體相容性
查看修訂版
如果設備實現支援具有
UI_MODE_TYPE_NORMAL
尺寸配置的螢幕並使用帶有圓角的實體顯示器來呈現這些螢幕,則它們:- [C-1-1] 必須確保每個此類顯示器至少符合以下要求之一:
- 當
15和 18 dp x1518 dp 框錨定在邏輯顯示器的每個角落時,每個框的至少一個像素在螢幕上可見。
- 當
- [C-1-1] 必須確保每個此類顯示器至少符合以下要求之一:
查看修訂版
恢復了以下要求:
如果設備實作宣告
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] 和 [C-10-4] 移至2.2.1。硬體.
- [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。
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、MLOUUDDMMM.A 中國_B獎論文、HAV 、GESTURE_START 和GESTURE_END) 。
- [ 7.10 /H]* 應實作android.os.VibrationEffect中用於清晰觸覺的所有公共常數,即(EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK 和 EFFECT_DOUBLE_CLICK),以及android.os.VibrationEect.os.VComposition .公共
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.T
返回android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,那麼它們:
- 必須符合Android 13 CDD 第 2.2.7.1 節中列出的媒體要求。
開始新的要求
如果手持設備實作為android.os.Build.VERSION_CODES.U
返回android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,那麼它們:- [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 個安全解碼器會話和1 個1080p 解析度@30fps 的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.U
返回android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
並且它們包含對硬體 AVC 或 HEVC 編碼器的支持,那麼它們:
- [5.2/H-2-1] 必須滿足硬體 AVC 和 HEVC 編解碼器的視訊編碼器率失真曲線定義的最低品質目標,如即將發布的文件中所定義。
查看修訂版
android.os.Build.VERSION_CODES.U
返回android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,那麼它們:- [ 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.U
返回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.1.1.3/H-3-1] 必須具有平均至少支援 1000 尼特的 HDR 顯示器。
- [7.6.1/H-2-1] 必須至少有 8 GB 實體記憶體。
查看修訂版
android.os.Build.VERSION_CODES.U
返回android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,那麼它們:- [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
文件中列舉的EXPRESSIVE
主題樣式RAINBOW
請參閱android.theme.customization.theme_styles
FRUIT_SALAD
產生動態色調調色盤,即TONAL_SPOT
、VIBRANT
、SPRITZ
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檔案描述符中,如下所述。
請參閱修訂
如果設備實現具有多個生物識別感測器,則它們:
[C-7-1]必須在鎖定中生物識別時(即禁用生物識別,直到用戶使用主要身份驗證解鎖)或時間限制鎖定(即生物識別暫時禁用,直到用戶等待時間間隔為止)由於失敗的嘗試過多,也鎖定了較低的生物辨識類別的所有其他生物辨識技術。在有時間結合的鎖定的情況下,生物辨識驗證的退縮時間必須是時間限制的所有生物辨識技術的最大退縮時間。
強烈建議[C-SR-12]當生物識別限制為鎖定時(即禁用生物識別,直到用戶使用主要身份驗證解鎖)或時間有限的鎖定(即臨時禁用了生物識別,直到用戶等待一段時間間隔)由於失敗的嘗試太多,也鎖定了同一生物辨識類別的所有其他生物辨識技術。在有時間結合的鎖定的情況下,強烈建議對生物辨識驗證的退縮時間是時間限制鎖定中所有生物辨識的最大退縮時間。
[C-7-2]必須向使用者挑戰建議的主要驗證(例如:PIN,圖案,密碼),以重設鎖定計數器以鎖定生物辨識。可以允許3類生物辨識物重置相同或下類別的鎖定生物辨識的鎖定計數器。不得允許2類或1類生物辨識技術完成任何生物辨識技術的重置鎖定操作。
如果設備實施希望將生物識別感測器視為1級(以前是便利),則它們:
[C-1-12]必須具有由Android Biometrics測試方案衡量的欺騙和無名的接受率不高於每個演示攻擊工具(PAI)物種的40%。
[C-SR-13]強烈建議透過Android Biometrics測試方案來衡量,使每個演示攻擊工具(PAI)物種的欺騙和無名的接受率不高於30%。
強烈建議[C-SR-14]揭露生物辨識感測器的生物特徵識別類別以及啟用它的相應風險。
強烈建議[C-SR-17]實施新的AIDL介面(例如,
IFace.aidl
和IFingerprint.aidl
)。
如果設備實施希望將生物識別感測器視為2級(以前較弱),則它們:
- [C-SR-15]強烈建議透過Android Biometrics測試方案測量,具有欺騙和無名的接受率不高於每個演示攻擊工具(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的上下文或由受hypervisor控制的受保護的虛擬機器之外的應用程式處理器的任何資料(例如嵌入),該處理器滿足了部分的要求9.17 。在Android版本9或更早版本上啟動的升級設備不受C-2-7的豁免。
如果設備實施希望將生物識別感測器視為3級(以前是強),則它們:
- [C-SR-16]強烈建議透過Android Biometrics測試方案來衡量,使每個演示攻擊工具(PAI)物種的欺騙和無名的接受率不高於7%。
7.3.13。 IEEE 802.1.15.4(UWB) :
請參閱修訂
如果設備實現包括對802.1.15.4的支援並將功能公開為第三方應用程序,則它們:
- [C-1-2]必須報告硬體功能flag
android.hardware.uwb
。 - [C-1-3]必須支援AOSP實作中定義的所有以下配置集( FIRA UCI參數的預定義組合)。
-
CONFIG_ID_1
:fira定義的單STATIC STS DS-TWR
範圍,遞延模式,範圍間隔240毫秒。 -
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
許可組下)。
通過標準組織(包括FIRA , CCC和CSA )所定義的相關符合和認證測試,有助於確保正確的802.1.15.4函數正確。
- [C-1-2]必須報告硬體功能flag
請參閱修訂
Android API和本文檔使用的「電話」專門指的是與放置語音通話和發送SMS訊息相關的硬件,或透過行動裝置(例如GSM,CDMA,LTE,NR)GSM或CDMA網路建立行動數據。支援「電話」的設備可能會選擇適合產品的某些或全部呼叫,訊息傳遞和資料服務。
透過GSM或CDMA網路。儘管這些語音呼叫可能會或可能不會被切換,但它們是為了獨立於使用相同網路實現的任何資料連接性的Android目的。換句話說,Android「電話」功能和API專門指的是語音通話和SMS。例如,不管他們是否使用蜂窩網路進行數據連接,都無法將呼叫或發送/接收SMS訊息的設備實現視為電話設備。請參閱修訂
如果設備實現包括對802.11的支援並將功能公開為第三方應用程序,則它們:
- [C-1-4]必須支援多播DNS(MDN),且不得過濾MDNS資料包(224.0.0.251或ff02 :: fb ),包括在螢幕不處於活動狀態時,除非下降或丟棄,否則過濾這些資料包是必要的,以保持適用於目標市場的監管要求所需的功耗範圍。
對於Android電視設備實現,即使在備用電源狀態下也是如此。
- [C-1-4]必須支援多播DNS(MDN),且不得過濾MDNS資料包(224.0.0.251或ff02 :: fb ),包括在螢幕不處於活動狀態時,除非下降或丟棄,否則過濾這些資料包是必要的,以保持適用於目標市場的監管要求所需的功耗範圍。
請參閱修訂
如果裝置實作宣告feature_bluetooth_le,則它們:
- 強烈建議[C-SR-2]測量和補償Rx偏移,以確保中間BLE RSSI為-60dBm +/- 10 dB,距離在
ADVERTISE_TX_POWER_HIGH
的參考設備距離1M距離為1M,該設備的方向為它們提供了方向。在「平行平面」上,螢幕面向相同的方向。 - 強烈建議[C-SR-3]測量和補償TX偏移,以確保中間BLE RSSI為-60dBm +/- 10 dB,當時從位於1M距離的參考設備掃描並在
ADVERTISE_TX_POWER_HIGH
處傳輸時,設備定向設備的位置,使它們在「平行平面」上,螢幕面向相同的方向。
- [C-10-3]必須測量並補償RX偏移,以確保中位數為-55dbm +/- 10 dB,距離參考設備在
ADVERTISE_TX_POWER_HIGH
上傳輸的參考設備距離為1M。 - [C-10-4]必須測量和補償TX偏移,以確保從位於1M距離的參考設備掃描並在
ADVERTISE_TX_POWER_HIGH
上傳輸時,將中位數為-55DBM +/- 10 dB。
如果裝置實作支援藍牙5.0版,則它們:
- 強烈建議[C-SR-4]提供支持:
- LE 2M 物理層
- Le編解碼器PHY
- LE 廣告擴展
- 定期廣告
- 至少10個廣告集
- 至少8個並發連接。每個連線都可以扮演任何一個連線拓樸角色。
- LE 連結層隱私
- 至少8個條目的「解決清單」的大小
- 強烈建議[C-SR-2]測量和補償Rx偏移,以確保中間BLE RSSI為-60dBm +/- 10 dB,距離在
請參閱修訂
- [C-1-7]必須確保從參考設備1M處的距離測量值的中位數在[1.75m,125m]之內,其中從DUT的頂部邊緣測量了地面真相距離。
舉起臉,傾斜45度。
- [C-1-7]必須確保從參考設備1M處的距離測量值的中位數在[1.75m,125m]之內,其中從DUT的頂部邊緣測量了地面真相距離。
請參閱修訂
後置相機是位於顯示器對面裝置側面的相機。也就是說,它像傳統的相機一樣在設備的另一側拍攝場景。
後置相機是一個面向世界的鏡頭,它像傳統的相機一樣在設備的另一側拍攝場景;在手持裝置上,這是位於裝置側面的相機。
請參閱修訂
前置鏡頭是與顯示器相同的相機。也就是說,通常用於對使用者進行映像的相機,例如視訊會議和類似的應用程式。
前置鏡頭是一種面向使用者的鏡頭,通常用於對使用者進行映像,例如視訊會議和類似的應用程式;在手持裝置上,它是位於裝置同一側的相機。
請參閱修訂
外部攝影機是可以隨時從設備實現的實體連接或脫離的相機,並且可以面對任何方向。例如USB攝影機。
請參閱修訂
設備實作必須針對所有可用攝影機實現以下行為。設備實現:
- [C-SR-1]對於具有多個RGB攝影機近距離並朝著同一方向面向的設備,強烈建議支援列出能力
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
的邏輯攝影機設備作為物理子設備。
- [C-SR-1]對於具有多個RGB攝影機近距離並朝著同一方向面向的設備,強烈建議支援列出能力
請參閱修訂
符合以下所有標準的設備免於上述要求:
- 無法由使用者旋轉的設備實現,例如汽車設備。
請參閱修訂
打算手持或磨損的設備可能包括通用觸覺執行器,可用於應用程序,包括透過鈴聲,警報,通知以及一般的觸控回饋來吸引註意力。
如果設備實作不包括這樣的通用觸覺執行器,則它們:
- [7.10/c]必須回傳false for forse for
Vibrator.hasVibrator()
。
如果設備實作確實包括至少一個這樣的通用觸覺執行器,則它們:
- [C-1-1]對於
Vibrator.hasVibrator()
必須傳回true。 - 不應使用偏心旋轉質量(ERM)觸覺致動器(振動器)。
- 應在
android.view.HapticFeedbackConstants
中實施所有公共常數(CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,text_handle_movementVIRTUAL_KEY
, fual_handle_move ,VIRTUAL_KEY_RELEASE
,CONFIRM
片REJECT
,GESTURE_START
和GESTURE_END
)。 - 應在
android.os.VibrationEffect
(EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
andEFFECT_DOUBLE_CLICK
TICK
中實施所有公共CLICK
,以及所有可行的publicPRIMITIVE_*
數數android.os.VibrationEffect.Composition
,即LOW_TICK
.QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
)。其中一些原語(例如LOW_TICK
和SPIN
只有在振動器可以支援相對較低的頻率時才可行。 - 應遵循在
android.view.HapticFeedbackConstants
中映射公共常數的指南,以與相應的振幅關係播放android.os.VibrationEffect
。 - 應該使用這些連結的觸覺常數映射。
- 應遵循
createOneShot()
和createWaveform()
API的品質評估。 - 應驗證public
android.os.Vibrator.hasAmplitudeControl()
API的結果正確反映了其振動器的功能。 - 應透過運行
android.os.Vibrator.hasAmplitudeControl()
來驗證振幅可伸縮性的功能。
如果設備實現遵循觸覺常數映射,則它們:
- 應透過執行
android.os.Vibrator.areAllEffectsSupported()
和android.os.Vibrator.arePrimitivesSupported()
API來驗證實作狀態。 - 應該對觸覺常數進行品質評估。
- 應驗證並更新如果需要如實現常數指南中所述的無支撐原始詞的後備配置。
- 如下所述,應提供後備支援以減輕失敗的風險。
有關設備特定要求,請參閱第2.2.1節。
- [7.10/c]必須回傳false for forse for
9.安全模型相容性
請參閱修訂
設備實現:
- [C-0-4]必須具有兩個使用者介面的一個和一個實作。
如果設備實現預先安裝任何包含任何系統UI智能的軟體包,系統環境音頻智能,系統音頻智能,系統通知智能,系統文本智能或系統視覺智能角色,則這些軟體包:
- [C-4-1]必須滿足
「 9.8.6內容擷取」部分中裝置實現的所有要求,「 9.8.6 OS等級和環境資料以及9.8.15沙盒API實作」。
- [C-4-2]不得擁有Android.Permission.Internet授權。這比第9.8.6節所列的強烈推薦要嚴格。
- [C-4-3]除了以下系統應用程式:藍牙,聯絡人,媒體,電話,系統和提供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%)的錯誤類別。- 堆疊緩衝區溢出
- 免費使用後使用
- 雙重免費
- 野外免費(沒有非麥芽指針)
設備實現:
- 強烈建議[C-SR-15]設定
ro.arm64.memtag.bootctl_supported
。
如果裝置實作設定係統屬性
ro.arm64.memtag.bootctl_supported
tum 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]必須顯示使用者警告並獲得明確的使用者同意
,允許啟用在使用者螢幕上顯示的任何敏感資訊啟用了螢幕鑄造或螢幕記錄,透過MediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
或專有API啟動。不得為使用者提供負擔能力,以停用將來的使用者同意顯示。
強烈建議[C-SR-1]顯示一個用戶警告,該警告與AOSP中實現的訊息完全相同,但只要訊息清楚地警告用戶,就可以更改用戶螢幕上的任何敏感資訊。
[C-0-4]除非使用者已允許使用者允許
associate()
與android.app.role.COMPANION_DEVICE_APP_STREAMING
或android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
裝置設定檔。
- [C-0-2]必須顯示使用者警告並獲得明確的使用者同意
9.8.6。 OS等級和環境資料:本節從內容擷取和應用程式搜尋重新命名為OS等級和環境資料。
請參閱修訂
Android,透過系統APIS
,支援裝置實現的機制,以擷取ContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
或其他專有方式應用程式和使用者敏感資料之間的以下應用程式資料互動:- 任何透過
AugmentedAutofillService
螢幕或其他資料傳送到系統。 - 任何可透過
Content Capture
API存取的螢幕或其他資料。 - 透過
FieldClassificationService
API存取的任何畫面或其他數據 - 任何應用程式資料透過
AppSearchManager
API傳遞給系統,並可以透過AppSearchGlobalManager.query
存取。
- 應用程式透過
Content Capture
API或或AppSearchManager
API提供給系統的任何其他事件都是類似功能的Android和專有API。
- 透過語音辨識器實現使用語音
SpeechRecognizer#onDeviceSpeechRecognizer()
獲得的音訊資料。 - 透過
AudioRecord
,SoundTrigger
或其他音訊API在背景(連續)中獲得的音訊數據,並且不會導致用戶可見的指標 - 透過攝影師或其他相機API在背景(連續)中獲得的攝影機數據,並且不會導致用戶可見的指示器
如果設備實現捕獲了上述任何數據,則它們:
[C-1-3]只能使用隱私保護機制發送所有此類資料
並將裝置登錄,除非每次共用資料時明確的使用者同意。隱私保護機制被定義為“只允許總體分析的機制,並防止已記錄事件或向單個用戶衍生結果的匹配”,以防止任何用戶資料具有內省(例如,使用諸如差異隱私技術(例如)RAPPOR
)。[C-1-5]不得與其他不遵循當前部分概述的OS組件共享此類數據(9.8.6
內容捕獲OS級和環境數據),除非每次均具有明確的用戶同意共享。除非作為Android SDK API(AmbientContext
,HotwordDetectionService
)來建構此類功能。[C-1-6]必須提供使用者負擔能力來刪除此類數據,以使
實現或專有方式收集ContentCaptureService
如果資料以設備上的任何形式儲存。如果使用者選擇刪除數據,則必須刪除所有收集的歷史資料。
- 強烈建議[C-SR-3]使用Android SDK API或類似的OEM擁有的開源儲存庫來實作;和 /或在沙盒實作中執行(請參閱9.8.15沙盒API實作)。
Android,透過
SpeechRecognizer#onDeviceSpeechRecognizer()
提供了在設備上執行語音識別的能力,而無需涉及網路。任何實施在裝置上的語音辨識器都必須遵循本節中概述的政策。- 任何透過
請參閱修訂
如果設備實現聲明
android.hardware.telephony
功能標誌,則它們:- [C-1-4]使用
BUGREPORT_MODE_TELEPHONY
產生的報告至少必須包含以下資訊:-
SubscriptionManagerService
轉儲
-
- [C-1-4]使用
9.8.14。憑證管理員:已刪除
9.8.15。沙盒API實現:新部分
請參閱修訂
Android透過一組委託API提供了處理安全OS等級和環境資料的機制。此類處理可以委派給具有特權存取權和降低通訊功能的預先安裝APK,稱為沙盒API實作。
任何沙盒API實作:
- [C-0-1]不得要求網路許可。
- [C-0-2]必須僅透過使用隱私機製或間接透過Android SDK API來支援的結構化API存取Internet。隱私保護機制被定義為“只允許總體分析並防止已記錄事件或向單一用戶派生結果匹配的機制”,以防止任何用戶資料具有內省(例如,使用諸如差異隱私技術(例如)拉牌)。
- [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.16。連續音訊和相機資料:新部分
請參閱修訂
除了在9.8.2錄製中概述的要求,9.8.6 OS級別和環境數據以及9.8.15沙盒API實現之外,還可以利用透過AudioreCord,Soundtrigger或其他AUDIO APIS在後台(連續)獲得的音訊數據或透過攝影師或其他相機API在背景(連續)中獲得的相機資料:
- [C-0-1]必須執行相應的指標(根據第9.8.2節的記錄)執行相應的指標(相機和/或麥克風),除非:
- 強烈建議[C-SR-1]要求使用此類數據的每個功能要求用戶同意,並在預設情況下被停用。
- [C-SR-2]強烈建議採用相同的治療方法(即遵循9.8.2記錄中概述的限制,9.8.6 OS級別和環境數據,9.8.15 Sandboxed API實現,以及9.8.16相機數據)來自來自遠端穿戴裝置的相機數據。
如果相機資料是從遠端可穿戴設備提供的,並以Android OS外的未加密形式訪問,沙盒實現或由
WearableSensingManager
構建的沙盒功能,則它們:- [C-1-1]必須向遠端穿戴裝置指示以在那裡顯示其他指示器。
如果設備提供了與沒有分配的關鍵字的數位助理應用程式互動的能力(要么處理通用用戶查詢,要么透過攝影機分析用戶的存在):
- [C-2-1]必須確保由持有
android.app.role.ASSISTANT
角色的軟體包提供此類實施。 - [C-2-2]必須確保此類實作利用
HotwordDetectionService
和/或VisualQueryDetectionService
Android API。
9.8.17。遙測:新部分
請參閱修訂
使用StatsLog API儲存Android儲存系統和應用程式日誌。這些日誌是透過StatsManager API管理的,可以透過特權系統應用程式使用。
StatsManager還提供了一種方法,可以從具有隱私保存機制的裝置中收集歸類為隱私敏感的資料。特別是,
StatsManager::query
API提供了查詢統計資料中定義的限制度量類別的能力。從StatsManager進行的任何實作查詢和收集限制指標:
- [C-0-1]必須是設備上的唯一應用程式/實現,並保留
READ_RESTRICTED_STATS
許可。 - [C-0-2]只能使用隱私保護機制傳送遙測資料和設備的日誌。隱私保護機制被定義為“只允許總體分析並防止已記錄事件或向單一用戶派生結果匹配的機制”,以防止任何用戶資料具有內省(例如,使用諸如差異隱私技術(例如)拉牌)。
- [C-0-3]不得將此類資料與裝置上的任何使用者身分(例如帳戶)相關聯。
- [C-0-4]不得與其他OS組件共享此類數據,這些組件不遵循當前部分中概述的要求(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密鑰庫系統允許應用程式開發人員將加密密鑰儲存在容器中,並透過鑰匙串API或密鑰庫API在加密操作中使用它們。設備實現:
- [C-0-3]必須限制失敗的主要驗證嘗試的數量。
- 強烈建議[C-SR-2]實現20次失敗的主要身份驗證嘗試的上限,如果用戶同意並選擇了該功能,請在超過失敗的主要身份驗證嘗試的限制後執行「出廠資料重置」。
如果裝置實作新增或修改驗證方法以解鎖鎖定螢幕,如果基於已知秘密並使用新的驗證方法作為鎖定螢幕的安全方法,則:
- [C-SR-3]強烈建議使用銷釘至少6位數或等效的20位熵。
- [C-2-1]長度小於6位的銷釘不得在沒有使用者互動的情況下自動進入,以免揭示銷釘長度。
請參閱修訂
設備實現:
- [C-0-1]必須限制失敗的主要驗證嘗試的數量。
- 強烈建議[C-SR-5]實現20次失敗的主要身份驗證嘗試的上限,如果用戶同意並選擇了該功能,則在超過失敗的主要身份驗證嘗試的限制後執行「出廠資料重置」。
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
如果裝置實作具有安全鎖定畫面並包含一個或多個實作
TrustAgentService
系統 API 的信任代理,則它們:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (cegaction dristraction憂慮。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-10] MUST disable installation of apps initiated from virtual devices.9.17。 Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-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 (pVM) .
- [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 only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM 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.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM 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 MachinepVM 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 MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto 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 ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
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 pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
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 be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
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- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the