Android 4.0相容性定義文檔

修訂版 4
最後更新時間：2013 年 4 月 21 日

版權所有 © 2012，Google Inc. 保留所有權利。
相容性@android.com

目錄

一、簡介
2. 資源
3、軟體
4. 應用程式封裝相容性
5. 多媒體相容性
6. 開發者工具相容性
7. 硬體相容性
8. 效能相容性
9. 安全模型相容性
10.軟體相容性測試
11. 可更新的軟體
12. 聯絡我們
附錄 A - 藍牙測試程序

一、簡介

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

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

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

若要被視為與 Android 4.0 相容，裝置實作必須符合本相容性定義中提出的要求，包括透過引用納入的任何文件。

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

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

2. 資源

  1. IETF RFC2119 要求等級： http://www.ietf.org/rfc/rfc2119.txt
  2. Android 相容性計劃概述： http://source.android.com/docs/compatibility/index.html
  3. Android 開源專案：http: //source.android.com/
  4. API定義與文件： http://developer.android.com/reference/packages.html
  5. Android 權限參考： http://developer.android.com/reference/android/Manifest.permission.html
  6. android.os.Build 參考： http://developer.android.com/reference/android/os/Build.html
  7. Android 4.0 允許的版本字串： http://source.android.com/docs/compatibility/4.0/versions.html
  8. 渲染腳本： http://developer.android.com/guide/topics/graphics/renderscript.html
  9. 硬體加速： http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView 類別： http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5 離線功能： http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5 影片標籤： http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C 地理定位 API： http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C 網路資料庫 API： http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB API： http://www.w3.org/TR/IndexedDB/
  17. Dalvik 虛擬機器規格：可在 Android 原始碼中找到，位於 dalvik/docs
  18. 應用程式小工具： http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. 通知： http ://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. 應用程式資源： http://code.google.com/android/reference/available-resources.html
  21. 狀態列圖示樣式指南： http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstruct
  22. 搜尋管理員： http://developer.android.com/reference/android/app/SearchManager.html
  23. 吐司：http: //developer.android.com/reference/android/widget/Toast.html
  24. 主題：http: //developer.android.com/guide/topics/ui/themes.html
  25. R.style類別： http://developer.android.com/reference/android/R.style.html
  26. 動態桌布： https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. Android 裝置管理： http://developer.android.com/guide/topics/admin/device-admin.html
  28. android.app.admin.DevicePolicyManager 類別： http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. Android 輔助使用服務 API： http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android 輔助使用 API： http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. 眼睛免費項目：http: //code.google.com/p/eyes-free
  32. 文字轉語音 API： http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. 參考工具文件（針對adb、aapt、ddms）： http://developer.android.com/guide/developing/tools/index.html
  34. Android apk 檔案說明： http://developer.android.com/guide/topics/fundamentals.html
  35. 清單檔案： http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Monkey測試工具： https://developer.android.com/studio/test/other-testing-tools/monkey
  37. Android android.content.pm.PackageManager 類別和硬體功能清單： http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. 支援多畫面： http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration： http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent： http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. 藍牙 API： http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF 推播協定： http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X： http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X： http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1： http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2： http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511： http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411： http://www.nxp.com/documents/application_note/AN130411.pdf
  50. 相機方向API： http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. android.hardware.Camera：http://developer.android.com/reference/android/hardware/Camera.html
  52. Android 開放配件： http://developer.android.com/guide/topics/usb/accessory.html
  53. USB 主機 API： http://developer.android.com/guide/topics/usb/host.html
  54. Android 安全性與權限參考： http://developer.android.com/guide/topics/security/security.html
  55. 適用於 Android 的應用程式：http: //code.google.com/p/apps-for-android
  56. android.app.DownloadManager 類別： http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android 檔案傳輸：http: //www.android.com/filetransfer
  58. Android 媒體格式： http://developer.android.com/guide/appendix/media-formats.html
  59. HTTP 直播協議草稿： http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. 運動事件 API： http://developer.android.com/reference/android/view/MotionEvent.html
  61. 觸控輸入配置： http://source.android.com/tech/input/touch-devices.html

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

3、軟體

3.1.託管 API 相容性

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

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

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

3.2.軟 API 相容性

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

3.2.1.權限

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

3.2.3.建構參數

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

範圍評論
android.os.Build.VERSION.RELEASE目前執行的 Android 系統的版本，採用人類可讀的格式。該欄位必須具有 [ Resources, 7 ] 中定義的字串值之一。
android.os.Build.VERSION.SDK目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.0.1 - 4.0.2，此欄位必須具有整數值 14。對於 Android 4.0.3 或更高版本，此欄位必須具有整數值 15。
android.os.Build.VERSION.SDK_INT目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.0.1 - 4.0.2，此欄位必須具有整數值 14。對於 Android 4.0.3 或更高版本，此欄位必須具有整數值 15。
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.0/IRK77/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 模式附加特殊權限，或阻止第三方應用程式綁定到這些模式並承擔對這些模式的控制。該禁止具體包括但不限於停用「選擇器」使用者介面，該介面允許使用者在全部處理相同意圖模式的多個應用程式之間進行選擇。

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.txt中定義了許多應用程式二進位介面 (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）
  • 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 的支援。

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

3.4.網路相容性

3.4.1.網頁視圖相容性

Android 開源實作使用 WebKit 渲染引擎來實作android.webkit.WebView 。由於為 Web 渲染系統開發全面的測試套件是不可行的，因此設備實作者必須在 WebView 實作中使用 WebKit 的特定上游版本。具體來說：

  • 裝置實現的android.webkit.WebView實作必須基於 Android 4.0 的上游 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的值相同

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

此外，設備實作必須支援 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：

此外，設備實作必須支援 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
超大平均密度指數32MB
超大電視解析度 / 高清分辨率64MB
超大高畫質像素128MB

3.8.使用者介面相容性

3.8.1.小部件

Android 定義了元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開「AppWidget」[參考資料，18 ]。 Android 開源參考版本包括一個 Launcher 應用程序，其中包含允許用戶在主畫面上新增、檢視和刪除 AppWidget 的使用者介面功能。

設備實作可以取代參考啟動器（即主螢幕）。替代啟動器應該包括對 AppWidget 的內建支持，並公開使用者介面功能以直接在啟動器內新增、配置、檢視和刪除 AppWidget。替代啟動器可以省略這些使用者介面元素；然而，如果它們被省略，裝置實作必須提供一個可從啟動器存取的單獨應用程序，允許使用者新增、配置、檢視和刪除 AppWidget。

設備實作必須能夠渲染標準網格大小為 4 x 4 的小工具。 （有關詳細信息，請參閱 Android SDK 文件 [參考資料，18 ] 中的應用程式小工具設計指南。

3.8.2.通知

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

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

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

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

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

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

3.8.4.吐司

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

3.8.5。主題

Android 提供「主題」作為應用程式在整個 Activity 或應用程式中應用樣式的機制。 Android 3.0 引入了新的「Holo」或「全像」主題，作為一組定義的樣式，供應用程式開發人員在想要匹配 Android SDK 定義的 Holo 主題外觀和感覺時使用[參考資料，24 ]。裝置實作不得更改向應用程式公開的任何 Holo 主題屬性 [參考資料，25 ]。

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

3.8.6。動態壁紙

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

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

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

3.8.7.最近的應用程式顯示

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

3.8.8.輸入管理設定

Android 4.0 包含輸入管理引擎的支援。 Android 4.0 API 允許自訂應用程式 IME 指定使用者可調設定。當顯示提供此類使用者設定的 IME 時，裝置實作必須包括一種讓使用者始終存取 IME 設定的方法。

3.9 設備管理

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

如果裝置實作不支援全部裝置管理策略，則它們不得允許啟用裝置管理應用程式。具體來說，如果裝置不支援所有裝置管理策略，則裝置實作必須回應android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN意圖，但必須顯示一則訊息，通知使用者該裝置不支援裝置管理。

3.10 輔助功能

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

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

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

3.11文字到語音

Android 4.0包括允許應用程式使用文字轉語音（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和開放手機聯盟都沒有做出任何代表，即這些編解碼器不受第三方專利的影響。打算在硬體或軟體產品中使用此原始碼的人請注意，此程式碼的實現（包括在開源軟體或共享軟體中）可能需要相關專利持有者的專利許可。

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

類型格式 /編解碼器編碼器解碼器細節文件類型 /容器格式
聲音的AAC LC/LTP必需的
包括麥克風硬體和定義android.hardware.microphone設備實現所需的。		必需的單聲道/立體聲含量以高達160 kbps的標準位元率和從8到48kHz的取樣率的任何組合
  • 3GPP (.3gp)
  • MPEG-4（.mp4、.m4a）
  • ADTS RAW AAC（.AAC，在Android 3.1+中解碼，在Android 4.0+中編碼，不支援ADIF）
  • mpeg-ts（.ts，不可尋求，Android 3.0+）
HE-AACv1 (AAC+)必需的
HE-AACv2（增強型 AAC+）必需的
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 和 Mobile XMF。支援鈴聲格式 RTTTL/RTX、OTA 和 iMelody
  • 類型 0 和 1（.mid、.xmf、.mxmf）
  • RTTTL/RTX（.rtttl、.rtx）
  • ota（.ota）
  • iMelody (.imy)
沃爾比斯必需的
  • 奧格 (.ogg)
  • 瑪特羅斯卡 (.mkv)
PCM/波必需的8-和16位元線性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.264AVC必需的
包括相機硬體和定義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 2.3.3+）		 WebM （.Webm）和Matroska（.MKV，Android 4.0+）

5.2視訊編碼

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

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

5.3.聲音錄製

當應用程式使用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輸入水準下，總諧波失真應小於1％至4000 Hz。

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

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

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

5.4.音訊延遲

音訊延遲廣泛定義為應用程式請求音訊播放或記錄操作與裝置實現實際開始操作之間的間隔。許多類別的應用程式都依靠短延遲來實現即時效果，例如聲音效果或VoIP通訊。包含麥克風硬體和聲明android.hardware.microphone裝置實作應符合本節中概述的所有音訊延遲要求。有關設備實現可能省略麥克風硬體的條件的詳細信息，請參見第7節。

就本節而言：

  • 「冷輸出延遲」被定義為應用程式請求播放和聲音開始播放時，音訊系統閒置並在請求之前關閉電源之間的間隔
  • 「溫暖的輸出延遲」定義為應用程式請求播放和聲音開始播放時，何時使用音訊系統的時間之間的間隔
  • 「連續輸出延遲」的定義是應用程式發行要播放的樣本與揚聲器物理播放相應聲音的間隔，而該設備當前正在播放音頻
  • 「冷輸入延遲」的定義是應用程式請求錄製和透過其回調傳遞到申請的錄音時，音訊系統和麥克風在請求之前閒置並關閉電源時的間隔
  • 「連續輸入延遲」的定義是在發生環境聲音的情況下以及透過其回調傳遞到錄音應用程式的樣本時，該裝置處於記錄模式

使用上述定義，設備實作應顯示這些屬性：

  • 100毫秒或更少的冷輸出潛伏期
  • 溫暖的輸出潛伏期為10毫秒或更少
  • 連續輸出潛伏期為45毫秒或更少
  • 100毫秒或更少的冷輸入潛伏期
  • 連續輸入延遲為50毫秒或更少

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

如果設備實現符合本節的要求，則可以透過android.content.pm.PackageManager類別報告功能“ android.hardware.audio.low-latency”，透過報告“ android.hardware.audio.low-lat-latency ”的功能來報告對低延遲音訊的支援。 [資源，37 ]相反，如果設備實現不符合這些要求，則不得報告對低延遲音訊的支援。

5.5.網路協定

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

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

6.開發人員工具相容性

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

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

大多數基於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提供。

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.0包括適當地調整應用程式資產和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'）的螢幕尺寸
  • 報告螢幕尺寸「正常」的裝置必須具有至少470 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”
裝置實現應定義標準的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文件中所體現和詳細介紹。裝置實作也必須支援Android SDK文件[資源，8 ]中詳細介紹的Android Renderscript。

設備實作也必須正確地識別為支援OpenGL ES 1.0和2.0。那是：

  • 託管API（例如透過GLES10.getString()方法）必須報告對OpenGL ES 1.0和2.0的支持
  • 本機C/C ++ OpenGL API（即透過Libgles_v1cm.so，Libgles_v2.so或Libegl.so提供的應用程式可用於應用程式的API）必須報告對OpenGL ES 1.0和2.0的支援。

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

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

Android 3.0引入了一種機制，以聲明他們希望透過使用明顯的標籤android:hardwareAccelerated或Direct API呼叫[ Resources，9 ]來啟用2D圖形的硬體加速度。

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

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

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

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

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

7.1.6。螢幕類型

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

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

固定像素設備實現

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

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

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

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

可變像素設備實現

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

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

  • 1280x720（也稱為720p）：“大螢幕尺寸”，“ tvdpi”（213 dpi）密度
  • 1920x1080（也稱為1080p）：“大螢幕尺寸”，“ xhdpi”（320 dpi）密度

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

7.1.7。螢幕技術

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

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

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導航範式至關重要。設備實作必須使這些功能在運行應用程式時始終為使用者提供。這些功能可以透過專用的實體按鈕（例如機械或電容觸控按鈕）實現，也可以使用專用的軟體鍵，手勢，觸控面板等實現。Android4.0支援這兩個實現。

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

  • 設備實施導航鍵必須使用螢幕的不同部分，無法使用應用程序，且不得掩蓋或以其他方式乾擾應用程式可用的螢幕部分。
  • 設備實作必須使顯示的一部分可用於滿足第7.1.1節中定義的要求的應用程式。
  • 當應用程式未指定係統UI模式或指定SYSTEM_UI_FLAG_VISIBLE時，裝置實作必須顯示導航金鑰。
  • 設備實作必須在應用程式指定SYSTEM_UI_FLAG_LOW_PROFILE時，將導航金鑰顯示在不引人注目的「低調」（例如DIM）模式中。
  • 當應用程式指定SYSTEM_UI_FLAG_HIDE_NAVIGATION時，裝置實作必須隱藏導覽金鑰。
  • 當TargetsDkversion <= 10時，裝置實作必須給應用程式鍵鍵，並且當TargetsDkversion> 10時不應顯示選單金鑰。

7.2.4.觸控螢幕輸入

設備實現：

  • 必須具有某種指標輸入系統（類似滑鼠或觸控）
  • 可能具有任何模態的觸控螢幕（例如電容或電阻）
  • 如果觸控螢幕支援多個指針，則應支援完全獨立追蹤的指針
  • 必須報告android.content.res.Configuration.touchscreen [ Resources，40 ]與裝置上特定觸控螢幕的類型相對應的值

Android 4.0包括對各種觸控屏，觸控板和假觸控輸入裝置的支援。基於觸控螢幕的裝置實現與顯示[資源，61 ]相關聯，因此使用者的印像是直接在螢幕上操縱項目。由於使用者直接接觸螢幕，因此系統不需要任何其他負擔來指示被操縱的物件。相較之下，假觸控介面提供了一個近似觸控螢幕功能子集的使用者輸入系統。例如，驅動螢幕遊標的滑鼠或遙控器近似觸摸，但要求使用者首先或聚焦，然後單擊。許多輸入設備，例如滑鼠，觸控板，基於陀螺儀的空氣滑鼠，陀螺儀，操縱桿和多觸控觸控板，都可以支援假觸控互動。 Android 4.0包括功能常數android.hardware.faketouch ，對應於高保真性非接觸式（即基於指針的）輸入設備，例如滑鼠或觸控板，可以充分模擬基於觸控的輸入（包括基本手勢（包括基本的手勢）支援），並指示該裝置支援觸控螢幕功能的模擬子集。聲明假觸摸功能的設備實作必須符合7.2.5節中的假觸摸要求。

設備實現必須報告與所使用的輸入類型相對應的正確功能。包括觸控螢幕（單觸控或更好）的裝置實作也必須報告平台功能Constant android.hardware.faketouch 。不包含觸控螢幕（且僅依賴指標裝置）的裝置實作不得報告任何觸控螢幕功能，且僅在第7.2.5節中符合假觸控要求，則必須僅報告android.hardware.faketouch 。

7.2.5.假觸摸輸入

聲明支持android.hardware.faketouch的設備實現

  • 必須報告指針位置的絕對X和Y螢幕位置，並在螢幕上顯示視覺指針[資源，60 ]
  • 必須以動作代碼報告觸控事件[資源，60 ]，以指定在螢幕上down或up指標上發生的狀態變更[ Resources，60 ]
  • 必須在螢幕上的物件up支援down ，該指針允許使用者在螢幕上的物件上效仿對象
  • 必須在時間閾值中down支援指針，指針up ， down指針，然後在螢幕上的物件上的同一位置上up指針，這使用戶可以在螢幕上的物件上進行雙重點擊[ Resources，60 ]
  • 必須在螢幕上的任意點down支援指針，指針移動到螢幕上的任何其他任意點，然後up指針，這使用戶可以模仿觸摸阻力
  • 必須down支援指針，然後允許用戶快速將物件移至螢幕上的其他位置，然後在螢幕上up指針，這使用戶可以在螢幕上播放對象

聲明支援android.hardware.faketouch.multitouch.distinct的裝置必須符合上述Faketouch的要求，也必須支援兩個或更多獨立的指標輸入的獨特追蹤。

7.2.6。麥克風

設備實作可能會省略麥克風。但是，如果裝置實作省略了麥克風，則不得報告android.hardware.microphone功能常數，並且必須根據第7節將音訊記錄API實作為NO-OPS。相反，確實具有麥克風的設備實現：

  • 必須報告android.hardware.microphone特徵常數
  • 應符合第5.3節的音訊品質要求
  • 應符合第5.4節的音訊延遲要求

7.3.感應器

Android 4.0包括用於存取各種感測器類型的API。設備實作通常可能會省略以下小節中規定的這些感測器。如果裝置包含具有針對第三方開發人員的對應API的特定感測器類型，則裝置實作必須如Android SDK文件中所述實作該API。例如，設備實作：

  • 必須按android.content.pm.PackageManager類別準確地報告感測器的存在或不存在。 [資源，37 ]
  • 必須透過SensorManager.getSensorList()和類似的方法返回準確的受支援感測器的列表
  • 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 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.0 APIs introduce 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.0 SDK documentation to be a streaming sensor.

7.3.1.加速度計

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

  • MUST be able to deliver events at 50 Hz or greater
  • 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)
  • MUST be able to deliver events at 100 Hz or greater
  • 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

7.3.7.溫度計

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

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 [ Resources, 42 ]. Device implementations SHOULD implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as appropriate for the device.

The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-driven Bluetooth test procedure described in Appendix A.

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.0, the Compatibility Definition for a future version is planned to change these to "MUST". That is, these stanards are optional in Android 4.0 but will be required in future versions. Existing and new devices that run Android 4.0 are very strongly encouraged to meet these requirements in Android 4.0 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:
    • 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.
    • 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 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.

Note that Android 4.0 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.0 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 (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.0 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裝置。
  • 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:

  1. 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.
  2. 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.
  3. 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 decoder 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.0 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.

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.也就是說，當設備處於橫向方向時，相機必須以橫向方向捕捉影像。 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 MUST have at least 350MB of non-volatile storage available for application private data.也就是說， /data分區必須至少 350MB。

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.應用程式共享儲存

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
  • 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, 51 ]

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, 52 ]

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.0 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 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.)
  • 備用運行時可以提供一個由所有使用備用運行時的應用程式共享的 Android 沙箱。
  • 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.

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 4.0 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.0. 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 Verfier 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 Android Market)

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

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.

Appendix A - Bluetooth Test Procedure

The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. The procedure requires two devices:

  • a candidate device implementation running the software build to be tested
  • a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

設定和安裝

  1. Build BluetoothChat.apk via 'make samples' from an Android source code tree.
  2. Install BluetoothChat.apk on the known-good device.
  3. Install BluetoothChat.apk on the candidate device.

Test Bluetooth Control by Apps

  1. Launch BluetoothChat on the candidate device, while Bluetooth is disabled.
  2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

Test Pairing and Communication

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
  3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
  4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
  5. Close the BluetoothChat app on both devices by pressing Home .
  6. Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

  1. Launch the Bluetooth Chat app on both devices.
  2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
  3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
  4. Send 10 or messages from each device, and verify that the other device receives them correctly.
  5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

  1. Re-launch the Bluetooth Chat app on both devices.
  2. Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.