Android 17 相容性定義 [預先發布版]

1. 簡介

本文列出裝置必須符合的規定，才能與 Android 17 相容。

「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」的使用方式，均符合 RFC2119 中定義的 IETF 標準。

本文所用的「裝置實作人員」或「實作人員」是指開發執行 Android 17 的硬體/軟體解決方案的個人或機構。「裝置實作」或「實作」是指開發的硬體/軟體解決方案。

如要視為與 Android 17 相容，裝置實作內容必須符合本相容性定義中列出的規定，包括透過參照併入的任何文件。

如果本定義或第 10 節所述的軟體測試未提及、含糊不清或不完整，裝置實作人員有責任確保與現有實作項目相容。

因此，Android 開放原始碼計畫是 Android 的參考實作項目，也是首選實作項目。強烈建議裝置實作者盡可能以 Android 開放原始碼計畫提供的「上游」原始碼為基礎進行實作。雖然理論上可以替換部分元件，但強烈建議不要這麼做，因為這樣會大幅增加通過軟體測試的難度。實作人員有責任確保行為與標準 Android 實作項目完全相容，包括 Compatibility Test Suite 內外的項目。最後請注意，本文明確禁止某些元件替換和修改作業。

本文件連結的許多資源直接或間接衍生自 Android SDK，功能與該 SDK 說明文件中的資訊相同。如果本相容性定義或相容性測試套件與 SDK 說明文件不一致，則以 SDK 說明文件為準。本文件中連結資源提供的任何技術細節，都視為本相容性定義的一部分。

1.1 文件結構

1.1.1. 各裝置類型的需求

第 2 節包含適用於特定裝置類型的所有規定。第 2 節的每個子節都專門介紹特定裝置類型。

適用於任何 Android 裝置實作的其他所有需求條件，都列在「第 2 節」之後的各節中。 本文將這些需求稱為「核心需求」。

1.1.2. 需求 ID

MUST 需求會指派需求 ID。

  • ID 僅適用於「必須」要求。
  • 強烈建議遵守的規定會標示為 [SR]，但不會指派 ID。
  • ID 包含：裝置類型 ID - 條件 ID - 需求 ID (例如 C-0-1)。

各 ID 的定義如下：

  • 裝置類型 ID (詳情請參閱第 2 節裝置類型)
    • C：核心 (適用於所有 Android 裝置實作的規定)
    • H：Android 手持裝置
    • T：Android TV 裝置
    • 答：Android Automotive 實作
    • W：Android Watch 實作
    • 分頁：Android 平板電腦導入作業
  • 條件 ID
    • 如果條件為無條件，則此 ID 會設為 0。
    • 如果需求條件為條件式，則第 1 個條件會指派 1，且同一節和同一裝置類型中的數字會遞增 1。
  • 需求 ID
    • 這個 ID 從 1 開始，並在同一區段和同一條件內遞增 1。

1.1.3. 第 2 節中的需求 ID

第 2 節中的需求 ID 分為兩部分。第一個對應於上述的區段 ID。第二部分會識別外型規格和外型規格專屬需求。

區段 ID，後面接著上述需求 ID。

  • 第 2 節中的 ID 包含： 節 ID / 裝置類型 ID - 條件 ID - 需求 ID (例如 7.4.3/A-0-1)。

2. 裝置類型

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

本節將說明這些裝置類型，以及適用於各裝置類型的其他規定和建議。

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

2.1 裝置設定

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

2.2. 手持裝置需求

Android 手持裝置是指通常以手持方式使用的 Android 裝置實作項目，例如 MP3 播放器、手機或平板電腦。

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

  • 使用可提供行動力的電源，例如電池。
  • 實體對角線螢幕尺寸介於 4 吋至 8 吋之間。
  • 具備觸控螢幕輸入介面。

本節其餘部分的額外規定，適用於 Android 手持裝置實作。

2.2.1. 硬體

手持裝置實作方式：

  • [7.1.1.1/H-0-1] 必須至少有一個與 Android 相容的螢幕，短邊至少 2.2 吋，長邊至少 3.4 吋。

  • [7.1.1.3/H-SR-1] 強烈建議提供使用者變更顯示大小 (螢幕密度) 的功能。

  • [7.1.1.1/H-0-2] 必須支援 GPU 合成圖像緩衝區，且緩衝區大小至少要與任何內建螢幕的最高解析度相同。

  • [7.1.1.1/H-0-3]* MUST map each UI_MODE_NORMAL display made available for third party applications onto an unobstructed physical display area that is at least 2.2 inches on the short edge and 3.4 inches on the long edge.

  • [7.1.1.3/H-0-1]* 必須將 DENSITY_DEVICE_STABLE 設為對應螢幕實際物理密度的 92% 以上。

如果手持裝置實作項目支援 Vulkan，則：

Android 17 中變更了需求條件的開始時間

如果手持裝置實作項目宣告支援任何 64 位元 ABI (無論是否支援任何 32 位元 ABI)，並為 ActivityManager.isLowRamDevice() 傳回 false，則：

  • [7.1.4.2/H-2-1] 必須支援 Vulkan 1.1以上版本。

變更後的要求 (2.2.1 > 7.1.4.2/H-2-1)

如果手持裝置實作項目透過 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.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 的應用程式，或是處理 ACTION_ASSIST 的活動，前提是前景活動未處理這些長按事件。KEYCODE_MEDIA_PLAY_PAUSEKEYCODE_HEADSETHOOK

  • [7.3.1/H-SR-1] 強烈建議加入 3 軸加速度計。

如果手持裝置實作項目包含 3 軸式加速度計，則：

  • [7.3.1/H-1-1] 必須能夠以至少 100 Hz 的頻率回報事件。

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

  • [7.3.3/H-2-1] 找到 GNSS 測量資料後，即使尚未回報根據 GPS/GNSS 計算出的位置資訊，也必須立即回報 GNSS 測量資料。

  • [7.3.3/H-2-2] 必須回報 GNSS 虛擬距離和虛擬距離變化率，在判定位置後，於空曠環境中靜止或以小於每平方秒 0.2 公尺的加速度移動時，至少 95% 的時間內，這些資料足以計算出 20 公尺內的位置和 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 自由度的姿勢感應器。

Android 17 新增的規定

如果手持裝置實作項目支援行動數據連線，則：

  • [7.4.1/H-1-1] 必須宣告 android.hardware.telephony.data 功能旗標。

新增規定結束 (2.2.1 > 7.4.1/H-1-1)

支援藍牙 LE 的手持裝置實作方式：

  • [7.4.3/H-SR-1] 強烈建議支援藍牙 LE 資料封包長度擴充功能。

如果裝置實作項目包含 802.11 (Wi-Fi) 支援，則：

如果裝置透過宣告 PackageManager.FEATURE_WIFI_AWARE 支援 Wi-Fi 鄰近感知網路 (NAN) 通訊協定，並透過宣告 PackageManager.FEATURE_WIFI_RTT 支援 Wi-Fi 定位 (Wi-Fi 往返時間 - RTT)，則：

  • [7.4.2.5/H-1-1] 必須準確回報範圍，在 160 MHz 頻寬下，第 68 個百分位數的誤差範圍為 +/-1 公尺 (以累積分布函數計算)，在 80 MHz 頻寬下，第 68 個百分位數的誤差範圍為 +/-2 公尺，在 40 MHz 頻寬下，第 68 個百分位數的誤差範圍為 +/-4 公尺，在 20 MHz 頻寬下，第 68 個百分位數的誤差範圍為 +/-8 公尺，距離為 10 公分、1 公尺、3 公尺和 5 公尺時，透過 WifiRttManager#startRanging Android API 觀察。

  • [7.4.2.5/H-SR-1] 強烈建議在 90 百分位數 (以累積分布函數計算) 的 160 MHz 頻寬下，回報的範圍準確度在 +/-1 公尺內；在 90 百分位數的 80 MHz 頻寬下，回報的範圍準確度在 +/-2 公尺內；在 90 百分位數的 40 MHz 頻寬下，回報的範圍準確度在 +/-4 公尺內；在 90 百分位數的 20 MHz 頻寬下，回報的範圍準確度在 +/-8 公尺內。這些準確度是在 10 公分距離下，透過 WifiRttManager#startRanging Android API 觀察所得。

強烈建議按照「在場校準」一文中的步驟設定評估功能。

Android 17 新增的規定

如果手持式裝置支援 Wi-Fi 附近裝置偵測 (PD) 通訊協定 (宣告 PackageManager.FEATURE_WIFI_PD) 和 Wi-Fi 定位 (Wi-Fi 往返時間 - RTT) (宣告 PackageManager.FEATURE_WIFI_RTT)，則：

  • [7.4.2.10/H-1-1] 必須使用至少 160 MHz 頻寬。

  • [7.4.2.10/H-1-2] 必須透過 WifiRttManager#startRanging Android API 觀察，在第 68 個百分位數 (以累積分布函數計算) 的 160 MHz 頻寬下，準確回報範圍，誤差必須在 +/-0.25 公尺內。

強烈建議按照「在場校正」一文中的步驟設定評估功能。

新增規定結束 (2.2.1 > 7.4.2.10/H-1-1 和 7.4.2.10/H-1-2)

如果手持裝置實作項目宣告 FEATURE_BLUETOOTH_LE，則：

  • [7.4.3/H-1-3] 必須測量並補償 Rx 偏移，確保 BLE RSSI 中位數為 -50 dBm +/-15 dB，且與以 ADVERTISE_TX_POWER_HIGH 傳輸的參考裝置相距 1 公尺。

  • [7.4.3/H-1-4] 必須測量並補償 Tx 偏移，確保從 1 公尺處的參考裝置掃描時，以 ADVERTISE_TX_POWER_HIGH 傳輸的 BLE RSSI 中位數為 -50 dBm +/-15 dB。

Android 17 新增的規定

如果手持裝置實作項目包含至少一個後置鏡頭，則：

  • [7.5.1/H-1-1] 必須具備至少 200 萬像素的解析度。

額外規定結束 (2.2.1 > 7.5.1/H-1-1)

如果手持裝置實作項目包含使用 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 列出功能的邏輯攝影機裝置，則：

  • [7.5.4/H-1-1] 預設必須為正常視野 (FOV)，且必須介於 50 到 90 度之間。

手持裝置實作方式：

  • [7.6.1/H-0-1] 必須提供至少 4 GB 的非揮發性儲存空間，供應用程式的私人資料 (又稱 /data 分割區) 使用。

  • [7.6.1/H-0-2] MUST return "true" for ActivityManager.isLowRamDevice() when there is less than 1 GB of memory available to the kernel and userspace.

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

  • [7.6.1/H-1-1] 如果預設螢幕使用高達 qHD (例如 FWVGA) 的畫面緩衝區解析度，核心和使用者空間可用的記憶體必須至少為 416 MB。

  • [7.6.1/H-2-1] 如果預設螢幕使用 HD+ (例如 HD、WSVGA) 以下的訊框緩衝區解析度，核心和使用者空間可用的記憶體必須至少為 592 MB。

  • [7.6.1/H-3-1] 如果預設螢幕使用高達 FHD (例如 WSXGA+) 的訊框緩衝區解析度，核心和使用者空間可用的記憶體必須至少為 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+ (例如 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] MUST declare the feature flag android.hardware.ram.low.

  • [7.6.1/H-9-2] 應用程式私有資料 (又稱「/data」分割區) 必須至少有 1.1 GB 的非揮發性儲存空間。

如果手持裝置實作項目包含超過 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] 必須僅支援單一 ABI (僅限 64 位元或僅限 32 位元)。

手持裝置實作方式：

  • [7.6.2/H-0-1] 不得提供小於 1 GiB 的應用程式共用儲存空間。

  • [7.7.1/H] SHOULD include a USB port supporting peripheral mode.

如果手持裝置實作項目包含 USB 連接埠和以周邊模式運作的控制器，則：

  • [7.7.1/H-1-1] 必須實作 Android 開放式配件 (AOA) API。

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

手持裝置實作方式：

  • [7.8.1/H-0-1] 必須包含麥克風。

  • [7.8.2/H-0-1] 必須有音訊輸出並宣告 android.hardware.audio.output。

如果手持裝置實作項目能夠滿足支援虛擬實境模式的所有效能需求，且包含支援虛擬實境模式，則：

  • [7.9.1/H-1-1] MUST declare the android.hardware.vr.high_performance feature flag.

  • [7.9.1/H-1-2] MUST include an application implementing android.service.vr.VrListenerService that can be enabled by VR applications via android.app.Activity#setVrModeEnabled.

如果手持裝置實作項目在主機模式中包含一或多個 USB-C 連接埠，且實作 (USB 音訊類別)，則除了第 7.7.2 節中的規定外，還須符合下列條件：

  • [7.8.2.2/H-1-1] 必須提供下列 HID 程式碼的軟體對應：
函式 對應 背景資訊 行為
A HID 用途頁面：0x0C
HID 用途：0x0CD
核心鍵：KEY_PLAYPAUSE
Android 鍵：KEYCODE_MEDIA_PLAY_PAUSE		 媒體播放 輸入：短按
輸出：播放或暫停
輸入：長按
輸出：啟動語音指令
傳送： 如果裝置已鎖定或螢幕關閉，則傳送 android.speech.action.VOICE_SEARCH_HANDS_FREE。否則傳送 android.speech.RecognizerIntent.ACTION_WEB_SEARCH
來電 輸入：短按
輸出：接聽電話
輸入：長按
輸出：拒接來電
通話中 輸入：短按
輸出：結束通話
輸入：長按
輸出：將麥克風設為靜音或取消靜音
B HID 用途頁面：0x0C
HID 用途：0x0E9
核心鍵：KEY_VOLUMEUP
Android 鍵：VOLUME_UP		 媒體播放、通話中 輸入：短按或長按
輸出：調高系統或耳機音量
C HID 用途頁面：0x0C
HID 用途：0x0EA
核心鍵：KEY_VOLUMEDOWN
Android 鍵：VOLUME_DOWN		 媒體播放、通話中 輸入：短按或長按
輸出：降低系統或耳機音量
D HID 用途頁面：0x0C
HID 用途：0x0CF
核心鍵：KEY_VOICECOMMAND
Android 鍵：KEYCODE_VOICE_ASSIST		 全部。可在任何執行個體中觸發。 輸入：短按或長按
輸出：啟動語音指令
  • [7.8.2.2/H-1-2] MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after the USB audio interfaces and endpoints have been properly enumerated in order to identify the type of terminal connected.

偵測到 USB 音訊終端機類型 0x0302 時，系統會：

  • [7.8.2.2/H-2-1] 必須廣播 Intent ACTION_HEADSET_PLUG，並將「microphone」額外設定為 0。

偵測到 USB 音訊終端機類型 0x0402 時，系統會：

  • [7.8.2.2/H-3-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 1.

在 USB 周邊裝置連線時呼叫 API AudioManager.getDevices()，會發生下列情況：

  • 如果 USB 音訊終端機類型欄位為 0x0302，[7.8.2.2/H-4-1] 必須列出類型為 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 音訊周邊裝置時，強烈建議在 1000 毫秒內執行 USB 描述元列舉、識別終端機類型，並廣播意圖 ACTION_HEADSET_PLUG。

如要瞭解宣告 android.hardware.audio.output 和 android.hardware.microphone 的手持裝置實作項目，請參閱第 5.6 節的 RTL 和 TTL 規定。

線性共振致動器 (LRA) 是單一質量彈簧系統，具有主要共振頻率，可讓質量沿著所需運動方向平移。

如果手持裝置導入作業包含至少一個一般用途的7.10線性共振致動器，則：

  • [7.10/H] SHOULD 將致動器放置在裝置通常由手持或觸碰的位置附近。

  • [7.10/H] 應在裝置自然方向的 X 軸 (左右) 中移動觸覺致動器。

如果手持裝置實作項目具有一般用途的觸覺致動器，即 X 軸線性共振致動器 (LRA)，則：

  • [7.10/H] X 軸 LRA 的共振頻率應低於 200 Hz。

如果手持裝置實作項目遵循觸覺常數對應，則：

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)

Android 17 新增的規定

  • [5.1/H-0-6] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

新增規定結束 (2.2.2 > 5.1/H-0-6)

2.2.3. 軟體

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

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

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

  • [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
  • [5.3/H-0-6] AV1

2.2.3. 軟體

手持裝置實作方式：

Android 17 中變更了需求條件的開始時間

  • [3.2.3.1/H-0-2]* 必須預先載入一或多個應用程式或服務元件，並搭配意圖處理常式，適用於這裡列出的所有應用程式意圖所定義的公開意圖篩選器模式。注意：「常見應用程式意圖」頁面會包含新的必要意圖「android.settings.VPN_APP_EXCLUSION_SETTINGS」。

變更後的要求 (2.2.3 > 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] MUST 提供 android.webkit.Webview API 的完整實作。

  • [3.4.2/H-0-1] 必須包含獨立的瀏覽器應用程式，供一般使用者瀏覽網頁。

Android 17 新增的規定

  • [3.8.1/H-0-1] 必須實作支援在應用程式內固定小工具的預設啟動器。

新增規定結束 (2.2.3 > 3.8.1/H-0-1)

  • [3.8.1/H-SR-1] 強烈建議實作支援在應用程式內釘選捷徑、小工具和 widgetFeatures 的預設啟動器。

  • [3.8.1/H-SR-2] 建議您實作預設啟動器，透過 ShortcutManager API 快速存取第三方應用程式提供的其他捷徑。

  • [3.8.1/H-SR-3] 強烈建議加入預設啟動器應用程式，顯示應用程式圖示的徽章。

Android 17 中變更了需求條件的開始時間

  • [3.8.2/H-SR-1] 強烈建議支援第三方應用程式小工具。

  • [3.8.2/H-0-1] 必須支援第三方應用程式小工具。

變更後的需求 (2.2.3 > 3.8.2/H-SR-1)

如果手持裝置實作項目支援 MediaStyle 通知，則：

如果應用程式符合所有宣傳特徵，即可宣傳即時更新通知。 這類通知在本文件中稱為「宣傳的即時更新通知」。手持裝置實作項目「必須」按照下列規定，醒目顯示宣傳的即時更新通知。

如果手持裝置實作項目宣告 API 級別 36.1 以上版本，則：

  • [3.8.3.1/H-0-1] 必須在鎖定螢幕的顯眼位置顯示「宣傳的即時更新通知」。

  • [3.8.3.1/H-0-12] 當「已宣傳的即時更新通知」與其他通知一起顯示時，必須顯示在通知堆疊頂端，且位於抬頭通知和彩色通知 (其中 setColorized 為 true) 上方。

    • 如果有多個應用程式符合「已宣傳的即時更新通知」資格，MAY 會決定通知欄和螢幕鎖定中顯示這類通知的順序。

  • [3.8.3.1/H-0-2] 必須在展開狀態下顯示「宣傳的即時更新通知」。

  • [3.8.3.1/H-0-3] 不得提供使用者可收合上述展開式通知的介面。

  • [3.8.3.1/H-0-4] 必須在「已宣傳的即時更新通知」中顯示文字內容的基本樣式 (粗體、斜體和底線)，如 StyleSpan 或 UnderlineSpan 所提供。

  • [3.8.3.1/H-0-5] 必須只顯示標準動作物件 (透過 Notification.Action)， 並隱藏非標準動作物件，例如輸入框、回覆按鈕和情境動作 (透過 addRemoteInput() 和 setContextual())， 即使通知包含這些物件，在宣傳的即時更新通知中也必須隱藏。

  • [3.8.3.1/H-0-6] 必須顯示精簡表示法 (也稱為狀態晶片，如 SDK 說明文件所述)，以顯示必須包含 Notification.getSmallIcon() 的已宣傳即時更新通知。

    • [3.8.3.1/H-0-7] 其他欄位為精簡表示法的選填欄位，但只要精簡表示法可以展開，就必須顯示 Notification.getShortCriticalText() (如有)，或 Notification.when (如沒有 Notification.getShortCriticalText)。

    • [3.8.3.1/H-0-8] 如果有多則「宣傳的即時更新」通知，狀態列中必須顯示至少一則通知的精簡表示方式。

    • [3.8.3.1/H-0-9] 使用者輕觸精簡表示法時，必須顯示相關聯的通知 (建議) 或開啟相關聯的應用程式 (透過 Notification.contentIntent)。

    • [3.8.3.1/H-0-13] 必須在相關聯的通知中顯示所有相同內容，如同通知欄中顯示的內容。

  • [3.8.3.1/H-0-10] 必須提供使用者介面，讓使用者停用及啟用個別應用程式通知的宣傳顯示。

  • [3.8.3.1/H-0-11] 必須正確顯示所有即時更新通知，包括但不限於不符合或僅部分符合宣傳特徵的非宣傳即時更新通知。這類非宣傳通知「必須」以非宣傳狀態顯示。

如果裝置實作 (包括第 7.2.3 節詳述的「最近使用的應用程式」功能導覽鍵) 會改變介面，則：

  • [3.8.3/H-1-1] 必須實作螢幕固定行為，並提供設定選單供使用者切換這項功能。

如果手持裝置實作支援「輔助」動作，則：

  • [3.8.4/H-SR-2] 強烈建議使用長按 HOME 鍵做為啟動小幫手應用程式的指定互動方式，如第 7.2.3 節所述。必須啟動使用者選取的小幫手應用程式；換句話說，就是實作 VoiceInteractionService 的應用程式，或是處理 ACTION_ASSIST 意圖的活動。

如果手持裝置實作項目支援 conversation notifications，並將其與警示和靜音非對話通知分組到不同區段，則：

  • [3.8.4/H-1-1]* 必須在非對話通知之前顯示對話通知，但持續進行中的前景服務通知和重要性：高通知除外。

如果 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] MUST provide access to this user affordance within three interactions from a default Launcher.

  • [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-1-6] 裝置實作項目「必須」正確顯示使用者可執行的操作，如下所示：

  • [3.8.16/H-1-7] 如果應用程式宣告中繼資料 META_DATA_PANEL_ACTIVITY， 就必須在啟動內嵌活動時，使用 EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS 傳遞 [3.8.16/H-1-5] 中定義的設定。

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

如果手持裝置實作項目未在鎖定任務模式下執行，當內容複製到剪貼簿時，會發生下列情況：

  • [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] 必須支援隨附裝置配對功能。

如果導覽功能是以螢幕上的手勢動作提供：

Android 17 新增的規定

手持裝置實作方式：

  • [3.20.1/H-0-1] 必須實作所有 Google 助理音訊串流需求。

新增要求結束 (2.2.3 > 3.20.1/H-0-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 宣告支援攝影機，則：

如果裝置實作的設定應用程式實作了分割功能 (使用活動嵌入功能)，則：

Android 17 移除的規定

如果裝置實作項目允許使用者撥打任何類型的電話，

已移除的規定 (2.2.3 > 7.4.1.2/H-0-1 和 7.4.1.2/H-0-2)

2.2.4. 效能與電力

  • [8.1/H-0-1] 影格延遲時間一致。 影格延遲時間不一致或影格延遲顯示的情況，每秒不得超過 5 個影格，且應低於每秒 1 個影格。

  • [8.1/H-0-2] 使用者介面延遲。 裝置實作項目必須確保使用者體驗低延遲，方法是在 36 秒內捲動 Android 相容性測試套件 (CTS) 定義的 10,000 個清單項目。

  • [8.1/H-0-3] 工作切換。啟動多個應用程式後，重新啟動已執行的應用程式時，必須在 1 秒內完成。

手持裝置實作方式：

  • [8.2/H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.

  • [8.2/H-0-2] 必須確保隨機寫入效能至少為 0.5 MB/s。

  • [8.2/H-0-3] 必須確保循序讀取效能至少為 15 MB/s。

  • [8.2/H-0-4] 必須確保隨機讀取效能至少為 3.5 MB/s。

如果手持裝置實作項目包含 AOSP 內建或擴充的裝置電源管理改善功能，則：

  • [8.3/H-1-1] MUST provide user affordance to enable and disable the battery saver feature.

  • [8.3/H-1-2] 必須提供使用者介面，顯示所有豁免於應用程式待命和打盹省電模式的應用程式。

手持裝置實作方式：

  • [8.4/H-0-1] 必須提供每個元件的電源設定檔，定義每個硬體元件的電流消耗值，以及元件隨時間造成的概略電池耗電量，如 Android 開放原始碼計畫網站所述。

  • [8.4/H-0-2] MUST report all power consumption values in milliampere hours (mAh).

  • [8.4/H-0-3] 必須回報每個程序的 UID 的 CPU 耗電量。Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目，符合這項規定。

  • [8.4/H-0-4]「必須」透過 adb shell dumpsys batterystats Shell 命令，向應用程式開發人員提供這項耗電量資訊。

  • 如果無法將硬體元件耗電量歸因於應用程式，則 [8.4/H] 應歸因於硬體元件本身。

如果手持裝置實作項目包含螢幕或視訊輸出，則：

手持裝置實作方式：

  • [8.5/H-0-1] 必須提供使用者功能提示，讓使用者查看所有具有有效前景服務或使用者啟動作業的應用程式，包括每個服務的啟動時間長度，如 SDK 文件所述。

  • [8.5/H-0-2]「必須」提供使用者功能提示，讓使用者停止執行前景服務或使用者啟動工作的應用程式。

2.2.5. 安全模式

手持裝置實作方式：

  • [9/H-0-1] 必須聲明 android.hardware.security.model.compatible 功能。

  • [9.1/H-0-1] MUST allow third-party apps to access the usage statistics via the android.permission.PACKAGE_USAGE_STATS permission and provide a user-accessible mechanism to grant or revoke access to such apps in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent.

如果手持裝置實作項目包含支援 VoiceInteractionService 的預設應用程式，則：

  • [9.1/H-0-2] 不得將 ACCESS_FINE_LOCATION 授予該應用程式做為預設值。

裝置實作項目必須聲明支援 android.software.credentials 和：

  • [9/H-0-2] 必須遵守 android.settings.CREDENTIAL_PROVIDER 意圖，允許選取憑證管理工具的偏好供應商。系統會啟用這個提供者，以進行自動填入，並將其設為預設位置，儲存透過 Credential Manager 輸入的新憑證。

  • [9/H-0-3] 必須支援至少 2 個並行憑證供應商，並在「設定」應用程式中提供使用者功能提示，以啟用或停用供應商。

  • [9.5/H-1-1] Android 16 已移除這項規定。

手持裝置實作方式：

  • [9.11/H-0-2] MUST back up the keystore implementation with an isolated execution environment.

  • [9.11/H-0-3] 必須實作 RSA、AES、ECDSA 和 HMAC 密碼編譯演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離「必須」封鎖核心或使用者空間程式碼可能存取隔離環境內部狀態的所有潛在機制，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目，因此符合這項規定，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當 Hypervisor 型隔離安全實作項目。

  • [9.11/H-0-4] MUST perform the lock screen authentication in the isolated execution environment and only when successful, allow the authentication-bound keys to be used. 螢幕鎖定憑證的儲存方式必須僅允許隔離的執行環境執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。

  • [9.11/H-0-5] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。驗證簽署金鑰不得做為永久裝置 ID 使用。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除以下要求：必須有以獨立執行環境為基礎的金鑰儲存區，並支援金鑰認證，除非裝置宣告 android.hardware.fingerprint 功能，而這項功能需要以獨立執行環境為基礎的金鑰儲存區。

如果手持裝置實作項目支援安全螢幕鎖定，則：

  • [9.11/H-1-1] 必須允許使用者選擇最短的螢幕休眠逾時時間，也就是從解鎖狀態轉換為鎖定狀態的時間，不得超過 15 秒。

  • [9.11/H-1-2] 必須提供使用者隱藏通知的功能提示，並停用所有形式的驗證，但 9.11.1 安全螢幕鎖定所述的主要驗證除外。Android 開放原始碼計畫符合鎖定模式的規定。

Android 17 中變更了需求條件的開始時間

如果裝置實作項目具有安全螢幕鎖定功能，且包含一或多個實作 TrustAgentService 系統 API 的信任的代理程式，則：

  • [9.11.1/H-1-1] 必須比每 72 小時一次更頻繁地要求使用者採用建議的主要驗證方式 (例如 PIN 碼、解鎖圖案或密碼)。

如果手持裝置實作項目設有安全螢幕鎖定，且包含一或多個呼叫 TrustAgentService.grantTrust() 系統 API 並使用 FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 旗標的信任的代理程式，則：

  • [9.11.1/H-1-1] TrustManagerService.revokeTrust() 必須在下列任一情況後呼叫：
    • 自授予信任權起，最多 24 小時。
    • 8 小時的閒置時間。

變更要求結束 (2.2.5 > 9.11.1/H-1-1)

如果手持裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，則：

  • [9.5/H-2-1] 必須支援受限設定檔，裝置擁有者可透過這項功能管理其他使用者及其在裝置上的功能。裝置擁有者可以透過受限制的設定檔，為其他使用者快速設定獨立的工作環境，並在這些環境中管理應用程式的細部限制。

如果手持裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能旗標，則：

  • [9.5/H-3-1] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作項目保持一致，以允許 /禁止其他使用者存取語音通話和簡訊。

  • [9.5/H-4-1] Android 16 已移除這項規定。

  • [9.5/H-4-2] Android 16 已移除這項規定。

設定受到限制

「受限設定」會向使用者顯示警告，並要求使用者確認，才能為下列應用程式授予權限：

  • 透過「應用程式商店」應用程式 (PackageManager 識別為 PACKAGE_DOWNLOADED_FILE) 以外的應用程式 (例如訊息應用程式或瀏覽器) 下載後安裝。

  • 從本機檔案安裝 (例如應用程式是側載)，由 PackageManager 識別為 PACKAGE_SOURCE_LOCAL_FILE。

對於以下 [9.8/H-0-5] 列出的任何強制執行權限及其相關聯的 ID。

這類應用程式會標示為「適用應用程式」，並須遵守本節列出的規定。

裝置實作方式：

  • [9.8/H-0-1] MUST implement Restricted Settings as outlined above for the following:

    • 特殊權限

      • 無障礙功能 (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
      • 通知接聽器 (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
      • 裝置管理員應用程式 (Manifest.permission.BIND_DEVICE_ADMIN)
      • 顯示在其他應用程式之上 (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
      • 使用存取權 (AppOpsManager.OPSTR_GET_USAGE_STATS)

    • 角色 (預設應用程式)

      • 撥號器 (RoleManager.ROLE_DIALER)
      • 簡訊 (RoleManager.ROLE_SMS)

    • 執行階段權限

      • 簡訊執行時間 (Manifest.permission_group.SMS)

  • [9.8/H-0-2] 必須預設啟用「受限制的設定」，且強烈建議不要提供任何使用者功能提示，讓使用者停用所有應用程式的「受限制的設定」。

  • [9.8/H-0-3] 必須確保在授予任何強制執行的權限前，取得每個受規範應用程式的使用者確認。

  • [9.8/H-0-4] 只能使用 EnhancedConfirmationManager API，從涵蓋應用程式的 AppInfo 頁面取得使用者確認資訊，以啟用受限設定。

  • [9.8/H-0-5] 強烈建議整合並呼叫 EnhancedConfirmationManager，以取得所有特殊權限，動態判斷是否為受限設定。

    • 鬧鐘和提醒：AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • 所有檔案存取權：AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
    • 顯示在其他應用程式之上：AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
    • 安裝不明應用程式：AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
    • 管理媒體：AppOpsManager.OPSTR_MANAGE_MEDIA
    • 修改系統設定：AppOpsManager.OPSTR_WRITE_SETTINGS
    • 子母畫面：AppOpsManager.OPSTR_PICTURE_IN_PICTURE
    • 開啟螢幕：AppOpsManager.OPSTR_TURN_SCREEN_ON
    • 全螢幕通知：AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
    • Wi-Fi 控制：AppOpsManager.OPSTR_CHANGE_WIFI_STATE
    • 無障礙功能：AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
    • 通知接聽器：AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
    • 使用存取權：AppOpsManager.OPSTR_GET_USAGE_STATS
    • 裝置管理員：Manifest.permission.BIND_DEVICE_ADMIN
    • 零打擾：Manifest.permission.MANAGE_NOTIFICATIONS

Android 透過 System API VoiceInteractionService 支援安全機制，可持續偵測語音啟動字詞，且不會顯示麥克風存取權指標；也可持續偵測查詢內容，且不會顯示麥克風或相機存取權指標。

如果手持裝置實作項目支援 System API HotwordDetectionService 或其他熱字詞偵測機制，且不需麥克風存取權指標，則：

  • [9.8/H-1-1] 必須確保熱字詞偵測服務只能將資料傳輸至系統、ContentCaptureService，或 SpeechRecognizer#createOnDeviceSpeechRecognizer() 建立的裝置端語音辨識服務。

  • [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] MUST NOT allow a user-installable application to provide the hotword detection service.

  • [9.8/H-1-10] 介面中不得顯示有關熱字詞偵測服務麥克風用量的量化資料。

  • [9.8/H-1-11] MUST log the number of bytes included in every transmission from the hotword detection service to allow inspectability for security researchers.

  • [9.8/H-1-12] 必須支援偵錯模式，記錄從熱字偵測服務傳輸的每個原始內容，供安全研究人員檢查。

  • [9.8/H-1-14] 成功將快速鍵結果傳輸至語音互動服務或類似實體時，必須顯示麥克風指標，如第 9.8.2 節所述。

  • [9.8/H-1-15] 必須確保在啟動字詞結果成功時，音訊串流會從啟動字詞偵測服務單向傳輸至語音互動服務。

  • [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 或裝置端語音辨識服務外，熱字偵測服務「不得」傳輸音訊資料、可用於重建 (全部或部分) 音訊的資料，或與熱字本身無關的音訊內容。

如果手持裝置實作項目支援 System API VisualQueryDetectionService 或其他查詢偵測機制，且不需麥克風和/或相機存取權指標，則：

  • [9.8/H-3-1] 必須確保查詢偵測服務只能將資料傳輸至系統、ContentCaptureService 或裝置端語音辨識服務 (由 SpeechRecognizer#createOnDeviceSpeechRecognizer() 建立)。

  • [9.8/H-3-2] 不得允許任何音訊或影片資訊傳輸到 VisualQueryDetectionService 外部，但傳輸到 ContentCaptureService 或裝置端的語音辨識服務除外。

  • [9.8/H-3-3] 裝置偵測到使用者有意與數位助理應用程式互動時 (例如透過攝影機偵測到使用者在場)，必須在系統 UI 中顯示使用者通知。

  • [9.8/H-3-4] 偵測到使用者查詢後，必須立即在 UI 中顯示麥克風指標和偵測到的使用者查詢。

  • [9.8/H-3-5] 不得允許使用者安裝的應用程式提供視覺查詢偵測服務。

如果手持裝置實作項目宣告 android.hardware.microphone，則：

  • [9.8.2/H-4-1] 應用程式從麥克風存取音訊資料時，必須顯示麥克風指標，但如果只有 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或具有 CDD 識別碼 [C-4-X] 的應用程式存取麥克風，則不在此限 (第 9.1 節中列出的角色)。

  • [9.8.2/H-4-2] 必須顯示使用麥克風的「最近使用的應用程式」和「使用中的應用程式」清單 (如 PermissionManager.getIndicatorAppOpUsageData() 傳回)，以及與這些應用程式相關聯的任何出處訊息。

  • [9.8.2/H-4-3] 系統應用程式具有可見的使用者介面或直接使用者互動時，不得隱藏麥克風指標。

  • [9.8.2/H-4-4] 必須顯示使用麥克風的「最近」和「運作中」應用程式清單 (如 PermissionManager.getIndicatorAppOpUsageData() 傳回)，以及與這些應用程式相關聯的任何出處訊息。

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

  • [9.8.2/H-5-1] 應用程式存取攝影機即時資料時，必須顯示相機指標，但如果應用程式僅存取 CDD 識別碼為 [C-4-X] 的第 9.1 節中列出的角色，則不在此限。

  • [9.8.2/H-5-2]「必須」使用 PermissionManager.getIndicatorAppOpUsageData() 傳回的攝影機，顯示最近使用的應用程式和使用中的應用程式，以及與這些應用程式相關聯的任何出處訊息。

  • [9.8.2/H-5-3] 系統應用程式如有可見的使用者介面或直接使用者互動，則不得隱藏相機指標。

Android 17 新增的規定

當非系統的前景應用程式存取裝置的精確位置時，裝置會執行下列操作：

  • [9.8.8/H-6-1] 必須顯示使用者可見的指標。

新增規定結束 (2.2.5 > 9.8.8/H-6-1)

驗證開機程序可確保裝置軟體的完整性。如果裝置實作支援這項功能，則：

  • [9.10/H-1-1] MUST verify all read-only partitions mounted during the Android boot sequence, and the VBMeta digest must include all these verified partitions in its calculation.

2.2.6. 開發人員工具和選項相容性

手持裝置實作方式 (* 不適用於平板電腦)：

  • [6.1/H-0-1]* 必須支援殼層指令 cmd testharness。

手持裝置實作方式：

  • Perfetto

    • [6.1/H-0-2] MUST 向殼層使用者公開二進位檔，該二進位檔的指令列須符合 perfetto 說明文件。/system/bin/perfetto

    • [6.1/H-0-3] perfetto 二進位檔必須接受符合perfetto 文件中定義結構定義的 protobuf 設定做為輸入內容。

    • [6.1/H-0-4] perfetto 二進位檔必須輸出符合perfetto 文件中定義結構定義的 protobuf 追蹤記錄。

    • [6.1/H-0-5] 必須透過 perfetto 二進位檔，提供至少perfetto 文件中說明的資料來源。

    • [6.1/H-0-6] 預設情況下，必須啟用 perfetto 追蹤的精靈 (系統屬性 persist.traced.enable)。

CDD 17：2.2.7 MPC 節的變更

我們大幅調整了媒體成效類別的資格規定架構。自 API 37 起，我們新增了 1、10、20 和 37 級別。此外，我們也參考媒體效能等級測量頁面，詳細列出 MPC 等級測量的各項要求，降低要求複雜度。

2.2.7. 手持媒體效能類別

如要瞭解媒體效能類別的定義，以及所有指標的媒體效能類別定義，請參閱第 7.11 節。

2.2.7.1. 媒體

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

  • 必須符合Android 17 CDD 2.2.7.1 節中列出的所有媒體要求，這些要求與裝置聲明的媒體效能類別等級相符。

  • [5.1/H-1-1] 必須透過與裝置宣告的媒體效能類別等級對應的 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，宣傳可在任何轉碼器組合中同時執行的硬體影片解碼器工作階段數量上限。

  • [5.1/H-1-2] 必須支援硬體影片解碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)、並行執行個體，以及與裝置宣告的媒體效能等級相應的影格遺失。

  • [5.1/H-1-3] 必須透過與裝置宣告的媒體效能類別等級對應的 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，宣傳可在任何轉碼器組合中同時執行的硬體影片編碼器工作階段數量上限。

  • [5.1/H-1-4] 必須支援硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)、並行執行個體，以及與裝置宣告的媒體效能等級相應的影格遺失。

  • [5.1/H-1-5] 必須透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，宣傳任何編解碼器組合中，硬體影片編碼器和解碼器工作階段的最大並行數，這些方法對應於裝置宣告的媒體效能類別等級。

  • [5.1/H-1-6] 必須支援硬體影片解碼器和硬體影片編碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)、並行執行個體，以及與裝置聲明的媒體效能等級相應的影格遺失。

  • [5.1/H-1-7] 在對應裝置聲明媒體效能等級的負載下，所有硬體視訊編碼器都必須在 1080p 或更小的視訊編碼工作階段中，具有編碼器初始化延遲。

  • [5.1/H-1-8] 在負載量對應於裝置聲明的媒體效能等級時，所有音訊編碼器都「必須」在位元率為 128 kbps 或更低的音訊編碼工作階段中，具有編碼器初始化延遲。

  • [5.1/H-1-9] 必須支援 2 個安全硬體影片解碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，以及與裝置聲明的媒體效能等級相應的影格遺失。

  • [5.1/H-1-10] 必須支援 3 個非安全硬體影片解碼器工作階段，以及 1 個安全硬體影片解碼器工作階段 (總共 4 個工作階段) (AVC、HEVC、VP9、AV1 或更新版本)，解析度和影格遺失情形須符合裝置聲明的媒體效能等級。

  • [5.1/H-1-11] 裝置聲明的媒體效能類別等級對應的每個硬體 AVC、HEVC、VP9 或 AV1 解碼器，都必須支援安全解碼器。

  • [5.1/H-1-12] 在負載量對應於裝置聲明的媒體效能類別等級時，所有硬體視訊解碼器都「必須」在 1080p 或更小的視訊解碼工作階段中，具有編解碼器初始化延遲。

  • [5.1/H-1-13] 在對應裝置宣告的媒體效能類別等級負載下，所有音訊解碼器都「必須」在 128 kbps 或更低位元率的音訊解碼工作階段中，具有編解碼器初始化延遲。

  • [5.1/H-1-14] 必須支援 AV1 硬體解碼器設定檔、功能和顯示方法，且這些項目須與裝置宣告的媒體效能類別等級相符。

  • [5.1/H-1-15] 必須至少有 1 個硬體視訊解碼器支援 4K60，且與裝置聲明的媒體效能類別等級相符。

  • [5.1/H-1-16] 必須至少有 1 個支援 4K60 的硬體影片編碼器，對應裝置聲明的媒體效能類別等級。

  • [5.1/H-1-17] 必須至少有 1 個支援 AVIF 基準設定檔的硬體圖片解碼器，對應裝置聲明的媒體效能類別等級。

  • [5.1/H-1-18] 必須支援 AV1 編碼器，且符合裝置聲明的媒體效能類別等級對應的位元率、每秒影格數和解析度規定。

  • [5.1/H-1-19] 必須支援 3 個 10 位元 (HDR) 硬體視訊解碼器和硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，以及與裝置聲明的媒體效能等級相應的解析度和掉格。

  • [5.1/H-1-20] 裝置上所有硬體 AV1 和 HEVC 編碼器都「必須」支援 Feature_HdrEditing 功能，且須符合裝置聲明的媒體效能類別等級。

  • [5.1/H-1-21] 必須支援所有硬體視訊解碼器 (AVC、HEVC、VP9、AV1 或更新版本) 的 FEATURE_DynamicColorAspect，這些解碼器對應裝置聲明的媒體效能類別等級。

  • [5.1/H-1-22] 必須支援以直向螢幕長寬比編碼、解碼、GPU 編輯及顯示影片內容，且須符合裝置聲明的媒體效能類別等級。

  • [5.2/H-2-1] 如果裝置實作項目支援硬體 AVC 或 HEVC 編碼器，則必須符合這些編碼器視訊編碼器速率失真曲線定義的最低品質目標，對應裝置宣告的媒體效能等級。

Android 17 新增的規定

附加規定結束 (2.2.7.1 > 5.2/H-2-2)

Android 17 新增的規定

  • [5.6/H-3-1] 必須能夠在播放正弦波之間切換，且音訊緩衝區不得發生欠載情形，這與裝置宣告的媒體效能類別等級相符。

  • [5.6/H-3-2] 必須符合與裝置聲明的媒體效能類別等級相應的 USB 音訊裝置輸出通道要求。

  • [5.6/H-3-3] 必須符合與裝置聲明媒體效能類別等級相應的 USB 音訊裝置輸入通道規定。

新增規定結束 (2.2.7.1 > 5.6/H-3-1 至 5.6/H-3-3)

  • [5.6/H-SR-1] 強烈建議支援與裝置聲明的媒體效能類別等級相應的音訊聲道混音。

  • [5.7/H-1-2] 必須支援 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL，並具備與裝置聲明的媒體效能類別等級相應的解密功能。

  • [5.12/H-1-2] 必須符合硬體 AV1 和 HEVC 編碼器的色彩格式規定，且與裝置聲明的媒體效能類別等級相符。

  • [5.12/H-1-3] 必須宣傳支援與裝置聲明的媒體效能類別等級相應的 EXT_YUV_target 擴充功能。

  • [7.1.4/H-1-1] 必須符合裝置聲明的媒體效能類別等級所對應的顯示處理器 (DPU) 規定。

2.2.7.2. 相機

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

Android 17 新增的規定

新增規定結束 (2.2.7.2 > 7.5/H-1-21)

2.2.7.3. 硬體

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

  • [7.1.1.1/H-1-1] This item is intentionally skipped.

  • [7.1.1.1/H-2-1] 必須具備與裝置聲明媒體效能類別等級相應的螢幕解析度。

  • [7.1.1.3/H-1-1] This item is intentionally skipped.

  • [7.1.1.3/H-2-1] 必須具備與裝置聲明的媒體效能類別等級相應的螢幕密度。

  • [7.1.1.3/H-3-1] 必須支援與裝置聲明的媒體效能類別等級相應的 HDR 顯示需求。

  • [7.6.1/H-1-1] This item is intentionally skipped.

  • [7.6.1/H-2-1] 必須符合裝置聲明的媒體效能類別等級對應的記憶體需求。

2.2.7.4. 效能

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

2.2.7.5. 圖形

如果手持裝置實作項目為 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，則：

2.3. 電視需求

Android 電視裝置是指 Android 裝置實作項目，可做為娛樂介面，供使用者在約十英尺外 (「靠後」或「10 英尺使用者介面」) 觀看數位媒體、電影、玩遊戲、使用應用程式和/或觀看電視直播。

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

  • 提供機制，可遠端控制顯示器上顯示的使用者介面，而顯示器可能距離使用者十英尺。
  • 內建螢幕的對角線長度超過 24 吋，或具備視訊輸出埠，例如 VGA、HDMI、DisplayPort 或無線顯示埠。

本節其餘部分的額外規定，適用於 Android TV 裝置實作。

2.3.1. 硬體

電視裝置實作方式：

  • [7.2.2/T-0-1] 必須支援D-Pad。
  • [7.2.3/T-0-1] 必須提供「首頁」和「返回」功能。
  • [7.2.3/T-0-2] MUST send both the normal and long press event of the Back function (KEYCODE_BACK) to the foreground application.
  • [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] MUST include support for an external camera that connects through this USB port but is not necessarily always connected.

如果電視裝置實作項目為 32 位元：

  • [7.6.1/T-1-1] 如果使用下列任何密度，核心和使用者空間可用的記憶體必須至少為 896MB：

    • 在小型/一般螢幕上，DPI 須為 400 以上
    • 大型螢幕上的 xhdpi 以上
    • 在特大螢幕上，tvdp 或更高

如果電視裝置實作項目為 64 位元：

  • [7.6.1/T-2-1] 如果使用下列任何密度，核心和使用者空間可用的記憶體必須至少為 1280MB：

    • 在小型/一般螢幕上，DPI 須為 400 以上
    • 大型螢幕上的 xhdpi 以上
    • 在特大螢幕上，tvdp 或更高

請注意，上文提及的「核心和使用者空間可用的記憶體」是指除了已專用於無線電、視訊等硬體元件的記憶體之外，裝置實作項目提供的記憶體空間，這些元件不受核心控制。

電視裝置實作方式：

  • [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 Profile (AAC+)
  • [5.1/T-0-3] AAC ELD (增強型低延遲 AAC)

Android 17 新增的規定

  • [5.1/T-0-4] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

新增要求結束 (2.3.2 > 5.1/T-0-4)

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

  • [5.2/T-0-1] H.264
  • [5.2/T-0-2] VP8
  • [5.2/T-0-3] AV1

電視裝置實作方式：

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

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

電視裝置實作項目「必須」支援 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] 以每秒 60 個影格的速度播放 HD 1080p 影片，並使用基準設定檔
  • [5.3.4/T-1-2] 60 FPS 的 HD 1080p，並採用 Main Profile
  • [5.3.4/T-1-3] HD 1080p，每秒 60 格，高畫質層級 4.2

電視裝置實作項目必須支援 H.265 硬體解碼器，並以標準視訊影格速率解碼 H.265，且解析度最高可達以下規格 (含)：

  • [5.3.5/T-1-1] HD 1080p，每秒 60 個影格，主要設定檔層級 4.1

如果電視裝置實作項目支援 H.265 解碼和 UHD 解碼設定檔，且搭載 H.265 硬體解碼器，則：

  • [5.3.5/T-2-1] 必須支援 UHD 解碼設定檔，且 Main10 Level 5 Main Tier 設定檔的影格速率為每秒 60 格

電視裝置實作項目「必須」支援 VP8 解碼，如第 5.3.6 節所述，且支援標準影片影格率和解析度，最高可達：

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

電視裝置實作項目必須支援 VP9 解碼，如第 5.3.7 節所述，且須支援標準影片影格速率和解析度，最高可達以下規格：

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

如果電視裝置實作項目支援 VP9 解碼和 UHD 解碼設定檔，且搭載 VP9 硬體解碼器，則：

  • [5.3.7/T-2-1] MUST support the UHD decoding profile at 60 frames per second with profile 0 (8 bit color depth)。
  • [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 輸出模式的刷新率設為 50 Hz 或 60 Hz。

如果電視裝置實作項目沒有內建螢幕，但支援透過 HDMI 連接的外接螢幕，則：

  • [5.8/T-1-1] MUST support HDCP 2.2.

如果電視裝置實作項目不支援 UHD 解碼，但支援透過 HDMI 連接的外接螢幕，則：

  • [5.8/T-2-1] 必須支援 HDCP 1.4

2.3.3. 軟體

電視裝置實作方式：

  • [3/T-0-1] MUST declare the features android.software.leanback and 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] 強烈建議支援子母畫面模式多視窗模式。
  • [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 引擎。

Android 電視輸入架構 (TIF) 可簡化將直播內容傳送到 Android 電視裝置的程序。TIF 提供標準 API，可建立控制 Android TV 裝置的輸入模組。

電視裝置實作方式：

  • [3/T-0-2] MUST declare the platform feature android.software.live_tv.
  • [3/T-0-3] 必須支援所有 TIF API，以便在裝置上安裝及使用這些 API 和第三方 TIF 輸入服務。

Android 電視調諧器架構 (TF) 可統一處理 Android 電視裝置上的調諧器即時內容和 IP 串流內容。Tuner Framework 提供標準 API，可建立使用 Android Television Tuner 的輸入服務。

如果裝置實作支援 Tuner，則：

  • [3/T-1-1] 必須支援所有 Tuner Framework API，以便在裝置上安裝及使用這些 API。

2.3.4. 效能與電力

  • [8.1/T-0-1] 一致的影格延遲。 影格延遲時間不一致或影格轉譯延遲的次數，每秒不得超過 5 個影格，且應低於每秒 1 個影格。
  • [8.2/T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
  • [8.2/T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
  • [8.2/T-0-3] 必須確保循序讀取效能至少為 15 MB/s。
  • [8.2/T-0-4] 必須確保隨機讀取效能至少為 3.5 MB/s。

如果電視裝置實作項目包含 AOSP 內建的裝置電源管理改善功能，或擴充 AOSP 內建的功能，則：

  • [8.3/T-1-1] 必須提供使用者功能提示，讓使用者啟用及停用省電模式。

如果電視裝置實作項目沒有電池，則：

如果電視裝置實作項目有電池，則：

  • [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 shell 命令，向應用程式開發人員提供這項耗電量資訊。

2.3.5. 安全模式

電視裝置實作方式：

  • [9/T-0-1] 必須宣告 android.hardware.security.model.compatible 功能。

如果電視裝置實作項目包含支援 VoiceInteractionService 的預設應用程式，則：

  • [9.1/T-0-1] 不得將 ACCESS_FINE_LOCATION 設為該應用程式的預設值。

電視裝置實作方式：

  • [9.11/T-0-1] MUST back up the keystore implementation with an isolated execution environment.
  • [9.11/T-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離「必須」封鎖所有潛在機制，避免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼專案 (AOSP) 使用 Trusty 實作項目，即可滿足這項需求，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當 Hypervisor 型隔離安全實作項目。
  • [9.11/T-0-3] MUST 在隔離的執行環境中執行螢幕鎖定驗證，且只有在驗證成功時，才允許使用與驗證相關聯的金鑰。螢幕鎖定憑證的儲存方式必須確保只有獨立執行環境可以執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。

  • [9.11/T-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。驗證簽署金鑰不得做為永久裝置 ID 使用。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除以下要求：必須有以獨立執行環境為基礎的金鑰儲存區，並支援金鑰認證，除非裝置宣告 android.hardware.fingerprint 功能，而這項功能需要以獨立執行環境為基礎的金鑰儲存區。

如果電視裝置實作項目支援安全螢幕鎖定，則：

  • [9.11/T-1-1] MUST allow the user to choose the Sleep timeout for transition from the unlocked to the locked state, with a minimum allowable timeout up to 15 seconds or less.

如果電視裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，則：

  • [9.5/T-2-1] 必須支援受限設定檔，裝置擁有者可透過這項功能管理其他使用者及其在裝置上的功能。裝置擁有者可以透過受限制的設定檔，為其他使用者快速設定獨立的工作環境，並在這些環境中管理應用程式的細部限制。

如果電視裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能旗標，則：

  • [9.5/T-3-1] 不得支援受限設定檔，但必須與 AOSP 的控制項實作項目保持一致，以允許 /禁止其他使用者存取語音通話和簡訊。

如果電視裝置實作項目宣告 android.hardware.microphone，則：

  • [9.8.2/T-4-1] 應用程式從麥克風存取音訊資料時，必須顯示麥克風指標，但麥克風僅供 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或持有第 9.1 節權限 (CDD 識別碼為 C-3-X) 的應用程式存取時，則不在此限。
  • [9.8.2/T-4-2] 針對具有可見使用者介面或直接使用者互動的系統應用程式，不得隱藏麥克風指標。

如果電視裝置實作項目宣告 android.hardware.camera.any，則：

  • [9.8.2/T-5-1] 應用程式存取即時攝影機資料時，必須顯示相機指標，但如果應用程式僅存取 CDD 識別碼 [C-3-X] 第 9.1 節「權限」中列出的角色，則不在此限。
  • [9.8.2/T-5-2] 系統應用程式不得隱藏相機指標，這類應用程式必須有可見的使用者介面或直接的使用者互動。

2.3.6. 開發人員工具和選項相容性

電視裝置實作方式：

  • Perfetto

    • [6.1/T-0-1] MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
    • [6.1/T-0-2] perfetto 二進位檔必須接受符合perfetto 說明文件中定義結構定義的 protobuf 設定做為輸入內容。
    • [6.1/T-0-3] perfetto 二進位檔必須輸出符合perfetto 說明文件中定義結構定義的 protobuf 追蹤記錄。
    • [6.1/T-0-4] 必須透過 perfetto 二進位檔提供至少perfetto 文件中說明的資料來源。
    • [6.1/T-0-5] 預設必須啟用 perfetto 追蹤精靈 (系統屬性 persist.traced.enable)。

2.4. 智慧手錶需求

Android Watch 裝置是指可穿戴在身上 (例如手腕) 的 Android 裝置實作項目。

如果 Android 裝置實作項目符合下列所有條件，就會歸類為手錶：

  • 螢幕的實際對角線長度介於 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] 必須為使用者提供「首頁」功能，以及「返回」功能 (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 計算出的位置，也必須立即回報 GNSS 測量值。
  • [7.3.3/W-1-2] 必須回報 GNSS 虛擬距離和虛擬距離速率，這些資料在判定位置後，於空曠環境中，在靜止或以每平方秒 0.2 公尺以下的加速度移動時，至少有 95% 的時間足以計算出 20 公尺內的位置，以及每秒 0.2 公尺內的速度。

如果手錶裝置實作項目包含 3 軸式迴轉儀，則：

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

Android 17 新增的規定

如果手錶裝置實作支援行動數據連線，則：

  • [7.4.1/W-1-1] 必須宣告 android.hardware.telephony.data 功能。

新增規定結束 (2.4.1 > 7.4.1/W-1-1)

觀看裝置實作內容：

  • [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] MUST declare the feature android.hardware.type.watch.
  • [3/W-0-2] MUST support 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. 效能與電力

如果手錶裝置實作項目包含 AOSP 內建的裝置電源管理改善功能，或擴充 AOSP 內建的功能，則：

  • [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 shell 指令，向應用程式開發人員提供這項耗電量資訊。
  • 如果無法將硬體元件耗電量歸因於應用程式，則應將 [8.4/W] 歸因於硬體元件本身。

2.4.5. 安全模式

觀看裝置實作內容：

  • [9/W-0-1] 必須宣告 android.hardware.security.model.compatible 功能。

如果手錶裝置實作項目包含支援 VoiceInteractionService 的預設應用程式，則：

  • [9.1/W-0-1] 不得將 ACCESS_FINE_LOCATION 設為該應用程式的預設值。

如果手錶裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，則：

  • [9.5/W-1-1] 必須支援受限設定檔，裝置擁有者可透過這項功能管理其他使用者，以及他們在裝置上的功能。裝置擁有者可以透過受限制的設定檔，為其他使用者快速設定獨立的工作環境，並在這些環境中管理應用程式的細部限制。

如果手錶裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能旗標，則：

  • [9.5/W-2-1] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作項目保持一致，以允許 /禁止其他使用者存取語音通話和簡訊。

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

Android 17 中變更了需求條件的開始時間

  • [9.11.1/W-1-1] 必須要求使用者進行一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案或密碼)，每隔 72 小時就必須 至少每隔 336 小時 (14 天) 就要驗證一次 。

變更後的要求 (2.4.5 > 9.11.1/W-1-1)

Android 17 新增的規定

如果裝置實作項目設有安全螢幕鎖定，且包含一或多個信任的代理程式 (這些代理程式會使用 FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 旗標呼叫 TrustAgentService.grantTrust() 系統 API)，則：

  • [9.11.1/W-2-1] 必須符合下列條件，才能使用該旗標呼叫 grantTrust()：
    • 裝置已連線至附近的手持裝置，且該裝置已啟用螢幕鎖定功能。
    • 使用者在過去 30 秒內，已透過該螢幕鎖定或第 3 級生物特徵辨識驗證身分。
  • [9.11.1/W-2-2] 穿戴式裝置脫離手腕或身體，且 TrustAgent 尚未撤銷信任時，必須將裝置狀態設為 TrustState.TRUSTABLE。

新增規定結束 (2.4.5 > 9.11.1/W-2-1 和 9.11.1/W-2-2)

2.5. 車輛相關規定

Android Automotive 實作是指車輛的車用運算主機將 Android 做為部分或所有系統和/或車用資訊娛樂功能的作業系統。

如果 Android 裝置實作項目宣告 android.hardware.type.automotive 功能，或符合下列所有條件，就會歸類為 Automotive。

  • 內建於車輛或可插入車輛。

  • 使用駕駛座列的螢幕做為主要螢幕。

本節其餘部分的額外規定，適用於 Android Automotive 裝置實作。

2.5.1. 硬體

車輛裝置實作：

  • [7.1.1.1/A-0-1] 螢幕的實際對角線尺寸必須至少為 6 吋。

  • [7.1.1.1/A-0-2] 螢幕尺寸版面配置必須至少為 750 dp x 480 dp。

  • [7.1.1.1/A-0-3] MUST support GPU composition of graphic buffers at least as large as the highest resolution of any built-in display.

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [7.1.1.1/A-1-1] 每個乘員區域的主螢幕必須有至少 6 吋的實體對角線大小。每個居住區域都應標記為 CarOccupantZoneManager.DISPLAY_TYPE_MAIN。

  • [7.1.1.1/A-1-2] 各個主要螢幕的螢幕尺寸版面配置必須至少為 750 dp x 480 dp。

如果車輛裝置實作支援 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] MUST include Vulkan loader and export all symbols.

如果車輛裝置實作項目支援 Vulkan，則：

如果車輛裝置實作透過 Configuration.isScreenHdr() 聲明支援高動態範圍螢幕，則：

  • [7.1.4.5/A-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/A-0-1] 裝置「必須」透過系統屬性 graphics.gpu.profiler.support 回報是否支援 GPU 剖析功能。

如果 Automotive 裝置實作項目透過系統屬性 graphics.gpu.profiler.support 宣告支援，則：

車輛裝置實作：

  • [7.1.5/A-0-1] 必須支援上游 Android 開放原始碼實作的舊版應用程式相容模式。也就是說，裝置實作「不得」變更啟動相容性模式的觸發條件或門檻，也「不得」變更相容性模式本身的行為。

車輛裝置實作：

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [7.3/A-1-1] 必須在所有螢幕 (包括後座螢幕) 上，根據資訊主頁的日/夜間模式，一致設定 NIGHT_MODE 旗標值。

如果車用裝置實作項目包含加速計，則：

  • [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感應器。

如果車用裝置實作項目包含陀螺儀，則：

  • [7.3.4/A-2-1] 必須能夠以至少 100 Hz 的頻率回報事件。

  • [7.3.4/A-2-3] 必須能夠測量高達每秒 250 度的方向變化。

  • [7.3.4/A-SR-1] 強烈建議將陀螺儀的測量範圍設為 +/-250 dps，盡可能提高解析度。

如果車用裝置實作項目包含 3 軸式迴轉儀，則：

  • [7.3.4/A-SR-2] Are STRONGLY RECOMMENDED to implement the composite sensor for limited axes gyroscope.

如果車用裝置實作項目包含少於 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 接收器或 4 天後，必須在 60 秒內判斷位置。

  • [7.3.3/A-3-2] 必須符合7.3.3/C-1-2 和 7.3.3/C-1-6 中所述的首次定位時間標準，適用於所有其他位置資訊要求 (即並非首次或 4 天後的要求)。如果車輛沒有以行動網路為基礎的資料連線，通常會使用接收器計算的 GNSS 軌道預測，或使用最後已知的車輛位置，以及至少 60 秒的航位推算能力，且位置準確度符合 7.3.3/C-1-3，或兩者兼具，以滿足 7.3.3/C-1-2 的要求。

如果車用裝置實作項目包含 TYPE_HEADING 感應器，則：

  • [7.3.4/A-4-3] MUST be able to report events up to a frequency of at least 1 Hz.

  • [7.3.4/A-SR-3] 強烈建議回報事件的頻率至少為 10 Hz。

  • 應以正北為參考方向。

  • 即使車輛靜止不動，也「應該」可以使用。

  • 解析度應至少為 1 度。

車輛裝置實作：

  • [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)。

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [7.4.3/A-1-1] MUST be independent and NOT interfere with other users' BT experience.

車輛裝置實作：

  • [7.4.5/A] 應支援以行動網路為基礎的資料連線。

  • [7.4.5/A] MAY use the System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID constant for networks that should be available to system apps.

如果裝置實作項目支援 AM/FM 廣播電台，並向任何應用程式公開這項功能，則：

  • [7.4/A-1-1] 必須聲明支援 FEATURE_BROADCAST_RADIO。

後置鏡頭是指朝向車輛外部的鏡頭，可安裝在車輛的任何位置，並朝向車輛外部，也就是拍攝車身遠側的場景，例如後視鏡頭。

前置鏡頭是指朝向使用者的鏡頭，可位於車輛的任何位置，並朝向車輛駕駛艙內部；也就是說，前置鏡頭會拍攝使用者，例如用於視訊會議和類似應用程式。

車輛裝置實作：

  • [7.5/A-SR-1] 強烈建議納入一或多個面向世界的攝影機。

  • 可能包含一或多個面向使用者的攝影機。

  • [7.5/A-SR-2] 建議支援多部攝影機的並行串流。

如果車用裝置實作項目包含至少一個面向世界的攝影機，則這類攝影機必須符合下列條件：

  • [7.5/A-1-1] 必須調整方向，讓相機的長邊對齊 Android Automotive 感應器軸的 X-Y 平面。

  • [7.5/A-SR-3] 強烈建議使用定焦或 EDOF (擴展景深) 硬體。

  • [7.5/A-1-2] 必須將主要朝外的攝影機設為攝影機 ID 最小的朝外攝影機。

如果車用裝置實作項目包含至少一個面向使用者的相機，則這類相機必須符合下列條件：

  • [7.5/A-2-1] 主要面向使用者的攝影機必須是攝影機 ID 最小的面向使用者攝影機。

  • 方向「可」經過調整，讓相機的長邊對齊 Android 車用感應器軸的 X-Y 平面。

如果 Automotive 裝置實作項目包含可透過 android.hardware.Camera 或 android.hardware.camera2 API 存取的相機，則：

  • [7.5/A-3-1] 必須遵守第 7.5 節的核心相機規定。

Android 17 移除的規定

如果 Automotive 裝置實作項目包含無法透過 android.hardware.Camera 或 android.hardware.camera2 API 存取的攝影機，則：

  • [7.5/A-4-1] 必須可透過 Extended View System 服務存取。

已移除的規定 (2.5.1 > 7.5/A-4-1)

如果車輛裝置實作項目包含一或多個可透過擴展視野系統服務存取的攝影機，這類攝影機必須符合下列條件：

  • [7.5/A-5-1] 攝影機預覽畫面不得旋轉或水平鏡像。

  • [7.5/A-SR-4] 建議解析度至少為 130 萬像素。

如果車用裝置實作項目包含一或多部攝影機，可透過擴充檢視系統服務和 android.hardware.Camera 或 android.hardware.Camera2 API 存取，則這類攝影機：

  • [7.5/A-6-1] 必須回報相同的攝影機 ID。

如果 Automotive 裝置實作項目提供專屬的 Camera API，則：

車輛裝置實作：

  • [7.6.1/A-0-1] 必須至少有 4 GB 的非揮發性儲存空間，可供應用程式私人資料 (/data 分割區) 使用。

  • [7.6.1/A] SHOULD 格式化資料分割區，以提升快閃儲存裝置的效能和使用壽命 (例如使用 f2fs 檔案系統)。

如果 Automotive 裝置實作項目透過內部不可移除儲存空間的一部分提供共用外部儲存空間，則：

  • [7.6.1/A-SR-1] 強烈建議使用 SDCardFS 等方式，減少對外部儲存空間執行作業時的 I/O 負擔。

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [7.6.1/A-1-1] 在單一 AAOS 執行個體中，每個並行 Android 使用者必須至少有 4 GB 的非揮發性儲存空間，可用於應用程式私人資料 (/data 分割區)。

如果車輛裝置實作項目為 64 位元：

  • [7.6.1/A-2-1] 如果使用下列任何密度，核心和使用者空間可用的記憶體必須至少為每個主螢幕 816 MB：

    • 小型/一般螢幕的 dpi 為 280 以下
    • 在特大螢幕上為 ldpi 或更低
    • 大型螢幕上的 mdpi 或更低

  • [7.6.1/A-2-2] 如果使用下列任何密度，核心和使用者空間可用的記憶體必須至少為每個主螢幕 944 MB：

    • 在小型/一般螢幕上，xhdpi 以上
    • 大型螢幕上的 hdpi 以上
    • 在特大螢幕上為 mdpi 以上

  • [7.6.1/A-2-3] 如果使用下列任何密度，核心和使用者空間可用的記憶體必須至少為每個主螢幕 1280 MB：

    • 在小型/一般螢幕上，DPI 須為 400 以上
    • 大型螢幕上的 xhdpi 以上
    • 在特大螢幕上，tvdp 或更高

  • [7.6.1/A-2-4] 如果使用下列任何密度，核心和使用者空間可用的記憶體必須至少為每個主螢幕 1824 MB：

    • 在小型/一般螢幕上，DPI 須為 560 以上
    • 大螢幕的 dpi 須為 400 以上
    • 特大螢幕上的 xhdpi 以上

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

車輛裝置實作：

  • [7.7.1/A] 應包含支援週邊裝置模式的 USB 連接埠。

如果 Automotive 裝置實作項目包含 USB 連接埠和以周邊模式運作的控制器，則：

  • [7.7.1/A-1-1] 必須實作 Android 開放式配件 (AOA) API。

如果車輛裝置實作項目包含支援主機模式的 USB 連接埠，則：

車輛裝置實作：

  • [7.8.1/A-0-1] 必須內建麥克風。

車輛裝置實作：

  • [7.8.2/A-0-1] 必須具備音訊輸出功能，並宣告 android.hardware.audio.output。

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [7.8.2/A-1-1] 針對多位使用者系統並行作業，每個主要螢幕都必須有音訊輸出裝置。

  • [7.8.2/A-1-2] MUST have a Driver audio zone covering the global cabin speaker. 前座乘客區可以共用駕駛人的音訊區，也可以有自己的音訊輸出。

在 USB 周邊裝置連線時呼叫 AudioManager.getDevices() API，會發生下列情況：

2.5.2. 多媒體

車輛裝置實作項目「必須」支援下列音訊編碼和解碼格式，並提供給第三方應用程式：

  • [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)

Android 17 新增的規定

  • [5.1/A-0-4] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

新增規定結束 (2.5.2 > 5.1/A-0-4)

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

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

  • [5.2/A-0-2] VP8

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

  • [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

強烈建議車輛裝置實作支援下列視訊解碼：

  • [5.3/A-SR-1] H.265 HEVC

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [5.5.3/A-1-1] MUST define identical volume curves for all audio output streams mapping to the same volume-group as defined in the car audio configuration file.

2.5.3. 軟體

車輛裝置實作：

  • [3/A-0-1] MUST declare the feature android.hardware.type.automotive.

  • [3/A-0-2] 必須支援 uiMode = UI_MODE_TYPE_CAR。

  • [3/A-0-3] MUST support all public APIs in the android.car.* namespace.

如果 Automotive 裝置實作項目使用 android.car.CarPropertyManager 和 android.car.VehiclePropertyIds 提供專屬 API，則：

  • [3/A-1-1] MUST NOT attach special privileges to system application's use of these properties, or prevent third-party applications from using these properties.

  • [3/A-1-2] 不得複製 SDK 中已有的車輛屬性。

車輛裝置實作：

如果 Automotive 裝置實作的設定應用程式實作了分割功能，使用活動嵌入時，這些應用程式會：

如果車用裝置實作項目支援並行多使用者 (多位 Android 使用者可同時與裝置互動，啟用 config_multiuserVisibleBackgroundUsers 時每位使用者都有自己的螢幕)，則：

  • [3.8/A-1-1] 針對並非目前前景使用者，但有權存取所指派螢幕的完整次要使用者預先定義 UserRestrictions 清單，必須實作下列項目。UserRestrictions 清單包括 DISALLOW_CONFIG_LOCALE、DISALLOW_CONFIG_BLUETOOTH、DISALLOW_BLUETOOTH、DISALLOW_CAMERA_TOGGLE 和 DISALLOW_MICROPHONE_TOGGLE。

  • [3.8/A-1-2]「不得」允許非目前前景使用者但有權存取所指派螢幕的完整次要使用者，透過「設定」或 API 變更任何其他使用者的日/夜間模式、語言代碼、日期、時間、時區或螢幕色彩功能 (包括亮度、夜燈、數位健康灰階和減少鮮豔色彩)。

車輛裝置實作：

如果車用裝置導入項目包含一鍵通話按鈕，則：

  • [3.8.4/A-1-1] 必須使用按住說話按鈕的短按操作，啟動使用者選取的小幫手應用程式，也就是實作 VoiceInteractionService 的應用程式。

車輛裝置實作：

  • [3.8.3.1/A-0-1] 必須按照 Notifications on Automotive OS SDK 說明文件所述，正確轉譯資源。

  • [3.8.3.1/A-0-2] MUST display PLAY and MUTE for notification actions in the place of those provided through Notification.Builder.addAction()

  • [3.8.3.1/A] SHOULD restrict the use of rich management tasks such as per-notification-channel controls. 可針對每個應用程式使用 UI 輔助功能，減少控制項。

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

車輛裝置實作：

Android 17 新增的規定

車輛裝置實作：

新增要求結束 (2.5.3 > 3.14/A-0-8 至 3.14/A-0-10)

如果車輛裝置實作項目包含預設啟動器應用程式，則：

車輛裝置實作：

  • [3.8/A] MAY restrict the application requests to enter a full screen mode as described in immersive documentation.

  • [3.8/A] MAY keep the status bar and the navigation bar visible at all times.

  • [3.8/A] MAY restrict the application requests to change the colors behind the system UI elements, to ensure those elements are clearly visible at all times.

Android 17 新增的規定

車輛裝置實作：

在前景執行應用程式時，無論應用程式是否具備 android.software.car.display_compatibility 功能或 android.hardware.type.automotive 功能，Automotive 裝置會：

  • [7.1.1/A-1-1] 必須提供「返回」功能。
新增規定結束 (2.5.3 > 7.1.1/A-0-1 和 7.1.1/A-1-1)

Android 17 移除的規定

如果車輛裝置實作項目允許使用者撥打任何類型的電話，則：

已移除的規定 (2.5.3 > 7.4.1.2/A-1-1 和 7.4.1.2/A-1-2)

2.5.4. 效能與電力

  • [8.1/A-0-1] 影格延遲時間一致。 影格延遲時間不一致或影格延遲顯示的情況，每秒不得超過 5 個影格，且應低於每秒 1 個影格。

  • [8.1/A-0-2] 使用者介面延遲。 裝置實作項目必須確保使用者體驗低延遲，方法是在 36 秒內捲動 Android 相容性測試套件 (CTS) 定義的 10,000 個清單項目。

  • [8.1/A-0-3] 工作切換。 啟動多個應用程式後，重新啟動已啟動的應用程式時，必須在 1 秒內完成。

車輛裝置實作：

  • [8.2/A-0-1] 必須回報每個程序的 UID 讀取和寫入非揮發性儲存空間的位元組數，以便開發人員透過系統 API android.car.storagemonitoring.CarStorageMonitoringManager 取得統計資料。Android 開放原始碼計畫透過 uid_sys_stats 核心模組滿足這項需求。

  • [8.2/A-0-2] 必須確保循序寫入效能至少為 5 MB/秒。

  • [8.2/A-0-3] MUST ensure a random write performance of at least 0.5 MB/s.

  • [8.2/A-0-4] 必須確保循序讀取效能至少為 15 MB/秒。

  • [8.2/A-0-5] 必須確保隨機讀取效能至少為 3.5 MB/s。

如果 Automotive 裝置實作項目傳回 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 的值大於或等於 android.os.Build.VERSION_CODES.U，則：

  • [8.2/A-1-1] 必須確保循序寫入效能至少為 150 MB/秒。

  • [8.2/A-1-2] 必須確保隨機寫入效能至少為 10 MB/s。

  • [8.2/A-1-3] 必須確保循序讀取效能至少為 250 MB/秒。

  • [8.2/A-1-4] 必須確保隨機讀取效能至少為 100 MB/s。

  • [8.2/A-1-5] 必須確保平行循序讀取和寫入效能，且讀取效能至少為 50 MB/秒，寫入效能至少為 25 MB/秒。

  • [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] MUST report CPU power consumption per each process's UID. Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目，符合這項規定。

  • 如果無法將硬體元件的耗電量歸因於應用程式，則應將耗電量歸因於硬體元件本身。

  • [8.4/A-0-4]「必須」透過 adb shell dumpsys batterystats Shell 命令，向應用程式開發人員提供這項耗電量資訊。

2.5.5. 安全模式

如果車輛裝置實作支援多位使用者，則：

如果車輛裝置實作支援 System API VisualQueryDetectionService 或其他查詢偵測機制，且不需要麥克風和/或相機存取權指標，則：

  • [9.8/A-1-1] 查詢偵測服務「必須」確保只能將資料傳輸至系統、ContentCaptureService 或裝置端語音辨識服務 (由 SpeechRecognizer#createOnDeviceSpeechRecognizer() 建立)。

  • [9.8/A-1-2] 不得允許任何音訊或視訊資訊傳輸至 VisualQueryDetectionService 以外的位置，ContentCaptureService 或裝置端的語音辨識服務除外。

  • [9.8/A-1-3] 裝置偵測到使用者意圖與數位助理應用程式互動時 (例如透過攝影機偵測到使用者在場)，必須在系統 UI 中顯示使用者通知。

  • [9.8/A-1-4] 偵測到使用者查詢後，必須立即顯示麥克風指標，並在 UI 中顯示偵測到的使用者查詢。

  • [9.8/A-1-5] MUST NOT allow a user-installable application to provide the visual query detection service.

如果車輛裝置實作項目宣告 android.hardware.microphone，則：

  • [9.8.2/A-1-1] 應用程式從麥克風存取音訊資料時，必須顯示麥克風指標，但如果只有 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或具有 第 9.1 節所述角色的應用程式存取麥克風，則不必顯示麥克風指標，CDD 識別碼為 [C-4-X]。

  • [9.8.2/A-1-2] 針對具有可見使用者介面或直接使用者互動的系統應用程式，不得隱藏麥克風指標。

  • [9.8.2/A-1-3] 必須在「設定」應用程式中提供使用者切換麥克風的功能提示。

如果車輛裝置實作項目宣告 android.hardware.camera.any，則：

  • [9.8.2/A-2-1] 應用程式存取攝影機即時資料時，必須顯示相機指標，但如果應用程式僅存取攝影機，且應用程式具有第 9.1 節「權限」中定義的角色，則不在此限，CDD 識別碼為 [C-4-X]。

  • [9.8.2/A-2-2] 系統應用程式具有可見的使用者介面或直接使用者互動時，不得隱藏相機指標。

  • [9.8.2/A-2-3] 必須提供使用者介面，讓使用者在「設定」應用程式中切換相機。

  • [9.8.2/A-2-4] 必須使用 PermissionManager.getIndicatorAppOpUsageData() 傳回的攝影機，顯示「最近使用的應用程式」和「使用中的應用程式」，以及與這些應用程式相關聯的任何出處訊息。

車輛裝置實作：

  • [9/A-0-1] 必須宣告 android.hardware.security.model.compatible 功能。

  • [9.11/A-0-1] MUST back up the keystore implementation with an isolated execution environment.

  • [9.11/A-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 密碼編譯演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離「必須」封鎖核心或使用者空間程式碼可能存取隔離環境內部狀態的所有潛在機制，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目，因此符合這項規定，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當 Hypervisor 型隔離安全實作項目。

  • [9.11/A-0-3] MUST perform the lock screen authentication in the isolated execution environment and only when successful, allow the authentication-bound keys to be used. 螢幕鎖定憑證的儲存方式必須僅允許隔離的執行環境執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。

  • [9.11/A-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。驗證簽署金鑰不得做為永久裝置 ID 使用。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除以下要求：必須有以獨立執行環境為基礎的金鑰儲存區，並支援金鑰認證，除非裝置宣告 android.hardware.fingerprint 功能，而這項功能需要以獨立執行環境為基礎的金鑰儲存區。

車輛裝置實作：

  • [9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems (e.g., allowlisting permitted message types and message sources)。

  • [9.14/A-0-2] MUST watchdog against denial of service attacks from the Android framework or third-party apps. 這項措施可防範惡意軟體以大量流量淹沒車輛網路，導致車輛子系統故障。

2.5.6. 開發人員工具和選項相容性

車輛裝置實作：

  • Perfetto

    • [6.1/A-0-1] MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation。

    • [6.1/A-0-2] perfetto 二進位檔必須接受符合perfetto 說明文件中定義結構定義的 protobuf 設定做為輸入內容。

    • [6.1/A-0-3] perfetto 二進位檔必須輸出符合perfetto 說明文件中定義結構定義的 protobuf 追蹤記錄。

    • [6.1/A-0-4] 必須透過 perfetto 二進位檔，提供至少perfetto 說明文件中描述的資料來源。

    • [6.1/A-0-5] 預設情況下，必須啟用 perfetto 追蹤常駐程式 (系統屬性 persist.traced.enable)。

2.6. 平板電腦需求

Android 平板電腦裝置是指通常符合下列所有條件的 Android 裝置實作方式：

  • 雙手握住使用。
  • 不具備貝殼式設計或變形設計。
  • 與裝置連線的實體鍵盤實作項目，連線方式為標準連線 (例如 USB、藍牙)。
  • 具有可提供移動性的電源，例如電池。
  • 螢幕尺寸大於 7 吋且小於 18 吋 (以對角線測量)。

平板電腦的實作方式與手持裝置類似。該節中的例外狀況會以星號 (*) 標示，並在本節中註明以供參考。

2.6.1. 硬體

陀螺儀

如果平板電腦實作項目包含 3 軸式迴轉儀，則：

  • [7.3.4/Tab-1-1] MUST be capable of measuring orientation changes up to 1000 degrees per second.

最低記憶體與儲存空間 (第 7.6.1 節)

手持裝置需求中列出的小/一般螢幕密度不適用於平板電腦。

虛擬實境模式 (第 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] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作項目保持一致，以允許 /禁止其他使用者存取語音通話和簡訊。

2.6.2. 軟體

  • [3.2.3.1/Tab-0-1] 必須預先載入一或多個具有意圖處理常式的應用程式或服務元件，以處理這裡列出的所有應用程式意圖所定義的公開意圖篩選器模式。

3. 軟體

3.1. 管理 API 相容性

受管理 Dalvik 位元碼執行環境是 Android 應用程式的主要媒介。Android 應用程式設計介面 (API) 是指一組 Android 平台介面，可供在受管理執行階段環境中執行的應用程式使用。

裝置實作方式：

  • [C-0-1] 必須提供所有已記錄的 API 完整實作項目，包括 Android SDK 提供的所有已記錄行為，或上游 Android 原始碼中以「@SystemApi」標記裝飾的任何 API。

  • [C-0-2] 必須支援/保留以 TestApi 註解 (@TestApi) 標示的所有類別、方法和相關聯元素。

  • [C-0-3] 不得省略任何受管理 API、變更 API 介面或簽章、偏離說明文件記載的行為，或納入無作業，除非本相容性定義明確允許。

  • [C-0-4] 即使省略 Android 包含 API 的某些硬體功能，仍須保留 API 並以合理方式運作。如要瞭解這個情境的具體規定，請參閱第 7 節。

  • [C-0-5] 不得允許第三方應用程式使用非 SDK 介面，這類介面是指 AOSP 啟動類別路徑中 Java 語言套件的方法和欄位，且不屬於公開 SDK。這包括以 @hide 註解裝飾的 API，但不包括 @SystemAPI，詳情請參閱 SDK 文件，以及私有和套件私有類別成員。

  • [C-0-6] 必須隨附與 AOSP 中適當 API 級別分支的 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路徑中，透過暫時和拒絕清單旗標提供的受限制清單相同的每個非 SDK 介面。

  • [C-0-7] 必須支援簽章設定動態更新機制，方法是在任何 APK 中嵌入簽章設定，並使用 Android 開放原始碼計畫中現有的公開金鑰，從受限制的清單中移除非 SDK 介面。

    不過，請注意以下幾點：

    • MAY：如果裝置實作中缺少隱藏 API 或實作方式不同，請將隱藏 API 移至拒絕清單，或從所有受限清單中省略。
    • MAY：如果 AOSP 中沒有隱藏的 API，請將隱藏的 API 新增至任何受限清單。

Android 17 中變更了需求條件的開始時間

  • [C-0-8] 不得支援安裝目標 API 級別低於 24 26 的應用程式。

變更後的要求 (3.1 > C-0-8)

3.1.1. Android 擴充功能

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

Android 裝置實作：

  • [C-0-1] 必須預先載入共用程式庫 ExtShared 和服務 ExtServices 的 AOSP 實作，且版本必須大於或等於各 API 級別允許的最低版本。舉例來說，Android 7.0 裝置實作項目 (API 級別 24) 必須至少包含版本 1。

  • [C-0-2] MUST only return valid extension version number that have been defined by the AOSP.

  • [C-0-3] MUST support all the APIs defined by the extension versions returned by android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) in the same manner as other managed APIs are supported, following the requirements in section 3.1.

3.1.2. Android 程式庫

由於 Apache HTTP 用戶端已遭淘汰，裝置實作項目：

  • [C-0-1] MUST NOT place the org.apache.http.legacy library in the bootclasspath.
  • [C-0-2] 只有在應用程式符合下列任一條件時，才必須將 org.apache.http.legacy 程式庫新增至應用程式類別路徑：
    • 以 API 級別 28 以下為目標。
    • 在資訊清單中宣告需要程式庫，方法是將 <uses-library> 的 android:name 屬性設為 org.apache.http.legacy。

AOSP 實作項目符合這些規定。

3.2. 軟體 API 相容性

除了第 3.1 節的受管理 API 之外，Android 也包含重要的執行階段專用「軟」API，例如意圖、權限和 Android 應用程式的類似層面，這些層面無法在應用程式編譯時強制執行。

3.2.1. 權限

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

3.2.2. 建構參數

Android API 在 android.os.Build 類別中包含多個常數，用於描述目前的裝置。

Android 17 中變更了需求條件的開始時間

  • [C-0-1] 為確保裝置實作項目提供一致且有意義的值，下表列出這些值的格式的其他限制，裝置實作項目必須遵守這些限制。
參數 詳細資料
VERSION.RELEASE 目前執行的 Android 系統版本，格式為使用者可判讀。這個欄位必須包含適用於 Android 17 的允許版本字串中定義的其中一個字串值。
VERSION.SDK 目前執行的 Android 系統版本，格式可供第三方應用程式程式碼存取。如果是 Android 17，這個欄位必須包含整數值 17_INT。
VERSION.SDK&lowbar;INT 目前執行的 Android 系統版本，格式可供第三方應用程式程式碼存取。如果是 Android 17，這個欄位必須包含整數值 17&lowbar;INT。
VERSION.INCREMENTAL 裝置實作人員選擇的值，用於指定目前執行的 Android 系統特定建構版本，格式為人類可判讀。針對提供給使用者的不同建構版本，這個值「不得」重複使用。這個欄位通常用於指出產生建構作業時所用的版本號碼或來源控制變更 ID。這個欄位的值必須可編碼為可列印的 7 位元 ASCII，且符合規則運算式 ^[^ :\/~]+$。
桌遊 裝置實作人員選擇的值，用於以人類可判讀的格式，識別裝置使用的特定內部硬體。這個欄位可能用於指出為裝置供電的電路板特定修訂版本。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9_-]+$。
品牌 這個值會反映與裝置相關聯的品牌名稱，也就是使用者所知的品牌名稱。必須採用人類可解讀的格式，且應代表裝置製造商或裝置的行銷公司品牌。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9_-]+$。
SUPPORTED&lowbar;ABIS 原生程式碼的指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS 原生程式碼的指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS 原生程式碼的第二個指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
CPU&lowbar;ABI 原生程式碼的指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
CPU&lowbar;ABI2 原生程式碼的第二個指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
DEVICE 裝置實作人員選擇的值，其中包含開發名稱或產品代號，用於識別裝置的硬體功能和工業設計設定。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9_-]+$。產品生命週期內，這個裝置名稱「不得」變更。
FINGERPRINT 可明確識別這個版本的字串。這項資訊「應該」要能合理地以人類可讀的形式呈現。格式必須符合以下範本：

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

例如：

acme/myproduct/
    mydevice:17/LMYXX/3359:userdebug/test-keys

指紋不得包含空白字元。這個欄位的值必須可編碼為 7 位元 ASCII。
硬體 硬體名稱 (來自核心指令列或 /proc)。這項資訊「應該」要能讓使用者輕鬆解讀。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9_-]+$。
主機 以人類可讀格式，唯一識別建構版本的主機。這個欄位的格式沒有任何規定，但不得為空值或空字串 ("")。
ID 裝置實作者選擇的 ID，用於以人類可讀的格式參照特定版本。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但「應」是對於使用者而言有意義的值，可區分軟體建構版本。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9._-]+$。
製造商 產品原始設備製造商 (OEM) 的商業名稱。這個欄位的格式沒有任何規定，但「不得」為空值或空字串 ("")。這個欄位「不得」在產品生命週期內變更。
SOC&lowbar;MANUFACTURER 產品所用晶片系統 (SOC) 的製造商名稱。使用相同 SoC 製造商的裝置應使用相同常數值。請向 SOC 製造商詢問要使用的正確常數。這個欄位的值必須可編碼為 7 位元 ASCII，必須符合規則運算式 ^([0-9A-Za-z ]+)，開頭和結尾不得為空白字元，且不得等於「unknown」。產品生命週期內，這個欄位「不得」變更。
SOC&lowbar;MODEL 產品中使用的主要晶片系統 (SOC) 型號名稱。使用相同 SoC 型號的裝置應使用相同常數值。請向 SOC 製造商詢問要使用的正確常數。 這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^([0-9A-Za-z ._/+-]+)$，不得以空白字元開頭或結尾，且不得等於「unknown」。產品生命週期內，這個欄位「不得」變更。
MODEL 裝置實作人員選擇的值，包含使用者所知的裝置名稱。這應與裝置向終端使用者行銷和銷售時使用的名稱相同。這個欄位的具體格式沒有任何規定，但不得為空值或空字串 ("")。強烈建議您在產品生命週期內不要變更這個欄位。
產品 裝置實作人員選擇的值，其中包含特定產品 (SKU) 的開發名稱或產品代號，且必須在同一品牌內保持不重複。必須是使用者可讀取的內容，但不一定會向使用者顯示。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9_-]+$。產品名稱在產品生命週期內不得變更。
ODM&lowbar;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。這個欄位的格式沒有任何規定，但不得為空值或空字串 ("")。
SECURITY&lowbar;PATCH 表示建構版本安全性修補程式等級的值。這表示該版本絕不會受到指定 Android 安全性公告中描述的任何問題影響。格式必須為 [YYYY-MM-DD]，與Android 公開安全性公告或 Android 安全性諮詢中定義的字串相符，例如「2015-11-01」。
BASE&lowbar;OS 這個值代表建構版本的 FINGERPRINT 參數，除了 Android 公開安全性公告提供的修補程式外，這個建構版本與其他版本完全相同。必須回報正確值，如果沒有這類建構版本，則回報空字串 ("")。
開機載入程式 裝置實作者選擇的值，用於以人類可判讀的格式，識別裝置中使用的特定內部系統啟動載入程式版本。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9._-]+$。
getRadioVersion() 必須 (是或傳回) 裝置實作人員選擇的值，用來識別裝置中使用的特定內部無線電/數據機版本，格式必須是人類可判讀的格式。如果裝置沒有任何內部無線電/數據機，則必須傳回 NULL。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9._-,]+$。
getSerial() 必須 (是或傳回) 硬體序號，且該序號必須可用，且在相同型號和製造商的裝置中不得重複。這個欄位的值必須可編碼為 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9]+$。
STRONGBOX&lowbar;MANUFACTURER 產品所用 StrongBox 晶片的製造商商業名稱。StrongBox 供應商提供正確的常數。 使用相同 StrongBox 供應商的裝置應使用相同常數值。這個欄位的值必須符合規則運算式 ^([0-9A-Za-z ]+)，且不得等於「unsupported」。產品生命週期內，這個欄位「不得」變更。
STRONGBOX&lowbar;MODEL 產品中使用的 StrongBox 晶片型號名稱。 StrongBox 供應商提供正確的常數。具有相同 StrongBox 供應商的裝置「應」使用相同常數值。這個欄位的值必須符合規則運算式 ^([0-9A-Za-z ._/+-]+)$，且不得等於「unsupported」。產品生命週期內，這個欄位「不得」變更。

變更要求結束 (3.2.2/C-0-1)

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 節中參照的每個 Intent 模式 (「設定」除外)。上游 Android 開放原始碼實作項目預設允許這項操作。

  • [C-0-2] 裝置實作人員「不得」將特殊權限附加至系統應用程式對這些 Intent 模式的使用，或禁止第三方應用程式繫結至這些模式並取得控制權。這項禁令具體包括但不限於停用「選擇器」使用者介面，讓使用者無法在處理相同意圖模式的多個應用程式之間進行選擇。

  • [C-0-3] 裝置實作內容「必須」提供使用者介面，供使用者修改意圖的預設活動。

  • 不過，如果預設活動為資料 URI 提供更具體的屬性，裝置實作做法「可能」會為特定 URI 模式 (例如 http://play.google.com) 提供預設活動。舉例來說，指定資料 URI「http://www.android.com」的意圖篩選器模式，比瀏覽器的「http://」核心意圖模式更具體。

Android 也提供機制，讓第三方應用程式針對特定類型的網頁 URI Intent 宣告授權預設應用程式連結行為。在應用程式的意圖篩選器模式中定義這類權威宣告時，裝置實作項目會：

  • [C-0-4] 必須嘗試驗證任何意圖篩選器，方法是執行數位資產連結規格中定義的驗證步驟，如上游 Android 開放原始碼專案的套件管理員所實作。
  • [C-0-5] MUST 在安裝應用程式期間嘗試驗證意圖篩選器，並將所有成功驗證的 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。
  • 如果成功驗證，但其他候選 URI 篩選器驗證失敗，MAY 可將特定 URI 意圖篩選器設為 URI 的預設應用程式處理常式。如果裝置實作項目這麼做，就必須在設定選單中，為使用者提供適當的每個 URI 模式覆寫。
  • 必須在「設定」中提供個別應用程式的應用程式連結控制項，如下所示：
    • [C-0-6] 使用者必須能夠全面覆寫應用程式的預設應用程式連結行為，讓應用程式一律開啟、一律詢問或永不開啟，且這項設定必須同樣適用於所有候選 URI 意圖篩選器。
    • [C-0-7] 使用者「必須」能夠查看候選 URI 意圖篩選器清單。
    • 裝置實作「可能」會讓使用者逐一覆寫已成功驗證的特定候選 URI 意圖篩選器。
    • [C-0-8] 如果裝置實作方式允許部分候選 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 文件中也說明瞭背景應用程式的限制。此外，某些廣播 Intent 必須有硬體支援才能運作。如果裝置支援必要的硬體，就「必須」廣播這些 Intent，並提供符合 SDK 文件的行為。
3.2.3.5. 條件式應用程式意圖

Android 內建設定，方便使用者選取預設應用程式，例如主畫面或簡訊。

在適當情況下，裝置實作項目「必須」提供類似的設定選單，且與 SDK 說明文件中所述的意圖篩選器模式和 API 方法相容，如下所示。

如果裝置實作項目回報 android.software.home_screen，表示：

如果裝置實作項目回報 android.hardware.telephony.calling，表示：

如果裝置實作項目回報 android.hardware.nfc.hce，表示：

如果裝置實作項目回報 android.hardware.nfc，表示：

如果裝置實作項目回報 android.hardware.bluetooth，表示：

如果裝置實作項目支援「勿擾」功能，則：

  • [C-6-1] MUST implement an activity that would respond to the intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity where the user can grant or deny the app access to DND policy configurations.

如果裝置實作項目允許使用者在裝置上使用第三方輸入法，則：

如果裝置實作項目支援第三方無障礙服務，則：

  • [C-8-1] 必須遵守 android.settings.ACCESSIBILITY_SETTINGS 意圖，提供使用者可存取的機制，以便啟用和停用第三方無障礙服務，以及預先載入的無障礙服務。

如果裝置實作項目支援 Wi-Fi Easy Connect，並向第三方應用程式公開這項功能，則：

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

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

如果裝置實作項目透過 android.hardware.camera.any 宣告支援攝影機，則：

如果裝置實作項目回報 android.software.device_admin，表示：

如果裝置實作項目聲明 android.software.autofill 功能旗標，則：

如果裝置實作項目包含預先安裝的應用程式，或希望允許第三方應用程式存取使用統計資料，則：

  • [C-SR-2] 強烈建議提供使用者可存取的機制，以回應宣告 android.permission.PACKAGE_USAGE_STATS 權限的應用程式，授予或撤銷使用統計資料的存取權，方法是使用 android.settings.ACTION_USAGE_ACCESS_SETTINGS Intent。

如果裝置實作項目打算禁止任何應用程式 (包括預先安裝的應用程式) 存取使用統計資料，則：

如果裝置實作項目顯示「設定」中 AutofillService_passwordsActivity 指定的活動連結，或透過類似機制顯示使用者密碼連結，則：

  • [C-16-1] 必須為所有已安裝的自動填入服務顯示這類連結。

如果裝置實作項目支援 VoiceInteractionService，且同時安裝多個使用此 API 的應用程式，則：

如果裝置實作項目回報這項功能 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 支援互動式螢幕保護程式 (先前稱為「夢幻螢幕」)。螢幕保護程式可讓使用者在裝置連接電源或固定在桌面底座上時，與應用程式互動。裝置實作：

  • 應支援螢幕保護程式，並提供設定選項，供使用者設定螢幕保護程式，以回應 android.settings.DREAM_SETTINGS 意圖。

如果裝置實作項目回報 android.hardware.nfc.uicc 或 android.hardware.nfc.ese，表示：

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] MUST include support for code running in the managed environment to call into native code, using the standard Java Native Interface (JNI) semantics.
  • [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 清單，並依偏好程度排序 (從最偏好到最不偏好)。

  • [C-0-6] 必須透過上述參數回報下列 ABI 清單的子集，且不得回報清單以外的任何 ABI。

  • [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 Surface 管理)
    • 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 中列出直接向第三方應用程式公開的其他非 AOSP 程式庫。

  • [C-0-10] 不得向指定 API 級別 24 以上版本的第三方應用程式公開任何其他原生程式庫，因為這些程式庫是在 AOSP 中實作及提供，屬於保留的系統程式庫。

  • [C-0-11] 必須透過 libGLESv3.so 程式庫，匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android 擴充套件函式符號。請注意，所有符號都「必須」存在，但第 7.1.4.1 節會更詳細地說明，何時需要完整實作每個對應函式。

  • [C-0-12] MUST export function symbols for the core Vulkan 1.1 function symbols, as well as the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, and VK_KHR_get_physical_device_properties2 extensions through the libvulkan.so library. 請注意，所有符號都「必須」存在，但第 7.1.4.2 節會更詳細說明何時需要完整實作每個對應函式。

  • 應使用上游 Android 開放原始碼計畫提供的原始碼和標頭檔建構。

請注意，Android 未來版本可能會支援其他 ABI。

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

如果裝置實作項目回報支援 armeabi ABI，則：

  • [C-3-1] 裝置也「必須」支援 armeabi-v7a 並回報支援情況，因為 armeabi 僅用於舊版應用程式的回溯相容性。

如果裝置實作項目回報支援 armeabi-v7a ABI，使用這個 ABI 的應用程式會：

  • [C-2-1] /proc/cpuinfo 中必須包含下列幾行，且不應變更同一裝置上的值，即使這些值是由其他 ABI 讀取也一樣。

    • Features:，後面接著裝置支援的任何選用 ARMv7 CPU 功能清單。
    • CPU architecture:，後面接著一個整數，說明裝置支援的最高 ARM 架構 (例如 ARMv8 裝置為「8」)。

  • [C-2-2] 即使 ABI 是透過原生 CPU 支援或軟體模擬，在 ARMv8 架構上實作，也必須一律提供下列作業：

    • SWP 和 SWPB 指令。
    • CP15ISB、CP15DSB 和 CP15DMB 障礙作業。

  • [C-2-3] 必須支援進階 SIMD (又稱 NEON) 擴充功能。

3.4. 網站相容性

3.4.1. WebView 相容性

如果裝置實作項目完整實作 android.webkit.Webview API，則：

  • [C-1-1] MUST report android.software.webview。

  • [C-1-2] 實作 android.webkit.WebView API 時，必須使用 Android 17 分支中，來自上游 Android 開放原始碼計畫的 Chromium 專案建構版本。

  • [C-1-3] 應用程式指定 SDK 等級 35 以下版本時，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 版本。

    • 裝置實作項目「可能」會省略使用者代理程式字串中的「Mobile」。

  • WebView 元件應盡可能支援多項 HTML5 功能，且如果支援該功能，應符合 HTML5 規格。

  • [C-1-4] MUST render the provided content or remote URL content in a process that is distinct from the application that instantiates the WebView. 具體來說，個別的算繪器程序「必須」持有較低的權限、以個別使用者 ID 執行、無法存取應用程式的資料目錄、沒有直接網路存取權，且只能透過 Binder 存取最低需求的系統服務。AOSP 實作的 WebView 符合這項規定。

Android 17 新增的規定

  • [C-1-5] 針對 SDK 等級 36 以上版本的應用程式，WebView 回報的系統預設使用者代理程式字串「必須」採用下列格式：

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
    • $(VERSION) 必須是靜態值 10。
    • $(MODEL) 必須是靜態字母 K。
    • $(CHROMIUM_MAJOR_VER)必須是上游 Android 開放原始碼計畫中的 Chromium 主要版本。
    • 裝置實作項目「可能」會省略使用者代理程式字串中的「Mobile」。

新增規定結束 (3.4.1 > C-1-5)

請注意，如果裝置實作項目為 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 取代網頁儲存空間，因此 IndexedDB 預計會成為日後 Android 版本的必要元件。

  • MAY 在獨立的瀏覽器應用程式中傳送自訂使用者代理程式字串。

  • 應盡可能在獨立的瀏覽器應用程式 (無論是以上游 WebKit 瀏覽器應用程式為基礎，還是第三方替代方案) 中，實作對HTML5 的支援。

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

3.5. API 行為相容性

裝置實作方式：

  • [C-0-9] MUST ensure that API behavioral compatibility is applied for all installed apps unless they are restricted as described in Section 3.5.1.
  • [C-0-10] MUST NOT implement the allowlisting approach that ensures API behavioral compatibility only for apps that are selected by device implementers.

各 API 類型 (受管理、軟體、原生和網頁) 的行為必須與上游 Android 開放原始碼計畫的偏好實作方式一致。相容性方面的一些具體領域包括：

  • [C-0-1] 裝置「不得」變更標準意圖的行為或語意。
  • [C-0-2] 裝置「不得」變更特定類型系統元件 (例如服務、活動、ContentProvider 等) 的生命週期或生命週期語意。
  • [C-0-3] 裝置「不得」變更標準權限的語意。
  • 裝置「不得」變更對背景應用程式強制執行的限制。 具體來說，針對背景應用程式：
    • [C-0-4] 必須停止執行應用程式註冊的回呼，以接收 GnssMeasurement 和 GnssNavigationMessage 的輸出內容。
    • [C-0-5] 透過 LocationManager API 類別或 WifiManager.startScan() 方法提供給應用程式的更新頻率「必須」受到速率限制。
    • [C-0-6] 如果應用程式指定 API 級別 25 以上版本，則除非廣播意圖需要 "signature" 或 "signatureOrSystem" protectionLevel 權限，或位於豁免清單中，否則應用程式資訊清單中不得允許註冊標準 Android 意圖的隱含廣播接收器。
    • [C-0-7] 如果應用程式指定 API 級別 25 以上版本，系統「必須」停止應用程式的背景服務，就像應用程式已呼叫服務的 stopSelf() 方法一樣，除非應用程式已加入暫時允許清單，可處理使用者可見的工作。
    • [C-0-8] 如果應用程式指定 API 級別 25 以上版本，則必須釋出應用程式持有的喚醒鎖定。
  • [C-0-11] 裝置必須從 Security.getProviders() 方法傳回下列安全防護供應商，做為前七個陣列值，且順序和名稱 (由 Provider.getName() 傳回) 和類別必須符合規定，除非應用程式已透過 insertProviderAt() 或 removeProvider() 修改清單。裝置「可能」會在下方指定的供應商清單後，傳回其他供應商。
    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. BC - 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] 除非有證據顯示系統健康狀態不良，否則不得自動套用這些專屬限制，但如果偵測到系統健康狀態不良 (例如喚醒鎖定卡住、服務長時間執行等)，則可對應用程式套用限制。裝置實作者「可以」決定條件，但「必須」與應用程式對系統健康狀態的影響有關。其他與系統健康狀態無關的條件 (例如應用程式在市場上不受歡迎)，不得做為評估標準。

  • [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] 規定。

如果裝置實作項目擴充了 AOSP 中實作的應用程式限制，則：

  • [C-2-1]必須按照本文件所述方式導入。

3.5.2. 應用程式休眠

如果裝置實作項目包含 Android 開放原始碼計畫 (AOSP) 內建的應用程式休眠功能，或擴充了 AOSP 內建的這項功能，則：

  • [C-1-1] 必須符合第 3.5.1 節中的所有規定，但 [C-1-6] 和 [C-1-3] 除外。
  • [C-1-2] 只有在有證據顯示使用者一段時間未使用應用程式時，才必須對該使用者套用應用程式限制。強烈建議您將這段時間設為一個月以上。使用情形必須透過 UsageStats#getLastTimeVisible() API 的明確使用者互動定義，或透過任何會導致應用程式離開強制停止狀態的項目定義，包括服務繫結、內容供應器繫結、明確的廣播等，這些項目會由新的 API UsageStats#getLastTimeAnyComponentUsed() 追蹤。
  • [C-1-3] 如有證據顯示任何使用者在一段時間內都未使用套件，則 MUST 僅適用於影響所有裝置使用者的限制。強烈建議這段時間至少為一個月。
  • [C-1-4] 不得導致應用程式無法回應活動意圖、服務繫結、內容供應器要求或明確的廣播。

AOSP 中的應用程式休眠功能符合上述規定。

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

裝置實作者「可以」在 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] MUST configure Dalvik runtimes to allocate memory in accordance with the upstream Android platform, and as specified by the following table. (如需螢幕大小和螢幕密度定義，請參閱第 7.1.1 節)。

  • 應使用 Android 執行階段 (ART)，這是 Dalvik 可執行檔格式的參考上游實作項目，以及參考實作項目的套件管理系統。

  • SHOULD run fuzz tests under various modes of execution and target architectures to assure the stability of the runtime. 請參閱 Android 開放原始碼計畫網站上的 JFuzz 和 DexFuzz。

請注意，以下指定的記憶體值為最小值，裝置實作 MAY 為每個應用程式分配更多記憶體。

螢幕版面配置 螢幕密度 應用程式記憶體下限
Android Watch 120 dpi (ldpi) 32 MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
小/一般 120 dpi (ldpi) 32 MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 dpi (420dpi) 112MB
480 dpi (xxhdpi) 128 MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256 MB
large 120 dpi (ldpi) 32 MB
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (xhdpi) 128 MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228MB
480 dpi (xxhdpi) 256 MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512 MB
特大 120 dpi (ldpi) 48MB
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8. 使用者介面相容性

3.8.1. 啟動器 (主畫面)

Android 包含啟動器應用程式 (主畫面)，並支援第三方應用程式取代裝置啟動器 (主畫面)。

如果裝置實作項目允許第三方應用程式取代裝置主畫面，則：

  • [C-1-1] 必須宣告平台功能 android.software.home_screen。

  • [C-1-2] 如果第三方應用程式使用 <adaptive-icon> 標記提供圖示，且呼叫 PackageManager 方法來擷取圖示，則 MUST 傳回 AdaptiveIconDrawable 物件。

如果裝置實作項目包含支援應用程式內捷徑固定功能的預設啟動器，則：

反之，如果裝置實作項目不支援在應用程式內釘選捷徑，則：

如果裝置實作項目實作了預設啟動器，可透過 ShortcutManager API 快速存取第三方應用程式提供的額外捷徑，則：

  • [C-4-1] 必須支援所有已記錄的快速鍵功能 (例如靜態和動態快速鍵、釘選快速鍵)，並完整實作 ShortcutManager API 類別的 API。

如果裝置實作項目包含預設啟動器應用程式，且該應用程式會顯示應用程式圖示的徽章，則：

  • [C-5-1] 必須遵守 NotificationChannel.setShowBadge() API 方法。換句話說，如果值設為 true，則顯示與應用程式圖示相關聯的視覺功能提示；如果所有應用程式的通知管道都將值設為 false，則不顯示任何應用程式圖示徽章配置。

  • 當第三方應用程式透過使用專屬 API 指出支援專屬徽章配置時，MAY 會以專屬徽章配置覆寫應用程式圖示徽章，但 SHOULD 使用SDK 中所述通知徽章 API 提供的資源和值，例如 Notification.Builder.setNumber() 和 Notification.Builder.setBadgeIconType() API。

如果裝置實作項目支援單色圖示，這些圖示會：

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

3.8.2. 小工具

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

如果裝置實作項目支援第三方應用程式小工具，則：

Android 17 中變更了需求條件的開始時間

  • [C-1-1] 必須宣告支援平台功能 android.software.app_widgets。

  • [C-1-2] 必須內建支援 AppWidget，並提供使用者介面功能提示，方便使用者新增、設定、預覽、移除、查看及調整 AppWidget 大小，除非使用者安全 (例如駕駛人分心) 受到威脅。

變更後的要求 (3.8.2 > C-1-1 和 C-1-2)
Android 17 移除的規定

  • [C-1-3] MUST be capable of rendering widgets that are 4 x 4 in the standard grid size. 詳情請參閱 Android SDK 說明文件中的「應用程式小工具設計指南」。

已移除的規定 (3.8.2 > C-1-3)
Android 17 新增的規定

新增規定結束 (3.8.2 > C-1-4 至 C-1-7)

  • 可能支援在螢幕鎖定畫面上顯示應用程式小工具。

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

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] MUST honor and implement properly the behaviors described for the APIs to update, remove and group notifications.

  • [C-1-4] MUST provide the full behavior of the NotificationChannel API documented in the SDK.

  • [C-1-5] 必須提供使用者功能，讓使用者能依管道和應用程式套件層級，封鎖及修改特定第三方應用程式的通知。

  • [C-1-6] MUST also provide a user affordance to display deleted notification channels.

  • [C-1-7] MUST correctly render all resources (images, stickers, icons, etc.) provided through Notification.MessagingStyle alongside the notification text without additional user interaction. 舉例來說，如果透過 setGroupConversation 設定群組對話，就必須顯示所有資源，包括透過 android.app.Person 提供的圖示。

  • [C-SR-1] 強烈建議提供使用者介面，讓使用者控管已授予「通知接聽程式」權限的應用程式可存取的通知。粒度必須達到使用者可針對每個這類通知監聽器，控制要橋接至該監聽器的通知類型。類型必須包含「對話」、「快訊」、「無聲」和「重要的持續性」通知。

  • [C-SR-2] 強烈建議提供使用者介面，讓使用者指定要排除哪些應用程式，不讓這些應用程式通知任何特定通知監聽器。

  • [C-SR-3] 建議在使用者多次關閉特定第三方應用程式的通知後，自動顯示使用者可用的功能提示，讓使用者封鎖該應用程式在每個管道和應用程式套件層級的通知。

  • 應支援複合式通知。

  • SHOULD 以抬頭通知形式顯示部分優先順序較高的通知。

  • SHOULD have a user affordance to snooze notifications.

  • MAY 只能管理第三方應用程式通知使用者重要事件的顯示時間和時機，以減少駕駛人分心等安全問題。

Android 11 支援對話通知，這類通知會使用 MessagingStyle，並提供已發布的 People 捷徑 ID。

裝置實作方式：

如果裝置實作項目支援 conversation notifications，且應用程式提供 bubbles 的必要資料，則：

  • [C-SR-5] 強烈建議將這個對話顯示為對話框。AOSP 實作項目符合這些需求，且預設使用系統 UI、設定和啟動器。

如果裝置實作支援豐富通知，則：

  • [C-2-1] 必須使用 Notification.Style API 類別及其子類別提供的確切資源，做為呈現的資源元素。

  • 應呈現 Notification.Style API 類別及其子類別中定義的每個資源元素 (例如圖示、標題和摘要文字)。

抬頭通知是系統在使用者所在介面以外顯示的通知。如果裝置實作支援抬頭通知，則：

3.8.3.2. 通知接聽器服務

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

裝置實作方式：

  • [C-0-1] MUST correctly and promptly update notifications in their entirety to all such installed and user-enabled listener services, including any and all metadata attached to the Notification object.

  • [C-0-2] 必須遵守 snoozeNotification() API 呼叫，並在 API 呼叫中設定的暫緩時間過後，關閉通知並進行回呼。

如果裝置實作項目提供延後通知的使用者功能，則：

  • [C-1-1] 必須透過 NotificationListenerService.getSnoozedNotifications() 等標準 API 正確反映已暫緩通知的狀態。

  • [C-1-2] 必須提供這項使用者功能，讓使用者暫緩接收各個已安裝第三方應用程式的通知，但來自持續性/前景服務的通知除外。

3.8.3.3. 零打擾/優先模式

如果裝置實作支援「勿擾」功能 (也稱為「優先模式」)，則：

  • [C-1-1] 裝置實作必須提供方法，讓使用者授予或拒絕第三方應用程式存取「請勿打擾」政策設定，並顯示應用程式建立的自動「請勿打擾」規則，以及使用者建立和預先定義的規則。

  • [C-1-3] 必須遵守沿著 NotificationManager.Policy 傳遞的 suppressedVisualEffects 值，且如果應用程式已設定任何 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 旗標，則應在「請勿打擾」設定選單中向使用者指出視覺效果已遭停用。

3.8.3.4. 敏感通知保護

私密通知資訊包括動態密碼、一次性確認碼，以及類似的驗證或重設代碼，這些資訊可能會顯示在傳送給使用者的通知中。

如果裝置實作項目允許第三方應用程式通知使用者重要事件，則：

  • [C-1-1] 除非監聽器服務屬於下列其中一種，否則系統「必須」從傳遞至通知監聽器的通知資訊中，遮蓋敏感資訊：

    • 系統簽署的應用程式，且 uid < 10000
    • 系統 UI
    • 貝殼
    • 指定的配對裝置應用程式 (由 CompanionDeviceManager 定義)
    • SYSTEM_AUTOMOTIVE_PROJECTION 角色
    • SYSTEM_NOTIFICATION_INTELLIGENCE 角色
    • HOME 角色

AOSP 實作的NotificationAssistantServices 即為符合這些規定的範例。如需範例，請參閱 android.ext.services.notification。

3.8.4. Assist API

Android 包含 Assist API，可讓應用程式選擇要與裝置上的 Google 助理分享多少目前情境的資訊。

Android 17 中變更了需求條件的開始時間

如果裝置實作支援「協助」動作，則：

  • [C-2-1] 必須清楚向使用者說明何時會分享內容，方法如下：

    • 每當小幫手應用程式存取內容時，螢幕邊緣會顯示白色光線，且持續時間和亮度符合或超過 Android 開放原始碼計畫的實作方式。

    • 對於預先安裝的小幫手應用程式，提供使用者功能提示，讓使用者在預設語音輸入和 Google 助理應用程式設定選單中，只需導覽兩次以下即可存取，且只有在使用者透過啟動字詞或輔助導覽鍵輸入明確叫用小幫手應用程式時，才分享內容。

  • [C-2-1] 只有在使用者透過輔助導覽鍵輸入、啟動字詞或其他指定進入點明確叫用小幫手應用程式時，才可與小幫手應用程式分享情境。

變更後的要求 (3.8.4 > C-2-1)

  • [C-2-2] 啟動小幫手應用程式的指定互動 (如第 7.2.3 節所述)「必須」啟動使用者選取的小幫手應用程式，也就是實作 VoiceInteractionService 的應用程式，或是處理 ACTION_ASSIST 意圖的活動。

3.8.5. 快訊和 Toast

應用程式可以使用 Toast API 向使用者顯示簡短的非模式字串，這些字串會在短時間後消失，並使用 TYPE_APPLICATION_OVERLAY 視窗類型 API，在其他應用程式上疊加顯示快訊視窗。

如果裝置實作項目包含螢幕或視訊輸出，則：

  • [C-1-1] 必須提供使用者介面，讓使用者封鎖應用程式顯示使用 TYPE_APPLICATION_OVERLAY 的警示視窗。AOSP 實作方式是在通知欄中提供控制項，因此符合這項規定。

  • [C-1-2] MUST honor the Toast API and display Toasts from applications to end users in some highly visible manner.

3.8.6. 主題

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

Android 包含「Holo」和「Material」主題系列，其中定義了一組樣式，供應用程式開發人員使用，以便配合 Android SDK 定義的 Holo 主題外觀和風格。

如果裝置實作項目包含螢幕或視訊輸出，則：

  • [C-1-1] 不得變更向應用程式公開的任何 Holo 主題屬性。

  • [C-1-2] 必須支援「Material」主題系列，且不得變更任何材質設計主題屬性或向應用程式公開的資產。

  • [C-1-3] 必須將「sans-serif」字型系列設為 Roboto 2.x 版 (適用於 Roboto 支援的語言)，或提供使用者功能提示，將「sans-serif」字型系列使用的字型變更為 Roboto 2.x 版 (適用於 Roboto 支援的語言)。

  • [C-1-4] 必須按照 AOSP Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 文件 (請參閱 android.theme.customization.system_palette 和 android.theme.customization.theme_style) 的規定，產生動態色彩色調調色盤。

  • [C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentation (see android.theme.customization.theme_styles), namely TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, andMONOCHROMATIC.

    與 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] MUST report the platform feature flag android.software.live_wallpaper.

3.8.8. 切換活動

上游 Android 原始碼包含總覽畫面，這是系統層級的使用者介面，可切換工作，並顯示最近存取的活動和工作，方法是使用使用者上次離開應用程式時，應用程式圖形狀態的縮圖。

裝置實作 (包括最近使用的功能導覽鍵，如第 7.2.3 節所述)「可能」會變更介面。

如果裝置實作 (包括第 7.2.3 節詳述的「最近使用的應用程式」功能導覽鍵) 會改變介面，則：

  • [C-1-1] 必須支援至少 7 項顯示的活動。

  • SHOULD 至少一次顯示 4 個活動的標題。

  • 「最近使用」畫面應顯示醒目顯示顏色、圖示和畫面標題。

  • 「應該」顯示關閉功能 (「x」)，但「可以」延遲顯示，直到使用者與畫面互動為止。

  • SHOULD 實作快速鍵，方便切換至上一個活動。

  • 應在輕觸兩下「最近使用的應用程式」功能鍵時，觸發最近使用的兩個應用程式之間的快速切換動作。

  • 如果裝置支援分割畫面多視窗模式，長按「最近使用」功能鍵「應該」會觸發該模式。

  • 可能將相關的近期項目顯示為可一起移動的群組。

  • [C-SR-1] 強烈建議使用上游 Android 使用者介面 (或類似的縮圖介面) 做為總覽畫面。

3.8.9. 輸入管理

Android 支援輸入管理，以及第三方輸入法編輯器。

如果裝置實作項目允許使用者在裝置上使用第三方輸入法，則：

  • [C-1-1] 必須宣告平台功能 android.software.input_methods，並支援 Android SDK 說明文件中定義的 IME API。

3.8.10. 透過螢幕鎖定畫面控制媒體

Android 5.0 以上版本已淘汰 Remote Control Client API，改用媒體通知範本，讓媒體應用程式整合顯示在螢幕鎖定畫面上的播放控制項。

3.8.11. 螢幕保護程式 (原為「夢境」)

如要瞭解如何設定螢幕保護程式，請參閱第 3.2.3.5 節。

3.8.12. 位置

如果裝置實作項目包含可提供位置座標的硬體感應器 (例如 GPS)，則：

3.8.13. Unicode 和字型

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

如果裝置實作項目包含螢幕或視訊輸出，則：

  • [C-1-1] 必須能夠以彩色字形顯示這些表情符號字元。

  • [C-1-2] 必須支援：

    • Roboto 2 字型，不同粗細的字體：sans-serif-thin、sans-serif-light、 sans-serif-medium、sans-serif-black、sans-serif-condensed、 sans-serif-condensed-light，適用於裝置支援的語言。

    • 完整涵蓋 Unicode 7.0 的拉丁文、希臘文和西里爾文，包括拉丁文擴充 A、B、C 和 D 範圍，以及 Unicode 7.0 貨幣符號區塊中的所有字形。

  • [C-1-3] 不得移除或修改系統映像檔中的 NotoColorEmoji.tff。 (可以新增表情符號字型，覆寫表情符號)NotoColorEmoji.tff

  • 應支援《Unicode 技術報告 #51》中指定的膚色和多元家庭表情符號。

如果裝置實作項目包含 IME，則：

  • SHOULD 為使用者提供這些表情符號字元的輸入法。

Android 支援算繪緬甸文字型。緬甸有幾種不符合 Unicode 標準的字型 (一般稱為「Zawgyi」)，用於顯示緬甸文。

如果裝置實作項目包含緬甸文支援，則：

  • [C-2-1] 必須以符合 Unicode 的字型預設算繪文字； 除非使用者在語言選單中選擇，否則不得將不符合 Unicode 的字型設為預設字型。

  • [C-2-2] 如果裝置支援非 Unicode 相容字型，則「必須」支援 Unicode 字型和非 Unicode 相容字型。不符合 Unicode 規範的字型「不得」移除或覆寫 Unicode 字型。

  • [C-2-3] 只有在指定指令碼代碼 Qaag 的語言代碼 (例如 my-Qaag) 時，才必須使用不符合 Unicode 標準的字型轉譯文字。其他 ISO 語言或地區代碼 (無論是已指派、未指派或保留) 都無法用於參照緬甸的非 Unicode 相容字型。應用程式開發人員和網頁作者可以指定 my-Qaag 做為指定語言代碼，就像指定任何其他語言一樣。

3.8.14. 多視窗

如果裝置實作項目可同時顯示多項活動，則：

  • [C-1-1] 必須根據 Android SDK 多視窗模式支援說明文件中說明的應用程式行為和 API，實作這類多視窗模式，並符合下列規定：

  • [C-1-2] Android 16 已移除這項規定。

  • [C-1-3] 如果螢幕高度小於 440 dp 且螢幕寬度小於 440 dp，則不得提供分割畫面或任意形式模式。

  • [C-1-4] 在子母畫面以外的多視窗模式中，活動大小不得縮小至 220 dp 以下。

Android 17 新增的規定

  • [C-1-5] 必須以完整不透明度顯示具有 selfMovable 屬性的工作，並提供可辨識的持續性裝飾 (例如說明文字列)，以及從這類持續性裝飾關閉工作的方法。

新增規定結束 (3.8.14 > C-1-5)

  • 螢幕尺寸 xlarge 的裝置實作項目「應」支援任意形式模式。

如果裝置實作項目支援多視窗模式和分割畫面模式，則：

  • [C-2-2] 如果啟動器應用程式是焦點視窗，則「必須」裁剪分割畫面多視窗模式的停駐活動，但「應」顯示部分內容。

  • [C-2-3] MUST honor the declared AndroidManifestLayout_minWidth and AndroidManifestLayout_minHeight values of the third-party launcher application and not override these values in the course of showing some content of the docked activity.

如果裝置實作支援多視窗模式和子母畫面多視窗模式，則：

  • [C-3-1] 應用程式在下列情況下，必須以子母畫面多視窗模式啟動活動：

  • [C-3-2] 必須透過 setActions() API，將 SystemUI 中的動作公開為目前子母畫面活動指定的動作。

  • [C-3-3] 必須支援大於或等於 1:2.39 且小於或等於 2.39:1 的顯示比例，如 PIP 活動透過 setAspectRatio() API 指定。

  • [C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如果未實作子母畫面模式，則必須將按鍵提供給前景活動。

  • [C-3-5] MUST provide a user affordance to block an app from displaying in PIP mode; the AOSP implementation meets this requirement by having controls in the notification shade.

  • [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 的高度。

如果裝置實作項目包含多個與 Android 相容的螢幕區域，並向應用程式提供這些區域，則：

  • [C-4-1] 必須支援多視窗模式。

如果裝置實作項目支援多視窗模式，則：

  • [C-5-1] MUST implement the correct version of the Window Manager Extensions API level as described in WindowManager Extensions.

3.8.15. 螢幕凹口

Android 支援螢幕凹口，詳情請參閱 SDK 文件。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] 除非使用者明確操作 (例如按下疊加層上的按鈕) 或指出要傳送內容，否則不得將剪貼簿資料傳送至任何元件、活動、服務或任何網路連線，但「9.8.6 內容擷取和應用程式搜尋」一節提及的服務除外。

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

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

AOSP 參考實作項目符合這些剪貼簿要求。

3.8.18. 位置資訊按鈕

Android 17 新增的規定

位置資訊按鈕是 Android UI 元素，應用程式開發人員可將其嵌入應用程式，以便在該應用程式的工作階段期間取得精確位置存取權。

裝置實作方式：

  • [C-0-1] 不得新增、修改或移除提供給應用程式開發人員的位置資訊按鈕自訂選項。

新增規定結束 (3.8.18 位置資訊按鈕)

3.9. 裝置管理

Android 內建多項功能，可讓裝置政策控制器應用程式透過 Device Policy Manager API，在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端清除作業。

3.9.1. 裝置佈建

3.9.1.1. 佈建裝置擁有者

如果裝置實作項目宣告 android.software.device_admin，則：

  • [C-1-1] 必須支援將裝置政策控制器 (DPC) 註冊為裝置擁有者應用程式，如下所述：

    • 如果裝置實作項目未設定使用者或使用者資料，則會發生下列情況：

      • [C-1-5] 如果裝置透過功能旗標 android.hardware.nfc 宣告支援近距離無線通訊 (NFC)，且收到含有 MIME 類型為 MIME_TYPE_PROVISIONING_NFC 記錄的 NFC 訊息，則必須將 DPC 應用程式註冊為裝置擁有者應用程式，或啟用 DPC 應用程式，讓使用者選擇要成為裝置擁有者或設定檔擁有者。

      • [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 15 已移除這項規定。

  • [C-2-1] Android 15 已移除這項規定。

  • [C-2-2] Android 15 已移除這項規定。

  • [C-2-3] Android 15 已移除這項規定。

3.9.1.2. 佈建受管理設定檔

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

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] 必須顯示通知圖示 (類似於 AOSP 上游工作徽章)，指出使用者何時位於受管理設定檔應用程式中。

  • [C-1-5] 裝置喚醒 (ACTION_USER_PRESENT) 時，如果前景應用程式位於受管理設定檔中，就必須顯示快訊，指出使用者位於受管理設定檔。

  • [C-1-6] 如果有受管理設定檔，則必須在 Intent「選擇器」中顯示視覺提示，讓使用者將 Intent 從受管理設定檔轉送至主要使用者 (或反向操作)，前提是裝置政策控制器已啟用這項功能。

  • [C-1-7] 如果有受管理設定檔，則必須為主要使用者和受管理設定檔提供下列使用者功能：

    • 分別計算主要使用者和受管理設定檔的電池、位置資訊、行動數據和儲存空間用量。
    • 獨立管理主要使用者或受管理設定檔中安裝的 VPN 應用程式。
    • 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
    • 在主要使用者或受管理設定檔中，獨立管理帳戶。

  • [C-1-8] 必須確保預先安裝的撥號、聯絡人和訊息應用程式可以搜尋及查詢受管理設定檔 (如有) 和主要設定檔中的來電者資訊 (如果裝置政策控制器允許)。

  • [C-1-9] 即使受管理設定檔不會計為主要使用者以外的其他使用者，也「必須」確保滿足啟用多使用者裝置的所有適用安全性規定 (請參閱第 9.5 節)。

  • [C-1-10] 如果使用者透過topActivity擷取螢幕畫面，且該畫面具有焦點 (使用者在所有活動中最後互動的畫面)，並屬於工作資料夾應用程式，則必須確保螢幕截圖資料儲存在工作資料夾儲存空間中。

  • [C-1-11] 儲存螢幕截圖到工作資料夾時，除了工作資料夾應用程式視窗，不得擷取任何其他螢幕內容 (系統資訊列、通知或任何個人資料夾內容)，確保個人資料夾資料不會儲存到工作資料夾。

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

  • [C-2-1] 必須支援指定獨立的螢幕鎖定，以符合下列需求，僅授予受管理設定檔中執行的應用程式存取權。

  • 當預先安裝的通話記錄、通話中 UI、進行中和未接來電通知中顯示受管理設定檔的聯絡人時，聯絡人和訊息應用程式「應該」會標示與受管理設定檔應用程式相同的徽章。

3.9.3. 受管理的使用者支援

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

  • [C-1-1] isLogoutEnabled 返回 true 時，必須提供使用者介面，讓使用者登出目前帳戶，並切換回多使用者工作階段中的主要使用者。使用者必須能從螢幕鎖定畫面存取使用者介面，且不必解鎖裝置。

如果裝置實作項目宣告 android.software.device_admin，並提供裝置端使用者功能提示，可新增其他次要使用者，則：

  • [C-SR-1] 應 STRONGLY RECOMMENDED 顯示與 android.app.action.PROVISION_MANAGED_DEVICE 啟動流程中顯示的相同 Android 開放原始碼計畫 裝置擁有者同意聲明揭露事項，然後再允許在新次要使用者中新增帳戶，讓使用者瞭解裝置受管理。

3.9.4. 裝置政策管理角色規定

如果裝置實作項目宣告 android.software.device_admin，則：

  • [C-1-1] MUST support the device policy management role as defined in Section 9.1. 您可以將 config_devicePolicyManagement 設為套件名稱，定義擁有裝置政策管理角色的應用程式。除非應用程式已預先載入，否則套件名稱後方「必須」加上半形冒號 (:) 和簽署憑證。

如果未如上所述為 config_devicePolicyManagement 定義套件名稱：

如果已為 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.9.5. 裝置政策解決架構

如果裝置實作項目宣告 android.software.device_admin，則：

3.10. 無障礙設定

Android 提供無障礙層，可協助身心障礙使用者更輕鬆地操作裝置。此外，Android 也提供平台 API，讓無障礙服務實作項目接收使用者和系統事件的回呼，並產生替代意見回饋機制，例如文字轉語音、觸覺回饋，以及觸控球/D-Pad 導覽。

如果裝置實作項目支援第三方無障礙服務，則：

  • [C-1-1] MUST 提供 Android 無障礙架構的實作項目，如 Accessibility API SDK 說明文件所述。
  • [C-1-2] MUST generate accessibility events and deliver the appropriate AccessibilityEvent to all registered AccessibilityService implementations as documented in the SDK.
  • [C-1-4] MUST provide a user affordance to control accessibility services that declare the AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. 請注意，如果裝置實作項目有系統導覽列，則「應」允許使用者在系統導覽列中選擇按鈕，以便控制這些服務。

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

  • [C-2-1] 如果資料儲存空間採用檔案型加密 (FBE) 技術加密，則預先安裝的無障礙服務必須以直接啟動感知應用程式的形式實作。
  • 在開箱設定流程中，應提供機制讓使用者啟用相關無障礙服務，以及調整字型大小、顯示大小和放大手勢的選項。

3.11. Text-to-Speech

Android 內含的 API 可供應用程式使用文字轉語音 (TTS) 服務，服務供應商也能提供 TTS 服務的實作項目。

如果裝置實作項目回報 android.hardware.audio.output 功能，則：

如果裝置實作支援安裝第三方 TTS 引擎，則：

  • [C-2-1] 必須提供使用者功能提示，讓使用者選取要在系統層級使用的文字轉語音引擎。

3.12. 不適用

3.13. 快速設定

Android 提供「快速設定」UI 元件，可快速存取常用或急需執行的動作。

如果裝置實作項目包含「快速設定」UI 元件，且支援第三方「快速設定」，則：

  • [C-1-1] 必須允許使用者透過第三方應用程式新增或移除 quicksettings API 提供的動態磚。
  • [C-1-2] 不得直接在「快速設定」中自動新增第三方應用程式的動態磚。
  • [C-1-3] 必須顯示使用者從第三方應用程式新增的所有動態磚，以及系統提供的快速設定動態磚。

3.14. 媒體 UI

如果裝置實作項目包含透過 MediaBrowser 或 MediaSession 與第三方應用程式互動的非語音啟動應用程式 (以下簡稱「應用程式」)，則這些應用程式：

  • [C-1-2] 必須清楚顯示透過 getIconBitmap() 或 getIconUri() 取得的圖示，以及透過 getTitle() 取得的標題，如 MediaDescription 所述。 可能會縮短標題，以符合安全法規 (例如駕駛人分心)。

  • [C-1-3] 顯示第三方應用程式提供的內容時，必須顯示該應用程式的圖示。

  • [C-1-4] MUST allow the user to interact with the entire MediaBrowser hierarchy. 為遵守安全法規 (例如駕駛人分心)，MAY 限制部分層級的存取權，但 MUST NOT 根據內容或內容供應商給予優先待遇。

  • [C-1-5] MUST consider double tap of KEYCODE_HEADSETHOOK or KEYCODE_MEDIA_PLAY_PAUSE as KEYCODE_MEDIA_NEXT for MediaSession.Callback#onMediaButtonEvent.

3.15. 免安裝應用程式

如果裝置實作支援免安裝應用程式，則必須符合下列規定：

  • [C-1-1] 即時應用程式「只能獲得具有 android:protectionLevel "instant" 權限的權限。
  • [C-1-2] 免安裝應用程式「不得」透過隱含意圖與已安裝的應用程式互動，除非符合下列任一條件：
    • 元件的意圖模式篩選器已公開，且具有 CATEGORY_BROWSABLE
    • 動作為 ACTION_SEND、ACTION_SENDTO 或 ACTION_SEND_MULTIPLE 其中之一
    • 目標會透過 android:visibleToInstantApps 明確公開
  • [C-1-3] 免安裝應用程式不得與已安裝的應用程式明確互動，除非元件是透過 android:visibleToInstantApps 公開。
  • [C-1-4] 安裝的應用程式不得查看裝置上免安裝應用程式的詳細資料，除非免安裝應用程式明確連結至已安裝的應用程式。

  • 裝置實作內容「必須」提供下列使用者功能，以便與免安裝應用程式互動。AOSP 預設的系統 UI、設定和啟動器符合這些需求。裝置實作方式：

    • [C-1-5] 必須提供使用者功能提示，讓使用者查看及刪除個別應用程式套件本機快取的免安裝應用程式。
    • [C-1-6] 免安裝應用程式在前台執行時，必須提供可收合的常駐使用者通知。這則使用者通知「必須」包含免安裝應用程式不需要安裝的資訊，並提供使用者提示，將使用者導向「設定」中的應用程式資訊畫面。如果是透過網頁意圖啟動的免安裝應用程式 (定義方式為使用動作設為 Intent.ACTION_VIEW 的意圖，且使用「http」或「https」的架構)，額外的使用者功能提示「應」允許使用者不啟動免安裝應用程式，並使用設定的網路瀏覽器啟動相關聯的連結 (如果裝置上有瀏覽器)。
    • [C-1-7] 如果裝置提供「最近」功能，則「最近」功能必須允許存取執行的免安裝應用程式。

  • [C-1-8] MUST preload one or more applications or service components with an intent handler for the intents listed in the SDK here and make the intents visible for Instant Apps.

3.16. 配對裝置配對連線

Android 支援隨附裝置配對，可更有效管理與隨附裝置的關聯，並提供 CompanionDeviceManager API 供應用程式存取這項功能。

如果裝置實作項目支援隨附裝置配對功能，則：

  • [C-1-1] 必須宣告功能旗標 FEATURE_COMPANION_DEVICE_SETUP。

  • [C-1-2] 必須確保android.companion套件中的 API 已完全導入。

  • [C-1-3] 必須提供使用者介面，供使用者選取/確認配對裝置存在且可運作，且必須使用 Android 開放原始碼計畫 中實作的相同訊息，不得新增或修改。

3.17. 耗用大量資源的應用程式

如果裝置實作項目宣告了 FEATURE_CANT_SAVE_STATE 功能，則：

  • [C-1-1] 系統一次只能安裝一個指定 cantSaveState 的安裝版應用程式。如果使用者離開這類應用程式時，並未明確結束應用程式 (例如在離開系統中的現有活動時按下主畫面按鈕，而不是按下返回按鈕，且系統中沒有其他現有活動)，則裝置實作方式必須優先處理該應用程式的 RAM，就像處理其他預期會持續執行的項目 (例如前景服務) 一樣。這類應用程式在背景執行時，系統仍可對其套用電源管理功能，例如限制 CPU 和網路存取權。
  • [C-1-2] MUST provide a UI affordance to chose the app that won't participate in the normal state save/restore mechanism once the user launches a second app declared with cantSaveState attribute.
  • [C-1-3] MUST NOT apply other changes in policy to apps that specify cantSaveState, such as changing CPU performance or changing scheduling prioritization.

如果裝置實作項目未宣告 FEATURE_CANT_SAVE_STATE 功能，則：

  • [C-1-1] MUST ignore the cantSaveState attribute set by apps and MUST NOT change the app behavior based on that attribute.

3.18. 聯絡人

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

當原始聯絡人的 ACCOUNT_NAME、ACCOUNT_TYPE 欄位與帳戶的 Account.name 和 Account.type 欄位相符時，原始聯絡人會「與」帳戶「建立關聯」或「儲存在」帳戶中。

預設本機帳戶：用於儲存原始聯絡人的帳戶，這類聯絡人只會儲存在裝置上，不會與 AccountManager 中的帳戶建立關聯，且是使用 null 值建立，適用於 ACCOUNT_NAME 和 ACCOUNT_TYPE 欄。

自訂本機帳戶：用於儲存原始聯絡人的帳戶，這類聯絡人只會儲存在裝置上，不會與 AccountManager 中的帳戶建立關聯，且是使用 ACCOUNT_NAME 和 ACCOUNT_TYPE 欄的非空值建立。

裝置實作方式：

  • [C-SR-1] 強烈建議不要建立自訂本機帳戶。

如果裝置實作項目使用自訂本機帳戶：

  • [C-1-1] 自訂本機帳戶的 ACCOUNT_NAME 必須在 ContactsContract.RawContacts.getLocalAccountName 前退回

  • [C-1-2] 自訂本機帳戶的 ACCOUNT_TYPE 必須由 ContactsContract.RawContacts.getLocalAccountType 傳回

  • [C-1-3] 第三方應用程式插入的原始聯絡人，如未指定帳戶，則必須插入裝置的預設聯絡人帳戶。如果預設聯絡人帳戶是 DEFAULT_ACCOUNT_STATE_LOCAL 或 DEFAULT_ACCOUNT_STATE_NOT_SET，這些原始聯絡人必須儲存在自訂本機帳戶中。

  • [C-1-4] 將原始聯絡人插入自訂本機帳戶時，新增或移除帳戶後，系統「不得」移除這些聯絡人。

  • [C-1-5] 對自訂本機帳戶執行的刪除作業必須立即清除原始聯絡人 (如同 CALLER_IS_SYNCADAPTER 參數設為 true)，即使 CALLER_IS_SYNCADAPTER 參數設為 false 或未指定也一樣。

Android 17 新增的規定

SIM 卡帳戶：從插入裝置的一或多張實體 SIM 卡鏡像複製的原始聯絡人帳戶，且未與 AccountManager 中的帳戶建立關聯。

裝置實作方式：

如果裝置實作項目使用 SIM 卡帳戶：

新增規定 (3.18 SIM 帳戶) 結束

3.18.2. 系統聯絡人挑選器

Android 17 新增的規定

Android 支援系統聯絡人挑選器，可讓應用程式存取有限的聯絡人資訊，不必取得廣泛的存取權。

如果裝置實作項目支援 Android 聯絡人，則：

  • [C-1-1] 如果應用程式指定 API 級別 37 以上版本，則「必須」實作系統聯絡人選擇工具 (com.android.contactspicker)。

  • [C-1-2] 必須實作 Intent.ACTION_PICK_CONTACTS 意圖。

新增規定結束 (3.18.2 系統聯絡人挑選器)

3.19. 語言設定

裝置實作方式：

  • [C-0-1] 對於不支援性別特定翻譯的語言，不得提供任何使用者功能，讓使用者選取性別特定語言處理方式。詳情請參閱文法資源。

3.20. 以 Google 助理為基礎的體驗

Android 17 新增的規定

Android 助理開發架構可讓您用語音控制 Android 應用程式。使用者可以透過 Google 助理，以語音啟動應用程式、執行工作、存取內容等。

如需本節內容，請參閱下列特殊裝置實作項目的分類：

  • 固定音量：固定音量裝置具有音量控制功能，但會禁止應用程式使用標準 AudioManager 方法變更音訊串流層級 (例如 Android Automotive OS 車輛)。

  • 全音量：全音量裝置的音量會鎖定在全音量，且無法衰減，並禁止軟體控制音量 (例如使用外接音箱的電視)。

  • 單一音量：單一音量裝置會將所有音訊串流對應至單一音量串流，因此調整音量時，所有音訊串流都會受到影響 (例如電視)。

新增需求條件 (3.20 Google 助理體驗) 結束

3.20.1. Google 助理音訊串流的相關規定

Android 17 新增的規定

持有 MANAGE_ASSISTANT_AUDIO 權限的應用程式：

  • [C-0-1] MUST be allowed to change STREAM_ASSISTANT volume programmatically.

如果裝置實作項目未宣告 android.hardware.type.watch，且不是固定音量、單一音量或全音量，則會發生以下情況：

  • [C-1-1] 必須將 STREAM_ASSISTANT 實作為已分離的音訊串流，且不得別名為任何其他串流。

  • [C-1-2] MUST ensure that audio playback using AudioAttributes with USAGE_ASSISTANT has its playback volume controlled by STREAM_ASSISTANT.

  • [C-1-3] 必須確保藍牙耳機在 A2DP 和 HFP 音訊設定檔之間切換時，音量索引維持不變。STREAM_ASSISTANT

  • [C-1-4] MODE_ASSISTANT_CONVERSATION 處於啟用狀態時，裝置「必須」禁止任何其他串流變更 STREAM_ASSISTANT 的音量，或套用至 USAGE_ASSISTANT 播放的衰減。STREAM_ASSISTANT

  • [C-1-5] 透過裝置或周邊裝置 (例如藍牙頭戴式耳機) 音量鍵調整音量時，必須變更 STREAM_ASSISTANT 串流音量，且不得變更其他串流音量，且須符合下列條件：

    • 「MODE_ASSISTANT_CONVERSATION」已啟用，且
    • 無法進行應用程式專屬自訂或啟用遠端播放。

  • [C-1-6] 必須在使用者介面中反映 Google 助理音量的任何變更。

新增規定結束 (3.20.1 助理音訊串流規定)

3.21. 隨附裝置同步功能支援

Android 17 新增的規定

Android 支援在隨附裝置之間同步處理資料。

如果裝置實作項目支援「零打擾」同步功能，則：

  • [C-1-1] 必須導入 ContextualModeManager#isModeSyncSupported API。

  • [C-1-2] MUST sync the setting indicating that Do Not Disturb is enabled through the CompanionDeviceManager secure channel using a data format compatible with the default CompanionDeviceManagerService implementation.

  • [C-1-3] 如果 ContextualModeManager#isModeSyncEnabled 傳回 true，就必須啟用這項同步功能。

如果裝置實作項目支援飛航模式同步功能，則：

  • [C-1-4] MUST sync the setting indicating that Airplane mode is enabled through the CompanionDeviceManager secure channel using a data format compatible with the default CompanionDeviceManagerService implementation.

  • [C-1-5] 如果啟用 Settings.Global.AIRPLANE_MODE_SYNC，就「必須」啟用這項同步功能。

新增規定結束 (3.21 隨附裝置同步功能支援)

3.22. ComputerControls API

Android 17 新增的規定

支援的代理程式可透過 ComputerControls API，代表使用者在 Android 裝置上自主執行動作，完成工作。

[C-1-1] 如果裝置實作項目預先載入擴充功能程式庫 com.android.extensions.computercontrol 來支援 ComputerControl，則：

  • 必須啟用 android.software.activities_on_secondary_display。
  • 必須顯示系統功能 com.android.extensions.computercontrol 為可用。
  • 必須啟用 VirtualDeviceManager。
  • 必須在 PackageManager#getSharedLibraries() 傳回的清單中加入 com.android.extensions.computercontrol。
  • 必須預先載入平台應用程式 com.android.virtualdevicemanager (建構目標 VirtualDeviceManager)。

新增需求結束 (3.22 ComputerControls API)

4. 應用程式封裝相容性

裝置實作方式：

  • [C-0-1] 必須能夠安裝及執行 Android「.apk」檔案，這些檔案是由官方 Android SDK 內含的「aapt」工具產生。
    • 由於上述要求可能較為困難，建議裝置實作項目使用 AOSP 參考實作項目的套件管理系統。

Android 17 中變更了需求條件的開始時間

變更後的要求 (4.0 > C-0-2)

  • [C-0-3] 不得擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式，以免這些檔案無法在其他相容裝置上正確安裝及執行。

  • [C-0-4] MUST NOT allow apps other than the current "installer of record" for the package to silently uninstall the app without any user confirmation, as documented in the SDK for the DELETE_PACKAGE permission. 例外狀況只有系統套件驗證應用程式處理 PACKAGE_NEEDS_VERIFICATION Intent，以及儲存空間管理工具應用程式處理 ACTION_MANAGE_STORAGE Intent。

  • [C-0-5] 必須有處理 android.settings.MANAGE_UNKNOWN_APP_SOURCES 意圖的活動。

  • [C-0-6] MUST NOT install application packages from unknown sources, unless the app that requests the installation meets all the following requirements:

    • 必須宣告 REQUEST_INSTALL_PACKAGES 權限，或將 android:targetSdkVersion 設為 24 以下。
    • 使用者必須已授予權限，才能從不明來源安裝應用程式。

  • SHOULD provide a user affordance to grant/revoke the permission to install apps from unknown sources per application, but MAY choose to implement this as a no-op and return RESULT_CANCELED for startActivityForResult(), if the device implementation does not want to allow users to have this choice. 不過，即使在這種情況下，他們也「應該」向使用者說明為何沒有顯示這類選項。

  • [C-0-7] 啟動應用程式中的活動前，系統必須透過系統 API PackageManager.setHarmfulAppWarning 顯示警告對話方塊，並提供警告字串給使用者。該應用程式已由同一個系統 API PackageManager.setHarmfulAppWarning 標示為可能有害。

  • SHOULD 提供使用者介面，讓使用者在警告對話方塊中選擇解除安裝或啟動應用程式。

  • [C-0-8] 必須實作對增量檔案系統的支援，如這裡所述。

  • [C-0-9] 必須支援使用 APK 簽署配置 v4 和 APK 簽署配置 v4.1 驗證 .apk 檔案。

5. 多媒體相容性

裝置實作方式：

  • [C-0-1] 必須支援 MediaCodecList 宣告的每種轉碼器，以及第 5.1 節中定義的媒體格式、編碼器、解碼器、檔案類型和容器格式。
  • [C-0-2] MUST declare and report support of the encoders, decoders available to third-party applications via MediaCodecList.
  • [C-0-3] 必須能夠正確解碼，並向第三方應用程式提供所有可編碼的格式。這包括編碼器產生的所有位元串流，以及 CamcorderProfile 中回報的設定檔。

裝置實作方式：

  • SHOULD aim for minimum codec latency, in others words, they
    • 不應取用及儲存輸入緩衝區，且只應在處理後傳回輸入緩衝區。
    • 不應保留解碼緩衝區，時間長度超過標準 (例如 SPS) 指定的時間。
    • 不應保留編碼緩衝區，時間長度超過 GOP 結構所需。

以下各節列出的所有轉碼器，都是 Android 開放原始碼計畫中偏好的 Android 實作方式，以軟體實作形式提供。

請注意，Google 和 Open Handset Alliance 均未聲明這些轉碼器不受第三方專利限制。有意在硬體或軟體產品中使用這項原始碼者，請注意，實作這項程式碼 (包括在開放原始碼軟體或共享軟體中) 可能需要取得相關專利權人的專利授權。

5.1. 媒體轉碼器

5.1.1. 音訊編碼

詳情請參閱 5.1.3 節。音訊轉碼器詳細資料。

如果裝置實作項目宣告 android.hardware.microphone，就「必須支援下列音訊格式的編碼，並提供給第三方應用程式：

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

Android 17 新增的規定

  • [C-1-4] MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC)

新增規定結束 (5.1.1 > C-1-4)

所有音訊編碼器都必須支援：

Android 17 新增的規定

使用 MPEG-D DRC (Extended High Efficiency AAC) 音訊編碼 MPEG-D USAC 時：

  • [C-3-2] 所有位元串流都必須包含符合 MPEG-D 音量控制設定檔或 MPEG-D 動態範圍控制設定檔 (第 1 級以上) 的中繼資料集，且須符合 ISO/IEC 23003-4 規定。

新增規定結束 (5.1.1 > C-3-2)

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-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE，包括高解析度音訊格式，最高可達 24 位元、192 kHz 取樣率和 8 個聲道。請注意，這項規定僅適用於解碼，裝置可在播放階段進行降取樣和降混。
  • [C-1-10] Opus
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 擴充 HE AAC 設定檔，包含 USAC 基準設定檔和 ISO/IEC 23003-4 動態範圍控制設定檔)

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

  • [C-2-1] 解碼時不得進行下混 (例如，5.0 AAC 串流必須解碼為五個聲道的 PCM，5.1 AAC 串流必須解碼為六個聲道的 PCM)。

  • [C-2-2] 動態範圍中繼資料必須符合 ISO/IEC 14496-3「Dynamic Range Control (DRC)」的定義，且 android.media.MediaFormat DRC 鍵可設定音訊解碼器的動態範圍相關行為。API 21 導入了 AAC DRC 鍵，包括：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 Dynamic Range Control Profile Level 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 中繼資料應優先處理。

所有音訊解碼器「必須」支援輸出：

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

  • [C-7-1] 應用程式「必須」能夠使用以金鑰 KEY_MAX_OUTPUT_CHANNEL_COUNT 解碼的方式進行設定，藉此控制內容是否要下混為立體聲 (使用值為 2 時)，或是使用原生聲道數輸出 (使用大於或等於該數的值時)。舉例來說，如果值為 6 以上，解碼器在輸入 5.1 內容時，就會輸出 6 個聲道。

  • [C-7-2] 解碼時，解碼器必須使用 KEY_CHANNEL_MASK 鍵，以 android.media.AudioFormat 常數 (例如：CHANNEL_OUT_5POINT1) 宣傳輸出格式所用的聲道遮罩。

Android 17 新增的規定

所有具備空間音效效果的手持式或平板電腦裝置，以及所有車用和電視裝置：

  • [C-8-1] 必須支援解碼包含以 AAC、FLAC、Opus 或 PCM 編碼音訊串流的 IAMF v1.0，且必須透過 android.media.MediaCodec API 提供 IAMF 解碼器。

  • [C-8-2] 必須確保 IAMF 解碼器會遵守用於透過 KEY_CHANNEL_MASK 鍵設定的聲道遮罩，並使用 android.media.AudioFormat 常數 (例如 CHANNEL_OUT_5POINT1)。

  • [C-8-3] MUST ensure the IAMF decoder advertises the active channel mask on the output format via the KEY_CHANNEL_MASK key, using android.media.AudioFormat constants such as CHANNEL_OUT_5POINT1.

新增規定結束 (5.1.2 > C-8-1 至 C-8-3)

如果裝置實作支援預設 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. 音訊轉碼器詳細資料

Android 17 中變更了需求條件的開始時間
格式/轉碼器 詳細資料 支援的檔案類型/容器格式
G.711 μ-law 和 A-law 支援以 8 kHz 取樣的單聲道/立體聲/5.1 內容
  • WAVE (.wav)
MPEG-4 AAC 設定檔
(AAC LC)		 支援單聲道/立體聲/5.0/5.1 內容，標準取樣率為 8 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
  • ADTS 原始 AAC (.aac，不支援 ADIF)
  • MPEG-TS (.ts，無法搜尋，只能解碼)
  • Matroska (.mkv，僅限解碼)
MPEG-4 HE AAC 設定檔 (AAC+) 支援單聲道/立體聲/5.0/5.1 內容，標準取樣率為 16 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
MPEG-4 HE AACv2
設定檔 (增強型 AAC+)		 支援單聲道/立體聲/5.0/5.1 內容，標準取樣率為 16 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
AAC ELD (增強型低延遲 AAC) 支援取樣率介於 16 到 48 kHz 的單聲道/立體聲內容。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
USAC MPEG-D USAC with MPEG-D DRC (Extended High Efficiency AAC) 解碼：支援單聲道/立體聲內容，標準取樣率為 7.35 至 48 kHz。
編碼：支援取樣率為 44.1 和 48 kHz 的單聲道/立體聲內容。 		MPEG-4 (.mp4、.m4a)
AMR-NB 4.75 至 12.2 kbps，取樣頻率為 8 kHz 3GPP (.3gp)
AMR-WB 9 種速率，從 6.60 kbit/s 到 23.85 kbit/s，以 16 kHz 取樣，如 AMR-WB，Adaptive Multi-Rate - Wideband Speech Codec 所定義 3GPP (.3gp)
FLAC 編碼器和解碼器都必須支援至少單聲道和立體聲模式。必須支援最高 192 kHz 的取樣率，以及 16 位元和 24 位元的解析度。處理 24 位元 FLAC 音訊資料時，必須使用浮點音訊設定。
  • FLAC (.flac)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MP3 單聲道/立體聲 8-320Kbps 固定位元率 (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 解碼：支援取樣率為 8000、12000、16000、24000 和 48000 Hz 的單聲道、立體聲、5.0 和 5.1 內容。
編碼：支援取樣率為 8000、12000、16000、24000 和 48000 Hz 的單聲道和立體聲內容。
  • 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 解碼：支援取樣率為 8000、12000、16000、24000 和 48000 Hz 的單聲道、立體聲、5.0 和 5.1 內容。
編碼：支援取樣率為 8000、12000、16000、24000 和 48000 Hz 的單聲道和立體聲內容。
  • Ogg (.ogg)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv)
  • Webm (.webm)
變更後的規定 (5.1.3 音訊編解碼器表格)

5.1.4. 圖片編碼

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

裝置實作項目「必須」支援下列圖片編碼：

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP
  • [C-0-4] AVIF
    • 裝置必須支援 BITRATE_MODE_CQ 和基準設定檔。

如果裝置實作項目支援透過 android.media.MediaCodec 為媒體類型 MIMETYPE_IMAGE_ANDROID_HEIC 進行 HEIC 編碼，則：

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

5.1.5. 圖片解碼

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

裝置實作內容「必須」支援解碼下列圖片編碼：

  • [C-0-1] JPEG

  • [C-0-2] GIF

  • [C-0-3] PNG

  • [C-0-4] BMP

  • [C-0-5] WebP

  • [C-0-6] Raw

  • [C-0-7] AVIF (基準設定檔)

如果裝置實作項目支援 HEVC 視訊解碼，則：

  • [C-1-1] 必須支援 HEIF (HEIC) 圖片解碼。

支援高位元深度格式 (每個通道 9 位元以上) 的圖片解碼器：

  • [C-2-1] 如應用程式要求，例如透過 android.graphics.Bitmap 的 ARGB_8888 設定，則必須支援輸出 8 位元等效格式。

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)
AVIF (基準設定檔) 圖片、圖片集、圖片序列基準設定檔 HEIF 容器 (.avif)

透過 MediaCodec API 公開的圖片編碼器和解碼器

  • [C-1-1] MUST support YUV420 8:8:8 flexible color format (COLOR_FormatYUV420Flexible) through CodecCapabilities.

  • [C-SR-1] 強烈建議支援 RGB888 顏色格式，以用於輸入 Surface 模式。

  • [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 讀取進行最佳化。

Android 17 新增的規定

如果裝置實作項目包含視訊解碼器或編碼器：

  • [C-5-1] 影片解碼器使用 2003 年或之後的編碼技術 (例如 AV1、AVC、HEVC、VP8、VP9 或 VVC) 時，必須：

    • 支援的最小尺寸為 144 x 144 像素，且
    • 透過 VideoCapabilities API (例如 getSupportedWidths() 和 getSupportedHeightsFor() 方法) 宣傳這項支援。

  • [C-5-2] 使用 2003 年後編碼技術 (例如 AV1、AVC、HEVC、VP8、VP9 或 VVC) 的影片編碼器「必須」：

    • 支援 Surface 輸入，每個編碼器的最小大小如下：
      • AVC：160x160 像素
      • VP8、HEVC、VP9 (如果提供編碼器)：160x160 像素
      • AV1 (如提供編碼器)：256x256 像素
    • MAY 產生比最小值大的影格大小的位元串流，前提是他們使用裁剪矩形資訊編碼適當的大小。

新增規定結束 (5.1.7 > C-5-1 和 C-5-2)

5.1.8. 視訊轉碼器清單

格式/轉碼器 詳細資料 支援的檔案類型/容器格式
H.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 節
VP9 詳情請參閱第 5.3 節
AV1 詳情請參閱第 5.2 節和第 5.3 節
  • MPEG-4 (.mp4)
  • Matroska (.mkv，僅限解碼)

5.1.9. 媒體轉碼器安全性

裝置實作項目「必須」確保符合媒體轉碼器安全功能，如下所述。

Android 支援跨平台的 OMX 多媒體加速 API，以及低負荷的 Codec 2.0 多媒體加速 API。

如果裝置實作支援多媒體，則：

  • [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 開放原始碼計畫中對應的 Codec 2.0 軟體轉碼器 (如有)。

  • [C-3-2] 必須將 Codec 2.0 軟體轉碼器放在 Android 開放原始碼計畫提供的軟體轉碼器程序中，以便更精確地授予軟體轉碼器存取權。

  • [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] 編解碼器名稱不得誤導使用者。舉例來說，名為「decoders」的轉碼器必須支援解碼，而名為「encoders」的轉碼器則必須支援編碼。名稱包含媒體格式的轉碼器必須支援這些格式。

如果裝置實作支援視訊轉碼器：

  • [C-2-1] 如果視訊轉碼器支援下列大小，則所有視訊轉碼器都必須發布可達成的影格率資料：
SD (畫質不佳) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p UHD
影片解析度
  • 176 x 144 像素 (H263、MPEG2、MPEG4)
  • 352 x 288 像素 (MPEG4 編碼器、H263、MPEG2)
  • 320 x 180 像素 (VP8、VP8)
  • 320 x 240 像素 (其他)
  • 704 x 576 像素 (H263)
  • 640 x 360 像素 (VP8、VP9)
  • 640 x 480 像素 (MPEG4 編碼器)
  • 720 x 480 像素 (其他，AV1)
  • 1408 x 1152 像素 (H263)
  • 1280 x 720 像素 (其他，AV1)
 1920 x 1080 像素 (MPEG4、AV1 以外的格式) 3840 x 2160 像素 (HEVC、VP9、AV1)

  • [C-2-2] 凡是歸類為硬體加速的視訊轉碼器，都「必須」發布效能點資訊。除非已由其他支援的標準效能點涵蓋，否則每個標準效能點都必須列出所有支援的標準效能點 (列於 PerformancePoint API 中)。

  • 此外，如果支援標準效能點以外的持續影片成效，也「應該」發布擴展效能點。

5.2. 影片編碼

如果裝置實作項目支援任何影片編碼器並提供給第三方應用程式，且將
MediaFormat.KEY_BITRATE_MODE 設為 BITRATE_MODE_VBR，讓編碼器以可變位元率模式運作，只要不影響最低畫質下限，編碼位元率：

  • 在一個滑動視窗中，不得超過影格內 (I 影格) 間隔位元率的 15%。
  • 在 1 秒的滑動視窗中，不應超過位元率的 100%。

如果裝置實作項目支援任何視訊編碼器，並提供給第三方應用程式使用，且將 MediaFormat.KEY_BITRATE_MODE 設為 BITRATE_MODE_CBR，讓編碼器以固定位元率模式運作，則編碼位元率：

  • [C-SR-2] 強烈建議在 1 秒的滑動視窗內，不要超過目標位元率的 15%。

如果裝置實作項目包含對角長度至少 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 影片編碼器，並提供給第三方應用程式使用，則：

  • SHOULD 支援為支援的編碼器動態設定位元率。

如果裝置實作項目提供硬體加速的影片或圖片編碼器，且支援透過 android.camera API 公開的一或多個附加或可插拔的硬體攝影機：

  • [C-4-1] 所有硬體加速的影片和圖片編碼器都必須支援從硬體攝影機編碼影格。
  • 應支援透過所有視訊或圖片編碼器，從硬體攝影機編碼影格。

如果裝置實作項目提供 HDR 編碼，則：

  • [C-SR-1] 強烈建議提供外掛程式，以便透過無縫轉碼 API 將 HDR 格式轉換為 SDR 格式。

5.2.1. H.263

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

  • [C-1-1] 必須支援使用基準設定檔層級 45 的 QCIF 解析度 (176 x 144)。SQCIF 解析度為選用項目。

5.2.2. H.264

如果裝置實作項目支援 H.264 轉碼器，則：

  • [C-1-1] MUST support Baseline Profile Level 3. 不過，ASO (任意切片排序)、FMO (彈性巨集區塊排序) 和 RS (冗餘切片) 支援為選用功能。此外，為維持與其他 Android 裝置的相容性，建議編碼器不要將 ASO、FMO 和 RS 用於基準設定檔。
  • [C-1-2] 必須支援下表中的 SD (標準畫質) 影片編碼設定檔。
  • 應支援 Main 設定檔等級 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 檔案。
  • SHOULD provide a hardware VP8 codec that meets the WebM project RTC hardware coding requirements, to ensure acceptable quality of web video streaming and video-conference services.

如果裝置實作項目透過媒體 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 聲稱支援設定檔 2 或設定檔 3：

  • 支援 12 位元格式為選用功能。

5.2.5. H.265

如果裝置實作項目支援 H.265 轉碼器，則：

  • [C-1-1] 必須支援主設定檔層級 3，解析度最高可達 512 x 512。
  • [C-SR-1] 如果有硬體編碼器，強烈建議支援 720 x 480 SD 設定檔和 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.2.6. AV1

如果裝置實作項目支援 AV1 編碼器，則：

  • [C-1-1] 必須支援 Main Profile，包括 8 位元和 10 位元內容。

  • [C-1-2] 必須發布成效資料，也就是透過 getSupportedFrameRatesFor() 或 getSupportedPerformancePoints() API，針對下表支援的解析度回報成效資料。

  • [C-1-3] 必須接受 HDR 中繼資料，並輸出至位元串流

如果 AV1 編碼器採用硬體加速，則：

  • [C-2-1] 必須支援下表中的 HD1080p 編碼設定檔：
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
視訊位元率 5 Mbps 8 Mbps 16 Mbps 50 Mbps

5.3. 影片解碼

Android 17 中變更了需求條件的開始時間

如果裝置實作項目支援 VP8、VP9、H.264、H.265 或 AV1 轉碼器，則：

  • [C-1-1] 必須透過標準 Android API，在同一串流中即時支援所有 VP8、VP9、H.264、H.265 和 AV1 轉碼器的動態影片解析度和影格率切換功能，且最高可達裝置上各轉碼器支援的最大解析度。

變更要求結束 (5.3 > C-1-1)

5.3.1. MPEG-2

如果裝置實作支援 MPEG-2 解碼器，則：

  • [C-1-1] 必須支援主要設定檔高階層。

5.3.2. H.263

如果裝置實作項目支援 H.263 解碼器，則：

  • [C-1-1] 必須支援基準設定檔第 30 級 (CIF、QCIF 和 SQCIF 解析度 @ 30 fps 384 kbps) 和第 45 級 (QCIF 和 SQCIF 解析度 @ 30 fps 128 kbps)。

5.3.3. MPEG-4

如果裝置實作項目包含 MPEG-4 解碼器，則：

  • [C-1-1] 必須支援 Simple Profile Level 3。

5.3.4. H.264

如果裝置實作項目支援 H.264 解碼器，則：

  • [C-1-1] 必須支援 Main Profile Level 3.1 和 基準設定檔。支援 ASO (任意切片排序)、FMO (彈性巨集區塊排序) 和 RS (冗餘切片) 為選用功能。
  • [C-1-2] 必須能夠解碼下列表格列出的 SD (標準畫質) 設定檔影片，並以基準設定檔和 Main 設定檔 Level 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] 必須支援 Main 設定檔層級 3 Main 層級和 SD 影片解碼設定檔，如下表所示。
  • 應支援下表所示的 HD 解碼設定檔。
  • [C-1-2] 如有硬體解碼器，則必須支援下表所示的 HD 解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度大於或等於影片解析度，則：

  • [C-2-1] 裝置實作項目必須支援至少一種 H.265 或 VP9 解碼，且支援 720、1080 和 UHD 設定檔。
SD (畫質不佳) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p UHD
影片解析度 352 x 288 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片影格率 30 fps 30 fps 30 fps 30/60 FPS (60 FPS電視必須支援 H.265 硬體解碼) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

  • [C-3-1] 裝置實作項目「必須」接受應用程式提供的必要 HDR 中繼資料，並支援從位元串流和/或容器中擷取及輸出必要 HDR 中繼資料。
  • [C-3-2] 裝置實作項目必須在裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上正確顯示 HDR 內容。

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] 裝置實作項目必須支援至少一種 VP9 或 H.265 解碼，且支援 720、1080 和 UHD 設定檔。
SD (畫質不佳) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p UHD
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片影格率 30 fps 30 fps 30 fps 30 fps (支援 VP9 硬體解碼的電視為 60 fps) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置實作項目聲稱支援 VP9Profile2 或 VP9Profile3，請透過 'CodecProfileLevel' 媒體 API 執行下列操作：

  • 支援 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) 上正確顯示 HDR 內容。

5.3.8. Dolby Vision

如果裝置實作項目透過 HDR_TYPE_DOLBY_VISION 宣告支援 Dolby Vision 解碼器，則：

  • [C-1-1] 必須提供支援 Dolby Vision 的擷取器。

  • [C-1-2] 必須在裝置螢幕或透過標準視訊輸出埠 (例如 HDMI) 連接的外接螢幕上，正確顯示 Dolby Vision 內容。

  • [C-1-3] MUST set the track ID of backward-compatible base-layer(s) (if present) to be the same as the combined Dolby Vision layer's track ID.

5.3.9. AV1

如果裝置實作項目支援 AV1 轉碼器，並提供給第三方應用程式，則：

  • [C-1-1] 必須支援 Main Profile，包括 8 位元和 10 位元內容。

如果裝置實作項目支援 AV1 編碼器和硬體加速解碼器，則：

  • [C-2-1] 當 Display.getSupportedModes() 方法回報的高度等於或大於 720p 時，裝置必須能夠解碼至少 HD 720p 影片解碼設定檔 (如下表所示)。
  • [C-2-2] 當 Display.getSupportedModes() 方法回報的高度等於或大於 1080p 時，裝置「必須」能夠解碼至少 HD 1080p 影片解碼設定檔 (如下表所示)。
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
視訊位元率 5 Mbps 8 Mbps 16 Mbps 50 Mbps

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

  • [C-3-1] MUST support extracting and outputting HDR metadata from the bitstream and/or container.

  • [C-3-2] 必須在裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上正確顯示 HDR 內容。

5.4. 音訊錄製

雖然自 Android 4.3 起，本節列出的一些規定為 SHOULD，但日後版本的相容性定義預計會將這些規定改為 MUST。強烈建議現有和新的 Android 裝置符合這些「應」列出的需求，否則升級至未來版本時，將無法達到 Android 相容性。

5.4.1. 原始音訊擷取和麥克風資訊

如果裝置實作項目宣告 android.hardware.microphone，則：

  • [C-1-1] 必須允許擷取任何成功開啟的 AudioRecord 或 AAudio 輸入串流原始音訊內容。至少須支援下列特徵：

  • 應允許擷取具有下列特徵的原始音訊內容：

    • 格式：線性 PCM、16 位元和 24 位元
    • 取樣率：8000、11025、16000、22050、24000、32000、44100、48000 Hz
    • 聲道：聲道數量與裝置上的麥克風數量相同

  • [C-1-2] MUST capture at above sample rates without up-sampling.

  • [C-1-3] 如果以降低取樣率擷取上述取樣率，則必須加入適當的抗鋸齒濾波器。

  • 應允許以 AM 廣播和 DVD 品質擷取原始音訊內容，也就是具備下列特徵：

    • 格式：線性 PCM，16 位元
    • 取樣率：22050、48000 Hz
    • 聲道：立體聲

  • [C-1-4] MUST honor the MicrophoneInfo API and properly fill in information for the available microphones on device accessible to the third-party applications via the AudioManager.getMicrophones() API, for active AudioRecord using MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, or VOICE_PERFORMANCE. 如果裝置實作項目允許 AM 廣播和 DVD 品質的原始音訊內容擷取，則：

  • [C-2-1] MUST capture without up-sampling at any ratio higher than 16000:22050 or 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] 強烈建議在低頻範圍內顯示振幅位準：具體來說，與用於錄製語音辨識音訊來源的每個麥克風的中頻範圍相比，30 Hz 至 100 Hz 的範圍應為 ±20 dB。

  • [C-SR-2] 強烈建議在高頻範圍內呈現振幅位準：具體來說，與用於錄製語音辨識音訊來源的每個麥克風的中頻範圍相比，4000 Hz 至 22 KHz 的振幅位準應為 ±30 dB。

  • 應設定音訊輸入靈敏度，使以 90 dB 音壓級 (SPL) 播放的 1000 Hz 正弦波音調來源 (在麥克風旁測量) 產生 RMS 2500 的理想回應，範圍為 1770 到 3530 (或 -22.35 db ±3dB Full Scale，適用於浮點/雙精度樣本)，用於錄製語音辨識音訊來源的每個麥克風皆適用。

  • 應記錄語音辨識音訊串流，使 PCM 振幅位準在麥克風的 90 dB SPL 範圍內，至少從 -18 dB 到 +12 dB，線性追蹤輸入 SPL 變化。

  • 應錄製語音辨識音訊串流，在麥克風的 90 dB SPL 輸入音量下，1 kHz 的總諧波失真 (THD) 應小於 1%。

如果裝置實作項目宣告採用專為語音辨識調整的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，則：

  • SHOULD 實作針對語音通訊調整的聲學回音消除器 (AEC) 技術，並在透過 AudioSource.VOICE_COMMUNICATION 擷取時，套用至擷取路徑。

Android 17 中變更了需求條件的開始時間

如果裝置實作項目提供聲學回音消除器，且在選取 AudioSource.VOICE_COMMUNICATION 時插入擷取音訊路徑，則：

  • [C-1-2] 必須透過 AcousticEchoCanceler API 方法 AcousticEchoCanceler.getEnabled()，反映音訊路徑上 AEC 的啟用狀態，且啟用時必須傳回 true，停用時則傳回 false。

變更後的要求 (5.4.4 > C-1-1 至 C-SR-3)

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.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] 必須支援 EFFECT_TYPE_DYNAMICS_PROCESSING 實作，且可透過 AudioEffect 子類別 DynamicsProcessing 控制。

  • [C-1-4] MUST support audio effects with floating-point input and output, when the effect results are returned to the framework audio pipeline. 這指的是典型的插入或輔助效果，例如等化器。如果架構音訊管道無法看到效果結果 (例如後製或卸載效果)，強烈建議採用同等行為。

  • [C-1-5] MUST make sure that audio effects support multiple channels up to the mixer channel count also known as FCC_LIMIT, when the effect results are returned to the framework audio pipeline. 這類效果是指一般的插入或輔助效果，但不包括會改變聲道數的特殊效果，例如下混、上混或空間化效果。如果架構音訊管道無法顯示效果 (例如後續處理或卸載效果)，建議採用同等行為。

  • 應支援可透過 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. 音訊輸出音量

車輛裝置實作：

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

5.5.4. 音訊卸載

如果裝置實作項目支援音訊卸載播放，則：

  • [C-SR-1] 強烈建議使用 AudioTrack 無間隙 API 和 MediaPlayer 的媒體容器，在兩個格式相同的片段之間，修剪播放的無間隙音訊內容。

  • [C-SR-2] 強烈建議為 AAC、MP3、OPUS 和 PCM 格式實作卸載播放功能。

Android 17 新增的規定

如果裝置實作項目宣告支援 MMAP PCM 卸載 (由含有 AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD 和 AUDIO_OUTPUT_FLAG_MMAP_NOIRQ 的標記的混合通訊埠宣告)，則：

  • [C-1-1] 必須支援至少 AUDIO_FORMAT_PCM_16_BIT， 立體聲和單聲道皆為 44.1 kHz 和 48 kHz。

  • [C-1-2] 緩衝區空間必須能夠儲存至少 5 秒的音訊，且音訊格式為 48 kHz 立體聲 PCM，每個樣本 16 位元。

新增要求結束 (5.5.4 > C-1-1 和 C-1-2)

5.5.5. 播放參數

Android 17 新增的規定

如果裝置實作項目支援 PlaybackParams API，播放參數：

  • [C-1-1] MUST support speeds between 0.5 and 2.0 with a pitch of 1.0.

新增要求結束 (5.5.5 播放參數)

5.6. 音訊延遲

音訊延遲是指音訊訊號通過系統時的時間延遲。許多類型的應用程式都依賴低延遲，才能實現即時音效。

本節使用下列定義：

  • 輸出延遲。應用程式寫入 PCM 編碼資料影格的時間，與對應聲音透過裝置端的感應器呈現給環境，或是訊號透過通訊埠離開裝置並可從外部觀察到的時間間隔。

  • 冷輸出延遲。從啟動輸出串流到第一個影格的呈現時間 (根據時間戳記) 之間的間隔。在此之前，音訊輸出系統處於閒置狀態並已關機。

  • 連續輸出延遲時間。裝置播放音訊後，後續影格的輸出延遲。

  • 輸入延遲。環境透過裝置端的轉換器或訊號進入裝置的通訊埠，將聲音傳送至裝置，應用程式讀取相應的 PCM 編碼資料影格之間的時間間隔。

  • 遺失輸入內容。輸入信號的初始部分，無法使用或無法取得。

  • 冷輸入延遲。音訊輸入系統閒置並關機後，從開始串流到收到第一個有效影格之間的時間。

  • 持續輸入延遲。裝置擷取音訊時，後續影格的輸入延遲。

  • 連續往返延遲時間。連續輸入延遲時間、連續輸出延遲時間和一個緩衝區週期的總和。緩衝期可讓應用程式處理訊號，並減少輸入和輸出串流之間的相位差。

  • OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 集。

  • AAudio 原生音訊 API。Android NDK 中的 AAudio API 集。

  • 時間戳記。這組資料包含串流中的相對影格位置，以及該影格進入或離開相關端點音訊處理管道的預估時間。另請參閱「AudioTimestamp」。

  • glitch。音訊訊號暫時中斷或樣本值不正確，通常是由輸出緩衝區下溢、輸入緩衝區溢位，或任何其他數位或類比噪音來源所導致。緩衝區下溢

  • 平均絕對偏差 (MAD)。一組值與平均值偏差絕對值的平均值。

  • 輕觸到音調延遲 (TTL) 是指從輕觸螢幕到透過喇叭聽到因輕觸而產生的音調之間經過的時間，由 CTS Verifier 測量。這是使用 AAudio 原生音訊 API 進行 5 次輸出測量的平均值。

  • 往返延遲 (RTL) 是指 CTS Verifier 測得的平均連續延遲，測量方式是使用 AAudio 原生音訊 API，透過迴路路徑將輸出內容回饋至輸入內容，並進行 5 次測量。

    迴路路徑如下：

    • 喇叭/麥克風：內建喇叭到內建麥克風。
    • 類比：3.5 公釐類比插孔和迴路轉接頭。
    • USB：USB 轉 3.5 公釐轉接頭和迴路轉接頭，或是 USB 音訊介面和迴路傳輸線。

  • FEATURE_AUDIO_LOW_LATENCY。 宣告 android.hardware.audio.low_latency 功能。

  • FEATURE_AUDIO_PRO。 宣告 android.hardware.audio.pro 功能。

  • MPC。媒體效能類別。

  • 頭部追蹤延遲。從慣性測量單元 (IMU) 擷取頭部動作，到耳機感應器偵測到此動作造成的聲音變化，所需的時間。

Android 17 新增的規定

裝置實作方式：

  • [C-0-1] MUST ensure that when an application calls android.media.AudioManager.setCommunicationDevice() with a supported device (such as wired headsets, built-in speakers or ear-pieces, or USB headsets), the android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() callback is invoked with that audio device within 1500 ms of the setCommunicationDevice() call returning true.

新增規定結束 (5.6 > C-0-1)

如果裝置實作項目聲明 android.hardware.audio.output，則必須符合或超過下列需求：

  • [C-1-1] Android 15 已移除這項規定。

  • [C-1-2] 冷輸出延遲時間不超過 500 毫秒。

  • [C-1-3] 使用 AAudioStreamBuilder_openStream() 開啟輸出串流的時間不得超過 1000 毫秒。

  • [C-1-4] 根據 AAudioStream_getTimestamp 傳回的輸入和輸出時間戳記計算出的往返延遲時間，必須在喇叭、有線耳機和無線耳機的測量往返延遲時間 200 毫秒內，適用於 AAUDIO_PERFORMANCE_MODE_NONE 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY。

  • [C-SR-1] Android 15 已移除這項規定。

  • [C-SR-2] Android 15 已移除這項規定。

  • [C-SR-4] Android 15 已移除這項規定。

  • [C-SR-5] Android 15 已移除這項規定。

  • [C-SR-6] Android 15 已移除這項規定。

  • [C-SR-7] Android 15 已移除這項規定。

  • [C-2-1] Android 15 已移除這項規定。

如果裝置實作項目包含 android.hardware.microphone，就「必須」符合下列輸入音訊規定：

  • [C-3-1] Android 15 已移除這項規定。

  • [C-3-2] 冷 輸入延遲時間不得超過 500 毫秒。

  • [C-3-3] 使用 AAudioStreamBuilder_openStream() 開啟輸入串流的時間必須少於 1000 毫秒。

  • [C-SR-8] Android 15 已移除這項規定。

  • [C-SR-11] Android 15 已移除這項規定。

  • [C-SR-12] Android 15 已移除這項規定。

下表定義了手持裝置實作的 RTL 要求，如 2.2.1 所定義，宣告 android.hardware.audio.output 和 android.hardware.microphone。

Android 17 中變更了需求條件的開始時間
裝置和聲明 RTL (毫秒) MAD (毫秒) 迴路路徑
手持式 200 25 喇叭/麥克風、類比 3.5 公釐 (如支援)、USB (如支援)
MPC_C (17) 以上版本 65 10 所有支援的資料路徑
>= MPC_T (13) through MPC_B (16) 80 15 至少一個路徑
FEATURE_AUDIO_LOW_LATENCY 50 10 至少一個路徑
FEATURE_AUDIO_PRO 25 5 至少一個路徑
FEATURE_AUDIO_PRO 20 5 類比 (如支援)
FEATURE_AUDIO_PRO 25 5 USB (如果不支援類比)
變更需求結束 (5.6 迴路延遲時間表)

下表定義手持裝置實作的 TTL 要求，如 2.2.1 所定義，宣告 android.hardware.audio.output 和 android.hardware.microphone。

Android 17 中變更了需求條件的開始時間

裝置和聲明 存留時間 (毫秒)
手持式 250
MPC_C (17) 以上版本 65
>= MPC_T (13) through MPC_B (16) 80
MPC_S (12) 100
FEATURE_AUDIO_PRO 80

變更後的要求 (5.6 存留時間要求表)

如果裝置實作項目支援 spatial audio 頭部追蹤，並宣告 PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY 標記，則：

  • [C-4-1] 頭部追蹤到音訊更新的延遲時間不得超過 300 毫秒。

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

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 		詳情請參閱第 5.1.8 節。
H263-2000 RFC 4629 詳情請參閱第 5.1.8 節。
AMR RFC 4867 詳情請參閱第 5.1.3 節 ，瞭解 AMR-NB
AMR-WB RFC 4867 詳情請參閱第 5.1.3 節 瞭解 AMR-WB
MP4V-ES RFC 6416 詳情請參閱第 5.1.8 節。
mpeg4-generic RFC 3640 如要進一步瞭解 AAC 和其變體，請參閱第 5.1.3 節。
MP2T RFC 2250 詳情請參閱 HTTP Live Streaming 下方的「MPEG-2 傳輸串流」

5.8. 安全媒體

如果裝置實作項目支援安全視訊輸出，且能夠支援安全途徑，則：

  • [C-1-1] 必須聲明支援 Display.FLAG_SECURE。

如果裝置實作項目聲明支援 Display.FLAG_SECURE 和無線螢幕分享通訊協定，則：

  • [C-2-1] MUST secure the link with a cryptographically strong mechanism such as HDCP 2.x or higher for the displays connected through wireless protocols such as Miracast.

如果裝置實作項目聲明支援 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 連線，這類傳輸方式包括：

  • [C-1-2] MUST support the inter-app MIDI software transport (virtual MIDI devices)

  • [C-1-3] 必須包含 libamidi.so (原生 MIDI 支援)

  • 應支援透過 USB 周邊裝置模式傳輸 MIDI，請參閱第 7.7 節

5.10. 專業音訊

如果裝置實作項目透過 android.content.pm.PackageManager 類別回報支援 android.hardware.audio.pro 功能，則：

  • [C-1-1] 必須回報對功能 android.hardware.audio.low_latency 的支援。

  • [C-1-2] 必須符合 FEATURE_AUDIO_PRO 的延遲時間要求，如第 5.6 節「音訊延遲」所述。

  • [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 毫秒以下的冷輸入延遲。

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

如果裝置實作項目省略 4 導體 3.5 公釐音訊插孔，並包含支援 USB 主機模式的 USB 連接埠，則：

  • [C-3-1] 必須實作 USB 音訊類別。

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 範圍內，必須達到 ±10 dB。

  • [C-1-3] 必須在低頻範圍內呈現振幅位準，具體來說，與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比，5 Hz 至 100 Hz 的範圍內必須為 ±20 dB。

  • [C-1-4] 必須在高頻範圍內呈現振幅位準：具體來說，與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比，7000 Hz 至 22 KHz 的範圍必須為 ±30 dB。

  • [C-1-5] 必須設定音訊輸入靈敏度，讓以 94 dB 音壓級 (SPL) 播放的 1000 Hz 正弦波音調來源，針對用於錄製未經處理音訊來源的每個麥克風，產生 RMS 為 520 的 16 位元樣本 (或浮點/雙精度樣本的 -36 dB 滿刻度) 回應。

  • [C-1-6] 用於錄製未經處理音訊來源的每個麥克風，訊噪比 (SNR) 必須達到 60 dB 以上。(而訊號雜訊比的測量方式，是 94 dB SPL 與等效 SPL 自我噪音 (A 加權) 之間的差異)。

  • [C-1-7] 針對用於錄製未經處理音訊來源的每個麥克風，在 90 dB SPL 輸入音量位準下，1 kHz 的總諧波失真 (THD) 必須小於 1%。

  • [C-1-8] 路徑中不得有任何其他訊號處理作業 (例如自動增益控制、高通濾波器或消除回音)，只能有將音量帶入所需範圍的音量乘數。簡單來說：

    • [C-1-9] 如果架構中因任何原因出現訊號處理程序，則必須停用該程序，並有效將訊號路徑的延遲或額外延遲時間降至零。
    • [C-1-10] 雖然路徑上可以有位準乘數，但不得在訊號路徑中造成延遲。

所有 SPL 測量值都是在受測麥克風旁直接測得。 如果是多個麥克風設定，這些規定適用於每個麥克風。

如果裝置實作項目宣告 android.hardware.microphone，但未支援未經處理的音訊來源，則：

  • [C-2-1] MUST return null for the AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API method, to properly indicate the lack of support.

  • [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] GPU 必須能夠取樣 P010 輸出緩衝區 (以 GPU_SAMPLING 用量分配時)。這可讓應用程式進行 GPU 合成和自訂色調對應。

如果影片解碼器宣傳支援 COLOR_Format32bitABGR2101010，則：

  • [C-2-1] 必須支援輸出介面和 CPU 可讀取 (ByteBuffer 輸出) 的 RGBA_1010102 格式。

如果影片編碼器宣稱支援 COLOR_FormatYUVP010，則：

  • [C-3-1] 必須支援 P010 格式，用於輸入 Surface 和 CPU 可寫入的 (ImageWriter、MediaImage、ByteBuffer) 輸入。

如果影片編碼器宣稱支援 COLOR_Format32bitABGR2101010，則：

  • [C-4-1] 必須支援輸入介面和 CPU 可寫入 (ImageWriter、ByteBuffer) 輸入的 RGBA_1010102 格式。注意：編碼器「不需要」在各種轉移曲線之間轉換。

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 編輯的視訊編碼器，則：

  • 如果沒有 HDR 中繼資料，系統「應」盡量縮短產生中繼資料的延遲時間，並「應」妥善處理部分影格有中繼資料，部分影格沒有中繼資料的情況。這項中繼資料應精確無誤 (例如，代表影格的實際峰值亮度和直方圖)。

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

  • [C-7-1] 必須支援至少一個 HDR 設定檔。

  • [C-7-2] MUST support FEATURE_HdrEditing for all HDR profiles advertised by that codec. In other words, they MUST support generating HDR metadata when not present for all HDR profiles supported that use HDR metadata.

  • [C-7-3] 必須支援下列影片編碼器輸入格式，完整保留 HDR 解碼訊號：

    • RGBA_1010102 (已在目標轉移曲線中) 的輸入介面和 ByteBuffer，且必須宣傳對COLOR_Format32bitABGR2101010 的支援。

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

  • [C-7-4] 必須宣傳支援 EXT_YUV_target OpenGL 擴充功能。

HDR 螢幕需求條件

如果裝置實作項目收到以 ADATASPACE_TRANSFER_HLG 編碼的緩衝區內容，且該內容透過 SurfaceControl.Transaction#setBuffer 傳送至螢幕，則：

  • [C-8-1] 必須遵循 BT. 2408-7 中的圖像白色建議，且顯示的內容最多只能是 SDR 內容的 4.926 倍。

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

6.1. 開發人員工具

裝置實作方式：

  • [C-0-1] 必須支援 Android SDK 提供的 Android 開發人員工具。

  • Android Debug Bridge (adb)

  • [C-0-2] 必須支援 Android SDK 中記載的 adb，以及 AOSP 中提供的殼層指令，供應用程式開發人員使用，包括 dumpsys、cmd stats 和 Simpleperf。

  • [C-0-11] MUST support the shell command cmd testharness. 如果裝置實作項目是從較舊的 Android 版本升級，且沒有持續性資料區塊，則可能可免除 C-0-11 規定。

  • [C-0-3] 不得變更透過 dumpsys 指令記錄的裝置系統事件 (batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats) 格式或內容。

  • [C-0-10] 必須完整記錄下列事件，並透過 cmd stats shell 指令和 StatsManager System API 類別存取及使用這些事件。

    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • InputDeviceUsageReported
    • JobStateChanged
    • KeyboardConfigured
    • KeyboardSystemsEventReported
    • PluggedStateChanged
    • PressureStallInformation
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • TouchpadUsage
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged

  • [C-0-4] 裝置端的 ADB Daemon 預設必須處於非使用中狀態，且必須提供使用者可存取的機制來開啟 Android Debug Bridge。

  • [C-0-5] 必須支援安全 ADB。Android 支援安全 adb。安全 adb 可讓已知經過驗證的主機使用 adb。

  • [C-0-6] MUST provide a mechanism allowing adb to be connected from a host machine. 具體內容如下：

如果沒有 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 或乙太網路連線至主體機器，且至少包含一個攝影機，則：

  • [C-5-1] 必須有 AdbManager#isAdbWifiQrSupported() 方法， 傳回 true。

  • Dalvik 偵錯監視服務 (ddms)

    • [C-0-7] MUST support all ddms features as documented in the Android SDK. 由於 ddms 使用 adb，因此預設應停用 ddms 支援，但只要使用者已如上啟用 Android Debug Bridge，就必須支援 ddms。

  • SysTrace

    • [C-0-9] MUST support the systrace tool as documented in the Android SDK. Systrace 預設必須處於非啟用狀態，且必須提供使用者可存取的機制來啟用 Systrace。

  • Perfetto

    • [C-SR-1] STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.

    • [C-SR-2] 強烈建議 perfetto 二進位檔接受符合perfetto 說明文件中定義結構定義的 protobuf 設定做為輸入內容。

    • [C-SR-3] 強烈建議 perfetto 二進位檔以 protobuf 追蹤記錄的形式輸出，且該追蹤記錄應符合perfetto 說明文件中定義的結構定義。

    • [C-SR-4] 建議您透過 perfetto 二進位檔提供至少perfetto 說明文件中說明的資料來源。

  • 記憶體不足終止工具

    • [C-0-12] MUST write a LMK_KILL_OCCURRED_FIELD_NUMBER Atom to the statsd log when an app is terminated by the Low Memory Killer.

  • 測試控管工具模式

    如果裝置實作項目支援 cmd testharness 殼層指令並執行 cmd testharness enable，則：

    • [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()

    • [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 方法。

Android 17 新增的規定

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.gpu_frequency 都設為 true，則：

  • [C-6-1] 必須按照 power.proto 中定義的 power/gpu_frequency 格式，回報 GPU 頻率追蹤點。

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.gpu_counters 都設為 true，則：

  • [C-7-1] MUST provide a Perfetto data producer for a data source named gpu.counters, queryable using: perfetto --query.

  • [C-7-2] 必須按照 GPU 計數器追蹤封包 Proto 規定，回報 GPU 計數器說明。

  • [C-7-3] 必須根據 GPU 計數器追蹤封包 Proto，回報裝置 GPU 計數器的相容值。

  • [C-7-4] MUST record the text descriptions for all enabled GPU Counters with no timestamp to perfetto trace.

  • [C-7-6] 必須提供非空白的預設 GPU 效能計數器集，用於剖析，如 GpuCounterSpec#select_by_default 所述。

    • 必須能夠同時啟用所有這些預設計數器。
    • 啟用後，這些追蹤點都「必須」將值發送至 Perfetto。

  • [C-7-7] 必須使用 GpuCounterSpec#select_by_default 反映至少一個預設選取計數器的 GPU 使用率。

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.gpu_counters.period 都設為 true，則：

  • [C-8-1] MUST 遵守 GPU 計數器取樣率的 counter_period_ns。支援的取樣率必須為 1 毫秒或更快。

  • [C-SR-1] 強烈建議支援 0.2 毫秒或更快的取樣率。

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.gpu_counters.groups 設為 true，則：

  • [C-9-1] 必須在下列每個 GPU 計數器群組中至少有一個計數器，如 GpuCounterSpec 所指定：COMPUTE、FRAGMENTS、MEMORY、PRIMITIVES 和 VERTICES。

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.gpu_counters.groups 都設為 true，且裝置支援光線追蹤，則：

  • [C-10-1] RAY_TRACING 群組中必須有計數器。

    如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.gpu_counters.zeroes_optimization 都設為 true，則：

  • [C-11-1] 在同一個 Perfetto 追蹤工作階段中，如果先前或後續回報的值為非零值，GPU 計數器「必須」只回報零值。

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.render_stages 都設為 true，則：

  • [C-12-1] MUST provide a Perfetto data producer for a data source named gpu.renderstages, queryable using perfetto --query.

  • [C-12-2] 必須按照 GPU 算繪階段事件 Proto，回報 GPU 算繪階段的相容值。

如果裝置實作項目將系統屬性 graphics.gpu.profiler.support 和 graphics.gpu.profiler.support.render_stages.queue_submit 都設為 true，則：

  • [C-13-1] 針對每個 Vulkan 佇列提交呼叫，Vulkan 驅動程式「必須」根據 Vulkan API 事件訊息規格發出 Perfetto 追蹤事件。
    • 這項事件「必須」包含單調遞增的專屬 submission_id，且該 submission_id 與對應 GPU 算繪階段事件中的 submission_id 相符。

新增規定結束 (6.1 > C-6-1 至 C-13-1)

6.2. 開發人員選項

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

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

  • [C-0-1] MUST honor the android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application development-related settings. 上游 Android 實作會預設隱藏「開發人員選項」選單，使用者只要在「設定」>「關於裝置」>「版本號碼」選單項目上按七 (7) 次，即可啟動「開發人員選項」。
  • [C-0-2] 預設必須隱藏「開發人員選項」。
  • [C-0-3] 必須提供明確機制，不得偏袒任何第三方應用程式，以啟用「開發人員選項」。必須提供公開文件或網站，說明如何啟用開發人員選項。這份文件或網站「必須」可從 Android SDK 文件連結。
  • 如果啟用「開發人員選項」且使用者安全堪慮，應用程式「應該」持續向使用者顯示視覺通知。
  • MAY 會暫時限制「開發人員選項」選單的存取權，方法是隱藏或停用選單，避免使用者在安全堪慮的情況下分心。

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] 如果 SDK 說明文件不允許空值，API 方法就「必須」傳回類別的無運算實作項目。
  • [C-0-6] API 方法不得擲回 SDK 文件未記載的例外狀況。
  • [C-0-7] 裝置實作項目必須透過 android.content.pm.PackageManager 類別的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法，針對相同版本指紋，持續回報準確的硬體設定資訊。

這些規定適用的典型情境是電話 API：即使在非手機裝置上，這些 API 也必須實作為合理的無作業。

7.1. 顯示和圖形

Android 內建多項功能，可根據裝置自動調整應用程式資產和 UI 版面配置，確保第三方應用程式能在各種硬體螢幕和設定上順利執行。Android 相容螢幕是指實作「Android 開發人員 - 螢幕相容性總覽」一節 (7.1) 和其子節，以及本 CDD 第 2 節中記錄的任何其他裝置類型專屬行為的所有行為和 API 的螢幕。

裝置實作方式：

  • [C-0-1] 預設情況下，第三方應用程式只能在與 Android 相容的螢幕上顯示。

本節要求中提及的單位定義如下：

  • 實體對角尺寸。螢幕發光部分兩個對角之間的距離 (以英吋為單位)。

  • 密度。1 英寸的水平或垂直線性跨度所涵蓋的像素數，以每英寸像素數 (ppi 或 dpi) 表示。如果列出每英寸像素數值和每英寸點數值，則水平和垂直每英寸點數值都必須落在列出的範圍內。

  • 顯示比例。螢幕長邊與短邊的像素比例。舉例來說，480 x 854 像素的螢幕比例為 854 / 480 = 1.779，約為「16:9」。

  • 密度獨立像素 (dp)。 虛擬像素單位，以 160 的螢幕密度為基準。對於某些密度 d 和像素數量 p，密度獨立像素數量 dp 的計算方式如下：dp = (160 / d) * p。

7.1.1. 螢幕設定

7.1.1.1. 螢幕大小和形狀

Android UI 架構支援各種不同的邏輯螢幕版面配置大小，應用程式可透過 Configuration.screenLayout 和 SCREENLAYOUT_SIZE_MASK 查詢目前設定的螢幕版面配置大小。Configuration.smallestScreenWidthDp

裝置實作方式：

  • [C-0-1] MUST report the correct layout size for the Configuration.screenLayout as defined in the Android SDK documentation. 具體來說，裝置實作內容必須回報正確的邏輯密度獨立像素 (dp) 螢幕尺寸，如下所示：

    • 如果裝置將 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 以外的任何值，且回報的 Configuration.screenLayout small 大小至少為 426 dp x 320 dp，則必須符合這項規定。

    • 回報 normal 大小的裝置Configuration.screenLayout， 必須至少為 480 dp x 320 dp。

    • 回報 Configuration.screenLayout 的 large 大小的裝置，必須至少為 640 dp x 480 dp。

    • 回報 xlarge 大小的裝置Configuration.screenLayout，必須至少為 960 dp x 720 dp。

  • [C-0-2] 必須正確遵守應用程式透過 AndroidManifest.xml 中的 <supports-screens> 屬性聲明的螢幕尺寸支援，如 Android SDK 文件所述。

  • 可能具有圓角設計的 Android 相容螢幕。

如果裝置實作項目支援可進行 UI_MODE_TYPE_NORMAL 大小設定的螢幕，並使用圓角實體螢幕算繪這些螢幕，則：

  • [C-1-1] MUST ensure that at least one of the following requirements is met for each such display:

    • 圓角的半徑小於或等於 38 dp。

    • 當 18 dp x 18 dp 的方塊錨定在邏輯螢幕的每個角落時，每個方塊至少有一個像素會顯示在畫面上。

  • 「應」包含使用者可切換至矩形邊角顯示模式的功能提示。

如果裝置實作項目只能進行 NO_KEYS 鍵盤設定，且打算回報支援 UI_MODE_TYPE_NORMAL UI 模式設定，則：

  • [C-4-1] 必須具備至少 596 dp x 384 dp 的版面配置大小 (不含任何螢幕凹口)。

如要瞭解如何正確導入 Sidecar 或擴充功能 API，請參閱 Window Manager Jetpack 的公開說明文件。

  • [C-4-1] Android 15 已移除這項規定。
7.1.1.2. 螢幕顯示比例

Android 14 已移除這個部分。

7.1.1.3. 螢幕密度

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

裝置實作：

  • [C-0-1] 必須透過 DENSITY_DEVICE_STABLE API 回報DisplayMetrics上列的其中一個 Android 架構密度，且每個實體螢幕的值必須是靜態值。不過，裝置「可能」會根據使用者在初始啟動後所做的顯示設定變更 (例如顯示大小)，回報不同的 DisplayMetrics.density。

  • 應定義與螢幕實際密度最接近的標準 Android 架構密度，或對應至手持裝置相同等效視角測量的數值。

如果裝置實作項目提供變更裝置顯示大小的機制，則：

  • [C-1-1] 不得將螢幕縮放超過 1.5 倍DENSITY_DEVICE_STABLE，或產生小於 320 dp 的有效最小螢幕尺寸 (相當於資源限定詞 sw320dp)，以先到者為準。

  • [C-1-2] 螢幕縮放比例不得小於 0.85 倍的DENSITY_DEVICE_STABLE。

  • 為確保良好的可用性和一致的字型大小，建議提供下列原生顯示選項的縮放比例 (同時遵守上述限制)：

    • 小：0.85 倍
    • 預設值：1 倍 (原生顯示比例)
    • 大：1.15 倍
    • 放大：1.3 倍
    • 最大 1.45 倍

7.1.2. 顯示指標

如果裝置實作項目包含與 Android 相容的螢幕，或與 Android 相容的螢幕畫面視訊輸出，則：

如果裝置實作項目未內建螢幕或視訊輸出功能，則：

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

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] Android 16 已移除這項規定。

  • [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] 必須支援所有對應的管理 API 和原生 API，以支援所識別的每個 OpenGL ES 版本。

如果裝置實作項目包含螢幕或視訊輸出，則：

  • [C-1-1] 必須支援 OpenGL ES 1.1、2.0、3.0 和 3.1，如 Android SDK 文件所載明。

  • [C-SR-1] Android 15 已移除這項規定。

  • 應支援 OpenGL ES 3.2。

OpenGL ES dEQP 測試會劃分成多個測試清單，每個清單都有相關聯的日期/版本號碼。這些檔案位於 Android 原始碼樹狀結構的 external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt 中。如果裝置支援 OpenGL ES，且自行回報的等級表示裝置可通過此等級和先前所有測試清單中的 dEQP 測試。

如果裝置實作項目支援任何 OpenGL ES 版本，則：

  • [C-2-1] 必須透過 OpenGL ES 受管理 API 和原生 API，回報實作的任何其他 OpenGL ES 擴充功能，反之，不得回報不支援的擴充功能字串。

  • [C-2-2] 必須支援 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、EGL_ANDROID_recordable 和 EGL_ANDROID_GLES_layers 擴充功能。

  • [C-2-3] 必須透過 android.software.opengles.deqp.level 功能標記，回報支援的 OpenGL ES dEQP 測試最高版本。

  • [C-2-4] 必須至少支援 132383489 版 (2020 年 3 月 1 日起)，如 android.software.opengles.deqp.level 功能旗標所回報。

  • [C-2-5] 必須通過測試清單中介於 132383489 版和 android.software.opengles.deqp.level 功能旗標指定版本之間的所有 OpenGL ES dEQP 測試，適用於每個支援的 OpenGL ES 版本。

  • [C-SR-2] 強烈建議支援 EGL_KHR_partial_update 和 OES_EGL_image_external 擴充功能。

  • 應透過 getString() 方法準確回報支援的任何紋理壓縮格式，這通常是供應商專屬格式。

  • 應支援 EGL_IMG_context_priority 和 EGL_EXT_protected_content 擴充功能。

如果裝置實作項目聲明支援 OpenGL ES 3.0、3.1 或 3.2，則：

  • [C-3-1] 除了 libGLESv2.so 程式庫中的 OpenGL ES 2.0 函式符號外，還必須匯出這些版本的對應函式符號。

  • [C-SR-3] 強烈建議支援 OES_EGL_image_external_essl3 擴充功能。

如果裝置實作項目支援 OpenGL ES 3.2，則：

  • [C-4-1] 必須完整支援 OpenGL ES Android 擴充套件。

如果裝置實作項目完全支援 OpenGL ES Android 擴充套件，則：

  • [C-5-1] 必須透過 android.hardware.opengles.aep 功能旗標識別支援。

如果裝置實作項目公開支援 EGL_KHR_mutable_render_buffer 擴充功能，則：

  • [C-6-1] 必須支援 EGL_ANDROID_front_buffer_auto_refresh 副檔名。
7.1.4.2. Vulkan

Android 支援 Vulkan，這是一種低負載的跨平台 API，可用於製作高品質 3D 圖像。

如果裝置實作項目支援 OpenGL ES 3.1，則：

  • [C-SR-1] 強烈建議加入 Vulkan 1.3 的支援。

  • [C-4-1] 不得支援 Vulkan 變體版本 (即 Vulkan 核心版本的變體部分必須為零)。

如果裝置實作項目包含螢幕或視訊輸出，則：

  • [C-SR-2] 強烈建議納入 Vulkan 1.3 的支援。

Vulkan dEQP 測試會劃分成多個測試清單，每個清單都有相關聯的日期/版本。這些檔案位於 Android 原始碼樹狀結構的 external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt 中。支援 Vulkan 的裝置會自行回報等級，表示裝置能通過這個等級和先前等級的所有 dEQP 測試清單。

如果裝置實作項目支援 Vulkan，則：

  • [C-1-1] 必須使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能旗標回報正確的整數值。

  • [C-1-2] 必須列舉至少一個 Vulkan 原生 API vkEnumeratePhysicalDevices() 的 VkPhysicalDevice。

  • [C-1-3] MUST fully implement the Vulkan 1.1 APIs for each enumerated VkPhysicalDevice.

  • [C-1-4] MUST enumerate layers, contained in native libraries named as libVkLayer*.so in the application package's native library directory, through the Vulkan native APIs vkEnumerateInstanceLayerProperties() and vkEnumerateDeviceLayerProperties().

Android 17 中變更了需求條件的開始時間

  • [C-1-5] 不得列舉應用程式套件以外的程式庫提供的層，或提供追蹤或攔截 Vulkan API 的其他方式，除非應用程式的 android:debuggable 屬性設為 true，或中繼資料 com.android.graphics.injectLayers.enable 設為 true ，但 OEM 和平台層除外 (請參閱「實作 Vulkan」說明文件)。

變更後的要求 (7.1.4.2 > C-1-5)

  • [C-1-6] MUST report all extension strings that they do support via the Vulkan native APIs , and conversely MUST NOT report extension strings that they do not correctly support.

Android 17 中變更了需求條件的開始時間

  • [C-1-7] 必須支援下列擴充功能：

    • VK_EXT_present_mode_fifo_latest_ready
    • VK_KHR_present_wait2
    • VK_KHR_android_surface
    • VK_KHR_incremental_present
    • VK_KHR_present_id
    • VK_KHR_present_id2
    • VK_KHR_surface
    • VK_KHR_swapchain

變更後的要求 (7.1.4.2 > C-1-7)

  • [C-1-8] 必須透過 android.software.vulkan.deqp.level 功能旗標，回報支援的 Vulkan dEQP 測試最高版本。

  • [C-1-9] 必須至少支援 android.software.vulkan.deqp.level 功能旗標回報的 132317953 版本 (2019 年 3 月 1 日起)。

  • [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 擴充功能的支援。

Android 17 中變更了需求條件的開始時間

  • [C-SR-3] 建議支援下列擴充功能：

    • VK_EXT_present_timing
    • VK_GOOGLE_display_timing
    • VK_KHR_driver_properties

變更後的需求 (7.1.4.2 > C-SR-3)

  • [C-1-12] 不得列舉對 VK_KHR_performance_query 擴充功能的支援。

  • [C-SR-4] Android Baseline 2022 設定檔中指定的規定「強烈建議」要符合。

  • [C-SR-5] 強烈建議支援 VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory 和 VK_EXT_global_priority。

  • [C-SR-6] 強烈建議搭配 HWUI 使用 SkiaVk。

如果裝置實作項目支援 Vulkan，則：

  • [C-SR-8] 強烈建議不要修改 Vulkan 載入器。

  • [C-1-14] 除非「KHR」、「GOOGLE」或「ANDROID」類型的 Vulkan 裝置擴充功能包含在 android.software.vulkan.deqp.level 功能旗標中，否則不得列舉這些擴充功能。

如果裝置實作項目不支援 Vulkan 1.0，則：

  • [C-2-1] 不得宣告任何 Vulkan 功能旗標 (例如 android.hardware.vulkan.level、android.hardware.vulkan.version)。

  • [C-2-2] 不得列舉 Vulkan 原生 API vkEnumeratePhysicalDevices() 的任何 VkPhysicalDevice。

Android 17 中變更了需求條件的開始時間

如果裝置實作項目支援 Vulkan 1.1，且宣告了這裡 或更高版本中說明的任何 Vulkan 功能旗標，則：

  • [C-3-1] MUST 支援 SYNC_FD 外部信號和控制代碼型別，以及 VK_ANDROID_external_memory_android_hardware_buffer 擴充功能。

  • [C-SR-7] 強烈建議您讓第三方應用程式使用 VK_KHR_external_fence_fd 擴充功能，並允許應用程式將圍欄酬載匯出至 POSIX 檔案描述元，以及從 POSIX 檔案描述元匯入圍欄酬載，詳情請參閱這篇文章。

變更後的要求 (7.1.4.2 > C-3-1 和 C-SR-7)

7.1.4.3. RenderScript

裝置實作方式：

7.1.4.4. 2D 圖形加速

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

裝置實作方式：

  • [C-0-1] 預設必須啟用硬體加速，且如果開發人員要求停用硬體加速 (方法是設定 android:hardwareAccelerated="false"，或直接透過 Android View API 停用硬體加速)，則必須停用硬體加速。

  • [C-0-2] MUST exhibit behavior consistent with the Android SDK documentation on hardware acceleration.

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 空間中，面積必須至少為 DCI-P3 的 90%。

  • [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 會指定「相容模式」，讓架構以「一般」螢幕大小 (寬度為 320 dp) 模式運作，以利舊版應用程式使用。這些應用程式是針對舊版 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. 輸入裝置

裝置實作方式：

7.2.1. 鍵盤

如果裝置實作項目支援第三方輸入法編輯器 (IME) 應用程式，則：

裝置實作方式：

7.2.2. 非觸控導覽

Android 支援 D-Pad、滾球和滾輪，做為非觸控導覽機制。

裝置實作方式：

如果裝置實作項目缺少非觸控導覽功能，則：

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

7.2.3. 瀏覽鍵

主畫面、最近使用的應用程式和返回功能通常是透過與專用實體按鈕或觸控螢幕特定部分的互動提供，對於 Android 導覽模式至關重要，因此裝置實作項目：

  • [C-0-1] MUST provide a user affordance to launch installed applications that have an activity with the <intent-filter> set with ACTION=MAIN and CATEGORY=LAUNCHER or CATEGORY=LEANBACK_LAUNCHER for Television device implementations. 「首頁」功能應做為這項使用者輔助功能的機制。
  • 應提供「最近」和「返回」功能的按鈕。

如果提供「首頁」、「最近」或「返回」功能，則：

  • [C-1-1] 只要可存取其中任一項目，就「必須」透過單一動作 (例如輕觸、按兩下或手勢) 存取。
  • [C-1-2] 必須清楚指出觸發各項功能的單一動作。例如在按鈕上印製可見的圖示、在螢幕的導覽列部分顯示軟體圖示，或是在開箱設定體驗期間，引導使用者逐步完成示範流程。

裝置實作方式：

  • [C-SR-1] 強烈建議不要為選單功能提供輸入機制，因為自 Android 4.0 起，選單功能已遭淘汰，改用動作列。

  • [C-SR-2] STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 「可取消」是指使用者在滑動未超過特定門檻時，可防止導覽功能執行 (例如返回主畫面、返回上一頁等)。

如果裝置實作提供「選單」功能，則：

  • [C-2-1] 只要動作溢位選單彈出式視窗不為空白，且動作列可見，就必須顯示動作溢位按鈕。
  • [C-2-2] 不得修改透過選取動作列中的溢位按鈕顯示的動作溢位彈出式視窗位置，但可修改透過選取「選單」功能顯示的動作溢位彈出式視窗位置。

如果裝置實作項目未提供「選單」功能，為確保回溯相容性，這些項目：

  • [C-3-1] 當 targetSdkVersion 小於 10 時，應用程式「必須」透過實體按鈕、軟體鍵或手勢提供「選單」功能。除非與其他導覽功能一併隱藏，否則應可存取「選單」功能。

如果裝置實作項目提供輔助功能，則：

  • [C-4-1] 必須在其他導覽鍵可供存取時，透過單一動作 (例如輕觸、按兩下或手勢) 存取「助理」功能。
  • [C-SR-3] 強烈建議使用長按 HOME 功能，做為指定互動。

如果裝置實作項目使用螢幕的特定部分顯示導覽鍵，則：

  • [C-5-1] 導覽鍵必須使用螢幕上與應用程式不同的部分，且不得遮蔽或干擾應用程式可用的螢幕部分。
  • [C-5-2] 必須將部分螢幕畫面提供給符合第 7.1.1 節所定義需求的應用程式。
  • [C-5-3] 必須遵守應用程式透過 View.setSystemUiVisibility() API 方法設定的旗標，以便正確隱藏螢幕的這部分 (又稱導覽列)，如 SDK 說明文件所述。

如果導覽功能是以螢幕上的手勢動作提供：

如果螢幕目前的方向在左側和右側邊緣提供導覽功能：

  • [C-7-1] 導覽功能必須是「返回」，且必須透過從螢幕目前方向的左右兩側邊緣滑動來提供。
  • [C-7-2] 如果在左側或右側邊緣提供自訂可滑動系統面板，則這些面板必須放置在畫面頂端 1/3 處，並提供清楚的視覺指標，持續顯示拖曳動作會叫用上述面板，而非返回。使用者「可以」設定系統面板，使其位於螢幕邊緣頂端 1/3 處下方，但系統面板「不得」使用超過邊緣 1/3 的空間。
  • [C-7-3] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT 或 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 標記，從邊緣滑動時的行為必須與 AOSP 實作方式相同，SDK 中有相關說明。
  • [C-7-4] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT 或 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 標記，自訂可滑動系統面板必須隱藏，直到使用者帶入或取消調暗系統資訊列 (即導覽列和狀態列)，如 AOSP 實作方式所示。

如果提供返回瀏覽功能，且使用者取消「返回」手勢，則：

  • [C-8-1] 必須呼叫 OnBackInvokedCallback.onBackCancelled()。
  • [C-8-2] 不得呼叫 OnBackInvokedCallback.onBackInvoked()。
  • [C-8-3] 不得傳送 KEYCODE_BACK 事件。

如果提供返回瀏覽功能，但前景應用程式「沒有」註冊 OnBackInvokedCallback，則：

  • 系統「應」為前景應用程式提供動畫，向使用者表示要返回，如 AOSP 所提供。

如果裝置實作項目支援系統 API setNavBarMode，允許任何具有 android.permission.STATUS_BAR 權限的系統應用程式設定導覽列模式，則：

  • [C-9-1] 必須支援 AOSP 程式碼提供的兒童友善圖示或按鈕式導覽。

7.2.4. 觸控螢幕輸入

Android 支援多種指標輸入系統，例如觸控螢幕、觸控板和模擬觸控輸入裝置。觸控螢幕裝置實作會與螢幕相關聯，讓使用者感覺自己是直接操作螢幕上的項目。由於使用者是直接觸控螢幕，系統不需要任何額外功能提示，即可指出正在操控的物件。

裝置實作方式：

  • 應具備某種指標輸入系統 (類似滑鼠或觸控)。
  • 應支援完全獨立追蹤的指標。

如果裝置實作項目在主要 Android 相容螢幕上包含觸控螢幕 (單點觸控或更佳)，則：

  • [C-1-1] 必須回報 TOUCHSCREEN_FINGER Configuration.touchscreen API 欄位。
  • [C-1-2] 必須回報 android.hardware.touchscreen 和 android.hardware.faketouch 功能旗標。

如果裝置實作項目包含觸控螢幕，且該螢幕可追蹤主要 Android 相容螢幕上的多點觸控，則：

  • [C-2-1] 必須回報適當的功能旗標 android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand，對應裝置上特定觸控螢幕的類型。

如果裝置實作項目依賴滑鼠或軌跡球等外部輸入裝置 (即並非直接觸控螢幕)，在主要 Android 相容螢幕上輸入內容，且符合第 7.2.5 節中的模擬觸控規定，則：

  • [C-3-1] MUST NOT report any feature flag starting with android.hardware.touchscreen.
  • [C-3-2] 只能回報 android.hardware.faketouch。
  • [C-3-3] MUST report TOUCHSCREEN_NOTOUCH for the Configuration.touchscreen API field.

7.2.5. 模擬觸控輸入

觸控模擬介面提供使用者輸入系統，可模擬觸控螢幕的部分功能。舉例來說，使用滑鼠或遙控器驅動螢幕上的游標，雖然近似於觸控，但使用者必須先指向或聚焦，然後點選。滑鼠、觸控板、陀螺儀式空鼠、陀螺儀指標、搖桿和多點觸控板等眾多輸入裝置，都能支援模擬觸控互動。Android 包含 android.hardware.faketouch 功能常數，對應高保真非觸控 (指標式) 輸入裝置，例如滑鼠或觸控板，可充分模擬觸控式輸入 (包括基本手勢支援)，並指出裝置支援觸控螢幕功能的模擬子集。

如果裝置實作項目未包含觸控螢幕，但包含其他想提供的指標輸入系統，則：

  • 「應」宣告支援 android.hardware.faketouch 功能旗標。

如果裝置實作項目聲明支援 android.hardware.faketouch，則：

  • [C-1-1] 必須回報指標位置的絕對 X 和 Y 螢幕位置，並在畫面上顯示指標。
  • [C-1-2] 必須回報觸控事件，並使用動作代碼指定指標在螢幕上向上或向下移動時發生的狀態變化。
  • [C-1-3] MUST support pointer down and up on an object on the screen, which allows users to emulate tap on an object on the screen.
  • [C-1-4] MUST support pointer down, pointer up, pointer down then pointer up in the same place on an object on the screen within a time threshold, which allows users to emulate double tap on an object on the screen.
  • [C-1-5] 必須支援在螢幕上任意點按指標，將指標移至螢幕上任何其他任意點，然後放開指標，讓使用者模擬觸控拖曳。
  • [C-1-6] 必須支援指標向下，然後允許使用者快速將物件移至螢幕上的不同位置，接著指標向上，讓使用者在螢幕上甩動物件。

如果裝置實作項目聲明支援 android.hardware.faketouch.multitouch.distinct，則：

  • [C-2-1] 必須聲明支援 android.hardware.faketouch。
  • [C-2-2] MUST 支援個別追蹤兩個以上的獨立指標輸入內容。

如果裝置實作項目聲明支援 android.hardware.faketouch.multitouch.jazzhand，則：

  • [C-3-1] 必須聲明支援 android.hardware.faketouch。
  • [C-3-2] 必須支援完全獨立追蹤 5 個 (追蹤手指) 以上的指標輸入。

7.2.6. 支援遊戲控制器

7.2.6.1. 按鈕對應

裝置實作方式：

  • [C-1-1] 必須能夠將 HID 事件對應至下表所列的相應 InputEvent 常數。上游 Android 實作項目符合這項要求。

如果裝置實作項目內嵌控制器，或隨附的控制器可輸入下表列出的所有事件，則：

  • [C-2-1] 必須宣告功能旗標 android.hardware.gamepad
按鈕 HID 用法2 Android 按鈕
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-Pad 向上1
D-Pad 向下1		 0x01 0x00393 AXIS_HAT_Y4
D-pad left1
D-pad right1		 0x01 0x00393 AXIS_HAT_X4
左肩鈕1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
右肩鈕1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
按一下左側搖桿1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
按一下右側搖桿1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
返回1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 上述 HID 用途必須在遊戲手把 CA (0x01 0x0005) 中宣告。

3 這項用法必須具有邏輯最小值 0、邏輯最大值 7、實體最小值 0、實體最大值 315、以度為單位的單位，以及 4 的報表大小。邏輯值定義為從垂直軸順時針旋轉；舉例來說，邏輯值為 0 代表未旋轉且按下向上按鈕，邏輯值為 1 代表旋轉 45 度且按下向上和向左鍵。

4 MotionEvent

類比控制項1 HID 用量 Android 按鈕
左觸發鍵 0x02 0x00C5 AXIS_LTRIGGER
右側觸發鍵 0x02 0x00C4 AXIS_RTRIGGER
左搖桿 0x01 0x0030
0x01 0x0031		 AXIS_X
AXIS_Y
右搖桿 0x01 0x0032
0x01 0x0035		 AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. 遙控器

如需裝置專屬需求，請參閱第 2.3.1 節。

7.3. 感應器

如果裝置實作項目包含特定感應器類型，且該類型有對應的第三方開發人員 API，裝置實作項目就「必須」實作該 API，如 Android SDK 說明文件和 Android 開放原始碼說明文件 (感應器) 所述。

裝置實作方式：

  • [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] 如果感應器串流要求的延遲時間上限為 0 毫秒，且應用程式處理器處於啟用狀態，則感應器資料的延遲時間上限必須為 100 毫秒 + 2 * sample_time。這項延遲不包括任何篩選延遲。

  • [C-1-3] 感應器啟動後，必須在 400 毫秒 + 2 * sample_time 內回報第一個感應器樣本。這個樣本的準確度為 0 也是可接受的。

  • [C-1-4] 對於 Android SDK 文件中指出為連續感應器的任何 API，裝置實作項目必須持續提供週期性資料樣本，且樣本的抖動應低於 3%，其中抖動定義為連續事件之間回報時間戳記值差異的標準差。

  • [C-1-5] MUST ensure that the sensor event stream MUST NOT prevent the device CPU from entering a suspend state or waking up from a suspend state.

  • [C-1-6] 必須以奈秒為單位回報事件時間，如 Android SDK 說明文件所述，代表事件發生並與 SystemClock.elapsedRealtimeNano() 時鐘同步的時間。

  • [C-SR-1] 強烈建議時間戳記同步錯誤低於 100 毫秒，且應低於 1 毫秒。

  • 啟用多個感應器時，耗電量「不得」超過個別感應器回報耗電量的總和。

上述清單僅供參考，Android SDK 和 Android 開放原始碼文件感應器的記錄行為才是權威資訊。

如果裝置實作項目包含特定感應器類型，且第三方開發人員可使用對應的 API，則：

  • [C-1-6] MUST 為所有感應器設定非零解析度，並透過 Sensor.getResolution() API 方法回報值。

部分感應器類型是複合類型，也就是說，這類感應器可從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速度感應器)。

裝置實作方式：

  • 如果包含感應器類型所述的必要實體感應器，就「應」實作這些感應器類型。

如果裝置實作項目包含複合感應器，則：

  • [C-2-1] MUST implement the sensor as described in the Android Open Source documentation on composite sensors.

如果裝置實作項目包含特定感應器類型，且該感應器類型有對應的第三方開發人員 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] 必須能夠測量從自由落體到任何軸向上四倍 gravity(4g) 以上的加速度。

  • [C-1-5] 必須具備至少 12 位元的解析度。

  • [C-1-6] 標準差不得超過 0.05 m/s^，且應以最快取樣率，針對至少 3 秒內收集的樣本，按軸計算標準差。

  • 應以至少 200 Hz 的頻率回報事件。

  • 解析度應至少為 16 位元。

  • 如果特性在生命週期內發生變化，則應在使用時校準並補償，且在裝置重新啟動時保留補償參數。

  • SHOULD be temperature compensated.

如果裝置實作項目包含 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] 強烈建議導入並回報 TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED 感應器。

如果裝置實作項目包含 3 軸式加速度計，且實作了 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器中的任一項：

  • [C-4-1] 這些裝置的耗電量總和必須一律低於 4 mW。

  • 在動態或靜態條件下，各項值應低於 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 以上的網路時，在空曠環境 (訊號強、多路徑可忽略、HDOP < 2) 中，裝置必須能在 10 秒內判斷位置 (快速首次定位時間)。通常只要使用某種形式的輔助或預測 GPS/GNSS 技術，即可滿足這項需求，盡量縮短 GPS/GNSS 定位時間 (輔助資料包括參考時間、參考位置和衛星星曆/時鐘)。

    • [C-1-6] 進行這類位置計算後，裝置實作項目必須在初始位置計算後的一小時內，於空曠處重新啟動位置要求時，在 5 秒內判斷位置，即使後續要求是在沒有資料連線的情況下提出，和/或是在電源重啟後提出也一樣。

  • 在空曠環境中，確定位置後，靜止不動或以每秒平方公尺不到 1 公尺的加速度移動時：

    • [C-1-3] 至少 95% 的時間內，必須能夠判斷 20 公尺內的定位，以及 0.5 公尺/秒內的車速。

    • [C-1-4] 必須透過 GnssStatus.Callback 同時追蹤及回報至少 8 顆來自單一星系的衛星。

    • 應能同時追蹤至少 24 顆衛星，來自多個星系 (例如 GPS + Glonass、北斗、Galileo 其中至少一個)。

  • [C-SR-2] 強烈建議在緊急電話通話期間，繼續透過 GNSS 定位供應商 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 公尺/秒平方的加速度移動時，應足以在至少 95% 的時間內，計算出 20 公尺內的位置和 0.2 公尺/秒內的速度。

7.3.4. 陀螺儀

裝置實作方式：

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

如果裝置實作項目包含陀螺儀，則：

  • [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。

  • [C-1-4] 必須具有 12 位元以上的解析度。

  • [C-1-5] 必須進行溫度補償。

  • [C-1-6] 必須在使用時校正和補償，並在裝置重新啟動時保留補償參數。

  • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). 變異數可隨取樣率而異，但「必須」受限於這個值。換句話說，如果以 1 Hz 取樣率測量陀螺儀的變異數，則變異數「應」不大於 1e-7 rad^2/s^2。

  • [C-SR-2] 裝置在室溫下靜止不動時，強烈建議校正誤差小於 0.01 rad/s。

  • [C-SR-3] 建議解析度為 16 位元以上。

  • 應以至少 200 Hz 的頻率回報事件。

如果裝置實作項目包含 3 軸式迴轉儀，則：

如果裝置實作項目包含少於 3 軸的陀螺儀，則：

  • [C-3-1] 必須導入並回報 TYPE_GYROSCOPE_LIMITED_AXES 感應器。

  • [C-SR-5] 強烈建議實作並回報 TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED 感應器。

如果裝置實作項目包含 3 軸式迴轉儀、加速計感應器和磁力儀感應器，則：

  • [C-4-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作項目包含 3 軸式加速度計和 3 軸式迴轉儀感應器，則：

  • [C-5-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。

  • [C-SR-6] 強烈建議實作TYPE_GAME_ROTATION_VECTOR複合感應器。

7.3.5. 氣壓計

裝置實作方式：

  • [C-SR-1] 建議加入氣壓計 (環境氣壓感應器)。

如果裝置實作項目包含氣壓計，則：

  • [C-1-1] 必須導入並回報 TYPE_PRESSURE 感應器。

  • [C-1-2] 必須能以 5 Hz 以上的頻率傳送事件。

  • [C-1-3] 必須經過溫度補償。

  • [C-SR-2] 強烈建議能夠回報 300 hPa 至 1100 hPa 範圍內的壓力測量值。

  • 應具有 1 hPa 的絕對準確度。

  • 在 20 hPa 範圍內，相對準確度應為 0.12 hPa (相當於海平面上約 200 公尺變化範圍內，準確度約為 1 公尺)。

宣告系統屬性 sensor.barometer.high_quality.implemented 的裝置實作項目：

  • [C-2-1] 必須回報 300 hPa 至 1100 hPa 範圍內的壓力測量值，絕對準確度為 +/- 1 hPa。

  • [C-2-2] 必須在 100 hPa 範圍內具有 0.15 hPa 的相對準確度，相當於海平面上 ~1000 公尺變化範圍內 ~1 公尺的準確度。

  • [C-2-3] 使用者輕觸、按壓或擠壓裝置時，壓力值必須穩定在 +/- 0.5 hPa 內。

  • [C-2-4] 使用者手持或將裝置放在口袋中行走時，氣壓值必須穩定在 +/- 0.15 hPa 範圍內。

  • [C-2-5] 啟動頻率超過 5 Hz 時，時間常數不得超過 300 毫秒，且平滑化不得跨感應器啟動。

  • [C-2-6] 暴露於日常照明和常見來源 (例如藍牙、行動網路連線或 Wi-Fi) 產生的無線電頻率時，必須穩定在 +/- 0.15 hPa 範圍內。

7.3.6. 溫度計

如果裝置實作項目包含環境溫度計 (溫度感應器)，則：

  • [C-1-1]「必須」定義SENSOR_TYPE_AMBIENT_TEMPERATURE環境溫度感應器，且感應器「必須」測量使用者與裝置互動時的環境 (室內/車輛駕駛室) 溫度 (以攝氏度為單位)。

如果裝置實作項目包含溫度計感應器，可測量環境溫度以外的溫度 (例如 CPU 溫度)，則：

如果裝置實作項目包含用於監控皮膚溫度的感應器，則：

7.3.7. 光度計

  • 裝置實作「可能」包含光度計 (環境光感應器)。

7.3.8. 鄰近感應器

  • 裝置實作「可能」會包含鄰近感應器。

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

  • [C-1-1] MUST measure the proximity of an object in the same direction as the screen. 也就是說，鄰近感應器「必須」朝向偵測螢幕附近的物體，因為這類感應器的主要用途是偵測使用者是否正在使用手機。如果裝置實作項目包含任何其他方向的鄰近感應器，則「不得」透過這個 API 存取。

  • [C-1-2] 必須具有 1 位元以上的準確度。

  • [C-1-3] 近距離讀數必須為 0 公分，遠距離讀數必須為 5 公分。

  • [C-1-4] 必須回報最大範圍和解析度 5。

7.3.9. 高精確度感應器

如果裝置實作項目包含本節定義的一組高品質感應器，並提供給第三方應用程式使用，則：

  • [C-1-1] MUST identify the capability through the android.hardware.sensor.hifi_sensors feature flag.

如果裝置實作項目宣告 android.hardware.sensor.hifi_sensors，則：

  • [C-2-1] 必須具備 TYPE_ACCELEROMETER 感應器，且該感應器：

    • 測量範圍必須至少介於 -8g 和 +8g 之間，強烈建議測量範圍至少介於 -16g 和 +16g 之間。

    • 測量解析度必須至少為 2048 LSB/g。

    • 測量頻率必須至少為 12.5 Hz 或更低。

    • 最大測量頻率必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。

    • 測量雜訊不得超過 400 μg/√Hz。

    • 必須實作此感應器的非喚醒形式，且緩衝功能至少要能儲存 3000 個感應器事件。

    • 批次處理耗電量不得超過 3 mW。

    • [C-SR-1] 強烈建議 3 dB 測量頻寬至少為奈奎斯特頻率的 80%，且此頻寬內的白噪音頻譜。

    • 在室溫下測試時，加速度隨機漫步應小於 30 μg √Hz。

    • 偏壓變化與溫度的關係應為 ≤ +/- 1 mg/°C。

    • 最佳擬合線非線性應 ≤ 0.5%，感應度變化與溫度變化比率應 ≤ 0.03%/C°。

    • 應具備 < 2.5 % 的交叉軸靈敏度，且在裝置運作溫度範圍內，交叉軸靈敏度變化應 < 0.2%。

  • [C-2-2] 必須具有與 TYPE_ACCELEROMETER 相同的品質要求。TYPE_ACCELEROMETER_UNCALIBRATED

  • [C-2-3] 必須具備 TYPE_GYROSCOPE 感應器，且：

    • 測量範圍必須至少介於 -1000 至 +1000 dps 之間。

    • 測量解析度必須至少為 16 LSB/dps。

    • 測量頻率必須至少為 12.5 Hz 或更低。

    • 最大測量頻率必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。

    • 測量雜訊必須不超過 0.014&°/s/√Hz。

    • [C-SR-2] 強烈建議 3 dB 測量頻寬至少為奈奎斯特頻率的 80%，且此頻寬內的白噪音頻譜。

    • SHOULD have a rate random walk less than 0.001&°/s √Hz tested at room temperature.

    • 相較於溫度，偏壓變化應 ≤ +/- 0.05&°/ s / °C。

    • 與溫度相比，靈敏度變化應 ≤ 0.02% / °C。

    • 最佳適配線非線性度應 ≤ 0.2%。

    • 應具有 ≤ 0.007&°/s/√Hz 的雜訊密度。

    • 裝置靜止時，在 10 ~ 40 ℃ 的溫度範圍內，校準誤差應小於 0.002 rad/s。

    • 應具有小於 0.1°/s/g 的 g 靈敏度。

    • 在裝置作業溫度範圍內，應具有 < 4.0 % 的交叉軸靈敏度，以及 < 0.3% 的交叉軸靈敏度變化。

  • [C-2-4] 必須具有與 TYPE_GYROSCOPE 相同的品質要求。TYPE_GYROSCOPE_UNCALIBRATED

  • [C-2-5] 必須具備 TYPE_GEOMAGNETIC_FIELD 感應器，且：

    • 測量範圍必須至少介於 -900 至 +900 μT 之間。

    • 測量解析度必須至少為 5 LSB/uT。

    • 測量頻率必須至少為 5 Hz 或更低。

    • 測量頻率上限必須為 50 Hz 以上。

    • 測量雜訊不得超過 0.5 uT。

  • [C-2-6] 必須具有與 TYPE_GEOMAGNETIC_FIELD 相同的品質要求，且：TYPE_MAGNETIC_FIELD_UNCALIBRATED

    • 必須實作這項感應器的非喚醒形式，且緩衝功能至少要能處理 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] MUST deliver samples to applications within 5 milliseconds from the time when the data is available on any of the above physical sensors to the application.

  • [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] MAY 有 TYPE_PROXIMITY 感應器，但如有，則 MUST 具備至少 100 個感應器事件的緩衝區容量。

請注意，本節中的所有耗電量規定都不包括應用程式處理器的耗電量。包括整個感應器鏈結所消耗的電力，例如感應器、任何支援電路、任何專用感應器處理系統等。

如果裝置實作項目包含直接感應器支援，則：

  • [C-3-1] 必須透過 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API，正確宣告支援的直接管道類型和直接回報率層級。

  • [C-3-2] 對於聲明支援感應器直接管道的所有感應器，必須支援至少一種感應器直接管道類型。

  • 應支援透過感應器直接管道回報下列類型主要感應器 (非喚醒變體) 的事件：

    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生物特徵辨識感應器

如要進一步瞭解如何評估生物辨識解鎖安全性，請參閱「評估生物辨識安全性」說明文件。

如果裝置實作項目包含安全螢幕鎖定，則：

  • 應包含生物辨識感應器

生物特徵辨識感應器可分為第 3 級 (舊稱強)、

第 2 級 (舊稱「弱」) 或第 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] MUST recognize and honor each parameter name defined as a constant in the Authenticators class and any combinations thereof. 反之，對於傳遞至 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法的整數常數，除了 Authenticators 中記錄為公開常數的常數及其任何組合外，不得接受或辨識。

  • [C-4-3] 裝置必須實作 ACTION_BIOMETRIC_ENROLL 動作，且裝置具備第 3 級或第 2 級生物特徵辨識功能。這項動作「必須」只顯示第 3 級或第 2 級生物特徵辨識的註冊進入點。

  • [C-4-4] 應用程式「必須」能使用 PromptContentView 內容顯示格式，將自訂內容新增至 BiometricPrompt。內容顯示格式不得擴充，以允許圖片、連結、互動式內容或其他形式的媒體，這些媒體不得已是 BiometricPromptAPI 的一部分。只要不變更、遮蓋或截斷這項內容，即可進行樣式調整 (例如變更位置、邊框間距、邊界和排版)。

如果裝置實作支援被動式生物辨識，則：

  • [C-5-1] 預設情況下，必須要求額外的確認步驟 (例如按下按鈕)。

  • [C-SR-1] 強烈建議提供設定，讓使用者覆寫應用程式偏好設定，並一律要求執行確認步驟。

  • [C-SR-2] 強烈建議確保確認動作安全無虞，作業系統或核心遭入侵時無法偽造。舉例來說，這表示根據實體按鈕的確認動作，會透過安全元件 (SE) 的僅輸入一般用途輸入/輸出 (GPIO) 接腳傳送，且只能透過按下實體按鈕驅動。

  • [C-5-2] 此外，還必須實作對應於 setConfirmationRequired(boolean) 的隱含驗證流程(不含確認步驟)，應用程式可設定使用此流程進行登入。

如果裝置實作項目有多個生物特徵辨識感應器，則：

  • [C-7-1] 如果生物辨識功能因嘗試次數過多而遭到鎖定 (即生物辨識功能會停用，直到使用者透過主要驗證解鎖為止)，或因嘗試次數過多而遭到限時鎖定 (即生物辨識功能會暫時停用，直到使用者等待一段時間為止)，則也必須鎖定所有其他生物辨識功能 (生物辨識類別較低)。如果鎖定時間有限，生物辨識驗證的輪詢時間必須是鎖定時間內所有生物辨識的輪詢時間上限。

  • [C-SR-12] 如果生物辨識功能因錯誤次數過多而遭到鎖定 (即生物辨識功能會停用，直到使用者透過主要驗證解鎖為止)，或因時間限制而遭到鎖定 (即生物辨識功能會暫時停用，直到使用者等待一段時間為止)，則強烈建議一併鎖定相同生物辨識類別的所有其他生物辨識功能。如果是時間限制鎖定，強烈建議將生物辨識驗證的退避時間設為時間限制鎖定中所有生物辨識的退避時間上限。

  • [C-7-2] MUST challenge the user for the recommended primary authentication (such as PIN, pattern, or password) to reset the lockout counter for a biometric being locked out. 第 3 級生物辨識「可能」允許重設鎖定計數器，適用於相同或較低等級的鎖定生物辨識。第 2 級或第 1 級生物辨識不得用於完成任何生物辨識的重設鎖定作業。

  • [C-SR-3] 強烈建議每次驗證時只要求確認一項生物特徵辨識資訊 (例如，如果裝置同時提供指紋和臉部感應器，則在確認其中一項資訊後，就應傳送 onAuthenticationSucceeded)。

如要讓裝置實作項目允許第三方應用程式存取金鑰儲存區金鑰，必須符合下列條件：

  • [C-6-1] 必須符合本節下方定義的第 3 類要求。

  • [C-6-2] 如果驗證需要 BIOMETRIC_STRONG，或驗證是透過 CryptoObject 叫用，則只能提供第 3 級生物特徵辨識。

如果裝置實作項目希望將生物特徵辨識感應器視為第 1 級 (舊稱「便利」)，則：

  • [C-1-1] 誤接受率必須低於 0.002%。

  • [C-1-2] 如果Android 生物特徵辨識測試通訊協定測得的詐欺和冒用接受率高於 7%，則必須揭露此模式的安全性可能不如高強度 PIN 碼、解鎖圖案或密碼，並清楚列舉啟用此模式的風險。

  • [C-1-9] 錯誤嘗試次數不得超過 20 次，且生物辨識驗證的退避時間不得少於 90 秒，之後就必須要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼) - 錯誤嘗試是指擷取品質良好 (BIOMETRIC_ACQUIRED_GOOD)，但與已註冊生物特徵辨識資料不符的嘗試。

  • [C-SR-4] 如果 Android 生物特徵辨識測試通訊協定測得的詐騙和冒用接受率高於 7%，強烈建議降低 [C-1-9] 中指定的生物特徵辨識驗證錯誤嘗試總次數。

  • [C-1-3] 必須限制生物特徵辨識驗證的嘗試次數，其中一次失敗嘗試是指擷取品質足夠 (BIOMETRIC_ACQUIRED_GOOD) 但與已註冊生物特徵辨識資訊不符的嘗試。

  • [C-SR-5] 建議在生物辨識驗證失敗五次後，將嘗試次數限制為至少每 [C-1-9] 30 秒一次，其中失敗嘗試是指擷取品質良好 (BIOMETRIC_ACQUIRED_GOOD) 但與已註冊生物辨識資料不符的嘗試。

  • [C-SR-6] 強烈建議在 TEE 中加入所有頻率限制邏輯。

  • [C-1-10] 一旦主要驗證回溯機制首次觸發 (如第 9.11 節的 [C-0-2] 所述)，就必須停用生物辨識驗證。

  • [C-1-11] 偽造和冒用接受率不得高於 30%，且 (1) 針對 A 級呈現攻擊儀器 (PAI) 物種的偽造和冒用接受率不得高於 30%，以及 (2) 針對 B 級 PAI 物種的偽造和冒用接受率不得高於 40%，如 Android 生物特徵辨識測試通訊協定所測量。

  • [C-1-4] 必須先建立信任鏈，讓使用者確認現有或新增受 TEE 保護的裝置憑證 (PIN 碼/圖案/密碼)，才能防止新增生物辨識資訊；Android 開放原始碼專案實作會在架構中提供相關機制。

  • [C-1-5] 使用者移除帳戶 (包括恢復原廠設定) 或移除建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 時，裝置必須完全移除所有可識別的使用者生物特徵辨識資料。

  • [C-1-6] MUST honor the individual flag for that biometric (i.e. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE, or DevicePolicymanager.KEYGUARD_DISABLE_IRIS)。

  • [C-1-7] 必須每隔 24 小時或更短時間，要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼)。

  • [C-1-8] 發生下列任一情況後，必須要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼) 或第 3 級 (嚴格) 生物特徵辨識：

    • 4 小時的閒置逾時時間。
    • 生物辨識驗證失敗 3 次。
    • 成功確認裝置憑證後，閒置逾時時間和驗證失敗次數就會重設。

  • [C-SR-7] 強烈建議使用 Android 開放原始碼計畫提供的架構邏輯，為新裝置強制執行 [C-1-7] 和 [C-1-8] 中指定的限制。

  • [C-SR-8] 強烈建議在裝置上測得的錯誤拒絕率低於 10%。

  • [C-SR-9] 建議每項已註冊的生物辨識技術，從偵測到生物辨識資訊到螢幕解鎖，延遲時間都應低於 1 秒。

  • [C-1-12] 每個冒充攻擊工具 (PAI) 物種的詐騙和冒充接受率不得高於 40%，這是根據 Android 生物特徵辨識測試通訊協定測得的結果。

  • [C-SR-13] 每種偽冒攻擊工具 (PAI) 的偽冒和冒用接受率強烈建議不高於 30%，並以 Android 生物特徵辨識測試通訊協定測量。

  • [C-SR-8] 強烈建議在裝置上測得的錯誤拒絕率低於 10%。

  • [C-1-15] MUST allow users to remove single or multiple biometrics enrollments.

  • [C-SR-14] 強烈建議揭露生物辨識感應器的生物辨識等級，以及啟用該感應器時的相關風險。

  • [C-SR-17] 強烈建議實作新的 AIDL 介面 (例如 IFace.aidl 和 IFingerprint.aidl)。

如果裝置實作項目想將生物特徵辨識感應器視為「第 2 級」(舊稱「弱」)，則：

  • [C-2-1] 必須符合上述第 1 類的所有規定。

  • [C-2-2] 偽造和冒用接受率不得高於 20%，且 (1) 偽造和冒用接受率不得高於 20% (針對 A 級別的呈現攻擊工具 (PAI) 物種)，以及 (2) 偽造和冒用接受率不得高於 30% (針對 B 級別的 PAI 物種)，如Android 生物特徵辨識測試通訊協定所測量。

  • [C-SR-15] 每種偽冒攻擊工具 (PAI) 的偽冒和冒用接受率，強烈建議不要超過 20%。

  • [C-2-3] MUST perform the biometric matching in an isolated execution environment outside Android user or kernel space, such as the Trusted Execution Environment (TEE), on a chip with a secure channel to the isolated execution environment or on Protected Virtual Machine that meets requirements in Section 9.17.

  • [C-2-4] 必須加密所有可識別資料，並以加密方式驗證，確保這些資料無法在隔離執行環境外取得、讀取或變更，或透過安全管道傳輸至隔離執行環境 (如 Android 開放原始碼計畫網站上的實作指南所述)，或透過符合第 9.17 節規定的 Hypervisor 控制的受保護虛擬機器。

  • [C-2-5] 針對攝影機生物特徵辨識，在進行生物特徵辨識驗證或註冊時：

    • 攝影機必須以某種模式運作，防止攝影機影格在隔離執行環境外部遭到讀取或變更，或防止攝影機影格在具有安全管道的晶片上遭到讀取或變更，該安全管道通往隔離執行環境或受 Hypervisor 控制的受保護虛擬機器，且該 Hypervisor 符合第 9.17 節的規定。

    • 如果是 RGB 單一攝影機解決方案，攝影機影格「可以」在獨立執行環境外讀取，以支援註冊預覽等作業，但「不得」變更。

  • [C-2-6] 不得允許第三方應用程式區分個別生物特徵辨識註冊。

  • [C-2-7] 不得允許應用程式處理器在 TEE 或受保護虛擬機器 (由符合第 9.17 節規定的 Hypervisor 控制) 的環境外，以未加密方式存取可識別的生物特徵辨識資料或任何衍生資料 (例如嵌入)。如果裝置在 Android 9 以下版本推出，升級後仍須遵守 [C-2-7] 規定。

  • [C-2-8] 必須具備安全的處理管道，確保作業系統或核心遭到入侵時，資料不會直接注入，以冒充使用者進行驗證。

  • [C-SR-10] 強烈建議針對所有生物特徵辨識模式加入活體偵測功能，並針對臉部生物特徵辨識加入注意力偵測功能。

  • [C-2-9] MUST make the biometric sensor available to third-party applications.

如果裝置實作項目希望將生物特徵辨識感應器視為第 3 級 (舊稱「強」)，則：

  • [C-3-1] 必須符合上述第 2 類的所有規定，但 [C-1-7] 和 [C-1-8] 除外。

  • [C-3-2] 必須實作硬體支援的金鑰儲存區。

  • [C-3-3] 偽造和冒用接受率不得高於 7%，且 (1) 偽造和冒用接受率不得高於 7% (針對 A 級呈現攻擊工具 (PAI) 物種)，以及 (2) 偽造和冒用接受率不得高於 20% (針對 B 級 PAI 物種)，以上皆須透過 Android 生物特徵辨識測試通訊協定測量。

  • [C-3-4] 必須每隔 72 小時或更短的時間，要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼)。

  • [C-3-5] 如果裝置支援的任何第 3 級生物特徵辨識重新註冊，就必須重新產生所有第 3 級生物特徵辨識的驗證器 ID。

  • [C-3-6] 必須對第三方應用程式啟用生物特徵辨識支援的金鑰儲存區金鑰。

  • [C-SR-16] 強烈建議，根據 Android 生物特徵辨識測試通訊協定的測量結果，每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒用接受率不得高於每個偽造和冒

如果裝置實作項目包含螢幕下指紋感應器 (UDFPS)，則：

  • [C-SR-11] 強烈建議您避免 UDFPS 的可觸控區域干擾三按鈕操作 (部分使用者可能需要此操作才能使用無障礙功能)。

7.3.11. 姿勢感應器

裝置實作方式：

  • 可能支援 6 自由度姿勢感應器。

如果裝置實作支援 6 自由度的姿勢感應器，則：

  • [C-1-1] 必須實作及回報 TYPE_POSE_6DOF 感應器。

  • [C-1-2] 必須比單獨的旋轉向量更準確。

7.3.12. 轉軸角度感應器

如果裝置實作項目支援轉軸角度感應器，則：

7.3.13. IEEE 802.1.15.4 (UWB)

如果裝置實作項目包含 802.1.15.4 的支援，並將功能公開給第三方應用程式，則：

  • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.

  • [C-1-3] 必須支援 AOSP 實作中定義的所有下列設定組合 (FIRA UCI 參數的預先定義組合)。

    • CONFIG_ID_1：FiRa 定義的單點傳播 STATIC STS DS-TWR 測距、 延遲模式、測距間隔 240 毫秒。

    • CONFIG_ID_2：FiRa 定義的一對多STATIC STS DS-TWR測距、延遲模式、測距間隔 200 毫秒。典型用途：智慧型手機與多部智慧型裝置互動。

    • CONFIG_ID_3：與 CONFIG_ID_1 相同，但不會回報到達角 (AoA) 資料。

    • CONFIG_ID_4：與 CONFIG_ID_1 相同，但已啟用 P-STS 安全模式。

    • CONFIG_ID_5：與 CONFIG_ID_2 相同，但已啟用 P-STS 安全模式。

    • CONFIG_ID_6：與 CONFIG_ID_3 相同，但已啟用 P-STS 安全模式。

    • CONFIG_ID_7：與 CONFIG_ID_2 相同，但已啟用 P-STS 個別受控者金鑰模式。

  • [C-1-4] 必須提供使用者功能提示，讓使用者切換 UWB 無線電的開啟/關閉狀態。

  • [C-1-5] 必須強制規定使用 UWB 無線電的應用程式持有UWB_RANGING 權限 (位於 NEARBY_DEVICES 權限群組下)。

通過標準機構 (包括 FIRA、CCC 和 CSA) 定義的相關一致性和認證測試，有助於確保 802.1.15.4 正常運作。

7.3.14. 自訂感應器

為提供差異化體驗，裝置實作項目「可能」會納入 Android 或 Wear OS 未涵蓋的其他感應器，預先載入的應用程式「可能」會存取這些感應器。

這類感應器的感應器 ID：

  • [C-0-1] MUST be higher than 65536.

如果自訂感應器用於健康或健身相關用途，則：

  • [C-0-2] 必須受到平台權限或系統權限保護。

7.4. 資料連線

7.4.1. 電話通訊系統

Android API 和本文所用的「電話」一詞，專指與撥打語音電話、傳送簡訊，或透過行動網路 (例如 GSM、CDMA、LTE、NR) 建立行動數據連線相關的硬體。支援「電話」的裝置可選擇提供部分或所有通話、訊息和資料服務，以符合產品需求。

  • Android 可用於未搭載電話硬體的裝置。也就是說，Android 可與手機以外的裝置相容。

如果裝置實作項目包含 GSM 或 CDMA 電話通訊，則：

  • [C-1-1] 必須根據技術宣告 android.hardware.telephony 功能旗標和其他子功能旗標。

  • [C-1-2] 必須完整支援該技術的 API。

  • 在撥打緊急電話時，應允許所有可用的行動網路服務類型 (2G、3G、4G、5G 等)，無論SetAllowedNetworkTypeBitmap()設定的網路類型為何。

如果裝置實作項目不含電話硬體，則：

  • [C-2-1] 必須將完整 API 實作為無作業。

如果裝置實作支援 eUICC 或 eSIM/嵌入式 SIM 卡，並包含專屬機制，可供第三方開發人員使用 eSIM 功能，則：

如果裝置實作項目未將系統屬性 ro.telephony.iwlan_operation_mode 設為 legacy，則：

如果裝置實作項目支援單一 IP 多媒體子系統 (IMS) 註冊，同時適用於多媒體電話服務 (MMTEL) 和進階通訊解決方案 (RCS) 功能，且預計遵守行動電信業者規定，針對所有 IMS 訊號流量使用單一 IMS 註冊，則：

如果裝置實作項目回報 android.hardware.telephony 功能，則：

如果裝置實作項目回報 android.hardware.telephony 功能並提供系統狀態列，則：

  • [C-7-1] 必須為特定群組 UUID 選取代表性的有效訂閱項目，以便在提供 SIM 卡狀態資訊的任何功能中向使用者顯示。這類功能包括狀態列行動網路訊號圖示或快速設定圖塊。

  • [C-SR-1] 強烈建議選擇有效資料訂閱做為代表性訂閱項目，除非裝置正在進行語音通話，否則強烈建議選擇有效語音訂閱做為代表性訂閱項目。

如果裝置實作項目回報 android.hardware.telephony 功能，則：

  • [C-6-7] 必須能夠開啟並同時使用每個 UICC 的最大邏輯通道數 (總共 20 個)，詳情請參閱 ETSI TS 102 221。

  • [C-6-8] 不得對有效電信業者應用程式 (由 TelephonyManager#getCarrierServicePackageName 指定) 自動或在未經使用者明確確認的情況下，套用下列任何行為：

    • 撤銷或限制網路存取權
    • 撤銷權限
    • 除了 AOSP 內建的電源管理功能外，還可限制應用程式在背景或前景應用程式執行
    • 停用或解除安裝應用程式

如果裝置實作項目回報 android.hardware.telephony 功能，且所有共用群組 UUID 的非機會性有效訂閱項目都已停用、從裝置上實際移除或標示為機會性，則裝置會發生下列情況：

  • [C-8-1] 必須自動停用同一群組中所有剩餘的有效機會訂閱項目。

如果裝置導入項目包含 GSM 電話通訊，但不包含 CDMA 電話通訊，則：

如果裝置實作項目支援具有多個連接埠和設定檔的 eUICC，則：

Android 17 新增的規定

如果裝置實作項目支援行動數據連線，則：

  • [C-SR-11] android.hardware.telephony.data強烈建議宣告這項功能。

如果裝置實作項目回報 android.hardware.telephony.data，表示：

  • [C-12-1] 必須支援至少兩個同步行動數據網路連線，例如 PDP 內容、PDN 連線和 DN 連線。

新增規定結束 (7.4.1 > C-SR-11 和 C-12-1)

7.4.1.1. 封鎖號碼功能適用性

如果裝置實作項目回報 android.hardware.telephony.calling 功能，則：

  • [C-1-1] 必須支援封鎖號碼

  • [C-1-2] 必須完整實作 BlockedNumberContract 和對應的 API，如 SDK 說明文件所述。

  • [C-1-3] MUST block all calls and messages from a phone number in BlockedNumberProvider without any interaction with apps. 只有在暫時解除號碼封鎖時 (如 SDK 文件所述)，才會例外。

  • [C-1-4] 必須將遭封鎖的通話寫入平台通話記錄供應商，且必須在預先安裝的撥號應用程式中，從預設通話記錄檢視畫面中篩除 BLOCKED_TYPE 通話。

  • [C-1-5] 不得針對遭封鎖的訊息寫入電話服務供應商。

  • [C-1-6] 必須實作封鎖號碼管理 UI，並透過 TelecomManager.createManageBlockedNumbersIntent() 方法傳回的意圖開啟。

  • [C-1-7] 不得允許次要使用者在裝置上查看或編輯封鎖號碼，因為 Android 平台會假設主要使用者完全控管裝置上的單一電話服務執行個體。次要使用者必須隱藏所有封鎖相關的 UI，且系統仍須遵守封鎖名單。

  • 裝置更新至 Android 7.0 時，應將封鎖的號碼遷移至供應商。

  • SHOULD 提供使用者介面，在預先安裝的撥號應用程式中顯示已封鎖的通話。

7.4.1.2. Telecom API

Android 17 新增的規定

如果裝置實作項目宣告 android.hardware.microphone 和 android.hardware.audio.output，但未宣告 android.hardware.type.television，則：

  • [7.4.1.2/C-0-1] 必須宣告功能旗標 android.software.telecom。

  • [7.4.1.2/C-0-2] 必須實作電信架構。

新增規定結束 (7.4.1.2 > C-0-1 和 C-0-2)

如果裝置實作項目回報 android.hardware.telephony.calling，表示：

  • [C-1-1] 必須支援 SDK 中說明的 ConnectionService API。

  • [C-1-2] 如果使用者正在通話，且通話是由不支援 CAPABILITY_SUPPORT_HOLD 指定保留功能的第三方應用程式發起，則必須顯示新的來電，並提供使用者接受或拒絕來電的選項。

  • [C-1-3] 必須有實作 InCallService 的應用程式。

  • [C-SR-1] 強烈建議通知使用者，接聽來電會導致通話中斷。

    AOSP 實作項目會透過抬頭通知，向使用者指出接聽來電會導致其他通話中斷，藉此符合這些規定。

  • [C-SR-2] EXTRA_LOG_SELF_MANAGED_CALLS 強烈建議預先載入預設撥號應用程式，當第三方應用程式在 PhoneAccount 上將 extras 鍵設為 true 時，預設撥號應用程式會在通話記錄中顯示通話記錄項目和第三方應用程式的名稱。

  • [C-SR-3] 強烈建議處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，以用於 android.telecom API，如下所示：

7.4.1.3. Cellular NAT-T Keepalive Offload

裝置實作方式：

  • 應支援行動網路保持連線卸載功能。

如果裝置實作項目支援行動網路連線保持運作卸載，並向第三方應用程式公開這項功能，則：

  • [C-1-1] 必須支援 SocketKeepAlive API。

  • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.

  • [C-1-3] 必須支援與 Cellular Radio HAL 支援的並行行動網路連線保持運作時段數量。

  • [C-SR-1] 強烈建議每個無線電執行個體至少支援三個蜂巢式網路連線保持運作插槽。

如果裝置實作項目不支援行動網路連線保持運作卸載，則：

  • [C-2-1] MUST return 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] 必須支援 mDNS，且不得在任何運作時間 (包括螢幕未處於啟用狀態時) 篩選 mDNS 封包 (224.0.0.251 或 ff02::fb)，除非未保留多點傳送鎖定，且封包是由 APF 篩選。封包不必滿足應用程式目前透過 NsdManager API 要求的任何 mDNS 作業。不過，如果為了符合目標市場適用的法規要求，裝置必須將耗電量維持在規定範圍內，裝置「可能」會篩選 mDNS 封包。

  • [C-1-5] 不得將 WifiManager.enableNetwork() API 方法呼叫視為充分的指標，藉此切換目前用於應用程式流量的預設有效 Network，以及 ConnectivityManager API 方法 (例如 getActiveNetwork 和 registerDefaultNetworkCallback) 傳回的 Network。換句話說，只有在成功驗證 Wi-Fi 網路提供網際網路存取權時，他們「可能」才會停用任何其他網路供應商 (例如行動數據) 提供的網際網路存取權。

  • [C-1-6] 強烈建議在呼叫 ConnectivityManager.reportNetworkConnectivity() API 方法時，重新評估 Network 的網路連線能力，並在評估結果顯示目前的 Network 不再提供網路連線能力時，切換至任何其他可用的網路 (例如行動數據)，以提供網路連線能力。

  • [C-1-7] STA 處於連線中斷狀態時，必須在每次掃描開始時，隨機產生探測要求訊框的來源 MAC 位址和序號。

  • [C-1-8] 必須使用一致的 MAC 位址 (掃描期間不應隨機產生 MAC 位址)。

  • [C-1-9] MUST 在掃描期間，正常 (循序) 疊代探測要求序號。

  • [C-1-10] MUST randomize Probe request sequence number between the last probe request of a scan and the first probe request of the next scan.

  • [C-SR-1] 強烈建議在關聯和關聯期間，隨機產生用於所有 STA 通訊的來源 MAC 位址，以連線至存取點 (AP)。

    • 裝置與每個 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 鎖定時，都「應該」關閉 Wi-Fi 省電模式，且鎖定處於啟用狀態。WIFI_MODE_FULL_LOW_LATENCY

  • [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 掃描位置資訊，則：

7.4.2.1. Wi-Fi Direct

裝置實作方式：

  • 應支援 Wi-Fi Direct (Wi-Fi 點對點)。

如果裝置實作項目包含 Wi-Fi Direct 支援，則：

  • [C-1-1] MUST implement the corresponding Android API as described in the SDK documentation.

  • [C-1-2] MUST report the hardware feature android.hardware.wifi.direct.

  • [C-1-3] 必須支援一般 Wi-Fi 作業。

  • [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。

  • [C-SR-1] 強烈建議針對所有新建立的 Wi-Fi Direct 連線，將來源 MAC 位址隨機化處理。

裝置實作方式：

如果裝置實作項目包含 TDLS 支援，且 TDLS 是透過 WiFiManager API 啟用，則：

  • [C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。

  • 只有在可能且有利時，才應使用 TDLS。

  • 應採用某種啟發式方法，且在效能可能比透過 Wi-Fi 存取點更差時，不使用 TDLS。

7.4.2.3. 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] 必須在不超過 30 分鐘的時間間隔內，以及每次啟用 Wi-Fi Aware 時，隨機產生 Wi-Fi Aware 管理介面位址，除非 Aware 測距作業正在進行中，或 Aware 資料路徑處於啟用狀態 (只要資料路徑處於啟用狀態，就不會隨機產生位址)。

如果裝置實作項目包含對 Wi-Fi Aware 和 Wi-Fi 定位功能的支援 (如第 7.4.2.5 節所述)，並將這些功能公開給第三方應用程式，則：

7.4.2.4. Wi-Fi Passpoint

如果裝置實作項目包含 802.11 (Wi-Fi) 支援，則：

如果裝置實作項目支援 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] MUST follow the AOSP implementation to discover, match and associate to Passpoint networks.

  • [C-1-6] 必須支援 Wi-Fi 聯盟 Passpoint R2 中定義的裝置佈建通訊協定子集，至少包括 EAP-TTLS 驗證和 SOAP-XML。

  • [C-1-7] MUST process the AAA server certificate as described in Hotspot 2.0 R3 specification.

  • [C-1-8] 必須支援使用者透過 Wi-Fi 選擇器控制佈建作業。

  • [C-1-9] MUST keep Passpoint configurations persistent across reboots.

  • [C-SR-1] 強烈建議支援條款及細則接受功能。

  • [C-SR-2] 強烈建議支援場地資訊功能。

如果提供全域 Passpoint 停用使用者控制項切換開關，實作項目應：

  • [C-3-1] 必須預設啟用 Passpoint。
7.4.2.5. Wi-Fi 定位 (Wi-Fi 封包往返時間 - RTT)

裝置實作方式：

如果裝置實作項目包含 Wi-Fi 定位支援，並向第三方應用程式公開這項功能，則：

  • [C-1-1] 必須按照 SDK 說明文件所述，實作 WifiRttManager API。

  • [C-1-2] 必須宣告 android.hardware.wifi.rtt 功能旗標。

  • [C-1-3] 執行 RTT 時，如果 Wi-Fi 介面未與存取點建立關聯，則必須為每個 RTT 叢發隨機產生來源 MAC 位址。

  • [C-1-4] 在第 68 個百分位數 (以累積分布函數計算) 時，80 MHz 頻寬的準確度必須在 2 公尺內。

  • [C-SR-1] 強烈建議在第 68 個百分位數 (以累積分佈函式計算) 的 80 MHz 頻寬下，準確回報 1.5 公尺內的距離。

7.4.2.6. Wi-Fi 保持運作卸載

裝置實作方式：

  • SHOULD include support for Wi-Fi keepalive offload.

如果裝置實作項目支援 Wi-Fi 保持連線卸載，並向第三方應用程式公開這項功能，則：

  • [C-1-1] MUST support the SocketKeepAlive API.

  • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi

如果裝置實作項目不支援 Wi-Fi 保持連線卸載，則：

7.4.2.7. Wi-Fi 輕鬆連線 (裝置佈建通訊協定)

裝置實作方式：

如果裝置實作項目支援 Wi-Fi Easy Connect，並向第三方應用程式公開這項功能，則：

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] MUST provide the user an option to select to use TOFU.
7.4.2.10. Wi-Fi 附近裝置偵測

Android 17 新增的規定

如果裝置實作項目包含 Wi-Fi 附近裝置偵測功能支援，則：

  • [C-1-1] 必須支援附近裝置偵測。

  • [C-1-2] 必須宣告 android.hardware.wifi.rtt 功能旗標。

  • [C-1-3] WifiRttManager#getProximityDetectionCharacteristics() 方法必須傳回非空值。

  • [C-1-4] 必須實作 WifiRttManager 連續測距 API。

  • [C-1-5] 必須同時支援 Wi-Fi 和 Wi-Fi 附近裝置偵測作業。

  • [C-1-6] 在第 68 個百分位數 (以累積分布函數計算) 的 80 MHz 頻寬下，準確度必須在 2 公尺內。

  • [C-1-7] 必須使用最高可用頻帶 (6 GHz、5 GHz 或 2.4 GHz) 執行鄰近偵測 (PD) 測距，並依下列優先順序使用支援的最大頻寬：160 MHz、80 MHz、40 MHz 和 20 MHz。

  • [C-SR-1] 強烈建議在第 68 個百分位數 (以累積分佈函式計算) 的 80 MHz 頻寬下，準確回報 1.5 公尺內的距離。

  • [C-SR-2] 強烈建議支援 802.11az NTB 測距。

新增需求結束 (7.4.2.10 Wi-Fi 鄰近偵測)

7.4.3. 藍牙

如果裝置實作項目支援藍牙音訊設定檔，則：

  • 應支援進階音訊轉碼器和藍牙音訊轉碼器 (例如 LDAC)。

如果裝置實作支援 HFP、A2DP 和 AVRCP，則：

  • 應支援至少 5 部連線裝置。

如果裝置實作項目宣告 android.hardware.vr.high_performance 功能，則：

  • [C-1-1] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能。

Android 支援藍牙和藍牙低功耗。

如果裝置實作項目支援藍牙和藍牙低功耗，則：

  • [C-2-1] 必須宣告相關平台功能 (分別為 android.hardware.bluetooth 和 android.hardware.bluetooth_le)，並實作平台 API。

  • 應視裝置情況實作相關藍牙設定檔，例如 A2DP、AVRCP、OBEX、HFP 等。

如果裝置實作項目支援藍牙低功耗 (BLE)，則：

  • [C-3-1] 必須宣告硬體功能 android.hardware.bluetooth_le。

  • [C-3-2] 必須啟用以 GATT (通用屬性設定檔) 為基礎的藍牙 API，如 SDK 說明文件和 android.bluetooth 所述。

  • [C-3-3] 必須回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，指出是否已實作 ScanFilter API 類別的篩選邏輯。

  • [C-3-4] 必須回報 BluetoothAdapter.isMultipleAdvertisementSupported() 的正確值，指出是否支援低功耗廣告。

  • [C-3-5] MUST implement a Resolvable Private Address (RPA) timeout no longer than 15 minutes and rotate the address at timeout to protect user privacy when device is actively using BLE for scanning or advertising. 為防範時間攻擊，逾時間隔也「必須」在 5 到 15 分鐘之間隨機設定。

  • 實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。

  • 應支援將批次掃描作業卸載至藍牙晶片組。

  • 應支援多個廣告，且至少有 4 個廣告空間。

如果裝置實作項目支援藍牙 LE，並使用藍牙 LE 掃描位置資訊，則：

  • [C-4-1] 必須提供使用者介面，讓使用者啟用/停用透過 System API BluetoothAdapter.isBleScanAlwaysAvailable() 讀取的值。

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

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

  • [C-6-1] 除非提出要求的應用程式根據目前的背景/前景狀態，成功通過android.permission.ACCESS_FINE_LOCATION權限檢查，否則不得允許存取任何可用於推算裝置位置的藍牙中繼資料 (例如掃描結果)。

如果裝置實作項目支援藍牙或藍牙低功耗，且應用程式資訊清單未包含開發人員的聲明，指出他們不會從藍牙衍生位置資訊，則：

如果裝置實作項目為 BluetoothAdapter.isLeAudioSupported() API 傳回 true，則：

  • [C-7-1] MUST support unicast client.

  • [C-7-2] 必須支援 2M PHY。

  • [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] MUST support at least 2 BIS links in a BIG.

  • [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 傳輸訊號，測試裝置與參考裝置相距 1 公尺時，95% 的 RSSI 測量值必須在 +/-9 dB 範圍內。

  • [C-10-2] 必須納入 Rx/Tx 校正，以減少每個通道的偏差，確保每個天線 (如使用多個天線) 上 3 個通道的測量值，有 95% 都在彼此 +/-3 dB 的範圍內。

如果裝置實作項目宣告 FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING，則：

  • [C-11-1] MUST report the hardware feature flag android.hardware.bluetooth_le.channel_sounding.

  • [C-11-2] 必須在第 90 個百分位數回報準確的範圍，誤差必須在 +/- 0.5 公尺內，計算方式為使用累積分布函數，距離為 1 公尺。

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

  • [C-SR-2] 建議您「強烈」測量並補償 Rx 偏移，確保在距離以 ADVERTISE_TX_POWER_HIGH 傳輸的參考裝置 1 公尺處，BLE RSSI 中位數為 -60 dBm +/-10 dB，且裝置方向為「平行平面」，螢幕朝向相同方向。

  • [C-SR-3] 強烈建議測量並補償傳輸偏移，確保從 1 公尺處的參考裝置掃描時，BLE RSSI 中位數為 -60 dBm +/-10 dB，且裝置方向為「平行平面」，螢幕朝向相同方向。ADVERTISE_TX_POWER_HIGH

強烈建議按照「在場校正需求」一文中的步驟設定評估功能。

7.4.4. 近距離無線通訊

裝置實作方式：

  • 應包含近距離無線通訊 (NFC) 的收發器和相關硬體。

  • [C-0-1] 即使不支援 NFC 或宣告 android.hardware.nfc 功能，也必須實作 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，因為這些類別代表與通訊協定無關的資料表示格式。

如果裝置實作項目包含 NFC 硬體，且計畫向第三方應用程式開放使用，則：

  • [C-1-1] MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method.

  • 必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：

  • [C-1-2] 必須能夠透過下列 NFC 標準，做為 NFC 論壇讀取器/寫入器 (如 NFC 論壇技術規格 NFCForum-TS-DigitalProtocol-1.0 所定義)：

    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC 論壇標記類型 2、3、4、5 (由 NFC 論壇定義)

  • [C-SR-1] 強烈建議能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息和原始資料。請注意，雖然 NFC 標準目前是「強烈建議」，但日後版本的相容性定義預計會將這些標準改為「必須」。這個版本可選擇是否採用這些標準，但日後推出的版本將強制採用。強烈建議現有和新裝置現在就符合這些要求，以便日後升級至平台新版本。

  • [C-1-13] 處於 NFC 探索模式時，必須輪詢所有支援的技術。

  • 裝置處於喚醒狀態、螢幕開啟且螢幕鎖定解除時，應處於 NFC 探索模式。

  • 應能讀取薄膜 NFC 條碼產品的條碼和網址 (如已編碼)。

請注意，上述 JIS、ISO 和 NFC 論壇規格沒有公開連結。

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

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

  • [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 卡片模擬 API。

如果裝置實作項目包含本節所述的一般 NFC 支援功能，且支援讀取器/寫入器角色中的 MIFARE 技術 (MIFARE Classic、MIFARE Ultralight、MIFARE Classic 上的 NDEF)，則：

  • [C-4-1] MUST implement the corresponding Android APIs as documented by the Android SDK.

  • [C-4-2] MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. 請注意，這不是標準 Android 功能，因此不會以常數形式出現在 android.content.pm.PackageManager 類別中。

7.4.5. 網路通訊協定和 API

7.4.5.1. 最低網路功能

裝置實作方式：

  • [C-0-1] 必須支援一或多種形式的資料網路。具體來說，裝置實作項目「必須」支援至少一個資料標準，且該標準的傳輸速率至少為 200 Kbit/sec。符合這項規定的技術包括 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] MUST enable IPv6 by default.

  • 必須確保 IPv6 通訊的可靠性與 IPv4 相同，例如：

  • [C-0-4] MUST maintain IPv6 connectivity in doze mode.

  • [C-0-5] 速率限制不得導致裝置在任何符合 IPv6 規範的網路上失去 IPv6 連線能力，這些網路使用的 RA 生命週期至少為 180 秒。

  • [C-0-6] 連線至 IPv6 網路時，裝置 MUST 為第三方應用程式提供直接 IPv6 網路連線，且裝置不得在本地進行任何形式的位址或通訊埠轉譯。無論是 Socket#getLocalAddress 或 Socket#getLocalPort 等受管理 API，還是 getsockname() 或 IPV6_PKTINFO 等 NDK API，都「必須」傳回實際用於在網路上傳送及接收封包的 IP 位址和連接埠，且這些位址和連接埠會顯示為網際網路 (網路) 伺服器的來源 IP 和連接埠。

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

如果裝置實作支援 Wi-Fi，則：

  • [C-1-1] 必須支援 Wi-Fi 上的雙重堆疊和僅限 IPv6 的作業。

如果裝置實作支援乙太網路，則：

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

如果裝置實作支援行動數據，則：

  • [C-3-1] MUST support IPv6 operation (IPv6-only and possibly dual-stack) on cellular.

如果裝置實作項目支援多種網路類型 (例如 Wi-Fi 和行動數據)，則：

  • [C-4-1] 裝置同時連線至多個網路類型時，必須同時滿足上述各項網路要求。
7.4.5.3. 網頁認證入口

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

如果裝置實作項目完整實作 android.webkit.Webview API，則：

  • [C-1-1] MUST provide a captive portal application to handle the intent ACTION_CAPTIVE_PORTAL_SIGN_IN and display the captive portal login page, by sending that intent, on call to the System API ConnectivityManager#startCaptivePortalApp(Network, Bundle).

  • [C-1-2] 裝置連上任何網路類型 (包括行動網路、Wi-Fi、乙太網路或藍牙) 時，必須偵測網頁認證入口，並支援透過網頁認證入口應用程式登入。

  • [C-1-3] 裝置設為使用嚴格模式的私人 DNS 時，必須支援使用明文 DNS 登入連線區門戶。

  • [C-1-4] 必須根據 SDK 說明文件，針對 android.net.LinkProperties.getPrivateDnsServerName 和 android.net.LinkProperties.isPrivateDnsActive，使用加密 DNS 處理所有未明確與連線驗證入口網站通訊的網路流量。

  • [C-1-5] 必須確保使用者登入封閉式入口網站時，應用程式使用的預設網路 (由 ConnectivityManager.getActiveNetwork、ConnectivityManager.registerDefaultNetworkCallback 傳回，且 Java 網路 API (例如 java.net.Socket) 和原生 API (例如 connect()) 預設使用) 是任何其他可提供網際網路存取的可用網路 (如有)。

7.4.6. 同步設定

裝置實作方式：

7.4.7. 數據節省模式

如果裝置實作項目包含計量付費連線，則為：

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

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

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

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

7.4.8. 安全元件

如果裝置實作項目支援可使用 Open Mobile API 的安全元件，並開放第三方應用程式使用，則：

7.4.9. UWB

如果裝置實作項目支援 802.1.15.4，並將這項功能公開給第三方應用程式，則：

  • [C-1-1]「必須」在 android.uwb 中實作對應的 Android API。

  • [C-1-2] 必須回報硬體功能旗標 android.hardware.uwb。

  • [C-1-3] 必須支援 Android 實作中定義的所有相關 UWB 設定檔。

  • [C-1-4] 必須提供使用者功能提示，讓使用者切換 UWB 無線電的開啟/關閉狀態。

  • [C-1-5] 必須強制規定使用 UWB 無線電的應用程式持有 UWB_RANGING 權限 (位於 NEARBY_DEVICES 權限群組下)。

  • [C-SR-1] 強烈建議通過標準機構定義的相關一致性和認證測試，包括 FIRA、CCC 和 CSA。

  • [C-1-6] 必須確保在非反射式腔室中，視線環境距離 1 公尺時，95% 的距離測量值在 +/-15 公分內。

  • [C-1-7] 必須確保與參考裝置距離 1 公尺時，距離測量中位數介於 [0.75 公尺，1.25 公尺] 之間，其中實際距離是從 DUT 的頂端測量。

  • [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)。

如果裝置實作項目包含至少一個攝影機，且預先安裝的攝影機應用程式會處理意圖 MediaStore.ACTION_MOTION_PHOTO_CAPTURE 或 MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE，則：

  • [C-1-4] 處理這些意圖時，預先安裝的相機應用程式必須先移除圖片中繼資料中的使用者位置資訊，再將圖片傳送至沒有 ACCESS_FINE_LOCATION 的接收應用程式。

  • [C-1-5] MUST ensure that the returned motion photo uses the Motion Photo format 1.0 specification.

Android 17 新增的規定

  • [C-1-6] 必須使用 CameraCharacteristics.INFO_DEVICE_TYPE 欄位，將每個攝影機裝置類型標示為 BUILT_IN、EXTERNAL 或 VIRTUAL。也必須使用 CaptureResult.INFO_DEVICE_TYPE 欄位標記每個攝影機輸出影格。
    如果攝影機 ID 動態重新對應至其他攝影機來源，請務必正確標示 CaptureResult.INFO_DEVICE_TYPE。

新增規定結束 (7.5 > C-1-6)

如果裝置實作項目支援 HDR 10 位元輸出功能，則：

  • [C-2-1] 必須為支援 10 位元輸出的每個攝影機裝置，至少支援 HLG HDR 設定檔。

  • [C-2-2] 必須支援主要後置或主要前置鏡頭的 10 位元輸出。

  • [C-SR-1] 強烈建議主要相機支援 10 位元輸出。

  • [C-2-3] 邏輯攝影機的所有BACKWARD_COMPATIBLE實體子攝影機和邏輯攝影機本身，都必須支援相同的 HDR 設定檔。

對於支援 10 位元 HDR 的邏輯相機裝置，如果實作 android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API，則：

  • [C-3-1] 必須支援透過邏輯相機上的 CONTROL_ZOOM_RATIO 控制項，在所有向後相容的實體相機之間切換。

7.5.1. 後置鏡頭

後置鏡頭是指朝向外部的鏡頭，可拍攝裝置遠側的場景，就像傳統相機一樣。在手持式裝置上，後置鏡頭位於螢幕對側。

裝置實作方式：

  • SHOULD 包含後置鏡頭。

如果裝置實作項目包含至少一個後置鏡頭，則：

  • [C-1-1] 必須回報功能旗標 android.hardware.camera 和 android.hardware.camera.any。

Android 17 移除的規定

  • [C-1-2] 解析度必須至少為 200 萬像素。

移除的規定結束 (7.5.1 > C-1-2)

  • 相機驅動程式「應」實作硬體自動對焦或軟體自動對焦 (對應用程式軟體而言是透明的)。

  • 可能具有定焦或 EDOF (擴展景深) 硬體。

  • 可能包含閃光燈。

如果攝影機有閃光燈：

  • [C-2-1] 在相機預覽畫面上註冊 android.hardware.Camera.PreviewCallback 例項時，閃光燈不得亮起，除非應用程式已透過啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，明確啟用閃光燈。請注意，這項限制不適用於裝置內建的系統相機應用程式，只適用於使用 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. 外接攝影機

外接式攝影機可隨時實體連接或卸除裝置，且可朝向任何方向，例如 USB 攝影機。

裝置實作方式：

  • 可能包括支援不一定總是連線的外接攝影機。

如果裝置實作項目包含外接攝影機支援，則：

  • [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 會向應用程式公開低階相機控制項，包括有效率的零複製連拍/串流流程，以及曝光、增益、白平衡增益、色彩轉換、去噪、銳利化等每格畫面控制項。

舊版 API 套件 android.hardware.Camera 在 Android 5.0 中標示為已淘汰，但應用程式仍應可使用。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 編碼格式，並以 byte[] 形式傳遞至 onPreviewFrame()。也就是說，NV21 必須是預設值。

  • [C-0-3] android.hardware.Camera 必須支援前置和後置鏡頭的 YV12 格式 (以 android.graphics.ImageFormat.YV12 常數表示)。(硬體視訊編碼器和攝影機可以使用任何原生像素格式，但裝置實作「必須」支援轉換為 YV12。)

  • [C-0-4] android.hardware.camera2 裝置透過 android.media.ImageReader API 輸出時，必須支援 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] MUST recognize and honor each parameter name defined as a constant in the android.hardware.Camera.Parameters class and the android.hardware.camera2.CaptureRequest class. 反之，裝置實作項目「不得」接受或辨識傳遞至 android.hardware.Camera.setParameters() 方法的字串常數，但 android.hardware.Camera.Parameters 上記錄為常數的字串常數除外。也就是說，如果硬體允許，裝置實作項目「必須」支援所有標準 Camera 參數，且「不得」支援自訂 Camera 參數類型。舉例來說，支援使用高動態範圍 (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 相機，做為實體子裝置。

如果裝置實作項目為第三方應用程式提供專屬的 Camera API，則：

Android 17 新增的規定

如果裝置實作項目調整第三方攝影機管道，使其與主要前置和後置攝影機的內建攝影機管道一致，則：

  • [C-2-1] 必須宣告 ro.camera.default_app_social_media_parity_enabled 系統屬性。

新增規定結束 (7.5.4 > C-2-1)

7.5.5. 攝影機方向

如果裝置實作項目有前置或後置鏡頭，這類鏡頭必須：

  • [C-1-1] 必須經過調整，讓相機的長邊對齊螢幕的長邊。也就是說，當裝置處於橫向模式時，相機必須以橫向模式擷取圖片。無論裝置的自然方向為何，這項規定都適用；也就是說，橫向主要裝置和直向主要裝置都適用。

    符合下列任一條件的裝置可免除這項規定：

    • 裝置採用可變幾何形狀的螢幕，例如摺疊式或鉸鏈式螢幕，且裝置的摺疊或鉸鏈狀態變更時，裝置會在直向主要和橫向主要 (或反之) 螢幕方向之間切換。

    • 使用者無法旋轉的裝置實作項目，例如車用裝置。

7.6. 記憶體與儲存空間

7.6.1. 記憶體和儲存空間下限

裝置實作方式：

  • [C-0-1] 必須包含下載管理員，應用程式可使用該管理員下載資料檔案，且必須能夠將至少 100 MB 的個別檔案下載至預設「快取」位置。

7.6.2. 應用程式共用儲存空間

裝置實作方式：

  • [C-0-1] MUST offer storage to be shared by applications, also often referred as "shared external storage", "application shared storage" or by the Linux path "/sdcard" it is mounted on.
  • [C-0-2] 必須預設掛接共用儲存空間，也就是「開箱即用」，無論儲存空間是實作在內部儲存空間元件或可移除式儲存媒體 (例如 Secure Digital 卡插槽) 上皆然。
  • [C-0-3] 必須直接在 Linux 路徑 sdcard 上掛接應用程式共用儲存空間，或在 sdcard 中加入 Linux 符號連結，指向實際掛接點。
  • [C-0-4] 對於指定 API 級別 29 以上的所有應用程式，預設「必須」啟用限定範圍儲存空間，但下列情況除外：
    • 應用程式已在資訊清單中要求 android:requestLegacyExternalStorage="true"。
  • [C-0-5] 透過 MediaStore 存取媒體檔案時，必須遮蓋儲存在這些檔案中的地點中繼資料 (例如 GPS Exif 標記)，但呼叫應用程式持有 ACCESS_MEDIA_LOCATION 權限時除外。

裝置實作「可能」會使用下列任一方式，滿足上述需求：

  • 使用者可存取的可卸除式儲存空間，例如 Secure Digital (SD) 卡插槽。
  • Android 開放原始碼計畫 (AOSP) 實作的內部 (不可移除) 儲存空間部分。

如果裝置實作項目使用可移除式儲存空間來滿足上述需求，則：

  • [C-1-1] 如果插槽中未插入儲存媒體，必須實作浮動式訊息或彈出式使用者介面，向使用者發出警告。
  • [C-1-2] 必須隨附 FAT 格式的儲存媒體 (例如 SD 卡)，或在購買時的包裝盒和其他材料上標示儲存媒體須另行購買。

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

  • 應使用內部應用程式共用儲存空間的 AOSP 實作方式。
  • 可能與應用程式私人資料共用儲存空間。

如果裝置實作項目具有支援 USB 周邊裝置模式的 USB 連接埠，則：

  • [C-3-1] MUST provide a mechanism to access the data on the application shared storage from a host computer.
  • 應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，公開這兩個儲存路徑的內容。
  • 可使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定來滿足這項需求。

如果裝置實作項目具有 USB 連接埠 (支援 USB 周邊模式) 且支援媒體傳輸通訊協定，則：

  • 應與參考 Android MTP 主機 (即 Android 檔案傳輸應用程式) 相容。
  • SHOULD report a USB device class of 0x00.
  • 應回報「MTP」的 USB 介面名稱。

7.6.3. 合併儲存空間

如果裝置預期會是行動裝置 (與電視不同)，則裝置實作方式如下：

  • [C-SR-1] 強烈建議在長期穩定的位置實作可攜式儲存空間，因為意外中斷連線可能會導致資料遺失/損毀。

如果可移除式儲存裝置連接埠位於長期穩定的位置，例如電池盒或其他保護蓋內，裝置實作方式如下：

7.7. USB

Android 17 新增的規定

定義

  • USB 主機模式是指裝置實作項目充當 USB 主機、在匯流排上供電，以及與周邊裝置通訊。

  • USB 裝置模式 (也稱為 USB 周邊模式) 是指裝置實作項目做為 USB 周邊裝置，透過上游連接埠連線至主機，並回應主機的要求。

  • USB 連接埠是指提供 USB 連線的機制，可以是實體 USB 插座，也可以是非標準介面 (例如彈簧針)。

新增規定結束 (7.7 USB 定義)

如果裝置實作項目有 USB 連接埠，則：

  • 應支援 USB 裝置模式。

  • 應支援 USB 主機模式。

  • SHOULD support disabling data signaling over USB.

7.7.1. USB 裝置模式

Android 17 中變更了需求條件的開始時間

如果裝置實作項目包含支援周邊 裝置模式的 USB 連接埠：

  • [C-1-1] 連接埠必須可連接至具有標準 A 型或 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] SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging specification, revision 1.2. 強烈建議現有和新的 Android 裝置符合這些需求，以便升級至未來的平台版本。

  • [C-SR-4] 強烈建議不要支援專有充電方法，因為這類方法會將 Vbus 電壓修改為超出預設等級，或變更接收器/來源角色，可能導致與支援標準 USB 電力傳輸方法的充電器或裝置發生互通性問題。雖然我們「強烈建議」這麼做，但日後 Android 版本可能會「要求」所有 Type-C 裝置完全支援標準 Type-C 充電器。

  • [C-SR-5] 如果支援 USB Type-C 和 USB 主機模式，強烈建議支援資料傳輸的電力傳輸功能，以及電力角色交換功能。

  • 應支援高電壓充電的電力傳輸，以及顯示輸出等替代模式。

  • 應實作 Android 開放式配件 (AOA) API 和規格，如 Android SDK 說明文件所述。

變更後的要求 (7.7.1 > C-1-1 至 C-SR-5)

如果裝置實作項目包含 USB 連接埠並實作 AOA 規格，則：

  • [C-2-1] MUST declare support for the hardware feature android.hardware.usb.accessory.
  • [C-2-2] USB 大量儲存類別的介面說明 iInterface 字串結尾必須包含「android」字串。

7.7.2. USB 主機模式

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

  • [C-1-1] 必須實作 Android USB 主機 API，如 Android SDK 中所述，且必須宣告支援硬體功能 android.hardware.usb.host。
  • [C-1-2] 必須導入支援，以連接標準 USB 周邊裝置。 他們必須具備下列其中一項條件：
    • 裝置端的 USB Type-C 連接埠，或隨附可將裝置專屬連接埠轉換為標準 USB Type-C 連接埠的傳輸線 (USB Type-C 裝置)。
    • 裝置上的 USB Type-A 連接埠，或隨附可將裝置上的專屬連接埠轉換為標準 USB Type-A 連接埠的傳輸線。
    • 裝置端的 micro-AB USB 連接埠，隨附的傳輸線應可轉接至標準 USB Type-A 連接埠。
  • [C-1-3] 不得隨附將 USB Type-A 或 micro-AB 連接埠轉換為 USB Type-C 連接埠 (插座) 的轉接器。
  • [C-SR-1] 建議您「強烈」導入 Android SDK 說明文件中所述的 USB 音訊類別。
  • 在主機模式下，應支援為連線的 USB 周邊裝置充電；宣傳至少 1.5A 的來源電流，如 USB Type-C Cable and Connector Specification Revision 1.2 的 Termination Parameters 一節所指定，適用於 USB Type-C 連接器，或使用 Charging Downstream Port (CDP) 輸出電流範圍，如 USB Battery Charging specifications, revision 1.2 所指定，適用於 Micro-AB 連接器。
  • 應實作並支援 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

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

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

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

  • [C-4-1] 必須實作 USB Type-C 規格 (第 4.5.1.3.3 節) 定義的雙重角色電源 (DRP) 功能。如果是 DRP 連接埠，在包含 3.5 公釐音訊插孔的裝置上，USB 電源接收器偵測 (主機模式) 可能預設為關閉，但使用者必須能夠啟用這項功能。
  • [C-SR-2] 強烈建議支援 DisplayPort。
    • 應支援 USB SuperSpeed 資料傳輸速率。
    • 強烈建議使用，以支援資料和電源角色交換的 Power Delivery。
  • [C-SR-3] 強烈建議不要支援「USB Type-C Cable and Connector Specification Revision 1.2」附錄 A 所述的音訊轉接頭配件模式。
  • 應實作最適合裝置外型的 Try.* 模型。舉例來說，手持裝置「應實作」Try.SNK 模型。

7.7.3. USB Power Delivery

Android 17 新增的規定

如果裝置實作項目包含 USB Type-C 連接埠，則：

  • [C-SR-1] 強烈建議實作核心的 USB Type-C 連接器類別，並實作說明 USB Type-C 連線、電源和資料角色的必要節點。如需實作詳細資料，請參閱 Android USB Type-C 說明文件。

如果裝置實作項目包含 USB Type-C 連接埠並支援 Power Delivery，則：

  • [C-SR-2] 強烈建議實作所有描述 USB Power Delivery 的節點。如要瞭解實作詳情，請參閱「Android USB PD 說明文件」。

如果裝置實作項目包含 USB Type-C 連接埠並支援替代模式，則：

  • [C-SR-3] 強烈建議實作核心 USB Type-C 連接器類別的替代模式和身分識別相關屬性。如需實作詳細資料，請參閱 Android USB Type-C 說明文件。

如果裝置實作項目包含 USB Type-C 連接埠，並支援 Thunderbolt 3 替代模式，則：

  • [C-SR-4] 強烈建議實作透過 Type-C 連接器類別覆寫目前替代模式的功能。

額外規定結束 (7.7.3 USB Power Delivery)

7.8. 音訊

7.8.1. 麥克風

如果裝置實作項目包含麥克風，則：

  • [C-1-1] 必須回報 android.hardware.microphone 功能常數。
  • [C-1-2] 必須符合第 5.4 節的音訊錄音規定。
  • [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
  • [C-SR-1] 強烈建議支援近超音波錄音，如第 7.8.3 節所述。

如果裝置實作項目省略麥克風，則：

  • [C-2-1] 不得回報 android.hardware.microphone 功能常數。
  • [C-2-2] 必須至少以無運算的形式實作音訊錄音 API，詳情請參閱第 7 節。

7.8.2. 音訊輸出裝置

如果裝置實作項目包含喇叭或音訊/多媒體輸出通訊埠，可供音訊輸出周邊裝置使用，例如 4 導體 3.5 公釐耳機插孔或使用 USB 音訊類別的 USB 主機模式通訊埠，則：

  • [C-1-1] 必須回報 android.hardware.audio.output 功能常數。
  • [C-1-2] 必須符合第 5.5 節的音訊播放規定。
  • [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
  • [C-SR-1] 強烈建議支援近超音波播放，如第 7.8.3 節所述。

如果裝置實作項目未包含喇叭或音訊輸出埠，則：

  • [C-2-1] 不得回報 android.hardware.audio.output 功能。
  • [C-2-2] 必須至少將音訊輸出相關 API 實作為無運算。

就本節而言，「輸出埠」是指實體介面，例如 3.5 公釐音訊插孔、HDMI 或 USB 主機模式通訊埠 (具備 USB 音訊類別)。透過藍牙、Wi-Fi 或行動網路等無線電通訊協定輸出音訊，不符合「輸出埠」的定義。

7.8.2.1. 類比音訊埠

為確保與 Android 生態系統中採用 3.5 公釐音訊插頭的耳機和其他音訊配件相容，如果裝置實作項目包含一或多個類比音訊連接埠，則：

  • [C-SR-1] 強烈建議至少包含一個 4 導體 3.5 公釐音訊插孔。

如果裝置實作項目有 4 芯 3.5 公釐音訊插孔，則：

  • [C-1-1] 必須支援立體聲耳機和立體聲耳麥 (含麥克風) 的音訊播放功能。
  • [C-1-2] 必須支援 CTIA 針腳順序的 TRRS 音訊插頭。
  • [C-1-3] 必須支援偵測及對應音訊插頭上麥克風和接地導體之間，以下 3 個範圍的等效阻抗：
    • 70 歐姆以下：KEYCODE_HEADSETHOOK
    • 210 至 290 歐姆：KEYCODE_VOLUME_UP
    • 360 至 680 歐姆：KEYCODE_VOLUME_DOWN
  • [C-1-4] MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack.
  • [C-1-5] 必須能夠在 32 歐姆的喇叭阻抗上，驅動至少 150mV ± 10% 的輸出電壓。
  • [C-1-6] 麥克風偏壓必須介於 1.8V 至 2.9V 之間。
  • [C-1-7] 必須偵測下列範圍的等效阻抗，並對應至音訊插頭上麥克風和接地導體的按鍵代碼：
    • 110 到 180 歐姆： KEYCODE_VOICE_ASSIST
  • [C-SR-2] 建議支援 OMTP 針腳順序的音訊插頭。
  • [C-SR-3] 建議支援透過附麥克風的立體聲耳機錄製音訊。

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

  • [C-2-1] MUST support the detection of microphone on the plugged in audio accessory.
7.8.2.2. 數位音訊埠

如需裝置專屬需求，請參閱第 2.2.1 節。

7.8.3. 近超音波

近超音波音訊的頻帶為 18.5 kHz 至 20 kHz。

裝置實作方式：

如果 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 範圍內，19 kHz 音調的訊號雜訊比 (未加權) 必須不低於 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

  • [C-2-1] 音箱在 18.5 kHz 至 20 kHz 的平均回應，必須比 2 kHz 的回應低 40 dB 以上。

7.8.4. 信號完整性

裝置實作方式：

  • 手持式裝置的輸入和輸出串流都應提供無故障的音訊訊號路徑，也就是在每條路徑一分鐘的測試中，測得的故障次數為零。使用 OboeTester 進行測試，並執行「Automated Glitch Test」。

測試時需要音訊回送 Dongle，可直接插入 3.5 公釐耳機插孔，或搭配 USB-C 對 3.5 公釐轉接器使用。應測試所有音訊輸出埠。

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

Perf Mode 分享 輸出取樣率 In Chans Out Chans
LOW_LATENCY 獨家 未指定 1 2
LOW_LATENCY 獨家 未指定 2 1
LOW_LATENCY 已分享的影片 未指定 1 2
LOW_LATENCY 已分享的影片 未指定 2 1
無 已分享的影片 48000 1 2
無 已分享的影片 48000 2 1
無 已分享的影片 44100 1 2
無 已分享的影片 44100 2 1
無 已分享的影片 16000 1 2
無 已分享的影片 16000 2 1

可靠的串流「應」符合下列訊號雜訊比 (SNR) 和總諧波失真 (THD) 的 2000 Hz 正弦波標準。

感應器 THD SNR
主要內建喇叭，使用外部參考麥克風測量 < 3.0% >= 50 dB
主要內建麥克風，使用外部參考音箱測量 < 3.0% >= 50 dB
內建類比 3.5 公釐插孔，已使用迴路轉接器測試 不到 1% >= 60 dB
手機隨附的 USB 轉接頭，已使用迴路轉接頭測試 < 1.0% >= 60 dB

7.9. 虛擬實境

Android 包含各種 API 和設施，可建構「虛擬實境」(VR) 應用程式，包括優質的行動 VR 體驗。裝置實作項目「必須」正確實作這些 API 和行為，詳情請參閱本節。

7.9.1. 虛擬實境模式

Android 支援虛擬實境模式，這項功能可處理通知的立體算繪作業，並在虛擬實境應用程式成為使用者焦點時，停用單眼系統 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] MUST support android.hardware.vulkan.level 0。
  • 應支援 android.hardware.vulkan.level 1 以上版本。
  • [C-1-6] 必須實作 EGL_KHR_mutable_render_buffer、 EGL_ANDROID_front_buffer_auto_refresh、 EGL_ANDROID_get_native_client_buffer、 EGL_KHR_fence_sync、 EGL_KHR_wait_sync、 EGL_IMG_context_priority、 EGL_EXT_protected_content、 EGL_EXT_image_gl_colorspace，並在可用 EGL 擴充功能清單中公開擴充功能。
  • [C-1-8] 必須實作 GL_EXT_multisampled_render_to_texture2、 GL_OVR_multiview、 GL_OVR_multiview2、 GL_EXT_protected_textures， 並在可用的 GL 擴充功能清單中公開擴充功能。
  • [C-SR-1] Are STRONGLY RECOMMENDED to implement GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, and expose the extensions in the list of available GL extensions.
  • [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 和螢幕必須能夠同步存取共用的前端緩衝區，以便以兩個算繪環境，以 60 FPS 的速度算繪 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] 必須支援 H.264 解碼，至少 3840 x 2160，30 fps， 壓縮至平均 40 Mbps (相當於 4 個 1920 x 1080 30 fps - 10 Mbps 的例項，或 2 個 1920 x 1080 60 fps - 20 Mbps 的例項)。
  • [C-1-12] 必須支援 HEVC 和 VP9，必須能夠解碼至少 1920 x 1080 (30 fps)，壓縮至平均 10 Mbps，且應能夠解碼 3840 x 2160 (30 fps，20 Mbps)，相當於 4 個 1920 x 1080 (30 fps，5 Mbps) 的執行個體。
  • [C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回準確的皮膚溫度值。
  • [C-1-14] 必須內嵌螢幕，且解析度必須至少為 1920 x 1080。
  • [C-SR-6] 強烈建議顯示器解析度至少為 2560 x 1440。
  • [C-1-15] 處於 VR 模式時，螢幕的更新率必須至少為 60 Hz。
  • [C-1-17] 螢幕必須支援低持久模式，持久度 ≤ 5 毫秒，持久度定義為像素發光的時間長度。
  • [C-1-18] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能 第 7.4.3 節。
  • [C-1-19] MUST support and properly report Direct Channel Type for all of the following default sensor types:
    • 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. 觸覺回饋

手持或穿戴式裝置可能包含一般用途的觸覺致動器，應用程式可透過鈴聲、鬧鐘、通知和一般觸覺回饋等方式，利用這類致動器吸引使用者注意。

如果裝置實作項目「未」包含這類一般用途的觸覺致動器，則：

  • [7.10/C] MUST return false for Vibrator.hasVibrator().

如果裝置實作「確實」包含至少一個這類一般用途的觸覺致動器，則：

如果裝置實作項目遵循觸覺常數對應，則：

7.11. 媒體成效類別

裝置實作的媒體效能類別可透過 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API 取得。從 Android R (版本 30) 開始，每個 Android 版本都定義了媒體效能類別的要求。特殊值 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 的檔案。
  • 隨機寫入效能。使用 4KB 寫入緩衝區寫入 256MB 檔案時測得。
  • 循序讀取效能。使用 10MB 的寫入緩衝區讀取 256MB 檔案時測得。
  • 隨機讀取效能。使用 4KB 寫入緩衝區讀取 256MB 檔案時測得。

8.3.省電模式

如果裝置實作項目包含 AOSP 提供的裝置電源管理改善功能 (例如應用程式待命值區、打盹)，或擴充這些功能以套用比「受限制」應用程式待命值區更嚴格的限制，則：

  • [C-1-1] 觸發、維護、喚醒演算法，以及使用全域系統設定或裝置設定，都不得偏離應用程式待命和螢幕關閉省電模式的 AOSP 實作方式。
  • [C-1-2] MUST NOT deviate from the AOSP implementation for the use of global settings or DeviceConfig to manage the throttling of jobs, alarm and network for apps in each bucket for App standby.
  • [C-1-3] 應用程式待命功能使用的應用程式待命值區數量不得與 AOSP 實作方式不同。
  • [C-1-4] 必須按照「電源管理」一文所述，實作應用程式待命儲存區和打盹模式。
  • [C-1-5] 裝置處於省電模式時，必須傳回 true，以表示 PowerManager.isPowerSaveMode()。
  • [C-1-6] 必須提供使用者功能提示，顯示所有豁免於應用程式待命和打盹省電模式或任何電池效能最佳化功能的應用程式，且必須實作 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 意圖，要求使用者允許應用程式忽略電池效能最佳化功能。
  • [C-SR-1] 強烈建議提供使用者介面，讓使用者啟用及停用省電模式。
  • [C-SR-2] 強烈建議提供使用者介面，顯示所有免除「應用程式待命」和「打盹」省電模式的應用程式。

如果裝置實作項目擴充了 AOSP 內含的電源管理功能，且擴充功能套用的限制比很少使用的應用程式待命值區更嚴格，請參閱第 3.5.1 節。

除了省電模式，Android 裝置實作「可能」會實作進階設定和電源介面 (ACPI) 定義的任何或所有 4 種休眠電源狀態。

如果裝置實作項目實作 ACPI 定義的 S4 電源狀態，則：

  • [C-1-1] 只有在使用者採取明確動作，將裝置設為非使用中狀態 (例如關上裝置實體零件的螢幕蓋，或關閉車輛或電視) 後，且在使用者重新啟動裝置 (例如打開螢幕蓋，或重新啟動車輛或電視) 前，才可進入此狀態。

如果裝置實作項目實作 ACPI 定義的 S3 電源狀態，則：

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

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

    舉例來說，第三方應用程式要求透過 FLAG_KEEP_SCREEN_ON 保持螢幕開啟，或透過 PARTIAL_WAKE_LOCK 保持 CPU 運作時，裝置不得進入 S3 狀態，除非使用者已明確採取動作，將裝置設為閒置狀態 (如 C-1-1 所述)。反之，當透過 JobScheduler 執行的第三方應用程式工作觸發時，或 Firebase 雲端通訊傳送至第三方應用程式時，裝置「必須」退出 S3 狀態，除非使用者已將裝置設為閒置狀態。這些並非完整範例，AOSP 會實作大量喚醒信號，從這個狀態觸發喚醒。

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 shell 指令，向應用程式開發人員提供這項電力用量資訊。
  • 如果無法將硬體元件耗電量歸因於應用程式，則應歸因於硬體元件本身。

8.5. 一致的效能

對於長時間執行的高效能應用程式，效能可能會大幅波動，原因可能是背景執行的其他應用程式，或是因溫度限制而導致 CPU 受到節流。Android 包含程式輔助介面，因此當裝置有能力時，最上層的前景應用程式可以要求系統最佳化資源分配，以因應這類波動。

裝置實作方式：

如果裝置實作項目回報支援持續效能模式，則：

  • [C-1-1] 應用程式要求時，必須為最上層的前景應用程式提供至少 30 分鐘的穩定效能。
  • [C-1-2] MUST honor the Window.setSustainedPerformanceMode() API and other related APIs.

如果裝置實作項目包含兩個以上的 CPU 核心，則：

  • SHOULD provide at least one exclusive core that can be reserved by the top foreground application.

如果裝置實作項目支援為頂層前景應用程式保留一個專屬核心，則：

  • [C-2-1] 必須透過 Process.getExclusiveCores() API 方法回報可供頂層前景應用程式預留的專屬核心 ID 編號。
  • [C-2-2] 除了應用程式使用的裝置驅動程式外，不得允許任何使用者空間程序在專屬核心上執行，但可視需要允許部分核心程序執行。

如果裝置實作項目不支援專屬核心，則：

8.6. 應用程式記憶體限制

Android 17 新增的規定

ActivityManagerService 的新元件 MemoryLimiter，以及衍生自可用實體記憶體的預設應用程式記憶體限制，會對每個應用程式程序使用的 DRAM 量設下限制。這項限制適用於應用程式程序中分配的所有記憶體，確保限制可做為應用程式開發人員的重要合約行為。

裝置實作方式：

  • [C-0-1] 不得使用任何方法、允許清單或政策，規避為應用程式設定的執行階段記憶體限制。

新增規定 (8.6 應用程式記憶體限制) 結束

9. 安全性模型相容性

裝置實作方式：

  • [C-0-1] MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs in the Android developer documentation.

  • [C-0-2] MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities.

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

  • [C-1-1] 必須支援下列小節列出的需求。

9.1. 權限

裝置實作方式：

  • [C-0-1] 必須支援 Android 開發人員說明文件中定義的 Android 權限模型和 Android 角色模型。具體來說，他們「必須」按照 SDK 說明文件中的說明，強制執行定義的每項權限和角色；不得省略、變更或忽略任何權限和角色。

  • 可新增其他權限，但新的權限 ID 字串不得位於 android.\* 命名空間。

  • [C-0-2] 具有 protectionLevel PROTECTION_FLAG_PRIVILEGED 的權限只能授予系統映像檔特殊權限路徑中預先安裝的應用程式 (以及 APEX 檔案)，且必須屬於每個應用程式明確允許的權限子集。AOSP 實作會從 etc/permissions/ 路徑中的檔案讀取並遵守每個應用程式允許的權限，並使用 system/priv-app 路徑做為特殊權限路徑，藉此符合這項規定。

  • [C-SR-1] protectionLevel 權限「強烈建議」僅授予下列對象： PROTECTION_SIGNATURE

    • 系統映像檔預先安裝的應用程式 (以及 APEX 檔案)。

    • 如果應用程式未納入系統映像檔，則會加入許可清單，並取得允許的權限。

防護等級為「危險」的權限是執行階段權限。如果應用程式的 targetSdkVersion 大於 22，則會在執行階段要求這些權限。

裝置實作方式：

  • [C-0-3] 必須顯示專屬介面，供使用者決定是否授予要求的執行階段權限，並提供管理執行階段權限的介面。

  • [C-0-5] 除非符合下列條件，否則不得將任何執行階段權限授予應用程式：

    • 裝置出貨時已安裝，且
    • 應用程式可先取得使用者同意聲明，再使用權限，

    或

  • [C-0-6] 只能將 android.permission.RECOVER_KEYSTORE 權限授予已註冊妥善保護的復原代理程式的系統應用程式。妥善保護的復原代理程式是指裝置端的軟體代理程式，可與裝置外的遠端儲存空間同步處理，並配備安全硬體，防護能力等同或優於 Google Cloud Key Vault 服務所述，可防範鎖定螢幕知識因素的暴力攻擊。

裝置實作方式：

  • [C-0-7] 應用程式透過標準 Android API 或專屬機制要求位置或體能活動資料時，必須遵守 Android 位置存取權屬性。這類資料包括但不限於：

    • 裝置位置 (例如經緯度)，如第 9.8.8 節所述。

    • 可用於判斷或估算裝置位置的資訊 (例如 SSID、BSSID、Cell ID，或裝置連線的網路位置)。

    • 使用者的體能活動或體能活動分類。

具體來說，裝置導入作業：

  • [C-0-8] 必須取得使用者同意，允許應用程式存取位置或體能活動資料。

  • [C-0-9] MUST grant a runtime permission ONLY to the app that holds sufficient permission as described on 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] MUST use the AppOpsManager APIs to record and track each and every programmatic access of data protected by dangerous permissions from Android activities and services.

  • [C-0-14] 只能將角色指派給功能符合角色需求的應用程式。

  • [C-0-15] 不得定義與平台定義的角色重複或功能超集的角色。

如果裝置包含可顯示健康相關生物特徵辨識資料 (例如心率或皮膚溫度) 的資料感應器，這些生物特徵辨識資料：

  • [C-0-16] MUST be guarded by platform permissions from android.permission-group.HEALTH, if there's a corresponding permission in HealthPermissions.

  • [C-0-17] 如果沒有平台權限符合所需的資料類型，則「必須」受自訂系統權限保護。例如 ELECTROCARDIOGRAM。

如果裝置回報 android.software.managed_users，表示：

  • [C-1-1] 不得由管理員在未經使用者同意的情況下授予下列權限：

    • 位置 (ACCESS_BACKGROUND_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_FINE_LOCATION)。
    • 相機 (CAMERA)
    • 麥克風 (RECORD_AUDIO)
    • 人體感應器 (BODY_SENSORS)
    • 健康 (HealthPermissions)
    • 體能活動 (ACTIVITY_RECOGNITION)

如果裝置回報 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 意圖的 Activity，選擇哪些應用程式可以在其他應用程式上繪製內容，則：

  • [C-2-1] MUST ensure that all activities with intent filters for the ACTION_MANAGE_OVERLAY_PERMISSION intent have the same UI screen, regardless of the initiating app or any information it provides.

如果裝置實作項目回報 android.software.device_admin，表示：

  • [C-3-1] 在完全受管理的裝置設定 (裝置擁有者設定) 期間，必須顯示免責事項，說明 IT 管理員可允許應用程式控制手機設定，包括麥克風、相機和位置資訊，並提供繼續設定或結束設定的選項，除非管理員已選擇不控管裝置權限。

如果裝置實作項目預先安裝的任何套件，包含「系統 UI 智慧功能」、「系統環境音訊智慧功能」、「系統音訊智慧功能」、「系統通知智慧功能」、「系統文字智慧功能」或「系統視覺智慧功能」角色，則這些套件：

9.2. UID 和程序隔離

裝置實作方式：

  • [C-0-1] 必須支援 Android 應用程式沙箱模型，其中每個應用程式都會以專屬的 Unix 樣式 UID 執行，並位於個別程序中。
  • [C-0-2] 必須支援以相同的 Linux 使用者 ID 執行多個應用程式，前提是應用程式已正確簽署及建構，如安全性與權限參考資料中所定義。

9.3. 檔案系統權限

裝置實作方式：

9.4. 替代執行環境

即使裝置實作項目包含執行應用程式的執行階段環境，且這些應用程式使用 Dalvik Executable Format 或原生程式碼以外的軟體或技術，也必須維持 Android 安全性和權限模型的一致性。簡單來說：

  • [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] 必須為每位使用者實作與 Android 平台安全模型一致的安全模型，如 API 中的「安全性與權限」參考文件所定義。

  • [C-1-3] 每個使用者執行個體都「必須」有獨立且隔離的共用應用程式儲存空間 (又稱 /sdcard) 目錄。

  • [C-1-4] MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to the files owned by any other user, even if the data of both users are stored on the same volume or file system.

  • [C-1-5] 如果裝置實作使用可移除式媒體做為外部儲存空間 API，則啟用多使用者功能時，必須使用僅儲存在系統可存取且不可移除式媒體上的金鑰，加密 SD 卡內容。因為這樣主機電腦就無法讀取媒體，裝置實作項目必須切換至媒體傳輸通訊協定或類似系統，才能讓主機電腦存取目前使用者的資料。

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

  • [C-2-1] MUST have separate and isolated shared application storage (a.k.a. /sdcard) directories for each user instance.

  • [C-2-2] MUST ensure that applications owned by and running on behalf of a given user cannot list, read, or write to the files owned by any other user, even if the data of both users are stored on the same volume or file system.

裝置實作「可以」為主要使用者 (且「只能」為主要使用者) 建立單一額外使用者設定檔 (類型為 android.os.usertype.profile.CLONE)，以便執行相同應用程式的雙重執行個體。這些雙重執行個體會共用部分隔離的儲存空間，同時在啟動器中向使用者顯示，並出現在相同的「最近」檢視畫面中。舉例來說，這項功能可用於支援使用者在雙 SIM 卡裝置上安裝單一應用程式的兩個不同執行個體。

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

  • [C-3-1] 只能提供存取權給父項使用者設定檔已可存取的儲存空間或資料，或是這個額外使用者設定檔直接擁有的儲存空間或資料。

  • [C-3-2] 不得將此做為工作資料夾。

  • [C-3-3] MUST have isolated private app data directories from the parent user account.

  • [C-3-4] 如果已佈建裝置擁有者 (請參閱 3.9.1 節)，則不得允許建立額外使用者設定檔，也不得允許佈建裝置擁有者，但須先移除額外使用者設定檔。

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

如果裝置實作項目建立上述額外使用者設定檔，且包含至少一部攝影機，並由預先安裝的攝影機應用程式處理 MediaStore.ACTION_MOTION_PHOTO_CAPTURE 或 MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE 意圖，則：

  • [C-5-1] 應用程式必須允許主要使用者處理來自其他使用者設定檔的意圖。

9.6. 付費簡訊警告

Android 支援向使用者發出警告，提醒他們注意任何傳送出去的付費簡訊。付費簡訊是指傳送給電信業者註冊服務的簡訊，使用者可能需要支付相關費用。

如果裝置實作項目聲明支援 android.hardware.telephony，則：

  • [C-1-1] MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. 上游 Android 開放原始碼計畫提供的實作方式符合這項需求。

9.7. 資安防護機制

裝置實作項目「必須」確保符合核心和平台中的安全防護功能，詳情如下。

Android 沙箱包含使用 Security-Enhanced Linux (SELinux) 強制存取控管 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中其他安全防護功能的功能。裝置實作方式：

  • [C-0-1] 即使在 Android 架構下方導入 SELinux 或任何其他安全防護功能，也必須維持與現有應用程式的相容性。

  • [C-0-2] 如果安全防護功能在 Android 框架下方偵測到並成功封鎖安全違規行為，則「不得」顯示使用者介面；但如果發生未封鎖的安全違規行為，導致成功遭到漏洞攻擊，則「可以」顯示使用者介面。

  • [C-0-3] 不得讓使用者或應用程式開發人員設定 Android 架構以下實作的 SELinux 或任何其他安全防護功能。

  • [C-0-4] 不得允許應用程式透過 API (例如裝置管理 API) 設定會導致相容性中斷的政策，進而影響其他應用程式。

  • [C-0-5] 必須將媒體架構分割成多個程序，以便根據 Android 開放原始碼計畫網站所述，為每個程序授予更精細的存取權。

  • [C-0-6] MUST implement a kernel application sandboxing mechanism which allows filtering of system calls using a configurable policy from multithreaded programs. 上游 Android 開放原始碼計畫會啟用 seccomp-BPF 並同步處理執行緒群組 (TSYNC)，以符合這項規定，詳情請參閱 source.android.com 的「Kernel Configuration」一節。

核心完整性和自我保護功能是 Android 安全性的重要環節。裝置實作方式：

  • [C-0-7] MUST implement kernel stack buffer overflow protection mechanisms. 這類機制包括 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。

  • [C-0-8] 必須實作嚴格的核心記憶體保護措施，確保可執行程式碼為唯讀、唯讀資料不可執行且不可寫入，以及可寫入資料不可執行 (例如同時啟用 rodata 和 CONFIG_STRICT_KERNEL_RWX)。

  • [C-0-9] 在原始出廠時搭載 API 級別 28 以上版本的裝置上，必須實作使用者空間和核心空間之間副本的靜態和動態物件大小界限檢查 (例如 CONFIG_HARDENED_USERCOPY)。

  • [C-0-10] 在核心模式下執行時 (例如透過硬體 PXN 或 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬)，不得在原先搭載 API 級別 28 以上版本的裝置上執行使用者空間記憶體。

  • [C-0-11] 在原始出貨時搭載 API 級別 28 以上版本的裝置上，不得在核心中讀取或寫入使用者空間記憶體，但透過正常 usercopy 存取 API (例如硬體 PAN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 則不在此限。

  • [C-0-12] 如果硬體容易受到 CVE-2017-5754 影響，且所有裝置原先搭載的 API 級別為 28 以上版本 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0)，則必須實作核心頁表隔離功能。

  • [C-0-13] 如果硬體容易受到 CVE-2017-5715 影響，則所有原先搭載 API 級別 28 以上版本 (例如 CONFIG_HARDEN_BRANCH_PREDICTOR) 的裝置，都必須實作分支預測強化功能。

  • [C-SR-1] 強烈建議在初始化後，將僅在初始化期間寫入的核心資料標示為唯讀 (例如 __ro_after_init)。

  • [C-SR-2] 強烈建議隨機安排核心程式碼和記憶體的版面配置，並避免可能影響隨機安排的曝光情況 (例如透過 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 使用開機載入程式熵)。CONFIG_RANDOMIZE_BASE

  • [C-SR-3] 強烈建議在核心中啟用控制流程完整性 (CFI)，進一步防範程式碼重用攻擊 (例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK)。

  • [C-SR-4] 強烈建議不要在已啟用控制流程完整性 (CFI)、影子呼叫堆疊 (SCS) 或整數溢位清除 (IntSan) 的元件上停用這些功能。

  • [C-SR-5] 強烈建議為任何其他安全敏感的使用者空間元件啟用 CFI、SCS 和 IntSan，如「CFI」和「IntSan」所述。

  • [C-SR-6] 建議啟用核心中的堆疊初始化，避免使用未初始化的本機變數 (CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO)。此外，裝置實作項目不應假設編譯器用於初始化本機變數的值。

  • [C-SR-7] 強烈建議在核心中啟用堆積初始化，防止使用未初始化的堆積分配 (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)，且不應假設核心用於初始化這些分配的值。

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

  • [C-1-1] 必須實作 SELinux。

  • [C-1-2] 必須將 SELinux 設為全域強制執行模式。

  • [C-1-3] 必須以強制執行模式設定所有網域。不允許使用寬鬆模式網域，包括裝置/供應商專屬網域。

Android 17 中變更了需求條件的開始時間

  • [C-1-4] 禁止事項：

    • 修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 提供的 system/sepolicy 資料夾中的 neverallow 規則
    • 將 AOSP SELinux 標籤不當附加至非 AOSP 元件

    政策必須遵守所有 neverallow 規則，包括 AOSP SELinux 網域和裝置/供應商專屬網域。

變更後的要求 (9.7 > C-1-4)

  • [C-1-5] MUST run third-party applications targeting API level 28 or higher in per-application SELinux sandboxes with per-app SELinux restrictions on each application's private data directory.

  • 應保留上游 Android 開放原始碼計畫系統/sepolicy 資料夾中提供的預設 SELinux 政策，並僅針對自家裝置專屬設定進一步新增這項政策。

如果裝置實作項目使用 Linux 以外的 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，ARMv8 裝置請使用 CONFIG_KASAN_SW_TAGS，其他裝置類型請使用 CONFIG_KASAN_GENERIC)。

  • [C-SR-12] 強烈建議在實際工作環境中使用記憶體錯誤偵測工具，例如 MTE、GWP-ASan 和 KFENCE。

如果裝置實作項目使用 Arm TrustZone 型 TEE，則：

  • [C-SR-13] 強烈建議使用標準通訊協定，在 Android 和 TEE 之間共用記憶體，例如 Arm Firmware Framework for Armv8-A (FF-A)。

  • [C-SR-14] 強烈建議限制信任的應用程式，只存取透過上述通訊協定明確與其共用的記憶體。如果裝置支援 Arm S-EL2 例外狀況層級，安全分割區管理員應會強制執行這項操作。否則，這項作業應由 TEE OS 強制執行。

記憶體安全技術是指在應用程式使用 android:memtagMode 資訊清單選項時，至少有 90% 以上的機率可減輕下列類別的錯誤：

  • 堆積緩衝區溢位
  • 釋放後使用
  • 重複釋放
  • 錯誤釋放 (釋放非 malloc 指標)

裝置實作方式：

  • [C-SR-15] Are STRONGLY RECOMMENDED to set ro.arm64.memtag.bootctl_supported.

如果裝置實作項目將系統屬性 ro.arm64.memtag.bootctl_supported 設為 true，則：

  • [C-3-1] 系統屬性 arm64.memtag.bootctl 必須接受以逗號分隔的下列值清單，並在下次重新啟動時套用所需效果：

    • memtag：已啟用上述定義的記憶體安全技術

    • memtag-once：暫時啟用上述記憶體安全技術，並在下次重新啟動時自動停用

    • memtag-off：已停用上述定義的記憶體安全技術

  • [C-3-2] MUST allow the shell user to set arm64.memtag.bootctl.

  • [C-3-3] MUST allow any process to read arm64.memtag.bootctl.

  • [C-3-4] 必須在啟動時將 arm64.memtag.bootctl 設為目前要求的狀態，如果裝置實作方式允許修改狀態而不變更系統屬性，也必須更新該屬性。

  • [C-SR-16] 建議顯示開發人員設定，設定 memtag-once 並重新啟動裝置。透過相容的開機載入程式，Android 開放原始碼計畫可透過 MTE 開機載入程式通訊協定滿足上述需求。

如果裝置聲明 android.hardware.telephony，支援無線電功能 CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK，且包含支援 2G 連線的行動數據機，則裝置實作方式：

9.8. 隱私權

9.8.1. 使用記錄

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

裝置實作方式：

  • [C-0-1] MUST keep a reasonable retention period of such user history.

  • [C-SR-1] 強烈建議保留 14 天的保留期限，這是 AOSP 實作中預設的設定。

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

裝置實作方式：

  • [C-0-2] 只能包含系統 API 類別 IncidentManager 建立的事故通報中標有 DEST_AUTOMATIC 的欄位。

  • [C-0-3] 不得使用系統事件 ID 記錄 SDK 文件StatsLog所述以外的任何其他事件。如果記錄其他系統事件，這些事件「可能」會使用 100,000 到 200,000 範圍內的不同原子 ID。

9.8.2. 錄影

裝置實作方式：

  • [C-0-1] 不得預先載入或散布軟體元件，在未經使用者同意或未顯示清楚的持續性通知的情況下，將使用者的私人資訊 (例如按鍵輸入、螢幕上顯示的文字、錯誤報告) 傳送至裝置外。

  • [C-0-2] 每次透過 MediaProjection.createVirtualDisplay() 或專有 API 啟用螢幕投放或螢幕錄製工作階段時，都必須顯示使用者警告訊息，並取得使用者明確同意，允許擷取使用者畫面上顯示的任何私密資訊。

  • [C-0-3] 啟用螢幕投放或螢幕錄製功能時，必須向使用者顯示持續性通知。AOSP 會在狀態列中顯示持續性通知圖示，以符合這項規定。

  • [C-SR-1] 強烈建議顯示使用者警告，該訊息與 Android 開放原始碼計畫 中實作的訊息完全相同，但可以修改，只要訊息清楚警告使用者，系統會擷取使用者螢幕上的任何機密資訊即可。

  • [C-0-4] Android 16 已移除這項規定。

裝置實作方式：

  • [C-0-7] 不得錄製、投影或投放敏感資訊，例如：

如果裝置實作項目包含系統中的功能，可擷取螢幕上顯示的內容，和/或透過系統 API ContentCaptureService 以外的方式錄製裝置播放的音訊串流，或是第 9.8.6 節「OS 層級和環境資料」所述的其他專屬方式，則：

  • [C-1-1] 啟用這項功能並主動擷取/錄製內容時，必須持續性向使用者發送通知。

如果裝置實作項目包含預設啟用的元件，能夠錄製環境音訊和/或錄製裝置播放的音訊，以推斷使用者情境的實用資訊，則：

  • [C-2-1] 除非使用者明確同意，否則不得將錄製的原始音訊或任何可轉換回原始音訊或近似音訊的格式，儲存在裝置的永久儲存空間或傳輸至裝置外。

「麥克風指標」是指螢幕上持續顯示且無法遮蔽的檢視畫面，讓使用者瞭解麥克風正在使用中(透過獨特的文字、顏色、圖示或組合)。

「相機指標」是指螢幕上持續顯示且無法遮蔽的檢視畫面，使用者可藉此瞭解相機是否正在使用中 (透過獨特的文字、顏色、圖示或組合)。

顯示一秒後，指標可能會在視覺上有所變化 (例如縮小)，不一定要按照原先呈現和理解的方式顯示。

麥克風指標可能會與主動顯示的攝影機指標合併，但前提是文字、圖示或顏色必須向使用者指出麥克風已開始使用。

如果文字、圖示或顏色會向使用者指出相機已開始使用，相機指標可以與目前顯示的麥克風指標合併。

如果裝置實作項目宣告 android.hardware.microphone，則：

  • [C-SR-1] 應用程式從麥克風存取音訊資料時，強烈建議顯示麥克風指標，但麥克風僅供 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或應用程式存取時，則不建議顯示麥克風指標。應用程式持有第 9.1 節「Permissions with CDD identifier [C-3-X]」中提及的角色時，也不建議顯示麥克風指標。

  • [C-SR-2] PermissionManager.getIndicatorAppOpUsageData() 傳回的「近期和使用中」應用程式清單，以及與這些應用程式相關的任何出處訊息，都「強烈建議」顯示。

  • [C-SR-3] 如果系統應用程式具有可見的使用者介面或直接使用者互動，強烈建議不要隱藏麥克風指標。

如果裝置實作項目宣告 android.hardware.camera.any，則：

  • [C-SR-4] 如果應用程式存取即時攝影機資料，強烈建議顯示相機指標，但如果應用程式僅存取 CDD 識別碼 [C-3-X] 第 9.1 節「權限」中列出的角色，則不需顯示相機指標。

  • [C-SR-5] 強烈建議使用 PermissionManager.getIndicatorAppOpUsageData() 傳回的攝影機，顯示「最近使用」和「使用中」應用程式，以及與這些應用程式相關聯的任何出處訊息。

  • [C-SR-6] 系統應用程式若有可見的使用者介面或直接使用者互動，強烈建議不要隱藏相機指標。

9.8.3. 連線能力

如果裝置實作項目具有支援 USB 周邊裝置模式的 USB 連接埠，則：

  • [C-1-1] 必須先顯示使用者介面，要求使用者同意，才能透過 USB 連接埠存取共用儲存空間的內容。

9.8.4. 網路流量

裝置實作方式：

  • [C-0-1] 必須預先安裝系統信任的憑證授權單位 (CA) 存放區的相同根憑證，如上游 Android 開放原始碼計畫提供。

  • [C-0-2] 必須隨附空白的使用者根 CA 存放區。

  • [C-0-3] 使用者新增根 CA 時，系統「必須」向使用者顯示警告，指出網路流量可能受到監控。

如果裝置流量是透過 VPN 傳輸，裝置實作項目會：

  • [C-1-1] 必須向使用者顯示警告，指出下列任一情況：
    • 該網路流量可能會受到監控。
    • 該網路流量會透過提供 VPN 的特定 VPN 應用程式轉送。

如果裝置實作項目預設啟用某種機制，可透過 Proxy 伺服器或 VPN 閘道 (例如預先載入已授予 android.permission.CONTROL_VPN 的 VPN 服務) 傳送網路資料流量，則：

  • [C-2-1] 啟用該機制前，必須徵求使用者同意，除非 VPN 是由裝置政策控制器透過 DevicePolicyManager.setAlwaysOnVpnPackage() 啟用，在這種情況下，使用者不需要另外同意，但必須收到通知。

如果裝置實作項目提供使用者切換第三方 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. 作業系統層級和環境資料保護機制

Android 透過系統 API 支援裝置實作機制，可擷取下列機密資料：

Android 17 中變更了需求條件的開始時間

  • 在畫面上顯示的文字和圖像，包括但不限於通知和輔助資料 (透過 AssistStructure API、擷取畫面緩衝區活動，以及錄製裝置畫面內容)。

變更後的要求 (9.8.6. 簡介)

  • 裝置錄製或播放的媒體資料，例如音訊或影片。

  • 輸入事件 (例如按鍵、滑鼠、手勢、語音、影片和無障礙功能)。

  • 透過 AugmentedAutofillService 傳送至系統的任何畫面或其他資料。

  • 透過 API Content Capture 存取的任何畫面或其他資料。

  • 透過 AppSearchManager API 傳遞至系統，且可透過 AppSearchGlobalManager.query 存取的任何應用程式資料。

  • 透過 TextClassifier API 傳送至系統 TextClassifier 的任何文字或其他資料，即傳送至系統服務，用於瞭解文字的意義，以及根據文字產生預測的後續動作。

  • 平台 AppSearch 實作項目建立索引的資料，包括但不限於文字、圖像、媒體資料或其他類似資料。

  • 使用 Speech Recognizer 實作 SpeechRecognizer#onDeviceSpeechRecognizer() 後取得的音訊資料。

  • 透過 AudioRecord、SoundTrigger或其他音訊 API 在背景 (持續) 取得音訊資料，且不會顯示使用者可見的指標

  • 透過 CameraManager 或其他 Camera API 在背景 (持續) 取得相機資料，但未顯示使用者可見的指標

Android 17 新增的規定

  • DynamicInstrumentationEventService擷取的任何資料

新增規定結束 (9.8.6 資料擷取)

Android 17 中變更了需求條件的開始時間

如果裝置實作項目擷取或分享上述私密資料，則： 如果沒有明確、獨立的使用者意圖或使用者可見的隱私權指標，就必須在受保護的執行環境中處理資料。這個環境：

  • [C-1-1] 儲存在裝置或傳輸中的所有這類資料都必須加密。這項加密作業可使用 Android 檔案加密功能，或Cipher SDK 中列為 API 26 以上版本的任何密碼。

  • [C-1-2] 不得使用Android 備份方法或任何其他備份方法備份原始或加密資料，如上述機密資料。

  • [C-1-3] 除非符合下列其中一項條件，否則「不得」將這類資料傳送至裝置外部：

    • 使用者明確啟動意圖 * 每次分享資料時，都會進行特定運算。

    • 使用隱私權保護機制，例如差異化隱私技術 (如 RAPPOR) 或機密聯合運算。

    • 資料會在受保護的執行環境中處理，防止服務供應商和基礎架構存取資料，例如禁止管理員存取、機密 VM、遠端認證、禁止私人資料輸出、停用記錄、IP 位址遮蔽和加密。

      • 凡是使用這個方法實作的項目，都必須提供讓使用者選擇停用的功能。

  • [C-1-3] MAY 會透過受信任的運算基礎雲端環境處理資料，保護資料免於服務供應商和基礎架構的侵害 (例如禁止管理員存取、機密 VM、遠端認證、禁止私人資料輸出、停用記錄、IP 遮蔽和加密)。使用這個方法的任何實作項目：
    • 必須提供使用者停用選項，且
    • 必須提供方法，讓使用者產生詳細且易於存取的記錄，瞭解環境的資料輸入和輸出情形。

  • [C-1-4] 不得將這類資料與裝置上的任何使用者身分 (例如 Account) 建立關聯，除非每次建立關聯時都取得使用者明確同意。

  • [C-1-4] MAY show this data on system owned UI surfaces.

  • [C-1-5] 不得分享或連結這類資料與任何使用者身分 (例如 Account)，除非每次分享時都取得使用者明確同意。每次連結資料時，或連結不會傳輸至其他不符合本節 (9.8.6 OS 層級和環境資料) 所述規定的 OS 元件時，都必須取得使用者明確同意。除非這類功能是做為 Android SDK API (AmbientContext、HotwordDetectionService)建構。

  • [C-1-6] 實作或專有方式在裝置或可信運算基礎雲端環境中以任何形式儲存資料時，必須提供使用者功能，以便清除這類資料。如果使用者選擇清除資料，系統「必須」移除所有收集到的歷來資料。

變更要求結束 (9.8.6 > C-1-1 至 C-1-6)

  • [C-1-7] MUST provide a user affordance to opt-out of the data, collected via AppSearch or proprietary means from being shown in Android platform (e.g., launcher).

Android 17 新增的規定

  • [C-1-8] 必須提供產生無障礙且詳盡記錄的方法，詳細說明環境中的資料輸入和輸出情形。

  • [C-1-9] 不得直接存取網際網路。

  • [C-1-10] MAY show UI remotely as long as no data is made visible to the host apk showing the UI.

  • [C-1-11] MUST keep the services separate from other system components (e.g. not binding the service or sharing process IDs with implementations not in the protected execution environment)。

  • [C-1-12] 只有在下列情況下，才可允許私密資料離開：

    • 每次分享資料時，都由使用者意圖* 明確啟動特定運算；或
    • 使用隱私權保護機制 (例如 RAPPOR / 機密聯合運算等差異化隱私技術)。

  • [C-1-13] MUST only allow exfiltration of sensitive data through:

    • 在 PCCSandbox 系統服務中允許的系統服務，且本身符合受保護執行環境 (9.8.6) 的規定，或
    • 指定的 Private Compute Core (PCC) 閘道 APK (定義於 9.8.15)。

  • [C-1-14] 除非經過端對端加密 (例如使用 Android Backup Service)，否則不得對從私密資料推斷出的資料執行雲端備份。

新增要求結束 (9.8.6 > C-1-8 至 C-1-14)

  • [C-SR-1] 強烈建議不要要求 INTERNET 權限。

  • [C-SR-2] 強烈建議僅透過結構化 API 存取網際網路，這些 API 應以公開可用的開放原始碼實作項目為基礎。

  • [C-SR-4] 強烈建議使用 Android SDK API 或類似的 OEM 擁有的開放原始碼存放區實作；和 / 或在沙箱實作中執行 (請參閱 9.8.15 沙箱 API 實作)。

Android 17 中變更了需求條件的開始時間

如果裝置實作項目包含實作 System API ContentCaptureService、AppSearchManager.index、DynamicInstrumentationEventService 的服務，或是擷取上述資料的任何專有服務，則：

  • [C-2-1] 不得允許使用者以可安裝的應用程式或服務取代服務，且只能允許預先安裝的服務擷取這類資料。

  • [C-2-2] 除了預先安裝的服務機制，不得允許任何應用程式擷取這類資料。

  • [C-2-3] 必須提供清楚且容易存取的使用者功能提示，讓使用者停用服務。

  • [C-2-4] 不得省略使用者管理服務所持有的 Android 權限的功能提示，且必須遵循第 9.1 節所述的 Android 權限模型。權限。

  • [C-SR-3] 強烈建議將服務與其他系統元件分開 (例如不繫結服務或共用程序 ID)，但下列情況除外：

    • 電話、聯絡人、系統 UI 和媒體

變更後的要求 (9.8.6 > C-2-1 至 C-SR-3)

9.8.7. 剪貼簿存取權

裝置實作方式：

  • [C-0-1] 除非第三方應用程式是預設 IME 或目前焦點所在的應用程式，否則「不得」從剪貼簿傳回剪下的資料 (例如透過 ClipboardManager API)。

  • [C-0-2] 必須在最後一次放置或讀取剪貼簿資料後，最多 60 分鐘內清除剪貼簿資料。

9.8.8. 位置

位置資訊包括 Android Location 類別中的資訊( 例如緯度、經度、海拔高度)，以及可轉換為位置資訊的 ID。位置資訊的精確度可以達到 DGPS (差分全球定位系統) 程度，也可以粗略到國家/地區層級的位置資訊 (例如國家/地區代碼位置資訊 - MCC - 行動國家/地區代碼)。

以下列出可直接推導使用者位置，或可轉換為使用者位置的類型。這份清單並不完整，但可做為範例，說明可直接或間接推導出位置資訊的項目：

  • GPS/GNSS/DGPS/PPP

    • 全球定位解決方案、全球導航衛星系統或差分全球定位解決方案
    • 這也包括原始全球導航衛星系統測量資料和全球導航衛星系統狀態
      • 可從原始全球導航衛星系統測量資料取得精確位置

  • 具有專屬 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] MUST ensure that the application using Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() is a user initiated emergency session (e.g., dial 911 or text to 911). 不過，在 Automotive 中，如果偵測到車禍/事故 (例如為了滿足 eCall 需求)，車輛「可能」會在沒有使用者主動互動的情況下啟動緊急工作階段。

  • [C-0-4] MUST preserve the Emergency Location Bypass APIs ability to bypass device location settings without changing the settings.

  • [C-0-5] 應用程式在背景中使用 ACCESS_BACKGROUND_LOCATION 權限存取使用者位置資訊後，必須排定通知，提醒使用者這項行為。

Android 17 新增的規定

當非系統前景應用程式在前台存取裝置的精確位置時，裝置會：

  • [C-SR-1] 強烈建議顯示使用者可見的指標

新增規定結束 (9.8.8 > C-1-1)

9.8.9. 已安裝的應用程式

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

裝置實作方式：

  • [C-0-1] 不得向指定 API 級別 30 以上版本的應用程式公開任何其他已安裝應用程式的詳細資料，除非該應用程式已可透過受管理 API 查看其他已安裝應用程式的詳細資料。包括但不限於裝置實作者新增的任何自訂 API 所公開的詳細資料，或可透過檔案系統存取的詳細資料。

  • [C-0-2] 不得授予任何應用程式讀取或寫入權限，存取外部儲存空間中其他應用程式的專屬應用程式特定目錄內的檔案。例外狀況如下：

    • 外部儲存空間供應商授權單位 (例如 DocumentsUI 等應用程式)。

    • 下載供應器，使用「downloads」供應器授權，將檔案下載至應用程式儲存空間。

    • 使用具備特殊權限 ACCESS_MTP 的平台簽署媒體傳輸通訊協定 (MTP) 應用程式，可將檔案傳輸至其他裝置。

    • 安裝其他應用程式且具備 INSTALL_PACKAGES 權限的應用程式，只能存取「obb」目錄，以管理 APK 擴充檔案。

9.8.10. 連線錯誤報告

如果裝置實作項目聲明 android.hardware.telephony 功能旗標，則：

  • [C-1-1] MUST support generating connectivity bug reports via BUGREPORT_MODE_TELEPHONY with BugreportManager.

  • [C-1-2] 每次使用 BUGREPORT_MODE_TELEPHONY 產生報表時，都必須取得使用者同意聲明，且不得提示使用者同意應用程式日後的所有要求。

  • [C-1-3] 未經使用者明確同意，不得將產生的報表傳回要求應用程式。

  • [C-1-4] 使用 BUGREPORT_MODE_TELEPHONY 產生的報表「必須」包含至少下列資訊：

    • TelephonyDebugService傾印
    • TelephonyRegistry傾印
    • WifiService傾印
    • ConnectivityService傾印
    • 呼叫套件的 CarrierService 例項傾印 (如已繫結)
    • 無線電記錄緩衝區
    • SubscriptionManagerService傾印

  • [C-1-5] 生成的報表不得包含下列內容：

    • 與連線偵錯無直接關聯的任何資訊。

    • 使用者安裝的任何應用程式流量記錄，或使用者安裝的應用程式/套件詳細設定檔 (UID 沒問題，但套件名稱不行)。

  • 可能包含與任何使用者身分無關的額外資訊。(例如供應商記錄檔)。

如果裝置實作項目在錯誤報告中包含其他資訊 (例如供應商記錄)，且這些資訊會影響隱私權/安全性/電池/儲存空間/記憶體，則：

  • [C-SR-1] STRONGLY RECOMMENDED to have a developer setting defaulted to disabled. AOSP 參考實作方案可滿足這項需求，方法是在開發人員設定中提供 Enable verbose vendor logging 選項，將其他裝置專屬供應商記錄納入錯誤報告。

9.8.11. 共用資料 blob

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

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

9.8.12. 音樂辨識

Android 透過系統 API MusicRecognitionManager 支援一種機制，讓裝置實作項目可根據音訊記錄要求音樂辨識，並將音樂辨識作業委派給實作 MusicRecognitionService API 的特殊權限應用程式。

如果裝置實作項目包含實作 System API MusicRecognitionManager 的服務，或是任何會串流音訊資料的專有服務 (如上所述)，則：

  • [C-1-1] MUST enforce that the caller of MusicRecognitionManager holds the MANAGE_MUSIC_RECOGNITION permission

  • [C-1-2] 必須強制規定單一預先安裝的音樂辨識應用程式實作 MusicRecognitionService。

  • [C-1-3] 不得允許使用者以可安裝的應用程式或服務，取代 MusicRecognitionManagerService 或 MusicRecognitionService。

  • [C-1-4] MUST ensure that when MusicRecognitionManagerService accesses the audio record and forwards it to the application implementing the MusicRecognitionService, the audio access is tracked via invocations of 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.8.14. 不適用

9.8.15. Private Compute Core 和 Gateway 應用程式實作項目

Android 17 中變更了需求條件的開始時間

Android 透過一組委派 API 提供機制，可處理安全的 OS 層級和環境資料。這類處理作業可委派給預先安裝的 APK，該 APK 具有特殊權限存取權和簡化的通訊功能，稱為「Sandboxed API 實作」。

如果裝置實作項目包含應用程式，且應用程式會對第 9.8.6 節 (OS 層級和環境資料) 所述的私密資料執行裝置端處理作業，強烈建議使用下文所述的 Private Compute Core (PCC) 架構。

PCC 環境中的任何沙箱化 API 實作 元件：

  • [C-0-1] 不得要求 INTERNET 權限。

  • [C-0-1] 必須在資訊清單宣告中，使用 android:isPrivateComputeCoreProcess="true" 屬性進行宣告。

  • [C-0-2] 只能透過結構化 API 存取網際網路，且這些 API 必須以公開發布的開放原始碼實作項目為基礎，並使用隱私權保護機制，或透過 Android SDK API 間接存取網際網路。隱私權保護機制定義為「僅允許匯總分析，並防止記錄的事件或衍生結果與個別使用者相符」，以防止任何使用者資料可供檢查 (例如使用 RAPPOR 等差異化隱私權技術實作)。

  • [C-0-2] 必須預先載入裝置系統映像檔。

  • [C-0-3] 服務必須與其他系統元件分開 (例如，不得繫結服務或共用程序 ID，但下列情況除外：

    • 電話、聯絡人、系統 UI 和媒體 (實作項目並非以 PCC UID 執行)。

  • [C-0-4] 不得允許使用者以可安裝的應用程式或服務取代服務

  • [C-0-5] 只能允許原始設備製造商 (OEM) 指派的預先安裝服務 (持有 PCC 管理員系統服務中定義的適當系統角色)，以及具備適當權限的服務 擷取這類資料。除非替代功能已內建於 Android 開放原始碼計畫 (例如數位助理應用程式)，否則請勿存取 9.8.6 節所述的敏感環境資料。

  • [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. 除非這類擷取功能是透過 Android SDK API 實作。

  • [C-0-7] 必須提供使用者介面，讓使用者停用服務。

  • [C-0-8] 不得省略使用者管理服務所持有的 Android 權限的功能提示，且必須遵循第 9.1 節所述的 Android 權限模型。權限。

  • [C-0-9] 必須在專屬程序中執行，且具有架構指派的專屬 UID，與主要應用程式程序和其他沙箱元件分開。

變更後的要求 (9.8.15 > C-0-1 至 C-1-4)

Android 17 新增的規定

PCC 環境元件所需的任何網路存取權，都必須透過指定 APK (做為 PCC 閘道應用程式) 進行 Proxy。指定元件：

  • [C-1-1] 必須取得 android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES 權限。這項權限會將應用程式指定為 PCC 閘道應用程式。

  • [C-1-2] 必須提供原始碼，供大眾驗證。

  • [C-1-3] 必須針對任何資料輸出使用隱私權保護機制，如第 9.8.6 節所述

  • [C-1-4] 必須支援 PCC 架構的稽核模式，包括在啟用時記錄網路要求、伺服器端點，以及其他與驗證隱私權保護行為相關的資料

新增規定結束 (9.8.15 > C-1-1 至 C-1-4)

9.8.16. 持續音訊和攝影機資料

如果裝置實作項目擷取第 9.8.2 節或第 9.8.6 節所述的任何資料，且這類實作項目使用透過 AudioRecord、SoundTrigger 或其他音訊 API 在背景 (持續) 取得的音訊資料，或是透過 CameraManager 或其他相機 API 在背景 (持續) 取得的相機資料，則：

  • [C-0-1] 除非符合下列情況，否則必須強制顯示相應指標 (相機和/或麥克風，如第 9.8.2 節「錄音」所述)：

  • [C-SR-1] 強烈建議要求使用者同意，才能使用任何會用到這類資料的功能，且預設為停用。

  • [C-SR-2] 強烈建議對來自遠端穿戴式裝置的攝影機資料，採取相同的處理方式 (即遵守 9.8.2 錄音、9.8.6 作業系統層級和環境資料、9.8.15 沙箱化 API 實作項目，以及 9.8.16 連續音訊和攝影機資料中列出的限制)。

如果裝置實作項目從遠端穿戴式裝置接收攝影機或麥克風資料，且資料在 Android 作業系統外部以未加密形式存取，或是由 WearableSensingManager 建構的沙箱化實作項目或沙箱化功能存取，則：

  • [C-1-1] MUST 指示遠端穿戴式裝置顯示額外指標。

如果裝置提供與數位助理應用程式互動的功能，且不需要使用指派的關鍵字 (可處理一般使用者查詢，或透過攝影機分析使用者是否在場)，則：

  • [C-2-1] MUST ensure such implementation is provided by a package holding the android.app.role.ASSISTANT role.

  • [C-2-2] 必須確保這類實作項目使用 HotwordDetectionService 和/或 VisualQueryDetectionService Android API。

9.8.17. 遙測

Android 會使用 StatsLog API 儲存系統和應用程式記錄。這些記錄由 StatsManager API 管理，可供具備權限的系統應用程式使用。

StatsManager 也提供從裝置收集隱私權敏感資料的方法，並採用隱私權保護機制。特別是，StatsManager::query API 可查詢在 StatsLog 中定義的受限指標類別。

任何從 StatsManager 查詢及收集受限指標的實作項目：

  • [C-0-1] 裝置上必須只有這項應用程式/實作項目，且必須持有 READ_RESTRICTED_STATS 權限。

  • [C-0-2] 只能使用隱私權保護機制傳送遙測資料和裝置記錄。隱私保護機制定義為「僅允許匯總分析，並防止記錄的事件或衍生結果與個別使用者相符」，以避免任何使用者層級資料可供檢查 (例如使用差異化隱私技術 (如 RAPPOR) 實作)。

  • [C-0-3] 不得將這類資料與裝置上的任何使用者身分 (例如帳戶) 建立關聯。

  • [C-0-4] 不得與不符合本節 (9.8.17 節) 規定之其他 OS 元件分享這類資料。遙測)。

  • [C-0-5] 必須提供使用者介面，讓使用者啟用/停用隱私權保護的遙測資料收集、使用及分享功能。

  • [C-0-6] 如果實作項目收集的資料以任何形式儲存在裝置上，則「必須」提供使用者功能來清除這類資料。如果使用者選擇清除資料，則必須移除裝置目前儲存的所有資料。

  • [C-0-7] 必須在開放原始碼存放區中揭露基礎隱私權保護通訊協定實作項目。

  • [C-0-8] MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog.

9.8.18. 代理函式隱私權

Android 17 新增的規定

裝置實作方式：

  • [C-0-1] MUST ensure any components executing AppFunctions hold either the EXECUTE_APP_FUNCTIONS or the EXECUTE_APP_FUNCTIONS_SYSTEM permission.

  • [C-0-2] 只能直接因應使用者明確操作而呼叫 AppFunction，且必須清楚向使用者指出要呼叫的應用程式，以及要在該應用程式中執行的主要動作。

  • [C-0-3] 不得代理或修改第三方應用程式的請求，以探索或執行 AppFunctions，除非符合 [C-0-1] 和 [C-0-2] 的規定。

  • [C-0-4] 除非系統元件在 9.8.6 中定義的受保護執行環境中運作，否則不得允許系統元件使用敏感的 OS 層級或環境資料 (如 9.8.6 OS 層級和環境資料保護措施中所定義) 或衍生資料，產生或參數化提醒。

新增需求條件 (9.8.18 > Agentic Functions Privacy)

9.9. 資料儲存加密

所有裝置都必須符合第 9.9.1 節的規定。如果裝置發布時的 API 級別早於本文件，則可免除 9.9.2 和 9.9.3 節的規定，但必須符合 Android 相容性定義文件 9.9 節的規定，且該文件對應的 API 級別為裝置發布時的級別。

9.9.1. 直接啟動

裝置實作方式：

9.9.2. 加密規定

裝置實作方式：

  • [C-0-1] 如果應用程式私人資料 (/data 分區) 和應用程式共用儲存空間分區 (/sdcard 分區) 是裝置的永久性部分，則必須加密。
  • [C-0-2] 使用者完成開箱設定體驗時，裝置預設必須啟用資料儲存加密功能。

  • [C-0-3] 必須實作下列兩種加密方法之一，以符合上述資料儲存加密規定：

9.9.3. 加密方法

如果裝置實作項目經過加密，則：

  • [C-1-1] 必須啟動，且不得要求使用者提供憑證，並在廣播 ACTION_LOCKED_BOOT_COMPLETED 訊息後，允許直接啟動感知應用程式存取裝置加密 (DE) 儲存空間。

  • [C-1-2] 在滿足以下條件前，不得允許存取憑證加密 (CE) 儲存空間：

    • 使用者透過主要驗證方法 (例如密碼、解鎖圖案或 PIN 碼) 解鎖裝置。
    • ACTION_USER_UNLOCKED 訊息已廣播。

  • [C-1-13] 不得提供任何方法，在沒有使用者提供的憑證、已註冊的保管金鑰，或符合第 9.9.4 節規定的重新啟動後繼續執行實作的情況下，解鎖 CE 保護的儲存空間。

  • [C-1-4] 必須使用驗證開機程序。

9.9.3.1. 檔案型加密搭配中繼資料加密

如果裝置實作項目使用檔案型加密搭配中繼資料加密，則：

  • [C-1-5] 必須使用 AES-256-XTS 或 Adiantum 加密檔案內容和檔案系統中繼資料。AES-256-XTS 是指以 XTS 模式運作的進階加密標準，加密金鑰長度為 256 位元；金鑰的完整長度為 512 位元。Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 所述。檔案系統中繼資料是指檔案大小、擁有權、模式和擴充屬性 (xattrs) 等資料。
  • [C-1-6] 必須使用 AES-256-CBC-CTS、AES-256-HCTR2 或 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) 的組合加密，而這些組合取決於檔案和檔案中的偏移。此外，所有這類組合都必須不重複，但如果加密作業是使用僅支援 32 位元 IV 長度的內嵌加密硬體完成，則不在此限。
  • [C-1-16] 必須確保不同目錄中所有未刪除的加密檔案名稱，都是使用不同的加密金鑰和初始化向量 (IV) 組合加密。

  • [C-1-17] 必須確保永久儲存空間上的所有加密檔案系統中繼資料區塊，都是使用不同的加密金鑰和初始化向量 (IV) 組合加密。

  • 保護 CE 和 DE 儲存空間以及檔案系統中繼資料的金鑰：

    • [C-1-7] 必須以加密編譯方式繫結至採用專屬硬體的金鑰儲存區。這個金鑰儲存區「必須」繫結至驗證開機程序和裝置的硬體信任根。
    • [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
    • [C-1-9] 如果使用者尚未指定螢幕鎖定憑證，CE 金鑰必須繫結至預設密碼。
    • [C-1-10] 必須是獨一無二，也就是說，任何使用者的 CE 或 DE 金鑰不得與其他使用者的 CE 或 DE 金鑰相符。
    • [C-1-11] 必須使用強制支援的密碼、金鑰長度和模式。
    • [C-1-12] 系統啟動載入程式解鎖和鎖定期間，必須安全清除資料，詳情請參閱這篇文章。

  • 應讓預先安裝的必要應用程式 (例如「鬧鐘」、「電話」、「訊息」) 支援直接啟動。

上游 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] 必須以加密編譯方式繫結至採用專屬硬體的金鑰儲存區。這個金鑰儲存區「必須」繫結至驗證開機程序和裝置的硬體信任根。
    • [C-1-6] 必須繫結至相應使用者的螢幕鎖定憑證。

您可以使用 Linux 核心的「dm-crypt」功能，透過使用者專屬磁碟分割區，實作使用者專屬的區塊層級加密。

9.9.4. 重新啟動後繼續播放

透過「重新啟動後繼續」功能，您可以在 OTA 啟動的重新啟動後，解鎖所有應用程式的 CE 儲存空間，包括尚未支援直接啟動的應用程式。這項功能可讓使用者在重新啟動後，繼續接收已安裝應用程式的通知。

實作「重新啟動後繼續」功能時，必須繼續確保裝置落入攻擊者手中時，即使裝置已開機、CE 儲存空間已解鎖，且使用者在收到 OTA 後已解鎖裝置，攻擊者也極難復原使用者以 CE 加密的資料。為防範內部攻擊，我們也假設攻擊者取得廣播加密簽署金鑰的存取權。

具體內容如下：

  • [C-0-1] 即使攻擊者實際持有裝置，且具備下列功能和限制，也「不得」讀取 CE 儲存空間：

    • 可使用任何供應商或公司的簽署金鑰，簽署任意訊息。
    • 可讓裝置接收 OTA。
    • 可修改任何硬體 (AP、快閃等) 的運作方式，但須遵守下列詳細說明。這類修改作業至少會延遲一小時，且會進行電源重啟，導致 RAM 內容遭到破壞。
    • 無法修改防竄改硬體 (例如 Titan M) 的運作方式。
    • 無法讀取即時裝置的 RAM。
    • 無法取得使用者憑證 (PIN 碼、解鎖圖案、密碼)，或以其他方式導致使用者輸入憑證。

舉例來說，如果裝置實作項目實作並遵守這裡的所有說明，就會符合 [C-0-1] 規定。

9.10. 裝置完整性

下列規定可確保裝置完整性狀態資訊公開透明。裝置實作方式：

  • [C-0-1] 必須透過 System API 方法正確回報，PersistentDataBlockManager.getFlashLockState()啟動載入程式狀態是否允許刷新系統映像檔。

  • [C-0-2] 必須支援驗證開機程序，確保裝置完整性。

如果裝置實作項目已推出，但較舊版 Android 不支援驗證開機程序，且無法透過系統軟體更新新增這項功能，則可能可免除這項規定。

驗證開機程序功能可確保裝置軟體的完整性。如果裝置實作支援這項功能，則：

  • [C-1-1] 必須宣告平台功能旗標 android.software.verified_boot。
  • [C-1-2] 必須在每個啟動程序中執行驗證。
  • [C-1-3] 必須從不可變更的硬體金鑰 (信任根) 開始驗證，一路向上驗證至系統分區。
  • [C-1-4] MUST 實作每個驗證階段，以檢查下一個階段中所有位元組的完整性和真實性，然後再執行下一個階段的程式碼。
  • [C-1-5] 必須使用與 NIST 目前建議的雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 同等強大的驗證演算法。
  • [C-1-6] 系統驗證失敗時，不得允許完成啟動程序，除非使用者同意嘗試啟動，在這種情況下，不得使用任何未經驗證的儲存區塊資料。
  • [C-1-7] 除非使用者已明確解鎖開機載入程式，否則不得允許修改裝置上已驗證的分割區。
  • [C-1-8] 必須使用防竄改儲存空間：用於儲存開機載入程式是否已解鎖。防竄改儲存空間是指開機載入程式可偵測儲存空間是否已從 Android 內部遭到竄改。
  • [C-1-9] 必須在使用者使用裝置時提示，並要求實際確認，才能從系統啟動載入程式鎖定模式轉換為系統啟動載入程式解鎖模式。
  • [C-1-10] 必須為 Android 使用的分割區 (例如開機、系統分割區) 實作回溯保護機制，並使用防竄改儲存空間儲存用於判斷最低允許 OS 版本的相關中繼資料。

  • [C-1-11] 必須在解鎖和鎖定開機載入程式期間，根據「9.12.」安全地清除所有使用者資料。資料刪除」(包括使用者資料分割區和任何 NVRAM 空間)。

  • [C-1-14] 對於系統設定中列為 require-strict-signature 的許可清單套件，每次啟動時都必須至少驗證一次簽章。

  • [C-SR-2] 強烈建議使用以「驗證開機程序」保護的分區為基礎的信任鏈結，驗證所有具備特殊權限的應用程式 APK 檔案。

  • [C-SR-3] 強烈建議您先驗證權限較高的應用程式從 APK 檔案外部載入的可執行構件 (例如動態載入的程式碼或編譯的程式碼)，再執行這些構件，或強烈建議您完全不要執行這些構件。

  • 對於任何具有持續性韌體 (例如數據機、攝影機) 的元件，都應實作回溯保護機制，並應使用防竄改儲存空間，儲存用於判斷最低允許版本的相關中繼資料。

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

如果裝置實作項目能夠逐頁驗證檔案內容，則：

  • [C-2-1] 支援以加密方式驗證檔案內容，不必讀取整個檔案。

  • [C-2-2] 如果讀取內容未按照上述 [C-2-1] 驗證，則不得允許對受保護檔案的讀取要求成功。

  • [C-2-4] 必須針對已啟用的檔案，以 O(1) 傳回檔案總和檢查碼。

如果裝置實作項目已發布，但無法在較早的 Android 版本中，根據信任的金鑰驗證檔案內容，且無法透過系統軟體更新新增這項功能，則可能可豁免此規定。上游 Android 開放原始碼計畫會根據 Linux 核心 fs-verity 功能，提供這項功能的偏好實作方式。

9.11. 金鑰和憑證

Android Keystore 系統可讓應用程式開發人員將加密編譯金鑰儲存在容器中，並透過 KeyChain API 或 Keystore API 將金鑰用於加密編譯作業。裝置實作方式：

  • [C-0-1] 必須允許匯入或產生至少 8,192 個金鑰。

  • [C-0-2] 螢幕鎖定驗證「必須」在驗證失敗後間隔一段時間才能再次嘗試。如果 n 是失敗嘗試次數，且 9 < n < 30，時間間隔必須至少為 30 秒。如果 n > 29，時間間隔值必須至少為 30*2^floor((n-30)/10) 秒或至少 24 小時，取較小者。

  • SHOULD not limit the number of keys that can be generated.

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

  • [C-1-1] MUST back up the keystore implementation with an isolated execution environment.

Android 17 中變更了需求條件的開始時間

  • [C-1-2] 必須實作 RSA、AES、ECDSA、ECDH (如果支援 IKeyMintDevice)、3DES 和 HMAC 加密演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式 支援的 IKeyMintDevice 或 IKeymasterDevice 版本所需的加密演算法和雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離「必須」封鎖所有可能機制，避免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目來滿足這項需求，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當 Hypervisor 型隔離安全實作項目。

變更後的要求 (9.11 > C-1-2)

  • [C-1-3] MUST 在隔離的執行環境中執行螢幕鎖定驗證，且只有在驗證成功時，才允許使用與驗證相關聯的金鑰。螢幕鎖定憑證必須以只能由獨立執行環境執行螢幕鎖定驗證的方式儲存。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。

  • [C-1-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。驗證簽署金鑰不得做為永久裝置 ID 使用。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除以下要求：必須有以獨立執行環境為基礎的金鑰儲存區，並支援金鑰認證，除非裝置宣告 android.hardware.fingerprint 功能，而這項功能需要以獨立執行環境為基礎的金鑰儲存區。

  • [C-1-5] MUST allow the user to choose the Sleep timeout for transition from the unlocked to the locked state, with a minimum allowable timeout up to 15 seconds. 車用裝置會在車用運算主機關閉或切換使用者時鎖定螢幕，這類裝置「可能」沒有休眠逾時設定。

  • [C-1-6] 必須支援 IKeymasterDevice 3.0 以上版本，或 IKeyMintDevice 1 以上版本。

Android 17 新增的規定

  • [C-SR-1] 強烈建議根據下列條件，針對主要驗證方法 (例如 PIN 碼、解鎖圖案或密碼)，強制設定獨特失敗嘗試之間的最低時間間隔：

    不重複的失敗嘗試次數 最短逾時時間
    0-4 0
    5 1 分鐘
    6 5 分鐘
    7 15 分鐘
    8 30 分鐘
    9 90 分鐘
    10 4 小時
    11 12 小時
    12 24 小時
    13 4 天
    14 13 天
    15 41 天
    16 123 天
    17 1 年
    18 3 年
    19 9 年

新增要求結束 (9.11 > C-SR-1 和逾時表)

9.11.1. 安全鎖定螢幕、驗證和虛擬裝置

AOSP 實作項目採用分層驗證模型，以知識因素為基礎的主要驗證可由次要的強效生物特徵辨識或較弱的第三層模式支援。

裝置實作方式：

  • [C-SR-1] 強烈建議只將下列其中一種方式設為主要驗證方法：

    • 數字 PIN 碼
    • 英數字元密碼
    • 在 3x3 點格線上滑動的模式

    請注意，本文將上述驗證方法稱為建議的主要驗證方法。

  • [C-0-1] MUST limit the number of failed primary authentication attempts.

  • [C-SR-5] 強烈建議實作主要驗證失敗次數上限 (20 次)，並在使用者同意啟用這項功能後，於主要驗證失敗次數超過上限時執行「恢復原廠設定」。

如果裝置實作項目將數字 PIN 碼設為建議的主要驗證方法，則：

  • [C-SR-6] 強烈建議 PIN 碼至少要有 6 位數，或等同於 20 位元的熵。

  • [C-SR-7] 強烈建議不要允許系統在沒有使用者互動的情況下自動輸入長度少於 6 位數的 PIN 碼，以免洩漏 PIN 碼長度。

如果裝置實作項目新增或修改建議的主要驗證方式，並使用新的驗證方式做為鎖定螢幕的安全方式，則新的驗證方式：

如果裝置實作項目新增或修改驗證方法，以便根據已知密碼解鎖螢幕鎖定，並使用新的驗證方法做為安全鎖定螢幕的方式：

  • [C-3-1] 輸入內容長度下限的熵必須大於 10 位元。

  • [C-3-2] 所有可能輸入內容的最大熵值必須大於 18 位元。

  • [C-3-3] 新的驗證方法「不得」取代 AOSP 實作及提供的任何建議主要驗證方法 (即 PIN 碼、解鎖圖案、密碼)。

  • [C-3-4] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setRequiredPasswordComplexity() 設定密碼規定政策，且複雜度常數比 PASSWORD_COMPLEXITY_NONE 更嚴格，或透過 DevicePolicyManager.setPasswordQuality() 方法設定的常數比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更嚴格，則必須停用新的驗證方法。

  • [C-3-5] 新的驗證方法必須每 72 小時或更短時間，還原為建議的主要驗證方法 (即 PIN 碼、圖案、密碼)，或清楚向使用者揭露部分資料不會備份，以保護資料隱私權。

如果裝置實作項目新增或修改建議的主要驗證方法，以解除螢幕鎖定，並使用以生物辨識為基礎的新驗證方法，將其視為安全的螢幕鎖定方式，則新方法：

  • [C-4-1] 必須符合第 7.3.10 節中針對第 1 類 (舊稱便利性) 所述的所有要求。

  • [C-4-2] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.

  • [C-4-3] 如果裝置政策控制器 (DPC) 應用程式已呼叫 DevicePolicyManager.setKeyguardDisabledFeatures() 方法，並設定任何相關聯的生物辨識旗標 (即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS)，則必須停用這項功能，且只能使用建議的主要驗證方式解鎖螢幕。

如果生物特徵辨識驗證方法不符合第 7.3.10 節所述的第 3 級 (舊稱嚴格) 規定：

  • [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) 應用程式已透過下列任一方式設定政策，則必須停用新方法，且只能允許使用建議的主要驗證方式解鎖螢幕：

  • [C-6-3] 至少每隔 4 小時，就必須要求使用者透過建議的主要驗證方法 (例如 PIN 碼、解鎖圖案或密碼) 進行驗證。實體權杖符合 C-X 中 TrustAgent 實作項目的規定時，系統會改為套用 [C-9-5] 中定義的逾時限制。

  • [C-6-4] 新方法「不得」視為安全螢幕鎖定，且「必須」遵守下方 C-8 列出的限制條件。

如果裝置實作項目具有安全螢幕鎖定功能，且包含一或多個實作 TrustAgentService 系統 API 的信任的代理程式，則：

  • [C-7-1] 裝置延後鎖定或可由信任的代理程式解鎖時，設定選單和螢幕鎖定中必須清楚顯示相關資訊。舉例來說，AOSP 會在設定選單中顯示「自動鎖定設定」和「電源鍵立即鎖定」的文字說明，並在螢幕鎖定畫面上顯示可辨識的圖示，藉此滿足這項規定。

  • [C-7-2] 必須遵守並完整實作 DevicePolicyManager 類別中的所有信任的代理程式 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常數。

  • [C-7-3] 不得在主要個人裝置 (例如手持式裝置) 上完整實作 TrustAgentService.addEscrowToken() 函式，但可在通常共用的裝置實作 (例如 Android TV 或車用裝置) 上完整實作該函式。

  • [C-7-4] MUST encrypt all stored tokens added by TrustAgentService.addEscrowToken().

  • [C-7-5] 不得在金鑰使用的同一部裝置上儲存加密金鑰或託管權杖。舉例來說，手機上儲存的金鑰可以解鎖電視上的使用者帳戶。對於 Automotive 裝置，不得將託管權杖儲存在車輛的任何部位。

  • [C-7-6] 啟用託管權杖來解密資料儲存空間前，必須告知使用者安全方面的影響。

  • [C-7-7] MUST have a fall-back mechanism to use one of the recommended primary authentication methods.

  • [C-7-9] 除非使用者安全 (例如駕駛人分心) 受到威脅，否則必須如第 7.3.10 節的 [C-1-7] 和 [C-1-8] 所述，要求使用者採用其中一種建議的主要驗證方法 (例如 PIN 碼、圖案或密碼)。

  • [C-7-10] 不得視為安全螢幕鎖定，且必須遵守下方 C-8 列出的限制。

  • [C-7-11] 不得允許主要個人裝置 (例如手持式裝置) 上的 TrustAgent 解鎖裝置，且只能使用 TrustAgent 將已解鎖的裝置維持在解鎖狀態，最多 4 小時。AOSP 中的 TrustManagerService 預設實作方式符合這項需求。

  • [C-7-12] MUST use a cryptographically secure (e.g UKEY2) communication channel to pass the escrow token from the storage device to the target device.

如果裝置實作項目新增或修改驗證方法，以解鎖上述非安全螢幕鎖定，並使用新的驗證方法解鎖 Keyguard：

如果裝置實作項目允許應用程式建立次要虛擬螢幕，但不支援相關聯的輸入事件 (例如透過 VirtualDeviceManager)，則：

  • [C-9-1] 裝置的預設螢幕鎖定時，必須鎖定這些次要虛擬螢幕，裝置的預設螢幕解鎖時，則必須解鎖這些次要虛擬螢幕。

如果裝置實作項目允許應用程式建立次要虛擬螢幕，並支援相關聯的輸入事件 (例如透過 VirtualDeviceManager)，則：

  • [C-10-1] MUST support separate lock states per virtual device

  • [C-10-2] Android 16 已移除這項規定。

  • [C-10-3] Android 16 已移除這項規定。

  • [C-10-4] 使用者啟動鎖定時，必須鎖定所有螢幕，包括透過手持裝置的必要鎖定使用者功能 (請參閱第 2.2.5 節 [9.11/H-1-2])

  • [C-10-5] 每個使用者都必須有獨立的虛擬裝置執行個體

  • [C-10-6] MUST disable app streaming as indicated by DevicePolicyManager.setNearbyAppStreamingPolicy.

  • [C-10-7] Android 16 已移除這項規定。

  • [C-10-11] 必須在虛擬裝置上停用驗證 UI，包括知識因素輸入和生物特徵辨識提示

  • [C-10-12] Android 16 已移除這項規定。

  • [C-10-13] 不得使用虛擬裝置鎖定狀態，透過 Android Keystore 系統進行使用者驗證授權。請參閱 KeyGenParameterSpec.Builder.setUserAuthentication*。

  • [C-10-14] 如果裝置實作共用剪貼簿，則在實體和虛擬裝置之間共用剪貼簿資料前，必須提供使用者功能提示，讓使用者啟用裝置間的剪貼簿共用功能。

  • [C-10-15] 存取剪貼簿資料時，必須在存取裝置和剪貼簿來源裝置上顯示通知。

如果裝置實作項目允許使用者將主要驗證知識因素從來源裝置轉移至目標裝置 (例如目標裝置的初始設定)，則：

  • [C-11-1] 將知識因素從來源裝置轉移至目標裝置時，必須使用與Google Cloud Key Vault 服務安全性白皮書所述類似的保護機制加密知識因素，確保知識因素無法從遠端解密，或用於從遠端解鎖任一裝置。

  • [C-11-2] 必須在來源裝置上要求使用者確認來源裝置的知識因素，才能將知識因素轉移至目標裝置。

  • [C-11-3] 如果目標裝置缺少任何設定的主要驗證知識因素，則必須要求使用者在目標裝置上確認轉移的知識因素，才能將該知識因素設為目標裝置的主要驗證知識因素，並提供從來源裝置轉移的任何資料。

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

  • [C-12-1] 只有在連線至具有螢幕鎖定的鄰近實體裝置，且使用者已透過該螢幕鎖定驗證身分時，才必須使用旗標呼叫 grantTrust()。鄰近裝置在使用者解鎖一次後，即可使用手錶或人體感測機制，滿足使用者驗證需求。

  • [C-12-2] 螢幕關閉時 (例如按下按鈕或螢幕逾時)，裝置實作項目必須進入 TrustState.TRUSTABLE 狀態，且 TrustAgent 不得撤銷信任。AOSP 符合這項規定。

  • [C-12-3] 只有在 TrustAgent 仍根據 [C-12-1] 的規定授予信任時，才可將裝置從 TrustState.TRUSTABLE 移至 TrustState.TRUSTED 狀態。

Android 17 中變更了需求條件的開始時間

  • [C-12-4] 如果實作項目未按照 [C-12-5]的定義，使用密碼編譯安全且準確的測距功能，則「必須」呼叫 TrustManagerService.revokeTrust()：

    • 授予信任權後最多 24 小時，或
    • 閒置 8 小時後，或
    • 如果實作項目未採用 [C-12-5] 中定義的密碼編譯安全且準確的測距方式， 與鄰近實體裝置的基礎連線中斷時。

變更後的要求 (9.11.1 > C-12-4)
。

  • [C-12-5] 實作項目如要依賴安全且準確的測距功能來滿足 [C-12-4] 的要求，必須使用下列其中一種解決方案：

    • 使用 UWB 實作：

      • 必須符合 7.4.9 所述的 UWB 一致性、認證、準確度和校準規定。

      • 必須使用 7.4.9 中列出的其中一種 P-STS 安全模式。

    • 使用 Wi-Fi 鄰近感知網路 (NAN) 實作：

      • 必須符合 2.2.1 [7.4.2.5/H-SR-1] 中的準確度規定，使用 160 MHz 頻寬 (或更高)，並按照「存在感校正」一文中的步驟設定測量。

      • 必須使用 IEEE 802.11az 定義的安全 LTF。

如果裝置實作項目允許應用程式建立次要虛擬螢幕，並支援相關聯的輸入事件 (例如透過 VirtualDeviceManager)，且螢幕未標示 VIRTUAL_DISPLAY_FLAG_SECURE，則：

  • [C-13-8] 必須禁止在虛擬裝置上啟動屬性 android:canDisplayOnRemoteDevices 或中繼資料 android.activity.can_display_on_remote_devices 設為 false 的活動。

  • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure and FLAG_SECURE from being started on the virtual device.

如果裝置實作項目支援透過 DeviceStateManager 分別顯示電源狀態，且支援透過 KeyguardDisplayManager 分別顯示螢幕鎖定狀態，則：

  • [C-SR-2] 強烈建議使用符合第 9.11.1 節定義的憑證，或符合第 7.3.10 節定義的至少第 1 級規格的生物辨識，允許從預設裝置螢幕獨立解鎖。

  • [C-SR-3] 強烈建議透過定義的螢幕逾時時間，限制個別螢幕解鎖。

  • [C-SR-4] STRONGLY RECOMMENDED to allow user to globally lock all displays through lockdown from primary 手持裝置.

9.11.2. StrongBox

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] MUST provide dedicated secure hardware that is used to back keystore and secure user authentication. 專用的安全硬體也可能用於其他用途。

  • [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 或 BSI-CC-PP-0117-2022 認證的硬體，或由國家認證的測試實驗室評估，並根據通用標準應用程式攻擊智慧卡潛力，納入高攻擊潛力漏洞評估。

  • [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] MUST implement the Identity Credential System (e.g., the android.security.identity.* APIs) with code communicating with a trusted application in an area that is securely isolated from the code running on the kernel and above. 安全隔離「必須」封鎖核心或使用者空間程式碼可能存取隔離環境內部狀態的所有潛在機制，包括 DMA。

  • [C-1-3] 實作身分憑證系統所需的加密作業 (例如 android.security.identity.* API) 必須完全在受信任的應用程式中執行，且私密金鑰資料絕不能離開隔離的執行環境，除非較高層級的 API (例如 createEphemeralKeyPair() 方法) 有特別要求。

  • [C-1-4] 實作受信任的應用程式時，務必確保其安全性屬性不受影響 (例如，除非符合存取控管條件，否則不會發布憑證資料；無法為任意資料產生 MAC)，即使 Android 運作異常或遭入侵也一樣。

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

9.12. 資料刪除

所有裝置的導入方式：

  • [C-0-1] 必須為使用者提供「恢復原廠設定」的機制。
  • [C-0-2] 執行「恢復原廠設定」時，必須刪除 userdata 檔案系統中的所有資料。
  • [C-0-3] 執行「恢復原廠設定」時，必須以符合相關產業標準 (例如 NIST SP800-88) 的方式刪除資料。
  • [C-0-4] 當主要使用者的裝置政策控制器應用程式呼叫 API 時，必須觸發上述「恢復原廠設定」程序。DevicePolicyManager.wipeData()
  • MAY 提供快速資料清除選項，只會進行邏輯資料清除。

9.13. 安全啟動模式

Android 提供安全啟動模式，使用者可透過這個模式啟動裝置，此時裝置只會執行預先安裝的系統應用程式，並停用所有第三方應用程式。這個模式又稱為「安全啟動模式」，可讓使用者解除安裝可能有害的第三方應用程式。

裝置實作方式如下：

  • [C-SR-1] STRONGLY RECOMMENDED to implement Safe Boot Mode.

如果裝置實作安全啟動模式，則：

  • [C-1-1] 必須提供使用者進入安全啟動模式的選項，且不得中斷裝置上安裝的第三方應用程式，但第三方應用程式是裝置政策控制器，且已將 UserManager.DISALLOW_SAFE_BOOT 旗標設為 true 時除外。

  • [C-1-2] MUST provide the user the capability to uninstall any third-party apps within Safe Mode.

  • SHOULD 提供使用者從開機選單進入安全開機模式的選項，但工作流程應與正常開機不同。

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 虛擬化架構 (AVF) API (android.system.virtualmachine.*) 可讓應用程式建立裝置端虛擬機器 (VM)、受保護的 VM (pVM) 和非受保護的 VM (非 pVM)，並將原生二進位檔載入及執行為酬載。

如果裝置實作項目將 FEATURE_VIRTUALIZATION_FRAMEWORK 設為 true，則：

  • [C-1-1] MUST ensure that android.system.virtualmachine.VirtualMachineManager.getCapabilities() returns one of the following:

    • CAPABILITY_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. 開發人員驗證

宣告 API 級別 36.1 以上版本的裝置實作項目：

  • 可能包含開發人員驗證服務的支援功能，可驗證應用程式是否來自已知開發人員。

裝置實作項目宣告 API 級別 36.1 以上版本，並在 config.xml 中定義 config_developerVerificationServiceProviderPackageName，設定開發人員驗證器：

  • [9.18/C-1-1] 每次安裝應用程式套件時，都必須叫用已設定的 android.content.pm.verify.developer.DeveloperVerifierService，包括新安裝和更新現有應用程式。

宣告 API 級別 36.1 以上版本的裝置實作項目：

  • 您也可以在 config.xml 中定義 config_developerVerificationPolicyDelegatePackageName，設定委派項目來設定有效政策。

如果已設定開發人員驗證器，裝置實作項目會：

  • [9.18/C-2-1] 只能允許開發人員驗證者或其設定的委派人，根據 android.content.pm.PackageInstaller 設定安裝政策。

如果驗證器是透過套件安裝工作階段叫用，裝置實作項目必須：

  • [9.18/C-3-1] 如有下列情況，裝置「必須」禁止安裝應用程式套件：

    • 安裝作業未通過開發人員身分驗證。

    • 安裝工作階段的開發人員驗證政策設為 DEVELOPER_VERIFICATION_POLICY_NONE 以外的值。

    • 除非適用 9.18/C-3-2 或 9.18/C-3-3。

Android 17 中變更了需求條件的開始時間

  • [9.18/C-3-2] MUST NOT prevent the installation of an application package regardless of policy or verification status when:
    • 透過 Android Debug Bridge (ADB) 安裝套件。
    • 這個套件是已設定的開發人員驗證器或其安裝程式。

變更要求結束 (9.18 > 9.18/C-3-2)

  • [9.18/C-3-3] 如符合下列所有條件，則不得禁止安裝應用程式套件：

    • 政策設為 DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN 或 DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN。

    • 驗證狀態顯示為未完成。

    • 安裝程式會回報 DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY，表示使用者明確要求繼續安裝。

Android 17 移除的規定

  • MAY allow the installation of an application package regardless of policy or verification status for installations initiated by the device owner on a managed device or the profile owner on a managed profile, but it's STRONGLY RECOMMENDED to prevent installations as outlined in 9.18/C-3-1.

移除要求 (9 月 18 日未標示 MAY 項目)

10. 軟體相容性測試

裝置實作項目必須通過本節所述的所有測試。不過請注意，沒有任何軟體測試套件是完全全面性的。因此，強烈建議裝置實作人員盡可能減少對 Android 開放原始碼計畫提供的 Android 參考和偏好實作項目進行變更。這樣做可將導入錯誤的風險降至最低，避免產生不相容問題，導致需要重新製作，甚至可能需要更新裝置。

10.1. Compatibility Test Suite

裝置實作方式：

  • [C-0-1] 必須使用裝置上的最終出貨軟體，通過 Android 開放原始碼計畫提供的 Android 相容性測試套件 (CTS)。

  • [C-0-2] 如有 CTS 模糊不清之處，以及重新實作參考原始碼部分內容的情況，都必須確保相容性。

CTS 旨在實際裝置上執行，與任何軟體一樣，CTS 本身可能含有錯誤。CTS 的版本與本相容性定義無關，且 Android 17 可能會發布多個 CTS 修訂版本。

裝置實作方式：

  • [C-0-3] 裝置軟體完成時，必須通過最新版 CTS。

  • 應盡可能使用 Android 開放原始碼樹狀結構中的參考實作。

10.2. CTS 驗證器

CTS Verifier 隨附於 Compatibility Test Suite，供人員操作，測試自動化系統無法測試的功能，例如攝影機和感應器是否正常運作。

裝置實作方式：

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

CTS 驗證器包含多種硬體的測試，包括部分選用硬體。

裝置實作方式：

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

如果相容性定義文件將某項功能標示為選用，則可略過或省略該功能的測試案例。

  • [C-0-2] 如上所述，每個裝置和每個建構版本都必須正確執行 CTS 驗證器。不過，由於許多建構版本非常相似，因此裝置實作者不必在僅有微小差異的建構版本上明確執行 CTS 驗證器。具體來說，如果裝置實作方式與通過 CTS 驗證器測試的實作方式不同，僅在於內含的語言代碼、品牌等，則可省略 CTS 驗證器測試。

11. 可更新的軟體

  • [C-0-1] 裝置實作內容必須包含可取代整個系統軟體的機制。這項機制不一定要執行「即時」升級，也就是說，裝置「可能」需要重新啟動。只要能取代裝置上預先安裝的完整軟體，任何方法都適用。舉例來說，下列任一方法都符合這項規定：

    • 透過重新啟動裝置進行「無線 (OTA)」下載，並離線更新。
    • 透過 USB 從主機電腦「連線」更新。
    • 「離線」更新：透過重新啟動，並從卸除式儲存裝置上的檔案更新。

  • [C-0-2] 所用的更新機制必須支援更新，且不會清除使用者資料。也就是說，更新機制「必須」保留應用程式私有資料和應用程式共用資料。請注意，上游 Android 軟體包含符合這項需求的更新機制。

  • [C-0-3] 整個更新檔「必須」經過簽署，且裝置上的更新機制「必須」根據裝置上儲存的公開金鑰驗證更新檔和簽章。

  • [C-SR-1] 強烈建議簽署機制使用 SHA-256 雜湊處理更新，並使用 ECDSA NIST P-256 針對公開金鑰驗證雜湊。

如果裝置實作項目支援非計量付費的數據連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，則：

  • [C-1-1] 必須支援無線下載，並透過重新啟動進行離線更新。

裝置實作項目「應」驗證系統映像檔在 OTA 後是否與預期結果完全相同。上游 Android 開放原始碼計畫中以區塊為基礎的 OTA 實作 (Android 5.1 以上版本新增) 符合這項規定。

此外，裝置實作項目「應」支援 A/B 系統更新。 AOSP 會使用啟動控制 HAL 實作這項功能。

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

  • [C-2-1] 裝置實作人員「必須」透過軟體更新修正錯誤，並按照上述機制套用更新。

Android 內建多項功能，可讓裝置擁有者應用程式 (如有) 控制系統更新的安裝作業。如果裝置的系統更新子系統回報 android.software.device_admin，則：

12. 文件變更記錄

自 Android 16 起，我們不會另外維護變更記錄。這份文件會醒目顯示先前版本的所有變更。

13. 與我們聯絡

您可以加入 android-compatibility 論壇，提出任何您認為文件未涵蓋的問題，或要求說明。