版權所有 © 2010，Google Inc. 保留所有權利。
相容性@android.com
一、簡介
本文檔列舉了手機相容Android 2.1必須滿足的要求。
「必須」、「不得」、「必需」、「應」、「不應」、「應該」、「不應該」、「建議」、「可以」和「可選」的使用符合 IETF 標準RFC2119 [參考資料, 1 ] 中定義。
在本文檔中，「裝置實現者」或「實現者」是指開發運行 Android 2.1 的硬體/軟體解決方案的個人或組織。 「設備實現」或「實現」是這樣開發的硬體/軟體解決方案。
要被視為與 Android 2.1 相容，裝置實作：
- 必須滿足本相容性定義中提出的要求，包括透過引用納入的任何文件。
- 必須透過裝置實現軟體完成時可用的最新版本的 Android 相容性測試套件 (CTS)。 （CTS 作為 Android 開源專案 [參考資料，2 ] 的一部分提供。）CTS 測試了本文檔中概述的許多（但不是全部）元件。
如果此定義或 CTS 未提及、不明確或不完整，則設備實現者有責任確保與現有實現的兼容性。因此，Android 開源專案 [參考資料, 3 ] 既是 Android 的參考實現，也是首選實現。強烈鼓勵設備實施者將其實施基於 Android 開源專案提供的「上游」原始碼。雖然假設某些組件可以替換為替代實現，但強烈建議不要這樣做，因為通過 CTS 測試將變得更加困難。實作者有責任確保與標準 Android 實作完全行為相容，包括相容性測試套件。最後，請注意，本文檔明確禁止某些組件替換和修改。
2. 資源
其中許多資源直接或間接源自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 系統的版本，採用人類可讀的格式。該欄位必須具有 [ Resources, 7 ] 中定義的字串值之一。 |
| android.os.Build.VERSION.SDK | 目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 2.1，此欄位必須具有整數值 7. |
| android.os.Build.VERSION.INCRMENTAL | 裝置實現者選擇的值，以人類可讀的格式指定目前正在執行的 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.INCRMENTAL 相同，但應該是一個對於最終用戶區分軟體版本足夠有意義的值。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。 |
| android.os.Build.MODEL | 設備實現者選擇的值，包含最終使用者已知的設備名稱。此名稱應與設備行銷和銷售給最終用戶時使用的名稱相同。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。 |
| android.os.Build.PRODUCT | 設備實現者選擇的值，包含設備的開發名稱或程式碼名稱。必須是人類可讀的，但不一定供最終用戶查看。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。 |
| android.os.Build.TAGS | 由設備實現者選擇的以逗號分隔的標籤列表，用於進一步區分構建。例如，“未簽名，調試”。此欄位不得為 null 或空字串 ("")，但單一標籤（例如「release」）就可以。 |
| android.os.Build.TIME | 表示建置發生時的時間戳記的值。 |
| android.os.Build.TYPE | 由設備實現者選擇的值，指定建置的運行時配置。此欄位應該具有與三種典型 Android 運行時配置相對應的值之一：「user」、「userdebug」或「eng」。 |
| android.os.Build.USER | 產生建置的使用者（或自動使用者）的名稱或使用者 ID。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。 |
3.2.3. Intent 相容性
Android 使用 Intent 來實現應用程式之間的鬆散耦合整合。本節描述與設備實現必須遵守的意圖模式相關的要求。 「榮幸」意味著裝置實現者必須提供一個 Android Activity 或 Service，指定匹配的 Intent 過濾器，並綁定到每個指定的 Intent 模式並實現正確的行為。
3.2.3.1.核心應用程式意圖
Android 上游專案定義了許多核心應用程序，例如電話撥號器、日曆、通訊錄、音樂播放器等。設備實施者可以用替代版本替換這些應用程式。
但是，任何此類替代版本都必須遵循上游項目提供的相同意圖模式。例如，如果裝置包含替代音樂播放器，它仍然必須遵循第三方應用程式發出的意圖模式來選擇歌曲。
以下應用程式被視為核心 Android 系統應用程式：
- 桌面時鐘
- 瀏覽器
- 日曆計算器
- 相機
- 聯絡人
- 電子郵件
- 畫廊
- GlobalSearch
- 啟動
- 器
- LivePicker（即動態桌布選擇器應用程式；如果裝置不支援動態桌布，則可以根據第3.8 .5 節省略。)
- 訊息傳遞（又稱「Mms」）
- 音樂
- 電話
- 設定
- SoundRecorder
核心 Android 系統應用程式包括各種被視為「公共」的 Activity 或 Service 元件。也就是說，屬性「android:exported」可以不存在，或者可以有值「true」。
對於核心 Android 系統應用程式之一中定義的每個活動或服務，如果未透過值為「false」的 android:exported 屬性標記為非公開，則裝置實作必須包含實作相同 Intent 篩選器的相同類型的元件模式作為Android系統的核心應用程式。
換句話說，裝置實作可以取代核心 Android 系統應用程式；但是，如果是這樣，裝置實作必須支援每個被替換的核心 Android 系統應用程式定義的所有 Intent 模式。
3.2.3.2. Intent 覆蓋
由於 Android 是一個可擴展平台，設備實現者必須允許第三方應用程式覆蓋核心系統應用程式中定義的每個 Intent 模式。上游Android開源專案預設允許這樣做；設備實作者不得為系統應用程式使用這些 Intent 模式附加特殊權限，或阻止第三方應用程式綁定到這些模式並承擔對這些模式的控制。該禁止具體包括但不限於停用「選擇器」使用者介面，該介面允許使用者在全部處理相同意圖模式的多個應用程式之間進行選擇。
3.2.3.3. Intent 命名空間
裝置實現者不得包含任何使用 ACTION、CATEGORY 或 android.* 命名空間中的其他鍵字串來支援任何新 Intent 或廣播 Intent 模式的 Android 元件。裝置實現者不得包含任何使用 ACTION、CATEGORY 或屬於另一個組織的包空間中的其他鍵字串來遵循任何新 Intent 或廣播 Intent 模式的 Android 元件。設備實現者不得更改或擴展第 3.2.3.1 節中列出的核心應用程式所使用的任何 Intent 模式。
該禁止類似於第 3.6 節中為 Java 語言類別指定的禁止。
3.2.3.4.廣播 Intents
第三方應用程式依靠平台廣播某些 Intent，以通知它們硬體或軟體環境的變化。 Android 相容裝置必須廣播公共廣播 Intents 以回應適當的系統事件。 SDK 文件中描述了廣播意圖。
3.3.本機 API 相容性
在 Dalvik 中運行的託管程式碼可以呼叫應用程式 .apk 檔案中提供的本機程式碼，作為針對適當裝置硬體架構編譯的 ELF .so 檔案。設備實作必須支援在託管環境中執行的程式碼，以使用標準 Java 本機介面 (JNI) 語意呼叫本機程式碼。以下 API 必須可供本機程式碼使用：
- libc（C 函式庫）
- libm（數學函式庫）
- JNI 介面
- libz（Zlib 壓縮）
- liblog（Android 日誌記錄）
- 對 C++ 的最低支援
- 支援 OpenGL，如下所述 設備實作必須支援 OpenGL ES
1.0 。缺乏硬體加速的設備必須使用軟體渲染器來實現 OpenGL ES 1.0。設備實作應該盡可能實現設備硬體支援的 OpenGL ES 1.1。如果硬體能夠在這些 API 上實現合理的效能，則設備實作應該提供 OpenGL ES 2.0 的實作。
這些函式庫必須與 Android 開源專案在 Bionic 中提供的版本來源相容（即標頭相容）和二進位相容（對於給定的處理器架構）。由於 Bionic 實作與其他實作（例如 GNU C 函式庫）不完全相容，因此裝置實作者應該使用 Android 實作。如果設備實現者使用這些庫的不同實現，他們必須確保標頭、二進位和行為相容性。
設備實作必須透過android.os.Build.CPU_ABI API 精確報告設備支援的本機應用程式二進位介面 (ABI)。 ABI 必須是最新版本的 Android NDK 中記錄的條目之一，位於檔案docs/CPU-ARCH-ABIS.txt中。請注意，Android NDK 的其他版本可能會引入對其他 ABI 的支援。
本機程式碼相容性具有挑戰性。因此，應該重申的是，強烈鼓勵設備實現者使用上面列出的庫的上游實現，以幫助確保相容性。
3.4. Web API 相容性
許多開發人員和應用程式的使用者介面依賴android.webkit.WebView類別 [參考資料，8 ] 的行為，因此 WebView 實作必須在 Android 實作之間相容。 Android開源實作使用WebKit渲染引擎來實作WebView。
由於為 Web 瀏覽器開發全面的測試套件是不可行的，因此設備實作者必須在 WebView 實作中使用 WebKit 的特定上游版本。具體來說：
- WebView 必須使用來自 Android 2.1 上游 Android 開源樹的 530.17 WebKit 建置。此版本包括一組針對 WebView 的特定功能和安全性修復。
- WebView 報告的用戶代理字串必須採用以下格式：
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17- ( VERSION) 字串必須與
android.os.Build.VERSION.RELEASE的值相同 - $(LOCALE) 字串的值應該遵循國家代碼和語言的 ISO 約定，並且應該引用當前配置的區域設定設備的
- $(MODEL)字串的值必須與
android.os.Build.MODEL的值相同 - $(BUILD) 字串的值必須與
android.os.Build.ID實作可以在獨立的
- ( VERSION) 字串必須與
瀏覽器應用程式中提供自訂用戶代理字串。更重要的是，獨立瀏覽器可以基於替代瀏覽器技術（例如 Firefox、Opera 等）。但是，即使發布了替代瀏覽器應用程序，提供給第三方應用程式的 WebView 元件也必須基於 WebKit，如上。
WebView 配置必須包括對 HTML5 資料庫、應用程式快取和地理定位 API 的支援 [參考資料，9 ]。 WebView 必須以某種形式支援 HTML5 <video>標籤。獨立的瀏覽器應用程式（無論是基於上游 WebKit 瀏覽器應用程式還是第三方替代方案）必須包含對剛剛為 WebView 列出的相同 HTML5 功能的支援。
3.5. API 行為相容性
每個 API 類型（託管、軟體、本機和 Web）的行為必須與上游 Android 開源專案的首選實作一致 [參考資料, 3 ]。一些特定的兼容性領域包括：
- 設備不得更改標準 Intent 的行為或含義
- 設備不得更改特定類型的系統組件（例如 Service、Activity、ContentProvider 等）的生命週期或生命週期語義 設備不得更改更改特定權限
- 的語義
上面的清單並不全面，設備實現者有責任確保行為相容性。因此，裝置實現者應該盡可能使用透過 Android 開源專案提供的原始程式碼，而不是重新實作系統的重要部分。
相容性測試套件 (CTS) 測試平台的重要部分（但不是全部）的行為相容性。實作者有責任確保與 Android 開源專案的行為相容性。
3.6. API 命名空間
Android 遵循 Java 程式語言定義的套件和類別命名空間約定。為了確保與第三方應用程式的相容性，裝置實作者不得對這些套件命名空間進行任何禁止的修改（見下文）： java.* javax.* sun.* android.*
- com.android
- .
- *
- 禁止
- 的
修改包括：
- 裝置實作必須請勿透過變更任何方法或類別簽名，或刪除類別或類別欄位來修改 Android 平台上公開的 API。
- 設備實作者可以修改 API 的底層實現，但此類修改不得影響任何公開暴露的 API 的規定行為和 Java 語言簽章。
- 設備實作者不得為上述 API 新增任何公開暴露的元素（例如類別或接口，或現有類別或介面的欄位或方法）。
「公開暴露的元素」是上游 Android 原始碼中未以「@hide」標記修飾的任何構造。換句話說，設備實現者不得公開新的 API 或更改上述命名空間中的現有 API。設備實現者可以進行僅限內部的修改，但這些修改不得公佈或以其他方式暴露給開發人員。
設備實作者可以新增自訂 API，但任何此類 API 不得位於另一個組織擁有或引用另一個組織的命名空間中。例如，裝置實作者不得將 API 新增至 com.google.* 或類似的命名空間；只有谷歌可以這樣做。同樣，Google 不得將 API 新增至其他公司的命名空間。
如果設備實現者建議改進上述包命名空間之一（例如透過向現有 API 添加有用的新功能，或添加新 API），則實現者應該訪問 source.android.com 並開始貢獻更改和的過程代碼，根據該網站上的信息。
請注意，上述限制對應於 Java 程式語言中命名 API 的標準約定；本節的目的只是為了加強這些約定，並透過將其納入此相容性定義來使其具有約束力。
3.7.虛擬機器相容性
設備實作必須支援完整的 Dalvik 可執行檔 (DEX) 字節碼規格和 Dalvik 虛擬機器語意 [參考資料, 10 ]。
裝置實作必須配置 Dalvik 為螢幕分類為中或低密度的裝置上的每個應用程式分配至少 16MB 記憶體。裝置實作必須配置 Dalvik 為螢幕分類為高密度的裝置上的每個應用程式分配至少 24MB 記憶體。請注意，設備實現可能會分配比這些數字更多的內存，但這不是必需的。
3.8.使用者介面相容性
Android 平台包括一些開發人員 API，允許開發人員連接到系統使用者介面。設備實作必須將這些標準 UI API 合併到他們開發的自訂使用者介面中，如下所述。
3.8.1. Widgets
Android 定義了元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開「AppWidget」[參考資料，11 ]。 Android 開源參考版本包括一個 Launcher 應用程序，其中包含使用者介面元素，允許使用者在主畫面上新增、檢視和刪除 AppWidget。
設備實施者可以取代參考啟動器（即主螢幕）。替代啟動器應該包括對 AppWidget 的內建支持，並公開使用者介面元素以直接在啟動器內新增、配置、檢視和刪除 AppWidget。替代啟動器可以省略這些使用者介面元素；然而，如果它們被省略，設備實現者必須提供一個可從啟動器訪問的單獨應用程序，允許用戶添加、配置、查看和刪除 AppWidget。
3.8.2.通知
Android 包含 API，允許開發人員通知使用者值得注意的事件 [參考資料，12 ]。設備實現者必須為如此定義的每一類通知提供支援；具體來說：聲音、振動、燈光和狀態列。
此外，實作必須正確呈現 API [資源，13 ] 或狀態列圖示樣式指南 [資源，14 ] 中提供的所有資源（圖示、聲音檔案等）。裝置實現者可以為通知提供替代的使用者體驗，而不是參考 Android 開源實作提供的體驗；然而，如上所述，此類替代通知系統必須支援現有通知資源。
3.8.3.搜尋
Android 包含 API [參考資料，15 ]，允許開發人員將搜尋合併到他們的應用程式中，並將應用程式的資料公開到全域系統搜尋中。一般來說，此功能由單一系統範圍的使用者介面組成，允許使用者輸入查詢、在使用者鍵入時顯示建議並顯示結果。 Android API 允許開發人員重複使用此介面在自己的應用程式中提供搜索，並允許開發人員向通用全域搜尋使用者介面提供結果。
設備實現必須包括一個單一的、共享的、系統範圍的搜尋使用者介面，能夠響應用戶輸入提供即時建議。設備實作必須實作允許開發人員重複使用此使用者介面以在自己的應用程式中提供搜尋的 API。設備實作必須實作 API，允許第三方應用程式在全域搜尋模式下運行時向搜尋框添加建議。如果沒有安裝使用此功能的第三方應用程序，則預設行為應該是顯示網路搜尋引擎結果和建議。
設備實作可以提供備用搜尋使用者介面，但應該包括硬或軟專用搜尋按鈕，可以隨時在任何應用程式中使用該按鈕來呼叫搜尋框架，並具有 API 文件中提供的行為。
3.8.4. Toast
應用程式可以使用「Toast」API（在[參考資料，16 ]中定義）向最終用戶顯示短的非模式字串，這些字串會在短暫的一段時間後消失。裝置實作必須以某種高可見性的方式向最終使用者顯示應用程式的 Toast。
3.8.5。動態壁紙
Android 定義了一種元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開一個或多個「動態壁紙」[參考資料，17 ]。動態壁紙是動畫、圖案或具有有限輸入功能的類似圖像，在其他應用程式後面顯示為壁紙。
如果硬體能夠以合理的幀速率運行所有動態壁紙，且不限制功能，並且不會對其他應用程式產生不利影響，則認為該硬體能夠可靠地運行動態壁紙。如果硬體限制導致壁紙和/或應用程式崩潰、故障、消耗過多的 CPU 或電池電量，或以不可接受的低幀速率運行，則該硬體被視為無法運行動態壁紙。例如，某些動態桌布可能會使用 OpenGL 1.0 或 2.0 上下文來渲染其內容。動態桌布將無法在不支援多個 OpenGL 上下文的硬體上可靠地運行，因為使用 OpenGL 上下文的動態桌布可能會與也使用 OpenGL 上下文的其他應用程式發生衝突。
如上所述，能夠可靠地運行動態壁紙的設備實現應該實現動態壁紙。如上所述，確定無法可靠運行動態壁紙的設備實作不得實現動態壁紙。
4. 參考軟體相容性
裝置實現者必須使用以下開源應用程式測試實作相容性：
- 計算器（包含在 SDK 中）
- Lunar Lander（包含在 SDK 中）
- “Apps for Android”應用程式 [參考資料，18 ]。
上述每個應用程式必須啟動並在實作上正確運行，以便實現被認為是相容的。
此外，裝置實作必須測試每個冒煙測試應用程式的每個選單項目（包括所有子選單）：
- ApiDemos（包含在 SDK 中）
- ManualSmokeTests（包含在 CTS 中）
上述應用程式中的每個測試案例必須在設備上正確運行執行。
5. 應用程式打包相容性
裝置實作必須安裝並執行由官方 Android SDK 中包含的「aapt」工具產生的 Android「.apk」檔案 [參考資料，19 ]。
裝置實作不得擴充 .apk [ Resources, 20 ]、Android Manifest [ Resources, 21 ] 或 Dalvik 位元組碼 [ Resources, 10 ] 格式，以免阻止這些檔案在其他相容裝置上正確安裝和運作。設備實作者應該使用 Dalvik 的參考上游實作以及參考實作的套件管理系統。
6. 多媒體相容性
設備實作必須支援以下多媒體編解碼器。所有這些編解碼器均作為 Android 開源專案的首選 Android 實作中的軟體實作提供。
請注意，Google 和開放手機聯盟均未聲明這些編解碼器不受第三方專利的阻礙。打算在硬體或軟體產品中使用此原始碼的人請注意，此程式碼的實現（包括在開源軟體或共享軟體中）可能需要相關專利持有者的專利許可。
| 音訊 | ||||
| 名稱 | 編碼器 | 解碼器 | 詳細資訊 | 檔案/容器格式 |
| AAC LC/LTP | X | 單聲道/立體聲內容採用高達 160 kbps 的標準位元速率和 8 至 48kHz | 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 | 9 速率從 6.60 kbit/s 到 23.85 kbit/s，在 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 | Type 0 和 1（.mid、.xmf、.mxmf）。還有 RTTTL/RTX (.rtttl、.rtx)、OTA (.ota) 和 iMelody (.imy) | |
| Ogg Vorbis | X | 奧格 (.ogg) | ||
| PCM | X | 8 位元和 16 位元線性 PCM（速率達到硬體限制） | WAVE (.wav) | |
| 影像 | ||||
| JPEG | X | X | 基本 + 逐行 | |
| 動圖 | X | |||
| 巴布亞紐幾內亞 | _ | _ | ||
| 骨形態發生蛋白 | X | |||
| 影片 | ||||
| H.263 | X | X | 3GPP (.3gp) 文件 | |
| H.264 | X | 3GPP (.3gp) 和 MPEG-4 (.mp4) 檔案 | ||
| MPEG4 簡單設定文件 | X | 3GPP (.3gp) 檔案 |
請注意，上表並未列出大多數視訊編解碼器的特定位元率要求。這樣做的原因是，實際上，目前設備硬體不一定支援精確映射到相關標準指定的位元率的位元率。取而代之的是，設備實現應在硬體上支援最高的位元率實用，直到規格定義的限制。
7.開發人員工具相容性
設備實作必須支援Android SDK中提供的Android開發人員工具。具體而言，與Android相容的裝置必須與：
- Android調試橋（稱為ADB） [ Resources，19 ]
設備實作必須支援Android SDK中記錄的所有adb功能。裝置側adb守護程式預設應無活動，但必須有一個可存取使用者的機制來開啟Android偵錯橋。 - Dalvik調試監視器服務（稱為DDM） [資源，19 ]
設備實作必須支援Android SDK中記錄的所有ddms功能。由於ddms使用adb，因此預設情況下，對ddms的支援應無效，但每當使用者啟動Android Debug Bridge（如上所述）時，必須支援DDMS。 - 猴子[資源，22 ]
設備實作必須包括猴子框架，並使其可用於使用應用程式。
8.硬體相容性
Android旨在支援設備實施者創建創新的形式和配置。同時，Android開發人員期望所有Android設備中的某些硬件，感測器和API。本節列出了所有Android 2.1相容設備必須支援的硬體功能。
如果裝置包含具有針對第三方開發人員的對應API的特定硬體元件，則裝置實作必須在Android SDK文件中定義的API實作。如果SDK中的API與指定為可選的硬體元件相互作用，且設備實作不具備該元件：必須存在元件
- API的類別定義，則必須
- 以某種合理的方式將API的行為實作為NO-OPS
- API方法必須在SDK文件允許的情況下傳回null值，
- API方法必須傳回SDK文件不允許的null值的NO-OP實現，其中適用 這些要求的場景的典型範例是電話API：即使是在非非
上方的API： - 手機設備，必須將這些API實作為合理的NO-OPS。
設備實作必須透過getSystemAvailableFeatures()和hasSystemFeature(String)方法來準確報告準確的硬體配置信息， android.content.pm.PackageManager類別。
8.1.顯示
Android 2.1包括在某些情況下執行某些自動縮放和轉換操作的設施，以確保第三方應用程式在各種硬體配置上都可以很好地運行[ Resources，23 ]。如本節所述，設備必須正確實施這些行為。
對於Android 2.1，這是最常見的顯示配置：
| 螢幕類型 | 寬度（像素） | 高度（像素） | 對角線長度範圍（英吋） | 螢幕尺寸群組 | 螢幕密度群組 |
| QVGA | 240 | 320 | 240 | 320 | 2.6-3.0 |
| 小型 | WQVGA | 240 | 400 | 400 | 3.2 -3.2 |
| FWQVGA | 240 | 432 | 3.5-3.8 | 正常 | 低 |
| HVGA | 320 | 480 | 3.0-3.5 | 正常 | 中型 |
| WVGA | 480 | 800 | 3.3-4.0 | 正常 | 高 |
| FWVGA | 480 | 854 | 3.5-4.080WVV | 180 | 480 |
| 854 | 3.5-4.00WVV | . | _ | _ | _ |
| _ | 必須 | _ | _ | _ | _ |
_配置與上述標準配置之一相對應的，以透過android.content.res.Configuration [ Resources，24 ]類別報告指示的螢幕大小。
某些.APK軟體包的表現未識別為支援特定密度範圍。在執行此類應用程式時，請採用以下限制：
- 設備實作必須在.APK中解釋資源，該資源缺乏密度限定符（預設值為媒體」（在SDK文件中稱為「 MDPI」） 。螢幕，
- 設備實作必須將中等/MDPI資產縮小為0.75。
- 在「高」密度螢幕上運作時，裝置實作必須將中等/MDPI資產擴展1.5倍。
- 設備實現不得在密度範圍內擴展資產，並且必須透過密度範圍之間的這些因素來擴展資產。
8.1.2.非標準顯示配置
顯示配置與第8.1.1節中列出的標準配置之一不符的配置需要附加考慮和工作以相容。設備實施者必須在第12節中與Android相容性團隊聯繫，以取得螢幕尺寸的儲存桶，密度和縮放係數的分類。提供此資訊後，設備實作必須按照指定實現。
請注意，某些顯示配置（例如非常大或很小的螢幕和某些長寬比）與Android 2.1完全不相容；因此，鼓勵設備實施者在開發過程中儘早與Android相容性團隊聯繫。
8.1.3.顯示指標
設備實作必須報告正確的值，因為android.util.DisplayMetrics中定義的所有顯示指標[ Resources，25 ]。
8.2.鍵盤
裝置實作：
- 必須包含對輸入管理框架的支援（允許第三方開發人員建立輸入管理引擎 - IE軟鍵盤）
- 。存在
- 硬
- 鍵盤
android.content.res.Configuration.keyboardQwerty ，或12鍵） 8.3
。非觸發導航
設備實作：
- 可能省略非接觸導航選項（即省略軌跡球，D-pad或wheel）
- 必須報告適用於
android.content.res.Configuration.navigation的正確值[資源，24 ]
8.4。螢幕方向
相容裝置必須透過應用程式來支援肖像或景觀螢幕方向的動態方向。也就是說，設備必須尊重應用程式的特定螢幕方向請求。設備實作可以選擇肖像或景觀方向作為預設設備。
每當透過android.content.res.configuration.orientation，android.view.display.getorientation（）或其他apis查詢時，裝置必須報告裝置目前方向的正確值。
8.5。觸控螢幕輸入裝置
實現：
- 必須具有觸控螢幕
- 的能力或電阻觸控螢幕
- 必須報告
android.content.res.Configuration[ Resources，24 ]的值，反映了與裝置8.6上特定觸控螢幕的類型相對應的
。 USB
裝置實作：
- 必須實作一個USB客戶端，可連接具有標準USB-A連接埠的USB主機
- 必須實現USB上的Android調試橋（如第7節所述）
- 必須實現USB品質儲存規範，以允許宿主連接到設備訪問/sdcard卷的內容的設備
- 應使用設備側面的Micro USB外形尺寸，
- 可能包括設備側的非標準端口，但是如果可以的話，必須使用能夠將自定義引腳連接到的電纜運送到標準USB- A埠
8.7。導航鍵
對Android導航範式至關重要。設備實作必須使這些功能始終為使用者提供，而不論應用程式狀態如何。這些功能應透過專用按鈕實現。它們可以使用軟體，手勢，觸控面板等實現，但是如果這樣，它們必須始終可訪問，並且不會遮蓋或乾擾可用的應用顯示區域。
設備實現者還應提供專用的搜尋鍵。設備實施者還可以為電話提供發送和結束鍵。
8.8.無線數據網路
設備實作必須包括無線高速數據網路的支援。具體而言，設備實作必須包括至少一個能夠為200kbit/sec或更高的無線資料標準的支援。滿足此需求的技術的範例包括Edge，HSPA，EV-DO，802.11G等。
如果裝置實作包括Android SDK的特定模式，即API（即WIFI，GSM或CDMA），則實作必須支援API。
設備可以實現多種形式的無線數據連接。設備可以實現有線資料連接（例如乙太網路），但仍必須包含至少一種形式的無線連接，如上所述。
8.9。相機
設備的實作必須包括相機。隨附的相機：
- 必須具有至少2兆像素的分辨率，
- 應具有硬體自動對焦，或在相機驅動程式中實現的軟體自動對焦（對應用程式軟體透明）
- 可能具有固定對焦或EDOF（擴展的場地）硬體
- 可能包括閃光燈。如果攝影機包含閃光燈，則在Android.hardware.Camera.previewCallback實例中已註冊在相機預覽表面上，除非應用程式已透過啟用
FLASH_MODE_AUTO或FLASH_MODE_ON屬性明確啟用flash，否則不得點亮閃光燈。Camera.Parameters。請注意，此約束不適用於裝置的內建系統攝影機應用程序，而僅適用於使用Camera.PreviewCallback的第三方應用程式。
裝置實作必須實現與攝影機相關的API的以下行為：
- 如果應用程式從未稱為android.hardware.camera.camera.parameters.setpreviewformat（int），則裝置必須使用android.hardware.pixelformat.ycbcr_420_sp，以便為預覽數據提供了預覽數據應用程式回調。
- 如果一個應用程式註冊Android.hardware.camera.previewCallback實例，且系統在預覽格式為ycbcr_420_sp時呼叫onpreviewFrame（）方法，則必須在onpreviewframe（）中傳遞到onpreviewframe（）中的資料中，也必須在NV21編碼格式中進一步。 （這是7K硬體家族的本機使用的格式。）也就是說，NV21必須是預設值。
裝置實作必須實作Android 2.1 SDK文件中包含的完整相機API [資源，26 ]），無論該裝置是否包含硬體自動對焦或其他功能。例如，缺乏自動對焦的攝影機仍然必須呼叫任何註冊的android.hardware.Camera.AutoFocusCallback實例（即使這與非Autofocus相機無關，
設備實現）必須識別並尊重每個參數名稱在每個參數名稱上定義為定義的常數android.hardware.Camera.Parameters類，如果基礎硬體支援此功能。如果設備硬體不支援功能，則API必須依照記錄。相反，裝置實作不得尊重或識別傳遞給android.hardware.Camera.setParameters()方法的字串常數，而不是在android.hardware.Camera.Parameters上記錄為Stonstants的方法，除非常量為字串，以指示字串表示字串，以指示字串指示字串。設備實施程序的名稱。也就是說，如果硬體允許，則設備實現必須支援所有標準的攝影機參數，並且不得支援自訂攝影機參數類型，除非透過字串前綴清楚地指示參數名稱是非標準的。
8.10。加速度計
設備的實作必須包括3軸加速度計，並且必須能夠以50 Hz或更高的速度提供事件。加速度計所使用的座標系必須符合Android API中詳細介紹的Android感測器座標系（請參閱[ Resources，27 ]）。
8.11。指南針
設備的實作必須包括3軸指南針，並且必須能夠提供10 Hz或更高的事件。指南針所使用的座標系必須遵守Android API中定義的Android感測器座標系（請參閱[資源，27 ]）。
8.12. GPS
設備實現必須包括GPS，並且應包括某種形式的「輔助GPS」技術，以最大程度地減少GPS鎖定時間。
8.13。電話
Android 2.1可以在不包括電話硬體的設備上使用。也就是說，Android 2.1與不是電話的裝置相容。但是，如果設備實作確實包括GSM或CDMA電話，則必須為該技術實施全部支援。不包括電話硬體的設備實作必須將完整的API作為NO-OPS實作。
另請參閱第8.8節，無線數據網路。
8.14。記憶體和儲存
裝置的實作必須至少具有92MB的記憶體可用於核心和使用者空間。 92MB必須是專門用於硬體組件（例如無線電，內存等）的任何內存，而不在核心的控制下。
設備實作必須至少具有150MB的非揮發性儲存空間，可用於使用者資料。也就是說， /data分區必須至少為150MB。
8.15。應用程式共享的儲存
設備實作必須為應用程式提供共享儲存。提供的共享儲存必須至少為2GB。
必須使用預設安裝的「開箱即用」安裝的共用儲存配置設備實作。如果共用儲存未安裝在Linux路徑/sdcard上，則該裝置必須包含從/sdcard到實際安裝點的Linux符號連結。
裝置實作必須依照記錄的android.permission.WRITE_EXTERNAL_STORAGE在此共用儲存中執行。共享儲存否則必須透過獲得該許可的任何應用程式可寫入。
設備實現可能具有用於用戶可存取的可移動儲存的硬件，例如安全的數位卡。另外，裝置實作可以將內部（不可拆卸）儲存空間分配為應用程式的共用儲存。
不管使用的共享存儲的形式如何，共享存儲都必須實現USB質量存儲，如第8.6節所述。當運箱即可到達時，必須將共用儲存安裝在脂肪檔案系統中。
考慮兩個常見的例子是說明的。如果裝置實作包含符合共享儲存需求的SD卡插槽，則必須將脂肪形式的SD卡2GB尺寸或更大的尺寸包含在裝置上，作為出售給用戶，並且預設必須安裝。另外，如果設備實作使用內部固定儲存來滿足此要求，則該儲存的大小或更大並安裝在/sdcard上（或/sdcard （如果安裝在其他地方），則必須是指向物理位置的符號連結。 ）注意
8.16。藍牙
設備實作必須包括藍牙收發器。裝置實作必須如SDK文件[ Resources，29 ]中所述啟用基於RFCOMM的藍牙API。設備實現應實現相關的藍牙配置文件，例如A2DP，AVRCP，OBEX等。
9.績效相容性
Android相容性計劃的目標之一是為消費者提供一致的應用程式經驗。相容的實作不僅必須確保應用程式在裝置上正確運行，而且還必須以合理的效能和整體良好的使用者體驗來確保應用程式的運作。裝置實作必須滿足下表中定義的Android 2.1相容裝置的關鍵效能指標：
| 公制 | 效能閾值 | 註解 |
| 應用程式啟動時間 | 以下應用程式應在指定的時間內啟動。
| 啟動時間被衡量為完成應用程式的預設活動的總時間，包括啟動Linux進程所需的時間，載入Android包裝到Dalvik VM中，然後致電ongreate。 |
| 同時 | 進行了應用程序，在啟動後重新啟動了已經運行的應用程式必須小於原始啟動時間。 |
10.安全模型相容性
設備實作必須實作與Android開發人員文件中API [ Resources，28 ]中的安全性和權限參考文件中定義的Android平台安全模型一致的安全模型。設備實作必須支援安裝自簽署的應用程序，而無需任何第三方/當局的任何其他權限/憑證。具體而言，相容的設備必須支援以下小節中所述的安全機制。
10.1.權限
設備實作必須支援Android開發人員文件中定義的Android權限模型[ Resources，28 ]。具體而言，實施必須執行按照SDK文件中所述的每個許可；無法省略，更改或忽略權限。如果新的權限ID字串不在Android中。*名稱空間，則實作可能會增加其他權限。
10.2. UID和製程隔離
設備實作必須支援Android應用程式沙盒模型，在該模型中，每個應用程式都以唯一的Unix式UID和單獨的流程運行。設備實作必須支援執行多個應用程式作為相同的Linux使用者ID，前提是在安全性和權限參考中定義的應用程式是正確簽署和建構的[ Resources，28 ]。
10.3.檔案系統權限
設備實作必須支援Android檔案存取權限模型，如安全性和權限參考所定義的所定義[ Resources，28 ]。
11.相容性測試套件
設備實作必須透過設備上的最終運輸軟體透過Android開源專案可從Android開源專案中獲得Android相容性測試套件（CTS）[ Resources，2 ]。此外，設備實施者應盡可能使用Android開源樹中的參考實現，並且必須確保在CTS含糊不清以及參考原始碼部分的任何重新實現的情況下相容。
CTS設計為在實際設備上運作。像任何軟體一樣，CTS本身可能包含錯誤。 CTS將與此相容性定義獨立於版本，並且可以為Android 2.1發布多個CTS的修訂。設備實作必須傳遞設備軟體完成時可用的最新CTS版本。
12.可更新的軟體
設備實作必須包括替換整個系統軟體的機制。該機構不必執行「即時」升級 - 也就是說，可能需要重新啟動設備。
只要可以替換設備上預先安裝的整個軟體，就可以使用任何方法。例如，以下任何方法都將滿足此要求：
- 透過重新啟動
- 「 tethered」更新USB的USB從主機PC「離線」
- 離線」更新透過重新啟動並從檔案上進行更新，並從檔案上進行更新，並從檔案上更新可移動儲存
使用的更新機制必須支援更新，而無需擦拭使用者資料。請注意，上游Android軟體包括滿足此要求的更新機制。
如果在發布後在設備實現中發現錯誤，但在其合理的產品壽命內與Android兼容性團隊協商確定以影響派對應用程序的兼容性，則設備實現者必須通過軟體糾正錯誤可根據剛才描述的機制應用的更新。
13.與我們聯繫，
您可以透過compatibility@android.com與文件作者聯繫以進行澄清，並提出您認為該文件不涵蓋的任何問題。