1. 簡介

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

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

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

裝置實作必須符合本相容性定義中列出的規定，包括透過參考納入的任何文件，才能視為與 Android 7.0 相容。

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

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

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

2. 裝置類型

雖然 Android 開放原始碼專案已用於實作各種裝置類型和板型規格，但架構和相容性要求的許多層面都已針對手持裝置進行最佳化。自 Android 5.0 起，Android 開放原始碼計畫的目標是支援更多類型的裝置，詳情請參閱本節。

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

• 裝置必須內建觸控螢幕。
• 必須具備可提供行動力的電源，例如電池。

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

• 必須內建螢幕，或提供 VGA、HDMI 等視訊輸出端，或無線端供顯示。
• 必須宣告 android.software.leanback 和 android.hardware.type.television 功能。

「Android Watch 裝置」是指可戴在身上 (例如手腕) 的 Android 裝置實作方式，且符合下列條件：

• 螢幕的對角長度必須介於 1.1 到 2.5 英寸之間。
• 必須宣告 android.hardware.type.watch 功能。
• 必須支援 uiMode = UI_MODE_TYPE_WATCH。

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

• 螢幕的對角長度必須大於或等於 6 英寸。
• 必須宣告 android.hardware.type.automotive 功能。
• 必須支援 uiMode = UI_MODE_TYPE_CAR。
• Android Automotive 實作項目必須支援 android.car.* 命名空間中的所有公開 API。

所有不屬於上述任何裝置類型的 Android 裝置實作，仍須符合本文件中的所有要求，才能與 Android 7.0 相容，除非該要求明確說明僅適用於上述特定的 Android 裝置類型。

2.1 裝置設定

以下是裝置類型硬體設定的主要差異摘要。(空白單元格代表「可能」)。本表未涵蓋所有設定，請參閱相關硬體章節瞭解詳情。

類別	功能	部分	手持式	電視	觀看	汽車	其他
輸入	D-Pad	7.2.2. 非觸控式導覽功能		必須
	觸控螢幕	7.2.4. 觸控螢幕輸入	必須		必須		應
	麥克風	7.8.1. 麥克風	必須	應	必須	必須	應
感應器	加速計	7.3.1 加速計	應		應		應
	GPS	7.3.3. GPS	應			應
網路與數據傳輸	Wi-Fi	7.4.2. IEEE 802.11	應	應		應	應
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	應	應			應
	藍牙	7.4.3. 藍牙	應	必須	必須	必須	應
	藍牙低功耗	7.4.3. 藍牙	應	必須	應	應	應
	行動對講機	7.4.5. 最低網路能力				應
	USB 周邊/主機模式	7.7. USB	應			應	應
輸出	喇叭和/或音訊輸出埠	7.8.2. 音訊輸出裝置	必須	必須		必須	必須

3. 軟體

3.1. 代管 API 相容性

受管理的 Dalvik 位元碼執行環境是 Android 應用程式的主要載具。Android 應用程式設計介面 (API) 是向在受管理的執行階段環境中執行的應用程式公開的 Android 平台介面組合。裝置實作項目必須提供完整實作項目，包括 Android SDK 公開的任何已記錄 API 或在上游 Android 原始碼中標示為「@SystemApi」的任何 API 的所有已記錄行為。

裝置實作項目必須支援/保留標示為 TestApi 註解 (@TestApi) 的所有類別、方法和相關元素。

裝置實作不得省略任何受管理的 API、變更 API 介面或簽章、偏離已記錄的行為，或包含無操作，除非本相容性定義明確允許。

這個相容性定義允許裝置實作略過 Android 所提供 API 的某些類型硬體。在這種情況下，API 必須仍會出現，並以合理的方式運作。如要瞭解此情境的具體規定，請參閱第 7 節。

3.1.1. Android 擴充功能

Android 支援擴充受管理的 API，同時維持相同的 API 級別版本。Android 裝置實作項目必須預先載入共用程式庫 ExtShared 和服務 ExtServices 的 AOSP 實作項目，且版本必須高於或等於各 API 級別允許的最低版本。舉例來說，搭載 Android 7.0 裝置實作項目，執行 API 級別 24 時，至少必須包含第 1 版。

3.2. 軟體 API 相容性

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

3.2.1. 權限

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

3.2.2. 建構參數

Android API 在 android.os.Build 類別上包含多個常數，用於描述目前的裝置。為在各裝置實作中提供一致且有意義的值，下表列出這些值的格式額外限制，裝置實作必須符合這些限制。

參數	詳細資料
VERSION.RELEASE	目前執行的 Android 系統版本，以人類可讀的格式表示。這個欄位必須包含 7.0 中定義的字串值之一。
VERSION.SDK	目前執行的 Android 系統版本，格式可供第三方應用程式程式碼存取。對於 Android 7.0，這個欄位必須設為整數值 7.0_INT。
VERSION.SDK_INT	目前執行的 Android 系統版本，格式可供第三方應用程式程式碼存取。對於 Android 7.0，這個欄位必須設為整數值 7.0_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:7.0/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	硬體序號，必須是不同裝置的專屬序號，且型號和製造商必須相同。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式「^([a-zA-Z0-9]{6,20})$」。
標記	裝置實作者選擇的標記清單，以半形逗號分隔，可進一步區分版本。這個欄位必須包含一個值，對應至三種典型的 Android 平台簽署設定：發布版金鑰、開發版金鑰、測試版金鑰。
時間	代表建構作業發生時間的時間戳記值。
類型	裝置實作者選擇的值，用於指定建構作業的執行階段設定。這個欄位必須包含一個值，對應至三種常見的 Android 執行階段設定：user、userdebug 或 eng。
USER	產生版本的使用者 (或自動化使用者) 的名稱或使用者 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
SECURITY_PATCH	這個值表示版本的安全性修補程式等級。此標記必須表示此版本在任何情況下都不會受到指定 Android 公開安全性公告中所述問題的影響。格式必須為 [YYYY-MM-DD]，且必須與 Android 安全性公告或Android 安全性警示中定義的字串相符，例如「2015-11-01」。
BASE_OS	這個值代表建構版本的 FINGERPRINT 參數，除了 Android 公開安全性公告中提供的修補程式外，其他都與此建構版本相同。必須回報正確的值，如果不存在此建構項目，則回報空字串 ("")。

3.2.3. 意圖相容性

3.2.3.1. 核心應用程式意圖

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

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

裝置實作項目必須適當地納入核心 Android 應用程式，或是實作相同意圖模式的元件，這些意圖模式是由這些核心 Android 應用程式的所有活動或服務元件定義，並透過 android:exported 屬性，以隱含或明確的方式公開給其他應用程式。

3.2.3.2. 意圖解析

由於 Android 是可擴充的平台，裝置實作必須允許第三方應用程式覆寫 第 3.2.3.1 節中所參照的每個意圖模式。上游 Android 開放原始碼實作內容預設允許這項功能；裝置實作者不得為系統應用程式使用這些意圖模式附加特殊權限，或禁止第三方應用程式繫結至這些模式並接管控制權。這項禁止行為包括但不限於停用「選擇器」使用者介面，該介面可讓使用者在多個應用程式中選擇，這些應用程式都會處理相同的意圖模式。

裝置實作項目必須提供使用者介面，讓使用者修改意圖的預設活動。

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

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

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

3.2.3.3. 意圖命名空間

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

3.2.3.4. 廣播意圖

第三方應用程式會依賴平台發布特定意圖，以便通知硬體或軟體環境的變更。相容的 Android 裝置必須在回應適當的系統事件時，發布公開廣播意圖。如要瞭解廣播意圖，請參閱 SDK 說明文件。

3.2.3.5. 預設應用程式設定

Android 內建的設定可讓使用者輕鬆選取預設應用程式，例如主畫面或簡訊。在適當情況下，裝置實作方式必須提供類似的設定選單，並與 SDK 說明文件中所述的意圖篩選器模式和 API 方法相容，如下所示。

裝置實作方式：

• 如果裝置實作項目回報 android.software.home_screen，則必須使用 android.settings.HOME_SETTINGS 意圖，顯示主畫面的預設應用程式設定選單。
• 如果裝置實作項目回報 android.hardware.telephony，則必須提供設定選單，呼叫 android.provider.Telephony.ACTION_CHANGE_DEFAULT 意圖，以便顯示對話方塊，變更預設的簡訊應用程式。
• 如果裝置實作項目回報 android.hardware.nfc.hce，則必須遵循 android.settings.NFC_PAYMENT_SETTINGS 意圖，顯示預設的 Tap & Pay 應用程式設定選單。
• 如果裝置實作項目回報 android.hardware.telephony，則必須遵循 android.telecom.action.CHANGE_DEFAULT_DIALER 意圖，顯示對話方塊，允許使用者變更預設的電話應用程式。

3.3. 原生 API 相容性

原生程式碼的相容性很難處理。因此，我們強烈建議裝置實作人員使用下列程式庫的實作項目，這些程式庫來自上游 Android 開放原始碼專案。

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

受管理的 Dalvik 位元碼可呼叫應用程式 .apk 檔案中提供的機器碼，做為為適當裝置硬體架構編譯的 ELF .so 檔案。由於原生程式碼高度仰賴基礎處理器技術，Android 會在 Android NDK 中定義多個應用程式二進位檔介面 (ABI)。裝置實作項目必須與一或多個已定義的 ABI 相容，且必須實作與 Android NDK 的相容性，如下所示。

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

• 必須支援在受管理環境中執行的程式碼，以便使用標準 Java Native Interface (JNI) 語意呼叫原生程式碼。
• 必須與下列清單中的每個必要程式庫相容 (即標頭相容)，並與 ABI 相容 (針對 ABI)。
• 如果支援任何 64 位元 ABI，則必須支援等效的 32 位元 ABI。
• 必須透過 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 參數，準確回報裝置支援的原生應用程式二進位介面 (ABI)，每個參數都是以半形逗號分隔的 ABI 清單，並依優先順序排列。
• 請務必透過上述參數回報最新版 Android NDK ABI 管理說明文件中記錄和說明的 ABI，且必須支援 Advanced SIMD (又稱 NEON) 擴充功能。
• 應使用上游 Android 開放原始碼專案提供的原始碼和標頭檔案進行建構

請注意，日後推出的 Android NDK 版本可能會支援其他 ABI。如果裝置實作不相容於現有的預先定義 ABI，則絕對不應回報支援任何 ABI。

下列原生程式碼 API 必須提供給包含原生程式碼的應用程式：

• 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 (數學程式庫)
• libOpenMAXAL.so (支援 OpenMAX AL 1.0.1)
• libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
• libRS.so
• libstdc++ (C++ 的最低支援程度)
• libvulkan.so (Vulkan)
• libz (Zlib 壓縮)
• JNI 介面
• 支援 OpenGL，如下所述

針對上述原生資料庫，裝置實作項目不得新增或移除公開函式。

上述未列出的原生程式庫，如果在 AOSP 中實作並提供做為系統程式庫，則屬於保留的程式庫，且不得公開給指定 API 級別 24 以上版本的第三方應用程式。

裝置實作可能會新增非 AOSP 程式庫，並直接將其做為 API 公開給第三方應用程式，但額外程式庫應位於 /vendor/lib 或 /vendor/lib64，且必須列於 /vendor/etc/public.libraries.txt 中。

請注意，裝置實作必須包含 libGLESv3.so，並且必須匯出 NDK 版本 android-24 中定義的所有 OpenGL ES 3.1 和 Android 擴充套件函式符號。雖然必須提供所有符號，但只有裝置實際支援的 OpenGL ES 版本和擴充功能，才需要完全實作對應的函式。

3.3.1.1. 圖形程式庫

Vulkan 是一款用於高效能 3D 圖形的低成本跨平台 API，裝置實作項目 (即使不支援 Vulkan API) 也必須符合下列規定：

• 它一律必須提供名為 libvulkan.so 的原生程式庫，為核心 Vulkan 1.0 API 和 VK_KHR_surface、VK_KHR_android_surface 和 VK_KHR_swapchain 擴充功能匯出函式符號。

裝置實作項目 (如果包含 Vulkan API 支援功能)：

• 必須透過 vkEnumeratePhysicalDevices 呼叫回報一或多個 VkPhysicalDevices。
• 每個列舉的 VkPhysicalDevices 都必須完整實作 Vulkan 1.0 API。
• 必須回報正確的 PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL 和 PackageManager#FEATURE_VULKAN_HARDWARE_VERSION 功能旗標。
• 您必須透過 libvulkan.so 中的 vkEnumerateInstanceLayerProperties 和 vkEnumerateDeviceLayerProperties 函式，列舉應用程式套件原生資料庫目錄中名為 libVkLayer*.so 的原生資料庫所包含的圖層。
• 除非應用程式具有 android:debuggable=”true” 屬性，否則不得列舉應用程式套件外程式庫提供的圖層，或提供其他追蹤或攔截 Vulkan API 的方式。

裝置實作 (如果不支援 Vulkan API)：

• 必須透過 vkEnumeratePhysicalDevices 呼叫回報 0 VkPhysicalDevices。
• 請務必不要宣告任何 Vulkan 功能旗標 PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL 和 PackageManager#FEATURE_VULKAN_HARDWARE_VERSION。

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

ARMv8 架構已淘汰多項 CPU 作業，包括在現有原生程式碼中使用的部分作業。在 64 位元 ARM 裝置上，下列已淘汰的作業必須透過原生 CPU 支援或軟體模擬，才能供 32 位元原生 ARM 程式碼使用：

• SWP 和 SWPB 指令
• SETEND 指令
• CP15ISB、CP15DSB 和 CP15DMB 的阻隔操作

Android NDK 的舊版會使用 /proc/cpuinfo 來探索 32 位元 ARM 原生程式碼的 CPU 功能。為與使用此 NDK 建構的應用程式相容，裝置必須在 /proc/cpuinfo 中加入以下行，以便供 32 位元 ARM 應用程式讀取：

• 「Features:」後方會列出裝置支援的任何選用 ARMv7 CPU 功能。
• 「CPU 架構：」，後面接著整數，說明裝置支援的最高 ARM 架構 (例如如為 ARMv8 裝置，則為「8」)。

只有在 32 位元 ARM 應用程式讀取 /proc/cpuinfo 時，才會套用這些規定。當 64 位元 ARM 或非 ARM 應用程式讀取時，裝置不應變更 /proc/cpuinfo。

3.4. 網頁相容性

3.4.1. WebView 相容性

平台功能 android.software.webview 必須在任何提供 android.webkit.WebView API 完整實作的裝置上回報，且不得在未完整實作 API 的裝置上回報。Android 開放原始碼實作項目會使用 Chromium 專案的程式碼，實作 android.webkit.WebView。由於無法為網頁轉譯系統開發完整的測試套件，因此裝置導入者必須在 WebView 實作中使用特定的上游 Chromium 版本。具體違規事項如下：

• 裝置的 android.webkit.WebView 實作項目必須以 Chromium 為基礎，該版本來自 Android 7.0 的上游 Android 開放原始碼專案。此版本包含 WebView 的特定功能和安全性修正項目。

• 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) 字串的值必須與 android.os.Build.ID 的值相同。
  • $(CHROMIUM_VER) 字串的值必須是上游 Android 開放原始碼專案中的 Chromium 版本。
  • 裝置實作可能會在使用者代理程式字串中省略「Mobile」。

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

3.4.2. 瀏覽器相容性

獨立瀏覽器可能採用 WebKit 以外的瀏覽器技術。不過，即使使用其他瀏覽器應用程式，提供給第三方應用程式的 android.webkit.WebView 元件仍必須以 WebKit 為基礎，如第 3.4.1 節所述。

實作可能會在獨立的瀏覽器應用程式中提供自訂使用者代理程式字串。

獨立的瀏覽器應用程式 (無論是基於上游 WebKit 瀏覽器應用程式，還是第三方替代品) 應盡可能支援 HTML5。裝置實作項目至少必須支援下列與 HTML5 相關的 API：

• 應用程式快取/離線作業
• <video> 標記
• 地理位置

此外，裝置實作方式必須支援 HTML5/W3C webstorage API，並建議支援 HTML5/W3C IndexedDB API。請注意，由於網路開發標準機構正從 webstorage 轉為偏好 IndexedDB，因此 IndexedDB 預計將成為日後 Android 版本的必要元件。

3.5. API 行為相容性

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

• 裝置絕對不得變更標準意圖的行為或語意。
• 裝置不得變更特定類型的系統元件 (例如服務、活動、ContentProvider 等) 的生命週期或生命週期語意。
• 裝置絕對不得變更標準權限的語意。

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

3.6. API 命名空間

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

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

禁止的修改包括：

• 裝置實作項目不得透過變更任何方法或類別簽章，或移除類別或類別欄位，修改 Android 平台上公開的 API。
• 裝置實作者可以修改 API 的基礎實作項目，但此類修改不得影響任何公開 API 的已知行為和 Java 語言簽章。
• 裝置實作者不得在上述 API 中加入任何公開暴露的元素 (例如類別或介面，或現有類別或介面的欄位或方法)。

「公開元素」是指任何未以「@hide」標記裝飾的結構體，就像在 Android 上游原始碼中使用的標記一樣。換句話說，裝置實作者不得在上述命名空間中公開新的 API，或變更現有的 API。裝置導入者可以進行僅限內部使用的修改，但這些修改不得宣傳或以其他方式提供給開發人員。

裝置實作人員可以新增自訂 API，但任何這類 API 都不得位於由其他機構擁有或參照的命名空間。舉例來說，裝置實作人員不得將 API 新增至 com.google.* 或類似的命名空間，只有 Google 可以這麼做。同樣地，Google 不得將 API 新增至其他公司的命名空間。此外，如果裝置實作內容包含標準 Android 命名空間以外的自訂 API，則這些 API 必須封裝在 Android 共用程式庫中，這樣只有明確使用這些 API 的應用程式 (透過 <uses-library> 機制) 才會受到這些 API 記憶體用量增加的影響。

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

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

3.7. 執行階段相容性

裝置實作項目必須支援完整的 Dalvik Executable (DEX) 格式和 Dalvik 位元碼規格和語義。裝置導入者應使用 ART、Dalvik 可執行格式的參考上游實作項目，以及參考實作項目的套件管理系統。

裝置實作項目必須設定 Dalvik 執行階段，以便根據上游 Android 平台和下表指定的內容分配記憶體。(如要瞭解螢幕大小和螢幕密度的定義，請參閱 7.1.1 節)。請注意，下方指定的記憶體值視為最小值，且裝置實作可能會為每個應用程式分配更多記憶體。

螢幕版面配置	螢幕密度	應用程式記憶體下限
Android 手錶	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (高解析度)	36MB
	280 dpi (280dpi)
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
小/正常	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (高解析度)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
large	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (高解析度)
	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 (高解析度)
	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 包含啟動器應用程式 (主畫面)，並支援第三方應用程式取代裝置啟動器 (主畫面)。允許第三方應用程式取代裝置主畫面的裝置實作，必須宣告平台功能 android.software.home_screen。

3.8.2. 小工具

Android 定義了元件類型和對應的 API 與生命週期，讓應用程式可向使用者提供 「AppWidget」，這項功能強烈建議在手持裝置實作中支援。支援在主畫面上嵌入小工具的裝置實作必須符合下列規定，並宣告支援平台功能 android.software.app_widgets。

• 裝置啟動器必須內建 AppWidget 支援功能，並提供使用者介面操作選項，可直接在啟動器中新增、設定、查看及移除 AppWidget。
• 裝置實作項目必須能夠算繪標準格狀大小的 4 x 4 小工具。詳情請參閱 Android SDK 說明文件中的「應用程式小工具設計指南」。
• 支援螢幕鎖定畫面的裝置實作可能會支援螢幕鎖定畫面上的應用程式小工具。

3.8.3. 通知

Android 提供的 API 可讓開發人員使用裝置的硬體和軟體功能，通知使用者重要事件。

部分 API 可讓應用程式使用硬體 (特別是聲音、震動和燈光) 執行通知或吸引注意。裝置實作項目必須支援使用硬體功能的通知，如 SDK 說明文件所述，並盡可能使用裝置實作硬體。舉例來說，如果裝置實作項目包含震動器，則必須正確實作震動 API。如果裝置實作項目缺少硬體，則必須將對應的 API 實作為無作業。第 7 節會進一步說明這項行為。

此外，實作方式必須正確轉譯 API 或狀態/系統列 圖示樣式指南中提供的所有資源 (圖示、動畫檔案等)，因為在 Android TV 裝置上，通知可能不會顯示。裝置導入者可以提供其他通知使用者體驗，而非 Android 開放原始碼參考導入作業提供的體驗；不過，這類其他通知系統必須支援現有的通知資源，如上所述。

Android 支援各種通知，例如：

• 豐富通知。持續性通知的互動式 View。
• 抬頭通知。使用者可以直接在互動式 View 中採取行動或關閉，無須離開目前的應用程式。
• 螢幕鎖定通知。在螢幕鎖定畫面上顯示通知，並提供精細的顯示控制選項。

當這類通知顯示時，Android 裝置實作項目必須正確執行豐富通知和快訊通知，並包含標題/名稱、圖示和文字，如Android API 中的說明所述。

Android 包含 Notification Listener Service API，可讓應用程式 (在使用者明確啟用後) 收到所有通知的副本，無論通知是否已發布或更新。裝置實作必須正確且迅速地將通知傳送至所有已安裝且使用者啟用的監聽器服務，包括附加至 Notification 物件的所有中繼資料。

支援 DND (請勿打擾) 功能的裝置實作必須符合下列規定：

• 您必須實作可回應意圖 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS 的活動，如果使用 UI_MODE_TYPE_NORMAL 實作，則該活動必須是使用者可授予或拒絕應用程式 DND 政策設定存取權的活動。
• 必須：如果裝置實作已提供一種方式，讓使用者授予或拒絕第三方應用程式存取 DND 政策設定，請一併顯示應用程式建立的自動 DND 規則，以及使用者建立的預先定義規則。
• 必須遵循 NotificationManager.Policy 傳遞的 suppressedVisualEffects 值，如果應用程式已設定 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 旗標，則應向使用者指出視覺效果已在 DND 設定選單中抑制。

3.8.4. 搜尋

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

Android 裝置實作項目應包含全域搜尋功能，也就是單一共用系統層級搜尋使用者介面，可根據使用者輸入內容提供即時建議。裝置實作項目應實作 API，讓開發人員能夠重複使用這個使用者介面，在自己的應用程式中提供搜尋功能。實作全域搜尋介面的裝置實作項目必須實作 API，讓第三方應用程式在全域搜尋模式下執行時，能夠在搜尋框中新增建議。如果沒有安裝使用這項功能的第三方應用程式，預設行為應為顯示網路搜尋引擎結果和建議。

Android 裝置實作項目應在裝置上實作助理，以便處理輔助動作。Android Automotive 實作項目則必須實作助理。

Android 也包含 Assist API，可讓應用程式選擇要與裝置上的 Google 助理共用多少目前情境資訊。支援 Assist 動作的裝置實作方式必須在螢幕邊緣顯示白色燈號，清楚向使用者指出何時會分享內容。為確保使用者能清楚看到指示燈，指示燈的時間長度和亮度必須符合或超過 Android 開放原始碼專案實作的時間長度和亮度。

3.8.5. Toasts

應用程式可以使用 「Toast」API，向使用者顯示短暫的非模式化字串，這類字串會在短時間後消失。裝置實作項目必須以某種高可見度的方式，向使用者顯示應用程式傳送的 Toast。

3.8.6。主題

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

Android 包含「Holo」主題系列，提供一組定義的樣式，供應用程式開發人員使用，以便配合 Android SDK 定義的 Holo 主題外觀和風格。裝置實作不得變更任何向應用程式公開的 Holo 主題屬性。

Android 包含「Material」主題系列，提供一組已定義的樣式，供應用程式開發人員在各種 Android 裝置類型上，配合設計主題的外觀和感受。裝置實作項目必須支援「Material」主題系列，且不得變更任何 Material 主題屬性或向應用程式公開的相關資產。

Android 也提供「裝置預設」主題系列，提供一組定義的樣式，供應用程式開發人員使用，以便與裝置實作者定義的裝置主題外觀和感受相符。裝置實作可能會修改向應用程式公開的裝置預設主題屬性。

Android 支援採用半透明系統列的變化主題，讓應用程式開發人員可在狀態列和導覽列後方填入應用程式內容。為了在這個設定中提供一致的開發人員體驗，請務必在不同裝置的實作中維持狀態列圖示樣式。因此，Android 裝置實作項目必須使用白色顯示系統狀態圖示 (例如訊號強度和電池電量) 和系統發出的通知，除非圖示表示有問題的狀態，或是應用程式使用 SYSTEM_UI_FLAG_LIGHT_STATUS_BAR 標記要求淺色狀態列。當應用程式要求淺色狀態列時，Android 裝置實作必須將系統狀態圖示的顏色變更為黑色 (詳情請參閱 R.style)。

3.8.7. 動態桌布

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

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

裝置實作項目如能如上所述可靠地執行動態桌布，就應實作動態桌布，且在實作時必須回報平台功能旗標 android.software.live_wallpaper。

3.8.8。活動切換

上游 Android 原始碼包含總覽畫面，這是系統層級使用者介面，可用於切換工作，並在使用者上次離開應用程式時，使用應用程式圖形狀態的縮圖圖片，顯示最近存取的活動和工作。裝置實作 (包括「最近使用」功能導覽鍵，詳見第 7.2.3 節) 可變更介面，但必須符合下列規定：

• 必須支援最多 6 個顯示活動。
• 一次至少顯示 4 項活動的標題。
• 必須實作螢幕固定行為，並為使用者提供可切換功能的設定選單。
• 應在「最近」中顯示醒目顯示顏色、圖示和畫面標題。
• 應顯示關閉操作元素 (「x」)，但可在使用者與畫面互動前延遲顯示。
• 應實作捷徑，方便切換至先前的活動
• 可將相關聯的近期內容顯示為一組一起移動的內容。
• 輕觸「最近」功能鍵兩次時，應會在最近兩個使用的應用程式之間觸發快速切換動作。
• 長按「最近使用」按鈕時，應觸發分割畫面多視窗模式 (如果支援的話)。

強烈建議裝置實作項目使用上游 Android 使用者介面 (或類似的縮圖介面) 做為概覽畫面。

3.8.9。輸入管理

Android 支援輸入管理功能，以及第三方輸入法編輯器。允許使用者在裝置上使用第三方輸入法功能的裝置實作，必須宣告平台功能 android.software.input_methods，並支援 Android SDK 文件中定義的 IME API。

宣告 android.software.input_methods 功能的裝置實作方式，必須提供使用者可存取的機制，以便新增及設定第三方輸入法。裝置實作項目必須在回應 android.settings.INPUT_METHOD_SETTINGS 意圖時，顯示設定介面。

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

從 Android 5.0 開始，我們已淘汰 Remote Control Client API，改用媒體通知範本，讓媒體應用程式可與鎖定畫面上顯示的播放控制項整合。支援螢幕鎖定畫面的裝置實作 (除非是 Android Automotive 或 Watch 實作)，必須顯示螢幕鎖定畫面通知，包括媒體通知範本。

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

Android 支援互動式螢幕保護程式 (先前稱為夢境)。當裝置連接電源處於閒置狀態，或已連接至桌面底座時，使用者可以透過螢幕保護程式與應用程式互動。Android Watch 裝置可以實作螢幕保護程式，但其他類型的裝置實作應支援螢幕保護程式，並提供設定選項，讓使用者根據 android.settings.DREAM_SETTINGS 意圖設定螢幕保護程式。

3.8.12. 位置

如果裝置有可提供位置座標的硬體感應器 (例如 GPS)，則「位置」選單中的「位置」選單必須顯示位置模式。

3.8.13. Unicode 和字型

Android 支援 Unicode 9.0 中定義的表情符號。所有裝置實作方式都必須能夠以彩色字形顯示這些表情符號字元，而當 Android 裝置實作方式包含 IME 時，應為使用者提供這些表情符號字元的輸入方式。

Android 手持裝置應支援 Unicode 技術報告 #51 中指定的膚色和多元家庭表情符號。

Android 支援 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 貨幣符號區塊中的所有字形。

3.8.14。多視窗模式

裝置實作可能選擇不實作任何多視窗模式，但如果裝置能夠同時顯示多個活動，則必須根據 Android SDK 多視窗模式支援文件中所述的應用程式行為和 API 實作此類多視窗模式，並符合下列規定：

• 應用程式可以在 AndroidManifest.xml 檔案中，明確透過 android:resizeableActivity 屬性，或隱含地透過 targetSdkVersion > 24 指出是否能夠在多視窗模式下運作。在資訊清單中明確將這個屬性設為 false 的應用程式，不得以多視窗模式啟動。未在資訊清單檔案中設定屬性的應用程式 (targetSdkVersion < 24) 可在多視窗模式下啟動，但系統必須提供警告，指出應用程式在多視窗模式下可能無法正常運作。
• 如果螢幕高度和寬度都小於 440 dp，裝置實作項目不得提供分割畫面或任意形式模式。
• 螢幕尺寸為 xlarge 的裝置實作項目應支援任意形式模式。
• Android TV 裝置實作項目必須支援子母畫面 (PIP) 模式多視窗，並在 PIP 開啟時將 PIP 多視窗置於右上角。
• 支援子母畫面模式多視窗的裝置實作方式，必須為子母畫面視窗分配至少 240x135 dp。
• 如果系統支援子母畫面多視窗模式，則必須使用 KeyEvent.KEYCODE_WINDOW 鍵控制子母畫面視窗；否則，該鍵必須可供前景活動使用。

3.9. 裝置管理

Android 包含多項功能，可讓具備安全意識的應用程式透過 Android Device Administration API，在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端資料清除作業。裝置實作項目必須提供 DevicePolicyManager 類別的實作項目。支援安全螢幕鎖定的裝置實作項目必須實作 Android SDK 說明文件中定義的所有裝置管理政策，並回報平台功能 android.software.device_admin。

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

如果裝置實作項目宣告 android.software.device_admin 功能，則必須實作裝置政策用戶端 (DPC) 應用程式的 Device Owner 應用程式佈建作業，如下所示：

• 如果裝置實作尚未設定使用者資料，則會：
  • 必須為 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 回報 true。
  • 您必須將 DPC 應用程式註冊為裝置擁有者應用程式，以回應意圖動作 android.app.action.PROVISION_MANAGED_DEVICE。
  • 如果裝置透過功能旗標 android.hardware.nfc 宣告支援近距離無線通訊 (NFC)，且收到的 NFC 訊息含有 MIME 類型 MIME_TYPE_PROVISIONING_NFC 的記錄，則必須將 DPC 應用程式註冊為裝置擁有者應用程式。
• 當裝置實作有使用者資料時，會執行以下操作：
  • 必須為 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 回報 false。
  • 不得再將任何 DPC 應用程式註冊為裝置擁有者應用程式。

裝置實作項目可能會預先安裝執行裝置管理功能的應用程式，但如果沒有使用者或裝置管理員明確同意或採取行動，則不得將此應用程式設為裝置擁有者應用程式。

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

如果裝置實作宣告 android.software.managed_users，則必須能夠註冊裝置政策控制器 (DPC) 應用程式，做為新受管理設定檔的擁有者。

受管理設定檔佈建程序 (由 android.app.action.PROVISION_MANAGED_PROFILE 啟動的流程) 使用者體驗必須與 AOSP 實作方式一致。

裝置實作方式必須在「設定」使用者介面中提供下列使用者操作元素，向使用者指出裝置政策控制器 (DPC) 已停用特定系統功能：

• 一致的圖示或其他使用者操作元素 (例如上游 AOSP 資訊圖示)，用於表示特定設定遭到裝置管理員限制。
• 裝置管理員透過 setShortSupportMessage 提供的簡短說明訊息。
• DPC 應用程式的圖示。

3.9.2 受管理的設定檔支援

支援受管理設定檔的裝置必須符合下列條件：

• 宣告 android.software.device_admin (請參閱「3.9 裝置管理」一節)。
• 不是低 RAM 裝置 (請參閱 7.6.1 節)。
• 將內部 (不可移除) 儲存空間分配為共用儲存空間 (請參閱第 7.6.2 節)。

支援受管理設定檔的裝置必須符合下列條件：

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

3.10. 無障礙功能

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

裝置實作內容必須符合下列規定：

• Android Automotive 實作項目應提供與 Android 預設實作項目一致的 Android 無障礙功能架構實作項目。
• 裝置實作 (不含 Android Automotive) 必須提供 Android 無障礙功能架構的實作項目，且必須與 Android 的預設實作項目一致。
• 裝置實作 (不含 Android Automotive) 必須透過 android.accessibilityservice API 支援第三方無障礙服務實作。
• 裝置實作 (不含 Android Automotive) 必須產生 AccessibilityEvents，並以與預設 Android 實作方式一致的方式，將這些事件傳送至所有已註冊的 AccessibilityService 實作

• 裝置實作 (不含沒有音訊輸出的 Android Automotive 和 Android Watch 裝置) 必須提供使用者可存取的機制，以便啟用及停用無障礙服務，並且必須在回應 android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS 意圖時顯示此介面。

• 強烈建議您在具備音訊輸出的 Android 裝置上，提供與 TalkBack** 和切換控制無障礙服務 (https://github.com/google/talkback) 功能相若或更優的無障礙服務。

• 具備音訊輸出的 Android 手錶裝置應在裝置上提供無障礙工具服務的實作項目，其功能應與 TalkBack 無障礙工具服務 (https://github.com/google/talkback) 相當或更優。
• 裝置實作應在開箱設定流程中提供機制，讓使用者啟用相關的無障礙服務，以及調整字型大小、顯示大小和放大手勢的選項。

** 適用於文字轉語音功能支援的語言。

此外，請注意，如果裝置使用檔案型加密 (FBE) 的加密儲存空間，則預先載入的無障礙服務必須是直接啟動感知 {directBootAware} 應用程式。

3.11. 文字轉語音

Android 包含 API，可讓應用程式使用文字轉語音 (TTS) 服務，並讓服務供應商提供 TTS 服務的實作項目。回報 android.hardware.audio.output 功能的裝置實作必須符合 Android TTS 架構相關規定。

Android Automotive 實作項目：

• 必須支援 Android TTS 架構 API。
• 可能支援安裝第三方 TTS 引擎。如果支援，合作夥伴必須提供使用者可存取的介面，讓使用者選取要用於系統層級的 TTS 引擎。

所有其他裝置實作：

• 必須支援 Android TTS 架構 API，並應包含支援裝置上可用語言的 TTS 引擎。請注意，上游 Android 開放原始碼軟體包含全功能的 TTS 引擎實作。
• 必須支援安裝第三方 TTS 引擎。
• 必須提供使用者可存取的介面，讓使用者在系統層級選取 TTS 引擎。

3.12. 電視輸入框架

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

支援 TIF 的裝置實作項目必須宣告平台功能 android.software.live_tv。

3.12.1. TV 應用程式

任何宣告支援電視直播的裝置實作項目，都必須安裝電視應用程式 (TV 應用程式)。Android 開放原始碼計畫提供 TV 應用程式的實作項目。

TV 應用程式必須提供安裝及使用電視頻道的設施，並符合下列規定：

• 裝置實作方式必須允許安裝及管理第三方 TIF 輸入 ( 第三方輸入)。
• 裝置實作可能會在預先安裝的 以 TIF 為基礎的輸入內容 (已安裝的輸入內容) 和第三方輸入內容之間提供視覺區隔。
• 裝置實作項目不得顯示第三方輸入內容，除非是從 TV 應用程式執行單一導覽動作 (例如從 TV 應用程式展開第三方輸入內容清單)。

3.12.1.1. 電子節目指南

Android TV 裝置實作項目必須顯示資訊和互動式疊加層，其中必須包含根據 TvContract.Programs 欄位中的值產生的電子節目指南 (EPG)。EPG 必須符合下列規定：

• EPG 必須顯示所有已安裝的輸入內容和第三方輸入內容的資訊。
• EPG 可視需要在已安裝的輸入裝置和第三方輸入裝置之間提供視覺區隔。
• 強烈建議 EPG 以同等重要性顯示已安裝的輸入裝置和第三方輸入裝置。EPG 必須在 EPG 上顯示第三方輸入內容，且距離已安裝輸入內容的單一導覽動作。
• 在頻道變更時，裝置實作必須顯示目前播放節目的 EPG 資料。

3.12.1.2. 導覽

電視應用程式必須允許使用 Android 電視裝置輸入裝置 (即遙控器、遙控器應用程式或遊戲控制器) 上的 D-Pad、返回和主畫面鍵，瀏覽下列功能：

• 變更電視頻道
• 開啟電子節目表
• 針對第三方以 TIF 為基礎的輸入內容進行設定和調整
• 開啟「設定」選單

電視應用程式應透過 CEC 將重要事件傳遞至 HDMI 輸入端。

3.12.1.3. 電視輸入應用程式連結

Android 電視裝置實作功能必須支援電視輸入應用程式連結，讓所有輸入功能都能提供從目前活動連至其他活動的活動連結 (也就是從直播節目連至相關內容的連結)。電視應用程式必須在提供電視輸入應用程式連結時顯示連結。

3.12.1.4. 時間轉移

Android TV 裝置實作方式必須支援時間轉換功能，讓使用者可暫停及繼續觀看直播內容。如果可對該節目進行時間轉移，裝置實作必須提供使用者暫停及繼續播放目前節目的方法。

3.12.1.5. 電視錄影

強烈建議 Android TV 裝置實作項目支援電視錄影功能。如果電視輸入裝置支援錄影功能，且不禁止錄製該節目，EPG 可能會提供錄製節目的方法。裝置實作應提供可播放錄製節目的使用者介面。

3.13. 快速設定

Android 裝置實作項目應包含快速設定 UI 元件，方便使用者快速存取常用或急需的操作。

Android 包含 quicksettings API，可讓第三方應用程式實作資訊方塊，讓使用者在「快速設定」UI 元件中，將系統提供的資訊方塊與自訂資訊方塊並列。如果裝置實作項目含有快速設定 UI 元件，則會：

• 必須允許使用者將第三方應用程式中的資訊方塊新增或移除至「快速設定」。
• 請勿自動將第三方應用程式的設定方塊新增至快速設定。
• 必須在系統提供的快速設定方塊旁，顯示所有使用者新增的第三方應用程式方塊。

3.14. 車輛 UI API

3.14.1. 車輛媒體 UI

宣告支援車用功能的任何裝置實作項目都必須包含 UI 架構，以支援使用 MediaBrowser 和 MediaSession API 的第三方應用程式。

支援依賴 MediaBrowser 和 MediaSession 的第三方應用程式的 UI 架構，有下列視覺需求：

• 必須顯示未經修改的 MediaItem 圖示和通知圖示。
• 必須顯示 MediaSession 所述的項目，例如中繼資料、圖示、圖像。
• 必須顯示應用程式名稱。
• 必須有抽屜來呈現 MediaBrowser 階層。

4. 應用程式封裝相容性

裝置實作項目必須安裝並執行由 官方 Android SDK 中「aapt」工具產生的 Android「.apk」檔案。因此，裝置實作應使用參考實作的套件管理系統。

套件管理工具必須支援使用 APK Signature Scheme v2 和 JAR 簽署驗證「.apk」檔案。

裝置實作不得擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式，以免這些檔案無法在其他相容的裝置上正確安裝及執行。

5. 多媒體相容性

5.1. 媒體轉碼器

裝置實作方式：

• 必須支援 Android SDK 說明文件中指定的核心媒體格式，除非本文件明確允許。

• 必須支援下表中定義並透過 MediaCodecList 回報的媒體格式、編碼器、解碼器、檔案類型和容器格式。

• 也必須能夠解碼 CamcorderProfile 中回報的所有設定檔

• 必須能夠解碼所有可編碼的格式。包括編碼器產生的所有位元資料流。

轉碼器應盡量減少轉碼器延遲時間，也就是說，轉碼器應

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

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

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

5.1.1. 音訊轉碼器

格式/編解碼	編碼器	解碼器	詳細資料	支援的檔案類型/容器格式
MPEG-4 AAC 設定檔 (AAC LC)	必填 1	必填	支援單聲道/立體聲/5.0/5.1 2 內容，標準取樣率介於 8 到 48 kHz 之間。	3GPP (.3gp) MPEG-4 (.mp4、.m4a) ADTS 原始 AAC (.aac，在 Android 3.1 以上版本中解碼，在 Android 4.0 以上版本中編碼，不支援 ADIF) MPEG-TS (.ts，無法尋找，Android 3.0 以上版本)
MPEG-4 HE AAC 格式 (AAC+)	必備 1 (Android 4.1 以上版本)	必填	支援單聲道/立體聲/5.0/5.1 2 內容，標準取樣率介於 16 到 48 kHz 之間。
MPEG-4 HE AACv2 Profile (增強型 AAC+)		必填	支援單聲道/立體聲/5.0/5.1 2 內容，標準取樣率介於 16 到 48 kHz 之間。
AAC ELD (增強型低延遲 AAC)	必備 1 (Android 4.1 以上版本)	必填 (Android 4.1 以上版本)	支援單聲道/立體聲內容，取樣率為 16 到 48 kHz 的標準值。
AMR-NB	必要3	必要3	4.75 至 12.2 kbps，取樣頻率為 8 kHz	3GPP (.3gp)
AMR-WB	必要3	必要3	9 種取樣率，從 6.60 kbit/s 到 23.85 kbit/s，取樣率為 16 kHz
FLAC		必填 (Android 3.1 以上版本)	單聲道/立體聲 (不支援多聲道)。取樣率最高可達 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	必要 4 (Android 4.1 以上版本)	必填	16 位元線性 PCM (速率上限為硬體限制)。裝置必須支援 8000、11025、16000 和 44100 Hz 頻率的原始 PCM 錄音取樣率。	WAVE (.wav)
Opus		必填 (Android 5.0 以上版本)		Matroska (.mkv)、Ogg(.ogg)

1 如要定義 android.hardware.microphone，此屬性為裝置實作項目的必要條件，但對於 Android 智慧手錶裝置實作項目則為選用條件。

2 錄製或播放作業可以以單聲道或立體聲執行，但如果要透過 android.media.MediaCodec API 中的預設 AAC 音訊解碼器，將多聲道串流 (即超過兩個聲道) 的 AAC 輸入緩衝區解碼為 PCM，則必須支援下列項目：

• 解碼時不進行下混 (例如，5.0 AAC 串流必須解碼為五個 PCM 聲道，5.1 AAC 串流必須解碼為六個 PCM 聲道)。
• 動態範圍中繼資料 (如 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。

3 這是 Android 手持裝置實作項目的必要條件。

4 如要定義 android.hardware.microphone，包括 Android Watch 裝置實作，則必須使用此類裝置實作。

5.1.2. 圖片編碼器

格式/編解碼	編碼器	解碼器	詳細資料	支援的檔案類型/容器格式
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)

5.1.3. 視訊轉碼器

• 宣稱支援 HDR 設定檔的轉碼器，必須支援 HDR 靜態中繼資料的剖析和處理。

• 如果媒體編解碼宣稱支援內部重新整理，則必須支援 10 到 60 影格範圍內的重新整理週期，並在設定的重新整理週期 20% 內準確運作。

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

• 視訊編碼器和解碼器務必支援 YUV420 彈性色彩格式 (COLOR_FormatYUV420Flexible)。

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

1 裝置實作項目必須包含相機硬體，並定義 android.hardware.camera 或 android.hardware.camera.front。

2 裝置導入 (Android Watch 裝置除外) 皆須使用。

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

4 裝置實作應支援寫入 Matroska WebM 檔案。

5 強烈建議 Android Automotive 使用者使用，Android Watch 使用者可視需要使用，所有其他裝置類型則必須使用。

6. 僅適用於 Android TV 裝置的實作方式。

5.2. 影片編碼

H.264、VP8、VP9 和 HEVC 影片編碼器：

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

H.263 和 MPEG-4 視訊編碼器應支援可動態設定的位元率。

所有影片編碼器應在兩個滑動視窗中，符合下列比特率目標：

• 請勿超過內部影格 (I 影格) 間隔的位元率約 15%。
• 在 1 秒的滑動視窗中，應不超過比特率的 100%。

5.2.1. H.263

搭載 H.263 編碼器的 Android 裝置實作方式，必須支援基準設定檔第 45 級。

5.2.2. H-264

支援 H.264 轉碼器的 Android 裝置實作方式：

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

	SD (低畫質)	SD (高畫質)	HD 720p 1	HD 1080p 1
影片解析度	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

1 如果硬體支援，但強烈建議 Android TV 裝置使用。

5.2.3. VP8

支援 VP8 編解碼器的 Android 裝置實作項目必須支援 SD 視訊編碼設定檔，並應支援下列 HD (高畫質) 視訊編碼設定檔。

	SD (低畫質)	SD (高畫質)	HD 720p 1	HD 1080p 1
影片解析度	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

1 如果硬體支援。

5.3. 影片解碼

裝置實作方式：

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

• 支援 Dolby Vision 解碼器的實作方式：

• 必須提供支援 Dolby Vision 的擷取工具。

• 必須在裝置螢幕或標準視訊輸出埠 (例如 HDMI)。

• 提供 Dolby Vision 相容擷取器的實作項目，必須將向下相容的基礎層 (如有) 的曲目索引，設為與合併 Dolby Vision 層的曲目索引相同。

5.3.1. MPEG-2

搭載 MPEG-2 解碼器的 Android 裝置實作方式必須支援 Main Profile High Level。

5.3.2. H.263

搭載 H.263 解碼器的 Android 裝置實作方式，必須支援基準設定檔第 30 級和第 45 級。

5.3.3. MPEG-4

搭載 MPEG-4 解碼器的 Android 裝置實作方式必須支援簡易設定檔第 3 級。

5.3.4. H.264

搭載 H.264 解碼器的 Android 裝置實作方式：

• 必須支援 Main Profile Level 3.1 和基準設定檔。
  您可以選擇支援 ASO (任意切片排序)、FMO (彈性區塊排序) 和 RS (重複切片)。
• 必須能夠解碼使用下表所列 SD (標準解析度) 設定檔，並以 Baseline Profile 和 Main Profile Level 3.1 (包括 720p30) 編碼的影片。
• 應具備解碼 HD (高畫質) 設定檔的功能，如下表所示。
• 此外，Android TV 裝置 (
  • 必須支援高畫質等級 4.2 和 HD 1080p60 解碼設定檔。
  • 必須能夠解碼使用 HD 設定檔的影片，如下表所示，並以基準設定檔、主設定檔或高設定檔等級 4.2 編碼

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

1 當 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度時，必須使用。

2 必須實作 Android TV 裝置。

5.3.5. H.265 (HEVC)

Android 裝置實作項目，如果支援 第 5.1.3 節所述的 H.265 編解碼器：

• 必須支援 Main Profile Level 3 Main 層級和 SD 影片解碼設定檔，如下表所示。
• 應支援下表所示的 HD 解碼設定檔。
• 如果有硬體解碼器，則必須支援下表所列的 HD 解碼設定檔。
• 此外，Android TV 裝置：
• 必須支援 HD 720p 解碼設定檔。
• 強烈建議支援 HD 1080p 解碼設定檔。如果支援 HD 1080p 解碼設定檔，則必須支援 Main Profile Level 4.1 Main 層級。
• 應支援 UHD 解碼設定檔。如果支援 UHD 解碼設定檔，轉碼器就必須支援 Main10 Level 5 Main Tier 設定檔。

	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 fps (60 fps 1 )	60 fps
影片位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 必須為支援 H.265 硬體解碼的 Android TV 裝置實作。

5.3.6. VP8

Android 裝置實作項目，如果支援 第 5.1.3 節所述的 VP8 編解碼器：

• 必須支援下表中的 SD 解碼設定檔。
• 應支援下表中的 HD 解碼設定檔。
• Android TV 裝置必須支援 HD 1080p60 解碼設定檔。

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

1 當 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度時，必須使用。

2 必須實作 Android TV 裝置。

5.3.7. VP9

Android 裝置實作項目，如果支援 第 5.1.3 節所述的 VP9 編解碼器：

• 必須支援下表所列的 SD 影片解碼設定檔。
• 應支援下表所示的 HD 解碼設定檔。
• 如果有硬體解碼器，則必須支援下表所示的 HD 解碼設定檔。

• 此外，Android TV 裝置：

  • 必須支援 HD 720p 解碼設定檔。
  • 強烈建議支援 HD 1080p 解碼設定檔。
  • 應支援 UHD 解碼設定檔。如果支援 UHD 影片解碼設定檔，則該設定檔必須支援 8 位元色彩深度，並且應支援 VP9 Profile 2 (10 位元)。

	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 1 )	60 fps
影片位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 如要實作搭載 VP9 硬體解碼功能的 Android TV 裝置，必須符合此規定。

5.4. 錄音

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

5.4.1. 擷取原始音訊

宣告 android.hardware.microphone 的裝置實作方式，必須允許擷取具有下列特性的原始音訊內容：

• 格式：線性 PCM，16 位元
• 取樣率：8000、11025、16000、44100
• 管道：Mono

上述取樣率的擷取作業必須在不進行升頻的情況下完成，且任何降頻作業都必須包含適當的反鋸齒濾鏡。

宣告 android.hardware.microphone 的裝置實作方式應允許擷取具有下列特性的原始音訊內容：

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

如果系統支援上述取樣率的擷取作業，則擷取作業必須在 16000:22050 或 44100:48000 以上的升頻比率下完成。任何向上或向下取樣的動作都必須包含適當的反鋸齒濾鏡。

5.4.2. 語音辨識擷取

android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源必須支援以 44100 和 48000 等取樣率擷取內容。

除了上述錄音規格外，如果應用程式已開始使用 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流，則：

• 裝置應顯示大致平坦的振幅與頻率特性：具體來說，從 100 Hz 到 4000 Hz 的頻率應為 ±3 dB。
• 音訊輸入靈敏度應設為 16 位元樣本的 RMS 為 2500，以便 1000 Hz 的 90 dB 聲音功率 (SPL) 來源產生 RMS。
• PCM 振幅等級應以線性方式追蹤輸入 SPL 變化，至少在麥克風的 90 dB SPL 下，從 -18 dB 到 +12 dB 的範圍內。
• 在麥克風上，1 kHz 的總諧波失真率應低於 1%，且輸入音量為 90 dB SPL。
• 如有雜訊抑制處理功能，則必須停用。
• 自動增益控制 (如有) 必須停用。

如果平台支援針對語音辨識調整的噪音抑制技術，則必須透過 android.media.audiofx.NoiseSuppressor API 控制效果。此外，雜訊抑制器效果描述元 UUID 欄位必須明確識別每種雜訊抑制技術的實作方式。

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

android.media.MediaRecorder.AudioSource 類別包含 REMOTE_SUBMIX 音訊來源。聲明 android.hardware.audio.output 的裝置必須正確實作 REMOTE_SUBMIX 音訊來源，這樣當應用程式使用 android.media.AudioRecord API 從這個音訊來源錄音時，就能擷取所有音訊串流的混合內容，除了以下情況：

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. 音訊播放

宣告 android.hardware.audio.output 的裝置實作方式，必須符合本節的規定。

5.5.1. 原始音訊播放

裝置必須允許播放具有下列特性的原始音訊內容：

• 格式：線性 PCM，16 位元
• 取樣率：8000、11025、16000、22050、32000、44100
• 聲道：單聲道、立體聲

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

• 取樣率：24000、48000

5.5.2. 音效

Android 提供音訊效果 API，供裝置實作。宣告 android.hardware.audio.output 功能的裝置實作：

• 必須支援透過 AudioEffect 子類別 Equalizer、LoudnessEnhancer 可控的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 實作。
• 必須支援可透過 Visualizer 類別控制的 Visualizer API 實作。
• 應支援可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作。

5.5.3. 音訊輸出音量

Android TV 裝置實作必須支援系統主音量，並在支援的輸出裝置上減低數位音訊輸出音量，但壓縮音訊直通輸出 (在裝置上不會進行音訊解碼) 除外。

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

5.6. 音訊延遲

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

本節的定義如下：

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

強烈建議聲明 android.hardware.audio.output 的裝置實作符合或超越下列音訊輸出要求：

• 冷輸出延遲時間為 100 毫秒以下
• 連續輸出延遲時間為 45 毫秒或更短的時間
• 盡量減少冷輸出抖動

如果裝置實作在使用 OpenSL ES PCM 緩衝區佇列 API 時，經過任何初始校正後符合本節規定，且至少有一個支援的音訊輸出裝置，則強烈建議您透過 android.content.pm.PackageManager 類別回報 android.hardware.audio.low_latency 功能，以便回報持續輸出延遲和冷輸出延遲。反之，如果裝置實作不符合這些規定，則不得回報支援低延遲音訊。

強烈建議包含 android.hardware.microphone 的裝置實作符合下列輸入音訊規定：

• 冷輸入延遲時間為 100 毫秒以下
• 連續輸入延遲時間為 30 毫秒或更短
• 連續往返延遲時間為 50 毫秒或更短的時間
• 盡量減少冷輸入抖動

5.7. 網路通訊協定

裝置必須支援 Android SDK 說明文件中指定的媒體網路通訊協定，才能播放音訊和影片。具體來說，裝置必須支援下列媒體網路通訊協定：

• HTTP(S) 漸進式串流
  必須透過 HTTP(S) 支援第 5.1 節中所有必要的編解碼和容器格式

• HTTP 即時串流草稿通訊協定，第 7 版
  必須支援下列媒體區段格式：

區隔格式	參考資料	必要的轉碼器支援
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 節。
使用 ADTS 格式和 ID3 標記的 AAC	ISO 13818-7	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節
WebVTT	WebVTT

• RTSP (RTP、SDP)

  必須支援下列 RTP 音訊/視訊設定檔和相關轉碼器。如需例外狀況，請參閱第 5.1 節中的表格附註。

設定檔名稱	參考資料	必要的轉碼器支援
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. 安全無虞的媒體服務

支援安全視訊輸出功能且能夠支援安全途徑的裝置實作項目，必須聲明支援 Display.FLAG_SECURE。如果裝置實作聲明支援 Display.FLAG_SECURE，且支援無線顯示器通訊協定，則必須使用加密機制強大的機制 (例如 HDCP 2.x 以上版本) 保護連結，以便使用 Miracast 無線顯示器。同樣地，如果裝置支援有線外接螢幕，則裝置實作必須支援 HDCP 1.2 以上版本。如要支援 4K 解析度的 Android 電視裝置，則必須實作 HDCP 2.2；如要支援較低解析度的裝置，則必須實作 HDCP 1.4 以上版本。上游 Android 開放原始碼實作項目包括支援無線 (Miracast) 和有線 (HDMI) 顯示器，且符合這項規定。

5.9. 樂器數位介面 (MIDI)

如果裝置實作支援應用程式間的 MIDI 軟體傳輸 (虛擬 MIDI 裝置)，且支援透過 所有 以下支援 MIDI 的硬體傳輸 (可提供一般非 MIDI 連線) 傳輸 MIDI，強烈建議您透過 android.content.pm.PackageManager 類別回報支援 android.software.midi 功能。

支援 MIDI 的硬體傳輸裝置如下：

• USB 主機模式 (第 7.7 節 USB)
• USB 周邊裝置模式 (第 7.7 節 USB)
• 以藍牙 LE 做為中樞角色的 MIDI (第 7.4.3 節 藍牙)

相反地，如果裝置實作透過上述特定 MIDI 硬體傳輸機制提供一般非 MIDI 連線功能，但不支援透過該硬體傳輸機制傳輸 MIDI，則不得回報支援 android.software.midi 功能。

5.10. 專業音訊

如果裝置實作符合下列所有需求，強烈建議您透過 android.content.pm.PackageManager 類別，回報支援 android.hardware.audio.pro 功能。

• 裝置實作項目必須回報是否支援 android.hardware.audio.low_latency 功能。
• 根據第 5.6 節「音訊延遲」的定義，持續的往返音訊延遲時間必須低於 20 毫秒，且至少應低於 10 毫秒。
• 如果裝置內含 4 導體 3.5 公釐耳機插孔，則音訊插孔路徑的持續往返音訊延遲時間不得超過 20 毫秒，且應低於 10 毫秒。
• 裝置實作必須包含支援 USB 主機模式和 USB 周邊模式的 USB 連接埠。
• USB 主機模式必須實作 USB 音訊類別。
• 如果裝置包含 HDMI 連接埠，裝置實作必須支援以 20 位元或 24 位元深度和 192 kHz 的立體聲和八聲道輸出，且不會發生位元深度損失或重新取樣。
• 裝置實作必須回報是否支援 android.software.midi 功能。
• 如果裝置搭載 4 導體 3.5 公釐音訊插孔，強烈建議裝置實作符合有線音訊耳機規格 (第 1.1 版)的「行動裝置 (插孔) 規格」部分。

必須使用 OpenSL ES PCM 緩衝區佇列 API 滿足延遲和 USB 音訊需求。

此外，回報支援這項功能的裝置實作項目應符合下列條件：

• 在音訊運作期間提供可持續的 CPU 效能。
• 盡量減少音訊時鐘與標準時間的誤差和誤差變化。
• 在 CPU CLOCK_MONOTONIC 運作時，盡量減少音訊時鐘漂移。
• 盡量縮短裝置端轉換器的音訊延遲時間。
• 透過 USB 數位音訊縮短音訊延遲時間。
• 記錄所有路徑的音訊延遲時間測量結果。
• 盡量減少音訊緩衝區完成回呼輸入時間的抖動，因為這會影響回呼所使用的 CPU 頻寬百分比。
• 在正常使用情況下，在回報的延遲時間內，提供零音訊不足 (輸出) 或超載 (輸入) 的情況。
• 提供零管道間延遲差異。
• 盡量縮短所有傳輸方式的 MIDI 平均延遲時間。
• 在所有傳輸途徑中，盡量減少 MIDI 延遲時間變化 (抖動)。
• 透過所有傳輸方式提供準確的 MIDI 時間戳記。
• 盡量減少裝置端轉換器的音訊信號雜訊，包括冷啟動後的立即期。
• 當兩個端點都處於活動狀態時，請在對應端點的輸入和輸出端提供零音訊時鐘差。對應端點的例子包括裝置上的麥克風和喇叭，或音訊插孔輸入和輸出。
• 在同一個執行緒上，當輸入和輸出端的對應端點都處於作用中狀態時，請處理音訊緩衝區完成回呼，並在輸入回呼傳回後立即進入輸出回呼。或者，如果無法在同一個執行緒上處理回呼，請在輸入回呼後立即輸入輸出回呼，讓應用程式在輸入和輸出端保持一致的時間。
• 針對對應端點的輸入和輸出端，將 HAL 音訊緩衝區之間的相位差異降到最低。
• 盡量縮短觸控延遲時間。
• 盡量減少負載下觸控延遲時間的變化 (抖動)。

5.11. 未處理的擷取畫面

從 Android 7.0 開始，我們新增了一個錄製來源。您可以使用 android.media.MediaRecorder.AudioSource.UNPROCESSED 音訊來源存取這項功能。在 OpenSL ES 中，您可以使用錄音預設值 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 存取。

裝置必須滿足下列所有條件，才能透過 android.media.AudioManager 屬性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 回報支援未經處理的音訊來源：

• 裝置在中頻範圍內必須呈現大致平坦的振幅與頻率特性，具體來說，從 100 Hz 到 7000 Hz 的頻率範圍內，振幅應為 ±10 dB。

• 裝置必須在低頻率範圍內顯示振幅等級：具體來說，從 5 Hz 到 100 Hz 的振幅等級必須比中頻率範圍高出 ±20 dB。

• 裝置必須在高頻範圍中顯示振幅等級：具體來說，從 7000 Hz 到 22 KHz 的振幅等級必須比中頻範圍高出 ±30 dB。

• 音訊輸入靈敏度必須設為，以便在 94 dB 聲壓級 (SPL) 下播放 1000 Hz 正弦音源時，可產生 16 位元取樣 RMS 為 520 的回應 (或浮點/雙精度取樣 RMS 為 -36 dB 的回應)。

• SNR > 60 dB (94 dB SPL 與等效 SPL 的差異，以 A 加權)。

• 麥克風的 1 kHz 輸入音量為 90 dB SPL 時，總諧波失真率不得超過 1%。

• 路徑中唯一允許的信號處理方式，就是將音量調到所需範圍的音量乘數。此音量調節係數絕對不得對訊號路徑造成延遲。

• 路徑中不得進行其他訊號處理，例如自動增益控制、高通濾波器或回音消除。如果架構中因任何原因出現任何訊號處理，則必須停用該處理，並有效地為訊號路徑引入零延遲或額外延遲。

所有 SPL 測量皆直接在測試中的麥克風旁進行。

如果是多個麥克風設定，則這些規定適用於每個麥克風。

強烈建議裝置滿足未經處理錄音來源的訊號路徑相關要求，但如果裝置聲稱支援未經處理的音訊來源，則必須滿足上述所有這些要求。

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

6.1. 開發人員工具

裝置實作方式必須支援 Android SDK 提供的 Android 開發人員工具。Android 相容裝置必須與下列項目相容：

• Android Debug Bridge (ADB)
  • 裝置實作方式必須支援 Android SDK 中記載的所有 ADB 函式，包括 dumpsys。
  • 裝置端 ADB 守護程序必須預設為停用，且必須提供使用者可存取的機制，以便啟用 Android 偵錯橋接器。如果裝置實作方式省略 USB 周邊裝置模式，則必須透過區域網路 (例如乙太網路或 802.11) 實作 Android Debug Bridge。
  • Android 支援安全的 ADB。安全的 ADB 可在已知的已驗證主機上啟用 ADB。裝置實作方式必須支援安全的 ADB。
• Dalvik 偵錯監視器服務 (ddms)
  • 裝置實作項目必須支援 Android SDK 說明文件中所述的所有 ddms 功能。
  • 由於 ddm 會使用 ADB，因此系統預設應不支援 ddm，但在使用者啟用 Android Debug Bridge 時，系統必須支援 ddm，如上所述。
• Monkey 裝置實作項目必須包含 Monkey 架構，並讓應用程式可使用該架構。
• SysTrace
  • 裝置實作項目必須支援 Android SDK 中說明的 systrace 工具。根據預設，Systrace 必須處於停用狀態，且必須提供使用者可存取的機制來開啟 Systrace。
  • 大多數以 Linux 為基礎的系統和 Apple Macintosh 系統會使用標準 Android SDK 工具來辨識 Android 裝置，不需要額外支援；不過，Microsoft Windows 系統通常需要新款 Android 裝置的驅動程式。(舉例來說，新的供應商 ID 和有時新的裝置 ID 需要 Windows 系統的客製化 USB 驅動程式)。
  • 如果裝置實作項目未受標準 Android SDK 提供的 ADB 工具辨識，裝置實作者就必須提供 Windows 驅動程式，讓開發人員能夠透過 ADB 通訊協定連線至裝置。這些驅動程式必須提供給 Windows XP、Windows Vista、Windows 7、Windows 8 和 Windows 10 的 32 位元和 64 位元版本。

6.2. 開發人員選項

Android 提供開發人員可用來設定應用程式開發相關設定的支援功能。裝置實作必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，才能顯示應用程式開發相關設定。上游 Android 實作會預設隱藏「開發人員選項」選單，使用者只要按下「設定」 >「關於裝置」 >「版本號碼」選單項目七 (7) 次，即可啟動「開發人員選項」。裝置實作方式必須為開發人員選項提供一致的體驗。具體來說，裝置實作方式必須預設隱藏「開發人員選項」，並提供啟用「開發人員選項」的機制，且該機制必須與上游 Android 實作方式一致。

7. 硬體相容性

如果裝置包含特定硬體元件，且該元件具有第三方開發人員的對應 API，則裝置實作方式必須按照 Android SDK 說明文件的說明實作該 API。如果 SDK 中的 API 與硬體元件互動，而該硬體元件為選用元件，且裝置實作不含該元件：

• 您仍必須提供元件 API 的完整類別定義 (如 SDK 所述)。
• API 的行為必須以某種合理的方式實作為無作業。
• 在 SDK 說明文件允許的情況下，API 方法必須傳回空值。
• API 方法必須傳回類別的無操作導入方式，因為 SDK 說明文件不允許空值。
• API 方法不得擲回 SDK 說明文件未記載的例外狀況。

電話 API 就是適用這些規定的典型情境：即使是在非手機裝置上，這些 API 也必須以合理的無作業方式實作。

裝置實作項目必須針對相同的建構指紋，透過 android.content.pm.PackageManager 類別的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法，一律回報正確的硬體設定資訊。

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 架構支援各種螢幕大小，並允許應用程式透過 SCREENLAYOUT_SIZE_MASK，使用 android.content.res.Configuration.screenLayout 查詢裝置螢幕大小 (又稱「螢幕版面配置」)。裝置實作項目必須回報正確的螢幕大小，這項資訊已在 Android SDK 說明文件中定義，並由上游 Android 平台決定。具體來說，裝置實作項目必須根據下列邏輯密度獨立像素 (dp) 螢幕尺寸，回報正確的螢幕大小。

• 除非是 Android Watch 裝置，否則裝置的螢幕尺寸必須至少為 426 dp x 320 dp (「小」)。
• 回報螢幕尺寸為「正常」的裝置，螢幕尺寸必須至少為 480 dp x 320 dp。
• 回報螢幕大小為「large」的裝置，螢幕大小必須至少為 640 dp x 480 dp。
• 回報螢幕大小為「xlarge」的裝置，螢幕尺寸必須至少為 960 dp x 720 dp。

此外：

• Android Watch 裝置的螢幕實體對角尺寸必須介於 1.1 到 2.5 英寸之間。
• Android Automotive 裝置的螢幕對角線必須大於或等於 6 吋。
• Android Automotive 裝置的螢幕尺寸必須至少為 750 dp x 480 dp。
• 其他類型的 Android 裝置實作方式 (實體整合式螢幕)，螢幕的對角線尺寸必須至少為 2.5 英寸。

裝置絕對不得變更回報的螢幕大小。

應用程式可選擇透過 AndroidManifest.xml 檔案中的 <supports-screens> 屬性，指出支援的螢幕尺寸。裝置實作項目必須正確遵循應用程式所聲明的支援螢幕大小，包括小螢幕、中等螢幕、大螢幕和特大螢幕，詳情請參閱 Android SDK 說明文件。

7.1.1.2. 螢幕顯示比例

雖然實體螢幕顯示器的螢幕顯示比例值沒有限制，但第三方應用程式算繪的表面螢幕顯示比例 (可從透過 DisplayMetrics 回報的值推導而得) 必須符合下列規定：

• 如果 uiMode 已設為 UI_MODE_TYPE_WATCH，則可將顯示比例值設為 1.0 (1:1)。
• 如果第三方應用程式透過 android:resizeableActivity 屬性表示可調整大小，則顯示比例值沒有任何限制。
• 在所有其他情況下，顯示比例必須介於 1.3333 (4:3) 和 1.86 (大約 16:9) 之間，除非應用程式已明確表示透過 maxAspectRatio 中繼資料值支援更高的螢幕顯示比例。

7.1.1.3. 螢幕密度

Android UI 架構定義了一組標準邏輯密度，協助應用程式開發人員指定應用程式資源。裝置實作項目必須透過 android.util.DisplayMetrics API 回報下列邏輯 Android 架構密度之一，並且必須以此標準密度執行應用程式，且不得隨時變更預設螢幕的值。

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 dpi (高解析度)
• 280 dpi (280dpi)
• 320 dpi (xhdpi)
• 360 dpi (360dpi)
• 400 dpi (400dpi)
• 420 dpi (420dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560dpi)
• 640 dpi (xxxhdpi)

裝置實作項目應定義標準 Android 架構密度，其數值應與螢幕的實體密度最為接近，除非該邏輯密度會使回報的螢幕大小低於最低支援大小。如果標準 Android 架構密度與實體密度數值最接近，但導致螢幕大小小於最小支援的相容螢幕大小 (320 dp 寬度)，則裝置實作應回報下一個較低的標準 Android 架構密度。

強烈建議裝置實作項目提供使用者變更顯示大小的設定。如果有實作項目可變更裝置的顯示大小，則該項目必須與 AOSP 實作項目保持一致，如下所示：

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

7.1.2. 多媒體廣告指標

裝置實作項目必須針對 android.util.DisplayMetrics 中定義的所有顯示指標回報正確值，且無論是否使用嵌入式或外接螢幕做為預設顯示裝置，都必須回報相同的值。

7.1.3. 螢幕方向

裝置必須回報支援的螢幕方向 (android.hardware.screen.portrait 和/或 android.hardware.screen.landscape)，且必須回報至少一種支援的螢幕方向。舉例來說，如果裝置的螢幕固定為橫向，例如電視或筆記型電腦，則應只回報 android.hardware.screen.landscape。

同時回報兩種螢幕方向的裝置，必須支援應用程式以直向或橫向螢幕方向進行動態調整。也就是說，裝置必須遵循應用程式要求的特定螢幕方向。裝置實作可能會將直向或橫向方向設為預設值。

無論透過 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查詢，裝置都必須回報裝置目前的正確方向值。

變更螢幕方向時，裝置不得變更回報的螢幕大小或密度。

7.1.4. 2D 和 3D 圖形加速功能

裝置實作方式必須同時支援 OpenGL ES 1.0 和 2.0，如 Android SDK 說明文件所述及詳情說明。裝置實作項目應在支援的裝置上支援 OpenGL ES 3.0、3.1 或 3.2。裝置實作項目也必須支援 Android RenderScript，詳情請參閱 Android SDK 說明文件。

裝置實作項目也必須正確識別自己是否支援 OpenGL ES 1.0、OpenGL ES 2.0、OpenGL ES 3.0、OpenGL 3.1 或 OpenGL 3.2。也就是：

• 受管理的 API (例如透過 GLES10.getString() 方法) 必須回報支援 OpenGL ES 1.0 和 OpenGL ES 2.0。
• 原生 C/C++ OpenGL API (可透過 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 提供給應用程式的 API) 必須回報支援 OpenGL ES 1.0 和 OpenGL ES 2.0。
• 宣告支援 OpenGL ES 3.0、3.1 或 3.2 的裝置實作必須支援對應的受管理 API，並納入原生 C/C++ API 支援。在宣告支援 OpenGL ES 3.0、3.1 或 3.2 的裝置實作中，libGLESv2.so 除了 OpenGL ES 2.0 函式符號外，也必須匯出對應的函式符號。

Android 提供 OpenGL ES 擴充功能套件，其中包含 Java 介面，並原生支援分割平鋪和 ASTC 紋理壓縮格式等進階圖形功能。如果裝置支援 OpenGL ES 3.2，則 Android 裝置實作項目必須支援擴充功能包，否則則可支援。如果擴充功能包獲得完整支援，裝置就必須透過 android.hardware.opengles.aep 功能旗標識別支援。

此外，裝置實作項目也可能會實作任何所需的 OpenGL ES 擴充功能。不過，裝置實作必須透過 OpenGL ES 受管理和原生 API 回報所有支援的擴充功能字串，反之，則不得回報不支援的擴充功能字串。

請注意，Android 支援應用程式可選擇指定需要特定 OpenGL 紋理壓縮格式。這類格式通常為供應商專用。Android 不需要裝置實作項目實作任何特定紋理壓縮格式。不過，應用程式應透過 OpenGL API 中的 getString() 方法，準確回報所支援的任何紋理壓縮格式。

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

裝置實作項目必須預設啟用硬體加速功能，且如果開發人員要求，則必須停用硬體加速功能，方法是將 android:hardwareAccelerated 設為「false」，或直接透過 Android View API 停用硬體加速功能。

此外，裝置實作功能必須符合 Android SDK 說明文件中關於硬體加速的行為。

Android 包含 TextureView 物件，可讓開發人員直接將硬體加速的 OpenGL ES 材質整合為 UI 階層中的算繪目標。裝置實作項目必須支援 TextureView API，且必須與上游 Android 實作項目的行為一致。

Android 支援 EGL_ANDROID_RECORDABLE，這是 EGLConfig 屬性，可指出 EGLConfig 是否支援將圖片轉譯至可將圖片記錄至影片的 ANativeWindow。裝置實作項目必須支援 EGL_ANDROID_RECORDABLE 擴充功能。

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

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

• Android Automotive 不支援舊版相容模式。
• 所有其他裝置實作方式都必須支援由上游 Android 開放原始碼實作的舊版應用程式相容模式。也就是說，裝置實作方式不得變更觸發條件或相容性模式的啟用門檻，也不得變更相容性模式本身的行為。

7.1.6. 螢幕技術

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

• 裝置必須支援可算繪 16 位元彩色圖形的螢幕，並建議支援可算繪 24 位元彩色圖形的螢幕。
• 裝置必須支援可算繪動畫的螢幕。
• 使用的顯示器技術必須具有 0.9 到 1.15 之間的像素顯示比例 (PAR)。也就是說，像素顯示比例必須接近正方形 (1.0)，容許值為 10% 至 15%。

7.1.7. 次要螢幕

Android 支援第二螢幕，可啟用媒體分享功能，並提供開發人員 API 來存取外部螢幕。如果裝置支援透過有線、無線或內嵌額外顯示器連線的方式連接外接螢幕，則裝置實作必須實作 顯示器管理器 API，如 Android SDK 說明文件所述。

7.2. 輸入裝置

裝置必須支援觸控螢幕，或符合 7.2.2 節中列出的非觸控導覽功能需求。

7.2.1. 鍵盤

裝置實作方式：

• 必須支援輸入管理架構 (可讓第三方開發人員建立輸入法編輯器，也就是軟體鍵盤)，詳情請參閱 http://developer.android.com。
• 必須提供至少一個軟體鍵盤 (無論是否有實體鍵盤)，但 Android Watch 裝置除外，因為其螢幕尺寸不太適合使用軟體鍵盤。
• 可納入其他螢幕鍵盤實作。
• 可包含硬體鍵盤。
• 請務必不要加入不符合 android.content.res.Configuration.keyboard 中指定格式 (QWERTY 或 12 鍵) 的實體鍵盤。

7.2.2. 非觸控導覽

裝置實作方式：

• 如果裝置實作不是 Android TV 裝置，則可省略非觸控導覽選項 (軌跡球、D-Pad 或方向盤)。
• 必須回報 android.content.res.Configuration.navigation 的正確值。
• 必須提供合理的替代使用者介面機制，用於選取及編輯文字，且必須與輸入管理引擎相容。上游 Android 開放原始碼實作內容包含選取機制，適合用於缺乏非觸控導覽輸入功能的裝置。

7.2.3. 瀏覽鍵

主畫面、近期使用和返回功能 (分別對應至按鍵事件 KEYCODE_HOME、KEYCODE_APP_SWITCH、KEYCODE_BACK) 對 Android 導覽模式至關重要，因此：

• Android 手持裝置實作項目必須提供「主畫面」、「最近使用」和「返回」功能。
• Android TV 裝置實作項目必須提供「Home」和「Back」功能。
• Android Watch 裝置實作必須提供「Home」功能供使用者使用，並提供「Back」功能 (除非處於 UI_MODE_TYPE_WATCH 狀態)。
• Android Watch 裝置實作項目 (而非其他 Android 裝置類型) 可能會使用按鍵事件 KEYCODE_BACK 的長按事件，並略過將該事件傳送至前景應用程式。
• Android Automotive 實作項目必須提供 Home 功能，並可提供 Back 和 Recent 功能。
• 所有其他類型的裝置實作都必須提供「Home」和「Back」功能。

這些功能可透過專屬實體按鈕 (例如機械式或電容式觸控按鈕) 實作，也可以透過螢幕上特定區域的專屬軟體按鈕、手勢、觸控面板等實作。Android 支援這兩種實作方式。所有這些功能都必須在可見時，透過單一動作 (例如輕觸、雙擊或手勢) 即可存取。

如果提供「最近使用的」功能，則必須有可見的按鈕或圖示，除非全螢幕模式下與其他導覽功能一併隱藏。這項異動不適用於從舊版 Android 升級的裝置，因為這些裝置有實體導覽按鈕，但沒有「最近使用的應用程式」鍵。

如果提供「Home」和「Back」功能，則每個功能都必須有可見的按鈕或圖示，除非在全螢幕模式下與其他導覽功能一起隱藏，或是 uiMode UI_MODE_TYPE_MASK 設為 UI_MODE_TYPE_WATCH。

自 Android 4.0 起，Menu 函式已淘汰，改用動作列。因此，搭載 Android 7.0 以上版本的新裝置實作項目不得實作專屬的選單按鈕。較舊的裝置實作項目不應為選單功能實作專屬實體按鈕，但如果實作實體選單按鈕，且裝置執行的應用程式 targetSdkVersion 大於 10，則裝置實作項目：

• 當行動列顯示行動溢位按鈕，且行動溢位選單彈出式視窗不為空白時，行動列必須顯示行動溢位按鈕。如果是搭載 Android 4.4 以下版本的裝置，但升級至 Android 7.0，則建議採用這種做法。
• 請勿修改透過選取動作列中的溢位按鈕顯示的動作溢位視窗位置。
• 選取實體選單按鈕時，動作溢位視窗會顯示在螢幕上經過修改的位置。

為了回溯相容性，當 targetSdkVersion 小於 10 時，裝置實作必須透過實體按鈕、軟體按鍵或手勢，讓應用程式可使用 Menu 函式。除非與其他導覽功能一併隱藏，否則應顯示此 Menu 函式。

支援 輔助動作和/或 VoiceInteractionService 的 Android 裝置實作項目，必須能夠在其他導覽鍵可見時，透過單一互動 (例如輕觸、雙擊或手勢) 啟動輔助應用程式。強烈建議您使用長按主畫面做為這項互動。指定的互動動作必須啟動使用者選取的輔助應用程式，也就是導入 VoiceInteractionService 的應用程式，或處理 ACTION_ASSIST 意圖的活動。

裝置實作可能會使用螢幕的不同部分來顯示導覽鍵，但如果是這種情況，則必須符合下列規定：

• 裝置實作導覽鍵時，請務必使用螢幕的獨立部分 (應用程式無法使用)，且不得遮蓋或以其他方式干擾應用程式可用的螢幕部分。
• 裝置實作必須將部分螢幕畫面提供給符合第 7.1.1 節所定義的應用程式。
• 如果應用程式未指定系統 UI 模式，或指定 SYSTEM_UI_FLAG_VISIBLE，裝置實作項目就必須顯示導覽鍵。
• 當應用程式指定 SYSTEM_UI_FLAG_LOW_PROFILE 時，裝置實作方式必須以不顯眼的「低調」(例如調低亮度) 模式顯示導覽鍵。
• 當應用程式指定 SYSTEM_UI_FLAG_HIDE_NAVIGATION 時，裝置實作項目必須隱藏導覽鍵。

7.2.4. 觸控螢幕輸入

裝置實作項目應具備某種指標輸入系統 (類似滑鼠或觸控)。不過，如果裝置實作不支援指標輸入系統，則不得回報 android.hardware.touchscreen 或 android.hardware.faketouch 功能常數。裝置實作方式確實包含指標輸入系統：

• 如果裝置輸入系統支援多個指標，則應支援完全獨立追蹤的指標。
• 必須回報 android.content.res.Configuration.touchscreen 的值，對應至裝置上特定觸控螢幕的類型。

Android 支援多種觸控螢幕、觸控板和假觸控輸入裝置。以觸控螢幕為基礎的裝置實作會與螢幕相關聯，讓使用者有直接操作畫面上項目的感受。由於使用者是直接觸碰螢幕，系統不需要任何額外的操作元素來指出正在操作的物件。相較之下，觸控模擬介面會提供使用者輸入系統，可模擬部分觸控螢幕功能。舉例來說，滑鼠或遙控器驅動螢幕上的游標，類似於觸控操作，但使用者必須先指向或聚焦，再點選。滑鼠、觸控板、陀螺儀空中滑鼠、陀螺儀指標、搖桿和多點觸控觸控板等許多輸入裝置，都支援觸控模擬互動。Android 包含功能常數 android.hardware.faketouch，對應至高保真非觸控 (以指標為準) 輸入裝置，例如滑鼠或觸控板，可充分模擬以觸控為基礎的輸入方式 (包括基本手勢支援)，並表示裝置支援模擬的觸控螢幕功能子集。宣告假觸控功能的裝置實作方式，必須符合第 7.2.5 節的假觸控需求。

裝置實作項目必須回報正確的功能，對應於所使用的輸入類型。包含觸控螢幕 (單點觸控或更高) 的裝置實作方式，必須回報平台功能常數 android.hardware.touchscreen。回報平台功能常數 android.hardware.touchscreen 的裝置實作項目，也必須回報平台功能常數 android.hardware.faketouch。不含觸控螢幕 (僅依賴指標裝置) 的裝置實作項目不得回報任何觸控螢幕功能，且如果符合第 7.2.5 節的觸控模擬要求，則必須只回報 android.hardware.faketouch。

7.2.5. 模擬觸控輸入

聲明支援 android.hardware.faketouch 的裝置實作：

• 必須回報指標位置的 絕對 X 和 Y 螢幕位置，並在畫面上顯示視覺指標。
• 您必須使用動作代碼回報觸控事件，指定指標在螢幕上向下或向上移動時發生的狀態變更。
• 必須支援在螢幕上對物件向上下移動指標，讓使用者模擬輕觸螢幕上的物件。
• 必須在時間門檻內，支援在畫面上某個物件的相同位置，執行「指標向下」、「指標向上」、「指標向下」和「指標向上」的動作，讓使用者能夠模擬雙擊畫面上的物件。
• 必須支援在螢幕上任意點按下指標，然後指標移動至螢幕上任意其他點，接著指標向上移動，讓使用者模擬觸控拖曳動作。
• 必須支援指標向下，讓使用者快速將物件移至螢幕上的不同位置，然後指標向上，讓使用者在螢幕上揮動物件。

宣告支援 android.hardware.faketouch.multitouch.distinct 的裝置必須符合上述 faketouch 的規定，且必須支援兩個或更多獨立指標輸入的不同追蹤。

7.2.6. 遊戲控制器支援功能

Android TV 裝置實作方式必須支援下列遊戲控制器的按鈕對應。上游 Android 實作項目包含符合這項規定的遊戲控制器實作項目。

7.2.6.1. 按鈕對應

Android TV 裝置實作方式必須支援下列按鍵對應：

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

1 個 KeyEvent

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

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

4 MotionEvent

類比控制項 1	HID 用量	Android 按鈕
左側扳機鍵	0x02 0x00C5	AXIS_LTRIGGER
右扳機	0x02 0x00C4	AXIS_RTRIGGER
左搖桿	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
右搖桿	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. 遙控器

Android TV 裝置實作項目應提供遙控器，讓使用者存取 TV 介面。遙控器可以是實體遙控器，也可以是可透過手機或平板電腦存取的軟體遙控器。遙控器必須符合下列規定。

• 搜尋提示。當使用者透過實體或軟體遙控器啟動語音搜尋功能時，裝置實作必須觸發 KEYCODE_SEARCH。
• 導覽 . 所有 Android TV 遙控器都必須包含「返回」、「主畫面」和「選取」按鈕，並支援方向鍵事件。

7.3. 感應器

Android 提供 API，可存取各種感應器類型。裝置實作通常可省略這些感應器，如以下各節所述。如果裝置包含特定感應器類型，且該類型有對應的 API 供第三方開發人員使用，則裝置實作必須實作該 API，如 Android SDK 說明文件和 Android 開放原始碼說明文件中所述的感應器。例如裝置實作：

• 必須根據 android.content.pm.PackageManager 類別，準確回報感應器是否存在。
• 必須透過 SensorManager.getSensorList() 和類似方法，傳回正確的支援感應器清單。
• 必須針對所有其他感應器 API 合理運作 (例如，在應用程式嘗試註冊事件監聽器時，適當地傳回 true 或 false，在沒有對應感應器時不呼叫感應器事件監聽器，等等)。
• 必須使用 Android SDK 說明文件中定義的各感應器類型相關國際單位制 (公制) 值，回報所有感應器測量值。
• 應以 Android SDK 說明文件中定義的時間單位 (奈秒) 回報事件時間，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘同步。現有和新款 Android 裝置強烈建議符合這些規定，以便升級至日後的平台版本，因為這可能會成為必要元件。同步處理錯誤應低於 100 毫秒。
• 在應用程式處理器運作時，如果感應器的傳送延遲時間為 5 毫秒 + 2 * sample_time，則感應器資料的傳送延遲時間不得超過 100 毫秒 + 2 * sample_time。這項延遲時間不包含任何篩選延遲時間。
• 必須在感應器啟用後的 400 毫秒 + 2 * sample_time 內回報第一個感應器樣本。這個樣本的精確度為 0 是可接受的。

上述清單並非完整列出所有情況；請參閱 Android SDK 的說明文件和 Android 開放原始碼文件中關於感應器的行為，以便瞭解相關資訊。

某些感應器類型為複合類型，也就是說，它們可以衍生自一或多個其他感應器提供的資料。(例如方向感應器和線性加速度感應器)。裝置實作項目應實作這些感應器類型，前提是這些感應器必須包含「感應器類型」一節所述的必要實體感應器。如果裝置實作包含複合感應器，則必須按照 Android 開放原始碼說明文件中「複合感應器」一節所述，實作該感應器。

部分 Android 感應器支援「持續」觸發模式，可持續傳回資料。對於 Android SDK 說明文件中指出為連續感應器的任何 API，裝置實作必須持續提供定期資料樣本，且雜訊應低於 3%，其中雜訊是指連續事件之間回報的時間戳記值差異的標準差。

請注意，裝置實作必須確保感應器事件串流不得防止裝置 CPU 進入暫停狀態，或從暫停狀態喚醒。

最後，當多個感應器啟用時，耗電量不應超過個別感應器回報的耗電量總和。

7.3.1. 加速計

裝置實作應包含 3 軸式加速度計。強烈建議 Android 手持裝置、Android Automotive 實作項目和 Android Watch 裝置加入此感應器。如果裝置實作包含 3 軸式加速度計，則會：

• 必須實作並回報 TYPE_ACCELEROMETER 感應器。
• 對於 Android Watch 裝置，必須能夠回報至少 50 Hz 的事件頻率 (此類裝置的電力限制較嚴格)，對於所有其他裝置類型則必須能夠回報 100 Hz 的事件頻率。
• 應回報的事件頻率應至少為 200 Hz。
• 必須遵循 Android API 中詳述的 Android 感應器座標系統。Android Automotive 實作項目必須遵循 Android 車輛感應器座標系統。
• 必須能夠在任何軸線上測量自由落體運動，最高可達重力 (4g) 的四倍。
• 解析度必須至少為 12 位元，且應至少為 16 位元。
• 如果特性在生命週期內發生變化，且已進行補償，則應在使用期間進行校正，並在裝置重新啟動時保留補償參數。
• 應進行溫度補償。
• 標準差必須小於 0.05 m/s^，且應根據每個軸以最快的取樣率，在至少 3 秒的時間內收集的樣本計算標準差。
• 應實作 Android SDK 文件中所述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR 和 TYPE_STEP_COUNTER 複合感應器。我們強烈建議現有和新款 Android 裝置實作 TYPE_SIGNIFICANT_MOTION 複合感應器。如果實作任何上述感應器，其耗電量總和必須低於 4 毫瓦，且在裝置處於動態或靜態狀態時，每個感應器的耗電量應低於 2 毫瓦和 0.5 毫瓦。
• 如果包含陀螺儀感應器，則必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器，並應實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。強烈建議現有和新款 Android 裝置實作 TYPE_GAME_ROTATION_VECTOR 感應器。
• 如果也包含陀螺儀感應器和磁力儀感應器，則必須實作 TYPE_ROTATION_VECTOR 複合感應器。

7.3.2. 磁力儀

裝置實作應包含 3 軸式磁力計 (指南針)。如果裝置內含 3 軸式磁力計，則會：

• 必須實作 TYPE_MAGNETIC_FIELD 感應器，並且應實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。強烈建議現有和新款 Android 裝置實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。
• 必須能夠回報至少 10 Hz 的事件頻率，並且應回報至少 50 Hz 的事件頻率。
• 必須遵循 Android API 中詳述的 Android 感應器座標系統。
• 必須能夠在飽和前，在各軸上測量 -900 µT 至 +900 µT 之間的值。
• 硬鐵偏移值必須小於 700 µT，且應小於 200 µT，方法是將磁力計遠離動態 (電流誘導) 和靜態 (磁鐵誘導) 磁場。
• 解析度必須等於或大於 0.6 µT，且應等於或大於 0.2 µT。
• 應進行溫度補償。
• 必須支援硬鐵偏差的線上校正和補償，並在裝置重新啟動之間保留補償參數。
• 必須套用軟鐵補償功能，可在使用中或裝置製造期間進行校正。
• 應具有標準差，以最快的取樣率，在至少 3 秒的時間內收集的樣本為基礎，逐軸計算，不得超過 0.5 µT。
• 如果也包含加速計感應器和陀螺儀感應器，則必須實作 TYPE_ROTATION_VECTOR 複合感應器。
• 如果也實作了加速計感應器，則可實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。不過，如果實作這項功能，感應器在以 10 Hz 的頻率註冊批次模式時，耗電量應低於 3 毫瓦。

7.3.3. GPS

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

• 我們強烈建議在緊急電話通話期間，裝置應繼續向應用程式提供正常的 GPS/GNSS 輸出內容，且位置輸出內容不得遭到封鎖。
• 透過 LocationManager#requestLocationUpdate 要求時，位置輸出必須以至少 1 Hz 的速率支援。
• 連上 0.5 Mbps 以上速度的網際網路連線時，必須能在 10 秒內 (快速首次定位時間) 判斷開放天空環境 (訊號強、多路徑效應微乎其微、HDOP 小於 2) 的位置。通常會透過使用某種形式的輔助或預測 GPS/GNSS 技術，以盡可能縮短 GPS/GNSS 鎖定時間 (輔助資料包括參考時間、參考位置和衛星定時碼/時鐘)，以符合這項規定。
  • 進行這類位置計算後，強烈建議裝置能夠在開放天空下，在位置要求重新啟動時，於 10 秒內判斷自身位置，並在初始位置計算後的 1 小時內，即使後續要求是在沒有資料連線和/或電源週期後提出，也能判斷自身位置。
• 在空曠地區確定位置後，如果車輛靜止不動或移動速度低於每秒平方公尺 1 公尺的加速度，請執行下列操作：
  • 至少在 95% 的時間內，必須能夠判斷 20 公尺以內的位置，以及每秒 0.5 公尺以內的速度。
  • 必須透過 GnssStatus.Callback 同時追蹤及回報至少 8 顆來自同一衛星座群的衛星。
  • 應可同時追蹤至少 24 顆衛星，來自多個星座 (例如 GPS + 至少一個全球導航衛星系統、北斗、Galileo)。
• 必須透過測試 API「getGnssYearOfHardware」回報 GNSS 技術世代。
• 如果 GNSS 技術世代回報為「2016」年或更新版本，強烈建議您必須符合下列所有規定。
  • 即使尚未回報透過 GPS/GNSS 計算的位置，也必須在找到 GPS 測量值時立即回報。
  • 必須回報 GPS 偽距離和偽距離速率，在確定位置後，在無遮蔽天空的情況下，當裝置處於靜止狀態或以每秒 0.2 公尺以下的加速度移動時，至少有 95% 的時間，系統都能計算出 20 公尺以內的位置和每秒 0.2 公尺以內的速度。

請注意，雖然上述部分 GPS 規定列為「強烈建議」，但下一個主要版本的相容性定義預計會將這些規定改為「必須」。

7.3.4. 陀螺儀

裝置實作應包含陀螺儀 (角變化感應器)。裝置不應包含陀螺儀感應器，除非也包含 3 軸加速計。如果裝置實作包含陀螺儀，則會：

• 您必須實作 TYPE_GYROSCOPE 感應器，並且應實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。我們強烈建議現有和新款 Android 裝置實作 SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 感應器。
• 必須能夠以每秒 1,000 度為單位測量方向變化。
• 對於 Android Watch 裝置，必須能夠回報至少 50 Hz 的事件頻率 (此類裝置的電力限制較嚴格)，對於所有其他裝置類型則必須能夠回報 100 Hz 的事件頻率。
• 應回報的事件頻率應至少為 200 Hz。
• 解析度必須為 12 位元以上，且應為 16 位元以上。
• 必須進行溫度補償。
• 在使用期間必須進行校正和補償，並在裝置重新啟動時保留補償參數。
• 變化值不得超過每 Hz 1e-7 弧度^2 / 秒^2 (每 Hz 變化值，或弧度^2 / 秒)。變化範圍可隨取樣率而異，但必須受此值限制。換句話說，如果您以 1 Hz 的取樣率測量陀螺儀的變異數，其值應不超過 1e-7 rad^2/s^2。
• 如果也包含加速計感應器和磁力儀感應器，則必須實作 TYPE_ROTATION_VECTOR 複合感應器。
• 如果包含加速計感應器，則必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器，並應實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。強烈建議現有和新款 Android 裝置實作 TYPE_GAME_ROTATION_VECTOR 感應器。

7.3.5. 氣壓計

裝置實作應包含氣壓計 (環境氣壓感應器)。如果裝置實作項目包含氣壓計，則會執行以下操作：

• 必須導入並回報 TYPE_PRESSURE 感應器。
• 必須能夠以 5 Hz 以上的頻率傳送事件。
• 必須具備足夠的精確度，才能估算高度。
• 必須進行溫度補償。

7.3.6. 溫度計

裝置實作可能會包含環境溫度計 (溫度感應器)。如果有此屬性，則必須定義為 SENSOR_TYPE_AMBIENT_TEMPERATURE，且必須以攝氏度測量環境 (房間) 溫度。

裝置實作項目可以 (但不應) 包含 CPU 溫度感應器。如果有此值，則必須定義為 SENSOR_TYPE_TEMPERATURE，且必須測量裝置 CPU 的溫度，且不得測量任何其他溫度。請注意，SENSOR_TYPE_TEMPERATURE 感應器類型已在 Android 4.0 淘汰。

7.3.7. 光度計

裝置實作可能會包含光度計 (環境光感應器)。

7.3.8. 鄰近感應器

裝置實作可能會包含鄰近感應器。可撥打語音通話且在 getPhoneType 中顯示 PHONE_TYPE_NONE 以外任何值的裝置，應包含接近感應器。如果裝置實作包含鄰近感應器，則會：

• 必須測量物體與螢幕方向相同的鄰近性。也就是說，接近感應器必須以偵測螢幕附近物體為方向，因為這類感應器的主要用途是偵測使用者正在使用的手機。如果裝置實作包含任何其他方向的鄰近感應器，則不得透過此 API 存取。
• 必須具備 1 位元以上的準確度。

7.3.9. 高精確度感應器

如要支援可滿足本節所列所有要求的高品質感應器，裝置實作必須透過 android.hardware.sensor.hifi_sensors 功能旗標識別支援。

聲明 android.hardware.sensor.hifi_sensors 的裝置，必須支援下列所有符合品質要求的感應器類型：

• SENSOR_TYPE_ACCELEROMETER
  • 測量範圍必須至少介於 -8g 和 +8g 之間。
  • 測量解析度必須至少為 1024 LSB/G。
  • 測量頻率必須為 12.5 Hz 以下。
  • 測量頻率上限必須為 400 Hz 以上。
  • 測量雜訊不得超過 400 uG/√Hz。
  • 必須實作此感應器的非喚醒形式，並提供至少 3000 個感應器事件的緩衝功能。
  • 必須具備不超過 3 毫瓦的批次耗電量。
  • 應具備 24 小時靜態資料集的靜態雜訊偏差穩定性，小於 15 μg/√Hz。
  • 偏差變化與溫度的關係應為 ≤ +/- 1mg / °C。
  • 最佳擬合線非線性應為 0.5% 以下，靈敏度變化與溫度應為 0.03%/°C 以下。

• SENSOR_TYPE_GYROSCOPE

  • 測量範圍必須至少介於 -1000 和 +1000 dps 之間。
  • 測量解析度必須至少為 16 LSB/dps。
  • 測量頻率必須為 12.5 Hz 以下。
  • 測量頻率上限必須為 400 Hz 以上。
  • 測量雜訊不得超過 0.014°/s/√Hz。
  • 應具備 24 小時靜態資料集的靜止偏差穩定性 < 0.0002 °/s √Hz。
  • 偏差變化與溫度的差異應為 ≤ +/- 0.05 °/ s / °C。
  • 敏感度變化與溫度之間的差異應小於 0.02% / °C。
  • 最佳擬合線的非線性應低於 0.2%。
  • 噪音密度應低於 0.007 °/s/√Hz。

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 與 SENSOR_TYPE_GYROSCOPE 的品質要求相同。

• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • 測量範圍必須至少介於 -900 和 +900 微特斯拉之間。
  • 測量解析度必須至少為 5 LSB/uT。
  • 測量頻率必須低於或等於 5 Hz。
  • 測量頻率上限必須為 50 Hz 以上。
  • 測量雜訊不得超過 0.5 uT。
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED 與 SENSOR_TYPE_GEOMAGNETIC_FIELD 的品質要求相同，但另外規定：
  • 必須實作此感應器的非喚醒形式，且緩衝功能至少可容納 600 個感應器事件。
• SENSOR_TYPE_PRESSURE
  • 測量範圍必須至少介於 300 和 1100 hPa 之間。
  • 測量解析度必須至少為 80 LSB/hPa。
  • 測量頻率必須低於或等於 1 Hz。
  • 測量頻率上限必須為 10 Hz 以上。
  • 測量雜訊不得超過 2 Pa/√Hz。
  • 必須實作此感應器的非喚醒形式，並提供至少 300 個感應器事件的緩衝功能。
  • 必須具備不超過 2 毫瓦的批次耗電量。
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • 必須實作此感應器的非喚醒形式，並提供至少 300 個感應器事件的緩衝功能。
  • 必須具備不超過 4 毫瓦的批次耗電量。
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
• SENSOR_TYPE_STEP_DETECTOR
  • 必須實作此感應器的非喚醒形式，且緩衝功能至少要有 100 個感應器事件。
  • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
  • 必須具備不超過 4 毫瓦的批次耗電量。
• SENSOR_TYPE_STEP_COUNTER
  • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。
• SENSOR_TILT_DETECTOR
  • 裝置靜止時的耗電量不得超過 0.5 毫瓦，移動時不得超過 1.5 毫瓦。

此外，這類裝置也必須符合下列感應器子系統規定：

• 加速計、陀螺儀感應器和磁力計回報的相同物理事件，其事件時間戳記必須相差 2.5 毫秒以內。
• 陀螺儀感應器事件時間戳記必須與攝影機子系統使用相同的時間基準，且誤差不得超過 1 毫秒。
• 高保真感應器必須在資料從實體感應器傳送至應用程式後的 5 毫秒內，將資料傳送至應用程式。
• 啟用下列任何感應器組合時，裝置靜止時的耗電量不得超過 0.5 毫瓦，裝置移動時的耗電量不得超過 2.0 毫瓦：
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

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

在宣告 android.hardware.sensor.hifi_sensors 的裝置實作中，也可能支援下列感應器類型，但如果這些感應器類型存在，則必須符合下列最小緩衝區功能需求：

• SENSOR_TYPE_PROXIMITY：100 個感應器事件

7.3.10. 指紋感應器

裝置實作項目如果設有安全的螢幕鎖定功能，應納入指紋感應器。如果裝置實作包含指紋感應器，且有對應的 API 供第三方開發人員使用，則：

• 必須宣告支援 android.hardware.fingerprint 功能。
• 必須按照 Android SDK 說明文件所述，完整實作對應的 API。
• 錯誤接受率不得高於 0.002%。
• 強烈建議您將誤拒率控制在 10% 以下 (以裝置測量為準)
• 強烈建議延遲時間低於 1 秒，以註冊 1 指紋的情況為例，從觸碰指紋感應器到螢幕解鎖的時間。
• 在指紋驗證失敗五次後，必須限制嘗試次數，至少 30 秒。
• 必須具備硬體支援的 KeyStore 實作項目，並在受信任的執行環境 (TEE) 中執行指紋比對，或是在具有與 TEE 安全通道的晶片上執行。
• 必須將所有可辨識的指紋資料加密，並透過密碼學驗證，以便在 Android 開放原始碼專案網站的實作指南中所述，在受信任的執行環境 (TEE) 之外取得、讀取或變更這些資料。
• 必須先建立信任鏈，才能新增指紋，方法是要求使用者確認現有憑證或新增 TEE 保護的全新裝置憑證 (PIN 碼/圖案/密碼)；Android 開放原始碼專案實作項目會在架構中提供相關機制。
• 請務必不要讓第三方應用程式區分個別指紋。
• 必須遵守 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT 標記。
• 從 Android 6.0 以下版本升級時，必須安全地遷移指紋資料，以符合上述規定或移除資料。
• 應使用 Android 開放原始碼計畫提供的 Android 指紋圖示。

7.3.11. 僅限 Android Automotive 感應器

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

7.3.11.1. 目前齒輪

Android Automotive 實作項目應提供目前的齒輪，做為 SENSOR_TYPE_GEAR。

7.3.11.2. 日間/夜間模式

Android Automotive 實作項目必須支援以 SENSOR_TYPE_NIGHT 定義的日間/夜間模式。這個標記的值必須與資訊主頁的晝夜模式一致，且應根據環境光感應器輸入的資訊。基礎環境光度感應器可能與光度計相同。

7.3.11.3. 駕駛狀態

Android Automotive 實作項目必須支援以 SENSOR_TYPE_DRIVING_STATUS 定義的行車狀態，並在車輛完全停車時，將預設值設為 DRIVE_STATUS_UNRESTRICTED。裝置製造商有責任根據產品運送市場適用的所有法律和規範，設定 SENSOR_TYPE_DRIVING_STATUS。

7.3.11.4. 車輪轉速

Android Automotive 實作項目必須提供車輛速度，定義為 SENSOR_TYPE_CAR_SPEED。

7.3.12. 姿勢感應器

裝置實作可能會支援具有 6 個自由度的姿勢感應器。建議 Android 手持裝置支援這項感應器。如果裝置實作支援 6 度自由度的姿勢感應器，則會：

• 必須實作並回報 TYPE_POSE_6DOF 感應器。
• 必須比單獨旋轉向量更準確。

7.4. 資料連線

7.4.1. 電話

Android API 和本文所用的「電話」一詞，專指透過 GSM 或 CDMA 網路撥打語音電話和傳送簡訊的硬體。雖然這些語音通話可能會或不會使用封包交換，但在 Android 的用途上，這些通話與任何可能使用相同網路實作的資料連線是獨立的。換句話說，Android 的「telephony」功能和 API 專指語音通話和簡訊。舉例來說，如果裝置無法撥打電話或傳送/接收簡訊，則無論是否使用行動網路進行資料連線，都不得回報 android.hardware.telephony 功能或任何子功能。

Android 可用於不含電話硬體的裝置。也就是說，Android 可與非手機裝置相容。不過，如果裝置實作內容包含 GSM 或 CDMA 電話服務，則必須完整支援該技術的 API。不含電話硬體的裝置實作項目必須將完整 API 實作為無作業。

7.4.1.1. 電話號碼封鎖相容性

Android 電信裝置實作方式必須支援封鎖號碼，並符合下列規定：

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

7.4.2. IEEE 802.11 (Wi-Fi)

所有 Android 裝置實作都應支援一或多種 802.11 形式。如果裝置實作內容確實支援 802.11，並將功能公開給第三方應用程式，則必須實作對應的 Android API，並符合下列條件：

• 必須回報硬體功能旗標 android.hardware.wifi。
• 必須按照 SDK 說明文件所述，實作多播 API。
• 必須支援多點傳送 DNS (mDNS)，且不得在任何作業期間過濾 mDNS 封包 (224.0.0.251)，包括：
  • 即使螢幕未處於啟用狀態也一樣。
  • 對於 Android TV 裝置實作，即使處於待機電源狀態也一樣。

7.4.2.1. Wi-Fi Direct

裝置實作應支援 Wi-Fi Direct (Wi-Fi 點對點)。如果裝置實作內容確實支援 Wi-Fi Direct，則必須實作 SDK 說明文件中所述的對應 Android API。如果裝置實作項目支援 Wi-Fi Direct，則會：

• 必須回報硬體功能 android.hardware.wifi.direct。
• 必須支援一般 Wi-Fi 作業。
• 應支援同時執行 Wi-Fi 和 Wi-Fi Direct 作業。

7.4.2.2. Wi-Fi 隧道直接連結設定

裝置實作項目應支援 Wi-Fi 隧道直接連結設定 (TDLS)，如 Android SDK 說明文件所述。如果裝置實作內容支援 TDLS，且 WiFiManager API 已啟用 TDLS，則裝置會：

• 只有在可行且有益的情況下，才應使用 TDLS。
• 應具備一些啟發法，且在效能可能比透過 Wi-Fi 存取點更差時，不要使用 TDLS。

7.4.3. 藍牙

支援 android.hardware.vr.high_performance 功能的裝置實作必須支援藍牙 4.2 和藍牙低功耗資料長度擴充功能。

Android 支援藍牙和藍牙低功耗。支援藍牙和藍牙低功耗的裝置實作項目必須宣告相關的平台功能 (分別為 android.hardware.bluetooth 和 android.hardware.bluetooth_le)，並實作平台 API。裝置實作項目應根據裝置需求，實作相關的藍牙設定檔，例如 A2DP、AVRCP、OBEX 等。

Android Automotive 實作應支援訊息存取設定檔 (MAP)。Android Automotive 實作項目必須支援下列藍牙設定檔：

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

裝置實作項目，包括支援藍牙低功耗：

• 必須宣告硬體功能 android.hardware.bluetooth_le。
• 必須啟用 GATT (通用屬性設定檔) 的藍牙 API，如 SDK 說明文件和 android.bluetooth 所述。
• 強烈建議您實作可解析私人地址 (RPA) 逾時機制，逾時時間不得超過 15 分鐘，並在逾時時輪替地址，以保護使用者隱私。
• 實作 ScanFilter API 時，應支援將篩選器邏輯卸載至藍牙晶片組，並在透過 android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() 方法查詢時，回報正確的值，指出篩選器邏輯實作的位置。
• 應支援將批次掃描卸載至藍牙晶片組，但如果不支援，則在透過 android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported() 方法查詢時，必須回報「false」。
• 應支援至少 4 個廣告位元的多重廣告，但如果不支援，則在透過 android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() 方法查詢時，必須回報「false」。

7.4.4. 近距離無線通訊

裝置實作應包含近距離無線通訊 (NFC) 的收發器和相關硬體。如果裝置實作確實包含 NFC 硬體，且計畫開放給第三方應用程式使用，則必須符合下列條件：

• 必須透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
• 必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：
  • 必須能夠透過下列 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 (由 NFC Forum 定義)
  • 強烈建議您能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息和原始資料。請注意，雖然下列 NFC 標準列為「強烈建議」，但未來版本的相容性定義預計會將這些標準改為「必須」。這些標準在本版本中為選用標準，但在日後版本中將為必要標準。強烈建議目前和新款搭載此 Android 版本的裝置，現在就符合這些要求，以便日後升級至平台新版本。
    • NfcV (ISO 15693)
  • 應可讀取 Thinfilm NFC Barcode 產品的條碼和網址 (如果已編碼)。
  • 必須能夠透過下列對等端標準和通訊協定傳送及接收資料：
    • ISO 18092
    • LLCP 1.2 (由 NFC 論壇定義)
    • SDP 1.0 (由 NFC 論壇定義)
    • NDEF 推送通訊協定
    • SNEP 1.0 (由 NFC Forum 定義)
  • 必須支援 Android Beam。
  • 必須實作 SNEP 預設伺服器。預設 SNEP 伺服器收到的有效 NDEF 訊息，必須使用 android.nfc.ACTION_NDEF_DISCOVERED 意圖，傳送至應用程式。在設定中停用 Android Beam 時，請務必不要停用傳送傳入 NDEF 訊息的功能。
  • 必須遵循 android.settings.NFCSHARING_SETTINGS 意圖，才能顯示 NFC 分享設定。
  • 必須實作 NPP 伺服器。NPP 伺服器收到的訊息必須以與 SNEP 預設伺服器相同的方式處理。
  • 必須實作 SNEP 用戶端，並在啟用 Android Beam 時嘗試將外寄 P2P NDEF 傳送至預設 SNEP 伺服器。如果找不到預設的 SNEP 伺服器，用戶端就必須嘗試傳送至 NPP 伺服器。
  • 必須允許前景活動使用 android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback 和 android.nfc.NfcAdapter.enableForegroundNdefPush 設定傳出 P2P NDEF 訊息。
  • 在傳送外向 P2P NDEF 訊息前，應使用手勢或畫面上的確認動作 (例如「輕觸即可傳送」)。
  • 應預設啟用 Android Beam，且必須能夠使用 Android Beam 傳送及接收資料，即使已開啟其他專屬 NFC P2p 模式也一樣。
  • 當裝置支援藍牙物件推送設定檔時，必須支援 NFC 連線轉移至藍牙。使用 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 要求，以便執行連線移交作業。
  • 在 NFC 探索模式下，必須輪詢所有支援的技術。
  • 裝置喚醒、螢幕處於開啟狀態，且鎖定畫面已解鎖時，應處於 NFC 偵測模式。

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

Android 支援 NFC 主機卡模擬 (HCE) 模式。如果裝置實作包含支援 HCE (適用於 NfcA 和/或 NfcB) 的 NFC 控制器晶片組，且支援應用程式 ID (AID) 路由，則該裝置會：

• 必須回報 android.hardware.nfc.hce 功能常數。
• 必須支援 Android SDK 中定義的 NFC HCE API。

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

• 必須回報 android.hardware.nfc.hcef 功能常數。
• 必須實作 Android SDK 中定義的 NfcF 卡模擬 API。

此外，裝置實作可能會針對下列 MIFARE 技術提供讀取器/寫入器支援。

• MIFARE Classic
• MIFARE Ultralight
• MIFARE Classic 上的 NDEF

請注意，Android 包含這些 MIFARE 類型的 API。如果裝置實作在讀取/寫入者角色中支援 MIFARE，則會：

• 必須依照 Android SDK 說明文件實作對應的 Android API。
• 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這並非標準 Android 功能，因此不會顯示為 android.content.pm.PackageManager 類別中的常數。
• 除非也實作一般 NFC 支援功能 (如本節所述)，否則絕對不得實作對應的 Android API，也不得回報 com.nxp.mifare 功能。

如果裝置實作不包含 NFC 硬體，則絕對不可透過 android.content.pm.PackageManager.hasSystemFeature() 方法宣告 android.hardware.nfc 功能，且必須將 Android NFC API 實作為無操作。

由於 android.nfc.NdefMessage 和 android.nfc.NdefRecord 類別代表不依附通訊協定的資料表示格式，因此即使裝置實作不支援 NFC 或宣告 android.hardware.nfc 功能，也必須實作這些 API。

7.4.5. 最低網路功能

裝置實作項目必須支援一或多種資料網路連線。具體來說，裝置實作必須支援至少一種資料標準，且該標準的傳輸速率必須達到 200Kbit/sec 以上。符合這項規定的技術包括 EDGE、HSPA、EV-DO、802.11g、乙太網路、藍牙 PAN 等。

如果裝置實作使用實體網路標準 (例如乙太網路) 做為主要資料連線，則應同時支援至少一種常見的無線資料標準，例如 802.11 (Wi-Fi)。

裝置可能會實作多種形式的資料連線。

裝置必須包含 IPv6 網路堆疊，並支援使用受管理的 API (例如 java.net.Socket 和 java.net.URLConnection) 以及原生 API (例如 AF_INET6 Sockets) 的 IPv6 通訊。所需的 IPv6 支援層級取決於網路類型，如下所示：

• 支援 Wi-Fi 網路的裝置必須支援雙重堆疊和 Wi-Fi 上的 IPv6 專用作業。
• 支援乙太網路的裝置必須支援乙太網路上的雙堆疊作業。
• 支援行動數據的裝置應支援行動數據的 IPv6 作業 (僅限 IPv6 和可能的雙重堆疊)。
• 裝置同時連上多個網路 (例如 Wi-Fi 和行動數據)，則必須同時符合連線至的每個網路的這些規定。

必須預設啟用 IPv6。

為了確保 IPv6 通訊與 IPv4 一樣可靠，即使螢幕處於非活動狀態，也絕對不能捨棄傳送至裝置的單播 IPv6 封包。如有必要節省電力，則可在硬體或韌體中限制重複的多播 IPv6 封包 (例如重複的相同路由器廣告) 的傳送速率。在這種情況下，速率限制絕對不會導致裝置在任何符合 IPv6 規格的網路上，因 RA 生命週期至少為 180 秒而失去 IPv6 連線。

休眠模式下必須維持 IPv6 連線。

7.4.6. 同步處理設定

裝置實作項目必須預設啟用主控台自動同步設定，以便 getMasterSyncAutomatically() 方法傳回「true」。

7.4.7. 數據節省模式

強烈建議使用計量付費網路的裝置實作方式提供數據節省模式。

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

• 必須支援 ConnectivityManager 類別中的所有 API，如 SDK 說明文件所述

• 您必須在設定中提供使用者介面，讓使用者將應用程式加入或移除許可清單。

相反地，如果裝置實作項目未提供數據節省模式，則會發生以下情況：

• 必須針對 ConnectivityManager.getRestrictBackgroundStatus() 傳回 RESTRICT_BACKGROUND_STATUS_DISABLED 值

• 不得廣播 ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

• 必須有一個可處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖的活動，但可將其實作為無操作。

7.5. 攝影機

裝置實作項目應包含後置鏡頭，並可包含前置鏡頭。後置鏡頭是位於裝置螢幕對側的鏡頭，也就是像傳統相機一樣，拍攝裝置遠端的場景。前置鏡頭是指位於裝置螢幕同一側的鏡頭，也就是通常用於拍攝使用者影像的鏡頭，例如視訊會議和類似應用程式。

如果裝置實作包含至少一個相機，應用程式必須能夠同時配置 3 個 RGBA_8888 點陣圖，大小與裝置上最高解析度相機感應器產生的圖片相同，同時相機必須處於開啟狀態，以便進行基本預覽和靜態影像拍攝。

7.5.1. 後置鏡頭

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

• 必須回報功能旗標 android.hardware.camera 和 android.hardware.camera.any。
• 解析度必須至少為 2000 萬像素。
• 應在相機驅動程式中實作硬體自動對焦或軟體自動對焦功能 (對應用程式軟體而言是透明的)。
• 可能會配備固定焦或 EDOF (擴大景深) 硬體。
• 可包含閃光效果。如果相機包含閃光燈，在相機預覽畫面註冊 android.hardware.Camera.PreviewCallback 例項時，閃光燈不得亮起，除非應用程式明確啟用閃光燈，也就是啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性。請注意，這項限制不適用於裝置內建的系統相機應用程式，只適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2. 前置鏡頭

裝置實作可能包含前置鏡頭。如果裝置實作方式包含至少一個前置鏡頭，則會：

• 必須回報功能旗標 android.hardware.camera.any 和 android.hardware.camera.front。
• 解析度必須至少為 VGA (640x480 像素)。
• 請勿將前置鏡頭設為 Camera API 的預設值。Android 的相機 API 提供前置鏡頭的專屬支援，裝置實作不得將 API 設為將前置鏡頭視為預設後置鏡頭，即使它是裝置上唯一的相機也是如此。
• 可包含第 7.5.1 節所述的後置鏡頭功能 (例如自動對焦、閃光燈等)。
• 應用程式在 CameraPreview 中顯示的串流，必須水平反射 (即鏡像)，如下所示：
  • 如果裝置實作功能可由使用者旋轉 (例如透過加速計自動旋轉，或透過使用者輸入手動旋轉)，攝影機預覽畫面必須相對於裝置目前的方向水平鏡像。
  • 如果目前的應用程式已透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法，明確要求旋轉相機螢幕，則相機預覽畫面必須根據應用程式指定的方向水平鏡像。
  • 否則，預覽畫面必須沿著裝置的預設水平軸鏡射。
• 必須以與攝影機預覽圖像串相同的方式，鏡像顯示後視鏡顯示的圖像。如果裝置實作不支援 PostView，這項規定顯然不適用。
• 請勿將最終擷取的靜態影像或影片串流鏡像傳回至應用程式回呼，或儲存至媒體儲存空間。

7.5.3. 外接鏡頭

裝置實作可能會支援外部相機，但不一定會一直連線。如果裝置支援外接攝影機，則必須符合下列條件：

• 必須宣告平台功能旗標 android.hardware.camera.external 和 android.hardware camera.any。
• 可支援多部攝影機。
• 如果外接攝影機是透過 USB 連接埠連線，則必須支援 USB 視訊類別 (UVC 1.0 以上)。
• 應支援 MJPEG 等影片壓縮功能，以便傳輸高品質未編碼的串流 (即原始或獨立壓縮的圖片串流)。
• 可支援以攝影機為基礎的影片編碼。如果支援，裝置實作必須能夠同時存取未編碼 / MJPEG 串流 (QVGA 或更高解析度)。

7.5.4. Camera API 行為

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

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

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

• 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則裝置必須使用 android.hardware.PixelFormat.YCbCr_420_SP 提供給應用程式回呼的預覽資料。
• 如果應用程式註冊 android.hardware.Camera.PreviewCallback 例項，且系統在預覽格式為 YCbCr_420_SP 時呼叫 onPreviewFrame() 方法，則傳遞至 onPreviewFrame() 的 byte[] 中的資料必須採用 NV21 編碼格式。也就是說，預設值必須是 NV21。
• 針對 android.hardware.Camera，裝置實作必須支援 YV12 格式 (由 android.graphics.ImageFormat.YV12 常數表示)，以便顯示前置和後置鏡頭的相機預覽畫面。(硬體影片編碼器和相機可以使用任何原生像素格式，但裝置實作必須支援轉換為 YV12)。
• 針對 android.hardware.camera2，裝置實作必須支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式，並透過 android.media.ImageReader API 輸出。

無論裝置是否包含硬體自動對焦或其他功能，裝置實作方式仍須實作 Android SDK 說明文件中包含的完整 Camera API。舉例來說，缺少自動對焦功能的相機仍必須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 例項 (即使這與非自動對焦相機無關)。請注意，這項做法也適用於前置鏡頭；舉例來說，即使大多數前置鏡頭不支援自動對焦，API 回呼仍必須按照上述方式「偽造」。

如果底層硬體支援這項功能，裝置實作必須辨識並遵循 android.hardware.Camera.Parameters 類別中定義為常數的每個參數名稱。如果裝置硬體不支援某項功能，API 必須按照說明運作。相反地，裝置實作不得認可或識別傳遞至 android.hardware.Camera.setParameters() 方法的字串常數，除非這些常數已在 android.hardware.Camera.Parameters 中記錄為常數。也就是說，如果硬體允許，裝置實作必須支援所有標準相機參數，且不得支援自訂相機參數類型。舉例來說，如果裝置實作項目支援使用高動態範圍 (HDR) 成像技術拍攝相片，就必須支援相機參數 Camera.SCENE_MODE_HDR。

由於並非所有裝置實作都能完全支援 android.hardware.camera2 API 的所有功能，因此裝置實作必須使用 Android SDK 所述的 android.info.supportedHardwareLevel 屬性回報適當的支援層級，並回報適當的架構功能旗標。

裝置實作項目也必須透過 android.request.availableCapabilities 屬性宣告 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標；如果任何已連結的相機裝置支援該功能，裝置就必須定義功能旗標。

每當相機拍攝新相片，且相片項目已新增至媒體儲存空間時，裝置實作方式都必須廣播 Camera.ACTION_NEW_PICTURE 意圖。

每當相機錄製新影片，且相片項目已新增至媒體儲存庫時，裝置實作項目就必須廣播 Camera.ACTION_NEW_VIDEO 意圖。

7.5.5. 相機方向

如有前置和後置鏡頭，兩者的方向都必須經過調整，確保相機的長邊與螢幕的長邊對齊。也就是說，當裝置以橫向方向握持時，相機就必須以橫向方向拍攝影像。無論裝置的自然方向為何，這項設定都適用，也就是適用於以橫向為主要方向的裝置，以及以直向為主要方向的裝置。

7.6. 記憶體與儲存空間

7.6.1. 記憶體和儲存空間需求

裝置實作項目可供核心和使用者空間使用的記憶體，至少必須等於或大於下表指定的最低值。(如要瞭解螢幕大小和密度的定義，請參閱 7.1.1 節)。

密度和螢幕大小	32 位元裝置	64 位元裝置
Android Watch 裝置 (由於螢幕較小)	416MB	不適用
在小型/一般螢幕上，解析度為 280dpi 以下 大型螢幕的 mdpi 或更低 超大螢幕的 ldpi 或更低	512MB	816MB
小型/一般螢幕：xhdpi 以上 大型螢幕須為 hdpi 或更高 超大螢幕的 mdpi 或更高	608MB	944MB
在小型/一般螢幕上，解析度須達 400 dpi 以上 大型螢幕的 xhdpi 或更高 在超大螢幕上使用 tvdpi 或更高	896MB	1280MB
在小螢幕/一般螢幕上，顯示解析度須達 560 dpi 以上 大型螢幕的解析度須高於 400dpi xhdpi 或更高 (超大螢幕)	1344MB	1824MB

最小記憶體值必須是除了任何記憶體空間之外，專門用於硬體元件 (例如無線電、影片等) 的值，這些值不在核心控制之下。

除非是 Android Watch，否則如果裝置實作可供核心和使用者空間使用的記憶體少於 512 MB，則必須針對 ActivityManager.isLowRamDevice() 傳回「true」值。

Android TV 裝置必須至少有 4 GB，其他裝置實作也必須至少有 3 GB 的非揮發性儲存空間，用於應用程式的私人資料。也就是說，Android TV 裝置的 /data 分割區必須至少有 4 GB，其他裝置實作項目的 /data 分割區則至少有 3 GB。對於執行 Android 的裝置實作，強烈建議至少要有 4 GB 的非揮發性儲存空間，用於應用程式私人資料，這樣才能升級至未來的平台版本。

Android API 包含 Download Manager，應用程式可使用這項工具下載資料檔案。下載管理員的裝置實作方式必須能夠將大小至少 100 MB 的個別檔案下載至預設的「快取」位置。

7.6.2. 應用程式共用儲存空間

裝置實作項目必須為應用程式提供共用儲存空間，這也常被稱為「共用外部儲存空間」。

裝置實作項目必須預設掛載共用儲存空間，以便「開箱即用」。如果共用儲存空間未掛載至 Linux 路徑 /sdcard，則裝置必須包含從 /sdcard 到實際掛載點的 Linux 符號連結。

裝置實作可能會提供可供使用者存取的可卸除式儲存空間硬體，例如 Secure Digital (SD) 卡插槽。如果這個時段用於滿足共用儲存空間需求，裝置實作方式如下：

• 必須實作 Toast 或彈出式使用者介面，在沒有 SD 卡時警告使用者。
• 必須隨附 FAT 格式的 1 GB 以上 SD 卡，或是在包裝盒和其他購買時提供的資料中顯示 SD 卡須另外購買。
• 必須根據預設掛載 SD 卡。

或者，裝置實作項目可以將內部 (不可移除) 儲存空間分配給應用程式，這類應用程式會納入上游 Android 開放原始碼專案；裝置實作項目應使用這項設定和軟體實作項目。如果裝置實作使用內部 (不可移除) 儲存空間來滿足共用儲存空間需求，而該儲存空間可能會與應用程式私人資料共用空間，則該儲存空間必須至少有 1 GB，且掛載至 /sdcard (如果掛載至其他位置，則 /sdcard 必須是指向實體位置的符號連結)。

裝置實作項目必須在這個共用儲存空間上強制執行 android.permission.WRITE_EXTERNAL_STORAGE 權限。否則，任何取得該權限的應用程式都必須能寫入共用儲存空間。

裝置實作內容如果包含多個共用儲存空間路徑 (例如同時提供 SD 卡插槽和共用內部儲存空間)，則必須只允許具備 WRITE_EXTERNAL_STORAGE 權限的預先安裝和特權 Android 應用程式寫入次要外部儲存空間，除非是寫入其專屬套件目錄，或在觸發 ACTION_OPEN_DOCUMENT_TREE 意圖時傳回的 URI 中。

不過，裝置實作項目應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，公開顯示兩個儲存路徑的內容。

無論使用的共用儲存空間形式為何，如果裝置實作項目有支援 USB 周邊裝置模式的 USB 連接埠，就必須提供某種機制，以便從主機電腦存取共用儲存空間的內容。裝置實作可能會使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定來滿足這項要求。如果裝置實作支援媒體傳輸通訊協定，則會：

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

7.6.3. 合併儲存空間

如果可移除儲存裝置的連接埠位於長期穩定的位置 (例如電池盒或其他保護蓋內)，強烈建議裝置實作項目實作可採用的儲存空間。

電視等裝置實作可能會透過 USB 連接埠啟用，因為這類裝置應為靜態裝置，而非行動裝置。不過，對於其他本身屬於行動裝置的裝置實作項目，強烈建議您在長期穩定的位置實作可採用的儲存空間，因為不小心中斷連線可能會導致資料遺失/損毀。

7.7. USB

裝置實作應支援 USB 周邊裝置模式，也應支援 USB 主機模式。

7.7.1. USB 周邊裝置模式

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

• 連接埠必須可連接至具有標準型 A 或型 C USB 連接埠的 USB 主機。
• 連接埠應使用 micro-B、micro-AB 或 Type-C USB 板型規格。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
• 連接埠應位於裝置底部 (依照自然方向)，或為所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，以便在裝置以連接埠朝下的方式顯示時，正確繪製畫面。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
• 必須允許連接 Android 裝置的 USB 主機，透過 USB 大量儲存裝置或媒體傳輸通訊協定存取共用儲存空間的內容。
• 應實作 Android Open Accessory (AOA) API 和規範，如 Android SDK 說明文件所述。如果是 Android 手持裝置，則必須實作 AOA API。實作 AOA 規格的裝置：
  • 必須宣告支援硬體功能 android.hardware.usb.accessory。
  • 必須按照 Android SDK 說明文件所述，導入 USB 音訊類別。
  • USB 大量儲存空間類別的 USB 大量儲存空間介面說明 iInterface 字串結尾處，一律須包含「android」字串
• 應實作支援功能，在 HS 嗶嗶聲和流量期間汲取 1.5 A 電流，如 USB 電池充電規格第 1.2 版所述。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
• Type-C 裝置必須依照 Type-C 電阻標準偵測 1.5A 和 3.0A 充電器，且必須偵測廣告中的變更。
• 強烈建議 Type-C 裝置也支援 USB 主機模式，以便在資料和電力角色互換時支援 Power Delivery。
• Type-C 裝置應支援高電壓充電的 Power Delivery 和顯示輸出等其他模式。
• USB 標準裝置描述元中的 iSerialNumber 值必須等於 android.os.Build.SERIAL 的值。
• 強烈建議 Type-C 裝置不支援會修改 Vbus 電壓超過預設等級的專屬充電方法，或變更匯流/來源角色，因為這可能會導致與支援標準 USB 電源供應方法的充電器或裝置發生互通性問題。雖然這項做法被列為「強烈建議」，但在日後的 Android 版本中，我們可能會要求所有 Type-C 裝置支援與標準 Type-C 充電器的完整互通性。

7.7.2. USB 主機模式

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

• 如果裝置實作支援 USB 3.1，則應使用 Type-C USB 連接埠。
• 可使用非標準的連接埠板型規格，但如果使用這種規格，必須隨附一或多條傳輸線，將連接埠轉換為標準的 Type-A 或 Type-C USB 連接埠。
• 可使用 micro-AB USB 連接埠，但如果使用這種連接埠，則應隨附可將連接埠轉換為標準型 A 或型 C USB 連接埠的傳輸線。
• 建議您務必導入 USB 音訊類別，詳情請參閱 Android SDK 說明文件。
• 必須實作 Android USB 主機 API，如 Android SDK 說明文件所述，並且必須宣告支援硬體功能 android.hardware.usb.host。
• 應在主機模式下支援裝置充電；宣傳的來源電流至少為 1.5A，如 [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) 所述，適用於 USB Type-C 連接器；或使用充電下游連接埠(CDP) 輸出電流範圍，如 USB Battery Charging specifications, revision 1.2 所述，適用於 Micro-AB 連接器。
• 強烈建議 USB Type-C 裝置支援 DisplayPort，且應支援 USB 超高速資料傳輸速率，並強烈建議支援 Power Delivery，以便切換資料和電力角色。
• 設有任何 type-A 或 type-AB 連接埠的裝置，不得隨附從此連接埠轉換為 type-C 插座的轉接器。
• 如果支援儲存空間存取架構 (SAF)，則必須辨識任何遠端連線的 MTP (媒體傳輸通訊協定) 裝置，並透過 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT 意圖存取其內容。
• 如果使用 Type-C USB 連接埠並支援周邊模式，則必須實作 USB Type-C 規格 (第 4.5.1.3.3 節) 定義的雙角色連接埠功能。
• 如果支援雙角色連接埠功能，應實作最適合裝置板型的 Try.* 模型。舉例來說，手持裝置應實作 Try.SNK 模型。

7.8. 音訊

7.8.1. 麥克風

裝置實作可能會省略麥克風。不過，如果裝置實作省略麥克風，則不得回報 android.hardware.microphone 功能常數，且必須依據第 7 節，至少以無操作方式實作音訊錄音 API。相反地，如果裝置實作方式確實有麥克風，則：

• 必須回報 android.hardware.microphone 功能常數。
• 必須符合第 5.4 節的音訊錄音規定。
• 必須符合第 5.6 節的音訊延遲要求。
• 強烈建議您支援近超音錄影功能，詳情請參閱第 7.8.3 節。

7.8.2. 音訊輸出

裝置實作方式包括喇叭，或音訊輸出周邊裝置的音訊/多媒體輸出端口，例如耳機或外接喇叭：

• 必須回報 android.hardware.audio.output 功能常數。
• 必須符合第 5.5 節的音訊播放規定。
• 必須符合第 5.6 節的音訊延遲要求。
• 強烈建議您支援近超音播放功能，詳情請參閱第 7.8.3 節。

相反地，如果裝置實作項目不包含喇叭或音訊輸出埠，則不得回報 android.hardware.audio 輸出功能，且至少必須將音訊輸出相關 API 實作為無操作。

Android Watch 裝置實作項目可以 (但不應) 有音訊輸出，但其他類型的 Android 裝置實作項目則必須有音訊輸出，並宣告 android.hardware.audio.output。

7.8.2.1. 類比音訊埠

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

• 必須支援音訊播放至立體聲耳機和有麥克風的立體聲耳機，並且應支援從有麥克風的立體聲耳機錄製音訊。
• 必須支援使用 CTIA 針腳排列的 TRRS 音訊插頭，並建議支援使用 OMTP 針腳排列的音訊插頭。
• 如果裝置實作支援麥克風，則必須支援偵測已插入的音訊配件麥克風，並廣播 android.intent.action.HEADSET_PLUG，其中額外值麥克風設為 1。
• 必須支援偵測功能，並將音訊插頭上麥克風和接地導體之間的等效阻抗，對應至下列 3 個範圍的按鍵代碼：
  • 70 歐姆以下：KEYCODE_HEADSETHOOK
  • 210-290 Ohm：KEYCODE_VOLUME_UP
  • 360-680 歐姆：KEYCODE_VOLUME_DOWN
• 強烈建議您偵測並對應音訊插頭上麥克風和接地導體之間等效阻抗的下列範圍，並將其對應至按鍵代碼：
  • 110-180 歐姆：KEYCODE_VOICE_ASSIST
• 插頭插入時，必須觸發 ACTION_HEADSET_PLUG，但只有在插頭上的所有接觸點都與插孔上的相關區段接觸時才會觸發。
• 必須能夠在 32 歐姆的喇叭阻抗上，驅動至少 150mV ± 10% 的輸出電壓。
• 麥克風偏壓電壓必須介於 1.8V 至 2.9V 之間。

7.8.3. 近場超音波

近超音波音訊是指 18.5 kHz 到 20 kHz 頻帶。裝置實作項目必須透過 AudioManager.getProperty API 正確回報支援超音波音訊功能，如下所示：

• 如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 為「true」，則 VOICE_RECOGNITION 和 UNPROCESSED 音訊來源必須符合下列規定：
  • 麥克風在 18.5 kHz 至 20 kHz 頻帶的平均功率響應，必須比 2 kHz 的響應低 15 dB 以下。
  • 麥克風在 19 kHz 音調 (-26 dBFS) 的情況下，超過 18.5 kHz 至 20 kHz 的未加權訊噪比不得低於 50 dB。
• 如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」，則揚聲器在 18.5 kHz 至 20 kHz 的平均回應，必須比 2 kHz 的回應低 40 dB。

7.9. 虛擬實境

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

7.9.1. 虛擬實境模式

支援 VR 應用程式模式的 Android 手持裝置實作方式，會處理通知的立體渲染，並在 VR 應用程式獲得使用者焦點時停用單眼系統 UI 元件，因此必須宣告 android.software.vr.mode 功能。宣告這項功能的裝置必須包含實作 android.service.vr.VrListenerService 的應用程式，且 VR 應用程式可透過 android.app.Activity#setVrModeEnabled 啟用該應用程式。

7.9.2. 虛擬實境高效能

Android 手持裝置實作項目必須透過 android.hardware.vr.high_performance 功能旗標，識別支援長時間使用高效能虛擬實境的功能，並符合下列規定。

• 裝置實作項目必須至少有 2 個實體核心。
• 裝置實作項目必須宣告 android.software.vr.mode 功能。
• 裝置實作可能會為前景應用程式提供專屬核心，並支援 Process.getExclusiveCores API，以便傳回頂層前景應用程式專屬的 CPU 核心數。如果支援專屬核心，則核心不得允許任何其他使用者空間程序在其上執行 (應用程式使用的裝置驅動程式除外)，但可視需要允許某些核心程序執行。
• 裝置實作項目必須支援持續效能模式。
• 裝置實作項目必須支援 OpenGL ES 3.2。
• 裝置實作項目必須支援 Vulkan 硬體層級 0，且應支援 Vulkan 硬體層級 1。
• 裝置實作項目必須實作 EGL_KHR_mutable_render_buffer 和 EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_create_native_client_buffer、EGL_KHR_fence_sync 和 EGL_KHR_wait_sync，才能用於共用緩衝區模式，並在可用的 EGL 擴充功能清單中公開這些擴充功能。
• GPU 和螢幕必須能夠同步存取共用前端緩衝區，以便以 60 fps 的速度，使用兩個轉譯內容顯示交替眼睛渲染的 VR 內容，且不會出現明顯的撕裂現象。
• 裝置實作項目必須實作 EGL_IMG_context_priority，並在可用的 EGL 擴充功能清單中公開該擴充功能。
• 裝置實作項目必須實作 GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2 和 GL_OVR_multiview_multisampled_render_to_texture，並在可用的 GL 擴充功能清單中公開這些擴充功能。
• 裝置實作項目必須實作 EGL_EXT_protected_content 和 GL_EXT_protected_textures，才能用於安全性材質影片播放，並在可用的 EGL 和 GL 擴充功能清單中公開這些擴充功能。
• 裝置實作必須支援至少 3840x2160@30fps-40Mbps 的 H.264 解碼 (相當於 1920x1080@30fps-10Mbps 的 4 個例項，或 1920x1080@60fps-20Mbps 的 2 個例項)。
• 裝置實作必須支援 HEVC 和 VP9，且必須能夠解碼至少 1920 x 1080@30 fps - 10 Mbps，並應能夠解碼 3840 x 2160@30 fps - 20 Mbps (相當於 1920 x 1080@30 fps - 5 Mbps 的 4 個例項)。
• 強烈建議裝置實作項目支援 android.hardware.sensor.hifi_sensors 功能，且必須符合 android.hardware.hifi_sensors 的陀螺儀、加速計和磁力計相關要求。
• 裝置實作必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回正確的皮膚溫度值。
• 裝置實作項目必須內建螢幕，且解析度至少為 FullHD(1080p)，強烈建議為 QuadHD (1440p) 以上。
• 螢幕的對角線尺寸必須介於 4.7 到 6 英寸之間。
• 在 VR 模式下，螢幕更新率必須至少為 60 Hz。
• 灰階至灰階、白色至黑色和黑色至白色的顯示延遲時間，必須小於或等於 3 毫秒。
• 螢幕必須支援低延遲模式，延遲時間須低於 5 毫秒，延遲時間定義為像素發光的時間長度。
• 裝置實作方式必須支援藍牙 4.2 和藍牙低功耗 (LE) 資料長度擴充功能 第 7.4.3 節。

8. 效能和電源

部分最低效能和電源標準對使用者體驗至關重要，並會影響開發人員在開發應用程式時的基準假設。Android Watch 裝置應符合，而其他類型的裝置實作則必須符合下列標準。

8.1. 使用者體驗一致性

裝置實作項目必須確保應用程式和遊戲的幀率和回應時間一致，以提供流暢的使用者介面。裝置實作方式必須符合下列規定：

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

8.2. 檔案 I/O 存取效能

裝置實作方式必須確保內部儲存空間檔案存取效能一致，無論讀取或寫入作業皆然。

• 依序寫入。裝置實作必須使用 10 MB 寫入緩衝區，確保 256 MB 檔案的序列寫入效能至少達到 5 MB/s。
• 隨機寫入。裝置實作必須使用 4 KB 寫入緩衝區，確保 256 MB 檔案的隨機寫入效能至少為 0.5 MB/s。
• 依序讀取。裝置實作必須使用 10 MB 寫入緩衝區，確保 256 MB 檔案的序列讀取效能至少為 15 MB/s。
• 隨機讀取。裝置實作必須使用 4 KB 寫入緩衝區，確保 256 MB 檔案的隨機讀取效能至少為 3.5 MB/s。

8.3.省電模式

Android 6.0 推出了應用程式待命和打盹省電模式，可最佳化電池用量。所有在這些模式中豁免的應用程式，都必須向使用者顯示。此外，這些省電模式的觸發、維護、喚醒演算法，以及使用全域系統設定的做法，不得偏離 Android 開放原始碼專案。

除了省電模式之外，Android 裝置實作項目也可能會實作任何或所有 4 種睡眠電源狀態，這由進階設定和電源介面 (ACPI) 定義，但如果實作項目實作 S3 和 S4 電源狀態，則只有在關閉裝置實體部分的蓋子時，才能進入這些狀態。

8.4. 耗電量計算

更準確的耗電量計算和回報功能，可為應用程式開發人員提供誘因和工具，以便最佳化應用程式的耗電模式。因此，裝置實作方式如下：

• 必須能夠追蹤硬體元件的耗電量，並將該耗電量歸因於特定應用程式。具體實作方式：
  • 必須提供個別元件的電源設定檔，定義每個硬體元件的目前耗電量值，以及元件隨時間推移造成的電池耗電量估計值，如 Android 開放原始碼專案網站所述。
  • 所有耗電量值都必須以毫安培小時 (mAh) 為單位回報。
  • 如果無法將硬體元件的耗電量歸因於應用程式，則應歸因於硬體元件本身。
  • 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫透過 uid_cputime 核心模組實作項目滿足這項需求。
• 必須透過 adb shell dumpsys batterystats 指令列，將這項電力使用情形提供給應用程式開發人員。
• 必須遵循 android.intent.action.POWER_USAGE_SUMMARY 意圖，並顯示顯示電源使用的設定選單。

8.5. 一致的效能

高效能長時間執行應用程式的效能可能會大幅波動，原因可能是其他應用程式在背景執行，或是 CPU 因溫度限制而降速。Android 包含程式介面，因此當裝置可用時，前景應用程式可要求系統最佳化資源分配，以因應這類波動。

裝置實作應支援持續效能模式，在透過 Window.setSustainedPerformanceMode() API 方法提出要求時，可為前景最上層應用程式提供一致的效能水準，持續一段較長的時間。裝置實作項目必須透過 PowerManager.isSustainedPerformanceModeSupported() API 方法，準確回報是否支援持續效能模式。

搭載兩個以上 CPU 核心的裝置實作項目應至少提供一個專屬核心，供最上層前景應用程式預留。如果提供，實作項目必須符合下列規定：

• 實作項目必須透過 Process.getExclusiveCores() API 方法，回報前景層級應用程式可保留的專屬核心 ID 編號。
• 裝置實作項目不得允許任何使用者空間程序 (除了應用程式用於在專屬核心上執行的裝置驅動程式)，但可視需要允許某些核心程序執行。

如果裝置實作不支援專屬核心，則必須透過 Process.getExclusiveCores() API 方法傳回空白清單。

9. 安全性模型相容性

裝置實作項目必須實作與 Android 平台安全性模型一致的安全性模型，如 Android 開發人員說明文件中 API 的「安全性和權限參考文件」所定義。裝置實作方式必須支援自行簽署應用程式的安裝作業，且不必向任何第三方/主管機關取得額外權限/憑證。具體來說，相容裝置必須支援下列子節點所述的安全機制。

9.1. 權限

裝置實作項目必須支援 Android 開發人員說明文件中定義的 Android 權限模型。具體來說，實作項目必須強制執行 SDK 說明文件中定義的每項權限，不得省略、變更或忽略任何權限。只要新權限 ID 字串不在 android.* 命名空間中，實作項目就可能會新增額外權限。

protectionLevel 為 'PROTECTION_FLAG_PRIVILEGED' 的權限，必須只授予系統映像檔中允許清單特權路徑(例如 AOSP 實作中的 system/priv-app 路徑) 中預先載入的應用程式。

防護等級為危險的權限是執行階段權限。目標 SDK 版本大於 22 的應用程式會在執行階段要求這些權限。裝置實作方式：

• 必須顯示專屬介面，讓使用者決定是否授予所要求的執行階段權限，並提供介面讓使用者管理執行階段權限。
• 必須有且只有一個實作兩種使用者介面。
• 除非符合下列情況，否則絕對不要向預先安裝的應用程式授予任何執行階段權限：
  • 在應用程式使用前，可以取得使用者的同意聲明
  • 執行階段權限與意圖模式相關聯，預先安裝的應用程式會設為預設處理常式

9.2. UID 和程序隔離

裝置實作項目必須支援 Android 應用程式沙箱模型，在該模型中，每個應用程式都會以獨特的 Unix 風格 UID 執行，並在個別程序中執行。裝置實作必須支援以相同 Linux 使用者 ID 執行多個應用程式，前提是應用程式已正確簽署及建構，如安全性和權限參考資料所定義。

9.3. 檔案系統權限

裝置實作項目必須支援 Android 檔案存取權限模型，如安全性和權限參考資料所定義。

9.4. 替代執行環境

裝置實作項目可能包含執行階段環境，這些環境會使用其他軟體或技術 (而非 Dalvik 可執行格式或原生程式碼) 執行應用程式。不過，這類替代執行環境不得危及 Android 安全性模型或已安裝 Android 應用程式的安全性，如本節所述。

替代執行階段本身必須是 Android 應用程式，並遵循標準的 Android 安全性模型，如第 9 節其他部分所述。

替代執行階段不得授予存取權，以便存取透過 <uses-permission> 機制在執行階段的 AndroidManifest.xml 檔案中未要求的權限所保護的資源。

替代執行階段絕對不允許應用程式使用受限於系統應用程式的 Android 權限保護的功能。

替代執行階段必須遵守 Android 沙箱模型。具體來說，替代執行階段：

• 應透過 PackageManager 將應用程式安裝到個別的 Android 沙箱 (Linux 使用者 ID 等)。
• 可提供單一 Android 沙箱，供使用替代執行階段的所有應用程式共用。
• 使用其他執行階段的安裝應用程式不得重複使用裝置上安裝的任何其他應用程式的沙箱，除非透過共用使用者 ID 和簽署憑證的標準 Android 機制。
• 不得啟動、授予或授予其他 Android 應用程式對應的沙箱存取權。
• 不得以超級使用者 (root) 或任何其他使用者 ID 的任何權限啟動、授予或授予其他應用程式。

替代執行階段的 .apk 檔案可納入裝置實作項目的系統映像檔，但必須使用與裝置實作項目中其他應用程式簽署金鑰不同的金鑰進行簽署。

安裝應用程式時，替代執行階段必須取得使用者同意，才能使用應用程式所需的 Android 權限。如果應用程式需要使用具有對應 Android 權限 (例如相機、GPS 等) 的裝置資源，替代執行階段必須通知使用者，應用程式將可存取該資源。如果執行階段環境未以這種方式記錄應用程式功能，則在安裝使用該執行階段的任何應用程式時，執行階段環境必須列出執行階段本身保有的所有權限。

9.5. 支援多位使用者

Android 支援多位使用者，並提供完整的使用者隔離功能。裝置實作可能會啟用多位使用者，但啟用時必須符合下列與多位使用者支援相關的規定：

• 啟用多使用者支援功能的 Android Automotive 裝置實作項目，必須包含訪客帳戶，讓使用者不必登入，即可使用車輛系統提供的所有功能。
• 如果裝置實作未宣告 android.hardware.telephony 功能旗標，就必須支援受限設定檔，這項功能可讓裝置擁有者管理裝置上的其他使用者和他們的功能。透過受限設定檔，裝置擁有者可以快速設定其他使用者可使用的獨立環境，並在這些環境中管理應用程式的精細限制。
• 相反地，宣告 android.hardware.telephony 功能旗標的裝置實作方式不得支援受限制的設定檔，但必須與 AOSP 的控制項實作方式保持一致，以便啟用 /停用其他使用者存取語音通話和 SMS 的權限。
• 裝置實作項目必須為每位使用者實作與 Android 平台安全模型一致的安全模型，如 API 中的安全性和權限參考文件所定義。
• Android 裝置上的每個使用者例項都必須有獨立且隔離的外部儲存目錄。裝置實作可能會在相同的磁碟區或檔案系統中儲存多位使用者的資料。不過，裝置實作方式必須確保由特定使用者擁有並代為執行的應用程式，無法列出、讀取或寫入任何其他使用者擁有的資料。請注意，可移除式媒體 (例如 SD 卡插槽) 可讓使用者透過主機電腦存取其他使用者的資料。因此，如果使用可卸除式媒體的裝置實作項目啟用多使用者功能，則必須使用僅儲存在系統可存取的可卸除式媒體上的金鑰，加密 SD 卡的內容。由於這會導致主機電腦無法讀取媒體，因此裝置實作必須切換至 MTP 或類似系統，讓主機電腦存取目前使用者的資料。因此，如果裝置實作使用可移動式媒體做為主要外部儲存空間，則可以但不應啟用多使用者功能。

9.6. 付費簡訊警告

Android 支援警告使用者任何傳送的付費簡訊。「付費簡訊」是指傳送至電信業者註冊服務的簡訊，可能會向使用者收費。宣告支援 android.hardware.telephony 的裝置實作項目，必須在傳送簡訊給使用者在裝置中 /data/misc/sms/codes.xml 檔案中定義的規則所識別的號碼之前，先向使用者發出警告。上游 Android 開放原始碼專案提供符合這項需求的實作方式。

9.7. 核心安全性功能

Android 沙箱包含使用 Security-Enhanced Linux (SELinux) 強制存取控制 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全性功能。SELinux 或在 Android 架構下實作的任何其他安全防護功能：

• 必須與現有應用程式相容。
• 在偵測到安全性違規並成功封鎖時，不得顯示使用者介面，但在未封鎖的安全性違規導致成功的漏洞攻擊時，則可以顯示使用者介面。
• 不應由使用者或開發人員設定。

如果任何用於設定政策的 API 會公開給可能影響其他應用程式的應用程式 (例如 Device Administration API)，則 API 不得允許會破壞相容性的設定。

裝置必須實作 SELinux，如果使用 Linux 以外的核心，則必須實作等同的強制存取控制系統。裝置也必須符合下列規定，這些規定可透過上游 Android 開放原始碼計畫中的參考實作項目滿足。

裝置實作方式：

• 必須將 SELinux 設為全域強制執行模式。
• 必須在強制模式中設定所有網域。不允許使用寬鬆模式網域，包括特定裝置/供應商的網域。
• 絕對不可修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 提供的 system/sepolicy 資料夾中現有的 neverallow 規則，且政策必須針對 AOSP SELinux 網域和裝置/供應商專屬網域，與所有現有的 neverallow 規則一併編譯。
• 必須將媒體架構分割為多個程序，以便根據 Android 開放原始碼專案網站所述，為每個程序授予更精確的存取權。

裝置實作應保留上游 Android 開放原始碼計畫的 system/sepolicy 資料夾中提供的預設 SELinux 政策，並只針對自身的裝置專屬設定進一步新增此政策。裝置實作項目必須與上游 Android 開放原始碼計畫相容。

裝置必須實作核心應用程式沙箱機制，以便使用多執行緒程式的可設定政策篩選系統呼叫。上游 Android 開放原始碼計畫透過啟用 seccomp-BPF 與執行緒群組同步處理 (TSYNC) 來滿足這項要求，如 source.android.com 的「核心設定」一節所述。

9.8. 隱私權

如果裝置在系統中實作功能，用於擷取螢幕上顯示的內容和/或錄製裝置上播放的音訊串流，則必須在啟用這項功能並主動擷取/錄製時，持續通知使用者。

如果裝置實作具有機制，會預設透過 Proxy 伺服器或 VPN 閘道轉送網路資料流量 (例如，預先載入已授予 android.permission.CONTROL_VPN 的 VPN 服務)，則裝置實作必須先徵得使用者同意，才能啟用該機制，除非該 VPN 是透過 DevicePolicyManager.setAlwaysOnVpnPackage() 由裝置政策控制器啟用，在這種情況下，使用者不需要提供單獨的同意聲明，但必須收到通知。

裝置實作項目必須隨附使用者新增的空白憑證授權單位 (CA) 存放區，並且必須為系統信任的 CA 存放區預先安裝與上游 Android 開放原始碼專案提供的相同根憑證。

當裝置透過 VPN 路由，或安裝使用者根 CA 時，實作必須顯示警告，指出網路流量可能會受到監控。

如果裝置實作項目的 USB 連接埠支援 USB 周邊模式，則必須先顯示使用者介面要求使用者同意，才能透過 USB 連接埠存取共用儲存空間的內容。

9.9. 資料儲存加密

如果裝置實作支援安全的鎖定畫面 (如第 9.11.1 節所述)，則裝置必須支援應用程式私密資料 (/data 分割區) 的資料儲存加密功能，以及應用程式共用儲存空間分割區 (/sdcard 分割區) (如果是裝置的永久性、不可移除的部分)。

如果裝置實作支援資料儲存加密功能，且進階加密標準 (AES) 加密效能超過 50 MiB/秒，則在使用者完成開箱即用設定體驗時，系統必須預設啟用資料儲存加密功能。如果裝置實作已在舊版 Android 上推出，且預設情況下已停用加密功能，則該裝置無法透過系統軟體更新符合規定，因此可能會獲得豁免。

裝置實作項目應透過實作檔案型加密 (FBE) 滿足上述資料儲存加密要求。

9.9.1. 直接啟動

所有裝置都必須實作 直接啟動模式 API，即使不支援儲存空間加密功能也一樣。特別是，LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED 意圖仍必須廣播，以便向 Direct Boot 感知應用程式傳送信號，指出裝置加密 (DE) 和憑證加密 (CE) 儲存位置可供使用者使用。

9.9.2. 檔案型加密

支援 FBE 的裝置實作方式：

• 必須在廣播 LOCKED_BOOT_COMPLETED 訊息後，在不要求使用者提供憑證的情況下啟動，並允許 Direct Boot 感知應用程式存取裝置加密 (DE) 儲存空間。
• 使用者必須先輸入憑證 (例如密碼、PIN 碼、圖案或指紋) 解鎖裝置，並廣播 ACTION_USER_UNLOCKED 訊息，您才可存取憑證加密 (CE) 儲存空間。裝置實作項目不得提供任何方法，讓使用者在不提供憑證的情況下，解鎖受 CE 保護的儲存空間。
• 必須支援驗證開機程序，並確保 DE 金鑰已以密碼編譯方式繫結至裝置的硬體信任根。
• 必須支援使用 AES 加密檔案內容，且金鑰長度為 256 位元，並以 XTS 模式運作。
• 必須支援使用 AES 加密檔案名稱，且金鑰長度為 256 位元，並採用 CBC-CTS 模式。
• 可支援其他密碼、金鑰長度和模式，用於加密檔案內容和檔案名稱，但預設情況下必須使用強制支援的密碼、金鑰長度和模式。
• 應讓預先載入的重要應用程式 (例如鬧鐘、電話、Messenger) 支援直接啟動模式。

保護 CE 和 DE 儲存區的金鑰：

• 必須透過加密編譯方式，與硬體支援的 Keystore 繫結。CE 金鑰必須繫結至使用者的螢幕鎖定憑證。如果使用者未指定任何螢幕鎖定憑證，則 CE 鍵必須繫結至預設密碼。
• 必須是獨一無二的值，換句話說，任何使用者的 CE 或 DE 金鑰都不能與其他使用者的 CE 或 DE 金鑰相符。

上游 Android 開放原始碼專案提供這項功能的首選實作方式，以 Linux 核心 ext4 加密功能為基礎。

9.9.3. 全磁碟加密

支援全磁碟加密 (FDE) 的裝置實作方式。必須使用 AES，且金鑰長度須為 128 位元 (或更長)，並採用專為儲存空間設計的模式 (例如 AES-XTS、AES-CBC-ESSIV)。加密金鑰在任何時候都不得未經加密就寫入儲存空間。除了在使用中時，加密金鑰應使用 AES 加密，並透過緩慢的拉伸演算法 (例如 PBKDF2 或 scrypt) 拉伸鎖定螢幕憑證。如果使用者未指定鎖定畫面憑證，或已停用密碼加密功能，系統應使用預設密碼包裝加密金鑰。如果裝置提供硬體支援的 KeyStore，密碼延展演算法必須以加密方式繫結至該 KeyStore。加密金鑰絕對不得傳送至裝置外 (即使包裝使用者密碼和/或硬體綁定金鑰也一樣)。上游 Android 開放原始碼專案提供這項功能的偏好實作方式，以 Linux 核心功能 dm-crypt 為基礎。

9.10. 裝置完整性

下列規定可確保裝置完整性狀態的透明度。

裝置實作項目必須透過系統 API 方法 PersistentDataBlockManager.getFlashLockState()，正確回報其系統啟動載入程式狀態是否允許刷新系統映像檔。FLASH_LOCK_UNKNOWN 狀態是為從舊版 Android 升級的裝置實作保留，因為舊版中不存在這個新的系統 API 方法。

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

• 宣告平台功能旗標 android.software.verified_boot。
• 對每個啟動序列執行驗證。
• 從信任根源的不可變更硬體金鑰開始驗證，一直到系統分區。
• 實作每個驗證階段，在執行下一個階段的程式碼前，先檢查下一個階段中所有位元的完整性和真實性。
• 使用驗證演算法，強度與 NIST 目前針對雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 的建議相同。
• 系統驗證失敗時，一律不得允許啟動作業完成，除非使用者同意嘗試啟動，但在這種情況下，不得使用任何未經驗證的儲存體區塊中的資料。
• 除非使用者明確解鎖啟動載入程式，否則不得修改裝置上的已驗證分區。

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

自 Android 6.0 起，如果裝置實作採用的進階加密標準 (AES) 加密效能超過 50 MiB/秒，則必須支援驗證開機程序，以確保裝置完整性。

如果裝置實作已推出，但未在舊版 Android 上支援驗證啟動，則該裝置無法透過系統軟體更新新增這項功能的支援，因此不受此規定約束。

9.11. 金鑰和憑證

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在容器中，並透過 KeyChain API 或 KeyStore API 在加密編譯作業中使用這些金鑰。

所有 Android 裝置實作項目都必須符合下列規定：

• 不應限制可產生的金鑰數量，且至少應允許匯入超過 8,192 個金鑰。
• 鎖定螢幕驗證功能必須設有嘗試次數限制，且必須具備指數型回退演算法。超過 150 次失敗嘗試後，每個嘗試之間的延遲時間必須至少為 24 小時。
• 如果裝置實作功能支援安全的螢幕鎖定功能，則必須使用安全的硬體備份 KeyStore 實作功能，並符合下列規定：
  • 必須有硬體支援的 RSA、AES、ECDSA 和 HMAC 加密演算法，以及 MD5、SHA1、SHA-2 系列雜湊函式，才能正確支援 Android Keystore 系統支援的演算法。
  • 必須在安全硬體中執行螢幕鎖定驗證，且只有在成功驗證後，才能使用與驗證綁定的金鑰。上游 Android 開放原始碼計畫提供可滿足這項需求的 Gatekeeper 硬體抽象層 (HAL)。

請注意，如果裝置實作已在舊版 Android 上推出，則該裝置不必具備硬體支援金鑰庫，除非它宣告需要硬體支援金鑰庫的 android.hardware.fingerprint 功能。

9.11.1. 安全螢幕鎖定畫面

裝置實作可能會新增或修改驗證方法來解鎖螢幕鎖定畫面，但仍須符合下列規定：

• 如果驗證方式是根據已知的密鑰，則必須符合下列所有規定，否則不得視為安全的螢幕鎖定畫面：
  • 輸入內容最短允許長度的熵值必須大於 10 位元。
  • 所有可能輸入內容的最大熵值必須大於 18 位元。
  • 不得取代 AOSP 中實作及提供的任何現有驗證方法 (PIN 碼、圖形、密碼)。
  • 如果裝置政策控制器 (DPC) 應用程式已透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策，且品質常數比 PASSWORD_QUALITY_SOMETHING 更嚴格，則必須停用。
• 如果驗證方法是根據實體符記或位置，則必須符合下列所有規定，否則不得視為安全的鎖定畫面：
  • 必須具備備用機制，以便使用其中一種主要驗證方法，該方法以已知的密鑰為基礎，且符合視為安全螢幕鎖定的條件。
  • 必須停用這項功能，並在裝置政策控制器 (DPC) 應用程式使用 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法設定政策時，只允許主要驗證機制解鎖螢幕，且該方法的品質常數比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格。
• 如果驗證方法是基於生物特徵辨識，則必須符合下列所有要求，否則不得視為安全的螢幕鎖定畫面：
  • 必須具備備用機制，以便使用其中一種主要驗證方法，該方法以已知的密鑰為基礎，且符合視為安全螢幕鎖定的條件。
  • 這項功能必須停用，且只有在裝置政策控制器 (DPC) 應用程式透過呼叫 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) 方法設定 keguard 功能政策時，才允許主要驗證機制解鎖螢幕。
  • 如同第 7.3.10 節所述，其誤認率必須與指紋感應器的誤認率相同或更低，否則必須停用，並在 Device Policy Controller (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策時，只允許主要驗證機制解鎖螢幕，且該政策的品質常數必須比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更嚴格。
• 如果驗證方法無法視為安全的鎖定畫面，則會發生以下情況：
  • KeyguardManager.isKeyguardSecure() 和 KeyguardManager.isDeviceSecure() 方法都必須傳回 false。
  • 如果裝置政策控制器 (DPC) 應用程式已透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策，且品質常數比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格，則必須停用。
  • 請務必不要重設 DevicePolicyManager.setPasswordExpirationTimeout() 設定的密碼到期計時器。
  • 如果應用程式已呼叫 KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)，則不得驗證存取金鑰存放區的權限。
• 如果驗證方法是根據實體符記、位置或生物特徵辨識，而錯誤接受率高於 7.3.10 節所述的指紋感應器要求，則：
  • 請務必不要重設 DevicePolicyManager.setPasswordExpirationTimeout() 設定的密碼到期計時器。
  • 如果應用程式已呼叫 KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)，則不得驗證存取金鑰庫的權限。

9.12. 資料刪除

裝置必須為使用者提供執行「恢復原廠設定」的機制，允許邏輯和實體刪除所有資料，但下列資料除外：

• 系統映像檔
• 系統映像檔所需的任何作業系統檔案

所有使用者產生的資料都必須刪除。這項做法必須符合相關的資料刪除業界標準，例如 NIST SP800-88。這項功能必須用於實作 第 3.9 節「裝置管理」中所述的 wipeData() API (Android 裝置管理 API 的一部分)。

裝置可能會提供快速資料清除功能，以便執行邏輯資料刪除作業。

9.13. 安全啟動模式

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

強烈建議 Android 裝置實作項目導入安全啟動模式，並符合下列規定：

• 裝置實作項目應為使用者提供選項，讓他們可以透過與正常開機不同的工作流程，從開機選單進入安全模式。

• 裝置實作必須為使用者提供進入安全啟動模式的選項，且該模式必須在裝置上安裝的第三方應用程式無法中斷的情況下執行，除非第三方應用程式是裝置政策控制器，且已將 UserManager.DISALLOW_SAFE_BOOT 標記設為 true。

• 裝置實作方式必須提供使用者在安全模式下解除安裝任何第三方應用程式的能力。

9.14. 汽車車輛系統隔離

Android Automotive 裝置應與重要車輛子系統交換資料，例如使用車輛 HAL 透過 CAN 匯流排等車輛網路傳送及接收訊息。Android Automotive 裝置實作項目必須在 Android 架構層以下實作安全防護功能，以防範 Android 架構或第三方應用程式與車輛子系統之間的惡意或非預期互動。這些安全性功能如下：

• 來自 Android 架構車輛子系統的門控訊息，例如允許清單的允許訊息類型和訊息來源。
• Watchdog 可防範來自 Android 架構或第三方應用程式的阻斷服務攻擊。這可防止惡意軟體向車輛網路大量傳送流量，進而導致車輛子系統發生故障。

10. 軟體相容性測試

裝置實作項目必須通過本節所述的所有測試。

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

10.1. 相容性測試套件

裝置實作項目必須使用裝置上的最終發布軟體，通過 Android 相容性測試套件 (CTS) (可從 Android 開放原始碼計畫取得) 的測試。此外，裝置實作者應盡可能使用 Android 開放原始碼樹狀結構中的參考實作項目，並必須確保在 CTS 中出現模糊情況時，以及在參考原始碼的任何部分重新實作時，能維持相容性。

CTS 設計用於在實際裝置上執行。和其他軟體一樣，CTS 本身可能也會有錯誤。CTS 的版本會與此相容性定義獨立運作，Android 7.0 可能會發布多個 CTS 修訂版本。裝置實作項目必須在裝置軟體完成時，通過最新的 CTS 版本。

10.2. CTS 驗證工具

裝置實作項目必須在 CTS Verifier 中正確執行所有適用的案例。CTS Verifier 是相容性測試套件的一部分，由人工操作員執行，用於測試自動化系統無法測試的功能，例如相機和感應器的正確運作情形。

CTS Verifier 可測試多種硬體，包括部分選用硬體。裝置實作必須通過所有硬體測試；舉例來說，如果裝置有加速計，就必須在 CTS Verifier 中正確執行加速計測試案例。針對相容性定義說明文件中標示為選用功能的測試案例，您可以選擇略過或省略。

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

11. 可更新軟體

裝置實作項目必須包含取代整個系統軟體的機制。這項機制不需要執行「即時」升級，也就是說，可能需要重新啟動裝置。

只要能取代裝置上預先安裝的軟體，您可以使用任何方法。舉例來說，下列任何一種做法都能滿足這項要求：

• 透過重新啟動進行離線更新的「無線更新」(OTA) 下載。
• 透過主機電腦的 USB 進行「連線」更新。
• 透過重新啟動和從可移除儲存空間的檔案更新「離線」更新。

不過，如果裝置實作內容支援無限量資料連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，則必須支援 OTA 下載，並透過重新啟動進行離線更新。

使用的更新機制必須支援不清除使用者資料的更新作業。也就是說，更新機制必須保留應用程式私人資料和應用程式共用資料。請注意，上游 Android 軟體包含符合此要求的更新機制。

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

如果裝置導入作業在發布後，但在與 Android 相容性團隊協商後判斷的合理產品壽命期間內，發現有影響第三方應用程式相容性的錯誤，則裝置導入者必須透過可依照上述機制套用的軟體更新，修正這類錯誤。

Android 包含多項功能，可讓裝置擁有者應用程式 (如有) 控制系統更新的安裝作業。為方便這項作業，回報 android.software.device_admin 的裝置系統更新子系統，必須實作 SystemUpdatePolicy 類別中所述的行為。

12. 文件變更記錄

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

• 說明變更記錄

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

1. 簡介
2. 裝置類型
3. 軟體
4. 應用程式封裝
5. 多媒體
6. 開發人員工具和選項
7. 硬體相容性
8. 效能和電源
9. 安全性模型
10. 軟體相容性測試
11. 可更新的軟體
12. 說明文件變更記錄
13. 聯絡我們

12.1. 變更記錄查看提示

變更內容如下所示：

• CDD
  相容性規定的重大變更。

• 文件
  外觀或建構相關變更。

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

13. 與我們聯絡

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