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

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

Android 5.1 相容性定義

1. 簡介

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

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

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

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

如果這個定義或第 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 實作項目必須支援 uiMode = UI_MODE_TYPE_CAR [Resources, 111]。

所有不屬於上述任何裝置類型的 Android 裝置實作，仍須符合本文件中的所有要求，才能與 Android 5.1 相容，除非該要求明確說明僅適用於上述特定的 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, 5] 或任何在上游 Android 原始碼中加上「@SystemApi」標記的 API 所公開的任何已記錄 API。

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

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

3.2. 軟性 API 相容性

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

3.2.1. 權限

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

3.2.2. 建構參數

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

參數	詳細說明
VERSION.RELEASE	目前執行的 Android 系統版本，以人類可讀的格式表示。這個欄位必須含有 [Resources, 8] 中定義的字串值。
VERSION.SDK	目前執行的 Android 系統版本，以第三方應用程式程式碼可存取的格式呈現。對於 Android 5.1，這個欄位必須有整數值 22。
VERSION.SDK_INT	目前執行的 Android 系統版本，以第三方應用程式程式碼可存取的格式呈現。對於 Android 5.1，這個欄位必須有整數值 22。
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:5.1/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。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。

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://」的瀏覽器篩選器更為明確。裝置實作必須提供使用者介面，讓使用者修改意圖的預設活動。

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 [Resources, 10]，則必須遵循 android.settings.HOME_SETTINGS 意圖，以便顯示主畫面的預設應用程式設定選單 [Resources, 10]
如果裝置實作項目回報 android.hardware.telephony，則必須提供設定選單，以便呼叫 android.provider.Telephony.ACTION_CHANGE_DEFAULT 意圖，顯示對話方塊以便變更預設的簡訊應用程式 [Resources, 9]
如果裝置實作項目回報 android.hardware.nfc.hce [Resources, 10]，則必須遵循 android.settings.NFC_PAYMENT_SETTINGS 意圖，顯示感應付款的預設應用程式設定選單。

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，請參閱 docs/ 目錄中的「NDK 程式設計師指南 | ABI 管理」
應使用上游 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, 11] 函式符號，如 NDK 版本 android-21 中所定義。雖然必須提供所有符號，但只有裝置實際支援的 OpenGL ES 版本和擴充功能，才需要完全實作對應的函式。

原生程式碼的相容性很難處理。因此，我們強烈建議裝置實作者使用上游 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, 12]。由於無法為網頁轉譯系統開發完整的測試套件，因此裝置導入者必須在 WebView 實作中使用特定的上游 Chromium 版本。具體違規事項如下：

裝置 android.webkit.WebView 實作項目必須以 Android 5.1 的 Android 開放原始碼專案上游 Chromium 版本為基礎。這個版本包含 WebView 的特定功能和安全性修正項目 [資源, 13]。
WebView 回報的使用者代理程式字串必須採用下列格式：
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE 的值相同。
- 您可以省略 $(WEBVIEW) 字串，但如果要加入，則必須是「wv」，以便指出這是 Webview
- $(MODEL) 字串的值必須與 android.os.Build.MODEL 的值相同。
- $(BUILD) 字串的值必須與 android.os.Build.ID 的值相同。
- $(CHROMIUM_VER) 字串的值必須是上游 Android 開放原始碼專案中的 Chromium 版本。
- 裝置實作可能會在使用者代理程式字串中省略「Mobile」。

WebView 元件應盡可能支援 HTML5 功能，如果支援該功能，則應符合 HTML5 規範 [Resources, 14]。

3.4.2. 瀏覽器相容性

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

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

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

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

應用程式快取/離線作業 [Resources, 15]
<video> 標記 [資源，16]
geolocation [Resources, 17]

此外，裝置實作必須支援 HTML5/W3C webstorage API [Resources, 18]，且應支援 HTML5/W3C IndexedDB API [Resources, 19]。請注意，由於網路開發標準機構正在轉向以 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 的應用程式 (透過 <uses-library> 機制) 才會受到這些 API 記憶體用量增加的影響。

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

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

3.7. 執行階段相容性

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

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

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

螢幕版面配置	螢幕密度	應用程式記憶體下限
小/正常	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi
	320 dpi (xhdpi)	80MB
	400 dpi (400dpi)	96MB
	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
	400 dpi (400dpi)	192MB
	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
	400 dpi (400dpi)	288MB
	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, 21]，這是一項強烈建議在手持裝置實作中支援的功能。支援在主畫面上嵌入小工具的裝置實作必須符合下列規定，並宣告支援平台功能 android.software.app_widgets。

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

3.8.3. 通知

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

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

此外，實作方式必須正確轉譯 API [「Resources, 23」] 或「Status/System Bar icon style guide」[「Resources, 24」] 中提供的所有資源 (圖示、動畫檔案等)，因為在 Android TV 裝置的情況下，系統可能不會顯示通知。裝置導入者可提供與 Android 開放原始碼參考導入方式不同的通知使用者體驗，但這類替代通知系統必須支援現有的通知資源，如上所述。

Android 支援各種通知，例如：

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

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

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

3.8.4. 搜尋

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

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

3.8.5. 浮動式訊息

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

3.8.6。主題

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

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

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

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

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

3.8.7. 動態桌布

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

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

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

3.8.8。活動切換

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

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

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

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

3.8.9。輸入管理

Android 支援輸入管理功能，並支援第三方輸入方法編輯器 [Resources, 34]。允許使用者在裝置上使用第三方輸入法功能的裝置實作，必須宣告平台功能 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 已淘汰，改用媒體通知範本，讓媒體應用程式可與螢幕鎖定畫面上顯示的播放控制項整合 [Resources, 35]。支援螢幕鎖定畫面的裝置實作 (除非是 Android Automotive 或 Watch 實作)，必須顯示螢幕鎖定畫面通知，包括媒體通知範本。

3.8.11. 夢境

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

3.8.12. 位置

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

3.8.13. Unicode 和字型

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

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, 39]。裝置實作項目必須提供 DevicePolicyManager 類別的實作項目 [Resources, 40]。支援 PIN 碼 (數字) 或密碼 (數字和英文字母) 的裝置實作，必須支援 Android SDK 說明文件 [資源，39] 中定義的所有裝置管理政策，並回報平台功能 android.software.device_admin。

裝置實作可能會預先安裝應用程式，用於執行裝置管理功能，但此應用程式不得預設為裝置擁有者應用程式 [Resources, 41]。

3.10. 無障礙設定

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

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

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

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

3.11. 文字轉語音

Android 包含 API，可讓應用程式使用文字轉語音 (TTS) 服務，並讓服務供應商提供 TTS 服務的實作項目 [Resources, 45]。回報 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 電視裝置實作必須支援電視輸入架構 [資源, 46]。

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

4. 應用程式封裝相容性

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

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

5. 多媒體相容性

5.1. 媒體轉碼器

除了本文件明確允許的情況外，裝置實作方式必須支援 Android SDK 說明文件 [Resources, 50] 中指定的核心媒體格式。具體來說，裝置實作必須支援下表中定義並透過 MediaCodecList 回報的媒體格式、編碼器、解碼器、檔案類型和容器格式 [Resources,112]。裝置實作項目也必須能夠解碼 CamcorderProfile 中回報的所有設定檔 [Resources, 113]。所有這些編解碼都會以軟體實作方式提供，並在 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 設定檔 (增強型 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. 視訊轉碼器

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

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

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

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

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

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

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

5.2. 影片編碼

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

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

	SD (低畫質)	SD (高畫質)	HD 720p1	HD 1080p1
影片解析度	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 720p1	HD 1080p1
影片解析度	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.264 解碼器的 Android 裝置實作項目必須支援基準設定檔第 3 級和下列 SD 視訊解碼設定檔，並應支援 HD 解碼設定檔。Android 電視裝置必須支援高畫質等級 4.2 和 HD 1080p 解碼設定檔。

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

1 此為 Android 電視裝置實作項目的必要條件，但其他裝置類型則僅在硬體支援時才適用。

2 這是 Android TV 裝置導入作業的必要條件。

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

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

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

2 這是 Android TV 裝置導入作業的必要條件。

根據第 5.1.3 節的說明，Android 裝置實作必須支援 VP9 編解碼器，且應支援 HD 解碼設定檔。強烈建議 Android TV 裝置支援 HD 1080p 解碼設定檔，並應支援 UHD 解碼設定檔。支援 UHD 影片解碼設定檔時，必須支援 8 位元色彩深度。

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

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

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

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

	SD (低畫質)	SD (高畫質)	HD 720p 1	HD 1080p 2	UHD 2
影片解析度	352 x 288 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片影格速率	30 fps	30 fps	30 fps	30 fps	30 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
聲道：立體聲

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 的範圍內。
在麥克風上，1Khz 的總諧波失真率應低於 1%，SPL 輸入音量為 90 dB。
如有雜訊抑制處理功能，則必須停用。
自動增益控制 (如有) 必須停用

如果平台支援針對語音辨識調整的噪音抑制技術，則必須透過 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, 52]。聲明 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 編碼資料影格之間的間隔。
冷輸入延遲。當音訊輸入系統在請求前處於閒置狀態並關閉電源時，第一個影格的輸入延遲時間和輸入時間損失總和。
持續輸入延遲。裝置擷取音訊時，後續影格輸入的延遲時間。
冷輸出抖動。冷輸出延遲值的個別測量值之間的差異。
冷輸入抖動。冷輸入延遲值的個別測量值之間的差異。
連續往返延遲時間。連續輸入延遲時間加上連續輸出延遲時間加上 5 毫秒。
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 類別 [Resources, 53] 回報 android.hardware.audio.low_latency 功能，以便回報低延遲音訊。相反地，如果裝置實作不符合這些要求，則不得回報支援低延遲音訊。

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

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

5.7. 網路協定

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

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

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) 顯示器，符合這項規定。

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

6.1. 開發人員工具

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

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

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

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

Dalvik 偵錯監視器服務 (ddms) [資源，57]

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

Monkey [資源, 58]

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

SysTrace [Resources, 59]

裝置實作項目必須支援 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 9 的 32 位元和 64 位元版本。

6.2. 開發人員選項

Android 提供開發人員支援，讓他們設定應用程式開發相關設定。裝置實作項目必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，才能顯示應用程式開發相關設定 [Resources, 60]。上游 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, 53]

7.1. 顯示和圖形

Android 包含自動調整應用程式資產和 UI 版面配置的設施，可根據裝置自動調整，確保第三方應用程式能在各種硬體設定下順利執行 [Resources, 61]。裝置必須正確實作這些 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 說明文件 [資源, 61] 中定義，並由上游 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)
400 dpi (400dpi)
480 dpi (xxhdpi)
560 dpi (560dpi)
640 dpi (xxxhdpi)

裝置實作應定義標準 Android 架構密度，這個密度在數值上應與螢幕的實體密度最接近，除非邏輯密度會使回報的螢幕大小低於最低支援值。如果標準 Android 架構密度與實際密度數值最接近，導致螢幕大小小於最小支援的螢幕尺寸 (320 dp 寬度)，裝置實作應回報下一個最低的標準 Android 架構密度。

7.1.2. 顯示指標

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

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, 63]。

裝置實作項目也必須正確識別自己是否支援 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, 64] 和原生支援的進階圖形功能，例如平鋪和 ASTC 紋理壓縮格式。Android 裝置實作項目可能會支援這個擴充功能包，但只有在完全實作時，才須透過 android.hardware.opengles.aep 功能旗標識別支援。

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

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

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

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

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

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

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

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, 67]。

7.2. 輸入裝置

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

7.2.1. 鍵盤

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

裝置實作方式：

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

7.2.2. 非觸控導覽

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

裝置實作方式：

如果裝置實作不是 Android TV 裝置，則可省略非觸控導覽選項 (軌跡球、D-Pad 或方向盤)。
必須回報 android.content.res.Configuration.navigation 的正確值 [Resources, 68]。
必須提供合理的替代使用者介面機制，用於選取及編輯文字，且必須與輸入管理引擎相容。上游 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 5.0 以上版本的新裝置實作項目不得實作專屬的選單按鈕。較舊的裝置實作項目不應為選單功能實作專屬實體按鈕，但如果實作實體選單按鈕，且裝置執行的應用程式 targetSdkVersion 大於 10，則裝置實作項目：

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

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

Android 支援輔助動作 [Resources, 69]。除了 Android Watch 裝置外，執行應用程式時，Android 裝置實作項目必須隨時向使用者提供 Assist 動作。輔助動作應以長按主畫面按鈕或在軟體主畫面按鈕上向上滑動的手勢實作。這項功能可透過其他實體按鈕、軟體鍵或手勢實作，但在其他導覽鍵可見時，必須能透過單一動作 (例如輕觸、雙擊或手勢) 存取。

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

裝置實作導覽鍵時，必須使用螢幕的獨立部分 (應用程式無法使用)，且不得遮蓋或以其他方式干擾應用程式可用的螢幕部分。
裝置實作必須將部分螢幕畫面提供給符合第 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, 68] 的值，對應至裝置上特定觸控螢幕的類型。

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

宣告支援 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)
方向鍵向上¹ 方向鍵向下¹	0x01 0x0039³	AXIS_HAT_Y⁴
向左鍵1 方向鍵右¹	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 [資源, 72]

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

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

4 [Resources, 71]

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

7.2.7. 遙控器

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

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

7.3. 感應器

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

必須根據 android.content.pm.PackageManager 類別 [Resources, 53] 準確回報感應器是否存在。
必須透過 SensorManager.getSensorList() 和類似方法，傳回正確的支援感應器清單。
必須針對所有其他感應器 API 合理運作 (例如，在應用程式嘗試註冊事件監聽器時，視情況傳回 true 或 false，在沒有對應感應器時不呼叫感應器事件監聽器，等等)。
必須使用 Android SDK 說明文件 [Resources, 74] 中定義的每種感應器類型的相關國際單位制值，回報所有感應器測量值。
應以 Android SDK 說明文件中定義的奈秒為單位回報事件時間，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘同步。我們強烈建議現有和新款 Android 裝置符合這些規定，以便升級至日後的平台版本，因為這可能會成為必要元件。同步處理錯誤應低於 100 毫秒 [Resources, 75]。

上述清單並非完整列出所有行為；Android SDK 的行為說明和 Android 開放原始碼說明文件 (關於感應器) [Resources, 73] 應視為權威來源。

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

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

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

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

7.3.1. 加速計

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

必須實作並回報 TYPE_ACCELEROMETER 感應器 [Resources, 78]。
針對 Android Watch 裝置，必須能夠回報至少 50 Hz 的事件頻率 (此類裝置的電力限制較嚴格)，而其他裝置類型則為 100 Hz。
應回報的事件頻率應至少為 200 Hz。
必須遵循 Android 感應器座標系統，詳情請參閱 Android API [Resources, 74]。
必須能夠在任何軸線上，測量從自由落體到重力 (4g) 或更大的加速度。
解析度必須至少為 8 位元，且應至少為 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, 74]。
必須能夠在飽和前，測量每個軸上的 -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.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 說明文件 [Resources, 79] 所述，實作多播 API。
必須支援多點傳送 DNS (mDNS)，且不得在任何運作期間過濾 mDNS 封包 (224.0.0.251)，包括螢幕處於非活動狀態時。

7.4.2.1. Wi-Fi Direct

裝置實作應支援 Wi-Fi Direct (Wi-Fi 點對點)。如果裝置實作確實支援 Wi-Fi Direct，則必須實作對應的 Android API，如 SDK 說明文件所述 [Resources, 80]。如果裝置實作項目支援 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 TV 裝置實作項目必須支援 Wi-Fi 隧道直接連結設定 (TDLS)，其他類型的 Android 裝置實作項目則應支援 Wi-Fi TDLS，詳情請參閱 Android SDK 說明文件 [資源, 81]。如果裝置實作確實支援 TDLS，且 WiFiManager API 已啟用 TDLS，則裝置會：

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

7.4.3. 藍牙

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

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

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

必須宣告硬體功能 android.hardware.bluetooth_le。
必須啟用 GATT (通用屬性設定檔) 的藍牙 API，如 SDK 說明文件和 [資源, 82] 所述。
實作 ScanFilter API 時，應支援將篩選器邏輯卸載至藍牙晶片組，並在透過 android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() 方法查詢時，回報正確的值，指出篩選器邏輯實作的位置。[Resources, 83]
應支援將批次掃描卸載至藍牙晶片組，但如果不支援，則在透過 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, 53]。
必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：
- 必須能夠透過下列 NFC 標準，充當 NFC Forum 讀取器/寫入器 (依 NFC Forum 技術規格 NFCForum-TS-DigitalProtocol-1.0 定義)：
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS 6319-4)
  - IsoDep (ISO 14443-4)
  - NFC Forum 標記類型 1、2、3、4 (由 NFC Forum 定義)
- 應可透過下列 NFC 標準讀取及寫入 NDEF 訊息。請注意，雖然下列 NFC 標準列為「建議」，但未來版本的相容性定義預計會將這些標準變更為「必須」。這些標準在本版本中為選用標準，但在日後版本中將為必要標準。對於執行此 Android 版本的現有裝置和新裝置，我們強烈建議立即符合這些要求，以便日後升級至平台新版本。
- 必須能夠透過下列對等端標準和通訊協定傳送及接收資料：
  - ISO 18092
  - LLCP 1.0 (由 NFC 論壇定義)
  - SDP 1.0 (由 NFC 論壇定義)
  - NDEF 推送通訊協定 [資源，84]
  - SNEP 1.0 (由 NFC Forum 定義)
- 必須支援 Android Beam [Resources, 85]：
  - 必須實作 SNEP 預設伺服器。預設 SNEP 伺服器收到的有效 NDEF 訊息，必須使用 android.nfc.ACTION_NDEF_DISCOVERED 意圖，傳送至應用程式。在設定中停用 Android Beam 時，請務必不要停用傳入 NDEF 訊息的調度作業。
  - 必須遵循 android.settings.NFCSHARING_SETTINGS 意圖，才能顯示 NFC 分享設定 [資源, 86]。
  - 必須實作 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」[Resources, 87] 和「Bluetooth Secure Simple Pairing Using NFC version 1.0」[Resources, 88] 規格，支援將連線交接給藍牙。這類實作必須實作移轉 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, 10]。

此外，裝置實作項目可能會針對下列 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, 53]。請注意，這不是標準的 Android 功能，因此不會顯示為 PackageManager 類別的常數。
除非也實作一般 NFC 支援功能 (如本節所述)，否則絕對不得實作對應的 Android API 或回報 com.nxp.mifare 功能。

如果裝置實作不包含 NFC 硬體，則不得透過 android.content.pm.PackageManager.hasSystemFeature() 方法 [Resources, 53] 宣告 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)。

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

7.4.6. 同步處理設定

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

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, 90] 方法，明確要求旋轉相機螢幕，則相機預覽畫面必須根據應用程式指定的方向水平鏡像。
- 否則，預覽畫面必須沿著裝置的預設水平軸鏡射。
必須以與攝影機預覽圖像串流相同的方式，鏡像顯示後視鏡顯示的圖像。如果裝置實作不支援 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 說明文件 [Resources, 91] 中所列的完整 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, 92]。

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

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

每當相機拍攝新相片，且相片項目已新增至媒體儲存區時，裝置實作方式都必須廣播 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, 95]。下載管理員的裝置實作方式必須能夠將大小至少為 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, 96]。
應回報 0x00 的 USB 裝置類別。
應回報的 USB 介面名稱為「MTP」。

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, 97] 硬體功能。
- 必須依照 Android SDK 文件 [資源，98]中所述導入 USB 音訊類別。
應實作支援，以便在 HS 嗶嗶聲和流量期間繪製 1.5 A 電流，如 USB 電池充電規格第 1.2 版所述 [資源, 99]。我們強烈建議現有和新款 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, 98]。強烈建議。
必須實作 Android SDK 說明中的 Android USB 主機 API，且必須宣告支援 android.hardware.usb.host 硬體功能 [資源, 100]。
應支援充電下游埠輸出電流範圍 1.5 A ~ 5 A，如 USB 電池充電規格第 1.2 版所述 [資源，99]。

7.8. 音訊

7.8.1. 麥克風

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

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

必須回報 android.hardware.microphone 功能常數
必須符合第 5.4 節的音訊錄音規定
必須符合第 5.6 節的音訊延遲要求

7.8.2. 音訊輸出裝置

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

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

必須回報 android.hardware.audio.output 功能常數。
必須符合第 5.5 節的音訊播放規定。
必須符合第 5.6 節的音訊延遲要求。

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

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

7.8.2.1. 類比音訊埠

為了與 Android 生態系統中使用 3.5 公釐音訊插頭的耳機和其他音訊配件相容 [資源，101]，如果裝置實作包含一個或多個類比音訊埠，至少應有一組音訊埠為 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 之間。

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。

9. 安全性模型相容性

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

9.1. 權限

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

9.2. UID 和程序隔離

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

9.3. 檔案系統權限

裝置實作項目必須支援「安全性和權限」參考資料中定義的 Android 檔案存取權限模式 [Resources, 102]。

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

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

9.6. 付費簡訊警告

Android 支援警告使用者任何傳送的付費簡訊 [資源，106]。付費簡訊是傳送至電信業者註冊服務的簡訊，可能會向使用者收費。宣告支援 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 不得允許會破壞相容性的設定。

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

裝置實作方式：

必須支援 SELinux 政策，允許依網域設定 SELinux 模式，且必須以強制模式設定所有網域。不允許使用寬鬆模式網域，包括特定裝置/供應商的網域。
應從裝置上的 /sepolicy 檔案載入政策。
絕對不可修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 提供的 sepolicy 檔案中所列的 neverallow 規則，且政策必須針對 AOSP SELinux 網域和裝置/供應商專屬網域，以所有 neverallow 規則編譯。
必須支援 SELinux 政策檔案的動態更新，且不必更新系統映像檔。

裝置實作項目應保留上游 Android 開放原始碼計畫中提供的預設 SELinux 政策，直到對 SELinux 政策的新增項目進行審查為止。裝置實作項目必須與上游 Android 開放原始碼計畫相容。

9.8. 隱私權

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

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

9.9. 全磁碟加密

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

如果裝置實作項目支援 PIN 碼 (數字) 或密碼 (英數字) 的鎖定畫面，則裝置必須支援應用程式私人資料 (/data 分割區) 的完整磁碟加密功能，以及 SD 卡分割區 (如果是裝置的永久性、不可移除的部分) [Resources, 107]。對於支援全磁碟加密的裝置，在使用者完成開箱體驗後，應一律啟用全磁碟加密功能。雖然此項要求在 Android 平台的這個版本中列為「應」遵循，但我們強烈建議您遵循這項規定，因為我們預計在日後的 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 平台對此規定為「應」遵循，但我們強烈建議您遵循此規定，因為我們預計在日後的 Android 版本中將此規定改為「必須」遵循。上游 Android 開放原始碼專案提供這項功能的首選實作方式，以 Linux 核心功能 dm-verity 為基礎。

10. 軟體相容性測試

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

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

10.1. 相容性測試套件

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

CTS 設計用於在實際裝置上執行。和任何軟體一樣，CTS 本身可能也會含有錯誤。CTS 的版本會與此相容性定義獨立運作，且 Android 5.1 可能會發布多個 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 5.1 以上版本的裝置實作，更新機制應支援驗證系統映像檔是否與 OTA 後的預期結果相同。自 Android 5.1 版起新增的源端 Android 開放原始碼計畫中的區塊式 OTA 實作，可滿足這項需求。

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

12. 文件變更記錄

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

小節	異動摘要
2. 裝置類型	新增 Android 汽車實作項目的定義。
2.1 裝置設定	新增 Android 汽車用車輛實作項目的欄。
3.3.2. 32 位元 ARM 原生程式碼相容性	新增了新版面。
3.4.1. WebView 相容性	更新 WebView 使用者代理程式字串規定，以便配合上游實作變更。
3.4.2. 瀏覽器相容性	新增 Android 汽車實作項目，做為另一個可能省略瀏覽器應用程式的情況。
3.7. 執行階段相容性	針對較小的螢幕更新所需的執行階段堆積大小，並新增新 dpi 桶 (280 dpi) 的必要條件。
3.8.3. 通知	針對 Android Watch、電視和 Automotive 實作項目的通知規定做出更明確的說明。
3.8.8。活動切換	放寬總覽標題數量規定。
3.8.10。透過螢幕鎖定畫面控制媒體	明確說明 Android Watch 和 Automotive 實作項目的相關規定。
3.8.13. Unicode 和字型	放寬表情符號輸入方式的要求。
3.9. 裝置管理	明確指出必須支援完整的裝置管理政策時的條件。
3.10. 無障礙設定	新增 Android Automotive 相關規定。
3.11. 文字轉語音	新增 Android Automotive 相關規定。
5.1. 媒體轉碼器	針對 CamcorderProfile 回報的編解碼器，強制支援解碼。
5.1.3 視訊轉碼器	新增 Android Automotive 相關規定。
5.4. 音訊錄製	在章節開頭處使用更明確的用語，確保「必須」要求會被解讀為「必要」。
7.1.1.3. 螢幕密度	新增螢幕 dpi (280 dpi)。
7.1.5. 舊版應用程式相容性模式	新增 Android Automotive 相關規定。
7.2 輸入裝置	新增一般介紹陳述式。
7.2.1. 鍵盤	新增 Android Automotive 相關規定。
7.2.3. 瀏覽鍵	新增 Android Automotive 相關規定。
7.3.1. 加速計	放寬 Android 手錶回報頻率規定。
7.3.4. 陀螺儀	放寬 Android 手錶回報頻率規定。
7.4.3 藍牙	新增 Android Automotive 相關規定。
7.4.4. 近距離無線通訊	明確指出主機卡模擬功能的必要條件。
7.6.1. 記憶體和儲存空間最低需求	針對解析度較低的螢幕裝置更新記憶體最低需求，並新增硬性限制需求 isLowRamDevice()。
7.6.2. 應用程式共用儲存空間	更新必須支援主機電腦存取權的必要條件。
7.7 USB	修正 USB 部分的錯字
7.6.2. 應用程式共用儲存空間	更新規定，讓預先安裝的系統應用程式可寫入次要外部儲存空間。
7.6.2. 應用程式共用儲存空間	應用程式可以使用 ACTION_OPEN_DOCUMENT_TREE 寫入次要外部儲存空間
7.6.2. 應用程式共用儲存空間	說明 /sdcard 可以與 /data 共用儲存空間
7.7 USB	從 7.7 版移除 UMS/MTP 的多餘要求
7.8.1. 麥克風	新增 Android Automotive 相關規定。
8.2. 檔案 I/O 存取效能	明確說明規定。
9.5. 支援多位使用者	主要外部儲存空間需要 SD 卡加密。
9.8. 隱私權	新增預先載入 VPN 的隱私權規定。
9.9. 全磁碟加密	明確指出必須支援全磁碟加密功能的條件。
9.10. 通過驗證的開機程序	澄清驗證開機程序的定義。
11. 可更新軟體	澄清 OTA 下載要求可允許，但並非 Android Automotive 實作項目的必要條件。