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

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

Android 6.0 相容性定義

1. 簡介

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

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

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

如要與 Android 6.0 相容，裝置實作方式必須符合本相容性定義中列出的規定，包括透過參照納入的任何文件。

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

因此，Android 開放原始碼計畫 [Resources, 2] 是 Android 的參考和偏好實作項目。強烈建議裝置實作人員盡可能以 Android 開放原始碼計畫提供的「上游」原始碼為基礎，進行實作。雖然部分元件可以假設以其他實作項目取代，但強烈建議您不要採用這種做法，因為通過軟體測試將變得更加困難。實作者有責任確保與標準 Android 實作項目的完整行為相容性，包括相容性測試套件和其他項目。最後，請注意，本文件明文禁止某些元件替換和修改作業。

第 14 節列出的許多資源都是直接或間接從 Android SDK 衍生而來，且功能上與該 SDK 說明文件中的資訊相同。在任何情況下，如果此相容性定義或相容性測試套件與 SDK 說明文件不一致，則以 SDK 說明文件為準。第 14 節中參考資料提供的任何技術細節，都會視為本相容性定義的一部分。

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 功能 [資源, 3]。

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

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

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

必須宣告 android.hardware.type.automotive 功能。
必須支援 uiMode = UI_MODE_TYPE_CAR [Resources, 5]。

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

2.1 裝置設定

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

類別	功能	小節	手提式	電視	觀看	Automotive	其他
輸入	D-Pad	7.2.2. 非觸控式導覽功能		必須
	觸控螢幕	7.2.4. 觸控螢幕輸入	必須		必須		SHOULD
	麥克風	7.8.1. 麥克風	必須	應	必須	必須	SHOULD
感應器	加速計	7.3.1 加速計	SHOULD		SHOULD		SHOULD
感應器	GPS	7.3.3. GPS	SHOULD			SHOULD
連線能力	Wi-Fi	7.4.2. IEEE 802.11	SHOULD	必須		SHOULD	SHOULD
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	SHOULD	SHOULD			SHOULD
	藍牙	7.4.3. 藍牙	SHOULD	必須	必須	必須	SHOULD
	藍牙低功耗	7.4.3. 藍牙	SHOULD	必須	SHOULD	SHOULD	SHOULD
	USB 周邊/主機模式	7.7. USB	SHOULD			SHOULD	SHOULD
輸出	喇叭和/或音訊輸出通訊埠	7.8.2. 音訊輸出裝置	必須	必須		必須	必須

3. 軟體

3.1. 代管 API 相容性

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

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

此相容性定義允許某些類型的硬體，讓裝置實作項目略過 Android 所包含的 API。在這種情況下，API 仍必須存在，且運作方式必須合理。如要瞭解此情境的具體規定，請參閱第 7 節。

3.2. 軟性 API 相容性

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

3.2.1. 權限

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

3.2.2. 建構參數

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

參數	詳細說明
VERSION.RELEASE	目前執行的 Android 系統版本，以人類可讀的格式表示。這個欄位必須包含 [Resources, 9] 中定義的字串值。
VERSION.SDK	目前執行的 Android 系統版本，以第三方應用程式程式碼可存取的格式呈現。對於 Android 6.0，這個欄位必須有整數值 23。
VERSION.SDK_INT	目前執行的 Android 系統版本，以第三方應用程式程式碼可存取的格式呈現。對於 Android 6.0，這個欄位必須有整數值 23。
VERSION.INCREMENTAL	裝置實作者選擇的值，用於指定目前執行中 Android 系統的特定版本，以人類可讀的格式呈現。此值絕對不可用於提供給使用者的不同版本。這個欄位的常見用途是指出系統用來產生建構項目的建構編號或來源控管變更 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
桌遊	裝置實作者選擇的值，用來識別裝置使用的特定內部硬體，格式為人類可讀。這個欄位的可能用途是指出為裝置供電的板子特定修訂版本。這個欄位的值必須能以 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:6.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。
使用者	產生版本的使用者 (或自動化使用者) 名稱或使用者 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
SECURITY_PATCH	這個值表示版本的安全性修補程式等級。此標記必須表示版本包含透過指定 Android 公開安全性公告發布的所有安全性修補程式。格式必須為 [YYYY-MM-DD]，且必須與公開安全性通報的 Android 安全性修補程式等級字串相符，例如「2015-11-01」。
BASE_OS	這個值代表建構版本的 FINGERPRINT 參數，除了 Android 公開安全性公告中提供的修補程式外，其他都與此建構版本相同。此值必須回報正確的值，如果不存在此建構項目，則回報空字串 ("")。

3.2.3. 意圖相容性

裝置實作項目必須遵循 Android 的鬆散耦合意圖系統，如以下各節所述。「符合」是指裝置實作者必須提供 Android 活動或服務，並指定相符的意圖篩選器，以便為每個指定的意圖模式繫結及實作正確的行為。

3.2.3.1. 核心應用程式意圖

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

桌上時鐘
Browser
日曆
聯絡人
圖庫
GlobalSearch
啟動器
音樂
設定

裝置實作項目應視情況納入核心 Android 應用程式，但必須納入實作這些核心 Android 應用程式所有「公開」活動或服務元件所定義的相同意圖模式的元件。請注意，如果沒有 android:exported 屬性或屬性值為 true，系統會將 Activity 或 Service 元件視為「公開」。

3.2.3.2. 意圖解析

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

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

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

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

必須嘗試驗證任何意圖篩選器，方法是執行 Digital Asset Links 規格 [Resources, 141] 中定義的驗證步驟，並由上游 Android 開放原始碼專案中的 Package Manager 實作。
必須在安裝應用程式時嘗試驗證意圖篩選器，並將所有已成功驗證的 UIR 意圖篩選器設為其 UIR 的預設應用程式處理常式。
如已成功驗證特定 URI 意圖篩選器，但其他候選 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 意圖，以便顯示主畫面的預設應用程式設定選單 [Resources, 10]
如果裝置實作報告 android.hardware.telephony，則必須提供設定選單，以便呼叫 android.provider.Telephony.ACTION_CHANGE_DEFAULT 意圖，顯示對話方塊以便變更預設的簡訊應用程式 [Resources, 11]
如果裝置實作項目回報 android.hardware.nfc.hce，則必須使用 android.settings.NFC_PAYMENT_SETTINGS 意圖，顯示預設的 Tap & Pay 應用程式設定選單 [資源, 10]

3.3. 原生 API 相容性

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 管理說明文件 [Resources, 12] 最新版本中記錄及說明的 ABI，且必須支援 Advanced SIMD (又稱為 NEON) [Resources, 13] 擴充功能
應使用上游 Android 開放原始碼專案提供的原始碼和標頭檔案進行建構

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

libc (C 程式庫)
libm (數學程式庫)
對 C++ 提供最精簡的支援
JNI 介面
liblog (Android 記錄)
libz (Zlib 壓縮)
libdl (動態連結器)
libGLESv1_CM.so (OpenGL ES 1.x)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.x)
libEGL.so (原生 OpenGL 途徑管理)
libjnigraphics.so
libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
libOpenMAXAL.so (支援 OpenMAX AL 1.0.1)
libandroid.so (原生 Android 活動支援)
libmediandk.so (原生媒體 API 支援)
支援 OpenGL，如下所述

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

請注意，裝置實作必須包含 libGLESv3.so，且必須以符號連結 (符號連結) 至 libGLESv2.so。反過來說，必須匯出所有 OpenGL ES 3.1 和 Android 擴充功能套件 [Resources, 14] 函式符號，如 NDK 版本 android-21 中所定義。雖然必須提供所有符號，但只有裝置實際支援的 OpenGL ES 版本和擴充功能，才需要完全實作對應的函式。

如果裝置實作包含名為 libvulkan.so 的原生程式庫，則必須匯出函式符號，並提供 Vulkan 1.0 API 的實作方式，以及由 Khronos Group 定義並通過 Khronos 相容性測試的 VK_KHR_surface、VK_KHR_swapchain 和 VK_KHR_android_surface 擴充功能。

原生程式碼的相容性很難處理。因此，我們強烈建議裝置實作者使用上游 Android 開放原始碼專案中上述程式庫的實作項目。

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 建構的應用程式相容，裝置在 32 位元 ARM 應用程式讀取 /proc/cpuinfo 時，必須包含以下行：

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

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

3.4. 網頁相容性

3.4.1. WebView 相容性

Android Watch 裝置可以，但所有其他裝置實作都必須提供 android.webkit.Webview API 的完整實作。

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

裝置的 android.webkit.WebView 實作項目必須以 Android 6.0 上游 Android 開放原始碼專案的 Chromium 版本為基礎。此版本包含 WebView 的特定功能和安全性修正項目 [Resources, 16]。
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 規範 [Resources, 17]。

3.4.2. 瀏覽器相容性

Android TV、Android 手錶和 Android Automotive 實作可能會省略瀏覽器應用程式，但必須支援第 3.2.3.1 節所述的公開意圖模式。所有其他類型的裝置實作方式都必須包含獨立的瀏覽器應用程式，方便一般使用者瀏覽網頁。

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

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

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

應用程式快取/離線作業 [Resources, 18]
<video> 標記 [Resources, 19]
geolocation [Resources, 20]

此外，裝置實作方式必須支援 HTML5/W3C webstorage API [Resources, 21]，並應支援 HTML5/W3C IndexedDB API [Resources, 22]。請注意，由於網路開發標準機構正在轉向以 IndexedDB 取代 webstorage，因此 IndexedDB 預計將成為日後 Android 版本的必要元件。

3.5. API 行為相容性

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

裝置不得變更標準意圖的行為或語意。
裝置絕對不得變更特定類型的系統元件 (例如服務、活動、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 的應用程式 (透過 lt;uses-librarygt; 機制) 才會受到這些 API 記憶體用量增加的影響。

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

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

3.7. 執行階段相容性

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

裝置實作內容必須設定 Dalvik 執行階段，以便根據上游 Android 平台和下表指定的內容分配記憶體。(如要瞭解螢幕大小和螢幕密度的定義，請參閱 7.1.1 節)。

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

螢幕版面配置	螢幕密度	應用程式記憶體下限
Android 手錶	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)
	240 dpi (hdpi)	36MB
	280 dpi	36MB
	320 dpi (xhdpi)	48MB
	360 dpi (360dpi)	48MB
	400 dpi (400dpi)	56MB
	420 dpi (420dpi)	64MB
	480 dpi (xxhdpi)	88MB
	560 dpi (560dpi)	112MB
	640 dpi (xxxhdpi)	154MB
小/正常	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi
	320 dpi (xhdpi)	80MB
	360 dpi (360dpi)	80MB
	400 dpi (400dpi)	96MB
	420 dpi (420dpi)	112MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
large	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)	80MB
	280 dpi	96MB
	320 dpi (xhdpi)	128MB
	360 dpi (360dpi)	160MB
	400 dpi (400dpi)	192MB
	420 dpi (420dpi)	228MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
特大	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)	96MB
	280 dpi	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 裝置實作項目的選用項目，但應在 Android 手持裝置上支援。

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

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

3.8.3. 通知

Android 包含 API，可讓開發人員使用裝置的硬體和軟體功能，通知使用者重要事件 [Resources, 25]。

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

此外，實作項目必須正確轉譯 API 或狀態/系統列圖示樣式指南中提供的所有資源 (圖示、動畫檔案等) [資源，26] [資源，27]，如果是 Android TV 裝置，則可能不會顯示通知。裝置導入者可提供與 Android 開放原始碼參考導入方式不同的通知使用者體驗，但這類替代通知系統必須支援現有的通知資源，如上所述。

Android 支援各種通知，例如：

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

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

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

3.8.4. 搜尋

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

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

Android 裝置實作項目應在裝置上實作助理，以便處理輔助動作 [Resources, 30]。

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

3.8.5. 浮動式訊息

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

3.8.6。主題

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

Android 包含「Holo」主題系列，可做為一組定義樣式的應用程式開發人員使用，以便符合 Android SDK 定義的 Holo 主題外觀和感受 [Resources, 33]。裝置實作項目不得變更任何向應用程式公開的 Holo 主題屬性 [Resources, 34]。

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

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

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

3.8.7. 動態桌布

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

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

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

3.8.8。活動切換

由於「近期」功能導覽鍵為選用項目，因此 Android TV 裝置和 Android Watch 裝置實作概覽畫面的規定為選用項目。

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

必須將相關聯的近期內容顯示為一組一起移動的內容。
至少必須支援最多 6 個顯示活動。
一次至少顯示 4 項活動的標題。
應在「最近使用」中顯示醒目顯示顏色、圖示和畫面標題。
必須實作螢幕固定行為 [Resources, 38]，並為使用者提供設定選單，以便切換這項功能。
應顯示關閉操作元素 (「x」)，但可在使用者與畫面互動前延遲顯示。

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

3.8.9。輸入管理

Android 支援輸入管理功能，並支援第三方輸入方法編輯器 [Resources, 39]。允許使用者在裝置上使用第三方輸入法功能的裝置實作，必須宣告平台功能 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 已淘汰，改用媒體通知範本，讓媒體應用程式可與螢幕鎖定畫面上顯示的播放控制項整合，做為螢幕鎖定畫面通知。[資源, 40]裝置實作項目必須正確轉譯媒體通知範本，做為第 3.8.3 節所述的螢幕鎖定通知的一部分。

3.8.11. 夢境

Android 支援名為 Dreams 的互動式螢幕保護程式 [Resources, 41]。當裝置連上電源處於閒置狀態，或已連接至桌面座架時，Dreams 可讓使用者與應用程式互動。Android Watch 裝置可實作 Dreams，但其他類型的裝置實作應支援 Dreams，並提供設定選項，讓使用者可根據 android.settings.DREAM_SETTINGS 意圖設定 Dreams。

3.8.12. 位置

如果裝置有可提供位置座標的硬體感應器 (例如 GPS)，則位置模式必須顯示在「設定」中的「位置」選單中 [資源, 42]。

3.8.13. Unicode 和字型

Android 支援彩色表情符號字元。當 Android 裝置實作包含 IME 時，裝置應為使用者提供輸入方法，以便輸入 Unicode 6.1 中定義的表情符號字元 [Resources, 43]。所有裝置都必須能夠以彩色圖示顯示這些表情符號。

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.9. 裝置管理

Android 提供多項功能，可讓具備安全防護機制的應用程式透過 Android Device Administration API [Resources, 44] 在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端資料清除。裝置實作項目必須提供 DevicePolicyManager 類別的實作項目 [資源, 45]。支援 PIN 碼 (數字) 或密碼 (英數字) 的裝置實作，必須支援 Android SDK 說明文件 [資源, 44] 中定義的裝置管理政策，並回報平台功能 android.software.device_admin。

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

如果裝置實作宣告 android.software.device_admin 功能，則裝置盒裝設定流程必須允許註冊裝置政策控制器 (DPC) 應用程式做為裝置擁有者應用程式 [ 資源, 46]。裝置實作可能會預先安裝執行裝置管理功能的應用程式，但如果沒有使用者或裝置管理員明確同意或採取行動，則不得將此應用程式設為裝置擁有者應用程式。

裝置擁有者佈建程序 (由 android.app.action.PROVISION_MANAGED_DEVICE [ Resources, 47] 啟動的流程) 使用者體驗必須符合 AOSP 實作

如果裝置實作項目回報 android.hardware.nfc，則必須啟用 NFC，即使是在開箱即用設定流程中也一樣，才能允許裝置擁有者進行 NFC 佈建 [資源, 48]。

3.9.1.2 受管理的設定檔佈建

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

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

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 支援受管理的設定檔
允許建立一 (且僅建立一) 個受管理的設定檔 [Resources, 50]
使用圖示徽章 (類似於 AOSP 上游工作徽章) 代表受管理的應用程式和小工具，以及其他徽章 UI 元素，例如「最近」和「通知」
顯示通知圖示 (類似 AOSP 上游工作標記)，指出使用者目前處於受管理設定檔應用程式中
當裝置喚醒 (ACTION_USER_PRESENT) 且前景應用程式位於受管理的設定檔中時，顯示浮動視窗，指出使用者處於受管理的設定檔
如果有受管理的設定檔，請在 Intent 選擇器中顯示視覺提示，讓使用者將意圖從受管理的設定檔轉寄給主要使用者，或反之 (如果裝置政策控制器已啟用)
如果有受管理的設定檔，請為主要使用者和受管理的設定檔提供下列使用者操作元素：
- 為主要使用者和受管理的設定檔分別計算電池、位置、行動數據和儲存空間用量。
- 獨立管理在主要使用者或受管理設定檔中安裝的 VPN 應用程式。
- 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
- 獨立管理主要使用者或受管理設定檔中的帳戶。
確保預設撥號程式可從受管理的設定檔 (如果有) 和主要設定檔查詢來電者資訊 (如果有)，前提是裝置政策控制器允許這麼做。
即使受管理的設定檔不算是除了主要使用者之外的另一位使用者，也必須確保其符合啟用多位使用者的裝置適用的所有安全性規定 (請參閱第 9.5 節)。

3.10. 無障礙設定

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

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

Android Automotive 實作項目應提供與預設 Android 實作項目一致的 Android 無障礙功能架構實作項目。
裝置實作 (不含 Android Automotive) 必須提供與預設 Android 實作相符的 Android 無障礙架構實作。
裝置實作 (不含 Android Automotive) 必須透過 android.accessibilityservice API 支援第三方無障礙服務實作 [Resources, 52]
裝置實作 (不含 Android Automotive) 必須產生 AccessibilityEvents，並以與預設 Android 實作方式一致的方式，將這些事件傳送至所有已註冊的 AccessibilityService 實作
裝置實作 (不含沒有音訊輸出的 Android Automotive 和 Android Watch 裝置) 必須提供使用者可存取的機制，以便啟用及停用無障礙服務，且必須在回應 android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS 意圖時顯示此介面。

此外，裝置實作項目應在裝置上實作無障礙服務，並提供機制，讓使用者在設定裝置時啟用無障礙服務。您可以透過 Eyes Free 專案取得無障礙服務的開放原始碼實作項目 [資源，53]。

3.11. 文字轉語音

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

Android Automotive 實作項目：

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

所有其他裝置實作方式：

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

3.12. 電視輸入框架

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

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

3.12.1. TV 應用程式

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

預設的 TV 應用程式必須提供已安裝輸入來源和第三方輸入來源的頻道存取權。請注意，安裝的輸入內容包含所有預設提供的輸入內容，無論是否以 TIF 為基礎。

TV 應用程式必須提供安裝及使用 TV 頻道的設施 [Resources, 56]，並符合下列規定：

裝置實作項目必須允許安裝及管理第三方 TIF 輸入 (第三方輸入) [資源, 57]。
裝置實作可能會在預先安裝的 TIF 輸入 (已安裝輸入) [資源, 58] 和第三方輸入之間提供視覺區隔。
裝置實作項目不得在 TV 應用程式之外，顯示超過單一導覽動作的第三方輸入內容 (也就是從 TV 應用程式展開第三方輸入內容清單)。

3.12.1.1. 電子節目指南

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

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

3.12.1.2. 導覽

Android TV 裝置輸入裝置 (例如遙控器、遙控器應用程式或遊戲控制器) 必須允許使用 D-Pad 瀏覽螢幕上所有可操作的部分。當畫面上沒有可操作的區段時，必須使用 D-Pad 向上和向下鍵才能變更即時電視頻道。

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

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

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

4. 應用程式封裝相容性

裝置實作項目必須安裝並執行由官方 Android SDK 中「aapt」工具產生的 Android「.apk」檔案 [Resources, 61]。

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

5. 多媒體相容性

5.1. 媒體轉碼器

除了本文件明確允許的情況外，裝置實作方式必須支援 Android SDK 說明文件 [Resources, 64] 中指定的核心媒體格式。具體來說，裝置實作必須支援下表中定義並透過 MediaCodecList 回報的媒體格式、編碼器、解碼器、檔案類型和容器格式 [Resources, 65]。裝置實作項目也必須能夠解碼 CamcorderProfile 中回報的所有設定檔 [Resources, 66]，並且必須能夠解碼所有可編碼的格式。所有這些編解碼都會以軟體實作方式提供，並在 Android 開放原始碼計畫的偏好 Android 實作中實作。

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

5.1.1. 音訊轉碼器

格式/編解碼	編碼器	解碼器	詳細說明	支援的檔案類型/容器格式
MPEG-4 AAC 設定檔 (AAC LC)	必要¹	必要	支援單聲道/立體聲/5.0/5.1² 內容，取樣率為 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+)	必要¹ (Android 4.1 以上版本)	必要	支援單聲道/立體聲/5.0/5.1² 內容，取樣率為 16 到 48 kHz 的標準值。
MPEG-4 HE AACv2 Profile (增強型 AAC+)		必要	支援單聲道/立體聲/5.0/5.1² 內容，取樣率為 16 到 48 kHz 的標準值。
AAC ELD (增強型低延遲 AAC)	必要¹ (Android 4.1 以上版本)	必填 (Android 4.1 以上版本)	支援標準取樣率 (16 到 48 kHz) 的單聲道/立體聲內容。
AMR-NB	必要³	必要³	4.75 至 12.2 kbps，取樣頻率為 8 kHz	3GPP (.3gp)
AMR-WB	必要³	必要³	9 種速率，從 6.60 kbit/s 到 23.85 kbit/s，取樣率為 16 kHz
FLAC		必填 (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	必要⁴ (Android 4.1 以上版本)	必要	16 位元線性 PCM (速率上限為硬體限制)。裝置必須支援以 8000、11025、16000 和 44100 Hz 頻率錄製原始 PCM 的取樣率。	WAVE (.wav)
Opus		必填 (Android 5.0 以上版本)		Matroska (.mkv)

1 如要定義 android.hardware.microphone，此屬性為裝置實作項目的必要條件，但 Android Watch 裝置實作項目則可選擇是否實作。

2 只需將 5.0/5.1 內容下混，錄製或轉譯超過 2 個聲道則為選用功能。

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)

5.1.3. 視訊轉碼器

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

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

2 除了 Android Watch 裝置外，裝置實作項目都需要這項屬性。

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

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

5 強烈建議 Android Automotive 使用者使用，Android Watch 使用者可視需求使用，所有其他裝置類型則為必填屬性。

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

5.2. 影片編碼

對於 Android Watch 裝置的導入作業，影片編碼器為選用項目。

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

支援 H.264 轉碼器的 Android 裝置實作項目，必須支援基準設定檔第 3 級和以下的 SD (標準解析度) 視訊編碼設定檔，並建議支援主設定檔第 4 級和以下的 HD (高畫質) 視訊編碼設定檔。強烈建議 Android TV 裝置以 30 fps 編碼 HD 1080p 影片。

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

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

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

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

1 如果硬體支援。

5.3. 影片解碼

對於 Android Watch 裝置的導入作業，影片編碼器為選用項目。

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

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

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

搭載 H.264 解碼器的 Android 裝置實作項目，必須支援 Main Profile 級別 3.1 和以下的 SD 視訊解碼設定檔，並應支援 HD 解碼設定檔。Android 電視裝置必須支援高畫質等級 4.2 和 HD 1080p 解碼設定檔。

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

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

2 必須用於 Android TV 裝置導入。

如要支援第 5.1.3 節所述的 VP8 編解碼器，Android 裝置實作項目必須支援下列 SD 解碼設定檔，並應支援 HD 解碼設定檔。Android TV 裝置必須支援 HD 1080p 解碼設定檔。

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

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

2 必須用於 Android TV 裝置導入。

根據第 5.1.3 節的說明，Android 裝置實作必須支援 VP9 編解碼器，且應支援 HD 解碼設定檔。強烈建議 Android TV 裝置支援 HD 1080p 解碼設定檔，並應支援 UHD 解碼設定檔。支援 UHD 影片解碼設定檔時，該設定檔必須支援 8 位元色彩深度，且應支援 VP9 設定檔 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	60 fps	60 fps
視訊位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

1 此為 Android 電視裝置實作項目的必要條件，但其他類型的裝置則須由硬體支援。

2 強烈建議在硬體支援的情況下，針對現有的 Android TV 裝置實作。

根據第 5.1.3 節的說明，Android 裝置實作項目如要支援 H.265 編碼器，就必須支援 Main Profile 級別 3 的主層級別，以及以下的 SD 視訊解碼設定檔，並且應支援 HD 解碼設定檔。強烈建議 Android TV 裝置支援 UHD 解碼設定檔和 HD 1080p 解碼設定檔。如果支援 HD 1080p 解碼設定檔，則必須支援 Main Profile Level 4.1 Main 層級。如果支援 UHD 解碼，則必須支援 Main10 級別 5 的主層級別。

	SD (低畫質)	SD (高畫質)	HD 720p¹	HD 1080p²	UHD²
影片解析度	352 x 288 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片影格速率	30 fps	30 fps	30 fps	60 fps²	60 fps
視訊位元率	600 Kbps	1.6 Mbps	4 Mbps	10 Mbps	20 Mbps

1 此為 Android 電視裝置實作項目的必要條件，但其他類型的裝置則須由硬體支援。

2 強烈建議在硬體支援的情況下，針對現有的 Android TV 裝置實作。

5.4. 音訊錄製

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

5.4.1. 原始音訊擷取

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

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

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

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

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

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

5.4.2. 語音辨識擷取

除了上述錄音規格外，當應用程式開始使用 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，供裝置實作使用 [Resources, 69]。聲明 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 裝置實作項目必須支援系統主音量，以及在支援的輸出裝置上提供數位音訊輸出音量衰減功能，但壓縮音訊直通輸出 (在裝置上不會進行音訊解碼) 除外。

5.6. 音訊延遲

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

本節的定義如下：

輸出延遲。應用程式寫入 PCM 編碼資料影格，與外部收聽器或轉換器可聽見或觀察到對應音訊之間的間隔。
冷輸出延遲。在音訊輸出系統在要求前處於閒置狀態且已關閉的情況下，第一個影格的輸出延遲時間。
連續輸出延遲時間。裝置播放音訊後，後續影格輸出延遲時間。
輸入延遲。外部聲響傳送至裝置與應用程式讀取相應 PCM 編碼資料影格之間的間隔。
冷輸入延遲。當音訊輸入系統在請求前處於閒置狀態並關閉電源時，第一個影格的輸入延遲時間和輸入時間損失總和。
持續輸入延遲。裝置擷取音訊時，後續影格輸入的延遲時間。
冷輸出抖動。冷輸出延遲值的個別測量值之間的差異。
冷輸入抖動。冷輸入延遲值的個別測量值之間的差異。
連續往返延遲時間。連續輸入延遲時間加上連續輸出延遲時間，再加上一個緩衝區時間。緩衝期可讓應用程式有時間進行處理，並減少輸入和輸出串流之間的相位差異。
OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 集合；請參閱 NDK_root/docs/opensles/index.html。

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

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

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

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

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

5.7. 網路協定

如 Android SDK 說明文件所述 [資源, 64]，裝置必須支援媒體網路通訊協定，才能播放音訊和影片。具體來說，裝置必須支援下列媒體網路通訊協定：

RTSP (RTP、SDP)
HTTP(S) 漸進式串流
HTTP(S) 即時串流草稿通訊協定，第 3 版 [資源，71]

5.8. 安全無虞的媒體服務

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

5.9. 樂器數位介面 (MIDI)

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

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

USB 主機模式 (第 7.7 節 USB)
USB 周邊裝置模式 (第 7.7 節 USB)

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

以藍牙 LE 為中心角色的 MIDI (第 7.4.3 節藍牙) 處於試用狀態。回報 android.software.midi 功能的裝置實作，且透過藍牙 LE 提供一般非 MIDI 連線功能時，應支援透過藍牙 LE 傳輸 MIDI。

5.10. 專業音訊

如果裝置實作符合下列所有需求，強烈建議您透過 android.content.pm.PackageManager 類別 [Resources, 70] 回報支援 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 版)的「行動裝置 (插孔) 規格」部分。

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

6.1. 開發人員工具

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

Android Debug Bridge (ADB) [資源，72]

裝置實作方式必須支援 Android SDK 中所述的所有 ADB 函式，包括 dumpsys [Resources, 73]。裝置端 ADB 守護程序預設為停用狀態，且必須提供使用者可存取的機制，才能開啟 Android Debug Bridge。如果裝置實作省略 USB 周邊裝置模式，則必須透過區域網路 (例如乙太網路或 802.11) 實作 Android 偵錯橋接器。

Android 支援安全的 ADB。安全 ADB 會在已知的已驗證主機上啟用 ADB。裝置實作項目必須支援安全的 ADB。

Dalvik 偵錯監視器服務 (ddms) [Resources, 74]

裝置實作項目必須支援 Android SDK 說明文件中列出的所有 ddms 功能。由於 ddm 使用 adb，因此 ddm 的支援功能應預設為停用狀態，但在使用者啟用 Android Debug Bridge 時，必須支援 ddm，如上所述。

Monkey [Resources, 75]

裝置實作項目必須包含 Monkey 架構，並讓應用程式可使用該架構。

SysTrace [Resources, 76]

裝置實作項目必須支援 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 意圖，才能顯示應用程式開發相關設定 [Resources, 77]。上游 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) 方法，一律回報正確的硬體設定資訊。[Resources, 70]

7.1. 顯示和圖形

Android 包含自動調整應用程式資產和 UI 版面配置的設施，可根據裝置自動調整，確保第三方應用程式可在各種硬體設定下順利執行 [Resources, 78]。裝置必須正確實作這些 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 Watch 裝置 (詳見第 2 節) 的螢幕尺寸可能較小，如本節所述。

Android UI 架構支援各種螢幕大小，並允許應用程式透過 SCREENLAYOUT_SIZE_MASK 使用 android.content.res.Configuration.screenLayout 查詢裝置螢幕大小 (又稱為「螢幕版面配置」)。裝置實作項目必須依照 Android SDK 說明文件 [Resources, 78] 的定義，回報正確的螢幕大小，並由上游 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 裝置實作方式 (實體整合螢幕)，螢幕的對角線尺寸必須至少為 2.5 英寸。

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

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

7.1.1.2. 螢幕顯示比例

Android Watch 裝置的顯示比例可能為 1.0 (1:1)。

螢幕顯示比例必須是 1.3333 (4:3) 到 1.86 (大約 16:9) 之間的值，但 Android Watch 裝置的顯示比例可能為 1.0 (1:1)，因為這類裝置的實作會將 UI_MODE_TYPE_WATCH 用於 android.content.res.Configuration.uiMode。

7.1.1.3. 螢幕密度

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

120 dpi (ldpi)
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi)
280 dpi
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 架構密度。

7.1.2. 顯示指標

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

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。裝置實作項目也必須支援 Android RenderScript，詳情請參閱 Android SDK 說明文件 [Resources, 80]。

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

受管理的 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 的裝置實作必須支援對應的受管理 API，並納入原生 C/C++ API 支援。在宣告支援 OpenGL ES 3.0 或 3.1 的裝置實作中，libGLESv2.so 除了匯出 OpenGL ES 2.0 函式符號外，還必須匯出對應的函式符號。

除了 OpenGL ES 3.1 之外，Android 還提供擴充功能套件，其中包含 Java 介面 [Resources, 81] 和原生支援的進階圖形功能，例如平鋪和 ASTC 紋理壓縮格式。Android 裝置實作項目可能會支援這個擴充功能包，但只有在完全實作時，才須透過 android.hardware.opengles.aep 功能旗標識別支援。

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

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

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

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

此外，裝置實作內容的行為必須與 Android SDK 說明文件中關於硬體加速的內容一致 [Resources, 82]。

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

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

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。如果裝置透過有線、無線或內嵌額外螢幕連線支援外接螢幕，則裝置實作必須實作 Android SDK 說明文件中所述的顯示器管理器 API [Resources, 84]。

7.2. 輸入裝置

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

7.2.1. 鍵盤

Android Watch 和 Android Automotive 實作項目可能會導入軟體鍵盤。所有其他裝置實作方式都必須實作螢幕鍵盤，並符合下列條件：

裝置實作方式：

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

7.2.2. 非觸控導覽

Android TV 裝置必須支援方向鍵。

裝置實作方式：

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

7.2.3. 瀏覽鍵

如本節所述，不同裝置類型的「Home」、「Recents」和「Back」功能適用性和顯示需求皆不相同。

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

Android 手持裝置實作項目必須提供「主畫面」、「近期」和「返回」功能。
Android TV 裝置實作項目必須提供「Home」和「Back」功能。
Android Watch 裝置實作項目必須提供使用者可用的「Home」功能和「Back」功能，但在 UI_MODE_TYPE_WATCH 模式下除外。
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 6.0 以上版本的新裝置實作項目不得實作專屬的選單功能實體按鈕。較舊的裝置實作項目不應為選單功能實作專屬實體按鈕，但如果實作實體選單按鈕，且裝置執行的應用程式 targetSdkVersion 大於 10，則裝置實作項目：

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

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

支援輔助動作的 Android 裝置實作項目 [Resources, 30] 必須在其他導覽鍵可見時，透過單一動作 (例如輕觸、雙擊或手勢) 提供存取權，強烈建議使用長按主畫面按鈕或軟體鍵做為單一動作。

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

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

7.2.4. 觸控螢幕輸入

Android 手持裝置和手錶裝置必須支援觸控螢幕輸入功能。

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

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

Android 支援多種觸控螢幕、觸控板和假觸控輸入裝置。以觸控螢幕為基礎的裝置實作項目會與螢幕相關聯 [Resources, 86]，讓使用者有直接操作螢幕上項目的印象。由於使用者直接觸碰螢幕，系統不需要任何額外的操作元素來指出要操作的物件。相較之下，觸控模擬介面會提供使用者輸入系統，可模擬部分觸控螢幕功能。舉例來說，滑鼠或遙控器驅動螢幕上的游標，可模擬觸控操作，但使用者必須先指向或聚焦，然後再點選。滑鼠、觸控板、陀螺儀空中滑鼠、陀螺儀指標、搖桿和多點觸控觸控板等許多輸入裝置，都能支援觸控模擬互動。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 螢幕位置，並在螢幕上顯示視覺指標 [Resources, 87]。
您必須使用動作代碼回報觸控事件，該代碼會指定在螢幕上向下或向上移動指標時發生的狀態變更 [Resources, 87]。
必須支援在畫面上對物件執行指標向下和向上操作，讓使用者模擬輕觸畫面上的物件。
必須在時間門檻內，支援在螢幕上同一個物件上執行「指標向下」、「指標向上」、「指標向下」和「指標向上」的操作，讓使用者模擬在螢幕上雙擊物件的操作 [Resources, 87]。
必須支援在螢幕上任意點按下指標，然後將指標移至螢幕上任意其他點，接著再將指標移至上方，讓使用者模擬觸控拖曳動作。
必須支援指標向下，讓使用者快速將物件移至螢幕上的不同位置，然後指標向上，讓使用者在螢幕上揮動物件。

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

7.2.6. 支援遊戲控制器

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

7.2.6.1. 按鈕對應

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

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

1 [Resources, 88]

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

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

4 [Resources, 87]

類比控制項¹	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 [Resources, 87]

7.2.7. 遙控器

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

搜尋提示。當使用者透過實體或軟體遙控器啟動語音搜尋功能時，裝置實作方式必須觸發 KEYCODE_SEARCH (如果裝置支援助理，則觸發 KEYCODE_ASSIST)。
導覽：所有 Android TV 遙控器都必須包含「返回」、「主畫面」和「選取」按鈕，並支援方向鍵事件 [Resources, 88]。

7.3. 感應器

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

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

上述清單並非完整列表，請參閱 Android SDK 的說明文件和 Android 開放原始碼說明文件 (關於感應器) [Resources, 89] 的行為，以便瞭解相關資訊。

某些感應器類型為複合類型，也就是說，這些類型可從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速度感應器)。如果裝置實作包含必要實體感應器 (如 [資源, 92]所述)，則應實作這些感應器類型。如果裝置實作包含複合感應器，則必須按照 Android 開放原始碼說明文件中關於複合感應器的說明，實作感應器 [Resources, 92]。

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

請注意，裝置實作必須確保感應器事件串流絕對不會阻止裝置 CPU 進入休眠狀態，或從休眠狀態喚醒。

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

7.3.1. 加速計

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

必須實作並回報 TYPE_ACCELEROMETER 感應器 [Resources, 94]。
針對 Android Watch 裝置，必須能夠回報至少 50 Hz 的事件頻率 (此類裝置的電力限制較嚴格)，而其他裝置類型則為 100 Hz。
應回報的事件頻率應至少為 200 Hz。
必須遵循 Android 感應器座標系統，詳情請參閱 Android API [Resources, 90]。
必須能夠在任何軸線上，測量從自由落體到重力 (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 感應器座標系統，詳情請參閱 Android API [Resources, 90]。
必須能夠在飽和前，測量每個軸上的 -900 µT 和 +900 µT 之間的值。
硬鐵偏移值必須小於 700 µT，且應小於 200 µT，方法是將磁力計遠離動態 (電流誘導) 和靜態 (磁鐵誘導) 磁場。
解析度必須等於或大於 0.6 µT，且應等於或大於 0.2 µ。
應進行溫度補償。
必須支援硬體偏差的線上校正和補償功能，並在裝置重新啟動時保留補償參數。
必須套用軟鐵補償功能，可在使用中或裝置製造期間進行校正。
應具有標準差，以最快的取樣率，在至少 3 秒的時間內收集樣本，並依每個軸計算，不得超過 0.5 µT。
如果也包含加速計感應器和陀螺儀感應器，則必須實作 TYPE_ROTATION_VECTOR 複合感應器。
如果也實作了加速計感應器，則可實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。不過，如果實作，感應器在以 10 Hz 的頻率註冊批次模式時，耗電量必須低於 10 毫瓦，且應低於 3 毫瓦。

7.3.3. GPS

裝置實作應包含 GPS 接收器。如果裝置實作確實包含 GPS 接收器，則應加入某種形式的「輔助 GPS」技術，盡可能縮短 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 rad^2 / s^2 (每 Hz 變化值或 rad^2 / s)。變化範圍可隨取樣率而異，但必須受此值限制。換句話說，如果您以 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 以下
- 測量頻率上限必須為 200 Hz 以上
- 測量雜訊不得超過 400uG/√Hz
- 必須實作此感應器的非喚醒表單，緩衝功能至少可容納 3000 個感應器事件
- 批次處理的耗電量不得超過 3 毫瓦
SENSOR_TYPE_GYROSCOPE
- 測量範圍必須至少介於 -1000 和 +1000 dps 之間
- 測量解析度必須至少為 16 LSB/dps
- 測量頻率必須為 12.5 Hz 以下
- 測量頻率上限必須為 200 Hz 以上
- 測量雜訊不得超過 0.014°/s/√Hz
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 與 SENSOR_TYPE_GYROSCOPE 具有相同的品質要求
SENSOR_TYPE_GEOMAGNETIC_FIELD
- 測量範圍必須至少介於 -900 和 +900 uT 之間
- 測量解析度必須至少為 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 毫瓦
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 毫秒。
將資料送至 HAL 的延遲時間應低於 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 [Resources, 95]。
錯誤接受率不得高於 0.002%。
強烈建議您將誤拒率控制在 10% 以下 (以裝置測量為準)
對於註冊的一根手指，強烈建議延遲時間低於 1 秒，從觸碰指紋感應器到螢幕解鎖的時間為準。
在指紋驗證失敗五次後，必須限制嘗試次數，至少為 30 秒。
必須具備硬體支援的 KeyStore 實作項目，並在受信任的執行環境 (TEE) 或具有安全通道至 TEE 的晶片上執行指紋比對作業。
必須將所有可辨識的指紋資料加密，並以密碼學方式驗證，以便在 Android 開放原始碼專案網站的實作指南 [Resources, 96] 中所述，在受信任執行環境 (TEE) 之外取得、讀取或變更這些資料。
必須先建立信任鏈，才能新增指紋，方法是讓使用者確認現有的裝置憑證 (PIN 碼/圖案/密碼)，或新增由 TEE 保護的裝置憑證；Android 開放原始碼專案實作會在架構中提供相關機制。
請務必不要讓第三方應用程式區分個別指紋。
必須遵循 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT 標記。
從 Android 6.0 以下版本升級時，必須將指紋資料安全地遷移至符合上述要求的裝置，或將其移除。
應使用 Android 開放原始碼計畫中提供的 Android 指紋圖示。

7.4. 資料連線

7.4.1. 電話通訊系統

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

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

7.4.2. IEEE 802.11 (Wi-Fi)

Android TV 裝置實作方式必須支援 Wi-Fi。

Android TV 裝置實作項目必須支援一或多種 802.11 形式 (b/g/a/n 等)，其他類型的 Android 裝置實作項目則應支援一或多種 802.11 形式。如果裝置實作內容確實支援 802.11，並將功能公開給第三方應用程式，則該裝置必須實作對應的 Android API，並符合下列條件：

必須回報硬體功能旗標 android.hardware.wifi。
必須按照 SDK 說明文件中的說明，導入多播 API [Resources, 97]。
必須支援多點傳送 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 說明文件 [Resources, 98] 中所述的對應 Android API。如果裝置實作項目支援 Wi-Fi Direct，則會符合下列條件：

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

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

Android 電視裝置實作項目必須支援 Wi-Fi 隧道直接連結設定 (TDLS)。

Android 電視裝置實作項目必須支援 Wi-Fi 隧道直接連結設定 (TDLS)，其他類型的 Android 裝置實作項目則應支援 Wi-Fi TDLS，如 Android SDK 說明文件所述 [資源, 99]。如果裝置實作確實支援 TDLS，且 WiFiManager API 已啟用 TDLS，則裝置會：

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

7.4.3. 藍牙

Android Watch 和 Automotive 實作項目必須支援藍牙。Android 電視實作項目必須支援藍牙和藍牙 LE。

Android 支援藍牙和藍牙低功耗 [資源，100]。支援藍牙和藍牙低功耗的裝置實作項目必須宣告相關的平台功能 (分別為 android.hardware.bluetooth 和 android.hardware.bluetooth_le)，並實作平台 API。裝置實作項目應導入相關的藍牙設定檔，例如 A2DP、AVCP、OBEX 等，以便裝置進行適當的處理。Android TV 裝置實作方式必須支援藍牙和藍牙 LE。

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

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

7.4.4. 近距離無線通訊

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

必須透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能 [Resources, 70]。
必須能夠透過下列 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 [Resources, 102] 產品的條碼和網址 (如果已編碼)。
- 必須能夠透過下列對等端標準和通訊協定傳送及接收資料：
  - ISO 18092
  - LLCP 1.2 (由 NFC 論壇定義)
  - SDP 1.0 (由 NFC 論壇定義)
  - NDEF 推送通訊協定 [資源，103]
  - SNEP 1.0 (由 NFC Forum 定義)
- 必須支援 Android Beam [Resources, 104]：
  - 必須實作 SNEP 預設伺服器。預設 SNEP 伺服器收到的有效 NDEF 訊息，必須使用 android.nfc.ACTION_NDEF_DISCOVERED 意圖，傳送至應用程式。在設定中停用 Android Beam 時，請務必不要停用傳入 NDEF 訊息的調度作業。
  - 必須遵循 android.settings.NFCSHARING_SETTINGS 意圖，才能顯示 NFC 分享設定 [資源，105]。
  - 必須實作 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 論壇的「連線交接版本 1.2」[資源，106] 和「使用 NFC 版本 1.0 進行藍牙安全簡易配對」[資源，107] 規格，支援將連線交接至藍牙。這類實作必須實作移轉 LLCP 服務，服務名稱為「urn:nfc:sn:handover」，用於透過 NFC 交換移轉要求/選取記錄，且必須使用藍牙物件推送設定檔進行實際的藍牙資料傳輸。基於舊版原因 (為了維持與 Android 4.1 裝置的相容性)，實作應仍接受 SNEP GET 要求，以便透過 NFC 交換交接要求/選取記錄。不過，實作本身不應傳送 SNEP GET 要求，以便執行連線移交作業。
- 在 NFC 探索模式下，必須輪詢所有支援的技術。
- 裝置喚醒、螢幕處於活動狀態且鎖定畫面解鎖時，應處於 NFC 偵測模式。

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

Android 支援 NFC 主機卡模擬 (HCE) 模式。如果裝置實作確實包含可支援 HCE 和應用程式 ID (AID) 路由的 NFC 控制器晶片組，則：

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

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

MIFARE Classic
MIFARE Ultralight
MIFARE Classic 上的 NDEF

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

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

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

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

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 網路介面) 的 IPv6 通訊。所需的 IPv6 支援層級取決於網路類型，如下所示：

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

必須預設啟用 IPv6。

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

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

7.4.6. 同步處理設定

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

7.5. 相機

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

如果裝置實作包含至少一個相機，應用程式應可同時配置 3 個位元圖，其大小等同於裝置上解析度最高的相機感應器所產生圖片的大小。

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()[Resources, 110] 方法旋轉相機螢幕，相機預覽畫面就必須根據應用程式指定的方向水平鏡像。
- 否則，預覽畫面必須沿著裝置的預設水平軸鏡射。
必須以與攝影機預覽圖像串流相同的方式，鏡像顯示後視鏡顯示的圖像。如果裝置實作不支援 postview，則這項規定顯然不適用。
不得鏡像最終擷取的靜態影像或影片串流，這些內容會傳回至應用程式回呼或儲存至媒體儲存空間。

7.5.3. 外接鏡頭

採用 USB 主機模式的裝置實作可能會支援連接至 USB 連接埠的外接相機。如果裝置支援外接相機，則會：

必須宣告平台功能 android.hardware.camera.external 和 android.hardware camera.any。
必須支援 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 說明文件 [資源, 111] 中所列的完整 Camera API。舉例來說，缺少自動對焦功能的相機仍須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 例項 (即使這與非自動對焦相機無關)。請注意，這項做法也適用於前置鏡頭。舉例來說，即使大多數前置鏡頭不支援自動對焦，API 回呼仍必須如上所述進行「偽造」。

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

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

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

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

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

7.5.5. 相機方向

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

7.6. 記憶體與儲存空間

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

Android TV 裝置必須至少有 5 GB 的非揮發性儲存空間，用於應用程式的私人資料。

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

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

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

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

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

Android API 包含下載管理工具，應用程式可使用該工具下載資料檔案 [Resources, 115]。下載管理員的裝置實作方式必須能夠將大小至少為 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 大量儲存空間，但應使用媒體傳輸通訊協定來滿足這項要求。如果裝置實作項目支援 Media Transfer Protocol，則會：

應與 Android MTP 參考主機 Android File Transfer 相容 [Resources, 116]。
應回報 0x00 的 USB 裝置類別。
應回報的 USB 介面名稱為「MTP」。

7.6.3. 合併儲存空間

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

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

7.7. USB

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

如果裝置實作包含支援周邊模式的 USB 連接埠，請遵循下列指示：

連接埠必須可連接至具有標準 Type-A 或 Type-C USB 連接埠的 USB 主機。
連接埠應使用 micro-B、micro-AB 或 Type-C USB 板型規格。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
連接埠應位於裝置底部 (依照自然方向)，或為所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，以便在裝置以連接埠朝下的方式擺放時，正確顯示畫面。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至未來的平台版本。
應實作 Android Open Accessory (AOA) API 和規格，如 Android SDK 說明文件所述。如果是 Android 手持裝置，則必須實作 AOA API。實作 AOA 規格的裝置：
- 必須宣告支援硬體功能 android.hardware.usb.accessory [Resources, 118]。
- 必須支援在首次連線至用來當作配件的 USB 主機時，建立以 AOA 通訊協定為基礎的通訊，而無須使用者變更預設的 USB 模式。
- 必須依照 Android SDK 說明文件 [資源，119] 所述導入 USB 音訊類別。
- 另外，USB 大容量儲存裝置類別也必須在 USB 大容量儲存裝置的介面說明 iInterface 字串結尾處加入「android」字串。
應實作支援，以便在 HS 嗶嗶聲和流量期間繪製 1.5 A 電流，如 USB 電池充電規格第 1.2 版所述 [資源, 120]。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本。
USB 標準裝置描述元中的 iSerialNumber 值必須等於 android.os.Build.SERIAL 的值。

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

如果裝置實作支援 USB 3.1，則應使用 Type-C USB 連接埠。
可使用非標準的通訊埠板型規格，但如果使用這種規格，必須隨附傳輸線或傳輸線，將通訊埠轉換為標準型 A 型或 C 型 USB 通訊埠。
可使用 micro-AB USB 連接埠，但如果使用這種連接埠，則應隨附一或多條可將連接埠轉換為標準型 A 或型 C USB 連接埠的傳輸線。
實作 USB 音訊類別的做法強烈建議，詳情請參閱 Android SDK 說明文件 [Resources, 119]。
必須實作 Android USB 主機 API，如 Android SDK 中的說明文件所述，並且必須宣告支援硬體功能 android.hardware.usb.host [Resources, 121]。
應在主機模式下支援裝置充電；宣傳的來源電流至少為 1.5A，如 USB Type-C 連接器的 USB Type-C 電纜和連接器規格第 1.2 版 [] 所述；或使用充電下游連接埠(CDP) 輸出電流範圍，如 Micro-AB 連接器的 USB 電池充電規格第 1.2 版 [資源，120] 所述。

7.8. 音訊

7.8.1. 麥克風

Android 手持裝置、手錶和汽車裝置的實作方式都必須包含麥克風。

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

必須回報 android.hardware.microphone 功能常數
必須符合第 5.4 節的音訊錄音規定
必須符合第 5.6 節的音訊延遲要求
強烈建議支援近超音錄影功能，如第 7.8.3 節所述

7.8.2. 音訊輸出裝置

Android Watch 裝置可能會包含音訊輸出裝置。

裝置實作內容包含喇叭，或具有音訊/多媒體輸出連接埠，用於音訊輸出週邊裝置，例如耳機或外接喇叭：

必須回報 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 公釐音訊插頭的耳機和其他音訊配件相容 [Resources, 122]，如果裝置實作包含一個或多個類比音訊埠，至少應有一組音訊埠為 4 導體 3.5 公釐音訊插孔。如果裝置實作項目有 4 導體 3.5 公釐音訊插孔，則會：

必須支援音訊播放至立體聲耳機和立體聲耳機 (含麥克風)，並應支援音訊錄製功能 (含麥克風)。
必須支援使用 CTIA 針腳排列順序的 TRRS 音訊插頭，並應支援使用 OMTP 針腳排列順序的音訊插頭。
如果裝置實作支援麥克風，則必須支援偵測已插入的音訊配件麥克風，並廣播 android.intent.action.HEADSET_PLUG，並將額外值麥克風設為 1。
應支援偵測和對應音訊插頭上麥克風和接地導體之間等效阻抗的以下 3 個範圍的鍵碼：
- 70 歐姆以下：KEYCODE_HEADSETHOOK
- 210-290 歐姆：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」，則
- 麥克風在 18.5 kHz 至 20 kHz 頻帶的平均功率響應，必須比 2 kHz 的響應低 15 dB 以下。
- 麥克風在 18.5 kHz 至 20 kHz 的頻率範圍內，以 -26 dBFS 的 19 kHz 音調測試時，未加權的訊噪比 (SNR) 不得低於 50 dB。
如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」，則揚聲器在 18.5 kHz 至 20 kHz 的平均回應必須比 2 kHz 的回應低 40 dB。

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 開放原始碼專案。

8.4. 耗電量計算

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

必須能夠追蹤硬體元件的耗電量，並將該耗電量歸因於特定應用程式。具體實作方式：
- 必須提供個別元件的電源設定檔，定義每個硬體元件的電流耗電量值，以及元件隨時間流逝而造成的電池耗電量估計值，如 Android 開放原始碼專案網站所述 [Resources, 123]。
- 所有耗電量值都必須以毫安培小時 (mAh) 為單位回報
- 如果無法將硬體元件的耗電量歸因於應用程式，則應歸因於硬體元件本身。
- 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼專案透過 uid_cputime 核心模組實作，符合這項規定。
必須透過 adb shell dumpsys batterystats 殼層指令，將這項電源用量提供給應用程式開發人員 [Resources, 124]。
必須遵循 android.intent.action.POWER_USAGE_SUMMARY 意圖，並顯示顯示此電源用量的設定選單 [Resources, 125]。

9. 安全性模型相容性

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

9.1. 權限

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

防護等級為危險的權限是執行階段權限。應用程式如果 targetSdkVersion 大於 22，就會在執行階段要求這些權限。裝置實作方式：

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

9.2. UID 和程序隔離

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

9.3. 檔案系統權限

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

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 支援多用戶環境，並提供完整的使用者隔離功能 [資源，127]。裝置實作可能會啟用多位使用者，但啟用時必須符合下列多使用者支援相關要求 [Resources, 128]：

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

9.6. 付費簡訊警告

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

9.7. 核心安全性功能

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

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

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

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

裝置實作方式：

必須將 SELinux 設為全域強制執行模式。
必須在強制模式中設定所有網域。不允許使用寬鬆模式網域，包括裝置/供應商專屬網域。
絕對不可修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 提供的 external/sepolicy 資料夾中現有的 neverallow 規則，且政策必須針對 AOSP SELinux 網域和裝置/供應商專屬網域，以所有現有 neverallow 規則進行編譯。

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

9.8. 隱私權

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

如果裝置實作具有機制，會預設透過 Proxy 伺服器或 VPN 閘道轉送網路資料流量 (例如，預先載入已授予 android.permission.CONTROL_VPN 的 VPN 服務)，則裝置實作必須先取得使用者同意，才能啟用該機制。

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

9.9. 全磁碟加密

對於未實作螢幕鎖定的 Android 裝置，此屬性為選用。

如果裝置實作支援安全鎖定畫面，並回報「true」以供 KeyguardManager.isDeviceSecure() 使用 [Resources, 131]，且不是透過 ActivityManager.isLowRamDevice() 方法回報的記憶體受限裝置，則該裝置必須支援應用程式私人資料 (/data 分割區) 的完整磁碟加密功能 [Resources, 132]，以及應用程式共用儲存空間分割區 (/sdcard 分割區) (如果是裝置的永久性、不可移除的部分)。

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

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

9.10. 通過驗證的開機程序

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

宣告平台功能旗標 android.software.verified_boot
在每個啟動序列上執行驗證
從信任根源的不可變動硬體金鑰開始驗證，並一路向上到系統分區
實作各個驗證階段，在執行下一個階段的程式碼前，先檢查下一個階段中所有位元的完整性和真實性
使用驗證演算法，其強度與 NIST 目前針對雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 的建議相同

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

自 Android 6.0 起，如果裝置實作採用的進階加密標準 (AES) 加密效能超過 50 MiB/秒，則必須支援驗證開機程序，以確保裝置完整性。如果裝置實作已推出，但未在舊版 Android 上支援經過驗證的啟動功能，則該裝置無法透過系統軟體更新新增這項功能的支援，因此不受此規定約束。

9.11. 金鑰和憑證

Android KeyStore 系統 [Resources, 133] 可讓應用程式開發人員將加密金鑰儲存在容器中，並透過 KeyChain API [Resources, 134] 或 KeyStore API [Resources, 135] 在加密運算中使用這些金鑰。

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

不應限制可產生的金鑰數量，且至少應允許匯入超過 8,192 個金鑰。
螢幕鎖定畫面驗證功能必須限制嘗試次數，並應採用 Android 開放原始碼計畫中實作的指數型退避演算法。
如果裝置實作項目支援安全鎖定畫面，且具有可實作受信任的執行環境 (TEE) 的安全硬體 (例如安全元件 (SE))，則可：
- 強烈建議您使用安全硬體備份金鑰存放區實作項目。上游 Android 開放原始碼專案提供 Keymaster 硬體抽象層 (HAL) 實作項目，可用於滿足這項需求。
- 如果裝置已實作硬體支援的 KeyStore，則必須在安全硬體中執行螢幕鎖定畫面驗證，且只有在成功驗證後，才允許使用與驗證綁定的金鑰。上游 Android 開放原始碼計畫提供的 Gatekeeper 硬體抽象層 (HAL) 可用於滿足這項需求 [Resources, 136]。

請注意，雖然上述 TEE 相關規定列為「強烈建議」，但下一個 API 版本的相容性定義預計會將這些規定改為「必要」。如果裝置實作已在較舊的 Android 版本上推出，且未在安全硬體上實作信任的作業系統，則該裝置可能無法透過系統軟體更新符合需求，因此強烈建議實作 TEE。

9.12. 資料刪除

裝置必須為使用者提供執行「恢復原廠設定」的機制，讓使用者能邏輯和實體刪除所有資料，但系統映像檔和其他分割區的資料除外，因為這些資料可視為系統映像檔的一部分。這項做法必須符合相關的資料刪除業界標準，例如 NIST SP800-88。這項 API 必須用於實作第 3.9 節「裝置管理」所述的 wipeData() API (Android 裝置管理 API 的一部分)。

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

10. 軟體相容性測試

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

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

10.1. 相容性測試套件

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

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

10.2. CTS 驗證器

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

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

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

11. 可更新軟體

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

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

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

不過，如果裝置實作內容支援不計量資料連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，則應遵守下列規定：

Android Automotive 實作項目應支援透過重新啟動進行離線更新的 OTA 下載作業。
所有其他裝置實作方式都必須支援透過重新啟動進行離線更新的 OTA 下載。

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

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

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

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

12. 文件變更記錄

下表列出本版本中相容性定義的變更摘要。

小節	異動內容摘要
依政策而異	將「encouraged」字詞的例項替換為「RECOMMENDED」
2. 裝置類型	Android Automotive 實作項目更新
3.2.2. 建構參數	新增硬體序號和版本的安全性修補程式等級
3.2.3.2. 意圖解析	將「Intent Overrides」重新命名為「Intent Resolution」，並新增與權威預設應用程式連結相關的新規定
3.3.1. 應用程式二進位檔介面	新增 Android ABI 支援功能；與 Vulkan 程式庫名稱相關的變更
3.4.1. WebView 相容性	變更 WebView 回報的使用者代理程式字串
3.7. 執行階段相容性	記憶體分配表的更新
3.8.4. 搜尋	關於 Google 助理規定的最新資訊
3.8.6。主題	新增要求，在使用者要求使用 SYSTEM_UI_FLAG_LIGHT_STATUS_BAR 標記時，支援黑色系統圖示
3.8.8。活動切換	放寬「摘要」標題數量規定。
3.8.10。透過螢幕鎖定畫面控制媒體	如需詳細資訊，請參閱 3.8.3 的「螢幕鎖定畫面媒體控制」部分。
3.9.1. 裝置佈建	包含裝置擁有者佈建和受管理的個人資料佈建的新專區
3.9.2. 受管理設定檔支援	新增一節，說明裝置必須支援受管理的設定檔功能
3.12.1. TV 應用程式	新增一節，說明 Android TV 裝置的 TV 應用程式規定
3.12.1.1. 電子節目指南	新增一節，說明 Android TV 裝置的 EPG 規定
3.12.1.2. 導覽	新增一節，說明 Android TV 裝置的 TV 應用程式導覽規定
3.12.1.3. 電視輸入應用程式連結	新增一節，說明 Android TV 裝置的電視輸入應用程式連結支援規定
5.1. 媒體轉碼器	關於支援核心媒體格式和解碼的更新。
5.1.3. 視訊轉碼器	與 Android 電視相關的變更和新增內容
5.2. 影片編碼	編碼器異動
5.3. 影片解碼	解碼器異動，包括支援動態影片解析度、畫面更新率切換等功能
5.4. 音訊錄製	新增音訊擷取相關內容
5.6. 音訊延遲	關於低延遲音訊支援功能的回報更新
5.10. 專業音訊	專業音訊支援的一般更新；行動裝置 (插孔) 規格、USB 音訊主機模式和其他更新
5.9. 樂器數位介面 (MIDI)	新增有關選用樂器數位介面 (MIDI) 支援功能的新章節
6.1. 開發人員工具	支援 Windows 10 的驅動程式更新
7.1.1.3. 螢幕密度	螢幕密度更新 (例如與 Android 智慧手錶相關的更新)
7.2.3. 瀏覽鍵	針對包含輔助動作的裝置實作項目更新規定
7.3. 感應器 (和子項)	部分感應器類型的新規定
7.3.9. 高精確度感應器	新增一節，說明支援高保真感應器的裝置相關規定
7.3.10. 指紋感應器	新增指紋感應器相關規定的章節
7.4.2. IEEE 802.11 (Wi-Fi)	關於多點傳送 DNS (mDNS) 支援功能的更新
7.4.3. 藍牙	新增與藍牙低功耗 (BLE) 的 Resolvable Private Address (RPA) 相關的內容
7.4.4. 近距離無線通訊	近距離無線通訊 (NFC) 相關規定的額外規定
7.4.5. 最低網路功能	新增 IPv6 支援規定
7.6.3. 合併儲存空間	實作可採用儲存空間的新專區
7.7. USB	與實作 AOA 規格相關的要求
7.8.3. 近場超音波	新增與近超音波錄製、播放和音訊相關的內容	放寬近超音麥克風的信噪比 (SNR) 規定。
8.3.省電模式	新增一節，說明應用程式待命和打盹模式的相關規定
8.4. 耗電量計算	新增一節，說明如何追蹤硬體元件的電力使用情形，並將電力使用情形歸因於特定應用程式
9.1. 權限	權限規定的額外規定
9.7. 核心安全性功能	SE Linux 更新
9.8. 隱私權	新增使用者同意聲明，允許使用者透過 USB 連接埠存取共用儲存空間
9.9. 全磁碟加密	全磁碟加密相關規定
9.10. 通過驗證的開機程序	驗證啟動的其他規定
9.11. 金鑰和憑證	新增關於金鑰和憑證的規定
9.12. 資料刪除	新增「恢復原廠設定」專區
11. 可更新軟體	與裝置擁有者設定的系統更新政策相關的規定