安卓13
2023 年 6 月 26 日
2. 設備類型
查看修訂版
如果汽車設備實現是 32 位:
[7.6.1/A-1-1] 如果使用以下任何密度,則內核和用戶空間可用的內存必須至少為 512MB:
- 小/普通屏幕上 280dpi 或更低
- 超大屏幕上的 ldpi 或更低
- 大屏幕上的 mdpi 或更低
[7.6.1/A-1-2] 如果使用以下任一密度,內核和用戶空間可用的內存必須至少為 608MB:
- 小/普通屏幕上的 xhdpi 或更高
- 大屏幕上的 hdpi 或更高
- 超大屏幕上的 mdpi 或更高
[7.6.1/A-1-3] 如果使用以下任何密度,則內核和用戶空間可用的內存必須至少為 896MB:
- 小/普通屏幕上 400dpi 或更高
- 大屏幕上 xhdpi 或更高
- 超大屏幕上的 tvdpi 或更高
[7.6.1/A-1-4] 如果使用以下任何密度,則內核和用戶空間可用的內存必須至少為 1344MB:
- 小/普通屏幕上 560dpi 或更高
- 大屏幕上 400dpi 或更高
- 在超大屏幕上 xhdpi 或更高
3、軟件
查看修訂版
如果設備實現報告android.hardware.telephony.calling
android.hardware.telephony
7. 硬件兼容性
9. 安全模型兼容性
查看修訂版
設備實現:
- 刪除了要求 [C-13-10] 和 9.11.4。
2023 年 3 月 20 日
2. 設備類型
查看修訂版
如果手持設備實現的設置應用程序使用活動嵌入實現拆分功能,那麼它們:
- [
C-17-13.2.3.1/ H-1-1 ] 必須有一個活動在啟用拆分功能時處理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY意圖。 Activity 必須受android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
保護,並且必須啟動從Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI解析的 Intent 的 Activity。
- [
查看修訂版
如果具有 VP9 硬件解碼器的電視設備實現支持 VP9 解碼和 UHD 解碼配置文件,則:
- [ 5.3.7 /T-
2-1SR1 ] 強烈建議支持每秒 60 幀的 UHD 解碼配置文件,配置文件 2(10 位色深)。
- [ 5.3.7 /T-
查看修訂版
汽車設備實現:
3、軟件
查看修訂版
開始新的要求
新聯繫人的默認帳戶:聯繫人提供程序提供 API 來管理創建新聯繫人時的默認帳戶設置。
如果設備實現預加載聯繫人應用程序,則預加載的聯繫人應用程序:
[C-2-1] 必須處理
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
意圖,以啟動用於帳戶選擇的 UI,並在選擇帳戶時將設置保存到聯繫人提供程序。[C-2-2] 在處理
ContactsContracts.Contacts.CONTENT_TYPE
和ContactsContract.RawContacts.CONTENT_TYPE
的Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
時,必須通過最初選擇帳戶來遵循默認帳戶設置。
查看修訂版
[移至2.2.3]
開始新的要求
如果設備實現的設置應用程序使用活動嵌入實現拆分功能,那麼它們:
- [C-17-1] 必須有一個 Activity 在啟用拆分功能時處理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY Intent。 Activity 必須受
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
保護,並且必須啟動從Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI解析的 Intent 的 Activity。
- [C-17-1] 必須有一個 Activity 在啟用拆分功能時處理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY Intent。 Activity 必須受
6. 開發者工具和選項兼容性
7. 硬件兼容性
查看修訂版
[移至7.4.9]
開始新的要求
如果設備實現包括對 802.1.15.4 的支持並向第三方應用程序公開該功能,則它們:
查看修訂版
如果設備實現
包括 GSM 或 CDMA 電話報告android.hardware.telephony
功能,然後:- [C-6-1]
SmsManager#sendTextMessage
和SmsManager#sendMultipartTextMessage
必須導致對CarrierMessagingService
的相應調用,以提供短信功能。SmsManager#sendMultimediaMessage
和SmsManager#downloadMultimediaMessage
必須導致對CarrierMessagingService
相應調用,以提供多媒體消息傳遞功能。 - [C-6-2]
android.provider.Telephony.Sms#getDefaultSmsPackage
指定的應用在發送和接收 SMS 和 MMS 消息時必須使用SmsManager API。 packages/apps/Messaging 中的 AOSP 參考實現滿足此要求。 - [C-6-3] 響應
Intent#ACTION_DIAL
的應用必須支持輸入*#*#CODE#*#*
格式的任意撥號代碼,並觸發相應的TelephonyManager#ACTION_SECRET_CODE
廣播。 - [C-6-4] 如果響應
Intent#ACTION_DIAL
的應用支持可視語音郵件轉錄,則該應用必須使用VoicemailContract.Voicemails#TRANSCRIPTION
向用戶顯示可視語音郵件轉錄。 - [C-6-5] 必須將具有等效組 UUID的所有SubscriptionInfo表示為顯示和控制 SIM 卡信息的所有用戶可見功能中的單個訂閱。此類功能的示例包括與
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
或EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
匹配的設置界面。 - [C-6-6] 不得在任何允許配置或控制 SIM 卡設置的用戶可見功能中顯示或允許控制具有非空組 UUID和機會位的任何 SubscriptionInfo。
如果設備實現
包括 GSM 或 CDMA 電話報告android.hardware.telephony
功能並提供系統狀態欄,然後:- [C-
6-7 -1 ] 必須為給定組 UUID選擇一個代表性的活動訂閱,以在提供 SIM 狀態信息的任何功能中向用戶顯示。此類可供性的示例包括狀態欄蜂窩信號圖標或快速設置圖塊。 - [C-SR-1] 強烈建議將代表性訂閱選擇為活動數據訂閱,除非設備處於語音呼叫中,在此期間強烈建議將代表性訂閱選擇為活動語音訂閱。
如果設備實現
包括 GSM 或 CDMA 電話報告android.hardware.telephony
功能,然後:- [C-6-
8[7 ] 必須能夠根據 ETSI TS 102 221 為每個 UICC 打開並同時使用最大數量的邏輯通道(總共 20 個)。 - [C-6-
108 ] 不得自動或未經用戶明確確認,將以下任何行為應用於活動運營商應用程序(由TelephonyManager#getCarrierServicePackageName
指定):- 撤銷或限製網絡訪問
- 撤銷權限
- 限制後台或前台應用程序執行超出 AOSP 中包含的現有電源管理功能
- 禁用或卸載該應用程序
如果設備實現
包括 GSM 或 CDMA 電話報告android.hardware.telephony
功能,並且所有共享組 UUID 的活動、非機會性訂閱均被禁用、從設備中物理刪除或標記為機會性訂閱,然後設備:- [C-
78 -1] 必須自動禁用同一組中所有剩餘的活動機會訂閱。
如果設備實現包括 GSM 電話但不包括 CDMA 電話,則:
- [C-
89 -1] 不得聲明PackageManager#FEATURE_TELEPHONY_CDMA
。 - [C-
89 -2] 嘗試在首選或允許的網絡類型位掩碼中設置任何 3GPP2 網絡類型時必須拋出IllegalArgumentException
。 - [C-
89 -3] 必須從TelephonyManager#getMeid
返回空字符串。
如果設備實現支持具有多個端口和配置文件的 eUICC,則它們:
- [C-
1110 -1] 必須聲明android.hardware.telephony.euicc.mep
功能標誌。
- [C-6-1]
查看修訂版
如果設備實現通過如果設備實現包括對 802.1.15.4 的支持並向第三方應用程序公開該功能,那麼它們:android.content.pm.PackageManager
類報告對android.hardware.uwb
功能的支持,開始新的要求
- [C-1-1] 必須在 android.uwb 中實現相應的 Android API。
- [C-1-2] 必須報告硬件功能標誌 android.hardware.uwb。
- [C-1-3] 必須支持 Android 實現中定義的所有相關 UWB 配置文件。
- [C-1-4] 必須向用戶提供可供性,以允許用戶切換 UWB 無線電的開/關狀態。
- [C-1-5] 必須強制要求使用 UWB 無線電的應用持有 UWB_RANGING 權限(在 NEARBY_DEVICES 權限組下)。
- [C-SR-1] 強烈建議通過標準組織(包括FIRA 、 CCC和CSA)定義的相關一致性和認證測試。
- [C-1-
16 ] 必須確保在非反射室中 1m 距離的視線環境中 95% 的測量結果在 +/-15 cm 之內。 - [C-1-
27 ] 必須確保距參考設備 1m 處的距離測量值的中值在 [0.75m, 1.25m] 範圍內,其中地面真實距離是從面朝上並傾斜 45 度的 DUT 頂部邊緣測量的。 - [C-SR-2] 強烈建議遵循存在校準要求中指定的測量設置步驟。
強烈建議遵循存在校準要求中指定的測量設置步驟。查看修訂版
為了與使用 USB-C 連接器的耳機和其他音頻配件兼容,並按照Android USB 耳機規範中的定義在整個 Android 生態系統中實現(USB 音頻類)。
2022 年 10 月 19 日
2. 設備類型
查看修訂版
如果手持設備實現未在鎖定任務模式下運行,則當內容複製到剪貼板時,它們:
- [3.8.17/H-1-1] 必須向用戶提供數據已復製到剪貼板的確認信息(例如“內容已復制”的縮略圖或警報)。此外,請在此處添加指示是否將跨設備同步剪貼板數據。
3、軟件
查看修訂版
如果設備實現的設置應用程序使用活動嵌入實現拆分功能,那麼它們:
- [C-17-1] 必須有一個 Activity 在啟用拆分功能時處理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY Intent。 Activity 必須受
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
保護,並且必須啟動從Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI解析的 Intent 的 Activity。
如果設備實現支持
VoiceInteractionService
並且同時安裝了多個使用此 API 的應用程序,則它們:- [C-18-1]必須遵循
android.settings.ACTION_VOICE_INPUT_SETTINGS
Intent,以顯示用於語音輸入和協助的默認應用設置菜單。
- [C-17-1] 必須有一個 Activity 在啟用拆分功能時處理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY Intent。 Activity 必須受
查看修訂版
- [C-1-4]必須在與實例化 WebView 的應用不同的進程中呈現所提供的內容或遠程 URL 內容。具體來說,單獨的渲染器進程必須擁有較低的權限,作為單獨的用戶 ID 運行,無權訪問應用程序的數據目錄,沒有直接的網絡訪問權限,並且只能通過 Binder 訪問最低要求的系統服務。 WebView的AOSP實現滿足了這個要求。
7. 硬件兼容性
查看修訂版
如果設備實現支持 IEEE 802.11 標準中定義的 Wi-Fi 省電模式,則:
[C-3-1] 必須每當應用程序通過WifiManager.createWifiLock()
和WifiManager.WifiLock.acquire()
獲取WIFI_MODE_FULL_HIGH_PERF
鎖定或WIFI_MODE_FULL_LOW_LATENCY
鎖定時,應關閉 Wi-Fi 省電模式
查看修訂版
如果設備實現包括對藍牙低功耗 (BLE) 的支持,則它們:
- [C-3-5] 必須實現不超過 15 分鐘的可解析私有地址 (RPA) 超時,並在超時時輪換地址,以在設備主動使用 BLE 進行掃描或廣告時保護用戶隱私。為了防止定時攻擊,超時間隔也必須隨機設置在 5 到 15 分鐘之間。
7.5.5 相機方向
查看修訂版
如果設備實現具有前置或後置攝像頭,則此類攝像頭:
- [C-1-1] 方向必須使攝像頭的長邊尺寸與屏幕的長邊尺寸對齊。也就是說,當設備處於橫向方向時,相機必須以橫向方向捕獲圖像。無論設備的自然方向如何,這都適用;也就是說,它適用於橫向主設備以及縱向主設備。
滿足以下所有標準的設備可免除上述要求:- 該設備實現了可變幾何屏幕,例如可折疊或鉸接顯示器。
- 當設備的折疊或鉸鏈狀態發生變化時,設備會在縱向主方向和橫向主方向之間切換(反之亦然)。
9. 安全模型兼容性
查看修訂版
當設備實現支持安全鎖屏時,它:
- [C-1-6] 必須支持 IKeymasterDevice 4.0、 IKeymasterDevice 4.1、IKeyMintDevice 版本 1 或 IKeyMintDevice 版本 2。
查看修訂版
如果設備實現了對 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 硬件:硬件要求更改如下。
輸入設備:
查看修訂版
手持設備實現:
如果設備通過聲明
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 米之內距離為 10 cm、1 m、3 m 和 5 m 時,在第 68 個百分位處為 +/-4 米,在 40 MHz 帶寬處為第 68 個百分位處,在 20 MHz 帶寬處為第 68 個百分位處為 +/-8 米,如下所示通過WifiRttManager#startRanging Android API觀察。
[ 7.4 .2.5/H-SR] 強烈建議在 90% 的 160 MHz 帶寬下準確報告範圍在 +/-1 米之內(根據累積分佈函數計算),在 80 MHz 時報告範圍在 +/-2 米之內通過WifiRttManager#startRanging Android API觀察到,在 90% 的帶寬下,在 90% 的帶寬下,在 90% 的帶寬下,+/-4 米,在 90% 的帶寬下,在 90% 的帶寬下,+/-8 米,距離為 10 厘米。
強烈建議遵循存在校準要求中指定的測量設置步驟。
音頻延遲:
查看修訂版
如果手持設備實現聲明
android.hardware.audio.output
和android.hardware.microphone
,它們:- [ 5.6 /H-1-1] 平均連續往返延遲必須為500
8005 次測量的誤差小於或等於毫秒,平均絕對偏差小於50100ms,通過以下數據路徑:“揚聲器到麥克風”、3.5 毫米環回適配器(如果支持)、USB 環回(如果支持)。至少一條受支持的路徑。
- [ 5.6 /H-1-1] 在揚聲器到麥克風數據路徑上的至少 5 次測量中,平均點擊音延遲必須為 500 毫秒或更短。
- [ 5.6 /H-1-1] 平均連續往返延遲必須為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、GEST URE_START和GESTURE_END)。
- [ 7.10 /H]* 應實現android.os.VibrationEffect中清晰觸覺的所有公共常量,即(EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK 和 EFFECT_DOUBLE_CLICK)以及android.os.VibrationEffect.Composition中豐富觸覺的所有可行公共
PRIMITIVE_*
常量(PRIMITIVE_CLICK 和 PRIMITIVE_TICK)(點擊、滴答聲、低滴答聲、快速下降、快速上升、慢速上升、旋轉、轟鳴)。其中一些原語(例如 LOW_TICK 和 SPIN)可能僅在振動器可以支持相對較低的頻率時才可行。
- [7.10/H]* 應遵循將android.view.HapticFeedbackConstants中的公共常量映射到推薦的android.os.VibrationEffect常量的指南,並具有相應的幅度關係。
- [ 7.10 /H]* 應驗證公共android.os.Vibrator.hasAmplitudeControl() API 的結果是否正確反映了其振動器的功能。
- [ 7.10 /H]* 應通過運行android.os.Vibrator.hasAmplitudeControl()來驗證幅度可擴展性的功能。
如果手持設備實施包括至少一個線性諧振執行器,則它們:
驗證簡單的設備控制:
查看修訂版
- [ 3.8 .16/H-1-5] 必須讓用戶能夠從第三方應用程序通過
ControlsProviderService
和Control
Control.isAuthRequired
API 註冊的控件中選擇退出應用程序指定的 auth-trivial 設備控件。
- [ 3.8 .16/H-1-5] 必須讓用戶能夠從第三方應用程序通過
媒體樣式通知:
查看修訂版
如果手持設備實現支持MediaStyle 通知,則它們:
- [3.8.3.1/H-1-SR] 強烈建議提供從系統 UI 訪問的用戶功能(例如“輸出切換器”),允許用戶在適當的可用媒體路由之間切換(例如藍牙設備和提供給MediaRouter2Manager的路由)當應用程序發布帶有MediaSession token 的MediaStyle 通知時。
2.2.4 性能和功耗:對運行前台服務的應用程序的新要求。
查看修訂版
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 音頻視頻錄製初始化的並發 1080p 到 720p 僅視頻轉碼會話。
- [5.1/H-1-8] 在負載下,所有音頻編碼器的 128 kbps 或更低比特率音頻編碼會話的編解碼器初始化延遲必須為 30 ms 或更短。此處的加載被定義為使用硬件視頻編解碼器以及 1080p 音頻視頻錄製初始化的並發 1080p 到 720p 僅視頻轉碼會話。
- [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,級別 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
。
最小樣本量 4MB 最小子樣本數 - H264 或 HEVC 32 最小子樣本數 - VP9 9 最小子樣本數 - AV1 288 最小子樣本緩衝區大小 1 MiB 最小通用加密緩衝區大小 500 KB 最小並發會話數 30 每個會話的最小密鑰數量 20 最小密鑰總數(所有會話) 80 DRM 密鑰的最小總數(所有會話) 6 消息大小 16 KB 每秒解密幀數 60 幀/秒 - [5.1/H-1-1] 必須通過
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 分辨率,camera2 JPEG 捕獲延遲必須小於 1000 毫秒(根據 CTS 相機性能測試在 ITS 照明條件 (3000K) 下對兩個主相機進行測量)。
- [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
功能。
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 硬件:更新了 3 軸加速度計和 3 軸陀螺儀要求,以及外視攝像頭要求。
查看修訂版
汽車設備實現:
- [ 7.3 .1/A-0-4] 必須符合 Android汽車傳感器坐標系。
- [ 7.3 /A-SR] 強烈建議包含 3 軸加速計和 3 軸陀螺儀。
- [ 7.3 /A-SR] 強烈建議實施並報告
TYPE_HEADING
傳感器。
如果汽車設備實現包括加速度計,則它們:
- [ 7.3 .1/A-1-1] 必須能夠以至少 100 Hz 的頻率報告事件。
如果設備實現包括 3 軸加速計,則:
- [ 7.3 .1/A-SR] 強烈建議為有限軸加速度計實施複合傳感器。
如果汽車設備實現包括少於 3 個軸的加速度計,則:
- [ 7.3 .1/A-1-3] 必須實現並報告
TYPE_ACCELEROMETER_LIMITED_AXES
傳感器。 - [ 7.3 .1/A-1-4] 必須實現並報告
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
傳感器。
如果汽車設備實現包括陀螺儀,則它們:
如果汽車設備實現包括 3 軸陀螺儀,則:
- [ 7.3 .4/A-SR] 強烈建議實施限軸陀螺儀複合傳感器。
如果汽車設備實現包括少於 3 軸的陀螺儀,則:
- [ 7.3 .4/A-4-1] 必須實現並報告
TYPE_GYROSCOPE_LIMITED_AXES
傳感器。 - [ 7.3 .4/A-4-2] 必須實現並報告
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
傳感器。
如果汽車設備實現包括
TYPE_HEADING
傳感器,則:外視攝像頭是對設備實現之外的場景進行成像的攝像頭,例如後視攝像頭
行車記錄儀。如果汽車設備實現包括外視攝像頭,對於此類攝像頭,它們:
[ 7.5 .5/A-SR] 強烈建議調整方向,使攝像機的長邊與地平線對齊。應支持Android同步框架。MAY have either hardware auto-focus or software auto-focus implemented in the camera driver.
If automotive device implementations include one or more exterior view cameras, and load Exterior View System (EVS) service, then for such a camera, they:
- [ 7.5 /A-2-1] MUST NOT rotate or horizontally mirror the camera preview.
Automotive device implementations:
- MAY include one or more cameras that are available to third party applications.
If automotive device implementations include at least one camera and make it available to third party applications then, they:
- [ 7.5 /A-3-1] MUST report the feature flag
android.hardware.camera.any
. - [ 7.5 /A-3-2] MUST not declare the camera as a system camera .
- MAY support external cameras described in section 7.5.3 .
- MAY include features (such as auto-focus, etc.) available to rear-facing cameras as described in section 7.5.1 .
2.5.5 Security Model : New requirements for camera permissions for automotive devices.
See revision
If Automotive device implementations declare
android.hardware.camera.any
, then they:[ 9.8.2 /A-2-1] MUST display the camera indicator when an app is accessing live camera data, but not when the camera is only being accessed by app(s) holding the roles called out in Section 9.1 Permissions with CDD identifier [C-3-X].
[ 9.8.2 /A-2-2] MUST not hide the camera indicator for system apps that have visible user interfaces or direct user interaction.
2.6.1 Tablet Requirements — Hardware : Update to tablet screen size requirements.
See revision
An Android Tablet device refers to an Android device implementation that typically meets all the following criteria:
- Has a screen display size greater than 7” and less than 18", measured diagonally.
Screen Size
- [ 7.1 .1.1/Tab-0-1] MUST have a screen in the range of 7 to 18 inches.
3. Software
3.2.2 Build Parameters : Updated ASCII characters in
getSerial()
.See revision
- [C-0-1] To provide consistent, meaningful values across device implementations, the table below includes additional restrictions on the formats of these values to which device implementations MUST conform.
Parameter Details getSerial() MUST (be or return) a hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9]+$” . 3.2.3.5 Conditional Application Intents : Update to requirements for conditional application intents.
See revision
If device implementations include a large display (generally having display width and height of 600dp+) and supports split functionality , then they:
- [C-17-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
and it MUST start the activity of the Intent parsed from Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI .
- [C-17-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by
3.5.1 Application Restriction : Updates to application restrictions.
See revision
If device implementations implement a proprietary mechanism to restrict apps (eg changing or restricting API behaviors that are described in the SDK) and that mechanism is more restrictive than the Restricted App Standby Bucket , they:
- [C-1-1] MUST allow the user to see the list of restricted apps.
- [C-1-2] MUST provide user affordance to turn on / off all of these proprietary restrictions on each app.
- [C-1-3] MUST not automatically apply these proprietary restrictions without evidence of poor system health behavior, but MAY apply the restrictions on apps upon detection of poor system health behavior like stuck wakelocks, long running services, and other criteria. The criteria MAY be determined by device implementers but MUST be related to the app's impact on the system health. Other criteria that are not purely related to the system health, such as the app's lack of popularity in the market, MUST NOT be used as criteria.
- [C-1-4] MUST not automatically apply these proprietary restrictions for apps when a user has turned off app restrictions manually, and MAY suggest the user to apply these proprietary restrictions.
[C-1-5] MUST inform users if these proprietary restrictions are applied to an app automatically. Such information MUST be provided in the 24-hour period preceding the application of these proprietary restrictions.
[C-1-6] MUST return true for the ActivityManager.isBackgroundRestricted() method for any API calls from an app.
[C-1-7] MUST NOT restrict the top foreground app that is explicitly used by the user.
[C-1-8] MUST suspend these proprietary restrictions on an app whenever a user starts to explicitly use the app, making it the top foreground application.
[C-1-9] MUST report all these proprietary restrictions events via UsageStats.
[C-1-10] MUST provide a public and clear document or website that describes how proprietary restrictions are applied. This document or website MUST be linkable from the Android SDK documents and MUST include:
- Triggering conditions for proprietary restrictions.
- What and how an app can be restricted.
- How an app can be exempted from such restrictions.
- How an app can request an exemption from proprietary restrictions, if they support such an exemption for apps the user can install.
If an app is pre-installed on the device and has never been explicitly used by a user for more than 30 days, [C-1-3] [C-1-5] are exempted.
3.8.1 Launcher (Home Screen) : Updates to support for
monochrome/adaptive-icon
.See revision
If device implementations support monochrome icons, these icons:
- [C-6-1] MUST be used only when a user explicitly enables them (eg via Settings or wallpaper picker menu).
3.8.2 Widgets : Update to third-party app widget presence in the Launcher.
See revision
If device implementations support third-party app widgets, they:
- [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets
directly within the Launcher.
- [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets
3.8.3.1 Presentation of Notifications : Clarifying the definition of heads-up notifications.
See revision
Heads up notifications are notifications that are presented to the user as they come in independently of the surface the user is on.
3.8.3.3 DND (Do not Disturb) / Priority Mode : Update to include Priority Mode in DND (Do Not Disturb) requirements.
See revision
3.8.3.3. DND (Do not Disturb) / Priority Mode
If device implementations support the DND feature (also called Priority Mode), they:
3.8.6 Themes : New requirements for dynamic color tonal palettes.
See revision
If device implementations include a screen or video output, they:
[C-1-4] MUST generate dynamic color tonal palettes as specified in the AOSP documentation of
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
(seeandroid.theme.customization.system_palette
andandroid.theme.customization.theme_style
).[C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
documentation (seeandroid.theme.customization.theme_styles
), namelyTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
."Source color" used to generate dynamic color tonal palettes when sent with
android.theme.customization.system_palette
(as documented inSettings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
).[C-1-6] MUST have a
CAM16
chroma value of 5 or larger.SHOULD be derived from the wallpaper via
com.android.systemui.monet.ColorScheme#getSeedColors
, which provides multiple valid source colors to pick one from.SHOULD use the value
0xFF1B6EF3
, if none of the provided colors meet the above source color requirement.
3.8.17 Clipboard : Added new requirements section for content on the clipboard.
See revision
3.8.17. Clipboard
Device implementations:
- [C-0-1] MUST NOT send clipboard data to any component, activity, service, or across any network connection, without explicit user action (eg, pressing a button on the overlay), except for services mentioned in 9.8.6 Content Capture and App Search .
If device implementations generate a user-visible preview when content is copied to the clipboard for any
ClipData
item whereClipData.getDescription().getExtras()
containsandroid.content.extra.IS_SENSITIVE
, they:- [C-1-1] MUST redact the user visible preview
The AOSP reference implementation satisfies these clipboard requirements.
3.9.1.1 Device Owner Provisioning : Updates to device owner provisioning requirements.
See revision
If device implementations declare
android.software.device_admin
, they:- [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:
- When the device implementation has neither users nor user data configured, it:
- [C-1-5] MUST enroll the DPC application as the Device Owner app or enable the DPC app to choose whether to become a Device Owner or a Profile Owner, if the device declares Near-Field Communications (NFC) support via the feature flag
android.hardware.nfc
and receives an NFC message containing a record with MIME typeMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] MUST send the ACTION_GET_PROVISIONING_MODE intent after device owner provisioning is triggered so that the DPC app can choose whether to become a Device Owner or a Profile Owner, depending on the values of
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, unless it can be determined from context that there is only one valid option.(such as for NFC based provisioning where Profile Owner provisioning is not supported). - [C-1-9] MUST send the ACTION_ADMIN_POLICY_COMPLIANCE intent to the Device Owner app if a Device Owner is established during provisioning regardless of the provisioning method used. The user must not be able to proceed in the Setup Wizard until the Device Owner app finishes.
- [C-1-5] MUST enroll the DPC application as the Device Owner app or enable the DPC app to choose whether to become a Device Owner or a Profile Owner, if the device declares Near-Field Communications (NFC) support via the feature flag
- When the device implementation has users or user data, it:
- [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.
- When the device implementation has neither users nor user data configured, it:
- [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP ) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for retail demo mode prior to on-screen, end-user interaction.
require some affirmative action before or during the provisioning process to consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use. [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
If device implementations declare
android.software.device_admin
, but also include a proprietaryDevice Ownerdevice management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:- [C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and has been configured in the proprietary solution to have the rights equivalent as a "Device Owner".
- [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by
android.app.action.PROVISION_MANAGED_DEVICE
prior to enrolling the DPC application as "Device Owner". - [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
MAY have user data on the device prior to enrolling the DPC application as "Device Owner".
- [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below:
3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.
See revision
3.9.4 Device Policy Management Role Requirements
If device implementations report
android.software.device_admin
orandroid.software.managed_users
, then they:- [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting
config_devicePolicyManagement
to the package name. The package name MUST be followed by:
and the signing certificate unless the application is preloaded.
If a package name is not defined for
config_devicePolicyManagement
as described above:- [C-2-1] Device implementations MUST support provisioning without a device policy management role holder application ( AOSP provides a reference implementation ).
If a package name is defined for
config_devicePolicyManagement
as described above:- [C-3-1] The application MUST be installed on all profiles for a user .
- [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting
config_devicePolicyManagementUpdater
.
If a package name is defined for
config_devicePolicyManagementUpdater
as described above:- [C-4-1] The application MUST be preinstalled on the device.
- [C-4-2] The application MUST implement an intent filter which resolves
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
.
- [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting
3.18 Contacts : Adding information for new contacts.
See revision
Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.
If device implementations preload a contacts app, then the pre-loaded contacts app:
[C-2-1] MUST handle the intent
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.[C-2-2] MUST honor the default account setting when handling
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
for theContactsContracts.Contacts.CONTENT_TYPE
andContactsContract.RawContacts.CONTENT_TYPE
by initially selecting the account.
4. Application Packaging Compatibility
4. Application Packaging Compatibility : Updates to APK Signature Scheme version.
See revision
Device implementations:
[C-0-2] MUST support verifying “.apk” files using the APK Signature Scheme v3.1 , APK Signature Scheme v3 , APK Signature Scheme v2 and JAR signing .
[C-0-9] MUST support verifying .apk files using the APK Signature Scheme v4 and APK Signature Scheme v4.1 .
5. Multimedia Compatibility
5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.
See revision
If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the
android.media.MediaCodec
API, then the following MUST be supported:- [C-7-1] MUST be able to be configured by the application using the decoding with the key
KEY_MAX_OUTPUT_CHANNEL_COUNT
to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content. - [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the
KEY_CHANNEL_MASK
key, using theandroid.media.AudioFormat
constants (example:CHANNEL_OUT_5POINT1
).
If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:
- [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key
KEY_MAX_OUTPUT_CHANNEL_COUNT
to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content. - [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the
KEY_CHANNEL_MASK
key, using the android.media.AudioFormat constants (example:CHANNEL_OUT_5POINT1
).
- [C-7-1] MUST be able to be configured by the application using the decoding with the key
5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.
See revision
If device implementations declare
android.hardware.microphone
, they:[C-1-1] MUST allow capture of raw audio content with the following characteristics for any
AudioRecord
orAAudio
INPUT stream that is opened successfully. At a minimum, the following characteristics MUST be supported :- Format: Linear PCM, 16-bit
- Sampling rates: 8000, 11025, 16000, 44100, 48000 Hz
- Channels: Mono
- Audio Sources:
DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, orVOICE_PERFORMANCE
. This also applies to the equivalent Input Presets inAAudio
, for example,AAUDIO_INPUT_PRESET_CAMCORDER
. - [C-1-4] MUST honor the
MicrophoneInfo
API and properly fill in information for the available microphones on device accessible to the third-party applications via theAudioManager.getMicrophones()
API, for active AudioRecord usingMediaRecorder.AudioSources DEFAULT
,MIC
,CAMCORDER
,VOICE_RECOGNITION
,VOICE_COMMUNICATION
,UNPROCESSED
, orVOICE_PERFORMANCE
.and the currently active microphones which are accessible to the third party applications via theAudioRecord.getActiveMicrophones()
andMediaRecorder.getActiveMicrophones()
APIs.
5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.
See revision
If device implementations declare
android.hardware.microphone
, they:- SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
- SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.
- SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.
See revision
5.4.6. Microphone Gain Levels [Moved to 5.4.2]
If device implementations declare
android.hardware.microphone
, they:- SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.
5.5.4 Audio Offload : Updates to the audio offload playback requirements.
See revision
If device implementations support audio offload playback , they:
- [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.
5.6 Audio Latency : Updates to the audio latency requirements.
See revision
For the purposes of this section, use the following definitions:
- cold output jitter . The variability among separate measurements of cold output latency values.
- cold input jitter . The variability among separate measurements of cold input latency values.
If device implementations declare
android.hardware.audio.output
, they MUST meet or exceed the following requirements:- [C-1-2] Cold output latency of 500 milliseconds or less.
- [C-1-3] Opening an output stream using
AAudioStreamBuilder_openStream()
MUST take less than 1000 milliseconds.
If device implementations declare
android.hardware.audio.output
they are STRONGLY RECOMMENDED to meet or exceed the following requirements:- [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path.
Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST. [C-SR] Minimize the cold output jitter.
If device implementations include
android.hardware.microphone
, they MUST meet these input audio requirements:- [C-3-2] Cold input latency of 500 milliseconds or less.
- [C-3-3] Opening an input stream using
AAudioStreamBuilder_openStream()
MUST take less than 1000 milliseconds.
If device implementations include
android.hardware.microphone
, they are STRONGLY RECOMMENDED to meet these input audio requirements:- [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path.
Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.
- [C-SR] Continuous input latency of 30 milliseconds or less.
- [C-SR] Minimize the cold input jitter.
5.10 Professional Audio : Updates to audio latency requirements for professional audio support.
See revision
If device implementations report support for feature
android.hardware.audio.pro
via the android.content.pm.PackageManager class, they:- [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less
and SHOULD be 10 milliseconds or lessover at least one supported path. - [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
. - [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
- [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.
If device implementations include a 4 conductor 3.5mm audio jack, they:
- [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .
- [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less
5.12 HDR Video : Added a new section for HDR Video requirements.
6. Developer Tools and Options Compatibility
6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.
See revision
If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:
- [C-4-1] MUST have the
AdbManager#isAdbWifiSupported()
method returntrue
.
If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:
- [C-5-1] MUST have the
AdbManager#isAdbWifiQrSupported()
method returntrue
.
GPU work information
Device implementations:
- [C-6-1] MUST implement the shell command
dumpsys gpu --gpuwork
to display the aggregated GPU work data returned by thepower/gpu_work_period
kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation isframeworks/native/services/gpuservice/gpuwork/
.
- [C-6-1] MUST implement the shell command
- [C-4-1] MUST have the
7. Hardware Compatibility
7.1.4.1 OpenGL ES : Update to recommended extensions.
See revision
If device implementations support any of the OpenGL ES versions, they:
- SHOULD support the
EGL_IMG_context_priority
andEGL_EXT_protected_content
extensions.
- SHOULD support the
7.1.4.2 Vulkan : Updates to version supported for Vulkan.
See revision
If device implementations support OpenGL ES 3.1, they:
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
Vulkan 1.1 - MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).
If device implementations include a screen or video output, they:
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
Vulkan 1.1
If device implementations include support for Vulkan 1.0 or higher, they:
- SHOULD support
VkPhysicalDeviceProtectedMemoryFeatures
andVK_EXT_global_priority
. - [C-1-12] MUST NOT enumerate support for the
VK_KHR_performance_query
extension. - [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.
- [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 .
7.2.3 Navigation Keys :
See revision
Device implementations:
- [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.
If the back navigation function is provided and the user cancels the Back gesture, then:
- [C-8-1]
OnBackInvokedCallback.onBackCancelled()
MUST be called. - [C-8-2]
OnBackInvokedCallback.onBackInvoked()
MUST NOT be called. - [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.
If the back navigation function is provided but the foreground application does NOT have an
OnBackInvokedCallback
registered, then:- The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.
If device implementations provide support for the system API
setNavBarMode
to allow any system app withandroid.permission.STATUS_BAR
permission to set the navigation bar mode, then they:- [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.
7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.
See revision
If device implementations include an accelerometer,
a 3-axis accelerometer,they:[C-1-2] MUST implement and reportTYPE_ACCELEROMETER
sensor.[SR] are STRONGLY RECOMMENDED to implement theTYPE_SIGNIFICANT_MOTION
composite sensor.[SR] are STRONGLY RECOMMENDED to implement and reportTYPE_ACCELEROMETER_UNCALIBRATED
sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.SHOULD implement theTYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors as described in the Android SDK document.
If device implementations include a 3-axis accelerometer, they:
- [C-2-1] MUST implement and report
TYPE_ACCELEROMETER
sensor. - [C-SR] Are STRONGLY RECOMMENDED to implement the
TYPE_SIGNIFICANT_MOTION
composite sensor. - [C-SR] Are STRONGLY RECOMMENDED to implement and report
TYPE_ACCELEROMETER_UNCALIBRATED
sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED. - SHOULD implement the
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors as described in the Android SDK document.
If device implementations include an accelerometer with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_ACCELEROMETER_LIMITED_AXES
sensor. - [C-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
sensor.
If device implementations include a 3-axis accelerometer and any of the
TYPE_SIGNIFICANT_MOTION
,TYPE_TILT_DETECTOR
,TYPE_STEP_DETECTOR
,TYPE_STEP_COUNTER
composite sensors are implemented:- [C-4-1] The sum of their power consumption MUST always be less than 4 mW.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors.
If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:
- [C-6-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.
See revision
If device implementations include a gyroscope, they:
- [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
- [C-1-4] MUST have a resolution of 12-bits or more.
- [C-1-5] MUST be temperature compensated.
- [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
- [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
- [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
- [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
- SHOULD report events up to at least 200 Hz.
If device implementations include a 3-axis gyroscope, they:
- [C-2-1] MUST implement the
TYPE_GYROSCOPE
sensor.
If device implementations include a gyroscope with less than 3 axes, they:
- [C-3-1] MUST implement and report
TYPE_GYROSCOPE_LIMITED_AXES
sensor. - [C-SR] Are STRONGLY_RECOMMENDED to implement and report
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
sensor.
If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:
- [C-4-1] MUST implement a
TYPE_ROTATION_VECTOR
composite sensor.
If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:
- [C-5-1] MUST implement the
TYPE_GRAVITY
andTYPE_LINEAR_ACCELERATION
composite sensors.
7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.
See revision
Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 .
Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:
- [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.
If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:
- [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .
If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:
- [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .
7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.
See revision
7.3.13. IEEE 802.1.15.4 (UWB)
If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:
- [C-1-1] MUST implement the corresponding Android API in android.uwb.
- [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
- [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
- [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
- [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
- [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .
7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.
See revision
If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:
- [C-3-1] MUST declare the
android.hardware.telephony.euicc
feature flag.provide a complete implementation of theEuiccManager API
.
If device implementations include GSM or CDMA telephony, then:
- [C-6-1] The
SmsManager#sendTextMessage
andSmsManager#sendMultipartTextMessage
MUST result in corresponding calls toCarrierMessagingService
for providing text messaging functionality.SmsManager#sendMultimediaMessage
andSmsManager#downloadMultimediaMessage
MUST result in corresponding calls toCarrierMessagingService
for providing multimedia messaging functionality. - [C-6-2] The application designated by
android.provider.Telephony.Sms#getDefaultSmsPackage
MUST use SmsManager APIs when sending and receiving SMS and MMS messages. The AOSP reference implementation in packages/apps/Messaging meets this requirement. - [C-6-3] The application which responds to
Intent#ACTION_DIAL
MUST support entry of arbitrary dialer codes formatted as*#*#CODE#*#*
and trigger a correspondingTelephonyManager#ACTION_SECRET_CODE
broadcast. - [C-6-4] The application which responds to
Intent#ACTION_DIAL
MUST useVoicemailContract.Voicemails#TRANSCRIPTION
to display visual voicemail transcription to users if it supports visual voicemail transcriptions. - [C-6-5] MUST represent all SubscriptionInfo with equivalent group UUIDs as a single subscription in all user-visible affordances that display and control SIM card information. Examples of such affordances include settings interfaces that match
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
orEuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
. - [C-6-6] MUST NOT display or allow control of any SubscriptionInfo with a non-null group UUID and opportunistic bit in any user-visible affordances that allow configuration or control of SIM card settings.
If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:
- [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
- [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.
If device implementations include GSM or CDMA telephony, then:
- [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
- [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by
TelephonyManager#getCarrierServicePackageName
) automatically or without explicit user confirmation:- Revoke or limit network access
- Revoke permissions
- Restrict background or foreground app execution beyond the existing power management features included in AOSP
- Disable or uninstall the app
If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:
- [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.
If device implementations include GSM telephony but not CDMA telephony, they:
- [C-8-1] MUST NOT declare
PackageManager#FEATURE_TELEPHONY_CDMA
. - [C-8-2] MUST throw an
IllegalArgumentException
upon attempts to set any 3GPP2 network types in preferred or allowed network type bitmasks. - [C-8-3] MUST return an empty string from
TelephonyManager#getMeid
.
If the device implementations support eUICCs with multiple ports and profiles, they:
- [C-11-1] MUST declare the
android.hardware.telephony.euicc.mep
feature flag.
- [C-3-1] MUST declare the
7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.
See revision
If device implementations report the
android.hardware.telephony feature
, they:- [C-1-4] MUST NOT write to the platform call log provider for a blocked call.
- [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with
BLOCKED_TYPE
out of the default call log view in the pre-installed dialer app. - SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.
7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.
See revision
7.4.1.3. Cellular NAT-T Keepalive Offload
Device implementations:
- SHOULD include support for Cellular keepalive offload.
If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:
- [C-1-1] MUST support the SocketKeepAlive API.
- [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
- [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
- [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.
If device implementations do not include support for cellular keepalive offload, they:
- [C-2-1] MUST return ERROR_UNSUPPORTED.
7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.
See revision
If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:
- [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
- [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.
See revision
Device implementations:
- SHOULD include support for Wi-Fi keepalive offload.
If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:
- [C-1-1] MUST support the SocketKeepAlive API.
- [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
and at least one keepalive slot over cellular.If device implementations do not include support for Wi-Fi keepalive offload, they:
- [C-2-1] MUST return
ERROR_UNSUPPORTED
.
7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.
See revision
7.4.2.9 Trust On First Use (TOFU)
If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:
- [C-4-1] MUST provide the user an option to select to use TOFU.
7.4.3 Bluetooth : Update to Bluetooth requirements.
See revision
If device implementations support Bluetooth Audio profile, they:
- SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.
If device implementations return
true
for theBluetoothAdapter.isLeAudioSupported()
API, then they:- [C-7-1] MUST support unicast client.
- [C-7-2] MUST support 2M PHY.
- [C-7-3] MUST support LE Extended advertising.
- [C-7-4] MUST support at least 2 CIS connections in a CIG.
- [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
- [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.
If device implementations return
true
for theBluetoothAdapter.isLeAudioBroadcastSourceSupported()
API, then they:- [C-8-1] MUST support at least 2 BIS links in a BIG.
- [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
- [C-8-3] MUST support LE Periodic advertising.
If device implementations return
true
for theBluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API, then they:- [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
- [C-9-2] MUST support LE Periodic advertising.
If device implementations declare
FEATURE_BLUETOOTH_LE
, they:- [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
in line of sight environment. - [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
- [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction. - [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
It is STRONGLY RECOMMENDED to follow the measurement setup steps specified in Presence Calibration Requirements .
If device implementations support Bluetooth version 5.0, then they:
- [C-SR] Are STRONGLY RECOMMENDED to provide support for:
- LE 2M PHY
- LE Codec PHY
- LE Advertising Extension
- Periodic advertising
- At least 10 advertisement sets
- At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
- LE Link Layer Privacy
- A "resolving list" size of at least 8 entries
7.4.9 UWB : Added a requirements section for UWB hardware.
See revision
7.4.9. UWB
If device implementations report support for feature
android.hardware.uwb
via theandroid.content.pm.PackageManager
class, then they:- [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
- [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.
It is STRONGLY RECOMMENDED to follow the measurement setup steps specified in Presence Calibration Requirements .
7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.
See revision
If device implementations support HDR 10-bit output capability, then they:
- [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
- [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
- [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
- [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.
For Logical camera devices which support 10-bit HDR that implement the
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API, they:- [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the
CONTROL_ZOOM_RATIO
control on the logical camera.
7.7.2 USB Host Mode : Revisions for dual role ports.
See revision
If device implementations include a USB port supporting host mode and USB Type-C, they:
- [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.
7.11 Media Performance Class : Updated to include Android T.
See revision
If device implementations return non-zero value for
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, they:- [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .
In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.
See section 2.2.7 for device-specific requirements.
9. Security Model Compatibility
9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.
See revision
- [C-0-2] Permissions with a
protectionLevel
ofPROTECTION_FLAG_PRIVILEGED
MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in theetc/permissions/
path and using thesystem/priv-app
path as the privileged path.
- [C-0-2] Permissions with a
9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.
See revision
Kernel integrity and self-protection features are integral to Android security. Device implementations:
- [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
CONFIG_INIT_STACK_ALL
orCONFIG_INIT_STACK_ALL_ZERO
). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.
- [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.
See revision
Device implementations:
- [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the
ClipboardManager
API) unless the 3rd-party app is the default IME or is the app that currently has focus. - [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.
- [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the
9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.
See revision
When the device implementation supports a secure lock screen, it:
- [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Secure isolation MUST block all potential mechanisms by which kernel or userspace code might access the internal state of the isolated environment, including DMA. The upstream Android Open Source Project (AOSP) meets this requirement by using the Trusty implementation, but another ARM TrustZone-based solution or a third-party reviewed secure implementation of a proper hypervisor-based isolation are alternative options.
9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.
See revision
If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:
- [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.
If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via
VirtualDeviceManager
, they:- [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.
If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:
- [C-10-1] MUST support separate lock states per virtual device
- [C-10-2] MUST disconnect all virtual devices upon idle timeout
- [C-10-3] MUST have an idle timeout
- [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
- [C-10-5] MUST have separate virtual device instances per user
- [C-10-6] MUST disable the creation of associated input events via
VirtualDeviceManager
when indicated byDevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
- [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
- [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
- [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See
KeyGenParameterSpec.Builder.setUserAuthentication*
.
When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:
- [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
- [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
- [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.
If device implementations have a secure lock screen and include one or more trust agents, which call the
TrustAgentService.grantTrust()
System API with theFLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
flag they:- [C-12-1] MUST only call
grantTrust()
with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement. - [C-12-2] MUST put the device implementation into the
TrustState.TRUSTABLE
state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement. - [C-12-3] MUST only move the device from
TrustState.TRUSTABLE
to theTrustState.TRUSTED
state if the TrustAgent is still granting trust based on the requirements in C-12-1. - [C-12-4] MUST call
TrustManagerService.revokeTrust()
after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.
If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
- [C-13-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
- [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
- [C-13-10] MUST disable installation of apps initiated from virtual devices.
9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.
See revision
To validate compliance with [C-1-3] through [C-1-9], device implementations:
- [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).
9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.
See revision
The Identity Credential System is defined and achieved by implementing all APIs in the
android.security.identity.*
package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.
9.11.4 ID Attestation : Added a section for ID attestation requirement.
See revision
9.11.4. ID Attestation
Device implementations MUST support ID attestation .
9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.
See revision
9.17. Android Virtualization Framework
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine.*
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines.
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then any Protected Virtual Machine instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
- [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
- [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
- [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
- [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
- [C-3-2] MUST wipe a page after it is used by a VM and before it is returned to the host (eg the pVM is destroyed).
- [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
- [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST support Isolated Compilation of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.
- [C-1-1] MUST support all the APIs defined by the
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2023-08-14 (世界標準時間)。
[] [] - [C-2-1] MUST return