自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。

本頁面由 Cloud Translation API 翻譯而成。

Android 9 相容性定義
透過集合功能整理內容你可以依據偏好儲存及分類內容。

1. 簡介

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

使用「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」時，請遵循 RFC2119 中定義的 IETF 標準。

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

如要與 Android 9 相容，裝置實作項目必須符合本相容性定義中列明的規定，包括透過參考整合的任何文件。

如果這個定義或第 10 節所述的軟體測試未明確說明或不完整，則裝置導入者有責任確保與現有導入作業的相容性。

因此，Android 開放原始碼計畫是 Android 的參考和偏好實作項目。強烈建議裝置實作者盡可能以「上游」原始碼為基礎，從 Android 開放原始碼計畫取得原始碼。雖然部分元件可假設以其他實作項目取代，但強烈建議您不要採用這種做法，因為通過軟體測試的難度會大幅提高。導入者有責任確保與標準 Android 導入方式 (包括相容性測試套件和其他測試) 完全相容。最後，請注意，本文件明文禁止某些元件替換和修改作業。

本文所連結的許多資源都是直接或間接從 Android SDK 衍生而來，因此功能上與該 SDK 說明文件中的資訊相同。無論在何種情況下，如果本相容性定義或相容性測試套件與 SDK 說明文件不一致，SDK 說明文件都會視為權威來源。本文件中連結的資源提供的任何技術細節，都視為是本相容性定義的一部分。

1.1 文件結構

1.1.1. 依裝置類型劃分的規定

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

其他適用於所有 Android 裝置實作的規定，會列在第 2 節後面的各個部分。本文件將這些需求稱為「核心要求」。

1.1.2. 需求 ID

系統會為「必須」要求指派需求 ID。

這個 ID 只會指派給「必須」規定。
強烈建議的規定會標示為 [SR]，但不會指派 ID。
這個 ID 包含：裝置類型 ID - 條件 ID - 需求 ID (例如 C-0-1)。

每個 ID 的定義如下：

裝置類型 ID (詳情請參閱「2. 裝置類型)
- C：核心 (適用於任何 Android 裝置實作的規定)
- H：Android 手持裝置
- T：Android TV 裝置
- 答：Android Automotive 實作
- 分頁：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 平板電腦的規定會標示為「*」。

2.2.1. 硬體

手持裝置實作方式：

[7.1.1.1/H-0-1] 螢幕的對角線尺寸必須至少為 2.5 英寸。
[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-1] 必須提供「Home」、「Recents」和「Back」功能。
[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 的事件頻率。

如果手持裝置實作項目包含陀螺儀，則會：

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

可撥打語音通話並在 getPhoneType 中指示 PHONE_TYPE_NONE 以外任何值的手持裝置實作方式：

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

手持裝置實作方式：

[7.3.12/H-SR] 建議支援具有 6 個自由度的姿勢感應器。
[7.4.3/H] 應支援藍牙和藍牙 LE。

如果手持裝置實作項目包含計量連線，則會：

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

手持裝置實作方式：

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

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

[7.6.1/H-1-1] 如果預設螢幕使用高達 qHD 的 Framebuffer 解析度 (例如 FWVGA)，則核心和使用者空間的可用記憶體必須至少為 416 MB。
[7.6.1/H-2-1] 如果預設螢幕使用高達 HD+ 的顯示緩衝區解析度 (例如 HD、WSVGA)，則核心和使用者空間可用的記憶體必須至少為 592 MB。
[7.6.1/H-3-1] 如果預設螢幕使用高達 FHD 的顯示緩衝區解析度 (例如 WSXGA+)，則核心和使用者空間可用的記憶體必須至少為 896 MB。
[7.6.1/H-4-1] 如果預設螢幕使用高達 QHD 的螢幕緩衝區解析度 (例如 QWXGA)，則核心和使用者空間的可用記憶體必須至少為 1344 MB。

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

[7.6.1/H-5-1] 如果預設螢幕使用高達 qHD 的 Framebuffer 解析度 (例如 FWVGA)，則核心和使用者空間可用的記憶體必須至少為 816 MB。
[7.6.1/H-6-1] 如果預設螢幕使用高達 HD+ 的顯示緩衝區解析度 (例如 HD、WSVGA)，則核心和使用者空間可用的記憶體必須至少為 944 MB。
[7.6.1/H-7-1] 如果預設螢幕使用高達 FHD 的顯示緩衝區解析度 (例如 WSXGA+)，則核心和使用者空間可用的記憶體必須至少為 1280 MB。
[7.6.1/H-8-1] 如果預設螢幕使用高達 QHD 的 framebuffer 解析度 (例如 QWXGA)，則核心和使用者空間可用的記憶體必須至少為 1824 MB。

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

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

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

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

[7.6.1/H-10-1] 應用程式私人資料 (又稱「/data」分區) 必須至少有 4GB 的非揮發性儲存空間。
應宣告功能旗標 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。

手持裝置實作方式：

[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，且 VR 應用程式可透過 android.app.Activity#setVrModeEnabled 啟用該應用程式。

2.2.2. 多媒體

手持裝置實作項目必須支援下列音訊編碼：

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

手持裝置實作方式必須支援下列音訊解碼：

[5.1.2/H-0-1] AMR-NB
[5.1.2/H-0-2] AMR-WB

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

[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] 必須包含通知遮罩，讓使用者能夠透過使用者操作元素 (例如 AOSP 中實作的動作按鈕或控制面板) 直接控制通知 (例如回覆、延後、關閉、封鎖)。
[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.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 裝置，或將內部 (不可移除) 儲存空間分配為共用儲存空間。

手持裝置實作方式：

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

2.2.4. 效能和電源

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

手持裝置實作方式：

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

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

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

手持裝置實作方式：

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

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

[8.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-1-1] 必須允許使用者選擇最短的休眠逾時時間，也就是從解鎖到鎖定的轉換時間，最短為 15 秒。
[9.11/H-1-2] 必須提供使用者操作提示，以便隱藏通知，並停用所有形式的驗證 (除了 9.11.1 安全的螢幕鎖定畫面中所述的主要驗證)。AOSP 符合鎖定模式的規定。

2.3. 電視相關規定

Android 電視裝置是指 Android 裝置實作，也就是娛樂介面，可供使用者在約 10 英尺 (約 3 公尺) 的距離內觀看數位媒體、電影、遊戲、應用程式和/或電視直播內容 (稱為「躺椅」或「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] 必須提供「Home」和「Back」功能。
[7.2.3/T-0-2] 必須將返回功能 (KEYCODE_BACK) 的一般和長按事件傳送至前景應用程式。
[7.2.6.1/T-0-1] 必須支援遊戲控制器，並宣告 android.hardware.gamepad 功能旗標。
[7.2.7/T] 應提供遠端控制項，讓使用者可以存取非觸控導覽和核心導覽鍵輸入內容。

如果電視裝置實作包含陀螺儀，則必須：

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

電視裝置實作方式：

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

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

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

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

[7.6.1/T-1-1] 如果使用下列任一密度，則核心和使用者空間可用的記憶體必須至少為 896 MB：
- 小/一般螢幕：400 dpi 以上
- 大型螢幕的 xhdpi 或更高
- 在超大螢幕上使用 tvdpi 或更高

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

[7.6.1/T-2-1] 如果使用下列任一密度，則核心和使用者空間可用的記憶體必須至少為 1280 MB：
- 小/一般螢幕：400 dpi 以上
- 大型螢幕的 xhdpi 或更高
- 在超大螢幕上使用 tvdpi 或更高

電視裝置實作方式：

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

2.3.2. 多媒體

電視裝置實作方式必須支援下列音訊編碼格式：

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

電視裝置實作方式必須支援下列影片編碼格式：

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

電視裝置實作方式：

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

電視裝置實作方式必須支援下列影片解碼格式：

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

強烈建議電視裝置實作項目支援下列影片解碼格式：

[5.3.1/T-SR] MPEG-2

電視裝置實作方式必須支援 H.264 解碼，詳情請參閱第 5.3.4 節，解碼時的標準影片影格速率和解析度必須為：

[5.3.4.4/T-1-1] 以 60 fps 播放 HD 1080p 內容，並使用 Baseline Profile
[5.3.4.4/T-1-2] 以 Main Profile 以每秒 60 張影格的速度播放 HD 1080p
[5.3.4.4/T-1-3] 以高畫面等級 4.2 和 60 fps 播放 HD 1080p 內容

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

[5.3.5.4/T-1-1] 以主 Profile Level 4.1 以每秒 60 影格播放 HD 1080p

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

[5.3.5.5/T-2-1] 必須支援以 Main10 Level 5 Main Tier 設定檔，以 60 張/秒的速度解碼 UHD 格式。

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

[5.3.6.4/T-1-1] HD 1080p 每秒 60 影格解碼設定檔

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

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

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

[5.3.7.5/T-2-1] 必須支援 UHD 解碼設定檔，以每秒 60 格和設定檔 0 (8 位元色彩深度) 為準。
[5.3.7.5/T-2-1] 強烈建議支援 UHD 解碼設定檔，以每秒 60 張影格和設定檔 2 (10 位元色彩深度) 為基礎。

電視裝置實作方式：

[5.5.3/T-0-1] 必須支援系統主音量，並在支援的輸出裝置上提供數位音訊輸出音量衰減功能，但壓縮音訊直通輸出 (裝置上不會進行音訊解碼) 除外。
[5.8/T-0-1] 必須設定 HDMI 輸出模式，以便選取所有有線螢幕可支援的最高解析度，並支援 50Hz 或 60Hz 的螢幕更新率。
[5.8/T-SR] 強烈建議為所有有線螢幕提供可供使用者設定的 HDMI 更新率選取器。
[5.8/T-SR] 強烈建議支援同時解碼安全串流。強烈建議同時解碼兩個串流。
[5.8] 應將 HDMI 輸出模式的刷新率設為 50 Hz 或 60 Hz，視裝置銷售地區的影片刷新率而定，適用於所有有線螢幕。

如果電視裝置實作支援 UHD 解碼，且支援外接螢幕，則會：

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

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

[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] 必須支援 TV Input Framework。

2.3.4. 效能和電源

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

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

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

電視裝置實作方式：

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

2.4. 智慧手錶需求

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

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

螢幕的對角線長度介於 1.1 到 2.5 英寸之間。
提供可配戴在身上的裝置機制。

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

2.4.1. 硬體

Watch 裝置實作：

[7.1.1.1/W-0-1] 螢幕的對角線尺寸必須介於 1.1 到 2.5 英寸之間。
[7.2.3/W-0-1] 必須提供使用者「Home」功能，以及「Back」功能 (除非處於 UI_MODE_TYPE_WATCH 中)。
[7.2.4/W-0-1] 必須支援觸控螢幕輸入。
[7.3.1/W-SR] 強烈建議加入 3 軸加速度計。
[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. 軟體

Watch 裝置實作：

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

Watch 裝置實作：

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

檢視宣告 android.hardware.audio.output 功能標記的裝置實作項目：

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

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

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

2.4.4. 效能和電源

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

[8.3/W-SR] 強烈建議您提供使用者操作提示，讓他們能夠查看所有不受應用程式待命和打盹省電模式影響的應用程式。
[8.3/W-SR] 強烈建議提供使用者操作元素，以便啟用及停用省電模式。

Watch 裝置實作：

[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.5. 汽車業規定

Android Automotive 實作是指車輛音響主機，其運作系統為 Android，用於部分或全部系統和/或資訊娛樂功能。

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

已嵌入車輛或可插入車輛。
使用駕駛座椅列的螢幕做為主要顯示螢幕。

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

2.5.1. 硬體

汽車裝置實作方式：

[7.1.1.1/A-0-1] 螢幕的對角線尺寸必須至少為 6 英寸。
[7.1.1.1/A-0-2] 螢幕大小版面配置必須至少為 750 dp x 480 dp。
[7.2.3/A-0-1] 必須提供「Home」功能，並可提供「Back」和「Recent」功能。
[7.2.3/A-0-2] 必須將返回功能 (KEYCODE_BACK) 的一般和長按事件傳送至前景應用程式。
[7.3.1/A-SR] 強烈建議加入 3 軸式加速度計。

如果車用裝置實作項目包含 3 軸式加速度計，則必須符合下列條件：

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

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

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

汽車裝置實作方式：

[7.3.11/A-0-1] 必須提供目前的裝備，如 SENSOR_TYPE_GEAR。

汽車裝置實作方式：

[7.3.11.2/A-0-1] 必須支援以 SENSOR_TYPE_NIGHT 定義的白天/夜間模式。
[7.3.11.2/A-0-2] SENSOR_TYPE_NIGHT 標記的值必須與資訊主頁的白天/夜間模式一致，且應以環境光感應器輸入為依據。
基礎環境光度感應器可能與光度計相同。
[7.3.11.4/A-0-1] 必須提供 SENSOR_TYPE_CAR_SPEED 定義的車輛速度。
[7.3.11.5/A-0-1] 必須提供 SENSOR_TYPE_PARKING_BRAKE 定義的停車煞車狀態。
[7.4.3/A-0-1] 必須支援藍牙，且應支援藍牙 LE。
[7.4.3/A-0-2] Android Automotive 實作項目必須支援下列藍牙設定檔：
- 使用免持聽筒設定檔 (HFP) 撥打電話。
- 透過音訊分發設定檔 (A2DP) 播放媒體。
- 透過遠端控制設定檔 (AVRCP) 控制媒體播放。
- 使用電話簿存取權設定檔 (PBAP) 分享聯絡人。
[7.4.3/A-SR] 強烈建議支援 Message Access Profile (MAP)。
[7.4.5/A] 應支援以行動網路為基礎的資料連線。
[7.4.5/A] 可針對系統應用程式可用的網路使用系統 API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常數。
[7.6.1/A-0-1] 必須至少有 4 GB 的非揮發性儲存空間，用於應用程式私人資料 (又稱「/data」分區)。

汽車裝置實作方式：

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

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

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

如果車用裝置實作是 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：
- 在小螢幕/一般螢幕上，顯示解析度為 560dpi 以上
- 大型螢幕的解析度須高於 400dpi
- xhdpi 或更高 (超大螢幕)

如果車用裝置實作方式為 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] 如果使用下列任一密度，核心和使用者空間可用的記憶體必須至少為 1824 MB：
- 在小螢幕/一般螢幕上，顯示解析度為 560dpi 以上
- 大型螢幕的解析度須高於 400dpi
- xhdpi 或更高 (超大螢幕)

汽車裝置實作方式：

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

汽車裝置實作方式：

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

汽車裝置實作方式：

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

2.5.2. 多媒體

車用裝置實作項目必須支援下列音訊編碼：

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

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

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

車用裝置實作項目必須支援下列影片解碼：

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

強烈建議車用裝置實作項目支援下列影片解碼功能：

[5.3/A-SR] H.265 HEVC

2.5.3. 軟體

汽車裝置實作方式：

[3/A-0-1] 必須宣告 android.hardware.type.automotive 功能。
[3/A-0-2] 必須支援 uiMode = UI_MODE_TYPE_CAR。
[3/A-0-3] 必須支援 android.car.* 命名空間中的所有公開 API。
[3.4.1/A-0-1] 必須提供 android.webkit.Webview API 的完整實作。
[3.8.3/A-0-1] 第三方應用程式要求時，必須顯示使用 Notification.CarExtender API 的通知。
[3.8.4/A-SR] 強烈建議在裝置上導入助理，以便處理輔助動作。
[3.13/A-SR] 強烈建議您加入快速設定 UI 元件。

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

[3.8.4/A-1-1] 必須使用短暫按下按鈕的互動方式，啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式。

汽車裝置實作方式：

[3.14/A-0-1] 必須包含 UI 架構，以便支援使用媒體 API 的第三方應用程式，如 3.14 所述。

2.5.4. 效能和電源

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

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

汽車裝置實作方式：

[8.2/A-0-1] 必須針對每個程序的 UID 回報讀取及寫入至非揮發性儲存空間的位元組數量，以便開發人員透過系統 API android.car.storagemonitoring.CarStorageMonitoringManager 取得統計資料。Android 開放原始碼計畫透過 uid_sys_stats 核心模組滿足這項需求。
[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.9.2/A-1-1] 必須支援針對每個使用者專屬的驗證金鑰進行加密。檔案型加密 (FBE) 就是其中一種方法。

汽車裝置實作方式：

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

2.6. 平板電腦需求條件

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

通常用於雙手握持。
不支援折疊式或可轉換式設定。
任何與裝置搭配使用的實體鍵盤實作方式，都必須透過標準連線方式連接。
具備可提供行動力的電源，例如電池。
螢幕對角線尺寸介於 7 到 18 英寸。

平板電腦裝置實作項目的必要條件與手持裝置實作項目相似。該節中以 * 號標示的項目為例外狀況，並在本節中列出供您參考。

2.4.1. 硬體

螢幕大小

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

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

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

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

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

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

虛擬實境模式 (第 7.9.1 節)

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

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

3. 軟體

3.1. 代管 API 相容性

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

裝置實作方式：

[C-0-1] 必須提供完整的實作項目，包括所有已記錄行為，這些行為是指 Android SDK 公開的任何已記錄 API，或是在 Android 上游原始碼中加上「@SystemApi」標記的任何 API。
[C-0-2] 必須支援/保留所有標示為 TestApi 註解 (@TestApi) 的類別、方法和相關元素。
[C-0-3] 除非本相容性定義明確允許，否則不得省略任何受管理的 API、變更 API 介面或簽章、偏離說明的行為，或包含無操作。
[C-0-4] 即使 Android 省略了某些硬體功能的 API，也必須保留這些 API，並以合理的方式運作。如要瞭解此情境的具體規定，請參閱第 7 節。
[C-0-5] 必須限制第三方應用程式使用隱藏 API，此類 API 的定義是指 Android 命名空間中的 API，並且已加上 @hidden 註解，但未加上 @SystemAPI 或 @TestApi，如SDK 文件所述。此外，每個隱藏 API 都必須與相同的限制清單一併發布，這些清單是透過 AOSP 中適當 API 級別分支的 prebuilts/runtime/appcompat/ 路徑中的暫時性清單和拒絕清單檔案提供。不過，
- 可行，如果裝置實作中沒有隱藏的 API，或實作方式不同，請將隱藏的 API 移至拒絕清單，或從所有受限制的清單中略過。
- 可行，如果 AOSP 中沒有隱藏的 API，請將隱藏的 API 新增至任何限制清單。
- 可實作動態更新機制，將隱藏的 API 從受限制清單移至限制較少的清單 (除了許可清單)。

3.1.1. Android 擴充功能

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

[C-0-1] Android 裝置實作項目必須預先載入共用程式庫 ExtShared 和服務 ExtServices 的 AOSP 實作項目，且版本必須高於或等於各 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，在資訊清單中宣告需要程式庫。

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

3.2. 軟體 API 相容性

除了第 3.1 節中的受管理 API，Android 也包含重要的「軟性」API，僅適用於執行階段，例如意圖、權限和其他無法在應用程式編譯期間強制執行的 Android 應用程式相關項目。

3.2.1. 權限

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

3.2.2. 建構參數

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

[C-0-1] 為在各裝置實作中提供一致且有意義的值，下表列出這些值的格式額外限制，裝置實作必須符合這些限制。

參數	詳細資料
VERSION.RELEASE	目前執行的 Android 系統版本，以人類可讀的格式表示。這個欄位必須包含 9 中定義的其中一個字串值。
VERSION.SDK	目前執行的 Android 系統版本，格式可供第三方應用程式程式碼存取。對於 Android 9，這個欄位必須設為整數值 9_INT。
VERSION.SDK_INT	目前執行的 Android 系統版本，格式可供第三方應用程式程式碼存取。對於 Android 9，這個欄位必須設為整數值 9_INT。
VERSION.INCREMENTAL	裝置實作者選擇的值，用於指定目前執行中 Android 系統的特定版本，並以人類可讀的格式呈現。這個值不得重複用於提供給使用者的不同版本。這個欄位的常見用途是指出系統用來產生建構項目的建構編號或來源控制變更 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
BOARD	裝置實作者選擇的值，用於識別裝置使用的特定內部硬體，以人類可讀的格式呈現。這個欄位的可能用途是指出為裝置供電的板子特定修訂版本。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
品牌	這個值會反映與裝置相關聯的品牌名稱，使用者可透過這個名稱辨識裝置。必須採用人類可讀的格式，且應代表裝置的製造商，或裝置行銷時使用的公司品牌。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
SUPPORTED_ABIS	原生程式碼的指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。本機 API 相容性。
SUPPORTED_32_BIT_ABIS	原生程式碼的指令集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。本機 API 相容性。
SUPPORTED_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_-]+$」。這個裝置名稱在產品的生命週期內不得變更。
FINGERPRINT	用於唯一識別此版本的字串。應以人類可讀的方式呈現。必須符合以下範本： $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 例如： acme/myproduct/ mydevice:9/LMYXX/3359:userdebug/test-keys 指紋不得包含空白字元。如果上述範本中的其他欄位含有空白字元，則必須在版本指紋中以其他字元取代，例如底線字元 ("_")。這個欄位的值必須能以 7 位元 ASCII 編碼。
硬體	硬體名稱 (來自核心命令列或 /proc)。應以人類可讀的方式呈現。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
主機	這個字串可用人類可讀的格式，唯一識別建構版本的代管服務器。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
ID	裝置實作者選擇的 ID，用於參照特定版本，並以人類可讀的格式呈現。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但應為使用者區分軟體版本時可充分利用的值。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
製造商	產品的原始設備製造商 (OEM) 商號。這個欄位沒有特定格式規定，但不得為空值或空白字串 ("")。這個欄位在產品生命週期內不得變更。
MODEL	裝置實作者選擇的值，包含使用者所知的裝置名稱。這個名稱應與向終端使用者行銷和銷售裝置時使用的名稱相同。這個欄位沒有特定格式規定，但不得為空值或空白字串 ("")。這個欄位在產品生命週期內不得變更。
產品	裝置實作者選擇的值，包含特定產品 (SKU) 的開發名稱或代碼名稱，且必須在同一個品牌中不重複。必須是人類可讀的格式，但不一定是供使用者查看。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。這個產品名稱在產品的生命週期內不得變更。
SERIAL	必須傳回「UNKNOWN」。
標記	裝置實作者選擇的標記清單，以半形逗號分隔，可進一步區分版本。這個欄位必須包含一個值，對應至三種典型的 Android 平台簽署設定：發布版金鑰、開發版金鑰、測試版金鑰。
時間	代表建構作業發生時間的時間戳記值。
類型	裝置實作者選擇的值，用於指定建構作業的執行階段設定。這個欄位必須包含一個值，對應至三種典型的 Android 執行階段設定：user、userdebug 或 eng。
USER	產生版本的使用者 (或自動化使用者) 的名稱或使用者 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
SECURITY_PATCH	這個值表示版本的安全性修補程式等級。此標記必須表示此版本在任何情況下都不會受到指定 Android 公開安全性公告中所述問題的影響。格式必須為 [YYYY-MM-DD]，且必須與 Android 安全性公告或Android 安全性警示中定義的字串相符，例如「2015-11-01」。
BASE_OS	這個值代表建構版本的 FINGERPRINT 參數，除了 Android 公開安全性公告中提供的修補程式外，其他都與此建構版本相同。必須回報正確的值，如果不存在此建構項目，則回報空字串 ("")。
BOOTLOADER	裝置實作者選擇的值，用於識別裝置中使用的特定內部系統啟動載入程式版本，以人類可讀的格式呈現。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
getRadioVersion()	必須 (或傳回) 裝置實作者選擇的值，以人類可讀的格式識別裝置中使用的特定內部無線電/調變器版本。如果裝置沒有任何內部無線電/數據機，則必須傳回 NULL。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。
getSerial()	必須 (或傳回) 硬體序號，且該序號必須可用且在型號和製造商相同的裝置中不重複。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。

3.2.3. 意圖相容性

3.2.3.1. 核心應用程式意圖

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

[C-0-1] 裝置實作必須為 AOSP 中下列核心 Android 應用程式定義的所有公開意圖篩選器模式，預先載入一或多個應用程式或服務元件，並附上意圖處理常式：
- 桌上時鐘
- 瀏覽器
- 日曆
- 聯絡人
- 相片庫
- GlobalSearch
- 啟動器
- 音樂
- 設定

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 Link 規格中定義的驗證步驟，並由上游 Android 開放原始碼專案中的 Package Manager 實作。
[C-0-5] 必須在安裝應用程式期間嘗試驗證意圖篩選器，並將所有已成功驗證的 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。
可將特定 URI 意圖篩選器設為其 URI 的預設應用程式處理常式，前提是這些篩選器已成功驗證，但其他候選 URI 篩選器驗證失敗。如果裝置實作這項功能，就必須在設定選單中提供適當的 URI 模式覆寫值。
您必須在「設定」中為使用者提供個別應用程式 App Links 控制項，如下所示：
- [C-0-6] 使用者必須能夠全面覆寫應用程式的預設應用程式連結行為，以便選擇「一律開啟」、「一律詢問」或「一律不開啟」等選項，且這些選項必須一律套用至所有候選 URI 意圖篩選器。
- [C-0-7] 使用者必須能夠查看候選 URI 意圖篩選器的清單。
- 裝置實作可能會為使用者提供功能，讓他們能夠根據個別意圖篩選器，覆寫已成功驗證的特定候選 URI 意圖篩選器。
- [C-0-8] 如果裝置實作讓部分候選 URI 意圖篩選器通過驗證，但其他候選 URI 意圖篩選器無法通過，則裝置實作必須提供使用者查看及覆寫特定候選 URI 意圖篩選器的功能。

3.2.3.3. 意圖命名空間

[C-0-1] 裝置實作不得包含任何 Android 元件，該元件會使用 android. 或 com.android. 命名空間中的 ACTION、CATEGORY 或其他關鍵字串，遵循任何新的意圖或廣播意圖模式。
[C-0-2] 裝置導入者不得在屬於其他機構的套件空間中，使用 ACTION、CATEGORY 或其他關鍵字串，納入任何遵循新意圖或廣播意圖模式的 Android 元件。
[C-0-3] 裝置實作者不得變更或擴充第 3.2.3.1 節所列核心應用程式使用的任何意圖模式。
裝置實作可能會包含意圖模式，使用與其自身組織明確相關聯的命名空間。這項禁止規定與第 3.6 節中針對 Java 語言類別所述的規定類似。

3.2.3.4. 廣播意圖

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

裝置實作方式：

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

3.2.3.5. 預設應用程式設定

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

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

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

[C-1-1] 必須遵循 android.settings.HOME_SETTINGS 意圖，顯示主畫面的預設應用程式設定選單。

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

[C-2-1] 必須提供設定選單，呼叫 android.provider.Telephony.ACTION_CHANGE_DEFAULT 意圖，顯示對話方塊以變更預設的簡訊應用程式。
[C-2-2] 必須遵循 android.telecom.action.CHANGE_DEFAULT_DIALER 意圖，顯示對話方塊，允許使用者變更預設的電話應用程式。
- 接聽與撥打電話時，必須使用使用者選取的預設電話應用程式 UI，但緊急電話會使用預先安裝的電話應用程式。
[C-2-3] 必須遵循 android.telecom.action.CHANGE_PHONE_ACCOUNTS 意圖，提供使用者操作選項，讓使用者能夠設定與 PhoneAccounts 相關聯的 ConnectionServices，以及電信服務供應商用來撥打電話的預設 PhoneAccount。AOSP 實作項目在「通話」設定選單中加入「撥打帳戶選項」選單，以符合這項規定。

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

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

如果裝置實作支援 VoiceInteractionService，且同時安裝多個使用此 API 的應用程式，則會發生以下情況：

[C-4-1] 必須遵循 android.settings.ACTION_VOICE_INPUT_SETTINGS 意圖，顯示語音輸入和 Google 助理的預設應用程式設定選單。

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] 如果螢幕本身調整大小，則必須相應調整 VirtualDisplay 上的所有活動。
當文字輸入欄位在次要螢幕上獲得焦點時，您可以在主要螢幕上顯示 IME (輸入法編輯器，一種可讓使用者輸入文字的使用者控制項)。
在支援觸控或按鍵輸入時，應在次要螢幕上實作輸入焦點，而與主螢幕無關。
應具備與該螢幕相對應的 android.content.res.Configuration，才能正確顯示、運作，並在活動在次要螢幕上啟動時維持相容性。

如果裝置實作可在次要螢幕上啟動一般 Android 活動，且主螢幕和次要螢幕具有不同的 android.util.DisplayMetrics：

[C-2-1] 在次要螢幕上，不得允許無法調整大小的活動 (在 AndroidManifest.xml 中具有 resizeableActivity=false) 和指定 API 級別 23 以下版本的應用程式。

如果裝置實作可在次要螢幕上啟動一般 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 相容 (針對 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。
- armeabi
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- [C-0-7] 必須為下列所有程式庫提供原生 API，讓包含原生程式碼的應用程式可使用：
- libaaudio.so (AAudio 原生音訊支援)
- libandroid.so (原生 Android 活動支援)
- libc (C 程式庫)
- libcamera2ndk.so
- libdl (動態連結器)
- libEGL.so (原生 OpenGL 途徑管理)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (Android 記錄)
- libmediandk.so (原生媒體 API 支援)
- libm (數學程式庫)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (支援 OpenMAX AL 1.0.1)
- libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
- libRS.so
- libstdc++ (C++ 的最低支援程度)
- libvulkan.so (Vulkan)
- libz (Zlib 壓縮)
- JNI 介面
[C-0-8] 請勿為上述原生程式庫新增或移除公開函式。
[C-0-9] 必須在 /vendor/etc/public.libraries.txt 中列出直接公開給第三方應用程式的其他非 AOSP 程式庫。
[C-0-10] 不得將任何其他原生程式庫公開給指定 API 級別 24 以上版本的第三方應用程式，因為這些程式庫是保留用途。
[C-0-11] 必須透過 libGLESv3.so 程式庫，匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android 擴充套件函式符號。請注意，雖然必須提供所有符號，但第 7.1.4.1 節會更詳細說明各個對應函式應在何時完全實作。
[C-0-12] 必須透過 libvulkan.so 程式庫，為核心 Vulkan 1.0 函式符號和 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 擴充功能匯出函式符號。請注意，雖然必須提供所有符號，但第 7.1.4.2 節會更詳細說明各個對應函式應在何時完全實作。
應使用上游 Android 開放原始碼專案提供的原始碼和標頭檔案進行建構

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

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

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

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

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

[C-2-1] 必須在 /proc/cpuinfo 中加入下列行，且不應變更相同裝置上的值，即使其他 ABI 讀取這些值也一樣。
- Features:，接著是裝置支援的任何選用 ARMv7 CPU 功能清單。
- CPU architecture:，後面接著整數，說明裝置支援的最高 ARM 架構 (例如如為 ARMv8 裝置，則為「8」)。
[C-2-2] 即使 ABI 是透過原生 CPU 支援或軟體模擬方式在 ARMv8 架構上實作，也必須隨時提供下列運算：
- SWP 和 SWPB 指令。
- SETEND 指令。
- CP15ISB、CP15DSB 和 CP15DMB 的阻隔操作。
[C-2-3] 必須支援 Advanced SIMD (又稱為 NEON) 擴充功能。

3.4. 網頁相容性

3.4.1. WebView 相容性

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

[C-1-1] 必須回報 android.software.webview。
[C-1-2] 如要實作 android.webkit.WebView API，請務必使用 Android 9 分支上游 Android 開放原始碼專案的 Chromium 專案版本。
[C-1-3] WebView 回報的使用者代理程式字串必須採用以下格式：

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE 的值相同。
- $(MODEL) 字串可為空白，但如果不為空白，則必須與 android.os.Build.MODEL 的值相同。
- 「Build/$(BUILD)」可省略，但如果使用，$(BUILD) 字串必須與 android.os.Build.ID 的值相同。
- $(CHROMIUM_VER) 字串的值必須是上游 Android 開放原始碼專案中的 Chromium 版本。
- 裝置實作可能會在使用者代理程式字串中省略「Mobile」。
WebView 元件應盡可能支援 HTML5 功能，如果支援該功能，則應符合 HTML5 規格。

3.4.2. 瀏覽器相容性

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

[C-1-1] 必須支援下列與 HTML5 相關的 API：
[C-1-2] 必須支援 HTML5/W3C webstorage API，並應支援 HTML5/W3C IndexedDB API。請注意，由於網路開發標準機構正從 webstorage 轉為偏好 IndexedDB，因此 IndexedDB 預計將成為日後 Android 版本的必要元件。
可在獨立的瀏覽器應用程式中提供自訂使用者代理程式字串。
應盡可能在獨立瀏覽器應用程式中實作 HTML5 支援功能 (無論是基於上游 WebKit 瀏覽器應用程式，還是第三方替代方案)。

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

[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] 必須透過 LocationManager API 類別或 WifiManager.startScan() 方法，限制應用程式收到更新的頻率。
- [C-0-6] 如果應用程式指定 API 級別 25 以上版本，則不得允許註冊廣播接收器，以便在應用程式資訊清單中接收標準 Android 意圖的隱含廣播訊息，除非廣播意圖需要 "signature" 或 "signatureOrSystem" protectionLevel 權限，或是位於豁免清單中。
- [C-0-7] 如果應用程式指定的目標 API 級別為 25 以上，則必須停止應用程式的背景服務，就像應用程式呼叫服務的 stopSelf() 方法一樣，除非應用程式已加入暫時許可清單，用於處理使用者可見的任務。
- [C-0-8] 如果應用程式指定的目標為 API 級別 25 以上版本，則必須釋出應用程式持有的喚醒鎖。
[C-0-9] 裝置必須將下列安全性供應器做為 Security.getProviders() 方法的前七個陣列值，以指定順序和名稱 (由 Provider.getName() 傳回) 和類別傳回，除非應用程式已透過 insertProviderAt() 或 removeProvider() 修改清單。裝置可能會在下方指定的供應商清單後傳回其他供應商。
1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider - sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. 背景活動限制

如果裝置實作 AOSP 中包含的應用程式限制，或擴充應用程式限制，則會發生以下情況：

[C-SR] 強烈建議提供使用者可用性，讓使用者查看受限制的應用程式清單。
[C-1-2] 必須提供使用者操作元素，讓他們開啟 / 關閉各個應用程式的限制。
[C-1-3] 如未發現系統健康行為不佳的證據，則不得自動套用限制，但在偵測到系統健康行為不佳 (例如 Wakelock 卡住、服務執行時間過長等) 時，則可對應用程式套用限制。裝置實作者可以決定這些條件，但必須與應用程式對系統健康狀態的影響有關。其他與系統健康無關的條件 (例如應用程式在市場上缺乏人氣) 絕對不可用作評估標準。
[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。「公開暴露的元素」是指任何未使用上游 Android 原始碼中使用的「@hide」標記裝飾的結構。

裝置實作者可以修改 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 執行階段 (ART)、Dalvik 執行檔格式的參考上游實作項目，以及參考實作項目的套件管理系統。
應在各種執行模式和目標架構下執行模糊測試，以確保執行階段的穩定性。請參閱 Android 開放原始碼計畫網站中的 JFuzz 和 DexFuzz。

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

螢幕版面配置	螢幕密度	應用程式記憶體下限
Android 手錶	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (高解析度)	36MB
	280 dpi (280dpi)	36MB
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
小/正常	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (高解析度)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
large	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (高解析度)	80MB
	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
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (高解析度)	96MB
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	360 dpi (360dpi)	240MB
	400 dpi (400dpi)	288MB
	420 dpi (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. 使用者介面相容性

3.8.1. 啟動器 (主畫面)

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

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

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

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

[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] 必須內建 AppWidget 支援功能，並提供使用者介面操作元素，讓使用者直接在啟動器中新增、設定、查看及移除 AppWidget。
[C-1-3] 必須能夠以標準格狀大小算繪 4 x 4 的小工具。詳情請參閱 Android SDK 說明文件中的「App Widget 設計指南」。
可支援在螢幕鎖定畫面上顯示應用程式小工具。

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

[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] 必須在通知內容中，顯示透過 Notification.Builder.addAction() 提供的動作，且無須額外使用者互動，如SDK 所述。

3.8.3.2. 通知接聽器服務

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

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

[C-1-1] 必須正確且迅速地將通知完整更新至所有已安裝且使用者啟用的事件監聽器服務，包括附加至 Notification 物件的所有中繼資料。
[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_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 標記，則應向使用者指出視覺效果已在 DND 設定選單中抑制。

3.8.4. 搜尋

Android 提供 API，可讓開發人員在應用程式中整合搜尋功能，並將應用程式資料公開至全球系統搜尋功能。一般來說，這項功能包含單一系統層級的使用者介面，可讓使用者輸入查詢，並在使用者輸入時顯示建議內容和結果。Android API 可讓開發人員重複使用這個介面，在自己的應用程式中提供搜尋功能，並將結果提供給常見的全球搜尋使用者介面。

Android 裝置實作項目應包含全域搜尋功能，也就是單一共用系統層級搜尋使用者介面，可根據使用者輸入內容提供即時建議。

如果裝置實作導入全域搜尋介面，則會：

[C-1-1] 必須實作 API，讓第三方應用程式在全球搜尋模式下執行時，能夠在搜尋框中新增建議。

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

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

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

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

[C-2-1] 必須向使用者明確指出何時分享了背景資訊，方法如下：
- 每當小幫手應用程式存取情境時，會在螢幕邊緣顯示白色燈光，且亮度和持續時間符合或超過 Android 開放原始碼專案實作的標準。
- 針對預先安裝的輔助應用程式，提供使用者可用性，讓使用者只需兩次導覽即可前往預設語音輸入和 Google 助理應用程式設定選單，並且只在使用者透過熱字詞或輔助導覽鍵輸入內容時，才會分享內容。
[C-2-2] 如第 7.2.3 節所述，啟動輔助應用程式的指定互動動作必須啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式，或處理 ACTION_ASSIST 意圖的活動。

3.8.5. 警示和 Toast

應用程式可使用 Toast API 向使用者顯示短短的非模態字串，該字串會在短時間後消失，並使用 TYPE_APPLICATION_OVERLAY 視窗類型 API 將警示視窗顯示為其他應用程式的疊加層。

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

[C-1-1] 您必須提供使用者操作提示，讓使用者能夠阻止應用程式顯示使用 TYPE_APPLICATION_OVERLAY 的警告視窗。AOSP 實作項目會在通知面板中提供控制項，以符合這項規定。
[C-1-2] 必須遵循 Toast API 規定，並以某種醒目的方式，向使用者顯示來自應用程式的 Toast。

3.8.6。主題

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

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

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

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

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

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

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

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

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

3.8.7. 動態桌布

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

如果硬體可以以合理的幀率執行所有動態桌布，且不會對其他應用程式造成不良影響，就表示硬體可穩定執行動態桌布。如果硬體限制導致桌布和/或應用程式發生異常、耗用過多 CPU 或電池電力，或是以不合理的低幀率執行，則系統會判定硬體無法執行動態桌布。舉例來說，部分動態桌布可能會使用 OpenGL 2.0 或 3.x 背景處理內容。在未支援多個 OpenGL 情境的硬體上，即時桌布無法穩定執行，因為即時桌布使用 OpenGL 情境時，可能會與其他同樣使用 OpenGL 情境的應用程式發生衝突。

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

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

[C-1-1] 必須回報平台功能旗標 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。螢幕鎖定畫面媒體控制選項

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

3.8.11. 螢幕保護程式 (原稱為「夢幻背景」)

Android 支援互動式螢幕保護程式 (先前稱為夢境)。當裝置連接電源處於閒置狀態，或已連接至桌面底座時，使用者可以透過螢幕保護程式與應用程式互動。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 中指定的膚色和多元家庭表情符號。

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

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

3.8.14。多視窗模式

如果裝置實作功能可同時顯示多項活動，則必須符合下列條件：

[C-1-1] 必須根據 Android SDK 多視窗模式支援說明文件中所述的應用程式行為和 API 實作這類多視窗模式，並符合下列規定：
[C-1-2] 應用程式可在 AndroidManifest.xml 檔案中指出是否能夠以多視窗模式運作，方法是明確將 android:resizeableActivity 屬性設為 true，或是讓 targetSdkVersion 大於 24 以間接方式表示。在資訊清單中明確將這項屬性設為 false 的應用程式，不得以多視窗模式啟動。舊版應用程式 (targetSdkVersion < 24) 如未設定這項 android:resizeableActivity 屬性，可能會以多視窗模式啟動，但系統必須提供警告，指出應用程式可能無法在多視窗模式下正常運作。
[C-1-3] 如果螢幕高度和寬度分別小於 440 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，將目前 PIP 活動指定的動作公開至 SystemUI。
[C-3-3] 必須支援 PIP 活動透過 setAspectRatio() API 指定的 1:2.39 以上和 2.39:1 以下的顯示比例。
[C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制 PIP 視窗；如果未實作 PIP 模式，則前景活動必須可使用該鍵。
[C-3-5] 必須提供使用者提示，以便阻止應用程式以 PIP 模式顯示；AOSP 實作項目在通知陰影中提供控制項，符合這項規定。
[C-3-6] Configuration.uiMode 設定為 UI_MODE_TYPE_TELEVISION 時，必須為 PIP 視窗分配寬度和高度下限 108 dp，以及寬度下限 240 dp 和高度下限 135 dp。

3.8.15。螢幕凹口

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

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

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

3.9. 裝置管理

Android 包含多項功能，可讓具備安全意識的應用程式透過 Android Device Administration 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] 必須將 DPC 應用程式註冊為裝置擁有者應用程式，以回應意圖動作 android.app.action.PROVISION_MANAGED_DEVICE。
  - [C-1-5] 如果裝置透過功能旗標 android.hardware.nfc 宣告支援近距離無線通訊 (NFC)，且收到的 NFC 訊息含有 MIME 類型 MIME_TYPE_PROVISIONING_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 辨識為標準「裝置擁有者」，則：

[C-2-1] 必須設有程序，以便驗證所宣傳的特定應用程式屬於合法的企業裝置管理解決方案，且已在專屬解決方案中進行設定，擁有與「裝置擁有者」相同的權限。
[C-2-2] 必須顯示與 android.app.action.PROVISION_MANAGED_DEVICE 啟動的流程相同的 AOSP 裝置擁有者同意聲明揭露事項，才能將 DPC 應用程式註冊為「裝置擁有者」。
在註冊 DPC 應用程式為「裝置擁有者」之前，裝置上可能會有使用者資料。

3.9.1.2 受管理的設定檔佈建作業

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

[C-1-1] 必須實作API，讓裝置政策控制器 (DPC) 應用程式成為新受管理設定檔的擁有者。
[C-1-2] 受管理的設定檔佈建程序 (由 android.app.action.PROVISION_MANAGED_PROFILE 啟動的流程) 使用者體驗必須與 AOSP 實作方式一致。
[C-1-3] 必須在「設定」中提供下列使用者操作元素，向使用者指出裝置政策控制器 (DPC) 已停用特定系統功能：
- 一致的圖示或其他使用者操作元素 (例如上游 AOSP 資訊圖示)，用於表示特定設定遭到裝置管理員限制。
- 裝置管理員透過 setShortSupportMessage 提供的簡短說明訊息。
- DPC 應用程式的圖示。

3.9.2 受管理的設定檔支援

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

[C-1-1] 必須透過 android.app.admin.DevicePolicyManager API 支援受管理的設定檔。
[C-1-2] 必須允許建立一個受管理的設定檔。
[C-1-3] 必須使用圖示徽章 (類似 AOSP 上游工作徽章) 代表受管理的應用程式和小工具，以及其他徽章 UI 元素，例如「最近」和「通知」。
[C-1-4] 必須顯示通知圖示 (類似 AOSP 上游工作徽章)，指出使用者目前處於受管理設定檔應用程式中。
[C-1-5] 如果裝置喚醒 (ACTION_USER_PRESENT) 且前景應用程式位於受管理的設定檔中，則必須顯示浮動視窗，指出使用者處於受管理的設定檔。
[C-1-6] 如果有受管理的設定檔，則必須在意圖「選擇器」中顯示視覺提示，讓使用者將意圖從受管理的設定檔轉寄給主要使用者，或反之 (如果已由裝置政策控制器啟用)。
[C-1-7] 如果有受管理的設定檔，則必須同時為主要使用者和受管理的設定檔提供下列使用者操作功能：
- 為主要使用者和受管理的設定檔分別計算電池、位置、行動數據和儲存空間用量。
- 獨立管理主要使用者或受管理設定檔中安裝的 VPN 應用程式。
- 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
- 獨立管理主要使用者或受管理設定檔中的帳戶。
[C-1-8] 必須確保預先安裝的撥號、聯絡人和訊息應用程式，可搜尋及查看受管理設定檔 (如果有) 和主要設定檔的來電者資訊 (如果有) (如果裝置政策控制器允許)。
[C-1-9] 必須確保其符合所有適用於啟用多使用者功能的裝置的安全性要求 (請參閱第 9.5 節)，即使受管理的設定檔不算是除了主要使用者之外的其他使用者。
[C-1-10] 必須支援指定符合下列規定的獨立鎖定畫面，以便授予在受管理設定檔中執行的應用程式存取權。
- 裝置實作項目必須遵循 DevicePolicyManager.ACTION_SET_NEW_PASSWORD 意圖，並顯示介面，以便為受管理的設定檔設定個別的螢幕鎖定憑證。
- 如同 Android 開放原始碼專案網站所述，受管理設定檔的螢幕鎖定憑證必須使用與父項設定檔相同的憑證儲存和管理機制。
- 除非呼叫 getParentProfileInstance 傳回的 DevicePolicyManager 例項，否則 DPC 密碼政策一律只會套用至受管理設定檔的鎖定畫面憑證。
當受管理的聯絡資料顯示在預先安裝的通話記錄、通話中的使用者介面、進行中的通話和未接來電通知、聯絡人和訊息應用程式中時，應使用與受管理的應用程式相同的徽章。

3.9.3 受管理使用者支援

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

[C-1-1] 在 isLogoutEnabled 傳回 true 時，您務必提供使用者操作提示，讓使用者登出目前的使用者，並在多使用者工作階段中切換回主要使用者。使用者必須能夠在鎖定畫面上存取操作提示，且不必解鎖裝置。

3.10. 無障礙功能

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

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

[C-1-1] 必須提供 Android 無障礙功能架構的實作項目，如無障礙功能 API SDK 說明文件所述。
[C-1-2] 必須產生無障礙事件，並將適當的 AccessibilityEvent 傳送至所有已註冊的 AccessibilityService 實作項目，如 SDK 中的說明文件所述。
[C-1-3] 必須遵循 android.settings.ACCESSIBILITY_SETTINGS 意圖，提供使用者可存取的機制，以便啟用及停用第三方無障礙服務，以及預先安裝的無障礙服務。
[C-1-4] 必須在系統的導覽列中新增按鈕，讓使用者在啟用的無障礙服務宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 時，控制無障礙服務。請注意，對於沒有系統導覽列的裝置實作，這項規定不適用，但裝置實作應提供使用者控制這些無障礙服務的操作元素。

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

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

3.11. 文字轉語音

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

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

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

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

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

3.12. 電視輸入框架

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

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

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

3.13. 快速設定

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

如果裝置實作包含快速設定 UI 元件，則會：

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

3.14. 媒體 UI

如果裝置實作內容包含 UI 架構，且支援依賴 MediaBrowser 和 MediaSession 的第三方應用程式，則會發生以下情況：

[C-1-1] 必須顯示未經修改的 MediaItem 圖示和通知圖示。
[C-1-2] 必須顯示 MediaSession 所述的項目，例如中繼資料、圖示、圖像。
[C-1-3] 必須顯示應用程式名稱。
[C-1-4] 必須使用抽屜或其他機制來呈現 MediaBrowser 階層，並為 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] 除非免安裝應用程式明確連結至已安裝的應用程式，否則不得查看裝置上的免安裝應用程式詳細資料。

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 SDK 中「aapt」工具產生的 Android「.apk」檔案。
由於上述要求可能相當困難，因此建議裝置實作使用 AOSP 參考實作的套件管理系統。

裝置實作方式：

[C-0-2] 必須支援使用 APK Signature Scheme v3、APK Signature Scheme v2 和 JAR 簽署驗證「.apk」檔案。
[C-0-3] 請勿擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式，以免這些檔案無法在其他相容裝置上正確安裝及執行。
[C-0-4] 除了套件的目前「正式安裝者」外，其他應用程式不得在未經使用者確認的情況下，悄悄解除安裝應用程式，如 DELETE_PACKAGE 權限的 SDK 所述。唯一的例外狀況是系統套件驗證器應用程式處理 PACKAGE_NEEDS_VERIFICATION 意圖，以及儲存空間管理器應用程式處理 ACTION_MANAGE_STORAGE 意圖。
[C-0-5] 活動必須處理 android.settings.MANAGE_UNKNOWN_APP_SOURCES 意圖。
[C-0-6] 請勿從不明來源安裝應用程式套件，除非要求安裝的應用程式符合下列所有規定：
- 必須宣告 REQUEST_INSTALL_PACKAGES 權限，或是將 android:targetSdkVersion 設為 24 以下。
- 使用者必須已授予權限，才能從不明來源安裝應用程式。
應為使用者提供操作選項，讓他們授予/撤銷從不明來源安裝應用程式的權限，但如果裝置實作不想讓使用者有此選擇，則可選擇將此操作設為無操作，並傳回 startActivityForResult() 的 RESULT_CANCELED。不過，即使在這種情況下，也應向使用者說明為何沒有顯示這類選項。
[C-0-7] 在應用程式中啟動活動前，必須顯示警告對話方塊，並透過系統 API PackageManager.setHarmfulAppWarning 向使用者提供警告字串，該活動已由相同的系統 API PackageManager.setHarmfulAppWarning 標示為可能有害。
應在警告對話方塊中提供使用者操作提示，讓使用者選擇解除安裝或啟動應用程式。

5. 多媒體相容性

裝置實作方式：

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

裝置實作方式：

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

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

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

5.1. 媒體轉碼器

5.1.1. 音訊編碼

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

如果裝置實作項目宣告 android.hardware.microphone，則必須支援下列音訊編碼：

[C-1-1] PCM/WAVE

5.1.2. 音訊解碼

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

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

[C-1-1] MPEG-4 AAC 設定檔 (AAC LC)
[C-1-2] MPEG-4 HE AAC Profile (AAC+)
[C-1-3] MPEG-4 HE AACv2 設定檔 (增強型 AAC+)
[C-1-4] AAC ELD (增強型低延遲 AAC)
[C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile，其中包含 USAC 基準設定檔，以及 ISO/IEC 23003-4 Dynamic Range Control Profile)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE
[C-1-10] Opus

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

[C-2-1] 解碼時，不得進行下混 (例如 5.0 AAC 串流必須解碼為五聲道 PCM，5.1 AAC 串流必須解碼為六聲道 PCM)。
[C-2-2] 動態範圍中繼資料必須符合 ISO/IEC 14496-3 中的「動態範圍控制 (DRC)」和 android.media.MediaFormat DRC 鍵所定義的規範，用於設定音訊解碼器的動態範圍相關行為。AAC DRC 鍵是在 API 21 中推出，包括 KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_ENCODED_TARGET_LEVEL。

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

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

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

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

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

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

5.1.3. 音訊轉碼器詳細資料

格式/編解碼	詳細資料	支援的檔案類型/容器格式
MPEG-4 AAC 設定檔 (AAC LC)	支援單聲道/立體聲/5.0/5.1 內容，取樣率為 8 到 48 kHz 的標準值。	3GPP (.3gp) MPEG-4 (.mp4、.m4a) ADTS 原始 AAC (.aac，不支援 ADIF) MPEG-TS (.ts，無法尋找)
MPEG-4 HE AAC 格式 (AAC+)	支援單聲道/立體聲/5.0/5.1 內容，標準取樣率介於 16 到 48 kHz 之間。
MPEG-4 HE AACv2 Profile (增強型 AAC+)	支援單聲道/立體聲/5.0/5.1 內容，標準取樣率介於 16 到 48 kHz 之間。
AAC ELD (增強型低延遲 AAC)	支援單聲道/立體聲內容，取樣率為 16 到 48 kHz 的標準值。
USAC	支援單聲道/立體聲內容，取樣率為 7.35 到 48 kHz 的標準取樣率。	MPEG-4 (.mp4、.m4a)
AMR-NB	4.75 至 12.2 kbps，取樣頻率為 8 kHz	3GPP (.3gp)
AMR-WB	9 個速率，從 6.60 kbit/s 到 23.85 kbit/s，取樣率為 16 kHz
FLAC	單聲道/立體聲 (不支援多聲道)。取樣率最高可達 48 kHz (但建議在 44.1 kHz 輸出的裝置上使用 44.1 kHz，因為 48 到 44.1 kHz 的降樣器不包含低通濾波器)。建議使用 16 位元；24 位元不套用抖動。	僅限 FLAC (.flac)
MP3	單聲道/立體聲 8-320 Kbps 固定位元率 (CBR) 或可變位元率 (VBR)	MP3 (.mp3)
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)
Vorbis		Ogg (.ogg) Matroska (.mkv，Android 4.0 以上版本)
PCM/WAVE	16 位元線性 PCM (速率上限為硬體限制)。裝置必須支援 8000、11025、16000 和 44100 Hz 頻率的原始 PCM 錄音取樣率。	WAVE (.wav)
Opus		Matroska (.mkv)、Ogg(.ogg)

5.1.4. 圖片編碼

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

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

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

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)

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)

5.1.7. 視訊轉碼器

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

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

[C-1-1] 視訊編碼器必須支援輸出和輸入位元組緩衝區大小，以便根據標準和設定容納可行的最大壓縮和未壓縮影格，但不得超出分配範圍。
[C-1-2] 影片編碼器和解碼器必須支援 YUV420 彈性色彩格式 (COLOR_FormatYUV420Flexible)。

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

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

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

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

5.1.8. 視訊轉碼器清單

格式/編解碼	詳細資料	支援的檔案類型/ 容器格式
H.263		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	詳情請參閱第 5.2 節和 5.3。	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts，僅限 AAC 音訊，無法跳轉，Android 3.0 以上版本)
H.265 HEVC	詳情請參閱第 5.3 節	MPEG-4 (.mp4)
MPEG-2	主要設定檔	MPEG2-TS
MPEG-4 SP		3GPP (.3gp)
VP8	詳情請參閱第 5.2 節和 5.3。	WebM (.webm) Matroska (.mkv)
VP9	詳情請參閱第 5.3 節	WebM (.webm) Matroska (.mkv)

5.2. 影片編碼

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

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

如果裝置實作包含內嵌螢幕顯示器，且對角長度至少為 2.5 英寸，或包含視訊輸出埠，或透過 android.hardware.camera.any 功能旗標宣告支援相機，則：

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

[C-1-1] 必須支援基準設定檔第 3 級。不過，您可以選擇是否支援 ASO (任意切片排序)、FMO (彈性區塊排序) 和 RS (重複切片)。此外，為維持與其他 Android 裝置的相容性，建議編碼器不要使用 ASO、FMO 和 RS 做為基準設定檔。
[C-1-2] 必須支援下表中的 SD (標準畫質) 影片編碼設定檔。
應支援 Main Profile Level 4。
應支援下表所示的 HD (高畫質) 影片編碼設定檔。

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

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

	SD (低畫質)	SD (高畫質)	HD 720p	HD 1080p
影片解析度	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
影片影格速率	20 fps	30 fps	30 fps	30 fps
影片位元率	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

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

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

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

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

	SD (低畫質)	SD (高畫質)	HD 720p	HD 1080p
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素
影片影格速率	30 fps	30 fps	30 fps	30 fps
影片位元率	800 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.4. VP9

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

應支援寫入 Matroska WebM 檔案。

5.3. 影片解碼

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

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

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

[C-2-1] 必須提供支援 Dolby Vision 的擷取工具。
[C-2-2] 必須在裝置螢幕或標準影片輸出埠 (例如 HDMI)。
[C-2-3] 必須將向下相容基本層 (如有) 的音軌索引設為與合併 Dolby Vision 層的音軌索引相同。

5.3.1. MPEG-2

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

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

5.3.2. H.263

如果裝置實作支援 H.263 解碼器，則必須符合下列條件：

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

5.3.3. MPEG-4

如果裝置實作 MPEG-4 解碼器，則會：

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

5.3.4. H.264

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

[C-1-1] 必須支援主設定檔等級 3.1 和基準設定檔。支援 ASO (任意切片排序)、FMO (彈性區塊排序) 和 RS (重複切片) 為選用功能。
[C-1-2] 必須能夠解碼使用下表所列 SD (標準解析度) 設定檔的影片，且以基準設定檔和主設定檔 Level 3.1 (包括 720p30) 編碼。
應具備解碼 HD (高畫質) 設定檔的功能，如下表所示。

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

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

	SD (低畫質)	SD (高畫質)	HD 720p	HD 1080p
影片解析度	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
影片影格速率	30 fps	30 fps	60 fps	30 fps (60 fps^電視)
影片位元率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

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

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

[C-2-1] 裝置實作方式必須支援至少一種 H.265 或 VP9 解碼功能，以便解碼 720、1080 和 UHD 設定檔。

	SD (低畫質)	SD (高畫質)	HD 720p	HD 1080p	UHD 超高畫質
影片解析度	352 x 288 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片影格速率	30 fps	30 fps	30 fps	30/60 fps (60 fps 適用於^{支援 H.265 硬體解碼的電視})	60 fps
影片位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3.6. VP8

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

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

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

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

	SD (低畫質)	SD (高畫質)	HD 720p	HD 1080p
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素
影片影格速率	30 fps	30 fps	30 fps (60 fps^電視)	30 (60 fps)^電視
影片位元率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

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

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

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

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

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

[C-3-1] 裝置實作方式必須至少支援一種 VP9 或 H.265 解碼功能，以便解碼 720、1080 和 UHD 設定檔。

	SD (低畫質)	SD (高畫質)	HD 720p	HD 1080p	UHD 超高畫質
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片影格速率	30 fps	30 fps	30 fps	30 fps (60 fps，^{支援 VP9 硬體解碼的電視})	60 fps
影片位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.4. 錄音

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

5.4.1. 擷取原始音訊

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

[C-1-1] 必須允許擷取原始音訊內容，且具備下列特性：
- 格式：線性 PCM，16 位元
- 取樣率：8000、11025、16000、44100 Hz
- 管道：單聲道
[C-1-2] 必須以上述取樣率進行擷取，且不得向上取樣。
[C-1-3] 使用上述取樣率進行降採樣時，必須加入適當的反鋸齒濾鏡。
應允許 AM 廣播和 DVD 品質擷取原始音訊內容，也就是下列特性：
- 格式：線性 PCM，16 位元
- 取樣率：22050、48000 Hz
- 聲道：立體聲

如果裝置實作可讓 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 音訊來源的音訊串流時，必須預設停用任何自動增益控制功能。
應以大致平坦的振幅與頻率特性錄製語音辨識音訊串流，具體來說，從 100 Hz 到 4000 Hz 的頻率應為 ±3 dB。
應設定輸入靈敏度，以便在 1000 Hz 的 90 dB 聲音功率級別 (SPL) 來源，為 16 位元樣本產生 2500 的 RMS。
應記錄語音辨識音訊串流，以便 PCM 振幅等級以線性方式追蹤輸入 SPL 的變化，至少在麥克風的 90 dB SPL 下，從 -18 dB 到 +12 dB 變化。
應錄製語音辨識音訊串流，其中 1 kHz 的總諧波失真 (THD) 小於 1%，麥克風的輸入音量為 90 dB SPL。

如果裝置實作宣告為語音辨識調整的 android.hardware.microphone 和雜訊抑制 (減少) 技術，則會：

[C-2-1] 您必須允許使用 android.media.audiofx.NoiseSuppressor API 控制此音效效果。
[C-2-2] 必須透過 AudioEffect.Descriptor.uuid 欄位，明確識別每種噪音抑制技術的實作方式。

5.4.3. 擷取資料，以便重新導向播放內容

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

如果裝置實作項目同時宣告 android.hardware.audio.output 和 android.hardware.microphone，則會發生以下情況：

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

5.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、48000

5.5.2. 音效

Android 提供音訊效果 API，供裝置實作。

如果裝置實作宣告 android.hardware.audio.output 功能，則會：

[C-1-1] 必須支援可透過 AudioEffect 子類別 Equalizer、LoudnessEnhancer 控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 實作項目。
[C-1-2] 必須支援可透過 Visualizer 類別控制的視覺化器 API 實作。
[C-1-3] 必須支援可透過 AudioEffect 子類別 DynamicsProcessing 控制的 EFFECT_TYPE_DYNAMICS_PROCESSING 實作。
應支援可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作。

5.5.3. 音訊輸出音量

汽車裝置實作方式：

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

5.6. 音訊延遲

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

本節的定義如下：

輸出延遲。應用程式寫入 PCM 編碼資料的時間點與裝置端轉換器或信號透過連接埠離開裝置並可在外部觀察到的時間點之間的間隔。
冷輸出延遲。在音訊輸出系統閒置並在要求前關閉電源的情況下，第一個影格的輸出延遲時間。
連續輸出延遲時間。裝置播放音訊後，後續影格輸出延遲時間。
輸入延遲。環境透過裝置端轉換器或信號透過連接埠進入裝置，到應用程式讀取相應 PCM 編碼資料影格之間的間隔。
輸入內容遺失。輸入信號的初始部分，無法使用或無法取得。
冷輸入延遲。當音訊輸入系統在要求前處於閒置狀態並關閉電源時，第一個影格輸入延遲時間和輸入延遲時間的總和。
持續輸入延遲。裝置擷取音訊時，後續影格輸入的延遲時間。
冷輸出抖動。冷輸出延遲值的個別測量值之間的變異。
冷輸入抖動。冷輸入延遲值的個別測量值之間的變異。
連續往返延遲時間。連續輸入延遲時間加上連續輸出延遲時間，再加上一個緩衝區時間。緩衝期可讓應用程式處理訊號，並減少輸入和輸出串流之間的相位差異。
OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 集。
AAudio 原生音訊 API。Android NDK 中的 AAudio API 組合。
時間戳記。這組資料包含串流中的相對影格位置，以及該影格進入或離開相關端點的音訊處理管道的預估時間。另請參閱 AudioTimestamp。

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

[C-SR] 冷啟動輸出延遲時間為 100 毫秒以下
[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-1-1] 請勿回報支援低延遲音訊。

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

[C-SR] 冷啟動輸入延遲時間為 100 毫秒以下。
[C-SR] 連續輸入延遲時間為 30 毫秒或更短。
[C-SR] 持續往返延遲時間為 50 毫秒或更短。
[C-SR] 盡量減少冷輸入抖動。
[C-SR] 將 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回的輸入時間戳記誤差限制在 +/- 1 毫秒內。

5.7. 網路通訊協定

裝置實作方式必須支援 Android SDK 說明文件中指定的媒體網路通訊協定，以便播放音訊和影片。

如果裝置實作包含音訊或視訊解碼器，則必須符合下列條件：

[C-1-1] 必須透過 HTTP(S) 支援第 5.1 節中所有必要的編解碼和容器格式。
[C-1-2] 必須支援下方媒體區段格式表格中列出的媒體區段格式，並採用 HTTP 即時串流草稿通訊協定第 7 版。
[C-1-3] 必須支援下列 RTSP 表格中的 RTP 音訊/視訊設定檔和相關編解碼。如需例外狀況，請參閱第 5.1 節中的表格附註。

媒體區段格式

區隔格式	參考資料	必要的轉碼器支援
MPEG-2 傳輸串流	ISO 13818	影片編碼器： H264 AVC MPEG-4 SP MPEG-2 如要進一步瞭解 H264 AVC、MPEG2-4 SP、和 MPEG-2，請參閱第 5.1.3 節。音訊轉碼器： AAC 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
AAC 搭配 ADTS 格式和 ID3 標記	ISO 13818-7	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節
WebVTT	WebVTT

區隔格式

參考資料

必要的轉碼器支援

MPEG-2 傳輸串流

ISO 13818

影片編碼器：

H264 AVC
MPEG-4 SP
MPEG-2

如要進一步瞭解 H264 AVC、MPEG2-4 SP、
和 MPEG-2，請參閱第 5.1.3 節。

音訊轉碼器：

如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。

AAC 搭配 ADTS 格式和 ID3 標記

ISO 13818-7

如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節

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 節。
H263-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-ES	RFC 6416	如要進一步瞭解 MPEG-4 SP，請參閱第 5.1.3 節。
mpeg4-generic	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 連線功能，包括：
- USB 主機模式，第 7.7 節
- USB 周邊裝置模式，第 7.7 節
- 以藍牙 LE 為媒介的 MIDI 扮演中樞角色，請參閱第 7.4.3 節
[C-1-2] 必須支援應用程式間的 MIDI 軟體傳輸 (虛擬 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 緩衝區佇列和 AAudio 原生音訊 API，以符合延遲和 USB 音訊需求。
[SR] 強烈建議在音訊處於活動狀態且 CPU 負載有所變化時，提供一致的 CPU 效能。您應使用 SimpleSynth 的 1bd6391 版本進行測試。SimpleSynth 應用程式必須搭配下列參數執行，並在 10 分鐘後達到零延遲：
- 工作週期：200,000
- 變化負載：開啟 (每 2 秒會在 100% 和 10% 的工作週期值之間切換，旨在測試 CPU 節流器行為)
- 穩定負載：關閉
應盡量減少音訊時鐘不準確和相對於標準時間的誤差。
在 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] 強烈建議您遵循有線音訊耳機規格 (第 1.1 版)的「行動裝置 (插孔) 規格」一節。
音訊插孔路徑的持續往返音訊延遲時間應不超過 10 毫秒。

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

[C-3-1] 必須實作 USB 音訊類別。
[C-3-2] 必須透過 USB 音訊類別，在 USB 主機模式連接埠上維持 20 毫秒或更短的音訊往返延遲時間。
使用 USB 音訊類別的 USB 主機模式通訊埠，持續往返音訊延遲時間應不超過 10 毫秒。

如果裝置實作包含 HDMI 連接埠，則必須符合下列條件：

[C-4-1] 必須支援以 20 位元或 24 位元深度和 192 kHz 的立體聲和八聲道輸出，且在至少一種設定中不損失位元深度或重新取樣。

5.11. 未處理的擷取畫面

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

如果裝置實作意圖支援未經處理的音訊來源，並將其提供給第三方應用程式，則應：

[C-1-1] 必須透過 android.media.AudioManager 屬性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 回報支援資訊。
[C-1-2] 必須在中頻範圍中呈現大致平坦的振幅與頻率特性：具體來說，每個用於錄製未經處理音訊來源的麥克風，在 100 Hz 到 7000 Hz 之間的振幅與頻率特性，必須介於 ±10 dB 之間。
[C-1-3] 必須顯示低頻範圍的振幅等級：具體來說，從 5 Hz 到 100 Hz 的 ±20 dB 與用於錄製未經處理音訊來源的每個麥克風的中頻範圍相比。
[C-1-4] 必須顯示高頻率範圍的振幅等級：具體來說，從 7000 Hz 到 22 KHz 的振幅等級，必須與用於錄製未經處理音訊來源的每個麥克風的中頻率範圍相符，且相差不得超過 ±30 dB。
[C-1-5] 必須設定音訊輸入靈敏度，以便在使用每個麥克風錄製未經處理的音訊來源時，以 94 dB 的聲壓級 (SPL) 播放 1000 Hz 正弦音源，產生 16 位元取樣 RMS 值 520 (或浮點/雙精度取樣 -36 dB 全量) 的回應。
[C-1-6] 每個用於錄製未經處理音訊來源的麥克風，信噪比 (SNR) 必須為 60 dB 以上。(而 SNR 是指 94 dB SPL 與等效 SPL 的差異，以 A 加權方式計算)。
[C-1-7] 每個用於錄製未經處理音訊來源的麥克風，在 90 dB SPL 輸入音量下，總諧波失真 (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 和 AOSP 提供的殼層指令，這些指令可供應用程式開發人員使用，包括 dumpsys 和 cmd stats。
- [C-0-3] 不得透過 dumpsys 指令記錄的裝置系統事件 (batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats) 變更格式或內容。
- [C-0-10] 必須完整記錄，並讓下列事件可供 cmd stats shell 指令和 StatsManager System API 類別存取。
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] 裝置端 ADB 守護程序必須預設為停用，且必須提供使用者可存取的機制，以便開啟 Android 偵錯橋接器。
- [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 功能。由於 ddm 使用 adb，因此預設情況下應不支援 ddm，但在使用者啟用 Android Debug Bridge 時，則必須支援 ddm，如上所述。
Monkey
- [C-0-8] 必須包含 Monkey 架構，並讓應用程式可使用該架構。
SysTrace
- [C-0-9] 必須支援 Android SDK 說明文件中的 systrace 工具。根據預設，Systrace 必須處於停用狀態，且必須提供使用者可存取的機制來開啟 Systrace。

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

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

6.2. 開發人員選項

Android 提供開發人員可用來設定應用程式開發相關設定的支援功能。

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

[C-0-1] 必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，才能顯示應用程式開發相關設定。上游 Android 實作項目會預設隱藏「開發人員選項」選單，使用者只要依序輕觸「設定」 >「關於裝置」 >「版本號碼」選單項目七 (7) 次，即可啟動「開發人員選項」。
[C-0-2] 必須預設隱藏開發人員選項。
[C-0-3] 必須提供明確的機制，確保啟用開發人員選項時，不會偏袒某個第三方應用程式。必須提供可公開瀏覽的文件或網站，說明如何啟用開發人員選項。這份文件或網站必須可從 Android SDK 文件連結。
啟用開發人員選項且使用者安全有疑慮時，應向使用者顯示持續性的視覺通知。
可透過視覺隱藏或停用開發人員選項選單，暫時限制使用者存取該選單，以免在使用者安全有疑的情況下造成干擾。

7. 硬體相容性

如果裝置包含特定硬體元件，且該元件具有對應的 API (供第三方開發人員使用)：

[C-0-1] 裝置實作項目必須實作 Android SDK 說明文件中所述的 API。

如果 SDK 中的 API 與硬體元件互動，而該硬體元件為選用元件，且裝置實作不含該元件：

[C-0-2] 您仍必須提供元件 API 的完整類別定義 (如 SDK 所述)。
[C-0-3] API 的行為必須以某種合理的方式實作為無作業。
[C-0-4] 在 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 版面配置，以便針對裝置進行適當調整，確保第三方應用程式可在各種硬體設定上順利執行。裝置必須正確實作這些 API 和行為，詳情請參閱本節。

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

實體對角尺寸。螢幕照明部分兩個相對角落之間的距離，以英寸為單位。
每英寸像素數 (dpi)。以 1 英寸的線性橫向或縱向跨距所涵蓋的像素數量。如果列出 dpi 值，橫向和縱向 dpi 都必須落在範圍內。
顯示比例。螢幕長邊和短邊像素的比例。舉例來說，如果螢幕解析度為 480x854 像素，則寬高比為 854/480 = 1.779，或大約為「16:9」。
密度獨立像素 (dp)。虛擬像素單位已歸一化為 160 dpi 螢幕，計算方式如下：pixels = dps * (density/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] 必須透過 AndroidManifest.xml 中的 <supports-screens> 屬性，正確遵循應用程式所聲明的螢幕尺寸支援情形，如 Android SDK 說明文件所述。
螢幕可能採用圓角設計。

如果裝置實作支援 UI_MODE_TYPE_NORMAL，且包含圓角螢幕，則會：

[C-1-1] 請務必確保圓角半徑小於或等於 38 dp。
應提供使用者操作提示，讓使用者切換至具有矩形角落的顯示模式。

7.1.1.2. 螢幕顯示比例

雖然實體螢幕顯示畫面不受螢幕顯示比例值限制，但第三方應用程式在其中算繪的邏輯顯示畫面螢幕顯示比例，可從透過 view.Display API 和 Configuration API 回報的高度和寬度值推算，必須符合下列規定：

[C-0-1] 設定為 UI_MODE_TYPE_NORMAL 的 Configuration.uiMode 裝置實作項目，其顯示比例值必須介於 1.3333 (4:3) 和 1.86 (大約 16:9) 之間，除非應用程式符合下列任一條件，才可視為已準備好進行延長顯示比例：
- 應用程式已透過 android.max_aspect 中繼資料值宣告支援較大的螢幕顯示比例。
- 應用程式會透過 android:resizeableActivity 屬性宣告可調整大小。
- 應用程式指定的 API 級別為 24 以上，且未宣告會限制允許顯示比例的 android:MaxAspectRatio。
[C-0-2] 將 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 的裝置實作項目，其顯示比例值必須設為 1.0 (1:1)。

7.1.1.3. 螢幕密度

Android UI 架構定義了一組標準邏輯密度，協助應用程式開發人員指定應用程式資源。

[C-0-1] 根據預設，裝置實作必須透過 DENSITY_DEVICE_STABLE API 回報下列邏輯 Android 架構密度之一，且此值不得隨時變更；不過，裝置可能會根據使用者在初始啟動後所做的顯示設定變更 (例如顯示大小)，回報不同的任意密度。
- 120 dpi (ldpi)
- 160 dpi (mdpi)
- 213 dpi (tvdpi)
- 240 dpi (高解析度)
- 260 dpi (260dpi)
- 280 dpi (280dpi)
- 300 dpi (300dpi)
- 320 dpi (xhdpi)
- 340 dpi (340dpi)
- 360 dpi (360dpi)
- 400 dpi (400dpi)
- 420 dpi (420dpi)
- 480 dpi (xxhdpi)
- 560 dpi (560dpi)
- 640 dpi (xxxhdpi)
裝置實作項目應定義標準 Android 架構密度，其數值應與螢幕的實體密度最為接近，除非該邏輯密度會使回報的螢幕大小低於最低支援大小。如果標準 Android 架構密度與實體密度數值最接近，但導致螢幕大小小於最小支援的相容螢幕大小 (320 dp 寬度)，則裝置實作應回報下一個較低的標準 Android 架構密度。

如果有可用途徑可變更裝置的顯示大小：

[C-1-1] 顯示大小不得大於原生密度的 1.5 倍，或產生小於 320dp (等同於資源限定詞 sw320dp) 的有效螢幕尺寸下限，以先到為準。
[C-1-2] 顯示器大小不得縮小至原生密度的 0.85 倍以下。
為確保良好的可用性和一致的字型大小，建議您提供下列原生顯示選項的縮放比例 (同時遵守上述限制)
小：0.85 倍
預設值：1x (原生顯示比例)
大：1.15 倍
較大：1.3 倍
最大 1.45 倍

7.1.2. 多媒體廣告指標

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

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

如果裝置實作項目不包含內嵌螢幕或影片輸出內容，則會發生以下情況：

[C-2-1] 針對模擬的預設 view.Display，必須針對 android.util.DisplayMetrics API 中定義的所有多媒體廣告指標回報合理的值。

7.1.3. 螢幕方向

裝置實作方式：

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

如果裝置實作支援這兩種螢幕方向，則會：

[C-1-1] 應用程式必須支援動態螢幕方向，也就是直向或橫向螢幕方向。也就是說，裝置必須遵循應用程式要求的特定螢幕方向。
[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 說明文件所述及詳情說明。
[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 擴充功能。
[SR] 強烈建議支援 EGL_KHR_partial_update。
應透過 getString() 方法，準確回報任何支援的紋理壓縮格式，這通常是特定供應商專屬的格式。

如果裝置實作宣告支援 OpenGL ES 3.0、3.1 或 3.2，則會：

[C-3-1] 除了 libGLESv2.so 程式庫中的 OpenGL ES 2.0 函式符號外，您必須匯出這些版本的相應函式符號。

如果裝置實作項目支援 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，這是一款用於高效能 3D 圖形的低成本跨平台 API。

如果裝置實作項目支援 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 擴充功能。

如果裝置實作項目不支援 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，則會：

[C-3-1] 必須提供 SYNC_FD 外部訊號量和句柄類型的支援。
[SR] 強烈建議支援 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 提供一種機制，讓應用程式宣告要在應用程式、活動、視窗或 View 層級為 2D 圖形啟用硬體加速功能，方法是使用資訊清單標記 android:hardwareAccelerated 或直接 API 呼叫。

裝置實作方式：

[C-0-1] 必須預設啟用硬體加速功能，且如果開發人員要求，則必須停用硬體加速功能，方法是將 android:hardwareAccelerated 設為「false」，或直接透過 Android View API 停用硬體加速功能。
[C-0-2] 必須顯示與 Android SDK 說明文件一致的硬體加速行為。

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

裝置實作方式：

[C-0-3] 必須支援 TextureView API，且必須與上游 Android 實作項目的行為一致。

7.1.4.5 廣色域螢幕

如果裝置實作項目透過 Configuration.isScreenWideColorGamut() 聲稱支援廣色域螢幕，則會：

[C-1-1] 螢幕必須經過色彩校正。
[C-1-2] 螢幕的色域必須涵蓋 CIE 1931 xyY 色域中的完整 sRGB 色域。
[C-1-3] 螢幕的色域範圍必須至少達 CIE 1931 xyY 空間的 DCI-P3 色域 90%。
[C-1-4] 必須支援 OpenGL ES 3.1 或 3.2，並正確回報。
[C-1-5] 必須宣傳支援 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、EGL_EXT_gl_colorspace_display_p3 和 EGL_KHR_gl_colorspace_display_p3 擴充功能。
[SR] 強烈建議支援 GL_EXT_sRGB。

相反地，如果裝置實作不支援廣色域螢幕，則會發生以下情況：

[C-2-1] 應涵蓋 CIE 1931 xyY 色域中 100% 以上的 sRGB，但畫面色彩範圍未定義。

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

Android 會指定「相容模式」，其中架構會以「正常」螢幕大小等效 (320 dp 寬度) 模式運作，以利舊版應用程式 (非針對舊版 Android 開發，且不支援螢幕大小獨立性)。

7.1.6. 螢幕技術

Android 平台包含 API，可讓應用程式在螢幕上算繪豐富的圖形。除非本文件特別允許，否則裝置必須支援 Android SDK 定義的所有 API。

裝置實作方式：

[C-0-1] 必須支援可轉譯 16 位元色彩圖形的螢幕。
應支援可顯示 24 位元彩色圖形的螢幕。
[C-0-2] 必須支援可轉譯動畫的螢幕。
[C-0-3] 必須使用像素顯示比例 (PAR) 介於 0.9 和 1.15 之間的顯示技術。也就是說，像素顯示比例必須接近正方形 (1.0)，容許值為 10% 至 15%。

7.1.7. 次要螢幕

Android 支援第二螢幕，可啟用媒體分享功能，並提供開發人員 API 來存取外部螢幕。

如果裝置實作項目支援透過有線、無線或內嵌額外螢幕連線的外接螢幕，則必須符合下列條件：

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

7.2. 輸入裝置

裝置實作方式：

[C-0-1] 您必須提供輸入機制，例如觸控螢幕或非觸控導覽，以便在 UI 元素之間切換。

7.2.1. 鍵盤

如果裝置實作項目支援第三方輸入法編輯器 (IME) 應用程式，則必須符合下列條件：

[C-1-1] 您必須宣告 android.software.input_methods 功能旗標。
[C-1-2] 必須完全實作 Input Management Framework
[C-1-3] 必須預先安裝軟體鍵盤。

裝置實作：* [C-0-1] 請勿加入不符合 android.content.res.Configuration.keyboard 中指定格式 (QWERTY 或 12 鍵) 的實體鍵盤。* 應納入其他螢幕鍵盤實作。* 可能包含硬體鍵盤。

7.2.2. 非觸控導覽

Android 支援 d-pad、軌跡球和輪盤，做為非觸控導覽機制。

裝置實作方式：

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

如果裝置實作項目缺少非觸控導覽功能，則會發生以下情況：

[C-1-1] 必須提供合理的替代使用者介面機制，用於選取及編輯文字，且必須與輸入管理引擎相容。上游 Android 開放原始碼實作內容包含選取機制，適合用於缺乏非觸控導覽輸入功能的裝置。

7.2.3. 瀏覽鍵

主畫面、最近使用和返回功能通常是透過與專屬實體按鈕或觸控螢幕的特定部分互動來提供，對 Android 導覽模式和裝置實作而言，這些功能至關重要：

[C-0-1] 必須提供使用者操作提示，以便啟動已安裝應用程式，其中活動的 <intent-filter> 已設為 ACTION=MAIN 和 CATEGORY=LAUNCHER，或 CATEGORY=LEANBACK_LAUNCHER (適用於電視裝置實作)。主畫面功能應是這項使用者操作功能的機制。
應提供「最近」和「返回」功能的按鈕。

如果提供「Home」、「Recents」或「Back」功能，則應符合下列條件：

[C-1-1] 必須透過單一動作 (例如輕觸、按兩下或手勢) 即可存取，且該動作必須可供使用。
[C-1-2] 必須清楚指出哪個單一動作會觸發每個函式。例如在按鈕上顯示可見的圖示、在螢幕的導覽列部分顯示軟體圖示，或是在開箱設定體驗期間，引導使用者逐步操作示範流程。

裝置實作方式：

[SR] 強烈建議您不要為 Menu 函式提供輸入機制，因為自 Android 4.0 起，這項功能已淘汰，改為使用動作列。

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

[C-2-1] 只要「動作溢位」選單彈出式視窗不為空白，且可見動作列，就必須顯示「動作溢位」按鈕。
[C-2-2] 請勿透過選取動作列中的溢位按鈕，修改顯示的動作溢位彈出式視窗位置，但您可以透過選取「選單」功能，在畫面上以修改後的位置顯示動作溢位彈出式視窗。

如果裝置實作未提供選單功能，為了向後相容性，裝置必須：* [C-3-1] 在 targetSdkVersion 小於 10 時，透過實體按鈕、軟體鍵或手勢，讓應用程式可使用選單功能。除非與其他導覽功能一併隱藏，否則應可存取此「Menu」功能。

如果裝置實作提供輔助功能，則必須符合以下規定：* [C-4-1] 在可使用其他導覽鍵時，必須透過單一動作 (例如輕觸、雙擊或手勢) 即可存取輔助功能。* [SR] 強烈建議使用長按「HOME」功能做為這項指定互動。

如果裝置實作會使用螢幕的不同部分來顯示導覽鍵，則必須符合下列條件：

[C-5-1] 導覽鍵必須使用螢幕的獨立部分，不得供應用程式使用，且不得遮蓋或以其他方式干擾應用程式可用的螢幕部分。
[C-5-2] 必須向符合第 7.1.1 節規定的應用程式提供部分顯示畫面。
[C-5-3] 應用程式必須遵循透過 View.setSystemUiVisibility() API 方法設定的標記，以便正確隱藏畫面中的這個獨特部分 (即導覽列)，如 SDK 說明文件所述。

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 用途²	Android 按鈕
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
是¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
方向鍵向上¹ 方向鍵向下¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad 左1 D-pad 右¹	0x01 0x0039³	AXIS_HAT_X⁴
左肩按鈕¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
右肩按鈕¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
左搖桿點擊¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
右搖桿點擊¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
主畫面¹	0x0c 0x0223	KEYCODE_HOME (3)
返回¹	0x0c 0x0224	KEYCODE_BACK (4)

1 個 KeyEvent

2 上述 HID 用途必須在遊戲控制器 CA (0x01 0x0005) 中宣告。

3 此用法必須具備以下屬性：邏輯最小值 0、邏輯最大值 7、實體最小值 0、實體最大值 315、單位為度數，以及回報大小為 4。邏輯值的定義是從垂直軸順時針旋轉；例如，邏輯值 0 代表沒有旋轉，且按下向上鍵，而邏輯值 1 代表旋轉 45 度，且同時按下向上鍵和向左鍵。

4 MotionEvent

類比控制項¹	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] 在應用程式處理器處於活動狀態時，如果感應器的串流傳輸延遲時間為 5 毫秒 + 2 * sample_time，則感應器資料的回報延遲時間不得超過 100 毫秒 + 2 * sample_time。這項延遲不包含任何篩選延遲。
[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. 加速計

裝置實作應包含 3 軸式加速度計。

如果裝置實作包含 3 軸式加速度計，則會：

[C-1-1] 必須能夠回報至少 50 Hz 的事件頻率。
[C-1-2] 必須實作並回報 TYPE_ACCELEROMETER 感應器。
[C-1-3] 必須遵循 Android API 中詳述的 Android 感應器座標系統。
[C-1-4] 必須能夠在任何軸向上，測量自由落體的加速度達到重力(4g) 的四倍以上。
[C-1-5] 解析度須至少為 12 位元。
[C-1-6] 標準差不得超過 0.05 m/s^，其中標準差應根據以最快的取樣率，在至少 3 秒的時間內收集的樣本，逐軸計算。
[SR] 強烈建議您導入 TYPE_SIGNIFICANT_MOTION 複合感應器。
[SR] 強烈建議在可使用線上加速計校正功能時，實作 TYPE_ACCELEROMETER_UNCALIBRATED 感應器。
應實作 Android SDK 文件中所述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。
應回報的事件頻率應至少為 200 Hz。
應具有至少 16 位元的解析度。
如果特性在生命週期中變更且經過補償，應在使用中進行校正，並在裝置重新啟動時保留補償參數。
應進行溫度補償。
也應實作 TYPE_ACCELEROMETER_UNCALIBRATED 感應器。

如果裝置實作項目包含 3 軸加速度計，且已實作 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR 或 TYPE_STEP_COUNTER 的複合感應器：

[C-2-1] 耗電量的總和必須一律低於 4 毫瓦。
當裝置處於動態或靜態狀態時，每個值應低於 2 毫瓦和 0.5 毫瓦。

如果裝置實作包含 3 軸加速計和陀螺儀感應器，則會：

[C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
應實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。
[SR] 強烈建議現有和新款 Android 裝置實作 TYPE_GAME_ROTATION_VECTOR 感應器。

如果裝置實作包含 3 軸加速計、陀螺儀感應器和磁力儀感應器，則這些感應器必須符合下列條件：

[C-4-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

7.3.2. 磁力儀

裝置實作應包含 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 軸磁力儀、加速計感應器和陀螺儀感應器，則這些感應器必須符合下列條件：

[C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作包含 3 軸磁力計和加速度計，則會：

可實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。

如果裝置實作包含 3 軸磁力儀、加速度計和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器，則會：

[C-3-1] 耗電量不得超過 10 毫瓦。
感應器以 10 Hz 的頻率註冊批次模式時，耗電量應低於 3 毫瓦。

7.3.3. GPS

裝置實作方式：

應包含 GPS/GNSS 接收器。

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

[C-1-1] 必須支援透過 LocationManager#requestLocationUpdate 要求時，以至少 1 Hz 的頻率輸出位置資訊。
[C-1-2] 連上 0.5 Mbps 以上數據傳輸速率的網際網路時，必須能在 10 秒內 (快速首次定位時間) 判定開放天空環境 (強訊號、多路徑效應微乎其微、HDOP 小於 2) 的位置。通常會透過使用某種形式的輔助或預測 GPS/GNSS 技術，以盡可能縮短 GPS/GNSS 鎖定時間來滿足這項要求 (輔助資料包括參考時間、參考位置和衛星測地/時鐘)。
- [C-1-6] 進行這類位置計算後，裝置實作項目必須在 5 秒內，在開放天空下，在位置要求重新啟動時，在初始位置計算後最多一小時內，即使後續要求是在沒有資料連線和/或電源週期後提出，也必須確定其位置。
在空曠地區確定位置後，如果裝置處於靜止狀態或以每秒平方公尺 1 公尺以下的速度移動，請執行下列操作：
- [C-1-3] 必須能夠在至少 95% 的時間內，判斷出 20 公尺以內的位置，以及每秒 0.5 公尺以內的速度。
- [C-1-4] 必須透過 GnssStatus.Callback 同時追蹤及回報單一星座至少 8 顆衛星。
- 應可同時追蹤至少 24 顆衛星，來自多個星座 (例如 GPS + 至少一個 GLONASS、北斗、Galileo)。
- [C-1-5] 必須透過測試 API「getGnssYearOfHardware」回報 GNSS 技術世代。
- [SR] 在緊急電話通話期間，繼續提供正常的 GPS/GNSS 位置輸出內容。
- [SR] 回報所有追蹤星座的 GNSS 測量資料 (如 GnssStatus 訊息所述)，但 SBAS 除外。
- [SR] 回報 AGC 和全球導航衛星系統測量頻率。
- [SR] 在每個 GPS/GNSS 位置中回報所有預估準確度 (包括方位、速度和垂直)。
- [SR] 強烈建議您盡可能滿足其他強制規定，針對透過 Test API LocationManager.getGnssYearOfHardware() 回報「2016」或「2017」年份的裝置。

如果裝置實作內容包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，且 LocationManager.getGnssYearOfHardware() Test API 回報的日期為「2016」或更新，則：

[C-2-1] 一旦偵測到全球導航衛星系統測量資料，就必須回報，即使尚未回報透過 GPS/全球導航衛星系統計算的位置也一樣。
[C-2-2] 必須回報 GNSS 偽距離和偽距離速率，在確定位置後，在無遮蔽天空的情況下，當裝置處於靜止狀態或以每秒 0.2 公尺以下的加速度移動時，至少有 95% 的時間，系統可計算出位置和速度，誤差範圍分別為 20 公尺和每秒 0.2 公尺。

如果裝置實作包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，且 LocationManager.getGnssYearOfHardware() Test API 回報的日期為「2017」或更新，則：

[C-3-1] 在緊急電話通話期間，必須持續提供正常的 GPS/GNSS 位置輸出內容。
[C-3-2] 必須回報所有追蹤星座的 GNSS 測量值 (如 GnssStatus 訊息所述)，但 SBAS 除外。
[C-3-3] 必須回報 AGC 和 GNSS 測量頻率。
[C-3-4] 必須將所有預估準確度 (包括方位角、速度和垂直) 回報為每個 GPS/GNSS 位置的一部分。

如果裝置實作包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，且 LocationManager.getGnssYearOfHardware() Test API 回報的日期為「2018」或更新，則：

[C-4-1] 在行動基地台 (MS) 網路啟動的緊急通話期間，應用程式必須持續提供正常的 GPS/GNSS 輸出內容。
[C-4-2] 必須將位置和測量值回報至 GNSS Location Provider API。

7.3.4. 陀螺儀

裝置實作方式：

應包含陀螺儀 (角變化感應器)。
除非也包含 3 軸加速計，否則請勿加入陀螺儀感應器。

如果裝置實作包含陀螺儀，則會：

[C-1-1] 必須能夠回報至少 50 Hz 的事件頻率。
[C-1-2] 必須實作 TYPE_GYROSCOPE 感應器，並且應實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。
[C-1-3] 必須能夠以每秒 1,000 度為單位測量方向變化。
[C-1-4] 解析度須為 12 位元以上，且應為 16 位元以上。
[C-1-5] 必須進行溫度補償。
[C-1-6] 在使用期間必須進行校正和補償，並在裝置重新啟動時保留補償參數。
[C-1-7] 變化值不得超過每 Hz 1e-7 弧度^2 / 秒^2 (每 Hz 變化值，或弧度^2 / 秒)。變化範圍可隨取樣率而異，但必須受到此值的限制。換句話說，如果您以 1 Hz 的取樣率測量陀螺儀的變異，其值應不超過 1e-7 rad^2/s^2。
[SR] 強烈建議現有和新款 Android 裝置實作 SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 感應器。
[SR] 當裝置在室溫下靜止時，建議校正誤差應低於 0.01 rad/s。
應回報的事件頻率應至少為 200 Hz。

如果裝置實作項目包含陀螺儀、加速計感應器和磁力儀感應器，則這些感應器必須符合下列條件：

[C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作包含陀螺儀和加速計感應器，則必須：

[C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
[SR] 強烈建議現有和新款 Android 裝置實作 TYPE_GAME_ROTATION_VECTOR 感應器。
應實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。

7.3.5. 氣壓計

裝置實作應包含氣壓計 (環境氣壓感應器)。

如果裝置實作項目包含氣壓計，則會：

[C-1-1] 必須實作並回報 TYPE_PRESSURE 感應器。
[C-1-2] 必須能夠以 5 Hz 以上的頻率傳送事件。
[C-1-3] 必須進行溫度補償。
[SR] 強烈建議您能夠回報 300hPa 到 1100hPa 範圍內的壓力測量值。
應具有 1hPa 的絕對精確度。
應在 20hPa 範圍內，相對準確度為 0.12hPa (相當於在海平面上，約 200m 的變化範圍內，準確度為約 1m)。

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 感應器，且符合下列條件：
- 測量範圍必須至少介於 -8g 和 +8g 之間，建議測量範圍至少介於 -16g 和 +16g 之間。
- 測量解析度必須至少為 2048 LSB/g。
- 測量頻率必須為 12.5 Hz 以下。
- 測量頻率上限必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
- 測量雜訊不得超過 400 μg/√Hz。
- 必須實作此感應器的非喚醒形式，並提供至少 3000 個感應器事件的緩衝功能。
- 必須有批次耗電量，且不得超過 3 毫瓦。
- [C-SR] 強烈建議 3dB 測量頻寬至少為 Nyquist 頻率的 80%，且白噪音頻譜位於這個頻寬內。
- 在室溫下測試時，加速度隨機走樣應小於 30 μg/√Hz。
- 偏差變化與溫度的關係應為 ≤ +/- 1 mg/°C。
- 最佳擬合線非線性應為 0.5% 以下，靈敏度變化與溫度應為 0.03%/°C 以下。
- 在裝置的操作溫度範圍內，應有小於 2.5 % 的橫軸敏感度，以及小於 0.2% 的橫軸敏感度變化。
[C-2-2] TYPE_ACCELEROMETER_UNCALIBRATED 必須符合 TYPE_ACCELEROMETER 的品質規定。
[C-2-3] 必須具備 TYPE_GYROSCOPE 感應器，且符合下列條件：
- 測量範圍必須至少介於 -1000 和 +1000 dps 之間。
- 測量解析度必須至少為 16 LSB/dps。
- 測量頻率必須為 12.5 Hz 以下。
- 測量頻率上限必須為 400 Hz 以上；應支援 SensorDirectChannel RATE_VERY_FAST。
- 測量雜訊不得超過 0.014°/s/√Hz。
- [C-SR] 強烈建議 3dB 測量頻寬至少為 Nyquist 頻率的 80%，且白噪音頻譜位於這個頻寬內。
- 在室溫下測試時，應有小於 0.001 °/s √Hz 的隨機速率。
- 偏差變化與溫度的差異應為 ≤ +/- 0.05 °/ s / °C。
- 溫度變化對應的敏感度應為 ≤ 0.02% / °C。
- 最佳擬合線的非線性應低於 0.2%。
- 噪音密度應低於 0.007 °/s/√Hz。
- 在裝置靜止時，溫度範圍為 10 到 40 ℃ 時，校正誤差應低於 0.002 rad/s。
- 應具有小於 0.1°/s/g 的重力感應器靈敏度。
- 在裝置的操作溫度範圍內，應具有小於 4.0 % 的跨軸靈敏度，以及小於 0.3% 的跨軸靈敏度變化。
[C-2-4] 必須有 TYPE_GYROSCOPE_UNCALIBRATED，且其品質規定與 TYPE_GYROSCOPE 相同。
[C-2-5] 必須具備 TYPE_GEOMAGNETIC_FIELD 感應器，且符合下列條件：
- 測量範圍必須至少介於 -900 和 +900 μT 之間。
- 測量解析度必須至少為 5 LSB/uT。
- 測量頻率必須低於或等於 5 Hz。
- 測量頻率上限必須為 50 Hz 以上。
- 測量雜訊不得超過 0.5 uT。
[C-2-6] 必須有 TYPE_MAGNETIC_FIELD_UNCALIBRATED，且符合與 TYPE_GEOMAGNETIC_FIELD 相同的品質規定，此外：
- 必須實作此感應器的非喚醒形式，且緩衝功能至少可容納 600 個感應器事件。
- [C-SR] 當回報率為 50 Hz 以上時，強烈建議白噪音頻譜從 1 Hz 到至少 10 Hz。
[C-2-7] 必須具備 TYPE_PRESSURE 感應器，且符合下列條件：
- 測量範圍必須至少介於 300 和 1100 hPa 之間。
- 測量解析度必須至少為 80 LSB/hPa。
- 測量頻率必須低於或等於 1 Hz。
- 測量頻率上限必須為 10 Hz 以上。
- 測量雜訊不得超過 2 Pa/√Hz。
- 必須實作此感應器的非喚醒形式，並提供至少 300 個感應器事件的緩衝功能。
- 必須具備不超過 2 毫瓦的批次耗電量。
[C-2-8] 必須具備 TYPE_GAME_ROTATION_VECTOR 感應器，且符合下列條件：
- 必須實作此感應器的非喚醒形式，並提供至少 300 個感應器事件的緩衝功能。
- 必須具備不超過 4 毫瓦的批次耗電量。
[C-2-9] 必須具備 TYPE_SIGNIFICANT_MOTION 感應器，且符合下列條件：
- 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
[C-2-10] 必須具備 TYPE_STEP_DETECTOR 感應器，且符合下列條件：
- 必須實作此感應器的非喚醒形式，且緩衝功能至少要有 100 個感應器事件。
- 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
- 必須具備不超過 4 毫瓦的批次耗電量。
[C-2-11] 必須具備 TYPE_STEP_COUNTER 感應器，且符合下列條件：
- 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
[C-2-12] 必須具備 TILT_DETECTOR 感應器，且符合下列條件：
- 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
[C-2-13] 加速計、陀螺儀和磁力計回報的相同物理事件事件時間戳記，必須相差 2.5 毫秒以內。加速計和陀螺儀回報的相同物理事件事件時間戳記，應在 0.25 毫秒內。
[C-2-14] 陀螺儀感應器事件時間戳記必須與攝影機子系統使用相同的時間基準，且誤差不得超過 1 毫秒。
[C-2-15] 從上述任何物理感應器提供資料至應用程式，必須在 5 毫秒內將資料傳送至應用程式。
[C-2-16] 啟用下列任何感應器組合時，裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時的耗電量不得超過 2.0 毫瓦：
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] 可使用 TYPE_PROXIMITY 感應器，但如果使用，則至少須具備 100 個感應器事件的緩衝區功能。

請注意，本節的所有耗電量要求都不包含應用程式處理器的耗電量。這包括整個感應器鏈路 (感應器、任何支援電路、任何專用感應器處理系統等) 所消耗的電力。

如果裝置實作內容包含直接感應器支援功能，則會：

[C-3-1] 必須透過 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API 正確宣告支援的直接管道類型和直接報表費率層級。
[C-3-2] 對於宣稱支援感應器直接管道的所有感應器，至少必須支援兩種感應器直接管道類型之一。
- TYPE_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. 生物特徵辨識感應器

7.3.10.1. 指紋感應器

如果裝置實作內容包含安全的螢幕鎖定畫面，則必須符合下列條件：

應包含指紋感應器。

如果裝置實作包含指紋感應器，並讓第三方應用程式可存取該感應器，則這些應用程式會：

[C-1-1] 必須宣告支援 android.hardware.fingerprint 功能。
[C-1-2] 必須按照 Android SDK 說明文件中的說明，完整實作對應的 API。
[C-1-3] 錯誤接受率不得高於 0.002%。
[SR] 強烈建議您將冒用和冒充內容的接受率控制在 7% 以下。
[C-1-4] 如果冒用和冒充的接受率高於 7%，則必須揭露這項模式的安全性可能不如高強度的 PIN 碼、解鎖圖案或密碼，並清楚列出啟用這項模式的風險。
[C-1-5] 在指紋驗證失敗五次後，必須至少限制 30 秒的嘗試次數。
[C-1-6] 必須實作硬體支援的 KeyStore，並在受信任的執行環境 (TEE) 或具有與 TEE 安全通道的晶片上執行指紋比對。
[C-1-7] 必須將所有可辨識的指紋資料加密，並透過密碼學驗證，以確保這些資料無法在 TEE 外部取得、讀取或變更，或是具備 Android 開放原始碼專案網站實作指南中所述的 TEE 安全通道。
[C-1-8] 必須先建立信任鏈，才能新增指紋，方法是要求使用者確認現有憑證，或新增由 TEE 保護的新裝置憑證 (PIN 碼/圖形/密碼)；Android 開放原始碼專案實作會在架構中提供相關機制。
[C-1-9] 請勿啟用第三方應用程式，以便區分個別指紋。
[C-1-10] 必須遵守 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT 標記。
[C-1-11] 從 Android 6.0 以下版本升級時，必須安全地遷移指紋資料，以符合上述規定，或將其移除。
[C-1-12] 在移除使用者帳戶 (包括透過恢復原廠設定) 時，必須徹底移除使用者的所有可辨識指紋資料。
[C-1-13] 請勿允許應用程式處理器未經加密的方式存取可辨識的指紋資料，或任何衍生自指紋資料的資料 (例如嵌入資料)。
[SR] 強烈建議錯誤拒絕率低於 10%，測試方式為在裝置上測試。
[SR] 對於註冊的指紋，強烈建議延遲時間低於 1 秒，從觸碰指紋感應器到螢幕解鎖的時間。
應使用 Android 開放原始碼計畫提供的 Android 指紋圖示。

7.3.10.2. 其他生物特徵辨識感應器

如果裝置實作包含一或多個非指紋生物特徵辨識感應器，並將這些感應器提供給第三方應用程式，則：

[C-1-1] 錯誤接受率不得高於 0.002%。
[C-SR] 強烈建議您將冒用和冒充內容的接受率控制在 7% 以下。
[C-1-2] 如果偽造和冒用接受率高於 7%，則必須揭露此模式的安全性可能低於高強度 PIN 碼、解鎖圖案或密碼，並清楚列出啟用此模式的風險。
[C-1-3] 在生物特徵驗證的五次錯誤嘗試後，必須限制嘗試次數，至少為 30 秒 - 其中錯誤嘗試是指擷取品質良好 (ACQUIRED_GOOD)，但不符合已註冊的生物特徵資料
[C-1-4] 必須具備硬體支援的 KeyStore 實作項目，並在 TEE 或具有與 TEE 安全通道的晶片上執行生物特徵辨識比對作業。
[C-1-5] 必須將所有可識別的資料加密並以密碼學方式驗證，以便在 TEE 之外取得、讀取或變更這些資料，或者使用具備與 TEE 連結的安全管道的晶片，如 Android 開放原始碼專案網站的實作指南所述。
[C-1-6] 必須先建立信任鏈，才能新增新的生物特徵辨識系統，方法是要求使用者確認現有的憑證，或新增由 TEE 保護的裝置憑證 (PIN 碼/圖形/密碼)；Android 開放原始碼專案實作項目會在架構中提供相關機制。
[C-1-7] 請勿允許第三方應用程式區分生物特徵註冊。
[C-1-8] 必須使用該生物特徵辨識的個別旗標 (例如：DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS)。
[C-1-9] 在移除使用者帳戶 (包括透過恢復原廠設定) 時，必須徹底移除使用者的所有可辨識生物特徵資料。
[C-1-10] 不得允許應用程式處理器在 TEE 以外的環境中，對可辨識的生物特徵辨識資料或任何衍生自該資料的資料 (例如嵌入資料) 進行未加密存取。
[C-SR] 強烈建議錯誤拒絕率低於 10%，測試方式為在裝置上測試。
[C-SR] 強烈建議每個已註冊的生物特徵辨識功能，從偵測到生物特徵到解鎖螢幕的延遲時間應低於 1 秒。

7.3.11. 僅限 Android Automotive 感應器

汽車專用感應器是在 android.car.CarSensorManager API 中定義。

7.3.11.1. 目前齒輪

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

7.3.11.2. 日間/夜間模式

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

7.3.11.3. 駕駛狀態

這項規定已淘汰。

7.3.11.4. 車輪轉速

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

7.3.11.5。手煞車

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

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 的「telephony」功能和 API 專指語音通話和簡訊。舉例來說，如果裝置無法撥打電話或傳送/接收簡訊，即使使用行動網路進行資料連線，也不算是電話裝置。

Android 可用於不含電話硬體的裝置。也就是說，Android 可與非手機裝置相容。

如果裝置實作包含 GSM 或 CDMA 電話通訊功能，則必須符合下列條件：

[C-1-1] 必須根據技術宣告 android.hardware.telephony 功能旗標和其他子功能旗標。
[C-1-2] 必須完整支援該技術的 API。

如果裝置實作不含電話硬體，則會發生以下情況：

[C-2-1] 必須將完整的 API 實作為無作業。

7.4.1.1. 電話號碼封鎖相容性

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

[C-1-1] 必須支援號碼封鎖功能
[C-1-2] 必須按照 SDK 說明文件的說明，完整實作 BlockedNumberContract 和對應的 API。
[C-1-3] 必須封鎖「BlockedNumberProvider」中所有電話號碼的來電和訊息，且不得與應用程式互動。唯一的例外狀況是，如 SDK 說明文件所述，系統暫時解除電話號碼封鎖。
[C-1-4] 不得針對遭封鎖的通話寫入平台通話記錄供應器。
[C-1-5] 不得針對已封鎖的訊息寫入電話供應商。
[C-1-6] 必須實作封鎖號碼管理 UI，並使用 TelecomManager.createManageBlockedNumbersIntent() 方法傳回的意圖開啟該 UI。
[C-1-7] 絕對不允許次要使用者查看或編輯裝置上的封鎖號碼，因為 Android 平台會假設主要使用者可完全控制裝置上的單一電話服務例項。所有與封鎖相關的使用者介面都必須隱藏給次要使用者，且系統仍必須遵循封鎖清單。
裝置更新至 Android 7.0 時，應將封鎖的號碼遷移至供應商。

7.4.1.2. Telecom API

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

[C-1-1] 必須支援 SDK 中所述的 ConnectionService API。
[C-1-2] 當使用者正在使用第三方應用程式進行通話 (該應用程式不支援透過 CAPABILITY_SUPPORT_HOLD 指定的保留功能) 時，應用程式必須顯示新的來電，並提供使用者接受或拒絕來電的選項。
[C-SR] 強烈建議您通知使用者，接聽來電會中斷正在進行的通話。

AOSP 實作內容會透過提示通知來滿足這些需求，向使用者指出接聽來電會導致另一通通話中斷。
[C-SR] 強烈建議您預先載入預設撥號應用程式，以便在第三方應用程式將 EXTRA_LOG_SELF_MANAGED_CALLS 額外鍵的 PhoneAccount 設為 true 時，顯示通話記錄項目和第三方應用程式的名稱。
[C-SR] 強烈建議您處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，以便支援 android.telecom API，如下所示：
- 在進行中的通話中，如果偵測到短暫按下按鍵事件，請呼叫 Connection.onDisconnect()。
- 在來電期間偵測到短暫按下按鍵事件時，呼叫 Connection.onAnswer()。
- 在來電期間偵測到長按按鍵事件時，呼叫 Connection.onReject()。
- 切換 CallAudioState 的靜音狀態。

7.4.2. IEEE 802.11 (Wi-Fi)

裝置實作方式：

應支援一或多種 802.11 形式。

如果裝置實作內容支援 802.11，並將這項功能公開給第三方應用程式，則必須：

[C-1-1] 必須實作對應的 Android API。
[C-1-2] 必須回報硬體功能旗標 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，該值預設用於應用程式流量，並由 ConnectivityManager API 方法 (例如 getActiveNetwork 和 registerDefaultNetworkCallback) 傳回。換句話說，如果系統成功驗證 Wi-Fi 網路提供網際網路存取服務，則可能只會停用任何其他網路供應商 (例如行動數據) 提供的網際網路存取服務。
[C-SR] 強烈建議在呼叫 ConnectivityManager.reportNetworkConnectivity() API 方法時，重新評估 Network 的網際網路存取權，並在評估結果判定目前 Network 不再提供網際網路存取權後，切換至任何可提供網際網路存取權的其他可用網路 (例如行動數據)。
[C-SR] 強烈建議在 STA 未連線時，每次掃描開始時隨機產生探測要求影格的來源 MAC 位址和序號。
- 每個組探測要求幀應使用一個一致的 MAC 位址 (在掃描過程中，不應隨機產生 MAC 位址)。
- 探測要求序號應在掃描中的探測要求之間正常 (依序) 重複。
- 探測要求序號應在掃描的最後一個探測要求和下次掃描的首個探測要求之間隨機產生。
[C-SR] 在 STA 未連線時，強烈建議您只允許在探測要求封包中使用下列元素：
- SSID 參數集 (0)
- DS 參數集 (3)

如果裝置實作支援 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，且 WiFiManager API 已啟用 TDLS，則會發生以下情況：

[C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。
只有在可行且有益的情況下，才應使用 TDLS。
應採用一些啟發法的做法，並在效能可能低於透過 Wi-Fi 存取點連線時，不要使用 TDLS。

7.4.2.3. Wi-Fi Aware

裝置實作方式：

應支援 Wi-Fi Aware。

如果裝置實作方式支援 Wi-Fi Aware，並將這項功能公開給第三方應用程式，則會發生以下情況：

[C-1-1] 必須實作 WifiAwareManager API，如SDK 說明文件所述。
[C-1-2] 必須宣告 android.hardware.wifi.aware 功能旗標。
[C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
[C-1-4] 必須在 Wi-Fi Aware 管理介面位址啟用時，以不超過 30 分鐘的間隔隨機產生。

如果裝置實作項目支援 Wi-Fi Aware 和 Wi-Fi 位置資訊 (如第 7.4.2.5 節所述)，並將這些功能公開給第三方應用程式，則必須符合下列條件：

[C-2-1] 必須實作位置感知探索 API：setRangingEnabled、setMinDistanceMm、setMaxDistanceMm 和 onServiceDiscoveredWithinRange。

7.4.2.4. Wi-Fi 存取點

裝置實作方式：

應支援 Wi-Fi Passpoint。

如果裝置實作項目支援 Wi-Fi 無線基地台，則必須符合下列條件：

[C-1-1] 必須按照 SDK 說明文件所述，實作與 Passpoint 相關的 WifiManager API。
[C-1-2] 必須支援 IEEE 802.11u 標準，特別是與網路探索和選取相關的標準，例如通用廣告服務 (GAS) 和存取網路查詢通訊協定 (ANQP)。

相反地，如果裝置實作不支援 Wi-Fi 存取點：

[C-2-1] Passpoint 相關 WifiManager API 的實作項目必須擲回 UnsupportedOperationException。

7.4.2.5。Wi-Fi 定位 (Wi-Fi 封包往返時間 - RTT)

裝置實作方式：

應支援 Wi-Fi 位置。

如果裝置實作方式支援 Wi-Fi 位置資訊，並將這項功能公開給第三方應用程式，則裝置會：

[C-1-1] 必須實作 WifiRttManager API，如SDK 說明文件所述。
[C-1-2] 必須宣告 android.hardware.wifi.rtt 功能旗標。
[C-1-3] 執行 RTT 時，如果執行 RTT 的 Wi-Fi 介面未與存取點建立關聯，則必須隨機產生每個 RTT 爆發事件的來源 MAC 位址。

7.4.3. 藍牙

如果裝置實作支援藍牙音訊設定檔，則會：

應支援進階音訊編解碼器和藍牙音訊編解碼器 (例如 LDAC)。

如果裝置實作支援 HFP、A2DP 和 AVRCP，則會：

應支援至少 5 個已連結的裝置。

如果裝置實作宣告 android.hardware.vr.high_performance 功能，則會：

[C-1-1] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能。

Android 支援藍牙和藍牙低功耗。

如果裝置實作項目支援藍牙和藍牙低功耗，則必須：

[C-2-1] 必須宣告相關的平台功能 (分別為 android.hardware.bluetooth 和 android.hardware.bluetooth_le)，並實作平台 API。
應根據裝置需求，實作相關的藍牙設定檔，例如 A2DP、AVRCP、OBEX、HFP 等。

如果裝置實作項目支援藍牙低功耗，則會：

[C-3-1] 必須宣告硬體功能 android.hardware.bluetooth_le。
[C-3-2] 必須啟用 GATT (通用屬性設定檔) 的 Bluetooth API，如 SDK 說明文件和 android.bluetooth 所述。
[C-3-3] 必須回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，以表示是否已實作 ScanFilter API 類別的篩選邏輯。
[C-3-4] 必須回報 BluetoothAdapter.isMultipleAdvertisementSupported() 的正確值，以表示是否支援低耗能廣告。
實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。
應支援將批次掃描作業卸載至藍牙晶片組。
應支援至少 4 個廣告位子的多個廣告。
[SR] 強烈建議您實作可解析私人地址 (RPA) 逾時機制，逾時時間不得超過 15 分鐘，並在逾時時輪替地址，以保護使用者隱私。

如果裝置實作支援藍牙 LE，並使用藍牙 LE 進行位置掃描，則必須：

[C-4-1] 必須提供使用者操作元素，以便透過系統 API BluetoothAdapter.isBleScanAlwaysAvailable() 啟用/停用讀取的值。

7.4.4. 近距離無線通訊

裝置實作方式：

應包含近距離無線通訊 (NFC) 的收發器和相關硬體。
[C-0-1] 必須實作 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，即使這些 API 不支援 NFC 或宣告 android.hardware.nfc 功能，因為這些類別代表不依附通訊協定的資料表示格式。

如果裝置實作包含 NFC 硬體，且打算讓第三方應用程式使用這項功能，則應：

[C-1-1] 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：
[C-1-2] 必須能夠透過下列 NFC 標準，充當 NFC Forum 讀取器/寫入器 (依 NFC Forum 技術規格 NFCForum-TS-DigitalProtocol-1.0 定義)：
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC Forum 標記類型 1、2、3、4、5 (由 NFC Forum 定義)
[SR] 強烈建議您能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息和原始資料。請注意，雖然 NFC 標準列為「強烈建議」，但日後的版本相容性定義預計會將這些標準改為「必須」。這些標準在本版本中為選用標準，但在日後版本中將為必要標準。強烈建議目前和新款搭載此 Android 版本的裝置，現在就符合這些要求，以便日後升級至平台新版本。
[C-1-3] 必須能夠透過下列對等端標準和通訊協定傳送及接收資料：
- ISO 18092
- LLCP 1.2 (由 NFC Forum 定義)
- SDP 1.0 (由 NFC 論壇定義)
- NDEF 推送通訊協定
- SNEP 1.0 (由 NFC Forum 定義)
[C-1-4] 必須支援 Android Beam，並應預設啟用 Android Beam。
[C-1-5] 啟用 Android Beam 或開啟其他專屬 NFC P2p 模式時，應用程式必須能夠使用 Android Beam 傳送及接收資料。
[C-1-6] 必須實作 SNEP 預設伺服器。預設 SNEP 伺服器收到的有效 NDEF 訊息，必須使用 android.nfc.ACTION_NDEF_DISCOVERED 意圖傳送至應用程式。在設定中停用 Android Beam 時，請務必不要停用傳送傳入 NDEF 訊息的功能。
[C-1-7] 必須遵循 android.settings.NFCSHARING_SETTINGS 意圖，顯示 NFC 分享設定。
[C-1-8] 必須實作 NPP 伺服器。NPP 伺服器收到的訊息必須以與 SNEP 預設伺服器相同的方式處理。
[C-1-9] 必須實作 SNEP 用戶端，並在啟用 Android Beam 時嘗試將外寄 P2P NDEF 傳送至預設的 SNEP 伺服器。如果找不到預設的 SNEP 伺服器，用戶端就必須嘗試傳送至 NPP 伺服器。
[C-1-10] 必須允許前景活動使用 android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback 和 android.nfc.NfcAdapter.enableForegroundNdefPush 設定傳出 P2P NDEF 訊息。
在傳送外向 P2P NDEF 訊息前，應使用手勢或畫面上的確認動作 (例如「輕觸即可傳送」)。
[C-1-11] 當裝置支援藍牙物件推送設定檔時，必須支援 NFC 連線轉移至藍牙。
[C-1-12] 使用 android.nfc.NfcAdapter.setBeamPushUris 時，必須支援將連線轉交至藍牙，方法是實作 NFC 論壇的「Connection Handover version 1.2」和「Bluetooth Secure Simple Pairing Using NFC version 1.0」規格。這類實作必須導入「urn:nfc:sn:handover」服務名稱的移交 LLCP 服務，以便透過 NFC 交換移交要求/選取記錄，且必須使用藍牙物件推送設定檔進行實際的藍牙資料傳輸。基於舊版原因 (與 Android 4.1 裝置相容)，實作應仍接受 SNEP GET 要求，以便透過 NFC 交換交接要求/選取記錄。不過，實作本身不應傳送 SNEP GET 要求，以便執行連線移交作業。
[C-1-13] 在 NFC 探索模式下，必須輪詢所有支援的技術。
裝置喚醒、螢幕處於活動狀態，且鎖定螢幕已解鎖時，應處於 NFC 偵測模式。
應能夠讀取 Thinfilm NFC Barcode 產品的條碼和網址 (如果已編碼)。

請注意，上述 JIS、ISO 和 NFC 論壇規格不適用於公開連結。

Android 支援 NFC 主機卡模擬 (HCE) 模式。

如果裝置實作項目包含支援 HCE (適用於 NfcA 和/或 NfcB) 的 NFC 控制器晶片組，並且支援應用程式 ID (AID) 路由，則會：

[C-2-1] 必須回報 android.hardware.nfc.hce 地圖項目常數。
[C-2-2] 必須支援 Android SDK 中定義的 NFC HCE API。

如果裝置實作內容包含支援 NfcF 的 HCE NFC 控制器晶片組，並且為第三方應用程式實作這項功能，則：

[C-3-1] 必須回報 android.hardware.nfc.hcef 地圖項目常數。
[C-3-2] 必須實作 Android SDK 中定義的 NfcF 卡模擬 API。

如果裝置實作符合本節所述的一般 NFC 支援功能，並且在讀取/寫入器角色中支援 MIFARE 技術 (MIFARE Classic、MIFARE Ultralight、MIFARE Classic 上的 NDEF)，則會：

[C-4-1] 必須實作 Android SDK 說明文件中的對應 Android API。
[C-4-2] 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這不是標準的 Android 功能，因此不會在 android.content.pm.PackageManager 類別中顯示為常數。

7.4.5. 最低網路功能

裝置實作方式：

[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] 在使用 RA 生命週期至少 180 秒的任何相容 IPv6 網路上，速率限制絕對不會導致裝置失去 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() 方法時，必須列舉可用的 Secure Elements 讀取器。

7.5. 攝影機

如果裝置實作包含至少一個相機，則會：

[C-1-1] 必須宣告 android.hardware.camera.any 功能旗標。
[C-1-2] 應用程式必須能夠同時配置 3 個 RGBA_8888 位圖，其大小與裝置上解析度最高的相機感應器所產生的圖片大小相同，以便在開啟相機進行基本預覽和靜態影像拍攝時使用。

7.5.1. 後置鏡頭

後置鏡頭是位於裝置螢幕對面側邊的鏡頭，也就是像傳統相機一樣，拍攝裝置遠端的場景。

裝置實作方式：

應包含後置鏡頭。

如果裝置實作包含至少一個後置鏡頭，則必須符合下列條件：

[C-1-1] 必須回報功能旗標 android.hardware.camera 和 android.hardware.camera.any。
[C-1-2] 解析度必須至少為 2000 萬像素。
應在相機驅動程式中實作硬體自動對焦或軟體自動對焦功能 (對應用程式軟體而言是透明的)。
可能會配備固定焦或 EDOF (擴大景深) 硬體。
可包含閃光燈。

如果攝影機有閃光燈：

[C-2-1] 在相機預覽畫面上註冊 android.hardware.Camera.PreviewCallback 例項時，除非應用程式已透過啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性明確啟用閃光燈，否則閃光燈不得亮起。請注意，這項限制不適用於裝置內建的系統相機應用程式，只適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2. 前置鏡頭

前置鏡頭是指位於裝置螢幕同一側的鏡頭，也就是通常用於拍攝使用者影像的鏡頭，例如視訊會議和類似應用程式。

裝置實作方式：

可包含前置鏡頭。

如果裝置實作包含至少一個前置鏡頭，則必須符合下列條件：

[C-1-1] 必須回報功能旗標 android.hardware.camera.any 和 android.hardware.camera.front。
[C-1-2] 解析度必須至少為 VGA (640x480 像素)。
[C-1-3] 請勿將前置鏡頭設為 Camera API 的預設鏡頭，也請勿將 API 設為將前置鏡頭視為預設後置鏡頭，即使前置鏡頭是裝置上唯一的鏡頭也一樣。
[C-1-4] 當目前應用程式透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法明確要求旋轉相機螢幕時，相機預覽畫面必須相對於應用程式指定的方向水平鏡像。反之，如果目前的應用程式未透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法明確要求旋轉相機螢幕，則預覽畫面必須沿著裝置的預設水平軸鏡像。
[C-1-5] 不得將最終擷取的靜態影像或影片串流鏡像，傳回至應用程式回呼或儲存至媒體儲存空間。
[C-1-6] 必須以與攝影機預覽圖像串流相同的方式，鏡像顯示後視鏡顯示的圖像。
可包含第 7.5.1 節所述的後置鏡頭功能 (例如自動對焦、閃光燈等)。

如果裝置實作可由使用者旋轉 (例如透過加速計自動旋轉，或透過使用者輸入手動旋轉)：

[C-2-1] 相機預覽畫面必須相對於裝置目前的方向水平鏡射。

7.5.3. 外接鏡頭

裝置實作方式：

可支援不一定隨時連線的外部攝影機。

如果裝置實作內容支援外接鏡頭，則應符合下列條件：

[C-1-1] 必須宣告平台功能旗標 android.hardware.camera.external 和 android.hardware camera.any。
[C-1-2] 如果外接式攝影機是透過 USB 主機連接埠連線，則必須支援 USB 視訊類別 (UVC 1.0 以上版本)。
[C-1-3] 必須在連接實體外部相機裝置的情況下，通過相機 CTS 測試。如需相機 CTS 測試的詳細資訊，請前往 source.android.com。
應支援 MJPEG 等影片壓縮功能，以便傳輸高品質未編碼的串流 (即原始或獨立壓縮的圖片串流)。
可支援多部攝影機。
可支援以攝影機為基礎的影片編碼。

如果支援以攝影機為基礎的影片編碼：

[C-2-1] 裝置實作必須能夠存取同時未經編碼 / MJPEG 串流 (QVGA 或更高解析度)。

7.5.4. Camera API 行為

Android 包含兩個可存取相機的 API 套件，較新的 android.hardware.camera2 API 會將較低層級的相機控制權公開給應用程式，包括高效率的零複製連拍/串流流程，以及曝光、增益、白平增益、色彩轉換、雜訊消除、銳化等每個影格控制項。

較舊的 API 套件 android.hardware.Camera 已在 Android 5.0 中標示為已淘汰，但仍可供應用程式使用。Android 裝置實作項目必須確保 API 持續支援，如本節和 Android SDK 所述。

在已淘汰的 android.hardware.Camera 類別和較新的 android.hardware.camera2 套件之間，所有共同的功能在兩個 API 中都必須具有相同的效能和品質。舉例來說，在相同的設定下，自動對焦速度和準確度必須相同，拍攝的圖片品質也必須相同。依賴兩個 API 不同語意的功能不必具備相同的速度或品質，但應盡可能相近。

裝置實作項目必須針對所有可用的相機，實作相機相關 API 的以下行為。裝置實作方式：

[C-0-1] 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則必須使用 android.hardware.PixelFormat.YCbCr_420_SP 提供給應用程式回呼的預覽資料。
[C-0-2] 當應用程式註冊 android.hardware.Camera.PreviewCallback 例項，系統呼叫 onPreviewFrame() 方法，且預覽格式為 YCbCr_420_SP 時，byte[] 中的資料必須進一步採用 NV21 編碼格式，才能傳送至 onPreviewFrame()。也就是說，預設值必須是 NV21。
[C-0-3] android.hardware.Camera 的正面和後置鏡頭預覽畫面，都必須支援 YV12 格式 (以 android.graphics.ImageFormat.YV12 常數表示)。(硬體影片編碼器和相機可以使用任何原生像素格式，但裝置實作必須支援轉換為 YV12)。
[C-0-4] 必須支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式，並透過 android.media.ImageReader API 將其做為輸出內容，適用於在 android.request.availableCapabilities 中宣告 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能的 android.hardware.camera2 裝置。
[C-0-5] 無論裝置是否提供硬體自動對焦或其他功能，都必須實作 Android SDK 文件中提供的完整 Camera API。舉例來說，缺少自動對焦功能的相機仍必須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 例項 (即使這與非自動對焦相機無關)。請注意，這項做法也適用於前置鏡頭；舉例來說，即使大多數前置鏡頭不支援自動對焦，API 回呼仍必須按照上述方式「偽造」。
[C-0-6] 必須辨識並遵循 android.hardware.Camera.Parameters 類別中定義為常數的每個參數名稱。相反地，除了 android.hardware.Camera.Parameters 上記錄為常數的字串外，裝置實作不得承認或識別傳遞至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作必須支援所有標準相機參數，且不得支援自訂相機參數類型。舉例來說，如果裝置實作功能支援使用高動態範圍 (HDR) 成像技術拍攝圖片，就必須支援相機參數 Camera.SCENE_MODE_HDR。
[C-0-7] 必須使用 android.info.supportedHardwareLevel 屬性，按照 Android SDK 說明的支援程度回報適當的支援程度，並回報適當的架構功能旗標。
[C-0-8] 必須透過 android.request.availableCapabilities 屬性宣告 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標；如果任何已連結的相機裝置支援該功能，則必須定義功能旗標。
[C-0-9] 每當相機拍攝新相片，且相片項目已新增至媒體儲存庫時，必須廣播 Camera.ACTION_NEW_PICTURE 意圖。
[C-0-10] 相機錄製新影片，且相片項目已新增至媒體儲存空間時，必須廣播 Camera.ACTION_NEW_VIDEO 意圖。
[C-SR] 強烈建議您支援列出 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 功能的邏輯相機裝置，適用於具有多個朝向相同方向的相機的裝置，其中每個實體相機都朝向該方向，只要架構支援實體相機類型，且實體相機的 CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL 為 LIMITED、FULL 或 LEVEL_3 即可。

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] 必須使用預設連接的共用儲存空間進行設定，也就是「開箱即用」，無論儲存空間是實作在內部儲存空間元件或可移除儲存媒體 (例如 Secure Digital 卡插槽) 皆然。
[C-0-3] 必須直接將應用程式共用儲存空間掛載至 Linux 路徑 sdcard，或是加入從 sdcard 到實際掛載點的 Linux 符號連結。
[C-0-4] 必須依照 SDK 說明文件，對這個共用儲存空間強制執行 android.permission.WRITE_EXTERNAL_STORAGE 權限。否則，任何取得該權限的應用程式都必須能寫入共用儲存空間。

裝置實作項目可使用下列任一方式，符合上述規定：

使用者可存取的可卸除式儲存空間，例如 Secure Digital (SD) 卡插槽。
在 Android 開放原始碼計畫 (AOSP) 中實作的部分內部 (不可移除) 儲存空間。

如果裝置實作項目使用可移除的儲存空間來滿足上述要求，則必須符合以下條件：

[C-1-1] 必須實作 Toast 或彈出式使用者介面，在插槽中未插入任何儲存媒體時警告使用者。
[C-1-2] 必須隨附 FAT 格式的儲存媒體 (例如 SD 卡)，或在包裝盒和其他購買時提供的資料中顯示，指出儲存媒體須另外購買。

如果裝置實作項目使用非可移除儲存空間的一部分來滿足上述需求，則必須符合下列條件：

應使用 AOSP 實作內部應用程式共用儲存空間。
可與應用程式私人資料共用儲存空間。

如果裝置實作包含多個共用儲存空間路徑 (例如同時提供 SD 卡插槽和共用內部儲存空間)，則會：

[C-2-1] 僅允許預先安裝且具有 WRITE_EXTERNAL_STORAGE 權限的 Android 特權應用程式寫入次要外部儲存空間，但如果是寫入應用程式專屬目錄或透過觸發 ACTION_OPEN_DOCUMENT_TREE 意圖傳回的 URI，則不在此限。

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，則該裝置會：

[C-3-1] 必須提供機制，從主機電腦存取應用程式共用儲存空間中的資料。
應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，公開顯示兩個儲存路徑的內容。
可使用 USB 大量儲存空間，但應使用媒體傳輸通訊協定來滿足這項規定。

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，且支援媒體傳輸通訊協定，則：

應與 Android MTP 參考主機 Android 檔案傳輸相容。
應回報 0x00 的 USB 裝置類別。
應回報的 USB 介面名稱為「MTP」。

7.6.3. 合併儲存空間

如果裝置的本質是行動裝置，而非電視，則裝置實作方式如下：

[SR] 強烈建議在長期穩定的位置實作可採用的儲存空間，因為不小心中斷連線可能會導致資料遺失/損毀。

如果可拆卸式儲存裝置連接埠位於長期穩定的位置 (例如電池隔間或其他保護蓋內)，裝置實作方式如下：

[SR] 強烈建議您導入可合併儲存空間。

7.7. USB

如果裝置實作有 USB 連接埠，則必須符合下列條件：

應支援 USB 周邊模式，並應支援 USB 主機模式。

7.7.1. USB 周邊裝置模式

如果裝置實作包含支援周邊模式的 USB 連接埠：

[C-1-1] 連接埠必須可連接至具有標準型 A 或型 C USB 連接埠的 USB 主機。
[C-1-2] 必須透過 android.os.Build.SERIAL 回報 USB 標準裝置描述元中的正確 iSerialNumber 值。
[C-1-3] 必須根據 Type-C 電阻標準偵測 1.5A 和 3.0A 充電器，且必須偵測廣告中是否支援 Type-C USB。
[SR] 連接埠應使用 micro-B、micro-AB 或 Type-C USB 板型規格。我們強烈建議現有和新款 Android 裝置符合這些規定，以便日後升級至平台新版本。
[SR] 裝置的連接埠應位於裝置底部 (依照自然方向)，或為所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，以便在裝置以連接埠朝下的方式擺放時，正確顯示畫面。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
[SR] 應實作支援功能，在 HS 嗶嗶聲和流量期間繪製 1.5 A 電流，如 USB 電池充電規格第 1.2 版所述。我們強烈建議現有和新款 Android 裝置符合這些規定，以便日後升級至平台新版本。
[SR] 強烈建議您不要支援會將 Vbus 電壓調高至超過預設等級的專屬充電方法，或變更匯流/來源角色，因為這可能會導致與支援標準 USB 電源供應方法的充電器或裝置發生互通性問題。雖然這項做法被列為「強烈建議」，但在日後的 Android 版本中，我們可能會要求所有 Type-C 裝置支援與標準 Type-C 充電器的完整互通性。
[SR] 強烈建議在支援 Type-C USB 和 USB 主機模式時，支援 Power Delivery 以便進行資料和電力角色互換。
應支援高電壓充電的 Power Delivery，並支援顯示輸出等其他模式。
應按照 Android SDK 說明文件中所述，實作 Android Open Accessory (AOA) API 和規格。

如果裝置實作項目包含 USB 連接埠並實作 AOA 規範，則會：

[C-2-1] 必須宣告支援硬體功能 android.hardware.usb.accessory。
[C-2-2] USB 大量儲存空間類別必須在 USB 大量儲存空間介面說明 iInterface 字串結尾處加入「android」字串

7.7.2. USB 主機模式

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

[C-1-1] 必須實作 Android USB 主機 API，如 Android SDK 中的說明文件所述，並且必須宣告支援硬體功能 android.hardware.usb.host。
[C-1-2] 必須支援連接標準 USB 周邊裝置，也就是說，必須符合下列任一條件：
- 裝置上有 Type-C 連接埠，或隨附的傳輸線可將裝置上的專屬連接埠轉換為標準 USB Type-C 連接埠 (USB Type-C 裝置)。
- 裝置上有 USB 類型 A 連接埠，或隨附的傳輸線可將裝置上的專屬連接埠轉換為標準 USB 類型 A 連接埠。
- 裝置上應具備 micro-AB 連接埠，並隨附可連接至標準 A 型連接埠的傳輸線。
[C-1-3] 不得隨附從 USB Type A 或 micro-AB 連接埠轉換為 Type-C 連接埠 (接收器) 的轉接器。
[SR] 強烈建議您按照 Android SDK 說明文件所述，實作 USB 音訊類別。
應支援在主機模式下為連接的 USB 周邊裝置充電；宣傳的來源電流至少為 1.5A，如 USB Type-C 傳輸線和連接器規格第 1.2 版中針對 USB Type-C 連接器所述的「終止參數」一節所述；或使用「充電下游埠」(CDP) 輸出電流範圍，如 USB 電池充電規格第 1.2 版中針對 Micro-AB 連接器所述。
應實作並支援 USB Type-C 標準。

如果裝置實作項目包含支援主機模式和 USB 音訊類別的 USB 連接埠，則會：

[C-2-1] 必須支援 USB HID 類別。
[C-2-2] 必須支援偵測及對應下列 HID 資料欄位，這些欄位已在 USB HID 用途表和語音指令用途要求中指定，並對應至 KeyEvent 常數，如下所示：
- 用量頁面 (0xC) 用量 ID (0x0CD)：KEYCODE_MEDIA_PLAY_PAUSE
- 使用量頁面 (0xC) 使用量 ID (0x0E9)：KEYCODE_VOLUME_UP
- 用量頁面 (0xC) 用量 ID (0x0EA)：KEYCODE_VOLUME_DOWN
- 用量頁面 (0xC) 用量 ID (0x0CF)：KEYCODE_VOICE_ASSIST

如果裝置實作項目包含支援主機模式和儲存空間存取架構 (SAF) 的 USB 連接埠，則會執行以下操作：

[C-3-1] 必須辨識任何遠端連線的 MTP (媒體傳輸通訊協定) 裝置，並透過 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT 意圖存取其內容。。

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

[C-4-1] 必須實作 USB Type-C 規格 (第 4.5.1.3.3 節) 所定義的雙角色連接埠功能。
[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. 音訊輸出

如果裝置實作包含音訊輸出周邊裝置的喇叭或音訊/多媒體輸出端 (例如使用 USB 音訊類別的 4 導體 3.5 公釐音訊插孔或 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. 類比音訊埠

為了與 Android 生態系統中使用 3.5 公釐音訊插頭的耳機和其他音訊配件相容，如果裝置實作包含一個或多個類比音訊埠，則應符合下列條件：

[C-SR] 強烈建議至少提供一個 4 導體 3.5 公釐耳機插孔的音訊埠。

如果裝置實作項目有 4 導體 3.5 公釐音訊插孔，則應符合下列規定：

[C-1-1] 必須支援音訊播放至立體聲耳機和立體聲耳機麥克風。
[C-1-2] 必須支援 TRRS 音訊插頭，並採用 CTIA 針腳排列順序。
[C-1-3] 必須支援以下 3 個等效阻抗範圍的偵測和對應至按鍵碼功能，這些範圍是音訊插頭上麥克風和接地導體之間的等效阻抗：
- 70 歐姆以下：KEYCODE_HEADSETHOOK
- 210-290 歐姆：KEYCODE_VOLUME_UP
- 360-680 歐姆：KEYCODE_VOLUME_DOWN
[C-1-4] 插頭插入時，必須觸發 ACTION_HEADSET_PLUG，但只有在插頭上的所有接點都接觸到插座上的相關區段時才會觸發。
[C-1-5] 必須能夠在 32 歐姆的喇叭阻抗上，驅動至少 150mV ± 10% 的輸出電壓。
[C-1-6] 麥克風偏壓電壓必須介於 1.8V 至 2.9V 之間。
[C-1-7] 必須偵測音訊插頭上麥克風和接地導體之間等效阻抗的下列範圍，並對應至鍵碼：
- 110-180 歐姆： KEYCODE_VOICE_ASSIST
[C-SR] 強烈建議支援使用 OMTP 針腳排列的音訊插頭。
[C-SR] 強烈建議支援使用內建麥克風的立體聲耳機錄製音訊。

如果裝置實作項目具有 4 導體 3.5 公釐音訊插孔且支援麥克風，並以 1 的額外值麥克風廣播 android.intent.action.HEADSET_PLUG，則會發生以下情況：

[C-2-1] 必須支援偵測已插入的音訊配件上的麥克風。

7.8.3. 近場超音波

近超音波音訊是指 18.5 kHz 到 20 kHz 頻帶。

裝置實作方式：

必須透過 AudioManager.getProperty API 正確回報支援超音波音訊功能，如下所示：

如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 為「true」，VOICE_RECOGNITION 和 UNPROCESSED 音訊來源必須符合下列規定：

[C-1-1] 麥克風在 18.5 kHz 至 20 kHz 頻帶的平均功率響應，必須比 2 kHz 的響應低 15 dB 以下。
[C-1-2] 麥克風在 19 kHz 音調 (-26 dBFS) 的情況下，超過 18.5 kHz 至 20 kHz 的未加權訊噪比不得低於 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

[C-2-1] 揚聲器在 18.5 kHz 至 20 kHz 的平均響應，必須比 2 kHz 的響應低 40 dB。

7.9. 虛擬實境

Android 提供 API 和設施，可用於建構「虛擬實境」(VR) 應用程式，包括高品質的行動 VR 體驗。裝置實作項目必須正確實作這些 API 和行為，詳情請參閱本節。

7.9.1. 虛擬實境模式

Android 支援VR 模式，這項功能可處理通知的立體渲染，並在 VR 應用程式獲得使用者焦點時停用單眼系統 UI 元件。

7.9.2. 虛擬實境模式 - 高效能

如果裝置實作支援 VR 模式，則會：

[C-1-1] 至少須有 2 個實體核心。
[C-1-2] 必須宣告 android.hardware.vr.high_performance 功能。
[C-1-3] 必須支援持續效能模式。
[C-1-4] 必須支援 OpenGL ES 3.2。
[C-1-5] 必須支援 android.hardware.vulkan.level 0。
應支援 android.hardware.vulkan.level 1 以上版本。
[C-1-6] 必須實作 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content、EGL_EXT_image_gl_colorspace，並在可用的 EGL 擴充功能清單中公開這些擴充功能。
[C-1-8] 必須實作 GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2、GL_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] 必須實作支援 AHardwareBuffer 標記 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT，如 NDK 所述。
[C-1-10] 必須支援 AHardwareBuffer，且至少支援下列格式的使用標記 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 的任意組合：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
[C-SR] 強烈建議您支援分配多個層級的 AHardwareBuffer，以及 C-1-10 中指定的標記和格式。
[C-1-11] 必須支援 H.264 解碼，解碼畫質至少為 3840 x 2160，以 30 fps 解析度解碼，並壓縮至平均 40 Mbps (相當於 4 個 1920 x 1080 的例項，以 30 fps 解析度解碼，壓縮至 10 Mbps，或 2 個 1920 x 1080 的例項，以 60 fps 解析度解碼，壓縮至 20 Mbps)。
[C-1-12] 必須支援 HEVC 和 VP9，且必須能夠解碼至少 1920 x 1080 的畫面，解碼後的畫面大小經過壓縮後平均為 10 Mbps，並且應能夠解碼 3840 x 2160 的畫面，解碼後的畫面大小經過壓縮後平均為 30 fps-20 Mbps (相當於 1920 x 1080 的 4 個執行個體，解碼後的畫面大小經過壓縮後平均為 30 fps-5 Mbps)。
[C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回正確的皮膚溫度值。
[C-1-14] 必須有嵌入式螢幕，且解析度至少為 1920 x 1080。
[C-SR] 強烈建議顯示解析度至少為 2560 x 1440。
[C-1-15] 在 VR 模式下，螢幕更新率必須至少為 60 Hz。
[C-1-17] 螢幕必須支援低延遲模式，延遲時間不得超過 5 毫秒，延遲時間是指像素發光的時間長度。
[C-1-18] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能第 7.4.3 節。
[C-1-19] 必須支援並正確回報下列所有預設感應器類型的直接管道類型：
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR] 強烈建議您為上述所有直接管道類型支援 TYPE_HARDWARE_BUFFER 直接管道類型。
[C-1-21] 必須符合第 7.3.9 節所述的 android.hardware.hifi_sensors 陀螺儀、加速計和磁力計相關要求。
[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.省電模式

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

[C-1-1] 應用程式待命和 Doze 省電模式的觸發、維護、喚醒演算法，以及使用全域系統設定時，請務必遵循 AOSP 實作方式。
[C-1-2] 不得偏離 Android 開放原始碼計畫的實作方式，使用全域設定來管理應用程式待命狀態中各個區塊中的工作、鬧鐘和網路的節流。
[C-1-3] 應用程式待命功能使用的應用程式待命值區數量，不得偏離 AOSP 實作。
[C-1-4] 必須按照「電源管理」一節所述，實作「應用程式待命區塊」和「打盹」功能。
[C-1-5] 裝置處於省電模式時，必須為 PowerManager.isPowerSaveMode() 傳回 true。
[C-SR] 強烈建議您提供使用者操作提示，讓使用者能夠啟用及停用省電模式。
[C-SR] 強烈建議您提供使用者操作提示，顯示所有不受應用程式待命和打盹省電模式影響的應用程式。

除了省電模式之外，Android 裝置實作項目也可能會實作進階設定和電源介面 (ACPI) 定義的 4 種睡眠電源狀態中的任何一種或全部。

如果裝置實作項目實作 ACPI 定義的 S4 電源狀態，則會：

[C-1-1] 裝置必須在使用者採取明確動作將裝置設為非活動狀態 (例如關閉裝置實體蓋子或關閉車輛或電視) 後，且在使用者重新啟用裝置 (例如開啟蓋子或重新開啟車輛或電視) 前，才可進入這個狀態。

如果裝置實作符合 ACPI 定義的 S3 電源狀態，則會：

[C-2-1] 必須符合上述 C-1-1 規定，或僅在第三方應用程式不需要系統資源 (例如螢幕、CPU) 時，才進入 S3 狀態。

相反地，當第三方應用程式需要系統資源時，必須退出 S3 狀態，如本 SDK 所述。

舉例來說，當第三方應用程式要求透過 FLAG_KEEP_SCREEN_ON 保持螢幕開啟，或透過 PARTIAL_WAKE_LOCK 讓 CPU 持續運作時，裝置不得進入 S3 狀態，除非使用者採取明確的動作，將裝置設為非活動狀態，如 C-1-1 所述。相反地，如果第三方應用程式透過 JobScheduler 執行的工作觸發，或是 Firebase 雲端通訊傳送至第三方應用程式，則裝置必須退出 S3 狀態，除非使用者將裝置設為非活動狀態。以上範例並非完整列舉，AOSP 實作了廣泛的喚醒信號，可從這個狀態喚醒裝置。

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 平台安全性模型一致的安全性模型，如 Android 開發人員說明文件中 API 的安全性和權限參考文件所定義。
[C-0-2] 必須支援自行簽署應用程式的安裝作業，且不必取得任何第三方/主管機關的額外權限/憑證。具體來說，相容裝置必須支援下列子節所述的安全機制。

9.1. 權限

裝置實作方式：

[C-0-1] 必須支援 Android 開發人員文件中定義的 Android 權限模型。具體來說，他們必須強制執行 SDK 說明文件中定義的每項權限；不得省略、變更或忽略任何權限。
可新增其他權限，但新權限 ID 字串不得位於 android.\* 命名空間。
[C-0-2] protectionLevel 為 PROTECTION_FLAG_PRIVILEGED 的權限，必須只授予在系統映像檔的特殊權限路徑中預先安裝的應用程式，且必須在每個應用程式的明確許可清單權限子集內。AOSP 實作方式是讀取 etc/permissions/ 路徑中的檔案，並尊重每個應用程式的許可清單權限，並使用 system/priv-app 路徑做為特殊權限路徑。

防護等級為危險的權限是執行階段權限。targetSdkVersion 大於 22 的應用程式會在執行階段要求這些權限。

裝置實作方式：

[C-0-3] 必須顯示專用介面，讓使用者決定是否授予要求的執行階段權限，並提供介面讓使用者管理執行階段權限。
[C-0-4] 必須有且只有一個實作兩個使用者介面。
[C-0-5] 請勿向預先安裝的應用程式授予任何執行階段權限，除非：
- 您可以在應用程式使用前取得使用者同意聲明。
- 執行階段權限與意圖模式相關聯，預先安裝的應用程式會設為預設處理常式。
[C-0-6] 請務必只將 android.permission.RECOVER_KEYSTORE 權限授予註冊了安全復原代理程式的系統應用程式。我們將「適當安全的復原代理程式」定義為裝置端軟體代理程式，可與裝置外部遠端儲存空間同步，且配備安全硬體，其保護力與 Google Cloud 密鑰金庫服務中所述的保護力相當或更強，以防範鎖定畫面知識因素的暴力攻擊。

如果裝置實作內容包含預先安裝的應用程式，或希望允許第三方應用程式存取使用統計資料，則應採取以下做法：

[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] 替代執行階段不得啟動、授予或授予其他應用程式超級使用者 (root) 或任何其他使用者 ID 的任何權限。
[C-0-7] 當裝置實作內容的系統映像檔包含其他執行階段的 .apk 檔案時，該檔案必須使用與用於簽署裝置實作內容中其他應用程式的金鑰不同的金鑰進行簽署。
[C-0-8] 安裝應用程式時，替代執行階段必須取得使用者同意，才能使用應用程式所需的 Android 權限。
[C-0-9] 如果應用程式需要使用具有對應 Android 權限 (例如相機、GPS 等) 的裝置資源，替代執行階段必須通知使用者，應用程式將可存取該資源。
[C-0-10] 如果執行階段環境未以這種方式記錄應用程式功能，則在安裝使用該執行階段的任何應用程式時，執行階段環境必須列出執行階段本身所持有的所有權限。
替代執行階段應透過 PackageManager 將應用程式安裝到個別的 Android 沙箱 (Linux 使用者 ID 等)。
替代執行階段可提供單一 Android 沙箱，供使用替代執行階段的所有應用程式共用。

9.5. 支援多位使用者

Android 支援多位使用者，並提供完整的使用者隔離功能。

如果裝置實作使用可移除媒體做為主要外部儲存空間，則可以啟用多使用者功能，但不應強制啟用。

如果裝置實作包含多位使用者，則裝置會執行以下操作：

[C-1-1] 必須符合下列與多使用者支援相關的規定。
[C-1-2] 必須為每位使用者實作與 Android 平台安全模型一致的安全模型，如 API 中的安全性和權限參考文件所定義。
[C-1-3] 每個使用者例項都必須有獨立的共用應用程式儲存空間 (又稱為 /sdcard) 目錄。
[C-1-4] 請務必確保由特定使用者擁有並以其名義執行的應用程式，無法列出、讀取或寫入任何其他使用者擁有的檔案，即使兩者的資料儲存在相同的磁區或檔案系統中也一樣。
[C-1-5] 啟用多使用者功能時，必須使用金鑰加密 SD 卡的內容，該金鑰只能儲存在系統可存取的非可移除媒體上 (如果裝置實作會使用可移除媒體的話，則適用於外部儲存空間 API)。由於這會導致主機電腦無法讀取媒體，因此裝置實作必須切換至 MTP 或類似系統，讓主機電腦存取目前使用者的資料。

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

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

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

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

9.6. 付費簡訊警告

Android 支援警告使用者任何傳送的付費簡訊。「付費簡訊」是指傳送至電信業者註冊服務的簡訊，可能會向使用者收費。

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

[C-1-1] 必須在傳送簡訊給裝置中 /data/misc/sms/codes.xml 檔案中定義的規則所識別的號碼之前，先向使用者發出警告。上游 Android 開放原始碼專案提供符合這項需求的實作方式。

9.7. 安全防護機制

裝置實作項目必須確保符合核心和平台的安全防護功能，如下所述。

Android 沙箱包含使用 Security-Enhanced Linux (SELinux) 強制存取控制 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全性功能。裝置實作方式：

[C-0-1] 即使在 Android 架構下實作 SELinux 或任何其他安全性功能，也必須維持與現有應用程式的相容性。
[C-0-2] 在 Android 架構下實作的安全性功能偵測到安全性違規並成功封鎖時，應用程式不得顯示使用者介面，但如果未封鎖安全性違規，導致攻擊成功，則應用程式可顯示使用者介面。
[C-0-3] 絕對不得讓使用者或應用程式開發人員設定 Android 架構下方實作的 SELinux 或任何其他安全性功能。
[C-0-4] 應用程式不得透過 API (例如 Device Administration API) 影響其他應用程式，以便設定會破壞相容性的政策。
[C-0-5] 必須將媒體架構分割成多個程序，以便根據 Android 開放原始碼專案網站說明，為每個程序授予更精確的存取權。
[C-0-6] 必須實作核心應用程式沙箱機制，以便使用多執行緒程式的可設定政策篩選系統呼叫。上游 Android 開放原始碼計畫透過啟用 seccomp-BPF 與執行緒群組同步處理 (TSYNC) 來滿足這項要求，如 source.android.com 的「核心設定」一節所述。

核心完整性和自我防護功能是 Android 安全防護的關鍵。裝置實作方式：

[C-0-7] 必須實作核心堆疊緩衝區溢位保護機制 (例如 CONFIG_CC_STACKPROTECTOR_STRONG)。
[C-0-8] 必須實作嚴格的核心記憶體保護機制，讓可執行的程式碼為唯讀、唯讀資料無法執行且無法寫入，而可寫入的資料無法執行 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
[C-0-9] 在原先搭載 API 級別 28 以上版本的裝置上，必須針對使用者空間和核心空間 (例如 CONFIG_HARDENED_USERCOPY) 之間的複本，實作靜態和動態物件大小邊界檢查。
[C-0-10] 在原先搭載 API 級別 28 以上版本的裝置上，執行核心模式 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 時，請務必不要執行使用者空間記憶體。
[C-0-11] 在原先搭載 API 級別 28 以上版本的裝置上，除了使用一般 usercopy 存取 API (例如硬體 PAN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 外，絕對不可在核心中讀取或寫入使用者空間記憶體。
[C-0-12] 必須在所有原先搭載 API 級別 28 以上版本 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 `CONFIG_UNMAP_KERNEL_AT_EL0) 的裝置上實作核心頁面表隔離功能。
[SR] 強烈建議您將僅在初始化期間寫入的核心資料，在初始化後標示為唯讀 (例如 __ro_after_init)。
[SR] 強烈建議您將核心程式碼和記憶體的版面配置設為隨機，並避免可能影響隨機化的曝光 (例如，透過 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 使用引導程式熵的 CONFIG_RANDOMIZE_BASE)。

如果裝置實作項目使用 Linux 核心，則會：

[C-1-1] 必須實作 SELinux。
[C-1-2] 必須將 SELinux 設為全域強制執行模式。
[C-1-3] 必須在強制模式下設定所有網域。不允許使用寬鬆模式網域，包括特定裝置/供應商的網域。
[C-1-4] 絕對不可修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 提供的 system/sepolicy 資料夾內的 neverallow 規則，且政策必須針對 AOSP SELinux 網域和裝置/供應商專屬網域，與所有現有 neverallow 規則一起編譯。
[C-1-5] 必須在每個應用程式的 SELinux 沙箱中執行指定 API 級別 28 以上版本的第三方應用程式，並在每個應用程式的私人資料目錄中設定個別的 SELinux 限制。
應保留上游 Android 開放原始碼計畫的 system/sepolicy 資料夾中提供的預設 SELinux 政策，並只針對自身裝置專屬的設定進一步新增此政策。

如果裝置實作已在較舊的 Android 版本上推出，且無法透過系統軟體更新符合 [C-1-1] 和 [C-1-5] 規定，則可免除這些規定。

如果裝置實作使用 Linux 以外的核心，則會發生以下情況：

[C-2-1] 必須使用與 SELinux 等同的強制存取控制系統。

Android 包含多項防禦深度功能，這些功能是裝置安全性不可或缺的要素。

裝置實作方式：

[C-SR] 強烈建議您不要在已啟用控制流程完整性 (CFI) 或整數溢位清理 (IntSan) 的元件上停用這些功能。
[C-SR] 強烈建議您為任何其他安全性敏感的使用者空間元件啟用 CFI 和 IntSan，如 CFI 和 IntSan 所述。

9.8. 隱私權

9.8.1。用量記錄

Android 會儲存使用者選擇的記錄，並透過 UsageStatsManager 管理這類記錄。

裝置實作方式：

[C-0-1] 必須保留這類使用者記錄一段合理的時間。
[SR] 強烈建議保留 AOSP 實作中預設設定的 14 天保留期限。

Android 會使用 StatsLog 識別碼儲存系統事件，並透過 StatsManager 和 IncidentManager 系統 API 管理這類記錄。

裝置實作方式：

[C-0-2] 由 System API 類別 IncidentManager 建立的事件報告中，只能包含標示為 DEST_AUTOMATIC 的欄位。
[C-0-3] 請勿使用系統事件 ID 記錄 StatsLog SDK 文件中未提及的任何其他事件。如果記錄其他系統事件，可能會使用 100,000 到 200,000 之間的不同原子 ID。

9.8.2. 錄製

裝置實作方式：

[C-0-1] 未經使用者同意，或未清除目前的通知，不得預先載入或發布會傳送使用者私人資訊 (例如按鍵動作、螢幕上顯示的文字) 的軟體元件。

如果裝置實作內容包含系統中的功能，用於擷取畫面上顯示的內容和/或錄製裝置上播放的音訊串流，則必須符合下列條件：

[C-1-1] 啟用這項功能並進行擷取/錄影時，必須持續向使用者發出通知。

如果裝置實作包含可立即啟用的元件，能夠錄製環境音訊，並推斷使用者情境的實用資訊，則必須：

[C-2-1] 除非經過使用者明確同意，否則不得將錄製的原始音訊或任何可轉換回原始音訊或近似影本的格式，儲存在裝置上的永久性儲存空間或傳送離開裝置。

9.8.3. 連線能力

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，則該裝置會：

[C-1-1] 必須先顯示使用者介面，要求使用者同意，才能透過 USB 連接埠存取共用儲存空間的內容。

9.8.4。網路流量

裝置實作方式：

[C-0-1] 必須為系統信任的憑證授權單位 (CA) 存放區預先安裝與上游 Android 開放原始碼計畫提供的相同根憑證。
[C-0-2] 必須提供空白的使用者根 CA 儲存庫。
[C-0-3] 新增使用者根 CA 時，必須向使用者顯示警告，指出網路流量可能會受到監控。

如果裝置流量是透過 VPN 轉送，裝置實作方式如下：

[C-1-1] 必須向使用者顯示警告，指出下列任一事項：
- 該網路流量可能會受到監控。
- 該網路流量會透過提供 VPN 的特定 VPN 應用程式轉送。

如果裝置實作有預設啟用的機制，可透過 Proxy 伺服器或 VPN 閘道轉送網路資料流量 (例如，在授予 android.permission.CONTROL_VPN 時預先載入 VPN 服務)，則會發生以下情況：

[C-2-1] 必須在啟用該機制前徵求使用者同意，除非該 VPN 是透過 DevicePolicyManager.setAlwaysOnVpnPackage() 由裝置政策控制器啟用，在這種情況下，使用者不需要提供個別同意聲明，但必須收到通知。

如果裝置實作可讓使用者切換第三方 VPN 應用程式「永久連線 VPN」功能的使用者操作元素，則必須符合下列條件：

[C-3-1] 對於不支援永久連線 VPN 服務的應用程式，請務必在 AndroidManifest.xml 檔案中將 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 屬性設為 false，以便停用這項使用者操作選項。

9.9. 資料儲存加密

如果進階加密標準 (AES) 加密效能 (以裝置上可用的 AES 技術 (例如 ARM 加密擴充功能) 為準) 超過 50 MiB/秒，則裝置實作方式如下：

[C-1-1] 必須支援應用程式私人資料 (/data 分區) 的資料儲存加密功能，以及應用程式共用儲存空間分區 (/sdcard 分區) (如果是裝置的永久性、不可移除的部分)，但一般共用裝置實作 (例如電視) 除外。
[C-1-2] 在使用者完成開箱即用體驗時，必須預設啟用資料儲存加密功能，但通常共用的裝置實作 (例如電視) 除外。

如果 AES 加密效能低於或等於 50 MiB/秒，裝置實作可能會使用 Adiantum-XChaCha12-AES，而非下列任何一種 AES 形式：第 9.9.2 節 [C-1-5] 中的 AES-256-XTS；第 9.9.2 節 [C-1-6] 中的 AES-256 在 CBS-CTS 模式下；第 9.9.3 節 [C-1-1] 中的 AES；第 9.9.3 節 [C-1-3] 中的 AES。

如果裝置實作已在舊版 Android 上推出，且無法透過系統軟體更新符合上述規定，則可能不受上述規定限制。

裝置實作方式：

應透過實作檔案為基礎的加密 (FBE) 來滿足上述資料儲存加密需求。

9.9.1. 直接啟動

裝置實作方式：

[C-0-1] 即使 Direct Boot 模式 API 不支援儲存空間加密功能，也必須實作這些 API。
[C-0-2] ACTION_LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED 意圖仍須廣播，以便向直接啟動感知應用程式傳送訊號，指出裝置加密 (DE) 和憑證加密 (CE) 儲存位置可供使用者使用。

9.9.2. 檔案型加密

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

[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 加密檔案內容。AES-256-XTS 是指在 XTS 模式下運作的 256 位元金鑰長度進階加密標準。XTS 金鑰的完整長度為 512 位元。
[C-1-6] 必須支援使用 CBC-CTS 模式的 AES-256 加密檔案名稱。
保護 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 核心 ext4 加密功能為基礎。

9.9.3. 全磁碟加密

如果裝置實作支援全磁碟加密 (FDE)，則會：

[C-1-1] 請務必在專為儲存空間設計的模式下使用 AES (例如 XTS 或 CBC-ESSIV)，且加密金鑰長度為 128 位元以上。
[C-1-2] 必須使用預設密碼包裝加密金鑰，且不得在任何時間將未經加密的加密金鑰寫入儲存空間。
[C-1-3] 必須預設使用 AES 加密金鑰，除非使用者明確選擇不使用，且鎖定螢幕憑證處於使用狀態，否則使用緩慢的拉伸演算法 (例如 PBKDF2 或 scrypt) 進行拉伸。
[C-1-4] 如果使用者未指定螢幕鎖定畫面憑證，或已停用密碼用於加密，且裝置提供硬體支援的 KeyStore，則上述預設密碼拉長演算法必須以加密方式繫結至該 KeyStore。
[C-1-5] 絕對不得將加密金鑰傳送出裝置 (即使包裝使用者密碼和/或硬體綁定金鑰也一樣)。

上游 Android 開放原始碼專案提供這項功能的偏好實作方式，以 Linux 核心功能 dm-crypt 為基礎。

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] 除非使用者已明確解鎖 Bootloader，否則不得修改裝置上的已驗證分區。
[C-SR] 如果裝置中有多個獨立晶片 (例如無線電、專用圖像處理器)，強烈建議在啟動時驗證每個晶片的啟動程序。
[C-1-8] 請務必使用防竄改儲存空間：用於儲存是否已解鎖 Bootloader 的資料。防竄改儲存空間是指引導程式可偵測儲存空間是否遭到 Android 內部竄改。
[C-1-9] 必須在使用裝置時提示使用者，並要求使用者實際確認，才能從啟動載入程式鎖定模式切換至啟動載入程式解鎖模式。
[C-1-10] 必須針對 Android 使用的分區 (例如啟動分區、系統分區) 實作回溯保護機制，並使用防竄改儲存空間來儲存用於判斷允許的最低 OS 版本的中繼資料。
[C-SR] 強烈建議您使用根源於 /system 且受驗證開機程序保護的信任鏈結，驗證所有特權應用程式 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] 務必確保安全硬體可完全控制觸控螢幕。

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 系統支援的演算法。安全隔離功能必須封鎖所有可能的機制，以免核心或使用者空間程式碼存取隔離環境的內部狀態，包括 DMA。上游 Android 開放原始碼計畫 (AOSP) 使用 Trusty 實作項目來滿足這項規定，但其他以 ARM TrustZone 為基礎的解決方案，或第三方審查的安全實作項目，也是適當的虛擬機器人隔離方式。
[C-1-3] 必須在隔離執行環境中執行螢幕鎖定畫面驗證，且只有在驗證成功時，才允許使用與驗證綁定的金鑰。螢幕鎖定憑證必須以只允許隔離執行環境執行螢幕鎖定驗證的方式儲存。上游 Android 開放原始碼計畫提供 Gatekeeper 硬體抽象層 (HAL) 和 Trusty，可用於滿足這項需求。
[C-1-4] 必須支援金鑰認證，其中認證簽署金鑰受到安全硬體保護，且簽署作業是在安全硬體中執行。認證簽署金鑰必須在大量裝置間共用，以免被用作裝置 ID。如要符合這項規定，您可以共用相同的認證金鑰，除非您生產的特定 SKU 數量至少達 100,000 個。如果某個 SKU 的產量超過 100,000 個，則每 100,000 個單位可能會使用不同的鍵。
[C-1-5] 必須允許使用者選擇休眠逾時時間，以便從解鎖狀態轉換為鎖定狀態，最短逾時時間不得超過 15 秒。

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

9.11.1. 安全螢幕鎖定畫面

AOSP 實作項目採用分層驗證模式，其中以知識工廠為基礎的主要驗證作業可由次要強大生物特徵辨識或次要弱式生物特徵辨識支援。

裝置實作方式：

[C-SR] 強烈建議您只將下列其中一種方法設為主要驗證方法：
- 數字 PIN 碼
- 英數密碼
- 在 3x3 點的格狀圖案上滑動

請注意，上述驗證方法是本文中建議的主要驗證方法。

如果裝置實作新增或修改建議的主要驗證方法，並使用新驗證方法做為鎖定螢幕的安全方法，新驗證方法必須符合下列條件：

[C-2-1] 必須是「要求驗證使用者才能使用金鑰」一文中所述的使用者驗證方法。
[C-2-2] 使用者解鎖安全鎖定畫面時，第三方開發人員應用程式必須解鎖所有金鑰。舉例來說，第三方開發人員應用程式必須透過相關 API (例如 createConfirmDeviceCredentialIntent 和 setUserAuthenticationRequired) 提供所有金鑰。

如果裝置實作內容會在使用已知機密值時，新增或修改驗證方法來解鎖螢幕鎖定畫面，並使用新的驗證方法，以便視為安全的螢幕鎖定方式：

[C-3-1] 最短允許輸入長度的熵值必須大於 10 位元。
[C-3-2] 所有可能輸入內容的最大熵值必須大於 18 位元。
[C-3-3] 新驗證方法不得取代 AOSP 中實作及提供的任何建議主要驗證方法 (例如 PIN 碼、圖形密碼、密碼)。
[C-3-4] 如果裝置政策控制器 (DPC) 應用程式已透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策，且品質常數比 PASSWORD_QUALITY_SOMETHING 更嚴格，則必須停用新驗證方法。

如果裝置實作新增或修改建議的主要驗證方法來解鎖鎖定畫面，並使用以生物特徵辨識為基礎的新驗證方法，以便視為安全的鎖定畫面方法，則新方法會：

[C-4-1] 必須符合第 7.3.10.2 節所述的所有規定。
[C-4-2] 必須提供備用機制，以便使用建議的主要驗證方法之一，該方法必須以已知的密鑰為基礎。
[C-4-3] 必須停用，且僅允許建議的主要驗證機制解鎖螢幕，前提是裝置政策控制器 (DPC) 應用程式已透過呼叫 DevicePolicyManager.setKeyguardDisabledFeatures() 方法，搭配任何相關的生物特徵辨識標記 (例如 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS) 設定 keguard 功能政策。
[C-4-4] 必須每隔 72 小時或更短時間，至少向使用者提出建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。
[C-4-5] 必須具備與指紋感應器相同或更嚴格的誤認率，如第 7.3.10 節所述；否則必須停用，並只允許在裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策時，使用建議的主要驗證機制解鎖螢幕，且該政策的品質常數比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更嚴格。
[C-SR] 強烈建議您將偽造和冒用接受率設為與指紋感應器相同或更嚴格，如第 7.3.10 節所述。
[C-4-6] 必須具備安全的處理管道，以免在作業系統或核心遭到入侵時，無法直接插入資料，以便偽造使用者驗證。
[C-4-7] 如果應用程式為 KeyGenParameterSpec.Built.setUserAuthenticationRequired() 設定 true，且生物特徵辨識功能為被動 (例如臉部或虹膜，沒有明確的意圖信號)，則必須搭配明確的確認動作 (例如按下按鈕)，才能存取 KeyStore 金鑰。
[C-SR] 我們強烈建議您保護被動生物特徵辨識的確認動作，以免遭到作業系統或核心入侵而遭到冒用。舉例來說，這表示以實體按鈕為依據的確認動作會透過安全元件 (SE) 的僅限輸入通用輸入/輸出 (GPIO) 針腳進行路由，而該針腳只能透過按下實體按鈕的方式驅動。

如果生物特徵辨識驗證方法未達到第 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] 使用者必須每隔 72 小時或更短時間，至少接受一次建議的主要驗證方法 (例如 PIN 碼、圖案、密碼) 驗證。
[C-6-4] 新方法不得視為安全的鎖定畫面，且必須遵循下方 C-8 所列的限制。

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

[C-7-1] 裝置鎖定功能延遲或可由信任代理程式解鎖時，必須在設定選單和螢幕鎖定畫面上清楚顯示相關資訊。舉例來說，AOSP 會在設定選單中顯示「自動鎖定設定」和「電源鍵立即鎖定」的文字說明，並在螢幕鎖定畫面上顯示可辨識的圖示，以符合這項規定。
[C-7-2] 必須尊重並完整實作 DevicePolicyManager 類別中的所有信任代理程式 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常數。
[C-7-3] 請勿在用於個人主要裝置 (例如手持裝置) 的裝置上完全實作 TrustAgentService.addEscrowToken() 功能，但可在通常共用的裝置實作中完全實作此功能 (例如 Android TV 或汽車裝置)。
[C-7-4] 必須加密 TrustAgentService.addEscrowToken() 新增的所有已儲存權杖。
[C-7-5] 請勿將加密金鑰儲存在使用金鑰的裝置上。舉例來說，手機儲存的金鑰可用於解鎖電視上的使用者帳戶。
[C-7-6] 必須先向使用者說明安全性影響，才能啟用保證金權杖來解密資料儲存空間。
[C-7-7] 必須提供備用機制，以便使用建議的主要驗證方法。
[C-7-8] 使用者必須每隔 72 小時或更短時間，至少接受一次建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 驗證。
[C-7-9] 在任何 4 小時的閒置逾時期間過後，系統都必須要求使用者採用建議的主要驗證方法 (例如 PIN 碼、圖案、密碼) 進行驗證。成功確認裝置憑證後，閒置逾時時間就會重設。
[C-7-10] 不得視為安全的鎖定畫面，且必須遵循下方 C-8 所列的限制。

如果裝置實作項目新增或修改驗證方法，以解鎖非上述安全鎖定畫面的鎖定畫面，並使用新的驗證方法解鎖鎖定畫面：

[C-8-1] 如果裝置政策控制器 (DPC) 應用程式已透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策，且品質常數比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格，則必須停用新方法。
[C-8-2] 不得重設 DevicePolicyManager.setPasswordExpirationTimeout() 設定的密碼到期計時器。
[C-8-3] 當應用程式為 KeyGenParameterSpec.Builder.setUserAuthenticationRequired() 設定 true 時，則不得驗證存取金鑰庫的權限。

9.11.2. StrongBox

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在專屬安全處理器和上述隔離執行環境中。

裝置實作方式：

[C-SR] 強烈建議支援 StrongBox。

如果裝置實作項目支援 StrongBox，則會：

[C-1-1] 必須宣告 FEATURE_STRONGBOX_KEYSTORE。
[C-1-2] 您必須提供專用安全硬體，用於備份 KeyStore 和安全使用者驗證機制。
[C-1-3] 必須具備獨立 CPU，且不與應用程式處理器 (AP) 共用快取、DRAM、協同處理器或其他核心資源。
[C-1-4] 務必確保與 AP 共用的任何外接裝置無法以任何方式變更 StrongBox 處理作業，或從 StrongBox 取得任何資訊。AP 可能會停用或封鎖對 StrongBox 的存取權。
[C-1-5] 必須具備準確度合理 (+-10%) 的內部時鐘，且不受 AP 操控。
[C-1-6] 必須使用真正的隨機號碼產生器，產生均勻分布的不可預測輸出內容。
[C-1-7] 必須具備防竄改功能，包括防範實體侵入和故障。
[C-1-8] 必須具備側通道抵抗力，包括抵抗透過電力、時間、電磁輻射和熱輻射側通道洩漏資訊的行為。
[C-1-9] 必須提供安全的儲存空間，確保內容的機密性、完整性、真實性、一致性和新鮮度。除了 StrongBox API 允許的情況外，儲存空間不得讀取或變更。
如要驗證是否符合 [C-1-3] 至 [C-1-9] 的規定，裝置實作項目必須：
- [C-1-10] 硬體必須符合「安全 IC 保護設定檔」BSI-CC-PP-0084-2014 的認證標準，或是由國家認可的測試實驗室評估，並根據「智慧卡的攻擊潛力應用的通用標準」評估高攻擊潛力的漏洞。
- [C-1-11] 必須納入經國家認證測試實驗室評估的韌體，並根據Common Criteria Application of Attack Potential to Smartcards評估高攻擊潛力的安全漏洞。
- [C-SR] 強烈建議您納入使用安全目標評估的硬體，評估等級為 5 (EAL)，並由 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] 當主要使用者的裝置政策控制器應用程式呼叫 DevicePolicyManager.wipeData() API 時，必須觸發上述「工廠資料重設」程序。
可提供快速資料清除選項，只執行邏輯資料擦除作業。

9.13. 安全啟動模式

Android 提供安全啟動模式，可讓使用者在該模式下啟動裝置，僅執行預先安裝的系統應用程式，並停用所有第三方應用程式。這個模式稱為「安全啟動模式」，可讓使用者解除安裝可能有害的第三方應用程式。

裝置實作方式如下：

[SR] 強烈建議您導入安全啟動模式。

如果裝置實作導入安全啟動模式，則會：

[C-1-1] 必須提供使用者進入安全啟動模式的選項，且該選項必須以無法中斷的方式從裝置上安裝的第三方應用程式進入，除非第三方應用程式是裝置政策控制器，且已將 UserManager.DISALLOW_SAFE_BOOT 標記設為 true。
[C-1-2] 您必須讓使用者能夠在安全模式下解除安裝任何第三方應用程式。
應為使用者提供選項，讓他們透過與一般開機不同的工作流程，從開機選單進入安全模式。

9.14. 汽車車輛系統隔離

Android Automotive 裝置應透過車輛 HAL，透過 CAN 匯流排等車輛網路傳送及接收訊息，與重要車輛子系統交換資料。

您可以實作 Android 架構層以下的安全防護功能，防止與這些子系統的惡意或非預期互動，藉此保護資料交換機制。

9.15. 訂閱方案

「訂閱方案」是指行動電信業者透過 SubscriptionManager.setSubscriptionPlans() 提供的帳單關聯方案詳細資料。

所有裝置實作：

[C-0-1] 必須將訂閱方案傳回給最初提供這些方案的行動電信業者應用程式。
[C-0-2] 不得從遠端備份或上傳訂閱方案。
[C-0-3] 僅允許目前提供有效訂閱方案的行動電信業者應用程式，提供覆寫值，例如 SubscriptionManager.setSubscriptionOverrideCongested()。

10. 軟體相容性測試

裝置實作項目必須通過本節所述的所有測試。不過，請注意，沒有任何軟體測試套件是完全全面的。因此，強烈建議裝置實作人員盡可能減少對 Android 參考和偏好實作的變更次數，這些實作方式可從 Android 開放原始碼計畫取得。這麼做可盡量降低引入錯誤的風險，避免出現需要重新處理的錯誤，並可能需要更新裝置。

10.1. 相容性測試套件

裝置實作方式：

[C-0-1] 必須使用裝置上的最終發布軟體，通過 Android 相容性測試套件 (CTS) (可從 Android 開放原始碼計畫取得)。
[C-0-2] 如有 CTS 的模糊情況，以及任何參考原始碼的部分重新實作，則必須確保相容性。

CTS 設計用於在實際裝置上執行。和其他軟體一樣，CTS 本身可能也會有錯誤。CTS 的版本會與此相容性定義獨立，且 Android 9 可能會發布多個 CTS 修訂版本。

裝置實作方式：

[C-0-3] 必須通過裝置軟體完成時可用的最新 CTS 版本。
應盡可能使用 Android 開放原始碼樹狀結構中的參考實作項目。

10.2. CTS 驗證工具

CTS Verifier 是相容性測試套件的一部分，由人工操作員執行，用於測試自動化系統無法測試的功能，例如相機和感應器的正確運作情形。

裝置實作方式：

[C-0-1] 必須在 CTS 驗證器中正確執行所有適用的案例。

CTS Verifier 可測試多種硬體，包括部分選用硬體。

裝置實作方式：

[C-0-2] 必須通過所有硬體測試；舉例來說，如果裝置有加速計，就必須在 CTS Verifier 中正確執行加速計測試案例。

針對相容性定義說明文件中標示為選用功能的測試案例，您可以選擇略過或省略。

[C-0-2] 如上所述，每部裝置和每個版本都必須正確執行 CTS Verifier。不過，由於許多版本都非常相似，因此裝置實作者不應在僅有細微差異的版本上明確執行 CTS 驗證工具。具體來說，如果裝置實作項目與通過 CTS Verifier 的實作項目僅在所包含的語言代碼、品牌等方面有所差異，則可省略 CTS Verifier 測試。

11. 可更新軟體

[C-0-1] 裝置實作必須包含替換整個系統軟體的機制。這項機制不需要執行「即時」升級，也就是說，可能需要重新啟動裝置。只要能取代裝置上預先安裝的軟體，您可以使用任何方法。舉例來說，下列任何一種做法都能滿足這項要求：
- 透過重新啟動進行離線更新的「無線更新」(OTA) 下載。
- 透過主機電腦的 USB 進行「連線」更新。
- 透過重新啟動和從可移除儲存空間的檔案更新「離線」更新。
[C-0-2] 使用的更新機制必須支援不清除使用者資料的更新作業。也就是說，更新機制必須保留應用程式私人資料和應用程式共用資料。請注意，上游 Android 軟體包含符合這項需求的更新機制。

如果裝置實作項目支援不計量的數據連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，則必須符合下列條件：

[C-1-1] 必須支援透過重新啟動進行離線更新的 OTA 下載作業。

對於搭載 Android 6.0 以上版本的裝置實作，更新機制應支援驗證系統映像檔與 OTA 後的預期結果是否相同。自 Android 5.1 版起新增的源端 Android 開放原始碼計畫中的區塊式 OTA 實作，可滿足這項需求。

此外，裝置實作也應支援 A/B 系統更新。AOSP 會使用啟動控制 HAL 實作這項功能。

如果在裝置推出後，但在與 Android 相容性團隊協商後判斷的合理產品壽命期間內，發現裝置實作有錯誤，導致第三方應用程式相容性受影響，則：

[C-2-1] 裝置實作者必須透過可用的軟體更新來修正錯誤，且該更新必須能套用剛才所述的機制。

Android 包含多項功能，可讓裝置擁有者應用程式 (如有) 控制系統更新的安裝作業。如果裝置的系統更新子系統回報 android.software.device_admin，則會發生以下情況：

[C-3-1] 必須實作 SystemUpdatePolicy 類別中所述的行為。

12. 文件變更記錄

如要查看本版本相容性定義的變更摘要，請參閱以下內容：

說明變更記錄

以下是各個部分的異動摘要：

12.1. 變更記錄查看提示

變更內容如下所示：

CDD
相容性規定的重大變更。
文件
外觀或建構相關變更。

為獲得最佳瀏覽體驗，請將 pretty=full 和 no-merges 網址參數附加至變更記錄網址。

13. 與我們聯絡

您可以加入 android-compatibility 論壇，提出疑問或提出您認為文件未涵蓋的任何問題。

Android 9 相容性定義 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

1. 簡介

1.1 文件結構

1.1.1. 依裝置類型劃分的規定

1.1.2. 需求 ID

1.1.3. 附錄 2 中的規定 ID

2. 裝置類型

2.1 裝置設定

2.2. 手持裝置需求條件

2.2.1. 硬體

2.2.2. 多媒體

2.2.3. 軟體

2.2.4. 效能和電源

2.2.5. 安全性模型

2.3. 電視相關規定

2.3.1. 硬體

2.3.2. 多媒體

2.3.3. 軟體

2.3.4. 效能和電源

2.4. 智慧手錶需求

2.4.1. 硬體

2.4.2. 多媒體

2.4.3. 軟體

2.4.4. 效能和電源

2.5. 汽車業規定

2.5.1. 硬體

2.5.2. 多媒體

2.5.3. 軟體

2.5.4. 效能和電源

2.5.5. 安全性模型

2.6. 平板電腦需求條件

2.4.1. 硬體

3. 軟體

3.1. 代管 API 相容性

3.1.1. Android 擴充功能

3.1.2. Android 程式庫

3.2. 軟體 API 相容性

3.2.1. 權限

3.2.2. 建構參數

3.2.3. 意圖相容性

3.2.3.1. 核心應用程式意圖

3.2.3.2. 意圖解析

3.2.3.3. 意圖命名空間

3.2.3.4. 廣播意圖

3.2.3.5. 預設應用程式設定

3.2.4. 次要螢幕上的活動

3.3. 原生 API 相容性

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

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

3.4. 網頁相容性

3.4.1. WebView 相容性

3.4.2. 瀏覽器相容性

3.5. API 行為相容性

3.5.1. 背景活動限制

3.6. API 命名空間

3.7. 執行階段相容性

3.8. 使用者介面相容性

3.8.1. 啟動器 (主畫面)

3.8.2. 小工具

3.8.3. 通知

3.8.3.1. 通知呈現方式

3.8.3.2. 通知接聽器服務

3.8.3.3. DND (請勿打擾)

3.8.4. 搜尋

3.8.5. 警示和 Toast

3.8.6。主題

3.8.7. 動態桌布

3.8.8。活動切換

3.8.9。輸入管理

3.8.10。螢幕鎖定畫面媒體控制選項

3.8.11. 螢幕保護程式 (原稱為「夢幻背景」)

3.8.12. 位置

3.8.13. Unicode 和字型

3.8.14。多視窗模式

3.8.15。螢幕凹口

3.9. 裝置管理

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

3.9.1.2 受管理的設定檔佈建作業

3.9.2 受管理的設定檔支援

Android 9 相容性定義
透過集合功能整理內容你可以依據偏好儲存及分類內容。