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

Android 4.3 相容性定義

修訂版 1
最後更新時間：2013 年 7 月 23 日

一、簡介

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

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

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

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

如果第 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.3 允許的版本字串： http://source.android.com/docs/compatibility/4.3/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/webdatabase/

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/security.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

Wifi 多播 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

Wifi 直連（Wifi 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

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

3、軟體

3.1.託管 API 相容性

託管（基於 Dalvik）執行環境是 Android 應用程式的主要工具。 Android 應用程式介面 (API) 是向在託管 VM 環境中運行的應用程式公開的一組 Android 平台介面。設備實現必須提供 Android 4.3 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.os.Build.VERSION.RELEASE	目前執行的 Android 系統的版本，採用人類可讀的格式。該欄位必須具有 [ Resources, 7 ] 中定義的字串值之一。
android.os.Build.VERSION.SDK	目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.3，此欄位必須具有整數值 18。
android.os.Build.VERSION.SDK_INT	目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.3，此欄位必須具有整數值 18。
android.os.Build.VERSION.INCREMENTAL	裝置實現者選擇的值，以人類可讀的格式指定目前正在執行的 Android 系統的特定版本。該值不得重複用於向最終用戶提供的不同建置。此欄位的典型用途是指示使用哪個版本號或原始碼控制變更標識符來產生版本。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
android.os.Build.BOARD	設備實現者選擇的值，以人類可讀的格式標識設備使用的特定內部硬體。此欄位的一個可能用途是指示為設備供電的板的特定版本。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.BRAND	設備實施者選擇的值，以人類可讀的格式標識生產該設備的公司、組織、個人等的名稱。此欄位的可能用途是指示銷售該設備的 OEM 和/或營運商。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.CPU_ABI	本機程式碼的指令集名稱（CPU 類型 + ABI 約定）。請參閱第 3.3 節：本機 API 相容性。
android.os.Build.CPU_ABI2	本機程式碼的第二指令集（CPU 類型 + ABI 約定）的名稱。請參閱第 3.3 節：本機 API 相容性。
android.os.Build.DEVICE	設備實施者所選擇的值，用於標識設備主體的特定配置或修訂（有時稱為「工業設計」）。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.FINGERPRINT	唯一標識此建置的字串。它應該是合理的人類可讀的。它必須遵循以下模板： `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` 例如： `acme/mydevice/generic:4.3/JRN53/3359:userdebug/test-keys` 指紋不得包含空白字元。如果上述模板中包含的其他字段具有空白字符，則必須在構建指紋中將它們替換為另一個字符，例如下劃線（“_”）字符。此欄位的值必須可編碼為 7 位元 ASCII。
android.os.Build.HARDWARE	硬體的名稱（來自核心命令列或/proc）。它應該是合理的人類可讀的。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.HOST	以人類可讀格式唯一標識建構建構的主機的字串。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
android.os.Build.ID	設備實現者選擇的標識符，用於引用特定版本，採用人類可讀的格式。該欄位可以與 android.os.Build.VERSION.INCRMENTAL 相同，但應該是一個對於最終用戶區分軟體版本足夠有意義的值。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.MANUFACTURER	產品原始設備製造商 (OEM) 的商品名稱。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
android.os.Build.MODEL	設備實現者選擇的值，包含最終使用者已知的設備名稱。此名稱應與設備行銷和銷售給最終用戶時使用的名稱相同。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
android.os.Build.Product	設備實施者選擇的值，包含產品的開發名稱或程式碼名稱 (SKU)。必須是人類可讀的，但不一定供最終用戶查看。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.SERIAL	硬體序號（如果有）。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^([a-zA-Z0-9]{0,20})$"` 。
android.os.Build.TAGS	由設備實現者選擇的以逗號分隔的標籤列表，可進一步區分建置。例如，“未簽名，調試”。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.TIME	表示建構發生時間的時間戳記的值。
android.os.Build.TYPE	由設備實現者選擇的值，指定建置的運行時配置。此欄位應該具有與三種典型 Android 運行時配置相對應的值之一：「user」、「userdebug」或「eng」。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式`"^[a-zA-Z0-9.,_-]+$"` 。
android.os.Build.USER	產生建置的使用者（或自動使用者）的名稱或使用者 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.2 節中引用的每個 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.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 精確報告設備支援的本機應用程式二進位介面 (ABI)
必須僅報告最新版本的 Android NDK（位於文件docs/CPU-ARCH-ABIS.txt中）記錄的 ABI
應使用上游 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 開源實作使用 WebKit 渲染引擎來實作android.webkit.WebView [參考資料，10 ]。由於為 Web 渲染系統開發全面的測試套件是不可行的，因此設備實作者必須在 WebView 實作中使用 WebKit 的特定上游版本。具體來說：

裝置實現的android.webkit.WebView實作必須基於 Android 4.3 的上游 Android 開源樹中的 534.30 WebKit 建置。此版本包括一組針對 WebView 的特定功能和安全性修復。設備實作者可以包括對 WebKit 實作的自訂；但是，任何此類自訂都不得改變 WebView 的行為，包括渲染行為。
WebView 報告的用戶代理字串必須採用以下格式：
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
- $(VERSION) 字串的值必須與android.os.Build.VERSION.RELEASE的值相同
- $(LOCALE) 字串的值應該遵循國家代碼和語言的 ISO 約定，並且應該引用設備目前配置的區域設置
- $(MODEL) 字串的值必須與android.os.Build.MODEL的值相同
- $(BUILD) 字串的值必須與android.os.Build.ID的值相同
- 設備實作可以在用戶代理字串中省略Mobile

WebView 元件應該盡可能支援 HTML5 [參考資料，11 ]。至少，設備實作必須支援與 WebView 中的 HTML5 關聯的每個 API：

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

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

HTML5 API 與所有 JavaScript API 一樣，必須在 WebView 中預設為停用，除非開發人員透過常用的 Android API 明確啟用它們。

3.4.2.瀏覽器相容性

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

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

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

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

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
超大	平均密度指數	32MB
超大	電視解析度 / 高清分辨率	64MB
超大	高畫質像素	128MB

3.8.使用者介面相容性

3.8.1.啟動器（主螢幕）

Android 4.3 包括啟動器應用程式（主螢幕）並支援第三方應用程式來取代裝置啟動器（主螢幕）。允許第三方應用程式替換裝置主畫面的裝置實作必須聲明平台功能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 4.3 支援豐富的通知，例如持續通知的互動式檢視。裝置實作必須正確顯示和執行豐富的通知，如 Android API 中所述。

3.8.4.搜尋

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

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

3.8.5。吐司

應用程式可以使用「 Toast」 API（在[資源，23 ]中定義）向最終用戶顯示短的非模式字串，該字串在短時間後消失。設備實現必須以某種高可見性顯示從應用程式到最終用戶的吐司。

3.8.6。主題

Android提供了「主題」作為應用程式在整個活動或應用程式中應用樣式的機制。 Android 4.3包含一個「 Holo」或「全像」主題，作為一組定義樣式，以供應用程式開發人員使用Android SDK [ Resources，24 ]所定義的Holo主題外觀和感覺，以便使用。設備實作不得改變暴露於應用程式的任何Holo主題屬性[資源，25 ]。

Android 4.3包含一個新的「裝置預設」主題，作為一組定義樣式，供應用程式開發人員使用裝置實現者定義的裝置主題的外觀和感覺，以便使用。設備實作可能會修改暴露於應用程式的DevicedEdefault主題屬性[ Resources，25 ]。

3.8.7.動態壁紙

Android定義了一種元件類型和相應的API和生命週期，該應用程式允許應用程式將一個或多個「 Live Wallpapers」暴露於最終用戶[ Resources，26 ]。即時壁紙是動畫，圖案或類似的圖像，其輸入功能有限，顯示為牆紙，在其他應用程式後面。

如果硬體能夠運行所有即時壁紙，則可以可靠地運行即時壁紙，而無需限制功能，並且在合理的幀率上沒有對其他應用程式不利影響。如果硬體中的限制導致壁紙和/或應用程式崩潰，故障，消耗過多的CPU或電池電量，或以不可接受的較低幀速率運行，則該硬體被認為無法運行Live Wallpaper。例如，某些即時桌布可以使用開放的GL 1.0或2.0上下文來渲染其內容。實時壁紙不會在不支援多個OpenGL上下文的硬體上可靠地運行，因為OpenGL上下文的即時壁紙使用可能與也使用OpenGL上下文的其他應用程式相抵觸。

如上所述，能夠可靠地運行即時壁紙的設備實現應實現即時壁紙。如上所述，確定不可靠地運行即時壁紙的設備實現不得實現即時壁紙。

3.8.8。最近的申請顯示

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

3.8.9。輸入管理

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

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

3.8.10.鎖定螢幕媒體遙控器

Android 4.3包括對遠端控制API的支持，該API可以使媒體應用程式與在遠端視圖中顯示的播放控制項整合在一起，例如裝置鎖定畫面[ Resources，74 ]。支援裝置中鎖定螢幕並允許使用者在主螢幕上新增小工具的裝置實作必須包括支援嵌入裝置鎖定畫面中的遙控器[資源，69 ]。

3.8.11。夢

Android 4.3包括對稱為Dreams的互動式螢幕保護程式的支援[ Resources，76 ]。夢想使用戶可以在閒置設備閒置或停靠在桌上碼頭中時與應用程式進行互動。設備實現必須包括對夢的支持，並為用戶提供設定選項以配置夢想。

3.9設備管理

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

3.10可訪問性

Android 4.3提供了一個可訪問性層，可幫助殘疾用戶更輕鬆地導航其裝置。此外，Android 4.3還提供了平台API，使可訪問性服務實現能夠接收用戶和系統事件的回調，並產生替代的反饋機制，例如文字到語音，觸覺反饋，軌跡球/D-pad導航[ Resources， 29 ] 。設備實作必須提供與預設Android實作一致的Android可訪問性框架的實作。具體而言，設備實作必須滿足以下要求。

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

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

3.11文字到語音

Android 4.3包括允許應用程式使用文字轉語音（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）
	Vorbis		必需的		ogg（.ogg） Matroska（.MKV）
	PCM/WAVE	必需的	必需的	8位元和16位元線性PCM **（速率達到硬體限制）。設備必須支援在8000,16000和44100 Hz頻率的原始PCM記錄的取樣率	波（.wav）
影像	JPEG	必需的	必需的	基礎+漸進式	JPEG (.jpg)
	動圖		必需的		gif（.gif）
	巴布亞紐幾內亞	必需的	必需的		PNG（.png）
	骨形態發生蛋白		必需的		BMP（.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+）***

*注意：僅需5.0/5.1內容的下降；錄製或渲染超過2個頻道是可選的。
**注意：16位元線性PCM捕獲是強制性的。 8位元線性PCM捕獲不是強制性的。
***注意：設備實作應支援編寫Matroska WebM文件。

5.2視訊編碼

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

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

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

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

5.3視訊解碼

Android設備實作應支援以下VP8和H.264視訊解碼設定檔。

	SD（低品質）	SD（高品質）	高清720p （在硬體的支援時）	高清1080p （在硬體的支援時）
視訊解析度	320 x 180 PX	640 x 360 像素	1280 x 720 像素	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.3的“應該”，但計劃將未來版本的兼容性定義更改為“必須”。也就是說，這些要求在Android 4.3中是可選的，但是將來版本將需要。非常強烈鼓勵運行Android 4.3的現有和新設備在Android 4.3中滿足這些要求，否則在升級到未來版本時，它們將無法達到Android相容性。

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

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 4.3包括適當適當調整應用程式資產和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.85（16：9）之間。

螢幕密度

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

120 DPI，稱為“ ldpi”
160 DPI，稱為“ MDPI”
213 DPI，稱為“ TVDPI”
240 DPI，稱為“ HDPI”
320 DPI，稱為“ XHDPI”
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 4.3包含對應用程式的支持，以期指定它們需要特定的OpenGL紋理壓縮格式。這些格式通常是特定於供應商的。 Android 4.3不需要裝置實作來實現任何特定的紋理壓縮格式。但是，他們應透過OpenGL API中的getString()方法準確地報告所支援的任何紋理壓縮格式。

Android 4.3包含一個機制，用於聲明他們希望透過使用明顯的標籤android:hardwareAccelerated或Direct API呼叫來啟用2D圖形的硬體加速度[ Resources，9 ]。

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

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

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

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

7.1.5。舊應用相容模式

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

7.1.6。螢幕類型

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

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

固定像素設備實現

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

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

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

例如，具有10英寸對角線尺寸的平板電腦具有1024x600像素分辨率被認為是固定像素大型MDPI顯示實現。如果它包含一個在720p或1080p下顯示的視頻輸出端口，則設備實現必須擴展輸出，以使輸出縮放applications are only executed in a large mdpi window, regardless of whether the fixed-pixel display or video output port is in use.

Variable-Pixel Device Implementations

Variable-pixel device implementations MUST support one or both of 1280x720, or 1920x1080 (that is, 720p or 1080p). Device implementations with variable-pixel displays MUST NOT support any other screen configuration or mode. Device implementations with variable-pixel screens MAY change screen configuration or mode at runtime or boot-time. For example, a user of a set-top box may replace a 720p display with a 1080p display, and the device implementation may adjust accordingly.

Additionally, variable-pixel device implementations MUST report the following configuration buckets for these pixel dimensions:

1280x720 (also known as 720p): 'large' screen size, 'tvdpi' (213 dpi) density
1920x1080 (also known as 1080p): 'large' screen size, 'xhdpi' (320 dpi) density

For clarity, device implementations with variable pixel dimensions are restricted to 720p or 1080p in Android 4.3, and MUST be configured to report screen size and density buckets as noted above.

7.1.7.螢幕技術

The Android platform includes APIs that allow applications to render rich graphics to the display. Devices MUST support all of these APIs as defined by the Android SDK unless specifically allowed in this document.具體來說：

Devices MUST support displays capable of rendering 16-bit color graphics and SHOULD support displays capable of 24-bit color graphics.
Devices MUST support displays capable of rendering animations.
The display technology used MUST have a pixel aspect ratio (PAR) between 0.9 and 1.1. That is, the pixel aspect ratio MUST be near square (1.0) with a 10% tolerance.

7.1.8。 External Displays

Android 4.3 includes support for secondary display to enable media sharing capabilities and developer APIs for accessing external displays. If a device supports an external display either via a wired, wireless or an embedded additional display connection then the device implementation MUST implement the display manager API as described in the Android SDK documentation [ Resources, 75 ]. Device implementations that support secure video output and are capable of supporting secure surfaces MUST declare support for Display.FLAG_SECURE . Specifically, device implementations that declare support for Display.FLAG_SECURE , MUST support HDCP 2.x or higher for Miracast wireless displays or HDCP 1.2 or higher for wired displays. The upstream Android open source implementation includes support for wireless (Miracast) and wired (HDMI) displays that satisfies this requirement.

7.2.輸入裝置

7.2.1.鍵盤

設備實現：

MUST include support for the Input Management Framework (which allows third party developers to create Input Management Engines - ie soft keyboard) as detailed at http://developer.android.com
MUST provide at least one soft keyboard implementation (regardless of whether a hard keyboard is present)
MAY include additional soft keyboard implementations
MAY include a hardware keyboard
MUST NOT include a hardware keyboard that does not match one of the formats specified in android.content.res.Configuration.keyboard [ Resources, 40 ] (that is, QWERTY, or 12-key)

設備實現：

MAY omit a non-touch navigation option (that is, may omit a trackball, d-pad, or wheel)
MUST report the correct value for android.content.res.Configuration.navigation [ Resources, 40 ]
MUST provide a reasonable alternative user interface mechanism for the selection and editing of text, compatible with Input Management Engines. The upstream Android open source implementation includes a selection mechanism suitable for use with devices that lack non-touch navigation inputs.

The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times when running applications. These functions MAY be implemented via dedicated physical buttons (such as mechanical or capacitive touch buttons), or MAY be implemented using dedicated software keys, gestures, touch panel, etc. Android 4.3 supports both implementations.

Android 4.3 includes support for assist action [ Resources, 63 ]. Device implementations MUST make the assist action available to the user at all times when running applications. This function MAY be implemented via hardware or software keys.

Device implementations MAY use a distinct portion of the screen to display the navigation keys, but if so, MUST meet these requirements:

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 .
Device implementation MUST present a Menu key to applications when targetSdkVersion <= 10 and SHOULD NOT present a Menu key when the targetSdkVersion > 10.

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 4.3 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 4.3 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.

The Android 4.3 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 4.3 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.3, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in Android 4.3 but will be required in future versions. Existing and new devices that run Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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.3, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in Android 4.3 but will be required in future versions. Existing and new devices that run Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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 but SHOULD NOT include a thermometer (ie temperature sensor.) If a device implementation does include a thermometer, it MUST measure the temperature of the device CPU. It MUST NOT measure any other temperature. (Note that this sensor type is deprecated in the Android 4.3 APIs.)

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 4.3 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 4.3 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 4.3 MAY be used on devices that do not include telephony hardware. That is, Android 4.3 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 (WiFi)

Android 4.3 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 Wifi 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 Wifi direct (Wifi peer-to-peer). If a device implementation does include support for Wifi direct, it MUST implement the corresponding Android API as described in the SDK documentation [ Resources, 68 ]. If a device implementation includes support for Wifi direct, then it:

MUST support regular Wifi operation
SHOULD support concurrent wifi and wifi Direct operation

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 docum. 42 ]。

7.4.4. Near-Field Communications

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" for Android 4.3, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these standards are optional in Android 4.3 but will be required in future versions. Existing and new devices that run Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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 SHOULD use SNEP GET requests for exchanging the handover request / select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer.
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.)

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 4.3 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 4.3 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。 Minimum Network Capability

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 (WiFi).

Devices MAY implement more than one form of data connectivity.

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 4.3 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 ifly camera as the default rear-facing camera, even裝置。
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. Camera API Behavior

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 4.3 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. Camera Orientation

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. Minimum Memory and Storage

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 MUST have at least 512MB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 512MB. Device implementations that run Android 4.3 are very strongly encouraged to have at least 1GB 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. Application Shared 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.

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) SHOULD modify the core applications such as the media scanner and ContentProvider to transparently support files placed in both locations.

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 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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 Android 4.3 are very strongly encouraged to meet these requirements in Android 4.3 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 4.3 are very strongly encouraged to meet these requirements in Android 4.3 so they will be able to upgrade to the future platform releases

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 4.3 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. Security Model Compatibility

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 and Process Isolation

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. Alternate Execution Environments

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。 Multi-User Support

Android 4.3 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 4.3 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. The upstream Android Open Source Project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage.

9.6. Premium SMS Warning

Android 4.3 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. Kernel Security Features

The Android Sandbox in Android 4.3 includes features that can use the SELinux mandatory access control system (MAC) and other security features in the Linux kernel. Device implementations MUST support SELinux MAC. Note that the upstream Android Open Source Project provides an implementation that satisfies this requirement.

SELinux or any security features implemented below the Android framework MUST maintain compatibility with existing applications. These features SHOULD be invisible to users and developers. These features 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. To ensure continued compatibility the reference implementation allows the use of SELinux in a permissive mode and supports dynamic policy updates without requiring a system image update. Device implementations using SELinux MUST support this permissive mode, support dynamic policy updates and log any policy violations without breaking applications or affecting system behavior. Implementations using SELinux SHOULD load policy from /sepolicy file on the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement. Device implementations SHOULD use the reference implementation in the Android Open Source Project, and device implementations MUST be compatible with the upstream Android Open Source Project.

10. Software Compatibility Testing

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 4.3 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.3. 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. Reference Applications

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. Updatable Software

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. 聯絡我們

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.