Android 15 相容性定義

1. 簡介

本文件列舉裝置必須符合的條件，才能與 Android 15 相容。

使用「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」等詞彙，是根據 RFC2119 中定義的 IETF 標準。

在這份文件中，「裝置實作者」或「實作者」是指開發搭載 Android 15 的硬體/軟體解決方案的個人或機構。「裝置實作」或「實作」是指所開發的硬體/軟體解決方案。

如要與 Android 15 相容，裝置實作方式必須符合本相容性定義中列出的規定，包括透過參考所納入的任何文件。

如果這個定義或第 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

系統會為「必須」要求指派需求 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 包含以下內容： Section ID / Device Type ID - Condition ID - Requirement ID (例如 7.4.3/A-0-1)。

2. 裝置類型

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

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

所有不屬於任何所述裝置類型的 Android 裝置實作，都必須符合本相容性定義其他部分的所有規定。

2.1 裝置設定

如要瞭解不同裝置類型的硬體設定主要差異，請參閱本節後續的裝置專屬規定。

2.2. 手持裝置需求

Android 手持裝置是指通常需要手持的 Android 裝置實作，例如 mp3 播放器、手機或平板電腦。

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

  • 使用可隨身攜帶的電源，例如電池。
  • 螢幕對角線尺寸介於 4 吋至 8 吋。
  • 提供觸控螢幕輸入介面。

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

注意：不適用於 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]* 必須將提供給第三方應用程式的每個 UI_MODE_NORMAL 顯示畫面，對應至未受阻礙的實體顯示區域，且短邊至少為 2.2 英寸，長邊至少為 3.4 英寸。

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

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

如果手持裝置實作項目透過 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 相容螢幕上提供 Home 功能。
  • [7.2.3/H-0-4] 必須在所有 Android 相容螢幕上提供「返回」功能，並在至少一個 Android 相容螢幕上提供「近期」功能。
  • [7.2.4/H-0-1] 必須支援觸控螢幕輸入。
  • [7.2.4/H-SR-1] 強烈建議您啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式，或是在前景活動未處理長按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 的情況下，處理 ACTION_ASSIST 的活動。
  • [7.3.1/H-SR-1] 強烈建議加入 3 軸加速計。

如果手持裝置實作項目包含 3 軸式加速度計，則會執行以下操作：

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

如果手持裝置導入作業包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，則會發生以下情況：

  • [7.3.3/H-2-1] 一旦偵測到 GNSS 測量資料，就必須立即回報，即使尚未回報透過 GPS/GNSS 計算的位置也一樣。
  • [7.3.3/H-2-2] 必須回報 GNSS 偽距和偽距速率，在確定位置後，在靜止或以每秒 0.2 公尺平方以下的加速度移動時，至少有 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 15 的新規定上路了

  • [7.4.3/H] 應支援藍牙和藍牙 LE。

支援藍牙 LE 的掌上型裝置實作方式：

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

新規定結束

如果裝置透過宣告 PackageManager.FEATURE_WIFI_AWARE 支援 Wi-Fi Neighbor Awareness Networking (NAN) 通訊協定，並透過宣告 PackageManager.FEATURE_WIFI_RTT 支援 Wi-Fi 定位 (Wi-Fi 往返時間 - RTT)，則裝置會：

  • [7.4.2.5/H-1-1] 必須準確回報範圍，在 68 百分位數的 160 MHz 頻寬中，範圍必須在 +/-1 公尺內 (使用累積分配函式計算)；在 68 百分位數的 80 MHz 頻寬中，範圍必須在 +/-2 公尺內；在 68 百分位數的 40 MHz 頻寬中，範圍必須在 +/-4 公尺內；在 68 百分位數的 20 MHz 頻寬中，範圍必須在 +/-8 公尺內，距離則是透過 WifiRttManager#startRanging Android API 觀察到的 10 公分、1 公尺、3 公尺和 5 公尺。

  • [7.4.2.5/H-SR-1] 強烈建議使用 WifiRttManager#startRanging Android API 進行測試，在 10 公分距離內，以 90 百分位數的準確度，在 160 MHz 頻寬下回報範圍 +/-1 公尺 (由累積分配函式計算)、在 80 MHz 頻寬下回報範圍 +/-2 公尺 (由累積分配函式計算)、在 40 MHz 頻寬下回報範圍 +/-4 公尺 (由累積分配函式計算)、在 20 MHz 頻寬下回報範圍 +/-8 公尺 (由累積分配函式計算)。

強烈建議您按照「存在校正」一文中指定的評估設定步驟操作。

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

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

如果手持裝置實作內容包含邏輯攝影機裝置，而該裝置會使用 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 列出功能，則會發生以下情況：

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

手持裝置實作方式：

  • [7.6.1/H-0-1] 應用程式私人資料 (又稱「/data」分區) 必須至少有 4 GB 的非揮發性儲存空間。
  • [7.6.1/H-0-2] 當核心和使用者空間可用的記憶體少於 1 GB 時，必須針對 ActivityManager.isLowRamDevice() 傳回「true」。

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

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

  • [7.6.1/H-2-1] 如果預設螢幕使用高達 HD+ 的框架緩衝區解析度 (例如 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 的 framebuffer 解析度 (例如 WSXGA+)，則核心和使用者空間可用的記憶體必須至少為 1280 MB。

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

請注意，上述「可供核心和使用者空間使用的記憶體」是指除了已專用於硬體元件 (例如無線電、影片等) 的記憶體之外，提供的記憶體空間，這些記憶體並未受限於裝置實作方式的核心控制。

如果手持裝置實作項目提供給核心和使用者空間的可用記憶體小於或等於 1 GB，則會發生以下情況：

  • [7.6.1/H-9-1] 必須宣告功能旗標 android.hardware.ram.low。
  • [7.6.1/H-9-2] 應用程式私人資料 (又稱「/data」分區) 至少須有 1.1 GB 的非揮發性儲存空間。

如果手持裝置實作項目提供給核心和使用者空間的記憶體超過 1 GB，則會發生以下情況：

  • [7.6.1/H-10-1] 應用程式私人資料 (又稱「/data」分區) 必須至少有 4 GB 的非揮發性儲存空間。
  • 應宣告功能旗標 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] 應包含支援週邊裝置模式的 USB 連接埠。

Android 15 的新規定上路了

如果手持裝置實作項目包含 USB 連接埠，且支援 以控制器在外接模式下運作，則：

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

新規定結束

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

手持裝置實作方式：

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

如果手持裝置實作項目能夠滿足支援 VR 模式的所有效能需求，並且提供相關支援，則必須符合下列條件：

  • [7.9.1/H-1-1] 必須宣告 android.hardware.vr.high_performance 功能旗標。
  • [7.9.1/H-1-2] 應用程式必須實作 android.service.vr.VrListenerService，且可透過 android.app.Activity#setVrModeEnabled 在 VR 應用程式中啟用。

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

  • [7.8.2.2/H-1-1] 必須提供以下 HID 代碼的軟體對應：
函式 對應 背景資訊 行為
A HID 使用頁面：0x0C
HID 用途：0x0CD
核心鍵：KEY_PLAYPAUSE
Android 鍵：KEYCODE_MEDIA_PLAY_PAUSE		 媒體播放 輸入：短按
輸出：播放或暫停
輸入：長按
輸出：啟動語音指令
傳送：如果裝置處於鎖定或螢幕關閉狀態，則傳送 android.speech.action.VOICE_SEARCH_HANDS_FREE。否則傳送 android.speech.RecognizerIntent.ACTION_WEB_SEARCH
來電 輸入：短按
輸出：接聽通話
輸入：長按
輸出：拒接來電
通話中 輸入：短按
輸出：結束通話
輸入：長按
輸出：將麥克風設為靜音或取消靜音
B HID 使用頁面：0x0C
HID 用途：0x0E9
核心鍵：KEY_VOLUMEUP
Android 鍵：VOLUME_UP		 媒體播放、通話中 輸入：短按或長按
輸出：調高系統或耳機音量
C HID 使用頁面：0x0C
HID 用途：0x0EA
核心鍵：KEY_VOLUMEDOWN
Android 鍵：VOLUME_DOWN		 媒體播放、通話中 輸入：短按或長按
輸出：降低系統或耳機音量
D HID 使用頁面：0x0C
HID 用法：0x0CF
核心鍵：KEY_VOICECOMMAND
Android 鍵：KEYCODE_VOICE_ASSIST		 。可在任何執行個體中觸發。 輸入：短按或長按
輸出：啟動語音指令
  • [7.8.2.2/H-1-2] 必須在插入插頭時觸發 ACTION_HEADSET_PLUG，但前提是 USB 音訊介面和端點已正確列舉，以便識別連接的終端類型。

偵測到 USB 音訊終端類型 0x0302 時，會發生以下情況：

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

偵測到 USB 音訊終端類型 0x0402 時，會發生以下情況：

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

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

  • [7.8.2.2/H-4-1] 如果 USB 音訊終端類型欄位為 0x0302，則必須列出類型為 AudioDeviceInfo.TYPE_USB_HEADSET 的裝置，以及角色 isSink()。

  • [7.8.2.2/H-4-2] 如果 USB 音訊終端類型欄位為 0x0402，則必須列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置和角色 isSink()。

  • [7.8.2.2/H-4-3] 如果 USB 音訊終端類型欄位為 0x0402，則必須列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置和角色 isSource()。

  • [7.8.2.2/H-4-4] 如果 USB 音訊終端類型欄位為 0x603，則必須列出類型為 AudioDeviceInfo.TYPE_USB_DEVICE 的裝置，以及角色 isSink()。

  • [7.8.2.2/H-4-5] 如果 USB 音訊終端類型欄位為 0x604，則必須列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置和角色 isSource()。

  • [7.8.2.2/H-4-6] 如果 USB 音訊終端類型欄位為 0x400，則必須列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置和角色 isSink()。

  • [7.8.2.2/H-4-7] 如果 USB 音訊終端類型欄位為 0x400，則必須列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置和 isSource() 角色。

  • [7.8.2.2/H-SR-1] 強烈建議在連接 USB-C 音訊外接裝置時，執行 USB 描述元列舉、識別終端類型，並在 1000 毫秒內廣播 Intent ACTION_HEADSET_PLUG。

Android 15 新規定生效

如果 針對手持裝置實作宣告 android.hardware.audio.output 和 android.hardware.microphone，則： 請參閱 5.6 節中的 RTL 和 TTL 規定。

  • [5.6/H-1-1] 在以下資料路徑中，連續測量 5 次後，平均回傳延遲時間必須小於 300 毫秒，且平均絕對誤差小於 30 毫秒：「喇叭至麥克風」、3.5 公釐迴路轉接器 (如有支援)、USB 迴路 (如有支援)。

  • [5.6/H-1-2] 在揚聲器至麥克風資料路徑上，至少測量 5 次，平均點擊至音訊延遲時間不得超過 300 毫秒。

新規定結束

線性諧振致動器 (LRA) 是單質量彈簧系統，具有主導諧振頻率，在該頻率下，質量會沿著所需運動方向轉換。

如果手持裝置實作包含至少一個通用 7.10 線性諧振致動器，則應符合下列條件：

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

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

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

  • [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. 軟體

手持裝置實作方式：

  • [3.2.3.1/H-0-1] 必須有處理 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT 意圖的應用程式，如 SDK 文件所述，並提供使用者操作元素，以便使用 DocumentsProvider API 存取文件提供者資料。
  • [3.2.3.1/H-0-2]* 對於所有由以下列出此處的應用程式意圖定義的公開意圖篩選器模式，必須使用意圖處理常式預先載入一個或多個應用程式或服務元件。
  • [3.2.3.1/H-SR-1] 強烈建議您預先載入可處理 ACTION_SENDTO 或 ACTION_SEND 或 ACTION_SEND_MULTIPLE 意圖的電子郵件應用程式，以便傳送電子郵件。
  • [3.4.1/H-0-1] 必須提供 android.webkit.Webview API 的完整實作。
  • [3.4.2/H-0-1] 必須提供獨立的瀏覽器應用程式，供一般使用者瀏覽網頁。
  • [3.8.1/H-SR-1] 強烈建議您實作可支援應用程式內捷徑、小工具和 widgetFeatures 固定功能的預設啟動器。
  • [3.8.1/H-SR-2] 強烈建議您實作預設啟動器，透過 ShortcutManager API 快速存取第三方應用程式提供的其他捷徑。
  • [3.8.1/H-SR-3] 強烈建議您加入預設的啟動器應用程式，以便顯示應用程式圖示的徽章。
  • [3.8.2/H-SR-1] 強烈建議您支援第三方應用程式小工具。
  • [3.8.3/H-0-1] 必須允許第三方應用程式透過 Notification 和 NotificationManager API 類別，通知使用者有重要事件發生。
  • [3.8.3/H-0-2] 必須支援多媒體通知。
  • [3.8.3/H-0-3] 必須支援抬頭通知。
  • [3.8.3/H-0-4] 必須加入通知遮罩，讓使用者能夠透過使用者操作元素 (例如 AOSP 中實作的動作按鈕或控制台) 直接控制通知 (例如回覆、暫緩、關閉、封鎖)。
  • [3.8.3/H-0-5] 必須在通知陰影中顯示透過 RemoteInput.Builder setChoices() 提供的選項。
  • [3.8.3/H-SR-1] 強烈建議您在通知陰影中顯示透過 RemoteInput.Builder setChoices() 提供的第一個選項，而不需要額外的使用者互動。
  • [3.8.3/H-SR-2] 強烈建議在使用者展開通知欄中的所有通知時，在通知欄中顯示透過 RemoteInput.Builder setChoices() 提供的所有選項。
  • [3.8.3.1/H-SR-1] 強烈建議您為顯示動作設定 Notification.Action.Builder.setContextual，並將其設為 true，以便與 Notification.Remoteinput.Builder.setChoices 顯示的回覆保持一致。
  • [3.8.4/H-SR-1] 強烈建議在裝置上實作助理，以便處理輔助動作。

如果手持裝置導入作業支援 MediaStyle 通知，則會執行以下操作：

  • [3.8.3.1/H-SR-2] 強烈建議在應用程式使用 MediaSession 權杖發布 MediaStyle 通知時，提供可從系統 UI 存取的使用者操作提示 (例如輸出切換器)，讓使用者在適當的可用媒體路徑 (例如提供給 MediaRouter2Manager 的藍牙裝置和路徑) 之間切換。

如果裝置實作 (包括最近功能導覽鍵) 如 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]* 必須在非對話通知前顯示對話通知，但持續顯示的前景服務通知和importance:high通知除外。

如果 Android 手持裝置實作項目支援鎖定畫面，則必須符合下列條件：

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

如果手持裝置實作項目支援安全的螢幕鎖定功能，則必須符合下列條件：

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

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

  • [3.8.16/H-1-1] 必須宣告功能旗標 android.software.controls，並將其設為 true。
  • [3.8.16/H-1-2] 必須提供使用者操作提示，讓使用者能夠透過 ControlsProviderService 和 Control API，從第三方應用程式註冊的控制項中新增、編輯、選取及操作使用者喜愛的裝置控制項。
  • [3.8.16/H-1-3] 必須在預設啟動器的三次互動中，提供此使用者操作選項的存取權。

  • [3.8.16/H-1-4] 在這個使用者操作選項中，必須準確顯示每個透過 ControlsProviderService API 提供控制項的第三方應用程式名稱和圖示，以及 Control API 提供的任何指定欄位。

  • [3.8.16/H-1-5] 必須提供使用者操作提示，讓使用者可從第三方應用程式透過 ControlsProviderService 和 Control Control.isAuthRequired API 註冊的控制項中，選擇停用應用程式指定的簡單驗證裝置控制項。

  • [3.8.16/H-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 開放原始碼專案提供的 Switch Access 和 TalkBack (針對預先安裝的文字轉語音引擎支援的語言) 無障礙服務相當或更優的無障礙服務。
  • [3.11/H-0-1] 必須支援安裝第三方 TTS 引擎。
  • [3.11/H-SR-1] 強烈建議您納入支援裝置上可用語言的 TTS 引擎。
  • [3.13/H-SR-1] 強烈建議您加入快速設定 UI 元件。

如果 Android 手持裝置實作聲明支援 FEATURE_BLUETOOTH 或 FEATURE_WIFI，則會：

  • [3.16/H-1-1] 必須支援隨附裝置配對功能。

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

  • [7.2.3/H] 從螢幕底部算起，主畫面功能的手勢辨識區域高度應不超過 32 個像素點。

如果手持裝置實作項目提供的導覽功能是從螢幕左側或右側邊緣的任一處以手勢操作：

  • [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 宣告支援攝影機，則會：

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

如果裝置實作可讓使用者撥打任何類型的電話，則

2.2.4. 效能和電源

  • [8.1/H-0-1] 一致的畫面延遲。影格延遲時間不一致或轉譯影格延遲的情況，每秒不得超過 5 個影格，且每秒應低於 1 個影格。
  • [8.1/H-0-2] 使用者介面延遲。裝置實作項目必須在 36 秒內捲動 Android Compatibility Test Suite (CTS) 定義的 10K 清單項目清單，確保低延遲的使用者體驗。
  • [8.1/H-0-3] 工作切換。啟動多個應用程式時，重新啟動已啟動的應用程式時，必須在 1 秒內完成。

手持裝置實作方式：

  • [8.2/H-0-1] 必須確保序列寫入效能至少為 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 中)，或可擴充 AOSP 中的功能，則必須符合以下條件：

  • [8.3/H-1-1] 必須提供使用者操作提示，以便啟用及停用省電模式。
  • [8.3/H-1-2] 必須提供使用者操作提示，以便顯示所有不受應用程式待命值區和 Doze 省電模式影響的應用程式。

手持裝置實作方式：

  • [8.4/H-0-1] 必須提供每個元件的電源設定檔，定義每個硬體元件的電流消耗值，以及元件隨時間推移造成的電池耗電量，如 Android 開放原始碼專案網站所述。
  • [8.4/H-0-2] 必須以毫安培小時 (mAh) 為單位回報所有耗電量值。
  • [8.4/H-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫透過 uid_cputime 核心模組實作來滿足這項需求。
  • [8.4/H-0-4] 必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供這項電量用量資訊。
  • 如果無法將硬體元件的耗電量歸因於應用程式，則應將 [8.4/H] 歸因於硬體元件本身。

如果手持裝置實作項目包含螢幕或影片輸出，則必須符合下列條件：

手持裝置實作方式：

  • [8.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] 必須允許第三方應用程式透過 android.permission.PACKAGE_USAGE_STATS 權限存取使用統計資料，並提供使用者可存取的機制，以回應 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，授予或撤銷對此類應用程式的存取權。

Android 15 的新規定上路了

裝置實作項目必須宣告支援 android.software.credentials，並符合下列條件：

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

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

新規定結束

如果裝置實作項目宣告支援 android.hardware.telephony，則會：

  • [9.5/H-1-1] 不得將 UserManager.isHeadlessSystemUserMode 設為 true。

手持裝置實作方式：

  • [9.11/H-0-2] 必須使用獨立的執行環境備份 KeyStore 實作。
  • [9.11/H-0-3] 必須實作 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上層級執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離功能必須封鎖所有潛在機制，以免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 使用 Trusty 實作項目來滿足這項要求，但其他以 ARM TrustZone 為基礎的解決方案，或第三方審查的安全實作項目，也是適當的虛擬機器人隔離方式。
  • [9.11/H-0-4] 必須在隔離執行環境中執行螢幕鎖定畫面驗證，且只有在成功驗證後，才允許使用與驗證綁定的金鑰。螢幕鎖定憑證必須以允許只有隔離執行環境執行螢幕鎖定驗證的方式儲存。上游 Android 開放原始碼專案提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項要求。

Android 15 的新規定上路了

  • [9.11/H-0-5] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業是在安全硬體中執行。認證簽署金鑰必須 在足夠多裝置上共用，才能避免金鑰 遭到阻止，無法用於永久裝置識別。如要符合這項規定，您可以共用相同的認證金鑰，除非您已製造出至少 100,000 個特定 SKU，如果某個 SKU 的產量超過 100,000 個，則每 100,000 個單位可能會使用不同的鍵。

新規定結束

請注意，如果裝置實作已在較舊的 Android 版本上推出，則該裝置不必符合要求，即不必具備由隔離執行環境支援的 KeyStore，也不必支援金鑰認證，除非該裝置宣告 android.hardware.fingerprint 功能，而該功能需要由隔離執行環境支援的 KeyStore。

當手持裝置實作支援安全的螢幕鎖定功能時，會具備以下功能：

  • [9.11/H-1-1] 必須允許使用者選擇最短的休眠逾時時間，也就是從解鎖到鎖定的轉換時間，最短為 15 秒。
  • [9.11/H-1-2] 必須提供使用者操作提示，以便隱藏通知和停用所有形式的驗證，但 9.11.1 安全的螢幕鎖定畫面中所述的主要驗證除外。Android 開放原始碼計畫符合鎖定模式的規定。

如果裝置實作項目設有安全的鎖定畫面，且包含一或多個信任代理程式 (實作 TrustAgentService 系統 API)，則會：

  • [9.11.1/H-1-1] 每 72 小時內，您必須至少要求使用者提供一次建議的主要驗證方法 (例如 PIN 碼、圖案、密碼)。

如果手持裝置實作包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

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

如果手持裝置實作包含多名使用者，並宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

  • [9.5/H-3-1] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作方式一致，才能啟用 /停用其他使用者存取語音通話和簡訊的權限。

如果手持裝置實作將 UserManager.isHeadlessSystemUserMode 設為 true，則

  • [9.5/H-4-1] 不得支援 eUICC 或具備通話功能的 eSIM。
  • [9.5/H-4-2] 不得宣告支援 android.hardware.telephony。

Android 透過系統 API VoiceInteractionService 支援安全的隨時啟動熱字詞偵測機制，無須麥克風存取權指示，以及隨時啟動查詢偵測機制，無須麥克風或相機存取權指示。

Android 15 的新規定上路了

受限制的設定

受限制設定會向使用者顯示警告，並要求使用者確認，以便為下列每個應用程式授予權限：

  • 透過應用程式 (例如訊息應用程式或瀏覽器) 下載後安裝，但不是 PackageManager 識別為 PACKAGE_DOWNLOADED_FILE 的「應用程式商店」應用程式。
  • 從本機檔案安裝 (例如應用程式已側載)，由 PackageManager 識別為 PACKAGE_SOURCE_LOCAL_FILE。

針對下方 [9.8/H-0-5] 所列的任何強制權限及其關聯 ID。

針對本節所列的規定，這類應用程式會標示為「受規範的應用程式」。

裝置實作方式：

  • [9.8/H-0-1] 必須針對下列項目實作上述的「限制設定」：

    • 特殊權限
      • 無障礙設計 (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

新規定結束

如果手持裝置實作支援系統 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] 不得允許使用者安裝的應用程式提供熱字詞偵測服務。
  • [9.8/H-1-10] 請勿在 UI 中顯示關於熱字詞偵測服務的麥克風使用情形的定量資料。
  • [9.8/H-1-11] 必須記錄熱字詞偵測服務每次傳輸內容所包含的位元組數量，以便安全研究人員進行檢查。
  • [9.8/H-1-12] 必須支援偵錯模式，記錄熱字詞偵測服務傳送的每個內容原始內容，以便安全研究人員進行檢查。

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

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

  • [9.8/H-SR-1] 強烈建議您先通知使用者，再將應用程式設為熱字詞偵測服務的提供者。

  • [9.8/H-SR-2] 強烈建議您禁止從熱字詞偵測服務傳送非結構化資料。

  • [9.8/H-SR-3] 強烈建議至少每小時或每 30 個硬體觸發事件 (以先到者為準) 重新啟動主控關鍵字偵測服務的程序。

如果裝置實作項目包含使用系統 API HotwordDetectionService 或類似機制來偵測熱字詞，但未提供麥克風使用指示，則應用程式會：

  • [9.8/H-2-1] 必須針對支援的每個熱字詞，向使用者明確通知。
  • [9.8/H-2-2] 不得透過熱字詞偵測服務保留原始音訊資料，或由此衍生的資料。
  • [9.8/H-2-3] 請勿從熱字詞偵測服務傳送音訊資料、可用於重建 (全部或部分) 音訊的資料，或與熱字詞本身無關的音訊內容，但可傳送至 ContentCaptureService 或裝置端語音辨識服務。

如果手持裝置實作支援系統 API VisualQueryDetectionService，或其他用於查詢偵測的機制，但未提供麥克風和/或相機存取權指示，則會發生以下情況：

  • [9.8/H-3-1] 請務必確保查詢偵測服務只能將資料傳送至系統、ContentCaptureService 或裝置端語音辨識服務 (由 SpeechRecognizer#createOnDeviceSpeechRecognizer() 建立)。
  • [9.8/H-3-2] 不得允許任何音訊或視訊資訊從 VisualQueryDetectionService 傳出，但可傳送至 ContentCaptureService 或裝置端語音辨識服務。
  • [9.8/H-3-3] 裝置偵測到使用者有意使用數位助理應用程式 (例如透過攝影機偵測使用者是否在場) 時，必須在系統使用者介面中顯示使用者通知。
  • [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 15 的新規定上路了

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

  • [9.10/H-1-1] 必須驗證在 Android 啟動序列中掛載的所有唯讀分區，且 VBMeta 摘要必須在計算中納入所有已驗證的分區。

新規定結束

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

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

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

Android 15 的新規定上路了

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

  • Perfetto
    • [6.1/H-0-2]* 必須將 /system/bin/perfetto 二進位檔公開給殼層使用者，且 cmdline 必須符合 Perfetto 說明文件。
    • [6.1/H-0-3]* Perfetto 二進位檔必須接受符合 Perfetto 說明文件中定義的結構定義的 protobuf 設定檔做為輸入內容。
    • [6.1/H-0-4]* Perfetto 二進位檔必須以輸出格式寫入 protobuf 追蹤記錄，且必須符合 Perfetto 說明文件中定義的結構定義。
    • [6.1/H-0-5]* 必須透過 perfetto 二進位檔提供至少 perfetto 說明文件中所述的資料來源。
    • [6.1/H-0-6]* 預設情況下，必須啟用 perfetto 追蹤 Daemon (系統屬性 persist.traced.enable)。

新規定結束

2.2.7. 手持媒體成效類別

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

2.2.7.1. 媒體

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.U，則會：

Android 15 的新規定上路了

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.V，則會：

新規定結束

  • [5.1/H-1-1] 必須透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，宣傳可在任何編解碼組合中同時執行的硬體視訊解碼器工作階段數量上限。

Android 15 新規定生效

  • [5.1/H-1-2] 必須支援 6 個 8 位元 (SDR) 硬體視訊解碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，同時執行任何編解碼器組合，其中 3 個工作階段為 1080p 解析度@30 fps，另外 3 個工作階段為 4K 解析度@30 fps。對於所有工作階段，每秒丟失的畫面不得超過 1 個。AV1 轉碼器只需要支援 1080p 解析度，但仍需要支援 1080p30fps 的 6 個執行個體。

新規定結束

  • [5.1/H-1-3] 必須透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，宣傳可在任何編解碼器組合中同時執行的硬體影片編碼器工作階段數量上限。

Android 15 的新規定上路了

  • [5.1/H-1-4] 必須支援 6 個 8 位元 (SDR) 硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，同時執行任何編解碼器組合，其中 4 個工作階段為 1080p 解析度@30 fps，2 個工作階段為 4K 解析度@30 fps。對於所有工作階段，每秒丟失的畫面不得超過 1 個。AV1 編解碼器只需要支援 1080p 解析度，但仍需要支援 1080p30fps 的 6 個例項。

新規定結束

  • [5.1/H-1-5] 必須透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，宣傳在任何編解碼器組合中，可同時執行的硬體視訊編碼器和解碼器工作階段數量上限。

Android 15 的新規定上路了

  • [5.1/H-1-6] 必須支援 6 個 8 位元 (SDR) 硬體影片解碼器例項，以及硬體影片編碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，在任何轉碼器組合中同時執行 4K@30fps 解析度的 3 個工作階段，其中最多 2 個為編碼器工作階段，3 個為 1080p 解析度的工作階段。對於所有工作階段，每秒丟失的畫面不得超過 1 個。AV1 編解碼器只需要支援 1080p 解析度，但仍需要支援 1080p30fps 的 6 個例項。

新規定結束

Android 15 的新規定上路了

  • [5.1/H-1-19] 必須支援 3 個 10 位元 (HDR) 硬體視訊解碼器和硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，同時以 4K@30fps 解析度執行，其中最多 1 個為編碼器工作階段，可透過 GL 途徑以 RGBA_1010102 輸入格式進行設定。對於所有工作階段，每秒不得遺失超過 1 個影格。如果是從 GL 途徑進行編碼，則不需要由編碼器產生 HDR 中繼資料。即使這項規定要求 4K，AV1 轉碼器工作階段也只需要支援 1080p 解析度。

新規定結束

  • [5.1/H-1-7] 在負載時，所有硬體視訊編碼器的 1080p 以下影片編碼工作階段，編碼器初始化延遲時間不得超過 40 毫秒。此處的負載定義為同時使用硬體視訊轉碼器的 1080p 至 720p 僅視訊轉碼工作階段，以及 1080p 的音訊/視訊錄製初始化。對於杜比視界編解碼器，編解碼器初始化延遲時間必須低於 50 毫秒。
  • [5.1/H-1-8] 在負載時，所有音訊編碼器的 128 kbps 以下位元率音訊編碼工作階段，編碼器初始化延遲時間不得超過 30 毫秒。此處的負載定義為同時使用硬體視訊轉碼器的 1080p 至 720p 僅視訊轉碼工作階段，以及 1080p 的音訊/視訊錄製初始化。

Android 15 的新規定上路了

  • [5.1/H-1-9] 必須支援 2 個安全硬體影片解碼器工作階段 (AVC、HEVC、VP9、AV1 或更新版本)，同時以 1080p 解析度@30 fps 執行，適用於 8 位元 (SDR) 和 10 位元 HDR 內容。對於所有工作階段，每秒不得有超過 1 個影格遺失。

新規定結束

Android 15 的新規定上路了

  • [5.1/H-1-10] 必須支援 3 個非安全硬體影片解碼器工作階段，以及 1 個安全硬體影片解碼器工作階段 (總共 4 個例項) (AVC、HEVC、VP9、AV1 或更新版本)，在任何轉碼器組合中同時執行 3 個工作階段，解析度為 4K 解析度@30fps，其中包括 1 個安全解碼器工作階段和 1 個非安全工作階段，解析度為 1080p 解析度@30fps，其中最多 2 個工作階段可為 10 位元 HDR。對於所有工作階段，每秒丟失的畫面不得超過 1 個。即使這項規定要求 4K，AV1 轉碼器工作階段也只需要支援 1080p 解析度。

新規定結束

  • [5.1/H-1-11] 必須為裝置上的每個硬體 AVC、HEVC、VP9 或 AV1 解碼器支援安全解碼器。
  • [5.1/H-1-12] 在負載時，所有硬體影片解碼器的 1080p 以下影片解碼工作階段，編解碼器初始化延遲時間不得超過 40 毫秒。此處的負載定義為同時使用硬體視訊轉碼器進行 1080p 至 720p 的單純視訊轉碼工作階段，以及 1080p 音訊/視訊播放初始化。對於杜比視界編解碼器，編解碼器初始化延遲時間必須低於 50 毫秒。
  • [5.1/H-1-13] 在負載時，所有音訊解碼器的 128 kbps 以下位元率音訊解碼工作階段，必須具備 30 毫秒以下的編解碼器初始化延遲時間。此處的「載入」定義為同時使用硬體視訊編解碼器，將 1080p 轉碼為 720p 的視訊轉碼工作階段，並搭配 1080p 音訊/視訊播放初始化。

Android 15 的新規定上路了

  • [5.1/H-1-14] 必須支援 AV1 硬體解碼器 Main 10、Level 4.1，並且具有膠片顆粒效果 ，在 GPU 合成時套用膠片顆粒效果。

新規定結束

  • [5.1/H-1-15] 至少須有 1 個硬體影像解碼器，支援 4K60。
  • [5.1/H-1-16] 至少須有 1 個硬體影像編碼器，支援 4K60。

Android 15 新規定生效

  • [5.1/H-1-21] 所有硬體影片解碼器 (AVC、HEVC、VP9、AV1 或更新版本) 都必須支援 FEATURE_DynamicColorAspect。注意：這表示應用程式可以在解碼工作階段中更新影片內容的色彩。支援 10 位元和 8 位元內容的解碼器，必須支援在 Surface 模式下，動態切換 8 位元和 10 位元內容。支援 HDR 傳遞函數的解碼器必須支援在 SDR 和 HDR 內容之間動態切換。

新規定結束

Android 15 的新規定上路了

  • [5.1/H-1-22] 必須支援編碼、解碼、GPU 編輯，並以直向顯示比例顯示影片內容，無論相機支援的最大解析度或 4K 的旋轉中繼資料為何 (以較低者為準)。注意：如果編解碼器支援 HDR，就會納入 HDR 設定檔。AV1 編碼器只需要支援 1080p 解析度。這項規定僅適用於硬體編碼器、GPU 和 DPU。

新規定結束

  • [5.3/H-1-1] 在載入 4K 60 fps 影片工作階段時，每 10 秒不得遺失超過 1 個影格 (即遺失影格率低於 0.167%)。
  • [5.3/H-1-2] 在 4K 工作階段的 60 fps 影片工作階段中，在影片解析度變更期間，不得在 10 秒內丟失超過 1 個影格。
  • [5.6/H-1-1] 使用 CTS Verifier 的輕觸音效測試時，輕觸音效延遲時間不得超過 80 毫秒。
  • [5.6/H-1-2] 必須透過至少一個支援的資料路徑，以 80 毫秒或更短的延遲時間來回傳送音訊。
  • [5.6/H-1-3] 必須支援 24 位元以上的音訊，以便透過 3.5 公釐耳機插孔 (如有) 和 USB 音訊 (如有) 輸出立體聲音訊，以便透過整個資料路徑提供低延遲和串流設定。針對低延遲設定，應用程式應在低延遲回呼模式下使用 AAudio。對於串流設定，應用程式應使用 Java AudioTrack。在低延遲和串流設定中，HAL 輸出匯出端應接受 AUDIO_FORMAT_PCM_24_BIT、AUDIO_FORMAT_PCM_24_BIT_PACKED、AUDIO_FORMAT_PCM_32_BIT 或 AUDIO_FORMAT_PCM_FLOAT 做為目標輸出格式。

Android 15 的新規定上路了

  • [5.6/H-1-4] 必須支援 4 以上聲道數的 USB 音訊裝置。(DJ 控制器會使用這項參數來預覽歌曲。)

新規定結束

  • [5.6/H-1-5] 必須支援符合類別的 MIDI 裝置，並宣告 MIDI 功能旗標。
  • [5.6/H-1-9] 必須支援至少 12 個混音通道。這表示可以使用 7.1.4 聲道遮罩開啟 AudioTrack，並正確將所有聲道轉為立體聲或下混成立體聲。
  • [5.6/H-SR] 強烈建議支援 24 聲道混音，且至少支援 9.1.6 和 22.2 聲道遮罩。
  • [5.7/H-1-2] 必須支援 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL，並提供下列內容解密功能。
最小樣本數量 4 MiB
子樣本數量下限 - H.264 或 HEVC 32
子樣本數量下限 - VP9 9
子樣本數量下限 - AV1 288
最小子樣本緩衝區大小 1 MiB
通用加密緩衝區大小下限 500 KiB
同時進行的工作階段數下限 30
每個工作階段的鍵數量下限 20
最低鍵數 (所有工作階段) 80
DRM 金鑰的最低總數 (所有工作階段) 6
訊息大小 16 KiB
每秒解密影格數 60 fps
  • [5.1/H-1-17] 至少須有 1 個硬體圖片解碼器，支援 AVIF 基準設定檔。
  • [5.1/H-1-18] 必須支援 AV1 編碼器，可在 30fps 和 1Mbps 下編碼至 480p 解析度。

Android 15 的新規定上路了

  • [5.1/H-1-20] 必須支援 Feature_HdrEditing 功能，適用於裝置上的所有硬體 AV1 和 HEVC 編碼器，解析度為 4K 或相機支援的最大解析度 (以較低者為準)。

新規定結束

  • [5.12/H-SR] 強烈建議您為裝置上的所有硬體 AV1 和 HEVC 編碼器支援 Feature_HdrEditing 功能。
  • [5.12/H-1-2] 裝置上的所有硬體 AV1 和 HEVC 編碼器都必須支援 RGBA_1010102 顏色格式。
  • [5.12/H-1-3] 必須宣告支援 EXT_YUV_target 擴充功能，以便從 YUV 紋理中以 8 位元和 10 位元取樣。
  • [7.1.4/H-1-1] 顯示處理單元 (DPU) 中必須至少有 6 個硬體疊加層，其中至少 2 個可顯示 10 位元影片內容。

Android 15 的新規定上路了

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.V，且支援硬體 AVC 或 HEVC 編碼器，則會：

新規定結束

2.2.7.2. 相機

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.U，則會：

Android 15 的新規定上路了

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.V，則會：

新規定結束

Android 15 新規定生效

  • [7.5/H-1-1] 主後置鏡頭的解析度必須至少為 1,200 萬像素，並支援 4K@30fps、1080p@60fps 和 720p@60fps 的錄影功能。主要後置鏡頭是相機 ID 最低的後置鏡頭。

新規定結束

  • [7.5/H-1-2] 必須具備主前置鏡頭，解析度至少為 600 萬像素，並支援 1080p@30fps 的錄影功能。主要前置鏡頭是相機 ID 最小的前置鏡頭。
  • [7.5/H-1-3] 必須支援 android.info.supportedHardwareLevel 屬性，其中背面主要相機為 FULL 以上，前置主要相機為 LIMITED 以上。
  • [7.5/H-1-4] 必須支援兩部主相機的 CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME。
  • [7.5/H-1-5] 必須在兩個主要相機的 ITS 照明條件 (3000K) 下，使用 CTS 相機 PerformanceTest 測量，相機 2 JPEG 擷取延遲時間 < 1000 毫秒 (1080p 解析度)。
  • [7.5/H-1-6] 在 ITS 照明條件 (3000K) 下，兩部主相機的 CTS 相機 PerformanceTest 測量結果，相機 2 的啟動延遲 (開啟相機至第一個預覽影格) 必須小於 500 毫秒。
  • [7.5/H-1-8] 必須支援主後置鏡頭的 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW 和 android.graphics.ImageFormat.RAW_SENSOR。
  • [7.5/H-1-9] 後置主相機必須支援 720p 或 1080p @ 240fps。
  • [7.5/H-1-10] 如果主鏡頭有超廣角 RGB 鏡頭，且朝向相同方向，則必須設為 ZOOM_RATIO 最小值 < 1.0。
  • [7.5/H-1-11] 必須在主要攝影機上實作同時前後串流。
  • [7.5/H-1-12] 必須同時支援主要前置鏡頭和主要後置鏡頭的 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION。
  • [7.5/H-1-13] 如果有超過 1 個 RGB 後置鏡頭，則必須支援主要後置鏡頭的 LOGICAL_MULTI_CAMERA 功能。
  • [7.5/H-1-14] 必須同時支援主要前置鏡頭和主要後置鏡頭的 STREAM_USE_CASE 功能。
  • [7.5/H-1-15] 必須透過 CameraX 和 Camera2 擴充功能支援主相機的夜間模式擴充功能。
  • [7.5/H-1-16] 必須支援主要攝影機的 DYNAMIC_RANGE_TEN_BIT 功能。
  • [7.5/H-1-17] 必須支援主相機的 CONTROL_SCENE_MODE_FACE_PRIORITY 和臉部偵測功能 (STATISTICS_FACE_DETECT_MODE_SIMPLE 或 STATISTICS_FACE_DETECT_MODE_FULL)。

Android 15 的新規定上路了

  • [7.5/H-1-18] 必須支援主要後置鏡頭和主要前置鏡頭的 JPEG_R。
  • [7.5/H-1-19] 必須支援 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION，以便在主後置鏡頭中，以 1080p HLG10 預覽畫面搭配最大尺寸 16:9 顯示比例 JPEG 和 720p HLG10 預覽畫面搭配最大尺寸 16:9 顯示比例 JPEG 串流組合。
  • [7.5/H-1-20] 原生相機應用程式中的主要後置鏡頭和主要前置鏡頭，預設輸出 JPEG_R。

新規定結束

2.2.7.3. 硬體

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.U，則會：

Android 15 的新規定上路了

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.V，則會：

新規定結束

  • [7.1.1.1/H-2-1] 螢幕解析度必須至少為 1080p。

Android 15 的新規定上路了

  • [7.1.1.3/H-2-1] 如果裝置的螢幕寬度小於 600 dp，則螢幕密度必須至少為 400 dpi。

新規定結束

  • [7.1.1.3/H-3-1] 必須具備 HDR 螢幕，且平均支援至少 1000 nits。

Android 15 的新規定上路了

新規定結束

2.2.7.4。成效

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.U，則會：

Android 15 的新規定上路了

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.V，則會：

新規定結束

  • [8.2/H-1-1] 必須確保序列寫入效能至少達到 150 MB/s。
  • [8.2/H-1-2] 必須確保隨機寫入效能至少為 10 MB/s。
  • [8.2/H-1-3] 必須確保序列讀取效能至少達到 250 MB/s。
  • [8.2/H-1-4] 必須確保隨機讀取效能至少達到 100 MB/s。
  • [8.2/H-1-5] 必須確保並行順序讀取和寫入效能，讀取效能須為 2 倍，寫入效能須為 1 倍，且至少達到 50 MB/s。

Android 15 的新規定上路了

2.2.7.5。圖形

如果手持裝置實作項目針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.V，則會：

新規定結束

2.3. 電視需求

Android 電視裝置是指 Android 裝置實作，為使用者提供娛樂介面，讓使用者坐在約 10 英尺 (約 3 公尺) 遠的地方觀看數位媒體、電影、遊戲、應用程式和/或直播電視 (稱為「躺椅」或「10 英尺使用者介面」)。

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

  • 提供機制，可在螢幕上遠端控制算繪的使用者介面，螢幕可能位於使用者前方 10 英尺 (約 3 公尺) 處。
  • 內建螢幕的對角線長度大於 24 吋，或內建影片輸出端口 (例如 VGA、HDMI、DisplayPort) 或顯示器的無線端口。

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

2.3.1. 硬體

電視裝置實作方式：

  • [7.2.2/T-0-1] 必須支援 D-pad。
  • [7.2.3/T-0-1] 必須提供「Home」和「Back」功能。
  • [7.2.3/T-0-2] 必須將返回功能 (KEYCODE_BACK) 的一般和長按事件傳送至前景應用程式。
  • [7.2.6.1/T-0-1] 必須支援遊戲控制器，並宣告 android.hardware.gamepad 功能旗標。
  • [7.2.7/T] 應提供遠端控制器，讓使用者存取非觸控式導覽功能和核心導覽鍵輸入內容。

如果電視裝置實作包含 3 軸式迴轉儀，則必須符合下列條件：

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

電視裝置實作方式：

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

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

  • [7.5.3/T-1-1] 必須支援透過此 USB 連接埠連線的外接相機，但不一定需要一直連線。

如果電視裝置實作是 32 位元：

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

    • 在小螢幕/一般螢幕上，解析度須達 400 dpi 以上
    • 大型螢幕：xhdpi 以上
    • 在超大螢幕上使用 tvdpi 或更高

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

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

    • 在小螢幕/一般螢幕上，解析度須達 400 dpi 以上
    • 大型螢幕：xhdpi 以上
    • 在超大螢幕上使用 tvdpi 或更高

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

電視裝置實作方式：

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

2.3.2. 多媒體

電視裝置實作方式必須支援下列音訊編碼和解碼格式，並提供給第三方應用程式：

  • [5.1/T-0-1] MPEG-4 AAC 設定檔 (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/T-0-3] AAC ELD (增強型低延遲 AAC)

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

  • [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] 以 Main Profile High Level 設定，以每秒 29.97 格數播放 HD 1080p。
  • [5.3.1/T-1-2] HD 1080i，每秒 59.94 格，採用主 Profile High 級別。必須解除交錯的 MPEG-2 影片，並提供給第三方應用程式。

如第 5.3.4 節所述，電視裝置實作方式必須支援 H.264 解碼，且以標準的影片影格速率和解析度運作，包括：

  • [5.3.4/T-1-1] 以 Baseline Profile 播放每秒 60 張影格的 HD 1080p 內容
  • [5.3.4/T-1-2] 以主 Profile 播放 60 fps 的 HD 1080p 內容
  • [5.3.4/T-1-3] 以每秒 60 影格播放 HD 1080p，並使用 High Profile Level 4.2

搭載 H.265 硬體解碼器的電視裝置實作方式，必須支援 H.265 解碼功能，如第 5.3.5 節所述，以標準視訊影格速率和解析度 (包括以下項目) 為限：

  • [5.3.5/T-1-1] 以 60 fps 的速度播放 HD 1080p 影片，並使用主 Profile Level 4.1

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

  • [5.3.5/T-2-1] 必須支援 UHD 解碼設定檔，以每秒 60 格的方式，使用 Main10 Level 5 Main Tier 設定檔

電視裝置實作方式必須支援 VP8 解碼，如第 5.3.6 節所述，以標準影片影格速率和解析度播放，包括：

  • [5.3.6/T-1-1] HD 1080p 以每秒 60 張影格的解碼設定檔

搭載 VP9 硬體解碼器的電視裝置實作方式，必須支援 VP9 解碼功能，如第 5.3.7 節所述，以標準的視訊影格速率和解析度 (包括以下項目)：

  • [5.3.7/T-1-1] 以每秒 60 張影格的 HD 1080p 播放，並使用設定檔 0 (8 位元色彩深度)

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

  • [5.3.7/T-2-1] 必須支援 UHD 解碼設定檔，以每秒 60 格和設定檔 0 (8 位元色彩深度) 為準。
  • [5.3.7/T-SR1] 強烈建議支援以 60 張/秒的速度，使用設定檔 2 (10 位元色彩深度) 解碼 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] 必須支援 HDCP 2.2。

如果電視裝置實作不支援 UHD 解碼，但支援透過 HDMI 連接的外接螢幕，則會發生以下情況：

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

2.3.3. 軟體

電視裝置實作方式：

  • [3/T-0-1] 必須宣告 android.software.leanback 和 android.hardware.type.television 功能。
  • [3.2.3.1/T-0-1] 對於由以下列出這裡的應用程式意圖定義的所有公開意圖篩選器模式，必須使用意圖處理常式預先載入一或多個應用程式或服務元件。
  • [3.4.1/T-0-1] 必須提供 android.webkit.Webview API 的完整實作。

如果 Android TV 裝置實作項目支援鎖定畫面，則會：

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

電視裝置實作方式：

  • [3.8.14/T-SR-1] 強烈建議您支援以多視窗模式支援圖片內圖片 (PIP) 模式。
  • [3.10/T-0-1] 必須支援第三方無障礙服務。
  • [3.10/T-SR-1] 強烈建議在裝置上預先載入無障礙服務，其功能與 TalkBack 開放原始碼專案提供的切換控制和 TalkBack (針對預先安裝的文字轉語音引擎支援的語言) 無障礙服務相當或更優。

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

  • [3.11/T-SR-1] 強烈建議您納入支援裝置上可用語言的 TTS 引擎。
  • [3.11/T-1-1] 必須支援安裝第三方 TTS 引擎。

Android 15 的新規定上路了

電視裝置實作方式：

  • [3.12/T-0-1] 必須支援 TV Input Framework。

新規定結束

Android 15 的新規定上路了

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

電視裝置實作方式：

  • [3/T-0-2] 必須宣告平台功能 android.software.live_tv。
  • [3/T-0-3] 必須支援所有 TIF API，以便使用這些 API 的應用程式和第三方 TIF 輸入來源服務，可在裝置上安裝及使用。

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

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

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

新規定結束

2.3.4. 效能和電源

  • [8.1/T-0-1] 一致的畫面延遲。影格延遲時間不一致或轉譯影格延遲的情況，每秒不得超過 5 個影格，且每秒應低於 1 個影格。
  • [8.2/T-0-1] 必須確保序列寫入效能至少為 5 MB/s。
  • [8.2/T-0-2] 必須確保隨機寫入效能至少為 0.5MB/s。
  • [8.2/T-0-3] 必須確保序列讀取效能至少為 15 MB/s。
  • [8.2/T-0-4] 必須確保隨機讀取效能至少為 3.5MB/s。

如果電視裝置實作內容包含改善裝置電源管理的功能 (包含在 AOSP 中)，或擴充 AOSP 中的功能，則必須符合下列條件：

  • [8.3/T-1-1] 必須提供使用者啟用和停用省電模式功能的操作元素。

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

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

  • [8.3/T-1-3] 必須提供使用者操作提示，以便顯示所有不受應用程式待命和 Doze 省電模式影響的應用程式。

電視裝置實作方式：

  • [8.4/T-0-1] 必須提供每個元件的電源設定檔，定義每個硬體元件的電流消耗值，以及元件隨時間推移造成的電池耗電量估計值，如 Android 開放原始碼計畫網站所述。
  • [8.4/T-0-2] 必須以毫安培小時 (mAh) 回報所有耗電量值。
  • [8.4/T-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫透過 uid_cputime 核心模組實作來滿足這項需求。
  • [8.4/T] 如果無法將硬體元件的耗電量歸因於應用程式，應歸因於硬體元件本身。
  • [8.4/T-0-4] 必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供這項電量用量資訊。

2.3.5. 安全性模型

電視裝置實作方式：

  • [9/T-0-1] 必須宣告 android.hardware.security.model.compatible 功能。
  • [9.11/T-0-1] 必須使用獨立的執行環境備份 KeyStore 實作。
  • [9.11/T-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上層級執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離功能必須封鎖所有潛在機制，以免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 使用 Trusty 實作項目來滿足這項要求，但其他以 ARM TrustZone 為基礎的解決方案，或第三方審查的安全實作項目，也是適當的虛擬機器人隔離方式。
  • [9.11/T-0-3] 必須在隔離的執行環境中執行螢幕鎖定畫面驗證，且只有在成功驗證後，才允許使用與驗證綁定的金鑰。螢幕鎖定憑證必須以允許只有隔離執行環境執行螢幕鎖定驗證的方式儲存。上游 Android 開放原始碼專案提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項要求。

Android 15 的新規定上路了

  • [9.11/T-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業是在安全硬體中執行。認證簽署金鑰必須 在足夠多裝置上共用，才能避免金鑰 遭到阻止，無法用於永久裝置識別。如要符合這項規定，您可以共用相同的認證金鑰，除非您已製造出至少 100,000 個特定 SKU，如果某個 SKU 的產量超過 100,000 個，則每 100,000 個單位可能會使用不同的鍵。

新規定結束

請注意，如果裝置實作已在較舊的 Android 版本上推出，則該裝置不必符合要求，即不必具備由隔離執行環境支援的 KeyStore，也不必支援金鑰認證，除非該裝置宣告 android.hardware.fingerprint 功能，而該功能需要由隔離執行環境支援的 KeyStore。

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

  • [9.11/T-1-1] 必須允許使用者選擇休眠逾時值，以便從解鎖狀態切換為鎖定狀態，且允許的逾時值最短為 15 秒。

如果電視裝置實作包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

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

如果電視裝置實作包含多位使用者，並宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

  • [9.5/T-3-1] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作方式一致，才能啟用 /停用其他使用者存取語音通話和簡訊的權限。

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

  • [9.8.2/T-4-1] 應用程式存取麥克風的音訊資料時，必須顯示麥克風指標，但如果只有 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或應用程式 (持有 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.8.2/T-5-2] 對於具有可見使用者介面或直接使用者互動的系統應用程式，請務必不要隱藏攝影機指示燈。

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

Android 15 新規定生效

電視裝置實作方式：

  • Perfetto
    • [6.1/T-0-1] 必須將 /system/bin/perfetto 二進位檔公開給殼層使用者，該使用者的 cmdline 必須符合 Perfetto 說明文件。
    • [6.1/T-0-2] Perfetto 二進位檔必須接受符合 Perfetto 說明文件中定義的結構定義，並將其做為 protobuf 設定的輸入內容。
    • [6.1/T-0-3] Perfetto 二進位檔必須將符合 Perfetto 說明文件中定義的結構定義，以輸出格式寫入 protobuf 追蹤記錄。
    • [6.1/T-0-4] 您必須透過 Perfeto 二進位檔提供至少一個 Perfeto 說明文件中所述的資料來源。
    • [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] 必須提供「Home」功能供使用者使用，且「Back」功能只能在 UI_MODE_TYPE_WATCH 中使用。

  • [7.2.4/W-0-1] 必須支援觸控螢幕輸入。

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

如果手錶裝置實作內容包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，則會發生以下情況：

  • [7.3.3/W-1-1] 一旦偵測到 GNSS 測量結果，就必須立即回報，即使尚未回報透過 GPS/GNSS 計算的位置也一樣。
  • [7.3.3/W-1-2] 必須回報 GNSS 偽距和偽距速率，在確定位置後，在靜止或以每秒 0.2 公尺平方以下的加速度移動時，至少有 95% 的時間，系統都能計算出 20 公尺以內的位置和每秒 0.2 公尺以內的速度。

如果 Watch 裝置實作包含 3 軸式迴轉儀，則會：

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

智慧手錶裝置實作方式：

  • [7.4.3/W-0-1] 必須支援藍牙。

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

  • [7.6.1/W-0-2] 核心和使用者空間必須至少有 416 MB 記憶體可用。

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

  • [7.8.2/W] 可能會有音訊輸出。

2.4.2. 多媒體

沒有其他規定。

2.4.3. 軟體

智慧手錶裝置實作方式：

  • [3/W-0-1] 必須宣告 android.hardware.type.watch 功能。
  • [3/W-0-2] 必須支援 uiMode = UI_MODE_TYPE_WATCH。
  • [3.2.3.1/W-0-1] 對於由此處列出的應用程式意圖定義的所有公開意圖篩選器模式，必須使用意圖處理常式預先載入一或多個應用程式或服務元件。

智慧手錶裝置實作方式：

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

請查看宣告 android.hardware.audio.output 功能標記的裝置實作項目：

  • [3.10/W-1-1] 必須支援第三方無障礙服務。
  • [3.10/W-SR-1] 強烈建議在裝置上預先載入與 TalkBack 開放原始碼專案提供的切換控制和 TalkBack (針對預先安裝的文字轉語音引擎支援的語言) 無障礙服務相若或更優的無障礙服務。

如果手錶裝置實作項目回報 android.hardware.audio.output 功能，則會：

  • [3.11/W-SR-1] 強烈建議您納入支援裝置上可用語言的 TTS 引擎。

  • [3.11/W-0-1] 必須支援安裝第三方 TTS 引擎。

2.4.4. 效能和電源

如果手錶裝置實作功能包含改善裝置電源管理的功能 (已納入 AOSP)，或擴充 AOSP 中的功能，則必須符合下列條件：

  • [8.3/W-SR-1] 強烈建議您提供使用者操作提示，以便顯示所有不受應用程式待命和 Doze 省電模式影響的應用程式。
  • [8.3/W-SR-2] 強烈建議提供使用者操作提示，讓使用者啟用及停用省電模式。

智慧手錶裝置實作方式：

  • [8.4/W-0-1] 必須提供每個元件的電源設定檔，定義每個硬體元件的電流消耗值，以及元件隨時間推移所造成的電池耗電量估計值，如 Android 開放原始碼專案網站所述。
  • [8.4/W-0-2] 必須以毫安培小時 (mAh) 回報所有耗電量值。
  • [8.4/W-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫透過 uid_cputime 核心模組實作來滿足這項需求。
  • [8.4/W-0-4] 必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供這項電量用量資訊。
  • 如果無法將硬體元件的耗電量歸因於應用程式，則應將 [8.4/W] 歸因於硬體元件本身。

2.4.5. 安全性模型

智慧手錶裝置實作方式：

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

如果手錶裝置實作包含多位使用者，且未宣告 android.hardware.telephony 功能標記，則會發生以下情況：

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

如果手錶裝置實作包含多位使用者，並宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

  • [9.5/W-2-1] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作方式一致，才能啟用 /停用其他使用者存取語音通話和簡訊的權限。

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

  • [9.11.1/W-1-1] 必須每隔 72 小時以上，才可要求使用者提供建議的主要驗證方法 (例如 PIN 碼、圖案、密碼)。

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。

Android 15 的新規定上路了

如果車用裝置實作支援並行多使用者功能 (即多位 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] 必須包含 Vulkan 載入器，並匯出所有符號。

汽車裝置實作方式：

Android 15 的新規定上路了

新規定結束

Android 15 的新規定上路了

如果車用裝置實作支援並行多使用者功能 (即多位 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] 強烈建議為有限軸加速計實作複合感應器。

如果車用裝置實作項目包含的加速計軸數少於 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] 強烈建議將陀螺儀的測量範圍設為 +/-250dps，以便盡可能提高解析度。

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

  • [7.3.4/A-SR-2] 強烈建議為有限軸陀螺儀實作複合感應器。

如果車用裝置實作項目包含的迴轉儀軸數少於 3 軸，則必須符合下列規定：

  • [7.3.4/A-4-1] 必須實作並回報 TYPE_GYROSCOPE_LIMITED_AXES 感應器。
  • [7.3.4/A-4-2] 必須實作並回報 TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED 感應器。

如果車用裝置實作項目包含 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] 必須能夠回報至少 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) 分享聯絡人。

Android 15 的新規定上路了

  • [7.4.3/A-SR-1] 強烈建議如果裝置有駕駛人座位區域，則應支援 Message Access Profile (MAP)。

新規定結束

Android 15 的新規定上路了

如果車用裝置實作支援並行多使用者功能 (即多位 Android 使用者可同時與裝置互動，並在啟用 config_multiuserVisibleBackgroundUsers 時使用各自的螢幕)，則會發生以下情況：

  • [7.4.3/A-1-1] 必須獨立運作，且不得干擾其他使用者的藍牙體驗。

新規定結束

汽車裝置實作方式：

  • [7.4.5/A] 應支援行動網路資料連線。
  • [7.4.5/A] 可針對系統應用程式可用的網路使用 System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常數。

如果裝置實作內容支援 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 平面對齊。

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

  • [7.5/A-3-1] 必須遵守第 7.5 節中的核心攝影機要求。

如果 Automotive 裝置實作內容包含無法透過 android.hardware.Camera 或 android.hardware.camera2 API 存取的相機，則：

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

如果車用裝置實作項目包含可透過 Extended View 系統服務存取的一或多部攝影機，則針對這類攝影機，系統會執行以下操作：

  • [7.5/A-5-1] 不得旋轉或水平鏡像相機預覽畫面。
  • [7.5/A-SR-4] 強烈建議解析度至少為 1.3 百萬像素。

如果車用裝置實作內容包含一或多部相機，且可透過 Extended View System Service 和 android.hardware.Camera 或 android.hardware.Camera2 API 存取，則針對這類相機，以下情況會發生：

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

如果車用裝置實作項目提供專屬相機 API，則會：

汽車裝置實作方式：

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

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

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

  • [7.6.1/A-SR-1] 強烈建議您減少在外部儲存空間上執行作業的 I/O 額外負擔，例如使用 SDCardFS。

Android 15 的新規定上路了

如果車用裝置實作支援並行多使用者功能 (即多位 Android 使用者可同時與裝置互動，並在啟用 config_multiuserVisibleBackgroundUsers 時使用各自的螢幕)，則會發生以下情況：

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

新規定結束

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

Android 15 的新規定上路了

  • [7.6.1/A-2-1] 如果使用下列任一密度，則核心和使用者空間可用的記憶體必須至少為 816 MB/主要顯示畫面：

    • 在小螢幕/一般螢幕上，解析度為 280 dpi 以下
    • 在超大螢幕上使用 ldpi 或更低的密度
    • 大型螢幕的 mdpi 或更低

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

    • 小型/一般螢幕：xhdpi 以上
    • 在大型螢幕上使用 hdpi 或更高解析度
    • 超大螢幕：mdpi 以上

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

    • 在小螢幕/一般螢幕上，解析度須達 400 dpi 以上
    • 大型螢幕：xhdpi 以上
    • 在超大螢幕上使用 tvdpi 或更高

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

    • 在小螢幕/一般螢幕上，至少為 560 dpi
    • 大螢幕的 400 dpi 以上
    • xhdpi 或更高 (超大螢幕)

請注意，上述「可供核心和使用者空間使用的記憶體」是指除了已專用於硬體元件 (例如無線電、影片等) 的記憶體之外，提供的記憶體空間，這些記憶體並未受限於裝置實作方式的核心控制。

新規定結束

汽車裝置實作方式：

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

汽車裝置實作方式：

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

汽車裝置實作方式：

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

Android 15 的新規定上路了

如果車用裝置實作支援並行多使用者功能 (即多位 Android 使用者可同時與裝置互動，並在啟用 config_multiuserVisibleBackgroundUsers 時使用各自的螢幕)，則會發生以下情況：

  • [7.8.2/A-1-1] 每個主螢幕都必須有音訊輸出裝置，以便同時支援多個使用者系統。
  • [7.8.2/A-1-2] 駕駛音訊區必須涵蓋車室內的全球喇叭。前座乘客區域可以與駕駛座區域共用音訊區域，也可以有自己的音訊輸出裝置。

新規定結束

2.5.2. 多媒體

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

  • [5.1/A-0-1] MPEG-4 AAC 設定檔 (AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/A-0-3] AAC ELD (增強型低延遲 AAC)

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

  • [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 15 的新規定上路了

如果車用裝置實作支援並行多使用者功能 (即多位 Android 使用者可同時與裝置互動，並在啟用 config_multiuserVisibleBackgroundUsers 時使用各自的螢幕)，則會發生以下情況：

  • [5.5.3/A-1-1] 必須為所有音訊輸出串流定義相同的音量曲線，這些串流會對應至汽車音訊設定檔案中定義的相同音量群組。

新規定結束

2.5.3. 軟體

汽車裝置實作方式：

  • [3/A-0-1] 必須宣告 android.hardware.type.automotive 功能。

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

  • [3/A-0-3] 必須支援 android.car.* 命名空間中的所有公開 API。

如果 Automotive 裝置實作項目使用 android.car.VehiclePropertyIds 搭配 android.car.CarPropertyManager 提供專屬 API，則會發生以下情況：

  • [3/A-1-1] 不得為系統應用程式使用這些屬性附加特殊權限，或禁止第三方應用程式使用這些屬性。
  • [3/A-1-2] 請勿複製 SDK 中已存在的車輛屬性。

汽車裝置實作方式：

  • [3.2.1/A-0-1] 必須支援並強制執行所有權限常數，如汽車權限參考頁面所述。

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

  • [3.4.1/A-0-1] 必須提供 android.webkit.Webview API 的完整實作。

Android 15 的新規定上路了

  • [3.8/A-0-1] 不得允許非目前前景使用者的完整次要使用者啟動活動，並在任何螢幕上存取 UI。

如果車用裝置實作支援並行多使用者功能 (即多位 Android 使用者可同時與裝置互動，並在啟用 config_multiuserVisibleBackgroundUsers 時使用各自的螢幕)，則會發生以下情況：

  • [3.8/A-1-1] 必須針對非目前前景使用者，但具有已指派給他們的顯示畫面 UI 存取權的完整次要使用者，實作下列預先定義的 UserRestrictions 清單。UserRestrictions 清單包括 DISALLOW_CONFIG_LOCALE、DISALLOW_CONFIG_BLUETOOTH、DISALLOW_BLUETOOTH、DISALLOW_CAMERA_TOGGLE 和 DISALLOW_MICROPHONE_TOGGLE。

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

新規定結束

汽車裝置實作方式：

如果車用裝置實作包含按下通話按鈕，則必須符合下列規定：

  • [3.8.4/A-1-1] 必須使用短暫按下推播通話按鈕的指定互動動作，才能啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式。

汽車裝置實作方式：

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

汽車裝置實作方式：

如果車用裝置實作內容包含預設啟動器應用程式，則必須符合下列規定：

汽車裝置實作方式：

  • [3.8/A] 可限制應用程式要求進入全螢幕模式，如 immersive documentation 所述。
  • [3.8/A] 可隨時顯示狀態列和導覽列。
  • [3.8/A] 可限制應用程式要求變更系統 UI 元素背後的顏色，以確保這些元素隨時都能清楚顯示。

2.5.4. 效能和電源

汽車裝置實作方式：

  • [8.2/A-0-1] 必須針對每個程序的 UID 回報讀取和寫入至非揮發性儲存空間的位元組數量，以便開發人員透過系統 API android.car.storagemonitoring.CarStorageMonitoringManager 取得統計資料。Android 開放原始碼專案透過 uid_sys_stats 核心模組滿足這項需求。
  • [8.3/A-1-3] 必須支援車庫模式。
  • [8.3/A] 應在每次行駛後至少處於車庫模式 15 分鐘，除非：
    • 電池電量耗盡。
    • 沒有排程閒置的工作。
    • 駕駛者退出車庫模式。
  • [8.4/A-0-1] 必須提供個別元件的電源設定檔，定義每個硬體元件的電流消耗值，以及這些元件隨時間推移所造成的電池耗電量估計值，如 Android 開放原始碼專案網站所述。
  • [8.4/A-0-2] 必須以毫安培小時 (mAh) 為單位回報所有耗電量值。
  • [8.4/A-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫透過 uid_cputime 核心模組實作來滿足這項需求。
  • [8.4/A] 如果無法將硬體元件的耗電量歸因於應用程式，則應歸因於硬體元件本身。
  • [8.4/A-0-4] 必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供這項電量用量資訊。

2.5.5. 安全性模型

如果車用裝置實作支援多位使用者，則應符合下列條件：

如果車用裝置實作宣告 android.hardware.microphone，則會：

  • [9.8.2/A-1-1] 應用程式存取麥克風的音訊資料時，必須顯示麥克風指示燈，但如果只有 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或具有 CDD 識別碼 [C-4-X] 的應用程式存取麥克風，則不必顯示麥克風指示燈。第 9.1 節
  • [9.8.2/A-1-2] 對於具有可見使用者介面或直接使用者互動的系統應用程式，請務必不要隱藏麥克風指示燈。
  • [9.8.2/A-1-3] 必須提供使用者操作提示，讓使用者在「設定」應用程式中切換麥克風。

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

  • [9.8.2/A-2-1] 應用程式存取即時攝影機資料時，必須顯示攝影機指標，但如果只有具備 CDD 識別碼 [C-4-X] 的應用程式存取攝影機，則不必顯示攝影機指標。第 9.1 節權限中定義的角色。
  • [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] 必須使用獨立的執行環境備份 KeyStore 實作。
  • [9.11/A-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上層級執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離功能必須封鎖所有潛在機制，以免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 使用 Trusty 實作項目來滿足這項要求，但其他以 ARM TrustZone 為基礎的解決方案，或第三方審查的安全實作項目，也是適當的虛擬機器人隔離方式。
  • [9.11/A-0-3] 必須在隔離的執行環境中執行螢幕鎖定畫面驗證，且只有在成功驗證後，才允許使用與驗證綁定的金鑰。螢幕鎖定憑證必須以允許只有隔離執行環境執行螢幕鎖定驗證的方式儲存。上游 Android 開放原始碼專案提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項要求。

Android 15 的新規定上路了

  • [9.11/A-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業是在安全硬體中執行。認證簽署金鑰必須 在足夠多裝置上共用，才能避免金鑰 遭到阻止，無法用於永久裝置識別。如要符合這項規定，您可以共用相同的認證金鑰，除非您已製造出至少 100,000 個特定 SKU，如果某個 SKU 的產量超過 100,000 個，則每 100,000 個單位可能會使用不同的鍵。

新規定結束

請注意，如果裝置實作已在較舊的 Android 版本上推出，則該裝置不必符合要求，即不必具備由隔離執行環境支援的 KeyStore，也不必支援金鑰認證，除非該裝置宣告 android.hardware.fingerprint 功能，而該功能需要由隔離執行環境支援的 KeyStore。

汽車裝置實作方式：

  • [9.14/A-0-1] 必須從 Android 架構車輛子系統中篩選訊息，例如將允許的訊息類型和訊息來源加入許可清單。
  • [9.14/A-0-2] 必須使用監視器，防範來自 Android 架構或第三方應用程式的拒絕服務攻擊。這可防止惡意軟體將流量大量傳送至車輛網路，進而導致車輛子系統發生故障。

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

Android 15 的新規定上路了

汽車裝置實作方式：

  • Perfetto
    • [6.1/A-0-1] 必須將 /system/bin/perfetto 二進位檔公開給殼層使用者，該使用者的 cmdline 必須符合 Perfetto 說明文件。
    • [6.1/A-0-2] Perfetto 二進位檔必須接受符合 Perfetto 說明文件中定義的結構定義的 protobuf 設定檔做為輸入內容。
    • [6.1/A-0-3] Perfetto 二進位檔必須將符合 Perfetto 說明文件中定義的結構定義，以輸出 protobuf 追蹤記錄的形式寫入。
    • [6.1/A-0-4] 必須透過 Perfeto 二進位檔提供至少 Perfeto 說明文件中所述的資料來源。
    • [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] 必須能夠測量每秒 1000 度以內的方向變化。

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

在手持裝置規範中，針對小螢幕/一般螢幕列出的螢幕密度不適用於平板電腦。

Android 15 的新規定上路了

USB 周邊裝置模式 (第 7.7.1 節)

如果平板電腦裝置實作內容包含支援周邊模式的 USB 連接埠，則會：

  • [7.7.1/Tab] 可實作 Android Open Accessory (AOA) API。

新規定結束

虛擬實境模式 (第 7.9.1 節)

虛擬實境高效能 (第 7.9.2 節)

虛擬實境規定不適用於平板電腦。

2.6.2. 安全性模型

金鑰和憑證 (第 9.11 節)

請參閱第 [9.11] 節。

如果平板電腦裝置實作包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

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

如果平板電腦裝置實作包含多位使用者，並宣告 android.hardware.telephony 功能旗標，則會發生以下情況：

  • [9.5/T-2-1] 不得支援受限制的設定檔，但必須與 AOSP 的控制項實作方式一致，才能啟用 /停用其他使用者存取語音通話和簡訊的權限。

2.6.2. 軟體

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

3. 軟體

3.1. 代管 API 相容性

受管理的 Dalvik 位元碼執行環境是 Android 應用程式的主要載具。Android 應用程式設計介面 (API) 是向在受控執行階段環境中執行的應用程式公開的 Android 平台介面集合。

裝置實作方式：

  • [C-0-1] 必須提供完整的實作項目，包括 Android SDK 公開的任何已記錄 API 或在上游 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 啟動作業 classpath 中 Java 語言套件中的方法和欄位，且不屬於公開 SDK 的一部分。這包括使用 @hide 註解修飾的 API (但未使用 @SystemAPI)，如 SDK 文件所述，以及私人和套件私人類別成員。

  • [C-0-6] 必須與每個非 SDK 介面一併發布，且這些介面必須列於 AOSP 中相應 API 級別分支的 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路徑中，透過暫時性和拒絕清單旗標提供的受限制清單。

  • [C-0-7] 必須支援已簽署的設定檔動態更新機制，藉此使用 AOSP 中現有的公開金鑰，在任何 APK 中嵌入已簽署的設定檔，從受限制清單中移除非 SDK 介面。

    不過，

    • 可行，如果隱藏的 API 在裝置實作中不存在或實作方式不同，請將隱藏的 API 移至拒絕清單，或從所有受限制的清單中略過。
    • 可行，如果 AOSP 中沒有隱藏的 API，請將隱藏的 API 加入任何限制清單。

Android 15 的新規定上路了

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

新規定結束

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] 請務必只傳回 AOSP 定義的有效擴充功能版本號碼。

  • [C-0-3] 必須按照第 3.1 節的規定，以與其他受管理 API 相同的方式支援 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) 傳回的擴充功能版本所定義的所有 API。

3.1.2. Android 程式庫

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

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

AOSP 實作方式符合這些需求。

3.2. 軟性 API 相容性

除了第 3.1 節中的受管理 API，Android 也包含重要的「軟性」API，僅適用於執行階段，這類 API 的形式包括意圖、權限，以及無法在應用程式編譯期間強制執行的 Android 應用程式類似層面。

3.2.1. 權限

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

3.2.2. 建構參數

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

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

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

例如：

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

指紋不得包含空白字元。這個欄位的值必須能以 7 位元 ASCII 編碼。
硬體 硬體名稱 (來自核心命令列或 /proc)。應以人類可讀的方式呈現。此欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 ^[a-zA-Z0-9_-]+$。
HOST 這個字串可用於以人類可讀格式，唯一識別建構所在主機。這個欄位的格式沒有特定規定，但不得為空值或空字串 ("")。
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.,_-]+)$。
SERIAL 必須傳回「UNKNOWN」。
標記 以半形逗號分隔的清單，列出裝置實作者選擇的標記，可進一步區分版本。標記必須能以 7 位元 ASCII 編碼，且符合規則運算式 ^[a-zA-Z0-9._-]+，且必須有一個值對應於三個典型的 Android 平台簽署設定：發布版金鑰、開發版金鑰和測試版金鑰。
時間 代表建構作業發生時間的時間戳記值。
類型 裝置實作者選擇的值，可指定建構作業的執行階段設定。這個欄位必須包含一個值，對應至三種常見的 Android 執行階段設定：user、userdebug 或 eng。
使用者 產生版本的使用者 (或自動化使用者) 的名稱或使用者 ID。這個欄位的格式沒有特定規定，但不得為空值或空字串 ("")。
SECURITY&lowbar;PATCH 這個值表示版本的安全性修補程式等級。這必須表示此版本在任何方面都不會受到指定 Android 公開安全性公告中所述問題的影響。格式必須為 [YYYY-MM-DD]，且必須與 Android 公共安全性公告或 Android 安全性警示中定義的字串相符，例如「2015-11-01」。
BASE&lowbar;OS 這個值代表建構版本的 FINGERPRINT 參數，除了 Android 公開安全性公告中提供的修補程式外，其他都與此建構版本相同。此值必須回報正確的值，如果不存在此版本，則回報空字串 ("")。
BOOTLOADER 裝置實作者選擇的值，用於識別裝置中使用的特定內部系統啟動載入程式版本，並以人類可讀的格式呈現。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 ^[a-zA-Z0-9._-]+$。
getRadioVersion() 必須 (或傳回) 裝置實作者選擇的值，以人類可讀的格式識別裝置中使用的特定內部無線電/調變器版本。如果裝置沒有任何內部無線電/數據機，則必須傳回 NULL。此欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 ^[a-zA-Z0-9._-,]+$。
getSerial() 必須 (或傳回) 硬體序號，且該序號必須可用，且在型號和製造商相同的裝置中不重複。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 ^[a-zA-Z0-9]+$。

3.2.3. 意圖相容性

3.2.3.1. 常見的應用程式意圖

Android 意圖可讓應用程式元件向其他 Android 元件要求功能。Android 上游專案包含應用程式清單，這些應用程式會實作多種意圖模式，用於執行常見動作。

裝置實作方式：

  • [C-SR-1] 強烈建議您使用意圖處理常規，針對以下列出「這裡」所列應用程式意圖定義的所有公開意圖篩選器模式，預先載入一或多個應用程式或服務元件，並提供滿足 SDK 中所述這些常見應用程式意圖的開發人員期望。

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

3.2.3.2. 意圖解析

  • [C-0-1] 由於 Android 是可擴充的平台，因此裝置實作必須允許第三方應用程式覆寫 第 3.2.3.1 節中所參照的每個意圖模式 (「設定」除外)。上游 Android 開放原始碼實作項目預設允許這項功能。

  • [C-0-2] 裝置實作者不得為系統應用程式使用這些意圖模式時附加特殊權限，或禁止第三方應用程式繫結至這些模式並接管控制權。這項禁止行為包括但不限於停用「選擇器」使用者介面，該介面可讓使用者在多個應用程式之間進行選擇，這些應用程式都會處理相同的意圖模式。

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

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

Android 也提供機制，讓第三方應用程式為特定類型的網頁 URI 意圖宣告權威預設的應用程式連結行為。如果在應用程式意圖篩選器模式中定義這類權威聲明，裝置實作方式如下：

  • [C-0-4] 必須嘗試驗證任何意圖篩選器，方法是執行 Digital Asset Links 規格中定義的驗證步驟，並由上游 Android 開放原始碼專案中的 Package Manager 實作。
  • [C-0-5] 必須在安裝應用程式時嘗試驗證意圖篩選器，並將所有已成功驗證的 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。
  • 可將特定 URI 意圖篩選器設為其 URI 的預設應用程式處理常式，前提是這些篩選器已成功驗證，但其他候選 URI 篩選器驗證失敗。如果裝置實作這項功能，則必須在設定選單中提供適合使用者的個別 URI 模式覆寫值。
  • 必須在「設定」中為使用者提供個別應用程式 App Links 控制項，如下所示：
    • [C-0-6] 使用者必須能夠全面覆寫應用程式的預設應用程式連結行為，包括一律開啟、一律詢問或一律不開啟，且這些行為必須一律套用至所有候選 URI 意圖篩選器。
    • [C-0-7] 使用者必須能夠查看候選 URI 意圖篩選器清單。
    • 裝置實作可能會讓使用者能夠根據個別意圖篩選器，覆寫已成功驗證的特定候選 URI 意圖篩選器。
    • [C-0-8] 如果裝置實作讓部分候選 URI 意圖篩選器驗證成功，但其他候選 URI 意圖篩選器驗證失敗，則裝置實作必須提供使用者查看及覆寫特定候選 URI 意圖篩選器的功能。
3.2.3.3. 意圖命名空間
  • [C-0-1] 裝置實作內容不得包含任何 Android 元件，這些元件會使用 android.* 或 com.android.* 命名空間中的 ACTION、CATEGORY 或其他關鍵字串，遵循任何新的意圖或廣播意圖模式。
  • [C-0-2] 裝置實作者不得在屬於其他機構的套件空間中，使用 ACTION、CATEGORY 或其他關鍵字串，納入任何遵循新意圖或廣播意圖模式的 Android 元件。
  • [C-0-3] 裝置實作者不得變更或擴充第 3.2.3.1 節所列的任何意圖模式。
  • 裝置實作可能會包含意圖模式，使用與其自身組織相關聯的命名空間。這項禁止規定與 第 3.6 節中針對 Java 語言類別所指定的規定類似。
3.2.3.4. 廣播意圖

第三方應用程式會依賴平台發布特定意圖，以便通知硬體或軟體環境的變更。

裝置實作方式：

  • [C-0-1] 必須根據 SDK 說明文件的說明，針對適當的系統事件廣播 此處列出的公開廣播意圖。請注意，這項規定不會與第 3.5 節相衝突，因為 SDK 文件中也說明瞭背景應用程式的限制。此外，某些廣播意圖會依硬體支援情況而定，如果裝置支援必要的硬體，就必須廣播意圖，並提供與 SDK 說明文件一致的行為。
3.2.3.5. 條件式應用程式意圖

Android 提供的設定可讓使用者輕鬆選取預設應用程式，例如主畫面或簡訊。

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

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

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

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

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

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

如果裝置實作支援 DND 功能，則會：

  • [C-6-1] 必須實作可回應意圖 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS 的活動，如果是使用 UI_MODE_TYPE_NORMAL 的實作項目，則該活動必須是使用者可授予或拒絕應用程式 DND 政策設定存取權的活動。

如果裝置實作可讓使用者在裝置上使用第三方輸入法，則使用者可：

如果裝置實作支援第三方無障礙服務，則必須符合下列條件：

  • [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 意圖，授予或撤銷使用者統計資料的存取權。

如果裝置實作方式不允許任何應用程式 (包括預先安裝的應用程式) 存取使用統計資料，則應採取以下做法：

如果裝置實作項目顯示的連結可連至「設定」中 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 支援互動式螢幕保護程式，這項功能先前稱為「Dreams」。當裝置連接至電源處於閒置狀態，或已連接至桌面底座時，使用者可以透過螢幕保護程式與應用程式互動。裝置實作方式：

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

如果裝置實作項目回報 android.hardware.nfc.uicc 或 android.hardware.nfc.ese，則會發生以下情況：

3.2.4. 輔助/多個螢幕上的活動

如果裝置實作允許在多個螢幕上啟動一般 Android 活動，則會執行以下操作：

如果裝置實作可在次要螢幕上啟動一般 Android 活動，且次要螢幕具有 android.view.Display.FLAG_PRIVATE 標記：

  • [C-3-1] 只有該螢幕的擁有者、系統和已在該螢幕上執行的活動，才能啟動該螢幕。任何人都可以啟動具有 android.view.Display.FLAG_PUBLIC 標記的螢幕。

3.3. 原生 API 相容性

原生程式碼的相容性很難處理。因此，裝置實作者必須：

  • [C-SR-1] 強烈建議您使用下列程式庫的實作項目，這些程式庫來自上游 Android 開放原始碼專案。

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

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

裝置實作方式：

  • [C-0-1] 必須與一或多個已定義的 Android NDK ABI 相容。
  • [C-0-2] 必須支援在受管理環境中執行的程式碼，以便使用標準 Java Native Interface (JNI) 語意，呼叫原生程式碼。
  • [C-0-3] 必須與下列清單中的每個必要程式庫相容 (即標頭相容)，並與 ABI 相容 (針對 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 清單，並依優先順序排列。

Android 15 的新規定上路了

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

新規定結束

  • [C-0-7] 必須為提供原生 API 的下列所有程式庫，提供可供包含原生程式碼的應用程式使用的程式庫：

    • libaaudio.so (AAudio 原生音訊支援)
    • libamidi.so (如果宣告的功能為 android.software.midi，則支援原生 MIDI)
    • libandroid.so (原生 Android 活動支援)
    • libc (C 程式庫)
    • libcamera2ndk.so
    • libdl (動態連結器)
    • libEGL.so (原生 OpenGL 途徑管理)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog (Android 記錄)
    • libmediandk.so (原生媒體 API 支援)
    • libm (數學程式庫)
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.so (支援 OpenMAX AL 1.0.1)
    • libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
    • libRS.so
    • libstdc++ (最少的 C++ 支援)
    • libvulkan.so (Vulkan)
    • libz (Zlib 壓縮)
    • JNI 介面

  • [C-0-8] 請勿為上述原生程式庫新增或移除公開函式。

  • [C-0-9] 必須在 /vendor/etc/public.libraries.txt 中列出直接公開給第三方應用程式的其他非 AOSP 程式庫。

  • [C-0-10] 不得將任何其他原生程式庫公開給以 API 級別 24 以上為目標版本的第三方應用程式，因為這些程式庫已保留。

  • [C-0-11] 必須透過 libGLESv3.so 程式庫，匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android 擴充套件函式符號。請注意，雖然必須提供所有符號，但第 7.1.4.1 節會進一步說明各個對應函式應在何時完全實作。

  • [C-0-12] 必須為核心 Vulkan 1.1 函式符號匯出函式符號，以及透過 libvulkan.so 程式庫匯出 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 擴充功能。請注意，雖然必須提供所有符號，但第 7.1.4.2 節會更詳細說明各個對應函式應在何時完全實作。

  • 應使用上游 Android 開放原始碼專案提供的原始碼和標頭檔案進行建構。

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

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

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

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

如果裝置實作項目回報支援 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] 必須支援 Advanced SIMD (又稱為 NEON) 擴充功能。

3.4. 網頁相容性

3.4.1. WebView 相容性

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

  • [C-1-1] 必須回報 android.software.webview。
  • [C-1-2] 如要實作 android.webkit.WebView API，必須使用 Android 15 分支上源自上游 Android 開放原始碼專案的 Chromium 專案版本。

  • [C-1-3] WebView 回報的使用者代理程式字串必須採用以下格式：

    Mozilla/5.0 (Linux；Android $(VERSION)；[$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE 的值相同。
    • $(MODEL) 字串可為空白，但如果不為空白，則必須與 android.os.Build.MODEL 的值相同。
    • 「Build/$(BUILD)」可省略，但如果使用了這個值，$(BUILD) 字串必須與 android.os.Build.ID 的值相同。
    • $(CHROMIUM_VER) 字串的值必須是上游 Android 開放原始碼專案中的 Chromium 版本。
    • 裝置實作可能會省略使用者代理程式字串中的「Mobile」。

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

  • [C-1-4] 必須在與建立 WebView 的應用程式不同的程序中，轉譯提供的內容或遠端網址內容。具體來說，獨立的轉譯器程序必須持有較低的權限，以獨立的使用者 ID 執行，無法存取應用程式的資料目錄，也無法直接存取網路，且只能透過 Binder 存取必要的最低系統服務。AOSP 實作的 WebView 符合這項規定。

請注意，如果裝置實作是 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。請注意，由於網路開發標準機構正從 webstorage 轉為偏好 IndexedDB，因此 IndexedDB 預計將成為日後 Android 版本的必要元件。
  • 可在獨立的瀏覽器應用程式中提供自訂使用者代理程式字串。
  • 應盡可能在獨立瀏覽器應用程式 (無論是基於上游 WebKit 瀏覽器應用程式，還是第三方替代品) 中，實作對 HTML5 的支援。

不過，如果裝置實作項目不包含獨立的瀏覽器應用程式，則會發生以下情況：

3.5. API 行為相容性

裝置實作方式：

  • [C-0-9] 必須確保所有已安裝的應用程式都會套用 API 行為相容性，除非這些應用程式受到 第 3.5.1 節所述的限制。
  • [C-0-10] 請勿實作許可清單方法，因為這類方法只會確保裝置實作者選取的應用程式與 API 行為相容。

每種 API 類型 (受管理、軟體、原生和網頁) 的行為都必須與上游 Android 開放原始碼專案的偏好實作方式一致。以下是一些特定的相容性問題：

  • [C-0-1] 裝置不得變更標準意圖的行為或語意。
  • [C-0-2] 裝置不得變更特定類型的系統元件 (例如 Service、Activity、ContentProvider 等) 的生命週期或生命週期語意。
  • [C-0-3] 裝置不得變更標準權限的語意。
  • 裝置不得變更對背景應用程式強制執行的限制。具體來說，對於背景應用程式：
    • [C-0-4] 必須停止執行應用程式註冊的回呼，以便接收 GnssMeasurement 和 GnssNavigationMessage 的輸出內容。
    • [C-0-5] 透過 LocationManager API 類別或 WifiManager.startScan() 方法，他們必須限制應用程式收到更新的頻率。
    • [C-0-6] 如果應用程式指定 API 級別 25 以上版本，則不得允許註冊廣播接收器，以便在應用程式資訊清單中隱含廣播標準 Android 意圖，除非廣播意圖需要 "signature" 或 "signatureOrSystem" protectionLevel 權限，或是位於豁免清單中。
    • [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. 應用程式休眠

如果裝置實作項目包含 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] 只有在有證據顯示包裝盒在一段時間內未曾由任何使用者使用時，才應套用影響所有裝置使用者的限制。強烈建議您設定一個月或更長的時間。
  • [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] 不得位於由其他機構擁有或參照的命名空間。舉例來說，裝置實作人員不得將 API 新增至 com.google.* 或類似的命名空間，只有 Google 可以這麼做。同樣地，Google 不得將 API 新增至其他公司的命名空間。
  • [C-0-6] 必須封裝在 Android 共用程式庫中，這樣只有明確使用這些 API 的應用程式 (透過 <uses-library> 機制) 才會受到這些 API 記憶體用量增加的影響。

裝置實作者可以使用原生語言新增 NDK API 以外的自訂 API，但自訂 API 必須符合下列條件：

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

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

請注意，上述限制與 Java 程式設計語言中 API 命名的標準慣例相符。本節的目的只是要強化這些慣例，並透過納入此相容性定義來使其具有約束力。

3.7. 執行階段相容性

裝置實作方式：

  • [C-0-1] 必須支援完整的 Dalvik Executable (DEX) 格式和 Dalvik 位元碼規格和語義。

  • [C-0-2] 必須設定 Dalvik 執行階段，以便根據上游 Android 平台和下表所述，分配記憶體。(如要瞭解螢幕大小和螢幕密度的定義，請參閱 7.1.1 節)。

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

  • 應在各種執行模式和目標架構下執行模糊測試，以確保執行階段的穩定性。請參閱 Android 開放原始碼計畫網站中的 JFuzz 和 DexFuzz。

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

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

3.8. 使用者介面相容性

3.8.1. 啟動器 (主畫面)

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

如果裝置實作允許第三方應用程式取代裝置主畫面，則這些應用程式必須符合下列條件：

  • [C-1-1] 必須宣告平台功能 android.software.home_screen。
  • [C-1-2] 當第三方應用程式使用 <adaptive-icon> 標記提供圖示，並呼叫用於擷取圖示的 PackageManager 方法時，必須傳回 AdaptiveIconDrawable 物件。

如果裝置實作內容包含支援應用程式內捷徑固定功能的預設啟動器，則會符合下列條件：

相反地，如果裝置實作不支援應用程式內捷徑的固定功能，則會發生以下情況：

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

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

如果裝置實作內容包含顯示應用程式圖示徽章的預設啟動器應用程式，則這些應用程式會：

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

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

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

3.8.2. 小工具

Android 會定義元件類型和相應的 API 和生命週期，讓應用程式可向使用者公開 "AppWidget"，進而支援第三方應用程式小工具。

如果裝置實作支援第三方應用程式小工具，則必須符合下列條件：

  • [C-1-1] 必須宣告支援平台功能 android.software.app_widgets。
  • [C-1-2] 必須內建 AppWidget 支援功能，並提供使用者介面操作元素，以便新增、設定、查看及移除 AppWidget
  • [C-1-3] 必須能夠以標準格狀大小算繪 4 x 4 的小工具。詳情請參閱 Android SDK 說明文件中的「App Widget 設計指南」。
  • 可支援在螢幕鎖定畫面上顯示應用程式小工具。

如果裝置實作項目支援第三方應用程式小工具和應用程式內的固定捷徑，則必須符合下列條件：

3.8.3. 通知

Android 包含 Notification 和 NotificationManager API，可讓第三方應用程式開發人員使用裝置的硬體元件 (例如聲音、震動和燈光) 和軟體功能 (例如通知陰影、系統列)，通知使用者重要事件，並吸引使用者注意。

3.8.3.1. 通知呈現方式

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

  • [C-1-1] 必須支援使用硬體功能的通知，如 SDK 說明文件所述，並盡可能支援裝置實作硬體。舉例來說，如果裝置實作項目包含震動器，則必須正確實作震動 API。如果裝置實作項目缺少硬體，則必須將對應的 API 實作為無操作。請參閱第 7 節，進一步瞭解這項行為。
  • [C-1-2] 必須正確轉譯 API 或狀態/系統列圖示樣式指南中提供的所有資源 (圖示、動畫檔案等)，雖然這些資源可能會提供與參考 Android 開放原始碼實作不同的通知使用者體驗。
  • [C-1-3] 必須正確遵循並實作 API 的行為描述，以便更新、移除及分組通知。
  • [C-1-4] 必須提供 SDK 中記錄的 NotificationChannel API 的完整行為。
  • [C-1-5] 必須提供使用者操作元素，讓使用者可依據各管道和應用程式套件層級，封鎖及修改特定第三方應用程式的通知。
  • [C-1-6] 也必須提供使用者操作提示，以便顯示已刪除的通知管道。

  • [C-1-7] 必須透過 Notification.MessagingStyle 提供的所有資源 (圖片、貼圖、圖示等)，與通知文字一併正確顯示，且不需額外使用者互動。舉例來說，您必須在透過 setGroupConversation 設定的群組對話中，顯示透過 android.app.Person 提供的所有資源，包括圖示。

  • [C-SR-1] 強烈建議您提供使用者可用選項，讓他們控制向已授予通知事件監聽器權限的應用程式顯示的通知。精細度必須如此，才能讓使用者針對每個這類通知事件監聽器，控制哪些通知類型會連結至這個事件監聽器。類型必須包含「對話」、「警示」、「靜音」和「重要持續性」通知。

  • [C-SR-2] 強烈建議您提供使用者可用來指定要排除哪些應用程式，以免通知任何特定通知監聽器的操作元素。

  • [C-SR-3] 強烈建議您在使用者多次關閉某個第三方應用程式通知後，自動顯示使用者操作選項，以便針對每個管道和應用程式套件層級封鎖該通知。

  • 應支援複合式通知。

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

  • 應提供使用者延後通知的操作提示。

  • 僅管理第三方應用程式可通知使用者的重要事件的可見度和時間，以減輕駕駛人分心等安全問題。

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

裝置實作方式：

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

  • [C-SR-5] 強烈建議以對話框形式顯示此對話。AOSP 實作項目會使用預設的系統使用者介面、設定和啟動器，符合這些規定。

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

  • [C-2-1] 必須使用確切的資源，如透過 Notification.Style API 類別及其子類別提供的資源，用於呈現的資源元素。
  • 應顯示 Notification.Style API 類別及其子類別中定義的每個資源元素 (例如圖示、標題和摘要文字)。

抬頭通知是指在使用者所在介面無關的情況下，向使用者顯示的通知。如果裝置實作項目支援抬頭通知，則會：

  • [C-3-1] 在顯示抬頭通知時，必須使用 Notification.Builder API 類別中說明的抬頭通知檢視畫面和資源。
  • [C-3-2] 必須顯示透過 Notification.Builder.addAction() 提供的動作，並搭配通知內容，且無須額外使用者互動，如SDK 所述。
3.8.3.2. 通知接聽器服務

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

裝置實作方式：

  • [C-0-1] 必須正確且迅速地更新所有已安裝及使用者啟用的監聽器服務的通知，包括附加至 Notification 物件的所有中繼資料。
  • [C-0-2] 必須遵循 snoozeNotification() API 呼叫，並在 API 呼叫中設定的延遲時間過後，關閉通知並回呼。

如果裝置實作方式提供使用者延後通知的操作選項，則應符合下列條件：

  • [C-1-1] 必須透過 NotificationListenerService.getSnoozedNotifications() 等標準 API 正確反映已暫緩的通知狀態。
  • [C-1-2] 必須提供此使用者操作元素，讓使用者暫緩各個已安裝第三方應用程式的通知，除非這些通知來自持續性/前景服務。
3.8.3.3. DND (請勿打擾) / 優先順序模式

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

  • [C-1-1] 必須：如果裝置實作已提供一種方式，讓使用者授予或拒絕第三方應用程式存取 DND 政策設定，則應一併顯示應用程式建立的自動 DND 規則，以及使用者建立的預先定義規則。
  • [C-1-3] 必須遵循 NotificationManager.Policy 傳遞的 suppressedVisualEffects 值，如果應用程式已設定 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 標記，則應向使用者指出視覺效果已在 DND 設定選單中抑制。

Android 15 的新規定上路了

3.8.3.4. 敏感通知保護

機密通知資訊包括動態密碼、動態確認碼和類似的驗證或重設碼等內容，這些內容可能會顯示在使用者的通知中。

如果裝置實作允許第三方應用程式通知使用者重大事件，則該應用程式必須符合下列條件：

  • [C-1-1] 除非是下列的事件，否則不得將敏感的通知資訊傳送至通知監聽器：

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

NotificationAssistantServices 的 AOSP 實作方式就是這些規定的範例，也符合這些規定。如需範例，請參閱 android.ext.services.notification。

新規定結束

3.8.4. Assist API

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

如果裝置實作支援 Assist 動作，則會：

  • [C-2-1] 必須明確向使用者說明何時分享了背景資訊，方法如下：
    • 每當小幫手應用程式存取情境時，會在螢幕邊緣顯示白色燈光，且亮度和時間長度符合或超過 Android 開放原始碼計畫實作項目的標準。
    • 針對預先安裝的輔助應用程式，提供使用者操作提示，距離預設語音輸入和 Google 助理應用程式設定選單的步驟少於兩個，且只有在使用者透過熱字詞或輔助導覽鍵輸入時，明確叫用輔助應用程式時才分享內容。
  • [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] 必須遵循 Toast API 規定，並以某種高度可見的方式，將應用程式中的 Toast 顯示給使用者。

3.8.6。主題

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

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

如果裝置實作內容包含螢幕或影片輸出內容，則必須符合下列條件：

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

  • [C-1-3] 必須針對 Roboto 支援的語言，將「無襯線」字型系列設為 Roboto 2.x 版，或是提供使用者選項，以便針對 Roboto 支援的語言，將「無襯線」字型系列使用的字型變更為 Roboto 2.x 版。

  • [C-1-4] 必須根據 Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 的 AOSP 說明文件 (請參閱 android.theme.customization.system_palette 和 android.theme.customization.theme_style) 產生動態色調調色盤。

  • [C-1-5] 必須使用 Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 說明文件 (請參閱 android.theme.customization.theme_styles) 列舉的色彩主題樣式 (即 TONAL_SPOT、VIBRANT、EXPRESSIVE、SPRITZ、RAINBOW、FRUIT_SALAD 和 MONOCHROMATIC) 產生動態色彩色調調色盤。

    「來源顏色」：用於在使用 android.theme.customization.system_palette 傳送時產生動態色調調色盤 (如 Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 所述)。

  • [C-1-6] CAM16 色度值必須為 5 以上。

    • 應透過 com.android.systemui.monet.ColorScheme#getSeedColors 從桌布衍生，這可提供多個有效的來源顏色供您挑選。

    • 如果提供的顏色均不符合上述來源顏色規定，則應使用 0xFF1B6EF3 值。

Android 也包含「Device Default」主題系列，提供一組已定義的樣式，供應用程式開發人員使用，以便與裝置實作者定義的裝置主題外觀和感受相符。

Android 支援含有半透明系統列的變化主題，讓應用程式開發人員可在狀態列和導覽列後方填入應用程式內容。為了在這個設定中提供一致的開發人員體驗，請務必在不同裝置的實作中維持狀態列圖示樣式。

如果裝置實作項目包含系統狀態列，則必須符合下列條件：

  • [C-2-1] 系統狀態圖示 (例如訊號強度和電池電量) 和系統發出的通知，必須使用白色，除非圖示表示有問題的狀態，或是應用程式使用 WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS 標記要求淺色狀態列。
  • [C-2-2] 應用程式要求淺色狀態列時，Android 裝置實作項目必須將系統狀態圖示的顏色變更為黑色 (詳情請參閱 R.style)。

3.8.7. 動態桌布

Android 定義了元件類型和對應的 API 和生命週期，讓應用程式可向使用者提供一或多個「動態桌布」。動態桌布是動畫、圖案或類似圖片，具有有限的輸入功能，可顯示為桌布，並在其他應用程式後方運作。

如果硬體可以以合理的幀率執行所有動態桌布，且不會對其他應用程式造成不良影響，就會被視為可靠地執行動態桌布。如果硬體限制導致桌布和/或應用程式當機、發生故障、耗用過多 CPU 或電池電力，或以不合理的低畫面更新率執行，則系統會判定硬體無法執行動態桌布。舉例來說，某些動態桌布可能會使用 OpenGL 2.0 或 3.x 背景來轉譯內容。在未支援多個 OpenGL 情境的硬體上，即時桌布無法穩定執行，因為即時桌布使用 OpenGL 情境時，可能會與其他也使用 OpenGL 情境的應用程式發生衝突。

  • 裝置實作項目應實作動態桌布，以便可如上所述可靠地執行動態桌布。

如果裝置實作動態桌布，則會執行以下操作：

  • [C-1-1] 必須回報平台功能旗標 android.software.live_wallpaper。

3.8.8。活動切換

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

裝置實作 (包括 第 7.2.3 節所述的近期功能導覽鍵) 可能會變更介面。

如果裝置實作 (包括 第 7.2.3 節所述的近期功能導覽鍵) 變更介面，則必須符合下列條件：

  • [C-1-1] 必須支援至少 7 個顯示活動。
  • 一次至少顯示 4 項活動的標題。
  • 應在「最近使用」中顯示醒目顯示顏色、圖示和畫面標題。
  • 應顯示關閉操作元素 (「x」)，但可在使用者與畫面互動前延遲顯示。
  • 應實作捷徑，方便切換至先前的活動。
  • 在輕觸兩次「最近」功能鍵時，應會在兩個最近使用的應用程式之間觸發快速切換動作。
  • 長按「最近」功能鍵時，應觸發分割畫面多視窗模式 (如果支援的話)。
  • 可將相關聯的近期內容顯示為一組一起移動的內容。
  • [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，改用Media Notification Template，讓媒體應用程式可與螢幕鎖定畫面上顯示的播放控制項整合。

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 中覆寫表情符號)
  • 應支援萬國碼技術報告 #51 中指定的膚色和多元家庭表情符號。

如果裝置實作包含 IME，則會執行以下操作：

  • 應為使用者提供這些表情符號的輸入方式。

Android 支援轉譯緬甸字型的功能。緬甸有幾種不符合 Unicode 規範的字型，通常稱為「Zawgyi」，用於轉譯緬甸語。

如果裝置實作內容支援緬甸文，則必須符合下列條件：

  • [C-2-1] 必須以符合 Unicode 規範的字型，以預設方式顯示文字；除非使用者在語言挑選器中選擇非 Unicode 規範的字型，否則不得將其設為預設字型。
  • [C-2-2] 如果裝置支援非萬國碼相容字型，則必須支援萬國碼字型和非萬國碼相容字型。不符合 Unicode 規範的字型不得移除或覆寫 Unicode 字型。
  • [C-2-3] 只有在指定使用 script code Qaag 的語言代碼 (例如 my-Qaag) 時，才須使用非 Unicode 相容字型顯示文字。其他 ISO 語言或地區代碼 (無論是否已指派、未指派或保留) 皆無法用於參照不符合 Unicode 規範的緬甸字型。應用程式開發人員和網頁作者可以將 my-Qaag 指定為指定語言代碼，就像其他語言一樣。

3.8.14。多視窗模式

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

  • [C-1-1] 必須根據 Android SDK 多視窗模式支援說明文件中所述的應用程式行為和 API 實作這類多視窗模式，並符合下列規定：
  • [C-1-2] 必須遵循 這個 SDK 所述，在 AndroidManifest.xml 檔案中由應用程式設定的 android:resizeableActivity。
  • [C-1-3] 如果螢幕高度和寬度均小於 440 dp，則不得提供分割畫面或任意形式模式。
  • [C-1-4] 在多視窗模式中，活動不得調整為小於 220dp 的大小 (子母畫面模式除外)。
  • 螢幕尺寸為 xlarge 的裝置實作應支援自由格式模式。

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

  • [C-2-2] 如果啟動器應用程式是焦點視窗，則必須裁剪分割畫面多視窗的已固定活動，但應顯示部分內容。
  • [C-2-3] 必須遵循第三方啟動器應用程式宣告的 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值，並在顯示已固定活動的部分內容時，不覆寫這些值。

如果裝置實作支援多視窗模式和子母畫面多視窗模式，則會：

  • [C-3-1] 應用程式在以下情況下，必須以子母畫面多視窗模式啟動活動： * 指定 API 級別 26 以上版本，並宣告 android:supportsPictureInPicture * 指定 API 級別 25 以下版本，並宣告 android:resizeableActivity 和 android:supportsPictureInPicture。
  • [C-3-2] 必須透過 setActions() API，將目前 PIP 活動指定的動作公開至 SystemUI。
  • [C-3-3] 必須支援大於或等於 1:2.39 且小於或等於 2.39:1 的顯示比例，如透過 setAspectRatio() API 指定的 PIP 活動所述。
  • [C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如果未實作子母畫面模式，則前景活動必須可使用該鍵。
  • [C-3-5] 必須提供使用者提示，以便阻止應用程式以 PIP 模式顯示；AOSP 實作項目在通知陰影中提供控制項，符合這項規定。

  • [C-3-6] 當應用程式未為 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 宣告任何值時，必須為 PIP 視窗分配下列最小寬度和高度：

    • 如果裝置的 Configuration.uiMode 設為 UI_MODE_TYPE_TELEVISION 以外的值，則必須分配最小寬度和高度為 108 dp。
    • 如果裝置的 Configuration.uiMode 設為 UI_MODE_TYPE_TELEVISION，則必須分配最小寬度 240 dp 和最小高度 135 dp。

Android 15 的新規定上路了

如果裝置實作包含多個與 Android 相容的顯示區域，並將這些區域提供給應用程式，則會發生以下情況：

  • [C-4-1] 應用程式必須支援多視窗模式。

如果裝置實作支援多視窗模式，則會：

新規定結束

3.8.15。螢幕凹口

Android 支援 SDK 文件中所述的螢幕裁剪功能。DisplayCutout API 會定義螢幕邊緣的區域，該區域可能因螢幕缺口或邊緣的曲面螢幕而無法供應用程式使用。

如果裝置實作包含螢幕缺口，則必須符合下列條件：

  • [C-1-5] 如果裝置的顯示比例為 1.0 (1:1)，則不得有缺口。
  • [C-1-2] 每個邊緣不得有超過一個裁剪區。
  • [C-1-3] 必須遵循應用程式透過 WindowManager.LayoutParams API 設定的顯示區域切除標記，如 SDK 所述。
  • [C-1-4] 必須針對 DisplayCutout API 中定義的所有裁剪指標回報正確的值。

3.8.16. 裝置控制

Android 包含 ControlsProviderService 和 Control API，可讓第三方應用程式發布裝置控制項，為使用者提供快速狀態和操作。

如要瞭解裝置相關需求，請參閱第 2_2_3 節。

3.8.17。剪貼簿

裝置實作方式：

  • [C-0-1] 除非使用者明確採取動作 (例如按下疊加畫面上的按鈕) 或表示要傳送內容，否則不得將剪貼簿資料傳送至任何元件、活動、服務，或透過任何網路連線傳送，9.8.6 內容擷取和應用程式搜尋中提及的服務除外。

如果裝置實作項目在 ClipData.getDescription().getExtras() 包含 android.content.extra.IS_SENSITIVE 的情況下，將內容複製到剪貼簿的任何 ClipData 項目時，產生使用者可見的預覽畫面，則會執行以下操作：

  • [C-1-1] 必須遮蓋可向使用者顯示的預覽畫面

AOSP 參考實作項目符合這些剪貼簿規定。

3.9. 裝置管理

Android 15 的新規定上路了

Android 包含可允許安全性感知 啟用裝置政策控制器應用程式的功能，讓這些應用程式透過 Android 裝置管理 API 裝置政策管理器 API，在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端資料清除。

如果裝置實作導入 Android SDK 說明文件中定義的所有裝置管理政策，則會：

  • [C-1-1] 必須宣告 android.software.device_admin。
  • [C-1-2] 必須支援裝置擁有者佈建作業，如第 3.9.1 節和第 3.9.1.1 節所述。

新規定結束

3.9.1. 裝置佈建

3.9.1.1. 裝置擁有者佈建

如果裝置實作宣告 android.software.device_admin，則會執行以下操作：

  • [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為裝置擁有者應用程式，如下所述：
    • 如果裝置實作未設定使用者或使用者資料，則會發生以下情況：
      • [C-1-5] 如果裝置透過功能旗標 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 應用程式註冊為裝置擁有者應用程式。

Android 15 的新規定上路了

  • [C-1-2] 必須在應用程式設為裝置擁有者之前，顯示適當的揭露通知 (例如 AOSP 中所述)，並取得使用者的肯定同意聲明，除非裝置在使用者與畫面互動前，已透過程式碼設定為零售商店示範模式。如果裝置實作項目宣告 android.software.device_admin，但也包含專屬的裝置管理解決方案，並提供機制，將在解決方案中設定的應用程式設為「裝置擁有者等同物」，以便由標準 Android DevicePolicyManager API 辨識，則：

  • [C-2-1] 必須設有程序，以便驗證所宣傳的特定應用程式屬於合法的企業裝置管理解決方案，且已在專屬解決方案中進行設定，擁有與「裝置擁有者」同等的權限。

  • [C-2-2] 在將 DPC 應用程式註冊為「裝置擁有者」之前，必須顯示與 android.app.action.PROVISION_MANAGED_DEVICE 啟動的流程相同的 AOSP 裝置擁有者同意聲明。

  • [C-2-3] 請勿硬式編碼同意聲明，或禁止使用其他裝置擁有者應用程式。

新規定結束

3.9.1.2. 受管理設定檔佈建

如果裝置實作宣告 android.software.managed_users，則會執行以下操作：

Android 15 的新規定上路了

新規定結束

3.9.2. 受管理設定檔支援

如果裝置實作宣告 android.software.managed_users，則會執行以下操作：

  • [C-1-1] 必須透過 android.app.admin.DevicePolicyManager API 支援受管理的設定檔。
  • [C-1-2] 必須允許建立一個受管理的設定檔。
  • [C-1-3] 必須使用圖示徽章 (類似 AOSP 上游工作徽章) 代表受管理的應用程式和小工具，以及其他徽章 UI 元素，例如「最近」和「通知」。
  • [C-1-4] 必須顯示通知圖示 (類似 AOSP 上游工作徽章)，指出使用者目前處於受管理設定檔應用程式中。
  • [C-1-5] 如果裝置喚醒 (ACTION_USER_PRESENT) 且前景應用程式位於受管理的設定檔中，則必須顯示浮動視窗，指出使用者處於受管理的設定檔。
  • [C-1-6] 如果有受管理的設定檔，則必須在 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] 必須支援指定符合下列規定的獨立螢幕鎖定畫面，以便只授予在受管理設定檔中執行的應用程式存取權。
  • 當預先安裝的通話記錄、通話中的使用者介面、進行中的通話和未接來電通知、聯絡人和訊息應用程式中顯示來自受管理設定檔的聯絡人時，應使用與用於表示受管理設定檔應用程式的徽章相同的徽章。

3.9.3. 受管理使用者支援

如果裝置實作宣告 android.software.managed_users，則會執行以下操作：

  • [C-1-1] 必須提供使用者操作提示，以便在 isLogoutEnabled 傳回 true 時，從目前使用者登出，並在多使用者工作階段中切換回主要使用者。使用者必需在鎖定畫面上看到使用者操作提示，且不必解鎖裝置。

如果裝置實作項目宣告 android.software.device_admin，並提供裝置端使用者可用性，以便新增其他次要使用者，則：

  • [C-SR-1] 強烈建議在允許在新的次要使用者帳戶中新增帳戶之前，顯示在 android.app.action.PROVISION_MANAGED_DEVICE 啟動的流程中顯示的相同 AOSP 裝置擁有者同意聲明揭露事項，讓使用者瞭解裝置受到管理。

3.9.4. 裝置政策管理角色需求

如果裝置實作回報 android.software.device_admin 或 android.software.managed_users，則會：

  • [C-1-1] 必須支援 第 9.1 節所定義的裝置政策管理角色。您可以將 config_devicePolicyManagement 設為套件名稱，藉此定義擁有裝置政策管理角色的應用程式。除非應用程式為預先載入，否則套件名稱後面必須接著 : 和簽署憑證。

如果未為 config_devicePolicyManagement 定義套件名稱，則會發生下列情況：

  • [C-2-1] 裝置實作必須支援在沒有裝置政策管理角色持有人應用程式的情況下進行佈建 (AOSP 提供參考實作項目)。

如果已為 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 或 android.software.managed_users，則表示：

3.10. 無障礙設定

Android 提供無障礙層，可協助身心障礙使用者更輕鬆地操作裝置。此外，Android 提供平台 API，可讓無障礙服務實作項目接收使用者和系統事件的回呼，並產生其他回饋機制，例如文字轉語音、觸覺回饋和軌跡球/方向鍵導覽。

如果裝置實作支援第三方無障礙服務，則必須符合下列條件：

  • [C-1-1] 必須提供 Android 無障礙功能架構的實作項目，如 無障礙功能 API SDK 說明文件所述。
  • [C-1-2] 必須產生無障礙事件，並將適當的 AccessibilityEvent 傳送至所有已註冊的 AccessibilityService 實作，如 SDK 中的文件所述。
  • [C-1-4] 您必須提供使用者操作宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 的無障礙服務的操作元素。請注意，對於具有系統導覽列的裝置實作，應允許使用者在系統導覽列中選擇按鈕來控制這些服務。

如果裝置實作內容包含預先安裝的無障礙服務，則必須符合下列條件：

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

3.11. 文字轉語音

Android 包含 API，可讓應用程式使用文字轉語音 (TTS) 服務，並讓服務供應商提供 TTS 服務的實作項目。

如果裝置實作項目回報 android.hardware.audio.output 功能，則：

如果裝置實作支援安裝第三方 TTS 引擎，則必須符合下列條件：

  • [C-2-1] 必須提供使用者操作提示，讓使用者選取要用於系統層級的 TTS 引擎。

Android 15 新規定生效

3.12. 電視輸入框架

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

如果裝置實作支援 TIF，則會：

  • [C-1-1] 必須宣告平台功能 android.software.live_tv。
  • [C-1-2] 必須支援所有 TIF API，以便使用這些 API 和第三方 TIF 輸入服務的應用程式可在裝置上安裝及使用。

新規定結束

3.13. 快速設定

Android 提供快速設定 UI 元件，可快速存取常用或急需的動作。

如果裝置實作內容包含「快速設定」UI 元件，且支援第三方「快速設定」，則會符合以下條件：

  • [C-1-1] 必須允許使用者透過第三方應用程式的 quicksettings API 新增或移除資訊方塊。
  • [C-1-2] 不得自動將第三方應用程式的資訊方塊直接新增至快速設定。
  • [C-1-3] 必須顯示所有使用者新增的第三方應用程式方塊，以及系統提供的快速設定方塊。

3.14. 媒體 UI

如果裝置實作包含透過 MediaBrowser 或 MediaSession 與第三方應用程式互動的非語音啟動應用程式 (以下稱為「應用程式」)，則應用程式必須符合下列規定：

  • [C-1-2] 必須清楚顯示透過 getIconBitmap() 或 getIconUri() 取得的圖示，以及透過 getTitle() 取得的標題，如 MediaDescription 所述。為了遵守安全法規 (例如駕駛人分心)，可以縮短標題。

  • [C-1-3] 凡是顯示第三方應用程式提供的內容，都必須顯示第三方應用程式圖示。

  • [C-1-4] 必須允許使用者與整個 MediaBrowser 階層互動。可限制部分階層的存取權，以符合安全規定 (例如駕駛人分心)，但不得基於內容或內容供應者給予優待。

  • [C-1-5] 必須將 KEYCODE_HEADSETHOOK 或 KEYCODE_MEDIA_PLAY_PAUSE 的雙擊動作視為 MediaSession.Callback#onMediaButtonEvent 的 KEYCODE_MEDIA_NEXT。

3.15. 免安裝應用程式

如果裝置實作支援即時應用程式，則必須符合下列規定：

  • [C-1-1] 即時應用程式必須只授予 android:protectionLevel 設為 "instant" 的權限。
  • [C-1-2] 除非符合下列任一條件，否則免安裝應用程式不得透過隱含意圖與已安裝的應用程式互動：
    • 元件公開的意圖模式篩選器具有 CATEGORY_BROWSABLE
    • 動作為 ACTION_SEND、ACTION_SENDTO 或 ACTION_SEND_MULTIPLE
    • 使用 android:visibleToInstantApps 明確公開目標
  • [C-1-3] 除非元件是透過 android:visibleToInstantApps 公開，否則免安裝應用程式不得明確與已安裝的應用程式互動。
  • [C-1-4] 除非免安裝應用程式明確連結至已安裝的應用程式，否則已安裝的應用程式不得查看裝置上的免安裝應用程式詳細資料。

  • 裝置實作方式必須提供以下使用者操作選項，以便與免安裝應用程式互動。AOSP 搭配預設的系統使用者介面、設定和啟動器，可符合相關規定。裝置實作方式：

    • [C-1-5] 您必須提供使用者操作提示，讓他們查看及刪除各個應用程式套件在本機快取的即時應用程式。
    • [C-1-6] 您必須提供常駐使用者通知，在免安裝應用程式於前景執行時，使用者可以將通知收合。這則使用者通知必須說明免安裝應用程式不需要安裝，並提供使用者提示，引導使用者前往「設定」中的應用程式資訊畫面。針對透過網頁意圖啟動的即時應用程式 (使用意圖，並將動作設為 Intent.ACTION_VIEW，且採用「http」或「https」的配置)，如果裝置上有可用的瀏覽器，則應提供額外的使用者操作選項，讓使用者不必啟動即時應用程式，而是透過已設定的網路瀏覽器啟動相關連結。
    • [C-1-7] 如果裝置支援「最近」功能，則必須允許使用者透過「最近」功能存取執行中的即時應用程式。

  • [C-1-8] 必須為 SDK 中列出的意圖使用意圖處理常式，為一或多個應用程式或服務元件預先載入，並讓意圖對即時應用程式可見。請參閱此處。

3.16. 配對裝置配對

Android 支援配件裝置配對功能，可更有效地管理與配件裝置的關聯，並提供 CompanionDeviceManager API，讓應用程式存取這項功能。

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

Android 15 的新規定上路了

  • [C-1-3] 必須提供使用者操作元素，讓使用者選取/確認配搭裝置是否存在且可運作，且必須使用與 AOSP 中實作相同的訊息，不得新增或修改。

新規定結束

3.17. 重量級應用程式

如果裝置實作宣告 FEATURE_CANT_SAVE_STATE 功能，則會：

  • [C-1-1] 一次只能有一個安裝應用程式指定 cantSaveState 在系統中執行。如果使用者離開這類應用程式時並未明確退出 (例如在系統中離開有效活動時按下主畫面，而不是在系統中沒有有效活動時按下返回鍵)，則裝置實作必須在 RAM 中將該應用程式視為優先，就像其他預期會持續執行的項目 (例如前景服務) 一樣。當這類應用程式處於背景執行時，系統仍可為其套用電源管理功能，例如限制 CPU 和網路存取。
  • [C-1-2] 使用者啟動以 cantSaveState 屬性宣告的第二個應用程式後，必須提供 UI 操作元素，以便選擇不會參與一般狀態儲存/還原機制的應用程式。
  • [C-1-3] 請勿將其他政策變更套用至指定 cantSaveState 的應用程式，例如變更 CPU 效能或變更排程優先順序。

如果裝置實作未宣告 FEATURE_CANT_SAVE_STATE 功能，則會發生以下情況：

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

3.18. 聯絡人

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

當ACCOUNT_NAME 和 ACCOUNT_TYPE 資料欄與帳戶的 Account.name 和 Account.type 欄位相符時，RawContacts 會「與」或「儲存在」帳戶中。

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

自訂本機帳戶：這是用於原始聯絡人的帳戶，只會儲存在裝置上，且不會與 AccountManager 中的帳戶相關聯。這些帳戶是使用 ACCOUNT_NAME 和 ACCOUNT_TYPE 資料欄的至少一個非空值建立。

裝置實作方式：

  • [C-SR-1] 強烈建議您不要建立自訂本機帳戶。

如果裝置實作使用自訂本機帳戶：

  • [C-1-1] 自訂本機帳戶的 ACCOUNT_NAME 必須由 ContactsContract.RawContacts.getLocalAccountName 傳回
  • [C-1-2] 自訂本機帳戶的 ACCOUNT_TYPE 必須由 ContactsContract.RawContacts.getLocalAccountType 傳回
  • [C-1-3] 第三方應用程式使用預設的本機帳戶插入的原始聯絡人 (也就是設定 ACCOUNT_NAME 和 ACCOUNT_TYPE 的空值)，必須插入自訂的本機帳戶。
  • [C-1-4] 新增或移除帳戶時，不得移除插入自訂本機帳戶的原始聯絡人。
  • [C-1-5] 針對自訂本機帳戶執行的刪除作業必須立即清除原始聯絡人 (就像將 CALLER_IS_SYNCADAPTER 參數設為 true 一樣)，即使 CALLER\_IS\_SYNCADAPTER 參數設為 false 或未指定也一樣。

Android 15 的新規定上路了

3.19. 語言設定

裝置實作方式：

  • [C-0-1] 對於不支援性別特定翻譯的語言，請勿提供任何使用者操作元素，讓使用者選取性別特定的語言處理方式。詳情請參閱文法資源。

新規定結束

4. 應用程式封裝相容性

裝置實作方式：

  • [C-0-1] 必須能夠安裝及執行由 官方 Android SDK 中「aapt」工具產生的 Android「.apk」檔案。

    • 由於上述要求可能難以實現，因此建議裝置實作項目使用 AOSP 參考實作項目的套件管理系統。

  • [C-0-2] 必須支援使用 APK Signature Scheme v3.1、APK Signature Scheme v3、APK Signature Scheme v2 和 JAR 簽署驗證「.apk」檔案。

  • [C-0-3] 請勿擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式，以免這些檔案無法在其他相容裝置上正確安裝及執行。

  • [C-0-4] 除了套件的現有「記錄安裝程式」外，其他應用程式不得在未經使用者確認的情況下，悄悄解除安裝應用程式，如 DELETE_PACKAGE 權限的 SDK 所述。唯一的例外狀況是系統套件驗證器應用程式處理 PACKAGE_NEEDS_VERIFICATION 意圖，以及儲存空間管理器應用程式處理 ACTION_MANAGE_STORAGE 意圖。

  • [C-0-5] 活動必須處理 android.settings.MANAGE_UNKNOWN_APP_SOURCES 意圖。

  • [C-0-6] 請勿從不明來源安裝應用程式套件，除非要求安裝的應用程式符合下列所有規定：

    • 必須宣告 REQUEST_INSTALL_PACKAGES 權限，或是將 android:targetSdkVersion 設為 24 以下。
    • 使用者必須授予權限，才能從不明來源安裝應用程式。

  • 應為使用者提供使用者操作元素，以便授予/撤銷從不明來源安裝應用程式的權限 (針對每個應用程式)，但如果裝置實作不想讓使用者有此選擇，則可選擇將此做為無操作，並針對 startActivityForResult() 傳回 RESULT_CANCELED。不過，即使在這種情況下，應用程式也應向使用者說明為何沒有顯示這類選項。

  • [C-0-7] 在應用程式中啟動活動之前，必須顯示警告對話方塊，並透過系統 API PackageManager.setHarmfulAppWarning 向使用者提供警告字串，且該活動已由相同的系統 API PackageManager.setHarmfulAppWarning 標示為可能有害。

  • 應在警告對話方塊中提供使用者操作提示，讓使用者選擇解除安裝或啟動應用程式。

  • [C-0-8] 必須實作對增量檔案系統的支援，如此處所述。

  • [C-0-9] 必須支援使用 APK 簽署配置 v4 和 APK 簽署配置 v4.1 驗證 .apk 檔案。

5. 多媒體相容性

裝置實作方式：

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

裝置實作方式：

  • 應盡量縮短編碼器延遲時間，也就是
    • 不應使用及儲存輸入緩衝區，且只在處理後傳回輸入緩衝區。
    • 不應將解碼緩衝區保留超過標準 (例如 SPS) 指定的時間。
    • 不應將編碼緩衝區保留超過 GOP 結構所需的時間。

下文所列的所有編碼器皆為 Android 開放原始碼計畫中偏好的 Android 實作項目提供的軟體實作項目。

請注意，Google 和開放手持裝置聯盟均未聲明這些編解碼不受第三方專利約束。如要在硬體或軟體產品中使用這個原始碼，請注意，實作這段程式碼 (包括在開放原始碼軟體或共享軟體中) 可能需要取得相關專利持有人的專利授權。

5.1. 媒體轉碼器

5.1.1. 音訊編碼

詳情請參閱 5.1.3 「音訊轉碼器詳細資料」。

如果裝置實作項目宣告 android.hardware.microphone，則必須支援編碼下列音訊格式，並將這些格式提供給第三方應用程式：

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

所有音訊編碼器都必須支援以下項目：

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 Profile (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 設定檔 (增強型 AAC+)
  • [C-1-4] AAC ELD (增強型低延遲 AAC)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile，包括 USAC Baseline Profile，以及 ISO/IEC 23003-4 Dynamic Range Control Profile)
  • [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

如果裝置實作內容支援透過 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 中的「動態範圍控制 (DRC)」和 android.media.MediaFormat DRC 鍵所定義的內容，以便設定音訊解碼器的動態範圍相關行為。AAC DRC 鍵是在 API 21 中推出，分別為 KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_ENCODED_TARGET_LEVEL。
  • [C-SR-1] 強烈建議所有 AAC 音訊解碼器都符合上述 C-2-1 和 C-2-2 規定。

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

  • [C-3-1] 音量和 DRC 中繼資料必須根據 MPEG-D DRC 動態範圍控制設定檔第 1 級進行解讀及套用。
  • [C-3-2] 解碼器必須根據以下 android.media.MediaFormat 鍵的設定運作：KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_DRC_EFFECT_TYPE。

MPEG-4 AAC、HE AAC 和 HE AACv2 設定檔解碼器：

  • 可使用 ISO/IEC 23003-4 動態範圍控制設定檔支援音量和動態範圍控制。

如果支援 ISO/IEC 23003-4，且解碼位元串流中同時存在 ISO/IEC 23003-4 和 ISO/IEC 14496-3 中繼資料，則：

  • 應優先採用 ISO/IEC 23003-4 中繼資料。

所有音訊解碼器都必須支援輸出：

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

  • [C-7-1] 應用程式必須能夠使用解碼功能，搭配 KEY_MAX_OUTPUT_CHANNEL_COUNT 鍵進行設定，以控制內容是否要下混成立體聲 (使用值為 2 時)，或是使用原生通道數輸出 (使用值等於或大於該數字時)。舉例來說，如果值為 6 或更高，則會將解碼器設為在輸入 5.1 內容時輸出 6 個頻道。
  • [C-7-2] 解碼時，解碼器必須使用 android.media.AudioFormat 常數 (例如 CHANNEL_OUT_5POINT1)，透過 KEY_CHANNEL_MASK 鍵宣告輸出格式所使用的通道遮罩。

如果裝置實作支援音訊解碼器 (除了預設 AAC 音訊解碼器)，且在輸入壓縮的多聲道內容時，能夠輸出多聲道音訊 (即超過 2 個聲道)，則：

  • [C-SR-2] 強烈建議應用程式使用 KEY_MAX_OUTPUT_CHANNEL_COUNT 鍵進行解碼，以便控制內容是否要下混成立體聲 (使用值為 2)，或是使用原生通道數輸出 (使用值等於或大於該數字)。舉例來說，如果值為 6 或更高，則會將解碼器設為在輸入 5.1 內容時輸出 6 個頻道。
  • [C-SR-3] 在解碼時，強烈建議解碼器使用 android.media.AudioFormat 常數 (例如 CHANNEL_OUT_5POINT1)，透過 KEY_CHANNEL_MASK 鍵宣告輸出格式所使用的頻道遮罩。

5.1.3. 音訊轉碼器詳細資料

格式/編解碼 詳細說明 支援的檔案類型/容器格式
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
Profile (增強型 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 支援單聲道/立體聲內容，取樣率為 7.35 到 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 位元的解析度。浮點音訊設定必須支援 FLAC 24 位元音訊資料處理。
  • FLAC (.flac)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅解碼)
MP3 單聲道/立體聲 8-320 Kbps 固定位元率 (CBR) 或可變位元率 (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅解碼)
MIDI MIDI 類型 0 和 1。DLS 1 和 2 版。XMF 和 Mobile XMF。支援的鈴聲格式：RTTTL/RTX、OTA 和 iMelody
  • 類型 0 和 1 (.mid、.xmf、.mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • iMelody (.imy)
Vorbis 解碼：支援單聲道、立體聲、5.0 和 5.1 內容，取樣率為 8000、12000、16000、24000 和 48000 Hz。
編碼：支援單聲道和立體聲內容，取樣率為 8000、12000、16000、24000 和 48000 Hz。
  • Ogg (.ogg)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv)
  • Webm (.webm)
PCM/WAVE PCM 編解碼器必須支援 16 位元線性 PCM 和 16 位元浮點。WAVE Extractor 必須支援 16 位元、24 位元、32 位元線性 PCM 和 32 位元浮點 (速率上限為硬體限制)。系統必須支援 8 kHz 到 192 kHz 的取樣率。 WAVE (.wav)
Opus 解碼：支援單聲道、立體聲、5.0 和 5.1 內容，取樣率為 8000、12000、16000、24000 和 48000 Hz。
編碼：支援單聲道和立體聲內容，取樣率為 8000、12000、16000、24000 和 48000 Hz。
  • Ogg (.ogg)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv)
  • Webm (.webm)

5.1.4. 圖片編碼

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

裝置實作項目必須支援下列圖片編碼：

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP
  • [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] 原始
  • [C-0-7] AVIF (基準設定檔)

如果裝置實作支援 HEVC 視訊解碼功能，則會：

  • [C-1-1] 必須支援 HEIF (HEIC) 圖片解碼。

支援高位元深度格式 (每個管道 9 位元以上) 的圖片解碼器：

  • [C-2-1] 應用程式要求時，必須支援輸出 8 位元等效格式，例如透過 android.graphics.Bitmap 的 ARGB_8888 設定。

5.1.6. 圖片編碼器詳細資料

格式/編解碼 詳細說明 支援的檔案類型/容器格式
JPEG 基本 + 漸進式 JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
原始 ARW (.arw)、CR2 (.cr2)、DNG (.dng)、NEF (.nef)、NRW (.nrw)、ORF (.orf)、PEF (.pef)、RAF (.raf)、RW2 (.rw2)、SRW (.srw)
HEIF 圖片、圖片集合、圖片序列 HEIF (.heif)、HEIC (.heic)
AVIF (基準設定檔) 圖片、圖片集合、圖片序列基準設定檔 HEIF 容器 (.avif)

透過 MediaCodec API 公開的圖片編碼器和解碼器

  • [C-1-1] 必須透過 CodecCapabilities 支援 YUV420 8:8:8 彈性色彩格式 (COLOR_FormatYUV420Flexible)。

  • [C-SR-1] 強烈建議您為輸入 Surface 模式支援 RGB888 顏色格式。

  • [C-1-3] 必須支援至少一種平面或半平面 YUV420 8:8:8 色彩格式：COLOR_FormatYUV420PackedPlanar (等同於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (等同於 COLOR_FormatYUV420SemiPlanar)。強烈建議同時支援這兩種格式。

5.1.7. 視訊轉碼器

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

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

  • [C-1-1] 視訊編碼器必須支援輸出和輸入位元組緩衝區大小，以便根據標準和設定容納可行的最大壓縮和未壓縮影格，但也不能超出分配範圍。

  • [C-1-2] 影片編碼器和解碼器必須透過 CodecCapabilities 支援 YUV420 8:8:8 彈性色彩格式 (COLOR_FormatYUV420Flexible)。

  • [C-1-3] 影片編碼器和解碼器必須支援至少一種平面或半平面 YUV420 8:8:8 色彩格式：COLOR_FormatYUV420PackedPlanar (等同於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (等同於 COLOR_FormatYUV420SemiPlanar)。強烈建議同時支援這兩種格式。

  • [C-SR-1] 強烈建議影片編碼器和解碼器支援至少一種硬體最佳化平面或半平面 YUV420 8:8:8 色彩格式 (YV12、NV12、NV21 或相等的供應商最佳化格式)。

  • [C-1-5] 支援高位元深度格式 (每個頻道 9 位元以上) 的影片解碼器，必須支援輸出應用程式要求的 8 位元等效格式。您必須透過 android.media.MediaCodecInfo 支援 YUV420 8:8:8 色彩格式，才能反映這項資訊。

如果裝置實作透過 Display.HdrCapabilities 宣傳 HDR 設定檔支援功能，則會：

  • [C-2-1] 必須支援 HDR 靜態中繼資料的剖析和處理。

如果裝置實作項目透過 MediaCodecInfo.CodecCapabilities 類別中的 FEATURE_IntraRefresh 宣傳內部重新整理支援功能，則會：

  • [C-3-1] 必須支援 10 到 60 影格範圍的更新週期，並在設定的更新週期 20% 內準確運作。

除非應用程式使用 KEY_COLOR_FORMAT 格式鍵指定其他格式，否則影片解碼器實作方式如下：

  • [C-4-1] 如果使用 Surface 輸出設定，則必須預設為針對硬體顯示器最佳化的色彩格式。
  • [C-4-2] 如果已設定為不使用 Surface 輸出，則必須預設為 YUV420 8:8:8 顏色格式，以便最佳化 CPU 讀取。

5.1.8. 視訊轉碼器清單

格式/編解碼 詳細說明 支援的檔案類型/容器格式
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 視訊編碼器，並將其提供給第三方應用程式，則：

  • 應支援支援的編碼器的動態可設定位元率。

如果裝置實作項目提供硬體加速影片或圖片編碼器，且支援透過 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] 必須支援基準設定檔第 3 級。不過，您可以選擇是否支援 ASO (任意切片排序)、FMO (彈性區塊排序) 和 RS (重複切片)。此外，為維持與其他 Android 裝置的相容性，建議編碼器不要使用 ASO、FMO 和 RS 做為基準設定檔。
  • [C-1-2] 必須支援下表中的 SD (標準畫質) 影片編碼設定檔。
  • 應支援 Main Profile Level 4。
  • 應支援下表所示的 HD (高畫質) 影片編碼設定檔。

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

  • [C-2-1] 必須支援下表中的編碼設定檔。
SD (低畫質) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p
影片解析度 320 x 240 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素
影片影格速率 20 fps 30 fps 30 fps 30 fps
視訊位元率 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

如果裝置實作支援 VP8 編解碼器，則會：

  • [C-1-1] 必須支援 SD 影片編碼設定檔。
  • 應支援下列 HD (高畫質) 影片編碼設定檔。
  • [C-1-2] 必須支援寫入 Matroska WebM 檔案。
  • 應提供符合 WebM 專案 RTC 硬體編碼需求的硬體 VP8 編解碼器，確保網路影片串流和視訊會議服務的品質符合要求。

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

  • [C-2-1] 必須支援下表中的編碼設定檔。
SD (低畫質) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
影片影格速率 30 fps 30 fps 30 fps 30 fps
視訊位元率 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

如果裝置實作支援 VP9 編解碼，則會：

  • [C-1-2] 必須支援 Profile 0 Level 3。
  • [C-1-1] 必須支援寫入 Matroska WebM 檔案。
  • [C-1-3] 必須產生 CodecPrivate 資料。
  • 應支援下表所示的 HD 解碼設定檔。
  • 如果有硬體編碼器，強烈建議 [C-SR-1] 支援 HD 解碼設定檔，如下表所示。
SD 標準畫質 HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片影格速率 30 fps 30 fps 30 fps 30 fps
視訊位元率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置實作聲稱透過 Media API 支援 Profile 2 或 Profile 3：

  • 支援 12 位元格式為選用功能。

5.2.5. H.265

如果裝置實作支援 H.265 編解碼器，則會符合以下條件：

  • [C-1-1] 必須支援主 Profile Level 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] 必須支援主設定檔，包括 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. 影片解碼

如果裝置實作支援 VP8、VP9、H.264 或 H.265 轉碼器，則會：

  • [C-1-1] 必須支援動態影片解析度和影格速率切換，透過相同串流中的標準 Android API 即時切換所有 VP8、VP9、H.264 和 H.265 轉碼器，並支援裝置上每個轉碼器支援的最高解析度。

5.3.1. MPEG-2

如果裝置實作支援 MPEG-2 解碼器，則必須符合下列條件：

  • [C-1-1] 必須支援主設定檔高層級別。

5.3.2. H.263

如果裝置實作支援 H.263 解碼器，則會：

  • [C-1-1] 必須支援基準設定檔等級 30 (CIF、QCIF 和 SQCIF 解析度 @ 30fps 384kbps) 和等級 45 (QCIF 和 SQCIF 解析度 @ 30fps 128kbps)。

5.3.3. MPEG-4

如果裝置實作 MPEG-4 解碼器，則必須符合下列條件：

  • [C-1-1] 必須支援簡易設定檔第 3 級。

5.3.4. H.264

如果裝置實作支援 H.264 解碼器，則會：

  • [C-1-1] 必須支援主設定檔等級 3.1 和基準設定檔。支援 ASO (任意切片排序)、FMO (彈性區塊排序) 和 RS (重複切片) 為選用功能。
  • [C-1-2] 必須能夠解碼下表所列的 SD (標準解析度) 設定檔，並以基準設定檔和主設定檔 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 Profile 級別 3 的主層級別，以及下表所示的 SD 影片解碼設定檔。
  • 應支援下表所示的 HD 解碼設定檔。
  • [C-1-2] 如果有硬體解碼器，則必須支援下表所列的 HD 解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則：

  • [C-2-1] 裝置實作方式必須支援至少一種 H.265 或 VP9 解碼功能，以便解碼 720、1080 和 UHD 設定檔。
SD (低畫質) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 352 x 288 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片影格速率 30 fps 30 fps 30 fps 30/60 fps (60 fps 適用於支援 H.265 硬體解碼的電視) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置實作聲稱透過 Media API 支援 HDR 設定檔：

  • [C-3-1] 裝置實作必須接受應用程式提供的必要 HDR 中繼資料，並支援從位元串流和/或容器中擷取及輸出必要的 HDR 中繼資料。
  • [C-3-2] 裝置實作方式必須在裝置螢幕或標準影片輸出埠 (例如 HDMI)。

5.3.6. VP8

如果裝置實作支援 VP8 編解碼器，則會：

  • [C-1-1] 必須支援下表中的 SD 解碼設定檔。
  • 應使用符合規定的硬體 VP8 編解碼器。
  • 應支援下表中的 HD 解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則：

  • [C-2-1] 裝置實作項目必須支援下表中的 720p 設定檔。
  • [C-2-2] 裝置實作項目必須支援下表中的 1080p 設定檔。
SD (低畫質) SD (高畫質) HD 高畫質 720p HD 高畫質 1080p
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
影片影格速率 30 fps 30 fps 30 fps (60 fps電視) 30 (60 fps，電視)
視訊位元率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

如果裝置實作支援 VP9 編解碼，則會：

  • [C-1-1] 必須支援下表所示的 SD 影片解碼設定檔。
  • 應支援下表所示的 HD 解碼設定檔。

如果裝置實作支援 VP9 編解碼器和硬體解碼器：

  • [C-2-1] 必須支援下表所示的 HD 解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則：

  • [C-3-1] 裝置實作方式必須支援至少一種 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 (60 fps，搭載 VP9 硬體解碼功能的電視) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置實作聲稱透過 'CodecProfileLevel' 媒體 API 支援 VP9Profile2 或 VP9Profile3：

  • 支援 12 位元格式為選用功能。

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

  • [C-4-1] 裝置實作必須接受應用程式提供的必要 HDR 中繼資料 (KEY_HDR_STATIC_INFO 適用於所有 HDR 設定檔，以及 HDR10Plus 設定檔的 'KEY_HDR10_PLUS_INFO')。也必須支援從位元串流和/或容器中擷取及輸出必要的 HDR 中繼資料。
  • [C-4-2] 裝置實作方式必須在裝置螢幕或標準影片輸出埠 (例如 HDMI)。

5.3.8. Dolby Vision

如果裝置實作項目透過 HDR_TYPE_DOLBY_VISION 宣告支援 Dolby Vision 解碼器，則會：

  • [C-1-1] 必須提供支援 Dolby Vision 的擷取器。

Android 15 的新規定上路了

  • [C-1-2] 必須在裝置螢幕上或透過標準視訊輸出埠連接的外接螢幕上，正確顯示 Dolby Vision 內容。HDMI)。

新規定結束

  • [C-1-3] 必須將向後相容的基礎層 (如有) 的軌跡 ID 設為與合併 Dolby Vision 層的軌跡 ID 相同。

5.3.9. AV1

如果裝置實作項目支援 AV1 編解碼器，並將其提供給第三方應用程式，則這些應用程式會：

  • [C-1-1] 必須支援主設定檔，包括 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] 必須支援從位元串流和/或容器中擷取及輸出 HDR 中繼資料。
  • [C-3-2] 必須在裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上正確顯示 HDR 內容。

5.4. 音訊錄製

雖然本節列出的部分規定自 Android 4.3 起列為「應」規定，但日後版本的相容性定義預計會將這些規定改為「必」規定。現有和新款 Android 裝置強烈建議符合這些「應」列出的規定，否則升級至未來版本時將無法達到 Android 相容性。

5.4.1. 原始音訊擷取和麥克風資訊

如果裝置實作宣告 android.hardware.microphone，則會執行以下操作：

  • [C-1-1] 必須允許擷取任何成功開啟的 AudioRecord 或 AAudio INPUT 串流的原始音訊內容。以下特性必須支援：

  • 應允許擷取具有下列特徵的原始音訊內容：

    • 格式：線性 PCM、16 位元和 24 位元
    • 取樣率：8000、11025、16000、22050、24000、32000、44100、48000 Hz
    • 頻道：與裝置上的麥克風數量相同

  • [C-1-2] 必須以上述取樣率進行擷取，且不得向上取樣。

  • [C-1-3] 使用上述取樣率進行降採樣時，必須加入適當的反鋸齒濾鏡。

  • 應允許 AM 廣播和 DVD 品質擷取原始音訊內容，也就是下列特性：

    • 格式：線性 PCM，16 位元
    • 取樣率：22050、48000 Hz
    • 聲道：立體聲

  • [C-1-4] 必須遵循 MicrophoneInfo API 的規定，並針對使用 MediaRecorder.AudioSources DEFAULT、MIC、CAMCORDER、VOICE_RECOGNITION、VOICE_COMMUNICATION、UNPROCESSED 或 VOICE_PERFORMANCE 的 AudioRecord 功能，為裝置上可供第三方應用程式存取的可用麥克風填入正確資訊。AudioManager.getMicrophones()如果裝置實作可讓 AM 收音機和 DVD 擷取原始音訊內容，則必須符合下列條件：

  • [C-2-1] 必須在無需向上取樣的情況下，以高於 16000:22050 或 44100:4800 的比例進行擷取。

  • [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，與用於錄製語音辨識音訊來源的每個麥克風的中頻範圍相比。

  • 應設定音訊輸入靈敏度，以便在 16 位元取樣範圍內，以 90 dB 的聲壓級別 (SPL) 播放 1000 Hz 正弦音源 (測量時位於麥克風旁)，為用於錄製語音辨識音訊來源的每個麥克風，提供 1770 到 3530 的 RMS 2500 理想回應 (或浮點/雙精度取樣為 -22.35 db ±3dB 全量)。

  • 應記錄語音辨識音訊串流，以便 PCM 振幅等級以線性方式追蹤輸入 SPL 的變化，至少在麥克風的 -18 dB 至 +12 dB re 90 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，則會執行以下操作：

  • 應實作聲學回音消除器 (AEC) 技術，並在使用 AudioSource.VOICE_COMMUNICATION 擷取時套用至擷取路徑，以便針對語音通訊進行調整。

如果裝置實作提供的 Acoustic Echo Canceler 會在選取 AudioSource.VOICE_COMMUNICATION 時插入擷取音訊路徑，則會執行以下操作：

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] 必須支援可透過 Visualizer 類別控制的視覺化器 API 實作。
  • [C-1-3] 必須支援可透過 AudioEffect 子類別 DynamicsProcessing 控制的 EFFECT_TYPE_DYNAMICS_PROCESSING 實作。

Android 15 的新規定上路了

  • [C-1-4] 當效果結果傳回至架構音訊管道時，必須支援音訊效果，並使用浮點輸入和輸出。這指的是等化器等一般插入或輔助效果。如果架構音訊管道 (例如後置處理或卸載的效果) 無法顯示效果結果，強烈建議您採用等效行為。

新規定結束

Android 15 新規定生效

  • [C-1-5] 必須確保音效效果在將效果結果傳回至架構音訊管道時，支援多個頻道 (最多為混合器頻道數，也稱為 FCC_LIMIT)。這指的是一般插入或輔助特效，但不包括會變更聲道數量的特效，例如下混、上混、空間化特效。如果架構音訊管道無法看到效果 (例如後處理或卸載的效果)，建議採用等效行為。

新規定結束

  • 應支援可透過 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. 音訊輸出音量

汽車裝置實作方式：

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

5.5.4. 音訊卸載

如果裝置實作支援音訊卸載播放，則會：

  • [C-SR-1] 強烈建議在 AudioTrack gapless API 和 MediaPlayer 的媒體容器指定時，修剪兩個格式相同的短片之間播放的無間斷音訊內容。

5.6. 音訊延遲

音訊延遲是指音訊訊號在系統中傳輸時的延遲時間。許多類型的應用程式都需要短延遲時間，才能實現即時音效效果。

本節的定義如下：

  • 輸出延遲。應用程式寫入 PCM 編碼資料影格，與相應聲音透過裝置端轉換器傳送至環境，或信號透過連接埠離開裝置並可在外部觀察到的時間間隔。
  • 冷輸出延遲。在音訊輸出系統在要求前處於閒置狀態並關閉電源的情況下，從開始輸出串流到第一個影格顯示時間之間的時間。
  • 連續輸出延遲時間。裝置播放音訊後，後續影格輸出延遲時間。
  • 輸入延遲。環境透過裝置端轉換器或信號透過連接埠進入裝置，到應用程式讀取相應 PCM 編碼資料影格之間的間隔。
  • 輸入內容遺失。輸入信號的初始部分，無法使用或無法取得。
  • 冷輸入延遲。在音訊輸入系統閒置並在要求前關閉電源的情況下，從開始串流到收到第一個有效影格之間的時間。
  • 持續輸入延遲。裝置擷取音訊時，後續影格輸入的延遲時間。
  • 連續往返延遲時間。連續輸入延遲時間加上連續輸出延遲時間，再加上一個緩衝區時間。緩衝期可讓應用程式處理訊號，並減少輸入和輸出串流之間的相位差異。
  • OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 集。
  • AAudio 原生音訊 API。Android NDK 中的 AAudio API 組合。
  • 時間戳記。一組組合，其中包含串流中的相對影格位置，以及該影格進入或離開相關端點的音訊處理管道的預估時間。另請參閱 AudioTimestamp。
  • glitch。音訊訊號中的暫時中斷或不正確的取樣值，通常是因為輸出端緩衝區不足、輸入端緩衝區溢位，或任何其他數位或類比雜訊來源所致。
  • 平均絕對誤差 (MAD)。一組值與平均值偏差的絕對值平均值。

Android 15 的新規定上路了

  • 輕觸至音效延遲時間 (TTL) 是指從輕觸螢幕到喇叭播放輕觸所產生的音效之間的時間，由 CTS Verifier 測量。這是使用 AAudio 原生音訊 API 輸出 5 次測量結果的平均值。

  • 來回延遲時間 (RTL) 是 CTS 驗證器所測量的平均持續延遲時間，測量方式是使用 AAudio 原生音訊 API，透過迴送路徑將輸出內容回饋至輸入內容。迴送路徑如下：

    • 喇叭/麥克風：內建喇叭和內建麥克風。
    • 類比：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.hardware.audio.output，則必須符合或超越下列需求：

Android 15 的新規定上路了

  • [C-1-1] AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 傳回的輸出時間戳記精確度為 +/- 2 毫秒。

新規定結束

  • [C-1-2] 冷啟動輸出延遲時間為 500 毫秒以下。

  • [C-1-3] 使用 AAudioStreamBuilder_openStream() 開啟輸出串流時，必須在 1000 毫秒內完成。

Android 15 的新規定上路了

  • [C-1-4] 根據 AAudioStream_getTimestamp 傳回的輸入和輸出時間戳記計算的往返延遲時間，必須在 AAUDIO_PERFORMANCE_MODE_NONE 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 的測量往返延遲時間範圍內，適用於揚聲器、有線和無線耳機。

新規定結束

Android 15 的新規定上路了

如果裝置實作宣告 android.hardware.audio.output，強烈建議您符合或超越下列規定：

  • [C-SR-1] 在揚聲器資料路徑中，冷輸出延遲時間為 100 毫秒以下。

  • [C-SR-2] 輕觸到音訊的延遲時間為 80 毫秒以下。

  • [C-SR-4] 強烈建議，以 AAudioStream_getTimestamp 傳回的輸入和輸出時間戳記為基礎，計算的來回延遲時間應在 AAUDIO_PERFORMANCE_MODE_NONE 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 的測量來回延遲時間 (以喇叭、有線和無線耳機為準) 的 30 毫秒內。

新規定結束

Android 15 的新規定上路了

如果裝置實作符合上述要求，在任何初始校正作業完成後，使用 AAudio 原生音訊 API 時，在至少一項支援的音訊輸出裝置上，連續輸出延遲和冷輸出延遲分別為：

新規定結束

Android 15 新規定生效

如果裝置實作項目不符合透過 AAudio 原生音訊 API 提供低延遲音訊的規定，則會發生以下情況：

  • [C-2-1] 請勿回報支援低延遲音訊。

新規定結束

如果裝置實作內容包含 android.hardware.microphone，則必須符合下列輸入音訊規定：

Android 15 的新規定上路了

  • [C-3-1] 將 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回的輸入時間戳記誤差限制在 +/- 2 毫秒內。此處的「錯誤」是指與正確值的偏差。

新規定結束

  • [C-3-2] 冷啟動輸入延遲時間為 500 毫秒以下。
  • [C-3-3] 使用 AAudioStreamBuilder_openStream() 開啟輸入串流時，必須在 1000 毫秒內完成。

Android 15 的新規定上路了

如果裝置實作內容包含 android.hardware.microphone，強烈建議您遵守下列輸入音訊規定：

  • [C-SR-8] 麥克風資料路徑的冷啟動輸入延遲時間為 100 毫秒以下。
  • [C-SR-11] 將 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回的輸入時間戳記誤差限制在 +/- 1 毫秒內。

新規定結束

Android 15 的新規定上路了

如果裝置實作項目宣告 android.hardware.audio.output 和 android.hardware.microphone，則會執行以下操作：

  • [C-SR-12] 強烈建議在至少一個支援的路徑上，連續往返延遲時間平均值為 50 毫秒以下，且平均絕對誤差小於 10 毫秒。

新規定結束

Android 15 的新規定上路了

下表定義了手持裝置實作項目的 RTL 需求，如 2.2.1 所定義，該部分會宣告 android.hardware.audio.output 和 android.hardware.microphone。

裝置和宣告 RTL (毫秒) MAD (毫秒) 回送路徑
手提式 250 30 喇叭/麥克風、類比 3.5 公釐 (如有支援)、USB (如有支援)
>= MPC_T (14) 80 15 至少一個路徑
FEATURE_AUDIO_LOW_LATENCY 50 10 至少一個路徑
FEATURE_AUDIO_PRO 25 5 至少一個路徑
FEATURE_AUDIO_PRO 20 5 類比 (如支援)
FEATURE_AUDIO_PRO 25 5 USB (如果系統不支援類比)

新規定結束

Android 15 的新規定上路了

下表定義了手持裝置實作項目的 TTL 相關規定，如 2.2.1 所定義，該規定會宣告 android.hardware.audio.output 和 android.hardware.microphone。

裝置和宣告 存留時間 (毫秒)
手提式 250
>= MPC_T (14) 80
MPC_S (13) 100
FEATURE_AUDIO_PRO 80

新規定結束

Android 15 的新規定上路了

如果裝置實作包含頭部追蹤的 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 酬載格式。如需例外狀況，請參閱第 5.1 節中的表格附註。

媒體區段格式

區隔格式 參考資料 必要的轉碼器支援
MPEG-2 傳輸串流 ISO 13818 影片編碼器：
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
如要進一步瞭解 H.264 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 		如要進一步瞭解 H.263，請參閱第 5.1.8 節。
H263-2000 RFC 4629 如要進一步瞭解 H.263，請參閱第 5.1.8 節。
AMR RFC 4867 如要進一步瞭解 AMR-NB，請參閱第 5.1.3 節。
AMR-WB RFC 4867 如要進一步瞭解 AMR-WB，請參閱第 5.1.3 節。
MP4V-ES RFC 6416 如要進一步瞭解 MPEG-4 SP，請參閱第 5.1.8 節。
mpeg4-generic RFC 3640 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.3 節
MP2T RFC 2250 詳情請參閱 HTTP 即時串流下方的「MPEG-2 傳輸串流」

5.8. 安全無虞的媒體服務

如果裝置實作支援安全視訊輸出，且能夠支援安全途徑，則會：

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

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

  • [C-2-1] 對於透過無線通訊協定 (例如 Miracast) 連線的螢幕，必須使用加密強度高的機制 (例如 HDCP 2.x 以上版本) 保護連結。

如果裝置實作宣告支援 Display.FLAG_SECURE 且支援有線外接螢幕，則會：

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

5.9. 樂器數位介面 (MIDI)

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

  • [C-1-1] 必須支援 MIDI 透過所有 MIDI 硬體傳輸裝置，這些傳輸裝置提供一般非 MIDI 連線功能，且這些傳輸裝置如下：

  • [C-1-2] 必須支援應用程式間的 MIDI 軟體傳輸 (虛擬 MIDI 裝置)

  • [C-1-3] 必須包含 libamidi.so (原生 MIDI 支援)

  • 應支援 MIDI 透過 USB 周邊模式，第 7.7 節

5.10. 專業音訊

如果裝置實作項目透過 android.content.pm.PackageManager 類別回報支援 android.hardware.audio.pro 功能，則會：

  • [C-1-1] 必須回報是否支援功能 android.hardware.audio.low_latency。

Android 15 的新規定上路了

  • [C-1-2] 必須具備連續的往返音訊延遲時間，符合 5.6 音訊延遲時間 中定義的 FEATURE_AUDIO_PRO 延遲時間要求，在至少一個支援的路徑上，延遲時間不得超過 25 毫秒。

新規定結束

  • [C-1-3] 必須包含支援 USB 主機模式和 USB 周邊模式的 USB 連接埠。
  • [C-1-4] 必須回報支援功能 android.software.midi。

Android 15 的新規定上路了

  • [C-1-5] 必須使用 AAudio 原生音訊 API 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY，滿足 USB 音訊延遲 需求。

新規定結束

  • [C-1-6] 冷啟動輸出延遲時間不得超過 200 毫秒。
  • [C-1-7] 冷輸入延遲時間不得超過 200 毫秒。

Android 15 的新規定上路了

  • [C-1-8] 在喇叭到麥克風資料路徑上，至少測量 5 次，平均觸碰至音訊延遲時間不得超過 80 毫秒。
  • [C-SR-1] 強烈建議符合 5.6 音訊延遲 一節所定義的延遲時間 (20 毫秒以下)，在 5 次測量中，揚聲器到麥克風路徑的平均絕對誤差小於 5 毫秒。
  • [C-SR-2] 強烈建議您使用 AAudio 原生音訊 API 透過 MMAP 路徑，滿足 Pro Audio 持續來回音訊延遲、冷輸入延遲和冷輸出延遲，以及 USB 音訊需求。

  • [C-SR-3] 強烈建議在音訊處於活動狀態且 CPU 負載有所變化時，提供一致的 CPU 效能。您應使用 Android 應用程式 SynthMark 進行測試。SynthMark 會使用在模擬音訊架構上執行的軟體合成器，用來評估系統效能。如需基準測試的說明，請參閱 SynthMark 說明文件。您必須使用「自動化測試」選項執行 SynthMark 應用程式，並取得下列結果：

    • voicemark.90 >= 32 voices
    • latencymark.fixed.little <= 15 毫秒
    • latencymark.dynamic.little <= 50 毫秒

  • 應盡量減少音訊時鐘不準確和相對於標準時間的誤差。

  • 在 CPU CLOCK_MONOTONIC 運作時，應盡量減少音訊時鐘漂移。

  • 應盡量縮短裝置端轉換器的音訊延遲時間。

  • 應盡量減少透過 USB 數位音訊傳輸的音訊延遲時間。

  • 應記錄所有路徑的音訊延遲時間測量結果。

  • 應盡量減少音訊緩衝區完成回呼輸入時間的抖動，因為這會影響回呼的完整 CPU 頻寬可用百分比。

  • 在正常使用情況下，應在回報的延遲時間內提供零音訊錯誤。

  • 應提供零管道間延遲差異。

  • 應盡量縮短所有傳輸方式的 MIDI 平均延遲時間。

  • 應盡量減少所有傳輸途徑下負載 (抖動) 下的 MIDI 延遲變化。

  • 應在所有傳輸途徑中提供準確的 MIDI 時間戳記。

  • 應盡量減少裝置端轉換器的音訊信號雜訊，包括冷啟動後的一段時間。

  • 在兩者皆處於啟用狀態時，應在對應端點的輸入和輸出端提供零音訊時鐘差異。對應端點的例子包括裝置上的麥克風和喇叭，或音訊插孔輸入和輸出。

  • 在同一個執行緒上，當輸入和輸出端的對應端點都處於活動狀態時，應處理音訊緩衝區完成回呼，並在輸入回呼傳回後立即進入輸出回呼。或者，如果無法在同一個執行緒上處理回呼，請在輸入回呼後立即輸入輸出回呼，讓應用程式在輸入和輸出端保持一致的時間。

  • 應盡量減少 HAL 音訊緩衝區與對應端點輸入和輸出端的相位差異。

  • 應盡量縮短觸控延遲時間。

  • 應盡量減少負載下觸控延遲時間的變化 (抖動)。

新規定結束

Android 15 的新規定上路了

如果裝置實作符合上述所有規定，則：

新規定結束

如果裝置實作包含 4 導體 3.5 公釐音訊插孔，則必須符合下列規定：

Android 15 的新規定上路了

  • [C-2-1] 必須符合以下條件：連續往返音訊延遲時間平均值為 20 毫秒或更短 (如 5.6 音訊延遲 所定義)，且在使用音訊回送 Dongle 的音訊插孔路徑上，經過 5 次測量後，平均絕對誤差小於 5 毫秒。

新規定結束

Android 15 的新規定上路了

新規定結束

如果裝置實作項目省略 4 導體 3.5 公釐耳機插孔，並包含支援 USB 主機模式的 USB 連接埠，則：

  • [C-3-1] 必須實作 USB 音訊類別。

Android 15 新規定生效

  • [C-3-2] 必須在使用 USB 音訊類別的 USB 主機模式連接埠時，在 5 次測量中，持續來回音訊延遲平均值為 25 毫秒以下，且平均絕對誤差小於 5 毫秒。(可使用 USB-3.5 毫米轉接器和音訊回送轉接器，或使用 USB 音訊介面搭配連接輸入端和輸出端的 Patch 線來測量)。
  • [C-SR-6] 強烈建議在使用支援這些需求的 USB 音訊外接裝置時，同時支援每個方向最多 8 個通道的 I/O、96 kHz 取樣率和 24 位元或 32 位元深度。
  • [C-SR-7] 強烈建議您使用 MMAP 路徑上的 AAudio 原生音訊 API 來滿足這組需求。

新規定結束

Android 15 新規定生效

如果裝置實作包含 HDMI 連接埠，則必須符合下列條件：

  • 應支援以 20 位元或 24 位元深度和 192 kHz 的立體聲和八聲道輸出，且至少在一個設定中不損失位元深度或重新取樣。

新規定結束

5.11. 擷取未處理的內容

Android 支援透過 android.media.MediaRecorder.AudioSource.UNPROCESSED 音訊來源錄製未經處理的音訊。在 OpenSL ES 中，您可以使用錄音預設值 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 存取。

如果裝置實作意圖支援未經處理的音訊來源，並將其提供給第三方應用程式，則應：

  • [C-1-1] 必須透過 android.media.AudioManager 屬性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 回報支援。

  • [C-1-2] 必須在中頻範圍內顯示大致平坦的振幅與頻率特性：具體來說，每個用於錄製未經處理音訊來源的麥克風，在 100 Hz 到 7000 Hz 之間的振幅與頻率特性必須為 ±10 dB。

  • [C-1-3] 必須顯示低頻率範圍的振幅等級：具體來說，從 5 z 到 100 Hz 的 ±20 dB 範圍，與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比。

  • [C-1-4] 必須顯示高頻率範圍的振幅等級：具體來說，從 7000 Hz 到 22 kHz 的 ±30 dB 範圍，與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比。

  • [C-1-5] 必須設定音訊輸入靈敏度，以便在使用每個麥克風錄製未經處理的音訊來源時，以 94 dB 的聲壓級別 (SPL) 播放 1000 Hz 正弦音源，產生 16 位元取樣率的 520 rms 回應 (或浮點/雙精確度取樣率的 -36 dB 全量)。

  • [C-1-6] 每個用於錄製未經處理音訊來源的麥克風，信噪比 (SNR) 都必須為 60 分貝以上。(SNR 的測量方式是將 94 dB SPL 與等效的 A 加權自噪聲 SPL 之間的差異)。

  • [C-1-7] 每個用於錄製未經處理音訊來源的麥克風，在 90 dB SPL 輸入音量下，總諧波失真 (THD) 不得超過 1% (1 kHz)。

  • [C-1-8] 除了將音量調整至所需範圍的音量乘數外，路徑中不得有任何其他訊號處理作業 (例如自動增益控制、高通濾波器或回音消除)。換句話說：

    • [C-1-9] 如果架構中因任何原因出現任何訊號處理，則必須停用，並有效地為訊號路徑引入零延遲或額外延遲。
    • [C-1-10] 雖然允許在路徑中使用音量調節器，但絕對不得在訊號路徑中引入延遲或延遲。

所有 SPL 測量皆直接在測試中的麥克風旁進行。如果是多個麥克風設定，這些規定適用於每個麥克風。

如果裝置實作宣告 android.hardware.microphone，但不支援未經處理的音訊來源，則會發生以下情況：

  • [C-2-1] 必須針對 AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API 方法傳回 null，以便正確指出缺乏支援。
  • 強烈建議您仍採用 [C-SR-1]，以滿足未經處理的錄音來源信號路徑的許多要求。

5.12. HDR 影片

Android 13 支援 HDR 技術，詳情請參閱即將推出的說明文件。

像素格式

如果影片解碼器宣稱支援 COLOR_FormatYUVP010，則：

  • [C-1-1] 必須支援 CPU 讀取的 P010 格式 (ImageReader、MediaImage、ByteBuffer)。在 Android 13 中，P010 已放寬，可允許 Y 和 UV 平面使用任意跨距。

  • [C-1-2] P010 輸出緩衝區必須能夠由 GPU 取樣 (當以 GPU_SAMPLING 用途配置時)。這可讓應用程式啟用 GPU 合成和自訂色調對應功能。

如果影片解碼器宣稱支援 COLOR_Format32bitABGR2101010，則表示：

  • [C-2-1] 必須支援輸出介面和 CPU 可讀取的 ByteBuffer 輸出格式 (RGBA_1010102)。

如果影片編碼器宣稱支援 COLOR_FormatYUVP010，則會：

  • [C-3-1] 必須支援輸入途徑和可由 CPU 寫入的輸入內容 (ImageWriter、MediaImage、ByteBuffer) 的 P010 格式。

如果影片編碼器宣稱支援 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 中繼資料時，以最短的延遲時間產生 HDR 中繼資料，並應妥善處理中繼資料在某些影格中存在，但在其他影格中不存在的情況。這些中繼資料應精確 (例如，代表影格實際的峰值亮度和直方圖)。

如果裝置實作內容包含支援 FEATURE_HdrEditing 的編解碼，則這些編解碼會：

  • [C-7-1] 必須支援至少一個 HDR 設定檔。

  • [C-7-2] 必須針對該編解碼器宣傳的所有 HDR 設定檔支援 FEATURE_HdrEditing。換句話說，如果不支援使用 HDR 中繼資料的所有 HDR 設定檔，則必須支援產生 HDR 中繼資料。

  • [C-7-3] 必須支援下列影片編碼器輸入格式，以便完整保留 HDR 解碼訊號：

    • 輸入介面和 ByteBuffer 都必須使用 RGBA_1010102 (已在目標轉移曲線中)，且必須宣傳支援 COLOR_Format32bitABGR2101010。

如果裝置實作內容包含支援 FEATURE_HdrEditing 的編解碼，則該裝置會：

  • [C-7-4] 必須宣傳對 EXT_YUV_target OpenGL 擴充功能的支援。

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

6.1. 開發人員工具

裝置實作方式：

Android 15 新規定生效

  • [C-0-2] 必須支援 Android SDK 中的 ADB 和 AOSP 提供的殼層指令，這些指令可供應用程式開發人員使用，包括 dumpsys、 cmd stats 和 Simpleperf。

新規定結束

  • [C-0-11] 必須支援殼層指令 cmd testharness。從未提供持續性資料區塊的舊版 Android 升級裝置實作項目，可能會免除 C-0-11 的規定。
  • [C-0-3] 不得透過 dumpsys 指令記錄的裝置系統事件 (batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats) 變更格式或內容。

Android 15 新規定生效

  • [C-0-10] 必須完整記錄並提供下列事件，讓 cmd stats 殼層指令和 StatsManager System API 類別能夠存取這些事件。
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • InputDeviceUsageReported
    • JobStateChanged
    • KeyboardConfigured
    • KeyboardSystemsEventReported
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • TouchpadUsage
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged

新規定結束

  • [C-0-4] 裝置端 ADB 守護程序必須預設為停用，且必須提供使用者可存取的機制，以便啟用 Android 偵錯橋接器。
  • [C-0-5] 必須支援安全的 ADB。Android 支援安全的 ADB。安全的 ADB 可在已知的已驗證主機上啟用 ADB。
  • [C-0-6] 必須提供機制，允許從主機連線至 ADB。具體違規事項如下：

如果沒有 USB 連接埠的裝置實作項目支援周邊模式，則會：

  • [C-3-1] 必須透過區域網路 (例如乙太網路或 Wi-Fi) 實作 ADB。
  • [C-3-2] 必須提供 Windows 7、8 和 10 的驅動程式，讓開發人員可透過 ADB 通訊協定連線至裝置。

如果裝置實作項目支援透過 Wi-Fi 或乙太網路連線至主機電腦的 ADB 連線，則會：

  • [C-4-1] AdbManager#isAdbWifiSupported() 方法必須傳回 true。

如果裝置實作項目支援透過 Wi-Fi 或乙太網路連線至主機的 ADB 連線，且包含至少一個攝影機，則會：

  • [C-5-1] 必須讓 AdbManager#isAdbWifiQrSupported() 方法傳回 true。

  • Dalvik 偵錯監視服務 (ddms)

    • [C-0-7] 必須支援 Android SDK 說明文件中所述的所有 ddms 功能。由於 ddm 使用 adb，因此 ddm 的支援功能應預設為停用狀態，但在使用者啟用 Android Debug Bridge 時，必須支援 ddm，如上所述。

  • SysTrace

    • [C-0-9] 必須支援 Android SDK 說明文件中的 systrace 工具。根據預設，Systrace 必須處於停用狀態，且必須提供使用者可存取的機制，才能開啟 Systrace。

  • Perfetto

    • [C-SR-1] 強烈建議您向殼層使用者公開 /system/bin/perfetto 二進位檔，該 cmdline 符合 Perfetto 說明文件。
    • [C-SR-2] 強烈建議您在輸入時，讓 Perfetto 二進位檔接受符合 Perfetto 說明文件中定義的結構描述的 protobuf 設定。
    • [C-SR-3] 強烈建議您使用 Perfetto 二進位檔，以符合 Perfetto 說明文件中定義的結構定義，將 protobuf 追蹤記錄寫入為輸出內容。
    • [C-SR-4] 強烈建議您透過 Perfetto 說明文件中所述的資料來源，透過 Perfeto 二進位檔提供資料來源。

  • 記憶體不足終止工具

    • [C-0-12] 當應用程式遭到「Low Memory Killer」終止時，必須將 LMK_KILL_OCCURRED_FIELD_NUMBER Atom 寫入 statsd 記錄。

  • 測試控管工具模式 如果裝置實作支援殼層指令 cmd testharness 並執行 cmd testharness enable，則會執行以下操作：

  • GPU 工作資訊

    裝置實作方式：

    • [C-0-13] 必須實作 shell 指令 dumpsys gpu --gpuwork，以便顯示 power/gpu_work_period 核心追蹤點傳回的匯總 GPU 工作資料，如果不支援追蹤點，則不顯示任何資料。AOSP 實作項目為 frameworks/native/services/gpuservice/gpuwork/。

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

  • [C-1-1] 應用程式開發人員必須提供操作提示，以便啟用/停用 GPU 偵錯圖層。
  • [C-1-2] 啟用 GPU 偵錯層時，必須在可偵錯應用程式的基礎目錄中，列舉外部工具 (即非平台或應用程式套件的一部分) 提供的程式庫中的層，以支援 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。

6.2. 開發人員選項

Android 提供開發人員支援，讓他們設定應用程式開發相關設定。

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

  • [C-0-1] 必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，顯示與應用程式開發相關的設定。上游 Android 實作項目會預設隱藏「開發人員選項」選單，使用者只要依序輕觸「設定」 >「關於裝置」 >「版本號碼」選單項目七 (7) 次，即可啟動開發人員選項。
  • [C-0-2] 必須預設隱藏開發人員選項。
  • [C-0-3] 必須提供明確的機制，確保啟用開發人員選項時，不會偏袒某個第三方應用程式。必須提供可供公眾存取的文件或網站，說明如何啟用開發人員選項。這份文件或網站必須可從 Android SDK 文件連結。
  • 啟用開發人員選項且使用者安全性有疑慮時，應向使用者提供持續性的視覺通知。
  • 可透過視覺隱藏或停用選單，暫時限制存取開發人員選項選單，以免在使用者安全有疑的情況下造成干擾。

7. 硬體相容性

如果裝置包含特定硬體元件，且該元件具有對應的 API (供第三方開發人員使用)：

  • [C-0-1] 裝置實作項目必須實作 Android SDK 說明文件中所述的 API。

如果 SDK 中的 API 與硬體元件互動，而該硬體元件已明確標示為選用，且裝置實作不含該元件：

  • [C-0-2] 元件 API 的完整類別定義 (如 SDK 所述) 仍須呈現。
  • [C-0-3] API 的行為必須以某種合理的方式實作為無操作。
  • [C-0-4] API 方法必須在 SDK 說明文件允許的情況下傳回空值。
  • [C-0-5] API 方法必須傳回類別的無操作導入方式，因為 SDK 說明文件不允許空值。
  • [C-0-6] API 方法不得擲回 SDK 說明文件未記錄的例外狀況。
  • [C-0-7] 裝置實作項目必須針對相同的建構指紋，透過 android.content.pm.PackageManager 類別的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法，一貫回報正確的硬體設定資訊。

電話 API 就是適用這些規定的典型情境：即使是在非手機裝置上，這些 API 也必須以合理的無作業方式實作。

7.1. 顯示和圖形

Android 包含自動調整應用程式素材資源和 UI 版面配置的設施，可確保第三方應用程式在各種硬體螢幕和設定下順利執行。Android 相容螢幕是指實作「Android 開發人員 - 螢幕相容性總覽」一文、本節 (7.1) 及其子節所述的所有行為和 API，以及本 CDD 第 2 節所述的任何其他裝置類型專屬行為。

裝置實作方式：

  • [C-0-1] 預設情況下，必須只將第三方應用程式算繪至 Android 相容的螢幕。

本節中所參照的單位定義如下：

  • 實體對角尺寸。螢幕亮面區域兩個相對角落之間的距離，以英寸為單位。
  • 密度。1 英寸線性水平或垂直跨度的像素數，以每英寸像素 (ppi 或 dpi) 表示。在列出 ppi 和 dpi 值的情況下，水平和垂直 dpi 都必須落在所列範圍內。
  • 顯示比例。螢幕長邊和短邊的像素比例。舉例來說，如果螢幕的解析度為 480x854 像素，則寬高比為 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] 必須依照 Android SDK 說明文件中定義的 Configuration.screenLayout，回報正確的版面配置大小。具體來說，裝置實作項目必須回報正確的邏輯密度獨立像素 (dp) 螢幕尺寸，如下所示：

    • 如果裝置的 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 以外的任何值，且回報 Configuration.screenLayout 的 small 大小，則必須至少為 426 dp x 320 dp。
    • 回報 Configuration.screenLayout normal 大小的裝置，必須至少有 480 dp x 320 dp。
    • 回報 Configuration.screenLayout large 大小的裝置，必須至少有 640 dp x 480 dp。
    • 為 Configuration.screenLayout 回報 xlarge 大小的裝置，必須至少有 960 dp x 720 dp。

  • [C-0-2] 必須正確遵循應用程式在 AndroidManifest.xml 中聲明的螢幕尺寸支援情形，如 Android SDK 說明文件所述，使用 <supports-screens> 屬性。

  • 可使用圓角的 Android 相容螢幕。

如果裝置實作項目支援可用於 UI_MODE_TYPE_NORMAL 大小設定的螢幕，並使用圓角實體螢幕來算繪這些螢幕，則會：

  • [C-1-1] 必須確保每個這類顯示畫面都符合下列至少一項規定：

    • 圓角半徑小於或等於 38 dp。
    • 當 18 dp x 18 dp 的方塊錨定在邏輯顯示畫面的每個角落時，每個方塊至少會在螢幕上顯示一個像素。

  • 應提供使用者操作提示，以便切換至具有矩形角落的顯示模式。

如果裝置實作項目僅支援 NO_KEYS 鍵盤設定，且打算回報支援 UI_MODE_TYPE_NORMAL 使用者介面模式設定，則應：

  • [C-4-1] 版面配置大小 (不含任何螢幕裁剪) 必須至少為 596 dp x 384 dp 或更大。

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

Android 15 的新規定上路了

如果裝置實作包含一或多個可折疊的 Android 相容顯示區域，或在多個 Android 相容顯示面板區域之間加入折疊式轉軸，並將這些顯示區域提供給應用程式，則：

  • [C-4-1] 必須實作正確版本的 Window Manager Extensions API 級別，如「WindowManager Extensions」一文所述。

新規定結束

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，或產生小於 320dp 的有效螢幕尺寸 (等同於資源限定詞 sw320dp)，以免造成螢幕顯示不佳。
  • [C-1-2] 不得將顯示器縮放至小於 DENSITY_DEVICE_STABLE 的 0.85 倍。
  • 為確保良好的可用性和一致的字型大小，建議您提供下列原生顯示選項的縮放比例 (同時遵守上述限制)
    • 小：0.85 倍
    • 預設值：1x (原生顯示縮放比例)
    • 大：1.15 倍
    • 較大：1.3 倍
    • 最大 1.45 倍

7.1.2. 顯示指標

如果裝置實作內容包含與 Android 相容的螢幕或將影片輸出至與 Android 相容的螢幕，則必須符合下列條件：

如果裝置實作內容不包含內嵌螢幕或影片輸出內容，則：

  • [C-2-1] 必須針對模擬的預設 view.Display，回報 Android 相容螢幕的正確值，如 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] 應用程式必須支援動態螢幕方向，可切換為直向或橫向。也就是說，裝置必須遵循應用程式要求的特定螢幕方向。
  • [C-1-2] 變更螢幕方向時，不得變更回報的螢幕大小或密度。
  • 可選取直向或橫向方向做為預設。

7.1.4. 2D 和 3D 圖形加速功能

7.1.4.1. OpenGL ES

裝置實作方式：

  • [C-0-1] 必須透過受管理的 API (例如透過 GLES10.getString() 方法) 和原生 API，正確識別支援的 OpenGL ES 版本 (1.1、2.0、3.0、3.1、3.2)。
  • [C-0-2] 必須針對所支援的每個 OpenGL ES 版本，提供所有對應的受管理 API 和原生 API 支援。

如果裝置實作內容包含螢幕或影片輸出內容，則必須符合下列條件：

Android 15 的新規定上路了

新規定結束

Android 15 的新規定上路了

  • [C-SR-1] 強烈建議支援 OpenGL ES 3.1。

新規定結束

  • 應支援 OpenGL ES 3.2。

OpenGL ES dEQP 測試會劃分為多個測試清單，每個清單都會附上相關日期/版本號碼。這些檔案位於 external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt 的 Android 原始碼樹中。如果裝置支援自報級別的 OpenGL ES，表示裝置可通過所有測試清單中的 dEQP 測試，且可回溯至該級別。

如果裝置實作項目支援任何 OpenGL ES 版本，則會：

  • [C-2-1] 必須透過 OpenGL ES 管理 API 和原生 API 回報已實作的任何其他 OpenGL ES 擴充功能，反之，則不得回報不支援的擴充功能字串。
  • [C-2-2] 必須支援 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、EGL_ANDROID_recordable 和 EGL_ANDROID_GLES_layers 擴充功能。
  • [C-2-3] 必須透過 android.software.opengles.deqp.level 功能旗標回報 OpenGL ES dEQP 測試支援的最高版本。
  • [C-2-4] 必須至少支援 android.software.opengles.deqp.level 功能旗標中所回報的 132383489 版 (自 2020 年 3 月 1 日起)。
  • [C-2-5] 針對每個支援的 OpenGL ES 版本，必須在 132383489 版與 android.software.opengles.deqp.level 功能旗標中指定的版本之間，通過測試清單中的所有 OpenGL ES dEQP 測試。
  • [C-SR-2] 強烈建議支援 EGL_KHR_partial_update 和 OES_EGL_image_external 擴充功能。

  • 應透過 getString() 方法，準確回報任何支援的紋理壓縮格式，這通常是特定供應商的格式。

  • 應支援 EGL_IMG_context_priority 和 EGL_EXT_protected_content 擴充功能。

如果裝置實作宣告支援 OpenGL ES 3.0、3.1 或 3.2，則會：

  • [C-3-1] 除了 libGLESv2.so 程式庫中的 OpenGL ES 2.0 函式符號外，您必須匯出這些版本的相應函式符號。
  • [C-SR-3] 強烈建議支援 OES_EGL_image_external_essl3 擴充功能。

如果裝置實作項目支援 OpenGL ES 3.2，則會：

  • [C-4-1] 必須完整支援 OpenGL ES Android 擴充套件。

如果裝置實作項目支援 OpenGL ES 的完整 Android 擴充套件，則會：

  • [C-5-1] 必須透過 android.hardware.opengles.aep 功能旗標識別支援。

如果裝置實作作業公開支援 EGL_KHR_mutable_render_buffer 擴充功能，則會：

  • [C-6-1] 也必須支援 EGL_ANDROID_front_buffer_auto_refresh 擴充功能。
7.1.4.2. Vulkan

Android 支援 Vulkan，這是一款低負載的跨平台 API，可用於製作高品質 3D 圖像。

如果裝置實作項目支援 OpenGL ES 3.1，則可執行以下操作：

  • [C-SR-1] 強烈建議您納入對 Vulkan 1.3 的支援。
  • [C-4-1] 不得支援 Vulkan 變化版本 (也就是說，Vulkan 核心版本的變化部分必須為零)。

如果裝置實作內容包含螢幕或影片輸出內容，則必須符合下列條件：

  • [C-SR-2] 強烈建議您納入對 Vulkan 1.3 的支援。

Vulkan dEQP 測試會分割為多個測試清單，每個清單都會附上相關日期/版本。這些檔案位於 external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt 的 Android 原始碼樹中。如果裝置支援自報級別的 Vulkan，表示該裝置可通過所有測試清單 (包括此級別和更早級別) 的 dEQP 測試。

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

  • [C-1-1] 必須使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能旗標回報正確的整數值。
  • [C-1-2] 必須為 Vulkan 原生 API vkEnumeratePhysicalDevices() 列舉至少一個 VkPhysicalDevice。
  • [C-1-3] 必須針對每個列舉的 VkPhysicalDevice 完全實作 Vulkan 1.1 API。
  • [C-1-4] 必須透過 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties()，列舉應用程式套件原生資料庫目錄中名為 libVkLayer*.so 的原生資料庫所包含的圖層。
  • [C-1-5] 除非應用程式已將 android:debuggable 屬性設為 true，或將中繼資料 com.android.graphics.injectLayers.enable 設為 true，否則不得列舉應用程式套件以外的程式庫所提供的圖層，或提供其他追蹤或攔截 Vulkan API 的方法。
  • [C-1-6] 必須透過 Vulkan 原生 API 回報所有支援的擴充功能字串，反之，則不得回報不支援的擴充功能字串。
  • [C-1-7] 必須支援 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 擴充功能。
  • [C-1-8] 必須透過 android.software.vulkan.deqp.level 功能旗標回報 Vulkan dEQP 測試支援的最高版本。
  • [C-1-9] 必須至少支援 132317953 版本 (自 2019 年 3 月 1 日起)，如 android.software.vulkan.deqp.level 功能旗標所述。
  • [C-1-10] 必須在 132317953 版本和 android.software.vulkan.deqp.level 功能旗標中指定的版本之間，通過測試清單中的所有 Vulkan dEQP 測試。
  • [C-1-11] 不得列舉支援 VK_KHR_video_queue、VK_KHR_video_decode_queue 或 VK_KHR_video_encode_queue 擴充功能。
  • [C-SR-3] 強烈建議支援 VK_KHR_driver_properties 和 VK_GOOGLE_display_timing 擴充功能。
  • [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。

Android 15 的新規定上路了

如果裝置實作項目支援 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。

如果裝置實作包含 Vulkan 1.1 的支援，並宣告 此處所述的任何 Vulkan 功能旗標，則會：

  • [C-3-1] 必須公開支援 SYNC_FD 外部訊號量和處理常式類型，以及 VK_ANDROID_external_memory_android_hardware_buffer 擴充功能。

  • [C-SR-7] 強烈建議您將 VK_KHR_external_fence_fd 擴充功能提供給第三方應用程式，並讓應用程式能夠將圍欄酬載匯出至 POSIX 檔案描述元，並從中匯入圍欄酬載，如這裡所述。

7.1.4.3. RenderScript

裝置實作方式：

7.1.4.4. 2D 圖形加速

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

裝置實作方式：

  • [C-0-1] 必須預設啟用硬體加速功能，且如果開發人員透過設定 android:hardwareAccelerated="false" 或直接透過 Android View API 停用硬體加速功能，則必須停用硬體加速功能。
  • [C-0-2] 必須顯示與 Android SDK 硬體加速說明文件一致的行為。

Android 包含 TextureView 物件，可讓開發人員直接將硬體加速的 OpenGL ES 材質整合為 UI 階層中的算繪目標。

裝置實作方式：

  • [C-0-3] 必須支援 TextureView API，且必須與上游 Android 實作項目的行為一致。
7.1.4.5. 廣色域螢幕

如果裝置實作項目透過 Configuration.isScreenWideColorGamut() 聲稱支援廣色域螢幕，則會：

  • [C-1-1] 螢幕必須經過色彩校正。
  • [C-1-2] 螢幕的色域必須完全涵蓋 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 開發的舊版應用程式，因為舊版 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] 必須提供使用者操作元素，以便啟動已安裝應用程式，其中活動的 <intent-filter> 已設為 ACTION=MAIN，並為電視裝置實作 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER。主畫面功能應是這項使用者操作元素的機制。
  • 應提供「最近」和「返回」功能的按鈕。

如果提供「Home」、「Recents」或「Back」功能，則應符合下列條件：

  • [C-1-1] 必須透過單一動作 (例如輕觸、雙擊或手勢) 即可存取，且任一動作皆可使用。
  • [C-1-2] 必須清楚指出哪個單一動作會觸發每個函式。例如在按鈕上顯示可見的圖示、在螢幕的導覽列部分顯示軟體圖示，或是在開箱設定體驗期間，引導使用者逐步操作示範流程。

裝置實作方式：

  • [C-SR-1] 強烈建議您不要為 Menu 函式提供輸入機制，因為自 Android 4.0 起，此函式已淘汰，改為使用動作列。

  • [C-SR-2] 強烈建議您提供可取消的所有導覽功能。「可取消」的定義是指，如果使用者在滑動動作結束後未釋放手指，則可防止導覽功能執行 (例如返回主畫面、返回上一個畫面等)。

如果裝置實作提供選單功能，則會：

  • [C-2-1] 只要動作溢位選單彈出式視窗不為空白，且動作列可見，就必須顯示動作溢位按鈕。
  • [C-2-2] 選取動作列中的溢位按鈕時，請勿修改顯示的動作溢位彈出式視窗位置，但選取「選單」功能時，您可以將動作溢位彈出式視窗顯示在螢幕上經過修改的位置。

如果裝置實作未提供 Menu 函式，為了向下相容，裝置會執行以下操作：

  • [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 標記時，自訂可滑動的系統面板必須隱藏，直到使用者將系統列 (又稱為導覽列和狀態列) 帶入或取消淡出，才會顯示。

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

  • [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] 必須為 Configuration.touchscreen API 欄位回報 TOUCHSCREEN_FINGER。
  • [C-1-2] 必須回報 android.hardware.touchscreen 和 android.hardware.faketouch 功能旗標。

如果裝置實作項目包含觸控螢幕，且可在主要 Android 相容螢幕上追蹤多個觸控動作，則必須符合下列條件：

  • [C-2-1] 必須回報適當的功能旗標 android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand，對應裝置上的特定觸控螢幕類型。

如果裝置實作項目仰賴外部輸入裝置 (例如滑鼠或軌跡球，也就是不直接觸碰螢幕) 在主要 Android 相容螢幕上輸入內容，且符合第 7.2.5 節的假觸控要求，則必須：

  • [C-3-1] 不得回報任何以 android.hardware.touchscreen 開頭的功能旗標。
  • [C-3-2] 請務必只回報 android.hardware.faketouch。
  • [C-3-3] 必須針對 Configuration.touchscreen API 欄位回報 TOUCHSCREEN_NOTOUCH。

7.2.5. 假觸控輸入

觸控模擬介面會提供使用者輸入系統，可模擬觸控螢幕的部分功能。舉例來說，滑鼠或遙控器可驅動螢幕上的游標，模擬觸控操作，但使用者必須先將游標移至目標，然後點選。滑鼠、觸控板、以陀螺儀為基礎的空中滑鼠、陀螺儀指標、搖桿和多點觸控觸控板等許多輸入裝置，都支援模擬觸控互動。Android 包含功能常數 android.hardware.faketouch，對應至高保真非觸控 (以滑鼠為準) 輸入裝置，例如滑鼠或觸控板，可充分模擬觸控輸入 (包括基本手勢支援)，並表示裝置支援模擬的觸控螢幕功能子集。

如果裝置實作項目不含觸控螢幕，但包含其他指標輸入系統，則應：

  • 應宣告支援 android.hardware.faketouch 功能旗標。

如果裝置實作項目宣告支援 android.hardware.faketouch，則會：

  • [C-1-1] 必須回報指標位置的 絕對 X 和 Y 螢幕位置，並在畫面上顯示視覺指標。
  • [C-1-2] 您必須使用動作代碼回報觸控事件，該代碼會指定在指標在螢幕上往下或往上移動時發生的狀態變更。
  • [C-1-3] 必須支援在畫面上對物件執行指標向上和向下操作，以便使用者模擬輕觸畫面上的物件。
  • [C-1-4] 必須在時間門檻內，支援在螢幕上同一個物件上，以指標下、指標上、指標下、指標上的順序操作，讓使用者模擬雙擊螢幕上的物件。
  • [C-1-5] 必須支援在螢幕上任意點按下指標，然後將指標移動至螢幕上任意其他任意點，接著再將指標移除，讓使用者模擬觸控拖曳動作。
  • [C-1-6] 必須支援指標向下，然後允許使用者快速將物件移至螢幕上的不同位置，然後指標向上，讓使用者在螢幕上揮動物件。

如果裝置實作項目宣告支援 android.hardware.faketouch.multitouch.distinct，則會：

  • [C-2-1] 必須宣告支援 android.hardware.faketouch。
  • [C-2-2] 必須支援對兩個以上獨立指標輸入內容進行獨立追蹤。

如果裝置實作項目宣告支援 android.hardware.faketouch.multitouch.jazzhand，則會：

  • [C-3-1] 必須宣告支援 android.hardware.faketouch。
  • [C-3-2] 必須支援 5 個 (追蹤一手的手指) 或更多獨立的游標輸入裝置的獨立追蹤功能。

7.2.6. 支援遊戲控制器

7.2.6.1. 按鈕對應

裝置實作方式：

  • [C-1-1] 必須能夠將 HID 事件對應至下表所列的對應 InputEvent 常數。上游 Android 實作項目符合這項規定。

如果裝置實作方式是內嵌控制器，或在盒中附上單獨的控制器，以便輸入下表所列的所有事件，則必須符合下列條件：

  • [C-2-1] 必須宣告功能旗標 android.hardware.gamepad
按鈕 HID 用途2 Android 按鈕
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
是1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad 向上1
D-pad 向下1		 0x01 0x00393 AXIS_HAT_Y4
D-pad 左側1
D-pad 右側1		 0x01 0x00393 AXIS_HAT_X4
左肩按鈕1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
右肩按鈕1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
按下左搖桿1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
右搖桿點擊1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
返回1 0x0c 0x0224 KEYCODE_BACK (4)

1 個 KeyEvent

2 上述 HID 用途必須在 Gamepad 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，則裝置實作必須按照 Android SDK 說明文件和 Android 開放原始碼說明文件中的說明，實作該 API。

裝置實作方式：

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

如果裝置實作包含特定感應器類型，且該類型有對應的 API 供第三方開發人員使用，則他們可以：

  • [C-1-1] 必須使用 Android SDK 說明文件中定義的各感應器類型相關國際單位制 (公制) 值，回報所有感應器測量值。
  • [C-1-2] 對於感應器串流的情況，如果應用程式處理器處於活動狀態，則必須以 100 毫秒 + 2 * sample_time 的最大延遲時間回報感應器資料，其中 sample_time 為要求的最大延遲時間。這項延遲不包含任何篩選延遲。
  • [C-1-3] 必須在感應器啟用後的 400 毫秒 + 2 * sample_time 內回報第一個感應器樣本。這個範例的精確度為 0，這屬於可接受的範圍。
  • [C-1-4] 對於 Android SDK 說明文件中指出的任何「連續感應器」 API，裝置實作必須持續提供定期資料樣本，且抖動應低於 3%，其中抖動是指連續事件之間回報的時間戳記值差異的標準差。
  • [C-1-5] 請務必確保感應器事件串流絕對不會阻止裝置 CPU 進入休眠狀態，或從休眠狀態喚醒。
  • [C-1-6] 必須以 Android SDK 說明文件中定義的奈秒為單位回報事件時間，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘同步。
  • [C-SR-1] 強烈建議將時間戳記同步處理錯誤值控制在 100 毫秒以下，且應將時間戳記同步處理錯誤值控制在 1 毫秒以下。
  • 啟用多個感應器時，耗電量不應超過個別感應器回報的耗電量總和。

以上清單並非完整列舉；Android SDK 的說明文件行為和 Android 開放原始碼說明文件的感應器應視為權威來源。

如果裝置實作包含特定感應器類型，且該類型有對應的 API 供第三方開發人員使用，則他們可以：

  • [C-1-6] 必須為所有感應器設定非零解析度，並透過 Sensor.getResolution() API 方法回報值。

某些感應器類型為複合類型，也就是說，這些類型可從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速度感應器)。

裝置實作方式：

  • 應在包含「感應器類型」中所述的必要實體感應器時，導入這些感應器類型。

如果裝置實作包含複合感應器，則會執行以下操作：

  • [C-2-1] 必須按照 Android 開放原始碼說明文件中關於複合感應器的說明，實作感應器。

如果裝置實作包含特定感應器類型，且該類型具有對應的第三方開發人員 API，而感應器只會回報一個值，則裝置實作會：

如果裝置實作項目包含支援 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 位元。
  • 如果特性在生命週期中變更且經過補償，則應在使用期間進行校正，並在裝置重新啟動之間保留補償參數。
  • 應進行溫度補償。

如果裝置實作包含 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 毫瓦。
  • 當裝置處於動態或靜態狀態時，每個值應低於 2 毫瓦和 0.5 毫瓦。

如果裝置實作包含 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 毫瓦。
  • 當感應器以 10 Hz 的頻率註冊批次模式時，耗電量應低於 3 毫瓦。

7.3.3. GPS

裝置實作方式：

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

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

  • [C-1-1] 透過 LocationManager#requestLocationUpdate 要求時，位置輸出必須以至少 1 Hz 的速率支援。
  • [C-1-2] 連上 0.5 Mbps 以上傳輸速的網際網路時，必須能在 10 秒內 (快速首次修正時間) 判定開放天空的定位 (強烈訊號、多路徑不明顯、HDOP < 2)。通常，您可以使用某種輔助或預測 GPS/GNSS 技術來滿足這項要求，以便盡可能縮短 GPS/GNSS 鎖定時間 (輔助資料包括參考時間、參考位置和衛星定時碼/時鐘)。
    • [C-1-6] 進行這類位置計算後，裝置實作項目必須在 5 秒內，在開放天空中，在位置要求重新啟動時，在初始位置計算後最多一小時內，確定其位置，即使後續要求是在沒有資料連線和/或電源週期後提出，也一樣。

  • 在空曠地區確定位置後，當裝置處於靜止狀態或以每秒平方公尺 1 公尺以下的加速度移動時：

    • [C-1-3] 必須能夠在至少 95% 的時間內，判斷出 20 公尺以內的位置，以及每秒 0.5 公尺以內的速度。
    • [C-1-4] 必須透過 GnssStatus.Callback 同時追蹤及回報單一星座至少 8 顆衛星的資料。
    • 應可同時追蹤至少 24 顆衛星，來自多個星座 (例如 GPS + 至少一個 Glonass、Beidou、Galileo)。

  • [C-SR-2] 強烈建議在緊急電話通話期間，透過 GNSS 位置供應器 API 繼續提供正常的 GPS/GNSS 位置輸出內容。

  • [C-SR-3] 強烈建議您回報所有追蹤到的星座 (如 GnssStatus 訊息所述) 的全球導航衛星系統測量資料，但 SBAS 除外。

  • [C-SR-4] 強烈建議您回報 AGC 和 GNSS 測量頻率。

  • [C-SR-5] 強烈建議您將所有預估準確度 (包括方位角、速度和垂直) 列為每個 GPS/GNSS 位置的一部分。

  • [C-SR-6] 強烈建議您一發現全球導航衛星系統測量資料，就回報這類資料，即使尚未回報透過 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] 變化值不得超過每 Hz 1e-7 rad^2 / s^2 (每 Hz 變化值，或 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] 強烈建議您能夠回報 300hPa 到 1100hPa 範圍內的壓力測量值。
  • 絕對精確度應為 1hPa。
  • 應在 20hPa 範圍內，具有 0.12hPa 的相對準確度 (相當於在海平面上，約 200m 的變化有 1m 的準確度)。

7.3.6. 測溫

如果裝置實作包含環境溫度計 (溫度感應器)，則必須：

  • [C-1-1] 必須為環境溫度感應器定義 SENSOR_TYPE_AMBIENT_TEMPERATURE，且感應器必須以攝氏度測量使用者與裝置互動時的環境 (房間/車廂) 溫度。

如果裝置實作包含溫度計感應器，可測量環境溫度以外的溫度，例如 CPU 溫度，則應遵守下列規定：

如果裝置實作包含用於監控皮膚溫度的感應器，則必須符合下列條件：

7.3.7. 光度計

  • 裝置實作可能會包含光度計 (環境光感應器)。

7.3.8. 鄰近感應器

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

如果裝置實作包含鄰近感應器，且只回報二元「近」或「遠」的讀數，則會發生以下情況：

  • [C-1-1] 必須測量物體與螢幕方向相同的近距離。也就是說，接近感應器必須以偵測靠近螢幕的物體為優先，因為這類感應器的主要用途是偵測使用者正在使用的手機。如果裝置實作包含其他方向的接近感應器，則絕對不應透過此 API 存取。
  • [C-1-2] 必須有 1 位元或更高的準確度。
  • [C-1-3] 必須使用 0 公分做為近距離讀數，並使用 5 公分做為遠距離讀數。
  • [C-1-4] 必須回報最大範圍和解析度為 5。

7.3.9. 高精確度感應器

如果裝置實作包含本節所定義的一系列高品質感應器，並將這些感應器提供給第三方應用程式，則這些感應器會：

  • [C-1-1] 必須透過 android.hardware.sensor.hifi_sensors 功能標記識別功能。

如果裝置實作宣告 android.hardware.sensor.hifi_sensors，則會執行以下操作：

  • [C-2-1] 必須具備 TYPE_ACCELEROMETER 感應器，且符合下列條件：

    • 測量範圍必須至少介於 -8g 和 +8g 之間，且強烈建議測量範圍至少介於 -16g 和 +16g 之間。
    • 測量解析度必須至少為 2048 LSB/g。
    • 測量頻率必須為 12.5 Hz 以下。
    • 測量頻率上限必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
    • 測量雜訊不得超過 400 μg/√Hz。
    • 必須實作此感應器的非喚醒形式，並提供至少 3000 個感應器事件的緩衝功能。
    • 必須有批次耗電量，且不得超過 3 毫瓦。
    • [C-SR-1] 強烈建議 3dB 測量頻寬至少為 Nyquist 頻率的 80%，且白噪音頻譜位於這個頻寬內。
    • 在室溫下測試時，加速度隨機走動應小於 30 μg/√Hz。
    • 偏差變化與溫度的差異應小於 +/- 1 mg/°C。
    • 最佳擬合線非線性應為 0.5% 以下，且靈敏度變化與溫度應為 0.03%/°C 以下。
    • 在裝置的操作溫度範圍內，交叉軸敏感度應小於 2.5%，且交叉軸敏感度變化小於 0.2%。

  • [C-2-2] 必須有 TYPE_ACCELEROMETER_UNCALIBRATED，且其品質要求與 TYPE_ACCELEROMETER 相同。

  • [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] 強烈建議 3dB 測量頻寬至少為 Nyquist 頻率的 80%，且白噪音頻譜位於這個頻寬內。
    • 在室溫下測試時，應有小於 0.001 °/s √Hz 的隨機速率。
    • 偏差變化與溫度的差異應小於 +/- 0.05 °/ s / °C。
    • 溫度敏感度變化應低於 0.02% / °C。
    • 最佳擬合線的非線性應低於 0.2%。
    • 噪音密度應低於 0.007 °/s/√Hz。
    • 在裝置靜止時，溫度範圍為 10 到 40 ℃ 時，校準誤差應小於 0.002 rad/s。
    • 應具有小於 0.1°/s/g 的重力感應度。
    • 在裝置的作業溫度範圍內，應具有跨軸敏感度 < 4.0%，以及跨軸敏感度變化 < 0.3%。

  • [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED 必須與 TYPE_GYROSCOPE 具有相同的品質規定。

  • [C-2-5] 必須具備 TYPE_GEOMAGNETIC_FIELD 感應器，且符合下列條件：

    • 測量範圍必須至少介於 -900 和 +900 μT 之間。
    • 測量解析度必須至少為 5 LSB/uT。
    • 測量頻率必須低於或等於 5 Hz。
    • 測量頻率上限必須為 50 Hz 以上。
    • 測量雜訊不得超過 0.5 uT。

  • [C-2-6] 必須有 TYPE_MAGNETIC_FIELD_UNCALIBRATED，其品質要求與 TYPE_GEOMAGNETIC_FIELD 相同，且：

    • 必須實作此感應器的非喚醒形式，並提供至少 600 個感應器事件的緩衝功能。
    • [C-SR-3] 當回報率為 50 Hz 以上時，強烈建議白噪音頻譜從 1 Hz 到至少 10 Hz。

  • [C-2-7] 必須具備 TYPE_PRESSURE 感應器，且符合下列條件：

    • 測量範圍必須至少介於 300 和 1100 hPa 之間。
    • 測量解析度必須至少為 80 LSB/hPa。
    • 測量頻率必須低於或等於 1 Hz。
    • 測量頻率上限必須為 10 Hz 以上。
    • 測量雜訊不得超過 2 Pa/√Hz。
    • 必須實作此感應器的非喚醒形式，並提供至少 300 個感應器事件的緩衝功能。
    • 批次處理的耗電量不得超過 2 毫瓦。

  • [C-2-8] 必須具備 TYPE_GAME_ROTATION_VECTOR 感應器。

  • [C-2-9] 必須具備 TYPE_SIGNIFICANT_MOTION 感應器，且符合下列條件：

    • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。

  • [C-2-10] 必須具備 TYPE_STEP_DETECTOR 感應器，且符合下列條件：

    • 必須實作此感應器的非喚醒形式，並提供至少 100 個感應器事件的緩衝功能。
    • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
    • 必須具有不超過 4 毫瓦的批次耗電量。

  • [C-2-11] 必須具備 TYPE_STEP_COUNTER 感應器，且符合下列條件：

    • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。

  • [C-2-12] 必須具備 TILT_DETECTOR 感應器，且符合下列條件：

    • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。

  • [C-2-13] 加速計、陀螺儀和磁力計回報的相同物理事件事件時間戳記，必須相差 2.5 毫秒以內。加速計和陀螺儀回報的相同物理事件事件時間戳記，應在 0.25 毫秒內。

  • [C-2-14] 陀螺儀感應器事件時間戳記必須與攝影機子系統相同，且誤差不得超過 1 毫秒。

  • [C-2-15] 必須在上述任何實體感應器提供資料給應用程式後的 5 毫秒內，將資料樣本傳送至應用程式。

  • [C-2-16] 在啟用下列任何感應器組合時，裝置靜止時的耗電量不得超過 0.5 毫瓦，裝置移動時的耗電量不得超過 2.0 毫瓦：

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] 可使用 TYPE_PROXIMITY 感應器，但如果使用，則至少須具備 100 個感應器事件的緩衝區功能。

請注意，本節中的所有耗電量規定均不包含應用程式處理器的耗電量。這包括整個感應器鏈路 (感應器、任何支援電路、任何專用感應器處理系統等) 所消耗的電力。

如果裝置實作方式包含直接感應器支援功能，則會：

  • [C-3-1] 必須透過 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API，正確宣告支援直接管道類型和直接回報率等級。
  • [C-3-2] 對於宣稱支援感應器直接管道的所有感應器，至少必須支援兩種感應器直接管道類型之一。
  • 應支援透過感應器直接管道回報事件，適用於下列類型的主要感應器 (非喚醒變化版本)：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生物特徵辨識感應器

如要進一步瞭解如何評估生物特徵解鎖安全性，請參閱「評估生物特徵辨識安全性」說明文件。

如果裝置實作內容包含安全的螢幕鎖定畫面，則會：

  • 應包含生物特徵辨識感應器

生物特徵辨識感應器可根據偽造和冒用接受率，以及生物特徵辨識管道的安全性，歸類為第 3 級 (舊稱強式)、第 2 級 (舊稱弱式) 或第 1 級 (舊稱便利性)。這項分類決定生物辨識感應器與平台和第三方應用程式介接的功能。如要將感應器歸類為 Class 1、Class 2 或 Class 3，則必須符合下列詳細說明的其他規定。第 2 級和第 3 級生物特徵辨識功能都會獲得額外功能，詳情請參閱下文。

如果裝置實作透過 android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL 向第三方應用程式提供生物特徵辨識感應器，則：

  • [C-4-1] 必須符合本文所定義的第 3 級或第 2 級 生物特徵辨識系統需求。
  • [C-4-2] 必須辨識並遵循在 Authenticators 類別中定義為常數的每個參數名稱，以及任何組合。相反地，除了在 Authenticators 中以公開常數記錄的常數，以及任何常數組合，您絕對不應認可或辨識傳遞至 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法的整數常數。
  • [C-4-3] 必須在搭載 Class 3 或 Class 2 生物辨識功能的裝置上實作 ACTION_BIOMETRIC_ENROLL 動作。這項動作必須只顯示第 3 級或第 2 級生物辨識系統的註冊入口點。

Android 15 的新規定上路了

  • [C-4-4] 應用程式必須允許使用 PromptContentView 內容顯示格式，將自訂內容新增至 BiometricPrompt。內容顯示格式不得擴充，以便允許圖像、連結、互動式內容或其他未屬於 BiometricPrompt API 的媒體格式。您可以進行不會變更、遮蔽或截斷這類內容的樣式調整 (例如變更位置、邊框間距、邊界和字體排版)。

新規定結束

如果裝置實作項目支援被動生物辨識功能，則必須符合下列條件：

  • [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] 必須要求使用者提供建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)，才能重設遭鎖定的生物特徵辨識鎖定計數器。第 3 級生物特徵辨識系統可針對相同或較低等級的鎖定生物特徵辨識系統，重設鎖定計數器。第 2 級或第 1 級生物特徵辨識功能絕對不應允許完成任何生物特徵辨識功能的鎖定重設作業。

  • [C-SR-3] 強烈建議您在每次驗證時，只要求確認一種生物特徵辨識資料 (例如，如果裝置上同時提供指紋和臉部感應器，則應在確認其中任一種生物特徵辨識資料後，才傳送 onAuthenticationSucceeded)。

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

  • [C-6-1] 必須符合下文中定義的 Class 3 相關規定。
  • [C-6-2] 驗證需要 BIOMETRIC_STRONG，或驗證是透過 CryptoObject 叫用時，必須只提供第 3 級生物特徵辨識。

如果裝置實作項目希望將生物特徵辨識感應器視為第 1 級 (舊稱便利)，則應採取以下做法：

  • [C-1-1] 錯誤接受率必須低於 0.002%。
  • [C-1-2] 必須揭露相較於高強度的 PIN 碼、解鎖圖案或密碼，這項模式的安全性可能較低，並且清楚列出啟用這項模式的風險，如果根據 Android 生物特徵辨識測試規範的測量結果，偽造和冒用接受率高於 7%，則須揭露這項資訊。
  • [C-1-9] 必須要求使用者提供建議的主要驗證方式 (例如生物特徵辨識驗證的回退時間至少為 90 秒，且錯誤嘗試次數不超過 20 次，才會要求使用者輸入 PIN 碼、解鎖圖案或密碼。錯誤嘗試次數是指擷取品質良好 (BIOMETRIC_ACQUIRED_GOOD) 但不符合已註冊生物特徵辨識的嘗試次數。
  • [C-SR-4] 如果根據 Android 生物特徵驗證測試規範，偽造和冒用者接受率高於 7%，強烈建議您降低 [C-1-9] 中指定的生物特徵驗證錯誤嘗試次數總數。
  • [C-1-3] 必須針對生物特徵辨識驗證設立速率限制，其中「錯誤嘗試」是指擷取品質足夠 (BIOMETRIC_ACQUIRED_GOOD) 但不符合已註冊生物特徵的情況。
  • [C-SR-5] 強烈建議在生物特徵辨識驗證的五次錯誤嘗試後，至少以 30 秒的間隔限制嘗試次數，以便達到每個 [C-1-9] 的錯誤嘗試次數上限。錯誤嘗試是指擷取品質良好 (BIOMETRIC_ACQUIRED_GOOD) 但不符合已註冊生物特徵的情況。
  • [C-SR-6] 強烈建議將所有速率限制邏輯放在 TEE 中。
  • [C-1-10] 如第 9.11 節的 [C-0-2] 所述，一旦主要驗證功能的回退機制首次觸發，就必須停用生物特徵辨識驗證機制。
  • [C-1-11] 必須符合以下條件：(1) 針對第 A 級呈現攻擊工具 (PAI) 類型，偽造和冒牌接受率不得超過 30%；(2) 針對第 B 級 PAI 類型，偽造和冒牌接受率不得超過 40%，測試方式請參閱 Android 生物辨識測試規範。
  • [C-1-4] 必須先建立信任鏈結，才能新增新的生物特徵辨識系統，方法是要求使用者確認現有或新增的裝置憑證 (PIN 碼/圖形/密碼)，並由 TEE 進行保護；Android 開放原始碼專案實作會在架構中提供相關機制。

Android 15 的新規定上路了

  • [C-1-5] 在使用者帳戶移除 (包括透過恢復原廠設定) 或移除建議的主要驗證方法 (例如 PIN 碼、圖形密碼、密碼) 時，必須完全移除使用者的所有可辨識生物特徵資料。

新規定結束

Android 15 的新規定上路了

  • [C-1-7] 必須每 24 小時或更短時間，要求使用者提供建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。注意：升級搭載 Android 9 以下版本的裝置時，必須每隔 72 小時或更短時間，要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼)。

新規定結束

Android 15 的新規定上路了

  • [C-1-8] 在發生下列任一情況後，您務必要求使用者提供建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)，或第 3 級 (強) 生物特徵辨識驗證：
    • 4 小時的閒置逾時時間，或
    • 生物特徵辨識驗證失敗 3 次。
    • 成功確認裝置憑證後，閒置逾時期間和失敗的驗證計數會重設。注意：搭載 Android 9 以下版本的裝置升級作業可能不受 C-1-8 規範。

新規定結束

  • [C-SR-7] 強烈建議您使用 Android 開放原始碼計畫提供的架構中邏輯，針對新裝置強制執行 [C-1-7] 和 [C-1-8] 中指定的限制。
  • [C-SR-8] 強烈建議錯誤拒絕率低於 10%，且是在裝置上測量。
  • [C-SR-9] 強烈建議每個註冊的生物特徵辨識功能，從偵測到生物特徵到解鎖螢幕的延遲時間應低於 1 秒。
  • [C-1-12] 必須採用 Android 生物辨識測試規範，針對每個呈現攻擊工具 (PAI) 類型，偽造和冒用接受率不得超過 40%。
  • [C-SR-13] 強烈建議您根據 Android 生物特徵辨識測試規範，以每個呈現攻擊工具 (PAI) 類型為單位，將偽造和冒牌接受率控制在 30% 以下。
  • [C-SR-8] 強烈建議錯誤拒絕率低於 10%，且是在裝置上測量。

Android 15 的新規定上路了

  • [C-1-15] 必須允許使用者移除單一或多個生物特徵註冊。

新規定結束

  • [C-SR-14] 強烈建議您揭露生物特徵辨識感應器的生物特徵辨識類別，以及啟用該感應器的相關風險。

  • [C-SR-17] 強烈建議實作新的 AIDL 介面 (例如 IFace.aidl 和 IFingerprint.aidl)。

如果裝置實作項目希望將生物特徵辨識感應器視為 Class 2 (舊稱 Weak)，則應：

  • [C-2-1] 必須符合上述第 1 級的所有規定。
  • [C-2-2] 必須將偽造和冒用者接受率控制在 20% 以下，其中 (1) 針對第 A 級的呈現攻擊工具 (PAI) 類型，偽造和冒用者接受率不得超過 20%；(2) 根據 Android 生物辨識測試規範，第 B 級 PAI 類型的偽造和冒用者接受率不得超過 30%。
  • [C-SR-15] 強烈建議您採用Android 生物辨識測試規範，讓每個呈現攻擊工具 (PAI) 類型的偽造和冒用者接受率不超過 20%。
  • [C-2-3] 必須在 Android 使用者或核心空間以外的隔離執行環境中執行生物特徵比對，例如受信任的執行環境 (TEE)、具有與隔離執行環境安全通道的晶片，或是符合第 9.17 節規定的受保護虛擬機器。
  • [C-2-4] 必須將所有可識別的資料加密並以密碼學方式驗證，以便在隔離執行環境之外，或在 Android 開放原始碼專案網站的實作指南中所述，透過安全通道連線至隔離執行環境的晶片，或由虛擬機器管理程序控制的受保護虛擬機器，無法取得、讀取或變更這些資料。
  • [C-2-5] 針對以攝影機為基礎的生物特徵辨識系統，在進行生物特徵辨識驗證或註冊時：
    • 攝影機必須以一種模式運作，以免攝影機影格在隔離執行環境之外遭到讀取或變更，或是在隔離執行環境中使用安全管道，或是由符合第 9.17 節規定的管理程序控制的受保護虛擬機器。
    • 對於 RGB 單相機解決方案，相機影格可以在隔離執行環境外讀取，以支援註冊預覽等作業，但仍不得變更。
  • [C-2-6] 不得允許第三方應用程式區分個別生物特徵註冊。
  • [C-2-7] 不得允許應用程式處理器在 TEE 或符合第 9.17 節規定的管理程序所控的 Protected Virtual Machine 之外的環境中，對可識別的生物特徵辨識資料或任何衍生自該資料的資料 (例如嵌入資料) 進行未加密存取。升級搭載 Android 9 以下版本的裝置，不受 C-2-7 規範。

  • [C-2-8] 必須具備安全的處理管道，以免在作業系統或核心遭到入侵時，無法直接插入資料，以便偽造使用者驗證。注意：如果裝置實作項目已在 Android 9 以下版本推出，且無法透過系統軟體更新符合 C-2-8 規定，則可能不受此規定約束。

  • [C-SR-10] 強烈建議您為所有生物特徵辨識模式加入活體偵測功能，並為臉部生物特徵辨識功能加入注意力偵測功能。

  • [C-2-9] 必須讓第三方應用程式存取生物辨識感應器。

如果裝置實作項目希望將生物特徵辨識感應器視為 Class 3 (舊稱 Strong)，則應：

  • [C-3-1] 必須符合上述第 2 級的所有規定，但 [C-1-7] 和 [C-1-8] 除外。
  • [C-3-2] 必須實作硬體支援的 KeyStore。
  • [C-3-3] 必須讓偽造和冒用接受率不超過 7%，其中 (1) 針對第 A 級的呈現攻擊工具 (PAI) 類型，偽造和冒用接受率不超過 7%，以及 (2) 針對第 B 級的 PAI 類型，偽造和冒用接受率不超過 20%，測試方式請參閱 Android 生物辨識測試規範。
  • [C-3-4] 每隔 72 小時或更短時間，就必須向使用者提出建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 驗證要求。
  • [C-3-5] 如果裝置支援的所有第 3 級生物辨識系統重新註冊，則必須重新產生驗證器 ID。
  • [C-3-6] 必須為第三方應用程式啟用生物辨識支援的 KeyStore 金鑰。

  • [C-SR-16] 強烈建議您採用每個呈現攻擊工具 (PAI) 類型 7% 以下的偽造和冒用者接受率，這項測試結果是根據 Android 生物辨識測試規範所得。

如果裝置實作包含螢幕下指紋感應器 (UDFPS)，則會：

  • [C-SR-11] 強烈建議您避免 UDFPS 的觸控區域干擾 3 鍵導覽 (部分使用者可能會為了無障礙功能而需要使用 3 鍵導覽)。

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] 必須回報硬體功能旗標 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.4. 資料連線

7.4.1. 電話通訊系統

Android API 和本文件所使用的「Telephony」一詞，專指與撥打語音通話和傳送簡訊，或透過行動網路 (例如 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 Multimedia Subsystem (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] 必須能夠依照 ETSI TS 102 221 為每個 UICC 開啟並同時使用最多的邏輯通道數量 (總計 20 個)。
  • [C-6-8] 請勿自動或未經使用者明確確認，將下列任何行為套用至有效的電信業者應用程式 (由 TelephonyManager#getCarrierServicePackageName 指定)：
    • 撤銷或限制網路存取權
    • 撤銷權限
    • 除了 AOSP 中現有的電源管理功能外，限制背景或前景應用程式執行作業
    • 停用或解除安裝應用程式

如果裝置實作項目回報 android.hardware.telephony 功能，且所有共用群組 UUID 的活動、非隨機訂閱項目已停用、從裝置中實際移除，或標示為隨機，則裝置會：

  • [C-8-1] 必須自動停用同一個群組中所有仍有效的隨機訂閱項目。

如果裝置實作包含 GSM 電話通訊，但不包含 CDMA 電話通訊，則會發生以下情況：

如果裝置實作項目支援多個通訊埠和設定檔的 eUICC，則會：

7.4.1.1. 號碼封鎖相容性

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

  • [C-1-1] 必須支援號碼封鎖功能
  • [C-1-2] 必須依照 SDK 說明文件的說明，完整實作 BlockedNumberContract 和對應的 API。

  • [C-1-3] 必須在 BlockedNumberProvider 中封鎖某個電話號碼的所有通話和訊息，且不得與應用程式互動。唯一的例外狀況是，如 SDK 說明文件所述，系統暫時解除號碼封鎖。

  • [C-1-4] 必須針對遭封鎖的通話寫入平台通話記錄提供者，並且必須從預先安裝的撥號應用程式中預設的通話記錄檢視畫面中，篩除使用 BLOCKED_TYPE 的通話。

  • [C-1-5] 不得針對已封鎖的訊息寫入電話供應商。

  • [C-1-6] 必須實作封鎖號碼管理 UI，並使用 TelecomManager.createManageBlockedNumbersIntent() 方法傳回的意圖開啟該 UI。

  • [C-1-7] 絕對不允許次要使用者查看或編輯裝置上的封鎖號碼，因為 Android 平台會假設主要使用者可完全控制裝置上的電話服務 (單一例項)。所有與封鎖相關的使用者介面都必須隱藏給次要使用者，且封鎖清單仍必須受到尊重。

  • 裝置更新至 Android 7.0 時，應將封鎖的號碼遷移至供應商。

  • 應提供使用者操作提示，在預先安裝的撥號應用程式中顯示已封鎖的通話。

7.4.1.2. Telecom API

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

  • [C-1-1] 必須支援 SDK 中所述的 ConnectionService API。
  • [C-1-2] 當使用者正在使用第三方應用程式進行通話 (該應用程式不支援透過 CAPABILITY_SUPPORT_HOLD 指定的保留功能) 時，必須顯示新的來電，並提供使用者接受或拒絕來電的操作選項。
  • [C-1-3] 應用程式必須實作 InCallService。

  • [C-SR-1] 強烈建議您通知使用者，接聽來電會導致正在進行的通話中斷。

    AOSP 實作項目會透過提示通知來滿足這些需求，向使用者指出接聽來電會導致其他通話中斷。

  • [C-SR-2] 強烈建議您預先載入預設撥號應用程式，以便在第三方應用程式將 EXTRA_LOG_SELF_MANAGED_CALLS 額外鍵設為 PhoneAccount 的 true 時，在其通話記錄中顯示通話記錄項目和第三方應用程式的名稱。

  • [C-SR-3] 強烈建議您處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，以便支援 android.telecom API，如下所示：

7.4.1.3. 行動網路 NAT-T 保持連線卸載

裝置實作方式：

  • 應支援行動網路保持連線功能。

如果裝置實作內容支援行動網路保持連線功能卸載，並將這項功能公開給第三方應用程式，則會發生以下情況：

  • [C-1-1] 必須支援 SocketKeepAlive API。
  • [C-1-2] 必須透過行動網路支援至少一個並行的保活連線時段。
  • [C-1-3] 必須支援與 Cellular Radio HAL 支援的相同數量的並行行動網路保持連線時段。
  • [C-SR-1] 強烈建議每個無線電執行個體至少支援三個行動網路保持連線時段。

如果裝置實作不支援行動網路保持連線卸載功能，則會發生以下情況：

  • [C-2-1] 必須傳回 ERROR_UNSUPPORTED。

7.4.2. IEEE 802.11 (Wi-Fi)

裝置實作方式：

  • 應支援一或多種 802.11 形式。

如果裝置實作內容支援 802.11，並將功能公開給第三方應用程式，則會發生以下情況：

  • [C-1-1] 必須實作對應的 Android API。
  • [C-1-2] 必須回報硬體功能旗標 android.hardware.wifi。
  • [C-1-3] 必須按照 SDK 說明文件所述，實作多播 API。

Android 15 的新規定上路了

  • [C-1-4] 必須支援多點傳送 DNS (mDNS)，且不得在任何運作期間 (包括螢幕處於非活動狀態時) 過濾 mDNS 封包 (224.0.0.251 或 ff02::fb)，除非為了符合目標市場適用的監管規定，而必須捨棄或過濾這些封包，才能維持在所需的耗電範圍內。

  • [C-1-4] 必須支援 mDNS，且不得在任何運作期間過濾 mDNS 封包 (224.0.0.251 或 ff02::fb)，包括螢幕處於非活動狀態時，除非多點傳送鎖定未保持，且封包已由 APF 過濾。這些封包不必滿足應用程式目前透過 NsdManager API 要求的任何 mDNS 作業。不過，如果為了符合目標市場適用的管制規定，而需要在電力消耗範圍內，裝置可能會篩選 mDNS 封包。

新規定結束

  • [C-1-5] 請勿將 WifiManager.enableNetwork() API 方法呼叫視為切換目前有效 Network 的充分指標。Network 預設用於應用程式流量，並由 ConnectivityManager API 方法 (例如 getActiveNetwork 和 registerDefaultNetworkCallback) 傳回。換句話說，只有在成功驗證 Wi-Fi 網路提供網際網路存取權時，他們才可能停用任何其他網路供應商 (例如行動數據) 提供的網際網路存取權。
  • [C-1-6] 強烈建議您在呼叫 ConnectivityManager.reportNetworkConnectivity() API 方法時，重新評估 Network 的網際網路存取權，並在評估結果判定目前 Network 不再提供網際網路存取權後，切換至任何可提供網際網路存取權的可用網路 (例如行動數據)。
  • [C-1-7] 必須在 STA 未連線時，在每次掃描開始時隨機產生探測要求資料框的來源 MAC 位址和序號。
  • [C-1-8] 必須使用一個一致的 MAC 位址 (在掃描過程中，不應隨機產生 MAC 位址)。
  • [C-1-9] 必須在掃描中，以正常 (依序) 方式在探測要求之間重複探測要求序號。
  • [C-1-10] 必須在掃描的最後一個探測要求和下一個掃描的首個探測要求之間，隨機產生探測要求序號。
  • [C-SR-1] 強烈建議在建立和建立連線時，將用於所有 STA 與存取點 (AP) 通訊的來源 MAC 位址隨機化。
    • 裝置必須為每個與其通訊的 SSID (Passpoint 的 FQDN) 使用不同的隨機 MAC 位址。
    • 裝置必須為使用者提供選項，以便透過非隨機和隨機選項控制每個 SSID (Passpoint 的 FQDN) 的隨機化，且必須將新 Wi-Fi 設定的預設模式設為隨機化。
  • [C-SR-2] 強烈建議為所建立的任何無線基地台使用隨機 BSSID。
    • MAC 位址必須隨機產生，並依據 AP 使用的 SSID 保留。
    • 裝置可能會提供使用者停用這項功能的選項。如果提供此選項，則必須預設啟用隨機化。

如果裝置實作內容支援 Wi-Fi 省電模式 (如 IEEE 802.11 標準所定義)，則必須符合下列條件：

  • 應用程式透過 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() API 取得 WIFI_MODE_FULL_HIGH_PERF 鎖定或 WIFI_MODE_FULL_LOW_LATENCY 鎖定，且鎖定狀態為有效時，應關閉 Wi-Fi 省電模式。
  • [C-3-2] 裝置處於 Wi-Fi 低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 模式時，裝置與存取點之間的平均來回延遲時間，必須小於 Wi-Fi 高效能鎖定 (WIFI_MODE_FULL_HIGH_PERF) 模式的延遲時間。
  • [C-SR-3] 強烈建議您在取得並啟用低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 時，盡量減少 Wi-Fi 往返延遲時間。

如果裝置實作支援 Wi-Fi，並使用 Wi-Fi 進行位置掃描，則：

7.4.2.1. Wi-Fi Direct

裝置實作方式：

  • 應支援 Wi-Fi Direct (Wi-Fi 點對點)。

如果裝置實作方式支援 Wi-Fi Direct，則必須符合下列條件：

  • [C-1-1] 必須實作 SDK 說明文件中所述的對應 Android API。
  • [C-1-2] 必須回報硬體功能 android.hardware.wifi.direct。
  • [C-1-3] 必須支援一般 Wi-Fi 作業。
  • [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。
  • [C-SR-1] 強烈建議您為所有新建立的 Wi-Fi Direct 連線隨機產生來源 MAC 位址。

裝置實作方式：

如果裝置實作內容支援 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] 必須在 Wi-Fi Aware 管理介面地址的間隔不超過 30 分鐘，以及啟用 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)，則會：

  • [C-1-1] 必須支援 Wi-Fi Passpoint。
  • [C-1-2] 必須按照 SDK 說明文件所述，實作與 Passpoint 相關的 WifiManager API。
  • [C-1-3] 必須支援 IEEE 802.11u 標準，特別是與網路探索和選取相關的標準，例如通用廣告服務 (GAS) 和存取網路查詢通訊協定 (ANQP)。
  • [C-1-4] 必須宣告 android.hardware.wifi.passpoint 功能旗標。
  • [C-1-5] 必須遵循 AOSP 實作方式，才能探索、比對及連結至 Passpoint 網路。
  • [C-1-6] 必須支援以下至少部分的裝置佈建通訊協定，如 Wi-Fi Alliance Passpoint R2 所定義：EAP-TTLS 驗證和 SOAP-XML。
  • [C-1-7] 必須依照 Hotspot 2.0 R3 規格處理 AAA 伺服器憑證。
  • [C-1-8] 必須支援使用者透過 Wi-Fi 挑選工具控管裝置設定。
  • [C-1-9] 必須在重新啟動後保留熱點設定。
  • [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 突發事件的來源 MAC 位址，執行 RTT 的 Wi-Fi 介面未與存取點建立關聯時，就會執行這項作業。
  • [C-1-4] 在 80 MHz 頻寬下，必須在第 68 百分位 (使用累積分配函式計算) 以內達到 2 公尺的精確度。
  • [C-SR-1] 強烈建議在 80 MHz 頻寬的 68 百分位數 (使用累積分佈函式計算) 內，準確回報距離為 1.5 公尺以內。
7.4.2.6。Wi-Fi 保持連線卸載

裝置實作方式：

  • 應支援 Wi-Fi keepalive 卸載功能。

如果裝置實作內容支援 Wi-Fi keepalive 卸載功能，並將這項功能公開給第三方應用程式，則：

  • [C-1-1] 必須支援 SocketKeepAlive API。
  • [C-1-2] 必須支援至少三個透過 Wi-Fi 的同時保持連線時段

如果裝置實作不支援 Wi-Fi keepalive 卸載功能，則會發生以下情況：

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] 必須提供使用者選項，讓他們選擇使用 TOFU。

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 (通用屬性設定檔) 的 Bluetooth API，如 SDK 說明文件和 android.bluetooth 所述。
  • [C-3-3] 必須回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，以指出是否已實作 ScanFilter API 類別的篩選邏輯。
  • [C-3-4] 必須回報正確的 BluetoothAdapter.isMultipleAdvertisementSupported() 值，以指出是否支援低耗能廣告。

  • [C-3-5] 必須實作可解析私人位址 (RPA) 逾時機制，逾時時間不得超過 15 分鐘，並在逾時時輪替位址，以便在裝置積極使用 BLE 進行掃描或廣告時保護使用者隱私。為避免時間攻擊，逾時間隔也必須隨機化，介於 5 到 15 分鐘之間。

  • 實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。

  • 應支援將批次掃描作業卸載至藍牙晶片組。

  • 應支援至少 4 個廣告位子的多個廣告。

如果裝置實作支援藍牙 LE，並使用藍牙 LE 進行位置掃描，則會：

  • [C-4-1] 必須提供使用者操作提示，以便啟用/停用透過系統 API BluetoothAdapter.isBleScanAlwaysAvailable() 讀取的值。

如果裝置實作內容支援藍牙 LE 和助聽器設定檔，則會符合下列條件：使用藍牙 LE 支援助聽器音訊

如果裝置實作項目支援藍牙或藍牙低功耗，則必須符合下列條件：

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

如果裝置實作項目支援藍牙或藍牙低功耗，且應用程式資訊清單未包含開發人員的聲明，表示他們不會從藍牙擷取位置資訊，則他們：

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

  • [C-7-1] 必須支援單播用戶端。
  • [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] 必須支援 BIG 中的至少 2 個 BIS 連結。
  • [C-8-2] 必須同時啟用 BAP 廣播來源和 BAP 廣播助理。
  • [C-8-3] 必須支援 LE 定期廣告。

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

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

如果裝置實作宣告 FEATURE_BLUETOOTH_LE，則會執行以下操作：

  • [C-10-1] 必須在 ADVERTISE_TX_POWER_HIGH 的視線環境中，以 1 公尺的距離測量參考裝置傳輸的 RSSI 值，其中 95% 的測量值必須在 +/-9dB 範圍內。
  • [C-10-2] 必須納入 Rx/Tx 修正值，以減少各個頻道的偏差，讓 3 個頻道上每個天線 (如果使用多個天線) 的測量值，在 95% 的測量值中保持在 +/-3dB 的範圍內。
  • [C-SR-2] 強烈建議您測量並補償 Rx 偏移，確保 BLE RSSI 中位數為 -60dBm +/-10 dB，且距離傳送 ADVERTISE_TX_POWER_HIGH 的參考裝置 1 公尺，且裝置方向為「平行平面」，螢幕朝向相同方向。
  • [C-SR-3] 強烈建議您測量並補償 Tx 偏移，以確保從位於 1 公尺距離的參考裝置掃描，並以 ADVERTISE_TX_POWER_HIGH 傳輸時，中位 BLE RSSI 為 -60dBm +/-10 dB，其中裝置方向為「平行平面」，螢幕朝向相同方向。

強烈建議您按照「觀看行為校正需求」一文中指定的評估設定步驟操作。

7.4.4. 近距離無線通訊

裝置實作方式：

  • 應包含近距離無線通訊 (NFC) 的收發器和相關硬體。
  • [C-0-1] 必須實作 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，即使這些 API 不支援 NFC 或宣告 android.hardware.nfc 功能，也必須實作，因為這些類別代表與通訊協定無關的資料表示格式。

如果裝置實作內容包含 NFC 硬體，且打算將其提供給第三方應用程式，則應：

  • [C-1-1] 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
  • 必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：
  • [C-1-2] 必須能夠透過下列 NFC 標準，充當 NFC Forum 讀取器/寫入器 (依 NFC Forum 技術規格 NFCForum-TS-DigitalProtocol-1.0 定義)：
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC Forum 標記類型 1、2、3、4、5 (由 NFC Forum 定義)

  • [C-SR-1] 強烈建議您能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息和原始資料。請注意，雖然 NFC 標準的規定為「強烈建議」，但日後的版本相容性定義預計會將這些規定改為「必須」。這些標準在本版本中為選用標準，但在日後的版本中將為必用標準。強烈建議執行此 Android 版本的現有裝置和新裝置，現在就符合這些要求，以便日後升級至平台的後續版本。

  • [C-1-13] 在 NFC 探索模式下，必須輪詢所有支援的技術。

  • 裝置喚醒時，螢幕處於開啟狀態，且鎖定螢幕已解鎖，應處於 NFC 探索模式。

  • 應能讀取 Thinfilm NFC Barcode 產品的條碼和網址 (如果已編碼)。

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

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

如果裝置實作項目包含可支援 HCE (適用於 NfcA 和/或 NfcB) 的 NFC 控制器晶片組，並且支援應用程式 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] 必須按照 Android SDK 說明文件導入對應的 Android API。
  • [C-4-2] 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這不是標準的 Android 功能，因此不會在 android.content.pm.PackageManager 類別中顯示為常數。

7.4.5. 網路通訊協定和 API

7.4.5.1. 最低網路功能

裝置實作方式：

  • [C-0-1] 必須支援一或多種資料網路連線。具體來說，裝置實作必須支援至少一種資料標準，且該標準的傳輸速率必須達到 200 Kbit/秒或更高。滿足這項規定的技術包括 EDGE、HSPA、EV-DO、802.11g、乙太網路和藍牙 PAN。
  • 當實體網路標準 (例如乙太網路) 是主要資料連線時，也應支援至少一種常見的無線資料標準，例如 802.11 (Wi-Fi)。
  • 可實作多種資料連結方式。
7.4.5.2. IPv6

裝置實作方式：

  • [C-0-2] 必須包含 IPv6 網路堆疊，並支援使用受管理 API (例如 java.net.Socket 和 java.net.URLConnection) 以及原生 API (例如 AF_INET6 網路介面) 的 IPv6 通訊。
  • [C-0-3] 必須預設啟用 IPv6。
    • 必須確保 IPv6 通訊的可靠性與 IPv4 相同，例如：
      • [C-0-4] 必須在休眠模式下維持 IPv6 連線。
      • [C-0-5] 在使用 RA 生命週期至少 180 秒的任何符合 IPv6 規範的網路上，速率限制絕對不會導致裝置失去 IPv6 連線。
  • [C-0-6] 連線至 IPv6 網路時，必須為第三方應用程式提供直接的 IPv6 網路連線，且不得在裝置上發生任何形式的位址或連接埠轉譯。受管理的 API (例如 Socket#getLocalAddress 或 Socket#getLocalPort) 和 NDK API (例如 getsockname() 或 IPV6_PKTINFO) 都必須傳回實際用於在網路上傳送及接收封包的 IP 位址和連接埠，並顯示為網際網路 (網頁) 伺服器的來源 IP 和連接埠。

所需的 IPv6 支援層級取決於網路類型，如以下規定所示。

如果裝置實作支援 Wi-Fi，則必須符合下列條件：

  • [C-1-1] 必須支援 Wi-Fi 上的雙重堆疊和僅限 IPv6 作業。

如果裝置實作方式支援乙太網路，則必須符合下列條件：

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

如果裝置實作項目支援行動數據，則必須符合下列條件：

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

如果裝置實作項目支援多種網路類型 (例如Wi-Fi 和行動數據) 時，會發生以下情況：

  • [C-4-1] 當裝置同時連線至多種網路類型時，必須同時符合上述每個網路的要求。
7.4.5.3. 網頁認證入口

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

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

  • [C-1-1] 必須提供網頁認證入口應用程式，以便在呼叫系統 API ConnectivityManager#startCaptivePortalApp(Network, Bundle) 時傳送意圖 ACTION_CAPTIVE_PORTAL_SIGN_IN，並顯示網頁認證入口登入頁面。
  • [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，則應移除該位置資訊。

如果裝置實作支援 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. 後置鏡頭

後置鏡頭是朝向外面的鏡頭，可拍攝裝置遠端的場景，就像傳統相機一樣；在手持裝置上，後置鏡頭位於裝置螢幕對側。

裝置實作方式：

  • 應包含後置鏡頭。

如果裝置實作包含至少一個後置鏡頭，則必須符合下列條件：

  • [C-1-1] 必須回報功能旗標 android.hardware.camera 和 android.hardware.camera.any。
  • [C-1-2] 解析度必須至少為 2000 萬像素。
  • 應在相機驅動程式中實作硬體自動對焦或軟體自動對焦功能 (對應用程式軟體而言是透明的)。
  • 可能會配備固定焦或 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 裝置實作項目必須確保 API 持續支援，如本節和 Android SDK 所述。

淘汰的 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 時，byte[] 中的資料必須進一步採用 NV21 編碼格式，才能傳遞至 onPreviewFrame()。也就是說，預設值必須是 NV21。
  • [C-0-3] 必須支援 YV12 格式 (由 android.graphics.ImageFormat.YV12 常數表示)，用於 android.hardware.Camera 的前置鏡頭和後置鏡頭預覽畫面。(硬體影片編碼器和相機可以使用任何原生像素格式，但裝置實作方式必須支援轉換為 YV12)。
  • [C-0-4] 必須支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式，做為透過 android.media.ImageReader API 輸出的內容，適用於在 android.request.availableCapabilities 中宣告 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能的 android.hardware.camera2 裝置。
  • [C-0-5] 無論裝置是否包含硬體自動對焦或其他功能，都必須實作 Android SDK 說明文件中提供的完整 Camera API。舉例來說，缺少自動對焦功能的相機仍必須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 例項 (即使這與非自動對焦相機無關)。請注意，這也適用於前置鏡頭。舉例來說，即使大多數前置鏡頭不支援自動對焦，API 回呼仍必須如上所述「偽造」。
  • [C-0-6] 必須辨識並尊重在 android.hardware.Camera.Parameters 類別和 android.hardware.camera2.CaptureRequest 類別中定義為常數的每個參數名稱。相反地，除了 android.hardware.Camera.Parameters 上記錄為常數的字串常數之外，裝置實作不得承認或辨識傳遞至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作必須支援所有標準相機參數，且不得支援自訂相機參數類型。舉例來說，如果裝置實作支援使用高動態範圍 (HDR) 成像技術擷取圖片，就必須支援相機參數 Camera.SCENE_MODE_HDR。
  • [C-0-7] 必須使用 android.info.supportedHardwareLevel 屬性，依 Android SDK 說明回報適當的支援層級，並回報適當的架構功能旗標。
  • [C-0-8] 必須透過 android.request.availableCapabilities 屬性宣告 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標；如果任何已連結的相機裝置支援該功能，則必須定義功能旗標。
  • [C-0-9] 相機拍攝新相片並將相片項目新增至媒體儲存空間時，必須廣播 Camera.ACTION_NEW_PICTURE 意圖。
  • [C-0-10] 相機錄製新影片，且圖片項目已新增至媒體儲存庫時，必須廣播 Camera.ACTION_NEW_VIDEO 意圖。
  • [C-0-11] 必須透過已淘汰的 android.hardware.Camera API 存取所有相機，也必須透過 android.hardware.camera2 API 存取。
  • [C-0-12] 請務必確保臉部外觀不會遭到變更，包括但不限於變更任何 android.hardware.camera2 或 android.hardware.Camera API 的臉部幾何形狀、臉部膚色或臉部皮膚光滑度。
  • [C-SR-1] 如果裝置有數個 RGB 攝影機，且彼此相距很近且朝向相同方向，強烈建議您支援列出 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 功能的邏輯相機裝置，其中包含朝向該方向的所有 RGB 攝影機，做為實體子裝置。

如果裝置實作為第三方應用程式提供專屬相機 API，則會發生以下情況：

7.5.5. 相機方向

如果裝置實作有前置或後置鏡頭，則該鏡頭：

  • [C-1-1] 相機的長邊必須與螢幕的長邊對齊。也就是說，當裝置以橫向方向握持時，相機就必須以橫向方向拍攝圖片。無論裝置的自然方向為何，這項設定都適用，也就是適用於以橫向為主要方向的裝置，以及以直向為主要方向的裝置。

符合下列所有條件的裝置不受上述規定約束：

  • 裝置會實作可變幾何學螢幕，例如可折疊或可摺疊的螢幕。
  • 當裝置的折疊或鉸接處狀態變更時，裝置會在直向優先和橫向優先 (或反之) 之間切換方向。
  • 使用者無法旋轉的裝置實作方式，例如車用裝置。

7.6. 記憶體與儲存空間

7.6.1. 記憶體和儲存空間需求

裝置實作方式：

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

7.6.2. 應用程式共用儲存空間

裝置實作方式：

  • [C-0-1] 應用程式必須提供可共用的儲存空間，這類儲存空間也經常被稱為「共用外部儲存空間」、「應用程式共用儲存空間」或掛載於 Linux 路徑「/sdcard」的儲存空間。
  • [C-0-2] 必須使用預設的共用儲存空間掛載方式進行設定，也就是「開箱即用」方式，無論儲存空間是實作在內部儲存空間元件上，還是可移除的儲存媒體 (例如安全數位卡插槽)。
  • [C-0-3] 必須將應用程式共用儲存空間直接掛載至 Linux 路徑 sdcard，或加入從 sdcard 到實際掛載點的 Linux 符號連結。
  • [C-0-4] 針對指定 API 級別 29 以上版本的所有應用程式，必須預設啟用範圍限定儲存空間，但在下列情況下除外：
    • 應用程式在資訊清單中要求 android:requestLegacyExternalStorage="true" 時。
  • [C-0-5] 必須在透過 MediaStore 存取媒體檔案時，遮蓋儲存在媒體檔案中的地點中繼資料 (例如 GPS Exif 標記)，除非呼叫端應用程式擁有 ACCESS_MEDIA_LOCATION 權限。

裝置實作項目可使用下列任一項功能來滿足上述要求：

  • 使用者可存取的可卸除式儲存空間，例如 Secure Digital (SD) 卡插槽。
  • 在 Android 開放原始碼計畫 (AOSP) 中實作的內部 (不可移除) 儲存空間。

如果裝置實作使用可移除式儲存空間來滿足上述要求，則必須符合下列條件：

  • [C-1-1] 必須實作 Toast 或彈出式使用者介面，在插槽中未插入任何儲存媒體時警告使用者。
  • [C-1-2] 必須隨附 FAT 格式的儲存媒體 (例如 SD 卡)，或在盒裝和其他購買時提供的資料中顯示，指出儲存媒體須另外購買。

如果裝置實作項目使用非可移除儲存空間的一部分來滿足上述需求，則必須符合以下條件：

  • 應使用內部應用程式共用儲存空間的 AOSP 實作項目。
  • 可與應用程式私人資料共用儲存空間。

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，則該裝置會：

  • [C-3-1] 必須提供機制，以便從主機電腦存取應用程式共用儲存空間中的資料。
  • 應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，公開儲存路徑中的內容。
  • 可使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定來滿足這項規定。

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，且支援媒體傳輸通訊協定，則會：

  • 應與 Android MTP 參考主機 Android 檔案傳輸 相容。
  • 應回報 0x00 的 USB 裝置類別。
  • 應回報的 USB 介面名稱為「MTP」。

7.6.3. 合併儲存空間

如果裝置的本質是行動裝置 (不像電視)，則裝置實作方式如下：

  • [C-SR-1] 強烈建議在長期穩定的位置實作可採用的儲存空間，因為不小心中斷連線可能會導致資料遺失/損毀。

如果可拆卸式儲存裝置連接埠位於長期穩定的位置 (例如電池隔間或其他保護蓋內)，裝置實作方式如下：

7.7. USB

如果裝置實作有 USB 連接埠，則必須符合下列條件：

  • 應支援 USB 周邊裝置模式，並應支援 USB 主機模式。
  • 應支援透過 USB 停用資料訊號。

7.7.1. USB 周邊裝置模式

如果裝置實作包含支援周邊模式的 USB 連接埠，請執行下列操作：

  • [C-1-1] 連接埠必須可連接至具有標準 Type-A 或 Type-C USB 連接埠的 USB 主機。
  • [C-1-2] 必須透過 android.os.Build.SERIAL 回報 USB 標準裝置描述元中的正確 iSerialNumber 值。
  • [C-1-3] 必須根據 Type-C 電阻標準偵測 1.5A 和 3.0A 充電器，且必須偵測廣告中的變更 (如果廣告支援 Type-C USB)。
  • [C-SR-1] 連接埠應使用 micro-B、micro-AB 或 Type-C USB 板型規格。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
  • [C-SR-2] 裝置的連接埠應位於裝置底部 (依照自然方向)，或為所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，以便在裝置以連接埠朝下的方式擺放時，正確顯示畫面。我們強烈建議現有和新款 Android 裝置符合這些需求，以便升級至日後的平台版本。
  • [C-SR-3] 應實作支援功能，以便在 HS 嗶嗶聲和流量期間汲取 1.5 A 電流，如 USB 電池充電規格第 1.2 版所述。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
  • [C-SR-4] 強烈建議不要支援會修改 Vbus 電壓超過預設等級的專屬充電方法，或變更匯流/來源角色，因為這可能會導致與支援標準 USB 電源供應方法的充電器或裝置發生互通性問題。雖然這項做法被列為「強烈建議」，但在日後的 Android 版本中，我們可能會要求所有 Type-C 裝置支援與標準 Type-C 充電器的完整互通性。
  • [C-SR-5] 強烈建議在支援 Type-C USB 和 USB 主機模式時，支援資料和電源角色交換的 Power Delivery。
  • 應支援高電壓充電的 Power Delivery，並支援顯示輸出等其他模式。
  • 應按照 Android SDK 說明文件中所述，實作 Android Open Accessory (AOA) API 和規格。

如果裝置實作包含 USB 連接埠並實作 AOA 規格，則會：

  • [C-2-1] 必須宣告對硬體功能 android.hardware.usb.accessory 的支援。
  • [C-2-2] USB 大量儲存空間類別必須在 USB 大量儲存空間的介面說明 iInterface 字串結尾處加入「android」字串

7.7.2. USB 主機模式

如果裝置實作項目包含支援主機模式的 USB 連接埠，則會執行以下操作：

  • [C-1-1] 必須按照 Android SDK 中的說明文件實作 Android USB 主機 API，並且必須宣告支援硬體功能 android.hardware.usb.host。
  • [C-1-2] 必須支援連接標準 USB 周邊裝置，也就是說，必須符合下列任一條件：
    • 裝置上有 Type-C 連接埠，或隨附的傳輸線可將裝置上的專屬連接埠轉換為標準 USB Type-C 連接埠 (USB Type-C 裝置)。
    • 裝置上有 A 型連接埠，或隨附的傳輸線可將裝置上的專屬連接埠轉換為標準 USB A 型連接埠。
    • 裝置上有 micro-AB 連接埠，且應隨附可轉換為標準 A 型連接埠的傳輸線。
  • [C-1-3] 不得隨附從 USB Type A 或 micro-AB 連接埠轉換至 Type C 連接埠 (接收器) 的轉接器。
  • [C-SR-1] 強烈建議您按照 Android SDK 說明文件中所述，實作 USB 音訊類別。
  • 應支援在主機模式下為已連結的 USB 周邊裝置充電；宣傳的來源電流至少為 1.5A，如 USB Type-C 電纜和連接器規格第 1.2 版中所述，適用於 USB Type-C 連接器；或使用充電下游連接埠 (CDP) 輸出電流範圍，如 USB 電池充電規格第 1.2 版中所述，適用於 Micro-AB 連接器。
  • 應實作並支援 USB Type-C 標準。

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

  • [C-2-1] 必須支援 USB HID 類別。
  • [C-2-2] 必須支援偵測及對應下列 HID 資料欄位，這些欄位已在 USB 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

如果裝置實作項目包含支援主機模式和 Storage Access Framework (SAF) 的 USB 連接埠，則會執行以下操作：

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

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

  • [C-4-1] 必須實作 USB Type-C 規格 (第 4.5.1.3.3 節) 所定義的雙角色連接埠功能。對於雙角色連接埠，在配備 3.5 毫米耳機插孔的裝置上，USB Sink 偵測 (主機模式) 可能會預設為關閉，但使用者必須能夠啟用這項功能。
  • [C-SR-2] 強烈建議支援 DisplayPort，應支援 USB 超高速資料傳輸率，並強烈建議支援 Power Delivery，以便切換資料和電源角色。
  • [C-SR-3] 強烈建議不要支援音訊轉接器配件模式，如 USB Type-C 傳輸線和連接器規格第 1.2 版的附錄 A 所述。
  • 應實作最適合裝置板型規格的 Try.* 模型。舉例來說，手持裝置應實作 Try.SNK 模型。

7.8. 音訊

7.8.1. 麥克風

如果裝置實作包含麥克風，則必須符合下列條件：

  • [C-1-1] 必須回報 android.hardware.microphone 地圖項目常數。
  • [C-1-2] 必須符合第 5.4 節的音訊錄音規定。
  • [C-1-3] 必須符合第 5.6 節的音訊延遲要求。
  • [C-SR-1] 強烈建議支援近超音錄影功能，如第 7.8.3 節所述。

如果裝置實作方式省略麥克風，則會發生以下情況：

  • [C-2-1] 請勿回報 android.hardware.microphone 功能常數。
  • [C-2-2] 必須依據第 7 節，至少以無作業方式實作音訊錄製 API。

7.8.2. 音訊輸出裝置

如果裝置實作包含音訊輸出周邊裝置 (例如 4 導體 3.5 公釐耳機插孔) 的音箱或音訊/多媒體輸出連接埠，或是使用 USB 音訊類別的 USB 主機模式連接埠，則應符合下列條件：

  • [C-1-1] 必須回報 android.hardware.audio.output 地圖項目常數。
  • [C-1-2] 必須符合第 5.5 節的音訊播放規定。
  • [C-1-3] 必須符合第 5.6 節的音訊延遲要求。
  • [C-SR-1] 強烈建議您支援近超音播放功能，如第 7.8.3 節所述。

如果裝置實作不包含音箱或音訊輸出埠，則會發生以下情況：

  • [C-2-1] 請勿回報 android.hardware.audio.output 功能。
  • [C-2-2] 必須至少將音訊輸出相關 API 實作為無作業。

在本節中，「輸出端口」是指實體介面，例如 3.5 公釐音訊插孔、HDMI 或 USB 主機模式端口 (含 USB 音訊類別)。透過藍牙、Wi-Fi 或行動網路等無線通訊協定支援音訊輸出，不符合「輸出埠」的資格。

7.8.2.1. 類比音訊埠

為了與 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] 插頭插入時，必須觸發 ACTION_HEADSET_PLUG，但只有在插頭上的所有接點都接觸到插座上的相關區段時才會觸發。
  • [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] 必須支援偵測已插入的音訊配件麥克風。
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 的頻率範圍內，以 -26 dBFS 的 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 的「自動錯誤測試」功能進行測試。

這項測試需要音訊迴路轉接器，可直接插入 3.5 公釐耳機插孔，和/或搭配 USB-C 轉 3.5 公釐轉接器使用。應測試所有音訊輸出埠。

OboeTester 目前支援 AAudio 路徑，因此應使用 AAudio 測試下列組合是否有異常：

效能模式 分享 輸出取樣率 在 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

可靠的串流應符合下列條件，以便針對 2000 Hz 正弦訊號，測量訊號雜訊比 (SNR) 和總諧波失真 (THD)。

換能器 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 支援VR 模式，這項功能可處理通知的立體渲染，並在 VR 應用程式獲得使用者焦點時停用單眼系統 UI 元件。

7.9.2. 虛擬實境模式 - 高效能

如果裝置實作支援 VR 模式，則會：

  • [C-1-1] 至少須有 2 個實體核心。
  • [C-1-2] 必須宣告 android.hardware.vr.high_performance 功能。
  • [C-1-3] 必須支援持續效能模式。
  • [C-1-4] 必須支援 OpenGL ES 3.2。
  • [C-1-5] 必須支援 android.hardware.vulkan.level 0。
  • 應支援 android.hardware.vulkan.level 1 以上版本。
  • [C-1-6] 必須實作 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content、EGL_EXT_image_gl_colorspace，並在可用的 EGL 擴充功能清單中公開這些擴充功能。
  • [C-1-8] 必須實作 GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2 和 GL_EXT_protected_textures，並在可用的 GL 擴充功能清單中公開這些擴充功能。
  • [C-SR-1] 強烈建議實作 GL_EXT_external_buffer、GL_EXT_EGL_image_array 和 GL_OVR_multiview_multisampled_render_to_texture，並在可用的 GL 擴充功能清單中公開這些擴充功能。
  • [C-SR-2] 強烈建議支援 Vulkan 1.1。
  • [C-SR-3] 強烈建議您實作 VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing 和 VK_KHR_shared_presentable_image，並在可用的 Vulkan 擴充功能清單中公開。
  • [C-SR-4] 強烈建議您至少公開一個 Vulkan 佇列群組，其中 flags 同時包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT，且 queueCount 至少為 2。
  • [C-1-7] GPU 和螢幕必須能夠同步存取共用前端緩衝區，以便以 60fps 和兩個轉譯內容的 VR 內容交替轉譯，並顯示無明顯撕裂的瑕疵。
  • [C-1-9] 必須實作支援 AHardwareBuffer 標記 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT，如 NDK 所述。
  • [C-1-10] 必須支援 AHardwareBuffer，且使用 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 等用途標記的任意組合，至少支援下列格式：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
  • [C-SR-5] 強烈建議您支援以多個層級和 C-1-10 中指定的標記和格式，分配 AHardwareBuffer。
  • [C-1-11] 必須支援 H.264 解碼，解碼畫質至少為 3840 x 2160，以 30 fps 解碼，壓縮至平均 40 Mbps (相當於 1920 x 1080 的 4 個例項，以 30 fps-10 Mbps 解碼，或 1920 x 1080 的 2 個例項，以 60 fps-20 Mbps 解碼)。
  • [C-1-12] 必須支援 HEVC 和 VP9，且必須能夠解碼至少 1920 x 1080，以 30 fps 壓縮至平均 10 Mbps，並且應能夠以 30 fps-20 Mbps 解碼 3840 x 2160 (相當於 30 fps-5 Mbps 的 1920 x 1080 四個例項)。
  • [C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回正確的皮膚溫度值。
  • [C-1-14] 必須有嵌入式螢幕，且解析度至少為 1920 x 1080。
  • [C-SR-6] 強烈建議顯示解析度至少為 2560 x 1440。
  • [C-1-15] 在 VR 模式下，螢幕更新率必須至少為 60 Hz。
  • [C-1-17] 螢幕必須支援低延遲模式，延遲時間不得超過 5 毫秒，延遲時間定義為像素發出光線的時間長度。
  • [C-1-18] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能 第 7.4.3 節。
  • [C-1-19] 必須支援並正確回報下列所有預設感應器類型的直接管道類型：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] 強烈建議您為上述所有直接管道類型支援 TYPE_HARDWARE_BUFFER 直接管道類型。
  • [C-1-21] 必須符合 第 7.3.9 節所述的陀螺儀、加速計和磁力計相關要求。android.hardware.hifi_sensors
  • [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] 必須為 Vibrator.hasVibrator() 傳回 false。

如果裝置實作確實包含至少一個這類通用觸覺感應致動器，則必須符合下列條件：

如果裝置實作符合觸覺常數對應，則會：

7.11. 媒體成效類別

您可以從 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API 取得裝置實作項目的媒體效能類別。從 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 檔案所測得。
  • 隨機寫入效能。使用 4 KB 寫入緩衝區寫入 256 MB 檔案所測得。
  • 順序讀取效能。使用 10 MB 寫入緩衝區讀取 256 MB 檔案所測得。
  • 隨機讀取效能。使用 4 KB 寫入緩衝區讀取 256 MB 檔案所測得。

8.3.省電模式

如果裝置實作包含 AOSP 中提供的功能，以改善裝置電源管理 (例如應用程式待命值區、Doze)，或擴充功能以套用比 受限制的應用程式待命值區更嚴格的限制，則：

  • [C-1-1] 請務必遵循 AOSP 實作方式，觸發、維護、喚醒演算法，以及使用應用程式待命和 Doze 省電模式的全球系統設定或 DeviceConfig。
  • [C-1-2] 應用程式待命功能的各個區塊中，應用程式使用全域設定或 DeviceConfig 時，不得偏離 Android 開放原始碼計畫的實作方式，以便管理工作、鬧鐘和網路的節流。
  • [C-1-3] 應用程式待命功能使用的應用程式待命值區數量，不得偏離 AOSP 實作。
  • [C-1-4] 必須實作「應用程式待命區塊」和「打盹」功能，詳情請參閱「電源管理」一文。
  • [C-1-5] 裝置處於省電模式時，必須針對 PowerManager.isPowerSaveMode() 傳回 true。
  • [C-1-6] 必須提供使用者操作提示，顯示所有可免於應用程式待命和 Doze 省電模式或任何電池最佳化功能的應用程式，且必須實作 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 狀態，除非使用者採取明確的動作，將裝置設為非活動狀態，否則不得進入 S3 狀態。相反地，如果第三方應用程式透過 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 殼層指令，向應用程式開發人員提供這項電源用量資訊。
  • 如果無法將硬體元件的耗電量歸因於應用程式，則應歸因於硬體元件本身。

8.5. 一致的效能

對於高效能長時間執行的應用程式，效能可能會大幅波動，原因可能是其他應用程式在背景執行，或是 CPU 因溫度限制而降速。Android 包含程式介面，因此當裝置有能力時，最上層的前景應用程式可以要求系統最佳化資源分配，以因應這類波動。

裝置實作方式：

如果裝置實作項目回報支援持續效能模式，則會：

  • [C-1-1] 應用程式要求時，必須為前景最上層應用程式提供至少 30 分鐘的一致效能。
  • [C-1-2] 必須遵循 Window.setSustainedPerformanceMode() API 和其他相關 API。

如果裝置實作包含兩個以上的 CPU 核心，則會發生以下情況：

  • 應至少提供一個獨佔核心，可由前景應用程式保留。

如果裝置實作功能可為頂層前景應用程式保留一個專屬核心，則會執行以下操作：

  • [C-2-1] 必須透過 Process.getExclusiveCores() API 方法，回報可由前景頂層應用程式保留的專屬核心 ID 編號。
  • [C-2-2] 除了應用程式使用的裝置驅動程式外，不得允許任何使用者空間處理程序在專屬核心上執行，但可視需要允許某些核心處理程序執行。

如果裝置實作不支援專屬核心，則會發生以下情況：

9. 安全性模型相容性

裝置實作方式：

  • [C-0-1] 必須實作與 Android 平台安全性模型一致的安全性模型，如 Android 開發人員說明文件中 API 的安全性和權限參考文件所定義。

  • [C-0-2] 必須支援安裝自行簽署的應用程式，且不必向任何第三方/主管機關索取任何額外權限/憑證。

如果裝置實作宣告 android.hardware.security.model.compatible 功能，則會：

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

9.1. 權限

裝置實作方式：

  • [C-0-1] 必須支援 Android 開發人員文件中定義的 Android 權限模型和 Android 角色模型。具體來說，他們必須依照 SDK 說明文件所述，強制執行 SDK 定義的每項權限和角色；不得省略、變更或忽略任何權限和角色。

  • 可新增其他權限，但新權限 ID 字串不得位於 android.\* 命名空間。

  • [C-0-2] protectionLevel 為 PROTECTION_FLAG_PRIVILEGED 的權限，必須只授予在系統映像檔 (以及APEX 檔案) 的特殊權限路徑中預先安裝的應用程式，且必須位於每個應用程式的明確許可清單權限子集。AOSP 實作項目會讀取並遵循 etc/permissions/ 路徑中的檔案，為每個應用程式提供許可清單權限，並使用 system/priv-app 路徑做為特殊權限路徑，以符合這項規定。

Android 15 新規定生效

  • [C-SR-1] 建議您只將 protectionLevel 為 PROTECTION_SIGNATURE 的權限授予下列項目：

    • 系統映像檔預先安裝的應用程式 (以及 APEX 檔案)。
    • 應用程式許可清單中允許的權限 (如果系統映像檔中未包含這些權限)。

新規定結束

防護等級為危險的權限是執行階段權限。targetSdkVersion 大於 22 的應用程式會在執行階段要求這些權限。

裝置實作方式：

  • [C-0-3] 必須顯示專用介面，讓使用者決定是否授予要求的執行階段權限，並提供介面讓使用者管理執行階段權限。

  • [C-0-5] 除非符合下列情況，否則不得向應用程式授予任何執行階段權限：

    • 這些應用程式會在裝置出貨時安裝，且

    • 應用程式使用權限前，可以先取得使用者的同意聲明。

      或

    • 執行階段權限是由預設權限授予政策授予，或由平台角色授予。

  • [C-0-6] 請務必只將 android.permission.RECOVER_KEYSTORE 權限授予註冊了安全 Recovery Agent 的系統應用程式。安全的復原代理人定義為裝置端軟體代理人，可與裝置外部遠端儲存空間同步，且配備安全硬體，提供與 Google Cloud 密鑰金庫服務中所述等同或更強的保護措施，以防範鎖定畫面知識因素的暴力攻擊。

裝置實作方式：

  • [C-0-7] 應用程式透過標準 Android API 或專屬機制要求位置或體能活動資料時，必須遵循 Android 位置權限屬性。這類資料包括但不限於：

    • 裝置的位置 (例如緯度和經度)，如第 9.8.8 節所述。
    • 可用於判斷或估算裝置位置的資訊 (例如 SSID、BSSID、行動網路 ID 或裝置連線的網路位置)。
    • 使用者的體能活動或體能活動分類。

具體來說，裝置實作方式如下：

  • [C-0-8] 必須取得使用者同意，才能允許應用程式存取位置或體能活動資料。
  • [C-0-9] 請務必僅授予 SDK 所述的應用程式足夠的執行階段權限。例如，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION)。

上述 Android 位置權限屬性唯一的例外狀況，是指應用程式未透過位置資訊衍生或識別使用者位置的情況，具體如下：

  • 應用程式擁有 RADIO_SCAN_WITHOUT_LOCATION 權限時。
  • 為裝置設定和設定目的，系統應用程式擁有 NETWORK_SETTINGS 或 NETWORK_SETUP_WIZARD 權限。

權限可標示為受限，以便變更其行為。

  • [C-0-10] 標有 hardRestricted 旗標的權限絕對不應授予應用程式，除非：

    • 應用程式 APK 檔案位於系統磁碟分割區。
    • 使用者將與 hardRestricted 權限相關聯的角色指派給應用程式。
    • 安裝程式會將 hardRestricted 授予應用程式。
    • 應用程式在舊版 Android 上獲得 hardRestricted。

  • [C-0-11] 擁有 softRestricted 權限的應用程式必須只取得有限的存取權，且必須在 SDK 中列為許可清單，才能取得完整存取權，SDK 會為每個 softRestricted 權限定義完整和有限的存取權 (例如 READ_EXTERNAL_STORAGE)。

  • [C-0-12] 請勿提供任何自訂函式或 API，以便略過 setPermissionPolicy 和 setPermissionGrantState API 中定義的權限限制。

  • [C-0-13] 必須使用 AppOpsManager API，記錄並追蹤每一次透過程式碼存取 Android 活動和服務中危險權限保護的資料。

  • [C-0-14] 請務必只將角色指派給符合角色規定的應用程式功能。

  • [C-0-15] 不得定義重複的角色，或平台定義的角色的超集功能。

如果裝置回報 android.software.managed_users，則表示：

  • [C-1-1] 不得由管理員靜默授予下列權限：
    • 位置 (ACCESS_BACKGROUND_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_FINE_LOCATION)。
    • 相機 (CAMERA)
    • 麥克風 (RECORD_AUDIO)
    • 人體感應器 (BODY_SENSORS)
    • 體能活動 (ACTIVITY_RECOGNITION)

如果裝置實作提供使用者操作元素，讓他們選擇哪些應用程式可在其他應用程式上繪製，並透過處理 ACTION_MANAGE_OVERLAY_PERMISSION 意圖的活動，則可執行以下操作：

  • [C-2-1] 必須確保所有具有 ACTION_MANAGE_OVERLAY_PERMISSION 意圖的意圖篩選器活動都具有相同的 UI 畫面，不論啟動應用程式或其提供的任何資訊為何。

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

  • [C-3-1] 在完全受管理的裝置設定 (裝置擁有者設定) 期間，必須顯示免責事項，指出 IT 管理員可讓應用程式控制手機上的設定，包括麥克風、相機和位置，並提供使用者繼續設定或退出設定的選項，除非管理員已選擇不控制裝置上的權限。

如果裝置實作預先安裝任何包含 System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence 或 System Visual Intelligence 角色的套件，則這些套件必須符合下列條件：

  • [C-4-1] 必須符合「9.8.6 作業系統層級和環境資料」和「9.8.15 沙箱 API 實作」一節中，針對裝置實作方式所列的所有規定。

如果裝置實作內容包含支援 VoiceInteractionService 的預設應用程式，則會符合下列條件：

  • [C-5-1] 不得將 ACCESS_FINE_LOCATION 授權為該應用程式的預設值。

9.2. UID 和程序隔離

裝置實作方式：

  • [C-0-1] 必須支援 Android 應用程式沙箱模型，其中每個應用程式都會以獨特的 Unix 風格 UID 和個別程序執行。
  • [C-0-2] 必須支援以相同的 Linux 使用者 ID 執行多個應用程式，前提是應用程式已正確簽署及建構，如安全性和權限參考資料所定義。

9.3. 檔案系統權限

裝置實作方式：

9.4. 替代執行環境

裝置實作必須維持 Android 安全性和權限模型的一致性，即使包含執行應用程式的執行階段環境，使用其他軟體或技術 (而非 Dalvik 可執行格式或原生程式碼) 執行應用程式，也一樣。換句話說：

  • [C-0-1] 替代執行階段本身必須是 Android 應用程式，並遵循標準的 Android 安全性模型，如第 9 節其他部分所述。

  • [C-0-2] 替代執行階段不得授予存取權，以便存取透過 <uses-permission> 機制在執行階段的 AndroidManifest.xml 檔案中未要求的權限所保護的資源。

  • [C-0-3] 替代執行階段絕對不允許應用程式使用受限於系統應用程式的 Android 權限保護的功能。

  • [C-0-4] 替代執行階段必須遵循 Android 沙箱模型，且使用替代執行階段的安裝應用程式不得重複使用裝置上安裝的任何其他應用程式的沙箱，除非透過共用使用者 ID 和簽署憑證的標準 Android 機制。

  • [C-0-5] 替代執行階段不得啟動、授予或授予其他 Android 應用程式對應的沙箱存取權。

  • [C-0-6] 替代執行階段不得啟動、授予或授予其他應用程式任何超級使用者 (root) 或其他使用者 ID 的權限。

  • [C-0-7] 當裝置實作系統映像檔中包含其他執行階段的 .apk 檔案時，必須使用與裝置實作中其他應用程式所用的金鑰不同的金鑰進行簽署。

  • [C-0-8] 安裝應用程式時，替代執行階段必須取得使用者同意，才能使用應用程式所用的 Android 權限。

  • [C-0-9] 當應用程式需要使用具有對應 Android 權限 (例如相機、GPS 等) 的裝置資源時，替代執行階段必須通知使用者，應用程式將能夠存取該資源。

  • [C-0-10] 如果執行階段環境未以這種方式記錄應用程式功能，則在安裝使用該執行階段的任何應用程式時，執行階段環境必須列出執行階段本身所持有的所有權限。

  • 替代執行階段應透過 PackageManager 將應用程式安裝到個別的 Android 沙箱 (Linux 使用者 ID 等)。

  • 替代執行階段可能會提供單一 Android 沙箱，供使用替代執行階段的所有應用程式共用。

9.5. 支援多位使用者

Android 支援多名使用者，並支援完整使用者隔離功能，以及使用部分隔離功能複製使用者設定檔(即 android.os.usertype.profile.CLONE 類型的單一額外使用者設定檔)。

  • 如果裝置實作使用可移動式媒體做為主要外部儲存空間，則可以但不應啟用多使用者功能。

如果裝置實作內容支援多位使用者，則必須符合下列條件：

  • [C-1-2] 必須為每位使用者實作安全模型，該模型必須符合 API 中 安全性和權限參考文件所定義的 Android 平台安全模型。
  • [C-1-3] 每個使用者例項都必須有獨立的共用應用程式儲存空間 (又稱為 /sdcard) 目錄。
  • [C-1-4] 請務必確保由特定使用者擁有並代為執行的應用程式，無法列出、讀取或寫入任何其他使用者擁有的檔案，即使兩者的資料儲存在相同的磁區或檔案系統中也一樣。
  • [C-1-5] 啟用多使用者功能時，必須使用金鑰加密 SD 卡的內容，該金鑰只能儲存在系統可存取的非可移除媒體上 (如果裝置實作使用外部儲存空間 API 的話)。由於這會導致主機電腦無法讀取媒體，因此裝置實作必須切換至 MTP 或類似系統，讓主機電腦存取目前使用者的資料。

如果裝置實作內容支援多位使用者，則除了專門用於執行同一應用程式的雙重執行個體的使用者，其他使用者可執行下列操作：

  • [C-2-1] 必須為每個使用者例項提供獨立的共用應用程式儲存空間 (又稱為 /sdcard) 目錄。
  • [C-2-2] 請務必確保由特定使用者擁有並代為執行的應用程式，無法列出、讀取或寫入任何其他使用者擁有的檔案，即使兩者的資料儲存在相同的磁區或檔案系統中也一樣。

裝置實作可能會針對主要使用者 (且僅針對主要使用者) 建立單一 android.os.usertype.profile.CLONE 類型的額外使用者設定檔，目的是執行相同應用程式的雙重例。這些雙重例會共用部分隔離的儲存空間，並同時在啟動器中呈現給使用者，也會顯示在相同的「近期」檢視畫面中。舉例來說，這項功能可用於支援使用者在雙 SIM 卡裝置上安裝單一應用程式的兩個個別例項。

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

  • [C-3-1] 請務必只提供存放空間或資料的存取權，這些存放空間或資料必須是父項使用者個人資料已可存取，或是由這個額外使用者個人資料直接擁有。
  • [C-3-2] 不得將此設為工作資料夾。
  • [C-3-3] 必須從父項使用者帳戶隔離私人應用程式資料目錄。
  • [C-3-4] 如果已設定裝置擁有者 (請見第 3.9.1 節)，則不得建立其他使用者設定檔；如果允許設定裝置擁有者，則必須先移除其他使用者設定檔。

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

9.6. 付費簡訊警告

Android 支援警告使用者傳送任何付費簡訊。「付費簡訊」是指傳送至電信業者註冊服務的簡訊，可能會向使用者收費。

如果裝置實作項目宣告支援 android.hardware.telephony，則會：

  • [C-1-1] 必須在傳送簡訊給使用者裝置中 /data/misc/sms/codes.xml 檔案中定義的規則運算式所識別的號碼前，先向使用者發出警告。上游 Android 開放原始碼專案提供符合這項需求的實作方式。

9.7. 資安防護機制

裝置實作項目必須確保符合核心和平台的安全防護功能，如下所述。

Android 沙箱包含使用 Security-Enhanced Linux (SELinux) 強制存取控制 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全性功能。裝置實作方式：

  • [C-0-1] 即使在 Android 架構下方實作 SELinux 或任何其他安全性功能，也必須與現有應用程式相容。
  • [C-0-2] 在偵測到安全性違規，且 Android 架構下實作的安全性功能成功封鎖時，不得顯示使用者介面，但在未封鎖的安全性違規導致成功的漏洞攻擊時，則可以顯示使用者介面。
  • [C-0-3] 絕對不得讓 SELinux 或任何其他在 Android 架構下實作的安全性功能，可供使用者或應用程式開發人員設定。
  • [C-0-4] 應用程式不得透過 API (例如 Device Administration API) 影響其他應用程式，以便設定會破壞相容性的政策。
  • [C-0-5] 必須將媒體架構分割為多個程序，以便根據 Android 開放原始碼專案網站說明，為每個程序授予更精確的存取權。
  • [C-0-6] 必須實作核心應用程式沙箱機制，以便使用多執行緒程式的可設定政策篩選系統呼叫。上游 Android 開放原始碼計畫透過啟用具有執行緒群組同步處理 (TSYNC) 的 seccomp-BPF，滿足這項要求，如source.android.com 的「核心設定」一節所述。

核心完整性和自我防護功能是 Android 安全防護的關鍵。裝置實作方式：

  • [C-0-7] 必須實作核心堆疊緩衝區溢位保護機制。這類機制的例子包括 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
  • [C-0-8] 必須實作嚴格的核心記憶體保護機制，其中可執行的程式碼為唯讀、唯讀資料不可執行且不可寫入，可寫入的資料不可執行 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
  • [C-0-9] 在原先搭載 API 級別 28 以上版本的裝置上，必須實作使用者空間和核心空間 (例如 CONFIG_HARDENED_USERCOPY) 之間的靜態和動態物件大小邊界檢查。
  • [C-0-10] 在原先搭載 API 級別 28 以上版本的裝置上，執行核心模式 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 時，請務必不要執行使用者空間記憶體。
  • [C-0-11] 在原先搭載 API 級別 28 以上版本的裝置上，除了一般 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] 必須在強制模式下設定所有網域。不允許使用許可模式網域，包括特定裝置/供應商的網域。
  • [C-1-4] 絕對不可修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 提供的 system/sepolicy 資料夾中現有的 neverallow 規則，且政策必須針對 AOSP SELinux 網域和裝置/供應商專屬網域，編譯所有現有的 neverallow 規則。
  • [C-1-5] 必須在每個應用程式的 SELinux 沙箱中執行指定 API 級別 28 以上版本的第三方應用程式，並針對每個應用程式的私人資料目錄設定個別的 SELinux 限制。
  • 應保留上游 Android 開放原始碼計畫的 system/sepolicy 資料夾中提供的預設 SELinux 政策，並只針對自己的裝置專屬設定進一步新增此政策。

如果裝置實作使用 Linux 以外的核心，或使用沒有 SELinux 的 Linux，則會發生以下情況：

  • [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、適用於 ARMv8 裝置的 CONFIG_KASAN_SW_TAGS，或適用於其他裝置類型的 CONFIG_KASAN_GENERIC)。
  • [C-SR-12] 強烈建議您在實際工作環境中使用記憶體錯誤偵測工具，例如 MTE、GWP-ASan 和 KFENCE。

如果裝置實作使用以 Arm TrustZone 為基礎的 TEE，則會：

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

記憶體安全性技術是一種技術，可在使用 android:memtagMode 資訊清單選項的應用程式中，至少減輕下列類型的錯誤機率 (高於 90%)：

  • 堆積緩衝區溢位
  • 釋放後使用
  • 重複釋放
  • 錯誤釋放 (釋放非 malloc 指標)

裝置實作方式：

  • [C-SR-15] 強烈建議設定 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] 必須允許殼層使用者設定 arm64.memtag.bootctl。

  • [C-3-3] 必須允許任何程序讀取 arm64.memtag.bootctl。

  • [C-3-4] 必須在啟動時將 arm64.memtag.bootctl 設為目前要求的狀態，如果裝置實作可在不變更系統屬性的情況下修改狀態，則必須更新屬性。

  • [C-SR-16] 強烈建議您顯示開發人員設定，設定 memtag-once 並重新啟動裝置。透過相容的系統啟動載入程式，Android 開放原始碼計畫可透過 MTE 系統啟動載入程式通訊協定滿足上述規定。

Android 15 的新規定上路了

如果裝置宣告 android.hardware.telephony、支援無線功能 CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK，且包含支援 2G 連線的行動數據機，則裝置實作方式如下：

新規定結束

9.8. 隱私權

9.8.1。用量記錄

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

裝置實作方式：

  • [C-0-1] 必須保留合理期間的使用者記錄。
  • [C-SR-1] 強烈建議您將 14 天保留期限維持為 AOSP 實作中預設的設定。

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

裝置實作方式：

  • [C-0-2] 由系統 API 類別 IncidentManager 建立的事件報告中，只能包含標示為 DEST_AUTOMATIC 的欄位。
  • [C-0-3] 除了 StatsLog SDK 文件中所述的事件外，請勿使用系統事件 ID 記錄任何其他事件。如果記錄其他系統事件，可能會使用 100,000 到 200,000 之間的不同原子 ID。

9.8.2. 錄製中

裝置實作方式：

  • [C-0-1] 未經使用者同意，不得預先載入或發布會將使用者的私人資訊 (例如按鍵動作、螢幕上顯示的文字、錯誤報告) 傳送至裝置外的軟體元件，或清除目前的通知。

  • [C-0-2] 每次透過 MediaProjection.createVirtualDisplay()、VirtualDeviceManager.createVirtualDisplay() 或專屬 API 啟動螢幕擷取工作階段時，都必須顯示使用者警告並徵得使用者明確同意，以便擷取使用者螢幕上顯示的任何機密資訊。

  • [C-0-3] 啟用投放螢幕或螢幕錄影功能時，必須向使用者顯示持續性通知。AOSP 會在狀態列中顯示持續通知圖示，以符合這項規定。

  • [C-SR-1] 強烈建議您顯示使用者警告，這項警告必須與 AOSP 中實作的訊息完全相同，但可以修改，只要訊息清楚警告使用者，指出系統會擷取使用者畫面上的任何敏感資訊即可。

  • [C-0-4] 請勿提供使用者可用來停用日後提示的操作選項，以便使用者同意擷取螢幕畫面，除非工作階段是由系統應用程式啟動，且使用者已允許該應用程式透過 android.app.role.COMPANION_DEVICE_APP_STREAMING 或 android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING 裝置設定檔associate()。

Android 15 的新規定上路了

裝置實作方式：

  • [C-0-7] 請勿錄製、投放或投射敏感資訊，例如：
    • 第 3.8.3.4 節 保護敏感通知中列出的敏感通知內容
    • 包含一次性密碼的應用程式活動視窗
    • 機密內容，例如使用者名稱、密碼和信用卡資訊

新規定結束

如果裝置實作內容包含系統中的功能，該功能會擷取螢幕上顯示的內容，並/或錄製在裝置上播放的音訊串流，但不是透過系統 API ContentCaptureService 或第 9.8.6 節 OS 層級和環境資料中所述的其他專屬方式，則必須符合下列條件：

  • [C-1-1] 只要啟用這項功能並進行拍攝/錄影，就必須持續向使用者發出通知。

如果裝置實作包含可立即啟用的元件，能夠錄製環境音訊和/或錄製裝置播放的音訊，以便推斷使用者背景資訊的實用資訊，則這些元件必須符合下列條件：

  • [C-2-1] 除非經過使用者明確同意，否則不得將錄製的原始音訊或任何可轉換回原始音訊或近似副本的格式，儲存在裝置上的永久性儲存空間或傳送離開裝置。

「麥克風指標」是指螢幕上可供使用者持續查看且無法遮蔽的檢視畫面，可讓使用者瞭解麥克風正在使用中(透過不重複的文字、顏色、圖示或某些組合)。

「相機指示器」是指螢幕上可供使用者持續查看且無法遮蔽的檢視畫面，可讓使用者瞭解相機正在使用中 (透過獨特文字、顏色、圖示或某些組合)。

在顯示第一秒後，指標可視需要進行視覺變化 (例如變小)，但不必維持原始呈現方式，也不必讓使用者瞭解。

麥克風指示圖示可與正在顯示的相機指示圖示合併，但前提是使用文字、圖示或顏色向使用者指出麥克風已開始使用。

只要使用文字、圖示或顏色向使用者顯示相機已開始使用，相機指標即可與正在顯示的麥克風指標合併。

如果裝置實作宣告 android.hardware.microphone，則會執行以下操作：

  • [C-SR-1] 強烈建議在應用程式存取麥克風的音訊資料時顯示麥克風指示燈，但如果只有 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或具有第 9.1 節「具有 CDD 識別碼的權限」[C-3-X] 中所述角色的應用程式存取麥克風，則不必顯示。。
  • [C-SR-2] 強烈建議您顯示使用麥克風的近期和活躍應用程式清單，並列出與這些應用程式相關的歸因訊息。PermissionManager.getIndicatorAppOpUsageData()
  • [C-SR-3] 強烈建議您不要隱藏麥克風指示燈，除非是針對具有可見使用者介面或直接使用者互動的系統應用程式。

如果裝置實作宣告 android.hardware.camera.any，則會執行以下操作：

  • [C-SR-4] 強烈建議在應用程式存取即時相機資料時顯示相機指標，但如果只有具備第 9.1 節「使用 CDD 識別碼的權限」[C-3-X] 中所述角色的應用程式存取相機，則不必顯示相機指標。
  • [C-SR-5] 強烈建議您使用 PermissionManager.getIndicatorAppOpUsageData() 傳回的攝影機資料，顯示「最近使用」和「正在執行」的應用程式，以及與這些應用程式相關的任何歸因訊息。
  • [C-SR-6] 強烈建議您不要隱藏攝影機指示燈，除非系統應用程式具有可見的使用者介面或直接使用者互動。

9.8.3. 連線能力

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，則該裝置會：

  • [C-1-1] 必須先顯示使用者介面，要求使用者同意，才能透過 USB 連接埠存取共用儲存空間的內容。

9.8.4。網路流量

裝置實作方式：

  • [C-0-1] 必須為系統信任的憑證授權單位 (CA) 存放區預先安裝與上游 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。OS 層級和環境資料

Android 透過系統 API 支援裝置實作機制，可擷取下列機密資料：

  • 螢幕上顯示的文字和圖像，包括但不限於透過 AssistStructure API 顯示的通知和輔助資料。
  • 媒體資料 (例如音訊或影片)，由裝置錄製或播放。

  • 輸入事件 (例如按鍵、滑鼠、手勢、語音、影片和無障礙功能)。

  • 任何透過 AugmentedAutofillService 傳送至系統的畫面或其他資料。

  • 任何可透過 Content Capture API 存取的畫面或其他資料。

  • 任何透過 AppSearchManager API 傳遞至系統，並可透過 AppSearchGlobalManager.query 存取的應用程式資料。

  • 透過 TextClassifier API 傳送至系統 TextClassifier 的任何文字或其他資料，也就是傳送至系統服務，以便瞭解文字的含義，並根據文字產生預測的後續動作。

  • 由平台 AppSearch 導入的索引資料，包括但不限於文字、圖形、媒體資料或其他類似資料。

  • 語音辨識器實作項目使用 SpeechRecognizer#onDeviceSpeechRecognizer() 所取得的音訊資料。

  • 透過 AudioRecord、SoundTrigger 或其他 Audio API 在背景 (持續) 取得音訊資料，且不會產生使用者可見的指標

  • 透過 CameraManager 或其他 Camera API 在背景 (持續) 取得相機資料，且不會產生使用者可見的指標

如果裝置實作擷取上述任何資料，則會：

  • [C-1-1] 儲存在裝置中的所有這類資料都必須加密。這項加密作業可使用 Android 檔案為基礎的加密功能，或任何 Cipher SDK 中列為 API 26 以上版本的加密器執行。
  • [C-1-2] 請勿使用 Android 備份方法或任何其他備份方法，備份原始資料或加密資料。
  • [C-1-3] 您必須使用隱私權保護機制，將所有這類資料傳送出裝置，除非每次分享資料時都獲得使用者的明確同意。隱私權保護機制定義為「僅允許匯總分析，並防止將記錄的事件或衍生結果與個別使用者進行比對」，以免任何個別使用者資料可供內省 (例如，使用差異化隱私技術 (例如 RAPPOR) 實作)。
  • [C-1-4] 不得將這類資料與裝置上的任何使用者身分 (例如 Account) 建立關聯，除非每次建立關聯時都徵得使用者明確同意。
  • [C-1-5] 不得將此類資料分享給未遵守本節 (9.8.6 作業系統層級和環境資料) 規定的其他 OS 元件，除非每次分享時都獲得使用者的明確同意。除非這類功能已建構為 Android SDK API (AmbientContext、HotwordDetectionService)。
  • [C-1-6] 必須提供使用者操作選項，讓他們能夠刪除實作項目或專屬方式收集的資料，無論資料以何種形式儲存在裝置上。如果使用者選擇刪除資料，則必須移除所有收集到的歷來資料。

  • [C-1-7] 您必須提供使用者選項，讓他們選擇不讓透過 AppSearch 或專屬方式收集的資料顯示在 Android 平台 (例如啟動器) 中。

  • [C-SR-1] 強烈建議您不要要求 INTERNET 權限。

  • [C-SR-2] 強烈建議您只透過有公開開放原始碼實作項目的結構化 API 存取網際網路。

  • [C-SR-4] 強烈建議您使用 Android SDK API 或類似的 OEM 專屬開放原始碼存放區，以及 / 或在沙箱實作中執行 (請參閱 9.8.15 沙箱 API 實作)。

如果裝置實作項目包含實作系統 API ContentCaptureService 或 AppSearchManager.index 的服務，或是任何可擷取上述資料的專屬服務，則這些服務必須符合下列條件：

  • [C-2-1] 請勿允許使用者以可供使用者安裝的應用程式或服務取代服務，且請務必只允許預先安裝的服務擷取這類資料。
  • [C-2-2] 除了預先安裝的服務機制外，不得允許任何應用程式擷取這類資料。
  • [C-2-3] 必須提供使用者停用服務的操作提示。

  • [C-2-4] 請務必提供使用者操作介面，以便管理服務所持有的 Android 權限，並遵循 第 9.1 節所述的 Android 權限模式。權限。

  • [C-SR-3] 強烈建議您將服務與其他系統元件分開 (例如不綁定服務或共用程序 ID)，但下列情況除外：

    • 電話、聯絡人、系統使用者介面和媒體

9.8.7. 剪貼簿存取權

裝置實作方式：

  • [C-0-1] 不得從剪貼簿傳回已剪報的資料 (例如透過 ClipboardManager API)，除非第三方應用程式是預設 IME，或為目前有焦點的應用程式。

  • [C-0-2] 必須在剪貼簿資料最後放入或讀取剪貼簿後的 60 分鐘內清除。

9.8.8。位置

位置資訊包括 Android 位置類別中的資訊( 例如緯度、經度、高度)，以及可轉換為位置的 ID。位置資訊可以精確到 DGPS (差分全球定位系統)，也可以粗略到國家/地區層級 (例如國家/地區代碼位置 - MCC - 行動國家/地區代碼)。

以下是位置類型清單，這些類型會直接衍生使用者的所在位置，或可轉換為使用者的所在位置。這並非完整清單，但可用於說明位置資訊可直接或間接擷取自哪些來源：

  • GPS/GNSS/DGPS/PPP
    • 全球定位解決方案或全球衛星導航系統或差分全球定位解決方案
    • 這也包括原始全球導航衛星系統測量資料和 GNSS 狀態
      • 精確位置資訊可從原始全球導航衛星系統測量資料推算而來
  • 無線技術，其中包含專屬 ID，例如：
    • Wi-Fi 存取點 (MAC、BSSID、名稱或 SSID)
    • 藍牙/BLE (MAC、BSSID、名稱或 SSID)
    • UWB (MAC、BSSID、名稱或 SSID)
    • 基地台 ID (3G、4G、5G… 包括所有未來的行動數據機技術，皆含有專屬 ID)

請參閱需要 ACCESS_FINE_Location 或 ACCESS_COARSE_Location 權限的 Android API，做為主要參考依據。

裝置實作方式：

  • [C-0-1] 未經使用者明確同意或使用者啟動，不得開啟/關閉裝置位置設定和 Wi-Fi/藍牙掃描設定。
  • [C-0-2] 您必須提供使用者存取位置相關資訊的操作提示，包括最近的位置要求、應用程式層級權限，以及用於判斷位置的 Wi-Fi/藍牙掃描功能。
  • [C-0-3] 請務必確認使用緊急定位繞過 API [LocationRequest.setLocationSettingsIgnored()] 的應用程式，是使用者啟動的緊急情況工作階段 (例如撥打或傳送簡訊給 911)。不過，在汽車方面，車輛在偵測到車禍/意外事故時，可能會在沒有使用者主動互動情況下啟動緊急工作階段 (例如為了符合 eCall 規定)。
  • [C-0-4] 必須保留緊急位置繞過 API 的功能，讓使用者不必變更設定，即可繞過裝置位置資訊設定。
  • [C-0-5] 應用程式在背景使用 [ACCESS_BACKGROUND_LOCATION] 權限存取位置資訊後，必須排程通知提醒使用者。

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] 必須透過 BugreportManager 使用 BUGREPORT_MODE_TELEPHONY 產生連線錯誤報告。
  • [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] 強烈建議將開發人員設定預設為停用。AOSP 參考實作項目在開發人員設定中提供 Enable verbose vendor logging 選項，可在錯誤報告中納入其他裝置專屬供應商記錄，以符合這項需求。

9.8.11。資料 blob 共用

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

如果裝置實作項目支援 SDK 說明文件中所述的共用資料 blob，則會：

9.8.12。音樂辨識

Android 透過系統 API MusicRecognitionManager，支援在有音訊錄音檔的情況下，讓裝置實作要求音樂辨識的機制，並將音樂辨識工作委派給實作 MusicRecognitionService API 的特權應用程式。

如果裝置實作內容包含實作系統 API MusicRecognitionManager 的服務，或任何會如上所述串流音訊資料的專屬服務，則會：

  • [C-1-1] 必須強制執行 MusicRecognitionManager 的呼叫端持有 MANAGE_MUSIC_RECOGNITION 權限
  • [C-1-2] 必須強制執行單一預先安裝的音樂辨識應用程式，實作 MusicRecognitionService。
  • [C-1-3] 請勿允許使用者將 MusicRecognitionManagerService 或 MusicRecognitionService 取代為使用者可安裝的應用程式或服務。
  • [C-1-4] 必須確保在 MusicRecognitionManagerService 存取音訊記錄並將其轉送至實作 MusicRecognitionService 的應用程式時，透過 AppOpsManager.noteOp / startOp 叫用來追蹤音訊存取權。

如果 MusicRecognitionManagerService 或 MusicRecognitionService 的裝置實作會儲存任何擷取的音訊資料，則會：

  • [C-2-1] 絕對不得將任何原始音訊或音訊指紋儲存在磁碟上，或在記憶體中保留超過 14 天。
  • [C-2-2] 除非每次分享時都徵得使用者明確同意，否則不得將這類資料分享給 MusicRecognitionService 以外的對象。

9.8.13。SensorPrivacyManager

如果裝置實作提供使用者關閉裝置實作攝影機和/或麥克風輸入的軟體操作元素，則應符合下列條件：

  • [C-1-1] 必須針對相關的 supportsSensorToggle() API 方法準確傳回「true」。
  • [C-1-2] 必須：當應用程式嘗試存取已封鎖的麥克風或相機時，必須向使用者顯示不可關閉的使用者操作元素，清楚指出該感應器已遭封鎖，並要求使用者選擇是否要繼續封鎖或解除封鎖，且必須符合此要求的 AOSP 實作。
  • [C-1-3] 必須只將空白 (或假) 相機和音訊資料傳遞至應用程式，且不得因使用者未透過上述 [C-1-2] 提供的使用者操作選項開啟相機或麥克風而回報錯誤代碼。

9.8.14。無

9.8.15。Sandboxed API 實作

Android 透過一組委派 API 提供機制，用於處理安全的作業系統層級和環境資料。這類處理作業可委派給預先安裝的 APK，該 APK 具有特權存取權和較少的通訊功能，稱為沙箱 API 實作。

任何 Sandboxed API 實作項目：

  • [C-0-1] 請勿要求 INTERNET 權限。
  • [C-0-2] 應用程式必須透過結構化 API 存取網際網路，且該 API 必須採用公開的隱私權保護機制開源實作項目，或間接透過 Android SDK API 存取網際網路。隱私權保護機制定義為「僅允許匯總分析，並防止系統將記錄的事件或衍生結果與個別使用者進行比對」，以免任何個別使用者資料可供內省 (例如，使用差異化隱私技術 (例如 RAPPOR) 實作)。
  • [C-0-3] 除了下列情況外，服務必須與其他系統元件分開 (例如，不要繫結服務或共用程序 ID)：
    • 電話、聯絡人、系統使用者介面和媒體
  • [C-0-4] 不得允許使用者以使用者可安裝的應用程式或服務取代服務
  • [C-0-5] 請務必只允許預先安裝的服務擷取這類資料。除非替換功能已內建於 Android 開放原始碼計畫 (例如數位助理應用程式)。
  • [C-0-6] 不得允許任何應用程式 (預先安裝服務機制除外) 擷取這類資料。除非這類擷取功能是使用 Android SDK API 實作。
  • [C-0-7] 必須提供使用者停用服務的操作元素。
  • [C-0-8] 請務必提供使用者管理服務所持有 Android 權限的操作選項，並遵循 第 9.1 節所述的 Android 權限模式。權限。

9.8.16。持續性音訊和相機資料

Android 15 的新規定上路了

除了 9.8.2 錄製、9.8.6 作業系統層級和環境資料，以及 9.8.15 沙箱 API 實作項目中列出的規定外，如果實作項目透過 AudioRecord、SoundTrigger 或其他 Audio API 在背景 (持續) 取得音訊資料，或透過 CameraManager 或其他 Camera API 在背景 (持續) 取得相機資料，則必須符合下列規定：

如果裝置實作項目擷取 9.8.2 或 9.8.6 節所述的任何資料，且這些實作項目透過 AudioRecord、SoundTrigger 或其他 Audio API 在背景 (持續) 取得音訊資料，或透過 CameraManager 或其他 Camera API 在背景 (持續) 取得攝影機資料，則：

新規定結束

  • [C-0-1] 必須強制執行對應的指標 (相機和/或麥克風，請參閱第 9.8.2 節「錄影」)，除非：
    • 這項存取權是在沙箱實作 (請參閱 9.8.15 沙箱 API 實作) 中執行，透過包裝函式持有下列一或多個角色：系統 UI 智慧、系統背景音訊智慧、系統音訊智慧、系統通知智慧、系統文字智慧或系統視覺智慧。
    • 存取權是透過沙箱執行，並透過 Android 開放原始碼計畫中的機制 (HotwordDetectionService、WearableSensingService、VisualQueryDetector) 實作及強制執行。
    • 數位助理應用程式會為了輔助目的而取得音訊存取權，並提供 SOURCE_HOTWORD 做為音訊來源。
    • 存取權由系統執行，並使用開放原始碼程式碼實作。
  • [C-SR-1] 強烈建議您為使用這類資料的每項功能要求使用者同意，並預設為停用。
  • [C-SR-2] 強烈建議您對來自遠端穿戴式裝置的相機資料，採取相同的處理方式 (即遵循 9.8.2 錄影、9.8.6 作業系統層級和環境資料、9.8.15 沙箱 API 實作，以及 9.8.16 持續音訊和相機資料)。

Android 15 的新規定上路了

如果攝影機資料是從遠端穿戴式裝置提供，且在 Android 作業系統、沙箱實作或 WearableSensingManager 建構的沙箱功能之外以未加密的形式存取，則會發生以下情況：

如果裝置實作項目從遠端穿戴式裝置接收相機或麥克風資料，且在 Android OS、沙箱實作項目或由 WearableSensingManager 建構的沙箱功能之外，以未加密的形式存取資料，則會發生以下情況：

新規定結束

  • [C-1-1] 必須指示遠端穿戴式裝置顯示額外的指標。

如果裝置提供與數位助理應用程式互動的能力，但未指定關鍵字 (處理一般使用者查詢，或透過攝影機分析使用者是否在場)，則裝置會：

  • [C-2-1] 必須確保此實作是由持有 android.app.role.ASSISTANT 角色的套件提供。
  • [C-2-2] 必須確保此實作方式使用 HotwordDetectionService 和/或 VisualQueryDetectionService Android API。

9.8.17. 遙測

Android 會使用 StatsLog API 儲存系統和應用程式記錄。這些記錄會透過 StatsManager API 進行管理，而系統應用程式可使用這些 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 ]必須強制執行本節中的資料傳出政策，以便控管 StatsLog 中定義的受限指標類別資料收集作業。

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] 必須在使用者提供憑證 (例如密碼、PIN 碼、圖案或指紋) 解鎖裝置後，才允許存取憑證加密 (CE) 儲存空間，並且廣播 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 是指進階加密標準，其使用 256 位元密碼金鑰長度，並在 XTS 模式下運作；金鑰的完整長度為 512 位元。Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 所述。檔案系統中繼資料是指檔案大小、擁有權、模式和擴充屬性 (xattr) 等資料。
  • [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) 組合加密，而這兩者都取決於檔案和檔案內的偏移量。此外，所有這類組合都必須是獨特的，除非是使用僅支援 IV 長度為 32 位元的內嵌加密硬體進行加密。
  • [C-1-16] 必須確保在不同目錄中，永久儲存空間中的所有未刪除的加密檔案名稱，均使用加密金鑰和初始化向量 (IV) 的不同組合加密。

  • [C-1-17] 必須確保使用加密金鑰和初始化向量 (IV) 的不同組合，對持續性儲存空間中的所有加密檔案系統中繼資料區塊進行加密。

  • 保護 CE 和 DE 儲存區和檔案系統中繼資料的金鑰：

    • [C-1-7] 必須透過加密編譯方式，與硬體支援的 Keystore 繫結。此 KeyStore 必須綁定至驗證開機程序和裝置的硬體信任根。
    • [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
    • [C-1-9] 如果使用者未指定螢幕鎖定畫面憑證，CE 金鑰必須綁定至預設密碼。
    • [C-1-10] 必須是獨特且不重複的值，換句話說，沒有任何使用者的 CE 或 DE 鍵會與其他使用者的 CE 或 DE 鍵相符。
    • [C-1-11] 必須使用系統支援的加密法、金鑰長度和模式。
    • [C-1-12] 必須在解鎖及鎖定系統啟動載入程式期間安全地清除，如這裡所述。

  • 應讓預先安裝的重要應用程式 (例如鬧鐘、電話、Messenger) 支援直接啟動。

上游 Android 開放原始碼專案提供以 Linux 核心「fscrypt」加密功能為基礎的檔案加密功能，以及以 Linux 核心「dm-default-key」功能為基礎的中繼資料加密功能。

9.9.3.2. 個別使用者區塊層級加密

如果裝置實作使用個別使用者的區塊層級加密功能，則會：

  • [C-1-1] 必須啟用多使用者支援功能，如第 9.5 節所述。
  • [C-1-2] 必須提供個別使用者分區，可使用原始分區或邏輯磁碟區。
  • [C-1-3] 必須為每位使用者使用不重複且獨特的加密金鑰，以便加密基礎的區塊裝置。

  • [C-1-4] 必須使用 AES-256-XTS 對使用者分區進行區塊層級加密。

  • 保護個別使用者區塊層級加密裝置的金鑰：

    • [C-1-5] 必須透過加密編譯方式，與硬體支援的 Keystore 繫結。此 KeyStore 必須綁定至驗證開機程序和裝置的硬體信任根。
    • [C-1-6] 必須繫結至對應使用者的鎖定畫面憑證。

您可以使用 Linux 核心的「dm-crypt」功能，針對個別使用者分割區實作個別使用者區塊層級加密。

9.9.4. 重新啟動時繼續執行

重新啟動後繼續執行功能可在 OTA 啟動的重新啟動後，解鎖所有應用程式的 CE 儲存空間，包括尚未支援直接啟動的應用程式。這項功能可讓使用者在重新啟動後，收到已安裝應用程式的通知。

實作 Resume-on-Reboot 時，必須持續確保在裝置落入攻擊者手中時，即使裝置已開機、CE 儲存空間已解鎖，且使用者在收到 OTA 後已解鎖裝置，攻擊者也極難復原使用者以 CE 加密的資料。針對內部攻擊防禦機制，我們也假設攻擊者會取得廣播加密編譯金鑰的存取權。

具體違規事項如下：

  • [C-0-1] 即使攻擊者實際擁有裝置，並具備下列功能和限制，CE 儲存空間也絕對不得可讀：

    • 可使用任何供應商或公司的簽署金鑰簽署任意訊息。
    • 可能會導致裝置收到 OTA。
    • 可修改任何硬體 (AP、閃燈等) 的運作方式，但請注意，如未按照下方說明進行修改，系統會延遲至少一小時，並進行會破壞 RAM 內容的電源週期。
    • 無法修改防竄改硬體 (例如 Titan M) 的運作方式。
    • 無法讀取直播裝置的 RAM。
    • 無法取得使用者的憑證 (PIN 碼、解鎖圖案、密碼)，或無法讓使用者輸入憑證。

舉例來說，如果裝置實作符合「這裡」所列的所有說明，就會符合 [C-0-1]。

9.10. 裝置完整性

下列規定可確保裝置完整性狀態資訊公開透明。裝置實作方式：

  • [C-0-1] 必須透過系統 API 方法 PersistentDataBlockManager.getFlashLockState() 正確回報其引導程式狀態是否允許刷新系統映像檔。

  • [C-0-2] 裝置完整性必須支援驗證開機程序。

如果裝置實作已推出，但在較舊的 Android 版本中不支援「已驗證啟動」，且無法透過系統軟體更新新增對這項功能的支援，則可能不受此規定限制。

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

  • [C-1-1] 必須宣告平台功能旗標 android.software.verified_boot。
  • [C-1-2] 必須在每次開機序列中執行驗證。
  • [C-1-3] 必須從信任根源的不可變硬體金鑰開始驗證，並一直到系統分區。
  • [C-1-4] 必須實作各個驗證階段，在執行下一個階段的程式碼前，先檢查下個階段中所有位元的完整性和真實性。
  • [C-1-5] 請務必使用驗證演算法，且其強度與 NIST 目前建議的雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 相當。
  • [C-1-6] 系統驗證失敗時，除非使用者同意嘗試啟動，否則絕對不允許啟動程序完成，在這種情況下，絕對不得使用任何未經驗證的儲存空間區塊中的資料。
  • [C-1-7] 除非使用者明確解鎖 Bootloader，否則不得修改裝置上的已驗證分區。
  • [C-1-8] 必須使用防竄改儲存空間：用於儲存是否已解鎖啟動載入程式。防竄改儲存空間是指引導程式可偵測儲存空間是否遭到 Android 內部竄改。
  • [C-1-9] 必須在使用者使用裝置時提示，並要求使用者實際確認，才允許從系統啟動載入程式鎖定模式切換至系統啟動載入程式解鎖模式。
  • [C-1-10] 必須針對 Android 使用的分區 (例如啟動、系統分區) 實作回溯保護機制，並使用防竄改儲存空間來儲存用於判斷允許的最低 OS 版本的中繼資料。
  • [C-1-11] 必須依照 9.12 的規定，在解鎖和鎖定系統啟動載入程式時，安全地清除所有使用者資料。「資料刪除」(包括 userdata 分割區和任何 NVRAM 空間)。

Android 15 的新規定上路了

  • [C-SR-1] 如果裝置中有多個獨立晶片 (例如無線電、專用影像處理器)，強烈建議您在啟動時驗證每個晶片的啟動程序。

  • [C-1-14] 對於系統設定中列為 require-strict-signature 的許可清單套件，每次啟動時都必須至少驗證一次簽章。

新規定結束

  • [C-SR-2] 強烈建議您使用根源於受驗證開機程序保護的分區的信任鏈結，驗證所有特權應用程式 APK 檔案。
  • [C-SR-3] 強烈建議您在執行任何由特權應用程式從 APK 檔案外部載入的可執行項目 (例如動態載入的程式碼或編譯的程式碼) 之前，先驗證這些項目，或強烈建議您完全不要執行這些項目。
  • 應針對任何具有持續性韌體的元件 (例如數據機、相機) 實作復原保護機制，並應使用防竄改儲存空間來儲存用於判斷允許的最低版本的結構化資料。

Android 15 的新規定上路了

如果裝置實作已推出，但在較舊版本的 Android 上不支援 C-1-8 至 C-1-11，且無法透過系統軟體更新新增對這些規定的支援，則可能會免除這些規定。

新規定結束

上游 Android 開放原始碼計畫在 external/avb/ 存放區中提供此功能的首選實作方式，可整合至用於載入 Android 的系統啟動載入程式。

如果裝置實作功能能夠逐頁驗證檔案內容，則會：

  • [C-2-1] 支援以密碼編譯方式驗證檔案內容，而無須讀取整個檔案。

  • [C-2-2] 如未依照上述 [C-2-1] 驗證讀取內容，則不得允許受保護檔案的讀取要求成功。

  • [C-2-4] 針對已啟用的檔案，必須以 O(1) 的時間回傳檔案總和檢查碼。

如果裝置實作功能已推出，但無法在舊版 Android 上使用信任金鑰驗證檔案內容，且無法透過系統軟體更新新增對這項功能的支援，則可能不受這項規定限制。上游 Android 開放原始碼專案提供這項功能的偏好實作方式，以 Linux 核心的 fs-verity 功能為基礎。

Android 15 的新規定上路了

裝置實作方式：

如果裝置實作項目支援 Android Protected Confirmation API，則會：

  • [C-3-1] 必須為 ConfirmationPrompt.isSupported() API 回報 true。

  • [C-3-2] 務必確保在 Android 作業系統 (包括其核心) 中執行的程式碼 (無論是否為惡意程式) 都無法在未經使用者互動情況下產生正面回應。

  • [C-3-3] 必須確保使用者能夠查看並核准提示訊息，即使 Android 作業系統 (包括核心) 遭到入侵也不例外。

新規定結束

9.11. 金鑰和憑證

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在容器中，並透過 KeyChain API 或 KeyStore API 在加密編譯作業中使用這些金鑰。裝置實作方式：

  • [C-0-1] 至少必須允許匯入或產生 8,192 個金鑰。
  • [C-0-2] 鎖定螢幕驗證功能必須在失敗嘗試之間實施時間間隔。以 n 為失敗嘗試次數，如果 9 < n < 30，時間間隔必須至少為 30 秒。如果 n > 29，時間間隔值必須至少為 30*2^floor((n-30)/10)) 秒，或至少 24 小時 (以較小者為準)。
  • 不應限制可產生的鍵數量。

當裝置實作支援安全的螢幕鎖定功能時，會執行以下操作：

  • [C-1-1] 必須使用獨立的執行環境備份 KeyStore 實作。
  • [C-1-2] 必須實作 RSA、AES、ECDSA、ECDH (如果支援 IKeyMintDevice)、3DES 和 HMAC 密碼編譯演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊函式，才能在與核心以上層級執行的程式碼安全隔離的區域中，妥善支援 Android Keystore 系統支援的演算法。安全隔離功能必須封鎖所有潛在機制，以免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 使用 Trusty 實作項目來滿足這項要求，但其他以 ARM TrustZone 為基礎的解決方案，或第三方審查的安全實作項目，也是適當的虛擬機器人隔離方式。
  • [C-1-3] 必須在隔離的執行環境中執行螢幕鎖定畫面驗證，且只有在成功時，才允許使用與驗證綁定的金鑰。螢幕鎖定憑證必須以只允許獨立執行環境執行螢幕鎖定驗證的方式儲存。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。

Android 15 的新規定上路了

  • [C-1-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業是在安全硬體中執行。認證簽署金鑰必須 在足夠多裝置之間共用，才能避免金鑰 遭到禁止，並用於永久裝置 ID。

    注意：如要符合這項規定，您必須針對特定 SKU 共用相同的認證金鑰，除非特定 SKU 的產量至少達到 100,000 個。如果產生超過 100,000 個 SKU 單位，則每個 100,000 個單位的組合可能會使用不同的鍵。或者，您也可以使用遠端金鑰佈建解決方案，為裝置佈建短期認證金鑰。

新規定結束

請注意，如果裝置實作已在較舊的 Android 版本上推出，則該裝置不必符合要求，即不必具備由隔離執行環境支援的 KeyStore，也不必支援金鑰認證，除非該裝置宣告 android.hardware.fingerprint 功能，而該功能需要由隔離執行環境支援的 KeyStore。

  • [C-1-5] 您必須允許使用者選擇休眠逾時時間，以便從解鎖狀態切換為鎖定狀態，最短逾時時間不得超過 15 秒。汽車裝置會在主機關閉或使用者切換時鎖定螢幕，因此不應有休眠逾時設定。
  • [C-1-6] 必須支援下列其中一種：
    • IKeymasterDevice 3.0
    • IKeymasterDevice 4.0
    • IKeymasterDevice 4.1
    • IKeyMintDevice 1 版，或
    • IKeyMintDevice 2.0 版。
  • [C-SR-1] 強烈建議支援 IKeyMintDevice 1 版。

9.11.1. 安全的螢幕鎖定、驗證和虛擬裝置

AOSP 實作項目採用分層驗證模式，其中以知識工廠為基礎的主要驗證作業可由次要強大生物特徵辨識或較弱的第三方模式提供支援。

裝置實作方式：

  • [C-SR-1] 強烈建議您只將下列其中一種設為主要驗證方法：

    • 數字 PIN 碼
    • 英數密碼

    • 在 3x3 點的格狀圖上滑動

      請注意，上述驗證方法是本文中建議的主要驗證方法。

  • [C-0-1] 必須限制主要驗證失敗的嘗試次數。

  • [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] 必須提供備用機制，以便使用建議的主要驗證方法之一，該方法必須以已知的密鑰為基礎。
  • [C-4-3] 必須停用，且僅允許建議的主要驗證機制解鎖螢幕，前提是裝置政策控制器 (DPC) 應用程式已透過呼叫 DevicePolicyManager.setKeyguardDisabledFeatures() 方法，搭配任何相關聯的生物特徵辨識旗標 (即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS) 設定 Keyguard 功能政策。

如果生物特徵辨識驗證方法不符合 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] 必須加密 TrustAgentService.addEscrowToken() 新增的所有已儲存權杖。
  • [C-7-5] 請勿將加密金鑰或擔保金鑰權杖儲存在使用金鑰的裝置上。舉例來說，使用者可以透過手機上的金鑰，解鎖電視上的使用者帳戶。對於 Automotive 裝置，系統不允許將分期付款保證金代碼儲存在車輛的任何部分。
  • [C-7-6] 必須先向使用者說明安全性影響，才能啟用分層保管權杖來解密資料儲存空間。
  • [C-7-7] 必須提供備用機制，以便使用建議的主要驗證方法。
  • [C-7-9] 除非使用者安全 (例如駕駛人分心) 有疑慮，否則使用者必須接受挑戰，採用 7.3.10 節 [C-1-7] 和 [C-1-8] 所述的其中一種建議主要驗證方法 (例如 PIN 碼、圖形密碼、密碼)。
  • [C-7-10] 不得視為安全的鎖定畫面，且必須遵循下方 C-8 所列的限制。
  • [C-7-11] 絕對不允許主要個人裝置 (例如手持裝置) 上的 TrustAgent 解鎖裝置，且只能將已解鎖的裝置維持在解鎖狀態，最多 4 小時。AOSP 中 TrustManagerService 的預設實作方式符合這項規定。
  • [C-7-12] 必須使用加密編譯安全 (例如 UKEY2) 通訊管道，將擔保憑證從儲存裝置傳遞至目標裝置。

如果裝置實作內容會新增或修改驗證方法，以解鎖非安全的螢幕鎖定畫面，並使用新的驗證方法解鎖鍵盤護照：

如果裝置實作允許應用程式建立次要虛擬顯示器，但不支援相關聯的輸入事件 (例如透過 VirtualDeviceManager)，則會發生以下情況：

  • [C-9-1] 必須在裝置的預設螢幕鎖定時鎖定這些次要虛擬螢幕，並在裝置的預設螢幕解鎖時解鎖這些次要虛擬螢幕。

如果裝置實作可讓應用程式建立次要虛擬顯示器，並支援相關聯的輸入事件 (例如透過 VirtualDeviceManager)，則會發生以下情況：

  • [C-10-1] 必須支援每個虛擬裝置的獨立鎖定狀態
  • [C-10-2] 必須在閒置時間到期時斷開所有虛擬裝置
  • [C-10-3] 必須有閒置逾時時間
  • [C-10-4] 使用者啟動鎖定功能時，必須鎖定所有畫面，包括透過手持裝置所需的鎖定使用者操作選項 (請參閱第 2.2.5 節 [9.11/H-1-2])
  • [C-10-5] 每位使用者都必須有個別的虛擬裝置執行個體

Android 15 的新規定上路了

  • [C-10-6] 必須在 DevicePolicyManager.setNearbyAppStreamingPolicy 指出應用程式串流時，透過 VirtualDeviceManager 停用建立相關聯輸入事件的功能。

新規定結束

Android 15 的新規定上路了

  • [C-10-7] 必須：
    • 停用剪貼簿使用權
    • 為每部支援剪貼簿的裝置啟用獨立的剪貼簿

  • [C-10-7] 必須為每部虛擬裝置使用專屬的剪貼簿 (或停用虛擬裝置的剪貼簿)

新規定結束

  • [C-10-11] 必須在虛擬裝置上停用驗證 UI，包括知識要素輸入和生物特徵提示

Android 15 的新規定上路了

  • [C-10-12] 必須限制從虛擬裝置啟動的意圖，僅顯示在相同的虛擬裝置上

新規定結束

  • [C-10-13] 請勿使用虛擬裝置鎖定狀態，做為使用者透過 Android KeyStore 系統進行驗證授權的依據。請參閱 KeyGenParameterSpec.Builder.setUserAuthentication*。

Android 15 的新規定上路了

  • [C-10-14] 如果裝置實作共用剪貼簿，則必須先提供使用者操作提示，讓使用者在實體和虛擬裝置之間分享剪貼簿資料。
  • [C-10-15] 跨裝置存取剪貼簿資料時，必須顯示通知，且必須在從初始分享時間起算的一分鐘後，讓內容無法存取。

新規定結束

當裝置實作允許使用者將主要驗證知識要素從來源裝置轉移至目標裝置時 (例如在目標裝置的初始設定中)，會發生以下情況：

  • [C-11-1] 從來源裝置傳輸至目標裝置時，必須使用類似於 Google Cloud 密鑰保管庫服務安全白皮書中所述的保護保證來加密知識因素，以免知識因素遭到遠端解密，或用於遠端解鎖任何裝置。
  • [C-11-2] 在來源裝置上，必須先要求使用者確認來源裝置的知識因子，再將知識因子轉移至目標裝置。
  • [C-11-3] 在缺少任何已設定主要驗證知識要素的目標裝置上，必須先要求使用者在目標裝置上確認已轉移的知識要素，再將該知識要素設為目標裝置的主要驗證知識要素，並提供從來源裝置轉移的任何資料。

如果裝置實作具有安全的鎖定畫面，且包含一或多個信任服務代理程式，這些服務代理程式會使用 FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 標記呼叫 TrustAgentService.grantTrust() 系統 API，並執行以下操作：

  • [C-12-1] 只有在連線至附近實體裝置 (該裝置有自己的鎖定畫面)，且使用者已透過該鎖定畫面驗證身分時，才應呼叫 grantTrust() 並加上標記。使用者解鎖一次後，鄰近裝置可使用手腕或人體感測機制，滿足使用者驗證要求。
  • [C-12-2] 螢幕關閉 (例如按下按鈕或顯示時間逾時) 且 TrustAgent 未撤銷信任時，裝置實作必須處於 TrustState.TRUSTABLE 狀態。AOSP 符合這項規定。
  • [C-12-3] 只有在 TrustAgent 仍根據 C-12-1 的規定授予信任時，才可將裝置從 TrustState.TRUSTABLE 移至 TrustState.TRUSTED 狀態。
  • [C-12-4] 必須呼叫 TrustManagerService.revokeTrust()
    • 授予信任權後最多 24 小時後，或
    • 閒置 8 小時後，或
    • 如果實作項目未使用 [C-12-5] 中定義的加密編譯安全性和精確的測距功能，當與附近實體裝置的基礎連線中斷時，就會發生此問題。
  • [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 中繼資料的活動，以免在虛擬裝置上啟動。

Android 15 新規定生效

  • [C-13-9] 必須封鎖活動，這些活動未明確啟用串流功能，且表示會顯示敏感內容，包括透過 SurfaceView#setSecure、 和FLAG_SECURE，或 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS，在虛擬裝置上啟動。

新規定結束

如果裝置實作項目透過 DeviceStateManager 支援個別的顯示器電源狀態，且透過 KeyguardDisplayManager 支援個別的顯示器鎖定狀態，則：

  • [C-SR-2] 強烈建議您使用符合第 9.11.1 節所定義的憑證，或是符合第 7.3.10 節所定義的至少第 1 級規格生物特徵辨識系統，以便透過預設裝置螢幕獨立解鎖。
  • [C-SR-3] 強烈建議透過定義的顯示器逾時時間限制單獨的顯示器解鎖功能。
  • [C-SR-4] 強烈建議允許使用者透過主要手持裝置的鎖定功能，全域鎖定所有螢幕。

9.11.2. 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] 必須提供專用的安全硬體，用於備份金鑰庫和安全的使用者驗證機制。專用安全硬體也可用於其他用途。

  • [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] 的規定，裝置實作項目必須：

Android 15 的新規定上路了

新規定結束

  • [C-1-11] 必須納入經國家認證測試實驗室評估的韌體，並根據Common Criteria Application of Attack Potential to Smartcards 評估高攻擊潛在漏洞。
  • [C-SR-2] 強烈建議納入使用安全目標評估的硬體，評估等級為 5 (EAL)，並由 AVA_VAN.5 加強。EAL 5 認證很可能會成為日後版本的必要條件。
  • [C-SR-3] 強烈建議您提供內部人攻擊防禦機制 (IAR)，也就是說，如果內部人員有權存取韌體簽署金鑰，就無法產生會導致 StrongBox 洩漏機密資料的韌體，以便繞過功能安全性要求，或以其他方式啟用機密使用者資料的存取權。建議實作 IAR 的方式，是在透過 IAuthSecret HAL 提供主要使用者密碼時，允許韌體更新。

9.11.3. Identity Credential

您可以透過在 android.security.identity.* 套件中實作所有 API，定義及建立身分憑證系統。這些 API 可讓應用程式開發人員儲存及擷取使用者身分證件。裝置實作方式：

  • [C-SR-1] 強烈建議導入身分憑證系統。

如果裝置實作導入身分憑證系統，則會執行以下操作：

  • [C-1-1] 對於 IdentityCredentialStore#getInstance() 方法，必須傳回非空值。

  • [C-1-2] 必須在與核心以上層級執行的程式碼安全隔離的區域中，使用與信任應用程式通訊的程式碼，實作身分憑證系統 (例如 android.security.identity.* API)。安全隔離功能必須封鎖所有潛在機制，以免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 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] 當主要使用者的裝置政策控制器應用程式呼叫 DevicePolicyManager.wipeData() API 時，必須觸發上述「工廠資料重設」程序。
  • 可提供快速資料清除選項，只執行邏輯資料擦除作業。

9.13. 安全啟動模式

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

裝置實作方式如下：

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

如果裝置實作安全啟動模式，則會執行以下操作：

  • [C-1-1] 必須為使用者提供進入安全啟動模式的選項，且該選項不會受到裝置上安裝的第三方應用程式影響，但如果第三方應用程式是裝置政策控制器，且已將 UserManager.DISALLOW_SAFE_BOOT 標記設為 true，則不在此限。

  • [C-1-2] 必須讓使用者能夠在安全模式下解除安裝任何第三方應用程式。

  • 應為使用者提供選項，讓他們透過與一般開機不同的工作流程，從開機選單進入安全模式。

9.14. 汽車車輛系統隔離

Android Automotive 裝置應透過 車輛 HAL，透過 CAN 匯流排等車輛網路傳送及接收訊息，與重要車輛子系統交換資料。

您可以實作 Android 架構層以下的安全性功能，防止與這些子系統的惡意或非預期互動，藉此保護資料交換機制。

9.15. 訂閱方案

「訂閱方案」是指行動電信業者透過 SubscriptionManager.setSubscriptionPlans() 提供的帳單關係方案詳細資料。

所有裝置實作方式：

  • [C-0-1] 必須將訂閱方案傳回給最初提供這些方案的行動電信業者應用程式。
  • [C-0-2] 不得從遠端備份或上傳訂閱方案。
  • [C-0-3] 僅允許目前提供有效訂閱方案的行動電信業者應用程式，提供 SubscriptionManager.setSubscriptionOverrideCongested() 等覆寫值。

9.16。應用程式資料遷移

如果裝置實作功能可將資料從裝置遷移至另一部裝置，且不會將複製的應用程式資料限制為應用程式開發人員透過資訊清單中的 android:fullBackupContent 屬性所設定的內容，則會發生以下情況：

  • [C-1-1] 不得從使用者未設定主要驗證機制的裝置，啟動應用程式資料傳輸作業，如 9.11.1 安全鎖定畫面和驗證機制所述。
  • [C-1-2] 必須在安全無虞的情況下，確認來源裝置上的主驗證，並確認使用者是否有意在任何資料傳輸前，複製來源裝置上的資料。
  • [C-1-3] 必須使用安全金鑰認證，確保裝置對裝置遷移作業中的來源裝置和目標裝置都是合法的 Android 裝置，且具有已鎖定的系統啟動載入程式。
  • [C-1-4] 請務必只將應用程式資料遷移至目標裝置上的同一個應用程式，且套件名稱和簽署憑證也必須相同。
  • [C-1-5] 設定選單中必須顯示，來源裝置已透過裝置間資料遷移功能遷移資料。使用者不應能夠移除這項指示。

9.17. Android 虛擬化架構

Android 15 的新規定上路了

Android 虛擬化架構 (AVF) API (android.system.virtualmachine.*) 可讓應用程式建立裝置端虛擬機器 (VM)、受保護的 VM (pVM) 和非受保護的 VM (non-pVM)，並將原生二進位檔載入並執行為酬載。

如果裝置實作將 FEATURE_VIRTUALIZATION_FRAMEWORK 設為 true，則會發生以下情況：

  • [C-1-1] 必須確保 android.system.virtualmachine.VirtualMachineManager.getCapabilities() 會傳回下列其中一個值：
    • CAPABILITY_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

新規定結束

10. 軟體相容性測試

裝置實作項目必須通過本節所述的所有測試。不過，請注意，沒有任何軟體測試套件是完全全面的。因此，我們強烈建議裝置實作者盡可能減少對 Android 參考和偏好實作的變更次數，這些實作方式可從 Android 開放原始碼計畫取得。這麼做可盡量降低引入錯誤的風險，避免出現需要重做及潛在裝置更新的不相容性問題。

10.1. 相容性測試套件

裝置實作方式：

  • [C-0-1] 必須使用裝置上的最終發布軟體，通過 Android 相容性測試套件 (CTS) (可從 Android 開放原始碼計畫取得) 的測試。

  • [C-0-2] 在 CTS 中出現模糊情況，或任何參考原始碼的部分重新實作時，一律須確保相容性。

CTS 設計用於在實際裝置上執行。和任何軟體一樣，CTS 本身可能也會含有錯誤。CTS 的版本會與此相容性定義獨立運作，且 Android 15 可能會發布多個 CTS 修訂版本。

裝置實作方式：

  • [C-0-3] 必須通過裝置軟體完成時可用的最新 CTS 版本。

  • 應盡可能使用 Android 開放原始碼樹狀結構中的參考實作項目。

10.2. CTS 驗證器

CTS 驗證器包含在相容性測試套件中，並由人工操作員執行，用於測試自動化系統無法測試的功能，例如相機和感應器的正確運作。

裝置實作方式：

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

CTS Verifier 可測試多種硬體，包括部分選用硬體。

裝置實作方式：

  • [C-0-2] 必須通過所有硬體測試；舉例來說，如果裝置有加速計，則必須在 CTS Verifier 中正確執行加速計測試案例。

針對這份相容性定義文件中標示為選用功能的測試案例，您可以選擇略過或省略。

  • [C-0-2] 如上所述，每部裝置和每個版本都必須正確執行 CTS 驗證工具。不過，由於許多版本都非常相似，因此在僅有細微差異的版本上，裝置實作者不應明確執行 CTS 驗證工具。具體來說，如果裝置實作內容與通過 CTS Verifier 的實作內容僅在所包含的語言代碼、品牌等方面有所差異，則可省略 CTS Verifier 測試。

11. 可更新軟體

  • [C-0-1] 裝置實作必須包含取代整個系統軟體的機制。這項機制不需要執行「即時」升級，也就是說，可能需要重新啟動裝置。只要能取代裝置上預先安裝的軟體，您可以使用任何方法。舉例來說，下列任何一種方法都能滿足這項要求：

    • 透過重新啟動進行離線更新的「無線更新 (OTA)」。
    • 透過主機電腦的 USB 連線進行「連線」更新。
    • 透過重新啟動和從可移除儲存空間的檔案更新，進行「離線」更新。

  • [C-0-2] 使用的更新機制必須支援不清除使用者資料的更新作業。也就是說，更新機制必須保留應用程式私人資料和應用程式共用資料。請注意，上游 Android 軟體包含符合此需求的更新機制。

  • [C-0-3] 整個更新檔案必須經過簽署，且裝置端更新機制必須根據儲存在裝置上的公開金鑰驗證更新檔案和簽章。

  • [C-SR-1] 強烈建議使用 SHA-256 對更新內容進行雜湊處理，並使用 ECDSA NIST P-256 驗證雜湊值與公開金鑰的對應關係。

如果裝置實作項目支援無限量數據連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，則這些裝置會：

  • [C-1-1] 必須支援透過重新啟動進行離線更新的 OTA 下載作業。

裝置實作項目應驗證系統映像檔與 OTA 後的預期結果是否完全相同。自 Android 5.1 版起新增的源端 Android 開放原始碼計畫中的區塊式 OTA 實作，可滿足這項需求。

此外，裝置實作也應支援 A/B 系統更新。AOSP 使用啟動控制 HAL 實作這項功能。

如果在裝置推出後，但在與 Android 相容性團隊協商後判斷的合理產品壽命期間內，發現裝置實作有錯誤，導致第三方應用程式的相容性受到影響，請採取以下行動：

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

Android 包含多項功能，可讓裝置擁有者應用程式 (如有) 控制系統更新的安裝作業。如果裝置的系統更新子系統回報 android.software.device_admin，則會發生以下情況：

12. 文件變更記錄

如要查看本版本相容性定義的變更摘要，請參閱以下說明：

13. 與我們聯絡

您可以加入 Android 相容性論壇，提出疑問或提出您認為文件未涵蓋的任何問題。