本頁面由 Cloud Translation API 翻譯而成。

Android 13 相容性定義

1. 簡介

本文件列舉讓裝置與 Android 13 相容，必須符合的規定。

根據 RFC2119 中定義的 IETF 標準，使用「必須」、「不得」、「必要」、「應」、「不應」、「不應」、「建議」、「建議」、「可能」和「選用」。

如本文件所述，「裝置實作者」或「實作器」是指開發執行 Android 13 硬體/軟體解決方案的人員或機構。「裝置實作」或「實作」是指目前開發的硬體/軟體解決方案。

為了能與 Android 13 相容，裝置實作項目「必須」符合此相容性定義中列出的要求，包括透過參考資料納入的所有文件。

如果這項定義或第 10 節所述的軟體測試處於靜音、不模糊或不完整，裝置實作人員必須負責確保與現有實作的相容性。

因此，Android 開放原始碼計畫既是 Android 的參考資料，也是偏好的實作方式。我們強烈建議裝置實作者根據 Android 開放原始碼計畫提供的「上游」原始碼，盡可能設定實作項目。雖然有些元件可能會以替代實作取代，但強烈建議不要遵循這種做法，因為傳遞軟體測試會變得更加困難。實作者有責任確保與標準 Android 實作項目完全相容，包括 Compatibility Test Suite。最後，請注意，本文件明確禁止特定元件替換和修改。

本文件中連結的許多資源都是直接或間接從 Android SDK 衍生，運作方式與 SDK 說明文件中的資訊相同。在任何情況下，如果此 Compatibility 定義或 Compatibility Test Suite 無法判別 SDK 說明文件，SDK 說明文件就會被視為具有權威性。本文件的連結資源中提供的任何技術細節，都會視為屬於此相容性定義的一部分。

1.1 文件結構

1.1.1. 各裝置類型的規定

第 2 節包含適用於特定裝置類型的所有要求。第 2 節中的每個子區段分別適用於特定裝置類型。

請參閱第 2 節之後的章節，瞭解適用於所有 Android 裝置實作項目的所有其他規定。這些需求在本文件中稱為「核心需求」。

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 包含：Section ID / Device Type ID - Condition ID - Requirement ID (例如 7.4.3/A-0-1)。

2. 裝置類型

Android 開放原始碼計畫提供軟體堆疊，可用於各種裝置類型和板型規格。為支援裝置的安全性，軟體堆疊 (包括任何替代的 OS 或替代核心實作) 應在安全環境中執行，如第 9 節及本 CDD 中所述。有些裝置類型具有相對較高的應用程式發布生態系統。

本節說明這些裝置類型，以及各裝置類型適用的其他要求和建議。

凡是不符合上述任何裝置類型的 Android 裝置實作項目，仍必須符合本相容性定義其他章節中的所有規定。

2.1 裝置設定

如要瞭解各裝置類型的硬體設定主要差異，請參閱本節所述的裝置專屬需求。

2.2. 手持裝置需求

「Android 手持裝置」是指經常在手持裝置時採用的 Android 裝置實作項目，例如 mp3 播放器、手機或平板電腦。

如果 Android 裝置的實作方式符合下列所有條件，就會歸類為手持裝置：

請備妥可提供行動用的電源 (例如電池)。
實體對角螢幕尺寸應介於 3.3 吋 (3.3 吋) 至 2.5 吋 (如果是裝置實作，且搭載 API 級別 29 或更早的機型) 到 8 吋。

本節其餘規定僅適用於 Android 手持裝置實作方式。

注意：不適用於 Android Tablet 裝置的要求會標上 *。

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 吋，長邊為 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] 必須回報裝置是否透過系統屬性 graphics.gpu.profiler.support 回報 GPU 剖析功能。

如果手持裝置實作項目透過系統屬性 graphics.gpu.profiler.support 宣告支援，則程式碼會：

[7.1.4.6/H-1-1] 必須回報為輸出符合 Perfetto 說明文件中 GPU 計數器和 GPU 轉譯階段的結構定義的 protobuf 追蹤記錄。
[7.1.4.6/H-1-2] 必須按照 GPU 計數器追蹤封包 proto 回報裝置 GPU 計數器的一致值。
[7.1.4.6/H-1-3] 必須遵循轉譯階段追蹤封包 proto，回報裝置 GPU RenderStage 的符合值。
[7.1.4.6/H-1-4] 必須依照下列格式回報 GPU 頻率追蹤點：power/gpu_frequency。

手持裝置實作方式：

[7.1.5/H-0-1] 必須支援上游 Android 開放原始碼所實作的舊版應用程式相容性模式。也就是說，裝置實作「不得」變更啟用相容性模式的觸發條件或門檻，也不得變更相容性模式本身的行為。
[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 的應用程式)，或是長按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 處理 ACTION_ASSIST 的活動 (如果前景活動未處理這些長按事件)。
[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 測量結果後立即回報，即使系統尚未回報 GPS/GNSS 計算出的位置也一樣。
[7.3.3/H-2-2] 必須回報 GNSS 虛擬範圍和虛擬範圍速率；判斷位置後，如果保持靜止或移動高度低於 0.2 公尺的每秒平方差，就足以在 20% 以內，每秒 0.2 公尺內計算速度至少為 20%，且每 0.2 公尺範圍內的速度至少為 0.2 公尺。

如果手持裝置實作含有 3 軸式迴轉儀，請按照以下步驟操作：

[7.3.4/H-3-1] 事件的回報頻率必須至少為 100 Hz。
[7.3.4/H-3-2] 必須能夠測量每秒高達 1000 度的螢幕方向變化。

手持裝置實作項目，可撥打語音通話，且在 getPhoneType 中表示 PHONE_TYPE_NONE 以外的任何值：

[7.3.8/H] 必須使用鄰近感應器。

手持裝置實作方式：

[7.3.11/H-SR-1] 強烈建議我們支援在 6 度自由移動的姿勢感應器。
[7.4.3/H] 必須支援藍牙和藍牙 LE。

如果裝置透過宣告 PackageManager.FEATURE_WIFI_RTT 來支援 Wi-Fi 和 Wi-Fi 位置 (Wi-Fi 封包往返時間 - RTT)，即可支援 Wi-Fi 鄰近感知網路 (NAN) 通訊協定，那麼：PackageManager.FEATURE_WIFI_AWARE

[7.4.2.5/H-1-1] 必須正確回報在第 68 個百分位數 (以第 160 MHz 測量到 +/-1 公尺頻寬) 範圍內，(在第 80 MHz 時為第 8 毫秒，在第 80 MHz 時為第 1.5 公尺，在第 80 MHz 時，第 1.5 公尺與第 8 毫秒的頻寬)，
[7.4.2.5/H-SR-1] 明顯建議，在第 90 個百分位數 (以第 160 MHz 的頻寬在第 160 MHz 之間，從第 80 公分 (MHz) 到第 19 個百分位數) 到 80 公分 +/-2 計的頻寬

強烈建議您遵循「Presence Calibration」中指定的評估設定步驟。

如果手持裝置實作包含使用 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] 如果核心和使用者空間可用的記憶體少於 1 GB，則必須針對 ActivityManager.isLowRamDevice() 傳回「true」。

如果手持裝置實作項目宣告僅支援 32 位元 ABI：

[7.6.1/H-1-1] 如果預設顯示畫面使用最高 qHD (例如 FWVGA)，核心和使用者空間可用的記憶體必須至少為 416 MB。
[7.6.1/H-2-1] 如果預設顯示畫面採用最高 HD+ 的 framebuffer 解析度 (例如 HD、WSVGA)，核心和使用者空間可用的記憶體至少須為 592 MB。
[7.6.1/H-3-1] 如果預設螢幕使用最高 FHD (例如 WSXGA+) 的 framebuffer 解析度，核心和使用者空間可用的記憶體必須至少為 896 MB。
[7.6.1/H-4-1] 如果預設顯示畫面採用最高 QHD (例如 QWXGA) 的影格緩衝區解析度，核心和使用者空間可用的記憶體「必須」至少為 1344 MB。

如果手持裝置實作項目宣告支援任何 64 位元 ABI (無論是否為 32 位元 ABI)：

[7.6.1/H-5-1] 如果預設顯示畫面使用最高 qHD (例如 FWVGA)，核心和使用者空間可用的記憶體必須至少為 816 MB。
[7.6.1/H-6-1] 如果預設顯示畫面採用最高 HD+ 的 framebuffer 解析度 (例如 HD、WSVGA)，核心和使用者空間可用的記憶體「必須」至少為 944 MB。
[7.6.1/H-7-1] 如果預設顯示畫面使用最高 FHD 的影格緩衝區解析度 (例如 WSXGA+)，核心和使用者空間可用的記憶體「必須」至少為 1280 MB。
[7.6.1/H-8-1] 如果預設顯示畫面使用最高 QHD (例如 QWXGA) 的影格緩衝區解析度，核心和使用者空間可用的記憶體「必須」至少為 1824 MB。

請注意，上述的「核心和使用者空間可用的記憶體」是指除了已用於無線電、影片等硬體元件的所有記憶體，這些記憶體不在核心在裝置實作上的控制下所提供的記憶體空間。

如果手持裝置實作項目所含的記憶體容量小於或等於 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] 至少要具備 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。
應宣告功能旗標 android.hardware.ram.normal。

如果手持裝置實作項目包含大於或等於 2 GB 且核心和使用者空間可用的記憶體小於 4 GB，則執行以下動作：

[7.6.1/H-SR-1] 強烈建議你僅支援 32 位元的使用者空間 (應用程式和系統程式碼)

如果手持裝置實作包含的核心記憶體和使用者空間可用的記憶體少於 2 GB，程式碼就會：

[7.6.1/H-1-1] 僅支援 32 位元 ABI。

手持裝置實作方式：

[7.6.2/H-0-1] 「不得」提供小於 1 GiB 的應用程式共用儲存空間。
[7.7.1/H] 必須採用支援週邊裝置模式的 USB 連接埠。

如果手持裝置實作包含支援週邊裝置模式的 USB 連接埠，這兩者就會：

[7.7.1/H-1-1] 必須實作 Android Open Accessory (AOA) API。

如果手持裝置實作包含支援主機模式的 USB 連接埠，就會：

[7.7.2/H-1-1] 必須按照 Android SDK 說明文件中所述實作 USB 音訊類別。

手持裝置實作方式：

[7.8.1/H-0-1] 必須包含麥克風。
[7.8.2/H-0-1] 必須具有音訊輸出並宣告 android.hardware.audio.output。

如果手持裝置實作能符合支援 VR 模式的所有效能需求，且提供相關支援，那麼：

[7.9.1/H-1-1] 必須宣告 android.hardware.vr.high_performance 功能標記。
[7.9.1/H-1-2] 「必須」納入一個可實作 android.service.vr.VrListenerService 的應用程式，該應用程式可透過 android.app.Activity#setVrModeEnabled 啟用 VR 應用程式。

如果手持裝置實作項目包含主機模式和實作 (USB 音訊類別) 的一或多個 USB-C 連接埠，除了第 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.RecognizerIntent.ACTION_WEB_SEARCH`。否則會傳送 `android.speech.RecognizerIntent.ACTION_WEB_SEARCHandroid.speech.action.VOICE_SEARCH_HANDS_FREE`
		來電	輸入內容：短暫按下輸出：接聽來電
		來電	輸入端：長按輸出：拒接來電
		通話中	輸入內容：短暫按下輸出：結束通話
		通話中	輸入端：長按輸出：將麥克風設為靜音或取消靜音
億	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] 必須播送 Intent ACTION_HEADSET_PLUG，並在「麥克風」額外將 0 設為 0。

偵測到 USB 音訊端子類型 0x0402 時，會：

[7.8.2.2/H-3-1] 必須廣播 Intent ACTION_HEADSET_PLUG，並在「麥克風」額外設定設為 1。

在 USB 週邊裝置連線時呼叫 API AudioManager.getDevices() 時：

[7.8.2.2/H-4-1] 如果 USB 音訊終端機類型欄位為 0x0302，則「必須」列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，以及角色 isSink()。
[7.8.2.2/H-4-2] 如果 USB 音訊終端機類型欄位為 0x0402，則必須列出一種類型的裝置 AudioDeviceInfo.TYPE_USB_HEADSET，以及角色 isSink()。
[7.8.2.2/H-4-3] 如果 USB 音訊終端機類型欄位為 0x0402，則「必須」列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，以及 isSource() 的角色。
[7.8.2.2/H-4-4] 如果 USB 音訊終端機類型欄位為 0x603，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置，以及角色 isSink()。
[7.8.2.2/H-4-5] 如果 USB 音訊終端機類型欄位為 0x604，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSource() 的角色。
[7.8.2.2/H-4-6] 如果 USB 音訊終端機類型欄位為 0x400，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSink()。
[7.8.2.2/H-4-7] 如果 USB 音訊終端機類型欄位為 0x400，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSource() 的角色。
[7.8.2.2/H-SR-1] 強烈建議在 USB-C 音訊週邊裝置連線時執行 USB 描述元列舉、在 1000 毫秒內識別終端機類型和廣播意圖 ACTION_HEADSET_PLUG。

如果手持裝置實作項目宣告 android.hardware.audio.output 和 android.hardware.microphone，兩者會：

[5.6/H-1-1] 平均連續往返延遲時間須達 500 毫秒或更短於 5 次以上，且資料路徑的平均絕對偏差小於 50 毫秒：「從喇叭連接麥克風」、「3.5 mm 迴圈轉接器」(如果支援)、USB 回循環轉接器 (如果支援)。
[5.6/H-1-2] 在喇叭到麥克風資料路徑上，至少須有 5 次測量，且輕觸音調的平均延遲時間至少為 500 毫秒。

如果手持裝置實作包含至少一項觸覺回饋器，行為器就會：

[7.10/H]* 不應使用超遠旋轉質量 (ERM) 觸動式致動器 (震動器)。
[7.10/H]* 應將執行器擺在一般手持或觸碰裝置的位置。
[7.10/H]* 應在 android.view.HapticFeedbackConstants 中實作清楚觸覺回饋的所有公開常數 (CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、KEYBOARD_RELEASE、KEYBOARD_TPREURE_VILOREKEY_REKEY_VISHSERT、GNG_VISERT、GNG_VISERT)。
。PRIMITIVE_*只有在震動器能夠支援相對較低的頻率時，才能使用上述部分基元 (例如 LOW_TICK 和 SPIN)。
[7.10/H]* 應遵循 android.view.HapticFeedbackConstants 中的對應公開常數指南，與建議的 android.os.VibrationEffect 常數，以及對應的振幅關係。
[7.10/H]* 應遵循 createOneShot() 和 createWaveform() API 的品質評估。
[7.10/H]* 必須驗證公開 android.os.Vibrator.hasAmplitudeControl() API 的結果是否正確反映震動功能的功能。

線性共振致動器 (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，藉此驗證實作狀態。
[7.10/H]* 應針對觸覺常數執行品質評估。
[7.10/H]* 如果需要針對不支援的基元進行備用設定，應按照常數的實作指南中的說明進行驗證及更新。

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)

手持裝置實作「必須」支援下列影片編碼格式，且可供第三方應用程式使用：

[5.2/H-0-1] H.264 AVC
[5.2/H-0-2] VP8

手持裝置實作「必須」支援下列影片解碼格式，並將這些格式提供給第三方應用程式：

[5.3/H-0-1] H.264 AVC
[5.3/H-0-2] H.265 HEVC
[5.3/H-0-3] MPEG-4 SP
[5.3/H-0-4] VP8
[5.3/H-0-5] VP9

2.2.3. 軟體

手持裝置實作方式：

[3.2.3.1/H-0-1] 「必須」有一個應用程式依 SDK 文件中所述的方式處理 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT 意圖，並使用 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 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] 必須支援複合式通知。
[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 存取的使用者預設用途 (例如輸出端切換器)，讓使用者在應用程式發布具有 MediaSession 權杖的 MediaStyle 通知時，切換可用的媒體路徑，例如藍牙裝置和提供給 MediaRouter2Manager 的路徑。

如果手持裝置導入方式支援小幫手動作，會發生以下情況：

[3.8.4/H-SR-2] 強烈建議使用長按 HOME 鍵做為指定互動來啟動輔助應用程式 (如第 7.2.3 節所述)。必須啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式，或處理 ACTION_ASSIST 意圖的活動。

如果手持裝置實作支援 conversation notifications，並將其分組為另一個區段，與快訊和非對話通知和非對話通知分組，這兩者會：

[3.8.4/H-1-1]* 「必須」在非對話通知之前顯示對話通知，但持續性前景服務通知和 importance:high 通知除外。

如果 Android 手持裝置可支援螢幕鎖定，請按照下列步驟操作：

[3.8.10/H-1-1] 必須顯示螢幕鎖定畫面通知，包括媒體通知範本。

如果手持裝置支援安全螢幕鎖定，功能會：

[3.9/H-1-1] 必須實作 Android SDK 說明文件中定義的所有裝置管理政策。

如果手持裝置實作項目支援 ControlsProviderService 和 Control API，並允許第三方應用程式發布裝置控制項，就會執行以下動作：

[3.8.16/H-1-1] 必須宣告功能旗標 android.software.controls，並將其設為 true。
[3.8.16/H-1-2] 必須為使用者提供需求，讓使用者能透過 ControlsProviderService 和 Control API，透過第三方應用程式註冊的控制項新增、編輯、選取及操作使用者慣用的裝置控制項。
[3.8.16/H-1-3] 「必須」在預設啟動器的三次互動中，提供使用者預設用途的存取權。
[3.8.16/H-1-4] 「必須」正確顯示這名使用者，才能使用透過 ControlsProviderService API 提供控制項的每個第三方應用程式，以及 Control API 提供的任何指定欄位。
[3.8.16/H-1-5] 必須向使用者提供需求，停用透過 ControlsProviderService 和 Control Control.isAuthRequired API 註冊的第三方應用程式指定的驗證裝置控制設定。

相反地，如果手持裝置實作項目未實作這類控制項，則：

[3.8.16/H-2-1] 必須針對 ControlsProviderService 和 Control API 回報 null。
[3.8.16/H-2-2] 必須宣告功能旗標 android.software.controls，並將其設為 false。

如果手持裝置的實作無法在鎖定任務模式下執行，那麼將內容複製到剪貼簿時：

[3.8.17/H-1-1] 「必須」向使用者顯示確認訊息，說明資料已複製到剪貼簿 (例如「複製內容」的縮圖或快訊)。此外，請加入此處，指出剪貼簿資料是否會跨裝置同步。

手持裝置實作方式：

[3.10/H-0-1] 必須支援第三方無障礙服務。
[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] 主畫面函式的手勢辨識區域高度應與螢幕底部相距 32 dp 以上。

如果手持裝置實作以手勢做為手勢，從螢幕左側或右側邊緣移動：

[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 保護，且「必須」啟動從 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI 剖析的 Intent 活動。

2.2.4. 效能與功率

[8.1/H-0-1] 影格延遲時間一致。影格延遲時間或轉譯影格延遲「不得」在一秒內發生超過 5 個影格，且每秒不得超過 1 個影格。
[8.1/H-0-2] 使用者介面延遲時間。裝置實作「必須」在 36 秒內捲動 Android Compatibility Test Suite (CTS) 定義的 1 萬個清單項目清單，確保提供低延遲的使用者體驗。
[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 開放原始碼計畫提供的裝置電源管理功能，或擴充 Android 開放原始碼計畫包含的功能，就會：

[8.3/H-1-1] 「必須」提供使用者預設用途，才能啟用和停用省電模式功能。
[8.3/H-1-2] 「必須」提供使用者預設用途，讓系統顯示不受應用程式待命和打盹省電模式限制的應用程式。

手持裝置實作方式：

[8.4/H-0-1] 「必須」提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量」，以及元件隨時間而造成的電池耗電預估情形 (如 Android 開放原始碼計畫網站上所述)。
[8.4/H-0-2] 必須以毫安小時 (mAh) 回報所有耗電量值。
[8.4/H-0-3] 必須根據每個程序的 UID 回報 CPU 耗電量。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 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，以滿足這項需求。
[9.11/H-0-5] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非產生至少 10 萬個指定 SKU 的單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰 MAY。
[9/H-0-1] 必須宣告「android.hardware.security.model.compatible」功能。

請注意，如果裝置實作項目已在較舊的 Android 版本上啟動，這類裝置不必具有受隔離執行環境支援的 KeyStore，並支援金鑰認證，除非其宣告了需要獨立執行環境支援的 KeyStore 的 android.hardware.fingerprint 功能。

如果手持裝置支援安全螢幕鎖定，行為會：

[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 將麥克風音訊資料或其衍生資料傳輸至系統伺服器，或透過 ContentCaptureManager API 傳送至 ContentCaptureService。
[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() 傳回的麥克風，顯示最近使用和使用中的應用程式清單，以及與這些應用程式相關的歸因訊息。

如果手持裝置實作項目宣告 android.hardware.camera.any，就會：

[9.8.2/H-5-1] 當應用程式存取即時相機資料時，「必須」顯示攝影機指標，但如果只有具備第 9.1 節(CDD ID [C-4-X]) 所述角色的應用程式才能存取相機，則不需要顯示攝影機指標。
[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 二進位檔「必須」接受做為輸入 protobuf 設定，且符合 Perfetto 說明文件中定義的結構定義。
- [6.1/H-0-4]* Perfetto 二進位檔「必須」以輸出為 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
- [6.1/H-0-5]* 請務必透過 Perfetto 二進位檔提供至少 perfetto 說明文件中所述的資料來源。
- [6.1/H-0-6]* 預設必須啟用 Perfetto 追蹤 Daemon (系統屬性 persist.traced.enable)。

2.2.7. 手持媒體效能類別

如要瞭解媒體效能類別的定義，請參閱 7.11 節。

2.2.7.1。媒體

如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.S，那麼：

必須符合 Android 12 CDD 第 2.2.7.1 節所列的媒體要求。

如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：

[5.1/H-1-1] 必須通告可透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法在任何轉碼器組合中同時執行的硬體視訊解碼器工作階段數量上限。
[5.1/H-1-2] 以 1080p 解析度@30 fps 同時執行的任何轉碼器組合，都必須支援 6 個硬體視訊解碼器工作階段執行個體 (AVC、HEVC、VP9、AV1 或以上)。
[5.1/H-1-3] 「必須」通告可透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法在任何轉碼器組合中並行執行的硬體視訊編碼器工作階段數量上限。
[5.1/H-1-4] 在任何以 1080p 解析度@30fps 執行的轉碼器組合中，必須支援 6 個硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或以上) 執行個體。
[5.1/H-1-5] 必須通告可在任何轉碼器組合中同時透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法執行的硬體視訊編碼器和解碼器工作階段數量上限。
[5.1/H-1-6] 以 1080p@30fps 解析度並行執行的所有轉碼器組合，都必須支援 6 個硬體視訊解碼器和硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或以上) 的執行個體。
[5.1/H-1-7] 針對 1080p 以下的所有硬體視訊編碼器，在負載不足的情況下，轉碼器初始化延遲時間不得超過 40 毫秒。此處載入定義為使用硬體視訊轉碼器和 1080p 音訊錄影初始化的 1080p 至 720p 純影片轉碼工作階段。針對 Dolby Vision 轉碼器，轉碼器的初始化延遲時間不得超過 50 毫秒。
[5.1/H-1-8] 在負載下，128 kbps 的轉碼器初始化延遲時間不得超過 30 毫秒；如果音訊編碼器處於載入狀態，則所有音訊編碼器的位元率音訊編碼工作階段都必須低於 30 毫秒。此處載入定義為使用硬體視訊轉碼器和 1080p 影音錄製初始化的 1080p 至 720p 純視訊轉碼工作階段。
[5.1/H-1-9] 必須支援以 1080p 解析度@30 fps 同時執行的任何轉碼器組合，支援 2 個安全硬體視訊解碼器工作階段執行個體 (AVC、HEVC、VP9、AV1 或以上)。
[5.1/H-1-10] 對於以 1080p 解析度@30fps 同時執行的轉碼器組合，必須支援 3 個不安全的硬體視訊解碼器工作階段執行個體，以及 1 個安全硬體視訊解碼器工作階段執行個體 (共 4 個執行個體) (AVC、HEVC、VP9、AV1 或以上版本)。
[5.1/ H-1-11] 裝置中的每個硬體 AVC、HEVC、VP9 或 AV1 解碼器都必須支援安全解碼器。
[5.1/H-1-12] 在負載不足的情況下，針對 1080p 以下所有硬體視訊解碼器，轉碼器初始化延遲時間不得超過 40 毫秒。此處載入的定義為使用硬體視訊轉碼器和 1080p 音訊影片播放初始化的 1080p 至 720p 純影片轉碼工作階段。針對 Dolby Vision 轉碼器，轉碼器的初始化延遲時間不得超過 50 毫秒。
[5.1/H-1-13] 處於載入狀態時，所有音訊解碼器的轉碼器初始化延遲時間不得超過 30 毫秒，或降低所有音訊解碼器的位元率音訊解碼工作階段。此處載入的定義為使用硬體視訊轉碼器和 1080p 影音播放初始化的 1080p 至 720p 純影片轉碼工作階段。
[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] 在載入 1080p 60 fps 影片的情況下，「不得」在 10 秒內捨棄超過 1 個影格 (也就是影格遺失率低於 0.167%)。載入定義為使用硬體視訊轉碼器和 128 kbps AAC 音訊播放的 1080p 至 720p 純影片轉碼工作階段。
[5.3/H-1-2] 如果在 60 fps 影片載入狀態下播放解析度影片，則「不得」在 10 秒內捨棄超過 1 個影格。載入定義為使用硬體視訊轉碼器和 128 kbps AAC 音訊播放的 1080p 至 720p 純影片轉碼工作階段。
[5.6/H-1-1] 使用 OboeTester 觸控色調測試或 CTS Verifier 點按色調測試時，輕觸音延遲時間必須維持在 80 毫秒以下。
[5.6/H-1-2] 至少使用一個支援的資料路徑，往返音訊延遲時間不得超過 80 毫秒。
[5.6/H-1-3] 必須支援大於 24 位元的音訊，才能輸出超過 3.5 公釐的立體聲音訊插孔；如果透過完整的資料路徑支援低延遲和串流設定，則必須支援使用 USB 音訊。針對低延遲設定，應用程式應在低延遲回呼模式下使用 AAudio。針對串流設定，應用程式應使用 Java AudioTrack。不論是低延遲還是串流設定，HAL 輸出接收器都應接受 AUDIO_FORMAT_PCM_24_BIT、AUDIO_FORMAT_PCM_24_BIT_PACKED、AUDIO_FORMAT_PCM_32_BIT 或 AUDIO_FORMAT_PCM_FLOAT 做為目標輸出格式。
[5.6/H-1-4] 必須支援超過 4 個聲道的 USB 音訊裝置 (DJ 控制器會使用此裝置來試聽歌曲)。
[5.6/H-1-5] 必須支援符合類別規範的 MIDI 裝置，並宣告 MIDI 功能標記。
[5.7/H-1-2] 必須支援具備下列內容解密功能的 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL。

樣本大小下限	4 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.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.S，那麼：

必須符合 Android 12 CDD 第 2.2.7.2 節所列的相機要求。

如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：

[7.5/H-1-1] 「必須」使用主要後置鏡頭，解析度至少為 1,200 萬像素，且支援拍攝每秒 4k@30fps 影片。主要後置鏡頭是相機 ID 最低的後置鏡頭。
[7.5/H-1-2] 「必須」使用主要前置鏡頭，解析度至少 500 萬像素，且支援拍攝格式為 1080p@30fps 的影片。主要前置鏡頭是前置鏡頭，相機 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] 兩台主鏡頭在 1080p 解析度下，至少要有 1000 毫秒的 camera2 JPEG 擷取延遲時間 < 1000 毫秒，這是 CTS 鏡頭效能 Test 在 ITS 照明條件 (3000K) 下所測得的結果。
[7.5/H-1-6] 這兩台主鏡頭的啟動延遲時間 (開啟相機到第一個預覽影格) 必須小於 500 毫秒，而這是 CTS 鏡頭效能 Test 在 ITS 照明條件 (3000K) 下所測得的結果。
[7.5/H-1-8] 必須支援主要後置鏡頭的 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW 和 android.graphics.ImageFormat.RAW_SENSOR。
[7.5/H-1-9] 「必須」使用支援 720p 或 1080p 的後置主要鏡頭 @ 240fps。
[7.5/H-1-10] 如果超廣角 RGB 相機朝向相同方向，主要相機必須設定最小 ZOOM_RATIO < 1.0。
[7.5/H-1-11] 務必在主要相機上實作並行前置串流。
[7.5/H-1-12] 必須為主要後置鏡頭支援 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION。
[7.5/H-1-13] 如果有多個 RGB 後置鏡頭超過 1 個，則「必須」支援主要後置鏡頭的 LOGICAL_MULTI_CAMERA 功能。
[7.5/H-1-14] 必須同時支援主要前置和主要後置鏡頭的 STREAM_USE_CASE 功能。

2.2.7.3. 硬體

如果手持裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.S，那麼：

必須符合 Android 12 CDD 第 2.2.7.3 節所列的硬體需求。

如果手持裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：

[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.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.S，那麼：

必須符合 Android 12 CDD 第 2.2.7.4 節所列的效能要求。

如果手持裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：

[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 英尺使用者介面」) 的使用者觀看數位媒體、電影、遊戲、應用程式和/或電視直播內容的娛樂介面。

如果 Android 裝置的實作方式符合下列所有條件，就會歸類為電視：

已提供遠端控制顯示幕上轉譯使用者介面的機制，可由此機制距離使用者僅 10 英尺遠。
使用內嵌螢幕的對角線長度大於 24 吋，或是加入影片輸出連接埠，例如 VGA、HDMI、DisplayPort，或用於顯示螢幕的無線連接埠。

本節其餘部分的其他規定僅適用於 Android TV 裝置實作方式。

2.3.1. 硬體

電視裝置導入方式：

[7.2.2/T-0-1] 必須支援 D-Pad。
[7.2.3/T-0-1] 必須提供 Home 和 Back 功能。
[7.2.3/T-0-2] 必須將返回函式的正常和長按事件 (KEYCODE_BACK) 同時傳送至前景應用程式。
[7.2.6.1/T-0-1] 必須納入遊戲控制器的支援功能，並宣告 android.hardware.gamepad 功能標記。
[7.2.7/T] 應提供遠端控制項，讓使用者透過該控制項存取非觸控瀏覽和核心瀏覽鍵輸入內容。

如果電視裝置導入作業含有 3 軸式陀螺儀，則必須：

[7.3.4/T-1-1] 必須能夠以至少 100 Hz 的頻率回報事件。
[7.3.4/T-1-2] 必須能夠測量每秒高達 1000 度的方向變化。

電視裝置導入方式：

[7.4.3/T-0-1] 必須支援藍牙和藍牙 LE。
[7.6.1/T-0-1] 至少須有 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。

如果電視裝置實作包含支援主機模式的 USB 連接埠，就會：

[7.5.3/T-1-1]「必須」提供透過這個 USB 連接埠連接 (但不一定隨時連接) 的外部攝影機的支援。

如果電視裝置導入方式是 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 以上版本

請注意，上述的「核心和使用者空間可用的記憶體」是指除了已指定至無線電、影片等硬體元件的所有記憶體之外，不在核心在裝置實作上控管措施中的記憶體空間。

電視裝置導入方式：

[7.8.1/T] 必須配備麥克風。
[7.8.2/T-0-1] 必須具有音訊輸出並宣告 android.hardware.audio.output。

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/T-0-1] H.264
[5.2/T-0-2] VP8

電視裝置導入方式：

[5.2.2/T-SR-1] 強烈建議我們支援以每秒 30 個影格的速度，支援 720p 的 H.264 編碼和 1080p 解析度影片。

電視裝置實作「必須」支援下列影片解碼格式，並提供給第三方應用程式：

[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] 使用 Main10 級 5 級設定檔時，必須支援每秒 60 個影格的 UHD 解碼設定檔

電視裝置實作「必須」支援 VP8 解碼功能，如第 5.3.6 節所述，且會以標準影片影格速率和解析度，最高包括：

[5.3.6/T-1-1] HD 高畫質 1080p (每秒 60 影格) 解碼設定檔

採用 VP9 硬體解碼器的電視裝置實作「必須」支援 VP9 解碼功能，如第 5.3.7 節所述，其標準影片影格速率和解析度最高，包括：

[5.3.7/T-1-1] HD 高畫質 1080p，每秒 60 個影格，設定檔 0 (8 位元色彩深度)

如果電視裝置實作包含 VP9 硬體解碼器，可支援 VP9 解碼和 UHD 超高畫質設定檔：

[5.3.7/T-2-1] 必須支援每秒 60 個影格的 UHD 解碼設定檔，設定檔 0 (8 位元色彩深度)。
[5.3.7/T-SR1] 強烈建議在搭配設定檔 2 (10 位元色彩深度) 的情況下，以每秒 60 個影格的速度支援 UHD 解碼設定檔。

電視裝置導入方式：

[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] 必須支援第三方無障礙服務。
[3.10/T-SR-1] 強烈建議在裝置上預先載入無障礙服務，這些功能與切換控制功能和 TalkBack (適用於預先安裝的文字轉語音引擎) 無障礙服務 (適用於預先安裝的文字轉語音引擎) 無障礙服務 (如TalkBack 開放原始碼專案所提供的語言) 不相上下。

如果電視裝置實作項目回報 android.hardware.audio.output 功能，就會：

[3.11/T-SR-1] 強烈建議提供支援裝置可用語言的 TTS 引擎。
[3.11/T-1-1] 必須支援第三方 TTS 引擎的安裝作業。

電視裝置導入方式：

[3.12/T-0-1] 必須支援電視輸入架構。

2.3.4. 效能與功率

[8.1/T-0-1] 影格延遲時間一致。影格延遲時間或轉譯影格延遲「不得」在一秒內發生超過 5 個影格，且每秒不得超過 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 開放原始碼計畫包含的功能)，或擴充 Android 開放原始碼計畫包含的功能，請按照下列步驟操作：

[8.3/T-1-1] 「必須」提供使用者預設用途，才能啟用和停用省電模式功能。

如果電視裝置未安裝電池：

[8.3/T-1-2] 必須按照「支援無電池功能的裝置」所述，將裝置註冊為無電池裝置。

如果電視裝置導入的電池符合下列條件：

[8.3/T-1-3] 「必須」提供使用者空間，才能顯示不受應用程式待命和打盹省電模式限制的所有應用程式。

電視裝置導入方式：

[8.4/T-0-1] 必須為每個元件提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量」，以及元件隨時間而造成的電池耗電預估情形 (如 Android 開放原始碼計畫網站上所述)。
[8.4/T-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
[8.4/T-0-3] 必須根據每個程序的 UID 回報 CPU 耗電量。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 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，以滿足這項需求。
[9.11/T-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非產生至少 10 萬個指定 SKU 的單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰 MAY。
[9/T-0-1] 必須宣告「android.hardware.security.model.compatible」功能。

如果電視裝置支援安全的螢幕鎖定功能，便可：

[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 二進位檔「必須」接受做為輸入 protobuf 設定，且符合 Perfetto 說明文件中定義的結構定義。
- [6.1/T-0-3] Perfetto 二進位檔「必須」以輸出形式輸出 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
- [6.1/T-0-4] 請務必透過 Perfetto 二進位檔提供至少 Perfetto 說明文件中所述的資料來源。

2.4. 智慧手錶需求

Android Watch 裝置是指設計在身上 (如手腕上) 的 Android 裝置實作。

如果 Android 裝置的實作方式符合下列所有條件，就會歸類為 Watch：

螢幕的實際對角線長度必須介於 1.1 到 2.5 吋之間。
提供要戴在身上的機制。

本節其餘部分的其他規定僅適用於 Android Watch 裝置實作方式。

2.4.1. 硬體

手錶裝置實作：

[7.1.1.1/W-0-1] 螢幕的物理對角線大小必須介於 1.1 到 2.5 吋之間。
[7.2.3/W-0-1] 必須為使用者提供 Home 函式和返回函式，但位於 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 測量結果後立即回報，即使系統尚未回報 GPS/GNSS 計算出的位置也一樣。
[7.3.3/W-1-2] 必須回報 GNSS 虛擬範圍和虛擬範圍速率；判斷位置後，如果保持靜止或移動高度低於 0.2 公尺的每秒平方差，就足以在 20% 以內，每秒 0.2 公尺內計算速度至少為 20%，且每 0.2 公尺範圍內的速度至少為 0.2 公尺。

如果手錶裝置導入方式包含 3 軸式迴轉儀，代碼會：

[7.3.4/W-2-1] 必須能夠測量每秒高達 1000 度的螢幕方向變化。

手錶裝置實作：

[7.4.3/W-0-1] 必須支援藍牙。
[7.6.1/W-0-1] 至少要有 1 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/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] 「必須」使用意圖處理常式預先載入一或多個應用程式或服務元件，以供此處列出的應用程式意圖定義的所有公開意圖篩選器模式使用。

手錶裝置實作：

[3.8.4/W-SR-1] 強烈建議你在裝置上實作助理來處理輔助動作。

宣告 android.hardware.audio.output 功能旗標的裝置實作方式：

[3.10/W-1-1] 必須支援第三方無障礙服務。
[3.10/W-SR-1] 強烈建議在裝置上預先載入無障礙服務，這些功能與切換控制功能和 TalkBack (適用於預先安裝的文字轉語音引擎) 無障礙服務 (適用於預先安裝的文字轉語音引擎) 無障礙服務 (如TalkBack 開放原始碼專案所提供的語言) 不相上下。

如果手錶裝置實作回報 android.hardware.audio.output 功能，那麼：

[3.11/W-SR-1] 強烈建議提供支援裝置可用語言的 TTS 引擎。
[3.11/W-0-1] 必須支援第三方 TTS 引擎的安裝作業。

2.4.4. 效能與功率

如果手錶裝置實作具有改善裝置電源管理功能 (Android 開放原始碼計畫包含的功能)，或擴充 Android 開放原始碼計畫包含的功能，就會：

[8.3/W-SR-1] 強烈建議使用者提供充足空間，讓系統顯示不受應用程式待命和打盹省電模式豁免的應用程式。
[8.3/W-SR-2] 極力建議您為使用者提供啟用及停用省電功能的選項。

手錶裝置實作：

[8.4/W-0-1] 「必須」提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量」，以及元件隨時間而造成的電池耗電預估情形 (如 Android 開放原始碼計畫網站上所述)。
[8.4/W-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
[8.4/W-0-3] 必須根據每個程序的 UID 回報 CPU 耗電量。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 裝置的實作方式宣告了 android.hardware.type.automotive 功能或符合下列所有條件，就會歸類為 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] 「必須」提供主畫面函式和「返回」和「最近」功能。
[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 結合其他感應器，導致位置失效。如果「Location」(位置) 受損，極力建議實作及回報使用的相應感應器類型和/或車輛物業 ID。
[7.3/A-0-4] 透過 LocationManager#requestLocationUpdates() 要求的位置「不得」相符。
[7.3.1/A-0-4] 必須遵守 Android 車用感應器座標系統。
[7.3/A-SR-1] 「STRONGLY_RECOMMENDED」包括 3 軸式加速度計和 3 軸式迴轉儀。
[7.3/A-SR-2] STRONGLY_RECOMMENDED 實作 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 要求。使用接收器上計算的 GNSS 軌道預測功能，或使用最後已知車輛位置，並且能夠讓定位準確度達到至少 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] 強烈建議使用 SDCardFS，減少在外部儲存空間執行的作業 I/O 負擔。

如果 Automotive 裝置實作方式為 64 位元：

[7.6.1/A-2-1] 如果使用下列任一密度，核心和使用者空間可用的記憶體必須至少為 816 MB：
- 在小螢幕/一般螢幕上，280 dpi 以下
- 搭載超大型螢幕的 ldpi 或更低版本
- 大螢幕上的 mdpi 或更低
[7.6.1/A-2-2] 如果使用下列任一密度，核心和使用者空間可用的記憶體必須至少為 944 MB：
- 小螢幕/一般螢幕適用的 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 裝置實作項目「必須」支援下列影片編碼格式，並提供給第三方應用程式：

[5.2/A-0-1] H.264 AVC
[5.2/A-0-2] VP8

Automotive 裝置實作項目「必須」支援下列影片解碼格式，並提供給第三方應用程式：

[5.3/A-0-1] H.264 AVC
[5.3/A-0-2] MPEG-4 SP
[5.3/A-0-3] VP8
[5.3/A-0-4] VP9

強烈建議您實作 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.* 命名空間中的所有公用 API。

如果 Automotive 裝置實作項目使用 android.car.CarPropertyManager 搭配 android.car.VehiclePropertyIds 提供專屬 API，就會：

[3/A-1-1]「不得」將特殊權限附加至系統應用程式使用這些屬性，或要防止第三方應用程式使用這些屬性。
[3/A-1-2] 不得複製 SDK 中既有的車輛屬性。

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 的通知。
[3.8.4/A-SR-1] 強烈建議你在裝置上實作助理，以便處理「輔助動作」。

如果 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] 必須顯示 PLAY 和 MUTE，才能取代透過 Notification.Builder.addAction() 提供的通知動作
[3.8.3.1/A] 應限制使用複合式管理工作，例如個別通知管道的控制項。可依應用程式使用 UI 預設用途來減少控管。

如果 Automotive 裝置實作項目支援使用者 HAL 屬性，則：

[3.9.3/A-1-1] 「必須」導入所有使用者生命週期屬性
- INITIAL_USER_INFO，SWITCH_USER，CREATE_USER，REMOVE_USER。

Automotive 裝置實作：

[3.14/A-0-1] 必須包括 UI 架構，以支援使用媒體 API 的第三方應用程式，如 3.14 節所述。
[3.14/A-0-2] 必須允許使用者在行車期間安全地與媒體應用程式互動。
[3.14/A-0-3] 必須使用 CAR_EXTRA_MEDIA_PACKAGE 額外項目支援 CAR_INTENT_ACTION_MEDIA_TEMPLATE 隱含意圖動作。
[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] 顯示 MediaBrowser 階層時必須遵循 CONTENT_STYLE_BROWSABLE_HINT 和 CONTENT_STYLE_PLAYABLE_HINT 定義。

如果 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] 「必須」提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量」，以及元件隨時間而造成的電池耗電預估情形 (如 Android 開放原始碼計畫網站上所述)。
[8.4/A-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
[8.4/A-0-3] 必須根據每個程序的 UID 回報 CPU 耗電量。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] 當應用程式存取即時相機資料時，「必須」顯示攝影機指標，但如果只有具備 CDD ID [C-3-X] 所述角色的應用程式，才能存取相機，則不需要顯示相機指標。
[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 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，以滿足這項需求。
[9.11/A-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非產生至少 10 萬個指定 SKU 的單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰 MAY。
[9/A-0-1] 必須宣告「android.hardware.security.model.compatible」功能。

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 二進位檔「必須」接受做為輸入 protobuf 設定，且符合 Perfetto 說明文件中定義的結構定義。
- [6.1/A-0-3] Perfetto 二進位檔「必須」寫入為 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
- [6.1/A-0-4] 請務必透過 Perfetto 二進位檔提供至少 perfetto 說明文件中所述的資料來源。

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.2.3.1/Tab-0-1] 「必須」使用意圖處理常式預先載入一或多個應用程式或服務元件，才能載入此處列出的應用程式意圖篩選器模式。

3. 軟體

3.1. 代管 API 相容性

代管的 Dalvik 位元碼執行環境是 Android 應用程式的主要工具。Android 應用程式設計介面 (API) 是一組 Android 平台介面，會向在代管執行階段環境中執行的應用程式公開。

裝置實作方式：

[C-0-1] 必須針對 Android SDK 公開的任何 API 所記錄的 API，或是在上游 Android 原始碼中以「@SystemApi」標記裝飾的任何 API，提供完整的實作項目，包括所有記載的行為。
[C-0-2] 必須支援/保留所有 TestApi 註解 (@TestApi) 標示的類別、方法和相關元素。
[C-0-3] 除非這個相容性定義明確允許，否則「不得」省略任何代管 API、變更 API 介面或簽名、偏離記錄行為，或納入免人工管理。
[C-0-4] 即使 Android 中的部分硬體功能遭到省略，也「必須」繼續以合理的方式呈現 API 並運作行為。如要瞭解這個情境的特定需求，請參閱第 7 節。
[C-0-5] 不得允許第三方應用程式使用非 SDK 介面。非 SDK 介面定義為 Java 語言套件中的方法和欄位。這些介面是位於 Android 開放原始碼計畫啟動類別路徑中，且不屬於公開 SDK 的一部分。這包括用 @hide 註解裝飾，但不使用 @SystemAPI 的 API (如 SDK 文件以及私人與套件私人類別成員所述)。
[C-0-6] 每個非 SDK 介面都必須隨附於 Android 開放原始碼計畫中適當 API 級別分支版本的 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路徑中，佈建和拒絕清單標記所提供的每個非 SDK 介面。
[C-0-7] 必須支援已簽署的設定動態更新機制，以便使用 Android 開放原始碼計畫現有的公開金鑰，在任何 APK 中嵌入已簽署的設定，藉此從受限制的清單移除非 SDK 介面。

但請注意下列事項：
- 如果缺少隱藏的 API，或在實作的裝置上採用不同實作方式，請將隱藏的 API 移至拒絕清單，或是從所有受限清單中省略。
- 如果 Android 開放原始碼計畫中沒有隱藏的 API，請將隱藏的 API 加入任何受限清單中。

3.1.1. Android 擴充功能

Android 支援透過更新該 API 級別的擴充功能版本，來擴充特定 API 級別的代管 API 介面。如果該 API 級別有擴充功能，android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API 會傳回所提供 apiLevel 的擴充功能版本。

Android 裝置實作：

[C-0-1] 必須預先載入共用程式庫 ExtShared 和服務 ExtServices 的 Android 開放原始碼計畫實作項目，且版本必須大於或等於每個 API 級別的最低版本。舉例來說，針對 Android 7.0 裝置實作項目，搭載 API 級別 24 的裝置「必須」包含至少 1 版。
[C-0-2] 「必須」只傳回 Android 開放原始碼計畫定義的有效擴充功能版本號碼。
[C-0-3] 必須依照第 3.1 節的規定，支援 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) 傳回擴充功能版本定義的所有 API，方法與其他代管 API 相同。

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. 權限

[C-0-1] 裝置實作者「必須」支援及強制執行「權限參考資料」頁面所述的所有權限常數。請注意，第 9 節列出了與 Android 安全性模型相關的其他規定。

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 整數值。
版本	裝置實作人員選擇的值，以人類可讀的格式指定目前執行 Android 系統的特定版本。使用者可用的不同版本「不得」重複使用這個值。這個欄位的常見用途是指出用於產生建構作業的版本號碼或原始碼控制變更 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_-]+$」。在產品生命週期內，這個裝置名稱「不得」變更。
指紋	專門用於識別此版本的字串。產品必須清晰可讀。請務必遵循以下範本： $(BRAND)/$(PRODUCT)/ $(裝置):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 舉例來說： acme/myproduct/ mydevice:13/LMYXX/3359:userdebug/test-keys 指紋「不得」包含空白字元。這個欄位的值必須能以 7 位元 ASCII 編碼。
硬體	硬體的名稱 (從核心指令列或 /proc)。此 ID 必須清晰可讀。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
主機	用於識別建構建構所在主機的專屬字串，並且採用人類可讀的格式。這個欄位的具體格式沒有規定，但「不得」為空值或空字串 (")。
ID	裝置實作者選擇的 ID，用於參照特定版本，並且採用人類可讀的格式。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但值應足以讓使用者區分不同軟體版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
製造商	產品的原始設備製造商 (OEM) 商號。這個欄位的具體格式沒有規定，但欄位不得為空值或空白字串 (「」)。在產品的生命週期中，這個欄位「不得」變更。
SOC_MANUFACTURER	產品中主要系統上主要系統 (SOC) 的製造商名稱。具有相同 SOC 製造商的裝置應使用相同的常數值。請洽詢 SOC 製造商，取得要使用的正確常數。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且必須符合規則運算式「^([0-9A-Za-z ]+)」、「開頭或結尾不得為空白字元，且不得等於「不明」。在產品生命週期內，這個欄位「不得」變更。
SOC_MODEL	產品中使用的晶片 (SOC) 上主要系統的模型名稱。採用相同 SOC 模型的裝置應使用相同的常數值。請洽詢 SOC 製造商，取得要使用的正確常數。這個欄位的值「必須」能以 7 位元 ASCII 編碼為 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 和 Test-keys。
時間	代表建構發生時間的時間戳記的值。
類型	裝置實作者選擇的值，用於指定版本的執行階段設定。這個欄位「必須」含有與以下三種一般 Android 執行階段設定的對應值：user、userdebug 或 eng。
使用者	產生版本的使用者 (或自動化使用者) 名稱或使用者 ID。這個欄位的具體格式沒有規定，但「不得」為空值或空字串 (")。
安全快門	表示版本安全性修補程式等級的值。「必須」表示該版本沒有任何安全漏洞，可影響到指定 Android 公開安全性公告所述的任何問題。請採用 [YYYY-MM-DD] 的格式，與 Android 公開安全性公告或 Android 安全性補充公告中所記錄的字串相符，例如「2015-11-01」。
BASE_OS	這個值代表版本的 FINGERPRINT 參數，與此版本相同 (Android 公開安全性公告提供的修補程式除外)。它必須回報正確的值，如果這類版本不存在，請回報空字串 (")。
新手上路	裝置實作者選擇的值，以人類可讀的格式，識別裝置中使用的特定內部系統啟動載入程式版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
getRadioVersion()	必須 (也就是或傳回) 由裝置實作人員選擇的值，用來識別裝置中使用的特定內部無線電/模組版本，並且採用人類可讀的格式。如果裝置沒有任何內部無線電/模組，就「必須」傳回 NULL。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。
getSerial()	「必須」是 (發行或歸還) 一組硬體序號，該序號必須存在於使用相同型號和 MANUFACTURER 的所有裝置上，而且不得重複。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9]+$」。

3.2.3. 意圖相容性

3.2.3.1。常見的應用程式意圖

Android 意圖可讓應用程式元件要求其他 Android 元件的功能。Android 上游專案內有一份應用程式清單，這些應用程式可以實作多個意圖模式來執行常用動作。

裝置實作方式：

[C-SR-1] 強烈建議使用意圖處理常式預先載入一或多個應用程式或服務元件，以使用這裡列出的下列應用程式意圖定義的所有公開意圖篩選器模式，並提供執行要求，也就是符合 SDK 中所述常見應用程式意圖的開發人員期望。

請參閱第 2 節，瞭解每種裝置類型的強制應用程式意圖。

3.2.3.2。意圖解決方案

[C-0-1] 由於 Android 是可擴充平台，因此裝置實作「必須」允許第 3.2.3.1 節中參照的各個意圖模式 (設定除外) 遭到第三方應用程式覆寫。根據預設，上游 Android 開放原始碼實作允許執行這項操作。
[C-0-2] 裝置實作者「不得」將特殊權限附加至系統應用程式使用這些意圖模式，或避免第三方應用程式繫結和假設這些模式。這項禁用行為包括但不限於停用「選擇工具」使用者介面，讓使用者選擇多個使用相同意圖模式的應用程式。
[C-0-3] 裝置實作「必須」提供使用者介面，讓使用者修改意圖的預設活動。
不過，當預設活動為資料 URI 提供更具體的屬性時，裝置實作項目「可以」針對特定 URI 模式提供預設活動 (例如 http://play.google.com)。例如，指定資料 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 意圖篩選器只能通過驗證，裝置實作「必須」能夠為使用者提供查看及覆寫特定候選 URI 意圖篩選器的功能。

3.2.3.3. 意圖命名空間

[C-0-1] 裝置實作「不得」包含任何 Android 元件，用於支持任何在 android.* 或 com.android.* 命名空間中使用 ACTION、CATEGORY 或其他金鑰字串的新意圖或廣播意圖模式。
[C-0-2] 裝置實作者「不得」包含任何在屬於其他機構的套件空間中，使用 ACTION、CATEGORY 或其他金鑰字串的新意圖或廣播意圖模式的 Android 元件。
[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 提供的設定可讓使用者輕鬆選取預設應用程式，例如主畫面或簡訊。

在可行的情況下，裝置實作「必須」提供類似的設定選單，且與以下 SDK 說明文件中所述的意圖篩選器模式和 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 意圖，為使用者提供設定與 PhoneAccounts 相關聯的 ConnectionServices，以及電信服務供應商用來撥打電話的預設 PhoneAccount。Android 開放原始碼計畫實作項目符合這項規定，只要在「Calls」設定選單中加入「Calling Account」選項選單即可。
[C-2-4] 必須允許擁有 android.app.role.CALL_REDIRECTION 角色的應用程式使用 android.telecom.CallRedirectionService。
[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 提供可處理這些意圖的預載撥號應用程式。

如果裝置導入作業回報 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 意圖，提供使用者可存取的機制，以在預先載入的無障礙服務旁啟用及停用第三方無障礙服務。

如果裝置實作項目支援 Wi-Fi Easy Connect 支援，並向第三方應用程式公開相關功能，他們必須：

[C-9-1] 必須按照 SDK 說明文件所述，實作 Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI 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 這裡所述的意圖，為這些意圖提供執行要求。

如果裝置實作程序宣告了 android.software.autofill 功能旗標，就會：

[C-14-1] 必須完全實作 AutofillService 和 AutofillManager API，並遵循 android.settings.REQUEST_SET_AUTOFILL_SERVICE 意圖，顯示預設的應用程式設定選單，藉此啟用及停用自動填入功能，以及變更使用者的預設自動填入服務。

如果裝置實作項目包含預先安裝的應用程式，或想允許第三方應用程式存取使用統計資料，可以採取下列做法：

[C-SR-2] 是我們極力建議的做法，為使用者提供可存取的機制，針對宣告 android.permission.PACKAGE_USAGE_STATS 權限的應用程式，針對 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，授予或撤銷使用統計資料的存取權。

如果裝置實作方式想禁止任何應用程式 (包括預先安裝的應用程式) 存取使用統計資料，將執行以下操作：

[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] 保證 API 相容性必須與在主要螢幕上執行的活動類似。
[C-1-3] 在新活動啟動時，必須透過 ActivityOptions.setLaunchDisplayId() API 指定目標顯示畫面，使新活動顯示在啟動活動所在的螢幕上。
[C-1-4] 只有在移除具有 Display.FLAG_PRIVATE 標記的螢幕時，請務必刪除所有活動。
[C-1-5] 除非應用程式使用 Activity#setShowWhenLocked() 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] 強烈建議使用上游 Android 開放原始碼專案中的下列程式庫實作項目。

3.3.1. 應用程式二進位檔介面

代管的 Dalvik 位元碼可呼叫應用程式 .apk 檔案中提供的原生程式碼，做為針對適當裝置硬體架構編譯的 ELF .so 檔案。由於原生程式碼高度依賴基礎處理器技術，因此 Android 會在 Android NDK 中定義多個應用程式二進位檔介面 (ABI)。

裝置實作方式：

[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、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 參數，準確回報裝置支援的原生應用程式二進位檔介面 (ABI)，每個 ABI 的逗號分隔清單，每個 ABI 按順序由高到低排列。
[C-0-6] 請務必透過上述參數，回報下列 ABI 清單中的子集，且不得回報不在清單上的 ABI。
- armeabi (NDK 不再支援做為目標)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] 所有含有原生程式碼的應用程式都必須提供下列所有程式庫，並提供原生 API：
- libaaudio.so (支援 AAudio 原生音訊)
- libamidi.so (原生 MIDI，如第 5.9 節所述功能使用 android.software.midi 功能，則可支援)
- 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] 必須列出 /vendor/etc/public.libraries.txt 中直接向第三方應用程式公開的其他非 Android 開放原始碼計畫程式庫。
[C-0-10] 請勿向指定 API 級別 24 以上級別的第三方應用程式，在 Android 開放原始碼計畫中實作並提供任何其他原生程式庫，做為系統程式庫。
[C-0-11] 「必須」透過 libGLESv3.so 程式庫匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android Extension Pack 函式符號。請注意，雖然所有符號必須都存在，但第 7.1.4.1 節將進一步說明預期各項對應函式完整實作的條件規定。
[C-0-12] 必須從 libvulkan.so 程式庫匯出核心 Vulkan 1.0 函式符號，以及 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 擴充功能的函式符號。請注意，雖然所有符號都必須完整顯示，但第 7.1.4.2 節將進一步說明預期各項對應函式完整實作時的相關規定。
應使用上游 Android 開放原始碼計畫中可用的原始碼和標頭檔案建構

請注意，日後推出的 Android 版本可能會支援更多 ABI。

3.3.2. 32 位元 ARM 原生程式碼相容性

如果裝置實作回報支援 armeabi ABI，就會：

[C-3-1] 也必須支援 armeabi-v7a 並回報支援，因為 armeabi 只適用於舊版應用程式。

如果裝置實作回報使用此 ABI 的應用程式支援 armeabi-v7a ABI，則會：

[C-2-1] 必須在 /proc/cpuinfo 中加入下列幾行，且不應修改同一部裝置上的值，即使其他 ABI 讀取這些值也一樣。
- Features:，後面加上裝置支援的任何選用 ARMv7 CPU 功能清單。
- CPU architecture:，後面加上整數，說明裝置支援的最高 ARM 架構 (例如「8」代表 ARMv8 裝置)。
[C-2-2] 必須隨時保持下列作業狀態，即使是透過原生 CPU 支援或透過軟體模擬在 ARMv8 架構中實作 ABI 也一樣：
- 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] 在 Android 13 分支版本上實作 android.webkit.WebView API 時，「必須」使用來自上游 Android 開放原始碼專案的 Chromium 專案版本。
[C-1-3] WebView 回報的使用者代理程式字串必須使用以下格式：

Mozilla/5.0 (Linux；Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/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) 字串的值「必須」是上游 Android 開放原始碼專案中的 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 相關聯的 API：
[C-1-2] 必須支援 HTML5/W3C webstorage API，且必須支援 HTML5/W3C IndexedDB API。請注意，隨著網頁開發標準機構逐漸改用 IndexedDB，而非 Web Storage，我們希望日後的 Android 版本將 IndexedDB 成為必要的元件。
可以在獨立的瀏覽器應用程式中提供自訂的使用者代理程式字串。
無論是以上游 WebKit 瀏覽器應用程式，還是第三方替代服務，都應盡可能在獨立的瀏覽器應用程式中導入 HTML5 的支援。

不過，如果裝置實作項目不包含獨立的瀏覽器應用程式，就會：

[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] 這些 API 必須限制透過 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-11] 除非應用程式透過 insertProviderAt() 或 removeProvider() 修改清單，否則裝置「必須」依指定順序，將下列安全性提供者傳回 Security.getProviders() 方法中的前七個陣列值，並使用指定名稱 (由 Provider.getName() 傳回) 和類別。裝置「可」在以下指定供應商清單後傳回其他供應商。
1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL：com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider - sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. 英屬哥倫比亞 - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

上方清單僅列舉部分例子，並未包含所有可能情況。Compatibility Test Suite (CTS) 會測試平台上的重要部分，確認是否的行為相容性。實作者必須負責確保與 Android 開放原始碼計畫的行為相容性。因此，裝置實作人員應盡可能使用透過 Android 開放原始碼計畫取得的原始碼，而非重新實作系統的重要部分。

3.5.1。應用程式限制

如果裝置實作項目採用專屬機制來限制應用程式 (例如變更或限制 SDK 中描述的 API 行為)，且這個機制的限制比受限應用程式待命值區嚴格，則：

[C-1-1] 必須允許使用者查看受限制的應用程式清單。
[C-1-2] 「必須」提供使用者預設負擔，才能為每個應用程式開啟 / 關閉所有專屬限制。
[C-1-3] 除非系統健康狀態不良，否則不得自動套用這些專屬限制，但「可能」會對應用程式套用限制，以偵測應用程式是否出現不良系統的健康狀態，例如 Wake Lock 停滯、長時間執行的服務和其他條件。這些標準可能是由裝置實作者決定，但必須與應用程式對系統健康狀態的影響相關。與系統健康狀態無關的其他條件 (例如應用程式市場熱門程度偏低) 不得做為評估標準。
[C-1-4] 當使用者手動停用應用程式限制時，「不得」自動為應用程式套用這些專屬限制，且建議使用者套用這些專屬限制。
[C-1-5] 如果應用程式自動套用這些專屬限制，請務必告知使用者。「必須」在套用這些專屬限制之前的 24 小時內提供這類資訊。
[C-1-6] 對於從應用程式發出的任何 API 呼叫，都必須針對 ActivityManager.isBackgroundRestricted() 方法傳回 true。
[C-1-7] 「不得」限制使用者明確使用的頂層前景應用程式。
[C-1-8] 每當使用者開始明確使用應用程式時，必須將應用程式設為頂層前景應用程式，這些專屬限制都必須暫停。
[C-1-10] 必須提供公開且明確的文件或網站，說明專屬限制的適用情形。這份文件或網站「必須」可以從 Android SDK 文件連結，且必須包含：
- 專屬限制的觸發條件。
- 應用程式的限制和限制方式。
- 如何讓應用程式不受這類限制限制。
- 如果應用程式支援使用者可安裝的應用程式豁免資格，可要求免除專屬限制的豁免。

如果應用程式已預先安裝在裝置上，且使用者從未明確使用超過 30 天，[C-1-3] [C-1-5] 不受此限制。

如果裝置實作項目會延長 Android 開放原始碼計畫實作的應用程式限制，就會：

[C-2-1]必須按照這份文件所述的導入作業進行。

3.5.2。應用程式休眠

如果裝置實作項目包括 Android 開放原始碼計畫中的應用程式休眠，或擴充 Android 開放原始碼計畫中的功能，那麼：

[C-1-1] 必須符合第 3.5.1 節中的所有規定，但 [C-1-6] 和 [C-1-3] 除外。
[C-1-2] 只有在可證明使用者已有一段時間未使用應用程式時，才能對使用者套用應用程式限制。極力建議將時間長度設為一個月以上。「必須」定義使用情形，包括使用者透過 UsageStats#getLastTimeVisible() API 明確互動的方式，或是可能導致應用程式結束強制停止狀態的任何行為，包括服務繫結、內容供應器繫結、明確廣播等，而新 API UsageStats#getLastTimeAnyUsed()
[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] 「不得」在上述命名空間的 API 中加入任何公開的元素 (例如類別、介面、欄位或方法)，或是測試或系統 API。「公開公開的元素」是指任何未以「@hide」標記裝飾的結構，就像上游 Android 原始碼中使用的一樣。

裝置實作者可能會修改 API 的基礎實作方式，但這類修改內容如下：

[C-0-3] 「不得」影響任何公開 API 所述行為和 Java 語言簽名。
[C-0-4] 不得宣傳或向開發人員揭露。

不過，裝置實作者可能會在標準 Android 命名空間之外新增自訂 API，但自訂 API：

[C-0-5] 不得位於其他機構擁有或參照的命名空間。舉例來說，裝置實作者「不得」將 API 新增至 com.google.* 或類似的命名空間，只有 Google 可以這麼做。同樣地，Google 也「不得」將 API 新增至其他公司的命名空間。
[C-0-6] 必須封裝在 Android 共用資料庫中，因此只有明確使用這類 API 的應用程式 (透過 <uses-library> 機制) 會受到這類 API 的記憶體用量增加的影響。

裝置實作者可能會新增原生語言 (NDK API 除外) 的自訂 API，但自訂 API：

[C-1-1] 「不得」位於 NDK 程式庫或由其他機構擁有的程式庫中，如這裡所述。

如果裝置實作人員建議改善上述其中一個套件命名空間 (例如為現有的 API 新增實用的新功能，或是新增 API)，實作者應前往 source.android.com，並根據該網站的資訊開始進行變更和程式碼。

請注意，上述限制符合 Java 程式設計語言中對 API 命名的標準慣例；本節目的只是要加強這些慣例，並透過納入這個相容性定義進行繫結。

3.7. 執行階段相容性

裝置實作方式：

[C-0-1] 必須支援完整的 Dalvik Executable (DEX) 格式和 Dalvik 位元碼規格和語意。
[C-0-2] 必須設定 Dalvik 執行階段，以便依照上游 Android 平台配置記憶體，如下表所指定。(如要瞭解螢幕大小和螢幕密度定義，請參閱第 7.1.1 節)。
應使用 Android RunTime (ART)、Dalvik 執行格式的參考上游實作，以及參考實作的套件管理系統。
應在各種執行模式和目標架構下執行模糊測試，以確保執行階段的穩定性。請參閱 Android 開放原始碼專案網站的 JFuzz 和 DexFuzz。

請注意，下列指定的記憶體值視為最小值，而裝置實作可能會為個別應用程式配置更多記憶體。

螢幕版面配置	螢幕密度	應用程式記憶體下限
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)	48MB
	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)	80MB
	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)	48MB
	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)	80MB
	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] 當第三方應用程式使用 <adaptive-icon> 標記提供圖示時，「必須」傳回 AdaptiveIconDrawable 物件，而系統會呼叫擷取圖示的 PackageManager 方法。

如果裝置實作項目包含支援應用程式內捷徑固定的預設啟動器，就會執行以下動作：

[C-2-1] 必須回報 ShortcutManager.isRequestPinShortcutSupported() 的 true。
[C-2-2] 必須先要求使用者授予權限，才能透過 ShortcutManager.requestPinShortcut() API 方法新增應用程式要求的捷徑。
[C-2-3] 必須支援固定捷徑，以及動態和靜態捷徑，如「應用程式捷徑」頁面所述。

相反地，如果裝置的實作不支援應用程式內捷徑固定功能，則可用來：

[C-3-1] 必須回報 ShortcutManager.isRequestPinShortcutSupported() 的 false。

如果裝置實作項目實作預設啟動器，方便快速存取第三方應用程式透過 ShortcutManager API 提供的其他捷徑，這項功能會執行以下動作：

[C-4-1] 必須支援所有記載的捷徑功能 (例如靜態和動態捷徑、固定捷徑)，並完整實作 ShortcutManager API 類別的 API。

如果裝置實作項目包含預設啟動器應用程式，會顯示應用程式圖示的標記，那麼應用程式圖示會：

[C-5-1] 必須遵循 NotificationChannel.setShowBadge() API 方法。換句話說，如果值設為 true，應顯示與應用程式圖示相關的視覺預設用途；當應用程式的所有通知管道都將值設為 false 時，不會顯示任何應用程式圖示徽章配置。
如果第三方應用程式表明支援使用專屬 API 提供的專屬徽章配置，但應使用透過 SDK 中說明的通知徽章 API (例如 Notification.Builder.setNumber() 和 Notification.Builder.setBadgeIconType() API) 提供的資源和值，都可以覆寫應用程式圖示徽章。

如果裝置實作支援單色圖示，系統會提供以下圖示：

[C-6-1] 只有在使用者明確啟用時 (例如透過「設定」或「桌布挑選器」選單) 才能使用。

3.8.2。小工具

Android 支援第三方應用程式小工具，方法是定義元件類型以及對應的 API 和生命週期，可讓應用程式向使用者公開「AppWidget」。

如果裝置導入方式支援第三方應用程式小工具，就會：

[C-1-1] 必須宣告支援平台功能 android.software.app_widgets。
[C-1-2] 必須納入 AppWidgets 的內建支援，並公開使用者介面預設用途，以便新增、設定、查看及移除 AppWidgets。
[C-1-3] 必須能夠顯示標準格線大小 4 x 4 的小工具。詳情請參閱 Android SDK 說明文件中的「應用程式小工具設計指南」。
可能支援螢幕鎖定畫面上的應用程式小工具。

如果裝置實作支援第三方應用程式小工具和應用程式內捷徑固定功能，設定就會：

[C-2-1] 必須回報 AppWidgetManager.html.isRequestPinAppWidgetSupported() 的 true。
[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] 必須提供 SDK 中記錄的 NotificationChannel API 完整行為。
[C-1-5] 「必須」提供使用者負擔，讓他們在每個管道和應用程式套件層級封鎖及修改特定第三方應用程式的通知。
[C-1-6] 也必須讓使用者負擔能顯示已刪除的通知管道。
[C-1-7] 必須正確轉譯透過 Notification.MessagingStyle 提供的所有資源 (圖片、貼圖、圖示等)，以及與通知文字相關的使用者。舉例來說，在透過 setGroupConversation 設定的群組對話中，「必須」顯示所有資源，包括透過 android.app.Person 提供的圖示。
[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] 必須依照 SDK 中所述，在不需使用者進行其他互動的情況下，將透過 Notification.Builder.addAction() 提供的操作與通知內容一併顯示。

3.8.3.2。通知接聽器服務

Android 包含 NotificationListenerService API，可讓應用程式 (使用者明確啟用後) 在發布或更新時接收所有通知的副本。

裝置實作方式：

[C-0-1] 必須針對所有已安裝及使用者啟用的事件監聽器服務，正確並立即更新通知，包括附加至通知物件的任何及所有中繼資料。
[C-0-2] 必須遵循 snoozeNotification() API 呼叫，並關閉通知，並在延後時間 (在 API 呼叫中設定的延後時間長度) 執行回呼。

如果裝置的實作具有使用者負擔延後通知的權限，就會執行以下動作：

[C-1-1] 必須透過標準 API (例如 NotificationListenerService.getSnoozedNotifications()) 正確反映延後通知的狀態。
[C-1-2] 「必須」為這個使用者預設負擔權限，才能暫停來自每個已安裝第三方應用程式的通知，除非應用程式是永久/前景服務。

3.8.3.3。DND (請勿打擾)/ 優先模式

如果裝置實作支援 DND 功能 (也稱為優先模式)，就會執行以下動作：

[C-1-1] 當裝置實作提供讓使用者授予或拒絕第三方應用程式存取 DND 政策設定的方法時，必須一併顯示應用程式建立的自動 DND 規則，以及使用者建立及預先定義的規則。
[C-1-3] 必須遵循 NotificationManager.Policy 傳遞的 suppressedVisualEffects 值，如果應用程式已設定任何 SUPPRESSED_effective_SCREEN_OFF 或 SUPPRESSED_effective_SCREEN_ON 標記，則「必須」向使用者說明在 DND 設定選單中隱藏視覺效果。

3.8.4。Assist API

Android 包含 Assist 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 的快訊視窗。Android 開放原始碼計畫實作項目必須在通知欄中提供控制項，以符合這項規定。
[C-1-2] 必須遵循 Toast API，並以高度可見的方式向使用者顯示應用程式浮動式訊息。

3.8.6。主題

Android 提供「主題」機制，讓應用程式能在整個活動或應用程式中套用樣式。

Android 提供「Holo」和「Material」主題系列做為一組定義的樣式，可讓應用程式開發人員在希望符合 Android SDK 定義的 Holo 主題外觀和風格時使用。

如果裝置實作項目包含畫面或影片輸出內容，就會發生以下情形：

[C-1-1] 不得變更向應用程式公開的任何 Holo 主題屬性。
[C-1-2] 必須支援「Material」主題系列，且不得變更任何質感設計主題屬性或向應用程式公開的資產。
[C-1-3] 「必須」針對 Roboto 支援的語言，將「sans-Serif」字型系列設為 Roboto 2.x 版，或讓使用者自由將用於「sans-Serif」字型系列的字型變更為 Roboto 2.x 版。
[C-1-4] 必須產生 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。

「Source color」用於與 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)，

[C-1-2] 必須在「設定」的「位置」選單中顯示位置的目前狀態。
[C-1-3]「不得」在「設定」的「位置」選單中顯示定位模式。

3.8.13。萬國碼 (Unicode) 和字型

Android 支援 Unicode 10.0 中定義的表情符號字元。

如果裝置實作項目包含畫面或影片輸出內容，就會發生以下情形：

[C-1-1] 必須能夠以色彩字符轉譯這些表情符號字元。
[C-1-2] 必須支援下列項目：
- 使用不同粗細的 Roboto 2 字型：sans-Serif-thin、Sans-Serif-light、sans-Ser-Serif-medium、Sans-Serif-black、Sans-Serif-condensed、sans-Serif-condensed-light 適用於裝置可用的語言。
- 完整 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]「只有」指定含有指令碼碼 Qaag 的語言代碼 (例如 my-Qag) 時，才要轉譯文字並使用不符合萬國碼 (Unicode) 規定的字型。其他 ISO 語言或區碼 (無論是否指派、未指派或保留) 都可用來參照緬甸的不符合萬國碼 (Unicode) 字型。應用程式開發人員和網頁作者可以將 my-Qag 指定為指定語言代碼，就像其他語言版本一樣。

3.8.14。多視窗模式

如果裝置實作具有同時顯示多個活動的功能，就會：

[C-1-1] 必須根據 Android SDK 多視窗模式支援說明文件中所述的應用程式行為和 API，實作這類多視窗模式，並且符合下列規定：
[C-1-2] 必須遵循此 SDK 中所述，在 AndroidManifest.xml 檔案中為應用程式設定的 android:resizeableActivity。
[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] 必須按照目前 PIP 活動透過 setActions() API，在其 SystemUI 中顯示動作。
[C-3-3] 必須支援 PIP 活動透過 setAspectRatio() API 指定，且大於或等於 1:2.39 且小於或等於 2.39:1 的顯示比例。
[C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如未實作子母畫面模式，該金鑰就「必須」可用於前景活動。
[C-3-5] 「必須」為使用者提供授權，禁止應用程式在子母畫面模式下顯示。Android 開放原始碼計畫實作項目可在通知欄中提供控制項，以符合這項規定。
[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。

3.8.15。螢幕去背

如同 SDK 文件所述，Android 支援螢幕凹口。DisplayCutout API 定義的畫面邊緣區域，在邊緣顯示螢幕凹口或曲線顯示時，可能不適用於應用程式。

如果裝置的實作方式包含螢幕凹口，會發生以下情況：

[C-1-5] 如果裝置的顯示比例為 1.0(1:1)，「不得」包含凹口。
[C-1-2] 每邊只能有一個凹口。
[C-1-3] 必須遵循 SDK 中所述的 WindowManager.LayoutParams API，依應用程式設定的螢幕凹口標記。
[C-1-4] 必須針對 DisplayCutout API 中定義的所有凹口指標回報正確的值。

3.8.16。裝置控制

Android 提供 ControlsProviderService 和 Control API，可讓第三方應用程式發布裝置控制項，以便快速為使用者設定狀態並完成動作。

如要瞭解裝置專屬的需求，請參閱 2_2_3 節。

3.8.17。剪貼簿

裝置實作方式：

[C-0-1] 未經使用者明確採取動作 (例如按下疊加畫面上的按鈕)，「C-0-1」不得將剪貼簿資料傳送至任何元件、活動、服務或跨任何網路連線，但「9.8.6 內容擷取和應用程式搜尋」中提及的服務則不在此限。

如果內容針對 ClipData.getDescription().getExtras() 包含 android.content.extra.IS_SENSITIVE 的任何 ClipData 項目複製到剪貼簿時，裝置實作會產生使用者可見的預覽：

[C-1-1] 必須遮蓋使用者可見的預覽畫面

Android 開放原始碼計畫參考資料實作項目符合這些剪貼簿規定。

3.9. 裝置管理

Android 提供的功能可讓安全感知應用程式透過 Android Device 管理 API 在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端清除。

如果裝置實作實作 Android SDK 說明文件中定義的完整裝置管理政策，就會執行以下動作：

[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 記錄的 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-7] 不得再註冊任何 DPC 應用程式，做為裝置擁有者應用程式。
[C-1-2] 「必須」顯示適當的揭露通知 (例如 Android 開放原始碼計畫參照)，並在將應用程式設為「裝置擁有者」前取得使用者的確認同意，除非裝置是在畫面、使用者互動前，以程式輔助方式設定零售展示模式。

如果裝置實作宣告為 android.software.device_admin，但也包含專屬裝置管理解決方案，並提供相關機制，讓解決方案根據標準 Android DevicePolicyManager API 認可的標準「裝置擁有者」，將自家解決方案中設定的應用程式推送為「等號裝置擁有者」：

[C-2-1] 必須設有程序來驗證所宣傳的應用程式屬於合法的企業裝置管理解決方案，並已在專屬解決方案中設定，擁有等同於「裝置擁有者」的權限。
[C-2-2] 在註冊 DPC 應用程式為「裝置擁有者」之前，必須顯示相同的 Android 開放原始碼計畫裝置擁有者同意聲明揭露聲明，與 android.app.action.PROVISION_MANAGED_DEVICE 發起的流程相同。
[C-2-3] 不得以硬式編碼的方式修改同意聲明狀態，或禁止使用者使用其他裝置擁有者的應用程式。

3.9.1.2 受管理設定檔佈建

如果裝置實作項目宣告 android.software.managed_users，就會：

[C-1-1] 必須實作 API，讓裝置政策控制器 (DPC) 應用程式成為新受管理設定檔的擁有者。
[C-1-2] 代管設定檔佈建程序 (DPC 使用 android.app.action.PROVISION_MANAGED_PROFILE 或平台發起的流程)、同意畫面和使用者體驗，「必須」符合 Android 開放原始碼計畫實作項目。
[C-1-3] 「設定」中必須提供下列使用者權限，以便在裝置政策控制器 (DPC) 停用特定系統功能時向使用者顯示：
- 當裝置管理員限制特定設定時，顯示一致的圖示或使用者預設用途 (例如上游 Android 開放原始碼計畫資訊圖示)。
- 裝置管理員透過 setShortSupportMessage 提供的簡短說明訊息。
- DPC 應用程式圖示。
[C-1-4] 如果在 android.app.action.PROVISION_MANAGED_PROFILE 意圖啟動佈建作業時建立了設定檔擁有者，且 DPC 已實作處理常式，則「必須」在工作資料夾中啟動 ACTION_PROVISIONING_SUCCESSFUL 意圖的處理常式。
[C-1-5] 當 android.app.action.PROVISION_MANAGED_PROFILE 意圖啟動佈建作業時，必須傳送 ACTION_PROFILE_PROVISIONING_COMPLETE 廣播至工作資料夾 DPC。
[C-1-6] 觸發設定檔擁有者佈建作業後，請務必傳送 ACTION_GET_PROVISIONING_MODE 意圖，讓 DPC 應用程式可以選擇要成為裝置擁有者或設定檔擁有者，除非佈建是由意圖 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 API 受管理的設定檔。
[C-1-2] 只能建立一個受管理的設定檔。
[C-1-3] 必須使用圖示徽章 (類似 Android 開放原始碼計畫上游工作徽章) 來代表受管理的應用程式、小工具，以及其他標記的 UI 元素，例如「最近使用與通知」。
[C-1-4] 必須顯示通知圖示 (類似 Android 開放原始碼計畫上游工作徽章)，表示使用者是在受管理的設定檔應用程式中。
[C-1-5] 必須顯示浮動式訊息，指出裝置喚醒及喚醒裝置 (ACTION_USER_PRESENT) 且前景應用程式位於受管理的設定檔內，表示使用者已位於受管理的設定檔中。
[C-1-6] 如果有受管理的設定檔，「必須」在意圖的「選擇工具」中顯示視覺預設用途，讓使用者可以將受管理設定檔的意圖轉送給主要使用者，反之亦然 (如果裝置政策控制器已啟用)。
[C-1-7] 如果有受管理的設定檔，「必須」針對主要使用者和受管理的設定檔公開下列使用者權限：
- 將主要使用者和受管理設定檔的電池、位置、行動數據和儲存空間用量分開計算。
- 獨立管理安裝在主要使用者或代管設定檔中的 VPN 應用程式。
- 獨立管理主要使用者或代管設定檔中安裝的應用程式。
- 獨立管理主要使用者或受管理設定檔中的帳戶。
[C-1-8] 如果裝置政策控制器允許，「必須」確保預先安裝的撥號程式、聯絡人和訊息應用程式能夠在受管理的設定檔 (如果有的話) 中搜尋及查詢呼叫端資訊。
[C-1-9] 即使受管理的設定檔並未納入主要使用者，也未將受管理設定檔視為其他使用者，但「必須」確保裝置符合所有適用於多位使用者的裝置安全性規定 (請參閱第 9.5 節)。

如果裝置實作項目宣告 android.software.managed_users 和 android.software.secure_lock_screen，就會：

[C-2-1] 必須支援指定獨立的螢幕鎖定畫面，並符合下列規定，才能僅授權給在受管理設定檔中執行的應用程式。
- 裝置實作項目「必須」遵循 DevicePolicyManager.ACTION_SET_NEW_PASSWORD 意圖，並顯示用於為受管理設定檔設定個別螢幕鎖定憑證的介面。
- 代管設定檔的螢幕鎖定憑證「必須」使用與上層設定檔相同的憑證儲存空間和管理機制，如 Android 開放原始碼計畫網站所述。
- DPC 密碼政策「必須」僅適用於代管設定檔的螢幕鎖定憑證，除非在 getParentProfileInstance 傳回的 DevicePolicyManager 例項上進行呼叫。
如果受管理設定檔的聯絡人顯示在預先安裝的通話記錄、通話使用者介面、進行中和未接來電通知、聯絡人和訊息應用程式中，他們都必須獲得徽章，且徽章應與代表受管理的設定檔應用程式相同。

3.9.3 受管理使用者支援

如果裝置實作項目宣告 android.software.managed_users，就會：

[C-1-1] isLogoutEnabled 傳回 true 時，「必須」為使用者提供登出功能，讓他們從目前的使用者登出，並切換回主要使用者。「必須」能在裝置未解鎖的情況下，從螢幕鎖定畫面存取使用者預設用途。

如果裝置實作項目宣告 android.software.device_admin，並提供裝置端使用者提示以新增額外的次要使用者，則：

[C-SR-1] 強烈建議「強烈建議」在 android.app.action.PROVISION_MANAGED_DEVICE 啟動流程中，顯示相同的 Android 開放原始碼計畫裝置擁有者同意聲明揭露聲明，這樣使用者才能將帳戶新增至新的次要使用者，讓使用者瞭解裝置處於管理狀態。

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] 「必須」按照 Accessibility API SDK 說明文件中的指示，實作 Android 無障礙架構。
[C-1-2] 必須產生無障礙事件，並依 SDK 中所述，為所有已註冊的 AccessibilityService 實作提供適當的 AccessibilityEvent。
[C-1-4] 對於宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 的無障礙服務，都必須提供使用者權限控制。請注意，如果是具有系統導覽列的裝置實作，必須允許使用者選擇系統導覽列中的按鈕來控制這些服務。

如果裝置實作項目包含預先安裝的無障礙服務，就會：

[C-2-1] 當資料儲存以檔案型加密 (FBE) 加密時，「必須」將這些預先安裝的無障礙服務實作為直接啟動感知應用程式。
「應」在開箱的設定流程中，提供一種機制，讓使用者啟用相關無障礙服務，以及調整字型大小、顯示大小和放大手勢的選項。

3.11. 文字轉語音

Android 中的 API 可讓應用程式使用文字轉語音 (TTS) 服務，並允許服務供應商實作 TTS 服務。

如果裝置實作回報 android.hardware.audio.output 功能，則會發生以下情況：

[C-1-1] 必須支援 Android TTS 架構 API。

如果裝置的導入方式支援安裝第三方 TTS 引擎，請按照下列步驟操作：

[C-2-1] 必須提供使用者預設用途，讓使用者能在系統層級選取 TTS 引擎。

3.12. 電視輸入架構

Android 電視輸入架構 (TIF) 簡化了將即時內容提交至 Android 電視裝置的程序。TIF 提供用於建立控制 Android Television 裝置的輸入模組的標準 API。

如果裝置實作支援 TIF，請按照下列步驟操作：

[C-1-1] 必須宣告平台功能 android.software.live_tv。
[C-1-2] 必須支援所有 TIF 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，將其設為 MediaSession.Callback#onMediaButtonEvent 的 KEYCODE_MEDIA_NEXT。

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 API，讓應用程式能使用這項功能。

如果實作的裝置支援隨附裝置配對功能，就會：

[C-1-1] 必須宣告功能旗標 FEATURE_COMPANION_DEVICE_SETUP 。
[C-1-2] 必須確保 android.companion 套件中的 API 已完全實作。
[C-1-3] 必須向使用者提供足夠空間，讓使用者選取/確認隨附裝置運作正常，可以正常運作。

3.17. 重量級應用程式

如果裝置實作方式宣告了 FEATURE_CANT_SAVE_STATE 功能，那麼：

[C-1-1] 「必須」只有一個已安裝的應用程式可指定 cantSaveState 在系統中執行。如果使用者在系統未明確退出應用程式的情況下退出應用程式 (例如，在使用者沒有主動退出應用程式的情況下按下主畫面，而是在沒有剩餘活動的情況下按下返回)，裝置實作就「必須」在 RAM 中優先執行該應用程式，因為其執行其他應持續運作的作業 (例如前景服務)。當這類應用程式在背景執行時，系統仍可對其套用電源管理功能，例如限制 CPU 和網路存取權。
[C-1-2] 當使用者啟動使用 cantSaveState 屬性宣告的第二個應用程式時，必須提供 UI 預設用途，選擇不會採用一般狀態儲存/還原機制的應用程式。
[C-1-3] 「不得」將政策中的其他變更套用到指定 cantSaveState 的應用程式，例如變更 CPU 效能或變更排程優先順序。

如果裝置實作方式未宣告 FEATURE_CANT_SAVE_STATE 功能，則表示：

[C-1-1] 必須忽略應用程式設定的 cantSaveState 屬性，「不得」根據該屬性變更應用程式行為。

3.18. 聯絡人

Android 提供 Contacts Provider API，可讓應用程式管理裝置上儲存的聯絡資訊。直接輸入裝置上的聯絡人資料通常會與網路服務同步，但資料「可能」也只會儲存在裝置上。僅儲存在裝置上的聯絡人稱為「本機聯絡人」。

當 ACCOUNT_NAME 和 ACCOUNT_TYPE 的欄與帳戶的對應 Account.name 和 Account.type 欄位相符時，RawContact 就會與帳戶「關聯」或「儲存在」帳戶中。

預設本機帳戶：用於儲存原始聯絡人的帳戶，這些聯絡人只會儲存在裝置上，而未與 AccountManager 中的帳戶建立關聯。此角色會在 ACCOUNT_NAME 和 ACCOUNT_TYPE 資料欄使用 null 值建立。

自訂本機帳戶：用於儲存原始聯絡人的帳戶，這些聯絡人只會儲存在裝置上，而未與 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」檔案。這類檔案是由官方 Android SDK 隨附的「aapt」工具產生。
- 由於上述規定可能具有挑戰性，因此建議裝置的實作方式使用 Android 開放原始碼計畫參考資料實作項目的套件管理系統。
[C-0-2] 必須支援使用 APK 簽名配置 3.1 版、APK 簽署配置 v3、APK 簽署配置 v2 和 JAR 簽署來驗證「.apk」檔案。
[C-0-3] 請勿以防止這些檔案在其他相容裝置上安裝及執行正確方式，擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式。
[C-0-4] 不得允許套件目前的「記錄安裝者」以外的應用程式，在未經使用者確認的情況下自行解除安裝應用程式 (如 SDK 中有關 DELETE_PACKAGE 權限的說明)。唯一的例外狀況是系統套件驗證器應用程式處理 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 提供，才能啟動應用程式 (由相同系統 API PackageManager.setHarmfulAppWarning 標示為可能有害)。
「應」在警告對話方塊中提供讓使用者自由選擇解除安裝或啟動應用程式的功能。
[C-0-8] 必須依照這裡的說明，實作漸進式檔案系統的支援功能。
[C-0-9] 必須支援使用 APK 簽署配置 v4 和 APK 簽署配置 v4.1 驗證 .apk 檔案。

5. 多媒體相容性

裝置實作方式：

[C-0-1] 必須針對 MediaCodecList 宣告的每個轉碼器，支援第 5.1 節中定義的媒體格式、編碼器、解碼器、檔案類型和容器格式。
[C-0-2] 必須透過 MediaCodecList 宣告及回報對第三方應用程式和解碼器的支援。
[C-0-3] 必須能夠正確解碼，並讓第三方應用程式使用所有可編碼的格式。這包括編碼器產生的所有位元流，以及其 CamcorderProfile 中回報的設定檔。

裝置實作方式：

應盡量縮短轉碼器延遲時間，換句話說，就是
- 請勿消耗及儲存輸入緩衝區，且只應處理一次就傳回輸入緩衝區。
- 請勿保留超過標準指定時間 (例如 SP) 的已解碼緩衝區。
- 「不應」保留超過 GOP 結構所需的編碼緩衝區。

下方所列的所有轉碼器都是以軟體實作的形式，透過 Android 開放原始碼計畫中偏好的 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 API 的 PCM 16 位元原生位元組順序音訊影格。

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

如果裝置實作支援透過 android.media.MediaCodec API 中的預設 AAC 音訊解碼器，將多頻道串流 (意即超過兩個頻道) 的 AAC 輸入緩衝區解碼至 PCM，「必須」支援以下項目：

[C-2-1] 必須「必須」在不下移的情況下執行解碼 (例如 5.0 AAC 串流必須解碼為 5 個 PCM 管道，5.1 AAC 串流必須解碼為 PCM 的六個管道)。
[C-2-2] 動態範圍中繼資料必須符合 ISO/IEC 14496-3 的「動態範圍控制 (DRC)」所定義，並使用 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] 強烈建議所有 AAC 音訊解碼器都符合上述要求 C-2-1 和 C-2-2 的規定。

解碼 USAC 音訊時，MPEG-D (ISO/IEC 23003-4)：

[C-3-1] 必須根據 MPEG-D DRC 動態範圍控制設定檔等級 1，解讀及套用粗糙度和 DRC 中繼資料。
[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 API 的 PCM 16 位元原生位元組順序音訊影格。

如果裝置實作支援透過 android.media.MediaCodec API 中的預設 AAC 音訊解碼器，將多頻道串流 (意即超過兩個頻道) 的 AAC 輸入緩衝區解碼至 PCM，則「必須」支援下列內容：

[C-7-1] 必須能由應用程式使用解碼 KEY_MAX_OUTPUT_CHANNEL_COUNT 鍵的設定，以控制內容是否會向下混音為立體聲 (使用值 2 時) 或以原生頻道數輸出時 (使用的值等於或大於該數字時)。舉例來說，如果值為 6 以上，則會在提供 5.1 內容時，將解碼器設為輸出 6 個頻道。
[C-7-2] 解碼時，解碼器「必須」使用 android.media.AudioFormat 常數 (例如：CHANNEL_OUT_5POINT1)，通告用於輸出格式的輸出格式所用的頻道遮罩 (例如：CHANNEL_OUT_5POINT1)。KEY_CHANNEL_MASK

如果裝置實作支援預設 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)	支援採用標準取樣率介於 8 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a) ADTS 原始 AAC (不支援 .aac、ADIF) MPEG-TS (.ts，不可搜尋，僅限解碼) Matroska (.mkv，僅限解碼)
MPEG-4 HE AAC 設定檔 (AAC+)	支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a)
MPEG-4 HE AACv2 設定檔 (強化 AAC+)	支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a)
AAC ELD (強化低延遲 AAC)	支援標準取樣率介於 16 至 48 kHz 的單聲道/立體內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a)
美國運通	支援標準取樣率介於 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 位元音訊資料處理「必須」支援浮點音訊設定。	FLAC (.flac) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) Matroska (.mkv，僅限解碼)
MP3	單聲道/立體聲 8 至 320 Kbps 常數 (CBR) 或可變位元率 (VBR)	MP3 (.mp3) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) Matroska (.mkv，僅限解碼)
MIDI	MIDI 類型 0 和 1。DLS 第 1 版和第 2 版。XMF 和 Mobile XMF。支援鈴聲格式 RTTTL/RTX、OTA 和 iMelody	輸入 0 和 1 (.mid、.xmf、.mxmf) RTTTL/RTX (.rtttl、.rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) Matroska (.mkv) Webm (.webm)
PCM/WAVE	PCM 轉碼器「必須」支援 16 位元線性 PCM 和 16 位元浮點值。WAVE 擷取器必須支援 16 位元、24 位元、32 位元的線性 PCM 和 32 位元浮點值 (達到硬體限制的速率)。必須支援從 8 kHz 至 192 kHz 之間的取樣率。	WAVE (.wav)
Opus	解碼：支援單聲道、立體聲、5.0 和 5.1 內容，取樣率為 8000、12000、16000、24000 和 48000 Hz。編碼：支援單聲道與立體聲內容 (採 8000、16000、16000、16000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000、12000 及 Hz 取樣率為單聲道與立體聲內容	Ogg (.ogg) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) Matroska (.mkv) Webm (.webm)

5.1.4。圖片編碼

詳情請參閱 5.1.6. 圖片轉碼器詳細資料。

裝置導入方式「必須」支援下列圖片編碼編碼：

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP

如果裝置實作方式透過 android.media.MediaCodec 支援媒體類型 MIMETYPE_IMAGE_ANDROID_HEIC 的 HEIC 編碼，就會發生以下情況：

[C-1-1] 必須提供支援 BITRATE_MODE_CQ 位元率控制模式、HEVCProfileMainStill 設定檔和 512 x 512 像素影格大小的硬體加速 HEVC 編碼器轉碼器。

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 位元的對等格式，例如透過 android.graphics.Bitmap 的 ARGB_8888 設定。

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] 必須透過 CodecCapabilities 支援 YUV420 8:8:8 彈性色彩格式 (COLOR_FormatYUV420Flexible)。
[C-SR-1] 強烈建議在輸入 Surface 模式下支援 RGB888 色彩格式。
[C-1-3] 必須支援至少一種平面或半平面 YUV420 8:8:8 顏色格式：COLOR_FormatYUV420PackedPlanar (相當於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (相當於 COLOR_FormatYUV420SemiPlanar)。極力建議您支援這兩種顏色。

5.1.7. 視訊轉碼器

為提供可接受的網路影片串流和視訊會議服務品質，裝置實作「應」使用符合規定的硬體 VP8 轉碼器。

如果裝置實作包含影片解碼器或編碼器：

[C-1-1] 影片轉碼器「必須」支援輸出和輸入位元組緩衝區大小，這些大小可容納標準和設定要求中最大可行的壓縮和未壓縮影格，但也不會過度分配。
[C-1-2] 視訊編碼器和解碼器必須在 CodecCapabilities 之前，支援 YUV420 8:8:8 彈性色彩格式 (COLOR_FormatYUV420Flexible)。
[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 色彩格式，才能反映這項設定。

如果裝置實作是透過 Display.HdrCapabilities 通告 HDR 設定檔支援，就會：

[C-2-1] 必須支援 HDR 靜態中繼資料剖析及處理功能。

如果裝置實作是透過 MediaCodecInfo.CodecCapabilities 類別中的 FEATURE_IntraRefresh 宣傳內部重新整理支援，就會執行以下動作：

[C-3-1] 必須支援 10 到 60 個影格的重新整理週期，並在設定的重新整理週期的 20% 內正確運作。

除非應用程式另外指定 KEY_COLOR_FORMAT 格式鍵，否則影片解碼器會實作：

[C-4-1] 如果透過 Surface 輸出進行設定，必須預設使用針對硬體螢幕最佳化的顏色格式。
[C-4-2] 如果設為不使用 Surface 輸出，則預設使用 YUV420 8:8:8 色彩格式，針對 CPU 讀取作業進行最佳化。

5.1.8。影片轉碼器清單

格式/轉碼器	詳細說明	支援的檔案類型/容器格式
標題 263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv，僅限解碼)
H.264 AVC	詳情請參閱第 5.2 節和第 5.3 節	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts，無法搜尋) Matroska (.mkv，僅限解碼)
H.265 HEVC	詳情請參閱第 5.3 節。	MPEG-4 (.mp4) Matroska (.mkv，僅限解碼)
MPEG-2	主要個人資料	MPEG2-TS (.ts，無法搜尋) MPEG-4 (僅限解碼 .mp4) Matroska (.mkv，僅限解碼)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv，僅限解碼)
VP8	詳情請參閱第 5.2 節和第 5.3 節	WebM (.webm) Matroska (.mkv)
VP9	詳情請參閱第 5.3 節。	WebM (.webm) Matroska (.mkv)

5.1.9。媒體轉碼器安全性

裝置實作「必須」確保符合下文所述的媒體轉碼器安全性功能。

Android 支援 OMX (跨平台多媒體加速 API) 和低負載多媒體加速 API 轉碼器 2.0。

如果裝置導入方式支援多媒體，就會執行以下動作：

[C-1-1] 必須「必須」透過 OMX 或 Codec 2.0 API (或兩者) 提供媒體轉碼器支援 (與 Android 開放原始碼計畫相同)，不得停用或規避安全保護措施。具體來說，這不表示每個轉碼器「必須」使用 OMX 或 Codec 2.0 API，只有至少可支援其中一個 API，且對可用 API 的支援「必須」包含目前的安全保護措施。
[C-SR-1] 強烈建議你加入 Codec 2.0 API 的支援。

如果裝置的實作不支援 Codec 2.0 API，程式碼會：

[C-2-1] 必須針對裝置支援的每種媒體格式和類型 (編碼器或解碼器)，加入 Android 開放原始碼計畫中相應的 OMX 軟體轉碼器 (如果有的話)。
[C-2-2] 名稱開頭為「OMX.google」的轉碼器。必須採用 Android 開放原始碼計畫的原始碼
[C-SR-2] 強烈建議 OMX 軟體轉碼器在轉碼器程序中執行，因此無法存取記憶體對應程式以外的硬體驅動程式。

如果裝置實作支援 Codec 2.0 API，就會發生以下情形：

[C-3-1] 必須針對裝置支援的每種媒體格式和類型 (編碼器或解碼器)，加入 Android 開放原始碼計畫 (如有) 中相應的轉碼器 2.0 軟體轉碼器。
[C-3-2] 「必須」在 Android 開放原始碼計畫中提供的軟體轉碼器程序中置入轉碼器 2.0 軟體轉碼器，才能縮小範圍授予軟體轉碼器的存取權。
[C-3-3] 名稱開頭為「c2.android」的轉碼器。必須採用 Android 開放原始碼計畫的原始碼

5.1.10。媒體轉碼器字元化

如果裝置導入方式支援媒體轉碼器，就會：

[C-1-1] 必須透過 MediaCodecInfo 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 超高畫質
影片解析度	176 x 144 像素 (H263、MPEG2、MPEG4) 352 x 288 px (MPEG4 編碼器、H263、MPEG2) 320 x 180 像素 (VP8，VP8) 320 x 240 像素 (其他)	704 x 576 像素 (H263) 640 x 360 像素 (VP8，VP9) 640 x 480 px (MPEG4 編碼器) 720 x 480 像素 (其他)	1408 x 1152 像素 (H263) 1280 x 720 像素 (其他)	1920 x 1080 px (不包括 MPEG4)	3840 x 2160 px (HEVC，VP9)

[C-2-2] 採硬體加速的視訊轉碼器必須發布效能點資訊。除非這些清單列出了所有支援的標準效能點 (列於 PerformancePoint API 中)，除非這些點受到其他支援的標準效能點的涵蓋範圍內。
此外，如果除了上述任一項標準以外，還能提升影片成效，而應發布額外的效能點。

5.2. 影片編碼

如果裝置實作支援任何影片編碼器，並將其提供給第三方應用程式，就會：

不應：超過兩個滑動窗，與內框 (I 影格) 間隔之間的位元率超過 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] 極力建議您提供適用於流暢轉碼 API 的外掛程式，以便從 HDR 格式轉換為 SDR 格式。

5.2.1。標題 263

如果裝置實作支援 H.263 編碼器，並且提供給第三方應用程式使用，它們會：

[C-1-1] 必須支援基準設定檔第 45 級。
應支援為支援的編碼器動態設定位元率。

5.2.2。H.264

如果裝置的實作支援 H.264 轉碼器，就會：

[C-1-1] 必須支援基準設定檔級別 3。不過，我們會提供 ASO (任意配量順序)、FMO (彈性巨集排序) 和 RS (備援配量) 的支援。此外，為了維持與其他 Android 裝置的相容性，我們建議編碼器不會將 ASO、FMO 和 RS 用於基準設定檔。
[C-1-2] 必須支援下表中的 SD (標準畫質) 影片編碼設定檔。
應支援第 4 級主要設定檔。
應支援 HD (高畫質) 影片編碼設定檔，如下表所示。

如果裝置實作回報透過媒體 API 提供 720p 或 1080p 解析度影片的 H.264 編碼支援，就會：

[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 硬體編碼規定的硬體 VP8 轉碼器，以確保網路影片串流和視訊會議服務的品質符合規範。

如果裝置實作回報透過媒體 API 回報支援 720p 或 1080p 解析度影片的 VP8 編碼，就會：

[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

如果裝置實作項目宣告透過 Media API 支援 Profile 2 或 Profile 3：

支援 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] 必須在同一個串流中，透過標準 Android API 支援所有 VP8、VP9、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 (多餘配量)。
[C-1-2] 必須能夠使用下表所列的 SD (標準畫質) 設定檔解碼影片，並使用基準設定檔和主要設定檔等級 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、1080 和 UHD 超高畫質設定檔的 H.265 或 VP9 解碼器。

	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

如果裝置實作項目要求透過 Media API 支援 HDR 設定檔：

[C-3-1] 裝置實作「必須」接受應用程式所需的 HDR 中繼資料，並支援從位元流和/或容器擷取及輸出所需的 HDR 中繼資料。
[C-3-2] 裝置實作「必須」在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

5.3.6。VP8

如果裝置導入方式支援 VP8 轉碼器，就會：

[C-1-1]「必須」支援下表中的 SD 解碼設定檔。
請務必使用符合規定的硬體 VP8 轉碼器。
應支援下表中的 HD 高畫質解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，請執行以下操作：

[C-2-1] 裝置實作項目「必須」支援下表中的 720p 設定檔。
[C-2-2] 裝置實作項目「必須」支援下表中的 1080p 設定檔。

	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] 裝置實作項目至少須支援 720、1080 和 UHD 超高畫質設定檔的 VP9 或 H.265 解碼器。

	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

如果裝置實作項目透過 'CodecProfileLevel' 媒體 API 宣告支援 VP9Profile2 或 VP9Profile3：

支援 12 位元格式。

如果裝置實作項目宣告透過媒體 API 支援 HDR 設定檔 (VP9Profile2HDR、VP9Profile2HDR10Plus、VP9Profile3HDR、VP9Profile3HDR10Plus)：

[C-4-1] 裝置實作「必須」從應用程式接受必要的 HDR 中繼資料 (所有 HDR 設定檔皆為 KEY_HDR_STATIC_INFO，HDR10Plus 設定檔則使用 'KEY_HDR10_PLUS_INFO')。也「必須」支援從位元流和/或容器中擷取及輸出所需的 HDR 中繼資料。
[C-4-2] 裝置實作「必須」在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

5.3.8。Dolby Vision

如果裝置實作程序透過 HDR_TYPE_DOLBY_VISION 宣告支援 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] 必須以 44100 和 48000 的取樣率之一擷取 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源。
[C-1-2] 從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，「必須」預設停用所有雜訊抑制音訊處理作業。
[C-1-3] 從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，必須預設停用所有自動增益控制項。
應該在中頻範圍中表現出近乎平坦的振幅與頻率特性：特別是從 100 Hz 到 4000 Hz 的 ±3dB，每個用來錄製語音辨識音訊來源的麥克風也要有這種特性。
[C-SR-1] 強烈建議在低頻率範圍內展現振幅：特別是從 ±20 dB 的 30 Hz 至 100 Hz 範圍，對於錄製語音辨識音訊來源的每個麥克風的中頻範圍相比，是比較理想的值。
[C-SR-2] 強烈建議在高頻率範圍內展現振幅：特別是從 4000 Hz 到 22 KHz 的振幅範圍相比，這是與錄製語音辨識音訊來源的每個麥克風中間頻率範圍相比的結果。
應設定音訊輸入靈敏度，讓每個使用 1000 Hz 音色調音源的 1000 Hz 音調音量來源 (在麥克風旁邊測量) (測量於麥克風旁邊) 時，以 1770 至 3500 的全聲道辨識 RMS 2500 和 3530 度，且錄音精確度為 1770 和 3530 (以 16 db 為 16) 的 RMS 2500 的理想回應。
請錄製語音辨識音訊串流，以讓 PCM 振動水平追蹤輸入 SPL 至少介於 -18 dB 到 +12 dB re 90 dB SPL 之間介於 -18 dB 到 +12 dB re 90 dB SPL 之間的變化。
使用麥克風時，在 1 kHz 的 1 kHz 輸入率為 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，就會：

應實作 Acoustic Echo canceler (AEC) 技術，專為語音通訊調整，並在使用 AudioSource.VOICE_COMMUNICATION 擷取時，套用到擷取路徑。

如果裝置實作提供在選取 AudioSource.VOICE_COMMUNICATION 的情況下，於擷取音訊路徑中插入的聲學回應取消工具，則會：

[C-SR-1] STRONGLY_RECOMMENDED 會透過 AcousticEchoCanceler API 方法 AcousticEchoCanceler.isAvailable() 宣告這個 API 方法。
[C-SR-2] 可 STRONGLY_RECOMMENDED，允許透過 AcousticEchoCanceler API 控制這個音訊效果。
[C-SR-3] 的 STRONGLY_RECOMMENDED 可識別每個透過 AudioEffect.Descriptor.uuid 欄位實作的 AEC 技術。

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] 必須支援可透過 AudioEffect 子類別 Equalizer 和 LoudnessEnhancer 控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 實作。
[C-1-2] 必須支援視覺化工具 API 實作，且可透過 Visualizer 類別控制。
[C-1-3] 必須支援可透過 AudioEffect 子類別 DynamicsProcessing 使用的 EFFECT_TYPE_DYNAMICS_PROCESSING 實作控制項。
應支援可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作項目。
[C-SR-1] 極力推薦支援浮點和多管道效果。

5.5.3. 音訊輸出音量

Automotive 裝置實作：

應允許使用 AudioAttributes 定義的內容類型或使用方式，以及 android.car.CarAudioManager 中公開定義的車輛音訊使用方式，分別調整每個音訊串流的音訊音量。

5.5.4。音訊卸載

如果裝置的導入方式支援音訊卸載播放，就會：

[C-SR-1] 如 AudioTrack gapless API 和 MediaPlayer 的媒體容器指定格式，「強烈建議」在兩個片段之間採用相同格式來剪輯播放的無間斷音訊內容。

5.6. 音訊延遲時間

音訊延遲是指音訊訊號通過系統的時間延遲。許多類別的應用程式都依賴短延遲時間來實現即時音效。

為達成本節目的，請使用下列定義：

輸出延遲。應用程式寫入 PCM 編碼資料框架的時間，與相應聲音在裝置端轉場器向環境呈現，或訊號透過通訊埠從裝置傳出的間隔時間，且可對外觀察。
冷輸出延遲。從輸出串流開始，到根據時間戳記，第一個影格的顯示時間，即音訊輸出系統處於閒置狀態，且在要求前關機的時間。
連續輸出延遲。裝置播放音訊後，後續影格的輸出延遲時間。
輸入延遲。裝置端傳訊器或訊號向裝置顯示音效的間隔時間，是指透過通訊埠進入裝置，以及應用程式讀取對應 PCM 編碼資料影格的間隔時間。
輸入信號的初始部分無法使用或無法使用。
冷輸入延遲時間。從串流開始到收到第一個有效影格的時間，是指音訊輸入系統處於閒置狀態，且在要求前關機的時間。
連續輸入延遲。後續影格的輸入延遲時間，當裝置擷取音訊時。
連續往返延遲時間。連續輸入延遲時間的總和加上連續輸出延遲時間加一個緩衝區週期的總和。緩衝期可讓應用程式處理應用程式信號和時間，減少輸入與輸出串流之間的階段差異。
OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 組合。
AAudio 原生音訊 API。Android NDK 中的 AAudio API 組合。
時間戳記：組合包含串流中的相對影格位置，以及影格進入或離開相關端點音訊處理管道的預估時間。另請參閱 AudioTimestamp。
音訊訊號中暫時中斷或不正確的範例值，通常是因為輸出的緩衝區不足、針對輸入的緩衝區過載，或任何其他數位或類比雜訊來源所致。
平均絕對偏差。從一組值的平均值偏差的絕對值平均值。
感應式延遲。從輕觸螢幕到聽到裝置發出聲音的間隔時間。

如果裝置實作項目宣告 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] 強烈建議確保針對從 AAudioStream_getPerformanceMode() 傳回 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 的串流，AAudioStream_getFramesPerBurst() 傳回的值小於或等於屬性鍵 AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER 傳回的值。android.media.AudioManager.getProperty(String)

如果裝置實作不符合透過 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	影片轉碼器： H264 AVC MPEG-4 SP MPEG-2 如要進一步瞭解 H264 AVC、MPEG2-4 SP、和 MPEG-2，請參閱第 5.1.8 節。音訊轉碼器：進階音訊編碼如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.3 節。
採用 ADTS 取景和 ID3 代碼的 AAC	ISO 13818-7	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節
WebVTT	WebVTT

區隔格式

參考資料

必要的轉碼器支援

MPEG-2 傳輸串流

ISO 13818

影片轉碼器：

H264 AVC
MPEG-4 SP
MPEG-2

如要進一步瞭解 H264 AVC、MPEG2-4 SP、
和 MPEG-2，請參閱第 5.1.8 節。

音訊轉碼器：

進階音訊編碼

如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.3 節。

採用 ADTS 取景和 ID3 代碼的 AAC

ISO 13818-7

如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節

WebVTT

RTSP (RTP、SDP)

個人資料名稱	參考資料	必要的轉碼器支援
H264 AVC	RFC 6184	如要進一步瞭解 H264 AVC，請參閱第 5.1.8 節
MP4A-LATM	RFC 6416	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.3 節
H263-1998	RFC 3551 RFC 4629 RFC 2190	如要進一步瞭解 H263，請參閱第 5.1.8 節。
263 至 2000 年	RFC 4629	如要進一步瞭解 H263，請參閱第 5.1.8 節。
AMR	RFC 4867	如要進一步瞭解 AMR-NB，請參閱第 5.1.3 節。
AMR-WB	RFC 4867	如要進一步瞭解 AMR-WB，請參閱第 5.1.3 節。
MP4V-西班牙語	RFC 6416	如要進一步瞭解 MPEG-4 SP，請參閱第 5.1.8 節。
mpeg4 泛型	RFC 3640	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.3 節
MP2T	RFC 2250	詳情請參閱 HTTP 直播底下的 MPEG-2 傳輸串流

5.8. 安全媒體

如果裝置實作支援安全視訊輸出，且能夠支援安全介面，就會發生以下情形：

[C-1-1] 必須宣告支援 Display.FLAG_SECURE。

如果裝置實作項目宣告支援 Display.FLAG_SECURE，並支援無線顯示通訊協定，就會：

[C-2-1] 請針對透過 Miracast 等無線通訊協定連線的螢幕，使用加密強度高的機制保護連結安全，例如 HDCP 2.x 以上版本。

如果裝置實作項目宣告支援 Display.FLAG_SECURE，並支援有線外部螢幕，就會：

[C-3-1] 必須支援所有透過使用者可存取的有線連接埠連接的外部螢幕，支援 HDCP 1.2 以上版本。

5.9. 樂器數位介面 (MIDI)

如果裝置實作項目透過 android.content.pm.PackageManager 類別回報支援功能 android.software.midi，就會：

[C-1-1] 必須「一律」透過支援 MIDI 的「所有」硬體傳輸 (MIDI) 支援 MIDI，這類傳輸方式提供一般的非 MIDI 連線，其中這類傳輸方式如下：
- USB 主機模式，第 7.7 節
- 藍牙 LE 技術的 MIDI，第 7.4.3 節
[C-1-2] 必須支援應用程式內的 MIDI 軟體傳輸 (虛擬 MIDI 裝置)
[C-1-3] 必須包含 libamidi.so (原生 MIDI 支援)
應支援第 7.7 節，透過 USB 週邊裝置模式支援 MIDI

5.10. 專業音質

如果裝置實作程序透過 android.content.pm.PackageManager 類別回報 android.hardware.audio.pro 功能支援，那麼這些程式碼會：

[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，才能符合延遲時間和 USB 音訊規定。
[C-1-6] 冷輸出延遲時間不得超過 200 毫秒。
[C-1-7] 冷輸入延遲時間不得超過 200 毫秒。
[C-1-8] 從喇叭到麥克風資料路徑的測量時，輕觸音調的平均延遲時間至少須為 80 毫秒或更短。
[C-SR-1] 強烈推薦符合 5.6 音訊延遲時間一節定義的延遲時間 (即 20 毫秒或更短)，且在揚聲器到麥克風路徑上，平均絕對差不超過 5 毫秒，超過 5 次測量。
[C-SR-2] 極力建議您透過 MMAP 路徑使用 AAudio 原生音訊 API，滿足 Pro Audio 的連續往返音訊延遲時間、冷輸入延遲時間和冷輸出延遲時間，以及 USB 音訊相關規定。
[C-SR-3] 強烈建議使用音訊，且 CPU 負載會有所不同，才能提供一致的 CPU 效能等級。請使用 Android 應用程式 SynthMark 進行測試。SynthMark 使用的軟體合成器在模擬音訊架構中執行，該模型可測量系統效能。如需基準測試的說明，請參閱 SynthMark 說明文件。SynthMark 應用程式必須使用「Automated Test」選項執行，才能達到下列結果：
- Voicemark.90 >= 32 種語音
- etcmark.fixed.little <= 15 毫秒
- etcmark.dynamic.little <= 50 毫秒
應盡量減少音訊時鐘的準確度，以及相對於標準時間的偏移。
在兩個動作皆啟用時，應盡量減少音訊時鐘相對於 CPU CLOCK_MONOTONIC 的偏移。
應盡量縮短裝置端轉換器的音訊延遲情形。
相較於 USB 數位音訊，應盡量縮短音訊延遲。
應記錄所有路徑的音訊延遲測量值。
請盡量減少音訊緩衝區完成回呼輸入時間的時基誤差，因為這會影響回呼可用的完整 CPU 頻寬百分比。
應該在正常使用時回報延遲，避免發生音訊故障。
應呈現零的跨管道延遲時間差異。
應盡量減少所有傳輸中的 MIDI 平均延遲時間。
應盡量減少所有傳輸過程中負載 (如時基誤差) 的 MIDI 延遲時間變化。
所有傳輸作業都應提供準確的 MIDI 時間戳記。
應盡量減少在裝置端轉場器 (包括冷啟動後會立即) 的音訊訊號雜訊。
當對應端點的輸入和輸出端時，如果兩者皆處於啟用狀態，則應該提供零的音訊時鐘差異。對應的端點範例包括裝置端麥克風和喇叭，或音訊插孔輸入和輸出。
在兩者皆啟用的情況下，應在同一個執行緒上針對對應端點的輸入和輸出端處理音訊緩衝區完成回呼，並在輸入回呼的傳回後立即輸入輸出回呼。如果無法在同一個執行緒上處理回呼，請在輸入輸入回呼後不久進入輸出回呼，讓應用程式擁有一致的輸入和輸出端時間。
請盡量減少對於對應端點的輸入和輸出端 HAL 音訊緩衝區之間的相位差異。
應盡量縮短觸控延遲時間。
應盡量減少載入時觸控延遲時間的變化 (時基誤差)。

如果裝置的實作方式符合上述所有規定，就會：

[C-SR-4] 強烈建議透過 android.content.pm.PackageManager 類別回報 android.hardware.audio.pro 功能的相關支援。

如果裝置實作項目包含 4 導體 3.5 公釐耳機插孔，則：

[C-2-1] 必須設定平均連續往返音訊延遲時間 (定義請見 5.6 音訊延遲一節)，在 20 毫秒或更短時間內，透過音訊回送連接器在音訊插孔路徑中，平均差額小於 5 毫秒，超過 5 次測量平均。
[C-SR-5] 強烈建議遵循有線音訊頭戴式規格 (v1.1) 的「行動裝置 (插孔)」規格。

如果裝置實作略過 4 導體 3.5 公釐音訊插孔，並納入支援 USB 主機模式的 USB 連接埠，就會執行以下動作：

[C-3-1] 必須實作 USB 音訊類別。
[C-3-2] 平均連續往返音訊延遲時間不得超過 25 毫秒，在使用 USB 主機模式通訊埠的 USB 主機模式通訊埠上，如果發生平均絕對差不超過 5 毫秒，則超過 5 次測量的平均絕對偏差。(您可以使用 USB-3.5mm 轉接器和音訊回送連接器，或透過 USB 音訊介面搭配修補線將輸入和輸出的連接線進行測量)。
[C-SR-6] 強烈建議「極力」支援同時支援最多 8 個 I/O 聲道，每個方向最多支援 8 個聲道，以及 96 kHz 取樣率，以及 24 位元或 32 位元深度 (如果與同樣支援這些要求的 USB 音訊週邊裝置搭配使用)。
[C-SR-7] 極力建議您透過 MMAP 路徑使用 AAudio 原生音訊 API，以符合這組要求。

如果裝置導入作業設有 HDMI 連接埠，請檢查下列事項：

至少應在一項設定支援 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] 在中頻範圍內，必須呈現大約平坦的振幅與頻率特性：特別是從 100 Hz 到 7000 Hz 的每組麥克風，用來記錄未處理音訊來源的個別麥克風。
[C-1-3] 必須在低頻率範圍中呈現振幅：特別是從 5 Hz 至 100 Hz 的振幅範圍相比，每個用於錄製未處理音訊來源的麥克風的中頻率範圍是比較的。
[C-1-4] 必須呈現高頻率範圍的振幅強度：特別是從 7000 Hz 到 22 KHz 的振幅，相比之下，對於記錄未處理音訊來源的每個麥克風而言，兩者之間的中間頻率範圍更是如此。
[C-1-5] 必須設定音訊輸入靈敏度，讓以 94 dB 音壓等級 (SPL) 播放的 1000 Hz 音色調源線能夠產生回應，針對 16 位元取樣 (每個使用且每單位 16 位元取樣的 RMS 以及 36 dB 完整體重計) 產生回應。
[C-1-6] 每個用來錄製未處理音訊來源的麥克風，都需達到 60 dB 以上的訊號雜訊比 (SNR)。(SNR 的測量結果是 94 dB SPL 與自噪音中的相等 SPL 之間的差異，A 加權)。
[C-1-7] 每 1 kHZ 的總諧變形 (THD) 必須小於 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) API 方法傳回 null，以正確指出缺少支援。
[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 (ImageWriter、MediaImage、ByteBuffer) 輸入的 P010 格式。

如果影片編碼器通告支援 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] 每個支援的 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 編輯功能的影片編碼器，則：

即使某些影格沒有中繼資料，請盡量縮短延遲時間，並妥善處理含有中繼資料但部分影格的中繼資料的情況。這個中繼資料必須精確 (例如，代表影格的實際峰值亮度和直方圖)。

如果裝置實作包含支援 FEATURE_HdrEditing 的轉碼器，則這些轉碼器：

[C-7-1] 必須支援至少一個 HDR 設定檔。
[C-7-2] 必須對該轉碼器通告的所有 HDR 設定檔支援 FEATURE_HdrEditing。換句話說，如果所有使用 HDR 中繼資料的支援 HDR 設定檔，則「必須」支援產生 HDR 中繼資料。
[C-7-3] 必須支援下列影片編碼器輸入格式，這些格式可完整保留已解碼的 HDR 訊號：
- 適用於輸入途徑和 ByteBuffer 的 RGBA_1010102 (已位於目標轉乘曲線中)，且必須支援對 COLOR_Format32bitABGR2101010 的支援。

如果裝置實作包含支援 FEATURE_HdrEditing 的轉碼器，則裝置如下：

[C-7-4] 必須廣告支援 EXT_YUV_target OpenGL 擴充功能。

6. 開發人員工具與選項的相容性

6.1. 開發人員工具

裝置實作方式：

[C-0-1] 必須支援 Android SDK 中提供的 Android 開發人員工具。
Android Debug Bridge (ADB)
- [C-0-2] 必須支援 Android SDK 中記錄的 ADB 和 Android 開放原始碼計畫提供的殼層指令，供應用程式開發人員使用，包括 dumpsys cmd stats
- [C-0-11] 必須支援殼層指令 cmd testharness。在沒有永久資料區塊的情況下，從舊版 Android 升級裝置實作項目不受 C-0-11 排除。
- [C-0-3] 「不得」變更透過 dumpsys 指令記錄的裝置系統事件 (batterystats 、diskstats、指紋、graphicstats、netstats、notification、 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 Debug Bridge。
- [C-0-5] 必須支援安全 ADB。Android 支援安全 ADB。安全 ADB 可在已知的驗證主機上啟用 ADB。
- [C-0-6] 必須提供允許 ADB 從主機機器連線的機制。具體違規事項如下：
如果裝置的實作方式在沒有 USB 連接埠的情況下支援週邊裝置模式，則會造成：
- [C-3-1] 必須透過區域區域網路 (例如乙太網路或 Wi-Fi) 實作 ADB。
- [C-3-2] 必須為 Windows 7、8 和 10 提供驅動程式，讓開發人員使用 ADB 通訊協定連接裝置。
如果裝置的實作支援透過 Wi-Fi 或乙太網路連至主機機器的 ADB 連線，則可執行以下動作：
- [C-4-1] 必須讓 AdbManager#isAdbWifiSupported() 方法傳回 true。
如果裝置實作支援透過 Wi-Fi 或乙太網路連至主機機器的 ADB 連線，且包含至少一部相機，請按照下列步驟操作：
- [C-5-1] 必須讓 AdbManager#isAdbWifiQrSupported() 方法傳回 true。
Dalvik 偵錯監控服務 (ddms)
- [C-0-7] 必須支援 Android SDK 中記錄的所有 ddms 功能。由於 ddms 會使用 ADB，預設會停用 ddms 的支援，但當使用者啟用 Android Debug Bridge 時，都必須支援上述功能。
SysTrace
- [C-0-9] 必須支援 Android SDK 中所述的 systrace 工具。 Systrace 必須預設為停用，且「必須」讓使用者能存取的機制才能啟用 Systrace。
Perfetto
- [C-SR-1] 強烈建議向殼層使用者公開 /system/bin/perfetto 二進位檔，而 cmdline 必須符合 Perfetto 說明文件。
- [C-SR-2] Perfetto 二進位檔極度建議接受為符合 Perfetto 說明文件所定義結構定義的 protobuf 設定。
- [C-SR-3] Perfetto 二進位檔強烈建議以輸出為輸出 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
- [C-SR-4] 強烈建議透過 Perfetto 二進位檔提供至少 Perfetto 說明文件中所述的資料來源。
低記憶體終止工具
- [C-0-12] 當應用程式遭低記憶體終止工具終止時，「必須」將 LMK_KILL_OCCURRED_FIELD_NUMBER Atom 寫入統計資料記錄。
測試控管模式 如果裝置實作支援殼層指令 cmd testharness，並執行 cmd testharness enable，就會執行以下動作：
- [C-2-1] 必須針對 ActivityManager.isRunningInUserTestHarness() 傳回 true
- [C-2-2] 「必須」按照「測試控管工具模式」說明文件中所述實作測試控管工具模式。
GPU 工作資訊

裝置實作方式：
- [C-0-13] 必須實作殼層指令 dumpsys gpu --gpuwork，才能顯示 power/gpu_work_period 核心追蹤記錄點傳回的匯總 GPU 工作資料；如果不支援追蹤點，則不顯示任何資料。Android 開放原始碼計畫實作方式為 frameworks/native/services/gpuservice/gpuwork/。

如果裝置實作項目透過 android.hardware.vulkan.version 功能旗標回報支援 Vulkan 1.0 以上版本，則：

[C-1-1] 「必須」提供預設用途，讓應用程式開發人員啟用/停用 GPU 偵錯層。
[C-1-2]「必須」啟用 GPU 偵錯層時，列舉外部工具 (即非平台或應用程式套件) 所提供可偵錯應用程式基本目錄中的程式庫層，以支援 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。

6.2. 開發人員選項

Android 支援開發人員設定應用程式開發相關設定。

裝置實作「必須」為開發人員選項提供一致的體驗，包括：

[C-0-1] 必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，才能顯示應用程式開發相關設定。根據預設，上游 Android 實作會隱藏「Developer Options」選單，讓使用者在「Settings」 >「About Device」 >「Build Number」選單項目中按下七 (7) 次後，再啟動開發人員選項。
[C-0-2] 預設必須隱藏開發人員選項。
[C-0-3] 「必須」提供明確機制，使應用程式能夠啟用開發人員選項，而不對某個第三方應用程式提供優先處理。「必須」提供可公開查看的文件或網站，說明如何啟用開發人員選項。這份文件或網站必須能從 Android SDK 文件連結。
如果已啟用開發人員選項，且有顧慮到使用者安全，就應持續向使用者顯示視覺通知。
對於「開發人員選項」選單，「開發人員選項」選單可能會暫時隱藏或停用選單，以免在顧慮使用者安全的情況下受到干擾。

7. 硬體相容性

如果裝置含有特定硬體元件，且該元件有第三方開發人員適用的 API：

[C-0-1] 裝置實作「必須」按照 Android SDK 說明文件中所述實作該 API。

如果 SDK 中的 API 與宣稱為選用的硬體元件互動，且裝置實作項目並未擁有該元件：

[C-0-2] 您仍必須提出元件 API 的完整類別定義 (如 SDK 所述)。
[C-0-3] API 的行為「必須」以合理方式實作為免人工管理。
[C-0-4] 在 SDK 說明文件允許的情況下，API 方法「必須」傳回空值。
[C-0-5] API 方法「必須」針對 SDK 說明文件不允許的空值類別，傳回免人工管理實作項目。
[C-0-6] API 方法「不得」擲回 SDK 說明文件未記錄的例外狀況。
[C-0-7] 裝置實作「必須」針對相同建構指紋，在 android.content.pm.PackageManager 類別上透過 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法持續回報準確的硬體設定資訊。

適用這些規定的典型範例就是電話 API：即使在手機以外的裝置上，這些 API 的實作方式都必須以合理的免人工管理方式實作。

7.1. 顯示和圖形

Android 內含可自動為裝置調整應用程式資產和 UI 版面配置的功能，確保第三方應用程式能在各種硬體設定上正常運作。在 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] 必須按照 Android SDK 說明文件中的定義，回報 Configuration.screenLayout 的正確版面配置大小。具體來說，裝置實作「必須」回報正確的邏輯密度獨立像素 (dp) 螢幕尺寸，如下所示：
- 如果裝置將 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 以外的任何值，且回報 Configuration.screenLayout 的 small 大小，則至少須具備 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] 必須如 Android SDK 說明文件所述，透過 AndroidManifest.xml 中的 <supports-screens> 屬性，正確遵循應用程式對於螢幕大小的支援。
「可能」具備與 Android 相容的螢幕(圓角設計)。

如果裝置實作項目支援 UI_MODE_TYPE_NORMAL，且提供有圓角的 Android 相容螢幕，就會執行以下動作：

[C-1-1] 必須確保符合下列至少一項條件：
- 圓角的半徑小於或等於 38 dp。
- 將 15 dp x 15 dp 的方塊固定在邏輯螢幕的各角落時，每個方塊至少要有一個像素顯示在畫面中。
應提供使用者預設用途，切換為以矩形邊角切換至顯示模式。

如果裝置實作項目包含與 Android 相容的摺疊式螢幕，或是在多個螢幕面板之間加入折疊轉軸，並提供這類螢幕轉譯第三方應用程式，那麼程式碼會：

[C-2-1] 必須實作擴充功能 API 的最新可用穩定版本，或導入 Window Manager Jetpack 程式庫使用的穩定版本 sidecar API。

如果裝置實作項目包含與 Android 相容的折疊式螢幕，或是在多個螢幕面板之間設置折疊轉軸，且轉軸或折疊跨越全螢幕應用程式視窗，就會執行以下動作：

[C-3-1] 必須向應用程式回報轉軸或折疊的位置、邊界和狀態。

如要進一步瞭解如何正確實作補充資訊或擴充功能 API，請參閱 Window Manager Jetpack 的公開說明文件。

7.1.1.2。螢幕顯示比例

雖然 Android 相容螢幕的實體螢幕顯示比例沒有限制，但第三方應用程式算繪的邏輯螢幕顯示比例可能衍生自透過 view.Display API 和 Configuration 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 設為 UI_MODE_TYPE_WATCH 的裝置實作項目，顯示比例值必須設為 1.0 (1:1)。

7.1.1.3. 螢幕密度

Android UI 架構會定義一組標準邏輯密度，協助應用程式開發人員指定應用程式資源。

[C-0-1] 根據預設，裝置實作項目「必須」只能回報 DisplayMetrics 透過 DENSITY_DEVICE_STABLE API 列出的其中一種 Android 架構密度，且這個值「不得」隨時變更；不過，裝置「可能」會根據使用者在初始啟動後所設的顯示設定變更 (例如顯示大小) 回報不同的任意密度。
裝置實作項目「必須」定義標準 Android 架構密度，且該密度與螢幕實際密度最接近，除非該邏輯密度將回報的螢幕大小推進低於支援下限。如果標準 Android 架構密度的數值接近實體密度，且螢幕尺寸小於支援的最小相容螢幕大小 (320 dp 寬度)，則裝置實作應會回報下一個最低的標準 Android 架構密度。

如果有權變更裝置的顯示大小：

[C-1-1] 顯示大小「不得」縮放任何大於原生密度的 1.5 倍，或產生小於 320dp (相當於資源限定詞 sw320dp) 的有效最小螢幕尺寸 (以先發生者為準)。
[C-1-2] 顯示大小「不得」小於原生密度的 0.85 倍。
為確保良好的可用性並維持一致的字型大小，建議提供下列原生多媒體廣告選項的縮放功能 (同時遵守上述的限制)。
- 小：0.85x
- 預設：1x (原生多媒體縮放比例)
- 大：1.15 倍
- 較大：1.3 倍
- 最大 1.45 倍

7.1.2. 顯示指標

如果裝置實作項目包含與 Android 相容的螢幕或影片輸出至 Android 相容螢幕，這些元件就會：

[C-1-1] 必須針對 android.util.DisplayMetrics API 中定義的所有 Android 相容顯示指標回報正確的值。

如果裝置實作項目不包含嵌入畫面或影片輸出內容，就會發生以下情形：

[C-2-1] 必須針對模擬的預設 view.Display，回報 android.util.DisplayMetrics API 中定義的 Android 相容螢幕的正確值。

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] 必須透過代管 API (例如透過 GLES10.getString() 方法) 和原生 API，正確識別支援的 OpenGL ES 版本 (1.1、2.0、3.0、3.1、3.2)。
[C-0-2] 必須針對指出支援的每個 OpenGL ES 版本，加入所有對應的代管 API 和原生 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 測試會分成多個測試清單，每個清單都有相關聯的日期/版本號碼。這些位於 external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt 的 Android 原始碼樹狀結構中。如果裝置在自行回報的層級支援 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] 必須回報透過 android.software.opengles.deqp.level 功能旗標支援的 OpenGL ES dEQP 測試最高版本。
[C-2-4] 至少必須支援 132383489 版 (自 2020 年 3 月 1 日起)，如 android.software.opengles.deqp.level 功能標記中所述。
[C-2-5] 針對每個支援的 OpenGL ES 版本，必須通過測試清單中 132383489 版與 android.software.opengles.deqp.level 功能旗標中指定的版本之間所有 OpenGL ES dEQP 測試。
[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 測試分成多個測試清單，每個清單都有相關的日期/版本。這些位於 external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt 的 Android 原始碼樹狀結構中。如果裝置在自行回報的層級支援 Vulkan，即表示裝置通過此層級和更早的所有測試清單，都能通過 dEQP 測試。

如果裝置實作項目支援 Vulkan 1.0 以上版本，程式碼就會：

[C-1-1] 必須使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能旗標回報正確的整數值。
[C-1-2] 請務必列舉至少一個 Vulkan 原生 API vkEnumeratePhysicalDevices() 適用的 VkPhysicalDevice。
[C-1-3] 必須為每個列舉的 VkPhysicalDevice 完全實作 Vulkan 1.0 API。
[C-1-4] 請務必透過 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties()，列舉應用程式套件原生程式庫目錄中名為 libVkLayer*.so 的層。
[C-1-5] 除非應用程式將 android:debuggable 屬性設為 true，否則「不得」列舉應用程式套件以外程式庫提供的層，或提供其他追蹤或攔截 Vulkan API 的方法。
[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] 必須回報透過 android.software.vulkan.deqp.level 功能旗標支援的最高 Vulkan dEQP 測試版本。
[C-1-9] 至少必須支援 132317953 版 (自 2019 年 3 月 1 日起)，如 android.software.vulkan.deqp.level 功能標記中所述。
[C-1-10] 必須在 132317953 版本與 android.software.vulkan.deqp.level 功能標記中指定的版本之間，通過測試清單中的所有 Vulkan dEQP 測試。
[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 vkEnumeratePhysicalDevices() 列舉任何 VkPhysicalDevice。

如果裝置實作項目支援 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，詳情請見 Android SDK 說明文件。

7.1.4.4 2D 圖形加速

Android 提供一種機制，可讓應用程式宣告要使用資訊清單標記 android:hardwareAccelerated 或直接 API 呼叫，在應用程式、活動、視窗或檢視畫面層級啟用 2D 圖形的硬體加速功能。

裝置實作方式：

[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] 在 CIE 1931 xyY 空間中，「必須」具備完全覆蓋 sRGB 色域的螢幕。
[C-1-3] 在 CIE 1931 xyY 中，「必須」具備網格大小至少為 90% 的 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] 必須按照 Android SDK 說明文件所述，實作 DisplayManager 系統服務和 API。

7.2. 輸入裝置

裝置實作方式：

[C-0-1] 必須包含在 UI 元素之間導覽的輸入機制，例如觸控螢幕或非觸控式導覽。

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-key) 中任一指定格式的硬體鍵盤。
應加入其他螢幕鍵盤實作。
可提供實體鍵盤。

7.2.2。非觸控瀏覽

Android 支援 D-pad、軌跡球和滾輪做為非觸控瀏覽的機制。

裝置實作方式：

[C-0-1] 必須回報 android.content.res.Configuration.navigation 的正確值。

如果裝置的實作方式缺少非觸控式導覽，就會：

[C-1-1] 「必須」針對選取及編輯文字提供合理的替代使用者介面機制，與輸入管理引擎相容。上游 Android 開放原始碼實作包含適合與缺少非觸控瀏覽輸入裝置使用的選取機制。

7.2.3. 瀏覽鍵

Home、Recents 和 Back 函式通常透過與專屬實體按鈕的互動，或觸控螢幕的不同部分提供，對於 Android 導覽範例而言至關重要，因此是裝置實作項目的關鍵要素：

[C-0-1] 如果已安裝的應用程式具備使用 ACTION=MAIN 和 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER 設置活動的 <intent-filter> 應用程式，則必須符合使用者需求，才能啟動該應用程式，以便執行電視裝置實作。首頁功能「必須」做為這項使用者預設用途的機制。
「應」提供「最近」和「返回」功能的按鈕。

如果有提供「首頁」、「最近使用」或「返回」功能，請按照下列步驟操作：

[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_DOWN 事件，則在系統手勢開始攔截觸控後，必須傳送 MotionEvent.ACTION_CANCEL 事件給前景應用程式。
[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.BEHAVIS_SHOW_BYIENT_BARS_，
[C-7-4] 如果前景應用程式實作了 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT，或 WindowInsetsController.BEHAVIOR_SHOW_BYIENT_BARS_，

如果提供返回導覽函式，且使用者取消返回手勢，則：

[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 API 欄位回報 TOUCHSCREEN_FINGER。
[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] 必須針對 Configuration.touchscreen API 欄位回報 TOUCHSCREEN_NOTOUCH。

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 用量²	Android 按鈕
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
是¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-Pad¹ D-Pad¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-Pad 向左1 D-Pad 向右鍵¹	0x01 0x0039³	AXIS_HAT_X⁴
左肩按鈕¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
右肩按鈕¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
按一下左鍵¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
按一下滑鼠右鍵¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
背面¹	0x0c 0x0224	KEYCODE_BACK (4)

1 個 KeyEvent

2 您必須在遊戲板 CA (0x01 0x0005) 中宣告上述 HID 用法。

3 這個用量的邏輯下限為 0、邏輯上限為 7、實體下限為 0、實體最大 315、單位 (單位為度)，以及 4 份報表。邏輯值定義為離垂直軸順時針旋轉；例如，邏輯值 0 表示沒有旋轉，按下向上按鈕，1 邏輯值 1 則代表旋轉 45 度，同時按下上下鍵。

4 MotionEvent

類比控制項¹	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 說明文件和感應器中的 Android 開放原始碼說明文件實作該 API。

裝置實作方式：

[C-0-1] 必須根據 android.content.pm.PackageManager 類別準確回報感應器是否存在。
[C-0-2] 必須透過 SensorManager.getSensorList() 和類似方法傳回支援的感應器清單。
[C-0-3] 必須對所有其他感應器 API 採取合理行為 (例如，在應用程式嘗試註冊事件監聽器時視情況傳回 true 或 false；如果沒有對應的感應器，則不呼叫感應器事件監聽器等等)。

如果裝置實作項目包含特定的感應器類型，且為第三方開發人員提供對應的 API，就會：

[C-1-1] 必須根據 Android SDK 說明文件中定義的各個感應器類型，使用相關國際單位 (指標) 值回報所有感應器測量結果。
[C-1-2] 必須回報感應器資料，延遲時間最長為 100 毫秒 + 2 * sample_time；如果是感應器串流，延遲時間最長為 0 毫秒，則在應用程式處理器處於啟用狀態時。此延遲未包含任何篩選延遲。
[C-1-3] 必須在感應器啟用的 400 毫秒 + 2 * 的情況下，回報第一個感應器樣本。此樣本的準確率為 0，可以接受。
[C-1-4] 如果 Android SDK 說明文件指出的 API 屬於連續感應器，裝置實作「必須」持續提供週期性資料樣本，且時基誤差不得超過 3%；其中時基誤差的定義為連續事件回報的時間戳記值差異的標準差。
[C-1-5] 必須確保感應器事件串流「不得」阻止裝置 CPU 進入暫停狀態或喚醒暫停狀態。
[C-1-6] 必須按照 Android SDK 說明文件中定義的奈秒回報事件時間，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘保持同步。
[C-SR-1] 強烈建議將時間戳記同步處理錯誤維持在 100 毫秒以下，並且應該將時間戳記同步處理錯誤維持在 1 毫秒以下。
如果啟用多個感應器，耗電量不應超過個別感應器回報的耗電量總和。

以上清單僅列舉部分內容；Android SDK 和感應器上的 Android 開放原始碼說明文件所記錄的行為皆視為合法授權。

如果裝置實作項目包含特定的感應器類型，且為第三方開發人員提供對應的 API，就會：

[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 API 中詳述的 Android 感應器座標系統。
[C-1-4] 必須能夠根據任何軸上的重力(4 公克) 或更多重力量測量
[C-1-5] 必須採用至少 12 位元的解析度。
[C-1-6] 標準差不得大於 0.05 m/s^，標準差應以每軸計算標準差，計算期間至少 3 秒收集到的樣本數，且至少要達到 3 秒，才能達到最快的取樣率。
回報的事件大小必須至少為 200 Hz。
解析度至少要有 16 位元。
如果生命週期內的特性會隨生命週期變化並補償，使用時應進行校正，並在裝置重新啟動前保留補償參數。
應針對溫度獲得補償。

如果裝置導入方式包含 3 軸式加速度計，就會發生以下情形：

[C-2-1] 必須導入及回報 TYPE_ACCELEROMETER 感應器。
[C-SR-4] 強烈建議實作 TYPE_SIGNIFICANT_MOTION 複合感應器。
[C-SR-5] 強烈建議導入及回報 TYPE_ACCELEROMETER_UNCALIBRATED 感應器。我們會強烈建議 Android 裝置符合這項規定，以便升級至日後的平台版本，此版本可能為「必要」。
請務必按照 Android SDK 文件所述，實作 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。

如果裝置導入的加速計少於 3 軸，就會：

[C-3-1] 必須導入及回報 TYPE_ACCELEROMETER_LIMITED_AXES 感應器。
[C-SR-6] STRONGLY_RECOMMENDED 實作 TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED 感應器並回報。

如果裝置實作項目包含 3 軸式加速度計，且已實作任何 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR 和 TYPE_STEP_COUNTER 複合感應器，請按照下列步驟操作：

[C-4-1] 兩者的耗電量總和必須小於 4 毫瓦。
裝置處於動態或靜態狀態時，每個音訊值應低於 2 mW 和 0.5 mW。

如果裝置實作包含 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 API 中詳述的 Android 感應器座標系統。
[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。
如果以 10 Hz 註冊感應器為批次模式，耗電量應低於 3 mW。

7.3.3. GPS

裝置實作方式：

[C-SR-1] 強烈建議你加入 GPS/GNSS 接收器。

如果裝置實作項目包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，就會：

[C-1-1] 透過 LocationManager#requestLocationUpdate 要求時，必須支援至少 1 Hz 的位置輸出功能。
[C-1-2] 必須能在連上 0.5 Mbps 或更快的數據連線速度時，在 10 秒內 (收到強訊號、對多徑執行過失、HDOP < 2) 來判斷位置。通常使用某種輔助或預測 GPS/GNSS 技術來盡可能縮短 GPS/GNSS 鎖定時間 (輔助資料包括參考時間、參考位置和衛星電話/時鐘)。
- [C-1-6] 進行這類位置計算後，裝置實作「必須」在 5 秒內 (在開放天空、重新啟動位置資訊要求時) 判斷其位置，即使在未連線至數據連線的情況下及/或重新開機後提出後續要求亦然。
判斷地點後，在開闊的天空中以加速或移動的每秒平方公尺小於 1 公尺：
- [C-1-3] 必須能夠判斷位置在 20 公尺以內，且速度在每秒 0.5 公尺以內，且時間至少為 95%。
- [C-1-4] 必須同時透過至少 8 顆星座的衛星，透過 GnssStatus.Callback 同時追蹤及回報情況。
- 至少要能夠同時追蹤至少 24 個來自多個星座的衛星，例如 GPS + 至少一種 Glonass、北斗、Galileo 其中之一。
[C-SR-2] 強烈建議在緊急電話通話期間，繼續透過 GNSS Location Provider API 繼續透過 GNSS Location Provider API 提供正常的 GPS/GNSS 定位資訊。
[C-SR-3] 強烈建議「強烈建議」針對追蹤的所有星座 (如 GnssStatus 訊息所回報) 回報 GNSS 測量結果，但 SBAS 除外。
[C-SR-4] 強烈建議使用記錄 AGC 和 GNSS 測量頻率。
[C-SR-5] 強烈建議將每個 GPS/GNSS 位置的所有準確估算結果 (包括方位、速度和產業資料) 回報給我們。
[C-SR-6] 強烈建議在找到 GNSS 測量結果後立即回報，即使系統尚未回報 GPS/GNSS 計算出的位置也一樣。
[C-SR-7] 強烈建議「不要」回報 GNSS 虛擬範圍和虛擬範圍比率。在判斷地點後，如果是靜止或移動的每秒平方小於 0.2 公尺，就足以在每秒 20% 以內，且速度至少在每秒 0.2 公尺範圍內計算 GNSS 虛擬範圍和虛擬範圍速率。

7.3.4。陀螺儀

裝置實作方式：

[C-SR-1] 強烈建議你加入陀螺儀感應器。

如果裝置導入作業包含陀螺儀，這項功能會：

[C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
[C-1-4] 必須採用 12 位元以上的解析度。
[C-1-5] 必須計算溫度。
[C-1-6] 在使用時必須進行校準及補償，並在裝置重新啟動時保留補償參數。
[C-1-7] 變異數不得大於 1e-7 rad^2/s^2/Hz (每 Hz 變異數，或每 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] STRONGLY_RECOMMENDED 實作 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 API。

7.3.7。相框模式

實作裝置可能包括光度感應器 (環境光度感應器)，

7.3.8。鄰近感應器

實作裝置可能包含鄰近感應器。

如果裝置實作項目包含鄰近感應器，但只會回報「附近」或「遠」讀取的二進位讀數，則會：

[C-1-1] 「必須」以與螢幕相同的方向測量物體的距離。也就是說，鄰近感應器必須朝向鄰近感應器來偵測靠近畫面的物件，因為這個感應器類型的主要意圖是偵測使用者正在使用的手機。如果裝置實作項目包含具有任何其他方向的鄰近感應器，就「不得」透過此 API 存取。
[C-1-2] 準確度必須達到 1 位元以上。
[C-1-3] 大約使用 0 公分做為近讀數，距離讀數不得超過 5 公分
[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 公克和 +16 公克之間的測量範圍。
- 必須採用至少 2048 LSB/g 的測量解析度。
- 測量頻率不得低於 12.5 Hz。
- 測量頻率上限為 400 Hz；應支援 SensorDirectChannel RATE_VERY_FAST。
- 測量噪音必須超過 400 μg/√Hz。
- 這個感應器必須實作至少 3,000 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
- 批次耗電量不得低於 3 毫瓦。
- [C-SR-1] 強烈建議採用至少 80% 的均衡頻率和白色雜訊光譜，才能有 3dB 測量頻寬。
- 應在房間溫度下進行隨機步行，且加速度不要低於 30 μg √Hz。
- 應該有偏誤變化，而不是溫度 ≤ +/- 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] 強烈建議採用至少 80% 的均衡頻率和白色雜訊光譜，才能有 3dB 測量頻寬。
- 應該在會議室溫度的情況下，進行低於 0.001 °/s √Hz 的隨機步行速率。
- 應該有偏誤變化，而不是溫度 ≤ +/- 0.05 °/ s / °C。
- 應有靈敏度變化，但溫度應為 ≤ 0.02% / °C。
- 應採用最佳適配線非線性性，且不超過 0.2%。
- 雜訊密度必須小於 0.007 °/s/√Hz。
- 裝置靜止時，應在溫度範圍 10 ~ 40 °C 中發生小於 0.002 rad/s 的校正錯誤。
- 應靈敏度小於 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] 如果報表速率為 50 Hz 以上，強烈建議使用從 1 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 mW；當裝置移動時，若同時啟用下列任何感應器組合，則耗電量不得高於 2.0 mW：
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] 可能具有 TYPE_PROXIMITY 感應器，但盡可能「必須」至少將緩衝區功能設為 100 個感應器事件。

請注意，本節的所有耗電量要求，都不包含應用程式處理器的耗電量。其中包含整個感應器鏈產生的電源，例如感應器、任何輔助電路、任何專用感應器處理系統等。

如果裝置的實作方式提供感應器直接支援，請採取下列做法：

[C-3-1] 必須使用 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API，正確宣告對直接管道類型和直接報表率層級的支援。
[C-3-2] 凡是宣告支援感應器直接通道的感應器，都必須支援至少兩種感應器直接通道類型之一。
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
針對以下類型的主要感應器 (非喚醒變化版本)，支援透過感應器直接管道回報事件：
- 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 級 (原為簡單性)。這種分類會決定生物特徵辨識感應器必須與平台和第三方應用程式連接的功能。感應器必須符合下列額外規定，才能將其歸類為「第 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) 方法的整數常數，但不包括在 Authenticators 和其中任何組合中記錄為公開常數的情況。
[C-4-3] 必須在採用第 3 級或第 2 級生物特徵辨識的裝置上實作 ACTION_BIOMETRIC_ENROLL 動作。這個動作只「必須」顯示第 3 級或第 2 級生物特徵辨識的註冊進入點。

如果裝置實作支援被動生物特徵辨識，就會：

[C-5-1] 在預設情況下，必須執行額外的確認步驟 (例如按下按鈕)。
[C-SR-1] 強烈建議你提供可讓使用者覆寫應用程式的偏好設定，並一律需要搭配的確認步驟。
[C-SR-2] 強烈「建議」採用已保護確認動作的安全機制，讓作業系統或核心入侵行為無法假冒攻擊。舉例來說，這表示根據實體按鈕的確認動作是透過安全元素 (SE) 的純輸入/輸出 (GPIO) 接腳轉送，該接腳無法透過實體按鈕按下以外的任何方式驅動。
[C-5-2] 必須另外實作與 setConfirmationRequired(boolean) 相對應的隱含驗證流程，後者可以設定在此登入流程中使用。

如果裝置實作的裝置有多個生物特徵辨識感應器，就會：

[C-SR-3] 強烈建議每個驗證都只確認一項生物特徵辨識 (例如，如果裝置同時支援指紋與臉孔感應器，應在確認任一種感應器後傳送 onAuthenticationSucceeded)。

為了讓裝置實作允許第三方應用程式存取 KeyStore 金鑰，程式碼必須：

[C-6-1] 必須符合本節中定義的第 3 級規定。
[C-6-2] 如果驗證需要 BIOMETRIC_STRONG，或者是透過 CryptoObject 叫用驗證，則「必須」顯示第 3 級生物特徵辨識。

如要將生物特徵辨識感應器視為「第 1 級」(先前稱為「便利」) 的裝置實作項目，請執行以下操作：

[C-1-1] 不正確的接受率必須低於 0.002%。
[C-1-2] 必須說明此模式的安全性可能低於高強度 PIN 碼、解鎖圖案或密碼，並清楚列舉啟用風險。如果假冒和攻擊者接受率高於 Android 生物特徵辨識測試通訊協定的 7%，則必須明確說明啟用此模式的風險。
[C-1-9] 進行生物特徵辨識驗證時，必須要求使用者提供建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)，且生物特徵辨識驗證的輪詢時間不得短於九十秒；即假試用是具有充分擷取品質 (BIOMETRIC_ACQUIRED_GOOD) 的試驗結果與已註冊的生物特徵辨識不符。
[C-SR-4] 如果 Android 生物特徵辨識測試通訊協定的測量結果高於 7%，強烈建議 [C-1-9] 中指定生物特徵辨識驗證的誤判試驗總數。
[C-1-3] 必須對生物特徵辨識驗證進行頻率限制嘗試：如果假使試行必須具有足夠的擷取品質 (BIOMETRIC_ACQUIRED_GOOD)，且不符合已註冊的生物特徵辨識，就要視為驗證嘗試。
[C-SR-5] 大量「建議」提出五次假造的生物特徵辨識驗證，並要求針對每 [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) Android 等級 BD 通訊協定的偽證接受率 (以 Android 等級 40% 為單位) 且高於 40%。
[C-1-4] 必須讓使用者確認現有或新增受到 TEE 保護的裝置憑證 (PIN 碼/圖案/密碼)，以防止新增生物特徵辨識功能；Android 開放原始碼專案實作項目為架構提供機制。
[C-1-5] 移除使用者帳戶時 (包括透過恢復原廠設定)，「必須」徹底移除使用者的所有可識別生物特徵辨識資料。
[C-1-6] 必須遵循該生物特徵辨識的個別標記 (即 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS)。
[C-1-7] 必須每 24 小時最多詢問使用者一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。注意：升級搭載 Android 9 以下版本的裝置，必須每 72 小時最多詢問一次主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。
[C-1-8] 只要符合下列任一條件，就必須要求使用者提供建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 或第 3 級 (STRONG) 生物特徵辨識：
- 4 小時的閒置逾時期限，或
- 3 次生物特徵辨識驗證失敗。
- 一旦成功確認裝置憑證，閒置逾時期限和驗證失敗次數就會重設。注意：如果是搭載 Android 9 以下版本的裝置升級，就不受 C-1-8 的規範。
[C-SR-7] 強烈建議使用 Android 開放原始碼專案提供的架構中的邏輯，對新裝置強制執行 [C-1-7] 和 [C-1-8] 中指定的限制。
[C-SR-8] 強烈建議將誤判率低於 10% (根據裝置測量而得)。
[C-SR-9] 強烈建議將延遲時間控制在 1 秒以下，從偵測到生物特徵辨識的時間到螢幕解鎖為止，而且每次註冊的生物特徵辨識功能都會發揮作用。

如果想將生物特徵辨識感應器視為類別 2 (先前稱為「弱」)，裝置實作項目會：

[C-2-1] 必須符合上述第 1 級的所有規定。
[C-2-2] 假冒和冒名錄接受率不得超過 20%，同時 (1) 等級 A 簡報攻擊工具 (PAI) 物種的欺騙及冒名接受率不得高於 20%，以及 (2) 測試等級 BPAI 物種接受率的假裝接受率不得超過 30%
[C-2-3] 「必須」在 Android 使用者或核心空間以外的獨立執行環境 (例如受信任的執行環境 (TEE)) 中執行生物特徵辨識比對，或是在晶片上設有安全管道到獨立的執行環境。
[C-2-4] 所有識別資料都必須經過加密及加密驗證，才能在獨立執行環境外取得、讀取或修改，也不能使用安全管道加密獨立執行環境的晶片 (如 Android 開放原始碼專案網站的實作指南所述)。
[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) 測試等級為比 20% 等級的 Bio 通訊協定規格接受率不高於 20%。
[C-3-4] 必須每 72 小時最多詢問使用者一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。
[C-3-5] 如果你已在裝置上重新註冊第 3 級生物特徵辨識，就必須重新產生這類 ID 的驗證器 ID。
[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] 必須支援至少 2 個介於 0 到 360 度 (包括 0 到 360 度) 之間的讀數。
[C-1-3] 必須傳回 getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) 的 Wakeup 感應器。

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 支援。
建議您在緊急電話期間 (無論 SetAllowedNetworkTypeBitmap() 設定的網路類型為何) 允許所有可用行動服務類型 (2G、3G、4G、5G 等)。

如果裝置實作項目不包含電話硬體，他們會：

[C-2-1] 「必須」導入完整的 API，免人工管理。

如果裝置實作支援 eUICC 或 eSIM 卡/內嵌 SIM 卡，且含有專屬機制，讓第三方開發人員使用 eSIM 卡功能，那麼第三方開發人員就能使用：

[C-3-1] 必須宣告 android.hardware.telephony.euicc 功能旗標。

如果裝置導入方式未將系統屬性 ro.telephony.iwlan\_operation\_mode 設為「舊版」，那麼：

[C-4-1] 當同一個 NetworkRegistrationInfo 執行個體 NetworkRegistrationInfo#getTransportType() 回報為「TRANSPORT_TYPE_WWAN」時，「不得」透過 NetworkRegistrationInfo#getAccessNetworkTechnology() 回報「NETWORK_TYPE_IWLAN」。

如果裝置實作支援同時為多媒體電話服務 (MMTEL) 和互動式通訊服務 (RCS) 功能註冊單一 IP 多媒體子系統 (IMS)，且應符合行動電信業者規定，對所有 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] 在向使用者顯示及控制 SIM 卡資訊的所有可用用途中，必須向所有具備同等群組 UUID 的 SubscriptionInfo 呈現單一訂閱項目。這類用途包括符合 Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS 或 EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS 的設定介面。
[C-6-6] 不得在可供設定或控制 SIM 卡設定的任何使用者可見用途中，顯示或允許控制具有非空值群組 UUID 和機會位元的任何 SubscriptionInfo。

如果裝置實作項目回報 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] 如果嘗試以偏好或允許的網路類型位元遮罩設定任何 3GPP2 網路類型，一律必須擲回 IllegalArgumentException。
[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] 必須實作已封鎖的電話號碼管理 UI，並透過 TelecomManager.createManageBlockedNumbersIntent() 方法傳回的意圖開啟該 UI。
[C-1-7] 「不得」允許次要使用者在裝置上查看或編輯封鎖的號碼，因為 Android 平台會假設主要使用者能夠完整控管裝置上的電話服務、單一執行個體。次要使用者「必須」隱藏所有封鎖相關的使用者介面，且必須遵守封鎖清單。
當裝置更新至 Android 7.0 時，應將已封鎖的號碼遷移至供應器。
預先安裝的撥號應用程式應讓使用者有足夠的負擔，以便顯示已封鎖的通話。

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] 強烈建議在第三方應用程式將 PhoneAccount 上的 EXTRA_LOG_SELF_MANAGED_CALLS 額外鍵設為 true 時，預先載入預設撥號應用程式，該應用程式會在其通話記錄中顯示通話記錄項目和第三方應用程式名稱。
[C-SR-3] 強烈建議為 android.telecom API 處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，如下所示：
- 在通話期間偵測到短暫按下按鍵事件時，呼叫 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] 必須實作 SDK 說明文件中所述的多點傳播 API。
[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] 強烈建議在建立關聯及建立關聯的情況下，隨機針對所有與存取點 (AP) 之間任何 STA 通訊所用的來源 MAC 位址隨機進行隨機化。
- 裝置「必須」針對與其通訊的每個 SSID (Passpoint 的 FQDN) 使用不同的隨機 MAC 位址。
- 裝置「必須」為使用者提供選項，讓使用者透過非隨機和隨機選項控制每個 SSID 的隨機化作業 (Passpoint 的 FQDN)，以及「必須」對新 Wi-Fi 設定隨機指派的預設模式。
[C-SR-2] 強烈建議針對自己建立的任何 AP 使用隨機的 BSSID。
- MAC 位址「必須」隨機化，且會保留 AP 使用的 SSID。
- 「裝置」可能提供使用者停用這項功能的選項。如有提供這個選項，則「必須」預設為啟用。

如果裝置實作項目支援 IEEE 802.11 標準中定義的 Wi-Fi 省電模式，就會：

每當應用程式透過 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() API 取得 WIFI_MODE_FULL_HIGH_PERF 鎖定或 WIFI_MODE_FULL_LOW_LATENCY 鎖定，且鎖定處於啟用狀態時，都應關閉 Wi-Fi 省電模式。
[C-3-2] 當裝置處於 Wi-Fi 低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 模式時，裝置和存取點之間的平均往返延遲時間必須小於 Wi-Fi 高音頻鎖定 (WIFI_MODE_FULL_HIGH_PERF) 模式的延遲時間。
[C-SR-3] 只有在取得低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 且生效後，才能盡可能縮短 Wi-Fi 往返延遲時間。

如果裝置實作項目支援 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] 必須按照 SDK 說明文件中所述實作對應的 Android API。
[C-1-2] 必須回報 android.hardware.wifi.direct 硬體功能。
[C-1-3] 必須支援一般 Wi-Fi 運作。
[C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。
[C-SR-1] 強烈建議為所有新格式的 Wi-Fi Direct 連線隨機隨機化來源 MAC 位址。

7.4.2.2。Wi-Fi 通道直接連結設定

裝置實作方式：

應納入 Android SDK 說明文件中所述的Wi-Fi 通道直接連結設定 (TDLS) 支援。

如果裝置實作項目支援 TDLS 且 WiFiManager API 啟用 TDLS，應用程式會：

[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] 必須按照 SDK 說明文件中所述實作 WifiAwareManager API。
[C-1-2] 必須宣告 android.hardware.wifi.aware 功能標記。
[C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
[C-1-4] 每次啟用 Wi-Fi Aware 時，都必須隨機對 Wi-Fi Aware 管理介面位址隨機執行，範圍不得低於 30 分鐘，且除非 Wi-Fi Aware 處於啟用狀態 (若啟用感知範圍動作，或感知資料路徑處於啟用狀態，則不需要隨機化)。

如果裝置實作項目包括第 7.4.2.5 節所述的 Wi-Fi Aware 和 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] 必須按照 SDK 說明文件中所述，實作 Passpoint 相關 WifiManager API。
[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] 必須根據無線基地台 2.0 R3 規格所述處理 AAA 伺服器憑證。
[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] 必須按照 SDK 說明文件中所述實作 WifiRttManager API。
[C-1-2] 必須宣告 android.hardware.wifi.rtt 功能標記。
[C-1-3] 必須針對執行 RTT 的 Wi-Fi 介面 (在執行 RTT 的 Wi-Fi 介面) 時，隨機化來源 MAC 位址，且這些位址與存取點沒有關聯。
[C-1-4] 務必在第 68 百分之一的 80 MHz 頻寬範圍內，準確達 2 公尺以內 (根據累積分佈函式計算而得)。
[C-SR-1] 強烈建議在第 68 個百分位數 (以累積分佈函式計算) 的 1.5 公尺內，正確回報頻寬在 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 Easy Connect 支援，並向第三方應用程式公開相關功能，他們必須：

[C-1-1] 必須讓 WifiManager#isEasyConnectSupported() 方法傳回 true。

7.4.2.8。企業 Wi-Fi 伺服器憑證驗證

如果未驗證 Wi-Fi 伺服器憑證或未設定 Wi-Fi 伺服器網域名稱，裝置會實作：

[C-SR-1] 強烈建議不要向使用者提供在「設定」應用程式中手動新增企業 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] 必須啟用 SDK 說明文件和 android.bluetooth 中所述的 GATT (一般屬性設定檔) 型藍牙 API。
[C-3-3] 請務必回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，指出是否已實作 ScanFilter API 類別的篩選邏輯。
[C-3-4] 請務必回報 BluetoothAdapter.isMultipleAdvertisementSupported() 的正確值，以指出是否支援低能源廣告。
[C-3-5] 必須實作可撤銷的私人位址 (RPA) 逾時時間不得超過 15 分鐘，並在逾時時旋轉地址，以保護使用者隱私。為避免時間攻擊，逾時間隔也必須在 5 到 15 分鐘之間隨機進行。
實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。
應支援將批次掃描卸載到藍牙晶片組。
應支援至少有 4 個版位的多廣告。

如果實作的裝置支援藍牙 LE，並使用藍牙 LE 掃描位置，請按照下列步驟操作：

[C-4-1] 必須為使用者提供需求，以啟用/停用透過 System API BluetoothAdapter.isBleScanAlwaysAvailable() 讀取值的功能。

如果裝置實作項目支援藍牙 LE 和助聽器設定檔 (如「使用藍牙 LE 助聽器音訊支援」一節所述)，則：

[C-5-1] 必須針對 BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID) 傳回 true。

如果裝置的實作支援藍牙或藍牙低功耗功能，則：

[C-6-1] 除非要求的應用程式根據目前的前景/背景狀態，通過 android.permission.ACCESS_FINE_LOCATION 權限檢查，否則請限制存取任何可能用來推導裝置位置的藍牙中繼資料 (例如掃描結果)。

如果裝置實作項目支援藍牙或藍牙低功耗，且應用程式資訊清單並未加入開發人員的宣告，指出他們並非透過藍牙取得位置資訊，則：

[C-6-2] 必須限制 android.permission.ACCESS_FINE_LOCATION 後方的藍牙存取權。

如果裝置實作針對 BluetoothAdapter.isLeAudioSupported() API 傳回 true，就會：

[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 單點傳播用戶端。

如果裝置實作針對 BluetoothAdapter.isLeAudioBroadcastSourceSupported() API 傳回 true，就會：

[C-8-1] 單一 BIG 中至少須支援 2 個 BIS 連結。
[C-8-2] 必須同時啟用 BAP 廣播來源和 BAP 廣播助理。
[C-8-3] 必須支援 LE 定期廣告。

如果裝置實作針對 BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API 傳回 true，就會：

[C-9-1] 必須支援 PAST (定期廣告同步傳輸)。
[C-9-2] 必須支援 LE 定期廣告。

如果裝置實作項目宣告 FEATURE_BLUETOOTH_LE，就會：

[C-10-1] 在近視環境中透過 ADVERTISE_TX_POWER_HIGH 傳輸的參考裝置時，其 RSSI 測量值必須落在 +/-9dB 內，兩者距離必須在 1 公尺的範圍內。
[C-10-2] 必須加入 Rx/Tx 修正來減少每管道偏差的情況，讓三個通道 (如果使用多個) 的測量結果相差 95%。
[C-SR-2] 強烈建議「不要」測量及補償 Rx 偏移，確保 BLE RSSI 與在 ADVERTISE_TX_POWER_HIGH 傳輸的參考裝置相距 1 公尺 +/-10 dB，且裝置方向為「平行平面」，且螢幕朝向相同方向的螢幕。
[C-SR-3] 強烈建議「極力」評估及補償 Tx 偏移量，確保從位於 1 公尺距離的參考裝置進行掃描時，在 ADVERTISE_TX_POWER_HIGH 進行傳輸時，裝置會朝向平行平面的方向朝向同一方向傳輸，藉此確保 BLE RSSI 的中位數為 -60dBm +/-10 dB。

強烈建議您遵循「Presence Calibration」中指定的評估設定步驟。

如果裝置的實作支援藍牙 5.0 版，就會發生以下情形：

[C-SR-4] 強烈建議你為下列項目提供支援：
- 低 200 萬階段
- LE 轉碼器 PHY
- LE 廣告額外資訊
- 定期廣告
- 至少 10 個廣告集
- 至少 8 個 LE 並行連線。每個連線都能屬於任一連線拓撲角色。
- LE Link 層隱私權
- 「解析清單」大小至少要有 8 個項目

7.4.4。近距離無線通訊

裝置實作方式：

應包括近距離無線通訊 (NFC) 專用的收發機和相關硬體。
[C-0-1] 即使類別不支援 NFC 或宣告 android.hardware.nfc 功能，因為類別代表通訊協定獨立資料表示法格式，也必須導入 android.nfc.NdefMessage 和 android.nfc.NdefRecord API。

如果裝置實作項目包含 NFC 硬體，且預計提供給第三方應用程式使用，就會執行以下動作：

[C-1-1] 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
必須能夠透過下列 NFC 標準讀取和寫入 NDEF 訊息，如下所示：
[C-1-2] 必須能夠以下列 NFC 標準做為 NFC 論壇讀取者/寫入者 (根據 NFC 論壇技術規格進行操作)
- 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] 強烈建議能夠根據下列 NFC 標準讀取和寫入 NDEF 訊息以及原始資料。請注意，雖然 NFC 標準明確表示「建議做法」，但未來版本的相容性定義將改為「必須」。這些標準在這個版本中是選用項目，但在日後推出的版本中也是必要條件。無論現有和新裝置搭載此 Android 版本，我們都強烈建議你立即符合這些規定，以便升級至未來的平台版本。
[C-1-13] 在 NFC 探索模式下，「必須」輪詢所有支援的技術。
當裝置處於啟用狀態且螢幕鎖定時，應使用 NFC 探索模式。
應能夠讀取 Thinfilm NFC 條碼產品的條碼和網址 (如果經過編碼)。

請注意，公開連結不適用於上述 JIS、ISO 和 NFC Forum 規格。

Android 支援 NFC 主機卡片模擬 (HCE) 模式。

如果裝置實作項目包含可支援 HCE (適用於 NfcA 和/或 NfcB) 的 NFC 控制器晶片組，並支援應用程式 ID (AID) 轉送功能，則裝置 ID 支援路徑如下：

[C-2-1] 必須回報 android.hardware.nfc.hce 功能常數。
[C-2-2] 必須支援 Android SDK 中定義的 NFC HCE API。

如果裝置實作項目包含支援 NfcF HCE 的 NFC 控制器晶片組，並為第三方應用程式實作這項功能，應用程式會：

[C-3-1] 必須回報 android.hardware.nfc.hcef 功能常數。
[C-3-2] 必須實作 Android SDK 中定義的 NfcF Card Emulation API。

如果裝置實作項目包括本節所述的一般 NFC 支援，並在讀取者/寫入者角色中支援 MIFARE 技術 (MIFARE Classic、MIFARE Ultralight、NDEF)，則可：

[C-4-1] 必須按照 Android SDK 的說明實作對應的 Android API。
[C-4-2] 「必須」透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這並非標準的 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 網路堆疊，並支援使用代管 API (例如 java.net.Socket 和 java.net.URLConnection) 和原生 API (例如 AF_INET6 通訊端) 的 IPv6 通訊。
[C-0-3] 預設必須啟用 IPv6。
- 「必須」確保 IPv6 通訊穩定做為 IPv4，例如：
  - [C-0-4] 必須在打盹模式下維持 IPv6 連線。
  - [C-0-5] 頻率限制「不得」會造成裝置在符合 IPv6 標準的情況下，使用 RA 生命週期至少 180 秒的任何網路失去 IPv6 連線。
[C-0-6] 連線至 IPv6 網路時，「必須」為第三方應用程式提供直接 IPv6 連線的直接連線功能，且不得在裝置上在本機進行任何形式的位址或通訊埠轉譯。Socket#getLocalAddress 或 Socket#getLocalPort 等代管 API，以及 getsockname() 或 IPV6_PKTINFO 等 NDK API，都「必須」傳回實際用於在網路上收發封包的 IP 位址和通訊埠，並且會顯示為網際網路 (Web) 伺服器的來源 IP 和通訊埠。

所需的 IPv6 支援等級取決於網路類型，如下列需求所示。

如果實作的裝置支援 Wi-Fi，就會發生以下情形：

[C-1-1] 必須「必須」支援在 Wi-Fi 連線時執行雙重堆疊和僅限 IPv6 的作業。

如果裝置實作項目支援乙太網路，他們會：

[C-2-1] 必須能在乙太網路上支援雙重堆疊和僅限 IPv6 作業。

如果裝置的實作方式支援行動數據，請按照下列步驟操作：

[C-3-1] 必須支援在行動網路上支援 IPv6 作業 (僅限 IPv6 及可能雙重堆疊)。

如果裝置導入方式支援多種網路類型 (例如包括：

[C-4-1] 當裝置同時連線至多個網路類型時，「必須」在每個網路中同時符合上述規定。

7.4.5.3。網頁認證入口

網頁認證入口是指需要登入才能取得網際網路的網路。

如果裝置實作提供完整的 android.webkit.Webview API 實作，就會：

[C-1-1] 必須在呼叫 System API ConnectivityManager#startCaptivePortalApp(Network, Bundle) 時，提供網頁認證入口應用程式來處理 ACTION_CAPTIVE_PORTAL_SIGN_IN 意圖，並顯示網頁認證入口登入頁面。
[C-1-2] 在裝置連線到任何網路類型 (包括行動網路/行動網路、Wi-Fi、乙太網路或藍牙) 時，「必須」執行網頁認證入口偵測，並支援登入。
[C-1-3] 當裝置設為使用私人 DNS 嚴格模式時，必須支援使用明文 DNS 登入網頁認證入口。
[C-1-4] 必須依據 android.net.LinkProperties.getPrivateDnsServerName 和 android.net.LinkProperties.isPrivateDnsActive 的 SDK 說明文件，使用加密的 DNS，所有未明確與網頁認證入口網站通訊的網路流量都使用加密的 DNS。
[C-1-5] 「必須」確保使用者登入網頁認證入口時，應用程式使用的預設網路 (由 ConnectivityManager.getActiveNetwork 傳回，ConnectivityManager.registerDefaultNetworkCallback，以及 Java 網路 API (例如 java.net.Socket 等) 和 Connect() 等原生 API 預設使用的網路) 都是任何其他提供網際網路連線的可用網路 (如果有的話)。

7.4.6。同步處理設定

裝置實作方式：

[C-0-1] 預設必須啟用主要自動同步處理設定，讓 getMasterSyncAutomatically() 方法傳回「true」。

7.4.7。數據節省模式

如果裝置實作項目提供計量付費連線，就會發生以下情形：

[C-SR-1] 強烈建議提供數據節省模式。

如果裝置實作項目提供數據節省模式，就會：

[C-1-1] 必須支援 ConnectivityManager 類別中的所有 API，如 SDK 說明文件中所述

如果裝置實作項目未提供數據節省模式，就會發生以下情形：

[C-2-1] 必須傳回 ConnectivityManager.getRestrictBackgroundStatus() 的值 RESTRICT_BACKGROUND_STATUS_DISABLED
[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] 必須針對含有 UICC 安全元素的裝置，透過 android.hardware.se.omapi.uicc 宣告正確的功能旗標；對於含有 eSE 安全元素的裝置，則需透過 android.hardware.se.omapi.ese 宣告正確的功能標記；對於具有 SD 為基礎的安全元素的裝置，則需要 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 無線電的應用程式 (在 NEARBY_devices 權限群組底下) 擁有 UWB_RANGING 權限。
[C-SR-1] 強烈建議你通過標準機構 (包括 FIRA、CCC 和 CSA) 所定義的相關合規性和認證測試。
- [C-1-6] 必須確保距離測量結果在距離 95% 以內，且距離為 95% 且距離非反射腔室時，兩者之間的距離不得超過 +/-15 公分。
- [C-1-7] 必須確保在參考裝置中，1 公尺的距離測量中位數介於 [0.75m, 1.25m] 內，其中地面實際距離是由雙手朝上且傾斜的 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] 凡是支援 10 位元輸出的相機裝置，都至少須支援 HLG HDR 設定檔。
[C-2-2] 必須支援 10 位元輸出，供主要後置鏡頭或主要前置鏡頭使用。
[C-SR-1] 強烈建議同時支援兩台主鏡頭的 10 位元輸出。
[C-2-3] 邏輯相機的所有 BACKWARD_COMPATIBLE 實體子相機和邏輯相機本身，都必須支援相同的 HDR 設定檔。

如果邏輯相機裝置支援實作 android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API 的 10 位元 HDR，這些裝置會執行以下動作：

[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] 除非應用程式已透過啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性來明確啟用閃光燈，否則手電筒「不得」碰到 android.hardware.Camera.PreviewCallback 例項，除非應用程式已在相機預覽介面註冊 android.hardware.Camera.PreviewCallback 例項。請注意，這項限制不適用於裝置的內建系統相機應用程式，但僅適用於使用 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 主機連接埠連接，則必須支援 USB 視訊類別 (UVC 1.0 以上版本)。
[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 提供應用程式較低層級的相機控制功能，包括高效率的零複製爆發/串流流程，以及曝光、增益、白平衡增加、色彩轉換、清除雜訊、銳化等每個影格的控制項。

在 Android 5.0 中，舊版 API 套件 android.hardware.Camera 標示為已淘汰，但應用程式應該仍可使用。實作 Android 裝置時，「必須」確保繼續如本節和 Android SDK 所述繼續支援該 API。

已淘汰的 android.hardware.Camera 類別和新版 android.hardware.camera2 套件之間通用的所有功能，「必須」在這兩個 API 中具備同等的效能和品質。舉例來說，在相同設定中，自動對焦速度和準確率必須相同，且拍攝圖像的品質必須相同。依附於兩個 API 不同語意的功能不一定要有相符的速度或品質，但應盡可能盡量達成比對。

裝置實作「必須」針對所有可用的相機，為相機相關 API 實作下列行為。裝置實作方式：

[C-0-1] 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則必須使用 android.hardware.PixelFormat.YCbCr_420_SP 做為提供給應用程式回呼的預覽資料。
[C-0-2] 在應用程式註冊 android.hardware.Camera.PreviewCallback 執行個體，且系統會呼叫 onPreviewFrame() 方法且預覽格式為 YCbCr_420_SP 時，必須使用 NV21 編碼格式，預覽格式為 YCbCr_420_SP，也就是傳遞至 onPreviewFrame() 的位元組 [] 資料。也就是說，必須預設為 NV21。
[C-0-3] 針對 android.hardware.Camera 的前置和後置鏡頭，都必須支援 YV12 格式 (如 android.graphics.ImageFormat.YV12 常數表示)。(硬體視訊編碼器和攝影機可能會使用任何原生像素格式，但裝置實作「必須」支援轉換為 YV12 格式)。
[C-0-4] 必須支援透過 android.media.ImageReader API 的 android.hardware.camera2 裝置使用 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式做為輸出內容，也就是透過 android.request.availableCapabilities 宣傳 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 的功能。
[C-0-5] 無論裝置是否具備硬體自動對焦或其他功能，都必須實作 Android SDK 說明文件中提供的完整 Camera API。舉例來說，沒有自動對焦的相機仍必須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 執行個體 (即使這與非自動對焦相機無關)。請注意，這適用於前置鏡頭；舉例來說，雖然多數前置鏡頭不支援自動對焦，但 API 回呼仍必須按照上述說明「加上假裝」。
[C-0-6] 必須識別並遵守 android.hardware.Camera.Parameters 類別和 android.hardware.camera2.CaptureRequest 類別中定義為常數的每個參數名稱。相反地，除了在 android.hardware.Camera.Parameters 中以常數記錄常數的方式，裝置實作都「不得」遵循或識別傳送至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作項目「必須」支援所有標準相機參數，且「不得」支援自訂相機參數類型。舉例來說，如果裝置的實作方式支援使用高動態範圍 (HDR) 影像技術拍攝，則「必須」支援相機參數 Camera.SCENE_MODE_HDR。
[C-0-7] 必須按照 Android SDK 中的說明，使用 android.info.supportedHardwareLevel 屬性回報適當的支援等級，並回報適當的架構功能旗標。
[C-0-8] 也必須透過 android.request.availableCapabilities 屬性宣告 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標。如果隨附的相機裝置支援此功能，則必須定義功能旗標。
[C-0-9] 每當相機拍攝新相片，並將相片項目新增至媒體儲存區時，都必須廣播 Camera.ACTION_NEW_PICTURE 意圖。
[C-0-10] 每當攝影機錄製新影片，並將照片項目新增至媒體儲存區時，都必須廣播 Camera.ACTION_NEW_VIDEO 意圖。
[C-0-11] 必須能夠透過已淘汰的 android.hardware.Camera API 存取所有相機，也能透過 android.hardware.camera2 API 存取。
[C-0-12] 必須確保臉部外觀未經過修改，包括但不限於更改任何 android.hardware.camera2 或 android.hardware.Camera API 的臉部幾何圖形、臉部膚色或臉部柔和劑。
[C-SR-1] 對於具有多個朝向同一方向的 RGB 相機裝置，強烈建議「極力推薦」支援列出功能 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 的邏輯相機裝置，包括所有面向實體的 RGB 相機。

如果裝置實作項目為第三方應用程式提供專屬相機 API，就會：

[C-1-1] 必須使用 android.hardware.camera2 API 實作這類相機 API。
可以為 android.hardware.camera2 API 提供供應商代碼和/或擴充功能。

7.5.5。相機方向

如果裝置實作方式有前置或後置鏡頭(例如：

[C-1-1] 必須清楚顯示方向，讓攝影機的長邊對齊螢幕的長邊。也就是說，如果裝置以橫向的方向拿著，相機就「必須」拍攝橫向的影像。無論裝置的自然方向為何，這都會適用，也就是適用於橫向和直向的裝置。

凡是符合下列所有條件的裝置，就不受上述規定限制：

裝置會實作可變幾何圖形的螢幕，例如折疊式或轉軸顯示螢幕。
當裝置的折疊或轉軸狀態變更時，裝置會將螢幕方向切換為橫向-primary (或相反)。

7.6. 記憶體與儲存空間

7.6.1。記憶體與儲存空間下限

裝置實作方式：

[C-0-1] 必須加入下載管理員，讓應用程式「可能」用來下載資料檔案，且「必須」能夠將大小至少為 100 MB 的個別檔案下載至預設「快取」位置。

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] 透過 MediaStore 存取這些檔案時，必須遮蓋位置中繼資料 (例如 GPS Exif 標記)，但呼叫應用程式擁有 ACCESS_MEDIA_LOCATION 權限時除外。

裝置實作方式「可能」符合上述規定，需使用下列其中一項：

使用者可存取的卸除式儲存空間，例如安全數位 (SD) 記憶卡插槽。
Android 開放原始碼計畫 (AOSP) 中實作的部分內部 (不可移除) 儲存空間。

如果裝置實作項目使用卸除式儲存空間滿足上述需求，則適用情形：

[C-1-1] 在插槽中沒有插入儲存媒介時，必須實作浮動式訊息或彈出式使用者介面警告使用者。
[C-1-2] 必須提供 FAT 格式的儲存媒介 (例如 SD 卡)，或是在購買時提供的包裝盒和其他可用材料上，這些儲存媒介必須另外購買。

如果裝置實作項目使用一部分無法移除的儲存空間滿足上述需求，則：

應使用內部應用程式共用儲存空間的 Android 開放原始碼計畫實作項目。
可以與應用程式私人資料共用儲存空間。

如果裝置實作項目具備支援 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] 這個連接埠「必須」可連線至具有標準 Type-A 或 Type-C USB 連接埠的 USB 主機。
[C-1-2] 必須透過 android.os.Build.SERIAL，在 USB 標準裝置描述元中回報 iSerialNumber 的正確值。
[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 裝置，才能與標準 C 型充電器完全互通。
[C-SR-5] 強烈建議在支援 Type-C USB 和 USB 主機模式的情況下，支援 Power Delivery 來處理資料及電源角色交換。
應支援 Power Delivery 針對高壓充電，並支援螢幕外等替代模式。
應實作 Android Open Accessory (AOA) API 和規格，如 Android SDK 說明文件中所述。

如果裝置實作項目包含 USB 連接埠並實作 AOA 規格，會執行以下動作：

[C-2-1] 必須宣告支援硬體功能 android.hardware.usb.accessory。
[C-2-2] USB 大量儲存空間級別「必須」在 USB 大量儲存裝置的介面說明 iInterface 字串結尾處加上「android」字串
不應實作 Android Open Accessory Protocol 2.0 說明文件中所述的 AOAv2 音訊。AOAv2 音訊已於 Android 8.0 版 (API 級別 26) 淘汰。

7.7.2。USB 主機模式

如果裝置實作包含支援主機模式的 USB 連接埠，就會：

[C-1-1] 必須實作 Android SDK 中記錄的 Android USB 主機 API，且必須宣告支援硬體功能 android.hardware.usb.host。
[C-1-2] 必須「必須」提供支援，才能連接標準 USB 週邊裝置，換句話說，裝置必須符合以下條件：
- 具有裝置端 C 連接埠，或是隨附傳輸線，可將裝置專屬通訊埠調整為標準 USB Type-C 連接埠 (USB Type-C 裝置)。
- 具有裝置類型 A 或隨附傳輸線，可將裝置專屬通訊埠調整為標準 USB 類型 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 連接線與連接器規格修訂版本 1.2 (適用於 USB Type-C 連接頭，或使用充電下游連接埠 (CDP) 連接器)，請參閱 USB 的下游連接埠 (CDP) 輸出電流規格。
應實作並支援 USB Type-C 標準。

如果裝置實作項目包含支援主機模式的 USB 連接埠和 USB 音訊類別，這兩者：

[C-2-1] 必須支援 USB HID 類別。
[C-2-2] 必須支援偵測及對應 USB HID 使用資料表中指定的 HID 資料欄位，以及語音指令使用要求和 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

如果裝置的實作項目包含支援主機模式的 USB 連接埠與儲存空間存取架構 (SAF)，就會：

[C-3-1] 必須辨識任何遠端連線的 MTP (媒體傳輸通訊協定) 裝置，並透過 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT 意圖存取裝置內容。.

如果裝置實作項目包含支援主機模式和 USB Type-C 的 USB 連接埠，就會：

[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 的附錄 A 所述。
請導入最適合裝置板型規格的 try.* 模型。例如手持裝置應實作 try.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] 必須根據第 7 節規定，至少實作音訊錄音 API 為免人工管理。

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
[C-1-4] 插入插頭時「必須」觸發ACTION_HEADSET_PLUG，但只有在所有聯絡人在外殼上觸碰到相關區塊時，才能觸發這個程序。
[C-1-5] 必須能夠在 32 毫米喇叭阻塞上駕駛至少 150mV ±10% 的輸出電壓。
[C-1-6] 麥克風偏壓電壓應介於 1.8V 至 2.9V 之間。
[C-1-7] 必須偵測並對應至音訊插頭上下列範圍相等範圍的按鍵碼：
- 110-180 ohm： KEYCODE_VOICE_ASSIST
[C-SR-2] 強烈建議透過 OMTP 輸出順序支援音訊插頭。
[C-SR-3] 強烈建議你透過麥克風支援立體聲耳機的音訊錄音。

如果裝置實作項目具有 4 導體 3.5 公釐音訊插孔，並支援麥克風，且將額外價值麥克風設為 1，則播送 android.intent.action.HEADSET_PLUG：

[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 的音色「必須」小於 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

[C-2-1] 講者在 18.5 kHz 至 20 kHz 的範圍內，平均的回應率不得低於 2 kHz。

7.8.4。信號完整性

裝置實作方式：

應該為手持裝置的輸入和輸出串流提供無故障的音訊訊號路徑，其定義依據為每個路徑測試一分鐘內測得的零故障事件。使用 OboeTester 的「Automated Glitch Test」進行測試。

測試時需使用音訊回送連接器 (直接用於 3.5 公釐耳機插孔)，及/或與 USB-C 轉 3.5 公釐轉接頭搭配使用。所有音訊輸出連接埠都必須測試。

OboeTester 目前支援 AAudio 路徑，因此下列組合應使用 AAudio 測試是否出現故障：

Perf 模式	共用	取樣率	In Chans	逃離冠軍
低延遲	專屬	未指定	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 的串流訊號訊號訊號 (SNR) 和 Total Harmonic Distortion (THD)。

換能器	THD 內容	得分
主要內建喇叭，使用外部參考麥克風測得	< 3.0%	>= 50 分貝
主要內建麥克風，使用外部參考喇叭進行測量	< 3.0%	>= 50 分貝
內建類比 3.5 公釐耳機插孔，使用回送轉接器進行測試	不到 1%	>= 60 分貝
手機隨附的 USB 轉接器，使用回送轉接器進行測試	< 1.0%	>= 60 分貝

7.9. 虛擬實境

Android 提供的 API 和設施可用來建構「虛擬實境」(VR) 應用程式，包括優質的行動 VR 體驗。裝置實作「必須」正確實作這些 API 和行為，如本節所述。

7.9.1。虛擬實境模式

Android 支援 VR 模式，這項功能可以處理通知的立體視覺轉譯，並在 VR 應用程式具備使用者焦點時停用單管系統 UI 元件。

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 中可用的 E 擴充功能清單，並在 E2 擴充功能清單中公開可用的擴充功能。
[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 內容的交錯顯示效果，而且不會顯示撕裂痕跡。
[C-1-9] 必須按照 NDK 中所述，為 AHardwareBuffer 旗標 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 實作支援。
[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] 強烈建議支援以 C-1-10 中指定的多個圖層和標記與格式配置 AHardwareBuffer。
[C-1-11] 必須支援以 3840 x 2160 解析度至少為 3840 x 2160 的 H.264 解碼，且壓縮後的平均頻寬為 40 Mbps (相當於 4 個 1920 x1080 且 30 fps-10 Mbps 或 10 Mbps 10 Mbps 的 2 個執行個體)。
[C-1-12] 必須支援 HEVC 和 VP9，必須能夠解碼至少 1920 x 1080 (每秒 30 個影格) 的編碼，平均壓縮為 10 Mbps，且必須能夠將 3840 x 2160 解碼為 3840 x 2160 且每秒 30 Mbps 1040 (每秒 30 Mbps 到 10 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 Data Length Extension (第 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] 不得允許任何其他使用者空間處理程序 (應用程式使用的裝置驅動程式除外)，但「可能」允許部分核心程序視需要執行。

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 節，瞭解裝置專屬的需求。

8. 效能與功率

有些最低效能和電源標準是影響使用者體驗的關鍵，並會影響開發人員開發應用程式時對基準假設的假設。

8.1. 使用者體驗一致性

當應用程式有一些最低需求，能確保應用程式和遊戲的影格速率和回應時間維持一致，即可為使用者提供流暢的使用者介面。根據第 2 節所述，視裝置類型而定，裝置的實作方式「可能」針對使用者介面延遲和工作切換有可量化的要求。

8.2. 檔案 I/O 存取效能

為應用程式私人資料儲存空間 (/data 分區) 提供一致的檔案存取效能基準，讓應用程式開發人員能設定對軟體設計有益的適當預期。視裝置類型而定，裝置實作的某些讀取和寫入作業可能會有第 2 節所述的特定需求：

依序寫入效能。計算方式如下：使用 10 MB 寫入緩衝區寫入 256 MB 檔案。
隨機寫入效能。計算方法是使用 4 KB 寫入緩衝區寫入 256 MB 檔案。
依序讀取效能。使用 10 MB 寫入緩衝區讀取 256 MB 檔案來評估。
隨機讀取效能。使用 4 KB 寫入緩衝區讀取 256 MB 檔案來評估。

8.3.省電模式

如果裝置實作項目包含 Android 開放原始碼計畫提供的改善裝置電源管理功能 (例如應用程式待命值區、打盹功能)，或擴充相關功能來套用比RESTRICTED 應用程式待命值區更嚴格的限制，則適用情形如下：

[C-1-1] 不得偏離 Android 開放原始碼計畫實作項目，例如：觸發、維護、喚醒演算法，以及「應用程式待命」和「打盹」模式下的全域系統設定或 DeviceConfig 的使用。
[C-1-2] 「不得」偏離使用 Android 開放原始碼計畫實作項目，使用全域設定或 DeviceConfig 來管理應用程式待命功能在每個值區中的應用程式工作節流、鬧鐘和網路節流。
[C-1-3] 不得偏離 Android 開放原始碼計畫實作項目，例如用於應用程式待命的應用程式待命值區數量。
[C-1-4] 必須按照「電源管理」中所述實作應用程式待命值區和打盹功能。
[C-1-5] 裝置開啟省電模式時，必須針對 PowerManager.isPowerSaveMode() 傳回 true。
[C-1-6] 「必須」提供使用者需求，以顯示所有不受應用程式待命和打盹省電模式的限制，或任何電池最佳化設定，且必須實作 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 意圖，要求使用者允許應用程式忽略電池最佳化。
[C-SR-1] 強烈建議使用者提供預設用途來啟用和停用省電功能。
[C-SR-2] 強烈建議提供使用者預設空間，讓系統顯示不受應用程式待命和打盹省電模式限制的應用程式。

如果裝置實作項目會擴充 Android 開放原始碼計畫的電源管理功能，且該擴充功能套用比稀有應用程式待命值區更嚴格的限制，請參閱第 3.5.1 節。

除了省電模式外，Android 裝置實作項目可能會實作進階設定和電源介面 (ACPI) 定義的所有 4 個休眠電源狀態。

如果裝置實作項目實作 ACPI 定義的 S4 電源狀態，就會發生以下情形：

[C-1-1] 只有在使用者執行明確操作的情況下，讓裝置處於閒置狀態 (例如蓋上裝置外蓋或關上車輛或電視的蓋蓋)，以及使用者重新啟用裝置前 (例如打開車蓋或重啟車輛或電視)，才能進入此狀態。

如果裝置實作項目實作 ACPI 定義的 S3 電源狀態，就會發生以下情形：

[C-2-1] 必須符合上述 C-1-1 標準，或者只有在第三方應用程式不需要系統資源 (例如螢幕、CPU) 時，才進入 S3 狀態。

相反地，當第三方應用程式需要系統資源時，必須如本 SDK 所述，否則必須退出 S3 狀態。

舉例來說，雖然第三方應用程式要求透過 FLAG_KEEP_SCREEN_ON 保持螢幕開啟，或透過 PARTIAL_WAKE_LOCK 讓 CPU 保持開啟，除非如 C-1-1 所述，否則裝置「不得」進入 S3 狀態，除非使用者採取明確行動，讓裝置處於停用狀態。相反地，當第三方應用程式透過 JobScheduler 實作的工作觸發，或將 Firebase 雲端通訊推送給第三方應用程式時，裝置「必須」退出 S3 狀態，除非使用者將裝置設為閒置狀態。上述示例並未涵蓋所有情況，Android 開放原始碼計畫會導入大量的喚醒信號，從此狀態觸發喚醒。

8.4. 耗電量會計

應用程式開發人員可獲得更準確的耗電量計算和報告，同時有利於改進應用程式的耗電量模式和實用工具。

裝置實作方式：

[C-SR-1] 強烈建議提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量值」，以及元件隨時間而造成的電池耗電情形 (如 Android 開放原始碼計畫網站上所述)。
[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 平台安全性模型，定義請見 Android 開發人員說明文件的 API 安全性和權限參考文件。
[C-0-2] 必須支援安裝自行簽署的應用程式，不需要任何第三方/主管機關提供額外權限/憑證。

如果裝置實作項目宣告了 android.hardware.security.model.compatible 功能，就會：

[C-1-1] 必須支援下列子節所列的規定。

9.1. 權限

裝置實作方式：

[C-0-1] 必須支援 Android 開發人員說明文件中定義的 Android 權限模型和 Android 角色模型。具體來說，這類 API 必須強制執行 SDK 說明文件中定義的每個權限和角色，也不能略過、修改或略過任何角色。
如果新的權限 ID 字串不在 android.\* 命名空間中，可以新增其他權限。
[C-0-2] 具有 PROTECTION_FLAG_PRIVILEGED 的 protectionLevel 權限。您只能向預先安裝在系統映像檔及 APEX 檔案中預先安裝的應用程式，以及每個應用程式明確加入許可清單的許可權限子集授予這項權限。Android 開放原始碼計畫實作項目符合這項規定，方法是以 system/priv-app 路徑，讀取及遵循許可清單中檔案所列的權限權限。etc/permissions/

防護等級為危險的權限即為執行階段權限。targetSdkVersion > 22 以上的應用程式在執行階段中提出要求。

裝置實作方式：

[C-0-3] 必須顯示專屬介面，讓使用者決定是否要授予要求的執行階段權限，以及提供管理執行階段權限的介面。
[C-0-4] 兩個使用者介面都只能擇一實作。如果裝置實作支援隨附裝置，隨附裝置「可能」會提供其他介面。
[C-0-5] 除非：
- 這些項目會在裝置出貨時安裝。「且」
- 在應用程式使用權限前，就能取得使用者的同意聲明。
  
  OR
- 執行階段權限是由預設權限授予政策授予或擁有平台角色。
[C-0-6] 只能將 android.permission.RECOVER_KEYSTORE 權限授予已註冊適當安全復原代理程式的系統應用程式。經過妥善保護的復原代理程式的定義，就是能與裝置外部遠端儲存空間保持同步的裝置端軟體代理程式。這類代理程式具備與 Google Cloud Key Vault 服務中所述同等或更強的安全硬體，可避免裝置因螢幕鎖定知識因素遭受暴力攻擊。

裝置實作方式：

[C-0-7] 如果應用程式透過標準 Android API 或專屬機制要求位置或體能活動資料，必須遵循 Android 位置存取權屬性。這類資料包括但不限於：
- 如第 9.8.8 節所述，裝置的所在位置 (例如經緯度)。
- 可用於判斷或預估裝置位置的資訊 (例如 SSID、BSSID、行動網路 ID 或裝置連線的網路位置)。
- 使用者的體能活動或體能活動分類。

具體來說，裝置導入方式：

[C-0-8] 必須取得使用者同意，允許應用程式存取位置或體能活動資料。
[C-0-9] 「只能」授予執行階段權限，「僅限於」享有 SDK 中所述足夠權限的應用程式。舉例來說，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 API 中定義的權限限制。
[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 可執行格式或原生程式碼也一樣。也就是說：

[C-0-1] 替代執行階段本身「必須」是 Android 應用程式，並遵循標準 Android 安全性模型，如第 9 節所述。
[C-0-2] 「不得」透過 <uses-permission> 機制，將未在執行階段的 AndroidManifest.xml 檔案中要求權限保護的資源存取給替代執行階段。
[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] 必須為每個使用者實作與 API 中安全性和權限參考文件中定義的 Android 平台安全性模型一致的安全性模型。
[C-1-3] 每個使用者執行個體都必須有獨立且獨立的共用應用程式儲存空間 (又稱為 /sdcard) 目錄。
[C-1-4] 必須確保由特定使用者擁有且代表特定使用者執行的應用程式無法列出、讀取或寫入任何其他使用者擁有的檔案，即使這兩個使用者的資料都儲存在相同的磁碟區或檔案系統中亦然。
[C-1-5] 在啟用多使用者功能時，如果裝置實作項目為外部儲存空間 API 使用卸除式媒體，則「必須」加密 SD 卡的內容，該金鑰只會儲存在系統可存取的不可移除媒體上。這會使主機電腦無法讀取媒體，因此裝置實作必須切換為 MTP 或類似系統，才能為主機電腦提供目前使用者資料的存取權。

如果裝置實作項目支援多位使用者，則除了專為執行相同應用程式的雙重執行個體建立的其他使用者以外，所有使用者：

[C-2-1] 每個使用者執行個體都必須有獨立且獨立的共用應用程式儲存空間 (又稱 /sdcard) 目錄。
[C-2-2] 必須確保特定使用者所擁有執行的應用程式無法列出、讀取或寫入任何其他使用者擁有的檔案，即使這兩個使用者的資料都儲存在相同的磁碟區或檔案系統中亦然。

為了執行同一個應用程式的兩個執行個體，裝置實作「可以」為主要使用者 (且僅限於主要使用者) 建立 android.os.usertype.profile.CLONE 類型的另一個使用者設定檔。這些兩個執行個體會共用部分獨立儲存空間，使用者會同時在啟動器中看到儲存空間，並顯示在相同的近期檢視畫面中。例如，此應用程式可用於支援使用者在雙 SIM 卡裝置上安裝兩個不同的單一應用程式。

如果裝置實作建立上述的額外使用者設定檔，則：

[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 沙箱機制，以及 Linux 核心中的其他安全性功能。裝置實作方式：

[C-0-1] 即使在 Android 架構下已實作 SELinux 或任何其他安全性功能，仍必須維持與現有應用程式的相容性。
[C-0-2] 當系統偵測到安全性違規行為，並成功由 Android 架構以下實作的安全性功能封鎖時，「不得」顯示使用者介面，但「可能」會顯示清楚可見的使用者介面，
[C-0-3] 不得將使用者或應用程式開發人員設為 Android 架構下實作的 SELinux 或任何其他安全性功能。
[C-0-4] 不得允許透過 API (例如 Device 管理 API) 影響其他應用程式的應用程式，設定破壞相容性的政策。
[C-0-5] 必須將媒體架構分割為多個程序，以更精簡地為每個程序授予存取權，如 Android 開放原始碼專案網站中的所述。
[C-0-6] 「必須」實作核心應用程式沙箱機制，才能使用多執行緒程式中可設定的政策篩選系統呼叫。如 source.android.com 的核心設定部分所述，上游 Android 開放原始碼專案啟用 seccomp-BPF 和執行緒群組同步處理 (TSYNC)，就能符合這項規定。

核心完整性和自我保護功能是 Android 安全性不可或缺的要素。裝置實作方式：

[C-0-7] 必須實作核心堆疊緩衝區溢位保護機制。這類機制為 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
[C-0-8] 必須實作嚴格的核心記憶體保護措施，其中可執行的程式碼為唯讀、唯讀資料無法執行且無法寫入，且可寫入資料為不可執行 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
[C-0-9] 在最初搭載 API 級別 28 以上的裝置上，必須針對使用者空間與核心空間 (例如 CONFIG_HARDENED_USERCOPY) 之間，實作靜態和動態物件大小邊界檢查。
[C-0-10] 在最初運送 API 級別 28 以上的裝置上在核心模式 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 中執行時，「不得」執行使用者空間記憶體。
[C-0-11] 在最初運送 API 級別 28 或以上的裝置上，「不得」在一般使用者副本存取 API 以外的核心中讀取或寫入使用者空間記憶體 (例如硬體 PAN 或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬)。
[C-0-12] 如果在最初運送 API 級別 28 以上的所有裝置上 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0) 的硬體出現安全漏洞，必須導入核心頁面表格隔離功能，
[C-0-13] 如果在最初運送 API 級別 28 或以上版本 (例如 CONFIG_HARDEN_BRANCH_PREDICTOR) 的所有裝置上，硬體的安全漏洞可更新至 CVE-2017-5715，則必須導入分支版本預測強化功能。
[C-SR-1] 強烈建議在核心中啟用堆疊初始化，避免使用未初始化的本機變數 (CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO)。此外，裝置實作也不應假設編譯器用於初始化本機變數的值。
[C-SR-2] 強烈建議保留核心資料，只有初始化期間才會寫入核心資料 (例如 __ro_after_init)。
[C-SR-3] 強烈建議「不要」隨機設定核心程式碼和記憶體的版面配置，並避免曝光會導致隨機化作業受損 (例如透過 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 套用系統啟動載入程式熵時)。CONFIG_RANDOMIZE_BASE
[C-SR-4] 強烈建議在核心中啟用控制流程完整性 (CFI)，為程式碼重複使用攻擊提供額外防護 (例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK)。
[C-SR-5] 強烈建議不要在已啟用控制流程的元件上停用控制流程完整性 (CFI)、陰影呼叫堆疊 (SCS) 或整數溢位清理 (IntSan)。
[C-SR-6] 極力建議您啟用 CFI、SCS 和 IntSan，藉此針對任何與安全性相關的使用者空間元件 (如 CFI 和 IntSan 所述) 啟用。
[C-SR-7] 強烈建議在核心中啟用堆疊初始化，避免使用未初始化的本機變數 (CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO)。此外，裝置實作也不應假設編譯器用於初始化本機變數的值。
[C-SR-8] 強烈建議在核心中啟用堆積初始化功能，避免使用未初始化的堆積分配量 (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)，且不應假設核心用於初始化這些配置的值。

如果裝置實作項目使用支援 SELinux 的 Linux 核心，就必須：

[C-1-1] 必須實作 SELinux。
[C-1-2] 必須將 SELinux 設為全域強制執行模式。
[C-1-3] 「必須」在強制執行模式下設定所有網域。不允許任何許可模式網域，包括裝置/廠商的專屬網域。
[C-1-4] 請勿修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 資料夾中存在的規則，以及這項政策「必須」以所有永不允許的規則進行編譯，包括 Android 開放原始碼計畫 SELinux 網域以及裝置/供應商專屬網域。
[C-1-5] 「必須」在個別應用程式的 SELinux 沙箱中，執行目標 API 級別為 28 以上的第三方應用程式，且每個應用程式的私人資料目錄均須設有 SELinux 限制。
應保留上游 Android 開放原始碼專案的 system/sepolicy 資料夾中提供的預設 SELinux 政策，並只針對自己的裝置專屬設定再加入這項政策。

如果裝置實作項目使用的核心不是 Linux 或 Linux，而沒有 SELinux，則裝置會執行以下動作：

[C-2-1] 必須使用與 SELinux 同等的必要存取權控管系統。

如果裝置實作方式採用支援 DMA 的 I/O 裝置，則：

[C-SR-9] 強烈建議使用 IOMMU (例如 ARM SMMU) 隔離每個支援 DMA 的 I/O 裝置。

Android 包含多種攸關裝置安全性的深度防禦功能。此外，Android 也著重於減少導致品質和安全性不佳的常見錯誤類別。

為了減少記憶體錯誤，裝置實作項目如下：

[C-SR-10] 強烈建議使用使用者空間記憶體錯誤偵測工具進行測試，例如 ARMv9 裝置的 MTE、針對 ARMv8 以上版本的裝置使用 HWASan，其他裝置類型則使用 ASan。
[C-SR-11] 強烈「建議」使用 KASAN 等核心記憶體錯誤偵測工具進行測試 (ARMv9 裝置專用 CONFIG_KASAN、CONFIG_KASAN_HW_TAGS、CONFIG_KASAN_SW_TAGS (適用於 ARMv8 裝置，或適用於其他裝置類型的 CONFIGENERKICAS)。
[C-SR-12] 強烈建議在 MTE、GWP-ASan 和 KFENCE 等實際工作環境中使用記憶體錯誤偵測工具。

如果裝置實作採用以 Arm TrustZone 為基礎的 TEE，會執行以下動作：

[C-SR-13] 強烈建議使用標準通訊協定在 Android 與 TEE 之間共用記憶體，例如 Armv8-A (FF-A) 的 Arm 韌體架構。
[C-SR-14] 強烈建議你限制信任的應用程式只能存取已透過上述通訊協定明確分享給這些應用程式的記憶體。如果裝置支援 Arm S-EL2 例外狀況層級，應由安全分區管理員強制執行。否則，應由 TEE OS 強制執行。

9.8. 隱私權

9.8.1。使用記錄

Android 會儲存使用者選擇的記錄，並透過 UsageStatsManager 管理這類記錄。

裝置實作方式：

[C-0-1] 請務必為這類使用者記錄保留合理的保留期限。
[C-SR-1] 強烈建議將 Android 開放原始碼計畫實作項目的預設保留期限設為 14 天。

Android 會使用 StatsLog ID 儲存系統事件，並透過 StatsManager 和 IncidentManager System API 管理這類記錄。

裝置實作方式：

[C-0-2] 只須在 System API 類別 IncidentManager 建立的事件報告中納入標示為 DEST_AUTOMATIC 的欄位。
[C-0-3] 不得使用系統事件 ID 記錄任何其他事件，而不是 StatsLog SDK 文件所載事件。如果記錄了其他系統事件，這些事件可能會使用不同的 Atom ID，範圍介於 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 或擁有 CDD ID [C-3-X] 所述角色的應用程式可存取麥克風，則不建議顯示麥克風指標。.
[C-SR-2] 強烈建議使用 PermissionManager.getIndicatorAppOpUsageData() 傳回的麥克風，顯示最近使用的應用程式和使用中的應用程式清單，以及與這些應用程式相關的歸因訊息。
[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] 必須針對上游 Android 開放原始碼專案中提供的系統信任憑證授權單位 (CA) 儲存庫，預先安裝相同的根憑證。
[C-0-2] 出貨時，請務必提供空白的使用者根 CA 商店。
[C-0-3] 新增使用者根 CA 時，「必須」向使用者顯示警告，指出可能監控網路流量。

如果裝置流量是透過 VPN 轉送，系統會採用以下裝置實作方式：

[C-1-1] 請務必向使用者顯示警告，指出下列其中一項做法：
- 該網路流量可能會受到監控。
- 系統會透過提供 VPN 的特定 VPN 應用程式轉送網路流量。

如果裝置實作具有預設為立即啟用的機制，會由 Proxy 伺服器或 VPN 閘道轉送網路流量 (例如預先載入已授予 android.permission.CONTROL_VPN 的 VPN 服務)，則會：

[C-2-1] 必須徵得使用者同意，才能啟用該機制；但如果裝置政策控制器透過 DevicePolicyManager.setAlwaysOnVpnPackage() 啟用 VPN，則使用者不需另外提供同意聲明，但「必須」僅收到通知。

如果裝置實作項目實作使用者需求，以便開啟第三方 VPN 應用程式的「永久連線 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。內容擷取和應用程式搜尋

透過 System API ContentCaptureService、AugmentedAutofillService、AppSearchGlobalManager.query 或其他獨有方式，Android 支援裝置實作機制，以擷取應用程式與使用者之間的下列應用程式資料互動：

在螢幕上顯示的文字和圖形，包括但不限於透過 AssistStructure API 顯示的通知和輔助資料。
裝置錄製或播放的媒體資料，例如音訊或影片。
輸入事件，例如按鍵、滑鼠、手勢、語音、影片和無障礙工具。
應用程式透過 Content Capture API 或 AppSearchManager API 提供給系統的任何其他事件，這類事件也是功能類似的 Android 和專屬 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] 「不得」將這類資料分享給未遵循目前章節 (9.8.6 內容擷取) 規定的其他 OS 元件，除非每次分享都經過使用者同意。
[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 權限，並依第 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 位置類別中的資訊( 例如緯度、經度、海拔高度)，以及可轉換成 Location 的 ID。位置可以十分符合 DGPS (差異全球定位系統) 或國家/地區層級位置 (例如國家/地區代碼位置 - MCC - 行動裝置國家/地區代碼)。

以下位置類型清單會直接產生使用者的位置，或可以轉換成使用者的位置。這份清單並未涵蓋所有位置，但應做為範例，說明哪些位置可以直接或間接從下列項目衍生：

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_Location 權限的 Android API，做為主要參考資料。

裝置實作方式：

[C-0-1] 未經使用者明確同意或使用者啟動，「不得」開啟或關閉裝置位置資訊設定和 Wi-Fi/藍牙掃描設定。
[C-0-2] 必須為使用者提供權限，讓他們存取位置資訊相關資訊，包括最近的位置要求、應用程式層級權限，以及使用 Wi-Fi/藍牙掃描來判斷位置。
[C-0-3] 必須確保使用緊急位置略過 API [LocationRequest.setLocationSettingsIgnored()] 的應用程式是使用者啟動的緊急工作階段 (例如：撥打 911 或傳送簡訊至 911)。然而， Automotive 車輛可能會在偵測到車禍/意外事故時，在使用者沒有主動互動的情況下啟動緊急工作階段。
[C-0-4] 必須讓 Emergency Location Bypass API 能夠略過裝置位置資訊設定，而不變更設定。
[C-0-5] 請務必排定通知，讓系統在應用程式透過 [ACCESS_BACKGROUND_LOCATION] 權限存取背景應用程式時，提醒使用者。

9.8.9。已安裝的應用程式

根據預設，指定 API 級別 30 以上的 Android 應用程式將無法查看其他應用程式的詳細資料 (請參閱 Android SDK 說明文件中的「套件瀏覽權限」)。

裝置實作方式：

[C-0-1] 除非應用程式可以透過代管 API 查看其他已安裝應用程式的詳細資料，否則不得向任何目標 API 級別 30 以上的應用程式提供其他已安裝應用程式的詳細資料。這包括但不限於由裝置實作工具新增，或可透過檔案系統存取的自訂 API 所公開的詳細資料。
[C-0-2] 「不得」將外部儲存空間內任何其他應用程式專屬應用程式專屬目錄中的檔案讀取或寫入權限授予任何應用程式。唯一的例外狀況如下：
- 外部儲存空間供應商授權 (例如 DocumentsUI 等應用程式)。
- 下載供應商，其使用「下載」提供者授權，將檔案下載到應用程式儲存空間。
- 平台簽署的媒體傳輸通訊協定 (MTP) 應用程式，會使用特殊權限權限 ACCESS_MTP 將檔案傳輸到其他裝置。
- 安裝其他應用程式且具有 INSTALL_PACKAGES 權限的應用程式，只能存取「obb」目錄，用於管理 APK 擴充檔案。

9.8.10。連線錯誤報告

如果裝置實作程序宣告了 android.hardware.telephony 功能旗標，就會：

[C-1-1] 必須支援透過 BugreportManager 透過 BUGREPORT_MODE_TELEPHONY 產生連線錯誤報告。
[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] 我們強烈建議將開發人員設定預設為停用。如要符合 Android 開放原始碼計畫參考資料的實作方式，請在開發人員設定中提供 Enable verbose vendor logging 選項，以便在錯誤報告中加入其他裝置的特定供應商記錄。

9.8.11。資料 blob 共用

Android 透過 BlobStoreManager 允許應用程式將資料 blob 提供給系統，以便與一組選定的應用程式共用。

如果裝置實作支援共用資料 blob (如 SDK 說明文件所述)，就會：

[C-1-1] 絕對不得分享屬於應用程式本身允許的資料 blob (即預設存取權的範圍，以及其他可透過 BlobStoreManager.session#allowPackageAccess() 或 BlobStoreManager.session#allowSameSignatureAccess() 或 BlobStoreManager.session#allowPublic bemod() 指定的其他存取模式) 以外的範圍。Android 開放原始碼計畫參考資料實作項目符合這些規定。
[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] 必須針對相關 supportsSensorToggle() API 方法準確傳回「true」。
[C-1-2] 當應用程式嘗試存取遭封鎖的麥克風或相機時，必須「必須」採用無法關閉的使用者用途，明確表示感應器遭到封鎖，且需要根據符合這項規定的 Android 開放原始碼計畫實作方式，選擇繼續封鎖或解除封鎖。
[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。
[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] 必須實作下列其中一種加密方法，以符合上述資料儲存加密要求：
- 檔案型加密 (FBE) 和中繼資料加密 (如第 9.9.3.1 節所述)。
- 「每位使用者的封鎖層級加密」一節如 9.9.3.2 節所述。

9.9.3. 加密方法

如果裝置實作項目已加密，會：

[C-1-1] 必須在不要求使用者提供憑證的情況下啟動，並允許直接啟動感知應用程式在 ACTION_LOCKED_BOOT_COMPLETED 訊息廣播後存取裝置加密 (DE) 儲存空間。
[C-1-2] 只有在使用者提供憑證 (例如密碼、PIN 碼、解鎖圖案或指紋) 解鎖裝置且已廣播 ACTION_USER_UNLOCKED 訊息而解鎖裝置後，才能存取憑證加密 (CE) 儲存空間。
[C-1-13] 「不得」提供任何解鎖 CE 受 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) 指示 (例如 ARM 型裝置上的 ARMv8 密碼學擴充功能，或 x86 型裝置上的 AES-NI)，則「必須」使用上述的 AES 選項，例如檔案名稱、檔案內容和檔案系統中繼資料加密機制，而非 Adiantum。
[C-1-13] 「必須」使用經過加密的高強度金鑰擷取函式 (例如 HKDF-SHA512)，從 CE 和 DE 金鑰衍生任何所需的子金鑰 (例如每個檔案金鑰)。「加密編譯安全且不可撤銷」是指金鑰衍生函式的安全性強度至少為 256 位元，本身也會做為「偽隨機函式系列」在輸入內容上運作的情況。
[C-1-14]「不得」針對不同的加密編譯用途，使用相同的檔案式加密 (FBE) 金鑰或子金鑰 (例如用於加密和金鑰衍生，或兩種不同的加密演算法)。
[C-1-15] 「必須」確保永久儲存空間上所有未刪除的加密檔案內容區塊，都使用加密金鑰和初始化向量 (IV) 的組合進行加密，這些區塊要依賴檔案和檔案內的偏移。此外，除非使用僅支援 IV 長度 32 位元的內嵌加密硬體來加密，否則所有這類組合均必須具有區別性。
[C-1-16] 必須確保不同目錄中的永久儲存空間中，所有未刪除的加密檔案名稱，都是使用不同的加密金鑰和初始化向量 (IV) 組合進行加密。
[C-1-17] 必須確保永久儲存空間中的所有加密檔案系統中繼資料區塊，都使用不同的加密金鑰和初始化向量 (IV) 的組合進行加密。
保護 CE 和 DE 儲存區域，以及檔案系統中繼資料的金鑰：
- [C-1-7] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。這個 KeyStore「必須」繫結於驗證開機程序和裝置的硬體信任根。
- [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
- [C-1-9] 使用者未指定螢幕鎖定憑證時，CE 金鑰必須繫結至預設密碼。
- [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、刷新等) 的運作，但下文會詳細說明；但這類修改作業需要至少延遲一小時，且會破壞 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 檔案外部載入的任何可執行構件 (例如動態載入的程式碼或編譯的程式碼)，或強烈「建議」不要執行這些構件。
凡是含有永久韌體 (例如數據機、相機) 的元件，都應導入復原保護機制，並應使用防竄改儲存空間儲存中繼資料，用來判斷系統允許的最低版本。

如果已在舊版 Android 沒有支援 C-1-8 到 C-1-11 的情況下啟動裝置實作項目，而且無法透過系統軟體更新新增這些要求的支援，那麼這類實作項目就「可能」不受這些要求規範。

上游 Android 開放原始碼計畫在 external/avb/ 存放區中提供了這項功能的偏好實作方式，可以整合至系統載入 Android 使用的系統啟動載入程式。

裝置實作方式：

[C-0-3] 必須支援針對未讀取整個檔案，以加密方式驗證檔案內容的功能。
[C-0-4] 當讀取內容未依據信任的金鑰驗證時，「不得」允許成功針對受保護檔案發出的讀取要求。

如果已經啟動裝置實作項目，但無法在舊版 Android 中根據信任的金鑰驗證檔案內容，也無法透過系統軟體更新新增這項功能，那麼這類實作項目就「可能」不受這項規定的限制。上游 Android 開放原始碼專案以 Linux kernel fs-verity 功能為基礎，提供這項功能的建議實作方式。

裝置實作方式：

[C-SR-4] 強烈建議支援 Android Protected Confirmation API。

如果裝置實作支援 Android Protected Confirmation API，就會執行以下操作：

[C-3-1] 必須針對 ConfirmationPrompt.isSupported() API 回報 true。
[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，則時間間隔至少須為 30 秒，期間 9 < n < 30)。如果是 n > 29，時間間隔值至少須為 30*2^floor((n-30)/10) 秒或至少 24 小時 (以較小者為準)。
不應限制可產生的金鑰數量

如果實作的裝置支援安全螢幕鎖定，它會：

[C-1-1] 必須使用獨立的執行環境備份 KeyStore 實作。
[C-1-2] 必須實作 RSA、AES、ECDSA、ECDH (如果支援 IKeyMintDevice)、3DES 和 HMAC 加密編譯演算法、MD5、SHA1 和 SHA-2 系列雜湊函式，才能在通過核心程式碼並在以上核心的環境中安全地隔離 Android KeyStore 系統支援的演算法。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。上游 Android 開放原始碼計畫 (AOSP) 採用 Trusty 實作項目來符合這項規定，但另外，以 ARM TrustZone 解決方案或第三方審查的安全實作方式為採用適當的管理程序隔離措施。
[C-1-3] 「必須」在獨立的執行環境中執行螢幕鎖定驗證，且僅在成功時允許使用驗證繫結金鑰。螢幕鎖定憑證的儲存方式，必須只允許隔離的執行環境執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，可用於滿足這項需求。
[C-1-4] 必須支援金鑰認證，因為認證簽署金鑰受到安全硬體保護，且簽署金鑰是在安全的硬體中執行。必須為一定數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。如要符合這項規定，其中一個方法是共用相同認證金鑰，除非產生至少 10 萬個指定 SKU 的單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰。

[C-1-5] 必須允許使用者選擇從解鎖狀態轉換為鎖定狀態的睡眠逾時時間，最短允許的逾時時間上限為 15 秒。這類汽車裝置會在車用運算主機關閉或使用者切換時鎖定螢幕，但「可能」沒有睡眠逾時設定。
[C-1-6] 必須支援 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] 您在 Android 開放原始碼計畫中導入及提供的任何建議主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 一律「不得」替換為新的驗證方法。
[C-3-4] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setRequiredPasswordComplexity() 設定密碼要求政策，使用比 PASSWORD_COMPLEXITY_NONE 之限制更嚴格的複雜性常數，或透過 DevicePolicyManager.setPasswordQuality() 常數，且限制為 KWEIO.setPasswordQuality() 常數，則「必須」停用新的驗證方法。
[C-3-5] 新的驗證方法「必須」每隔 72 小時改回使用建議的主要驗證方法 (例如 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 碼、解鎖圖案、密碼)，如第 7.3.10 節中的 [C-1-7] 和 [C-1-8] 所述。
[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] 至少每 4 小時須要求使用者以任一建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 進行驗證。如果實體權杖符合 C-X 中 TrustAgent 實作的要求，系統會改為套用 C-9-5 中定義的逾時限制。
[C-6-4] 「不得」將新方法視為安全螢幕鎖定，且必須遵守下列 C-8 所列的限制。

如果裝置實作項目設有安全螢幕鎖定，且包含一或多個實作 TrustAgentService System API 的信任代理程式，就會執行以下操作：

[C-7-1] 當裝置鎖定延遲或已由信任的代理程式解鎖時，必須在設定選單和螢幕鎖定畫面上明確指示。舉例來說，Android 開放原始碼計畫符合這項規定，在設定選單中顯示「自動鎖定設定」和「電源鍵立即鎖定」等文字說明，並在螢幕鎖定畫面上顯示可區分的圖示。
[C-7-2] 必須尊重並完整實作 DevicePolicyManager 類別中的所有信任代理程式 API，例如 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] 除非使用者的安全 (例如駕駛人分心) 不妥當，否則「必須」驗證使用者採用第 7.3.10 節中 [C-1-7] 和 [C-1-8] 所述的任一建議主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 方法。
[C-7-10] 不得視為安全螢幕鎖定，且必須遵守下列 C-8 限制。
[C-7-11] 不得允許主要個人裝置 (例如手持裝置) 上的 TrustAgent 解鎖裝置，且只能讓已解鎖裝置保持解鎖狀態最長 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 以用於判斷鎖定狀態。

如果裝置實作項目允許應用程式建立次要虛擬螢幕，且不支援透過 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] 如 DevicePolicyManager.setNearbyAppStreamingPolicy 指示，「必須」停用透過 VirtualDeviceManager 建立相關輸入事件的功能
[C-10-7] 「必須」針對每部虛擬裝置使用個別的剪貼簿 (或針對虛擬裝置停用剪貼簿)
[C-10-11] 必須在虛擬裝置上停用驗證 UI，包括知識因素輸入和生物特徵辨識提示
[C-10-12] 必須限制從虛擬裝置啟動的意圖，僅顯示在同一部虛擬裝置上
[C-10-13] 不得使用虛擬裝置鎖定狀態做為 Android KeyStore 系統的使用者驗證授權。詳情請參閱 KeyGenParameterSpec.Builder.setUserAuthentication*。

如果可讓使用者將主要驗證知識因子從來源裝置轉移至目標裝置 (例如進行目標裝置的初始設定)，會執行以下動作：

[C-11-1] 將知識因素從來源裝置傳輸到目標裝置時，「必須」為知識要素加密 (類似 Google Cloud Key Vault 服務安全性白皮書中所述)，以免知識因子無法從遠端解密，或是用來從遠端解鎖任一裝置。
[C-11-2] 「必須」在來源裝置上要求使用者確認來源裝置的知識，再將知識因素傳送到目標裝置。
[C-11-3] 在缺少任何主要驗證知識的目標裝置上，「必須」要求使用者先確認目標裝置上的知識因素已傳輸，再將其設定為目標裝置的主要驗證知識因素，以及從來源裝置傳輸的任何資料。

如果裝置實作項目具有安全螢幕鎖定畫面，且包含一或多個信任代理程式，就會使用 FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 標記呼叫 TrustAgentService.grantTrust() System API：

[C-12-1] 只有在連線至本身有螢幕鎖定功能的鄰近實體裝置，以及使用者針對該螢幕鎖定畫面驗證身分時，才需要使用旗標呼叫 grantTrust()。在使用者單次解鎖後，Proxi 裝置可使用腕上或人體感測機制，滿足使用者驗證要求。
[C-12-2] 螢幕關閉時 (例如按下按鈕或顯示螢幕逾時)，且 TrustAgent 未撤銷信任時，必須將裝置實作加入 TrustState.TRUSTABLE 狀態。AOSP 符合這項規定。
[C-12-3] 如果 TrustAgent 仍根據 C-12-1 的規定授予信任，則「必須」將裝置從 TrustState.TRUSTABLE 移至 TrustState.TRUSTED 狀態。
[C-12-4] 在授予信任、超過 8 小時閒置期間，或與鄰近實體裝置的基本連線中斷時，必須呼叫 TrustManagerService.revokeTrust()。

如果裝置實作項目可讓應用程式建立次要虛擬螢幕，並支援透過 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 節定義的憑證會議規定，或至少使用第 7.3.10 節定義的第 1 級會議，以便從預設裝置螢幕獨立解鎖。
[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] 必須採用獨立的 CPU，不得與應用程式處理器 (AP) 共用快取、DRAM、輔助處理器或其他核心資源。
[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] 必須採用安全儲存空間，確保內容的機密性、完整性、真實性、一致性和即時性。除非 StrongBox API 允許，否則「不得」讀取或修改儲存空間。
如要驗證裝置是否符合 [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. 身分憑證

身分憑證系統是由實作 android.security.identity.* 套件中的所有 API 所定義與完成。這些 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] 信任的應用程式「必須」在實作時，不會影響其安全性屬性。舉例來說，除非符合存取權控管條件，否則系統不會發布憑證資料，也無法產生任何 MAC 供任意資料。

上游 Android 開放原始碼計畫提供了可信任應用程式 (libeic) 的參考實作，可用於實作身分識別憑證系統。

9.12. 資料刪除

所有裝置實作方式：

[C-0-1] 「必須」為使用者提供執行「恢復原廠設定」的機制。
[C-0-2] 執行「恢復原廠設定」時，「必須」刪除使用者資料檔案系統中的所有資料。
[C-0-3] 執行「恢復原廠設定」時，請務必以符合 NIST SP800-88 等相關業界標準的方式刪除資料。
[C-0-4] 主要使用者的 Device Policy Controller 應用程式呼叫 DevicePolicyManager.wipeData() API 時，必須觸發上述「恢復原廠設定」程序。
可能提供快速清除資料選項，只可執行邏輯資料清除作業。

9.13. 安全啟動模式

Android 提供安全啟動模式，讓使用者啟動以下模式：僅允許系統執行預先安裝的系統應用程式，並停用所有第三方應用程式。這個模式稱為「安全啟動模式」，可讓使用者解除安裝可能有害的第三方應用程式。

裝置導入方式如下：

[C-SR-1] 強烈建議你導入安全啟動模式。

如果裝置實作了安全啟動模式，就會：

[C-1-1] 「必須」為使用者提供進入安全啟動模式的選項，使安裝在裝置上的第三方應用程式無法中斷服務，但第三方應用程式為 Device Policy Controller 且將 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.* 套件定義的所有 API。
[C-1-2] 不得修改 Android SELinux 和權限模型，以管理受保護的虛擬機器。
[C-1-3] 「不得」修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 中列出的不允許規則，且在編譯政策時「必須」採用所有一律不允許的規則。
[C-1-4] 不得允許不受信任的程式碼 (例如第三方應用程式) 建立及執行 Protected Virtual Machine。注意：日後的 Android 版本中可能會發生變更。
[C-1-5] 「不得」允許受保護虛擬機器執行原廠映像檔或其更新以外的程式碼。任何不屬於 Android 驗證開機程序的內容 (例如從網際網路下載或側載的檔案) 都「不得」在受保護的虛擬機器中執行。

如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*) 的支援功能，則代表所有 Protected Virtual Machine 執行個體：

[C-2-1] 必須能夠執行 Protected Virtual Machine 中的虛擬化 APEX 中提供的所有作業系統。
[C-2-2] 不得允許受保護的虛擬機器執行未經裝置實作者或 OS 廠商簽署的作業系統。
[C-2-3] 「不得」允許受保護的虛擬機器以程式碼形式執行資料 (例如 SELinux 一律不允許 execmem)。
[C-2-4] 不得修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 中提供的系統/sepolicy/microdroid 中的永不允許規則。
[C-2-5] 即使對非 Microdroid 作業系統，也必須採用受保護的虛擬機器深度防禦機制 (例如 pVM 適用的 SELinux)。
[C-2-6] 必須確保 pVM 韌體無法驗證初始映像檔時，會拒絕啟動。
[C-2-7] 必須確保 instance.img 的完整性遭入侵時，pVM 韌體會拒絕啟動。

如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*) 的支援，則管理程序：

[C-3-1] 除非頁面擁有者明確分享，否則「不得」允許任何 pVM 存取屬於其他實體 (例如其他 pVM 或管理程序) 的頁面。其中包括主機 VM。CPU 和 DMA 存取均適用此規定。
[C-3-2] 網頁已供 VM 使用後，請「務必」抹除頁面內容，再將該頁面傳回主機 (例如 pVM 遭刪除)。
[C-3-3] 「必須」確保在 pVM 中的任何程式碼之前，已載入並執行 pVM 韌體。
[C-3-4] 必須確保提供給 pVM 執行個體的 BCC 和 CDI 只能透過該特定執行個體衍生。

如果裝置實作 Android 虛擬化架構 API 的支援功能，則請針對所有區域：

[C-4-1] 不得向允許略過 Android 安全性模型的 pVM 提供功能。

如果裝置實作 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 開放原始碼計畫提供的 Android Compatibility Test Suite (CTS)。
[C-0-2] 必須確保 CTS 中模稜兩可的情況，以及參照原始碼中特定部分的任何重新實作時，都確保相容。

CTS 的設計宗旨是在實際裝置上執行。和任何軟體一樣 CTS 本身可能包含錯誤CTS 的版本與此相容性定義無關，且可能針對 Android 13 發布多個 CTS 修訂版本。

裝置實作方式：

[C-0-3] 必須通過裝置軟體完成時可用的最新 CTS 版本。
請盡可能使用 Android 開放原始碼樹狀結構中的參考實作。

10.2. CTS 驗證器

Compatibility Test Suite 隨附 CTS Verifier，可由真人操作人員執行，測試無法由自動化系統測試的功能，例如相機和感應器的正確功能。

裝置實作方式：

[C-0-1] 「必須」正確執行 CTS 驗證器中的所有適用案例。

CTS Verifier 可針對多種硬體進行測試，包括部分為選用硬體。

裝置實作方式：

[C-0-2] 必須通過本身硬體的所有測試；舉例來說，如果裝置擁有加速計，就「必須」正確執行 CTS 驗證器中的加速計測試案例。

這份相容性定義文件「可以」略過或略過標示選用功能的測試案例。

[C-0-2] 每個裝置和每個版本都必須正確執行 CTS Verifier (如上所述)。不過，由於許多版本非常相似，因此裝置實作者不應在僅有顯著差異的版本中明確執行 CTS 驗證器。具體來說，裝置實作項目不同於只透過包含的地區、品牌宣傳等組合通過 CTS Verifier 的實作項目，但可以省略 CTS Verifier 測試。

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 後預期結果是否相同。自 Android 5.1 版起，在上游 Android 開放原始碼專案中新增以區塊為基礎的 OTA 實作符合這項規定。

此外，裝置實作項目必須支援 A/B 系統更新。Android 開放原始碼計畫利用啟動控制項 HAL 實作這項功能。

如果在裝置實作項目已發布後發現錯誤，但已在其合理的產品生命週期內發現錯誤 (經諮詢 Android 相容性團隊確認，會影響第三方應用程式相容性)，則：

[C-2-1] 裝置實作者「必須」透過能根據上述機制套用的可用軟體更新來修正錯誤。

Android 提供可讓裝置擁有者應用程式 (如有) 控制系統更新安裝的功能。如果裝置的系統更新子系統回報 android.software.device_admin，就會：

[C-3-1] 必須實作 SystemUpdatePolicy 類別所述的行為。

12. 文件變更記錄

以下摘要說明這個版本的相容性定義異動：

2023 年 10 月 4 日

2. 裝置類型

2.2.5. 安全性模型：
查看修訂版本
- [9.8/H-1-14] 如 9.8.2 節所述，當啟動字詞結果成功傳送至語音時，必須顯示麥克風指標，如 9.8.2 所述。~~[9.8/C-3-1]~~
2.2.7.1 媒體：
查看修訂版本
- [5.1/H-1-7] 針對 1080p 以下的所有硬體視訊編碼器，在負載不足的情況下，轉碼器初始化延遲時間不得超過 40 毫秒。此處載入定義為使用硬體視訊轉碼器和 1080p 音訊錄影初始化的 1080p 至 720p 純影片轉碼工作階段。針對 Dolby Vision 轉碼器，轉碼器的初始化延遲時間不得超過 50 毫秒。
- [5.1/H-1-12] 在負載不足的情況下，針對 1080p 以下所有硬體視訊解碼器，轉碼器初始化延遲時間不得超過 40 毫秒。此處載入的定義為使用硬體視訊轉碼器和 1080p 音訊影片播放初始化的 1080p 至 720p 純影片轉碼工作階段。針對 Dolby Vision 轉碼器，轉碼器的初始化延遲時間不得超過 50 毫秒。
- [5.1/H-1-13] 處於載入狀態時，所有音訊解碼器的轉碼器初始化延遲時間不得超過 30 毫秒，或降低所有音訊解碼器的位元率音訊解碼工作階段。此處載入的定義為使用硬體視訊轉碼器和 1080p 影音播放初始化的 1080p 至 720p 純影片轉碼工作階段。

7.4. 資料連線

7.4.1.1. 號碼封鎖相容性：

查看修訂版本

如果裝置實作項目回報 android.hardware.telephony.calling 功能，就會：
7.4.1.2. Telecom API：

查看修訂版本

如果裝置導入作業回報 android.hardware.telephony.calling，就會：

9.11. 金鑰和憑證

9.11.2. StrongBox：

查看修訂版本

是透過 IAuthSecret HAL 提供

移除 IAR 將成為 Android 14 的「必須」規定。

2023 年 6 月 26 日

2. 裝置類型

2.2.1. 硬體
- 移除要求 7.2.3/H-0-5、7.2.3/H-0-6、7.2.3/H-0-7
- 其他更新：
  
  查看修訂版本
  
  極力建議您遵循「所在地校正規定」一節中指明的評估設定步驟。
2.5.1. 硬體
查看修訂版本
如果 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] 如果使用下列任一密度，核心和使用者空間可用的記憶體必須至少為 1344 MB：

在小螢幕/一般螢幕上，採用 560 dpi 以上

在大螢幕裝置上播放 400 dpi 以上

搭載 xhdpi (含) 以上大螢幕

3. 軟體

3.2.3.5. 條件式應用程式意圖

查看修訂版本

如果裝置實作方式回報 android.hardware.telephony.calling ~~android.hardware.telephony~~，則會發生以下情形：

7. 硬體相容性

7.4. 資料連線

查看修訂版本

所在地校正~~相關規定~~。

9. 安全性模型相容性

9.1 權限
查看修訂版本

裝置實作方式：
- [C-0-5] 除非以下情況，否則「不得」將任何執行階段權限~~預先安裝~~至應用程式：
  - 這些裝置會在裝置出貨時安裝，「且」
  - 在應用程式使用權限權限前，可以取得使用者的同意聲明。
  或
  - 預設權限授予政策或持有平台角色，會授予執行階段權限；~~與預先安裝應用程式的意圖模式相關聯，這個模式會設為預設處理常式。~~
9.11. 金鑰和憑證
- 移除規定 [C-13-10] 和 9.11.4。

2023 年 3 月 20 日

2. 裝置類型

2.2.3. 軟體
查看修訂版本
如果手持裝置的實作設定應用程式使用活動嵌入功能實作分割功能，則：
- [~~C-17-1~~3.2.3.1/ H-1-1] 啟用分割功能時，「必須」具有處理設定#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY的活動。活動必須受 android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK 保護，且「必須」啟動從 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI 剖析的 Intent 活動。
終止新規定
2.3.2. 多媒體
查看修訂版本

如果電視裝置實作包含 VP9 硬體解碼器，可支援 VP9 解碼和 UHD 超高畫質設定檔：
- [5.3.7/T-~~2-1~~SR1] 強烈建議在設定 2 (10 位元色彩深度) 的情況下，以每秒 60 個影格的速度支援 UHD 解碼設定檔。
2.5.1. 硬體
查看修訂版本

Automotive 裝置實作：
- [7.3/A-~~0-1~~SR1] 將 GPS/GNSS 結合其他感應器，導致位置可能失效。如果「Location」(位置) 受損，極力建議實作及回報使用的相應感應器類型和/或車輛物業 ID。
- [7.3/A-~~0-2~~0-4] 透過 LocationManager#requestLocationUpdates() 要求的 Location 位置「不得」相符。

3. 軟體

3.18. 聯絡人
查看修訂版本
新聯絡人的預設帳戶：Contact Provider 提供 API，可在建立新聯絡人時管理預設帳戶的設定。

如果裝置實作預先載入了聯絡人應用程式，則會預先載入聯絡人應用程式：

[C-2-1] 必須處理意圖 ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT，以啟動帳戶選取作業的 UI，並在選取帳戶時將設定儲存至聯絡人提供者。

[C-2-2] 為 ContactsContracts.Contacts.CONTENT_TYPE 和 ContactsContract.RawContacts.CONTENT_TYPE 處理 Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT 時，必須先選取帳戶，才能採用預設的帳戶設定。

終止新規定
3.2.3.5. 條件式應用程式意圖
查看修訂版本

[已移至 2.2.3]
如果裝置實作的「設定」應用程式透過活動嵌入功能實作分割功能，則：

[C-17-1] 在開啟分割功能的情況下，「必須」具有處理 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY 意圖的活動。活動必須受 android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK 保護，且「必須」啟動從 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI 剖析的 Intent 活動。

終止新規定

6. 開發人員工具與選項的相容性

6.1. 開發人員工具
查看修訂版本
Monkey

[C-0-8] 必須納入 Monkey 架構，供應用程式使用。

7. 硬體相容性

7.3.13. IEEE 802.1.15.4 (UWB)
查看修訂版本

[已移至 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 無線電的應用程式 (在 NEARBY_devices 權限群組底下) 擁有 UWB_RANGING 權限。

[C-1-6] 強烈建議你通過標準機構 (包括 FIRA、CCC 和 CSA) 定義的規範和認證測試。

終止新規定
7.4.1. 電話
查看修訂版本

如果裝置實作~~包含 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] 在向使用者顯示及控制 SIM 卡資訊的所有可用用途中，必須向所有具備同等群組 UUID 的 SubscriptionInfo 呈現單一訂閱項目。這類用途包括符合 Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS 或 EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS 的設定介面。
- [C-6-6] 不得在可供設定或控制 SIM 卡設定的任何使用者可見用途中，顯示或允許控制具有非空值群組 UUID 和機會位元的任何 SubscriptionInfo。
如果裝置實作方式~~包含 GSM 或 CDMA 電話~~，請回報 android.hardware.telephony 功能並提供系統狀態列，然後：
- [C-6-7-1] 必須為特定群組 UUID 選取具有代表性的有效訂閱項目，才能在提供 SIM 卡狀態資訊的任何用途中向使用者顯示。例如狀態列的行動網路訊號圖示或快速設定方塊等。
- [C-SR-1] 我們強烈建議為代表性訂閱項目選擇為有效資料訂閱，除非裝置正在語音通話中，因此我們強烈建議在這類訂閱期間建議代表訂閱為有效的語音訂閱。
如果裝置實作~~包含 GSM 或 CDMA 電話~~，請回報 android.hardware.telephony 功能，然後：
- [C-6-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] 當您嘗試以偏好或允許的網路類型位元遮罩設定任何 3GPP2 網路類型時，必須擲回 IllegalArgumentException。
- [C-89-3] 必須從 TelephonyManager#getMeid 傳回空字串。
如果裝置實作支援具有多個通訊埠和設定檔的 eUICC，則：
- [C-1110-1] 必須宣告 android.hardware.telephony.euicc.mep 功能標記。
7.4.9. UWB
查看修訂版本

~~如果裝置實作項目透過 android.content.pm.PackageManager 類別回報 android.hardware.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 無線電的應用程式 (在 NEARBY_devices 權限群組底下) 擁有 UWB_RANGING 權限。
- [C-SR-1] 強烈建議你通過標準機構 (包括 FIRA、CCC 和 CSA) 所定義的相關合規性和認證測試。
- [C-1-16] 必須確保距離測量結果在距離環境 1 公尺與 1 公尺以內的距離為 95% 以內，並且以非反射式室內空間測量距離。
- [C-1-27] 必須確保從參考裝置測得的距離中位數介於 [0.75m, 1.25 公尺] 內，其中真值距離以雙手朝上且傾斜的 45 度為基準。
- [C-SR-2] 極力建議您遵循「在家狀態校正規定」中所述的評估設定步驟。
~~極力建議您遵循「在家狀態校正規定」中所述的評估設定步驟。~~

終止新規定
7.8.2.2. 數位音訊連接埠

查看修訂版本

~~為了與耳機和其他音訊配件相容，請使用 USB-C 連接器，並實作 (USB 音訊類別)，在 Android 生態系統中如「Android USB 耳機規格」所述。~~

2022 年 10 月 19 日

2. 裝置類型

2.2.3 軟體
查看修訂版本

如果手持裝置的實作無法在鎖定任務模式下執行，那麼將內容複製到剪貼簿時：
- [3.8.17/H-1-1] 必須向使用者確認資料已複製到剪貼簿 (例如「已複製內容」的縮圖或快訊)。此外，加入這裡即可指出剪貼簿資料是否會在不同裝置間保持同步。

3. 軟體

3.2.3.5. 條件式應用程式意圖
查看修訂版本

如果裝置實作的「設定」應用程式透過活動嵌入功能實作分割功能，請按照下列步驟操作：
- [C-17-1] 啟用分割功能時，「必須」具有處理 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY 意圖的活動。活動必須受 android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK 保護，且必須「必須」從 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI 剖析的意圖中啟動該意圖的活動。
如果裝置實作支援 VoiceInteractionService，且同時安裝多個使用這個 API 的應用程式，就會：
- [C-18-1] 必須遵循 android.settings.ACTION_VOICE_INPUT_SETTINGS 意圖，才能針對語音輸入和小幫手顯示預設的應用程式設定選單。
3.4.1 WebView 相容性
查看修訂版本
- [C-1-4]「必須」在與執行個體化 WebView 的應用程式不同的情況下，轉譯提供的內容或遠端網址內容。具體來說，獨立的轉譯器程序「必須」擁有較低權限、以獨立的使用者 ID 執行、無法存取應用程式的資料目錄、沒有直接網路存取權，而且只能透過 Binder 存取最低需求的系統服務。WebView 的 Android 開放原始碼計畫實作符合這項規定。

7. 硬體相容性

7.4.2 IEEE 802.11 (Wi-Fi)
查看修訂版本

如果裝置實作項目支援 IEEE 802.11 標準中定義的 Wi-Fi 省電模式，就會：
- ~~[C-3-1] 必須~~ 應該在應用程式取得 WIFI_MODE_FULL_HIGH_PERF 透過 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() 鎖定 WIFI_MODE_FULL_HIGH_PERF 時關閉 Wi-Fi 省電模式WIFI_MODE_FULL_LOW_LATENCY
7.4.3 藍牙
查看修訂版本

如果裝置的實作支援藍牙低功耗 (BLE)，即支援：
- [C-3-5] 當裝置主動使用 BLE 掃描或廣告時，「必須」實作可撤銷的私人網址 (RPA) 逾時時間不得超過 15 分鐘，並在逾時時輪替地址，以保護使用者隱私。為防止時間攻擊，逾時間隔也「必須」在 5 到 15 分鐘之間隨機進行。
7.5.5 相機方向
查看修訂版本

如果裝置實作方式有前置或後置鏡頭(例如：
- [C-1-1] 必須清楚顯示方向，讓攝影機的長邊對齊螢幕的長邊。也就是說，如果裝置以橫向的方向拿著，相機就「必須」拍攝橫向的影像。無論裝置的自然方向為何，這都會適用，也就是適用於橫向和直向的裝置。
凡是符合下列所有條件的裝置，就不受上述規定限制：
- 裝置會實作可變幾何圖形的螢幕，例如折疊式或轉軸顯示螢幕。
- 當裝置的折疊或轉軸狀態變更時，裝置會將螢幕方向切換為橫向-primary (或相反)。
終止新規定

9. 安全性模型相容性

9.11 金鑰和憑證
查看修訂版本

如果實作的裝置支援安全螢幕鎖定，它會：
- [C-1-6] 必須支援 IKeymasterDevice 4.0、IKeymasterDevice 4.1、IKeyMintDevice 版本 1 或 IKeyMintDevice 2。
9.17 Android 虛擬化架構
查看修訂版本

如果裝置實作 Android 虛擬化架構 API (android.system.virtualmachine.*) 的支援功能，Android 主機會執行以下動作：
- [C-1-3] 「不得」修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 中提供的不允許規則，且這項政策必須全部以一律不允許的規則進行編譯。
如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*) 的支援，即為任何 Protected Virtual Machine 執行個體：
- ~~[C-2-4] 不得修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 中提供的系統/sepolicy/microdroid 中的永不允許規則。~~
如果裝置實作 Android Virtualization Framework API 的支援功能，則針對金鑰管理機制：
- [C-6-2] 請務必正確做 DICE，亦即提供正確的值。 ~~但可能不需要這麼精細的細節。~~

2022 年 8 月 15 日

2. 裝置類型

2.2.1 硬體：硬體需求的變更如下。
- 輸入裝置：
  查看修訂版本
  
  手持裝置實作方式：
  [7.2.3/H-0-5] 當返回手勢啟動或按下返回按鈕 (KEYCODE_BACK) 時，必須在目前聚焦的視窗中呼叫 OnBackInvokedCallback.onBackStarted()。
  
  [7.2.3/H-0-6] 發出返回手勢或返回按鈕 (向上) 時，必須呼叫 OnBackInvokedCallback.onBackInvoked()。
  
  [7.2.3/H-0-7] 在未修訂返回手勢或 KEYCODE_BACK 事件取消時，必須呼叫 OnBackInvokedCallback.onBackCancelled()。
  
  終止新規定
  如果裝置透過宣告 PackageManager.FEATURE_WIFI_RTT 來支援 Wi-Fi 和 Wi-Fi 位置 (Wi-Fi 封包往返時間 - RTT)，即可支援 Wi-Fi 鄰近感知網路 (NAN) 通訊協定，那麼：PackageManager.FEATURE_WIFI_AWARE
  
  [7.4.2.5/H-1-1] 必須正確回報在第 68 個百分位數 (以第 160 MHz 測量到 160 MHz 至 160 MHz 至 160 MHz 之間) 範圍內，+/-2 公尺 (在第 80 MHz 時為第 80 MHz 的頻寬範圍)，+/-2 公尺 (第 80 MHz 時為第 80 MHz 的頻寬，以及第 80 MHz 的第 80 MHz 頻寬，以及第 80 MHz 至 80%)。
  
  [7.4.2.5/H-SR] 明顯建議，在第 90 個百分位數 (以第 90 個百分位數為 160 MHz 時) 內偵測到 Wi/-1 頻寬，並在第 90 MHz 時為第 90 公分，在頻寬第 80 MHz 時為第 90 公分 +/90 公尺。在頻寬 90 MHz 時為第 90 公分
  
  我們強烈建議您遵循「在家狀態校正規定」中所述的評估設定步驟。
  
  終止新規定
- 音訊延遲：
  查看修訂版本
  
  如果手持裝置實作項目宣告 android.hardware.audio.output 和 android.hardware.microphone，兩者會：
  - [5.6/H-1-1] 平均連續往返延遲時間不得超過 500 ~~800~~ 毫秒，且在超過 5 次測量時，平均絕對差小於 50 ~~100~~ 毫秒；如果支援又循環的 USB 3 核心。~~至少一個支援的路徑。~~
  [5.6/H-1-1] 在喇叭到麥克風資料路徑上，至少須有 5 次測量，且輕觸音調延遲時間平均不得超過 500 毫秒。
  
  終止新規定
- 觸覺技術輸入：
  查看修訂版本
  
  如果手持裝置實作包含至少一項觸覺回饋器，行為器就會：
  - [7.10/H]* 不應使用超遠旋轉質量 (ERM) 觸動式致動器 (震動器)。
  - [7.10/H]* 應將執行器擺在一般手持或觸碰裝置的位置。
  - [7.10/H]* 應在 android.view.HapticFeedbackConstants 中實作清楚觸覺回饋的所有公開常數 (CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、KEYBOARD_RELEASE、KEYBOARD_TPREURE_VILOREKEY_REKEY_VIKEY_RETEXT、CONLOREKEY_VISHSERT、GNG_VISERT)。
  - [7.10/H]* 應在 android.os.VibrationEffect 中為清晰的觸覺回饋 (例如 FLEDGE_TICK、ef_CLICK、FLEDGE_HEAVY_CLICK 和 effective_DOUBLE_CLICK) 和所有可行的公開 PRIMITIVE_* Viposition 常數{/1.4IVE 常數只有在震動器能夠支援相對較低的頻率時，才能使用上述部分基元 (例如 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()，驗證振幅擴充性的能力。~~
  如果手持裝置實作包含至少一項線性共振致動器，他們會：
  - [7.10/H]* 應在直向螢幕方向的 X 軸 (右) 移動觸覺致動器。
  - [7.10/H]* 如果需要為不支援的基元進行備用設定，應按照常數的實作指南中的說明進行驗證及更新。
  - ~~[7.10/H]* 應提供備用支援，以降低執行失敗的風險，如這裡所述。~~
2.2.3 軟體：
- 驗證三部裝置主機：
  查看修訂版本
  - [3.8.16/H-1-5] 必須為使用者提供授權，選擇停用第三方應用程式透過 ControlsProviderService 和 Control Control.isAuthRequired API 註冊的控制選項，停用第三方應用程式指定的驗證裝置控制項。
- MediaStyle 通知：
  查看修訂版本
  
  如果手持裝置實作支援 MediaStyle 通知：
  - [3.8.3.1/H-1-SR] 強烈建議使用者透過系統 UI 存取此工具(例如「輸出切換器」)，讓使用者在應用程式發布含有 MediaRouter2Manager 的 MediaStyle 權杖通知時，切換可用的媒體路徑(例如藍牙裝置和提供給 MediaRouter2Manager 的路徑)。
2.2.4 效能和電源：針對執行前景服務的應用程式製定新規定。
查看修訂版本
手持裝置實作方式：
- [8.5/H-0-1]「必須」在「設定」選單中為使用者提供用途，以便停止執行前景服務的應用程式，並顯示所有具備有效前景服務的應用程式，以及這些服務的持續時間 (如 SDK 文件所述)。
  
  如 SDK 文件中所述，部分應用程式可能不受停止，或是列入這類使用者預設用途的範圍內。
終止新規定

2.2.7.1 媒體：「手持需求媒體」一節的更新如下：

查看修訂版本

如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：

[5.1/H-1-1] 必須通告可透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法在任何轉碼器組合中同時執行的硬體視訊解碼器工作階段數量上限。
[5.1/H-1-2] 以 1080p 解析度@30 fps 同時執行的任何轉碼器組合，都必須支援 6 個硬體視訊解碼器工作階段執行個體 (AVC、HEVC、VP9、AV1 或以上)。
[5.1/H-1-3] 「必須」通告可透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法在任何轉碼器組合中並行執行的硬體視訊編碼器工作階段數量上限。
[5.1/H-1-4] 在任何以 1080p 解析度@30fps 執行的轉碼器組合中，必須支援 6 個硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或以上) 執行個體。
[5.1/H-1-5] 必須通告可在任何轉碼器組合中同時透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法執行的硬體視訊編碼器和解碼器工作階段數量上限。
[5.1/H-1-6] 以 1080p@30fps 解析度並行執行的所有轉碼器組合，都必須支援 6 個硬體視訊解碼器和硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或以上) 的執行個體。
[5.1/H-1-7] 針對 1080p 以下的所有硬體視訊編碼器，在負載不足的情況下，轉碼器初始化延遲時間不得超過 40 毫秒。此處載入定義為使用硬體視訊轉碼器和 1080p 音訊錄影初始化的 1080p 至 720p 純影片轉碼工作階段。
[5.1/H-1-8] 在負載下，128 kbps 的轉碼器初始化延遲時間不得超過 30 毫秒；如果音訊編碼器處於載入狀態，則所有音訊編碼器的位元率音訊編碼工作階段都必須低於 30 毫秒。此處載入定義為使用硬體視訊轉碼器和 1080p 影音錄製初始化的 1080p 至 720p 純視訊轉碼工作階段。
[5.1/H-1-9] 必須支援以 1080p 解析度@30 fps 同時執行的任何轉碼器組合，支援 2 個安全硬體視訊解碼器工作階段執行個體 (AVC、HEVC、VP9、AV1 或以上)。
[5.1/H-1-10] 對於以 1080p 解析度@30fps 同時執行的轉碼器組合，必須支援 3 個不安全的硬體視訊解碼器工作階段執行個體，以及 1 個安全硬體視訊解碼器工作階段執行個體 (共 4 個執行個體) (AVC、HEVC、VP9、AV1 或以上版本)。
[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 硬體解碼器支援底片顆粒。
[5.1/H-1-15] 至少須有 1 個支援 4K60 的硬體視訊解碼器。
[5.1/H-1-16] 至少必須使用 1 個支援 4K60 的硬體視訊編碼器。
[5.3/H-1-1] 在載入 1080p 60 fps 影片的情況下，「不得」在 10 秒內捨棄超過 1 個影格 (也就是影格遺失率低於 0.167%)。載入定義為使用硬體視訊轉碼器和 128 kbps AAC 音訊播放的 1080p 至 720p 純影片轉碼工作階段。
[5.3/H-1-2] 如果在 60 fps 影片載入狀態下播放解析度影片，則「不得」在 10 秒內捨棄超過 1 個影格。載入定義為使用硬體視訊轉碼器和 128 kbps AAC 音訊播放的 1080p 至 720p 純影片轉碼工作階段。
[5.6/H-1-1] 使用 OboeTester 觸控色調測試或 CTS Verifier 點按色調測試時，輕觸音延遲時間必須維持在 80 毫秒以下。
[5.6/H-1-2] 至少使用一個支援的資料路徑，往返音訊延遲時間不得超過 80 毫秒。
[5.6/H-1-3] 必須支援大於 24 位元的音訊，才能輸出超過 3.5 公釐的立體聲音訊插孔；如果透過完整的資料路徑支援低延遲和串流設定，則必須支援使用 USB 音訊。針對低延遲設定，應用程式應在低延遲回呼模式下使用 AAudio。針對串流設定，應用程式應使用 Java AudioTrack。不論是低延遲還是串流設定，HAL 輸出接收器都應接受 AUDIO_FORMAT_PCM_24_BIT、AUDIO_FORMAT_PCM_24_BIT_PACKED、AUDIO_FORMAT_PCM_32_BIT 或 AUDIO_FORMAT_PCM_FLOAT 做為目標輸出格式。
[5.6/H-1-4] 必須支援超過 4 個聲道的 USB 音訊裝置 (DJ 控制器會使用此裝置來試聽歌曲)。
[5.6/H-1-5] 必須支援符合類別規範的 MIDI 裝置，並宣告 MIDI 功能標記。
[5.7/H-1-2] 必須支援具備下列內容解密功能的 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL。

樣本大小下限	4 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 Camera：媒體效能類別相機功能的更新。
查看修訂版本
如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：
- [7.5/H-1-1] 「必須」使用主要後置鏡頭，解析度至少為 1,200 萬像素，且支援拍攝每秒 4k@30fps 影片。主要後置鏡頭是相機 ID 最低的後置鏡頭。
- [7.5/H-1-2] 「必須」使用主要前置鏡頭，解析度至少 500 萬像素，且支援拍攝格式為 1080p@30fps 的影片。主要前置鏡頭是前置鏡頭，相機 ID 最低。
- [7.5/H-1-3] 這兩個主要相機都必須支援 android.info.supportedHardwareLevel 屬性為 FULL 或更好。
- [7.5/H-1-4] 兩個主要相機都必須支援 CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME。
- [7.5/H-1-5] 兩台主鏡頭在 1080p 解析度下，至少要有 1000 毫秒的 camera2 JPEG 擷取延遲時間 < 1000 毫秒，這是 CTS 鏡頭效能 Test 在 ITS 照明條件 (3000K) 下所測得的結果。
- [7.5/H-1-6] 這兩台主鏡頭的啟動延遲時間 (開啟相機到第一個預覽影格) 必須小於 500 毫秒，而這是 CTS 鏡頭效能 Test 在 ITS 照明條件 (3000K) 下所測得的結果。
- [7.5/H-1-8] 必須支援主要後置鏡頭的 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW 和 android.graphics.ImageFormat.RAW_SENSOR。
- [7.5/H-1-9] 「必須」使用支援 720p 或 1080p 的後置主要鏡頭 @ 240fps。
- [7.5/H-1-10] 如果超廣角 RGB 相機朝向相同方向，主要相機必須設定最小 ZOOM_RATIO < 1.0。
- [7.5/H-1-11] 務必在主要相機上實作並行前置串流。
- [7.5/H-1-12] 必須同時支援主要前置和主要後置鏡頭的 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION。
- [7.5/H-1-13] 如果有多部 RGB 相機的方向相同，則必須支援主要相機的 LOGICAL_MULTI_CAMERA 功能。
- [7.5/H-1-14] 必須同時支援主要前置和主要後置鏡頭的 STREAM_USE_CASE 功能。
終止新規定
2.2.7.3 硬體：硬體的媒體效能類別規定更新。
查看修訂版本
如果手持裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：
- [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.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.T，那麼：
- [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 安全性模型：針對車用裝置的相機權限設下新規定。
查看修訂版本
如果 Automotive 裝置實作宣告了 android.hardware.camera.any，那麼：
- [9.8.2/A-2-1] 當應用程式存取即時相機資料時，「必須」顯示攝影機指標，但如果只有具備 CDD ID [C-3-X] 所述角色的應用程式，才能存取相機，則不需要顯示相機指標。
- [9.8.2/A-2-2] 如果系統應用程式具有可見的使用者介面或直接使用者互動，就不得隱藏相機指標。
終止新規定
2.6.1 平板電腦需求 - 硬體：更新平板電腦螢幕大小規定。
查看修訂版本

Android 平板電腦裝置是指 Android 裝置實作項目，通常符合以下所有條件：
- 螢幕尺寸大於 7 吋且小於 18 吋，以對角線測得的數值。
螢幕大小

[7.1.1.1/Tab-0-1] 螢幕數量必須介於 7 到 18 英寸之間。

3. 軟體

3.2.2 版本參數：已更新 getSerial() 中的 ASCII 字元。

查看修訂版本

[C-0-1] 為了在不同裝置實作項目中提供一致且有意義的值，下表針對這些值在裝置實作項目必須符合哪些格式方面設有額外限制。

參數	詳細說明
getSerial()	「必須」是 (發行或歸還) 一組硬體序號，該序號必須存在於使用相同型號和 MANUFACTURER 的所有裝置上，而且不得重複。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式 “^[a-zA-Z0-9]+$”。

3.2.3.5 條件式應用程式意圖：更新條件式應用程式意圖的相關規定。
查看修訂版本
如果裝置實作項目包含大型螢幕 (一般為螢幕寬度和高度為 600dp 以上)，並支援分割功能，請按照下列步驟操作：
- [C-17-1] 在開啟分割功能的情況下，「必須」具有處理 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY 意圖的活動。活動必須受 android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK 保護，且「必須」啟動從 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI 剖析的 Intent 活動。
終止新規定
3.5.1 應用程式限制：應用程式限制更新。
查看修訂版本

如果裝置實作項目採用專屬機制來限制應用程式(例如變更或限制 SDK 中描述的 API 行為)，且該機制比受限制的應用程式待命值區更嚴格，就會執行以下動作：
- [C-1-1] 必須允許使用者查看受限制的應用程式清單。
- [C-1-2] 「必須」提供使用者預設負擔，才能為每個應用程式開啟 / 關閉所有專屬限制。
- [C-1-3] 除非系統健康狀態不良，否則不得自動套用這些專屬限制，但「可能」會對應用程式套用限制，以偵測應用程式是否出現不良系統的健康狀態，例如 Wake Lock 停滯、長時間執行的服務和其他條件。這些標準可能是由裝置實作者決定，但必須與應用程式對系統健康狀態的影響相關。與系統健康狀態無關的其他條件 (例如應用程式市場熱門程度偏低) 不得做為評估標準。
- [C-1-4] 當使用者手動停用應用程式限制時，「不得」自動為應用程式套用這些專屬限制，且建議使用者套用這些專屬限制。
- [C-1-5] 如果應用程式自動套用這些專屬限制，請務必告知使用者。「必須」在套用這些專屬限制之前的 24 小時內提供這類資訊。
- [C-1-6] 對於來自應用程式的任何 API 呼叫，都必須針對 ActivityManager.isBackgroundRestricted() 方法傳回 true。
- [C-1-7] 「不得」限制使用者明確使用的頂層前景應用程式。
- [C-1-8] 每當使用者開始明確使用應用程式時，必須將應用程式設為頂層前景應用程式，這些專屬限制都必須暫停。
- [C-1-9] 請務必透過 UsageStats 回報所有專屬限制事件。
- [C-1-10] 必須提供公開且明確的文件或網站，說明專屬限制的適用情形。這份文件或網站「必須」可以從 Android SDK 文件連結，且必須包含：
  
  專屬限制的觸發條件。
  
  應用程式的限制和限制方式。
  
  如何讓應用程式不受這類限制限制。
  
  如果應用程式支援使用者可安裝的應用程式豁免資格，可要求免除專屬限制的豁免。
如果應用程式已預先安裝在裝置上，且使用者從未明確使用超過 30 天，[C-1-3] [C-1-5] 不受此限制。

終止新規定
3.8.1 啟動器 (主畫面)：更新支援 monochrome/adaptive-icon。
查看修訂版本
如果裝置實作支援單色圖示，系統會提供以下圖示：
- [C-6-1] 只有在使用者明確啟用時 (例如透過「設定」或「桌布挑選器」選單) 才能使用。
終止新規定
3.8.2 小工具：更新啟動器中的第三方應用程式小工具狀態。
查看修訂版本

如果裝置導入方式支援第三方應用程式小工具，就會：
- [C-1-2] 必須~~直接在啟動器中~~提供 AppWidgets 的內建支援，以及提供使用者介面預設用途，以便新增、設定、查看及移除 AppWidgets。
3.8.3.1 通知呈現方式：清楚說明抬頭通知的定義。

查看修訂版本

抬頭通知指的是在使用者離開使用者所處介面時，系統向使用者顯示的通知。
3.8.3.3 DND (零打擾) / 優先模式：更新並在 DND (零打擾) 功能中加入優先模式。

查看修訂版本

3.8.3.3。DND (零打擾) / 優先模式

如果裝置實作支援 DND 功能 (也稱為優先模式)，就會：
3.8.6 主題：對動態調色盤的新規定。
查看修訂版本

如果裝置實作項目包含畫面或影片輸出內容，就會發生以下情形：
- [C-1-4] 必須產生 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。
  
  「Source color」用於與 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] 未經使用者明確採取動作 (例如按下疊加畫面上的按鈕)，「C-0-1」不得將剪貼簿資料傳送至任何元件、活動、服務或跨任何網路連線，但「9.8.6 內容擷取和應用程式搜尋」中提及的服務則不在此限。
如果內容針對 ClipData.getDescription().getExtras() 包含 android.content.extra.IS_SENSITIVE 的任何 ClipData 項目複製到剪貼簿時，裝置實作會產生使用者可見的預覽：
- [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) 支援，並收到包含 NFC 類型 MIME_TYPE_PROVISIONING_NFC 記錄的 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-7] 不得再註冊任何 DPC 應用程式，做為裝置擁有者應用程式。
- [C-1-2] 除非在將應用程式設為「裝置擁有者」前，以程式輔助方式將零售展示模式設為使用者在螢幕上或於使用者進行互動前，否則「必須」顯示適當的揭露通知 (例如 Android 開放原始碼計畫參照) 並取得使用者確認同意。只有在裝置由擁有者完成應用程式佈建程序前或期間，需要完成某些明確動作，才能進行裝置佈建程序。同意聲明可透過使用者操作或某些程式輔助方法取得，但如 Android 開放原始碼計畫中提及的適當揭露通知，必須在啟動裝置擁有者佈建程序之前顯示。此外，企業用於佈建裝置擁有者的程式輔助裝置擁有者同意聲明機制「不得」幹擾非企業使用的「現成體驗」。
- ~~[C-1-3] 不得以硬式編碼的方式將同意聲明程式碼編寫及禁止使用其他裝置擁有者的應用程式。~~
如果裝置實作宣告了 android.software.device_admin，但也包含專屬的~~裝置擁有者~~裝置管理解決方案，並提供機制，讓解決方案根據標準 Android DevicePolicyManager API 認可，將解決方案中設定的應用程式升級為標準「裝置擁有者」：
- [C-2-1] 必須設有程序來驗證所宣傳的應用程式屬於合法的企業裝置管理解決方案，並已在專屬解決方案中設定，擁有等同於「裝置擁有者」的權限。
- [C-2-2] 在註冊 DPC 應用程式為「裝置擁有者」之前，必須顯示相同的 Android 開放原始碼計畫裝置擁有者同意聲明揭露聲明，與 android.app.action.PROVISION_MANAGED_DEVICE 發起的流程相同。
- [C-2-3] 不得以硬式編碼的方式修改同意聲明狀態，或禁止使用者使用其他裝置擁有者的應用程式。
- ~~在註冊 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。
終止新規定
3.18 聯絡人：新增新聯絡人的資訊。
查看修訂版本
新聯絡人的預設帳戶：Contact Provider 提供 API，可在建立新聯絡人時管理預設帳戶的設定。

如果裝置實作預先載入了聯絡人應用程式，則會預先載入聯絡人應用程式：
- [C-2-1] 必須處理意圖 ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT，以啟動帳戶選取作業的 UI，並在選取帳戶時將設定儲存至聯絡人提供者。
- [C-2-2] 為 ContactsContracts.Contacts.CONTENT_TYPE 和 ContactsContract.RawContacts.CONTENT_TYPE 處理 Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT 時，必須先選取帳戶，才能採用預設的帳戶設定。
終止新規定

4. 應用程式套件的相容性

4. 應用程式封裝相容性：APK 簽署配置版本更新。
查看修訂版本

裝置實作方式：
- [C-0-2] 必須支援使用 APK 簽署配置 v3.1 、APK 簽署配置 v3、APK 簽名配置 v2 和 JAR 簽署來驗證「.apk」檔案。
- [C-0-9] 必須支援使用 APK 簽署配置 v4 和 APK 簽署配置 4.1 版驗證 .apk 檔案。

5. 多媒體相容性

5.1.2 音訊解碼：針對能夠輸出多聲道音訊的解碼器新增規定。
查看修訂版本
如果裝置實作支援透過 android.media.MediaCodec API 中的預設 AAC 音訊解碼器，將多頻道串流 (意即超過兩個頻道) 的 AAC 輸入緩衝區解碼至 PCM，則「必須」支援下列內容：
- [C-7-1] 必須能由應用程式使用解碼 KEY_MAX_OUTPUT_CHANNEL_COUNT 鍵的設定，以控制內容是否會向下混音為立體聲 (使用值 2 時) 或以原生頻道數輸出時 (使用的值等於或大於該數字時)。舉例來說，如果值為 6 以上，則會在提供 5.1 內容時，將解碼器設為輸出 6 個頻道。
- [C-7-2] 解碼時，解碼器「必須」使用 android.media.AudioFormat 常數 (例如：CHANNEL_OUT_5POINT1)，通告用於輸出格式的輸出格式所用的頻道遮罩 (例如：CHANNEL_OUT_5POINT1)。KEY_CHANNEL_MASK
如果裝置實作支援預設 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)，大力宣傳使用 KEY_CHANNEL_MASK 鍵的輸出格式所用的頻道遮罩。
終止新規定
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 啟用錄音功能。 ~~以及目前已啟用的麥克風，第三方應用程式可透過 AudioRecord.getActiveMicrophones() 和 MediaRecorder.getActiveMicrophones() API 存取。~~
5.4.2 語音辨識擷取功能：更新語音辨識音訊串流的規定，並新增麥克風增益等級相關規定。
查看修訂版本

如果裝置實作項目宣告 android.hardware.microphone，就會：
錄製語音辨識音訊串流時，應以大約平坦的振幅與頻率特性 (特別是 ±3 dB、從 100 Hz 至 4000 Hz) 錄製。

請務必使用輸入敏感度集錄製語音辨識音訊串流，讓 1000 Hz 的 90 dB 聲音功率 (SPL) 源能產生 2500 RMS 的 16 位元樣本。
- 應該在中頻範圍中表現出近乎平坦的振幅與頻率特性：特別是從 100 Hz 到 4000 Hz 的 ±3dB，每個用來錄製語音辨識音訊來源的麥克風也要有這種特性。
- [C-SR] 強烈建議在低頻率範圍內展現振幅：特別是從 ±20 dB 的 30 Hz 至 100 Hz 範圍，這是與錄製語音辨識音訊來源的每個麥克風的中頻範圍相比的結果。
- [C-SR] 強烈建議在高頻率範圍內展現振幅：特別是從 4000 Hz 到 22 KHz 的振幅範圍相比，這是與錄製語音辨識音訊來源的每個麥克風的中頻範圍相比的結果。
- 應設定音訊輸入靈敏度，讓每個使用 1000 Hz 音色調音源的 1000 Hz 音調音量來源 (在麥克風旁邊測量) (測量於麥克風旁邊) 時，以 1770 至 3500 的全聲道辨識 RMS 2500 和 3530 度，且錄音精確度為 1770 和 3530 (以 16 db 為 16) 的 RMS 2500 的理想回應。
終止新規定
5.4.6 麥克風強化程度：將麥克風提升等級的要求移至第 5.4.2 節。
查看修訂版本

5.4.6。麥克風音量再升級 [已移至 5.4.2]
如果裝置實作項目宣告 android.hardware.microphone，就會：

中頻範圍應呈現大約平坦的振幅與頻率特性：特別是從 100 Hz 到 4000 Hz 的 ±3dB，每個用來錄製語音辨識音訊來源的麥克風也都應如此。

[C-SR] 強烈建議在低頻率範圍內展現振幅：特別是從 5 Hz 到 100 Hz 的振幅範圍相比，這是與錄製語音辨識音訊來源的每個麥克風的中頻範圍相比而得。

[C-SR] 強烈建議在高頻率範圍內展現振幅：特別是從 ±30 dB 從 4000 Hz 到 22 KHz，對於錄製語音辨識音訊來源的每個麥克風的中頻範圍相比，這點特別明顯。

應設定音訊輸入靈敏度，以便在以 90 dB 音壓等級 (SPL) 播放的 1000 Hz 單色調源產生一個回應，其中 16 位元樣本的 RMS 為 2500 (或每個使用針對浮點/雙精度取樣而使用的語音辨識為 -22.35 dB Full Scale)。
5.5.4 音訊卸載：更新音訊卸載播放要求。
查看修訂版本

如果裝置的導入方式支援音訊卸載播放，就會：
- [C-SR] 極力建議在 AudioTrack gapless API 和 MediaPlayer 的媒體容器中指定相同格式的兩個片段之間，剪輯之間的無間斷音訊內容。
5.6 音訊延遲時間：更新音訊延遲要求。
查看修訂版本

為達成本節目的，請使用下列定義：
冷輸出時基誤差。冷輸出延遲時間值的個別測量結果間的變異性。

冷輸入時基誤差。不同測量冷輸入延遲時間值的變異數。
如果裝置實作項目宣告 android.hardware.audio.output，則必須符合或超過下列規定：
- [C-1-2] 冷輸出延遲時間為 500 毫秒以下。
- [C-1-3] 使用 AAudioStreamBuilder_openStream() 開啟輸出串流需要不到 1000 毫秒的時間。
如果裝置實作宣告 android.hardware.audio.output，則極力建議符合或超過下列規定：
- [C-SR] 說話者資料路徑的冷輸出延遲時間為 100 毫秒或更短。如果現有和新裝置搭載此 Android 版本，我們「一定會」盡可能符合這些需求條件。在未來的平台版本中，我們將需要將冷輸出延遲時間設為 200 毫秒以下，也就是「必須」的情況。
- ~~[C-SR] 盡量減少冷輸出時基誤差。~~
如果裝置實作項目包含 android.hardware.microphone，則必須符合下列輸入音訊規定：
- [C-3-2] 冷輸入延遲時間為 500 毫秒以下。
- [C-3-3] 使用 AAudioStreamBuilder_openStream() 開啟輸入串流需要不到 1000 毫秒的時間。
如果裝置實作項目包含 android.hardware.microphone，強烈建議您符合以下輸入音訊規定：
- [C-SR] 透過麥克風資料路徑，冷輸入延遲時間不超過 100 毫秒。~~如果現有和新裝置搭載此 Android 版本，我們「一定會」盡可能符合這些需求條件。日後推出的平台版本將需要達到 200 毫秒以下的冷輸入延遲時間。~~
[C-SR] 連續輸入延遲時間不超過 30 毫秒。

[C-SR] 盡量減少冷輸入時基誤差。
5.10 專業音訊：更新專業音訊支援的音訊延遲要求。
查看修訂版本

如果裝置實作程序透過 android.content.pm.PackageManager 類別回報 android.hardware.audio.pro 功能支援，那麼這些程式碼會：
- [C-1-2] 必須設定連續往返音訊延遲，具體定義請見5.6 音訊延遲時間一節為 25 毫秒以下~~，而且至少應有 10 毫秒~~，透過至少一個支援的路徑。
- [C-1-5] 必須使用 AAudio 原生音訊 API 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY，才能符合延遲時間和 USB 音訊規定。
- [C-1-8] 在揚聲器對麥克風資料路徑的測量時，輕觸音調的平均延遲時間至少須為 80 毫秒，或更短於 5 次。
- [C-SR] 強烈建議在音訊啟用且 CPU 負載會有所不同時，提供一致的 CPU 效能等級。請使用 Android 應用程式 SynthMark 進行測試。SynthMark 使用的軟體合成器在模擬音訊架構中運作，以測量系統效能。如需基準測試的相關說明，請參閱 SynthMark 說明文件。SynthMark 應用程式必須使用「Automated Test」選項執行，並得到以下結果： * Voicemark.90 >= 32 語音 *延遲時間 mark.fixed.little <= 15 毫秒 * 延遲時間標示.dynamic.little <= 50 msec
- ~~觸控輸入之間的延遲時間應小於或等於 40 毫秒。~~
如果裝置實作項目包含 4 導體 3.5 公釐耳機插孔，則：
- [C-2-1] 必須使用音訊回送連接器，在 5.6 音訊延遲一節定義連續往返音訊延遲時間 (定義為 20 毫秒以下)，以及超過 5 次測量後，在音訊插孔路徑使用音訊回送連接器時，平均絕對差小於 5 毫秒。
5.12 HDR 影片：新增有關 HDR 影片需求的章節。

6. 開發人員工具與選項的相容性

6.1 開發人員工具：更新連線能力和 GPU 核心需求條件。
查看修訂版本

如果裝置的實作支援透過 Wi-Fi 或乙太網路連至主機機器的 ADB 連線，則可執行以下動作：
- [C-4-1] 必須讓 AdbManager#isAdbWifiSupported() 方法傳回 true。
如果裝置的實作支援透過 Wi-Fi 或乙太網路連至主機機器的 ADB 連線，且包含至少一部相機，請按照下列步驟操作：
- [C-5-1] 必須讓 AdbManager#isAdbWifiQrSupported() 方法傳回 true。
- GPU 工作資訊
  
  裝置實作方式：
  
  [C-6-1] 必須實作殼層指令 dumpsys gpu --gpuwork，才能顯示 power/gpu_work_period 核心追蹤記錄點傳回的匯總 GPU 工作資料；如果不支援追蹤點，則不顯示任何資料。Android 開放原始碼計畫實作方式為 frameworks/native/services/gpuservice/gpuwork/。
終止新規定

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 設定檔的規定。
7.2.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 裝置符合這項規定，以便升級至未來平台版本，而這可能為「必要」。
- ~~應實作 Android SDK 文件所述的 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 裝置符合這項規定，以便升級至日後的平台版本，此版本可能為「必要」。
- 請務必按照 Android SDK 文件所述，實作 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。
如果裝置導入的加速計少於 3 軸，就會：
- [C-3-1] 必須導入及回報 TYPE_ACCELEROMETER_LIMITED_AXES 感應器。
- [C-SR] STRONGLY_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] 變異數不得大於 1e-7 rad^2/s^2/Hz (每 Hz 變異數，或每 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] STRONGLY_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 級 (原為簡單性)。這種分類會決定生物特徵辨識感應器必須與平台和第三方應用程式連接的功能。感應器必須滿足下列額外規定，才能將感應器歸類為第 1 級、類別 2 或類別 3。預設感應器會歸類為第 1 級。感應器需要將感應器歸類為「第 2 級」或「第 3 級」，必須符合下列詳細說明。類別 2 和類別 3 的生物特徵辨識功能都會取得其他功能，詳見下文。

如要將生物特徵辨識感應器視為「第 1 級」(先前稱為「便利」) 的裝置實作項目，請執行以下操作：
- [C-1-11] 假冒和假冒者接受率必須高於 30%，同時 (1) 等級 A 簡報攻擊工具 (PAI) 物種的偽接受率和示意圖接受率不得超過 30%，以及 (2) Android 等級 BD 通訊協定的偽證接受率 (以 Android 等級 40% 為單位) 且高於 40%。
終止新規定
如果想將生物特徵辨識感應器視為類別 2 (先前稱為「弱」)，裝置實作項目會：
- [C-2-2] 假冒和冒名錄接受率不得超過 20%，其中 (1) 級 A 簡報攻擊工具 (PAI) 物種的偽接受率未高於 20%，且 (2) 測試等級 BAI 物種的偽接受率 (以 30% 為單位) ，而非高於 30%
如要將生物特徵辨識感應器視為第 3 級 (先前稱為「Strong」) 的裝置實作項目，請執行以下操作：
- [C-3-3] 假冒和冒名錄接受率不得超過 7%，但 (1) 等級：A 型簡報攻擊工具 (PAI) 物種超過 7% 的偽證接受率，(2) 代表等級 BAI 協定的偽證接受率 (以 20% 為單位)
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 無線電的應用程式 (在 NEARBY_devices 權限群組底下) 擁有 UWB_RANGING 權限。
- [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] 在向使用者顯示及控制 SIM 卡資訊的所有可用用途中，必須向所有具備同等群組 UUID 的 SubscriptionInfo 呈現單一訂閱項目。這類用途包括符合 Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS 或 EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS 的設定介面。
- [C-6-6] 不得在可供設定或控制 SIM 卡設定的任何使用者可見用途中，顯示或允許控制具有非空值群組 UUID 和機會位元的任何 SubscriptionInfo。
如果裝置實作項目包含 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] 如果嘗試在偏好的網路類型或允許的網路類型位元遮罩中設定任何 3GPP2 網路類型，一律必須擲回 IllegalArgumentException。
- [C-8-3] 必須從 TelephonyManager#getMeid 傳回空字串。
如果裝置實作支援具有多個通訊埠和設定檔的 eUICC，則：
- [C-11-1] 必須宣告 android.hardware.telephony.euicc.mep 功能旗標。
終止新規定
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] 強烈建議在第 68 個百分位數 (以累積分佈函式計算) 的 1.5 公尺內，正確回報頻寬在 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 藍牙：藍牙相關規定更新。
查看修訂版本

如果實作的裝置支援藍牙音訊設定檔，就會：
- 應支援採用 A2DP 的進階音訊轉碼器和藍牙音訊轉碼器 (例如 LDAC)。
如果裝置實作針對 BluetoothAdapter.isLeAudioSupported() API 傳回 true，就會：
- [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 單點傳播用戶端。
如果裝置實作針對 BluetoothAdapter.isLeAudioBroadcastSourceSupported() API 傳回 true，就會：
- [C-8-1] 單一 BIG 中至少須支援 2 個 BIS 連結。
- [C-8-2] 必須同時啟用 BAP 廣播來源和 BAP 廣播助理。
- [C-8-3] 必須支援 LE 定期廣告。
如果裝置實作針對 BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API 傳回 true，就會：
- [C-9-1] 必須支援 PAST (定期廣告同步傳輸)。
- [C-9-2] 必須支援 LE 定期廣告。
如果裝置實作項目宣告 FEATURE_BLUETOOTH_LE，就會：
- [C-10-1] 在近視環境中透過 ADVERTISE_TX_POWER_HIGH 傳輸的參考裝置時，其 RSSI 測量值必須落在 +/-9dB 內，兩者距離必須在 1 公尺的範圍內。
- [C-10-2] 必須加入 Rx/Tx 修正來減少每管道偏差的情況，讓三個通道 (如果使用多個) 的測量結果相差 95%。
- [C-SR] 強烈建議「務必」測量及補償 Rx 偏移，確保 BLE RSSI 與在 ADVERTISE_TX_POWER_HIGH 傳輸的參考裝置相距 1 公尺為 -60dBm +/-10 dB，其方向為「平行平面」，且螢幕朝向相同方向的螢幕。
- [C-SR] 強烈建議「請務必」測量並補償 Tx 偏移，確保 BLE RSSI 從位於 1 公尺距離的參考裝置進行掃描時，在 ADVERTISE_TX_POWER_HIGH 進行傳輸 (裝置方向為平行的方向，且螢幕朝向同一方向) 時，可確保 BLE RSSI 的中位數為 -60dBm +/-10 dB。
我們強烈建議您遵循「在家狀態校正規定」中所述的評估設定步驟。

如果裝置的實作支援藍牙 5.0 版，就會發生以下情形：
- [C-SR] 強烈建議你為下列項目提供支援：
  
  低 200 萬階段
  
  LE 轉碼器 PHY
  
  LE 廣告額外資訊
  
  定期廣告
  
  至少 10 個廣告集
  
  至少 8 個 LE 並行連線。每個連線都能屬於任一連線拓撲角色。
  
  LE Link 層隱私權
  
  「解析清單」大小至少要有 8 個項目
終止新規定
7.4.9 UWB：新增 UWB 硬體的要求部分。
查看修訂版本
7.4.9。UWB

如果裝置實作程序透過 android.content.pm.PackageManager 類別回報功能 android.hardware.uwb 支援，那麼：
- [C-1-1] 必須確保距離測量結果在距離 95% 以內，且距離為 95% 且距離非反射腔室時，兩者之間的距離不得超過 +/-15 公分。
- [C-1-2] 必須確保在參考裝置中，1 公尺的距離測量中位數介於 [0.75m, 1.25m] 內，其中地面實際距離是由雙手朝上且傾斜的 45 度角所測量而得。
我們強烈建議您遵循「在家狀態校正規定」中所述的評估設定步驟。

終止新規定
7.5 相機：更新 HDR 10 位元輸出功能的規定。
查看修訂版本
如果裝置的實作支援 HDR 10 位元輸出功能，就會：
- [C-2-1] 凡是支援 10 位元輸出的相機裝置，都至少須支援 HLG HDR 設定檔。
- [C-2-2] 必須支援 10 位元輸出，供主要後置鏡頭或主要前置鏡頭使用。
- [C-SR] 強烈建議同時支援兩台主鏡頭的 10 位元輸出內容。
- [C-2-3] 邏輯相機的所有 BACKWARD_COMPATIBLE 實體子相機和邏輯相機本身，都必須支援相同的 HDR 設定檔。
如果邏輯相機裝置支援實作 android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API 的 10 位元 HDR，這些裝置會執行以下動作：
- [C-3-1] 必須支援透過邏輯相機上的 CONTROL_ZOOM_RATIO 控制項，在所有回溯相容的實體相機之間切換。
終止新規定
7.7.2 USB 主機模式：雙角色通訊埠的修訂版本。
查看修訂版本

如果裝置實作項目包含支援主機模式和 USB Type-C 的 USB 連接埠，就會：
- [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 傳回非零值，就會：
- [C-1-3] 必須符合第 2.2.7 節所述的「媒體效能類別」所有規定。
換句話說，Android T 中的媒體效能類別僅為版本為 T、S 或 R 的手持裝置定義。

終止新規定
請參閱第 2.2.7 節，瞭解裝置專屬的需求。

9. 安全性模型相容性

9.1 權限：將預先安裝應用程式的權限許可清單延伸至 APEX 檔案。
查看修訂版本
- [C-0-2] 具有 PROTECTION_FLAG_PRIVILEGED 的 protectionLevel 權限，「必須」只授予安裝在系統映像檔 (以及 APEX 檔案) 中預先安裝的應用程式，且每個應用程式都必須位於已明確加入許可清單的許可權限子集內。Android 開放原始碼計畫實作項目符合這項規定，方法是透過 system/priv-app 中檔案的權限，使用 system/priv-app 中每個檔案的特殊權限路徑，並授予允許權限的所有權限。etc/permissions/
9.7 安全性功能：更新初始化需求條件，確保核心完整性。
查看修訂版本

核心完整性和自我保護功能是 Android 安全性中不可或缺的一環。裝置實作方式：
- [C-SR] 強烈建議在核心中啟用堆疊初始化，避免使用未初始化的本機變數 (CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO)。此外，裝置實作也不應假設編譯器用於初始化本機變數的值。
終止新規定
9.8.7 隱私權 - 剪貼簿存取權：在剪下/複製/貼上活動後 60 分鐘後自動清除剪貼簿資料，以保護使用者隱私。
查看修訂版本

裝置實作方式：
- [C-0-1] 「不得」傳回剪貼簿中的剪輯資料 (例如透過 ClipboardManager API)，除非第三方應用程式為預設 IME，或者是目前聚焦的應用程式。
- [C-0-2] 剪貼簿資料最後放到剪貼簿或從剪貼簿讀取後，最多 60 分鐘才能清除這些資料。
9.11 金鑰和憑證：更新安全螢幕鎖定要求，包括對加密演算法新增 ECDH 和 3DES。
查看修訂版本

如果實作的裝置支援安全螢幕鎖定，它會：
- [C-1-2] 必須實作 RSA、AES、ECDSA、ECDH (如果支援 IKeyMintDevice)、3DES 和 HMAC 加密編譯演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在上述區域安全地隔離 Android KeyStore 系統支援的演算法，並在上述程式碼中執行這些程式碼。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。上游 Android 開放原始碼計畫 (AOSP) 採用 Trusty 實作項目來符合這項規定，但另外，以 ARM TrustZone 解決方案或第三方審查的安全實作方式為採用適當的管理程序隔離措施。
9.11.1 安全螢幕鎖定、驗證和虛擬裝置：新增虛擬裝置和驗證移轉作業的需求一節。
查看修訂版本

如果裝置實作方式新增或修改用於解鎖螢幕鎖定的驗證方法，且會根據實體權杖或位置採用新的驗證方法：
- [C-6-3] 至少每 4 小時須要求使用者以任一建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 進行驗證。如果實體權杖符合 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] 如 DevicePolicyManager.setNearbyAppStreamingPolicy 指示，「必須」停用透過 VirtualDeviceManager 建立相關輸入事件的功能
- [C-10-7] 「必須」針對每部虛擬裝置使用個別的剪貼簿 (或針對虛擬裝置停用剪貼簿)
- [C-10-11] 必須在虛擬裝置上停用驗證 UI，包括知識因素輸入和生物特徵辨識提示
- [C-10-12] 必須限制從虛擬裝置啟動的意圖，僅顯示在同一部虛擬裝置上
- [C-10-13] 不得使用虛擬裝置鎖定狀態做為 Android KeyStore 系統的使用者驗證授權。詳情請參閱 KeyGenParameterSpec.Builder.setUserAuthentication*。
如果可讓使用者將主要驗證知識因子從來源裝置轉移至目標裝置 (例如進行目標裝置的初始設定)，會執行以下動作：
- [C-11-1] 將知識因素從來源裝置傳輸到目標裝置時，「必須」為知識要素加密 (類似 Google Cloud Key Vault 服務安全性白皮書中所述)，以免知識因子無法從遠端解密，或是用來從遠端解鎖任一裝置。
- [C-11-2] 「必須」在來源裝置上要求使用者確認來源裝置的知識，再將知識因素傳送到目標裝置。
- [C-11-3] 在缺少任何主要驗證知識的目標裝置上，「必須」要求使用者先確認目標裝置上的知識因素已傳輸，再將其設定為目標裝置的主要驗證知識因素，以及從來源裝置傳輸的任何資料。
如果裝置實作項目具有安全螢幕鎖定畫面，且包含一或多個信任代理程式，就會使用 FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 標記呼叫 TrustAgentService.grantTrust() System API：
- [C-12-1] 只有在連線至本身有螢幕鎖定功能的鄰近實體裝置，以及使用者針對該螢幕鎖定畫面驗證身分時，才需要使用旗標呼叫 grantTrust()。在使用者單次解鎖後，Proxi 裝置可使用腕上或人體感測機制，滿足使用者驗證要求。
- [C-12-2] 螢幕關閉時 (例如按下按鈕或顯示螢幕逾時)，且 TrustAgent 未撤銷信任時，必須將裝置實作加入 TrustState.TRUSTABLE 狀態。AOSP 符合這項規定。
- [C-12-3] 如果 TrustAgent 仍根據 C-12-1 的規定授予信任，則「必須」將裝置從 TrustState.TRUSTABLE 移至 TrustState.TRUSTED 狀態。
- [C-12-4] 在授予信任、超過 8 小時閒置期間，或與鄰近實體裝置的基本連線中斷時，必須呼叫 TrustManagerService.revokeTrust()。
如果裝置實作項目可讓應用程式建立次要虛擬螢幕，並支援透過 VirtualDeviceManager 等相關輸入事件，且螢幕未標示 VIRTUAL_DISPLAY_FLAG_SECURE，那麼：
- [C-13-8] 必須封鎖含有 android:canDisplayOnRemoteDevices 屬性或中繼資料 android.activity.can_display_on_remote_devices 的活動，以免在虛擬裝置上啟動。
- [C-13-9] 必須封鎖未明確啟用串流的活動，並指出活動會顯示機密內容，包括透過 SurfaceView#setSecure、FLAG_SECURE 或 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS，而無法在虛擬裝置上啟動。
- [C-13-10] 必須停止安裝從虛擬裝置啟動的應用程式。
終止新規定
9.11.2 Strongbox：要求內部攻擊阻力 (IAR) 的必要性。
查看修訂版本

如要驗證裝置是否符合 [C-1-3] 到 [C-1-9] 的規範，裝置實作情形如下：
- [C-SR] 極力建議採用內部攻擊防範機制 (IAR)，也就是說，可存取韌體簽署金鑰的內部人員不得產生韌體，導致 StrongBox 外洩密鑰、規避功能安全性要求，或以其他方式存取敏感的使用者資料。如要實作 IAR，建議您只在透過 IAuthSecret HAL 提供主要使用者密碼時才允許韌體更新。IAR 將成為 Android 14 的「必要」項目。
9.11.3 身分憑證：新增身分憑證系統參照實作的相關資訊。

查看修訂版本

身分憑證系統是由實作 android.security.identity.* 套件中的所有 API 所定義與完成。這些 API 可讓應用程式開發人員儲存及擷取使用者身分文件。裝置實作方式：

上游 Android 開放原始碼計畫提供了可信任應用程式 (libeic) 的參考實作，可用於實作身分識別憑證系統。

終止新規定
9.11.4 ID 認證：新增 ID 認證規定的章節。

查看修訂版本

9.11.4。身分證件認證

裝置實作項目必須支援 ID 認證。

終止新規定
9.17 Android 虛擬化架構：新增 Android 虛擬化架構的規定一節。
查看修訂版本
9.17。Android 虛擬化架構

如果裝置實作 Android 虛擬化架構 API (android.system.virtualmachine.*) 的支援功能，Android 主機會執行以下動作：
- [C-1-1] 必須支援 android.system.virtualmachine.* 套件定義的所有 API。
- [C-1-2] 不得修改 Android SELinux 和權限模型，以管理受保護的虛擬機器。
- [C-1-3] 「不得」修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 中列出的不允許規則，且在編譯政策時「必須」採用所有一律不允許的規則。
- [C-1-4] 不得允許不受信任的程式碼 (例如第三方應用程式) 建立及執行 Protected Virtual Machine。注意：日後的 Android 版本中可能會發生變更。
- [C-1-5] 「不得」允許受保護虛擬機器執行原廠映像檔或其更新以外的程式碼。任何不屬於 Android 驗證開機程序的內容 (例如從網際網路下載或側載的檔案) 都「不得」在受保護的虛擬機器中執行。
如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*) 的支援功能，則代表所有 Protected Virtual Machine 執行個體：
- [C-2-1] 必須能夠執行 Protected Virtual Machine 中的虛擬化 APEX 中提供的所有作業系統。
- [C-2-2] 不得允許受保護的虛擬機器執行未經裝置實作者或 OS 廠商簽署的作業系統。
- [C-2-3] 「不得」允許受保護的虛擬機器以程式碼形式執行資料 (例如 SELinux 一律不允許 execmem)。
- [C-2-4] 不得修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 中提供的系統/sepolicy/microdroid 中的永不允許規則。
- [C-2-5] 即使對非 Microdroid 作業系統，也必須採用受保護的虛擬機器深度防禦機制 (例如 pVM 適用的 SELinux)。
- [C-2-6] 必須確保 pVM 韌體無法驗證初始映像檔時，會拒絕啟動。
- [C-2-7] 必須確保 instance.img 的完整性遭入侵時，pVM 韌體會拒絕啟動。
如果裝置實作 Android Virtualization Framework API (android.system.virtualmachine.*) 的支援，則管理程序：
- [C-3-1] 除非頁面擁有者明確分享，否則「不得」允許任何 pVM 存取屬於其他實體 (例如其他 pVM 或管理程序) 的頁面。其中包括主機 VM。CPU 和 DMA 存取均適用此規定。
- [C-3-2] 網頁已供 VM 使用後，請「務必」抹除頁面內容，再將該頁面傳回主機 (例如 pVM 遭刪除)。
- [C-3-3] 「必須」確保在 pVM 中的任何程式碼之前，已載入並執行 pVM 韌體。
- [C-3-4] 必須確保提供給 pVM 執行個體的 BCC 和 CDI 只能透過該特定執行個體衍生。
如果裝置實作 Android 虛擬化架構 API 的支援功能，則請針對所有區域：
- [C-4-1] 不得向允許略過 Android 安全性模型的 pVM 提供功能。
如果裝置實作 Android 虛擬化架構 API 的支援功能，則：
- [C-5-1] 必須支援 ART 執行階段更新的隔離編譯功能。
如果裝置實作 Android Virtualization Framework API 的支援功能，則針對金鑰管理機制：
- [C-6-1] 根 DICE 鏈結必須在使用者無法修改的地方 (即使是在解鎖的裝置中亦然)。(這是為了確保不被假冒)。
- [C-6-2] 請務必正確做 DICE，亦即提供正確的值。但可能不需要這麼精細的細節。
終止新規定

13. 與我們聯絡

您可以加入 android-compatibility 論壇，詢問有關文件未涵蓋的問題或提出任何問題。