自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。

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

Android 2.3 相容性定義

1. 簡介

本文件列舉了手機必須符合的條件，才能與 Android 2.3 相容。

使用「必須」、「不得」、「必要」、「應」、「應當」、「不得」、「應」、「不得」、「建議」、「可」和「選用」等詞彙，是根據 RFC2119 中定義的 IETF 標準 [資源, 1]。

在本文件中，「裝置實作者」或「實作者」是指開發搭載 Android 2.3 的硬體/軟體解決方案的個人或機構。「裝置實作」或「實作」是指所開發的硬體/軟體解決方案。

裝置實作必須符合本相容性定義中列出的要求，包括透過參考納入的任何文件，才能視為與 Android 2.3 相容。

如果這個定義或第 10 節所述的軟體測試未明確說明或不完整，則裝置導入者有責任確保與現有導入作業的相容性。因此，Android 開放原始碼計畫 [Resources, 3] 是 Android 的參考和偏好實作項目。強烈建議裝置實作者盡可能以「上游」原始碼為基礎，從 Android 開放原始碼計畫取得原始碼。雖然部分元件理論上可由其他實作項目取代，但我們強烈建議您不要這麼做，因為通過軟體測試的難度會大幅提高。實作者有責任確保與標準 Android 實作項目的行為完全相容，包括 Compatibility Test Suite 和其他項目。最後，請注意，本文件明文禁止某些元件替換和修改作業。

請注意，這份相容性定義是為了配合 Android 2.3.3 更新 (API 級別 10) 而發布。此定義會取代 Android 2.3 以下版本 (2.3.3 除外) 的相容性定義，並取代這些定義。(也就是說，2.3.1 和 2.3.2 版本已淘汰)。未來搭載 Android 2.3 的 Android 相容裝置，必須搭載 2.3.3 以上版本。

2. 資源

IETF RFC2119 需求等級：http://www.ietf.org/rfc/rfc2119.txt

Android 相容性計畫簡介：http://source.android.com/docs/compatibility/index.html

Android 開放原始碼計畫：http://source.android.com/

API 定義和說明文件：http://developer.android.com/reference/packages.html

Android 權限參考資料：http://developer.android.com/reference/android/Manifest.permission.html

android.os.Build 參考資料：http://developer.android.com/reference/android/os/Build.html

Android 2.3 允許使用的版本字串：http://source.android.com/docs/compatibility/2.3/versions.html

android.webkit.WebView 類別：http://developer.android.com/reference/android/webkit/WebView.html

HTML5：http://www.whatwg.org/specs/web-apps/current-work/multipage/

HTML5 離線功能：http://dev.w3.org/html5/spec/Overview.html#offline

HTML5 影片標記：http://dev.w3.org/html5/spec/Overview.html#video

HTML5/W3C 地理位置 API：http://www.w3.org/TR/geolocation-API/

HTML5/W3C 網路資料庫 API：http://www.w3.org/TR/webdatabase/

HTML5/W3C IndexedDB API：http://www.w3.org/TR/IndexedDB/

Dalvik 虛擬機器規格：可在 Android 原始碼的 dalvik/docs 中找到

AppWidget：http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

通知：http://developer.android.com/guide/topics/ui/notifiers/notifications.html

應用程式資源：http://code.google.com/android/reference/available-resources.html

狀態列圖示樣式指南：http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure

搜尋管理工具：http://developer.android.com/reference/android/app/SearchManager.html

Toast：http://developer.android.com/reference/android/widget/Toast.html

動態桌布：https://android-developers.googleblog.com/2010/02/live-wallpapers.html

參考工具說明文件 (適用於 ADB、AAPT、DDMS)：http://developer.android.com/guide/developing/tools/index.html

Android 應用程式檔案說明：http://developer.android.com/guide/topics/fundamentals.html

資訊清單檔案：http://developer.android.com/guide/topics/manifest/manifest-intro.html

Monkey 測試工具：https://developer.android.com/studio/test/other-testing-tools/monkey

Android 硬體功能清單：http://developer.android.com/reference/android/content/pm/PackageManager.html

支援多螢幕：http://developer.android.com/guide/practices/screens_support.html

android.util.DisplayMetrics：http://developer.android.com/reference/android/util/DisplayMetrics.html

android.content.res.Configuration：http://developer.android.com/reference/android/content/res/Configuration.html

感應器座標空間：http://developer.android.com/reference/android/hardware/SensorEvent.html

Bluetooth API：http://developer.android.com/reference/android/bluetooth/package-summary.html

NDEF 推送通訊協定：http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

MIFARE MF1S503X：http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

MIFARE MF1S703X：http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

MIFARE MF0ICU1：http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf

MIFARE MF0ICU2：http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf

MIFARE AN130511：http://www.nxp.com/documents/application_note/AN130511.pdf

MIFARE AN130411：http://www.nxp.com/documents/application_note/AN130411.pdf

相機方向 API：http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

android.hardware.Camera：http://developer.android.com/reference/android/hardware/Camera.html

Android 安全性和權限參考資料：http://developer.android.com/guide/topics/security/security.html

Android 版應用程式：http://code.google.com/p/apps-for-android

這些資源多半是直接或間接從 Android 2.3 SDK 衍生而來，功能上與該 SDK 說明文件中的資訊相同。無論何時，如果此相容性定義或相容性測試套件與 SDK 說明文件不一致，SDK 說明文件都會視為權威來源。上述參考資料中提供的任何技術細節，都會視為本相容性定義的一部分。

3. 軟體

Android 平台包含一組受管理的 API、一組原生 API，以及一組所謂的「軟體」API，例如 Intent 系統和網路應用程式 API。本節將詳細說明與相容性密切相關的硬式和軟式 API，以及其他相關技術和使用者介面行為。裝置實作項目必須遵守本節中的所有規定。

3.1. 代管 API 相容性

代管 (以 Dalvik 為基礎) 執行環境是 Android 應用程式的主要載具。Android 應用程式設計介面 (API) 是指向在受管理的 VM 環境中執行的應用程式公開的 Android 平台介面組合。裝置實作項目必須提供完整實作項目，包括所有已記錄行為，以及 Android 2.3 SDK 公開的任何已記錄 API [Resources, 4]。

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

這個相容性定義允許某些類型的硬體，讓裝置實作項目略過 Android 所附帶的 API。在這種情況下，API 必須仍會出現，並以合理的方式運作。如要瞭解此情境的具體規定，請參閱第 7 節。

3.2. 軟性 API 相容性

除了第 3.1 節所述的受管理 API 外，Android 也包含了重要的「軟性」API，也就是在執行階段時的「軟性」API，例如 Intent、權限，以及無法在應用程式編譯期間強制執行的 Android 應用程式類似層面。本節將詳細說明與 Android 2.3 相容所需的「軟性」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.3，這個欄位必須包含整數值 9。
android.os.Build.VERSION.INCREMENTAL	裝置實作者選擇的值，用於指定目前執行中 Android 系統的特定版本，並以人類可讀的格式呈現。這個值絕對不可用於向使用者提供的不同版本。這個欄位的常見用途是指出系統用來產生建構項目的建構編號或來源控管變更 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
android.os.Build.BOARD	裝置實作者選擇的值，用來識別裝置使用的特定內部硬體，格式為人類可讀。這個欄位的可能用途是指出為裝置供電的板子特定修訂版本。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.BRAND	裝置實作者選擇的值，用於以人類可讀的格式，標示出裝置製造商的公司、機構、個人等名稱。這個欄位的可能用途是指出販售裝置的原始設備製造商和/或電信業者。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.DEVICE	裝置實作者選擇的值，用於識別裝置主體 (有時稱為「工業設計」) 的特定設定或修訂版本。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.FINGERPRINT	用於唯一識別此版本的字串。應以人類可讀的方式呈現。必須遵循以下範本： `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` 例如： `acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys` 指紋不得包含空白字元。如果上述範本中包含其他含有空白字元的欄位，則必須在版本指紋中以其他字元取代，例如底線字元 ("_")。這個欄位的值必須能以 7 位元 ASCII 編碼。
android.os.Build.HOST	以人類可讀格式，提供可明確識別建構所在主機的字串。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
android.os.Build.ID	裝置實作者選擇的 ID，用於參照特定版本，並以人類可讀的格式呈現。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但應為使用者區分軟體版本時可充分利用的值。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.MODEL	裝置實作者選擇的值，其中包含使用者所知的裝置名稱。這應與向終端使用者行銷和銷售裝置時使用的名稱相同。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。
android.os.Build.PRODUCT	裝置實作者選擇的值，其中包含裝置的開發名稱或代碼名稱。必須是人類可讀的形式，但不一定是供使用者查看。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.TAGS	裝置實作者選擇的標記清單，以半形逗號分隔，可進一步區分版本。例如「unsigned,debug」。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.TIME	代表建構作業發生時間的時間戳記值。
android.os.Build.TYPE	裝置實作者選擇的值，可指定建構作業的執行階段設定。這個欄位應包含下列三種常見 Android 執行階段設定的其中一個值：「user」、「userdebug」或「eng」。這個欄位的值必須能以 7 位元 ASCII 編碼，且符合規則運算式 `"^[a-zA-Z0-9.,_-]+$"`。
android.os.Build.USER	產生版本的使用者 (或自動化使用者) 的名稱或使用者 ID。這個欄位沒有特定格式規定，但不得為空值或空字串 ("")。

3.2.3. 意圖相容性

Android 會使用意圖，在應用程式之間實現鬆散整合。本節說明與意圖模式相關的規定，裝置實作必須遵守這些規定。「遵循」是指裝置實作者必須提供 Android 活動或服務，指定相符的意圖篩選器，並為每個指定的意圖模式繫結及實作正確的行為。

3.2.3.1. 核心應用程式意圖

Android 上游專案定義了許多核心應用程式，例如電話撥號程式、日曆、聯絡簿、音樂播放器等。裝置導入者可以將這些應用程式替換為其他版本。

不過，任何這類替代版本都必須遵循上游專案提供的相同意圖模式。舉例來說，如果裝置含有其他音樂播放器，則仍須遵循第三方應用程式發出的 Intent 模式，才能選取歌曲。

以下應用程式屬於核心 Android 系統應用程式：

桌上時鐘
Browser
日曆
計算機
聯絡人
電子郵件
圖庫
GlobalSearch
啟動器
音樂
設定

核心 Android 系統應用程式包含各種活動或服務元件，這些元件被視為「公開」。也就是說，「android:exported」屬性可能不存在，或可能具有「true」值。

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

換句話說，裝置實作項目可以取代核心 Android 系統應用程式；不過，如果是這種情況，裝置實作項目就必須支援所有 Intent 模式，也就是每個核心 Android 系統應用程式所定義的 Intent 模式。

3.2.3.2. 意圖覆寫

由於 Android 是可擴充的平台，因此裝置實作者必須允許第三方應用程式覆寫第 3.2.3.1 節中所述的每個 Intent 模式。上游 Android 開放原始碼專案預設允許這項功能；裝置實作者不得為系統應用程式使用這些意圖模式而附加特殊權限，或禁止第三方應用程式繫結至這些模式並接管控制權。這項禁止行為包括但不限於停用「選擇器」使用者介面，因為這類介面可讓使用者在多個應用程式之間進行選擇，而這些應用程式都會處理相同的意圖模式。

3.2.3.3. 意圖命名空間

裝置實作者不得納入任何 Android 元件，因為這些元件會使用 android.* 命名空間中的 ACTION、CATEGORY 或其他關鍵字串，遵循任何新的意圖或廣播意圖模式。裝置實作者不得納入任何 Android 元件，這些元件會在屬於其他機構的套件空間中，使用 ACTION、CATEGORY 或其他關鍵字串來遵循任何新的 Intent 或廣播意圖模式。裝置實作者不得變更或擴充第 3.2.3.1 節所列核心應用程式使用的任何 Intent 模式。

這項禁止規定與第 3.6 節中針對 Java 語言類別所指定的規定類似。

3.2.3.4. 廣播意圖

第三方應用程式會依賴平台發布特定意圖，以便通知硬體或軟體環境的變更。相容的 Android 裝置必須廣播公開廣播意圖，以回應適當的系統事件。如要瞭解廣播意圖，請參閱 SDK 說明文件。

3.3. 原生 API 相容性

在 Dalvik 中執行的受管理程式碼可以呼叫應用程式 .apk 檔案中提供的機器碼，做為為適當裝置硬體架構編譯的 ELF .so 檔案。由於原生程式碼高度依賴基礎處理器技術，Android 會在 Android NDK 的 docs/CPU-ARCH-ABIS.txt 檔案中定義多個應用程式二進位檔介面 (ABI)。如果裝置實作與一或多個定義的 ABI 相容，則應實作與 Android NDK 的相容性，如下所示。

如果裝置實作項目支援 Android ABI，則會：

必須支援在受管理環境中執行的程式碼，以便使用標準 Java Native Interface (JNI) 語意，呼叫原生程式碼。
必須與下列清單中的每個必要程式庫相容 (即標頭相容)，並與 ABI 相容 (二進位檔相容)
必須透過 android.os.Build.CPU_ABI API 準確回報裝置支援的原生應用程式二進位檔介面 (ABI)
請務必只在 docs/CPU-ARCH-ABIS.txt 檔案中，回報 Android NDK 最新版本中記錄的 ABI。
應使用上游 Android 開放原始碼專案提供的原始碼和標頭檔案進行建構

下列原生程式碼 API 必須提供給包含原生程式碼的應用程式：

libc (C 程式庫)
libm (數學程式庫)
對 C++ 提供最精簡的支援
JNI 介面
liblog (Android 記錄)
libz (Zlib 壓縮)
libdl (動態連結器)
libGLESv1_CM.so (OpenGL ES 1.0)
libGLESv2.so (OpenGL ES 2.0)
libEGL.so (原生 OpenGL 途徑管理)
libjnigraphics.so
libOpenSLES.so (Open Sound Library 音訊支援)
libandroid.so (原生 Android 活動支援)
支援 OpenGL，如下所述

請注意，日後推出的 Android NDK 版本可能會支援其他 ABI。如果裝置實作不相容於現有的預先定義 ABI，則絕對不應回報支援任何 ABI。

原生程式碼的相容性很難處理。因此，我們再次強調，強烈建議裝置實作者使用上述程式庫的上游實作項目，以確保相容性。

3.4. 網頁相容性

許多開發人員和應用程式都會在使用者介面中使用 android.webkit.WebView 類別 [Resources, 8] 的行為，因此 WebView 實作必須與各 Android 實作相容。同樣地，完整的現代化網頁瀏覽器是 Android 使用者體驗的核心。裝置實作項目必須包含與上游 Android 軟體相符的 android.webkit.WebView 版本，且必須包含支援 HTML5 的現代瀏覽器，如下所述。

3.4.1. WebView 相容性

Android 開放原始碼實作項目會使用 WebKit 算繪引擎來實作 android.webkit.WebView。由於無法為網路轉譯系統開發完整的測試套件，因此裝置實作人員必須在 WebView 實作中使用 WebKit 的特定上游版本。具體違規事項如下：

裝置實作項目的 android.webkit.WebView 實作項目必須以 Android 2.3 的 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 [Resources, 9]。裝置實作項目至少必須支援 WebView 中與 HTML5 相關聯的下列各項 API：

應用程式快取/離線作業 [Resources, 10]
<video> 標記 [Resources, 11]
geolocation [Resources, 12]

此外，裝置實作必須支援 HTML5/W3C webstorage API [Resources, 13]，並應支援 HTML5/W3C IndexedDB API [Resources, 14]。請注意，隨著網路開發標準機構轉向偏好 IndexedDB 而非 webstorage，IndexedDB 預計將成為日後 Android 版本的必要元件。

如同所有 JavaScript API，HTML5 API 在 WebView 中的預設狀態為停用，除非開發人員透過一般 Android API 明確啟用。

3.4.2. 瀏覽器相容性

裝置實作項目必須包含獨立的瀏覽器應用程式，供一般使用者瀏覽網頁。獨立瀏覽器可採用 WebKit 以外的瀏覽器技術。不過，即使使用其他瀏覽器應用程式，提供給第三方應用程式的 android.webkit.WebView 元件仍必須以 WebKit 為基礎，如第 3.4.1 節所述。

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

獨立瀏覽器應用程式 (無論是基於上游 WebKit 瀏覽器應用程式，還是第三方替代品) 應盡可能支援 HTML5 [資源, 9]。裝置實作項目至少必須支援下列與 HTML5 相關的 API：

應用程式快取/離線作業 [Resources, 10]
<video> 標記 [Resources, 11]
geolocation [Resources, 12]

3.5. API 行為相容性

每種 API 類型 (受管理、軟體、原生和網路) 的行為都必須與上游 Android 開放原始碼專案的偏好實作相符 [Resources, 3]。以下是一些特定的相容性問題：

裝置不得變更標準意圖的行為或語意
裝置不得變更特定類型的系統元件 (例如服務、活動、ContentProvider 等) 的生命週期或生命週期語意
裝置絕對不得變更標準權限的語意

此處僅列舉部分內容，並未包含所有可能情況。Compatibility Test Suite (CTS) 會測試平台的大部分行為相容性，但並非全部。實作者有責任確保與 Android 開放原始碼專案的行為相容性。因此，裝置實作人員應盡可能使用 Android 開放原始碼計畫提供的原始碼，而非重新實作系統的重要部分。

3.6. API 命名空間

Android 遵循 Java 程式設計語言定義的套件和類別命名空間慣例。為確保與第三方應用程式相容，裝置導入者不得對下列套件命名空間進行任何禁止的修改 (請見下文)：

java.*
javax.*
sun.*
android.*
com.android.*

禁止的修改包括：

裝置實作項目不得透過變更任何方法或類別簽章，或移除類別或類別欄位，修改 Android 平台上公開公開的 API。
裝置實作者可以修改 API 的基礎實作項目，但此類修改不得影響任何公開 API 的已知行為和 Java 語言簽章。
裝置實作者不得在上述 API 中加入任何公開的元素 (例如類別或介面、欄位或方法)。

「公開暴露的元素」是指任何未以「@hide」標記裝飾的結構體，就像在 Android 上游原始碼中使用的標記一樣。換句話說，裝置實作者不得在上述命名空間中公開新的 API，或變更現有的 API。裝置實作者可以進行僅限內部使用的修改，但這些修改不得宣傳或以其他方式提供給開發人員。

裝置實作人員可以新增自訂 API，但任何這類 API 不得位於由其他機構擁有或參照的命名空間。舉例來說，裝置實作人員絕對不應將 API 新增至 com.google.* 或類似的命名空間；只有 Google 可以這麼做。同樣地，Google 也絕對不應將 API 新增至其他公司的命名空間。此外，如果裝置實作內容包含標準 Android 命名空間以外的自訂 API，則這些 API 必須封裝在 Android 共用程式庫中，這樣只有明確使用這些 API (透過 <uses-library> 機制) 的應用程式，才會受到這些 API 記憶體用量增加的影響。

如果裝置實作人員建議改善上述其中一個套件命名空間 (例如在現有 API 中新增實用的新功能，或新增 API)，則應前往 source.android.com，並根據該網站上的資訊，開始提供變更和程式碼的程序。

請注意，上述限制與 Java 程式設計語言中 API 命名的標準慣例相符；本節只是為了強化這些慣例，並透過納入這個相容性定義來使其具約束力。

3.7. 虛擬機器相容性

裝置實作項目必須支援完整的 Dalvik 執行檔 (DEX) 位元碼規格和 Dalvik 虛擬機器語意 [資源, 15]。

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

3.8. 使用者介面相容性

Android 平台包含一些開發人員 API，可讓開發人員鉤掛至系統使用者介面。裝置實作項目必須將這些標準 UI API 納入開發的自訂使用者介面，如下所述。

3.8.1. 小工具

Android 定義了元件類型和對應的 API 與生命週期，讓應用程式可向使用者公開「AppWidget」[Resources, 16]。Android 開放原始碼參考版本包含啟動器應用程式，其中包含使用者介面元素，可讓使用者在主畫面上新增、查看及移除 AppWidget。

裝置實作者可以替換參考啟動器 (即主畫面) 的替代方案。替代啟動器應內建 AppWidget 支援功能，並提供使用者介面元素，以便直接在啟動器中新增、設定、查看及移除 AppWidget。替代啟動器可省略這些使用者介面元素；不過，如果省略這些元素，裝置實作者必須提供可從啟動器存取的獨立應用程式，讓使用者新增、設定、查看及移除 AppWidget。

3.8.2. 通知

Android 包含 API，可讓開發人員通知使用者重要事件 [Resources, 17]。裝置實作者必須支援每個已定義的通知類別，具體來說就是聲音、震動、燈光和狀態列。

此外，實作項目必須正確轉譯 API [Resources, 18] 或狀態列圖示樣式指南 [Resources, 19] 中提供的所有資源 (圖示、音訊檔案等)。裝置導入者可以提供其他通知使用者體驗，而非參考 Android 開放原始碼導入作業所提供的體驗；不過，這類其他通知系統必須支援現有的通知資源，如上所述。

3.8.3. 搜尋

Android 包含 API [Resources, 20]，可讓開發人員將搜尋功能整合至應用程式，並將應用程式資料公開至全域系統搜尋。一般來說，這項功能包含單一系統層級使用者介面，可讓使用者輸入查詢，並在使用者輸入時顯示建議內容和結果。Android API 可讓開發人員重複使用這個介面，在自己的應用程式中提供搜尋功能，並將結果提供給常見的全域搜尋使用者介面。

裝置實作功能必須包含單一共用系統層級搜尋使用者介面，能夠根據使用者輸入內容提供即時建議。裝置實作項目必須實作 API，讓開發人員能夠重複使用這個使用者介面，在自己的應用程式中提供搜尋功能。裝置實作項目必須導入 API，讓第三方應用程式在全球搜尋模式下，將建議內容加入搜尋框。如果沒有安裝可使用這項功能的第三方應用程式，預設行為應是顯示網路搜尋引擎結果和建議。

裝置實作可能會提供其他搜尋使用者介面，但應包含硬式或軟式專用搜尋按鈕，可在任何應用程式中隨時用於叫用搜尋架構，並提供 API 說明文件中提供的行為。

3.8.4. 浮動式訊息

應用程式可以使用「Toast」API (定義於 [Resources, 21])，向使用者顯示短暫的非模態字串，該字串會在短時間後消失。裝置實作項目必須以某種高可見度的方式，向使用者顯示應用程式傳送的 Toast。

3.8.5. 動態桌布

Android 定義了元件類型和對應的 API 與生命週期，讓應用程式可向使用者提供一或多個「動態桌布」[Resources, 22]。動態桌布是指動畫、圖案或類似圖片，具有有限的輸入功能，可顯示為桌布，並在其他應用程式後方運作。

如果硬體可以以合理的幀率執行所有動態桌布，且不會對其他應用程式造成不良影響，就表示硬體可穩定執行動態桌布。如果硬體限制導致桌布和/或應用程式發生異常、耗用過多 CPU 或電池電力，或是以不合理的低畫面更新率執行，則系統會判定硬體無法執行動態桌布。舉例來說，某些動態桌布可能會使用 Open GL 1.0 或 2.0 內容顯示內容。在未支援多個 OpenGL 內容的硬體上，即時桌布無法穩定執行，因為即時桌布使用 OpenGL 內容時，可能會與其他同樣使用 OpenGL 內容的應用程式發生衝突。

裝置實作項目應實作動態桌布，以便可如上所述可靠地執行動態桌布。如果裝置實作項目無法如上述所述可靠地執行動態桌布，則絕對不應實作動態桌布。

4. 應用程式封裝相容性

裝置實作項目必須安裝並執行由官方 Android SDK 中「aapt」工具產生的 Android「.apk」檔案 [Resources, 23]。

裝置實作不得擴充 .apk [Resources, 24]、Android 資訊清單 [Resources, 25] 或 Dalvik 位元碼 [Resources, 15] 格式，以免這些檔案無法在其他相容的裝置上正確安裝及執行。裝置實作人員應使用 Dalvik 的參考上游實作項目，以及參考實作項目的套件管理系統。

5. 多媒體相容性

裝置實作項目必須完整實作所有多媒體 API。裝置實作方式必須支援下列所有多媒體編解碼，並應符合下列聲音處理指南。裝置實作方式必須至少包含一種音訊輸出方式，例如喇叭、耳機插孔、外接喇叭連線等。

5.1. 媒體轉碼器

裝置實作項目必須支援多媒體編解碼，詳情請參閱以下各節。所有這些編解碼皆以軟體實作方式提供，並在 Android 開放原始碼計畫的偏好 Android 實作方式中實作。

請注意，Google 和開放手持裝置聯盟均未聲明這些編解碼不受第三方專利限制。如要在硬體或軟體產品中使用這個原始碼，請注意，這段程式碼的實作方式 (包括在開放原始碼軟體或共享軟體中) 可能需要相關專利持有人的專利授權。

下表未列出大多數影片編解碼的特定位元率需求。原因是，實際上，目前的裝置硬體不一定支援與相關標準指定的必要位元率完全對應的位元率。相反地，裝置實作應支援硬體上可行的最高位元率，上限為規格定義的限制。

5.1.1. 媒體解碼器

裝置實作項目必須針對下表所述的每個編解碼和格式實作解碼器。請注意，每種媒體類型的解碼器皆由上游 Android 開放原始碼計畫提供。

音訊
	名稱	詳細資料	檔案/容器格式
	AAC LC/LTP	單聲道/立體聲內容，標準位元率最高 160 kbps，取樣率介於 8 至 48 kHz 之間的任何組合	3GPP (.3gp) 和 MPEG-4 (.mp4、.m4a)。不支援原始 AAC (.aac)
	HE-AACv1 (AAC+)
	HE-AACv2 (增強型 AAC+)
	AMR-NB	4.75 至 12.2 kbps，取樣頻率為 8 kHz	3GPP (.3gp)
	AMR-WB	9 個速率，從 6.60 kbit/s 到 23.85 kbit/s，取樣率為 16 kHz	3GPP (.3gp)
	MP3	單聲道/立體聲 8-320 Kbps 固定位元率 (CBR) 或可變位元率 (VBR)	MP3 (.mp3)
	MIDI	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)
	Ogg Vorbis		Ogg (.ogg)
	PCM	8 位元和 16 位元線性 PCM (速率上限為硬體限制)	WAVE (.wav)
Image
	JPEG	基本 + 漸進式
	GIF
	PNG
	BMP
影片
	H.263		3GPP (.3gp) 檔案
	H.264		3GPP (.3gp) 和 MPEG-4 (.mp4) 檔案
	MPEG4 簡易設定檔		3GPP (.3gp) 檔案

5.1.2. 媒體編碼器

裝置實作應盡可能納入 5.1.1 節所列的多種媒體格式的編碼器。不過，部分編碼器不適合用於缺少特定選用硬體的裝置。舉例來說，如果裝置缺少任何相機，就不適合使用 H.263 視訊的編碼器。因此，裝置實作項目必須依照下表所述條件實作媒體編碼器。

如要進一步瞭解裝置實作可能會省略硬體的條件，請參閱第 7 節。

音訊
	名稱	詳細資料	檔案/容器格式	條件
	AMR-NB	4.75 至 12.2 kbps，取樣頻率為 8 kHz	3GPP (.3gp)	包含麥克風硬體並定義 `android.hardware.microphone` 的裝置實作項目，必須包含這些音訊格式的編碼器。
	AMR-WB	9 個速率，從 6.60 kbit/s 到 23.85 kbit/s，取樣率為 16 kHz	3GPP (.3gp)
	AAC LC/LTP	單聲道/立體聲內容，標準位元率最高 160 kbps，取樣率介於 8 至 48 kHz 之間的任何組合	3GPP (.3gp) 和 MPEG-4 (.mp4、.m4a)。
Image	JPEG	基本 + 漸進式		所有裝置實作方式都必須包含這些圖片格式的編碼器，因為 Android 2.3 包含了應用程式可用來以程式輔助方式產生這些類型檔案的 API。
Image	PNG
影片	H.263		3GPP (.3gp) 檔案	包含相機硬體且定義 `android.hardware.camera` 或 `android.hardware.camera.front` 的裝置實作，必須包含這些影片格式的編碼器。

除了上述編碼器外，裝置實作也應包含 H.264 編碼器。請注意，未來版本的相容性定義預計會將這項規定改為「必須」。也就是說，在 Android 2.3 中，H.264 編碼是選用的，但在日後的版本中將會是必要的。對於搭載 Android 2.3 的現有裝置和新裝置，我們強烈建議您在 Android 2.3 中符合這項要求，否則在升級至未來版本時，這些裝置將無法達到 Android 相容性。

5.2. 音訊錄製

當應用程式使用 android.media.AudioRecord API 開始錄製音訊串流時，裝置實作應使用下列各項行為取樣及錄製音訊：

雜訊抑制處理 (如有) 應停用。
自動增益控制 (如有) 應停用。
裝置應顯示大致平坦的振幅與頻率特性，具體來說，從 100 Hz 到 4000 Hz 的頻率應為 ±3 dB
音訊輸入靈敏度應設為 1000 Hz 的 90 dB 聲音功率 (SPL) 來源，以便 16 位元樣本的 RMS 達到 5000。
PCM 振幅等級應以線性方式追蹤輸入 SPL 變化，至少在麥克風的 90 dB SPL 下，從 -18 dB 到 +12 dB 的範圍內。
在 90 dB SPL 輸入音量下，100 Hz 至 4000 Hz 的總諧波失真應低於 1%。

注意：雖然上述規定在 Android 2.3 中列為「SHOULD」，但未來版本的相容性定義預計會將這些規定改為「MUST」。也就是說，這些規定在 Android 2.3 中為選用項目，但在日後的版本中將會強制規定。對於搭載 Android 2.3 的現有裝置和新裝置，我們強烈建議您在 Android 2.3 中滿足這些需求，否則在升級至未來版本時，這些裝置將無法達到 Android 相容性。

5.3. 音訊延遲

音訊延遲時間的廣義定義是指應用程式要求音訊播放或錄製作業，以及裝置實作實際開始作業之間的間隔時間。許多類型的應用程式都需要短延遲，才能實現音效或 VOIP 通訊等即時效果。裝置實作內容包含麥克風硬體，並宣告 android.hardware.microphone 時，應符合本節所述的所有音訊延遲要求。如要進一步瞭解裝置實作方式可能會在何種情況下省略麥克風硬體，請參閱第 7 節。

本節的用詞定義如下：

「冷輸出延遲」是指應用程式要求音訊播放，與音訊開始播放之間的間隔，在音訊系統閒置並在要求前關機的情況下
「暖出力延遲」是指應用程式要求音訊播放，以及音訊開始播放之間的間隔，且音訊系統最近已使用，但目前處於閒置狀態 (也就是靜音)
「連續輸出延遲」是指在裝置正在播放音訊時，應用程式發出要播放的樣本，與喇叭實際播放相應聲音之間的間隔
在應用程式要求錄音，以及透過回呼將第一個樣本傳送至應用程式之間的間隔，稱為「冷輸入延遲」。在要求之前，音訊系統和麥克風處於閒置狀態，且已關閉電源
「持續輸入延遲」是指裝置處於錄音模式時，當環境音發生，且相應的樣本透過回呼傳送至錄音應用程式

使用上述定義時，裝置實作應顯示下列每個屬性：

冷輸出延遲時間為 100 毫秒以下
輸出延遲時間為 10 毫秒以下
連續輸出延遲時間為 45 毫秒或更短
冷輸入延遲時間為 100 毫秒以下
連續輸入延遲時間為 50 毫秒或更短

如果裝置實作符合本節的規定，則可透過 android.content.pm.PackageManager 類別回報「android.hardware.audio.low-latency」功能，回報低延遲音訊支援功能。[資源，27] 相反地，如果裝置實作不符合這些要求，則不得回報支援低延遲音訊。

6. 開發人員工具相容性

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

Android Debug Bridge (簡稱 ADB) [資源，23]
裝置實作必須支援 Android SDK 中記錄的所有 adb 函式。裝置端 adb 守護程序應預設為停用，但必須提供使用者可存取的機制，才能開啟 Android Debug Bridge。
Dalvik 偵錯監控服務 (稱為 ddms) [Resources, 23]
裝置實作必須支援 Android SDK 中記載的所有 ddms 功能。由於 ddms 使用 adb，因此預設情況下應不支援 ddms，但在使用者啟用 Android Debug Bridge 時，必須支援 ddms，如上所述。
Monkey [Resources, 26]
裝置實作必須包含 Monkey 架構，並讓應用程式可使用該架構。

大多數以 Linux 為基礎的系統和 Apple Macintosh 系統，可使用標準 Android SDK 工具辨識 Android 裝置，無須額外支援；但 Microsoft Windows 系統通常需要新 Android 裝置的驅動程式。(例如，新的供應商 ID 和有時新的裝置 ID 需要 Windows 系統的客製化 USB 驅動程式)。如果裝置實作項目未受標準 Android SDK 提供的 adb 工具辨識，裝置實作者就必須提供 Windows 驅動程式，讓開發人員可透過 adb 通訊協定連線至裝置。這些驅動程式必須提供給 Windows XP、Windows Vista 和 Windows 7，且提供 32 位元和 64 位元版本。

7. 硬體相容性

Android 的目的，是讓裝置導入者能夠建立創新的板型規格和設定。同時，Android 開發人員會編寫創新應用程式，這些應用程式會依賴透過 Android API 提供的各種硬體和功能。本節中的規定，在裝置導入者可使用的創新功能，以及開發人員需要確保應用程式只在可正常執行的裝置上提供這兩者之間取得平衡。

如果裝置包含特定硬體元件，且該元件具有第三方開發人員的對應 API，則裝置實作方式必須按照 Android SDK 說明文件的說明實作該 API。如果 SDK 中的 API 與硬體元件互動，而該硬體元件已明確標示為選用，且裝置實作不含該元件：

元件 API 的完整類別定義 (如 SDK 所述) 仍必須存在
API 的行為必須以某種合理的方式實作為無操作
API 方法必須在 SDK 說明文件允許的情況下傳回空值
API 方法必須傳回類別的無操作實作項目，因為 SDK 說明文件不允許空值
API 方法不得擲回 SDK 說明文件未記載的例外狀況

適用這些規定的典型情境範例是 telephony API：即使是在非手機裝置上，這些 API 也必須以合理的無操作方式實作。

裝置實作項目必須透過 android.content.pm.PackageManager 類別的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法，準確回報硬體設定資訊。[資源，27]

7.1. 顯示和圖形

Android 2.3 包含自動調整應用程式資產和 UI 版面配置的設施，以確保第三方應用程式可在各種硬體設定下順利執行 [Resources, 28]。裝置必須正確實作這些 API 和行為，詳情請參閱本節。

7.1.1. 螢幕設定

裝置實作項目可使用任何像素尺寸的螢幕，但必須符合下列規定：

螢幕的對角線長度不得小於 2.5 英寸
密度必須至少為 100 dpi
長寬比必須介於 1.333 (4:3) 和 1.779 (16:9) 之間
使用的顯示器技術包含正方形像素

只要裝置實作項目的螢幕符合上述規定，就視為相容，不需要採取其他行動。Android 架構實作會自動計算顯示器特性，例如螢幕大小值區和密度值區。在大多數情況下，架構決定都是正確的。如果使用預設架構運算，則無需採取其他行動。如要變更預設值，或使用不符合上述規定的螢幕，裝置導入者必須洽詢 Android 相容性團隊，以取得第 12 節所述的指導方針。

上述規範所使用的單位定義如下：

「實際對角線尺寸」是指螢幕亮面部分兩個相對角落之間的距離，以英寸為單位。
「dpi」(「每英寸點數」) 是指 1 英寸水平或垂直線性跨度的像素數。如果列出 dpi 值，水平和垂直 dpi 都必須在範圍內。
「顯示比例」是螢幕長邊與短邊的比例。舉例來說，如果螢幕的解析度為 480x854 像素，則 854 / 480 = 1.779，或大約「16:9」。

裝置實作項目必須只使用單一靜態設定的螢幕。也就是說，裝置實作不得啟用多個螢幕設定。舉例來說，由於一般電視支援多種解析度，例如 1080p、720p 等等，因此這項設定與 Android 2.3 不相容。(不過，我們正在研究支援這類設定，並預計在日後的 Android 版本中實現)。

7.1.2. 顯示指標

裝置實作項目必須針對 android.util.DisplayMetrics [Resources, 29] 中定義的所有顯示指標回報正確的值。

7.1.3. 宣告的螢幕支援

應用程式可選擇透過 AndroidManifest.xml 檔案中的 <supports-screens> 屬性，指出支援的螢幕大小。裝置實作項目必須正確遵循應用程式所聲明的對小型、中型和大型螢幕的支援情形，詳情請參閱 Android SDK 說明文件。

7.1.4. 螢幕方向

相容的裝置必須支援應用程式以直向或橫向螢幕方向變更動態方向。也就是說，裝置必須遵循應用程式要求的特定螢幕方向。裝置實作可能會將直向或橫向方向設為預設值。無法實際旋轉的裝置，只要應用程式要求直向模式，並使用可用螢幕的部分畫面，即可透過「黑邊」方式符合這項規定。

無論是透過 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查詢，裝置都必須回報裝置目前的正確值。

7.1.5. 3D 圖形加速

裝置實作方式必須支援 OpenGL ES 1.0，以符合 Android 2.3 API 的要求。對於缺乏 3D 加速硬體的裝置，上游 Android 開放原始碼專案會提供 OpenGL ES 1.0 的軟體實作。裝置實作應支援 OpenGL ES 2.0。

實作項目可省略 Open GL ES 2.0 支援功能；不過，如果省略支援功能，裝置實作項目不得回報支援 OpenGL ES 2.0。具體來說，如果裝置實作項目缺乏 OpenGL ES 2.0 支援，則會發生以下情況：

受管理的 API (例如透過 GLES10.getString() 方法) 不得回報支援 OpenGL ES 2.0
原生 C/C++ OpenGL API (也就是透過 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 提供給應用程式的 API) 不得回報支援 OpenGL ES 2.0。

反之，如果裝置實作確實支援 OpenGL ES 2.0，則必須透過上述路徑準確回報支援情形。

請注意，Android 2.3 支援應用程式可選擇指定需要特定 OpenGL 紋理壓縮格式。這些格式通常是供應商專用。Android 2.3 不需要裝置實作項目就能實作任何特定紋理壓縮格式。不過，應透過 OpenGL API 中的 getString() 方法，準確回報支援的任何紋理壓縮格式。

7.2. 輸入裝置

Android 2.3 支援多種使用者輸入模式。裝置實作項目必須支援本節所提供的使用者輸入裝置。

7.2.1. 鍵盤

裝置實作方式：

必須支援輸入管理架構 (可讓第三方開發人員建立輸入管理引擎，例如軟體鍵盤)，詳情請參閱 developer.android.com
必須提供至少一個軟體鍵盤 (無論是否有實體鍵盤)
可納入其他螢幕鍵盤實作
可包含硬體鍵盤
請勿加入不符合 android.content.res.Configuration.keyboard [Resources, 30] 中所述格式的實體鍵盤 (也就是 QWERTY 或 12 鍵)

裝置實作方式：

可省略非觸控導覽選項 (也就是可省略軌跡球、D-Pad 或滾輪)
必須回報 android.content.res.Configuration.navigation [Resources, 30] 的正確值
必須提供合理的替代使用者介面機制，用於選取及編輯文字，且必須與輸入管理引擎相容。上游 Android 開放原始碼包含選取機制，適合用於缺乏非觸控導覽輸入功能的裝置。

主畫面、選單和返回功能對於 Android 導覽模式至關重要。無論應用程式狀態為何，裝置實作項目都必須隨時向使用者提供這些功能。這些功能應透過專用按鈕實作。您可以使用軟體、手勢、觸控面板等方式實作，但必須確保使用者一律可存取，且不會遮蔽或干擾可用的應用程式顯示區域。

裝置實作者也應提供專屬搜尋鍵。裝置實作者也可能提供電話的傳送和結束鍵。

7.2.4. 觸控螢幕輸入

裝置實作方式：

必須具備觸控螢幕
可能具備電容式或電阻式觸控螢幕
必須回報 android.content.res.Configuration [Resources, 30] 的值，反映裝置上特定觸控螢幕的類型
如果觸控螢幕支援多個指標，應支援完全獨立追蹤的指標

7.3. 感應器

Android 2.3 包含用於存取各種感應器類型的 API。裝置實作通常可省略這些感應器，如以下各節所述。如果裝置包含特定感應器類型，且該類型有對應的 API 供第三方開發人員使用，則裝置實作方式必須按照 Android SDK 說明文件所述實作該 API。例如裝置實作：

必須根據 android.content.pm.PackageManager 類別準確回報感應器是否存在。[資源，27]
必須透過 SensorManager.getSensorList() 和類似方法，傳回支援感應器的正確清單
必須針對所有其他感應器 API 合理運作 (例如，在應用程式嘗試註冊事件監聽器時，適當地傳回 true 或 false，在沒有對應感應器時不呼叫感應器事件監聽器，等等)。

以上清單並未詳盡列出所有情況；Android SDK 的行為說明應視為權威資訊。

部分感應器類型為合成類型，也就是說，這些感應器可以從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速度感應器)。裝置實作項目應在包含必要的實體感應器時，實作這些感應器類型。

Android 2.3 API 引入了「串流」感應器的概念，這類感應器會持續傳回資料，而非只在資料變更時才傳回。裝置實作必須持續提供任何 API 的定期資料樣本，這些 API 在 Android 2.3 SDK 說明文件中標示為串流感應器。

7.3.1. 加速計

裝置實作應包含 3 軸式加速度計。如果裝置實作包含 3 軸式加速度計，則會：

必須能夠以 50 Hz 以上的頻率傳送事件
必須遵循 Android API 中的 Android 感應器座標系統 (請參閱 [Resources, 31])
必須能夠在任何三維向量上，從自由落體測量到兩倍重力 (2g) 以上
必須有 8 位元以上的精確度
標準差必須不超過 0.05 m/s^2

7.3.2. 磁力儀

裝置實作應包含 3 軸磁力儀 (即指南針)。如果裝置內含 3 軸式磁力計，則會：

必須能夠以 10 Hz 以上的頻率傳送事件
必須遵循 Android API 中的 Android 感應器座標系統 (請參閱「資源，31」)。
必須能夠對一系列的場強進行取樣，以涵蓋地磁場
必須有 8 位元以上的精確度
標準差必須不超過 0.5 µT

7.3.3. GPS

裝置實作應包含 GPS 接收器。如果裝置實作方式確實包含 GPS 接收器，則應加入某種形式的「輔助 GPS」技術，以盡可能縮短 GPS 鎖定時間。

7.3.4. 陀螺儀

裝置實作應包含陀螺儀 (即角度變更感應器)。裝置不應包含陀螺儀感應器，除非同時包含 3 軸加速計。如果裝置實作項目包含陀螺儀，則會：

必須能夠測量高達 5.5*Pi 弧度/秒 (即每秒約 1,000 度) 的方向變化
必須能夠以 100 Hz 以上的頻率傳送事件
必須有 8 位元以上的精確度

7.3.5. 氣壓計

裝置實作可能會包含氣壓計 (即環境空氣壓力感應器)。如果裝置實作項目包含氣壓計，則會執行以下操作：

必須能夠以 5 Hz 以上的頻率傳送事件
必須具備足夠的精確度，才能估算高度

7.3.7. 溫度計

裝置實作可能會 (但不應) 包含溫度計 (即溫度感應器)。如果裝置實作項目包含溫度計，則必須測量裝置 CPU 的溫度。絕對不得測量任何其他溫度。(請注意，此感應器類型已在 Android 2.3 API 中淘汰)。

7.3.7. 光度計

裝置實作可能會包含光度計 (即環境光感應器)。

7.3.8. 鄰近感應器

裝置實作可能會包含鄰近感應器。如果裝置實作包含鄰近感應器，則該裝置必須在與螢幕相同方向測量物體的鄰近性。也就是說，鄰近感應器必須以偵測螢幕附近物體為方向，因為這類感應器的主要意圖是偵測使用者正在使用的手機。如果裝置實作項目包含其他方向的鄰近感應器，則絕對不應透過此 API 存取。如果裝置實作有鄰近感應器，則必須具備 1 位元或更高的準確度。

7.4. 資料連線

網路連線和網際網路存取權是 Android 的重要功能。同時，裝置對裝置互動功能可為 Android 裝置和應用程式帶來重大價值。裝置實作方式必須符合本節中列出的要求。

7.4.1. 電話通訊系統

Android 2.3 API 和本文件所使用的「Telephony」是指與透過 GSM 或 CDMA 網路撥打語音通話和傳送簡訊相關的硬體。雖然這些語音通話可能會或不會以封包交換方式進行，但在 Android 2.3 中，這些通話與使用相同網路的任何資料連線皆視為獨立。換句話說，Android 的「telephony」功能和 API 專門用於語音通話和簡訊；舉例來說，如果裝置實作無法撥打電話或傳送/接收簡訊，則無論是否使用行動網路進行資料連線，都不得回報「android.hardware.telephony」功能或任何子功能。

Android 2.3 可用於不含電話功能硬體的裝置。也就是說，Android 2.3 與非手機裝置相容。不過，如果裝置實作內容包含 GSM 或 CDMA 電話服務，則必須針對該技術的 API 實作完整支援。不含電話服務硬體的裝置實作項目，必須將完整的 API 實作為無操作。

7.4.2. IEEE 802.11 (Wi-Fi)

Android 2.3 裝置實作應支援一或多種 802.11 格式 (b/g/a/n 等)。如果裝置實作確實支援 802.11，則必須實作相應的 Android API。

7.4.3. 藍牙

裝置實作應包含藍牙收發器。包含藍牙收發機的裝置實作項目必須啟用 SDK 說明文件 [Resources, 32] 中所述的 RFCOMM 型藍牙 API。裝置實作項目應根據裝置需求，實作相關的藍牙設定檔，例如 A2DP、AVRCP、OBEX 等。

相容性測試套件包含涵蓋 Android RFCOMM Bluetooth API 基本作業的案例。不過，由於藍牙是裝置之間的通訊協定，因此無法透過在單一裝置上執行的單元測試進行完整測試。因此，裝置實作也必須通過附錄 A 所述的人為操作藍牙測試程序。

7.4.4. 近距離無線通訊

裝置實作應包含近距離無線通訊 (NFC) 的收發器和相關硬體。如果裝置實作包含 NFC 硬體，則會：

必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。[資源，27]

必須能夠透過下列 NFC 標準讀取及寫入 NDEF 訊息：

必須能夠透過下列 NFC 標準，充當 NFC Forum 讀取器/寫入器 (依據 NFC Forum 技術規格 NFCForum-TS-DigitalProtocol-1.0 定義)：
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS 6319-4)
- NfcV (ISO 15693)
- IsoDep (ISO 14443-4)
- NFC Forum 標記類型 1、2、3、4 (由 NFC Forum 定義)
必須能夠透過下列對等端標準和通訊協定傳送及接收資料：
- ISO 18092
- LLCP 1.0 (由 NFC 論壇定義)
- SDP 1.0 (由 NFC 論壇定義)
- NDEF Push Protocol [Resources, 33]
在 NFC 探索模式下，必須掃描所有支援的技術。
裝置喚醒且螢幕處於活動狀態時，應處於 NFC 探索模式。

(請注意，上述 JIS、ISO 和 NFC 論壇規格不適用於公開連結)。

此外，裝置實作應支援下列廣泛部署的 MIFARE 技術。

MIFARE Classic (NXP MF1S503x [Resources, 34], MF1S703x [Resources, 35])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 36], MF0ICU2 [Resources, 37])
MIFARE Classic 上的 NDEF (NXP AN130511 [Resources, 38]、AN130411 [Resources, 39])

請注意，Android 2.3.3 包含這些 MIFARE 類型的 API。如果裝置實作項目支援 MIFARE，則會：

必須實作 Android SDK 說明文件中的對應 Android API
必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。[Resources, 27] 請注意，這不是標準的 Android 功能，因此不會在 PackageManager 類別中顯示為常數。
除非也實作一般 NFC 支援功能 (如本節所述)，否則絕對不得實作對應的 Android API 或回報 com.nxp.mifare 功能

如果裝置實作不包含 NFC 硬體，則絕對不可透過 android.content.pm.PackageManager.hasSystemFeature() 方法 [Resources, 27] 宣告 android.hardware.nfc 功能，且必須將 Android 2.3 NFC API 實作為無操作。

由於 android.nfc.NdefMessage 和 android.nfc.NdefRecord 類別代表不依附通訊協定的資料表示格式，因此即使裝置實作不支援 NFC 或宣告 android.hardware.nfc 功能，也必須實作這些 API。

7.4.5. 最低網路功能

裝置實作必須支援一或多種形式的資料網路。具體來說，裝置實作必須支援至少一種資料標準，且該標準的傳輸速率必須達到 200Kbit/sec 以上。滿足這項規定的技術包括 EDGE、HSPA、EV-DO、802.11g、乙太網路等。

如果裝置實作項目以實體網路標準 (例如乙太網路) 做為主要資料連線，則應同時支援至少一種常見的無線資料標準，例如 802.11 (Wi-Fi)。

裝置可能會實作多種形式的資料連線。

7.5. 相機

裝置實作應包含後置鏡頭，且可能包含前置鏡頭。後置鏡頭是位於裝置螢幕對面側邊的鏡頭，也就是像傳統相機一樣，拍攝裝置遠端的場景。前置鏡頭是位於裝置螢幕同一側的鏡頭，也就是通常用於拍攝使用者圖像的鏡頭，例如視訊會議和類似應用程式。

7.5.1. 後置鏡頭

裝置實作項目應包含後置鏡頭。如果裝置實作包含後置鏡頭，則必須符合下列條件：

解析度必須至少為 2000 萬像素
應在相機驅動程式中實作硬體自動對焦或軟體自動對焦功能 (對應用程式軟體而言是透明的)
可能有固定焦或 EDOF (擴大景深) 硬體
可包含閃光效果。如果相機包含閃光燈，在相機預覽途徑註冊 android.hardware.Camera.PreviewCallback 例項時，閃光燈必須處於關閉狀態，除非應用程式已透過啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，明確啟用閃光燈。請注意，這項限制不適用於裝置內建的系統相機應用程式，只適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2. 前置鏡頭

裝置實作可能包含前置鏡頭。如果裝置實作包含前置鏡頭，則必須符合下列條件：

解析度必須至少為 VGA (即 640x480 像素)
請勿將前置鏡頭設為 Camera API 的預設值。也就是說，Android 2.3 中的相機 API 有針對前置鏡頭提供特定支援，而裝置實作方式不得將 API 設為將前置鏡頭視為預設後置鏡頭，即使前置鏡頭是裝置上唯一的相機也是如此。
可包含後置鏡頭可用的功能 (例如自動對焦、閃光燈等)，如第 7.5.1 節所述。
應用程式在 CameraPreview 中顯示的串流必須水平反射 (即鏡像)，如下所示：

如果裝置實作功能可由使用者旋轉 (例如透過加速計自動旋轉，或透過使用者輸入手動旋轉)，相機預覽畫面必須相對於裝置目前的方向水平鏡像。
如果目前的應用程式已明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() [Resources, 40] 方法旋轉相機螢幕，相機預覽畫面必須根據應用程式指定的方向水平鏡像。
否則，預覽畫面必須沿著裝置的預設水平軸鏡像顯示。

必須以與相機預覽圖片串流相同的方式，將傳回至任何「postview」相機回呼處理常式的圖片資料鏡像。(如果裝置實作不支援 PostView 回呼，則這項規定顯然不適用)。
不得鏡像最終擷取的靜態影像或影片串流，這些內容會傳回至應用程式回呼或儲存至媒體儲存空間

7.5.3. Camera API 行為

裝置實作項目必須針對相機相關 API 實作下列行為，包括前置鏡頭和後置鏡頭：

如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則裝置必須使用 android.hardware.PixelFormat.YCbCr_420_SP 提供給應用程式回呼的預覽資料。
如果應用程式註冊 android.hardware.Camera.PreviewCallback 例項，且系統在預覽格式為 YCbCr_420_SP 時呼叫 onPreviewFrame() 方法，則傳遞至 onPreviewFrame() 的 byte[] 中的資料必須採用 NV21 編碼格式。也就是說，預設值必須是 NV21。
裝置實作應支援 YV12 格式 (以 android.graphics.ImageFormat.YV12 常數表示)，以便預覽前置和後置鏡頭。請注意，未來版本的相容性定義預計會將這項規定改為「必須」。也就是說，在 Android 2.3 中，您可以選擇是否支援 YV12，但在日後推出的版本中，必須支援。對於搭載 Android 2.3 的現有裝置和新裝置，我們強烈建議在 Android 2.3 中符合這項要求，否則升級至未來版本時將無法達到 Android 相容性。

無論裝置是否包含硬體自動對焦或其他功能，裝置實作項目都必須實作 Android 2.3 SDK 說明文件 [Resources, 41] 中所包含的完整 Camera API。舉例來說，缺少自動對焦功能的相機仍必須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 例項 (即使這與非自動對焦相機無關)。請注意，這項做法也適用於前置鏡頭；舉例來說，即使大多數前置鏡頭不支援自動對焦，API 回呼仍必須如上所述「偽造」。

如果底層硬體支援這項功能，裝置實作項目就必須辨識並遵循 android.hardware.Camera.Parameters 類別中定義為常數的每個參數名稱。如果裝置硬體不支援某項功能，API 必須依照說明運作。相反地，除了 android.hardware.Camera.Parameters 上記錄為常數的字串常數外，裝置實作不得認可或識別傳遞至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作必須支援所有標準相機參數，且不得支援自訂相機參數類型。

7.5.4. 相機方向

如有前置和後置鏡頭，兩者的方向都必須經過調整，確保相機的長邊與螢幕的長邊對齊。也就是說，當裝置處於橫向方向時，相機就必須以橫向方向拍攝影像。無論裝置的自然方向為何，這項規定都適用，也就是適用於主要為橫向或直向的裝置。

7.6. 記憶體與儲存空間

Android 2.3 的基本功能是執行應用程式。裝置實作項目必須符合本節規定，確保應用程式有足夠的儲存空間和記憶體可供正常運作。

7.6.1. 記憶體和儲存空間最低需求

裝置實作項目必須至少提供 128 MB 的記憶體給核心和使用者空間使用。除了用於硬體元件 (例如無線電、記憶體等) 的記憶體 (不在核心控制之下)，128 MB 必須是額外的記憶體。

裝置實作項目必須提供至少 150 MB 的非揮發性儲存空間，供使用者資料使用。也就是說，/data 分區必須至少有 150 MB。

除了上述要求之外，裝置實作應至少提供 1 GB 的非揮發性儲存空間，供使用者資料使用。請注意，這項較高的規定預計會在日後的 Android 版本中成為硬性最低要求。強烈建議裝置實作項目現在就符合這些要求，否則可能無法與未來版本的 Android 相容。

Android API 包含下載管理工具，應用程式可使用這項工具下載資料檔案。下載管理器實作項目必須能夠下載 55 MB 或更大的個別檔案。下載管理工具的實作方式應可下載 100 MB 以上的檔案。

7.6.2. 應用程式共用儲存空間

裝置實作方式必須為應用程式提供共用儲存空間。提供的共用儲存空間大小必須至少為 1 GB。

裝置實作項目必須使用預設的共用儲存空間掛載方式進行設定，也就是「開箱即用」。如果共用儲存空間未掛載至 Linux 路徑 /sdcard，則裝置必須包含從 /sdcard 到實際掛載點的 Linux 符號連結。

裝置實作項目必須依照文件規定，對這項共用儲存空間強制執行 android.permission.WRITE_EXTERNAL_STORAGE 權限。否則，任何取得該權限的應用程式都必須能寫入共用儲存空間。

裝置實作可能會提供可讓使用者存取的可移除儲存空間硬體，例如 Secure Digital 卡。或者，裝置實作項目可以將內部 (不可移除) 儲存空間分配給應用程式共用儲存空間。

無論使用的共用儲存空間形式為何，裝置實作方式都必須提供某種機制，以便從主機電腦存取共用儲存空間的內容，例如 USB 大量儲存空間或媒體傳輸通訊協定。

以下列舉兩個常見的例子說明。如果裝置實作包含 SD 卡插槽，以符合共用儲存空間的規定，則在銷售給使用者的裝置中，必須附上 1 GB 大小或更大的 FAT 格式 SD 卡，且必須預設為已掛載。或者，如果裝置實作使用內部固定儲存空間來滿足這項要求，則該儲存空間的大小必須為 1 GB 以上，且必須掛載至 /sdcard (如果掛載至其他位置，則 /sdcard 必須是實體位置的符號連結)。

包含多個共用儲存空間路徑 (例如 SD 卡插槽和共用內部儲存空間) 的裝置實作項目應修改核心應用程式 (例如媒體掃描器和 ContentProvider)，以便透明地支援儲存在這兩個位置的檔案。

7.7. USB

裝置實作方式：

必須實作 USB 用戶端，可透過標準 USB-A 連接埠連線至 USB 主機
必須透過 USB 實作 Android Debug Bridge (如第 7 節所述)
必須實作 USB 大量儲存裝置規格，允許連線至裝置的主機存取 /sdcard 音量中的內容
應在裝置端使用 micro USB 板型規格
裝置端可納入非標準連接埠，但如果納入，則必須隨附可將自訂針腳連接至標準 USB-A 連接埠的傳輸線

8. 成效相容性

相容的實作項目必須確保應用程式不僅能正確執行，還能提供合理的效能和整體良好的使用者體驗。裝置實作項目必須符合下表中定義的 Android 2.3 相容裝置主要效能指標：

指標	效能門檻	備註
應用程式啟動時間	以下應用程式應在指定時間內啟動。瀏覽器：少於 1300 毫秒多媒體訊息/簡訊：小於 700 毫秒 AlarmClock：小於 650 毫秒	啟動時間是指完成應用程式預設活動載入作業的總時間，包括啟動 Linux 程序、將 Android 套件載入至 Dalvik VM，以及呼叫 onCreate 所需的時間。
同時申請	啟動多個應用程式後，重新啟動已啟動且正在執行的應用程式，所需時間必須少於原始啟動時間。

9. 安全性模型相容性

裝置實作項目必須實作與 Android 平台安全性模型一致的安全性模型，如 Android 開發人員說明文件中 API 的「安全性和權限」參考文件所定義 [Resources, 42]。裝置實作方式必須支援自行簽署應用程式的安裝作業，且不必向任何第三方/主管機關索取額外的權限/憑證。具體來說，相容裝置必須支援下列子節點所述的安全機制。

9.1. 權限

裝置實作方式必須支援 Android 權限模型，如 Android 開發人員說明文件所定義 [Resources, 42]。具體來說，導入方式必須強制執行 SDK 說明文件中定義的每項權限；不得省略、變更或忽略任何權限。如果新權限 ID 字串不在 android.* 命名空間中，實作可能會新增額外權限。

9.2. UID 和程序隔離

裝置實作項目必須支援 Android 應用程式沙箱模型，其中每個應用程式都會以獨特的 Unix 風格 UID 執行，並在個別程序中執行。裝置實作必須支援以相同的 Linux 使用者 ID 執行多個應用程式，前提是應用程式已正確簽署及建構，如「安全性和權限」參考資料 [Resources, 42] 所定義。

9.3. 檔案系統權限

裝置實作項目必須支援 Android 檔案存取權限模型，如「安全性和權限」參考資料所定義 [Resources, 42]。

9.4. 替代執行環境

裝置實作項目可能包含執行應用程式的執行階段環境，這些執行階段環境會使用其他軟體或技術 (而非 Dalvik 虛擬機器或原生程式碼) 執行應用程式。不過，這類替代執行環境不得危及 Android 安全性模型或已安裝 Android 應用程式的安全性，如本節所述。

替代執行階段本身必須是 Android 應用程式，並遵守標準 Android 安全性模型，如第 9 節其他部分所述。

替代執行階段不得授予存取權，以便存取透過 <uses-permission> 機制在執行階段的 AndroidManifest.xml 檔案中未要求的權限所保護的資源。

替代執行階段絕對不允許應用程式使用受限於系統應用程式的 Android 權限保護的功能。

替代執行階段必須遵守 Android 沙箱模型。具體違規事項如下：

替代執行階段應透過 PackageManager 將應用程式安裝到個別的 Android 沙箱 (也就是 Linux 使用者 ID 等)
替代執行階段可提供單一 Android 沙箱，供所有使用替代執行階段的應用程式共用。
替代執行階段和使用替代執行階段的安裝應用程式，不得重複使用裝置上安裝的任何其他應用程式的沙箱，除非透過共用使用者 ID 和簽署憑證的標準 Android 機制
替代執行階段不得與其他 Android 應用程式對應的沙箱一同啟動、授予存取權，或取得存取權。

替代執行階段不得啟動、授予或授予其他應用程式任何超級使用者 (root) 或其他使用者 ID 的權限。

替代執行階段的 .apk 檔案可納入裝置實作項目的系統映像檔，但必須使用與裝置實作項目中其他應用程式簽署金鑰不同的金鑰進行簽署。

安裝應用程式時，替代執行階段必須針對應用程式使用的 Android 權限，取得使用者的同意。也就是說，如果應用程式需要使用具有對應 Android 權限 (例如相機、GPS 等) 的裝置資源，替代執行階段必須通知使用者，應用程式將可存取該資源。如果執行階段環境未以這種方式記錄應用程式功能，則在安裝使用該執行階段的任何應用程式時，執行階段環境必須列出執行階段本身所持有的所有權限。

10. 軟體相容性測試

Android 開放原始碼計畫包含各種測試工具，可驗證裝置實作是否相容。裝置實作項目必須通過本節所述的所有測試。

不過，請注意，沒有任何軟體測試套件是完全全面的。因此，我們強烈建議裝置實作者盡可能減少對 Android 2.3 參考和偏好實作的變更次數，這些實作方式可從 Android 開放原始碼專案取得。這樣一來，您就能盡量降低引入錯誤的風險，避免出現需要重做及潛在裝置更新的不相容性問題。

10.1. 相容性測試套件

裝置實作項目必須使用裝置上的最終發布軟體，通過 Android 相容性測試套件 (CTS) [Resources, 2] [Resources, 2] Resources, 2]。此外，裝置實作人員應盡可能使用 Android 開放原始碼樹狀結構中的參考實作項目，並務必在 CTS 中出現模糊情況，以及參考原始碼的任何部分重新實作時，確保相容性。

CTS 設計用於在實際裝置上執行。就像任何軟體一樣，CTS 本身可能含有錯誤。CTS 的版本會與此相容性定義獨立，且可能會針對 Android 2.3 發布多個 CTS 修訂版本。裝置實作項目必須在裝置軟體完成時，通過最新的 CTS 版本。

必須在裝置實作軟體完成時，通過最新版本的 Android 相容性測試套件 (CTS)。(CTS 可透過 Android 開放原始碼計畫取得 [資源, 2]。)CTS 會測試本文所述的許多元件，但並非全部。

10.2. CTS 驗證器

裝置實作項目必須在 CTS Verifier 中正確執行所有適用的案例。CTS 驗證器包含在相容性測試套件中，並由人工操作人員執行，用於測試自動化系統無法測試的功能，例如相機和感應器的正確運作。

CTS Verifier 可測試多種硬體，包括部分選用硬體。裝置實作必須通過所有硬體測試；舉例來說，如果裝置有加速計，就必須在 CTS Verifier 中正確執行加速計測試案例。針對這份相容性定義文件中標示為選用的功能，測試案例可省略或略過。

如上所述，每部裝置和每個版本都必須正確執行 CTS Verifier。不過，由於許多版本都非常相似，因此裝置實作者不應在僅有細微差異的版本上明確執行 CTS 驗證工具。具體來說，如果裝置實作項目與已通過 CTS 驗證器的實作項目僅在所包含的語言代碼、品牌等方面有所差異，則可省略 CTS 驗證器測試。

10.3. 參考應用程式

裝置導入者必須使用下列開放原始碼應用程式，測試導入相容性：

「Apps for Android」應用程式 [Resources, 43]。
Replica Island (可在 Android Market 中取得；僅適用於支援 OpenGL ES 2.0 的裝置實作)

上述每個應用程式都必須在實作項目上正確啟動及運作，才能視為相容。

11. 可更新軟體

裝置實作項目必須包含替換整個系統軟體的機制。這項機制不必執行「即時」升級，也就是說，可能需要重新啟動裝置。

只要可以取代裝置上預先安裝的軟體，您可以使用任何方法。舉例來說，下列任何一種方法都能滿足這項要求：

透過重新啟動進行離線更新的無線更新 (OTA) 下載
透過主機電腦的 USB 連線進行「連線」更新
透過重新啟動和從可移除儲存空間的檔案更新「離線」更新

使用的更新機制必須支援不清除使用者資料的更新作業。請注意，上游 Android 軟體包含符合此要求的更新機制。

如果在裝置導入後 (但在與 Android 相容性團隊協商後決定的合理產品壽命期間內) 發現錯誤，導致影響第三方應用程式的相容性，裝置導入者就必須透過可用的軟體更新修正錯誤，且可依照剛剛所述機制套用。

12. 與我們聯絡

如有任何問題，請透過 compatibility@android.com 與文件作者聯絡，以便釐清問題，並提出您認為文件未涵蓋的任何問題。

附錄 A - 藍牙測試程序

相容性測試套件包含涵蓋 Android RFCOMM Bluetooth API 基本作業的案例。不過，由於藍牙是裝置之間的通訊協定，因此無法透過在單一裝置上執行的單元測試進行完整測試。因此，裝置實作也必須通過下文所述的人為操作藍牙測試程序。

測試程序會根據 Android 開放原始碼專案樹狀結構中的 BluetoothChat 範例應用程式進行。這個程序需要兩部裝置：

候選裝置實作項目，執行要測試的軟體版本
已知相容的獨立裝置實作項目，以及所測試裝置實作項目的模型，也就是「已知良好」的裝置實作項目

在下方測試程序中，這些裝置分別稱為「候選」和「已知良好」裝置。

設定和安裝

透過 Android 原始碼樹狀結構中的「make samples」建構 BluetoothChat.apk。
在已知正常運作的裝置上安裝 BluetoothChat.apk。
在候選裝置上安裝 BluetoothChat.apk。

測試應用程式藍牙控制功能

在候選裝置上啟動 BluetoothChat，但藍牙功能已停用。
確認候選裝置會開啟藍牙，或透過對話方塊提示使用者開啟藍牙。

測試配對和通訊

在兩部裝置上啟動藍牙聊天應用程式。
在 BluetoothChat 中 (使用「選單」) 讓已知可正常運作的裝置可供偵測。
在候選裝置上，透過 BluetoothChat (使用「選單」) 掃描藍牙裝置，然後與已知可用的裝置配對。
從每部裝置傳送 10 則以上訊息，並確認另一部裝置是否正確收到這些訊息。
按下Home 鍵，關閉兩部裝置上的 BluetoothChat 應用程式。
使用裝置的「設定」應用程式，將各裝置解除配對。

測試反向配對和通訊

在兩部裝置上啟動藍牙聊天應用程式。
在 BluetoothChat 中 (使用選單) 讓候選裝置可供偵測。
在已知可正常運作的裝置上，透過 BluetoothChat (使用「選單」) 掃描藍牙裝置，並與候選裝置配對。
從每部裝置傳送 10 或以上訊息，並確認另一部裝置是否正確收到這些訊息。
在兩部裝置上關閉藍牙聊天應用程式，方法是重複按「返回」鍵，直到 Launcher 畫面顯示為止。

測試重新啟動

在兩部裝置上重新啟動藍牙通訊應用程式。
從每部裝置傳送 10 或以上訊息，並確認另一部裝置是否正確收到這些訊息。

注意：上述測試中，有些情況是使用「Home」鍵結束測試部分，有些則是使用「Back」鍵。這些測試並非多餘，也不是選用的測試：其目的是驗證在活動明確終止 (透過使用者按下「返回」按鈕，呼叫 finish()) 和隱含傳送至背景 (透過使用者按下「Home」鍵) 時，藍牙 API 和堆疊是否正常運作。每個測試序列都必須按照說明執行。

Android 2.3 相容性定義

目錄

1. 簡介

2. 資源

3. 軟體

3.1. 代管 API 相容性

3.2. 軟性 API 相容性

3.2.1. 權限

3.2.2. 建構參數

3.2.3. 意圖相容性

3.2.3.1. 核心應用程式意圖

3.2.3.2. 意圖覆寫

3.2.3.3. 意圖命名空間

3.2.3.4. 廣播意圖

3.3. 原生 API 相容性

3.4. 網頁相容性

3.4.1. WebView 相容性

3.4.2. 瀏覽器相容性

3.5. API 行為相容性

3.6. API 命名空間

3.7. 虛擬機器相容性

3.8. 使用者介面相容性

3.8.1. 小工具

3.8.2. 通知

3.8.3. 搜尋

3.8.4. 浮動式訊息

3.8.5. 動態桌布

4. 應用程式封裝相容性

5. 多媒體相容性

5.1. 媒體轉碼器

5.1.1. 媒體解碼器

5.1.2. 媒體編碼器

5.2. 音訊錄製

5.3. 音訊延遲

6. 開發人員工具相容性

7. 硬體相容性

7.1. 顯示和圖形

7.1.1. 螢幕設定

7.1.2. 顯示指標

7.1.3. 宣告的螢幕支援

7.1.4. 螢幕方向

7.1.5. 3D 圖形加速

7.2. 輸入裝置

7.2.1. 鍵盤

7.2.2. 非觸控導覽

7.2.3. 瀏覽鍵

7.2.4. 觸控螢幕輸入

7.3. 感應器

7.3.1. 加速計

7.3.2. 磁力儀

7.3.3. GPS

7.3.4. 陀螺儀

7.3.5. 氣壓計

7.3.7. 溫度計

7.3.7. 光度計

7.3.8. 鄰近感應器

7.4. 資料連線

7.4.1. 電話通訊系統

7.4.2. IEEE 802.11 (Wi-Fi)

7.4.3. 藍牙

7.4.4. 近距離無線通訊

7.4.5. 最低網路功能

7.5. 相機

7.5.1. 後置鏡頭

7.5.2. 前置鏡頭

7.5.3. Camera API 行為

7.5.4. 相機方向

7.6. 記憶體與儲存空間

7.6.1. 記憶體和儲存空間最低需求

7.6.2. 應用程式共用儲存空間

7.7. USB

8. 成效相容性

9. 安全性模型相容性

9.1. 權限

9.2. UID 和程序隔離

9.3. 檔案系統權限

9.4. 替代執行環境

10. 軟體相容性測試

10.1. 相容性測試套件

10.2. CTS 驗證器