Android 2.2 相容性定義

版權所有 © 2010，Google Inc. 保留所有權利。
相容性@android.com

目錄

一、簡介
2. 資源
3、軟體
4. 參考軟體相容性
5. 應用程式封裝相容性
6. 多媒體相容性
7. 開發者工具相容性
8. 硬體相容性
9. 效能相容性
10. 安全模型相容性
11.相容性測試套件
12. 可更新的軟體
13. 聯絡我們
附錄 A - 藍牙測試程序

一、簡介

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

「必須」、「不得」、「必需」、「應」、「不應」、「應該」、「不應該」、「建議」、「可以」和「可選」的使用符合 IETF 標準RFC2119 [參考資料, 1 ] 中定義。

在本文檔中，「裝置實現者」或「實現者」是指開發運行 Android 2.2 的硬體/軟體解決方案的個人或組織。 「設備實現」或「實現」是這樣開發的硬體/軟體解決方案。

要被視為與 Android 2.2 相容，裝置實作：

  • 必須滿足本相容性定義中提出的要求，包括透過引用納入的任何文件。
  • 必須透過裝置實現軟體完成時可用的最新版本的 Android 相容性測試套件 (CTS)。 （CTS 作為 Android 開源專案 [參考資料，2 ] 的一部分提供。）CTS 測試了本文檔中概述的許多（但不是全部）元件。

如果此定義或 CTS 未提及、不明確或不完整，則設備實現者有責任確保與現有實現的兼容性。因此，Android 開源專案 [參考資料, 3 ] 既是 Android 的參考實現，也是首選實現。強烈鼓勵設備實施者將其實施基於 Android 開源專案提供的「上游」原始碼。雖然假設某些組件可以替換為替代實現，但強烈建議不要這樣做，因為通過 CTS 測試將變得更加困難。實作者有責任確保與標準 Android 實作完全行為相容，包括相容性測試套件。最後，請注意，本文檔明確禁止某些組件替換和修改。

2. 資源

  1. IETF RFC2119 要求等級： http://www.ietf.org/rfc/rfc2119.txt
  2. Android 相容性計劃概述： http://source.android.com/docs/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.2 允許的版本字串： http://source.android.com/docs/compatibility/2.2/versions.html
  8. android.webkit.WebView 類別： http://developer.android.com/reference/android/webkit/WebView.html
  9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  10. Dalvik 虛擬機器規格：可在 Android 原始碼中找到，位於 dalvik/docs
  11. 應用程式小工具： 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#statusbarstruct
  15. 搜尋管理員： http://developer.android.com/reference/android/app/SearchManager.html
  16. 吐司：http: //developer.android.com/reference/android/widget/Toast.html
  17. 動態桌布： https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. 適用於 Android 的應用程式：http: //code.google.com/p/apps-for-android
  19. 參考工具文件（針對adb、aapt、ddms）： http://developer.android.com/guide/developing/tools/index.html
  20. Android apk 檔案說明： http://developer.android.com/guide/topics/fundamentals.html
  21. 清單檔案： http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. Monkey測試工具： https://developer.android.com/studio/test/other-testing-tools/monkey
  23. Android 硬體功能清單： http://developer.android.com/reference/android/content/pm/PackageManager.html
  24. 支援多畫面： http://developer.android.com/guide/practices/screens_support.html
  25. android.content.res.Configuration： http://developer.android.com/reference/android/content/res/Configuration.html
  26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  27. android.hardware.Camera：http://developer.android.com/reference/android/hardware/Camera.html
  28. 感測器座標空間： http://developer.android.com/reference/android/hardware/SensorEvent.html
  29. Android 安全性與權限參考： http://developer.android.com/guide/topics/security/security.html
  30. 藍牙 API： http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3、軟體

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

3.1.託管 API 相容性

託管（基於 Dalvik）執行環境是 Android 應用程式的主要工具。 Android 應用程式介面 (API) 是向在託管 VM 環境中運行的應用程式公開的一組 Android 平台介面。設備實現必須提供 Android 2.2 SDK 公開的任何記錄的 API 的完整實現，包括所有記錄的行為 [參考資料，4 ]。

設備實作不得省略任何託管 API、更改 API 介面或簽章、偏離記錄的行為或包含無操作，除非本相容性定義明確允許。

3.2.軟 API 相容性

除了第 3.1 節中的託管 API 之外，Android 還包括一個重要的僅運行時「軟」API，其形式為 Intent、權限和 Android 應用程式的類似方面，這些方面無法在應用程式編譯時強制執行。本節詳細介紹與 Android 2.2 相容所需的「軟」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.2，此欄位必須具有整數值 8。
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.2/ERC77/3359:userdebug/test-keys
指紋不得包含空白字元。如果上述模板中包含的其他字段具有空白字符，則必須在構建指紋中將它們替換為另一個字符，例如下劃線（“_”）字符。
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.意圖相容性

Android 使用 Intent 來實現應用程式之間的鬆散耦合整合。本節描述與設備實現必須遵守的意圖模式相關的要求。 「榮幸」意味著裝置實現者必須提供一個 Android Activity 或 Service，指定匹配的 Intent 過濾器，並綁定到每個指定的 Intent 模式並實現正確的行為。

3.2.3.1.核心應用意圖

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

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

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

  • 英式鐘
  • 瀏覽器
  • 日曆
  • 計算機
  • 相機
  • 聯絡方式
  • 電子郵件
  • 畫廊
  • 全球搜尋
  • 啟動器
  • LivePicker（即動態壁紙選擇器應用程式；如果裝置不支援動態壁紙，則可以根據第 3.8.5 節省略。）
  • 訊息傳遞（又稱「彩信」）
  • 音樂
  • 電話
  • 設定
  • 錄音機

Android 系統核心應用程式包括各種被視為「公共」的 Activity 或 Service 元件。也就是說，屬性「android:exported」可以不存在，或者可以有值「true」。

對於核心 Android 系統應用程式之一中定義的每個活動或服務，如果未透過值為「false」的 android:exported 屬性標記為非公開，則裝置實作必須包含實作相同 Intent 篩選器的相同類型的元件模式作為Android系統的核心應用程式。

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

3.2.3.2.意圖覆蓋

由於 Android 是一個可擴展平台，裝置實現者必須允許第 3.2.3.1 節中引用的每個 Intent 模式被第三方應用程式覆蓋。上游Android開源專案預設允許這樣做；設備實作者不得為系統應用程式使用這些 Intent 模式附加特殊權限，或阻止第三方應用程式綁定到這些模式並承擔對這些模式的控制。該禁止具體包括但不限於停用「選擇器」使用者介面，該介面允許使用者在全部處理相同意圖模式的多個應用程式之間進行選擇。

3.2.3.3.意圖命名空間

裝置實現者不得包含任何使用 ACTION、CATEGORY 或 android.* 命名空間中的其他鍵字串來支援任何新意圖或廣播意圖模式的 Android 元件。裝置實現者不得包含任何使用 ACTION、CATEGORY 或屬於另一個組織的包空間中的其他鍵字串來遵循任何新 Intent 或廣播 Intent 模式的 Android 元件。設備實現者不得更改或擴展第 3.2.3.1 節中列出的核心應用程式所使用的任何 Intent 模式。

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

3.2.3.4.廣播意圖

第三方應用程式依靠平台廣播某些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.網路相容性

許多開發人員和應用程式的使用者介面都依賴android.webkit.WebView類別 [參考資料, 8 ] 的行為，因此 WebView 實作必須在 Android 實作之間相容。同樣，完整的網路體驗是 Android 用戶體驗的核心。裝置實作必須包含與上游 Android 軟體一致的android.webkit.WebView版本，並且必須包含支援現代 HTML5 的瀏覽器，如下所述。

3.4.1.網頁視圖相容性

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

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

WebView 配置必須包括對 HTML5 資料庫、應用程式快取和地理定位 API 的支援 [參考資料，9 ]。 WebView 必須包含對 HTML5 <video>標籤的支援。 HTML5 API 與所有 JavaScript API 一樣，必須在 WebView 中預設為停用，除非開發人員透過常用的 Android API 明確啟用它們。

3.4.2.瀏覽器相容性

設備實作必須包括用於一般使用者 Web 瀏覽的獨立瀏覽器應用程式。獨立瀏覽器可以基於 WebKit 以外的瀏覽器技術。然而，即使發布了替代瀏覽器應用程序，提供給第三方應用程式的android.webkit.WebView元件也必須基於 WebKit，如第 3.4.1 節中所述。

實作可以在獨立的瀏覽器應用程式中提供自訂使用者代理字串。

獨立的瀏覽器應用程式（無論是基於上游 WebKit 瀏覽器應用程式還是第三方替代品）應該盡可能支援 HTML5 [參考資料，9 ]。至少，裝置實作必須支援 HTML5 地理定位、應用程式快取、資料庫 API 以及獨立瀏覽器應用程式中的 <video> 標記。

3.5. API 行為相容性

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

  • 設備不得更改標準 Intent 的行為或意義
  • 設備不得更改特定類型系統元件（例如服務、活動、ContentProvider 等）的生命週期或生命週期語意
  • 設備不得更改特定權限的語意

上面的列表並不全面，設備實現者有責任確保行為相容性。因此，裝置實現者應該盡可能使用透過 Android 開源專案提供的原始程式碼，而不是重新實作系統的重要部分。

相容性測試套件 (CTS) 測試平台的重要部分（但不是全部）的行為相容性。實作者有責任確保與 Android 開源專案的行為相容性。

3.6. API命名空間

Android 遵循 Java 程式語言定義的套件和類別命名空間約定。為了確保與第三方應用程式的相容性，裝置實作者不得對這些套件命名空間進行任何禁止的修改（見下文）：

  • java.*
  • javax.*
  • 太陽。*
  • 安卓。*
  • com.android.*

禁止的修改包括：

  • 裝置實作不得透過更改任何方法或類別簽名，或刪除類別或類別欄位來修改 Android 平台上公開的 API。
  • 設備實作者可以修改 API 的底層實現，但此類修改不得影響任何公開暴露的 API 的規定行為和 Java 語言簽章。
  • 設備實作者不得為上述 API 新增任何公開暴露的元素（例如類別或接口，或現有類別或介面的欄位或方法）。

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

設備實作者可以新增自訂 API，但任何此類 API 不得位於另一個組織擁有或引用另一個組織的命名空間中。例如，裝置實作者不得將 API 新增至 com.google.* 或類似的命名空間；只有谷歌可以這樣做。同樣，Google 不得將 API 新增至其他公司的命名空間。

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

請注意，上述限制對應於 Java 程式語言中命名 API 的標準約定；本節的目的只是為了加強這些約定，並透過將其納入此相容性定義來使其具有約束力。

3.7.虛擬機器相容性

裝置實作必須支援完整的 Dalvik 執行檔 (DEX) 字節碼規格和 Dalvik 虛擬機器語意 [參考資料, 10 ]。

螢幕分類為中密度或低密度的裝置實作必須配置 Dalvik 為每個應用程式分配至少 16MB 記憶體。螢幕分類為高密度的裝置實作必須配置 Dalvik 為每個應用程式分配至少 24MB 記憶體。請注意，設備實作可能會分配比這些數字更多的記憶體。

3.8.使用者介面相容性

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

3.8.1.小部件

Android 定義了元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開「AppWidget」[參考資料，11 ]。 Android 開源參考版本包括一個 Launcher 應用程序，其中包含使用者介面元素，允許使用者在主畫面上新增、檢視和刪除 AppWidget。

設備實施者可以取代參考啟動器（即主螢幕）。替代啟動器應該包括對 AppWidget 的內建支持，並公開使用者介面元素以直接在啟動器內新增、配置、檢視和刪除 AppWidget。替代啟動器可以省略這些使用者介面元素；然而，如果它們被省略，設備實現者必須提供一個可從啟動器訪問的單獨應用程序，允許用戶添加、配置、查看和刪除 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 或電池電量，或以不可接受的低幀速率運行，則該硬體被視為無法運行動態壁紙。例如，某些動態桌布可能會使用 OpenGL 1.0 或 2.0 上下文來渲染其內容。動態桌布將無法在不支援多個 OpenGL 上下文的硬體上可靠地運行，因為使用 OpenGL 上下文的動態桌布可能會與也使用 OpenGL 上下文的其他應用程式發生衝突。

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

4. 參考軟體相容性

設備實作者必須使用以下開源應用程式測試實現相容性：

  • 計算器（包含在 SDK 中）
  • 月球著陸器（包含在 SDK 中）
  • 「Apps for Android」應用程式 [參考資料，18 ]。
  • 複製島（在 Android 市場中提供；僅支援 OpenGL ES 2.0 的裝置實作需求）

上述每個應用程式必須啟動並在實作上正確運行，以便實現被認為是相容的。

此外，裝置實作必須測試每個冒煙測試應用程式的每個選單項目（包括所有子選單）：

  • ApiDemos（包含在 SDK 中）
  • 手動煙霧測試（包含在 CTS 中）

上述應用程式中的每個測試案例必須在設備實作上正確運行。

5. 應用程式封裝相容性

裝置實作必須安裝並運行由官方 Android SDK 中包含的「aapt」工具產生的 Android「.apk」檔案 [參考資料，19 ]。

裝置實作不得擴充 .apk [ Resources, 20 ]、Android Manifest [ Resources, 21 ] 或 Dalvik 位元組碼 [ Resources, 10 ] 格式，以免阻止這些檔案在其他相容裝置上正確安裝和運作。設備實作者應該使用 Dalvik 的參考上游實作以及參考實作的套件管理系統。

6. 多媒體相容性

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

6.1.媒體編解碼器

設備實作必須支援以下多媒體編解碼器。所有這些編解碼器均作為 Android 開源專案的首選 Android 實作中的軟體實作提供。

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

聲音的
姓名編碼器解碼器細節文件/容器格式
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 8kHz 時取樣率為 4.75 至 12.2 kbps 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 和 Mobile XMF。支援鈴聲格式 RTTTL/RTX、OTA 和 iMelody輸入 0 和 1（.mid、.xmf、.mxmf）。還有 RTTTL/RTX（.rtttl、.rtx）、OTA（.ota）和 iMelody（.imy）
奧格·沃爾比斯X奧格 (.ogg)
相變材料X 8 位元和 16 位元線性 PCM（速率達到硬體限制）波形 (.wav)
影像
JPEG X X基礎+漸進
動圖X
巴布亞紐幾內亞X X
骨形態發生蛋白X
影片
H.263 X X 3GPP (.3gp) 文件
H.264 X 3GPP (.3gp) 和 MPEG-4 (.mp4) 文件
MPEG4 簡單設定檔X 3GPP (.3gp) 文件

請注意，上表並未列出大多數視訊編解碼器的特定位元率要求。原因在於，在實務上，目前的裝置硬體不一定支援與相關標準指定的所需位元率精確映射的位元率。相反，設備實現應該支援硬體上實際的最高位元率，最高可達規範定義的限制。

6.2.聲音錄製

當應用程式使用android.media.AudioRecord API 開始錄製音訊串流時，裝置實作應該使用以下每種行為來取樣和錄製音訊：

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

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

6.3.音訊延遲

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

就本節而言：

  • 「冷輸出延遲」定義為應用程式請求音訊播放與聲音開始播放之間的時間間隔，此時音訊系統在請求之前已空閒並斷電
  • 「熱輸出延遲」定義為應用程式請求音訊播放與聲音開始播放之間的時間間隔，此時音訊系統最近已被使用但目前處於空閒狀態（即靜音）
  • 「連續輸出延遲」定義為裝置目前正在播放音訊時應用程式發出要播放的樣本與揚聲器實際播放對應聲音之間的時間間隔
  • 「冷輸入延遲」定義為應用程式請求音訊錄製與透過回呼將第一個樣本傳遞給應用程式之間的時間間隔，此時音訊系統和麥克風在請求之前已空閒並斷電
  • 「連續輸入延遲」定義為當裝置處於錄音模式時，發生環境聲音以及與該聲音對應的樣本透過其回調傳遞到錄音應用程式時

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

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

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

7. 開發者工具相容性

裝置實作必須支援 Android SDK 中提供的 Android 開發人員工具。具體來說，Android 相容設備必須相容：

  • Android 調試橋（稱為 adb） [資源，19 ]
    裝置實作必須支援 Android SDK 中記錄的所有adb函數。預設情況下，裝置端adb守護程式應該處於非活動狀態，但必須有一個使用者可存取的機制來開啟 Android 偵錯橋。
  • Dalvik 調試監視器服務（稱為 ddms） [資源，19 ]
    裝置實作必須支援 Android SDK 中記錄的所有ddms功能。由於ddms使用adb ，因此預設對ddms的支援應該處於非活動狀態，但每當用戶啟動 Android 偵錯橋時就必須支持，如上所述。
  • 猴子[資源，22 ]
    裝置實作必須包含 Monkey 框架，並使其可供應用程式使用。

8. 硬體相容性

Android 旨在支援裝置實施者創建創新的外形尺寸和配置。同時，Android 開發人員期望所有 Android 裝置都能使用某些硬體、感測器和 API。本節列出了所有 Android 2.2 相容裝置必須支援的硬體功能。

如果裝置包含具有供第三方開發人員使用的相應 API 的特定硬體元件，則裝置實作必須實作 Android SDK 文件中定義的 API。如果 SDK 中的 API 與指定為可選的硬體元件交互，且裝置實作不擁有該元件：

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

應用這些要求的場景的典型範例是電話 API：即使在非電話設備上，這些 API 也必須以合理的無操作方式實作。

設備實作必須透過android.content.pm.PackageManager類別上的getSystemAvailableFeatures()和hasSystemFeature(String)方法準確地報告準確的硬體配置資訊。 [資源，23 ]

8.1.展示

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

對於 Android 2.2，以下是最常見的顯示配置：

螢幕類型寬度（像素）高度（像素）對角線長度範圍（英吋）螢幕尺寸組螢幕密度組
QVGA 240 320 2.6 - 3.0小的低的
WQVGA 240 400 3.2 - 3.5普通的低的
FWQVGA 240第432章3.5 - 3.8普通的低的
HVGA 320第480章3.0 - 3.5普通的中等的
寬VGA第480章800 3.3 - 4.0普通的高的
FWVGA第480章第854章3.5 - 4.0普通的高的
寬VGA第480章800 4.8 - 5.5大的中等的
FWVGA第480章第854章5.0 - 5.8大的中等的

與上述標準配置之一相對應的裝置實作必須配置為透過android.content.res.Configuration [ Resources, 24 ] 類別向應用程式報告指示的螢幕尺寸。

某些 .apk 套件的清單並未將其標識為支援特定的密度範圍。運行此類應用程式時，存在以下限制：

  • 設備實作必須將 .apk 中缺少密度限定符的資源解釋為預設為「medium」（在 SDK 文件中稱為「mdpi」）。
  • 在「低」密度螢幕上操作時，裝置實作必須將中/mdpi 資源縮小 0.75 倍。
  • 在「高」密度螢幕上操作時，裝置實作必須將中等/mdpi 資源擴展至 1.5 倍。
  • 設備實現不得在密度範圍內縮放資產，而必須在密度範圍之間精確地按這些因素縮放資產。

8.1.2.非標準顯示配置

與第 8.1.1 節中列出的標準配置之一不符的顯示配置需要額外的考慮和工作才能相容。裝置實現者必須按照第 13 節中所述聯繫 Android 相容性團隊，以獲得螢幕尺寸桶、密度和縮放因子的分類。當提供此資訊時，設備實作必須按照指定的方式實現它們。

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

8.1.3.顯示指標

裝置實作必須報告android.util.DisplayMetrics [參考資料，26 ] 中定義的所有顯示指標的正確值。

8.1.4.聲明的螢幕支持

應用程式可以透過 AndroidManifest.xml 檔案中的<supports-screens>屬性指示它們支援的螢幕尺寸。裝置實作必須正確遵循應用程式聲明的對小、中和大螢幕的支持，如 Android SDK 文件中所述。

8.2.鍵盤

設備實現：

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

8.3.非觸控式導航

設備實現：

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

8.4.螢幕方向

相容設備必須支援應用程式動態定向為縱向或橫向螢幕方向。也就是說，設備必須尊重應用程式對特定螢幕方向的請求。設備實作可以選擇縱向或橫向作為預設方向。

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

8.5。觸控螢幕輸入

設備實現：

  • 必須有觸控螢幕
  • 可能有電容式或電阻式觸控螢幕
  • 必須報告android.content.res.Configuration [ Resources, 25 ] 的值，反映與裝置上特定觸控螢幕的類型相對應的值
  • 如果觸控螢幕支援多個指針，則應支援完全獨立追蹤的指針

8.6。 USB

設備實現：

  • 必須實現 USB 用戶端，可透過標準 USB-A 連接埠連接到 USB 主機
  • 必須透過 USB 實現 Android 調試橋（如第 7 節所述）
  • 必須實現 USB 大容量儲存規範，以允許連接到裝置的主機存取 /sdcard 磁碟區的內容
  • 應在裝置端使用 micro USB 外型規格
  • 可以在裝置端包含非標準端口，但如果是這樣，則必須附帶能夠將自訂引腳分配連接到標準 USB-A 連接埠的電纜
  • 應實現對 USB 大容量儲存規格的支援（以便可以從主機 PC 存取裝置上的可移動或固定儲存）

8.7.導航鍵

主頁、選單和返回功能對於 Android 導航範例至關重要。設備實作必須使這些功能始終可供使用者使用，無論應用程式狀態如何。這些功能應該透過專用按鈕來實現。它們可以使用軟體、手勢、觸控面板等來實現，但如果是這樣，它們必須始終可訪問，並且不會遮擋或乾擾可用的應用程式顯示區域。

設備實現者也應該提供專用的搜尋鍵。設備實施者還可以提供電話通話的發送和結束鍵。

8.8.無線數據網路

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

如果裝置實作包含 Android SDK 包含 API 的特定模式（即 WiFi、GSM 或 CDMA），則實作必須支援該 API。

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

8.9。相機

設備實現必須包括後置攝像頭。附帶的後置相機：

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

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

  1. 如果應用程式從未呼叫過 android.hardware.Camera.Parameters.setPreviewFormat(int)，則裝置必須使用 android.hardware.PixelFormat.YCbCr_420_SP 來提供給應用程式回呼的預覽資料。
  2. 如果應用程式註冊了 android.hardware.Camera.PreviewCallback 實例，且當預覽格式為 YCbCr_420_SP 時系統呼叫 onPreviewFrame() 方法，則傳入 onPreviewFrame() 的 byte[] 中的資料也必須是 NV21 編碼格式。 （這是 7k 硬體系列本身使用的格式。）也就是說，NV21 必須是預設格式。

裝置實作必須實作 Android 2.2 SDK 文件中包含的完整相機 API [參考資料，27 ]），無論裝置是否包含硬體自動對焦或其他功能。例如，缺乏自動對焦的相機仍然必須呼叫任何已註冊的android.hardware.Camera.AutoFocusCallback實例（即使這與非自動對焦相機無關。）

如果底層硬體支援該功能，則裝置實作必須識別並遵循android.hardware.Camera.Parameters類別上定義為常數的每個參數名稱。如果設備硬體不支援某項功能，則 API 的行為必須依照文件記錄。相反，裝置實作不得尊重或識別傳遞給android.hardware.Camera.setParameters()方法的字串常數，除了在android.hardware.Camera.Parameters上記錄為常數的字串常數。也就是說，如果硬體允許，設備實作必須支援所有標準相機參數，並且不得支援自訂相機參數類型。

設備實現可能包括前置鏡頭。但是，如果裝置實作包含前置鏡頭，則裝置上實作的相機 API 預設不得使用前置鏡頭。也就是說，Android 2.2 中的相機 API 僅適用於後置鏡頭，裝置實作不得重複使用或重載 API 來作用於前置相機（如果存在）。請注意，裝置實現者新增的任何支援前置攝影機的自訂 API 必須遵守第 3.5 和 3.6 節；例如，如果提供自訂android.hardware.Camera或Camera.Parameters子類別來支援前置鏡頭，則它不得位於現有命名空間中，如第 3.5 節和第 3.6 節所述。請注意，包含前置鏡頭並不符合設備包含後置相機的要求。

8.10。加速度計

設備實作必須包含 3 軸加速計，並且必須能夠以 50 Hz 或更高頻率傳送事件。加速度計所使用的座標系必須符合 Android API 中詳細說明的 Android 感測器座標系（請參閱 [參考資料，28 ]）。

8.11。羅盤

設備實作必須包含 3 軸羅盤，並且必須能夠以 10 Hz 或更高頻率傳送事件。指南針所使用的座標系必須符合 Android API 中定義的 Android 感測器座標系（請參閱 [參考資料，28 ]）。

8.12.全球定位系統

設備實作必須包括 GPS 接收器，並且應該包括某種形式的「輔助 GPS」技術，以最大限度地減少 GPS 鎖定時間。

8.13。電話

Android 2.2 可在不含電話硬體的裝置上使用。也就是說，Android 2.2 相容於手機以外的裝置。但是，如果設備實作確實包含 GSM 或 CDMA 電話，則它必須實現對該技術的 API 的完全支援。不包含電話硬體的設備實作必須將完整的 API 實作為無操作。

另請參閱第 8.8 節「無線資料網路」。

8.14。記憶體和儲存

裝置實作必須至少有 92MB 的記憶體可供核心和使用者空間使用。 92MB 必須是除任何專用於硬體組件（例如無線電、記憶體等不受核心控制的記憶體）之外的記憶體。

設備實作必須具有至少 150MB 的非揮發性儲存空間可用於使用者資料。也就是說， /data分區必須至少為150MB。

除了上述要求之外，設備實作還應至少有128MB的記憶體可用於核心和用戶空間，此外，任何專用於不在核心控制下的硬體元件的記憶體之外。設備實作至少應具有可用於用戶資料的1GB非揮發性儲存。請注意，計劃在未來版本的Android中將這些更高的要求成為艱苦的最低要求。強烈鼓勵設備實現現在滿足這些要求，否則它們可能沒有資格獲得未來版本的Android的兼容性。

8.15。應用程式共享儲存

設備實作必須為應用程式提供共享儲存。提供的共享儲存必須至少為2GB。

必須使用預設安裝的「開箱即用」安裝的共用儲存配置設備實作。如果共用儲存未安裝在Linux路徑/sdcard上，則該裝置必須包含從/sdcard到實際安裝點的Linux符號連結。

裝置實作必須依照記錄的android.permission.WRITE_EXTERNAL_STORAGE在此共用儲存中執行。共享儲存否則必須透過獲得該許可的任何應用程式可寫入。

設備實現可能具有用於用戶可存取的可移動儲存的硬件，例如安全的數位卡。另外，裝置實作可以將內部（不可拆卸）儲存空間分配為應用程式的共用儲存。

不管使用的共享存儲的形式如何，共享存儲都必須實現USB質量存儲，如第8.6節所述。當運箱即可到達時，必須將共用儲存安裝在脂肪檔案系統中。

考慮兩個常見的例子是說明的。如果裝置實作包含符合共享儲存需求的SD卡插槽，則必須將脂肪形式的SD卡2GB尺寸或更大的尺寸包含在裝置上，作為出售給用戶，並且預設必須安裝。另外，如果設備實現使用內部固定存儲來滿足此要求，則該存儲的尺寸或更大，格式為fat，並安裝在/sdcard /sdcard （如果是物理位置，則必須是符合物理位置的符號鏈接安裝在其他地方。）

裝置實作包括多個共用儲存路徑（例如SD卡插槽和共用內部儲存）應修改核心應用程序，例如媒體掃描器和ContentProvider，以透明地支援放置在兩個位置的檔案。

8.16。藍牙

設備實作必須包括藍牙收發器。裝置實作必須如SDK文件[資源，30 ]中所述啟用基於RFCOMM的藍牙API。設備實現應實現相關的藍牙配置文件，例如A2DP，AVRCP，OBEX等。

相容性測試套件包括涵蓋Android RFCOMM藍牙API的基本操作的案例。但是，由於藍牙是設備之間的通訊協議，因此無法透過在單一裝置上執行的單元測試對其進行全面測試。因此，設備實作也必須通過附錄A中所述的人類驅動藍牙測試程序。

9.效能相容性

Android相容性計劃的目標之一是為消費者提供一致的應用程式經驗。相容的實作不僅必須確保應用程式在裝置上正確運行，而且還必須以合理的效能和整體良好的使用者體驗來確保應用程式的運作。裝置實作必須符合下表中定義的Android 2.2相容裝置的關鍵效能指標：

公制效能閾值評論
申請發射時間以下應用程式應在指定的時間內啟動。
  • 瀏覽器：小於1300ms
  • MMS/SMS：小於700ms
  • 警報路線：小於650ms
啟動時間衡量是完成應用程式的預設活動的總時間，包括啟動Linux進程，將Android軟體包載入到Dalvik VM中所需的時間，然後致電onCreate。
同時應用啟動了多個應用程式後，啟動後重新發布已經運行的應用程式必須小於原始啟動時間。

10.安全模型相容性

設備實作必須實現與Android開發人員文件中API [ Resources，29 ]中的安全性和權限參考文獻文件中定義的Android平台安全模型一致的安全模型。設備實作必須支援安裝自簽署的應用程序，而無需任何第三方/當局的任何其他權限/憑證。具體而言，相容的設備必須支援以下小節中所述的安全機制。

10.1.權限

設備實作必須支援Android開發人員文件[資源，29 ]中定義的Android權限模型。具體而言，實施必須執行按照SDK文件中所述的每個許可；無法省略，更改或忽略權限。如果新的權限ID字串不在Android中。*名稱空間，則實作可能會增加其他權限。

10.2. UID 和進程隔離

設備實作必須支援Android應用程式沙盒模型，在該模型中，每個應用程式都以唯一的UNIX式UID和單獨的流程運行。設備實作必須支援執行多個應用程式作為相同的Linux使用者ID，前提是在安全性和權限參考中定義的應用程式是正確簽署和建構的[ Resources，29 ]。

10.3.檔案系統權限

設備實作必須支援Android檔案存取權限模型，如「安全性和權限參考」 [ Resources，29 ]中定義的定義。

10.4.備用執行環境

設備實作可能包括使用其他軟體或技術執行應用程式的執行時間環境，而不是Dalvik虛擬機器或本機程式碼。但是，此類替代執行環境不得妥協，如本節所述，因此安裝了Android應用程式的安全模型或已安裝的Android應用程式的安全性。

替代運行時間本身必須是Android應用程序，並遵守標準的Android安全模型，如第10節中其他地方所述。

不得授予替代運行時間存取由運行時的<uses-permission>檔案中未要求的權限保護的資源的存取權限。

替代運行時間不得允許應用程式使用受系統應用程式限制的Android權限保護的功能。

替代運行時必須遵守Android沙盒模型。具體來說：

  • 替代運行時間應透過PackageManager安裝應用程序，然後將其安裝到單獨的Android沙箱中（即Linux用戶ID等）
  • 替代運行時可能會使用替代運行時提供所有應用程式共享的單一Android沙箱。
  • 使用替代運行時的替代運行時間和安裝應用程式不得重複使用裝置上安裝的任何其他應用程式的沙箱，除非透過共用使用者ID的標準Android機制和簽章證書
  • 替代運行時間不得與其他Android應用程式相對應的沙箱啟動，授予或授予存取權限。

不得啟動，授予，授予，授予或授予替代運行時間，向其他應用程式（root）或任何其他使用者ID的任何特權。

備用運行時間的.APK檔案可能包含在裝置實現的系統影像中，但必須以與簽署裝置實作中包含的其他應用程式的金鑰簽署。

安裝應用程式時，替代運行時間必須獲得應用程式使用的Android權限的用戶同意。也就是說，如果應用程式需要使用相應的Android許可（例如相機，GPS等）的裝置資源，則替代運行時必須通知用戶該應用程式能夠存取該資源。如果運行時環境未以這種方式記錄應用程式功能，則運行時環境必須在使用該運行時安裝任何應用程式時列出運行時本身持有的所有權限。

11.相容性測試套件

設備實作必須透過設備上的最終運輸軟體透過Android開源專案可從Android開源專案中獲得Android相容性測試套件（CTS）[ 2 ]。此外，設備實施者應盡可能使用Android開源樹中的參考實現，並且必須確保在CTS含糊不清以及參考原始碼部分的任何重新實現的情況下相容。

CTS設計為在實際設備上運作。像任何軟體一樣，CTS本身可能包含錯誤。 CTS將與此相容性定義獨立於版本，並且可以為Android 2.2發布CTS的多個修訂版。設備實作必須傳遞設備軟體完成時可用的最新CTS版本。

12.可更新軟體

設備實現必須包括替換整個系統軟體的機制。該機構不必執行「即時」升級 - 也就是說，可能需要重新啟動設備。

只要可以替換設備上預先安裝的整個軟體，就可以使用任何方法。例如，以下任何方法都可以滿足此要求：

  • 透過重新啟動的離線更新的直播（OTA）下載
  • 主機PC上USB上的「束縛」更新
  • 「離線」透過重新啟動進行更新，並在可移動儲存空間上的檔案中更新

所使用的更新機制必須支援更新，而無需擦除使用者資料。請注意，上游Android軟體包括滿足此要求的更新機制。

如果在發布後在設備實現中發現錯誤，但在其合理的產品壽命內與Android兼容性團隊協商確定以影響派對應用程序的兼容性，則設備實現者必須通過軟體糾正錯誤可根據剛才描述的機制應用的更新。

13. 聯絡我們

您可以透過compatibility@android.com與文件作者聯繫以進行澄清，並提出您認為該文件不涵蓋的任何問題。

附錄 A - 藍牙測試程序

相容性測試套件包括涵蓋Android RFCOMM藍牙API的基本操作的案例。但是，由於藍牙是設備之間的通訊協議，因此無法透過在單一裝置上執行的單元測試對其進行全面測試。因此，設備實作還必須通過以下所述的人類驅動藍牙測試程序。

測試過程基於Android開源專案樹中包含的藍牙範例應用程式。該過程需要兩個設備：

  • 運行要測試的軟體建構的候選設備實現
  • 已知已知的單獨的設備實現是相容的，以及正在測試的設備實現的模型 - 即，“已知的良好”設備實現

以下測試程序分別將這些設備分別稱為「候選」和「已知良好」設備。

設定和安裝

  1. 從Android原始碼樹中建構BluetoothChat.apk通過「製作樣品」。
  2. 在已知的良好設備上安裝bluetoothchat.apk。
  3. 在候選設備上安裝bluetoothchat.apk。

透過應用程式測試藍牙控制

  1. 在停用藍牙時，請在候選裝置上啟動藍牙。
  2. 驗證候選裝置是否開啟藍牙，或透過對話方塊提示使用者開啟藍牙。

測驗配對和交流

  1. 在兩個裝置上啟動藍牙聊天應用程式。
  2. 使已知的良好設備可以從藍牙奇蹟（使用選單）內發現。
  3. 在候選裝置上，從藍牙內部掃描藍牙裝置（使用選單），然後與已知的好裝置配對。
  4. 從每個裝置發送10條或更多訊息，並驗證其他裝置是否正確接收它們。
  5. 透過按回家，在兩個裝置上關閉兩個裝置上的藍牙應用程式。
  6. 使用設備設定應用程序，從另一個設備上取消每個設備。

在反向方向上測試配對和通信

  1. 在兩個裝置上啟動藍牙聊天應用程式。
  2. 使候選設備可從藍牙奇蹟（使用選單）內發現。
  3. 在已知的良好裝置上，從藍牙內部掃描藍牙裝置（使用選單），然後與候選裝置配對。
  4. 從每個設備發送10個或訊息，並驗證其他設備是否正確接收它們。
  5. 透過反覆向後重新啟動發射器，關閉兩個裝置上的藍牙聊天應用程式。

測試重新發布

  1. 在兩個裝置上重新啟動藍牙聊天應用程式。
  2. 從每個設備發送10個或訊息，並驗證其他設備是否正確接收它們。

注意：以上測試的某些情況透過使用家中的一些情況結束了測試部分，有些則使用背部。這些測試不是多餘的，也不是可選的：目的是在明確終止活動時（透過使用者按下來呼叫（）），並隱含地發送到後台（透過使用者按回家。）每個測試順序必須如上所述執行。