Android 2.1 兼容性定義

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

本文檔列舉了為使手機與 Android 2.1 兼容而必須滿足的要求。

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

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

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

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

如果此定義或 CTS 不明確、模棱兩可或不完整，則設備實現者有責任確保與現有實現的兼容性。出於這個原因，Android 開源項目 [ Resources, 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. 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 2.1 允許的版本字符串：http: //source.android.com/compatibility/2.1/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. 動態壁紙：http: //developer.android.com/resources/articles/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. Android apk 文件說明：http: //developer.android.com/guide/topics/fundamentals.html
  21. 清單文件：http: //developer.android.com/guide/topics/manifest/manifest-intro.html
  22. 猴子測試工具：http: //developer.android.com/guide/developing/tools/monkey.html
  23. 支持多屏：http: //developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration：http: //developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics：http: //developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera：http://developer.android.com/reference/android/hardware/Camera.html
  27. 傳感器坐標空間：http: //developer.android.com/reference/android/hardware/SensorEvent.html
  28. Android 安全和權限參考：http: //developer.android.com/guide/topics/security/security.html
  29. 藍牙 API：http: //developer.android.com/reference/android/bluetooth/package-summary.html

其中許多資源直接或間接源自 Android 2.1 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.1 SDK [資源，4 ] 公開的任何已記錄 API 的完整實施，包括所有已記錄的行為。

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

3.2.軟 API 兼容性

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

3.2.1。權限

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

3.2.2.構建參數

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

範圍註釋
android.os.Build.VERSION.RELEASE當前執行的 Android 系統的版本，採用人類可讀的格式。該字段必須具有 [ Resources, 7 ] 中定義的字符串值之一。
android.os.Build.VERSION.SDK當前執行的 Android 系統的版本，採用第三方應用程序代碼可訪問的格式。對於 Android 2.1，此字段必須具有整數值 7。
android.os.Build.VERSION.INCREMENTAL設備實現者選擇的值，以人類可讀的格式指定當前執行的 Android 系統的特定構建。此值不得重複用於交付給最終用戶的不同構建。此字段的典型用途是指示使用哪個構建號或源代碼控制更改標識符來生成構建。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.BOARD設備實現者選擇的一個值，用於標識設備使用的特定內部硬件，採用人類可讀的格式。該字段的一個可能用途是指示為設備供電的電路板的特定版本。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.BRAND由設備實施者選擇的值，以人類可讀的格式標識生產設備的公司、組織、個人等的名稱。此字段的一種可能用途是指明銷售設備的 OEM 和/或運營商。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.DEVICE由設備實施者選擇的一個值，用於標識設備主體的特定配置或修訂（有時稱為“工業設計”）。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.FINGERPRINT唯一標識此構建的字符串。它應該是合理的人類可讀的。它必須遵循這個模板：
$(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
例如：
acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
指紋不得包含空格。如果上述模板中包含的其他字段有空格，則應將它們替換為指紋中的 ASCII 下劃線（“_”）字符。
android.os.Build.HOST一個字符串，以人類可讀的格式唯一標識構建所基於的主機。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.ID設備實現者選擇的標識符，用於引用特定版本，採用人類可讀的格式。此字段可以與 android.os.Build.VERSION.INCREMENTAL 相同，但應該是一個足以讓最終用戶區分軟件構建的值。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.MODEL由設備實現者選擇的一個值，其中包含最終用戶已知的設備名稱。這應該與設備銷售和銷售給最終用戶的名稱相同。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.PRODUCT設備實現者選擇的一個值，包含設備的開發名稱或代碼名稱。必須是人類可讀的，但不一定供最終用戶查看。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。
android.os.Build.TAGS由設備實現者選擇的以逗號分隔的標籤列表，用於進一步區分構建。例如，“未簽名，調試”。此字段不得為 null 或空字符串 ("")，但可以使用單個標籤（例如 "release"）。
android.os.Build.TIME表示構建發生時間的時間戳的值。
android.os.Build.TYPE設備實現者選擇的值，指定構建的運行時配置。該字段應該具有對應於三個典型 Android 運行時配置的值之一：“user”、“userdebug”或“eng”。
android.os.Build.USER生成構建的用戶（或自動用戶）的名稱或用戶 ID。該字段的具體格式沒有要求，但不能為空或空字符串（“”）。

3.2.3。意圖兼容性

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

3.2.3.1。核心應用意圖

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

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

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

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

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

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

3.2.3.2。意圖覆蓋

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

注意：本節由 Erratum EX6580 修改。

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 必須可用於本機代碼：

設備實現必須支持 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. Web API 兼容性

許多開發人員和應用程序的用戶界面依賴於android.webkit.WebView類 [資源，8 ] 的行為，因此 WebView 實現必須在 Android 實現之間兼容。 Android 開源實現使用 WebKit 渲染引擎來實現 WebView。

因為為 Web 瀏覽器開發一個全面的測試套件是不可行的，設備實現者必須在 WebView 實現中使用特定的上游構建的 WebKit。具體來說：

實現可以在獨立的瀏覽器應用程序中提供自定義用戶代理字符串。更重要的是，獨立瀏覽器可能基於替代瀏覽器技術（如 Firefox、Opera 等）。但是，即使交付了替代瀏覽器應用程序，提供給第三方應用程序的 WebView 組件也必須基於 WebKit，如上。

WebView 配置必須包括對 HTML5 數據庫、應用程序緩存和地理定位 API [資源，9 ] 的支持。 WebView 必須以某種形式包含對 HTML5 <video>標記的支持。獨立的瀏覽器應用程序（無論是基於上游 WebKit 瀏覽器應用程序還是第三方替代品）必須包含對剛剛為 WebView 列出的相同 HTML5 功能的支持。

3.5. API 行為兼容性

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

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

兼容性測試套件 (CTS) 測試平台的重要部分的行為兼容性，但不是全部。實施者有責任確保與 Android 開源項目的行為兼容性。

3.6. API 命名空間

Android 遵循 Java 編程語言定義的包和類命名空間約定。為確保與第三方應用程序的兼容性，設備實施者不得對這些包命名空間進行任何禁止的修改（見下文）：

禁止的修改包括：

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

設備實現者可以添加自定義 API，但任何此類 API 不得位於其他組織擁有或引用的命名空間中。例如，設備實現者不得將 API 添加到 com.google.* 或類似命名空間；只有谷歌可以這樣做。同樣，Google 不得將 API 添加到其他公司的命名空間。

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

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

3.7.虛擬機兼容性

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

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

3.8.用戶界面兼容性

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

3.8.1.小部件

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

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

3.8.2.通知

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

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

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. 參考軟件兼容性

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

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

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

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

5. 應用程序封裝兼容性

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

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

6. 多媒體兼容性

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

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

聲音的
姓名編碼器解碼器細節文件/容器格式
AAC LC/LTP X標準比特率高達 160 kbps 和採樣率介於 8 至 48 kHz 之間的任意組合的單聲道/立體聲內容3GPP (.3gp) 和 MPEG-4 (.mp4, .m4a)。不支持原始 AAC (.aac)
HE-AACv1 (AAC+) X
HE-AACv2（增強型 AAC+） X
AMR-NB X X 4.75 至 12.2 kbps 採樣率 @ 8kHz 3GPP (.3gp)
AMR-WB X從 6.60 kbit/s 到 23.85 kbit/s 的 9 種速率在 16kHz 下採樣3GPP (.3gp)
MP3 X單聲道/立體聲 8-320Kbps 恆定 (CBR) 或可變比特率 (VBR) MP3 (.mp3)
MIDI X MIDI 類型 0 和 1。DLS 版本 1 和 2。XMF 和移動 XMF。支持鈴聲格式 RTTTL/RTX、OTA 和 iMelody鍵入 0 和 1（.mid、.xmf、.mxmf）。還有 RTTTL/RTX (.rtttl, .rtx)、OTA (.ota) 和 iMelody (.imy)
奧格·沃爾比斯X奧格 (.ogg)
PCM X 8- and 16-bit linear PCM (rates up to limit of hardware) WAVE (.wav)
Image
JPEG X X base+progressive
GIF X
PNG X X
BMP X
Video
H.263 X X 3GPP (.3gp) files
H.264 X 3GPP (.3gp) and MPEG-4 (.mp4) files
MPEG4 Simple Profile X 3GPP (.3gp) file

Note that the table above does not list specific bitrate requirements for most video codecs. The reason for this is that in practice, current device hardware does not necessarily support bitrates that map exactly to the required bitrates specified by the relevant standards. Instead, device implementations SHOULD support the highest bitrate practical on the hardware, up to the limits defined by the specifications.

7. Developer Tool Compatibility

Device implemenations MUST support the Android Developer Tools provided in the Android SDK. Specifically, Android-compatible devices MUST be compatible with:

  • Android Debug Bridge (known as adb) [ Resources, 19 ]
    Device implementations MUST support all adb functions as documented in the Android SDK. The device-side adb daemon SHOULD be inactive by default, but there MUST be a user-accessible mechanism to turn on the Android Debug Bridge.
  • Dalvik Debug Monitor Service (known as ddms) [ Resources, 19 ]
    Device implementations MUST support all ddms features as documented in the Android SDK. As ddms uses adb , support for ddms SHOULD be inactive by default, but MUST be supported whenever the user has activated the Android Debug Bridge, as above.
  • Monkey [ Resources, 22 ]
    Device implementations MUST include the Monkey framework, and make it available for applications to use.

8. Hardware Compatibility

Android is intended to support device implementers creating innovative form factors and configurations. At the same time Android developers expect certain hardware, sensors and APIs across all Android device. This section lists the hardware features that all Android 2.1 compatible devices must support.

If a device includes a particular hardware component that has a corresponding API for third-party developers, the device implementation MUST implement that API as defined in the Android SDK documentation. If an API in the SDK interacts with a hardware component that is stated to be optional and the device implementation does not possess that component:

A typical example of a scenario where these requirements apply is the telephony API: even on non-phone devices, these APIs must be implemented as reasonable no-ops.

Device implementations MUST accurate report accurate hardware configuration information via the getSystemAvailableFeatures() and hasSystemFeature(String) methods on the android.content.pm.PackageManager class.

8.1. Display

Android 2.1 includes facilities that perform certain automatic scaling and transformation operations under some circumstances, to ensure that third-party applications run reasonably well on a variety of hardware configurations [ Resources, 23 ]. Devices MUST properly implement these behaviors, as detailed in this section.

For Android 2.1, this are the most common display configurations:

Screen Type Width (Pixels) Height (Pixels) Diagonal Length Range (inches) Screen Size Group Screen Density Group
QVGA 240 320 2.6 - 3.0 Small Low
WQVGA 240 400 3.2 - 3.5 Normal Low
FWQVGA 240 432 3.5 - 3.8 Normal Low
HVGA 320 480 3.0 - 3.5 Normal Medium
WVGA 480 800 3.3 - 4.0 Normal High
FWVGA 480 854 3.5 - 4.0 Normal High
WVGA 480 800 4.8 - 5.5 Large Medium
FWVGA 480 854 5.0 - 5.8 Large Medium

Device implementations corresponding to one of the standard configurations above MUST be configured to report the indicated screen size to applications via the android.content.res.Configuration [ Resources, 24 ] class.

Some .apk packages have manifests that do not identify them as supporting a specific density range. When running such applications, the following constraints apply:

8.1.2. Non-Standard Display Configurations

Display configurations that do not match one of the standard configurations listed in Section 8.1.1 require additional consideration and work to be compatible. Device implementers MUST contact Android Compatibility Team as provided for in Section 12 to obtain classifications for screen-size bucket, density, and scaling factor. When provided with this information, device implementations MUST implement them as specified.

Note that some display configurations (such as very large or very small screens, and some aspect ratios) are fundamentally incompatible with Android 2.1; therefore device implementers are encouraged to contact Android Compatibility Team as early as possible in the development process.

8.1.3. Display Metrics

Device implementations MUST report correct valuesfor all display metrics defined in android.util.DisplayMetrics [ Resources, 25 ].

8.2. Keyboard

Device implementations:

8.3. Non-touch Navigation

Device implementations:

8.4. Screen Orientation

Compatible devices MUST support dynamic orientation by applications to either portrait or landscape screen orientation. That is, the device must respect the application's request for a specific screen orientation. Device implementations MAY select either portrait or landscape orientation as the default.

Devices MUST report the correct value for the device's current orientation, whenever queried via the android.content.res.Configuration.orientation, android.view.Display.getOrientation(), or other APIs.

8.5. Touchscreen input

Device implementations:

8.6. USB

Device implementations:

8.7. Navigation keys

The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times, regardless of application state. These functions SHOULD be implemented via dedicated buttons. They MAY be implemented using software, gestures, touch panel, etc., but if so they MUST be always accessible and not obscure or interfere with the available application display area.

Device implementers SHOULD also provide a dedicated search key. Device implementers MAY also provide send and end keys for phone calls.

8.8. Wireless Data Networking

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

If a device implementation includes a particular modality for which the Android SDK includes an API (that is, WiFi, GSM, or CDMA), the implementation MUST support the API.

Devices MAY implement more than one form of wireless data connectivity. Devices MAY implement wired data connectivity (such as Ethernet), but MUST nonetheless include at least one form of wireless connectivity, as above.

8.9. Camera

Device implementations MUST include a camera. The included camera:

Device implementations MUST implement the following behaviors for the camera-related APIs:

  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. (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.1 SDK documentation [ Resources, 26 ]), 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 , unless the constants are prefixed with a string indicating the name of the device implementer. That is, device implementations MUST support all standard Camera parameters if the hardware allows, and MUST NOT support custom Camera parameter types unless the parameter names are clearly indicated via a string prefix to be non-standard.

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, 27 ]).

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, 27 ]).

8.12. GPS

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

8.13. Telephony

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

Note: this section was modified by Erratum EX6580.

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 and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted elsewhere.)

Note: this section was added by Erratum EX6580.

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

Note: this section was added by Erratum EX6580.

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.1 compatible device defined in the table below:

Metric Performance Threshold Comments
Application Launch Time The following applications should launch within the specified time. 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.

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, 28 ] 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. Permissions

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

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, 28 ].

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.1. 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:

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.