Android 10 相容性定義

1. 簡介

本文列出裝置必須符合的需求，才能與 Android 10 相容。

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

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

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

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

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

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

1.1 文件結構

1.1.1. 依裝置類型劃分的需求

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

第 2 節之後的章節列出所有其他規定，這些規定適用於任何 Android 裝置實作。本文將這些需求稱為「核心需求」。

1.1.2. 需求 ID

MUST 需求會指派需求 ID。

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

各 ID 的定義如下：

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

1.1.3. 第 2 節中的需求 ID

第 2 節中的規定 ID 會以對應的節 ID 開頭，後面接續上述規定 ID。

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

2. 裝置類型

雖然 Android 開放原始碼計畫提供可用於各種裝置類型和板型規格的軟體堆疊，但有幾種裝置類型已建立相對完善的應用程式發布生態系統。

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

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

2.1 裝置設定

如要瞭解各裝置類型在硬體設定方面的主要差異，請參閱本節中適用於特定裝置的規定。

2.2. 手持裝置需求

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

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

• 使用可提供行動力的電源，例如電池。
• 實際對角線螢幕尺寸介於 2.5 到 8 吋之間。

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

2.2.1. 硬體

手持裝置實作方式：

• [7.1.1.1/H-0-1] 必須至少有一個與 Android 相容的螢幕，實體對角線尺寸至少為 2.5 吋，且每個與 Android 相容的螢幕都必須符合本文件中所述的所有規定。
• [7.1.1.3/H-SR] 強烈建議提供使用者變更顯示大小 (螢幕密度) 的功能。

如果手持裝置實作項目透過 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.5/H-0-1] 必須支援上游 Android 開放原始碼實作的舊版應用程式相容模式。也就是說，裝置實作「不得」變更啟動相容模式的觸發條件或門檻，也「不得」變更相容模式本身的行為。
• [7.2.1/H-0-1] 必須支援第三方輸入法編輯器 (IME) 應用程式。
• [7.2.3/H-0-3] 必須在提供主畫面的所有 Android 相容螢幕上提供「首頁」功能。
• [7.2.3/H-0-4] 必須在所有 Android 相容螢幕上提供返回功能，並在至少一個 Android 相容螢幕上提供「最近」功能。
• [7.2.3/H-0-2] 必須將「返回」功能 (KEYCODE_BACK) 的一般和長按事件都傳送至前景應用程式。系統「不得」取用這些事件，且「可以」由 Android 裝置外部觸發 (例如連線至 Android 裝置的外部硬體鍵盤)。
• [7.2.4/H-0-1] 必須支援觸控螢幕輸入。
• [7.2.4/H-SR] 如果前景活動未處理這些長按事件，強烈建議在長按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 時，啟動使用者選取的小幫手應用程式，也就是實作 VoiceInteractionService 的應用程式，或處理 ACTION_ASSIST 的活動。
• [7.3.1/H-SR] 強烈建議加入 3 軸式加速度計。

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

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

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

• [7.3.3/H-2-1] 找到 GNSS 測量資料後，即使尚未回報從 GPS/GNSS 計算出的位置資訊，也必須立即回報 GNSS 測量資料。
• [7.3.3/H-2-2] 必須回報 GNSS 虛擬距離和虛擬距離變化率，在空曠環境中判斷位置後，靜止或以小於每平方秒 0.2 公尺的加速度移動時，至少 95% 的時間內，這些資料足以計算出 20 公尺內的位置，以及 0.2 公尺/秒內的速度。

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

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

可撥打語音電話並在 getPhoneType 中指出 PHONE_TYPE_NONE 以外任何值的實作項目：

• [7.3.8/H] 應包含鄰近感應器。

手持裝置實作方式：

• [7.3.11/H-SR] 建議支援 6 自由度的姿勢感應器。
• [7.4.3/H] SHOULD include support for Bluetooth and Bluetooth LE.

如果手持裝置實作項目包含付費連線，則：

• [7.4.7/H-1-1] 必須提供數據節省模式。

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

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

手持裝置實作方式：

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

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

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

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

• [7.6.1/H-3-1] 如果預設螢幕使用高達 FHD (例如 WSXGA+) 的訊框緩衝區解析度，核心和使用者空間可用的記憶體必須至少為 896MB。

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

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

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

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

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

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

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

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

• [7.6.1/H-9-1] MUST declare the feature flag android.hardware.ram.low.
• [7.6.1/H-9-2] 必須具備至少 1.1 GB 的非揮發性儲存空間，用於存放應用程式私有資料 (又稱「/data」分割區)。

如果手持裝置實作項目包含超過 1 GB 的記憶體 (可供核心和使用者空間使用)，則：

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

手持裝置實作方式：

• [7.6.2/H-0-1] 不得提供小於 1 GiB 的應用程式共用儲存空間。
• [7.7.1/H] SHOULD include a USB port supporting peripheral mode.

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

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

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

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

手持裝置實作方式：

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

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

• [7.9.1/H-1-1] MUST declare the android.hardware.vr.high_performance feature flag.
• [7.9.1/H-1-2] 必須包含實作 android.service.vr.VrListenerService 的應用程式，VR 應用程式可透過 android.app.Activity#setVrModeEnabled 啟用該應用程式。

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

• [7.8.2.2/H-1-1] 必須提供以下 HID 代碼的軟體對應：

• [7.8.2.2/H-1-2] 插入插頭時，必須觸發 ACTION_HEADSET_PLUG，但前提是 USB 音訊介面和端點已正確列舉，以便識別所連線的終端機類型。

偵測到 USB 音訊終端機類型 0x0302 時，這些終端機：

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

偵測到 USB 音訊終端機類型 0x0402 時，這些終端機：

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

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

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

• [7.8.2.2/H-4-2] 如果 USB 音訊終端機類型欄位為 0x0402，則 MUST 會列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，且 role isSink()。

• [7.8.2.2/H-4-3] 如果 USB 音訊終端機類型欄位為 0x0402，則 MUST 會列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，且 role 為 isSource()。

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

• [7.8.2.2/H-4-5] 如果 USB 音訊終端機類型欄位為 0x604，則 MUST 會列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置，且 role 為 isSource()。

• [7.8.2.2/H-4-6] 如果 USB 音訊終端機類型欄位為 0x400，則 MUST 會列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置，且 role isSink()。

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

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

2.2.2. 多媒體

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

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

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

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

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

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

2.2.3. 軟體

手持裝置實作方式：

• [3.2.3.1/H-0-1] 必須具備可處理 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT 意圖 的應用程式 (如 SDK 文件所述)，並使用 DocumentsProvider API 提供使用者存取文件供應商資料的功能提示。
• [3.4.1/H-0-1] 必須完整實作 android.webkit.Webview API。
• [3.4.2/H-0-1] 必須提供獨立的瀏覽器應用程式，供一般使用者瀏覽網頁。
• [3.8.1/H-SR] 強烈建議實作支援在應用程式內釘選捷徑、小工具和 widgetFeatures 的預設啟動器。
• [3.8.1/H-SR] 強烈建議實作預設啟動器，透過 ShortcutManager API 快速存取第三方應用程式提供的額外快速鍵。
• [3.8.1/H-SR] 強烈建議加入預設啟動器應用程式，顯示應用程式圖示的徽章。
• [3.8.2/H-SR] 強烈建議支援第三方應用程式小工具。
• [3.8.3/H-0-1] MUST allow third-party apps to notify users of notable events through the Notification and NotificationManager API classes.
• [3.8.3/H-0-2] 必須支援豐富通知。
• [3.8.3/H-0-3] MUST support heads-up notifications.
• [3.8.3/H-0-4] 必須包含通知欄，讓使用者可透過動作按鈕或控制台等使用者功能提示，直接控制通知 (例如回覆、延後、關閉、封鎖)，如 Android 開放原始碼計畫 實作方式所示。
• [3.8.3/H-0-5] MUST display the choices provided through RemoteInput.Builder setChoices() in the notification shade.
• [3.8.3/H-SR] RemoteInput.Builder setChoices()「強烈建議在通知陰影中顯示透過 RemoteInput.Builder setChoices() 提供的第一個選項，使用者不需額外互動。
• [3.8.3/H-SR] RemoteInput.Builder setChoices() 強烈建議在使用者展開通知欄中的所有通知時，於通知欄中顯示所有選項。
• [3.8.3.1/H-SR] Notification.Action.Builder.setContextual 設為 true 的動作「強烈建議」與 Notification.Remoteinput.Builder.setChoices 顯示的回覆內嵌顯示。
• [3.8.4/H-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.

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

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

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

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

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

• [3.9/H-1-1] 必須實作 Android SDK 文件中定義的完整裝置管理政策。
• [3.9/H-1-2] 裝置必須透過 android.software.managed_users 功能旗標宣告支援受管理設定檔，但如果裝置設定為回報自身為低 RAM 裝置，或將內部 (不可移除) 儲存空間分配為共用儲存空間，則不在此限。

手持裝置實作方式：

• [3.10/H-0-1] 必須支援第三方無障礙服務。
• [3.10/H-SR] 強烈建議在裝置上預先載入無障礙服務，這些服務的功能應與TalkBack 開放原始碼專案提供的切換控制功能和 TalkBack 無障礙服務相當或更勝一籌 (適用於預先安裝的文字轉語音引擎支援的語言)。
• [3.11/H-0-1] 必須支援安裝第三方 TTS 引擎。
• [3.11/H-SR] 強烈建議加入支援裝置可用語言的 TTS 引擎。
• [3.13/H-SR] 強烈建議加入「快速設定」UI 元件。

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

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

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

• [7.2.3/H]「首頁」功能的手勢辨識區高度應不超過螢幕底部的 32 dp。

如果手持式裝置實作項目提供導覽功能，可從螢幕左右兩側的任何位置以手勢操作：

• [7.2.3/H-0-1] 導覽功能的手勢區域寬度必須小於兩側各 40 dp。手勢區域的預設寬度應為 24 dp。

2.2.4. 效能和電力

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

手持裝置實作方式：

• [8.2/H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.
• [8.2/H-0-2] 必須確保隨機寫入效能至少為 0.5 MB/s。
• [8.2/H-0-3] 必須確保循序讀取效能至少達到 15 MB/s。
• [8.2/H-0-4] 必須確保隨機讀取效能至少為 3.5 MB/s。

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

• [8.3/H-1-1] 必須提供使用者介面，讓使用者啟用及停用省電功能。
• [8.3/H-1-2] 必須提供使用者介面，顯示所有已排除在「應用程式待機」和「螢幕關閉進入休眠」省電模式外的應用程式。

手持裝置實作方式：

• [8.4/H-0-1] 必須提供每個元件的電力設定檔，定義每個硬體元件的電流消耗值，以及元件隨時間造成的概略電池耗電量，如 Android 開放原始碼計畫網站所述。
• [8.4/H-0-2] 必須以毫安時 (mAh) 報告所有耗電量值。
• [8.4/H-0-3] MUST report CPU power consumption per each process's UID. Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目，滿足這項需求。
• [8.4/H-0-4] 必須透過 adb shell dumpsys batterystats shell 命令，向應用程式開發人員提供這項耗電量資訊。
• [8.4/H] 如果無法將硬體元件耗電量歸因於應用程式，則應將其歸因於硬體元件本身。

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

• [8.4/H-1-1] 必須遵守 android.intent.action.POWER_USAGE_SUMMARY 意圖，並顯示設定選單，其中會顯示耗電量。

2.2.5. 安全模型

手持裝置實作方式：

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

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

• [9.11/H-0-2]* 必須使用獨立的執行環境備份金鑰儲存區實作項目。
• [9.11/H-0-3]*「必須」實作 RSA、AES、ECDSA 和 HMAC 密碼編譯演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離機制「必須」封鎖所有潛在機制，避免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目來滿足這項需求，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當管理程序型隔離安全實作項目。
• [9.11/H-0-4]* MUST 在獨立執行環境中執行螢幕鎖定驗證，且只有在驗證成功時，才允許使用與驗證相關聯的金鑰。螢幕鎖定憑證的儲存方式必須確保只有獨立執行環境可以執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。
• [9.11/H-0-5]* 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。認證簽署金鑰必須在足夠數量的裝置間共用，以防止金鑰做為裝置 ID 使用。如要符合這項規定，除非特定 SKU 的產量至少達到 10 萬部，否則請共用相同的認證金鑰。如果 SKU 的生產數量超過 10 萬個，每 10 萬個單位「可能」會使用不同的金鑰。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除必須具備由獨立執行環境支援的金鑰儲存區，以及支援金鑰認證的要求，除非裝置聲明 android.hardware.fingerprint 功能，而這項功能需要由獨立執行環境支援的金鑰儲存區。

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

• [9.11/H-1-1] 必須允許使用者選擇最短的螢幕逾時時間，也就是從解鎖狀態轉換為鎖定狀態的時間，為 15 秒或更短。
• [9.11/H-1-2] 必須提供使用者選項，隱藏通知並停用所有形式的驗證，但 9.11.1 安全螢幕鎖定畫面所述的主要驗證除外。AOSP 符合鎖定模式的要求。

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

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

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

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

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
  • [6.1/H-0-3]* perfetto 二進位檔必須接受 protobuf 設定做為輸入內容，且該設定必須符合perfetto 文件中定義的結構。
  • [6.1/H-0-4]* perfetto 二進位檔必須將 protobuf 追蹤記錄寫入輸出內容，且該追蹤記錄必須符合perfetto 說明文件中定義的結構定義。
  • [6.1/H-0-5]* 必須透過 perfetto 二進位檔，至少提供perfetto 文件中說明的資料來源。

2.3. 電視需求

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

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

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

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

2.3.1. 硬體

電視裝置實作方式：

• [7.2.2/T-0-1] 必須支援方向鍵。
• [7.2.3/T-0-1] 必須提供「首頁」和「返回」功能。
• [7.2.3/T-0-2] MUST send both the normal and long press event of the Back function (KEYCODE_BACK) to the foreground application.
• [7.2.6.1/T-0-1] 必須支援遊戲控制器，並宣告 android.hardware.gamepad 功能旗標。
• [7.2.7/T] 應提供遙控器，讓使用者可透過遙控器存取非觸控導覽和核心導覽鍵輸入內容。

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

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

電視裝置實作方式：

• [7.4.3/T-0-1] 必須支援藍牙和藍牙低功耗。
• [7.6.1/T-0-1] 必須提供至少 4 GB 的非揮發性儲存空間，供應用程式專用資料使用 (又稱「/data」分割區)。

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

• [7.5.3/T-1-1] MUST include support for an external camera that connects through this USB port but is not necessarily always connected.

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

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

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

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

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

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

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

電視裝置實作方式：

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

2.3.2. 多媒體

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

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

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

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

電視裝置實作方式：

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

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

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

電視裝置實作項目「必須」支援 MPEG-2 解碼，如第 5.3.1 節所述，且支援標準影片影格速率和最高解析度，包括：

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

電視裝置實作項目「必須」支援 H.264 解碼，如第 5.3.4 節所述，且支援標準影片影格速率和最高解析度 (含)：

• [5.3.4/T-1-1] 60 每秒影格數的 HD 1080p 影片，並採用 基準設定檔
• [5.3.4/T-1-2] HD 1080p，每秒 60 個影格，主要設定檔
• [5.3.4/T-1-3] HD 1080p，每秒 60 格，High Profile Level 4.2

電視裝置實作項目必須支援 H.265 解碼，如第 5.3.5 節所述，且須使用 H.265 硬體解碼器，並以標準視訊影格速率和解析度解碼，最高可達：

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

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

• [5.3.5/T-2-1] MUST support the UHD decoding profile at 60 frames per second with Main10 Level 5 Main Tier profile.

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

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

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

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

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

• [5.3.7/T-2-1] MUST support the UHD decoding profile at 60 frames per second with profile 0 (8 bit color depth).
• [5.3.7/T-2-1] 強烈建議支援每秒 60 格的 UHD 解碼設定檔，並採用設定檔 2 (10 位元色深)。

電視裝置實作方式：

• [5.5/T-0-1] 必須支援系統主音量和數位音訊輸出音量衰減 (適用於支援的輸出)，但壓縮音訊直通輸出除外 (裝置不會解碼音訊)。

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

• [5.8/T-0-1] 必須設定 HDMI 輸出模式，選取 50Hz 或 60Hz 重新整理頻率支援的最高解析度。
• [5.8/T-SR] 強烈建議提供使用者可設定的 HDMI 重新整理率選取器。
• [5.8] 應根據裝置銷售地區的影片刷新率，將 HDMI 輸出模式的刷新率設為 50Hz 或 60Hz。

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

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

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

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

2.3.3. 軟體

電視裝置實作方式：

• [3/T-0-1] MUST declare the features android.software.leanback and android.hardware.type.television.
• [3.4.1/T-0-1] 必須完整實作 android.webkit.Webview API。

如果 Android TV 裝置實作項目支援螢幕鎖定，則：

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

電視裝置實作方式：

• [3.8.14/T-SR] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode multi-window.
• [3.10/T-0-1] 必須支援第三方無障礙服務。
• [3.10/T-SR] 裝置「強烈建議」預先載入無障礙服務，這些服務的功能應與TalkBack 開放原始碼專案提供的切換控制和 TalkBack (適用於預先安裝的文字轉語音引擎支援的語言) 無障礙服務相當或更強大。

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

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

電視裝置實作方式：

• [3.12/T-0-1] MUST support TV Input Framework.

2.3.4. 效能和電力

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

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

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

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

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

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

• [8.3/T-1-3] 必須提供使用者介面，顯示所有已排除在「應用程式待機」和「螢幕關閉進入休眠」省電模式外的應用程式。

電視裝置實作方式：

• [8.4/T-0-1] 必須提供每個元件的電源設定檔，定義每個硬體元件的耗電量值，以及元件隨時間造成的電池耗電量概略值，如 Android 開放原始碼計畫網站所述。
• [8.4/T-0-2] 必須以毫安時 (mAh) 回報所有耗電量值。
• [8.4/T-0-3] MUST report CPU power consumption per each process's UID. Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目，滿足這項需求。
• [8.4/T] 如果無法將硬體元件耗電量歸因於應用程式，則應歸因於硬體元件本身。
• [8.4/T-0-4]「必須」透過 adb shell dumpsys batterystats shell 指令，向應用程式開發人員提供這項耗電量資訊。

2.3.5. 安全模型

電視裝置實作方式：

• [9.11/T-0-1] MUST back up the keystore implementation with an isolated execution environment.
• [9.11/T-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離機制「必須」封鎖所有潛在機制，避免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目來滿足這項需求，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當管理程序型隔離安全實作項目。
• [9.11/T-0-3] MUST 在隔離的執行環境中執行螢幕鎖定驗證，且只有在驗證成功時，才允許使用與驗證相關聯的金鑰。螢幕鎖定憑證的儲存方式必須確保只有獨立執行環境可以執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。
• [9.11/T-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。認證簽署金鑰必須在足夠數量的裝置間共用，以防止金鑰做為裝置 ID 使用。如要符合這項規定，除非特定 SKU 的產量至少達到 10 萬部，否則請共用相同的認證金鑰。如果 SKU 的生產數量超過 10 萬個，每 10 萬個單位「可能」會使用不同的金鑰。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除必須具備由獨立執行環境支援的金鑰儲存區，以及支援金鑰認證的要求，除非裝置聲明 android.hardware.fingerprint 功能，而這項功能需要由獨立執行環境支援的金鑰儲存區。

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

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

如果電視裝置實作項目包含多位使用者，但未宣告 android.hardware.telephony 特徵標記，則：

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

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

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

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

電視裝置實作方式：

• Perfetto
  • [6.1/T-0-1] MUST 向殼層使用者公開 /system/bin/perfetto 二進位檔，且 cmdline 符合perfetto 說明文件。
  • [6.1/T-0-2] perfetto 二進位檔必須接受輸入符合perfetto 文件中定義結構定義的 protobuf 設定。
  • [6.1/T-0-3] perfetto 二進位檔必須輸出符合perfetto 說明文件中定義結構定義的 protobuf 追蹤記錄。
  • [6.1/T-0-4] 必須透過 perfetto 二進位檔，至少提供perfetto 說明文件中說明的資料來源。

2.4. 智慧手錶需求

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

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

• 螢幕的實際對角線長度介於 1.1 至 2.5 吋。
• 提供可穿戴在身上的機制。

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

2.4.1. 硬體

觀看裝置實作內容：

• [7.1.1.1/W-0-1] 螢幕的實際對角線尺寸必須介於 1.1 吋至 2.5 吋之間。

• [7.2.3/W-0-1] 必須為使用者提供「首頁」功能，以及「返回」功能 (處於 UI_MODE_TYPE_WATCH 狀態時除外)。

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

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

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

• [7.3.3/W-1-1] 找到 GNSS 測量結果後，必須立即回報，即使尚未回報從 GPS/GNSS 計算出的位置資訊也一樣。
• [7.3.3/W-1-2] 必須回報 GNSS 虛擬距離和虛擬距離速率，在判定位置後，於空曠環境中靜止或以小於每平方秒 0.2 公尺的加速度移動時，至少 95% 的時間內，這些資料足以計算出 20 公尺內的位置，以及 0.2 公尺/秒內的速度。

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

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

觀看裝置實作內容：

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

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

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

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

• [7.8.2/W] MAY but SHOULD NOT have audio output.

2.4.2. 多媒體

沒有其他相關規定。

2.4.3. 軟體

觀看裝置實作內容：

• [3/W-0-1] MUST declare the feature android.hardware.type.watch.
• [3/W-0-2] MUST support uiMode = UI_MODE_TYPE_WATCH。

觀看裝置實作內容：

• [3.8.4/W-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.

查看宣告 android.hardware.audio.output 功能旗標的智慧手錶裝置實作項目：

• [3.10/W-1-1] 必須支援第三方無障礙服務。

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

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

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

2.4.4. 效能和電力

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

• [8.3/W-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all apps that are exempted from App Standby and Doze power-saving modes.
• [8.3/W-SR] 強烈建議提供使用者介面，讓使用者啟用及停用省電模式功能。

觀看裝置實作內容：

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

2.4.5. 安全模型

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

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

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

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

2.5. 車輛相關規定

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

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

• 內建於車輛或可插入車輛。
• 使用駕駛座列的螢幕做為主要螢幕。

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

2.5.1. 硬體

車輛裝置實作方式：

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

• [7.1.1.1/A-0-2] 螢幕尺寸布局必須至少為 750 dp x 480 dp。

• [7.2.3/A-0-1] 必須提供「首頁」功能，且可提供「返回」和「最近」功能。

• [7.2.3/A-0-2] 必須將「返回」功能 (KEYCODE_BACK) 的一般和長按事件都傳送至前景應用程式。
• [7.3/A-0-1] 必須實作並回報 GEAR_SELECTION、NIGHT_MODE、PERF_VEHICLE_SPEED 和 PARKING_BRAKE_ON。
• [7.3/A-0-2] NIGHT_MODE 旗標的值必須與資訊主頁的日/夜間模式一致，且應以環境光感應器輸入內容為依據。底層環境光感應器可能與照度計相同。
• [7.3/A-0-3] 必須為提供的每個感應器，在 SensorAdditionalInfo 中提供感應器額外資訊欄位 TYPE_SENSOR_PLACEMENT。
• [7.3/A-0-1] MAY dead reckon Location by fusing GPS/GNSS with additional sensors. 如果位置是推算而來，強烈建議您實作並回報使用的對應感應器類型和/或車輛屬性 ID。
• [7.3/A-0-2] 透過 LocationManager#requestLocationUpdates() 要求的位置不得與地圖比對。

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

• [7.3.1/A-1-1] 必須能夠回報事件，頻率至少為 100 Hz。
• [7.3.1/A-1-2] 必須符合 Android 車輛感應器座標系統。

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

• [7.3.4/A-2-1] 必須能夠以至少 100 Hz 的頻率回報事件。
• [7.3.4/A-2-2] 也「必須」實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。
• [7.3.4/A-2-3] 必須能夠測量每秒高達 250 度的方向變化。
• [7.3.4/A-SR] 強烈建議將陀螺儀的測量範圍設為 +/-250dps，盡可能提高解析度

車輛裝置實作方式：

• [7.4.3/A-0-1] 必須支援藍牙，且應支援藍牙 LE。

• [7.4.3/A-0-2] Android Automotive 實作項目必須支援下列藍牙設定檔：

  • 透過免持聽筒設定檔 (HFP) 撥打電話。
  • 透過音訊散布設定檔 (A2DP) 播放媒體。
  • 透過遙控器設定檔 (AVRCP) 控制媒體播放。
  • 使用電話簿存取設定檔 (PBAP) 分享聯絡人。

• [7.4.3/A-SR] Are STRONGLY RECOMMENDED to support Message Access Profile (MAP).

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

• [7.4.5/A]「MAY」使用系統 API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常數，適用於系統應用程式可用的網路。

外部檢視攝影機是指可拍攝裝置實作範圍以外場景的攝影機，例如行車記錄器。

車輛裝置實作方式：

• 應包含一或多部外部檢視攝影機。

如果車輛裝置實作項目包含外部視野攝影機，這類攝影機必須：

• [7.5/A-1-1] 除非符合相機核心規定，否則不得透過 Android Camera API 存取外部攝影機。
• [7.5/A-SR] 強烈建議不要旋轉或水平鏡像相機預覽畫面。
• [7.5.5/A-SR] 強烈建議相機的方向應經過調整，讓相機的長邊對齊水平線。
• [7.5/A-SR] 強烈建議解析度至少為 130 萬像素。
• 應具備定焦或 EDOF (擴展景深) 硬體。
• 可能在攝影機驅動程式中實作硬體自動對焦或軟體自動對焦。

車輛裝置實作方式：

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

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

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

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

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

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

  • 小型/一般螢幕的 dpi 為 280 或更低
  • 在特大螢幕上使用 ldpi 或更低的密度
  • 大型螢幕上的 mdpi 或更低

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

  • 小型/一般螢幕的 xhdpi 以上
  • 大型螢幕上的 hdpi 以上
  • 超大螢幕上的 mdpi 以上

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

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

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

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

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

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

  • 小型/一般螢幕的 dpi 為 280 或更低
  • 在特大螢幕上使用 ldpi 或更低的密度
  • 大型螢幕上的 mdpi 或更低

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

  • 小型/一般螢幕的 xhdpi 以上
  • 大型螢幕上的 hdpi 以上
  • 超大螢幕上的 mdpi 以上

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

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

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

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

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

車輛裝置實作方式：

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

車輛裝置實作方式：

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

車輛裝置實作方式：

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

2.5.2. 多媒體

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

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

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

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

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

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

強烈建議汽車裝置實作支援下列影片解碼：

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

2.5.3. 軟體

車輛裝置實作方式：

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

• [3/A-0-2] MUST support uiMode = UI_MODE_TYPE_CAR。

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

• [3.2.1/A-0-1] MUST support and enforce all permissions constants as documented by the Automotive Permission reference page.

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

• [3.8.3/A-0-1] MUST display notifications that use the Notification.CarExtender API when requested by third-party applications.

• [3.8.4/A-SR] 強烈建議在裝置上導入助理，以處理輔助動作。

如果車用裝置導入作業包含「按鈕說話」按鈕，則：

• [3.8.4/A-1-1] 必須使用一按即說按鈕的短按操作，啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式。

車輛裝置實作方式：

• [3.8.3.1/A-0-1] MUST correctly render resources as described in the Notifications on Automotive OS SDK documentation.
• [3.8.3.1/A-0-2] MUST display PLAY and MUTE for notification actions in the place of those provided through Notification.Builder.addAction()
• [3.8.3.1/A] SHOULD 限制使用豐富的管理工作，例如個別通知管道控制項。MAY use UI affordance per application to reduce controls.

車輛裝置實作方式：

• [3.14/A-0-1] 必須包含 UI 架構，支援第三方應用程式使用第 3.14 節所述的媒體 API。
• [3.14/A-0-2] MUST allow the user to safely interact with Media Applications while driving.
• [3.14/A-0-3] MUST support the CAR_INTENT_ACTION_MEDIA_TEMPLATE implicit Intent action with the CAR_EXTRA_MEDIA_PACKAGE extra.
• [3.14/A-0-4] 必須提供進入媒體應用程式偏好設定活動的介面元素，但只有在車輛使用者體驗限制未生效時，才能啟用該介面元素。
• [3.14/A-0-5] 必須顯示媒體應用程式設定的錯誤訊息，且必須支援選用的額外項目 ERROR_RESOLUTION_ACTION_LABEL 和 ERROR_RESOLUTION_ACTION_INTENT。
• [3.14/A-0-6] 支援搜尋功能的應用程式「必須」支援應用程式內搜尋功能提示。
• [3.14/A-0-7] 顯示 MediaBrowser 階層時，必須遵守 CONTENT_STYLE_BROWSABLE_HINT 和 CONTENT_STYLE_PLAYABLE_HINT 定義。

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

• [3.14/A-1-1] MUST include media services and open them with the CAR_INTENT_ACTION_MEDIA_TEMPLATE intent.

車輛裝置實作方式：

• [3.8/A] MAY restrict the application requests to limit the ability to enter a full screen mode as described in immersive documentation.
• [3.8/A] MAY keep the status bar and the navigation bar visible at all times.
• [3.8/A] 可能會限制應用程式要求，以確保系統 UI 元素後方的顏色不會變更，確保這些元素一律清楚可見，詳情請參閱 WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS 和 WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION。

2.5.4. 效能和電力

車輛裝置實作方式：

• [8.2/A-0-1] 必須回報每個程序 UID 讀取和寫入非揮發性儲存空間的位元組數，以便開發人員透過系統 API android.car.storagemonitoring.CarStorageMonitoringManager 取得統計資料。Android 開放原始碼計畫透過 uid_sys_stats 核心模組滿足這項需求。
• [8.3/A-1-3] 車輛關機前，必須至少進入車庫模式一次。
• [8.3/A-1-4] 必須處於車庫模式至少 15 分鐘，除非：
  • 電池沒電。
  • 系統未排定任何閒置工作。
  • 駕駛人結束車庫模式。
• [8.4/A-0-1] 必須提供每個元件的電源設定檔，定義每個硬體元件的耗電量值，以及元件隨時間造成的概略電池耗電量，如 Android 開放原始碼計畫網站所述。
• [8.4/A-0-2] 必須以毫安時 (mAh) 回報所有耗電量值。
• [8.4/A-0-3] MUST report CPU power consumption per each process's UID. Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目，滿足這項需求。
• [8.4/A] 如果無法將硬體元件耗電量歸因於應用程式，則應歸因於硬體元件本身。
• [8.4/A-0-4]「必須」透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供這項耗電量資訊。

2.5.5. 安全模型

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

• [9.5/A-1-1]「不得」允許使用者與無頭系統使用者互動或切換至該使用者，裝置佈建除外。
• [9.5/A-1-2] 必須先切換為「次要使用者」，才能執行 BOOT_COMPLETED。
• [9.5/A-1-3] 即使裝置上的使用者人數已達上限，也必須支援建立訪客使用者。

車輛裝置實作方式：

• [9.11/A-0-1] 必須使用獨立的執行環境備份金鑰儲存區實作。
• [9.11/A-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離機制「必須」封鎖所有潛在機制，避免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目來滿足這項需求，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當管理程序型隔離安全實作項目。
• [9.11/A-0-3] MUST perform the lock screen authentication in the isolated execution environment and only when successful, allow the authentication-bound keys to be used. 螢幕鎖定憑證的儲存方式必須確保只有獨立執行環境可以執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。
• [9.11/A-0-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。認證簽署金鑰必須在足夠數量的裝置間共用，以防止金鑰做為裝置 ID 使用。如要符合這項規定，除非特定 SKU 的產量至少達到 10 萬部，否則請共用相同的認證金鑰。如果 SKU 的生產數量超過 10 萬個，每 10 萬個單位「可能」會使用不同的金鑰。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除必須具備由獨立執行環境支援的金鑰儲存區，以及支援金鑰認證的要求，除非裝置聲明 android.hardware.fingerprint 功能，而這項功能需要由獨立執行環境支援的金鑰儲存區。

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

• [9.11/A-1-1] 必須允許使用者選擇從解鎖狀態轉換為鎖定狀態的睡眠逾時時間，且允許的逾時時間下限為 15 秒或更短。

車輛裝置實作方式：

• [9.14/A-0-1] MUST 控管來自 Android 架構車輛子系統的訊息，例如允許使用許可的訊息類型和訊息來源。
• [9.14/A-0-2] MUST watchdog against denial of service attacks from the Android framework or third-party apps. 這項措施可防範惡意軟體以大量流量淹沒車輛網路，導致車輛子系統故障。

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

車輛裝置實作方式：

• Perfetto
  • [6.1/A-0-1] MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
  • [6.1/A-0-2] perfetto 二進位檔必須接受符合perfetto 說明文件中定義結構定義的 protobuf 設定做為輸入內容。
  • [6.1/A-0-3] perfetto 二進位檔必須輸出符合perfetto 文件中定義結構定義的 protobuf 追蹤記錄。
  • [6.1/A-0-4] 必須透過 perfetto 二進位檔，提供至少perfetto 說明文件中描述的資料來源。

2.6. 平板電腦需求

Android 平板電腦裝置是指符合下列所有條件的 Android 裝置實作項目：

• 通常雙手握住使用。
• 不具備貝殼式或可轉換的配置。
• 與裝置搭配使用的任何實體鍵盤都必須透過標準連線方式連線。
• 具有可提供移動性的電源，例如電池。
• 實體對角線螢幕尺寸介於 7 到 18 吋。

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

2.6.1. 硬體

螢幕大小

• [7.1.1.1/Tab-0-1] 螢幕尺寸必須介於 7 到 18 吋。

陀螺儀

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

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

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

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

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

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

• [7.7.1/Tab] MAY implement the Android Open Accessory (AOA) API.

虛擬實境模式 (第 7.9.1 節)

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

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

2.6.2. 安全模型

金鑰和憑證 (第 9.11 節)

請參閱第 [9.11] 節。

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

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

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

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

3. 軟體

3.1. 管理 API 相容性

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

裝置實作方式：

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

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

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

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

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

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

  不過，這些帳戶：

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

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

3.1.1. Android 擴充功能

Android 支援擴充受管理 API，同時維持相同的 API 級別版本。

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

3.1.2. Android 程式庫

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

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

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

3.2. 軟體 API 相容性

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

3.2.1. 權限

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

3.2.2. 建構參數

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

• [C-0-1] 為確保裝置實作項目提供一致且有意義的值，下表列出這些值的格式的其他限制，裝置實作項目「必須」符合這些限制。

3.2.3. 意圖相容性

3.2.3.1. 核心應用程式意圖

Android 意圖可讓應用程式元件向其他 Android 元件要求功能。Android 上游專案包含一份清單，列出視為 Android 核心應用程式的應用程式，這些應用程式會實作多種意圖模式，以執行常見動作。

• [C-0-1] 裝置實作項目「必須」預先載入一或多個應用程式或服務元件，並搭配意圖處理常式，適用於 AOSP 中下列核心 Android 應用程式定義的所有公開意圖篩選器模式：

  • 桌上時鐘
  • 瀏覽器
  • 日曆
  • 聯絡人
  • 錶面圖庫
  • GlobalSearch
  • 啟動器
  • 音樂
  • 設定

3.2.3.2. 意圖解析

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

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

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

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

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

• [C-0-4] MUST attempt to validate any intent filters by performing the validation steps defined in the Digital Asset Links specification as implemented by the Package Manager in the upstream Android Open Source Project.
• [C-0-5] MUST attempt validation of the intent filters during the installation of the application and set all successfully validated URI intent filters as default app handlers for their URIs.
• 如果特定 URI 意圖篩選器通過驗證，但其他候選 URI 篩選器驗證失敗，MAY 可將特定 URI 意圖篩選器設為 URI 的預設應用程式處理常式。如果裝置實作這項功能，就必須在設定選單中為使用者提供適當的 URI 模式覆寫。
• 必須在「設定」中提供應用程式連結控制項，讓使用者逐一設定應用程式，如下所示：
  • [C-0-6] 使用者「必須」能夠全面覆寫應用程式的預設應用程式連結行為，讓應用程式一律開啟、一律詢問或永不開啟，且「必須」同樣適用於所有候選 URI 意圖篩選器。
  • [C-0-7] 使用者必須能夠查看候選 URI 意圖篩選器清單。
  • 裝置實作「可能」會讓使用者逐一覆寫已成功驗證的特定候選 URI 意圖篩選器。
  • [C-0-8] 如果裝置實作可讓部分候選 URI 意圖篩選器通過驗證，但其他篩選器則無法通過，裝置實作「必須」提供使用者檢視及覆寫特定候選 URI 意圖篩選器的功能。

3.2.3.3. 意圖命名空間

• [C-0-1] 裝置實作「不得」包含任何 Android 元件，這些元件會使用 android. 或 com.android. 命名空間中的 ACTION、CATEGORY 或其他鍵字串，遵守任何新的意圖或廣播意圖模式。
• [C-0-2] 裝置實作者不得在屬於其他機構的套件空間中，納入任何會使用 ACTION、CATEGORY 或其他鍵字串，遵守任何新意圖或廣播意圖模式的 Android 元件。
• [C-0-3] 裝置實作人員不得變更或擴充第 3.2.3.1 節所列核心應用程式使用的任何意圖模式。
• 裝置實作項目「可以」包含使用命名空間的意圖模式，這些命名空間明顯與自家機構相關聯。這項禁令與第 3.6 節中針對 Java 語言類別指定的禁令類似。

3.2.3.4. 廣播意圖

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

裝置實作方式：

• [C-0-1] 必須根據 SDK 說明文件，在適當的系統事件發生時，播送公開的廣播意圖。請注意，這項規定與第 3.5 節並不衝突，因為 SDK 文件中也說明瞭背景應用程式的限制。

3.2.3.5. 預設應用程式設定

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

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

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

• [C-1-1] MUST honor the android.settings.HOME_SETTINGS intent to show a default app settings menu for Home Screen.

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

• [C-2-1] 必須提供設定選單，呼叫含有 RoleManager.ROLE_SMS 的 RoleManager.createRequestRoleIntent(String) 意圖，顯示變更預設簡訊應用程式的對話方塊。

• [C-2-2] 必須遵守 android.telecom.action.CHANGE_DEFAULT_DIALER 意圖，顯示對話方塊，讓使用者變更預設的「電話」應用程式。

  • 除了緊急電話外，撥打和接聽電話時，都必須使用使用者選取的預設「電話」應用程式 UI，緊急電話則會使用預先安裝的「電話」應用程式。

• [C-2-3] 必須遵守 android.telecom.action.CHANGE_PHONE_ACCOUNTS 意圖，讓使用者設定與 PhoneAccounts 相關聯的 ConnectionServices，以及電信服務供應商用於撥出電話的預設 PhoneAccount。AOSP 實作方式是在「通話」設定選單中加入「通話帳戶選項」選單，以符合這項規定。

• [C-2-4] 應用程式具備 android.app.role.CALL_REDIRECTION 角色時，必須允許 android.telecom.CallRedirectionService。

• [C-2-5] MUST provide the user affordance to choose an app that holds the android.app.role.CALL_REDIRECTION role.

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

• [C-3-1] 必須遵守 android.settings.NFC_PAYMENT_SETTINGS 意圖，顯示感應支付的預設應用程式設定選單。

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

• [C-4-1] 必須接受 android.settings.ACTION_VOICE_INPUT_SETTINGS 意圖，顯示語音輸入和輔助功能的預設應用程式設定選單。

3.2.4. 在第二個/多個螢幕上進行活動

如果裝置實作項目允許在多個螢幕上啟動一般 Android 活動，則：

• [C-1-1] 必須設定 android.software.activities_on_secondary_displays 功能旗標。
• [C-1-2] MUST guarantee API compatibility similar to an activity running on the primary display.
• [C-1-3] 如果啟動新活動時未透過 ActivityOptions.setLaunchDisplayId() API 指定目標螢幕，新活動必須與啟動活動的螢幕相同。
• [C-1-4] 移除 Display.FLAG_PRIVATE 旗標時，必須終止所有活動。
• [C-1-5] 裝置鎖定時，如果使用安全螢幕鎖定功能，應用程式必須在所有螢幕上安全地隱藏內容，除非應用程式使用 Activity#setShowWhenLocked() API 選擇在鎖定畫面上顯示內容。
• 如果活動是在次要螢幕上啟動，則「應該」要有與該螢幕對應的 android.content.res.Configuration，才能正確顯示及運作，並維持相容性。

如果裝置實作項目允許在第二個螢幕上啟動一般 Android 活動，且第二個螢幕具有 android.view.Display.FLAG_PRIVATE 旗標：

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

3.3. 原生 API 相容性

原生程式碼的相容性是個難題。因此，裝置實作人員：

• [SR] 強烈建議使用上游 Android 開放原始碼計畫中列出的程式庫實作項目。

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

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

裝置實作方式：

• [C-0-1] 必須與一或多個已定義的 ABI 相容，並實作 Android NDK 的相容性。
• [C-0-2] 必須支援在受管理環境中執行的程式碼，使用標準 Java Native Interface (JNI) 語意呼叫原生程式碼。
• [C-0-3] 必須與下列清單中的每個必要程式庫來源相容 (即標頭相容)，且與 ABI 二進位檔相容。
• [C-0-5] 裝置必須透過 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 參數，準確回報支援的原生應用程式二進位檔介面 (ABI)，每個參數都是以半形逗號分隔的 ABI 清單，並依偏好程度排序，最偏好的 ABI 排在最前面。

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

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (AAudio 原生音訊支援)

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

• [C-0-8] 不得新增或移除上述原生程式庫的公開函式。

• [C-0-9] MUST list additional non-AOSP libraries exposed directly to third-party apps in /vendor/etc/public.libraries.txt.
• [C-0-10] 針對 API 級別 24 以上版本的第三方應用程式，不得公開任何其他原生程式庫 (在 AOSP 中實作並以系統程式庫形式提供)，因為這些程式庫受到保留。
• [C-0-11] 必須透過 libGLESv3.so 程式庫，匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android 擴充套件函式符號。請注意，所有符號都「必須」存在，但第 7.1.4.1 節會更詳細說明何時需要完整實作每個對應函式。
• [C-0-12] 必須透過 libvulkan.so 程式庫匯出核心 Vulkan 1.0 函式符號，以及 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 擴充功能的函式符號。請注意，所有符號都「必須」存在，但第 7.1.4.2 節會更詳細說明何時應完整實作每個對應函式。
• 應使用上游 Android 開放原始碼計畫提供的原始碼和標頭檔建構

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

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

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

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

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

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

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

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

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

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

3.4. 網站相容性

3.4.1. WebView 相容性

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

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

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

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

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

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

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

請注意，如果裝置實作項目為 32 位元，或宣告功能旗標 android.hardware.ram.low，則可免除 C-1-3。

3.4.2. 瀏覽器相容性

如果裝置實作包含用於一般網頁瀏覽的獨立瀏覽器應用程式，則：

• [C-1-1] 必須支援與 HTML5 相關的各項 API：
  • 應用程式快取/離線作業
  • <video> 標記
  • geolocation
• [C-1-2] 必須支援 HTML5/W3C webstorage API，且應支援 HTML5/W3C IndexedDB API。請注意，由於網頁開發標準機構正在轉移，以 IndexedDB 取代網頁儲存空間，因此 IndexedDB 預計會在日後的 Android 版本中成為必要元件。
• MAY 會在獨立的 Browser 應用程式中傳送自訂使用者代理程式字串。
• 應盡可能在獨立瀏覽器應用程式中導入 HTML5 支援功能 (無論是根據上游 WebKit 瀏覽器應用程式或第三方替代項目)。

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

• [C-2-1] 仍須支援第 3.2.3.1 節所述的公開意圖模式。

3.5. API 行為相容性

裝置實作方式：

• [C-0-9] MUST 確保所有已安裝的應用程式都套用 API 行為相容性，除非這些應用程式受到限制 (如第 3.5.1 節所述)。
• [C-0-10] MUST NOT implement the allowlisting approach that ensures API behavioral compatibility only for apps that are selected by device implementers.

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

• [C-0-1] 裝置「不得」變更標準意圖的行為或語意。
• [C-0-2] 裝置不得變更特定類型系統元件 (例如服務、活動、ContentProvider 等) 的生命週期或生命週期語意。
• [C-0-3] 裝置「不得」變更標準權限的語意。
• 裝置「不得」變更對背景應用程式強制執行的限制。具體來說，如果是背景應用程式：
  • [C-0-4] 必須停止執行應用程式註冊的回呼，以接收 GnssMeasurement 和 GnssNavigationMessage 的輸出內容。
  • [C-0-5] 透過 LocationManager API 類別或 WifiManager.startScan() 方法提供給應用程式的更新頻率「必須」受到速率限制。
  • [C-0-6] 如果應用程式指定 API 級別 25 以上版本，則除非廣播意圖需要 "signature" 或 "signatureOrSystem" protectionLevel 權限，或位於豁免清單中，否則應用程式資訊清單中不得註冊標準 Android 意圖的隱含廣播接收器。
  • [C-0-7] 如果應用程式指定 API 級別 25 以上版本，系統「必須」停止應用程式的背景服務，就像應用程式已呼叫服務的 stopSelf() 方法一樣，除非應用程式已加入暫時允許清單，可處理使用者可見的工作。
  • [C-0-8] 如果應用程式指定 API 級別 25 以上版本，則必須釋出應用程式持有的喚醒鎖定。
• [C-0-9] 裝置必須從 Security.getProviders() 方法傳回下列安全防護供應商，做為前七個陣列值，且順序和名稱 (由 Provider.getName() 傳回) 和類別必須與下表相同，除非應用程式已透過 insertProviderAt() 或 removeProvider() 修改清單。裝置「可能」會在下方指定的供應商清單後，傳回其他供應商。
  1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

請注意，此處僅為列舉，並未包含所有資訊。Compatibility Test Suite (CTS) 會測試平台的重要部分，確保行為相容性，但並非所有部分。實作人員有責任確保行為與 Android 開放原始碼計畫相容。因此，裝置實作人員應盡可能使用 Android 開放原始碼計畫提供的原始碼，而非重新實作系統的重要部分。

3.5.1. 背景活動限制

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

• [C-1-1] 必須提供使用者功能提示，讓使用者查看受限應用程式清單。
• [C-1-2] 必須提供使用者介面，讓使用者開啟 / 關閉各個應用程式的限制。
• [C-1-3] 如無系統健康狀態不良的證據，不得自動套用限制，但偵測到系統健康狀態不良 (例如喚醒鎖定卡住、服務長時間執行等) 時，可對應用程式套用限制。裝置實作者「可以」決定條件，但條件「必須」與應用程式對系統健康狀態的影響有關。不得使用與系統健康狀態無關的其他條件，例如應用程式在市場上缺乏人氣。
• [C-1-4] 如果使用者手動關閉應用程式限制，裝置「不得」自動套用應用程式限制，但「可以」建議使用者套用應用程式限制。
• [C-1-5] 如果系統自動對應用程式套用限制，必須通知使用者。
• [C-1-6] 受限應用程式呼叫此 API 時，必須傳回 true 做為 ActivityManager.isBackgroundRestricted()。
• [C-1-7] 不得限制使用者明確使用的頂層前景應用程式。
• [C-1-8] 如果使用者明確開始使用受限應用程式，且該應用程式成為最上層的前景應用程式，則 MUST 暫停對該應用程式的限制。

3.6. API 命名空間

Android 遵循 Java 程式設計語言定義的套件和類別命名空間慣例。為確保與第三方應用程式相容，裝置實作者「不得」對下列套件命名空間進行任何禁止的修改 (見下文)：

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

也就是說，這些使用者：

• [C-0-1] 不得變更任何方法或類別簽章，也不得移除類別或類別欄位，藉此修改 Android 平台上公開的 API。
• [C-0-2] 不得在上述命名空間的 API 中，加入任何公開顯示的元素 (例如類別或介面，或是現有類別或介面的欄位或方法)，或測試或系統 API。「公開公開的元素」是指未以「@hide」標記裝飾的任何建構函式，如上游 Android 原始碼所用。

裝置實作人員「可以」修改 API 的基礎實作方式，但這類修改：

• [C-0-3] 不得影響任何公開 API 的聲明行為和 Java 語言簽章。
• [C-0-4] 不得向開發人員宣傳或以其他方式揭露。

不過，裝置實作人員「可以」在標準 Android 命名空間以外新增自訂 API，但自訂 API：

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

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

請注意，上述限制符合 Java 程式設計語言中命名 API 的標準慣例；本節僅旨在強化這些慣例，並透過納入本相容性定義，使這些慣例具有約束力。

3.7. 執行階段相容性

裝置實作方式：

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

• [C-0-2] MUST configure Dalvik runtimes to allocate memory in accordance with the upstream Android platform, and as specified by the following table. (如需螢幕大小和螢幕密度的定義，請參閱第 7.1.1 節)。

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

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

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

3.8. 使用者介面相容性

3.8.1. 啟動器 (主畫面)

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

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

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

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

• [C-2-1] MUST report true for ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] 必須提供使用者介面，在透過 ShortcutManager.requestPinShortcut() API 方法新增應用程式要求的捷徑前，先徵求使用者同意。
• [C-2-3] 必須支援固定捷徑，以及「應用程式捷徑」頁面中記錄的動態和靜態捷徑。

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

• [C-3-1] MUST report false for ShortcutManager.isRequestPinShortcutSupported().

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

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

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

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

3.8.2. 小工具

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

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

• [C-1-1] 必須宣告支援平台功能 android.software.app_widgets。
• [C-1-2] 必須內建支援 AppWidget，並提供使用者介面，讓使用者直接在啟動器中新增、設定、查看及移除 AppWidget。
• [C-1-3] MUST be capable of rendering widgets that are 4 x 4 in the standard grid size. 詳情請參閱 Android SDK 說明文件中的「應用程式小工具設計指南」。
• 可能支援在螢幕鎖定畫面上顯示應用程式小工具。

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

• [C-2-1] MUST report true for AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] 必須提供使用者介面，在透過 AppWidgetManager.requestPinAppWidget() API 方法新增應用程式要求的捷徑前，先徵求使用者同意。

3.8.3. 通知

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

3.8.3.1. 通知顯示方式

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

• [C-1-1] 必須支援使用硬體功能的通知，如 SDK 說明文件所述，並盡可能搭配裝置實作硬體。舉例來說，如果裝置實作項目包含震動器，就「必須」正確實作震動 API。如果裝置實作缺少硬體，對應的 API 必須實作為空運算。詳情請參閱第 7 節。
• [C-1-2] 必須正確算繪 API 或狀態/系統列圖示樣式指南中提供的所有資源 (圖示、動畫檔案等)，但可提供與 Android 開放原始碼實作參照不同的通知使用者體驗。
• [C-1-3] 必須遵守並正確實作這些 API 所述的行為，才能更新、移除及分組通知。
• [C-1-4] 必須提供 SDK 中記錄的 NotificationChannel API 完整行為。
• [C-1-5] 必須提供使用者介面，讓使用者能依據管道和應用程式套件層級，封鎖及修改特定第三方應用程式的通知。
• [C-1-6] MUST also provide a user affordance to display deleted notification channels.
• [C-1-7] MUST correctly render all resources (images, stickers, icons, etc.) provided through Notification.MessagingStyle alongside the notification text without additional user interaction. 舉例來說，透過 setGroupConversation 設定的群組對話中，必須顯示所有資源，包括透過 android.app.Person 提供的圖示。
• [C-SR] 強烈建議在使用者多次關閉特定第三方應用程式的通知後，自動顯示使用者可用的選項，讓使用者封鎖該應用程式在每個管道和應用程式套件層級的通知。
• 應支援複合式通知。
• SHOULD 將部分優先順序較高的通知顯示為抬頭通知。
• SHOULD have a user affordance to snooze notifications.
• MAY 只能管理第三方應用程式何時可通知使用者重要事件，以減輕駕駛人分心等安全問題。

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

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

如果裝置實作支援抬頭通知，則：

• [C-3-1] 顯示抬頭通知時，必須使用 Notification.Builder API 類別所述的抬頭通知檢視區塊和資源。
• [C-3-2] 必須一併顯示透過 Notification.Builder.addAction() 提供的動作和通知內容，且不需要額外的使用者互動，如 SDK 所述。

3.8.3.2. 通知接聽器服務

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

如果裝置實作項目回報了 android.hardware.ram.normal 功能旗標，則：

• [C-1-1] MUST correctly and promptly update notifications in their entirety to all such installed and user-enabled listener services, including any and all metadata attached to the Notification object.
• [C-1-2] 必須遵守 snoozeNotification() API 呼叫，並在 API 呼叫中設定的暫緩時間過後，關閉通知並進行回呼。

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

• [C-2-1] 必須透過 NotificationListenerService.getSnoozedNotifications() 等標準 API 正確反映已暫緩通知的狀態。
• [C-2-2] 除非通知來自持續性/前景服務，否則「必須」提供這項使用者功能，讓使用者暫緩接收各個已安裝第三方應用程式的通知。

3.8.3.3. DND (零打擾)

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

• [C-1-1] 必須實作活動，以回應 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS 意圖。如果是 UI_MODE_TYPE_NORMAL 實作項目，則必須是使用者可授予或拒絕應用程式存取「請勿打擾」政策設定的活動。
• [C-1-2] 裝置實作方式必須提供使用者授權或拒絕第三方應用程式存取「請勿打擾」政策設定的方法，並顯示應用程式建立的「自動請勿打擾規則」，以及使用者建立和預先定義的規則。
• [C-1-3] 必須遵守透過 NotificationManager.Policy 傳遞的 suppressedVisualEffects 值，且如果應用程式已設定任何 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 旗標，則應在「請勿打擾」設定選單中向使用者指出視覺效果已遭停用。

3.8.4. 搜尋

Android 包含多項 API，可供開發人員在應用程式中加入搜尋功能，並將應用程式資料公開到全域系統搜尋中。一般來說，這項功能包含單一系統層級的使用者介面，可供使用者輸入查詢內容、在輸入時顯示建議，以及顯示結果。開發人員可以透過 Android API 重複使用這個介面，在自己的應用程式中提供搜尋功能，並將結果提供給通用的全域搜尋使用者介面。

• Android 裝置實作內容「應」包含全域搜尋功能，也就是單一的系統共用搜尋使用者介面，能夠即時建議使用者輸入內容。

如果裝置實作項目實作了全域搜尋介面，則：

• [C-1-1] MUST implement the APIs that allow third-party applications to add suggestions to the search box when it is run in global search mode.

如果沒有安裝任何使用全域搜尋的第三方應用程式：

• 預設行為應為顯示網頁搜尋引擎結果和建議。

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

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

• [C-2-1] 必須清楚向使用者說明情境資訊的分享時機，方法如下：
  • 每次小幫手應用程式存取內容時，螢幕邊緣都會顯示白光，且持續時間和亮度符合或超過 Android 開放原始碼專案的實作方式。
  • 對於預先安裝的小幫手應用程式，提供使用者可透過少於兩次導覽，存取預設語音輸入和小幫手應用程式設定選單的功能提示，且僅在使用者透過啟動字詞或小幫手導覽鍵輸入明確叫用小幫手應用程式時，分享相關資訊。
• [C-2-2] 如第 7.2.3 節所述，啟動小幫手應用程式的指定互動「必須」啟動使用者選取的小幫手應用程式，也就是實作 VoiceInteractionService 的應用程式，或是處理 ACTION_ASSIST 意圖的活動。

3.8.5. 快訊和 Toast

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

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

• [C-1-1] 必須提供使用者介面，讓使用者封鎖應用程式顯示使用 TYPE_APPLICATION_OVERLAY 的警示視窗。AOSP 實作會在通知欄中提供控制項，以滿足這項需求。

• [C-1-2] 必須遵守 Toast API，並以顯眼的方式向使用者顯示應用程式的 Toast。

3.8.6. 主題

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

Android 包含「Holo」和「Material」主題系列，應用程式開發人員可使用這組定義的樣式，配合 Android SDK 定義的 Holo 主題外觀和風格。

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

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

Android 也包含「裝置預設」主題系列，其中定義了一組樣式，應用程式開發人員可使用這些樣式，配合裝置實作人員定義的裝置主題外觀和風格。

• 裝置實作項目「可能」會修改向應用程式公開的裝置預設主題屬性。

Android 支援半透明系統資訊列的變體主題，應用程式開發人員可使用應用程式內容填滿狀態列和導覽列後方的區域。為確保這種設定下的開發人員體驗一致，請務必在不同裝置實作中維持狀態列圖示樣式。

如果裝置實作項目包含系統狀態列，則：

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

3.8.7. 動態桌布

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

如果硬體能以合理的影格率執行所有動態桌布，且不會對其他應用程式造成負面影響，也不會限制功能，即視為可穩定執行動態桌布。如果硬體限制導致桌布和/或應用程式當機、故障、消耗過多 CPU 或電池電力，或是以無法接受的低畫面更新率執行，則硬體會被視為無法執行動態桌布。舉例來說，部分動態桌布可能會使用 OpenGL 2.0 或 3.x 環境轉譯內容。如果硬體不支援多個 OpenGL 環境，動態桌布就無法穩定運作，因為動態桌布使用的 OpenGL 環境可能會與其他應用程式使用的 OpenGL 環境衝突。

• 如上所述，如果裝置實作項目能夠穩定執行動態桌布，就「應該」實作動態桌布。

如果裝置實作項目實作動態桌布，則：

• [C-1-1] MUST report the platform feature flag android.software.live_wallpaper.

3.8.8. 切換活動

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

裝置實作項目 (包括「最近」功能導覽鍵，詳情請參閱第 7.2.3 節)「可能」會變更介面。

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

• [C-1-1] 必須支援至少 7 項顯示的活動。
• SHOULD at least display the title of 4 activities at a time.
• [C-1-2] 必須實作螢幕固定行為，並提供設定選單供使用者切換這項功能。
• 「最近」畫面應顯示醒目顯示顏色、圖示和畫面標題。
• 「應該」顯示關閉功能提示 (「x」)，但「可以」延遲顯示，直到使用者與畫面互動為止。
• SHOULD 實作快速鍵，方便切換至上一個活動。
• SHOULD 在輕觸兩次「最近使用的應用程式」功能鍵時，觸發最近使用的兩個應用程式之間的快速切換動作。
• 如果支援，長按「最近使用」功能鍵「應」會觸發分割畫面多視窗模式。
• 可將相關的近期活動顯示為一組，並一起移動。
• [SR] 強烈建議使用上游 Android 使用者介面 (或類似的縮圖介面) 做為總覽畫面。

3.8.9. 輸入管理

Android 支援輸入管理和第三方輸入法編輯器。

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

• [C-1-1] 必須宣告平台功能 android.software.input_methods，並支援 Android SDK 說明文件中定義的 IME API。
• [C-1-2] MUST provide a user-accessible mechanism to add and configure third-party input methods in response to the android.settings.INPUT_METHOD_SETTINGS intent.

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

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

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

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

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

Android 支援互動式螢幕保護程式 (舊稱「夢幻螢幕保護程式」)。當裝置接上電源、處於閒置狀態或固定在桌面底座上時，使用者可以透過螢幕保護程式與應用程式互動。Android Watch 裝置「可以」實作螢幕保護程式，但其他類型的裝置實作「應」支援螢幕保護程式，並提供設定選項，讓使用者因應 android.settings.DREAM_SETTINGS 意圖設定螢幕保護程式。

3.8.12. Location

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

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

3.8.13. Unicode 和字型

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

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

• [C-1-1] 必須能夠以彩色字形呈現這些表情符號字元。
• [C-1-2] 必須支援：
  • Roboto 2 字型，具有不同粗細的字體，包括 sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light，適用於裝置支援的語言。
  • 完整涵蓋 Unicode 7.0 的拉丁文、希臘文和西里爾文，包括拉丁文擴充 A、B、C 和 D 範圍，以及 Unicode 7.0 貨幣符號區塊中的所有字形。
• 應支援 Unicode 技術報告 #51 中指定的膚色和多元家庭表情符號。

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. 多視窗模式

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

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

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

• [C-2-1] 必須預先載入可調整大小的啟動器做為預設值。
• [C-2-2] 如果啟動器應用程式是焦點視窗，則必須裁剪分割畫面多視窗模式的停駐活動，但應顯示部分內容。
• [C-2-3] MUST honor the declared AndroidManifestLayout_minWidth and AndroidManifestLayout_minHeight values of the third-party launcher application and not override these values in the course of showing some content of the docked activity.

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

• [C-3-1] 應用程式必須在子母畫面多視窗模式中啟動活動，條件如下：* 目標 API 級別為 26 以上，且宣告 android:supportsPictureInPicture。* 目標 API 級別為 25 以下，且同時宣告 android:resizeableActivity 和 android:supportsPictureInPicture。
• [C-3-2] 必須透過 setActions() API，在 SystemUI 中公開目前子母畫面活動指定的操作。
• [C-3-3] 必須支援大於或等於 1:2.39 且小於或等於 2.39:1 的長寬比，如 PIP 活動透過 setAspectRatio() API 指定。
• [C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如果未實作子母畫面模式，則必須讓前景活動使用該鍵。
• [C-3-5] 必須提供使用者功能提示，讓使用者封鎖應用程式在子母畫面模式中顯示；AOSP 實作方式符合這項規定，因為通知欄中含有控制項。
• [C-3-6] Configuration.uiMode 設為 UI_MODE_TYPE_TELEVISION 時，必須為子母畫面視窗分配至少 108 dp 的寬度和高度，以及至少 240 dp 的寬度和 135 dp 的高度。

3.8.15. 螢幕凹口

Android 支援螢幕凹口，詳情請參閱 SDK 文件。DisplayCutout API 會定義螢幕邊緣的區域，這個區域無法顯示內容。

如果裝置實作項目包含螢幕凹口，則：

• [C-1-1] 裝置短邊只能有凹口。反之，如果裝置的顯示比例為 1.0 (1:1)，則「絕對不能」有凹口。
• [C-1-2] 每條邊緣最多只能有一個凹口。
• [C-1-3] 必須遵守應用程式透過 WindowManager.LayoutParams API 設定的螢幕凹口標記，如 SDK 所述。
• [C-1-4] 必須回報 DisplayCutout API 中定義的所有凹口指標的正確值。

3.9. 裝置管理

Android 包含多項功能，可讓注重安全性的應用程式透過 Android 裝置管理 API，在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端清除作業。

如果裝置實作項目實作 Android SDK 文件中定義的完整裝置管理政策，則：

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

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

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

• [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為裝置擁有者應用程式，如下所述：
  • 如果裝置實作尚未設定任何使用者資料，則：
    • [C-1-3] MUST report true for DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)。
    • [C-1-4] MUST enroll the DPC application as the Device Owner app in response to the intent action android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] 如果裝置透過功能標記 android.hardware.nfc 宣告支援近距離無線通訊 (NFC)，且收到含有 MIME 類型為 MIME_TYPE_PROVISIONING_NFC 記錄的 NFC 訊息，則必須將 DPC 應用程式註冊為裝置擁有者應用程式。
  • 如果裝置實作項目包含使用者資料，則：
    • [C-1-6] MUST report false for the DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] 不得再將任何 DPC 應用程式註冊為裝置擁有者應用程式。
• [C-1-2] 在佈建程序中，必須要求使用者採取確認動作，同意將應用程式設為裝置擁有者。同意聲明可透過使用者動作或在佈建期間以程式輔助方式提供，但不得硬式編碼，也不得妨礙使用其他裝置擁有者應用程式。

如果裝置實作項目宣告 android.software.device_admin，但同時包含專屬的裝置擁有者管理解決方案，並提供機制，將解決方案中設定的應用程式升級為「裝置擁有者等同項目」，以符合標準 Android DevicePolicyManager API 認可的標準「裝置擁有者」，則：

• [C-2-1] 必須制定程序，確認宣傳的特定應用程式屬於正當的企業裝置管理解決方案，且已在專有解決方案中設定，具備等同於「裝置擁有者」的權限。
• [C-2-2] 註冊 DPC 應用程式為「裝置擁有者」前，必須顯示與 android.app.action.PROVISION_MANAGED_DEVICE 啟動流程相同的 AOSP 裝置擁有者同意聲明揭露事項。
• 在將 DPC 應用程式註冊為「裝置擁有者」之前，裝置上可能已有使用者資料。

3.9.1.2 受管理設定檔佈建

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

• [C-1-1] MUST implement the APIs allowing a Device Policy Controller (DPC) application to become the owner of a new Managed Profile.

• [C-1-2] 受管理設定檔佈建程序 (使用者透過 android.app.action.PROVISION_MANAGED_PROFILE 啟動的流程) 必須與 AOSP 實作項目一致。

• [C-1-3] 必須在「設定」中提供下列使用者功能，向使用者指出特定系統功能已遭裝置政策控制器 (DPC) 停用：

  • 使用一致的圖示或其他使用者功能提示 (例如上游 Android 開放原始碼計畫 資訊圖示)，表示特定設定受到裝置管理員限制。
  • 裝置管理員透過 setShortSupportMessage 提供的簡短說明訊息。
  • DPC 應用程式的圖示。

3.9.2 支援受管理設定檔

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

• [C-1-1] 必須支援透過 android.app.admin.DevicePolicyManager API 管理的設定檔。
• [C-1-2] 必須允許建立一個且僅一個受管理設定檔。
• [C-1-3] 必須使用圖示徽章 (類似於 AOSP 上游工作徽章)，代表受管理應用程式和 Widget，以及其他帶有徽章的 UI 元素，例如「最近使用的應用程式」和「通知」。
• [C-1-4] 必須顯示通知圖示 (類似於 AOSP 上游工作徽章)，指出使用者何時位於受管理設定檔應用程式中。
• [C-1-5] 裝置喚醒 (ACTION_USER_PRESENT) 時，如果前景應用程式位於受管理設定檔中，就必須顯示浮動式訊息，指出使用者位於受管理設定檔。
• [C-1-6] 如果有受管理設定檔，則必須在 Intent「選擇器」中顯示視覺提示，讓使用者將 Intent 從受管理設定檔轉送至主要使用者，或反向轉送，前提是裝置政策控制器已啟用這項功能。
• [C-1-7] 如果有受管理設定檔，則必須為主要使用者和受管理設定檔提供下列使用者功能：
  • 主要使用者和受管理設定檔的電池、位置資訊、行動數據和儲存空間用量會分開計算。
  • 獨立管理主要使用者或受管理設定檔中安裝的 VPN 應用程式。
  • 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
  • 在主要使用者或受管理設定檔中，獨立管理帳戶。
• [C-1-8] 如果裝置政策控制器允許，預先安裝的撥號、聯絡人和訊息應用程式必須能夠從受管理設定檔 (如果有的話) 和主要設定檔中，搜尋及查詢來電者資訊。
• [C-1-9] 即使受管理設定檔不會計為主要使用者以外的其他使用者，也必須確保符合啟用多使用者功能的裝置適用的所有安全性規定 (請參閱第 9.5 節)。
• [C-1-10] MUST support the ability to specify a separate lock screen meeting the following requirements to grant access to apps running in a managed profile.
  • 裝置實作項目「必須」遵守 DevicePolicyManager.ACTION_SET_NEW_PASSWORD 意圖，並顯示介面，以便為受管理設定檔設定個別的螢幕鎖定憑證。
  • 如 Android 開放原始碼專案網站所述，受管理設定檔的螢幕鎖定憑證必須使用與父項設定檔相同的憑證儲存和管理機制。
  • DPC 密碼政策「必須」只套用至受管理設定檔的螢幕鎖定憑證，除非呼叫 getParentProfileInstance 傳回的 DevicePolicyManager 執行個體。
• 當預先安裝的通話記錄、通話中 UI、進行中和未接來電通知中顯示受管理設定檔的聯絡人時，聯絡人和訊息應用程式「應該」會標示與受管理設定檔應用程式相同的徽章。

3.9.3 受管理使用者支援

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

• [C-1-1] isLogoutEnabled 傳回 true 時，在多使用者工作階段中，必須提供使用者介面，讓使用者登出目前帳戶並切換回主要使用者。使用者必須能在不解鎖裝置的情況下，從鎖定畫面存取使用者介面。

3.10. 可存取性

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

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

• [C-1-1] MUST provide an implementation of the Android accessibility framework as described in the accessibility APIs SDK documentation.
• [C-1-2] MUST generate accessibility events and deliver the appropriate AccessibilityEvent to all registered AccessibilityService implementations as documented in the SDK.
• [C-1-3] 必須遵守 android.settings.ACCESSIBILITY_SETTINGS 意圖，提供使用者可存取的機制，以便啟用和停用第三方無障礙服務，以及預先安裝的無障礙服務。
• [C-1-4] 啟用的無障礙服務宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 時，系統的導覽列中必須新增按鈕，讓使用者控制無障礙服務。請注意，如果裝置實作項目沒有系統導覽列，則不適用這項規定，但裝置實作項目「應」提供使用者控制這些無障礙服務的機制。

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

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

3.11. Text-to-Speech

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

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

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

如果裝置實作支援安裝第三方 TTS 引擎，則：

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

3.12. 電視輸入架構

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

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

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

3.13. 快速設定

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

如果裝置實作項目包含「快速設定」UI 元件，則：

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

3.14. 媒體 UI

如果裝置實作項目包含透過 MediaBrowser 或 MediaSession 與第三方應用程式互動的非語音啟動應用程式 (以下簡稱「應用程式」)，則應用程式：

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

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

• [C-1-4] MUST allow the user to interact with the entire MediaBrowser hierarchy. 為遵守安全法規 (例如駕駛人分心)，MAY 限制部分層級的存取權，但 MUST NOT 根據內容或內容供應商給予優先待遇。

• [C-1-5] MUST consider double tap of KEYCODE_HEADSETHOOK or KEYCODE_MEDIA_PLAY_PAUSE as KEYCODE_MEDIA_NEXT for MediaSession.Callback#onMediaButtonEvent.

3.15. 免安裝應用程式

裝置實作項目「必須」符合下列規定：

• [C-0-1] 即時應用程式「必須」只取得 android:protectionLevel 設為 "instant" 的權限。
• [C-0-2] 免安裝應用程式「不得」透過隱含意圖與已安裝的應用程式互動，除非符合下列任一條件：
  • 元件的意圖模式篩選器已公開，且具有 CATEGORY_BROWSABLE
  • 動作為 ACTION_SEND、ACTION_SENDTO 或 ACTION_SEND_MULTIPLE 其中之一
  • 目標會透過 android:visibleToInstantApps 明確公開
• [C-0-3] 免安裝應用程式不得與已安裝的應用程式明確互動，除非元件是透過 android:visibleToInstantApps 公開。
• [C-0-4] 安裝的應用程式不得查看裝置上免安裝應用程式的詳細資料，除非免安裝應用程式明確連線至已安裝的應用程式。
• 裝置實作內容「必須」提供下列使用者功能，讓使用者與免安裝應用程式互動。AOSP 預設的系統 UI、設定和啟動器符合相關規定。裝置實作項目：
  • [C-0-5] MUST provide a user affordance to view and delete Instant Apps locally cached for each individual app package.
  • [C-0-6] 免安裝應用程式在前台執行時，必須提供可收合的常駐使用者通知。這則使用者通知「必須」包含免安裝應用程式不需要安裝的資訊，並提供使用者提示，將使用者導向「設定」中的應用程式資訊畫面。如果是透過網頁意圖啟動的免安裝應用程式 (定義方式為使用動作設為 Intent.ACTION_VIEW 的意圖，且配置「http」或「https」的架構)，如果裝置上有瀏覽器，則應提供額外的使用者功能，讓使用者不要啟動免安裝應用程式，而是透過設定的網頁瀏覽器啟動相關聯的連結。
  • [C-0-7] 如果裝置提供「最近」功能，則「最近」功能必須允許存取執行的免安裝應用程式。

3.16. 配對裝置配對連線

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

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

• [C-1-1] 必須宣告功能旗標 FEATURE_COMPANION_DEVICE_SETUP。
• [C-1-2] MUST ensure the APIs in the android.companion package is fully implemented.
• [C-1-3] MUST provide user affordances for the user to select/confirm a companion device is present and operational.

3.17. 重量級應用程式

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

• [C-1-1] 系統一次只能安裝一個指定 cantSaveState 執行的應用程式。如果使用者離開這類應用程式時，並未明確結束應用程式 (例如在離開系統中的現有活動時按下主畫面按鈕，而不是在系統中沒有任何現有活動時按下返回鍵)，則裝置實作方式必須優先處理該應用程式的 RAM，就像處理其他預期會持續執行的項目 (例如前景服務) 一樣。這類應用程式在背景執行時，系統仍可對其套用電源管理功能，例如限制 CPU 和網路存取權。
• [C-1-2] MUST provide a UI affordance to chose the app that won't participate in the normal state save/restore mechanism once the user launches a second app declared with cantSaveState attribute.
• [C-1-3] 不得對指定 cantSaveState 的應用程式套用其他政策變更，例如變更 CPU 效能或排程優先順序。

如果裝置實作項目未宣告 FEATURE_CANT_SAVE_STATE 功能，則：

• [C-1-1] MUST ignore the cantSaveState attribute set by apps and MUST NOT change the app behavior based on that attribute.

4. 應用程式封裝相容性

裝置實作方式：

• [C-0-1] 必須能夠安裝及執行 Android「.apk」檔案，這些檔案是由官方 Android SDK 內含的「aapt」工具產生。
• 由於上述要求可能較為困難，因此建議裝置實作項目使用 AOSP 參考實作項目的套件管理系統。

裝置實作方式：

• [C-0-2] 必須支援使用 APK 簽署配置 v3、APK 簽署配置 v2 和 JAR 簽署驗證「.apk」檔案。
• [C-0-3] 不得擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式，以免這些檔案無法在其他相容裝置上正確安裝及執行。

• [C-0-4] 根據 DELETE_PACKAGE 權限的 SDK 說明文件，不得允許套件的「記錄安裝程式」以外的應用程式，在未經使用者確認的情況下，以無聲模式解除安裝應用程式。唯一例外是處理 PACKAGE_NEEDS_VERIFICATION Intent 的系統套件驗證器應用程式，以及處理 ACTION_MANAGE_STORAGE Intent 的儲存空間管理員應用程式。

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

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

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

• SHOULD provide a user affordance to grant/revoke the permission to install apps from unknown sources per application, but MAY choose to implement this as a no-op and return RESULT_CANCELED for startActivityForResult(), if the device implementation does not want to allow users to have this choice. 不過，即使在這種情況下，他們也「應該」向使用者說明為何沒有顯示這類選項。

• [C-0-7] 應用程式啟動活動前，如果該應用程式已由系統 API PackageManager.setHarmfulAppWarning 標示為可能有害，則 MUST 顯示警告對話方塊，並透過系統 API PackageManager.setHarmfulAppWarning 提供警告字串給使用者。

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

5. 多媒體相容性

裝置實作方式：

• [C-0-1] 必須支援 5.1 節中定義的媒體格式、編碼器、解碼器、檔案類型和容器格式，適用於 MediaCodecList 宣告的每個轉碼器。
• [C-0-2] MUST declare and report support of the encoders, decoders available to third-party applications via MediaCodecList.
• [C-0-3] 必須能夠正確解碼，並向第三方應用程式提供所有可編碼的格式。包括編碼器產生的所有位元串流，以及 CamcorderProfile 中回報的設定檔。

裝置實作方式：

• SHOULD aim for minimum codec latency, in others words, they
  • 不應取用及儲存輸入緩衝區，且處理後只能傳回輸入緩衝區。
  • 不應保留解碼緩衝區，時間長度超過標準 (例如 SPS) 指定的時間。
  • 不應保留編碼緩衝區，時間長度超過 GOP 結構所需。

Android 開放原始碼計畫的偏好 Android 實作項目，會以軟體實作方式提供下列各節列出的所有轉碼器。

請注意，Google 和開放手機聯盟均未聲明這些轉碼器不受第三方專利限制。有意在硬體或軟體產品中使用這項原始碼者，請注意，實作這項程式碼 (包括在開放原始碼軟體或共享軟體中) 可能需要相關專利權人的專利授權。

5.1. 媒體轉碼器

5.1.1. 音訊編碼

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

如果裝置實作項目聲明支援 android.hardware.microphone，就「必須」支援下列音訊格式的編碼，並提供給第三方應用程式：

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

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

• [C-3-1] 透過 android.media.MediaCodec API 傳送 PCM 16 位元原生位元組順序音訊影格。

5.1.2. 音訊解碼

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

如果裝置實作項目宣告支援 android.hardware.audio.output 功能，就必須支援解碼下列音訊格式：

• [C-1-1] MPEG-4 AAC 設定檔 (AAC LC)
• [C-1-2] MPEG-4 HE AAC 設定檔 (AAC+)
• [C-1-3] MPEG-4 HE AACv2 設定檔 (增強型 AAC+)
• [C-1-4] AAC ELD (增強型低延遲 AAC)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 擴充 HE AAC 設定檔，包括 USAC 基準設定檔和 ISO/IEC 23003-4 動態範圍控制設定檔)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE，包括高解析度音訊格式，最高可達 24 位元、192 kHz 取樣率和 8 個聲道。請注意，這項規定僅適用於解碼，裝置可在播放階段進行降取樣和降混。
• [C-1-10] Opus

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

• [C-2-1] 解碼時不得進行降混 (例如，5.0 AAC 串流必須解碼為五個聲道的 PCM，5.1 AAC 串流必須解碼為六個聲道的 PCM)。
• [C-2-2] 動態範圍中繼資料必須如 ISO/IEC 14496-3 的「Dynamic Range Control (DRC)」一節所定義，且 android.media.MediaFormat DRC 鍵可設定音訊解碼器的動態範圍相關行為。API 21 導入了 AAC DRC 鍵，包括：KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_ENCODED_TARGET_LEVEL。
• [SR] 強烈建議所有 AAC 音訊解碼器都應符合上述 C-2-1 和 C-2-2 規定。

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

• [C-3-1] 必須根據 MPEG-D DRC Dynamic Range Control Profile Level 1，解讀及套用響度和 DRC 中繼資料。
• [C-3-2] 解碼器「必須」根據使用下列 android.media.MediaFormat 鍵設定的設定運作：KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_DRC_EFFECT_TYPE。

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

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

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

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

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

• [C-6-1] 透過 android.media.MediaCodec API 傳送 PCM 16 位元原生位元組順序音訊影格。

5.1.3. 音訊轉碼器詳細資料

5.1.4. 圖片編碼

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

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

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

如果裝置實作項目支援透過 android.media.MediaCodec 對媒體類型 MIMETYPE_IMAGE_ANDROID_HEIC 進行 HEIC 編碼，則：

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

5.1.5. 圖片解碼

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

裝置實作內容「必須」支援解碼下列圖片編碼：

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Raw
• [C-0-7] HEIF (HEIC)

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

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

5.1.6. 圖片轉碼器詳細資料

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

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

• [SR] STRONGLY RECOMMENDED to support RGB888 color format for input Surface mode.

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

5.1.7. 視訊轉碼器

• 為確保網頁影片串流和視訊會議服務的品質，裝置實作項目「應」使用符合需求的 VP8 硬體轉碼器。

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

• [C-1-1] 視訊轉碼器「必須」支援輸出和輸入位元組緩衝區大小，以容納標準和設定所規定的最大可行壓縮和未壓縮影格，但也不會過度分配。

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

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

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

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

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

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

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

• [C-3-1] MUST support the refresh periods in the range of 10 - 60 frames and accurately operate within 20% of configured refresh period.

除非應用程式使用 KEY_COLOR_FORMAT 格式鍵另行指定，否則影片解碼器實作項目：

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

5.1.8. 視訊轉碼器清單

5.1.9. 媒體轉碼器安全性

裝置實作項目「必須」確保符合媒體轉碼器安全功能，如下所述。

Android 支援跨平台的 OMX 多媒體加速 API，以及低負荷的 Codec 2.0 多媒體加速 API。

如果裝置實作支援多媒體，則：

• [C-1-1] 必須透過 OMX 或 Codec 2.0 API (或兩者) 支援媒體轉碼器，如 Android 開放原始碼計畫所示，且不得停用或規避安全防護措施。這並非指每個轉碼器「必須」使用 OMX 或 Codec 2.0 API，而是指「必須」支援至少一個 API，且支援的 API「必須」包含現有的安全防護措施。
• [C-SR] 強烈建議加入 Codec 2.0 API 的支援。

如果裝置實作項目不支援 Codec 2.0 API，則：

• [C-2-1] 裝置支援的每種媒體格式和類型 (編碼器或解碼器)，都必須包含 Android 開放原始碼計畫中對應的 OMX 軟體轉碼器 (如有)。
• [C-2-2] 名稱開頭為「OMX.google.」的轉碼器 必須以 Android 開放原始碼計畫原始碼為基礎。
• [C-SR] STRONGLY RECOMMENDED that the OMX software codecs run in a codec process that does not have access to hardware drivers other than memory mappers.

如果裝置實作項目支援 Codec 2.0 API，則：

• [C-3-1] 裝置支援的每種媒體格式和類型 (編碼器或解碼器)，都必須包含 Android 開放原始碼專案中對應的 Codec 2.0 軟體轉碼器 (如有)。
• [C-3-2] 必須在 Android 開放原始碼計畫提供的軟體轉碼器程序中，存放 Codec 2.0 軟體轉碼器，以便更精確地授予軟體轉碼器存取權。
• [C-3-3] 名稱開頭為「c2.android.」的轉碼器。必須以 Android 開放原始碼計畫原始碼為基礎。

5.1.10. 媒體轉碼器特徵

如果裝置實作支援媒體轉碼器，則：

• [C-1-1] MUST return correct values of media codec characterization via the MediaCodecInfo API.

我們特別建議您採取以下做法：

• [C-1-2] 名稱開頭為「OMX.」的轉碼器。必須使用 OMX API，且名稱須符合 OMX IL 命名規範。
• [C-1-3] 名稱開頭為「c2.」的轉碼器。必須使用 Codec 2.0 API，且名稱須符合 Android 的 Codec 2.0 命名規範。
• [C-1-4] 名稱開頭為「OMX.google.」或「c2.android.」的轉碼器 不得視為供應商或硬體加速。
• [C-1-5] 在編解碼器程序 (供應商或系統) 中執行的編解碼器，若可存取記憶體分配器和對映器以外的硬體驅動程式，則不得歸類為僅限軟體。
• [C-1-6] Android 開放原始碼計畫中沒有的編解碼器，或並非以該計畫中的原始碼為基礎的編解碼器，都必須歸類為供應商。
• [C-1-7] 使用硬體加速的轉碼器必須標示為硬體加速。
• [C-1-8] Codec 名稱不得誤導。舉例來說，名為「解碼器」的轉碼器「必須」支援解碼，而名為「編碼器」的轉碼器「必須」支援編碼。名稱包含媒體格式的轉碼器「必須」支援這些格式。

如果裝置實作項目支援視訊編解碼器：

• [C-2-1] 如果轉碼器支援下列大小，所有視訊轉碼器都必須發布可達成的影格率資料：

• [C-2-2] 凡是歸類為硬體加速的視訊轉碼器，都必須發布效能點資訊。除非已涵蓋在其他支援的標準效能點中，否則每個標準效能點都必須列出所有支援的標準效能點 (列於 PerformancePoint API 中)。
• 此外，如果支援標準以外的持續影片效能，也「應該」發布擴展效能點。

5.2. 影片編碼

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

• 在兩個滑動視窗中，不應超過影格內 (I 影格) 間隔間位元率的 15%。
• 在 1 秒的滑動視窗中，不應超過位元率的 100%。

如果裝置實作項目包含對角長度至少 2.5 吋的內嵌螢幕，或包含視訊輸出埠，或透過 android.hardware.camera.any 功能旗標宣告支援攝影機，則：

• [C-1-1] 必須支援至少一個 VP8 或 H.264 影片編碼器，並提供給第三方應用程式使用。
• 應支援 VP8 和 H.264 視訊編碼器，並提供給第三方應用程式使用。

如果裝置實作項目支援 H.264、VP8、VP9 或 HEVC 視訊編碼器，並提供給第三方應用程式，則：

• [C-2-1] 必須支援動態設定位元率。
• SHOULD 支援可變動的畫面更新率，其中影片編碼器 SHOULD 根據輸入緩衝區的時間戳記判斷即時畫面時間長度，並根據該畫面時間長度分配位元值區。

如果裝置實作項目支援 MPEG-4 SP 視訊編碼器，並提供給第三方應用程式使用，則：

• SHOULD 支援為支援的編碼器動態設定位元率。

如果裝置實作項目提供硬體加速的視訊或圖片編碼器，並支援透過 android.camera API 公開的一或多個附加或可插入的硬體攝影機：

• [C-4-1] 所有硬體加速影片和圖片編碼器都必須支援從硬體攝影機編碼影格。
• SHOULD 支援透過所有影片或圖片編碼器，從硬體攝影機編碼影格。

5.2.1. H.263

如果裝置實作項目支援 H.263 編碼器，並提供給第三方應用程式，則：

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

5.2.2. H.264

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

• [C-1-1] MUST support Baseline Profile Level 3. 不過，支援 ASO (任意切片排序)、FMO (彈性巨集區塊排序) 和 RS (冗餘切片) 為選用功能。此外，為維持與其他 Android 裝置的相容性，建議編碼器不要將 ASO、FMO 和 RS 用於基準設定檔。
• [C-1-2] 必須支援下表中的 SD (標準畫質) 視訊編碼設定檔。
• SHOULD support Main Profile Level 4.
• 應支援下表所示的 HD (高畫質) 影片編碼設定檔。

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

• [C-2-1] MUST support the encoding profiles in the following table.

5.2.3. VP8

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

• [C-1-1] MUST support the SD video encoding profiles.
• 應支援下列 HD (高畫質) 影片編碼設定檔。
• [C-1-2] 必須支援寫入 Matroska WebM 檔案。
• SHOULD provide a hardware VP8 codec that meets the WebM project RTC hardware coding requirements, to ensure acceptable quality of web video streaming and video-conference services.

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

• [C-2-1] MUST support the encoding profiles in the following table.

5.2.4. VP9

如果裝置實作項目支援 VP9 編碼器，則：

• [C-1-2] 必須支援 Profile 0 Level 3。
• [C-1-1] 必須支援寫入 Matroska WebM 檔案。
• [C-1-3] 必須產生 CodecPrivate 資料。
• 應支援下表所示的 HD 解碼設定檔。
• [SR] are STRONGLY RECOMMENDED to support the HD decoding profiles as indicated in the following table if there is a hardware encoder.

如果裝置實作項目聲稱透過 Media API 支援設定檔 2 或設定檔 3：

• 支援 12 位元格式為選用項目。

5.2.5. H.265

如果裝置實作項目支援 H.265 轉碼器，則：

• [C-1-1] 必須支援主要設定檔第 3 級。
• 應支援下表所示的 HD 編碼設定檔。
• [SR] 建議 STRONGLY 支援下列表格中所示的 HD 編碼設定檔 (如有硬體編碼器)。

5.3. 影片解碼

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

• [C-1-1] 必須透過標準 Android API，在同一串流中即時支援動態視訊解析度和影格率切換，適用於所有 VP8、VP9、H.264 和 H.265 轉碼器，且解析度最高可達裝置支援的各轉碼器上限。

5.3.1. MPEG-2

如果裝置實作支援 MPEG-2 解碼器，則：

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

5.3.2. H.263

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

• [C-1-1] 必須支援基準設定檔等級 30 和等級 45。

5.3.3. MPEG-4

如果裝置實作項目包含 MPEG-4 解碼器，則：

• [C-1-1] MUST support Simple Profile Level 3.

5.3.4. H.264

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

• [C-1-1] 必須支援 Main 設定檔層級 3.1 和基準設定檔。支援 ASO (任意切片排序)、FMO (彈性巨集區塊排序) 和 RS (冗餘切片) 為選用功能。
• [C-1-2] 必須能夠解碼以基準設定檔和主要設定檔 3.1 級 (包括 720p30) 編碼的影片，且這些影片採用下表列出的 SD (標準畫質) 設定檔。
• 應能解碼具有 HD (高畫質) 設定檔的影片，如下表所示。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，裝置實作項目：

• [C-2-1] 必須支援下表中的 HD 720p 影片解碼設定檔。
• [C-2-2] 必須支援下表中的 HD 1080p 影片解碼設定檔。

5.3.5. H.265 (HEVC)

如果裝置實作項目支援 H.265 轉碼器，則：

• [C-1-1] 必須支援 Main 設定檔 Level 3 Main 層級，以及下表所示的 SD 影片解碼設定檔。
• 應支援下表所示的 HD 解碼設定檔。
• [C-1-2] 如有硬體解碼器，則必須支援下表所示的 HD 解碼設定檔。

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

• [C-2-1] 裝置實作項目必須支援至少一種 720、1080 和 UHD 設定檔的 H.265 或 VP9 解碼。

如果裝置實作項目透過 Media API 聲稱支援 HDR 設定檔 (HEVCProfileMain10HDR10、HEVCProfileMain10HDR10Plus)：

• [C-3-1] 裝置實作項目「必須」接受應用程式透過 MediaCodec API 傳送的必要 HDR 中繼資料 (所有 HDR 設定檔的 MediaFormat#KEY_HDR_STATIC_INFO)，並支援從位元串流和/或容器中擷取必要 HDR 中繼資料 (所有 HDR 設定檔的 MediaFormat#KEY_HDR_STATIC_INFO，以及 HDR10Plus 設定檔的 MediaFormat#KEY_HDR10_PLUS_INFO)，如相關規格所定義。此外，這些轉碼器也必須支援從位元串流和/或容器輸出必要 HDR 中繼資料 (所有 HDR 設定檔的 MediaFormat#KEY_HDR_STATIC_INFO)，如相關規格所定義。

• [C-SR] 強烈建議裝置實作項目支援透過 MediaCodec#getOutputFormat(int) 為 HDR10Plus 設定檔輸出中繼資料 MediaFormat#KEY_HDR10_PLUS_INFO.

• [C-3-2] 裝置實作項目「必須」在裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上，正確顯示 HEVCProfileMain10HDR10 設定檔的 HDR 內容。

• [C-SR] 強烈建議裝置實作項目正確顯示裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上的 HEVCProfileMain10HDR10Plus 設定檔 HDR 內容。

5.3.6. VP8

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

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

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

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

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 設定檔。

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

• 支援 12 位元格式為選用項目。

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

• [C-4-1] 裝置實作項目必須接受應用程式透過 MediaCodec API 傳送的必要 HDR 中繼資料 (所有 HDR 設定檔的 MediaFormat#KEY_HDR_STATIC_INFO，以及 HDR10Plus 設定檔的參數 MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO)，並支援從位元串流和/或容器中擷取必要 HDR 中繼資料 (所有 HDR 設定檔的 MediaFormat#KEY_HDR_STATIC_INFO，以及 HDR10Plus 設定檔的 MediaFormat#KEY_HDR10_PLUS_INFO)，如相關規格所定義。此外，這些轉碼器也「必須」支援從位元串流和/或容器輸出必要 HDR 中繼資料 (所有 HDR 設定檔的 MediaFormat#KEY_HDR_STATIC_INFO)，如相關規格所定義。

• [C-4-2] 裝置實作項目必須在裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上，正確顯示 VP9Profile2HDR 和 VP9Profile3HDR 設定檔的 HDR 內容。

• [C-SR] 強烈建議裝置實作項目支援透過 MediaCodec#getOutputFormat(int) 為 HDR10Plus 設定檔輸出中繼資料 MediaFormat#KEY_HDR10_PLUS_INFO。

• [C-SR] 強烈建議裝置實作項目正確顯示 VP9Profile2HDR10Plus 和 VP9Profile3HDR10Plus 設定檔的 HDR 內容，無論是在裝置螢幕上或標準視訊輸出埠 (例如 HDMI) 上。

5.3.8. Dolby Vision

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

• [C-1-1] 必須提供支援 Dolby Vision 的擷取器。
• [C-1-2] 必須在裝置螢幕或標準視訊輸出埠 (例如 HDMI) 上正確顯示 Dolby Vision 內容。
• [C-1-3] 如有向後相容的基礎層，則必須將其音軌索引設為與合併的 Dolby Vision 層音軌索引相同。

5.3.9. AV1

如果裝置實作項目支援 AV1 編解碼器，則：

• [C-1-1] MUST support Profile 0 including 10-bit content.

5.4. 錄音

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

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

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

• [C-1-1] MUST allow capture of raw audio content with the following characteristics:

  • 格式：線性 PCM，16 位元
  • 取樣率：8000、11025、16000、44100、48000 Hz
  • 頻道：單聲道

• SHOULD allow capture of raw audio content with the following characteristics:

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

• [C-1-2] MUST capture at above sample rates without up-sampling.

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

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

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

• [C-1-4] 必須遵守 MicrophoneInfo API，並透過 AudioManager.getMicrophones() API 正確填寫第三方應用程式可存取的裝置麥克風資訊，以及透過 AudioRecord.getActiveMicrophones() 和 MediaRecorder.getActiveMicrophones() API 存取的目前啟用麥克風資訊。如果裝置實作項目允許擷取 AM 廣播和 DVD 品質的原始音訊內容，則：

• [C-2-1] MUST capture without up-sampling at any ratio higher than 16000:22050 or 44100:48000.

• [C-2-2] 必須為任何升採樣或降採樣作業加入適當的反鋸齒濾鏡。

5.4.2. 擷取語音辨識內容

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

• [C-1-1] 必須以 44100 和 48000 其中一個取樣率擷取 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源。
• [C-1-2] 預設情況下，從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，必須停用任何降噪音訊處理作業。
• [C-1-3] 根據預設，從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，必須停用任何自動增益控制項。
• 應錄製語音辨識音訊串流，並確保振幅與頻率特性大致平坦：具體來說，從 100 Hz 到 4000 Hz 之間應為 ±3 dB。
• 應錄製語音辨識音訊串流，並將輸入靈敏度設為：在 1000 Hz 時，90 dB 音量位準 (SPL) 來源的 16 位元樣本會產生 2500 的 RMS。
• 應記錄語音辨識音訊串流，使 PCM 振幅位準在麥克風的 90 dB SPL 範圍內，至少從 -18 dB 到 +12 dB re 90 dB SPL，線性追蹤輸入 SPL 變化。
• SHOULD 錄製語音辨識音訊串流，在麥克風的 90 dB SPL 輸入音量下，1 kHz 的總諧波失真 (THD) 應小於 1%。

如果裝置實作項目聲明android.hardware.microphone和降噪 (抑制) 技術已針對語音辨識進行調整，則：

• [C-2-1] 必須允許使用 android.media.audiofx.NoiseSuppressor API 控制這項音效。
• [C-2-2] 必須透過 AudioEffect.Descriptor.uuid 欄位，不重複地識別每項雜訊抑制技術實作項目。

5.4.3. 擷取播放重新導向的內容

android.media.MediaRecorder.AudioSource 類別包含 REMOTE_SUBMIX 音訊來源。

如果裝置實作項目同時宣告 android.hardware.audio.output 和 android.hardware.microphone，則：

• [C-1-1] 必須正確實作 REMOTE_SUBMIX 音訊來源，以便應用程式使用 android.media.AudioRecord API 從這個音訊來源錄音時，擷取所有音訊串流的混音，但下列項目除外：

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. 聲學回音消除器

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

• SHOULD 實作針對語音通訊調整的聲學回音消除器 (AEC) 技術，並在透過 AudioSource.VOICE_COMMUNICATION 擷取時套用至擷取路徑

如果裝置實作項目提供聲學回音消除器，且在選取 AudioSource.VOICE_COMMUNICATION 時插入擷取音訊路徑，則：

• [C-SR] are STRONGLY_RECOMMENDED to declare this via AcousticEchoCanceler API method AcousticEchoCanceler.isAvailable()
• [C-SR] AcousticEchoCanceler API「強烈建議」允許控制這項音效。
• [C-SR] 強烈建議透過 AudioEffect.Descriptor.uuid 欄位，為每項 AEC 技術實作項目指定專屬 ID。

5.4.5. 同時擷取

如果裝置實作項目宣告 android.hardware.microphone，就「必須」實作並行擷取功能，如這份文件所述。具體來說：

• [C-1-1] 必須允許無障礙服務透過 AudioSource.VOICE_RECOGNITION 擷取音訊，且至少有一個應用程式透過任何 AudioSource 擷取音訊，同時存取麥克風。
• [C-1-2] 預先安裝的應用程式必須允許同時存取麥克風，該應用程式具有 Google 助理角色，且至少有一個應用程式使用任何 AudioSource 擷取內容，但 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 除外。
• [C-1-3] 應用程式使用 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 擷取音訊時，除了無障礙服務外，其他應用程式的音訊擷取功能都必須靜音。不過，如果應用程式透過 AudioSource.VOICE_COMMUNICATION 擷取音訊，且是具備 CAPTURE_AUDIO_OUTPUT 權限的預先安裝應用程式，就能擷取語音通話內容。
• [C-1-4] 如果兩個以上的應用程式同時擷取音訊，且沒有任何應用程式的 UI 位於最上層，則最近開始擷取的應用程式會收到音訊。

5.4.6. 麥克風增益等級

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

• 在中間頻率範圍內，應呈現大致平坦的振幅與頻率特性：具體來說，用於錄製語音辨識音訊來源的每個麥克風，在 100 Hz 到 4000 Hz 範圍內應為 ±3dB。
• 音訊輸入靈敏度應設為：以 90 dB 音壓級 (SPL) 播放 1000 Hz 正弦波音調來源時，每個用於錄製語音辨識音訊來源的麥克風，都會產生 RMS 為 2500 的回應 (或浮點/雙精度樣本的 -22.35 dB 滿刻度)。
• [C-SR] 強烈建議在低頻範圍內顯示振幅位準：具體來說，與用於錄製語音辨識音訊來源的每個麥克風中頻範圍相比，5 Hz 至 100 Hz 的振幅位準應為 ±20 dB。
• [C-SR] 強烈建議在高頻範圍內呈現振幅位準：具體來說，與用於錄製語音辨識音訊來源的每個麥克風的中頻範圍相比，從 4000 Hz 到 22 KHz 的範圍內為 ±30 dB。

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、32000、44100、48000 (適用於上述管道設定)
    • 單聲道和立體聲 96000

• 應允許播放具有下列特性的原始音訊內容：

  • 取樣率：24000

5.5.2. 音效

Android 提供音效 API，供裝置實作使用。

如果裝置實作項目聲明瞭 android.hardware.audio.output 功能，則：

• [C-1-1] MUST support the EFFECT_TYPE_EQUALIZER and EFFECT_TYPE_LOUDNESS_ENHANCER implementations controllable through the AudioEffect subclasses Equalizer and LoudnessEnhancer.
• [C-1-2] 必須支援視覺化工具 API 實作，並可透過 Visualizer 類別控制。
• [C-1-3] 必須支援可透過 AudioEffect 子類別 DynamicsProcessing 控制的 EFFECT_TYPE_DYNAMICS_PROCESSING 實作項目。
• 應支援可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作。
• [C-SR] 強烈建議支援浮點和多聲道效果。

5.5.3. 音訊輸出音量

車輛裝置實作方式：

• SHOULD allow adjusting audio volume separately per each audio stream using the content type or usage as defined by AudioAttributes and car audio usage as publicly defined in android.car.CarAudioManager.

5.6. 音訊延遲

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

本節適用下列定義：

• 輸出延遲。應用程式寫入 PCM 編碼資料影格的時間，與對應聲音透過裝置上的轉換器呈現給環境的時間間隔，或訊號透過連接埠離開裝置並可從外部觀察的時間間隔。
• 冷輸出延遲。音訊輸出系統在要求前處於閒置狀態並已關機時，第一個影格的輸出延遲時間。
• 連續輸出延遲時間。裝置播放音訊後，後續影格的輸出延遲時間。
• 輸入延遲。環境透過裝置上的轉換器向裝置發出聲音，或訊號透過連接埠進入裝置，到應用程式讀取相應的 PCM 編碼資料影格之間的時間間隔。
• 遺失輸入內容。輸入信號的初始部分，無法使用或無法取得。
• 冷輸入延遲。音訊輸入系統在要求前處於閒置和關機狀態時，遺失的輸入時間和第一個影格的輸入延遲時間總和。
• 持續輸入延遲。裝置擷取音訊時，後續影格的輸入延遲。
• 冷輸出抖動。冷啟動延遲時間值的個別測量結果之間的變異性。
• 冷輸入抖動。冷輸入延遲時間值的個別測量值之間的變異性。
• 連續往返延遲時間。連續輸入延遲時間、連續輸出延遲時間和一個緩衝區週期的總和。緩衝期可讓應用程式處理訊號，並縮短輸入和輸出串流之間的相位差。
• OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 集。
• AAudio 原生音訊 API。Android NDK 中的 AAudio API 集。
• 時間戳記。由串流中的相對影格位置，以及該影格進入或離開相關端點音訊處理管道的預估時間所組成的配對。另請參閱 AudioTimestamp。
• glitch。音訊訊號暫時中斷或樣本值不正確，通常是由於輸出發生緩衝區欠位、輸入發生緩衝區溢位，或任何其他數位或類比噪音來源。

如果裝置實作項目聲明 android.hardware.audio.output，則必須符合或超過下列需求：

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

如果裝置實作項目宣告 android.hardware.audio.output，強烈建議符合或超過下列需求：

• [C-SR] 冷輸出延遲時間不超過 100 毫秒。強烈建議現有和新裝置現在就符合這些規定，在 2021 年的未來平台版本中，我們將要求冷輸出延遲時間必須為 200 毫秒或更短。
• [C-SR] 連續輸出延遲時間為 45 毫秒以下。
• [C-SR] Minimize the cold output jitter.
• [C-SR] AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 傳回的輸出時間戳記精確度為 +/- 1 毫秒。

如果裝置實作符合上述需求，在完成任何初始校準後，使用 OpenSL ES PCM 緩衝區佇列和 AAudio 原生音訊 API 時，至少有一個支援的音訊輸出裝置的連續輸出延遲和冷輸出延遲時間為：

• [C-SR] 強烈建議宣告 android.hardware.audio.low_latency 功能旗標，回報低延遲音訊。
• [C-SR] 強烈建議透過 AAudio API 滿足低延遲音訊需求。
• [C-SR] 強烈建議確保對於從 AAudioStream_getPerformanceMode() 傳回 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 的串流，AAudioStream_getFramesPerBurst() 傳回的值小於或等於 android.media.AudioManager.getProperty(String) 針對屬性鍵 AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER 傳回的值。

如果裝置實作項目無法透過 OpenSL ES PCM 緩衝區佇列和 AAudio 原生音訊 API，滿足低延遲音訊的需求，則：

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

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

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

如果裝置實作項目包含 android.hardware.microphone，強烈建議符合下列輸入音訊需求：

• [C-SR] 冷輸入延遲時間不超過 100 毫秒。強烈建議現有和新裝置現在就符合這些規定，在 2021 年的未來平台版本中，我們將要求冷輸入延遲時間必須為 200 毫秒或更短。
• [C-SR] 連續輸入延遲時間不得超過 30 毫秒。
• [C-SR] 連續往返延遲時間為 50 毫秒或更短的時間。
• [C-SR] Minimize the cold input jitter.
• [C-SR] 將 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回的輸入時間戳記錯誤限制在 +/- 1 毫秒內。

5.7. 網路通訊協定

裝置實作項目「必須」支援 Android SDK 說明文件中指定的音訊和影片播放媒體網路通訊協定。

如果裝置實作項目包含音訊或視訊解碼器，則：

• [C-1-1] 必須透過 HTTP(S) 支援第 5.1 節中的所有必要轉碼器和容器格式。

• [C-1-2] 必須透過 HTTP 即時串流草案通訊協定第 7 版，支援下方「媒體區段格式」表格中顯示的媒體區段格式。

• [C-1-3] 必須支援下列 RTP 音訊視訊設定檔，以及下方 RTSP 表格中的相關轉碼器。如需例外狀況，請參閱第 5.1 節中的表格註腳。

媒體片段格式

RTSP (RTP、SDP)

5.8. 安全無虞的媒體服務

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

• [C-1-1] 必須聲明支援 Display.FLAG_SECURE。

如果裝置實作項目聲明支援 Display.FLAG_SECURE 和無線螢幕通訊協定，則：

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

如果裝置實作項目聲明支援 Display.FLAG_SECURE 和有線外接螢幕，則：

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

5.9. 樂器數位介面 (MIDI)

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

• [C-1-1] 必須支援透過所有支援 MIDI 的硬體傳輸方式傳輸 MIDI，並提供非 MIDI 的一般連線功能，這些傳輸方式包括：

  • USB 主機模式，第 7.7 節
  • USB 周邊裝置模式，第 7.7 節
  • 透過藍牙 LE 進行 MIDI 傳輸 (擔任中央角色)，請參閱第 7.4.3 節

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

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

5.10. 專業音訊

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

• [C-1-1] 必須回報功能 android.hardware.audio.low_latency 的支援情形。
• [C-1-2] 必須具有連續往返音訊延遲時間，如第 5.6 節「音訊延遲」所定義，至少在一個支援的路徑上，延遲時間為 20 毫秒或更短，且應為 10 毫秒或更短。
• [C-1-3] 必須包含支援 USB 主機模式和 USB 周邊模式的 USB 連接埠。
• [C-1-4] MUST report support for feature android.software.midi.
• [C-1-5] 必須使用 OpenSL ES PCM 緩衝區佇列 API 和至少一個 AAudio 原生音訊 API 路徑，滿足延遲和 USB 音訊需求。
• [SR] 強烈建議使用 MMAP 路徑的 AAudio 原生音訊 API，以符合延遲和 USB 音訊需求。
• [C-1-6] 必須有 200 毫秒以下的冷輸出延遲時間。
• [C-1-7] 必須有 200 毫秒以下的冷輸入延遲。
• [SR] 強烈建議在音訊處於啟用狀態且 CPU 負載量不同時，提供一致的 CPU 效能。請使用 SynthMark Android 應用程式版本 (提交 ID 09b13c6f49ea089f8c31e5d035f912cc405b7ab8) 測試這項功能。SynthMark 會使用在模擬音訊架構上執行的軟體合成器，測量系統效能。您必須使用「自動化測試」選項執行 SynthMark 應用程式，並獲得下列結果：
  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 毫秒
  • latencymark.dynamic.little <= 50 毫秒

如要瞭解基準，請參閱 SynthMark 說明文件。

• 應盡量減少音訊時鐘相對於標準時間的不準確度和漂移。
• 在兩者都處於啟用狀態時，音訊時脈漂移相對於 CPU CLOCK_MONOTONIC 應盡量減少。
• SHOULD minimize audio latency over on-device transducers.
• SHOULD minimize audio latency over USB digital audio.
• SHOULD document audio latency measurements over all paths.
• SHOULD 盡量減少音訊緩衝區完成回呼項目時間的抖動，因為這會影響回呼可用的完整 CPU 頻寬百分比。
• 在正常使用情況下，應在回報的延遲時間內提供零音訊故障。
• SHOULD 提供零通道間延遲差異。
• SHOULD minimize MIDI mean latency over all transports.
• 在所有傳輸方式中，都應盡量減少負載下的 MIDI 延遲變異性 (抖動)。
• SHOULD provide accurate MIDI timestamps over all transports.
• SHOULD minimize audio signal noise over on-device transducers, including the period immediately after cold start.
• 如果對應端點都處於啟用狀態，輸入和輸出端點之間的音訊時鐘差異應為零。對應端點的例子包括裝置上的麥克風和喇叭，或是音訊插孔的輸入和輸出。
• 如果輸入和輸出兩端點都處於有效狀態，則應在同一執行緒上處理音訊緩衝區完成回呼，並在從輸入回呼傳回後立即進入輸出回呼。或者，如果無法在同一個執行緒上處理回呼，請在輸入回呼後不久輸入輸出回呼，讓應用程式的輸入和輸出端保持一致的時間。
• SHOULD minimize the phase difference between HAL audio buffering for the input and output sides of corresponding end-points.
• SHOULD minimize touch latency.
• SHOULD 盡量減少負載下的觸控延遲變異數 (抖動)。
• 從觸控輸入到音訊輸出，延遲時間應小於或等於 40 毫秒。

如果裝置實作項目符合上述所有規定，則：

• [SR] STRONGLY RECOMMENDED to report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class.

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

• [C-2-1] MUST have the continuous round-trip audio latency to be 20 milliseconds or less over the audio jack path.
• [SR] STRONGLY RECOMMENDED to comply with section Mobile device (jack) specifications of the Wired Audio Headset Specification (v1.1).
• 透過音訊插孔路徑，連續往返音訊延遲時間應為 10 毫秒或更短。

如果裝置實作省略 4 導體 3.5 公釐音訊插孔，並包含支援 USB 主機模式的 USB 連接埠，則：

• [C-3-1] 必須實作 USB 音訊類別。
• [C-3-2] 透過 USB 音訊類別使用 USB 主機模式連接埠時，必須具備連續往返音訊延遲時間 20 毫秒以下。
• 使用 USB 音訊類別時，透過 USB 主機模式通訊埠，音訊延遲時間應不超過 10 毫秒。
• [C-SR] 搭配也支援這些需求的 USB 音訊周邊裝置時，強烈建議支援雙向最多 8 個聲道、96 kHz 取樣率，以及 24 位元或 32 位元深度的同步 I/O。

如果裝置實作項目包含 HDMI 連接埠，則：

• 應支援以立體聲和八個聲道輸出 20 位元或 24 位元深度和 192 kHz，且至少在一個設定中不會遺失位元深度或重新取樣。

5.11. 擷取未處理的資料

Android 支援透過 android.media.MediaRecorder.AudioSource.UNPROCESSED 音訊來源錄製未經處理的音訊。在 OpenSL ES 中，可以使用錄音預設值 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 存取。

如果裝置實作項目打算支援未經處理的音訊來源，並提供給第三方應用程式，則：

• [C-1-1] 必須透過 android.media.AudioManager 屬性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 回報支援情形。

• [C-1-2] 必須在中頻範圍內呈現大致平坦的振幅與頻率特性：具體來說，用於錄製未經處理音訊來源的每個麥克風，在 100 Hz 至 7000 Hz 範圍內必須為 ±10dB。

• [C-1-3] 必須在低頻範圍內呈現振幅位準：具體來說，與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比，5 Hz 至 100 Hz 的振幅位準必須在 ±20 dB 範圍內。

• [C-1-4] 必須在高頻範圍內呈現振幅位準：具體來說，與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比，7000 Hz 至 22 KHz 的振幅位準必須在 ±30 dB 範圍內。

• [C-1-5] 必須設定音訊輸入靈敏度，使以 94 dB 音壓級 (SPL) 播放的 1000 Hz 正弦波音調來源，針對用於錄製未處理音訊來源的每個麥克風，產生 RMS 為 520 的回應 (或浮點/雙精度樣本的 -36 dB 滿刻度)。

• [C-1-6] 用於錄製未經處理音訊來源的每個麥克風，訊號雜訊比 (SNR) 必須達到 60 dB 以上。(而訊號雜訊比的測量方式，是 94 dB SPL 與等效 SPL 自我噪音 (A 加權) 之間的差異)。

• [C-1-7] 必須在 90 dB SPL 輸入位準下，針對用於錄製未經處理音訊來源的每個麥克風，在 1 kHz 時的總諧波失真 (THD) 低於 1%。

• 路徑中不得有任何其他訊號處理作業 (例如自動增益控制、高通濾波器或迴音消除)，只能有將音量帶入所需範圍的音量乘數。換句話說：

• [C-1-8] 如果架構中因任何原因出現信號處理程序，則必須停用該程序，並有效將信號路徑的延遲或額外延遲時間降至零。
• [C-1-9] 雖然路徑上可以有位準乘數，但不得為訊號路徑帶來延遲或延遲。

所有 SPL 測量值都是在受測麥克風旁直接測得。如有多個麥克風設定，這些規定適用於每個麥克風。

如果裝置實作項目宣告 android.hardware.microphone，但未支援未經處理的音訊來源，則：

• [C-2-1] MUST return null for the AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API method, to properly indicate the lack of support.
• [SR] 仍強烈建議滿足未處理錄音來源的信號路徑要求，

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

6.1. 開發人員工具

裝置實作方式：

• [C-0-1] 必須支援 Android SDK 提供的 Android 開發人員工具。

• Android Debug Bridge (adb)

  • [C-0-2] MUST support adb as documented in the Android SDK and the shell commands provided in the AOSP, which can be used by app developers, including dumpsys cmd stats
  • [C-SR] 強烈建議支援殼層指令 cmd testharness。
  • [C-0-3] 不得變更透過 dumpsys 指令記錄的裝置系統事件 (batterystats、diskstats、指紋、graphicsstats、netstats、通知、procstats) 格式或內容。
  • [C-0-10] 必須完整記錄下列事件，並提供給 cmd stats shell 指令和 StatsManager System API 類別存取和使用。
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] 裝置端的 adb 精靈必須預設為非使用中狀態，且必須提供使用者可存取的機制來開啟 Android Debug Bridge。
  • [C-0-5] 必須支援安全 adb。Android 支援安全 adb。安全 adb 可讓已知經過驗證的主機使用 adb。

  • [C-0-6] 必須提供機制，允許從主體機器連線至 ADB。例如：

    • 如果裝置實作項目沒有支援周邊裝置模式的 USB 連接埠，就必須透過區域網路 (例如乙太網路或 Wi-Fi) 實作 adb。
    • 必須提供 Windows 7、9 和 10 的驅動程式，讓開發人員使用 adb 通訊協定連線至裝置。

• Dalvik 偵錯監視服務 (ddms)

  • [C-0-7] MUST support all ddms features as documented in the Android SDK. 由於 ddms 使用 adb，因此預設情況下，對 ddms 的支援「應」為非使用中狀態，但只要使用者已啟用 Android Debug Bridge，就「必須」支援 ddms，如上所述。
• Monkey
  • [C-0-8] 必須包含 Monkey 架構，並供應用程式使用。
• SysTrace
  • [C-0-9] MUST support the systrace tool as documented in the Android SDK. Systrace 預設必須處於非啟用狀態，且必須提供使用者可存取的機制來啟用 Systrace。

• Perfetto

  • [C-SR] /system/bin/perfetto 二進位檔「強烈建議」向 Shell 使用者公開，且 cmdline 符合perfetto 說明文件。
  • [C-SR] 強烈建議 perfetto 二進位檔接受符合perfetto 說明文件中定義結構的 protobuf 設定做為輸入內容。
  • [C-SR] 強烈建議 perfetto 二進位檔將 protobuf 追蹤記錄寫入輸出內容，並遵守perfetto 說明文件中定義的結構定義。
  • [C-SR] 強烈建議透過 perfetto 二進位檔提供至少perfetto 說明文件中描述的資料來源。

• 測試控管工具模式

  如果裝置實作項目支援 cmd testharness 殼層指令並執行 cmd testharness enable，則：

  • [C-2-1] MUST return true for ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] MUST implement Test Harness Mode as described in harness mode documentation.

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

• [C-1-1] 必須提供應用程式開發人員可啟用/停用 GPU 偵錯層的功能提示。
• [C-1-2] 啟用 GPU 偵錯層時，必須列舉偵錯應用程式基本目錄中，外部工具 (即不屬於平台或應用程式套件) 提供的程式庫中的層，以支援 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。

6.2. 開發人員選項

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

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

• [C-0-1] MUST honor the android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application development-related settings. 上游 Android 實作會預設隱藏「開發人員選項」選單，使用者只要在「設定」>「關於裝置」>「版本號碼」選單項目上按七 (7) 次，即可啟動「開發人員選項」。
• [C-0-2] 必須預設隱藏「開發人員選項」。
• [C-0-3] 必須提供明確機制，不得偏袒任何第三方應用程式，以啟用「開發人員選項」。必須提供公開文件或網站，說明如何啟用「開發人員選項」。這份文件或網站必須可從 Android SDK 文件連結。
• 如果啟用「開發人員選項」且使用者安全堪慮，應用程式「應」持續向使用者顯示視覺通知。
• MAY 可能會暫時限制存取「開發人員選項」選單，方法是隱藏或停用該選單，避免使用者在安全堪慮的情況下分心。

7. 硬體相容性

如果裝置包含特定硬體元件，且第三方開發人員可使用對應的 API：

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

如果 SDK 中的 API 與聲明為選用元素的硬體元件互動，而裝置實作沒有該元件：

• [C-0-2] 仍須提供元件 API 的完整類別定義 (如 SDK 文件所述)。
• [C-0-3] API 的行為必須以某種合理方式實作為無作業。
• [C-0-4] 只要 SDK 說明文件允許，API 方法就必須傳回空值。
• [C-0-5] 如果 SDK 說明文件不允許空值，API 方法就必須傳回類別的無運算實作項目。
• [C-0-6] API 方法不得擲回 SDK 說明文件未記載的例外狀況。
• [C-0-7] 裝置實作項目必須透過 android.content.pm.PackageManager 類別的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法，針對相同建構指紋，持續回報準確的硬體設定資訊。

電話 API 就是適用這些規定的典型情境：即使在非手機裝置上，這些 API 也必須實作為合理的無作業。

7.1. 顯示和圖形

Android 內建多項功能，可自動調整應用程式資產和 UI 版面配置，確保第三方應用程式能在各種硬體設定上順利執行。在所有可執行第三方 Android 相容應用程式的 Android 相容螢幕上，裝置實作項目「必須」正確實作這些 API 和行為，詳情請參閱本節。

本節要求中提及的單位定義如下：

• 實體對角尺寸。螢幕發光部分兩個對角之間的距離 (以英吋為單位)。
• 每英吋點數 (dpi)。1 英寸的線性水平或垂直跨度所涵蓋的像素數。如果列出 dpi 值，水平和垂直 dpi 都必須在範圍內。
• 顯示比例。螢幕長邊像素與短邊像素的比例。舉例來說，如果螢幕的像素為 480x854，則比例為 854/480 = 1.779，或大約「16:9」。
• 密度獨立像素 (dp)。虛擬像素單位已標準化為 160 dpi 螢幕，計算方式如下：像素 = dp * (密度/160)。

7.1.1. 螢幕設定

7.1.1.1. 螢幕大小和形狀

Android UI 架構支援各種不同的邏輯螢幕版面配置大小，並允許應用程式透過 Configuration.screenLayout 和 SCREENLAYOUT_SIZE_MASK 查詢目前設定的螢幕版面配置大小。Configuration.smallestScreenWidthDp

裝置實作方式：

• [C-0-1] MUST report the correct layout size for the Configuration.screenLayout as defined in the Android SDK documentation. 具體來說，裝置實作內容「必須」回報正確的邏輯密度獨立像素 (dp) 螢幕尺寸，如下所示：

  • 如果裝置的 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 以外的任何值，且回報的 small 大小為 Configuration.screenLayout，則必須至少為 426 dp x 320 dp。
  • 回報 normal 大小的裝置，Configuration.screenLayout 至少須為 480 dp x 320 dp。
  • 回報 large 大小的裝置 (Configuration.screenLayout)，必須至少為 640 dp x 480 dp。
  • 回報 Configuration.screenLayout 大小的裝置xlarge，必須至少為 960 dp x 720 dp。

• [C-0-2] 必須透過 AndroidManifest.xml 中的 <supports-screens> 屬性，正確遵守應用程式聲明的螢幕尺寸支援，如 Android SDK 文件所述。

• 可能具有圓角設計的 Android 相容螢幕。

如果裝置實作項目支援 UI_MODE_TYPE_NORMAL，且包含圓角 Android 相容螢幕，則：

• [C-1-1] 必須確保圓角的半徑小於或等於 38 dp。
• 應包含使用者可切換至矩形邊角顯示模式的介面。

7.1.1.2. 螢幕顯示比例

雖然 Android 相容螢幕的實體螢幕顯示比例沒有限制，但第三方應用程式的邏輯螢幕顯示比例(可從透過 view.Display API 和 Configuration API 回報的高度和寬度值衍生而來) 必須符合下列規定：

• [C-0-1] 除非應用程式符合下列其中一項條件，否則將 Configuration.uiMode 設為 UI_MODE_TYPE_NORMAL 的裝置實作項目，顯示比例值必須小於或等於 1.86 (約為 16:9)：

  • 應用程式已透過 android.max_aspect 中繼資料值，宣告支援較大的螢幕顯示比例。
  • 應用程式會透過 android:resizeableActivity 屬性宣告可調整大小。
  • 應用程式指定 API 級別 24 以上版本，且未宣告會限制允許顯示比例的 android:maxAspectRatio。

• [C-0-2] 除非應用程式符合下列其中一項條件，可拉伸得更寬，否則將 Configuration.uiMode 設為 UI_MODE_TYPE_NORMAL 的裝置實作項目，顯示比例值必須大於或等於 1.3333 (4:3)：

  • 應用程式會透過 android:resizeableActivity 屬性宣告可調整大小。
  • 應用程式宣告的 android:minAspectRatio 會限制允許的長寬比。

• [C-0-3] 如果裝置實作項目將 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH，則顯示比例值必須設為 1.0 (1:1)。

7.1.1.3. 螢幕密度

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

• [C-0-1] 根據預設，裝置實作項目只能透過 DENSITY_DEVICE_STABLE API 回報 DisplayMetrics 上列出的其中一個 Android 架構密度，且這個值不得隨時變更；不過，裝置可根據使用者在初始啟動後設定的螢幕設定變更 (例如螢幕大小)，回報不同的任意密度。

• 裝置實作應定義在數值上最接近螢幕實際密度的標準 Android 架構密度，除非該邏輯密度會使回報的螢幕大小低於支援的最小值。如果與實體密度最接近的標準 Android 架構密度，導致螢幕大小小於支援的最小相容螢幕大小 (寬度 320 dp)，裝置實作「應」回報次低的標準 Android 架構密度。

如果裝置提供變更顯示大小的選項：

• [C-1-1] 螢幕大小的縮放比例不得超過原生密度的 1.5 倍，或產生小於 320dp 的有效最小螢幕尺寸 (相當於資源限定符 sw320dp)，以先到者為準。
• [C-1-2] 顯示大小的縮放比例不得小於原生密度的 0.85 倍。
• 為確保良好的可用性和一致的字型大小，建議提供下列原生顯示選項的縮放比例 (同時遵守上述限制)：
• 小：0.85 倍
• 預設值：1 倍 (原生顯示比例)
• 大：1.15 倍
• 較大：1.3 倍
• 最大 1.45 倍

7.1.2. 顯示指標

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

• [C-1-1] MUST report correct values for all Android-compatible display metrics defined in the android.util.DisplayMetrics API.

如果裝置實作項目未內建螢幕或視訊輸出功能，則：

• [C-2-1] 必須回報 android.util.DisplayMetrics API 中定義的 Android 相容螢幕正確值，以供模擬預設 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] MUST support dynamic orientation by applications to either portrait or landscape screen orientation. 也就是說，裝置「必須」尊重應用程式對特定螢幕方向的要求。
• [C-1-2] 變更螢幕方向時，不得變更回報的螢幕大小或密度。
• MAY 選取直向或橫向做為預設方向。

7.1.4. 2D 和 3D 圖形加速

7.1.4.1 OpenGL ES

裝置實作方式：

• [C-0-1] 必須透過受管理 API (例如透過 GLES10.getString() 方法) 和原生 API，正確識別支援的 OpenGL ES 版本 (1.1、2.0、3.0、3.1、3.2)。
• [C-0-2] 必須支援所有對應的管理 API 和原生 API，才能支援所識別的每個 OpenGL ES 版本。

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

• [C-1-1] 必須支援 OpenGL ES 1.1 和 2.0，詳情請參閱 Android SDK 說明文件。
• [C-SR] 強烈建議支援 OpenGL ES 3.1。
• 應支援 OpenGL ES 3.2。

如果裝置實作項目支援任何 OpenGL ES 版本，則：

• [C-2-1] 實作任何其他 OpenGL ES 擴充功能時，必須透過 OpenGL ES 管理 API 和原生 API 回報，反之，不得回報不支援的擴充功能字串。
• [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-SR] STRONGLY RECOMMENDED to support the EGL_KHR_partial_update and OES_EGL_image_external extensions.
• 應透過 getString() 方法準確回報支援的任何紋理壓縮格式，這通常是供應商專屬格式。

如果裝置實作項目宣告支援 OpenGL ES 3.0、3.1 或 3.2，則：

• [C-3-1] 除了 libGLESv2.so 程式庫中的 OpenGL ES 2.0 函式符號外，還必須匯出這些版本的對應函式符號。
• [SR] 強烈建議支援 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，則：

• [SR] 強烈建議納入 Vulkan 1.1 支援。

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

• 應支援 Vulkan 1.1。

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

• [C-1-1] 必須使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能旗標回報正確的整數值。
• [C-1-2] 必須列舉至少一個 Vulkan 原生 API vkEnumeratePhysicalDevices() 的 VkPhysicalDevice。
• [C-1-3] MUST fully implement the Vulkan 1.0 APIs for each enumerated VkPhysicalDevice.
• [C-1-4] 必須透過 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties()，列舉應用程式套件原生資料庫目錄中，名為 libVkLayer*.so 的原生資料庫所含的圖層。
• [C-1-5] 除非應用程式的 android:debuggable 屬性設為 true，否則不得列舉應用程式套件以外程式庫提供的層，也不得提供追蹤或攔截 Vulkan API 的其他方式。
• [C-1-6] MUST report all extension strings that they do support via the Vulkan native APIs , and conversely MUST NOT report extension strings that they do not correctly support.
• [C-1-7] 必須支援 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 擴充功能。
• [C-SR] 強烈建議支援 VK_KHR_driver_properties 和 VK_GOOGLE_display_timing 擴充功能。

如果裝置實作項目不支援 Vulkan 1.0，則：

• [C-2-1] 不得宣告任何 Vulkan 功能旗標 (例如 android.hardware.vulkan.level、android.hardware.vulkan.version)。
• [C-2-2] 不得列舉任何 Vulkan 原生 API vkEnumeratePhysicalDevices() 的 VkPhysicalDevice。

如果裝置實作項目支援 Vulkan 1.1，且宣告任何 Vulkan 功能旗標，則：

• [C-3-1] MUST 支援 SYNC_FD 外部信號和控制代碼型別，以及 VK_ANDROID_external_memory_android_hardware_buffer 擴充功能。

7.1.4.3 RenderScript

• [C-0-1] 裝置實作項目「必須」支援 Android RenderScript，詳情請參閱 Android SDK 說明文件。

7.1.4.4 2D 圖形加速

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

裝置實作方式：

• [C-0-1] 預設必須啟用硬體加速，且如果開發人員要求停用硬體加速 (方法是設定 android:hardwareAccelerated="false” 或直接透過 Android View API 停用硬體加速)，則必須停用硬體加速。
• [C-0-2] MUST exhibit behavior consistent with the Android SDK documentation on hardware acceleration.

Android 包含 TextureView 物件，可讓開發人員直接整合硬體加速的 OpenGL ES 紋理，做為 UI 階層中的算繪目標。

裝置實作方式：

• [C-0-3] 必須支援 TextureView API，且行為必須與上游 Android 實作項目一致。

7.1.4.5 廣色域螢幕

如果裝置實作項目透過 Configuration.isScreenWideColorGamut() 聲明支援廣色域螢幕，則：

• [C-1-1] 必須配備經過色彩校正的螢幕。
• [C-1-2] 顯示螢幕的色域必須完全涵蓋 CIE 1931 xyY 空間中的 sRGB 色域。
• [C-1-3] 螢幕的色域在 CIE 1931 xyY 空間中，面積必須至少為 DCI-P3 的 90%。
• [C-1-4] 必須支援 OpenGL ES 3.1 或 3.2，並正確回報。
• [C-1-5] 必須宣傳支援 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、EGL_EXT_gl_colorspace_display_p3、EGL_EXT_gl_colorspace_display_p3_linear 和 EGL_EXT_gl_colorspace_display_p3_passthrough 擴充功能。
• [C-SR] Are STRONGLY RECOMMENDED to support GL_EXT_sRGB.

反之，如果裝置實作項目不支援廣色域螢幕，則：

• [C-2-1] 應涵蓋 CIE 1931 xyY 空間中 100% 以上的 sRGB，但螢幕色域未定義。

7.1.5. 舊版應用程式相容模式

Android 會指定「相容模式」，讓架構以「正常」螢幕大小 (寬度為 320 dp) 模式運作，以利舊版應用程式使用。這些應用程式是針對舊版 Android 開發，不支援螢幕大小獨立性。

7.1.6. 螢幕技術

Android 平台包含多個 API，可讓應用程式在 Android 相容螢幕上算繪豐富的圖像。除非本文另有規定，否則裝置必須支援 Android SDK 定義的所有 API。

裝置實作的所有 Android 相容螢幕：

• [C-0-1] MUST be capable of rendering 16-bit color graphics.
• SHOULD support displays capable of 24-bit color graphics.
• [C-0-2] 必須能夠算繪動畫。
• [C-0-3] 像素長寬比 (PAR) 必須介於 0.9 和 1.15 之間。也就是說，像素顯示比例必須接近正方形 (1.0)，容許 10% 至 15% 的誤差。

7.1.7. 第二螢幕

Android 支援與 Android 相容的第二螢幕，可啟用媒體分享功能，並提供開發人員 API 來存取外接螢幕。

如果裝置實作支援外接螢幕 (透過有線、無線或內建額外螢幕連線)，則：

• [C-1-1] 必須按照 Android SDK 說明文件所述，實作 DisplayManager 系統服務和 API。

7.2. 輸入裝置

裝置實作方式：

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

7.2.1. 鍵盤

如果裝置實作項目包含第三方輸入法編輯器 (IME) 應用程式的支援功能，則：

• [C-1-1] 必須宣告 android.software.input_methods 功能旗標。
• [C-1-2] 必須完整實作 Input Management Framework
• [C-1-3] 必須預先安裝軟體鍵盤。

裝置實作：* [C-0-1] 不得包含與 android.content.res.Configuration.keyboard 中指定格式 (QWERTY 或 12 鍵) 不符的實體鍵盤。* 應包含額外的螢幕鍵盤實作項目。* 可能包含實體鍵盤。

7.2.2. 非觸控導覽

Android 支援 D-Pad、滾球和滾輪，做為非觸控導覽機制。

裝置實作方式：

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

如果裝置實作項目缺少非觸控導覽功能，則：

• [C-1-1] 必須提供合理的替代使用者介面機制，以選取及編輯文字，且須與輸入管理引擎相容。上游 Android 開放原始碼實作項目包含選取機制，適用於沒有非觸控導覽輸入內容的裝置。

7.2.3. 瀏覽鍵

主畫面、最近使用的應用程式和返回功能通常是透過與專用實體按鈕或觸控螢幕特定部分的互動提供，對於 Android 導覽模式至關重要，因此裝置實作項目：

• [C-0-1] 必須提供使用者介面，啟動已安裝的應用程式，這些應用程式的活動已將 <intent-filter> 設為 ACTION=MAIN，且電視裝置實作項目為 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER。「首頁」功能應做為這項使用者輔助功能的機制。
• 應提供「最近使用」和「返回」功能的按鈕。

如果提供「首頁」、「最近使用」或「返回」功能，這些功能：

• [C-1-1] 只要其中任一項目可存取，就必須透過單一動作 (例如輕觸、按兩下或手勢) 存取。
• [C-1-2] 必須清楚指出哪個單一動作會觸發每個函式。例如在按鈕上印製可見的圖示、在螢幕的導覽列部分顯示軟體圖示，或是在開箱設定體驗期間，引導使用者逐步完成示範流程。

裝置實作方式：

• [SR] are STRONGLY RECOMMENDED to not provide the input mechanism for the Menu function as it is deprecated in favor of action bar since Android 4.0.

如果裝置實作提供「選單」功能，則：

• [C-2-1] 只要動作溢位選單彈出式視窗不為空白，且動作列可見，就必須顯示動作溢位按鈕。
• [C-2-2] 不得修改透過選取動作列中的溢位按鈕顯示的動作溢位彈出式視窗位置，但可修改透過選取「選單」功能顯示的動作溢位彈出式視窗位置。

如果裝置實作項目未提供「選單」功能，為確保回溯相容性，建議您：* [C-SR] 強烈建議在 targetSdkVersion 小於 10 時，透過實體按鈕、軟體鍵或手勢，向應用程式提供「選單」功能。除非與其他導覽功能一併隱藏，否則應該可以存取這個「選單」功能。

如果裝置實作項目提供輔助功能，則：

• [C-4-1] 必須在其他導覽鍵可供存取時，透過單一動作 (例如輕觸、按兩下或手勢) 存取「Google 助理」功能。
• [SR] STRONGLY RECOMMENDED to use long press on HOME function as this designated interaction.

如果裝置實作項目使用螢幕的特定部分顯示導覽鍵，則：

• [C-5-1] 導覽鍵必須使用螢幕上應用程式無法存取的獨立部分，且不得遮蔽或干擾應用程式可用的螢幕部分。
• [C-5-2] 必須提供部分螢幕畫面給應用程式，且該部分須符合第 7.1.1 節定義的規定。
• [C-5-3] 必須遵守應用程式透過 View.setSystemUiVisibility() API 方法設定的標記，以便正確隱藏螢幕的這部分 (即導覽列)，如 SDK 說明文件所述。

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() 只能用於回報「首頁」手勢辨識區域。
• [C-6-2] 手勢必須在排除矩形內啟動 (由前景應用程式透過 View#setSystemGestureExclusionRects() 提供)，但不得在 WindowInsets#getMandatorySystemGestureInsets() 之外，只要排除矩形符合 View#setSystemGestureExclusionRects() 文件中指定的排除上限，就不得攔截導覽功能。
• [C-6-3] 如果先前已將 MotionEvent.ACTION_DOWN 事件傳送至前景應用程式，則在開始攔截系統手勢的觸控事件後，必須將 MotionEvent.ACTION_CANCEL 事件傳送至前景應用程式。
• [C-6-4] 必須提供使用者介面，讓使用者切換至以按鈕為基礎的螢幕上導覽 (例如在「設定」中)。
• SHOULD 提供主畫面功能，方法是從螢幕目前方向的底部邊緣向上滑動。
• SHOULD 提供「最近」功能，使用者在與「首頁」手勢相同的區域向上滑動並按住螢幕後放開，即可使用這項功能。
• 在 WindowInsets#getMandatorySystemGestureInsets() 內啟動的手勢「不應」受到前景應用程式透過 View#setSystemGestureExclusionRects() 提供的排除矩形影響。

如果螢幕目前的方向在左右兩側邊緣提供導覽功能：

• [C-7-1] 導覽功能必須是「返回」，且必須提供從螢幕目前方向的左右兩側邊緣滑動的手勢。
• [C-7-2] 如果在左側或右側邊緣提供可自訂滑動的系統面板，這些面板必須放置在畫面頂端 1/3 處，並清楚顯示持續的視覺指標，指出拖曳會叫用上述面板，因此不會返回。使用者「可以」設定系統面板，使其位於螢幕邊緣頂端 1/3 處下方，但系統面板「不得」使用超過邊緣 1/3 的長度。
• [C-7-3] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 標記，從邊緣滑動時的行為必須與 AOSP 實作方式相同，詳情請參閱 SDK。
• [C-7-4] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 旗標，自訂可滑動系統面板必須隱藏，直到使用者帶入系統資訊列 (即導覽列和狀態列)，如 AOSP 實作方式所示。

7.2.4. 觸控螢幕輸入

Android 支援多種指標輸入系統，例如觸控螢幕、觸控板和模擬觸控輸入裝置。觸控螢幕裝置的實作方式會與螢幕相關聯，讓使用者感覺自己是直接操作螢幕上的項目。由於使用者是直接觸控螢幕，因此系統不需要任何額外的可供性，即可指出正在操控的物件。

裝置實作方式：

• 應具備某種指標輸入系統 (類似滑鼠或觸控)。
• SHOULD support fully independently tracked pointers.

如果裝置實作項目包含觸控螢幕 (單點觸控或更佳)，則：

• [C-1-1] 必須回報 TOUCHSCREEN_FINGER Configuration.touchscreen API 欄位。
• [C-1-2] 必須回報 android.hardware.touchscreen 和 android.hardware.faketouch 功能旗標。

如果裝置實作項目包含可追蹤多點觸控的觸控螢幕，則：

• [C-2-1] 必須回報與裝置上特定觸控螢幕類型相應的適當功能旗標 android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand。

如果裝置實作項目不含觸控螢幕 (僅依賴指標裝置)，且符合第 7.2.5 節中的觸控模擬規定，則：

• [C-3-1] 不得回報任何以 android.hardware.touchscreen 開頭的功能旗標，且只能回報 android.hardware.faketouch。

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] 必須支援指標按下，然後允許使用者快速將物件移至螢幕上的不同位置，接著指標在螢幕上放開，讓使用者在螢幕上甩動物件。
• [C-1-7] 必須回報 TOUCHSCREEN_NOTOUCH 的 Configuration.touchscreen API 欄位。

如果裝置實作項目聲明支援 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. 按鈕對應

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

• [C-1-1] 必須內建控制器，或在盒裝中附上獨立控制器，以提供輸入下表所列所有事件的方法。
• [C-1-2] 必須能夠將 HID 事件對應至相關聯的 Android view.InputEvent 常數，如下表所示。上游 Android 實作項目包含滿足這項需求的遊戲控制器實作項目。

1 KeyEvent

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

3 這項用法的邏輯最小值必須為 0、邏輯最大值必須為 7、實體最小值必須為 0、實體最大值必須為 315、單位必須為度，且報表大小必須為 4。邏輯值定義為從垂直軸順時針旋轉；舉例來說，邏輯值為 0 代表未旋轉且按下向上按鈕，邏輯值為 1 則代表旋轉 45 度且按下向上和向左鍵。

4 MotionEvent

1 MotionEvent

7.2.7. 遙控器

如需裝置專屬需求，請參閱第 2.3.1 節。

7.3. 感應器

如果裝置實作包含特定感應器類型，且有對應的第三方開發人員 API，裝置實作「必須」實作該 API，如 Android SDK 說明文件和 Android 開放原始碼說明文件 (感應器) 所述。

裝置實作方式：

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

如果裝置實作項目包含特定感應器類型，且第三方開發人員可使用對應的 API，則：

• [C-1-1] 必須回報所有感應器測量值，並針對 Android SDK 說明文件中定義的每種感應器類型，使用相關的國際單位制 (公制) 值。
• [C-1-2] 如果應用程式處理器處於活動狀態，且感應器串流的最大要求延遲時間為 0 毫秒，則感應器資料的延遲時間上限為 100 毫秒 + 2 * sample_time。這項延遲不包括任何篩選延遲。
• [C-1-3] 感應器啟動後，必須在 400 毫秒 + 2 * sample_time 內回報第一個感應器樣本。這個樣本的準確率為 0 也是可以接受的。

• [SR] SHOULD report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock. 強烈建議現有和新的 Android 裝置符合這些需求，以便升級至日後的平台版本，因為這可能成為必要元件。同步錯誤應低於 100 毫秒。

• [C-1-4] 對於 Android SDK 說明文件指出為「連續感應器」的任何 API，裝置實作項目必須持續提供週期性資料樣本，且樣本的抖動應低於 3%，其中抖動定義為連續事件之間回報時間戳記值差異的標準差。

• [C-1-5] MUST ensure that the sensor event stream MUST NOT prevent the device CPU from entering a suspend state or waking up from a suspend state.

• 啟動多個感應器時，耗電量「不應」超過個別感應器回報耗電量的總和。

上述清單並非詳盡無遺，Android SDK 和 Android 開放原始碼文件中的感應器行為說明才是權威資訊。

部分感應器類型是複合類型，也就是說，這類感應器可從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速度感應器)。

裝置實作方式：

• 如果包含感應器類型所述的必要實體感應器，就「應該」實作這些感應器類型。

如果裝置實作項目包含複合感應器，則：

• [C-2-1] 必須按照 Android 開放原始碼說明文件中的複合感應器說明，實作感應器。

7.3.1. 加速計

裝置實作方式：

• [C-SR] 強烈建議加入 3 軸式加速度計。

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

• [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
• [C-1-2] 必須導入及回報 TYPE_ACCELEROMETER 感應器。
• [C-1-3] 必須遵守 Android API 中詳述的 Android 感應器座標系統。
• [C-1-4] MUST be capable of measuring from freefall up to four times the gravity(4g) or more on any axis.
• [C-1-5] 必須具備至少 12 位元的解析度。
• [C-1-6] 標準差不得大於 0.05 m/s^，且標準差應以最快取樣率，根據至少 3 秒內收集的樣本，按軸計算。
• [SR] 建議 STRONGLY 實作 TYPE_SIGNIFICANT_MOTION 複合感應器。
• [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. 強烈建議 Android 裝置符合這項規定，以便升級至日後的平台版本，屆時這項規定可能成為必要條件。
• 應實作 Android SDK 文件所述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。
• SHOULD report events up to at least 200 Hz.
• 解析度應至少為 16 位元。
• 如果特性在生命週期內發生變化，則應在使用時校準並補償，且在裝置重新啟動時保留補償參數。
• SHOULD be temperature compensated。

如果裝置實作項目包含 3 軸式加速度計，且實作了 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器中的任一項：

• [C-2-1] 這些裝置的耗電量總和必須一律低於 4 mW。
• 在動態或靜態條件下，各項的功率應低於 2 mW 和 0.5 mW。

如果裝置實作項目包含 3 軸式加速度計和 3 軸式迴轉儀感應器，則：

• [C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
• [C-SR] 強烈建議實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。

如果裝置實作項目包含 3 軸式加速度計、3 軸式迴轉儀感應器和磁力儀感應器，則：

• [C-4-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

7.3.2. 磁力儀

裝置實作方式：

• [C-SR] 強烈建議加入 3 軸式磁力儀 (指南針)。

如果裝置實作項目包含 3 軸磁力計，則：

• [C-1-1] 必須實作 TYPE_MAGNETIC_FIELD 感應器。
• [C-1-2] 必須能夠以至少 10 Hz 的頻率回報事件，且應以至少 50 Hz 的頻率回報事件。
• [C-1-3] 必須遵守 Android API 中詳述的 Android 感應器座標系統。
• [C-1-4] 飽和前，必須能夠測量每個軸上介於 -900 µT 和 +900 µT 之間的值。
• [C-1-5] 必須將硬鐵偏移值設為小於 700 µT，且應設為小於 200 µT，方法是將磁力計遠離動態 (電流感應) 和靜態 (磁鐵感應) 磁場。
• [C-1-6] 必須具有等於或高於 0.6 µT 的解析度。
• [C-1-7] MUST support online calibration and compensation of the hard iron bias, and preserve the compensation parameters between device reboots.
• [C-1-8] 必須套用軟鐵補償，校準作業可在裝置使用中或生產期間進行。
• [C-1-9] 必須有標準差，且以最快取樣率在至少 3 秒內收集的樣本為基礎，按軸計算標準差，不得超過 1.5 µT；標準差應不超過 0.5 µT。
• 應實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。
• [SR] 強烈建議現有和新的 Android 裝置實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。

如果裝置實作項目包含 3 軸磁力儀、加速計感應器和 3 軸式迴轉儀感應器，則：

• [C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作項目包含 3 軸磁力計和加速度計，則：

• MAY 實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。

如果裝置實作項目包含 3 軸磁力儀、加速計和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器，則：

• [C-3-1] MUST consume less than 10 mW.
• 感應器以 10 Hz 註冊為批次模式時，耗電量「應」低於 3 mW。

7.3.3. GPS

裝置實作方式：

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

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

• [C-1-1] 透過 LocationManager#requestLocationUpdate 要求時，必須支援至少 1 Hz 的位置輸出速率。
• [C-1-2] 連線至 0.5 Mbps 以上的網際網路時，裝置「必須」能在空曠環境 (訊號強、多路徑可忽略、HDOP < 2) 中，於 10 秒內判斷位置 (快速首次定位)。通常只要使用某種形式的輔助或預測 GPS/GNSS 技術，即可縮短 GPS/GNSS 鎖定時間 (輔助資料包括參考時間、參考位置和衛星星曆/時鐘)，即可滿足這項需求。
  • [C-1-6] 進行這類位置計算後，裝置實作必須在 5 秒內判斷位置 (空曠處)，即使後續要求是在沒有資料連線的情況下提出，和/或是在電源循環後提出，也必須在初始位置計算後一小時內完成。

• 在空曠處判斷位置後，靜止不動或以低於每秒平方公尺 1 公尺的加速度移動時：

  • [C-1-3] 至少 95% 的時間內，裝置必須能夠判斷 20 公尺內的所在位置，以及 0.5 公尺/秒內的移動速度。
  • [C-1-4] 必須透過 GnssStatus.Callback 同時追蹤及回報至少 8 顆來自單一衛星群的衛星。
  • 應能同時追蹤多個星群的至少 24 顆衛星 (例如 GPS + 至少一個全球導航衛星系統、北斗、伽利略)。
  • [C-SR] 強烈建議在緊急電話通話期間，繼續透過 GNSS 定位供應商 API 提供正常的 GPS/GNSS 位置輸出內容。
  • [C-SR] 強烈建議回報所有追蹤的 GNSS 星座圖 (如 GnssStatus 訊息所回報) 的 GNSS 測量結果，但 SBAS 除外。
  • [C-SR] 強烈建議回報 AGC 和 GNSS 測量頻率。
  • [C-SR] 強烈建議回報所有準確度估計值 (包括方位、速度和垂直)，做為每個 GPS/GNSS 位置的一部分。
  • [C-SR] 強烈建議您在發現 GNSS 測量資料時立即回報，即使尚未回報從 GPS/GNSS 計算出的位置資訊也沒關係。
  • [C-SR] 強烈建議回報 GNSS 虛擬距離和虛擬距離變化率，在空曠環境中判斷位置後，當裝置靜止或以小於每平方秒 0.2 公尺的加速度移動時，這些資料應足以在至少 95% 的時間內，將位置計算在 20 公尺內，速度計算在每秒 0.2 公尺內。

7.3.4. 陀螺儀

裝置實作方式：

• [C-SR] 強烈建議加入陀螺儀感應器，除非也加入 3 軸式加速度計。

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

• [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
• [C-1-2] 必須實作 TYPE_GYROSCOPE 感應器，強烈建議同時實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。
• [C-1-4] 必須為 12 位元以上的解析度，建議為 16 位元以上的解析度。
• [C-1-5] MUST be temperature compensated.
• [C-1-6] 必須在使用時校正和補償，並在裝置重新啟動時保留補償參數。
• [C-1-7] 每 Hz 的變異數不得大於 1e-7 rad^2 / s^2 (每 Hz 的變異數，或 rad^2 / s)。變異數可隨取樣率而異，但必須受此值限制。換句話說，如果以 1 Hz 的取樣率測量陀螺儀的變異數，則變異數「不應」大於 1e-7 rad^2/s^2。
• [SR] 裝置在室溫下靜止不動時，強烈建議校準誤差小於 0.01 rad/s。
• SHOULD report events up to at least 200 Hz.

如果裝置實作項目包含 3 軸式迴轉儀、加速計感應器和磁力儀感應器，則：

• [C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作項目包含 3 軸式加速度計和 3 軸式迴轉儀感應器，則：

• [C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
• [C-SR] 強烈建議實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。

7.3.5. 氣壓計

裝置實作方式：

• [C-SR] 建議包含氣壓計 (環境氣壓感應器)。

如果裝置實作項目包含氣壓計，則：

• [C-1-1] 必須導入及回報 TYPE_PRESSURE 感應器。
• [C-1-2] 必須能夠以 5 Hz 以上的頻率傳送事件。
• [C-1-3] MUST be temperature compensated.
• [SR] STRONGLY RECOMMENDED to be able to report pressure measurements in the range 300hPa to 1100hPa.
• 應具有 1 hPa 的絕對準確度。
• 在 20 hPa 範圍內，相對準確度應為 0.12 hPa (相當於海平面上 ~200 公尺變化範圍內，準確度為 ~1 公尺)。

7.3.6. 溫度計

裝置實作方式：

• 可能包含環境溫度計 (溫度感應器)。
• MAY but SHOULD NOT include a CPU temperature sensor.

如果裝置實作項目包含環境溫度計 (溫度感應器)，則：

• [C-1-1] 必須定義為 SENSOR_TYPE_AMBIENT_TEMPERATURE，且必須測量使用者與裝置互動時的環境 (室內/車輛駕駛室) 溫度，以攝氏度為單位。
• [C-1-2] 必須定義為 SENSOR_TYPE_TEMPERATURE。
• [C-1-3] 必須測量裝置 CPU 的溫度。
• [C-1-4] 不得測量任何其他溫度。

請注意，Android 4.0 已淘汰 SENSOR_TYPE_TEMPERATURE 感應器類型。

7.3.7. 光度計

• 裝置實作「可能」包含光度計 (環境光感應器)。

7.3.8. 鄰近感應器

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

如果裝置實作項目包含鄰近感應器，則：

• [C-1-1] MUST measure the proximity of an object in the same direction as the screen. 也就是說，近接感應器「必須」朝向螢幕，偵測靠近螢幕的物體，因為這類感應器的主要用途是偵測使用者是否正在使用手機。如果裝置實作項目包含任何其他方向的距離感應器，則「不得」透過這個 API 存取。
• [C-1-2] 必須具有 1 位元以上的準確度。

7.3.9. 高精確度感應器

如果裝置實作項目包含本節定義的一組高品質感應器，並提供給第三方應用程式使用，則：

• [C-1-1] 必須透過 android.hardware.sensor.hifi_sensors 功能旗標識別功能。

如果裝置實作項目宣告 android.hardware.sensor.hifi_sensors，則：

• [C-2-1] 必須具備 TYPE_ACCELEROMETER 感應器，且：

  • 測量範圍必須至少介於 -8g 和 +8g 之間，測量範圍應至少介於 -16g 和 +16g 之間。
  • 測量解析度必須至少為 2048 LSB/g。
  • 測量頻率必須至少為 12.5 Hz 或更低。
  • 最大測量頻率必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
  • 測量雜訊不得超過 400 μg/√Hz。
  • 必須實作這項感應器的非喚醒形式，且緩衝功能至少要能處理 3000 個感應器事件。
  • 批次處理耗電量不得超過 3 mW。
  • [C-SR] 強烈建議 3 dB 測量頻寬至少為奈奎斯特頻率的 80%，且此頻寬內的白噪音頻譜。
  • 在室溫下測試時，加速度隨機漫步應小於 30 μg √Hz。
  • 相較於溫度，偏差變化「應」為 ≤ +/- 1 mg/°C。
  • 最佳擬合線非線性應 ≤ 0.5%，感應度變化與溫度變化比應 ≤ 0.03%/C°。
  • 在裝置作業溫度範圍內，應具有 < 2.5 % 的跨軸向靈敏度，以及 < 0.2% 的跨軸向靈敏度變化。

• [C-2-2] 必須具有與 TYPE_ACCELEROMETER 相同的品質要求。TYPE_ACCELEROMETER_UNCALIBRATED

• [C-2-3] 必須具備 TYPE_GYROSCOPE 感應器，且：

  • 測量範圍必須至少介於 -1000 和 +1000 dps 之間。
  • 測量解析度必須至少為 16 LSB/dps。
  • 測量頻率必須至少為 12.5 Hz 或更低。
  • 最大測量頻率必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
  • 測量雜訊必須不超過 0.014°/s/√Hz。
  • [C-SR] 強烈建議 3 dB 測量頻寬至少為奈奎斯特頻率的 80%，且此頻寬內的白噪音頻譜。
  • 在室溫下測試時，隨機漫步速率應小於 0.001 °/s √Hz。
  • SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C.
  • 相較於溫度，靈敏度變化應 ≤ 0.02% / °C。
  • 最佳適配線非線性度應 ≤ 0.2%。
  • 噪音密度應 ≤ 0.007 °/s/√Hz。
  • 裝置靜止時，在 10 ~ 40 ℃ 的溫度範圍內，校正誤差應小於 0.002 rad/s。
  • SHOULD have g-sensitivity less than 0.1°/s/g.
  • 在裝置運作溫度範圍內，應具備 < 4.0 % 的交叉軸靈敏度，以及 < 0.3% 的交叉軸靈敏度變化。

• [C-2-4] 必須具備與 TYPE_GYROSCOPE 相同的品質要求。TYPE_GYROSCOPE_UNCALIBRATED

• [C-2-5] 必須具備 TYPE_GEOMAGNETIC_FIELD 感應器，且：

  • 測量範圍必須至少介於 -900 至 +900 μT。
  • 測量解析度必須至少為 5 LSB/uT。
  • 測量頻率必須至少為 5 Hz 或更低。
  • 測量頻率上限必須為 50 Hz 以上。
  • 測量雜訊不得超過 0.5 uT。

• [C-2-6] 必須有 TYPE_MAGNETIC_FIELD_UNCALIBRATED，且品質規定與 TYPE_GEOMAGNETIC_FIELD 相同，此外：

  • 必須實作這項感應器的非喚醒形式，且緩衝功能至少要能處理 600 個感應器事件。
  • [C-SR] 如果回報率為 50 Hz 以上，強烈建議白噪音頻譜至少要介於 1 Hz 到 10 Hz 之間。

• [C-2-7] 必須具備 TYPE_PRESSURE 感應器，且：

  • 測量範圍必須介於 300 至 1100 hPa 之間。
  • 測量解析度必須至少為 80 LSB/hPa。
  • 測量頻率必須為 1 Hz 以下。
  • 測量頻率上限必須為 10 Hz 以上。
  • 測量噪音不得超過 2 Pa/√Hz。
  • 必須實作這類感應器的非喚醒形式，且緩衝功能至少要能處理 300 個感應器事件。
  • 批次處理耗電量不得超過 2 mW。
• [C-2-8] 必須具備 TYPE_GAME_ROTATION_VECTOR 感應器。
• [C-2-9] 必須具備 TYPE_SIGNIFICANT_MOTION 感應器，且：
  • 裝置靜止時的耗電量不得超過 0.5 mW，移動時不得超過 1.5 mW。
• [C-2-10] 必須具備 TYPE_STEP_DETECTOR 感應器，且：
  • 必須實作這項感應器的非喚醒形式，且緩衝功能至少要能處理 100 個感應器事件。
  • 裝置靜止時的耗電量不得超過 0.5 mW，移動時不得超過 1.5 mW。
  • 批次處理耗電量不得超過 4 mW。
• [C-2-11] 必須具備 TYPE_STEP_COUNTER 感應器，且：
  • 裝置靜止時的耗電量不得超過 0.5 mW，移動時不得超過 1.5 mW。
• [C-2-12] 必須具備 TILT_DETECTOR 感應器，且：
  • 裝置靜止時的耗電量不得超過 0.5 mW，移動時不得超過 1.5 mW。
• [C-2-13] 加速度計、陀螺儀和磁力計回報的同一實體事件，其事件時間戳記彼此間的差異不得超過 2.5 毫秒。加速度計和陀螺儀回報的同一實體事件，其事件時間戳記的差異應在 0.25 毫秒內。
• [C-2-14] 陀螺儀感應器事件時間戳記必須與攝影機子系統的時間基準相同，且誤差在 1 毫秒內。
• [C-2-15] MUST deliver samples to applications within 5 milliseconds from the time when the data is available on any of the above physical sensors to the application.
• [C-2-16] 啟用下列任一感應器組合時，裝置靜止時的耗電量不得超過 0.5 mW，移動時不得超過 2.0 mW：
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] MAY have a TYPE_PROXIMITY sensor, but if present MUST have a minimum buffer capability of 100 sensor events.

請注意，本節中的所有耗電量規定都不包含應用程式處理器的耗電量。包括整個感應器鏈結的耗電量，例如感應器、任何支援電路、任何專用感應器處理系統等。

如果裝置實作項目包含直接感應器支援，則：

• [C-3-1] 必須透過 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API，正確宣告支援的直接管道類型和直接回報率層級。
• [C-3-2] 對於聲明支援感應器直接管道的所有感應器，都必須支援至少一種感應器直接管道類型。
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• SHOULD support event reporting through sensor direct channel for primary sensor (non-wakeup variant) of the following types:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生物辨識感應器

如要進一步瞭解如何評估生物辨識解鎖安全性，請參閱「評估生物辨識安全性」文件。

如果裝置實作項目包含安全螢幕鎖定，則：

• 應包含生物辨識感應器

生物特徵辨識感應器可根據其詐欺和冒用接受率，以及生物特徵辨識管道的安全性，分類為「強效」、「弱效」或「便利」。這項分類會決定生物特徵辨識感應器與平台和第三方應用程式介接時必須具備的功能。感應器預設會歸類為「便利性」，如要歸類為「弱」或「強」，則須符合下列額外規定。弱和強生物特徵辨識驗證都會獲得額外功能，詳情如下。

如要讓第三方應用程式使用生物特徵辨識感應器，裝置實作項目必須：

• [C-0-1] 必須符合本文件定義的「嚴密」或「寬鬆」生物特徵辨識要求。

如要允許第三方應用程式存取金鑰儲存區金鑰，請在裝置實作中：

• [C-0-2] 必須符合本文定義的「強」要求。

此外：

• [C-0-3] 如果強生物特徵辨識是處於被動狀態 (例如臉部或虹膜辨識，沒有使用者意圖的明確信號)，則「必須」搭配明確的確認動作 (例如按下按鈕)。
  • [C-SR] 強烈建議確保被動式生物特徵辨識的確認動作安全無虞，作業系統或核心遭到入侵時，才不會遭到偽造。舉例來說，這表示根據實體按鈕執行的確認動作，會透過安全元件 (SE) 的輸入專用通用輸入/輸出 (GPIO) 接腳傳送，且只能透過按下實體按鈕驅動。

如果裝置實作項目希望將生物特徵辨識感應器視為「便利性」，則：

• [C-1-1] 誤接受率必須低於 0.002%。
• [C-1-2] 如果接受偽造和冒用身分的比率高於 7%，則必須揭露此模式的安全性可能低於高強度 PIN 碼、解鎖圖案或密碼，並清楚列舉啟用此模式的風險。
• [C-1-3] 生物特徵辨識驗證失敗五次後，必須限制嘗試次數，至少 30 秒內不得再嘗試驗證。驗證失敗是指擷取品質足夠 (BIOMETRIC_ACQUIRED_GOOD)，但與已註冊的生物特徵辨識資料不符。
• [C-1-4] 必須先建立信任鏈，讓使用者確認現有或新增受 TEE 保護的裝置憑證 (PIN 碼/圖案/密碼)，才能防止新增生物特徵辨識資訊；Android 開放原始碼專案實作會在架構中提供相關機制。
• [C-1-5] 使用者帳戶移除時 (包括透過恢復原廠設定)，必須完全移除所有可識別的使用者生物特徵辨識資料。
• [C-1-6] 必須遵守該生物特徵辨識的個別標記 (即 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS)。
• [C-1-7] 對於搭載 Android 10 的新裝置，系統必須每 24 小時或更短時間，要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼)；對於從舊版 Android 升級的裝置，系統必須每 72 小時或更短時間，要求使用者進行建議的主要驗證。

• [C-1-8] 在下列情況發生後，必須要求使用者進行建議的主要驗證 (例如：PIN 碼、解鎖圖案、密碼)：

  • 4 小時的閒置逾時期限，或
  • 生物辨識驗證失敗 3 次。
  • 成功確認裝置憑證後，閒置逾時時間和驗證失敗次數就會重設。

  如果裝置是從舊版 Android 升級，則可免除 C-1-8 規定。

• [C-SR] 強烈建議裝置上的誤拒率低於 10%。

• [C-SR] 建議每項已註冊的生物特徵辨識功能，從偵測到生物特徵辨識資訊到螢幕解鎖，延遲時間都應低於 1 秒。

如果裝置實作項目希望將生物特徵辨識感應器視為「弱」，則：

• [C-2-1] 必須符合上述「便利性」的所有規定，[C-1-2] 除外。
• [C-2-2] 必須確保接受冒用和冒充身分者的比率不超過 20%。
• [C-2-3] 必須實作硬體支援的金鑰儲存區，並在 Android 使用者或核心空間以外的獨立執行環境中執行生物特徵辨識比對，例如受信任的執行環境 (TEE)，或在與獨立執行環境之間有安全通道的晶片上執行。
• [C-2-4] 必須加密所有可識別資料，並以密碼編譯方式驗證，確保這些資料無法在獨立執行環境外取得、讀取或變更，或透過與獨立執行環境的安全管道取得，如 Android 開放原始碼計畫網站上的實作指南所述。
• [C-2-5] 進行攝影機生物辨識驗證或註冊時：
  • 攝影機必須以某種模式運作，確保攝影機畫面不會在隔離的執行環境外遭讀取或變更，或透過安全管道傳輸至隔離的執行環境。
  • 如果是 RGB 單一攝影機解決方案，攝影機影格「可以」在獨立執行環境外讀取，以支援註冊預覽等作業，但「不得」變更。
• [C-2-6] 不得允許第三方應用程式區分個別生物特徵辨識註冊。
• [C-2-7] 不得允許在 TEE 環境以外，以未加密的方式存取可識別的生物特徵辨識資料或任何衍生資料 (例如嵌入)。

• [C-2-8] 必須具備安全的處理管道，確保作業系統或核心遭到入侵時，資料不會直接注入，以錯誤方式驗證使用者身分。

  如果裝置實作項目已在舊版 Android 上推出，且無法透過系統軟體更新滿足 C-2-8 要求，則「可能」可免除這項要求。

如果裝置實作項目希望將生物特徵辨識感應器視為「強」，則：

• [C-3-1] 必須符合上述「弱」的所有規定。從舊版 Android 升級的裝置仍須遵守 C-2-7 規定。
• [C-3-2] 必須將仿冒和冒名接受率控制在 7% 以下。
• [C-3-3] 必須每隔 72 小時或更短時間，要求使用者進行建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼)。

7.3.12. 姿勢感應器

裝置實作方式：

• 可能支援 6 自由度姿勢感應器。

如果裝置實作支援 6 自由度姿勢感應器，則：

• [C-1-1] 必須導入及回報 TYPE_POSE_6DOF 感應器。
• [C-1-2] 必須比單獨的旋轉向量更準確。

7.4. 資料連線

7.4.1. 電話通訊系統

Android API 和本文所指的「電話」專指透過 GSM 或 CDMA 網路撥打語音電話及傳送簡訊的相關硬體。雖然這些語音通話可能採用封包交換技術，也可能沒有，但就 Android 而言，這些通話與使用相同網路實作的任何資料連線無關。換句話說，Android「電話」功能和 API 專指語音通話和簡訊。舉例來說，無論裝置是否使用行動網路連線傳輸資料，只要無法撥打電話或傳送/接收簡訊，就不屬於電話裝置。

• Android 可用於不含電話硬體的裝置。也就是說，Android 可與手機以外的裝置相容。

如果裝置實作項目包含 GSM 或 CDMA 電話通訊，則：

• [C-1-1] 必須根據技術宣告 android.hardware.telephony 功能旗標和其他子功能旗標。
• [C-1-2] 必須完整支援該技術的 API。

如果裝置實作項目不含電話硬體，則：

• [C-2-1] MUST implement the full APIs as no-ops.

如果裝置實作作業支援 eUICC 或 eSIM/嵌入式 SIM 卡，並包含專屬機制，可供第三方開發人員使用 eSIM 功能，則：

• [C-3-1] 必須提供 EuiccManager API 的完整實作。

7.4.1.1. 號碼封鎖功能適用性

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

• [C-1-1] 必須支援號碼封鎖功能
• [C-1-2] 必須按照 SDK 說明文件所述，完整實作 BlockedNumberContract 和對應的 API。
• [C-1-3] MUST block all calls and messages from a phone number in 'BlockedNumberProvider' without any interaction with apps. 唯一的例外狀況是暫時解除號碼封鎖，詳情請參閱 SDK 說明文件。
• [C-1-4] 針對遭封鎖的通話，不得寫入平台通話記錄供應商。
• [C-1-5] MUST NOT write to the Telephony provider for a blocked message.
• [C-1-6] 必須實作封鎖號碼管理 UI，並使用 TelecomManager.createManageBlockedNumbersIntent() 方法傳回的意圖開啟該 UI。
• [C-1-7] Android 平台會假設主要使用者完全控管裝置上的電話服務 (單一執行個體)，因此不得允許次要使用者查看或編輯裝置上封鎖的號碼。次要使用者必須隱藏所有封鎖相關的 UI，且系統仍須遵守封鎖清單。
• 裝置更新至 Android 7.0 時，應將封鎖的號碼遷移至供應商。

7.4.1.2. Telecom API

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

• [C-1-1] 必須支援 SDK 中說明的 ConnectionService API。
• [C-1-2] 如果使用者正在通話，且通話是由不支援 CAPABILITY_SUPPORT_HOLD 指定暫停功能的第三方應用程式發起，則必須顯示新的來電，並提供使用者接受或拒絕來電的選項。
• [C-1-3] 必須有實作 InCallService 的應用程式。

• [C-SR] 強烈建議通知使用者，接聽來電會中斷進行中的通話。

  AOSP 實作項目會透過即時通知，向使用者指出接聽來電會導致其他通話中斷，藉此滿足這些需求。

• [C-SR] STRONGLY RECOMMENDED to preload the default dialer app that shows a call log entry and the name of a third-party app in its call log when the third-party app sets the EXTRA_LOG_SELF_MANAGED_CALLS extras key on its PhoneAccount to true.

• [C-SR] 強烈建議處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，以用於 android.telecom API，如下所示：
  • 在通話期間偵測到按鍵事件的短按時，請呼叫 Connection.onDisconnect()。
  • 在來電期間偵測到按鍵事件的短按時，請呼叫 Connection.onAnswer()。
  • 在來電期間偵測到按鍵事件長按時，請呼叫 Connection.onReject()。
  • 切換 CallAudioState 的靜音狀態。

7.4.2. IEEE 802.11 (Wi-Fi)

裝置實作方式：

• 應支援一或多種 802.11 形式。

如果裝置實作項目支援 802.11，並將這項功能公開給第三方應用程式，則：

• [C-1-1] 必須實作對應的 Android API。
• [C-1-2] MUST report the hardware feature flag android.hardware.wifi.
• [C-1-3] 必須按照 SDK 說明文件所述，實作多播 API。
• [C-1-4] 必須支援多點傳送 DNS (mDNS)，且不得在任何作業時間 (包括：) 篩選 mDNS 封包 (224.0.0.251)：
  • 即使螢幕未處於啟用狀態。
  • 對於 Android 電視裝置實作，即使處於待機電源狀態也是如此。
• [C-1-5] 不得將 WifiManager.enableNetwork() API 方法呼叫視為充分的指標，藉此切換目前用於應用程式流量的預設 Network，以及 ConnectivityManager API 方法 (例如 getActiveNetwork 和 registerDefaultNetworkCallback) 傳回的 Network。換句話說，只有在成功驗證 Wi-Fi 網路提供網際網路存取權時，他們「可能」才會停用任何其他網路供應商 (例如行動數據) 提供的網際網路存取權。
• [C-1-6] 強烈建議在呼叫 ConnectivityManager.reportNetworkConnectivity() API 方法時，重新評估 Network 的網際網路存取權，一旦評估結果顯示目前的 Network 無法再提供網際網路存取權，請切換至任何其他可用的網路 (例如行動數據)，以提供網際網路存取權。
• [C-SR] 強烈建議在 STA 斷線時，於每次掃描開始時隨機產生探測要求影格的來源 MAC 位址和序號。
  • 組成一次掃描的每個探查要求影格群組「應」使用一致的 MAC 位址 (「不應」在掃描中途隨機產生 MAC 位址)。
  • 在掃描期間，探測要求序號在探測要求之間應正常 (循序) 疊代。
  • 探測要求序號應在掃描的最後一個探測要求和下一次掃描的第一個探測要求之間隨機產生。
• [C-SR] 強烈建議在 STA 中斷連線時，僅允許探查要求框架中的下列元素：
  • SSID 參數集 (0)
  • DS 參數集 (3)

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

• [C-3-1] 應用程式透過 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() API 取得 WIFI_MODE_FULL_HIGH_PERF 鎖定或 WIFI_MODE_FULL_LOW_LATENCY 鎖定，且鎖定處於啟用狀態時，必須關閉 Wi-Fi 省電模式。
• [C-3-2] 裝置處於 Wi-Fi 低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 模式時，裝置與存取點之間的平均來回延遲時間，必須小於 Wi-Fi 高效能鎖定 (WIFI_MODE_FULL_HIGH_PERF) 模式下的延遲時間。
• [C-SR] 取得並生效低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 時，強烈建議使用 STRONGLY RECOMMENDED，盡量縮短 Wi-Fi 往返延遲時間。

如果裝置實作項目支援 Wi-Fi，並使用 Wi-Fi 掃描位置資訊，則：

• [C-2-1] 必須提供使用者介面，讓使用者啟用/停用透過 WifiManager.isScanAlwaysAvailable API 方法讀取的值。

7.4.2.1. Wi-Fi Direct

裝置實作方式：

• 應支援 Wi-Fi Direct (Wi-Fi 點對點)。

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

• [C-1-1] 必須按照 SDK 說明文件所述，實作對應的 Android API。
• [C-1-2] MUST report the hardware feature android.hardware.wifi.direct。
• [C-1-3] 必須支援一般 Wi-Fi 作業。
• [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。

7.4.2.2. Wi-Fi 隧道直接連結設定

裝置實作方式：

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

如果裝置實作項目包含 TDLS 支援，且 WiFiManager API 已啟用 TDLS，則：

• [C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。
• 只有在可能且有利時，才應使用 TDLS。
• SHOULD 有一些啟發式方法，且在效能可能比透過 Wi-Fi 存取點更差時，不使用 TDLS。

7.4.2.3. Wi-Fi Aware

裝置實作方式：

• 應支援 Wi-Fi Aware。

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

• [C-1-1] 必須按照 SDK 說明文件所述，實作 WifiAwareManager API。
• [C-1-2] 必須宣告 android.hardware.wifi.aware 功能旗標。
• [C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
• [C-1-4] 必須在不超過 30 分鐘的時間間隔內，以及每次啟用 Wi-Fi Aware 時，隨機產生 Wi-Fi Aware 管理介面位址。

如果裝置實作項目包含對 Wi-Fi Aware 和 Wi-Fi 定位功能的支援 (如第 7.4.2.5 節所述)，並向第三方應用程式公開這些功能，則：

• [C-2-1] 必須實作位置感知探索 API：setRangingEnabled、setMinDistanceMm、setMaxDistanceMm 和 onServiceDiscoveredWithinRange。

7.4.2.4. Wi-Fi Passpoint

裝置實作方式：

• 應支援 Wi-Fi Passpoint。

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

• [C-1-1] 必須按照 SDK 說明文件所述，實作 Passpoint 相關 WifiManager API。
• [C-1-2] 必須支援 IEEE 802.11u 標準，特別是與網路探索和選取相關的標準，例如通用廣告服務 (GAS) 和存取網路查詢通訊協定 (ANQP)。

反之，如果裝置實作項目不支援 Wi-Fi Passpoint：

• [C-2-1] 實作 Passpoint 相關 WifiManager API 時，必須擲回 UnsupportedOperationException。

7.4.2.5. Wi-Fi 定位 (Wi-Fi 封包往返時間 - RTT)

裝置實作方式：

• 應支援 Wi-Fi 定位。

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

• [C-1-1] 必須按照 SDK 說明文件所述，實作 WifiRttManager API。
• [C-1-2] 必須宣告 android.hardware.wifi.rtt 功能旗標。
• [C-1-3] 執行 RTT 時，如果 Wi-Fi 介面未與存取點建立關聯，則必須為執行的每個 RTT 叢發隨機產生來源 MAC 位址。

7.4.2.6. Wi-Fi Keepalive Offload

裝置實作方式：

• SHOULD include support for Wi-Fi keepalive offload.

如果裝置實作項目支援 Wi-Fi 保持連線卸載，並向第三方應用程式公開這項功能，則：

• [C-1-1] MUST support the SocketKeepAlive API.

• [C-1-2] 必須支援至少三個 Wi-Fi 並行連線保持活動狀態的時段，以及至少一個行動網路連線保持活動狀態的時段。

如果裝置實作項目不支援 Wi-Fi 保持連線卸載，則：

• [C-2-1] 必須傳回 ERROR_UNSUPPORTED。

7.4.2.7. Wi-Fi 輕鬆連線 (裝置佈建通訊協定)

裝置實作方式：

• 應支援 Wi-Fi 輕鬆連線 (DPP)。

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

• [C-1-1] 必須按照 SDK 說明文件所述，實作 Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API。
• [C-1-2] WifiManager#isEasyConnectSupported() 方法必須傳回 true。

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 等。

如果裝置實作項目支援藍牙低功耗，則：

• [C-3-1] 必須宣告硬體功能 android.hardware.bluetooth_le。
• [C-3-2] 必須啟用以 GATT (通用屬性設定檔) 為基礎的藍牙 API，如 SDK 說明文件和 android.bluetooth 所述。
• [C-3-3] 必須回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，指出是否已實作 ScanFilter API 類別的篩選邏輯。
• [C-3-4] 必須回報 BluetoothAdapter.isMultipleAdvertisementSupported() 的正確值，指出是否支援低功耗廣告。
• 實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。
• 應支援將批次掃描作業卸載至藍牙晶片組。

• SHOULD support multi advertisement with at least 4 slots.

• [SR] 強烈建議實作可解析的私人位址 (RPA) 逾時，時間不超過 15 分鐘，並在逾時時輪替位址，以保護使用者隱私。

如果裝置實作項目支援藍牙低功耗，並使用藍牙低功耗掃描位置資訊，則：

• [C-4-1] 必須提供使用者介面，讓使用者啟用/停用透過 System API BluetoothAdapter.isBleScanAlwaysAvailable() 讀取的值。

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

• [C-5-1] MUST return true for BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. 近距離無線通訊

裝置實作方式：

• 應包含近距離無線通訊 (NFC) 的收發器和相關硬體。
• [C-0-1] 即使不支援 NFC 或宣告 android.hardware.nfc 功能，也必須實作 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，因為這些類別代表與通訊協定無關的資料表示格式。

如果裝置實作項目包含 NFC 硬體，且計畫向第三方應用程式開放使用，則：

• [C-1-1] 必須透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
• 必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：
• [C-1-2] 必須能夠透過下列 NFC 標準，做為 NFC 論壇讀取器/寫入器 (如 NFC 論壇技術規格 NFCForum-TS-DigitalProtocol-1.0 所定義)：
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NFC-F (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC 論壇標記類型 1、2、3、4、5 (由 NFC 論壇定義)

• [SR] 強烈建議能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息和原始資料。請注意，雖然 NFC 標準目前是「強烈建議」，但日後版本的相容性定義預計會將這些標準改為「必須」。這個版本可選擇是否採用這些標準，但日後推出的版本將強制採用。強烈建議現有和新裝置立即滿足這些需求，以便升級至未來的平台版本。

• [C-1-13] 處於 NFC 探索模式時，必須輪詢所有支援的技術。

• 裝置處於喚醒狀態、螢幕開啟且螢幕鎖定解除時，應處於 NFC 探索模式。
• 應能讀取 Thinfilm NFC 條碼產品的條碼和網址 (如已編碼)。

請注意，上述 JIS、ISO 和 NFC 論壇規格不提供公開連結。

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

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

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

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

• [C-3-1] MUST report the android.hardware.nfc.hcef feature constant.
• [C-3-2] 必須實作 Android SDK 中定義的 NfcF 卡片模擬 API。

如果裝置實作項目包含本節所述的一般 NFC 支援，且支援讀取器/寫入器角色的 MIFARE 技術 (MIFARE Classic、MIFARE Ultralight、MIFARE Classic 上的 NDEF)，則：

• [C-4-1] 必須實作 Android SDK 記載的對應 Android API。
• [C-4-2] MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. 請注意，這不是標準 Android 功能，因此不會以常數形式出現在 android.content.pm.PackageManager 類別中。

7.4.5. 最低網路功能

裝置實作方式：

• [C-0-1] 必須支援一或多種形式的資料網路。具體來說，裝置實作內容「必須」支援至少一個資料標準，且資料傳輸速率至少為 200 Kbit/sec。符合這項規定的技術包括 EDGE、HSPA、EV-DO、802.11g、乙太網路和藍牙 PAN。
• 如果實體網路標準 (例如乙太網路) 是主要的資料連線，也「應」支援至少一個常見的無線資料標準，例如 802.11 (Wi-Fi)。
• MAY 實作多種形式的資料連線。
• [C-0-2] 必須包含 IPv6 網路堆疊，並支援使用受管理 API (例如 java.net.Socket 和 java.net.URLConnection) 以及原生 API (例如 AF_INET6 插座) 的 IPv6 通訊。
• [C-0-3] MUST enable IPv6 by default.
• 必須確保 IPv6 通訊的可靠性與 IPv4 相同，例如：
  • [C-0-4] MUST maintain IPv6 connectivity in doze mode.
  • [C-0-5] 在任何使用 RA 生命週期至少 180 秒的 IPv6 相容網路中，速率限制不得導致裝置失去 IPv6 連線。
• [C-0-6] 連線至 IPv6 網路時，必須為第三方應用程式提供直接 IPv6 網路連線，裝置上不得進行任何形式的位址或連接埠轉譯。無論是受管理 API (例如 Socket#getLocalAddress 或 Socket#getLocalPort)，還是 NDK API (例如 getsockname() 或 IPV6_PKTINFO)，都「必須」傳回實際用於在網路上傳送及接收封包的 IP 位址和連接埠。

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

如果裝置實作支援 Wi-Fi，則：

• [C-1-1] 必須支援 Wi-Fi 上的雙重堆疊和僅限 IPv6 作業。

如果裝置實作支援乙太網路，則：

• [C-2-1] 必須支援乙太網路上的雙堆疊作業。

如果裝置實作支援行動數據，則：

• 應支援行動網路上的 IPv6 作業 (僅限 IPv6，可能也支援雙重堆疊)。

如果裝置實作支援多種網路類型 (例如 Wi-Fi 和行動數據)，則：

• [C-3-1] 裝置同時連線至多個網路類型時，必須同時滿足每個網路的上述要求。

7.4.6. 同步設定

裝置實作方式：

• [C-0-1] 預設必須開啟主要自動同步設定，方法 getMasterSyncAutomatically() 才會傳回「true」。

7.4.7. 數據節省模式

如果裝置實作項目包含付費連線，則為：

• [SR] STRONGLY RECOMMENDED to provide the data saver mode.

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

• [C-1-1] 必須支援 ConnectivityManager 類別中的所有 API，如 SDK 說明文件所述
• [C-1-2] MUST provide a user interface in the settings, that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent, allowing users to add applications to or remove applications from the allowlist.

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

• [C-2-1] 必須針對 ConnectivityManager.getRestrictBackgroundStatus() 傳回 RESTRICT_BACKGROUND_STATUS_DISABLED 值。
• [C-2-2] MUST NOT broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED。
• [C-2-3] 必須有處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖的活動，但可將其實作為無運算。

7.4.8. 安全元件

如果裝置實作項目支援 Open Mobile API 可用的安全元件，並提供給第三方應用程式，則：

• [C-1-1] 呼叫 android.se.omapi.SEService.getReaders() 方法時，必須列舉可用的安全元件讀取器。

7.5. 攝影機

如果裝置實作項目包含至少一部相機，則：

• [C-1-1] 必須宣告 android.hardware.camera.any 功能旗標。
• [C-1-2] 應用程式必須能夠同時配置 3 個 RGBA_8888 點陣圖，大小等同於裝置上最大解析度相機感應器產生的圖片，同時開啟相機以進行基本預覽和靜態拍攝。
• [C-1-3] 預先安裝的預設相機應用程式處理意圖 MediaStore.ACTION_IMAGE_CAPTURE、MediaStore.ACTION_IMAGE_CAPTURE_SECURE 或 MediaStore.ACTION_VIDEO_CAPTURE 時，必須負責在將圖片中繼資料傳送至接收應用程式前，移除使用者位置資訊 (如果接收應用程式沒有 ACCESS_FINE_LOCATION)。

7.5.1. 後置鏡頭

後置鏡頭位於裝置螢幕的背面，可拍攝裝置遠端的場景，就像傳統相機一樣。

裝置實作方式：

• 應包含後置鏡頭。

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

• [C-1-1] 必須回報功能旗標 android.hardware.camera 和 android.hardware.camera.any。
• [C-1-2] 解析度必須至少為 200 萬像素。
• 相機驅動程式「應」實作硬體自動對焦或軟體自動對焦 (對應用程式軟體而言是透明的)。
• 可能配備定焦或 EDOF (擴展景深) 硬體。
• 可能包含閃光燈。

如果攝影機有閃光燈：

• [C-2-1] 在 Camera 預覽畫面上註冊 android.hardware.Camera.PreviewCallback 例項時，閃光燈不得亮起，除非應用程式已透過啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，明確啟用閃光燈。請注意，這項限制不適用於裝置內建的系統相機應用程式，只適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2. 前置鏡頭

前置鏡頭位於裝置螢幕的同一側，通常用於拍攝使用者，例如視訊會議和類似應用程式。

裝置實作方式：

• 可包含前置鏡頭。

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

• [C-1-1] 必須回報功能旗標 android.hardware.camera.any 和 android.hardware.camera.front。
• [C-1-2] 必須至少為 VGA 解析度 (640x480 像素)。
• [C-1-3] 不得將前置鏡頭設為 Camera API 的預設鏡頭，也不得將 API 設為將前置鏡頭視為預設後置鏡頭，即使裝置上只有一個鏡頭也一樣。
• [C-1-4] 如果目前應用程式已明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法旋轉相機畫面，相機預覽畫面必須相對於應用程式指定方向水平鏡像。反之，如果目前的應用程式未透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法明確要求旋轉相機畫面，預覽畫面就「必須」沿著裝置的預設水平軸鏡像翻轉。
• [C-1-5] 不得將傳回應用程式回呼或提交至媒體儲存空間的最終擷取靜態影像或影片串流鏡像化。
• [C-1-6] 必須以與攝影機預覽影像串流相同的方式，鏡像顯示後視畫面顯示的影像。
• 可包含後置鏡頭適用的功能 (例如自動對焦、閃光燈等)，詳情請參閱第 7.5.1 節。

如果裝置實作項目可由使用者旋轉 (例如透過加速計自動旋轉，或透過使用者輸入內容手動旋轉)：

• [C-2-1] 相機預覽畫面必須根據裝置目前的方向水平鏡像。

7.5.3. 外接攝影機

裝置實作方式：

• 可能包括支援不一定總是連線的外接攝影機。

如果裝置實作項目包含外接攝影機的支援，則：

• [C-1-1] 必須宣告平台功能旗標 android.hardware.camera.external 和 android.hardware camera.any。
• [C-1-2] 如果外接攝影機透過 USB 主機連接埠連線，則必須支援 USB 視訊類別 (UVC 1.0 以上版本)。
• [C-1-3] 必須通過攝影機 CTS 測試，且已連線實體外接攝影機裝置。如要瞭解相機 CTS 測試的詳細資料，請前往 source.android.com。
• 應支援 MJPEG 等影片壓縮格式，以便傳輸未編碼的高畫質串流 (即原始或獨立壓縮的圖片串流)。
• 可能支援多部攝影機。
• 可能支援以攝影機為基礎的影片編碼。

如果支援攝影機影片編碼：

• [C-2-1] 裝置實作必須能存取未編碼 / MJPEG 同步串流 (QVGA 以上解析度)。

7.5.4. Camera API 行為

Android 包含兩個 API 套件，可存取相機。較新的 android.hardware.camera2 API 會向應用程式公開較低層級的相機控制項，包括有效率的零複製連拍/串流流程，以及曝光、增益、白平衡增益、色彩轉換、去噪、銳利化等每格畫面控制項。

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

在舊版 android.hardware.Camera 類別和新版 android.hardware.camera2 套件中，所有常見功能都必須具備同等效能和品質。舉例來說，在設定相同的情況下，自動對焦速度和準確度必須相同，且拍攝的影像品質也必須相同。如果功能取決於兩個 API 的不同語意，則不一定要有相符的速度或品質，但應盡可能相符。

裝置實作項目「必須」為所有可用攝影機的攝影機相關 API 實作下列行為。裝置實作方式：

• [C-0-1] 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則必須使用 android.hardware.PixelFormat.YCbCr_420_SP，為應用程式回呼提供預覽資料。
• [C-0-2] 如果應用程式註冊 android.hardware.Camera.PreviewCallback 例項，且系統呼叫 onPreviewFrame() 方法，而預覽格式為 YCbCr_420_SP，則傳遞至 onPreviewFrame() 的 byte[] 中的資料必須採用 NV21 編碼格式。也就是說，NV21 必須是預設值。
• [C-0-3] 必須支援前置和後置鏡頭的相機預覽畫面 (如 android.graphics.ImageFormat.YV12 常數所示) 的 YV12 格式 (android.hardware.Camera)。(硬體視訊編碼器和攝影機可使用任何原生像素格式，但裝置實作內容「必須」支援轉換為 YV12)。
• [C-0-4] 針對在 android.request.availableCapabilities 中宣傳 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能的 android.hardware.camera2 裝置，透過 android.media.ImageReader API 輸出時，必須支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式。
• [C-0-5] 無論裝置是否包含硬體自動對焦或其他功能，都「必須」實作 Android SDK 說明文件中包含的完整 Camera API。舉例來說，即使沒有自動對焦功能，相機仍須呼叫所有已註冊的 android.hardware.Camera.AutoFocusCallback 執行個體 (即使這與非自動對焦相機無關)。請注意，這適用於前置鏡頭；舉例來說，即使大多數前置鏡頭不支援自動對焦，API 回呼仍「必須」如說明所述「偽造」。
• [C-0-6] MUST recognize and honor each parameter name defined as a constant in the android.hardware.Camera.Parameters class and the android.hardware.camera2.CaptureRequest class. 反之，裝置實作項目「不得」接受或辨識傳遞至 android.hardware.Camera.setParameters() 方法的字串常數，除非這些常數已記錄在 android.hardware.Camera.Parameters 中。也就是說，如果硬體允許，裝置實作項目「必須」支援所有標準攝影機參數，且「不得」支援自訂攝影機參數類型。舉例來說，支援使用高動態範圍 (HDR) 成像技術拍攝圖片的裝置實作項目，必須支援相機參數 Camera.SCENE_MODE_HDR。
• [C-0-7] 必須使用 Android SDK 中說明的 android.info.supportedHardwareLevel 屬性回報適當的支援層級，並回報適當的架構功能旗標。
• [C-0-8] 透過 android.request.availableCapabilities 屬性聲明 android.hardware.camera2 的個別攝影機功能，並聲明適當的功能標記；如果任何附加的攝影機裝置支援該功能，則必須定義功能標記。
• [C-0-9] 只要相機拍下新相片，且相片項目已新增至媒體商店，就必須廣播 Camera.ACTION_NEW_PICTURE 意圖。
• [C-0-10] 只要攝影機錄製新影片，且相片項目已新增至媒體商店，就必須廣播 Camera.ACTION_NEW_VIDEO 意圖。
• [C-0-11] 必須透過已淘汰的 android.hardware.Camera API 存取所有攝影機，且也能透過 android.hardware.camera2 API 存取。
• [C-SR] 對於朝向相同方向的多部 RGB 攝影機，強烈建議裝置支援列出 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 功能的邏輯攝影機裝置，其中包含朝向該方向的所有 RGB 攝影機，做為實體子裝置。

如果裝置實作項目向第三方應用程式提供專屬的 Camera API，則：

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

7.5.5. 攝影機方向

如果裝置實作項目有前置或後置鏡頭，這類鏡頭：

• [C-1-1] 必須經過調整，確保相機的長邊與螢幕的長邊對齊。也就是說，當裝置處於橫向時，相機必須以橫向拍攝圖片。無論裝置的自然方向為何，這項規則都適用，也就是說，橫向和直向裝置都適用。

7.6. 記憶體與儲存空間

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

裝置實作方式：

• [C-0-1] 必須包含下載管理員，應用程式可使用該管理員下載資料檔案，且必須能夠將至少 100 MB 的個別檔案下載至預設「快取」位置。

7.6.2. 應用程式共用儲存空間

裝置實作方式：

• [C-0-1] MUST offer storage to be shared by applications, also often referred as “shared external storage”, "application shared storage" or by the Linux path "/sdcard" it is mounted on.
• [C-0-2] 必須預設設定共用儲存空間，也就是「開箱即用」，無論儲存空間是實作在內部儲存空間元件或可移除式儲存媒體 (例如 Secure Digital 卡插槽) 上。
• [C-0-3] 必須直接在 Linux 路徑 sdcard 上掛接應用程式共用儲存空間，或在 sdcard 中加入 Linux 符號連結，指向實際掛接點。
• [C-0-4] 必須在共用儲存空間中強制執行 android.permission.WRITE_EXTERNAL_STORAGE 權限，如 SDK 文件所述。
• [C-0-5] 對於指定 API 級別 29 以上的所有應用程式，預設必須啟用限定範圍儲存空間，但下列情況除外：
  • 如果應用程式是在裝置升級至 API 級別 29 之前安裝，無論應用程式的目標 API 為何，都會受到影響。
  • 應用程式已在資訊清單中要求 android:requestLegacyExternalStorage="true"。
  • 應用程式獲得 android.permission.WRITE_MEDIA_STORAGE 權限時。
• [C-0-6] 必須強制執行：啟用限定範圍儲存空間的應用程式不得直接存取應用程式專屬目錄以外的檔案系統，這些目錄是由 Context API 方法 (例如 Context.getExternalFilesDirs()、Context.getExternalCacheDirs()、Context.getExternalMediaDirs() 和 Context.getObbDirs() 方法) 傳回。
• [C-0-7] 透過 MediaStore 存取媒體檔案時，必須遮蓋儲存在這些檔案中的位置中繼資料 (例如 GPS Exif 標記)，但呼叫應用程式持有 ACCESS_MEDIA_LOCATION 權限時除外。

裝置實作「可能」會使用下列任一方式，滿足上述需求：

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

如果裝置實作項目使用可移除式儲存空間來滿足上述需求，則：

• [C-1-1] 如果插槽中未插入儲存媒體，必須實作快顯或彈出式使用者介面，向使用者發出警告。
• [C-1-2] 必須隨附 FAT 格式的儲存媒體 (例如 SD 卡)，或在包裝盒和購買時提供的其他材料上註明儲存媒體須另行購買。

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

• 應使用內部應用程式共用儲存空間的 AOSP 實作項目。
• 可能與應用程式私人資料共用儲存空間。

如果裝置實作項目包含多個共用儲存空間路徑 (例如 SD 卡插槽和共用內部儲存空間)，則：

• [C-2-1] 僅允許預先安裝的 Android 應用程式和具備 WRITE_MEDIA_STORAGE 權限的應用程式寫入次要外部儲存空間，但寫入套件專屬目錄或在啟動 ACTION_OPEN_DOCUMENT_TREE 意圖後傳回的 URI 內時除外。
• [C-2-2] 必須要求只有在授予 android.permission.WRITE_EXTERNAL_STORAGE 權限時，才將與 android.permission.WRITE_MEDIA_STORAGE 權限相關聯的直接存取權授予使用者可見的應用程式。
• [SR] 強烈建議預先安裝的 Android 應用程式和具備特殊權限的應用程式使用 MediaStore 等公開 API 與儲存裝置互動，而不是依賴 android.permission.WRITE_MEDIA_STORAGE 授予的直接存取權。

如果裝置實作項目具有支援 USB 周邊裝置模式的 USB 連接埠，則：

• [C-3-1] MUST provide a mechanism to access the data on the application shared storage from a host computer.
• 應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，公開這兩個儲存路徑的內容。
• 可使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定來滿足這項需求。

如果裝置實作項目具有 USB 連接埠 (採用 USB 周邊模式) 並支援媒體傳輸通訊協定，則：

• 應與參考 Android MTP 主機「Android 檔案傳輸應用程式」相容。
• SHOULD report a USB device class of 0x00.
• 應回報「MTP」的 USB 介面名稱。

7.6.3. 合併儲存空間

如果裝置預期會是行動裝置 (與電視不同)，則裝置實作方式如下：

• [SR] 強烈建議在長期穩定的位置實作可攜式儲存空間，因為意外中斷連線可能會導致資料遺失/毀損。

如果可移除式儲存裝置連接埠位於長期穩定的位置，例如電池盒或其他保護蓋內，裝置實作方式如下：

• [SR] STRONGLY RECOMMENDED to implement adoptable storage.

7.7. USB

如果裝置實作項目有 USB 連接埠，則：

• 應支援 USB 周邊裝置模式，且應支援 USB 主機模式。

7.7.1. USB 周邊裝置模式

如果裝置實作項目包含支援周邊模式的 USB 連接埠：

• [C-1-1] 連接埠必須可連接至具有標準 Type-A 或 Type-C USB 連接埠的 USB 主機。
• [C-1-2] 必須透過 android.os.Build.SERIAL 回報 USB 標準裝置描述元中 iSerialNumber 的正確值。
• [C-1-3] 必須根據 Type-C 電阻標準偵測 1.5A 和 3.0A 充電器，且如果支援 Type-C USB，必須偵測廣告中的變更。
• [SR] 連接埠應使用 micro-B、micro-AB 或 Type-C USB 板型規格。強烈建議現有和新的 Android 裝置符合這些需求，以便升級至未來的平台版本。
• [SR] 連接埠「應」位於裝置底部 (依自然方向)，或為所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，以便在裝置連接埠位於底部時，正確繪製顯示畫面。強烈建議現有和新的 Android 裝置符合這些需求，以便升級至日後的平台版本。
• [SR] SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging specification, revision 1.2. 強烈建議現有和新的 Android 裝置符合這些需求，以便升級至未來的平台版本。
• [SR] 強烈建議不要支援專有充電方法，因為這類方法會將 Vbus 電壓修改為超出預設值，或變更接收器/來源角色，可能導致與支援標準 USB Power Delivery 方法的充電器或裝置發生互通性問題。雖然這項規定標示為「強烈建議」，但日後的 Android 版本可能會要求所有 Type-C 裝置完全支援標準 Type-C 充電器。
• [SR] 強烈建議支援 Power Delivery，以便在支援 Type-C USB 和 USB 主機模式時，交換資料和電源角色。
• 應支援高電壓充電的 Power Delivery，以及顯示器輸出等替代模式。
• 應實作 Android Open Accessory (AOA) API 和規格，如 Android SDK 說明文件所述。

如果裝置實作包含 USB 連接埠並實作 AOA 規格，則：

• [C-2-1] MUST declare support for the hardware feature android.hardware.usb.accessory.
• [C-2-2] USB 大量儲存類別的介面說明 iInterface 字串結尾必須包含「android」字串。

7.7.2. USB 主機模式

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

• [C-1-1] 必須實作 Android USB 主機 API，如 Android SDK 所述，且必須宣告支援硬體功能 android.hardware.usb.host。
• [C-1-2] 必須實作支援，以連線至標準 USB 周邊裝置，換句話說，必須符合下列任一條件：
  • 具備裝置上的 C 型連接埠，或隨附可將裝置上的專屬連接埠轉換為標準 USB C 型連接埠的傳輸線 (USB C 型裝置)。
  • 具備 A 型連接埠，或隨附可將裝置專屬連接埠轉換為標準 USB A 型連接埠的傳輸線。
  • 具備裝置端 micro-AB 連接埠，且應隨附可轉接至標準 A 型連接埠的傳輸線。
• [C-1-3] 不得隨附將 USB Type-A 或 Micro-AB 連接埠轉換為 Type-C 連接埠 (插座) 的轉接器。
• [C-SR] 強烈建議實作 Android SDK 文件中記載的 USB 音訊類別。
• 應支援在主機模式下為連線的 USB 周邊裝置充電；根據 USB Type-C Cable and Connector Specification Revision 1.2 的 Termination Parameters 區段，為 USB Type-C 連接器宣傳至少 1.5A 的來源電流，或根據 USB Battery Charging specifications, revision 1.2，為 Micro-AB 連接器使用 Charging Downstream Port(CDP) 輸出電流範圍。
• 應實作並支援 USB Type-C 標準。

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

• [C-2-1] 必須支援 USB HID 類別。
• [C-2-2] 必須支援偵測和對應 USB HID 用途表和語音指令用途要求中指定的下列 HID 資料欄位，並對應至 KeyEvent 常數，如下所示：
  • 使用頁面 (0xC) 使用 ID (0x0CD)：KEYCODE_MEDIA_PLAY_PAUSE
  • 使用頁面 (0xC) 使用 ID (0x0E9)：KEYCODE_VOLUME_UP
  • 使用頁面 (0xC) 使用 ID (0x0EA)：KEYCODE_VOLUME_DOWN
  • 使用頁面 (0xC) 使用 ID (0x0CF)：KEYCODE_VOICE_ASSIST

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

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

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

• [C-4-1] 必須實作 USB Type-C 規格 (第 4.5.1.3.3 節) 定義的雙重角色連接埠功能。
• [SR] 強烈建議支援 DisplayPort，應支援 USB SuperSpeed 資料速率，並強烈建議支援電力傳輸，以進行資料和電源角色交換。
• [SR] 強烈建議不要支援「USB Type-C Cable and Connector Specification Revision 1.2」附錄 A 所述的音訊轉接頭配件模式。
• 應實作最適合裝置板型規格的 Try.* 模型。舉例來說，手持裝置「應」實作 Try.SNK 模型。

7.8. 音訊

7.8.1. 麥克風

如果裝置實作項目包含麥克風，則：

• [C-1-1] MUST report the android.hardware.microphone feature constant.
• [C-1-2] 必須符合第 5.4 節的音訊錄音規定。
• [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
• [SR] 強烈建議支援近超音波錄音功能，詳情請參閱第 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] MUST report the android.hardware.audio.output feature constant.
• [C-1-2] 必須符合第 5.5 節的音訊播放規定。
• [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
• [SR] 強烈建議支援近超音波播放，詳情請參閱第 7.8.3 節。

如果裝置實作項目未包含喇叭或音訊輸出埠，則：

• [C-2-1] 不得回報 android.hardware.audio.output 功能。
• [C-2-2] 至少必須將音訊輸出相關 API 實作為無運算。

就本節而言，「輸出埠」是指實體介面，例如 3.5 公釐音訊插孔、HDMI 或 USB 主機模式埠 (具備 USB 音訊類別)。透過藍牙、Wi-Fi 或行動網路等無線通訊協定輸出音訊，不符合「輸出埠」的定義。

7.8.2.1. 類比音訊埠

如要與 Android 生態系統中採用 3.5 公釐音訊插頭的耳機和其他音訊配件相容，如果裝置實作項目包含一或多個類比音訊連接埠，則：

• [C-SR] 強烈建議至少包含一個音訊連接埠，且為 4 導體 3.5 公釐耳機插孔。

如果裝置實作項目有 4 導體 3.5 公釐音訊插孔，則：

• [C-1-1] 必須支援透過立體聲耳機和立體聲耳機麥克風播放音訊。
• [C-1-2] 必須支援 CTIA 針腳順序的 TRRS 音訊插頭。
• [C-1-3] MUST support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 70 歐姆以下：KEYCODE_HEADSETHOOK
  • 210 至 290 歐姆：KEYCODE_VOLUME_UP
  • 360 至 680 歐姆：KEYCODE_VOLUME_DOWN
• [C-1-4] MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack.
• [C-1-5] MUST be capable of driving at least 150mV ± 10% of output voltage on a 32 ohm speaker impedance.
• [C-1-6] 麥克風偏壓必須介於 1.8V 至 2.9V。
• [C-1-7] 必須偵測音訊插頭上麥克風和接地導體之間等效阻抗的下列範圍，並對應至按鍵碼：
  • 110 到 180 歐姆： KEYCODE_VOICE_ASSIST
• [C-SR] Are STRONGLY RECOMMENDED to support audio plugs with the OMTP pin-out order.
• [C-SR] 強烈建議支援透過附麥克風的立體聲耳機錄製音訊。

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

• [C-2-1] MUST support the detection of microphone on the plugged in audio accessory.

7.8.2.2. 數位音訊埠

為與使用 USB-C 接頭並在 Android 生態系統中實作 (USB 音訊類別) 的耳機和其他音訊配件相容，如 Android USB 耳機規格中所定義。

如需裝置專屬需求，請參閱第 2.2.1 節。

7.8.3. 近超音波

近超音波音訊的頻帶為 18.5 kHz 至 20 kHz。

裝置實作方式：

• 必須透過 AudioManager.getProperty API 正確回報近超音波音訊功能支援情形，如下所示：

如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 為「true」，VOICE_RECOGNITION 和 UNPROCESSED 音訊來源必須符合下列規定：

• [C-1-1] 麥克風在 18.5 kHz 至 20 kHz 頻帶的平均功率回應，必須比 2 kHz 的回應低 15 dB 以下。
• [C-1-2] 在 18.5 kHz 至 20 kHz 的頻率範圍內，麥克風的未加權訊號雜訊比 (19 kHz 音調，-26 dBFS) 必須不低於 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

• [C-2-1] 音箱在 18.5 kHz 至 20 kHz 的平均回應值，必須比 2 kHz 的回應值低 40 dB 以上。

7.8.4. 信號完整性

裝置實作方式：

• 手持裝置的輸入和輸出串流都應提供無故障的音訊訊號路徑，也就是在每條路徑的一分鐘測試期間，測得的故障次數為零。使用 [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) 進行「Automated Glitch Test」。

測試時需要音訊回送 Dongle，可直接插入 3.5 公釐耳機插孔，或搭配 USB-C 對 3.5 公釐轉接器使用。應測試所有音訊輸出埠。

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

可靠的串流「應」符合下列 2000 Hz 正弦訊號的訊號雜訊比 (SNR) 和總諧波失真 (THD) 標準。

7.9. 虛擬實境

Android 包含各種 API 和設施，可建構「虛擬實境」(VR) 應用程式，包括優質的行動 VR 體驗。裝置實作項目「必須」正確實作這些 API 和行為，詳情請參閱本節。

7.9.1. 虛擬實境模式

Android 支援虛擬實境模式，這項功能可處理通知的立體算繪作業，並在虛擬實境應用程式取得使用者焦點時，停用單眼系統 UI 元件。

7.9.2. 虛擬實境模式 - 高效能

如果裝置實作項目支援 VR 模式，則：

• [C-1-1] 至少須有 2 個實體核心。
• [C-1-2] 必須宣告 android.hardware.vr.high_performance 功能。
• [C-1-3] 必須支援持續效能模式。
• [C-1-4] 必須支援 OpenGL ES 3.2。
• [C-1-5] MUST support android.hardware.vulkan.level 0。
• 應支援 android.hardware.vulkan.level 1 以上版本。
• [C-1-6] 必須實作 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content、EGL_EXT_image_gl_colorspace，並在可用 EGL 擴充功能清單中公開擴充功能。
• [C-1-8] 必須實作 GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2、GL_OVR_multiview_multisampled_render_to_texture、GL_EXT_protected_textures，並在可用的 GL 擴充功能清單中公開擴充功能。
• [C-SR] 強烈建議導入 GL_EXT_external_buffer 和 GL_EXT_EGL_image_array，並在可用的 Google 連結擴充功能清單中顯示擴充功能。
• [C-SR] 強烈建議支援 Vulkan 1.1。
• [C-SR] 強烈建議實作 VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing、VK_KHR_shared_presentable_image，並在可用的 Vulkan 擴充功能清單中公開。
• [C-SR] 強烈建議公開至少一個 Vulkan 佇列系列，其中 flags 包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT，且 queueCount 至少為 2。
• [C-1-7] GPU 和螢幕「必須」能夠同步存取共用的前端緩衝區，以便以兩個算繪環境，以 60 FPS 的速度算繪 VR 內容，並交替顯示左右眼畫面，且不會出現明顯的畫面撕裂問題。
• [C-1-9] 必須實作對 AHardwareBuffer 標記 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 的支援，如 NDK 所述。
• [C-1-10] 必須支援 AHardwareBuffer，並搭配使用任何組合的用法旗標 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT，至少支援下列格式：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
• [C-SR] 強烈建議支援分配具有多個圖層的 AHardwareBuffer，以及 C-1-10 中指定的標記和格式。
• [C-1-11] 必須支援 H.264 解碼，至少 3840 x 2160，30 fps，壓縮至平均 40 Mbps (相當於 4 個 1920 x 1080 30 fps 10 Mbps 的例項，或 2 個 1920 x 1080 60 fps 20 Mbps 的例項)。
• [C-1-12] 必須支援 HEVC 和 VP9，必須能夠以 30 FPS 解碼至少 1920 x 1080 的影片，壓縮後平均為 10 Mbps，且應能夠以 30 FPS 解碼 3840 x 2160 的影片 (20 Mbps，相當於以 30 FPS 解碼 4 個 1920 x 1080 的影片，每個 5 Mbps)。
• [C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回準確的皮膚溫度值。
• [C-1-14] 必須內嵌螢幕，且解析度必須至少為 1920 x 1080。
• [C-SR] 建議顯示解析度至少為 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] 強烈建議支援上述所有直接管道類型TYPE_HARDWARE_BUFFER的直接管道類型。
• [C-1-21] 必須符合android.hardware.hifi_sensors的陀螺儀、加速計和磁力計相關規定，詳情請參閱第 7.3.9 節。
• [C-SR] 強烈建議支援 android.hardware.sensor.hifi_sensors 功能。
• [C-1-22] 端對端動作到光子延遲時間不得超過 28 毫秒。
• [C-SR] 強烈建議端對端動作到光子延遲時間不超過 20 毫秒。
• [C-1-23] 必須具備至少 85% 的首格畫面比率，也就是從黑到白轉換後首格畫面的像素亮度，與穩定狀態下白色像素亮度的比率。
• [C-SR] 強烈建議第一格畫面比例至少為 90%。
• 可為前景應用程式提供專屬核心，並支援 Process.getExclusiveCores API，傳回頂層前景應用程式專屬的 CPU 核心數。

如果支援專屬核心，則核心：

• [C-2-1] 不得允許任何其他使用者空間程序在其上執行 (應用程式使用的裝置驅動程式除外)，但可視需要允許部分核心程序執行。

8. 效能和電力

部分最低效能和電力標準對使用者體驗至關重要，且會影響開發人員開發應用程式時的基準假設。

8.1. 使用者體驗一致性

如果應用程式和遊戲符合特定最低需求，確保影格率和回應時間一致，就能為使用者提供流暢的使用者介面。視裝置類型而定，裝置實作項目「可能」會對使用者介面延遲和工作切換設下可測量的要求，詳情請參閱第 2 節。

8.2. 檔案 I/O 存取效能

為應用程式私有資料儲存空間 (/data 分割區) 提供一致的檔案存取效能，可做為一般基準，讓應用程式開發人員設定適當的期望，有助於軟體設計。視裝置類型而定，裝置實作方式「可能」須符合第 2 節所述的特定需求，才能執行下列讀取和寫入作業：

• 循序寫入效能。使用 10 MB 的寫入緩衝區寫入 256 MB 的檔案時測得。
• 隨機寫入效能。測量方式為使用 4KB 寫入緩衝區寫入 256MB 檔案。
• 循序讀取效能：測量方式為使用 10 MB 的寫入緩衝區讀取 256 MB 的檔案。
• 隨機讀取效能。使用 4KB 寫入緩衝區讀取 256MB 檔案時測得。

8.3.省電模式

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

• [C-1-1] 觸發、維護、喚醒演算法，以及應用程式待機和微光省電模式的全域系統設定，不得與 AOSP 實作方式有所差異。
• [C-1-2] MUST NOT deviate from the AOSP implementation for the use of global settings to manage the throttling of jobs, alarm and network for apps in each bucket for App standby.
• [C-1-3] 用於應用程式待命的應用程式待命值區數量，不得與 AOSP 實作方式有所差異。
• [C-1-4] 必須按照「電源管理」一節所述，實作應用程式待命儲存區和打盹模式。
• [C-1-5] 裝置處於省電模式時，必須傳回 PowerManager.isPowerSaveMode() 的 true。
• [C-SR] 強烈建議提供使用者介面，讓使用者啟用及停用省電模式。
• [C-SR] 強烈建議提供使用者可顯示所有應用程式的功能提示，這些應用程式可免除應用程式待命和打盹省電模式。

除了省電模式，Android 裝置實作「可能」會實作進階設定和電源介面 (ACPI) 定義的 4 種休眠電源狀態。

如果裝置實作項目實作 ACPI 定義的 S4 電源狀態，則：

• [C-1-1] 只有在使用者採取明確動作將裝置設為非使用中狀態 (例如關上裝置實體蓋子，或關閉車輛或電視)，且使用者重新啟動裝置前 (例如打開蓋子，或重新啟動車輛或電視) 時，才必須進入這個狀態。

如果裝置實作項目實作 ACPI 定義的 S3 電源狀態，則：

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

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

  舉例來說，雖然第三方應用程式會透過 FLAG_KEEP_SCREEN_ON 要求保持螢幕開啟，或透過 PARTIAL_WAKE_LOCK 要求 CPU 保持運作，但除非使用者已明確採取動作，將裝置設為閒置狀態 (如 C-1-1 所述)，否則裝置「不得」進入 S3 狀態。反之，當第三方應用程式透過 JobScheduler 執行的工作觸發，或 Firebase 雲端通訊傳送至第三方應用程式時，裝置「必須」退出 S3 狀態，除非使用者已將裝置設為閒置狀態。這些並非完整範例，AOSP 會實作大量喚醒訊號，從這個狀態觸發喚醒。

8.4. 耗電量會計

更準確地計算和回報耗電量，可為應用程式開發人員提供誘因和工具，進一步最佳化應用程式的耗電模式。

裝置實作方式：

• [SR] 強烈建議提供每個元件的電源設定檔，定義每個硬體元件的耗電量值，以及元件隨時間造成的電池耗電量 (如 Android 開放原始碼計畫網站所述)。
• [SR] STRONGLY RECOMMENDED to report all power consumption values in milliampere hours (mAh).
• [SR] STRONGLY RECOMMENDED to report CPU power consumption per each process's UID. Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目，滿足這項需求。
• [SR] STRONGLY RECOMMENDED to make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.
• 如果無法將硬體元件耗電量歸因於應用程式，則應歸因於硬體元件本身。

8.5. 一致的效能

對於長時間執行的效能密集型應用程式，效能可能會大幅波動，原因可能是背景執行的其他應用程式，或是因溫度限制而導致 CPU 節流。Android 包含程式化介面，因此當裝置有能力時，最上層的前景應用程式可以要求系統最佳化資源分配，以解決這類波動問題。

裝置實作方式：

• [C-0-1] 必須透過 PowerManager.isSustainedPerformanceModeSupported() API 方法，準確回報持續效能模式的支援情形。

• SHOULD support Sustained Performance Mode.

如果裝置實作項目回報支援持續效能模式，則：

• [C-1-1] 應用程式要求時，必須為最上層的前景應用程式提供至少 30 分鐘的穩定效能。
• [C-1-2] MUST honor the Window.setSustainedPerformanceMode() API and other related APIs.

如果裝置實作項目包含兩個以上的 CPU 核心，則：

• SHOULD 提供至少一個專屬核心，供頂層前景應用程式預留。

如果裝置實作項目支援為頂層前景應用程式保留一個專屬核心，則：

• [C-2-1] 必須透過 Process.getExclusiveCores() API 方法回報可由頂層前景應用程式預留的專屬核心 ID 編號。
• [C-2-2] 除了應用程式使用的裝置驅動程式外，不得允許任何使用者空間程序在專屬核心上執行，但可視需要允許部分核心程序執行。

如果裝置實作項目不支援專屬核心，則：

• [C-3-1] 必須透過 Process.getExclusiveCores() API 方法傳回空白清單。

9. 安全性模型相容性

裝置實作方式：

• [C-0-1] MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs in the Android developer documentation.

• [C-0-2] 必須支援安裝自行簽署的應用程式，不必取得任何第三方/授權單位的額外權限/憑證。具體來說，相容裝置「必須」支援下列小節所述的安全機制。

9.1. 權限

裝置實作方式：

• [C-0-1] 必須支援 Android 開發人員說明文件中定義的 Android 權限模型。具體來說，他們「必須」按照 SDK 文件中的說明，強制執行每項權限；不得省略、變更或忽略任何權限。

• 可新增其他權限，但前提是新的權限 ID 字串不得位於 android.\* 命名空間中。

• [C-0-2] PROTECTION_FLAG_PRIVILEGED protectionLevel 權限只能授予系統映像檔特殊權限路徑中預先安裝的應用程式，且必須在每個應用程式明確允許的權限子集中。AOSP 實作會讀取並遵守 etc/permissions/ 路徑中每個應用程式的允許權限，並使用 system/priv-app 路徑做為特殊權限路徑，藉此符合這項規定。

防護等級為「危險」的權限是執行階段權限。如果應用程式的 targetSdkVersion 大於 22，則會在執行階段要求這些權限。

裝置實作方式：

• [C-0-3] 必須顯示專屬介面，供使用者決定是否授予要求的執行階段權限，並提供介面供使用者管理執行階段權限。
• [C-0-4] 必須實作這兩個使用者介面，且只能實作一次。
• [C-0-5] 不得授予預先安裝的應用程式任何執行階段權限，除非：
  • 應用程式可先取得使用者同意，再使用這項資訊。
  • 執行階段權限與預先安裝應用程式設為預設處理常式的意圖模式相關聯。
• [C-0-6] 只能將 android.permission.RECOVER_KEYSTORE 權限授予已註冊妥善保護的復原代理程式的系統應用程式。妥善保護的復原代理程式是指裝置上的軟體代理程式，可與裝置外的遠端儲存空間同步處理，並配備安全硬體，防護能力等同或優於Google Cloud Key Vault Service 所述，可防止鎖定螢幕知識因素遭到暴力攻擊。

裝置實作方式：

• [C-0-7] 應用程式透過標準 Android API 或專屬機制要求位置或體能活動資料時，必須遵守 Android 位置存取權屬性。這類資料包括但不限於：

  • 裝置位置 (例如經緯度)。
  • 可用於判斷或推測裝置位置的資訊 (例如 SSID、BSSID、Cell ID、藍牙掃描或裝置連線的網路位置)。
  • 使用者的體能活動或體能活動分類。

具體來說，裝置實作項目包括：

• [C-0-8] 必須徵得使用者同意，才能允許應用程式存取位置或體能活動資料。
• [C-0-9] MUST grant a runtime permission ONLY to the app that holds sufficient permission as described on SDK. 舉例來說，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION)。

權限可以標示為受限，藉此改變權限的行為。

• [C-0-10] 除非符合下列條件，否則不得將標有 hardRestricted 旗標的權限授予應用程式：

  • 應用程式 APK 檔案位於系統磁碟分割區。
  • 使用者將與 hardRestricted 權限相關聯的角色指派給應用程式。
  • 安裝程式會將 hardRestricted 授予應用程式。
  • 應用程式在較舊的 Android 版本中取得 hardRestricted。

• [C-0-11] 應用程式持有 softRestricted 權限時，只能取得有限存取權，且必須先加入 SDK 中所述的允許清單，才能取得完整存取權。SDK 中會針對每個 softRestricted 權限定義完整和有限存取權 (例如 WRITE_EXTERNAL_STORAGE 和 READ_EXTERNAL_STORAGE)。

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

• [SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant or revoke access to the usage stats in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent for apps that declare the android.permission.PACKAGE_USAGE_STATS permission.

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

• [C-1-1] 仍須有處理 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖模式的活動，但須將其實作為無運算元，也就是與使用者拒絕存取時的行為相同。

9.2. UID 和程序隔離

裝置實作方式：

• [C-0-1] MUST support the Android application sandbox model, in which each application runs as a unique Unixstyle UID and in a separate process.
• [C-0-2] MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference.

9.3. 檔案系統權限

裝置實作方式：

• [C-0-1] 必須支援「安全性與權限參考資料」中定義的 Android 檔案存取權限模型。

9.4. 替代執行環境

即使裝置實作項目包含執行應用程式的執行階段環境，且這些應用程式使用的軟體或技術並非 Dalvik Executable Format 或原生程式碼，裝置實作項目也「必須」維持 Android 安全性和權限模型的一致性。換句話說：

• [C-0-1] 替代執行階段本身必須是 Android 應用程式，並遵守標準 Android 安全性模型，如第 9 節所述。

• [C-0-2] 透過 <uses-permission> 機制，替代執行階段「不得」存取受權限保護的資源，且這些權限未在執行階段的 AndroidManifest.xml 檔案中要求。

• [C-0-3] 替代執行階段「不得」允許應用程式使用受 Android 權限保護的功能，這些權限僅限系統應用程式使用。

• [C-0-4] 替代執行階段必須遵守 Android 沙箱模型，且使用替代執行階段安裝的應用程式不得重複使用裝置上任何其他應用程式的沙箱，但透過共用使用者 ID 和簽署憑證等標準 Android 機制除外。

• [C-0-5] 替代執行階段不得啟動、授予或取得與其他 Android 應用程式對應的沙箱存取權。

• [C-0-6] 替代執行階段「不得」啟動，也不得授予或授予其他應用程式超級使用者 (根) 或任何其他使用者 ID 的權限。

• [C-0-7] 如果裝置實作的系統映像檔中包含替代執行階段的 .apk 檔案，則必須使用與裝置實作中其他應用程式簽署金鑰不同的金鑰簽署。

• [C-0-8] 安裝應用程式時，替代執行階段必須取得使用者同意，才能使用應用程式的 Android 權限。

• [C-0-9] 如果應用程式需要使用對應 Android 權限的裝置資源 (例如攝影機、GPS 等)，替代執行階段「必須」通知使用者，應用程式將可存取該資源。

• [C-0-10] 如果執行階段環境未以這種方式記錄應用程式功能，則使用該執行階段安裝任何應用程式時，執行階段環境「必須」列出執行階段本身擁有的所有權限。

• 替代執行階段「應」透過 PackageManager 將應用程式安裝到個別的 Android 沙盒 (Linux 使用者 ID 等)。

• 替代執行階段「可能」會提供單一 Android 沙箱，供使用替代執行階段的所有應用程式共用。

9.5. 支援多位使用者

Android 支援多位使用者，並提供完整的使用者隔離功能。

• 如果裝置使用可移除式媒體做為主要外部儲存空間，則「可以」但「不應」啟用多使用者功能。

如果裝置實作項目包含多位使用者，則：

• [C-1-1] 必須符合下列多使用者支援相關規定。
• [C-1-2] 必須為每位使用者實作與 Android 平台安全模型一致的安全模型，如 API 的「安全性與權限參考文件」中所定義。
• [C-1-3] 每個使用者執行個體都必須有獨立且隔離的共用應用程式儲存空間 (又稱 /sdcard) 目錄。
• [C-1-4] MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to the files owned by any other user, even if the data of both users are stored on the same volume or filesystem.
• [C-1-5] 如果裝置實作使用可移除式媒體做為外部儲存空間 API，則啟用多使用者時，必須使用僅儲存在系統可存取且不可移除媒體上的金鑰，加密 SD 卡內容。因為這樣主機電腦就無法讀取媒體，裝置實作必須切換至 MTP 或類似系統，才能讓主機電腦存取目前使用者的資料。

9.6. 付費簡訊警告

Android 支援在使用者傳送付費簡訊時發出警告。付費簡訊是指傳送給電信業者註冊服務的簡訊，使用者可能需要支付相關費用。

如果裝置實作項目聲明支援 android.hardware.telephony，則：

• [C-1-1] 必須先警告使用者，再將簡訊傳送至裝置 /data/misc/sms/codes.xml 檔案中定義的規則運算式所識別的號碼。上游 Android 開放原始碼計畫提供的實作項目符合這項需求。

9.7. 安全功能

裝置實作項目「必須」確保核心和平台中的安全功能符合下列規定。

Android 沙箱包含的功能會使用 Security-Enhanced Linux (SELinux) 強制存取控管 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全防護功能。裝置實作方式：

• [C-0-1] 即使在 Android 架構下方實作 SELinux 或任何其他安全性功能，也必須維持與現有應用程式的相容性。
• [C-0-2] 如果 Android 框架下方的安全防護功能偵測到安全性違規行為並成功封鎖，則不得顯示使用者介面；但如果發生未封鎖的安全性違規行為，導致成功遭到漏洞攻擊，則可顯示使用者介面。
• [C-0-3] MUST NOT make SELinux or any other security features implemented below the Android framework configurable to the user or app developer.
• [C-0-4] 不得允許應用程式透過 API (例如裝置管理 API) 影響其他應用程式，進而設定不相容的政策。
• [C-0-5] 媒體架構必須分割成多個程序，以便根據 Android 開放原始碼計畫網站所述，為每個程序授予更精細的存取權。
• [C-0-6] MUST implement a kernel application sandboxing mechanism which allows filtering of system calls using a configurable policy from multithreaded programs. 上游 Android 開放原始碼計畫會啟用 seccomp-BPF，並透過執行緒群組同步 (TSYNC) 滿足這項需求，詳情請參閱 source.android.com 的「Kernel Configuration」一節。

核心完整性和自我保護功能是 Android 安全性的重要環節。裝置實作方式：

• [C-0-7] MUST implement kernel stack buffer overflow protection mechanisms. 這類機制包括 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
• [C-0-8] 必須實作嚴格的核心記憶體保護措施，確保可執行程式碼為唯讀，唯讀資料不可執行也不可寫入，可寫入資料不可執行 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
• [C-0-9] 裝置出廠時若搭載 API 級別 28 以上版本，就必須在使用者空間和核心空間之間複製時，實作靜態和動態物件大小界限檢查 (例如 CONFIG_HARDENED_USERCOPY)。
• [C-0-10] 在原始出廠時搭載 API 級別 28 以上版本的裝置上，於核心模式執行時 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬)，不得執行使用者空間記憶體。
• [C-0-11] 在原始出廠時搭載 API 級別 28 以上版本的裝置上，核心不得在正常 usercopy 存取 API (例如硬體 PAN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 之外，讀取或寫入核心中的使用者空間記憶體。
• [C-0-12] 如果硬體容易受到 CVE-2017-5754 影響，則所有原先搭載 API 級別 28 以上版本 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0) 的裝置，都必須實作核心頁面表格隔離功能。
• [C-0-13] 如果硬體容易受到 CVE-2017-5715 影響，則必須在所有原先搭載 API 級別 28 以上版本的裝置 (例如 CONFIG_HARDEN_BRANCH_PREDICTOR) 上，實作分支預測強化功能。
• [SR] STRONGLY RECOMMENDED to keep kernel data which is written only during initialization marked read-only after initialization (e.g. __ro_after_init).

• [C-SR] 強烈建議隨機安排核心程式碼和記憶體的版面配置，並避免暴露會影響隨機安排的資訊 (例如透過 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 使用開機載入程式熵)。 CONFIG_RANDOMIZE_BASE

• [C-SR] 強烈建議在核心中啟用控制流程完整性 (CFI)，進一步防範程式碼重用攻擊 (例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK)。

• [C-SR] 強烈建議不要在已啟用控制流程完整性 (CFI)、陰影呼叫堆疊 (SCS) 或整數溢位清除 (IntSan) 的元件上停用這些功能。
• [C-SR] 強烈建議為任何額外的安全敏感使用者空間元件啟用 CFI、SCS 和 IntSan，詳情請參閱 CFI 和 IntSan。

如果裝置實作項目使用 Linux 核心，則：

• [C-1-1] 必須實作 SELinux。
• [C-1-2] 必須將 SELinux 設為全域強制執行模式。
• [C-1-3] 必須以強制執行模式設定所有網域。不允許任何寬鬆模式網域，包括裝置/供應商專屬網域。
• [C-1-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy folder provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present, for both AOSP SELinux domains as well as device/vendor specific domains.
• [C-1-5] MUST run third-party applications targeting API level 28 or higher in per-application SELinux sandboxes with per-app SELinux restrictions on each application's private data directory.
• 應保留上游 Android 開放原始碼計畫系統/sepolicy 資料夾中提供的預設 SELinux 政策，並僅針對自己的裝置專屬設定進一步新增這項政策。

如果裝置實作項目已在舊版 Android 上推出，且無法透過系統軟體更新滿足 [C-1-1] 和 [C-1-5] 的要求，則可能可豁免這些要求。

如果裝置實作項目使用 Linux 以外的核心，則：

• [C-2-1] 必須使用等同於 SELinux 的強制存取控管系統。

Android 內建多項縱深防禦功能，是裝置安全性的重要環節。

9.8. 隱私權

9.8.1. 使用記錄

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

裝置實作方式：

• [C-0-1] MUST keep a reasonable retention period of such user history.
• [SR] 建議您保留 14 天的保留期限，這是 AOSP 實作中預設的設定。

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

裝置實作方式：

• [C-0-2] 只能包含由 System API 類別 IncidentManager 建立的事件報告中標示 DEST_AUTOMATIC 的欄位。
• [C-0-3] 除了 StatsLog SDK 文件所述的事件外，不得使用系統事件 ID 記錄任何其他事件。如果記錄其他系統事件，這些事件「可能」會使用 100,000 到 200,000 範圍內的不同原子 ID。

9.8.2. 錄製

裝置實作方式：

• [C-0-1] 預先載入或散布的軟體元件不得在未經使用者同意或未顯示清楚的持續性通知的情況下，將使用者的私人資訊 (例如按鍵輸入、螢幕上顯示的文字、錯誤報告) 傳送至裝置外。

• [C-0-2] 透過 MediaProjection 或專有 API 啟用螢幕投放或螢幕錄製功能時，必須顯示與 AOSP 實質相同的訊息，並取得使用者明確同意。不得提供使用者停用日後顯示使用者同意聲明的機制。

• [C-0-3] 啟用螢幕投放或螢幕錄製功能時，必須持續向使用者顯示通知。AOSP 會在狀態列中顯示持續性通知圖示，以符合這項規定。

如果裝置實作項目在系統中包含以下功能：擷取螢幕上顯示的內容，且/或透過系統 API ContentCaptureService 以外的方式錄製裝置上播放的音訊串流，或是第 9.8.6 節「內容擷取」所述的其他專有方式，則：

• [C-1-1] 啟用這項功能並主動擷取/錄製內容時，必須持續性通知使用者。

如果裝置實作項目包含預設啟用的元件，能夠錄製環境音訊和/或錄製裝置播放的音訊，以推斷使用者情境的實用資訊，則：

• [C-2-1] 除非使用者明確同意，否則不得將錄製的原始音訊或任何可轉換回原始音訊或近似音訊的格式，儲存在裝置的永久儲存空間或傳輸到裝置外。

9.8.3. 連線能力

如果裝置實作項目具有支援 USB 周邊裝置模式的 USB 連接埠，則：

• [C-1-1] 必須先顯示使用者介面，徵求使用者同意，才能透過 USB 連接埠存取共用儲存空間的內容。

9.8.4. 網路流量

裝置實作方式：

• [C-0-1] 必須預先安裝系統信任的憑證授權單位 (CA) 存放區的相同根憑證，如上游 Android 開放原始碼計畫提供的憑證。
• [C-0-2] 必須隨附空白的使用者根 CA 存放區。
• [C-0-3] 使用者新增根 CA 時，系統「必須」向使用者顯示警告，指出網路流量可能受到監控。

如果裝置流量是透過 VPN 傳輸，裝置實作項目：

• [C-1-1] 必須向使用者顯示警告，指出下列任一情況：
  • 該網路流量可能會受到監控。
  • 該網路流量會透過提供 VPN 的特定 VPN 應用程式轉送。

如果裝置實作項目預設啟用某種機制，可透過 Proxy 伺服器或 VPN 閘道轉送網路資料流量 (例如預先載入已授予 android.permission.CONTROL_VPN 的 VPN 服務)，則：

• [C-2-1] 啟用該機制前，必須徵求使用者同意，除非 VPN 是由 Device Policy Controller 透過 DevicePolicyManager.setAlwaysOnVpnPackage() 啟用，在這種情況下，使用者不必另外提供同意聲明，但必須收到通知。

如果裝置實作項目提供使用者切換第三方 VPN 應用程式「永久連線 VPN」功能的機制，則：

• [C-3-1] 對於不支援永久連線 VPN 服務的應用程式，請務必透過設定 AndroidManifest.xml 檔案中的 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 屬性為 false，停用這項使用者功能提示。

9.8.5. 裝置 ID

裝置實作方式：

• [C-0-1] 除非符合下列其中一項規定，否則應用程式「必須」禁止存取裝置序號，以及 (如適用) IMEI/MEID、SIM 卡序號和國際行動用戶識別碼 (IMSI)：
  • 是由裝置製造商驗證的簽署電信業者應用程式。
  • 已獲得 READ_PRIVILEGED_PHONE_STATE 權限。
  • 擁有電信業者權限，如「UICC 電信業者權限」一文所述。
  • 是裝置擁有者或設定檔擁有者，且已獲授 READ_PHONE_STATE 權限。
  • (僅限 SIM 卡序號/ICCID) 必須符合當地法規，偵測訂閱者身分證明的變更。

9.8.6. 內容擷取

Android 透過 System API ContentCaptureService 或其他專屬方式，支援裝置實作機制，可擷取應用程式與使用者之間的下列互動：

• 在畫面上顯示的文字和圖像，包括但不限於透過 AssistStructure API 顯示的通知和輔助資料。
• 裝置錄製或播放的媒體資料，例如音訊或影片。
• 輸入事件 (例如按鍵、滑鼠、手勢、語音、影片和無障礙)。
• 應用程式透過 Content Capture API 或類似的專屬 API 提供給系統的任何其他事件。

如果裝置實作項目擷取上述資料，則：

• [C-1-1] 必須加密儲存在裝置中的所有這類資料。這項加密作業「可能」會使用 Android 檔案加密功能，或 Cipher SDK 中列為 API 26 以上版本的任何密碼。
• [C-1-2] 不得使用 Android 備份方法或任何其他備份方法，備份原始或加密資料。
• [C-1-3] 必須僅使用隱私權保護機制傳送所有這類資料和裝置記錄。隱私權保護機制定義為「僅允許匯總分析，並防止記錄的事件或衍生結果與個別使用者相符」，以避免任何使用者資料可供檢查 (例如使用差異化隱私技術 (如 RAPPOR) 實作)。
• [C-1-4] 不得將這類資料與裝置上的任何使用者身分 (例如 Account) 建立關聯，除非每次建立關聯時都徵得使用者的明確同意。
• [C-1-5] 不得與其他應用程式分享這類資料，除非每次分享時都取得使用者明確同意。
• [C-1-6] 如果ContentCaptureService或專有方式收集的資料以任何形式儲存在裝置上，則必須提供使用者清除這類資料的機制。

如果裝置實作項目包含實作 System API ContentCaptureService 的服務，或任何會擷取上述資料的專屬服務，則：

• [C-2-1] 不得允許使用者以可安裝的應用程式或服務取代內容擷取服務，且只能允許預先安裝的服務擷取這類資料。
• [C-2-2] 除了預先安裝的內容擷取服務機制外，不得允許任何應用程式擷取這類資料。
• [C-2-3] 必須提供使用者選項，停用內容擷取服務。
• [C-2-4] 不得省略使用者管理內容擷取服務所持有的 Android 權限，且必須遵循第 9.1 節所述的 Android 權限模式。權限。

• [C-SR] 強烈建議將內容擷取服務元件與其他系統元件分開，例如不要繫結服務或共用程序 ID，但下列情況除外：

  • 電話、聯絡人、系統 UI 和媒體

9.8.7. 剪貼簿存取權

裝置實作方式：

• [C-0-1] 除非應用程式是預設 IME 或目前具有焦點，否則不得傳回剪貼簿上經過裁剪的資料 (例如透過 ClipboardManager API)。

9.8.8. Location

裝置實作方式：

• [C-0-1] 未經使用者明確同意或主動操作，不得開啟/關閉裝置位置資訊設定和 Wi-Fi/藍牙掃描設定。
• [C-0-2] 必須提供使用者介面，讓使用者存取位置相關資訊，包括最近的位置要求、應用程式層級權限，以及使用 Wi-Fi/藍牙掃描功能判斷位置資訊的情形。
• [C-0-3] MUST ensure that the application using Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] is a user initiated emergency session (e.g. dial 911 or text to 911).
• [C-0-4] 必須保留緊急位置資訊繞過 API 的功能，在不變更設定的情況下繞過裝置位置資訊設定。
• [C-0-5] 應用程式在背景使用 [ACCESS_BACKGROUND_LOCATION] 權限存取使用者位置資訊後，必須排定通知，提醒使用者這項行為。

9.9. 資料儲存加密

所有裝置都必須符合第 9.9.1 節的規定。如果裝置的推出 API 級別早於本文件，則可免除 9.9.2 和 9.9.3 節的要求，但必須符合 Android 相容性定義文件 9.9 節的要求，且該文件對應的 API 級別必須與裝置推出時的 API 級別相同。

9.9.1. 直接開機

裝置實作方式：

• [C-0-1] 即使不支援儲存空間加密，也必須實作直接啟動模式 API。

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED Intent 仍須廣播，向可偵測直接啟動的應用程式發出信號，指出裝置加密 (DE) 和憑證加密 (CE) 儲存位置可供使用者使用。

9.9.2. 加密規定

裝置實作方式：

• [C-0-1] 如果應用程式私有資料 (/data 分區) 和應用程式共用儲存空間分區 (/sdcard 分區) 是裝置的永久性部分，且無法移除，則必須加密。
• [C-0-2] 使用者完成開箱設定體驗時，裝置預設必須啟用資料儲存空間加密功能。
• [C-0-3] 必須透過實作檔案式加密 (FBE)，滿足上述資料儲存加密規定。

9.9.3. 檔案型加密

已加密的裝置：

• [C-1-1] 必須啟動，且不會要求使用者提供憑證，並在廣播 ACTION_LOCKED_BOOT_COMPLETED 訊息後，允許支援直接啟動的應用程式存取裝置加密 (DE) 儲存空間。
• [C-1-2] 只有在使用者提供憑證 (例如密碼、PIN 碼、圖案或指紋) 解鎖裝置，且系統已廣播 ACTION_USER_UNLOCKED 訊息後，才可允許存取憑證加密 (CE) 儲存空間。
• [C-1-3] 不得提供任何方法，在沒有使用者提供的憑證或已註冊的保管金鑰的情況下，解鎖 CE 保護的儲存空間。
• [C-1-4] 必須使用驗證開機程序，並確保 DE 金鑰以加密方式繫結至裝置的硬體信任根。
• [C-1-5] 必須使用 AES-256-XTS 或 Adiantum 加密檔案內容。AES-256-XTS 是指以 XTS 模式運作的進階加密標準，加密金鑰長度為 256 位元，完整金鑰長度為 512 位元。Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 所述。
• [C-1-6] 必須使用 AES-256-CBC-CTS 或 Adiantum 加密檔案名稱。

• [C-1-12] 如果裝置有進階加密標準 (AES) 指令，檔案內容必須使用 AES-256-XTS，檔案名稱則必須使用 AES-256-CBC-CTS (而非 Adiantum)。AES 指令是 ARM 型裝置上的 ARMv8 密碼編譯擴充功能，或是 x86 型裝置上的 AES-NI。如果裝置沒有 AES 指令，裝置「可能」會使用 Adiantum。

• 保護 CE 和 DE 儲存空間的金鑰：

• [C-1-7] 必須以加密編譯方式繫結至硬體支援的金鑰儲存區。

• [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
• [C-1-9] 如果使用者未指定螢幕鎖定憑證，CE 金鑰必須繫結至預設密碼。
• [C-1-10] 必須是獨一無二，也就是說，任何使用者的 CE 或 DE 金鑰不得與其他使用者的 CE 或 DE 金鑰相符。
• [C-1-11] 必須使用強制支援的密碼、金鑰長度和模式。

• [C-SR] 強烈建議使用與裝置硬體信任根目錄以密碼編譯方式繫結的金鑰，加密檔案系統中繼資料，例如檔案大小、擁有權、模式和擴充屬性 (xattrs)。

• 預先安裝的必要應用程式 (例如「鬧鐘」、「電話」、「訊息」)「應該」要支援直接啟動。

上游 Android 開放原始碼計畫會根據 Linux 核心的「fscrypt」加密功能，提供這項功能的偏好實作方式。

9.10. 裝置完整性

下列規定可確保裝置完整性狀態資訊公開透明。裝置實作方式：

• [C-0-1] 必須透過 System API 方法 PersistentDataBlockManager.getFlashLockState() 正確回報，指出系統啟動載入程式狀態是否允許刷新系統映像檔。FLASH_LOCK_UNKNOWN 狀態保留給從舊版 Android 升級的裝置實作項目，因為舊版 Android 沒有這個新的系統 API 方法。

• [C-0-2] MUST support Verified Boot for device integrity.

如果裝置實作項目已在較舊的 Android 版本中推出，且無法透過系統軟體更新新增對這項功能的支持，則「可能」可免除這項需求。

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

• [C-1-1] 必須宣告平台功能旗標 android.software.verified_boot。
• [C-1-2] 必須在每個啟動程序中執行驗證。
• [C-1-3] 必須從不可變更的硬體金鑰 (信任根) 開始驗證，一路向上驗證至系統分割區。
• [C-1-4] MUST implement each stage of verification to check the integrity and authenticity of all the bytes in the next stage before executing the code in the next stage.
• [C-1-5] 必須使用與 NIST 目前建議的雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 同等強大的驗證演算法。
• [C-1-6] 系統驗證失敗時，不得允許開機完成，除非使用者同意嘗試開機，在這種情況下，不得使用任何未驗證的儲存區塊資料。
• [C-1-7] 除非使用者已明確解鎖啟動載入程式，否則不得允許修改裝置上的已驗證分割區。
• [C-SR] 如果裝置中有多個獨立晶片 (例如無線電、專用影像處理器)，強烈建議在啟動時驗證每個晶片的啟動程序。
• [C-1-8] 必須使用防竄改儲存空間：用於儲存開機載入程式是否已解鎖。防竄改儲存空間是指開機載入程式可從 Android 內部偵測儲存空間是否遭到竄改。
• [C-1-9] 裝置使用中時，必須提示使用者，並要求實際確認，才能從系統啟動載入程式鎖定模式轉換為系統啟動載入程式解鎖模式。
• [C-1-10] 必須為 Android 使用的分割區 (例如啟動、系統分割區) 實作回溯保護機制，並使用防竄改儲存空間儲存中繼資料，以判斷允許的最低 OS 版本。
• [C-SR] 強烈建議您使用以驗證開機程序保護的分區為根的信任鏈結，驗證所有具備特殊權限的應用程式 APK 檔案。
• [C-SR] 強烈建議您先驗證權限較高的應用程式從 APK 檔案外部載入的可執行構件 (例如動態載入的程式碼或編譯的程式碼)，再執行這些構件，或強烈建議您完全不要執行這些構件。
• 對於任何具有永久韌體的元件 (例如數據機、攝影機)，都「應」實作回溯保護機制，且「應」使用防竄改儲存空間，儲存用於判斷最低允許版本的相關中繼資料。

如果裝置實作項目已發布，但較舊版 Android 不支援 C-1-8 到 C-1-10，且無法透過系統軟體更新新增這些要求，則可能可免除這些要求。

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

裝置實作方式：

• [C-R] 建議支援 Android Protected Confirmation API。

如果裝置實作項目支援 Android Protected Confirmation API，則：

• [C-3-1] 必須回報 true，以瞭解 ConfirmationPrompt.isSupported() API。

• [C-3-2] MUST ensure that code running in the Android OS including its kernel, malicious or otherwise, cannot generate a positive response without user interaction.

• [C-3-3] 即使 Android 作業系統 (包括核心) 遭到入侵，也必須確保使用者能夠查看並核准提示訊息。

9.11. 金鑰和憑證

應用程式開發人員可透過 Android Keystore 系統，將加密編譯金鑰儲存在容器中，並透過 KeyChain API 或 Keystore API 使用這些金鑰執行加密編譯作業。裝置實作方式：

• [C-0-1] MUST allow at least 8,192 keys to be imported or generated.
• [C-0-2] 螢幕鎖定驗證必須限制嘗試次數，且必須採用指數輪詢演算法。如果失敗次數超過 150 次，每次嘗試之間必須間隔至少 24 小時。
• SHOULD not limit the number of keys that can be generated

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

• [C-1-1] MUST back up the keystore implementation with an isolated execution environment.
• [C-1-2] 必須實作 RSA、AES、ECDSA 和 HMAC 密碼編譯演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在與核心和更高層級執行的程式碼安全隔離的區域中，正確支援 Android Keystore 系統支援的演算法。安全隔離機制「必須」封鎖所有潛在機制，避免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 會使用 Trusty 實作項目來滿足這項需求，但您也可以選擇其他以 ARM TrustZone 為基礎的解決方案，或是經過第三方審查的適當管理程序型隔離安全實作項目。
• [C-1-3] MUST perform the lock screen authentication in the isolated execution environment and only when successful, allow the authentication-bound keys to be used. 螢幕鎖定憑證的儲存方式必須確保只有獨立執行環境可以執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。
• [C-1-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業在安全硬體中執行。認證簽署金鑰必須在足夠數量的裝置間共用，以防止金鑰做為裝置 ID 使用。如要符合這項規定，除非特定 SKU 的產量至少達到 10 萬部，否則請共用相同的認證金鑰。如果 SKU 的生產數量超過 10 萬個，每 10 萬個單位「可能」會使用不同的金鑰。

請注意，如果裝置實作作業已在較早的 Android 版本上推出，則這類裝置可免除必須具備由獨立執行環境支援的金鑰儲存區，以及支援金鑰認證的要求，除非裝置聲明 android.hardware.fingerprint 功能，而這項功能需要由獨立執行環境支援的金鑰儲存區。

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

9.11.1. 安全鎖定螢幕和驗證

AOSP 實作項目採用分層驗證模型，以知識因素為基礎的主要驗證可由次要的強效生物特徵辨識或較弱的第三層模式支援。

裝置實作方式：

• [C-SR] 強烈建議只將下列其中一種方法設為主要驗證方式：
  • 數字 PIN 碼
  • 英數字元密碼
  • 在 3x3 點格線上滑動的模式

請注意，本文將上述驗證方法稱為建議的主要驗證方法。

如果裝置實作項目新增或修改建議的主要驗證方法，並使用新的驗證方法做為鎖定螢幕的安全方式，則新的驗證方法：

• [C-2-1] 必須是「要求驗證使用者才能使用金鑰」一節所述的使用者驗證方法。
• [C-2-2] 使用者解鎖安全螢幕鎖定時，第三方開發人員應用程式必須解鎖所有金鑰。舉例來說，所有金鑰都必須透過相關 API (例如 createConfirmDeviceCredentialIntent 和 setUserAuthenticationRequired) 提供給第三方開發人員應用程式。

如果裝置實作項目新增或修改驗證方法，以便根據已知密碼解鎖螢幕鎖定畫面，並使用新的驗證方法做為安全鎖定螢幕的方式：

• [C-3-1] 輸入內容最短長度的熵值必須大於 10 位元。
• [C-3-2] 所有可能輸入內容的最大熵值必須大於 18 位元。
• [C-3-3] 新的驗證方法不得取代 AOSP 實作及提供的任何建議主要驗證方法 (即 PIN 碼、圖案、密碼)。
• [C-3-4] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定的密碼品質政策，其限制性常數比 PASSWORD_QUALITY_SOMETHING 更嚴格，則必須停用新的驗證方法。
• [C-3-5] 新的驗證方法必須每 72 小時或更短時間，還原為建議的主要驗證方法 (即 PIN 碼、圖案、密碼)，或清楚向使用者揭露部分資料不會備份，以保護資料隱私權。

如果裝置實作項目新增或修改建議的主要驗證方法，以便解鎖螢幕鎖定，並使用以生物特徵辨識為基礎的新驗證方法，將其視為安全鎖定螢幕的方式，則新方法：

• [C-4-1] 必須符合第 7.3.10 節中針對「便利性」的所有規定。
• [C-4-2] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.
• [C-4-3] 如果裝置政策控制器 (DPC) 應用程式呼叫 DevicePolicyManager.setKeyguardDisabledFeatures() 方法，並設定任何相關聯的生物特徵辨識旗標 (即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS)，則必須停用此功能，且只能允許使用建議的主要驗證方式解鎖螢幕。

如果生物特徵辨識驗證方法不符合第 7.3.10 節所述的高強度規定：

• [C-5-1] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定的密碼品質政策比 PASSWORD_QUALITY_BIOMETRIC_WEAK 嚴格，就必須停用這些方法。
• [C-5-2] 閒置時間超過 4 小時後，系統「必須」要求使用者進行建議的主要驗證 (例如：PIN 碼、解鎖圖案、密碼)。成功確認裝置憑證後，閒置逾時時間會重設。
• [C-5-3] 這些方法「不得」視為安全螢幕鎖定，且「必須」符合本節下方以 C-8 開頭的規定。

如果裝置實作項目新增或修改了用來解鎖螢幕鎖定的驗證方法，且新的驗證方法是以實體權杖或位置資訊為依據：

• [C-6-1] 他們「必須」具備備援機制，可使用其中一種建議的主要驗證方法 (以已知密碼為依據)，並符合視為安全螢幕鎖定的條件。
• [C-6-2] 如果裝置政策控制器 (DPC) 應用程式已透過 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法設定政策，且品質常數比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格，則必須停用新方法，且只能使用其中一種建議的主要驗證方法解鎖螢幕。
• [C-6-3] 至少每隔 4 小時，系統就必須要求使用者進行一次建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)。
• [C-6-4] 新方法「不得」視為安全鎖定螢幕，且「必須」遵守下方 C-8 列出的限制。

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

• [C-7-1] 裝置鎖定延遲或可由信任的代理程式保持解鎖狀態時，設定選單和螢幕鎖定上必須清楚顯示相關資訊。舉例來說，AOSP 會在設定選單中顯示「自動鎖定設定」和「按下電源鍵立即鎖定」的文字說明，並在鎖定畫面上顯示可辨識的圖示，藉此符合這項規定。
• [C-7-2] 必須遵守並完整實作 DevicePolicyManager 類別中的所有信任的代理程式 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常數。
• [C-7-3] 不得在主要個人裝置 (例如手持式裝置) 上完整實作 TrustAgentService.addEscrowToken() 功能，但可在通常會共用的裝置實作項目 (例如 Android TV 或車用裝置) 上完整實作該功能。
• [C-7-4] MUST encrypt all stored tokens added by TrustAgentService.addEscrowToken().
• [C-7-5] 不得在金鑰使用的同一部裝置上儲存加密金鑰或託管權杖。舉例來說，手機上儲存的金鑰可以解鎖電視上的使用者帳戶。
• [C-7-6] 啟用代管權杖來解密資料儲存空間前，必須告知使用者安全影響。
• [C-7-7] MUST have a fall-back mechanism to use one of the recommended primary authentication methods.
• [C-7-8] 除非擔心使用者安全 (例如駕駛人分心)，否則系統必須至少每 72 小時要求使用者進行一次建議的主要驗證 (例如 PIN 碼、解鎖圖案、密碼)。
• [C-7-9] 除非使用者安全 (例如駕駛人分心) 受到威脅，否則在任何 4 小時的閒置逾時期間後，系統「必須」要求使用者採用其中一種建議的主要驗證方法 (例如 PIN 碼、圖案、密碼)。成功確認裝置憑證後，閒置逾時時間會重設。
• [C-7-10] 不得視為安全螢幕鎖定，且必須遵守下方 C-8 列出的限制。
• [C-7-11] 不得允許主要個人裝置 (例如手持式裝置) 上的 TrustAgent 解鎖裝置，且只能使用 TrustAgent 將已解鎖的裝置維持在解鎖狀態，最多 4 小時。Android 開放原始碼計畫 (AOSP) 中的 TrustManagerService 預設實作方式符合這項規定。
• [C-7-12] MUST use a cryptographically secure (e.g UKEY2) communication channel to pass the escrow token from the storage device to the target device.

如果裝置實作項目新增或修改驗證方式，以解除鎖定上述非安全螢幕鎖定，並使用新的驗證方式解除鎖定 Keyguard：

• [C-8-1] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定的密碼品質政策比 PASSWORD_QUALITY_UNSPECIFIED 嚴格，則必須停用新方法。
• [C-8-2] 他們「不得」重設 DevicePolicyManager.setPasswordExpirationTimeout() 設定的密碼到期計時器。
• [C-8-3] 裝置「不得」公開 API，供第三方應用程式變更鎖定狀態。

9.11.2. StrongBox

Android Keystore 系統可讓應用程式開發人員將加密編譯金鑰儲存在專屬安全處理器，以及上述隔離的執行環境中。這類專用安全處理器稱為「StrongBox」。下方 C-1-3 至 C-1-11 的規定定義了裝置必須符合的條件，才能成為 StrongBox。

具有專用安全處理器的裝置實作項目：

• [C-SR] Are STRONGLY RECOMMENDED to support StrongBox. 日後推出的版本可能需要使用 StrongBox。

如果裝置實作項目支援 StrongBox，則：

• [C-1-1] 必須宣告 FEATURE_STRONGBOX_KEYSTORE。

• [C-1-2] 必須提供專用的安全硬體，用於備份 KeyStore 和確保使用者驗證安全。專屬安全硬體也可能用於其他用途。

• [C-1-3] 必須具備獨立 CPU，且不得與應用程式處理器 (AP) 共用快取、DRAM、協同處理器或其他核心資源。

• [C-1-4] 必須確保與 AP 共用的任何周邊裝置，都無法以任何方式變更 StrongBox 處理程序，或從 StrongBox 取得任何資訊。AP「可能」會停用或封鎖 StrongBox 的存取權。

• [C-1-5] 必須具備合理準確度 (±10%) 的內部時鐘，且不受 AP 操控。

• [C-1-6] 必須具備真正的隨機號碼產生器，可產生均勻分布且無法預測的輸出內容。

• [C-1-7] 必須具備防竄改功能，包括防範實體入侵和故障。

• [C-1-8] 必須具備側通道抗性，包括防範透過電力、時序、電磁輻射和熱輻射側通道洩漏資訊。

• [C-1-9] 必須具備安全儲存空間，確保內容的機密性、完整性、真實性、一致性和新鮮度。除非 StrongBox API 允許，否則不得讀取或變更儲存空間。

• 如要驗證裝置實作是否符合 [C-1-3] 至 [C-1-9]，請：

  • [C-1-10] 必須包含通過安全 IC 保護剖繪 BSI-CC-PP-0084-2014 認證的硬體，或由國家認證的測試實驗室評估，並根據通用標準應用程式的智慧卡攻擊潛力納入高攻擊潛力漏洞評估。
  • [C-1-11] 必須包含由國家認證測試實驗室評估的韌體，並根據「Common Criteria Application of Attack Potential to Smartcards」納入高攻擊潛力漏洞評估。
  • [C-SR] 強烈建議納入使用安全目標評估的硬體，評估保證等級 (EAL) 為 5，並以 AVA_VAN.5 擴增。日後推出的版本可能需要 EAL 5 認證。

• [C-SR] 建議「強烈」提供內部攻擊防禦 (IAR) 功能，也就是說，即使內部人員有權存取韌體簽署金鑰，也無法產生會導致 StrongBox 洩漏機密、規避功能安全需求，或以其他方式存取敏感使用者資料的韌體。建議您實作 IAR 時，只允許透過 IAuthSecret HAL 提供主要使用者密碼，藉此更新韌體。

9.12. 資料刪除

所有裝置實作項目：

• [C-0-1] 必須提供使用者執行「恢復原廠設定」的機制。
• [C-0-2] MUST delete all data on the userdata filesystem.
• [C-0-3] 必須以符合相關產業標準 (例如 NIST SP800-88) 的方式刪除資料。
• [C-0-4] 當主要使用者的裝置政策控制器應用程式呼叫 DevicePolicyManager.wipeData() API 時，必須觸發上述「恢復原廠設定」程序。
• MAY 提供快速資料清除選項，只會執行邏輯資料清除作業。

9.13. 安全啟動模式

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

裝置實作方式如下：

• [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

如果裝置實作安全啟動模式，則：

• [C-1-1] 必須提供使用者進入安全啟動模式的選項，且不得中斷裝置上安裝的第三方應用程式，但第三方應用程式是裝置政策控制器，且已將 UserManager.DISALLOW_SAFE_BOOT 旗標設為 true 時除外。

• [C-1-2] MUST provide the user the capability to uninstall any third-party apps within Safe Mode.

• SHOULD 提供使用者從開機選單進入安全開機模式的選項，但工作流程應與正常開機不同。

9.14. 車輛系統隔離

Android Automotive 裝置應使用車輛 HAL，透過 CAN 匯流排等車輛網路傳送及接收訊息，與重要車輛子系統交換資料。

實作 Android 架構層下方的安全功能，即可保護資料交換程序，防止惡意或無意與這些子系統互動。

9.15. 訂閱方案

「訂閱方案」是指行動電信業者透過 SubscriptionManager.setSubscriptionPlans() 提供的帳單關係方案詳細資料。

所有裝置實作項目：

• [C-0-1] MUST return subscription plans only to the mobile carrier app that has originally provided them.
• [C-0-2] 不得從遠端備份或上傳訂閱方案。
• [C-0-3] 只能允許覆寫，例如 SubscriptionManager.setSubscriptionOverrideCongested()，且只能來自目前提供有效訂閱方案的行動電信業者應用程式。

10. 軟體相容性測試

裝置實作項目必須通過本節所述的所有測試。不過請注意，沒有任何軟體測試套件是完全全面性的。因此，強烈建議裝置實作者盡可能減少對 Android 開放原始碼計畫提供的 Android 參考和偏好實作方式進行變更。這樣做可盡量避免因導入錯誤而產生不相容問題，導致需要重新製作及更新裝置。

10.1. 相容性測試套件

裝置實作方式：

• [C-0-1] 裝置必須使用最終出貨軟體，通過 Android 開放原始碼計畫提供的 Android 相容性測試套件 (CTS)。

• [C-0-2] 如有 CTS 模糊不清之處，以及重新實作參考原始碼部分內容的情況，必須確保相容性。

CTS 專為在實際裝置上執行而設計。與任何軟體一樣，CTS 本身可能含有錯誤。CTS 的版本與本相容性定義無關，Android 10 可能會發布多個 CTS 修訂版本。

裝置實作方式：

• [C-0-3] 裝置軟體完成時，必須通過最新版 CTS。

• SHOULD use the reference implementation in the Android Open Source tree as much as possible.

10.2. CTS 驗證器

CTS Verifier 隨附於 Compatibility Test Suite，供人員操作，測試自動化系統無法測試的功能，例如相機和感應器是否正常運作。

裝置實作方式：

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

CTS 驗證器包含多種硬體的測試，包括部分選用硬體。

裝置實作方式：

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

如果相容性定義說明文件將功能標示為選用，則可略過或省略相關測試案例。

• [C-0-2] 如上所述，每個裝置和每個建構版本都必須正確執行 CTS 驗證器。不過，由於許多建構版本非常相似，因此如果建構版本只有微不足道的差異，裝置實作人員就不必明確執行 CTS 驗證器。具體來說，如果裝置實作方式與通過 CTS 驗證器測試的實作方式不同，僅在於內含的語言代碼集、品牌等，則可省略 CTS 驗證器測試。

11. 可更新的軟體

• [C-0-1] 裝置實作內容必須包含可取代整個系統軟體的機制。這項機制不一定要執行「即時」升級，也就是說，裝置「可能」需要重新啟動。只要能取代裝置上預先安裝的所有軟體，任何方法都適用。舉例來說，下列任一方法都符合這項規定：

  • 透過「無線更新」(OTA) 下載，並在重新啟動後離線更新。
  • 透過 USB 從主機電腦「連線」更新。
  • 「離線」更新：透過重新啟動裝置，並從卸除式儲存裝置上的檔案更新。

• [C-0-2] 所用的更新機制必須支援更新，且不會清除使用者資料。也就是說，更新機制「必須」保留應用程式私人資料和應用程式共用資料。請注意，上游 Android 軟體包含符合這項規定的更新機制。

• [C-0-3] 整個更新內容「必須」經過簽署，且裝置上的更新機制「必須」根據裝置上儲存的公開金鑰，驗證更新內容和簽章。

• [C-SR] 強烈建議簽署機制使用 SHA-256 雜湊更新，並使用 ECDSA NIST P-256 針對公開金鑰驗證雜湊。

如果裝置實作項目支援不計量的數據連線，例如 802.11 或藍牙 PAN (個人區域網路) 設定檔，則：

• [C-1-1] 必須支援透過重新啟動進行離線更新的無線下載。

如果裝置實作項目是透過 Android 6.0 以上版本啟動，更新機制「應」支援驗證系統映像檔在 OTA 後是否與預期結果完全相同。上游 Android 開放原始碼計畫中以區塊為基礎的 OTA 實作方式 (自 Android 5.1 起新增)，符合這項規定。

此外，裝置實作項目「應」支援 A/B 系統更新。AOSP 會使用啟動控制 HAL 實作這項功能。

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

• [C-2-1] 裝置實作人員必須透過軟體更新修正錯誤，並按照上述機制套用更新。

Android 內建多項功能，可讓裝置擁有者應用程式 (如有) 控制系統更新的安裝作業。如果裝置的系統更新子系統回報 android.software.device_admin，則：

• [C-3-1] 必須實作 SystemUpdatePolicy 類別中說明的行為。

12. 文件變更記錄

如要查看這個版本相容性定義的變更摘要：

• 文件修訂記錄

各個部分異動內容的摘要：

1. 簡介
2. 裝置類型
3. 軟體
4. 應用程式封裝
5. 多媒體
6. 開發人員工具和選項
7. 硬體相容性
8. 效能和電力
9. 安全模式
10. 軟體相容性測試
11. 可更新的軟體
12. 文件變更記錄
13. 聯絡我們

12.1. 查看變更記錄的訣竅

變更內容標示如下：

• CDD
  相容性需求有重大異動。

• 文件
  與外觀或建構相關的變更。

如要獲得最佳觀看體驗，請在更新記錄網址中附加 pretty=full 和 no-merges 網址參數。

13. 與我們聯絡

您可以加入 android-compatibility 論壇，要求釐清問題，或提出您認為文件未涵蓋的任何問題。