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

Android 4.4 相容性定義

修訂版 1
最後更新時間：2013 年 11 月 27 日

一、簡介

本文檔列舉了裝置與 Android 4.4 相容必須滿足的要求。

「必須」、「不得」、「必需」、「應」、「不應」、「應該」、「不應該」、「建議」、「可以」和「可選」的使用符合 IETF 標準RFC2119 [參考資料, 1 ] 中定義。

在本文檔中，「裝置實現者」或「實現者」是指開發運行 Android 4.4 的硬體/軟體解決方案的個人或組織。「設備實現」或「實現」是這樣開發的硬體/軟體解決方案。

要被視為與 Android 4.4 相容，裝置實作必須滿足此相容性定義中提出的要求，包括透過引用合併的任何文件。

如果第 10 節中所述的此定義或軟體測試是沉默的、不明確的或不完整的，則設備實現者有責任確保與現有實現的兼容性。

因此，Android 開源專案 [參考資料, 3 ] 既是 Android 的參考實現，也是首選實現。強烈鼓勵設備實現者最大程度地基於 Android 開源專案提供的「上游」原始程式碼來實現其實現。雖然假設某些組件可以替換為替代實現，但強烈建議不要這樣做，因為通過軟體測試將變得更加困難。實作者有責任確保與標準 Android 實作完全行為相容，包括相容性測試套件。最後，請注意，本文檔明確禁止某些組件替換和修改。

2. 資源

IETF RFC2119 要求等級： http://www.ietf.org/rfc/rfc2119.txt

Android 相容性計劃概述： http://source.android.com/docs/compatibility/index.html

Android 開源專案：http: //source.android.com/

API定義與文件： http://developer.android.com/reference/packages.html

Android 權限參考： http://developer.android.com/reference/android/Manifest.permission.html

android.os.Build 參考： http://developer.android.com/reference/android/os/Build.html

Android 4.4 允許的版本字串： http://source.android.com/docs/compatibility/4.4/versions.html

渲染腳本： http://developer.android.com/guide/topics/graphics/renderscript.html

硬體加速： http://developer.android.com/guide/topics/graphics/hardware-accel.html

android.webkit.WebView 類別： http://developer.android.com/reference/android/webkit/WebView.html

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

HTML5 離線功能： http://dev.w3.org/html5/spec/Overview.html#offline

HTML5 影片標籤： http://dev.w3.org/html5/spec/Overview.html#video

HTML5/W3C 地理定位 API： http://www.w3.org/TR/geolocation-API/

HTML5/W3C 網路儲存 API： http://www.w3.org/TR/webstorage/

HTML5/W3C IndexedDB API： http://www.w3.org/TR/IndexedDB/

Dalvik 虛擬機器規格：可在 Android 原始碼中找到，位於 dalvik/docs

應用程式小工具： http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

通知： http ://developer.android.com/guide/topics/ui/notifiers/notifications.html

應用程式資源： http://code.google.com/android/reference/available-resources.html

狀態列圖示樣式指南： http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

搜尋管理員： http://developer.android.com/reference/android/app/SearchManager.html

吐司：http: //developer.android.com/reference/android/widget/Toast.html

主題：http: //developer.android.com/guide/topics/ui/themes.html

R.style類別： http://developer.android.com/reference/android/R.style.html

動態桌布： https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Android 裝置管理： http://developer.android.com/guide/topics/admin/device-admin.html

DevicePolicyManager參考： http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

Android 輔助使用服務 API： http://developer.android.com/reference/android/accessibilityservice/package-summary.html

Android 輔助使用 API： http://developer.android.com/reference/android/view/accessibility/package-summary.html

眼睛免費項目：http: //code.google.com/p/eyes-free

文字轉語音 API： http://developer.android.com/reference/android/speech/tts/package-summary.html

參考工具文件（針對adb、aapt、ddms、systrace）：http: //developer.android.com/guide/developing/tools/index.html

Android apk 檔案說明： http://developer.android.com/guide/topics/fundamentals.html

清單檔案： http://developer.android.com/guide/topics/manifest/manifest-intro.html

Monkey測試工具： https://developer.android.com/studio/test/other-testing-tools/monkey

Android android.content.pm.PackageManager 類別和硬體功能清單： http://developer.android.com/reference/android/content/pm/PackageManager.html

支援多畫面： http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration： http://developer.android.com/reference/android/content/res/Configuration.html

android.hardware.SensorEvent： http://developer.android.com/reference/android/hardware/SensorEvent.html

藍牙 API： http://developer.android.com/reference/android/bluetooth/package-summary.html

NDEF 推播協定： http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X： http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X： http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1： http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2： http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511： http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411： http://www.nxp.com/documents/application_note/AN130411.pdf

相機方向API： http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

相機： http://developer.android.com/reference/android/hardware/Camera.html

Android 開放配件： http://developer.android.com/guide/topics/usb/accessory.html

USB 主機 API： http://developer.android.com/guide/topics/usb/host.html

Android 安全與權限參考： http://developer.android.com/guide/topics/security/permissions.html

適用於 Android 的應用程式：http: //code.google.com/p/apps-for-android

Android 下載管理器： http://developer.android.com/reference/android/app/DownloadManager.html

Android 檔案傳輸：http: //www.android.com/filetransfer

Android 媒體格式： http://developer.android.com/guide/appendix/media-formats.html

HTTP 直播協議草稿： http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

NFC 連線切換： http://www.nfc-forum.org/specs/spec_list/#conn_handover

使用 NFC 進行藍牙安全簡單配對： http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

Wi-Fi 群播 API： http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

動作輔助： http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

USB 充電規格： http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

Android 光束： http://developer.android.com/guide/topics/nfc/nfc.html

Android USB 音訊： http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

Android NFC 共享設定： http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

Wi-Fi 直連（Wi-Fi P2P）： http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

鎖定與主畫面小工具： http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

使用者管理員參考： http://developer.android.com/reference/android/os/UserManager.html

外部儲存參考：https: //source.android.com/docs/core/storage

外部儲存 API： http://developer.android.com/reference/android/os/Environment.html

簡訊短代碼： http://en.wikipedia.org/wiki/Short_code

媒體遠端控制客戶端： http://developer.android.com/reference/android/media/RemoteControlClient.html

顯示管理器： http://developer.android.com/reference/android/hardware/display/DisplayManager.html

夢想： http://developer.android.com/reference/android/service/dreams/DreamService.html

Android 應用程式開發相關設定： http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

相機： http ://developer.android.com/reference/android/hardware/Camera.Parameters.html

EGL 擴充 -EGL_ANDROID_RECORDABLE： http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

運動事件 API： http://developer.android.com/reference/android/view/MotionEvent.html

觸碰輸入配置： http://source.android.com/docs/core/interaction/input/touch-devices.html

統一碼 6.1.0： http://www.unicode.org/versions/Unicode6.1.0/

WebView 相容性：http: //www.chromium.org/

Android 裝置擁有者應用程式： http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

WifiManager API： http://developer.android.com/reference/android/net/wifi/WifiManager.html

RTC 硬體編碼需求： http://www.webmproject.org/hardware/rtc-coding-requirements/

Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

內容解析器： http://developer.android.com/reference/android/content/ContentResolver.html

設定InjectorService： http://developer.android.com/reference/android/location/SettingInjectorService.html

基於主機的卡片模擬： http://developer.android.com/guide/topics/connectivity/nfc/hce.html

電話提供者： http://developer.android.com/reference/android/provider/Telephony.html

其中許多資源直接或間接源自 Android SDK，並且在功能上與該 SDK 文件中的資訊相同。在任何情況下，如果本相容性定義或相容性測試套件與 SDK 文件不一致，則 SDK 文件被視為具有權威性。上述參考文獻中提供的任何技術細節均被視為包含在本相容性定義中。

3、軟體

3.1.託管 API 相容性

託管（基於 Dalvik）執行環境是 Android 應用程式的主要工具。 Android 應用程式介面 (API) 是向在託管 VM 環境中運行的應用程式公開的一組 Android 平台介面。設備實現必須提供 Android SDK 公開的任何記錄的 API 的完整實現，包括所有記錄的行為 [參考資料，4 ]。

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

此相容性定義允許裝置實作省略 Android 包含的 API 的某些類型的硬體。在這種情況下，API 必須仍然存在並以合理的方式運行。有關此場景的具體要求，請參閱第 7 節。

3.2.軟 API 相容性

除了第 3.1 節中的託管 API 之外，Android 還包括一個重要的僅運行時「軟」API，其形式為 Intent、權限和 Android 應用程式的類似方面，這些方面無法在應用程式編譯時強制執行。

3.2.1.權限

設備實現者必須支援並強制執行權限參考頁 [參考資料，5 ] 中記錄的所有權限常數。請注意，第 9 節列出了與 Android 安全模型相關的附加要求。

3.2.2.建構參數

Android API 包含android.os.Build類別 [ Resources, 6 ] 上的許多常數，用於描述目前裝置。為了跨裝置實作提供一致、有意義的值，下表包含裝置實作必須遵守的這些值的格式的附加限制。

範圍	評論
版本.發布	目前執行的 Android 系統的版本，採用人類可讀的格式。該欄位必須具有 [ Resources, 7 ] 中定義的字串值之一。
版本.SDK	目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.4，此欄位必須具有整數值 19。
版本.SDK_INT	目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.4，此欄位必須具有整數值 19。
版本.增量	裝置實現者選擇的值，以人類可讀的格式指定目前正在執行的 Android 系統的特定版本。該值不得重複用於向最終用戶提供的不同建置。此欄位的典型用途是指示使用哪個版本號或原始碼控制變更標識符來產生版本。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
木板	設備實現者選擇的值，以人類可讀的格式標識設備使用的特定內部硬體。此欄位的一個可能用途是指示為設備供電的板的特定版本。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
品牌	反映最終用戶所知的與設備相關的品牌名稱的值。必須採用人類可讀的格式，並且應該代表設備的製造商或設備銷售的公司品牌。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
CPU_ABI	本機程式碼的指令集名稱（CPU 類型 + ABI 約定）。請參閱第 3.3 節：本機 API 相容性。
CPU_ABI2	本機程式碼的第二指令集（CPU 類型 + ABI 約定）的名稱。請參閱第 3.3 節：本機 API 相容性。
裝置	設備實現者選擇的值，包含標識硬體功能配置和設備工業設計的開發名稱或代號。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
指紋	唯一標識此建置的字串。它應該是合理的人類可讀的。它必須遵循以下模板： `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` 例如： `acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys` 指紋不得包含空白字元。如果上述模板中包含的其他字段具有空白字符，則必須在構建指紋中將它們替換為另一個字符，例如下劃線（“_”）字符。此欄位的值必須可編碼為 7 位元 ASCII。
硬體	硬體的名稱（來自核心命令列或/proc）。它應該是合理的人類可讀的。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
主持人	以人類可讀格式唯一標識建構建構的主機的字串。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
ID	設備實現者選擇的標識符，用於引用特定版本，採用人類可讀的格式。該欄位可以與 android.os.Build.VERSION.INCRMENTAL 相同，但應該是一個對於最終用戶區分軟體版本足夠有意義的值。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
製造商	產品原始設備製造商 (OEM) 的商品名稱。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
模型	設備實現者選擇的值，包含最終使用者已知的設備名稱。此名稱應與設備行銷和銷售給最終用戶時使用的名稱相同。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
產品	設備實施者選擇的值，包含特定產品 (SKU) 的開發名稱或程式碼名稱，該名稱在同一品牌中應該是唯一的。必須是人類可讀的，但不一定供最終用戶查看。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
串口	必須可用的硬體序號。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^([a-zA-Z0-9]{6,20})$"` 。
標籤	由設備實現者選擇的以逗號分隔的標籤列表，可進一步區分建置。例如，“未簽名，調試”。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
時間	表示建構發生時間的時間戳記的值。
類型	由設備實現者選擇的值，指定建置的運行時配置。此欄位應該具有與三種典型 Android 運行時配置相對應的值之一：「user」、「userdebug」或「eng」。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
使用者	產生建置的使用者（或自動使用者）的名稱或使用者 ID。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。

3.2.3.意圖相容性

裝置實作必須遵循 Android 的鬆散耦合 Intent 系統，如下節所述。「榮幸」意味著裝置實現者必須提供一個 Android Activity 或 Service，指定匹配的 Intent 過濾器，並綁定到每個指定的 Intent 模式並實現正確的行為。

3.2.3.1.核心應用意圖

Android上游專案定義了一些核心應用程序，例如聯絡人、日曆、照片庫、音樂播放器等。設備實施者可以用替代版本替換這些應用程式。

但是，任何此類替代版本都必須遵循上游項目提供的相同意圖模式。例如，如果裝置包含替代音樂播放器，它仍然必須遵循第三方應用程式發出的意圖模式來選擇歌曲。

以下應用程式被視為核心 Android 系統應用程式：

英式鐘
瀏覽器
日曆
聯絡方式
畫廊
全球搜尋
啟動器
音樂
設定

Android 系統核心應用程式包括各種被視為「公共」的 Activity 或 Service 元件。也就是說，屬性「android:exported」可以不存在，或者可以有值「true」。

對於核心 Android 系統應用程式之一中定義的每個活動或服務，如果未透過值為「false」的 android:exported 屬性標記為非公開，則裝置實作必須包含實作相同 Intent 篩選器的相同類型的元件模式作為Android系統的核心應用程式。

換句話說，裝置實作可以取代核心 Android 系統應用程式；但是，如果是這樣，裝置實作必須支援每個被替換的核心 Android 系統應用程式定義的所有 Intent 模式。

3.2.3.2.意圖覆蓋

由於 Android 是一個可擴展平台，裝置實作必須允許第 3.2.3.1 節中引用的每個 Intent 模式被第三方應用程式覆蓋。上游 Android 開源實作預設允許這樣做；設備實作者不得為系統應用程式使用這些 Intent 模式附加特殊權限，或阻止第三方應用程式綁定到這些模式並承擔對這些模式的控制。該禁止具體包括但不限於停用「選擇器」使用者介面，該介面允許使用者在全部處理相同 Intent 模式的多個應用程式之間進行選擇。

但是，如果預設活動為資料 URI 提供更具體的篩選器，則裝置實作可以為特定 URI 模式（例如 http://play.google.com）提供預設活動。例如，指定資料 URI「http://www.android.com」的 Intent 過濾器比「http://」的瀏覽器過濾器更具體。設備實作必須為使用者提供一個使用者介面來修改意圖的預設活動。

3.2.3.3.意圖命名空間

裝置實作不得包含任何使用 Android.* 或 com.android.* 命名空間中的 ACTION、CATEGORY 或其他鍵字串來支援任何新 Intent 或廣播 Intent 模式的 Android 元件。裝置實現者不得包含任何使用 ACTION、CATEGORY 或屬於另一個組織的包空間中的其他鍵字串來遵循任何新 Intent 或廣播 Intent 模式的 Android 元件。設備實現者不得更改或擴展第 3.2.3.1 節中列出的核心應用程式所使用的任何 Intent 模式。設備實作可以包括使用與其自己的組織明確相關的命名空間的意圖模式。

該禁止類似於第 3.6 節中為 Java 語言類別指定的禁止。

3.2.3.4.廣播意圖

第三方應用程式依靠平台廣播某些Intent來通知它們硬體或軟體環境的變化。 Android 相容裝置必須廣播公共廣播 Intents 以回應適當的系統事件。 SDK 文件中描述了廣播意圖。

3.2.3.5.預設應用程式設定

Android 4.4 新增了允許用戶選擇預設家庭和簡訊應用程式的設定。設備實作必須為每個設備提供類似的使用者設定選單，與 SDK 文件 [參考資料，91 ] 中描述的 Intent 過濾器模式和 API 方法相容。

3.3.本機 API 相容性

3.3.1 應用程式二進位介面

Dalvik 中執行的託管程式碼可以呼叫應用程式 .apk 檔案中提供的本機程式碼，作為針對適當裝置硬體架構編譯的 ELF .so 檔案。由於本機程式碼高度依賴底層處理器技術，因此 Android 在 Android NDK 中的檔案docs/CPU-ARCH-ABIS.html中定義了許多應用程式二進位介面 (ABI)。如果裝置實現與一個或多個已定義的 ABI 相容，則它應該實現與 Android NDK 的兼容性，如下所示。

如果裝置實現包含對 Android ABI 的支持，則：

必須支援在託管環境中執行的程式碼，以使用標準 Java 本機介面 (JNI) 語義呼叫本機程式碼
必須與下面列表中每個所需的庫來源相容（即標頭相容）和二進位相容（對於 ABI）
必須透過android.os.Build.CPU_ABI API 和android.os.Build.CPU_ABI2參數精確報告設備支援的本機應用程式二進位介面 (ABI)。
必須透過android.os.Build.CPU_ABI2報告僅在最新版本的 Android NDK 中記錄的 ABI，位於文件docs/CPU-ARCH-ABIS.html中
必須透過android.os.Build.CPU_ABI報告下列 ABI 之一

armeabi-v7a
x86
米普斯

應使用上游 Android 開源專案中提供的源代碼和頭文件進行構建

以下本機程式碼 API 必須可用於包含本機程式碼的應用程式：

libc（C 庫）
libm（數學庫）
對 C++ 的最低支持
JNI介面
liblog（Android 日誌記錄）
libz（Zlib 壓縮）
libdl（動態連結器）
libGLESv1_CM.so（OpenGL ES 1.0）
libGLESv2.so（OpenGL ES 2.0）
libGLESv3.so（OpenGL ES 3.0）
libEGL.so（原生 OpenGL 表面管理）
libjnigraphics.so
libOpenSLES.so（OpenSL ES 1.0.1 音訊支援）
libOpenMAXAL.so（OpenMAX AL 1.0.1 支援）
libandroid.so（原生 Android 活動支援）
支援 OpenGL，如下所述

請注意，Android NDK 的未來版本可能會引入對其他 ABI 的支援。如果設備實作與現有的預定義 ABI 不相容，則它根本無法報告對任何 ABI 的支援。

請注意，裝置實作必須包含 libGLESv3.so，並且它必須符號連結（符號）連結到 libGLESv2.so。在聲明支援 OpenGL ES 3.0 的裝置實作上，除了 OpenGL ES 2.0 函數符號之外，libGLESv2.so 還必須匯出 OpenGL ES 3.0 函數符號。

本機程式碼相容性具有挑戰性。因此，應該重申的是，強烈鼓勵設備實現者使用上面列出的庫的上游實作來幫助確保相容性。

3.4.網路相容性

3.4.1.網頁視圖相容性

Android 開源實作使用 Chromium 專案中的程式碼來實作android.webkit.WebView [參考資料，10 ]。由於為 Web 渲染系統開發全面的測試套件是不可行的，因此設備實作者必須在 WebView 實作中使用 Chromium 的特定上游版本。具體來說：

裝置android.webkit.WebView實作必須基於 Android 4.4 的上游 Android 開源專案的 Chromium 建置。此版本包括一組針對 WebView 的特定功能和安全性修復。 [資源，83 ]
WebView 報告的用戶代理字串必須採用以下格式：
Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 字串的值必須與android.os.Build.VERSION.RELEASE的值相同。
- $(LOCALE) 字串的值是可選的，應該遵循國家代碼和語言的 ISO 約定，並且應該引用設備目前配置的區域設定。如果省略，則尾隨分號也必須刪除。
- $(MODEL) 字串的值必須與android.os.Build.MODEL的值相同。
- $(BUILD) 字串的值必須與android.os.Build.ID的值相同。
- $(CHROMIUM_VER) 字串的值必須是上游 Android 開源專案中 Chromium 的版本。
- 設備實作可以在用戶代理字串中省略Mobile 。

WebView 元件應該盡可能支援 HTML5 [參考資料，11 ]。

3.4.2.瀏覽器相容性

設備實作必須包括用於一般使用者 Web 瀏覽的獨立瀏覽器應用程式。獨立瀏覽器可以基於 WebKit 以外的瀏覽器技術。但是，即使使用備用瀏覽器應用程序，提供給第三方應用程式的android.webkit.WebView元件也必須基於 WebKit，如第 3.4.1 節中所述。

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

獨立的瀏覽器應用程式（無論是基於上游 WebKit 瀏覽器應用程式還是第三方替代品）應該盡可能支援 HTML5 [參考資料，11 ]。設備實作至少必須支援與 HTML5 相關的每個 API：

應用程式快取/離線操作 [資源，12 ]
<video> 標籤 [資源，13 ]
地理定位 [資源，14 ]

此外，設備實作必須支援 HTML5/W3C webstorage API [參考資料，15 ]，並且應該支援 HTML5/W3C IndexedDB API [參考資料，16 ]。請注意，隨著 Web 開發標準機構逐漸轉向支援 IndexedDB 而不是 Webstorage，IndexedDB 預計將成為 Android 未來版本中的必要組件。

3.5. API 行為相容性

每個 API 類型（託管、軟體、本機和 Web）的行為必須與上游 Android 開源專案的首選實作一致 [參考資料, 3 ]。一些特定的兼容性領域是：

設備不得更改標準 Intent 的行為或語意
設備不得更改特定類型系統元件（例如服務、活動、ContentProvider 等）的生命週期或生命週期語意
設備不得更改標準權限的語意

上面的列表並不全面。相容性測試套件 (CTS) 測試平台的重要部分（但不是全部）的行為相容性。實作者有責任確保與 Android 開源專案的行為相容性。因此，裝置實現者應該盡可能使用透過 Android 開源專案提供的原始程式碼，而不是重新實作系統的重要部分。

3.6. API命名空間

Android 遵循 Java 程式語言定義的套件和類別命名空間約定。為了確保與第三方應用程式的相容性，裝置實作者不得對這些套件命名空間進行任何禁止的修改（見下文）：

java.*
javax.*
太陽。*
安卓。*
com.android.*

禁止的修改包括：

裝置實作不得透過更改任何方法或類別簽名，或刪除類別或類別欄位來修改 Android 平台上公開的 API。
設備實作者可以修改 API 的底層實現，但此類修改不得影響任何公開暴露的 API 的規定行為和 Java 語言簽章。
設備實作者不得為上述 API 新增任何公開暴露的元素（例如類別或接口，或現有類別或介面的欄位或方法）。

「公開暴露的元素」是指未使用上游 Android 原始碼中使用的「@hide」標記修飾的任何構造。換句話說，設備實現者不得公開新的 API 或更改上述命名空間中的現有 API。設備實現者可以進行僅限內部的修改，但這些修改不得公佈或以其他方式暴露給開發人員。

設備實作者可以新增自訂 API，但任何此類 API 不得位於另一個組織擁有或引用另一個組織的命名空間中。例如，裝置實作者不得將 API 新增至 com.google.* 或類似的命名空間；只有谷歌可以這樣做。同樣，Google 不得將 API 新增至其他公司的命名空間。此外，如果裝置實作包含標準 Android 命名空間之外的自訂 API，則這些 API 必須打包在 Android 共用程式庫中，以便只有明確使用它們（透過<uses-library>機制）的應用程式才會受到內存使用量增加的影響此類 API。

如果設備實現者建議改進上述包命名空間之一（例如透過向現有 API 添加有用的新功能，或添加新 API），則實現者應該訪問 source.android.com 並開始貢獻更改和的過程代碼，根據該網站上的信息。

請注意，上述限制對應於 Java 程式語言中命名 API 的標準約定；本節的目的只是為了加強這些約定，並透過將其納入此相容性定義來使其具有約束力。

3.7.虛擬機器相容性

裝置實作必須支援完整的 Dalvik 執行檔 (DEX) 字節碼規格和 Dalvik 虛擬機器語意 [參考資料, 17 ]。

裝置實作必須配置 Dalvik 以根據上游 Android 平台分配內存，並如下表所示。（有關螢幕尺寸和螢幕密度定義，請參閱第 7.1.1 節。）

請注意，下面指定的記憶體值被視為最小值，設備實作可以為每個應用程式分配更多記憶體。

螢幕尺寸	螢幕密度	應用記憶體
小/普通/大	LDPI/MDPI	16MB
小/普通/大	電視解析度 / 高清分辨率	32MB
小/普通/大	高畫質像素	64MB
小/普通/大	400dpi	96MB
小/普通/大	xxhdpi	128MB
小/普通/大	xxxhdpi	256MB
超大	平均密度指數	32MB
超大	電視解析度 / 高清分辨率	64MB
超大	高畫質像素	128MB
超大	400dpi	192MB
超大	xxhdpi	256MB
超大	xxxhdpi	512MB

3.8.使用者介面相容性

3.8.1.啟動器（主螢幕）

Android 包括啟動器應用程式（主畫面）並支援第三方應用程式來取代裝置啟動器（主畫面）。允許第三方應用程式替換裝置主畫面的裝置實作必須聲明平台功能android.software.home_screen 。

3.8.2.小部件

Android 定義了元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開「AppWidget」[參考資料，18 ]。支援在主畫面上嵌入小工具的裝置實作必須滿足以下要求並聲明對平台功能android.software.app_widgets的支援。

裝置啟動器必須包含對 AppWidget 的內建支持，並公開使用者介面功能以直接在啟動器中新增、配置、檢視和刪除 AppWidget。
設備實作必須能夠渲染標準網格大小為 4 x 4 的小工具。（有關詳細信息，請參閱 Android SDK 文件 [參考資料，18 ] 中的應用程式小工具設計指南。
包括鎖定螢幕的支援的裝置實作必須支援鎖定螢幕上的應用程式小工具。

3.8.3.通知

Android 包含的 API 允許開發人員使用裝置的硬體和軟體功能來通知使用者值得注意的事件 [參考資料，19 ]。

某些 API 允許應用程式使用硬體（特別是聲音、振動和燈光）執行通知或吸引註意力。設備實作必須支援使用硬體功能的通知，如 SDK 文件所述，並儘可能支援設備實現硬體。例如，如果裝置實作包含振動器，則它必須正確實作振動 API。如果設備實作缺少硬件，則對應的 API 必須實作為無操作。請注意，第 7 節對此行為進行了進一步詳細說明。

此外，實作必須正確呈現 API [資源，20 ] 或狀態/系統列圖示樣式指南 [資源，21 ] 中提供的所有資源（圖示、聲音檔案等）。裝置實現者可以為通知提供替代的使用者體驗，而不是參考 Android 開源實作提供的體驗；然而，如上所述，此類替代通知系統必須支援現有通知資源。

Android 支援豐富的通知，例如持續通知的互動式視圖。裝置實作必須正確顯示和執行豐富的通知，如 Android API 中所述。

3.8.4.搜尋

Android 包含 API [參考資料，22 ]，允許開發人員將搜尋合併到他們的應用程式中，並將應用程式的資料公開到全域系統搜尋中。一般來說，此功能由單一系統範圍的使用者介面組成，允許使用者輸入查詢、在使用者鍵入時顯示建議並顯示結果。 Android API 允許開發人員重複使用此介面在自己的應用程式中提供搜索，並允許開發人員向通用全域搜尋使用者介面提供結果。

設備實現必須包括一個單一的、共享的、系統範圍的搜尋使用者介面，能夠響應用戶輸入提供即時建議。設備實作必須實作允許開發人員重複使用此使用者介面以在自己的應用程式中提供搜尋的 API。設備實作必須實作 API，允許第三方應用程式在全域搜尋模式下運行時向搜尋框添加建議。如果沒有安裝使用此功能的第三方應用程序，則預設行為應該是顯示網路搜尋引擎結果和建議。

3.8.5。吐司

應用程式可以使用「Toast」API（在[參考資料，23 ]中定義）向最終用戶顯示短的非模態字串，這些字串會在短暫的一段時間後消失。裝置實作必須以某種高可見性的方式向最終使用者顯示應用程式的 Toast。

3.8.6。主題

Android 提供「主題」作為應用程式在整個 Activity 或應用程式中應用樣式的機制。

Android 包含一個「Holo」主題系列，作為一組定義的樣式，供應用程式開發人員在想要匹配 Android SDK 定義的 Holo 主題外觀和感覺時使用[參考資料，24 ]。裝置實作不得更改向應用程式公開的任何 Holo 主題屬性 [參考資料，25 ]。

Android 還包含一個「裝置預設」主題系列，作為一組定義的樣式，供應用程式開發人員在想要匹配裝置實現者定義的裝置主題的外觀和風格時使用。設備實作可以修改向應用程式公開的 DeviceDefault 主題屬性 [參考資料，25 ]。

從版本 4.4 開始，Android 現在支援具有半透明系統列的新變體主題，允許應用程式開發人員用其應用程式內容填充狀態列和導覽列後面的區域。為了在此配置中實現一致的開發人員體驗，在不同的裝置實作中保持狀態列圖示樣式非常重要。因此，Android 裝置實作必須對系統狀態圖示（例如訊號強度和電池電量）和系統發出的通知使用白色，除非圖示指示有問題的狀態 [參考資料，25 ]。

3.8.7.動態壁紙

Android 定義了一種元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開一個或多個「動態壁紙」[參考資料，26 ]。動態壁紙是動畫、圖案或具有有限輸入功能的類似圖像，在其他應用程式後面顯示為壁紙。

如果硬體能夠以合理的幀速率運行所有動態壁紙，且不限制功能，並且不會對其他應用程式產生不利影響，則認為該硬體能夠可靠地運行動態壁紙。如果硬體限制導致壁紙和/或應用程式崩潰、故障、消耗過多的 CPU 或電池電量，或以不可接受的低幀速率運行，則該硬體被視為無法運行動態壁紙。例如，某些動態桌布可能會使用 OpenGL 1.0 或 2.0 上下文來渲染其內容。動態桌布將無法在不支援多個 OpenGL 上下文的硬體上可靠地運行，因為使用 OpenGL 上下文的動態桌布可能會與也使用 OpenGL 上下文的其他應用程式發生衝突。

如上所述，能夠可靠地運行動態壁紙的設備實現應該實現動態壁紙。如上所述，確定無法可靠運行動態壁紙的設備實作不得實現動態壁紙。

3.8.8。最近的應用程式顯示

上游 Android 原始碼包括一個使用者介面，用於使用使用者上次離開應用程式時應用程式圖形狀態的縮圖來顯示最近的應用程式。設備實現可能會改變或消除此使用者介面；然而，Android 的未來版本計劃更廣泛地使用此功能。強烈鼓勵裝置實現對最近的應用程式使用上游 Android 使用者介面（或類似的基於縮圖的介面），否則它們可能與未來版本的 Android 不相容。

3.8.9。輸入管理

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

聲明android.software.input_methods功能的裝置實作必須提供使用者可存取的機制來新增和設定第三方輸入法。裝置實作必須顯示設定介面以回應android.settings.INPUT_METHOD_SETTINGS意圖。

3.8.10.鎖定螢幕媒體遙控器

Android 支援遠端控制 API，允許媒體應用程式與遠端視圖中顯示的播放控制項（如裝置鎖定畫面）整合[參考資料，74 ]。支援裝置鎖定畫面並允許使用者在主畫面上新增小工具的裝置實作必須支援在裝置鎖定畫面中嵌入遠端控制[參考資料，69 ]。

3.8.11.夢

Android 支援名為 Dreams 的互動式螢幕保護程式 [參考資料，76 ]。 Dreams 允許使用者在充電設備空閒或插入桌面底座時與應用程式互動。設備實作必須包括對 Dreams 的支持，並為使用者提供配置 Dreams 的設定選項。

3.8.12.地點

位置模式必須顯示在設定 [資源，87 ] 內的位置選單中。透過Android 4.4中引入的SettingInjectorService提供的位置服務必須顯示在相同的位置選單中[資源，89 ]。

3.8.13.統一碼

Android 4.4 支援彩色表情符號。 Android 裝置實作必須提供使用者 Unicode 6.1 [參考資料，82 ] 中定義的表情符號字元的輸入方法，並且必須能夠以彩色字形呈現這些表情符號字元。

3.9.設備管理

Android 包含允許安全感知應用程式在系統層級執行裝置管理功能的功能，例如透過 Android 裝置管理 API 實作密碼原則或執行遠端抹除 [參考資料，27 ]。設備實作必須提供DevicePolicyManager類別的實作 [參考資料，28 ]。包含鎖定畫面支援的裝置實作必須支援 Android SDK 文件 [參考資料，27 ] 中定義的全部裝置管理策略。

設備實作可以預先安裝執行裝置管理功能的應用程序，但該應用程式不得開箱即用地設定為預設裝置所有者應用程式 [參考資料，84 ]。

3.10.無障礙

Android 提供了一個輔助功能層，可以幫助殘障用戶更輕鬆地導航其裝置。此外，Android 還提供平台 API，使輔助功能服務實現能夠接收使用者和系統事件的回呼並產生備用回饋機制，例如文字轉語音、觸覺回饋和軌跡球/方向鍵導航 [參考資料，29 ]。設備實作必須提供與預設Android實作一致的Android可訪問性框架的實作。具體而言，設備實作必須滿足以下要求。

設備實作必須透過android.accessibilityservice API [ Resources，30 ]來支援第三方可訪問性服務實作。
裝置實作必須產生AccessibilityEvents ，並以符合預設的Android實作的方式將這些事件交付給所有已註冊的AccessibilityService實作。
裝置實作必須提供可存取和停用可存取性服務的使用者存取機制，並且必須根據android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS意圖顯示此介面。

此外，設備實現應在設備上提供可訪問性服務的實現，並應為使用者提供在設備設定期間啟用可訪問性服務的機制。可訪問性服務的開源實作可從眼睛免費專案[ Resources，31 ]。

3.11.文字轉語音

Android包括允許應用程式使用文字轉語音（TTS）服務的API，並允許服務提供者提供TTS服務的實現[ Resources，32 ]。設備實作必須滿足與Android TTS框架相關的這些要求：

設備實作必須支援Android TTS框架API，並應包括支援設備上可用語言的TTS引擎。請注意，上游 Android 開源軟體包含功能齊全的 TTS 引擎實作。
設備實現必須支援安裝第三方TTS引擎。
設備實作必須提供一個可存取使用者的接口，該接口允許使用者選擇用於系統級別的TTS引擎。

4. 應用程式封裝相容性

設備實作必須安裝並執行Android「 .apk」文件，該文件由官方Android SDK中包含的「 AAPT」工具產生[ Resources，33 ]。

設備實作不得擴展.APK [資源，34 ]，Android清單[資源，35 ]，Dalvik bytecode [ Resources 17 ]或RenderScript字節碼的格式，以防止這些文件安裝並在其他兼容設備。設備實現者應使用DALVIK的參考上游實現以及參考實現的軟體包管理系統。

5. 多媒體相容性

設備實現必須包括至少一種形式的音訊輸出，例如揚聲器，耳機插孔，外部揚聲器連接等。

5.1.媒體編解碼器

設備實作必須支援Android SDK文檔[資源，58 ]中指定的核心媒體格式，除非本文檔明確允許。具體而言，設備實作必須支援下表中定義的媒體格式，編碼器，解碼器，檔案類型和容器格式。所有這些編解碼器都是在Android開源專案的首選Android實作中作為軟體實現的。

請注意，Google和開放手機聯盟都沒有做出任何代表，即這些編解碼器不受第三方專利的影響。建議打算在硬體或軟體產品中使用此原始碼的人，該程式碼的實現（包括開源軟體或共享軟體）可能需要相關專利持有人的專利許可。

請注意，這些表不列出大多數視訊編解碼器的特定位元速率要求，因為目前裝置硬體不一定支援將其對應到相關標準指定的所需位元速率的位元率。取而代之的是，設備實現應在硬體上支援最高的位元率實用，直到規格定義的限制。

類型	格式 /編解碼器	編碼器	解碼器	細節	文件類型 /容器格式
聲音的	MPEG-4 AAC設定檔（AAC LC）	包括麥克風硬體和定義`android.hardware.microphone`設備實現所需的。	必需的	支援單聲道/立體聲/5.0/5.1*的內容，其標準取樣率從8到48 kHz。	3GPP（.3GP） MPEG-4（.mp4，.m4a） ADTS RAW AAC（.AAC，在Android 3.1+中解碼，在Android 4.0+中編碼，不支援ADIF） mpeg-ts（.ts，不可尋求，Android 3.0+）
	MPEG-4 HE AAC設定檔（AAC+）	包括麥克風硬體和定義android.hardware.microphone的設備實作所需	必需的	支援單聲道/立體聲/5.0/5.1*的內容，其標準取樣率從16到48 kHz。
	MPEG-4 HE AAC V2設定檔（增強AAC+）		必需的	支援單聲道/立體聲/5.0/5.1*的內容，其標準取樣率從16到48 kHz。
	MPEG-4音訊物件類型ER AAC ELD（增強的低延遲AAC）	包括麥克風硬體和定義android.hardware.microphone的設備實作所需	必需的	支援單聲道/立體聲含量，標準取樣率從16到48 kHz。
	AMR-NB	包括麥克風硬體和定義`android.hardware.microphone`設備實現所需的。	必需的	4.75至12.2 kbps @ 8kHz採樣	3GPP（.3GP）
	AMR-WB	包括麥克風硬體和定義`android.hardware.microphone`設備實現所需的。	必需的	9率從6.60 kbit/s到23.85 kbit/s @ 16kHz	3GPP（.3GP）
	FLAC		必需的（Android 3.1+）	單聲道/立體聲（無多聲道）。最高48 kHz的樣品速率（但建議在44.1 kHz輸出的設備上使用高達44.1 kHz，因為48至44.1 kHz傾斜的傾角不包括低通濾波器）。建議使用16位；沒有抖動適用於24位。	僅FLAC（.flac）
	MP3		必需的	單聲道/立體聲8-320kbps常數（CBR）或可變位量（VBR）	mp3（.mp3）
	MIDI		必需的	MIDI類型0和1。DLS版本1和2。XMF和移動XMF。支援鈴聲格式RTTTL/RTX，OTA和IMELODY	類型0和1（.mid，.xmf，.mxmf） rtttl/rtx（.rtttl，.rtx） ota（.ota） imelody（.imy）
	沃爾比斯		必需的		ogg（.ogg） Matroska（.MKV）
	PCM/WAVE	必需的	必需的	8位元和16位元線性PCM **（速率達到硬體限制）。設備必須支援在8000,16000和44100 Hz頻率的原始PCM記錄的取樣率	波（.wav）
影像	JPEG	必需的	必需的	基礎+漸進式	jpeg（.jpg）
	動圖		必需的		GIF (.gif)
	巴布亞紐幾內亞	必需的	必需的		PNG (.png)
	骨形態發生蛋白		必需的		點陣圖 (.bmp)
	WEBP	必需的	必需的		WebP（.WEBP）
影片	H.263	包括相機硬體和定義`android.hardware.camera`或`android.hardware.camera.front`的設備實作所需的。	必需的		3GPP（.3GP） MPEG-4（.mp4）
	H.264 AVC	包括相機硬體和定義`android.hardware.camera`或`android.hardware.camera.front`的設備實作所需的。	必需的	基線概況（BP）	3GPP（.3GP） MPEG-4（.mp4） mpeg-ts（.ts，僅AAC音頻，不可尋找，Android 3.0+）
	MPEG-4 sp		必需的		3GPP（.3GP）
	VP8 ****	必需的（Android 4.3+）	必需的（Android 2.3.3+）		WebM （.Webm）和Matroska（.MKV，Android 4.0+）***
	VP9		必需的（Android 4.4+）		WebM （.Webm）和Matroska（.MKV，Android 4.0+）***

*注意：僅需5.0/5.1內容的下降；錄製或渲染超過2個頻道是可選的。
**注意：16位元線性PCM捕獲是強制性的。 8位元線性PCM捕獲不是強制性的。
***注意：設備實作應支援編寫Matroska WebM文件。
****注意：對於Web視訊串流和視訊會議服務的可接受質量，設備實作應使用符合[資源，86 ]中要求的硬體VP8編解碼器。

5.2.視訊編碼

包括後置相機和聲明android.hardware.camera的Android設備實作應支援以下H.264視訊編碼設定檔。

	SD（低品質）	SD（高品質）	高清（在硬體支援時）
視訊解析度	176 x 144 PX	480 x 360 PX	1280 x 720 PX
視訊框架速率	12 fps	30 幀/秒	30 幀/秒
視訊比特率	56 kbps	500 kbps或更高	2 Mbps或更高
音訊編解碼器	AAC-LC	AAC-LC	AAC-LC
音訊頻道	1（單聲道）	2（立體聲）	2（立體聲）
音訊比特率	24Kbps	128 kbps	192Kbps

包括後置相機和聲明android.hardware.camera應支援以下VP8視訊編碼設定檔的Android設備實現

	SD（低品質）	SD（高品質）	高清720p （在硬體的支援下）	高清1080p （在硬體的支援下）
視訊解析度	320 x 180 PX	640 x 360 PX	1280 x 720 PX	1920 x 1080 像素
視訊框架速率	30 幀/秒	30 幀/秒	30 幀/秒	30 幀/秒
視訊比特率	800 kbps	2Mbps	4Mbps	10Mbps

5.3.視訊解碼

Android裝置實作應支援下列VP8，VP9和H.264視訊解碼設定檔。設備實作也應支援VP8，VP9和H.264編解碼器的同一流中的動態視訊解析度切換。

	SD（低品質）	SD（高品質）	高清720p （在硬體的支援時）	高清1080p （在硬體的支援時）
視訊解析度	320 x 180 PX	640 x 360 PX	1280 x 720 PX	1920 x 1080 像素
視訊框架速率	30 幀/秒	30 幀/秒	30 幀/秒	30 幀/秒
視訊比特率	800 kbps	2Mbps	8Mbps	20Mbps

5.4.聲音錄製

當應用程式使用android.media.AudioRecord API開始錄製音訊串流時，包括麥克風硬體和聲明android.hardware.microphone必須用這些行為進行範例和錄製音訊：

該設備應表現出大約平坦的幅度與頻率特性。具體而言，±3 dB，從100 Hz到4000 Hz
應該設定音頻輸入靈敏度，以使1000 Hz的90 dB聲音源（SPL）源可為16位元樣品產生2500的RMS。
PCM振幅水平應線性追蹤至少30 dB上的SPL變化，從-18 dB到+12 dB re 90 dB re 90 dB spl在麥克風上。
在90 dB SPL輸入水準下，1KHz的總諧波失真應小於1％。

除上述記錄規格外，當應用程式開始使用android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION Audio來源來錄製音訊串流時，

降噪處理，如果存在，則必須停用。
自動增益控制（如果存在）必須停用。

來自Android 4.4， android.media.MediaRecorder.AudioSource類別有新的音訊來源： REMOTE_SUBMIX 。裝置必須正確實現REMOTE_SUBMIX音訊來源，以便應用程式使用android.media.AudioRecord API從此音訊來源錄製時，它可以捕獲所有音訊串流的混合，除了以下內容：

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

注意：雖然上面概述的某些要求被稱為“應該”，因為Android 4.3，但計劃將未來版本的兼容性定義更改為“必須”。也就是說，這些要求在Android 4.4中是可選的，但是將來版本將需要。強烈鼓勵運行Android的現有和新設備滿足這些要求，或者在升級到將來版本時，它們將無法獲得Android相容性。

如果該平台支援抑制語音辨識的噪音抑制技術，則該效果必須從android.media.audiofx.NoiseSuppressor API中控制。此外，抑制噪音效果描述符的「 UUID」欄位必須唯一地識別噪音抑制技術的每個實作。

5.5.音訊延遲

音訊延遲是隨著音訊訊號通過系統的時間延遲。許多類別的應用程式都依賴短延遲來實現即時聲音效果。

為本節的目的：

「輸出延遲」定義為應用程式編寫PCM編碼資料的幀與外部偵聽器可以聽到相應的聲音或換能器觀察到相應的聲音之間的間隔
「冷輸出延遲」定義為第一幀的輸出延遲，當音訊輸出系統閒置並在請求之前降低電源時
「連續輸出延遲」定義為後續影格的輸出延遲，在裝置已經播放音訊之後
「輸入延遲」是將外部聲音顯示給裝置的間隔與應用程式讀取對應的PCM編碼資料幀的間隔
「冷輸入延遲」定義為遺失的輸入時間和第一幀的輸入延遲的總和，當音訊輸入系統閒置並在請求之前停止電源時
「連續輸入延遲」定義為後續影格的輸入延遲，而裝置已經擷取音訊
「 OpenSL ES PCM緩衝列式API」是Android NDK中與PCM相關的OPESL ES API的集合；請參閱NDK_ROOT /docs/opensles/index.html /index.html

根據第5節，所有相容的設備實作都必須包括至少一種形式的音訊輸出。設備實現應滿足或超過這些輸出延遲要求：

100毫秒或更少的冷輸出潛伏期
連續輸出潛伏期為45毫秒或更少

如果裝置實現在使用OpenSL ES PCM緩衝區佇列API時進行任何初始校準後滿足本節的要求，則在至少一個支援的音訊輸出裝置上，對於連續輸出延遲和冷輸出潛伏期，它可能會報告對低延遲音訊的支持，透過報告「 android.hardware.audio.low-low-latency」功能透過android.content.pm.PackageManager類別。 [資源，37 ]相反，如果設備實現不符合這些要求，則不得報告對低延遲音訊的支援。

根據第7.2.5節，可以透過設備實現省略麥克風硬體。

包含麥克風硬體和聲明android.hardware.microphone裝置實作應滿足這些輸入音訊延遲要求：

100毫秒或更少的冷輸入潛伏期
連續輸入延遲為50毫秒或更少

5.6.網路協定

設備必須支援Android SDK文件[資源，58 ]中指定的音訊和視訊播放的媒體網路協定。具體而言，設備必須支援以下媒體網路協定：

RTSP（RTP，SDP）
HTTP（S）漸進式串流媒體
HTTP（S）即時串流草稿協議，版本3 [資源，59 ]

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

6.1.開發者工具

設備實作必須支援Android SDK中提供的Android開發人員工具。具體而言，與Android相容的設備必須與：

Android調試橋（稱為ADB） [資源，33 ]
設備實作必須支援Android SDK中記錄的所有adb功能。預設情況下，裝置側adb守護程式必須不活動，並且必須有一個可存取使用者的機制來開啟Android偵錯橋。
Android包含安全ADB的支援。安全ADB可以在已知身份驗證的宿主上啟用ADB。設備實作必須支援安全的ADB。
Dalvik調試監視器服務（稱為DDMS） [資源，33 ]
設備實作必須支援Android SDK中記錄的所有ddms功能。由於ddms使用adb ，因此預設情況下，對ddms的支援應無效，但每當使用者啟動Android Debug Bridge（如上所述）時，必須支援DDMS。
猴子[資源，36 ]
設備實作必須包括猴子框架，並使其可用於使用應用程式。
Systrace [資源，33 ]
設備實作必須支援Android SDK中記錄的Systrace工具。 Systrace預設必須不活動，且必須有一個可存取Systrace的使用者存取機制。

大多數基於Linux的系統和Apple Macintosh系統使用標準Android SDK工具識別Android設備，而無需額外支援；但是，Microsoft Windows系統通常需要新的Android裝置的驅動程式。（例如，新的供應商ID和有時新設備ID需要Windows系統的自訂USB驅動程式。）如果adb工具無法按照標準Android SDK中提供的ADB工具識別設備實現，則設備實現者必須為Windows驅動程式提供允許開發人員連接到Windows驅動程式使用adb協定的裝置。這些驅動程式必須在32位元和64位元版本中為Windows XP，Windows Vista，Windows 7和Windows 8提供。

6.2.開發者選項

Android包括對開發人員配置與應用程式開發相關的設定的支援。裝置實作必須尊重android.settings.application_development_settings意圖顯示與應用程式開發相關的設定[資源，77 ]。預設情況下，上游Android實作會將「開發者選項」選單隱藏起來，並使使用者在設定>「關於裝置」>「建置號碼」選單項目上按7（7）次之後啟動開發人員選項。設備實作必須為開發人員選項提供一致的體驗。具體而言，設備實作必須預設使用開發人員選項，並且必須提供一種機制來啟用與上游Android實作一致的開發人員選項。

6.2.1.實驗性的

Android 4.4引入了ART，這是一種實驗性的Android運行時，可在「開發人員選項」選單中進行預覽。設備實作應包括ART（LIBART.SO），並支援開發人員選項的雙啟動，但必須將Dalvik（libdvm.so）保留為預設運行時。

7. 硬體相容性

如果裝置包含具有針對第三方開發人員對應的API的特定硬體元件，則裝置實作必須如Android SDK文件中所述實作該API。如果SDK中的API與指定為選購的硬體元件相互作用，且設備實作不具備該元件：

組件API的完整類別定義（如SDK所記錄）仍然必須存在
API的行為必須以某種合理的方式實現為無措施
API方法必須在SDK文件允許的情況下傳回null值
API方法必須傳回SDK文件不允許未允許的null值的類別的NO-OP實現
API方法不得拋出SDK文件未記錄的異常

這些需求適用的方案的一個典型範例是電話API：即使在非電話設備上，這些API也必須實作為合理的NO-OPS。

設備實作必須透過android.content.pm.PackageManager類別上的getSystemAvailableFeatures()和hasSystemFeature(String)方法準確地報告準確的硬體配置資訊。 [資源，37 ]

7.1.顯示和圖形

Android包括適當適當地調整應用程式資產和UI佈局的設施，以確保第三方應用程式在各種硬體配置上運作良好[ Resources，38 ]。如本節所述，設備必須正確實施這些API和行為。

本節中要求所引用的單位定義如下：

「物理對角線大小」是顯示器點亮部分的兩個相對角的距離。
「 DPI」（意思是「每英吋點」）是由1英吋的線性水平或垂直跨度所包含的像素的數量。列出了DPI值，水平和垂直DPI都必須在該範圍內。
「縱橫比」是螢幕較長維與較短維度的比率。例如，480x854像素的顯示為854 /480 = 1.779，或大致為「 16：9」。
「密度無關的像素」或（「 DP」）是標準化為160 DPI螢幕的虛擬像素單元，計算為： pixels = dps * (density / 160) 。

7.1.1.螢幕配置

螢幕尺寸

Android UI框架支援各種不同的螢幕尺寸，並允許應用程式透過android.content.res.Configuration.screenLayout與SCREENLAYOUT_SIZE_MASK查詢裝置螢幕大小（aka「螢幕佈局」）。裝置實作必須報告Android SDK文件[資源，38 ]中定義的正確螢幕大小，並由上游Android平台決定。具體而言，設備實現必須根據以下邏輯密度獨立的像素（DP）螢幕尺寸報告正確的螢幕尺寸。

設備必須具有至少426 dp x 320 dp（'small'）的螢幕尺寸
報告螢幕尺寸「正常」的裝置必須具有至少480 dp x 320 dp的螢幕尺寸
報告螢幕尺寸「大」的裝置必須具有至少640 dp x 480 dp的螢幕尺寸
報告螢幕尺寸「 Xlarge」的裝置必須具有至少960 dp x 720 dp的螢幕尺寸

此外，設備必須具有至少2.5英吋的物理對角線尺寸。

設備不得隨時更改其報告的螢幕尺寸。

應用程式可選擇地指示透過<Supports-Screens> AndroidManifest.xml檔案中的<supports-screens>屬性支援的螢幕大小。裝置實作必須正確地尊重應用程式對Android SDK文件中所述的小型，正常，大和Xlarge螢幕的指定支援。

螢幕縱橫比

縱橫比必須是1.3333（4：3）至1.86（約16：9）的值

螢幕密度

Android UI框架定義了一組標準邏輯密度，以幫助應用程式開發人員針對應用程式資源。設備實作必須透過android.util.DisplayMetrics API報告以下邏輯Android框架密度之一，並且必須以此標準密度執行應用程式。

120 DPI，稱為“ ldpi”
160 DPI，稱為“ MDPI”
213 DPI，稱為“ TVDPI”
240 DPI，稱為“ HDPI”
320 DPI，稱為“ XHDPI”
400 dpi，稱為“ 400dpi”
480 DPI，稱為“ xxhdpi”
640 DPI，稱為“ xxxhdpi'

裝置實現應定義標準的Android框架密度，該密度在數值上最接近螢幕的物理密度，除非該邏輯密度將報告的螢幕尺寸推高以下所支援的最小值。如果在數值上最接近物理密度的標準Android框架密度會導致螢幕尺寸小於最小的相容螢幕尺寸（320 dp寬度），則裝置實現應報告下一個最低的標準Android框架密度。

7.1.2.顯示指標

設備實作必須報告android.util.DisplayMetrics中定義的所有顯示指標的正確值[ Resources，39 ]。

7.1.3.螢幕方向

設備必須透過應用程式來支援人像或景觀螢幕方向的動態方向。也就是說，設備必須尊重應用程式的特定螢幕方向請求。設備實作可以選擇肖像或景觀方向作為預設設備。

每當透過android.content.res.configuration.orientation，android.view.display.getorientation（）或其他apis查詢時，裝置必須報告裝置目前方向的正確值。

更改方向時，設備不得更改報告的螢幕尺寸或密度。

裝置必須報告他們支援的螢幕方向（ android.hardware.screen.portrait和/或android.hardware.screen.landscape ），並且必須至少報告一個支援的方向。例如，具有固定取向景觀螢幕（例如電視或筆記型電腦）的裝置只能報告android.hardware.screen.landscape 。

7.1.4. 2D 和 3D 圖形加速

設備實作必須支援OpenGL ES 1.0和2.0，如Android SDK文件中所體現和詳細介紹。設備實作應支援能夠支援OpenGL ES 3.0的裝置上的OpenGL ES 3.0。裝置實作也必須支援Android SDK文件[資源，8 ]中詳細介紹的Android Renderscript。

裝置實作也必須正確辨識自己為支援OpenGL ES 1.0，OpenGL ES 2.0或OpenGL ES 3.0。那是：

託管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支援的設備實作必須支援OpenGL ES 3.0託管API，並包括對本機C/C ++ API的支援。在宣告對OpenGL ES 3.0支援的裝置實作時，LibGlesV2.因此，除了OpenGL ES 2.0函數符號外，必須匯出OpenGL ES 3.0功能符號。

設備實作可以實現任何所需的OpenGL ES擴充功能。但是，裝置實作必須透過OpenGL ES託管和本機API報告它們所支援的所有擴充字串，相反，不得報告不支援的擴充字串。

請注意，Android包括對應用程式的支持，以指定它們需要特定的OpenGL紋理壓縮格式。這些格式通常是特定於供應商的。 Android不需要裝置實作來實現任何特定的紋理壓縮格式。但是，他們應透過OpenGL API中的getString()方法準確地報告所支援的任何紋理壓縮格式。

Android包括一個機制，用於聲明他們希望透過使用明顯標籤android:hardwareAccelerated或Direct API呼叫在應用程序，活動，視窗或視圖層級上啟用2D圖形的硬體加速度[ Resources，9 ]。

在Android 4.4中，裝置實作必須預設啟用硬體加速度，如果開發人員透過設定android:hardwareAccelerated="false"或直接透過Android View API來停用硬體加速度，則必須停用硬體加速度。

此外，設備實作必須表現出與硬體加速器的Android SDK文件一致的行為[ Resources，9 ]。

Android包含一個TextureView對象，該對象使開發人員可以直接將硬體加速的OpenGL ES紋理整合為UI層次結構中的渲染目標。設備實作必須支援TextureView API，並且必須透過上游Android實作表現出一致的行為。

Android包括對EGL_ANDROID_RECORDABLE的支持，EGLCONFIG屬性指示EGLCONFIG是否支援將影像記錄到影片的AnativeWindow。設備實作必須支援EGL_ANDROID_RECORDABLE副檔名[資源，79 ]。

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

Android指定了一種“相容模式”，其中框架以“正常”螢幕尺寸等效（320dp寬度）模式運行，以獲取未開發的舊版本應用程式的舊版本的Android，該應用程式的舊版本，此版本是預先螢幕尺寸的獨立性。設備實作必須包括對上游Android開源程式碼實現的傳統應用程式相容模式的支援。也就是說，設備實作不得更改啟動相容模式的觸發器或閾值，且不得改變相容模式本身的行為。

7.1.6。螢幕類型

設備實現螢幕被歸類為兩種類型之一：

固定像素顯示實作：螢幕是僅支援單一像素寬度和高度的單一面板。通常，螢幕與裝置物理整合。例如手機，平板電腦等。
可變像素顯示實現：設備實現要么沒有嵌入式螢幕，還包括一個視頻輸出端口，例如VGA，HDMI或用於顯示的無線端口，或者俱有可以更改像素尺寸的嵌入式屏幕。例如電視，機上盒等。

固定像素設備實現

固定像素裝置實作可以使用任何像素維度的螢幕，只要它們符合定義此相容性定義的要求。

固定像素實作可能包括一個視訊輸出端口，用於外部顯示。但是，如果顯示用於運行應用程序，則該設備必須滿足以下要求：

該設備必須報告相同的螢幕配置和顯示指標，如固定像素顯示器所述，如第7.1.1和7.1.2節所述。
該設備必須報告與固定像素顯示器相同的邏輯密度。
該設備必須報告與固定像素顯示器相同或非常接近的螢幕尺寸。

例如，具有10英寸對角線大小的平板電腦具有1024x600像素分辨率被認為是固定像素大型MDPI顯示實現。如果它包含一個視頻輸出端口，該視頻輸出端口在720p或1080p處顯示設備，則設備實現必須擴展輸出，以便應用程式以使應用程式以便應用程式以使應用程式以便應用程式。僅在使用固定像素顯示或視訊輸出連接埠的大型MDPI視窗中執行。

可變像素設備實現

可變像素設備實作必須至少支援1280x720、1920x1080或3840x2160（即720p，1080p或4k）中的至少一個。具有可變像素顯示器的裝置實現不得支援任何其他螢幕配置或模式。具有可變像素螢幕的裝置實作可能會在運行時或啟動時間變更螢幕配置或模式。例如，機上盒的使用者可以用1080p顯示器替換720p顯示屏，並且設備實現可以進行相應調整。

此外，可變像素設備實現必須報告這些像素尺寸的以下配置桶：

1280x720（也稱為720p）：“大螢幕尺寸”，“ tvdpi”（213 dpi）密度
1920x1080（也稱為1080p）：“大螢幕尺寸”，“ xhdpi”（320 dpi）密度
3840x2160（也稱為4K）：'大螢幕尺寸，'xxxhdpi'（640 dpi）密度

為了清楚起見，具有可變像素尺寸的裝置實作僅限於Android 4.4中的720p，1080p或4k，必須配置以報告上面指出的螢幕尺寸和密度桶。

7.1.7.螢幕技術

Android平台包含允許應用程式將豐富圖形呈現為顯示的API。除非本文檔中明確允許，否則設備必須支援Android SDK定義的所有這些API。具體來說：

設備必須支援能夠渲染16位元顏色圖形的顯示器，並應支援能夠具有24位元顏色圖形的顯示。
設備必須支援能夠渲染動畫的顯示器。
所使用的顯示技術必須具有0.9至1.1之間的像素縱橫比（PAR）。也就是說，像素縱橫比必須在正方形（1.0）附近，其公差為10％。

7.1.8。外部顯示

Android包括對輔助顯示的支持，以啟用媒體共享功能和開發人員API，以存取外部顯示。如果裝置透過有線，無線或嵌入式附加顯示連線來支援外部顯示，則裝置實作必須如Android SDK文件[ Resources，75 ]中所述實作顯示管理器API。支援安全視訊輸出並且能夠支援安全表面的裝置實作必須聲明對Display.FLAG_SECURE的支援。具體而言，要聲明對Display的支援的設備實現Display.FLAG_SECURE ，對於Miracast Wireless Displays或HDCP 1.2或更高的有線顯示器，必須支援HDCP 2.x或更高的HDCP 2.x或更高。上游Android開源實作包括滿足此要求的無線（Miracast）和有線（HDMI）顯示的支援。

7.2.輸入裝置

7.2.1.鍵盤

設備實現：

必須包括對輸入管理框架的支援（該框架允許第三方開發人員建立輸入管理引擎 - IE軟鍵盤），如http://developer.android.com詳細介紹。
必須至少提供一個軟鍵盤實現（無論是否存在硬鍵盤）
可能包括其他軟鍵盤實現
可能包括硬體鍵盤
不得包含與android.content.res.Configuration.keyboard [ Resources，40 ]中指定的格式之一的硬體鍵盤（即，Qwerty或12-KEY）

7.2.2.非觸控式導航

設備實現：

可能會省略非接觸式導覽選項（即可能省略軌跡球，D-pad或車輪）
必須報告android.content.res.Configuration.navigation的正確值[ Resources，40 ]
必須提供合理的替代使用者介面機制，以選擇和編輯文本，與輸入管理引擎相容。上游Android開源實作包含一種選擇機制，適用於缺少非接觸導航輸入的裝置。

7.2.3.導航鍵

房屋，恢復和背部功能對於Android導航範式至關重要。設備實作必須使這些功能在運行應用程式時始終為使用者提供。這些功能可以透過專用的實體按鈕（例如機械或電容式觸控按鈕）來實現，也可以使用螢幕上不同部分，手勢，觸控面板等的專用軟體金鑰來實現。Android支援這兩個實現。所有這些功能都必須透過單一動作（例如TAP，雙擊或手勢）存取。

背面和後衛功能應具有可見的按鈕或圖標，除非與其他螢幕模式下的其他導航功能一起隱藏。除非與全螢幕模式下的其他導航功能一起隱藏，否則家庭功能必須具有可見的按鈕或圖示。

自Android 4.0以來，將選單功能不建議使用動作列。設備實作不應為選單功能實現專用的實體按鈕。如果實現了實體選單按鈕，並且裝置正在運行帶有targetSdkVersion > 10的應用程序，則裝置實作：

對於使用Android 4.4啟動的設備，必須在可見操作列且所得的動作溢出選單上的POPU並不空時，必須在操作列上顯示動作溢位按鈕。
對於具有較早版本但升級到Android 4.4的現有設備，應在可見操作列並且所得的操作溢出選單彈出視窗時顯示動作列上的動作溢出按鈕。
不得透過選擇動作列中的溢出按鈕來修改顯示動作溢位彈出的位置。
選擇「實體選單」按鈕顯示時，可以在螢幕上的修改位置呈現動作溢位彈出視窗。

為了向後相容，當targetSdkVersion <= 10（透過實體按鈕，軟體鍵或手勢）時，裝置實作必須使選單功能可用於應用程式。除非與其他導覽功能一起隱藏，否則應顯示此功能表功能。

Android支援輔助行動[資源，63 ]。設備實作必須使用戶在執行應用程式時始終為使用者提供輔助操作。輔助操作應作為主按鈕上的長壓或軟體主機上的滑動手勢實施。可以透過另一個實體按鈕，軟體金鑰或手勢來實現此功能，但是當可見其他導航鍵時，必須透過單一操作（例如TAP，雙擊或手勢）存取此功能。

裝置實作可以使用螢幕的不同部分顯示導航金鑰，但是如果是，則必須符合以下要求：

Device implementation navigation keys MUST use a distinct portion of the screen, not available to applications, and MUST NOT obscure or otherwise interfere with the portion of the screen available to applications.
Device implementations MUST make available a portion of the display to applications that meets the requirements defined in Section 7.1.1 .
Device implementations MUST display the navigation keys when applications do not specify a system UI mode, or specify SYSTEM_UI_FLAG_VISIBLE .
Device implementations MUST present the navigation keys in an unobtrusive "low profile" (eg. dimmed) mode when applications specify SYSTEM_UI_FLAG_LOW_PROFILE .
Device implementations MUST hide the navigation keys when applications specify SYSTEM_UI_FLAG_HIDE_NAVIGATION .

7.2.4.觸控螢幕輸入

Device implementations SHOULD have a pointer input system of some kind (either mouse-like, or touch). However, if a device implementation does not support a pointer input system, it MUST NOT report the android.hardware.touchscreen or android.hardware.faketouch feature constant. Device implementations that do include a pointer input system:

SHOULD support fully independently tracked pointers, if the device input system supports multiple pointers
MUST report the value of android.content.res.Configuration.touchscreen [ Resources, 40 ] corresponding to the type of the specific touchscreen on the device

Android includes support for a variety of touch screens, touch pads, and fake touch input devices. Touch screen based device implementations are associated with a display [ Resources, 81 ] such that the user has the impression of directly manipulating items on screen. Since the user is directly touching the screen, the system does not require any additional affordances to indicate the objects being manipulated. In contrast, a fake touch interface provides a user input system that approximates a subset of touchscreen capabilities. For example, a mouse or remote control that drives an on-screen cursor approximates touch, but requires the user to first point or focus then click. Numerous input devices like the mouse, trackpad, gyro-based air mouse, gyro-pointer, joystick, and multi-touch trackpad can support fake touch interactions. Android 4.0 includes the feature constant android.hardware.faketouch , which corresponds to a high-fidelity non-touch (that is, pointer-based) input device such as a mouse or trackpad that can adequately emulate touch-based input (including basic gesture support), and indicates that the device supports an emulated subset of touchscreen functionality. Device implementations that declare the fake touch feature MUST meet the fake touch requirements in Section 7.2.5 .

Device implementations MUST report the correct feature corresponding to the type of input used. Device implementations that include a touchscreen (single-touch or better) MUST report the platform feature constant android.hardware.touchscreen . Device implementations that report the platform feature constant android.hardware.touchscreen MUST also report the platform feature constant android.hardware.faketouch . Device implementations that do not include a touchscreen (and rely on a pointer device only) MUST NOT report any touchscreen feature, and MUST report only android.hardware.faketouch if they meet the fake touch requirements in Section 7.2.5 .

7.2.5. Fake touch input

Device implementations that declare support for android.hardware.faketouch

MUST report the absolute X and Y screen positions of the pointer location and display a visual pointer on the screen [ Resources, 80 ]
MUST report touch event with the action code [ Resources, 80 ] that specifies the state change that occurs on the pointer going down or up on the screen [ Resources, 80 ]
MUST support pointer down and up on an object on the screen, which allows users to emulate tap on an object on the screen
MUST support pointer down , pointer up , pointer down then pointer up in the same place on an object on the screen within a time threshold, which allows users to emulate double tap on an object on the screen [ Resources, 80 ]
MUST support pointer down on an arbitrary point on the screen, pointer move to any other arbitrary point on the screen, followed by a pointer up , which allows users to emulate a touch drag
MUST support pointer down then allow users to quickly move the object to a different position on the screen and then pointer up on the screen, which allows users to fling an object on the screen

Devices that declare support for android.hardware.faketouch.multitouch.distinct MUST meet the requirements for faketouch above, and MUST also support distinct tracking of two or more independent pointer inputs.

7.2.6。麥克風

Device implementations MAY omit a microphone. However, if a device implementation omits a microphone, it MUST NOT report the android.hardware.microphone feature constant, and must implement the audio recording API as no-ops, per Section 7 . Conversely, device implementations that do possess a microphone:

MUST report the android.hardware.microphone feature constant
SHOULD meet the audio quality requirements in Section 5.4
SHOULD meet the audio latency requirements in Section 5.5

7.3.感應器

Android includes APIs for accessing a variety of sensor types. Devices implementations generally MAY omit these sensors, as provided for in the following subsections. If a device includes a particular sensor type that has a corresponding API for third-party developers, the device implementation MUST implement that API as described in the Android SDK documentation. For example, device implementations:

MUST accurately report the presence or absence of sensors per the android.content.pm.PackageManager class. [ Resources, 37 ]
MUST return an accurate list of supported sensors via the SensorManager.getSensorList() and similar methods
MUST behave reasonably for all other sensor APIs (for example, by returning true or false as appropriate when applications attempt to register listeners, not calling sensor listeners when the corresponding sensors are not present; etc.)
MUST report all sensor measurements using the relevant International System of Units (ie metric) values for each sensor type as defined in the Android SDK documentation [ Resources, 41 ]

The list above is not comprehensive; the documented behavior of the Android SDK is to be considered authoritative.

Some sensor types are synthetic, meaning they can be derived from data provided by one or more other sensors. (Examples include the orientation sensor, and the linear acceleration sensor.) Device implementations SHOULD implement these sensor types, when they include the prerequisite physical sensors.

Android includes a notion of a "streaming" sensor, which is one that returns data continuously, rather than only when the data changes. Device implementations MUST continuously provide periodic data samples for any API indicated by the Android SDK documentation to be a streaming sensor. Note that the device implementations MUST ensure that the sensor stream must not prevent the device CPU from entering a suspend state or waking up from a suspend state.

7.3.1.加速度計

Device implementations SHOULD include a 3-axis accelerometer. If a device implementation does include a 3-axis accelerometer, it:

SHOULD be able to deliver events at 120 Hz or greater. Note that while the accelerometer frequency above is stated as "SHOULD" for Android 4.4, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in Android but will be required in future versions. Existing and new devices that run Android are very strongly encouraged to meet these requirements in Android so they will be able to upgrade to the future platform releases
MUST comply with the Android sensor coordinate system as detailed in the Android APIs (see [ Resources, 41 ])
MUST be capable of measuring from freefall up to twice gravity (2g) or more on any three-dimensional vector
MUST have 8-bits of accuracy or more
MUST have a standard deviation no greater than 0.05 m/s^2

7.3.2.磁力計

Device implementations SHOULD include a 3-axis magnetometer (ie compass.) If a device does include a 3-axis magnetometer, it:

MUST be able to deliver events at 10 Hz or greater
MUST comply with the Android sensor coordinate system as detailed in the Android APIs (see [ Resources, 41 ]).
MUST be capable of sampling a range of field strengths adequate to cover the geomagnetic field
MUST have 8-bits of accuracy or more
MUST have a standard deviation no greater than 0.5 µT

7.3.3.全球定位系統

Device implementations SHOULD include a GPS receiver. If a device implementation does include a GPS receiver, it SHOULD include some form of "assisted GPS" technique to minimize GPS lock-on time.

7.3.4.陀螺儀

Device implementations SHOULD include a gyroscope (ie angular change sensor.) Devices SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is also included. If a device implementation includes a gyroscope, it:

MUST be temperature compensated.
MUST be capable of measuring orientation changes up to 5.5*Pi radians/second (that is, approximately 1,000 degrees per second).
SHOULD be able to deliver events at 200 Hz or greater. Note that while the gyroscope frequency above is stated as "SHOULD" for Android 4.4, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in Android but will be required in future versions. Existing and new devices that run Android are very strongly encouraged to meet these requirements so they will be able to upgrade to the future platform releases.
MUST have 12-bits of accuracy or more
MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but must be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.
MUST have timestamps as close to when the hardware event happened as possible. The constant latency must be removed.

7.3.5.晴雨表

Device implementations MAY include a barometer (ie ambient air pressure sensor.) If a device implementation includes a barometer, it:

MUST be able to deliver events at 5 Hz or greater
MUST have adequate precision to enable estimating altitude
MUST be temperature compensated

7.3.6。溫度計

Device implementations MAY include an ambient thermometer (ie temperature sensor). If present, it MUST be defined as SENSOR_TYPE_AMBIENT_TEMPERATURE and it MUST measure the ambient (room) temperature in degrees Celsius.

Device implementations MAY but SHOULD NOT include a CPU temperature sensor. If present, it MUST be defined as SENSOR_TYPE_TEMPERATURE , it MUST measure the temperature of the device CPU, and it MUST NOT measure any other temperature. Note the SENSOR_TYPE_TEMPERATURE sensor type was deprecated in Android 4.0.

7.3.7.光度計

Device implementations MAY include a photometer (ie ambient light sensor.)

7.3.8.接近感測器

Device implementations MAY include a proximity sensor. If a device implementation does include a proximity sensor, it MUST measure the proximity of an object in the same direction as the screen. That is, the proximity sensor MUST be oriented to detect objects close to the screen, as the primary intent of this sensor type is to detect a phone in use by the user. If a device implementation includes a proximity sensor with any other orientation, it MUST NOT be accessible through this API. If a device implementation has a proximity sensor, it MUST be have 1-bit of accuracy or more.

7.4.數據連接

7.4.1.電話

"Telephony" as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages via a GSM or CDMA network. While these voice calls may or may not be packet-switched, they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words, the Android "telephony" functionality and APIs refer specifically to voice calls and SMS; for instance, device implementations that cannot place calls or send/receive SMS messages MUST NOT report the "android.hardware.telephony" feature or any sub-features, regardless of whether they use a cellular network for data connectivity.

Android MAY be used on devices that do not include telephony hardware. That is, Android is compatible with devices that are not phones. However, if a device implementation does include GSM or CDMA telephony, it MUST implement full support for the API for that technology. Device implementations that do not include telephony hardware MUST implement the full APIs as no-ops.

7.4.2. IEEE 802.11（無線網路）

Android device implementations SHOULD include support for one or more forms of 802.11 (b/g/a/n, etc.) If a device implementation does include support for 802.11, it MUST implement the corresponding Android API.

Device implementations MUST implement the multicast API as described in the SDK documentation [ Resources, 62 ]. Device implementations that do include Wi-Fi support MUST support multicast DNS (mDNS). Device implementations MUST NOT filter mDNS packets (224.0.0.251) at any time of operation including when the screen is not in an active state.

7.4.2.1.無線直連

Device implementations SHOULD include support for Wi-Fi direct (Wi-Fi peer-to-peer). If a device implementation does include support for Wi-Fi direct, it MUST implement the corresponding Android API as described in the SDK documentation [ Resources, 68 ]. If a device implementation includes support for Wi-Fi direct, then it:

MUST support regular Wi-Fi operation
SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation

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

Device implementations SHOULD include support for Wi-Fi Tunneled Direct Link Setup (TDLS) as described in the Android SDK Documentation [ Resources, 85 ]. If a device implementation does include support for TDLS and TDLS is enabled by the WiFiManager API, the device:

SHOULD use TDLS only when it is possible AND beneficial.
SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point.

7.4.3.藍牙

Device implementations SHOULD include a Bluetooth transceiver. Device implementations that do include a Bluetooth transceiver MUST enable the RFCOMM-based Bluetooth API as described in the SDK documentation and declare hardware feature android.hardware.bluetooth [ Resources, 42 ]. Device implementations SHOULD implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as appropriate for the device.

Device implementations that do include support for Bluetooth GATT (generic attribute profile) to enable communication with Bluetooth Smart or Smart Ready devices MUST enable the GATT-based Bluetooth API as described in the SDK documenware andclare documenware andclare docm. 42 ]。

7.4.4.近場通訊

Device implementations SHOULD include a transceiver and related hardware for Near-Field Communications (NFC). If a device implementation does include NFC hardware, then it:

MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method. [ Resources, 37 ]
MUST be capable of reading and writing NDEF messages via the following NFC standards:
- MUST be capable of acting as an NFC Forum reader/writer (as defined by the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS 6319-4)
  - IsoDep (ISO 14443-4)
  - NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
SHOULD be capable of reading and writing NDEF messages via the following NFC standards. Note that while the NFC standards below are stated as "SHOULD", the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in this version but will be required in future versions. Existing and new devices that run this version of Android are very strongly encouraged to meet these requirements now so they will be able to upgrade to the future platform releases.
- NfcV (ISO 15693)
MUST be capable of transmitting and receiving data via the following peer-to-peer standards and protocols:
- ISO 18092
- LLCP 1.0 (defined by the NFC Forum)
- SDP 1.0 (defined by the NFC Forum)
- NDEF Push Protocol [ Resources, 43 ]
- SNEP 1.0 (defined by the NFC Forum)
MUST include support for Android Beam [ Resources, 65 ]:
- MUST implement the SNEP default server. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
- Device implementations MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 67 ].
- MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
- MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
- MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
- SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages.
- SHOULD enable Android Beam by default
- MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations must support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 60 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 61 ] specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name "urn:nfc:sn:handover" for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
MUST poll for all supported technologies while in NFC discovery mode.
SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.

(Note that publicly available links are not available for the JIS, ISO, and NFC Forum specifications cited above.)

Android 4.4 introduces support for NFC Host Card Emulation (HCE) mode. If a device implementation does include an NFC controller capable of HCE and Application ID (AID) routing, then it:

MUST report the android.hardware.nfc.hce feature constant
MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 90 ]

Additionally, device implementations MAY include reader/writer support for the following MIFARE technologies.

MIFARE Classic (NXP MF1S503x [ Resources, 44 ], MF1S703x [ Resources, 45 ])
MIFARE Ultralight (NXP MF0ICU1 [ Resources, 46 ], MF0ICU2 [ Resources, 47 ])
NDEF on MIFARE Classic (NXP AN130511 [ Resources, 48 ], AN130411 [ Resources, 49 ])

Note that Android includes APIs for these MIFARE types. If a device implementation supports MIFARE in the reader/writer role, it:

MUST implement the corresponding Android APIs as documented by the Android SDK
MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() method. [ Resources, 37 ] Note that this is not a standard Android feature, and as such does not appear as a constant on the PackageManager class.
MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare feature unless it also implements general NFC support as described in this section

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 37 ], and MUST implement the Android NFC API as a no-op.

As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a protocol-independent data representation format, device implementations MUST implement these APIs even if they do not include support for NFC or declare the android.hardware.nfc feature.

7.4.5。最低網路能力

Device implementations MUST include support for one or more forms of data networking. Specifically, device implementations MUST include support for at least one data standard capable of 200Kbit/sec or greater. Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

Devices MAY implement more than one form of data connectivity.

7.4.6。同步設定

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns "true" [ Resources, 88 ].

7.5。相機

Device implementations SHOULD include a rear-facing camera, and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

7.5.1.後置攝像頭

Device implementations SHOULD include a rear-facing camera. If a device implementation includes a rear-facing camera, it:

MUST have a resolution of at least 2 megapixels
SHOULD have either hardware auto-focus, or software auto-focus implemented in the camera driver (transparent to application software)
MAY have fixed-focus or EDOF (extended depth of field) hardware
MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be lit while an android.hardware.Camera.PreviewCallback instance has been registered on a Camera preview surface, unless the application has explicitly enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes of a Camera.Parameters object. Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback .

7.5.2.前置鏡頭

Device implementations MAY include a front-facing camera. If a device implementation includes a front-facing camera, it:

MUST have a resolution of at least VGA (that is, 640x480 pixels)
MUST NOT use a front-facing camera as the default for the Camera API. That is, the camera API in Android has specific support for front-facing cameras, and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the裝置.
MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in Section 7.5.1.
MUST horizontally reflect (ie mirror) the stream displayed by an app in a CameraPreview, as follows:

If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device's current orientation.
If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation() [ Resources, 50 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
Otherwise, the preview MUST be mirrored along the device's default horizontal axis.

MUST mirror the image displayed by the postview in the same manner as the camera preview image stream. (If the device implementation does not support postview, this requirement obviously does not apply.)
MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3.相機 API 行為

Device implementations MUST implement the following behaviors for the camera-related APIs, for both front- and rear-facing cameras:

If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int) , then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
If an application registers an android.hardware.Camera.PreviewCallback instance and the system calls the onPreviewFrame() method when the preview format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further be in the NV21 encoding format. That is, NV21 MUST be the default.
Device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)

Device implementations MUST implement the full Camera API included in the Android SDK documentation [ Resources, 51 ]), regardless of whether the device includes hardware autofocus or other capabilities. For instance, cameras that lack autofocus MUST still call any registered android.hardware.Camera.AutoFocusCallback instances (even though this has no relevance to a non-autofocus camera.) Note that this does apply to front-facing cameras; for instance, even though most front-facing cameras do not support autofocus, the API callbacks must still be "faked" as described.

Device implementations MUST recognize and honor each parameter name defined as a constant on the android.hardware.Camera.Parameters class, if the underlying hardware supports the feature. If the device hardware does not support a feature, the API must behave as documented. Conversely, Device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters . That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types. For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 78 ]).

Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent whenever a new picture is taken by the camera and the entry of the picture has been added to the media store.

Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent whenever a new video is recorded by the camera and the entry of the picture has been added to the media store.

7.5.4.相機方向

Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen's long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device's natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices.

7.6。記憶體和儲存

7.6.1.最小內存和存儲

Device implementations MUST have at least 340MB of memory available to the kernel and userspace. The 340MB MUST be in addition to any memory dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Device implementations with less than 512MB of memory available to the kernel and userspace MUST return the value "true" for ActivityManager.isLowRamDevice() .

Device implementations MUST have at least 1GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 1GB. Device implementations that run Android are very strongly encouraged to have at least 2GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications may use to download data files [ Resources, 56 ]. The device implementation of the Download Manager MUST be capable of downloading individual files of at least 100MB in size to the default "cache" location.

7.6.2. Shared External Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 1GB in size.

Device implementations MUST be configured with shared storage mounted by default, "out of the box". If the shared storage is not mounted on the Linux path /sdcard , then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MUST enforce as documented the android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. Shared storage MUST otherwise be writable by any application that obtains that permission.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital card. Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps. The upstream Android Open Source Project includes an implementation that uses internal device storage for shared external storage APIs; device implementations SHOULD use this configuration and software implementation.

Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:

The device implementation SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 57 ].
The device implementation SHOULD report a USB device class of 0x00 .
The device implementation SHOULD report a USB interface name of 'MTP'.

If the device implementation lacks USB ports, it MUST provide a host computer with access to the contents of shared storage by some other means, such as a network file system.

It is illustrative to consider two common examples. If a device implementation includes an SD card slot to satisfy the shared storage requirement, a FAT-formatted SD card 1GB in size or larger MUST be included with the device as sold to users, and MUST be mounted by default. Alternatively, if a device implementation uses internal fixed storage to satisfy this requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST NOT allow Android applications to write to the secondary external storage, except for their package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

7.7. USB

Device implementations SHOULD include a USB client port, and SHOULD include a USB host port.

If a device implementation includes a USB client port:

the port MUST be connectable to a USB host with a standard USB-A port
the port SHOULD use the micro USB form factor on the device side. Existing and new devices that run Android are very strongly encouraged to meet these requirements in Android so they will be able to upgrade to the future platform releases
the port SHOULD be centered in the middle of an edge. Device implementations SHOULD either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new devices that run Androidare very strongly encouraged to meet these requirements in Android so they will be able to upgrade to future platform releases.
if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the micro-USB port
it MUST allow a host connected to the device to access the contents of the shared storage volume using either USB mass storage or Media Transfer Protocol
it MUST implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 52 ]
it MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 66 ]
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android are very strongly encouraged to meet these requirements so they will be able to upgrade to the future platform releases
The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. Performance Compatibility

Device implementations MUST meet the key performance metrics of an Android- compatible device defined in the table below:

公制	Performance Threshold	評論
Application Launch Time	The following applications should launch within the specified time. Browser: less than 1300ms Contacts: less than 700ms Settings: less than 700ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

9. 安全模型相容性

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

9.1.權限

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

9.2. UID 和進程隔離

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

9.3.檔案系統權限

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 54 ].

9.4.備用執行環境

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model.具體來說：

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will will resource 。 If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

9.5。多用戶支援

Android includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support [ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]
Android includes support for restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Device implementations that include support for multiple users MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage.

9.6。高級簡訊警告

Android includes support for warning users for any outgoing premium SMS message [ Resources, 73 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

9.7.核心安全特性

The Android Sandbox includes features that can use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features, if implemented below the Android framework:

MUST maintain compatibility with existing applications
MUST not have a visible user interface, even when violations are detected
SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux and meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

it MUST support a SELinux policy that allows the SELinux mode to be set on a per-domain basis with:

domains that are in enforcing mode in the upstream Android Open Source implementation (such as installd, netd, and vold) MUST be in enforcing mode
domain(s) for third-party applications SHOULD remain in permissive mode to ensure continued compatibility

it SHOULD load policy from /sepolicy file on the device
it MUST support dynamic updates of the SELinux policy file without requiring a system image update
it MUST log any policy violations without breaking applications or affecting system behavior

Device implementations SHOULD retain the default SELinux policy provided in the upstream Android Open Source Project, until they have first audited their additions to the SELinux policy. Device implementations MUST be compatible with the upstream Android Open Source Project.

9.8.隱私

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9.9. Full-Disk Encryption

IF the device has lockscreen, the device MUST support full-disk encryption.

10.軟體相容性測試

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1.相容性測試套件

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.4. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2. CTS驗證器

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3.參考應用

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Google Play Store)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. 可更新的軟體

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. 文件變更日誌

The following table contains a summary of the changes to the Compatibility Definition in this release.

部分	Summary of change
3.2.2.建構參數	Revised descriptions of BRAND, DEVICE, and PRODUCT. SERIAL is now required.
3.2.3.5.預設應用程式設定	New section that adds requirement to comply with new default application settings
3.3.1 Application Binary Interfaces	Clarified allowed values for the `android.os.Build.CPU_ABI` and `android.os.Build.CPU_ABI2` parameters.
3.4.1.網頁視圖相容性	Added Chromium as required WebView implementation.
3.7.虛擬機器相容性	Added requirement for xxhdpi and 400dpi screen densities.
3.8.6。主題	Updated to reflect use of translucent system bars.
3.8.12.地點	New section that adds requirement location settings be centralized.
3.8.13.統一碼	New section that adds requirement for emoji support.
3.9.設備管理	Noted preinstalled administrative applications cannot be the default Device Owner application.
5.1.媒體編解碼器	Added VP9 decoder requirement. Added recommended specification for hardware VP8 codecs.
5.3.視訊解碼	Added VP9. Added recommendation for dynamic resolution switching.
5.4.聲音錄製	Added `REMOTE_SUBMIX` as new required audio source. Made use of `android.media.audiofx.NoiseSuppressor` API a requirement.
6.2.1 Experimental	New section that introduces the ART runtime and requires Dalvik as the default runtime.
7.1.1.螢幕配置	Replaced 1.85 aspect ratio with 1.86. Added 400dpi screen density.
7.1.6。 Screen Types	Added 640 dpi (4K) resolution configuration.
7.2.3. Navigation keys	Added Recents function as essential; demoted Menu function in priority.
7.3.6。溫度計	Added SENSOR_TYPE_AMBIENT_TEMPERATURE as recommended thermometer.
7.4.2.2。 Wi-Fi 隧道直接連結設定	New section that adds support for Wi-Fi Tunneled Direct Link Setup (TDLS).
7.4.4.近場通訊	Added Host Card Emulation (HCE) as a requirement. Replaced SNEP GET with Logical Link Control Protocol (LLCP) and added the Bluetooth Object Push Profile as a requirement.
7.4.6。同步設定	New section that adds requirement auto-sync data be enabled by default.
7.6.1.最小內存和存儲	Added `ActivityManager.isLowRamDevice()` setting requirement for devices with less than 512MB of memory. Increased storage requirements from 512MB and 1GB to 1GB and 2GB, respectively.
7.6.2. Shared "External" Storage	Editorial fixes such as change of section name, and moved text that fits in this section from section 9.5. Noted applications may write to their package-specific directories on secondary external storage.
7.7. USB	Added requirement all devices report a USB serial number.
9.5。多用戶支援	Moved non multi-user specific text to section 7.6.2.
9.7.核心安全特性	Rewritten to note switch of SELinux to enforcing mode and requirement SELinux output not be rendered in the user interface.
9.8.隱私	New section that adds requirement audio and video recording must trigger continuous notifications to the user.
9.9. Full-Disk Encryption	New section that adds requirement devices with lockscreen support full-disk encryption.
12. 文件變更日誌	New section that summarizes changes in the CDD by section.

13. 聯絡我們

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.