Android 2.2 兼容性定義

版權所有 © 2010，谷歌公司。保留所有權利。
compatibility@android.com

目錄

一、簡介

本文檔列舉了手機要兼容 Android 2.2 必須滿足的要求。

“必須”、“不得”、“要求”、“應”、“不應”、“應該”、“不應該”、“推薦”、“可以”和“可選”的使用符合 IETF 標準在 RFC2119 [資源，1 ] 中定義。

在本文檔中，“設備實施者”或“實施者”是指開發運行 Android 2.2 的硬件/軟件解決方案的個人或組織。 “設備實現”或“實現”是這樣開發的硬件/軟件解決方案。

要被視為與 Android 2.2 兼容，設備實現：

• 必須滿足此兼容性定義中提出的要求，包括通過引用合併的任何文檔。
• 必須通過設備實現軟件完成時可用的最新版本的 Android 兼容性測試套件 (CTS)。 （CTS 作為 Android 開源項目 [參考資料 2 ] 的一部分提供。）CTS 測試許多（但不是全部）本文檔中概述的組件。

如果此定義或 CTS 是沉默的、模棱兩可的或不完整的，則設備實施者有責任確保與現有實施的兼容性。出於這個原因，Android 開源項目 [參考資料，3 ] 是 Android 的參考和首選實現。強烈鼓勵設備實施者將他們的實施建立在 Android 開源項目提供的“上游”源代碼的基礎上。雖然假設某些組件可以用替代實現替換，但強烈不鼓勵這種做法，因為通過 CTS 測試將變得更加困難。實施者有責任確保與標準 Android 實施的完全行為兼容性，包括並超出兼容性測試套件。最後，請注意本文檔明確禁止某些組件替換和修改。

2.資源

1. IETF RFC2119 要求級別： http ://www.ietf.org/rfc/rfc2119.txt
2. Android 兼容性程序概述：http: //source.android.com/compatibility/index.html
3. 安卓開源項目：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 2.2 允許的版本字符串：http: //source.android.com/compatibility/2.2/versions.html
8. android.webkit.WebView類：http: //developer.android.com/reference/android/webkit/WebView.html
9. HTML5：http: //www.whatwg.org/specs/web-apps/current-work/multipage/
10. Dalvik 虛擬機規範：在 Android 源代碼中可用，位於 dalvik/docs
11. AppWidgets：http: //developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. 通知：http: //developer.android.com/guide/topics/ui/notifiers/notifications.html
13. 應用資源： http ://code.google.com/android/reference/available-resources.html
14. 狀態欄圖標樣式指南：http: //developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. 搜索管理器：http: //developer.android.com/reference/android/app/SearchManager.html
16. 敬酒：http: //developer.android.com/reference/android/widget/Toast.html
17. 動態壁紙： https ://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. 適用於 Android 的應用程序： http ://code.google.com/p/apps-for-android
19. 參考工具文檔（adb、aapt、ddms）：http: //developer.android.com/guide/developing/tools/index.html
20. 安卓apk文件說明：http: //developer.android.com/guide/topics/fundamentals.html
21. 清單文件：http: //developer.android.com/guide/topics/manifest/manifest-intro.html
22. 猴子測試工具： https ://developer.android.com/studio/test/other-testing-tools/monkey
23. Android 硬件功能列表：http: //developer.android.com/reference/android/content/pm/PackageManager.html
24. 支持多屏幕：http: //developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration：http: //developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics：http: //developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera：http://developer.android.com/reference/android/hardware/Camera.html
28. 傳感器坐標空間：http: //developer.android.com/reference/android/hardware/SensorEvent.html
29. Android 安全和權限參考：http: //developer.android.com/guide/topics/security/security.html
30. 藍牙 API：http: //developer.android.com/reference/android/bluetooth/package-summary.html

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

3. 軟件

Android 平台包括一組託管 API、一組本機 API 和一組所謂的“軟”API，例如 Intent 系統和 Web 應用程序 API。本節詳細介紹了兼容性不可或缺的硬 API 和軟 API，以及某些其他相關的技術和用戶界面行為。設備實現必須符合本節中的所有要求。

3.1.託管 API 兼容性

託管（基於 Dalvik）執行環境是 Android 應用程序的主要載體。 Android 應用程序編程接口 (API) 是暴露給在託管 VM 環境中運行的應用程序的一組 Android 平台接口。設備實現必須提供 Android 2.2 SDK [參考資料，4 ] 公開的任何已記錄 API 的完整實現，包括所有已記錄的行為。

設備實現不得省略任何託管 API、更改 API 接口或簽名、偏離記錄的行為或包含空操作，除非本兼容性定義明確允許。

3.2.軟 API 兼容性

除了第 3.1 節中的託管 API 之外，Android 還包括一個重要的僅限運行時的“軟”API，其形式為 Intents、權限和 Android 應用程序的類似方面，這些方面不能在應用程序編譯時強制執行。本節詳細介紹了與 Android 2.2 兼容所需的“軟”API 和系統行為。設備實現必須滿足本節中提出的所有要求。

3.2.1.權限

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

3.2.2.構建參數

Android API 在android.os.Build類 [ Resources, 6 ] 中包含許多常量，這些常量旨在描述當前設備。為了在設備實現中提供一致的、有意義的值，下表包括對設備實現必須遵守的這些值的格式的額外限制。

3.2.3.意圖兼容性

Android 使用 Intents 來實現應用程序之間的鬆散耦合集成。本節描述了與設備實現必須遵守的 Intent 模式相關的要求。 “榮譽”意味著設備實現者必須提供一個 Android 活動或服務，指定一個匹配的 Intent 過濾器並綁定到每個指定的 Intent 模式並為每個指定的 Intent 模式實現正確的行為。

3.2.3.1.核心應用意圖

Android 上游項目定義了一些核心應用程序，例如電話撥號器、日曆、通訊錄、音樂播放器等。設備實施者可以用替代版本替換這些應用程序。

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

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

• 台鐘
• 瀏覽器
• 日曆
• 計算器
• 相機
• 聯繫人
• 電子郵件
• 畫廊
• 全球搜索
• 啟動器
• LivePicker（即動態壁紙選擇器應用程序；如果設備不支持動態壁紙，根據第 3.8.5 節可以省略。）
• 消息（又名“彩信”）
• 音樂
• 電話
• 設置
• 錄音機

核心 Android 系統應用程序包括各種被認為是“公共”的 Activity 或 Service 組件。也就是說，屬性“android:exported”可能不存在，或者可能具有值“true”。

對於核心 Android 系統應用之一中定義的每個活動或服務，如果未通過值為“false”的 android:exported 屬性標記為非公共，設備實現必須包含實現相同 Intent 過濾器的相同類型的組件patterns 作為核心的 Android 系統應用程序。

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

3.2.3.2.意圖覆蓋

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

3.2.3.3.意圖命名空間

設備實現者不得在 android.* 命名空間中包含任何使用 ACTION、CATEGORY 或其他鍵字符串來支持任何新 Intent 或 Broadcast Intent 模式的 Android 組件。設備實現者不得在屬於另一個組織的包空間中包含任何使用 ACTION、CATEGORY 或其他鍵字符串來支持任何新 Intent 或 Broadcast Intent 模式的 Android 組件。設備實施者不得更改或擴展第 3.2.3.1 節中列出的核心應用程序使用的任何 Intent 模式。

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

3.2.3.4.廣播意圖

第三方應用依賴平台廣播某些Intent，通知自身硬件或軟件環境的變化。 Android 兼容設備必須廣播公共廣播 Intent 以響應適當的系統事件。 SDK 文檔中描述了廣播意圖。

3.3.本機 API 兼容性

在 Dalvik 中運行的託管代碼可以調用應用程序 .apk 文件中提供的本機代碼，作為針對相應設備硬件架構編譯的 ELF .so 文件。設備實現必須包括對在託管環境中運行的代碼的支持，以使用標準 Java 本機接口 (JNI) 語義調用本機代碼。以下 API 必須可用於本機代碼：

• libc（C 庫）
• libm（數學庫）
• JNI接口
• libz（Zlib 壓縮）
• liblog（Android 日誌記錄）
• 對 C++ 的最小支持
• 支持 OpenGL，如下所述

設備實現必須支持 OpenGL ES 1.0。缺少硬件加速的設備必須使用軟件渲染器實現 OpenGL ES 1.0。設備實現應該盡可能多地實現設備硬件支持的 OpenGL ES 1.1。如果硬件能夠在這些 API 上實現合理的性能，設備實現應該提供 OpenGL ES 2.0 的實現。

這些庫必須與 Android 開源項目在 Bionic 中提供的版本源代碼兼容（即標頭兼容）和二進制兼容（對於給定的處理器架構）。由於 Bionic 實現與其他實現（例如 GNU C 庫）不完全兼容，因此設備實現者應該使用 Android 實現。如果設備實現者使用這些庫的不同實現，他們必須確保標頭、二進制和行為兼容性。

設備實現必須通過android.os.Build.CPU_ABI API 準確報告設備支持的本機應用程序二進制接口 (ABI)。 ABI 必須是最新版本的 Android NDK 中記錄的條目之一，在文件docs/CPU-ARCH-ABIS.txt中。請注意，其他版本的 Android NDK 可能會引入對其他 ABI 的支持。

本機代碼兼容性具有挑戰性。出於這個原因，應該重申，非常強烈地鼓勵設備實現者使用上面列出的庫的上游實現來幫助確保兼容性。

3.4.網絡兼容性

許多開發人員和應用程序的用戶界面依賴於android.webkit.WebView類 [ Resources, 8 ] 的行為，因此 WebView 實現必須在 Android 實現之間兼容。同樣，完整的網絡體驗是 Android 用戶體驗的核心。設備實現必須包括與上游 Android 軟件一致的android.webkit.WebView版本，並且必須包括支持 HTML5 的現代瀏覽器，如下所述。

3.4.1. Web 視圖兼容性

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

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

WebView 配置必須包括對 HTML5 數據庫、應用程序緩存和地理定位 API 的支持 [參考資料，9 ]。 WebView 必須包含對 HTML5 <video>標籤的支持。與所有 JavaScript API 一樣，HTML5 API 必須在 WebView 中默認禁用，除非開發人員通過常用的 Android API 明確啟用它們。

3.4.2.瀏覽器兼容性

設備實現必須包括一個獨立的瀏覽器應用程序，供一般用戶瀏覽網頁。獨立瀏覽器可以基於 WebKit 以外的瀏覽器技術。然而，即使發布了備用瀏覽器應用程序，提供給第三方應用程序的android.webkit.WebView組件也必須基於 WebKit，如第 3.4.1 節所述。

實現可以在獨立的瀏覽器應用程序中提供自定義用戶代理字符串。

獨立的瀏覽器應用程序（無論是基於上游 WebKit 瀏覽器應用程序還是第三方替代品）應該盡可能多地支持 HTML5 [參考資料，9 ]。至少，設備實現必須支持 HTML5 地理定位、應用程序緩存和數據庫 API 以及獨立瀏覽器應用程序中的 <video> 標記。

3.5. API 行為兼容性

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

• 設備不得更改標準 Intent 的行為或含義
• 設備不得改變特定類型系統組件（例如服務、活動、內容提供者等）的生命週期或生命週期語義
• 設備不得更改特定權限的語義

上面的列表並不全面，設備實施者有責任確保行為兼容性。出於這個原因，設備實施者應該盡可能使用通過 Android 開源項目提供的源代碼，而不是重新實施系統的重要部分。

兼容性測試套件 (CTS) 測試平台的重要部分的行為兼容性，但不是全部。實施者有責任確保與 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 添加到其他公司的命名空間。

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

請注意，上述限制對應於 Java 編程語言中命名 API 的標準約定；本節的目的只是為了加強這些約定，並通過將它們包含在此兼容性定義中來使其具有約束力。

3.7.虛擬機兼容性

設備實現必須支持完整的 Dalvik 可執行 (DEX) 字節碼規範和 Dalvik 虛擬機語義 [參考資料，10 ]。

具有分類為中密度或低密度屏幕的設備實現必須配置 Dalvik 為每個應用程序分配至少 16MB 的內存。具有歸類為高密度屏幕的設備實現必須配置 Dalvik 為每個應用程序分配至少 24MB 的內存。請注意，設備實現可能會分配比這些數字更多的內存。

3.8.用戶界面兼容性

Android 平台包含一些開發人員 API，允許開發人員掛接到系統用戶界面。設備實現必須將這些標準 UI API 合併到他們開發的自定義用戶界面中，如下所述。

3.8.1.小部件

Android 定義了一種組件類型以及相應的 API 和生命週期，允許應用程序向最終用戶公開“AppWidget”[參考資料，11 ]。 Android 開源參考版本包括一個 Launcher 應用程序，該應用程序包含允許用戶從主屏幕添加、查看和刪除 AppWidgets 的用戶界面元素。

設備實施者可以替代參考啟動器（即主屏幕）。替代啟動器應該包括對 AppWidgets 的內置支持，並公開用戶界面元素以直接在啟動器中添加、配置、查看和刪除 AppWidgets。替代啟動器可以省略這些用戶界面元素；然而，如果它們被省略，設備實現者必須提供一個單獨的應用程序，可以從啟動器訪問，允許用戶添加、配置、查看和刪除 AppWidgets。

3.8.2.通知

Android 包含允許開發人員通知用戶重要事件的 API [參考資料，12 ]。設備實施者必須為如此定義的每一類通知提供支持；特別是：聲音、振動、燈光和狀態欄。

此外，實現必須正確呈現 API [ Resources, 13 ] 或狀態欄圖標樣式指南 [ Resources, 14 ] 中提供的所有資源（圖標、聲音文件等）。設備實施者可以為通知提供替代用戶體驗，而不是參考 Android 開源實施所提供的體驗；然而，這樣的替代通知系統必須支持現有的通知資源，如上所述。

3.8.3.搜索

Android 包含 API [參考資料，15 ]，允許開發人員將搜索合併到他們的應用程序中，並將他們的應用程序數據公開到全局系統搜索中。一般來說，此功能包含一個單一的系統級用戶界面，允許用戶輸入查詢、在用戶鍵入時顯示建議並顯示結果。 Android API 允許開發人員重用此接口以在他們自己的應用程序中提供搜索，並允許開發人員向通用的全局搜索用戶界面提供結果。

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

設備實現可以提供備用搜索用戶界面，但應該包含一個硬或軟專用搜索按鈕，可以在任何應用程序中隨時使用它來調用搜索框架，其行為在 API 文檔中提供。

3.8.4.乾杯

應用程序可以使用“Toast”API（在 [參考資料，16 ] 中定義）向最終用戶顯示短的非模態字符串，這些字符串會在短時間後消失。設備實現必須以某種高可見性方式向最終用戶顯示來自應用程序的 Toast。

3.8.5.動態壁紙

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

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

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

4.參考軟件兼容性

設備實施者必須使用以下開源應用程序測試實施兼容性：

• 計算器（包含在 SDK 中）
• 月球著陸器（包含在 SDK 中）
• “Apps for Android”應用程序 [參考資料，18 ]。
• Replica Island（在 Android Market 中可用；僅支持 OpenGL ES 2.0 的設備實現需要）

上面的每個應用程序都必須啟動並在實現上正確運行，以使實現被認為是兼容的。

此外，設備實現必須測試每個冒煙測試應用程序的每個菜單項（包括所有子菜單）：

• ApiDemos（包含在SDK中）
• ManualSmokeTests（包含在 CTS 中）

上述應用程序中的每個測試用例都必須在設備實現上正確運行。

5. 應用打包兼容性

設備實現必須安裝並運行由官方 Android SDK 中包含的“aapt”工俱生成的 Android“.apk”文件 [參考資料，19 ]。

設備實現不得擴展 .apk [ Resources, 20 ]、Android Manifest [ Resources, 21 ] 或 Dalvik 字節碼 [ Resources, 10 ] 格式，以防止這些文件在其他兼容設備上正確安裝和運行.設備實現者應該使用 Dalvik 的參考上游實現，以及參考實現的包管理系統。

6. 多媒體兼容性

設備實現必須完全實現所有多媒體 API。設備實現必須包括對下述所有多媒體編解碼器的支持，並且應符合下述聲音處理準則。

6.1.媒體編解碼器

設備實現必須支持以下多媒體編解碼器。所有這些編解碼器都作為軟件實現在 Android 開源項目的首選 Android 實現中提供。

請注意，Google 和開放手機聯盟均未就這些編解碼器不受第三方專利的約束作出任何聲明。那些打算在硬件或軟件產品中使用此源代碼的人請注意，此代碼的實施（包括在開源軟件或共享軟件中）可能需要相關專利持有人的專利許可。

請注意，上表並未列出大多數視頻編解碼器的具體比特率要求。這樣做的原因是，在實踐中，當前的設備硬件不一定支持精確映射到相關標準規定的所需比特率的比特率。相反，設備實現應該支持硬件上實際可行的最高比特率，達到規範定義的限制。

6.2.聲音錄製

當應用程序使用android.media.AudioRecord API 開始錄製音頻流時，設備實現應該使用以下每個行為採樣和錄製音頻：

• 降噪處理，如果存在，應該被禁用。
• 自動增益控制（如果存在）應該被禁用。
• 該設備應該表現出近似平坦的振幅與頻率特性；具體來說，±3 dB，從 100 Hz 到 4000 Hz
• 應設置音頻輸入靈敏度，使 1000 Hz 的 90 dB 聲功率級 (SPL) 源產生 16 位樣本的 RMS 為 5000。
• PCM 振幅水平應該線性跟踪輸入 SPL 在至少 30 dB 的範圍內從 -18 dB 到 +12 dB 再到麥克風的 90 dB SPL。
• 在 90 dB SPL 輸入電平下，從 100 Hz 到 4000 Hz 的總諧波失真應小於 1%。

注意：雖然上述要求在 Android 2.2 中被表述為“應該”，但未來版本的兼容性定義計劃將這些要求更改為“必須”。也就是說，這些要求在 Android 2.2 中是可選的，但在未來的版本中將是必需的。強烈建議運行 Android 2.2 Android 的現有設備和新設備在 Android 2.2 中滿足這些要求，否則在升級到未來版本時將無法獲得 Android 兼容性。

6.3.音頻延遲

音頻延遲被廣泛定義為應用程序請求音頻播放或錄製操作與設備實現實際開始操作之間的時間間隔。許多類別的應用程序都依賴於短延遲來實現實時效果，例如音效或 VOIP 通信。設備實現應滿足本節中概述的所有音頻延遲要求。

就本節而言：

• “冷輸出延遲”被定義為應用程序請求音頻播放和聲音開始播放之間的時間間隔，此時音頻系統在請求之前處於空閒和斷電狀態
• “暖輸出延遲”定義為應用程序請求音頻播放和聲音開始播放之間的間隔，音頻系統最近被使用但當前處於空閒狀態（即無聲）
• “連續輸出延遲”定義為應用程序發出要播放的樣本與揚聲器實際播放相應聲音之間的間隔，同時設備當前正在播放音頻
• “冷輸入延遲”被定義為應用程序請求錄音與第一個樣本通過其回調傳遞給應用程序之間的時間間隔，此時音頻系統和麥克風在請求之前處於空閒狀態並已關閉
• “連續輸入延遲”被定義為當環境聲音出現時，當與該聲音對應的樣本通過其回調傳送到錄音應用程序時，同時設備處於錄音模式

使用上述定義，設備實現應該展示以下每個屬性：

• 100 毫秒或更短的冷輸出延遲
• 10 毫秒或更短的暖輸出延遲
• 45 毫秒或更短的連續輸出延遲
• 100 毫秒或更短的冷輸入延遲
• 50 毫秒或更短的連續輸入延遲

注意：雖然上述要求在 Android 2.2 中被表述為“應該”，但未來版本的兼容性定義計劃將這些要求更改為“必須”。也就是說，這些要求在 Android 2.2 中是可選的，但在未來的版本中將是必需的。強烈建議運行 Android 2.2 Android 的現有設備和新設備在 Android 2.2 中滿足這些要求，否則在升級到未來版本時將無法獲得 Android 兼容性。

7. 開發工具兼容性

設備實現必須支持 Android SDK 中提供的 Android 開發者工具。具體來說，Android 兼容設備必須兼容：

• Android 調試橋（稱為 adb） [資源，19 ]
  設備實現必須支持 Android SDK 中記錄的所有adb函數。默認情況下，設備端adb守護進程應該處於非活動狀態，但必須有一個用戶可訪問的機制來打開 Android 調試橋。
• Dalvik 調試監控服務（稱為 ddms） [資源，19 ]
  設備實現必須支持 Android SDK 中記錄的所有ddms功能。由於ddms使用adb ，默認情況下對ddms的支持應該處於非活動狀態，但必須在用戶激活 Android Debug Bridge 時支持，如上所述。
• Monkey [資源, 22 ]
  設備實現必須包含 Monkey 框架，並使其可供應用程序使用。

8. 硬件兼容性

Android 旨在支持設備實現者創建創新的外形和配置。同時，Android 開發人員希望某些硬件、傳感器和 API 能夠跨所有 Android 設備。本節列出了所有 Android 2.2 兼容設備必須支持的硬件功能。

如果設備包含具有第三方開發者相應 API 的特定硬件組件，則設備實現必須按照 Android SDK 文檔中的定義實現該 API。如果 SDK 中的 API 與聲明為可選的硬件組件交互，而設備實現不擁有該組件：

• 組件 API 的類定義必須存在
• API 的行為必須以某種合理的方式實現為空操作
• API 方法必須在 SDK 文檔允許的情況下返回空值
• API 方法必須返回 SDK 文檔不允許空值的類的無操作實現

這些要求適用的場景的一個典型示例​​是電話 API：即使在非電話設備上，這些 API 也必須作為合理的空操作來實現。

設備實現必須通過android.content.pm.PackageManager類上的getSystemAvailableFeatures()和hasSystemFeature(String)方法準確報告準確的硬件配置信息。 [資源, 23 ]

8.1.展示

Android 2.2 包括在某些情況下執行某些自動縮放和轉換操作的工具，以確保第三方應用程序在各種硬件配置上運行良好 [參考資料，24 ]。設備必須正確實現這些行為，如本節所述。

對於 Android 2.2，這些是最常見的顯示配置：

對應於上述標準配置之一的設備實現必須配置為通過android.content.res.Configuration [ Resources, 24 ] 類向應用程序報告指示的屏幕尺寸。

一些 .apk 包的清單沒有將它們標識為支持特定的密度範圍。運行此類應用程序時，以下限制適用：

• 設備實現必須將 .apk 中缺少密度限定符的資源解釋為默認為“中”（在 SDK 文檔中稱為“mdpi”。）
• 在“低”密度屏幕上運行時，設備實現必須按 0.75 倍縮小 medium/mdpi 資產。
• 在“高”密度屏幕上運行時，設備實現必須將中/mdpi 資產放大 1.5 倍。
• 設備實現不得在密度範圍內縮放資產，並且必須在密度範圍之間準確地按這些因素縮放資產。

8.1.2.非標準顯示配置

與第 8.1.1 節中列出的標準配置之一不匹配的顯示配置需要額外考慮並努力兼容。設備實現者必須按照第 13 節中的描述聯繫 Android 兼容性團隊，以獲得屏幕尺寸桶、密度和比例因子的分類。當提供此信息時，設備實現必須按規定實現它們。

請注意，某些顯示配置（例如非常大或非常小的屏幕以及某些縱橫比）從根本上與 Android 2.2 不兼容；因此，我們鼓勵設備實施者在開發過程中儘早聯繫 Android 兼容性團隊。

8.1.3.顯示指標

設備實現必須為android.util.DisplayMetrics [資源，26 ] 中定義的所有顯示指標報告正確的值。

8.1.4.聲明的屏幕支持

應用程序可以通過 AndroidManifest.xml 文件中的<supports-screens>屬性指示它們支持的屏幕尺寸。如 Android SDK 文檔中所述，設備實現必須正確遵守應用程序聲明的對小、中和大屏幕的支持。

8.2.鍵盤

設備實現：

• 必須包括對輸入管理框架的支持（它允許第三方開發人員創建輸入管理引擎——即軟鍵盤），詳見 developer.android.com
• 必須提供至少一種軟鍵盤實現（無論是否存在硬鍵盤）
• 可能包括額外的軟鍵盤實現
• 可能包括硬件鍵盤
• 不得包含與android.content.res.Configuration.keyboard [ Resources, 25 ] 中指定的格式之一不匹配的硬件鍵盤（即 QWERTY 或 12 鍵）

8.3.非觸摸導航

設備實現：

• 可以省略非觸摸導航選項（即可以省略軌跡球、方向鍵或滾輪）
• 必須報告android.content.res.Configuration.navigation [資源，25 ] 的正確值

8.4.屏幕方向

兼容設備必須支持應用程序動態定位為縱向或橫向屏幕方向。也就是說，設備必須尊重應用程序對特定屏幕方向的請求。設備實現可以選擇縱向或橫向作為默認方向。

每當通過 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查詢時，設備必須報告設備當前方向的正確值。

8.5.觸摸屏輸入

設備實現：

• 必須有觸摸屏
• 可能有電容式或電阻式觸摸屏
• 必須報告android.content.res.Configuration [ Resources, 25 ] 的值，反映對應於設備上特定觸摸屏的類型
• 如果觸摸屏支持多個指針，則應支持完全獨立跟踪的指針

8.6. USB

設備實現：

• 必須實現 USB 客戶端，可連接到具有標準 USB-A 端口的 USB 主機
• 必須通過 USB 實現 Android 調試橋（如第 7 節所述）
• 必須實現 USB 大容量存儲規範，以允許連接到設備的主機訪問 /sdcard 卷的內容
• 應在設備端使用微型 USB 外形規格
• 可以在設備端包含一個非標準端口，但如果是這樣的話，必須隨附一根能夠將自定義引出線連接到標準 USB-A 端口的電纜
• 應實現對 USB 大容量存儲規範的支持（以便可以從主機 PC 訪問設備上的可移動或固定存儲）

8.7.導航鍵

Home、Menu 和 Back 功能對於 Android 導航範例是必不可少的。設備實現必須使這些功能始終可供用戶使用，無論應用程序狀態如何。這些功能應該通過專用按鈕實現。它們可以使用軟件、手勢、觸摸屏等來實現，但如果是這樣的話，它們必須始終可訪問並且不會遮擋或乾擾可用的應用程序顯示區域。

設備實施者還應該提供一個專用的搜索鍵。設備實施者還可以為電話呼叫提供發送和結束鍵。

8.8.無線數據網絡

設備實現必須包括對無線高速數據網絡的支持。具體而言，設備實現必須包括對至少一種能夠達到 200Kbit/sec 或更高速率的無線數據標準的支持。滿足此要求的技術示例包括 EDGE、HSPA、EV-DO、802.11g 等。

如果設備實現包含 Android SDK 包含 API（即 WiFi、GSM 或 CDMA）的特定模式，則該實現必須支持該 API。

設備可以實現不止一種形式的無線數據連接。設備可以實現有線數據連接（例如以太網），但仍必須包括至少一種形式的無線連接，如上所述。

8.9.相機

設備實現必須包含後置攝像頭。隨附的後置攝像頭：

• 分辨率必須至少為 2 兆像素
• 應該在相機驅動程序中實現硬件自動對焦或軟件自動對焦（對應用軟件透明）
• 可能有固定焦距或 EDOF（擴展景深）硬件
• 可能包括閃光燈。如果相機包含閃光燈，則當 android.hardware.Camera.PreviewCallback 實例已在相機預覽表面上註冊時，閃光燈不得點亮，除非應用程序已通過啟用閃光燈的FLASH_MODE_AUTO或FLASH_MODE_ON屬性顯式啟用閃光燈Camera.Parameters對象。請注意，此約束不適用於設備的內置系統相機應用程序，而僅適用於使用Camera.PreviewCallback的第三方應用程序。

設備實現必須為相機相關 API 實現以下行為：

1. 如果應用程序從未調用過 android.hardware.Camera.Parameters.setPreviewFormat(int)，則設備必須使用 android.hardware.PixelFormat.YCbCr_420_SP 來提供給應用程序回調的預覽數據。
2. 如果應用程序註冊了android.hardware.Camera.PreviewCallback實例，當預覽格式為YCbCr_420_SP時系統調用了onPreviewFrame()方法，則傳入onPreviewFrame()的byte[]中的數據還必須是NV21編碼格式。 (This is the format used natively by the 7k hardware family.) That is, NV21 MUST be the default.

Device implementations MUST implement the full Camera API included in the Android 2.2 SDK documentation [ Resources, 27 ]), 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.)

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 MAY include a front-facing camera. However, if a device implementation includes a front-facing camera, the camera API as implemented on the device MUST NOT use the front-facing camera by default. That is, the camera API in Android 2.2 is for rear-facing cameras only, and device implementations MUST NOT reuse or overload the API to act on a front-facing camera, if one is present. Note that any custom APIs added by device implementers to support front-facing cameras MUST abide by sections 3.5 and 3.6; for instance, if a custom android.hardware.Camera or Camera.Parameters subclass is provided to support front-facing cameras, it MUST NOT be located in an existing namespace, as described by sections 3.5 and 3.6. Note that the inclusion of a front-facing camera does not meet the requirement that devices include a rear-facing camera.

8.10. Accelerometer

Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at 50 Hz or greater. The coordinate system used by the accelerometer MUST comply with the Android sensor coordinate system as detailed in the Android APIs (see [ Resources, 28 ]).

8.11. Compass

Device implementations MUST include a 3-axis compass and MUST be able to deliver events 10 Hz or greater. The coordinate system used by the compass MUST comply with the Android sensor coordinate system as defined in the Android API (see [ Resources, 28 ]).

8.12. GPS

Device implementations MUST include a GPS receiver, and SHOULD include some form of "assisted GPS" technique to minimize GPS lock-on time.

8.13. Telephony

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

See also Section 8.8, Wireless Data Networking.

8.14. Memory and Storage

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

Device implementations MUST have at least 150MB of non-volatile storage available for user data. That is, the /data partition MUST be at least 150MB.

Beyond the requirements above, device implementations SHOULD have at least 128MB of memory available to kernel and userspace, in addition to any memory dedicated to hardware components that is not under the kernel's control. Device implementations SHOULD have at least 1GB of non-volatile storage available for user data. Note that these higher requirements are planned to become hard minimums in a future version of Android. Device implementations are strongly encouraged to meet these requirements now, or else they may not be eligible for compatibility for a future version of Android.

8.15. Application Shared Storage

Device implementations MUST offer shared storage for applications. The shared storage provided MUST be at least 2GB 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, the shared storage MUST implement USB mass storage, as described in Section 8.6. As shipped out of the box, the shared storage MUST be mounted with the FAT filesystem.

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 2GB 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 2GB in size or larger, formatted as FAT, 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.

8.16. Bluetooth

Device implementations MUST include a Bluetooth transceiver. Device implementations MUST enable the RFCOMM-based Bluetooth API as described in the SDK documentation [ Resources, 30 ]. 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.

9. Performance Compatibility

One of the goals of the Android Compatibility Program is to enable consistent application experience to consumers. Compatible implementations must ensure not only that applications simply run correctly on the device, but that they do so with reasonable performance and overall good user experience. Device implementations MUST meet the key performance metrics of an Android 2.2 compatible device defined in the table below:

10. 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, 29 ] 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.

10.1.權限

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 29 ]. 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.

10.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, 29 ].

10.3. Filesystem Permissions

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

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

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 be able to access that 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.

11. Compatibility Test Suite

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 2.2. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

12. 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. 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 thid-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

13. Contact Us

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

Setup and Installation

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.