1. 簡介
本文件列舉出裝置需要符合哪些規範。 可與 Android 13 相容
使用「必須」、「不得」、「必要」、「應」、「不應」、「應該」、 「不應該」、「建議」、「可能」和「選用」符合 IETF 標準 RFC2119 中定義的標準。
本文件使用情境為「裝置實作器」或「實作器」是人物 或機構開發採用 Android 的 硬體/軟體解決方案 13.「裝置導入」或「實作」是 硬體/軟體解決方案
欲視為與 Android 13 相容裝置 導入方式「必須」符合本相容性說明 定義,包括透過參考資料彙整的所有文件。
這項定義或說明中描述的軟體測試 區段 10 表示靜音、不明確或 不完整,裝置實作人員需負責確保 與現行實作的相容性
因此,Android 開放原始碼計畫 是 Android 的參考與偏好實作。裝置 強烈建議實作者根據 在「上游」您可以透過 Android 開放原始碼計畫。雖然部分元件可以假設 替換成其他實作方式,我們強烈建議您不要 務必遵循這個做法,因為通過軟體測試 變得更困難實作人員有責任 與標準 Android 實作項目的行為相容性,包括 以及 Compatibility Test Suite 以外的資源最後請注意 本文件明確禁止替代和修改。
本文件所連結的許多資源 而且運作方式與 相關資訊適用情況 定義或 Compatibility Test Suite 不同意 SDK 說明文件,系統會將 SDK 說明文件視為具有公信力。任何技術性問題 請參閱這份文件所連結資源中提供的詳細資料 才會納入此相容性定義中。
1.1 文件結構
1.1.1.各裝置類型的規定
第 2 節包含所有適用於 指定任一種裝置類型。第 2 節的每個子節都是 是專門針對特定類型的裝置所設計的
所有其他規定適用於所有 Android 裝置 請參閱第 2 節後的區段。 這些需求稱為「核心需求」。
1.1.2.規定 ID
系統會針對「必須」的規定指派要求 ID。
- 一組 ID 僅用於「必須」的規定。
- 強烈建議的規定會標示為 [SR],但尚未指派 ID。
- ID 由以下元素組成:裝置類型 ID - 條件 ID - 規定 ID (例如 C-0-1)。
每個 ID 的定義如下:
- 裝置類型 ID (詳情請參閱2.裝置類型)
- C:核心 (適用於所有 Android 裝置的實作規範)
- H:Android 手持裝置
- T:Android 電視裝置
- A:Android Automotive 實作
- W:Android Watch 實作
- 分頁:Android 平板電腦實作
- 條件 ID
- 當條件為無條件時,這個 ID 會設為 0。
- 如果條件為條件式,系統會將 1 指派給第 1 次 相同區段內設有條件,且數字的遞增單位為 1, 相同的裝置類型。
- 規定 ID
- 這個 ID 從 1 開始,並在相同區段內以 1 遞增, 相同的條件
1.1.3.第 2 節的規定 ID
第 2 節的要求 ID 包含兩個部分。第一個 對應上述的區段 ID。第二個部分代表 板型規格和特定板型規格的專屬規定。
部分 ID,後面接著上述規定 ID。
- 第 2 部分的 ID 包含以下項目: 專區 ID / 裝置類型 ID - 條件 ID - 要求 ID (例如 7.4.3/A-0-1)。
2. 裝置類型
Android 開放原始碼計畫提供軟體堆疊, 用於各種裝置類型和板型規格為了支援裝置安全性 軟體堆疊,包括任何替代的 OS 或替代核心 應在安全環境中執行,才能如上所述 。目前有幾種裝置類型 一個擁有相對成熟的應用程式發布生態系統。
本節說明這些裝置類型,以及其他規定和 適用於各裝置類型的建議。
所有不符合上述任一項目的 Android 裝置實作 裝置類型仍必須符合本節其他章節的所有規定 相容性定義。
2.1 裝置設定
各裝置的硬體設定主要差異。 類型,請參閱本節所述的裝置專屬需求。
2.2. 手持裝置需求
Android 手持裝置是指 Android 裝置實作, 通常用來在手持方式使用,例如 mp3 播放器、手機 平板電腦。
如果 Android 裝置的實作方式符合所有 符合以下條件:
- 請備妥可提供行動用的電源 (例如電池)。
- 螢幕尺寸符合 3.3 吋 (或 對於搭載 API 級別 29 或 ) 到 8 吋。
本節其他規定僅適用於 Android 手持裝置實作。
2.2.1. 硬體
手持裝置實作方式:
- [7.1.1.1/H-0-1] 至少必須有一個 符合本文所述所有需求的 Android 相容螢幕 文件。
[7.1.1.3/H-SR-1] 強烈建議 為使用者提供預設變更顯示大小 (螢幕密度) 的選項。
[7.1.1.1/H-0-2] 必須支援 GPU 組合 圖像緩衝區至少與任何內建程式碼的最高解析度相同 螢幕。
如果手持裝置實作支援軟體螢幕旋轉功能,可以:
- [7.1.1.1/H-1-1]* 必須製作邏輯畫面 供第三方應用程式使用。 長邊短邊,長邊為 2.7 英吋 搭載 Android API 級別 29 以下版本的裝置: 不受這項規定約束。
如果手持裝置實作不支援軟體螢幕旋轉功能, 他們會:
- [7.1.1.1/H-2-1]* 必須製作邏輯畫面 第三方應用程式可用的網路頻寬至少須為 2.7 吋 短邊。 搭載 Android API 級別 29 以下版本的裝置: 不受這項規定約束。
如果手持裝置實作方式支援高動態範圍
透過 Configuration.isScreenHdr()
顯示
,他們:
- [7.1.4.5/H-1-1] 請務必
EGL_EXT_gl_colorspace_bt2020_pq
、EGL_EXT_surface_SMPTE2086_metadata
、EGL_EXT_surface_CTA861_3_metadata
、VK_EXT_swapchain_colorspace
和VK_EXT_hdr_metadata
擴充功能。
手持裝置實作方式:
- [7.1.4.6/H-0-1] 必須回報裝置是否
透過系統屬性支援 GPU 剖析功能
graphics.gpu.profiler.support
。
如果手持裝置實作方式透過系統屬性宣告支援
graphics.gpu.profiler.support
,他們:
- [7.1.4.6/H-1-1] 必須回報為 符合 GPU 計數器和 GPU 結構定義的 protobuf 追蹤記錄 Perfetto 說明文件中定義的轉譯階段。
- [7.1.4.6/H-1-2] 必須回報合規值 以取得裝置的 GPU 計數器 GPU 計數器追蹤封包 proto。
- [7.1.4.6/H-1-3] 必須回報合規值 取得特定分數值 轉譯階段追蹤封包 proto。
- [7.1.4.6/H-1-4] 必須回報 GPU 頻率 追蹤點,格式為:power/gpu_frequency。
手持裝置實作方式:
- [7.1.5/H-0-1] 必須支援舊版 應用程式相容模式 (如上游 Android 開放式應用程式所實作) Cloud Build 觸發條件 會在您變更原始碼時自動啟動建構作業也就是說,裝置導入方式「不得」變更觸發條件或 相容模式啟用的門檻,而且「不得」變更 相容性模式本身的行為
- [7.2.1/H-0-1] 必須提供第三方支援 輸入法編輯器 (IME) 應用程式。
- [7.2.3/H-0-2] 必須同時傳送一般和長按
返回函式的事件 (
KEYCODE_BACK
) 移到前景應用程式系統「不得」使用這些事件 且可能是由 Android 裝置以外的地方 (例如外部硬體) 觸發 鍵盤就會接到 Android 裝置上。 - [7.2.3/H-0-3] 必須提供開啟住家功能 所有提供主畫面的 Android 相容螢幕。
- [7.2.3/H-0-4] 一律必須提供返回函式 Android 相容螢幕和「最近」函式至少 查看與 Android 相容的螢幕
- [7.2.4/H-0-1] 必須支援觸控螢幕輸入。
- [7.2.4/H-SR-1] 強烈建議你推出
使用者選擇的輔助應用程式,也就是
VoiceInteractionService,或是處理
ACTION_ASSIST
的活動 按住KEYCODE_MEDIA_PLAY_PAUSE
或KEYCODE_HEADSETHOOK
前景活動無法處理這些長按事件。 - [7.3.1/H-SR-1] 強烈建議你加入 3 軸 加速計。
如果手持裝置實作項目包含 3 軸式加速度計,請按照下列步驟操作:
- [7.3.1/H-1-1] 必須能夠按頻率回報活動 至少 100 Hz。
如果手持裝置導入方式包含 GPS/GNSS 接收器,並回報
透過 android.hardware.location.gps
功能將功能套用至應用程式
旗幟,他們可以:
- [7.3.3/H-2-1] 務必立即回報 GNSS 測量結果 。
- [7.3.3/H-2-2] 必須回報 GNSS 虛擬範圍和虛擬範圍 費率,在判斷地點後,在開放天際的環境中顯示 靜息或移動,且每秒小於 0.2 公尺的平方 足以計算出 20 公尺以內且速度 0.2 公尺以內,至少 95% 的時間
如果手持裝置實作含有 3 軸式迴轉儀,請按照以下步驟操作:
可撥打語音通話並提供訊息的手持裝置實作方式
getPhoneType
中 PHONE_TYPE_NONE
以外的任何值:
- [7.3.8/H] 必須使用鄰近感應器。
手持裝置實作方式:
如果裝置支援 Wi-Fi 鄰近感知網路 (NAN) 通訊協定,
正在宣告 PackageManager.FEATURE_WIFI_AWARE
和 Wi-Fi 位置資訊 (Wi-Fi 回合)
行程時間 - RTT) 前,請先宣告 PackageManager.FEATURE_WIFI_RTT
,然後:
[7.4.2.5/H-1-1] 請務必正確回報此範圍, 介於 68 百分位數 +/-1 公尺 (160 MHz 頻寬) 內 (計算方式為 搭配累積分佈函式),+/-2 公尺 (80 MHz 頻寬) 第 68 個百分位數,40 MHz 頻寬為 +/-4 公尺,第 68 個百分位數 和 +/-8 公尺 (20 MHz 頻寬,第 68 個百分位數,距離 10) 公分、1 公尺、3 公尺和 5 公尺,透過 WifiRttManager#startRanging Android API。
[7.4.2.5/H-SR-1] 強烈建議你回報 範圍準確到 +/-1 公尺 (160 MHz) 頻寬 (90th) 內 百分位數 (根據累計分佈函式計算),+/-2 公尺 (80 MHz 頻寬,第 90 個百分位數),+/-4 公尺 (40 MHz) 和 20 MHz 頻寬的 +/-8 公尺頻寬 距離 10 公分的第 90 個百分位數,透過 WifiRttManager#startRanging Android API。
我們強烈建議您按照 所在地校正。
如果手持裝置實作項目包含列出清單的邏輯相機裝置
功能
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
、
他們會:
- [7.5.4/H-1-1] 預設必須符合一般視野 (FOV) 且必須介於 50 到 95 度之間
手持裝置實作方式:
- [7.6.1/H-0-1] 至少必須有 4 GB 適用於應用程式私人資料的非揮發性儲存空間 (又稱為「/data」分區)。
- [7.6.1/H-0-2] 必須針對以下值傳回「true」:
記憶體少於 1 GB 時
ActivityManager.isLowRamDevice()
提供給核心和使用者空間使用
如果手持裝置實作項目宣告僅支援 32 位元 ABI:
[7.6.1/H-1-1] 核心的可用記憶體 如果預設螢幕使用 framebuffer,則使用者空間不得小於 416 MB 最高可達 qHD (例如 FWVGA)。
[7.6.1/H-2-1] 核心的可用記憶體 如果預設螢幕使用 framebuffer,則使用者空間不得小於 592 MB 解析度最高為 HD+ (例如 HD、WSVGA)。
[7.6.1/H-3-1] 核心的可用記憶體 如果預設螢幕使用 framebuffer,則使用者空間不得小於 896 MB 最高解析度最高 FHD (例如 WSXGA+)。
[7.6.1/H-4-1] 核心的可用記憶體 假如預設顯示器會使用 1,344 MB,使用者空間 最高等級為 QHD (例如 QWXGA)。
如果手持裝置實作項目宣告支援任何 64 位元 ABI (無論是否為 32 位元 ABI):
[7.6.1/H-5-1] 核心的可用記憶體 以及使用者空間 如果預設顯示螢幕採用 framebuffer 解析度,解析度至少為 816 MB 至 qHD (例如 FWVGA)。
[7.6.1/H-6-1] 核心的可用記憶體 且使用者空間必須至少為 如果預設螢幕採用高達 HD+ 的影格緩衝區解析度,則為 944 MB 例如 HD、WSVGA。
[7.6.1/H-7-1] 核心的可用記憶體 且使用者空間必須至少為 如果預設螢幕採用最高 FHD 的 framebuffer 解析度,1280 MB (例如 WSXGA+)。
[7.6.1/H-8-1] 核心的可用記憶體 且使用者空間必須至少為 如果預設螢幕採用最高 QHD 的 framebuffer 解析度,1824 MB (例如 QWXGA)。
請注意,「核心和使用者空間可用的記憶體」以上是指 所提供的記憶體空間 無線電、影片等非核心的 控管裝置導入方式
如果手持裝置實作的記憶體小於或等於 1 GB 提供給核心和使用者空間使用,具有以下特性:
- [7.6.1/H-9-1] 必須聲明功能標記
android.hardware.ram.low
。 - [7.6.1/H-9-2] 至少需要 1.1 GB 適用於應用程式的非揮發性儲存空間 私人資料(又稱為「/data」分區)。
如果手持裝置實作包含超過 1 GB 的可用記憶體 加入核心和使用者空間後,就可以:
- [7.6.1/H-10-1] 至少必須有 4GB 可用的非揮發性儲存空間 應用程式私人資料 (又稱「/data」分區)。
- 應宣告功能旗標
android.hardware.ram.normal
。
如果手持裝置導入方式大於或等於 2 GB 以及核心和使用者空間可用的記憶體少於 4 GB,這兩者包括:
- [7.6.1/H-SR-1] 強烈建議你僅支援 32 位元使用者空間 (應用程式和系統程式碼)
如果手持裝置實作項目包含少於 2 GB 的可用記憶體 進行以下操作:
- [7.6.1/H-1-1] 只能支援單一 ABI (僅限 64 位元或 32 位元) )。
手持裝置實作方式:
如果手持裝置含有支援週邊裝置的 USB 連接埠 模式,就會:
- [7.7.1/H-1-1] 必須實作 Android Open Accessory (AOA) 也能使用 Google Cloud CLI 或 Compute Engine API
如果手持裝置實作包含支援主機模式的 USB 連接埠, 他們會:
手持裝置實作方式:
如果手持裝置實作能達到所有效能 需要支援 VR 模式並包含支援,才能滿足以下條件:
- [7.9.1/H-1-1] 必須宣告
android.hardware.vr.high_performance
功能旗標。 - [7.9.1/H-1-2] 必須加入申請書
實作可透過 VR 啟用的
android.service.vr.VrListenerService
透過android.app.Activity#setVrModeEnabled
部署應用程式。
如果手持裝置實作在主機中加入一或多個 USB-C 連接埠 模式和實作 (USB 音訊類別),再加上 第 7.7.2 節,藉此:
- [7.8.2.2/H-1-1] 「必須」提供下列軟體對應 的 HID 代碼:
函式 | 對應 | 背景資訊 | 行為 |
---|---|---|---|
A | HID 用量頁面:0x0C HID 用量:0x0CD 核心金鑰: KEY_PLAYPAUSE Android 金鑰: KEYCODE_MEDIA_PLAY_PAUSE |
媒體播放 | 輸入來源:短按 輸出:播放或暫停 |
輸入來源:長按 輸出:啟動語音指令 傳送: android.speech.action.VOICE_SEARCH_HANDS_FREE (表示裝置)
螢幕已鎖定或螢幕關閉傳送
否則會設為 android.speech.RecognizerIntent.ACTION_WEB_SEARCH |
|||
來電 | 輸入來源:短按 輸出:接聽來電 |
||
輸入來源:長按 輸出:拒接來電 |
|||
通話中 | 輸入來源:短按 輸出:結束通話 |
||
輸入來源:長按 輸出:將麥克風設為靜音或取消靜音 |
|||
B | HID 用量頁面:0x0C HID 用量:0x0E9 核心金鑰: KEY_VOLUMEUP Android 金鑰: VOLUME_UP |
媒體播放、通話中 | 輸入來源:長按 輸出:調高系統或耳機的音量 |
C | HID 用量頁面:0x0C HID 用量:0x0EA 核心金鑰: KEY_VOLUMEDOWN Android 金鑰: VOLUME_DOWN |
媒體播放、通話中 | 輸入來源:長按 輸出:調低系統或耳機的音量 |
D | HID 用量頁面:0x0C HID 用量:0x0CF 核心金鑰: KEY_VOICECOMMAND Android 金鑰: KEYCODE_VOICE_ASSIST |
。可以在任何執行個體中觸發。 | 輸入來源:長按 輸出:啟動語音指令 |
- [7.8.2.2/H-1-2] 必須觸發 ACTION_HEADSET_PLUG 但只有在 USB 音訊介面和端點 正確列舉,以便識別連接的終端機類型。
偵測到 USB 音訊端子類型 0x0302 時,會:
- [7.8.2.2/H-2-1] 必須具有以下功能:廣播意圖 ACTION_HEADSET_PLUG 「麥克風」將更多的值設為 0。
偵測到 USB 音訊端子類型 0x0402 時,會:
- [7.8.2.2/H-3-1] 必須具有以下項目的廣播意圖 ACTION_HEADSET_PLUG: 「麥克風」將額外設為 1
當 USB 週邊裝置處於呼叫狀態時,呼叫 API AudioManager.getDevices() 是否已連線:
[7.8.2.2/H-4-1] 必須列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置 如果 USB 音訊終端機類型欄位為 0x0302,則為 isSink()
[7.8.2.2/H-4-2] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_HEADSET,以及 USB 音訊端子的 isSink() 角色 類型欄位大小為 0x0402
[7.8.2.2/H-4-3] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_HEADSET,以及 USB 音訊終端機的角色 isSource() 類型欄位大小為 0x0402
[7.8.2.2/H-4-4] 請列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置 如果 USB 音訊終端機類型欄位為 0x603,則為 isSink()。
[7.8.2.2/H-4-5] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSource() (如果 USB 音訊終端機) 類型欄位大小為 0x604
[7.8.2.2/H-4-6] 必須列出一種類型的裝置 AudioDeviceInfo.TYPE_USB_DEVICE,以及 USB 音訊終端機類型的角色 isSink() 為 0x400
[7.8.2.2/H-4-7] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSource() (如果 USB 音訊終端機) 類型欄位大小為 0x400
[7.8.2.2/H-SR-1] 我們強烈建議在 USB-C 音訊週邊裝置,如要執行 USB 描述元列舉,識別 終端機類型和廣播意圖 ACTION_HEADSET_PLUG 1000 毫秒。
如果手持裝置實作項目宣告 android.hardware.audio.output
和
android.hardware.microphone
,他們:
[5.6/H-1-1] 必須具有平均連續來回行程 提供 500 毫秒或 超過 5 次測量,平均絕對偏差小於 50 毫秒 / 3.5 公釐 Loopback Adapter (如果支援)、USB 回送 (如果支援)。
[5.6/H-1-2] 「必須」的平均延遲時間 至少 500 毫秒內。 麥克風資料路徑
如果手持裝置實作包含至少一項觸覺回饋器,行為器就會:
- [7.10/H]* 不應使用對等旋轉質量 (ERM) 觸覺技術致動器 (震動器)。
- [7.10/H]* 請決定執行器的位置 附近。
- [7.10/H]* 應針對 清晰觸覺回饋 (在 android.view.HapticFeedbackConstants 中) 例如 (CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、 KEYBOARD_TAP、LONG_PRESS、TEXT_HANDLE_MOVE、VIRTUAL_KEY、 VIRTUAL_KEY_RELEASE、CONFIRM、REJECT、GESTURE_START 和 GESTURE_END)。
- [7.10/H]* 應針對
清晰觸覺回饋
(android.os.VibrationEffect)
例如 (effective_TICK、effective_CLICK、admob_HEAVY_CLICK 和
Effect_DOUBLE_CLICK) 且所有可行的大眾
以下項目的
PRIMITIVE_*
常數: 豐富觸覺回饋 位於 android.os.VibrationEffect.Composition 中 也就是名稱 (CLICK、TICK、LOW_TICK、QUICK_FALL、 QUICK_RISE、SLOW_RISE、SPIN、THUD)。其中一些基本功能, 只有在震動器支援時,系統才會提供 LOW_TICK 和 SPIN 頻率相對較低 [7.10/H]* 應遵循對應公開常數指南 (位於 android.view.HapticFeedbackConstants) 中 與建議的 android.os.VibrationEffect 常數 與相應的振盪關係
[7.10/H]* 必須遵循 品質評估 適用於 createOneShot() 和 createWaveform() 相互整合
[7.10/H]* 必須驗證公開 android.os.Vibrator.hasAmplitudeControl() 的結果 API 可正確反映震動功能的能力。
線性共振致動器 (LRA) 是一種單質彈簧高手 慣用的共振頻率,質量在質上互譯
如果手持裝置導入方式包含至少一項線性共振 執行者的工作:
- [7.10/H]* 應在 X 軸上移動觸覺回饋器 縱向模式 (右)。
如果手持裝置採用的觸覺回饋器為 X 軸 線性共振致動器 (LRA) 可以:
- [7.10/H]* X 軸應有雷同的頻率 LRA 低於 200 Hz。
如果手持裝置實作方式遵循觸覺常數對應,就會執行以下動作:
- [7.10/H]* 必須執行 android.os.Vibrator.areAllEffectsSupported() 和 android.os.Vibrator.arePrimitivesSupported() API 的部署作業。
2.2.2. 多媒體
手持裝置實作「必須」支援下列音訊編碼和 以及將格式解碼給第三方應用程式:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] MPEG-4 AAC 設定檔 (AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC 設定檔 (AAC+)
- [5.1/H-0-5] AAC ELD (強化低延遲 AAC)
手持裝置實作「必須」支援下列影片編碼 格式,以及提供給第三方應用程式使用:
手持裝置實作「必須」支援下列影片解碼功能 格式,以及提供給第三方應用程式使用:
2.2.3. 軟體
手持裝置實作方式:
- [3.2.3.1/H-0-1] 必須提供
處理
ACTION_GET_CONTENT
、ACTION_OPEN_DOCUMENT
,ACTION_OPEN_DOCUMENT_TREE
, 和ACTION_CREATE_DOCUMENT
SDK 文件中描述的意圖,並提供使用者負擔 使用DocumentsProvider
API 存取文件提供者資料。 - [3.2.3.1/H-0-2]* 必須預先載入其中一個 具有意圖處理常式的一或多個應用程式或服務元件 下列應用程式定義的所有公開意圖篩選器模式 意圖清單請見這篇文章。
- [3.2.3.1/H-SR-1] 十分可靠 建議預先載入可處理 ACTION_SENDTO 的電子郵件應用程式 或ACTION_SEND 或 ACTION_SEND_MULTIPLE 意圖傳送電子郵件
- [3.4.1/H-0-1] 必須提供完整
android.webkit.Webview
API 的實作。 - [3.4.2/H-0-1] 「必須」包含獨立瀏覽器 一般使用者網路瀏覽應用程式。
- [3.8.1/H-SR-1] 強烈建議你使用 實作預設啟動器,支援應用程式內的捷徑固定功能。 小工具和 widgetFeatures 類別。
- [3.8.1/H-SR-2] 強烈建議你使用 實作預設啟動器,以便快速存取 由第三方應用程式透過 ShortcutManager 提供的捷徑 也能使用 Google Cloud CLI 或 Compute Engine API
- [3.8.1/H-SR-3] 強烈建議你使用 加入預設的啟動器應用程式,為應用程式圖示顯示標記。
- [3.8.2/H-SR-1] 強烈建議你使用 支援第三方應用程式小工具。
- [3.8.3/H-0-1] 必須允許第三方
應用程式可透過
Notification
和NotificationManager
API 類別。 - [3.8.3/H-0-2] 必須支援 RTF 格式 通知。
- [3.8.3/H-0-3] 必須支援抬頭通知 通知。
- [3.8.3/H-0-4] 必須包含 通知欄,方便使用者直接控制 (例如 回覆、延後、關閉、封鎖) 透過使用者預設用途通知,例如 您在 Android 開放原始碼計畫中實作的動作按鈕或控制面板。
- [3.8.3/H-0-5] 必須顯示選項
提供者:
RemoteInput.Builder setChoices()
通知欄 - [3.8.3/H-SR-1] 強烈建議你使用
顯示透過
RemoteInput.Builder setChoices()
提供的第一個選項 且不需任何額外使用者互動。 - [3.8.3/H-SR-2] 強烈建議你使用
顯示透過
RemoteInput.Builder setChoices()
提供的所有選項 在使用者展開 通知欄。 - [3.8.3.1/H-SR-1] 強烈建議你使用
顯示適用於
Notification.Action.Builder.setContextual
的動作 已設為true
,其中會顯示由Notification.Remoteinput.Builder.setChoices
。 - [3.8.4/H-SR-1] 強烈建議你使用 在裝置上實作助理來處理輔助動作。
如果手持裝置實作支援 MediaStyle 通知 他們會:
- [3.8.3.1/H-SR-2] 強烈建議你使用
為使用者提供透過
系統 UI,可讓使用者切換可用的媒體
路徑 (例如藍牙裝置和
MediaRouter2Manager
) 應用程式發布含有MediaSession
權杖的MediaStyle
通知時。
如果手持裝置導入方式支援小幫手動作,會發生以下情況:
- [3.8.4/H-SR-2] 強烈建議你使用
長按
HOME
鍵做為指定互動來啟動 如第 7.2.3 節所述。必須啟動 使用者選擇的輔助應用程式,也就是VoiceInteractionService
敬上 ,或是處理ACTION_ASSIST
意圖的活動。
如果手持裝置實作方式支援 conversation notifications
並將這些郵件分組為獨立部分,與快訊及靜音非對話對話
通知時:
- [3.8.4/H-1-1]* 必須顯示 顯示對話通知: 但「持續性前景服務通知」除外 importance:高 通知。
如果 Android 手持裝置可支援螢幕鎖定,請按照下列步驟操作:
- [3.8.10/H-1-1] 必須顯示居家鎖 畫面通知,包括媒體通知範本。
如果手持裝置支援安全螢幕鎖定,功能會:
如果手持裝置實作支援
ControlsProviderService
敬上
和 Control
API 並允許第三方應用程式發布裝置控制項,接著會進行下列動作:
- [3.8.16/H-1-1] 必須聲明這項功能
標記
android.software.controls
並設為true
。 - [3.8.16/H-1-2] 必須提供使用者
能夠新增、編輯、選取及操作
常用的裝置控制功能 (來自第三方註冊的控制選項)
應用程式,透過
ControlsProviderService
和Control
相互整合 - [3.8.16/H-1-3] 必須授予 會在預設啟動器進行三次互動時提供相應功能
[3.8.16/H-1-4] 必須正確顯示 使用者能承受每個第三方應用程式的名稱和圖示 透過
ControlsProviderService
提供控制項 以及Control
提供的任何指定欄位 相互整合[3.8.16/H-1-5] 必須提供使用者 能夠停用下列應用程式的專用驗證裝置控制項: 透過
ControlsProviderService
和Control
Control.isAuthRequired
API。
相反地,如果手持裝置並未實作這類控制選項, 他們會:
- [3.8.16/H-2-1] 必須檢舉
null
:ControlsProviderService
和Control
相互整合 - [3.8.16/H-2-2] 必須聲明這項功能
標記
android.software.controls
並設為false
。
如果手持裝置的實作無法在鎖定任務模式下執行,那麼將內容複製到剪貼簿時:
- [3.8.17/H-1-1] 必須向使用者確認 複製到剪貼簿 (例如「已複製內容」的縮圖或快訊)。 此外,這裡也會指出系統是否會同步處理剪貼簿資料 跨裝置使用 YouTube
手持裝置實作方式:
- [3.10/H-0-1] 必須支援第三方無障礙設定 免費 Google Cloud 服務
- [3.10/H-SR-1] 強烈建議預先載入 裝置上的無障礙服務與或超越的功能相等 和 TalkBack 的切換控制功能 (適用於 文字轉語音引擎) 無障礙服務,如同TalkBack 開啟頁面所示 來源專案。
- [3.11/H-0-1] 必須支援 第三方 TTS 引擎。
- [3.11/H-SR-1] 極力建議您加入 支援裝置可用語言的 TTS 引擎。
- [3.13/H-SR-1] 極力建議您加入 快速設定 UI 元件。
如果 Android 手持裝置實作項目宣告 FEATURE_BLUETOOTH
或
FEATURE_WIFI
支援,他們:
- [3.16/H-1-1] 必須支援隨附裝置配對 而不是每個特徵的分數
如果系統以手勢動作的形式提供導覽功能:
- [7.2.3/H] 主畫面的手勢辨識區域 函式的高度不得大於 。
如果手持裝置實作以手勢形式提供瀏覽功能 從畫面左側或右側邊緣的任何位置:
- [7.2.3/H-0-1] 導覽函式的手勢區域 每邊的寬度必須小於 40 dp。手勢區域應該是 根據預設,寬度為 24 dp。
如果手持裝置可支援安全螢幕鎖定,且 核心和使用者空間可用的記憶體大小等於或等於 2 GB,這兩者包括:
- [3.9/H-1-2] 必須透過
android.software.managed_users
功能旗標。
如果 Android 手持裝置實作方式宣告支援相機
android.hardware.camera.any
他們:
- [7.5.4/H-1-1] 必須尊重
android.media.action.STILL_IMAGE_CAMERA
和android.media.action.STILL_IMAGE_CAMERA_SECURE
的意圖,並依照 SDK 中的說明,以靜態圖像模式啟動相機。 - [7.5.4/H-1-2] 必須尊重
android.media.action.VIDEO_CAMERA
意圖以啟動影片模式啟動相機 (如 SDK 所述)。
如果手持裝置的實作設定應用程式會 分割功能 然後再透過活動嵌入功能
- [3.2.3.1/ H-1-1]
必須包含用來處理
啟用分割功能時,Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY意圖。活動必須受「
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
」保護,且「必須」使用 啟動剖析自剖析的意圖活動 設定#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI。
2.2.4.效能與功率
- [8.1/H-0-1] 影格延遲時間一致。 影格延遲不一致或轉譯影格延遲,「不得」發生更多 且每秒影格數通常不超過 1 個
- [8.1/H-0-2] 使用者介面延遲。 實作裝置必須「必須」的安全性狀態, Android Compatibility Test Suite 定義的 1 萬個清單項目清單 (CTS) 幾乎不會超過 36 秒。
- [8.1/H-0-3] 工作切換,時間 啟動了多個應用程式, 應用程式啟動後只需不到 1 秒即可。
手持裝置實作方式:
- [8.2/H-0-1] 必須確保 至少每秒 5 MB 的寫入效能。
- [8.2/H-0-2] 必須確保隨機寫入 至少每秒 0.5 MB
- [8.2/H-0-3] 必須確保循序讀取 至少每秒 15 MB 的效能。
- [8.2/H-0-4] 必須確保隨機讀取 至少每秒 3.5 MB
如果手持裝置實作包含提升裝置效能的功能 或擴充 Android 開放原始碼計畫內含的功能 後,您會發現:
手持裝置實作方式:
- [8.4/H-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ,以及測試過程中 。
- [8.4/H-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
- [8.4/H-0-3] 必須回報 CPU 效能
每段程序的 UID。Android 開放原始碼計畫滿足
要求通過
uid_cputime
核心模組實作。 - [8.4/H-0-4] 必須使用
可透過
adb shell dumpsys batterystats
使用 殼層指令給應用程式開發人員。 - [8.4/H] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式
如果手持裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
- [8.4/H-1-1] 必須尊重
android.intent.action.POWER_USAGE_SUMMARY
意圖,並顯示顯示此耗電量的設定選單。
手持裝置實作方式:
- [8.5/H-0-1] 必須在
透過「設定」選單停止執行前景的應用程式
服務,並顯示已啟用前景服務的所有應用程式,以及
定義應用程式後,每次使用付費服務 (SDK 規定)
文件。
- 部分應用程式可能不受禁止,也不必在該應用程式上架。 如 SDK 文件所述。
2.2.5。安全性模型
手持裝置實作方式:
- [9.1/H-0-1] 必須允許第三方應用程式存取
透過
android.permission.PACKAGE_USAGE_STATS
權限和 提供使用者可用的機制,在以下位置授予或撤銷這類應用程式的存取權: 回覆android.settings.ACTION_USAGE_ACCESS_SETTINGS
意圖。
手持裝置實作方式:
- [9.11/H-0-2] 必須備份 KeyStore 實作 隔離的執行環境
- [9.11/H-0-3] 必須導入 RSA、AES、 ECDSA 和 HMAC 加密編譯演算法,以及 MD5、SHA1 和 SHA-2 系列 雜湊函式,妥善支援 Android KeyStore 系統 所在區域的演算法,與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境,包括《數位市場法》上游 Android 開放原始碼 專案 (AOSP) 利用 Trusty 實作項目達成這項規定, ARM TrustZone 解決方案或第三方經過安全審查 可替代實作方式,以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
- [9.11/H-0-4] 必須執行螢幕鎖定 隔離於隔離執行環境中驗證 成功,請允許使用驗證繫結金鑰。螢幕鎖定畫面 憑證的儲存方式必須僅允許獨立執行 執行螢幕鎖定驗證。上游 Android 開放原始碼專案 總機人員硬體抽象層 (HAL) 和 Trusty 合作,以滿足這項需求
- [9.11/H-0-5] 必須支援金鑰認證 認證簽署金鑰受到安全的硬體保護, 在安全的硬體中執行「必須」共用認證簽署金鑰 以便透過足夠數量的裝置使用金鑰 做為裝置 ID為符合這項規定,其中一種方法是提供 除非特定 SKU 至少有 10 萬個單位 產生的結果。如果產生的 SKU 超過 100,000 個單位,請採用 每 100,000 個單位可使用鍵 MAY。
- [9/H-0-1] 必須宣告「android.hardware.security.model.compatible」 而不是每個特徵的分數
請注意,如果裝置已啟動至較舊的 Android 版本
這類裝置不受具有 KeyStore 的限制
並支援金鑰認證
除非宣告了 android.hardware.fingerprint
功能,而該功能需要
由獨立執行環境支援的 KeyStore。
如果手持裝置支援安全螢幕鎖定,行為會:
- [9.11/H-1-1] 必須允許使用者選擇 休眠逾時,也就是從解鎖狀態進入鎖定狀態的時間 則不超過 15 秒。
- [9.11/H-1-2] 必須提供使用者隱藏的額度 通知以及停用所有驗證形式, 訊息中所述的主要驗證 9.11.1 安全螢幕鎖定。Android 開放原始碼計畫會 都應設為鎖定模式
如果手持裝置實作項目包含多位使用者和
未宣告 android.hardware.telephony
功能旗標,則會:
- [9.5/H-2-1] 必須支援設有限制的個人資料、 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後,裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。
如果手持裝置實作項目包含多位使用者和
宣告 android.hardware.telephony
功能旗標後:
- [9.5/H-3-1] 不支援受限制功能 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。
Android 透過 System API VoiceInteractionService 支援 安全啟動字詞偵測功能,偵測不到麥克風存取權
如果手持裝置實作支援 System API
HotwordDetectionService
或其他不含啟動字詞偵測的機制
麥克風存取指標,它們可以:
- [9.8/H-1-1] 必須確認啟動字詞偵測服務只能傳輸 將資料傳送至系統或 ContentCaptureService
- [9.8/H-1-2] 必須確認啟動字詞偵測服務只能傳輸
麥克風音訊資料,或從裝置擷取到系統伺服器的資料
HotwordDetectionService
API,或透過以下方式執行ContentCaptureService
:ContentCaptureManager
API。 - [9.8/H-1-3] 「請勿」提供長度超過 30 秒的麥克風音訊。 對啟動字詞偵測服務發出的硬體觸發要求。
- [9.8/H-1-4] 「不得」提供超過 8 秒的緩衝麥克風音訊。 傳送到啟動字詞偵測服務的個別要求。
- [9.8/H-1-5] 請勿將 30 秒以上的緩衝麥克風音訊提供給 語音互動服務或類似實體
- [9.8/H-1-6] 非音訊資料不得超過 100 個位元組 每個成功啟動字詞都會從啟動字詞偵測服務傳出 結果。
- [9.8/H-1-7] 不得傳輸超過 5 位元的資料 。
- [9.8/H-1-8] 必須允許傳輸啟動字詞中的資料 偵測服務的相關資訊。
- [9.8/H-1-9] 「不得」允許可供使用者安裝的應用程式提供 啟動字詞偵測服務
- [9.8/H-1-10] 符合下列條件時,「不得」在 UI 量化資料中顯示麥克風用量: 啟動字詞偵測服務
- [9.8/H-1-11] 必須記錄每次傳輸中包含的位元組數 啟動字詞偵測服務,以在安全的情況下 研究。
- [9.8/H-1-12] 必須支援偵錯模式, 以便檢查應用程式 安全研究人員
- [9.8/H-1-14] 必須顯示上一節所述的麥克風指示 9.8.2,如果 啟動字詞結果成功傳送至語音 互動服務或類似實體
- [9.8/H-SR-1] 強烈建議使用者在設定 做為啟動字詞偵測服務的供應商
- [9.8/H-SR-2] 強烈建議禁止傳送 非結構化資料。
- [9.8/H-SR-3] 強烈建議你重新開始裝載 啟動字詞偵測服務,至少每小時或每 30 次一次 硬體觸發事件 (以先發生者為準)
如果裝置實作項目包含使用 System API 的應用程式
HotwordDetectionService
,或是類似機制,用於偵測啟動字詞
麥克風使用指標,應用程式:
- [9.8/H-2-1] 針對每個啟動字詞,請務必向使用者明確告知 支援。
- [9.8/H-2-2] 「不得」保留原始音訊資料或衍生的資料 經由啟動字詞偵測服務提交要求
- [9.8/H-2-3] 「不得」從啟動字詞偵測服務、音訊傳輸
包括能用來重新建構音訊 (整或部分) 的資料
或是與啟動字詞本身無關的音訊內容 (
ContentCaptureService
。
如果手持裝置實作項目宣告 android.hardware.microphone
,就會:
- [9.8.2/H-4-1] 發生在以下情況時,必須顯示麥克風指示燈
應用程式正在從麥克風存取音訊資料,但無法存取
只有
HotwordDetectionService
能存取麥克風,SOURCE_HOTWORD
、ContentCaptureService
,或擁有以下角色的應用程式: 列於第 9.1 節,且 CDD ID [C-4-X]。 - [9.8.2/H-4-2] 必須顯示近期和使用中清單
應用程式使用麥克風做為傳回的
PermissionManager.getIndicatorAppOpUsageData()
,以及任何作者資訊 或是與 Gemini 相關的訊息
如果手持裝置實作項目宣告 android.hardware.camera.any
,就會:
- [9.8.2/H-5-1] 應用程式正在存取即時攝影機資料,但若只有攝影機存取,則不會 具有以下角色的應用程式存取: 包含 CDD ID [C-4-X] 的 section 9.1。
- [9.8.2/H-5-2] 必須顯示最近使用過的應用程式和正在使用的應用程式
PermissionManager.getIndicatorAppOpUsageData()
傳回的相機, 以及所有相關的歸因訊息
2.2.6.開發人員工具與選項的相容性
手持裝置實作 (* 不適用於平板電腦):
- [6.1/H-0-1]* 必須支援殼層指令
cmd testharness
。
手持裝置實作 (* 不適用於平板電腦):
- Perfetto
- [6.1/H-0-2]* 必須公開一個
/system/bin/perfetto
cmdline 會符合 Perfetto 說明文件。 - [6.1/H-0-3]* Perfetto 二進位必須接受 輸入符合 Perfetto 說明文件。
- [6.1/H-0-4]* Perfetto 二進位檔「必須」以 然後輸出符合 Perfetto 說明文件。
- [6.1/H-0-5]* 必須透過 Perfetto 提供 二進位檔案,至少應包含 Perfetto 說明文件中所述的資料來源。
- [6.1/H-0-6]* Perfetto 追蹤的 Daemon 必須
預設為啟用 (系統資源
persist.traced.enable
)。
- [6.1/H-0-2]* 必須公開一個
2.2.7.手持媒體效能類別
2.2.7.1。媒體
如果手持裝置實作傳回 android.os.Build.VERSION_CODES.S
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
之後,他們會:
- 必須符合 Android 12 CDD 中列出的媒體要求 第 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] 必須支援 6 個硬體視訊解碼器工作階段執行個體 (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30 fps 同步播放。
- [5.1/H-1-3] 必須通告硬體視訊編碼器的數量上限
可以在任何轉碼器組合中透過
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法 - [5.1/H-1-4] 必須支援 6 個硬體視訊編碼器執行個體 工作階段 (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30fps 同步播放。
- [5.1/H-1-5] 必須通告硬體視訊編碼器的數量上限,
能透過多種轉碼器組合,在任何轉碼器組合中並行執行的解碼器工作階段
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法 - [5.1/H-1-6] 必須支援 6 個硬體視訊解碼器和硬體執行個體 任何轉碼器中的影片編碼器工作階段 (AVC、HEVC、VP9、AV1 或以上) 以 1080p@30 FPS 的解析度並行運作。
- [5.1/H-1-7] 轉碼器初始化延遲時間不得超過 40 毫秒 所有硬體視訊編碼器都適用的 1080p 或更小影片編碼工作階段 載入容器時此處載入定義為 1080p 至 720p 的並行 僅使用硬體視訊轉碼器和 1080p 音訊錄影初始化。對 Dolby Vision 轉碼器而言, 轉碼器初始化延遲時間不得超過 50 毫秒。
- [5.1/H-1-8] 轉碼器初始化延遲時間不得超過 30 毫秒 在所有音訊編碼器中,128 kbps 或較低的位元率音訊編碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊錄音初始化。
- [5.1/H-1-9] 必須支援 2 個安全硬體視訊解碼器執行個體 工作階段 (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30 fps 同步播放。
- [5.1/H-1-10] 必須支援 3 個不安全的硬體視訊解碼器執行個體 以及 1 個安全硬體視訊解碼器工作階段 任何轉碼器組合中 (共 4 個執行個體) (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30 FPS 並行執行。
- [5.1/ H-1-11] 必須為每個硬體 AVC、HEVC、 裝置上的 VP9 或 AV1 解碼器。
- [5.1/H-1-12] 轉碼器初始化延遲時間不得超過 40 毫秒 所有硬體視訊解碼器都適用 1080p 以下的影片解碼工作階段 載入容器時此處載入定義為 1080p 至 720p 的並行 僅使用硬體視訊轉碼器和 1080p 音訊影片播放初始化。針對 Dolby Vision 轉碼器 初始化延遲時間不得超過 50 毫秒。
- [5.1/H-1-13] 轉碼器初始化延遲時間不得超過 30 毫秒 針對所有音訊解碼器產生 128 kbps 或較低的位元率音訊解碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊影片播放初始化。
- [5.1/H-1-14] 必須支援 AV1 硬體解碼器 Main 10 (等級 4.1)。
- [5.1/H-SR-1] 強烈建議你為 AV1 硬體支援底片顆粒 編碼器和解碼器
- [5.1/H-1-15] 至少須有 1 個支援 4K60 的硬體視訊解碼器。
- [5.1/H-1-16] 至少必須使用 1 個支援 4K60 的硬體視訊編碼器。
- [5.3/H-1-1] 「不得」在 10 秒內捨棄超過 1 個畫面 (例如低於 0.167% 影格的影格速率) 可錄製 1080p 60 fps 的影片 載入。載入定義為 1080p 至 720p 的並行影片 這可讓您使用硬體視訊轉碼器 轉碼工作階段,以及 128 kbps 進階音訊播放。
- [5.3/H-1-2] 影片播放期間「不得」在 10 秒內捨棄超過 1 個影格 在載入時,在 60 fps 影片工作階段中會有多快的解析度變化。負載的定義是 使用硬體的 1080p 至 720p 純視訊轉碼工作階段 視訊轉碼器,以及 128 kbps AAC 音訊播放功能。
- [5.6/H-1-1] 觸控色調延遲時間必須不超過 80 毫秒 使用 OboeTester 的觸覺測試,或 CTS Verifier 觸控色調測試。
- [5.6/H-1-2] 往返音訊延遲時間不得超過 80 毫秒 至少使用一個支援的資料路徑
- [5.6/H-1-3] 必須支援 3.5 公釐音訊 (超過 24 位元) 的立體聲輸出
會插入插孔 (如果投放的話) 和 USB 音訊 (如果透過
適用於低延遲和串流設定的完整資料路徑。低溫
延遲設定,則應用程式應在低延遲時間使用 AAudio
回呼模式。串流適用
應用程式應使用 Java AudioTrack。無論
HAL 輸出接收器應接受延遲和串流設定
AUDIO_FORMAT_PCM_24_BIT
、AUDIO_FORMAT_PCM_24_BIT_PACKED
、AUDIO_FORMAT_PCM_32_BIT
或AUDIO_FORMAT_PCM_FLOAT
用於其目標輸出內容 格式。 - [5.6/H-1-4] 必須支援超過 4 個聲道 USB 音訊裝置 (DJ 會使用這些裝置) 來試聽歌曲)。
- [5.6/H-1-5] 必須支援符合類別規範的 MIDI 裝置,並聲明 MIDI 功能旗標
- [5.7/H-1-2] 必須支援「
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
」: 下列內容解密功能。
樣本大小下限 | 4 MiB |
子樣本數量下限 - H264 或 HEVC | 32 |
子樣本數量下限 - VP9 | 9 |
子樣本數下限 - AV1 | 288 號 |
子樣本緩衝區空間下限 | 1 MiB |
一般加密緩衝區空間下限 | 500 KiB |
並行工作階段數量下限 | 30 |
每個工作階段的金鑰數量下限 | 20 |
金鑰總數下限 (所有工作階段) | 80 號 |
DRM 金鑰總數下限 (全部) 工作階段) | 6 |
郵件大小 | 16 KiB |
每秒解密影格數 | 60 fps |
2.2.7.2。相機
如果手持裝置實作傳回 android.os.Build.VERSION_CODES.S
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
之後,他們會:
- 必須符合 Android 12 CDD 中列出的相機需求 第 2.2.7.2 節。
如果手持裝置實作傳回 android.os.Build.VERSION_CODES.T
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
之後,他們會:
- [7.5/H-1-1] 必須使用主要後置鏡頭,解析度須為 至少 1200 萬像素,支援拍攝每秒 4k@30 FPS 的影片。主要 後置鏡頭是指具備最低相機 ID 的後置鏡頭。
- [7.5/H-1-2] 必須使用主要前置鏡頭,解析度須為 至少 500 萬像素,且支援拍攝每秒 1080p@30 FPS 的影片。主要 前置鏡頭是前置鏡頭,且相機 ID 最低。
- [7.5/H-1-3] 必須支援
android.info.supportedHardwareLevel
資源, 如果是後台的主要裝置,至少要FULL
,前端則為LIMITED
。 相機上 - [7.5/H-1-4] 必須提供支援
兩者皆為
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
相機上 - [7.5/H-1-5] 必須具有 camera2 JPEG 擷取延遲時間 <執行時間為 1000 毫秒 根據 ITS 部門的 CTS 鏡頭 PerformanceTest 評估,為 1080p 解析度 兩個主鏡頭的亮度 (300 萬)。
- [7.5/H-1-6] 必須設定 camera2 啟動延遲時間 (開啟相機即可先行預覽) 頁框) <CTS 鏡頭 PerformanceTest 對 ITS 的影響為 500 毫秒 兩個主鏡頭的亮度 (300 萬)。
- [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] 必須達到最低 ZOOM_RATIO <1.0 代表主要鏡頭 (如果有的話) 是面向相同方向的超廣角 RGB 相機。
- [7.5/H-1-11] 「必須」在主要執行個體上實作並行前端串流 相機上
- [7.5/H-1-12] 必須支援
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
做為主要後置鏡頭的相機板 - [7.5/H-1-13] 必須支援主要版本的
LOGICAL_MULTI_CAMERA
功能 後置鏡頭 (如果超過 1 個 RGB 後置鏡頭)。 - [7.5/H-1-14] 必須同時支援兩者的
STREAM_USE_CASE
功能 前置和主要後置鏡頭
2.2.7.3.硬體
如果手持裝置實作傳回android.os.Build.VERSION_CODES.S
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,然後他們:
- 必須符合 Android 12 CDD 中列出的硬體需求 第 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.S
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,然後他們:
- 必須符合 Android 12 CDD 中列出的效能要求 第 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。
- [8.2/H-1-2] 必須確保隨機寫入效能至少達到每秒 10 MB。
- [8.2/H-1-3] 必須確保連續讀取效能至少達到每秒 250 MB。
- [8.2/H-1-4] 必須確保至少 40 MB/秒的隨機讀取效能
2.3.電視需求
Android 電視裝置是指在 是一種娛樂介面,可讓使用者存取數位媒體、電影、遊戲、應用程式, 和/或電視直播服務。 使用者介面」)。
如果 Android 裝置的實作方式符合所有條件,就會歸類為電視 符合以下條件:
- 已提供可遠端控制 顯示螢幕可能離使用者有 10 英尺遠。
- 內嵌螢幕 (對角線長度大於 24) 吋或加入影片輸出連接埠,例如 VGA、HDMI、DisplayPort 或 無線連接埠
本節其他規定僅適用於 Android 電視裝置實作。
2.3.1.硬體
電視裝置導入方式:
- [7.2.2/T-0-1] 必須支援 D-Pad。
- [7.2.3/T-0-1] 必須提供住家和返回 函式。
- [7.2.3/T-0-2] 必須同時傳送一般和長按
返回函式的事件 (
KEYCODE_BACK
) 移到前景應用程式 - [7.2.6.1/T-0-1] 必須支援遊戲
並宣告
android.hardware.gamepad
功能旗標。 - [7.2.7/T] 應提供遠端控制 使用者可以存取非觸控式瀏覽,以及 核心瀏覽鍵輸入。
如果電視裝置導入作業含有 3 軸式陀螺儀,則必須:
電視裝置導入方式:
如果電視裝置實作包含支援主機模式的 USB 連接埠, 他們會:
- [7.5.3/T-1-1] 必須支援外接鏡頭 但不一定總是連上網路
如果電視裝置導入方式是 32 位元:
[7.6.1/T-1-1] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 896 MB:
- 在小螢幕/一般螢幕上,400 dpi 以上
- 在大螢幕上使用 xhdpi 或更高版本
- 搭載 tvdpi 以上版本
如果電視裝置導入方式是 64 位元:
[7.6.1/T-2-1] 核心的可用記憶體 如果符合下列任何一種密度,則使用者空間大小至少必須為 1280 MB 已使用:
- 在小螢幕/一般螢幕上,400 dpi 以上
- 在大螢幕上使用 xhdpi 或更高版本
- 搭載 tvdpi 以上版本
請注意,「核心和使用者空間可用的記憶體」以上是指 所提供的記憶體空間 無線電、影片等硬體元件 並控制在裝置實作上。
電視裝置導入方式:
2.3.2.多媒體
電視裝置實作「必須」支援下列音訊編碼 以及解碼格式,並提供給第三方應用程式使用:
- [5.1/T-0-1] MPEG-4 AAC 設定檔 (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC 設定檔 (AAC+)
- [5.1/T-0-3] AAC ELD (強化低延遲 AAC)
電視裝置實作「必須」支援下列影片編碼 格式,以及提供給第三方應用程式使用:
電視裝置導入方式:
- [5.2.2/T-SR-1] 強烈建議你提供支援 以每秒 30 個影格的速度播放 720p 與 1080p 解析度影片的 H.264 編碼。
電視裝置實作「必須」支援下列影片解碼功能 格式,以及提供給第三方應用程式使用:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
電視裝置實作「必須」支援 MPEG-2 解碼,詳情請見 第 5.3.1 節:標準影片影格速率,且最高和 包括:
- [5.3.1/T-1-1] HD 高畫質 1080p (每秒 29.97 影格) 主要設定檔
- [5.3.1/T-1-2] HD 高畫質 1080i,每秒 59.94 影格 主要設定檔他們必須「必須」解除交錯 MPEG-2 影片 並提供給第三方應用程式
電視裝置實作「必須」支援 H.264 解碼功能,詳情請見 第 5.3.4 節:標準影片影格速率,且最高和 包括:
- [5.3.4/T-1-1] HD 高畫質 1080p (每秒 60 影格) 基準設定檔
- [5.3.4/T-1-2] HD 高畫質 1080p (每秒 60 影格) 主要個人資料
- [5.3.4/T-1-3] HD 高畫質 1080p (每秒 60 影格) 高設定檔層級 4.2
採用 H.265 硬體解碼器的電視裝置實作「必須」支援 H.265 解碼 (如第 5.3.5 節所述),以標準影片影格速率播放 及解析度:
- [5.3.5/T-1-1] HD 高畫質 1080p (每秒 60 影格) 主要設定檔層級 4.1
如果電視裝置實作支援 H.265 硬體解碼器 H.265 解碼和 UHD 超高畫質設定檔時,兩者會:
- [5.3.5/T-2-1] 必須支援 UHD 解碼設定檔 每秒 60 個影格,搭配 Main10 第 5 級主要設定檔
電視裝置實作「必須」支援 VP8 解碼,詳情請見 第 5.3.6 節:標準影片影格速率,且最高和 包括:
- [5.3.6/T-1-1] HD 高畫質 1080p (每秒 60 影格) 解碼設定檔
採用 VP9 硬體解碼器的電視裝置實作「必須」支援 VP9 可以採用標準影片影格速率 最高 (含) 以下的解析度:
- [5.3.7/T-1-1] HD 高畫質 1080p (每秒 60 影格) 設定檔 0 (8 位元色彩深度)
如果電視裝置實作搭配 VP9 硬體解碼器支援 VP9 以及 UHD 解碼設定檔
- [5.3.7/T-2-1] 必須支援 UHD 解碼設定檔 每秒 60 個影格,設定檔 0 (8 位元色彩深度)。
- [5.3.7/T-SR1] 強烈建議你提供支援 UHD 超高畫質解碼設定檔,每秒 60 個影格,設定檔 2 (10 位元色彩深度)。
電視裝置導入方式:
- [5.5/T-0-1] 必須支援系統主節點 支援的輸出內容音量和數位音訊輸出音量, ,但不適用於經過壓縮的音訊直通輸出 (不會進行音訊解碼) 應用程式)。
如果電視裝置沒有內建螢幕, 但支援透過 HDMI 連接的外接螢幕:
- [5.8/T-0-1] 必須將 HDMI 輸出模式設為 選擇 50Hz 或 60Hz 支援的最大解析度 重新整理頻率。
- [5.8/T-SR-1] 極力建議為使用者提供服務 可設定的 HDMI 刷新率選取器。
- [5.8] 必須設定 HDMI 輸出模式重新整理頻率 至 50Hz 或 60Hz,取決於該區域的 裝置販售日期
如果電視裝置沒有內建螢幕, 但支援透過 HDMI 連接的外接螢幕:
- [5.8/T-1-1] 必須支援 HDCP 2.2。
如果電視裝置導入作業不支援 UHD 解碼功能,但 支援透過 HDMI 連接的外接螢幕:
- [5.8/T-2-1] 必須支援 HDCP 1.4
2.3.3.軟體
電視裝置導入方式:
- [3/T-0-1] 必須聲明
android.software.leanback
和android.hardware.type.television
。 - [3.2.3.1/T-0-1] 必須預先載入一或多個 具有意圖處理常式的更多應用程式或服務元件 下列應用程式意圖定義的公開意圖篩選器模式 請參閱這篇文章。
- [3.4.1/T-0-1] 必須提供完整
android.webkit.Webview
API 的實作。
如果 Android TV 裝置實作支援螢幕鎖定功能,可執行以下動作:
- [3.8.10/T-1-1] 必須顯示門鎖 畫面通知,包括媒體通知範本。
電視裝置導入方式:
- [3.8.14/T-SR-1] 強烈建議你使用 支援子母畫面 (PIP) 模式的多視窗模式。
- [3.10/T-0-1] 必須支援第三方無障礙設定 免費 Google Cloud 服務
- [3.10/T-SR-1] 強烈建議你 在裝置上預先載入無障礙服務 切換控制功能和 TalkBack 的功能 (適用於 預先安裝的文字轉語音引擎) 無障礙服務 Talkback 開放原始碼專案。
如果電視裝置導入方式回報這項功能
android.hardware.audio.output
,他們:
電視裝置導入方式:
- [3.12/T-0-1] 必須支援電視輸入架構。
2.3.4.效能與功率
- [8.1/T-0-1] 影格延遲時間一致。 影格延遲不一致或轉譯影格延遲,「不得」發生更多 且每秒影格數通常不超過 1 個
- [8.2/T-0-1] 必須確保 至少每秒 5 MB 的寫入效能。
- [8.2/T-0-2] 必須確保隨機寫入 至少每秒 0.5 MB
- [8.2/T-0-3] 必須確保 至少每秒 15 MB 的讀取效能。
- [8.2/T-0-4] 必須確保隨機讀取 至少每秒 3.5 MB
如果電視裝置導入了可改善裝置效能的功能 或擴充 Android 開放原始碼計畫內含的功能 後,您會發現:
- [8.3/T-1-1] 必須提供使用者預設用途才能啟用 然後停用省電模式
如果電視裝置未安裝電池:
如果電視裝置導入的電池符合下列條件:
- [8.3/T-1-3] 必須為使用者提供顯示空間 所有適用應用程式待命和打盹省電模式的應用程式。
電視裝置導入方式:
- [8.4/T-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ,以及測試過程中 。
- [8.4/T-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
- [8.4/T-0-3] 必須回報 CPU 效能
每段程序的 UID。Android 開放原始碼計畫滿足
要求通過
uid_cputime
核心模組實作。 - [8.4/T] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式
- [8.4/T-0-4] 必須使用
可透過
adb shell dumpsys batterystats
使用 殼層指令給應用程式開發人員。
2.3.5。安全性模型
電視裝置導入方式:
- [9.11/T-0-1] 必須備份 KeyStore 實作 隔離的執行環境
- [9.11/T-0-2] 必須導入 RSA、AES、 ECDSA 和 HMAC 加密編譯演算法,以及 MD5、SHA1 和 SHA-2 系列 雜湊函式,妥善支援 Android KeyStore 系統 所在區域的演算法,與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境,包括《數位市場法》上游 Android 開放原始碼 專案 (AOSP) 利用 Trusty 實作項目達成這項規定, ARM TrustZone 解決方案或第三方經過安全審查 可替代實作方式,以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
- [9.11/T-0-3] 必須執行螢幕鎖定 隔離於隔離執行環境中驗證 成功,請允許使用驗證繫結金鑰。螢幕鎖定畫面 憑證的儲存方式必須僅允許獨立執行 執行螢幕鎖定驗證。上游 Android 開放原始碼專案 總機人員硬體抽象層 (HAL) 和 Trusty 合作,以滿足這項需求
- [9.11/T-0-4] 必須支援金鑰認證, 認證簽署金鑰受到安全的硬體保護, 在安全的硬體中執行「必須」共用認證簽署金鑰 以便透過足夠數量的裝置使用金鑰 做為裝置 ID為符合這項規定,其中一種方法是提供 除非特定 SKU 至少有 10 萬個單位 產生的結果。如果產生的 SKU 超過 100,000 個單位,請採用 每 100,000 個單位可使用鍵 MAY。
- [9/T-0-1] 必須宣告「android.hardware.security.model.compatible」 而不是每個特徵的分數
請注意,如果裝置已啟動至較舊的 Android 版本
這類裝置不受具有 KeyStore 的限制
並支援金鑰認證
除非宣告了 android.hardware.fingerprint
功能,而該功能需要
由獨立執行環境支援的 KeyStore。
如果電視裝置支援安全的螢幕鎖定功能,便可:
- [9.11/T-1-1] 必須允許使用者選擇睡眠 逾時狀況 允許逾時,最長可達 15 秒。
如果電視裝置導入方式有多位使用者
未宣告 android.hardware.telephony
功能旗標,則會:
- [9.5/T-2-1] 必須支援設有限制的個人資料。 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後,裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。
如果電視裝置導入方式有多位使用者
宣告 android.hardware.telephony
功能旗標後:
- [9.5/T-3-1] 不支援受限制的 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。
如果電視裝置實作項目宣告 android.hardware.microphone
,就會:
- [9.8.2/T-4-1] 發生在以下情況時,必須顯示麥克風指示燈 應用程式正在從麥克風存取音訊資料,但無法存取 麥克風只能透過 HotwordDetectionService、SOURCE_HOTWORD、 ContentCaptureService,或擁有第 9.1 節所述角色的應用程式 CDD ID C-3-X] 的權限。
- [9.8.2/T-4-2] 不得隱藏 具有可見使用者介面或直接使用者互動的系統應用程式。
如果電視裝置實作項目宣告 android.hardware.camera.any
,就會:
- [9.8.2/T-5-1] 應用程式正在存取即時攝影機資料,但只有攝影機存取時則不會 擁有第 9.1 節所述角色的應用程式能夠存取 CDD ID [C-3-X] 的權限。
- [9.8.2/T-5-2] 請勿隱藏相機指標的 具有可見使用者介面或直接使用者互動的系統應用程式。
2.3.6.開發人員工具與選項的相容性
電視裝置導入方式:
- Perfetto
- [6.1/T-0-1] 必須公開一個
/system/bin/perfetto
cmdline 會符合 Perfetto 說明文件。 - [6.1/T-0-2] Perfetto 二進位檔「必須」接受 輸入符合 Perfetto 說明文件。
- [6.1/T-0-3] Perfetto 二進位檔「必須」以 然後輸出符合 Perfetto 說明文件。
- [6.1/T-0-4] 必須透過 Perfetto 提供 二進位檔案,至少應包含 Perfetto 說明文件中所述的資料來源。
- [6.1/T-0-1] 必須公開一個
2.4.智慧手錶需求
Android Watch 裝置是指 Android 裝置實作,目的是 例如戴在手腕上
如果 Android 裝置的導入方式符合所有 符合下列條件:
- 螢幕的實際對角線長度必須介於 1.1 至 2.5 之間 吋。
- 提供要戴在身上的機制。
本節其他規定僅適用於 Android 手錶裝置實作。
2.4.1.硬體
手錶裝置實作:
[7.1.1.1/W-0-1] 「必須」顯示 介於 1.1 到 2.5 吋之間
[7.2.3/W-0-1] 必須支援家用功能 和返回函式,但位於
UI_MODE_TYPE_WATCH
時除外。[7.2.4/W-0-1] 必須支援觸控螢幕輸入。
[7.3.1/W-SR-1] 強烈建議你加入 3 軸 加速計。
如果手錶裝置導入方式包含 GPS/GNSS 接收器,並回報
透過 android.hardware.location.gps
功能將功能套用至應用程式
旗幟,他們可以:
- [7.3.3/W-1-1] 務必立即回報 GNSS 測量結果 。
- [7.3.3/W-1-2] 必須回報 GNSS 虛擬範圍和虛擬範圍 費率,在判斷地點後,在開放天際的環境中顯示 靜息或移動,且每秒小於 0.2 公尺的平方 足以計算出 20 公尺以內且速度 0.2 公尺以內,至少 95% 的時間
如果手錶裝置導入方式包含 3 軸式迴轉儀,代碼會:
- [7.3.4/W-2-1] 必須能夠評估螢幕方向變化 高達每秒 1000 度
手錶裝置實作:
[7.4.3/W-0-1] 必須支援藍牙。
[7.6.1/W-0-1] 至少必須為 非揮發性儲存空間,適用於應用程式私人資料 (又稱「/data」分區)。
[7.6.1/W-0-2] 至少必須有 416 MB 記憶體 提供給核心和使用者空間使用
[7.8.1/W-0-1] 必須包含麥克風。
[7.8.2/W] 可能會輸出音訊。
2.4.2.多媒體
沒有其他相關規定。
2.4.3.軟體
手錶裝置實作:
- [3/W-0-1] 必須聲明這項功能
android.hardware.type.watch
。 - [3/W-0-2] 必須支援 uiMode = UI_MODE_TYPE_WATCH。
- [3.2.3.1/W-0-1] 必須預先載入其中一個 具有意圖處理常式的一或多個應用程式或服務元件 下列應用程式定義的所有公開意圖篩選器模式 意圖清單請見這篇文章。
手錶裝置實作:
宣告 android.hardware.audio.output
的手錶裝置實作
功能旗標:
- [3.10/W-1-1] 必須支援第三方無障礙設定 免費 Google Cloud 服務
- [3.10/W-SR-1] 強烈建議預先載入 裝置上的無障礙服務與或超越的功能相等 和 TalkBack 的切換控制功能 (適用於 文字轉語音引擎) 無障礙服務 Talkback 開放原始碼專案。
如果手錶裝置實作方式回報 android.hardware.audio.output 功能, 他們會:
2.4.4.效能與功率
如果實作的手錶裝置內含可改善裝置效能的功能 或擴充 Android 開放原始碼計畫內含的功能 後,您會發現:
手錶裝置實作:
- [8.4/W-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ,以及測試過程中 。
- [8.4/W-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
- [8.4/W-0-3] 必須回報 CPU 效能
每段程序的 UID。Android 開放原始碼計畫滿足
要求通過
uid_cputime
核心模組實作。 - [8.4/W-0-4] 必須使用
可透過
adb shell dumpsys batterystats
使用 殼層指令給應用程式開發人員。 - [8.4/W] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式
2.4.5。安全性模型
手錶裝置實作:
- [9/W-0-1] 必須宣告
android.hardware.security.model.compatible
而不是每個特徵的分數
如果手錶裝置實作項目包含多位使用者,且
未宣告 android.hardware.telephony
功能旗標,則會:
- [9.5/W-1-1] 必須支援設有限制的個人資料。 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後,裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。
如果手錶裝置實作項目包含多位使用者,且
宣告 android.hardware.telephony
功能旗標後:
- [9.5/W-2-1] 不支援受限制功能 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。
2.5.汽車規定
Android Automotive 實作是指執行中的車輛車用運算主機 Android 是部分或整個系統的作業系統,和/或 資訊娛樂功能
Android 裝置的實作方式如果宣告為 Automotive 應用程式
「android.hardware.type.automotive
」功能或符合下列所有條件
標準。
- 嵌入或連接汽車車輛的一部分。
- 使用駕駛座椅列的螢幕做為主要顯示器。
本節其他規定僅適用於 Android Automotive 裝置實作。
2.5.1.硬體
Automotive 裝置實作:
- [7.1.1.1/A-0-1] 螢幕至少要有 6 單位和實際對角線尺寸
[7.1.1.1/A-0-2] 必須設有螢幕大小的版面配置 至少 750 dp x 480 dp
[7.2.3/A-0-1] 必須提供住家功能,且 5 月 會提供 Back 和 Recent 函式。
[7.2.3/A-0-2] 必須同時傳送一般和長按 返回函式的事件 (
KEYCODE_BACK
) 移到前景應用程式[7.3/A-0-1] 必須導入及回報
GEAR_SELECTION
、NIGHT_MODE
,PERF_VEHICLE_SPEED
和PARKING_BRAKE_ON
。[7.3/A-0-2]
NIGHT_MODE
旗標「必須」與數字面板日/夜間模式一致,且應該根據 環境光度感應器輸入基礎環境光度感應器可能與相同 Photometer 轉換成。[7.3/A-0-3] 必須提供感應器的其他資訊欄位
TYPE_SENSOR_PLACEMENT
。[7.3/A-SR1] 可能死亡地點 將 GPS/GNSS 與其他感應器結合在一起如果位置 致命危險,極力建議您採行 對應的感應器 類型和/或車輛物業 ID
[7.3/A-0-4] 地點 透過 LocationManager#requestLocationUpdates() 要求 「必須與」對應。
[7.3/A-SR-1] STRONGLY_RECOMMENDED 可納入 3 軸 加速計和 3 軸式迴轉儀。
[7.3/A-SR-2] 想要導入並回報
TYPE_HEADING
感應器。
如果 Automotive 裝置實作支援 OpenGL ES 3.1,就會執行以下動作:
- [7.1.4.1/A-0-1] 必須聲明 OpenGL ES 3.1 以上版本。
- [7.1.4.1/A-0-2] 必須支援 Vulkan 1.1。
- [7.1.4.1/A-0-3] 必須加入 Vulkan 載入器 並匯出所有符號
如果 Automotive 裝置導入加速計,請按照下列步驟操作:
- [7.3.1/A-1-1] 必須能夠按頻率回報活動 至少 100 Hz。
如果裝置導入方式包含 3 軸式加速度計,就會發生以下情形:
- [7.3.1/A-SR-1] 強烈建議導入 複合感應器,適用於限定軸心加速計
如果 Automotive 裝置導入的加速計低於 3 軸來:
- [7.3.1/A-1-3] 必須導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES
感應器。 - [7.3.1/A-1-4] 必須導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
感應器。
如果 Automotive 裝置導入了陀螺儀,則必須:
- [7.3.4/A-2-1] 必須能夠按頻率回報事件 至少 100 Hz。
- [7.3.4/A-2-3] 必須能夠評估螢幕方向變化 到每秒可達 250 度的位置
- [7.3.4/A-SR-1] 強烈建議你為 陀螺儀的測量範圍為 +/-250dp,以便盡可能提高解析度
如果 Automotive 裝置導入作業包含 3 軸式迴轉儀,請按照下列步驟操作:
- [7.3.4/A-SR-2] 強烈建議導入 適用於有限軸形陀螺儀的複合感應器。
如果 Automotive 裝置實作的陀螺儀少於 3 軸,則:
- [7.3.4/A-4-1] 必須導入及回報
TYPE_GYROSCOPE_LIMITED_AXES
感應器。 - [7.3.4/A-4-2] 必須導入及回報
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
感應器。
如果 Automotive 裝置導入了 GPS/GNSS 接收器,但沒有 包括:
- [7.3.3/A-3-1] 初次必須判斷所在位置 GPS/GNSS 接收器在 60 秒內開機或超過 4 天。
- [7.3.3/A-3-2] 必須符合首次修正時間條件 如 7.3.3/C-1-2 和 7.3.3/C-1-6 所述 則針對所有其他位置要求 (例如非第一次的要求) 或超過 4 天後)。規定 7.3.3/C-1-2 為 通常可在沒有行動網路數據連線的車輛中運作 方法是使用 最後已知車輛位置以及現在的 至少 60 秒,且位置準確度符合 7.3.3/C-1-3,或兩者並用。
如果汽車裝置實作包含 TYPE_HEADING
感應器,其:
- [7.3.4/A-4-3] 必須能夠按頻率回報事件 至少 1 Hz。
- [7.3.4/A-SR-3] STRONGLY_RECOMMENDED 可回報下列事件: 頻率至少為 10 Hz。
- 應參照正北。
- 車輛靜止不動時仍應使用車輛。
- 解析度至少要為 1 度。
Automotive 裝置實作:
- [7.4.3/A-0-1] 必須支援藍牙,且應採用 支援藍牙 LE。
- [7.4.3/A-0-2] Android Automotive 實作項目
必須支援下列藍牙設定檔:
- 透過免持聽筒設定檔 (HFP) 撥打電話。
- 透過音訊發布設定檔 (A2DP) 播放媒體。
- 遠端控制設定檔 (AVRCP) 的媒體播放控制項。
- 透過電話簿存取設定檔 (PBAP) 分享聯絡人。
[7.4.3/A-SR-1] 強烈建議你提供支援 訊息存取設定檔 (MAP)。
[7.4.5/A] 必須支援行動網路 以網路為基礎的數據連線
[7.4.5/A] 可使用 System API 以下項目的
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
常數: 系統應用程式應該可以使用的網路。
室外視角攝影機是指拍攝裝置外部場景的相機 例如後置鏡頭
Automotive 裝置實作:
- 必須設置一或多個室外視角相機。
如果 Automotive 裝置導入了外部視角相機,例如 相機的作用:
- [7.5/A-1-1] 不得有室外視角 使用 Android Camera API,除非它們符合 符合相機核心需求。
[7.5/A-SR-1] 強烈建議不要輪播或 水平鏡像翻轉相機預覽畫面
[7.5/A-SR-2] 強烈建議你提出解決方法 至少 130 萬像素
應使用固定對焦或 EDOF (延伸領域深度) 硬體。
可能在 相機驅動程式
如果汽車裝置實作方式包含一或多個室外視角相機, 並載入「外部檢視系統」(EVS) 服務,然後針對這類相機:
- [7.5/A-2-1] 不得旋轉或水平鏡射 。
Automotive 裝置實作:
- 「可能」包含一或多個第三方可用的攝影機 應用程式。
如果汽車裝置實作項目至少包含一支攝影機, 第三方應用程式提供的功能:
- [7.5/A-3-1] 必須回報功能標記
android.hardware.camera.any
。 - [7.5/A-3-2] 不得宣告相機為 「系統相機」
- 支援外部相機 (如第 7.5.3 節所述)。
- 可能提供後置鏡頭的功能 (例如自動對焦等) 如第 7.5.1 節所述。
Automotive 裝置實作:
[7.6.1/A-0-1] 至少必須有 4 GB 適用於應用程式私人資料的非揮發性儲存空間 (又稱為「/data」分區)。
[7.6.1/A] 必須設定資料分區的格式 提升效能和快閃記憶體的壽命,例如 使用
f2fs
檔案系統。
如果 Automotive 裝置實作方式是透過 部分內部非卸除式儲存空間時,您可以:
- [7.6.1/A-SR-1] 強烈建議你減少
對在外部儲存空間執行作業的 I/O 負擔,例如
使用
SDCardFS
。
如果 Automotive 裝置實作方式為 64 位元:
[7.6.1/A-2-1] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 816 MB:
- 在小螢幕/一般螢幕上,280 dpi 以下
- 搭載超大型螢幕的 ldpi 或更低版本
- 大螢幕上的 mdpi 或更低
[7.6.1/A-2-2] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間至少必須為 944MB:
- 小螢幕/一般螢幕適用的 xhdpi 或更高
- 在大螢幕上使用 hdpi 或更高版本
- 在特大型螢幕上使用 mdpi 或更高版本
[7.6.1/A-2-3] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 1280 MB:
- 在小螢幕/一般螢幕上,400 dpi 以上
- 在大螢幕上使用 xhdpi 或更高版本
- 搭載 tvdpi 以上版本
[7.6.1/A-2-4] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 1824 MB:
- 在小螢幕/一般螢幕上,採用 560 dpi 以上
- 在大螢幕裝置上播放 400 dpi 以上
- 搭載 xhdpi (含) 以上大螢幕
請注意,「核心和使用者空間可用的記憶體」以上是指 所提供的記憶體空間 無線電、影片等非核心的 控管裝置導入方式
Automotive 裝置實作:
- [7.7.1/A] 必須納入支援週邊裝置模式的 USB 連接埠。
Automotive 裝置實作:
- [7.8.1/A-0-1] 必須包含麥克風。
Automotive 裝置實作:
- [7.8.2/A-0-1] 必須備妥音訊輸出並宣告
android.hardware.audio.output
。
2.5.2。多媒體
Automotive 裝置實作項目「必須」支援下列音訊編碼 以及解碼格式,並提供給第三方應用程式使用:
- [5.1/A-0-1] MPEG-4 AAC 設定檔 (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC 設定檔 (AAC+)
- [5.1/A-0-3] AAC ELD (強化低延遲 AAC)
Automotive 裝置實作項目「必須」支援下列影片編碼 格式,以及提供給第三方應用程式使用:
Automotive 裝置實作項目「必須」支援下列影片解碼功能 格式,以及提供給第三方應用程式使用:
我們強烈建議導入 Automotive 裝置,以便支援 下列影片解碼:
- [5.3/A-SR-1] H.265 HEVC
2.5.3.軟體
Automotive 裝置實作:
[3/A-0-1] 必須聲明功能
android.hardware.type.automotive
。[3/A-0-2] 必須支援 uiMode =
UI_MODE_TYPE_CAR
。[3/A-0-3] 必須支援
android.car.*
命名空間
如果 Automotive 裝置實作提供專屬的 API
android.car.CarPropertyManager
,內含
android.car.VehiclePropertyIds
,
他們會:
Automotive 裝置實作:
[3.2.1/A-0-1] 必須全面支援並強制執行所有政策 權限常數 (如汽車權限參考資料頁面所記錄)。
[3.2.3.1/A-0-1] 必須預先載入一或多個 具有意圖處理常式的更多應用程式或服務元件 下列應用程式意圖定義的公開意圖篩選器模式 請參閱這篇文章。
[3.4.1/A-0-1] 必須提供完整
android.webkit.Webview
API 的實作。[3.8.3/A-0-1] 必須顯示 使用
Notification.CarExtender
的通知 API 要求。
如果 Automotive 裝置實作包含「按下並交談」按鈕,就會:
- [3.8.4/A-1-1] 必須使用短暫的
將按下推送按鈕指派為指定互動的操作
使用者選擇的輔助應用程式,也就是
VoiceInteractionService
。
Automotive 裝置實作:
- [3.8.3.1/A-0-1] 必須正確
按照
Notifications on Automotive OS
中所述轉譯資源。 SDK 說明文件。 - [3.8.3.1/A-0-2] 必須顯示
使用「播放」和「靜音」模式取代透過
Notification.Builder.addAction()
- [3.8.3.1/A] 必須限制 使用豐富的管理工作,例如個別通知管道的控制。 可依應用程式使用 UI 預設用途來減少控管。
如果 Automotive 裝置實作項目支援使用者 HAL 屬性,則:
Automotive 裝置實作:
- [3.14/A-0-1] 必須納入支援的 UI 架構 第一節所述使用媒體 API 的第三方應用程式。 3.14。
- [3.14/A-0-2] 必須允許使用者安全地進行互動 。
- [3.14/A-0-3] 必須支援
CAR_INTENT_ACTION_MEDIA_TEMPLATE
隱含意圖動作CAR_EXTRA_MEDIA_PACKAGE
外加。 - [3.14/A-0-4] 必須提供導航用途 是媒體應用程式的 偏好 活動, 但只有在車輛使用者體驗限制功能未生效時,才需要啟用這項功能。
- [3.14/A-0-5] 必須顯示
錯誤訊息
而且必須支援選用的額外項目
ERROR_RESOLUTION_ACTION_LABEL
和ERROR_RESOLUTION_ACTION_INTENT
。 - [3.14/A-0-6] 必須支援應用程式內搜尋預設用途 支援搜尋功能的應用程式。
- [3.14/A-0-7] 必須尊重
CONTENT_STYLE_BROWSABLE_HINT
和CONTENT_STYLE_PLAYABLE_HINT
顯示 MediaBrowser 產品的定義 階層
如果 Automotive 裝置實作內含預設啟動器應用程式,就會執行以下動作:
- [3.14/A-1-1] 必須包括及開啟媒體服務
使用
CAR_INTENT_ACTION_MEDIA_TEMPLATE
意圖。
Automotive 裝置實作:
- [3.8/A] 可能會限制應用程式
要求進入全螢幕模式,如
immersive documentation
所述。 - [3.8/A] 可保留狀態列, 導覽列
- [3.8/A] 可能會限制應用程式 要求變更系統 UI 元素後方的顏色,以確保 這些元素必須隨時能清楚顯示
2.5.4.效能與功率
Automotive 裝置實作:
- [8.2/A-0-1] 必須回報
根據各個程序的 UID 讀取和寫入非揮發性儲存空間,
開發人員可透過 System API 查看統計資料
android.car.storagemonitoring.CarStorageMonitoringManager
。Android 公開 來源專案透過uid_sys_stats
核心模組符合要求。 - [8.3/A-1-3] 必須支援車庫模式。
- [8.3/A] 至少應使用車庫模式
開車後 15 分鐘,但下列情形除外:
- 電量耗盡。
- 未安排任何閒置工作。
- 駕駛會結束車庫模式。
- [8.4/A-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ,以及測試過程中 。
- [8.4/A-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
- [8.4/A-0-3] 必須回報 CPU 效能
每段程序的 UID。Android 開放原始碼計畫滿足
要求通過
uid_cputime
核心模組實作。 - [8.4/A] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式
- [8.4/A-0-4] 必須使用
可透過
adb shell dumpsys batterystats
使用 殼層指令給應用程式開發人員。
2.5.5。安全性模型
如果 Automotive 裝置實作支援多位使用者:
- [9.5/A-1-1] 不得允許使用者與 也可以切換至無使用者介面系統使用者 但裝置佈建除外。
- [9.5/A-1-2] 必須切換為次要使用者
BOOT_COMPLETED
前。 - [9.5/A-1-3] 必須支援建立 訪客使用者 即使已達到裝置的數量上限也一樣
如果 Automotive 裝置實作項目宣告 android.hardware.camera.any
,則
他們會:
- [9.8.2/A-2-1] 運作時,「必須」顯示相機指示燈 應用程式正在存取即時攝影機資料,但若只有攝影機存取,則不會 具有以下角色的應用程式存取: 第 9.1 節權限 。
- [9.8.2/A-2-2] 請勿隱藏相機指標的 具有可見使用者介面或直接使用者互動的系統應用程式。
Automotive 裝置實作:
- [9.11/A-0-1] 必須備份 KeyStore 實作 隔離的執行環境
- [9.11/A-0-2] 必須導入 RSA、AES、 ECDSA 和 HMAC 加密編譯演算法,以及 MD5、SHA1 和 SHA-2 系列 雜湊函式,妥善支援 Android KeyStore 系統 所在區域的演算法,與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境,包括《數位市場法》上游 Android 開放原始碼 專案 (AOSP) 利用 Trusty 實作項目達成這項規定, ARM TrustZone 解決方案或第三方經過安全審查 可替代實作方式,以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
- [9.11/A-0-3] 必須執行螢幕鎖定 隔離於隔離執行環境中驗證 成功,請允許使用驗證繫結金鑰。螢幕鎖定畫面 憑證的儲存方式必須僅允許獨立執行 執行螢幕鎖定驗證。上游 Android 開放原始碼專案 總機人員硬體抽象層 (HAL) 和 Trusty 合作,以滿足這項需求
- [9.11/A-0-4] 必須支援金鑰認證, 認證簽署金鑰受到安全的硬體保護, 在安全的硬體中執行「必須」共用認證簽署金鑰 以便透過足夠數量的裝置使用金鑰 做為裝置 ID為符合這項規定,其中一種方法是提供 除非特定 SKU 至少有 10 萬個單位 。如果產生的 SKU 超過 100,000 個單位,請採用 每 100,000 個單位可使用鍵 MAY。
- [9/A-0-1] 必須宣告「android.hardware.security.model.compatible」 而不是每個特徵的分數
請注意,如果裝置已啟動至較舊的 Android 版本
這類裝置不受具有 KeyStore 的限制
並支援金鑰認證
除非宣告了 android.hardware.fingerprint
功能,而該功能需要
由獨立執行環境支援的 KeyStore。
Automotive 裝置實作:
- [9.14/A-0-1] 必須控管郵件 來自 Android 架構車輛子系統,例如將允許的訊息加入許可清單 以及訊息來源
- [9.14/A-0-2] 必須防止監控 來自 Android 架構或第三方應用程式的阻斷服務攻擊。這個 防止惡意軟體在車輛網路中流出流量。 這可能會導致車輛子系統故障。
2.5.6.開發人員工具與選項的相容性
Automotive 裝置實作:
- Perfetto
- [6.1/A-0-1] 必須公開一個
/system/bin/perfetto
cmdline 會符合 Perfetto 說明文件。 - [6.1/A-0-2] Perfetto 二進位檔「必須」接受 輸入符合 Perfetto 說明文件。
- [6.1/A-0-3] Perfetto 二進位檔「必須」以 然後輸出符合 Perfetto 說明文件。
- [6.1/A-0-4] 必須透過 Perfetto 提供 二進位檔案,至少應包含 Perfetto 說明文件中所述的資料來源。
- [6.1/A-0-1] 必須公開一個
2.6.平板電腦需求
Android 平板電腦裝置是指 Android 裝置實作, 通常符合下列所有條件:
- 用於雙手並用於雙手。
- 沒有貝殼式設計或可轉換設定。
- 與裝置連線搭配使用的實體鍵盤實作方式: 適用於標準連線 (例如 USB、藍牙)。
- 具有可提供行動用的電源 (例如電池)。
- 螢幕尺寸大於 7 吋且小於 18 吋,是根據對角線測得的數值。
平板電腦裝置實作時的需求條件與手持裝置類似 。該節中會以 * 表示例外。 並在本節中註記,以備參考
2.6.1.硬體
陀螺儀
如果平板電腦裝置導入方式包含 3 軸式迴轉儀,代碼會:
- [7.3.4/Tab-1-1] 必須能夠評估方向 每秒最多可變更 1000 度
記憶體與儲存空間下限 (第 7.6.1 節)
手持小型/一般螢幕的螢幕密度 則不適用平板電腦。
USB 週邊裝置模式 (第 7.7.1 節)
如果平板電腦裝置實作包含支援週邊裝置的 USB 連接埠 模式,就會:
- [7.7.1/Tab] 可能實作 Android Open Accessory (AOA) API。
虛擬實境模式 (第 7.9.1 節)
虛擬實境高效能 (第 7.9.2 節)
虛擬實境要求不適用於平板電腦。
2.6.2.安全性模型
金鑰和憑證 (第 9.11 節)
請參閱 [9.11] 一節。
如果平板電腦裝置的實作方式包含多位使用者
未宣告 android.hardware.telephony
功能旗標,則會:
- [9.5/T-1-1] 必須支援設有限制的個人資料。 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後,裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。
如果平板電腦裝置的實作方式包含多位使用者
宣告 android.hardware.telephony
功能旗標後:
- [9.5/T-2-1] 不支援受限制功能 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。
2.6.2.軟體
3. 軟體
3.1. 代管 API 相容性
代管的 Dalvik 位元碼執行環境是 Android 應用程式。Android 應用程式設計介面 (API) Android 平台中運作的應用程式 管理執行階段環境
裝置實作方式:
[C-0-1] 必須提供完整導入程序,包括所有明確文件 所有由 Android SDK 公開的已記錄 API 行為 或任何上游 Android 中以「@SystemApi」標記裝飾的 API Cloud Build 觸發條件 會在您變更原始碼時自動啟動建構作業
[C-0-2] 必須支援/保留所有類別、方法和相關元素 由 TestApi 註解 (@TestApi) 標記
[C-0-3] 不得省略任何受管理的 API 或更改 API 介面或簽名; 偏離記錄行為,或屬於免人工管理,除非 這項相容性定義特別允許。
[C-0-4] 「必須」保持 API 正常運作且運作 即使是 Android 應用程式的某些硬體功能 包含 API 的部分請參閱第 7 節 瞭解有哪些特殊需求
[C-0-5] 不得允許第三方應用程式使用非 SDK 介面。 都定義為 Java 語言套件中的方法和欄位 加入 Android 開放原始碼計畫的啟動類別路徑,且該路徑未構成公開資料 將機器學習工作流程自動化這包含以
@hide
註解裝飾,但不含有@SystemAPI
(如 SDK 文件中所述) 以及私人和非公開課程成員[C-0-6] 每個非 SDK 介面都必須以相同的受限介面提供 透過臨時和拒絕清單旗標提供的清單
prebuilts/runtime/appcompat/hiddenapi-flags.csv
有關 Android 開放原始碼計畫中適當 API 級別分支版本的路徑。[C-0-7] 必須支援已簽署的設定 動態更新機制:從受限制的清單中移除非 SDK 介面 使用現有的公開金鑰,將已簽署的設定嵌入任何 APK 。
但請注意下列事項:
- 如果裝置上沒有隱藏的 API,或是該 API 在裝置上的實作方式不同,可能會發生這種情況 將隱藏的 API 移至拒絕清單,或從拒絕清單省略該 API 。
- 如果 Android 開放原始碼計畫中沒有隱藏的 API,請新增隱藏的 API 傳送至任何受限清單
3.1.1. Android 擴充功能
Android 支援透過以下項目擴充特定 API 級別的代管 API 介面:
更新該 API 級別的擴充功能版本
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
API 會傳回
提供的 apiLevel
擴充功能版本 (如有適用的擴充功能)
API 級別。
Android 裝置實作:
[C-0-1] 「必須」預先載入兩個共用程式庫的 Android 開放原始碼計畫實作項目
ExtShared
和服務ExtServices
,且版本大於或等於 每個 API 級別允許的最低版本例如 Android 7.0 搭載 API 級別 24 的裝置實作至少必須包含 第 1 版。[C-0-2] 「必須」只傳回已經 是由 Android 開放原始碼計畫定義的定義。
[C-0-3] 必須支援擴充功能版本定義的所有 API
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
已退回 方法與支援其他代管 API 的方法相同, 滿足第 3.1 節的要求。
3.1.2. Android 程式庫
由於 Apache HTTP 用戶端已淘汰, 裝置實作:
- [C-0-1] 不得將
org.apache.http.legacy
程式庫放在 「Bootclasspath」 - [C-0-2] 「必須」將
org.apache.http.legacy
程式庫新增至應用程式 應用程式必須符合下列任一條件時,系統才會執行類別路徑:- 目標 API 級別為 28 以下。
- 在資訊清單中設定要使用的程式庫,以宣告需要該程式庫
<uses-library>
的android:name
屬性設為org.apache.http.legacy
。
Android 開放原始碼計畫實作項目符合這些規定。
3.2. 軟 API 相容性
除了第 3.1 節列出的代管 API 之外, Android 也包含一個重要的執行階段專屬「soft」 API,如下所示: 例如 Android 應用程式的意圖、權限等等 無法在應用程式編譯時強制執行。
3.2.1. 權限
3.2.2。版本參數
Android API 在 android.os.Build 類別 用來描述目前的裝置
- [C-0-1] 跨裝置提供一致且有意義的值 請參閱下表,其中列出各廣告格式的額外限制 才能符合所需的裝置導入方式。
參數 | 詳細說明 |
---|---|
版本 | 目前執行 Android 系統的版本,可透過人類可讀的格式 格式。這個欄位「必須」含有 適用於 Android 13 的許可版本字串。 |
SDK 版本 | 目前執行 Android 系統的版本,格式為 第三方應用程式程式碼存取。針對 Android 13, 這個欄位「必須」包含整數值 13_INT。 |
VERSION.SDK_INT | 目前執行 Android 系統的版本,格式為 第三方應用程式程式碼存取。針對 Android 13, 這個欄位「必須」包含整數值 13_INT。 |
版本 | 指定特定版本的裝置實作者選擇的值 而且是使用人類可讀的格式。這個 提供給使用者的不同版本「不得」重複使用。A 罩杯 這個欄位通常會用於指出 原始碼控制變更 ID 用於產生建構作業這個鍵 都必須能以可列印的 7 位元 ASCII 格式編碼,且符合 規則運算式「^[^ :\/~]+$」。 |
桌遊 | 裝置實作者選擇的值,用來識別 裝置所用的內部硬體,採人類可讀的格式。可能 此欄位的用途是指出電路板電源的特定修訂版本 裝置。這個欄位的值必須能以 7 位元 ASCII 字元和 符合規則運算式「^[a-zA-Z0-9_-]+$」。 |
品牌 | 這個值代表與裝置相關聯的品牌名稱 使用者格式必須清晰可讀,且須為 裝置的製造商或裝置所屬的公司品牌 上市。這個欄位的值必須能以 7 位元 ASCII 格式編碼,且相符 規則運算式「^[a-zA-Z0-9_-]+$」。 |
支援濫用 | 原生指令集的名稱 (CPU 類型 + ABI 慣例) 再也不是件繁重乏味的工作請參閱第 3.3 節。本機 API 相容性。 |
支援 32_BIT_ABIS | 原生指令集的名稱 (CPU 類型 + ABI 慣例) 再也不是件繁重乏味的工作請參閱第 3.3 節。本機 API 相容性。 |
支援 64_BIT_ABIS | 第二個指令集的名稱 (CPU 類型 + ABI 慣例) 原生程式碼請參閱第 3.3 節。原生廣告 API 相容性。 |
CPU_ABI | 原生指令集的名稱 (CPU 類型 + ABI 慣例) 再也不是件繁重乏味的工作請參閱第 3.3 節。本機 API 相容性。 |
CPU_ABI2 | 第二個指令集的名稱 (CPU 類型 + ABI 慣例) 原生程式碼請參閱第 3.3 節。原生廣告 API 相容性。 |
裝置 | 由裝置實作者選擇的值,包含開發名稱 或是程式碼名稱,指出硬體功能和設定 裝置的工業設計這個欄位的值必須可供編碼 並以 7 位元 ASCII 格式比對規則運算式 「^[a-zA-Z0-9_-]+$」。在此期間,此裝置名稱「不得」變更 都會使用產品的生命週期 |
指紋 | 專門用於識別此版本的字串。請合理
人類可讀的格式請務必遵循以下範本:
$(品牌)/$(PRODUCT)/ 例如: acme/myproduct/ 指紋「不得」包含空白字元。如果 這個欄位必須能編碼成 7 位元 ASCII。 |
硬體 | 硬體的名稱 (從核心指令列或 /proc)。這項服務 產品必須合理人類可讀。這個欄位的值必須 能以 7 位元 ASCII 編碼,且符合規則運算式 「^[a-zA-Z0-9_-]+$」。 |
主機 | 可明確識別建立版本所在主機的字串。 人類可讀的格式對 Pod 來說, 但這個欄位「不得」為空值或空字串 (")。 |
ID | 裝置實作者選擇的 ID,用來參照特定 版本。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL,但必須是充分的價值 以便使用者區分不同軟體版本這個鍵 都必須能以 7 位元 ASCII 格式編碼,且符合 運算式「^[a-zA-Z0-9._-]+$」。 |
製造商 | 產品。這個欄位的特定格式沒有任何規定。 ,但不得為空值或空字串 (")。這個欄位 在產品效期內不得變更。 |
SOC_MANUFACTURER | 主要系統的製造商名稱 晶片 (SOC)。SOC 製造商裝置相同的裝置 應該使用相同的常數值。請洽詢 SOC 製造商 要使用的正確常數這個欄位的值必須可供編碼 做為 7 位元 ASCII,「必須」符合 「^([0-9A-Za-z ]+)」的開頭或結尾不得為空白字元。 而且不一定要等於「未知」在 都會使用產品的生命週期 |
SOC_MODEL | 晶片中主要系統 (SOC) 的模型名稱; 搭載相同 SOC 模型的裝置應使用相同的常數 值。請洽詢 SOC 製造商以取得要使用的正確常數。 這個欄位的值必須能以 7 位元 ASCII 格式編碼,且與 規則運算式 “^([0-9A-Za-z ._/+-]+)$”,「不得」開頭或 結尾為空白,而且不得等於「未知」。這個欄位 在產品效期內不得變更。 |
MODEL | 由裝置實作者選擇的值,其中包含 系統判斷每個裝置的位置這個名稱與 使用者行銷和銷售裝置。我們並未針對 特定格式,但不得為空值或 空字串 ("")。在 都會使用產品的生命週期 |
產品 | 由裝置實作者選擇的值,包含開發名稱 每個產品 (SKU) 的代碼名稱,都必須在 同一個品牌必須是人類可讀的內容,但不一定能用來觀看 直接回應使用者的需求這個欄位的值必須能以 7 位元 ASCII 字元和 符合規則運算式「^[a-zA-Z0-9_-]+$」。這項產品 在產品生命週期內,名稱不得變更。 |
ODM_SKU | 由裝置實作者選擇的選用值,其中包含
SKU (存貨單位) 用於追蹤
例如裝置隨附的任何週邊裝置。
這個欄位的值必須能以 7 位元 ASCII 格式編碼,且與
規則運算式 ^([0-9A-Za-z.,_-]+)$ 。 |
序號 | 必須傳回「UNKNOWN」。 |
標記 | 裝置實作者選擇的標記清單 (以半形逗號分隔) 以便進一步區分版本標記必須能以 7 位元 ASCII 格式編碼 且符合規則運算式「^[a-zA-Z0-9._-]+」和「必須」 提供與三個一般 Android 平台相對應的其中一個值 簽署設定:release-keys、dev-keys 和測試金鑰。 |
時間 | 代表建構發生時間的時間戳記的值。 |
類型 | 裝置實作者選擇的值,用於指定執行階段 建構作業的佈建方式這個欄位必須包含其中一個值 對應至三種典型 Android 執行階段設定:使用者 userdebug 或 eng. |
使用者 | 產生這類內容的使用者 (或自動使用者) 名稱或使用者 ID 建構應用程式這個欄位的特定格式沒有任何規定。 ,但不得為空值或空字串 (")。 |
安全快門 | 表示版本安全性修補程式等級的值。必須代表 這個版本並未造成任何容易遭受上述問題影響 完成指定的 Android 公開安全性公告一定要讓 格式為 [YYYY-MM-DD],與 Android 公開安全性公告 或 Android 安全性補充公告,例如「2015-11-01」。 |
BASE_OS | 一個值,代表建構中 FINGERPRINT 參數的值, 與此版本完全相同,但不包含在 Android 公開安全性公告。必須回報正確的值,並指出 這類版本不存在,請回報空字串 ("")。 |
新手上路 | 裝置實作者選擇的值,用來識別 裝置使用的內部系統啟動載入程式版本,採用人類可讀的格式。 這個欄位的值必須能以 7 位元 ASCII 格式編碼,且與 規則運算式「^[a-zA-Z0-9._-]+$」。 |
getRadioVersion() | 必須 (等於或傳回) 裝置實作者選擇的值 識別裝置中使用的特定內部無線電/模組版本 格式。如果裝置沒有內部任何內部 IP 位址 無線電/模組必須傳回 NULL。這個欄位的值必須 能以 7 位元 ASCII 編碼,且符合規則運算式 「^[a-zA-Z0-9._-,]+$」。 |
getSerial() | 必須 (已準備好或退回) 提供使用的硬體序號 而且在相同的型號和製造商的裝置中均不重複。如果 這個欄位必須能編碼成 7 位元 ASCII,且符合規則運算式 「^[a-zA-Z0-9]+$」。 |
3.2.3.意圖相容性
3.2.3.1。常見的應用程式意圖
Android 意圖允許應用程式元件 其他 Android 元件Android 上游專案會列出 實作多個意圖模式以執行常用動作的應用程式。
裝置實作方式:
- [C-SR-1] 強烈建議預先載入一或多個應用程式,或是 針對所有公開意圖篩選器,使用包含意圖處理常式的服務元件 此處所列的應用程式意圖定義的模式 並給予執行要求,即符合開發人員對這些常見的要求 應用程式意圖。
如要瞭解必要的應用程式意圖,請參閱第 2 節。 每種裝置類型
3.2.3.2。意圖解決方案
[C-0-1] 由於 Android 是可擴充平台,因此裝置導入方式「必須」 允許第 3.2.3.1 節所參照的每個意圖模式。 ,但「設定」除外。 上游 Android 開放原始碼實作允許此做法。
[C-0-2] 裝置實作者「不得」將特殊權限附加至系統 應用程式使用這些意圖模式,或防範第三方應用程式 由繫結至及假設這些模式的控制。這項禁令 包括但不限於停用「選擇工具」使用者 介面,可讓使用者選取多個應用程式 處理相同的意圖模式
[C-0-3] 裝置實作「必須」提供使用者介面,以便使用者 可修改意圖的預設活動。
不過,裝置導入方式可能會提供 預設活動提供 更具體地說明資料 URI 屬性例如意圖篩選器模式 指定資料 URI「http://www.android.com」會比 瀏覽器的核心意圖模式 (適用於「http://」)
Android 也內建可供第三方應用程式宣告的機制 官方預設的應用程式連結行為 特定類型的網路 URI 意圖如果系統提供這類權威聲明 所定義的應用程式意圖篩選器模式、裝置實作方式:
- [C-0-4] 「必須」嘗試執行 Digital Asset Links 規格定義的驗證步驟 如上游 Android 開放原始碼的套件管理員實作即可 專案。
- [C-0-5] 安裝 應用程式,並將所有已成功驗證的 URI 意圖篩選器設為 為其 URI 的預設應用程式處理常式。
- 可以將特定 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。 表示驗證成功,但其他候選 URI 篩選器失敗 驗證。如果裝置導入方式這樣做,就「必須」提供 設定選單內的個別 URI 格式覆寫值。
- 「設定」中「必須」為使用者提供個別應用程式連結控制項,例如:
如下:
- [C-0-6] 使用者「必須」能完全覆寫預設應用程式 應用程式的連結行為:一律開啟、一律詢問或永不開啟 這些要求必須同樣套用至所有候選 URI 意圖篩選器。
- [C-0-7] 使用者「必須」可以查看候選 URI 意圖清單 篩選器。
- 裝置實作「可能」能讓使用者執行下列操作: 覆寫已成功覆寫的特定候選 URI 意圖篩選器 並按個別意圖篩選器加以驗證
- [C-0-8] 裝置實作「必須」讓使用者能夠 查看及覆寫特定候選 URI 意圖篩選器 (如有) 實作能讓某些候選 URI 意圖篩選器成功 但部分驗證失敗
3.2.3.3.意圖命名空間
- [C-0-1] 裝置實作「不得」包含 遵循任何使用 ACTION、CATEGORY 或 則位於 android.* 或 com.android.* 命名空間中。
- [C-0-2] 裝置實作者「不得」包含 使用 ACTION、CATEGORY 或 其他金鑰字串。
- [C-0-3] 裝置實作者不得變更或擴充任何意圖 第 3.2.3.1 節所列的模式。
- 裝置實作項目可能包含清楚使用命名空間的意圖模式 而且明顯與自家機構相關聯這項禁令為 類似於第 3.6 節中 Java 語言類別指定的。
3.2.3.4。廣播意圖
第三方應用程式仰賴這個平台,將特定意圖廣播至 並在硬體或軟體環境變更時發出通知。
裝置實作方式:
- [C-0-1] 必須播送此處所列的公開廣播意圖 回應 SDK 文件中所述的適當系統事件。 請注意,這項規定與第 3.5 節並未衝突, SDK 中也會描述背景應用程式的限制 說明文件。此外,特定廣播意圖在硬體上是有條件的 支援;前提是裝置必須支援必要的硬體,其「必須」能夠播送 意圖,並在 SDK 說明文件中提供內嵌行為。
3.2.3.5。條件式應用程式意圖
Android 提供的設定可讓使用者輕鬆選取 預設應用程式,例如主畫面或簡訊
而且,裝置導入作業「必須」提供類似的設定 ,並與前述意圖篩選器模式和 API 方法相容 。
如果裝置導入作業回報 android.software.home_screen
,就會:
- [C-1-1] 必須尊重
android.settings.HOME_SETTINGS
意圖顯示主畫面的預設應用程式設定選單。
如果裝置實作回報 android.hardware.telephony.calling,就會發生以下情形:
[C-2-1] 必須提供設定選單,讓系統能呼叫
android.provider.Telephony.ACTION_CHANGE_DEFAULT
敬上 意圖,顯示變更預設簡訊應用程式的對話方塊。[C-2-2] 必須尊重
android.telecom.action.CHANGE_DEFAULT_DIALER
目的,是要顯示對話方塊,讓使用者變更預設電話。 應用程式。- 「務必」使用使用者選取的預設「電話」應用程式 UI 存取傳入/輸入訊息, 接聽及撥打緊急電話。 。
[C-2-3] 必須尊重 android.telecom.action.CHANGE_PHONE_ACCOUNTS 提供意圖讓使用者負擔設定
ConnectionServices
的意圖 與PhoneAccounts
相關聯的,如 以及通訊服務提供端預設 PhoneAccount 撥出電話。Android 開放原始碼計畫實作方式符合這項規定, 包括「通話帳戶」選項「通話」選單設定選單。[C-2-4] 必須允許
android.telecom.CallRedirectionService
表示包含android.app.role.CALL_REDIRECTION
的應用程式 角色。[C-2-5] 必須為使用者提供負擔,才能選擇含有
android.app.role.CALL_REDIRECTION
敬上 角色。[C-2-6] 必須尊重 android.intent.action.SENDTO 和 android.intent.action.VIEW 意圖並提供活動以傳送/顯示簡訊。
[C-SR-1] 強烈推薦 android.intent.action.ANSWER。 android.intent.action.CALL、 android.intent.action.CALL_BUTTON、 android.intent.action.VIEW &android.intent.action.DIAL 針對預載的撥號應用程式處理意圖和呼叫 按照 SDK 中的說明提供執行要求。
如果裝置導入作業回報 android.hardware.nfc.hce
,就會:
- [C-3-1] 必須遵循 android.settings.NFC_PAYMENT_SETTINGS 意圖顯示「感應式付款」的預設應用程式設定選單。
- [C-3-2] 必須遵循 android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT 「目的」顯示一個活動,用於開啟對話方塊並要求使用者變更 特定類別的預設卡片模擬服務 (如 SDK 中所述)。
如果裝置導入作業回報 android.hardware.nfc
,就會:
- [C-4-1] 必須遵循這些意圖 android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED &android.nfc.action.TECH_DISCOVERED, ,顯示能滿足開發人員對這些意圖的期望 所說明的資訊。
如果裝置導入作業回報 android.hardware.bluetooth
,就會:
- [C-5-1] 必須尊重「android.bluetooth.adapter.action.REQUEST_ENABLE」 意圖並顯示系統活動,讓使用者開啟藍牙功能。
- [C-5-2] 必須尊重 「android.bluetooth.adapter.action.REQUEST_DISCOVERABLE」 意圖,並顯示要求可探索模式的系統活動。
如果裝置實作支援 DND 功能,就會:
- [C-6-1] 必須實作會回應意圖的活動
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
、 使用 UI_MODE_TYPE_NORMAL 進行實作時,必須是 使用者可以授予或拒絕應用程式 DND 政策設定的存取權。
如果裝置實作方式允許使用者在 這些裝置,他們可以:
- [C-7-1] 必須為使用者提供可存取的機制,以便新增及設定
來回應
android.settings.INPUT_METHOD_SETTINGS
敬上 意圖。
如果裝置實作項目支援第三方無障礙服務,就會:
- [C-8-1] 必須尊重
android.settings.ACCESSIBILITY_SETTINGS
目的在於提供使用者可存取的機制,以啟用及停用 第三方無障礙服務及預先載入的無障礙功能 免費 Google Cloud 服務
如果裝置實作提供 Wi-Fi 輕鬆連線支援,並公開 目的是:
- [C-9-1] 必須導入 Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI SDK 說明文件中所述的 Intent API。
如果裝置實作項目提供數據節省模式,就會:
- [C-10-1] 「必須」在設定中提供用來處理
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
敬上 意圖,允許使用者在清單中 允許或封鎖允許清單
如果裝置實作項目未提供數據節省模式,就會發生以下情形:
- [C-11-1] 必須包含能處理
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
敬上 但也可以當做免人工管理來導入
如果裝置實作方式宣告支援相機
android.hardware.camera.any
,他們:
- [C-12-3] 必須能處理,且「必須」只允許預先安裝的 Android 應用程式
處理下列意圖
MediaStore.ACTION_IMAGE_CAPTURE
、MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, 和MediaStore.ACTION_VIDEO_CAPTURE
,詳情請參閱 SDK 文件中所列。
如果裝置導入作業回報 android.software.device_admin
,就會:
[C-13-1] 必須遵循意圖
android.app.action.ADD_DEVICE_ADMIN
叫用 UI,透過新增裝置管理員的方式將使用者導向到 或是允許他們拒絕系統[C-13-2] 必須尊重意圖 android.app.action.PROVISION_MANAGED_PROFILE、 android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD、 android.app.action.SET_NEW_PASSWORD &android.app.action.START_ENCRYPTION 並且具備為這些意圖提供執行要求的活動 (如上所述) 請參閱這裡的 SDK 使用說明。
如果裝置導入方式宣告 android.software.autofill
就會:
- [C-14-1] 必須完全導入
AutofillService
和AutofillManager
API 並遵循 android.settings.REQUEST_SET_AUTOFILL_SERVICE 顯示預設應用程式設定選單,藉此啟用及停用自動填入功能 變更使用者的預設自動填入服務。
如果裝置的實作項目包含預先安裝的應用程式,或您希望 第三方應用程式來存取使用統計資料:
- [C-SR-2] 強烈建議提供使用者可存取的機制
或撤銷針對
android.settings.ACTION_USAGE_ACCESS_SETTINGS
宣告
android.permission.PACKAGE_USAGE_STATS
的應用程式 權限。
如果裝置的實作方式打算禁止任何應用程式 (包括預先安裝的應用程式) 應用程式存取使用統計資料時,必須:
- [C-15-1] 仍必須包含能處理 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖模式,但「必須」實作為免人工管理,且具有同等 顯示使用者拒絕授予存取權時的行為
如果裝置導入方式顯示 AutofillService_passwordsActivity 在「設定」中,或透過類似的機制連結至使用者密碼:
[C-16-1] 必須針對所有已安裝的自動填入服務顯示這類連結。
[C-17-1] [已移至 2.2.3]
如果裝置實作項目支援 VoiceInteractionService
且
逐一安裝這個 API 的應用程式時,他們會:
- [C-18-1] 必須尊重
android.settings.ACTION_VOICE_INPUT_SETTINGS
意圖,顯示語音輸入和小幫手的預設應用程式設定選單。
如果裝置實作結果回報 android.hardware.audio.output
功能,
他們會:
- [C-SR-3] 極力建議遵循 android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA 和 android.speech.tts.engine.GET_SAMPLE_TEXT 意圖有一個活動可提供 執行這些意圖的執行要求,如 SDK 這裡所述。
Android 支援互動式螢幕保護程式 (先前稱為 像是 Dreams螢幕保護程式可讓使用者在裝置中與應用程式互動 已接上電源或座架在桌面座架上。 裝置實作方式:
- 應加入螢幕保護程式支援,並為
使用者設定螢幕保護程式來回應
android.settings.DREAM_SETTINGS
意圖。
3.2.4。次要/多螢幕上的活動
如果裝置導入方式允許,啟動正常 Android 活動, 一個螢幕,只能:
- [C-1-1] 必須設定
android.software.activities_on_secondary_displays
功能旗標 - [C-1-2] 保證與執行於 主螢幕。
- [C-1-3] 新活動顯示的螢幕必須與
就會啟動新活動時未指定目標
透過
ActivityOptions.setLaunchDisplayId()
顯示 也能使用 Google Cloud CLI 或 Compute Engine API - [C-1-4] 顯示具有
Display.FLAG_PRIVATE
敬上 標記就會移除 - [C-1-5] 必須在裝置鎖定時安全地隱藏所有螢幕上的內容
顯示安全螢幕鎖定。除非應用程式選擇顯示在鎖定頂端
使用
Activity#setShowWhenLocked()
的畫面 也能使用 Google Cloud CLI 或 Compute Engine API - 應具備
android.content.res.Configuration
以及用來顯示、 並保持相容性 次要螢幕。
如果裝置實作方式允許在次要上啟動一般 Android 活動 螢幕和次要螢幕具有 android.view.Display.FLAG_PRIVATE 旗標:
- [C-3-1] 只有該螢幕、系統和活動的擁有者 畫面上必須能啟動該螢幕所有人都能在 具有 android.view.Display.FLAG_PUBLIC 的螢幕 旗標。
3.3.原生 API 相容性
原生程式碼相容性不高。因此 裝置實作項目如下:
- [C-SR-1] 強烈建議使用程式庫的實作方式 下列字串。
3.3.1.應用程式二進位檔介面
代管的 Dalvik 位元碼可以呼叫應用程式提供的原生程式碼
.apk
檔案為針對適當裝置硬體編譯的 ELF .so
檔案
這個架構的簡短總覽原生程式碼高度依賴基礎處理器
Android 定義了多種應用程式二進位檔介面 (ABI),
Android NDK。
裝置實作方式:
- [C-0-1] 必須與一或多個定義的 Android NDK ABI 相容。
- [C-0-2] 必須支援在代管環境中執行的程式碼, 透過標準 Java Native Interface (JNI) 呼叫原生程式碼 語意
- [C-0-3] 必須能夠與原始碼相容 (即與標頭相容) 和 與清單中的每個必要程式庫相容 (適用於 ABI) 。
- [C-0-5] 必須正確回報原生應用程式二進位檔介面
裝置透過
android.os.Build.SUPPORTED_ABIS
支援的 (ABI),android.os.Build.SUPPORTED_32_BIT_ABIS
和android.os.Build.SUPPORTED_64_BIT_ABIS
參數 (以半形逗號分隔) 將 ABI 從最多到最低的順序排列。 [C-0-6] 請務必透過上述參數回報下列部分參數 且「不得」回報不在清單上的 ABI。
armeabi
(NDK 不再支援做為目標)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] 必須製作下列所有提供原生 API 的程式庫 包含原生程式碼的應用程式:
- libaaudio.so (支援 AAudio 原生音訊)
- libamidi.so (原生 MIDI,如功能
android.software.midi
) 聲明的權利,如第 5.9 節所述)。 - libandroid.so (原生 Android 活動支援)
- libc (C 程式庫)
- libcamera2ndk.so
- libdl (動態連結器)
- libEGL.so (原生 OpenGL 介面管理)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- Libicuuc.so
- libjnigraphics.so
- liblog (Android 記錄)
- libmediandk.so (支援原生媒體 API)
- libm (數學資料庫)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (OpenMAX AL 1.0.1 支援)
- libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
- libRS.so
- libstdc++ (最低支援 C++)
- libvulkan.so (Vulkan)
- libz (Zlib 壓縮)
- JNI 介面
[C-0-8] 不得新增或移除原生資料庫的公用函式 。
[C-0-9] 必須列出直接公開給其他非 Android 開放原始碼計畫的程式庫 「
/vendor/etc/public.libraries.txt
」中的第三方應用程式。[C-0-10] 不得揭露其他任何原生資料庫, 在 Android 開放原始碼計畫中,以系統程式庫的形式提供,向指定 API 的第三方應用程式提供 級別 24 以上,系統將保留此廣告。
[C-0-11] 必須匯出所有 OpenGL ES 3.1 和 Android 擴充功能套件 透過
libGLESv3.so
程式庫取得 NDK 中定義的函式符號。 請注意,雖然所有符號都必須提供,但第 7.1.4.1 節說明瞭 將詳細說明每個檔案完整導入的 提供相對應的函式[C-0-12] 必須匯出核心 Vulkan 1.0 函式的函式符號 以及
VK_KHR_surface
、VK_KHR_android_surface
VK_KHR_swapchain
、VK_KHR_maintenance1
和VK_KHR_get_physical_device_properties2
擴充功能透過libvulkan.so
程式庫。請注意,雖然所有符號「必須」 第 7.1.4.2 節將進一步說明, 各對應函式應採用的實作方式。請務必使用 上游 Android 開放原始碼計畫
請注意,日後推出的 Android 版本可能會支援額外的功能 ABI。
3.3.2.32 位元 ARM 原生程式碼相容性
如果裝置實作回報支援 armeabi
ABI,就會:
- [C-3-1] 也必須支援
armeabi-v7a
並向我們回報相關支援,armeabi
僅適用於舊版應用程式的回溯相容性。
如果裝置實作回報對應用程式的支援 armeabi-v7a
ABI
並使用這個 ABI 進行下列操作:
[C-2-1] 必須在
/proc/cpuinfo
中加入下列幾行,且不得 會修改同一個裝置上的值,即使其他 ABI 讀取這些值也是如此。Features:
,後面加上任何選用的 ARMv7 CPU 功能清單 支援的瀏覽器。CPU architecture:
,後面加上用來說明裝置的整數 最高支援 ARM 架構 (例如「8」適用於 ARMv8 裝置)。
[C-2-2] 必須一律保留下列作業,即使 在 ARMv8 架構上實作 ABI 的情況, 原生 CPU 支援或透過軟體模擬:
- SWP 和 SWPB 指示。
- CP15ISB、CP15DSB 和 CP15DMB 障礙行動。
[C-2-3] 必須支援進階 SIMD (又稱為 NEON) 副檔名。
3.4.網路相容性
3.4.1.WebView 相容性
如果裝置實作提供完整的
android.webkit.Webview
API,則具有以下權限:
- [C-1-1] 必須回報
android.software.webview
。 - [C-1-2] 必須使用 Chromium 專案版本
。
13 個分支用於實作
android.webkit.WebView
也能使用 Google Cloud CLI 或 Compute Engine API [C-1-3] WebView 回報的使用者代理程式字串必須使用以下格式:
Mozilla/5.0 (Linux;Android $(VERSION);[$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML,例如 Gecko) 版本/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE。
- $(MODEL) 字串「可能」為空白,但如果並非空白,則「必須」 這個值與 android.os.Build.MODEL 相同。
- 「Build/$(BUILD)」如果有 $(BUILD) 一起,可以省略 字串必須與 android.os.Build.ID 的值相同。
- $(CHROMIUM_VER) 字串的值「必須」是 Chromium 版本 。
- 裝置導入方式可以在使用者代理程式字串中省略行動裝置。
WebView 元件「必須」支援所有 HTML5 功能, 並支援此功能,且務必符合 HTML5 規格。
[C-1-4] 「必須」在程序中轉譯提供的內容或遠端網址內容 與執行個體化 WebView 的應用程式不同詳細說明 獨立的轉譯器程序「必須」保有較低權限 做為獨立使用者 ID,則無法存取應用程式的資料目錄。 沒有直接網路存取權,只能存取必要權限 提供名為「Binder」的映像檔WebView 的 Android 開放原始碼計畫實作符合 這項規定。
請注意,如果裝置實作項目為 32 位元,或已宣告功能標記
android.hardware.ram.low
,不受 C-1-3 的約束。
3.4.2。瀏覽器相容性
如果裝置實作項目包含適用於一般用途的獨立瀏覽器應用程式 就會遇到以下問題:
- [C-1-1] 必須針對下列 HTML5:
- [C-1-2] 必須支援 HTML5/W3C webstorage API,且必須支援 HTML5/W3C IndexedDB API:請注意,因為網頁版 目前正逐漸改用 IndexedDB webstorage, IndexedDB 預計將成為 未來的 Android 版本
- 可以在獨立的瀏覽器應用程式中提供自訂的使用者代理程式字串。
- 應盡可能為 HTML5 (獨立) 瀏覽器應用程式 (無論是以上游 WebKit 瀏覽器為基礎) 或第三方的替代品)。
如果裝置實作項目不包含獨立瀏覽器 這兩個版本:
- [C-2-1] 仍必須支援如 第 3.2.3.1 節。
3.5.API 行為相容性
裝置實作方式:
- [C-0-9] 必須確保 API 行為相容性適用於所有 已安裝的應用程式,除非應用程式受到 第 3.5.1 節。
- [C-0-10] 「不得」導入許可清單方法,以確保 API 行為相容性僅適用於裝置選取的應用程式 實作器。
每種 API 類型 (代管、軟、原生和網頁) 的行為都必須 與向上游的偏好實作一致 Android 開放原始碼計畫。一些特定區域 相容性為:
- [C-0-1] 裝置不得變更 標準意圖
- [C-0-2] 裝置不得變更 特定類型的系統元件 (例如 Service、Activity、ContentProvider 等)。
- [C-0-3] 裝置「不得」變更標準權限的語意。
- 裝置「不得」變更背景應用程式強制執行的限制。
具體來說,背景應用程式:
- [C-0-4] 這些伺服器必須停止執行由
接收
GnssMeasurement
的輸出內容 和GnssNavigationMessage
。 - [C-0-5] 這些 Pod 必須使用頻率限制
透過
LocationManager
提供給應用程式 API 類別或WifiManager.startScan()
方法。 - [C-0-6] 如果應用程式指定的 API 級別為 25 以上,就「不得」
允許針對的隱式廣播訊息註冊廣播接收器
應用程式資訊清單中的標準 Android 意圖 (除非廣播
意圖需要
"signature"
或"signatureOrSystem"
protectionLevel
或是列於豁免清單中。 - [C-0-7] 如果應用程式指定的 API 級別為 25 以上,就必須停止執行
應用程式背景服務的方式,就像應用程式呼叫了
服務
stopSelf()
方法,除非應用程式加入臨時許可清單來處理 向使用者顯示的工作 - [C-0-8] 如果應用程式指定的 API 級別為 25 以上,就必須 放開應用程式保留的 Wake Lock。
- [C-0-4] 這些伺服器必須停止執行由
接收
- [C-0-11] 裝置「必須」將下列安全性服務供應商歸還至
Security.getProviders()
中的七個陣列值 方法,按指定順序並帶有指定名稱 (與Provider.getName()
) 和類別,除非應用程式透過insertProviderAt()
或removeProvider()
。裝置數 可在指定提供者清單後傳回其他提供者 。- AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL:
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider -
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- 英屬哥倫比亞 -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP -
上方清單僅列舉部分例子,並未包含所有可能情況。Compatibility Test Suite (CTS) 測試 平台上的幾個部分都能確保行為相容性,但並非全部。 實作者必須負責確保行為相容性 Android 開放原始碼計畫因此 應使用 Android 開放原始碼計畫中取得的原始碼, 而不是重新導入系統的重要部分
3.5.1。應用程式限制
如果裝置實作項目採用專屬機制來限制應用程式 (例如變更或限制即將執行的 API 行為) 所載) 和 也就是比受限應用程式待命值區更加嚴格的機制:
- [C-1-1] 必須允許使用者查看受限制的應用程式清單。
- [C-1-2] 必須提供使用者權限,才能開啟或關閉所有功能 專屬限制
[C-1-3] 在沒有要求的情況下,不得自動套用這些專屬限制 可能存在不良系統健康行為的證據,但可能對應用程式實施了限制 在偵測到不良系統健康行為 (例如 Wake Lock 停滯或長時間跑步) 時 服務以及其他條件標準「可能」視裝置而定 但必須與應用程式對系統健康狀態的影響相關其他 與系統健康狀態無關的條件,例如應用程式的 缺乏市場熱門程度,「不得」當做條件。
[C-1-4] 「不得」為應用程式自動套用這些專屬限制 使用者手動關閉應用程式限制,且「可能」建議使用者 才能套用專屬限制
[C-1-5] 必須告知使用者,僅適用於這些專屬限制 應用程式就會自動調整「必須」於 24 小時內提供這類資訊 先確定這些專屬限制的應用範圍。
[C-1-6] 必須為 ActivityManager.isBackgroundRestricted() 傳回 true 方法。
[C-1-7] 不得限制應用程式明確使用的頂層前景應用程式 使用者。
[C-1-8] 每當有人讓應用程式 使用者開始明確使用應用程式,讓應用程式位於前景 應用程式。
[C-1-10] 必須提供公開且明確的文件或網站,藉此說明 專屬限制的適用情形這份文件或網站必須 可從 Android SDK 文件中連結,且必須包含:
- 專屬限制的觸發條件。
- 應用程式的限制和限制方式。
- 如何讓應用程式不受這類限制限制。
- 應用程式如何要求豁免專屬限制 都能夠讓使用者安裝的應用程式不受限制。
如果應用程式已預先安裝在裝置上,但應用程式從未明確使用該應用程式 使用者超過 30 天,[C-1-3] [C-1-5] 就符合豁免資格。
如果裝置實作方式會延長執行的應用程式限制 後,您會發現:
- [C-2-1]必須按照這份文件所述的導入作業進行。
3.5.2。應用程式休眠
如果裝置實作項目包括 Android 開放原始碼計畫或 Android 開放原始碼計畫中的應用程式休眠 會擴充 Android 開放原始碼計畫中的功能,因此會:
- [C-1-1] 必須符合第 3.5.1 節的所有規定,但 [C-1-6] 和 [C-1-3]。
- [C-1-2] 「必須」只在使用者遇到 。這個 極力建議將時間長度設為一個月以上。必須使用 (透過 UsageStats#getLastTimeVisible() 透過明確使用者互動定義) 會導致應用程式結束強制停止狀態的 API 或任何可能原因。 包括服務繫結、內容供應器繫結、明確廣播等 ,以便透過新的 API UsageStats#getLastTimeAnyComponentUsed() 追蹤。
- [C-1-3] 「必須」僅套用對所有裝置使用者造成影響的限制 有證據顯示,已有任一時間未使用該套件 讓應用程式從可以最快做出回應的位置 回應使用者要求極力建議將時間長度設為一個月以上。
- [C-1-4] 不得算繪應用程式無法回應活動意圖。 服務繫結、內容供應器要求或明確廣播訊息。
Android 開放原始碼計畫的應用程式休眠功能符合上述規定。
3.6.API 命名空間
Android 遵循 Java 定義的套件和類別命名空間慣例 程式設計語言為確保與第三方應用程式相容 裝置實作者「不得」對 以下套件命名空間:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
也就是說,他們會:
- [C-0-1] 不得修改 Android 平台上公開公開的 API 變更任何方法或類別簽名,或者移除類別或類別 只要使用來自這些領域的 小型資料集訓練即可
- [C-0-2] 不得加入任何公開的元素 (例如類別或 介面,或現有類別/介面的欄位或方法) 或「測試」 或「System API」至上述命名空間中的 API建立「對外公開」 元素」是任何未以「@hide」裝飾的結構標記為 所用的參數。
裝置實作者可能會修改 API 的基礎實作方式,但 進行此類修改:
- [C-0-3] 「不得」影響 任何公開的 API
- [C-0-4] 不得宣傳或向開發人員揭露。
不過,裝置實作者可能會新增標準 Android 以外的自訂 API 命名空間之外,但自訂 API:
- [C-0-5] 不得包含在他人所擁有或參照的命名空間
並根據貴機構的使命
價值觀和目標進行調整舉例來說,裝置實作者「不得」將 API 新增到
com.google.*
或類似的命名空間:只有 Google 能這麼做。同樣地 Google 「不得」將 API 新增到其他公司命名空間 - [C-0-6] 必須封裝在 Android 共用資料庫中,以便僅包含應用程式 明確使用這些內容 (透過 <uses-library> 機制) 則會受到這類 API 的記憶體用量增加影響
裝置實作者可能會新增原生語言 (NDK 以外) 的自訂 API 但自訂 API 除外:
- [C-1-1] 「不得」位於 NDK 程式庫或他人擁有的程式庫 機構也能按照 請按這裡。
如果裝置實作人員提議改進上述其中一個套件命名空間 (例如在現有 API 中新增實用的新功能,或 API),實作者應造訪 source.android.com 並開始做出變更 程式碼就會取代該程式碼。
請注意,上述限制符合標準的命名慣例 Java 程式設計語言中的 API;本節旨在 然後透過納入這個相容性的範圍 定義。
3.7.執行階段相容性
裝置實作方式:
[C-0-1] 必須支援完整的 Dalvik 執行檔 (DEX) 格式 以及 Dalvik 位元碼規格和語意。
[C-0-2] 必須設定 Dalvik 執行階段,才能分配記憶體 並依據上游 Android 平台指定的 下表。(詳情請參閱第 7.1.1 節)。 螢幕大小和螢幕密度定義)。
應使用 Android RunTime (ART), Dalvik 可執行格式實作,以及參考 實作套件管理系統
請注意,下方指定的記憶體值視為最小值, 裝置實作可能會為個別應用程式配置更多記憶體。
螢幕版面配置 | 螢幕密度 | 應用程式記憶體下限 |
---|---|---|
Android Watch | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | ||
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | 36MB | |
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 48MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 56MB | |
420 dpi (420dpi) | 64MB | |
480 dpi (xxhdpi) | 88MB | |
560 dpi (560dpi) | 112MB | |
640 dpi (xxxhdpi) | 154MB | |
小型/標準 | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | ||
160 dpi (mdpi) | ||
180 dpi (180dpi) | 48MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | ||
320 dpi (xhdpi) | 80MB | |
360 dpi (360dpi) | ||
400 dpi (400dpi) | 96MB | |
420 dpi (420dpi) | 112MB | |
480 dpi (xxhdpi) | 128MB | |
560 dpi (560dpi) | 192MB | |
640 dpi (xxxhdpi) | 256MB | |
大 | 120 dpi (ldpi) | 32MB |
140 dpi (140dpi) | 48MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 80MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 96MB | |
320 dpi (xhdpi) | 128MB | |
360 dpi (360dpi) | 160MB | |
400 dpi (400dpi) | 192MB | |
420 dpi (420dpi) | 228MB | |
480 dpi (xxhdpi) | 256MB | |
560 dpi (560dpi) | 384MB | |
640 dpi (xxxhdpi) | 512MB | |
特大 | 120 dpi (ldpi) | 48MB |
140 dpi (140dpi) | 80MB | |
160 dpi (mdpi) | ||
180 dpi (180dpi) | 96MB | |
200 dpi (200dpi) | ||
213 dpi (tvdpi) | ||
220 dpi (220dpi) | ||
240 dpi (hdpi) | ||
280 dpi (280dpi) | 144MB | |
320 dpi (xhdpi) | 192MB | |
360 dpi (360dpi) | 240MB | |
400 dpi (400dpi) | 288MB | |
420 dpi (420dpi) | 336MB | |
480 dpi (xxhdpi) | 384MB | |
560 dpi (560dpi) | 576MB | |
640 dpi (xxxhdpi) | 768MB |
3.8.使用者介面相容性
3.8.1。啟動器 (主畫面)
Android 提供啟動器應用程式 (主畫面) 和 取代裝置啟動器 (主畫面) 的第三方應用程式。
如果實作裝置可讓第三方應用程式替換裝置 主畫面,他們可以:
- [C-1-1] 必須宣告平台功能
android.software.home_screen
。 - [C-1-2] 必須退回
AdaptiveIconDrawable
物件使用<adaptive-icon>
標記提供 其圖示,以及PackageManager
擷取圖示的方法已獲得呼叫。
如果裝置實作項目包含支援應用程式內的預設啟動器 固定捷徑時,系統會執行以下動作:
- [C-2-1] 必須回報以下項目:
true
ShortcutManager.isRequestPinShortcutSupported()
。 - [C-2-2] 必須先要求使用者授予權限,才能新增要求捷徑
透過
ShortcutManager.requestPinShortcut()
API 方法。 - [C-2-3] 必須支援固定捷徑以及動態和靜態內容 捷徑,詳情請參閱應用程式捷徑頁面。
相反地,如果裝置的實作不支援應用程式內固定功能, 快速鍵:
- [C-3-1] 必須回報以下項目:
false
ShortcutManager.isRequestPinShortcutSupported()
。
如果裝置實作項目實作預設啟動器來提供快速回應 存取第三方應用程式提供的其他捷徑 ShortcutManager API 的運作方式具有以下特性:
- [C-4-1] 必須支援所有記載的快速鍵功能 (例如
動態捷徑、固定捷徑),並完全實作
ShortcutManager
敬上 API 類別。
如果裝置實作項目包含預設啟動器應用程式,會顯示徽章 應用程式圖示後會:
- [C-5-1] 必須尊重
NotificationChannel.setShowBadge()
API 方法。 也就是說,如果應用程式圖示 將值設為true
,在所有結果顯示,不顯示任何應用程式圖示徽章配置 應用程式通知管道的值已設為false
。 - 您可以改用專屬的徽章配置,取代應用程式圖示徽章
第三方應用程式表示公司獲得專屬徽章配置
使用專屬 API,但應使用資源和價值
透過 SDK 中所述的通知徽章 API 取得,
例如:
Notification.Builder.setNumber()
和Notification.Builder.setBadgeIconType()
也能使用 Google Cloud CLI 或 Compute Engine API
如果裝置實作支援 單色 以下圖示:
- [C-6-1] 只有在使用者明確啟用應用程式時 (例如透過 設定或桌布挑選器選單)。
3.8.2。小工具
Android 支援第三方應用程式小工具,方法是定義元件類型 對應的 API 和生命週期可讓應用程式 「應用程式小工具」 供使用者參考
如果裝置導入方式支援第三方應用程式小工具,就會:
- [C-1-1] 必須聲明支援平台功能
android.software.app_widgets
。 - [C-1-2] 必須納入 AppWidgets 的內建支援和公開 新增、設定、查看和移除 AppWidgets 的使用者介面預設用途。
- [C-1-3] 必須能顯示 4 x 4 的小工具 標準格狀檢視請參閱應用程式小工具設計指南 。
- 可能支援螢幕鎖定畫面上的應用程式小工具。
如果裝置實作項目支援第三方應用程式小工具和應用程式內 固定捷徑時,系統會執行以下動作:
- [C-2-1] 必須回報以下項目:
true
AppWidgetManager.html.isRequestPinAppWidgetSupported()
。 - [C-2-2] 必須先要求使用者授予權限,才能新增要求捷徑
透過
AppWidgetManager.requestPinAppWidget()
API 方法。
3.8.3.通知
Android 包括 Notification
和
NotificationManager
讓第三方應用程式開發人員透過 API 通知使用者值得注意的事件。
吸引使用者注意力使用硬體元件 (例如音效、震動)
和燈號) 和軟體功能 (例如通知欄、系統列) 的
裝置。
3.8.3.1。通知呈現方式
如果允許第三方應用程式在導入裝置時通知使用者重要事件,請注意以下事項:
- [C-1-1] 必須支援使用硬體功能的通知,如 SDK 說明文件,並盡可能在裝置實作的情況下 硬體舉例來說,如果裝置導入作業內含震動功能,就「必須」 正確實作震動 API。如果裝置實作 硬體,相關的 API 「必須」是免人工管理來實作。這項行為是 詳情請參閱第 7 節。
- [C-1-2] 必須正確轉譯所有資源 API 或 狀態/系統列圖示樣式指南, 但可能會在通知時提供替代的使用者體驗 而不是 Android 開放原始碼的 參考資料。
- [C-1-3] 必須遵循並依照 API 更新、移除和群組通知。
- [C-1-4] 必須提供 NotificationChannel 的完整行為 API 中載明的 API
- [C-1-5] 必須提供使用者負擔,才能封鎖及修改 每個管道和應用程式套件層級的第三方應用程式通知。
- [C-1-6] 也必須為使用者提供預設用途,允許顯示已刪除的通知 頻道。
- [C-1-7] 必須正確轉譯所有資源 (圖片、貼紙、圖示等) 透過 Notification.MessagingStyle 通知文字旁,無需任何額外使用者互動。適用對象 例如,「必須」顯示所有資源,包括 android.app.Person 轉入群組對話中 setGroupConversation,藉此指定群組對話。
- [C-SR-1] 強烈建議使用者提供應用程式 控管提供給以下應用程式的通知: 通知接聽器權限。精細程度必須能讓使用者 控制每個這類通知事件監聽器 橋接到這個事件監聽器類型「必須」包括「對話」、「快訊」 「靜音」和「重要的持續性」通知。
- [C-SR-2] 強烈「建議」提供能讓使用者指定的預設用途 停止通知任何特定通知事件監聽器。
- [C-SR-3] 強烈建議你盡量自動提供使用者負擔 針對每個管道和應用程式封鎖特定第三方應用程式的通知 使用者多次關閉該通知後的套件層級。
- 應支援複合式通知。
- 應以抬頭通知的形式呈現優先順序較高的通知。
- 應讓使用者有足夠的需求來延後通知。
- 「可能」僅管理第三方應用程式傳送通知的時機和時機 使用者所關注的事件,藉此減少駕駛人分心等安全問題。
Android 11 導入了對話通知的支援功能, 使用 MessagingStyle 的通知 並提供已發布的 People 捷徑 ID。
裝置實作方式:
- [C-SR-4] 強烈建議將這兩個元素分組和顯示
conversation notifications
敬上 優先顯示非對話通知,但 持續性前景服務通知和importance:high
通知。
如果裝置實作方式支援 conversation notifications
應用程式提供了必要的資料
bubbles
,他們:
- [C-SR-5] 強烈建議你以對話框形式顯示這個對話。 Android 開放原始碼計畫實作項目以預設的系統 UI 滿足上述要求。 「設定」和「啟動器」
如果裝置的實作支援複合式通知,就會發生以下狀況:
- [C-2-1] 「必須」使用
透過
Notification.Style
提供的資源元素的 API 類別及其子類別。 - 應呈現每項資源元素 (例如
圖示、標題和摘要文字) 定義於
Notification.Style
API 類別及其子類別
抬頭通知是一種 只會在使用者接觸曝光時, 保持開啟。如果裝置導入方式支援抬頭通知 然後執行下列操作:
- [C-3-1] 必須使用抬頭通知檢視畫面和資源
,如同
Notification.Builder
顯示抬頭通知時的 API 類別。 - [C-3-2] 必須顯示經由
Notification.Builder.addAction()
敬上 與通知內容一起出現,使用者不需進行額外互動 ,詳情請參閱 SDK。
3.8.3.2。通知接聽器服務
Android 包含 NotificationListenerService
可讓應用程式 (使用者明確啟用後) 接收
包括發布或更新所有通知
裝置實作方式:
- [C-0-1] 必須正確並及時更新整個通知 所有已安裝和使用者啟用的事件監聽器服務 (包括任何與 附加至通知物件的所有中繼資料
- [C-0-2] 必須尊重
snoozeNotification()
API 呼叫,關閉通知並在延後後執行回呼 時間長度。
如果裝置的實作具有使用者負擔延後通知的權限,就會執行以下動作:
- [C-1-1] 必須正確反映延後通知的狀態
經由標準 API 傳送
NotificationListenerService.getSnoozedNotifications()
。 - [C-1-2] 必須授予這位使用者權限,讓他們能暫停通知 安裝您的應用程式,除非應用程式的來源 持續性/前景服務
3.8.3.3。DND (請勿打擾)/ 優先模式
如果裝置實作支援 DND 功能 (又稱為「優先模式」),他們可以:
- [C-1-1] 必須「必須」適用於裝置的實作已為使用者提供方法 授予或拒絕第三方應用程式存取 DND 政策設定; 顯示自動 DND 規則 建立的規則。
- [C-1-3] 必須尊重
suppressedVisualEffects
透過NotificationManager.Policy
傳送的值 如果應用程式已設定任何 SUPPRESSED_effective_SCREEN_OFF 或 SUPPRESSED_ff_SCREEN_ON 標記,此標記應告知使用者 DND 設定選單中隱藏視覺效果。
3.8.4。Assist API
Android 包含輔助 API 讓應用程式能選取當目前背景所需的資訊量 分享給裝置上的助理。
如果裝置導入方式支援輔助動作,就會:
- [C-2-1] 分享背景資訊時,必須向使用者明確指出
:
- 每當輔助應用程式存取內容時,畫面會顯示白色 畫面邊緣必須符合或超過時間長度 Android 開放原始碼計畫實作畫面的亮度。
- 針對預先安裝的輔助應用程式,使用者能享有的負擔更低 兩人之間有大約兩個訪客 預設的語音輸入和 Google 助理應用程式設定選單, 並且只在由遠端叫用輔助應用程式的情況下,才分享背景資訊 使用者透過啟動字詞或輔助瀏覽鍵輸入內容
- [C-2-2] 指定啟動輔助應用程式的互動行為 (如所述)
在第 7.2.3 節中,「必須」啟動使用者選取
輔助應用程式,也就是實作
VoiceInteractionService
的應用程式。 或是處理ACTION_ASSIST
意圖的活動
3.8.5。快訊與浮動式訊息
應用程式可以使用 Toast
這個 API 可以向使用者顯示在
使用 TYPE_APPLICATION_OVERLAY
視窗類型 API,在其他應用程式上方以重疊方式顯示快訊視窗。
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
[C-1-1] 「必須」提供使用者權限,禁止應用程式顯示快訊 使用
TYPE_APPLICATION_OVERLAY
的視窗 ,直接在 Google Cloud 控制台實際操作。Android 開放原始碼計畫實作項目必須在通知欄中提供控制項,以符合這項規定。[C-1-2] 必須遵循 Toast API,並在部分高層級向使用者顯示應用程式浮動式訊息 顯示方式
3.8.6。主題
Android 提供「主題」機制,讓應用程式在 整個活動或應用程式
Android 內含「Holo」和「Material」是一組已定義的樣式 供應用程式開發人員使用 Holo 主題外觀和風格 符合 Android SDK 的定義
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
- [C-1-1] 不得變更 應用程式。
- [C-1-2] 必須支援「Material」主題系列,且不得變更 Material Design 主題屬性 或公開給應用程式的任何資產
[C-1-3] 必須設定「sans-Serif」字型系列 適用於語言的 Roboto 2.x 版 也讓使用者能夠自行選擇合適的字型 代表「sans-Serif」Roboto 2.x 版的字型系列 以及 Roboto 支援的語言
[C-1-4] 必須產生 Android 開放原始碼計畫中指定的動態調色盤
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
說明文件 (請參閱 「android.theme.customization.system_palette
」和android.theme.customization.theme_style
)。[C-1-5] 必須使用色彩主題樣式產生動態調色盤 列舉的
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
中 說明文件 (請參閱android.theme.customization.theme_styles
), 也就是TONAL_SPOT
、VIBRANT
、EXPRESSIVE
、SPRITZ
、RAINBOW
、FRUIT_SALAD
。「來源顏色」每次傳送
android.theme.customization.system_palette
(如記錄於Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
)。[C-1-6]
CAM16
色域值必須大於或等於 5。是否應該透過
com.android.systemui.monet.ColorScheme#getSeedColors
,提供 有多種有效的來源顏色可供選擇。如果提供的顏色皆不符,則應使用
0xFF1B6EF3
值 上述來源顏色規定。
Android 也包含「裝置預設」主題系列,做為一組已定義的樣式 供應用程式開發人員使用 根據裝置實作者定義的裝置主題。
- 裝置實作方式可能會修改公開的裝置預設主題屬性 應用程式。
Android 支援具有半透明系統資訊列的變化版本主題, 以便填滿狀態和導覽列後方的區域 與應用程式內容互動為了在此提供一致的開發人員體驗 您必須在整個容器中保留狀態列圖示樣式 不同的裝置導入方式
如果裝置導入方式包含系統狀態列,就會:
- [C-2-1] 系統狀態圖示 (例如訊號強度和 電池電量) 以及系統所發出的通知,除非該圖示 表示有問題的狀態,或者應用程式要求顯示光源狀態列, WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS 旗標。
- [C-2-2] 實作 Android 裝置時,「必須」變更系統顏色 在應用程式出現時,將狀態圖示變成黑色 (詳情請參閱 R.style) 要求顯示淺色狀態列
3.8.7。動態桌布
Android 定義了元件類型和對應的 API 和生命週期 來公開一或多個應用程式 「動態桌布」 供使用者參考動態桌布是動畫、圖案或類似的圖片 因為輸入功能有限,顯示為桌布、背後其他圖片 應用程式。
只要硬體能穩定運作,就被視為能夠穩定執行動態桌布 所有動態桌布,且功能不受限 而不會對其他應用程式造成負面影響。如果 硬體 會造成桌布和/或應用程式當機、故障、消耗 CPU 或電池耗電量過多,或是執行時超出影格速率上限 硬體視為無法執行動態桌布舉例來說 動態桌布可能會使用 OpenGL 2.0 或 3.x 內容來顯示內容。 在不支援多重功能的硬體上,動態桌布將無法穩定執行 OpenGL 結構定義,因為動態桌布使用 OpenGL 結構定義時可能會發生衝突 與其他使用 OpenGL 內容的應用程式互動。
- 裝置實作,可穩定地執行動態桌布 。
如果裝置實作的是動態桌布,動態桌布會:
- [C-1-1] 必須回報平台功能旗標 android.software.live_wallpaper。
3.8.8。活動切換
上游 Android 原始碼包含 總覽畫面, 系統層級的使用者介面,用於切換工作並顯示最近存取過的項目 透過應用程式圖形 狀態。
裝置實作 包括近期函式瀏覽鍵,詳情請參閱 第 7.2.3 節 自訂介面。
如果裝置實作項目包含最近使用的功能瀏覽鍵,詳情如下: 第 7.2.3 節修改介面:
- [C-1-1] 最多只能支援 7 個顯示活動。
- 一次至少應顯示 4 項活動的標題。
- [C-1-2] 必須導入螢幕固定行為 並提供設定選單,方便使用者切換功能
- 應在近期顯示醒目顯示顏色、圖示和畫面標題。
- 應顯示關閉的預設用途 (「x」),但可能要等到使用者與螢幕互動後再執行。
- 「應」導入捷徑,以便輕鬆切換至上一個活動。
- 應在最近使用的兩個金鑰間觸發快速切換動作 應用程式。
- 在支援的情況下,應觸發分割畫面多視窗模式 (如果支援的話) 長按最近函式鍵。
- 可能顯示有關聯的近期資訊群組。
- [C-SR-1] 強烈建議使用上游 Android 使用者 總覽畫面 (或類似的縮圖式介面)。
3.8.9。輸入管理
Android 支援 輸入管理 以及第三方輸入法編輯器支援
如果裝置實作方式允許使用者在 這些裝置,他們可以:
- [C-1-1] 必須宣告平台功能 android.software.input_methods 和 支援 Android SDK 說明文件中定義的 IME API。
3.8.10。螢幕鎖定媒體控制項
Remote Control Client API 已從 Android 5.0 淘汰,改用 媒體通知範本 可讓媒體應用程式整合 。
3.8.11。螢幕保護程式 (先前為 Dream)
請參閱第 3.2.3.5 節的設定 表明瞭需要消弭螢幕保護程式的意圖
3.8.12。位置
如果裝置實作項目內含支援 GPS 的硬體感應器 (例如 GPS) 提供位置座標
3.8.13。萬國碼 (Unicode) 和字型
Android 支援在清單中定義的表情符號字元 Unicode 10.0。
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
- [C-1-1] 必須能夠以色彩字符轉譯這些表情符號字元。
- [C-1-2] 必須支援下列項目:
- Roboto 2 字型粗細不同:sans-Serif-thin、Sans-Serif-light Sans-Serif-medium、Sans-Serif-black、Sans-Serif-condensed Sans-Serif 冷凝型燈 (適用於裝置支援的語言)。
- 完整 Unicode 7.0 涵蓋拉丁、希臘和西里爾文,包括 拉丁擴充 A、B、C 和 D 範圍,以及貨幣中的所有字符 Unicode 7.0 的符號區塊。
- [C-1-3] 不得移除或修改系統映像檔中的 NotoColorEmoji.tff。 (您可以新增表情符號字型來覆寫表情符號中的表情符號,但 NotoColorEmoji.tff
- 應支援 Unicode 技術報告 #51。
如果裝置實作項目包含輸入法編輯器,則會:
- 這些表情符號字元應為使用者提供輸入法。
Android 支援轉譯緬甸字型。緬甸擁有好幾個 非萬國碼 (Unicode) 相容字型,一般稱為「Zawgyi」表示緬甸 語言。
如果裝置的實作選項支援緬甸文,請注意:
- [C-2-1] 預設顯示文字時,必須使用符合 Unicode 標準的字型。 除非使用者,否則非萬國碼 (Unicode) 規定的字型「不得」設為預設字型 即可在語言選單中選取所需項目
- [C-2-2] 必須支援 Unicode 字型,以及不符合 Unicode 規範的字型 裝置使用不符合 Unicode 規定的字型。非萬國碼 (Unicode) 相容字型「不得」移除或覆寫 Unicode 字型。
- [C-2-3] 只有在 語言代碼 指令碼程式碼 Qag (例如 my-Qag)。沒有其他 ISO 語言或區碼 ( 指派、未指派或保留) 可用於參照非萬國碼 (Unicode) 符合緬甸的字型應用程式開發人員和網頁作者 請將 my-Qag 指定為指定語言代碼 或其他語言。
3.8.14。多視窗模式
如果裝置實作支援在以下位置顯示多項活動: 同時也:
- [C-1-1] 必須根據 Android SDK 中描述的應用程式行為和 API 多視窗模式支援說明文件,以及 Meet 下列要求:
- [C-1-2] 必須尊重
android:resizeableActivity
由應用程式設定,如AndroidManifest.xml
檔案所述 此 SDK - [C-1-3] 如果是使用分割畫面或任意形式模式,就「不得」提供 螢幕高度小於 440 dp,且螢幕寬度小於 440 dp。
- [C-1-4] 活動的大小「不得」將大小調整為小於 220 dp 子母畫面模式以外的多視窗模式。
- 裝置實作且螢幕大小
xlarge
必須支援任意形式 模式。
如果裝置實作項目支援多視窗模式,以及分割畫面 模式,就會:
- [C-2-2] 必須在分割畫面多視窗模式下裁剪固定活動,但 如果啟動器應用程式是焦點視窗,則應顯示部分內容。
- [C-2-3] 必須遵循宣告的
AndroidManifestLayout_minWidth
和AndroidManifestLayout_minHeight
,且不會覆寫這些值 在顯示座架活動的部分內容中
如果裝置實作支援多視窗模式和子母畫面 多視窗模式的作用:
- [C-3-1] 必須在子母畫面多視窗模式下啟動活動
以下情況表示:
* 指定 API 級別 26 以上並宣告
android:supportsPictureInPicture
敬上 * 指定 API 級別為 25 以下,並宣告android:resizeableActivity
和android:supportsPictureInPicture
。 - [C-3-2] 必須按照
由目前子母畫面活動透過
setActions()
指定 也能使用 Google Cloud CLI 或 Compute Engine API - [C-3-3] 支援的長寬比必須大於或等於
1:2.39 且小於或等於 2.39:1,由子母畫面活動指定
setAspectRatio()
也能使用 Google Cloud CLI 或 Compute Engine API - [C-3-4] 必須使用
KeyEvent.KEYCODE_WINDOW
控制子母畫面視窗;如未執行子母畫面模式,關鍵就「必須」 可用在前景活動中。 - [C-3-5] 「必須」提供使用者負擔,禁止應用程式顯示 子母畫面模式;能夠符合這項規定 。
[C-3-6] 請務必為子母畫面分配下列寬度和高度下限 未宣告任何
AndroidManifestLayout_minWidth
敬上 和AndroidManifestLayout_minHeight
:- 未正確設定 Configuration.uiMode 的裝置
UI_MODE_TYPE_TELEVISION
敬上 必須分配最小寬度和高度為 108 dp。 - 已設定 Configuration.uiMode 的裝置
UI_MODE_TYPE_TELEVISION
敬上 請分配最小寬度為 240 dp,高度下限為 135 dp。
- 未正確設定 Configuration.uiMode 的裝置
3.8.15。螢幕去背
如同上所述,Android 支援螢幕凹口
。DisplayCutout
API 會定義
螢幕邊緣不對應用程式而言不作用的區域
這會導致裝置使用螢幕凹口或曲線顯示。
如果裝置的實作方式包含螢幕凹口,會發生以下情況:
- [C-1-5] 如果裝置的顯示比例為 1.0(1:1),「不得」包含凹口。
- [C-1-2] 每邊只能有一個凹口。
- [C-1-3] 必須遵循應用程式設定的螢幕凹口旗標
WindowManager.LayoutParams
敬上 與 SDK 中所述的 - [C-1-4] 務必針對以下項目中定義的所有凹口指標回報正確的值:
DisplayCutout
API。
3.8.16。裝置控制
Android 包括 ControlsProviderService
和 Control
方便第三方應用程式發布裝置控制項的 API
狀態和動作
如要瞭解裝置專屬的需求,請參閱 2_2_3 節。
3.8.17。剪貼簿
裝置實作方式:
- [C-0-1] 不得將剪貼簿資料傳送給任何元件、活動、服務或 使用者未明確採取動作 (例如按下 按鈕),但 9.8.6 內容擷取和應用程式搜尋。
如果裝置導入方式會在複製內容時產生使用者可見的預覽
複製到剪貼簿的任何 ClipData
項目
ClipData.getDescription().getExtras()
包含
android.content.extra.IS_SENSITIVE
,他們:
- [C-1-1] 必須遮蓋使用者可見的預覽畫面
Android 開放原始碼計畫參考資料實作項目符合這些剪貼簿規定。
3.9.裝置管理
Android 隨附的功能可讓具有安全性感知的應用程式執行 裝置管理功能,例如強制設定密碼 或執行遠端清除 Android Device 管理 API
如果裝置實作項目實作完整的裝置管理範圍, :
- [C-1-1] 必須宣告
android.software.device_admin
。 - [C-1-2] 必須依照下列說明支援裝置擁有者佈建作業 第 3.9.1 節和 第 3.9.1.1 節。
3.9.1 裝置佈建
3.9.1.1 裝置擁有者佈建
如果裝置實作項目宣告 android.software.device_admin
,就會:
- [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為
裝置擁有者應用程式
如下所述:
- 當裝置實作
使用者或
使用者資料設定後
- [C-1-5] 必須註冊 DPC 應用程式做為裝置擁有者應用程式
或啟用裝置政策控制器 (DPC) 應用程式
成為裝置擁有者或設定檔擁有者
如果裝置透過
功能旗標
android.hardware.nfc
並收到 NFC 訊息 包含 MIME 類型的記錄MIME_TYPE_PROVISIONING_NFC
。 - [C-1-8] 必須傳送 ACTION_GET_PROVISIONING_MODE
意圖並取得裝置擁有者佈建後的流量
DPC 應用程式可以選擇成為裝置擁有者或設定檔
擁有者,視
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, 除非能在 這兩個內容只有一個有效選項。 - [C-1-9] 必須 ACTION_ADMIN_POLICY_COMPLIANCE 提供給裝置擁有者應用程式的意圖 (如果已建立裝置擁有者) 佈建狀態。 使用者必須必須等到 完成「裝置擁有者」應用程式的設定。
- [C-1-5] 必須註冊 DPC 應用程式做為裝置擁有者應用程式
或啟用裝置政策控制器 (DPC) 應用程式
成為裝置擁有者或設定檔擁有者
如果裝置透過
功能旗標
- 當裝置實作
或使用者
使用者資料時,它會:
- [C-1-7] 不得將任何 DPC 申請註冊為裝置擁有者應用程式 。
- 當裝置實作
使用者或
使用者資料設定後
- [C-1-2] 必須顯示適當的揭露通知 (例如 Android 開放原始碼計畫參照) 的應用程式,並在應用程式前取得使用者的確認同意 設為裝置擁有者 (除非裝置是透過程式輔助方式設定) 適用於零售商展示模式 並未顯示在畫面上,
如果裝置實作項目宣告了 android.software.device_admin
,但同時宣告了
提供專屬裝置管理解決方案,並提供相關機制
,將解決方案中設定的應用程式升級為「裝置擁有者」
等值」標準「裝置擁有者」如標準 Android 系統辨識的
DevicePolicyManager
API 具有以下特點:
- [C-2-1] 必須設有專門程序,才能驗證特定應用程式 促銷屬於合法企業裝置管理 並已在專屬解決方案中設定 取得與「裝置擁有者」同等的權利。
- [C-2-2] 必須顯示與
由
android.app.action.PROVISION_MANAGED_DEVICE
發起的資料流 ,以「裝置擁有者」的身分註冊 DPC 應用程式。 - [C-2-3] 不得以硬式編碼的方式寫入同意聲明或禁止事項 使用其他裝置擁有者的應用程式
3.9.1.2 受管理設定檔佈建
如果裝置實作項目宣告 android.software.managed_users
,就會:
[C-1-1] 必須實作 API 讓 Device Policy Controller (DPC) 應用程式 新受管理設定檔的擁有者。
[C-1-2] 受管理設定檔佈建程序 (DPC 使用 android.app.action.PROVISION_MANAGED_PROFILE)。 同意畫面和使用者體驗必須一致 實作 Android 開放原始碼計劃
[C-1-3] 「設定」中「必須」提供下列使用者預設用途 指示使用者 裝置政策控制器 (DPC):
- 圖示一致或符合其他使用者的需求 (例如上游 Android 開放原始碼計畫資訊圖示),表示 以及裝置管理員
- 裝置管理員透過
setShortSupportMessage
。 - DPC 應用程式圖示。
[C-1-4] 必須啟動 ACTION_PROVISIONING_SUCCESSFUL 的處理常式 資料必須登錄於 佈建作業是由 android.app.action.PROVISION_MANAGED_PROFILE 啟動 意圖且 DPC 已經實作這個處理常式。
[C-1-5] 必須傳送 ACTION_PROFILE_PROVISIONING_COMPLETE 在執行佈建時,將廣播訊息廣播至工作資料夾 DPC android.app.action.PROVISION_MANAGED_PROFILE 意圖。
[C-1-6] 必須傳送 ACTION_GET_PROVISIONING_MODE 觸發了設定檔擁有者佈建後的所有意圖 可以選擇成為裝置擁有者或設定檔擁有者,但 佈建是由意圖 android.app.action.PROVISION_MANAGED_PROFILE 觸發。
[C-1-7] 必須傳送 ACTION_ADMIN_POLICY_COMPLIANCE 設定檔擁有者於 佈建限制,無論使用哪種佈建方法, (當意圖 android.app.action.PROVISION_MANAGED_PROFILE 觸發布建時)。 在設定檔開始前,使用者無法在設定精靈中繼續操作 擁有者應用程式已完成。
[C-1-8] 必須傳送 ACTION_MANAGED_PROFILE_PROVISIONED 在建立個人資料擁有者後向個人資料 DPC 播送。 無論使用的佈建方法為何
3.9.2 支援受管理設定檔
如果裝置實作項目宣告 android.software.managed_users
,就會:
- [C-1-1] 必須支援透過
android.app.admin.DevicePolicyManager
管理受管理的設定檔 相互整合 - [C-1-2] 只能建立一個受管理的設定檔。
- [C-1-3] 必須使用圖示徽章 (類似 Android 開放原始碼計畫上游工作徽章),才能 代表受管理的應用程式和小工具,以及其他標記的 UI 元素 例如「近期」和通知。
- [C-1-4] 必須顯示通知圖示 (類似 Android 開放原始碼計畫上游工作) 徽章),表示使用者何時屬於受管理的設定檔應用程式。
- [C-1-5] 必須顯示浮動式訊息,指出使用者有受管理 設定檔是否喚醒,以及裝置喚醒的時間點 (ACTION_USER_PRESENT) 前景應用程式位於受管理的設定檔中。
- [C-1-6] 如果有受管理的設定檔,「必須」在 意圖「選擇者」可讓使用者從代管式 VPN 閘道 將設定檔還原為主要使用者,反之亦然 控制器。
- [C-1-7] 如果有受管理的設定檔,「必須」揭露下列使用者
主要使用者和受管理設定檔可實現的功能:
- 將電池、位置、行動數據和儲存空間用量分開計算 。
- 獨立管理安裝在主要伺服器中 或受管理的設定檔
- 獨立管理主要使用者在當中安裝的應用程式 或受管理的設定檔
- 獨立管理主要使用者或受管理使用者的帳戶
- [C-1-8] 必須確保預先安裝的撥號程式、聯絡人和訊息 應用程式可在受管理的 Android 裝置上搜尋及查詢來電者資訊 以及主要設定檔的資料 (如果有的話) 根據 Device Policy Controller 允許
- [C-1-9] 必須確認符合所有安全性需求 適用於多位使用者啟用的使用者 (請參閱第 9.5 節),即使是受管理的設定檔也一樣 則不計入主要使用者以外的其他使用者。
如果裝置實作方式宣告了 android.software.managed_users
並
android.software.secure_lock_screen
,他們:
- [C-2-1] 必須支援另外指定螢幕鎖定畫面的會議
下列需求條件,將存取權授予在受管理應用程式中執行的應用程式
。
- 裝置導入方式必須遵循
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
敬上 意圖並顯示用於設定獨立螢幕鎖定畫面的介面 。 - 受管理設定檔的螢幕鎖定憑證「必須」使用相同的憑證 憑證儲存和管理機製做為主要設定檔 與 Android 開放原始碼計畫網站。
- 裝置政策控制器 (DPC) 密碼政策
必須套用到受管理設定檔的螢幕鎖定憑證,除非
會在由 SDK 傳回的
DevicePolicyManager
例項上呼叫 getParentProfileInstance。
- 裝置導入方式必須遵循
- 顯示受管理設定檔的聯絡人時 列於預先安裝的通話記錄、來電使用者介面、進行中和未接來電 通知、聯絡人和訊息應用程式均應加上 標示出受管理的設定檔應用程式。
3.9.3 受管理使用者支援
如果裝置實作項目宣告 android.software.managed_users
,就會:
- [C-1-1] 必須提供使用者容許條件,讓使用者登出目前的使用者
並在多使用者工作階段中切換回主要使用者
isLogoutEnabled
敬上 會傳回true
。「必須」可以在螢幕鎖定畫面上存取使用者授權 而不必解鎖裝置
如果裝置實作方式宣告了 android.software.device_admin
,並提供了
增減「次要使用者」的裝置端使用者需求:
- [C-SR-1] 強烈建議向相同 Android 開放原始碼計畫裝置擁有者顯示同意聲明 在由 Google 發起的流程中, android.app.action.PROVISION_MANAGED_DEVICE、 才能將帳戶加入新的次要「使用者」 以便使用者瞭解裝置受到管理
3.9.4 裝置政策管理角色要求
如果裝置導入作業回報 android.software.device_admin
或
android.software.managed_users
,然後他們:
- [C-1-1] 必須支援裝置政策管理角色 (如
第 9.1 節。擁有裝置政策管理角色的應用程式
可以透過將
config_devicePolicyManagement
設為套件名稱來定義。 除非預先載入應用程式,否則套件名稱後面必須加上:
以及簽署憑證。
如果 config_devicePolicyManagement
的套件名稱未定義為
前提:
- [C-2-1] 實作裝置「必須」支援在沒有裝置的情況下佈建 政策管理角色持有者應用程式 (Android 開放原始碼計畫提供參考實作)。
如果按照上述說明為 config_devicePolicyManagement
定義了套件名稱
以上:
- [C-3-1] 所有應用程式都必須安裝 設定檔 適用於使用者。
- [C-3-2] 裝置實作可能會定義更新
佈建前的裝置政策管理角色擁有者
config_devicePolicyManagementUpdater
。
如果將 config_devicePolicyManagementUpdater
的套件名稱定義為
前提:
- [C-4-1] 應用程式「必須」預先安裝在裝置上。
- [C-4-2] 應用程式「必須」實作意圖篩選器,
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
。
3.10.無障礙設定
Android 提供的無障礙工具層,可協助身心障礙使用者 也能更輕鬆地瀏覽裝置此外,Android 也提供平台 API 可讓無障礙服務實作以接收使用者的回呼 並產生替代回饋機制 文字轉語音、觸覺回饋和軌跡球/D-Pad 導航。
如果裝置實作項目支援第三方無障礙服務,就會:
- [C-1-1] 必須實作 Android 無障礙功能 使用 PersistentVolumeClaim Accessibility API SDK 說明文件。
- [C-1-2] 必須產生無障礙功能事件,並提供適當的
所有已註冊的
AccessibilityEvent
AccessibilityService
按照 SDK 中的指示執行。 - [C-1-4] 必須提供使用者授權,讓他們控管無障礙功能 宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON。 請注意,對於具有系統導覽列的裝置實作項目, 應讓使用者能在系統的 導覽列控管這些服務
如果裝置實作項目包含預先安裝的無障礙服務,就會:
- [C-2-1] 必須按照 直接啟動感知 應用程式。
- 使用者應在開箱的設定流程中,提供可啟用機制的機制 相關無障礙服務 以及調整字型大小的選項 顯示大小和放大手勢
3.11.文字轉語音
Android 提供的 API 可讓應用程式使用文字轉語音 服務,並讓服務供應商能夠實作 TTS 免費 Google Cloud 服務
如果裝置實作回報功能 android.hardware.audio.output, 他們會:
- [C-1-1] 必須支援 Android TTS 架構 相互整合
如果裝置的導入方式支援安裝第三方 TTS 引擎,請按照下列步驟操作:
- [C-2-1] 必須提供使用者優先度,讓使用者能夠選取 TTS 要在系統層級使用
3.12.電視輸入架構
Android 電視輸入架構 (TIF) 可簡化直播內容的提交方式 發布到 Android TV 裝置。TIF 提供了要建立模型的標準 API 控制 Android TV 裝置的輸入模組
如果裝置實作支援 TIF,請按照下列步驟操作:
- [C-1-1] 必須宣告平台功能
android.software.live_tv
。 - [C-1-2] 必須支援所有 TIF API,例如使用 這些 API 和第三方 TIF 輸入內容 服務可在裝置上安裝及使用。
3.13.快速設定
Android 提供快速設定 UI 元件,可讓使用者快速存取 或迫切需要的動作
如果實作的裝置包含快速設定 UI 元件,並支援第三方 「快速設定」頁面的用途:
- [C-1-1] 必須允許使用者新增或移除透過
quicksettings
敬上 API 限制。 - [C-1-2] 「不得」直接從第三方應用程式自動新增資訊方塊 加入「快速設定」選單
- [C-1-3] 必須顯示使用者在第三方應用程式中新增的所有資訊方塊 旁邊還有系統提供的快速設定方塊。
3.14。媒體使用者介面
如果裝置的實作方式含有無法啟動語音操作的應用程式 (也就是與應用程式互動的應用程式),
使用 MediaBrowser
建立第三方應用程式
或 MediaSession
,
應用程式:
[C-1-2] 必須清楚顯示透過
getIconBitmap()
或getIconUri()
取得的圖示以及標題 透過getTitle()
取得 (如MediaDescription
所述)。 為遵守安全法規 (例如駕駛人分心),可能會縮短名稱。[C-1-3] 顯示 使用這個第三方應用程式
[C-1-4] 必須允許使用者與整個
MediaBrowser
互動 階層為遵循安全法規,「可能」限制部分階層人員的存取 (例如駕駛人分心),但「不得」根據內容或 內容供應器。[C-1-5] 必須考慮輕觸兩下
KEYCODE_HEADSETHOOK
敬上 或KEYCODE_MEDIA_PLAY_PAUSE
使用身分:KEYCODE_MEDIA_NEXT
新機MediaSession.Callback#onMediaButtonEvent
。
3.15.免安裝應用程式
如果裝置實作項目支援免安裝應用程式,就必須符合下列規定: 規定:
- [C-1-1] 免安裝應用程式只能取得具有
android:protectionLevel
敬上 已設為"instant"
。 - [C-1-2] 免安裝應用程式「不得」透過隱含意圖與已安裝的應用程式互動
除非符合下列任一條件:
- 此元件的意圖模式篩選器已公開,且具有 CATEGORY_BROWSABLE
- 這個動作可以是下列其中之一:ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE
- 系統已透過 android:visibleToInstantApps 明確公開目標
- [C-1-3] 除非 元件是透過 android:visibleToInstantApps 公開
- [C-1-4] 已安裝的應用程式「不得」在 除非免安裝應用程式明確連線至 已安裝的應用程式。
裝置實作「必須」提供下列使用者負擔 與免安裝應用程式互動Android 開放原始碼計畫符合 預設系統 UI、設定和啟動器裝置實作方式:
- [C-1-5] 必須為使用者提供權限,才能查看及刪除免安裝應用程式 以便針對每個個別應用程式套件 使用本機快取功能
- [C-1-6] 必須向使用者提供有效通知
會在前景執行免安裝應用程式時收合。這位使用者
通知「必須」說明免安裝應用程式不必安裝
並提供引導使用者前往應用程式的功能
資訊畫面。對於透過網路意圖啟動的免安裝應用程式,如
定義方法是使用動作設為
Intent.ACTION_VIEW
的意圖 配置為「http」或「https」; 不得讓使用者啟動免安裝應用程式,並 啟動與所配置網路瀏覽器相關的連結 (如果瀏覽器) 可用位置。 - [C-1-7] 必須允許「最近」存取執行中的免安裝應用程式 函式 (如果有的話)。
[C-1-8] 必須預先載入一或多個應用程式或服務元件 這裡包含 SDK 所列意圖的意圖處理常式,以及該意圖的處理常式 以及顯示免安裝應用程式的意圖
3.16.配對裝置配對
Android 支援配對裝置配對功能,可提升管理效率
與隨附裝置建立關聯,並提供 CompanionDeviceManager
。
如果實作的裝置支援隨附裝置配對功能,就會:
- [C-1-1] 必須宣告功能標記
FEATURE_COMPANION_DEVICE_SETUP
,直接在 Google Cloud 控制台實際操作。 - [C-1-2] 必須確保
android.companion
已完全實作套件 - [C-1-3] 必須為使用者提供可用功能,讓使用者選取/確認夥伴 正常運作並正常運作。
3.17. 重量級應用程式
如果裝置實作方式宣告了 FEATURE_CANT_SAVE_STATE
功能,
然後:
- [C-1-1] 「必須」僅安裝一個指定
cantSaveState
敬上 一次在系統中執行如果使用者 使用者未明確離開應用程式 (例如按下 在家模式期間離開系統活動,而非按下返回按鈕 系統中沒有剩餘的活動),那麼 裝置實作項目必須像在其他用途上一樣,在 RAM 中優先執行該應用程式 例如前景服務 當這類應用程式在背景執行時,系統仍可使用電力 例如限制 CPU 和網路存取權 - [C-1-2] 必須提供 UI 預設用途,以便選擇不會
在使用者行為後參與正常狀態儲存/還原機制
啟動使用
cantSaveState
宣告的第二個應用程式 屬性。 - [C-1-3] 「不得」將政策中的其他變更套用到指定的應用程式
cantSaveState
、 例如變更 CPU 效能或變更排程優先順序
如果裝置實作方式未宣告這項功能
FEATURE_CANT_SAVE_STATE
、
然後:
- [C-1-1] 必須忽略
cantSaveState
屬性,且「不得」根據該設定變更應用程式行為。 屬性。
3.18.聯絡人
Android 包括 Contacts
Provider
運用 API,讓應用程式管理裝置上儲存的聯絡資訊。
直接輸入裝置上的聯絡人資料通常會保持同步
透過 Web 服務存取資料,但資料「可能」只會儲存在裝置上。
只儲存在裝置上的聯絡人稱為「本機」
聯絡人。
RawContacts
是否「相關聯」或「已儲存於」換
帳戶
當
ACCOUNT_NAME
,
和
ACCOUNT_TYPE
,
原始聯絡人欄中的
帳戶名稱
和
Account.type
欄位。
預設本機帳戶:存放原始聯絡人的帳戶
且未與 AccountManager 中的帳戶建立關聯 (
已為事件建立 null 值
ACCOUNT_NAME
,
和
ACCOUNT_TYPE
,
欄。
自訂本機帳戶:儲存原始聯絡人的帳戶,只會儲存在
且未與 AccountManager 中的帳戶建立關聯 (
為
ACCOUNT_NAME
,
和
ACCOUNT_TYPE
,
欄。
裝置實作方式:
- [C-SR-1] 強烈建議不要建立自訂本機帳戶。
如果裝置的實作程序使用自訂本機帳戶:
- [C-1-1]
ACCOUNT_NAME
、 (必須退回自訂本機帳戶中的電子郵件地址),ContactsContract.RawContacts.getLocalAccountName
- [C-1-2]
ACCOUNT_TYPE
、 (必須退回自訂本機帳戶中的電子郵件地址),ContactsContract.RawContacts.getLocalAccountType
- [C-1-3] 由第三方應用程式插入原始聯絡人,並使用
預設本機帳戶 (也就是將
ACCOUNT_NAME
和ACCOUNT_TYPE
) 必須插入自訂區域 帳戶。 - [C-1-4] 不得插入自訂本機帳戶中的原始聯絡人 新增或移除帳戶
- [C-1-5] 針對自訂本機帳戶執行的刪除作業
「必須」可能導致原始聯絡人立即遭到清除 (就像
CALLER_IS_SYNCADAPTER
參數設為 true),即使已設定CALLER\_IS\_SYNCADAPTER
參數也一樣 設為 false 或是未指定
4. 應用程式封裝的相容性
裝置實作方式:
[C-0-1] 必須能夠安裝及執行 Android「.apk」檔案 自己透過「aapt」工具產生的 官方 Android SDK
- 上述規定可能比較困難,因此裝置實作後的 建議使用 Android 開放原始碼計畫參考資料實作項目的套件管理功能 有些人會將 Cloud Storage 視為檔案系統 但實際上不是
[C-0-2] 必須支援使用 APK Signature Scheme v3.1, APK Signature Scheme v3, APK 簽署配置 v2 和 JAR 簽署中。
[C-0-3] 不得延伸 .apk、 Android 資訊清單, Dalvik 位元碼,或 RenderScript 位元碼格式時,可避免這些檔案 安裝在其他相容裝置上正常執行。
[C-0-4] 不得允許現有應用程式以外的應用程式 "記錄安裝者",以便套件在無訊息的情況下解除安裝應用程式 使用者確認,如
DELETE_PACKAGE
的 SDK 中所述 權限。唯一的例外狀況是系統套件驗證器應用程式處理 PACKAGE_NEEDS_VERIFICATION 意圖和儲存空間管理工具應用程式處理 ACTION_MANAGE_STORAGE 意圖。[C-0-5] 必須包含能夠處理
android.settings.MANAGE_UNKNOWN_APP_SOURCES
敬上 意圖。[C-0-6] 不得安裝不明來源的應用程式套件 來源 (要求安裝的應用程式除外) 符合下列所有條件:
- 它必須宣告
REQUEST_INSTALL_PACKAGES
或將android:targetSdkVersion
設為 24 以下。 - 必須已獲使用者授權,才能從這個應用程式安裝應用程式 來源為不明。
- 它必須宣告
「應」提供使用者負擔,讓他們授予/撤銷 為每個應用程式安裝不明來源的應用程式,但也可選擇實作 此為免人工管理,並針對
startActivityForResult()
傳回RESULT_CANCELED
。 。 不過即使如此,他們也應該向使用者說明 給予支援[C-0-7] 「必須」顯示警告對話方塊,內含 透過系統 API
PackageManager.setHarmfulAppWarning
提供 在應用程式中啟動活動之前,表示已標記為 由相同的系統 APIPackageManager.setHarmfulAppWarning
進行,與可能 有害。「應」提供使用者負擔,讓他們選擇解除安裝或啟動 是否套用了警告對話方塊
[C-0-8] 必須依文件說明,導入漸進式檔案系統的支援功能 請按這裡。
[C-0-9] 必須支援使用 APK 簽署配置 v4 驗證 .apk 檔案 APK Signature Scheme v4.1。
5. 多媒體相容性
裝置實作方式:
- [C-0-1] 必須支援媒體格式、編碼器、解碼器、檔案類型
以及第 5.1 節中定義的容器格式
的每個轉碼器。
MediaCodecList
。 - [C-0-2] 必須宣告及回報對編碼器和解碼器的支援
透過 Cloud Shell 的指令列
MediaCodecList
。 - [C-0-3] 必須能正確解碼,並提供給第三方
應用程式可編碼的所有格式這包括
產生及回報的剖析檔
CamcorderProfile
。
裝置實作方式:
- 應盡量縮短轉碼器延遲時間,換句話說
- 不應使用及儲存輸入緩衝區,且只傳回輸入緩衝區 加以處理
- 「不得」保留超過 標準 (例如 SPS)。
- 「不得」保留超過 GOP 所需時間的編碼緩衝區 成本中心的架構
下一節列出的所有轉碼器都是以軟體形式提供 在 Android Open 上,偏好 Android 實作中的實作 來源專案。
請注意,Google 或開放手機聯盟均不 表示這些轉碼器不在第三方專利中。這些 建議您打算在硬體或軟體產品中使用此原始碼 包括開放原始碼軟體中的 共用軟體可能會要求相關專利持有人的專利授權。
5.1. 媒體轉碼器
5.1.1.音訊編碼
詳情請參閱 5.1.3.音訊轉碼器詳細資料。
如果裝置實作方式宣告 android.hardware.microphone
它們「必須」支援將下列音訊格式編碼,以便提供
提供第三方應用程式存取權
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opu
所有音訊編碼器「必須」支援:
- [C-3-1] 透過
android.media.MediaCodec
使用 PCM 16 位元原生位元組順序音訊影格 也能使用 Google Cloud CLI 或 Compute Engine API
5.1.2.音訊解碼
詳情請參閱 5.1.3.音訊轉碼器詳細資料。
如果裝置導入方式宣告支援
android.hardware.audio.output
功能,必須支援
下列音訊格式:
- [C-1-1] MPEG-4 AAC 設定檔 (AAC LC)
- [C-1-2] MPEG-4 HE AAC 設定檔 (AAC+)
- [C-1-3] MPEG-4 HE AACv2 設定檔 (增強 AAC+)
- [C-1-4] AAC ELD (強化型低延遲 AAC)
- [C-1-11] xHE-AAC (ISO/IEC 23003-3 擴充 HE AAC 設定檔),內含 USAC 基準設定檔和 ISO/IEC 23003-4 動態範圍 控管設定檔)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] 麻省理工學院
- [C-1-8] Vorbis
- [C-1-9] PCM/WAVE 包含高解析度音訊 最高 24 位元、192 kHz 取樣率和 8 個頻道。 請注意,這項規定僅適用於解碼,且該作業是指 可在播放階段進行向下取樣和向下混音。
- [C-1-10] Opu
如果裝置導入方式支援解碼 AAC 輸入緩衝區,
從預設管道串流到 PCM
android.media.MediaCodec
API 中的 AAC 音訊解碼器必須符合以下條件
支援:
- [C-2-1] 必須執行解碼作業,才能進行解壓縮 (例如 5.0 AAC)。 串流必須解碼為五個 PCM 管道,5.1 AAC 串流必須解碼 高達六個管道)
- [C-2-2] 動態範圍中繼資料必須依照「動態範圍控制」中的定義
(剛果民主共和國),並將
android.media.MediaFormat
DRC 金鑰設為 設定音訊解碼器的動態範圍相關行為 AAC DRC 金鑰是在 API 21 中導入,如下所示:KEY_AAC_DRC_ATTENUATION_FACTOR
、KEY_AAC_DRC_BOOST_FACTOR
、KEY_AAC_DRC_HEAVY_COMPRESSION
、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
和KEY_AAC_ENCODED_TARGET_LEVEL
。 - [C-SR-1] 強烈建議你遵守上述要求 C-2-1 和 C-2-2 的規定 滿足所有 AAC 音訊解碼器的需求
解碼 USAC 音訊時,MPEG-D (ISO/IEC 23003-4):
- [C-3-1] 必須解讀及運用音量和 DRC 中繼資料 根據 MPEG-D DRC 動態範圍控制設定檔等級 1。
- [C-3-2] 解碼器「必須」根據設定
使用下列
android.media.MediaFormat
鍵進行設定:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
和KEY_AAC_DRC_EFFECT_TYPE
。
MPEG-4 AAC、HE AAC 和 HE AACv2 設定檔解碼器:
- 使用 ISO/IEC 23003-4 支援響度和動態範圍控制 動態範圍控制設定檔。
如果系統支援 ISO/IEC 23003-4,以及 ISO/IEC 23003-4 和 ISO/IEC 14496-3 中繼資料會以已解碼的位元流表示,然後:
- 優先採用 ISO/IEC 23003-4 中繼資料。
所有音訊解碼器「必須」支援輸出:
- [C-6-1] 透過
android.media.MediaCodec
使用 PCM 16 位元原生位元組順序音訊影格 也能使用 Google Cloud CLI 或 Compute Engine API
如果裝置導入方式支援解碼 AAC 輸入緩衝區,
從預設管道串流到 PCM
android.media.MediaCodec
API 中的 AAC 音訊解碼器,則「必須」
支援:
- [C-7-1] 應用程式必須能使用解碼功能進行設定
使用按鍵
KEY_MAX_OUTPUT_CHANNEL_COUNT
敬上 控制內容是否由立體聲調低混音為立體聲 (使用 2 的值時) 或是透過原生通道數輸出 (如果使用的值等於或 )。舉例來說,如果值設為 6 以上 解碼器,以便在提供 5.1 內容時輸出 6 個頻道。 - [C-7-2] 解碼時,解碼器「必須」宣傳所用的頻道遮罩
對輸出格式執行
KEY_CHANNEL_MASK
敬上 索引鍵,使用android.media.AudioFormat
常數 (例如:CHANNEL_OUT_5POINT1
)。
如果裝置實作支援非預設 AAC 以外的音訊解碼器 音訊解碼器,且能夠輸出多聲道音訊 ( 2 個聲道),然後:
- [C-SR-2] 我們強烈建議使用解碼器設定解碼器
建構應用程式
KEY_MAX_OUTPUT_CHANNEL_COUNT
敬上 控制內容是否由立體聲調低混音為立體聲 (使用 2 的值時) 或是透過原生通道數輸出 (如果使用的值等於或 )。舉例來說,如果值設為 6 以上 解碼器,以便在提供 5.1 內容時輸出 6 個頻道。 - [C-SR-3] 解碼時,強烈建議使用解碼器來宣傳
使用
KEY_CHANNEL_MASK
敬上 鍵,使用 android.media.AudioFormat 常數 (例如:CHANNEL_OUT_5POINT1
)。
5.1.3.音訊轉碼器詳細資料
格式/轉碼器 | 詳細說明 | 支援的檔案類型/容器格式 |
---|---|---|
MPEG-4 AAC 設定檔 (AAC LC) |
支援標準級單聲道/立體聲/5.0/5.1 內容 取樣率從 8 至 48 kHz。 |
|
MPEG-4 HE AAC 設定檔 (AAC+) | 支援標準級單聲道/立體聲/5.0/5.1 內容 取樣率從 16 至 48 kHz。 |
|
MPEG-4 HE AACv2 設定檔 (加強型 AAC+) |
支援標準級單聲道/立體聲/5.0/5.1 內容 取樣率從 16 至 48 kHz。 |
|
AAC ELD (強化低延遲 AAC) | 支援採標準取樣率介於 16 至 16 之間的單聲道/立體聲內容 48 kHz。 |
|
美國運通 | 支援採用標準取樣率 7.35 的單聲道/立體聲內容 高達 48 kHz | MPEG-4 (.mp4、.m4a) |
美國醫力軍 | 4.75 到 12.2 kbps 取樣時 @ 8 kHz | 3GPP (.3gp) |
AMR-WB | 9 速率從每秒 6.60 kbit 到 23.85 kbit/s 取樣 @ 16 kHz,定義請見 AMR-WB,自動調整多速率音訊 - 寬頻語音轉碼器 | 3GPP (.3gp) |
FLAC | 編碼器和解碼器都至少要具備單聲道和立體模式 支援。必須支援高達 192 kHz 的取樣率;16 位元和 24 位元 解析度必須受支援。必須處理 FLAC 的 24 位元音訊資料 與浮點音訊設定搭配使用。 |
|
MP3 | 單聲道/立體聲 8 至 320 Kbps 常數 (CBR) 或可變位元率 (VBR) |
|
MIDI | MIDI 類型 0 和 1。DLS 第 1 版和第 2 版。XMF 和 Mobile XMF。支援: 鈴聲格式 RTTTL/RTX、OTA 和 iMelody |
|
Vorbis | 解碼:使用取樣功能支援單聲道、立體聲、5.0 和 5.1 內容
速率為 8000、12000、16000、24000 和 48000 Hz。 編碼:支援單聲道和立體聲內容,取樣率為 8000、12000、16000、24000 和 48000 Hz。 |
|
PCM/WAVE | PCM 轉碼器「必須」支援 16 位元線性 PCM 和 16 位元浮點值。華盛頓 擷取器必須支援 16 位元、24 位元、32 位元的線性 PCM 和 32 位元浮點值 (速率上限為硬體限制)。必須提供以下來源的取樣率: 8 kHz 至 192 kHz。 | WAVE (.wav) |
Opus | 解碼:支援單聲道、立體聲、5.0 和 5.1 內容
取樣率為 8000、12000、16000、24000 和 48000 Hz。
編碼:支援單聲道和立體聲內容 取樣率為 8000、12000、16000、24000 和 48000 Hz。 |
|
5.1.4。圖片編碼
詳情請參閱 5.1.6.圖片轉碼器詳細資料。
裝置導入方式「必須」支援下列圖片編碼編碼:
- [C-0-1] JPEG
- [C-0-2] PNG
- [C-0-3] WebP
如果裝置導入方式支援 HEIC 編碼 (透過 android.media.MediaCodec
)
媒體類型為 MIMETYPE_IMAGE_ANDROID_HEIC
,
他們會:
- [C-1-1] 必須提供硬體加速的 HEVC 編碼器,
支援「
BITRATE_MODE_CQ
」 位元率控制模式,HEVCProfileMainStill
並且畫面大小為 512 x 512 像素
5.1.5。圖片解碼
詳情請參閱 5.1.6.圖片轉碼器詳細資料。
裝置實作「必須」支援解碼下列圖片編碼:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] 原始
如果裝置導入方式支援 HEVC 影片解碼,就會: * [C-1-1] 必須支援 HEIF (HEIC) 圖片解碼。
支援高位元深度格式 (每個頻道 9 位元以上) 的圖片解碼器:
- [C-2-1] 必須依照下列要求,支援輸出 8 位元對等格式:
應用程式,例如透過
ARGB_8888
android.graphics.Bitmap
的設定
5.1.6.圖片轉碼器詳細資料
格式/轉碼器 | 詳細說明 | 支援的檔案類型/容器格式 |
---|---|---|
JPEG | 基準 + 漸進式 | JPEG (.jpg) |
GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
原始 | ARW (.arw)、CR2 (.cr2)、DNG (.dng)、NEF (.nef)、NRW (.nrw)、ORF (.orf)、 PEF (.pef)、RAF (.raf)、RW2 (.rw2)、SRW (.srw) | |
HEIF | 圖片、圖片集合、圖片序列 | HEIF (.heif)、HEIC (.heic) |
透過 MediaCodec API 公開的圖片編碼器和解碼器
[C-1-1] 必須支援 YUV420 8:8:8 彈性顏色 格式 (
COLOR_FormatYUV420Flexible
) 至CodecCapabilities
。[C-SR-1] 強烈建議為輸入介面支援 RGB888 色彩格式 模式。
[C-1-3] 必須支援至少一種平面或半平面 YUV420 8:8:8 顏色格式:
COLOR_FormatYUV420PackedPlanar
(等同於COLOR_FormatYUV420Planar
) 或COLOR_FormatYUV420PackedSemiPlanar
(相當於 至COLOR_FormatYUV420SemiPlanar
)。強烈建議各位提供支援 兩者。
5.1.7.視訊轉碼器
- 提供可接受的網路影片串流和視訊會議品質 服務、裝置導入方式 「必須」使用符合 requirements。
如果裝置實作包含影片解碼器或編碼器:
[C-1-1] 視訊轉碼器必須支援輸出和輸入位元組緩衝區大小 能容納最大可行的壓縮和未壓縮影格 但也不會過度分配
[C-1-2] 視訊編碼器和解碼器必須支援 YUV420 8:8:8 彈性色彩 格式 (
COLOR_FormatYUV420Flexible
) 至CodecCapabilities
。[C-1-3] 視訊編碼器和解碼器「必須」支援至少一個平面或解碼器 半平面 YUV420 8:8:8 顏色格式:
COLOR_FormatYUV420PackedPlanar
(相當於COLOR_FormatYUV420Planar
) 或COLOR_FormatYUV420PackedSemiPlanar
(相當於COLOR_FormatYUV420SemiPlanar
)。 因此強烈建議你同時支援這兩種格式。[C-SR-1] 極力建議您支援影片編碼器和解碼器 至少一種硬體最佳化平面或半平面 YUV420 8:8:8 色 格式 (YV12、NV12、NV21 或同等供應商的最佳化格式)。
[C-1-5] 支援高位元深度格式的影片解碼器 (每個通道 9 位元以上) 如果符合下列條件,則必須支援輸出 8 位元等值格式: 應用程式要求的所有憑證「必須」藉由支持 透過
android.media.MediaCodecInfo
使用 YUV420 8:8:8 色彩格式。
如果裝置實作方式透過以下方式宣傳 HDR 設定檔支援
Display.HdrCapabilities
、
他們會:
- [C-2-1] 必須支援 HDR 靜態中繼資料剖析及處理功能。
若裝置導入方式採用內部重新整理支援,可透過
MediaCodecInfo.CodecCapabilities
中的 FEATURE_IntraRefresh
類別,他們:
- [C-3-1] 必須支援 10 到 60 個影格的重新整理週期, 在設定的重新整理週期的 20% 內正確執行。
除非應用程式另行使用 KEY_COLOR_FORMAT
格式鍵、影片解碼器實作:
- [C-4-1] 必須預設使用針對硬體螢幕最佳化的顏色格式 如果使用 Surface 輸出進行設定
- [C-4-2] 必須預設使用針對 CPU 最佳化的 YUV420 8:8:8 色彩格式 設為不使用 Surface 輸出。
5.1.8。影片轉碼器清單
格式/轉碼器 | 詳細說明 | 支援的檔案類型/容器格式 |
---|---|---|
標題 263 |
|
|
H.264 AVC | 請參閱第 5.2 節 和 5.3 瞭解詳情 |
|
H.265 HEVC | 詳情請參閱第 5.3 節。 |
|
MPEG-2 | 主要個人資料 |
|
MPEG-4 SP |
|
|
VP8 | 請參閱第 5.2 節和 5.3 瞭解詳情 |
|
VP9 | 詳情請參閱第 5.3 節。 |
|
5.1.9。媒體轉碼器安全性
實作裝置「必須」符合媒體轉碼器安全性功能 說明。
Android 支援 OMX 跨平台多媒體加速 API 以及 Codec 2.0,這是一種低負載的多媒體加速 API。
如果裝置導入方式支援多媒體,就會執行以下動作:
- [C-1-1] 必須「必須」透過 OMX 或轉碼器 2.0 提供媒體轉碼器支援 Android 開放原始碼專案中的 API (或兩者皆用),且不會停用或 規避安全保護措施但這不表示 轉碼器「必須」使用支援 OMX 或 Codec 2.0 API 的 API, 系統「必須」提供多種 API,且「必須」支援可用的 API 內建安全防護機制
- [C-SR-1] 強烈建議你加入 Codec 2.0 API 的支援。
如果裝置的實作不支援 Codec 2.0 API,程式碼會:
- [C-2-1] 必須加入 Android 裝置對應的 OMX 軟體轉碼器 開放原始碼專案 (如有),適用於各種媒體格式和類型 (編碼器或解碼器)。
- [C-2-2] 名稱開頭為「OMX.google」的轉碼器。必須採用 取得了機器學習模型
- [C-SR-2] 強烈建議 OMX 軟體轉碼器在轉碼器中執行 這類程序無法存取記憶體對應工具以外的硬體驅動程式。
如果裝置實作支援 Codec 2.0 API,就會發生以下情形:
- [C-3-1] 必須加入 為各種媒體格式和類型提供的 Android 開放原始碼計畫 (如適用) (編碼器或解碼器)。
- [C-3-2] 必須將轉碼器 2.0 軟體轉碼器放入軟體轉碼器 「Android 開放原始碼計畫」所提供的程序, 能縮小授予軟體轉碼器的存取權
- [C-3-3] 名稱開頭為「c2.android」的轉碼器。必須採用 取得了機器學習模型
5.1.10。媒體轉碼器字元化
如果裝置導入方式支援媒體轉碼器,就會:
- [C-1-1] 「必須」透過
MediaCodecInfo
敬上 也能使用 Google Cloud CLI 或 Compute Engine API
請特別注意以下幾點:
- [C-1-2] 名稱開頭為「OMX」的轉碼器。必須使用 OMX API 且名稱符合 OMX IL 命名規範。
- [C-1-3] 名稱開頭為「c2」的轉碼器。必須使用 Codec 2.0 API 名稱符合 Android Codec 2.0 命名規範。
- [C-1-4] 名稱開頭為「OMX.google」的轉碼器。或「c2.android」。必須 「不得」稱為供應商或硬體加速。
- [C-1-5] 在轉碼器程序 (供應商或系統) 中執行的轉碼器,具有 必須「不得」存取記憶體配置器和對應工具以外的硬體驅動程式 而是純軟體。
- [C-1-6] 轉碼器不存在於 Android 開放原始碼計畫中,或不存在 「必須」視為供應商。
- [C-1-7] 必須定義使用硬體加速的轉碼器 硬體加速
- [C-1-8] 轉碼器名稱不得誤導使用者。例如名為 「解碼器」必須能夠支援解碼功能,以及名為「編碼器」的檔案須提供支援 編碼。名稱包含媒體格式的轉碼器「必須」支援這些格式 格式。
如果裝置導入方式支援視訊轉碼器:
- [C-2-1] 所有影片轉碼器「必須」發布可達成的畫面更新率資料 以下是轉碼器支援的大小:
SD 標準畫質 (低品質) | SD 標準畫質 (高品質) | HD 高畫質 720p | HD 高畫質 1080p | UHD 超高畫質 | |
---|---|---|---|---|---|
影片解析度 |
|
|
|
1920 x 1080 px (不包括 MPEG4) | 3840 x 2160 px (HEVC,VP9) |
- [C-2-2] 採用硬體加速的視訊轉碼器
發布效能點資訊這些資料欄必須逐一支援
標準表現點 (列在
PerformancePoint
中) API)。 - 此外,如果能提升廣告成效,則須提供 則可維持影片成效,而超越上述其中一種標準。
5.2.影片編碼
如果裝置導入方式支援任何影片編碼器,且提供 他們會:
- 不應,超過兩個滑動窗,超過位元率 15% 之間的間隔。
- 比滑動窗口的位元率不應超過 100% 設為 1 秒
如果裝置實作項目中含有
對角線長度至少 2.5 吋,或是視訊輸出連接埠
透過 android.hardware.camera.any
宣告支援相機
就會:
- [C-1-1] 必須包含至少一部 VP8 或 H.264 影片的支援功能 以供第三方應用程式使用
- 應同時支援 VP8 和 H.264 影片編碼器,並提供給 第三方應用程式的功能
如果裝置實作支援任何 H.264、VP8、VP9 或 HEVC 影片 提供給第三方應用程式使用,它們會:
- [C-2-1] 必須支援動態可設定的位元率。
- 應支援可變的畫面更新率,影片編碼器應 瞬息萬變的影格持續時間 (依據輸入緩衝區的時間戳記)。 並根據該影格持續時間分配位元值區
如果裝置實作支援 MPEG-4 SP 影片編碼器,並為其設定 提供給第三方應用程式使用,具有以下優點:
- 應支援為支援的編碼器動態設定位元率。
如果裝置實作提供硬體加速視訊或圖片編碼器,
並支援一或多個連接或可插式硬體攝影機,以
android.camera
API:
- [C-4-1] 必須支援所有硬體加速視訊和影像編碼器 擷取來自硬體鏡頭的編碼影格
- 應支援硬體相機中所有影片的編碼影格 或圖片編碼器
如果裝置實作方式提供 HDR 編碼,就會:
- [C-SR-1] 極力建議您為 以及能從 HDR 格式轉換為 SDR 格式。
5.2.1。標題 263
如果裝置實作方式支援 H.263 編碼器,且可供使用 他們會:
- [C-1-1] 必須支援基準設定檔第 45 級。
- 應支援為支援的編碼器動態設定位元率。
5.2.2。H.264
如果裝置的實作支援 H.264 轉碼器,就會:
- [C-1-1] 必須支援基準設定檔第 3 級。 但支援 ASO (任意 Slice 排序)、FMO (彈性) 「巨集封鎖順序」) 和 RS (備援配量) 為選用項目。此外,前往 保持與其他 Android 裝置的相容性,因此建議使用 編碼器不會將 ASO、FMO 和 RS 用於基準設定檔,
- [C-1-2] 必須支援 SD (標準畫質) 影片編碼設定檔 下表。
- 應支援第 4 級主要設定檔。
- 應支援 HD (高畫質) 影片編碼設定檔; 請參閱下表。
如果裝置導入方式回報支援 720p 或 1080p 的 H.264 編碼 透過媒體 API 解析度影片,可以:
- [C-2-1] 必須支援下表中的編碼設定檔。
SD 標準畫質 (低品質) | SD 標準畫質 (高畫質) | HD 高畫質 720p | HD 高畫質 1080p | |
---|---|---|---|---|
影片解析度 | 320 x 240 像素 | 720 x 480 像素 | 1280 x 720 像素 | 1920 x 1080 像素 |
影片畫面更新率 | 20 fps | 30 fps | 30 fps | 30 fps |
視訊位元率 | 384 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.3.VP8
如果裝置導入方式支援 VP8 轉碼器,就會:
- [C-1-1] 必須支援 SD 影片編碼設定檔。
- 應支援下列 HD (高畫質) 影片編碼設定檔。
- [C-1-2] 必須支援編寫 Matroska WebM 檔案。
- 應提供符合 WebM 專案 RTC 硬體編碼規定,以確保 品質尚可、網路影片串流和視訊會議服務品質等。
如果裝置導入方式回報支援 720p 或 1080p 的 VP8 編碼 透過媒體 API 解析度影片,可以:
- [C-2-1] 必須支援下表中的編碼設定檔。
SD 標準畫質 (低品質) | SD 標準畫質 (高畫質) | HD 高畫質 720p | HD 高畫質 1080p | |
---|---|---|---|---|
影片解析度 | 320 x 180 像素 | 640 x 360 像素 | 1280 x 720 像素 | 1920 x 1080 像素 |
影片畫面更新率 | 30 fps | 30 fps | 30 fps | 30 fps |
視訊位元率 | 800 Kbps | 2 Mbps | 4 Mbps | 10 Mbps |
5.2.4。VP9
如果裝置導入方式支援 VP9 轉碼器,就會:
- [C-1-2] 必須支援個人資料 0 第 3 級。
- [C-1-1] 必須支援編寫 Matroska WebM 檔案。
- [C-1-3] 必須產生 CodecPrivate 資料。
- 「應該」支援 HD 編碼解碼設定檔,如下表所示。
- [C-SR-1] 極力建議支援 HD 解碼設定檔 如果有硬體編碼器,請參照下表。
SD 標準畫質 | HD 高畫質 720p | HD 高畫質 1080p | UHD 超高畫質 | |
---|---|---|---|---|
影片解析度 | 720 x 480 像素 | 1280 x 720 像素 | 1920 x 1080 像素 | 3840 x 2160 像素 |
影片畫面更新率 | 30 fps | 30 fps | 30 fps | 30 fps |
視訊位元率 | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
如果裝置的實作方式聲稱支援設定檔 2 或設定檔 3,請前往 媒體 API:
- 支援 12 位元格式。
5.2.5。標題 265
如果裝置實作支援 H.265 轉碼器,就會:
- [C-1-1] 必須支援主要設定檔第 3 級。
- 「應該」支援 HD 高畫質編碼設定檔,如下表所示。
- [C-SR-1] 極力建議支援 HD 編碼設定檔 如果有硬體編碼器,請參照下表。
SD 標準畫質 | HD 高畫質 720p | HD 高畫質 1080p | UHD 超高畫質 | |
---|---|---|---|---|
影片解析度 | 720 x 480 像素 | 1280 x 720 像素 | 1920 x 1080 像素 | 3840 x 2160 像素 |
影片畫面更新率 | 30 fps | 30 fps | 30 fps | 30 fps |
視訊位元率 | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
5.3.影片解碼
如果裝置實作支援 VP8、VP9、H.264 或 H.265 轉碼器,則代碼如下:
- [C-1-1] 必須支援動態影片解析度和畫面更新率切換功能 所有 VP8、VP9 等所有 VP8 均屬標準 Android API。 H.264 和 H.265 轉碼器,且最高支援最高解析度 。
5.3.1。MPEG-2
如果裝置實作支援 MPEG-2 解碼器,就會:
- [C-1-1] 必須支援主要設定檔高階裝置。
5.3.2。標題 263
如果裝置實作支援 H.263 解碼器,就會:
- [C-1-1] 必須支援基準設定檔第 30 級和第 45 級。
5.3.3.MPEG-4
如果裝置使用 MPEG-4 解碼器,它們:
- [C-1-1] 必須支援簡易設定檔層級 3。
5.3.4。H.264
如果裝置實作支援 H.264 解碼器,就會:
- [C-1-1] 必須支援主要設定檔層級 3.1 和基準設定檔。支援 適用於 ASO (任意配量排序)、FMO (彈性巨集排序) 和 RS (多餘配量) 為 OPTIONAL。
- [C-1-2] 必須能使用 SD 標準畫質將影片解碼 (Standard Definition) 設定檔清單列於下表,並使用基準設定檔進行編碼 以及主要設定檔層級 3.1 (包括 720p30)
- 應能夠將具有 HD (高畫質) 設定檔的影片解碼 ,如下表所示。
如果 Display.getSupportedModes()
方法回報的高度為
等於或大於影片解析度、裝置導入方式:
- [C-2-1] 必須支援在下列情況下支援 HD 高畫質 720p 影片解碼設定檔 表格。
- [C-2-2] 必須支援下列內容的 HD 高畫質 1080p 影片解碼設定檔 表格。
SD 標準畫質 (低品質) | SD 標準畫質 (高畫質) | HD 高畫質 720p | HD 高畫質 1080p | |
---|---|---|---|---|
影片解析度 | 320 x 240 像素 | 720 x 480 像素 | 1280 x 720 像素 | 1920 x 1080 像素 |
影片畫面更新率 | 30 fps | 30 fps | 60 fps | 30 fps (60 fps電視) |
視訊位元率 | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.5。H.265 (HEVC)
如果裝置實作支援 H.265 轉碼器,就會:
- [C-1-1] 必須支援主要設定檔等級 3 的主要等級和 SD 影片 ,如下表所示。
- 「應該」支援 HD 編碼解碼設定檔,如下表所示。
- [C-1-2] 必須支援下列 HD 高畫質解碼設定檔 使用硬體解碼器
如果 Display.getSupportedModes()
方法回報的高度為
等於或大於影片解析度,則:
- [C-2-1] 裝置導入作業至少必須支援 H.265 或 VP9 之一 720、1080 和 UHD 超高畫質設定檔
SD 標準畫質 (低品質) | SD 標準畫質 (高畫質) | HD 高畫質 720p | HD 高畫質 1080p | UHD 超高畫質 | |
---|---|---|---|---|---|
影片解析度 | 352 x 288 像素 | 720 x 480 像素 | 1280 x 720 像素 | 1920 x 1080 像素 | 3840 x 2160 像素 |
影片畫面更新率 | 30 fps | 30 fps | 30 fps | 30/60 fps (60 fps,採用 H.265 硬體解碼的電視) | 60 fps |
視訊位元率 | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
如果裝置的實作方式宣稱能透過媒體支援 HDR 設定檔 API:
- [C-3-1] 裝置的實作「必須」接受從以下來源取得的 HDR 中繼資料: 並支援擷取及輸出必要的 HDR 技術 從 Bitstream 和/或容器上傳
- [C-3-2] 裝置實作「必須」正確顯示 或標準視訊輸出連接埠 (例如HDMI)。
5.3.6。VP8
如果裝置導入方式支援 VP8 轉碼器,就會:
- [C-1-1]「必須」支援下表中的 SD 解碼設定檔。
- 請務必使用符合 requirements。
- 應支援下表中的 HD 高畫質解碼設定檔。
如果 Display.getSupportedModes()
方法回報的高度相等
或大於影片解析度,則:
- [C-2-1] 實作裝置必須「必須」支援 720p 設定檔 資料表。
- [C-2-2] 裝置實作必須支援 資料表。
SD 標準畫質 (低品質) | SD 標準畫質 (高畫質) | HD 高畫質 720p | HD 高畫質 1080p | |
---|---|---|---|---|
影片解析度 | 320 x 180 像素 | 640 x 360 像素 | 1280 x 720 像素 | 1920 x 1080 像素 |
影片畫面更新率 | 30 fps | 30 fps | 30 fps (60 fps電視) | 30 (60 fps電視) |
視訊位元率 | 800 Kbps | 2 Mbps | 8 Mbps | 20 Mbps |
5.3.7。VP9
如果裝置導入方式支援 VP9 轉碼器,就會:
- [C-1-1] 必須支援 SD 影片解碼設定檔,如 資料表。
- 「應該」支援 HD 編碼解碼設定檔,如下表所示。
如果裝置實作支援 VP9 轉碼器和硬體解碼器:
- [C-2-1] 必須支援下列 HD 高畫質解碼設定檔 表格。
如果 Display.getSupportedModes()
方法回報的高度為
等於或大於影片解析度,則:
- [C-3-1] 裝置導入作業至少必須支援 VP9 或 H.265 中的一項 720、1080 和 UHD 超高畫質設定檔
SD 標準畫質 (低品質) | SD 標準畫質 (高畫質) | HD 高畫質 720p | HD 高畫質 1080p | UHD 超高畫質 | |
---|---|---|---|---|---|
影片解析度 | 320 x 180 像素 | 640 x 360 像素 | 1280 x 720 像素 | 1920 x 1080 像素 | 3840 x 2160 像素 |
影片畫面更新率 | 30 fps | 30 fps | 30 fps | 30 fps (採用 VP9 硬體解碼的電視) | 60 fps |
視訊位元率 | 600 Kbps | 1.6 Mbps | 4 Mbps | 5 Mbps | 20 Mbps |
如果裝置的實作方式宣稱支援 VP9Profile2
或 VP9Profile3
透過 'CodecProfileLevel'
媒體 API:
- 支援 12 位元格式。
如果裝置的實作方式宣稱支援 HDR 設定檔 (VP9Profile2HDR
,
VP9Profile2HDR10Plus
、VP9Profile3HDR
、VP9Profile3HDR10Plus
) 透過
媒體 API:
- [C-4-1] 裝置實作「必須」接受必要的 HDR 中繼資料
(
KEY_HDR_STATIC_INFO
)。 它會顯示所有 HDR 設定檔 「KEY_HDR10_PLUS_INFO」 供 HDR10Plus 設定檔使用) 應用程式。也「必須」支援 從位元流和/或容器取得 HDR 中繼資料。 - [C-4-2] 裝置實作「必須」正確顯示 或標準視訊輸出連接埠 (例如HDMI)。
5.3.8。Dolby Vision
如果裝置實作方式宣告支援 Dolby Vision 解碼器
HDR_TYPE_DOLBY_VISION
敬上
,他們:
- [C-1-1] 必須提供支援 Dolby Vision 的擷取器。
- [C-1-2] 必須在裝置螢幕上正確顯示 Dolby Vision 內容,或 安裝在標準影片輸出連接埠上 (例如HDMI)。
- [C-1-3] 必須設定曲目 ID 回溯相容基礎層 (如有) 與 也就是 Dolby Vision 層的軌跡 ID
5.3.9。AV1
如果裝置實作支援 AV1 轉碼器,就會:
- [C-1-1] 必須支援 Profile 0,其中包含 10 位元內容。
5.4.音訊錄製
雖然本節介紹的一些規定已列為必須 自 Android 4.3 起,我們計劃針對日後的版本進行相容性定義 改為「必須」變更現有和新 Android 裝置強烈 建議以符合「應」」列出的這些條件,或者 日後升級到未來版本時,將無法達到 Android 相容性 版本。
5.4.1。原始音訊擷取和麥克風資訊
如果裝置實作項目宣告 android.hardware.microphone
,就會:
[C-1-1] 必須允許針對以下項目擷取原始音訊內容 任何已開啟的
AudioRecord
或AAudio
INPUT 串流 「必須」至少支援以下特性:- 格式:線性 PCM、16 位元
- 取樣率:8000、11025、16000、44100、48000 Hz
- 聲道:單聲道
- 音訊來源:
DEFAULT
、MIC
,CAMCORDER
,VOICE_RECOGNITION
、VOICE_COMMUNICATION
、UNPROCESSED
、 或VOICE_PERFORMANCE
。 這也適用於AAudio
中的同等輸入預設設定, (例如:AAUDIO_INPUT_PRESET_CAMCORDER
)。
應使用以下格式擷取原始音訊內容 特性:
- 格式:線性 PCM、16 位元和 24 位元
- 取樣率:8000、11025、16000、22050、24000、32000、44100、 48000 Hz
- 聲道:鏡頭組麥克風的數量和頻道數量一樣多 裝置
[C-1-2] 必須以上述取樣率擷取,不要向上取樣。
[C-1-3] 當 上述取樣率會以降低取樣率呈現。
應允許 AM 無線電和 DVD 品質擷取原始音訊內容, 意味著下列特性:
- 格式:線性 PCM、16 位元
- 取樣率:22050、48000 Hz
- 頻道:立體聲
[C-1-4] 必須遵循
MicrophoneInfo
API 並正確填入裝置的可用麥克風資訊 由第三方應用程式存取AudioManager.getMicrophones()
API (適用於主動式錄音工具)MediaRecorder.AudioSources DEFAULT
、MIC
、CAMCORDER
、VOICE_RECOGNITION
、VOICE_COMMUNICATION
、UNPROCESSED
或VOICE_PERFORMANCE
。
如果裝置支援 AM 無線電和 DVD 品質擷取原始音訊 讓他們:
- [C-2-1] 拍攝時,除非取樣率高於任何比例 16000:22050 或 44100:48000。
- [C-2-2] 在任何向上取樣時,都必須加入適當的反鋸齒濾鏡 或降低取樣率
5.4.2。擷取以辨識聲音
如果裝置實作項目宣告 android.hardware.microphone
,就會:
- [C-1-1] 必須擷取
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
音訊來源,位置: 其中一個取樣率是 44100 和 48000 - [C-1-2] 必須在以下情況下,預設停用雜訊抑制音訊處理作業
錄製「
AudioSource.VOICE_RECOGNITION
」音訊的音訊串流 來源。 [C-1-3] 開始錄製時,必須預設停用所有自動增益控制項 來自「
AudioSource.VOICE_RECOGNITION
」音訊來源的音訊串流。應展現近似寬鬆與頻率特性 中頻段值:特別是從 100 Hz 到 4000 Hz 的 ±3dB 和用來錄製語音辨識音訊來源的每個麥克風
[C-SR-1] 強烈建議 [C-SR-1] 在低點 頻率範圍:特別是從 30 Hz 至 100 Hz 的 ±20 dB 每個用於錄音的麥克風音頻範圍 辨識音訊來源
[C-SR-2] 強烈建議 [C-SR-2] 在高處展現振幅 頻率範圍:特別是從 4000 Hz 到 22 KHz 的 ±30 dB, 每個用於錄音的麥克風音頻範圍 辨識音訊來源
應設定音訊輸入靈敏度,讓 1000 Hz 單調色調來源 音量為 90 dB 時 (測量在麥克風旁邊) 會產生 RMS 2500 的理想回覆,範圍介於 1770 到 3530 以 16 之間 位元樣本 (或 -22.35 db ±3dB 全體重計,浮點/雙精度浮點數) 樣本) 音訊來源。
應錄製語音辨識音訊串流,以調整 PCM 的振動 水平追蹤輸入 SPL 變化幅度至少介於 -18 之間 (至少 30 dB) dB 到 +12 dB re 90 dB SPL 麥克風。
應以全諧音波錄製語音辨識音訊 1 kHz 的變形 (THD) 低於 1% (以 90 dB SPL 輸入等級為基準) 麥克風。
如果裝置實作方式宣告 android.hardware.microphone
和雜訊
專為語音辨識而調整的抑制 (縮減) 技術,它們:
- [C-2-1] 必須允許使用者透過
android.media.audiofx.NoiseSuppressor
API。 - [C-2-2] 必須明確識別每種雜訊抑制技術
透過
AudioEffect.Descriptor.uuid
欄位進行實作
5.4.3.擷取用於重新規劃路線的拍攝畫面
android.media.MediaRecorder.AudioSource
類別包含 REMOTE_SUBMIX
音訊來源。
如果裝置實作程序同時宣告 android.hardware.audio.output
和
android.hardware.microphone
,他們:
[C-1-1] 必須正確實作
REMOTE_SUBMIX
音訊來源, 當應用程式使用android.media.AudioRecord
API 記錄這個事件時 音訊來源,會擷取所有音訊串流的混合內容,但以下情況除外:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4。聲學回聲消除器
如果裝置實作項目宣告 android.hardware.microphone
,就會:
- 應導入無聲電子學取消工具
(AEC) 技術經過調整,適用於語音通訊,並會套用至擷取路徑。
以
AudioSource.VOICE_COMMUNICATION
擷取。
如果裝置導入方式提供聲學電子訊號取消工具,
在 AudioSource.VOICE_COMMUNICATION
時插入擷取音訊路徑
將會:
- [C-SR-1] 是 STRONGLY_RECOMMENDED 透過 AcousticEchoCanceler 宣告這項資訊 API 方法 AcousticEchoCanceler.isAvailable()
- [C-SR-2] 可 STRONGLY_RECOMMENDED 可使用 AcousticEchoCanceler 控制 也能使用 Google Cloud CLI 或 Compute Engine API
- [C-SR-3] 能 STRONGLY_RECOMMENDED 識別各項 AEC 技術 您可以透過 AudioEffect.Descriptor.uuid ] 欄位。
5.4.5。並行擷取
如果裝置實作程序宣告了 android.hardware.microphone
,就「必須」
請按照本文件的說明實作並行擷取。具體違規事項如下:
- [C-1-1] 必須允許無障礙設定並行存取麥克風
使用
AudioSource.VOICE_RECOGNITION
和至少一項服務進行擷取 並透過任何AudioSource
擷取應用程式 - [C-1-2] 預先安裝的應用程式必須允許並行存取麥克風
包含 Google 助理角色和至少一個應用程式
任何
AudioSource
擷取,但AudioSource.VOICE_COMMUNICATION
或AudioSource.CAMCORDER
。 - [C-1-3] 除非其他應用程式,否則一律必須將音訊擷取設為靜音
無障礙服務,此時應用程式擷取
AudioSource.VOICE_COMMUNICATION
或AudioSource.CAMCORDER
。不過,如果 有應用程式透過AudioSource.VOICE_COMMUNICATION
擷取,接著另一個應用程式 可透過具有特殊權限 (預先安裝) 的 權限CAPTURE_AUDIO_OUTPUT
。 - [C-1-4] 如果有兩個以上的應用程式同時擷取, 應用程式上方沒有 UI,也就是最近開始擷取的 接收音訊。
5.4.6。麥克風提升等級 [已移至 5.4.2]
5.5.音訊播放
Android 提供的支援功能,可讓應用程式透過音訊播放音訊 輸出週邊裝置 (如第 7.8.2 節所述)。
5.5.1。原始音訊播放
如果裝置實作項目宣告 android.hardware.audio.output
,就會:
[C-1-1] 必須允許播放符合下列規定的原始音訊內容 特性:
- 來源格式:線性 PCM、16 位元、8 位元、浮點值
- 聲道:單聲道、立體聲、有效的多頻道設定 最多 8 個頻道
- 取樣率 (以 Hz 為單位):
- 8000、11025、16000、22050、24000、32000、44100、48000 的頻道 上方列出的設定
- 96000 單聲道和立體聲
5.5.2。音效
Android 提供音效 API 以便進行裝置導入作業
如果裝置實作方式宣告了 android.hardware.audio.output
功能,
他們會:
- [C-1-1] 必須支援
EFFECT_TYPE_EQUALIZER
和EFFECT_TYPE_LOUDNESS_ENHANCER
實作可透過 AudioEffect 子類別Equalizer
和LoudnessEnhancer
。 - [C-1-2] 必須支援視覺化工具 API 實作,且可透過
Visualizer
類別。 - [C-1-3] 必須支援
EFFECT_TYPE_DYNAMICS_PROCESSING
導入作業 可透過 AudioEffect 子類別DynamicsProcessing
控制。 - 應支援
EFFECT_TYPE_BASS_BOOST
、EFFECT_TYPE_ENV_REVERB
、EFFECT_TYPE_PRESET_REVERB
和EFFECT_TYPE_VIRTUALIZER
實作 可透過AudioEffect
子類別BassBoost
控制EnvironmentalReverb
、PresetReverb
和Virtualizer
。 - [C-SR-1] 強烈建議支援浮點和 多通路
5.5.3.音訊輸出音量
Automotive 裝置實作:
- 應允許調整音訊音量
根據定義的內容類型或使用方式,在每個音訊串流中單獨處理
製作者:
AudioAttributes
和車輛音訊使用情形 (定義請見android.car.CarAudioManager
)。
5.5.4。音訊卸載
如果裝置的導入方式支援音訊卸載播放,就會:
- [C-SR-1] 強烈建議你剪輯已播放的無聲音訊內容 是由 AudioTrack 無差異 API 以及 MediaPlayer 的媒體容器
5.6.音訊延遲時間
音訊延遲是指音訊訊號通過系統的時間延遲。 許多類型的應用程式都仰賴短的延遲時間來即時 音效
為達成本節目的,請使用下列定義:
- 輸出延遲。應用程式寫入影格之間的間隔 以及在遊戲中呈現相應聲音時 或該信號會經由 並可對外觀察
- 冷輸出延遲。從開始輸出串流和 第一個影格的顯示時間 (根據時間戳記) 系統一直處於閒置狀態,並且已關機。
- 連續輸出延遲。後續影格的輸出延遲時間 再開始播放音訊
- 輸入延遲。每次發出聲音的間隔時間 透過裝置端轉換器或訊號進入裝置 通訊埠,以及應用程式讀取 PCM 編碼資料的對應影格時。
- 輸入信號的初始部分,無法使用或 無法使用。
- 冷輸入延遲時間。從開始串流到啟動串流之間的所需時間 就會在音訊輸入系統處於閒置狀態時,收到第一個有效影格 在要求之前關閉電源。
- 連續輸入延遲。後續影格的輸入延遲時間 表示裝置正在擷取音訊。
- 連續往返延遲時間。持續輸入延遲時間總和 連續輸出延遲時間加上一個緩衝區。緩衝區空間 等待應用程式處理信號和等待時間,以減少階段 輸出與輸出串流之間的差異
- OpenSL ES PCM 緩衝區佇列 API。PCM 相關集合 OpenSL ES Android NDK 中的 API。
- AAudio 原生音訊 API。其中一組 AAudio API (位於 Android NDK 內)
- 時間戳記:一組內含相對影格位置的組合 以及該影格進入或離開頁面的預估時間 相關端點上的音訊處理管道其他參考資訊 AudioTimestamp。
- 音訊訊號中暫時中斷或樣本值不正確 通常是由 buffer underrun 負責輸出, 緩衝區或類比雜訊造成多餘
- 平均絕對偏差。計算函式時 與一組值平均值的差距。
- 感應式延遲。從輕觸螢幕到啟動所需要的時間 說話者聽到輕觸產生的音調。
如果裝置實作方式宣告了 android.hardware.audio.output
,
必須符合或超過下列規定:
- [C-1-1] 傳回的輸出時間戳記,
AudioTrack.getTimestamp
而
AAudioStream_getTimestamp
則是 +/- 2 毫秒。 [C-1-2] 冷輸出延遲時間為 500 毫秒 以下。
[C-1-3] 「必須」使用
AAudioStreamBuilder_openStream()
開啟輸出串流 只需要不到 1000 毫秒的時間
如果裝置實作項目宣告 android.hardware.audio.output
極力建議您符合下列規定:
- [C-SR-1] 喇叭資料回報冷輸出延遲時間為 100 毫秒或更短 路徑。
[C-SR-2] 觸控色調延遲時間為 80 毫秒以下。
[C-SR-4] 傳回的輸出時間戳記, AudioTrack.getTimestamp 而
AAudioStream_getTimestamp
則是 +/- 1 毫秒。
如果裝置導入方式符合上述規定,在初始 校正 (使用 AAudio 原生音訊 API) 持續輸出 至少使用一個支援音訊時的延遲時間和冷輸出延遲時間 則代表:
- [C-SR-5] 強烈建議透過宣告的方式,回報低延遲音訊
android.hardware.audio.low_latency
功能旗標。 - [C-SR-6] 強烈建議你符合低延遲需求條件 透過 AAudio API 處理音訊
- [C-SR-7] 強烈建議確保會傳回的串流
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
敬上 來自AAudioStream_getPerformanceMode()
,AAudioStream_getFramesPerBurst()
傳回的值。 小於或等於android.media.AudioManager.getProperty(String)
傳回的值 屬性鍵AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
。
如果裝置實作不符合低延遲音訊的需求條件 透過 AAudio 原生音訊 API 採取下列行動:
- [C-2-1] 「不得」回報支援低延遲音訊的相關支援。
如果裝置實作項目包含 android.hardware.microphone
,
必須符合下列輸入音訊規定:
[C-3-1] 限制輸入時間戳記中的錯誤,由 AudioRecord.getTimestamp 或
AAudioStream_getTimestamp
以 +/- 2 毫秒。 「錯誤」這裡是指與正確值的偏差。[C-3-2] 冷輸入延遲時間為 500 毫秒 以下。
[C-3-3] 必須使用「
AAudioStreamBuilder_openStream()
」開啟輸入串流 只需要不到 1000 毫秒的時間
如果裝置實作項目包含 android.hardware.microphone
,
強烈建議符合以下輸入音訊的規定:
[C-SR-8] 使用麥克風,冷輸入延遲時間不超過 100 毫秒 資料路徑
[C-SR-11] 限制輸入時間戳記中的錯誤,由 AudioRecord.getTimestamp 或
AAudioStream_getTimestamp
以 +/- 1 毫秒。
如果裝置實作方式宣告了 android.hardware.audio.output
並
android.hardware.microphone
,他們:
- [C-SR-12] 強烈建議採用「平均連續封包延遲時間」 計算 50 毫秒或更短時間超過 5 次時,提供平均絕對偏差 小於 10 毫秒,且至少需透過一個系統支援的路徑。
5.7.網路協定
裝置導入方式必須支援 媒體網路通訊協定 Android SDK 說明文件中所述的音訊和影片播放方法。
針對需要實作裝置的各項轉碼器和容器格式 支援,裝置導入方式:
[C-1-1] 必須支援 HTTP 和 HTTPS 的轉碼器或容器。
[C-1-2] 必須支援下列媒體區隔格式: 下方媒體區隔格式表格 HTTP 即時串流草稿通訊協定第 7 版。
[C-1-3] 必須支援對應的 RTSP 酬載格式,如 RTSP 表格。如有例外情形,請參閱 第 5.1 節。
媒體區隔格式
區隔格式 | 參考資料 | 必要的轉碼器支援 |
---|---|---|
MPEG-2 傳輸串流 | ISO 13818 |
視訊轉碼器:
以及 MPEG-2 音訊轉碼器:
|
採用 ADTS 取景和 ID3 代碼的 AAC | ISO 13818-7 | 請參閱第 5.1.1 節 ,進一步瞭解 AAC 及其變化版本 |
WebVTT | WebVTT |
RTSP (RTP、SDP)
設定檔名稱 | 參考資料 | 必要的轉碼器支援 |
---|---|---|
H264 AVC | RFC 6184 | 請參閱第 5.1.8 節。 瞭解 H264 AVC 的詳細資訊 |
MP4A-LATM | RFC 6416 | 請參閱第 5.1.3 節。 ,進一步瞭解 AAC 及其變化版本 |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
請參閱第 5.1.8 節。 瞭解有關 H263 的詳細資訊 |
263 至 2000 年 | RFC 4629 | 請參閱第 5.1.8 節。 瞭解有關 H263 的詳細資訊 |
AMR | RFC 4867 | 請參閱第 5.1.3 節。 瞭解 AMR-NB 的詳細資料 |
AMR-WB | RFC 4867 | 請參閱第 5.1.3 節。 取得 AMR-WB 的詳細資料 |
MP4V-西班牙語 | RFC 6416 | 請參閱第 5.1.8 節。 ,瞭解 MPEG-4 SP 詳細資料 |
mpeg4 泛型 | RFC 3640 | 請參閱第 5.1.3 節。 ,進一步瞭解 AAC 及其變化版本 |
MP2T | RFC 2250 | 詳情請參閱 HTTP 直播底下的 MPEG-2 傳輸串流 |
5.8.安全媒體
如果裝置導入方式支援安全視訊輸出,並能 支援多種安全介面
- [C-1-1] 必須宣告支援
Display.FLAG_SECURE
。
如果裝置實作項目宣告支援 Display.FLAG_SECURE
和支援
因此可以:
- [C-2-1] 必須使用加密嚴密的機制來保護連結安全,例如 適用於透過無線通訊協定連線的螢幕的 HDCP 2.x 以上版本。 像是 Miracast
如果裝置實作方式宣告支援 Display.FLAG_SECURE
和
支援有線外接螢幕,因此:
- [C-3-1] 必須支援所有連接的外接螢幕的 HDCP 1.2 以上版本 須透過使用者可用的有線連接埠
5.9.樂器數位介面 (MIDI)
如果裝置導入作業回報支援功能 android.software.midi
透過
android.content.pm.PackageManager
類別,他們:
[C-1-1] 必須針對所有支援 MIDI 的硬體傳輸元件支援 MIDI 可提供一般的非 MIDI 連線,且其傳輸方式為:
[C-1-2] 必須支援跨應用程式 MIDI 軟體傳輸功能 (虛擬 MIDI 裝置)
[C-1-3] 必須包含 libamidi.so (原生 MIDI 支援)
應支援第 7.7 節,透過 USB 週邊裝置模式支援 MIDI
5.10.專業音質
如果裝置導入結果回報支援功能
android.hardware.audio.pro
(透過
android.content.pm.PackageManager
類別,他們:
- [C-1-1] 必須回報功能支援
android.hardware.audio.low_latency
。 - [C-1-2] 必須設定連續往返音訊延遲,如 第 5.6 節音訊延遲,屬於 至少使用一個支援路徑的時間為 25 毫秒或更短。
- [C-1-3] 必須隨附支援 USB 主機模式和 USB 的 USB 連接埠 週邊裝置模式。
- [C-1-4] 必須回報支援
android.software.midi
功能。 - [C-1-5] 必須使用
AAudio 原生音訊
API 和
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
。 - [C-1-6] 冷輸出延遲時間不得超過 200 毫秒。
- [C-1-7] 冷輸入延遲時間不得超過 200 毫秒。
- [C-1-8] 輕觸手勢的平均延遲時間必須不超過 80 毫秒 至少 5 次測量喇叭對麥克風資料路徑的測量。
- [C-SR-1] 強烈建議符合本節定義的延遲時間 5.6 音訊延遲時間:20 毫秒或 少於 5 次測量,且平均絕對偏差小於 5 延遲時間
- [C-SR-2] 極力建議符合 Pro Audio 規定, 連續往返音訊延遲、冷輸入延遲和冷輸出 使用 AAudio 原生音訊 API 的延遲和 USB 音訊要求 執行 MMAP 路徑
[C-SR-3] 強烈建議採用一致的 CPU 等級 而在啟用音訊和 CPU 負載時,整體效能會有所不同。請進行測試 使用 Android 應用程式 SynthMark。 SynthMark 使用軟體合成器在模擬音訊架構中運作 用於測量系統效能詳情請參閱 SynthMark 說明文件 。合成馬克 應用程式是使用 「自動化測試」選項,並達到下列結果:
- Voicemark.90 >= 32 種語音
- etcmark.fixed.little <= 15 毫秒
- etcmark.dynamic.little <= 50 毫秒
應盡量減少音訊時鐘的準確度,以及相對於標準時間的偏移。
應盡量減少音訊時鐘相對於 CPU 的偏移
CLOCK_MONOTONIC
啟用後應盡量縮短裝置端轉換器的音訊延遲情形。
相較於 USB 數位音訊,應盡量縮短音訊延遲。
應記錄所有路徑的音訊延遲測量值。
應盡量減少音訊緩衝區完成回呼輸入時間時基誤差,因為 會影響回呼的可用完整 CPU 頻寬百分比。
應該在正常使用時回報延遲,避免發生音訊故障。
應呈現零的跨管道延遲時間差異。
應盡量減少所有傳輸中的 MIDI 平均延遲時間。
應盡量減少所有傳輸過程中負載 (如時基誤差) 的 MIDI 延遲時間變化。
所有傳輸作業都應提供準確的 MIDI 時間戳記。
應盡量減少使用裝置端變換器的音訊訊號雜訊,包括 冷啟動。
輸出端和輸出端之間的音訊時鐘差異應呈現零 相應的端點 (當兩者皆啟用時)。對應示例 端點包括裝置端麥克風和喇叭,或音訊插孔輸入端 輸出內容
應該處理輸入和輸出端的音訊緩衝區完成回呼 同一執行緒上相對應的端點,且輸入 會在輸入回呼傳回後立即觸發輸出回呼。或 如果無法在同一個執行緒上處理回呼,請輸入 進入輸入回呼後不久,就會輸出回呼,允許 確保輸入端和輸出端的時間一致
應盡量減少輸入音訊緩衝區之間的 HAL 音訊緩衝區差異 以對應端點為起點
應盡量縮短觸控延遲時間。
應盡量減少載入時觸控延遲時間的變化 (時基誤差)。
如果裝置的實作方式符合上述所有規定,就會:
- [C-SR-4] 強烈建議你回報功能相關支援資訊
android.hardware.audio.pro
(透過android.content.pm.PackageManager
) 類別
如果裝置實作項目包含 4 導體 3.5 公釐耳機插孔,則:
- [C-2-1] 必須設定平均連續往返音訊延遲時間,如 區段 5.6 音訊延遲時間 (20 毫秒以下)。 超過 5 個測量值,平均絕對偏差在 5 毫秒內 使用音訊回送連接器。
- [C-SR-5] 極力建議遵守 「行動裝置 (外插) 規格」部分 參閱有線音訊頭戴式裝置規格 (1.1 版)。
如果裝置實作方式省略 4 導電線 3.5 公釐耳機插孔, 納入支援 USB 主機模式的 USB 連接埠,您可以:
- [C-3-1] 必須實作 USB 音訊類別。
- [C-3-2] 必須設定下列的連續往返音訊延遲時間: 不超過 25 毫秒,超過 5 種測量平均絕對偏差 使用 USB 音訊類別的 USB 主機模式連接埠少於 5 毫秒。 (可使用 USB-3.5 公釐轉接頭和音訊回送功能進行測量) 使用連接器,或使用 USB 音訊介面搭配接線連接 輸出的內容)
- [C-SR-6] 強烈建議你最多同時支援 8 個 I/O 大會管道 每個方向、96 kHz 取樣率以及 24 位元或 32 位元深度 (如使用中) 以及支援這些需求的 USB 音訊週邊設備
- [C-SR-7] 強烈建議使用 MMAP 路徑上的 AAudio 原生音訊 API。
如果裝置導入作業設有 HDMI 連接埠,請檢查下列事項:
- 應支援立體聲輸出內容和八個聲道 (20 位元或 20 位元) 深度 24 位元和 192 kHz,沒有位元深度損失或重新取樣 至少一項資源
5.11.擷取尚未處理
Android 支援透過以下方式錄製未處理的音訊:
android.media.MediaRecorder.AudioSource.UNPROCESSED
個音訊來源。於
OpenSL ES,如要使用記錄預設設定存取這項服務
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
。
如果裝置實作意圖支援未處理的音訊來源,並做出 提供給第三方應用程式使用,具有以下特點:
[C-1-1] 請務必透過
android.media.AudioManager
回報支援 資源 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED。[C-1-2] 必須呈現近似平坦/與頻率的 中頻率範圍的特性:特別是從 ±10 dB 使用每個麥克風錄製未經處理的個別麥克風 (刷新率可達 100 Hz 至 7000 Hz) 音訊來源。
[C-1-3] 必須能夠以低頻率表現振幅 範圍:特別是從 5 z 至 100 Hz 的 ±20 dB 每個用來錄音的麥克風都屬於中音波 未處理的音訊來源
[C-1-4] 必須頻率高,才能顯示振幅 範圍:特別是從 7000 Hz 到 22 KHz 的 ±30 dB 每個用來錄音的麥克風都屬於中音波 未處理的音訊來源
[C-1-5] 必須設定音訊輸入靈敏度,以便讓 1000 Hz 單調 以 94 dB 聲音壓力水平 (SPL) 播放的語氣來源產生回應 16 位元樣本的 RMS 為 520 (16 位元取樣;如果是浮點/雙精度浮點數,則為 -36 dB 完整比例) 精確度範例), 音訊來源。
[C-1-6] 必須達到 60 dB 或更高的訊號雜訊比 (SNR) 。 (SNR 的測量結果是 94 dB SPL 與等值以下之間的差異) 自我噪音的 SPL、A 加權)。
[C-1-7] 總諧變形 (THD) 必須小於 1 kHZ 為 1%,而每個麥克風輸入層級為 90 dB SPL 輸入等級:1% 錄製未處理的音訊來源。
[C-1-8] 必須不具有任何其他訊號處理 (例如自動增益) 控制、高通濾器或回音消除) 等標準係數,讓等級能達到所需範圍。也就是說:
- [C-1-9] 如果架構中有任何信號處理, 必須要將其停用,並有效地造成零延遲或 因此信號路徑會額外延遲
- [C-1-10] 雖然可位於路徑中的等級係數,但不得 可能會導致訊號路徑發生延遲或延遲。
所有 SPL 測量結果都直接放在受測試的麥克風旁邊。 如果是多種麥克風設定,則必須符合下列需求條件: 每個麥克風。
如果裝置實作項目宣告了 android.hardware.microphone
,但未宣告
支援未處理的音訊來源,這些影片:
- [C-2-1] 必須針對
AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
傳回null
API 方法,正確指出缺乏支援功能。 - [C-SR-1] 仍廣受建議,可滿足大多數需求 來取得未處理記錄來源的信號路徑。
5.12.HDR 影片
Android 13 支援 HDR 技術,詳情請參閱後續說明文件。
像素格式
如果影片解碼器通告支援 COLOR_FormatYUVP010,則:
[C-1-1] 必須支援 CPU 讀取的 P010 格式 (ImageReader、MediaImage、 ByteBuffer)。在 Android 13 中,P010 會寬鬆,允許 Y 任意步長 和 UV 飛機
[C-1-2] P010 輸出緩衝區「必須」可供 GPU 取樣 (當 則是依 GPU_SAMPLING 用量分配)。如此一來,就能建立 GPU 組合和自訂 各個應用程式的色調對應功能
如果影片解碼器通告支援 COLOR_Format32bitABGR2101010,則應該:
- [C-2-1] 必須支援 RGBA_1010102 格式的輸出介面和 CPU 可讀取 (ByteBuffer 輸出內容)。
如果影片編碼器通告支援 COLOR_FormatYUVP010,就會:
- [C-3-1] 必須支援輸入介面和可寫入 CPU 的 P010 格式 (ImageWriter、MediaImage、ByteBuffer)。
如果影片編碼器通告支援 COLOR_Format32bitABGR2101010,請按照下列步驟操作:
- [C-4-1] 必須支援 RGBA_1010102 格式的輸入介面和可寫入 CPU (ImageWriter、ByteBuffer) 輸入內容。注意:在各種傳輸之間進行轉換 編碼器不需要使用曲線。
HDR 拍攝需求
針對支援 HDR 設定檔的所有影片編碼器,按照以下方式實作裝置:
[C-5-1] 不得假設 HDR 中繼資料是精確的。舉例來說, 編碼影格的像素可能超出峰值亮度,或 可能沒有代表影格的直方圖。
應匯總 HDR 動態中繼資料,以產生合適的 HDR 靜態資料 編碼串流的中繼資料,而且這些串流應會在每個結尾 編碼工作階段。
如果裝置的實作支援使用 CamcorderProfile API 進行 HDR 擷取 然後:
[C-6-1] 也必須支援透過 Camera2 API 拍攝 HDR 相片。
[C-6-2] 至少要支援 1 個硬體加速視訊編碼器, 的每個 HDR 技術
[C-6-3] 必須 (最低) 支援 HLG 擷取。
[C-6-4] 必須支援寫入 HDR 中繼資料 (如果適用於 HDR 影片) 錄製到擷取的影片檔案中。適用於 AV1、HEVC 和 DolbyVision 也就是將中繼資料納入編碼後的位元流。
[C-6-5] 必須支援 P010 和 COLOR_FormatYUVP010。
[C-6-6] 預設必須支援 HDR 轉 SDR 色調對應 硬體加速解碼器。也就是 如果裝置可以擷取 HDR10+ HEVC,則預設的 HEVC 解碼器必須能 ,以 SDR 形式解碼擷取的串流。
HDR 編輯需求條件
如果裝置實作包含支援 HDR 編輯功能的影片編碼器, 他們會:
- 產生 HDR 中繼資料時,應盡量縮短延遲時間。 也應該妥善處理有中繼資料 看似無害這些中繼資料必須精確 (例如 代表影格的實際峰值亮度和直方圖)。
如果裝置導入方式包含支援 FEATURE_HdrEditing 的轉碼器,則 這些轉碼器:
[C-7-1] 必須支援至少一個 HDR 設定檔。
[C-7-2] 凡是透過廣告宣傳的 HDR 設定檔,都必須支援 FEATURE_HdrEditing 該轉碼器。換句話說,在執行相同要求的情況下,這類檔案「必須」支援產生 HDR 中繼資料 則不會。
[C-7-3] 必須支援下列完整版影片編碼器輸入格式 如何保留已解碼的 HDR 訊號:
- 兩個輸入的 RGBA_1010102 (已位於目標轉乘曲線中) 同時,請「務必」向廣告客戶 COLOR_Format32bitABGR2101010。
如果裝置導入方式包含支援 FEATURE_HdrEditing 的轉碼器,則 裝置:
- [C-7-4] 必須廣告支援 EXT_YUV_target OpenGL 擴充功能。
6. 開發人員工具與選項的相容性
6.1.開發人員工具
裝置實作方式:
- [C-0-1] 必須支援 Android 中提供的 Android 開發人員工具 將機器學習工作流程自動化
-
- [C-0-2] 必須支援 Android SDK 和殼層中記錄的 ADB
以及 Android 開放原始碼計劃中提供的指令,供應用程式開發人員使用
包含
dumpsys
cmd stats
- [C-0-11] 必須支援殼層指令
cmd testharness
。升級中 沒有 永久資料區塊「可能」不受 C-0-11 的規範。 - [C-0-3] 不得變更裝置系統的格式或內容 事件 (batterystats 、diskstats、Fingerprint、graphicstats、netstats、 透過 dumpsys 指令記錄通知、procstats
- [C-0-10] 必須錄影、確保內容不遺漏,以及於後續活動
可供
cmd stats
殼層指令和StatsManager
系統 API 類別。- ActivityForegroundState 已變更
- 偵測到異常狀況
- 已回報的應用程式導覽標記
- 應用程式當機
- AppStart 發生
- 電池等級已變更
- BatterySaverModeState 已變更
- BleScanResultReceived
- BleScanState 已變更
- ChargingState 已變更
- DeviceIdleModeState 已變更
- 前景服務狀態已變更
- GpsScanState 已變更
- 工作狀態已變更
- PluggedState 已變更
- 已排程工作狀態已變更
- 畫面狀態已變更
- SyncState 已變更
- SystemElapsedRealtime
- UidProcessState 已變更
- WakelockState 已變更
- 喚醒鬧鐘發生次數
- WifiLockState 已變更
- WifiMulticastLockState 已變更
- WifiScanState 已變更
- [C-0-4] 裝置端 ADB Daemon 必須預設為停用, 「必須」具備可供使用者存取的機制,才能開啟 Android 偵錯功能 橋樑。
- [C-0-5] 必須支援安全 ADB。Android 內建安全功能 ADB。安全 ADB 可在已知的驗證主機上啟用 ADB。
- [C-0-6] 必須提供機制,讓 ADB 能夠從外部伺服器 託管機器具體違規事項如下:
如果裝置的實作方式在沒有 USB 連接埠的情況下支援週邊裝置模式,則會造成:
- [C-3-1] 必須透過區域區域網路 (例如乙太網路) 實作 ADB 或 Wi-Fi)。
- [C-3-2] 必須提供 Windows 7、8 和 10 的驅動程式, 以便使用 ADB 通訊協定 連接裝置
如果裝置實作支援透過 Wi-Fi 或乙太網路:
- [C-4-1] 必須採用
AdbManager#isAdbWifiSupported()
方法 傳回true
。
如果裝置實作支援透過 Wi-Fi 或乙太網路 至少包括一部相機:
- [C-5-1] 必須採用
AdbManager#isAdbWifiQrSupported()
方法 傳回true
。
- [C-0-2] 必須支援 Android SDK 和殼層中記錄的 ADB
以及 Android 開放原始碼計劃中提供的指令,供應用程式開發人員使用
包含
-
- [C-0-7] 必須支援 Android SDK 中記錄的所有 ddms 功能。 由於 ddms 會使用 ADB,因此預設會停用 ddms 的支援功能,但 在使用者啟用 Android Debug Bridge、 。
-
- [C-0-9] 必須支援 Android SDK 中所述的 systrace 工具。 Systrace 必須預設為停用,且使用者可以存取 啟用 Systrace
-
- [C-SR-1] 強烈建議你公開呈現
/system/bin/perfetto
cmdline 會符合 Perfetto 說明文件。 - [C-SR-2] 極力建議接受 Perfetto 二進位檔案。 符合 Perfetto 說明文件。
- [C-SR-3] Perfetto 二進位檔強烈建議以輸出內容形式寫入 符合 Perfetto 說明文件。
- [C-SR-4] 強烈建議使用 Perfetto 二進位檔案提供 Perfetto 說明文件中至少描述的資料來源。
- [C-SR-1] 強烈建議你公開呈現
-
- [C-0-12] 必須將
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom 寫入 應用程式因低記憶體終止工具而終止時的統計資料記錄。
- [C-0-12] 必須將
測試控管工具模式 如果裝置實作支援殼層指令
cmd testharness
和 執行cmd testharness enable
,它們:- [C-2-1] 必須傳回
true
ActivityManager.isRunningInUserTestHarness()
- [C-2-2] 必須按照 測試控管模式說明文件。
- [C-2-1] 必須傳回
GPU 工作資訊
裝置實作方式:
- [C-0-13] 必須實作殼層指令
dumpsys gpu --gpuwork
才能顯示power/gpu_work_period
核心傳回的匯總 GPU 工作資料 追蹤記錄點,如果不支援追蹤點,則不顯示任何資料。Android 開放原始碼計畫 實作為frameworks/native/services/gpuservice/gpuwork/
。
- [C-0-13] 必須實作殼層指令
如果裝置導入方式透過
android.hardware.vulkan.version
功能旗標,可以:
- [C-1-1] 「必須」提供可供應用程式開發人員啟用/停用的預設工具 GPU 偵錯圖層
- [C-1-2] 「必須」啟用 GPU 偵錯圖層時,列舉 由外部工具提供的程式庫 (例如,非平台或 應用程式套件)設為 支援 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。
6.2.開發人員選項
Android 支援開發人員設定應用程式 開發相關設定
導入裝置時,「必須」為 「開發人員選項」的用途:
- [C-0-1] 必須尊重 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖顯示應用程式開發相關設定。上游 Android 根據預設,系統會隱藏開發人員選項選單,讓使用者 在「設定」> 上按下七 (7) 次後,啟動開發人員選項 關於裝置 >「Build Number」選單項目。
- [C-0-2] 預設必須隱藏開發人員選項。
- [C-0-3] 必須提供明確機制,讓 以待開發人員 選項。「必須」提供公開可見的文件或網站,說明如何 啟用開發人員選項。這份文件或網站必須連結至 Android SDK 文件
- 在「開發人員」時應持續向使用者顯示視覺通知 選項已啟用,且使用者安全無虞。
- 可能會暫時限制「開發人員選項」選單的存取權 隱藏或停用選單,以免在 使用者的安全有顧慮
7. 硬體相容性
如果裝置包含特定硬體元件 第三方開發人員適用的 API:
- [C-0-1] 裝置實作「必須」實作 Android SDK 說明文件中所述的 API 設定。
如果 SDK 中的 API 會與宣稱為選用的硬體元件互動 裝置實作方式不具備該元件:
- [C-0-2] 完成元件的類別定義 (如 SDK 所記錄) 您仍須提供 API。
- [C-0-3] API 的行為「必須」在合理範圍內實作為免人工管理 。
- [C-0-4] 在 SDK 允許的情況下,API 方法「必須」傳回空值 說明文件。
- [C-0-5] API 方法「必須」傳回含有空值的類別免人工管理實作 根據 SDK 說明文件的用途建立政策。
- [C-0-6] API 方法「不得」擲回 SDK 未記錄的例外狀況 說明文件。
- [C-0-7] 裝置的實作方式必須持續回報準確的硬體裝置
透過
getSystemAvailableFeatures()
和 中的hasSystemFeature(String)
方法 android.content.pm.PackageManager 類別。
符合這些規定的典型例子就是電話通訊系統 API:即使在手機以外的裝置上,仍必須以合理的方式實作這些 API 免人工管理。
7.1.顯示和圖形
Android 內含自動調整應用程式資產和 UI 的功能 為裝置設定合適的版面配置,確保第三方應用程式 適用於多種硬體設定。 支援所有第三方 Android 相容螢幕的 Android 相容螢幕 應用程式才能順利執行,但裝置的實作「必須」正確實作這些 API 和行為
本節中規定所參照的單位定義如下:
- 實際對角線大小。兩個對手之間的距離 (以英寸為單位) 螢幕亮起部分的角落。
- 每英寸像素數 (dpi)。以線性方式包入的像素數量 水平或垂直範圍為 1」。列出 dpi 值時,皆是橫向 且垂直 dpi 必須落在範圍之內
- 顯示比例。長尺寸與 縮短螢幕尺寸例如,480x854 像素的螢幕 為 854/480 = 1.779 或大約「16:9」。
- 密度獨立像素 (dp)。虛擬像素單位正規化為 160 dpi 螢幕,計算方式為:像素 = dps * (密度/160)。
7.1.1.畫面設定
7.1.1.1。螢幕大小和形狀
Android UI 架構支援多種不同的邏輯畫面版面配置
大小,並讓應用程式查詢目前設定的螢幕
版面配置大小 (透過 Configuration.screenLayout
搭配 SCREENLAYOUT_SIZE_MASK
)
和 Configuration.smallestScreenWidthDp
。
裝置實作方式:
[C-0-1] 必須回報正確的
Configuration.screenLayout
,如 Android SDK 說明文件中所定義。 具體來說,裝置導入方式必須「必須」回報正確的邏輯 密度獨立像素 (dp) 螢幕尺寸,如下所示:Configuration.uiMode
設為任何其他值的裝置 UI_MODE_TYPE_WATCH,並回報small
Configuration.screenLayout
,必須至少為 426 dp x 320 dp。- 回報
Configuration.screenLayout
大小為normal
的裝置, 不得小於 480 dp x 320 dp。 - 回報
Configuration.screenLayout
大小為large
的裝置, 不得小於 640 dp x 480 dp。 - 回報
Configuration.screenLayout
大小為xlarge
的裝置, 不得小於 960 dp x 720 dp。
[C-0-2] 必須正確遵循申請書」說明 透過 <
supports-screens
> 支援螢幕大小 屬性,如 AndroidManifest.xml 中的屬性 。「可能」具備與 Android 相容的螢幕(圓角設計)。
如果裝置實作方式支援 UI_MODE_TYPE_NORMAL
,並納入
與 Android 相容的螢幕,採圓角設計,如下所示:
[C-1-1] 必須確認至少符合下列一項規定 滿足:
- 圓角的半徑小於或等於 38 dp。
- 將 15 dp x 15 dp 的方塊固定在邏輯的每個角落 螢幕,每個方塊至少要有一個像素。
應提供使用者需求,以改用 長方形邊角
如果裝置導入方式包含 Android 相容螢幕, 可折疊式裝置,或是在多個螢幕面板之間加入折疊轉軸 可用於轉譯第三方應用程式的螢幕,功能如下:
- [C-2-1] 「必須」導入最新的可用穩定版本 擴充功能 API 或 sidecar API 的穩定版 由 Window Manager Jetpack 程式庫使用。
如果裝置導入方式包含 Android 相容螢幕, 摺疊式裝置,或是在多個顯示面板之間加入折疊轉軸 轉軸或摺疊會通過全螢幕應用程式視窗:
- [C-3-1] 必須回報轉軸或折疊位置的位置、邊界和狀態 或補充資訊 API
如要進一步瞭解如何正確實作補充資訊或擴充功能 API,請參閱 Window Manager Jetpack 的公開說明文件。
7.1.1.2。螢幕顯示比例
雖然
Android 相容螢幕,也就是邏輯顯示器的顯示比例
其中顯示的網頁,可能是按高度和
透過 view.Display
回報的寬度值
API 和設定
API,必須符合下列規定:
[C-0-1]
Configuration.uiMode
設定的裝置實作方式為UI_MODE_TYPE_NORMAL
的顯示比例值必須小於或等於 變更為 1.86 (大約 16:9),除非應用程式符合下列任一條件 條件:- 應用程式已宣告支援更大的螢幕顯示比例
透過
android.max_aspect
中繼資料值。 - 應用程式會透過 android:resizeableActivity 宣告可調整大小 屬性。
- 應用程式指定 API 級別 24 以上版本,但未宣告
android:maxAspectRatio
敬上 限制支援的顯示比例。
- 應用程式已宣告支援更大的螢幕顯示比例
透過
[C-0-3]
Configuration.uiMode
設為Configuration.uiMode
的裝置實作方式UI_MODE_TYPE_WATCH
的顯示比例值必須設為 1.0 (1:1)。
7.1.1.3.螢幕密度
Android UI 架構會定義一組標準邏輯密度, 鎖定應用程式資源
[C-0-1] 根據預設,裝置導入作業「必須」只回報下列一種 清單列出的 Android 架構密度
DisplayMetrics
敬上 透過DENSITY_DEVICE_STABLE
API 且這個值「不得」隨時變動;不過,裝置可能會回報 設定不同的像素密度 使用者在初始設定後所進行的變更 (例如顯示大小) 啟動。裝置實作項目應定義標準 Android 架構密度 以數字表示最接近螢幕實際密度的數值 (除非是) 邏輯密度會導致回報的螢幕大小低於支援的下限。如果 標準 Android 架構密度 (與 表示螢幕尺寸必須小於最小 支援的相容螢幕大小 (320 dp 寬度),裝置導入作業必須 則會回報下一個最低標準 Android 架構密度。
如果有權變更裝置的顯示大小:
- [C-1-1] 顯示大小「不得」與原生密度的 1.5 倍或大於 1.5 倍 產生的有效最小螢幕尺寸小於 320 dp (相當於 變更為資源限定詞 sw320dp
- [C-1-2] 顯示大小「不得」小於原生密度的 0.85 倍。
- 為了保持良好的可用性並維持一致的字型大小,建議您
系統會提供下列原生多媒體廣告選項的縮放功能 (但必須遵守限制
以上說明)
- 小:0.85x
- 預設:1x (原生多媒體縮放比例)
- 大:1.15 倍
- 較大:1.3 倍
- 最大 1.45 倍
7.1.2.顯示指標
如果裝置導入方式包含 Android 相容螢幕,或 影片輸出到 Android 相容螢幕中,它們:
- [C-1-1] 必須針對所有 Android 相容螢幕回報正確的值
指標定義在
android.util.DisplayMetrics
API。
如果裝置實作項目不含內嵌畫面或影片輸出內容, 他們會:
- [C-2-1] 必須回報 Android 相容螢幕的正確值
android.util.DisplayMetrics
API 中的定義 ,以取得模擬的預設view.Display
。
7.1.3.螢幕方向
裝置實作方式:
- [C-0-1] 必須回報支援的螢幕方向
(
android.hardware.screen.portrait
和/或android.hardware.screen.landscape
),且至少必須回報一項支援的資料來源 方向。例如螢幕方向為固定橫向的裝置 螢幕 (例如電視或筆記型電腦) 僅「必須」 檢舉「android.hardware.screen.landscape
」。 - [C-0-2] 必須根據裝置目前情況回報正確的值
每次透過
android.content.res.Configuration.orientation
,android.view.Display.getOrientation()
或其他 API
如果裝置實作支援這兩種螢幕方向,就會發生以下情形:
- [C-1-1] 必須讓應用程式支援直向或橫向螢幕動態螢幕方向 方向。也就是說,裝置必須遵循應用程式針對特定螢幕的要求 方向。
- [C-1-2] 變更螢幕方向時,「不得」變更回報的螢幕大小或密度。
- 可選擇直向或橫向做為預設方向。
7.1.4。2D 和 3D 圖形加速
7.1.4.1 OpenGL ES
裝置實作方式:
- [C-0-1] 必須正確識別支援的 OpenGL ES 版本 (1.1、2.0、
3.0、3.1、3.2),或透過代管 API (例如透過
GLES10.getString()
方法) 和原生 API。 - [C-0-2] 必須納入所有對應的代管 API 的支援和 。
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
- [C-1-1] 必須同時支援 OpenGL ES 1.1 和 2.0,詳見完整說明 參閱 Android SDK 說明文件。
- [C-SR-1] 強烈建議你支援 OpenGL ES 3.1。
- 應支援 OpenGL ES 3.2。
OpenGL ES dEQP 測試會分割為數個測試清單,每個清單都有
相關聯的日期/版本號碼。這些位於以下的 Android 原始碼樹狀結構:
external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt
。符合以下條件的裝置
在自行回報等級的情況下支援 OpenGL ES,表示它能通過 dEQP
進行測試。
如果裝置實作支援任何 OpenGL ES 版本,就會:
- [C-2-1] 「必須」透過 OpenGL ES 代管 API 和原生 API 回報 其他已實作的 OpenGL ES 擴充功能,反之亦然 「不要」回報不支援的擴充功能字串。
- [C-2-2] 必須支援
EGL_KHR_image
、EGL_KHR_image_base
、EGL_ANDROID_image_native_buffer
、EGL_ANDROID_get_native_client_buffer
、EGL_KHR_wait_sync
、EGL_KHR_get_all_proc_addresses
、EGL_ANDROID_presentation_time
、EGL_KHR_swap_buffers_with_damage
、EGL_ANDROID_recordable
及EGL_ANDROID_GLES_layers
擴充功能。 - [C-2-3] 必須回報 OpenGL ES dEQP 測試最新版本
透過
android.software.opengles.deqp.level
功能旗標提供支援。 - [C-2-4] 至少必須支援 132383489 版 (自 2020 年 3 月 1 日起),
在
android.software.opengles.deqp.level
功能旗標中回報的。 - [C-2-5] 在各版本之間「必須」通過測試清單中的所有 OpenGL ES dEQP 測試
132383489,以及
android.software.opengles.deqp.level
功能旗標 (適用於每個支援項目) OpenGL ES 版本。 - [C-SR-2] 強烈建議你支援
EGL_KHR_partial_update
和OES_EGL_image_external
個擴充功能。 - 應透過
getString()
方法 (任何紋理) 準確回報 支援的壓縮格式,通常視供應商而定。 - 應支援
EGL_IMG_context_priority
和EGL_EXT_protected_content
個擴充功能。
如果裝置實作宣告支援 OpenGL ES 3.0、3.1 或 3.2,就會發生以下情形:
- [C-3-1] 「必須」匯出這些版本對應的函式符號 以及 libGLESv2.so 程式庫中的 OpenGL ES 2.0 函式符號。
- [C-SR-3] 強烈建議你支援
OES_EGL_image_external_essl3
。
如果裝置的實作支援 OpenGL ES 3.2,就會發生以下情形:
- [C-4-1] 必須完整支援 OpenGL ES Android 擴充功能包。
如果裝置實作支援 OpenGL ES Android 擴充功能套件, 他們可以:
- [C-5-1] 必須透過
android.hardware.opengles.aep
找出支援資訊 功能旗標
如果裝置實作項目公開對 EGL_KHR_mutable_render_buffer
的支援
可以使用:
- [C-6-1] 必須同時支援
EGL_ANDROID_front_buffer_auto_refresh
。
7.1.4.2 Vulkan
Android 支援 Vulkan ,這個低負載的跨平台 API,可用於進行高效能 3D 圖形。
如果裝置的實作支援 OpenGL ES 3.1,就會發生以下情形:
- [C-SR-1] 極力建議您加入對 Vulkan 1.3 的支援。
- [C-4-1]「不得」支援 Vulkan 變化版本版本 (即變化版本) 部分 Vulkan 核心版本的部分都必須為零)。
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
- [C-SR-2] 極力建議您加入對 Vulkan 1.3 的支援。
Vulkan dEQP 測試分成多個測試清單,每個清單都有
相關日期/版本這些位於以下的 Android 原始碼樹狀結構:
external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt
。符合以下條件的裝置
在自行回報的層級支援 Vulkan,表示 Vulkan 可以通過 dEQP
進行測試。
如果裝置實作項目支援 Vulkan 1.0 以上版本,程式碼就會:
- [C-1-1] 請務必回報正確的整數值
「
android.hardware.vulkan.level
」和「android.hardware.vulkan.version
」 功能旗標 - [C-1-2] 必須列舉,至少要有一個
VkPhysicalDevice
適用於 Vulkan 原生 APIvkEnumeratePhysicalDevices()
,直接在 Google Cloud 控制台實際操作。 - [C-1-3] 每個列舉項目都必須完全實作 Vulkan 1.0 API
VkPhysicalDevice
。 - [C-1-4] 請務必列舉包含在名為
位於應用程式套件的原生程式庫目錄中的
libVkLayer*.so
, 透過 Vulkan 原生 APIvkEnumerateInstanceLayerProperties()
和vkEnumerateDeviceLayerProperties()
,直接在 Google Cloud 控制台實際操作。 - [C-1-5] 不得列舉非實作
提供追蹤或攔截
Vulkan API (除非應用程式具有
android:debuggable
屬性) 已設為true
。 - [C-1-6] 請務必透過 Vulkan 原生 API,相反地「不得」回報擴充功能字串 他們無法妥善支援
- [C-1-7] 必須支援 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 的擴充功能。
- [C-1-8] 必須回報 Vulkan dEQP 測試的最高版本
透過
android.software.vulkan.deqp.level
功能旗標提供支援。 - [C-1-9] 至少必須支援
132317953
版 (自 2019 年 3 月 1 日起), 已回報在android.software.vulkan.deqp.level
功能旗標中。 - [C-1-10] 必須通過測試清單中的所有 Vulkan dEQP 測試,
版本
132317953
,以及android.software.vulkan.deqp.level
功能旗標。 - [C-1-11] 「不得」列舉對 VK_KHR_video_queue 的支援 VK_KHR_video_decode_Queue 或 VK_KHR_video_encode_Queue 擴充功能。
- [C-SR-3] 強烈建議你支援
VK_KHR_driver_properties
和VK_GOOGLE_display_timing
個擴充功能。 - 應支援
VkPhysicalDeviceProtectedMemoryFeatures
和VK_EXT_global_priority
。 - [C-1-12]「不得」列舉 VK_KHR_performance_query 擴充功能支援。
- [C-SR-4] 強烈建議你符合 Android Baseline 2021 設定檔
如果裝置實作項目不支援 Vulkan 1.0,那麼程式碼會:
- [C-2-1] 不得宣告任何 Vulkan 功能標記 (例如
android.hardware.vulkan.level
、android.hardware.vulkan.version
)。 - [C-2-2] 不得為 Vulkan 原生 API 列舉任何
VkPhysicalDevice
vkEnumeratePhysicalDevices()
。
如果裝置實作項目提供對 Vulkan 1.1 的支援,並宣告 Vulkan 功能旗標的作用如下:
- [C-3-1] 必須公開對
SYNC_FD
外部指示和控制代碼的支援 類型和VK_ANDROID_external_memory_android_hardware_buffer
副檔名
7.1.4.3 RenderScript
- [C-0-1] 裝置實作項目必須支援 Android RenderScript 。
7.1.4.4 2D 圖形加速
Android 提供一種機制,可讓應用程式宣告 在「應用程式」、「活動」、 使用資訊清單標記,就在視窗或資料檢視層級 android:hardwareAccelerated 或直接 API 呼叫
裝置實作方式:
- [C-0-1] 預設「必須」啟用硬體加速功能,且「必須」 如果開發人員透過設定 android:hardwareAccelerated="false" 或停用硬體加速 直接透過 Android View API
- [C-0-2] 行為違反 硬體加速的 Android SDK 說明文件。
Android 包含可讓開發人員直接整合的 TextureView 物件 硬體加速 OpenGL ES 紋理做為 UI 階層中的算繪目標。
裝置實作方式:
- [C-0-3] 必須支援 TextureView API,且必須 行為模式與上游 Android 實作方式一致
7.1.4.5 廣角螢幕
如果裝置實作方式聲稱支援廣域螢幕
Configuration.isScreenWideColorGamut()
,他們:
- [C-1-1] 必須採用色彩校正的螢幕。
- [C-1-2] 必須採用色調涵蓋 sRGB 色域的螢幕 完全是 CIE 1931 xyY 的空間。
- [C-1-3] 螢幕必須具有至少 90% 的面積 CIE 1931 xyY 空間中的 DCI-P3。
- [C-1-4] 必須支援 OpenGL ES 3.1 或 3.2 並妥善回報。
- [C-1-5] 請務必為
EGL_KHR_no_config_context
宣傳支援服務;EGL_EXT_pixel_format_float
、EGL_KHR_gl_colorspace
、EGL_EXT_gl_colorspace_scrgb
、EGL_EXT_gl_colorspace_scrgb_linear
、EGL_EXT_gl_colorspace_display_p3
、EGL_EXT_gl_colorspace_display_p3_linear
、 及EGL_EXT_gl_colorspace_display_p3_passthrough
。 - [C-SR-1] 強烈建議你支援
GL_EXT_sRGB
。
相反地,如果裝置實作項目不支援廣角螢幕,就會:
- [C-2-1] 在 CIE 1931 xyY 空間中,必須涵蓋 100% 以上的 sRGB 未定義螢幕色域。
7.1.5。舊版應用程式相容性模式
Android 會指定「相容性模式」,這個模式會在 「正常」相等螢幕尺寸相等 (320dp 寬度) 模式,結合多種優點 未針對舊版 Android 開發的應用程式 而且不受螢幕大小的獨立性
7.1.6。螢幕技術
Android 平台中的 API 可讓應用程式呈現豐富多樣的 投放至 Android 相容螢幕裝置必須支援下列所有 以 Android SDK 定義的 API (除非本文件特別許可)。
裝置實作方式的所有 Android 相容螢幕:
- [C-0-1] 必須能夠轉譯 16 位元色彩圖形。
- 應支援能夠顯示 24 位元色彩圖形的螢幕。
- [C-0-2] 必須能夠轉譯動畫。
- [C-0-3] 必須採用像素顯示比例 (PAR) 介於 0.9 到 1.15 之間也就是說,像素顯示比例必須接近正方形 (1.0),容忍度為 10 至 15%。
7.1.7.第二螢幕
Android 支援次要 Android 相容螢幕,以便啟用 媒體分享功能,以及用於存取外部螢幕的開發人員 API。
如果裝置的實作支援透過有線方式使用外接螢幕, 無線連線或嵌入式螢幕連線,這些技術可以:
- [C-1-1] 必須導入
DisplayManager
系統服務和 API
7.2.輸入裝置
裝置實作方式:
7.2.1。鍵盤
如果裝置導入方式提供第三方支援 輸入法編輯器 (IME) 應用程式:
- [C-1-1] 必須宣告
android.software.input_methods
功能旗標 - [C-1-2] 必須完全導入
Input Management Framework
- [C-1-3] 「必須」配有預先安裝的軟體鍵盤。
裝置實作方式:
- [C-0-1] 「不得」使用不符合 android.content.res.Configuration.keyboard 中指定的格式 (QWERTY 或 12 鍵)。
- 應加入其他螢幕鍵盤實作。
- 可提供實體鍵盤。
7.2.2。非觸控瀏覽
Android 支援 D-pad、軌跡球和滾輪做為 非觸控式瀏覽方式
裝置實作方式:
- [C-0-1] 必須回報 android.content.res.Configuration.navigation。
如果裝置的實作方式缺少非觸控式導覽,就會:
- [C-1-1] 「必須」提供合理的替代使用者介面機制, 文字選取和編輯功能,相容於輸入管理引擎。 上游 Android 開放原始碼實作包含選取機制 適用於沒有非觸控式瀏覽輸入裝置的裝置。
7.2.3.瀏覽鍵
「首頁」 近期、 和 Back 功能通常透過與專屬實體按鈕的互動提供 或觸控螢幕的獨立部分 導覽模式,因此的裝置導入方式:
- [C-0-1] 必須為使用者提供授權,以啟動已安裝的應用程式
包含具有
<intent-filter>
設定且ACTION=MAIN
和CATEGORY=LAUNCHER
或CATEGORY=LEANBACK_LAUNCHER
(適用於電視裝置) 。 首頁功能「必須」做為這項使用者預設用途的機制。 - 「應」提供「最近」和「返回」功能的按鈕。
如果有提供「首頁」、「最近使用」或「返回」功能,請按照下列步驟操作:
- [C-1-1] 必須讓使用者透過單一動作 (例如輕觸、按兩下或 畫面)。
- [C-1-2] 必須明確指出會觸發哪個單一動作 每個函式按鈕上顯示可見的圖示,顯示軟體 圖示,或是引導使用者逐步完成 在開箱即用的逐步教學流程中, 這類指標的範例
裝置實作方式:
[C-SR-1] 強烈建議不要為 選單函式 因為該版本已淘汰,並改用動作列,自 Android 4.0 版起取代。
[C-SR-2] 極力建議您根據 可取消。「可取消」一種是使用者能夠 導航功能停止執行 (例如返回首頁、返回等) 滑動手勢不會超過特定門檻。
如果裝置實作提供選單功能,就會:
- [C-2-1] 每當使用者執行動作時,都必須顯示動作溢位按鈕 溢位選單彈出式選單不是空白的,而且會顯示動作列。
- [C-2-2] 「不得」修改動作溢位彈出式視窗的位置 即可調整顯示效果,但選取動作列中的溢位按鈕後 動作溢位彈出式視窗出現在畫面中的修改位置 (如果有的話) 就可以看到選單
如果裝置實作項目未提供選單功能,
相容性:
* [C-3-1] 在
targetSdkVersion
小於 10,不論是透過實體按鈕、軟體金鑰還是
或手勢這個選單函式必須能與
其他導覽函式。
如果裝置導入方式提供輔助函式, 他們會:
- [C-4-1] 必須讓使用者透過單一動作存取輔助功能 時 (例如輕觸、按兩下或手勢)。
- [C-SR-3] 強烈推薦使用長按主畫面功能,因為 指派的互動方式
如果裝置導入方式獨立顯示 瀏覽鍵時,可以執行以下動作:
- [C-5-1] 瀏覽鍵「必須」使用畫面的一部分,不得 提供給應用程式,不得遮蓋或乾擾 可用的螢幕部分。
- [C-5-2] 必須向符合下列條件的應用程式提供螢幕的一部分畫面 符合第 7.1.1 節中定義的規定。
- [C-5-3] 必須遵循應用程式透過
View.setSystemUiVisibility()
所設定的旗標 API 方法,因此畫面的這個不同部分 (又稱為導覽列) 可正確隱藏,如文件所述 SDK。
如果系統以手勢動作的形式提供導覽功能:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
敬上 「必須」只用於回報主畫面手勢辨識區域。 - [C-6-2] 由
前景應用程式
View#setSystemGestureExclusionRects()
、 但位於WindowInsets#getMandatorySystemGestureInsets()
, 只要排除 矩形可超出排除數量上限 (如 說明文件View#setSystemGestureExclusionRects()
。 - [C-6-3] 必須傳送前景應用程式
MotionEvent.ACTION_CANCEL
敬上 系統手勢、輕觸事件開始攔截事件後, 如果前景應用程式先前MotionEvent.ACTION_DOWN
活動。 - [C-6-4] 必須提供使用者負擔,轉為在螢幕上 以按鈕為基礎的導覽 (例如,在「設定」中)。
- 「應」提供首頁功能,只要從手機底部邊緣向上滑動即可 目前的螢幕方向。
- 「最近」按下時,「最近」按鈕 只要向上滑動並按住 點選與「主畫面」手勢相同的區域
- 在
WindowInsets#getMandatorySystemGestureInsets()
敬上 不受前景提供的排除矩形影響 應用程式View#setSystemGestureExclusionRects()
。
是否從左側和右側邊緣的任何位置提供導覽函式 目前的螢幕方向:
- [C-7-1] 瀏覽功能「必須」返回,並以滑動手勢的方式提供 以及螢幕目前方向的左側和右側邊緣
- [C-7-2] 如果在左側提供自訂滑動系統面板,或是 務必放在畫面上方 1/3 的底部 清楚、持續性的視覺指示,拖曳會叫用 上述面板,因此不會返回。系統面板可能有 由使用者設定,因此到達畫面最上方的 1/3 處 但系統面板「不得使用」超過邊緣的 1/3 邊線。
- [C-7-3] 當前景應用程式有 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT,或 已設定 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 旗標, 從邊緣滑動的手勢 必須與 Android 開放原始碼計畫中的實作相同, 已列載於 SDK 中
- [C-7-4] 當前景應用程式有 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT,或 已設定 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 旗標, 自訂滑動系統面板必須隱藏,直到使用者進入或 取消延遲系統資訊列 (又稱為導覽列和狀態列) 。
如果提供返回瀏覽函式,且使用者取消返回 手勢,然後:
- [C-8-1] 必須呼叫
OnBackInvokedCallback.onBackCancelled()
。 - [C-8-2] 不得呼叫
OnBackInvokedCallback.onBackInvoked()
。 - [C-8-3] 「不得」分派 KEYCODE_BACK 事件。
如果提供返回瀏覽函式,但前景應用程式
「OnBackInvokedCallback
」尚未註冊,那麼:
- 系統「必須」為前景應用程式提供動畫 暗示使用者返回 Android 開放原始碼計畫。
如果裝置實作支援系統 API setNavBarMode
,即可
允許任何具有 android.permission.STATUS_BAR
權限的系統應用程式設定
導覽列模式,然後:
- [C-9-1] 必須支援適合兒童的圖示或按鈕式 使用 Android 開放原始碼計畫程式碼提供的導覽介面。
7.2.4。觸控螢幕輸入
Android 支援多種指標輸入系統,例如 觸控螢幕、觸控板和模擬觸控輸入裝置。 以觸控螢幕為基礎的裝置實作 與螢幕相關聯,方便使用者直接 操控螢幕上的項目由於使用者是直接觸碰螢幕 系統不需要任何其他用途 問題。
裝置實作方式:
- 應採用某種程度的指標輸入系統 (類似滑鼠或輕觸)。
- 應支援完全獨立追蹤的指標。
如果裝置實作項目提供觸控螢幕 (單點觸控或更優異), 主要 Android 相容螢幕,因此支援以下功能:
- [C-1-1] 必須回報
Configuration.touchscreen
的TOUCHSCREEN_FINGER
API 欄位。 - [C-1-2] 必須回報
android.hardware.touchscreen
和android.hardware.faketouch
功能旗標。
如果裝置導入方式包含觸控螢幕,可追蹤 只要在 Android 相容主要螢幕上輕觸一下,就能:
- [C-2-1] 必須回報適當的功能旗標
android.hardware.touchscreen.multitouch
,android.hardware.touchscreen.multitouch.distinct
、android.hardware.touchscreen.multitouch.jazzhand
對應裝置上特定觸控螢幕的類型。
如果裝置實作時需要使用外部輸入裝置,例如滑鼠或 在主要畫面輸入軌跡球 (即未直接觸碰螢幕) 與 Android 相容的螢幕,並符合 第 7.2.5 節,他們會:
- [C-3-1] 「不得」回報任何開頭為
android.hardware.touchscreen
。 - [C-3-2] 必須只回報
android.hardware.faketouch
。 - [C-3-3] 必須回報
TOUCHSCREEN_NOTOUCH
Configuration.touchscreen
API 欄位。
7.2.5。虛擬觸控輸入
虛假觸控介面提供使用者輸入系統,可近似一小部分 觸控螢幕功能。例如利用滑鼠或遙控器來駕駛 畫面上的遊標是概略觸控,但使用者必須第一個指向或 然後按一下焦點多種輸入裝置,例如滑鼠、觸控板、陀螺儀 空氣滑鼠、陀螺儀、搖桿和多點觸控板可支援 觸控互動Android 加入功能常數 android.hardware.faketouch,對應至高保真非觸控 (指標型) 輸入裝置,如滑鼠或觸控板, 模擬觸控式輸入 (包括基本手勢支援),並在 裝置支援模擬一部分的觸控螢幕功能。
如果裝置的實作方式沒有觸控螢幕,但提供其他觸控螢幕 供使用者使用的指標輸入系統:
- 應宣告支援
android.hardware.faketouch
功能標記。
如果裝置實作結果宣告支援 android.hardware.faketouch
,
他們會:
- [C-1-1] 必須回報 X 和 Y 的絕對位置 並在螢幕上顯示視覺指標。
- [C-1-2] 「必須」使用指定 指標上當機或上移 螢幕。
- [C-1-3] 必須讓畫面上的物件支援指標向下和向上, 可讓使用者模擬輕觸畫面上的物件
- [C-1-4] 必須支援向下、指標上、指標朝上,以及指標向上 會和畫面上某個物件在時間門檻內的相同位置 可讓使用者模擬輕觸兩下 螢幕上有一個物件
- [C-1-5] 必須支援在螢幕上任意位置朝下指標、 指標移至螢幕上任何其他點,後面接著指標 向上,可讓使用者模擬觸控拖曳功能。
- [C-1-6] 必須把支援指標向下移,然後讓使用者 拖曳到螢幕上的不同位置,然後將滑鼠遊標移到螢幕上的上方, 可讓使用者快速滑過畫面上的物件
如果裝置導入方式宣告支援
android.hardware.faketouch.multitouch.distinct
,他們:
- [C-2-1] 必須宣告支援
android.hardware.faketouch
。 - [C-2-2] 必須能夠針對兩個以上的獨立指標進行獨特追蹤 輸入內容
如果裝置導入方式宣告支援
android.hardware.faketouch.multitouch.jazzhand
,他們:
- [C-3-1] 必須宣告支援
android.hardware.faketouch
。 - [C-3-2] 必須支援 5 種不同軌跡 (追蹤手指) 或更多獨立指標輸入項目。
7.2.6。遊戲控制器支援
7.2.6.1。按鈕對應
裝置實作方式:
- [C-1-1] 必須能將 HID 事件對應至對應的
InputEvent
常數,如下表所示。Android 上游導入可符合這項規定。
如果裝置導入方式內嵌控制器或隨附獨立控制器,可供使用者輸入下表列出的所有事件,請注意:
- [C-2-1] 必須宣告功能標記
android.hardware.gamepad
按鈕 | HID 用量2 | Android 按鈕 |
---|---|---|
A1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
B1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
是1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
D-Pad 向上鍵1 D-Pad1 |
0x01 0x00393 | AXIS_HAT_Y4 |
D-Pad 左側1 D-Pad 向右鍵1 |
0x01 0x00393 | AXIS_HAT_X4 |
左肩按鈕1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
右肩按鈕1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
按一下左鍵1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
按一下滑鼠右鍵1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
背面1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 個 KeyEvent
2 必須在遊戲中宣告上述 HID 用法 填充 CA (0x01 0x0005)。
3 這個用法的邏輯下限為 0、 邏輯上限:7,實體下限為 0,實體最大實體 315 個,單位 ,報表大小為 4。邏輯值定義為 沿著垂直軸順時針旋轉;例如 0 表示沒有旋轉,按下向上按鈕,0 則代表邏輯值 1 代表旋轉 45 度,同時按下向上鍵和向左鍵 已按下。
類比控制項1 | HID 用量 | Android 按鈕 |
---|---|---|
離開觸發條件 | 0x02 0x00C5 | AXIS_LTRIGGER |
右側觸發條件 | 0x02 0x00C4 | AXIS_RTRIGGER |
左搖桿 | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
右搖桿 | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
1 個 MotionEvent
7.2.7。遙控器
請參閱 2.3.1 節,瞭解裝置專屬的需求。
7.3.感應器
如果裝置實作項目包含特定感應器類型, 以及供第三方開發人員使用的 API、裝置實作 「必須」按照 Android SDK 說明文件和 sensors 的 Android 開放原始碼說明文件。
裝置實作方式:
- [C-0-1] 必須根據
android.content.pm.PackageManager
敬上 類別 - [C-0-2] 「必須」透過
SensorManager.getSensorList()
和類似方法。 - [C-0-3] 必須對所有其他感應器 API (例如
當應用程式嘗試註冊時,適當傳回
true
或false
事件監聽器,而當對應的感應器不呼叫時,則不會呼叫感應器事件監聽器 存在;等)。
如果裝置實作項目包含特定感應器類型, 因此需要執行以下動作:
- [C-1-1] 必須回報所有感應器測量資料 建立每個事件的相關國際單位 (指標) 值 Android SDK 說明文件中定義的感應器類型。
- [C-1-2] 必須回報延遲時間最長 100 的感應器資料 毫秒 + 2 * sample_time: 應用程式處理器處於啟用狀態時,要求的最大延遲時間為 0 毫秒。 此延遲未包含任何篩選延遲。
- [C-1-3] 必須在 400 毫秒 + 2 內回報第一個感應器樣本 感應器啟動的 sample_time。此樣本可以接受 準確率為 0
- [C-1-4] Android SDK 說明文件指出的 API 必須為 連續感應器 裝置的實作「必須」持續提供 定期資料樣本的時基誤差必須低於 3% 其中,抖動的定義是指 連續事件之間的時間戳記值。
- [C-1-5] 必須確保感應器事件串流 「不得」阻止裝置 CPU 進入暫停狀態或喚醒 停止狀態
- [C-1-6] 必須回報活動時間 定義為奈秒,代表 事件發生的時間,並與 SystemClock.elapsedRealtimeNano() 時鐘。
- [C-SR-1] 強烈建議使用時間戳記同步處理錯誤 低於 100 毫秒,且應該發生時間戳記同步處理錯誤低於 1 幾毫秒
- 啟動多個感應器時,耗電量不應超過 個別感應器回報的耗電量總和。
上方清單僅列舉部分內容;記錄到的 Android SDK 行為 以及 Android 開放原始碼說明文件 感應器 具公信力
如果裝置實作項目包含特定感應器類型, 因此需要執行以下動作:
- [C-1-6] 必須為所有感應器設定非零的解析度,並回報值
透過
Sensor.getResolution()
API 方法。
某些感應器類型為複合類型,因此可從所提供的資料中衍生資料 再由一或多個其他感應器讀取資料(例如方向感應器和 線性加速感應器)。
裝置實作方式:
- 應實作這些感應器類型, 使用必要的實體感應器 感應器類型。
如果裝置實作項目內含複合感應器,請執行下列操作:
- [C-2-1] 必須按照 Android 開放原始碼中所述的方式實作感應器 複合感應器說明文件。
如果裝置實作項目包含特定感應器類型, 代表第三方開發人員的對應 API,而感應器只會回報一個 價值,然後採用裝置導入方式:
- [C-3-1] 必須將感應器的解析度設為 1,並回報值
透過
Sensor.getResolution()
API 方法。
如果裝置實作項目包含支援特定感應器類型 SensorAdditionalInfo#TYPE_VEC3_CALIBRATION 感應器提供給第三方開發人員,讓他們:
- [C-4-1] 「不得」加入任何固定的工廠判定校正結果 參數。
若裝置導入方式包含 3 軸式加速度計, 3 軸式迴轉儀感應器或磁力儀感應器,它們具有以下特性:
- [C-SR-2] 強烈建議使用確保加速計、陀螺儀和 磁力儀具有固定的相對位置,如果裝置 可變形 (例如折疊式裝置) 時,感應器軸會保持一致且一致 內建感應器座標系統,適用於各種可能的裝置 轉換狀態。
7.3.1。加速計
裝置實作方式:
- [C-SR-1] 強烈建議你加入 3 軸式加速度計。
如果裝置導入作業包含加速計,請按照下列步驟操作:
- [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
- [C-1-3] 必須遵守 Android 感應器座標系統 如 Android API 中所述
- [C-1-4] 必須能夠以自由落體到 4 倍的幅度 各軸的重心(4 公克) 以上。
- [C-1-5] 必須採用至少 12 位元的解析度。
- [C-1-6] 標準差不得大於 0.05m/s^,其中 標準差應以樣本數為基準來計算 收集超過 3 秒的資料收集期間,而且是最快的取樣率。
- 回報的事件大小必須至少為 200 Hz。
- 解析度至少要有 16 位元。
- 如果使用中的特性產生變化,則不應進行校正 生命週期和補償,並保留補償參數 。
- 應針對溫度獲得補償。
如果裝置導入方式包含 3 軸式加速度計,就會發生以下情形:
- [C-2-1] 必須導入及回報
TYPE_ACCELEROMETER
感應器。 - [C-SR-4] 強烈建議導入
TYPE_SIGNIFICANT_MOTION
複合感應器 - [C-SR-5] 極力建議導入及回報
TYPE_ACCELEROMETER_UNCALIBRATED
感應器。Android 裝置極度強大 建議符合這項規定,以便他們能升級至 。 - 應導入
TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
TYPE_STEP_COUNTER
Android SDK 文件所述的複合感應器。
如果裝置導入的加速計少於 3 軸,就會:
- [C-3-1] 必須導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES
感應器。 - [C-SR-6] 想要導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
感應器。
如果裝置導入方式包含 3 軸式加速度計和
TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
、
已實作 TYPE_STEP_COUNTER
複合感應器:
- [C-4-1] 兩者的耗電量總和必須小於 4 毫瓦。
- 裝置處於動態或動態時 靜態條件
如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀感應器, 他們會:
- [C-5-1] 必須導入
TYPE_GRAVITY
和TYPE_LINEAR_ACCELERATION
複合感應器。 - [C-SR-7] 極力建議您導入
TYPE_GAME_ROTATION_VECTOR
敬上 複合感應器
如果裝置導入方式包含 3 軸式加速度計、3 軸式迴轉儀感應器, 和磁力儀感應器進行以下操作:
- [C-6-1] 必須實作
TYPE_ROTATION_VECTOR
複合感應器。
7.3.2。磁力儀
裝置實作方式:
- [C-SR-1] 強烈建議你加入 3 軸的磁力計 (指南針)。
如果裝置實作方式包含 3 軸的磁力儀,將會:
- [C-1-1] 必須實作
TYPE_MAGNETIC_FIELD
感應器。 - [C-1-2] 必須能夠以至少 10 Hz 的頻率回報事件 ,並應該回報至少 50 Hz 的事件。
- [C-1-3] 必須符合 Android 感應器座標系統 如 Android API
- [C-1-4] 必須能夠個別測量介於 -900 μT 和 +900 μT 之間的距離 再進化。
- [C-1-5] 必須具有小於 700 μT 的硬鐵偏移值,而且必須 將磁力儀放在離 200 μT 以下的距離 動態 (目前誘發) 和靜態 (磁場誘發) 磁場。
- [C-1-6] 解析度必須等於或小於 0.6 μT。
- [C-1-7] 必須支援線上校準及補償硬鐵 並保留裝置重新啟動時的補償參數。
- [C-1-8] 「必須」使用軟鐵補償,校準程序可以 於使用期間或裝置生產過程中完成。
- [C-1-9] 必須設定標準差,並以各軸為基準來計算 收集期間至少 3 秒的樣本收集速度為最快的取樣 ,不得大於 1.5 μT;標準差不得大於 0.5 μT。
- [C-1-10] 必須導入
TYPE_MAGNETIC_FIELD_UNCALIBRATED
敬上 感應器。
如果裝置導入方式包含 3 軸式磁力計,就會有加速計 感應器和 3 軸式迴轉儀感應器,這些感應器具有以下功能:
- [C-2-1] 必須實作
TYPE_ROTATION_VECTOR
複合感應器。
如果裝置實作方式包含 3 軸式磁力計 (加速計),將會:
- 可實作
TYPE_GEOMAGNETIC_ROTATION_VECTOR
感應器。
如果裝置實作方式包括 3 軸式磁力計、加速計和
TYPE_GEOMAGNETIC_ROTATION_VECTOR
感應器,可以:
- [C-3-1] 耗電量必須低於 10 mW。
- 在批次模式註冊感應器的情況下,耗電量應小於 3 毫瓦 速度為 10 Hz
7.3.3.GPS
裝置實作方式:
- [C-SR-1] 強烈建議你加入 GPS/GNSS 接收器。
如果裝置實作包含 GPS/GNSS 接收器,並回報功能
透過 android.hardware.location.gps
功能旗標套用至應用程式,將:
- [C-1-1] 必須支援以至少 1 Hz 的速率輸出位置
已透過
LocationManager#requestLocationUpdate
要求。 - [C-1-2] 必須能夠判斷在空曠情況下的位置
在 10 秒內 (快速信號,多徑無阻,HDOP < 2)
每次修正時間) 連上 0.5 Mbps 或更快的數據速度
網際網路連線。使用部分應用程式就能符合這項規定。
輔助或預測 GPS/GNSS 技術形式
以縮短 GPS/GNSS 鎖定時間 (輔助資料包含參考時間、
參考地點和衛星/時鐘)。
- [C-1-6] 算出此類位置後,裝置 導入方式「必須」決定其在開放天空中、在 5 秒,再次提出位置資訊要求時,最多持續 1 小時 就算在後續要求中 未使用數據連線及/或重新開機後完成。
判斷地點後,在開放天際的環境中,靜止或靜止不動 移動的加速度小於每秒 1 公尺的平方:
- [C-1-3] 必須能夠判斷距離為 20 公尺且速度最快的位置 每秒 0.5 公尺,且至少需要 95% 的時間。
- [C-1-4] 必須同時透過以下方式追蹤及回報:
GnssStatus.Callback
敬上 至少 8 個衛星定位。 - 至少要能同時追蹤 24 個衛星、 多個星座 (例如 GPS 及至少 1 座鳳凰城的其中一顆 Galileo)。
[C-SR-2] 極力建議繼續提供正常 GPS/GNSS 緊急電話期間,透過 GNSS Location Provider API 取得位置資訊 呼叫。
[C-SR-3] 強烈建議 追蹤的星座(如 GnssStatus 訊息中報告),但例外 SBAS 系列
[C-SR-4] 強烈建議你回報 AGC 和 GNSS 的頻率 成效評估方式
[C-SR-5] 強烈建議提供所有準確率預估值 (包括方位、速度和垂直)。
[C-SR-6] 強烈建議你盡快記錄 GNSS 評估結果 或是 GNSS 計算出的位置 。
[C-SR-7] 強烈建議你回報 GNSS 虛擬範圍和 虛擬範圍比率,在判斷地點後 靜止不動或移動時 每秒不到 0.2 公尺的平方 足以計算出 20 公尺以內且速度 0.2 公尺以內,至少 95% 的時間
7.3.4。陀螺儀
裝置實作方式:
- [C-SR-1] 強烈建議你加入陀螺儀感應器。
如果裝置導入作業包含陀螺儀,這項功能會:
- [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
- [C-1-4] 必須採用 12 位元以上的解析度。
- [C-1-5] 必須計算溫度。
- [C-1-6] 使用時請務必進行校準與補償,並且保留 。
- [C-1-7] 每 Hz 的變異數不得超過 1e-7 rad^2 / s^2 (每 Hz 的變異數,或雷比^2 / 秒)。變異數則是以 但必須受到這個值限制。也就是說 以 1 Hz 的取樣率測量陀螺儀的變異數,不應大於 高於 1e-7 rad^2/s^2。
- [C-SR-2] 校正錯誤應一律小於 0.01 以上 裝置在室溫下靜止時移動
- [C-SR-3] 強烈建議採用 16 位元以上的解析度。
- 回報的事件大小必須至少為 200 Hz。
如果裝置實作方式包含 3 軸式迴轉儀,請按照下列步驟操作:
- [C-2-1] 必須實作
TYPE_GYROSCOPE
感應器。 - [C-SR-4] 強烈建議導入
TYPE_GYROSCOPE_UNCALIBRATED
感應器。
如果裝置實作的陀螺儀少於 3 軸,參數:
- [C-3-1] 必須導入及回報
TYPE_GYROSCOPE_LIMITED_AXES
感應器。 - [C-SR-5] 想要導入並回報相關情況
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
感應器。
如果裝置導入方式包含 3 軸式迴轉儀, 和磁力儀感應器進行以下操作:
- [C-4-1] 必須實作
TYPE_ROTATION_VECTOR
複合感應器。
如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀 感應器,因此會:
- [C-5-1] 必須導入
TYPE_GRAVITY
和TYPE_LINEAR_ACCELERATION
複合感應器 - [C-SR-6] 強烈建議你導入
TYPE_GAME_ROTATION_VECTOR
敬上 複合感應器
7.3.5。氣壓計
裝置實作方式:
- [C-SR-1] 強烈建議加上氣壓計 (環境氣壓) 感應器)。
如果裝置導入作業內含氣壓計,請按照下列步驟操作:
- [C-1-1] 必須導入及回報
TYPE_PRESSURE
感應器。 - [C-1-2] 必須能夠以 5 Hz 以上傳送事件。
- [C-1-3] 必須計算溫度。
- [C-SR-2] 強烈推薦能夠回報壓力測量值 介於 300hPa 至 1100hPa 之間
- 應有 1hPa 的絕對精確性。
- 應有 20hPa 範圍的 0.12hPa 相對準確度 (海拔 200 公尺的變動幅度達到約 100 萬的準確率值)。
7.3.6。測溫
如果裝置導入作業包括環境溫度計 (溫度感應器), 他們會:
- [C-1-1] 必須定義
SENSOR_TYPE_AMBIENT_TEMPERATURE
環境溫度感應器和感應器「必須」測量環境 (房間/車廂) 與使用者進行互動的位置 以攝氏度為單位。
如果裝置的實作方式附有溫度計感應器,可測量 溫度以外的溫度 (例如 CPU 溫度) 會進行以下動作:
- [C-2-1] 不得定義
SENSOR_TYPE_AMBIENT_TEMPERATURE
例如溫度感應器
如果裝置裝有可監控皮膚溫度的感應器, 然後:
- [C-SR-1] 強烈建議你 PowerManager.getThermalHeadroom 也能使用 Google Cloud CLI 或 Compute Engine API
7.3.7。相框模式
- 實作裝置可能包括光度感應器 (環境光度感應器),
7.3.8。鄰近感應器
- 實作裝置可能包含鄰近感應器。
如果裝置導入作業包含鄰近感應器,但系統只回報 二元性別讀數表示:
- [C-1-1] 測量物體與物體的距離時,應與 。換句話說,鄰近感應器必須朝向鄰近感應器才能偵測物體 因為這種感應器類型的主要用途 偵測使用者正在使用的手機如果裝置導入方式包含 其他方向的鄰近感應器,「不得」存取 透過這個 API
- [C-1-2] 準確度必須達到 1 位元以上。
- [C-1-3] 靠近讀數必須使用 0 公分, 讀取資料。
- [C-1-4] 請務必回報最大範圍和解析度為 5。
7.3.9。高保真感測器
如果裝置實作項目包含一組品質較高的感應器 (如定義) 並將這些內容提供給第三方應用程式,則這些應用程式具有以下特點:
- [C-1-1] 必須透過
android.hardware.sensor.hifi_sensors
功能旗標。
如果裝置實作方式宣告 android.hardware.sensor.hifi_sensors
他們會:
[C-2-1] 必須具備下列功能的
TYPE_ACCELEROMETER
感應器:- 測量範圍必須介於 -8 公克到 +8 公克之間,且為 強烈建議採用至少 -16 克的測量範圍 和 +16g
- 必須採用至少 2048 LSB/g 的測量解析度。
- 測量頻率不得低於 12.5 Hz。
- 測量頻率上限為 400 Hz 以上;應
支援 SensorDirectChannel
RATE_VERY_FAST
。 - 測量噪音必須超過 400 μg/√Hz。
- 必須導入這個感應器的非喚醒形式,才能使用緩衝區 至少可處理 3,000 個感應器事件
- 批次耗電量不得低於 3 毫瓦。
- [C-SR-1] 強烈建議使用 3dB 測量頻寬 至少 80% 的荷蘭頻率和白雜訊光譜 頻寬。
- 應在 室溫。
- 應該有偏誤變化,而不是溫度 ≤ +/- 1 毫克/°C。
- 應採用 ≤ 0.5% 且靈敏度變化與溫度變化 (與溫度 ≤ ) 的非線性 0.03%/C°。
- 跨軸敏感度應為 <2.5 % 和 跨軸靈敏度 <裝置作業溫度範圍介於 0.2% 之間。
[C-2-2] 必須具有相同的
TYPE_ACCELEROMETER_UNCALIBRATED
品質相關規定 (TYPE_ACCELEROMETER
)[C-2-3] 必須使用
TYPE_GYROSCOPE
感應器,才能執行以下操作:- 測量範圍必須至少介於 -1,000 到 +1000 dp。
- 測量解析度必須至少為 16 LSB/dp。
- 測量頻率不得低於 12.5 Hz。
- 測量頻率上限為 400 Hz 以上;應
支援 SensorDirectChannel
RATE_VERY_FAST
。 - 測量噪音必須超過 0.014°/s/√Hz。
- [C-SR-2] 強烈建議使用 3dB 測量頻寬 至少 80% 的荷蘭頻率和白雜訊光譜 頻寬。
- 應在房間內進行測試,且其隨機步行速度必須小於 0.001 °/s √Hz 溫度。
- 應該有偏誤變化,而不是溫度 ≤ +/- 0.05 °/ s / °C。
- 應有靈敏度變化,但溫度應為 ≤ 0.02% / °C。
- 應採用最佳適配線非線性性,且不超過 0.2%。
- 雜訊密度必須小於 0.007 °/s/√Hz。
- 校正錯誤應小於 0.002 雷/秒 裝置靜止時,溫度範圍為 10 ~ 40 °C。
- 應靈敏度小於 0.1°/s/g。
- 跨軸敏感度應為 <4.0 % 和跨軸敏感度 變化 <裝置作業溫度範圍介於 0.3% 之間。
[C-2-4] 必須具有品質相同的
TYPE_GYROSCOPE_UNCALIBRATED
定義TYPE_GYROSCOPE
要求。[C-2-5] 必須使用
TYPE_GEOMAGNETIC_FIELD
感應器,才能執行以下操作:- 測量範圍必須至少介於 -900 到 +900 μT 之間。
- 必須採用至少 5 LSB/uT 的測量解析度。
- 測量頻率不得低於 5 Hz。
- 測量頻率上限為 50 Hz 以上。
- 測量噪音必須超過 0.5 uT。
[C-2-6] 必須具有品質相同的
TYPE_MAGNETIC_FIELD_UNCALIBRATED
須滿足TYPE_GEOMAGNETIC_FIELD
的需求,以及下列項目:- 必須導入這個感應器的非喚醒形式,才能使用緩衝區 至少支援 600 個感應器事件
- [C-SR-3] 強烈建議使用白噪音頻譜 (1 Hz 到 1 Hz) 回報率為 50 Hz 或更高時,至少 10 Hz。
[C-2-7] 必須具備下列功能的
TYPE_PRESSURE
感應器:- 測量範圍必須介於 300 到 1100 hPa 之間。
- 必須採用至少 80 LSB/hPa 的測量解析度。
- 測量頻率不得低於 1 Hz。
- 測量頻率上限為 10 Hz。
- 測量噪音必須不能超過 2 Pa/√Hz。
- 必須導入這個感應器的非喚醒形式,才能使用緩衝區 至少支援 300 個感應器事件
- 批次耗電量不得低於 2 mW。
[C-2-8] 必須搭配
TYPE_GAME_ROTATION_VECTOR
感應器。[C-2-9] 必須使用
TYPE_SIGNIFICANT_MOTION
感應器,才能執行以下操作:- 裝置處於以下狀態時,耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。
[C-2-10] 必須搭載
TYPE_STEP_DETECTOR
感應器,才能執行以下操作:- 必須導入這個感應器的非喚醒形式,才能使用緩衝區 至少支援 100 個感應器事件
- 裝置處於以下狀態時,耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。
- 批次耗電量不得低於 4 mW。
[C-2-11] 必須搭載下列
TYPE_STEP_COUNTER
感應器:- 裝置處於以下狀態時,耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。
[C-2-12] 必須搭載
TILT_DETECTOR
感應器,才能執行以下操作:- 裝置處於以下狀態時,耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。
[C-2-13] 相同實體事件的時間戳記, 加速計、陀螺儀和磁力儀皆須在 2.5 毫秒內 建構的介面由系統回報的相同實體事件時間戳記 加速計和陀螺儀應在各間隔 0.25 毫秒內 其他。
[C-2-14] 必須同時設有陀螺儀感應器事件時間戳記 而且在 1 毫秒內發生錯誤。
[C-2-15] 請務必在 5 毫秒內,將範例提供給應用程式 上述任何實體感應器取得資料時 傳送至應用程式
[C-2-16] 耗電量「不得」高於 0.5 毫瓦 當裝置為靜態時,且裝置正在移動時為 2.0 mW 啟用下列感應器組合時:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] 可能配備
TYPE_PROXIMITY
感應器,但如果有的話 至少將緩衝區功能設為 100 個感應器事件
請注意,本節的所有耗電量要求均不包含 應用程式處理器的耗電量。其中包括 Google 的 整個感測器鏈,也就是感應器、任何支撐電路、 而專門的感應器處理系統等
如果裝置的實作方式提供感應器直接支援,請採取下列做法:
- [C-3-1] 必須正確宣告支援直接管道類型和直接管道類型
透過
isDirectChannelTypeSupported
回報費率層級 和getHighestDirectReportRateLevel
也能使用 Google Cloud CLI 或 Compute Engine API - [C-3-2] 必須支援至少兩種感應器直接通道類型的一種 。
- 應透過感應器直接管道支援事件報告,
感應器 (非喚醒變化版本):
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10。生物特徵辨識感應器
如需評估生物特徵辨識解鎖安全性的其他背景資訊,請參閱 評估生物特徵辨識安全性說明文件。
如果實作的裝置包含安全螢幕鎖定,他們會:
- 應包含生物特徵辨識感應器
生物特徵辨識感應器可歸類為第 3 級 (先前稱為 Strong) 第 2 級 (舊稱 Weak) 或第 1 級 (舊稱「便利」) 然後取而代之的是 這種模型這個分類會決定 生物特徵辨識感應器必須連結 Google Cloud Platform 應用程式。感應器必須符合下列額外規定, 分級為「第 1 級」、「第 2 級」或「第 3 級」。 第 2 級和第 3 級生物特徵辨識功能都具備下列功能 詳情請見下文。
如果裝置實作項目提供生物特徵辨識感應器給第三方 透過 android.hardware.biometrics.BiometricManager 安裝應用程式 android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL、 他們會:
- [C-4-1] 必須符合第 3 級或第 2 級生物特徵辨識的規定 可採用其他定義方法
- [C-4-2] 必須識別並遵守定義為常數的每個參數名稱 Authenticators 類別和其中的任何組合 相反地,「不得」使用或識別傳遞到 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法以外的方法 驗證器 和任意組合
- [C-4-3] 必須導入 ACTION_BIOMETRIC_ENROLL 對搭載第 3 級或第 2 級生物特徵辨識的裝置執行動作。 這項操作「必須」顯示第 3 級的註冊進入點 或第 2 級生物特徵辨識。
如果裝置實作支援被動生物特徵辨識,就會:
- [C-5-1] 在預設情況下,「必須」需要額外的確認步驟 (例如按下按鈕)。
- [C-SR-1] 強烈建議使用者採用 覆寫應用程式偏好設定,並一律需要 確認步驟。
- [C-SR-2] 強烈建議確保確認動作安全無虞 避免作業系統或核心入侵的破壞行為 例如,這表示根據實體按鈕的確認動作 是透過僅限輸入的一般用途輸入/輸出 (GPIO) 針腳轉送 無法以非 實體按鈕的按下動作
- [C-5-2] 必須另外實作隱含驗證流程 (無須進行確認步驟) 對應到 setConfirmationRequired(boolean)、 哪些應用程式可以設定用於登入流程
如果裝置實作的裝置有多個生物特徵辨識感應器,就會:
- [C-SR-3] 強烈建議你只確認一種生物特徵辨識資料 每種驗證方式 (例如同時提供指紋與臉部感應器的情況下) 裝置上,onAuthenticationSucceeded 而應在其確認後傳送)。
為了讓裝置實作允許 KeyStore 金鑰存取權 第三方應用程式的功能:
- [C-6-1] 必須符合第 3 級 (如 以下章節。
- [C-6-2] 驗證時,只能提供第 3 級的生物特徵辨識資訊 需要 BIOMETRIC_STRONG、 或是使用 CryptoObject 叫用驗證。
如要在裝置實作項目中將生物特徵辨識感應器視為第 1 級, (舊稱「便利性」) 的用途如下:
- [C-1-1] 不正確的接受率必須低於 0.002%。
- [C-1-2] 必須說明此模式的安全性可能低於高強度 PIN 碼。 並清楚說明啟用風險。 假冒和偽造接受率高於 7% Android 生物特徵辨識測試通訊協定。
- [C-1-9] 必須要求使用者要求提供建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 的 20 次警告和 20 次 不到 90 秒的生物特徵辨識驗證的輪詢時間 假試用是拍攝品質足夠的 (BIOMETRIC_ACQUIRED_GOOD) 與已註冊的生物特徵辨識不相符。
- [C-SR-4] 強烈建議你降低虛假試驗的總數 用於生物特徵辨識驗證 [C-1-9] (假使是假冒者) Android 生物特徵辨識指標的接受率高於 7% 測試通訊協定。
- [C-1-3] 必須限制生物特徵辨識驗證的頻率,其中
假試用是拍攝品質足夠的
(
BIOMETRIC_ACQUIRED_GOOD
)。 與已註冊的生物特徵辨識不相符的情況。 - [C-SR-5] 強烈建議你至少嘗試限制頻率 出現 5 次虛構的生物特徵辨識驗證證明後 30 秒 每個 [C-1-9] 的虛假試驗數量上限 - 虛假試驗為 足夠的拍攝品質 (BIOMETRIC_ACQUIRED_GOOD),不符合 已註冊的生物特徵辨識。
- [C-SR-6] 強烈建議在 TEE 中採用所有頻率限制邏輯。
- [C-1-10] 主要驗證輪詢後,「必須」停用生物特徵辨識功能 最初觸發,如第 9.11 節 [C-0-2] 所述。
- [C-1-11] 假冒及冒名要求接受率不得超過 30% 具有 (1) 假冒 A 級簡報的假冒與冒名接受率 攻擊工具 (PAI) 物種超過 30%,以及 (2) 假冒 第一級 PAI 物種的即時接受率,如 40% 以上, Android 生物特徵辨識測試通訊協定
- [C-1-4] 必須避免在未建立 讓使用者確認現有裝置或新增裝置,建立信任鏈 受 TEE 保護的憑證 (PIN 碼/圖案/密碼);Android Open 實作來源專案會在架構中提供相應機制 例如
- [C-1-5] 必須完全移除使用者的所有可識別生物特徵辨識資料 使用者帳戶移除時 (包括透過恢復原廠設定)。
- [C-1-6] 必須尊重該生物特徵辨識 (即
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
、DevicePolicymanager.KEYGUARD_DISABLE_FACE
,或DevicePolicymanager.KEYGUARD_DISABLE_IRIS
)。 - [C-1-7] 必須要求使用者提出建議的主要驗證方式 (例如 PIN 碼、圖案、密碼) 最多每 24 小時一次。 注意:升級搭載 Android 9 以下版本的裝置「必須」 要求使用者執行建議的主要驗證方式 (例如 PIN 碼、 每 72 小時或一次解鎖一次。
- [C-1-8] 必須向使用者詢問建議的主要年齡
驗證 (例如:PIN 碼、解鎖圖案、密碼) 或第 3 級 (STRONG) 生物特徵辨識
在下列其中一個項目後:
- 4 小時的閒置逾時期限,或
- 3 次生物特徵辨識驗證失敗。
- 閒置逾時期限和失敗的驗證次數已重設 並在成功確認裝置憑證後執行。 注意:升級至搭載 Android 9 以下版本的裝置可能需 不受 C-1-8 的規範。
- [C-SR-7] 強烈建議你使用提供的架構中的邏輯 以便強制執行 新裝置的 [C-1-7] 和 [C-1-8]。
- [C-SR-8] 強烈建議將拒絕率設為低於 10% (以裝置為準)。
- [C-SR-9] 強烈建議將延遲時間維持在 1 秒以下, 從偵測到生物特徵辨識的時間點到螢幕解鎖 已註冊的生物特徵辨識。
如要在裝置實作項目中將生物特徵辨識感應器視為第 2 級, (原為 Weak) 客戶:
[C-2-1] 必須符合上述第 1 級的所有規定。
[C-2-2] 假冒和冒名要求接受率不得超過 20% 具有 (1) 假冒 A 級簡報的假冒與冒名接受率 攻擊工具 (PAI) 物種不超過 20%,以及 (2) 假冒 第一級 PAI 物種的即時接受率,如 30% 以上, 透過 Android 生物特徵辨識測試通訊協定。
[C-2-3] 必須展現 在 Android 以外的獨立執行環境中進行生物特徵辨識比對 使用者或核心空間,例如受信任的執行環境 (TEE);或 ,透過包含安全通道的晶片,連線至獨立的執行環境。
[C-2-4] 所有識別資料都必須經過加密及加密處理 才能取得、讀取或修改 隔離的執行環境,或是包含安全管道的晶片 獨立的執行環境,如實作中所述 準則 掌握更多相關詳細資訊
[C-2-5] 適用於相機式生物特徵辨識,以及生物特徵辨識驗證 或註冊正在進行中:
- 「務必」在禁止相機畫面的模式下操作相機 在隔離執行環境或晶片外讀取或修改 並透過安全管道傳送至隔離執行環境
- 如果是 RGB 單一相機解決方案,相機影格 CAN 可在獨立執行環境外讀取以支援作業 例如預覽註冊,但「不得」修改。
[C-2-6] 「不得」允許第三方應用程式區分 個人生物特徵辨識註冊資料。
[C-2-7] 不得允許未加密存取可識別的生物特徵辨識資料;或 任何從資料衍生到應用程式處理器的資料 (如嵌入) 應用在 TEE 的情境之外升級在 Android 裝置上運作的裝置 9 以下版本不在 C-2-7 的適用範圍內。
[C-2-8] 必須提供安全的處理管道, 系統或核心入侵行為無法允許資料直接插入 假冒使用者身分 注意:如果裝置實作項目已推出 Android 第 9 版 或更早的版本,無法透過系統軟體符合 C-2-8 的要求 更新,則可能不受規定的約束。
[C-SR-10] 強烈建議以下所有人採用有效性偵測 臉部生物特徵辨識的生物特徵辨識和注意力偵測功能
[C-2-9] 必須允許第三方使用生物特徵辨識感應器 應用程式。
如要在裝置實作下將生物特徵辨識感應器視為第 3 級, (先前稱為「Strong」) 的情況下,他們會:
- [C-3-1] 必須符合上述第 2 級的所有規定,但 [C-1-7] 和 [C-1-8]。
- [C-3-2] 必須實作硬體支援的 KeyStore。
- [C-3-3] 假冒及假冒他人接受率必須高於 7% 的確有 (1) 代表 A 級簡報攻擊工具 (PAI) 物種不到 7%,且 (2) 高於 B 級 PAI 物種的虛假或冒名接受率 大於 20% Android 生物特徵辨識測試通訊協定。
- [C-3-4] 必須向使用者詢問建議的主要年齡 每 72 小時驗證一次 (例如 PIN 碼、解鎖圖案、密碼) 以下。
- [C-3-5] 必須重新產生 Authenticator ID 適用於裝置支援的所有第 3 級生物特徵辨識 (如果有的話) 重新註冊。
- [C-3-6] 必須為第三方啟用生物特徵辨識支援的 KeyStore 金鑰 應用程式。
如果裝置實作項目包含螢幕底下的指紋感應器 (UDFPS), 他們會:
- [C-SR-11] 強烈建議你避免 UDFPS 的可觸控區域 幹擾三按鈕操作模式( 部分使用者可能需要 無障礙功能)。
7.3.11。姿勢感應器
裝置實作方式:
- 可能支援 6 度自由度的姿勢感應器。
如果裝置實作支援自由 6 度自由姿勢的姿勢感應器,請按照下列步驟操作:
- [C-1-1] 必須導入及回報
TYPE_POSE_6DOF
感應器。 - [C-1-2] 必須比只使用旋轉向量時的精確度更高。
7.3.12。轉軸角度感應器
如果裝置的實作方式支援轉軸角度感應器,就會:
- [C-1-1] 必須導入並回報
TYPE_HINGLE_ANGLE
。 - [C-1-2] 必須支援至少兩種 0 到 360 度之間的讀數 (包括 0 和 360 度)。
- [C-1-3] 必須傳回醒來
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
的感應器。
7.3.13。IEEE 802.1.15.4 [已移至 7.4.9]
7.4.資料連線
7.4.1。電話通訊系統
「電話」是 Android API 所使用的「電話」,本文件著重說明 透過 GSM 撥打語音通話及傳送簡訊等相關硬體 或 CDMA 網路。儘管這些語音通話不一定能促成封包切換, 這類連結屬於 Android 的用途,不屬於任何資料 這些連線能力可透過相同網路實作。也就是 Android 的「電話」功能和 API 都專指語音 通話和簡訊。例如無法撥打電話或 無論是收發簡訊, 以及透過行動網路進行數據連線。
- Android MAY 適用於不含電話硬體硬體的裝置。沒錯 表示 Android 與非手機裝置相容。
如果裝置實作包含 GSM 或 CDMA 電話,則:
- [C-1-1] 必須宣告
android.hardware.telephony
功能旗標和 再依據技術定義其他子功能旗標 - [C-1-2] 「必須」針對該技術導入完整的 API 支援。
- 應允許所有可用的行動服務類型 (2G、3G、4G、5G 等)
,不論網路類型為何,
SetAllowedNetworkTypeBitmap()
)。
如果裝置實作項目不包含電話硬體,他們會:
- [C-2-1] 「必須」導入完整的 API,免人工管理。
如果裝置的實作支援 eUICC 或 eSIM 卡/內嵌 SIM 卡,且 專屬機制為第三方提供 eSIM 卡功能 開發人員的工作:
- [C-3-1] 必須宣告
android.hardware.telephony.euicc
敬上 功能旗標
如果裝置導入方式未將系統屬性 ro.telephony.iwlan\_operation\_mode
設為「舊版」,那麼:
- [C-4-1] 不得回報「NETWORK_TYPE_IWLAN」 透過 NetworkRegistrationInfo#getAccessNetworkTechnology() 進行設定 當 NetworkRegistrationInfo#getTransportType() 時 對於同一個 NetworkRegistrationInfo 執行個體,則會回報為「TRANSPORT_TYPE_WWAN」。
如果裝置實作支援單一 IP 多媒體子系統 (IMS) 多媒體電話服務 (MMTEL) 和 採用進階通訊解決方案 (RCS) 功能,並且必須遵守 行動電信業者規範,使用單一 所有 IMS 信號流量的 IMS 註冊,它們:
- [C-5-1] 必須宣告
android.hardware.telephony.ims
並提供 適用於 MMTEL 和 RCS User Capability Exchange API 的 ImsService API。 - [C-5-2] 必須宣告
android.hardware.telephony.ims.singlereg
功能旗標,並提供 SipTransport API 的完整實作。 GbaService API, 專門指揮官的指示,使用 IRadio 1.6 HAL,以及進行佈建 透過自動設定伺服器 (ACS) 或其他專屬佈建 透過 IMS Configuration API 監控機制。
如果裝置實作項目回報 android.hardware.telephony
功能,則:
- [C-6-1]
SmsManager#sendTextMessage
和SmsManager#sendMultipartTextMessage
必須產生相應的呼叫CarrierMessagingService
提供文字訊息功能SmsManager#sendMultimediaMessage
敬上 和SmsManager#downloadMultimediaMessage
必須產生相應的呼叫CarrierMessagingService
以提供多媒體傳訊功能 - [C-6-2] 指定的應用程式
android.provider.Telephony.Sms#getDefaultSmsPackage
敬上 必須使用 SmsManager 收發簡訊和多媒體訊息時可用的 API。Android 開放原始碼計畫參考資料 套件/應用程式/訊息中的實作符合這項規定。 - [C-6-3] 回應
Intent#ACTION_DIAL
敬上 必須支援輸入*#*#CODE#*#*
和 觸發相應的TelephonyManager#ACTION_SECRET_CODE
廣播。 - [C-6-4] 回應
Intent#ACTION_DIAL
敬上 必須使用VoicemailContract.Voicemails#TRANSCRIPTION
以視覺化方式向使用者顯示轉錄文字的語音轉錄內容 (如果支援視覺化功能) 語音轉錄。 - [C-6-5] 必須代表所有 SubscriptionInfo 和同等規則
群組 UUID
以單一訂閱項目的形式,提供各項功能,以及供使用者瀏覽的功能
控制 SIM 卡資訊例如設定
比對出的介面
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
敬上 或EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
。 - [C-6-6] 不得根據 非空值群組 UUID 和機會位元 任何使用者可見的預設用途 允許設定或控制 SIM 卡設定。
如果裝置實作結果回報 android.hardware.telephony
功能
並提供系統狀態列,然後:
- [C-7-1] 必須為指定項目選取具代表性的有效訂閱方案 UUID 群組 也就是提供 SIM 卡狀態的任何用途 可能不準確或不適當這類預設用途的例子包括狀態列行動網路 訊號圖示或快速設定方塊。
- [C-SR-1] 強烈建議這個代表性訂閱是 成為 有效資料訂閱 除非裝置語音 來電,強烈推薦業務代表 訂閱是指有效的語音訂閱。
如果裝置實作項目回報 android.hardware.telephony
功能,則:
- [C-6-7] 必須能夠開放,並且同時使用最大值 根據 ETSI TS 102 221 的每個 UICC 邏輯通道數 (共 20 個)。
- [C-6-8] 「不得」對使用中的電信業者應用程式套用下列任何行為
(由
TelephonyManager#getCarrierServicePackageName
指定) 自動或未經使用者明確確認:- 撤銷或限制網路存取權
- 撤銷權限
- 限制在 Android 開放原始碼計畫現有電源管理功能之外的情況下,執行背景或前景應用程式作業
- 停用或解除安裝應用程式
如果裝置實作結果回報 android.hardware.telephony
功能,
全部有效,
非機會式訂閱
共用群組 UUID 將會停用
從裝置取下,或標示為有機會從裝置中移除,然後:
- [C-8-1] 必須自動停用所有剩餘使用中的 機會式 同一個群組中的訂閱項目
如果裝置實作包含 GSM 電話,但不包括 CDMA 電話,則:
- [C-9-1] 「不得」宣告
PackageManager#FEATURE_TELEPHONY_CDMA
。 - [C-9-2] 當嘗試設定任一參數時,必須擲回
IllegalArgumentException
偏好或允許的網路類型位元遮罩的 3GPP2 網路類型。 - [C-9-3] 必須傳回來自以下值的空字串:
TelephonyManager#getMeid
。
如果裝置實作支援具有多個通訊埠和設定檔的 eUICC,則:
- [C-10-1] 必須宣告
android.hardware.telephony.euicc.mep
敬上 功能旗標
7.4.1.1。號碼封鎖相容性
如果裝置實作項目回報 android.hardware.telephony.calling
功能,就會:
- [C-1-1] 必須支援電話號碼封鎖功能
- [C-1-2] 必須完全導入
BlockedNumberContract
以及 SDK 文件中所述的對應 API [C-1-3] 必須封鎖以下地區所有來自電話號碼的來電和訊息: 「blockNumberProvider」完全不必與應用程式互動唯一的例外狀況 通常是因 SDK 中所述的 說明文件。
[C-1-4] 必須寫入平台通話記錄供應商 已封鎖來電,而且必須過濾掉有
BLOCKED_TYPE
的來電 預設的通話紀錄檢視畫面。[C-1-5] 「不得」寫信給電話供應商 表示已封鎖的訊息
[C-1-6] 必須實作已開啟的號碼管理使用者介面 (已開啟) 以及
TelecomManager.createManageBlockedNumbersIntent()
傳回的意圖 方法。[C-1-7] 「不得」允許次要使用者查看或編輯已封鎖的號碼 Android 平台會假設主要使用者俱備 單一執行個體。所有語言 「必須」對次要使用者隱藏封鎖相關使用者介面,且「必須」加入封鎖清單 仍尊重他人
裝置更新時,應將已封鎖的號碼遷移至供應商 。
應用程式預先安裝的來電應顯示已封鎖的通話,而且應提供使用者負擔 撥號應用程式
7.4.1.2。Telecom API
如果裝置導入作業回報 android.hardware.telephony.calling
,就會:
- [C-1-1] 必須支援 SDK 中所述的
ConnectionService
API。 - [C-1-2] 必須顯示新來電,並向使用者清楚說明
當使用者正在通話時,接聽或拒接來電
由不支援保留功能的第三方應用程式所製作
透過
CAPABILITY_SUPPORT_HOLD
。 - [C-1-3] 應用程式「必須」 InCallService:
[C-SR-1] 強烈建議你告知使用者回答問題 來電會中斷進行中的通話。
Android 開放原始碼計畫實作項目可透過抬頭通知,符合這些規定 向接聽來電的使用者說明 才能掛斷其他通話
[C-SR-2] 強烈建議你預先載入預設撥號應用程式, 會在其通話記錄中顯示通話記錄項目和第三方應用程式的名稱 第三方應用程式設定
EXTRA_LOG_SELF_MANAGED_CALLS
敬上 在PhoneAccount
上額外將鍵新增至true
。[C-SR-3] 強烈建議你處理音訊耳機的 適用於行動裝置的
KEYCODE_MEDIA_PLAY_PAUSE
和KEYCODE_HEADSETHOOK
事件android.telecom
API,如下所示:- 呼叫
Connection.onDisconnect()
在通話期間偵測到短暫按下按鍵事件時。 - 呼叫
Connection.onAnswer()
在來電期間偵測到短暫按下按鍵事件時。 - 呼叫
Connection.onReject()
在來電期間偵測到長按按鍵事件時。 - 切換
CallAudioState
的靜音狀態。
- 呼叫
7.4.1.3。行動網路 NAT-T 保持運作卸載
裝置實作方式:
- 應支援行動網路保持運作卸載。
如果裝置實作支援行動保持運作的卸載功能, 會負責向第三方應用程式提供這些功能:
- [C-1-1] 必須支援 SocketKeepAlive API。
- [C-1-2] 必須支援至少一個透過行動網路並行的保持運作運算單元。
- [C-1-3] 必須盡可能支援多個同時進行的行動網路保持運作運算單元 行動無線電 HAL 支援功能
- [C-SR-1] 強烈建議你至少支援三種手機保持運作狀態 每個無線電執行個體的運算單元數量。
如果裝置的實作不支援行動網路保持運作卸載功能, 他們會:
- [C-2-1] 必須傳回 ERROR_UNSUPPORTED。
7.4.2。IEEE 802.11 (Wi-Fi)
裝置實作方式:
- 應支援一或多種 802.11 形式。
如果裝置實作提供 802.11 支援,並公開 功能,讓他們:
- [C-1-1] 必須實作對應的 Android API。
- [C-1-2] 必須回報硬體功能旗標
android.hardware.wifi
。 - [C-1-3] 必須導入多點傳送 API 如 SDK 說明文件中所述。
- [C-1-4] 必須支援多點傳送 DNS (mDNS),且「不得」篩選 mDNS 封包
(224.0.0.251),包括:
- 即使螢幕未處於使用中狀態也一樣。
- 適用於 Android TV 裝置實作 (即使在待機模式下也適用) 電源狀態。
- [C-1-5] 不得將
WifiManager.enableNetwork()
透過 API 方法呼叫,即可充分指示切換目前使用中的 應用程式流量預設使用的Network
,並且會傳回 製作者:ConnectivityManager
API 方法,例如getActiveNetwork
和registerDefaultNetworkCallback
。 也就是說,他們「可能」只會禁止 其他網路供應商 (例如行動數據網路) 是否成功通過驗證 該 Wi-Fi 網路提供網際網路存取權。 - [C-1-6] 強烈建議你
ConnectivityManager.reportNetworkConnectivity()
敬上 呼叫 API 方法時,請重新評估Network
上的網際網路存取權, 一旦評估判定目前的Network
不再提供 網際網路連線,切換至其他可用的網路 (例如行動網路) 網路資料)。 - [C-1-7] 必須隨機產生來源 MAC 位址和探測序列編號 每次掃描開始時一次要求影格數,STA 則 已中斷連線。
- [C-1-8] 必須使用一個一致的 MAC 位址 (不應隨機化 MAC 位址) 掃描的位址)。
- [C-1-9] 必須按照一般 (依序) 方式疊代探測要求序號 指定權重
- [C-1-10] 必須在最後一個探測作業之間隨機產生探測要求序號 和下一次掃描作業的第一次探測要求
- [C-SR-1] 強烈建議你隨機挑選要用於 MAC 位址的來源 MAC 位址
與存取點 (AP) 的所有 STA 通訊,藉此連結
連結。
- 裝置「必須」為每個 SSID 使用不同的隨機 MAC 位址 (Passpoint FQDN) 則會與其通訊。
- 裝置「必須」為使用者提供控制 每個 SSID (Passpoint 的 FQDN) 隨機化和非隨機 和「必須」設定新 Wi-Fi 的預設模式 隨機排序
- [C-SR-2] 強烈建議他們為任何 AP 使用隨機的 BSSID
建立。
- 每個 MAC 位址都必須隨機化,並保留成 AP。
- 「裝置」可能提供使用者停用這項功能的選項。 如有提供這個選項,則「必須」預設為啟用。
如果裝置實作所需支援 Wi-Fi 省電模式 (如定義) 的 IEEE 802.11 標準:
- 每次取得應用程式時,都應關閉 Wi-Fi 省電模式
WIFI_MODE_FULL_HIGH_PERF
鎖或WIFI_MODE_FULL_LOW_LATENCY
門鎖 透過WifiManager.createWifiLock()
和WifiManager.WifiLock.acquire()
API,而且鎖定功能已啟用。 - [C-3-2] 裝置之間的平均往返延遲時間
以及存取點
(
WIFI_MODE_FULL_LOW_LATENCY
) 模式必須小於 Wi-Fi 高效能鎖定 (WIFI_MODE_FULL_HIGH_PERF
) 模式下的延遲時間。 - [C-SR-3] 強烈建議你盡量縮短 Wi-Fi 封包往返延遲時間
每當收到低延遲鎖定 (
WIFI_MODE_FULL_LOW_LATENCY
) 時 並生效
如果實作的裝置支援 Wi-Fi 並使用 Wi-Fi 掃描位置, 他們會:
- [C-2-1] 必須提供使用者負擔以啟用/停用值讀取功能
透過
WifiManager.isScanAlwaysAvailable
API 方法。
7.4.2.1。Wi-Fi Direct
裝置實作方式:
- 應提供 Wi-Fi Direct (Wi-Fi 點對點) 支援。
如果裝置的實作支援 Wi-Fi Direct,請採取下列行動:
- [C-1-1] 必須實作對應的 Android API 如 SDK 說明文件中所述。
- [C-1-2] 必須回報
android.hardware.wifi.direct
硬體功能。 - [C-1-3] 必須支援一般 Wi-Fi 運作。
- [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。
- [C-SR-1] 強烈建議為所有使用者提供來源 MAC 位址 新建立的 Wi-Fi Direct 連線。
7.4.2.2。Wi-Fi 通道直接連結設定
裝置實作方式:
- 應提供 Wi-Fi 通道直接連結設定 (TDLS) 如 Android SDK 說明文件中所述。
如果裝置實作項目支援 TDLS,且 Wi-FiManager API 執行升級作業:
- [C-1-1] 必須透過
WifiManager.isTdlsSupported
宣告支援 TDLS。 - 請只在可能且有利的情況下使用 TDLS。
- 應獲得一些經驗法則,避免在效能表現可能受到影響的情況下使用 TDLS 會比通過 Wi-Fi 存取點還更好。
7.4.2.3。Wi-Fi 偵測
裝置實作方式:
- 應提供 Wi-Fi Aware 支援。
如果裝置實作項目提供 Wi-Fi Aware 支援,並公開 具備以下存取權:
- [C-1-1] 必須按照
WifiAwareManager
SDK 說明文件。 - [C-1-2] 必須宣告
android.hardware.wifi.aware
功能標記。 - [C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
- [C-1-4] 請務必每隔一段時間隨機隨機產生 Wi-Fi Aware 管理介面位址 不超過 30 分鐘。此外,如果未啟用 Wi-Fi Aware, 範圍轉移作業進行中,或 Aware 資料路徑已啟用 (隨機化未 只要資料路徑為有效狀態,就會有不良記錄)。
如果裝置實作項目提供 Wi-Fi Aware 和 參閱 7.4.2.5 節所述的 Wi-Fi 位置資訊和 先向第三方應用程式提供這些功能,然後:
- [C-2-1] 必須實作位置辨識探索 API:setRangingEnabled、 setMinDistanceMm、 setMaxDistanceMm 與 onServiceDiscoveredWithinRange。
7.4.2.4。Wi-Fi Passpoint
如果裝置的實作支援 802.11 (Wi-Fi) 版本,他們會:
- [C-1-1] 必須支援 Wi-Fi Passpoint。
- [C-1-2] 必須導入 Passpoint 相關
WifiManager
API,因為 搭配 SDK 說明文件中所述。 - [C-1-3] 必須支援 IEEE 802.11u 標準、明確相關 到「聯播網」發掘及選擇,例如「一般廣告」 服務 (GAS) 和存取網路查詢通訊協定 (ANQP)。
- [C-1-4] 必須宣告
android.hardware.wifi.passpoint
功能標記。 - [C-1-5] 必須遵循 Android 開放原始碼計畫實作項目,才能探索、比對並建立關聯 傳遞到 Passpoint 網路
- [C-1-6] 至少要支援下列部分的裝置佈建 Wi-Fi Alliance Passpoint R2:EAP-TTLS 中定義的通訊協定 驗證和 SOAP-XML
- [C-1-7] 必須按照下列說明處理 AAA 伺服器憑證: 無線基地台 2.0 R3 規格。
- [C-1-8] 必須讓使用者能夠透過 Wi-Fi 挑選器控管佈建作業。
- [C-1-9] 重新啟動時,請務必讓 Passpoint 設定保持一致。
- [C-SR-1] 極力建議支援條款及細則 接受功能。
- [C-SR-2] 強烈建議支援地點資訊功能。
如果提供全域 Passpoint 停用使用者控制項切換選項,系統會導入以下程式碼:
- [C-3-1] 預設「必須」啟用 Passpoint。
7.4.2.5。Wi-Fi 定位服務 (Wi-Fi 封包往返時間 - RTT)
裝置實作方式:
- 應支援 Wi-Fi 定位。
如果裝置實作項目支援 Wi-Fi 定位功能,並公開 具備以下存取權:
- [C-1-1] 必須按照
WifiRttManager
SDK 說明文件。 - [C-1-2] 必須宣告
android.hardware.wifi.rtt
功能標記。 - [C-1-3] 必須為每個 RTT 爆發來源隨機產生來源 MAC 位址 此物件會在用於 RTT 的 Wi-Fi 介面時執行 執行的範圍未與存取點建立關聯。
- [C-1-4] 在第 68 號享有 80 MHz 頻寬時,請確保準確度為 2 公尺以內 百分位數 (以累計分佈函式計算)。
- [C-SR-1] 強烈建議在 1.5 公尺以內回報正確 和第 68 個百分位數的 80 MHz 頻寬 ( 累計分配函式)。
7.4.2.6。Wi-Fi 保持運作卸載
裝置實作方式:
- 應提供 Wi-Fi 保持運作卸載支援。
如果裝置實作支援 Wi-Fi 保持運作卸載功能 以及向第三方應用程式提供這些功能後,應用程式會:
- [C-1-1] 必須支援 SocketKeepAlive API。
- [C-1-2] 必須透過 Wi-Fi 支援至少三個並行的保持運作運算單元。
如果裝置實作不支援 Wi-Fi 保持運作卸載功能, 他們會:
- [C-2-1] 必須傳回
ERROR_UNSUPPORTED
。
7.4.2.7。Wi-Fi 輕鬆連線 (裝置佈建通訊協定)
裝置實作方式:
- 應支援 Wi-Fi 輕鬆連線 (DPP)。
如果裝置實作提供 Wi-Fi 輕鬆連線支援,並公開 目的是:
- [C-1-1] 必須搭配 WifiManager#isEasyConnectSupported()
方法會傳回
true
。
7.4.2.8。企業 Wi-Fi 伺服器憑證驗證
如果 Wi-Fi 伺服器憑證未通過驗證或 Wi-Fi 伺服器 未設定網域名稱,裝置實作方式:
- [C-SR-1] 強烈建議不要為使用者提供 手動新增 Enterprise Wi-Fi 網路 。
7.4.2.9。初次使用時信任 (TOFU)
如果裝置的實作方式支援首次使用時信任 (TOFU) 和 允許使用者定義 WPA/WPA2/WPA3-Enterprise 設定 然後:
- [C-4-1] 必須讓使用者能選擇使用 TOFU。
7.4.3.藍牙
如果實作的裝置支援藍牙音訊設定檔,就會:
- 應支援進階音訊轉碼器和藍牙音訊轉碼器 (例如 LDAC) 搭配 A2DP。
如果裝置實作支援 HFP、A2DP 和 AVRCP,請按照下列步驟操作:
- 應支援至少 5 部連線裝置。
如果裝置導入方式宣告 android.hardware.vr.high_performance
那麼他們會:
- [C-1-1] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能。
Android 支援藍牙和藍牙低功耗。
如果實作的裝置支援藍牙和藍牙 低功耗:
- [C-2-1] 必須聲明相關的平台功能
(
android.hardware.bluetooth
和android.hardware.bluetooth_le
) ) 並實作平台 API。 - 應實作相關的藍牙設定檔,例如 視裝置適用的 A2DP、AVRCP、OBEX、HFP 等。
如果實作的裝置支援藍牙低功耗 (BLE),即可:
- [C-3-1] 必須宣告硬體功能
android.hardware.bluetooth_le
。 - [C-3-2] 必須啟用 GATT (一般屬性設定檔) 式藍牙 中所述的 API android.bluetooth。
- [C-3-3] 必須回報
BluetoothAdapter.isOffloadedFilteringSupported()
用於表示 ScanFilter 的篩選邏輯 已實作 API 類別。 - [C-3-4] 必須回報
BluetoothAdapter.isMultipleAdvertisementSupported()
表示 是否支援低能源廣告。 - [C-3-5] 必須不再導入可撤銷的私人網址 (RPA) 逾時 於逾時時限內輪替地址,以保護使用者隱私 裝置使用 BLE 掃描或放送廣告時。 為了避免時差攻擊,必須一併隨機設定逾時間隔 介於 5 到 15 分鐘
- 應支援將篩選邏輯卸載至藍牙晶片組 建議使用 ScanFilter API。
- 應支援將批次掃描卸載到藍牙晶片組。
- 應支援至少有 4 個版位的多廣告。
如果實作的裝置支援藍牙 LE,並將藍牙 LE 用於 位置掃描則能:
- [C-4-1] 必須提供使用者負擔以啟用/停用值讀取功能
透過 System API
BluetoothAdapter.isBleScanAlwaysAvailable()
。
如果實作的裝置支援藍牙 LE 和助聽器 個人資料,說明如下: 透過藍牙 LE 支援的助聽器音訊支援:
- [C-5-1] 必須傳回
true
BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID)。
如果實作的裝置支援藍牙或藍牙低功耗, 他們會:
- [C-6-1] 必須限制存取任何藍牙中繼資料 (例如掃描)
結果) 可用來推斷裝置的所在位置,除非
要求的應用程式成功將
android.permission.ACCESS_FINE_LOCATION
以目前的前景/背景狀態為依據的權限檢查。
如果實作的裝置支援藍牙或藍牙低功耗 應用程式資訊清單未包含開發人員的宣告 並非透過藍牙取得位置資訊 然後:
- [C-6-2] 必須限制
android.permission.ACCESS_FINE_LOCATION
後方的藍牙存取權。
如果裝置實作傳回 true
的
BluetoothAdapter.isLeAudioSupported()
API,然後會:
- [C-7-1] 必須支援單點傳播用戶端。
- [C-7-2] 必須支援 200 萬個菲律賓,
- [C-7-3] 必須支援 LE 延伸廣告。
- [C-7-4] CIG 中至少須支援 2 個 CIS 連線。
- [C-7-5] 必須啟用 BAP 單點傳播用戶端、CSIP 集合協調器、MCP 伺服器 VCP 控制器和 CCP 伺服器。
- [C-SR-1] 極力建議啟用 HAP 單點傳播用戶端。
如果裝置實作傳回 true
的
BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API,然後會:
- [C-8-1] 單一 BIG 中至少須支援 2 個 BIS 連結。
- [C-8-2] 必須啟用 BAP 廣播來源、BAP 廣播助理 。
- [C-8-3] 必須支援 LE 定期廣告。
如果裝置實作傳回 true
的
BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API,然後會:
- [C-9-1] 必須支援 PAST (定期廣告同步傳輸)。
- [C-9-2] 必須支援 LE 定期廣告。
如果裝置實作項目宣告 FEATURE_BLUETOOTH_LE
,就會:
- [C-10-1] 必須採用 +/-9dB 的 RSSI 測量結果,才能確保 95% 的
測量距離與參考裝置 (
ADVERTISE_TX_POWER_HIGH
。 - [C-10-2] 必須加入 Rx/Tx 修正,才能減少每個管道的偏差 測量 3 個聲道 每個天線的測量值 (如果使用多個) 介於彼此的 +/-3dB 之間,佔 95% 的 測量資料
- [C-SR-2] 強烈建議你評估與補償的 Rx 偏移
確保 BLE RSSI 的中位數是 -60dBm +/-10 dB,距離
參考裝置傳輸時間:
ADVERTISE_TX_POWER_HIGH
,裝置來源 並將方向定向為「平行平面」螢幕寬度都一樣 往上移動即可 - [C-SR-3] 強烈建議你評估與補償的 Tx 偏移量
從參照掃描掃描時,確保 BLE RSSI 的中位數為 -60dBm +/-10 dB
裝置定位在 1 公尺以內,且傳輸至
ADVERTISE_TX_POWER_HIGH
,即裝置的功能為主軸 「平行平面」就是面對相同方向的螢幕
我們強烈建議您按照 所在地校正。
如果裝置的實作支援藍牙 5.0 版,就會發生以下情形:
- [C-SR-4] 強烈建議你為下列項目提供支援:
- 低 200 萬階段
- LE 轉碼器 PHY
- LE 廣告額外資訊
- 定期廣告
- 至少 10 個廣告集
- 至少 8 個 LE 並行連線。每個連線可以 連線拓撲角色
- LE Link 層隱私權
- 「解決問題清單」項目大小至少為 8 個項目
7.4.4。近距離無線通訊
裝置實作方式:
- 應提供近距離無線通訊設備和相關硬體 通訊 (NFC):
- [C-0-1] 必須導入
android.nfc.NdefMessage
和android.nfc.NdefRecord
API,即使 API 不支援 NFC 或 宣告android.hardware.nfc
功能,因為類別代表 通訊協定獨立資料表示格式,
如果裝置實作項目內含 NFC 硬體,並打算提供 第三方應用程式的權限:
- [C-1-1] 必須向開發人員回報「
android.hardware.nfc
」功能android.content.pm.PackageManager.hasSystemFeature()
方法。 - 必須能夠透過下列 NFC 讀取及寫入 NDEF 訊息 標準屬性:
- [C-1-2] 必須能擔任 NFC 論壇讀取者/寫入者
(根據 NFC 論壇的技術規格定義)。
NFCForum-TS-DigitalProtocol-1.0),
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC 論壇標記類型 1、2、3、4、5 (由 NFC 論壇定義)
[C-SR-1] 強烈建議能夠讀取和寫入 NDEF 訊息與原始資料 (須符合下列 NFC 標準)。請注意, NFC 標準標示為「強烈建議」 我們計劃因應未來版本變更的相容性定義: 必須「必須」能避免這個版本均為選用標準,但規定是必填項目 。搭載這個版本的現有和新裝置 我們強烈建議 Android 符合這些條件 都能升級至未來的平台版本。
[C-1-13] 使用 NFC 探索功能時,「必須」輪詢所有支援的技術 模式。
裝置喚醒時,應處於 NFC 探索模式 螢幕處於啟動狀態,且螢幕鎖定時已解鎖。
應該能夠讀取 Thinfilm NFC 條碼 很少直接解答該如何打造產品
請注意,公開的連結不適用於 JIS、ISO 和 NFC 文中所述的論壇規格。
Android 支援 NFC 主機卡片模擬 (HCE) 模式。
如果裝置實作包含支援 HCE 的 NFC 控制器晶片組 (適用於 NfcA 和/或 NfcB) 並且支援應用程式 ID (AID) 轉送功能,這些機制包括:
- [C-2-1] 必須回報
android.hardware.nfc.hce
功能常數。 - [C-2-2] 必須支援 NFC HCE API Android SDK 中定義的內容
如果裝置實作包含支援 HCE 的 NFC 控制器晶片組 ,並實作第三方應用程式的功能,將:
- [C-3-1] 必須回報
android.hardware.nfc.hcef
功能常數。 - [C-3-2] 必須導入 NfcF Card Emulation API 符合 Android SDK 的定義
如果裝置實作項目提供如本內容所述的一般 NFC 支援 區段及支援 MIFARE 技術 (MIFARE Classic、 MIFARE Ultralight、MIFARE Classic 上的 NDEF),必須具備以下角色:
- [C-4-1] 必須按照 Android SDK
- [C-4-2] 必須向下列人員回報「
com.nxp.mifare
」功能:android.content.pm.PackageManager.hasSystemFeature
() 方法。請注意,這並非標準的 Android 功能,因此不會 在android.content.pm.PackageManager
類別中以常數顯示。
7.4.5。網路通訊協定和 API
7.4.5.1。最低網路功能
裝置實作方式:
- [C-0-1] 必須支援一或多種 以及資料網路具體來說,裝置的實作「必須」提供 至少一個能夠使用 200 Kbit/秒以上的資料標準。優先放送示例 包括 EDGE、HSPA、EV-DO 802.11g、乙太網路和藍牙 PAN。
- 也應支援至少一項常見的無線資料 標準,例如 802.11 (Wi-Fi),但其實是實體網路標準 (例如 乙太網路) 是主要數據連線。
- 可以導入多種形式的數據連線。
7.4.5.2。IPv6
裝置實作方式:
- [C-0-2] 必須納入 IPv6 網路堆疊,並支援 IPv6
以及使用代管 API 進行通訊,例如
java.net.Socket
和java.net.URLConnection
以及原生 API,例如AF_INET6
通訊端。 - [C-0-3] 預設為啟用 IPv6。
- 「必須」確保 IPv6 通訊可靠做為 IPv4,例如:
- [C-0-4] 必須在打盹模式下維持 IPv6 連線。
- [C-0-5] 頻率限制「不得」導致裝置失去 IPv6 且支援高可用性 VPN 網路的任何網路,且該網路會使用 至少 180 秒
- 「必須」確保 IPv6 通訊可靠做為 IPv4,例如:
- [C-0-6] 必須向第三方應用程式提供直接 IPv6 連線功能
無需任何形式的位址或 IP 位址
通訊埠翻譯作業會在裝置端進行這兩種代管 API,例如
Socket#getLocalAddress
敬上 或Socket#getLocalPort
) 和 NDK API (例如getsockname()
或IPV6_PKTINFO
) 都必須傳回 IP 這個位址和通訊埠實際用於 網路,並且會以來源 IP 和網際網路 (Web) 伺服器的通訊埠形式顯示。
所需的 IPv6 支援等級會因網路類型而異,如 下列規定。
如果實作的裝置支援 Wi-Fi,就會發生以下情形:
- [C-1-1] 必須「必須」支援在 Wi-Fi 連線時執行雙重堆疊和僅限 IPv6 的作業。
如果裝置實作項目支援乙太網路,他們會:
- [C-2-1] 必須支援在 乙太網路。
如果裝置的實作方式支援行動數據,請按照下列步驟操作:
- [C-3-1] 必須支援 IPv6 作業 (僅限 IPv6 且可能採用雙重堆疊) 。
如果裝置導入方式支援多種網路類型 (例如Wi-Fi 和行動數據) 的涵蓋範圍,包括:
- [C-4-1] 每個網路都必須同時符合上述規定 當裝置同時連線至多種網路類型時。
7.4.5.3。網頁認證入口
網頁驗證入口是指需要登入才能使用的網路 連上網際網路。
如果裝置實作提供完整的
android.webkit.Webview API
、
他們會:
- [C-1-1] 必須提供網頁認證入口應用程式來處理意圖
ACTION_CAPTIVE_PORTAL_SIGN_IN
敬上 並傳送該意圖,以便顯示網頁認證入口登入頁面 呼叫 System APIConnectivityManager#startCaptivePortalApp(Network, Bundle)
。 - [C-1-2] 必須執行網頁認證入口偵測,並支援登入 當裝置連線時,透過網頁認證入口應用程式來連線 任何網路類型 (包括行動網路/行動網路、Wi-Fi、乙太網路) 或使用藍牙功能
- [C-1-3] 必須支援使用明文 DNS 登入網頁認證入口 當裝置設定使用私人 DNS 嚴格模式時。
- [C-1-4] 「必須」按照 SDK 說明文件中的指示,使用加密的 DNS
android.net.LinkProperties.getPrivateDnsServerName
敬上 和android.net.LinkProperties.isPrivateDnsActive
適用於所有未明確與 網頁認證入口。 - [C-1-5] 必須確保使用者透過網頁認證登入
入口網站,由應用程式使用的預設網路 (由
ConnectivityManager.getActiveNetwork
、ConnectivityManager.registerDefaultNetworkCallback
, 預設也由 Java 網路 API 使用,例如 java.net.Socket 和原生 API (例如 connect()) 是任何其他可用的網路 提供網際網路連線 (如果有的話)
7.4.6。同步處理設定
裝置實作方式:
- [C-0-1] 「必須」將主自動同步處理設定預設為開啟,
getMasterSyncAutomatically()
方法 會傳回「true」。
7.4.7。數據節省模式
如果裝置實作項目提供計量付費連線,就會發生以下情形:
- [C-SR-1] 強烈建議提供數據節省模式。
如果裝置實作項目提供數據節省模式,就會:
- [C-1-1] 必須支援
ConnectivityManager
中的所有 API SDK 說明文件中所述類別
如果裝置實作項目未提供數據節省模式,就會發生以下情形:
- [C-2-1] 必須傳回
RESTRICT_BACKGROUND_STATUS_DISABLED
的值ConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] 不得廣播
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
。
7.4.8。安全元件
如果裝置實作方式支援支援 Open Mobile API 安全元素,並將這些元素提供給第三方應用程式,它們具有以下特點:
[C-1-1] 請務必透過
android.se.omapi.SEService.getReaders()
API。[C-1-2] 必須採用
android.hardware.se.omapi.uicc
敬上 應用程式具有 UICC 型安全元素android.hardware.se.omapi.ese
具有以 eSE 為基礎的安全元件android.hardware.se.omapi.sd
。
7.4.9。UWB
如果裝置的導入方式包含對 802.1.15.4 的支援,並且公開 因此會:
- [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-6] 必須確保距離測量結果在 +/-15 公分以內以 95% 為單位 只能測量距離 非反射性的腔
- [C-1-7] 必須確保距離測量結果的中位數是 1 公尺 在參照裝置的 [0.75m, 1.25m] 內,實際資料 距離以 DUT 站立且傾斜的頂端邊緣為測量單位 45 度。
- [C-SR-2] 強烈建議你按照評估設定步驟操作 指定於 所在地校正。
7.5.相機
如果裝置的實作方式至少包含一部相機,這些裝置會:
- [C-1-1] 必須宣告
android.hardware.camera.any
功能標記。 - [C-1-2] 應用程式必須能夠同時 3 個 RGBA_8888 點陣圖等於 裝置上最大的解析度相機感應器,同時相機是否開啟,以 但還是要擷取基本預覽
- [C-1-3] 必須確認預先安裝的預設相機應用程式
處理意圖
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_IMAGE_CAPTURE_SECURE
, 或MediaStore.ACTION_VIDEO_CAPTURE
, 負責移除圖片中繼資料中的使用者位置。 不在接收端應用程式的情況下,將其傳送到接收端應用程式 具備ACCESS_FINE_LOCATION
。
如果裝置的實作支援 HDR 10 位元輸出功能,就會:
- [C-2-1] 每部相機裝置至少須支援 HLG HDR 設定檔 支援 10 位元輸出
- [C-2-2] 必須支援 10 位元輸出,供主要後置鏡頭或 主要前置鏡頭
- [C-SR-1] 強烈建議同時支援兩個主要版本支援 10 位元輸出 相機上
- [C-2-3] 所有成員都必須支援相同的 HDR 設定檔 邏輯相機支援 BACKWARD_COMPATIBLE 的實體子相機,以及 邏輯性相機本身
適用於支援 10 位元 HDR,且採用
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API,則具有以下權限:
- [C-3-1] 必須支援在所有具回溯相容性的實體之間切換
透過邏輯相機上的
CONTROL_ZOOM_RATIO
控制項操作。
7.5.1。後置鏡頭
後置鏡頭是指位於 裝置就在螢幕對面;也就是圖片最遠處的場景 就像傳統相機一樣
裝置實作方式:
- 應使用後置鏡頭。
如果裝置實作項目包含至少一個後置鏡頭,會發生下列情況:
- [C-1-1] 必須回報功能旗標
android.hardware.camera
和android.hardware.camera.any
。 - [C-1-2] 必須採用至少 200 萬像素的解析度。
- 應導入硬體自動對焦或軟體自動對焦功能 (直通應用程式軟體),
- 可能具備固定對焦或 EDOF (延伸領域深度) 硬體。
- 可能包含閃光燈。
如果攝影機包含閃光燈:
- [C-2-1] 閃光燈時,手電筒「不得」亮起
已註冊
android.hardware.Camera.PreviewCallback
個執行個體 顯示在相機預覽介面上,除非應用程式已明確啟用 啟用FLASH_MODE_AUTO
或FLASH_MODE_ON
屬性,即可使用 FlashCamera.Parameters
物件的定義。請注意,這項限制不適用於 裝置內建的系統相機應用程式,但僅限第三方 使用Camera.PreviewCallback
存取應用程式。
7.5.2。前置鏡頭
前置鏡頭是指位於裝置同一側的攝影機 螢幕顯示;也就是說,通常用於拍攝使用者的相機 可用來進行視訊會議和類似的應用
裝置實作方式:
- 可使用前置鏡頭。
如果裝置的實作方式至少包含一個前置鏡頭,這些裝置會:
- [C-1-1] 必須回報功能旗標
android.hardware.camera.any
和android.hardware.camera.front
。 - [C-1-2] 解析度至少須為 VGA (640x480 像素)。
- [C-1-3] 「不得」使用前置鏡頭做為 Camera API,且不得設定 API,將前置鏡頭視為 。
- [C-1-4] 相機預覽畫面必須和
目前應用程式所指定的方向
明確要求相機
螢幕就會通過呼叫
android.hardware.Camera.setDisplayOrientation()
敬上 方法。相反地,預覽畫面「必須」與裝置的預設畫面同步 目前應用程式未明確請求 呼叫,「相機」畫面就會透過呼叫android.hardware.Camera.setDisplayOrientation()
敬上 方法。 - [C-1-5] 「不得」反映最終拍攝的靜態圖片或影片串流 傳回至應用程式回呼,或承諾用於媒體儲存空間。
- [C-1-6] 請務必以相同方式鏡像投射後檢視畫面所顯示的圖像 做為相機預覽圖像串流
- 可能提供自動對焦、閃光燈等 後置鏡頭,如第 7.5.1 節所述。
如果裝置導入方式可由使用者旋轉 (例如 透過加速計自動切換,或依使用者輸入內容手動執行):
- [C-2-1] 相機預覽畫面必須根據 裝置目前的螢幕方向。
7.5.3.外接鏡頭
裝置實作方式:
- 可考慮支援外接攝影機,但不一定有 隨時保持連線。
如果裝置的實作支援外部攝影機,這些裝置會:
- [C-1-1] 必須宣告平台功能旗標
《
android.hardware.camera.external
》和《android.hardware camera.any
》。 - [C-1-2] 如果外接式裝置,則必須支援 USB 視訊類別 (UVC 1.0 以上版本) 必須透過 USB 主機連接埠連接攝影機
- [C-1-3] 必須使用實體外接鏡頭裝置通過相機 CTS 測試 已連線。如要進一步瞭解相機 CTS 測試,請前往 source.android.com。
- 應支援 MJPEG 等影片壓縮功能,以便傳輸 高品質未編碼串流 (原始或獨立壓縮的圖片) 串流)。
- 支援多部相機。
- 支援相機式影片編碼。
如果支援相機式影片編碼:
- [C-2-1] 同時 未編碼 / MJPEG 串流 (QVGA 或更高解析度) 必須可供存取 裝置實作。
7.5.4。Camera API 行為
Android 提供兩種存取相機的 API 套件 (新版) android.hardware.camera2 API 向應用程式公開低階相機控制項。 包括高效率的零複製/串流資料流,以及每個影格的控制項 曝光, 增加, 白平衡, 色彩轉換, 降噪, 銳利, 等等。
舊版 API 套件 android.hardware.Camera
在
Android 5.0 版本,但應仍可供應用程式使用。Android 裝置
導入方式「必須」確保如
這個區段以及 Android SDK 中
已淘汰的 android.hardware.Camera 類別通用的所有功能 而較新的 android.hardware.camera2 套件「必須」具備同等效能 以及品質與品質舉例來說,假設有對等的設定 自動對焦速度和準確率必須相同,且拍攝圖像的品質必須相同 必須相同。依附兩個 API 不同語意的功能 不需要具有比對速度或品質,但應盡量達成密切比對
裝置實作「必須」為 相機相關 API。裝置實作方式:
- [C-0-1] 必須使用
android.hardware.PixelFormat.YCbCr_420_SP
預覽 當應用程式從未呼叫時,提供給應用程式回呼的資料android.hardware.Camera.Parameters.setPreviewFormat(int)
。 - [C-0-2] 應用程式時,必須進一步採用 NV21 編碼格式
註冊
android.hardware.Camera.PreviewCallback
系統會呼叫onPreviewFrame()
方法和預覽 格式為 YCbCr_420_SP,也就是傳遞至onPreviewFrame()
的位元組 [] 資料。 也就是說,必須預設為 NV21。 - [C-0-3] 必須支援 YV12 格式 (如
android.graphics.ImageFormat.YV12
常數) 兩者的相機預覽畫面android.hardware.Camera
適用的前置和後置鏡頭(硬體 影片編碼器和攝影機可以使用任何原生像素格式,但裝置會 導入方式「必須」支援轉換為 YV12 的版本)。 - [C-0-4] 必須支援
android.hardware.ImageFormat.YUV_420_888
和 使用android.hardware.ImageFormat.JPEG
格式做為輸出內容android.media.ImageReader
適用的android.hardware.camera2
裝置 宣傳「REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
」 功能,android.request.availableCapabilities
。 - [C-0-5] 仍需實作完整的 Camera API
參閱該文件,無論裝置
包括硬體自動對焦或其他功能例如相機需要的相機
缺少自動對焦功能,您仍然必須針對
android.hardware.Camera.AutoFocusCallback
個執行個體 (雖然沒有執行個體 以及與非自動對焦相機之間的關聯性)。請注意,這適用於前置鏡頭 相機;例如大多數前置鏡頭 自動對焦功能,API 回呼仍必須依照描述。 - [C-0-6] 必須識別及遵循每個參數名稱
在 Pod 中定義為常數
android.hardware.Camera.Parameters
敬上 和android.hardware.camera2.CaptureRequest
類別。 相反地,裝置的實作「不得」遵循或辨識字串常數 只傳遞至其他方法的android.hardware.Camera.setParameters()
方法 在android.hardware.Camera.Parameters
上以常數記錄。也就是說 裝置實作項目必須「必須」支援所有標準相機參數, 硬體允許,且「不得」支援自訂的相機參數類型。 例如支援擷取圖片的裝置導入方式 使用高動態範圍 (HDR) 影像技術「必須」支援相機參數Camera.SCENE_MODE_HDR
。 - [C-0-7] 必須使用
android.info.supportedHardwareLevel
敬上 並回報適當的 架構功能旗標。 - [C-0-8] 必須也宣告其個別相機功能
android.hardware.camera2
(透過android.request.availableCapabilities
資源 並宣告適當的功能旗標 如果裝置連接的任何相機裝置,「必須」定義功能旗標 可支援這項功能 - [C-0-9] 必須廣播
Camera.ACTION_NEW_PICTURE
意圖 (每次相機拍攝新相片時) 和 已將 張圖片新增至媒體儲存區。 - [C-0-10] 必須播送
Camera.ACTION_NEW_VIDEO
意圖,以及攝影機記錄新影片的意圖 已將 張圖片新增至媒體儲存區。 - [C-0-11] 必須允許所有透過已淘汰的相機存取
android.hardware.Camera
敬上 您也可以透過android.hardware.camera2
存取 API 也能使用 Google Cloud CLI 或 Compute Engine API - [C-0-12] 必須確保臉部外觀未經過修改,包括:
包括但不限於改變臉部幾何圖形、臉部膚色或臉部
適合任何
android.hardware.camera2
的肌膚保養 或android.hardware.Camera
也能使用 Google Cloud CLI 或 Compute Engine API - [C-SR-1] 對於有多個 RGB 相機朝向同一方向的裝置,
我們極力建議支援邏輯相機裝置
能力
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
、 包括所有面向該方向的 RGB 相機,做為實體次要裝置。
如果裝置實作項目為第三方應用程式提供專屬相機 API, 他們會:
- [C-1-1] 必須使用
android.hardware.camera2
實作這類相機 API 也能使用 Google Cloud CLI 或 Compute Engine API - 可向
android.hardware.camera2
提供供應商代碼和/或擴充功能 也能使用 Google Cloud CLI 或 Compute Engine API
7.5.5。相機方向
如果裝置實作方式有前置或後置鏡頭(例如:
- [C-1-1] 請清楚取向,攝影機的長邊對齊 螢幕的長邊。也就是將裝置拿在橫向時 螢幕方向,相機「必須」以橫向方式拍攝圖片。這個 不受裝置的自然方向影響;也就是說 橫向或直向裝置,以及直向的主要裝置。
凡是符合下列所有條件的裝置,就不受上述規定限制:
- 裝置會導入可變幾何圖形的螢幕,例如折疊式或轉軸 螢幕。
- 當裝置的折疊或轉軸狀態改變時,裝置會在 portrait-primary 至橫向-Primary (或相反) 螢幕方向。
7.6.記憶體與儲存空間
7.6.1。記憶體與儲存空間下限
裝置實作方式:
- [C-0-1] 必須包含 下載管理員 「可能」使用的應用程式「可能」下載資料檔案,而且具備 下載大小至少為 100 MB 的個別檔案。 「快取」或 HTTP/HTTPS 位置
7.6.2。應用程式共用儲存空間
裝置實作方式:
- [C-0-1] 「必須」提供儲存空間供應用程式共用 (通常簡稱為 做為「共用外部儲存空間」、「應用程式共用儲存空間」或是 Linux 的 路徑「/sdcard」與掛接的
- [C-0-2] 必須設定預設掛接共用儲存裝置或其他 「立即可用」的文字,不論儲存空間是否實作於 內部儲存元件或卸除式儲存媒介 (例如 數位卡插槽)。
- [C-0-3] 「必須」直接在 Linux 路徑上掛接應用程式共用儲存空間
請
sdcard
,或是加入sdcard
至實際掛接的 Linux 符號連結 點。 - [C-0-4] 必須啟用
限定範圍儲存空間
根據預設
指定 API 級別 29 以上的應用程式,但下列情況除外:
- 當應用程式要求
android:requestLegacyExternalStorage="true"
。
- 當應用程式要求
- [C-0-5] 必須遮蓋位置中繼資料 (例如 GPS EXIF 標記) 儲存在
透過
MediaStore
存取這些檔案時的媒體檔案,但 發出呼叫的應用程式會保留ACCESS_MEDIA_LOCATION
權限。
裝置實作方式「可能」符合上述規定,請使用 包括:
- 使用者可存取的卸除式儲存空間,例如安全數位 (SD) 記憶卡插槽。
- 內部 (不可移除) 儲存空間的一部分,如 Android 開放原始碼計畫 (AOSP)。
如果裝置實作方式為滿足上述需求,使用卸除式儲存空間 需求,他們可以:
- [C-1-1] 必須導入浮動式訊息或彈出式使用者介面警告使用者 儲存媒介不存在時。
- [C-1-2] 必須包含 FAT 格式的儲存媒介 (例如 SD 卡) 或節目 以及購買時提供的其他資料 媒介必須另外購買。
如果實作裝置時,使用一部分無法移除的儲存空間來滿足 上述規定:
- 應使用分享到內部應用程式的 Android 開放原始碼計畫實作項目 如果 30 天內讀取資料不到一次 建議使用 Nearline Storage
- 可以與應用程式私人資料共用儲存空間。
如果裝置實作項目具備支援 USB 週邊裝置模式的 USB 連接埠, 他們會:
- [C-3-1] 必須提供存取應用程式資料的機制 共用儲存空間
- 應以公開透明的方式公開來自這兩個儲存空間路徑的內容
Android 的媒體掃描器服務和
android.provider.MediaStore
。 - 可能使用 USB 大量儲存裝置,但應使用媒體傳輸通訊協定以滿足 這項規定。
如果裝置實作的 USB 連接埠具備 USB 週邊裝置模式,並支援 媒體傳輸通訊協定,他們可以:
- 必須與參考 Android MTP 主機相容 Android 檔案傳輸應用程式
- 必須回報 0x00 的 USB 裝置類別。
- 請回報「MTP」的 USB 介面名稱。
7.6.3.採用儲存空間
假如裝置本身應為行動裝置,而不是電視, 裝置實作方式如下:
- [C-SR-1] 強烈建議在以下位置導入要使用的儲存空間: 才能維持長期穩定位置 可能造成資料遺失/損毀
如果卸除式儲存裝置通訊埠位於長期穩定的位置, 例如電池座或其他保護蓋 裝置實作方式如下:
- [C-SR-2] 強烈建議導入 合併儲存空間。
7.7.USB
若裝置實作有 USB 連接埠,請檢查下列事項:
- 應支援 USB 週邊模式,且應支援 USB 主機模式。
- 應支援停用 USB 數據訊號。
7.7.1。USB 週邊裝置模式
如果裝置實作包含支援週邊裝置的 USB 連接埠:
- [C-1-1] 連接埠「必須」可連接具備標準的 USB 主機 Type-A 或 Type-C USB 連接埠。
- [C-1-2] 必須根據 USB 標準回報
iSerialNumber
的正確值 透過android.os.Build.SERIAL
設定裝置描述元 - [C-1-3] 必須根據 Type-C 電阻器偵測 1.5A 和 3.0A 充電器 「標準」而且「必須」偵測廣告中的變更 (如果提供支援) Type-C USB。
- [C-SR-1] 連接埠必須使用 micro-B、micro-AB 或 Type-C USB 板型規格。 現有和新款 Android 裝置強烈建議要符合這些規格 相關規定,以便升級至日後的平台版本。
- [C-SR-2] 連接埠應位於裝置底部 (根據自然方向) 或啟用軟體螢幕旋轉功能 所有應用程式 (包括主畫面),讓螢幕在 裝置以位於底部的連接埠方向為準。現有和新的 Android 裝置 我們會強烈建議符合這些規定的裝置, 較新的平台版本
- [C-SR-3] 應導入支援功能,在 HS 晶片期間繪製 1.5 A 電流 以及 USB 電池充電規格 (修訂版本 1.2) 所規定的流量。 現有和新款 Android 裝置強烈建議要符合這些規格 相關規定,以便升級至日後的平台版本。
- [C-SR-4] 強烈建議不要提供專屬支援服務 充電方法;修改 Vbus 電壓超過預設等級,或改變 這樣接收器/來源角色可能會導致與 或支援標準 USB Power Delivery 方法的充電器或裝置。雖然 在日後的 Android 版本中,這稱為「強烈建議」 可能需要用到所有 Type-C 裝置,才能完整支援與標準的互通性 Type-C 充電器。
- [C-SR-5] 強烈建議你為資料與 Power Delivery 支援 電源角色交換,前提是這些裝置支援 Type-C USB 和 USB 主機模式。
- 應支援 Power Delivery 針對高壓充電與支援 替代模式,例如螢幕。
- 應導入 Android Open Accessory (AOA) API 和 請參閱 Android SDK 說明文件中的指示
如果裝置實作包含 USB 連接埠並實作 AOA 規格,以便:
- [C-2-1] 必須宣告支援硬體功能
android.hardware.usb.accessory
。 - [C-2-2] USB 大量儲存空間級別「必須」包含「android」字串的
USB 大量儲存裝置的介面說明
iInterface
字串結尾
7.7.2。USB 主機模式
如果裝置實作包含支援主機模式的 USB 連接埠,就會:
- [C-1-1] 必須實作 Android USB 主機 API,如
Android SDK,且必須宣告支援硬體功能
android.hardware.usb.host
。 - [C-1-2] 必須導入支援功能,才能連接標準 USB 週邊裝置。
換句話說,它們「必須」:
- 使用裝置端 C 連接埠,或透過傳輸線調整裝置端的傳輸線 專用連接埠和標準 USB Type-C 連接埠 (USB Type-C 裝置)。
- 使用裝置端 A,或是透過傳輸線調整裝置端的設定 和標準 USB Type-A 連接埠搭配使用。
- 裝置端的 Micro-AB 連接埠應搭配傳輸線, 複製到標準的 A 型連接埠
- [C-1-3] 「請勿」隨附從 USB 類型 A 轉換的變壓器,或 micro-AB 連接埠連線到 Type-C 連接埠 (插座)。
- [C-SR-1] 強烈建議導入 USB 音訊類別 如 Android SDK 說明文件所述
- 在主機充電時,應支援為連接的 USB 週邊裝置充電 模式;廣告的源源目前至少為 1.5A,如 適用於 USB Type-C 的 USB Type-C 傳輸線和連接器規格修訂版本 1.2 或使用充電下游連接埠(CDP) 將目前範圍輸出為 USB 電池充電規格 (修訂版本 1.2) 。
- 應實作並支援 USB Type-C 標準。
如果裝置實作項目提供支援主機模式的 USB 連接埠和 USB 音訊類別,就能得到下列好處:
- [C-2-1] 必須支援 USB HID 類別。
- [C-2-2] 必須支援偵測及對應下列 HID 資料
USB HID 使用表格中指定的欄位
和 Voice 指令使用要求
加入
KeyEvent
常數,如下所示:- 用量頁面 (0xC) 用量 ID (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- 用量頁面 (0xC) 用量 ID (0x0E9):
KEYCODE_VOLUME_UP
- 用量頁面 (0xC) 用量 ID (0x0EA):
KEYCODE_VOLUME_DOWN
- 用量頁面 (0xC) 用量 ID (0x0CF):
KEYCODE_VOICE_ASSIST
- 用量頁面 (0xC) 用量 ID (0x0CD):
如果裝置實作項目提供支援主機模式的 USB 連接埠, 儲存空間存取架構 (SAF),他們可以:
- [C-3-1] 必須辨識任何遠端連線的 MTP (媒體傳輸通訊協定)
並透過
ACTION_GET_CONTENT
存取相關內容,ACTION_OPEN_DOCUMENT
和ACTION_CREATE_DOCUMENT
意圖。
如果裝置實作項目包含支援主機模式和 USB 的 USB 連接埠 Type-C 代表:
- [C-4-1] 必須實作 USB 定義的雙角色通訊埠功能 Type-C 規格 (第 4.5.1.3.3 節)。雙通道用 角色連接埠,如果是支援 3.5 公釐耳機插孔的裝置,則為 USB 接收器 自動偵測 (主機模式) 可能預設為關閉,但只有在執行 以便啟用該功能
- [C-SR-2] 強烈推薦支援 DisplayPort,應支援 USB 超速資料傳輸速率,也強烈建議支援 Power Delivery 功能 資料及輔助角色交換
- [C-SR-3] 強烈建議「不」支援音訊轉接器配件模式, 會在 USB Type-C 傳輸線和連接器規格修訂版本 1.2。
- 請導入最適合 裝置板型規格舉例來說,手持裝置必須 試試看 SNK 模型。
7.8.音訊
7.8.1。麥克風
如果裝置實作項目內含麥克風,裝置會:
- [C-1-1] 必須回報
android.hardware.microphone
功能常數。 - [C-1-2] 必須符合下列音訊錄音規定: 第 5.4 節。
- [C-1-3] 必須符合 第 5.6 節。
- [C-SR-1] 強烈建議你支援近乎超音波錄音功能 (如上所述) 第 7.8.3 節。
如果裝置實作方式省略麥克風,系統會:
- [C-2-1] 「不得」回報
android.hardware.microphone
功能常數。 - [C-2-2] 至少要導入音訊錄音 API,至少要以人工作業方式處理 第 7 節。
7.8.2。音訊輸出裝置
如果裝置的實作方式包含喇叭或音訊/多媒體輸出裝置 音訊輸出週邊裝置的連接埠,例如 4 導體 3.5 公釐耳機插孔, 使用 USB 音訊類別的 USB 主機模式連接埠:
- [C-1-1] 必須回報
android.hardware.audio.output
功能常數。 - [C-1-2] 必須符合 第 5.5 節。
- [C-1-3] 必須符合 第 5.6 節。
- [C-SR-1] 強烈建議你支援近乎超音波播放功能 (如上所述) 第 7.8.3 節。
如果裝置的實作方式不包含喇叭或音訊輸出通訊埠,就會:
- [C-2-1] 不得回報
android.hardware.audio.output
功能。 - [C-2-2] 至少要實作音訊輸出相關 API 作為免人工管理。
就本節目的而言,「輸出通訊埠」是 實體介面 例如 3.5 公釐耳機插孔、HDMI 或具備 USB 音訊類別的 USB 主機模式通訊埠。 支援透過藍牙、 Wi-Fi 或行動網路不符合「輸出連接埠」的資格。
7.8.2.1。類比音訊連接埠
如何與耳機和其他音訊配件相容 3.5 公釐音訊插頭適用於 Android 生態系統 (如有裝置) 實作包含一或多個類比音訊通訊埠:
- [C-SR-1] 強烈建議你至少加入 音訊連接埠以及 4 指導管 3.5 公釐耳機插孔。
如果裝置實作方式為 4 導體 3.5 公釐耳機插孔,則:
- [C-1-1] 必須支援透過立體聲耳機和立體聲耳機播放音訊 麥克風圖示
- [C-1-2] 必須支援 CTIA 輸出順序的 TRRS 音訊插頭。
- [C-1-3] 必須支援偵測並對應至
麥克風與接地之間的 3 個範圍同等阻礙
音訊插頭上的導電器:
- 70 ohm 以下:
KEYCODE_HEADSETHOOK
- 210-290 ohm:
KEYCODE_VOLUME_UP
- 360-680 ohm:
KEYCODE_VOLUME_DOWN
- 70 ohm 以下:
- [C-1-4] 插入插頭時必須觸發
ACTION_HEADSET_PLUG
,但 外掛程式上的所有聯絡人都觸碰到相關的區隔後才會開始 。 - [C-1-5] 必須能夠駕駛至少 150mV ±10% 的輸出電壓, 32 釐米喇叭阻抗
- [C-1-6] 麥克風偏壓電壓應介於 1.8V 至 2.9V 之間。
- [C-1-7] 必須偵測並對應至以下項目的按鍵碼
麥克風與地面電導體之間的衝擊範圍
:
- 110-180 ohm:
KEYCODE_VOICE_ASSIST
- 110-180 ohm:
- [C-SR-2] 強烈建議你透過 OMTP 支援音訊插頭
- [C-SR-3] 強烈建議你支援立體聲音訊錄音 配備麥克風的耳機。
如果裝置實作可提供 4 指導管 3.5 公釐耳機插孔,並支援
並透過麥克風廣播android.intent.action.HEADSET_PLUG
將麥克風設為 1,那麼麥克風會:
- [C-2-1] 必須能偵測插在插入音訊的麥克風 。
7.8.2.2。數位音訊連接埠
如要瞭解裝置專屬的需求,請參閱 2.2.1 節。
7.8.3.近乎超音波
近乎超音波音訊為 18.5 kHz 至 20 kHz 錶帶。
裝置實作方式:
- 必須正確回報 透過 AudioManager.getProperty 提供接近超音波的音訊功能 API,如下所示:
如果PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
為「true」,代表
「VOICE_RECOGNITION
」和「UNPROCESSED
」音訊來源:
- [C-1-1] 在 18.5 kHz 至 20 kHz 頻帶中,麥克風的平均功率響應 以 2 kHz 而言,回應率不得超過 15 dB。
- [C-1-2] 麥克風的未加權訊號與噪音比,比率超過 18.5 kHz 至 20 kHz 在 -26 dBFS 下,19 kHz 的語氣不得低於 50 dB。
如果PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
為「true」:
- [C-2-1] 講者在 18.5 kHz 至 20 kHz 的範圍內,平均的回應率不得低於 2 kHz。
7.8.4。信號完整性
裝置實作方式:
- 應提供無故障的音訊訊號路徑, 並根據零故障的定義,將手持裝置上的資料輸出串流 會在每個路徑一分鐘的測試內進行測量 使用 OboeTester 進行測試 「自動化毛刺測試」
測試需要音訊回送連接器。 。 所有音訊輸出連接埠都必須測試。
OboeTester 目前支援 AAudio 路徑,因此 下列組合應使用 AAudio 測試是否出現故障:
效能模式 | 共享 | 取樣率 | 英屬香腸 | 逃離袖 |
---|---|---|---|---|
低延遲 | 專屬 | 未指定 | 1 | 2 |
低延遲 | 專屬 | 未指定 | 2 | 1 |
低延遲 | 已分享的影片 | 未指定 | 1 | 2 |
低延遲 | 已分享的影片 | 未指定 | 2 | 1 |
無 | 已分享的影片 | 48000 | 1 | 2 |
無 | 已分享的影片 | 48000 | 2 | 1 |
無 | 已分享的影片 | 44100 | 1 | 2 |
無 | 已分享的影片 | 44100 | 2 | 1 |
無 | 已分享的影片 | 16000 | 1 | 2 |
無 | 已分享的影片 | 16000 | 2 | 1 |
可靠的直播內容「必須」符合下列條件,才能收到「雜訊」訊號 適用於 2000 Hz 的 2000 Hz 同質量 (SNR) 和總諧變形 (THD)。
換能器 | THD 內容 | 得分 |
---|---|---|
主要內建喇叭,使用外部參考麥克風測得 | <3.0% | >= 50 分貝 |
主要內建麥克風,使用外部參考喇叭進行測量 | <3.0% | >= 50 分貝 |
內建類比 3.5 公釐耳機插孔,使用回送轉接器進行測試 | 不到 1% | >= 60 分貝 |
手機隨附的 USB 轉接器,使用回送轉接器進行測試 | <1.0% | >= 60 分貝 |
7.9.虛擬實境
Android 提供用於建構「虛擬實境」的 API 和設施(虛擬實境) 包括優質的行動 VR 體驗。裝置 實作「必須」正確實作這些 API 和行為 可參閱本節內容
7.9.1。虛擬實境模式
Android 支援 VR 模式, 處理通知的立體視覺呈現並停用 單項系統 UI 元件,而 VR 應用程式則是使用者焦點。
7.9.2。虛擬實境模式 - 高效能
如果裝置實作支援虛擬實境模式,請按照下列步驟操作:
- [C-1-1] 至少必須有 2 個實體核心。
- [C-1-2] 必須宣告
android.hardware.vr.high_performance
功能。 - [C-1-3] 必須支援持續效能模式。
- [C-1-4] 必須支援 OpenGL ES 3.2。
- [C-1-5] 必須支援
android.hardware.vulkan.level
0。 - 應支援
android.hardware.vulkan.level
1 以上版本。 - [C-1-6] 必須導入
EGL_KHR_mutable_render_buffer
、EGL_ANDROID_front_buffer_auto_refresh
,EGL_ANDROID_get_native_client_buffer
,EGL_KHR_fence_sync
,EGL_KHR_wait_sync
、EGL_IMG_context_priority
、EGL_EXT_protected_content
、EGL_EXT_image_gl_colorspace
、 並在可用的 EGL 擴充功能清單中顯示擴充功能。 - [C-1-8] 必須導入
GL_EXT_multisampled_render_to_texture2
、GL_OVR_multiview
,GL_OVR_multiview2
,GL_EXT_protected_textures
, 並在可用的 GL 擴充功能清單中顯示擴充功能。 - [C-SR-1] 極力推薦導入
GL_EXT_external_buffer
、GL_EXT_EGL_image_array
,GL_OVR_multiview_multisampled_render_to_texture
, 並在可用的 GL 擴充功能清單中顯示擴充功能。 - [C-SR-2] 極力推薦支援 Vulkan 1.1。
- [C-SR-3] 極力推薦導入
VK_ANDROID_external_memory_android_hardware_buffer
、VK_GOOGLE_display_timing
,VK_KHR_shared_presentable_image
, 並顯示在可用的 Vulkan 擴充功能清單中。 - [C-SR-4] 強烈建議至少公開一個 Vulkan 佇列系列,其中
flags
包含VK_QUEUE_GRAPHICS_BIT
和VK_QUEUE_COMPUTE_BIT
且queueCount
至少為 2。 - [C-1-7] GPU 和螢幕「必須」可以同步處理共用存取權 前端緩衝區,讓交錯顯示 VR 內容 (每秒 60 個影格) 和兩秒 會呈現一個算繪背景,但不會呈現明顯的茶格瑕疵。
- [C-1-9] 必須導入
AHardwareBuffer
支援功能 旗標AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
和AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
如 NDK 中所述。 - [C-1-10] 必須針對
AHardwareBuffer
的AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
,AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
,AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
至少為下列格式:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
。 - [C-SR-5] 強烈建議支援
AHardwareBuffer
s 分配 C-1-10 中指定了多個圖層和旗標與格式 - [C-1-11] 必須支援 H.264 解碼器,解析度至少為 3840 x 2160 (30fps), 壓縮到 40 Mbps 的平均值 (相當於 1920 x1080 (30 fps-10 Mbps) 或 2 個執行個體 (1920 x 1080,每秒 60 fps-20 Mbps)。
- [C-1-12] 必須支援 HEVC 和 VP9,且至少要具備解碼能力 1920 x 1080 (每秒 30 個影格) 壓縮到平均 10 Mbps,且應 能夠解碼 3840 x 2160,速度為 30 fps-20 Mbps (相當於 4 個 1920 x 1080 執行個體,每秒 30 fps-5 Mbps)。
- [C-1-13] 必須支援
HardwarePropertiesManager.getDeviceTemperatures
API 然後傳回準確的皮膚溫度值 - [C-1-14] 必須具有內嵌畫面,且解析度至少需 1920 x 1080。
- [C-SR-6] 強烈建議採用至少 2560 x 1440。
- [C-1-15] 處於 VR 模式時,螢幕至少要更新 60 Hz。
- [C-1-17] 螢幕「必須」支援低持久模式 (不超過 5 毫秒) 持續性,持續定義為 就是一個像素發光的
- [C-1-18] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能 第 7.4.3 節。
- [C-1-19] 必須提供支援並妥善回報
直接管道類型
下列所有預設感應器類型:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] 強烈建議你
TYPE_HARDWARE_BUFFER
敬上 上述所有直接管道類型的直接管道類型。 - [C-1-21] 必須符合陀螺儀、加速計和磁力儀相關
android.hardware.hifi_sensors
的相關規定,如 第 7.3.9 節。 - [C-SR-8] 強烈建議你
android.hardware.sensor.hifi_sensors
功能。 - [C-1-22] 端對端動作必須高於光子延遲時間 28 毫秒。
- [C-SR-9] 強烈建議使用端對端動態到光影延遲 不超過 20 毫秒
- [C-1-23] 請務必設定第一個畫面比例,也就是介於 從黑色轉變為黑畫面後的第一個影格像素亮度 白色像素以及白色像素在穩定狀態下的亮度,至少為 85%。
- [C-SR-10] 強烈建議將第一個影格比例至少設為 90%。
- 可以為前景提供專屬核心
應用程式,且可能支援
Process.getExclusiveCores
API 傳回 頂層前景專屬的 CPU 核心數量 應用程式。
如果支援專屬核心,則使用核心:
- [C-2-1] 不得允許其他的使用者空間處理程序執行 (但應用程式使用的裝置驅動程式除外),但「MAY」允許一些核心 視需要執行其他程序
7.10。觸覺回饋
如要瞭解裝置專屬的需求,請參閱 2.2.1 節。
7.11。媒體成效類別
可取得裝置實作的媒體效能類別
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
API。需求條件
針對每個 Android 版本,從
R (30 版)。特殊值為 0 時,表示裝置並非
媒體成效類別
如果裝置實作針對
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,他們:
[C-1-1] 傳回的值至少須為
android.os.Build.VERSION_CODES.R
。[C-1-2] 必須實作手持裝置。
[C-1-3] 必須符合「媒體成效等級」的所有規定描述 第 2.2.7 節。
換句話說,Android T 中的媒體效能類別只有在 版本 T、S 或 R 的手持裝置。
請參閱第 2.2.7 節,瞭解裝置適用的方式 Google Cloud 就是最佳選擇
8. 效能與功率
某些最低效能和電源標準對使用者體驗至關重要 並影響開發人員在開發機器學習模型時 應用程式。
8.1.使用者體驗一致性
我們為使用者提供流暢的使用者介面 確保一致性的影格速率和回應時間 應用程式和遊戲根據裝置類型導入裝置 「或許」對使用者介面延遲和工作有可量化的要求 如果換機操作,請依照第 2 節所述的方式切換。
8.2.檔案 I/O 存取效能
為
應用程式私人資料儲存空間 (/data
分區) 可讓應用程式開發人員
訂出合適的軟體設計方向。裝置
視裝置類型而定,廣告導入方式可能有些許需求
詳見第 2 節中的以下內容
以及寫入作業
- 依序寫入效能。測量方法是使用以下程式碼寫入 256 MB 檔案: 10 MB 寫入緩衝區。
- 隨機寫入效能。使用 4 KB 寫入 256 MB 檔案來評估結果 寫入緩衝區。
- 依序讀取效能。使用以下安全工具讀取 256 MB 檔案 10 MB 寫入緩衝區。
- 隨機讀取效能。藉由讀取使用 4 KB 的 256 MB 檔案來評估值 寫入緩衝區。
8.3.省電模式
如果實作的裝置包含改善裝置電源管理機制的功能 並加入 Android 開放原始碼計畫 (例如應用程式待命值區、打盹) 中或擴充功能 為套用比 RESTRICTED 應用程式待命值區更嚴格的限制,包括:
- [C-1-1] 觸發事件時,不得偏離 Android 開放原始碼計畫的實作項目, 以及使用全域系統設定或 裝置設定 分別是「應用程式待命」和「打盹省電模式」
- [C-1-2] 「不得」偏離 Android 開放原始碼計畫實作項目,以便使用全域 或 DeviceConfig 管理工作、鬧鐘和 為每個值區中的應用程式建立網路待命。
- [C-1-3] 應用程式使用的應用程式待命值區 待機。
- [C-1-4] 必須實作應用程式待命值區和打盹功能 如「電源管理」中所述。
- [C-1-5] 必須退還
PowerManager.isPowerSaveMode()
的true
裝置開啟省電模式時。 - [C-1-6] 必須為使用者提供授權,才能顯示豁免的應用程式 使用應用程式待命和打盹省電模式,或任何電池效能最佳化設定 且務必導入 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 意圖要求使用者允許應用程式忽略電池 以及最佳化調整
- [C-SR-1] 強烈建議提供使用者負擔以實現 停用省電模式功能。
- [C-SR-2] 強烈建議使用者提供足夠空間來顯示所有 不受應用程式待命和打盹省電模式限制的應用程式。
如果採用的裝置會擴充隨附的電源管理功能, ,且該擴充功能適用的限制比 「稀有應用程式待命值區」 第 3.5.1 節。
除了省電模式外,Android 裝置實作方式可能為 MAY 執行「進階」定義的 4 種睡眠電源狀態 (完全或全部) 設定和電源介面 (ACPI)。
如果裝置實作方式實作 他們可以採取以下做法:
- [C-1-1] 只有在使用者採取明確行動後,才能輸入這個狀態 讓裝置進入閒置狀態 (例如蓋上機蓋時, 裝置或汽車/電視),然後 使用者重新啟用裝置 (例如打開機蓋或轉動車輛) 或電視再次播放)。
如果裝置實作方式實作 他們可以採取以下做法:
[C-2-1] 必須符合上述 C-1-1 標準,或只在第三方時進入 S3 狀態 應用程式不需要系統資源 (例如螢幕、CPU)。
相反地,當第三方應用程式需要 系統資源
舉例來說,第三方應用程式要求保持畫面 直到
FLAG_KEEP_SCREEN_ON
為止,或是確保 CPU 持續運作PARTIAL_WAKE_LOCK
,除非如上所述,裝置「不得」進入 S3 狀態 在 C-1-1 的版本中,使用者已採取明確行動,將裝置放在 停用狀態相反地,第三方應用程式的工作 必須透過 JobScheduler 或 Firebase 雲端通訊 否則裝置「必須」退出 S3 狀態,除非 使用者將裝置設為閒置狀態。包括但不限於: 相關範例和 Android 開放原始碼計畫實作了大量會觸發喚醒功能的喚醒信號 。
8.4.耗電量會計
更準確計算耗電量和耗電量 應用程式開發人員提供了獎勵和工具來最佳化電力使用的工具 應用程式的模式
裝置實作方式:
- [C-SR-1] 強烈建議提供個別組件的電源設定檔 定義目前消耗值 ,以及測試過程中 。
- [C-SR-2] 強烈建議以公釐為單位所有耗電量值 小時 (mAh)。
- [C-SR-3] 強烈建議你針對每個程序的 UID 回報 CPU 耗電量。
Android 開放原始碼計畫通過了
uid_cputime
核心模組實作。 - [C-SR-4] 強烈建議你透過
adb shell dumpsys batterystats
敬上 殼層指令給應用程式開發人員。 - 無法歸因於硬體元件 最終歸功於應用程式
8.5.一致的效能
針對高效能長時間執行的應用程式,效能可能大幅波動。 原因可能是其他應用程式在背景執行,或 CPU 節流 。Android 包含程式輔助介面 則頂層前景應用程式可以要求 系統會最佳化資源分配方式,以因應這類波動。
裝置實作方式:
[C-0-1] 必須正確回報永續發展效能模式的支援情形 透過
PowerManager.isSustainedPerformanceModeSupported()
API 方法。應持續推動效能模式。
如果裝置導入資料回報支援持續性效能模式,則表示:
- [C-1-1] 必須為頂層前景應用程式提供一致等級的 至少持續 30 分鐘 (當應用程式提出要求時)。
- [C-1-2] 必須尊重
Window.setSustainedPerformanceMode()
API 和其他相關 API
如果裝置的實作項目包含兩個以上的 CPU 核心,則會造成:
- 至少應提供一個頂端保留的專屬核心 前景應用程式。
如果裝置實作支援預留一個頂層核心 前景應用程式,因此能:
- [C-2-1] 必須透過
Process.getExclusiveCores()
回報 API 方法為可保留的專屬核心 ID 編號 頂端前景應用程式 - [C-2-2] 不得允許除了裝置驅動程式以外的任何使用者空間處理程序 有些記憶體會在獨家核心上執行,但或許能讓 執行所需的核心程序
如果裝置實作項目不支援專屬核心,就會:
- [C-3-1] 請務必透過
Process.getExclusiveCores()
敬上 API 方法。
9. 安全性模型相容性
裝置實作方式:
[C-0-1] 必須採用一致的安全性模型 Android 平台的安全性模型 (如 安全性和權限參考文件 。
[C-0-2] 必須支援自行簽署的安裝作業 而且不必取得 第三方/授權者。
如果裝置導入方式宣告 android.hardware.security.model.compatible
那麼他們會:
- [C-1-1] 必須支援下列子節所列的規定。
9.1.權限
裝置實作方式:
[C-0-1] 必須支援 Android 權限模型和 Android 角色模型 (定義於 Android 開發人員說明文件中所列)。具體來說 必須強制執行以下項目中定義的各項權限和角色: SDK 說明文件;也不可以使用任何角色 或被忽略。
可新增其他權限,提供新的權限 ID 字串 不在
android.\*
命名空間中[C-0-2]
protectionLevel
的PROTECTION_FLAG_PRIVILEGED
權限 只能授予預先安裝在 系統映像檔 (以及 APEX 檔案), 。 Android 開放原始碼計畫實作方式符合這項規定,方法是參閱 許可清單中的檔案列出各個應用程式已加入許可清單的權限etc/permissions/
路徑並使用system/priv-app
路徑做為 特殊權限路徑
防護等級為危險的權限即為執行階段權限。
具有「targetSdkVersion
」的應用程式 >22 在執行階段提出請求
裝置實作方式:
- [C-0-3] 必須顯示專屬的介面,供使用者決定 是否要授予要求的執行階段權限 可讓使用者管理執行階段權限的介面。
- [C-0-4] 使用者只能擇一執行 存取 API如果實作的裝置支援隨附裝置, 隨附裝置可能包含額外介面。
[C-0-5] 「不得」授予任何執行階段權限給 應用程式,除非:
[C-0-6] 必須授予
android.permission.RECOVER_KEYSTORE
權限 僅適用於註冊適當安全復原代理程式的系統應用程式。A 罩杯 正確安全復原代理程式的定義為裝置端軟體代理程式 能與裝置外的遠端儲存空間同步 提供防護等級等於或超越現有硬體的安全硬體 描述 Google Cloud Key Vault 服務 以防範暴力攻擊對螢幕知識因素構成的暴力攻擊
裝置實作方式:
[C-0-7] 應用程式必須遵循 Android 位置存取權屬性 透過標準 Android API 要求位置資訊或體能活動資料 或專屬機制這類資料包括但不限於:
- 根據上方說明所述的裝置所在位置 (例如經緯度) 第 9.8.8 節。
- 可用於判斷或預估裝置的 位置 (例如 SSID、BSSID、基地台 ID 或網路的位置) 裝置連線時)。
- 使用者的體能活動或體能活動分類。
具體來說,裝置導入方式:
- [C-0-8] 必須取得使用者同意,應用程式才能存取 位置或體能活動資料。
- [C-0-9] 「只能」授予執行階段權限給持有
足夠的權限。
例如:
TelephonyManager#getServiceState
需要
android.permission.ACCESS_FINE_LOCATION
)。
上述 Android 位置存取權屬性的唯一例外: 應用程式未存取位置資訊以取得或識別使用者的位置;特別是:
- 應用程式擁有
RADIO_SCAN_WITHOUT_LOCATION
權限時。 - 在裝置設定和設定中,系統應用程式會保留
NETWORK_SETTINGS
或NETWORK_SETUP_WIZARD
權限。
權限可標示為受限制改變其行為。
[C-0-10] 標有
hardRestricted
標記的權限「不得」 授予應用程式的權限,除非:- 應用程式 APK 檔案位於系統分區中。
- 使用者指派的角色與
hardRestricted
相關聯 授予應用程式權限 - 安裝程式將
hardRestricted
授予應用程式。 - 應用程式獲得舊版 Android 的
hardRestricted
。
[C-0-11] 擁有
softRestricted
權限的應用程式只能受到限制 而且除非依照 SDK,其中每個softRestricted
定義了完整與有限的存取權 權限 (例如READ_EXTERNAL_STORAGE
)。[C-0-12] 不得提供任何自訂函式或 API 來略過 setPermissionPolicy 中定義的權限限制 和 setPermissionGrantState 相互整合
[C-0-13] 「必須」使用 AppOpsManager API 記錄及追蹤 能夠以程式輔助的方式存取受危險權限保護的資料 Android 活動與服務。
[C-0-14] 請務必只指派角色給具備下列功能的應用程式: 滿足職務要求
[C-0-15] 請勿定義重複或超集合功能的角色 代表平台定義的角色
如果裝置回報android.software.managed_users
,他們會:
- [C-1-1] 不得
管理員:
- 位置 (ACCESS_BACKGROUND_LOCATION,ACCESS_COARSE_LOCATION), ACCESS_FINE_LOCATION)。
- 相機 (CAMERA)
- 麥克風 (RECORD_AUDIO)
- 人體感測器 (BODY_SENSORS)
- 體能活動 (ACTIVITY_RECOGNITION)
如果裝置實作項目能讓使用者自由選擇
有一個活動可以處理
ACTION_MANAGE_OVERLAY_PERMISSION
敬上
目的:
- [C-2-1] 必須確保具有意圖篩選器的所有活動
ACTION_MANAGE_OVERLAY_PERMISSION
敬上 意圖都具有相同的 UI 畫面,無論啟動的應用程式或任何 這些資訊
如果裝置實作回報 android.software.device_admin,就會:
- [C-3-1] 必須在全代管裝置設定中顯示免責事項 (裝置擁有者設定) 指出 IT 管理員可執行下列操作: 允許應用程式控製手機上的設定,包括麥克風、相機和 以及讓使用者繼續設定或離開設定的選項,除非有 管理員已選擇不控制裝置的權限。
如果裝置實作項目預先安裝任何包含 System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence 或 System Visual Intelligence 角色的套件,則包含以下套件:
- [C-4-1] 必須符合「9.8.6 內容擷取」一節所列裝置實作方面的所有規定。
- [C-4-2] 「不得」擁有 android.permission.INTERNET 權限。這項規定比第 9.8.6 節所列的「強烈推薦」要嚴格。
- [C-4-3] 「不得」繫結至其他應用程式,但下列系統應用程式除外:藍牙、聯絡人、媒體、電話、SystemUI 和提供網際網路 API 的元件。此規定比第 9.8.6 節「強烈推薦」的規定更嚴格。
9.2.UID 與程序隔離
裝置實作方式:
- [C-0-1] 必須支援 Android 應用程式 沙箱模型,每個應用程式會以專屬 Unixstyle UID 執行 然後以獨立的程序處理
- [C-0-2] 必須支援執行多個應用程式 相同的 Linux 使用者 ID (前提是應用程式必須正確簽署 建構與建構元件 安全性和權限參考資料。
9.3.檔案系統權限
裝置實作方式:
- [C-0-1] 必須支援 Android 檔案存取權 權限模型,在 安全性和權限參考資料。
9.4.替代執行環境
實作裝置必須維持 Android 的安全性和一致性 權限模型,即使其中包含 應用程式使用 Dalvik Executable 以外的其他軟體或技術 格式或原生程式碼。也就是說:
[C-0-1] 替代執行階段本身「必須」是 Android 應用程式 並遵循其他平台的標準 Android 安全性模型 第 9 節。
[C-0-2] 不得將資源存取權授予替代執行階段 受到執行階段
AndroidManifest.xml
中未要求權限保護 透過 <uses-permission
>以注意力機制為基礎[C-0-3] 替代執行階段「不得」允許應用程式利用 功能受到 Android 權限保護。
[C-0-4] 替代執行階段必須符合 Android 沙箱模型 以及透過替代執行階段安裝的應用程式 可重複使用裝置上安裝的任何其他應用程式沙箱,但 共用使用者 ID 和簽署憑證的標準 Android 機制。
[C-0-5] 其他執行階段「不得」透過允許、授權或取得方式啟動 存取與其他 Android 應用程式對應的沙箱。
[C-0-6] 不得透過啟動、授予或授權的方式啟動替代執行階段 授予超級使用者 (根使用者) 或任何其他應用程式的權限 使用者 ID
[C-0-7] 當網頁中含有替代執行階段的
.apk
檔案時 裝置實作的系統映像檔,「必須」使用專屬的金鑰簽署 從用於簽署裝置中其他應用程式的金鑰 。[C-0-8] 安裝應用程式時,「必須」取得替代執行階段 針對應用程式使用的 Android 權限徵得使用者同意。
[C-0-9] 應用程式需要使用裝置資源時 必須具備相應的 Android 權限 (例如相機、GPS 等), 替代執行階段「必須」告知使用者應用程式能夠 取得該項資源的存取權
[C-0-10] 執行階段環境未記錄應用程式的情形 執行階段環境「必須」列出所有權限 由執行階段自行保留。
替代執行階段應透過
PackageManager
安裝應用程式 獨立的 Android 沙箱 (Linux 使用者 ID 等)。替代執行階段可以提供所有人共用的單一 Android 沙箱 使用替代執行階段應用程式
9.5.多使用者支援
Android 裝置支援多位使用者
支援完全區隔使用者,以及複製使用者個人資料
部分隔離(例如單一使用者其他類型的使用者設定檔)
android.os.usertype.profile.CLONE
)。
- 可導入裝置,但對於多人使用,則不應啟用多使用者 卸除式媒體 主要外部儲存空間容量
如果裝置的實作支援多位使用者:
- [C-1-2] 必須為每個使用者導入安全措施 符合 Android 平台的安全性模型 安全性和權限參考文件 解讀方式。
- [C-1-3] 必須具有獨立的獨立共用應用程式儲存空間
(又稱為
/sdcard
) 目錄。 - [C-1-4] 必須確保由 特定使用者無法列出、讀取或寫入其他使用者擁有的檔案, 即使兩位使用者的資料都儲存在相同的磁碟區或檔案系統中,也能使用。
- [C-1-5] 啟用多使用者功能時,務必將 SD 卡的內容加密 使用的金鑰只儲存在非卸除式媒體上,且只有在系統可存取 裝置的實作方式會為外部儲存空間 API 使用卸除式媒體。 因為這會讓主機電腦無法讀取媒體,實作裝置 必須改用 MTP 或類似系統,以提供主機電腦 存取目前使用者的資料。
如果裝置實作項目支援多位使用者 除了專為執行雙執行個體作業建立的使用者以外 但在同一個應用程式中,他們會:
- [C-2-1] 必須具有獨立的獨立共用應用程式儲存空間 (又稱為 /sdcard) 目錄,
- [C-2-2] 必須確保在 特定使用者無法列出、讀取或寫入擁有的檔案 任何使用者存取的資料,即使兩位使用者的資料儲存在相同的 磁碟區或檔案系統
導入裝置時,可以建立單一類型的額外使用者設定檔
對主要使用者執行 android.os.usertype.profile.CLONE
(僅限
主要使用者),藉此執行同一個應用程式的兩個執行個體。
這些雙執行個體會共用部分獨立儲存空間
使用者同時顯示在啟動器中的「最近」檢視畫面中。
例如,此應用程式可用於支援使用者安裝
單一應用程式的執行個體
如果裝置實作建立上述額外的使用者設定檔, 然後:
- [C-3-1] 「必須」只提供儲存空間或已存 可供上層使用者個人資料存取,或直接由此 其他使用者設定檔。
- [C-3-2] 「不得」以工作資料夾做為工作資料夾。
- [C-3-3] 必須區隔來自父項的私人應用程式資料目錄 使用者帳戶。
- [C-3-4] 「不得」允許建立額外的使用者設定檔 (如有) 為「裝置擁有者」佈建 (請參閱第 3.9.1 節),或允許「裝置擁有者」 而不需要先移除額外的使用者設定檔
9.6.付費簡訊警告
Android 支援針對任何傳出的使用者發出警告 付費簡訊。付費簡訊 訊息是傳送給向電信業者註冊的服務,且 向使用者收取的費用
如果裝置實作結果宣告支援 android.hardware.telephony
,
他們會:
- [C-1-1] 必須先警告使用者,才能傳送簡訊到電話號碼
以
/data/misc/sms/codes.xml
中定義的規則運算式表示 檔案。上游 Android 開放原始碼計畫 符合這項規定的導入方法
9.7.資安防護機制
裝置實作「必須」確保同時符合 如下所述。
Android Sandbox 中有使用安全增強式 Linux 的功能 (SELinux) 強制性存取控制 (MAC) 系統、seccomp 沙箱及其他 安全功能裝置實作方式:
- [C-0-1] 必須維持與現有應用程式的相容性 SELinux 或任何其他安全性功能已實作於 Android 之下 這個架構的重點在於
- [C-0-2] 發生安全措施時,「不得」顯示使用者介面 就會透過安全防護功能成功加以封鎖 導入在 Android 架構底下,但「可能」有清楚可見的使用者介面 發生以安全為違規而遭解除封鎖的威脅,導致漏洞遭人成功利用時。
- [C-0-3] 不得實作 SELinux 或任何其他已實作的安全性功能 下方可供使用者或應用程式開發人員設定的 Android 架構。
- [C-0-4] 不得允許影響其他應用程式的應用程式 透過 Device 管理 API 等 API 就會破壞相容性
- [C-0-5] 必須將媒體架構分成多個程序, 可集中授予每個程序的存取權 描述 瞭解相關詳細資訊
- [C-0-6] 必須實作核心應用程式沙箱機制 啟用時,可使用以下 設定的可設定政策,篩選系統呼叫 多執行緒程式上游 Android 開放原始碼計畫 要求以 Threadgroup 啟用 seccomp-BPF 並按照說明 找到「核心設定」部分。
核心完整性和自我保護功能是 Android 不可或缺的一環 安全性。裝置實作方式:
- [C-0-7] 必須實作核心堆疊緩衝區溢位保護機制。
這類機制的例子包括
CC_STACKPROTECTOR_REGULAR
和CONFIG_CC_STACKPROTECTOR_STRONG
。 - [C-0-8] 在可執行檔的位置,必須採用嚴格的核心記憶體保護措施
此為唯讀資料,唯讀資料無法執行或無法寫入。
可寫入資料為不可執行檔 (例如
CONFIG_DEBUG_RODATA
或CONFIG_STRICT_KERNEL_RWX
)。 - [C-0-9] 必須導入靜態和動態物件大小
使用者空間與核心空間之間副本的邊界檢查
(例如
CONFIG_HARDENED_USERCOPY
) 僅限以 API 級別出貨的裝置購買 28 以上版本。 - [C-0-10] 執行時「不得」執行使用者空間記憶體
處於核心模式 (例如硬體 PXN,或透過
CONFIG_CPU_SW_DOMAIN_PAN
或CONFIG_ARM64_SW_TTBR0_PAN
) 原始運送服務的格式為 API 級別 28 以上。 - [C-0-11] 不得讀取或寫入
一般使用者副本存取 API 以外的核心 (例如硬體 PAN 或
透過
CONFIG_CPU_SW_DOMAIN_PAN
或CONFIG_ARM64_SW_TTBR0_PAN
模擬) 。 - [C-0-12] 如果硬體
在最初以 API 級別運送的所有裝置上,安全漏洞其 CVE-2017-5754 的安全漏洞
28 以上版本 (例如
CONFIG_PAGE_TABLE_ISOLATION
或CONFIG_UNMAP_KERNEL_AT_EL0
)。 - [C-0-13] 如果硬體
在最初以 API 級別運送的所有裝置上,安全漏洞其 CVE-2017-5715 的安全漏洞
28 以上版本 (例如
CONFIG_HARDEN_BRANCH_PREDICTOR
)。 - [C-SR-1] 強烈建議保留核心資料
這個方法只會在初始化期間寫入,之後才會標示為唯讀
(例如
__ro_after_init
)。 [C-SR-2] 強烈建議 避免暴露在 (例如:
CONFIG_RANDOMIZE_BASE
具有系統啟動載入程式熵)/chosen/kaslr-seed Device Tree node
或EFI_RNG_PROTOCOL
)。[C-SR-3] 強烈建議你在以下機構單位中啟用控制流程完整性 (CFI) 機制 這項核心功能,針對重複使用程式碼的攻擊提供額外防護 (例如
CONFIG_CFI_CLANG
和CONFIG_SHADOW_CALL_STACK
)。[C-SR-4] 強烈建議不要停用控制流程完整性 (CFI); 開啟陰影呼叫堆疊 (SCS) 或整數溢位清理 (IntSan) 所有具備該功能的應用程式
[C-SR-5] 極力建議您為所有的產品啟用 CFI、SCS 和 IntSan 安全敏感的使用者空間元件,詳情請參閱 CFI 和 IntSan。
[C-SR-6] 強烈建議在核心中啟用堆疊初始化 防止使用未初始化的本機變數 (
CONFIG_INIT_STACK_ALL
或CONFIG_INIT_STACK_ALL_ZERO
)。 此外,在裝置上執行裝置時,不應假設編譯器使用的值 初始化 Local。[C-SR-7] 強烈建議在核心中啟用堆積初始化功能 避免使用未初始化的堆積分配量 (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
),而且不應假設 來初始化這些配置。
如果裝置實作項目採用支援這項功能的 Linux 核心 SELinux,他們可以:
- [C-1-1] 必須實作 SELinux。
- [C-1-2] 必須將 SELinux 設為全域強制執行模式。
- [C-1-3] 「必須」在強制執行模式下設定所有網域。沒有許可模式 許可網域,包括特定裝置/供應商的網域。
- [C-1-4] 請勿修改、省略或取代永不允許的規則 位於上游 Android 開放原始碼系統提供的 system/sepolicy 資料夾中 專案 (AOSP) 和政策都必須以所有永不允許的規則進行編譯。 ,以及裝置/廠商特定網域。
- [C-1-5] 必須執行以 API 級別 28 以上為目標的第三方應用程式 個別應用程式的 SELinux 沙箱,每個應用程式各有 SELinux 限制 控管應用程式的私人資料目錄
- 應保留系統/sepolicy 中提供的預設 SELinux 政策 上游 Android 開放原始碼專案的資料夾,並且只加入 定義自己的裝置專屬設定。
如果裝置實作採用的是 Linux 或 Linux 以外的核心 (在沒有 SELinux 的情況下), 他們會:
- [C-2-1] 必須使用 等於 SELinux
如果裝置實作方式採用支援 DMA 的 I/O 裝置,則:
- [C-SR-9] 強烈建議每個 I/O 裝置隔離符合《數位市場法》規定、 使用 IOMMU (例如 ARM SMMU)。
Android 包含多種裝置不可或缺的深度防禦功能 安全性。此外,Android 也著重於減少常見錯誤類別 導致品質不佳和安全性降低
為了減少記憶體錯誤,裝置實作項目如下:
- [C-SR-10] 強烈建議使用使用者空間記憶體錯誤進行測試 ARMv9 裝置的 MTE、HWASan (適用於 ARMv8 以上版本裝置) 或 ASan 適合其他裝置類型使用
- [C-SR-11] 強烈建議使用核心記憶體錯誤進行測試 ,例如 KASAN (CONFIG_KASAN,CONFIG_KASAN_HW_TAGS ARMv9 裝置,CONFIG_KASAN_SW_TAGS (適用於 ARMv8 裝置) 或 CONFIG_KASAN_GENERIC 廣告。
- [C-SR-12] 強烈建議在 例如 MTE、GWP-ASan 和 KFENCE
如果裝置實作採用以 Arm TrustZone 為基礎的 TEE,會執行以下動作:
- [C-SR-13] 強烈建議使用記憶體標準通訊協定 Android 和 TEE 之間分享的資料,例如 Arm 韌體架構 Armv8-A (FF-A)。
- [C-SR-14] 強烈建議將信任的應用程式設為 存取已透過上述指令明確與他們共用的記憶體 因此效能相當卓越如果裝置支援 Arm S-EL2 例外狀況等級, ,應由安全分區管理員強制執行。否則,您應該 執行 TEE OS 強制執行的指令
9.8.隱私權
9.8.1。使用記錄
Android 會儲存使用者選擇的記錄,並管理這類記錄。 UsageStatsManager。
裝置實作方式:
- [C-0-1] 請務必為這類使用者記錄保留合理的保留期限。
- [C-SR-1] 極力建議將 14 天的保留期限維持在 預設的設定。
Android 使用 StatsLog
儲存系統事件
識別碼,並透過 StatsManager
和
IncidentManager
System API。
裝置實作方式:
- [C-0-2] 「必須」只包含以
DEST_AUTOMATIC
標示的欄位 事件報告 (由系統 API 類別IncidentManager
建立)。 - [C-0-3] 不得使用系統事件 ID 記錄任何其他事件
與
StatsLog
中描述的內容不同 SDK 文件。如有記錄其他系統事件,它們可能會使用 介於 100,000 至 200,000 之間
9.8.2。錄製中
裝置實作方式:
- [C-0-1] 「不得」直接預先載入或發布 傳送使用者的私人資訊 (例如按鍵動作、 裝置螢幕、錯誤報告)、未經使用者同意或清除裝置 持續性通知。
- [C-0-2] 必須顯示同意聲明,並徵得使用者同意,允許任何敏感內容
使用者畫面上的資訊,每次系統或時間都會擷取。
螢幕投放或螢幕錄製功能是透過以下程式啟用:
MediaProjection
敬上 專屬 API「不得」提供使用者停用未來服務的預設用途 使用者同意聲明。 - [C-0-3] 投放畫面時,「必須」持續通知使用者 或螢幕錄影功能已啟用Android 開放原始碼計畫能夠顯示 狀態列中的持續性通知圖示。
如果裝置實作項目中包含下列
擷取畫面上顯示的內容及/或錄製音訊串流
透過系統 API ContentCaptureService
以外的裝置在裝置上執行;或
第 9.8.6 節內容擷取,他們會:
- [C-1-1] 每當這種情況發生 功能是否已啟用,且正在主動擷取/錄製。
如果裝置實作項目包含可立即啟用的元件, 錄製環境音訊和/或錄製裝置播放的音訊 能推斷出有關使用者情境的實用資訊
- [C-2-1] 「不得」存放永久的裝置儲存空間或傳輸到 裝置錄製的原始音訊或任何可轉換的格式 原始音訊或近似的傳真,除非使用者明確同意。
「麥克風指標」指的是螢幕上持續可見的檢視畫面 且不能經過遮蔽,導致使用者理解其麥克風處於 使用(透過不重複文字、顏色、圖示或組合的方式)。
「攝影機指標」指的是螢幕上的檢視畫面, 因為相機正在使用中,使用者無法理解其內容,因此不能予以遮蓋。 (透過不重複的文字、顏色、圖示或某些組合)。
顯示前一秒後,指標可能會改變,例如 而且不需要和原始圖片一樣顯示 瞭解
麥克風指標可能會與主動顯示的相機合併 指標,前提是文字、圖示或顏色 已開始使用麥克風。
攝影機指示可能會與主動顯示的麥克風合併 指標,前提是文字、圖示或顏色會在使用者 已開始。
如果裝置實作項目宣告 android.hardware.microphone
,就會:
- [C-SR-1] 強烈建議在應用程式顯示麥克風指標時顯示麥克風指標
存取來自麥克風的音訊資料,而無法使用麥克風
僅供
HotwordDetectionService
、SOURCE_HOTWORD
存取,ContentCaptureService
,或擁有第一節提及的角色的應用程式 9.1 具有 CDD ID [C-3-X] 的權限。 。 - [C-SR-2] 強烈建議你顯示近期和活躍清單
應用程式使用麥克風做為傳回的
PermissionManager.getIndicatorAppOpUsageData()
,以及任何歸因方式 或是與 Gemini 相關的訊息 - [C-SR-3] 強烈建議不要隱藏麥克風指示器 具有可見使用者介面或直接使用者互動的系統應用程式。
如果裝置實作項目宣告 android.hardware.camera.any
,就會:
- [C-SR-4] 強烈建議在應用程式 存取即時攝影機的資料,但無法存取攝影機時便無法存取 擁有第 9.1 節「具備 CDD 權限」所述角色的應用程式。 ID [C-3-X]。
- [C-SR-5] 強烈建議使用
PermissionManager.getIndicatorAppOpUsageData()
所傳回的相機, 以及所有相關的歸因訊息 - [C-SR-6] 強烈建議不要為系統隱藏相機指示器 具有可見使用者介面或直接使用者互動的應用程式。
9.8.3.連線能力
如果裝置實作項目具備支援 USB 週邊裝置模式的 USB 連接埠, 他們會:
- [C-1-1] 必須事先顯示已徵得使用者同意的使用者介面 允許透過 USB 連接埠存取共用儲存裝置的內容。
9.8.4。網路流量
裝置實作方式:
- [C-0-1] 必須預先安裝相同的系統信任的根憑證 依提供的憑證授權單位 (CA) 商店 。
- [C-0-2] 出貨時,請務必提供空白的使用者根 CA 商店。
- [C-0-3] 必須向使用者顯示警告,說明網路流量 使用者根憑證授權單位可能會受到監控。
如果裝置流量是透過 VPN 轉送,系統會採用以下裝置實作方式:
- [C-1-1] 必須向使用者顯示警告,指出以下事項:
- 該網路流量可能會受到監控。
- 也就是透過特定 VPN 轉送網路流量 用於提供 VPN 的應用程式
如果裝置導入方式設有機制,並預設為立即啟用。
透過 Proxy 伺服器或 VPN 閘道 (例如
預先載入 android.permission.CONTROL_VPN
的 VPN 服務),兩者會:
- [C-2-1] 必須先徵得使用者同意,才能啟用該機制。
除非裝置政策控制器透過
DevicePolicyManager.setAlwaysOnVpnPackage()
敬上 ,在此情況下,使用者不需另外提供同意聲明, 只需收到通知。
如果裝置實作項目可滿足使用者需求的設定,將 「永久連線 VPN」功能:
- [C-3-1] 必須針對不支援的應用程式停用這項使用者權限
透過以下方式在
AndroidManifest.xml
檔案中設定永久連線 VPN 服務SERVICE_META_DATA_SUPPORTS_ALWAYS_ON
屬性設為false
。
9.8.5。裝置 ID
裝置實作方式:
- [C-0-1] 必須防止他人存取裝置序號及
適用、IMEI/MEID、SIM 卡序號和國際行動裝置
應用程式的訂閱者身分 (IMSI),除非應用程式符合下列任一條件
規定:
- 是已簽署的電信業者應用程式,經過裝置製造商驗證。
- 已授予
READ_PRIVILEGED_PHONE_STATE
權限。 - 具備 UICC 電信業者權限中定義的電信業者權限。
- 是已授予
READ_PHONE_STATE
權限。 - (僅適用於 SIM 卡序號/ICCID) 符合當地法規 應用程式會偵測訂閱者身分的變化。
9.8.6。內容擷取和應用程式搜尋
Android 透過 System API ContentCaptureService
。
AugmentedAutofillService
、AppSearchGlobalManager.query
或其他使用者
專屬的方式,可支援裝置的導入機制,方便擷取
應用程式與下列應用程式之間的資料互動
使用者:
- 顯示在螢幕上的文字和圖形,包括但不限於:
透過
AssistStructure
接收通知和輔助資料 也能使用 Google Cloud CLI 或 Compute Engine API - 裝置錄製或播放的媒體資料,例如音訊或影片。
- 輸入事件,例如按鍵、滑鼠、手勢、語音、影片和無障礙工具。
- 應用程式透過
Content Capture
敬上 提供類似功能的 Android 或AppSearchManager
API 專屬 API - 透過
TextClassifier API
傳送的任何文字或其他資料 傳送給系統 TextClassifier,亦即由系統服務瞭解 並根據分析結果 文字。 - 透過平台 AppSearch 實作方式建立索引的資料,包含但不包括 資料、圖像、媒體資料或其他類似資料
如果裝置的導入方式擷取上述資料,就會:
- [C-1-1] 儲存在裝置中的所有這類資料都必須經過加密。這個 「可能性」是採用 Android 檔案加密機制 的加密套件 (如 Cipher SDK 所述) 為 API 26 以上版本。
- [C-1-2] 「不得」使用 Android 備份方法或任何其他返回方法 向上擴充方法
- [C-1-3] 「必須」使用
隱私權保護機制隱私權保護機制
屬於「它們只能進行匯總和防止
將記錄的事件或衍生結果與個別使用者進行比對
防止任何個別使用者資料遭到檢查 (例如使用
差異化隱私技術,例如
RAPPOR
)。 - [C-1-4] 「不得」將這類資料與任何使用者身分 (例如
以
Account
的身分) 但若資料儲存時就已取得使用者的明確同意,則不在此限。 連結。 - [C-1-5] 「不得」將這類資料分享給其他不會這麼做的 OS 元件 遵循目前章節所列出的要求 (9.8.6 內容擷取),除非每次都徵得使用者同意 而且是共用的
- [C-1-6] 「必須」為使用者提供充足的容量,才能清除這類資料
「
ContentCaptureService
」或其專屬用途 資料會以任何形式儲存在裝置上。 - [C-1-7] 必須為使用者提供意願選項,讓他們選擇拒絕收集資料 透過 AppSearch 或專屬方式避免自己的內容出現在 Android 平台上 例如啟動器。
- [C-SR-1] 強烈建議「不要」要求 網際網路權限。
- [C-SR-2] 強烈建議你只能透過網路存取網際網路 結構化 API
如果裝置實作項目包含實作 System API 的服務
ContentCaptureService
、AppSearchManager.index
或任何專屬服務
擷取資料,就會:
- [C-2-1] 不得允許使用者以 使用者可以安裝的應用程式或服務,且必須 以便擷取這類資料。
- [C-2-2] 必須「不得」允許預先安裝服務以外的任何應用程式 以擷取這類資料
- [C-2-3] 必須為使用者提供停用服務的額度。
- [C-2-4] 管理 Android 權限時,不得省略使用者負擔 由服務保管,並依循 Android 的相關權限 如 第 9.1 節:權限。
[C-SR-3] 強烈建議將這些服務與其他服務區隔開來 系統元件(例如不要繫結服務或共用程序 ID) 但以下例外:
- 電話、聯絡人、系統 UI 和媒體
Android 透過 SpeechRecognizer#onDeviceSpeechRecognizer()
可讓您
即可在不涉及網路的情況下,在裝置上執行語音辨識功能。
任何在裝置上實作的 SpeechRecognizer 都「必須」符合政策規定
將根據本節內容
9.8.7。剪貼簿存取權
裝置實作方式:
- [C-0-1] 「不得」傳回剪貼簿中的剪輯資料 (例如透過
ClipboardManager
敬上 API),除非第三方應用程式為預設輸入法編輯器,或者是 焦點目前位於 - [C-0-2] 剪貼簿資料一旦超過 60 分鐘,「必須」清除。 或者從剪貼簿讀取。
9.8.8。位置
位置包含 Android 位置類別中的資訊( 例如 Latitude、 經度、高度),以及可以轉換成 Location 的 ID。 位置可以精確為 DGPS (差異化全球定位系統),或 概略的國家/地區層級位置 (例如國家/地區代碼位置 - 我的客戶中心 - 行動電話) 國家/地區代碼)。
以下是直接產生使用者的位置類型清單 也可以轉換成使用者的位置這並未涵蓋所有情況 清單,但應做為例子,當做位置資訊直接或 間接衍生自:
- GPS/GNSS/DGPS/PPP
- 全球定位解決方案、全球導航系統,或 差異化全球定位解決方案
- 原始 GNSS 評估和 GNSS 狀態也包含在內
- 精確位置可以從原始 GNSS 評估結果取得
- 識別專屬 ID 的無線技術,例如:
- Wi-Fi 存取點 (MAC、BSSID、名稱或 SSID)
- 藍牙/BLE (MAC、BSSID、名稱或 SSID)
- UWB (MAC、BSSID、名稱或 SSID)
- 基地台 ID (3G、4G、5G... 我包括日後所有推出的行動網路數據機) 有專屬 ID 的技術)
為提供資訊的主要參考資料,請參閱 ACCESS_FINE_Location 或 ACCESS_COARSE_位置權限。
裝置實作方式:
- [C-0-1] 「不得」開啟/關閉裝置位置資訊設定和 Wi-Fi/藍牙 未經使用者同意或使用者明確啟動即掃描設定
- [C-0-2] 必須為使用者提供要求存取權,才能存取相關的位置資訊 包括最近的位置資訊要求、應用程式層級權限和使用情形等資訊 ,以掃描 Wi-Fi/藍牙來確定位置。
- [C-0-3] 必須確保應用程式使用 Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] 是使用者啟動的緊急事件 (例如:撥打 911 或傳送簡訊給 911)。但汽車可能 在未主動使用者互動的情況下啟動緊急工作階段 偵測到車禍/事故 (例如符合 eCall 規定)。
- [C-0-4] 必須讓緊急位置略過 API 的功能能夠: 略過裝置的位置資訊設定,而不變更設定。
- [C-0-5] 必須排定在以下時間過後提醒使用者的通知:
但該應用程式在背景使用
「[
ACCESS_BACKGROUND_LOCATION
]」權限。
9.8.9。已安裝的應用程式
如果 Android 應用程式的目標 API 級別為 30 以上,就無法查看其他詳細資料 預設安裝的應用程式 (請參閱 Android 裝置的「套件瀏覽權限」一節) SDK 說明文件)。
裝置實作方式:
- [C-0-1] 不得向任何目標 API 級別 30 以上的應用程式提供詳細資料 。除非應用程式能夠查看詳細資訊 其他已安裝應用程式的相關作業這包括 不限於裝置新增的任何自訂 API 所顯示的詳細資料 或透過檔案系統存取
- [C-0-2] 不得授予任何應用程式、讀取或寫入任何其他檔案的權限
應用程式專屬目錄
外部儲存空間唯一的例外如下:
- 外部儲存空間供應商授權 (例如 DocumentsUI 等應用程式)。
- 下載供應商,其使用「下載」提供者授權 將檔案下載到應用程式儲存空間
- 平台簽署的媒體傳輸通訊協定 (MTP) 應用程式,採用 特殊權限 ACCESS_MTP,以便將檔案傳輸到 在其他裝置上播放。
- 安裝其他應用程式並取得權限的應用程式 INSTALL_PACKAGES 只能存取「OBB」目錄 APK 擴充檔案:
9.8.10。連線錯誤報告
如果裝置實作程序宣告了 android.hardware.telephony
功能旗標,
他們會:
- [C-1-1] 必須支援透過以下方式產生連線錯誤報告:
BUGREPORT_MODE_TELEPHONY
搭配 BugreportManager。 - [C-1-2] 每次
BUGREPORT_MODE_TELEPHONY
時,都必須取得使用者同意聲明 用於產生報表,而且「不得」提示使用者同意所有 應用程式未來的要求 - [C-1-3] 若無錯誤,「不得」將產生的報告傳回要求的應用程式 使用者明確表示同意
- [C-1-4] 使用「
BUGREPORT_MODE_TELEPHONY
」產生的報表必須包含 至少提供下列資訊:TelephonyDebugService
轉儲TelephonyRegistry
轉儲WifiService
轉儲ConnectivityService
轉儲- 呼叫套件的
CarrierService
例項傾印 (如果已繫結) - 無線電記錄緩衝區
- [C-1-5] 產生的報表中不得包含下列資訊:
- 任何與連線能力無關的資訊 以及偵錯
- 使用者安裝的任何類型應用程式流量記錄或詳細設定檔 使用者安裝的應用程式/套件 (可使用 UID,套件名稱 則不會)。
- 可加入與任何使用者無關的額外資訊 識別個人身分(例如廠商記錄)。
如果裝置的實作方式在內容中加入其他資訊 (例如供應商記錄) 以及含有隱私/安全性/電池/儲存空間/記憶體 他們可以:
- [C-SR-1] 強烈建議將開發人員設定預設為
已停用。只要提供
Enable verbose vendor logging
,即可實作 Android 開放原始碼計畫參考資料 選項,納入其他裝置專屬的供應商記錄 回報的部分。
9.8.11。資料 blob 共用
Android (透過 BlobStoreManager) 允許應用程式向「系統」提供資料 blob,並與指定對象共用 應用程式組
如果裝置實作支援共用資料 blob,如 SDK 說明文件 他們會:
- [C-1-1] 不得分享不屬於應用程式的資料 blob 用途 (即預設存取權的範圍和其他存取權) 支援多種模式 BlobStoreManager.session#allowPackageAccess() BlobStoreManager.session#allowSameSignatureAccess() 或 BlobStoreManager.session#allowPublicAccess() 「請勿」修改)。Android 開放原始碼計畫參考資料實作項目符合以下規定: Google Cloud 就是最佳選擇
- [C-1-2] 「不得」將安全雜湊值傳送到裝置外部,或與其他應用程式共用 的資料 blob (用於控制存取權)。
9.8.12。音樂辨識
Android 透過 System API MusicRecognitionManager 支援 要求音樂辨識、提供音訊錄音的裝置,以及 將音樂辨識委派給實作 MusicRecognitionService API。
如果裝置實作項目包含實作 System API 的服務 MusicRecognitionManager 或任何可串流播放音訊資料的專屬服務 功能:
- [C-1-1] 必須強制 MusicRecognitionManager 的呼叫端持有
MANAGE_MUSIC_RECOGNITION
的權限 - [C-1-2] 必須強制使用預先安裝的單一音樂辨識 應用程式實作 MusicRecognitionService
- [C-1-3] 不得允許使用者取代 MusicRecognitionManagerService 或透過可安裝的應用程式或服務 MusicRecognitionService
- [C-1-4] 「必須」確保 MusicRecognitionManagerService 存取 錄音,並轉送至應用程式 MusicRecognitionService,透過 AppOpsManager.noteOp / startOp。
如果裝置實作 MusicRecognitionManagerService MusicRecognitionService 會儲存任何擷取的音訊資料,然後:
- [C-2-1] 千萬「不得」在磁碟上儲存任何原始音訊或音訊指紋 還是在記憶體中超過 14 天
- [C-2-2] 不得向 MusicRecognitionService 以外的對象分享這類資料,但 每次分享時都要經過使用者同意。
9.8.13。SensorPrivacyManager
如果裝置的實作方式能提供使用者關閉的軟體用途 相機和/或麥克風輸入裝置,兩者會:
- [C-1-1] 必須正確傳回「true」建立相關 supportsSensorToggle() API 方法。
- [C-1-2] 「必須」、當應用程式嘗試存取遭封鎖的麥克風或相機時, 向使用者提供無法關閉的使用者預設用途, 表示感應器已封鎖,因此必須選擇才能繼續 封鎖或解除封鎖 才能正常運作
- [C-1-3] 只能將空白 (或假) 的相機和音訊資料傳遞給應用程式 且不會因為使用者未開啟相機而回報錯誤代碼 或根據上述 [C-1-2] 說明的資源配置存取麥克風。
9.9.資料儲存加密
所有裝置都必須符合第 9.9.1 節的規定。 如果裝置在本文件的 API 級別上推出,就視為 已免除 9.9.2 和 9.9.3 節的規定;而不是他們 必須符合 Android 相容性第 9.9 節的規定 與裝置啟動的 API 級別相對應的定義文件。
9.9.1。直接啟動
裝置實作方式:
[C-0-1] 即使已導入直接啟動模式 API, 不支援 Storage 加密
[C-0-2]
ACTION_LOCKED_BOOT_COMPLETED
和ACTION_USER_UNLOCKED
您仍須透過廣播,向直接啟動感知的應用程式發出信號 裝置加密 (DE) 和憑證加密 (CE) 儲存空間位置 使用者可用的資源
9.9.2。加密規定
裝置實作方式:
- [C-0-1] 必須將應用程式加密,設為不公開
資料 (
/data
個分區),以及應用程式共用儲存空間分區 (/sdcard
分區) 必須是裝置的永久性無法移除的零件。 - [C-0-2] 在預設狀態下,「必須」啟用資料儲存加密功能 使用者已完成開箱的設定體驗
[C-0-3] 必須符合上述資料儲存加密機制 ,藉此達成下列目的:
9.9.3.加密方法
如果裝置實作項目已加密,會:
- [C-1-1] 必須啟動啟動,但不要求使用者提供憑證,
允許直接啟動感知應用程式存取裝置加密 (DE) 儲存空間
ACTION_LOCKED_BOOT_COMPLETED
訊息播送後的大小 - [C-1-2] 之後,「必須」符合下列條件,才能存取憑證加密 (CE) 儲存空間
使用者提供憑證,藉此解鎖裝置
(例如密碼、PIN 碼、解鎖圖案或指紋) 和
ACTION_USER_UNLOCKED
訊息是否已播送 - [C-1-13] 「不得」提供任何解鎖 CE 保護儲存裝置的方法 使用者提供的憑證、註冊的託管金鑰或 以符合 第 9.9.4 節。
- [C-1-4] 必須使用驗證開機程序。
9.9.3.1。使用中繼資料加密功能來加密檔案
如果裝置的實作方式使用檔案型加密和中繼資料加密, 他們會:
- [C-1-5] 必須使用 AES-256-XTS 或 Adiantum。AES-256-XTS 是進階加密標準 具有 256 位元加密金鑰長度,以 XTS 模式操作;與 索引鍵為 512 位元Adiantum 是指 Adiantum-XChaCha12-AES,如 https://github.com/google/adiantum檔案系統中繼資料屬於資料,例如檔案 尺寸、擁有權、模式和延伸屬性 (xattrs)。
- [C-1-6] 必須使用 AES-256-CBC-CTS 加密檔案名稱 或 Adiantum
- [C-1-12] 如果裝置採用進階加密標準 (AES) 指示 (例如 ARMv8 密碼學擴充功能 (ARM 型裝置上的 ARMv8 加密擴充功能),或 x86 型裝置上的 AES-NI),然後是上述的 AES 選項 檔案內容和檔案系統中繼資料加密機制 必須使用,而非 Adiantum
- [C-1-13] 必須使用加密高強度且無法復原的金鑰 衍生函式 (例如 HKDF-SHA512),以便衍生任何所需子鍵 (例如 例如 CE 和 DE 金鑰,「加密編譯」、 不可撤銷」代表金鑰衍生功能的安全性強度 至少為 256 位元,且行為做為偽隨機函式 家人 而非輸入內容
- [C-1-14] 不得使用相同的檔案式加密 (FBE) 金鑰或子金鑰 用於不同的加密編譯用途 (例如同時用於加密與金鑰) 衍生,或兩種不同的加密演算法)。
- [C-1-15] 「必須」確保未刪除的加密檔案內容區塊全都 永久儲存空間是由加密金鑰和 相依檔案和內部偏移 檔案。另外,除非 加密是透過僅支援 IV 長度為 32 位元。
- [C-1-16] 必須確保持續儲存所有未刪除的加密檔案名稱 分別用於加密不同目錄中的 包括加密金鑰和初始化向量 (IV),
[C-1-17] 「必須」確保所有加密檔案系統中繼資料封鎖 永久儲存空間是以不同的加密金鑰組合進行加密 以及初始化向量 (IV)。
保護 CE 和 DE 儲存區域,以及檔案系統中繼資料的金鑰:
- [C-1-7] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。 這個 KeyStore「必須」繫結於驗證開機程序和裝置硬體 信任根
- [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
- [C-1-9] 當使用者使用 未指定螢幕鎖定憑證。
- [C-1-10] 必須提供獨特且不同的內容,亦即使用者的 CE 或 DE 金鑰比對其他使用者的 CE 或 DE 金鑰。
- [C-1-11] 必須採用強制性支援的加密機制、金鑰長度和 。
- [C-1-12] 在系統啟動載入程式解鎖和鎖定時,必須安全地清除資料 ,請參閱這裡的說明。
應使用預先安裝的必要應用程式 (例如鬧鐘、電話、Messenger) 感應啟動感知。
上游 Android 開放原始碼專案提供了偏好的實作方式 以 Linux 核心「fscrypt」為基礎的檔案式加密加密功能 和中繼資料加密機制 (以 Linux 核心「dm-default-key」為基礎)而不是每個特徵的分數
9.9.3.2。每位使用者區塊層級加密
如果裝置的實作方式採用個別使用者區塊層級加密,則:
- [C-1-1] 「必須」啟用第 9.5 節所述的多使用者支援功能。
- [C-1-2] 必須為每個使用者提供分區,使用原始分區或 邏輯磁碟區
- [C-1-3] 每位使用者都必須使用不重複的加密金鑰 基礎區塊裝置的加密
[C-1-4] 必須使用 AES-256-XTS 為使用者進行區塊層級加密 多個分區
保護每位使用者區塊層級加密裝置的金鑰:
- [C-1-5] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。 這個 KeyStore「必須」繫結於驗證開機程序和裝置硬體 信任根
- [C-1-6] 必須繫結至對應使用者的螢幕鎖定畫面 憑證
您可以使用 Linux 核心實作每位使用者區塊層級的加密作業 「dm-crypt」而非每位使用者的分區
9.9.4。重新啟動時繼續
在重新啟動時重新啟用應用程式,可以解鎖所有應用程式的 CE 儲存空間,包括這些應用程式 但請注意,在透過 OTA 啟動的重新啟動後,尚不支援直接啟動功能。這個 功能可讓使用者在安裝 。
「在重新啟動時繼續」的實作必須持續確保 裝置落入攻擊者手中 攻擊者可復原使用者的 CE 加密資料,即使裝置電源 已開啟,取得 CE 儲存空間,而使用者在收到裝置後, OTA 也沒有限制為防止內部人員攻擊,我們也會假設攻擊者 以播送加密編譯簽署金鑰
具體違規事項如下:
[C-0-1] 即使是實際擁有憑證的攻擊者,也「不得」讀取 CE 儲存空間 裝置使用者,也會有下列功能和限制:
- 可使用任何廠商或公司的簽署金鑰來任意簽署 訊息。
- 這可能會導致裝置接收 OTA。
- 可以修改任何硬體 (AP、Flash 等) 的作業,但 以下詳細說明,但這類修改至少需要 和重新開機會破壞 RAM 內容。
- 無法修改防竄改硬體 (例如 Titan M) 的運作情形。
- 無法讀取使用中裝置的 RAM。
- 無法取得使用者的憑證 (PIN 碼、解鎖圖案、密碼),或 否則就會被輸入。
舉例來說,應用程式實作的裝置實作方式 如要瞭解詳細的說明,請參閱這篇文章 符合 [C-0-1] 的規範。
9.10。裝置完整性
下列規定可確保 裝置完整性。裝置實作方式:
[C-0-1] 必須使用系統 API 方法正確回報
PersistentDataBlockManager.getFlashLockState()
是否為系統啟動載入程式 允許刷新系統映像檔。[C-0-2] 必須支援驗證開機程序,確保裝置完整性。
如果裝置已啟動,不支援驗證開機程序 舊版 Android,無法支援這項功能 系統軟體更新的功能,可能不受 才能正常運作
驗證開機程序可保證裝置完整性 軟體如果裝置導入方式支援這項功能,就會執行以下動作:
- [C-1-1] 必須宣告平台功能旗標
android.software.verified_boot
。 - [C-1-2] 必須在每個啟動序列中執行驗證作業。
- [C-1-3] 必須使用不可變更的硬體金鑰 (即 並會移往系統分區。
- [C-1-4] 必須實作每個驗證階段,才能檢查完整性 所有位元組的真實性,且在 進入下一階段
- [C-1-5] 務必使用驗證演算法,盡可能維持既有狀態 NIST 對雜湊演算法 (SHA-256) 和公開金鑰的建議 (RSA-2048)。
- [C-1-6] 系統驗證失敗時,不得允許啟動。 除非使用者同意繼續啟動,在這種情況下, 「不得」使用任何未經驗證的儲存空間區塊。
- [C-1-7] 「不得」允許修改裝置上已驗證的分區 除非使用者明確解鎖系統啟動載入程式。
- [C-SR-1] 如果裝置上有多個獨立晶片 (例如無線電、 專用的映像檔處理器),各個晶片的啟動程序 強烈建議在啟動時驗證每個階段。
- [C-1-8] 必須使用防竄改儲存空間,以便儲存 系統啟動載入程式已解鎖。防竄改儲存空間機制是指系統啟動載入程式 偵測儲存空間是否遭到 Android 內部竄改
- [C-1-9] 必須在使用裝置時提示使用者 允許系統啟動載入程式轉移程序前,必須取得實體確認權限 並鎖定模式進入系統啟動載入程式解鎖模式。
- [C-1-10] 必須針對 Android 使用的分區導入復原保護機制 (例如啟動程序、系統分區) 並使用防竄改儲存空間儲存 中繼資料,用於判斷系統允許的最小 OS 版本。
- [C-1-11] 必須在系統啟動載入程式解鎖期間,安全地清除所有使用者資料, 如 '9.12.資料刪除(包括使用者資料分區和 任何 NVRAM 聊天室)。
- [C-SR-2] 強烈建議使用以下憑證驗證所有具有特殊權限的應用程式 APK 檔案: 受驗證開機程序保護的分區中的信任鏈結。
- [C-SR-3] 強烈建議驗證 從其 APK 檔案之外具有特殊權限的應用程式 (例如動態載入的程式碼或 或強烈「建議」不要執行這些程式碼 。
- 必須為任何具有永久性設定的元件導入復原保護機制 韌體 (例如數據機、相機) 以及「應使用防破壞儲存」 儲存中繼資料,用來決定系統允許的最低版本。
如果裝置已啟動裝置實作項目,但未支援 C-1-8 到 C-1-8 舊版 Android 上的 C-1-11,無法新增 安裝系統軟體更新的要求,這些程式「可能」已免於 Google Cloud 就是最佳選擇
上游 Android 開放原始碼計畫提供了偏好的實作方式
這項功能 (external/avb/
)
存放區,可與系統載入的系統啟動載入程式整合
Android。
裝置實作方式:
- [C-0-3] 必須支援以加密編譯的方式驗證檔案內容, 不必讀取整個檔案。
- [C-0-4] 「不得」允許受保護檔案的讀取要求成功 讀取內容未經信任的金鑰驗證時。
如果裝置已經啟動,但沒有進行驗證 在較舊的 Android 版本中,依據可信任金鑰的檔案內容,且無法新增 透過系統軟體更新這項功能支援這項功能,但這類支援 。上游 Android 開放原始碼專案提供了 偏好實作這項功能,以 Linux kernel fs-verity 功能為基礎。
裝置實作方式:
- [C-SR-4] 強烈建議支援 Android Protected Confirmation API。
如果裝置實作支援 Android 保護確認 API 的用途:
[C-3-1] 必須回報
ConfirmationPrompt.isSupported()
的true
也能使用 Google Cloud CLI 或 Compute Engine API[C-3-2] 必須確保在 Android 作業系統中執行的程式碼,包括 核心、惡意或其他行為,在沒有不良行為的情況下,就無法產生正面回應 互動。
[C-3-3] 必須確認使用者能夠查看並核准 在 Android 作業系統 (包括其核心) 的情況下 遭到破解。
9.11.金鑰和憑證
Android KeyStore 系統 可讓應用程式開發人員將加密編譯金鑰儲存至容器,並在容器中使用 透過 KeyChain API 執行加密編譯作業 或是 Keystore API 裝置實作方式:
- [C-0-1] 至少須允許匯入或產生 8,192 組金鑰。
- [C-0-2] 螢幕鎖定驗證必須導入時間間隔 。如果 n 為失敗次數, 9< > 間隔必須至少為 30 秒n <30.對於 n >29、 時間間隔值必須至少為 30*2^floor((n-30)/10) 秒,或 至少 24 小時 (以較短者為準)。
- 不應限制可產生的金鑰數量
如果實作的裝置支援安全螢幕鎖定,它會:
- [C-1-1] 必須使用獨立的 執行環境
- [C-1-2] 必須導入 RSA、AES、ECDSA ECDH (如果支援 IKeyMintDevice)、3DES、 以及 HMAC 密碼編譯演算法,以及 MD5、SHA1 和 SHA-2 系列雜湊 能夠妥善支援 Android KeyStore 系統支援的函式 所在區域的演算法,安全地與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境,包括《數位市場法》上游 Android 開放原始碼 Project (Android 開放原始碼計畫) 使用 值得信賴,但 其他以 ARM TrustZone 為基礎的解決方案,或是由第三方人員 可替代實作方式,以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
- [C-1-3] 必須在獨立環境中執行螢幕鎖定驗證 執行環境,且僅在成功時允許驗證繫結 要使用的金鑰螢幕鎖定憑證必須儲存在 以便僅允許獨立的執行環境執行螢幕鎖定 驗證。上游 Android 開放原始碼計畫 總機人員硬體抽象層 (HAL) 和 Trusty 合作,以滿足這項需求
- [C-1-4] 必須支援認證簽署金鑰所在的金鑰認證 受安全硬體的保護,而且是在安全的硬體中執行。 必須讓一定數量的範圍內共用認證簽署金鑰 防止金鑰做為裝置 ID 使用單程 您符合這項規定,就是共用相同認證金鑰,除非: 系統針對特定 SKU 產生至少 100,000 個單位。如果超過 100,000 個單位 則每 100,000 個單位可能會使用不同的索引鍵。
請注意,如果裝置已啟動至較舊的 Android 版本
這類裝置不受具有 KeyStore 的限制
並支援金鑰認證
除非宣告了 android.hardware.fingerprint
功能,而該功能需要
由獨立執行環境支援的 KeyStore。
- [C-1-5] 必須允許使用者選擇 並鎖定為鎖定狀態,且最短允許的逾時期限 15 秒。可隨車用運算主機鎖定螢幕的 Automotive 裝置 關閉或使用者切換,可能「沒有」睡眠逾時的情況 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定
- [C-1-6] 必須支援下列其中一種帳戶:
- IKeymasterDevice 3.0、
- IKeymasterDevice 4.0
- IKeymasterDevice 4.1、
- IKeyMintDevice 版本 1,或
- IKeyMintDevice 版本 2。
- [C-SR-1] 極力建議支援 IKeyMintDevice 版本 1。
9.11.1.保護螢幕鎖定、驗證及虛擬裝置
Android 開放原始碼計畫的實作方式採用分層驗證模型,其中 知識庫的主要驗證機制可由 第二種高強度生物特徵辨識或低階形式。
裝置實作方式:
- [C-SR-1] 強烈建議你只將下列其中一種設定設為主要驗證方式
方法:
- 數字 PIN
- 英數字元密碼
- 3x3 點狀格線中的滑動模式
請注意,上述驗證方法稱為 主要驗證方法。
如果裝置實作方式新增或修改建議的主要驗證方式 並運用新的驗證方法鎖定螢幕, 新的驗證方法:
- [C-2-1] 必須如 要求驗證使用者以使用金鑰。
如果裝置導入作業新增或修改要解鎖的驗證方法 鎖定螢幕 (以已知的密鑰為依據),並使用新的驗證方式 方法才是鎖定螢幕的安全方式:
- [C-3-1] 允許的最短輸入長度必須達到 大於 10 位元
- [C-3-2] 所有可能輸入值的最大熵「必須」大於 18 位元。
- [C-3-3] 新的驗證方法「不得」取代任何 建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 所提供的解決方案。
- [C-3-4] 啟用新的驗證方式後, 裝置政策控制器 (DPC) 應用程式已設定密碼 透過 Google Cloud 控制台 DevicePolicyManager.setRequiredPasswordComplexity() 並使用較受限的複雜度常數 PASSWORD_COMPLEXITY_NONE 或透過 DevicePolicyManager.setPasswordQuality() 設定 方法,常數大於 100 的 PASSWORD_QUALITY_BIOMETRIC_WEAK。
- [C-3-5] 新的驗證方法「必須」改回使用 建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、 密碼),或是清楚向 使用者可能導致部分資料不會因為 保護自身資料的隱私權
如果裝置實作方式新增或修改建議的主要驗證方式 解鎖螢幕鎖定的方法,以及使用 新技術是採用生物特徵辨識技術 偵測裝置是否安全 方法:
- [C-4-1] 必須符合一節所述的所有規定 7.3.10,適用於第 1 級 (舊稱) 便利性)。
- [C-4-2] 必須設有備用機制,才能使用建議選項 主要驗證方法。
- [C-4-3] 必須停用,且只允許使用建議的主要執行個體
驗證以解鎖螢幕時,裝置政策控制器 (DPC)
應用程式已透過呼叫 方法設定鍵盤保護功能政策
DevicePolicyManager.setKeyguardDisabledFeatures()
敬上 ,使用任何相關的生物特徵辨識旗標 (例如KEYGUARD_DISABLE_BIOMETRICS
、KEYGUARD_DISABLE_FINGERPRINT
、KEYGUARD_DISABLE_FACE
或KEYGUARD_DISABLE_IRIS
)。
如果生物特徵辨識驗證方式不符合需求 適用於第 3 級 (前身為「Strong」),如上述內容所述 第 7.3.10 節:
- [C-5-1] 裝置政策控制器 (DPC) 「必須」停用這些方法
應用程式已透過
DevicePolicyManager.setRequiredPasswordComplexity()
使用比
PASSWORD_COMPLEXITY_LOW
限制更複雜的值區 或使用 DevicePolicyManager.setPasswordQuality() 方法是使用較嚴格的品質常數PASSWORD_QUALITY_BIOMETRIC_WEAK
。 - [C-5-2] 必須要求使用者驗證推薦的首選主要電話號碼 驗證 (例如:PIN 碼、解鎖圖案、密碼),方法如 [C-1-7] 和 [C-1-8],請參閱第 7.3.10 節。
- [C-5-3] 這些方法「不得」視為安全螢幕鎖定。 符合本節中以 C-8 開頭的相關規定。
如果裝置導入作業新增或修改要解鎖的驗證方法 鎖定螢幕,而新的驗證方法是以實體權杖為基礎 或是位置:
- [C-6-1] 他們「必須」採用備用機制,才能使用建議的 主要驗證方式,以已知密鑰為基礎, 才是安全螢幕鎖定。
- [C-6-2] 必須停用新方法,且僅允許以下其中一種:
建議的主要驗證方法
裝置政策控制器 (DPC) 應用程式已採用以下其中一項設定:
-
DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
敬上 種方式 -
DevicePolicyManager.setPasswordQuality()
敬上 方法是使用較嚴格的品質常數PASSWORD_QUALITY_NONE
。 DevicePolicyManager.setRequiredPasswordComplexity()
方法,複雜程度比PASSWORD_COMPLEXITY_NONE
。
-
- [C-6-3] 必須要求使用者接受其中一項建議的主要執行個體 至少每隔一次驗證方式 (PIN 碼、解鎖圖案、密碼) 驗證 4 小時。當實體權杖符合 C-X 中 TrustAgent 實作方面的需求、逾時限制 則會套用 C-9-5 所定義。
- [C-6-4] 「不得」將新方法視為安全螢幕鎖定 遵循下列 C-8 中所列的限制。
如果裝置導入了安全螢幕鎖定,且包含一或多個
實作 TrustAgentService
System API 的信任代理程式,這類代理程式會:
- [C-7-1] 必須在設定選單和居家鎖上清楚標示 裝置鎖定螢幕。 舉例來說,Android 開放原始碼計畫會顯示 「自動鎖定設定」以及「電源鍵立即鎖定」的 設定選單和螢幕鎖定畫面上可清楚辨識的圖示。
- [C-7-2] 必須尊重並完整導入
DevicePolicyManager
類別,例如KEYGUARD_DISABLE_TRUST_AGENTS
常數。 - [C-7-3] 「不得」完全導入
TrustAgentService.addEscrowToken()
功能,在做為主要個人裝置使用 例如手持裝置,但可以在裝置上完整實作這個函式 常見的分享模式 (例如 Android TV 或 Automotive 裝置)。 - [C-7-4] 必須加密儲存
TrustAgentService.addEscrowToken()
。 - [C-7-5] 「不得」將加密金鑰或託管權杖儲存在 和使用車鑰的裝置舉例來說, 儲存在手機上的金鑰,以便在電視上解鎖使用者帳戶。 汽車無法儲存信託權杖 車輛的任何零件都沒問題
- [C-7-6] 必須在 啟用託管權杖以解密資料儲存空間。
- [C-7-7] 必須採用備用機制,才能使用建議選項 主要驗證方法。
- [C-7-8] 必須要求使用者接受任一推薦的主任 至少每 72 次驗證一次驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 小時,除非使用者的安全 (例如駕駛人分心) 為止 因此不必擔心
- [C-7-9] 必須要求使用者接受任一建議的主要執行個體 驗證 (例如:PIN 碼、解鎖圖案、密碼) 方法, 如第 7.3.10 節中的 [C-1-7] 和 [C-1-8],除非 使用者安全 (例如駕駛人分心) 具有疑慮。
- [C-7-10] 不得視為安全螢幕鎖定,且必須遵守 限制條件。
- [C-7-11] 不得允許主要個人裝置上的 TrustAgents 使用 (例如手持裝置) 解鎖裝置,且只能用來 讓已解鎖裝置保持在解鎖狀態 最長 4 小時。預設實作 Android 開放原始碼計畫中的 TrustManagerService 符合這項規定。
- [C-7-12] 必須使用加密編譯的安全機制 (例如 UKEY2) 將託管符記從儲存體中傳遞 複製到目標裝置
如果裝置導入作業新增或修改要解鎖的驗證方法 也就是不是上述的安全鎖定畫面,然後 新的鍵盤鎖解鎖方法:
- [C-8-1] 裝置政策控制器「必須」停用新方法
(DPC) 應用程式已透過
DevicePolicyManager.setPasswordQuality()
敬上 方法是使用較嚴格的品質常數PASSWORD_QUALITY_NONE
或透過DevicePolicyManager.setRequiredPasswordComplexity()
並使用較受限的複雜度常數 「PASSWORD_COMPLEXITY_NONE」。 - [C-8-2] 使用者「不得」重設
DevicePolicyManager.setPasswordExpirationTimeout()
。 - [C-8-3] 使用者「不得」向第三方應用程式公開 API 使用 API 變更鎖定狀態
如果裝置實作允許應用程式建立次要執行個體
虛擬螢幕
不支援相關聯的輸入事件,例如透過
VirtualDeviceManager
、
他們會:
- [C-9-1] 預設顯示器處於鎖定狀態,並在下列情況下解鎖這些次要虛擬螢幕: 裝置的預設螢幕已解鎖。
如果實作裝置,可讓應用程式建立次要虛擬螢幕和支援相關輸入來源 事件 (例如透過 VirtualDeviceManager) 可以觸發以下動作:
- [C-10-1] 必須為每個虛擬裝置支援獨立的鎖定狀態
- [C-10-2] 必須在閒置逾時時中斷所有虛擬裝置的連線
- [C-10-3] 必須設定閒置逾時
- [C-10-4] 當使用者啟動 鎖定功能,包括 根據手持裝置所需的鎖定式使用者預設用途 (請參閱 第 2.2.5 節 [9.11/H-1-2])
- [C-10-5] 每位使用者都必須有獨立的虛擬裝置執行個體
- [C-10-6] 必須停用相關輸入事件的建立功能:
VirtualDeviceManager
(如以下情況表示)DevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] 必須為每個虛擬裝置使用個別的剪貼簿 (或為虛擬裝置停用剪貼簿)
- [C-10-11] 必須在虛擬裝置上停用驗證 UI,包括 知識因素輸入和生物特徵辨識提示
- [C-10-12] 必須限制顯示透過虛擬裝置啟動的意圖 只會在同個虛擬裝置上運作
- [C-10-13] 不得使用虛擬裝置鎖定狀態做為使用者驗證方式
取得 Android KeyStore 系統的授權。詳情請見
KeyGenParameterSpec.Builder.setUserAuthentication*
。
如果裝置實作項目允許使用者轉移主要裝置 從來源裝置到目標裝置的驗證知識因素 例如:進行目標裝置的初始設定時,他們會:
- [C-11-1] 必須加密知識因素,保護保證類似於 這些 Pod 中 Google Cloud Key Vault 服務 傳輸安全性白皮書 從來源裝置到目標裝置的知識因素 知識因子無法從遠端解密或用於遠端解鎖 任一裝置。
- [C-11-2] 必須在來源裝置上要求使用者確認 來源裝置的知識因素,再轉移知識因素 複製到目標裝置
- [C-11-3] 必須,目標裝置上未設定任何主要驗證方式 並請使用者確認轉移的知識因素 將知識因素設為主要裝置 驗證知識因素 可使用從來源裝置轉移的任何資料。
如果裝置導入了安全螢幕鎖定,且包含一或多個
可藉由信任代理程式呼叫 TrustAgentService.grantTrust()
System API
FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
標記會:
- [C-12-1] 連線至
grantTrust()
以及設有螢幕鎖定畫面的鄰近實體裝置 以該螢幕鎖定方式驗證身分。透過 Proxy 傳送裝置 在使用者單次解鎖後,使用腕上或人體感測機制 滿足使用者驗證要求 - [C-12-2] 必須將裝置實作加入
TrustState.TRUSTABLE
螢幕關閉時 (例如按下按鈕或螢幕關閉) 逾時),且 TrustAgent 並未撤銷信任。Android 開放原始碼計畫符合要求 這項規定。 - [C-12-3] 只能將裝置從「
TrustState.TRUSTABLE
」移到TrustState.TRUSTED
狀態:表示 TrustAgent 仍會依據 C-12-1 中的需求條件。 - [C-12-4] 必須撥打
TrustManagerService.revokeTrust()
- 最多 24 小時後才取得信任,
- 8 小時閒置期間之後,或
- 如果實作方式未使用加密編譯安全 準確度 (如 [C-12-5] 中定義) 位置相差甚遠。
- [C-12-5] 導入仰賴安全準確的範圍, 要求 [C-12-4] 必須使用下列其中一種解決方案:
如果實作裝置,可讓應用程式建立次要虛擬螢幕和支援相關輸入來源 事件,例如透過 VirtualDeviceManager 且螢幕未標示為 VIRTUAL_DISPLAY_FLAG_SECURE,它們:
- [C-13-8] 必須封鎖含有 android:canDisplayOnRemoteDevices 屬性或中繼資料 android.activity.can_display_on_remote_devices 設為 false 的 活動,才能在虛擬上啟動 裝置。
- [C-13-9] 必須封鎖活動 這些元件不會明確啟用串流 指出它們會顯示機密內容,包括透過 SurfaceView#setSecure FLAG_SECURE 或 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS 則是透過虛擬裝置啟動
如果裝置實作方式可透過以下方式支援個別螢幕電源狀態:
DeviceStateManager
,並且透過以下方式支援不同的螢幕鎖定狀態
KeyguardDisplayManager
,他們:
- [C-SR-2] 強烈建議使用憑證會議 要求 (根據第 9.11.1 節定義) 或至少從事生物特徵辨識會議 第 1 級規格 (根據第 7.3.10 節) 定義的規格, 。
- [C-SR-3] 強烈建議你限制個別螢幕的解鎖方式 並傳回相關內容
- [C-SR-4] 強烈建議使用者全面鎖定所有螢幕 從主要手持裝置鎖定後開始鎖定
9.11.2。強固盒
Android KeyStore 系統可讓您 應用程式開發人員將加密編譯金鑰儲存在專屬的安全處理器中 以及上述的獨立執行環境如此 專用的安全處理器稱為「StrongBox」。需求 C-1-3 至下方的 C-1-11 表單,定義裝置必須符合哪些要求 符合 StrongBox 資格
具備專用安全處理器的裝置實作方式:
- [C-SR-1] 強烈建議支援 StrongBox。StrongBox 會 可能會成為日後版本中的必要條件
如果裝置的實作支援 StrongBox,他們會:
[C-1-1] 必須宣告 FEATURE_STRONGBOX_KEYSTORE。
[C-1-2] 「必須」提供用於背蓋的專屬安全硬體 KeyStore 和安全的使用者驗證。專屬的 硬體產品也可以用於其他用途
[C-1-3] 必須採用不共用快取、DRAM 和輔助處理器的獨立 CPU 或其他核心資源與應用程式處理器 (AP) 搭配使用。
[C-1-4] 必須確保與 AP 共用的所有周邊裝置均無法修改 以任何方式處理 StrongBox,或從 StrongBox 取得任何資訊。 AP 可能會停用或封鎖 StrongBox 存取權。
[C-1-5] 必須具有合理的內部時鐘 (+-10%) 不會遭到 AP 操控
[C-1-6] 必須具備真正的隨機號碼產生器 均勻分佈且無法預測的輸出內容。
[C-1-7] 必須防範竄改行為,包括抵抗各種攻擊 就是能達到的實體滲透率和毛刺
[C-1-8] 必須面對旁視力 (包括抵抗性攻擊) 利用功率、時間、電磁輻射和熱力洩漏資訊 輻射側聲道。
[C-1-9] 「必須提供」安全儲存空間,確保機密性 完整性、真實性、一致性和即時性 內容。「不得」讀取或修改儲存體,除非是 。
為了驗證符合 [C-1-3] 至 [C-1-9] 規範,裝置 實作:
- [C-1-10] 必須包含針對 安全 IC 保護設定檔 BSI-CC-PP-0084-2014 或 經由國家認證實驗室評估 高度攻擊潛在安全漏洞的評估依據 可能遭受攻擊的共通準則 智慧型卡片。
- [C-1-11] 必須包含由 經國家認可的測試實驗室結合高攻擊 評估潛在安全漏洞 適用於智慧型卡片可能遭受攻擊的共通準則。
- [C-SR-2] 強烈建議你納入 使用安全目標、評估保證等級進行評估 (EAL) 5,以 AVA_VAN.5 擴增。EAL 5 認證可能會 成為未來版本中的必要條件
- [C-SR-3] 強烈建議提供內部人士攻擊抵抗 (IAR),也就是能存取韌體簽署的內部人員 金鑰無法產生導致 StrongBox 外洩的韌體 規避功能性安全性要求 讓使用者存取敏感的使用者資料。建議的 IAR 僅允許使用主要使用者密碼更新韌體 是透過 IAuthSecret HAL 提供
9.11.3.身分憑證
識別資訊憑證系統是由所有實作
API 中的
android.security.identity.*
敬上
套件。應用程式開發人員可利用這些 API 儲存及擷取使用者身分
文件。裝置實作方式:
- [C-SR-1] 強烈建議導入身分憑證 系統:
如果裝置的實作實作了身分識別憑證系統,就會:
[C-1-1] 必須針對 IdentityCredentialStore#getInstance() 傳回非空值 方法。
[C-1-2] 必須實作身分識別憑證系統 (例如
android.security.identity.*
API) 與透過信任存放區通訊的程式碼 應用程式區域,而且與執行程式碼的 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境,包括《數位市場法》[C-1-3] 實作身分所需的加密編譯作業 憑證系統 (例如
android.security.identity.*
API) 必須 「必須」在信任應用程式及私密金鑰內容中執行 除非特別需要,否則一律不要離開獨立的執行環境 與較高層級的 API (例如 createEphemeralKeyPair() 方法)。[C-1-4] 信任的應用程式「必須」採用 安全屬性不會受到影響 (例如:未發布憑證資料 除非滿足存取權控管條件,否則系統無法為 任意資料)。
上游 Android 開放原始碼計畫提供了參考資料 信任的應用程式的實作 (libeic) 用於實作身分識別憑證系統。
9.12.資料刪除
所有裝置實作方式:
- [C-0-1] 「必須」為使用者提供執行「恢復原廠設定」的機制。
- [C-0-2] 執行 「恢復原廠設定」。
- [C-0-3] 請務必以符合相關需求的方式刪除資料 例如 NIST SP800-88 等業界標準, 重設」的訊息。
- [C-0-4] 必須觸發上述的「恢復原廠設定」處理完成後
DevicePolicyManager.wipeData()
敬上 API 是由主要使用者的 Device Policy Controller 應用程式呼叫。 - 可能提供快速清除資料選項,只可執行邏輯資料清除作業。
9.13.安全啟動模式
Android 提供安全啟動模式,可讓使用者開機並進入模式 只允許預先安裝的系統應用程式,且所有第三方 應用程式已停用。這個模式稱為「安全啟動模式」,可讓使用者 解除安裝可能有害的第三方應用程式。
裝置導入方式如下:
- [C-SR-1] 強烈建議你導入安全啟動模式。
如果裝置實作了安全啟動模式,就會:
[C-1-1] 必須為使用者提供 以無法外部第三方中斷的方式進入安全啟動模式 裝置上安裝的應用程式,但第三方應用程式為 同時設定了
UserManager.DISALLOW_SAFE_BOOT
敬上 標記為 true[C-1-2] 必須讓使用者能夠 在安全模式中解除安裝任何第三方應用程式。
應為使用者提供透過該選項進入安全啟動模式的選項 啟動選單,但此模式的工作流程與一般啟動程序不同。
9.14。汽車車輛系統隔離
Android Automotive 裝置應與重要車輛交換資料 車輛 HAL ,透過 CAN 公車等車輛網路收發訊息。
導入下列安全性功能,即可確保資料交換機制安全無虞 Android 架構層可防範惡意或無意間與應用程式互動 這些子系統
9.15。訂閱計畫
「訂閱方案」請參閱我們提供的計費關係方案詳細資料
由行動電信業者提供
SubscriptionManager.setSubscriptionPlans()
。
所有裝置實作方式:
- [C-0-1] 必須只將訂閱方案退還給符合下列條件的行動電信業者應用程式: 。
- [C-0-2] 「不得」從遠端備份或上傳訂閱方案。
- [C-0-3] 只能允許覆寫值,例如
SubscriptionManager.setSubscriptionOverrideCongested()
、 。
9.16。應用程式資料遷移
如果裝置實作具有將資料從裝置遷移至雲端的功能 ,且不限制複製的應用程式資料 是由應用程式開發人員透過資訊清單設定 android:fullBackupContent 屬性:
- [C-1-1] 「不得」從以下來源啟動應用程式資料轉移程序: 使用者尚未將主要驗證設為 描述 9.11.1 安全螢幕鎖定和驗證。
- [C-1-2] 必須安全地確認來源的主要驗證方式 ,確認使用者意圖在來源中複製資料 裝置才會轉移任何資料。
- [C-1-3] 「必須」使用安全金鑰認證來確保 在裝置對裝置之間遷移時,系統會偵測出裝置本身和目標裝置, 合法的 Android 裝置,並且系統啟動載入程式已鎖定。
- [C-1-4]「必須」只將應用程式資料遷移至 並使用相同的套件名稱「和」簽署憑證。
- [C-1-5] 必須顯示來源裝置已包含資料 則透過設定選單遷移裝置間資料。使用者 「不得」移除此跡象。
9.17。Android 虛擬化架構
如果裝置實作 Android 虛擬化架構 API (android.system.virtualmachine.*
) 的支援功能,Android 主機會執行以下動作:
- [C-1-1] 必須支援
android.system.virtualmachine.*
套件。 - [C-1-2] 「不得」修改 這項解決方案可讓您更輕鬆地管理受保護的虛擬機器
- [C-1-3] 不得修改、省略或取代 上游 Android 開放原始碼計畫中提供的系統/sepolicy (AOSP) 和政策都必須以所有永不允許的規則進行編譯。
- [C-1-4] 不得允許不信任的程式碼 (例如第三方應用程式) 建立及執行 受保護的虛擬機器。 注意:日後的 Android 版本中可能會發生變更。
- [C-1-5] 不得允許受保護的虛擬機器執行 並未包含在原廠映像檔或其更新範圍內。上述內容不在保固範圍內 經由 Android 驗證開機程序 (例如從網際網路或 側載)「不得」在受保護的虛擬機器中執行。
如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*
) 的支援功能,則代表所有 Protected Virtual Machine 執行個體:
- [C-2-1] 必須能夠執行 虛擬化 APEX
- [C-2-2] 「不得」允許受保護的虛擬機器執行作業系統 未經裝置實作者或 OS 廠商簽署。
- [C-2-3] 「不得」允許受保護的虛擬機器以程式碼形式執行資料 (例如 SELinux 從未允許 execmem)。
- [C-2-4] 不得修改、省略或取代 上游 Android 開放原始碼提供的 system/sepolicy/microdroid 專案 (AOSP)。
- [C-2-5] 必須實作受保護的虛擬機器深度防禦機制 (例如 pVM 適用的 SELinux),甚至是非 Microdroid 作業系統。
- [C-2-6] 必須確保 pVM 韌體會在無法驗證時拒絕啟動 加入更多雜訊
- [C-2-7] 必須確保完整性時,pVM 韌體會拒絕啟動 instance.img 遭入侵
如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*
) 的支援,則管理程序:
- [C-3-1] 不得允許任何 pVM 存取屬於其他的頁面 以外的實體 (即其他 pVM 或管理程序),除非網頁明確提供這項資訊 擁有者。其中包括主機 VM。CPU 和 DMA 存取均適用此規定。
- [C-3-2] 當 VM 使用網頁後,請一律清除該網頁的資料,系統才會傳回網頁 傳送至主機 (例如 pVM 遭刪除)。
- [C-3-3] 必須確保在 或部署於 pVM 中的任何程式碼
- [C-3-4] 必須確保將 BCC 和 CDI 提供給 pVM 執行個體 所有衍生自該特定執行個體
如果裝置實作 Android 虛擬化架構 API 的支援功能, 然後涵蓋所有領域:
- [C-4-1] 不得向允許略過 Android 安全性模型。
如果裝置實作 Android 虛擬化架構 API 的支援功能,則:
- [C-5-1] 必須支援 ART 執行階段更新的隔離編譯功能。
如果裝置實作 Android Virtualization Framework API 的支援功能,則針對金鑰管理機制:
- [C-6-1] 根層級 DICE 鏈結必須在使用者無法修改的地方 (即便是 並解鎖裝置。(這是為了確保不被假冒)。
- [C-6-2] 請務必正確做 DICE,亦即提供正確的值。
10. 軟體相容性測試
裝置實作「必須」通過本節所述的所有測試。 不過請注意,沒有完整的軟體測試套件。 因此,我們強烈建議裝置實作者 參考檔案與首選檔案變更次數下限 Android 開放原始碼計畫提供的 Android 實作。 這麼做可將引入不相容的錯誤風險降至最低 需重新作業及可能更新裝置。
10.1.Compatibility Test Suite
裝置實作方式:
[C-0-1] 必須通過 Android Compatibility Test Suite (CTS) ,使用最終的運送服務 安裝該軟體
[C-0-2] 必須確保 CTS 與任何 重實作參考原始碼的部分內容。
CTS 的設計宗旨是在實際裝置上執行。和任何軟體一樣,CTS 本身可能包含昆蟲CTS 的版本會與 相容性定義,以及可能發布的多個 CTS 修訂版本 Android 13。
裝置實作方式:
[C-0-3] 必須通過裝置當下可用的 CTS 版本 或是軟體已完成
應使用 Android 開放原始碼樹中的參考實作
10.2.CTS 驗證器
Compatibility Test Suite 隨附 CTS Verifier 目的在於由真人操作人員執行,以測試無法支援的功能 例如相機功能的正確性 感應器。
裝置實作方式:
- [C-0-1] 「必須」正確執行 CTS 驗證器中的所有適用案例。
CTS Verifier 針對多種硬體進行了測試,包括部分硬體。 非必填
裝置實作方式:
- [C-0-2] 必須通過他們擁有的所有硬體測試。例如 如果裝置具備加速計,則應「必須」正確執行 CTS Verifier 中的加速計測試案例。
測試相容性定義為選用功能的情況 文件可能會略過或省略。
- [C-0-2] 每部裝置和每個版本都必須正確執行 CTS Verifier 如上所述。不過,由於許多版本非常相似, 實作者不應在建構時明確執行 CTS Verifier 只有稍有不同具體來說,這類裝置導入作業 不同於過去只通過 CTS 驗證器的實作 包含一組包含的地區、品牌宣傳等。但可以省略 CTS 驗證器測試。
11. 可更新的軟體
[C-0-1] 裝置的實作「必須」提供用來取代 整個系統軟體機制不需執行「即時」 升級,也就是說,裝置可能要重新啟動。 任何方法都可以使用,前提是它可以取代 裝置上預先安裝的軟體。例如以下任一種 能滿足這項需求的方法:
- 「無線更新」(OTA)下載成離線更新。
- 「網路共用」從主機電腦透過 USB 更新。
- 「離線」即可進行更新,並透過卸除式儲存空間中的檔案更新。
[C-0-2] 使用的更新機制「必須」支援更新,但使用者不需抹除使用者 資料。也就是說,更新機制「必須」保留應用程式的私人資料, 應用程式共用資料。請注意,上游 Android 軟體包含 配合這項需求條件。
[C-0-3] 完整更新必須簽署且裝置端更新機制 「必須」針對裝置上儲存的公開金鑰驗證更新和簽名。
[C-SR-1] 我們強烈建議使用簽署機制對更新檔案進行雜湊處理 使用 SHA-256,並使用 ECDSA NIST 根據公開金鑰驗證雜湊 P-256。
如果裝置導入方式支援非計量付費資料 連線,例如 802.11 或藍牙 PAN (個人區域網路) 設定檔 然後:
- [C-1-1] 必須支援透過離線更新和離線更新進行 OTA 下載。
裝置實作應驗證系統映像檔與二進位檔相同 結果顯示 OTA 結束後的預期結果區塊式 OTA Android 開放原始碼計畫中的實作方式,自 Android 起新增 5.1 來滿足這項規定。
此外,裝置實作項目必須支援 A/B 系統更新。 Android 開放原始碼計畫利用啟動控制項 HAL 實作這項功能。
如果裝置發布後發現錯誤,但 其合理的產品生命週期內,將諮詢 以便影響第三方相容性 應用程式,然後:
- [C-2-1] 裝置實作者「必須」透過軟體修正錯誤 可依照上述機制套用的更新。
Android 提供的功能可讓裝置擁有者應用程式 (如有) 控制系統更新的安裝作業如果系統更新子系統 若是裝置回報 android.software.device_admin,然後:
- [C-3-1] 必須實作 SystemUpdatePolicy 中所述的行為 類別
12. 文件變更記錄
以下摘要說明相容性定義的異動項目 版本:
2023 年 10 月 4 日
2. 裝置類型
-
查看修訂版本
- [9.8/H-1-14] 必須顯示麥克風指標,如 9.8.2 節所述
[9.8/C-3-1]:用於將成功的啟動字詞結果傳送至語音
- [9.8/H-1-14] 必須顯示麥克風指標,如 9.8.2 節所述
-
查看修訂版本
[5.1/H-1-7] 轉碼器初始化延遲時間不得超過 40 毫秒 所有硬體視訊編碼器都適用的 1080p 或更小影片編碼工作階段 載入容器時此處載入定義為 1080p 至 720p 的並行 僅使用硬體視訊轉碼器和 1080p 音訊錄影初始化。對 Dolby Vision 轉碼器而言, 轉碼器初始化延遲時間不得超過 50 毫秒。
[5.1/H-1-12] 轉碼器初始化延遲時間不得超過 40 毫秒 所有硬體視訊解碼器都適用 1080p 以下的影片解碼工作階段 載入容器時此處載入定義為 1080p 至 720p 的並行 僅使用硬體視訊轉碼器和 1080p 音訊影片播放初始化。針對 Dolby Vision 轉碼器 初始化延遲時間不得超過 50 毫秒。
[5.1/H-1-13] 只有在 30 毫秒內,轉碼器初始化延遲時間達到 30 毫秒以下 針對所有音訊解碼器產生 128 kbps 或較低的位元率音訊解碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊影片播放初始化。
7.4.資料連線
-
查看修訂版本
如果裝置實作項目回報
android.hardware.telephony.calling
功能,就會: -
查看修訂版本
如果裝置導入作業回報
android.hardware.telephony.calling
,就會:
9.11.金鑰和憑證
-
查看修訂版本
是透過 IAuthSecret HAL 提供
移除 IAR 將成為 Android 14 的「必須」規定。
2023 年 6 月 26 日
2. 裝置類型
-
移除要求 7.2.3/H-0-5、7.2.3/H-0-6、7.2.3/H-0-7
其他更新內容:
查看修訂版本
我們強烈建議您按照 所在地校正
相關規定。
-
查看修訂版本
如果 Automotive 裝置實作作業是 32 位元:
[7.6.1/A-1-1] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 512 MB:
- 在小螢幕/一般螢幕上,280 dpi 以下
- 搭載超大型螢幕的 ldpi 或更低版本
- 大螢幕上的 mdpi 或更低
[7.6.1/A-1-2] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 608 MB:
- 小螢幕/一般螢幕適用的 xhdpi 或更高
- 在大螢幕上使用 hdpi 或更高版本
- 在特大型螢幕上使用 mdpi 或更高版本
[7.6.1/A-1-3] 核心的可用記憶體 如果您使用了下列任一密度,則使用者空間必須至少為 896 MB:
- 在小螢幕/一般螢幕上,400 dpi 以上
- 在大螢幕上使用 xhdpi 或更高版本
- 搭載 tvdpi 以上版本
[7.6.1/A-1-4] 核心的可用記憶體 如果符合下列任何一種密度,則使用者空間大小至少必須為 1344MB 已使用:
- 在小螢幕/一般螢幕上,採用 560 dpi 以上
- 在大螢幕裝置上播放 400 dpi 以上
- 搭載 xhdpi (含) 以上大螢幕
3. 軟體
-
查看修訂版本
如果裝置實作方式回報 android.hardware.telephony.calling
、 他們會:android.hardware.telephony
7. 硬體相容性
9. 安全性模型相容性
-
查看修訂版本
裝置實作方式:
[C-0-5] 「不得」授予任何執行階段權限
預先安裝應用程式,除非:- 這些裝置會在裝置出貨時安裝,「且」
- 可以在應用程式前取得使用者的同意聲明
使用
it權限
或
-
- 移除規定 [C-13-10] 和 9.11.4。
2023 年 3 月 20 日
2. 裝置類型
-
查看修訂版本
如果手持裝置的實作設定應用程式會 分割功能 然後再透過活動嵌入功能
- [
C-17-13.2.3.1/ H-1-1] 「必須具備」 設定#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY 意圖。活動必須受 「android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
」且「必須」 啟動剖析自剖析的意圖活動 設定#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI。
終止新規定
- [
-
查看修訂版本
如果電視裝置實作搭配 VP9 硬體解碼器支援 VP9 以及 UHD 解碼設定檔
- [5.3.7/T-
2-1SR1] 強烈建議你支援 UHD 解碼器 設定為每秒 60 個影格,設定檔 2 (10 位元色彩深度)。
- [5.3.7/T-
-
查看修訂版本
Automotive 裝置實作:
[7.3/A-
0-1SR1] 將 GPS/GNSS 結合其他感應器,導致位置可能失效。如果位置 致命危險,極力建議您採行 對應的感應器 類型和/或車輛物業 ID[7.3/A-
0-20-4] 地點 透過 LocationManager#requestLocationUpdates() 要求 「必須與」對應。
3. 軟體
-
查看修訂版本
新聯絡人的預設帳戶:Contact Provider 提供用於管理 API 建立新的聯絡人時預設帳戶的設定。
如果裝置實作預先載入的聯絡人應用程式, 應用程式:
[C-2-1] 必須處理意圖
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
用來啟動 選取帳戶,並將設定儲存到「Contact Provider」(帳戶時) 已選取。[C-2-2] 處理資料時,必須遵循預設帳戶設定
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
: 「ContactsContracts.Contacts.CONTENT_TYPE
」和 將預設資料欄設為ContactsContract.RawContacts.CONTENT_TYPE
讓他們使用服務帳戶
終止新規定
-
查看修訂版本
[已移至 2.2.3]
如果裝置實作的「設定」應用程式 分割功能 然後再透過活動嵌入功能
- [C-17-1] 必須包含能夠處理
啟用分割功能時,Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY意圖。活動必須受「
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
」保護,且「必須」使用 啟動剖析自剖析的意圖活動 設定#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI。
終止新規定
- [C-17-1] 必須包含能夠處理
啟用分割功能時,Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY意圖。活動必須受「
6. 開發人員工具與選項的相容性
-
查看修訂版本
- 猴子
- [C-0-8] 必須納入 Monkey 架構, 採用的 API
- 猴子
7. 硬體相容性
-
查看修訂版本
[已移至 7.4.9]
如果裝置的導入方式包含對 802.1.15.4 的支援,並且公開 功能,讓他們:
- [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-1-6] 極力建議您通過相關法規和 由標準機構訂定的認證測試,包括 FIRA、CCC 和 CSA 表單中的指示操作。
終止新規定
-
查看修訂版本
如果裝置實作
包含 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
敬上 必須使用 SmsManager 收發簡訊和多媒體訊息時可用的 API。Android 開放原始碼計畫參考資料 套件/應用程式/訊息中的實作符合這項規定。 - [C-6-3] 回應
Intent#ACTION_DIAL
敬上 必須支援輸入*#*#CODE#*#*
和 觸發相應的TelephonyManager#ACTION_SECRET_CODE
廣播。 - [C-6-4] 回應
Intent#ACTION_DIAL
敬上 必須使用VoicemailContract.Voicemails#TRANSCRIPTION
以視覺化方式向使用者顯示轉錄文字的語音轉錄內容 (如果支援視覺化功能) 語音轉錄。 - [C-6-5] 必須代表所有 SubscriptionInfo 和同等規則
群組 UUID
以單一訂閱項目的形式,提供各項功能,以及供使用者瀏覽的功能
控制 SIM 卡資訊例如設定
比對出的介面
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
敬上 或EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
。 - [C-6-6] 不得根據 非空值群組 UUID 和機會位元 任何使用者可見的預設用途 允許設定或控制 SIM 卡設定。
如果裝置導入方式
包含 GSM 或 CDMA 電話,則會回報android.hardware.telephony
功能並提供系統狀態列,然後:- [C-
6-7-1] 必須為指定項目選取具代表性的有效訂閱方案 群組 UUID 也就是提供 SIM 卡狀態的任何用途 可能不準確或不適當這類預設用途的例子包括狀態列行動網路 訊號圖示或快速設定方塊。 - [C-SR-1] 強烈建議這個代表性訂閱是 成為 有效資料訂閱 除非裝置語音 來電,強烈推薦業務代表 訂閱是指有效的語音訂閱。
如果裝置實作方式
包含 GSM 或 CDMA 電話,請回報android.hardware.telephony
功能,接著執行以下動作:- [C-6-
87] 必須能夠開放,並且同時採用最大值 根據 ETSI TS 102 221 的每個 UICC 邏輯通道數 (共 20 個)。 - [C-6-
108] 「不得」對使用中的電信業者應用程式套用下列任何行為 (由TelephonyManager#getCarrierServicePackageName
指定) 自動或未經使用者明確確認:- 撤銷或限制網路存取權
- 撤銷權限
- 限制在 Android 開放原始碼計畫現有電源管理功能之外的情況下,執行背景或前景應用程式作業
- 停用或解除安裝應用程式
如果裝置實作方式
包含 GSM 或 CDMA 電話,請回報android.hardware.telephony
功能和所有 有效的非機會型訂閱 共用群組 UUID 將會停用、從裝置中移除 或將裝置標示為投機,然後是裝置:- [C-
78-1] 必須自動停用所有剩餘使用中的 機會式 同一個群組中的訂閱項目
如果裝置實作包含 GSM 電話,但不包括 CDMA 電話,則:
- [C-
89-1]「不得」宣告PackageManager#FEATURE_TELEPHONY_CDMA
。 - [C-
89-2] 每次嘗試設定任意值時,請務必擲回IllegalArgumentException
偏好或允許的網路類型位元遮罩的 3GPP2 網路類型。 - [C-
89-3] 必須從以下字串傳回空白字串:TelephonyManager#getMeid
。
如果裝置實作支援具有多個通訊埠和設定檔的 eUICC,則:
- [C-
1110-1] 必須聲明android.hardware.telephony.euicc.mep
功能旗標
- [C-6-1]
-
查看修訂版本
如果裝置導入方式回報功能支援如果裝置實作項目支援 並提供給第三方應用程式, 然後:android.hardware.uwb
(透過android.content.pm.PackageManager
類別,- [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] 必須確保距離測量結果介於 +/-15 公分以 95% 之間 只能測量距離 非反射性的腔 - [C-1-
27] 必須確保距離測量結果的中位數是 1 公尺 在參照裝置的 [0.75m, 1.25m] 內,實際資料 距離以 DUT 站立且傾斜的頂端邊緣為測量單位 45 度。 - [C-SR-2] 強烈建議你按照評估設定步驟操作 指定於 所在地校正要求。
極力建議遵循評估 「所在地校準規定」一文中指定的設定步驟。終止新規定
-
查看修訂版本
如何與耳機和其他裝置相容 音訊配件 (採用 USB-C 連接器且採用 USB 音訊類別) 查看 Android 生態系統中 Android USB 耳機規格一文中的定義。
2022 年 10 月 19 日
2. 裝置類型
-
查看修訂版本
如果手持裝置無法在 鎖定任務模式, 內容複製到剪貼簿時:
- [3.8.17/H-1-1] 必須向對方確認 也就是資料 複製到剪貼簿 (例如「已複製內容」的縮圖或快訊)。 此外,這裡也會指出系統是否會同步處理剪貼簿資料 跨裝置互動
3. 軟體
-
查看修訂版本
如果裝置實作的 「設定」應用程式 分割功能、 透過活動嵌入功能 ,藉此執行下列動作:
- [C-17-1] 必須包含能夠處理
設定#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
意圖。必須保護活動
來自
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
,以及 必須啟動剖析的意圖活動 設定#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI。
如果裝置實作項目支援
VoiceInteractionService
且 逐一安裝這個 API 的應用程式時,他們會:- [C-18-1] 必須尊重
android.settings.ACTION_VOICE_INPUT_SETTINGS
意圖,顯示語音輸入和小幫手的預設應用程式設定選單。
- [C-17-1] 必須包含能夠處理
設定#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
意圖。必須保護活動
來自
-
查看修訂版本
- [C-1-4]必須呈現 所設內容或遠端網址內容,與例項化 WebView 的應用程式不同。具體來說,獨立的轉譯器程序「必須」擁有較低權限、以獨立的使用者 ID 執行、無法存取應用程式的資料目錄、沒有直接網路存取權,而且只能透過 Binder 存取最低需求的系統服務。WebView 的 Android 開放原始碼計畫實作符合這項規定。
7. 硬體相容性
-
查看修訂版本
如果裝置實作所需支援 Wi-Fi 省電模式 (如定義) 的 IEEE 802.11 標準:
[C-3-1] 必須應 在應用程式成功取得時關閉 Wi-Fi 省電模式。 「WIFI_MODE_FULL_HIGH_PERF
」鎖或WIFI_MODE_FULL_LOW_LATENCY
鎖 透過WifiManager.createWifiLock()
和WifiManager.WifiLock.acquire()
-
查看修訂版本
如果實作的裝置提供藍牙低功耗 (BLE) 支援, 他們會:
- [C-3-5] 必須不再導入可撤銷的私人網址 (RPA) 逾時 於逾時時限內輪替地址,以保護使用者隱私 裝置使用 BLE 掃描或 廣告。,瞭解如何調查及移除這項存取權。 為了避免時差攻擊,必須一併隨機設定逾時間隔 介於 5 到 15 分鐘
查看修訂版本
如果裝置實作方式有前置或後置鏡頭(例如:
- [C-1-1] 請清楚取向,攝影機的長邊對齊 螢幕的長邊。也就是將裝置拿在橫向時 螢幕方向,相機「必須」以橫向方式拍攝圖片。這個 不受裝置的自然方向影響;也就是說 橫向或直向裝置,以及直向的主要裝置。
凡是符合下列所有條件的裝置,就不受上述規定限制:- 裝置會導入可變幾何圖形的螢幕,例如折疊式或轉軸 螢幕。
- 當裝置的折疊或轉軸狀態改變時,裝置會在 portrait-primary 至橫向-Primary (或相反) 螢幕方向。
終止新規定
9. 安全性模型相容性
-
查看修訂版本
如果實作的裝置支援安全螢幕鎖定,它會:
- [C-1-6] 必須支援 IKeymasterDevice 4.0、IKeymasterDevice 4.1、 IKeyMintDevice 版本 1 或 IKeyMintDevice 版本 2。
-
查看修訂版本
如果裝置實作 Android 虛擬化架構的支援功能 API (
android.system.virtualmachine.*
),Android 主機:[C-1-3] 不得修改、省略或取代 上游 Android 開放原始碼計畫中提供的系統/sepolicy (Android 開放原始碼計畫) 和政策都必須以所有永不允許的規則進行編譯。
如果裝置實作 Android 虛擬化架構的支援功能 API (
android.system.virtualmachine.*
),然後是任何受保護的虛擬機器 執行個體:[C-2-4] 不得修改、省略或取代 上游 Android 開放原始碼提供的 system/sepolicy/microdroid 專案 (Android 開放原始碼計畫)。
如果裝置實作 Android Virtualization Framework API 的支援功能,則針對金鑰管理機制:
- [C-6-2] 請務必正確做 DICE,亦即提供正確的值。
但可能不需要這麼精細的細節。
2022 年 8 月 15 日
2. 裝置類型
2.2.1 硬體:變更 硬體需求
輸入裝置:
查看修訂版本
手持裝置實作方式:
- [7.2.3/H-0-5] 必須撥打電話
目前
OnBackInvokedCallback.onBackStarted()
返回手勢啟動或返回按鈕時聚焦的視窗 (KEYCODE_BACK
) 已按下「向下鍵」。 - [7.2.3/H-0-6] 必須撥打電話
返回手勢為
OnBackInvokedCallback.onBackInvoked()
最新的修訂版本,或放開 [返回] 按鈕 (UP)。 - [7.2.3/H-0-7] 必須撥打電話
未返回手勢時則為
OnBackInvokedCallback.onBackCancelled()
否則KEYCODE_BACK
事件就會取消
終止新規定
如果裝置支援 Wi-Fi 鄰近感知網路 (NAN) 通訊協定, 正在宣告
PackageManager.FEATURE_WIFI_AWARE
和 Wi-Fi 位置資訊 (Wi-Fi 回合) 行程時間 - RTT) 前,請先宣告PackageManager.FEATURE_WIFI_RTT
,然後:[7.4.2.5/H-1-1] 請務必正確回報此範圍, 介於 68 百分位數 +/-1 公尺 (160 MHz 頻寬) 內 (計算方式為 搭配累積分佈函式),+/-2 公尺 (80 MHz 頻寬) 位於第 68 個百分位數,40 MHz 頻寬為 +/-4 公尺,68th 時為 +/-4 公尺 百分位數及 +/-8 公尺 (20 MHz 頻寬,第 68 個百分位數) 距離 10 公分、1 公尺、3 公尺和 5 公尺,透過 WifiRttManager#startRanging Android API。
[7.4.2.5/H-SR] 極力建議正確回報距離在第 90 個百分位數 (第 90 個百分位數) 到 +/-1 公尺頻寬 (第 90% 到 160 MHz 之間) 範圍為 +/-2 公尺 (在頻寬第 90 MHz 時為第 10 公分以上;第 90 公分的頻寬在第 80 MHz 時,第 90 公分) +/-2 公尺 (在頻寬 80 MHz 時為第 90 公分以上) WifiRttManager#startRanging Android API。
我們強烈建議您按照 所在地校正要求。
終止新規定
- [7.2.3/H-0-5] 必須撥打電話
目前
音訊延遲:
查看修訂版本
如果手持裝置實作項目宣告
android.hardware.audio.output
和android.hardware.microphone
,他們:- [5.6/H-1-1] 必須具有平均連續來回行程
延遲時間為 500
800毫秒或 少於 5 次測量,平均絕對偏差小於 5 50 超過100毫秒 下列資料路徑:「喇叭對麥克風」 3.5 公釐 Loopback Adapter (如果支援)、USB 回送 (如果支援)。至少支援一種 路徑。
- [5.6/H-1-1] 「必須」的平均延遲時間 至少 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、GESTURE_START 和 GESTURE_END)。
- [7.10/H]* 應針對
清晰觸覺回饋
(android.os.VibrationEffect)
例如 (effective_TICK、effective_CLICK、admob_HEAVY_CLICK 和
effective_DOUBLE_CLICK) 以及所有 可能的公營
以下項目的
PRIMITIVE_*
常數: 豐富觸覺回饋 位於 android.os.VibrationEffect.Composition namely(PRIMITIVE_CLICK 和 PRIMITIVE_TICK)(CLICK、TICK、LOW_TICK、QUICK_FALL、 QUICK_RISE、SLOW_RISE、SPIN、THUD)。其中一些基本功能, 只有在震動器支援時,系統才會提供 LOW_TICK 和 SPIN 頻率相對較低,瞭解如何調查及移除這項存取權。
- [7.10/H]* 應遵循對應公開常數指南 (位於 android.view.HapticFeedbackConstants) 中 與建議的 android.os.VibrationEffect 常數 與相應的振盪關係
終止新規定
- [7.10/H]* 應使用這些已連結的觸覺常數 「對應」。
- [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。
- [3.8.16/H-1-5] 必須提供使用者
能夠停用下列應用程式的專用驗證裝置控制項:
透過
MediaStyle 通知:
查看修訂版本
如果手持裝置實作支援 MediaStyle 通知 他們會:
- [3.8.3.1/H-1-SR] 強烈建議你使用 為使用者提供更多專屬功能(例如「輸出端切換器」) 這能讓使用者切換合適的 媒體路徑,例如應用程式透過 MediaSession 權杖發布 MediaStyle 通知,以及提供給 MediaRouter2Manager 的路徑。
2.2.4 效能與電源:針對運作的應用程式製定新規定 前景服務
查看修訂版本
手持裝置實作方式:
- [8.5/H-0-1] 必須在
透過「設定」選單停止執行前景的應用程式
服務,並顯示已啟用前景服務的所有應用程式,以及
定義應用程式後,每次使用付費服務 (SDK 規定)
文件。
- 部分應用程式可能不受禁止,也不必在該應用程式上架。 如 SDK 文件所述。
終止新規定
- [8.5/H-0-1] 必須在
透過「設定」選單停止執行前景的應用程式
服務,並顯示已啟用前景服務的所有應用程式,以及
定義應用程式後,每次使用付費服務 (SDK 規定)
文件。
2.2.7.1 媒體:在 「手持需求媒體」一節,如下所示:
查看修訂版本
如果手持裝置實作傳回
android.os.Build.VERSION_CODES.T
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
之後,他們會:- [5.1/H-1-1] 通告硬體視訊解碼器數量上限
可以在任何轉碼器組合中透過
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法 - [5.1/H-1-2] 必須支援 6 個硬體視訊解碼器工作階段執行個體 (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30 fps 同步播放。
- [5.1/H-1-3] 必須通告硬體視訊編碼器的數量上限
可以在任何轉碼器組合中透過
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法 - [5.1/H-1-4] 必須支援 6 個硬體視訊編碼器執行個體 工作階段 (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30fps 同步播放。
- [5.1/H-1-5] 必須通告硬體視訊編碼器的數量上限,
能透過多種轉碼器組合,在任何轉碼器組合中並行執行的解碼器工作階段
CodecCapabilities.getMaxSupportedInstances()
和VideoCapabilities.getSupportedPerformancePoints()
方法 - [5.1/H-1-6] 必須支援 6 個硬體視訊解碼器和硬體執行個體 任何轉碼器中的影片編碼器工作階段 (AVC、HEVC、VP9、AV1 或以上) 以 1080p@30 FPS 的解析度並行運作。
- [5.1/H-1-7] 轉碼器初始化延遲時間不得超過 40 毫秒 所有硬體視訊編碼器都適用的 1080p 或更小影片編碼工作階段 載入容器時此處載入定義為 1080p 至 720p 的並行 僅使用硬體視訊轉碼器和 1080p 音訊錄影初始化。
- [5.1/H-1-8] 轉碼器初始化延遲時間不得超過 30 毫秒 在所有音訊編碼器中,128 kbps 或較低的位元率音訊編碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊錄音初始化。
- [5.1/H-1-9] 必須支援 2 個安全硬體視訊解碼器執行個體 工作階段 (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30 fps 同步播放。
- [5.1/H-1-10] 必須支援 3 個不安全的硬體視訊解碼器執行個體 以及 1 個安全硬體視訊解碼器工作階段 任何轉碼器組合中 (共 4 個執行個體) (AVC、HEVC、VP9、AV1 或以上版本) 以 1080p 解析度@30 FPS 並行執行。
- [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 硬體的底片 Grain 提供支援 編碼器和解碼器
- [5.1/H-1-15] 至少須有 1 個支援 4K60 的硬體視訊解碼器。
- [5.1/H-1-16] 至少必須使用 1 個支援 4K60 的硬體視訊編碼器。
- [5.3/H-1-1] 「不得」在 10 秒內捨棄超過 1 個畫面 (例如低於 0.167% 影格的影格速率) 可錄製 1080p 60 fps 的影片 載入。載入定義為 1080p 至 720p 的並行影片 這可讓您使用硬體視訊轉碼器 轉碼工作階段,以及 128 kbps 進階音訊播放。
- [5.3/H-1-2] 影片播放期間「不得」在 10 秒內捨棄超過 1 個影格 在載入時,在 60 fps 影片工作階段中會有多快的解析度變化。負載的定義是 使用硬體的 1080p 至 720p 純視訊轉碼工作階段 視訊轉碼器,以及 128 kbps AAC 音訊播放功能。
- [5.6/H-1-1] 觸控色調延遲時間必須不超過 80 毫秒 使用 OboeTester 的觸覺測試,或 CTS Verifier 觸控色調測試。
- [5.6/H-1-2] 往返音訊延遲時間不得超過 80 毫秒 至少使用一個支援的資料路徑
- [5.6/H-1-3] 必須支援 3.5 公釐音訊 (超過 24 位元) 的立體聲輸出
會插入插孔 (如果投放的話) 和 USB 音訊 (如果透過
適用於低延遲和串流設定的完整資料路徑。低溫
延遲設定,則應用程式應在低延遲時間使用 AAudio
回呼模式。串流適用
應用程式應使用 Java AudioTrack。無論
HAL 輸出接收器應接受延遲和串流設定
AUDIO_FORMAT_PCM_24_BIT
、AUDIO_FORMAT_PCM_24_BIT_PACKED
、AUDIO_FORMAT_PCM_32_BIT
或AUDIO_FORMAT_PCM_FLOAT
用於其目標輸出內容 格式。 - [5.6/H-1-4] 必須支援超過 4 個聲道 USB 音訊裝置 (DJ 會使用這些裝置) 來試聽歌曲)。
- [5.6/H-1-5] 必須支援符合類別規範的 MIDI 裝置,並聲明 MIDI 功能旗標
- [5.7/H-1-2] 必須支援「
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
」: 下列內容解密功能。
樣本大小下限 4 MiB 子樣本數量下限 - H264 或 HEVC 32 子樣本數量下限 - VP9 9 子樣本數下限 - AV1 288 號 子樣本緩衝區空間下限 1 MiB 一般加密緩衝區空間下限 500 KiB 並行工作階段數量下限 30 每個工作階段的金鑰數量下限 20 金鑰總數下限 (所有工作階段) 80 號 DRM 金鑰總數下限 (全部) 工作階段) 6 郵件大小 16 KiB 每秒解密影格數 60 fps 終止新規定
- [5.1/H-1-1] 通告硬體視訊解碼器數量上限
可以在任何轉碼器組合中透過
2.2.7.2 Camera:媒體效能類別相機功能的更新。
查看修訂版本
如果手持裝置實作傳回
android.os.Build.VERSION_CODES.T
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
之後,他們會:- [7.5/H-1-1] 必須使用主要後置鏡頭,解析度須為 至少 1200 萬像素,支援拍攝每秒 4k@30 FPS 的影片。主要 後置鏡頭是指具備最低相機 ID 的後置鏡頭。
- [7.5/H-1-2] 必須使用主要前置鏡頭,解析度須為 至少 500 萬像素,且支援拍攝每秒 1080p@30 FPS 的影片。主要 前置鏡頭是前置鏡頭,且相機 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] 必須具有 camera2 JPEG 擷取延遲時間 <執行時間為 1000 毫秒 根據 ITS 部門的 CTS 鏡頭 PerformanceTest 評估,為 1080p 解析度 兩個主鏡頭的亮度 (300 萬)。
- [7.5/H-1-6] 必須設定 camera2 啟動延遲時間 (開啟相機即可先行預覽) 頁框) <CTS 鏡頭 PerformanceTest 對 ITS 的影響為 500 毫秒 兩個主鏡頭的亮度 (300 萬)。
- [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] 必須達到最低 ZOOM_RATIO <1.0 代表主要鏡頭 (如果有的話) 是面向相同方向的超廣角 RGB 相機。
- [7.5/H-1-11] 「必須」在主要執行個體上實作並行前端串流 相機上
- [7.5/H-1-12] 必須支援
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
以及主要前置與主要後置鏡頭 - [7.5/H-1-13] 必須支援主要版本的
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。
- [8.2/H-1-2] 必須確保隨機寫入效能至少達到每秒 10 MB。
- [8.2/H-1-3] 必須確保連續讀取效能至少達到每秒 250 MB。
- [8.2/H-1-4] 必須確保至少 40 MB/秒的隨機讀取效能
終止新規定
2.5.1 硬體:更新 3 軸式加速度計和 3 軸式迴轉儀的要求,以及 拍攝外觀的相機需求
查看修訂版本
Automotive 裝置實作:
- [7.3.1/A-0-4] 必須符合 Android 車用感應器座標系統。
- [7.3/A-SR] STRONGLY_RECOMMENDED 可納入 3 軸 加速計和 3 軸式迴轉儀。
- [7.3/A-SR] STRONGLY_RECOMMENDED 導入及回報
TYPE_HEADING
感應器。
如果 Automotive 裝置導入加速計,請按照下列步驟操作:
- [7.3.1/A-1-1] 必須能夠按頻率回報活動 至少 100 Hz。
如果裝置導入方式包含 3 軸式加速度計,就會發生以下情形:
- [7.3.1/A-SR] 極力建議您導入 複合感應器,適用於限定軸心加速計
如果 Automotive 裝置導入的加速計低於 3 軸來:
- [7.3.1/A-1-3] 必須導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES
感應器。 - [7.3.1/A-1-4] 必須導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
感應器。
如果 Automotive 裝置導入了陀螺儀,則必須:
- [7.3.4/A-2-1] 必須能夠按頻率回報事件 至少 100 Hz。
- [7.3.4/A-2-3] 必須能夠評估螢幕方向變化 到每秒可達 250 度的位置
- [7.3.4/A-SR] 極力建議您設定 陀螺儀的測量範圍為 +/-250dp,以便盡可能提高解析度
終止新規定
如果 Automotive 裝置導入作業包含 3 軸式迴轉儀,請按照下列步驟操作:
- [7.3.4/A-SR] 極力建議您導入 適用於有限軸形陀螺儀的複合感應器。
如果 Automotive 裝置實作的陀螺儀少於 3 軸,則:
- [7.3.4/A-4-1] 必須導入及回報
TYPE_GYROSCOPE_LIMITED_AXES
感應器。 - [7.3.4/A-4-2] 必須導入及回報
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
感應器。
如果汽車裝置實作包含
TYPE_HEADING
感應器,其:- [7.3.4/A-4-3] 必須能夠按頻率回報事件 至少 1 Hz。
- [7.3.4/A-SR] STRONGLY_RECOMMENDED 可回報等於或高於 頻率至少為 10 Hz。
- 應參照正北。
- 車輛靜止不動時仍應使用車輛。
- 解析度至少要為 1 度。
終止新規定
室外視角攝影機是指拍攝裝置外部場景的相機 ,例如 後置鏡頭
行車記錄器。如果 Automotive 裝置導入了外部視角相機,例如 相機的作用:
[7.5.5/A-SR] 強烈建議你提供資訊方向, 相機的長邊對齊地平線。應提供支援 Android 同步處理架構。可能在 相機驅動程式
如果汽車裝置實作方式包含一或多個室外視角相機, 並載入「外部檢視系統」(EVS) 服務,然後針對這類相機:
- [7.5/A-2-1] 不得旋轉或水平鏡射 。
Automotive 裝置實作:
- 「可能」包含一或多個第三方可用的攝影機 應用程式。
如果汽車裝置實作項目至少包含一支攝影機, 第三方應用程式提供的功能:
- [7.5/A-3-1] 必須回報功能標記
android.hardware.camera.any
。 - [7.5/A-3-2] 不得宣告相機為 「系統相機」
- 支援外部相機 (如第 7.5.3 節所述)。
- 可能提供後置鏡頭的功能 (例如自動對焦等) 如第 7.5.1 節所述。
終止新規定
2.5.5 安全性模型: 車用裝置的相機權限新規定。
查看修訂版本
2.6.1 平板電腦需求 - 硬體: 更新平板電腦螢幕大小規定。
查看修訂版本
Android 平板電腦裝置是指 Android 裝置實作, 通常符合下列所有條件:
- 螢幕顯示大小超過 7 吋 小於 18 吋,沿著對角線測得的數值
螢幕大小
- [7.1.1.1/Tab-0-1] 必須能在 7 到 18 英寸的範圍內顯示螢幕。
3. 軟體
3.2.2 版本參數: 已更新
getSerial()
中的 ASCII 字元。查看修訂版本
- [C-0-1] 跨裝置提供一致且有意義的值 請參閱下表,其中列出各廣告格式的額外限制 才能符合所需的裝置導入方式。
參數 詳細說明 getSerial() 必須 (已準備好或退回) 提供使用的硬體序號 而且在相同的型號和製造商的裝置中均不重複。如果 這個欄位必須能編碼成 7 位元 ASCII,且符合規則運算式 「^[a-zA-Z0-9]+$」。 3.2.3.5 條件式應用程式意圖: 條件式應用程式意圖的相關規定更新。
查看修訂版本
如果裝置實作項目包含大型螢幕 (一般情況下,螢幕寬度和高度為 600dp 以上),並支援 分割功能 然後:
- [C-17-1] 必須包含能夠處理
設定#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
意圖。活動必須受
「
android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK
」且「必須」 啟動剖析自剖析的意圖活動 設定#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI。
終止新規定
- [C-17-1] 必須包含能夠處理
設定#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY
意圖。活動必須受
「
3.5.1 應用程式限制: 應用程式限制更新。
查看修訂版本
如果裝置實作項目採用專屬機制來限制應用程式 (例如變更或限制較常產生的 API 行為) 其他方式),這是較為廣泛的機制 僅限於 「受限應用程式待命」值區 他們會:
- [C-1-1] 必須允許使用者查看受限制的應用程式清單。
- [C-1-2] 必須提供使用者權限,才能開啟或關閉所有功能 專屬限制
- [C-1-3] 在沒有要求的情況下,不得自動套用這些專屬限制 可能存在不良系統健康行為的證據,但可能對應用程式實施了限制 在偵測到不良系統健康行為 (例如 Wake Lock 停滯或長時間跑步) 時 服務以及其他條件標準「可能」視裝置而定 但必須與應用程式對系統健康狀態的影響相關其他 與系統健康狀態無關的條件,例如應用程式的 缺乏市場熱門程度,「不得」當做條件。
- [C-1-4] 「不得」為應用程式自動套用這些專屬限制 使用者手動關閉應用程式限制,且「可能」建議使用者 才能套用專屬限制
[C-1-5] 必須告知使用者,僅適用於這些專屬限制 應用程式就會自動調整「必須」於 24 小時內提供這類資訊 先確定這些專屬限制的應用範圍。
[C-1-6] 必須針對 ActivityManager.isBackgroundRestricted() 方法。
[C-1-7] 不得限制應用程式明確使用的頂層前景應用程式 使用者。
[C-1-8] 每當有人讓應用程式 使用者開始明確使用應用程式,讓應用程式位於前景 應用程式。
[C-1-9] 請務必透過 使用統計資料。
[C-1-10] 必須提供公開且明確的文件或網站,藉此說明 專屬限制的適用情形這份文件或網站必須 可從 Android SDK 文件中連結,且必須包含:
- 專屬限制的觸發條件。
- 應用程式的限制和限制方式。
- 如何讓應用程式不受這類限制限制。
- 應用程式如何要求豁免專屬限制 都能夠讓使用者安裝的應用程式不受限制。
如果應用程式已預先安裝在裝置上,但應用程式從未明確使用該應用程式 使用者超過 30 天,[C-1-3] [C-1-5] 就符合豁免資格。
終止新規定
3.8.1 啟動器 (主畫面): 支援
monochrome/adaptive-icon
的更新。查看修訂版本
3.8.2 小工具:更新 第三方應用程式小工具在啟動器中存在。
查看修訂版本
如果裝置導入方式支援第三方應用程式小工具,就會:
- [C-1-2] 必須納入 AppWidgets 的內建支援和公開
新增、設定、查看和移除 AppWidgets 的使用者介面預設用途
直接開啟啟動器
- [C-1-2] 必須納入 AppWidgets 的內建支援和公開
新增、設定、查看和移除 AppWidgets 的使用者介面預設用途
3.8.3.1 通知呈現方式: 說明抬頭通知的定義。
查看修訂版本
抬頭通知是一種 只會在使用者接觸曝光時, 保持開啟。
3.8.3.3 DND (零打擾) / 優先模式: 更新應用程式,在 DND (零打擾) 模式中加入優先模式。
查看修訂版本
3.8.3.3。DND (零打擾) / 優先模式
如果裝置實作支援 DND 功能 (又稱為「優先模式」):
3.8.6 主題:全新 動態調色盤的相關要求。
查看修訂版本
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
[C-1-4] 必須產生 Android 開放原始碼計畫中指定的動態調色盤
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
說明文件 (請參閱 「android.theme.customization.system_palette
」和android.theme.customization.theme_style
)。[C-1-5] 必須使用色彩主題樣式產生動態調色盤 列舉的
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
中 說明文件 (請參閱android.theme.customization.theme_styles
), 也就是TONAL_SPOT
、VIBRANT
、EXPRESSIVE
、SPRITZ
、RAINBOW
、FRUIT_SALAD
。「來源顏色」每次傳送
android.theme.customization.system_palette
(如記錄於Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
)。[C-1-6]
CAM16
色域值必須大於或等於 5。是否應該透過
com.android.systemui.monet.ColorScheme#getSeedColors
,提供 有多種有效的來源顏色可供選擇。如果提供的顏色皆不符,則應使用
0xFF1B6EF3
值 上述來源顏色規定。
終止新規定
3.8.17 剪貼簿:新增 有關剪貼簿內容的新規定部分。
查看修訂版本
3.8.17。剪貼簿
裝置實作方式:
- [C-0-1] 不得將剪貼簿資料傳送給任何元件、活動、服務或 使用者未明確採取動作 (例如按下 按鈕),但 9.8.6 內容擷取和應用程式搜尋。
如果裝置導入方式會在複製內容時產生使用者可見的預覽 複製到剪貼簿的任何
ClipData
項目ClipData.getDescription().getExtras()
包含android.content.extra.IS_SENSITIVE
,他們:- [C-1-1] 必須遮蓋使用者可見的預覽畫面
Android 開放原始碼計畫參考資料實作項目符合這些剪貼簿規定。
終止新規定
3.9.1.1 裝置擁有者佈建: 裝置擁有者佈建規定更新。
查看修訂版本
如果裝置實作項目宣告
android.software.device_admin
,就會:- [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為
裝置擁有者應用程式
如下所述:
- 當裝置實作
以上
使用者或
使用者資料設定後,系統會採取以下做法:
- [C-1-5] 必須註冊 DPC 應用程式做為裝置擁有者應用程式
或啟用裝置政策控制器 (DPC) 應用程式
成為裝置擁有者或設定檔擁有者
如果裝置透過
功能旗標
android.hardware.nfc
並收到 NFC 訊息 包含 MIME 類型的記錄MIME_TYPE_PROVISIONING_NFC
。 - [C-1-8] 必須傳送 ACTION_GET_PROVISIONING_MODE
意圖並取得裝置擁有者佈建後的流量
DPC 應用程式可以選擇成為裝置擁有者或設定檔
擁有者,取決於
android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES
, ,除非這項資訊取自 這兩個內容只有一個有效選項。(例如使用 NFC 技術) 不支援設定檔擁有者佈建作業)。 - [C-1-9] 必須 ACTION_ADMIN_POLICY_COMPLIANCE 提供給裝置擁有者應用程式的意圖 (如果已建立裝置擁有者) 佈建狀態。 使用者必須必須等到 完成「裝置擁有者」應用程式的設定。
- [C-1-5] 必須註冊 DPC 應用程式做為裝置擁有者應用程式
或啟用裝置政策控制器 (DPC) 應用程式
成為裝置擁有者或設定檔擁有者
如果裝置透過
功能旗標
- 當裝置實作方式出現
使用者或
使用者資料後,就能享有以下優勢:
- [C-1-7] 不得將任何 DPC 申請註冊為裝置擁有者應用程式 。
- 當裝置實作
以上
使用者或
使用者資料設定後,系統會採取以下做法:
- [C-1-2] 必須顯示適當的揭露聲明
(例如 Android 開放原始碼計畫參照) 的應用程式,並在應用程式前取得使用者的確認同意
設為裝置擁有者 (除非裝置是透過程式輔助方式設定)
適用於零售商展示模式
直到畫面上的使用者互動
必須在廣告開始前或活動期間採取一些確認行動 完成佈建程序 應用程式設為裝置擁有者可以透過使用者動作或 而是適合 揭露聲明 (如 Android 開放原始碼計畫所參照) 必須在裝置擁有者之前顯示 已啟動佈建作業。此外,程式輔助裝置擁有者也須取得同意聲明 企業不得採用 (由企業) 佈建裝置擁有者的機制 幹擾使用者的「開箱體驗」 供非企業使用 [C-1-3] 不得以硬式編碼的方式,將同意聲明或同意聲明程式碼 防止使用其他裝置 擁有者應用程式。
如果裝置實作項目宣告了
android.software.device_admin
,但同時宣告了 包含裝置擁有者裝置管理解決方案並提供相關機制 ,將解決方案中設定的應用程式升級為「裝置擁有者」 等值」標準「裝置擁有者」如標準 Android 系統辨識的 DevicePolicyManager API 具有以下特點:- [C-2-1] 必須設有專門程序,才能驗證特定應用程式 促銷屬於合法企業裝置管理 並已在專屬解決方案中設定 取得與「裝置擁有者」同等的權利。
- [C-2-2] 必須顯示與
由
android.app.action.PROVISION_MANAGED_DEVICE
發起的資料流 ,以「裝置擁有者」的身分註冊 DPC 應用程式。 - [C-2-3] 不得以硬式編碼的方式修改同意聲明狀態,或不得 使用其他應用程式擁有者的應用程式
註冊 DPC 申請之前,裝置上可能已有使用者資料 「裝置擁有者」。
- [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為
裝置擁有者應用程式
如下所述:
3.9.4 裝置管理角色需求條件: 新增「裝置管理角色需求條件」一節。
查看修訂版本
3.9.4 裝置政策管理角色要求
如果裝置導入作業回報
android.software.device_admin
或android.software.managed_users
,然後他們:- [C-1-1] 必須支援裝置政策管理角色 (如
第 9.1 節。擁有裝置政策管理角色的應用程式
可以透過將
config_devicePolicyManagement
設為套件名稱來定義。 除非預先載入應用程式,否則套件名稱後面必須加上:
以及簽署憑證。
如果
config_devicePolicyManagement
的套件名稱未定義為 前提:- [C-2-1] 實作裝置「必須」支援在沒有裝置的情況下佈建 政策管理角色持有者應用程式 (Android 開放原始碼計畫提供參考實作)。
如果按照上述說明為
config_devicePolicyManagement
定義了套件名稱 以上:- [C-3-1] 所有應用程式都必須安裝 設定檔 適用於使用者。
- [C-3-2] 裝置實作可能會定義更新
佈建前的裝置政策管理角色擁有者
config_devicePolicyManagementUpdater
。
如果將
config_devicePolicyManagementUpdater
的套件名稱定義為 前提:- [C-4-1] 應用程式「必須」預先安裝在裝置上。
- [C-4-2] 應用程式「必須」實作意圖篩選器,
android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER
。
終止新規定
- [C-1-1] 必須支援裝置政策管理角色 (如
第 9.1 節。擁有裝置政策管理角色的應用程式
可以透過將
3.18 聯絡人:新增聯絡人 收集新聯絡人的資訊
查看修訂版本
新聯絡人的預設帳戶:Contact Provider 提供用於管理 API 建立新的聯絡人時預設帳戶的設定。
如果裝置實作預先載入的聯絡人應用程式, 應用程式:
[C-2-1] 必須處理意圖
ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT
用來啟動 選取帳戶,並將設定儲存到「Contact Provider」(帳戶時) 已選取。[C-2-2] 處理資料時,必須遵循預設帳戶設定
Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT
: 「ContactsContracts.Contacts.CONTENT_TYPE
」和 將預設資料欄設為ContactsContract.RawContacts.CONTENT_TYPE
讓他們使用服務帳戶
終止新規定
4. 應用程式套件的相容性
4. 應用程式封裝的相容性: APK Signature 配置版本更新。
查看修訂版本
裝置實作方式:
[C-0-2] 必須支援使用 APK Signature Scheme v3.1 , APK Signature Scheme v3, APK 簽署配置 v2 和 JAR 簽署
[C-0-9] 必須支援使用 APK Signature Scheme v4 和 APK Signature Scheme v4.1 。
5. 多媒體相容性
5.1.2 音訊解碼:針對能夠輸出多聲道音訊的解碼器新增規定。
查看修訂版本
如果裝置導入方式支援解碼 AAC 輸入緩衝區, 從預設管道串流到 PCM
android.media.MediaCodec
API 中的 AAC 音訊解碼器,則「必須」 支援:- [C-7-1] 應用程式必須能使用解碼功能進行設定
使用按鍵
KEY_MAX_OUTPUT_CHANNEL_COUNT
敬上 控制內容是否由立體聲調低混音為立體聲 (使用 2 的值時) 或是透過原生通道數輸出 (如果使用的值等於或 )。舉例來說,如果值設為 6 以上 解碼器,以便在提供 5.1 內容時輸出 6 個頻道。 - [C-7-2] 解碼時,解碼器「必須」宣傳所用的頻道遮罩
對輸出格式執行
KEY_CHANNEL_MASK
敬上 索引鍵,使用android.media.AudioFormat
常數 (例如:CHANNEL_OUT_5POINT1
)。
如果裝置實作支援非預設 AAC 以外的音訊解碼器 音訊解碼器,且能夠輸出多聲道音訊 ( 2 個聲道),然後:
- [C-SR] 極力建議解碼器
建構應用程式
KEY_MAX_OUTPUT_CHANNEL_COUNT
敬上 控制內容是否由立體聲調低混音為立體聲 (使用 2 的值時) 或是透過原生通道數輸出 (如果使用的值等於或 )。舉例來說,如果值設為 6 以上 解碼器,以便在提供 5.1 內容時輸出 6 個頻道。 - [C-SR] 解碼時,極力建議使用解碼器來宣傳
使用
KEY_CHANNEL_MASK
敬上 鍵,使用 android.media.AudioFormat 常數 (例如:CHANNEL_OUT_5POINT1
)。
終止新規定
- [C-7-1] 應用程式必須能使用解碼功能進行設定
使用按鍵
5.4.1 原始音訊擷取和麥克風資訊: 更新支援的音訊輸入串流音訊來源。
查看修訂版本
如果裝置實作項目宣告
android.hardware.microphone
,就會:[C-1-1] 必須允許擷取符合下列規定的原始音訊內容 任何
AudioRecord
或AAudio
的特性 INPUT 串流已成功開啟。至少要: 「必須」是系統支援的特性:- 格式:線性 PCM、16 位元
- 取樣率:8000、11025、16000、44100、48000 Hz
- 聲道:單聲道
- 音訊來源:
DEFAULT
、MIC
,CAMCORDER
,VOICE_RECOGNITION
、VOICE_COMMUNICATION
、UNPROCESSED
、 或VOICE_PERFORMANCE
。 這也適用於AAudio
中的同等輸入預設設定, (例如:AAUDIO_INPUT_PRESET_CAMCORDER
)。 - [C-1-4] 必須遵循
MicrophoneInfo
API 並正確填入裝置的可用麥克風資訊 由第三方應用程式存取AudioManager.getMicrophones()
API;適用於主動錄音,使用MediaRecorder.AudioSources DEFAULT
、MIC
、CAMCORDER
、VOICE_RECOGNITION
、VOICE_COMMUNICATION
、UNPROCESSED
或VOICE_PERFORMANCE
。以及目前使用的麥克風 可透過三種管道 透過 kubectl 指令AudioRecord.getActiveMicrophones()
和MediaRecorder.getActiveMicrophones()
API。
5.4.2 語音辨識擷取功能: 更新語音辨識音訊串流的規定和新增規定 麥克風音量增加
查看修訂版本
如果裝置實作項目宣告
android.hardware.microphone
,就會:- 應以大約平坦的方式錄製語音辨識音訊串流 振幅與頻率特性:特別是從 100 Hz 降至 ±3 dB 4000 Hz。
- 應透過輸入敏感度設定錄製語音辨識音訊串流 因此,1000 Hz 的 90 dB 聲音功率 (SPL) 源能產生 RMS 值 如果是 16 位元樣本,則為 2500。
- 應展現近似寬鬆與頻率特性 中頻段值:特別是從 100 Hz 到 4000 Hz 的 ±3dB 和用來錄製語音辨識音訊來源的每個麥克風
- [C-SR] 強烈建議 [C-SR] 在低點 頻率範圍:特別是從 30 Hz 至 100 Hz 的 ±20 dB 每個用於錄音的麥克風音頻範圍 辨識音訊來源
- [C-SR] 強烈建議 [C-SR] 在高空 頻率範圍:特別是從 4000 Hz 到 22 KHz 的 ±30 dB, 每個用於錄音的麥克風音頻範圍 辨識音訊來源
- 應設定音訊輸入靈敏度,讓 1000 Hz 單調色調來源 音量為 90 dB 時 (測量在麥克風旁邊) 會產生 RMS 2500 的理想回覆,範圍介於 1770 到 3530 以 16 之間 位元樣本 (或 -22.35 db ±3dB 全體重計,浮點/雙精度浮點數) 樣本) 音訊來源。
終止新規定
5.4.6 麥克風強化程度: 將麥克風提升等級的規定移至第 5.4.2 節。
查看修訂版本
5.4.6。麥克風音量再升級 [已移至 5.4.2]
如果裝置實作項目宣告
android.hardware.microphone
,就會:- 應呈現大約平坦的振幅與頻率 中頻率範圍的特性:特別是從 100 的 ±3dB 每個用來錄音的麥克風都以 Hz 至 4000 Hz 辨識音訊來源
- [C-SR] 強烈建議 [C-SR] 在低點 頻率範圍:特別是從 5 Hz 至 100 Hz 的 ±20 dB 錄製到每個用於錄音的麥克風音域 以及語音辨識音訊來源。
- [C-SR] 極力推薦 高頻率範圍:特別是從 4000 Hz 到 22 KHz 的 ±30 dB 與每個所用麥克風的中頻範圍相比 錄製語音辨識音訊來源。
- 應設定音訊輸入靈敏度,讓 1000 Hz 單調 達到 90 分貝聲音壓力水平 (SPL) 時的音調來源會產生反應 由於 RMS 為 2500,16 位元樣本 (浮點值則為 -22.35 dB 全規模) 點/雙精度取樣) 錄製語音辨識音訊來源。
5.5.4 音訊卸載: 更新音訊卸載播放規定。
查看修訂版本
如果裝置的導入方式支援音訊卸載播放,就會:
- [C-SR] 強烈建議你剪輯已播放的無間音訊內容 是兩部同格式的短片之間 指定的 Pod 中 AudioTrack 無差異 API 以及 MediaPlayer 的媒體容器
5.6 音訊延遲: 音訊延遲規定更新。
查看修訂版本
為達成本節目的,請使用下列定義:
- 冷輸出時基誤差。個別冷資料測量結果的變異性 輸出延遲時間值
- 冷輸入時基誤差。個別冷資料測量結果的變異性 輸入延遲時間的值
如果裝置實作方式宣告了
android.hardware.audio.output
, 必須符合或超過下列規定:- [C-1-2] 冷輸出延遲時間為 500 毫秒 以下。
- [C-1-3] 使用以下方式開啟輸出串流:
AAudioStreamBuilder_openStream()
必須 不到 1,000 毫秒就能完成
如果裝置實作項目宣告
android.hardware.audio.output
極力建議您符合下列規定:- [C-SR] 喇叭資料回報冷輸出延遲時間為 100 毫秒或更短
路徑。
執行此 Android 版本的現有裝置和新裝置都「一定會」 強烈建議立即符合這些條件。在未來的平台上 就需要將冷輸出延遲時間設為 200 毫秒或更短, (必要)。 [C-SR] 盡量減少冷輸出時基誤差。
如果裝置實作項目包含
android.hardware.microphone
, 必須符合下列輸入音訊規定:- [C-3-2] 冷輸入延遲時間為 500 毫秒 以下。
- [C-3-3] 正在使用以下方式開啟輸入串流
AAudioStreamBuilder_openStream()
必須 不到 1,000 毫秒就能完成
如果裝置實作項目包含
android.hardware.microphone
, 強烈建議符合以下輸入音訊的規定:- [C-SR] 麥克風的冷輸入延遲時間不超過 100 毫秒
資料路徑
執行的現有裝置和新裝置 這個 Android 版本 強烈建議你立即符合這些條件。未來 將冷輸入延遲時間設為 200 毫秒以下 這些必要性。
- [C-SR] 連續輸入延遲時間不超過 30 毫秒。
- [C-SR] 盡量減少冷輸入時基誤差。
5.10 專業音質: 專業音訊支援的音訊延遲規定更新。
查看修訂版本
如果裝置導入結果回報支援功能
android.hardware.audio.pro
(透過 android.content.pm.PackageManager 類別,他們:- [C-1-2] 必須設定連續往返音訊延遲,如
第 5.6 節音訊延遲時間
25 毫秒以下
應使用
10 毫秒或 減少。 - [C-1-5] 必須使用
AAudio 原生音訊
API 和
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
- [C-1-8] 「必須」的平均延遲時間 至少 5 次。 麥克風資料路徑
- [C-SR] 強烈建議提供一致的 CPU 程度 而在啟用音訊和 CPU 負載時,整體效能會有所不同。請進行測試 使用 Android 應用程式 SynthMark。 SynthMark 使用軟體合成器在模擬音訊架構中運作 用於測量系統效能請參閱 SynthMark 說明文件 查看基準測試相關說明合成馬克 應用程式是使用 「自動化測試」選項,並達到下列結果: * Voicemark.90 >= 32 種語音 * Latencymark.fixed.little <= 15 毫秒 * Latencymark.dynamic.little <= 50 毫秒
觸控輸入和音訊之間應有延遲 確保輸出內容小於或等於 40 毫秒。
如果裝置實作項目包含 4 導體 3.5 公釐耳機插孔,則:
- [C-2-1] 必須設定平均連續往返音訊延遲時間,如 區段 5.6 音訊延遲時間 (20 毫秒以下)。 超過 5 個測量值,平均絕對偏差在 5 毫秒內 音訊插孔路徑 音訊回送連接器。
- [C-1-2] 必須設定連續往返音訊延遲,如
第 5.6 節音訊延遲時間
25 毫秒以下
應使用
5.12 HDR 影片: 新增「HDR 影片」需求條件。
6. 開發人員工具與選項的相容性
6.1 開發人員工具: 連線能力和 GPU 核心需求條件的更新。
查看修訂版本
如果裝置實作支援透過 Wi-Fi「或乙太網路」:
- [C-4-1] 必須採用
AdbManager#isAdbWifiSupported()
方法 傳回true
。
如果裝置實作支援透過 Wi-Fi 或乙太網路 至少包括一部相機:
- [C-5-1] 必須採用
AdbManager#isAdbWifiQrSupported()
方法 傳回true
。
GPU 工作資訊
裝置實作方式:
- [C-6-1] 必須實作殼層指令
dumpsys gpu --gpuwork
才能顯示power/gpu_work_period
核心傳回的匯總 GPU 工作資料 追蹤記錄點,如果不支援追蹤點,則不顯示任何資料。Android 開放原始碼計畫 實作為frameworks/native/services/gpuservice/gpuwork/
。
- [C-6-1] 必須實作殼層指令
終止新規定
- [C-4-1] 必須採用
7. 硬體相容性
7.1.4.1 OpenGL ES:更新 建議額外資訊
查看修訂版本
如果裝置實作支援任何 OpenGL ES 版本,就會:
- 應支援
EGL_IMG_context_priority
和EGL_EXT_protected_content
個擴充功能。
終止新規定
- 應支援
7.1.4.2 Vulkan:更新 適用於 Vulkan 的多個版本
查看修訂版本
如果裝置的實作支援 OpenGL ES 3.1,就會發生以下情形:
- [SR] 強烈建議你提供
Vulkan 1.3 版。
Vulkan 1.1 版 - 「不得」支援 Vulkan 變化版本 (也就是 Vulkan 核心版本必須為零)。
如果裝置實作項目包含畫面或影片輸出內容,就會發生以下情形:
- [SR] 強烈建議你提供
Vulkan 1.3 版。
Vulkan 1.1 版
如果裝置實作項目支援 Vulkan 1.0 以上版本,程式碼就會:
- 應提供支援
VkPhysicalDeviceProtectedMemoryFeatures
和VK_EXT_global_priority
。 - [C-1-12] 「不得」列舉支援
VK_KHR_performance_query
副檔名。 - [C-SR] 強烈建議你達成 Android Baseline 2021 設定檔指定的規定。
- [SR] 強烈建議你提供
Vulkan 1.3 版。
查看修訂版本
裝置實作方式:
- [C-SR] 極力建議您根據 可取消。「可取消」一種是使用者能夠 導航功能停止執行 (例如返回首頁、返回等) 滑動手勢不會超過特定門檻。
終止新規定
如果提供返回瀏覽函式,且使用者取消返回 手勢,然後:
- [C-8-1] 必須呼叫
OnBackInvokedCallback.onBackCancelled()
。 - [C-8-2] 不得呼叫
OnBackInvokedCallback.onBackInvoked()
。 - [C-8-3] 「不得」分派 KEYCODE_BACK 事件。
如果提供返回瀏覽函式,但前景應用程式 「
OnBackInvokedCallback
」尚未註冊,那麼:- 系統「必須」為前景應用程式提供動畫 暗示使用者返回 Android 開放原始碼計畫。
如果裝置實作支援系統 API
setNavBarMode
,即可 允許任何具有android.permission.STATUS_BAR
權限的系統應用程式設定 導覽列模式,然後:- [C-9-1] 必須支援適合兒童的圖示或按鈕式 使用 Android 開放原始碼計畫程式碼提供的導覽介面。
終止新規定
7.3.1 加速計: 更新加速計的感應器需求。
查看修訂版本
如果裝置導入方式包含加速計
3 軸式加速度計他們會:[C-1-2] 必須導入及回報TYPE_ACCELEROMETER
感應器。[SR] 強烈建議導入TYPE_SIGNIFICANT_MOTION
複合感應器。[SR] 極力建議導入 報表TYPE_ACCELEROMETER_UNCALIBRATED
感應器。強烈建議 Android 裝置符合這項規定, 他們可以升級至較新的平台版本 變更為「必要」。應實作TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
、TYPE_STEP_COUNTER
複合資料 。
如果裝置導入方式包含 3 軸式加速度計,就會發生以下情形:
- [C-2-1] 必須導入及回報
TYPE_ACCELEROMETER
感應器。 - [C-SR] 強烈建議導入
TYPE_SIGNIFICANT_MOTION
複合感應器 - [C-SR] 極力建議導入及回報
TYPE_ACCELEROMETER_UNCALIBRATED
感應器。Android 裝置極度強大 建議符合這項規定,以便他們能升級至 。 - 應導入
TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
TYPE_STEP_COUNTER
Android SDK 文件所述的複合感應器。
如果裝置導入的加速計少於 3 軸,就會:
- [C-3-1] 必須導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES
感應器。 - [C-SR] 強烈_RECOMMENDED 導入及回報
TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED
感應器。
終止新規定
如果裝置導入方式包含 3 軸式加速度計和
TYPE_SIGNIFICANT_MOTION
、TYPE_TILT_DETECTOR
、TYPE_STEP_DETECTOR
、 已實作TYPE_STEP_COUNTER
複合感應器:- [C-4-1] 耗電量一律低於 4 mW。
如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀感應器, 他們會:
- [C-5-1] 必須導入
TYPE_GRAVITY
和TYPE_LINEAR_ACCELERATION
複合感應器。
如果裝置導入方式包含 3 軸式加速度計、3 軸式迴轉儀感應器, 和磁力儀感應器進行以下操作:
- [C-6-1] 必須導入
TYPE_ROTATION_VECTOR
複合感應器。
7.3.4 陀螺儀:更新 以及陀螺儀感應器的需求條件。
查看修訂版本
如果裝置導入作業包含陀螺儀,這項功能會:
- [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
- [C-1-4] 必須採用 12 位元以上的解析度。
- [C-1-5] 必須計算溫度。
- [C-1-6] 使用時請務必進行校準與補償,並且保留 。
- [C-1-7] 每 Hz 的變異數不得超過 1e-7 rad^2 / s^2 (每 Hz 的變異數,或雷比^2 / 秒)。變異數則是以 但必須受到這個值限制。也就是說 以 1 Hz 的取樣率測量陀螺儀的變異數,不應大於 高於 1e-7 rad^2/s^2。
- [C-SR] 校正錯誤應一律小於 0.01 以上 裝置在室溫下靜止時移動
- [C-SR] 強烈建議採用 16 位元以上的解析度。
- 回報的事件大小必須至少為 200 Hz。
終止新規定
如果裝置導入方式包含 3 軸式迴轉儀, ,
- [C-2-1] 必須導入
TYPE_GYROSCOPE
感應器。
如果裝置實作的陀螺儀少於 3 軸,參數:
- [C-3-1] 必須導入及回報
TYPE_GYROSCOPE_LIMITED_AXES
感應器。 - [C-SR] 強烈_RECOMMENDED 導入及回報
TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED
感應器。
終止新規定
如果裝置導入方式包含 3 軸式迴轉儀, 和磁力儀感應器進行以下操作:
- [C-4-1] 必須導入
TYPE_ROTATION_VECTOR
複合感應器。
如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀 感應器,因此會:
- [C-5-1] 必須導入
TYPE_GRAVITY
和TYPE_LINEAR_ACCELERATION
複合感應器。
7.3.10 生物特徵辨識感應器: 更新生物特徵辨識感應器的感應器相關規定。
查看修訂版本
生物特徵辨識感應器可歸類為第 3 級 (先前稱為 Strong) 第 2 級 (舊稱 Weak) 或第 1 級 (舊稱「便利」) 然後取而代之的是 這種模型這個分類會決定 生物特徵辨識感應器必須連結 Google Cloud Platform 應用程式。感應器必須符合 需要歸類為 第 1 級、第 2 級或第 3 級。
根據預設,感應器會歸類為第 1 級,因此需要 才能分類這些目標對象 指定為「類別 2」或「類別 3」。類別 2 和類別 3 生物特徵辨識可取得更多功能,詳情請參閱下文。如要在裝置實作項目中將生物特徵辨識感應器視為第 1 級, (舊稱「便利性」) 的用途如下:
- [C-1-11] 假冒及冒名要求接受率不得超過 30% 具有 (1) 假冒 A 級簡報的假冒與冒名接受率 攻擊工具 (PAI) 物種超過 30%,以及 (2) 假冒 第一級 PAI 物種的即時接受率,如 40% 以上, Android 生物特徵辨識測試通訊協定
終止新規定
如要在裝置實作項目中將生物特徵辨識感應器視為第 2 級, (原為 Weak) 客戶:
- [C-2-2] 假冒和冒名要求接受率不得超過 20% 的 (1) 假冒和冒名接受者 A 級簡報攻擊工具 (PAI) 物種不到 20% 以及 (2) 假冒 B 級 PAI 物種的假冒和冒名接受率 高於 30% Android 生物特徵辨識測試通訊協定。
如要在裝置實作下將生物特徵辨識感應器視為第 3 級, (先前稱為「Strong」) 的情況下,他們會:
- [C-3-3] 假冒及假冒他人接受率必須高於 7% 有 (1) 假冒和冒名接受者 A 級簡報攻擊工具 (PAI) 物種不到 7%,且 (2) 高於 B 級 PAI 物種的虛假或冒名接受率 大於 20% Android 生物特徵辨識測試通訊協定。
7.3.13 IEEE 802.1.15.4 (UWB): 新增 UWB 的規定部分。
查看修訂版本
7.3.13。IEEE 802.1.15.4 (UWB)
如果裝置的導入方式包含對 802.1.15.4 的支援,並且公開 功能,讓他們:
- [C-1-1] 必須在 android.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-1-6] 極力建議您通過相關法規和 由標準機構訂定的認證測試,包括 FIRA、CCC 和 CSA 表單中的指示操作。
終止新規定
7.4.1 電話:更新 GSM、CDMA 電話服務以及行動網路使用方面的通話需求 可以管理叢集設定,像是節點 資源調度、安全性和其他預先設定項目
查看修訂版本
如果裝置的實作支援 eUICC 或 eSIM 卡/內嵌 SIM 卡,且 專屬機制為第三方提供 eSIM 卡功能 開發人員的工作:
- [C-3-1] 必須 宣告
android.hardware.telephony.euicc
功能旗標請參閱EuiccManager API
。
如果裝置實作方式包含 GSM 或 CDMA 電話,則:
- [C-6-1]
SmsManager#sendTextMessage
和SmsManager#sendMultipartTextMessage
必須產生相應的呼叫CarrierMessagingService
提供文字訊息功能SmsManager#sendMultimediaMessage
敬上 和SmsManager#downloadMultimediaMessage
必須產生相應的呼叫CarrierMessagingService
以提供多媒體傳訊功能 - [C-6-2] 指定的應用程式
android.provider.Telephony.Sms#getDefaultSmsPackage
敬上 必須使用 SmsManager 收發簡訊和多媒體訊息時可用的 API。Android 開放原始碼計畫參考資料 套件/應用程式/訊息中的實作符合這項規定。 - [C-6-3] 回應
Intent#ACTION_DIAL
敬上 必須支援輸入*#*#CODE#*#*
和 觸發相應的TelephonyManager#ACTION_SECRET_CODE
廣播。 - [C-6-4] 回應
Intent#ACTION_DIAL
敬上 必須使用VoicemailContract.Voicemails#TRANSCRIPTION
以視覺化方式向使用者顯示轉錄文字的語音轉錄內容 (如果支援視覺化功能) 語音轉錄。 - [C-6-5] 必須代表所有 SubscriptionInfo 和同等規則
群組 UUID
以單一訂閱項目的形式,提供各項功能,以及供使用者瀏覽的功能
控制 SIM 卡資訊例如設定
比對出的介面
Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS
敬上 或EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS
。 - [C-6-6] 不得根據 非空值群組 UUID 和機會位元 任何使用者可見的預設用途 允許設定或控制 SIM 卡設定。
如果裝置實作項目包含 GSM 或 CDMA 電話, 系統狀態列,然後:
- [C-6-7] 必須為指定項目選取具代表性的有效訂閱方案 UUID 群組 也就是提供 SIM 卡狀態的任何用途 可能不準確或不適當這類預設用途的例子包括狀態列行動網路 訊號圖示或快速設定方塊。
- [C-SR] 強烈建議這個代表性訂閱是 成為 有效資料訂閱 除非裝置語音 來電,強烈推薦業務代表 訂閱是指有效的語音訂閱。
如果裝置實作方式包含 GSM 或 CDMA 電話,則:
- [C-6-8] 必須能夠開放,並且同時採用最大值 根據 ETSI TS 102 221 的每個 UICC 邏輯通道數 (共 20 個)。
- [C-6-10] 「不得」對使用中的電信業者應用程式套用下列任何行為
(由
TelephonyManager#getCarrierServicePackageName
指定) 自動或未經使用者明確確認:- 撤銷或限制網路存取權
- 撤銷權限
- 限制在 Android 開放原始碼計畫現有電源管理功能之外的情況下,執行背景或前景應用程式作業
- 停用或解除安裝應用程式
如果裝置實作項目包含 GSM 或 CDMA 電話服務,以及 運作中, 非機會式訂閱 共用群組 UUID 將會停用 從裝置取下,或標示為有機會從裝置中移除,然後:
- [C-7-1] 必須自動停用所有剩餘使用中的 機會式 同一個群組中的訂閱項目
如果裝置實作包含 GSM 電話,但不包括 CDMA 電話,則:
- [C-8-1] 「不得」宣告
PackageManager#FEATURE_TELEPHONY_CDMA
。 - [C-8-2] 當試圖設定任何答案時,
IllegalArgumentException
必須 偏好或允許的網路類型位元遮罩的 3GPP2 網路類型。 - [C-8-3] 必須傳回來自以下值的空白字串:
TelephonyManager#getMeid
。
如果裝置實作支援具有多個通訊埠和設定檔的 eUICC,則:
- [C-11-1] 必須宣告
android.hardware.telephony.euicc.mep
敬上 功能旗標
終止新規定
- [C-3-1] 必須 宣告
7.4.1.1 號碼封鎖相容性: 編號封鎖規定更新。
查看修訂版本
如果裝置導入方式回報
android.hardware.telephony feature
, 他們會:- [C-1-4] 請勿寫信給 平台通話記錄供應商 即可。
- [C-1-4] 必須寫入平台通話記錄供應商
已封鎖來電,而且必須過濾掉有
BLOCKED_TYPE
的來電 預設的通話紀錄檢視畫面。 - 應用程式預先安裝的來電應顯示已封鎖的通話,而且應提供使用者負擔 撥號應用程式
終止新規定
7.4.1.3 Cellular NAT-T Keepalive 卸載:「行動網路」一節 NAT-T 保持運作卸載。
查看修訂版本
7.4.1.3。行動網路 NAT-T 保持運作卸載
裝置實作方式:
- 應支援行動網路保持運作卸載。
如果裝置實作支援行動保持運作的卸載功能, 會負責向第三方應用程式提供這些功能:
- [C-1-1] 必須支援 SocketKeepAlive API。
- [C-1-2] 必須支援至少一個透過行動網路並行的保持運作運算單元。
- [C-1-3] 必須盡可能支援多個同時進行的行動網路保持運作運算單元 行動無線電 HAL 支援功能
- [C-SR] 強烈建議應支援至少三種行動網路保持運作狀態 每個無線電執行個體的運算單元數量。
如果裝置的實作不支援行動網路保持運作卸載功能, 他們會:
- [C-2-1] 必須傳回 ERROR_UNSUPPORTED。
終止新規定
7.4.2.5 Wi-Fi 位置資訊 (Wi-Fi 封包往返時間 - RTT): Wi-Fi 定位精確度更新。
查看修訂版本
如果裝置實作項目支援 Wi-Fi 定位功能,並公開 具備以下存取權:
- [C-1-4] 在第 68 號享有 80 MHz 頻寬時,請確保準確度為 2 公尺以內 百分位數 (以累計分佈函式計算)。
- [C-SR] 強烈建議在 1.5 公尺以內準確回報 和第 68 個百分位數的 80 MHz 頻寬 ( 累計分配函式)。
終止新規定
7.4.2.6 Wi-Fi Keepalive 卸載: 已更新,新增行動網路保持運作卸載要求。
查看修訂版本
裝置實作方式:
- 應提供 Wi-Fi 保持運作卸載支援。
如果裝置實作支援 Wi-Fi 保持運作卸載功能 以及向第三方應用程式提供這些功能後,應用程式會:
- [C-1-1] 必須支援 SocketKeepAlive API。
- [C-1-2] 必須支援透過 Wi-Fi 連線至少三個並行的保持運作運算單元
和至少一個保持手機運作的運算單元。
如果裝置實作不支援 Wi-Fi 保持運作卸載功能, 他們會:
- [C-2-1] 必須傳回
ERROR_UNSUPPORTED
。
7.4.2.9 首次使用信任 (TOFU): 新增「首次使用時信任」一節。
查看修訂版本
7.4.2.9 首次使用信任 (TOFU)
如果裝置的實作方式支援首次使用時可信任 (TOFU),並允許 使用者必須定義 WPA/WPA2/WPA3-Enterprise 設定,然後他們才能:
- [C-4-1] 必須讓使用者能選擇使用 TOFU。
終止新規定
7.4.3 藍牙:更新至 藍牙需求。
查看修訂版本
如果實作的裝置支援藍牙音訊設定檔,就會:
- 應支援進階音訊轉碼器和藍牙音訊轉碼器 (例如 LDAC) 採用 A2DP。
如果裝置實作傳回
true
的BluetoothAdapter.isLeAudioSupported()
API,然後會:- [C-7-1] 必須支援單點傳播用戶端。
- [C-7-2] 必須支援 200 萬個菲律賓,
- [C-7-3] 必須支援 LE 延伸廣告。
- [C-7-4] CIG 中至少須支援 2 個 CIS 連線。
- [C-7-5] 必須啟用 BAP 單點傳播用戶端、CSIP 集合協調器、MCP 伺服器 VCP 控制器和 CCP 伺服器。
- [C-SR] 極力建議啟用 HAP 單點傳播用戶端。
如果裝置實作傳回
true
的BluetoothAdapter.isLeAudioBroadcastSourceSupported()
API,然後會:- [C-8-1] 單一 BIG 中至少須支援 2 個 BIS 連結。
- [C-8-2] 必須啟用 BAP 廣播來源、BAP 廣播助理 。
- [C-8-3] 必須支援 LE 定期廣告。
如果裝置實作傳回
true
的BluetoothAdapter.isLeAudioBroadcastAssistantSupported()
API,然後會:- [C-9-1] 必須支援 PAST (定期廣告同步傳輸)。
- [C-9-2] 必須支援 LE 定期廣告。
如果裝置實作項目宣告
FEATURE_BLUETOOTH_LE
,就會:- [C-10-1] 必須採用 +/-9dB 的 RSSI 測量結果,才能確保 95% 的
測量距離與參考裝置 (
ADVERTISE_TX_POWER_HIGH
。 - [C-10-2] 必須加入 Rx/Tx 修正,才能減少每個管道的偏差 測量 3 個聲道 每個天線的測量值 (如果使用多個) 介於彼此的 +/-3dB 之間,佔 95% 的 測量資料
- [C-SR] 強烈建議你評估並補償因 Rx 偏移
確保 BLE RSSI 的中位數是 -60dBm +/-10 dB,距離
參考裝置傳輸時間:
ADVERTISE_TX_POWER_HIGH
,裝置來源 並將方向定向為「平行平面」螢幕寬度都一樣 往上移動即可 - [C-SR] 強烈建議你評估與補償的 Tx 偏移量
從參照掃描掃描時,確保 BLE RSSI 的中位數為 -60dBm +/-10 dB
裝置定位在 1 公尺以內,且傳輸至
ADVERTISE_TX_POWER_HIGH
,即裝置的功能取向 「平行平面」就是面對相同方向的螢幕
我們強烈建議您遵循「在家狀態校正規定」中所述的評估設定步驟。
如果裝置的實作支援藍牙 5.0 版,就會發生以下情形:
- [C-SR] 強烈建議你為下列項目提供支援:
- 低 200 萬階段
- LE 轉碼器 PHY
- LE 廣告額外資訊
- 定期廣告
- 至少 10 個廣告集
- 至少 8 個 LE 並行連線。每個連線可以 連線拓撲角色
- LE Link 層隱私權
- 「解決問題清單」項目大小至少為 8 個項目
終止新規定
7.4.9 UWB:新增規定 「UWB 硬體」部分
查看修訂版本
7.4.9。UWB
如果裝置導入作業回報支援功能
android.hardware.uwb
透過android.content.pm.PackageManager
類別,然後執行以下作業:- [C-1-1] 必須確保距離測量結果在 +/-15 公分以內以 95% 為單位 只能測量距離 非反射性的腔
- [C-1-2] 必須確保距離測量結果的中位數是 1 公尺 在參照裝置的 [0.75m, 1.25m] 內,實際資料 距離以 DUT 站立且傾斜的頂端邊緣為測量單位 45 度。
我們強烈建議您按照 所在地校正要求。
終止新規定
7.5 相機:更新 HDR 10 位元輸出功能需求
查看修訂版本
如果裝置的實作支援 HDR 10 位元輸出功能,就會:
- [C-2-1] 每部相機裝置至少須支援 HLG HDR 設定檔 支援 10 位元輸出
- [C-2-2] 必須支援 10 位元輸出,供主要後置鏡頭或 主要前置鏡頭
- [C-SR] 強烈建議同時支援 10 位元的雙重輸出內容 相機上
- [C-2-3] 所有成員都必須支援相同的 HDR 設定檔 邏輯相機支援 BACKWARD_COMPATIBLE 的實體子相機,以及 邏輯性相機本身
適用於支援 10 位元 HDR,且採用
android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO
API,則具有以下權限:- [C-3-1] 必須支援在所有具回溯相容性的實體之間切換
透過邏輯相機上的
CONTROL_ZOOM_RATIO
控制項操作。
終止新規定
7.7.2 USB 主機模式: 雙角色通訊埠修訂版本。
查看修訂版本
如果裝置實作項目包含支援主機模式和 USB 的 USB 連接埠 Type-C 代表:
- [C-4-1] 必須實作 USB 定義的雙角色通訊埠功能 Type-C 規格 (第 4.5.1.3.3 節)。雙通道 角色連接埠,如果是支援 3.5 公釐耳機插孔的裝置,則為 USB 接收器 自動偵測 (主機模式) 可能預設為關閉,但只有在執行 使用者就無法啟用
7.11 媒體成效類別: 更新後納入 Android T。
查看修訂版本
如果裝置實作針對
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
,他們:請參閱第 2.2.7 節。 瞭解裝置專屬的需求
9. 安全性模型相容性
9.1 權限:延長 預先安裝應用程式至 APEX 檔案的權限許可清單路徑。
查看修訂版本
- [C-0-2]
protectionLevel
的PROTECTION_FLAG_PRIVILEGED
權限 只能授予預先安裝在以下特殊權限路徑的應用程式: 系統映像檔 (以及 APEX 檔案), 部分 GCP 明確列入許可清單的權限 應用程式。Android 開放原始碼計畫實作方式符合這項規定,請參閱 遵循etc/permissions/
路徑,並使用system/priv-app
路徑做為 特殊權限路徑
- [C-0-2]
9.7 安全性功能: 更新初始化需求條件,確保核心完整性。
查看修訂版本
核心完整性和自我保護功能是 Android 安全性中不可或缺的一環。 裝置實作方式:
- [C-SR] 強烈建議在核心中啟用堆疊初始化功能,以便
禁止使用未初始化的本機變數 (
CONFIG_INIT_STACK_ALL
或CONFIG_INIT_STACK_ALL_ZERO
)。此外,不要假設 用於初始化本機值的值。
終止新規定
- [C-SR] 強烈建議在核心中啟用堆疊初始化功能,以便
禁止使用未初始化的本機變數 (
9.8.7 隱私權 - 剪貼簿存取權: 剪下/複製/貼上後 60 分鐘後自動清除剪貼簿資料 活動以保護使用者隱私
查看修訂版本
裝置實作方式:
- [C-0-1] 「不得」傳回剪貼簿中的剪輯資料 (例如透過
ClipboardManager
敬上 API) 的情況,除非這是 第三方 應用程式是預設的輸入法編輯器,或者是目前聚焦的應用程式。 - [C-0-2] 最多只能清除剪貼簿資料 如果距離上次響起 60 分鐘 或者從剪貼簿讀取。
- [C-0-1] 「不得」傳回剪貼簿中的剪輯資料 (例如透過
9.11 金鑰和憑證: 更新安全螢幕鎖定需求條件,包括 將 ECDH 和 3DES 新增至加密演算法。
查看修訂版本
如果實作的裝置支援安全螢幕鎖定,它會:
- [C-1-2] 必須導入 RSA、AES、ECDSA ECDH (如果支援 IKeyMintDevice)、3DES 以及 HMAC 密碼編譯演算法,以及 MD5、SHA1 和 SHA-2 系列雜湊 能夠妥善支援 Android KeyStore 系統支援的函式 所在區域的演算法,安全地與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境,包括《數位市場法》上游 Android 開放原始碼 Project (Android 開放原始碼計畫) 使用 值得信賴,但 其他以 ARM TrustZone 為基礎的解決方案,或是由第三方人員 可替代實作方式,以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
9.11.1 安全螢幕鎖定、驗證和虛擬裝置: 新增虛擬裝置和驗證傳輸的需求區段。
查看修訂版本
如果裝置導入作業新增或修改要解鎖的驗證方法 鎖定螢幕,而新的驗證方法是以實體權杖為基礎 或是位置:
- [C-6-3] 必須要求使用者接受其中一項建議的主要執行個體 至少每隔一次驗證方式 (PIN 碼、解鎖圖案、密碼) 驗證 4 小時。實體權杖符合 C-X 中 TrustAgent 實作方面的需求、逾時限制 則會套用 C-9-5 所定義。
如果裝置實作允許應用程式建立次要執行個體 虛擬螢幕 不支援相關聯的輸入事件,例如透過
VirtualDeviceManager
、 他們會:- [C-9-1] 預設顯示器處於鎖定狀態,並在下列情況下解鎖這些次要虛擬螢幕: 裝置的預設螢幕已解鎖。
若應用程式允許實作裝置,則可建立次要虛擬螢幕 並支援相關的輸入事件,例如: VirtualDeviceManager 他們會:
- [C-10-1] 必須為每個虛擬裝置支援獨立的鎖定狀態
- [C-10-2] 必須在閒置逾時時中斷所有虛擬裝置的連線
- [C-10-3] 必須設定閒置逾時
- [C-10-4] 當使用者啟動 鎖定功能,包括 根據手持裝置所需的鎖定式使用者預設用途 (請參閱 第 2.2.5 節 [9.11/H-1-2])
- [C-10-5] 每位使用者都必須有獨立的虛擬裝置執行個體
- [C-10-6] 必須停用相關輸入事件的建立功能:
VirtualDeviceManager
(如以下情況表示)DevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] 必須為每個虛擬裝置使用個別的剪貼簿 (或為虛擬裝置停用剪貼簿)
- [C-10-11] 必須在虛擬裝置上停用驗證 UI,包括 知識因素輸入和生物特徵辨識提示
- [C-10-12] 必須限制顯示透過虛擬裝置啟動的意圖 只會在同個虛擬裝置上運作
- [C-10-13] 不得使用虛擬裝置鎖定狀態做為使用者驗證方式
取得 Android KeyStore 系統的授權。詳情請見
KeyGenParameterSpec.Builder.setUserAuthentication*
。
如果裝置實作項目允許使用者轉移主要裝置 從來源裝置到目標裝置的驗證知識因素 例如:進行目標裝置的初始設定時,他們會:
- [C-11-1] 必須加密知識因素,保護保證類似於 這些 Pod 中 Google Cloud Key Vault 服務 傳輸安全性白皮書 從來源裝置到目標裝置的知識因素 知識因子無法從遠端解密或用於遠端解鎖 任一裝置。
- [C-11-2] 必須在來源裝置上要求使用者確認 能否掌握來源裝置的知識因素,再轉移知識因素 複製到目標裝置
- [C-11-3] 必須,目標裝置上未設定任何主要驗證方式 並請使用者確認轉移的知識因素 將知識因素設為主要裝置 驗證知識因素 可使用從來源裝置轉移的任何資料。
如果裝置導入了安全螢幕鎖定,且包含一或多個 可藉由信任代理程式呼叫
TrustAgentService.grantTrust()
System APIFLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE
標記會:- [C-12-1] 連線至
grantTrust()
以及設有螢幕鎖定畫面的鄰近實體裝置 以該螢幕鎖定方式驗證