Android 10 相容性定義

1. 引言

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

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

如本文件所述，「裝置實作者」或「實作器」是指開發搭載 Android 10 的硬體/軟體解決方案的個人或機構。「裝置導入」或「導入」是硬體/軟體解決方案開發的

裝置實作項目「必須」符合此相容性定義中的規定，包括透過參考資料納入的任何文件，才能符合 Android 10 相容性規定。

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

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

本文件中所連結的許多資源都是直接或間接從 Android SDK 衍生，運作方式與 SDK 說明文件中的資訊相同。無論此 Compatibility Definition 或 Compatibility Test Suite 無法認同 SDK 說明文件，皆可視為具有權威性的 SDK 說明文件。本文連結的所有資源中提供的技術細節都會納入此相容性定義。

1.1 文件結構

1.1.1.各裝置類型的規定

第 2 節：說明適用於特定裝置類型的所有規定。第 2 節的每個子節都專指特定裝置類型。

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

1.1.2.規定 ID

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

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

每個 ID 的定義如下：

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

1.1.3.第 2 節的規定 ID

第 2 節中的規定 ID 開頭為對應的版面 ID，後面接著上述規定 ID。

• 第 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 手持裝置實作方式。

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

2.2.1. 硬體

手持裝置實作方式：

• [7.1.1.1/H-0-1] 實體對角線大小至少須有 2.5 吋與 Android 相容的螢幕，且所有與 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] 強烈建議「只」啟動使用者選取的輔助應用程式：也就是實作 VoiceInteractionService 的應用程式；如果前景活動不處理這些長按事件，則在長按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 時處理 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 根據資料計算結果，也必須立即回報。
• [7.3.3/H-2-2] 必須回報 GNSS 虛擬範圍和虛擬範圍比率；在判斷地點後，如果是靜止或移動的加速度低於 0.2 公尺的每秒平方公尺，就足以計算在 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] 必須支援藍牙和藍牙 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，則必須針對 ActivityManager.isLowRamDevice() 傳回「true」。

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

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

• [7.6.1/H-2-1] 如果預設顯示螢幕採用最高 HD+ 的 framebuffer 解析度 (例如 HD、WSVGA)，核心和使用者空間的可用記憶體必須至少為 592 MB。

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

• [7.6.1/H-4-1] 如果預設顯示畫面採用最高 QHD (例如 QWXGA) 的影格緩衝區解析度，核心和使用者空間的可用記憶體大小「必須」為至少 1344 MB。

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

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

• [7.6.1/H-6-1] 如果預設顯示螢幕採用最高 HD+ 的 framebuffer 解析度 (例如 HD、WSVGA)，核心和使用者空間可用的記憶體「必須」為至少 944 MB。

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

• [7.6.1/H-8-1] 如果預設顯示畫面採用最高 QHD (例如 QWXGA) 的影格緩衝區解析度，核心和使用者空間的可用記憶體大小「必須」為至少 1824 MB。

請注意，「核心和使用者空間可用的記憶體」上述所附的記憶體空間，以及已專門用於硬體元件 (例如無線電、影片等) 不受核心在裝置實作控制控制的記憶體空間外的記憶體空間。

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

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

如果手持裝置實作包含超過 1 GB 可用記憶體，供核心和使用者空間使用，程式碼會執行以下動作：

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

手持裝置實作方式：

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

如果手持裝置內含支援週邊裝置模式的 USB 連接埠，就會：

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

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

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

手持裝置實作方式：

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

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

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

如果手持裝置實作在主機模式中加入一或多個 USB-C 連接埠並實作 (USB 音訊類別)，除了第 7.7.2 節的規定外，請加入下列要求：

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

功能	對應	背景資訊	行為
A 罩杯	HID 用量頁面：0x0C HID 用量：0x0CD 核心金鑰：KEY_PLAYPAUSE Android 金鑰：KEYCODE_MEDIA_PLAY_PAUSE	媒體播放	輸入來源：短按 輸出：播放或暫停
			輸入來源：長按 輸出：啟動語音指令 已傳送：android.speech.action.VOICE_SEARCH_HANDS_FREE (如果裝置處於鎖定狀態或螢幕關閉)。否則會傳送 android.speech.RecognizerIntent.ACTION_WEB_SEARCH
		來電	輸入來源：短按 輸出：接聽來電
			輸入來源：長按 輸出：拒接來電
		通話中	輸入來源：短按 輸出：結束通話
			輸入來源：長按 輸出：將麥克風設為靜音或取消靜音
B 罩杯	HID 用量頁面：0x0C HID 用量：0x0E9 核心金鑰：KEY_VOLUMEUP Android 金鑰：VOLUME_UP	媒體播放、通話中	輸入來源：長按 輸出：調高系統或耳機的音量
C 罩杯	HID 用量頁面：0x0C HID 用量：0x0EA 核心金鑰：KEY_VOLUMEDOWN Android 金鑰：VOLUME_DOWN	媒體播放、通話中	輸入來源：長按 輸出：調低系統或耳機的音量
D	HID 用量頁面：0x0C HID 用量：0x0CF 核心金鑰：KEY_VOICECOMMAND Android 金鑰：KEYCODE_VOICE_ASSIST	。可以在任何執行個體中觸發。	輸入來源：長按 輸出：啟動語音指令

• [7.8.2.2/H-1-2] 插入插頭時必須觸發 ACTION_HEADSET_PLUG，但必須在 USB 音訊介面和端點正確列舉後，才能識別已連接的端子類型。

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

• [7.8.2.2/H-2-1] 必須透過「麥克風」廣播 Intent ACTION_HEADSET_PLUG將更多的值設為 0。

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

• [7.8.2.2/H-3-1] 必須透過「麥克風」廣播 Intent ACTION_HEADSET_PLUG將額外設為 1

連接 USB 週邊裝置時呼叫 API AudioManager.getDevices() 時，系統會執行以下動作：

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

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

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

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

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

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

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

• [7.8.2.2/H-SR] 強烈推薦在 USB-C 音訊週邊裝置連線時執行 USB 描述元列舉、在 1000 毫秒內識別終端機類型和廣播意圖 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] 「必須」擁有應用程式，依 SDK 文件所述處理 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT 意圖，並使用 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] 必須允許第三方應用程式透過 Notification 和 NotificationManager API 類別通知使用者值得注意的事件。
• [3.8.3/H-0-2] 必須支援複合式通知。
• [3.8.3/H-0-3] 必須支援抬頭通知，
• [3.8.3/H-0-4] 必須納入通知欄，讓使用者能夠透過使用者預設用途直接控制 (例如回覆、延後、關閉、封鎖) 通知 (如在 Android 開放原始碼計畫中導入的動作按鈕或控制台等)。
• [3.8.3/H-0-5] 必須在通知欄中顯示透過 RemoteInput.Builder setChoices() 提供的選項。
• [3.8.3/H-SR] 強烈建議你直接在通知欄中顯示透過 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] 強烈建議你在裝置上實作助理，以便處理輔助動作。

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

• [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 裝置時，會將其回報為低 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] 必須確保連續寫入效能至少達到 5 MB。
• [8.2/H-0-2] 必須確保每秒至少寫入效能達到 0.5 MB。
• [8.2/H-0-3] 必須確保連續讀取效能至少達到 15 MB。
• [8.2/H-0-4] 必須確保隨機讀取效能達到每秒至少 3.5 MB。

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

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

手持裝置實作方式：

• [8.4/H-0-1] 「必須」依元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。
• [8.4/H-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/H-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/H-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，將電源用量提供給應用程式開發人員。
• [8.4/H] 無法將硬體元件的電力用量歸功給應用程式時，應歸於硬體元件本身。

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

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

2.2.5。安全性模型

手持裝置實作方式：

• [9.1/H-0-1] 「必須」允許第三方應用程式透過 android.permission.PACKAGE_USAGE_STATS 權限存取使用統計資料，並提供使用者可存取的機制，以回應 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，授予或撤銷對這類應用程式的存取權。

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

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

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

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

• [9.11/H-1-1] 必須允許使用者選擇最短的睡眠逾時時間 (也就是從解鎖狀態到鎖定狀態的最短時間，不超過 15 秒)。
• [9.11/H-1-2] 必須為使用者提供隱藏通知和停用所有驗證形式的功能，但「9.11.1 安全螢幕鎖定」中所述的主要驗證除外。Android 開放原始碼計畫符合鎖定模式的規定。

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

• [9.5/H-2-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

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

• [9.5/H-3-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

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

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

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

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

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

2.3.電視需求

Android 電視裝置是一種 Android 裝置實作服務，屬於娛樂介面，適合身處約 10 英尺 (「向後」或「10 英尺」的使用者介面) 的使用者觀看數位媒體、電影、遊戲、應用程式和/或電視直播內容。

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

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

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

2.3.1.硬體

電視裝置導入方式：

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

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

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

電視裝置導入方式：

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

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

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

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

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

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

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

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

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

請注意，「核心和使用者空間可用的記憶體」上述所附的記憶體空間，以及已專門用於硬體元件 (例如無線電、影片等) 不受核心在裝置實作控制控制的記憶體空間外的記憶體空間。

電視裝置導入方式：

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

2.3.2.多媒體

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

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

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

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

電視裝置導入方式：

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

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

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

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

• [5.3.1/T-1-1] HD 高畫質 1080p (每秒 29.97 影格) 搭配主要設定檔的高階畫面。
• [5.3.1/T-1-2] HD 高畫質 1080i，每秒 59.94 影格，搭配主要設定檔高階裝置。他們「必須」對交錯的 MPEG-2 影片提供交錯處理，並提供給第三方應用程式使用。

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

• [5.3.4/T-1-1] 使用基準設定檔，以每秒 60 個影格的速度播放 HD 高畫質 1080p 影片
• [5.3.4/T-1-2] HD 高畫質 1080p (每秒 60 影格) 搭配主要設定檔
• [5.3.4/T-1-3] HD 高畫質 1080p (每秒 60 影格) 和高設定檔等級 4.2

若電視裝置採用 H.265 硬體解碼器，「必須」支援 H.265 解碼器 (如第 5.3.5 節所述)，以標準影片影格速率和解析度，最高包括：

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

如果電視裝置實作採用 H.265 硬體解碼器，可支援 H.265 解碼和 UHD 解碼設定檔，請按照下列步驟操作：

• [5.3.5/T-2-1] 使用 Main10 第 5 級主要設定檔時，必須支援每秒 60 影格的 UHD 解碼設定檔。

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

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

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

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

如果電視裝置實作搭配 VP9 硬體解碼器，可支援 VP9 解碼和 UHD 超高畫質設定檔，請按照下列步驟操作：

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

電視裝置導入方式：

• [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] 必須支援 HDCP 2.2。

如果電視裝置實作不支援 UHD 解碼功能，而需支援透過 HDMI 連接外接螢幕，裝置就會：

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

2.3.3.軟體

電視裝置導入方式：

• [3/T-0-1] 必須宣告 android.software.leanback 和 android.hardware.type.television 功能。
• [3.4.1/T-0-1] 必須提供 android.webkit.Webview API 的完整實作。

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

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

電視裝置導入方式：

• [3.8.14/T-SR] 強烈建議你支援子母畫面 (PIP) 模式多視窗模式。
• [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] 必須支援電視輸入架構。

2.3.4.效能與功率

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

如果電視裝置實作包含改善裝置電源管理功能 (Android 開放原始碼計畫) 的功能，或擴充 Android 開放原始碼計畫包含的功能，請按照下列步驟操作：

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

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

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

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

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

電視裝置導入方式：

• [8.4/T-0-1] 「必須」依元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。
• [8.4/T-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/T-0-3] 必須回報每個程序 UID 的 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/T] 無法將硬體元件的電力用量歸功給應用程式時，應歸於硬體元件本身。
• [8.4/T-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，將電源用量提供給應用程式開發人員。

2.3.5。安全性模型

電視裝置導入方式：

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

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

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

• [9.11/T-1-1] 必須允許使用者選擇從解鎖狀態轉換成鎖定狀態的睡眠逾時時間，且允許的逾時時間最短應設為 15 秒。

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

• [9.5/T-2-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

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

• [9.5/T-3-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

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

電視裝置導入方式：

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

2.4.智慧手錶需求

Android Watch 裝置是指想戴在身體 (例如手腕) 上的 Android 裝置實作。

Android 裝置的實作方式須符合下列所有條件，才能歸類為 Watch：

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

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

2.4.1.硬體

手錶裝置實作：

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

• [7.2.3/W-0-1] 必須為使用者提供主畫面功能和返回功能，但位於 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 公尺的每秒平方公尺，就足以在 20 公尺內，以每秒 0.2 公尺 (0.2 公尺) 的範圍內計算位置，至少在 0.2 公尺以內。

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

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

手錶裝置實作：

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

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

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

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

• [7.8.2/W] 可能，但「不」有音訊輸出裝置。

2.4.2.多媒體

沒有其他相關規定。

2.4.3.軟體

手錶裝置實作：

• [3/W-0-1] 必須聲明 android.hardware.type.watch 功能。
• [3/W-0-2] 必須支援 uiMode = UI_MODE_TYPE_WATCH。

手錶裝置實作：

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

宣告 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.效能與功率

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

• [8.3/W-SR] 強烈建議向使用者提供充足空間，以顯示不受應用程式待命和打盹省電模式豁免的應用程式。
• [8.3/W-SR] 極力建議為使用者提供預設預算來啟用和停用省電功能。

手錶裝置實作：

• [8.4/W-0-1] 必須為每個元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。
• [8.4/W-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/W-0-3] 必須回報每個程序 UID 的 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/W-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，將電源用量提供給應用程式開發人員。
• [8.4/W] 無法歸屬於應用程式的硬體元件電力使用時，應歸於硬體元件本身。

2.4.5。安全性模型

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

• [9.5/W-1-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

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

• [9.5/W-2-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

2.5.汽車規定

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

如果 Android 裝置的實作方式宣告了 android.hardware.type.automotive 功能或符合下列所有條件，系統就會將這類裝置歸類為 Automotive。

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

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

2.5.1.硬體

Automotive 裝置實作：

• [7.1.1.1/A-0-1] 螢幕對角線長度至少要有 6 吋。

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

• [7.2.3/A-0-1] 「必須」提供主畫面功能，且「可能」提供返回和最近使用的功能。

• [7.2.3/A-0-2] 必須將返回函式的正常和長按事件 (KEYCODE_BACK) 同時傳送至前景應用程式。
• [7.3/A-0-1] 必須導入並回報 GEAR_SELECTION、NIGHT_MODE、PERF_VEHICLE_SPEED 和 PARKING_BRAKE_ON。
• [7.3/A-0-2] NIGHT_MODE 旗標的值必須與資訊主頁日/夜間模式一致，且應該根據環境光度感應器輸入的資料。基礎環境光度感應器可能與 Photometer 相同。
• [7.3/A-0-3] 針對每個提供的感應器，「必須」提供感應器的其他資訊欄位 TYPE_SENSOR_PLACEMENT。
• [7.3/A-0-1] 將 GPS/GNSS 結合其他感應器，導致地點失效。如果「位置」不明，強烈建議導入及回報所用感應器類型和/或車輛物業 ID。
• [7.3/A-0-2] 透過 LocationManager#requestLocationUpdates() 要求的 Location 位置「不得」對應。

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

• [7.3.1/A-1-1] 事件的回報頻率必須至少為 100 Hz。
• [7.3.1/A-1-2] 必須遵守 Android 車用感應器座標系統。

如果 Automotive 裝置導入作業包含 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] 強烈建議將陀螺儀的測量範圍設為 +/-250dp，盡可能提高解析度

Automotive 裝置實作：

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

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

  • 透過免持聽筒設定檔 (HFP) 撥打電話。
  • 透過音訊發布設定檔 (A2DP) 播放媒體。
  • 遠端控制設定檔 (AVRCP) 的媒體播放控制項。
  • 透過電話簿存取設定檔 (PBAP) 分享聯絡人。

• [7.4.3/A-SR] 強烈建議支援訊息存取設定檔 (MAP)。

• [7.4.5/A] 必須支援行動網路數據連線。

• [7.4.5/A] 可能會針對系統應用程式可用的網路使用 System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常數。

室外視角相機是指拍攝裝置以外的場景 (例如行車記錄器)。

Automotive 裝置實作：

• 必須設置一或多個室外視角相機。

如果 Automotive 裝置導入了這類相機的室外視角相機，請按照下列步驟操作：

• [7.5/A-1-1]「不得」具備透過 Android Camera API 存取的外側鏡頭，除非其符合相機核心需求。
• [7.5/A-SR] 強烈建議不要旋轉或水平鏡射相機預覽畫面。
• [7.5.5/A-SR] 強烈建議拍攝方向，確保攝影機的長邊對齊地平線。
• [7.5/A-SR] 強烈建議採用至少 130 萬像素的解析度。
• 應使用固定對焦或 EDOF (延伸領域深度) 硬體。
• 相機驅動程式中可能具備硬體自動對焦或軟體自動對焦功能。

Automotive 裝置實作：

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

• [7.6.1/A] 必須設定資料分區的格式，才能提高執行效能和快閃儲存的壽命，例如使用 f2fs 檔案系統。

如果 Automotive 裝置實作會透過部分內部非卸除儲存空間提供共用外部儲存空間，則會造成以下影響：

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

如果 Automotive 裝置實作作業是 32 位元：

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

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

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

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

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

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

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

  • 在小螢幕/一般螢幕上，採用 560 dpi 以上
  • 在大螢幕裝置上播放 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕

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

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

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

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

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

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

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

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

  • 在小螢幕/一般螢幕上，採用 560 dpi 以上
  • 在大螢幕裝置上播放 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕

請注意，「核心和使用者空間可用的記憶體」上述所附的記憶體空間，以及已專門用於硬體元件 (例如無線電、影片等) 不受核心在裝置實作控制控制的記憶體空間外的記憶體空間。

Automotive 裝置實作：

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

Automotive 裝置實作：

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

Automotive 裝置實作：

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

2.5.2。多媒體

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

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

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

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

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

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

我們強烈建議實作 Automotive 裝置，以便支援下列影片解碼功能：

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

2.5.3.軟體

Automotive 裝置實作：

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

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

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

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

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

• [3.8.3/A-0-1] 如第三方應用程式要求，「必須」顯示使用 Notification.CarExtender API 的通知。

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

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

• [3.8.4/A-1-1] 「必須」使用短暫按下推送按鈕，做為指定互動啟動使用者選擇的輔助應用程式 (也就是實作 VoiceInteractionService 的應用程式)。

Automotive 裝置實作：

• [3.8.3.1/A-0-1] 必須正確轉譯 Notifications on Automotive OS SDK 說明文件中所述的資源。
• [3.8.3.1/A-0-2] 必須顯示 PLAY 和 MUTE，才能取代透過 Notification.Builder.addAction() 提供的通知動作
• [3.8.3.1/A] 應限制使用豐富的管理工作，例如個別通知管道的控制項。可依應用程式使用 UI 預設用途來減少控管。

Automotive 裝置實作：

• [3.14/A-0-1] 必須納入 UI 架構，以支援使用媒體 API 的第三方應用程式，如第 3.14 節所述。
• [3.14/A-0-2] 必須允許使用者在行車期間安全地與媒體應用程式互動。
• [3.14/A-0-3] 必須搭配 CAR_EXTRA_MEDIA_PACKAGE 額外項目支援 CAR_INTENT_ACTION_MEDIA_TEMPLATE 隱含意圖動作。
• [3.14/A-0-4] 必須提供選項來瀏覽媒體應用程式的偏好設定活動，但只有在車輛使用者體驗限制功能未發揮作用時，才需要啟用這項功能。
• [3.14/A-0-5] 必須顯示媒體應用程式設定的錯誤訊息，且必須支援選用的額外項目 ERROR_RESOLUTION_ACTION_LABEL 和 ERROR_RESOLUTION_ACTION_INTENT。
• [3.14/A-0-6] 如果應用程式支援搜尋功能，就必須支援應用程式內搜尋預設用途。
• [3.14/A-0-7] 顯示 MediaBrowser 階層時，必須遵守 CONTENT_STYLE_BROWSABLE_HINT 和 CONTENT_STYLE_PLAYABLE_HINT 定義。

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

• [3.14/A-1-1] 必須包括媒體服務，並使用 CAR_INTENT_ACTION_MEDIA_TEMPLATE 意圖開啟服務。

Automotive 裝置實作：

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

2.5.4.效能與功率

Automotive 裝置實作：

• [8.2/A-0-1] 必須針對每個程序的 UID，回報讀取和寫入非揮發性儲存空間的資料量，這樣才能透過 System API android.car.storagemonitoring.CarStorageMonitoringManager 取得開發人員的統計資料。Android 開放原始碼計畫透過 uid_sys_stats 核心模組符合相關規定。
• [8.3/A-1-3] 請至少進入車庫模式一次，車輛才會關機。
• [8.3/A-1-4] 至少必須進入車庫模式 15 分鐘，但下列情形除外：
  • 電量耗盡。
  • 未安排任何閒置工作。
  • 駕駛會結束車庫模式。
• [8.4/A-0-1] 「必須」依元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。
• [8.4/A-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/A-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/A] 無法將硬體元件的電力使用行為歸功於應用程式時，應註明硬體元件本身。
• [8.4/A-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供此電源用量。

2.5.5。安全性模型

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

• [9.5/A-1-1] 「不得」允許使用者進行互動或切換至無使用者介面系統使用者，但裝置佈建除外。
• [9.5/A-1-2] 請務必在 BOOT_COMPLETED前，轉換為次要使用者。
• [9.5/A-1-3] 即使裝置上的使用者數量已達上限，仍必須支援建立訪客使用者的功能。

Automotive 裝置實作：

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

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

如果 Automotive 裝置實作支援安全的螢幕鎖定功能，就會採取以下做法：

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

Automotive 裝置實作：

• [9.14/A-0-1] 必須控管來自 Android 架構車輛子系統的訊息，例如將允許的訊息類型和訊息來源加入許可清單。
• [9.14/A-0-2] 必須監控 Android 架構或第三方應用程式中的阻斷服務攻擊。這可避免惡意軟體因流量導致車輛網路受損，而可能導致車輛子系統故障。

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

Automotive 裝置實作：

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

2.6.平板電腦需求

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

• 通常用於握住雙手。
• 沒有貝殼式設計或可轉換設定。
• 在裝置上採用實體鍵盤時，「必須」透過標準連線方式連線。
• 具有可提供行動用的電源 (例如電池)。
• 螢幕尺寸介於 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] 可能實作 Android Open Accessory (AOA) API。

虛擬實境模式 (第 7.9.1 節)

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

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

2.6.2.安全性模型

金鑰和憑證 (第 9.11 節)

請參閱 [9.11] 一節。

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

• [9.5/T-1-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

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

• [9.5/T-2-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

3. 軟體

3.1. 代管 API 相容性

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

裝置實作方式：

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

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

• [C-0-3] 除非此相容性定義明確允許，否則「不得」省略任何代管 API、更改 API 介面或簽章、偏離記錄行為，或納入免人工管理 (No-ops)。

• [C-0-4] 即使 Android 提供的部分硬體功能遭到省略，也必須繼續以合理的方式呈現 API 並運作行為。如要瞭解這個情境的具體需求，請參閱第 7 節。

• [C-0-5] 不得允許第三方應用程式使用非 SDK 介面 (這類介面定義為 Java 語言套件中的方法和欄位，該介面位於 Android 開放原始碼計畫啟動類別路徑中，且不屬於公開 SDK 的一部分)。這包括用 @hide 註解裝飾，但使用 @SystemAPI 的 API (如 SDK 文件以及私人和套件私人類別成員所述)。

• [C-0-6] 每個非 SDK 介面都必須隨附於 Android 開放原始碼計畫中適當 API 級別分支版本的佈建清單和拒絕清單標記，並列在 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路徑中的個別非 SDK 介面上。

  但請注意下列事項：

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

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

3.1.1. Android 擴充功能

Android 支援擴充代管 API，同時保持相同的 API 級別版本。

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

3.1.2. Android 程式庫

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

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

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

3.2. 軟 API 相容性

除了第 3.1 節中的代管 API 外，Android 也包含重要的執行階段專用「soft」API，其形式包括意圖、權限，以及 Android 應用程式編譯時無法強制執行的類似功能。

3.2.1. 權限

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

3.2.2。版本參數

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

• [C-0-1] 為了讓各種裝置實作項目都提供一致且有意義的值，下表針對這些值的其他格式設有額外限制，指出裝置導入方式必須符合哪些規定。

參數	詳細資料
版本	目前執行 Android 系統的版本，採用人類可讀的格式。這個欄位「必須」包含 10 中定義的其中一個字串值。
SDK 版本	目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 10，這個欄位「必須」包含整數值 10_INT。
VERSION.SDK_INT	目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 10，這個欄位「必須」包含整數值 10_INT。
版本	裝置實作人員選擇的值，以人類可讀的格式指定目前執行 Android 系統的特定版本。使用者可用的不同版本「不得」重複使用這個值。這個欄位的常見用途是指出用於產生建構作業的版本號碼或原始碼控制變更 ID。這個欄位的值必須能當做可列印的 7 位元 ASCII 編碼，且符合規則運算式「^[^ :\/~]+$」。
遊戲板	裝置實作人員選擇的值，以人類可讀的格式識別裝置所使用的特定內部硬體。這個欄位的可能用途，是指出裝置供電的主機板特定修訂版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
品牌	這個值代表使用者所已知與裝置相關的品牌名稱。必須採用人類可讀的格式，且應代表裝置的製造商或銷售裝置的公司品牌。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
支援濫用	原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
支援 32_BIT_ABIS	原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
支援 64_BIT_ABIS	原生程式碼的第二個指令集 (CPU 類型 + ABI 慣例) 的名稱。請參閱第 3.3 節。原生 API 相容性。
CPU_ABI	原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
CPU_ABI2	原生程式碼的第二個指令集 (CPU 類型 + ABI 慣例) 的名稱。請參閱第 3.3 節。原生 API 相容性。
裝置	裝置實作者選擇的值，內含可識別硬體功能和工業設計裝置的開發名稱或代碼名稱。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。在產品的生命週期中，此裝置名稱「不得」變更。
指紋	專門用於識別此版本的字串。產品必須清晰可讀。請務必遵循以下範本： $(品牌)/$(PRODUCT)/ $(裝置)：$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL)：$(TYPE)/$(TAGS) 例如： acme/myproduct/ mydevice:10/LMYXX/3359:userdebug/test-keys 指紋「不得」包含空白字元。這個欄位的值必須能以 7 位元 ASCII 編碼。
硬體	硬體的名稱 (從核心指令列或 /proc)。產品必須清晰可讀。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
主機	用於識別建構建構所在主機的專屬字串，並且採用人類可讀的格式。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
印尼	裝置實作人員選擇用來參照特定版本的 ID，採用人類可讀的格式。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但值應足以讓使用者區分不同軟體版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
製造商	產品的原始設備製造商 (OEM) 商標名稱。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。在產品的生命週期中，這個欄位不得變更。
機型	由裝置實作者選擇的值，內含使用者已知的裝置名稱。這個名稱必須與用來行銷和向使用者銷售裝置的名稱相同。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。在產品的生命週期中，這個欄位不得變更。
產品	由裝置實作者選擇的值，內含特定產品 (SKU) 的開發名稱或代碼名稱，但該產品在同一個品牌中不得重複。必須是人類可讀的內容，但不一定能供使用者查看。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。在產品效期內，這個產品名稱「不得」變更。
序號	必須傳回「UNKNOWN」。
標記	由裝置實作工具選擇的標記清單 (以半形逗號分隔)，可進一步區分版本。這些標記「必須」能以 7 位元 ASCII 形式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+」，且「必須」包含與三種一般 Android 平台簽署設定相對應的值：release-keys、dev-keys 和 test-keys。
時間	代表建構發生時間的時間戳記的值。
類型	裝置實作者選擇的值，用於指定版本的執行階段設定。這個欄位「必須」設有其中一個值，對應三種一般 Android 執行階段設定：user、userdebug 或 eng。
使用者	產生版本的使用者 (或自動化使用者) 名稱或使用者 ID。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
安全快門	表示版本安全性修補程式等級的值。「必須」表示該版本沒有任何安全漏洞，可影響到指定 Android 公開安全性公告所述的任何問題。請採用 [YYYY-MM-DD] 的格式，與 Android 公開安全性公告或 Android 安全性補充公告中所列出的定義字串相符，例如「2015-11-01」。
BASE_OS	此值代表版本 (FINGERPRINT) 的 FINGERPRINT 參數，與此版本相同 (Android 公開安全性公告提供的修補程式除外)。它必須回報正確的值，如果這類版本不存在，請回報空字串 ("")。
新手上路	裝置實作者選擇的值，以人類可讀的格式，識別裝置中使用的特定內部系統啟動載入程式版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
getRadioVersion()	必須 (也就是或傳回) 由裝置實作者選擇的值，用來識別裝置中使用的特定內部無線電/數據機版本，且格式必須是人類可讀的格式。如果裝置沒有任何內部無線電/模組，就「必須」傳回 NULL。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。
getSerial()	「必須」提供 (發行或歸還) 一組硬體序號，該序號必須專屬於採用相同型號和 MANUFACTURER 的所有裝置。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。

3.2.3.意圖相容性

3.2.3.1。核心應用程式意圖

Android 意圖可讓應用程式元件要求其他 Android 元件的功能。Android 上游專案含有一系列被視為 Android 核心應用程式的應用程式，這些應用程式會實作多種意圖模式來執行常用動作。

• [C-0-1] 裝置實作項目「必須」利用意圖處理常式，預先載入一或多個 Android 開放原始碼計畫核心 Android 應用程式所定義的公開意圖篩選器模式。

  • 桌上時鐘
  • 瀏覽器
  • 日曆
  • 聯絡人
  • 圖片庫
  • 全域搜尋
  • 啟動器
  • Music (音樂)
  • 設定

3.2.3.2。意圖解決方案

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

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

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

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

Android 也提供第三方應用程式，能夠針對特定類型的網路 URI 意圖，宣告具有公信力的預設應用程式連結行為。如果應用程式的意圖篩選器模式定義了這類權威宣告，裝置實作方式會：

• [C-0-4] 「必須」嘗試執行 Digital Asset Links 規格中定義的驗證步驟，驗證任何意圖篩選器 (如上游 Android 開放原始碼專案中套件管理員實作)。
• [C-0-5] 「必須」在安裝應用程式時嘗試驗證意圖篩選器，並將所有成功驗證的 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。
• 如果成功驗證，但其他候選 URI 篩選器驗證失敗，可以將其特定 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。如果裝置採用這種做法，就「必須」在設定選單中提供使用者適當的個別 URI 模式覆寫值。
• 「設定」必須依下列方式，在「設定」中提供個別應用程式的應用程式連結控制項：
  • [C-0-6] 使用者「必須」能全面覆寫應用程式的預設應用程式連結行為：一律開啟、一律詢問或不開啟，而且「必須」對所有候選 URI 意圖篩選器一視同仁。
  • [C-0-7] 使用者「必須」可以查看候選 URI 意圖篩選器清單。
  • 裝置實作「可能」可讓使用者依個別意圖篩選器，覆寫已成功驗證的特定候選 URI 意圖篩選器。
  • [C-0-8] 如果裝置實作可讓某些候選 URI 意圖篩選器成功驗證，某些候選 URI 意圖篩選器可能通過驗證，但裝置實作「必須」能讓使用者查看及覆寫特定候選 URI 意圖篩選器。

3.2.3.3.意圖命名空間

• [C-0-1] 裝置實作項目不得含有任何採用 Android 中 ACTION、CATEGORY 或其他金鑰字串的新意圖或廣播意圖模式的 Android 元件。或 com.android. 命名空間。
• [C-0-2] 裝置實作者「不得」含有任何採用 ACTION、CATEGORY 或其他機構套件空間中 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] 必須遵循 android.settings.HOME_SETTINGS 意圖，在主畫面中顯示預設的應用程式設定選單。

如果裝置導入作業回報 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。Android 開放原始碼計畫實作項目必須包含「通話帳戶選項」「通話」選單設定選單。

• [C-2-4] 凡是擁有「android.app.role.CALL_REDIRECTION」角色的應用程式，都必須允許 android.telecom.CallRedirectionService。

• [C-2-5] 必須讓使用者負擔能力，才能選擇具備 android.app.role.CALL_REDIRECTION 角色的應用程式。

如果裝置導入作業回報 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] 保證 API 相容性與在主要顯示器上執行的活動類似。
• [C-1-3] 在新活動啟動時，必須透過 ActivityOptions.setLaunchDisplayId() API 指定目標顯示畫面，使新活動顯示在啟動活動的螢幕上。
• [C-1-4] 移除具有 Display.FLAG_PRIVATE 標記的螢幕時，請務必刪除所有活動。
• [C-1-5] 使用 Activity#setShowWhenLocked() API 選擇讓裝置在螢幕鎖定的頂端顯示內容時，「必須」安全地隱藏所有螢幕上的內容。
• 應具備與該螢幕對應的 android.content.res.Configuration，以便在次要螢幕上啟動活動時能正確顯示、運作並維持相容性。

如果裝置實作項目允許在次要顯示器上啟動一般的 Android 活動，而次要顯示器上含有 android.view.Display.FLAG_PRIVATE 標記：

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

3.3.原生 API 相容性

原生程式碼相容性不高。因此，裝置實作者有：

• [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 的逗號分隔清單，依順序由高到低排序。

• [C-0-6] 請務必透過上述參數，回報下列 ABI 清單中的部分 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 功能使用，則支援 MIDI)
  • libandroid.so (原生 Android 活動支援)
  • libc (C 程式庫)
  • libcamera2ndk.so
  • libdl (動態連結器)
  • libEGL.so (原生 OpenGL 介面管理)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • Libicuuc.so
  • libjnigraphics.so
  • liblog (Android 記錄)
  • libmediandk.so (支援原生媒體 API)
  • libm (數學資料庫)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (OpenMAX AL 1.0.1 支援)
  • libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
  • libRS.so
  • libstdc++ (最低支援 C++)
  • libvulkan.so (Vulkan)
  • libz (Zlib 壓縮)
  • JNI 介面

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

• [C-0-9] 必須列出 /vendor/etc/public.libraries.txt 中直接向第三方應用程式公開的其他非 Android 開放原始碼計畫程式庫。
• [C-0-10] 請勿向指定 API 級別 24 以上級別的第三方應用程式，向 Android 開放原始碼計畫中實作及提供的其他原生程式庫 (做為系統程式庫) 揭露。
• [C-0-11] 「必須」透過 libGLESv3.so 程式庫匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android Extension Pack 函式符號。請注意，雖然所有符號都必須完整呈現，但第 7.1.4.1 節將進一步說明預期各項對應函式完整實作的相關規定。
• [C-0-12] 「必須」透過 libvulkan.so 程式庫匯出核心 Vulkan 1.0 函式符號，以及 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 擴充功能的函式符號。請注意，雖然所有符號都必須完整呈現，但第 7.1.4.2 節將進一步說明預期各項對應函式完整實作的相關規定。
• 應使用上游 Android 開放原始碼計畫提供的原始碼和標頭檔案建立

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

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

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

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

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

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

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

• [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] 必須回報android.software.webview。
• [C-1-2] 「必須」在 Android 10 分支版本上，使用取自上游 Android 開放原始碼專案的 Chromium 專案版本，實作 android.webkit.WebView API。

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

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

  • $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE 的值相同。
  • $(MODEL) 字串「可能」為空白，但如果並非空白，則值必須與 android.os.Build.MODEL 相同。
  • 「Build/$(BUILD)」如果找到 $(BUILD) 字串，可以省略，但必須與 android.os.Build.ID 的值相同。
  • $(CHROMIUM_VER) 字串的值「必須」是上游 Android 開放原始碼專案中的 Chromium 版本。
  • 裝置導入方式可以在使用者代理程式字串中省略行動裝置。

• WebView 元件「必須」盡可能支援最多的 HTML5 功能，如果其支援的功能也必須符合 HTML5 規格。

• [C-1-4] 「必須」與會例項化 WebView 的應用程式不同，轉譯提供的內容或遠端網址內容。具體來說，獨立的轉譯器程序「必須」擁有較低權限、以獨立的使用者 ID 執行、無法存取應用程式的資料目錄、沒有直接網路存取權，而且只能透過 Binder 存取最低需求的系統服務。WebView 的 Android 開放原始碼計畫實作符合這項規定。

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

3.4.2。瀏覽器相容性

如果裝置實作項目包含適用於一般網路瀏覽的獨立瀏覽器應用程式，就會：

• [C-1-1] 「必須」支援下列各個與 HTML5 相關聯的 API：
  • 應用程式快取/離線作業
  • <影片>標記
  • 地理位置
• [C-1-2] 必須支援 HTML5/W3C webstorage API，且必須支援 HTML5/W3C IndexedDB API。請注意，隨著網頁開發標準機構逐漸改用 IndexedDB，而非 webstorage，未來 Android 版本應將 IndexedDB 成為必要的元件。
• 可以在獨立的瀏覽器應用程式中提供自訂的使用者代理程式字串。
• 無論是以上游 WebKit 瀏覽器應用程式還是第三方替代網站，都應盡可能在獨立的瀏覽器應用程式中導入 HTML5 的支援。

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

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

3.5.API 行為相容性

裝置實作方式：

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

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

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

上方清單僅列舉部分例子，並未包含所有可能情況。Compatibility Test Suite (CTS) 會測試平台中的大量行為相容性，但並非全部。實作者應負責確保與 Android 開放原始碼計畫的行為相容性。因此，裝置實作者應盡可能使用 Android 開放原始碼計畫提供的原始碼，而非重新導入系統的重要部分。

3.5.1。背景限制

如果裝置實作項目導入 Android 開放原始碼計畫中包含的應用程式限制，或延長應用程式限制，就會造成以下情況：

• [C-1-1] 必須為使用者提供預設用途，讓使用者查看受限制的應用程式清單。
• [C-1-2] 必須為使用者提供自由選項，才能為個別應用程式開啟 / 關閉限制。
• [C-1-3] 不得在沒有出現不良系統健康行為的證據的情況下自動套用限制，但「可能」在偵測到不良系統健康行為 (例如喚醒鎖定、長時間執行的服務和其他條件) 時，對應用程式套用限制。這些標準可能取決於裝置實作者，但必須與應用程式對系統健康狀態的影響相關。與系統健全性無關的其他條件 (例如應用程式在市場上的熱門度偏低)，「不得」做為條件使用。
• [C-1-4] 當使用者手動關閉應用程式限制時，應用程式「不得」自動套用應用程式限制，並建議使用者套用應用程式限制。
• [C-1-5] 如果應用程式已自動套用應用程式限制，請務必告知使用者。
• [C-1-6] 當受限制的應用程式呼叫這個 API 時，必須針對 ActivityManager.isBackgroundRestricted() 傳回 true。
• [C-1-7] 「不得」限制使用者明確使用的頂層前景應用程式。
• [C-1-8] 當使用者明確開始使用受限的應用程式時，如果該應用程式成為頂層前景應用程式，就必須暫停限制。

3.6.API 命名空間

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

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

也就是說，他們會：

• [C-0-1] 不得透過變更任何方法或類別簽章，或移除類別或類別欄位，在 Android 平台上修改公開的 API。
• [C-0-2] 「不得」在上述命名空間的 API 中加入任何公開的元素 (例如類別、介面、欄位或方法)，或是測試或系統 API。「公開公開的元素」是指任何未以「@hide」標記裝飾的結構，就像上游 Android 原始碼使用一樣。

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

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

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

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

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

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

3.7.執行階段相容性

裝置實作方式：

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

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

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

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

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

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

3.8.使用者介面相容性

3.8.1。啟動器 (主畫面)

Android 提供啟動器應用程式 (主畫面)，以及支援第三方應用程式，可取代裝置啟動器 (主畫面)。

如果裝置的實作方式允許第三方應用程式取代裝置主畫面，請執行以下操作：

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

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

• [C-2-1] 必須回報 ShortcutManager.isRequestPinShortcutSupported() 的true。
• [C-2-2] 「必須」在使用者負擔範圍內，再透過 ShortcutManager.requestPinShortcut() API 方法新增應用程式要求的捷徑。
• [C-2-3] 必須支援固定捷徑，以及動態和靜態捷徑，詳情請參閱「應用程式捷徑」頁面。

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

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

如果裝置實作項目實作預設啟動器，讓使用者可透過 ShortcutManager API 快速存取第三方應用程式提供的其他捷徑，必須執行以下動作：

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

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

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

3.8.2。小工具

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

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

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

如果裝置實作支援第三方應用程式小工具和應用程式內捷徑固定功能，您就能執行下列操作：

• [C-2-1] 必須回報 AppWidgetManager.html.isRequestPinAppWidgetSupported() 的true。
• [C-2-2] 「必須」在使用者負擔範圍內，再透過 AppWidgetManager.requestPinAppWidget() API 方法新增應用程式要求的捷徑。

3.8.3.通知

Android 提供 Notification 和 NotificationManager API，可讓第三方應用程式開發人員通知使用者重要事件並吸引使用者注意力。

3.8.3.1。通知呈現方式

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

• [C-1-1] 必須支援使用硬體功能的通知，如 SDK 說明文件所述，以及在裝置實作硬體上盡可能支援通知。舉例來說，如果裝置實作方式包含震動功能，「必須」正確實作震動 API。如果裝置實作方式缺少硬體，「必須」將對應的 API 實作為免人工管理。如要進一步瞭解這項行為，請參閱第 7 節。
• [C-1-2] 「必須」正確轉譯 API 或狀態/系統列圖示樣式指南中提供的所有資源 (圖示、動畫檔案等)，但這些資源可以為通知提供替代的使用者體驗，而不是根據 Android 開放原始碼實作方法提供的內容。
• [C-1-3] 必須遵循並妥善實作 API 所述的行為，才能更新、移除及群組通知。
• [C-1-4] 必須提供 SDK 中記錄的 NotificationChannel API 完整行為。
• [C-1-5] 「必須」根據每個管道和應用程式套件層級，為使用者提供封鎖和修改特定第三方應用程式的通知。
• [C-1-6] 也必須讓使用者負擔能顯示已刪除的通知管道。
• [C-1-7] 「必須」正確轉譯透過 Notification.MessagingStyle 提供的所有資源 (圖片、貼圖、圖示等)，使用者不需任何額外互動。舉例來說，在透過 setGroupConversation 設定的群組對話中，「必須」顯示所有資源，包括透過 android.app.Person 提供的圖示。
• [C-SR] 強烈建議「強烈建議」在使用者多次關閉該通知後，自動依每個管道和應用程式套件層級封鎖特定第三方應用程式的通知。
• 應支援複合式通知。
• 應以抬頭通知的形式呈現優先順序較高的通知。
• 應讓使用者有足夠的需求來延後通知。
• 「盡量」只管理第三方應用程式何時能通知使用者特定事件的顯示設定和時間，以減少駕駛人分心等安全問題。

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

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

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

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

3.8.3.2。通知接聽器服務

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

如果裝置導入方式回報功能旗標 android.hardware.ram.normal，系統會採取以下做法：

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

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

• [C-2-1] 必須使用標準 API (例如 NotificationListenerService.getSnoozedNotifications()) 正確反映延後通知的狀態。
• [C-2-2] 「必須」授予使用者權限，讓他們能從每個已安裝的第三方應用程式中延後通知 (除非應用程式來源是持續/前景服務)。

3.8.3.3。DND (請勿打擾)

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

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

3.8.4。搜尋

Android 提供的 API 可讓開發人員將搜尋功能加入應用程式，並將應用程式資料公開到全域系統搜尋。一般來說，這項功能是由整個系統通用的使用者介面所組成，可讓使用者輸入查詢、在使用者輸入內容時顯示建議，以及顯示結果。開發人員可利用 Android API 重複使用這個介面，以在自家應用程式中提供搜尋功能，並讓開發人員將結果提供給常見的全域搜尋使用者介面。

• Android 裝置實作「必須」提供全域搜尋，以及整個系統通用的搜尋使用者介面，可根據使用者輸入內容提供即時建議。

如果裝置實作項目實作全域搜尋介面，就會發生以下情形：

• [C-1-1] 「必須」實作 API，讓第三方應用程式在全域搜尋模式中執行時，在搜尋框中添加建議。

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

• 預設行為「必須」顯示網頁搜尋引擎的結果和建議。

Android 也包含 Assist API，可讓應用程式選擇與裝置助理分享多少目前背景資訊的資訊。

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

• [C-2-1] 透過下列任一方式分享背景資訊時，必須向使用者明確指出：
  • 每次輔助應用程式存取內容時，在螢幕邊緣周圍顯示白色燈號，且指示燈符合或超過 Android 開放原始碼計畫實作作業的時間長度和亮度。
  • 就預先安裝的小幫手應用程式而言，從預設的語音輸入和 Google 助理應用程式設定選單只提供不到 2 個導覽選項，且只在使用者透過啟動字詞或輔助操作鍵輸入明確叫用輔助應用程式時，才提供背景資訊。
• [C-2-2] 指定互動用來啟動輔助應用程式 (如第 7.2.3 節所述) 「必須」啟動使用者選擇的輔助應用程式，也就是實作 VoiceInteractionService 或處理 ACTION_ASSIST 意圖的活動。

3.8.5。快訊與浮動式訊息

應用程式可以使用 Toast API，向使用者顯示在短時間內消失的簡短非強制化字串，並使用 TYPE_APPLICATION_OVERLAY 視窗類型 API，將快訊視窗以重疊方式顯示在其他應用程式上方。

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

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

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

3.8.6。主題

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

Android 內含「Holo」和「Material」是一組已定義的樣式，可讓應用程式開發人員在希望符合 Android SDK 定義的 Holo 主題外觀和風格時使用。

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

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

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 情境的動態桌布可能會與其他使用 OpenGL 內容的應用程式發生衝突。

• 如上所述，可穩定執行動態桌布的裝置實作應導入動態桌布。

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

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

3.8.8。活動切換

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

如第 7.2.3 節所述，裝置實作項目包含近期函式瀏覽鍵，並會變更介面。

如果裝置實作項目包含最近使用函式瀏覽鍵 (如第 7.2.3 節所述) 的變更，就會發生以下情形：

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

3.8.9。輸入管理

Android 支援輸入管理功能，並支援第三方輸入法編輯器。

如果使用者的實作裝置允許使用者在裝置上使用第三方輸入法，就會：

• [C-1-1] 必須宣告平台功能 android.software.input_methods，並支援 Android SDK 說明文件中定義的 IME API。
• [C-1-2] 「必須」提供讓使用者存取的機制，以便新增及設定第三方輸入法以回應 android.settings.INPUT_METHOD_SETTINGS 意圖。

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

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

3.8.10。螢幕鎖定媒體控制項

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

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

Android 支援先前稱為 Dreams 的互動式螢幕保護程式。螢幕保護程式可讓使用者在已連接電源的裝置或座架在桌面座架上時，與應用程式互動。Android Watch 裝置「可」實作螢幕保護程式，但其他類型的裝置「應」提供螢幕保護程式支援，並提供設定選項，方便使用者根據 android.settings.DREAM_SETTINGS 意圖來設定螢幕保護程式。

3.8.12。地區

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

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

3.8.13。萬國碼 (Unicode) 和字型

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

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

• [C-1-1] 必須能夠以色彩字符轉譯這些表情符號字元。
• [C-1-2] 必須支援下列項目：
  • Roboto 2 字型的粗細如下：sans-Serif-thin、Sans-Serif-light、Sans-Serif-medium、Sans-Serif-black、Sans-Serif-condensed、Sans-Serif-condensed-light 適用於裝置支援的語言。
  • 完整 Unicode 7.0 涵蓋拉丁、希臘和斯拉夫文，包括拉丁文 A、B、C 和 D 範圍，以及 Unicode 7.0 貨幣符號區塊中的所有字符。
• 應支援 Unicode 技術報告 #51 中指定的膚色和多樣家庭表情符號。

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

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

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] 必須遵循此 SDK 中所述，在 AndroidManifest.xml 檔案中為應用程式設定的 android:resizeableActivity。
• [C-1-3] 如果螢幕高度小於 440 dp，且螢幕寬度小於 440 dp，就「不得」提供分割畫面或任意形式模式。
• [C-1-4] 在子母畫面以外的多視窗模式下，活動「不得」調整為小於 220 dp 的大小。
• 螢幕尺寸為 xlarge 的裝置實作應支援任意形式模式。

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

• [C-2-1] 必須預先載入可調整大小的啟動器做為預設值。
• [C-2-2] 針對分割畫面多視窗模式，「必須」裁剪固定活動，但如果啟動器應用程式是焦點視窗，則必須顯示部分內容。
• [C-2-3] 必須遵循第三方啟動器應用程式宣告的 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值，在顯示已插入活動的部分內容時，請勿覆寫這些值。

如果裝置實作支援多視窗模式和子母畫面多視窗模式，就會執行以下動作：

• [C-3-1] 當應用程式處於以下狀態時，「必須」在子母畫面多視窗模式下啟動活動：* 指定 API 級別 26 以上，並宣告 android:supportsPictureInPicture * 指定 API 級別 25 以下並宣告 android:resizeableActivity 和 android:supportsPictureInPicture。
• [C-3-2] 「必須」按照目前子母畫面透過 setActions() API，在自家 SystemUI 中顯示動作。
• [C-3-3] 必須依照子母畫面模式透過 setAspectRatio() API 指定的規定，支援大於或等於 1:2.39 且小於或等於 2.39:1 的顯示比例。
• [C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如未實作子母畫面模式，關鍵就「必須」適用於前景活動。
• [C-3-5] 「必須」提供使用者負擔，禁止應用程式在子母畫面模式下顯示。Android 開放原始碼計畫實作項目通知欄內提供控制項，以符合這項規定。
• [C-3-6] 當 Configuration.uiMode 設為 UI_MODE_TYPE_TELEVISION 時，子 IP 視窗的寬度和高度下限一律為 108 dp，而子母畫面視窗的最小寬度 240 dp，高度則為 135 dp。

3.8.15。螢幕去背

如同 SDK 文件所述，Android 支援螢幕凹口。DisplayCutout API 定義在螢幕邊緣，無法用來顯示內容的區域。

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

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

3.9.裝置管理

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

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

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

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

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

• [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為裝置擁有者應用程式，如下所述：
  • 如果裝置實作尚未設定使用者資料，系統會：
    • [C-1-3] 必須回報 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 的true。
    • [C-1-4] 為回應意圖動作 android.app.action.PROVISION_MANAGED_DEVICE，請務必註冊 DPC 應用程式做為裝置擁有者應用程式。
    • [C-1-5] 如果裝置透過功能旗標 android.hardware.nfc 宣告近距離無線通訊 (NFC) 支援，且收到包含 MIME 類型 MIME_TYPE_PROVISIONING_NFC 記錄的 NFC 訊息，就「必須」將 DPC 應用程式註冊為「裝置擁有者」應用程式。
  • 如果裝置實作方式包含使用者資料，就會執行以下動作：
    • [C-1-6] 必須回報DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)的false。
    • [C-1-7] 不得再註冊任何 DPC 應用程式，做為裝置擁有者應用程式。
• [C-1-2] 必須要求在佈建過程中進行一些確認動作，才能將應用程式設為裝置擁有者。同意聲明可以透過使用者操作，或在佈建過程中透過某些程式輔助方式取得同意聲明，但「不得」透過硬式編碼或禁止使用其他裝置擁有者應用程式。

如果裝置實作方式宣告 android.software.device_admin，但也包含專屬的裝置擁有者管理解決方案，並提供機制，可宣傳他們解決方案中設定「相當於裝置擁有者」的應用程式標準「裝置擁有者」標準 Android DevicePolicyManager API 辨識，這些 API 會：

• [C-2-1] 必須設有專門程序，用於驗證目前宣傳的應用程式屬於合法的企業裝置管理解決方案，而且專屬解決方案中已設定該解決方案，具有與「裝置擁有者」同等的權限。
• [C-2-2] 在註冊 DPC 應用程式為「裝置擁有者」之前，必須顯示相同的 Android 開放原始碼計畫裝置擁有者同意聲明揭露聲明，與 android.app.action.PROVISION_MANAGED_DEVICE 發起的流程相同。
• 以「裝置擁有者」註冊 DPC 應用程式之前，裝置上可能已有使用者資料。

3.9.1.2 受管理設定檔佈建

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

• [C-1-1] 必須實作允許裝置政策控制器 (DPC) 應用程式的 API，成為新受管理設定檔的擁有者。

• [C-1-2] 受管理設定檔佈建程序 (由 android.app.action.PROVISION_MANAGED_PROFILE 啟動的流程) 使用者「必須」符合 Android 開放原始碼計畫實作項目。

• [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] 必須使用圖示徽章 (類似 Android 開放原始碼計畫上游工作徽章) 代表受管理的應用程式、小工具，以及其他標記的 UI 元素，例如「近期與」通知。
• [C-1-4] 必須顯示通知圖示 (類似 Android 開放原始碼計畫上游工作徽章)，表示使用者位於受管理的設定檔應用程式中。
• [C-1-5] 必須顯示浮動式訊息，指出裝置處於喚醒狀態且裝置喚醒時 (ACTION_USER_PRESENT)，且前景應用程式位於受管理的設定檔。
• [C-1-6] 如有受管理的設定檔，「必須」在意圖「選擇工具」中顯示視覺預設用途允許使用者將意圖從受管理的設定檔轉送給主要使用者；如果已經啟用 Device Policy Controller，則可反向轉送意圖的使用者。
• [C-1-7] 如果已有受管理的設定檔，「必須」針對主要使用者和受管理的設定檔提供下列使用者權限：
  • 將主要使用者和受管理設定檔的電池、位置、行動數據和儲存空間用量分開計算。
  • 管理主要使用者或受管理設定檔中安裝的 VPN 應用程式。
  • 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
  • 獨立管理主要使用者或受管理設定檔中的帳戶。
• [C-1-8]「必須」確保預先安裝的撥號程式、聯絡人和訊息應用程式可以在受管理的設定檔 (如果有的話) 中搜尋及查詢來電者資訊 (如有)。
• [C-1-9] 即使受管理的設定檔並未計入主要使用者，仍必須符合所有適用於多位使用者的裝置的安全性規定 (請參閱第 9.5 節)。
• [C-1-10] 必須能夠指定獨立的螢幕鎖定畫面，並符合下列規定，才能授予受管理設定檔所執行應用程式的存取權。
  • 裝置實作方式「必須」遵循 DevicePolicyManager.ACTION_SET_NEW_PASSWORD 意圖，並顯示用來為受管理的設定檔設定獨立螢幕鎖定憑證的介面。
  • 受管理設定檔的螢幕鎖定憑證「必須」採用與上層設定檔相同的憑證儲存空間和管理機制 (如 Android 開放原始碼計畫網站所述)。
  • DPC 密碼政策「必須」僅適用於受管理設定檔的螢幕鎖定憑證，除非 getParentProfileInstance 傳回的 DevicePolicyManager 例項進行呼叫。
• 如果受管理設定檔的聯絡人顯示在預先安裝的通話記錄、通話使用者介面、進行中和未接來電通知、聯絡人和訊息應用程式上，就必須標有代表受管理設定檔應用程式的徽章。

3.9.3 受管理使用者支援

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

• [C-1-1] isLogoutEnabled 傳回 true 時，「必須」為使用者提供登出權，讓使用者自行登出目前使用者，然後在多使用者工作階段中切換回主要使用者。「必須」可以在未解鎖裝置的情況下，透過螢幕鎖定畫面存取使用者預設用途。

3.10.無障礙功能

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

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

• [C-1-1] 必須按照 Accessibility API SDK 說明文件中的指示，實作 Android 無障礙架構。
• [C-1-2] 必須產生無障礙事件，並依 SDK 中記錄，向所有已註冊的 AccessibilityService 實作提供適當的 AccessibilityEvent。
• [C-1-3] 必須遵循 android.settings.ACCESSIBILITY_SETTINGS 意圖，才能提供使用者可存取的機制，連同預先安裝的無障礙服務一起啟用及停用。
• [C-1-4] 請在系統的導覽列中加入按鈕，讓使用者在已啟用的無障礙服務宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 時，能夠控制無障礙服務。請注意，如果是沒有系統導覽列的裝置實作，則不適用這項規定，但裝置實作應提供使用者負擔來控管這些無障礙服務。

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

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

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 提供用於建立控制 Android Television 裝置的輸入模組的標準 API。

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

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

3.13.快速設定

Android 提供的「快速設定」UI 元件可讓您快速存取常用或迫切需要的動作。

如果裝置實作項目內含快速設定 UI 元件，就會：

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

3.14。媒體使用者介面

如果裝置的實作方式包含無法透過 MediaBrowser 或 MediaSession 與第三方應用程式互動、未啟用語音功能的應用程式 (即「應用程式」)，應用程式：

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

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

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

• [C-1-5] 建議輕觸兩下 KEYCODE_HEADSETHOOK 或 KEYCODE_MEDIA_PLAY_PAUSE，視為 MediaSession.Callback#onMediaButtonEvent 的 KEYCODE_MEDIA_NEXT。

3.15.免安裝應用程式

裝置實作方式必須符合下列規定：

• [C-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] 除非免安裝應用程式明確連線至已安裝的應用程式，否則已安裝的應用程式「不得」在裝置上查看免安裝應用程式的詳細資料。
• 裝置實作「必須」提供下列使用者權限，以便與免安裝應用程式互動。Android 開放原始碼計畫符合預設系統 UI、設定和啟動器的規定。裝置實作方式：
  • [C-0-5] 「必須」為使用者提供權限，才能查看及刪除個別應用程式套件本機快取的免安裝應用程式。
  • [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] 必須確保 android.companion 套件中的 API 已完全實作。
• [C-1-3] 必須為使用者提供預設空間，讓使用者選取/確認隨附裝置運作正常，並可正常使用。

3.17. 重量級應用程式

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

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

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

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

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

裝置實作方式：

• [C-0-1] 必須能夠安裝及執行 Android 官方 Android SDK 中「aapt」工具所產生的 Android「.apk」檔案。
• 由於上述規定可能具有挑戰性，因此建議裝置實作採用 Android 開放原始碼計畫參考資料實作項目的套件管理系統。

裝置實作方式：

• [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 意圖的系統套件驗證器應用程式，以及處理 ACTION_MANAGE_STORAGE 意圖的儲存空間管理工具應用程式。

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

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

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

• 「應該」應為使用者提供授權，讓他們為每個應用程式授予/撤銷不明來源安裝應用程式的權限，但如果裝置的實作不允許使用者選擇此選項，則「可以」選擇以免人工管理的方式導入 RESULT_CANCELED，為 startActivityForResult() 傳回 RESULT_CANCELED。但即使如此，他們也應該向使用者說明沒有這類選擇的原因。

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

• 「應」在警告對話方塊中提供讓使用者彈性選擇解除安裝或啟動應用程式的選項。

5. 多媒體相容性

裝置實作方式：

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

裝置實作方式：

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

下方所列的所有轉碼器，都是以 Android 開放原始碼計畫中偏好的 Android 實作方式提供的軟體實作。

請注意，Google 或 Open Handset Alliance 皆不代表這些轉碼器不在第三方專利中。有意將此原始碼用於硬體或軟體產品的使用者，建議在實作此程式碼 (包括開放原始碼軟體或共享軟體) 的情況下，可能需要相關專利持有人的專利授權。

5.1. 媒體轉碼器

5.1.1.音訊編碼

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

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

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

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

• [C-3-1] 使用 android.media.MediaCodec API 的 PCM 16 位元原生位元組順序音訊影格。

5.1.2.音訊解碼

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

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

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

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

• [C-2-1] 必須執行解碼而無需下移 (例如，5.0 AAC 串流必須解碼為五個 PCM 管道，5.1 AAC 串流必須解碼為六個 PCM 管道)。
• [C-2-2] 動態範圍中繼資料必須依照「動態範圍控制 (DRC)」的定義，並使用 android.media.MediaFormat DRC 金鑰設定音訊解碼器的動態範圍相關行為。AAC DRC 金鑰是在 API 21 中導入，為：KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_ENCODED_TARGET_LEVEL。
• [SR] 強烈建議所有 AAC 音訊解碼器都符合上述要求 C-2-1 和 C-2-2 的規定。

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

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

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

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

如果系統支援 ISO/IEC 23003-4，且在已解碼的位元中同時含有 ISO/IEC 23003-4 和 ISO/IEC 14496-3 中繼資料，那麼：

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

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

• [C-6-1] 使用 android.media.MediaCodec API 的 PCM 16 位元原生位元組順序音訊影格。

5.1.3.音訊轉碼器詳細資料

格式/轉碼器	詳細資料	支援的檔案類型/容器格式
MPEG-4 AAC 設定檔 (AAC LC)	支援採用標準取樣率介於 8 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a) ADTS 原始 AAC (不支援 .aac、ADIF) MPEG-TS (.ts，不可搜尋，僅限解碼) Matroska (.mkv，僅限解碼)
MPEG-4 HE AAC 設定檔 (AAC+)	支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a)
MPEG-4 HE AACv2 設定檔 (加強型 AAC+)	支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a)
AAC ELD (強化低延遲 AAC)	支援標準取樣率介於 16 至 48 kHz 的單聲道/立體聲內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a)
美國運通	支援標準取樣率介於 7.35 至 48 kHz 的單聲道/立體聲內容。	MPEG-4 (.mp4、.m4a)
美國醫力軍	4.75 到 12.2 kbps 取樣時 @ 8 kHz	3GPP (.3gp)
AMR-WB	9 速率從每秒 6.60 kbit 到 23.85 kbit/s 取樣 @ 16 kHz，定義請見 AMR-WB, Adaptive Multi-Rate - 寬頻語音轉碼器	3GPP (.3gp)
FLAC	編碼器和解碼器都需支援至少單聲道和立體聲模式。必須支援高達 192 kHz 的取樣率；必須支援 16 位元和 24 位元解析度。FLAC 的 24 位元音訊資料處理「必須」支援浮點音訊設定。	FLAC (.flac) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) Matroska (.mkv，僅限解碼)
MP3	單聲道/立體聲 8 至 320 Kbps 常數 (CBR) 或可變位元率 (VBR)	MP3 (.mp3) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) Matroska (.mkv，僅限解碼)
MIDI	MIDI 類型 0 和 1。DLS 第 1 版和第 2 版。XMF 和 Mobile XMF。支援鈴聲格式 RTTTL/RTX、OTA 和 iMelody	輸入 0 和 1 (.mid、.xmf、.mxmf) RTTTL/RTX (.rtttl、.rtx) OTA (.ota) iMelody (.imy)
沃比斯		Ogg (.ogg) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) 馬特羅斯卡文 (.mkv) Webm (.webm)
PCM/WAVE	PCM 轉碼器「必須」支援 16 位元線性 PCM 和 16 位元浮點值。WAVE 擷取器「必須」支援 16 位元、24 位元、32 位元的線性 PCM 和 32 位元浮點值 (頻率取決於硬體限制)。取樣率必須為 8 kHz 至 192 kHz 的支援範圍。	WAVE (.wav)
Opus		Ogg (.ogg) MPEG-4 (僅限 .mp4、.m4a，僅限解碼) 馬特羅斯卡文 (.mkv) Webm (.webm)

5.1.4。圖片編碼

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

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

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

如果裝置實作方式支援透過 android.media.MediaCodec 為媒體類型 MIMETYPE_IMAGE_ANDROID_HEIC 使用 HEIC 編碼，即可：

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

5.1.5。圖片解碼

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

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

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

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

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

5.1.6.圖片轉碼器詳細資料

格式/轉碼器	詳細資料	支援的檔案類型/容器格式
JPEG	基準 + 漸進式	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
未加工		ARW (.arw)、CR2 (.cr2)、DNG (.dng)、NEF (.nef)、NRW (.nrw)、ORF (.orf)、PEF (.pef)、RAF (.raf)、RW2 (.rw2)、SRW (.srw)
HEIF	圖片、圖片集合、圖片序列	HEIF (.heif)、HEIC (.heic)

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

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

• [SR] 強烈建議在輸入 Surface 模式下支援 RGB888 色彩格式。

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

5.1.7.視訊轉碼器

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

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

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

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

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

• [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] 重新整理時，必須在 10 到 60 個影格的範圍內，並在設定的重新整理週期的 20% 內準確運作。

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

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

5.1.8。影片轉碼器清單

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

5.1.9。媒體轉碼器安全性

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

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

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

• [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] 強烈建議 OMX 軟體轉碼器在轉碼器程序中執行，不能存取記憶體對應程式以外的硬體驅動程式。

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

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

5.1.10。媒體轉碼器字元化

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

• [C-1-1] 「必須」透過 MediaCodecInfo API 傳回媒體轉碼器字元化的正確值。

請特別注意以下幾點：

• [C-1-2] 名稱開頭為「OMX」的轉碼器。必須使用 OMX API，且名稱符合 OMX IL 命名規範。
• [C-1-3] 名稱開頭為「c2」的轉碼器。必須使用 Codec 2.0 API，且名稱符合 Android 的 Codec 2.0 命名規範。
• [C-1-4] 名稱開頭為「OMX.google」的轉碼器。或「c2.android」。「不得」稱為供應商或硬體加速。
• [C-1-5] 在轉碼器程序 (供應商或系統) 中執行的轉碼器若具備記憶體配置器和對應器以外的硬體驅動程式，則「不得」僅歸類為軟體。
• [C-1-6] 轉碼器不存在於 Android 開放原始碼計畫中，或是不是以該專案的原始碼為依據。「必須」歸類為供應商。
• [C-1-7] 必須使用硬體加速的轉碼器如硬體加速特性所定義。
• [C-1-8] 轉碼器名稱不得誤導使用者。例如名為「解碼器」的轉碼器必須能夠支援解碼功能，以及名為「編碼器」的檔案必須支援編碼。名稱包含媒體格式的轉碼器「必須」支援這些格式。

如果裝置導入方式支援視訊轉碼器：

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

	SD 標準畫質 (低品質)	SD 標準畫質 (高品質)	HD 高畫質 (720p)	HD 高畫質 (1080p)	UHD 超高畫質
影片解析度	176 x 144 像素 (H263、MPEG2、MPEG4) 352 x 288 px (MPEG4 編碼器、H263、MPEG2) 320 x 180 像素 (VP8，VP8) 320 x 240 像素 (其他)	704 x 576 像素 (H263) 640 x 360 像素 (VP8，VP9) 640 x 480 px (MPEG4 編碼器) 720 x 480 像素 (其他)	1408 x 1152 像素 (H263) 1280 x 720 像素 (其他)	1920 x 1080 px (不包括 MPEG4)	3840 x 2160 px (HEVC，VP9)

• [C-2-2] 使用硬體加速技術的視訊轉碼器「必須」發布效能點資訊。這些樣本必須列出所有支援的標準效能點 (列於 PerformancePoint API 中)，除非這些面向在其他支援的標準效能點涵蓋範圍內。
• 此外，如果除了上述任一項標準之外，還能提升影片成效，而你也必須發布更多的成效數據。

5.2.影片編碼

如果裝置導入方式支援任何影片編碼器，並提供第三方應用程式使用，就會採取以下做法：

• 不應是兩個滑動式窗口，與內框 (I 影格) 間隔之間的位元率超過 15%。
• 位元率不應超過 100% 超過滑動窗口 1 秒。

如果裝置實作項目具有 2.5 吋以上對角線長度的嵌入式螢幕、影片輸出連接埠，或透過 android.hardware.camera.any 功能旗標宣告支援相機，包括：

• [C-1-1] 必須包含至少一種 VP8 或 H.264 視訊編碼器的支援，且可供第三方應用程式使用。
• 應同時支援 VP8 和 H.264 視訊編碼器，且可供第三方應用程式使用。

如果裝置實作支援任何 H.264、VP8、VP9 或 HEVC 視訊編碼器，並提供給第三方應用程式使用，他們會：

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

如果裝置實作支援 MPEG-4 SP 影片編碼器，並提供給第三方應用程式使用，它們：

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

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

• [C-4-1] 所有硬體加速視訊和影像編碼器「必須」支援硬體相機的編碼影格。
• 應支援硬體相機透過所有影片或圖片編碼器編碼的影格。

5.2.1。標題 263

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

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

5.2.2。標題 264

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

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

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

• [C-2-1] 必須支援下表中的編碼設定檔。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 (720p)	HD 高畫質 (1080p)
影片解析度	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	20 fps	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格
視訊位元率	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3.VP8

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

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

如果裝置導入方式回報支援透過媒體 API 針對 720p 或 1080p 解析度影片的 VP8 編碼，就會：

• [C-2-1] 必須支援下表中的編碼設定檔。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 (720p)	HD 高畫質 (1080p)
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格
視訊位元率	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4。VP9

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

• [C-1-2] 必須支援個人資料 0 第 3 級。
• [C-1-1] 必須支援編寫 Matroska WebM 檔案。
• [C-1-3] 必須產生 CodecPrivate 資料。
• 「應該」支援 HD 編碼解碼設定檔，如下表所示。
• 若有硬體編碼器，[SR] 極力建議支援 HD 解碼設定檔，如下表所示。

	SD 標準畫質	HD 高畫質 (720p)	HD 高畫質 (1080p)	UHD 超高畫質
影片解析度	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格
視訊位元率	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

如果裝置的實作方式宣稱可透過 Media API 支援 Profile 2 或 Profile 3：

• 支援 12 位元格式。

5.2.5。標題 265

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

• [C-1-1] 必須支援主要設定檔第 3 級。
• 「應該」支援 HD 高畫質編碼設定檔，如下表所示。
• 若有硬體編碼器，[SR] 極力建議支援 HD 高畫質編碼設定檔，如下表所示。

	SD 標準畫質	HD 高畫質 (720p)	HD 高畫質 (1080p)	UHD 超高畫質
影片解析度	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格
視訊位元率	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3.影片解碼

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

• [C-1-1] 必須在同一串流中，透過標準 Android API 使用標準 Android API 的動態影片解析度和畫面更新率切換功能，即時支援所有 VP8、VP9、H.264 和 H.265 轉碼器，以及裝置每個轉碼器支援的最高解析度。

5.3.1。MPEG-2

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

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

5.3.2。標題 263

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

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

5.3.3.MPEG-4

如果裝置使用 MPEG-4 解碼器，它們：

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

5.3.4。標題 264

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

• [C-1-1] 必須支援主要設定檔層級 3.1 和基準設定檔。您可以選擇支援 ASO (任意配量排序)、FMO (彈性巨集排序) 和 RS (多餘配量)。
• [C-1-2] 必須能使用下表所列的 SD (標準畫質) 設定檔解碼影片，並使用基準設定檔和主要設定檔層級 3.1 (包括 720p30) 編碼。
• 「應該」能使用 HD (高畫質) 設定檔來解碼影片，如下表所示。

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

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

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 (720p)	HD 高畫質 (1080p)
影片解析度	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	60 fps	30 fps (60 fps^電視)
視訊位元率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5。H.265 (HEVC)

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

• [C-1-1] 必須支援第 3 級主要層級和 SD 影片解碼設定檔，如下表所示。
• 「應該」支援 HD 編碼解碼設定檔，如下表所示。
• [C-1-2] 使用硬體解碼器時，「必須」支援如下表所示的 HD 高畫質解碼設定檔。

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

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

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 (720p)	HD 高畫質 (1080p)	UHD 超高畫質
影片解析度	352 x 288 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格	30/60 fps (60 fps，^採用 H.265 硬體解碼的電視)	60 fps
視訊位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

如果裝置的實作方式透過 Media API 聲明支援 HDR 設定檔 (HEVCProfileMain10HDR10、HEVCProfileMain10HDR10Plus)：

• [C-3-1] 裝置實作「必須」使用 MediaCodec API 從應用程式接受必要的 HDR 中繼資料 (所有 HDR 設定檔的MediaFormat#KEY_HDR_STATIC_INFO)，並支援擷取所需的 HDR 中繼資料 (從所有 HDR 設定檔中定義的 MediaFormat#KEY_HDR_STATIC_INFO，以及 MediaFormat_PLUS0 資訊，這些規格還必須能根據相關規格的定義，從位元流和/或容器輸出所需的 HDR 中繼資料 (所有 HDR 設定檔的MediaFormat#KEY_HDR_STATIC_INFO)。

• [C-SR] 裝置的實作方式極力「建議」支援透過 MediaCodec#getOutputFormat(int) 輸出 HDR10Plus 設定檔的中繼資料 MediaFormat#KEY_HDR10_PLUS_INFO.

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

• [C-SR] 極力建議採用裝置實作方式，HEVCProfileMain10HDR10Plus在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

5.3.6。VP8

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

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

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

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

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 (720p)	HD 高畫質 (1080p)
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	30 fps (60 fps^電視)	30 (60 fps^電視)
視訊位元率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7。VP9

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

• [C-1-1]「必須」支援 SD 影片解碼設定檔，如下表所示。
• 「應該」支援 HD 編碼解碼設定檔，如下表所示。

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

• [C-2-1] 「必須」支援 HD 高畫質解碼設定檔，如下表所示。

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

• [C-3-1] 裝置實作項目至少須支援 720、1080 和 UHD 超高畫質設定檔解碼的 VP9 或 H.265 檔案。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 (720p)	HD 高畫質 (1080p)	UHD 超高畫質
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片畫面更新率	每秒 30 個影格	每秒 30 個影格	每秒 30 個影格	30 fps (^採用 VP9 硬體解碼的電視)	60 fps
視訊位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

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

• 支援 12 位元格式。

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

• [C-4-1] 裝置實作「必須」從使用 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] 裝置實作「必須」正確顯示裝置螢幕上 VP9Profile2HDR 和 VP9Profile3HDR 設定檔的 HDR 內容，或是標準視訊輸出連接埠 (例如HDMI)。

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

• [C-SR] 極力建議裝置實作方式為 VP9Profile2HDR10Plus 和 VP9Profile3HDR10Plus 設定檔在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

5.3.8。Dolby Vision

如果裝置實作方式透過 HDR_TYPE_DOLBY_VISION 宣告支援 Dolby Vision 解碼器，就會發生以下情形：

• [C-1-1] 必須提供支援 Dolby Vision 的擷取器。
• [C-1-2] 必須在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。
• [C-1-3] 必須將回溯相容基礎層 (如有) 的軌跡索引設為與 Dolby Vision 圖層合併後追蹤索引相同的。

5.3.9。AV1 格式

如果裝置實作支援 AV1 轉碼器，就會：

• [C-1-1] 必須支援 Profile 0，其中包含 10 位元內容。

5.4.錄音

雖然本節所列的部分規定已列為自 Android 4.3 起的「應有的元件」，我們計劃將日後版本的相容性定義變更為「必須」。我們強烈建議現有和新的 Android 裝置符合「應」的上述條件，否則日後升級至新版本時，將無法獲得 Android 相容性。

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

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

• [C-1-1] 必須允許擷取符合下列規定的原始音訊內容：

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

• 應提供具備下列特性的原始音訊內容：

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

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

• [C-1-3] 如果以低取樣率擷取上述取樣率，「必須」加入適當的反鋸齒篩選器。

• 應允許 AM 無線電和 DVD 品質擷取原始音訊內容，這意味著下列特性：

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

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

• [C-2-1] 必須採用高於 16000:22050 或 44100:48000 的任何比例，不要進行上取樣。

• [C-2-2] 在任何向上取樣或降低取樣時，都必須加入適當的反鋸齒篩選器。

5.4.2。擷取以辨識聲音

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

• [C-1-1] 必須以 44100 和 48000 這兩種取樣率擷取 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源。
• [C-1-2] 從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，「必須」預設停用所有雜訊抑制音訊處理作業。
• [C-1-3] 從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，必須預設停用所有自動增益控制項。
• 錄製聲音串流時，應以大約平坦的振幅與頻率特性 (特別是 ±3 dB、從 100 Hz 至 4000 Hz) 錄製。
• 請務必使用輸入靈敏度集錄製語音辨識音訊串流，讓 1000 Hz 的 90 dB 聲音功率 (SPL) 源能產生 2500 RMS 的 16 位元樣本。
• 請錄製語音辨識音訊串流，讓 PCM 的振幅與輸入的 SPL 可以線性追蹤至少 30 分貝 (介於麥克風之間介於 -18 dB 到 +12 dB re 90 dB SPL 之間) 的差距。
• 如以 90 dB SPL 輸入等級，以 1 kHz 為 1 kHz 的音訊辨識音訊串流必須小於 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，就會：

• 應導入 Acoustic Echo canceler (AEC) 技術，專門針對語音通訊加以調整，且在使用 AudioSource.VOICE_COMMUNICATION 拍攝時，會套用到擷取路徑

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

• [C-SR] STRONGLY_RECOMMENDED 透過 AcousticEchoCanceler API 方法 AcousticEchoCanceler.isAvailable() 宣告這個 API 方法。
• [C-SR] 可 STRONGLY_RECOMMENDED，才能透過 AcousticEchoCanceler API 控制這個音訊效果。
• [C-SR] 的用途是 STRONGLY_RECOMMENDED，用 AudioEffect.Descriptor.uuid 欄位識別各項 AEC 技術實作。

5.4.5。並行擷取

如果裝置實作程序宣告 android.hardware.microphone，則「必須」按照本文件所述實作並行擷取。詳細說明：

• [C-1-1] 「必須」允許無障礙服務透過 AudioSource.VOICE_RECOGNITION 擷取，且至少有一個應用程式以任何 AudioSource 擷取的應用程式同時存取麥克風。
• [C-1-2] 必須允許預先安裝的應用程式並行存取麥克風，且該應用程式具備 Google 助理角色，且至少有一個應用程式以任何 AudioSource 擷取 (AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 除外)。
• [C-1-3] 除無障礙服務外，如果應用程式使用 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 擷取內容，必須關閉其他應用程式的音訊擷取功能。不過，如果應用程式透過 AudioSource.VOICE_COMMUNICATION 擷取資訊，如果應用程式具備 CAPTURE_AUDIO_OUTPUT 權限 (預先安裝) 特殊權限，其他應用程式也能擷取語音來電。
• [C-1-4] 如果有兩個以上的應用程式同時擷取，而且在上方都沒有使用者介面，則啟動擷取最近音訊的應用程式。

5.4.6。麥克風增益

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

• 應該在中頻範圍中表現出近乎平坦的振幅與頻率特性：特別是從 100 Hz 到 4000 Hz 的 ±3dB，每個用來錄製語音辨識音訊來源的麥克風也要有這種特性。
• 應設定音訊輸入靈敏度，以便在以 90 dB 音壓等級 (SPL) 播放的 1000 Hz 內聲色調來源產生 2500 RMS 的 RMS 回應 (針對浮點數/每個音訊樣本使用 -22.35 dB 完整聲道，且每個語音樣本錄音/雙精度樣本錄音)。
• [C-SR] 強烈建議在低頻率範圍內展現振幅：特別是從 5 Hz 到 100 Hz 的振幅，相比之下，錄製語音辨識音訊來源的每個麥克風的中頻率範圍相比。
• [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] 必須支援可透過 AudioEffect 子類別 Equalizer 和 LoudnessEnhancer 控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 實作。
• [C-1-2] 必須支援視覺化工具 API 實作，且可透過 Visualizer 類別控制。
• [C-1-3] 必須支援 EFFECT_TYPE_DYNAMICS_PROCESSING 實作控制項，透過 AudioEffect 子類別 DynamicsProcessing
• 應支援可透過 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.音訊輸出音量

Automotive 裝置實作：

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

5.6.音訊延遲時間

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

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

• 輸出延遲。應用程式寫入 PCM 編碼資料影格的時間，與在裝置端傳音器或信號向環境呈現相應聲音的間隔時間，該音訊會透過通訊埠從裝置傳出，因此可對外觀察。
• 冷輸出延遲。第一個影格的輸出延遲時間，如果音訊輸出系統在要求前處於閒置狀態且已關機，則第一個影格的輸出延遲時間。
• 連續輸出延遲。裝置播放音訊後，後續影格的輸出延遲時間。
• 輸入延遲。裝置透過裝置端轉換器或訊號向裝置顯示聲音的間隔時間，是指透過連接埠進入裝置，以及應用程式讀取對應 PCM 編碼資料影格的間隔時間。
• 輸入信號的初始部分無法使用或無法使用。
• 冷輸入延遲時間。音訊輸入系統在要求前處於閒置狀態，且在要求前已關機，第一個影格的輸入時間總和與輸入延遲時間。
• 連續輸入延遲。後續影格的輸入延遲時間，同時裝置正在擷取音訊。
• 冷輸出時基誤差。不同測量冷輸出延遲時間值之間的變異性。
• 冷輸入時基誤差。不同測量冷輸入延遲時間值的差距。
• 連續往返延遲時間。連續輸入延遲時間的總和加上連續輸出延遲時間加一個緩衝區週期的總和。緩衝期可讓應用程式處理信號和時間，減少輸入與輸出串流之間的階段差異。
• OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 組合。
• AAudio 原生音訊 API。Android NDK 中的 AAudio API 組合。
• timestamp：組合包含串流中的相對影格位置，以及該影格進入或離開相關端點音訊處理管道的預估時間。另請參閱 AudioTimestamp。
• 音訊訊號的暫時性中斷或樣本值不正確，通常是因為輸出的緩衝區不足、輸入的緩衝區過度，或是任何其他數位或類比噪音來源所致。

如果裝置實作項目宣告 android.hardware.audio.output，則必須符合或超過下列規定：

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

如果裝置導入方式宣告 android.hardware.audio.output，就極力建議符合或超過下列規定：

• [C-SR] 冷輸出延遲時間不超過 100 毫秒。凡是搭載此 Android 版本的現有裝置和新裝置，都「極力」建議現在符合這些規定。針對 2021 年日後推出的平台版本，我們規定的冷輸出延遲時間必須小於 200 毫秒。
• [C-SR] 連續輸出延遲時間不超過 45 毫秒。
• [C-SR] 盡量減少冷輸出時基誤差。
• [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 毫秒。凡是搭載此 Android 版本的現有裝置和新裝置，都「極力」建議現在符合這些規定。針對 2021 年日後推出的平台版本，我們規定「必須」的情況，將冷輸入延遲時間設為 200 毫秒以下。
• [C-SR] 連續輸入延遲時間不超過 30 毫秒。
• [C-SR] 連續往返延遲時間不超過 50 毫秒。
• [C-SR] 盡量減少冷輸入時基誤差。
• [C-SR] 將輸入時間戳記中的錯誤 (由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回) 限制為 +/- 1 毫秒。

5.7.網路通訊協定

裝置導入作業「必須」支援播放音訊和影片播放的媒體網路通訊協定，如 Android SDK 說明文件所述。

如果裝置導入方式包含音訊或影片解碼器，就會：

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

• [C-1-2] 必須支援下方 HTTP 即時串流草稿通訊協定 (第 7 版) 中所列出的媒體區隔格式表格格式。

• [C-1-3] 「必須」支援下方 RTSP 表格中的下列 RTP 音訊視訊設定檔和相關轉碼器。如有例外情況，請參閱 5.1 節中的表格註釋。

媒體區隔格式

區隔格式	參考資料	必要的轉碼器支援
MPEG-2 傳輸串流	ISO 13818	視訊轉碼器： H264 AVC MPEG-4 SP MPEG-2 如需 H264 AVC、MPEG2-4 SP 的詳細資訊，請參閱第 5.1.3 節。 以及 MPEG-2 音訊轉碼器： 進階音訊編碼 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
採用 ADTS 取景和 ID3 代碼的 AAC	ISO 13818-7	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
WebVTT	WebVTT

RTSP (RTP、SDP)

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

5.8.安全媒體

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

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

如果裝置導入方式宣告支援 Display.FLAG_SECURE，並支援無線顯示通訊協定，就會：

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

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

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

5.9.樂器數位介面 (MIDI)

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

• [C-1-1] 必須「一律」透過支援 MIDI 的「所有」硬體傳輸 (MIDI) 支援 MIDI，這類傳輸方式提供一般的非 MIDI 連線：

  • USB 主機模式，第 7.7 節
  • 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] 必須回報支援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 效能一致。請使用 Android 應用程式版本的 SynthMark 修訂版本 ID 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 進行測試。SynthMark 使用的軟體合成器在模擬音訊架構中運作，以測量系統效能。SynthMark 應用程式必須使用「Automated Test」選項執行，並達到下列結果：
  • Voicemark.90 >= 32 種語音
  • etcmark.fixed.little <= 15 毫秒
  • etcmark.dynamic.little <= 50 毫秒

如需基準測試的說明，請參閱 SynthMark 說明文件。

• 應盡量減少音訊時鐘的準確度，以及相對於標準時間的偏移。
• 在兩個動作皆啟動時，應盡量減少音訊時鐘相對於 CPU (CLOCK_MONOTONIC) 的偏移。
• 應盡量縮短裝置端轉換器的音訊延遲情形。
• 相較於 USB 數位音訊，應盡量縮短音訊延遲。
• 應記錄所有路徑的音訊延遲測量值。
• 請盡量減少音訊緩衝區完成回呼輸入時間的時基誤差，因為這會影響回呼可用的完整 CPU 頻寬百分比。
• 應該在正常使用時回報延遲，避免發生音訊故障。
• 應呈現零的跨管道延遲時間差異。
• 應盡量減少所有傳輸中的 MIDI 平均延遲時間。
• 應盡量減少所有傳輸過程中負載 (如時基誤差) 的 MIDI 延遲時間變化。
• 所有傳輸作業都應提供準確的 MIDI 時間戳記。
• 請盡量減少在裝置端配音裝置 (包括冷啟動後) 的音訊訊號雜訊。
• 如果兩者啟用時，對應端點的輸入與輸出端應呈現零的音訊時脈。相應的端點範例包括裝置端麥克風和喇叭，或是音訊插孔輸入和輸出。
• 在兩者皆啟用的情況下，應在同一個執行緒上針對對應端點的輸入和輸出端，處理音訊緩衝區完成回呼，並在輸入回呼的傳回後立即輸入輸出回呼。如果無法在同一個執行緒上處理回呼，則在輸入輸入回呼後不久，輸入輸出回呼，讓應用程式擁有一致的輸入和輸出端時間。
• 請盡量減少對於對應端點的輸入和輸出端 HAL 音訊緩衝區之間的相位差異。
• 應盡量縮短觸控延遲時間。
• 應盡量減少載入時觸控延遲時間的變化 (時基誤差)。
• 從觸控輸入到輸出音訊的延遲時間應小於或等於 40 毫秒。

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

• [SR] 強烈建議透過 android.content.pm.PackageManager 類別回報對 android.hardware.audio.pro 功能的支援。

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

• [C-2-1] 音訊插孔路徑的連續往返音訊延遲時間不得超過 20 毫秒。
• [SR] 強烈建議遵循有線音訊頭戴式規格 (v1.1) 的行動裝置 (插孔) 規格。
• 連續往返音訊延遲時間應在音訊插孔路徑中不超過 10 毫秒。

如果裝置實作不需要 4 導電線 3.5 公釐耳機插孔，並加入支援 USB 主機模式的 USB 連接埠，就會：

• [C-3-1] 必須實作 USB 音訊類別。
• [C-3-2] 在使用 USB 主機模式連接埠的 USB 主機模式連接埠上，往返音訊延遲時間不得超過 20 毫秒，且必須使用 USB 音訊類別。
• 使用 USB 音訊類別的 USB 主機模式連接埠時，連續往返音訊延遲時間應小於 10 毫秒。
• [C-SR] 強烈建議「極力」支援同時支援最多 8 個 I/O 聲道，並支援每個方向最多 8 個通道，搭配 96 kHz 取樣率，以及 24 位元或 32 位元深度 (如果與同時支援這些要求的 USB 音訊週邊裝置)。

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

• 至少要透過一項設定，支援 8 個聲道和 8 個聲道 (解析度為 20 位元或 24 位元)，並且沒有位元深度損失或重新取樣。

5.11.擷取尚未處理

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

如果裝置實作意圖支援未處理的音訊來源，並提供給第三方應用程式使用，就會執行以下動作：

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

• [C-1-2] 在中頻範圍內，必須呈現大致扁平的振幅與頻率特性：特別是從 100 Hz 到 7000 Hz 的每台麥克風，用來記錄未處理音訊來源的每個麥克風。

• [C-1-3] 低頻率範圍必須呈現振幅 (特別是 ±20 dB 的 5 Hz 至 100 Hz 範圍)，對於記錄未處理音訊來源的每個麥克風，兩者的中頻範圍相比差異更是如此。

• [C-1-4] 必須在高頻率範圍內表現振幅 (特別是 ±30 dB 的 7000 Hz 至 22 KHz 範圍)，對於錄製未處理音訊來源的每個麥克風，兩者相比表現出的中頻範圍相當明顯。

• [C-1-5] 必須設定音訊輸入靈敏度，讓以 94 dB 音壓等級 (SPL) 播放的 1000 Hz 聲調音源能產生回應，且 RMS 為 520，針對 16 位元取樣 (每個使用且每個未精度取樣的音訊，-36 dB 完整體重計)

• [C-1-6] 針對每個用來錄製未處理音訊來源的麥克風，每個麥克風都必須達到 60 dB 以上的訊號雜訊比 (SNR)。(SNR 的衡量標準為 94 dB SPL 與自雜噪音 (A 加權) 相等的 SPL 之間) 的差異。

• [C-1-7] 以 90 dB SPL 輸入等級時，每個用於錄製未處理音訊來源的麥克風，每 1 kHZ 的總諧變形變形 (THD) 都必須小於 1%。

• 除非路徑經過調整，否則請勿要求任何其他處理訊號 (例如自動增益控制、高通過濾器或回音取消)，以便讓等級範圍達到所需範圍。也就是說：

• [C-1-8] 如果架構中存在任何原因的訊號處理，則「必須」停用並有效將零延遲或額外的延遲傳送至信號路徑。
• [C-1-9] 當層級係數允許在路徑上，但「不得」造成信號路徑延遲或延遲。

所有 SPL 測量結果都直接放在受測試的麥克風旁邊。如果設定多種麥克風，則這些需求適用於每個麥克風。

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

• [C-2-1] 必須為 AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API 方法傳回 null，才能正確指出不支援這項功能。
• [SR] 仍極力建議，以滿足未處理錄製來源的信號路徑要求 (盡可能滿足多項要求)。

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

6.1.開發人員工具

裝置實作方式：

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

• Android Debug Bridge (ADB)

  • [C-0-2] 必須支援 Android SDK 中記錄的 ADB 和 Android 開放原始碼計畫提供的殼層指令，供應用程式開發人員使用，包括 dumpsys cmd stats
  • [C-SR] 強烈建議支援殼層指令 cmd testharness。
  • [C-0-3] 「不得」變更透過 dumpsys 指令記錄的裝置系統事件 (batterystats 、diskstats、Fingerprint、graphicstats、netstats、notification、 procstats) 的格式或內容。
  • [C-0-10] 請務必進行記錄 (不可省略)，並開放 cmd stats 殼層指令和 StatsManager 系統 API 類別存取下列事件。
    • ActivityForegroundState 已變更
    • 偵測到異常狀況
    • 已回報的應用程式導覽標記
    • 應用程式當機
    • AppStart 發生
    • 電池等級已變更
    • BatterySaverModeState 已變更
    • BleScanResultReceived
    • BleScanState 已變更
    • ChargingState 已變更
    • DeviceIdleModeState 已變更
    • 前景服務狀態已變更
    • GpsScanState 已變更
    • 工作狀態已變更
    • PluggedState 已變更
    • 已排程工作狀態已變更
    • 畫面狀態已變更
    • SyncState 已變更
    • SystemElapsedRealtime
    • UidProcessState 已變更
    • WakelockState 已變更
    • 喚醒鬧鐘發生次數
    • WifiLockState 已變更
    • WifiMulticastLockState 已變更
    • WifiScanState 已變更
  • [C-0-4] 裝置端 ADB Daemon 必須預設為停用，且該機制必須可讓使用者存取，才能啟用 Android Debug Bridge。
  • [C-0-5] 必須支援安全 ADB。Android 支援安全 ADB。安全 ADB 可在已知的驗證主機上啟用 ADB。

  • [C-0-6] 必須提供讓 ADB 從主機機器連線的機制。例如：

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

• Dalvik 偵錯監控服務 (ddms)

  • [C-0-7] 必須支援 Android SDK 中記錄的所有 ddms 功能。由於 ddms 會使用 ADB，因此預設不支援 ddms，但當使用者啟用 Android Debug Bridge 時，「必須」提供支援。
• 猴子
  • [C-0-8] 必須加入 Monkey 架構，供應用程式使用。
• SysTrace
  • [C-0-9] 必須支援 Android SDK 中所述的 systrace 工具。Systrace「必須」預設為停用，且「必須」讓使用者能存取的機制來開啟 Systrace。

• Perfetto

  • [C-SR] 強烈建議向殼層使用者公開 /system/bin/perfetto 二進位檔 (cmdline 須符合 Perfetto 說明文件)。
  • [C-SR] Perfetto 二進位檔極度建議接受為符合 Perfetto 說明文件 定義結構定義的 protobuf 設定。
  • [C-SR] 極力建議您根據 Perfetto 說明文件中定義的結構定義，將 Perfetto 二進位檔寫入為輸出內容 protobuf 追蹤記錄。
  • [C-SR] 強烈建議透過 Perfetto 二進位檔提供至少 Perfetto 說明文件中所述的資料來源。

• 測試控管工具模式

  如果裝置實作項目支援殼層指令 cmd testharness 並執行 cmd testharness enable，就會執行以下動作：

  • [C-2-1] 必須傳回 ActivityManager.isRunningInUserTestHarness() 的 true
  • [C-2-2] 「必須」按照控管模式說明文件中所述實作測試控管工具模式。

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

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

6.2.開發人員選項

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

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

• [C-0-1] 必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，以顯示應用程式開發相關設定。上游 Android 實作方式預設會隱藏「開發人員選項」選單，讓使用者在「設定」> 點選七 (7) 次後，就能啟動開發人員選項關於裝置 >「Build Number」選單項目。
• [C-0-2] 預設必須隱藏開發人員選項。
• [C-0-3] 必須針對啟用開發人員選項，提供明確的機制，使應用程式無法優先採用其他應用程式。「必須」提供可公開查看的文件或網站，並說明如何啟用開發人員選項。這份文件或網站必須能從 Android SDK 文件連結。
• 如果已啟用開發人員選項，且有顧慮到使用者安全，就應持續向使用者顯示視覺通知。
• 「開發人員選項」選單可能會暫時限制存取，例如隱藏或停用選單，以免在保障使用者安全的情況下受到干擾。

7. 硬體相容性

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

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

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

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

符合這些要求適用的常見情況範例為電話 API：即使在手機以外的裝置上，這些 API 仍必須以合理的免人工管理方式實作。

7.1.顯示和圖形

Android 包含可以自動為裝置調整應用程式資產和 UI 版面配置的功能，以確保第三方應用程式能在各種硬體設定上正常運作。在 Android 相容螢幕上，所有第三方 Android 相容應用程式皆可執行，裝置實作「必須」正確實作這些 API 和行為，詳情請見本節的內容。

本節中規定所參照的單位定義如下：

• 實際對角線大小。顯示器的兩個反對角之間的距離 (以英寸為單位)。
• 每英寸像素數 (dpi)。覆蓋 1 的線性水平或垂直範圍的像素數量。在列出 dpi 值的情況下，水平和垂直的 dpi 都必須落在這個範圍內。
• 顯示比例。長尺寸與螢幕短邊的像素比例。舉例來說，480x854 像素的顯示大小會是 854/480 = 1.779，或大概是「16:9」。
• 密度獨立像素 (dp)。虛擬像素單位正規化為 160 dpi 螢幕，計算方式為：像素 = dps * (密度/160)。

7.1.1.畫面設定

7.1.1.1。螢幕大小和形狀

Android UI 架構支援各種不同的邏輯螢幕版面配置大小，可讓應用程式透過 Configuration.screenLayout 搭配 SCREENLAYOUT_SIZE_MASK 和 Configuration.smallestScreenWidthDp，查詢目前設定的螢幕版面配置大小。

裝置實作方式：

• [C-0-1] 必須按照 Android SDK 說明文件所定義，回報 Configuration.screenLayout 的正確版面配置大小。具體來說，裝置實作「必須」回報正確的邏輯密度獨立像素 (dp) 螢幕尺寸，如下所示：

  • 如果裝置將 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 以外的任何值，且回報 Configuration.screenLayout 的 small 大小，則裝置至少應具備 426 dp x 320 dp。
  • 裝置回報 Configuration.screenLayout 的 normal 尺寸時，至少必須為 480 dp x 320 dp。
  • 回報 Configuration.screenLayout 的 large 尺寸的裝置不得小於 640 dp x 480 dp。
  • 裝置回報 Configuration.screenLayout 的 xlarge 尺寸不得小於 960 dp x 720 dp。

• [C-0-2] 必須正確遵循申請書」如 Android SDK 說明文件所述，透過 AndroidManifest.xml 中的 <supports-screens> 屬性支援螢幕大小。

• 「可能」具備與 Android 相容的螢幕(圓角設計)。

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

• [C-1-1] 必須確保圓角圓角的半徑小於或等於 38 dp。
• 應提供使用者預設用途，切換為以矩形邊角切換至顯示模式。

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] 根據預設，裝置實作項目「必須」只回報 DisplayMetrics 透過 DENSITY_DEVICE_STABLE API 列出的其中一種 Android 架構密度，且這個值「不得」隨時變更。不過，裝置「可能」會根據使用者在初始啟動後設定的顯示設定變更 (例如顯示大小)，回報不同的任意密度。

• 裝置實作項目「必須」定義最接近螢幕實體密度的標準 Android 架構密度，除非該邏輯密度會將回報的螢幕大小推進低於支援下限。如果標準 Android 架構密度的數值接近實體密度，且螢幕尺寸小於支援的最小相容螢幕尺寸 (320 dp 寬度)，則裝置實作應會回報下一個最低標準 Android 架構密度。

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

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

7.1.2.顯示指標

如果裝置導入方式包含與 Android 相容的螢幕或影片輸出，且可輸出至 Android 相容螢幕，這些元件就會：

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

如果裝置導入方式未提供嵌入畫面或影片輸出內容，請按照下列步驟操作：

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

7.1.3.螢幕方向

裝置實作方式：

• [C-0-1] 必須回報支援的螢幕方向 (android.hardware.screen.portrait 和/或 android.hardware.screen.landscape)，且至少必須回報一種支援的螢幕方向。舉例來說，如果裝置螢幕方向為固定的橫向螢幕 (例如電視或筆電)，就只能回報 android.hardware.screen.landscape。
• [C-0-2] 每次透過 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查詢時，都必須回報裝置目前螢幕方向的正確值。

如果裝置實作支援這兩種螢幕方向，就會發生以下情形：

• [C-1-1] 必須讓應用程式支援直向或橫向螢幕方向的動態螢幕方向。也就是說，裝置「必須」遵循應用程式的特定螢幕方向要求。
• [C-1-2] 變更螢幕方向時，「不得」變更回報的螢幕大小或密度。
• 可選擇直向或橫向做為預設方向。

7.1.4。2D 和 3D 圖形加速

7.1.4.1 OpenGL ES

裝置實作方式：

• [C-0-1] 必須透過代管 API (例如透過 GLES10.getString() 方法) 和原生 API，正確識別支援的 OpenGL ES 版本 (1.1、2.0、3.0、3.1、3.2)。
• [C-0-2] 必須針對指出支援的每個 OpenGL ES 版本，加入所有對應的代管 API 和原生 API 的支援。

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

• [C-1-1] 必須同時支援 OpenGL ES 1.1 和 2.0，詳情請參閱 Android SDK 說明文件。
• [C-SR] 強烈建議我們支援 OpenGL ES 3.1。
• 應支援 OpenGL ES 3.2。

如果裝置實作支援任何 OpenGL ES 版本，就會：

• [C-2-1] 「必須」透過 OpenGL ES 代管 API 和原生 API 回報自己已導入的任何其他 OpenGL ES 擴充功能，而且「不得」回報不支援的擴充功能字串。
• [C-2-2] 必須支援 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、EGL_ANDROID_recordable 和 EGL_ANDROID_GLES_layers 的擴充功能。
• [C-SR] 強烈建議支援 EGL_KHR_partial_update 和 OES_EGL_image_external 擴充功能。
• 應透過 getString() 方法正確回報，也就是他們支援的任何紋理壓縮格式，通常僅適用於供應商。

如果裝置實作宣告支援 OpenGL ES 3.0、3.1 或 3.2，就會發生以下情形：

• [C-3-1] 除了 OpenGL ES 2.0 程式庫中的 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] 必須為每個列舉的 VkPhysicalDevice 完全實作 Vulkan 1.0 API。
• [C-1-4] 請務必透過 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties()，列舉位於應用程式套件原生程式庫目錄中名為 libVkLayer*.so 的原生程式庫中的層。
• [C-1-5] 除非應用程式將 android:debuggable 屬性設為 true，否則「不得」列舉應用程式套件以外程式庫提供的層，或提供其他追蹤或攔截 Vulkan API 的方法。
• [C-1-6] 必須回報所有透過 Vulkan 原生 API 支援的擴充功能字串，相反地，也「不得」回報未正確支援的擴充功能字串。
• [C-1-7] 必須支援 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 擴充功能。
• [C-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] 必須公開對 SYNC_FD 外部路徑和處理常式類型和 VK_ANDROID_external_memory_android_hardware_buffer 擴充功能的支援。

7.1.4.3 RenderScript

• [C-0-1] 裝置實作項目「必須」支援 Android RenderScript，詳情請見 Android SDK 說明文件。

7.1.4.4 2D 圖形加速

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

裝置實作方式：

• [C-0-1] 在預設情況下，「必須」啟用硬體加速功能，如果開發人員透過設定 android:hardwareAccelerated="false" 或直接透過 Android View API 停用硬體加速功能來要求硬體加速功能，則「必須」停用硬體加速功能。
• [C-0-2] 必須呈現與硬體加速 Android SDK 說明文件一致的行為。

Android 包含 TextureView 物件，可讓開發人員直接整合硬體加速的 OpenGL ES 紋理，做為 UI 階層中的算繪目標。

裝置實作方式：

• [C-0-3] 必須支援 TextureView API，而且「必須」展現與上游 Android 實作一致的行為。

7.1.4.5 廣角螢幕

如果裝置實作方式透過 Configuration.isScreenWideColorGamut() 宣告支援廣角螢幕，就會：

• [C-1-1] 必須採用色彩校正的螢幕。
• [C-1-2] 的螢幕「必須」採用 CIE 1931 xyY 空間中完全覆蓋 sRGB 色域的螢幕。
• [C-1-3] 在 CIE 1931 xyY 中，「必須」具備總域的 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] 強烈建議你支援 GL_EXT_sRGB。

相反地，如果裝置實作項目不支援廣角螢幕，就會：

• [C-2-1] 在 CIE 1931 xyY 空間中，必須涵蓋 100% 以上的 sRGB，但螢幕色彩密度未定義。

7.1.5。舊版應用程式相容性模式

Android 會指定「相容性模式」，讓架構以「正常」狀態運作螢幕尺寸等效 (320dp 寬度) 模式，適用於未針對未依螢幕尺寸獨立而開發的舊版 Android 開發的舊版應用程式。

7.1.6。螢幕技術

Android 平台中的 API 可讓應用程式將豐富的圖形算繪至與 Android 相容的顯示器。除非本文件特別許可，否則裝置「必須」支援 Android SDK 定義的所有 API。

裝置實作方式的所有 Android 相容螢幕：

• [C-0-1] 必須能夠轉譯 16 位元色彩圖形。
• 應支援能夠顯示 24 位元色彩圖形的螢幕。
• [C-0-2] 必須能夠轉譯動畫。
• [C-0-3] 像素顯示比例 (PAR) 必須介於 0.9 和 1.15 之間。也就是說，像素顯示比例必須接近 1.0 正方形 (寬 10 ~ 15%)，

7.1.7.第二螢幕

Android 支援次要 Android 相容螢幕，以啟用媒體分享功能，並使用開發人員 API 存取外部螢幕。

如果裝置的實作支援有線、無線或嵌入式其他螢幕連線來連接外接螢幕，請注意：

• [C-1-1] 必須按照 Android SDK 說明文件所述，實作 DisplayManager 系統服務和 API。

7.2.輸入裝置

裝置實作方式：

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

7.2.1。鍵盤

如果裝置實作項目支援第三方輸入法編輯器 (IME) 應用程式，請按照下列步驟操作：

• [C-1-1] 必須宣告 android.software.input_methods 功能標記。
• [C-1-2] 必須完全導入 Input Management Framework
• [C-1-3] 「必須」配有預先安裝的軟體鍵盤。

裝置實作：* [C-0-1]「不得」提供不符合 android.content.res.Configuration.keyboard 指定格式 (QWERTY 或 12-key) 的硬體鍵盤。* 應加入其他螢幕鍵盤實作。* 可能提供實體鍵盤。

7.2.2。非觸控瀏覽

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

裝置實作方式：

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

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

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

7.2.3.瀏覽鍵

「主畫面」、「近期活動」和「返回」功能通常透過與專屬實體按鈕或觸控螢幕不同部分的互動提供，是 Android 導覽範例不可或缺的要素，因此裝置的實作方式如下：

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

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

• [C-1-1] 必須讓使用者能透過單一動作 (例如輕觸、按兩下或手勢) 存取其中任何項目。
• [C-1-2] 必須明確指出每個函式會觸發哪個單一動作。這類指標包括在按鈕上呈現可見的圖示、在畫面的導覽列顯示軟體圖示，或是引導使用者逐步示範教學流程。

裝置實作方式：

• [SR] 強烈建議不要為選單函式提供輸入機制，因為該函式已從 Android 4.0 起淘汰，並改用動作列。

如果裝置實作提供選單功能，就會：

• [C-2-1] 每當動作溢位選單彈出式選單沒有空白，且系統顯示動作列時，「必須」顯示動作溢位按鈕。
• [C-2-2] 「不得」透過在動作列中選取溢位按鈕的方式修改動作溢位彈出式視窗顯示的位置，但「可能」選取選單函式，以在畫面修改時的位置顯示動作溢位彈出式視窗。

如果裝置實作項目未提供選單功能，但基於回溯相容性，則：* [C-SR] 強烈建議在 targetSdkVersion 小於 10 時 (透過實體按鈕、軟體鍵或手勢)，為應用程式提供選單功能。這個選單函式必須可供存取，除非與其他導覽功能一併隱藏。

如果裝置導入方式提供輔助函式，就會：

• [C-4-1] 在可存取其他瀏覽鍵時，「必須」開放透過單一動作 (例如輕觸、按兩下或手勢) 存取輔助功能。
• [SR] 強烈建議使用長按主畫面功能，做為這項指定的互動方式。

如果裝置的實作方式使用螢幕上的不同部分顯示瀏覽鍵，就會執行以下動作：

• [C-5-1] 瀏覽鍵「必須」使用畫面的特定部分，且不得提供給應用程式使用，也「不得」遮蓋或乾擾應用程式可用的部分畫面。
• [C-5-2] 凡是符合第 7.1.1 節規定的應用程式，都必須提供部分顯示畫面。
• [C-5-3] 必須遵循應用程式透過 View.setSystemUiVisibility() API 方法設定的旗標，以便讓畫面的這個不同部分 (亦即導覽列) 按照 SDK 的說明正確隱藏。

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() 只能用於回報主畫面手勢辨識區域。
• [C-6-2] 如果手勢啟動位置在前景應用程式透過 View#setSystemGestureExclusionRects() 提供的排除矩形內，但不是 WindowInsets#getMandatorySystemGestureInsets()，則「不得」攔截導航函式，前提是必須在 View#setSystemGestureExclusionRects() 的說明文件規定的排除限制內，達到排除限制的範圍內。
• [C-6-3] 如果前景應用程式先前已傳送 MotionEvent.ACTION_DOWN 事件，則在系統手勢開始攔截觸控後，必須傳送 MotionEvent.ACTION_CANCEL 事件給前景應用程式。
• [C-6-4] 必須提供使用者負擔，以便切換到畫面上的按鈕式導覽 (例如，在「設定」中)。
• 「應」提供主畫面功能；從目前螢幕方向從螢幕底部邊緣往上滑動。
• 在放開手指前，必須從與主畫面手勢相同的區域，使用「最近使用」功能。
• 在 WindowInsets#getMandatorySystemGestureInsets() 內啟動的手勢將「不會」因前景應用程式透過 View#setSystemGestureExclusionRects() 提供的排除矩形而受到影響。

如果有從目前螢幕方向左側和右側邊緣的任何位置提供導覽函式：

• [C-7-1] 「必須」返回，並在目前螢幕方向從左側和右側邊緣往右滑動時提供。
• [C-7-2] 如果提供自訂滑動系統面板於左側或右側邊緣，「必須」放置在螢幕頂端 1/3 處，同時清楚顯示持續性的視覺指示，讓使用者藉由拖曳操作會叫用上述面板，因此不會返回。系統面板「可」設置在畫面邊緣頂端 1/3 的下方，但系統面板「不得」使用超過邊緣的 1/3。
• [C-7-3] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 旗標，從邊緣滑動行為「必須」與 Android 開放原始碼計畫實作相同，詳情請參閱 SDK 中記錄。
• [C-7-4] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 旗標，則「必須」隱藏自訂滑動系統面板，直到使用者開啟 Android 開放原始碼計畫提供的系統資訊列 (又稱為導覽列和狀態列) 為止。

7.2.4。觸控螢幕輸入

Android 支援多種指標輸入系統，例如觸控螢幕、觸控板和模擬觸控輸入裝置。以觸控螢幕為基礎的裝置實作方式會與螢幕相關聯，讓使用者擁有直接操控畫面上的項目。由於使用者是直接觸碰螢幕，系統並不需要任何額外的預設用途來表示受操控的物件。

裝置實作方式：

• 應採用某種指標輸入系統 (類似滑鼠或觸控)。
• 應支援完全獨立追蹤的指標。

如果裝置實作項目包含觸控螢幕 (單點觸控或改善)，則裝置會執行以下動作：

• [C-1-1] 必須回報 Configuration.touchscreen API 欄位的 TOUCHSCREEN_FINGER。
• [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] 必須回報 Configuration.touchscreen API 欄位的 TOUCHSCREEN_NOTOUCH。

如果裝置實作項目宣告支援 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 上游實作包括為符合這項規定的遊戲控制器實作。

按鈕	HID 用量^2	Android 按鈕
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
是^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-Pad 向上鍵^1 D-Pad^1	0x01 0x0039^3	AXIS_HAT_Y^4
D-Pad 左側1 D-Pad 向右鍵^1	0x01 0x0039^3	AXIS_HAT_X^4
左肩按鈕^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
右肩按鈕^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
按一下左鍵^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
按一下滑鼠右鍵^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
首頁^1	0x0c 0x0223	KEYCODE_HOME (3)
背面^1	0x0c 0x0224	KEYCODE_BACK (4)

1 個 KeyEvent

2 「必須」在遊戲板 CA (0x01 0x0005) 中宣告上述 HID 使用行為。

3 這個使用方法「必須」的邏輯下限為 0、邏輯上限為 7、實體下限為 0、實體最大為 315、單位 (以度為單位)，以及報告大小為 4。邏輯值定義為與垂直軸順時針旋轉。舉例來說，邏輯值 0 表示沒有旋轉，按下向上按鈕；邏輯值 1 則代表旋轉 45 度，同時按下向上鍵和向左鍵。

4 MotionEvent

類比控制項^1	HID 用量	Android 按鈕
離開觸發條件	0x02 0x00C5	AXIS_LTRIGGER
右側觸發條件	0x02 0x00C4	AXIS_RTRIGGER
左搖桿	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
右搖桿	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 個 MotionEvent

7.2.7。遙控器

請參閱 2.3.1 節，瞭解裝置專屬的需求。

7.3.感應器

如果裝置實作項目包含特定感應器類型，且該類型具有第三方開發人員適用的 API，則裝置的實作「必須」按照 Android SDK 說明文件和感應器中的 Android 開放原始碼說明文件實作該 API。

裝置實作方式：

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

如果裝置實作項目包含特定感應器類型，且該類型為第三方開發人員提供對應 API，請按照下列步驟操作：

• [C-1-1] 必須根據 Android SDK 說明文件中定義的各種感應器類型，使用相關國際單位 (公制) 值回報所有感應器測量結果。
• [C-1-2] 只有在應用程式處理器處於啟用狀態時，感應器串流要求的延遲時間最長為 100 毫秒 + 2 * sample_time，才能回報感應器資料，延遲時間最長為 0 毫秒。此延遲未包含任何篩選延遲。
• [C-1-3] 必須在感應器啟用的 400 毫秒 + 2 * sample_time 內，回報第一個感應器樣本。此樣本的準確率為 0，可以接受。

• [SR] 「應該」回報事件時間 (以奈秒為單位)，如 Android SDK 說明文件中所定義，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘保持同步。我們強烈建議現有和新推出的 Android 裝置符合這些規定，以便升級至日後推出的平台版本，這可能會成為「必要」元件。同步處理錯誤應小於 100 毫秒。

• [C-1-4] 如果 Android SDK 說明文件指出的 API 是連續的感應器，裝置實作項目「必須」持續提供時基誤差低於 3% 的週期性資料樣本，其中時基誤差的定義為連續事件回報時間戳記值的差異標準差。

• [C-1-5] 必須確保感應器事件串流「不得」阻止裝置 CPU 進入暫停狀態或從暫停狀態喚醒。

• 如果啟用多個感應器，耗電量不應超過個別感應器回報的耗電量總和。

上方清單僅列舉部分內容；記載 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] 必須能夠根據任何軸上的重力(4 公克) 或更多重力量測量
• [C-1-5] 必須採用至少 12 位元的解析度。
• [C-1-6] 標準差不得大於 0.05 m/s^。標準差應根據至少 3 秒收集到的樣本數 (至少 3 秒)，根據每個軸計算標準差。
• 我們強烈建議 [SR] 實作 TYPE_SIGNIFICANT_MOTION 複合感應器。
• 我們強烈建議 [SR] 實作及回報 TYPE_ACCELEROMETER_UNCALIBRATED 感應器。我們會強烈建議 Android 裝置符合這項規定，以便升級至未來平台版本，且此版本可能為「必要」。
• 請務必按照 Android SDK 文件所述，實作 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。
• 回報的事件大小必須至少為 200 Hz。
• 解析度至少要有 16 位元。
• 如果生命週期內的特性在生命週期內有所變化並已補償，則使用時應進行校正，並保留裝置重新啟動之間的補償參數。
• 應針對溫度獲得補償。

如果裝置實作項目包含 3 軸式加速度計以及任何 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR，系統會實作 TYPE_STEP_COUNTER 複合感應器：

• [C-2-1] 兩者的耗電量總和必須小於 4 毫瓦。
• 裝置處於動態或靜態狀態時，每個頻寬皆應低於 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] 必須支援線上校正和補償硬鐵偏誤，並在裝置重新啟動時保留補償參數。
• [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 軸式磁力計 (加速計)，將會：

• 可實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。

如果裝置實作方式包含 3 軸式磁力計、加速計和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器，請按照下列步驟操作：

• [C-3-1] 耗電量必須低於 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 以上數據網路連線的情況下，在 10 秒內 (快速信號、多徑、HDOP < 2) 的空中判斷位置。通常使用某種輔助或預測的 GPS/GNSS 技術來盡可能縮短 GPS/GNSS 鎖定時間 (輔助資料包含參考時間、參考位置和衛星電話/時鐘)。
  • [C-1-6] 進行這類位置計算後，裝置在計算位置時，「必須」判斷所在位置 (在開放天空、5 秒內、重新啟動位置要求後或首次計算位置要求後最多 1 小時內，即使後續在沒有數據連線的情況下提出後續要求及/或重新開機也一樣)。

• 判斷地點後，在開闊的天空的情況下，靜止或移動的加速度小於每秒 1 公尺的平方：

  • [C-1-3] 必須能夠判斷所在位置在 20 公尺以內，且速度在每秒 0.5 公尺以內，且時間至少為 95%。
  • [C-1-4] 必須同時透過至少 8 個星座衛星的 GnssStatus.Callback 同時追蹤及回報資料。
  • 「必須」能夠同時從多個星座 (例如 GPS 以及至少 24 個星座、北斗、Galileo) 追蹤 24 個衛星。
  • [C-SR] 極力建議在緊急電話通話期間，繼續透過 GNSS 定位提供器 API 繼續傳送正常的 GPS/GNSS 定位資訊。
  • [C-SR] 強烈建議「強烈建議」針對追蹤的所有星座 (如 GnssStatus 訊息所報告) 記錄 GNSS 測量結果 (SBAS 除外)。
  • [C-SR] 強烈建議使用記錄 AGC 和 GNSS 評估頻率。
  • [C-SR] 強烈建議將每個 GPS/GNSS 位置的所有準確度預估值 (包括航向、速度和產業資料) 回報給我們。
  • [C-SR] 強烈建議「強烈建議」在找到 GNSS 測量結果後立即記錄，即使尚未記錄到 GPS/GNSS 根據數據計算結果也能立即回報。
  • [C-SR] 強烈建議「不要」回報 GNSS 虛擬範圍和虛擬範圍比率。在判斷地點後，在開放天空的情況下，如果靜止或移動的加速度低於每秒 0.2 公尺，就足以算出每秒 95% 範圍內的位置，且每秒速度在 0.2 公尺內，就至少等同於每秒 95%。

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] 必須計算溫度。
• [C-1-6] 在使用期間必須進行校準及補償，並在裝置重新啟動時保留補償參數。
• [C-1-7] 變異數必須不超過 1e-7 rad^2/s^2/Hz (每 Hz 變異數，或雷射值^2/秒)。變異數可以隨取樣率而異，但必須受到這個值限制。換句話說，如果您以 1 Hz 的取樣率測量陀螺儀的變異數，則不應大於 1e-7 rad^2/s^2。
• [SR] 「強烈建議」裝置在室溫下靜止時，校正錯誤應小於 0.01 雷/秒。
• 回報的事件大小必須至少為 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] 必須計算溫度。
• [SR] 強烈建議能夠回報 300hPa 到 1100hPa 範圍的壓力測量值。
• 應有 1hPa 的絕對精確性。
• 應該擁有超過 20hPa 範圍的 0.12hPa 相對準確度 (當海平面上變更幅度約 200 公尺時，準確度可達 100 萬以下)。

7.3.6。溫度計

裝置實作方式：

• 可能包括環境溫度計 (溫度感應器)。
• 不一定，但不應使用 CPU 溫度感應器。

如果裝置導入作業內含環境溫度計 (溫度感應器)，請按照下列步驟操作：

• [C-1-1] 必須定義為 SENSOR_TYPE_AMBIENT_TEMPERATURE，且必須測量使用者與裝置互動時的環境 (房間/車廂) 溫度 (以攝氏度為單位)。
• [C-1-2] 必須定義為 SENSOR_TYPE_TEMPERATURE。
• [C-1-3] 必須測量裝置 CPU 的溫度。
• [C-1-4] 請勿測量任何其他溫度。

請注意，SENSOR_TYPE_TEMPERATURE 感應器類型已在 Android 4.0 中淘汰。

7.3.7。相框模式

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

7.3.8。鄰近感應器

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

如果裝置導入作業內含鄰近感應器，就會：

• [C-1-1] 「必須」以與螢幕相同的方向測量物體的距離。也就是說，鄰近感應器必須設為偵測畫面附近的物體，因為這類感應器類型的主要用途是偵測使用者正在使用的手機。如果裝置實作項目包含具有任何其他方向的鄰近感應器，就「不得」透過此 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感應器：

  • 測量範圍必須介於 -8 公克到 +8 公克之間，且應有至少 -16 克和 +16 克的測量範圍。
  • 必須採用至少 2048 LSB/g 的測量解析度。
  • 測量頻率不得低於 12.5 Hz。
  • 測量頻率上限為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
  • 測量噪音必須超過 400 μg/√Hz。
  • 這個感應器必須採用至少 3,000 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 批次耗電量不得低於 3 毫瓦。
  • [C-SR] 強烈建議使用 3dB 測量頻寬 (Nyquist 頻率) 80% 以上，白色雜訊光譜範圍則在此頻寬中。
  • 應在室溫環境下測試隨機步行速度低於 30 μg √Hz。
  • 應該有偏誤變化，而不是溫度 ≤ +/- 1 毫克/°C。
  • 應採用 ≤ 0.5% 且靈敏度與溫度變化 (相較於溫度 ≤ 0.03%/C°) 的非線性線性廣告。
  • 跨軸敏感度應為 <2.5 % 和跨軸敏感度變化 <裝置作業溫度範圍介於 0.2% 之間。

• [C-2-2] 的 TYPE_ACCELEROMETER_UNCALIBRATED 必須採用與 TYPE_ACCELEROMETER 相同的品質規定。

• [C-2-3] 必須使用 TYPE_GYROSCOPE 感應器，才能執行以下操作：

  • 測量範圍必須至少介於 -1,000 到 +1000 dp。
  • 測量解析度必須至少為 16 LSB/dp。
  • 測量頻率不得低於 12.5 Hz。
  • 測量頻率上限為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
  • 測量噪音必須超過 0.014°/s/√Hz。
  • [C-SR] 強烈建議使用 3dB 測量頻寬 (Nyquist 頻率) 80% 以上，白色雜訊光譜範圍則在此頻寬中。
  • 應在室溫環境下，進行低於 0.001 °/s √ 的隨機步行速率。
  • 應該有偏誤變化，而不是溫度 ≤ +/- 0.05 °/ s / °C。
  • 應有靈敏度變化，但溫度應為 ≤ 0.02% / °C。
  • 應採用最佳適配線非線性性，且不超過 0.2%。
  • 雜訊密度必須小於 0.007 °/s/√Hz。
  • 裝置靜止時，應在溫度範圍 10 到 40 °C 之間，出現低於 0.002 rad/s 的校準錯誤。
  • 應靈敏度小於 0.1°/s/g。
  • 跨軸敏感度應為 <4.0 % 和跨軸敏感度變化 <裝置作業溫度範圍介於 0.3% 之間。

• [C-2-4] 的 TYPE_GYROSCOPE_UNCALIBRATED 品質規定必須與 TYPE_GYROSCOPE 相同。

• [C-2-5] 必須使用 TYPE_GEOMAGNETIC_FIELD 感應器，才能執行以下操作：

  • 測量範圍必須至少介於 -900 到 +900 μT 之間。
  • 必須採用至少 5 LSB/uT 的測量解析度。
  • 測量頻率不得低於 5 Hz。
  • 測量頻率上限為 50 Hz 以上。
  • 測量噪音必須超過 0.5 uT。

• [C-2-6] 的 TYPE_MAGNETIC_FIELD_UNCALIBRATED 品質規定必須與 TYPE_GEOMAGNETIC_FIELD 相同，此外：

  • 這個感應器必須採用至少 600 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • [C-SR] 如果報表速率為 50 Hz 以上，強烈建議使用從 1 Hz 到至少 10 Hz 的白雜訊頻譜。

• [C-2-7] 必須具備下列功能的TYPE_PRESSURE感應器：

  • 測量範圍必須介於 300 到 1100 hPa 之間。
  • 必須採用至少 80 LSB/hPa 的測量解析度。
  • 測量頻率不得低於 1 Hz。
  • 測量頻率上限為 10 Hz。
  • 測量噪音必須不能超過 2 Pa/√Hz。
  • 這個感應器必須採用至少 300 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 批次耗電量不得低於 2 mW。
• [C-2-8] 必須搭配 TYPE_GAME_ROTATION_VECTOR 感應器。
• [C-2-9] 必須使用 TYPE_SIGNIFICANT_MOTION 感應器，才能執行以下操作：
  • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
• [C-2-10] 必須搭載 TYPE_STEP_DETECTOR 感應器，才能執行以下操作：
  • 這個感應器必須採用至少 100 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
  • 批次耗電量不得低於 4 mW。
• [C-2-11] 必須搭載下列 TYPE_STEP_COUNTER 感應器：
  • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
• [C-2-12] 必須搭載 TILT_DETECTOR 感應器，才能執行以下操作：
  • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
• [C-2-13] 同一實體事件的事件時間戳記，必須間隔於兩者間隔 2.5 毫秒以內。針對加速計和陀螺儀，相同實體事件的事件時間戳記，兩者相差不多 0.25 毫秒。
• [C-2-14] 「陀螺儀」感應器事件的時間戳記必須與相機子系統相同，且在 1 毫秒內發生錯誤。
• [C-2-15] 從上述任何實體感應器可取得資料時，「必須」在 5 毫秒內將範例提供給應用程式。
• [C-2-16] 當裝置處於靜態狀態時，當裝置處於靜止狀態時「不得」高於 0.5 mW；在啟用以下任何感應器組合的情況下，裝置在移動時「不得」超過 2.0 mW：
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] 可能具有 TYPE_PROXIMITY 感應器，但如果有的話，至少「緩衝區」功能「必須」為 100 個感應器事件。

請注意，本節所述的所有耗電量要求，都不包含「應用程式處理器」的耗電量。其內含整個感應器鏈的力量，包括感應器、輔助電路、任何專用感應器處理系統等。

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

• [C-3-1] 必須透過 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API，正確宣告支援直接管道類型和直接報表率層級。
• [C-3-2] 凡是宣告支援感應器直接通道的感應器，都必須支援至少兩種感應器直接通道類型之一。
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• 針對以下類型的主要感應器 (非喚醒變化版本)，支援透過感應器直接管道回報事件：
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10。生物特徵辨識感應器

如需評估生物特徵辨識解鎖安全性的其他背景資訊，請參閱測量生物特徵辨識安全性說明文件。

如果實作的裝置包含安全螢幕鎖定，他們會：

• 應包含生物特徵辨識感應器

生物特徵辨識感應器可以根據假冒和冒名接受率，以及生物特徵辨識管道的安全性，區分為強、低或便利類別。這種分類會決定生物特徵辨識感應器與平台和第三方應用程式之間的介面功能。根據預設，感應器會歸類為「便利性」。此外，感應器要分類為「弱」或「強」，必須符合以下所述的額外規定。「弱」和「強」生物特徵辨識功能都會取得額外功能，詳情請參閱下文。

如要為第三方應用程式提供生物特徵辨識感應器，裝置實作方式如下：

• [C-0-1] 必須符合本文件中定義的高或低生物特徵辨識規定。

如要允許第三方應用程式存取 KeyStore 金鑰，裝置實作方式如下：

• [C-0-2] 必須符合本文件中定義的「強」規定。

其他規範事項如下：

• [C-0-3] 必須搭配明確的確認動作 (例如按下按鈕) 與強對生物特徵辨識進行配對 (例如沒有明確表示使用者意圖的臉部或鳶尾花)。
  • [C-SR] 「強烈」建議我們加強被動式生物特徵辨識的確認動作，避免作業系統或核心入侵行為以假冒為目標。舉例來說，根據實體按鈕的確認動作，會透過安全元素 (SE) 的純輸入/輸出 (GPIO) 接腳轉送，該接腳不得以按下實體按鈕以外的任何方式驅動。

如果您想將生物特徵辨識感應器視為便利，可以對裝置的實作設定採取下列做法：

• [C-1-1] 不正確的接受率必須低於 0.002%。
• [C-1-2] 比起高強度的 PIN 碼、解鎖圖案或密碼，此模式的安全性可能較低。如果詐騙者的接受率高於 7%，則必須明確列舉啟用此模式的風險。
• [C-1-3] 如果進行 5 次生物特徵辨識驗證，則必須嘗試提供至少 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 碼、解鎖圖案、密碼)，以及每 72 小時 (適用於從舊版 Android 版本升級的裝置) 一次。

• [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] 「必須」具備硬體支援的 KeyStore 實作項目，並在 Android 使用者或核心空間 (例如受信任的執行環境 (TEE)) 以外的獨立執行環境 (例如受信任的執行環境 (TEE)) 或具備獨立執行環境安全通道的晶片中執行生物特徵辨識比對。
• [C-2-4] 所有識別資料都必須經過加密及加密驗證，才能在獨立執行環境外取得、讀取或修改，也不能使用安全管道搭配隔離執行環境的晶片 (如 Android 開放原始碼專案網站上的實作指南所述)。
• [C-2-5] 針對相機型生物特徵辨識，正在進行生物特徵辨識驗證或註冊：
  • 「務必」在以下模式下操作攝影機，避免相機影格在隔離執行環境外讀取或修改，或是使用安全通道的晶片，進入獨立的執行環境。
  • 如為 RGB 單鏡頭解決方案，「CAN」可在獨立執行環境外讀取相機影格，以支援註冊預覽等作業，但「不得」變更。
• [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 MAY 適用於不含電話硬體硬體的裝置。也就是說，Android 與非手機裝置相容。

如果裝置實作包含 GSM 或 CDMA 電話，則：

• [C-1-1] 必須根據技術宣告 android.hardware.telephony 功能旗標和其他子功能旗標。
• [C-1-2] 「必須」針對該技術導入完整的 API 支援。

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

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

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

• [C-3-1] 必須提供完整的 EuiccManager API 實作。

7.4.1.1。號碼封鎖相容性

如果裝置導入方式回報 android.hardware.telephony feature，就會：

• [C-1-1] 必須支援電話號碼封鎖功能
• [C-1-2] 必須完全導入 BlockedNumberContract 和 SDK 說明文件中對應的 API。
• [C-1-3] 必須封鎖「BlockingNumberProvider」中來自電話號碼的所有來電和訊息完全不必與應用程式互動唯一的例外狀況是我們依照 SDK 說明文件中的規定暫時撤銷電話號碼封鎖。
• [C-1-4] 對於已封鎖的通話，「不得」寫入平台通話記錄供應商。
• [C-1-5] 「請勿」針對已封鎖的訊息傳送訊息給電話供應商。
• [C-1-6] 必須實作已封鎖的電話號碼管理 UI，該 UI 是透過 TelecomManager.createManageBlockedNumbersIntent() 方法傳回的意圖開啟。
• [C-1-7] 「不得」允許次要使用者查看或編輯裝置上已封鎖的號碼，因為 Android 平台會假設主要使用者俱備裝置的電話服務完整控制權。「必須」對次要使用者隱藏所有封鎖相關使用者介面，且仍須遵守封鎖清單。
• 當裝置更新至 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] 強烈建議你通知使用者接聽來電後，通話就會結束。

  Android 開放原始碼計畫實作項目可透過抬頭通知達成這些規定，並在使用者接聽來電後造成其他通話遭到捨棄。

• [C-SR] 強烈建議在第三方應用程式將 PhoneAccount 上的 EXTRA_LOG_SELF_MANAGED_CALLS 額外鍵設為 true 時，預先載入預設撥號應用程式，該應用程式會顯示通話記錄項目和第三方應用程式的名稱。

• [C-SR] 極力建議您為 android.telecom API 處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，如下所示：
  • 在通話期間偵測到短暫按下按鍵事件時，呼叫 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] 必須回報硬體功能旗標 android.hardware.wifi。
• [C-1-3] 必須按照 SDK 說明文件中所述導入多點傳播 API。
• [C-1-4] 必須支援多點傳送 DNS (mDNS)，且在作業期間一律「不得」篩選 mDNS 封包 (224.0.0.251)，包括：
  • 即使螢幕未處於使用中狀態也一樣。
  • 適用於 Android TV 裝置實作，即使處於待機狀態也一樣。
• [C-1-5] 不得將 WifiManager.enableNetwork() API 方法呼叫視為足以切換應用程式流量目前預設使用中的 Network，且是由 getActiveNetwork 和 registerDefaultNetworkCallback 等 API 方法傳回。ConnectivityManager也就是說，只有在其他網路供應商 (例如行動數據) 成功驗證 Wi-Fi 網路可正常提供網際網路的情況下，他們「才能」停用其網際網路連線。
• [C-1-6] 強烈建議「強烈建議」在呼叫 ConnectivityManager.reportNetworkConnectivity() API 方法時重新評估 Network 上的網際網路存取權。如果評估結果判斷目前的 Network 不再提供網際網路，請切換至其他提供網際網路的可用網路 (例如行動數據網路)。
• [C-SR] 極力建議在每次掃描作業開始時隨機隨機處理來源 MAC 位址和探測要求影格的序號，一次掃描一次，但 STA 則處於中斷連線狀態。
  • 包含一次掃描作業的每組探測要求框架，都應使用一個一致的 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) 並生效時，盡可能降低 Wi-Fi 封包往返延遲時間。

如果裝置的實作功能支援 Wi-Fi 並使用 Wi-Fi 掃描位置，請按照下列步驟操作：

• [C-2-1] 必須為使用者提供需求，以啟用/停用透過 WifiManager.isScanAlwaysAvailable API 方法讀取的值。

7.4.2.1。Wi-Fi Direct

裝置實作方式：

• 應提供 Wi-Fi Direct (Wi-Fi 點對點) 支援。

如果裝置的實作支援 Wi-Fi Direct，請採取下列行動：

• [C-1-1] 必須按照 SDK 說明文件所述，實作對應的 Android API。
• [C-1-2] 必須回報 android.hardware.wifi.direct 硬體功能。
• [C-1-3] 必須支援一般 Wi-Fi 運作。
• [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。

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

裝置實作方式：

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

如果裝置實作項目支援 TDLS，且 Wi-FiManager API 已啟用 TDLS，應用程式就會：

• [C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。
• 請只在可能且有利的情況下使用 TDLS。
• 「不應」使用一些經驗法則，並「不要」使用 TDLS (因為網路效能可能比使用 Wi-Fi 存取點更高)。

7.4.2.3。Wi-Fi 偵測

裝置實作方式：

• 應提供 Wi-Fi Aware 支援。

如果裝置的實作項目支援 Wi-Fi Aware 功能，並向第三方應用程式公開相關功能，那麼：

• [C-1-1] 必須按照 SDK 說明文件中所述導入 WifiAwareManager API。
• [C-1-2] 必須宣告 android.hardware.wifi.aware 功能標記。
• [C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
• [C-1-4] 啟用 Wi-Fi Aware 時，「必須」以不超過 30 分鐘的間隔隨機為 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 時) 與存取點之間，請務必為每個執行 RTT 突發的突發來源 MAC 位址隨機化來源 MAC 位址。

7.4.2.6。Wi-Fi 保持運作卸載

裝置實作方式：

• 應提供 Wi-Fi 保持運作卸載支援。

如果實作的裝置支援 Wi-Fi 保持運作卸載功能，並向第三方應用程式公開相關功能，那麼：

• [C-1-1] 必須支援 SocketKeepAlive API。

• [C-1-2] 必須支援透過 Wi-Fi 連線至少三個並行的保持運作運算單元，以及至少一個保持運作狀態的運算單元。

如果裝置的實作不支援 Wi-Fi 保持運作卸載功能，就會：

• [C-2-1] 必須傳回 ERROR_UNSUPPORTED。

7.4.2.7。Wi-Fi 輕鬆連線 (裝置佈建通訊協定)

裝置實作方式：

• 應支援 Wi-Fi 輕鬆連線 (DPP)。

如果實作的裝置支援 Wi-Fi 輕鬆連線，並且向第三方應用程式公開相關功能，那麼：

• [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] 必須啟用 SDK 說明文件和 android.bluetooth 中所述的 GATT (一般屬性設定檔) 式藍牙 API。
• [C-3-3] 請務必回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，指出是否已導入 ScanFilter API 類別的篩選邏輯。
• [C-3-4] 請務必回報 BluetoothAdapter.isMultipleAdvertisementSupported() 的正確值，指出是否支援低功耗廣告。
• 實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。
• 應支援將批次掃描卸載到藍牙晶片組。

• 應支援至少有 4 個版位的多廣告。

• [SR] 強烈建議你導入可撤銷私人網址 (RPA) 逾時時間不得超過 15 分鐘，並在逾時時輪替網址，以保護使用者隱私。

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

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

如果實作的裝置支援藍牙 LE 和助聽器設定檔 (如使用藍牙 LE 的助聽器音訊支援一節所述)，即可：

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

7.4.4。近距離無線通訊

裝置實作方式：

• 應包括適用於近距離無線通訊 (NFC) 的收發機和相關硬體。
• [C-0-1] 即使類別不支援 NFC 或宣告 android.hardware.nfc 功能，這些 API 仍必須導入 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)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC 論壇標記類型 1、2、3、4、5 (由 NFC 論壇定義)

• [SR] 強烈建議能夠根據以下 NFC 標準讀取和寫入 NDEF 訊息，以及原始資料。請注意，雖然 NFC 標準明確表示「建議做法」，但未來版本的相容性定義將改為「必須」。這些標準對這個版本而言是選用項目，但在日後推出的版本中也是必要條件。目前搭載此 Android 版本的現有裝置和新裝置都非常積極符合相關規定，因此能夠升級至未來發布的平台版本。

• [C-1-13] 在 NFC 探索模式下，「必須」輪詢所有支援的技術。

• 當裝置處於啟用狀態且螢幕鎖定時，應使用 NFC 探索模式。
• 應能讀取 Thinfilm NFC 條碼產品的條碼和網址 (如果經過編碼)，

請注意，上述的 JIS、ISO 和 NFC 論壇規格並未提供公開連結。

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

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

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

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

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

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

• [C-4-1] 必須按照 Android SDK 的說明實作對應的 Android API。
• [C-4-2] 「必須」透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這並非標準的 Android 功能，因此不會做為 android.content.pm.PackageManager 類別中的常數。

7.4.5。最低網路功能

裝置實作方式：

• [C-0-1] 必須支援一或多種資料網路。具體來說，裝置實作項目「必須」支援至少一項支援 200 Kbit/秒以上的資料標準。例如 EDGE、HSPA、EV-DO、802.11g、乙太網路和藍牙 PAN，
• 此外，在以實體網路標準 (例如乙太網路) 做為主要數據連線的情況下，至少應支援一項通用無線資料標準，例如 802.11 (Wi-Fi)。
• 可以導入多種形式的數據連線。
• [C-0-2] 必須納入 IPv6 網路堆疊，並支援使用代管 API (例如 java.net.Socket 和 java.net.URLConnection) 和原生 API (例如 AF_INET6 通訊端) 的 IPv6 通訊。
• [C-0-3] 預設為啟用 IPv6。
• 「必須」確保 IPv6 通訊可靠做為 IPv4，例如：
  • [C-0-4] 必須在打盹模式下維持 IPv6 連線。
  • [C-0-5] 頻率限制「不得」會造成裝置在符合 IPv6 規範的網路中，無法使用 RA 生命週期至少 180 秒的 IPv6 連線。
• [C-0-6] 連線至 IPv6 網路時，「必須」向第三方應用程式提供直接 IPv6 連線功能的網路，且不得在裝置上進行任何形式的位址或通訊埠轉譯。Socket#getLocalAddress 或 Socket#getLocalPort 等代管 API，以及 getsockname() 或 IPV6_PKTINFO 等 NDK API，都「必須」傳回實際用於在網路上收發封包的 IP 位址和通訊埠。

所需的 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] 強烈建議提供數據節省模式。

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

• [C-1-1] 必須支援 ConnectivityManager 類別中的所有 API，如 SDK 說明文件所述
• [C-1-2] 「必須」在設定中提供處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖的使用者介面，允許使用者將應用程式新增至許可清單，或從許可清單中移除應用程式。

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

• [C-2-1] 必須傳回 ConnectivityManager.getRestrictBackgroundStatus() 的值 RESTRICT_BACKGROUND_STATUS_DISABLED
• [C-2-2] 「不得」廣播「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.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，明確啟用閃光燈，否則手電筒「不得」亮起 android.hardware.Camera.PreviewCallback 例項，除非應用程式已在相機預覽表面註冊 android.hardware.Camera.PreviewCallback 例項。請注意，這項限制不適用於裝置的內建系統相機應用程式，但僅適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2。前置鏡頭

前置鏡頭是指與螢幕位於裝置同一側的相機。也就是說，通常用於拍攝使用者的影像，像是用於視訊會議和類似的應用程式。

裝置實作方式：

• 可使用前置鏡頭。

如果裝置的實作方式至少包含一個前置鏡頭，這些裝置會：

• [C-1-1] 必須回報功能標記 android.hardware.camera.any 和 android.hardware.camera.front。
• [C-1-2] 解析度至少須為 VGA (640x480 像素)。
• [C-1-3] 「不得」使用前置鏡頭做為 Camera API 的預設後置鏡頭，且「不得」將 API 設為預設後置鏡頭，即使該裝置是裝置上唯一的鏡頭。
• [C-1-4] 當目前應用程式明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法旋轉相機螢幕時，相機預覽「必須」以應用程式所指定的方向水平鏡像翻轉。相反地，如果目前應用程式未明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法旋轉相機螢幕，預覽畫面「必須」沿著裝置的預設水平軸鏡像翻轉。
• [C-1-5] 「不得」反映傳回至應用程式回呼或承諾用於媒體儲存空間的最終擷取靜態影像或影片串流。
• [C-1-6] 「必須」按照相機預覽圖像串流的形式，鏡像投射後檢視畫面所顯示的圖像。
• 可包含後置鏡頭可用的功能 (例如自動對焦、閃光燈等)，如第 7.5.1 節所述。

如果裝置導入方式可由使用者旋轉 (例如透過加速計自動運作，或透過使用者輸入操作手動旋轉)：

• [C-2-1] 相機預覽畫面「必須」根據裝置目前的螢幕方向水平鏡像。

7.5.3.外接鏡頭

裝置實作方式：

• 不一定能隨時連接外接鏡頭，

如果裝置的實作支援外部攝影機，這些裝置會：

• [C-1-1] 必須宣告平台功能旗標 android.hardware.camera.external 和 android.hardware camera.any。
• [C-1-2] 如果外接攝影機透過 USB 主機連接埠連接，則必須支援 USB 視訊類別 (UVC 1.0 以上版本)。
• [C-1-3] 必須通過連接實體外接鏡頭裝置的相機 CTS 測試。如要進一步瞭解相機 CTS 測試，請前往 source.android.com。
• 應支援 MJPEG 等影片壓縮，以便傳輸高畫質的未編碼串流 (即原始或獨立壓縮的影像串流)。
• 支援多部相機。
• 支援相機式影片編碼。

如果支援相機式影片編碼：

• [C-2-1] 裝置實作必須能存取同時未編碼 / MJPEG 串流 (QVGA 或更高解析度)。

7.5.4。Camera API 行為

Android 提供兩種 API 套件來存取相機，新版 android.hardware.camera2 API 提供應用程式較低層級的相機控制功能，包括高效率的零複製爆發/串流流程，以及曝光、增益、白平衡增加、色彩轉換、雜訊、銳化等每個畫面的控制選項。

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

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

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

• [C-0-1] 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則必須使用 android.hardware.PixelFormat.YCbCr_420_SP 做為提供給應用程式回呼的預覽資料。
• [C-0-2] 當應用程式註冊 android.hardware.Camera.PreviewCallback 執行個體，且系統會呼叫 onPreviewFrame() 方法且預覽格式為 YCbCr_420_SP 時，必須進一步採用 NV21 編碼格式，而預覽格式是 YCbCr_420_SP，也就是傳遞到 onPreviewFrame() 的位元組 [] 資料。也就是說，必須預設為 NV21。
• [C-0-3] 一律支援 android.hardware.Camera 的前置和後置鏡頭的 YV12 格式 (如 android.graphics.ImageFormat.YV12 常數表示)。(硬體視訊編碼器和攝影機可能會使用任何原生像素格式，但裝置的實作「必須」支援轉換為 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] 必須識別並遵守 android.hardware.Camera.Parameters 類別和 android.hardware.camera2.CaptureRequest 類別中定義為常數的每個參數名稱。相反地，除了在 android.hardware.Camera.Parameters 上記錄為常數的字串常數以外，裝置實作項目「不得」遵循或識別傳送至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作項目「必須」支援所有標準相機參數，且「不得」支援自訂的相機參數類型。舉例來說，如果裝置的實作方式支援使用高動態範圍 (HDR) 影像技術擷取相片，就「必須」支援相機參數 Camera.SCENE_MODE_HDR。
• [C-0-7] 必須按照 Android SDK 中的說明，使用 android.info.supportedHardwareLevel 屬性回報適當的支援等級，並回報適當的架構功能旗標。
• [C-0-8] 也必須透過 android.request.availableCapabilities 屬性宣告 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標。如果裝置隨附的相機裝置支援此功能，「必須」定義功能旗標。
• [C-0-9] 每當相機拍攝新相片，並將圖片項目新增至媒體儲存區時，都必須播送 Camera.ACTION_NEW_PICTURE 意圖。
• [C-0-10] 每當相機錄製新影片，並將圖片項目新增至媒體儲存區時，都必須廣播 Camera.ACTION_NEW_VIDEO 意圖。
• [C-0-11] 必須讓所有相機都能透過已淘汰的 android.hardware.Camera API 存取，也可以透過 android.hardware.camera2 API 存取。
• [C-SR] 如果裝置有多個 RGB 相機朝同一方向，我們強烈建議支援列出功能 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 的邏輯相機裝置，包括所有面向實體的 RGB 相機。

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

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

7.5.5。相機方向

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

• [C-1-1] 請清楚顯示相機的長邊，讓相機的長邊對齊螢幕的長邊。也就是說，當裝置保持橫向時，相機「必須」拍攝橫向的照片。這不受裝置的自然方向影響；適用於橫向和直向主要裝置

7.6.記憶體與儲存空間

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

裝置實作方式：

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

7.6.2。應用程式共用儲存空間

裝置實作方式：

• [C-0-1] 「必須」提供應用程式共用儲存空間 (通常稱為「共用外部儲存空間」或「應用程式共用儲存空間」)或 Linux 路徑「/sdcard」與掛接的
• [C-0-2] 必須設定預設的共用儲存裝置，也就是「立即可用」，不論儲存空間是實作在內部儲存元件或卸除式儲存媒介上 (例如安全數位卡插槽)。
• [C-0-3] 必須直接在 Linux 路徑 sdcard 上安裝應用程式共用儲存空間，或加入從 sdcard 到實際掛接點的 Linux 符號連結。
• [C-0-4] 必須如 SDK 中記錄，對這個共用儲存空間強制執行 android.permission.WRITE_EXTERNAL_STORAGE 權限。
• [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 卡)，或是在購買時，顯示需要另外購買儲存媒介的包裝盒和其他材料。

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

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

如果裝置的實作含有多個共用儲存空間路徑 (例如 SD 卡插槽和共用內部儲存空間)，這些路徑：

• [C-2-1]「必須」只允許預先安裝及具有 WRITE_MEDIA_STORAGE 權限的 Android 應用程式寫入次要外部儲存空間，但寫入套件專屬目錄或啟動 ACTION_OPEN_DOCUMENT_TREE 意圖後傳回的 URI 除外。
• [C-2-2] 必須要求只有在同時獲得 android.permission.WRITE_EXTERNAL_STORAGE 權限時，才可將與 android.permission.WRITE_MEDIA_STORAGE 權限相關的直接存取權授予使用者可見的應用程式。
• [SR] 強烈建議：預先安裝和具有特殊權限的 Android 應用程式會使用公用 API (例如 MediaStore) 與儲存裝置互動，而不是依賴 android.permission.WRITE_MEDIA_STORAGE 授予的直接存取權。

如果裝置實作項目具備支援 USB 週邊裝置模式的 USB 連接埠，就會：

• [C-3-1] 「必須」提供從主機電腦上存取應用程式共用儲存空間資料的機制。
• 應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，以公開透明的方式顯示這兩個儲存空間路徑的內容。
• 「可能」使用 USB 大量儲存裝置，但「應該」使用媒體傳輸通訊協定以滿足這項需求。

如果裝置的實作具備具備 USB 週邊裝置模式的 USB 連接埠，並支援媒體傳輸通訊協定，請注意：

• 必須與參考 Android MTP 主機的 Android 檔案傳輸應用程式相容。
• 必須回報 0x00 的 USB 裝置類別。
• 請回報「MTP」的 USB 介面名稱。

7.6.3.採用儲存空間

如果裝置應為行動裝置的性質與電視不同，其導入方式如下：

• [SR] 強烈建議你長期在穩定的位置導入可用的儲存空間，因為意外中斷連線可能會導致資料遺失/損毀。

如果卸除式儲存裝置連接埠位於長期穩定的位置 (例如電池座或其他保護蓋)，裝置的實作方式如下：

• [SR] 強烈建議導入採用儲存空間。

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] 「應該」導入相關支援，在 HS 晶片期間繪製 1.5 A 電流，並按照 USB 電池充電規格 (修訂版本 1.2 版本) 規定繪製。我們會強烈建議現有和新的 Android 裝置符合這些規定，以便升級至未來的平台版本。
• [SR] 強烈建議不要支援專門用來修改 Vbus 電壓以外的充電方法，或是更改接收器/來源角色，這樣可能會導致支援標準 USB Power Delivery 方法的充電器或裝置發生互通性問題。雖然這種做法稱為「強烈建議」，但在日後的 Android 版本中，我們可能會要求所有 Type-C 裝置支援與標準 C 型充電器完全互通。
• [SR] 強烈建議在支援 Type-C USB 和 USB 主機模式的情況下，支援用於資料傳輸和電源角色交換的 Power Delivery。
• 應支援 Power Delivery 針對高壓充電，並支援螢幕外等替代模式。
• 應導入 Android Open Accessory (AOA) API 和規格，如 Android SDK 說明文件所述。

如果裝置實作包含 USB 連接埠並實作 AOA 規格，則：

• [C-2-1] 必須宣告支援硬體功能 android.hardware.usb.accessory。
• [C-2-2] USB 大量儲存空間級別「必須」包含「android」字串位於介面說明的iInterface USB 大量儲存裝置中

7.7.2。USB 主機模式

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

• [C-1-1] 必須實作 Android SDK 中記錄的 Android USB Host API，且「必須」宣告支援硬體功能 android.hardware.usb.host。
• [C-1-2] 必須「必須」導入支援功能，才能連接標準 USB 週邊裝置，換句話說，裝置必須：
  • 具備裝置端 C 連接埠或隨附傳輸線，可將裝置專屬連接埠調整為標準 USB Type-C 連接埠 (USB Type-C 裝置)。
  • 具有裝置端 A 或隨附傳輸線，可將裝置端專屬連接埠調整為標準的 USB Type-A 連接埠。
  • 具備裝置端 micro-AB 連接埠，且該連接埠應隨附可適應標準 A 型連接埠的傳輸線。
• [C-1-3] 請勿隨附從 USB 型 A 或 micro-AB 連接埠轉換為 Type-C 連接埠 (插座) 的變壓器。
• [C-SR] 極力建議您實作 USB 音訊類別 (如 Android SDK 說明文件所述)。
• 在主機模式下，應支援為已連接的 USB 週邊裝置充電。根據 USB Type-C 傳輸線和連接器規格修訂版本 1.2 (適用於 USB Type-C 連接器) 的終止參數一節，針對 USB Type-C 連接器放送廣告，以及使用充電下游連接埠 (CDP) 輸出目前範圍至少 1.5A (適用於 Micro-AB 連接器的修訂版本 1.2)。
• 應實作並支援 USB Type-C 標準。

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

• [C-2-1] 必須支援 USB HID 類別。
• [C-2-2] 必須支援偵測及對應 USB HID 用量表中指定的下列 HID 資料欄位，以及將語音指令使用要求和 KeyEvent 常數的對應作業，如下所示：
  • 用量頁面 (0xC) 用量 ID (0x0CD)：KEYCODE_MEDIA_PLAY_PAUSE
  • 用量頁面 (0xC) 用量 ID (0x0E9)：KEYCODE_VOLUME_UP
  • 用量頁面 (0xC) 用量 ID (0x0EA)：KEYCODE_VOLUME_DOWN
  • 用量頁面 (0xC) 用量 ID (0x0CF)：KEYCODE_VOICE_ASSIST

如果裝置實作項目包括支援主機模式的 USB 連接埠與儲存空間存取架構 (SAF)，必須採取以下做法：

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

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

• [C-4-1] 必須依照 USB Type-C 規格定義實作雙角色通訊埠功能 (第 4.5.1.3.3 節)。
• [SR] 強烈建議你支援 DisplayPort，也應支援 USB 超級速度資料速率，而且強烈建議支援 Power Delivery 處理資料和替換角色。
• [SR] 強烈建議「不」支援音訊轉接器配件模式，如 USB Type-C 傳輸線和連接器規格修訂版本 1.2 的附錄 A 所述。
• 請採用最適合裝置板型規格的 try.* 型號。例如手持裝置應實作 try.SNK 模型。

7.8.音訊

7.8.1。麥克風

如果裝置實作項目內含麥克風，裝置會：

• [C-1-1] 必須回報 android.hardware.microphone 功能常數。
• [C-1-2] 必須符合第 5.4 節的音訊錄音規定。
• [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
• [SR] 強烈建議支援近乎超音波錄製功能 (如第 7.8.3 節所述)。

如果裝置實作方式省略麥克風，系統會：

• [C-2-1] 「不得」回報 android.hardware.microphone 功能常數。
• [C-2-2] 必須根據第 7 節規定，至少實作音訊錄音 API 為免人工管理。

7.8.2。音訊輸出裝置

如果裝置實作項目包含喇叭，或是音訊輸出週邊裝置的音訊/多媒體輸出連接埠 (例如 4 導體 3.5 公釐耳機插孔，或採用 USB 音訊類別的 USB 主機模式連接埠)，您可以：

• [C-1-1] 必須回報 android.hardware.audio.output 功能常數。
• [C-1-2] 必須符合第 5.5 節的音訊播放規定。
• [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
• [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。類比音訊連接埠

為使用 3.5 公釐音訊插頭與 Android 生態系統相容的耳機和其他音訊配件，如果裝置實作項目包含一或多個類比音訊通訊埠，裝置必須：

• [C-SR] 強烈建議至少加入其中一個音訊連接埠，做為 4 導體 3.5 公釐耳機插孔。

如果裝置實作方式為 4 導體 3.5 公釐耳機插孔，則：

• [C-1-1] 必須支援透過附麥克風的立體聲耳機和立體聲耳機播放音訊。
• [C-1-2] 必須支援 CTIA 輸出順序的 TRRS 音訊插頭。
• [C-1-3] 必須支援偵測及對應按鍵碼，用來偵測麥克風與音訊插頭上下列 3 個範圍同等的阻力。
  • 70 ohm 以下：KEYCODE_HEADSETHOOK
  • 210-290 ohm：KEYCODE_VOLUME_UP
  • 360-680 ohm：KEYCODE_VOLUME_DOWN
• [C-1-4] 在插入插頭時「必須」觸發 ACTION_HEADSET_PLUG，但只有在所有接上電源上的聯絡人在插孔上觸碰到對應的區塊時，才能觸發這個程序。
• [C-1-5] 必須能夠透過 32 毫米喇叭阻抗，駕駛至少 150mV ±10% 的輸出電壓。
• [C-1-6] 麥克風偏壓電壓應介於 1.8V 至 2.9V 之間。
• [C-1-7] 在音訊插頭上，只要裝置具備以下範圍內對應的阻力，必須偵測對應的按鍵碼並對應對應的按鍵碼：
  • 110-180 ohm： KEYCODE_VOICE_ASSIST
• [C-SR] 強烈建議你按照 OMTP 撥出順序支援音訊插頭。
• [C-SR] 強烈建議你透過附麥克風的立體聲耳機支援錄音功能。

如果裝置實作項目具有 4 指導管 3.5 公釐耳機插孔，並支援麥克風，且將額外的麥克風設定為 1，則播送 android.intent.action.HEADSET_PLUG：

• [C-2-1] 必須能偵測已接上電源的音訊配件麥克風。

7.8.2.2。數位音訊連接埠

根據 Android USB 耳機規格的定義，使用 USB-C 連接器並實作 (USB 音訊類別) 至 Android 生態系統中，與耳機和其他音訊配件相容。

如要瞭解裝置專屬的需求，請參閱 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 頻帶中，麥克風的平均功率回應「必須」低於 15 dB (2 kHz)。
• [C-1-2] 麥克風的未加權訊號與雜訊比超過 18.5 kHz 至 20 kHz，在 -26 dBFS 的音色「必須」小於 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

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

7.8.4。信號完整性

裝置實作方式：

• 「應該」為手持裝置的輸入和輸出串流提供無故障的音訊訊號路徑。根據每個路徑測試一分鐘的測試期間所測量到的零故障事件定義。使用 [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester)「Automation Glitch Test」後執行測試。

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

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

效能模式	共享	取樣率	英屬香腸	逃離袖
低延遲	專屬	未指定	1 分	2 分
低延遲	專屬	未指定	2 分	1 分
低延遲	已分享	未指定	1 分	2 分
低延遲	已分享	未指定	2 分	1 分
無	已分享	4,8000 人	1 分	2 分
無	已分享	4,8000 人	2 分	1 分
無	已分享	44,100 人	1 分	2 分
無	已分享	44,100 人	2 分	1 分
無	已分享	16,000 人	1 分	2 分
無	已分享	16,000 人	2 分	1 分

可靠的串流必須符合下列條件，才能達到 2000 Hz 的訊號強度訊號 (SNR) 和 Total Harmonic Distortion (THD)。

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

7.9.虛擬實境

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

7.9.1。虛擬實境模式

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

7.9.2。虛擬實境模式 - 高效能

如果裝置實作支援虛擬實境模式，請按照下列步驟操作：

• [C-1-1] 至少必須有 2 個實體核心。
• [C-1-2] 必須宣告 android.hardware.vr.high_performance 功能。
• [C-1-3] 必須支援持續效能模式。
• [C-1-4] 必須支援 OpenGL ES 3.2。
• [C-1-5] 必須支援 android.hardware.vulkan.level 0。
• 應支援 android.hardware.vulkan.level 1 以上版本。
• [C-1-6] 必須實作 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content、EGL_EXT_image_gl_colorspace，並在可用的 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，並在可用的 GL 擴充功能清單中顯示擴充功能。
• [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 和螢幕「必須」能夠同步處理共用前端緩衝區的存取權，讓兩個影格之間以 60fps 交替顯示 VR 內容，在沒有可見的撕裂痕跡的情況下無法顯示。
• [C-1-9] 必須按照 NDK 中所述，為 AHardwareBuffer 標記 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 實作支援。
• [C-1-10] 必須導入 AHardwareBuffer 支援功能與使用旗標 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT，至少要採用以下格式：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
• [C-SR] 強烈建議支援透過 C-1-10 指定多個圖層和標記和格式的 AHardwareBuffer 配置。
• [C-1-11] 必須支援以 3840 x 2160 解析度 (每秒 30 個影格) 的 H.264 解碼器，平均壓縮至 40 Mbps (相當於 4 個 1920 x1080 且 30 fps-10 Mbps 或 1080 x 10 Mbps 的 2 個執行個體)。
• [C-1-12] 必須支援 HEVC 和 VP9，必須能夠解碼至少 1920 x 1080 (每秒 30 個影格) 的編碼，平均壓縮為 10 Mbps，且 應該能夠將 3840 x 2160 解碼為 3840 x 2160 (每秒 30 Mbps 至 10 每秒 30 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 Data Length Extension第 7.4.3 節。
• [C-1-19] 必須針對下列所有預設感應器類型，支援並正確回報直接管道類型：
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] 強烈建議針對上述所有直接管道類型支援 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 檔案。
• 隨機寫入效能。計算方法是使用 4 KB 寫入緩衝區寫入 256 MB 檔案。
• 依序讀取效能。使用 10 MB 寫入緩衝區讀取 256 MB 檔案來評估。
• 隨機讀取效能。使用 4 KB 寫入緩衝區讀取 256 MB 檔案來評估。

8.3.省電模式

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

• [C-1-1] 「不得」偏離於 Android 開放原始碼計畫實作項目，用於觸發、維護、喚醒演算法，以及「應用程式待命」和「打盹」模式的全域系統設定。
• [C-1-2] 「不得」偏離 Android 開放原始碼計畫實作項目，因為使用全域設定來管理應用程式待命時，每個值區中的應用程式工作節流、警報和網路節流情形。
• [C-1-3] 不得偏離 Android 開放原始碼計畫實作項目，例如用於應用程式待命的應用程式待命值區數量。
• [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 狀態。

  相反地，如果第三方應用程式需要系統資源 (如本 SDK 所述)，則「必須」退出 S3 狀態。

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

8.4.耗電量會計

更準確的耗電量計算和耗電量報告，能為應用程式開發人員提供獎勵和最佳化應用程式耗電量模式的工具。

裝置實作方式：

• [SR] 強烈建議提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及特定元件隨時間變化的約略電量 (如 Android 開放原始碼計畫網站上所述)。
• [SR] 強烈建議以毫秒 (mAh) 為單位回報所有耗電量的值。
• [SR] 強烈建議採用每個程序 UID 回報的 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [SR] 強烈建議透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供此電源用量。
• 如果無法將硬體元件的電力用量歸功於應用程式，則必須註明硬體元件本身。

8.5.一致的效能

高效能長時間執行的應用程式可能會因為溫度限製而在背景中執行其他應用程式，或 CPU 節流，造成應用程式效能大幅波動。Android 內含程式輔助介面，因此在裝置支援時，頂層前景應用程式就可以要求系統最佳化資源分配方式，以因應這類波動。

裝置實作方式：

• [C-0-1] 請務必透過 PowerManager.isSustainedPerformanceModeSupported() API 方法正確回報永續效能模式的支援情況。

• 應持續推動效能模式。

如果裝置導入資料回報支援持續性效能模式，則表示：

• [C-1-1] 必須在應用程式要求時，為頂層前景應用程式提供至少 30 分鐘的穩定效能。
• [C-1-2] 必須遵循 Window.setSustainedPerformanceMode() API 和其他相關 API。

如果裝置的實作項目包含兩個以上的 CPU 核心，則會造成：

• 您至少應提供一個可由頂層前景應用程式保留的專屬核心。

如果裝置實作支援為頂層前景應用程式保留一個專屬核心，就會執行以下動作：

• [C-2-1] 必須透過 Process.getExclusiveCores() API 方法回報，頂端前景應用程式可保留的專屬核心 ID 數量。
• [C-2-2] 「不得」允許任何使用者空間處理程序，除非應用程式所使用的裝置驅動程式在專屬核心上執行，但允許某些核心程序在必要時執行。

如果裝置實作項目不支援專屬核心，就會：

• [C-3-1] 「必須」透過 Process.getExclusiveCores() API 方法傳回空白清單。

9. 安全性模型相容性

裝置實作方式：

• [C-0-1] 必須實作 Android 開發人員說明文件中 API 安全性和權限參考文件所定義的安全性模型，以符合 Android 平台的安全性模型。

• [C-0-2] 必須支援安裝自行簽署的應用程式，不需要任何第三方/主管機關提供額外權限/憑證。具體而言，相容裝置「必須」支援下列子節所述的安全性機制。

9.1.權限

裝置實作方式：

• [C-0-1] 必須支援 Android 開發人員說明文件中定義的 Android 權限模型。具體來說，這些權限「必須」強制執行 SDK 說明文件中定義的各項權限。亦不得省略、修改或略過任何權限。

• 如果新的權限 ID 字串不在 android.\* 命名空間中，可以新增其他權限。

• [C-0-2] 只有 protectionLevel 為 PROTECTION_FLAG_PRIVILEGED 的權限，「必須」只授予已安裝在系統映像檔的特殊權限路徑中，以及每個應用程式明確加入許可清單權限的子集。Android 開放原始碼計畫實作項目符合這項規定，方法是透過 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 服務中所述同等或防護的安全硬體，可避免裝置受到暴力攻擊。

裝置實作方式：

• [C-0-7] 如果應用程式透過標準 Android API 或專屬機制要求位置或體能活動資料，必須遵循 Android 位置存取權屬性。這類資料包括但不限於：

  • 裝置的所在位置 (例如經緯度)。
  • 可用於判斷或推測裝置所在位置的資訊 (例如 SSID、BSSID、行動網路 ID、藍牙掃描，或裝置連線的網路位置)。
  • 使用者的體能活動或體能活動分類。

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

• [C-0-8] 必須取得使用者同意，應用程式才能存取位置或體能活動資料。
• [C-0-9] 必須「只」授予執行階段權限，「只有」符合 SDK 所述足夠權限的應用程式。舉例來說，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION。

權限可標示為受限制改變其行為。

• [C-0-10] 除非以下情況，否則「不得」將標有「hardRestricted」標記的權限授予應用程式：

  • 應用程式 APK 檔案位於系統分區中。
  • 使用者將與 hardRestricted 權限相關聯的角色指派給應用程式。
  • 安裝程式將 hardRestricted 授予應用程式。
  • 應用程式獲得舊版 Android 的 hardRestricted。

• [C-0-11] 擁有 softRestricted 權限的應用程式「必須」只能獲得有限存取權，且「不得」取得完整存取權，直到按照 SDK 所述將許可清單加入許可清單。許可清單中所述的個別 softRestricted 權限定義了完整與有限的存取權 (例如 WRITE_EXTERNAL_STORAGE 和 READ_EXTERNAL_STORAGE)。

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

• [SR] 強烈建議提供使用者可存取的機制，針對宣告 android.permission.PACKAGE_USAGE_STATS 權限的應用程式提供 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，以回應或撤銷使用統計資料的存取權。

如果裝置實作方式禁止任何應用程式 (包括預先安裝的應用程式) 存取使用統計資料，將採取下列做法：

• [C-1-1] 「必須」仍有處理 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖模式的活動，但「必須」將此模式實作為免人工管理，此行為等同於使用者拒絕存取時的行為。

9.2.UID 與程序隔離

裝置實作方式：

• [C-0-1] 必須支援 Android 應用程式沙箱模型，在這個模型中，每個應用程式都會以專屬 Unix 樣式 UID 執行，並以獨立的程序執行。
• [C-0-2] 必須支援以同一個 Linux 使用者 ID 執行多個應用程式，前提是已根據安全性和權限參考資料中的定義妥善簽署及建構應用程式。

9.3.檔案系統權限

裝置實作方式：

• [C-0-1] 必須支援「安全性和權限參考資料」中定義的 Android 檔案存取權限模型。

9.4.替代執行環境

裝置實作項目必須維持 Android 安全性和權限模型的一致性，即使這類環境使用的執行階段環境使用其他軟體或技術來執行應用程式，而非 Dalvik 可執行格式或原生程式碼也一樣。也就是說：

• [C-0-1] 替代執行階段「必須」是 Android 應用程式，並遵循標準 Android 安全性模型，如第 9 節所述。

• [C-0-2] 「不得」透過 <uses-permission> 在執行階段的 AndroidManifest.xml 檔案中，要求所保護的資源存取權，而其他執行階段以注意力機制為基礎

• [C-0-3] 替代執行階段「不得」允許應用程式使用受 Android 權限保護的功能，僅限系統應用程式使用。

• [C-0-4] 替代執行階段「必須」遵守 Android 沙箱模型，並使用替代執行階段安裝應用程式，除非透過共用使用者 ID 和簽署憑證的標準 Android 機制，重複使用裝置上安裝的任何其他應用程式的沙箱。

• [C-0-5] 其他執行階段「不得」啟動、授予或取得其他 Android 應用程式對應沙箱的存取權。

• [C-0-6] 不得透過超級使用者 (根層級) 或任何其他使用者 ID 的任何權限，啟動、授予其他執行階段，或授予其他應用程式權限。

• [C-0-7] 當裝置實作項目的系統映像檔中包含替代執行階段的 .apk 檔案時，使用的金鑰必須不同於裝置實作過程中用於簽署其他應用程式的金鑰。

• [C-0-8] 安裝應用程式時，替代執行階段「必須」針對應用程式使用的 Android 權限取得使用者同意聲明。

• [C-0-9] 如果應用程式需要使用具有對應 Android 權限的裝置資源 (例如相機、GPS 等)，替代執行階段「必須」告知使用者應用程式將能存取該項資源。

• [C-0-10] 當執行階段環境未以此方式記錄應用程式功能時，執行階段環境在安裝任何使用該執行階段的應用程式時，「必須」列出執行階段本身持有的所有權限。

• 替代執行階段應透過 PackageManager 安裝應用程式，至獨立的 Android 沙箱 (Linux 使用者 ID 等)。

• 替代執行階段可以提供一個 Android 沙箱，由所有使用替代執行階段的應用程式共用。

9.5.多使用者支援

Android 提供多位使用者支援功能，並支援完整的使用者隔離功能。

• 裝置實作項目可能，但若將卸除式媒體用於主要外部儲存空間，則不應啟用多位使用者。

如果裝置的實作方式包含多位使用者，這些使用者：

• [C-1-1] 必須符合下列多使用者支援服務相關要求。
• [C-1-2] 必須為每個使用者實作與 API 中安全性和權限參考文件中定義的 Android 平台安全性模型一致的安全性模型。
• [C-1-3] 每個使用者執行個體都必須有獨立且獨立的共用應用程式儲存空間 (又稱 /sdcard) 目錄。
• [C-1-4] 必須確保其他使用者擁有且代表特定使用者擁有的應用程式無法列出、讀取或寫入任何其他使用者擁有的檔案，即使這兩個使用者的資料都儲存在相同的磁碟區或檔案系統中亦然。
• [C-1-5] 啟用多使用者功能時，如果裝置採用的金鑰只儲存在系統可存取的卸除式媒體上，「必須」加密 SD 卡的內容，前提是裝置實作項目為外部儲存 API 使用卸除式媒體。由於這會使主機電腦無法讀取媒體，就必須改用 MTP 或類似的系統，讓主機電腦可以存取目前使用者資料。

9.6.付費簡訊警告

Android 支援針對任何傳出的付費簡訊警告使用者。付費簡訊是傳送給向電信業者註冊的服務的簡訊，可能要向使用者收取相關費用。

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

• [C-1-1] 傳送簡訊給裝置上 /data/misc/sms/codes.xml 檔案中定義的規則運算式指定號碼前，必須先警告使用者。上游 Android 開放原始碼計畫提供符合這項規定的實作項目。

9.7.安全性功能

裝置實作「必須」確保核心和平台的安全性功能符合下述規定。

Android Sandbox 內含以下功能：採用安全增強式 Linux (SELinux) 的必要存取控制 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全性功能。裝置實作方式：

• [C-0-1] 即使在 Android 架構下已實作 SELinux 或任何其他安全性功能，仍必須維持與現有應用程式的相容性。
• [C-0-2] 當系統偵測到安全性違規行為，並成功由 Android 架構底下的安全性功能封鎖時，「不得」顯示使用者介面，但「可能」會在出現未成功安全性的違規行為，導致漏洞遭人成功利用時，顯示使用者介面。
• [C-0-3] 不得將使用者或應用程式開發人員設為 Android 架構下實作的 SELinux 或任何其他安全性功能。
• [C-0-4] 不得允許透過 API (例如 Device 管理 API) 影響其他應用程式的應用程式，設定破壞相容性的政策。
• [C-0-5] 請將媒體架構分成多個程序，以配合 Android 開放原始碼計畫網站上的所述，縮小各程序的存取權範圍。
• [C-0-6] 「必須」實作核心應用程式沙箱機制，才能使用多執行緒程式中可設定的政策篩選系統呼叫。上游 Android 開放原始碼專案符合這項規定，方法是按照 source.android.com 的「核心設定」一節所述，啟用 seccomp-BPF 搭配執行緒群組同步處理 (TSYNC)。

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

• [C-0-7] 必須實作核心堆疊緩衝區溢位保護機制。這類機制的例子包括 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
• [C-0-8] 必須實施嚴格的核心記憶體防護措施，包括可執行程式碼為唯讀、唯讀資料無法執行且無法寫入，且可寫入資料為不可執行 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
• [C-0-9] 在最初出貨 API 級別 28 以上的裝置上，必須導入靜態和動態物件大小邊界檢查使用者空間與核心空間 (例如 CONFIG_HARDENED_USERCOPY) 之間的副本。
• [C-0-10] 在最初運送 API 級別 28 以上的裝置上在核心模式 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 執行時，「不得」執行使用者空間記憶體。
• [C-0-11] 在最初出貨 API 級別 28 以上的裝置上，不得透過一般使用者副本存取 API (例如硬體 PAN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 以外的核心在核心中讀取或寫入使用者空間記憶體。
• [C-0-12] 如果所有最初運送 API 級別 28 以上的裝置 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0) 的硬體容易受到 CVE-2017-5754 安全漏洞影響，請務必導入核心頁面表格隔離功能。
• [C-0-13] 如果在最初運送 API 級別 28 或以上版本的所有裝置上 (例如 CONFIG_HARDEN_BRANCH_PREDICTOR) 的硬體容易受到 CVE-2017-5715 安全漏洞影響，「必須」導入分支預測機制強化功能。
• [SR] 強烈建議保留只有初始化期間寫入的核心資料 (例如 __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 所述) 啟用 CFI、SCS 和 IntSan。

如果裝置實作項目使用 Linux kernel，請執行以下動作：

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

如果裝置實作的裝置已推出較舊的 Android 版本，且無法透過系統軟體更新符合 [C-1-1] 和 [C-1-5] 需求條件，就可能不受上述規定的限制。

如果裝置實作項目使用 Linux 以外的核心，就會發生以下情形：

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

Android 包含多種攸關裝置安全性的深度防禦功能。

9.8.隱私性佳

9.8.1。使用記錄

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

裝置實作方式：

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

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

裝置實作方式：

• [C-0-2] 只須在 System API 類別 IncidentManager 建立的事件報告中，加入標示為 DEST_AUTOMATIC 的欄位。
• [C-0-3] 如果不是 StatsLog SDK 文件中所述，不得使用系統事件 ID 來記錄任何其他事件。如果記錄了其他系統事件，這些事件可能會使用不同的 Atom ID，範圍介於 100,000 至 200,000 之間。

9.8.2。錄音中

裝置實作方式：

• [C-0-1] 未經使用者同意或未清除持續性通知，「不得」事先預先載入或發布用來將私人資訊 (例如按鍵動作、螢幕上顯示的文字、錯誤報告) 傳送至裝置的軟體元件。

• [C-0-2] 一律透過 MediaProjection 或專屬 API 啟用螢幕投放或螢幕錄製功能，必須顯示並徵得與 Android 開放原始碼計畫相同的使用者明確同意聲明。「不得」向使用者提供可停止顯示使用者同意聲明的選項。

• [C-0-3] 在啟用螢幕投放或螢幕錄製功能時，「必須」持續向使用者顯示通知。Android 開放原始碼計畫可在狀態列中顯示持續性通知圖示，以符合這項規定。

如果裝置實作包含的系統功能會擷取畫面上顯示的內容，以及/或者透過 System 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] 必須事先徵得使用者同意，才能啟用該機制；但如果裝置政策控制器透過 DevicePolicyManager.setAlwaysOnVpnPackage() 啟用 VPN，則使用者不需另外提供同意聲明，但「必須」收到通知。

如果裝置實作方式可滿足使用者需求，開啟「永久連線 VPN」功能：

• [C-3-1] 如果應用程式在 AndroidManifest.xml 檔案中不支援永久連線 VPN 服務，請務必透過將 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 屬性設為 false，停用這位使用者的預設要求。

9.8.5。裝置 ID

裝置實作方式：

• [C-0-1] 必須防止應用程式存取裝置序號及 IMEI/MEID、SIM 卡序號和國際行動裝置訂閱者身分識別 (IMSI)，但應用程式必須符合下列任一條件：
  • 是已簽署的電信業者應用程式，經過裝置製造商驗證。
  • 已授予 READ_PRIVILEGED_PHONE_STATE 權限。
  • 具備 UICC 電信業者權限中定義的電信業者權限。
  • 擁有 READ_PHONE_STATE 權限的裝置擁有者或設定檔擁有者。
  • (僅適用於 SIM 卡序號/ICCID) 根據當地法規，應用程式能偵測訂閱者身分的變化。

9.8.6。內容擷取

Android、透過 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 節權限。

• [C-SR] 強烈建議將內容擷取服務元件分開，例如，請勿將服務或共用程序 ID 與其他系統元件繫結，但下列項目除外：

  • 電話、聯絡人、系統 UI 和媒體

9.8.7。剪貼簿存取權

裝置實作方式：

• [C-0-1] 除非應用程式是預設輸入法編輯器，或目前是聚焦的應用程式，否則「不得」傳回剪貼簿中的剪輯資料 (例如透過 ClipboardManager API)。

9.8.8。地區

裝置實作方式：

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

9.9.資料儲存加密

所有裝置都必須符合第 9.9.1 節的規定。裝置在本文所述前的 API 級別推出，不受第 9.9.2 節和 9.9.3 節所述規定的約束；相反地，這些 API 必須符合 Android 相容性定義說明文件第 9.9 節的規定，這些要求會對應裝置搭載的 API 級別。

9.9.1。直接啟動

裝置實作方式：

• [C-0-1] 即使不支援儲存空間加密，仍必須實作直接啟動模式 API。

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED 意圖仍「必須」播送向直接啟動通知的應用程式傳送裝置加密 (DE) 和憑證加密 (CE) 儲存位置可供使用者使用。

9.9.2。加密規定

裝置實作方式：

• [C-0-1] 如果應用程式是裝置的永久不可移除部分，請將應用程式私人資料 (/data 分區) 以及應用程式共用儲存空間分區 (/sdcard 分區) 加密。
• [C-0-2] 在使用者完成開箱設定體驗時，根據預設，「必須」啟用資料儲存加密功能。
• [C-0-3] 必須導入檔案型加密 (FBE)，符合上述資料儲存加密規定。

9.9.3.檔案型加密

已加密的裝置：

• [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 是進階加密標準與 256 位元加密金鑰長度的進階加密標準，以 XTS 模式操作；金鑰的完整長度為 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] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。

• [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
• [C-1-9] 使用者未指定螢幕鎖定憑證時，CE 金鑰必須繫結至預設密碼。
• [C-1-10] 不得重複，換言之，也就是說，使用者的 CE 或 DE 金鑰不得與其他使用者的 CE 或 DE 金鑰相符。
• [C-1-11] 「必須」使用強制支援的加密方式、金鑰長度和模式。

• [C-SR] 強烈建議使用做為加密繫結至裝置硬體信任根的金鑰來加密檔案系統中繼資料，例如檔案大小、擁有權、模式和擴充屬性 (xattrs)。

• 應啟用預先安裝的必要應用程式 (例如鬧鐘、手機、Messenger) 直接啟動偵測功能。

上游 Android 開放原始碼專案以 Linux kernel「fscrypt」為基礎，提供這項功能的偏好實作方式加密功能。

9.10。裝置完整性

下列規定可確保裝置完整性，清楚呈現裝置完整性。裝置實作方式：

• [C-0-1] 無論系統啟動載入程式狀態是否允許刷新系統映像檔，都必須透過系統 API 方法 PersistentDataBlockManager.getFlashLockState() 正確回報。FLASH_LOCK_UNKNOWN 狀態會保留給從舊版 Android 升級，且這個新的系統 API 方法不存在的裝置實作。

• [C-0-2] 必須支援驗證開機程序，確保裝置完整性。

如果裝置實作的裝置在舊版 Android 中沒有支援驗證開機程序，但無法透過系統軟體更新新增這項功能，則這類實作項目可能不受這項規定的限制。

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

• [C-1-1] 必須宣告平台功能旗標 android.software.verified_boot。
• [C-1-2] 必須在每個啟動序列中執行驗證作業。
• [C-1-3] 「必須」使用不可變更的硬體金鑰 (也就是信任根) 啟動驗證程序，並往至系統分區。
• [C-1-4] 必須導入每個驗證階段，檢查下一階段中所有位元組的完整性和真實性，再在下一個階段執行程式碼。
• [C-1-5] 「必須」根據 NIST 現行的雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 建議，使用驗證演算法做為現行標準。
• [C-1-6] 系統驗證失敗時，「不得」允許完成啟動；除非使用者同意嘗試啟動，否則「一律不得使用」來自未通過驗證儲存區塊的資料。
• [C-1-7] 除非使用者已明確解鎖系統啟動載入程式，否則「不得」允許修改裝置上的已驗證分割區。
• [C-SR] 如果裝置上有多個獨立晶片 (例如無線電、特殊影像處理器)，強烈建議每個晶片的啟動程序在啟動時驗證每個階段。
• [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] 必須回報 ConfirmationPrompt.isSupported() API 的 true。

• [C-3-2] 「必須」確保在 Android 作業系統中執行的程式碼 (包括其核心、惡意或其他內容) 在使用者未進行互動的情況下，才能產生正面回應。

• [C-3-3] 請務必確保使用者能夠審查及核准提示訊息，即使 Android 作業系統 (包括核心) 遭到入侵亦然。

9.11.金鑰和憑證

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在容器中，並透過 KeyChain API 或 Keystore API 將其用於加密編譯作業。裝置實作方式：

• [C-0-1] 至少須允許匯入或產生 8,192 組金鑰。
• [C-0-2] 螢幕鎖定驗證次數「必須」嘗試限制頻率，且「必須」使用指數輪詢演算法。如果嘗試失敗超過 150 次，則每次嘗試時須等待至少 24 小時。
• 不應限制可產生的金鑰數量

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

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

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

• [C-1-5] 必須允許使用者選擇從解鎖狀態轉換至鎖定狀態的睡眠逾時時間，且最短允許的逾時時間上限為 15 秒。

9.11.1.安全的螢幕鎖定和驗證

Android 開放原始碼計畫的實作方式採用分層式驗證模式，其中以知識為根據的主要驗證方式，則由深厚的生物特徵辨識，或採用較低的第三種形式。

裝置實作方式：

• [C-SR] 強烈建議你只將下列其中一種類型設為主要驗證方法：
  • 數字 PIN
  • 英數字元密碼
  • 3x3 點狀格線中的滑動模式

請注意，上述驗證方式稱為本文中建議的主要驗證方式。

如果裝置實作新增或修改建議的主要驗證方式，並採用新的驗證方式來確保螢幕鎖定安全，則新的驗證方式如下：

• [C-2-1] 必須按照「要求驗證使用者金鑰」一節所述，為使用者驗證方式。
• [C-2-2] 必須解鎖第三方開發人員應用程式的所有金鑰，才能在使用者解鎖安全螢幕鎖定畫面時使用。舉例來說，第三方開發人員應用程式「必須」能透過相關 API (例如 createConfirmDeviceCredentialIntent 和 setUserAuthenticationRequired) 提供所有金鑰。

如果裝置實作項目新增或修改驗證方式 (系統是以已知的密鑰為依據)，藉此解鎖螢幕鎖定畫面，並採用新的驗證方法視為安全的螢幕鎖定方式，則適用以下情形：

• [C-3-1] 允許的最短輸入長度熵必須大於 10 位元。
• [C-3-2] 所有可能輸入值的最大熵必須大於 18 位元。
• [C-3-3] 新的驗證方式「不得」取代 Android 開放原始碼計畫中提供的任何建議主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)。
• [C-3-4] 當裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策時，「必須」停用新驗證方法 (有效常數比 PASSWORD_QUALITY_SOMETHING 更嚴格)。
• [C-3-5] 新的驗證方法「必須」每隔 72 小時改回使用建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)，或是向使用者清楚揭露部分資料不會備份，以保障資料隱私。

如果裝置實作新增或修改建議的主要驗證方式來解鎖螢幕鎖定，並採用以生物特徵辨識技術為基礎的新驗證方法，才能安全鎖定螢幕，那麼以下新方法：

• [C-4-1] 必須符合第 7.3.10 節所述的所有便利性規定。
• [C-4-2] 必須設定備用機制，才能使用以已知密鑰為基礎的建議主要驗證方法。
• [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 電視或 Automotive 裝置) 上完全實作功能。
• [C-7-4] 必須加密 TrustAgentService.addEscrowToken() 新增的所有已儲存權杖。
• [C-7-5] 「不得」在使用金鑰的裝置上儲存加密金鑰或託管權杖。舉例來說，使用者可以使用儲存在手機上的金鑰解鎖電視上的使用者帳戶。
• [C-7-6] 啟用託管權杖以解密資料儲存空間之前，必須告知使用者安全性方面的影響。
• [C-7-7] 必須採用備用機制，才能使用建議的主要驗證方法。
• [C-7-8] 除非使用者有安全疑慮 (例如造成駕駛人分心) 的情況，否則請務必每 72 小時以一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 進行驗證。
• [C-7-9] 除非使用者有安全疑慮 (例如造成駕駛人分心)，否則「必須」在 4 小時的閒置逾時期限過後，要求使用者進行任一建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。系統會在成功確認裝置憑證後，重設閒置逾時期限。
• [C-7-10] 不得視為安全螢幕鎖定，且必須遵守下列 C-8 限制。
• [C-7-11] 「不得」允許主要個人裝置 (例如手持裝置) 上的 TrustAgent 解鎖裝置，且只能讓已解鎖裝置的處於解鎖狀態最長 4 小時。Android 開放原始碼計畫中的 TrustManagerService 預設實作方式符合這項規定。
• [C-7-12] 「必須」使用經過加密編譯的安全 (例如 UKEY2) 通訊管道，將儲存裝置中的託管權杖傳遞至目標裝置。

如果裝置實作會新增或修改驗證方法，以便解鎖非安全螢幕鎖定畫面 (如上所述)，並使用新的驗證方法解鎖鍵盤保護功能，請按照下列步驟操作：

• [C-8-1] 裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法 (比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格的品質常數) 設定密碼品質政策時，「必須」停用新方法。
• [C-8-2] 使用者「不得」重設 DevicePolicyManager.setPasswordExpirationTimeout() 設定的密碼到期計時器。
• [C-8-3] 使用者「不得」公開 API 來變更鎖定狀態，供第三方應用程式使用。

9.11.2。強固盒

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在專屬的安全處理器以及上述的獨立執行環境中。這類專屬的安全處理器稱為「StrongBox」。以下 C-1-3 到 C-1-11 的要求定義了裝置「必須」符合 StrongBox 條件。

具備專用安全處理器的裝置實作方式：

• [C-SR] 強烈建議開始支援 StrongBox。StrongBox 可能會成為日後版本中的必要項目。

如果裝置的實作支援 StrongBox，他們會：

• [C-1-1] 必須宣告 FEATURE_STRONGBOX_KEYSTORE。

• [C-1-2] 「必須」提供專門用於備份 KeyStore 及保護使用者驗證的專屬安全硬體。專屬的安全硬體也可能用於其他用途。

• [C-1-3] 必須使用獨立 CPU，而且應用程式不得與應用程式處理器 (AP) 共用快取、DRAM、輔助處理器或其他核心資源。

• [C-1-4] 「必須」確保與 AP 共用的任何週邊裝置均不得以任何方式變更 StrongBox 處理程序，或從 StrongBox 取得任何資訊。AP 可能會停用或封鎖 StrongBox 存取權。

• [C-1-5] 必須採用具合理準確性 (+-10%) 的內部時鐘，方便 AP 操控。

• [C-1-6] 必須具備真正的隨機號碼產生器，可產生均勻分佈且無法預測的輸出內容。

• [C-1-7] 必須防範竄改行為，包括抵抗實體滲透和故障。

• [C-1-8] 必須採取某些側面的阻力，包括防止透過電力、時機、電磁輻射和熱輻射側邊通道洩漏資訊。

• [C-1-9] 必須提供安全儲存空間，確保內容的機密性、完整性、真實性、一致性和即時性。除非 StrongBox API 允許，否則「不得」讀取或修改儲存體。

• 如要驗證裝置是否符合 [C-1-3] 到 [C-1-9] 的規範，裝置實作情形如下：

  • [C-1-10] 「必須」納入經安全 IC 保護設定檔 BSI-CC-PP-0084-2014 認證的硬體，或通過國家認可的測試實驗室進行評估，根據智慧型卡片可能遭受攻擊的共通條件應用，進行高度攻擊潛在安全漏洞的評估。
  • [C-1-11] 「必須」包含經過國家認可的測試實驗室評估的韌體，該實驗室係根據智慧型卡片可能遭受攻擊的常見條件套用，納入高度攻擊的潛在安全漏洞評估。
  • [C-SR] 強烈建議納入使用安全性目標、評估保證等級 (EAL) 5 評估的硬體，並以 AVA_VAN.5 強化。您可能會在日後的版本中取得 EAL 5 認證。

• [C-SR] 極力建議提供內部攻擊防範機制 (IAR)，也就是說，擁有韌體簽署金鑰存取權的內部人員不得產生韌體導致 StrongBox 外洩密鑰、規避功能安全性要求，或以其他方式存取敏感的使用者資料。建議的實作 IAR 方法是僅在透過 IAuthSecret HAL 提供主要使用者密碼時，才允許韌體更新。

9.12.資料刪除

所有裝置實作方式：

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

9.13.安全啟動模式

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

裝置導入方式如下：

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

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

• [C-1-1] 「必須」為使用者提供進入安全啟動模式的選項，使安裝在裝置上的第三方應用程式無法中斷服務，但第三方應用程式為 Device Policy Controller 且將 UserManager.DISALLOW_SAFE_BOOT 旗標設為 true 時除外。

• [C-1-2] 「必須」允許使用者在安全模式下解除安裝任何第三方應用程式。

• 應為使用者提供與正常啟動不同的工作流程，從啟動選單進入安全啟動模式。

9.14。汽車車輛系統隔離

Android Automotive 裝置應使用車輛 HAL 透過車輛網路 (例如 CAN 公車) 收發訊息，藉此與重要的車輛子系統交換資料。

您可以在 Android 架構層下方實作安全性功能，防範與這些子系統惡意或無意間的互動，進而保護資料交換的安全。

9.15。訂閱計畫

「訂閱方案」請參閱行動電信業者透過 SubscriptionManager.setSubscriptionPlans() 提供的收費關係方案詳細資料。

所有裝置實作方式：

• [C-0-1] 「必須」只向原先提供訂閱方案的行動電信業者應用程式傳回資費方案。
• [C-0-2] 「不得」從遠端備份或上傳訂閱方案。
• [C-0-3] 「必須」只允許透過目前提供有效訂閱方案的行動電信業者應用程式覆寫 SubscriptionManager.setSubscriptionOverrideCongested() 等覆寫設定。

10. 軟體相容性測試

裝置實作「必須」通過本節所述的所有測試。不過請注意，沒有完整的軟體測試套件。因此，強烈建議裝置實作者盡量採取最低限度的變更，讓 Android 開放原始碼計畫提供 Android 的參照與偏好的實作方式。這麼做可將引入錯誤的風險降到最低，讓團隊之間的作業有所不相容，並導致裝置可能更新。

10.1.Compatibility Test Suite

裝置實作方式：

• [C-0-1] 必須利用裝置上的最終運送軟體，通過 Android 開放原始碼計畫提供的 Android Compatibility Test Suite (CTS)。

• [C-0-2] 必須確保 CTS 中模稜兩可的情況，以及參照原始碼部分內容的重新導入作業，以確保相容。

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

裝置實作方式：

• [C-0-3] 必須通過裝置軟體完成時可用的最新 CTS 版本。

• 請盡可能使用 Android 開放原始碼樹狀結構中的參考實作方式。

10.2.CTS 驗證器

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

裝置實作方式：

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

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

裝置實作方式：

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

您或許可以略過或略過這份相容性定義說明文件中註明的選用功能測試案例。

• [C-0-2] 每個裝置和每個版本都必須正確執行 CTS Verifier (如上所述)。不過，由於許多版本非常相似，因此裝置實作者不應在僅有顯著差異的版本中明確執行 CTS Verifier。具體來說，裝置導入方式不同於實作項目，但該實作方法只通過涵蓋的語言代碼、品牌宣傳等組合，但通過 CTS Verifier 驗證。因此請略過 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] 必須支援透過離線更新和離線更新進行 OTA 下載。

如果是搭載 Android 6.0 以上版本的裝置實作項目，更新機制「必須」支援驗證系統映像檔是否與 OTA 後預期結果相同。自 Android 5.1 版起，在上游 Android 開放原始碼計畫中新增以區塊為基礎的 OTA 實作符合這項規定。

此外，裝置實作項目必須支援 A/B 系統更新。Android 開放原始碼計畫利用啟動控制項 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 論壇，詢問有關文件未涵蓋的問題或提出任何問題。