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

Android 1.6 兼容性定義

Android 兼容性定義：Android 1.6
安卓 1.6 r2
谷歌公司
compatibility@android.com

一、簡介
本文檔列舉了手機必須滿足的要求
兼容安卓1.6。此定義假定熟悉 Android 兼容性計劃
[資源，1]。
使用“必須”、“不得”、“要求”、“應該”、“不應”、“應該”、“不應該”、“推薦”、
“可能”和“可選”符合 RFC2119 [參考資料，2] 中定義的 IETF 標準。
如本文檔中所用，“設備實施者”或“實施者”是指開發
運行 Android 1.6 的硬件/軟件解決方案。 “設備實現”或“實現”是
如此開發的硬件/軟件解決方案。
要被視為與 Android 1.6 兼容，設備實現：
1. 必須滿足本兼容性定義中提出的要求，包括任何文檔
通過引用併入。
2. 必須通過作為 Android Open 的一部分提供的 Android 兼容性測試套件 (CTS)
源項目 [資源, 3]。 CTS 測試大多數（但不是全部）本文檔中概述的組件
文檔。
如果此定義或 CTS 是沉默的、模棱兩可的或不完整的，則由設備負責
實現者以確保與現有實現的兼容性。為此，Android Open
Source Project [ Resources , 4] 是 Android 的參考和首選實現。設備
強烈鼓勵實施者將他們的實施建立在“上游”源代碼的基礎上
可從 Android 開源項目獲得。雖然假設可以更換某些組件
對於替代實現，強烈不鼓勵這種做法，因為通過 CTS 測試將成為
困難得多。實施者有責任確保與
標準的 Android 實現，包括並超越兼容性測試套件。
2.資源
此兼容性定義參考了可在此處獲得的大量資源。
1. Android 兼容性計劃概述： https ://sites.google.com/a/android.com/compatibility/
怎麼運行的
2. IETF RFC2119 要求等級： http ://www.ietf.org/rfc/rfc2119.txt
3.兼容性測試套件： http ://sites.google.com/a/android.com/compatibility/compatibility-test-
套件--cts
4.安卓開源項目：http: //source.android.com/
5. API定義及文檔：http: //developer.android.com/reference/packages.html
6.內容提供者： http ://code.google.com/android/reference/android/provider/package-
摘要.html
7.可用資源： http ://code.google.com/android/reference/available-resources.html
8. 安卓清單文件： http ://code.google.com/android/devel/bblocks-manifest.html
9.Android權限參考：http: //developer.android.com/reference/android/
清單.permission.html
10. 構建常量：http: //developer.android.com/reference/android/os/Build.html
11. 網絡視圖：http: //developer.android.com/reference/android/webkit/WebView.html
12. Gears 瀏覽器擴展： http ://code.google.com/apis/gears/

13. Dalvik虛擬機規範，在源代碼的dalvik/docs目錄下找到
查看;也可在http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14. AppWidgets：http: //developer.android.com/guide/practices/ui_guidelines/widget_design.html
15.通知：http: //developer.android.com/guide/topics/ui/notifiers/notifications.html
16.狀態欄圖標樣式指南：http: //developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. 搜索管理器：http: //developer.android.com/reference/android/app/SearchManager.html
18.吐司：http: //developer.android.com/reference/android/widget/Toast.html
19. Android 應用程序： http ://code.google.com/p/apps-for-android
20.安卓apk文件說明：http: //developer.android.com/guide/topics/fundamentals.html
21. 安卓調試橋（adb）： http ://code.google.com/android/reference/adb.html
22. Dalvik調試監控服務（ddms）： http ://code.google.com/android/reference/ddms.html
23. 猴子：http: //developer.android.com/guide/developing/tools/monkey.html
24. 顯示獨立文檔：
25.配置常量：http: //developer.android.com/reference/android/content/res/
配置.html
26. 顯示指標：http: //developer.android.com/reference/android/util/DisplayMetrics.html
27. 相機：http: //developer.android.com/reference/android/hardware/Camera.html
28.傳感器坐標空間：http: //developer.android.com/reference/android/hardware/
傳感器事件.html
29. Android 安全和權限參考：http: //developer.android.com/guide/topics/security/
安全.html
其中許多資源直接或間接源自 Android 1.6 SDK，並將在
在功能上與該 SDK 文檔中的信息相同。在任何情況下
Compatibility Definition 與SDK文檔不一致，SDK文檔被認為
權威性。上述參考文獻中提供的任何技術細節均被納入考慮
成為此兼容性定義的一部分。
3. 軟件
Android 平台包括一組託管（“硬”）API 和一組所謂的“軟”API
例如 Intent 系統、本地代碼 API 和 Web 應用程序 API。本節詳細介紹了硬和
兼容性不可或缺的軟 API，以及某些其他相關技術和用戶界面
行為。設備實現必須符合本節中的所有要求。
3.1.託管 API 兼容性
託管（基於 Dalvik）執行環境是 Android 應用程序的主要載體。這
Android 應用程序編程接口 (API) 是一組暴露給 Android 平台的接口
在託管 VM 環境中運行的應用程序。設備實現必須提供完整的
Android 公開的任何已記錄 API 的實現，包括所有已記錄的行為
1.6 SDK，如：
1. 核心 Android Java 語言 API [資源，5]。
2. 內容提供商[資源, 6]。
3. 資源[資源，7]。
4. AndroidManifest.xml 的屬性和元素 [Resources, 8]。

設備實現不得省略任何託管 API、更改 API 接口或簽名、偏離
來自記錄的行為，或包括空操作，除非此兼容性特別允許
定義。
3.2.軟 API 兼容性
除了第 3.1 節中的託管 API 之外，Android 還包含一個重要的僅運行時“軟件”
API，以 Intent、權限和 Android 應用程序的類似方面等形式存在
不能在應用程序編譯時強制執行。本節詳細介紹“軟”API 和系統
與 Android 1.6 兼容所需的行為。設備實現必須滿足所有
本節提出的要求。
3.2.1.權限
設備實現者必須支持並強制執行由
權限參考頁 [資源, 9]。請注意，第 10 節列出了與以下相關的附加要求
安卓安全模型。
3.2.2.構建參數
Android API 在 android.os.Build 類[Resources, 10]上包含許多常量，它們是
旨在描述當前設備。跨設備提供一致的、有意義的值
實現，下表包括對這些值的格式的附加限制
設備實現必須符合。
範圍
註釋
當前執行的Android系統的版本，在human-
android.os.Build.VERSION.RELEASE
可讀格式。對於 Android 1.6，此字段必須具有字符串值
“1.6”。
當前執行的 Android 系統的版本，格式為
android.os.Build.VERSION.SDK
第三方應用程序代碼可訪問。對於 Android 1.6，此字段
必須有整數值 4。
指定特定構建的設備實現者選擇的值
當前正在執行的 Android 系統，以人類可讀的格式。
此值不得重複用於交付到最後的不同構建
android.os.Build.VERSION.INCREMENTAL 用戶。此字段的典型用途是指示哪個內部版本號或
源代碼控制更改標識符用於生成構建。那裡
對該字段的具體格式沒有要求，只是
不得為 null 或空字符串 ("")。
設備實施者選擇的一個值，用於標識特定的內部
設備使用的硬件，採用人類可讀的格式。一個可能的用途
android.os.Build.BOARD
這個領域是為了表明板供電的具體修訂
設備。該字段的具體格式沒有要求，
除了它不能為 null 或空字符串 ("")。
設備實施者選擇的一個值，用於標識設備的名稱
android.os.Build.BRAND 品牌
生產設備的公司、組織、個人等，在
人類可讀的格式。該字段的一個可能用途是指示 OEM

和/或銷售該設備的運營商。沒有要求
此字段的特定格式，除了它不能為 null 或空
細繩（””）。
設備實施者選擇的一個值，用於識別特定的
身體的配置或修改（有時稱為“工業
android.os.Build.DEVICE
design")的設備。具體格式沒有要求
這個字段，除了它不能為 null 或空字符串 ("")。
唯一標識此構建的字符串。它應該是合理的
人類可讀的。它必須遵循這個模板：
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.指紋
$(BUILD_VERSION_TAGS)
例如：acme/mydevicel/generic/generic:Donut/ERC77/
3359:用戶調試/測試鍵
指紋不得包含空格。如果其他字段包含在
上面的模板有空格，它們應該替換為 ASCII
指紋中的下劃線（“_”）字符。
一個字符串，用於唯一標識構建所在的主機，以人為單位
android.os.Build.HOST
可讀格式。對具體格式沒有要求
字段，除了它不能為 null 或空字符串 ("")。
設備實施者選擇的標識符，用於指代特定的
以人類可讀的格式發布。該字段可以與
android.os.Build.VERSION.INCREMENTAL，但應該是一個值
android.os.Build.ID
旨在對最終用戶有些意義。沒有
對該字段的特定格式的要求，除了它不能
為 null 或空字符串 ("")。
由設備實現者選擇的一個值，其中包含設備的名稱
最終用戶已知的設備。這應該是相同的名字
android.os.Build.MODEL
設備在其下營銷和銷售給最終用戶。沒有
對該字段的特定格式的要求，除了它不能
為 null 或空字符串 ("")。
包含開發的設備實施者選擇的值
設備的名稱或代號。必須是人類可讀的，但不是
android.os.Build.PRODUCT
必須供最終用戶查看。沒有要求
關於這個字段的特定格式，除了它不能為空或
空字符串 ("")。
由設備實施者選擇的以逗號分隔的標籤列表
進一步區分構建。例如，“未簽名，調試”。這個領域
android.os.Build.TAGS
不得為 null 或空字符串 ("")，而是單個標記（例如
“釋放”）很好。
android.os.Build.TIME
表示構建發生時間的時間戳的值。
指定運行時的設備實現者選擇的值
構建的配置。該字段應該具有以下值之一
android.os.Build.TYPE
對應三種典型的Android運行時配置："user",
“userdebug”或“eng”。
生成的用戶（或自動用戶）的名稱或用戶 ID
android.os.Build.USER
建造。該字段的具體格式沒有要求，
除了它不能為 null 或空字符串 ("")。

3.2.3.意圖兼容性
Android 使用 Intents 來實現應用程序之間的鬆散耦合集成。本節介紹
與設備實現必須遵守的 Intent 模式相關的要求。經過
“榮幸”，這意味著設備實現者必須提供 Android 活動、服務或其他
指定匹配的 Intent 過濾器並綁定到每個過濾器並為每個過濾器實現正確行為的組件
指定的 Intent 模式。
3.2.3.1.核心應用意圖
Android 上游項目定義了一些核心應用程序，例如電話撥號器、日曆、
通訊錄、音樂播放器等。設備實施者可以將這些應用程序替換為
替代版本。
然而，任何此類替代版本必須遵循上游提供的相同 Intent 模式
項目。（例如，如果設備包含替代音樂播放器，它仍然必須遵守 Intent 模式
由第三方應用程序發出以選擇歌曲。）設備實現必須支持所有 Intent 模式
列於附錄 A。
3.2.3.2.意圖覆蓋
由於 Android 是一個可擴展的平台，設備實現者必須允許
附錄 A 將被第三方應用程序覆蓋。上游Android開源項目
默認情況下允許這樣做；設備實現者不得將特殊權限附加到系統應用程序的
使用這些 Intent 模式，或阻止第三方應用程序綁定並控制
這些圖案。該禁令具體包括禁用“選擇器”用戶界面，該界面允許
用戶在處理相同 Intent 模式的多個應用程序之間進行選擇。
3.2.3.3.意圖命名空間
設備實現者不得包含任何支持任何新 Intent 或
在 android.* 命名空間中使用 ACTION、CATEGORY 或其他關鍵字符串廣播 Intent 模式。
設備實現者不得包含任何支持任何新 Intent 或
在包空間中使用 ACTION、CATEGORY 或其他關鍵字符串廣播 Intent 模式
屬於另一個組織。設備實施者不得更改或擴展任何 Intent
附錄 A 或 B 中列出的模式。
此禁止類似於第 3.6 節中為 Java 語言類指定的禁止。

3.2.3.4.廣播意圖
第三方應用依賴平台廣播一定的Intent來通知自己的變化
硬件或軟件環境。 Android 兼容設備必須廣播公共廣播
響應適當系統事件的意圖。所需的廣播意圖列表在
附錄 B；但是，請注意，SDK 可能會定義額外的廣播意圖，這些意圖也必須是
榮幸。
3.3.本機 API 兼容性
在 Dalvik 中運行的託管代碼可以作為 ELF 調用應用程序 .apk 文件中提供的本機代碼
為適當的設備硬件架構編譯的 .so 文件。設備實現必須包括
支持在託管環境中運行的代碼調用本地代碼，使用標準 Java
本機接口 (JNI) 語義。以下 API 必須可用於本機代碼：
• libc（C 庫）
• libm（數學庫）
• JNI 接口
• libz（Zlib 壓縮）
• liblog（Android 日誌記錄）
•對 C++ 的最低支持
• OpenGL ES 1.1
這些庫必須是源代碼兼容的（即標頭兼容的）和二進制兼容的（對於給定的
處理器架構）與 Android 開源項目在 Bionic 中提供的版本。自從
仿生實現與其他實現不完全兼容，例如 GNU C
庫，設備實現者應該使用 Android 實現。如果設備實施者使用
這些庫的不同實現，它們必須確保標頭和二進制兼容性。
本機代碼兼容性具有挑戰性。出於這個原因，我們希望重申設備實施者是
強烈建議使用上面列出的庫的上游實現，以幫助
確保兼容性。
3.4.網絡 API 兼容性
許多開發人員和應用程序依賴於 android.webkit.WebView 類的行為 [資源，
11] 用於他們的用戶界面，因此 WebView 實現必須跨 Android 兼容
實施。 Android Open Source 實現使用 WebKit 渲染引擎版本來
實現 WebView。
因為為 Web 瀏覽器開發全面的測試套件是不可行的，設備實現者
必須在 WebView 實現中使用 WebKit 的特定上游構建。具體來說：
• WebView 必須使用來自上游 Android 開源樹的 528.5+ WebKit 構建
安卓 1.6。此版本包括一組特定的 WebView 功能和安全修復程序。
• WebView 報告的用戶代理字符串必須採用以下格式：
Mozilla/5.0 (Linux; U; Android 1.6; <語言>-<國家>; <設備
名稱>; Build/<build ID>) AppleWebKit/528.5+（KHTML，如 Gecko）
版本/3.1.2 Mobile Safari/525.20.1

◦ “<device name>”字符串必須與值相同
android.os.Build.MODEL
◦ “<build ID>”字符串必須與 android.os.Build.ID 的值相同。
◦ "<language>" 和 "<country>" 字符串應該遵循通常的約定
國家代碼和語言，並且應該參考設備的當前語言環境
請求的時間。
實現可以在獨立的瀏覽器應用程序中提供自定義用戶代理字符串。什麼是
此外，獨立瀏覽器可能基於替代瀏覽器技術（例如 Firefox、
Opera 等）但是，即使發布了備用瀏覽器應用程序，WebView 組件
提供給第三方應用程序必須基於 WebKit，如上所述。
獨立的瀏覽器應用程序應該包括對 Gears [參考資料， 12] 和 MAY 的支持
包括對部分或全部 HTML5 的支持。
3.5. API 行為兼容性
每種 API 類型（託管、軟、本機和 Web）的行為必須與
Android 開源項目提供的首選 Android 實現。
一些特定的兼容性領域是：
• 設備不得改變標準 Intent 的行為或含義
• 設備不得改變特定類型系統的生命週期或生命週期語義
組件（如Service、Activity、ContentProvider等）
• 設備不得更改特定權限的語義
上面的列表並不全面，設備實施者有責任確保行為
兼容性。出於這個原因，設備實現者應該使用通過
盡可能使用 Android 開源項目，而不是重新實現系統的重要部分。
兼容性測試套件 (CTS) 測試平台的重要部分以實現行為兼容性，
但不是所有的。實現者有責任確保與 Android 的行為兼容性
開源項目。
3.6. API 命名空間
Android 遵循 Java 編程定義的包和類命名空間約定
語言。為確保與第三方應用程序的兼容性，設備實施者不得製作
對這些包名稱空間的任何禁止修改（見下文）：
• java.*
• javax.*
• 太陽。*
• 安卓。*
• com.android.*
禁止的修改包括：
• 設備實現不得修改 Android 平台上公開公開的 API
通過更改任何方法或類簽名，或通過刪除類或類字段。

• 設備實施者可以修改 API 的底層實施，但是這樣
修改不得影響任何聲明的行為和 Java 語言簽名
公開暴露的 API。
• 設備實施者不得添加任何公開的元素（例如類或
現有類或接口的接口、字段或方法）到上述 API。
“公開暴露的元素”是任何在元素中沒有用“@hide”標記裝飾的構造
上游安卓源代碼。換句話說，設備實現者不得公開新的 API 或
更改上述命名空間中的現有 API。設備實施者可以僅供內部使用
修改，但這些修改不得公佈或以其他方式暴露給開發人員。
設備實現者可以添加自定義 API，但任何此類 API 不得位於擁有的命名空間中
通過或提及另一個組織。例如，設備實現者不得將 API 添加到
com.google.* 或類似的命名空間；只有谷歌可以這樣做。同樣，Google 不得將 API 添加到
其他公司的命名空間。
如果設備實現者提議改進上面的包命名空間之一（例如通過添加
對現有 API 有用的新功能，或添加新的 API），實施者應該訪問
source.android.com 並開始貢獻更改和代碼的過程，根據
該網站上的信息。
請注意，上述限制對應於 Java 中命名 API 的標準約定
編程語言；本節只是旨在加強這些公約並使其具有約束力
通過包含在此兼容性定義中。
3.7.虛擬機兼容性
兼容的 Android 設備必須支持完整的 Dalvik 可執行 (DEX) 字節碼規範和
Dalvik 虛擬機語義 [資源，13]。
3.8.用戶界面兼容性
Android 平台包含一些開發者 API，允許開發者掛接到系統用戶
界面。設備實現必須將這些標準 UI API 合併到自定義用戶界面中
它們會發展，如下所述。
3.8.1.小部件
Android 定義了一個組件類型和相應的 API 和生命週期，允許應用程序公開
給最終用戶的“AppWidget”[參考資料，14] 。 Android 開源參考版本包括
包含允許用戶添加、查看和刪除的用戶界面元素的啟動器應用程序
主屏幕上的 AppWidgets。
設備實施者可以替代參考啟動器（即主屏幕）。
替代啟動器應該包括對 AppWidgets 的內置支持，並公開用戶界面
直接在 Launcher 中添加、查看和刪除 AppWidgets 的元素。替代發射器可能
省略這些用戶界面元素；然而，如果它們被省略，設備實現者必須提供一個
可從 Launcher 訪問的獨立應用程序，允許用戶添加、查看和刪除
應用程序小部件。

3.8.2.通知
Android 包含允許開發人員通知用戶重要事件的 API [資源，15]。設備
實施者必須為如此定義的每一類通知提供支持；特別是：聲音，
震動、燈光和狀態欄。
此外，實現必須正確呈現所有資源（圖標、聲音文件等）
在 API [資源， 7] 或狀態欄圖標樣式指南 [資源，16] 中提供。設備
實施者可以為通知提供替代的用戶體驗，而不是
參考 Android 開源實現；但是，此類替代通知系統必須
支持現有的通知資源，如上所述。
3.8.3.搜索
Android 包括允許開發人員將搜索合併到他們的應用程序中的API [參考資料， 17]，
並將其應用程序的數據公開到全球系統搜索中。一般來說，這個功能
由一個單一的、系統範圍的用戶界面組成，允許用戶輸入查詢、顯示建議
as users type, and displays results. The Android APIs allow developers to reuse this interface to provide
search within their own apps, and allow developers to supply results to the common global search user
interface.
Device implementations MUST include a single, shared, system-wide search user interface capable of
real-time suggestions in response to user input. Device implementations MUST implement the APIs that
allow developers to reuse this user interface to provide search within their own applications.
Device implementations MUST implement the APIs that allow third-party applications to add suggestions
to the search box when it is run in global search mode. If no third-party applications are installed that
make use of this functionality, the default behavior SHOULD be to display web search engine results and
suggestions.
Device implementations MAY ship alternate search user interfaces, but SHOULD include a hard or soft
dedicated search button, that can be used at any time within any app to invoke the search framework,
with the behavior provided for in the API documentation.
3.8.4. Toasts
Applications can use the "Toast" API (defined in [ Resources, 18]) to display short non-modal strings to the
end user, that disappear after a brief period of time. Device implementations MUST display Toasts from
applications to end users in some high-visibility manner.
4. Reference Software Compatibility
Device implementers MUST test implementation compatibility using the following open-source
applications:
• Calculator (included in SDK)
• Lunar Lander (included in SDK)
• ApiDemos (included in SDK)
• The "Apps for Android" applications [ Resources, 19]
Each app above MUST launch and behave correctly on the implementation, for the implementation to be

considered compatible.
5. Application Packaging Compatibility
Device implementations MUST install and run Android ".apk" files as generated by the "aapt" tool
included in the official Android SDK [ Resources , 20].
Devices implementations MUST NOT extend either the .apk, Android Manifest, or Dalvik bytecode
formats in such a way that would prevent those files from installing and running correctly on other
compatible devices. Device implementers SHOULD use the reference upstream implementation of Dalvik,
and the reference implementation's package management system.
6. Multimedia Compatibility
A compatible Android device must support the following multimedia codecs. All of these codecs are
provided as software implementations in the preferred Android implementation from the Android Open
Source Project [ Resources , 4].
Please note that neither Google nor the Open Handset Alliance make any representation that these
codecs are unencumbered by third-party patents. Those intending to use this source code in hardware or
software products are advised that implementations of this code, including in open source software or
shareware, may require patent licenses from the relevant patent holders.
Audio
Name
Encoder Decoder Details
Files Supported
Mono/Stereo content in any
3GPP (.3gp) and
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
up to 160 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
3GPP (.3gp) and
HE-AACv1
combination of standard bit rates
MPEG-4 (.mp4, .m4a)
X
(AAC+)
up to 96 kbps and sampling rates files. No support for raw
between 8 to 48kHz
AAC (.aac)
Mono/Stereo content in any
HE-AACv2
3GPP (.3gp) and
combination of standard bit rates
(enhanced
MPEG-4 (.mp4, .m4a)
X
up to 96 kbps and sampling rates
AAC+)
files. No support for raw
between 8 to 48kHz
AAC (.aac)
AMR-NB
4.75 to 12.2 kbps sampled @
3GPP (.3gp) files
X
X
8kHz
AMR-WB
9 rates from 6.60 kbit/s to 23.85
-3GPP (.3gp) files
X
kbit/s sampled @ 16kHz
MP3
Mono/Stereo 8-320Kbps constant MP3 (.mp3) files
X
(CBR) or variable bit-rate (VBR)
Type 0 and 1 (.mid, .xmf,
MIDI Type 0 and 1. DLS Version 1
MIDI
X
.mxmf). Also RTTTL/RTX
and 2. XMF and Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

Support for ringtone formats
and iMelody (.imy)
RTTTL/RTX, OTA, and iMelody
Ogg Vorbis
.ogg
X
8- and 16-bit linear PCM (rates up
PCM
X
WAVE
to limit of hardware)
Image
Files
Name
Encoder Decoder Details
Supported
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
Video
Files
Name
Encoder Decoder Details
Supported
3GPP (.3gp)
H.263
X
X
files
3GPP (.3gp)
H.264
X
and MPEG-4
(.mp4) files
MPEG4
X
3GPP (.3gp) file
SP
7. Developer Tool Compatibility
Device implementations MUST support the Android Developer Tools provided in the Android SDK.
Specifically, Android-compatible devices MUST be compatible with:
• Android Debug Bridge or adb [Resources , 21]
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 or ddms [Resources , 22]
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, 23]
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 1.6 compatible devices must support. In
Android 1.6, the majority of hardware features (such as WiFi, compass, and accelerometer) are required.
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.
8.1. Display
Android 1.6 includes facilities that perform certain automatic scaling and transformation operations under
some circumstances, to ensure that third-party applications run reasonably well on hardware
configurations for which they were not necessarily explicitly designed [Resources, 24] . Devices MUST
properly implement these behaviors, as detailed in this section.
8.1.1. Standard Display Configurations
This table lists the standard screen configurations considered compatible with Android:
Diagonal
Screen Size
Screen Density
Screen Type
Width (Pixels)
Height (Pixels)
Length Range
Group
Group
(inches)
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,
25] 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:

• Device implementations MUST interpret any resources that are present as defaulting to
"medium" (known as "mdpi" in the SDK documentation.)
• When operating on a "low" density screen, device implementations MUST scale down medium/
mdpi assets by a factor of 0.75.
• When operating on a "high" density screen, device implementations MUST scale up medium/
mdpi assets by a factor of 1.5.
• Device implementations MUST NOT scale assets within a density range, and MUST scale
assets by exactly these factors between density ranges.
8.1.2. Non-Standard Display Configurations
Display configurations that do not match one of the standard configurations listed in Section 8.2.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 1.6; 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 values for all display metrics defined in
android.util.DisplayMetrics [Resources , 26].
8.2. Keyboard
Device implementations:
• MUST include support for the Input Management Framework (which allows third party
developers to create Input Management Engines -- ie soft keyboard) as detailed at
developer.android.com
• MUST provide at least one soft keyboard implementation (regardless of whether a hard
keyboard is present)
• MAY include additional soft keyboard implementations
• MAY include a hardware keyboard
• MUST NOT include a hardware keyboard that does not match one of the formats specified
in android.content.res.Configuration [ Resources, 25] (that is, QWERTY, or 12-key)
8.3. Non-touch Navigation
Device implementations:
• MAY omit non-touch navigation options (that is, may omit a trackball, 5-way directional pad, or
wheel)
• MUST report via android.content.res.Configuration [Resources , 25] the correct value for the
device's hardware

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:
• MUST have a touchscreen
• MAY have either capacative or resistive touchscreen
• MUST report the value of android.content.res.Configuration [ Resources, 25] reflecting
corresponding to the type of the specific touchscreen on the device
8.6. USB
Device implementations:
• MUST implement a USB client, connectable to a USB host with a standard USB-A port
• MUST implement the Android Debug Bridge over USB (as described in Section 7)
• MUST implement a USB mass storage client for the removable/media storage is present in the
device
• SHOULD use the micro USB form factor on the device side
• SHOULD implement support for the USB Mass Storage specification (so that either removable
or fixed storage on the device can be accessed from a host PC)
• MAY include a non-standard port on the device side, but if so MUST ship with a cable capable of
connecting the custom pinout to standard USB-A port
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. WiFi
Device implementations MUST support 802.11b and 802.11g, and MAY support 802.11a.

8.9. Camera
Device implementations MUST include a camera. The included camera:
• 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.
Device implementations MUST implement the following behaviors for the camera-related APIs
[Resources, 27] :
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.
8.9.1. Non-Autofocus Cameras
If a device lacks an autofocus camera, the device implementer MUST meet the additional requirements in
this section. Device implementations MUST implement the full Camera API included in the Android 1.6
SDK documentation in some reasonable way, regardless of actual camera hardware's capabilities.
For Android 1.6, if the camera lacks auto-focus, the device implementation MUST adhere to the following:
1. The system MUST include a read-only system property named "ro.workaround.noautofocus"
with the value of "1". This value is intended to be used by applications such as Android Market to
selectively identify device capabilities, and will be replaced in a future version of Android with a
robust API.
2. If an application calls android.hardware.Camera.autoFocus(), the system MUST call the
onAutoFocus() callback method on any registered
android.hardware.Camera.AutoFocusCallback instances, even though no focusing actually
happened. This is to avoid having existing applications break by waiting forever for an autofocus
callback that will never come.
3. The call to the AutoFocusCallback.onAutoFocus() method MUST be triggered by the driver or
framework in a new event on the main framework Looper thread. That is, Camera.autoFocus()
MUST NOT directly call AutoFocusCallback.onAutoFocus() since this violates the Android
framework threading model and will break apps.
8.10. Accelerometer
Device implementations MUST include a 3-axis accelerometer and MUST be able to deliver events at at
least 50 Hz. The coordinate system used by the accelerometer MUST comply with the Android sensor
coordinate system as detailed in the Android API s [Resources , 28].

8.11. Compass
Device implementations MUST include a 3-axis compass and MUST be able to deliver events at at least
10 Hz. The coordinate system used by the compass MUST comply with the Android sensor coordinate
system as defined in the Android API [Resources , 28].
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
Device implementations:
• MUST include either GSM or CDMA telephony
• MUST implement the appropriate APIs as detailed in the Android SDK documentation at
developer.android.com
Note that this requirement implies that non-phone devices are not compatible with Android 1.6; Android
1.6 devices MUST include telephony hardware. Please see Appendix C for information on non-phone
devices.
8.14. Volume controls
Android-compatible devices MUST include a mechanism to allow the user to increase and decrease the
audio volume. Device implementations MUST make these functions available to the user at all times,
regardless of application state. These functions MAY be implemented using physical hardware keys,
software, gestures, touch panel, etc., but they MUST be always accessible and not obscure or interfere
with the available application display area (see Display above).
When these buttons are used, the corresponding key events MUST be generated and sent to the
foreground application. If the event is not intercepted and sunk by the application then device
implementation MUST handle the event as a system volume control.
9. Performance Compatibility
One of the goals of the Android Compatibility Program is to ensure a consistent application experience for
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 1.6 compatible device,
as in the table below:
Metric
Performance Threshold
Comments

This is tested by CTS.
The following applications
The launch time is measured as the total time to
should launch within the
complete loading the default activity for the
Application
specified time.
application, including the time it takes to start the
Launch Time
Browser: less than 1300ms
Linux process, load the Android package into the
MMS/SMS: less than 700ms
Dalvik VM, and call onCreate.
AlarmClock: less than 650ms
Multiple applications will be
This is tested by CTS.
launched. Re-launching the
Simultaneous first application should
Applications
complete taking 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, 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 following security mechanisms:
10.1. Permissions
Device implementations MUST support the Android permissions model as defined in the Android
developer documentation [ Resources , 9]. 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. User 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].
11. Compatibility Test Suite
Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 3] 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 1.6. However, such releases will only fix behavioral bugs in the CTS
tests and will not impose any new tests, behaviors or APIs for a given platform release.
12. Contact Us
You can contact the Android Compatibility Team at compatibility@android.com for clarifications related to
this Compatibiltiy Definition and to provide feedback on this Definition.

Appendix A: Required Application Intents
NOTE: this list is provisional, and will be updated in the future.
Application Actions
Schemes MIME Types
(none)
text/plain
http
text/html
Browser
android.intent.action.VIEW
https
application/xhtml+xml
application/
vnd.wap.xhtml+xml
(none)
android.intent.action.WEB_SEARCH
http
(none)
https
android.media.action.IMAGE_CAPTURE
android.media.action.STILL_IMAGE_CAMERA
Camera
android.media.action.VIDEO_CAMERA
android.media.action.VIDEO_CAPTURE
vnd.android.cursor.dir/
android.intent.action.VIEW
image
android.intent.action.GET_CONTENT
vnd.android.cursor.dir/
android.intent.action.PICK
video
android.intent.action.ATTACH_DATA
image/*
video/*
android.intent.action.VIEW
rtsp
video/mp4
video/3gp
android.intent.action.VIEW
http
video/3gpp
video/3gpp2
android.intent.action.DIAL
Phone /
android.intent.action.VIEW
tel
Contacts
android.intent.action.CALL
android.intent.action.DIAL
vnd.android.cursor.dir/
android.intent.action.VIEW
person

vnd.android.cursor.dir/
person
vnd.android.cursor.dir/
android.intent.action.PICK
phone
vnd.android.cursor.dir/
postal-address
vnd.android.cursor.item/
person
vnd.android.cursor.item/
android.intent.action.GET_CONTENT
phone
vnd.android.cursor.item/
postal-address
text/plain
Email
android.intent.action.SEND
image/*
video/*
android.intent.action.VIEW
mailto
android.intent.action.SENDTO
sms
android.intent.action.VIEW
smsto
SMS / MMS android.intent.action.SENDTO
mms
mmsto
audio/*
application/ogg
Music
android.intent.action.VIEW
file
application/x-ogg
application/itunes
audio/mp3
audio/x-mp3
android.intent.action.VIEW
http
audio/mpeg
audio/mp4
audio/mp4a-latm
vnd.android.cursor.dir/
artistalbum
vnd.android.cursor.dir/
album
vnd.android.cursor.dir/
android.intent.action.PICK
nowplaying
vnd.android.cursor.dir/
track
nd.android.cursor.dir/
playlist
vnd.android.cursor.dir/
video
media/*
audio/*
android.intent.action.GET_CONTENT
application/ogg
application/x-ogg
video/*

content
Package
android.intent.action.VIEW
file
Installer
package
file
android.intent.action.PACKAGE_INSTALL
http
https
android.intent.action.ALL_APPS
android.settings.SETTINGS
android.settings.WIRELESS_SETTINGS
android.settings.AIRPLANE_MODE_SETTINGS
android.settings.WIFI_SETTINGS
android.settings.APN_SETTINGS
android.settings.BLUETOOTH_SETTINGS
android.settings.DATE_SETTINGS
android.settings.LOCALE_SETTINGS
Settings
android.settings.INPUT_METHOD_SETTINGS
com.android.settings.SOUND_SETTINGS
com.android.settings.DISPLAY_SETTINGS
android.settings.SECURITY_SETTING
android.settings.LOCATION_SOURCE_SETTINGS
android.settings.INTERNAL_STORAGE_SETTINGS
android.settings.MEMORY_CARD_SETTINGS
android.intent.action.SET_WALLPAPER
Search
android.intent.action.SEARCH
query
android.intent.action.SEARCH_LONG_PRESS
Voice
android.intent.action.VOICE_COMMAND
Contacts Management
Intent Action
Description
Starts an Activity that lets the user pick
ATTACH_IMAGE
a contact to attach an image to.
Used
EXTRA_CREATE_DESCRIPTION
with SHOW_OR_CREATE_CONTACT to
specify an exact description to be

shown when prompting user about
creating a new contact.
Used
with SHOW_OR_CREATE_CONTACT to
EXTRA_FORCE_CREATE
force creating a new contact if no
matching contact found.
This is the intent that is fired when a
SEARCH_SUGGESTION_CLICKED
search suggestion is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED search suggestion for creating a
contact is clicked on.
This is the intent that is fired when a
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
search suggestion for dialing a number
is clicked on.
Takes as input a data URI with a mailto:
SHOW_OR_CREATE_CONTACT
or tel: scheme.

Appendix B: Required Broadcast Intents NOTE: this list is provisional, and will be
updated in the future.
Intent Action
Description
Broadcast Action: This is broadcast once, after the
ACTION_BOOT_COMPLETED
system has finished booting.
Broadcast Action: This is broadcast once, when a
ACTION_CALL_BUTTON
call is received.
Broadcast Action: The "Camera Button" was
ACTION_CAMERA_BUTTON
pressed.
Broadcast Action: The current
ACTION_CONFIGURATION_CHANGED
device Configuration (orientation, locale, etc) has
changed.
ACTION_DATE_CHANGED
Broadcast Action: The date has changed.
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_LOW
on the device
Broadcast Action: Indicates low memory condition
ACTION_DEVICE_STORAGE_OK
on the device no longer exists
Broadcast Action: Wired Headset plugged in or
ACTION_HEADSET_PLUG
unplugged.
Broadcast Action: An input method has been
ACTION_INPUT_METHOD_CHANGED
changed.
Broadcast Action: External media was removed
ACTION_MEDIA_BAD_REMOVAL
from SD card slot, but mount point was not
unmounted.
Broadcast Action: The "Media Button" was
ACTION_MEDIA_BUTTON
pressed.
Broadcast Action: External media is present, and
being disk-checked The path to the mount point for
ACTION_MEDIA_CHECKING
the checking media is contained in the
Intent.mData field.
Broadcast Action: User has expressed the desire to
ACTION_MEDIA_EJECT
remove the external storage media.
Broadcast Action: External media is present and
ACTION_MEDIA_MOUNTED
mounted at its mount point.
Broadcast Action: External media is present, but is
using an incompatible fs (or is blank) The path to
ACTION_MEDIA_NOFS
the mount point for the checking media is
contained in the Intent.mData field.
Broadcast Action: External media has been
ACTION_MEDIA_REMOVED
removed.
Broadcast Action: The media scanner has finished
ACTION_MEDIA_SCANNER_FINISHED
scanning a directory.
Broadcast Action: Request the media scanner to
ACTION_MEDIA_SCANNER_SCAN_FILE
scan a file and add it to the media database.

Broadcast Action: The media scanner has started
ACTION_MEDIA_SCANNER_STARTED
scanning a directory.
Broadcast Action: External media is unmounted
ACTION_MEDIA_SHARED
because it is being shared via USB mass storage.
Broadcast Action: External media is present but
ACTION_MEDIA_UNMOUNTABLE
cannot be mounted.
Broadcast Action: External media is present, but
ACTION_MEDIA_UNMOUNTED
not mounted at its mount point.
Broadcast Action: An outgoing call is about to be
ACTION_NEW_OUTGOING_CALL
placed.
Broadcast Action: A new application package has
ACTION_PACKAGE_ADDED
been installed on the device.
Broadcast Action: An existing application package
ACTION_PACKAGE_CHANGED
has been changed (eg a component has been
enabled or disabled.
Broadcast Action: The user has cleared the data of
a package. This should be preceded
by ACTION_PACKAGE_RESTARTED, after which
ACTION_PACKAGE_DATA_CLEARED
all of its persistent data is erased and this
broadcast sent. Note that the cleared package
does not receive this broadcast. The data contains
the name of the package.
Broadcast Action: An existing application package
has been removed from the device. The data
ACTION_PACKAGE_REMOVED
contains the name of the package. The package
that is being installed does not receive this Intent.
Broadcast Action: A new version of an application
ACTION_PACKAGE_REPLACED
package has been installed, replacing an existing
version that was previously installed.
Broadcast Action: The user has restarted a
package, and all of its processes have been killed.
All runtime state associated with it (processes,
ACTION_PACKAGE_RESTARTED
alarms, notifications, etc) should be removed. Note
that the restarted package does not receive this
broadcast. The data contains the name of the
package.
Broadcast Action: Some content providers have
parts of their namespace where they publish new
ACTION_PROVIDER_CHANGED
events or items that the user may be especially
interested in.
ACTION_SCREEN_OFF
Broadcast Action: Sent after the screen turns off.
ACTION_SCREEN_ON
Broadcast Action: Sent after the screen turns on.
Broadcast Action: A user ID has been removed
ACTION_UID_REMOVED
from the system.
Broadcast Action: The device has entered USB
ACTION_UMS_CONNECTED
Mass Storage mode.

Broadcast Action: The device has exited USB
ACTION_UMS_DISCONNECTED
Mass Storage mode.
Broadcast Action: Sent when the user is present
ACTION_USER_PRESENT
after device wakes up (eg when the keyguard is
gone).
Broadcast Action: The current system wallpaper
ACTION_WALLPAPER_CHANGED
has changed.
ACTION_TIME_CHANGED
Broadcast Action: The time was set.
ACTION_TIME_TICK
Broadcast Action: The current time has changed.
ACTION_TIMEZONE_CHANGED
Broadcast Action: The timezone has changed.
Broadcast Action: The charging state, or charge
ACTION_BATTERY_CHANGED
level of the battery has changed.
Broadcast Action: Indicates low battery condition
ACTION_BATTERY_LOW
on the device. This broadcast corresponds to the
"Low battery warning" system dialog.
Broadcast Action: Indicates the battery is now okay
after being low. This will be sent
ACTION_BATTERY_OKAY
after ACTION_BATTERY_LOW once the battery
has gone back up to an okay state.
Network State
Intent Action
Description
Broadcast intent action indicating that the
NETWORK_STATE_CHANGED_ACTION
state of Wi-Fi connectivity has changed.
Broadcast intent action indicating that the
RSSI_CHANGED_ACTION
RSSI (signal strength) has changed.
Broadcast intent action indicating that a
SUPPLICANT_STATE_CHANGED_ACTION
connection to the supplicant has been
established or lost.
Broadcast intent action indicating that Wi-Fi
WIFI_STATE_CHANGED_ACTION
has been enabled, disabled, enabling,
disabling, or unknown.
The network IDs of the configured networks
NETWORK_IDS_CHANGED_ACTION
could have changed.
Broadcast intent action indicating that the
ACTION_BACKGROUND_DATA_SETTING_CHANGED setting for background data usage has
changed values.
Broadcast intent indicating that a change in
CONNECTIVITY_ACTION
network connectivity has occurred.
Broadcast Action: The user has switched the
ACTION_AIRPLANE_MODE_CHANGED
phone into or out of Airplane Mode.

Appendix C: Future Considerations This appendix clarifies certain portions of this Android
1.6 Compatibility Definition, and in some cases discusses anticipated or planned changes intended for a
future version of the Android platform. This appendix is for informational and planning purposes only, and
is not part of the Compatibility Definition for Android 1.6.
1. Non-telephone Devices
Android 1.6 is intended exclusively for telephones; telephony functionality is not optional. Future versions
of the Android platform are expected to make telephony optional (and thus allow for non-phone Android
devices), but only phones are compatible with Android 1.6.
2. Bluetooth Compatibility
The Android 1.6 release of Android does not support Bluetooth APIs, so from a compatibility perspective
Bluetooth does not impose any considerations for this version of the platform. However, a future version
of Android will introduce Bluetooth APIs. At that point, supporting Bluetooth will become mandatory for
compatibility.
Consequently, we strongly recommend that Android 1.6 devices include Bluetooth, so that they will be
compatible with future versions of Android that require Bluetooth.
3. Required Hardware Components
All hardware components in Section 8 (including WiFi, magnetometer/compass, accelerometer, etc.) are
required and may not be omitted. Future versions of Android are expected to make some (but not all) of
these components optional, in tandem with corresponding tools for third-party developers to handle these
changes.
4. Sample Applications
The Compatibility Definition Document for a future version of Android will include a more extensive and
representative list of applications than the ones listed in Section 4, above. For Android 1.6, the
applications listed in Section 4 must be tested.
5. Touch Screens
Future versions of the Compatibility Definition may or may not allow for devices to omit touchscreens.
However, currently much of the Android framework implementation assumes the existence of a
touchscreen; omitting a touchscreen would break substantially all current third-party Android applications,
so in Android 1.6 a touchscreen is required for compatibility.

6. Performance
Future versions of CTS will also measure the CPU utilization and performance of the following
components of an implementation:
• 2D graphics
• 3D graphics
• Video playback
• Audio playback
• Bluetooth A2DP playback

Android 1.6 兼容性定義

Document Outline