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

Android 2.1兼容性定義

版權所有©2010,GoogleInc。保留所有權利。
兼容性@ android.com

1.簡介

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

根據IETF標準,使用“必須”,“必須”,“必須”,“將”,“不應”,“應該”,“不應”,“推薦”,“可以”和“可選”在RFC2119 [ Resources,1 ]中定義。

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

被認為與Android 2.1兼容的設備實現:

  • 必須滿足此兼容性定義中提出的要求,包括通過引用併入的所有文檔。
  • 設備實現軟件完成時,必須通過最新版本的Android兼容性測試套件(CTS)。 (CTS是Android開源項目[ 參考資料,2 ]的一部分。)CTS測試了本文檔中概述的許多但並非全部組件。

如果此定義或CTS是靜默的,模棱兩可的或不完整的,則設備實現者有責任確保與現有實現的兼容性。因此,Android Open Source Project [ 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虛擬機規範:可在dalvik / docs的Android源代碼中獲得
  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公開的任何已記錄API的完整實現,包括所有已記錄的行為[ 參考資料,4 ]。

設備實現絕不能忽略任何託管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系統的版本,格式為人類可讀。該字段必須具有[ 資源,7 ]中定義的字符串值之一。
android.os.Build.VERSION.SDK 當前正在執行的Android系統的版本,其格式可供第三方應用程序代碼訪問。對於Android 2.1,此字段必須具有整數值7。
android.os.Build.VERSION.INCREMENTAL 設備實施者選擇的值,以人類可讀的格式指定當前正在執行的Android系統的特定版本。不得將此值用於交付給最終用戶的其他內部版本。該字段的典型用法是指示使用哪個內部版本號或源代碼管理更改標識符來生成內部版本。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.BOARD 設備實施者選擇的值,以人類可讀的格式標識設備使用的特定內部硬件。該字段的可能用途是指示為設備供電的電路板的特定版本。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.BRAND 設備實施者選擇的值,以人類可讀的格式標識製造設備的公司,組織,個人等的名稱。該字段的可能用途是指示出售設備的OEM和/或運營商。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.DEVICE 由設備實施者選擇的一個值,用於標識設備主體的特定配置或版本(有時稱為“工業設計”)。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
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 一個字符串,以人類可讀的格式唯一地標識構建所基於的主機。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.ID 設備實現者選擇的標識符以人類可讀的格式引用特定的版本。該字段可以與android.os.Build.VERSION.INCREMENTAL相同,但應該是一個足以讓最終用戶區分軟件版本的值。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.MODEL 由設備實施者選擇的值,包含最終用戶已知的設備名稱。該名稱應與設備銷售並出售給最終用戶時使用的名稱相同。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.PRODUCT 設備實施者選擇的值,其中包含設備的開發名稱或代碼名稱。必須是人類可讀的,但不一定要供最終用戶查看。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。
android.os.Build.TAGS 設備實施者選擇的以逗號分隔的標籤列表,這些標籤進一步區分了版本。例如,“ unsigned,debug”。該字段不得為null或空字符串(“”),但可以使用單個標籤(例如“ release”)。
android.os.Build.TIME 表示生成時間的時間戳記的值。
android.os.Build.TYPE 設備實施者選擇的值,用於指定構建的運行時配置。該字段應具有與以下三種典型的Android運行時配置相對應的值之一:“ user”,“ userdebug”或“ eng”。
android.os.Build.USER 生成構建的用戶(或自動用戶)的名稱或用戶ID。除了必須不得為null或空字符串(“”)之外,對該字段的特定格式沒有任何要求。

3.2.3。意向兼容性

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

3.2.3.1。核心應用意向

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

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

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

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

對於在一個核心Android系統應用中定義的每個未通過android:exported屬性標記為“ false”的未標記為非公開的Activity或服務,設備實現都必須包括實現相同Intent過濾器的相同類型的組件模式作為Android系統的核心應用。

換句話說,設備實現可以取代核心的Android系統應用;但是,如果確實如此,則設備實現必須支持被替換的每個核心Android系統應用定義的所有Intent模式。

3.2.3.2。意圖替代

由於Android是可擴展的平台,因此設備實現者必須允許第三方應用程序覆蓋核心系統應用程序中定義的每個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必須對本機代碼可用:

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

這些庫必須與Android Open Source項目在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類[ Resources,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開源項目的首選實現一致[ Resources,3 ]。兼容性的一些特定領域是:

上面的列表並不全面,設備實施者有責任確保行為兼容。因此,設備實施者應盡可能使用可通過Android開放源代碼項目獲得的源代碼,而不是重新實現系統的重要部分。

兼容性測試套件(CTS)測試平台的大部分行為行為兼容性,但不是全部。實現者有責任確保與Android開放源代碼項目的行為兼容。

3.6。 API命名空間

Android遵循Java編程語言定義的package和class名稱空間約定。為確保與第三方應用程序兼容,設備實現者不得對這些軟件包名稱空間進行任何禁止的修改(請參見下文):

禁止的修改包括:

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

設備實現者可以添加自定義API,但是任何此類API均不得位於另一個組織擁有或引用的組織的命名空間中。例如,設備實施者不得將API添加到com.google。*或類似的名稱空間;只有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” [ Resources,11 ]。 Android開放源參考發行版包含一個Launcher應用程序,該應用程序包含用戶界面元素,允許用戶從主屏幕添加,查看和刪除AppWidget。

設備實施者可以用替代方法替代參考啟動器(即主屏幕)。替代啟動器應包括對AppWidget的內置支持,並公開用戶界面元素以直接在啟動器中添加,配置,查看和刪除AppWidget。替代啟動器可以省略這些用戶界面元素;但是,如果省略了它們,則設備實現者必須提供可從啟動器訪問的單獨應用程序,該應用程序允許用戶添加,配置,查看和刪除AppWidget。

3.8.2。通知事項

Android包含一些API,這些API允許開發人員將值得注意的事件通知用戶[ 參考資料,12 ]。設備實現者必須為這樣定義的每類通知提供支持;具體來說:聲音,振動,燈光和狀態欄。

另外,實現必須正確呈現API [ 資源,13 ]或狀態欄圖標樣式指南[ 資源,14 ]中提供的所有資源(圖標,聲音文件等)。設備實現者可以為通知提供不同於參考Android開放源實現所提供的用戶體驗;但是,如上所述,此類替代通知系統必須支持現有的通知資源。

Android包含API [ Resources,15 ],這些API允許開發人員將搜索合併到他們的應用程序中,並將他們的應用程序數據公開到全局系統搜索中。通常,此功能由單個系統範圍的用戶界面組成,該界面允許用戶輸入查詢,在用戶鍵入內容時顯示建議並顯示結果。 Android API允許開發人員重用此接口以在其自己的應用程序中提供搜索,並允許開發人員將結果提供給通用的全局搜索用戶界面。

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

設備實現可以附帶替代的搜索用戶界面,但應包括硬性或軟性專用搜索按鈕,可以按API文檔中提供的行為在任何應用程序中隨時使用該按鈕來調用搜索框架。

3.8.4。敬酒

應用程序可以使用“ Toast” API(在[ 參考資料,16 ]中定義)向最終用戶顯示簡短的非模式字符串,這些字符串會在短時間後消失。設備實現必須以某種高度可見的方式顯示從應用程序到最終用戶的敬酒。

3.8.5。動態壁紙

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

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

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

4.參考軟件兼容性

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

上面的每個應用程序都必須啟動並在實現上正確運行,以確保實現兼容。

此外,設備實現必須測試以下每個煙霧測試應用程序的每個菜單項(包括所有子菜單):

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

5.應用程序包裝兼容性

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

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

6.多媒體兼容性

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

請注意,無論是Google還是開放手機聯盟,都不代表這些編解碼器不受第三方專利的限制。建議那些打算在硬件或軟件產品中使用此源代碼的人,此代碼的實現(包括在開源軟件或共享軟件中)可能需要獲得相關專利持有者的專利許可。

音訊
名稱 編碼器 解碼器 細節 文件/容器格式
AAC LC / LTP X Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates between 8 to 48kHz 3GPP (.3gp) and MPEG-4 (.mp4, .m4a). No support for raw AAC (.aac)
HE-AACv1 (AAC+) X
HE-AACv2 (enhanced AAC+) X
AMR-NB X X 4.75 to 12.2 kbps sampled @ 8kHz 3GPP (.3gp)
AMR-WB X 9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz 3GPP (.3gp)
MP3 X Mono/Stereo 8-320Kbps constant (CBR) or variable bit-rate (VBR) MP3 (.mp3)
MIDI X MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for ringtone formats RTTTL/RTX, OTA, and iMelody Type 0 and 1 (.mid, .xmf, .mxmf). Also RTTTL/RTX (.rtttl, .rtx), OTA (.ota), and iMelody (.imy)
Ogg Vorbis X Ogg (.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.

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

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.

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.