Android 15 相容性定義

1. 簡介

本文件列舉出裝置需要符合哪些規範。 可與 Android 15 相容

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

本文件使用情境為「裝置實作器」或「實作器」是人物 或機構開發採用 Android 的 硬體/軟體解決方案 15.「裝置導入」或「實作」是 硬體/軟體解決方案

符合 Android 15 標準 導入方式「必須」符合本相容性說明 定義，包括透過參考資料彙整的所有文件。

這項定義或說明中描述的軟體測試 區段 10 表示靜音、不明確或 不完整，裝置實作人員需負責確保 與現行實作的相容性

因此，Android 開放原始碼計畫 是 Android 的參考與偏好實作。裝置 強烈建議實作者根據 在「上游」您可以透過 Android 開放原始碼計畫。雖然部分元件可以假設 替換成其他實作方式，我們強烈建議您不要 務必遵循這個做法，因為通過軟體測試 變得更困難實作人員有責任 與標準 Android 實作項目的行為相容性，包括 以及 Compatibility Test Suite 以外的資源最後請注意 本文件明確禁止替代和修改。

本文件所連結的許多資源 而且運作方式與 相關資訊適用情況 定義或 Compatibility Test Suite 不同意 SDK 說明文件，系統會將 SDK 說明文件視為具有公信力。任何技術性問題 請參閱這份文件所連結資源中提供的詳細資料 才會納入此相容性定義中。

1.1 文件結構

1.1.1.各裝置類型的規定

第 2 節包含所有適用於 指定任一種裝置類型。第 2 節的每個子節都是 是專門針對特定類型的裝置所設計的

所有其他規定適用於所有 Android 裝置 請參閱第 2 節後的區段。 這些需求稱為「核心需求」。

1.1.2.規定 ID

系統會針對「必須」的規定指派要求 ID。

  • 一組 ID 僅用於「必須」的規定。
  • 強烈建議的規定會標示為 [SR]，但尚未指派 ID。
  • ID 由以下元素組成：裝置類型 ID - 條件 ID - 規定 ID (例如 C-0-1)。

每個 ID 的定義如下：

  • 裝置類型 ID (詳情請參閱2.裝置類型)
    • C：核心 (適用於所有 Android 裝置的實作規範)
    • H：Android 手持裝置
    • T：Android 電視裝置
    • A：Android Automotive 實作
    • W：Android Watch 實作
    • 分頁：Android 平板電腦實作
  • 條件 ID
    • 當條件為無條件時，這個 ID 會設為 0。
    • 如果條件為條件式，系統會將 1 指派給第 1 次 相同區段內設有條件，且數字的遞增單位為 1， 相同的裝置類型。
  • 規定 ID
    • 這個 ID 從 1 開始，並在相同區段內以 1 遞增， 相同的條件

1.1.3.第 2 節的規定 ID

第 2 節的要求 ID 包含兩個部分。第一個 對應上述的區段 ID。第二個部分代表 板型規格和特定板型規格的專屬規定。

部分 ID，後面接著上述規定 ID。

  • 第 2 部分的 ID 包含以下項目： 專區 ID / 裝置類型 ID - 條件 ID - 要求 ID (例如 7.4.3/A-0-1)。

2. 裝置類型

Android 開放原始碼計畫提供軟體堆疊， 用於各種裝置類型和板型規格為了支援裝置安全性 軟體堆疊，包括任何替代的 OS 或替代核心 應在安全環境中執行，才能如上所述 。目前有幾種裝置類型 一個擁有相對成熟的應用程式發布生態系統。

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

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

2.1 裝置設定

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

2.2. 手持裝置需求

Android 手持裝置是指 Android 裝置實作， 通常用來在手持方式使用，例如 mp3 播放器、手機 平板電腦。

如果 Android 裝置的實作方式符合所有 符合以下條件：

  • 請備妥可提供行動用的電源 (例如電池)。
  • 螢幕尺寸符合 4 吋到 8 吋
  • 具備觸控螢幕輸入介面。

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

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

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

如果手持裝置實作方式透過系統屬性宣告支援 graphics.gpu.profiler.support，他們：

手持裝置實作方式：

  • [7.1.5/H-0-1] 必須支援舊版 應用程式相容模式 (如上游 Android 開放式應用程式所實作) Cloud Build 觸發條件 會在您變更原始碼時自動啟動建構作業也就是說，裝置導入方式「不得」變更觸發條件或 相容模式啟用的門檻，而且「不得」變更 相容性模式本身的行為
  • [7.2.1/H-0-1] 必須提供第三方支援 輸入法編輯器 (IME) 應用程式。
  • [7.2.3/H-0-2] 必須同時傳送一般和長按 返回函式的事件 (KEYCODE_BACK) 移到前景應用程式系統「不得」使用這些事件 且可能是由 Android 裝置以外的地方 (例如外部硬體) 觸發 鍵盤就會接到 Android 裝置上。
  • [7.2.3/H-0-3] 必須提供開啟住家功能 所有提供主畫面的 Android 相容螢幕。
  • [7.2.3/H-0-4] 一律必須提供返回函式 Android 相容螢幕和「最近」函式至少 查看與 Android 相容的螢幕
  • [7.2.4/H-0-1] 必須支援觸控螢幕輸入。
  • [7.2.4/H-SR-1] 強烈建議你推出 使用者選擇的輔助應用程式，也就是 VoiceInteractionService，或是處理 ACTION_ASSIST 的活動 按住 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 前景活動無法處理這些長按事件。
  • [7.3.1/H-SR-1] 強烈建議你加入 3 軸 加速計。

如果手持裝置實作項目包含 3 軸式加速度計，請按照下列步驟操作：

  • [7.3.1/H-1-1] 必須能夠按頻率回報活動 至少 100 Hz。

如果手持裝置導入方式包含 GPS/GNSS 接收器，並回報 透過 android.hardware.location.gps 功能將功能套用至應用程式 旗幟，他們可以：

  • [7.3.3/H-2-1] 務必立即回報 GNSS 測量結果 。
  • [7.3.3/H-2-2] 必須回報 GNSS 虛擬範圍和虛擬範圍 費率，在判斷地點後，在開放天際的環境中顯示 靜息或移動，且每秒小於 0.2 公尺的平方 足以計算出 20 公尺以內且速度 0.2 公尺以內，至少 95% 的時間

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

  • [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] 強烈建議你支援姿勢感應器 自由移動。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [7.4.3/H] 必須納入 藍牙和藍牙 LE。

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

  • [7.4.3/H-SR-1] 強烈建議你提供支援 Bluetooth LE Data Packet Length Extension。

終止新規定

如果裝置支援 Wi-Fi 鄰近感知網路 (NAN) 通訊協定， 正在宣告 PackageManager.FEATURE_WIFI_AWARE 和 Wi-Fi 位置資訊 (Wi-Fi 回合) 行程時間 - RTT) 前，請先宣告 PackageManager.FEATURE_WIFI_RTT，然後：

  • [7.4.2.5/H-1-1] 請務必正確回報此範圍， 介於 68 百分位數 +/-1 公尺 (160 MHz 頻寬) 內 (計算方式為 搭配累積分佈函式)，+/-2 公尺 (80 MHz 頻寬) 第 68 個百分位數，40 MHz 頻寬為 +/-4 公尺，第 68 個百分位數 和 +/-8 公尺 (20 MHz 頻寬，第 68 個百分位數，距離 10) 公分、1 公尺、3 公尺和 5 公尺，透過 WifiRttManager#startRanging Android API。

  • [7.4.2.5/H-SR-1] 強烈建議你回報 範圍準確到 +/-1 公尺 (160 MHz) 頻寬 (90th) 內 百分位數 (根據累計分佈函式計算)，+/-2 公尺 (80 MHz 頻寬，第 90 個百分位數)，+/-4 公尺 (40 MHz) 和 20 MHz 頻寬的 +/-8 公尺頻寬 距離 10 公分的第 90 個百分位數，透過 WifiRttManager#startRanging Android API。

我們強烈建議您按照 所在地校正。

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

  • [7.4.3/H-1-3] 必須測量並補償 Rx 調整，確保 BLE RSSI 的中位數是 -50dBm +/-15 分貝，距離 參考裝置 (傳輸至 ADVERTISE_TX_POWER_HIGH)
  • [7.4.3/H-1-4] 必須測量並補償 Tx 調整，確保 BLE RSSI 的中位數為 -50dBm +/-15 dB 參考裝置定位為 1 公尺，且傳輸至 ADVERTISE_TX_POWER_HIGH。

如果手持裝置實作項目包含列出清單的邏輯相機裝置 功能 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA、 他們會：

  • [7.5.4/H-1-1] 預設必須符合一般視野 (FOV) 必須介於 50 和 度。

手持裝置實作方式：

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

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

  • [7.6.1/H-1-1] 核心的可用記憶體 如果預設螢幕使用 framebuffer，則使用者空間不得小於 416 MB 最高可達 qHD (例如 FWVGA)。

  • [7.6.1/H-2-1] 核心的可用記憶體 如果預設螢幕使用 framebuffer，則使用者空間不得小於 592 MB 解析度最高為 HD+ (例如 HD、WSVGA)。

  • [7.6.1/H-3-1] 核心的可用記憶體 如果預設螢幕使用 framebuffer，則使用者空間不得小於 896 MB 最高解析度最高 FHD (例如 WSXGA+)。

  • [7.6.1/H-4-1] 核心的可用記憶體 假如預設顯示器會使用 1,344 MB，使用者空間 最高等級為 QHD (例如 QWXGA)。

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

  • [7.6.1/H-5-1] 核心的可用記憶體 以及使用者空間 如果預設顯示螢幕採用 framebuffer 解析度，解析度至少為 816 MB 至 qHD (例如 FWVGA)。

  • [7.6.1/H-6-1] 核心的可用記憶體 且使用者空間必須至少為 如果預設螢幕採用高達 HD+ 的影格緩衝區解析度，則為 944 MB 例如 HD、WSVGA。

  • [7.6.1/H-7-1] 核心的可用記憶體 且使用者空間必須至少為 如果預設螢幕採用最高 FHD 的 framebuffer 解析度，1280 MB (例如 WSXGA+)。

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

請注意，「核心和使用者空間可用的記憶體」以上是指 所提供的記憶體空間 無線電、影片等非核心的 控管裝置導入方式

如果手持裝置實作的記憶體小於或等於 1 GB 提供給核心和使用者空間使用，具有以下特性：

  • [7.6.1/H-9-1] 必須聲明功能標記 android.hardware.ram.low。
  • [7.6.1/H-9-2] 至少需要 1.1 GB 適用於應用程式的非揮發性儲存空間 私人資料（又稱為「/data」分區)。

如果手持裝置實作包含超過 1 GB 的可用記憶體 加入核心和使用者空間後，就可以：

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

如果手持裝置導入方式大於或等於 2 GB 以及核心和使用者空間可用的記憶體少於 4 GB，這兩者包括：

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

如果手持裝置實作項目包含少於 2 GB 的可用記憶體 進行以下操作：

  • [7.6.1/H-1-1] 只能支援單一 ABI (僅限 64 位元或 32 位元) )。

手持裝置實作方式：

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果手持裝置實作包含 USB 連接埠 支援 並搭配控制器 過週邊裝置模式時，它們會：

  • [7.7.1/H-1-1] 必須實作 Android Open Accessory (AOA) 也能使用 Google Cloud CLI 或 Compute Engine 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] 必須加入申請書 實作可透過 VR 啟用的 android.service.vr.VrListenerService 透過 android.app.Activity#setVrModeEnabled 部署應用程式。

如果手持裝置實作在主機中加入一或多個 USB-C 連接埠 模式和實作 (USB 音訊類別)，再加上 第 7.7.2 節，藉此：

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

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

  • [7.8.2.2/H-2-1] 必須具有以下功能：廣播意圖 ACTION_HEADSET_PLUG 「麥克風」將更多的值設為 0。

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

  • [7.8.2.2/H-3-1] 必須具有以下項目的廣播意圖 ACTION_HEADSET_PLUG： 「麥克風」將額外設為 1

當 USB 週邊裝置處於呼叫狀態時，呼叫 API AudioManager.getDevices() 是否已連線：

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

  • [7.8.2.2/H-4-2] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_HEADSET，以及 isSink() 角色 (如果 USB 音訊端子) 類型欄位大小為 0x0402

  • [7.8.2.2/H-4-3] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_HEADSET，以及 isSource() 角色 (如果 USB 音訊端子) 類型欄位大小為 0x0402

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

  • [7.8.2.2/H-4-5] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_DEVICE 和 isSource() 角色 (如果 USB 音訊端子) 類型欄位大小為 0x604

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

  • [7.8.2.2/H-4-7] 必須列出一種裝置類型 AudioDeviceInfo.TYPE_USB_DEVICE 和 isSource() 角色 (如果 USB 音訊端子) 類型欄位大小為 0x400

  • [7.8.2.2/H-SR-1] 我們強烈建議在 USB-C 音訊週邊裝置，如要執行 USB 描述元列舉，識別 終端機類型和廣播意圖 ACTION_HEADSET_PLUG 1000 毫秒。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 適用對象 手持裝置實作 android.hardware.audio.output和android.hardware.microphone， 請參閱章節中 RTL 和存留時間的相關規定 5.6。

  • [5.6/H-1-1] 必須具有平均連續來回行程 提供 300 毫秒或 少於 5 次測量，平均絕對偏差小於 5 超過 30 毫秒 下列資料路徑：「揚聲器對麥克風」 3.5 公釐 Loopback Adapter (如果支援)、USB 回送 (如果支援)。

  • [5.6/H-1-2] 「必須」的平均延遲時間 每 300 毫秒 對說話者的音量減少至少 5 次 麥克風資料路徑

終止新規定

線性共振致動器 (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 提供的捷徑 也能使用 Google Cloud CLI 或 Compute Engine API
  • [3.8.1/H-SR-3] 強烈建議你使用 加入預設的啟動器應用程式，為應用程式圖示顯示標記。
  • [3.8.2/H-SR-1] 強烈建議你使用 支援第三方應用程式小工具。
  • [3.8.3/H-0-1] 必須允許第三方 應用程式可透過 Notification 和 NotificationManager API 類別。
  • [3.8.3/H-0-2] 必須支援 RTF 格式 通知。
  • [3.8.3/H-0-3] 必須支援抬頭通知 通知。
  • [3.8.3/H-0-4] 必須包含 通知欄，方便使用者直接控制 (例如 回覆、延後、關閉、封鎖) 透過使用者預設用途通知，例如 您在 Android 開放原始碼計畫中實作的動作按鈕或控制面板。
  • [3.8.3/H-0-5] 必須顯示選項 提供者：RemoteInput.Builder setChoices() 通知欄
  • [3.8.3/H-SR-1] 強烈建議你使用 顯示透過 RemoteInput.Builder setChoices() 提供的第一個選項 且不需任何額外使用者互動。
  • [3.8.3/H-SR-2] 強烈建議你使用 顯示透過 RemoteInput.Builder setChoices() 提供的所有選項 在使用者展開 通知欄。
  • [3.8.3.1/H-SR-1] 強烈建議你使用 顯示適用於Notification.Action.Builder.setContextual的動作 已設為 true，其中會顯示由 Notification.Remoteinput.Builder.setChoices。
  • [3.8.4/H-SR-1] 強烈建議你使用 在裝置上實作助理來處理輔助動作。

如果手持裝置實作支援 MediaStyle 通知 他們會：

  • [3.8.3.1/H-SR-2] 強烈建議你使用 為使用者提供透過 系統 UI，可讓使用者切換可用的媒體 路徑 (例如藍牙裝置和 MediaRouter2Manager) 應用程式發布含有 MediaSession 權杖的 MediaStyle 通知時。

如果裝置實作項目包含最近使用函式瀏覽鍵， 第 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:高 通知。

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

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

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

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

如果手持裝置實作支援 ControlsProviderService敬上 和 Control API 並允許第三方應用程式發布裝置控制項，接著會進行下列動作：

相反地，如果手持裝置並未實作這類控制選項， 他們會：

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

  • [3.8.17/H-1-1] 必須向使用者確認 複製到剪貼簿 (例如「已複製內容」的縮圖或快訊)。 此外，這裡也會指出系統是否會同步處理剪貼簿資料 跨裝置使用 YouTube

手持裝置實作方式：

  • [3.10/H-0-1] 必須支援第三方無障礙設定 免費 Google Cloud 服務
  • [3.10/H-SR-1] 強烈建議預先載入 裝置上的無障礙服務與或超越的功能相等 和 TalkBack 的切換控制功能 (適用於 文字轉語音引擎) 無障礙服務，如同TalkBack 開啟頁面所示 來源專案。
  • [3.11/H-0-1] 必須支援 第三方 TTS 引擎。
  • [3.11/H-SR-1] 極力建議您加入 支援裝置可用語言的 TTS 引擎。
  • [3.13/H-SR-1] 極力建議您加入 快速設定 UI 元件。

如果 Android 手持裝置實作項目宣告 FEATURE_BLUETOOTH 或 FEATURE_WIFI支援，他們：

  • [3.16/H-1-1] 必須支援隨附裝置配對 而不是每個特徵的分數

如果系統以手勢動作的形式提供導覽功能：

  • [7.2.3/H] 主畫面的手勢辨識區域 函式的高度不得大於 。

如果手持裝置實作以手勢形式提供瀏覽功能 從畫面左側或右側邊緣的任何位置：

  • [7.2.3/H-0-1] 導覽函式的手勢區域 每邊的寬度必須小於 40 dp。手勢區域應該是 根據預設，寬度為 24 dp。

如果手持裝置可支援安全螢幕鎖定，且 核心和使用者空間可用的記憶體大小等於或等於 2 GB，這兩者包括：

  • [3.9/H-1-2] 必須透過 android.software.managed_users 功能旗標。

如果 Android 手持裝置實作方式宣告支援相機 android.hardware.camera.any他們：

如果裝置實作的設定應用程式 分割功能 然後再透過活動嵌入功能

如果裝置導入方式允許使用者透過任何形式撥打電話，

2.2.4.效能與功率

  • [8.1/H-0-1] 影格延遲時間一致。 影格延遲不一致或轉譯影格延遲，「不得」發生更多 且每秒影格數通常不超過 1 個
  • [8.1/H-0-2] 使用者介面延遲。 實作裝置必須「必須」的安全性狀態， Android Compatibility Test Suite 定義的 1 萬個清單項目清單 (CTS) 幾乎不會超過 36 秒。
  • [8.1/H-0-3] 工作切換，時間 啟動了多個應用程式， 應用程式啟動後只需不到 1 秒即可。

手持裝置實作方式：

  • [8.2/H-0-1] 必須確保 至少每秒 5 MB 的寫入效能。
  • [8.2/H-0-2] 必須確保隨機寫入 至少每秒 0.5 MB
  • [8.2/H-0-3] 必須確保循序讀取 至少每秒 15 MB 的效能。
  • [8.2/H-0-4] 必須確保隨機讀取 至少每秒 3.5 MB

如果手持裝置實作包含提升裝置效能的功能 或擴充 Android 開放原始碼計畫內含的功能 後，您會發現：

  • [8.3/H-1-1] 必須提供使用者預設用途才能啟用 然後停用省電模式
  • [8.3/H-1-2] 必須為使用者提供顯示空間 所有適用應用程式待命和打盹省電模式的應用程式。

手持裝置實作方式：

  • [8.4/H-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ，以及測試過程中 。
  • [8.4/H-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
  • [8.4/H-0-3] 必須回報 CPU 效能 每段程序的 UID。Android 開放原始碼計畫滿足 要求通過uid_cputime核心模組實作。
  • [8.4/H-0-4] 必須使用 可透過 adb shell dumpsys batterystats 使用 殼層指令給應用程式開發人員。
  • [8.4/H] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式

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

手持裝置實作方式：

  • [8.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。 意圖。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

裝置實作「必須」宣告支援 android.software.credentials和：

  • [9/H-0-2] 必須遵循 android.settings.CREDENTIAL_PROVIDER 意圖 允許選取 Credential Manager 偏好的提供者。 這個提供者會啟用自動填入功能，以及 也會成為儲存新憑證的預設位置 輸入的憑證

  • [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 系統 所在區域的演算法，與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境，包括《數位市場法》上游 Android 開放原始碼 專案 (AOSP) 利用 Trusty 實作項目達成這項規定， ARM TrustZone 解決方案或第三方經過安全審查 可替代實作方式，以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
  • [9.11/H-0-4] 必須執行螢幕鎖定 隔離於隔離執行環境中驗證 成功，請允許使用驗證繫結金鑰。螢幕鎖定畫面 憑證的儲存方式必須僅允許獨立執行 執行螢幕鎖定驗證。上游 Android 開放原始碼專案 總機人員硬體抽象層 (HAL) 和 Trusty 合作，以滿足這項需求

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [9.11/H-0-5] 必須支援金鑰認證 認證簽署金鑰受到安全的硬體保護， 在安全的硬體中執行 「必須」 在以下服務之間共用認證簽署金鑰： 變得足夠的裝置數量，以防止按鍵 禁止 避免當成「永久」使用 裝置 ID 為了符合這項規定，其中一個方法是提供 除非特定 SKU 至少有 10 萬個單位 產生的結果。如果產生的 SKU 超過 100,000 個單位，請採用 每 100,000 個單位可使用 MAY 鍵。

終止新規定

請注意，如果裝置已啟動至較舊的 Android 版本 這類裝置不受具有 KeyStore 的限制 並支援金鑰認證 除非宣告了 android.hardware.fingerprint 功能，而該功能需要 由獨立執行環境支援的 KeyStore。

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

  • [9.11/H-1-1] 必須允許使用者選擇 休眠逾時，也就是從解鎖狀態進入鎖定狀態的時間 則不超過 15 秒。
  • [9.11/H-1-2] 必須提供使用者隱藏的額度 通知以及停用所有驗證形式， 訊息中所述的主要驗證 9.11.1 安全螢幕鎖定。Android 開放原始碼計畫會 都應設為鎖定模式

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

  • [9.11.1/H-1-1] 採用建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 頻率必須每 72 小時超過一次。

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

  • [9.5/H-2-1] 必須支援設有限制的個人資料、 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後，裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。

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

  • [9.5/H-3-1] 不支援受限制功能 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。

如果手持裝置導入方式設為 UserManager.isHeadlessSystemUserMode 給true，他們

  • [9.5/H-4-1] 「不得」提供 eUICC 支援、 以及具備通話功能的 eSIM 卡
  • [9.5/H-4-2] 不得宣告 android.hardware.telephony。

Android 透過 System API VoiceInteractionService 支援 安全啟動字詞偵測功能，偵測不到麥克風存取權 和一律開啟查詢偵測功能，無需麥克風或攝影機 存取指標

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

設定受到限制

受限制的設定會向使用者顯示警示 並請使用者確認以授予權限 符合以下任一條件：

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

針對任何強制執行的權限 相關識別碼：

  • 鬧鐘和提醒：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

這類應用程式標示為「涵蓋的應用程式」符合需求的 找到的結果。

裝置實作方式：

  • [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] 必須僅允許使用者確認，才能啟用受限制的設定 ，瞭解如何從適用應用程式的 AppInfo 頁面取得資訊。 透過 EnhancedConfirmationManager API 呼叫

  • [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
，瞭解如何調查及移除這項存取權。

終止新規定

如果手持裝置實作支援 System API HotwordDetectionService 或其他不含啟動字詞偵測的機制 麥克風存取指標，它們可以：

  • [9.8/H-1-1] 必須確認啟動字詞偵測服務只能傳輸 將資料傳送到系統 (ContentCaptureService) 或由 Google 建立的裝置端語音辨識服務 SpeechRecognizer#createOnDeviceSpeechRecognizer()。
  • [9.8/H-1-2] 必須確認啟動字詞偵測服務只能傳輸 麥克風音訊資料，或從裝置擷取到系統伺服器的資料 HotwordDetectionService API，或透過以下方式執行 ContentCaptureService： ContentCaptureManager API。
  • [9.8/H-1-3] 「請勿」提供長度超過 30 秒的麥克風音訊。 對啟動字詞偵測服務發出的硬體觸發要求。
  • [9.8/H-1-4] 「不得」提供超過 8 秒的緩衝麥克風音訊。 傳送到啟動字詞偵測服務的個別要求。
  • [9.8/H-1-5] 請勿將 30 秒以上的緩衝麥克風音訊提供給 語音互動服務或類似實體
  • [9.8/H-1-6] 不得允許超過 100 個位元組的資料 (不含音訊串流) 才能在每次成功時從啟動字詞偵測服務傳出 啟動字詞搜尋結果。
  • [9.8/H-1-7] 不得傳輸超過 5 位元的資料 。
  • [9.8/H-1-8] 必須允許傳輸啟動字詞中的資料 偵測服務的相關資訊。
  • [9.8/H-1-9] 「不得」允許可供使用者安裝的應用程式提供 啟動字詞偵測服務
  • [9.8/H-1-10] 符合下列條件時，「不得」在 UI 量化資料中顯示麥克風用量： 啟動字詞偵測服務
  • [9.8/H-1-11] 必須記錄每次傳輸中包含的位元組數 啟動字詞偵測服務，以在安全的情況下 研究。
  • [9.8/H-1-12] 必須支援偵錯模式， 以便檢查應用程式 安全研究人員

  • [9.8/H-1-14] 必須顯示上一節所述的麥克風指示 9.8.2：用於將成功的啟動字詞結果傳送至語音 互動服務或類似實體

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

  • [9.8/H-SR-1] 強烈建議使用者在設定 做為啟動字詞偵測服務的供應商

  • [9.8/H-SR-2] 強烈建議禁止傳送 非結構化資料。

  • [9.8/H-SR-3] 強烈建議你重新開始裝載 啟動字詞偵測服務，至少每小時或每 30 次一次 硬體觸發事件 (以先發生者為準)

如果裝置實作項目包含使用 System API 的應用程式 HotwordDetectionService，或是類似機制，用於偵測啟動字詞 麥克風使用指標，應用程式：

  • [9.8/H-2-1] 針對每個啟動字詞，請務必向使用者明確告知 支援。
  • [9.8/H-2-2] 「不得」保留原始音訊資料或衍生的資料 經由啟動字詞偵測服務提交要求
  • [9.8/H-2-3] 「不得」從啟動字詞偵測服務、音訊傳輸 包括能用來重新建構音訊 (整或部分) 的資料 或是與啟動字詞本身無關的音訊內容 ( ContentCaptureService或裝置端語音 識別服務

如果手持裝置實作支援 System API VisualQueryDetectionService 或其他查詢偵測機制 沒有麥克風和/或相機存取權指示，他們可以：

  • [9.8/H-3-1] 必須確認查詢偵測服務只能傳送 將資料傳送到系統，或ContentCaptureService，或裝置端語音 辨識服務 SpeechRecognizer#createOnDeviceSpeechRecognizer())。
  • [9.8/H-3-2] 不得傳送任何音訊或視訊資訊 以外的引數VisualQueryDetectionService，但 ContentCaptureService 或裝置端語音辨識服務
  • [9.8/H-3-3] 當裝置偵測到使用者時，「必須」在系統使用者介面中顯示使用者通知 意圖與數位助理應用程式互動 (例如偵測 透過攝影機與人互動)。
  • [9.8/H-3-4] 必須顯示麥克風指標並顯示偵測到的偵測器 系統在偵測到使用者查詢後，立即在 UI 中顯示使用者查詢。
  • [9.8/H-3-5] 「不得」允許可供使用者安裝的應用程式提供 視覺化查詢偵測服務

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

  • [9.8.2/H-4-1] 發生在以下情況時，必須顯示麥克風指示燈 應用程式正在從麥克風存取音訊資料，但無法存取 只有 HotwordDetectionService 能存取麥克風， SOURCE_HOTWORD、ContentCaptureService，或擁有以下角色的應用程式： 列於第 9.1 節，且 CDD ID [C-4-X]。
  • [9.8.2/H-4-2] 必須顯示近期和使用中清單 應用程式使用麥克風做為傳回的 PermissionManager.getIndicatorAppOpUsageData()，以及任何作者資訊 或是與 Gemini 相關的訊息
  • [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 ID [C-4-X] 的 section 9.1。
  • [9.8.2/H-5-2] 必須顯示最近使用過的應用程式和正在使用的應用程式 PermissionManager.getIndicatorAppOpUsageData() 傳回的相機， 以及所有相關的歸因訊息
  • [9.8.2/H-5-3] 請勿隱藏相機指標的 具有可見使用者介面或直接使用者互動的系統應用程式。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

驗證開機程序是確保裝置軟體完整性的功能。 如果裝置導入方式支援這項功能，就會執行以下動作：

  • [9.10/H-1-1] 必須驗證所有唯讀分區 掛接於 Android 啟動序列期間，以及 VBMeta 摘要 必須在計算時納入所有已驗證的分區。
，瞭解如何調查及移除這項存取權。

終止新規定

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

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

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

終止新規定

2.2.7.手持媒體效能類別

如要瞭解 媒體成效類別

2.2.7.1。媒體

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.U 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.V敬上 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

終止新規定

  • [5.1/H-1-1] 通告硬體視訊解碼器數量上限 可以在任何轉碼器組合中透過 「CodecCapabilities.getMaxSupportedInstances()」和 VideoCapabilities.getSupportedPerformancePoints() 方法。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-2] 必須支援 6 個 8 位元 (SDR) 硬體視訊解碼器執行個體 工作階段 (AVC、HEVC、VP9、AV1 等) 與 3 個工作階段同時進行，速度為 1080p 解析度 (每秒 30 個影格) 和 3 個工作階段 (4K 解析度) Resolution@30fps，除非 AV1。 所有工作階段「不得」超過 1 個影格 且每秒可捨棄的影格速率 AV1 轉碼器只需要支援 1080p 解析度，但仍需要支援 6 個以 1080p30fps 播放的 6 個執行個體。

終止新規定

  • [5.1/H-1-3] 必須通告硬體視訊編碼器的數量上限 可以在任何轉碼器組合中透過 「CodecCapabilities.getMaxSupportedInstances()」和 VideoCapabilities.getSupportedPerformancePoints() 方法。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-4] 必須支援 6 個 8 位元 (SDR) 硬體視訊編碼器的執行個體 工作階段 (AVC、HEVC、VP9、AV1 等) 與 4 個工作階段同時進行，速度為 1080p 解析度@30 fps，以及 2 個工作階段在 4K 解析度 Resolution@30fps，除非 AV1。 所有工作階段「不得」超過 1 個影格 且每秒可捨棄的影格速率 AV1 轉碼器只需要支援 1080p 解析度，但仍然可以使用 可支援 6 個執行個體 (每秒 1080p30)。

終止新規定

  • [5.1/H-1-5] 必須通告硬體視訊編碼器的數量上限， 可以同時在任何轉碼器組合中透過 「CodecCapabilities.getMaxSupportedInstances()」和 VideoCapabilities.getSupportedPerformancePoints() 方法。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-6] 必須支援 6 個 8 位元 (SDR) 硬體視訊解碼器執行個體 以及硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 等) 轉碼器組合與 3 個工作階段 (4K@30 FPS) 同時執行 解析度 (除非是 AV1 格式)，而最多只能有 2 個為編碼器工作階段和 3 個 和 1080p 解析度的工作階段 所有工作階段「不得」超過 1 個影格 且每秒可捨棄的影格速率 AV1 轉碼器只需要支援 1080p 解析度，但仍然可以使用 可支援 6 個執行個體 (每秒 1080p30)。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-19] 必須支援 3 個 10 位元 (HDR) 硬體視訊解碼器執行個體 以及硬體視訊編碼器工作階段 (AVC、HEVC、VP9、AV1 等) 以 4K@30 FPS 的解析度並行執行的轉碼器組合 (除非 AV1) 其中最多 1 個是編碼器工作階段，可設為 RGBA_1010102 輸入格式 (透過 GL 介面提供)。對於 所有工作階段，每邊出現的影格「不得」超過 1 個 第二。由編碼器產生 HDR 中繼資料 如果是由 GL 介面編碼，則不需要。AV1 轉碼器工作階段是 只需要支援 1080p 解析度，即使在這項要求呼叫時 4K。

終止新規定

  • [5.1/H-1-7] 轉碼器初始化延遲時間不得超過 40 毫秒 對所有硬體視訊編碼器而言， 1080p 或更小的影片編碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊錄音初始化。針對 Dolby Vision 轉碼器 初始化延遲時間不得超過 50 毫秒。
  • [5.1/H-1-8] 轉碼器初始化延遲時間不得超過 30 毫秒 在所有音訊編碼器中，128 kbps 或較低的位元率音訊編碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊錄音初始化。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-9] 必須支援 2 個安全硬體視訊解碼器執行個體 工作階段 (AVC、HEVC、VP9、AV1 等) 8 位元 (SDR) 和 8 位元 (SDR) 兩者的解析度均為 4K 解析度@30 fps (除非 AV1 格式) 10 位元 HDR 內容。 所有工作階段「不得」超過 1 個影格 且每秒可捨棄的影格速率 不論是否使用 AV1 轉碼器工作階段，都只需要支援 1080p 解析度 需要 4K 畫質。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-10] 必須支援 3 個不安全的硬體視訊解碼器執行個體 以及 1 個安全硬體視訊解碼器工作階段 任何轉碼器組合中 (共 4 個執行個體) (AVC、HEVC、VP9、AV1 或以上版本) 與 3 個工作階段同時執行，解析度為 4K 解析度@30fps (除非 AV1) 當中包含 1 個安全解碼器工作階段和 1 個 nn-Secure 工作階段 (1080p) Resolution@30fps，其中最多 2 個工作階段可採用 10 位元 HDR 格式。 所有工作階段「不得」超過 1 個影格 且每秒可捨棄的影格速率 不論是否使用 AV1 轉碼器工作階段，都只需要支援 1080p 解析度 需要 4K 畫質。

終止新規定

  • [5.1/H-1-11] 必須為每個硬體 AVC、HEVC、 VP9 或 AV1 解碼器
  • [5.1/H-1-12] 轉碼器初始化延遲時間不得超過 40 毫秒 所有硬體視訊解碼器都適用 1080p 以下的影片解碼工作階段 載入容器時此處載入定義為 1080p 至 720p 的並行 僅使用硬體視訊轉碼器和 1080p 音訊影片播放初始化。針對 Dolby Vision 轉碼器 初始化延遲時間不得超過 50 毫秒。
  • [5.1/H-1-13] 轉碼器初始化延遲時間不得超過 30 毫秒 針對所有音訊解碼器產生 128 kbps 或較低的位元率音訊解碼工作階段 載入。此載入定義是 1080p 至 720p 的並行影片 以及運用硬體視訊轉碼器和 1080p 的 音訊影片播放初始化。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-14] 必須支援 AV1 硬體解碼器 Main 10 (等級 4.1) 以及膠片顆粒 使用膠片顆粒效果對 GPU 組成。

終止新規定

  • [5.1/H-1-15] 至少須有 1 個支援 4K60 的硬體視訊解碼器。
  • [5.1/H-1-16] 至少必須使用 1 個支援 4K60 的硬體視訊編碼器。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

終止新規定

  • [5.3/H-1-1] 「不得」在 10 秒內捨棄超過 1 個影格 (亦即小於 1 影格速率為 0.167%)。
  • [5.3/H-1-2] 影片播放期間「不得」在 10 秒內捨棄超過 1 個影格 在載入 4K 工作階段時，在 60 fps 影片工作階段中解析度會有所變化。
  • [5.6/H-1-1] 在使用 CTS Verifier 的觸覺回饋測試
  • [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 用於目標輸出格式。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.6/H-1-4] 必須支援超過 4 聲道 USB 音訊裝置。 (DJ 控制器會使用這個 ID 試聽歌曲)。

終止新規定

  • [5.6/H-1-5] 必須支援符合等級標準的 MIDI 裝置，並聲明 MIDI 功能旗標。
  • [5.6/H-1-9] 必須支援至少 12 個聲道混音。這表示 能夠以 7.1.4 聲道遮罩開啟音軌， 調整空間，將所有頻道化為立體聲
  • [5.6/H-SR] 強烈建議採用 24 個管道搭配 至少支援 9.1.6 和 22.2 聲道遮罩
  • [5.7/H-1-2] 必須支援 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL 和 。
樣本大小下限 4 MiB
子樣本數量下限 - H264 或 HEVC 32
子樣本數量下限 - VP9 9
子樣本數下限 - AV1 288 號
子樣本緩衝區空間下限 1 MiB
一般加密緩衝區空間下限 500 KiB
並行工作階段數量下限 30
每個工作階段的金鑰數量下限 20
金鑰總數下限 (所有工作階段) 80 號
DRM 金鑰總數下限 (全部) 工作階段) 6
郵件大小 16 KiB
每秒解密影格數 60 fps
  • [5.1/H-1-17] 至少須有 1 個支援 AVIF 的硬體影像解碼器 基準設定檔。
  • [5.1/H-1-18] 必須支援最高 480p 編碼的 AV1 編碼器 解析度高達 30 FPS 和 1 Mbps

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [5.1/H-1-20] 必須支援 Feature_HdrEditing 支援 4K 畫質的裝置 AV1 和 HEVC 編碼器 解析度或相機支援的最大解析度 (以較低者為準)。

終止新規定

  • [5.12/H-SR] 強烈建議你配合 Feature_HdrEditing敬上 內建所有硬體 AV1 和 HEVC 編碼器的功能。
  • [5.12/H-1-2] 必須支援所有硬體 AV1 和 裝置上支援 HEVC 編碼器。
  • [5.12/H-1-3] 必須向 8 和 10 位元的 YUV 紋理樣本
  • [7.1.4/H-1-1] 顯示器時，螢幕畫面上至少須有 6 個硬體重疊圖層 單位 (DPU)，至少有 2 個可顯示 10 位元的影片內容。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.V敬上 代表android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，且包含 支援硬體 AVC 或 HEVC 編碼器：

終止新規定

2.2.7.2。相機

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.U 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.V敬上 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

終止新規定

  • [7.5/H-1-2] 必須使用主要前置鏡頭，解析度須為 至少 600 萬像素，且支援拍攝每秒 1080p@30 FPS 的影片。主要 前置鏡頭是前置鏡頭，且相機 ID 最低。
  • [7.5/H-1-3] 必須支援 android.info.supportedHardwareLevel 資源， 如果是後台主要服務，請至少 FULL，前端則為 LIMITED 以上 相機上
  • [7.5/H-1-4] 必須支援 兩個主要服務：CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME 相機上
  • [7.5/H-1-5] 必須採用 camera2 JPEG 擷取延遲時間 <1,000 名 CTS 鏡頭 PerformanceTest 測得的 1080p 解析度為毫秒 兩台主鏡頭的 ITS 亮度 (300 萬)。
  • [7.5/H-1-6] 必須設定 camera2 啟動延遲時間 (開啟相機即可先行預覽) 頁框) <CTS 鏡頭 PerformanceTest 對 ITS 的影響為 500 毫秒 兩個主鏡頭的亮度 (300 萬)。
  • [7.5/H-1-8] 必須支援 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW 和 android.graphics.ImageFormat.RAW_SENSOR 用於主要後置鏡頭
  • [7.5/H-1-9] 「必須」使用支援 720p 或 1080p 的後置主鏡頭 @ 240fps。
  • [7.5/H-1-10] 必須指定最低 ZOOM_RATIO <1.0 代表主要鏡頭 (如果有的話) 是面向相同方向的超廣角 RGB 相機。
  • [7.5/H-1-11] 「必須」在主要執行個體上實作並行前端串流 相機上
  • [7.5/H-1-12] 必須提供支援 兩個主要服務：CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION 前置和主要後置鏡頭
  • [7.5/H-1-13] 必須支援 LOGICAL_MULTI_CAMERA 功能 用於主要後置鏡頭 (如果超過 1 個 RGB 後置鏡頭) 相機上
  • [7.5/H-1-14] 必須同時支援兩者的 STREAM_USE_CASE 功能 前置和主要後置鏡頭
  • [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) 以及主要相機

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [7.5/H-1-18] 必須為主要後支援 JPEG_R 和 。
  • [7.5/H-1-19] 必須提供支援 CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION 代表 1080p HLG10 最大尺寸為 16:9 的預覽畫面，長寬比為 16:9，支援 720p HLG10 預覽 。 後置鏡頭
  • [7.5/H-1-20] 主要執行個體必須預設輸出 JPEG_R 原生相機應用程式中的後置和主要前置鏡頭。

終止新規定

2.2.7.3.硬體

如果手持裝置實作傳回android.os.Build.VERSION_CODES.U android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.V敬上 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

終止新規定

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [7.1.1.3/H-2-1] 螢幕密度必須至少為 400 dpi 裝置的螢幕寬度 <600 dp。

終止新規定

  • [7.1.1.3/H-3-1] 必須使用支援至少 1000 nit 的 HDR 螢幕

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

終止新規定

2.2.7.4。成效

如果手持裝置實作傳回android.os.Build.VERSION_CODES.U android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.V敬上 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

終止新規定

  • [8.2/H-1-1] 必須確保連續寫入效能至少達到 150 MB。
  • [8.2/H-1-2] 必須確保隨機寫入效能至少達到每秒 10 MB。
  • [8.2/H-1-3] 必須確保連續讀取效能至少達到每秒 250 MB。
  • [8.2/H-1-4] 必須確保隨機讀取效能達到每秒至少 100 MB。
  • [8.2/H-1-5] 必須確保平行循序讀取和寫入效能 1 倍的讀取和寫入效能至少達到 50 MB。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

2.2.7.5。圖形

如果手持裝置實作傳回 android.os.Build.VERSION_CODES.V 對於 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

終止新規定

2.3.電視需求

Android 電視裝置是指在 是一種娛樂介面，可讓使用者存取數位媒體、電影、遊戲、應用程式， 和/或電視直播服務。 使用者介面」)。

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

  • 已提供可遠端控制 顯示螢幕可能離使用者有 10 英尺遠。
  • 內嵌螢幕 (對角線長度大於 24) 吋或加入影片輸出連接埠，例如 VGA、HDMI、DisplayPort 或 無線連接埠

本節其他規定僅適用於 Android 電視裝置實作。

2.3.1.硬體

電視裝置導入方式：

  • [7.2.2/T-0-1] 必須支援 D-Pad。
  • [7.2.3/T-0-1] 必須提供住家和返回 函式。
  • [7.2.3/T-0-2] 必須同時傳送一般和長按 返回函式的事件 (KEYCODE_BACK) 移到前景應用程式
  • [7.2.6.1/T-0-1] 必須支援遊戲 並宣告 android.hardware.gamepad 功能旗標。
  • [7.2.7/T] 應提供遠端控制 使用者可以存取非觸控式瀏覽，以及 核心瀏覽鍵輸入。

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

  • [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] 必須支援外接鏡頭 但不一定總是連上網路

如果電視裝置導入方式是 32 位元：

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

    • 在小螢幕/一般螢幕上，400 dpi 以上
    • 在大螢幕上使用 xhdpi 或更高版本
    • 搭載 tvdpi 以上版本

如果電視裝置導入方式是 64 位元：

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

    • 在小螢幕/一般螢幕上，400 dpi 以上
    • 在大螢幕上使用 xhdpi 或更高版本
    • 搭載 tvdpi 以上版本

請注意，「核心和使用者空間可用的記憶體」以上是指 所提供的記憶體空間 無線電、影片等硬體元件 控制在裝置實作上。

電視裝置導入方式：

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

2.3.2.多媒體

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

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

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

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

電視裝置導入方式：

  • [5.2.2/T-SR-1] 強烈建議你提供支援 以每秒 30 個影格的速度播放 720p 與 1080p 解析度影片的 H.264 編碼。

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

電視裝置實作「必須」支援 MPEG-2 解碼，詳情請見 第 5.3.1 節：標準影片影格速率，且最高和 包括：

  • [5.3.1/T-1-1] HD 高畫質 1080p (每秒 29.97 影格) 主要設定檔
  • [5.3.1/T-1-2] HD 高畫質 1080i，每秒 59.94 影格 主要設定檔他們必須「必須」解除交錯 MPEG-2 影片 並提供給第三方應用程式

電視裝置實作「必須」支援 H.264 解碼功能，詳情請見 第 5.3.4 節：標準影片影格速率，且最高和 包括：

  • [5.3.4/T-1-1] HD 高畫質 1080p (每秒 60 影格) 基準設定檔
  • [5.3.4/T-1-2] HD 高畫質 1080p (每秒 60 影格) 主要個人資料
  • [5.3.4/T-1-3] HD 高畫質 1080p (每秒 60 影格) 高設定檔層級 4.2

採用 H.265 硬體解碼器的電視裝置實作「必須」支援 H.265 解碼 (如第 5.3.5 節所述)，以標準影片影格速率播放 及解析度：

  • [5.3.5/T-1-1] HD 高畫質 1080p (每秒 60 影格) 主要設定檔層級 4.1

如果電視裝置實作支援 H.265 硬體解碼器 H.265 解碼和 UHD 超高畫質設定檔時，兩者會：

  • [5.3.5/T-2-1] 必須支援 UHD 解碼設定檔 每秒 60 個影格，搭配 Main10 第 5 級主要設定檔

電視裝置實作「必須」支援 VP8 解碼，詳情請見 第 5.3.6 節：標準影片影格速率，且最高和 包括：

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

採用 VP9 硬體解碼器的電視裝置實作「必須」支援 VP9 可以採用標準影片影格速率 最高 (含) 以下的解析度：

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

如果電視裝置實作搭配 VP9 硬體解碼器支援 VP9 以及 UHD 解碼設定檔

  • [5.3.7/T-2-1] 必須支援 UHD 解碼設定檔 每秒 60 個影格，設定檔 0 (8 位元色彩深度)。
  • [5.3.7/T-SR1] 強烈建議你提供支援 UHD 超高畫質解碼設定檔，每秒 60 個影格，設定檔 2 (10 位元色彩深度)。

電視裝置導入方式：

  • [5.5/T-0-1] 必須支援系統主節點 支援的輸出內容音量和數位音訊輸出音量， ，但不適用於經過壓縮的音訊直通輸出 (不會進行音訊解碼) 應用程式)。

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

  • [5.8/T-0-1] 必須將 HDMI 輸出模式設為 50Hz 或 60Hz 適用所選像素格式的最高解析度。 外部螢幕的重新整理頻率，取決於 販售區域
  • [5.8/T-SR-1] 極力建議為使用者提供服務 可設定的 HDMI 刷新率選取器。
  • [5.8] 必須設定 HDMI 輸出模式重新整理頻率 至 50Hz 或 60Hz，取決於該區域的 裝置販售日期

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

  • [5.8/T-1-1] 必須支援 HDCP 2.2。

如果電視裝置導入作業不支援 UHD 解碼功能，但 支援透過 HDMI 連接的外接螢幕：

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

2.3.3.軟體

電視裝置導入方式：

  • [3/T-0-1] 必須聲明 android.software.leanback敬上 和 android.hardware.type.television。
  • [3.2.3.1/T-0-1] 必須預先載入一或多個 具有意圖處理常式的更多應用程式或服務元件 下列應用程式意圖定義的公開意圖篩選器模式 請參閱這篇文章。
  • [3.4.1/T-0-1] 必須提供完整 android.webkit.Webview API 的實作。

如果 Android TV 裝置實作支援螢幕鎖定功能，可執行以下動作：

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

電視裝置導入方式：

  • [3.8.14/T-SR-1] 強烈建議你使用 支援子母畫面 (PIP) 模式的多視窗模式。
  • [3.10/T-0-1] 必須支援第三方無障礙設定 免費 Google Cloud 服務
  • [3.10/T-SR-1] 強烈建議你 在裝置上預先載入無障礙服務 切換控制功能和 TalkBack 的功能 (適用於 預先安裝的文字轉語音引擎) 無障礙服務 Talkback 開放原始碼專案。

如果電視裝置導入方式回報這項功能 android.hardware.audio.output，他們：

  • [3.11/T-SR-1] 極力建議您加入 支援裝置可用語言的 TTS 引擎。
  • [3.11/T-1-1] 必須支援 第三方 TTS 引擎。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

電視裝置導入方式：

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

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

Android 電視輸入架構 (TIF) 簡化了 向 Android TV 裝置提交直播內容。TIF 提供了 提供 API，用於建立控制 Android Television 裝置的輸入模組。

電視裝置導入方式：

  • [3/T-0-2] 必須宣告平台功能 android.software.live_tv。
  • [3/T-0-3] 必須支援所有 TIF API，例如 這些 API 會使用這些 API 第三方 TIF 型輸入內容 服務可在裝置上安裝及使用。

Android 電視調諧器架構 (TF) 統一處理 Tuner 的直播內容處理方式，以及來自 IP 的串流內容 在 Android TV 裝置上播放Turner Framework 提供了標準 API 來建立使用 Android Television Tuner 的輸入服務。

如果裝置的實作支援 Tuner，就會執行下列動作：

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

終止新規定

2.3.4.效能與功率

  • [8.1/T-0-1] 影格延遲時間一致。 影格延遲不一致或轉譯影格延遲，「不得」發生更多 且每秒影格數通常不超過 1 個
  • [8.2/T-0-1] 必須確保 至少每秒 5 MB 的寫入效能。
  • [8.2/T-0-2] 必須確保隨機寫入 至少每秒 0.5 MB
  • [8.2/T-0-3] 必須確保 至少每秒 15 MB 的讀取效能。
  • [8.2/T-0-4] 必須確保隨機讀取 至少每秒 3.5 MB

如果電視裝置導入了可改善裝置效能的功能 或擴充 Android 開放原始碼計畫內含的功能 後，您會發現：

  • [8.3/T-1-1] 必須提供使用者預設用途才能啟用 然後停用省電模式

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

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

  • [8.3/T-1-3] 必須為使用者提供顯示空間 所有適用應用程式待命和打盹省電模式的應用程式。

電視裝置導入方式：

  • [8.4/T-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ，以及測試過程中 。
  • [8.4/T-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
  • [8.4/T-0-3] 必須回報 CPU 效能 每段程序的 UID。Android 開放原始碼計畫滿足 要求通過uid_cputime核心模組實作。
  • [8.4/T] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式
  • [8.4/T-0-4] 必須使用 可透過 adb shell dumpsys batterystats 使用 殼層指令給應用程式開發人員。

2.3.5。安全性模型

電視裝置導入方式：

  • [9/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 系統 所在區域的演算法，與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境，包括《數位市場法》上游 Android 開放原始碼 專案 (AOSP) 利用 Trusty 實作項目達成這項規定， ARM TrustZone 解決方案或第三方經過安全審查 可替代實作方式，以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
  • [9.11/T-0-3] 必須執行螢幕鎖定 隔離於隔離執行環境中驗證 成功，請允許使用驗證繫結金鑰。螢幕鎖定畫面 憑證的儲存方式必須僅允許獨立執行 執行螢幕鎖定驗證。上游 Android 開放原始碼專案 總機人員硬體抽象層 (HAL) 和 Trusty 合作，以滿足這項需求

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [9.11/T-0-4] 必須支援金鑰認證， 認證簽署金鑰受到安全的硬體保護， 在安全的硬體中執行 「必須」 在以下服務之間共用認證簽署金鑰： 變得足夠的裝置數量，以防止按鍵 禁止 避免當成「永久」使用 裝置 ID 為了符合這項規定，其中一個方法是提供 除非特定 SKU 至少有 10 萬個單位 產生的結果。如果產生的 SKU 超過 100,000 個單位，請採用 每 100,000 個單位可使用 MAY 鍵。

終止新規定

請注意，如果裝置已啟動至較舊的 Android 版本 這類裝置不受具有 KeyStore 的限制 並支援金鑰認證 除非宣告了 android.hardware.fingerprint 功能，而該功能需要 由獨立執行環境支援的 KeyStore。

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

  • [9.11/T-1-1] 必須允許使用者選擇睡眠 逾時狀況 允許逾時，最長可達 15 秒。

如果電視裝置導入方式有多位使用者 未宣告 android.hardware.telephony 功能旗標，則會：

  • [9.5/T-2-1] 必須支援設有限制的個人資料。 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後，裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。

如果電視裝置導入方式有多位使用者 宣告 android.hardware.telephony 功能旗標後：

  • [9.5/T-3-1] 不支援受限制的 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。

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

  • [9.8.2/T-4-1] 發生在以下情況時，必須顯示麥克風指示燈 應用程式正在從麥克風存取音訊資料，但無法存取 麥克風只能透過 HotwordDetectionService、SOURCE_HOTWORD、 ContentCaptureService，或擁有第 9.1 節所述角色的應用程式 CDD ID C-3-X 的權限。
  • [9.8.2/T-4-2] 不得隱藏 具有可見使用者介面或直接使用者互動的系統應用程式。

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

  • [9.8.2/T-5-1] 應用程式正在存取即時攝影機資料，但只有攝影機存取時則不會 擁有第 9.1 節所述角色的應用程式能夠存取 CDD ID [C-3-X] 的權限。
  • [9.8.2/T-5-2] 請勿隱藏相機指標的 具有可見使用者介面或直接使用者互動的系統應用程式。

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

電視裝置導入方式：

終止新規定

2.4.智慧手錶需求

Android Watch 裝置是指 Android 裝置實作，目的是 例如戴在手腕上

如果 Android 裝置的導入方式符合所有 符合以下條件：

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

本節其他規定僅適用於 Android 手錶裝置實作。

2.4.1.硬體

手錶裝置實作：

  • [7.1.1.1/W-0-1] 「必須」顯示 介於 1.1 到 2.5 吋之間

  • [7.2.3/W-0-1] 必須支援家用功能 和返回函式，但位於 UI_MODE_TYPE_WATCH 時除外。

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

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

如果手錶裝置實作項目支援 Vulkan，就必須：

如果手錶裝置導入方式包含 GPS/GNSS 接收器，並回報 透過 android.hardware.location.gps 功能將功能套用至應用程式 旗幟，他們可以：

  • [7.3.3/W-1-1] 務必立即回報 GNSS 測量結果 。
  • [7.3.3/W-1-2] 必須回報 GNSS 虛擬範圍和虛擬範圍 費率，在判斷地點後，在開放天際的環境中顯示 靜息或移動，且每秒小於 0.2 公尺的平方 足以計算出 20 公尺以內且速度 0.2 公尺以內，至少 95% 的時間

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

  • [7.3.4/W-2-1] 必須能夠評估螢幕方向變化 高達每秒 1000 度

手錶裝置實作：

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

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

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

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

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

2.4.2.多媒體

沒有其他相關規定。

2.4.3.軟體

手錶裝置實作：

  • [3/W-0-1] 必須聲明這項功能 android.hardware.type.watch。
  • [3/W-0-2] 必須支援 uiMode = UI_MODE_TYPE_WATCH。
  • [3.2.3.1/W-0-1] 必須預先載入其中一個 具有意圖處理常式的一或多個應用程式或服務元件 下列應用程式定義的所有公開意圖篩選器模式 意圖清單請見這篇文章。

手錶裝置實作：

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

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

  • [3.10/W-1-1] 必須支援第三方無障礙設定 免費 Google Cloud 服務
  • [3.10/W-SR-1] 強烈建議預先載入 裝置上的無障礙服務與或超越的功能相等 和 TalkBack 的切換控制功能 (適用於 文字轉語音引擎) 無障礙服務 Talkback 開放原始碼專案。

如果手錶裝置實作方式回報 android.hardware.audio.output 功能， 他們會：

  • [3.11/W-SR-1] 極力建議您加入 支援裝置可用語言的 TTS 引擎。

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

2.4.4.效能與功率

如果實作的手錶裝置內含可改善裝置效能的功能 或擴充 Android 開放原始碼計畫內含的功能 後，您會發現：

  • [8.3/W-SR-1] 極力建議您提供 顯示免除應用程式待命的所有應用程式，以及 打盹省電模式。
  • [8.3/W-SR-2] 強烈建議你提供 ，以啟用和停用省電模式功能。

手錶裝置實作：

  • [8.4/W-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ，以及測試過程中 。
  • [8.4/W-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
  • [8.4/W-0-3] 必須回報 CPU 效能 每段程序的 UID。Android 開放原始碼計畫滿足 要求通過uid_cputime核心模組實作。
  • [8.4/W-0-4] 必須使用 可透過 adb shell dumpsys batterystats 使用 殼層指令給應用程式開發人員。
  • [8.4/W] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式

2.4.5。安全性模型

手錶裝置實作：

  • [9/W-0-1] 必須宣告 android.hardware.security.model.compatible 而不是每個特徵的分數

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

  • [9.5/W-1-1] 必須支援設有限制的個人資料。 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後，裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。

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

  • [9.5/W-2-1] 不支援受限制功能 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。

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

  • [9.11.1/W-1-1] 使用建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 頻率必須每 72 小時超過一次。

2.5.汽車規定

Android Automotive 實作是指執行中的車輛車用運算主機 Android 是部分或整個系統的作業系統，和/或 資訊娛樂系統的功能

Android 裝置的實作方式如果宣告為 Automotive 應用程式 「android.hardware.type.automotive」功能或符合下列所有條件 標準。

  • 嵌入或連接汽車車輛的一部分。
  • 使用駕駛座椅列的螢幕做為主要顯示器。

本節其他規定僅適用於 Android Automotive 裝置實作。

2.5.1.硬體

Automotive 裝置實作：

  • [7.1.1.1/A-0-1] 螢幕至少要有 6 單位和實際對角線尺寸
  • [7.1.1.1/A-0-2] 必須設有螢幕大小的版面配置 至少 750 dp x 480 dp

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 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。

終止新規定

如果 Automotive 裝置實作支援 OpenGL ES 3.1，就會執行以下動作：

  • [7.1.4.1/A-0-1] 必須聲明 OpenGL ES 3.1 以上版本。
  • [7.1.4.1/A-0-2] 必須支援 Vulkan 1.1。
  • [7.1.4.1/A-0-3] 必須加入 Vulkan 載入器 並匯出所有符號

如果 Automotive 裝置實作項目支援 Vulkan，就會：

Automotive 裝置實作：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [7.2.3/A-0-1] 必須提供 首頁 和返回函式，且 MAY 可提供 返回和 近期函式。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 Android 使用者同時與裝置互動 因此使用自己的螢幕 config_multiuserVisibleBackgroundUsers敬上 已啟用的情況下)，他們會：

  • [7.3/A-1-1] 必須設定 NIGHT_MODE敬上 一致地透過數字面板日/夜間模式使用 所有螢幕，包括後座螢幕。

終止新規定

如果 Automotive 裝置導入加速計，請按照下列步驟操作：

  • [7.3.1/A-1-1] 必須能夠按頻率回報活動 至少 100 Hz。

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

  • [7.3.1/A-SR-1] 強烈建議導入 複合感應器，適用於限定軸心加速計

如果 Automotive 裝置導入的加速計低於 3 軸來：

  • [7.3.1/A-1-3] 必須導入及回報 TYPE_ACCELEROMETER_LIMITED_AXES感應器。
  • [7.3.1/A-1-4] 必須導入及回報 TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED感應器。

如果 Automotive 裝置導入了陀螺儀，則必須：

  • [7.3.4/A-2-1] 必須能夠按頻率回報事件 至少 100 Hz。
  • [7.3.4/A-2-3] 必須能夠評估螢幕方向變化 到每秒可達 250 度的位置
  • [7.3.4/A-SR-1] 強烈建議你為 陀螺儀的測量範圍為 +/-250dp，以便盡可能提高解析度

如果 Automotive 裝置導入作業包含 3 軸式迴轉儀，請按照下列步驟操作：

  • [7.3.4/A-SR-2] 強烈建議導入 適用於有限軸形陀螺儀的複合感應器。

如果 Automotive 裝置實作的陀螺儀少於 3 軸，則：

  • [7.3.4/A-4-1] 必須導入及回報 TYPE_GYROSCOPE_LIMITED_AXES感應器。
  • [7.3.4/A-4-2] 必須導入及回報 TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED感應器。

如果 Automotive 裝置導入了 GPS/GNSS 接收器，但沒有 包括：

  • [7.3.3/A-3-1] 初次必須判斷所在位置 GPS/GNSS 接收器在 60 秒內開機或超過 4 天。
  • [7.3.3/A-3-2] 必須符合首次修正時間條件 如 7.3.3/C-1-2 和 7.3.3/C-1-6 所述 則針對所有其他位置要求 (例如非第一次的要求) 或超過 4 天之後)。要求 7.3.3/C-1-2 為 通常可在沒有行動網路數據連線的車輛中運作 方法是使用 最後已知車輛位置以及現在的 至少 60 秒，且位置準確度符合 7.3.3/C-1-3，或兩者並用。

如果汽車裝置實作包含 TYPE_HEADING 感應器，其：

  • [7.3.4/A-4-3] 必須能夠按頻率回報事件 至少 1 Hz。
  • [7.3.4/A-SR-3] STRONGLY_RECOMMENDED 可回報下列事件： 頻率至少為 10 Hz。
  • 應參照正北。
  • 車輛靜止不動時仍應使用車輛。
  • 解析度至少要為 1 度。

Automotive 裝置實作：

  • [7.4.3/A-0-1] 必須支援藍牙，且應採用 支援藍牙 LE。
  • [7.4.3/A-0-2] Android Automotive 實作項目 必須支援下列藍牙設定檔：
    • 透過免持聽筒設定檔 (HFP) 撥打電話。
    • 透過音訊發布設定檔 (A2DP) 播放媒體。
    • 遠端控制設定檔 (AVRCP) 的媒體播放控制項。
    • 透過電話簿存取設定檔 (PBAP) 分享聯絡人。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [7.4.3/A-SR-1] 強烈建議你提供支援 如果裝置有駕駛人所在區域，則訊息存取設定檔 (MAP)

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 Android 使用者同時與裝置互動 因此使用自己的螢幕 config_multiuserVisibleBackgroundUsers敬上 已啟用的情況下)，他們會：

  • [7.4.3/A-1-1] 必須獨立且「不會」幹擾 與其他使用者共用BT 經驗。

終止新規定

Automotive 裝置實作：

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

後置鏡頭是指面向任何地點的鏡頭 面向車廂，面向車廂；也就是 車輛身體最遠處的場景，例如後置鏡頭

前置鏡頭是指面向使用者的鏡頭，可以放在任何位置 面向車廂，面向車廂；那是這樣 使用者的圖像，像是用於視訊會議和類似的應用程式。

Automotive 裝置實作：

  • [7.5/A-SR-1] 強烈建議你納入一或多個面向世界 相機上
  • 可能配備一或多個面向使用者的相機。
  • [7.5/A-SR-2] 強烈建議你支援 拍攝多部攝影機

如果 Automotive 裝置導入作業中至少包含一部 對相機鏡頭來說，這些技術會：

  • [7.5/A-1-1] 必須調整方向，確保相機的長邊對齊 Android 汽車感測器軸的 X-Y 平面設計而成
  • [7.5/A-SR-3] 強烈建議採用固定對焦或 EDOF 硬體 (延伸景深) 硬體。
  • [7.5/A-1-2] 「必須」使用前置鏡頭做為面向 相機 ID 最低的相機

如果 Automotive 裝置導入作業中至少包含一部 面向使用者的面向，對這類相機來說：

  • [7.5/A-2-1] 主鏡頭「必須」是面向使用者的相機 最低為相機 ID
  • 務必取向，攝影機的長邊對齊 X-Y Android 汽車感測器軸的平面。

如果 Automotive 裝置須提供可透過以下工具存取的相機： 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] 必須可透過擴充觀看系統服務存取。

如果 Automotive 裝置包含一或多部攝影機，可透過 這類相機的擴充檢視畫面系統服務：

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

如果 Automotive 裝置提供專屬的相機 API，就會：

Automotive 裝置實作：

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

  • [7.6.1/A] 必須設定資料分區的格式 提升效能和快閃記憶體的壽命 (例如， 使用 f2fs 檔案系統)。

如果 Automotive 裝置實作方式是透過 部分內部非卸除式儲存空間時，您可以：

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 Android 使用者同時與裝置互動 因此使用自己的螢幕 config_multiuserVisibleBackgroundUsers敬上 已啟用的情況下)，他們會：

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

終止新規定

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [7.6.1/A-2-1] 核心的可用記憶體 且使用者空間不得小於 816 MB 每個主螢幕 如果使用以下任一密度：

    • 在小螢幕/一般螢幕上，螢幕解析度低於 280 dpi
    • 搭載超大型螢幕的 ldpi 或更低版本
    • 大螢幕上的 mdpi 或更低

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

    • 小螢幕/一般螢幕適用的 xhdpi 或更高
    • 在大型螢幕上使用 hdpi 或更高版本
    • 在特大型螢幕上使用 mdpi 或更高版本

  • [7.6.1/A-2-3] 核心的可用記憶體 且使用者空間不得小於 1280 MB 每個主螢幕 如果使用以下任一密度：

    • 在小螢幕/一般螢幕上搭載 400 dpi 以上
    • 在大螢幕上使用 xhdpi 或更高版本
    • 搭載 tvdpi 以上版本

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

    • 在小螢幕/一般螢幕上搭載 560 dpi 以上
    • 在大螢幕上設為 400 dpi 以上
    • 搭載 xhdpi (含) 以上大螢幕

請注意，「核心和使用者空間可用的記憶體」以上是指 所提供的記憶體空間 無線電、影片等非核心的 控管裝置導入方式

終止新規定

Automotive 裝置實作：

  • [7.7.1/A] 必須納入支援週邊裝置模式的 USB 連接埠。

Automotive 裝置實作：

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

Automotive 裝置實作：

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 Android 使用者同時與裝置互動 因此使用自己的螢幕 config_multiuserVisibleBackgroundUsers敬上 已啟用的情況下)，他們會：

  • [7.8.2/A-1-1] 每個主電源都必須擁有音訊輸出裝置 多使用者系統並行
  • [7.8.2/A-1-2] 必須使用駕駛人音訊區功能， CANNOT TRANSLATE前乘客區可以分享司機的音訊 區域，或是自己的音訊輸出裝置。

終止新規定

2.5.2。多媒體

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

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

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

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

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

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

我們強烈建議導入 Automotive 裝置，以便支援 下列影片解碼：

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 Android 使用者同時與裝置互動 因此使用自己的螢幕 config_multiuserVisibleBackgroundUsers敬上 已啟用的情況下)，他們會：

  • [5.5.3/A-1-1] 必須定義相同的音量曲線 所有音訊輸出串流都會對應至相同的音量群組 (如 車子音訊設定檔。

終止新規定

2.5.3.軟體

Automotive 裝置實作：

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

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

  • [3/A-0-3] 必須支援 android.car.*敬上 命名空間

如果 Automotive 裝置實作提供專屬的 API android.car.CarPropertyManager，內含 android.car.VehiclePropertyIds, 他們會：

  • [3/A-1-1] 不得將特殊權限附加至系統 應用程式使用這些屬性，或阻止第三方應用程式 利用這些屬性
  • [3/A-1-2] 不得複製已經 SDK 中找到。

Automotive 裝置實作：

  • [3.2.1/A-0-1] 必須全面支援並強制執行所有政策 權限常數 (如汽車權限參考資料頁面所記錄)。

  • [3.2.3.1/A-0-1] 必須預先載入一或多個 具有意圖處理常式的更多應用程式或服務元件 下列應用程式意圖定義的公開意圖篩選器模式 請參閱這篇文章。

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

如果 Automotive 裝置實作支援並行多使用者 (可讓多位 Android 使用者同時與裝置互動 因此使用自己的螢幕 config_multiuserVisibleBackgroundUsers敬上 適用於非目前前景使用者的完整次要使用者 但具備螢幕的 UI 存取權，就需要：

終止新規定

Automotive 裝置實作：

如果 Automotive 裝置實作包含「按下並交談」按鈕，就會：

  • [3.8.4/A-1-1] 必須使用短暫的 並使用推送按鈕為指定的互動來啟動 使用者選擇的輔助應用程式，也就是 VoiceInteractionService。

Automotive 裝置實作：

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

Automotive 裝置實作：

如果 Automotive 裝置實作內含預設啟動器應用程式，就會執行以下動作：

Automotive 裝置實作：

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

2.5.4.效能與功率

Automotive 裝置實作：

  • [8.2/A-0-1] 必須回報 根據各個程序的 UID 讀取和寫入非揮發性儲存空間， 開發人員可透過 System API 查看統計資料 android.car.storagemonitoring.CarStorageMonitoringManager。Android 公開 來源專案透過 uid_sys_stats 核心模組符合要求。
  • [8.3/A-1-3] 必須支援車庫模式。
  • [8.3/A] 至少應使用車庫模式 開車後 15 分鐘，但下列情形除外：
    • 電量耗盡。
    • 未安排任何閒置工作。
    • 駕駛會結束車庫模式。
  • [8.4/A-0-1] 必須提供 定義目前消耗量值的每個元件電源設定檔 ，以及測試過程中 。
  • [8.4/A-0-2] 必須回報所有電力 以毫秒 (mAh) 為單位。
  • [8.4/A-0-3] 必須回報 CPU 效能 每段程序的 UID。Android 開放原始碼計畫滿足 要求通過uid_cputime核心模組實作。
  • [8.4/A] 必須註明 硬體元件本身 (如果無法歸屬硬體元件的耗電量) 傳送至應用程式
  • [8.4/A-0-4] 必須使用 可透過 adb shell dumpsys batterystats 使用 殼層指令給應用程式開發人員。

2.5.5。安全性模型

如果 Automotive 裝置實作支援多位使用者：

如果 Automotive 裝置實作項目宣告 android.hardware.microphone， 他們會：

  • [9.8.2/A-1-1] 發生在以下情況時，必須顯示麥克風指示燈 應用程式正在從麥克風存取音訊資料，但無法存取 麥克風僅供 HotwordDetectionService、SOURCE_HOTWORD 和 ContentCaptureService或具有角色呼叫的應用程式 含有 CDD ID [C-4-X] 的第 9.1 節。
  • [9.8.2/A-1-2] 請勿隱藏 具有可見使用者介面或直接使用者互動的系統應用程式。
  • [9.8.2/A-1-3] 必須提供使用者負擔， 麥克風。

如果 Automotive 裝置實作項目宣告 android.hardware.camera.any，則 他們會：

  • [9.8.2/A-2-1] 應用程式正在存取即時攝影機資料，但若只有攝影機存取，則不會 具備特定角色(依下表定義) 的應用程式存取 第 9.1 節權限 。
  • [9.8.2/A-2-2] 請勿隱藏相機指標的 具有可見使用者介面或直接使用者互動的系統應用程式。
  • [9.8.2/A-2-3] 「設定」應用程式中「必須」提供使用者預設用途，以便切換相機。
  • [9.8.2/A-2-4] 系統傳回時，必須顯示最近使用相機和正在使用相機的應用程式 來源：PermissionManager.getIndicatorAppOpUsageData() (以及任何來源) 歸因訊息

Automotive 裝置實作：

  • [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 系統 所在區域的演算法，與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境，包括《數位市場法》上游 Android 開放原始碼 專案 (AOSP) 利用 Trusty 實作項目達成這項規定， ARM TrustZone 解決方案或第三方經過安全審查 可替代實作方式，以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
  • [9.11/A-0-3] 必須執行螢幕鎖定 隔離於隔離執行環境中驗證 成功，請允許使用驗證繫結金鑰。螢幕鎖定畫面 憑證的儲存方式必須僅允許獨立執行 執行螢幕鎖定驗證。上游 Android 開放原始碼專案 總機人員硬體抽象層 (HAL) 和 Trusty 合作，以滿足這項需求

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [9.11/A-0-4] 必須支援金鑰認證， 認證簽署金鑰受到安全的硬體保護， 在安全的硬體中執行 「必須」 在以下服務之間共用認證簽署金鑰： 變得足夠的裝置數量，以防止按鍵 禁止 避免當成「永久」使用 裝置 ID 為了符合這項規定，其中一個方法是提供 除非特定 SKU 至少有 10 萬個單位 產生的結果。如果產生的 SKU 超過 100,000 個單位，請採用 每 100,000 個單位可使用 MAY 鍵。

終止新規定

請注意，如果裝置已啟動至較舊的 Android 版本 這類裝置不受具有 KeyStore 的限制 並支援金鑰認證 除非宣告了 android.hardware.fingerprint 功能，而該功能需要 由獨立執行環境支援的 KeyStore。

Automotive 裝置實作：

  • [9.14/A-0-1] 必須控管郵件 來自 Android 架構車輛子系統，例如將允許的訊息加入許可清單 以及訊息來源
  • [9.14/A-0-2] 必須防止監控 來自 Android 架構或第三方應用程式的阻斷服務攻擊。這個 防止惡意軟體在車輛網路中流出流量。 這可能會導致車輛子系統故障。

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

Automotive 裝置實作：

終止新規定

2.6.平板電腦需求

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

  • 用於雙手並用於雙手。
  • 沒有貝殼式設計或可轉換設定。
  • 與裝置連線搭配使用的實體鍵盤實作方式： 適用於標準連線 (例如 USB、藍牙)。

  • 具有可提供行動用的電源 (例如電池)。

  • 螢幕尺寸大於 7 吋且小於 18 吋，是根據對角線測得的數值。

平板電腦裝置實作時的需求條件與手持裝置類似 。該節中會以 * 表示例外。 並在本節中註記，以備參考

2.6.1.硬體

陀螺儀

如果平板電腦裝置導入方式包含 3 軸式迴轉儀，代碼會：

  • [7.3.4/Tab-1-1] 必須能夠評估方向 每秒最多可變更 1000 度

記憶體與儲存空間下限 (第 7.6.1 節)

手持小型/一般螢幕的螢幕密度 則不適用平板電腦。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

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

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

終止新規定

虛擬實境模式 (第 7.9.1 節)

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

虛擬實境要求不適用於平板電腦。

2.6.2.安全性模型

金鑰和憑證 (第 9.11 節)

請參閱 [9.11] 一節。

如果平板電腦裝置的實作方式包含多位使用者 未宣告 android.hardware.telephony 功能旗標，則會：

  • [9.5/T-1-1] 必須支援設有限制的個人資料。 裝置擁有者可透過這項功能管理其他使用者 在裝置上的功能。設定設有限制的個人資料後，裝置擁有者就能 快速設定不同的環境供其他使用者工作 還能夠管理更精細的限制 在這些環境中使用。

如果平板電腦裝置的實作方式包含多位使用者 宣告 android.hardware.telephony 功能旗標後：

  • [9.5/T-2-1] 不支援受限制功能 但務必符合 Android 開放原始碼計畫的 實作方式 允許 /禁止其他使用者存取語音通話和簡訊。

2.6.2.軟體

  • [3.2.3.1/Tab-0-1] 必須預先載入其中一個 具有意圖處理常式的一或多個應用程式或服務元件 下列應用程式意圖定義的公開意圖篩選器模式 請參閱這篇文章。

3. 軟體

3.1. 代管 API 相容性

代管的 Dalvik 位元碼執行環境是 Android 應用程式。Android 應用程式設計介面 (API) Android 平台中運作的應用程式 管理執行階段環境

裝置實作方式：

  • [C-0-1] 必須提供完整導入程序，包括所有明確文件 伺服器監控任何已記錄的 API 行為 Android SDK 或任何以「@SystemApi」裝飾的 API上游 Android 中的標記 Cloud Build 觸發條件 會在您變更原始碼時自動啟動建構作業

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

  • [C-0-3] 不得省略任何受管理的 API 或更改 API 介面或簽名； 偏離記錄行為，或屬於免人工管理，除非 這項相容性定義特別允許。

  • [C-0-4] 「必須」保持 API 正常運作且運作 即使是 Android 應用程式的某些硬體功能 包含 API 的部分請參閱第 7 節 瞭解有哪些特殊需求

  • [C-0-5] 不得允許第三方應用程式使用非 SDK 介面。 都定義為 Java 語言套件中的方法和欄位 加入 Android 開放原始碼計畫的啟動類別路徑，且該路徑未構成公開資料 將機器學習工作流程自動化這包含以 @hide 註解裝飾，但不含有 @SystemAPI (如 SDK 文件中所述) 以及私人和非公開課程成員

  • [C-0-6] 每個非 SDK 介面都必須以相同的受限介面提供 透過臨時和拒絕清單旗標提供的清單 prebuilts/runtime/appcompat/hiddenapi-flags.csv 有關 Android 開放原始碼計畫中適當 API 級別分支版本的路徑。

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

    但請注意下列事項：

    • 如果裝置上沒有隱藏的 API，或是該 API 在裝置上的實作方式不同，可能會發生這種情況 將隱藏的 API 移至拒絕清單，或從拒絕清單省略該 API 。
    • 如果 Android 開放原始碼計畫中沒有隱藏的 API，請新增隱藏的 API 傳送至任何受限清單

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

終止新規定

3.1.1. Android 擴充功能

Android 支援透過以下項目擴充特定 API 級別的代管 API 介面： 更新該 API 級別的擴充功能版本 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API 會傳回 提供的 apiLevel 擴充功能版本 (如有適用的擴充功能) API 級別。

Android 裝置實作：

  • [C-0-1] 「必須」預先載入兩個共用程式庫的 Android 開放原始碼計畫實作項目 ExtShared 和服務ExtServices，且版本大於或等於 每個 API 級別允許的最低版本例如 Android 7.0 搭載 API 級別 24 的裝置實作至少必須包含 第 1 版。

  • [C-0-2] 「必須」只傳回已經 是由 Android 開放原始碼計畫定義的定義。

  • [C-0-3] 必須支援擴充功能版本定義的所有 API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) 已退回 方法與支援其他代管 API 的方法相同， 滿足第 3.1 節的要求。

3.1.2. Android 程式庫

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

  • [C-0-1] 不得將 org.apache.http.legacy 程式庫放在 「Bootclasspath」
  • [C-0-2] 「必須」將 org.apache.http.legacy 程式庫新增至應用程式 應用程式必須符合下列任一條件時，系統才會執行類別路徑：
    • 目標 API 級別為 28 以下。
    • 在資訊清單中設定要使用的程式庫，以宣告需要該程式庫 <uses-library> 的 android:name 屬性設為 org.apache.http.legacy。

Android 開放原始碼計畫實作項目符合這些規定。

3.2. 軟 API 相容性

除了第 3.1 節列出的代管 API 之外， Android 還包含大量的「純執行階段」API 的形式 例如 Android 應用程式的意圖、權限等等 無法在應用程式編譯時強制執行。

3.2.1. 權限

  • [C-0-1] 裝置實作者「必須」支援並強制執行所有權限 權限參考資料頁面中記錄的常數。 請注意，第 9 節列出其他 以便滿足 Android 安全性模型的需要

3.2.2。版本參數

Android API 在 android.os.Build 類別 用來描述目前的裝置

  • [C-0-1] 跨裝置提供一致且有意義的價值 請參閱下表，其中列出各廣告格式的額外限制 才能符合所需的裝置導入方式。
參數 詳細說明
版本 目前執行 Android 系統的版本，可透過人類可讀的格式 格式。這個欄位「必須」含有 適用於 Android 15 的許可版本字串。
SDK 版本 目前執行 Android 系統的版本，格式為 第三方應用程式程式碼存取。針對 Android 15， 這個欄位「必須」包含整數值 15_INT。
VERSION.SDK&lowbar;INT 目前執行 Android 系統的版本，格式為 第三方應用程式程式碼存取。針對 Android 15， 這個欄位「必須」包含整數值 15&lowbar;INT。
版本 指定特定版本的裝置實作者選擇的值 而且是使用人類可讀的格式。這個 提供給使用者的不同版本「不得」重複使用。A 罩杯 這個欄位通常會用於指出 原始碼控制變更 ID 用於產生建構作業這個鍵 都必須能以可列印的 7 位元 ASCII 格式編碼，且符合 規則運算式 ^[^ :\/~]+$。
桌遊 裝置實作者選擇的值，用來識別 裝置所用的內部硬體，採人類可讀的格式。可能 此欄位的用途是指出電路板電源的特定修訂版本 裝置。這個欄位的值必須能以 7 位元 ASCII 字元和 符合規則運算式 ^[a-zA-Z0-9_-]+$。
品牌 這個值代表與裝置相關聯的品牌名稱 使用者格式必須清晰可讀，且須為 裝置的製造商或裝置所屬的公司品牌 上市。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且相符 規則運算式 ^[a-zA-Z0-9_-]+$
支援(&L) 原生指令集的名稱 (CPU 類型 + ABI 慣例) 再也不是件繁重乏味的工作請參閱第 3.3 節。本機 API 相容性。
支援&lowbar;32&lowbar;BIT&lowbar;ABIS 原生指令集的名稱 (CPU 類型 + ABI 慣例) 再也不是件繁重乏味的工作請參閱第 3.3 節。本機 API 相容性。
支援&lowbar;64&lowbar;BIT&lowbar;ABIS 第二個指令集的名稱 (CPU 類型 + ABI 慣例) 原生程式碼請參閱第 3.3 節。原生廣告 API 相容性。
CPU/ABI 原生指令集的名稱 (CPU 類型 + ABI 慣例) 再也不是件繁重乏味的工作請參閱第 3.3 節。本機 API 相容性。
CPU&lowbar;ABI2 第二個指令集的名稱 (CPU 類型 + ABI 慣例) 原生程式碼請參閱第 3.3 節。原生廣告 API 相容性。
裝置 由裝置實作者選擇的值，包含開發名稱 或是程式碼名稱，指出硬體功能和設定 裝置的工業設計這個欄位的值必須可供編碼 並以 7 位元 ASCII 格式比對規則運算式 ^[a-zA-Z0-9_-]+$。在此期間，此裝置名稱「不得」變更 都會使用產品的生命週期
指紋 專門用於識別此版本的字串。請合理 人類可讀的格式請務必遵循以下範本：

$(品牌)/$(PRODUCT)/
$(裝置)：$(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_-]+$。
主機 可明確識別建立版本所在主機的字串。 人類可讀的格式對 Pod 來說， 但這個欄位「不得」為空值或空字串 (")。
ID 裝置實作者選擇的 ID，用來參照特定 版本。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL，但必須是充分的價值 以便使用者區分不同軟體版本這個鍵 都必須能以 7 位元 ASCII 格式編碼，且符合 運算式 ^[a-zA-Z0-9._-]+$。
製造商 產品。這個欄位的特定格式沒有任何規定。 ，但不得為空值或空字串 (")。這個欄位 在產品生命週期內，不得變更。
SOC&lowbar;MANUFACTURER 主要系統的製造商名稱 晶片 (SOC)。SOC 製造商裝置相同的裝置 應該使用相同的常數值。請洽詢 SOC 製造商 要使用的正確常數這個欄位的值必須可供編碼 做為 7 位元 ASCII，「必須」符合 ^([0-9A-Za-z ]+)，開頭或結尾不得為空白字元。 而且「不得」等於「未知」。在 都會使用產品的生命週期
SOC&lowbar;MODEL 晶片中主要系統 (SOC) 的模型名稱； 搭載相同 SOC 模型的裝置應使用相同的常數 值。請洽詢 SOC 製造商以取得要使用的正確常數。 這個欄位的值必須能以 7 位元 ASCII 格式編碼，且與 規則運算式 ^([0-9A-Za-z ._/+-]+)$，不得開頭或 結尾為空白，而且「不能」等於「未知」。這個欄位 在產品生命週期內，不得變更。
MODEL 由裝置實作者選擇的值，其中包含 系統判斷每個裝置的位置這個名稱與 使用者行銷和銷售裝置。我們並未針對 特定格式，但不得為空值或 空字串 ("")。在 都會使用產品的生命週期
產品 由裝置實作者選擇的值，包含開發名稱 每個產品 (SKU) 的代碼名稱，都必須在 同一個品牌必須是人類可讀的內容，但不一定能用來觀看 直接回應使用者的需求這個欄位的值必須能以 7 位元 ASCII 字元和 符合規則運算式 ^[a-zA-Z0-9_-]+$。這項產品 在產品生命週期內，名稱不得變更。
ODM&lowbar；SKU 由裝置實作者選擇的選用值，其中包含 SKU (存貨單位) 用於追蹤 例如裝置隨附的任何週邊裝置。 這個欄位的值必須能以 7 位元 ASCII 格式編碼，且與 規則運算式 ^([0-9A-Za-z.,_-]+)$。
序號 必須傳回「UNKNOWN」。
標記 裝置實作者選擇的標記清單 (以半形逗號分隔) 以便進一步區分版本標記必須能以 7 位元 ASCII 格式編碼 且符合規則運算式 ^[a-zA-Z0-9._-]+ 和必須 提供與三個一般 Android 平台相對應的其中一個值 簽署設定：release-keys、dev-keys 和測試金鑰。
時間 代表建構發生時間的時間戳記的值。
類型 裝置實作者選擇的值，用於指定執行階段 建構作業的佈建方式這個欄位必須包含其中一個值 對應至三種典型 Android 執行階段設定：使用者 userdebug 或 eng.
使用者 產生這類內容的使用者 (或自動使用者) 名稱或使用者 ID 建構應用程式這個欄位的特定格式沒有任何規定。 ，但不得為空值或空字串 (")。
安全性(&L) 表示版本安全性修補程式等級的值。必須代表 這個版本並未造成任何容易遭受上述問題影響 完成指定的 Android 公開安全性公告一定要讓 格式為 [YYYY-MM-DD]，與 Android 公開安全性 公告或 Android 安全性補充公告，例如「2015-11-01」。
BASE-bar;OS 一個值，代表建構中 FINGERPRINT 參數的值， 與此版本完全相同，但不包含在 Android 公開安全性公告。必須回報正確的值，並指出 這類版本不存在，請回報空字串 ("")。
新手上路 裝置實作者選擇的值，用來識別 裝置使用的內部系統啟動載入程式版本，採用人類可讀的格式。 這個欄位的值必須能以 7 位元 ASCII 格式編碼，且與 規則運算式 ^[a-zA-Z0-9._-]+$。
getRadioVersion() 必須 (等於或傳回) 裝置實作者選擇的值 識別裝置中使用的特定內部無線電/模組版本 格式。如果裝置沒有內部任何內部 IP 位址 無線電/模組必須傳回 NULL。這個欄位的值必須 能以 7 位元 ASCII 編碼，且符合規則運算式 ^[a-zA-Z0-9._-,]+$。
getSerial() 必須 (已準備好或退回) 提供使用的硬體序號 而且在相同的型號和製造商的裝置中均不重複。如果 這個欄位必須能編碼成 7 位元 ASCII，且符合規則運算式 ^[a-zA-Z0-9]+$。

3.2.3.意圖相容性

3.2.3.1。常見的應用程式意圖

Android 意圖允許應用程式元件 其他 Android 元件Android 上游專案會列出 實作多個意圖模式以執行常用動作的應用程式。

裝置實作方式：

  • [C-SR-1] 強烈建議預先載入一或多個應用程式，或是 針對所有公開意圖篩選器，使用包含意圖處理常式的服務元件 此處所列的應用程式意圖定義的模式 並給予執行要求，即符合開發人員對這些常見的要求 應用程式意圖。

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

3.2.3.2。意圖解決方案

  • [C-0-1] 由於 Android 是可擴充平台，因此裝置導入方式「必須」 允許第 3.2.3.1 節所參照的每個意圖模式。 但不適用於「設定」或由第三方應用程式覆寫。 上游 Android 開放原始碼實作允許此做法。

  • [C-0-2] 裝置實作者「不得」將特殊權限附加至系統 應用程式使用這些意圖模式，或防範第三方應用程式 由繫結至及假設這些模式的控制。這項禁令 包括但不限於停用「選擇工具」使用者 介面，可讓使用者選取多個應用程式 處理相同的意圖模式

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

  • 不過，裝置導入方式可能會提供 預設活動提供 更具體地說明資料 URI 屬性例如意圖篩選器模式 指定資料 URI「http://www.android.com」會比 與瀏覽器的核心意圖模式 (「http://」)

Android 也內建可供第三方應用程式宣告的機制 官方預設的應用程式連結行為 特定類型的網路 URI 意圖如果系統提供這類權威聲明 所定義的應用程式意圖篩選器模式、裝置實作方式：

  • [C-0-4] 「必須」嘗試執行 Digital Asset Links 規格定義的驗證步驟 如上游 Android 開放原始碼的套件管理員實作即可 專案。
  • [C-0-5] 安裝 應用程式，並將所有已成功驗證的 URI 意圖篩選器設為 為其 URI 的預設應用程式處理常式。
  • 可以將特定 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。 表示驗證成功，但其他候選 URI 篩選器失敗 驗證。如果裝置導入方式這樣做，就「必須」提供 設定選單內的個別 URI 格式覆寫值。
  • 「設定」中「必須」為使用者提供個別應用程式連結控制項，例如： 如下：
    • [C-0-6] 使用者「必須」能完全覆寫預設應用程式 應用程式的連結行為：一律開啟、一律詢問或永不開啟 這些要求必須同樣套用至所有候選 URI 意圖篩選器。
    • [C-0-7] 使用者「必須」可以查看候選 URI 意圖清單 篩選器。
    • 裝置實作「可能」能讓使用者執行下列操作： 覆寫已成功覆寫的特定候選 URI 意圖篩選器 並按個別意圖篩選器加以驗證
    • [C-0-8] 裝置實作「必須」讓使用者能夠 查看及覆寫特定候選 URI 意圖篩選器 (如有) 實作能讓某些候選 URI 意圖篩選器成功 但部分驗證失敗
3.2.3.3.意圖命名空間
  • [C-0-1] 裝置實作「不得」包含 遵循任何使用 ACTION、CATEGORY 或 則位於 android.* 或 com.android.* 命名空間中。
  • [C-0-2] 裝置實作者「不得」包含 使用 ACTION、CATEGORY 或 其他金鑰字串。
  • [C-0-3] 裝置實作者不得變更或擴充任何意圖 第 3.2.3.1 節所列的模式。
  • 裝置實作項目可能包含清楚使用命名空間的意圖模式 而且明顯與自家機構相關聯這項禁令為 類似於第 3.6 節中 Java 語言類別指定的。
3.2.3.4。廣播意圖

第三方應用程式仰賴這個平台，將特定意圖廣播至 並在硬體或軟體環境變更時發出通知。

裝置實作方式：

  • [C-0-1] 必須播送此處所列的公開廣播意圖 回應 SDK 文件中所述的適當系統事件。 請注意，這項規定與第 3.5 節並未衝突， SDK 中也會描述背景應用程式的限制 說明文件。此外，特定廣播意圖在硬體上是有條件的 支援；前提是裝置必須支援必要的硬體，其「必須」能夠播送 意圖，並在 SDK 說明文件中提供內嵌行為。
3.2.3.5。條件式應用程式意圖

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

而且，裝置導入作業「必須」提供類似的設定 ，並與前述意圖篩選器模式和 API 方法相容 。

如果裝置導入作業回報 android.software.home_screen，就會：

如果裝置導入作業回報 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 目的在於提供使用者可存取的機制，以啟用及停用 第三方無障礙服務及預先載入的無障礙功能 免費 Google Cloud 服務

如果裝置實作提供 Wi-Fi 輕鬆連線支援，並公開 目的是：

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

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

如果裝置實作方式宣告支援相機 android.hardware.camera.any，他們：

如果裝置導入作業回報 android.software.device_admin，就會：

如果裝置導入方式宣告 android.software.autofill 就會：

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

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

如果裝置導入方式顯示 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 活動， 一個螢幕，只能：

  • [C-1-1] 必須設定android.software.activities_on_secondary_displays 功能旗標
  • [C-1-2] 保證與執行於 主螢幕。
  • [C-1-3] 新活動顯示的螢幕必須與 就會啟動新活動時未指定目標 透過 ActivityOptions.setLaunchDisplayId() 顯示 也能使用 Google Cloud CLI 或 Compute Engine API
  • [C-1-4] 顯示具有 Display.FLAG_PRIVATE敬上 標記就會移除
  • [C-1-5] 必須在裝置鎖定時安全地隱藏所有螢幕上的內容 顯示安全螢幕鎖定。除非應用程式選擇顯示在鎖定頂端 使用 Activity#setShowWhenLocked() 的畫面 也能使用 Google Cloud CLI 或 Compute Engine API
  • 應具備 android.content.res.Configuration 以及用來顯示、 並保持相容性 次要螢幕。

如果裝置實作方式允許在次要上啟動一般 Android 活動 螢幕和次要螢幕具有 android.view.Display.FLAG_PRIVATE 旗標：

  • [C-3-1] 只有該螢幕、系統和活動的擁有者 畫面上必須能啟動該螢幕所有人都能在 具有 android.view.Display.FLAG_PUBLIC 的螢幕 旗標。

3.3.原生 API 相容性

原生程式碼相容性不高。因此 裝置實作項目如下：

  • [C-SR-1] 強烈建議使用程式庫的實作方式 下列字串。

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

代管的 Dalvik 位元碼可以呼叫應用程式提供的原生程式碼 .apk 檔案為針對適當裝置硬體編譯的 ELF .so 檔案 這個架構的簡短總覽原生程式碼高度依賴基礎處理器 Android 定義了多種應用程式二進位檔介面 (ABI)， Android NDK。

裝置實作方式：

  • [C-0-1] 必須與一或多個定義的 Android NDK ABI 相容。
  • [C-0-2] 必須支援在代管環境中執行的程式碼， 透過標準 Java Native Interface (JNI) 呼叫原生程式碼 語意
  • [C-0-3] 必須能夠與原始碼相容 (即與標頭相容) 和 與清單中的每個必要程式庫相容 (適用於 ABI) 。
  • [C-0-5] 必須正確回報原生應用程式二進位檔介面 裝置透過 android.os.Build.SUPPORTED_ABIS 支援的 (ABI)， android.os.Build.SUPPORTED_32_BIT_ABIS和 android.os.Build.SUPPORTED_64_BIT_ABIS 參數 (以半形逗號分隔) 將 ABI 從最多到最低的順序排列。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-0-6] 請務必透過上述參數回報下列部分參數 且「不得」回報不在清單上的 ABI。

終止新規定

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

    • libaaudio.so (支援 AAudio 原生音訊)
    • libamidi.so (原生 MIDI，如功能 android.software.midi) 聲明的權利，如第 5.9 節所述)。
    • libandroid.so (原生 Android 活動支援)
    • libc (C 程式庫)
    • libcamera2ndk.so
    • libdl (動態連結器)
    • libEGL.so (原生 OpenGL 介面管理)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • Libicuuc.so
    • libjnigraphics.so
    • liblog (Android 記錄)
    • libmediandk.so (支援原生媒體 API)
    • libm (數學資料庫)
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.so (OpenMAX AL 1.0.1 支援)
    • libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
    • libRS.so
    • libstdc++ (最低支援 C++)
    • libvulkan.so (Vulkan)
    • libz (Zlib 壓縮)
    • JNI 介面

  • [C-0-8] 不得新增或移除原生資料庫的公用函式 。

  • [C-0-9] 必須列出直接公開給其他非 Android 開放原始碼計畫的程式庫 「/vendor/etc/public.libraries.txt」中的第三方應用程式。

  • [C-0-10] 不得揭露其他任何原生資料庫， 在 Android 開放原始碼計畫中，以系統程式庫的形式提供，向指定 API 的第三方應用程式提供 級別 24 以上，系統將保留此廣告。

  • [C-0-11] 必須匯出所有 OpenGL ES 3.1 和 Android 擴充功能套件 透過 libGLESv3.so 程式庫取得 NDK 中定義的函式符號。 請注意，雖然所有符號都必須提供，但第 7.1.4.1 節說明瞭 將詳細說明每個檔案完整導入的 提供相對應的函式

  • [C-0-12] 必須匯出核心的函式符號 Vulkan 1.1 函式 以及 VK_KHR_surface、VK_KHR_android_surface VK_KHR_swapchain、VK_KHR_maintenance1和 VK_KHR_get_physical_device_properties2擴充功能透過 libvulkan.so 程式庫。請注意，雖然所有符號「必須」 第 7.1.4.2 節 則詳細說明瞭 各對應函式應採用的實作方式。

  • 請務必使用 上游 Android 開放原始碼計畫

請注意，日後推出的 Android 版本可能會支援額外的功能 ABI。

3.3.2.32 位元 ARM 原生程式碼相容性

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

  • [C-3-1] 也必須支援 armeabi-v7a 並向我們回報相關支援， armeabi 僅適用於舊版應用程式的回溯相容性。

如果裝置實作回報對應用程式的支援 armeabi-v7a ABI 並使用這個 ABI 進行下列操作：

  • [C-2-1] 必須在 /proc/cpuinfo 中加入下列幾行，且不得 會修改同一個裝置上的值，即使其他 ABI 讀取這些值也是如此。

    • Features:，後面加上任何選用的 ARMv7 CPU 功能清單 支援的瀏覽器。
    • CPU architecture:，後面加上用來說明裝置的整數 最高支援 ARM 架構 (例如「8」適用於 ARMv8 裝置)。

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

    • SWP 和 SWPB 指示。
    • CP15ISB、CP15DSB 和 CP15DMB 障礙行動。

  • [C-2-3] 必須支援進階 SIMD (又稱為 NEON) 副檔名。

3.4.網路相容性

3.4.1.WebView 相容性

如果裝置實作提供完整的 android.webkit.Webview API，則具有以下權限：

  • [C-1-1] 必須回報android.software.webview。
  • [C-1-2] 必須使用 Chromium 專案版本 。 15 個分支用於實作 android.webkit.WebView敬上 也能使用 Google Cloud CLI 或 Compute Engine API

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

    Mozilla/5.0 (Linux；Android $(VERSION)；[$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML，例如 Gecko) 版本/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE。
    • $(MODEL) 字串「可能」為空白，但如果並非空白，則「必須」 這個值與 android.os.Build.MODEL 相同。
    • 「Build/$(BUILD)」如果有 $(BUILD) 一起，可以省略 字串必須與 android.os.Build.ID 的值相同。
    • $(CHROMIUM_VER) 字串的值「必須」是 Chromium 版本 。
    • 裝置導入方式可以在使用者代理程式字串中省略行動裝置。

  • WebView 元件「必須」支援所有 HTML5 功能， 並支援此功能，且務必符合 HTML5 規格。

  • [C-1-4] 「必須」在程序中轉譯提供的內容或遠端網址內容 與執行個體化 WebView 的應用程式不同詳細說明 獨立的轉譯器程序「必須」保有較低權限 做為獨立使用者 ID，則無法存取應用程式的資料目錄。 沒有直接網路存取權，只能存取必要權限 提供名為「Binder」的映像檔WebView 的 Android 開放原始碼計畫實作符合 這項規定。

請注意，如果裝置實作項目為 32 位元，或已宣告功能標記 android.hardware.ram.low，不受 C-1-3 的約束。

3.4.2。瀏覽器相容性

如果裝置實作項目包含適用於一般用途的獨立瀏覽器應用程式 就會遇到以下問題：

  • [C-1-1] 必須針對下列 HTML5：
  • [C-1-2] 必須支援 HTML5/W3C webstorage API，且必須支援 HTML5/W3C IndexedDB API：請注意，因為網頁版 目前正逐漸改用 IndexedDB webstorage, IndexedDB 預計將成為 未來的 Android 版本
  • 可以在獨立的瀏覽器應用程式中提供自訂的使用者代理程式字串。
  • 應盡可能為 HTML5 (獨立) 瀏覽器應用程式 (無論是以上游 WebKit 瀏覽器為基礎) 或第三方的替代品)。

如果裝置實作項目不包含獨立瀏覽器 這兩個版本：

3.5.API 行為相容性

裝置實作方式：

  • [C-0-9] 必須確保 API 行為相容性適用於所有 已安裝的應用程式，除非應用程式受到 第 3.5.1 節。
  • [C-0-10] 「不得」導入許可清單方法，以確保 API 行為相容性僅適用於裝置選取的應用程式 實作器。

每種 API 類型 (代管、軟、原生和網頁) 的行為都必須 與向上游的偏好實作一致 Android 開放原始碼計畫。一些特定區域 相容性為：

  • [C-0-1] 裝置不得變更 標準意圖
  • [C-0-2] 裝置不得變更 特定類型的系統元件 (例如 Service、Activity、ContentProvider 等)。
  • [C-0-3] 裝置「不得」變更標準權限的語意。
  • 裝置「不得」變更背景應用程式強制執行的限制。 具體來說，背景應用程式：
    • [C-0-4] 這些伺服器必須停止執行由 接收 GnssMeasurement 的輸出內容 和 GnssNavigationMessage。
    • [C-0-5] 這些 Pod 必須使用頻率限制 提供給應用程式 LocationManager敬上 API 類別 WifiManager.startScan()。 方法。
    • [C-0-6] 如果應用程式指定的 API 級別為 25 以上，就「不得」 允許針對的隱式廣播訊息註冊廣播接收器 應用程式資訊清單中的標準 Android 意圖 (除非廣播 意圖需要 "signature" 或 "signatureOrSystem" protectionLevel敬上 或位於 豁免清單。
    • [C-0-7] 如果應用程式指定的 API 級別為 25 以上，就必須停止執行 應用程式背景服務的方式，就像應用程式呼叫了 服務 stopSelf()敬上 方法，除非應用程式加入臨時許可清單來處理 向使用者顯示的工作
    • [C-0-8] 如果應用程式指定的 API 級別為 25 以上，就必須 放開應用程式保留的 Wake Lock。
  • [C-0-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. 英屬哥倫比亞 - 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。應用程式限制

如果裝置實作項目採用專屬機制來限制應用程式 (例如變更或限制即將執行的 API 行為) 所載) 和 也就是比受限應用程式待命值區更加嚴格的機制：

  • [C-1-1] 必須允許使用者查看受限制的應用程式清單。
  • [C-1-2] 必須提供使用者權限，才能開啟或關閉所有功能 專屬限制

  • [C-1-3] 在沒有要求的情況下，不得自動套用這些專屬限制 可能存在不良系統健康行為的證據，但可能對應用程式實施了限制 在偵測到不良系統健康行為 (例如 Wake Lock 停滯或長時間跑步) 時 服務以及其他條件標準「可能」視裝置而定 但必須與應用程式對系統健康狀態的影響相關其他 與系統健康狀態無關的條件，例如應用程式的 缺乏市場熱門程度，「不得」當做條件。

  • [C-1-4] 「不得」為應用程式自動套用這些專屬限制 使用者手動關閉應用程式限制，且「可能」建議使用者 才能套用專屬限制

  • [C-1-5] 必須告知使用者，僅適用於這些專屬限制 應用程式就會自動調整「必須」於 24 小時內提供這類資訊 先確定這些專屬限制的應用範圍。

  • [C-1-6] 必須為 ActivityManager.isBackgroundRestricted() 傳回 true 方法。

  • [C-1-7] 不得限制應用程式明確使用的頂層前景應用程式 使用者。

  • [C-1-8] 每當有人讓應用程式 使用者開始明確使用應用程式，讓應用程式位於前景 應用程式。

  • [C-1-10] 必須提供公開且明確的文件或網站，藉此說明 專屬限制的適用情形這份文件或網站必須 可從 Android SDK 文件中連結，且必須包含：

    • 專屬限制的觸發條件。
    • 應用程式的限制和限制方式。
    • 如何讓應用程式不受這類限制限制。
    • 應用程式如何要求豁免專屬限制 都能夠讓使用者安裝的應用程式不受限制。

如果應用程式已預先安裝在裝置上，但應用程式從未明確使用該應用程式 使用者超過 30 天，[C-1-3] [C-1-5] 就符合豁免資格。

如果裝置實作方式會延長執行的應用程式限制 後，您會發現：

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

3.5.2。應用程式休眠

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

  • [C-1-1] 必須符合第 3.5.1 節的所有規定，但 [C-1-6] 和 [C-1-3]。
  • [C-1-2] 「必須」只在使用者遇到 。這個 極力建議將時間長度設為一個月以上。必須使用 是由使用者透過 UsageStats#getLastTimeVisible() 會導致應用程式結束強制停止狀態的 API 或任何可能原因。 包括服務繫結、內容供應器繫結、明確廣播等 ，以便透過新的 API UsageStats#getLastTimeAnyComponentUsed() 追蹤。
  • [C-1-3] 「必須」僅套用對所有裝置使用者造成影響的限制 有證據顯示，已有任一時間未使用該套件 讓應用程式從可以最快做出回應的位置 回應使用者要求極力建議將時間長度設為一個月以上。
  • [C-1-4] 不得算繪應用程式無法回應活動意圖。 服務繫結、內容供應器要求或明確廣播訊息。

Android 開放原始碼計畫的應用程式休眠功能符合上述規定。

3.6.API 命名空間

Android 遵循 Java 定義的套件和類別命名空間慣例 程式設計語言為確保與第三方應用程式相容 裝置實作者「不得」對 以下套件命名空間：

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

也就是說，他們會：

  • [C-0-1] 不得修改 Android 平台上公開公開的 API 變更任何方法或類別簽名，或者移除類別或類別 只要使用來自這些領域的 小型資料集訓練即可
  • [C-0-2] 不得加入任何公開的元素 (例如類別或 介面，或現有類別/介面的欄位或方法) 或「測試」 或「System API」至上述命名空間中的 API建立「對外公開」 元素」是任何未以「@hide」裝飾的結構標記為 所用的參數。

裝置實作者可能會修改 API 的基礎實作方式，但 進行此類修改：

  • [C-0-3] 「不得」影響 任何公開的 API
  • [C-0-4] 不得宣傳或向開發人員揭露。

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

  • [C-0-5] 不得包含在他人所擁有或參照的命名空間 並根據貴機構的使命 價值觀和目標進行調整舉例來說，裝置實作者「不得」將 API 新增到 com.google.* 或類似的命名空間：只有 Google 能這麼做。同樣地 Google 「不得」將 API 新增到其他公司命名空間
  • [C-0-6] 必須封裝在 Android 共用資料庫中，以便僅包含應用程式 明確使用這些內容 (透過 <uses-library> 機制) 則會受到這類 API 的記憶體用量增加影響

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

  • [C-1-1] 「不得」位於 NDK 程式庫或他人擁有的程式庫 機構也能按照 請按這裡。

如果裝置實作人員提議改進上述其中一個套件命名空間 (例如在現有 API 中新增實用的新功能，或 API)，實作者應造訪 source.android.com 並開始做出變更 程式碼就會取代該程式碼。

請注意，上述限制符合標準的命名慣例 Java 程式設計語言中的 API；本節旨在 然後透過納入這個相容性的範圍 定義。

3.7.執行階段相容性

裝置實作方式：

  • [C-0-1] 必須支援完整的 Dalvik 執行檔 (DEX) 格式 以及 Dalvik 位元碼規格和語意。

  • [C-0-2] 必須設定 Dalvik 執行階段，才能分配記憶體 並依據上游 Android 平台指定的 下表。(詳情請參閱第 7.1.1 節)。 螢幕大小和螢幕密度定義)。

  • 應使用 Android RunTime (ART)， Dalvik 可執行格式實作，以及參考 實作套件管理系統

  • 應在各種執行模式下執行模糊測試 和目標架構，確保執行階段的穩定性詳情請參閱 爵士狂想 和 DexFuzz 。

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

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

3.8.使用者介面相容性

3.8.1。啟動器 (主畫面)

Android 提供啟動器應用程式 (主畫面) 和 取代裝置啟動器 (主畫面) 的第三方應用程式。

如果實作裝置可讓第三方應用程式替換裝置 主畫面，他們可以：

  • [C-1-1] 必須宣告平台功能 android.software.home_screen。
  • [C-1-2] 必須退回AdaptiveIconDrawable 物件使用 <adaptive-icon> 標記提供 其圖示，以及 PackageManager 擷取圖示的方法已獲得呼叫。

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

相反地，如果裝置的實作不支援應用程式內固定功能， 快速鍵：

如果裝置實作項目實作預設啟動器來提供快速回應 存取第三方應用程式提供的其他捷徑 ShortcutManager API 的運作方式具有以下特性：

  • [C-4-1] 必須支援所有記載的快速鍵功能 (例如 動態捷徑、固定捷徑)，並完全實作 ShortcutManager敬上 API 類別。

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

  • [C-5-1] 必須尊重NotificationChannel.setShowBadge() API 方法。 也就是說，如果應用程式圖示 將值設為 true，在所有結果顯示，不顯示任何應用程式圖示徽章配置 應用程式通知管道的值已設為 false。
  • 您可以改用專屬的徽章配置，取代應用程式圖示徽章 第三方應用程式表示公司獲得專屬徽章配置 使用專屬 API，但應使用資源和價值 透過 SDK 中所述的通知徽章 API 取得， 例如：Notification.Builder.setNumber() 和Notification.Builder.setBadgeIconType() 也能使用 Google Cloud CLI 或 Compute Engine API

如果裝置實作支援 單色 以下圖示：

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

3.8.2。小工具

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

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

  • [C-1-1] 必須聲明支援平台功能 android.software.app_widgets。
  • [C-1-2] 必須納入 AppWidgets 的內建支援和公開 新增、設定、查看和移除 AppWidgets 的使用者介面預設用途
  • [C-1-3] 必須能顯示 4 x 4 的小工具 標準格狀檢視請參閱應用程式小工具設計指南 。
  • 可能支援螢幕鎖定畫面上的應用程式小工具。

如果裝置實作項目支援第三方應用程式小工具和應用程式內 固定捷徑時，系統會執行以下動作：

3.8.3.通知

Android 包括 Notification 和 NotificationManager。 讓第三方應用程式開發人員透過 API 通知使用者值得注意的事件。 吸引使用者注意力使用硬體元件 (例如音效、震動) 和燈號) 和軟體功能 (例如通知欄、系統列) 的 裝置。

3.8.3.1。通知呈現方式

如果允許第三方應用程式在導入裝置時通知使用者重要事件，請注意以下事項：

  • [C-1-1] 必須支援使用硬體功能的通知，如 SDK 說明文件，並盡可能在裝置實作的情況下 硬體舉例來說，如果裝置導入作業內含震動功能，就「必須」 正確實作震動 API。如果裝置實作 硬體，相關的 API 「必須」是免人工管理來實作。這項行為是 詳情請參閱第 7 節。
  • [C-1-2] 必須正確轉譯所有資源 API 或 狀態/系統列圖示樣式指南， 但可能會在通知時提供替代的使用者體驗 而不是 Android 開放原始碼的 參考資料。
  • [C-1-3] 必須遵循並依照 API 更新、移除和群組通知。
  • [C-1-4] 必須提供 NotificationChannel 的完整行為 API 中載明的 API
  • [C-1-5] 必須提供使用者負擔，才能封鎖及修改 每個管道和應用程式套件層級的第三方應用程式通知。
  • [C-1-6] 也必須為使用者提供預設用途，允許顯示已刪除的通知 頻道。

  • [C-1-7] 必須正確轉譯所有資源 (圖片、貼紙、圖示等) 透過 Notification.MessagingStyle 通知文字旁，無需任何額外使用者互動。適用對象 例如，「必須」顯示所有資源，包括 android.app.Person 轉入群組對話中 setGroupConversation，藉此指定群組對話。

  • [C-SR-1] 強烈建議使用者提供應用程式 控管提供給以下應用程式的通知： 通知接聽器權限。精細程度必須能讓使用者 控制每個這類通知事件監聽器 橋接到這個事件監聽器類型「必須」包括「對話」、「快訊」 「靜音」和「重要的持續性」通知。

  • [C-SR-2] 強烈「建議」提供能讓使用者指定的預設用途 停止通知任何特定通知事件監聽器。

  • [C-SR-3] 強烈建議你盡量自動提供使用者負擔 針對每個管道和應用程式封鎖特定第三方應用程式的通知 使用者多次關閉該通知後的套件層級。

  • 應支援複合式通知。

  • 應以抬頭通知的形式呈現優先順序較高的通知。

  • 應讓使用者有足夠的需求來延後通知。

  • 「可能」僅管理第三方應用程式傳送通知的時機和時機 使用者所關注的事件，藉此減少駕駛人分心等安全問題。

Android 11 導入了對話通知的支援功能， 使用 MessagingStyle 的通知 並提供已發布的 People 捷徑 ID。

裝置實作方式：

如果裝置實作方式支援 conversation notifications 應用程式提供了必要的資料 bubbles，他們：

  • [C-SR-5] 強烈建議你以對話框形式顯示這個對話。 Android 開放原始碼計畫實作項目以預設的系統 UI 滿足上述要求。 「設定」和「啟動器」

如果裝置的實作支援複合式通知，就會發生以下狀況：

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

抬頭通知是一種 只會在使用者接觸曝光時， 保持開啟。如果裝置導入方式支援抬頭通知 然後執行下列操作：

  • [C-3-1] 必須使用抬頭通知檢視畫面和資源 ，如同 Notification.Builder 顯示抬頭通知時的 API 類別。
  • [C-3-2] 必須顯示經由 Notification.Builder.addAction()敬上 與通知內容一起出現，使用者不需進行額外互動 ，詳情請參閱 SDK。
3.8.3.2。通知接聽器服務

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

裝置實作方式：

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

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

  • [C-1-1] 必須正確反映延後通知的狀態 經由標準 API 傳送 NotificationListenerService.getSnoozedNotifications()。
  • [C-1-2] 必須授予這位使用者權限，讓他們能暫停通知 安裝您的應用程式，除非應用程式的來源 持續性/前景服務
3.8.3.3。DND (請勿打擾) / 優先模式

如果裝置實作支援 DND 功能 (又稱為「優先模式」)，他們可以：

  • [C-1-1] 必須「必須」適用於裝置的實作已為使用者提供方法 授予或拒絕第三方應用程式存取 DND 政策設定； 顯示自動 DND 規則 透過應用程式建立、結合使用者建立的規則。
  • [C-1-3] 必須尊重suppressedVisualEffects 透過 NotificationManager.Policy 傳送的值 如果應用程式已設定任何 SUPPRESSED_effective_SCREEN_OFF 或 SUPPRESSED_ff_SCREEN_ON 標記，此標記應告知使用者 DND 設定選單中隱藏視覺效果。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

3.8.3.4。機密通知保護

機密通知資訊包括動態密碼 一次性確認碼，以及類似的驗證或重設 可能會顯示在 通知 讓使用者享有低延遲和高可用性

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

  • [C-1-1] 必須遮蓋敏感通知資訊， 通知接聽器，除非監聽器服務為下列其中一個值：

    • 具有 uid 的系統簽署應用程式 <10,000 名
    • 系統 UI
    • 貝殼
    • 指定的隨附裝置應用程式 (由 CompanionDeviceManager 定義)
    • SYSTEM_AUTOMOTIVE_PROJECTION 個角色
    • SYSTEM_NOTIFICATION_INTELLIGENCE 個角色
    • 主畫面角色

Android 開放原始碼計畫實作 NotificationAssistantServices敬上 檢討並滿足這些需求詳情請見 android.ext.services.notification敬上 例如，

終止新規定

3.8.4。輔助 API

Android 包含輔助 API 讓應用程式能選取當目前背景所需的資訊量 分享給裝置上的助理。

如果裝置導入方式支援輔助動作，就會：

  • [C-2-1] 分享背景資訊時，必須向使用者明確指出 ：
    • 每當輔助應用程式存取內容時，畫面會顯示白色 畫面邊緣必須符合或超過時間長度 Android 開放原始碼計畫實作畫面的亮度。
    • 針對預先安裝的輔助應用程式，使用者能享有的負擔更低 兩人之間有大約兩個訪客 預設的語音輸入和 Google 助理應用程式設定選單， 並且只在由遠端叫用輔助應用程式的情況下，才分享背景資訊 使用者透過啟動字詞或輔助瀏覽鍵輸入內容
  • [C-2-2] 指定啟動輔助應用程式的互動行為 (如所述) 在第 7.2.3 節中，「必須」啟動使用者選取 輔助應用程式，也就是實作 VoiceInteractionService 的應用程式。 或是處理 ACTION_ASSIST 意圖的活動

3.8.5。快訊與浮動式訊息

應用程式可以使用 Toast 這個 API 可以向使用者顯示在 使用 TYPE_APPLICATION_OVERLAY 視窗類型 API，在其他應用程式上方以重疊方式顯示快訊視窗。

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

  • [C-1-1] 「必須」提供使用者權限，禁止應用程式顯示快訊 使用 TYPE_APPLICATION_OVERLAY 的視窗。 Android 開放原始碼計畫實作項目必須在通知欄中提供控制項，以符合這項規定。

  • [C-1-2] 必須遵循 Toast API，並在部分高層級向使用者顯示應用程式浮動式訊息 顯示方式

3.8.6。主題

Android 提供「主題」做為應用程式套用樣式的機制 整個活動或應用程式

Android 內建「Holo」和「材質」是一組已定義的樣式 供應用程式開發人員使用 Holo 主題外觀和風格 符合 Android SDK 的定義

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

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

  • [C-1-3] 必須設定「sans-Serif」字型系列 適用於語言的 Roboto 2.x 版 也讓使用者能夠自行選擇合適的字型 代表「sans-Serif」Roboto 2.x 版的字型系列 以及 Roboto 支援的語言

  • [C-1-4] 必須產生 Android 開放原始碼計畫中指定的動態調色盤 Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES 說明文件 (請參閱 「android.theme.customization.system_palette」和 android.theme.customization.theme_style)。

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

    「來源顏色」每次傳送 android.theme.customization.system_palette (如記錄於 Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES)。

  • [C-1-6] CAM16 色域值必須大於或等於 5。

    • 是否應該透過 com.android.systemui.monet.ColorScheme#getSeedColors，提供 有多種有效的來源顏色可供選擇。

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

Android 還包含「裝置預設設定」是一組已定義的樣式 供應用程式開發人員使用 根據裝置實作者定義的裝置主題。

Android 支援具有半透明系統資訊列的變化版本主題， 以便填滿狀態和導覽列後方的區域 與應用程式內容互動為了在此提供一致的開發人員體驗 您必須在整個容器中保留狀態列圖示樣式 不同的裝置導入方式

如果裝置導入方式包含系統狀態列，就會：

  • [C-2-1] 系統狀態圖示 (例如訊號強度和 電池電量) 以及系統所發出的通知，除非該圖示 表示有問題的狀態，或者應用程式要求顯示光源狀態列， WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS 旗標。
  • [C-2-2] 實作 Android 裝置時，「必須」變更系統顏色 在應用程式出現時，將狀態圖示變成黑色 (詳情請參閱 R.style) 要求顯示淺色狀態列

3.8.7。動態桌布

Android 定義了元件類型和對應的 API 和生命週期 來公開一或多個應用程式 「動態桌布」 供使用者參考動態桌布是動畫、圖案或類似的圖片 因為輸入功能有限，顯示為桌布、背後其他圖片 應用程式。

只要硬體能穩定運作，就被視為能夠穩定執行動態桌布 所有動態桌布，且功能不受限 而不會對其他應用程式造成負面影響。如果 硬體 會造成桌布和/或應用程式當機、故障、消耗 CPU 或電池耗電量過多，或是執行時超出影格速率上限 硬體視為無法執行動態桌布舉例來說 動態桌布可能會使用 OpenGL 2.0 或 3.x 內容來顯示內容。 在不支援多重功能的硬體上，動態桌布將無法穩定執行 OpenGL 結構定義，因為動態桌布使用 OpenGL 結構定義時可能會發生衝突 與其他使用 OpenGL 內容的應用程式互動。

  • 裝置實作，可穩定地執行動態桌布 。

如果裝置實作的是動態桌布，動態桌布會：

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

3.8.8。活動切換

上游 Android 原始碼包含 總覽畫面， 系統層級的使用者介面，用於切換工作並顯示最近存取過的項目 透過應用程式圖形 狀態。

裝置實作 包括近期函式瀏覽鍵，詳情請參閱 第 7.2.3 節 自訂介面。

如果裝置實作項目包含最近使用的功能瀏覽鍵，詳情如下： 第 7.2.3 節修改介面：

  • [C-1-1] 最多只能支援 7 個顯示活動。
  • 一次至少應顯示 4 項活動的標題。
  • 應在近期顯示醒目顯示顏色、圖示和畫面標題。
  • 應顯示關閉的預設用途 (「x」)，但可能要等到使用者與螢幕互動後再執行。
  • 「應」導入捷徑，以便輕鬆切換至上一個活動。
  • 應在最近使用的兩個金鑰間觸發快速切換動作 應用程式。
  • 在支援的情況下，應觸發分割畫面多視窗模式 (如果支援的話) 長按最近函式鍵。
  • 可能顯示有關聯的近期資訊群組。
  • [C-SR-1] 強烈建議使用上游 Android 使用者 總覽畫面 (或類似的縮圖式介面)。

3.8.9。輸入管理

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

如果裝置實作方式允許使用者在 這些裝置，他們可以：

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

3.8.10。螢幕鎖定媒體控制項

Remote Control Client API 已從 Android 5.0 淘汰，改用 媒體通知範本 可讓媒體應用程式整合 。

3.8.11。螢幕保護程式 (先前為 Dream)

請參閱第 3.2.3.5 節的設定 表明瞭需要消弭螢幕保護程式的意圖

3.8.12。位置

如果裝置實作項目內含支援 GPS 的硬體感應器 (例如 GPS) 提供位置座標

3.8.13。萬國碼 (Unicode) 和字型

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

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

  • [C-1-1] 必須能夠以色彩字符轉譯這些表情符號字元。
  • [C-1-2] 必須支援下列項目：
    • Roboto 2 字型粗細不同：sans-Serif-thin、Sans-Serif-light Sans-Serif-medium、Sans-Serif-black、Sans-Serif-condensed Sans-Serif 冷凝型燈 (適用於裝置支援的語言)。
    • 完整 Unicode 7.0 涵蓋拉丁、希臘和西里爾文，包括 拉丁擴充 A、B、C 和 D 範圍，以及貨幣中的所有字符 Unicode 7.0 的符號區塊。
  • [C-1-3] 不得移除或修改系統映像檔中的 NotoColorEmoji.tff。 (您可以新增表情符號字型來覆寫表情符號中的表情符號，但 NotoColorEmoji.tff
  • 應支援 Unicode 技術報告 #51。

如果裝置實作項目包含輸入法編輯器，則會：

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

Android 支援轉譯緬甸字型。緬甸擁有好幾個 不符合 Unicode 規範的字型，一般稱為「Zawgyi」轉譯緬甸 語言。

如果裝置的實作選項支援緬甸文，請注意：

  • [C-2-1] 預設顯示文字時，必須使用符合 Unicode 標準的字型。 除非使用者，否則非萬國碼 (Unicode) 規定的字型「不得」設為預設字型 即可在語言選單中選取所需項目
  • [C-2-2] 必須支援 Unicode 字型，以及不符合 Unicode 規範的字型 裝置使用不符合 Unicode 規定的字型。非萬國碼 (Unicode) 相容字型「不得」移除或覆寫 Unicode 字型。
  • [C-2-3] 只有在 語言代碼 指令碼程式碼 Qag (例如 my-Qag)。沒有其他 ISO 語言或區碼 ( 指派、未指派或保留) 可用於參照非萬國碼 (Unicode) 符合緬甸的字型應用程式開發人員和網頁作者 請將 my-Qag 指定為指定語言代碼 或其他語言。

3.8.14。多視窗模式

如果裝置實作支援在以下位置顯示多項活動： 同時也：

  • [C-1-1] 必須根據 Android SDK 中描述的應用程式行為和 API 多視窗模式支援說明文件，以及 Meet 下列要求：
  • [C-1-2] 必須尊重android:resizeableActivity 由應用程式設定，如 AndroidManifest.xml 檔案所述 此 SDK
  • [C-1-3] 如果是使用分割畫面或任意形式模式，就「不得」提供 螢幕高度小於 440 dp，且螢幕寬度小於 440 dp。
  • [C-1-4] 活動的大小「不得」將大小調整為小於 220 dp 子母畫面模式以外的多視窗模式。
  • 裝置實作且螢幕大小 xlarge 必須支援任意形式 模式。

如果裝置實作項目支援多視窗模式，以及分割畫面 模式，就會：

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

如果裝置實作支援多視窗模式和子母畫面模式 多視窗模式的作用：

  • [C-3-1] 必須在子母畫面多視窗模式下啟動活動 以下情況表示： * 指定 API 級別 26 以上並宣告 android:supportsPictureInPicture敬上 * 指定 API 級別為 25 以下，並宣告 android:resizeableActivity 和 android:supportsPictureInPicture。
  • [C-3-2] 必須按照 由目前子母畫面活動透過 setActions() 指定 也能使用 Google Cloud CLI 或 Compute Engine API
  • [C-3-3] 支援的長寬比必須大於或等於 1:2.39 且小於或等於 2.39:1，由子母畫面活動指定 setAspectRatio() 也能使用 Google Cloud CLI 或 Compute Engine API
  • [C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如未執行子母畫面模式，關鍵就「必須」 可用在前景活動中。
  • [C-3-5] 「必須」提供使用者負擔，禁止應用程式顯示 子母畫面模式；能夠符合這項規定 。

  • [C-3-6] 請務必為子母畫面分配下列寬度和高度下限 未宣告任何 AndroidManifestLayout_minWidth敬上 和 AndroidManifestLayout_minHeight：

    • 未正確設定 Configuration.uiMode 的裝置 UI_MODE_TYPE_TELEVISION敬上 必須分配最小寬度和高度為 108 dp。
    • 已設定 Configuration.uiMode 的裝置 UI_MODE_TYPE_TELEVISION敬上 請分配最小寬度為 240 dp，高度下限為 135 dp。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置實作項目包含多個 Android 相容 以及向應用程式提供這類區域的功能：

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

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

終止新規定

3.8.15。螢幕去背

如同上所述，Android 支援螢幕凹口 。DisplayCutout API 會定義 螢幕邊緣不對應用程式而言不作用的區域 這會導致裝置使用螢幕凹口或曲線顯示。

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

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

3.8.16。裝置控制

Android 包括 ControlsProviderService 和 Control 方便第三方應用程式發布裝置控制項的 API 狀態和動作

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

3.8.17。剪貼簿

裝置實作方式：

如果裝置導入方式會在複製內容時產生使用者可見的預覽 複製到剪貼簿的任何 ClipData 項目 ClipData.getDescription().getExtras()包含 android.content.extra.IS_SENSITIVE，他們：

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

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

3.9.裝置管理

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

Android 內建多項功能， 應用程式 啟用 裝置政策控制器應用程式 裝置管理功能，例如強制設定密碼 或執行遠端清除 Android Device 管理 API Device Policy Manager API。

如果裝置實作項目實作完整的裝置管理範圍， ：

  • [C-1-1] 必須宣告 android.software.device_admin。
  • [C-1-2] 必須依照下列說明支援裝置擁有者佈建作業 第 3.9.1 節和 第 3.9.1.1 節。

終止新規定

3.9.1。裝置佈建

3.9.1.1。裝置擁有者佈建

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

  • [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為 裝置擁有者應用程式 如下所述：
    • 當裝置實作 使用者或 使用者資料設定後
      • [C-1-5] 必須註冊 DPC 應用程式做為裝置擁有者應用程式 或啟用裝置政策控制器 (DPC) 應用程式 成為裝置擁有者或設定檔擁有者 如果裝置透過 功能旗標 android.hardware.nfc 並收到 NFC 訊息 包含 MIME 類型的記錄 MIME_TYPE_PROVISIONING_NFC。
      • [C-1-8] 必須傳送 ACTION_GET_PROVISIONING_MODE 意圖並取得裝置擁有者佈建後的流量 DPC 應用程式可以選擇成為裝置擁有者或設定檔 擁有者，視 android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, 除非能在 這兩個內容只有一個有效選項。
      • [C-1-9] 必須 ACTION_ADMIN_POLICY_COMPLIANCE 提供給裝置擁有者應用程式的意圖 (如果已建立裝置擁有者) 佈建狀態。 使用者必須必須等到 完成「裝置擁有者」應用程式的設定。
    • 當裝置實作 或使用者 使用者資料時，它會：
      • [C-1-7] 不得將任何 DPC 申請註冊為裝置擁有者應用程式 。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-2] 必須顯示適當的揭露通知 (例如 Android 開放原始碼計畫參照) 的應用程式，並在應用程式前取得使用者的確認同意 設為裝置擁有者 (除非裝置是透過程式輔助方式設定) 適用於零售商展示模式 並未顯示在畫面上， 如果裝置實作項目宣告了 android.software.device_admin，但同時宣告了 包含 裝置管理解決方案並提供相關機制 ，將解決方案中設定的應用程式升級為「裝置擁有者」 等值」標準「裝置擁有者」如標準 Android 系統辨識的 DevicePolicyManager API 具有以下特點：

  • [C-2-1] 必須設有專門程序，才能驗證特定應用程式 促銷屬於合法企業裝置管理 並已在專屬解決方案中設定 取得與「裝置擁有者」同等的權利。

  • [C-2-2] 必須顯示與 由 android.app.action.PROVISION_MANAGED_DEVICE 發起的資料流 ，以「裝置擁有者」的身分註冊 DPC 應用程式。

  • [C-2-3] 不得以硬式編碼的方式寫入同意聲明或禁止事項 使用其他裝置擁有者的應用程式

終止新規定

3.9.1.2。受管理設定檔佈建

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

終止新規定

3.9.2。支援受管理設定檔

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

  • [C-1-1] 必須支援透過android.app.admin.DevicePolicyManager管理受管理的設定檔 相互整合
  • [C-1-2] 只能建立一個受管理的設定檔。
  • [C-1-3] 必須使用圖示徽章 (類似 Android 開放原始碼計畫上游工作徽章)，才能 代表受管理的應用程式和小工具，以及其他標記的 UI 元素 例如「近期」和通知。
  • [C-1-4] 必須顯示通知圖示 (類似 Android 開放原始碼計畫上游工作) 徽章)，表示使用者何時屬於受管理的設定檔應用程式。
  • [C-1-5] 必須顯示浮動式訊息，指出使用者有受管理 設定檔是否喚醒，以及裝置喚醒的時間點 (ACTION_USER_PRESENT) 前景應用程式位於受管理的設定檔中。
  • [C-1-6] 如果有受管理的設定檔，「必須」在 意圖「選擇者」可讓使用者從代管式 VPN 閘道 將設定檔還原為主要使用者，反之亦然 控制器。
  • [C-1-7] 如果有受管理的設定檔，「必須」揭露下列使用者 主要使用者和受管理設定檔可實現的功能：
    • 將電池、位置、行動數據和儲存空間用量分開計算 。
    • 獨立管理安裝在主要伺服器中 或受管理的設定檔
    • 獨立管理主要使用者在當中安裝的應用程式 或受管理的設定檔
    • 獨立管理主要使用者或受管理使用者的帳戶
  • [C-1-8] 必須確保預先安裝的撥號程式、聯絡人和訊息 應用程式可在受管理的 Android 裝置上搜尋及查詢來電者資訊 以及主要設定檔的資料 (如果有的話) 根據 Device Policy Controller 允許
  • [C-1-9] 必須確認符合所有安全性需求 適用於多位使用者啟用的使用者 (請參閱第 9.5 節)，即使是受管理的設定檔也一樣 則不計入主要使用者以外的其他使用者。
  • [C-1-10] 必須確認螢幕截圖資料會儲存在工作資料夾中 儲存空間 (如果使用 topActivity敬上 含有焦點的視窗 (使用者上次在所有活動中互動的時間) 並屬於 工作資料夾應用程式。
  • [C-1-11] 「不得」擷取任何其他螢幕內容 (系統資訊列、 通知或任何個人資料夾內容)，但工作資料夾除外 應用程式 window/windows 避免將螢幕截圖儲存到工作資料夾 (為了確保個人安全， 設定檔資料不會儲存在工作資料夾中)。

如果裝置實作方式宣告了 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 開放原始碼計畫裝置擁有者顯示同意聲明 在由 Google 發起的流程中， android.app.action.PROVISION_MANAGED_DEVICE、 才能將帳戶加入新的次要「使用者」 以便使用者瞭解裝置受到管理

3.9.4。Device Policy Management 角色需求條件

如果裝置導入作業回報 android.software.device_admin 或 android.software.managed_users，然後他們：

  • [C-1-1] 必須支援裝置政策管理角色 (如 第 9.1 節。擁有裝置政策管理角色的應用程式 可以透過將 config_devicePolicyManagement 設為套件名稱來定義。 除非預先載入應用程式，否則套件名稱後面必須加上 : 以及簽署憑證。

如果 config_devicePolicyManagement 的套件名稱未定義為 前提：

如果按照上述說明為 config_devicePolicyManagement 定義了套件名稱 以上：

  • [C-3-1] 所有應用程式都必須安裝 設定檔 適用於使用者。
  • [C-3-2] 裝置實作可能會定義更新 佈建前的裝置政策管理角色擁有者 config_devicePolicyManagementUpdater。

如果將 config_devicePolicyManagementUpdater 的套件名稱定義為 前提：

  • [C-4-1] 應用程式「必須」預先安裝在裝置上。
  • [C-4-2] 應用程式「必須」實作意圖篩選器， android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER。

3.9.5。裝置政策解決架構

如果裝置導入作業回報 android.software.device_admin 或 android.software.managed_users，然後他們：

3.10.無障礙設定

Android 提供的無障礙工具層，可協助身心障礙使用者 也能更輕鬆地瀏覽裝置此外，Android 也提供平台 API 可讓無障礙服務實作以接收使用者的回呼 並產生替代回饋機制 文字轉語音、觸覺回饋和軌跡球/D-Pad 導航。

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

  • [C-1-1] 必須實作 Android 無障礙功能 使用 PersistentVolumeClaim Accessibility API SDK 說明文件。
  • [C-1-2] 必須產生無障礙功能事件，並提供適當的 所有已註冊的AccessibilityEvent AccessibilityService 按照 SDK 中的指示執行。
  • [C-1-4] 必須提供使用者授權，讓他們控管無障礙功能 宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON。 請注意，對於具有系統導覽列的裝置實作項目， 應讓使用者能在系統的 導覽列控管這些服務

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

  • [C-2-1] 必須按照 直接啟動感知 應用程式。
  • 使用者應在開箱的設定流程中，提供可啟用機制的機制 相關無障礙服務 以及調整字型大小的選項 顯示大小和放大手勢

3.11.文字轉語音

Android 提供的 API 可讓應用程式使用文字轉語音 服務，並讓服務供應商能夠實作 TTS 免費 Google Cloud 服務

如果裝置實作回報功能 android.hardware.audio.output， 他們會：

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

  • [C-2-1] 必須提供使用者優先度，讓使用者能夠選取 TTS 要在系統層級使用

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

3.12.電視輸入架構

Android 電視輸入架構 (TIF) 簡化了 向 Android TV 裝置提交直播內容。TIF 提供了 提供 API，用於建立控制 Android Television 裝置的輸入模組。

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

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

終止新規定

3.13.快速設定

Android 提供快速設定 UI 元件，可讓使用者快速存取 或迫切需要的動作

如果實作的裝置包含快速設定 UI 元件，並支援第三方 「快速設定」頁面的用途：

  • [C-1-1] 必須允許使用者新增或移除透過 quicksettings敬上 API 限制。
  • [C-1-2] 「不得」直接從第三方應用程式自動新增資訊方塊 加入「快速設定」選單
  • [C-1-3] 必須顯示使用者在第三方應用程式中新增的所有資訊方塊 旁邊還有系統提供的快速設定方塊。

3.14。媒體使用者介面

如果裝置的實作方式含有無法啟動語音操作的應用程式 (也就是與應用程式互動的應用程式)， 使用 MediaBrowser 建立第三方應用程式 或 MediaSession， 應用程式：

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

  • [C-1-3] 顯示 使用這個第三方應用程式

  • [C-1-4] 必須允許使用者與整個 MediaBrowser 互動 階層為遵循安全法規，「可能」限制部分階層人員的存取 (例如駕駛人分心)，但「不得」根據內容或 內容供應器。

  • [C-1-5] 必須考慮輕觸兩下 KEYCODE_HEADSETHOOK敬上 或 KEYCODE_MEDIA_PLAY_PAUSE 使用身分：KEYCODE_MEDIA_NEXT 新機 MediaSession.Callback#onMediaButtonEvent。

3.15.免安裝應用程式

如果裝置實作項目支援免安裝應用程式，就必須符合下列規定： 規定：

  • [C-1-1] 免安裝應用程式只能取得具有 android:protectionLevel敬上 已設為 "instant"。
  • [C-1-2] 免安裝應用程式「不得」透過隱含意圖與已安裝的應用程式互動 除非符合下列任一條件：
    • 此元件的意圖模式篩選器已公開，且具有 CATEGORY_BROWSABLE
    • 這個動作可以是下列其中之一：ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE
    • 系統已透過 android:visibleToInstantApps 明確公開目標
  • [C-1-3] 除非 元件是透過 android:visibleToInstantApps 公開
  • [C-1-4] 已安裝的應用程式「不得」在 除非免安裝應用程式明確連線至 已安裝的應用程式。

  • 裝置實作「必須」提供下列使用者負擔 與免安裝應用程式互動Android 開放原始碼計畫符合 預設系統 UI、設定和啟動器裝置實作方式：

    • [C-1-5] 必須為使用者提供權限，才能查看及刪除免安裝應用程式 以便針對每個個別應用程式套件 使用本機快取功能
    • [C-1-6] 必須向使用者提供有效通知 會在前景執行免安裝應用程式時收合。這位使用者 通知「必須」說明免安裝應用程式不必安裝 並提供引導使用者前往應用程式的功能 資訊畫面。對於透過網路意圖啟動的免安裝應用程式，如 定義方法是使用動作設為 Intent.ACTION_VIEW 的意圖 配置為「http」或「https」； 不得讓使用者啟動免安裝應用程式，並 啟動與所配置網路瀏覽器相關的連結 (如果瀏覽器) 可用位置。
    • [C-1-7] 必須允許「最近」存取執行中的免安裝應用程式 函式 (如果有的話)。

  • [C-1-8] 必須預先載入一或多個應用程式或服務元件 這裡包含 SDK 所列意圖的意圖處理常式，以及該意圖的處理常式 以及顯示免安裝應用程式的意圖

3.16.配對裝置配對

Android 支援配對裝置配對功能，可提升管理效率 與隨附裝置建立關聯，並提供 CompanionDeviceManager 。

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-3] 必須提供使用者功能，供使用者選取/確認 配對裝置並且正常運作。 這些訊息「必須」使用與 Android 開放原始碼計畫中 相同的訊息，且不得加上 修改。

終止新規定

3.17. 重量級應用程式

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

  • [C-1-1] 「必須」僅安裝一個指定 cantSaveState敬上 一次在系統中執行如果使用者 使用者未明確離開應用程式 (例如按下 在家模式期間離開系統活動，而非按下返回按鈕 系統中沒有剩餘的活動)，那麼 裝置實作項目必須像在其他用途上一樣，在 RAM 中優先執行該應用程式 例如前景服務 當這類應用程式在背景執行時，系統仍可使用電力 例如限制 CPU 和網路存取權
  • [C-1-2] 必須提供 UI 預設用途，以便選擇不會 在使用者行為後參與正常狀態儲存/還原機制 啟動使用 cantSaveState 宣告的第二個應用程式 屬性。
  • [C-1-3] 「不得」將政策中的其他變更套用到指定的應用程式 cantSaveState、 例如變更 CPU 效能或變更排程優先順序

如果裝置實作方式未宣告這項功能 FEATURE_CANT_SAVE_STATE、 然後：

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

3.18.聯絡人

Android 包括 Contacts Provider敬上 運用 API，讓應用程式管理裝置上儲存的聯絡資訊。 直接輸入裝置上的聯絡人資料通常會保持同步 透過 Web 服務存取資料，但資料「可能」只會儲存在裝置上。 只儲存在裝置上的聯絡人稱為「本機」 聯絡人。

RawContacts 是否「相關聯」或「已儲存於」換 帳戶 當 ACCOUNT_NAME, 和 ACCOUNT_TYPE， 原始聯絡人欄中的 帳戶名稱 和 Account.type 欄位。

預設本機帳戶：存放原始聯絡人的帳戶 裝置，但未與 AccountManager 包含 空值 值 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 或是未指定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

3.19.語言設定

裝置實作方式：

  • [C-0-1] 「不得」針對特定性別提供任何使用者負擔 針對不支持文法性別的語言 翻譯工作請參閱文法資源 瞭解詳情

終止新規定

4. 應用程式封裝的相容性

裝置實作方式：

  • [C-0-1] 必須能夠安裝及執行 Android「.apk」做為 「aapt」產生的隨機標記使用 GCP 控制台中的 官方 Android SDK

    • 上述規定可能比較困難，因此裝置實作後的 建議使用 Android 開放原始碼計畫參考資料實作項目的套件管理功能 有些人會將 Cloud Storage 視為檔案系統 但實際上不是

  • [C-0-2] 必須支援驗證「.apk」方法是使用 APK Signature Scheme v3.1， APK Signature Scheme v3， APK 簽署配置 v2 和 JAR 簽署中。

  • [C-0-3] 不得延伸 .apk、 Android 資訊清單， Dalvik 位元碼，或 RenderScript 位元碼格式時，可避免這些檔案 安裝在其他相容裝置上正常執行。

  • [C-0-4] 不得允許現有應用程式以外的應用程式 "記錄安裝者"，以便套件在無訊息的情況下解除安裝應用程式 使用者確認，如 SDK 中 DELETE_PACKAGE敬上 權限。唯一的例外狀況是系統套件驗證器應用程式處理 PACKAGE_NEEDS_VERIFICATION 意圖和 Storage Manager 應用程式 ACTION_MANAGE_STORAGE 意圖。

  • [C-0-5] 必須包含能夠處理 android.settings.MANAGE_UNKNOWN_APP_SOURCES敬上 意圖。

  • [C-0-6] 不得安裝不明來源的應用程式套件 來源 (要求安裝的應用程式除外) 符合下列所有條件：

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

  • 「應」提供使用者負擔，讓他們授予/撤銷 為每個應用程式安裝不明來源的應用程式，但也可選擇實作 視為免人工管理，並傳回RESULT_CANCELED startActivityForResult(), 。 不過即使如此，他們也應該向使用者說明 給予支援

  • [C-0-7] 「必須」顯示警告對話方塊，內含 透過系統 API PackageManager.setHarmfulAppWarning 提供 在應用程式中啟動活動之前，表示已標記為 由相同的系統 API PackageManager.setHarmfulAppWarning 進行，與可能 有害。

  • 「應」提供使用者負擔，讓他們選擇解除安裝或啟動 是否套用了警告對話方塊

  • [C-0-8] 必須依文件說明，導入漸進式檔案系統的支援功能 請按這裡。

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

，瞭解如何調查及移除這項存取權。

5. 多媒體相容性

裝置實作方式：

  • [C-0-1] 必須支援媒體格式、編碼器、解碼器、檔案類型 以及第 5.1 節中定義的容器格式 的每個轉碼器。MediaCodecList。
  • [C-0-2] 必須宣告及回報對編碼器和解碼器的支援 透過 Cloud Shell 的指令列 MediaCodecList。
  • [C-0-3] 必須能正確解碼，並提供給第三方 應用程式可編碼的所有格式這包括 產生及回報的剖析檔 CamcorderProfile。

裝置實作方式：

  • 應盡量縮短轉碼器延遲時間，換句話說
    • 不應使用及儲存輸入緩衝區，且只傳回輸入緩衝區 加以處理
    • 「不得」保留超過 標準 (例如 SPS)。
    • 「不得」保留超過 GOP 所需時間的編碼緩衝區 成本中心的架構

下一節列出的所有轉碼器都是以軟體形式提供 在 Android Open 上，偏好 Android 實作中的實作 來源專案。

請注意，Google 或開放手機聯盟均不 表示這些轉碼器不在第三方專利中。這些 建議您打算在硬體或軟體產品中使用此原始碼 包括開放原始碼軟體中的 共用軟體可能會要求相關專利持有人的專利授權。

5.1. 媒體轉碼器

5.1.1.音訊編碼

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

如果裝置實作方式宣告 android.hardware.microphone 它們「必須」支援將下列音訊格式編碼，以便提供 提供第三方應用程式存取權

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

所有音訊編碼器「必須」支援：

  • [C-3-1] 透過 android.media.MediaCodec 使用 PCM 16 位元原生位元組順序音訊影格 也能使用 Google Cloud CLI 或 Compute Engine API

5.1.2.音訊解碼

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

如果裝置導入方式宣告支援 android.hardware.audio.output 功能，必須支援 下列音訊格式：

  • [C-1-1] MPEG-4 AAC 設定檔 (AAC LC)
  • [C-1-2] MPEG-4 HE AAC 設定檔 (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 設定檔 (增強 AAC+)
  • [C-1-4] AAC ELD (強化型低延遲 AAC)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 擴充 HE AAC 設定檔)，內含 USAC 基準設定檔和 ISO/IEC 23003-4 動態範圍 控管設定檔)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] 麻省理工學院
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE 包含高解析度音訊 最高 24 位元、192 kHz 取樣率和 8 個頻道。 請注意，這項規定僅適用於解碼，且該作業是指 可在播放階段進行向下取樣和向下混音。
  • [C-1-10] Opu

如果裝置導入方式支援解碼 AAC 輸入緩衝區， 從預設管道串流到 PCM android.media.MediaCodec API 中的 AAC 音訊解碼器必須符合以下條件 支援：

  • [C-2-1] 必須執行解碼作業，才能進行解壓縮 (例如 5.0 AAC)。 串流必須解碼為五個 PCM 管道，5.1 AAC 串流必須解碼 高達六個管道)
  • [C-2-2] 動態範圍中繼資料必須依照「動態範圍控制」中的定義 (剛果民主共和國)，並將 android.media.MediaFormat DRC 金鑰設為 設定音訊解碼器的動態範圍相關行為 AAC DRC 金鑰是在 API 21 中導入，如下所示： KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、 KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL和 KEY_AAC_ENCODED_TARGET_LEVEL。
  • [C-SR-1] 強烈建議你遵守上述要求 C-2-1 和 C-2-2 的規定 滿足所有 AAC 音訊解碼器的需求

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

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

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

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

如果系統支援 ISO/IEC 23003-4，以及 ISO/IEC 23003-4 和 ISO/IEC 14496-3 中繼資料會以已解碼的位元流表示，然後：

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

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

  • [C-6-1] 透過 android.media.MediaCodec 使用 PCM 16 位元原生位元組順序音訊影格 也能使用 Google Cloud CLI 或 Compute Engine API

如果裝置導入方式支援解碼 AAC 輸入緩衝區， 從預設管道串流到 PCM android.media.MediaCodec API 中的 AAC 音訊解碼器，則「必須」 支援：

  • [C-7-1] 應用程式必須能使用解碼功能進行設定 使用按鍵 KEY_MAX_OUTPUT_CHANNEL_COUNT敬上 控制內容是否由立體聲調低混音為立體聲 (使用 2 的值時) 或是透過原生通道數輸出 (如果使用的值等於或 )。舉例來說，如果值設為 6 以上 解碼器，以便在提供 5.1 內容時輸出 6 個頻道。
  • [C-7-2] 解碼時，解碼器「必須」宣傳所用的頻道遮罩 對輸出格式執行 KEY_CHANNEL_MASK敬上 索引鍵，使用 android.media.AudioFormat 常數 (例如： CHANNEL_OUT_5POINT1)。

如果裝置實作支援非預設 AAC 以外的音訊解碼器 音訊解碼器，且能夠輸出多聲道音訊 ( 2 個聲道)，然後：

  • [C-SR-2] 我們強烈建議使用解碼器設定解碼器 建構應用程式 KEY_MAX_OUTPUT_CHANNEL_COUNT敬上 控制內容是否由立體聲調低混音為立體聲 (使用 2 的值時) 或是透過原生通道數輸出 (如果使用的值等於或 )。舉例來說，如果值設為 6 以上 解碼器，以便在提供 5.1 內容時輸出 6 個頻道。
  • [C-SR-3] 解碼時，強烈建議使用解碼器來宣傳 使用 KEY_CHANNEL_MASK敬上 鍵，使用 android.media.AudioFormat 常數 (例如： CHANNEL_OUT_5POINT1)。

5.1.3.音訊轉碼器詳細資料

格式/轉碼器 詳細說明 支援的檔案類型/容器格式
MPEG-4 AAC 設定檔
(AAC LC)		 支援標準級單聲道/立體聲/5.0/5.1 內容 取樣率從 8 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
  • ADTS 原始 AAC (不支援 .aac、ADIF)
  • MPEG-TS (.ts，不可搜尋，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MPEG-4 HE AAC 設定檔 (AAC+) 支援標準級單聲道/立體聲/5.0/5.1 內容 取樣率從 16 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
MPEG-4 HE AACv2
設定檔 (加強型 AAC+)		 支援標準級單聲道/立體聲/5.0/5.1 內容 取樣率從 16 至 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
AAC ELD (強化低延遲 AAC) 支援採標準取樣率介於 16 至 16 之間的單聲道/立體聲內容 48 kHz。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
美國運通 支援採用標準取樣率 7.35 的單聲道/立體聲內容 高達 48 kHz MPEG-4 (.mp4、.m4a)
美國醫力軍 4.75 到 12.2 kbps 取樣時 @ 8 kHz 3GPP (.3gp)
AMR-WB 9 速率從每秒 6.60 kbit 到 23.85 kbit/s 取樣 @ 16 kHz，定義請見 AMR-WB，自動調整多速率音訊 - 寬頻語音轉碼器 3GPP (.3gp)
FLAC 編碼器和解碼器都至少要具備單聲道和立體模式 支援。必須支援高達 192 kHz 的取樣率；16 位元和 24 位元 解析度必須受支援。必須處理 FLAC 的 24 位元音訊資料 與浮點音訊設定搭配使用。
  • FLAC (.flac)
  • MPEG-4 (僅限 .mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MP3 單聲道/立體聲 8 至 320 Kbps 常數 (CBR) 或可變位元率 (VBR)
  • MP3 (.mp3)
  • MPEG-4 (僅限 .mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MIDI MIDI 類型 0 和 1。DLS 第 1 版和第 2 版。XMF 和 Mobile XMF。支援： 鈴聲格式 RTTTL/RTX、OTA 和 iMelody
  • 輸入 0 和 1 (.mid、.xmf、.mxmf)
  • RTTTL/RTX (.rtttl、.rtx)
  • iMelody (.imy)
Vorbis 解碼：使用取樣功能支援單聲道、立體聲、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 位元浮點值。華盛頓 擷取器必須支援 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 和基準設定檔。

如果裝置導入方式支援 HEIC 編碼 (透過 android.media.MediaCodec) 媒體類型為 MIMETYPE_IMAGE_ANDROID_HEIC， 他們會：

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

5.1.6.圖片轉碼器詳細資料

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

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

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

  • [C-SR-1] 強烈建議為輸入介面支援 RGB888 色彩格式 模式。

  • [C-1-3] 必須支援至少一種平面或半平面 YUV420 8:8:8 顏色格式：COLOR_FormatYUV420PackedPlanar (等同於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (相當於 至 COLOR_FormatYUV420SemiPlanar)。強烈建議各位提供支援 兩者。

5.1.7.視訊轉碼器

  • 提供可接受的網路影片串流和視訊會議品質 服務、裝置導入方式 「必須」使用符合 requirements。

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

  • [C-1-1] 視訊轉碼器必須支援輸出和輸入位元組緩衝區大小 能容納最大可行的壓縮和未壓縮影格 但也不會過度分配

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

  • [C-1-3] 視訊編碼器和解碼器「必須」支援至少一個平面或解碼器 半平面 YUV420 8:8:8 顏色格式：COLOR_FormatYUV420PackedPlanar (相當於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (相當於 COLOR_FormatYUV420SemiPlanar)。 因此強烈建議你同時支援這兩種格式。

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

  • [C-1-5] 支援高位元深度格式的影片解碼器 (每個通道 9 位元以上) 如果符合下列條件，則必須支援輸出 8 位元等值格式： 應用程式要求的所有憑證「必須」藉由支持 透過 android.media.MediaCodecInfo 使用 YUV420 8:8:8 色彩格式。

如果裝置實作方式透過以下方式宣傳 HDR 設定檔支援 Display.HdrCapabilities、 他們會：

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

若裝置導入方式採用內部重新整理支援，可透過 MediaCodecInfo.CodecCapabilities中的 FEATURE_IntraRefresh 類別，他們：

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

除非應用程式另行使用 KEY_COLOR_FORMAT 格式鍵、影片解碼器實作：

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

5.1.8。影片轉碼器清單

格式/轉碼器 詳細說明 支援的檔案類型/容器格式
標題 263
  • 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 或轉碼器 2.0 提供媒體轉碼器支援 Android 開放原始碼專案中的 API (或兩者皆用)，且不會停用或 規避安全保護措施但這不表示 轉碼器「必須」使用支援 OMX 或 Codec 2.0 API 的 API， 系統「必須」提供多種 API，且「必須」支援可用的 API 內建安全防護機制
  • [C-SR-1] 強烈建議你加入 Codec 2.0 API 的支援。

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

  • [C-2-1] 必須加入 Android 裝置對應的 OMX 軟體轉碼器 開放原始碼專案 (如有)，適用於各種媒體格式和類型 (編碼器或解碼器)。
  • [C-2-2] 名稱開頭為「OMX.google」的轉碼器。必須採用 取得了機器學習模型
  • [C-SR-2] 強烈建議 OMX 軟體轉碼器在轉碼器中執行 這類程序無法存取記憶體對應工具以外的硬體驅動程式。

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

  • [C-3-1] 必須加入 為各種媒體格式和類型提供的 Android 開放原始碼計畫 (如適用) (編碼器或解碼器)。
  • [C-3-2] 必須將轉碼器 2.0 軟體轉碼器放入軟體轉碼器 「Android 開放原始碼計畫」所提供的程序， 能縮小授予軟體轉碼器的存取權
  • [C-3-3] 名稱開頭為「c2.android」的轉碼器。必須採用 取得了機器學習模型

5.1.10。媒體轉碼器字元化

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

  • [C-1-1] 「必須」透過 MediaCodecInfo敬上 也能使用 Google Cloud CLI 或 Compute Engine API

請特別注意以下幾點：

  • [C-1-2] 名稱開頭為「OMX」的轉碼器。必須使用 OMX API 且名稱符合 OMX IL 命名規範。
  • [C-1-3] 名稱開頭為「c2」的轉碼器。必須使用 Codec 2.0 API 名稱符合 Android Codec 2.0 命名規範。
  • [C-1-4] 名稱開頭為「OMX.google」的轉碼器。或「c2.android」。必須 「不得」稱為供應商或硬體加速。
  • [C-1-5] 在轉碼器程序 (供應商或系統) 中執行的轉碼器，具有 必須「不得」存取記憶體配置器和對應工具以外的硬體驅動程式 而是純軟體。
  • [C-1-6] 轉碼器不存在於 Android 開放原始碼計畫中，或不存在 「必須」視為供應商。
  • [C-1-7] 必須定義使用硬體加速的轉碼器 硬體加速
  • [C-1-8] 轉碼器名稱不得誤導使用者。例如名為 「解碼器」必須能夠支援解碼功能，以及名為「編碼器」的檔案須提供支援 編碼。名稱包含媒體格式的轉碼器「必須」支援這些格式 格式。

如果裝置導入方式支援視訊轉碼器：

  • [C-2-1] 所有影片轉碼器「必須」發布可達成的畫面更新率資料 以下是轉碼器支援的大小：
SD 標準畫質 (低品質) SD 標準畫質 (高品質) HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度
  • 176 x 144 像素 (H263、MPEG2、MPEG4)
  • 352 x 288 px (MPEG4 編碼器、H263、MPEG2)
  • 320 x 180 像素 (VP8，VP8)
  • 320 x 240 像素 (其他)
  • 704 x 576 像素 (H263)
  • 640 x 360 像素 (VP8，VP9)
  • 640 x 480 px (MPEG4 編碼器)
  • 720 x 480 像素 (其他，AV1)
  • 1408 x 1152 像素 (H263)
  • 1280 x 720 像素 (其他，AV1)
 1920 x 1080 px (MPEG4、AV1 除外) 3840 x 2160 px (HEVC、VP9、AV1)
  • [C-2-2] 採用硬體加速的視訊轉碼器 發布效能點資訊這些資料欄必須逐一支援 標準表現點 (列在 PerformancePoint 中) API)。
  • 此外，如果能提升廣告成效，則須提供 則可維持影片成效，而超越上述其中一種標準。

5.2.影片編碼

如果裝置導入方式支援任何影片編碼器， 第三方應用程式，並設定
MediaFormat.KEY_BITRATE_MODE 到 BITRATE_MODE_VBR 以便在可變位元率模式下運作 前提是不會影響最低品質下限 編碼的位元率：

  • 不應過度單單 滑動視窗，超過 15% 與內部影格之間 (I 影格) 的位元率超過 15% 間隔。
  • 不得超過 100% 比滑動區間 (滑動視窗) 高出 100%。

如果裝置導入方式支援任何影片編碼器， 以及設定 MediaFormat.KEY_BITRATE_MODE 到 BITRATE_MODE_CBR。 因此編碼器會以固定位元率模式運作，然後編碼位元率：

  • [C-SR-2] 強烈建議 「不得」超過目標位元率的 15% (以 1 秒滑動期為單位)。

如果裝置實作項目中含有 對角線長度至少 2.5 吋，或是視訊輸出連接埠 透過 android.hardware.camera.any 宣告支援相機 就會：

  • [C-1-1] 必須包含至少一部 VP8 或 H.264 影片的支援功能 以供第三方應用程式使用
  • 應同時支援 VP8 和 H.264 影片編碼器，並提供給 第三方應用程式的功能

如果裝置實作支援任何 H.264、VP8、VP9 或 HEVC 影片 提供給第三方應用程式使用，它們會：

  • [C-2-1] 必須支援動態可設定的位元率。
  • 應支援可變的畫面更新率，影片編碼器應 瞬息萬變的影格持續時間 (依據輸入緩衝區的時間戳記)。 並根據該影格持續時間分配位元值區

如果裝置實作支援 MPEG-4 SP 影片編碼器，並為其設定 提供給第三方應用程式使用，具有以下優點：

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

如果裝置實作提供硬體加速視訊或圖片編碼器， 並支援一或多個連接或可插式硬體攝影機，以 android.camera API：

  • [C-4-1] 必須支援所有硬體加速視訊和影像編碼器 擷取來自硬體鏡頭的編碼影格
  • 應支援硬體相機中所有影片的編碼影格 或圖片編碼器

如果裝置實作方式提供 HDR 編碼，就會：

  • [C-SR-1] 極力建議您為 以及能從 HDR 格式轉換為 SDR 格式。

5.2.1。標題 263

如果裝置實作方式支援 H.263 編碼器，且可供使用 他們會：

  • [C-1-1] 必須支援 QCIF 解析度 (176 x 144) 使用基準設定檔層級 45 SQCIF 解析度是選用項目。

5.2.2。H.264

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

  • [C-1-1] 必須支援基準設定檔第 3 級。 但支援 ASO (任意 Slice 排序)、FMO (彈性) 「巨集封鎖順序」) 和 RS (備援配量) 為選用項目。此外，前往 保持與其他 Android 裝置的相容性，因此建議使用 編碼器不會將 ASO、FMO 和 RS 用於基準設定檔，
  • [C-1-2] 必須支援 SD (標準畫質) 影片編碼設定檔 下表。
  • 應支援第 4 級主要設定檔。
  • 應支援 HD (高畫質) 影片編碼設定檔； 請參閱下表。

如果裝置導入方式回報支援 720p 或 1080p 的 H.264 編碼 透過媒體 API 解析度影片，可以：

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

5.2.3.VP8

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

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

如果裝置導入方式回報支援 720p 或 1080p 的 VP8 編碼 透過媒體 API 解析度影片，可以：

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

5.2.4。VP9

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

  • [C-1-2] 必須支援個人資料 0 第 3 級。
  • [C-1-1] 必須支援編寫 Matroska WebM 檔案。
  • [C-1-3] 必須產生 CodecPrivate 資料。
  • 「應該」支援 HD 編碼解碼設定檔，如下表所示。
  • [C-SR-1] 極力建議支援 HD 解碼設定檔 如果有硬體編碼器，請參照下表。
SD 標準畫質 HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 30 fps 30 fps 30 fps 30 fps
視訊位元率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置的實作方式聲稱支援設定檔 2 或設定檔 3，請前往 媒體 API：

  • 支援 12 位元格式。

5.2.5。標題 265

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

  • [C-1-1] 必須支援第 3 級的主要設定檔 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] 必須支援動態影片解析度和畫面更新率切換功能 所有 VP8、VP9 等所有 VP8 均屬標準 Android API。 H.264 和 H.265 轉碼器，且最高支援最高解析度 。

5.3.1。MPEG-2

如果裝置實作支援 MPEG-2 解碼器，就會：

  • [C-1-1] 必須支援主要設定檔高階裝置。

5.3.2。標題 263

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

  • [C-1-1] 必須支援基準設定檔第 30 級 (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 (多餘配量) 為 OPTIONAL。
  • [C-1-2] 必須能使用 SD 標準畫質將影片解碼 (Standard Definition) 設定檔清單列於下表，並使用基準設定檔進行編碼 以及主要設定檔層級 3.1 (包括 720p30)
  • 應能夠將具有 HD (高畫質) 設定檔的影片解碼 ，如下表所示。

如果 Display.getSupportedModes() 方法回報的高度為 等於或大於影片解析度、裝置導入方式：

  • [C-2-1] 必須支援在下列情況下支援 HD 高畫質 720p 影片解碼設定檔 表格。
  • [C-2-2] 必須支援下列內容的 HD 高畫質 1080p 影片解碼設定檔 表格。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p HD 高畫質 1080p
影片解析度 320 x 240 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素
影片畫面更新率 30 fps 30 fps 60 fps 30 fps (60 fps電視)
視訊位元率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5。H.265 (HEVC)

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

  • [C-1-1] 必須支援主要設定檔等級 3 的主要等級和 SD 影片 ，如下表所示。
  • 「應該」支援 HD 編碼解碼設定檔，如下表所示。
  • [C-1-2] 必須支援下列 HD 高畫質解碼設定檔 使用硬體解碼器

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

  • [C-2-1] 裝置導入作業至少必須支援 H.265 或 VP9 之一 720、1080 和 UHD 超高畫質設定檔
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 352 x 288 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 30 fps 30 fps 30 fps 30/60 fps (60 fps，採用 H.265 硬體解碼的電視) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置的實作方式宣稱能透過媒體支援 HDR 設定檔 API：

  • [C-3-1] 裝置的實作「必須」接受從以下來源取得的 HDR 中繼資料： 並支援擷取及輸出必要的 HDR 技術 從 Bitstream 和/或容器上傳
  • [C-3-2] 裝置實作「必須」正確顯示 或標準視訊輸出連接埠 (例如HDMI)。

5.3.6。VP8

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

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

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

  • [C-2-1] 實作裝置必須「必須」支援 720p 設定檔 資料表。
  • [C-2-2] 裝置實作必須支援 資料表。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p HD 高畫質 1080p
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
影片畫面更新率 30 fps 30 fps 30 fps (60 fps電視) 30 (60 fps電視)
視訊位元率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7。VP9

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

  • [C-1-1] 必須支援 SD 影片解碼設定檔，如 資料表。
  • 「應該」支援 HD 編碼解碼設定檔，如下表所示。

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

  • [C-2-1] 必須支援下列 HD 高畫質解碼設定檔 表格。

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

  • [C-3-1] 裝置導入作業至少必須支援 VP9 或 H.265 中的一項 720、1080 和 UHD 超高畫質設定檔
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 30 fps 30 fps 30 fps 30 fps (採用 VP9 硬體解碼的電視) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

  • 支援 12 位元格式。

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

  • [C-4-1] 裝置實作「必須」接受必要的 HDR 中繼資料 (KEY_HDR_STATIC_INFO)。 它會顯示所有 HDR 設定檔 「KEY_HDR10_PLUS_INFO」 供 HDR10Plus 設定檔使用) 應用程式。也「必須」支援 從位元流和/或容器取得 HDR 中繼資料。
  • [C-4-2] 裝置實作「必須」正確顯示 或標準視訊輸出連接埠 (例如HDMI)。

5.3.8。Dolby Vision

如果裝置實作方式宣告支援 Dolby Vision 解碼器 HDR_TYPE_DOLBY_VISION、 他們會：

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [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] 必須能夠解碼至少 720p 高畫質 720p 影片解碼設定檔 下表是在Display.getSupportedModes()回報的高度時表 方法等於或大於 720p。
  • [C-2-2] 必須能夠解碼至少 HD 1080p 影片解碼設定檔 資料來自下表 (由Display.getSupportedModes()回報的高度) 方法等於或大於 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] 必須支援擷取及輸出 以及/或容器
  • [C-3-2] 必須在裝置螢幕或 標準視訊輸出連接埠 (例如 HDMI)。

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 並正確填入裝置的可用麥克風資訊 由第三方應用程式存取 AudioManager.getMicrophones()。 API (適用於主動式錄音工具) MediaRecorder.AudioSources DEFAULT、MIC、CAMCORDER、VOICE_RECOGNITION、 VOICE_COMMUNICATION、UNPROCESSED 或 VOICE_PERFORMANCE。 如果裝置支援 AM 無線電和 DVD 品質擷取原始音訊 讓他們：

  • [C-2-1] 拍攝時，除非取樣率高於任何比例 16000:22050 或 44100:48000。

  • [C-2-2] 在任何向上取樣時，都必須加入適當的反鋸齒濾鏡 或降低取樣率

5.4.2。擷取以辨識聲音

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

  • [C-1-1] 必須擷取 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION音訊來源，位置： 其中一個取樣率是 44100 和 48000
  • [C-1-2] 必須在以下情況下，預設停用雜訊抑制音訊處理作業 錄製「AudioSource.VOICE_RECOGNITION」音訊的音訊串流 來源。

  • [C-1-3] 開始錄製時，必須預設停用所有自動增益控制項 來自「AudioSource.VOICE_RECOGNITION」音訊來源的音訊串流。

  • 應展現近似寬鬆與頻率特性 中頻段值：特別是從 100 Hz 到 4000 Hz 的 ±3dB 和用來錄製語音辨識音訊來源的每個麥克風

  • [C-SR-1] 強烈建議 [C-SR-1] 在低點 頻率範圍：特別是從 30 Hz 至 100 Hz 的 ±20 dB 每個用於錄音的麥克風音頻範圍 辨識音訊來源

  • [C-SR-2] 強烈建議 [C-SR-2] 在高處展現振幅 頻率範圍：特別是從 4000 Hz 到 22 KHz 的 ±30 dB， 每個用於錄音的麥克風音頻範圍 辨識音訊來源

  • 應設定音訊輸入靈敏度，讓 1000 Hz 單調色調來源 音量為 90 dB 時 (測量在麥克風旁邊) 會產生 RMS 2500 的理想回覆，範圍介於 1770 到 3530 以 16 之間 位元樣本 (或 -22.35 db ±3dB 全體重計，浮點/雙精度浮點數) 樣本) 音訊來源。

  • 應錄製語音辨識音訊串流，以調整 PCM 的振動 水平追蹤輸入 SPL 變化幅度至少介於 -18 之間 (至少 30 dB) dB 到 +12 dB re 90 dB SPL 麥克風。

  • 應以全諧音波錄製語音辨識音訊 1 kHz 的變形 (THD) 低於 1% (以 90 dB SPL 輸入等級為基準) 麥克風。

如果裝置實作方式宣告 android.hardware.microphone 和雜訊 專為語音辨識而調整的抑制 (縮減) 技術，它們：

  • [C-2-1] 必須允許使用者透過 android.media.audiofx.NoiseSuppressor API。
  • [C-2-2] 必須明確識別每種雜訊抑制技術 透過 AudioEffect.Descriptor.uuid 欄位進行實作

5.4.3.擷取用於重新規劃路線的拍攝畫面

android.media.MediaRecorder.AudioSource 類別包含 REMOTE_SUBMIX 音訊來源。

如果裝置實作程序同時宣告 android.hardware.audio.output 和 android.hardware.microphone，他們：

  • [C-1-1] 必須正確實作 REMOTE_SUBMIX 音訊來源， 當應用程式使用 android.media.AudioRecord API 記錄這個事件時 音訊來源，會擷取所有音訊串流的混合內容，但以下情況除外：

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4。聲學回聲消除器

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

  • 應導入無聲電子學取消工具 (AEC) 技術經過調整，適用於語音通訊，並會套用至擷取路徑。 以 AudioSource.VOICE_COMMUNICATION 擷取。

如果裝置導入方式提供聲學電子訊號取消工具， 在 AudioSource.VOICE_COMMUNICATION 時插入擷取音訊路徑 將會：

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] 必須支援 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER實作可透過 AudioEffect 子類別 Equalizer 和 LoudnessEnhancer。
  • [C-1-2] 必須支援視覺化工具 API 實作，且可透過 Visualizer 類別。
  • [C-1-3] 必須支援 EFFECT_TYPE_DYNAMICS_PROCESSING 導入作業 可透過 AudioEffect 子類別 DynamicsProcessing 控制。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-4] 必須支援音效， 浮點輸入和輸出(如果效果) 並將結果傳回架構音訊管道意思是典型的 像是插入等化器效果強烈對等行為 當架構音訊未顯示效果結果時，則建議採用這個做法 管道 (例如後續處理或卸載效果)。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-5] 請確保音效可支援多個聲道，最多 混音器管道數又稱為 FCC_LIMIT 效果結果傳回架構音訊管道時這個 是指一般的插入或輔助效果，但不含這類特效 例如放下合輯、上半部、空間化的影響，頻道數量也因此而改變。 當 架構音訊管線 (例如後續處理或卸載) 。

終止新規定

  • 應支援 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、 EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作 可透過 AudioEffect 子類別 BassBoost 控制 EnvironmentalReverb、PresetReverb 和 Virtualizer。
  • [C-SR-1] 強烈建議支援浮點和 多通路

5.5.3.音訊輸出音量

Automotive 裝置實作：

  • 應允許調整音訊音量 根據定義的內容類型或使用方式，在每個音訊串流中單獨處理 由 AudioAttributes 提供 和車輛音訊使用方式 (定義於 android.car.CarAudioManager 中公開定義)。

5.5.4。音訊卸載

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

  • [C-SR-1] 強烈建議你剪輯已播放的無聲音訊內容 是屬於相同格式 指定的 Pod 中 AudioTrack 無差異 API 以及 MediaPlayer 的媒體容器

5.6.音訊延遲時間

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

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

  • 輸出延遲。應用程式寫入影格之間的間隔 以及在遊戲中呈現相應聲音時 或該信號會經由 並可對外觀察
  • 冷輸出延遲。從開始輸出串流和 第一個影格的顯示時間 (根據時間戳記) 系統一直處於閒置狀態，並且已關機。
  • 連續輸出延遲。後續影格的輸出延遲時間 再開始播放音訊
  • 輸入延遲。每次發出聲音的間隔時間 透過裝置端轉換器或訊號進入裝置 通訊埠，以及應用程式讀取 PCM 編碼資料的對應影格時。
  • 輸入信號的初始部分，無法使用或 無法使用。
  • 冷輸入延遲時間。從開始串流到啟動串流之間的所需時間 就會在音訊輸入系統處於閒置狀態時，收到第一個有效影格 在要求之前關閉電源。
  • 連續輸入延遲。後續影格的輸入延遲時間 表示裝置正在擷取音訊。
  • 連續往返延遲時間。持續輸入延遲時間總和 連續輸出延遲時間加上一個緩衝區。緩衝區空間 等待應用程式處理信號和等待時間，以減少階段 輸出與輸出串流之間的差異
  • OpenSL ES PCM 緩衝區佇列 API。PCM 相關集合 OpenSL ES Android NDK 中的 API。
  • AAudio 原生音訊 API。其中一組 AAudio API (位於 Android NDK 內)
  • 時間戳記：一組內含相對影格位置的組合 以及該影格進入或離開頁面的預估時間 相關端點上的音訊處理管道其他參考資訊 AudioTimestamp。
  • 音訊訊號中暫時中斷或樣本值不正確 通常是由 buffer underrun 負責輸出， 緩衝區或類比雜訊造成多餘
  • 平均絕對偏差 (MAD)。計算函式時 與一組值平均值的差距。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • 而 CTS 驗證器測量的觸控音延遲時間 (TTL) 即為時間 與相關結果所生成的音調之間 有輕觸的喇叭。這是使用 5 種方式的 用於輸出的 AAudio 原生音訊 API。

  • 來回延遲時間 (RTL) 是由 CTS 驗證器測量得出，為平均值 5 次測量的持續延遲 (透過動態饋給的回送路徑進行測量) 透過 AAudio 原生音訊 API，將輸出內容傳回輸入內容。 回送路徑如下：

    • 喇叭/麥克風：內建麥克風，內建麥克風。
    • 類比：3.5 公釐類比插孔和一個回送轉接器。
    • USB：USB 轉 3.5 公釐轉接頭，以及迴轉轉接頭或 USB 音訊 以及迴歸線

  • FEATURE_AUDIO_PRO。android.hardware.audio.pro 功能： 宣告。

  • MPC。媒體成效類別

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • 抬頭追蹤延遲時間：時間 擷取根據慣性測量單位 (IMU) 拍攝的頭部動作 與耳機變音器的偵測模型造成的 這個動畫

終止新規定

如果裝置實作方式宣告了 android.hardware.audio.output， 必須符合或超過下列規定：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-1] 傳回的輸出時間戳記， AudioTrack.getTimestamp 而 AAudioStream_getTimestamp 則是 +/- 2 毫秒。

終止新規定

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

  • [C-1-3] 「必須」使用 AAudioStreamBuilder_openStream() 開啟輸出串流 只需要不到 1000 毫秒的時間

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-4] 根據輸入和輸出結果計算的來回延遲時間 AAudioStream_getTimestamp 傳回的時間戳記必須在 AAUDIO_PERFORMANCE_MODE_NONE與 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 適用於揚聲器 (有線和無線) 耳機。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置實作項目宣告 android.hardware.audio.output 極力建議您符合下列規定：

  • [C-SR-1] 揚聲器的冷輸出延遲時間為 100 毫秒或更短 資料路徑

  • [C-SR-2] 觸控色調延遲時間為 80 毫秒以下。

  • [C-SR-4] 根據輸入和輸出結果計算的來回延遲時間 AAudioStream_getTimestamp 傳回的時間戳記極度建議使用 維持在 30 毫秒內 AAUDIO_PERFORMANCE_MODE_NONE 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY ，適用於揚聲器、有線和無線耳機

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置導入方式符合上述規定，在初始 校正 (使用 AAudio 原生音訊 API) 持續輸出 至少使用一個支援音訊時的延遲時間和冷輸出延遲時間 則代表：

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置實作不符合低延遲音訊的需求條件 透過 AAudio 原生音訊 API 採取下列行動：

  • [C-2-1] 「不得」回報支援低延遲音訊的相關支援。

終止新規定

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-3-1] 限制輸入時間戳記中的錯誤，由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 以 +/- 2 毫秒。 「錯誤」這裡是指與正確值的偏差。

終止新規定

  • [C-3-2] 冷輸入延遲時間為 500 毫秒 以下。
  • [C-3-3] 必須使用「AAudioStreamBuilder_openStream()」開啟輸入串流 只需要不到 1000 毫秒的時間

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置實作項目包含 android.hardware.microphone， 強烈建議符合以下輸入音訊的規定：

  • [C-SR-8] 使用麥克風，冷輸入延遲時間不超過 100 毫秒 資料路徑
  • [C-SR-11] 限制輸入時間戳記中的錯誤，由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 以 +/- 1 毫秒。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置實作方式宣告了 android.hardware.audio.output 並 android.hardware.microphone，他們：

  • [C-SR-12] 強烈建議採用「平均連續封包延遲時間」 計算 50 毫秒或更短時間超過 5 次時，提供平均絕對偏差 小於 10 毫秒，且至少需透過一個系統支援的路徑。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

下表定義手持裝置的 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 (如不支援類比)

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

下表定義手持裝置的 TTL 相關規定 2.2.1 中定義的實作 android.hardware.audio.output 和 android.hardware.microphone。

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

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置導入方式提供 spatial audio敬上 採用頭追蹤 並宣告 PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY 旗幟，他們可以：

  • [C-4-1] 頭部追蹤延遲時間不得超過 300 毫秒。

終止新規定

5.7.網路協定

裝置導入方式必須支援 媒體網路通訊協定 Android SDK 說明文件中所述的音訊和影片播放方法。

針對需要實作裝置的各項轉碼器和容器格式 支援，裝置導入方式：

  • [C-1-1] 必須支援 HTTP 和 HTTPS 的轉碼器或容器。

  • [C-1-2] 必須支援下列媒體區隔格式： 下方媒體區隔格式表格 HTTP 即時串流草稿通訊協定第 7 版。

  • [C-1-3] 必須支援對應的 RTSP 酬載格式，如 RTSP 表格。如有例外情形，請參閱 第 5.1 節。

媒體區隔格式

區隔格式 參考資料 必要的轉碼器支援
MPEG-2 傳輸串流 ISO 13818 視訊轉碼器：
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
，瞭解如何調查及移除這項存取權。 如需 H264 AVC、MPEG2-4 SP 的詳細資訊，請參閱第 5.1.8 節。
以及 MPEG-2

音訊轉碼器：

  • 進階音訊編碼
，瞭解如何調查及移除這項存取權。 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.3 節。
採用 ADTS 取景和 ID3 代碼的 AAC ISO 13818-7 請參閱第 5.1.1 節 ，進一步瞭解 AAC 及其變化版本
WebVTT WebVTT

RTSP (RTP、SDP)

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

5.8.安全媒體

如果裝置導入方式支援安全視訊輸出，並能 支援多種安全介面

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

如果裝置實作項目宣告支援 Display.FLAG_SECURE 和支援 因此可以：

  • [C-2-1] 必須使用加密嚴密的機制來保護連結安全，例如 適用於透過無線通訊協定連線的螢幕的 HDCP 2.x 以上版本。 像是 Miracast

如果裝置實作方式宣告支援 Display.FLAG_SECURE 和 支援有線外接螢幕，因此：

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

5.9.樂器數位介面 (MIDI)

如果裝置導入作業回報支援功能 android.software.midi 透過 android.content.pm.PackageManager 類別，他們：

  • [C-1-1] 必須針對所有支援 MIDI 的硬體傳輸元件支援 MIDI 可提供一般的非 MIDI 連線，且其傳輸方式為：

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

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

  • 應支援第 7.7 節，透過 USB 週邊裝置模式支援 MIDI

5.10.專業音質

如果裝置導入結果回報支援功能 android.hardware.audio.pro (透過 android.content.pm.PackageManager 類別，他們：

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-2] 必須能連續播放來回音訊 延遲時間，會解決延遲的問題 FEATURE_AUDIO_PRO 相關規定 (如定義) 第 5.6 節音訊延遲時間 (共 至少支援 25 毫秒或更短時間內 路徑。

終止新規定

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-5] 必須達到 延遲時間和 USB 音訊 延遲時間相關規定 方法是使用 音訊原生音訊 API 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY。

終止新規定

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-8] 輕觸手勢的平均延遲時間必須不超過 80 毫秒 至少 5 次測量喇叭對麥克風資料路徑的測量。
  • [C-SR-1] 強烈建議符合本節定義的延遲時間 5.6 音訊延遲時間：20 毫秒或 少於 5 次測量，且平均絕對偏差小於 5 延遲時間
  • [C-SR-2] 極力建議符合 Pro Audio 規定， 連續往返音訊延遲、冷輸入延遲和冷輸出 使用 AAudio 原生音訊 API 的延遲和 USB 音訊要求 執行 MMAP 路徑

  • [C-SR-3] 強烈建議採用一致的 CPU 等級 而在啟用音訊和 CPU 負載時，整體效能會有所不同。請進行測試 使用 Android 應用程式 SynthMark。 SynthMark 使用軟體合成器在模擬音訊架構中運作 用於測量系統效能詳情請參閱 SynthMark 說明文件 。合成馬克 應用程式是使用 「自動化測試」並達成下列結果：

    • Voicemark.90 >= 32 種語音
    • etcmark.fixed.little <= 15 毫秒
    • etcmark.dynamic.little <= 50 毫秒

  • 應盡量減少音訊時鐘的準確度，以及相對於標準時間的偏移。

  • 應盡量減少音訊時鐘相對於 CPU 的偏移CLOCK_MONOTONIC 啟用後

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

  • 相較於 USB 數位音訊，應盡量縮短音訊延遲。

  • 應記錄所有路徑的音訊延遲測量值。

  • 應盡量減少音訊緩衝區完成回呼輸入時間時基誤差，因為 會影響回呼的可用完整 CPU 頻寬百分比。

  • 應該在正常使用時回報延遲，避免發生音訊故障。

  • 應呈現零的跨管道延遲時間差異。

  • 應盡量減少所有傳輸中的 MIDI 平均延遲時間。

  • 應盡量減少所有傳輸過程中負載 (如時基誤差) 的 MIDI 延遲時間變化。

  • 所有傳輸作業都應提供準確的 MIDI 時間戳記。

  • 應盡量減少使用裝置端變換器的音訊訊號雜訊，包括 冷啟動。

  • 輸出端和輸出端之間的音訊時鐘差異應呈現零 相應的端點 (當兩者皆啟用時)。對應示例 端點包括裝置端麥克風和喇叭，或音訊插孔輸入端 輸出內容

  • 應該處理輸入和輸出端的音訊緩衝區完成回呼 同一執行緒上相對應的端點，且輸入 會在輸入回呼傳回後立即觸發輸出回呼。或 如果無法在同一個執行緒上處理回呼，請輸入 進入輸入回呼後不久，就會輸出回呼，允許 確保輸入端和輸出端的時間一致

  • 應盡量減少輸入音訊緩衝區之間的 HAL 音訊緩衝區差異 以對應端點為起點

  • 應盡量縮短觸控延遲時間。

  • 應盡量減少載入時觸控延遲時間的變化 (時基誤差)。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

終止新規定

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

終止新規定

如果裝置實作方式省略 4 導電線 3.5 公釐耳機插孔， 納入支援 USB 主機模式的 USB 連接埠，您可以：

  • [C-3-1] 必須實作 USB 音訊類別。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-3-2] 必須設定下列的連續往返音訊延遲時間： 不超過 25 毫秒，超過 5 種測量平均絕對偏差 使用 USB 音訊類別的 USB 主機模式連接埠少於 5 毫秒。 (可使用 USB-3.5 公釐轉接頭和音訊回送功能進行測量) 使用連接器，或使用 USB 音訊介面搭配接線連接 輸出的內容)
  • [C-SR-6] 強烈建議你最多同時支援 8 個 I/O 大會管道 每個方向、96 kHz 取樣率以及 24 位元或 32 位元深度 (如使用中) 以及支援這些需求的 USB 音訊週邊設備
  • [C-SR-7] 強烈建議使用 MMAP 路徑上的 AAudio 原生音訊 API。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

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

  • 應支援立體聲輸出內容和八個聲道 (20 位元或 20 位元) 深度 24 位元和 192 kHz，沒有位元深度損失或重新取樣 至少一項資源

終止新規定

5.11.擷取尚未處理

Android 支援透過以下方式錄製未處理的音訊： android.media.MediaRecorder.AudioSource.UNPROCESSED 個音訊來源。於 OpenSL ES，如要使用記錄預設設定存取這項服務 SL_ANDROID_RECORDING_PRESET_UNPROCESSED。

如果裝置實作意圖支援未處理的音訊來源，並做出 提供給第三方應用程式使用，具有以下特點：

  • [C-1-1] 請務必透過android.media.AudioManager回報支援 資源 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED。

  • [C-1-2] 必須呈現近似平坦/與頻率的 中頻率範圍的特性：特別是從 ±10 dB 使用每個麥克風錄製未經處理的個別麥克風 (刷新率可達 100 Hz 至 7000 Hz) 音訊來源。

  • [C-1-3] 必須能夠以低頻率表現振幅 範圍：特別是從 5 z 至 100 Hz 的 ±20 dB 每個用來錄音的麥克風都屬於中音波 未處理的音訊來源

  • [C-1-4] 必須頻率高，才能顯示振幅 範圍：特別是從 7000 Hz 到 22 KHz 的 ±30 dB 每個用來錄音的麥克風都屬於中音波 未處理的音訊來源

  • [C-1-5] 必須設定音訊輸入靈敏度，以便讓 1000 Hz 單調 以 94 dB 聲音壓力水平 (SPL) 播放的語氣來源產生回應 16 位元樣本的 RMS 為 520 (16 位元取樣；如果是浮點/雙精度浮點數，則為 -36 dB 完整比例) 精確度範例)， 音訊來源。

  • [C-1-6] 必須達到 60 dB 或更高的訊號雜訊比 (SNR) 。 (SNR 的測量結果是 94 dB SPL 與等值以下之間的差異) 自我噪音的 SPL、A 加權)。

  • [C-1-7] 總諧變形 (THD) 必須小於 1 kHZ 為 1%，而每個麥克風輸入層級為 90 dB SPL 輸入等級：1% 錄製未處理的音訊來源。

  • [C-1-8] 必須不具有任何其他訊號處理 (例如自動增益) 控制、高通濾器或回音消除) 等標準係數，讓等級能達到所需範圍。也就是說：

    • [C-1-9] 如果架構中有任何信號處理， 必須要將其停用，並有效地造成零延遲或 因此信號路徑會額外延遲
    • [C-1-10] 雖然可位於路徑中的等級係數，但不得 可能會導致訊號路徑發生延遲或延遲。

所有 SPL 測量結果都直接放在受測試的麥克風旁邊。 如果是多種麥克風設定，則必須符合下列需求條件： 每個麥克風。

如果裝置實作項目宣告了 android.hardware.microphone，但未宣告 支援未處理的音訊來源，這些影片：

  • [C-2-1] 必須針對AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)傳回 null API 方法，正確指出缺乏支援功能。
  • [C-SR-1] 仍極力推薦，可滿足大多數需求 來取得未處理記錄來源的信號路徑。

5.12.HDR 影片

Android 13 支援 HDR 技術，詳情請參閱後續說明文件。

像素格式

如果影片解碼器通告支援 COLOR_FormatYUVP010，則：

  • [C-1-1] 必須支援 CPU 讀取的 P010 格式 (ImageReader、MediaImage、 ByteBuffer)。在 Android 13 中，P010 會寬鬆，允許 Y 任意步長 和 UV 飛機

  • [C-1-2] P010 輸出緩衝區「必須」可供 GPU 取樣 (當 則是依 GPU_SAMPLING 用量分配)。如此一來，就能建立 GPU 組合和自訂 各個應用程式的色調對應功能

如果影片解碼器通告支援 COLOR_Format32bitABGR2101010，則應該：

  • [C-2-1] 必須支援 RGBA_1010102 格式的輸出介面和 CPU 可讀取 (ByteBuffer 輸出內容)。

如果影片編碼器通告支援 COLOR_FormatYUVP010，就會：

  • [C-3-1] 必須支援輸入介面和可寫入 CPU 的 P010 格式 (ImageWriter、MediaImage、ByteBuffer)。
，瞭解如何調查及移除這項存取權。

如果影片編碼器通告支援 COLOR_Format32bitABGR2101010，請按照下列步驟操作：

  • [C-4-1] 必須支援 RGBA_1010102 格式的輸入介面和可寫入 CPU (ImageWriter、ByteBuffer) 輸入內容。注意：在各種傳輸之間進行轉換 編碼器不需要使用曲線。

HDR 拍攝需求

針對支援 HDR 設定檔的所有影片編碼器，按照以下方式實作裝置：

  • [C-5-1] 不得假設 HDR 中繼資料是精確的。舉例來說， 編碼影格的像素可能超出峰值亮度，或 可能沒有代表影格的直方圖。

  • 應匯總 HDR 動態中繼資料，以產生合適的 HDR 靜態資料 編碼串流的中繼資料，而且這些串流應會在每個結尾 編碼工作階段。

如果裝置的實作支援使用 CamcorderProfile API 進行 HDR 擷取 然後：

  • [C-6-1] 也必須支援透過 Camera2 API 拍攝 HDR 相片。

  • [C-6-2] 至少要支援 1 個硬體加速視訊編碼器， 的每個 HDR 技術

  • [C-6-3] 必須 (最低) 支援 HLG 擷取。

  • [C-6-4] 必須支援寫入 HDR 中繼資料 (如果適用於 HDR 影片) 錄製到擷取的影片檔案中。適用於 AV1、HEVC 和 DolbyVision 也就是將中繼資料納入編碼後的位元流。

  • [C-6-5] 必須支援 P010 和 COLOR_FormatYUVP010。

  • [C-6-6] 預設必須支援 HDR 轉 SDR 色調對應 硬體加速解碼器。也就是 如果裝置可以擷取 HDR10+ HEVC，則預設的 HEVC 解碼器必須能 ，以 SDR 形式解碼擷取的串流。

HDR 編輯需求條件

如果裝置實作包含支援 HDR 編輯功能的影片編碼器， 他們會：

  • 產生 HDR 中繼資料時，應盡量縮短延遲時間。 也應該妥善處理有中繼資料 看似無害這些中繼資料必須精確 (例如 代表影格的實際峰值亮度和直方圖)。

如果裝置導入方式包含支援 FEATURE_HdrEditing 的轉碼器，則 這些轉碼器：

  • [C-7-1] 必須支援至少一個 HDR 設定檔。

  • [C-7-2] 必須支援 FEATURE_HdrEditing 支援以下服務的所有 HDR 設定檔： 該轉碼器。換句話說，在執行相同要求的情況下，這類檔案「必須」支援產生 HDR 中繼資料 則不會。

  • [C-7-3] 必須支援下列完整版影片編碼器輸入格式 如何保留已解碼的 HDR 訊號：

    • 兩個輸入的 RGBA_1010102 (已位於目標轉乘曲線中) 同時，請「務必」向廣告客戶 COLOR_Format32bitABGR2101010。

如果裝置導入方式包含支援 FEATURE_HdrEditing 的轉碼器，則 裝置：

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

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

6.1.開發人員工具

裝置實作方式：

  • [C-0-1] 必須支援 Android 中提供的 Android 開發人員工具 將機器學習工作流程自動化
  • Android Debug Bridge (ADB)

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-0-2] 必須支援 Android SDK 和殼層中記錄的 ADB 以及 Android 開放原始碼計劃中提供的指令，供應用程式開發人員使用 包括 dumpsys、 cmd stats和 Simpleperf。

終止新規定

  • [C-0-11] 必須支援殼層指令 cmd testharness。升級中 沒有 永久資料區塊「可能」不受 C-0-11 的規範。
  • [C-0-3] 不得變更裝置系統的格式或內容 事件 (batterystats、diskstats、Fingerprint、graphicstats、netstats、 透過 dumpsys 指令記錄通知、procstats

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-0-10] 必須錄影、確保內容不遺漏，以及於後續活動 可供 cmd stats 殼層指令和 StatsManager 系統 API 類別。
    • ActivityForegroundState 已變更
    • 偵測到異常狀況
    • 已回報的應用程式導覽標記
    • 應用程式當機
    • AppStart 發生
    • 電池等級已變更
    • BatterySaverModeState 已變更
    • BleScanResultReceived
    • BleScanState 已變更
    • ChargingState 已變更
    • DeviceIdleModeState 已變更
    • 前景服務狀態已變更
    • GpsScanState 已變更
    • InputDeviceUsageReported
    • 工作狀態已變更
    • 鍵盤設定
    • KeyboardSystemsEventReported
    • PluggedState 已變更
    • 已排程工作狀態已變更
    • 畫面狀態已變更
    • SyncState 已變更
    • SystemElapsedRealtime
    • 觸控板使用方式
    • UidProcessState 已變更
    • WakelockState 已變更
    • 喚醒鬧鐘發生次數
    • WifiLockState 已變更
    • WifiMulticastLockState 已變更
    • WifiScanState 已變更

終止新規定

  • [C-0-4] 裝置端 ADB Daemon 必須預設為停用， 「必須」具備可供使用者存取的機制，才能開啟 Android 偵錯功能 橋樑。
  • [C-0-5] 必須支援安全 ADB。Android 內建安全功能 ADB。安全 ADB 可在已知的驗證主機上啟用 ADB。
  • [C-0-6] 必須提供機制，讓 ADB 能夠從外部伺服器 託管機器具體違規事項如下：

如果裝置的實作方式在沒有 USB 連接埠的情況下支援週邊裝置模式，則會造成：

  • [C-3-1] 必須透過區域區域網路 (例如乙太網路) 實作 ADB 或 Wi-Fi)。
  • [C-3-2] 必須提供 Windows 7、8 和 10 的驅動程式， 以便使用 ADB 通訊協定 連接裝置

如果裝置實作支援透過 Wi-Fi 或乙太網路：

  • [C-4-1] 必須採用 AdbManager#isAdbWifiSupported() 方法 傳回 true。

如果裝置實作支援透過 Wi-Fi 或乙太網路 至少包括一部相機：

  • [C-5-1] 必須採用 AdbManager#isAdbWifiQrSupported() 方法 傳回 true。

  • Dalvik 偵錯監控服務 (ddms)

    • [C-0-7] 必須支援 Android SDK 中記錄的所有 ddms 功能。 由於 ddms 會使用 ADB，因此預設會停用 ddms 的支援功能，但 在使用者啟用 Android Debug Bridge、 。

  • SysTrace

    • [C-0-9] 必須支援 Android SDK 中所述的 systrace 工具。 Systrace 必須預設為停用，且使用者可以存取 啟用 Systrace

  • Perfetto

  • 低記憶體終止工具

    • [C-0-12] 必須將 LMK_KILL_OCCURRED_FIELD_NUMBER Atom 寫入 應用程式因低記憶體終止工具而終止時的統計資料記錄。

  • 測試控管工具模式 如果裝置實作支援殼層指令 cmd testharness 和 執行 cmd testharness enable，它們：

  • GPU 工作資訊

    裝置實作方式：

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

如果裝置導入方式透過 android.hardware.vulkan.version 功能旗標，可以：

  • [C-1-1] 「必須」提供可供應用程式開發人員啟用/停用的預設工具 GPU 偵錯圖層
  • [C-1-2] 「必須」啟用 GPU 偵錯圖層時，列舉 由外部工具提供的程式庫 (例如，非平台或 應用程式套件)設為 支援 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。

6.2.開發人員選項

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

導入裝置時，「必須」為 「開發人員選項」的用途：

  • [C-0-1] 必須尊重 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖顯示應用程式開發相關設定。上游 Android 根據預設，系統會隱藏開發人員選項選單，讓使用者 在「設定」> 上按下七 (7) 次後，啟動開發人員選項 關於裝置 >「Build Number」選單項目。
  • [C-0-2] 預設必須隱藏開發人員選項。
  • [C-0-3] 必須提供明確機制，讓 以待開發人員 選項。「必須」提供公開可見的文件或網站，說明如何 啟用開發人員選項。這份文件或網站必須連結至 Android SDK 文件
  • 在「開發人員」時應持續向使用者顯示視覺通知 選項已啟用，且使用者安全無虞。
  • 可能會暫時限制「開發人員選項」選單的存取權 隱藏或停用選單，以免在 使用者的安全有顧慮

7. 硬體相容性

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

  • [C-0-1] 裝置實作「必須」實作 Android SDK 說明文件中所述的 API 設定。

如果 SDK 中的 API 會與宣稱為選用的硬體元件互動 裝置實作方式不具備該元件：

  • [C-0-2] 完成元件的類別定義 (如 SDK 所記錄) 您仍須提供 API。
  • [C-0-3] API 的行為「必須」在合理範圍內實作為免人工管理 。
  • [C-0-4] 在 SDK 允許的情況下，API 方法「必須」傳回空值 說明文件。
  • [C-0-5] API 方法「必須」傳回含有空值的類別免人工管理實作 根據 SDK 說明文件的用途建立政策。
  • [C-0-6] API 方法「不得」擲回 SDK 未記錄的例外狀況 說明文件。
  • [C-0-7] 裝置的實作方式必須持續回報準確的硬體裝置 透過 getSystemAvailableFeatures() 和 中的 hasSystemFeature(String) 方法 android.content.pm.PackageManager 類別。

符合這些規定的典型例子就是電話通訊系統 API：即使在手機以外的裝置上，仍必須以合理的方式實作這些 API 免人工管理。

7.1.顯示和圖形

Android 內含自動調整應用程式資產和 UI 的功能 為裝置設定合適的版面配置，確保第三方應用程式 能在多種硬體顯示器和設定上順利執行。一個 Android 相容螢幕是實作所有 所述行為和 API，請參閱「Android 開發人員 - 螢幕相容性」一文 概述，此 區段 (7.1) 及其子區段，以及任何其他裝置類型 上述第 2 節的具體行為 CDD。

裝置實作方式：

  • [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] 必須回報正確的 Configuration.screenLayout，如 Android SDK 說明文件中所定義。 具體來說，裝置導入方式必須「必須」回報正確的邏輯 密度獨立像素 (dp) 螢幕尺寸，如下所示：

    • Configuration.uiMode 設為任何其他值的裝置 UI_MODE_TYPE_WATCH，並回報 small Configuration.screenLayout，必須至少為 426 dp x 320 dp。
    • 回報 Configuration.screenLayout 大小為 normal 的裝置， 不得小於 480 dp x 320 dp。
    • 回報 Configuration.screenLayout 大小為 large 的裝置， 不得小於 640 dp x 480 dp。
    • 回報 Configuration.screenLayout 大小為 xlarge 的裝置， 不得小於 960 dp x 720 dp。

  • [C-0-2] 必須正確遵循申請書」說明 透過 <supports-screens> 支援螢幕大小 屬性，如 AndroidManifest.xml 中的屬性 。

  • 「可能」具備與 Android 相容的螢幕(圓角設計)。

如果裝置導入方式支援 UI_MODE_TYPE_NORMAL 個大小設定 並使用帶有圓角的實體螢幕呈現這些畫面 他們會：

  • [C-1-1] 必須確認至少符合下列一項規定 區域大小

    • 圓角的半徑小於或等於 38 dp。
    • 將 18 dp x 18 dp 的方塊固定在邏輯的每個角落 螢幕，每個方塊至少要有一個像素。

  • 應提供使用者需求，以改用 長方形邊角

如果裝置實作功能僅支援 NO_KEYS 鍵盤設定， 並打算回報對 UI_MODE_TYPE_NORMAL UI 模式的支援 可以：

  • [C-4-1] 版面配置大小必須設為至少 (不包括任何螢幕凹口) 596 dp x 384 dp 以上。

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置導入方式包含一或多個 Android 相容顯示區域 摺疊式裝置，或是在多個物件之間 Android 相容顯示面板區域， 因此必須：

終止新規定

7.1.1.2。螢幕顯示比例

這個部分已在 Android 14 中刪除。

7.1.1.3.螢幕密度

Android UI 架構會定義一組標準邏輯密度， 鎖定應用程式資源

裝置實作方式：

  • [C-0-1] 必須回報下列 Android 架構密度： 在 DisplayMetrics 透過 DENSITY_DEVICE_STABLE API 且每個實體螢幕的這個值都必須是靜態值。 不過裝置「可能」 回報其他DisplayMetrics.density 並依照使用者提出的顯示設定變更 (針對 例如「顯示大小」)。

  • 應定義標準 Android 架構密度 (以數值表示) 最接近螢幕的實體密度，或是對應到 相當於手持裝置的角度視野測量值

若裝置導入方式能提供 裝置的顯示大小，這類動作會：

  • [C-1-1] 「不得」將螢幕縮放至超過 1.5 倍 DENSITY_DEVICE_STABLE敬上 或產生小於 320 dp 的有效最小螢幕尺寸 (相當於 變更為資源限定詞 sw320dp
  • [C-1-2] 不得縮放螢幕 小於 0.85 倍的 DENSITY_DEVICE_STABLE。
  • 為了保持良好的可用性並維持一致的字型大小，建議您 系統會提供下列原生多媒體廣告選項的縮放功能 (但必須遵守限制 以上說明)
    • 小：0.85x
    • 預設：1x (原生多媒體縮放比例)
    • 大：1.15 倍
    • 較大：1.3 倍
    • 最大 1.45 倍

7.1.2.顯示指標

如果裝置導入方式包含 Android 相容螢幕，或 影片輸出到 Android 相容螢幕中，它們：

如果裝置實作項目不含內嵌畫面或影片輸出內容， 他們會：

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

7.1.3.螢幕方向

裝置實作方式：

  • [C-0-1] 必須回報支援的螢幕方向 (android.hardware.screen.portrait 和/或 android.hardware.screen.landscape)，且至少必須回報一項支援的資料來源 方向。例如螢幕方向為固定橫向的裝置 螢幕 (例如電視或筆記型電腦) 僅「必須」 檢舉「android.hardware.screen.landscape」。
  • [C-0-2] 必須回報裝置目前情況的正確值 每次透過 android.content.res.Configuration.orientation, android.view.Display.getOrientation() 或其他 API

如果裝置實作支援這兩種螢幕方向，就會發生以下情形：

  • [C-1-1] 必須讓應用程式支援直向或橫向螢幕動態螢幕方向 方向。也就是說，裝置必須遵循應用程式對特定螢幕的要求 方向。
  • [C-1-2] 變更螢幕方向時，「不得」變更回報的螢幕大小或密度。
  • 可選擇直向或橫向做為預設方向。

7.1.4。2D 和 3D 圖形加速

7.1.4.1。OpenGL ES

裝置實作方式：

  • [C-0-1] 必須正確識別支援的 OpenGL ES 版本 (1.1、2.0、 3.0、3.1、3.2)，或透過代管 API (例如透過 GLES10.getString() 方法) 和原生 API。
  • [C-0-2] 必須納入所有對應的代管 API 的支援和 。

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

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-1] 必須同時支援 OpenGL ES 1.1，「以及」2.0、3.0 和 3.1 版，提供完整詳盡說明 參閱 Android SDK 說明文件。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-SR-1] 強烈建議你支援 OpenGL ES 3.1。

終止新規定

  • 應支援 OpenGL ES 3.2。

OpenGL ES dEQP 測試會分割為數個測試清單，每個清單都有 相關聯的日期/版本號碼。這些位於以下的 Android 原始碼樹狀結構： external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt。符合以下條件的裝置 在自行回報等級的情況下支援 OpenGL ES，表示它能通過 dEQP 進行測試。

如果裝置實作支援任何 OpenGL ES 版本，就會：

  • [C-2-1] 「必須」透過 OpenGL ES 代管 API 和原生 API 回報 其他已實作的 OpenGL ES 擴充功能，反之亦然 「不要」回報不支援的擴充功能字串。
  • [C-2-2] 必須支援 EGL_KHR_image、EGL_KHR_image_base、 EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、 EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、 EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、 EGL_ANDROID_recordable 及 EGL_ANDROID_GLES_layers 擴充功能。
  • [C-2-3] 必須回報 OpenGL ES dEQP 測試最新版本 透過 android.software.opengles.deqp.level 功能旗標提供支援。
  • [C-2-4] 至少必須支援 132383489 版 (自 2020 年 3 月 1 日起)， 在 android.software.opengles.deqp.level 功能旗標中回報的。
  • [C-2-5] 在各版本之間「必須」通過測試清單中的所有 OpenGL ES dEQP 測試 132383489，以及 android.software.opengles.deqp.level 功能旗標 (適用於每個支援項目) OpenGL ES 版本。
  • [C-SR-2] 強烈建議你支援 EGL_KHR_partial_update 和 OES_EGL_image_external 個擴充功能。

  • 應透過 getString() 方法 (任何紋理) 準確回報 支援的壓縮格式，通常視供應商而定。

  • 應支援 EGL_IMG_context_priority 和 EGL_EXT_protected_content 個擴充功能。

如果裝置實作宣告支援 OpenGL ES 3.0、3.1 或 3.2，就會發生以下情形：

  • [C-3-1] 「必須」匯出這些版本對應的函式符號 以及 libGLESv2.so 程式庫中的 OpenGL ES 2.0 函式符號。
  • [C-SR-3] 強烈建議你支援 OES_EGL_image_external_essl3 。

如果裝置的實作支援 OpenGL ES 3.2，就會發生以下情形：

  • [C-4-1] 必須完整支援 OpenGL ES Android 擴充功能包。

如果裝置實作支援 OpenGL ES Android 擴充功能套件， 他們可以：

  • [C-5-1] 必須透過android.hardware.opengles.aep找出支援資訊 功能旗標

如果裝置實作項目公開對 EGL_KHR_mutable_render_buffer 的支援 可以使用：

  • [C-6-1] 必須同時支援 EGL_ANDROID_front_buffer_auto_refresh 。
7.1.4.2。Vulkan

Android 支援 Vulkan。 低負載的跨平台 API，可用於進行高效能 3D 圖形。

如果裝置的實作支援 OpenGL ES 3.1，就會發生以下情形：

  • [C-SR-1] 強烈建議你提供 Vulkan 1.3 版。
  • [C-4-1]「不得」支援 Vulkan 變化版本版本 (即變化版本) 部分 Vulkan 核心版本的部分都必須為零)。

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

  • [C-SR-2] 強烈建議你提供 Vulkan 1.3 版。

Vulkan dEQP 測試分成多個測試清單，每個清單都有 相關日期/版本這些位於以下的 Android 原始碼樹狀結構： external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt。符合以下條件的裝置 在自行回報的層級支援 Vulkan，表示 Vulkan 可以通過 dEQP 進行測試。

如果裝置實作項目支援 Vulkan，就會：

  • [C-1-1] 請務必回報正確的整數值 「android.hardware.vulkan.level」和「android.hardware.vulkan.version」 功能旗標
  • [C-1-2] 必須列舉，至少要有一個 VkPhysicalDevice 適用於 Vulkan 原生 API vkEnumeratePhysicalDevices()
  • [C-1-3] 每個列舉項目都必須完全實作 Vulkan 1.1 API VkPhysicalDevice。
  • [C-1-4] 請務必列舉包含在名為 位於應用程式套件的原生程式庫目錄中的 libVkLayer*.so， 透過 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties()。
  • [C-1-5] 不得列舉非實作 提供追蹤或攔截 Vulkan API (除非應用程式具有 android:debuggable 屬性) 設為 true 或中繼資料 com.android.graphics.injectLayers.enable 已設為 true。
  • [C-1-6] 請務必透過 Vulkan 原生 API，相反地「不得」回報擴充功能字串 他們無法妥善支援
  • [C-1-7] 必須支援 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 的擴充功能。
  • [C-1-8] 必須回報 Vulkan dEQP 測試的最高版本 透過 android.software.vulkan.deqp.level 功能旗標提供支援。
  • [C-1-9] 至少必須支援 132317953 版 (自 2019 年 3 月 1 日起)， 已回報在 android.software.vulkan.deqp.level 功能旗標中。
  • [C-1-10] 必須通過測試清單中的所有 Vulkan dEQP 測試， 版本 132317953，以及 android.software.vulkan.deqp.level 功能旗標。
  • [C-1-11] 「不得」列舉對 VK_KHR_video_queue 的支援 VK_KHR_video_decode_Queue 或 VK_KHR_video_encode_Queue 擴充功能。
  • [C-SR-3] 強烈建議你支援 VK_KHR_driver_properties 和 VK_GOOGLE_display_timing 個擴充功能。
  • [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] 強烈建議將 SkiaVk 與 HWUI 搭配使用。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置實作項目支援 Vulkan，就必須：

  • [C-SR-8] 強烈建議不要修改 Vulkan 載入器。
  • [C-1-14] 不得列舉「KHR」類型的 Vulkan 裝置擴充功能 「GOOGLE」或「ANDROID」除非在 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 列舉任何 VkPhysicalDevice vkEnumeratePhysicalDevices()。

如果裝置實作項目提供對 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 檔案，以及從 POSIX 檔案匯入圍欄酬載 就如同先前介紹的 這裡。

7.1.4.3.RenderScript

裝置實作方式：

7.1.4.4。2D 圖形加速

Android 提供一種機制，可讓應用程式宣告 在「應用程式」、「活動」、 使用資訊清單標記，就在視窗或資料檢視層級 android:hardwareAccelerated 或直接 API 呼叫

裝置實作方式：

  • [C-0-1] 預設「必須」啟用硬體加速功能，且「必須」 如果開發人員透過設定 android:hardwareAccelerated="false"或停用硬體加速 直接透過 Android View API
  • [C-0-2] 行為違反 硬體加速的 Android SDK 說明文件。

Android 包含可讓開發人員直接整合的 TextureView 物件 硬體加速 OpenGL ES 紋理做為 UI 階層中的算繪目標。

裝置實作方式：

  • [C-0-3] 必須支援 TextureView API，且必須 行為模式與上游 Android 實作方式一致
7.1.4.5。廣角螢幕

如果裝置實作方式聲稱支援廣域螢幕 Configuration.isScreenWideColorGamut()，他們：

  • [C-1-1] 必須採用色彩校正的螢幕。
  • [C-1-2] 必須採用色調涵蓋 sRGB 色域的螢幕 完全是 CIE 1931 xyY 的空間。
  • [C-1-3] 螢幕必須具有至少 90% 的面積 CIE 1931 xyY 空間中的 DCI-P3。
  • [C-1-4] 必須支援 OpenGL ES 3.1 或 3.2 並妥善回報。
  • [C-1-5] 請務必為EGL_KHR_no_config_context宣傳支援服務； EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、 EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、 EGL_EXT_gl_colorspace_display_p3、EGL_EXT_gl_colorspace_display_p3_linear、 及EGL_EXT_gl_colorspace_display_p3_passthrough 。
  • [C-SR-1] 強烈建議你支援 GL_EXT_sRGB。

相反地，如果裝置實作項目不支援廣角螢幕，就會：

  • [C-2-1] 在 CIE 1931 xyY 空間中，必須涵蓋 100% 以上的 sRGB 未定義螢幕色域。

7.1.5。舊版應用程式相容性模式

Android 會指定「相容模式」這個架構會在 「正常」相等螢幕尺寸相等 (320dp 寬度) 模式，結合多種優點 未針對舊版 Android 開發的應用程式 而且不受螢幕大小的獨立性

7.1.6。螢幕技術

Android 平台中的 API 可讓應用程式呈現豐富多樣的 投放至 Android 相容螢幕裝置必須支援下列所有 以 Android SDK 定義的 API (除非本文件特別許可)。

裝置實作方式的所有 Android 相容螢幕：

  • [C-0-1] 必須能夠轉譯 16 位元色彩圖形。
  • 應支援能夠顯示 24 位元色彩圖形的螢幕。
  • [C-0-2] 必須能夠轉譯動畫。
  • [C-0-3] 必須採用像素顯示比例 (PAR) 介於 0.9 到 1.15 之間也就是說，像素顯示比例必須接近正方形 (1.0)，容忍度為 10 至 15%。

7.1.7.第二螢幕

Android 支援次要 Android 相容螢幕，以便啟用 媒體分享功能，以及用於存取外部螢幕的開發人員 API。

如果裝置的實作支援透過有線方式使用外接螢幕， 無線連線或嵌入式螢幕連線，這些技術可以：

7.2.輸入裝置

裝置實作方式：

7.2.1。鍵盤

如果裝置導入方式提供第三方支援 輸入法編輯器 (IME) 應用程式：

裝置實作方式：

7.2.2。非觸控瀏覽

Android 支援 D-pad、軌跡球和滾輪做為 非觸控式瀏覽方式

裝置實作方式：

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

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

7.2.3.瀏覽鍵

「首頁」 近期、 和 Back 功能通常透過與專屬實體按鈕的互動提供 或觸控螢幕的獨立部分 導覽模式，因此的裝置導入方式：

  • [C-0-1] 必須為使用者提供授權，以啟動已安裝的應用程式 包含具有 <intent-filter> 設定且 ACTION=MAIN 和 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER (適用於電視裝置) 。 首頁功能「必須」做為這項使用者預設用途的機制。
  • 「應」提供「最近」和「返回」功能的按鈕。

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

  • [C-1-1] 必須讓使用者透過單一動作 (例如輕觸、按兩下或 畫面)。
  • [C-1-2] 必須明確指出會觸發哪個單一動作 每個函式按鈕上顯示可見的圖示，顯示軟體 圖示，或是引導使用者逐步完成 在開箱即用的逐步教學流程中， 這類指標的範例

裝置實作方式：

  • [C-SR-1] 強烈建議不要為 選單函式 因為該版本已淘汰，並改用動作列，自 Android 4.0 版起取代。

  • [C-SR-2] 極力建議您根據 可取消。「可取消」一種是使用者能夠 導航功能停止執行 (例如返回首頁、返回等) 滑動手勢不會超過特定門檻。

如果裝置實作提供選單功能，就會：

  • [C-2-1] 每當使用者執行動作時，都必須顯示動作溢位按鈕 溢位選單彈出式選單不是空白的，而且會顯示動作列。
  • [C-2-2] 「不得」修改動作溢位彈出式視窗的位置 即可調整顯示效果，但選取動作列中的溢位按鈕後 動作溢位彈出式視窗出現在畫面中的修改位置 (如果有的話) 就可以看到選單

如果裝置實作項目未提供選單功能， 相容性：

  • [C-3-1] 在 targetSdkVersion 小於 10，不論是透過實體按鈕、軟體金鑰還是 或手勢這個選單函式必須能與 其他導覽函式。

如果裝置導入方式提供輔助函式， 他們會：

  • [C-4-1] 必須讓使用者透過單一動作存取輔助功能 時 (例如輕觸、按兩下或手勢)。
  • [C-SR-3] 強烈推薦使用長按主畫面功能，因為 指派的互動方式

如果裝置導入方式獨立顯示 瀏覽鍵時，可以執行以下動作：

  • [C-5-1] 瀏覽鍵「必須」使用畫面的一部分，不得 提供給應用程式，不得遮蓋或乾擾 可用的螢幕部分。
  • [C-5-2] 必須向符合下列條件的應用程式提供螢幕的一部分畫面 符合第 7.1.1 節中定義的規定。
  • [C-5-3] 必須遵循應用程式透過 View.setSystemUiVisibility() 所設定的旗標 API 方法，因此畫面的這個不同部分 (又稱為導覽列) 可正確隱藏，如文件所述 SDK。

如果系統以手勢動作的形式提供導覽功能：

是否從左側和右側邊緣的任何位置提供導覽函式 目前的螢幕方向：

  • [C-7-1] 導覽功能「必須」返回，並以 從螢幕目前方向的左右兩側滑動 。
  • [C-7-2] 如果在左側提供自訂滑動系統面板，或是 務必放在畫面上方 1/3 的底部 清楚、持續性的視覺指示，拖曳會叫用 上述面板，因此不會返回。系統面板可能有 由使用者設定，因此到達畫面最上方的 1/3 處 但系統面板「不得使用」超過邊緣的 1/3 邊線。
  • [C-7-3] 當前景應用程式有 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY， WindowInsetsController.BEHAVIOR_DEFAULT，或 已設定 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 旗標， 從邊緣滑動的手勢 必須與 Android 開放原始碼計畫中的實作相同， 已列載於 SDK 中
  • [C-7-4] 當前景應用程式有 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY， WindowInsetsController.BEHAVIOR_DEFAULT，或 已設定 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 旗標， 自訂滑動系統面板必須隱藏，直到使用者進入或 取消延遲系統資訊列 (又稱為導覽列和狀態列) 。

如果提供返回瀏覽函式，且使用者取消返回 手勢，然後：

  • [C-8-1] 必須呼叫 OnBackInvokedCallback.onBackCancelled()。
  • [C-8-2] 不得呼叫 OnBackInvokedCallback.onBackInvoked()。
  • [C-8-3] 「不得」分派 KEYCODE_BACK 事件。

如果提供返回瀏覽函式，但前景應用程式 「OnBackInvokedCallback」尚未註冊，那麼：

  • 系統「必須」為前景應用程式提供動畫 暗示使用者返回 Android 開放原始碼計畫。

如果裝置實作支援系統 API setNavBarMode，即可 允許任何具有 android.permission.STATUS_BAR 權限的系統應用程式設定 導覽列模式，然後：

  • [C-9-1] 必須支援適合兒童的圖示或按鈕式 使用 Android 開放原始碼計畫程式碼提供的導覽介面。

7.2.4。觸控螢幕輸入

Android 支援多種指標輸入系統，例如 觸控螢幕、觸控板和模擬觸控輸入裝置。 以觸控螢幕為基礎的裝置實作 與螢幕相關聯，方便使用者直接 操控螢幕上的項目由於使用者是直接觸碰螢幕 系統不需要任何其他用途 問題。

裝置實作方式：

  • 應採用某種程度的指標輸入系統 (類似滑鼠或輕觸)。
  • 應支援完全獨立追蹤的指標。

如果裝置實作項目提供觸控螢幕 (單點觸控或更優異)， 主要 Android 相容螢幕，因此支援以下功能：

  • [C-1-1] 必須回報Configuration.touchscreen的TOUCHSCREEN_FINGER API 欄位。
  • [C-1-2] 必須回報android.hardware.touchscreen和 android.hardware.faketouch 功能旗標。

如果裝置導入方式包含觸控螢幕，可追蹤 只要在 Android 相容主要螢幕上輕觸一下，就能：

  • [C-2-1] 必須回報適當的功能旗標 android.hardware.touchscreen.multitouch， android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand 對應裝置上特定觸控螢幕的類型。

如果裝置實作時需要使用外部輸入裝置，例如滑鼠或 在主要畫面輸入軌跡球 (即未直接觸碰螢幕) 與 Android 相容的螢幕，並符合 第 7.2.5 節，他們會：

  • [C-3-1] 「不得」回報任何開頭為 android.hardware.touchscreen。
  • [C-3-2] 必須只回報android.hardware.faketouch。
  • [C-3-3] 必須回報TOUCHSCREEN_NOTOUCH Configuration.touchscreen API 欄位。

7.2.5。虛擬觸控輸入

虛假觸控介面提供使用者輸入系統，可近似一小部分 觸控螢幕功能。例如利用滑鼠或遙控器來駕駛 畫面上的遊標是概略觸控，但使用者必須第一個指向或 然後按一下焦點多種輸入裝置，例如滑鼠、觸控板、陀螺儀 空氣滑鼠、陀螺儀、搖桿和多點觸控板可支援 觸控互動Android 加入功能常數 android.hardware.faketouch，對應至高保真非觸控 (指標型) 輸入裝置，如滑鼠或觸控板， 模擬觸控式輸入 (包括基本手勢支援)，並在 裝置支援模擬一部分的觸控螢幕功能。

如果裝置的實作方式沒有觸控螢幕，但提供其他觸控螢幕 供使用者使用的指標輸入系統：

  • 應宣告支援 android.hardware.faketouch 功能標記。

如果裝置實作結果宣告支援 android.hardware.faketouch， 他們會：

  • [C-1-1] 必須回報 X 和 Y 的絕對位置 並在螢幕上顯示視覺指標。
  • [C-1-2] 「必須」使用指定 指標上發生的狀態變更 在畫面上向下或向上。
  • [C-1-3] 必須讓畫面上的物件支援指標向下和向上， 可讓使用者模擬輕觸畫面上的物件
  • [C-1-4] 必須支援向下、指標上、指標朝上，以及指標向上 會和畫面上某個物件在時間門檻內的相同位置 可讓使用者模擬輕觸兩下 螢幕上有一個物件
  • [C-1-5] 必須支援在螢幕上任意位置朝下指標、 指標移至螢幕上任何其他點，後面接著指標 向上，可讓使用者模擬觸控拖曳功能。
  • [C-1-6] 必須把支援指標向下移，然後讓使用者 拖曳到螢幕上的不同位置，然後將滑鼠遊標移到螢幕上的上方， 可讓使用者快速滑過畫面上的物件

如果裝置導入方式宣告支援 android.hardware.faketouch.multitouch.distinct，他們：

  • [C-2-1] 必須宣告支援 android.hardware.faketouch。
  • [C-2-2] 必須能夠針對兩個以上的獨立指標進行獨特追蹤 輸入內容

如果裝置導入方式宣告支援 android.hardware.faketouch.multitouch.jazzhand，他們：

  • [C-3-1] 必須宣告支援 android.hardware.faketouch。
  • [C-3-2] 必須支援 5 種不同軌跡 (追蹤手指) 或更多獨立指標輸入項目。

7.2.6。遊戲控制器支援

7.2.6.1。按鈕對應

裝置實作方式：

  • [C-1-1] 必須能將 HID 事件對應至對應的 InputEvent 常數，如下表所示。Android 上游導入可符合這項規定。

如果裝置導入方式內嵌控制器或隨附獨立控制器，可供使用者輸入下表列出的所有事件，請注意：

  • [C-2-1] 必須宣告功能標記 android.hardware.gamepad
按鈕 HID 用量2 Android 按鈕
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
是1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-Pad 向上鍵1
D-Pad1		 0x01 0x00393 AXIS_HAT_Y4
D-Pad 左側1
D-Pad 向右鍵1		 0x01 0x00393 AXIS_HAT_X4
左肩按鈕1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
右肩按鈕1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
按一下左鍵1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
按一下滑鼠右鍵1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
背面1 0x0c 0x0224 KEYCODE_BACK (4)

1 個 KeyEvent

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

3 這個用法的邏輯下限為 0、 邏輯上限：7，實體下限為 0，實體最大實體 315 個，單位 ，報表大小為 4。邏輯值定義為 沿著垂直軸順時針旋轉；例如 0 表示沒有旋轉，按下向上按鈕，0 則代表邏輯值 1 代表旋轉 45 度，同時按下向上鍵和向左鍵 已按下。

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 說明文件和 sensors 的 Android 開放原始碼說明文件。

裝置實作方式：

  • [C-0-1] 必須根據 android.content.pm.PackageManager敬上 類別
  • [C-0-2] 「必須」透過 SensorManager.getSensorList() 和類似方法。
  • [C-0-3] 必須對所有其他感應器 API (例如 當應用程式嘗試註冊時，適當傳回 true 或 false 事件監聽器，而當對應的感應器不呼叫時，則不會呼叫感應器事件監聽器 存在；等)。

如果裝置實作項目包含特定感應器類型， 因此需要執行以下動作：

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

上方清單僅列舉部分內容；記錄到的 Android SDK 行為 以及 Android 開放原始碼說明文件 感應器 具公信力

如果裝置實作項目包含特定感應器類型， 因此需要執行以下動作：

  • [C-1-6] 必須為所有感應器設定非零的解析度，並回報值 透過 Sensor.getResolution() API 方法。

某些感應器類型為複合類型，因此可從所提供的資料中衍生資料 再由一或多個其他感應器讀取資料(例如方向感應器和 線性加速感應器)。

裝置實作方式：

  • 應實作這些感應器類型， 使用必要的實體感應器 感應器類型。

如果裝置實作項目內含複合感應器，請執行以下操作：

  • [C-2-1] 必須按照 Android 開放原始碼中所述的方式實作感應器 複合感應器說明文件。

如果裝置實作項目包含特定感應器類型， 代表第三方開發人員的對應 API，而感應器只會回報一個 價值，然後採用裝置導入方式：

如果裝置實作項目包含支援特定感應器類型 SensorAdditionalInfo#TYPE_VEC3_CALIBRATION 感應器提供給第三方開發人員，讓他們：

  • [C-4-1] 「不得」加入任何固定的工廠判定校正結果 參數。

若裝置導入方式包含 3 軸式加速度計， 3 軸式迴轉儀感應器或磁力儀感應器，它們具有以下特性：

  • [C-SR-2] 強烈建議使用確保加速計、陀螺儀和 磁力儀具有固定的相對位置，如果裝置 可變形 (例如折疊式裝置) 時，感應器軸會保持一致且一致 內建感應器座標系統，適用於各種可能的裝置 轉換狀態。

7.3.1。加速計

裝置實作方式：

  • [C-SR-1] 強烈建議你加入 3 軸式加速度計。

如果裝置導入作業包含加速計，請按照下列步驟操作：

  • [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
  • [C-1-3] 必須遵守 Android 感應器座標系統 如 Android API 中所述
  • [C-1-4] 必須能夠以自由落體到 4 倍的幅度 各軸的 gravity(4g) 以上。
  • [C-1-5] 必須採用至少 12 位元的解析度。
  • [C-1-6] 標準差不得大於 0.05m/s^，其中 標準差應以樣本數為基準來計算 收集超過 3 秒的資料收集期間，而且是最快的取樣率。
  • 回報的事件大小必須至少為 200 Hz。
  • 解析度至少要有 16 位元。
  • 如果使用中的特性產生變化，則不應進行校正 生命週期和補償，以及保留補償參數 。
  • 應針對溫度獲得補償。

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

  • [C-2-1] 必須導入及回報 TYPE_ACCELEROMETER 感應器。
  • [C-SR-4] 強烈建議導入 TYPE_SIGNIFICANT_MOTION 複合感應器
  • [C-SR-5] 極力建議導入及回報 TYPE_ACCELEROMETER_UNCALIBRATED感應器。Android 裝置極度強大 建議符合這項規定，以便他們能升級至 。
  • 應導入 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、 TYPE_STEP_DETECTOR TYPE_STEP_COUNTER Android SDK 文件所述的複合感應器。

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

  • [C-3-1] 必須導入及回報 TYPE_ACCELEROMETER_LIMITED_AXES 感應器。
  • [C-SR-6] 想要導入及回報 TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED感應器。

如果裝置導入方式包含 3 軸式加速度計和 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、 已實作 TYPE_STEP_COUNTER 複合感應器：

  • [C-4-1] 他們加總 耗電量一律低於 4 mW。
  • 裝置處於動態或動態時 靜態條件

如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀感應器， 他們會：

  • [C-5-1] 必須導入 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器
  • [C-SR-7] 極力建議您導入 TYPE_GAME_ROTATION_VECTOR 複合感應器。

如果裝置導入方式包含 3 軸式加速度計、3 軸式迴轉儀感應器， 和磁力儀感應器進行以下操作：

  • [C-6-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

7.3.2。磁力儀

裝置實作方式：

  • [C-SR-1] 強烈建議你加入 3 軸的磁力計 (指南針)。

如果裝置實作方式包含 3 軸的磁力儀，將會：

  • [C-1-1] 必須實作 TYPE_MAGNETIC_FIELD 感應器。
  • [C-1-2] 必須能夠以至少 10 Hz 的頻率回報事件 ，並應該回報至少 50 Hz 的事件。
  • [C-1-3] 必須符合 Android 感應器座標系統 如 Android API
  • [C-1-4] 必須能夠個別測量介於 -900 μT 和 +900 μT 之間的距離 再進化。
  • [C-1-5] 必須具有小於 700 μT 的硬鐵偏移值，而且必須 將磁力儀放在離 200 μT 以下的距離 動態 (目前誘發) 和靜態 (磁場誘發) 磁場。
  • [C-1-6] 解析度必須等於或小於 0.6 μT。
  • [C-1-7] 必須支援線上校準及補償硬鐵 並保留裝置重新啟動時的補償參數。
  • [C-1-8] 「必須」使用軟鐵補償，校準程序可以 於使用期間或裝置生產過程中完成。
  • [C-1-9] 必須設定標準差，並以各軸為基準來計算 收集期間至少 3 秒的樣本收集速度為最快的取樣 ，不得大於 1.5 μT；標準差不得大於 0.5 μT。
  • [C-1-10] 必須導入 TYPE_MAGNETIC_FIELD_UNCALIBRATED敬上 感應器。

如果裝置導入方式包含 3 軸式磁力計，就會有加速計 感應器和 3 軸式迴轉儀感應器，這些感應器具有以下功能：

  • [C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作方式包含 3 軸式磁力計 (加速計)，將會：

  • 可實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。

如果裝置實作方式包括 3 軸式磁力計、加速計和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器，可以：

  • [C-3-1] 耗電量必須低於 10 mW。
  • 在批次模式註冊感應器的情況下，耗電量應小於 3 毫瓦 速度為 10 Hz

7.3.3.GPS

裝置實作方式：

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

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

  • [C-1-1] 必須支援以至少 1 Hz 的速率輸出位置 已透過 LocationManager#requestLocationUpdate 要求。
  • [C-1-2] 必須能夠判斷在空曠情況下的位置 在 10 秒內 (快速信號，多徑無阻，HDOP < 2) 每次修正時間) 連上 0.5 Mbps 或更快的數據速度 網際網路連線。使用部分應用程式就能符合這項規定。 輔助或預測 GPS/GNSS 技術形式 以縮短 GPS/GNSS 鎖定時間 (輔助資料包含參考時間、 參考地點和衛星/時鐘)。
    • [C-1-6] 算出此類位置後，裝置 導入方式「必須」決定其在開放天空中、在 5 秒，再次提出位置資訊要求時，最多持續 1 小時 就算在後續要求中 未使用數據連線及/或重新開機後完成。

  • 判斷地點後，在開放天際的環境中，靜止或靜止不動 移動的加速度小於每秒 1 公尺的平方：

    • [C-1-3] 必須能夠判斷距離為 20 公尺且速度最快的位置 每秒 0.5 公尺，且至少需要 95% 的時間。
    • [C-1-4] 必須同時透過以下方式追蹤及回報： GnssStatus.Callback敬上 至少 8 個衛星定位。
    • 至少要能同時追蹤 24 個衛星、 多個星座 (例如 GPS 及至少 1 座鳳凰城的其中一顆 Galileo)。

  • [C-SR-2] 極力建議繼續提供正常 GPS/GNSS 緊急電話期間透過 GNSS Location Provider API 輸出的位置資訊 呼叫。

  • [C-SR-3] 強烈建議 追蹤的星座（如 GnssStatus 訊息中報告），但例外 SBAS 系列

  • [C-SR-4] 強烈建議你回報 AGC 和 GNSS 的頻率 成效評估方式

  • [C-SR-5] 強烈建議提供所有準確率預估值 (包括方位、速度和垂直)。

  • [C-SR-6] 強烈建議你盡快記錄 GNSS 評估結果 或是 GNSS 計算出的位置 。

  • [C-SR-7] 強烈建議你回報 GNSS 虛擬範圍和 虛擬範圍比率，在判斷地點後 靜止不動或移動時 每秒不到 0.2 公尺的平方 足以計算出 20 公尺以內且速度 0.2 公尺以內，至少 95% 的時間

7.3.4。陀螺儀

裝置實作方式：

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

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

  • [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
  • [C-1-4] 必須採用 12 位元以上的解析度。
  • [C-1-5] 必須計算溫度。
  • [C-1-6] 使用時請務必進行校準與補償，並且保留 。
  • [C-1-7] 每 Hz 的變異數不得超過 1e-7 rad^2 / s^2 (每 Hz 的變異數，或雷比^2 / 秒)。變異數則是以 但必須受到這個值限制。也就是說 以 1 Hz 的取樣率測量陀螺儀的變異數，不應大於 高於 1e-7 rad^2/s^2。
  • [C-SR-2] 校正錯誤應一律小於 0.01 以上 裝置在室溫下靜止時移動
  • [C-SR-3] 強烈建議採用 16 位元以上的解析度。
  • 回報的事件大小必須至少為 200 Hz。

如果裝置實作方式包含 3 軸式迴轉儀，請按照下列步驟操作：

如果裝置實作的陀螺儀少於 3 軸，參數：

  • [C-3-1] 必須導入及回報 TYPE_GYROSCOPE_LIMITED_AXES 感應器。
  • [C-SR-5] 想要導入並回報相關情況 TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED感應器。

如果裝置導入方式包含 3 軸式迴轉儀， 和磁力儀感應器進行以下操作：

  • [C-4-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀 感應器，因此會：

  • [C-5-1] 必須導入 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器
  • [C-SR-6] 強烈建議你導入 TYPE_GAME_ROTATION_VECTOR敬上 複合感應器

7.3.5。氣壓計

裝置實作方式：

  • [C-SR-1] 強烈建議加上氣壓計 (環境氣壓) 感應器)。

如果裝置導入作業內含氣壓計，請按照下列步驟操作：

  • [C-1-1] 必須導入及回報 TYPE_PRESSURE 感應器。
  • [C-1-2] 必須能夠以 5 Hz 以上傳送事件。
  • [C-1-3] 必須計算溫度。
  • [C-SR-2] 強烈推薦能夠回報壓力測量值 介於 300hPa 至 1100hPa 之間
  • 應有 1hPa 的絕對精確性。
  • 應有 20hPa 範圍的 0.12hPa 相對準確度 (海拔 200 公尺的變動幅度達到約 100 萬的準確率值)。

7.3.6。測溫

如果裝置導入作業包括環境溫度計 (溫度感應器)， 他們會：

  • [C-1-1] 必須定義 SENSOR_TYPE_AMBIENT_TEMPERATURE 環境溫度感應器和感應器「必須」測量環境 (房間/車廂) 與使用者進行互動的位置 以攝氏度為單位。

如果裝置的實作方式附有溫度計感應器，可測量 溫度以外的溫度 (例如 CPU 溫度) 會進行以下動作：

如果裝置裝有可監控皮膚溫度的感應器， 然後：

7.3.7。相框模式

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

7.3.8。鄰近感應器

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

如果裝置導入作業包含鄰近感應器，但系統只回報 二進位「附近的」或「far」讀者：

  • [C-1-1] 測量物體與物體的距離時，應與 。換句話說，鄰近感應器必須朝向鄰近感應器才能偵測物體 因為這種感應器類型的主要用途 偵測使用者正在使用的手機如果裝置導入方式包含 其他方向的鄰近感應器，「不得」存取 透過這個 API
  • [C-1-2] 準確度必須達到 1 位元以上。
  • [C-1-3] 靠近讀數必須使用 0 公分， 讀取資料。
  • [C-1-4] 請務必回報最大範圍和解析度為 5。

7.3.9。高保真感測器

如果裝置實作項目包含一組品質較高的感應器 (如定義) 並將這些內容提供給第三方應用程式，則這些應用程式具有以下特點：

  • [C-1-1] 必須透過 android.hardware.sensor.hifi_sensors 功能旗標。

如果裝置實作方式宣告 android.hardware.sensor.hifi_sensors 他們會：

  • [C-2-1] 必須具備下列功能的TYPE_ACCELEROMETER感應器：

    • 測量範圍必須介於 -8 公克到 +8 公克之間，且為 強烈建議採用至少 -16 克的測量範圍 和 +16g
    • 必須採用至少 2048 LSB/g 的測量解析度。
    • 測量頻率不得低於 12.5 Hz。
    • 測量頻率上限為 400 Hz 以上；應 支援 SensorDirectChannel RATE_VERY_FAST。
    • 測量噪音必須超過 400 μg/√Hz。
    • 必須導入這個感應器的非喚醒形式，才能使用緩衝區 至少可處理 3,000 個感應器事件
    • 批次耗電量不得低於 3 毫瓦。
    • [C-SR-1] 強烈建議使用 3dB 測量頻寬 至少 80% 的荷蘭頻率和白雜訊光譜 頻寬。
    • 應在 室溫。
    • 應該有偏誤變化，而不是溫度 ≤ +/- 1 毫克/°C。
    • 應採用 ≤ 0.5% 且靈敏度變化與溫度變化 (與溫度 ≤ ) 的非線性 0.03%/C°。
    • 跨軸敏感度應為 <2.5 % 和 跨軸靈敏度 <裝置作業溫度範圍介於 0.2% 之間。

  • [C-2-2] 必須具有相同的 TYPE_ACCELEROMETER_UNCALIBRATED 品質相關規定 (TYPE_ACCELEROMETER)

  • [C-2-3] 必須使用 TYPE_GYROSCOPE 感應器，才能執行以下操作：

    • 測量範圍必須至少介於 -1,000 到 +1000 dp。
    • 測量解析度必須至少為 16 LSB/dp。
    • 測量頻率不得低於 12.5 Hz。
    • 測量頻率上限為 400 Hz 以上；應 支援 SensorDirectChannel RATE_VERY_FAST。
    • 測量噪音必須超過 0.014°/s/√Hz。
    • [C-SR-2] 強烈建議使用 3dB 測量頻寬 至少 80% 的荷蘭頻率和白雜訊光譜 頻寬。
    • 應在房間內進行測試，且其隨機步行速度必須小於 0.001 °/s √Hz 溫度。
    • 應該有偏誤變化，而不是溫度 ≤ +/- 0.05 °/ s / °C。
    • 應有靈敏度變化，但溫度應為 ≤ 0.02% / °C。
    • 應採用最佳適配線非線性性，且不超過 0.2%。
    • 雜訊密度必須小於 0.007 °/s/√Hz。
    • 校正錯誤應小於 0.002 雷/秒 裝置靜止時，溫度範圍為 10 ~ 40 °C。
    • 應靈敏度小於 0.1°/s/g。
    • 跨軸敏感度應為 <4.0 % 和跨軸敏感度 變化 <裝置作業溫度範圍介於 0.3% 之間。

  • [C-2-4] 必須具有品質相同的TYPE_GYROSCOPE_UNCALIBRATED 定義TYPE_GYROSCOPE要求。

  • [C-2-5] 必須使用 TYPE_GEOMAGNETIC_FIELD 感應器，才能執行以下操作：

    • 測量範圍必須至少介於 -900 到 +900 μT 之間。
    • 必須採用至少 5 LSB/uT 的測量解析度。
    • 測量頻率不得低於 5 Hz。
    • 測量頻率上限為 50 Hz 以上。
    • 測量噪音必須超過 0.5 uT。

  • [C-2-6] 必須具有品質相同的TYPE_MAGNETIC_FIELD_UNCALIBRATED 須滿足 TYPE_GEOMAGNETIC_FIELD 的需求，以及下列項目：

    • 必須導入這個感應器的非喚醒形式，才能使用緩衝區 至少支援 600 個感應器事件
    • [C-SR-3] 強烈建議使用白噪音頻譜 (1 Hz 到 1 Hz) 回報率為 50 Hz 或更高時，至少 10 Hz。

  • [C-2-7] 必須具備下列功能的TYPE_PRESSURE感應器：

    • 測量範圍必須介於 300 到 1100 hPa 之間。
    • 必須採用至少 80 LSB/hPa 的測量解析度。
    • 測量頻率不得低於 1 Hz。
    • 測量頻率上限為 10 Hz。
    • 測量噪音必須不能超過 2 Pa/√Hz。
    • 必須導入這個感應器的非喚醒形式，才能使用緩衝區 至少支援 300 個感應器事件
    • 批次耗電量不得低於 2 mW。

  • [C-2-8] 必須搭配 TYPE_GAME_ROTATION_VECTOR 感應器。

  • [C-2-9] 必須使用 TYPE_SIGNIFICANT_MOTION 感應器，才能執行以下操作：

    • 裝置處於以下狀態時，耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。

  • [C-2-10] 必須搭載 TYPE_STEP_DETECTOR 感應器，才能執行以下操作：

    • 必須導入這個感應器的非喚醒形式，才能使用緩衝區 至少支援 100 個感應器事件
    • 裝置處於以下狀態時，耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。
    • 批次耗電量不得低於 4 mW。

  • [C-2-11] 必須搭載下列 TYPE_STEP_COUNTER 感應器：

    • 裝置處於以下狀態時，耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。

  • [C-2-12] 必須搭載 TILT_DETECTOR 感應器，才能執行以下操作：

    • 裝置處於以下狀態時，耗電量必須低於 0.5 mW 靜態影像和 1.5 mW。

  • [C-2-13] 相同實體事件的時間戳記， 加速計、陀螺儀和磁力儀皆須在 2.5 毫秒內 建構的介面由系統回報的相同實體事件時間戳記 加速計和陀螺儀應在各間隔 0.25 毫秒內 其他。

  • [C-2-14] 必須同時設有陀螺儀感應器事件時間戳記 而且在 1 毫秒內發生錯誤。

  • [C-2-15] 請務必在 5 毫秒內，將範例提供給應用程式 上述任何實體感應器取得資料時 傳送至應用程式

  • [C-2-16] 耗電量「不得」高於 0.5 毫瓦 當裝置為靜態時，且裝置正在移動時為 2.0 mW 啟用下列感應器組合時：

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] 可能配備 TYPE_PROXIMITY 感應器，但如果有的話 至少將緩衝區功能設為 100 個感應器事件

請注意，本節的所有耗電量要求均不包含 應用程式處理器的耗電量。其中包括 Google 的 整個感測器鏈，也就是感應器、任何支撐電路、 而專門的感應器處理系統等

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

  • [C-3-1] 必須正確宣告支援直接管道類型和直接管道類型 透過 isDirectChannelTypeSupported 回報費率層級 和 getHighestDirectReportRateLevel 也能使用 Google Cloud CLI 或 Compute Engine API
  • [C-3-2] 必須支援至少兩種感應器直接通道類型的一種 。
  • 應透過感應器直接管道支援事件報告， 感應器 (非喚醒變化版本)：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10。生物特徵辨識感應器

如需評估生物特徵辨識解鎖安全性的其他背景資訊，請參閱 評估生物特徵辨識安全性說明文件。

如果實作的裝置包含安全螢幕鎖定，他們會：

  • 應包含生物特徵辨識感應器

生物特徵辨識感應器可歸類為第 3 級 (先前稱為 Strong) 第 2 級 (舊稱 Weak) 或第 1 級 (舊稱「便利」) 然後取而代之的是 這種模型這個分類會決定 生物特徵辨識感應器必須連結 Google Cloud Platform 應用程式。感應器必須符合下列額外規定， 分級為「第 1 級」、「第 2 級」或「第 3 級」。 第 2 級和第 3 級生物特徵辨識功能都具備下列功能 詳情請見下文。

如果裝置實作項目提供生物特徵辨識感應器給第三方 透過 android.hardware.biometrics.BiometricManager 安裝應用程式 android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL、 他們會：

  • [C-4-1] 必須符合第 3 級或第 2 級生物特徵辨識的規定 可採用其他定義方法
  • [C-4-2] 必須識別並遵守定義為常數的每個參數名稱 Authenticators 類別和其中的任何組合 相反地，「不得」使用或識別傳遞到 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法以外的方法 驗證器 和任意組合
  • [C-4-3] 必須導入 ACTION_BIOMETRIC_ENROLL 對搭載第 3 級或第 2 級生物特徵辨識的裝置執行動作。 這項操作「必須」顯示第 3 級的註冊進入點 或第 2 級生物特徵辨識。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-4-4] 必須允許應用程式將自訂內容新增至「BiometricPrompt」 放送 PromptContentView 內容顯示格式內容顯示 不得延伸這些格式，以允許取得圖像、連結、互動式內容 不屬於 BiometricPrompt 的其他形式的媒體 也能使用 Google Cloud CLI 或 Compute Engine API不會修改、遮掩或截斷此內容的樣式調整 不同元素 (例如變更位置、邊框間距、邊界、 字體排版)。

終止新規定

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

  • [C-5-1] 在預設情況下，「必須」需要額外的確認步驟 (例如按下按鈕)。
  • [C-SR-1] 強烈建議使用者採用 覆寫應用程式偏好設定，並一律需要 確認步驟。
  • [C-SR-2] 強烈建議確保確認動作安全無虞 避免作業系統或核心入侵的破壞行為 例如，這表示根據實體按鈕的確認動作 是透過僅限輸入的一般用途輸入/輸出 (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] 必須符合第 3 級 (如 以下章節。
  • [C-6-2] 驗證時，只能提供第 3 級的生物特徵辨識資訊 需要 BIOMETRIC_STRONG、 或是使用 CryptoObject 叫用驗證。

如要在裝置實作項目中將生物特徵辨識感應器視為第 1 級， (舊稱「便利性」) 的用途如下：

  • [C-1-1] 不正確的接受率必須低於 0.002%。
  • [C-1-2] 必須說明此模式的安全性可能低於高強度 PIN 碼。 並清楚說明啟用風險。 假冒和偽造接受率高於 7% Android 生物特徵辨識測試通訊協定。
  • [C-1-9] 必須要求使用者要求提供建議的主要驗證方式 (例如：PIN 碼、解鎖圖案、密碼) 且未超過 20 次 不到 90 秒的生物特徵辨識驗證的輪詢時間 假試用是拍攝品質足夠的 (BIOMETRIC_ACQUIRED_GOOD) 與已註冊的生物特徵辨識不相符。
  • [C-SR-4] 強烈建議你降低虛假試驗的總數 用於生物特徵辨識驗證 [C-1-9] (假使是假冒者) Android 生物特徵辨識指標的接受率高於 7% 測試通訊協定。
  • [C-1-3] 必須限制生物特徵辨識驗證的頻率，其中 假試用是拍攝品質足夠的 (BIOMETRIC_ACQUIRED_GOOD)。 與已註冊的生物特徵辨識不相符的情況。
  • [C-SR-5] 強烈建議你至少嘗試限制頻率 出現 5 次虛構的生物特徵辨識驗證證明後 30 秒 每個 [C-1-9] 的虛假試驗數量上限 - 虛假試驗為 足夠的拍攝品質 (BIOMETRIC_ACQUIRED_GOOD)，不符合 已註冊的生物特徵辨識。
  • [C-SR-6] 強烈建議在 TEE 中採用所有頻率限制邏輯。
  • [C-1-10] 主要驗證輪詢後，「必須」停用生物特徵辨識功能 最初觸發，如第 9.11 節 [C-0-2] 所述。
  • [C-1-11] 假冒及冒名要求接受率不得超過 30% 具有 (1) 假冒 A 級簡報的假冒與冒名接受率 攻擊工具 (PAI) 物種超過 30%，以及 (2) 假冒 第一級 PAI 物種的即時接受率，如 40% 以上， Android 生物特徵辨識測試通訊協定測得的分數。
  • [C-1-4] 必須避免在未建立 讓使用者確認現有裝置或新增裝置，建立信任鏈 受 TEE 保護的憑證 (PIN 碼/圖案/密碼)；Android Open 實作來源專案會在架構中提供相應機制 例如

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-5] 必須完全移除使用者的所有可識別生物特徵辨識資料 使用者帳戶移除時 (包括透過恢復原廠設定) 也不是建議主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 都會遭到移除。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-7] 必須要求使用者提出建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼等) 每 24 小時一次。 注意：升級搭載 Android 9 以下版本的裝置「必須」升級 要求使用者執行建議的主要驗證方式 (例如 PIN 碼、 解鎖圖案、密碼) 最多 1 次。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-8] 必須向使用者詢問建議的主要年齡 驗證 (例如 PIN 碼、解鎖圖案、密碼) 或第 3 級 (STRONG) 生物特徵辨識 在下列其中一個項目後：
    • 4 小時的閒置逾時期限，或
    • 3 次生物特徵辨識驗證失敗。
    • 閒置逾時期限和失敗的驗證次數已重設 並在成功確認裝置憑證後執行。 注意：升級搭載 Android 9 版的裝置 或更早的版本，符合 C-1-8 的豁免資格。

終止新規定

  • [C-SR-7] 強烈建議你使用提供的架構中的邏輯 以便強制執行 新裝置的 [C-1-7] 和 [C-1-8]。
  • [C-SR-8] 強烈建議設定錯誤的拒絕率 低於 10% (以裝置為準)。
  • [C-SR-9] 強烈建議將延遲時間維持在 1 秒以下， 從偵測到生物特徵辨識的時間點到螢幕解鎖 已註冊的生物特徵辨識。
  • [C-1-12] 假冒和冒名要求接受率不得超過 40% 每種呈現式攻擊工具 (PAI) 物種的比率 Android 生物特徵辨識測試通訊協定。
  • [C-SR-13] 強烈推薦您冒用他人身分 攻擊者接受率未高於 30% 每種呈現式攻擊工具 (PAI) 物種的比率 Android 生物特徵辨識測試通訊協定。
  • [C-SR-8] 強烈建議設定錯誤的拒絕率 低於 10% (以裝置為準)。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-15] 必須允許使用者移除單一或多個生物特徵辨識資料 註冊。

終止新規定

  • [C-SR-14] 強烈建議你揭露 生物特徵辨識感應器及其對應風險。

  • [C-SR-17] 強烈建議導入新的 AIDL 介面 (例如 IFace.aidl 和 IFingerprint.aidl)。

如要在裝置實作項目中將生物特徵辨識感應器視為第 2 級， (原為 Weak) 客戶：

  • [C-2-1] 必須符合上述第 1 級的所有規定。
  • [C-2-2] 假冒和冒名要求接受率不得超過 20% 的確有 (1) 代表 A 級簡報攻擊工具 (PAI) 物種不到 20% 以及 (2) 假冒 B 級 PAI 物種的假冒和冒名接受率 高於 30% Android 生物特徵辨識測試通訊協定。
  • [C-SR-15] 強烈推薦假冒和假冒他人 接受率不超過 20% 每種呈現式攻擊工具 (PAI) 物種的比率 Android 生物特徵辨識測試通訊協定。
  • [C-2-3] 必須展現 在 Android 以外的獨立執行環境中進行生物特徵辨識比對 使用者或核心空間，例如受信任的執行環境 (TEE) 透過包含安全通道的晶片，連線至獨立的執行環境 或符合第 9.17 節規定的「Protected Virtual Machine」
  • [C-2-4] 所有識別資料都必須經過加密及加密處理 才能取得、讀取或修改 隔離的執行環境，或是包含安全管道的晶片 獨立的執行環境，如實作中所述 準則 Android 開放原始碼計畫網站 或受保護的虛擬機器上 由符合第 9.17 節所列需求的管理程序控管。
  • [C-2-5] 適用於相機式生物特徵辨識，以及生物特徵辨識驗證 或註冊正在進行中：
    • 「務必」在禁止相機畫面的模式下操作相機 在隔離執行環境或晶片外讀取或修改 隔離執行環境或受保護環境的安全管道 由符合第一節需求的管理程序控管的虛擬機器 9.17。
    • 如果是 RGB 單一相機解決方案，相機影格 CAN 可在獨立執行環境外讀取以支援作業 例如預覽註冊，但「不得」修改。
  • [C-2-6] 「不得」允許第三方應用程式區分 個人生物特徵辨識註冊資料。
  • [C-2-7] 不得允許未加密存取可識別的生物特徵辨識資料；或 任何從資料衍生到應用程式處理器的資料 (如嵌入) TEE 或受保護虛擬機器控制的環境外 遵循第 9.17 節的要求管理程序。 搭載 Android 9 以下版本的裝置升級不符合豁免條件 分別是 C-2-7 的

  • [C-2-8] 必須提供安全的處理管道， 系統或核心入侵行為無法允許資料直接插入 假冒使用者身分 注意：如果裝置實作項目已推出 Android 第 9 版 或更早的版本，無法透過系統軟體符合 C-2-8 的要求 更新，則可能不受規定的約束。

  • [C-SR-10] 強烈建議以下所有人採用有效性偵測 臉部生物特徵辨識的生物特徵辨識和注意力偵測功能

  • [C-2-9] 必須允許第三方使用生物特徵辨識感應器 應用程式。

如要在裝置實作下將生物特徵辨識感應器視為第 3 級， (先前稱為「Strong」) 的情況下，他們會：

  • [C-3-1] 必須符合上述第 2 級的所有規定，但 [C-1-7] 和 [C-1-8]。
  • [C-3-2] 必須實作硬體支援的 KeyStore。
  • [C-3-3] 假冒及假冒他人接受率必須高於 7% 的確有 (1) 代表 A 級簡報攻擊工具 (PAI) 物種不到 7%，且 (2) 高於 B 級 PAI 物種的虛假或冒名接受率 大於 20% Android 生物特徵辨識測試通訊協定。
  • [C-3-4] 必須向使用者詢問建議的主要年齡 每 72 小時驗證一次 (例如 PIN 碼、解鎖圖案、密碼) 以下。
  • [C-3-5] 必須重新產生 Authenticator ID 適用於裝置支援的所有第 3 級生物特徵辨識 (如果有的話) 重新註冊。
  • [C-3-6] 必須為第三方啟用生物特徵辨識支援的 KeyStore 金鑰 應用程式。

  • [C-SR-16] 強烈推薦假冒和假冒他人 接受率不超過 每種呈現式攻擊工具 (PAI) 物種的 7%，評估標準為 Android 生物特徵辨識測試通訊協定。 如果裝置實作項目包含螢幕底下的指紋感應器 (UDFPS)， 他們會：

  • [C-SR-11] 強烈建議你避免 UDFPS 的可觸控區域 幹擾三按鈕操作模式( 部分使用者可能需要 無障礙功能)。

7.3.11。姿勢感應器

裝置實作方式：

  • 可能支援 6 度自由度的姿勢感應器。

如果裝置實作支援自由 6 度自由姿勢的姿勢感應器，請按照下列步驟操作：

  • [C-1-1] 必須導入及回報 TYPE_POSE_6DOF 感應器。
  • [C-1-2] 必須比只使用旋轉向量時的精確度更高。

7.3.12。轉軸角度感應器

如果裝置的實作方式支援轉軸角度感應器，就會：

7.3.13。IEEE 802.1.15.4 (UWB)

如果裝置的導入方式包含對 802.1.15.4 的支援，並且公開 功能，讓他們：

  • [C-1-2] 必須回報硬體功能旗標 android.hardware.uwb。
  • [C-1-3] 必須支援下列所有設定集 (預先定義的設定集) 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。電話通訊系統

「電話」而是在本文件中特別針對 與撥打語音通話及傳送簡訊等相關硬體服務的情形。 透過行動裝置建立行動數據 (例如 GSM、CDMA、LTE、NR)GSM 或 CDMA 更是如此支援「電話」功能的裝置您可以選擇提供部分或全部 通話、訊息和資料服務

  • Android MAY 適用於不含電話硬體硬體的裝置。沒錯 表示 Android 與非手機裝置相容。

如果裝置實作包含 GSM 或 CDMA 電話，則：

  • [C-1-1] 必須宣告 android.hardware.telephony 功能旗標和 再依據技術定義其他子功能旗標
  • [C-1-2] 「必須」針對該技術導入完整的 API 支援。
  • 應允許所有可用的行動服務類型 (2G、3G、4G、5G 等) ，不論網路類型為何， SetAllowedNetworkTypeBitmap())。

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

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

如果裝置的實作支援 eUICC 或 eSIM 卡/內嵌 SIM 卡，且 專屬機制為第三方提供 eSIM 卡功能 開發人員的工作：

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

如果裝置實作支援單一 IP 多媒體子系統 (IMS) 多媒體電話服務 (MMTEL) 和 採用進階通訊解決方案 (RCS) 功能，並且必須遵守 行動電信業者規範，使用單一 所有 IMS 信號流量的 IMS 註冊，它們：

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

如果裝置實作結果回報 android.hardware.telephony 功能 並提供系統狀態列，然後：

  • [C-7-1] 必須為指定項目選取具代表性的有效訂閱方案 UUID 群組 也就是提供 SIM 卡狀態的任何用途 可能不準確或不適當這類預設用途的例子包括狀態列行動網路 訊號圖示或快速設定方塊。
  • [C-SR-1] 強烈建議這個代表性訂閱是 成為 有效資料訂閱 除非裝置語音 來電，強烈推薦業務代表 訂閱是指有效的語音訂閱。

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

  • [C-6-7] 必須能夠開放，並且同時使用最大值 根據 ETSI TS 102 221 的每個 UICC 邏輯通道數 (共 20 個)。
  • [C-6-8] 「不得」對使用中的電信業者應用程式套用下列任何行為 (由TelephonyManager#getCarrierServicePackageName指定) 自動或未經使用者明確確認：
    • 撤銷或限制網路存取權
    • 撤銷權限
    • 限制在 Android 開放原始碼計畫現有電源管理功能之外的情況下，執行背景或前景應用程式作業
    • 停用或解除安裝應用程式

如果裝置實作結果回報 android.hardware.telephony 功能， 全部有效， 非機會式訂閱 共用群組 UUID 將會停用 從裝置取下，或標示為有機會從裝置中移除，然後：

  • [C-8-1] 必須自動停用所有剩餘使用中的 機會式 同一個群組中的訂閱項目

如果裝置實作包含 GSM 電話，但不包括 CDMA 電話，則：

如果裝置實作支援具有多個通訊埠和設定檔的 eUICC，則：

7.4.1.1。號碼封鎖相容性

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

  • [C-1-1] 必須支援電話號碼封鎖功能
  • [C-1-2] 必須完全導入 BlockedNumberContract 以及 SDK 文件中所述的對應 API

  • [C-1-3] 必須封鎖以下地區所有來自電話號碼的來電和訊息： 「blockNumberProvider」完全不必與應用程式互動唯一的例外狀況 通常是因 SDK 中所述的 說明文件。

  • [C-1-4] 必須寫入平台通話記錄供應商 已封鎖來電，而且必須過濾掉有 BLOCKED_TYPE 的來電 預設的通話紀錄檢視畫面。

  • [C-1-5] 「不得」寫信給電話供應商 表示已封鎖的訊息

  • [C-1-6] 必須實作已開啟的號碼管理使用者介面 (已開啟) 以及 TelecomManager.createManageBlockedNumbersIntent() 傳回的意圖 方法。

  • [C-1-7] 「不得」允許次要使用者查看或編輯已封鎖的號碼 Android 平台會假設主要使用者俱備 單一執行個體。所有語言 「必須」對次要使用者隱藏封鎖相關使用者介面，且「必須」加入封鎖清單 仍尊重他人

  • 裝置更新時，應將已封鎖的號碼遷移至供應商 。

  • 應用程式預先安裝的來電應顯示已封鎖的通話，而且應提供使用者負擔 撥號應用程式

7.4.1.2。Telecom API

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

  • [C-1-1] 必須支援 SDK 中所述的 ConnectionService API。
  • [C-1-2] 必須顯示新來電，並向使用者清楚說明 當使用者正在通話時，接聽或拒接來電 由不支援保留功能的第三方應用程式所製作 透過 CAPABILITY_SUPPORT_HOLD。
  • [C-1-3] 應用程式「必須」 InCallService：

  • [C-SR-1] 強烈建議你告知使用者回答問題 來電會中斷進行中的通話。

    Android 開放原始碼計畫實作項目可透過抬頭通知，符合這些規定 向接聽來電的使用者說明 才能掛斷其他通話

  • [C-SR-2] 強烈建議你預先載入預設撥號應用程式， 會在其通話記錄中顯示通話記錄項目和第三方應用程式的名稱 第三方應用程式設定 EXTRA_LOG_SELF_MANAGED_CALLS敬上 在 PhoneAccount 上額外將鍵新增至 true。

  • [C-SR-3] 強烈建議你處理音訊耳機的 適用於行動裝置的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件 android.telecom敬上 API，如下所示：

7.4.1.3。行動網路 NAT-T 保持運作卸載

裝置實作方式：

  • 應支援行動網路保持運作卸載。

如果裝置實作支援行動保持運作的卸載功能， 會負責向第三方應用程式提供這些功能：

  • [C-1-1] 必須支援 SocketKeepAlive API。
  • [C-1-2] 必須支援至少一個透過行動網路並行的保持運作運算單元。
  • [C-1-3] 必須盡可能支援多個同時進行的行動網路保持運作運算單元 行動無線電 HAL 支援功能
  • [C-SR-1] 強烈建議你至少支援三種手機保持運作狀態 每個無線電執行個體的運算單元數量。

如果裝置的實作不支援行動網路保持運作卸載功能， 他們會：

  • [C-2-1] 必須傳回 ERROR_UNSUPPORTED。

7.4.2。IEEE 802.11 (Wi-Fi)

裝置實作方式：

  • 應支援一或多種 802.11 形式。

如果裝置實作提供 802.11 支援，並公開 功能，讓他們：

  • [C-1-1] 必須實作對應的 Android API。
  • [C-1-2] 必須回報硬體功能旗標 android.hardware.wifi。
  • [C-1-3] 必須導入多點傳送 API 如 SDK 說明文件中所述。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [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 要求的 mDNS 作業 相互整合不過，裝置會在必要時篩選 mDNS 封包 避免超出法規需求規定的耗電量 以及適用的 DPI

終止新規定

  • [C-1-5] 不得將WifiManager.enableNetwork() 透過 API 方法呼叫，即可充分指示切換目前使用中的 應用程式流量預設使用的 Network，並且會傳回 製作者：ConnectivityManager API 方法，例如 getActiveNetwork 和 registerDefaultNetworkCallback。 也就是說，他們「可能」只會禁止 其他網路供應商 (例如行動數據網路) 是否成功通過驗證 該 Wi-Fi 網路提供網際網路存取權。
  • [C-1-6] 強烈建議你 ConnectivityManager.reportNetworkConnectivity()敬上 呼叫 API 方法時，請重新評估 Network 上的網際網路存取權， 一旦評估判定目前的 Network 不再提供 網際網路連線，切換至其他可用的網路 (例如行動網路) 網路資料)。
  • [C-1-7] 必須隨機產生來源 MAC 位址和探測序列編號 每次掃描開始時一次要求影格數，STA 則 已中斷連線。
  • [C-1-8] 必須使用一個一致的 MAC 位址 (不應隨機化 MAC 位址) 掃描的位址)。
  • [C-1-9] 必須按照一般 (依序) 方式疊代探測要求序號 指定權重
  • [C-1-10] 必須在最後一個探測作業之間隨機產生探測要求序號 和下一次掃描作業的第一次探測要求
  • [C-SR-1] 強烈建議你隨機挑選要用於 MAC 位址的來源 MAC 位址 與存取點 (AP) 的所有 STA 通訊，藉此連結 連結。
    • 裝置「必須」為每個 SSID 使用不同的隨機 MAC 位址 (Passpoint FQDN) 則會與其通訊。
    • 裝置「必須」為使用者提供控制 每個 SSID (Passpoint 的 FQDN) 隨機化和非隨機 和「必須」設定新 Wi-Fi 的預設模式 隨機排序
  • [C-SR-2] 強烈建議他們為任何 AP 使用隨機的 BSSID 建立。
    • 每個 MAC 位址都必須隨機化，並保留成 AP。
    • 「裝置」可能提供使用者停用這項功能的選項。 如有提供這個選項，則「必須」預設為啟用。

如果裝置實作所需支援 Wi-Fi 省電模式 (如定義) 的 IEEE 802.11 標準：

  • 每次取得應用程式時，都應關閉 Wi-Fi 省電模式 WIFI_MODE_FULL_HIGH_PERF 鎖或 WIFI_MODE_FULL_LOW_LATENCY 門鎖 透過 WifiManager.createWifiLock() 和WifiManager.WifiLock.acquire() API，而且鎖定功能已啟用。
  • [C-3-2] 裝置之間的平均往返延遲時間 以及存取點 (WIFI_MODE_FULL_LOW_LATENCY) 模式必須小於 Wi-Fi 高效能鎖定 (WIFI_MODE_FULL_HIGH_PERF) 模式下的延遲時間。
  • [C-SR-3] 強烈建議你盡量縮短 Wi-Fi 封包往返延遲時間 每當收到低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 時 並生效

如果實作的裝置支援 Wi-Fi 並使用 Wi-Fi 掃描位置， 他們會：

7.4.2.1。Wi-Fi Direct

裝置實作方式：

  • 應提供 Wi-Fi Direct (Wi-Fi 點對點) 支援。

如果裝置的實作支援 Wi-Fi Direct，請採取下列行動：

  • [C-1-1] 必須實作對應的 Android API 如 SDK 說明文件中所述。
  • [C-1-2] 必須回報 android.hardware.wifi.direct 硬體功能。
  • [C-1-3] 必須支援一般 Wi-Fi 運作。
  • [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。
  • [C-SR-1] 強烈建議為所有使用者提供來源 MAC 位址 新建立的 Wi-Fi Direct 連線。

裝置實作方式：

如果裝置實作項目支援 TDLS，且 Wi-FiManager API 執行升級作業：

  • [C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。
  • 請只在可能且有利的情況下使用 TDLS。
  • 應獲得一些經驗法則，避免在效能表現可能受到影響的情況下使用 TDLS 會比通過 Wi-Fi 存取點還更好。
7.4.2.3。Wi-Fi 偵測

裝置實作方式：

如果裝置實作項目提供 Wi-Fi Aware 支援，並公開 具備以下存取權：

  • [C-1-1] 必須按照WifiAwareManager SDK 說明文件。
  • [C-1-2] 必須宣告 android.hardware.wifi.aware 功能標記。
  • [C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
  • [C-1-4] 請務必每隔一段時間隨機隨機產生 Wi-Fi Aware 管理介面位址 不超過 30 分鐘。此外，如果未啟用 Wi-Fi Aware， 範圍轉移作業進行中，或 Aware 資料路徑已啟用 (隨機化未 只要資料路徑為有效狀態，就會有不良記錄)。

如果裝置實作項目提供 Wi-Fi Aware 和 參閱 7.4.2.5 節所述的 Wi-Fi 位置資訊和 先向第三方應用程式提供這些功能，然後：

7.4.2.4。Wi-Fi Passpoint

如果裝置的實作支援 802.11 (Wi-Fi) 版本，他們會：

  • [C-1-1] 必須支援 Wi-Fi Passpoint。
  • [C-1-2] 必須導入 Passpoint 相關 WifiManager API，因為 搭配 SDK 說明文件中所述。
  • [C-1-3] 必須支援 IEEE 802.11u 標準、明確相關 到「聯播網」發掘及選擇，例如「一般廣告」 服務 (GAS) 和存取網路查詢通訊協定 (ANQP)。
  • [C-1-4] 必須宣告 android.hardware.wifi.passpoint 功能標記。
  • [C-1-5] 必須遵循 Android 開放原始碼計畫實作項目，才能探索、比對並建立關聯 傳遞到 Passpoint 網路
  • [C-1-6] 至少要支援下列部分的裝置佈建 Wi-Fi Alliance Passpoint R2：EAP-TTLS 中定義的通訊協定 驗證和 SOAP-XML
  • [C-1-7] 必須按照下列說明處理 AAA 伺服器憑證： 無線基地台 2.0 R3 規格。
  • [C-1-8] 必須讓使用者能夠透過 Wi-Fi 挑選器控管佈建作業。
  • [C-1-9] 重新啟動時，請務必讓 Passpoint 設定保持一致。
  • [C-SR-1] 極力建議支援條款及細則 接受功能。
  • [C-SR-2] 強烈建議支援地點資訊功能。

如果提供全域 Passpoint 停用使用者控制項切換選項，系統會導入以下程式碼：

  • [C-3-1] 預設「必須」啟用 Passpoint。
7.4.2.5。Wi-Fi 定位服務 (Wi-Fi 封包往返時間 - RTT)

裝置實作方式：

如果裝置實作項目支援 Wi-Fi 定位功能，並公開 具備以下存取權：

  • [C-1-1] 必須按照WifiRttManager SDK 說明文件。
  • [C-1-2] 必須宣告 android.hardware.wifi.rtt 功能標記。
  • [C-1-3] 必須為每個 RTT 爆發來源隨機產生來源 MAC 位址 此物件會在用於 RTT 的 Wi-Fi 介面時執行 執行的範圍未與存取點建立關聯。
  • [C-1-4] 在第 68 號享有 80 MHz 頻寬時，請確保準確度為 2 公尺以內 百分位數 (以累計分佈函式計算)。
  • [C-SR-1] 強烈建議在 1.5 公尺以內回報正確 和第 68 個百分位數的 80 MHz 頻寬 ( 累計分配函式)。
7.4.2.6。Wi-Fi 保持運作卸載

裝置實作方式：

  • 應提供 Wi-Fi 保持運作卸載支援。

如果裝置實作支援 Wi-Fi 保持運作卸載功能 以及向第三方應用程式提供這些功能後，應用程式會：

  • [C-1-1] 必須支援 SocketKeepAlive API。
  • [C-1-2] 必須支援透過 Wi-Fi 連線至少三個並行的保持運作運算單元

如果裝置實作不支援 Wi-Fi 保持運作卸載功能， 他們會：

7.4.2.7。Wi-Fi 輕鬆連線 (裝置佈建通訊協定)

裝置實作方式：

如果裝置實作提供 Wi-Fi 輕鬆連線支援，並公開 目的是：

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

如果 Wi-Fi 伺服器憑證未通過驗證或 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 (一般屬性設定檔) 式藍牙 中所述的 API android.bluetooth。
  • [C-3-3] 必須回報 BluetoothAdapter.isOffloadedFilteringSupported() 用於表示 ScanFilter 的篩選邏輯 已實作 API 類別。
  • [C-3-4] 必須回報 BluetoothAdapter.isMultipleAdvertisementSupported() 表示 是否支援低能源廣告。

  • [C-3-5] 必須不再導入可撤銷的私人網址 (RPA) 逾時 並在逾時時輪替地址，以保護使用者隱私 裝置使用 BLE 掃描或放送廣告時。 為了避免時差攻擊，必須一併隨機設定逾時間隔 介於 5 到 15 分鐘

  • 應支援將篩選邏輯卸載至藍牙晶片組 建議使用 ScanFilter API。

  • 應支援將批次掃描卸載到藍牙晶片組。

  • 應支援至少有 4 個版位的多廣告。

如果實作的裝置支援藍牙 LE，並將藍牙 LE 用於 位置掃描則能：

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

如果實作的裝置支援藍牙 LE 和助聽器 個人資料，說明如下： 透過藍牙 LE 支援的助聽器音訊支援：

如果實作的裝置支援藍牙或藍牙低功耗， 他們會：

  • [C-6-1] 必須限制存取任何藍牙中繼資料 (例如掃描) 結果) 可用來推斷裝置的所在位置，除非 要求的應用程式成功將 android.permission.ACCESS_FINE_LOCATION 以目前的前景/背景狀態為依據的權限檢查。

如果實作的裝置支援藍牙或藍牙低功耗 應用程式資訊清單未包含開發人員的宣告 並非透過藍牙取得位置資訊 然後：

如果裝置實作傳回 true 的 BluetoothAdapter.isLeAudioSupported() API，然後會：

  • [C-7-1] 必須支援單點傳播用戶端。
  • [C-7-2] 必須支援 200 萬個菲律賓，
  • [C-7-3] 必須支援 LE 延伸廣告。
  • [C-7-4] CIG 中至少須支援 2 個 CIS 連線。
  • [C-7-5] 必須啟用 BAP 單點傳播用戶端、CSIP 集合協調器、MCP 伺服器 VCP 控制器和 CCP 伺服器。
  • [C-SR-1] 極力建議啟用 HAP 單點傳播用戶端。

如果裝置實作傳回 true 的 BluetoothAdapter.isLeAudioBroadcastSourceSupported() API，然後會：

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

如果裝置實作傳回 true 的 BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API，然後會：

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

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

  • [C-10-1] 必須採用 +/-9dB 的 RSSI 測量結果，才能確保 95% 的 測量距離與參考裝置 ( ADVERTISE_TX_POWER_HIGH。
  • [C-10-2] 必須加入 Rx/Tx 修正，才能減少每個管道的偏差 測量 3 個聲道 每個天線的測量值 (如果使用多個) 介於彼此的 +/-3dB 之間，佔 95% 的 測量資料
  • [C-SR-2] 強烈建議你評估與補償的 Rx 偏移 確保 BLE RSSI 的中位數是 -60dBm +/-10 dB，距離 參考裝置傳輸時間：ADVERTISE_TX_POWER_HIGH，裝置來源 並將方向定向為「平行平面」螢幕寬度都一樣 往上移動即可
  • [C-SR-3] 強烈建議你評估與補償的 Tx 偏移量 從參照掃描掃描時，確保 BLE RSSI 的中位數為 -60dBm +/-10 dB 裝置定位在 1 公尺以內，且傳輸至 ADVERTISE_TX_POWER_HIGH，即裝置的功能為主軸 「平行平面」就是面對相同方向的螢幕

我們強烈建議您按照 所在地校正要求。

7.4.4。近距離無線通訊

裝置實作方式：

  • 應提供近距離無線通訊設備和相關硬體 通訊 (NFC)：
  • [C-0-1] 必須導入 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，即使 API 不支援 NFC 或 宣告 android.hardware.nfc 功能，因為類別代表 通訊協定獨立資料表示格式，

如果裝置實作項目內含 NFC 硬體，並打算提供 第三方應用程式的權限：

  • [C-1-1] 必須向開發人員回報「android.hardware.nfc」功能 android.content.pm.PackageManager.hasSystemFeature() 方法。
  • 必須能夠透過下列 NFC 讀取及寫入 NDEF 訊息 標準屬性：
  • [C-1-2] 必須能擔任 NFC 論壇讀取者/寫入者 (根據 NFC 論壇的技術規格定義)。 NFCForum-TS-DigitalProtocol-1.0)，
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC 論壇標記類型 1、2、3、4、5 (由 NFC 論壇定義)

  • [C-SR-1] 強烈建議能夠讀取和寫入 NDEF 訊息與原始資料 (須符合下列 NFC 標準)。請注意， NFC 標準標示為「強烈建議」 我們計劃因應未來版本變更的相容性定義： 必須「必須」能避免這個版本均為選用標準，但規定是必填項目 。搭載這個版本的現有和新裝置 我們強烈建議 Android 符合這些條件 都能升級至未來的平台版本。

  • [C-1-13] 使用 NFC 探索功能時，「必須」輪詢所有支援的技術 模式。

  • 裝置喚醒時，應處於 NFC 探索模式 螢幕處於啟動狀態，且螢幕鎖定時已解鎖。

  • 應該能夠讀取 Thinfilm NFC 條碼 很少直接解答該如何打造產品

請注意，公開的連結不適用於 JIS、ISO 和 NFC 文中所述的論壇規格。

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

如果裝置實作包含支援 HCE 的 NFC 控制器晶片組 (適用於 NfcA 和/或 NfcB) 並且支援應用程式 ID (AID) 轉送功能，這些機制包括：

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

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

  • [C-3-1] 必須回報 android.hardware.nfc.hcef 功能常數。
  • [C-3-2] 必須導入 NfcF Card Emulation API 符合 Android SDK 的定義

如果裝置實作項目提供如本內容所述的一般 NFC 支援 區段及支援 MIFARE 技術 (MIFARE Classic、 MIFARE Ultralight、MIFARE Classic 上的 NDEF)，必須具備以下角色：

  • [C-4-1] 必須按照 Android SDK
  • [C-4-2] 必須向下列人員回報「com.nxp.mifare」功能： android.content.pm.PackageManager.hasSystemFeature() 方法。請注意，這並非標準的 Android 功能，因此不會 在 android.content.pm.PackageManager 類別中以常數顯示。

7.4.5。網路通訊協定和 API

7.4.5.1。最低網路功能

裝置實作方式：

  • [C-0-1] 必須支援一或多種 以及資料網路具體來說，裝置的實作「必須」提供 至少一個能夠使用 200 Kbit/秒以上的資料標準。優先放送示例 包括 EDGE、HSPA、EV-DO 802.11g、乙太網路和藍牙 PAN。
  • 也應支援至少一項常見的無線資料 標準，例如 802.11 (Wi-Fi)，但其實是實體網路標準 (例如 乙太網路) 是主要數據連線。
  • 可以導入多種形式的數據連線。
7.4.5.2。IPv6

裝置實作方式：

  • [C-0-2] 必須納入 IPv6 網路堆疊，並支援 IPv6 以及使用代管 API 進行通訊，例如 java.net.Socket 和 java.net.URLConnection 以及原生 API，例如 AF_INET6 通訊端。
  • [C-0-3] 預設為啟用 IPv6。
    • 「必須」確保 IPv6 通訊可靠做為 IPv4，例如：
      • [C-0-4] 必須在打盹模式下維持 IPv6 連線。
      • [C-0-5] 頻率限制「不得」導致裝置失去 IPv6 且支援高可用性 VPN 網路的任何網路，且該網路會使用 至少 180 秒
  • [C-0-6] 必須向第三方應用程式提供直接 IPv6 連線功能 無需任何形式的位址或 IP 位址 通訊埠翻譯作業只會在裝置上進行這兩種代管 API，例如 Socket#getLocalAddress敬上 或 Socket#getLocalPort) 和 NDK API (例如 getsockname() 或 IPV6_PKTINFO) 都必須傳回 IP 這個位址和通訊埠實際用於 網路，並且會以來源 IP 和網際網路 (Web) 伺服器的通訊埠形式顯示。

所需的 IPv6 支援等級會因網路類型而異，如 下列規定。

如果實作的裝置支援 Wi-Fi，就會：

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

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

  • [C-2-1] 必須支援在 乙太網路。

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

  • [C-3-1] 必須支援 IPv6 作業 (僅限 IPv6 且可能採用雙重堆疊) 。

如果裝置導入方式支援多種網路類型 (例如Wi-Fi 和行動數據) 的涵蓋範圍，包括：

  • [C-4-1] 每個網路都必須同時符合上述規定 當裝置同時連線至多種網路類型時。
7.4.5.3。網頁認證入口

網頁驗證入口是指需要登入才能使用的網路 連上網際網路。

如果裝置實作提供完整的 android.webkit.Webview API、 他們會：

  • [C-1-1] 必須提供網頁認證入口應用程式來處理意圖 ACTION_CAPTIVE_PORTAL_SIGN_IN敬上 並傳送該意圖，以便顯示網頁認證入口登入頁面 呼叫 System API ConnectivityManager#startCaptivePortalApp(Network, Bundle)。
  • [C-1-2] 必須執行網頁認證入口偵測，並支援登入 當裝置連線時，透過網頁認證入口應用程式來連線 任何網路類型 (包括行動網路/行動網路、Wi-Fi 和乙太網路) 或使用藍牙功能
  • [C-1-3] 必須支援使用明文 DNS 登入網頁認證入口 當裝置設定使用私人 DNS 嚴格模式時。
  • [C-1-4] 「必須」按照 SDK 說明文件中的指示，使用加密的 DNS android.net.LinkProperties.getPrivateDnsServerName敬上 和 android.net.LinkProperties.isPrivateDnsActive 適用於所有未明確與 網頁認證入口。
  • [C-1-5] 必須確保使用者透過網頁認證登入 入口網站，由應用程式使用的預設網路 (由 ConnectivityManager.getActiveNetwork、 ConnectivityManager.registerDefaultNetworkCallback, 預設也由 Java 網路 API 使用，例如 java.net.Socket 而原生 API (例如 connect()) 則是任何其他可用的網路 提供網際網路連線 (如果有的話)

7.4.6。同步處理設定

裝置實作方式：

7.4.7。數據節省模式

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

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

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

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

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

7.4.8。安全元件

如果裝置實作方式支援支援 Open Mobile API 安全元素，並將這些元素提供給第三方應用程式，它們具有以下特點：

7.4.9。UWB

如果裝置導入方式提供支援 並提供給第三方應用程式 然後：

  • [C-1-1] 必須在 android.uwb 中實作對應的 Android API。
  • [C-1-2] 必須回報硬體功能標記 android.hardware.uwb。
  • [C-1-3] 必須支援 Android 中定義的所有相關 UWB 設定檔 。
  • [C-1-4] 必須提供使用者負擔，讓使用者切換 UWB 無線電開啟/關閉狀態。
  • [C-1-5] 必須強制要求使用 UWB 無線電的應用程式擁有 UWB_RANGING 權限 (在 NEARBY_devices 權限群組底下)。
  • [C-SR-1] 極力建議您通過相關法規和 由標準機構訂定的認證測試，包括 FIRA、CCC 和 CSA 表單中的指示操作。
  • [C-1-6] 必須確保距離測量結果在 +/-15 公分以內以 95% 為單位 只能測量距離 非反射性的腔
  • [C-1-7] 必須確保距離測量結果的中位數是 1 公尺 在參照裝置的 [0.75m, 1.25m] 內，實際資料 距離是由 DUT 頂端邊緣測量而得。
  • [C-SR-2] 強烈建議你按照評估設定步驟操作 指定於 所在地校正要求。

7.5.相機

如果裝置的實作方式至少包含一部相機，這些裝置會：

如果裝置的實作支援 HDR 10 位元輸出功能，就會：

  • [C-2-1] 每部相機裝置至少須支援 HLG HDR 設定檔 支援 10 位元輸出
  • [C-2-2] 必須支援 10 位元輸出，供主要後置鏡頭或 主要前置鏡頭
  • [C-SR-1] 強烈建議同時支援兩個主要版本支援 10 位元輸出 相機上
  • [C-2-3] 所有成員都必須支援相同的 HDR 設定檔 邏輯相機支援 BACKWARD_COMPATIBLE 的實體子相機，以及 邏輯性相機本身

適用於支援 10 位元 HDR，且採用 android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API，則具有以下權限：

  • [C-3-1] 必須支援在所有具回溯相容性的實體之間切換 透過邏輯相機上的 CONTROL_ZOOM_RATIO 控制項操作。

7.5.1。後置鏡頭

後置鏡頭則是使用世界鏡頭的相機，拍攝遠處景象 如同傳統相機也就是攝影機 (位於裝置側面的螢幕另一側)。

裝置實作方式：

  • 應使用後置鏡頭。

如果裝置實作項目包含至少一個後置鏡頭，會發生下列情況：

  • [C-1-1] 必須回報功能旗標 android.hardware.camera 和 android.hardware.camera.any。
  • [C-1-2] 必須採用至少 200 萬像素的解析度。
  • 應導入硬體自動對焦或軟體自動對焦功能 (直通應用程式軟體)，
  • 可能具備固定對焦或 EDOF (延伸領域深度) 硬體。
  • 可能包含閃光燈。

如果攝影機包含閃光燈：

  • [C-2-1] 閃光燈時，手電筒「不得」亮起 已註冊 android.hardware.Camera.PreviewCallback 個執行個體 顯示在相機預覽介面上，除非應用程式已明確啟用 啟用 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，即可使用 Flash Camera.Parameters 物件的定義。請注意，這項限制不適用於 裝置內建的系統相機應用程式，但僅限第三方 使用 Camera.PreviewCallback 存取應用程式。

7.5.2。前置鏡頭

前置鏡頭是指面向使用者的鏡頭，通常用來拍攝圖像 使用者存取視訊會議等類似的應用程式；手持裝置 也就是與螢幕位於裝置同一側的相機

裝置實作方式：

  • 建議使用前置鏡頭。

如果裝置的實作方式至少包含一個前置鏡頭，這些裝置會：

  • [C-1-1] 必須回報功能旗標 android.hardware.camera.any 和 android.hardware.camera.front。
  • [C-1-2] 解析度至少須為 VGA (640x480 像素)。
  • [C-1-3] 「不得」使用前置鏡頭做為 Camera API，且不得設定 API，將前置鏡頭視為 。
  • [C-1-4] 相機預覽畫面必須和 目前應用程式所指定的方向 明確要求相機 螢幕就會通過呼叫 android.hardware.Camera.setDisplayOrientation()敬上 方法。相反地，預覽畫面「必須」以裝置的預設方式雙向同步 目前應用程式未明確請求 呼叫，「相機」畫面就會透過呼叫 android.hardware.Camera.setDisplayOrientation()敬上 方法。
  • [C-1-5] 「不得」反映最終拍攝的靜態圖片或影片串流 傳回至應用程式回呼，或承諾用於媒體儲存空間。
  • [C-1-6] 請務必以相同方式鏡像投射後檢視畫面所顯示的圖像 做為相機預覽圖像串流
  • 可能提供自動對焦、閃光燈等 後置鏡頭，如第 7.5.1 節所述。

如果裝置導入方式可由使用者旋轉 (例如 透過加速計自動切換，或依使用者輸入內容手動執行)：

  • [C-2-1] 相機預覽畫面必須根據 裝置目前的螢幕方向

7.5.3.外接鏡頭

外接式攝影機是可以實際連接或卸離的攝影機 裝置實作方式，且可能遇到任何方向；例如 USB 相機上

裝置實作方式：

  • 可考慮支援外接攝影機，但不一定有 隨時保持連線。

如果裝置的實作支援外部攝影機，這些裝置會：

  • [C-1-1] 必須宣告平台功能旗標 《android.hardware.camera.external》和《android.hardware camera.any》。
  • [C-1-2] 如果外接式裝置，則必須支援 USB 視訊類別 (UVC 1.0 以上版本) 必須透過 USB 主機連接埠連接攝影機
  • [C-1-3] 必須使用實體外接鏡頭裝置通過相機 CTS 測試 已連線。如要進一步瞭解相機 CTS 測試，請前往 source.android.com。
  • 應支援 MJPEG 等影片壓縮功能，以便傳輸 高品質未編碼串流 (原始或獨立壓縮的圖片) 串流)。
  • 支援多部相機。
  • 支援相機式影片編碼。

如果支援相機式影片編碼：

  • [C-2-1] 同時 未編碼 / MJPEG 串流 (QVGA 或更高解析度) 必須可供存取 裝置實作。

7.5.4。Camera API 行為

Android 提供兩種存取相機的 API 套件 (新版) android.hardware.camera2 API 向應用程式公開低階相機控制項。 包括高效率的零複製/串流資料流，以及每個影格的控制項 曝光, 增加, 白平衡, 色彩轉換, 降噪, 銳利, 等等。

舊版 API 套件 android.hardware.Camera 在 Android 5.0 版本，但應仍可供應用程式使用。Android 裝置 導入方式「必須」確保如 這個區段以及 Android SDK 中

已淘汰的 android.hardware.Camera 類別通用的所有功能 而較新的 android.hardware.camera2 套件「必須」具備同等效能 以及品質與品質舉例來說，假設有對等的設定 自動對焦速度和準確率必須相同，且拍攝圖像的品質必須相同 必須相同。依附兩個 API 不同語意的功能 不需要具有比對速度或品質，但應盡量達成密切比對 。

裝置實作「必須」為 相機相關 API。裝置實作方式：

  • [C-0-1] 必須使用 android.hardware.PixelFormat.YCbCr_420_SP 預覽 當應用程式從未呼叫時，提供給應用程式回呼的資料 android.hardware.Camera.Parameters.setPreviewFormat(int)。
  • [C-0-2] 應用程式時，必須進一步採用 NV21 編碼格式 註冊 android.hardware.Camera.PreviewCallback 系統會呼叫 onPreviewFrame() 方法和預覽 格式為 YCbCr_420_SP，也就是傳遞至 onPreviewFrame() 的位元組 [] 資料。 也就是說，必須預設為 NV21。
  • [C-0-3] 必須支援 YV12 格式 (如 android.graphics.ImageFormat.YV12 常數) 兩者的相機預覽畫面 android.hardware.Camera 適用的前置和後置鏡頭(硬體 影片編碼器和攝影機可以使用任何原生像素格式，但裝置會 導入方式「必須」支援轉換為 YV12 的版本)。
  • [C-0-4] 必須支援 android.hardware.ImageFormat.YUV_420_888 和 使用 android.hardware.ImageFormat.JPEG 格式做為輸出內容 android.media.ImageReader 適用的 android.hardware.camera2 裝置 宣傳「REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE」 功能，android.request.availableCapabilities。
  • [C-0-5] 仍需實作完整的 Camera API 參閱該文件，無論裝置 包括硬體自動對焦或其他功能例如相機需要的相機 缺少自動對焦功能，您仍然必須針對 android.hardware.Camera.AutoFocusCallback 個執行個體 (雖然沒有執行個體 以及與非自動對焦相機之間的關聯性)。請注意，這適用於前置鏡頭 相機；例如大多數前置鏡頭 則 API 回呼仍必須「虛設」。
  • [C-0-6] 必須識別及遵循每個參數名稱 在 Pod 中定義為常數 android.hardware.Camera.Parameters敬上 和 android.hardware.camera2.CaptureRequest 類別。 相反地，裝置的實作「不得」遵循或辨識字串常數 傳遞至其他 android.hardware.Camera.setParameters() 方法 在 android.hardware.Camera.Parameters 上以常數記錄。也就是說 裝置實作項目必須「必須」支援所有標準相機參數， 硬體允許，且「不得」支援自訂的相機參數類型。 例如支援擷取圖片的裝置導入方式 使用高動態範圍 (HDR) 影像技術「必須」支援相機參數 Camera.SCENE_MODE_HDR。
  • [C-0-7] 必須使用 android.info.supportedHardwareLevel敬上 並回報適當的 架構功能旗標。
  • [C-0-8] 必須也宣告其個別相機功能 android.hardware.camera2 (透過 android.request.availableCapabilities 資源 並宣告適當的功能旗標 如果裝置連接的相機裝置有任何，「必須」定義功能旗標 可支援這項功能
  • [C-0-9] 必須廣播Camera.ACTION_NEW_PICTURE 意圖 (每次相機拍攝新相片時) 和 已將 張圖片新增至媒體儲存區。
  • [C-0-10] 必須播送Camera.ACTION_NEW_VIDEO 意圖，以及攝影機記錄新影片的意圖 已將 張圖片新增至媒體儲存區。
  • [C-0-11] 必須允許所有透過已淘汰的相機存取 android.hardware.Camera敬上 您也可以透過 android.hardware.camera2 存取 API 也能使用 Google Cloud CLI 或 Compute Engine API
  • [C-0-12] 必須確保臉部外觀未經過修改，包括： 包括但不限於改變臉部幾何圖形、臉部膚色或臉部 適合任何 android.hardware.camera2 的肌膚保養 或 android.hardware.Camera 也能使用 Google Cloud CLI 或 Compute Engine API
  • [C-SR-1] 適用於配備多組 RGB 相機的裝置 例如鄰近區域，面向相同方向 我們極力建議支援邏輯相機裝置 能力 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA、 包括所有面向該方向的 RGB 相機，做為實體次要裝置。

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

  • [C-1-1] 必須使用 android.hardware.camera2 實作這類相機 API 也能使用 Google Cloud CLI 或 Compute Engine API
  • 可向 android.hardware.camera2 提供供應商代碼和/或擴充功能 也能使用 Google Cloud CLI 或 Compute Engine API

7.5.5。相機方向

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

  • [C-1-1] 請清楚取向，攝影機的長邊對齊 螢幕的長尺寸也就是將裝置拿在橫向時 螢幕方向，相機「必須」以橫向方式拍攝圖片。這個 不受裝置的自然方向影響；也就是說 橫向或直向裝置，以及直向的主要裝置。

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

  • 裝置會導入可變幾何圖形的螢幕，例如折疊式或轉軸 螢幕。
  • 當裝置的折疊或轉軸狀態改變時，裝置會在 portrait-primary 至橫向-Primary (或相反) 螢幕方向。
  • 無法由使用者旋轉的裝置實作 視為車用裝置

7.6.記憶體與儲存空間

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

裝置實作方式：

  • [C-0-1] 必須包含 下載管理員 「可能」使用的應用程式「可能」下載資料檔案，而且具備 下載大小至少為 100 MB 的個別檔案。 「快取」或 HTTP/HTTPS 位置

7.6.2。應用程式共用儲存空間

裝置實作方式：

  • [C-0-1] 「必須」提供儲存空間供應用程式共用 (通常簡稱為 做為「共用外部儲存空間」、「應用程式共用儲存空間」或是 Linux 的 路徑「/sdcard」與掛接的
  • [C-0-2] 必須設定預設掛接共用儲存裝置或其他 「立即可用」的文字，不論儲存空間是否實作於 內部儲存元件或卸除式儲存媒介 (例如 數位卡插槽)。
  • [C-0-3] 「必須」直接在 Linux 路徑上掛接應用程式共用儲存空間 請sdcard，或是加入 sdcard 至實際掛接的 Linux 符號連結 點。
  • [C-0-4] 必須啟用 限定範圍儲存空間 根據預設 應用程式指定目標 API 級別 29 以上，但下列情況除外：
    • 當應用程式要求 android:requestLegacyExternalStorage="true" 。
  • [C-0-5] 必須遮蓋位置中繼資料 (例如 GPS EXIF 標記) 儲存在 透過 MediaStore 存取這些檔案時的媒體檔案，但 發出呼叫的應用程式會保留 ACCESS_MEDIA_LOCATION 權限。

裝置實作方式「可能」符合上述規定，請使用 包括：

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

如果裝置實作方式為滿足上述需求，使用卸除式儲存空間 需求，他們可以：

  • [C-1-1] 必須導入浮動式訊息或彈出式使用者介面警告使用者 儲存媒介不存在時。
  • [C-1-2] 必須包含 FAT 格式的儲存媒介 (例如 SD 卡) 或節目 以及購買時提供的其他資料 媒介必須另外購買。

如果實作裝置時，使用一部分無法移除的儲存空間來滿足 上述規定：

  • 應使用分享到內部應用程式的 Android 開放原始碼計畫實作項目 如果 30 天內讀取資料不到一次 建議使用 Coldline Storage
  • 可以與應用程式私人資料共用儲存空間。

如果裝置實作項目具備支援 USB 週邊裝置模式的 USB 連接埠， 他們會：

  • [C-3-1] 必須提供存取應用程式資料的機制 共用儲存空間
  • 應以公開透明的方式公開來自這兩個儲存空間路徑的內容 Android 的媒體掃描器服務和 android.provider.MediaStore。
  • 可能使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定以滿足 這項規定。

如果裝置實作的 USB 連接埠具備 USB 週邊裝置模式，並支援 媒體傳輸通訊協定，他們可以：

7.6.3.採用儲存空間

假如裝置本身應為行動裝置，而不是電視， 裝置實作方式如下：

  • [C-SR-1] 強烈建議在以下位置導入要使用的儲存空間： 才能維持長期穩定位置 可能造成資料遺失/損毀

如果卸除式儲存裝置通訊埠位於長期穩定的位置， 例如電池座或其他保護蓋 裝置實作方式如下：

7.7.USB

若裝置實作有 USB 連接埠，請檢查下列事項：

  • 應支援 USB 週邊模式，且應支援 USB 主機模式。
  • 應支援停用 USB 數據訊號。

7.7.1。USB 週邊裝置模式

如果裝置實作包含支援週邊裝置的 USB 連接埠：

  • [C-1-1] 連接埠「必須」可連接具備標準的 USB 主機 Type-A 或 Type-C USB 連接埠。
  • [C-1-2] 必須根據 USB 標準回報 iSerialNumber 的正確值 透過 android.os.Build.SERIAL 設定裝置描述元
  • [C-1-3] 必須根據 Type-C 電阻器偵測 1.5A 和 3.0A 充電器 「標準」而且「必須」偵測廣告中的變更 (如果提供支援) Type-C USB。
  • [C-SR-1] 連接埠必須使用 micro-B、micro-AB 或 Type-C USB 板型規格。 現有和新款 Android 裝置強烈建議要符合這些規格 相關規定，以便升級至日後的平台版本。
  • [C-SR-2] 連接埠應位於裝置底部 (根據自然方向) 或啟用軟體螢幕旋轉功能 所有應用程式 (包括主畫面)，讓螢幕在 裝置以位於底部的連接埠方向為準。現有和新的 Android 裝置 我們會強烈建議符合這些規定的裝置， 較新的平台版本
  • [C-SR-3] 應導入支援功能，在 HS 晶片期間繪製 1.5 A 電流 以及 USB 電池充電規格 (修訂版本 1.2) 所規定的流量。 現有和新款 Android 裝置強烈建議要符合這些規格 相關規定，以便升級至日後的平台版本。
  • [C-SR-4] 強烈建議不要提供專屬支援服務 充電方法；修改 Vbus 電壓超過預設等級，或改變 這樣接收器/來源角色可能會導致與 或支援標準 USB Power Delivery 方法的充電器或裝置。雖然 在日後的 Android 版本中，這稱為「強烈建議」 可能需要用到所有 Type-C 裝置，才能完整支援與標準的互通性 Type-C 充電器。
  • [C-SR-5] 強烈建議你為資料與 Power Delivery 支援 電源角色交換，前提是這些裝置支援 Type-C USB 和 USB 主機模式。
  • 應支援 Power Delivery 針對高壓充電與支援 替代模式，例如螢幕。
  • 應導入 Android Open Accessory (AOA) API 和 請參閱 Android SDK 說明文件中的指示

如果裝置實作包含 USB 連接埠並實作 AOA 規格，以便：

  • [C-2-1] 必須宣告支援硬體功能 android.hardware.usb.accessory。
  • [C-2-2] USB 大量儲存空間級別「必須」包含「android」字串的 USB 大量儲存裝置的介面說明 iInterface 字串結尾

7.7.2。USB 主機模式

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

  • [C-1-1] 必須實作 Android USB 主機 API，如 Android SDK，且必須宣告支援硬體功能 android.hardware.usb.host。
  • [C-1-2] 必須導入支援功能，才能連接標準 USB 週邊裝置。 換句話說，它們「必須」：
    • 使用裝置端 C 連接埠，或透過傳輸線調整裝置端的傳輸線 專用連接埠和標準 USB Type-C 連接埠 (USB Type-C 裝置)。
    • 使用裝置端 A，或是透過傳輸線調整裝置端的設定 和標準 USB Type-A 連接埠搭配使用。
    • 裝置端的 Micro-AB 連接埠應搭配傳輸線， 複製到標準的 A 型連接埠
  • [C-1-3] 「請勿」隨附從 USB 類型 A 轉換的變壓器，或 micro-AB 連接埠連線到 Type-C 連接埠 (插座)。
  • [C-SR-1] 極力建議您導入 USB 音訊類別 如 Android SDK 說明文件所述
  • 在主機充電時，應支援為連接的 USB 週邊裝置充電 模式；廣告的源源目前至少為 1.5A，如 適用於 USB Type-C 的 USB Type-C 傳輸線和連接器規格修訂版本 1.2 或使用充電下游連接埠 (CDP) 將目前範圍輸出為 的 USB 電池充電規格，修訂版本 1.2 。
  • 應實作並支援 USB Type-C 標準。

如果裝置實作項目提供支援主機模式的 USB 連接埠和 USB 音訊類別，就能得到下列好處：

  • [C-2-1] 必須支援 USB HID 類別。
  • [C-2-2] 必須支援偵測及對應下列 HID 資料 USB HID 使用表格中指定的欄位 和 Voice 指令使用要求 加入 KeyEvent 常數，如下所示：
    • 用量頁面 (0xC) 用量 ID (0x0CD)：KEYCODE_MEDIA_PLAY_PAUSE
    • 用量頁面 (0xC) 用量 ID (0x0E9)：KEYCODE_VOLUME_UP
    • 用量頁面 (0xC) 用量 ID (0x0EA)：KEYCODE_VOLUME_DOWN
    • 用量頁面 (0xC) 用量 ID (0x0CF)：KEYCODE_VOICE_ASSIST

如果裝置實作項目提供支援主機模式的 USB 連接埠， 儲存空間存取架構 (SAF)，他們可以：

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

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

  • [C-4-1] 必須實作 USB 定義的雙角色通訊埠功能 Type-C 規格 (第 4.5.1.3.3 節)。雙通道用 角色連接埠，如果是支援 3.5 公釐耳機插孔的裝置，則為 USB 接收器 自動偵測 (主機模式) 可能預設為關閉，但只有在執行 以便啟用該功能
  • [C-SR-2] 強烈推薦支援 DisplayPort，應支援 USB 超速資料傳輸速率，也強烈建議支援 Power Delivery 功能 資料及輔助角色交換
  • [C-SR-3] 強烈建議「不」支援音訊轉接器配件模式， 會在 USB Type-C 傳輸線和連接器規格修訂版本 1.2。
  • 請導入最適合 裝置板型規格舉例來說，手持裝置必須 試試看 SNK 模型。

7.8.音訊

7.8.1。麥克風

如果裝置實作項目內含麥克風，裝置會：

  • [C-1-1] 必須回報 android.hardware.microphone 功能常數。
  • [C-1-2] 必須符合下列音訊錄音規定： 第 5.4 節。
  • [C-1-3] 必須符合 第 5.6 節。
  • [C-SR-1] 強烈建議你支援近乎超音波錄音功能 (如上所述) 第 7.8.3 節。

如果裝置實作方式省略麥克風，系統會：

  • [C-2-1] 「不得」回報 android.hardware.microphone 功能常數。
  • [C-2-2] 至少要導入音訊錄音 API，至少要以人工作業方式處理 第 7 節。

7.8.2。音訊輸出裝置

如果裝置的實作方式包含喇叭或音訊/多媒體輸出裝置 音訊輸出週邊裝置的連接埠，例如 4 導體 3.5 公釐耳機插孔， 使用 USB 音訊類別的 USB 主機模式連接埠：

  • [C-1-1] 必須回報 android.hardware.audio.output 功能常數。
  • [C-1-2] 必須符合 第 5.5 節。
  • [C-1-3] 必須符合 第 5.6 節。
  • [C-SR-1] 強烈建議你支援近乎超音波播放功能 (如上所述) 第 7.8.3 節。

如果裝置的實作方式不包含喇叭或音訊輸出通訊埠，就會：

  • [C-2-1] 不得回報android.hardware.audio.output功能。
  • [C-2-2] 至少要實作音訊輸出相關 API 作為免人工管理。

就本節目的而言，「輸出通訊埠」是 實體介面 例如 3.5 公釐耳機插孔、HDMI 或具備 USB 音訊類別的 USB 主機模式通訊埠。 支援透過藍牙、 Wi-Fi 或行動網路不符合「輸出連接埠」的資格。

7.8.2.1。類比音訊連接埠

為了與 耳機和其他音訊配件 3.5 公釐音訊插頭適用於 Android 生態系統 (如有裝置) 實作包含一或多個類比音訊通訊埠：

  • [C-SR-1] 強烈建議你至少加入 音訊連接埠以及 4 指導管 3.5 公釐耳機插孔。

如果裝置實作方式為 4 導體 3.5 公釐耳機插孔，則：

  • [C-1-1] 必須支援透過立體聲耳機和立體聲耳機播放音訊 麥克風圖示
  • [C-1-2] 必須支援 CTIA 輸出順序的 TRRS 音訊插頭。
  • [C-1-3] 必須支援偵測並對應至 麥克風與接地之間的 3 個範圍同等阻礙 音訊插頭上的導電器：
    • 70 ohm 以下：KEYCODE_HEADSETHOOK
    • 210-290 ohm：KEYCODE_VOLUME_UP
    • 360-680 ohm：KEYCODE_VOLUME_DOWN
  • [C-1-4] 插入插頭時必須觸發 ACTION_HEADSET_PLUG，但 外掛程式上的所有聯絡人都觸碰到相關的區隔後才會開始 。
  • [C-1-5] 必須能夠駕駛至少 150mV ±10% 的輸出電壓， 32 釐米喇叭阻抗
  • [C-1-6] 麥克風偏壓電壓應介於 1.8V 至 2.9V 之間。
  • [C-1-7] 必須偵測並對應至以下項目的按鍵碼 麥克風與地面電導體之間的衝擊範圍 ：
    • 110-180 ohm： KEYCODE_VOICE_ASSIST
  • [C-SR-2] 強烈建議你透過 OMTP 支援音訊插頭
  • [C-SR-3] 強烈建議你支援立體聲音訊錄音 配備麥克風的耳機。

如果裝置實作可提供 4 指導管 3.5 公釐耳機插孔，並支援 並透過麥克風廣播android.intent.action.HEADSET_PLUG 將麥克風設為 1，那麼麥克風會：

  • [C-2-1] 必須能偵測插在插入音訊的麥克風 。
7.8.2.2。數位音訊連接埠

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

7.8.3.近乎超音波

近乎超音波音訊為 18.5 kHz 至 20 kHz 錶帶。

裝置實作方式：

如果PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 為「true」，代表 「VOICE_RECOGNITION」和「UNPROCESSED」音訊來源：

  • [C-1-1] 在 18.5 kHz 至 20 kHz 頻帶中，麥克風的平均功率回應 以 2 kHz 而言，回應率不得超過 15 dB。
  • [C-1-2] 麥克風的未加權訊號與噪音比，比率超過 18.5 kHz 至 20 kHz 在 -26 dBFS 下，19 kHz 的語氣不得低於 50 dB。

如果PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

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

7.8.4。信號完整性

裝置實作方式：

  • 應提供無故障的音訊訊號路徑， 並根據零故障的定義，將手持裝置上的資料輸出串流 會在每個路徑一分鐘的測試內進行測量 使用 OboeTester 進行測試 「Automatic Glitch Test」

測試需要音訊回送連接器。 。 所有音訊輸出連接埠都必須測試。

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

效能模式 分享 取樣率 英屬香腸 逃離袖
低延遲 專屬 未指定 1 2
低延遲 專屬 未指定 2 1
低延遲 已分享的影片 未指定 1 2
低延遲 已分享的影片 未指定 2 1
無 已分享的影片 48000 1 2
無 已分享的影片 48000 2 1
無 已分享的影片 44100 1 2
無 已分享的影片 44100 2 1
無 已分享的影片 16000 1 2
無 已分享的影片 16000 2 1

可靠的直播內容「必須」符合下列條件，才能收到「雜訊」訊號 適用於 2000 Hz 的 2000 Hz 同質量 (SNR) 和總諧變形 (THD)。

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

7.9.虛擬實境

Android 提供用於建構「虛擬實境」的 API 和設施(虛擬實境) 包括優質的行動 VR 體驗。裝置 實作「必須」正確實作這些 API 和行為 可參閱本節內容

7.9.1。虛擬實境模式

Android 支援 VR 模式， 處理通知的立體視覺呈現並停用 單項系統 UI 元件，而 VR 應用程式則是使用者焦點。

7.9.2。虛擬實境模式 - 高效能

如果裝置實作支援虛擬實境模式，請按照下列步驟操作：

  • [C-1-1] 至少必須有 2 個實體核心。
  • [C-1-2] 必須宣告 android.hardware.vr.high_performance 功能。
  • [C-1-3] 必須支援持續效能模式。
  • [C-1-4] 必須支援 OpenGL ES 3.2。
  • [C-1-5] 必須支援 android.hardware.vulkan.level 0。
  • 應支援 android.hardware.vulkan.level 1 以上版本。
  • [C-1-6] 必須導入 EGL_KHR_mutable_render_buffer、 EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync、 EGL_KHR_wait_sync、 EGL_IMG_context_priority、 EGL_EXT_protected_content、 EGL_EXT_image_gl_colorspace、 並在可用的 EGL 擴充功能清單中顯示擴充功能。
  • [C-1-8] 必須導入 GL_EXT_multisampled_render_to_texture2、 GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures、 並在可用的 GL 擴充功能清單中顯示擴充功能。
  • [C-SR-1] 極力推薦導入 GL_EXT_external_buffer、 GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, 並在可用的 GL 擴充功能清單中顯示擴充功能。
  • [C-SR-2] 極力推薦支援 Vulkan 1.1。
  • [C-SR-3] 極力推薦導入 VK_ANDROID_external_memory_android_hardware_buffer、 VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, 並顯示在可用的 Vulkan 擴充功能清單中。
  • [C-SR-4] 強烈建議至少公開一個 Vulkan 佇列系列，其中 flags 包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT 且 queueCount 至少為 2。
  • [C-1-7] GPU 和螢幕「必須」可以同步處理共用存取權 前端緩衝區，讓交錯顯示 VR 內容 (每秒 60 個影格) 和兩秒 會呈現一個算繪背景，但不會呈現明顯的茶格瑕疵。
  • [C-1-9] 必須導入 AHardwareBuffer 支援功能 旗標 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、 AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 如 NDK 中所述。
  • [C-1-10] 必須針對 AHardwareBuffer 的 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 至少為下列格式： AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
  • [C-SR-5] 強烈建議支援 AHardwareBuffers 分配 C-1-10 中指定了多個圖層和旗標與格式
  • [C-1-11] 必須支援 H.264 解碼器，解析度至少為 3840 x 2160 (30fps)， 壓縮到 40 Mbps 的平均值 (相當於 1920 x1080 (30 fps-10 Mbps) 或 2 個執行個體 (1920 x 1080，每秒 60 fps-20 Mbps)。
  • [C-1-12] 必須支援 HEVC 和 VP9，且至少要具備解碼能力 1920 x 1080 (每秒 30 個影格) 壓縮到平均 10 Mbps，且應 能夠解碼 3840 x 2160，速度為 30 fps-20 Mbps (相當於 4 個 1920 x 1080 執行個體，每秒 30 fps-5 Mbps)。
  • [C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API 然後傳回準確的皮膚溫度值
  • [C-1-14] 必須具有內嵌畫面，且解析度至少需 1920 x 1080。
  • [C-SR-6] 強烈建議採用至少 2560 x 1440。
  • [C-1-15] 處於 VR 模式時，螢幕至少要更新 60 Hz。
  • [C-1-17] 螢幕「必須」支援低持久模式 (不超過 5 毫秒) 持續性，持續定義為 就是一個像素發光的
  • [C-1-18] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能 第 7.4.3 節。
  • [C-1-19] 必須提供支援並妥善回報 直接管道類型 下列所有預設感應器類型：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] 強烈建議你 TYPE_HARDWARE_BUFFER敬上 上述所有直接管道類型的直接管道類型。
  • [C-1-21] 必須符合陀螺儀、加速計和磁力儀相關 android.hardware.hifi_sensors 的相關規定，如 第 7.3.9 節。
  • [C-SR-8] 強烈建議你 android.hardware.sensor.hifi_sensors 功能。
  • [C-1-22] 端對端動作必須高於光子延遲時間 28 毫秒。
  • [C-SR-9] 強烈建議使用端對端動態到光影延遲 不超過 20 毫秒
  • [C-1-23] 請務必設定第一個畫面比例，也就是介於 從黑色轉變為黑畫面後的第一個影格像素亮度 白色像素以及白色像素在穩定狀態下的亮度，至少為 85%。
  • [C-SR-10] 強烈建議將第一個影格比例至少設為 90%。
  • 可以為前景提供專屬核心 應用程式，且可能支援 Process.getExclusiveCores API 傳回 頂層前景專屬的 CPU 核心數量 應用程式。

如果支援專屬核心，則使用核心：

  • [C-2-1] 不得允許其他的使用者空間處理程序執行 (但應用程式使用的裝置驅動程式除外)，但「MAY」允許一些核心 視需要執行其他程序

7.10。觸覺回饋

用於手持或佩戴的裝置可能包含一般用途觸覺回饋 這項工具可用於應用程式 透過鈴聲、鬧鐘和通知，以及一般觸覺回饋。

如果裝置的實作「不包含」這類一般用途的觸覺回饋器， 他們會：

  • [7.10/C] 必須為 Vibrator.hasVibrator() 傳回 false。

如果裝置的實作方式至少應提供一種一般用途觸覺回饋 執行者的工作：

如果裝置實作方式遵循觸覺常數對應，就會：

7.11。媒體成效類別

可取得裝置實作的媒體效能類別 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API。需求條件 針對每個 Android 版本，從 R (30 版)。特殊值為 0 時，表示裝置並非 媒體成效類別

如果裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS，他們：

  • [C-1-1] 傳回的值至少須為 android.os.Build.VERSION_CODES.R。

  • [C-1-2] 必須實作手持裝置。

  • [C-1-3] 必須符合「媒體成效等級」的所有規定描述 第 2.2.7 節。

換句話說，Android T 中的媒體效能類別只有在 版本 T、S 或 R 的手持裝置。

請參閱第 2.2.7 節，瞭解裝置適用的方式 Google Cloud 就是最佳選擇

8. 效能與功率

某些最低效能和電源標準對使用者體驗至關重要 並影響開發人員在開發機器學習模型時 應用程式。

8.1.使用者體驗一致性

我們為使用者提供流暢的使用者介面 確保一致性的影格速率和回應時間 應用程式和遊戲根據裝置類型導入裝置 「或許」對使用者介面延遲和工作有可量化的要求 如果換機操作，請依照第 2 節所述的方式切換。

8.2.檔案 I/O 存取效能

為 應用程式私人資料儲存空間 (/data 分區) 可讓應用程式開發人員 訂出合適的軟體設計方向。裝置 視裝置類型而定，廣告導入方式可能有些許需求 詳見第 2 節中的以下內容 以及寫入作業

  • 依序寫入效能。測量方法是使用以下程式碼寫入 256 MB 檔案： 10 MB 寫入緩衝區。
  • 隨機寫入效能。使用 4 KB 寫入 256 MB 檔案來評估結果 寫入緩衝區。
  • 依序讀取效能。使用以下安全工具讀取 256 MB 檔案 10 MB 寫入緩衝區。
  • 隨機讀取效能。藉由讀取使用 4 KB 的 256 MB 檔案來評估值 寫入緩衝區。

8.3.省電模式

如果實作的裝置包含改善裝置電源管理機制的功能 並加入 Android 開放原始碼計畫 (例如應用程式待命值區、打盹) 中或擴充功能 為套用比 RESTRICTED 應用程式待命值區更嚴格的限制，包括：

  • [C-1-1] 觸發事件時，不得偏離 Android 開放原始碼計畫的實作項目， 以及使用全域系統設定或 裝置設定 分別是「應用程式待命」和「打盹省電模式」
  • [C-1-2] 「不得」偏離 Android 開放原始碼計畫實作項目，以便使用全域 或 DeviceConfig 管理工作、鬧鐘和 為每個值區中的應用程式建立網路待命。
  • [C-1-3] 應用程式待命值區 。
  • [C-1-4] 必須實作應用程式待命值區 並按照「電源管理」一節中所述的方法輕觸「打盹」。
  • [C-1-5] 必須傳回 true PowerManager.isPowerSaveMode() 裝置開啟省電模式時。
  • [C-1-6] 必須為使用者提供授權，才能顯示豁免的應用程式 使用應用程式待命和打盹省電模式，或任何電池效能最佳化設定 且務必導入 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 意圖要求使用者允許應用程式忽略電池 以及最佳化調整
  • [C-SR-1] 強烈建議提供使用者負擔以實現 停用省電模式功能。
  • [C-SR-2] 強烈建議使用者提供足夠空間來顯示所有 不受應用程式待命和打盹省電模式限制的應用程式。

如果採用的裝置會擴充隨附的電源管理功能， ，且該擴充功能適用的限制比 請參閱第 3.5.1 節。

除了省電模式外，Android 裝置實作方式可能為 MAY 執行「進階」定義的 4 種睡眠電源狀態 (完全或全部) 設定和電源介面 (ACPI)。

如果裝置實作方式實作 他們可以採取以下做法：

  • [C-1-1] 只有在使用者採取明確行動後，才能輸入這個狀態 讓裝置進入閒置狀態 (例如蓋上機蓋時， 裝置或汽車/電視)，然後 使用者重新啟用裝置 (例如打開機蓋或轉動車輛) 或電視再次播放)。

如果裝置實作方式實作 他們可以採取以下做法：

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

    相反地，當第三方應用程式需要 系統資源

    舉例來說，第三方應用程式要求保持畫面 直到 FLAG_KEEP_SCREEN_ON 為止，或是確保 CPU 持續運作 PARTIAL_WAKE_LOCK，除非如上所述，裝置「不得」進入 S3 狀態 在 C-1-1 的版本中，使用者已採取明確行動，將裝置放在 停用狀態相反地，第三方應用程式的工作 必須透過 JobScheduler 或 Firebase 雲端通訊 否則裝置「必須」退出 S3 狀態，除非 使用者將裝置設為閒置狀態。包括但不限於： 相關範例和 Android 開放原始碼計畫實作了大量會觸發喚醒功能的喚醒信號 。

8.4.耗電量會計

更準確計算耗電量和耗電量 應用程式開發人員提供了獎勵和工具來最佳化電力使用的工具 應用程式的模式

裝置實作方式：

  • [C-SR-1] 強烈建議提供個別組件的電源設定檔 定義目前消耗值 ，以及測試過程中 。
  • [C-SR-2] 強烈建議以公釐為單位所有耗電量值 小時 (mAh)。
  • [C-SR-3] 強烈建議你針對每個程序的 UID 回報 CPU 耗電量。 Android 開放原始碼計畫通過了 uid_cputime 核心模組實作。
  • [C-SR-4] 強烈建議你透過 adb shell dumpsys batterystats敬上 殼層指令給應用程式開發人員。
  • 無法歸因於硬體元件 最終歸功於應用程式

8.5.一致的效能

針對高效能長時間執行的應用程式，效能可能大幅波動。 原因可能是其他應用程式在背景執行，或 CPU 節流 。Android 包含程式輔助介面 則頂層前景應用程式可以要求 系統會最佳化資源分配方式，以因應這類波動。

裝置實作方式：

如果裝置導入資料回報支援持續性效能模式，則表示：

  • [C-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 平台的安全性模型 (如 安全性和權限參考文件 。

  • [C-0-2] 必須支援自行簽署的安裝作業 而且不必取得 第三方/授權者。

如果裝置導入方式宣告 android.hardware.security.model.compatible 那麼他們會：

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

9.1.權限

裝置實作方式：

  • [C-0-1] 必須支援 Android 權限模型和 Android 角色模型 (定義於 Android 開發人員說明文件中所列)。具體來說 必須強制執行以下項目中定義的各項權限和角色： SDK 說明文件；也不可以使用任何角色 或被忽略。

  • 可新增其他權限，提供新的權限 ID 字串 不在 android.\* 命名空間中

  • [C-0-2] protectionLevel 的 PROTECTION_FLAG_PRIVILEGED 權限 只能授予預先安裝在 系統映像檔 APEX 檔案)，並且 。 Android 開放原始碼計畫實作方式符合這項規定，方法是參閱 許可清單中的檔案列出各個應用程式已加入許可清單的權限 etc/permissions/ 路徑並使用 system/priv-app 路徑做為 特殊權限路徑

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-SR-1] protectionLevel 的 PROTECTION_SIGNATURE 權限 極力建議您只授予以下其中一種角色：

    • 預先安裝在系統映像檔上的應用程式 (以及 APEX 檔案)。
    • 獲得許可權限的應用程式未包含在許可清單中的應用程式 系統映像檔
    ，瞭解如何調查及移除這項存取權。

終止新規定

防護等級為危險的權限即為執行階段權限。 具有「targetSdkVersion」的應用程式 >22 在執行階段提出請求

裝置實作方式：

  • [C-0-3] 必須顯示專屬的介面，供使用者決定 是否要授予要求的執行階段權限 可讓使用者管理執行階段權限的介面。

  • [C-0-5] 不得向應用程式授予任何執行階段權限，除非：

    • 這些項目會在裝置出貨時安裝。「且」

    • 可以在應用程式前取得使用者的同意聲明 運用權限

      或

    • 已授予執行階段權限 依據預設權限授權政策 或持有平台角色時

  • [C-0-6] 必須授予 android.permission.RECOVER_KEYSTORE 權限 僅適用於註冊適當安全復原代理程式的系統應用程式。A 罩杯 正確安全復原代理程式的定義為裝置端軟體代理程式 能與裝置外的遠端儲存空間同步 提供防護等級等於或超越現有硬體的安全硬體 描述 Google Cloud Key Vault 服務 以防範暴力攻擊對螢幕知識因素構成的暴力攻擊

裝置實作方式：

  • [C-0-7] 應用程式必須遵循 Android 位置存取權屬性 透過標準 Android API 要求位置資訊或體能活動資料 或專屬機制這類資料包括但不限於：

    • 根據上方說明所述的裝置所在位置 (例如經緯度) 第 9.8.8 節。
    • 可用於判斷或預估裝置的 位置 (例如 SSID、BSSID、基地台 ID 或網路的位置) 裝置連線時)。
    • 使用者的體能活動或體能活動分類。

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

  • [C-0-8] 必須取得使用者同意，應用程式才能存取 位置或體能活動資料。
  • [C-0-9] 「只能」授予執行階段權限給持有 足夠的權限。 例如： TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION)。

上述 Android 位置存取權屬性的唯一例外： 應用程式未存取位置資訊以取得或識別使用者的位置；特別是：

  • 應用程式擁有 RADIO_SCAN_WITHOUT_LOCATION 權限時。
  • 在裝置設定和設定中，系統應用程式會保留 NETWORK_SETTINGS 或 NETWORK_SETUP_WIZARD 權限。

權限可標示為受限制改變其行為。

  • [C-0-10] 標有 hardRestricted 標記的權限「不得」 授予應用程式的權限，除非：

    • 應用程式 APK 檔案位於系統分區中。
    • 使用者指派的角色與 hardRestricted 相關聯 授予應用程式權限
    • 安裝程式將 hardRestricted 授予應用程式。
    • 應用程式獲得舊版 Android 的 hardRestricted。

  • [C-0-11] 擁有 softRestricted 權限的應用程式只能受到限制 而且除非依照 SDK，其中每個 softRestricted 定義了完整與有限的存取權 權限 (例如 READ_EXTERNAL_STORAGE)。

  • [C-0-12] 不得提供任何自訂函式或 API 來略過 setPermissionPolicy 中定義的權限限制 和 setPermissionGrantState 相互整合

  • [C-0-13] 「必須」使用 AppOpsManager API 記錄及追蹤 能夠以程式輔助的方式存取受危險權限保護的資料 Android 活動與服務。

  • [C-0-14] 請務必只指派角色給具備下列功能的應用程式： 滿足職務要求

  • [C-0-15] 請勿定義重複或超集合功能的角色 代表平台定義的角色

如果裝置回報android.software.managed_users，他們會：

  • [C-1-1] 不得 管理員：
    • 位置 (ACCESS_BACKGROUND_LOCATION，ACCESS_COARSE_LOCATION)， ACCESS_FINE_LOCATION)。
    • 相機 (CAMERA)
    • 麥克風 (RECORD_AUDIO)
    • 人體感測器 (BODY_SENSORS)
    • 體能活動 (ACTIVITY_RECOGNITION)

如果裝置實作項目能讓使用者自由選擇 有一個活動可以處理 ACTION_MANAGE_OVERLAY_PERMISSION敬上 目的：

  • [C-2-1] 必須確保具有意圖篩選器的所有活動 ACTION_MANAGE_OVERLAY_PERMISSION敬上 意圖都具有相同的 UI 畫面，無論啟動的應用程式或任何 這些資訊

如果裝置實作回報 android.software.device_admin，就會：

  • [C-3-1] 必須在全代管裝置設定中顯示免責事項 (裝置擁有者設定) 指出 IT 管理員可執行下列操作： 允許應用程式控製手機上的設定，包括麥克風、相機和 以及讓使用者繼續設定或離開設定的選項，除非有 管理員已選擇不控制裝置的權限。

如果裝置實作項目預先安裝任何包含 System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence 或 System Visual Intelligence 角色的套件，則包含以下套件：

  • [C-4-1] 必須完全符合 第 9.8.6 節：作業系統層級和環境資料，以及 9.8.15 沙箱模式 API 實作。」

如果裝置實作項目包含支援 VoiceInteractionService他們：

  • [C-5-1] 「不得」將 ACCESS_FINE_LOCATION 設為預設授權 應用程式。

9.2.UID 與程序隔離

裝置實作方式：

  • [C-0-1] 必須支援 Android 應用程式 沙箱模型，每個應用程式會以專屬 Unixstyle UID 執行 然後以獨立的程序處理
  • [C-0-2] 必須支援執行多個應用程式 相同的 Linux 使用者 ID (前提是應用程式必須正確簽署 建構與建構元件 安全性和權限參考資料。

9.3.檔案系統權限

裝置實作方式：

9.4.替代執行環境

實作裝置必須維持 Android 的安全性和一致性 權限模型，即使其中包含 應用程式使用 Dalvik Executable 以外的其他軟體或技術 格式或原生程式碼。也就是說：

  • [C-0-1] 替代執行階段本身「必須」是 Android 應用程式 並遵循其他平台的標準 Android 安全性模型 第 9 節。

  • [C-0-2] 不得將資源存取權授予替代執行階段 受到執行階段 AndroidManifest.xml 中未要求權限保護 透過 <uses-permission>以注意力機制為基礎

  • [C-0-3] 替代執行階段「不得」允許應用程式利用 功能受到 Android 權限保護。

  • [C-0-4] 替代執行階段必須符合 Android 沙箱模型 以及透過替代執行階段安裝的應用程式 可重複使用裝置上安裝的任何其他應用程式沙箱，但 共用使用者 ID 和簽署憑證的標準 Android 機制。

  • [C-0-5] 其他執行階段「不得」透過允許、授權或取得方式啟動 存取與其他 Android 應用程式對應的沙箱。

  • [C-0-6] 不得透過啟動、授予或授權的方式啟動替代執行階段 授予超級使用者 (根使用者) 或任何其他應用程式的權限 使用者 ID

  • [C-0-7] 當網頁中含有替代執行階段的 .apk 檔案時 裝置實作的系統映像檔，「必須」使用專屬的金鑰簽署 從用於簽署裝置中其他應用程式的金鑰 。

  • [C-0-8] 安裝應用程式時，「必須」取得替代執行階段 針對應用程式使用的 Android 權限徵得使用者同意。

  • [C-0-9] 應用程式需要使用裝置資源時 必須具備相應的 Android 權限 (例如相機、GPS 等)， 替代執行階段「必須」告知使用者應用程式能夠 取得該項資源的存取權

  • [C-0-10] 執行階段環境未記錄應用程式的情形 執行階段環境「必須」列出所有權限 由執行階段自行保留。

  • 替代執行階段應透過 PackageManager 安裝應用程式 獨立的 Android 沙箱 (Linux 使用者 ID 等)。

  • 替代執行階段可以提供所有人共用的單一 Android 沙箱 使用替代執行階段應用程式

9.5.多使用者支援

Android 裝置支援多位使用者 支援完全區隔使用者，以及複製使用者個人資料 部分隔離(例如單一使用者其他類型的使用者設定檔) android.os.usertype.profile.CLONE)。

  • 可導入裝置，但對於多人使用，則不應啟用多使用者 卸除式媒體 主要外部儲存空間容量

如果裝置的實作支援多位使用者：

  • [C-1-2] 必須為每個使用者導入安全措施 符合 Android 平台的安全性模型 安全性和權限參考文件 解讀方式。
  • [C-1-3] 必須具有獨立的獨立共用應用程式儲存空間 (又稱為 /sdcard) 目錄。
  • [C-1-4] 必須確保由 特定使用者無法列出、讀取或寫入其他使用者擁有的檔案， 即使兩位使用者的資料都儲存在相同的磁碟區或檔案系統中。
  • [C-1-5] 啟用多使用者功能時，務必將 SD 卡的內容加密 使用的金鑰只儲存在非卸除式媒體上，且只有在系統可存取 裝置的實作方式會為外部儲存空間 API 使用卸除式媒體。 因為這會讓主機電腦無法讀取媒體，實作裝置 必須改用 MTP 或類似系統，以提供主機電腦 存取目前使用者資料。

如果裝置實作項目支援多位使用者 除了專為執行雙執行個體作業建立的使用者以外 但在同一個應用程式中，他們會：

  • [C-2-1] 必須具有獨立的獨立共用應用程式儲存空間 (又稱為 /sdcard) 目錄，
  • [C-2-2] 必須確保在 特定使用者無法列出、讀取或寫入擁有的檔案 任何使用者存取的資料，即使兩位使用者的資料儲存在相同的 磁碟區和檔案系統

導入裝置時，可以建立單一類型的額外使用者設定檔 對主要使用者執行 android.os.usertype.profile.CLONE (僅限 主要使用者)，藉此執行同一個應用程式的兩個執行個體。 這些雙執行個體會共用部分獨立儲存空間 使用者同時顯示在啟動器中的「最近」檢視畫面中。 例如，此應用程式可用於支援使用者安裝 單一應用程式的執行個體

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

  • [C-3-1] 「必須」只提供儲存空間或已存 可供上層使用者個人資料存取，或直接由此 其他使用者設定檔。
  • [C-3-2] 「不得」以工作資料夾做為工作資料夾。
  • [C-3-3] 必須區隔來自父項的私人應用程式資料目錄 使用者帳戶。
  • [C-3-4] 「不得」允許建立額外的使用者設定檔 (如有) 為「裝置擁有者」佈建 (請參閱第 3.9.1 節)，或允許「裝置擁有者」 而不需要先移除額外的使用者設定檔

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

9.6.付費簡訊警告

Android 支援針對任何傳出的使用者發出警告 付費簡訊。付費簡訊 訊息是傳送給向電信業者註冊的服務，且 向使用者收取的費用

如果裝置實作結果宣告支援 android.hardware.telephony， 他們會：

  • [C-1-1] 必須先警告使用者，才能傳送簡訊到電話號碼 以 /data/misc/sms/codes.xml 中定義的規則運算式表示 檔案。上游 Android 開放原始碼計畫 符合這項規定的導入方法

9.7.資安防護機制

裝置實作「必須」確保同時符合 如下所述。

Android Sandbox 中有使用安全增強式 Linux 的功能 (SELinux) 強制性存取控制 (MAC) 系統、seccomp 沙箱及其他 安全功能裝置實作方式：

  • [C-0-1] 必須維持與現有應用程式的相容性 SELinux 或任何其他安全性功能已實作於 Android 之下 這個架構的重點在於
  • [C-0-2] 發生安全措施時，「不得」顯示使用者介面 就會透過安全防護功能成功加以封鎖 導入在 Android 架構底下，但「可能」有清楚可見的使用者介面 發生以安全為違規而遭解除封鎖的威脅，導致漏洞遭人成功利用時。
  • [C-0-3] 不得實作 SELinux 或任何其他已實作的安全性功能 下方可供使用者或應用程式開發人員設定的 Android 架構。
  • [C-0-4] 不得允許影響其他應用程式的應用程式 透過 Device 管理 API 等 API 就會破壞相容性
  • [C-0-5] 必須將媒體架構分成多個程序， 可集中授予每個程序的存取權 描述 瞭解相關詳細資訊
  • [C-0-6] 必須實作核心應用程式沙箱機制 啟用時，可使用以下 設定的可設定政策，篩選系統呼叫 多執行緒程式上游 Android 開放原始碼計畫 要求以 Threadgroup 啟用 seccomp-BPF 並按照說明 找到「核心設定」部分。

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

  • [C-0-7] 必須實作核心堆疊緩衝區溢位保護機制。 這類機制的例子包括 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
  • [C-0-8] 在可執行檔的位置，必須採用嚴格的核心記憶體保護措施 此為唯讀資料，唯讀資料無法執行或無法寫入。 可寫入資料為不可執行檔 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
  • [C-0-9] 必須導入靜態和動態物件大小 使用者空間與核心空間之間副本的邊界檢查 (例如 CONFIG_HARDENED_USERCOPY) 僅限以 API 級別出貨的裝置購買 28 以上版本。
  • [C-0-10] 執行時「不得」執行使用者空間記憶體 處於核心模式 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN) 原始運送服務的格式為 API 級別 28 以上。
  • [C-0-11] 不得讀取或寫入 一般使用者副本存取 API 以外的核心 (例如硬體 PAN 或 透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 。
  • [C-0-12] 如果硬體 在最初以 API 級別運送的所有裝置上，安全漏洞其 CVE-2017-5754 的安全漏洞 28 以上版本 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0)。

  • [C-0-13] 如果硬體 在最初以 API 級別運送的所有裝置上，安全漏洞其 CVE-2017-5715 的安全漏洞 28 以上版本 (例如 CONFIG_HARDEN_BRANCH_PREDICTOR)。

  • [C-SR-1] 強烈建議保留核心資料 這個方法只會在初始化期間寫入，之後才會標示為唯讀 (例如 __ro_after_init)。

  • [C-SR-2] 強烈建議 避免暴露在 (例如：CONFIG_RANDOMIZE_BASE 具有系統啟動載入程式熵) /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL)。

  • [C-SR-3] 強烈建議你在以下機構單位中啟用控制流程完整性 (CFI) 機制 這項核心功能，針對重複使用程式碼的攻擊提供額外防護 (例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK)。

  • [C-SR-4] 強烈建議不要停用控制流程完整性 (CFI)； 開啟陰影呼叫堆疊 (SCS) 或整數溢位清理 (IntSan) 所有具備該功能的應用程式

  • [C-SR-5] 極力建議您為所有的產品啟用 CFI、SCS 和 IntSan 安全敏感的使用者空間元件，詳情請參閱 CFI 和 IntSan。

  • [C-SR-6] 強烈建議在核心中啟用堆疊初始化 防止使用未初始化的本機變數 (CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO)。 此外，在裝置上執行裝置時，不應假設編譯器使用的值 初始化 Local。

  • [C-SR-7] 強烈建議在核心中啟用堆積初始化功能 避免使用未初始化的堆積分配量 (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)，而且不應假設 來初始化這些配置。

如果裝置實作項目採用支援這項功能的 Linux 核心 SELinux，他們可以：

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

如果裝置實作採用的是 Linux 或 Linux 以外的核心 (在沒有 SELinux 的情況下)， 他們會：

  • [C-2-1] 必須使用 等於 SELinux

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

  • [C-SR-9] 強烈建議每個 I/O 裝置隔離符合《數位市場法》規定、 使用 IOMMU (例如 ARM SMMU)。

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

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

  • [C-SR-10] 強烈建議使用使用者空間記憶體錯誤進行測試 ARMv9 裝置的 MTE、HWASan (適用於 ARMv8 以上版本裝置) 或 ASan 適合其他裝置類型使用
  • [C-SR-11] 強烈建議使用核心記憶體錯誤進行測試 ，例如 KASAN (CONFIG_KASAN，CONFIG_KASAN_HW_TAGS ARMv9 裝置，CONFIG_KASAN_SW_TAGS (適用於 ARMv8 裝置) 或 CONFIG_KASAN_GENERIC 廣告。
  • [C-SR-12] 強烈建議在 例如 MTE、GWP-ASan 和 KFENCE

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

  • [C-SR-13] 強烈建議使用記憶體標準通訊協定 Android 和 TEE 之間分享的資料，例如 Arm 韌體架構 Armv8-A (FF-A)。
  • [C-SR-14] 強烈建議將信任的應用程式設為 存取已透過上述指令明確與他們共用的記憶體 因此效能相當卓越如果裝置支援 Arm S-EL2 例外狀況等級， ，應由安全分區管理員強制執行。否則，您應該 執行 TEE OS 強制執行的指令

記憶體安全技術是一種至少 在使用 android:memtagMode敬上 資訊清單選項：

  • 堆積緩衝區溢位
  • 釋放後使用
  • 雙釋放
  • 狂野自由 (不含非 M-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] 強烈建議你提供 然後重新啟動裝置。只要使用相容的系統啟動載入程式， Android 開放原始碼計畫會透過 MTE 系統啟動載入程式通訊協定。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置宣告 android.hardware.telephony，則支援無線電 功能 CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK 包括支援 2G 連線的行動數據機、 實作：

，瞭解如何調查及移除這項存取權。

終止新規定

9.8.隱私權

9.8.1。使用記錄

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

裝置實作方式：

  • [C-0-1] 請務必為這類使用者記錄保留合理的保留期限。
  • [C-SR-1] 極力建議將 14 天的保留期限維持在 預設的設定。

Android 使用 StatsLog 儲存系統事件 識別碼，並透過 StatsManager 和 IncidentManager System API。

裝置實作方式：

  • [C-0-2] 「必須」只包含以 DEST_AUTOMATIC 標示的欄位 事件報告 (由系統 API 類別 IncidentManager 建立)。
  • [C-0-3] 不得使用系統事件 ID 記錄任何其他事件 與 StatsLog 中描述的內容不同 SDK 文件。如有記錄其他系統事件，它們可能會使用 介於 100,000 至 200,000 之間

9.8.2。錄製中

裝置實作方式：

  • [C-0-1] 「不得」直接預先載入或發布 傳送使用者的私人資訊 (例如按鍵動作、 裝置螢幕、錯誤報告)、未經使用者同意或清除裝置 持續性通知。

  • [C-0-2] 必須顯示使用者警告，並徵得使用者明確同意 允許使用者查看畫面上顯示的任何機密資訊 都會擷取至每次要擷取的工作階段 透過 MediaProjection.createVirtualDisplay()、 VirtualDeviceManager.createVirtualDisplay(), 專屬 API

  • [C-0-3] 投放畫面時，「必須」持續通知使用者 或螢幕錄影功能已啟用Android 開放原始碼計畫能夠顯示 狀態列中的持續性通知圖示。

  • [C-SR-1] 強烈建議顯示與使用者警告的確切內容 與 Android 開放原始碼計畫實作的訊息相同，但只要 訊息中明確警告使用者， 擷取螢幕畫面。

  • [C-0-4] 「不得」為使用者提供停用該功能的提示 使用者必須同意擷取螢幕畫面，但如果工作階段是由 使用者允許 associate()敬上 使用 android.app.role.COMPANION_DEVICE_APP_STREAMING。 或 android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING 裝置上的設定檔。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

裝置實作方式：

  • [C-0-7] 「不得」記錄、投影或投放機密資訊，例如：

終止新規定

如果裝置實作項目中包含下列 擷取畫面上顯示的內容及/或錄製音訊串流 透過系統 API ContentCaptureService 以外的裝置在裝置上執行；或 第 9.8.6 節的 OS 層級和微光資料：

  • [C-1-1] 每當這種情況發生 功能是否已啟用，且正在主動擷取/錄製。

如果裝置實作項目包含可立即啟用的元件， 錄製環境音訊和/或錄製裝置播放的音訊 能推斷出有關使用者情境的實用資訊

  • [C-2-1] 「不得」存放永久的裝置儲存空間或傳輸到 裝置錄製的原始音訊或任何可轉換的格式 原始音訊或近似的傳真，除非使用者明確同意。

「麥克風指標」指的是螢幕上持續可見的 且不能經過遮蔽，導致使用者理解其麥克風處於 使用(透過不重複文字、顏色、圖示或組合的方式)。

「相機指標」指的是使用者螢幕上的一個畫面 因為相機正在使用中，使用者無法理解其內容，因此不能予以遮蓋。 (透過不重複的文字、顏色、圖示或某些組合)。

顯示前一秒後，指標可能會改變，例如 而且不需要和原始圖片一樣顯示 瞭解

麥克風指標可能會與主動顯示的相機合併 指標，前提是文字、圖示或顏色 已開始使用麥克風。

攝影機指示可能會與主動顯示的麥克風合併 指標，前提是文字、圖示或顏色會在使用者 已開始。

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

  • [C-SR-1] 強烈建議在應用程式顯示麥克風指標時顯示麥克風指標 存取來自麥克風的音訊資料，而無法使用麥克風 僅供 HotwordDetectionService、SOURCE_HOTWORD 存取， ContentCaptureService，或擁有第一節提及的角色的應用程式 9.1 具有 CDD ID [C-3-X] 的權限。 。
  • [C-SR-2] 強烈建議你顯示近期和活躍清單 應用程式使用麥克風做為傳回的 PermissionManager.getIndicatorAppOpUsageData()，以及任何歸因方式 或是與 Gemini 相關的訊息
  • [C-SR-3] 強烈建議不要隱藏麥克風指示器 具有可見使用者介面或直接使用者互動的系統應用程式。

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

  • [C-SR-4] 強烈建議在應用程式 存取即時攝影機的資料，但無法存取攝影機時便無法存取 擁有第 9.1 節「具備 CDD 權限」所述角色的應用程式。 ID [C-3-X]。
  • [C-SR-5] 強烈建議使用 PermissionManager.getIndicatorAppOpUsageData() 所傳回的相機， 以及所有相關的歸因訊息
  • [C-SR-6] 強烈建議不要為系統隱藏相機指示器 具有可見使用者介面或直接使用者互動的應用程式。

9.8.3.連線能力

如果裝置實作項目具備支援 USB 週邊裝置模式的 USB 連接埠， 他們會：

  • [C-1-1] 必須事先顯示已徵得使用者同意的使用者介面 允許透過 USB 連接埠存取共用儲存裝置的內容。

9.8.4。網路流量

裝置實作方式：

  • [C-0-1] 必須預先安裝相同的系統信任的根憑證 依提供的憑證授權單位 (CA) 商店 。
  • [C-0-2] 出貨時，請務必提供空白的使用者根 CA 商店。
  • [C-0-3] 必須向使用者顯示警告，說明網路流量 使用者根憑證授權單位可能會受到監控。

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

  • [C-1-1] 必須向使用者顯示警告，指出以下事項：
    • 該網路流量可能會受到監控。
    • 也就是透過特定 VPN 轉送網路流量 用於提供 VPN 的應用程式

如果裝置導入方式設有機制，並預設為立即啟用。 透過 Proxy 伺服器或 VPN 閘道 (例如 預先載入 android.permission.CONTROL_VPN 的 VPN 服務)，兩者會：

  • [C-2-1] 必須先徵得使用者同意，才能啟用該機制。 除非裝置政策控制器透過 DevicePolicyManager.setAlwaysOnVpnPackage()、 在這種情況下，使用者不需另外提供同意聲明， 只需收到通知。

如果裝置實作項目可滿足使用者需求的設定，將 「永久連線 VPN」功能：

  • [C-3-1] 必須針對不支援的應用程式停用這項使用者權限 透過以下方式在 AndroidManifest.xml 檔案中設定永久連線 VPN 服務 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 屬性設為 false。

9.8.5。裝置 ID

裝置實作方式：

  • [C-0-1] 必須防止他人存取裝置序號及 適用、IMEI/MEID、SIM 卡序號和國際行動裝置 應用程式的訂閱者身分 (IMSI)，除非應用程式符合下列任一條件 規定：
    • 是已簽署的電信業者應用程式，經過裝置製造商驗證。
    • 已授予 READ_PRIVILEGED_PHONE_STATE 權限。
    • 具備 UICC 電信業者權限中定義的電信業者權限。
    • 是已授予 READ_PHONE_STATE權限。
    • (僅適用於 SIM 卡序號/ICCID) 符合當地法規 應用程式會偵測訂閱者身分的變化。

9.8.6。OS 層級和微光資料

Android 透過 System API 支援裝置機制 擷取下列機密資料的實作方式：

  • 顯示在螢幕上的文字和圖形，包括但不限於： 透過 AssistStructure 接收通知和輔助資料 也能使用 Google Cloud CLI 或 Compute Engine API
  • 裝置錄製或播放的媒體資料，例如音訊或影片。

  • 輸入事件，例如按鍵、滑鼠、手勢、語音、影片和無障礙工具。

  • 透過 AugmentedAutofillService 傳送到 有些人會將 Cloud Storage 視為檔案系統 但實際上不是

  • 任何螢幕或其他資料 Content Capture敬上 相互整合

  • 透過 AppSearchManager API 傳遞至系統的任何應用程式資料 且可透過 AppSearchGlobalManager.query 存取

  • 透過 TextClassifier API 傳送的任何文字或其他資料 傳送給系統 TextClassifier，亦即由系統服務告知 並根據分析結果 文字。

  • 透過平台 AppSearch 實作方式建立索引的資料，包含但不包括 資料、圖像、媒體資料或其他類似資料

  • 因使用 SpeechRecognizer#onDeviceSpeechRecognizer() (由語音辨識器產生) 導入。

  • 透過 AudioRecord 在背景 (持續) 取得的音訊資料， SoundTrigger 或其他音訊 API，但使用者無法看見 指標

  • 透過 CameraManager 或 但未產生使用者可見的指標

如果裝置的導入方式擷取上述任何資料，就會：

  • [C-1-1] 儲存在裝置中的所有這類資料都必須經過加密。這個 「可能性」是採用 Android 檔案加密機制 的加密套件 (如 Cipher SDK 所述) 為 API 26 以上版本。
  • [C-1-2] 「不得」使用 Android 備份方法或任何其他返回方法 向上擴充方法
  • [C-1-3] 「必須」只將這類資料傳送給 採用隱私權保護機制的裝置，但以下兩者除外： 且每次資料評估前必須取得使用者明確同意 共用。隱私權保護機制 屬於「它們只能進行匯總和防止 將記錄的事件或衍生結果與個別使用者進行比對 防止任何個別使用者資料遭到檢查 (例如使用 差異化隱私技術，例如 RAPPOR)。
  • [C-1-4] 「不得」將這類資料與任何使用者身分 (例如 以 Account 的身分) 但若資料儲存時就已取得使用者的明確同意，則不在此限。 連結。
  • [C-1-5] 「不得」將這類資料分享給其他不會這麼做的 OS 元件 遵循目前章節所列出的要求 (9.8.6 作業系統層級和環境資料)，但每隔多久就取得使用者明確同意 分享時長。除非具有 建立為 Android SDK API (AmbientContext、 HotwordDetectionService)。
  • [C-1-6] 「必須」為使用者提供充足的容量，才能清除這類資料 「專屬」或「專屬」是指在 資料會以任何形式儲存在裝置上。如果 使用者選擇清除資料，請「必須」移除所有已收集的歷來資料 資料。

  • [C-1-7] 必須為使用者提供意願選項，讓他們選擇拒絕收集資料 透過 AppSearch 或專屬方式避免自己的內容出現在 Android 平台上 (例如啟動器)。

  • [C-SR-1] 強烈建議「不要」要求 網際網路權限。

  • [C-SR-2] 強烈建議你只能透過網路存取網際網路 結構化 API

  • [C-SR-4] 極力建議使用 Android SDK API 或 類似的原始設備製造商 (OEM) 專屬開放原始碼存放區和 / 或 採用沙箱機制的實作方式 (請參閱 9.8.15 沙箱模式 API 實作)。

如果裝置實作項目包含實作 System API 的服務 ContentCaptureService、AppSearchManager.index 或任何專屬服務 擷取資料，就會：

  • [C-2-1] 不得允許使用者以 使用者可以安裝的應用程式或服務，且必須 以便擷取這類資料。
  • [C-2-2] 必須「不得」允許預先安裝服務以外的任何應用程式 以擷取這類資料
  • [C-2-3] 必須為使用者提供停用服務的額度。

  • [C-2-4] 管理 Android 權限時，不得省略使用者負擔 由服務保管，並依循 Android 的相關權限 如 第 9.1 節：權限。

  • [C-SR-3] 強烈建議將這些服務與其他服務區隔開來 系統元件 (例如不要繫結服務或共用程序 ID) 但以下例外：

    • 電話、聯絡人、系統 UI 和媒體

9.8.7。剪貼簿存取權

裝置實作方式：

  • [C-0-1] 「不得」傳回剪貼簿中的剪輯資料 (例如透過 ClipboardManager敬上 API)，除非第三方 應用程式是預設的輸入法編輯器，或者是目前聚焦的應用程式。

  • [C-0-2] 剪貼簿資料一旦超過 60 分鐘，「必須」清除。 或者從剪貼簿讀取。

9.8.8。位置

位置包含 Android 位置類別中的資訊( 例如 Latitude、 經度、高度)，以及可以轉換成 Location 的 ID。 位置可以精確為 DGPS (差異化全球定位系統)，或 概略的國家/地區層級位置 (例如國家/地區代碼位置 - 我的客戶中心 - 行動電話) 國家/地區代碼)。

以下是直接產生使用者的位置類型清單 也可以轉換成使用者的位置這並未涵蓋所有情況 清單，但應做為例子，當做位置資訊直接或 間接衍生自：

  • GPS/GNSS/DGPS/PPP
    • 全球定位解決方案、全球導航系統，或 差異化全球定位解決方案
    • 原始 GNSS 評估和 GNSS 狀態也包含在內
      • 精確位置可以從原始 GNSS 評估結果取得
  • 識別專屬 ID 的無線技術，例如：
    • Wi-Fi 存取點 (MAC、BSSID、名稱或 SSID)
    • 藍牙/BLE (MAC、BSSID、名稱或 SSID)
    • UWB (MAC、BSSID、名稱或 SSID)
    • 基地台 ID (3G、4G、5G...，包括日後所有推出的行動網路數據機) 有專屬 ID 的技術)

為提供資訊的主要參考資料，請參閱 ACCESS_FINE_Location 或 ACCESS_COARSE_位置權限。

裝置實作方式：

  • [C-0-1] 「不得」開啟/關閉裝置位置資訊設定和 Wi-Fi/藍牙 未經使用者同意或使用者明確啟動即掃描設定
  • [C-0-2] 必須為使用者提供要求存取權，才能存取相關的位置資訊 包括最近的位置資訊要求、應用程式層級權限和使用情形等資訊 ，以掃描 Wi-Fi/藍牙來確定位置。
  • [C-0-3] 必須確保應用程式使用 Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] 是使用者啟動的緊急事件 (例如：撥打 911 或傳送簡訊給 911)。但汽車可能 在未主動使用者互動的情況下啟動緊急工作階段 偵測到車禍/事故 (例如符合 eCall 規定)。
  • [C-0-4] 必須讓緊急位置略過 API 功能能夠： 略過裝置的位置資訊設定，而不變更設定。
  • [C-0-5] 必須排定在以下時間過後提醒使用者的通知： 但該應用程式在背景使用 「[ACCESS_BACKGROUND_LOCATION]」權限。

9.8.9。已安裝的應用程式

如果 Android 應用程式的目標 API 級別為 30 以上，就無法查看其他詳細資料 預設安裝的應用程式 (請參閱 Android 裝置的「套件瀏覽權限」一節) SDK 說明文件)。

裝置實作方式：

  • [C-0-1] 不得向任何目標 API 級別 30 以上的應用程式提供詳細資料 。除非應用程式能夠查看詳細資訊 其他已安裝應用程式的相關作業這包括 不限於裝置新增的任何自訂 API 所顯示的詳細資料 或透過檔案系統存取
  • [C-0-2] 不得授予任何應用程式、讀取或寫入任何其他檔案的權限 應用程式專屬目錄 外部儲存空間唯一的例外如下：
    • 外部儲存空間供應商授權 (例如 DocumentsUI 等應用程式)。
    • 使用「下載內容」的下載供應商提供者授權 將檔案下載到應用程式儲存空間
    • 平台簽署的媒體傳輸通訊協定 (MTP) 應用程式，採用 特殊權限 ACCESS_MTP，以便將檔案傳輸到 在其他裝置上播放。
    • 安裝其他應用程式並取得權限的應用程式 INSTALL_PACKAGES 只能存取「obb」方便您管理 APK 擴充檔案：

9.8.10。連線錯誤報告

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

  • [C-1-1] 必須支援透過以下方式產生連線錯誤報告： BUGREPORT_MODE_TELEPHONY 搭配 BugreportManager。
  • [C-1-2] 每次 BUGREPORT_MODE_TELEPHONY 時，都必須取得使用者同意聲明 用於產生報表，而且「不得」提示使用者同意所有 應用程式未來的要求
  • [C-1-3] 若無錯誤，「不得」將產生的報告傳回要求的應用程式 使用者明確表示同意
  • [C-1-4] 使用「BUGREPORT_MODE_TELEPHONY」產生的報表必須包含 至少提供下列資訊：
    • TelephonyDebugService 轉儲
    • TelephonyRegistry 轉儲
    • WifiService 轉儲
    • ConnectivityService 轉儲
    • 呼叫套件的 CarrierService 例項傾印 (如果已繫結)
    • 無線電記錄緩衝區
    • SubscriptionManagerService 轉儲
  • [C-1-5] 產生的報表中不得包含下列資訊：
    • 任何與連線能力無關的資訊 以及偵錯
    • 使用者安裝的任何類型應用程式流量記錄或詳細設定檔 使用者安裝的應用程式/套件 (可使用 UID，套件名稱 則不會)。
  • 可加入與任何使用者無關的額外資訊 識別個人身分(例如廠商記錄)。

如果裝置的實作方式在內容中加入其他資訊 (例如供應商記錄) 以及含有隱私/安全性/電池/儲存空間/記憶體 他們可以：

  • [C-SR-1] 強烈建議將開發人員設定預設為 已停用。只要提供 Enable verbose vendor logging，即可實作 Android 開放原始碼計畫參考資料 選項，納入其他裝置專屬的供應商記錄 回報的部分。

9.8.11。資料 blob 共用

Android (透過 BlobStoreManager) 讓應用程式提供資料 blob 至系統，進而與選定所選項目共用 應用程式組

如果裝置實作支援共用資料 blob，如 SDK 說明文件 他們會：

9.8.12。音樂辨識

Android 透過 System API MusicRecognitionManager 支援 要求音樂辨識、提供音訊錄音的裝置，以及 將音樂辨識委派給實作 MusicRecognitionService API。

如果裝置實作項目包含實作 System API 的服務 MusicRecognitionManager 或任何可串流播放音訊資料的專屬服務 功能：

  • [C-1-1] 必須強制 MusicRecognitionManager 的呼叫端持有 MANAGE_MUSIC_RECOGNITION的權限
  • [C-1-2] 必須強制使用預先安裝的單一音樂辨識 應用程式實作 MusicRecognitionService
  • [C-1-3] 不得允許使用者取代 MusicRecognitionManagerService 或透過可安裝的應用程式或服務 MusicRecognitionService
  • [C-1-4] 「必須」確保 MusicRecognitionManagerService 存取 錄音，並轉送至應用程式 MusicRecognitionService，透過 AppOpsManager.noteOp / startOp。

如果裝置實作 MusicRecognitionManagerService MusicRecognitionService 會儲存任何擷取的音訊資料，然後：

  • [C-2-1] 千萬「不得」在磁碟上儲存任何原始音訊或音訊指紋 還是在記憶體中超過 14 天
  • [C-2-2] 不得向 MusicRecognitionService 以外的對象分享這類資料，但 每次分享時都要經過使用者同意。

9.8.13。SensorPrivacyManager

如果裝置的實作方式能提供使用者關閉的軟體用途 相機和/或麥克風輸入裝置，兩者會：

  • [C-1-1] 必須正確傳回「true」建立相關 supportsSensorToggle() API 方法。
  • [C-1-2] 「必須」、當應用程式嘗試存取遭封鎖的麥克風或相機時， 向使用者提供無法關閉的使用者預設用途， 表示感應器已封鎖，因此必須選擇才能繼續 封鎖或解除封鎖 才能正常運作
  • [C-1-3] 只能將空白 (或假) 的相機和音訊資料傳遞給應用程式 且不會因為使用者未開啟相機而回報錯誤代碼 或根據上述 [C-1-2] 說明的資源配置存取麥克風。

9.8.14。無

9.8.15。採用沙箱機制的 API 實作

Android 透過一組委派 API 提供一種安全的處理機制 OS 層級和微光資料這類處理作業可委派給 具有特殊存取權限的 APK，通訊功能較少，稱為 採用沙箱機制的 API 實作。

任何採用沙箱機制的 API 實作：

  • [C-0-1] 不得要求 INTERNET。
  • [C-0-2] 「必須」只能透過符合下列條件的結構化 API 存取網際網路： 使用保護隱私權的公開開放原始碼實作方式 或透過 Android SDK API 間接使用。隱私權保護 這種機制的用途是 防止將記錄的事件或產生的結果與個別使用者進行比對", 防止任何個別使用者資料 (例如使用 採用其他差異化隱私技術，例如 RAPPOR)。
  • [C-0-3] 必須將服務與其他系統元件區隔開來 (例如，不得繫結服務或共用程序 ID)，唯 包括：
    • 電話、聯絡人、系統 UI 和媒體
  • [C-0-4] 不得允許使用者以 使用者可安裝的應用程式或服務
  • [C-0-5] 「必須」只允許預先安裝的服務擷取這類資料。 除非 Android 開放原始碼計畫已內建替代功能 (例如數位版 。
  • [C-0-6] 必須「不得」允許預先安裝服務以外的任何應用程式 以擷取這類資料除非這類擷取功能 是透過 Android SDK API 實作
  • [C-0-7] 必須為使用者提供停用服務的額度。
  • [C-0-8] 管理 Android 權限時，不得省略使用者負擔 這些元件都會由服務保存，並依循 Android 權限模型 描述 第 9.1 節：權限。

9.8.16。連續的音訊和相機資料

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

除了 9.8.2 錄製、9.8.6 OS 等級與 環境資料和 9.8.15 採用沙箱機制的 API 實作 運用在背景中 (持續) 取得的 AudioRecord、SoundTrigger 或其他音訊 API 或取得的相機資料 背景 (持續運作) 透過 CameraManager 或其他 Camera API：

如果裝置的導入方式會擷取 9.8.2 或 第 9.8.6 節，以及這種實作方式採用 背景 (持續播放) 透過 AudioRecord、SoundTrigger 或其他音訊 API 或使用 CameraManager 在背景 (持續) 取得的相機資料，或 其他 Camera API 的運作時間：

終止新規定

  • [C-0-1] 必須強制執行對應的指標 (攝影機和/或麥克風 條款 9.8.2 錄製)，除非：
    • 這項存取權會在採用沙箱機制的實作中執行 (詳情請參閱 9.8.15 在沙箱中執行 API 實作時)， 下列角色： 系統 UI Intelligence 系統環境音訊智慧、 系統音訊智慧、 系統通知情報、 系統文字智慧、 或 System Visual Intelligence。
    • 存取行為是透過沙箱執行的 透過 Android 開放原始碼計畫的機制強制執行 (HotwordDetectionService、 WearableSensingService、VisualQueryDetector)。
    • 數位應用程式將存取音訊資料，以便提供輔助用途 Google 助理應用程式，提供 SOURCE_HOTWORD 做為音訊來源。
    • 存取是由系統執行，並使用 的開放原始碼。
  • [C-SR-1] 強烈建議每次發生 功能使用這類資料，並預設為停用。
  • [C-SR-2] 強烈建議你採用相同的治療方式 (即遵循 9.8.2 錄製、9.8.6 作業系統層級與環境資料中概述的限制， 9.8.15 採用沙箱機制的 API 實作項目和 9.8.16 連續音訊和相機 資料) 對來自遠端穿戴式裝置的相機資料。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

來自遠端穿戴式裝置的相機資料，且在 Android 作業系統、採用沙箱機制的實作項目或沙箱之外的未加密表單 功能之前，請先：WearableSensingManager

如果裝置的實作方式會從遙控器接收攝影機或麥克風資料 穿戴式裝置中的資料，且其資料是以未加密形式 (位於 Android 作業系統、採用沙箱機制的實作項目，或 Google 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 也能用來收集隱私類別的資料 更敏感的內容我們要用 StatsManager::query API 可讓您查詢受限制的指標 類別的定義 在 StatsLog 中。

任何導入作業查詢及收集 StatsManager：

  • [C-0-1] 必須是裝置唯一的應用程式/實作項目，並保留 READ_RESTRICTED_STATS 權限。
  • [C-0-2] 「必須」使用 隱私權保護機制隱私權保護機制的定義如下 以便進行彙整分析並防止比對 「記錄事件或衍生結果」 可檢查每位使用者的資料 (例如使用不同 隱私保護技術，例如 RAPPOR)。
  • [C-0-3] 「不得」將這類資料與任何使用者身分 (例如 帳戶) 應用程式。
  • [C-0-4] 「請勿」將這類資料分享給其他未遵循的 OS 元件 要求 (9.8.17 隱私權保護) 遙測)。
  • [C-0-5] 必須為使用者提供啟用/停用隱私權保護功能的選項 遙測收集、使用及分享。
  • [C-0-6] 「必須」為使用者提供充足的資源，才能清除這類資料 系統會收集資料以任何形式儲存在裝置上。如果 使用者選擇清除資料，請「務必」移除目前儲存在 裝置。
  • [C-0-7] 必須揭露基礎隱私權保護通訊協定的執行情況 建立容器映像檔
  • [C-0-8 ]必須強制執行本節的資料輸出政策，限制收集作業 設有限制指標類別的資料 in 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] 必須啟動啟動，但不要求使用者提供憑證， 允許直接啟動感知應用程式存取裝置加密 (DE) 儲存空間 ACTION_LOCKED_BOOT_COMPLETED訊息播送後的大小
  • [C-1-2] 之後，「必須」符合下列條件，才能存取憑證加密 (CE) 儲存空間 使用者提供憑證，藉此解鎖裝置 (例如密碼、PIN 碼、解鎖圖案或指紋) 和ACTION_USER_UNLOCKED 訊息是否已播送
  • [C-1-13] 「不得」提供任何解鎖 CE 保護儲存裝置的方法 使用者提供的憑證、註冊的託管金鑰或 以符合 第 9.9.4 節。
  • [C-1-4] 必須使用驗證開機程序。
9.9.3.1。使用中繼資料加密功能來加密檔案

如果裝置的實作方式使用檔案型加密和中繼資料加密， 他們會：

  • [C-1-5] 必須使用 AES-256-XTS 或 Adiantum。AES-256-XTS 是進階加密標準 具有 256 位元加密金鑰長度，以 XTS 模式操作；與 金鑰是 512 位元.Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum檔案系統中繼資料屬於資料，例如檔案 尺寸、擁有權、模式和延伸屬性 (xattrs)。
  • [C-1-6] 必須使用 AES-256-CBC-CTS、AES-256-HCTR2 來加密檔案名稱。 或 Adiantum
  • [C-1-12] 如果裝置採用進階加密標準 (AES) 指示 (例如 ARMv8 密碼學擴充功能 (ARM 型裝置上的 ARMv8 加密擴充功能)，或 x86 型裝置上的 AES-NI)，然後針對檔案名稱使用上述 AES 選項 檔案內容和檔案系統中繼資料加密機制，不能使用 Adiantum。
  • [C-1-13] 必須使用加密高強度且無法復原的金鑰 衍生函式 (例如 HKDF-SHA512)，以便衍生任何所需子鍵 (例如 例如 CE 和 DE 金鑰，「加密編譯」、 不可撤銷」代表金鑰衍生功能的安全性強度 至少為 256 位元，且行為做為偽隨機函式 家人 而非輸入內容
  • [C-1-14] 不得使用相同的檔案式加密 (FBE) 金鑰或子金鑰 用於不同的加密編譯用途 (例如同時用於加密與金鑰) 衍生，或兩種不同的加密演算法)。
  • [C-1-15] 「必須」確保未刪除的加密檔案內容區塊全都 永久儲存空間是由加密金鑰和 相依檔案和內部偏移 檔案。另外，除非 加密是透過僅支援 IV 長度為 32 位元。
  • [C-1-16] 必須確保持續儲存所有未刪除的加密檔案名稱 分別用於加密不同目錄中的 包括加密金鑰和初始化向量 (IV)，

  • [C-1-17] 「必須」確保所有加密檔案系統中繼資料封鎖 永久儲存空間是以不同的加密金鑰組合進行加密 以及初始化向量 (IV)。

  • 保護 CE 和 DE 儲存區域以及檔案系統中繼資料的金鑰：

    • [C-1-7] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。 這個 KeyStore「必須」繫結於驗證開機程序和裝置硬體 信任根
    • [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
    • [C-1-9] 當使用者使用 未指定螢幕鎖定憑證。
    • [C-1-10] 必須提供獨特且不同的內容，亦即使用者的 CE 或 DE 金鑰比對其他使用者的 CE 或 DE 金鑰。
    • [C-1-11] 必須採用強制性支援的加密機制、金鑰長度和 。
    • [C-1-12] 在系統啟動載入程式解鎖和鎖定時，必須安全地清除資料 ，請參閱這裡的說明。

  • 應使用預先安裝的必要應用程式 (例如鬧鐘、電話、Messenger) 感應啟動感知。

上游 Android 開放原始碼專案提供了偏好的實作方式 以 Linux 核心「fscrypt」為基礎的檔案式加密加密功能 和中繼資料加密機制 (以 Linux 核心「dm-default-key」為基礎)而不是每個特徵的分數

9.9.3.2。每位使用者區塊層級加密

如果裝置的實作方式採用個別使用者區塊層級加密，則：

  • [C-1-1] 「必須」啟用第 9.5 節所述的多使用者支援功能。
  • [C-1-2] 必須為每個使用者提供分區，使用原始分區或 邏輯磁碟區
  • [C-1-3] 每位使用者都必須使用不重複的加密金鑰 基礎區塊裝置的加密

  • [C-1-4] 必須使用 AES-256-XTS 為使用者進行區塊層級加密 多個分區

  • 保護每位使用者區塊層級加密裝置的金鑰：

    • [C-1-5] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。 這個 KeyStore「必須」繫結於驗證開機程序和裝置硬體 信任根
    • [C-1-6] 必須繫結至對應使用者的螢幕鎖定畫面 憑證

您可以使用 Linux 核心實作每位使用者區塊層級的加密作業 「dm-crypt」而非每位使用者的分區

9.9.4。重新啟動時繼續

在重新啟動時重新啟用應用程式，可以解鎖所有應用程式的 CE 儲存空間，包括這些應用程式 但請注意，在透過 OTA 啟動的重新啟動後，尚不支援直接啟動功能。這個 功能可讓使用者在安裝 。

「在重新啟動時繼續」的實作必須持續確保 裝置落入攻擊者手中 攻擊者可復原使用者的 CE 加密資料，即使裝置電源 已開啟，取得 CE 儲存空間，而使用者在收到裝置後， OTA 也沒有限制為防止內部人員攻擊，我們也會假設攻擊者 以播送加密編譯簽署金鑰

具體違規事項如下：

  • [C-0-1] 即使是實際擁有憑證的攻擊者，也「不得」讀取 CE 儲存空間 裝置使用者，也會有下列功能和限制：

    • 可使用任何廠商或公司的簽署金鑰來任意簽署 訊息。
    • 這可能會導致裝置接收 OTA。
    • 可以修改任何硬體 (AP、Flash 等) 的作業，但 以下詳細說明，但這類修改至少需要 和重新開機會破壞 RAM 內容。
    • 無法修改防竄改硬體 (例如 Titan M) 的運作情形。
    • 無法讀取使用中裝置的 RAM。
    • 無法取得使用者的憑證 (PIN 碼、解鎖圖案、密碼)，或 否則就會被輸入。

舉例來說，應用程式實作的裝置實作方式 如要瞭解詳細的說明，請參閱這篇文章 符合 [C-0-1] 的規範。

9.10。裝置完整性

下列規定可確保 裝置完整性。裝置實作方式：

  • [C-0-1] 必須使用系統 API 方法正確回報 PersistentDataBlockManager.getFlashLockState() 是否為系統啟動載入程式 允許刷新系統映像檔。

  • [C-0-2] 必須支援驗證開機程序，確保裝置完整性。

如果裝置已啟動，不支援驗證開機程序 舊版 Android，無法新增支援 系統軟體更新的功能，可能不受 才能正常運作

驗證開機程序可保證裝置完整性 軟體如果裝置導入方式支援這項功能，就會執行以下動作：

  • [C-1-1] 必須宣告平台功能旗標 android.software.verified_boot。
  • [C-1-2] 必須在每個啟動序列中執行驗證作業。
  • [C-1-3] 必須使用不可變更的硬體金鑰 (即 並會移往系統分區。
  • [C-1-4] 必須實作每個驗證階段，才能檢查完整性 所有位元組的真實性，且在 進入下一階段
  • [C-1-5] 務必使用驗證演算法，盡可能維持既有狀態 NIST 對雜湊演算法 (SHA-256) 和公開金鑰的建議 (RSA-2048)。
  • [C-1-6] 系統驗證失敗時，不得允許啟動。 除非使用者同意繼續啟動，在這種情況下， 「不得」使用任何未經驗證的儲存空間區塊。
  • [C-1-7] 「不得」允許修改裝置上已驗證的分區 除非使用者明確解鎖系統啟動載入程式。
  • [C-1-8] 必須使用防竄改儲存空間，以便儲存 系統啟動載入程式已解鎖。防竄改儲存空間機制是指系統啟動載入程式 偵測儲存空間是否遭到 Android 內部竄改
  • [C-1-9] 必須在使用裝置時提示使用者 允許系統啟動載入程式轉移程序前，必須取得實體確認權限 並鎖定模式進入系統啟動載入程式解鎖模式。
  • [C-1-10] 必須針對 Android 使用的分區導入復原保護機制 (例如啟動程序、系統分區) 並使用防竄改儲存空間儲存 中繼資料，用於判斷系統允許的最小 OS 版本。
  • [C-1-11] 必須在系統啟動載入程式解鎖期間，安全地清除所有使用者資料， 如 '9.12.資料刪除(包括使用者資料分區和 任何 NVRAM 聊天室)。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-SR-1] 如果裝置上有多個獨立晶片 (例如無線電、 專用的映像檔處理器)，各個晶片的啟動程序 強烈建議在啟動時驗證每個階段。

  • [C-1-14] 每次啟動都必須至少驗證簽章一次，才能列入許可清單 列在系統設定中列為 require-strict-signature 的套件。

終止新規定

  • [C-SR-2] 強烈建議使用以下憑證驗證所有具有特殊權限的應用程式 APK 檔案： 受驗證開機程序保護的分區中的信任鏈結。
  • [C-SR-3] 強烈建議驗證 從其 APK 檔案之外具有特殊權限的應用程式 (例如動態載入的程式碼或 或強烈「建議」不要執行這些程式碼 。
  • 必須為任何具有永久性設定的元件導入復原保護機制 韌體 (例如數據機、相機) 以及「應使用防破壞儲存」 儲存中繼資料，用來決定系統允許的最低版本。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

如果裝置已啟動裝置實作項目，但未支援 C-1-8 到 C-1-8 舊版 Android 上的 C-1-11，無法新增 安裝系統軟體更新的要求，這些程式「可能」已免於 Google Cloud 就是最佳選擇

終止新規定

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

如果裝置實作可以驗證檔案 那麼他們會：

  • [C-2-1] 支援加密驗證檔案內容，無需讀取 整個檔案。

  • [C-2-2] 不得允許 安全檔案的讀取要求在未讀取內容時成功 是依據上述 [C-2-1] 驗證的。

  • [C-2-4] 必須針對已啟用的檔案傳回 O(1) 中的總和檢查碼。

如果裝置已經啟動，但沒有進行驗證 在較舊的 Android 版本中，依據可信任金鑰的檔案內容，且無法新增 透過系統軟體更新這項功能支援這項功能，但這類支援 。上游 Android 開放原始碼專案提供了 偏好實作這項功能，以 Linux kernel fs-verity 功能為基礎。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

裝置實作方式：

如果裝置實作支援 Android 保護確認 API 的用途：

  • [C-3-1] 必須回報ConfirmationPrompt.isSupported()的true 也能使用 Google Cloud CLI 或 Compute Engine API

  • [C-3-2] 必須確保在 Android 作業系統中執行的程式碼，包括 核心、惡意或其他行為，在沒有不良行為的情況下，就無法產生正面回應 互動。

  • [C-3-3] 必須確認使用者能夠查看並核准 在 Android 作業系統 (包括其核心) 的情況下 遭到破解。

終止新規定

9.11.金鑰和憑證

Android KeyStore 系統 可讓應用程式開發人員將加密編譯金鑰儲存至容器，並在容器中使用 透過 KeyChain API 執行加密編譯作業 或是 Keystore API 裝置實作方式：

  • [C-0-1] 至少須允許匯入或產生 8,192 組金鑰。
  • [C-0-2] 螢幕鎖定驗證必須導入時間間隔 。如果 n 為失敗次數， 時間間隔至少須為 30 秒，n <30.對於 n >29、 時間間隔值必須至少為 30*2^floor((n-30)/10) 秒 或至少 24 小時 (以較短者為準)。
  • 請勿限制可產生的金鑰數量。

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

  • [C-1-1] 必須使用獨立的 執行環境
  • [C-1-2] 必須導入 RSA、AES、ECDSA ECDH (如果支援 IKeyMintDevice)、3DES、 以及 HMAC 密碼編譯演算法，以及 MD5、SHA-1 和 SHA-2 系列雜湊 能夠妥善支援 Android KeyStore 系統支援的函式 所在區域的演算法，與執行的程式碼 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境，包括《數位市場法》上游 Android 開放原始碼 Project (Android 開放原始碼計畫) 使用 值得信賴，但 其他以 ARM TrustZone 為基礎的解決方案，或是由第三方人員 可替代實作方式，以管理程序為基礎 只要設定成「自動重新啟動」 和「在主機維護期間」選項即可
  • [C-1-3] 必須在獨立環境中執行螢幕鎖定驗證 執行環境，且僅在成功時允許驗證繫結 要使用的金鑰螢幕鎖定憑證必須儲存在 以便僅允許獨立的執行環境執行螢幕鎖定 驗證。上游 Android 開放原始碼計畫 總機人員硬體抽象層 (HAL) 和 Trusty 合作，以滿足這項需求

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-1-4] 必須支援認證簽署金鑰所在的金鑰認證 受安全硬體的保護，而且是在安全的硬體中執行。 「必須」 在以下服務之間共用認證簽署金鑰： 變得足夠的裝置數量，以防止按鍵 禁止 避免當成「永久」使用 裝置 ID

    注意：為符合這項規定，您必須共用相同的認證金鑰 特定 SKU 除非 至少 100,000 個指定的單位 如果超過 100,000 個單位 可以為每個群組使用不同鍵 超過 100,000 個單位 另外 遠端金鑰佈建解決方案可用於在短期內佈建 取得認證金鑰。

終止新規定

請注意，如果裝置已啟動至較舊的 Android 版本 這類裝置不受具有 KeyStore 的限制 並支援金鑰認證 除非宣告了 android.hardware.fingerprint 功能，而該功能需要 由獨立執行環境支援的 KeyStore。

  • [C-1-5] 必須允許使用者選擇 並鎖定為鎖定狀態，且最短允許的逾時期限 15 秒。可隨車用運算主機鎖定螢幕的 Automotive 裝置 關閉或使用者切換，可能「沒有」睡眠逾時的情況 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定
  • [C-1-6] 必須支援下列其中一種帳戶：
    • IKeymasterDevice 3.0、
    • IKeymasterDevice 4.0
    • IKeymasterDevice 4.1、
    • IKeyMintDevice 版本 1，或
    • IKeyMintDevice 版本 2。
  • [C-SR-1] 極力建議支援 IKeyMintDevice 版本 1。

9.11.1.保護螢幕鎖定、驗證及虛擬裝置

Android 開放原始碼計畫的實作方式採用分層驗證模型，其中 知識庫的主要驗證機制可由 第二種高強度生物特徵辨識或低階形式。

裝置實作方式：

  • [C-SR-1] 強烈建議你只將下列其中一種設定設為主要驗證方式 方法：

    • 數字 PIN
    • 英數字元密碼

    • 3x3 點狀格線中的滑動模式

      請注意，上述驗證方法稱為 主要驗證方法。

  • [C-0-1] 必須限制主要驗證失敗次數。

  • [C-SR-5] 強烈建議你不要導入上限 20 次 主要驗證嘗試，若使用者同意並選擇啟用這項功能， 執行「恢復原廠設定」超過上限的主要節點數量 驗證嘗試。

若裝置導入作業將數字 PIN 設為建議的主要 PIN 碼 驗證方法，然後：

  • [C-SR-6] 強烈建議使用至少 6 位數的 PIN 碼，或 相當於 20 位元熵。
  • [C-SR-7] 強烈建議「不要」使用長度少於 6 位數的 PIN 碼 允許使用者在沒有互動的情況下自動輸入 PIN 碼，以免洩漏 PIN 碼 長度。

如果裝置實作方式新增或修改建議的主要驗證方式 並運用新的驗證方法鎖定螢幕， 新的驗證方法：

如果裝置導入作業新增或修改要解鎖的驗證方法 鎖定螢幕 (以已知的密鑰為依據)，並使用新的驗證方式 方法才是鎖定螢幕的安全方式：

  • [C-3-1] 允許的最短輸入長度必須達到 大於 10 位元
  • [C-3-2] 所有可能輸入值的最大熵「必須」大於 18 位元。
  • [C-3-3] 新的驗證方法「不得」取代任何 建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 所提供的解決方案。
  • [C-3-4] 啟用新的驗證方式後， 裝置政策控制器 (DPC) 應用程式已設定密碼 透過 Google Cloud 控制台 DevicePolicyManager.setRequiredPasswordComplexity() 並使用較受限的複雜度常數 PASSWORD_COMPLEXITY_NONE 或透過 DevicePolicyManager.setPasswordQuality() 設定 方法，常數大於 100 的 PASSWORD_QUALITY_BIOMETRIC_WEAK。
  • [C-3-5] 新的驗證方法「必須」改回使用 建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、 密碼)，或是清楚向 使用者可能導致部分資料不會因為 保護自身資料的隱私權

如果裝置實作方式新增或修改建議的主要驗證方式 解鎖螢幕鎖定的方法，以及使用 新技術是採用生物特徵辨識技術 偵測裝置是否安全 方法：

  • [C-4-1] 必須符合一節所述的所有規定 7.3.10，適用於第 1 級 (舊稱) 便利性)。
  • [C-4-2] 必須設有備用機制，才能使用建議選項 主要驗證方法。
  • [C-4-3] 必須停用，且只允許使用建議的主要執行個體 驗證以解鎖螢幕時，裝置政策控制器 (DPC) 應用程式已透過呼叫 方法設定鍵盤保護功能政策 DevicePolicyManager.setKeyguardDisabledFeatures()、 與任何相關的生物特徵辨識旗標 (例如 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、 KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS)。

如果生物特徵辨識驗證方式不符合需求 適用於第 3 級 (前身為「Strong」)，如上述內容所述 第 7.3.10 節：

  • [C-5-1] 裝置政策控制器 (DPC) 「必須」停用這些方法 應用程式已透過 DevicePolicyManager.setRequiredPasswordComplexity() 使用比 PASSWORD_COMPLEXITY_LOW 限制更複雜的值區 或使用 DevicePolicyManager.setPasswordQuality() 方法是使用較嚴格的品質常數 PASSWORD_QUALITY_BIOMETRIC_WEAK。
  • [C-5-2] 必須要求使用者驗證推薦的首選主要電話號碼 驗證 (例如：PIN 碼、解鎖圖案、密碼)，方法如 [C-1-7] 和 [C-1-8]，請參閱第 7.3.10 節。
  • [C-5-3] 這些方法「不得」視為安全螢幕鎖定。 符合本節中以 C-8 開頭的相關規定。

如果裝置導入作業新增或修改要解鎖的驗證方法 鎖定螢幕，而新的驗證方法是以實體權杖為基礎 或是位置：

  • [C-6-1] 他們「必須」採用備用機制，才能使用建議的 主要驗證方式，以已知密鑰為基礎， 才是安全螢幕鎖定。
  • [C-6-2] 必須停用新方法，且僅允許以下其中一種： 建議的主要驗證方法 裝置政策控制器 (DPC) 應用程式已採用以下其中一項設定：
  • [C-6-3] 必須要求使用者接受其中一項建議的主要執行個體 至少每隔一次驗證方式 (PIN 碼、解鎖圖案、密碼) 驗證 4 小時。當實體權杖符合 C-X 中 TrustAgent 實作方面的需求、逾時限制 則會套用 C-9-5 所定義。
  • [C-6-4] 「不得」將新方法視為安全螢幕鎖定 遵循下列 C-8 中所列的限制。

如果裝置導入了安全螢幕鎖定，且包含一或多個 實作 TrustAgentService System API 的信任代理程式，這類代理程式會：

  • [C-7-1] 必須在設定選單和居家鎖上清楚標示 裝置鎖定螢幕。 舉例來說，Android 開放原始碼計畫會顯示 「自動鎖定設定」以及「電源鍵立即鎖定」的 設定選單和螢幕鎖定畫面上可清楚辨識的圖示。
  • [C-7-2] 必須尊重並完整導入 DevicePolicyManager 類別，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常數。
  • [C-7-3] 「不得」完全導入 TrustAgentService.addEscrowToken() 功能，在做為主要個人裝置使用 例如手持裝置，但可以在裝置上完整實作這個函式 常見的分享模式 (例如 Android TV 或 Automotive 裝置)。
  • [C-7-4] 必須加密儲存 TrustAgentService.addEscrowToken()。
  • [C-7-5] 「不得」將加密金鑰或託管權杖儲存在 和使用車鑰的裝置舉例來說， 儲存在手機上的金鑰，以便在電視上解鎖使用者帳戶。 汽車無法儲存信託權杖 車輛的任何零件都沒問題
  • [C-7-6] 必須在 啟用託管權杖以解密資料儲存空間。
  • [C-7-7] 必須採用備用機制，才能使用建議選項 主要驗證方法。
  • [C-7-9] 必須要求使用者接受任一建議的主要執行個體 驗證 (例如：PIN 碼、解鎖圖案、密碼) 方法， 如第 7.3.10 節中的 [C-1-7] 和 [C-1-8]，除非 使用者安全 (例如駕駛人分心) 具有疑慮。
  • [C-7-10] 不得視為安全螢幕鎖定，且必須遵守 限制條件。
  • [C-7-11] 不得允許主要個人裝置上的 TrustAgents 使用 (例如手持裝置) 解鎖裝置，且只能用來 讓已解鎖裝置保持在解鎖狀態 最長 4 小時。預設實作 Android 開放原始碼計畫中的 TrustManagerService 符合這項規定。
  • [C-7-12] 必須使用加密編譯的安全機制 (例如 UKEY2) 將託管符記從儲存體中傳遞 複製到目標裝置

如果裝置導入作業新增或修改要解鎖的驗證方法 也就是不是上述的安全鎖定畫面，然後 新的鍵盤鎖解鎖方法：

如果裝置實作允許應用程式建立次要執行個體 虛擬螢幕 不支援相關聯的輸入事件，例如透過 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] 每位使用者都必須有獨立的虛擬裝置執行個體

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-10-6] 必須禁止建立相關輸入來源 透過 VirtualDeviceManager 回報的事件 由 應用程式串流提供 。 DevicePolicyManager.setNearbyAppStreamingPolicy。

終止新規定

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-10-7] 必須：
    • 停用剪貼簿
    • 為每部支援剪貼簿的裝置啟用獨立的剪貼簿

  • [C-10-7] 必須為每個虛擬裝置使用個別的剪貼簿 (或為虛擬裝置停用剪貼簿)

終止新規定

  • [C-10-11] 必須在虛擬裝置上停用驗證 UI，包括 知識因素輸入和生物特徵辨識提示

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-10-12] 必須限制顯示透過虛擬裝置啟動的意圖 只會在同個虛擬裝置上運作

終止新規定

  • [C-10-13] 不得使用虛擬裝置鎖定狀態做為使用者驗證方式 取得 Android KeyStore 系統的授權。詳情請見 KeyGenParameterSpec.Builder.setUserAuthentication*。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-10-14] 必須為使用者提供權限設定，如此才能啟用剪貼簿分享功能 裝置，必須先在實體和虛擬裝置之間共用剪貼簿資料 說明裝置是否導入共用剪貼簿
  • [C-10-15] 必須允許應用程式在各平台存取剪貼簿資料時顯示通知 裝置，且「必須」在一分鐘內 (從 初次分享時間。

終止新規定

如果裝置實作項目允許使用者轉移主要裝置 從來源裝置到目標裝置的驗證知識因素 例如：進行目標裝置的初始設定時，他們會：

  • [C-11-1] 必須加密知識因素，保護保證類似於 這些 Pod 中 Google Cloud Key Vault 服務 傳輸安全性白皮書 從來源裝置到目標裝置的知識因素 知識因子無法從遠端解密或用於遠端解鎖 任一裝置。
  • [C-11-2] 必須在來源裝置上要求使用者確認 來源裝置的知識因素，再轉移知識因素 複製到目標裝置
  • [C-11-3] 必須，目標裝置上未設定任何主要驗證方式 並請使用者確認轉移的知識因素 將知識因素設為主要裝置 驗證知識因素 可使用從來源裝置轉移的任何資料。

如果裝置導入了安全螢幕鎖定，且包含一或多個 可藉由信任代理程式呼叫 TrustAgentService.grantTrust() System API FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 標記會：

  • [C-12-1] 連線至grantTrust() 以及設有螢幕鎖定畫面的鄰近實體裝置 以該螢幕鎖定方式驗證身分。透過 Proxy 傳送裝置 在使用者單次解鎖後，使用腕上或人體感測機制 滿足使用者驗證要求
  • [C-12-2] 必須將裝置實作加入 TrustState.TRUSTABLE 螢幕關閉時 (例如按下按鈕或螢幕關閉) 逾時)，且 TrustAgent 並未撤銷信任。Android 開放原始碼計畫符合要求 這項規定。
  • [C-12-3] 只能將裝置從「TrustState.TRUSTABLE」移到 TrustState.TRUSTED 狀態：表示 TrustAgent 仍會依據 C-12-1 中的需求條件。
  • [C-12-4] 必須撥打 TrustManagerService.revokeTrust()
    • 最多 24 小時後才取得信任，
    • 8 小時閒置期間之後，或
    • 如果實作方式未使用加密編譯安全 準確度 (如 [C-12-5] 中定義) 位置相差甚遠。
  • [C-12-5] 導入仰賴安全準確的範圍， 要求 [C-12-4] 必須使用下列其中一種解決方案：
    • 使用 UWB 實作：
      • 必須符合規範、認證、正確性和 校正要求 ，適用於 UWB。詳情請參閱 7.4.9。
      • 必須使用 7.4.9。
    • 使用 Wi-Fi 社區感知網路 (NAN) 實作：

如果實作裝置，可讓應用程式建立次要虛擬螢幕和支援相關輸入來源 事件，例如透過 VirtualDeviceManager 且螢幕未標示為 VIRTUAL_DISPLAY_FLAG_SECURE，它們：

  • [C-13-8] 必須封鎖含有 android:canDisplayOnRemoteDevices 屬性或中繼資料 android.activity.can_display_on_remote_devices 設為 false 的 活動，才能在虛擬上啟動 裝置。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

  • [C-13-9] 必須封鎖活動 這些元件不會明確啟用串流 指出它們會顯示敏感內容 SurfaceView#setSecure、 和 FLAG_SECURE或 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS、 實際使用的裝置

終止新規定

如果裝置實作方式可透過以下方式支援個別螢幕電源狀態： DeviceStateManager，並且透過以下方式支援不同的螢幕鎖定狀態 KeyguardDisplayManager，他們：

  • [C-SR-2] 強烈建議使用憑證會議 要求 (根據第 9.11.1 節定義) 或至少從事生物特徵辨識會議 第 1 級規格 (根據第 7.3.10 節) 定義的規格， 。
  • [C-SR-3] 強烈建議你限制個別螢幕的解鎖方式 並傳回相關內容
  • [C-SR-4] 強烈建議使用者全面鎖定所有螢幕 從主要手持裝置鎖定後開始鎖定

9.11.2。強固盒

Android KeyStore 系統可讓您 應用程式開發人員將加密編譯金鑰儲存在專屬的安全處理器中 以及上述的獨立執行環境如此 專用的安全處理器稱為「StrongBox」。需求 C-1-3 至下方的 C-1-11 表單，定義裝置必須符合哪些要求 符合 StrongBox 資格

具備專用安全處理器的裝置實作方式：

  • [C-SR-1] 強烈建議支援 StrongBox。StrongBox 會 可能會成為日後版本中的必要條件

如果裝置的實作支援 StrongBox，他們會：

  • [C-1-1] 必須宣告 FEATURE_STRONGBOX_KEYSTORE。

  • [C-1-2] 「必須」提供用於背蓋的專屬安全硬體 KeyStore 和安全的使用者驗證。專屬的 硬體產品也可以用於其他用途

  • [C-1-3] 必須採用不共用快取、DRAM 和輔助處理器的獨立 CPU 或其他核心資源與應用程式處理器 (AP) 搭配使用。

  • [C-1-4] 必須確保與 AP 共用的所有周邊裝置均無法修改 以任何方式處理 StrongBox，或從 StrongBox 取得任何資訊。 AP 可能會停用或封鎖 StrongBox 存取權。

  • [C-1-5] 必須具有合理的內部時鐘 (+-10%) 不會遭到 AP 操控

  • [C-1-6] 必須具備真正的隨機號碼產生器 均勻分佈且無法預測的輸出內容。

  • [C-1-7] 必須防範竄改行為，包括抵抗各種攻擊 就是能達到的實體滲透率和毛刺

  • [C-1-8] 必須面對旁視力 (包括抵抗性攻擊) 利用功率、時間、電磁輻射和熱力洩漏資訊 輻射側聲道。

  • [C-1-9] 「必須提供」安全儲存空間，確保機密性 完整性、真實性、一致性和即時性 內容。「不得」讀取或修改儲存體，除非是 。

  • 為了驗證符合 [C-1-3] 至 [C-1-9] 規範，裝置 實作：

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

終止新規定

  • [C-1-11] 必須包含由 經國家認可的測試實驗室結合高攻擊 評估潛在安全漏洞 適用於智慧型卡片可能遭受攻擊的共通準則。
  • [C-SR-2] 強烈建議你納入 使用安全目標、評估保證等級進行評估 (EAL) 5，以 AVA_VAN.5 擴增。EAL 5 認證可能會 成為未來版本中的必要條件
  • [C-SR-3] 強烈建議提供內部人士攻擊抵抗 (IAR)，也就是能存取韌體簽署的內部人員 金鑰無法產生導致 StrongBox 外洩的韌體 規避功能性安全性要求 讓使用者存取敏感的使用者資料。建議的 IAR 僅允許使用主要使用者密碼更新韌體 是透過 IAuthSecret HAL 提供

9.11.3.身分憑證

識別資訊憑證系統是由所有實作 API 中的 android.security.identity.*敬上 套件。應用程式開發人員可利用這些 API 儲存及擷取使用者身分 文件。裝置實作方式：

  • [C-SR-1] 強烈建議導入身分憑證 系統：

如果裝置的實作實作了身分識別憑證系統，就會：

  • [C-1-1] 必須針對 IdentityCredentialStore#getInstance() 傳回非空值 方法。

  • [C-1-2] 必須實作身分識別憑證系統 (例如 android.security.identity.* API) 與透過信任存放區通訊的程式碼 應用程式區域，而且與執行程式碼的 與核心以上版本之間的互動安全隔離「必須」封鎖所有潛在機制 核心或使用者空間程式碼可能存取 隔離環境，包括《數位市場法》

  • [C-1-3] 實作身分所需的加密編譯作業 憑證系統 (例如 android.security.identity.* API) 必須 「必須」在信任應用程式及私密金鑰內容中執行 除非特別需要，否則一律不要離開獨立的執行環境 與較高層級的 API (例如 createEphemeralKeyPair() 方法)。

  • [C-1-4] 信任的應用程式「必須」採用 安全屬性不會受到影響 (例如：未發布憑證資料 除非滿足存取權控管條件，否則系統無法為 任意資料)。

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

9.12.資料刪除

所有裝置實作方式：

  • [C-0-1] 「必須」為使用者提供執行「恢復原廠設定」的機制。
  • [C-0-2] 執行 「恢復原廠設定」。
  • [C-0-3] 請務必以符合相關需求的方式刪除資料 例如 NIST SP800-88 等業界標準， 重設」的訊息。
  • [C-0-4] 必須觸發上述的「恢復原廠設定」處理完成後 DevicePolicyManager.wipeData()敬上 API 是由主要使用者的 Device Policy Controller 應用程式呼叫。
  • 可能提供快速清除資料選項，只可執行邏輯資料清除作業。

9.13.安全啟動模式

Android 提供安全啟動模式，可讓使用者開機並進入模式 只允許預先安裝的系統應用程式，且所有第三方 應用程式已停用。這個模式稱為「安全啟動模式」，可讓使用者 解除安裝可能有害的第三方應用程式。

裝置導入方式如下：

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

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

  • [C-1-1] 必須為使用者提供 以無法外部第三方中斷的方式進入安全啟動模式 裝置上安裝的應用程式，但第三方應用程式為 同時設定了 UserManager.DISALLOW_SAFE_BOOT敬上 標記為 true

  • [C-1-2] 必須讓使用者能夠 在安全模式中解除安裝任何第三方應用程式。

  • 應為使用者提供透過該選項進入安全啟動模式的選項 啟動選單，但此模式的工作流程與一般啟動程序不同。

9.14。汽車車輛系統隔離

Android Automotive 裝置應與重要車輛交換資料 車輛 HAL ，透過 CAN 公車等車輛網路收發訊息。

導入下列安全性功能，即可確保資料交換機制安全無虞 Android 架構層可防範惡意或無意間與應用程式互動 這些子系統

9.15。訂閱計畫

「訂閱方案」請參閱我們提供的計費關係方案詳細資料 由行動電信業者提供 SubscriptionManager.setSubscriptionPlans()。

所有裝置實作方式：

9.16。應用程式資料遷移

如果裝置實作具有將資料從裝置遷移至雲端的功能 ，且不限制複製的應用程式資料 是由應用程式開發人員透過資訊清單設定 android:fullBackupContent 屬性：

  • [C-1-1] 「不得」從以下來源啟動應用程式資料轉移程序： 使用者尚未將主要驗證設為 描述 9.11.1 安全螢幕鎖定和驗證。
  • [C-1-2] 必須安全地確認來源的主要驗證方式 ，確認使用者意圖在來源中複製資料 裝置才會轉移任何資料。
  • [C-1-3] 「必須」使用安全金鑰認證來確保 在裝置對裝置之間遷移時，系統會偵測出裝置本身和目標裝置， 合法的 Android 裝置，並且系統啟動載入程式已鎖定。
  • [C-1-4]「必須」只將應用程式資料遷移至 並使用相同的套件名稱「和」簽署憑證。
  • [C-1-5] 必須顯示來源裝置已包含資料 則透過設定選單遷移裝置間資料。使用者 「不得」移除此跡象。

開始 15 的新規定 (Android 開放原始碼計畫實驗功能)

9.17。Android 虛擬化架構

Android 虛擬化架構 (AVF) API (android.system.virtualmachine.*) 同時支援受保護的虛擬機器 (pVM) 和非防護的虛擬機器 (非 PVM) 以下系統屬性：

如果將 ro.boot.hypervisor.vm.supported 設為 true，則非 PVM 會 支援。

如果將 ro.boot.hypervisor.protected_vm.supported 設為 true，PVM 就會 支援。

裝置實作方式：

  • [C-0-1] 必須支援 Android 虛擬化架構 API (android.system.virtualmachine.*) 適用於 pVM、非 PVM，以及 兩者。

如果裝置實作 Android 支援功能 Virtualization Framework API (android.system.virtualmachine.*)， Android 主機：

  • [C-1-1] 必須支援 android.system.virtualmachine 套件。

  • [C-0-2] [C-1-2] 「不得」修改 Protected 的管理 虛擬機器(pVM) pVM 和非 PVM)。
  • [C-0-4] [C-1-4] 必須僅允許使用平台簽署的程式碼。特殊權限 已預先安裝在唯讀分區中的應用程式 建立及執行 pVM 虛擬機器。 注意：日後的 Android 版本中可能會發生變更。
  • [C-0-5] [C-1-5] 必須只允許不可進行偵錯的 pVM 執行工廠中的程式碼 圖片或平台更新，當中也包含 特殊權限 已預先安裝 應用程式。

如果裝置實作 Android 支援功能 Virtualization Framework API (android.system.virtualmachine.*)，然後 任何 pVM 執行個體：

  • [C-0-6] [C-2-1] 必須能夠執行虛擬化中可用的所有作業系統 。
  • [C-0-7] [C-2-2] 「不得」允許 pVM 執行未經 裝置實作或 OS 廠商
  • [C-0-8] [C-2-3] 不得允許 PVM 以程式碼的形式執行資料 (例如 SELinux 永不允許) execmem)。
  • [C-0-9] [C-2-5] 「必須」採用深度 pVM 防禦機制 (例如，pVM 適用的 SELinux) 適合非 microdroid 作業系統使用
  • [C-0-10] [C-2-6] 「必須」確保 VM 無法執行的映像檔時，pVM 無法啟動 進行驗證「必須」在 VM 內完成驗證。
  • [C-0-11] [C-2-7] 如果執行個體的完整性，「必須」確保 pVM 無法啟動。img 遭到破解。

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

  • [C-0-12] [C-3-1] 「必須」確保 VM 擁有的記憶體頁面專屬 (pVM 或主機 VM訪客或主機 pVM) 或管理程序只有 管理虛擬機器或管理程序 保護或未受防護的虛擬機器
  • [C-0-13] [C-3-2] 在 PVM 使用網頁後，請清除網頁中的資料，然後才能傳回網頁 傳送至主機 (例如 pVM 遭刪除)。
  • [C-0-14] [C-SR-1] 強烈建議 必須確保 在 pVM 中的任何程式碼之前，系統會先載入並執行 pVM 韌體。
  • [C-0-15] [C-3-4] 必須確保每個 VM 均 pVM 衍生每個 VM 也就是「開機憑證鏈結」的密鑰 (BCC) 和複合裝置 ID (CDI) 提供給 pVM 執行個體 無法衍生自該特定的 VM pVM 執行個體和變更 。

Android 虛擬化架構 (AVF) API (android.system.virtualmachine.*) 可讓應用程式建立可載入及執行的裝置端虛擬機器 (VM)。 做為酬載

如果裝置實作方式將 FEATURE_VIRTUALIZATION_FRAMEWORK 設為 true，就會：

  • [C-1-6] 必須確保 android.system.virtualmachine.VirtualMachineManager.getCapabilities() 會傳回至少下列其中一項：
    • CAPABILITY_PROTECTED_VM
    • CAPABILITY_NON_PROTECTED_VM

如果裝置實作 Android 虛擬化架構 API 的支援功能， 然後涵蓋所有領域：

  • [C-4-1] 不得向允許略過 Android 安全性模型。

如果裝置實作 Android 虛擬化架構 API 的支援功能，則：

  • [C-5-1] 必須能支援隔離編譯，但可將其停用 裝置出貨時的隔離編譯功能。

如果裝置實作 Android 支援功能 以及 Virtualization Framework API 金鑰管理：

  • [C-SR-2] 強烈建議使用 DICE 做為每個 VM 的密鑰衍生 以注意力機制為基礎

  • [C-0-16] 必須針對受保護 VM 所使用的分區導入復原保護機制 (例如啟動、pVM 韌體) 使用 防竄改儲存設備 用來判斷允許的分區最低版本需求的中繼資料 包括相關 DICE 中的安全性版本 對應的憑證

終止新規定

10. 軟體相容性測試

裝置實作「必須」通過本節所述的所有測試。 不過請注意，沒有完整的軟體測試套件。 因此，我們強烈建議裝置實作者 參考檔案與首選檔案變更次數下限 Android 開放原始碼計畫提供的 Android 實作。 這麼做可將引入不相容的錯誤風險降至最低 需重新作業及可能更新裝置。

10.1.Compatibility Test Suite

裝置實作方式：

CTS 的設計宗旨是在實際裝置上執行。和任何軟體一樣，CTS 本身可能包含昆蟲CTS 的版本會與 相容性定義，以及可能發布的多個 CTS 修訂版本 Android 15。

裝置實作方式：

  • [C-0-3] 必須通過裝置當下可用的 CTS 版本 或是軟體已完成

  • 應使用 Android 開放原始碼樹中的參考實作

10.2.CTS 驗證器

Compatibility Test Suite 隨附 CTS Verifier 目的在於由真人操作人員執行，以測試無法支援的功能 例如相機功能的正確性 感應器。

裝置實作方式：

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

CTS Verifier 針對多種硬體進行了測試，包括部分硬體。 非必填

裝置實作方式：

  • [C-0-2] 必須通過他們擁有的所有硬體測試。例如 如果裝置具備加速計，則應「必須」正確執行 CTS Verifier 中的加速計測試案例。

測試相容性定義為選用功能的情況 文件可能會略過或省略。

  • [C-0-2] 每部裝置和每個版本都必須正確執行 CTS Verifier 如上所述。不過，由於許多版本非常相似， 實作者不應在建構時明確執行 CTS Verifier 只有稍有不同具體來說，這類裝置導入作業 不同於過去只通過 CTS 驗證器的實作 包含一組包含的地區、品牌宣傳等。但可以省略 CTS 驗證器測試。

11. 可更新的軟體

  • [C-0-1] 裝置的實作「必須」提供用來取代 整個系統軟體機制不需執行「即時」 升級，也就是說，裝置可能要重新啟動。 任何方法都可以使用，前提是它可以取代 裝置上預先安裝的軟體。例如以下任一種 能滿足這項需求的方法：

    • 「無線更新」(OTA)下載成離線更新。
    • 「網路共用」從主機電腦透過 USB 更新。
    • 「離線」即可進行更新，並透過卸除式儲存空間中的檔案更新。

  • [C-0-2] 使用的更新機制「必須」支援更新，但使用者不需抹除使用者 資料。也就是說，更新機制「必須」保留應用程式的私人資料， 應用程式共用資料。請注意，上游 Android 軟體包含 配合這項需求條件。

  • [C-0-3] 完整更新必須簽署且裝置端更新機制 「必須」針對裝置上儲存的公開金鑰驗證更新和簽名。

  • [C-SR-1] 我們強烈建議使用簽署機制對更新檔案進行雜湊處理 使用 SHA-256，並使用 ECDSA NIST 根據公開金鑰驗證雜湊 P-256。

如果裝置導入方式支援非計量付費資料 連線，例如 802.11 或藍牙 PAN (個人區域網路) 設定檔 然後：

  • [C-1-1] 必須支援透過離線更新和離線更新進行 OTA 下載。

裝置實作應驗證系統映像檔與二進位檔相同 結果顯示 OTA 結束後的預期結果區塊式 OTA Android 開放原始碼計畫中的實作方式，自 Android 起新增 5.1 來滿足這項規定。

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

如果裝置發布後發現錯誤，但 其合理的產品生命週期內，將諮詢 以便影響第三方相容性 應用程式，然後：

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

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

12. 文件變更記錄

如需此版本相容性定義的異動摘要，請參閱：

13. 與我們聯絡

您不妨加入 android 相容性論壇 然後要求進一步說明，或提出您認為文件並未的問題 翻唱。