Android 4.2 相容性定義

修訂版2
最後更新時間：2013 年 2 月 17 日

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

目錄

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

一、簡介

本文檔列舉了裝置與 Android 4.2 相容必須滿足的要求。

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

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

要被認為與 Android 4.2 相容，裝置實作必須滿足此相容性定義中提出的要求，包括透過引用合併的任何文件。

如果第 10 節中所述的此定義或軟體測試是沉默的、不明確的或不完整的，則設備實現者有責任確保與現有實現的兼容性。

因此，Android 開源專案 [參考資料, 3 ] 既是 Android 的參考實現，也是首選實現。強烈鼓勵設備實現者最大程度地基於 Android 開源專案提供的「上游」原始程式碼來實現其實現。雖然假設某些組件可以替換為替代實現，但強烈建議不要這樣做，因為通過軟體測試將變得更加困難。實作者有責任確保與標準 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 4.2 允許的版本字串： http://source.android.com/docs/compatibility/4.2/versions.html
  8. 渲染腳本： http://developer.android.com/guide/topics/graphics/renderscript.html
  9. 硬體加速： http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView 類別： http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5 離線功能： http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5 影片標籤： http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C 地理定位 API： http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C 網路資料庫 API： http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB API： http://www.w3.org/TR/IndexedDB/
  17. Dalvik 虛擬機器規格：可在 Android 原始碼中找到，位於 dalvik/docs
  18. 應用程式小工具： http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. 通知： http ://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. 應用程式資源： http://code.google.com/android/reference/available-resources.html
  21. 狀態列圖示樣式指南： http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html
  22. 搜尋管理員： http://developer.android.com/reference/android/app/SearchManager.html
  23. 吐司：http: //developer.android.com/reference/android/widget/Toast.html
  24. 主題：http: //developer.android.com/guide/topics/ui/themes.html
  25. R.style類別： http://developer.android.com/reference/android/R.style.html
  26. 動態桌布： https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. Android 裝置管理： http://developer.android.com/guide/topics/admin/device-admin.html
  28. DevicePolicyManager參考： http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. Android 輔助使用服務 API： http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android 輔助使用 API： http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. 眼睛免費項目：http: //code.google.com/p/eyes-free
  32. 文字轉語音 API： http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. 參考工具文件（針對adb、aapt、ddms、systrace）：http: //developer.android.com/guide/developing/tools/index.html
  34. Android apk 檔案說明： http://developer.android.com/guide/topics/fundamentals.html
  35. 清單檔案： http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Monkey測試工具： https://developer.android.com/studio/test/other-testing-tools/monkey
  37. Android android.content.pm.PackageManager 類別和硬體功能清單： http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. 支援多畫面： http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration： http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent： http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. 藍牙 API： http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF 推播協定： http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X： http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X： http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1： http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2： http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511： http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411： http://www.nxp.com/documents/application_note/AN130411.pdf
  50. 相機方向API： http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. 相機： http://developer.android.com/reference/android/hardware/Camera.html
  52. Android 開放配件： http://developer.android.com/guide/topics/usb/accessory.html
  53. USB 主機 API： http://developer.android.com/guide/topics/usb/host.html
  54. Android 安全性與權限參考： http://developer.android.com/guide/topics/security/security.html
  55. 適用於 Android 的應用程式：http: //code.google.com/p/apps-for-android
  56. Android 下載管理器： http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android 檔案傳輸：http: //www.android.com/filetransfer
  58. Android 媒體格式： http://developer.android.com/guide/appendix/media-formats.html
  59. HTTP 直播協議草稿： http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. NFC 連線切換： http://www.nfc-forum.org/specs/spec_list/#conn_handover
  61. 使用 NFC 進行藍牙安全簡單配對： http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
  62. Wifi 多播 API： http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
  63. 動作輔助： http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
  64. USB 充電規格： http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
  65. Android 光束： http://developer.android.com/guide/topics/nfc/nfc.html
  66. Android USB 音訊： http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
  67. Android NFC 共享設定： http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
  68. Wifi 直連（Wifi P2P）： http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
  69. 鎖定與主畫面小工具： http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
  70. 使用者管理員參考： http://developer.android.com/reference/android/os/UserManager.html
  71. 外部儲存參考：https: //source.android.com/docs/core/storage
  72. 外部儲存 API： http://developer.android.com/reference/android/os/Environment.html
  73. 簡訊短代碼： http://en.wikipedia.org/wiki/Short_code
  74. 媒體遠端控制客戶端： http://developer.android.com/reference/android/media/RemoteControlClient.html
  75. 顯示管理器： http://developer.android.com/reference/android/hardware/display/DisplayManager.html
  76. 夢想： http://developer.android.com/reference/android/service/dreams/DreamService.html
  77. Android 應用程式開發相關設定： http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
  • 相機： http ://developer.android.com/reference/android/hardware/Camera.Parameters.html

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

    3、軟體

    3.1.託管 API 相容性

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

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

    此相容性定義允許裝置實作省略 Android 包含的 API 的某些類型的硬體。在這種情況下，API 必須仍然存在並以合理的方式運行。有關此場景的具體要求，請參閱第 7 節。

    3.2.軟 API 相容性

    除了第 3.1 節中的託管 API 之外，Android 還包括一個重要的僅運行時「軟」API，其形式為 Intent、權限和 Android 應用程式的類似方面，這些方面無法在應用程式編譯時強制執行。

    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 4.2，此欄位必須具有整數值 17。
    android.os.Build.VERSION.SDK_INT目前執行的 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。對於 Android 4.2，此欄位必須具有整數值 17。
    android.os.Build.VERSION.INCREMENTAL裝置實現者選擇的值，以人類可讀的格式指定目前正在執行的 Android 系統的特定版本。該值不得重複用於向最終用戶提供的不同建置。此欄位的典型用途是指示使用哪個版本號或原始碼控制變更標識符來產生版本。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
    android.os.Build.BOARD設備實現者選擇的值，以人類可讀的格式標識設備使用的特定內部硬體。此欄位的一個可能用途是指示為設備供電的板的特定版本。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式"^[a-zA-Z0-9.,_-]+$" 。
    android.os.Build.BRAND設備實施者選擇的值，以人類可讀的格式標識生產該設備的公司、組織、個人等的名稱。此欄位的可能用途是指示銷售該設備的 OEM 和/或營運商。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式"^[a-zA-Z0-9.,_-]+$" 。
    android.os.Build.CPU_ABI本機程式碼的指令集名稱（CPU 類型 + ABI 約定）。請參閱第 3.3 節：本機 API 相容性。
    android.os.Build.CPU_ABI2本機程式碼的第二指令集（CPU 類型 + ABI 約定）的名稱。請參閱第 3.3 節：本機 API 相容性。
    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:4.2/JRN53/3359:userdebug/test-keys
    指紋不得包含空白字元。如果上述模板中包含的其他字段具有空白字符，則必須在構建指紋中將它們替換為另一個字符，例如下劃線（“_”）字符。此欄位的值必須可編碼為 7 位元 ASCII。
    android.os.Build.HARDWARE硬體的名稱（來自核心命令列或/proc）。它應該是合理的人類可讀的。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式"^[a-zA-Z0-9.,_-]+$" 。
    android.os.Build.HOST以人類可讀格式唯一標識建構建構的主機的字串。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
    android.os.Build.ID設備實現者選擇的標識符，用於引用特定版本，採用人類可讀的格式。該欄位可以與 android.os.Build.VERSION.INCRMENTAL 相同，但應該是一個對於最終用戶區分軟體版本足夠有意義的值。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式"^[a-zA-Z0-9.,_-]+$" 。
    android.os.Build.MANUFACTURER產品原始設備製造商 (OEM) 的商品名稱。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
    android.os.Build.MODEL設備實現者選擇的值，包含最終使用者已知的設備名稱。此名稱應與設備行銷和銷售給最終用戶時使用的名稱相同。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。
    android.os.Build.Product設備實施者選擇的值，包含產品的開發名稱或程式碼名稱 (SKU)。必須是人類可讀的，但不一定供最終用戶查看。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式"^[a-zA-Z0-9.,_-]+$" 。
    android.os.Build.SERIAL硬體序號（如果有）。此欄位的值必須可編碼為 7 位元 ASCII 並符合正規表示式"^([a-zA-Z0-9]{0,20})$" 。
    android.os.Build.TAGS由設備實現者選擇的以逗號分隔的標籤列表，用於進一步區分建置。例如，“未簽名，調試”。此欄位的值必須可編碼為 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。該欄位的具體格式沒有要求，但不能為 null 或空字串 ("")。

    3.2.3.意圖相容性

    裝置實作必須遵循 Android 的鬆散耦合 Intent 系統，如下節所述。 「榮幸」意味著裝置實現者必須提供一個 Android Activity 或 Service，指定匹配的 Intent 過濾器，並綁定到每個指定的 Intent 模式並實現正確的行為。

    3.2.3.1.核心應用意圖

    Android上游專案定義了一些核心應用程序，例如聯絡人、日曆、照片庫、音樂播放器等。設備實施者可以用替代版本替換這些應用程式。

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

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

    • 英式鐘
    • 瀏覽器
    • 日曆
    • 聯絡方式
    • 畫廊
    • 全球搜尋
    • 啟動器
    • 音樂
    • 設定

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

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

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

    3.2.3.2.意圖覆蓋

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

    但是，如果預設活動為資料 URI 提供更具體的篩選器，則裝置實作可以為特定 URI 模式（例如 http://play.google.com）提供預設活動。例如，指定資料 URI「http://www.android.com」的 Intent 過濾器比「http://」的瀏覽器過濾器更具體。設備實作必須為使用者提供一個使用者介面來修改意圖的預設活動。

    3.2.3.3.意圖命名空間

    裝置實作不得包含任何使用 Android.* 或 com.android.* 命名空間中的 ACTION、CATEGORY 或其他鍵字串來支援任何新 Intent 或廣播 Intent 模式的 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 相容性

    3.3.1 應用程式二進位介面

    Dalvik 中執行的託管程式碼可以呼叫應用程式 .apk 檔案中提供的本機程式碼，作為針對適當裝置硬體架構編譯的 ELF .so 檔案。由於本機程式碼高度依賴底層處理器技術，因此 Android 在 Android NDK 中的檔案docs/CPU-ARCH-ABIS.html中定義了許多應用程式二進位介面 (ABI)。如果裝置實現與一個或多個已定義的 ABI 相容，則它應該實現與 Android NDK 的兼容性，如下所示。

    如果裝置實現包含對 Android ABI 的支持，則：

    • 必須支援在託管環境中執行的程式碼，以使用標準 Java 本機介面 (JNI) 語義呼叫本機程式碼。
    • 必須與下面列表中每個所需的庫來源相容（即標頭相容）和二進位相容（對於 ABI）
    • 必須透過android.os.Build.CPU_ABI API 精確報告設備支援的本機應用程式二進位介面 (ABI)
    • 必須僅報告最新版本的 Android NDK（位於文件docs/CPU-ARCH-ABIS.txt中）記錄的 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（OpenSL ES 1.0.1 音訊支援）
    • libOpenMAXAL.so（OpenMAX AL 1.0.1 支援）
    • libandroid.so（原生 Android 活動支援）
    • 支援 OpenGL，如下所述

    請注意，Android NDK 的未來版本可能會引入對其他 ABI 的支援。如果設備實作與現有的預定義 ABI 不相容，則它根本無法報告對任何 ABI 的支援。

    本機程式碼相容性具有挑戰性。因此，應該重申的是，強烈鼓勵設備實現者使用上面列出的庫的上游實作來幫助確保相容性。

    3.4.網路相容性

    3.4.1.網頁視圖相容性

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

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

    WebView 元件應該盡可能支援 HTML5 [參考資料，11 ]。至少，設備實作必須支援與 WebView 中的 HTML5 關聯的每個 API：

    此外，設備實作必須支援 HTML5/W3C webstorage API [參考資料，15 ]，並且應該支援 HTML5/W3C IndexedDB API [參考資料，16 ]。請注意，隨著 Web 開發標準機構逐漸轉向支援 IndexedDB 而不是 Webstorage，IndexedDB 預計將成為 Android 未來版本中的必要組件。

    HTML5 API 與所有 JavaScript API 一樣，必須在 WebView 中預設為停用，除非開發人員透過常用的 Android API 明確啟用它們。

    3.4.2.瀏覽器相容性

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

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

    獨立的瀏覽器應用程式（無論是基於上游 WebKit 瀏覽器應用程式還是第三方替代品）應該盡可能支援 HTML5 [參考資料，11 ]。設備實作至少必須支援與 HTML5 相關的每個 API：

    此外，設備實作必須支援 HTML5/W3C webstorage API [參考資料，15 ]，並且應該支援 HTML5/W3C IndexedDB API [參考資料，16 ]。請注意，隨著 Web 開發標準機構逐漸轉向支援 IndexedDB 而不是 Webstorage，IndexedDB 預計將成為 Android 未來版本中的必要組件。

    3.5. API 行為相容性

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

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

    上面的列表並不全面。相容性測試套件 (CTS) 測試平台的重要部分（但不是全部）的行為相容性。實作者有責任確保與 Android 開源專案的行為相容性。因此，裝置實現者應該盡可能使用透過 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 新增至其他公司的命名空間。此外，如果裝置實作包含標準 Android 命名空間之外的自訂 API，則這些 API 必須打包在 Android 共用程式庫中，以便只有明確使用它們（透過<uses-library>機制）的應用程式才會受到內存使用量增加的影響此類 API。

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

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

    3.7.虛擬機器相容性

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

    裝置實作必須配置 Dalvik 以根據上游 Android 平台分配內存，並如下表所示。 （有關螢幕尺寸和螢幕密度定義，請參閱第 7.1.1 節。）

    請注意，下面指定的記憶體值被視為最小值，設備實作可以為每個應用程式分配更多記憶體。

    螢幕尺寸螢幕密度應用記憶體
    小/普通/大LDPI/MDPI 16MB
    小/普通/大電視解析度 / 高清分辨率32MB
    小/普通/大高畫質像素64MB
    超大平均密度指數32MB
    超大電視解析度 / 高清分辨率64MB
    超大高畫質像素128MB

    3.8.使用者介面相容性

    3.8.1.小部件

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

    設備實作可以取代參考啟動器（即主螢幕）。替代啟動器應該包括對 AppWidget 的內建支持，並公開使用者介面功能以直接在啟動器內新增、配置、檢視和刪除 AppWidget。替代啟動器可以省略這些使用者介面元素；然而，如果它們被省略，裝置實作必須提供一個可從啟動器存取的單獨應用程序，允許使用者新增、配置、檢視和刪除 AppWidget。

    設備實作必須能夠渲染標準網格大小為 4 x 4 的小工具。 （有關詳細信息，請參閱 Android SDK 文件 [參考資料，18 ] 中的應用程式小工具設計指南。

    3.8.2.通知

    Android 包含的 API 允許開發人員使用裝置的硬體和軟體功能來通知使用者值得注意的事件 [參考資料，19 ]。

    某些 API 允許應用程式使用硬體（特別是聲音、振動和燈光）執行通知或吸引註意。設備實作必須支援使用硬體功能的通知，如 SDK 文件所述，並儘可能支援設備實現硬體。例如，如果裝置實作包含振動器，則它必須正確實作振動 API。如果設備實作缺少硬件，則對應的 API 必須實作為無操作。請注意，第 7 節對此行為進行了進一步詳細說明。

    此外，實作必須正確呈現 API [資源，20 ] 或狀態/系統列圖示樣式指南 [資源，21 ] 中提供的所有資源（圖示、聲音檔案等）。裝置實現者可以為通知提供替代的使用者體驗，而不是參考 Android 開源實作提供的體驗；然而，如上所述，此類替代通知系統必須支援現有通知資源。

    Android 4.2 支援豐富的通知，例如持續通知的互動式檢視。裝置實作必須正確顯示和執行豐富的通知，如 Android API 中所述。

    Android 包含 API [參考資料，22 ]，允許開發人員將搜尋合併到他們的應用程式中，並將應用程式的資料公開到全域系統搜尋中。一般來說，此功能由單一系統範圍的使用者介面組成，允許使用者輸入查詢、在使用者鍵入時顯示建議並顯示結果。 Android API 允許開發人員重複使用此介面在自己的應用程式中提供搜索，並允許開發人員向通用全域搜尋使用者介面提供結果。

    設備實現必須包括一個單一的、共享的、系統範圍的搜尋使用者介面，能夠響應用戶輸入提供即時建議。設備實作必須實作允許開發人員重複使用此使用者介面以在自己的應用程式中提供搜尋的 API。設備實作必須實作 API，允許第三方應用程式在全域搜尋模式下運行時向搜尋框添加建議。如果沒有安裝使用此功能的第三方應用程序，則預設行為應該是顯示網路搜尋引擎結果和建議。

    3.8.4.吐司

    應用程式可以使用「Toast」API（在[參考資料，23 ]中定義）向最終用戶顯示短的非模態字串，這些字串會在短暫的一段時間後消失。裝置實作必須以某種高可見性的方式向最終使用者顯示應用程式的 Toast。

    3.8.5。主題

    Android 提供「主題」作為應用程式在整個 Activity 或應用程式中應用樣式的機制。 Android 4.2 包含「Holo」或「全像」主題作為一組定義的樣式，供應用程式開發人員在想要匹配 Android SDK 定義的 Holo 主題外觀和感覺時使用[參考資料，24 ]。裝置實作不得更改向應用程式公開的任何 Holo 主題屬性 [參考資料，25 ]。

    Android 4.2 包含一個新的「裝置預設」主題，作為一組定義的樣式，供應用程式開發人員在想要匹配裝置實現者定義的裝置主題的外觀和風格時使用。設備實作可以修改向應用程式公開的 DeviceDefault 主題屬性 [參考資料，25 ]。

    3.8.6。動態壁紙

    Android 定義了一種元件類型以及相應的 API 和生命週期，允許應用程式向最終用戶公開一個或多個「動態壁紙」[參考資料，26 ]。動態壁紙是動畫、圖案或具有有限輸入功能的類似圖像，在其他應用程式後面顯示為壁紙。

    如果硬體能夠以合理的幀速率運行所有動態壁紙，且不限制功能，並且不會對其他應用程式產生不利影響，則認為該硬體能夠可靠地運行動態壁紙。如果硬體限制導致壁紙和/或應用程式崩潰、故障、消耗過多的 CPU 或電池電量，或以不可接受的低幀速率運行，則該硬體被視為無法運行動態壁紙。例如，某些動態桌布可能會使用 OpenGL 1.0 或 2.0 上下文來渲染其內容。動態桌布將無法在不支援多個 OpenGL 上下文的硬體上可靠地運行，因為使用 OpenGL 上下文的動態桌布可能會與也使用 OpenGL 上下文的其他應用程式發生衝突。

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

    3.8.7.最近的應用程式顯示

    上游 Android 4.2 原始程式碼包括一個使用者介面，用於使用使用者上次離開應用程式時應用程式圖形狀態的縮圖來顯示最近的應用程式。設備實現可能會改變或消除此使用者介面；然而，Android 的未來版本計劃更廣泛地使用此功能。強烈鼓勵裝置實現對最近的應用程式使用上游 Android 4.2 使用者介面（或類似的基於縮圖的介面），否則它們可能與未來版本的 Android 不相容。

    3.8.8.輸入管理設定

    Android 4.2 包含輸入管理引擎的支援。 Android 4.2 API 允許自訂應用程式 IME 指定使用者可調設定。當顯示提供此類使用者設定的 IME 時，裝置實作必須包括一種讓使用者始終存取 IME 設定的方法。

    3.8.9。鎖定和主螢幕小工具

    Android 4.2 支援使用者可以嵌入主畫面或鎖定畫面中的應用程式小工具（有關詳細信息，請參閱 Android SDK 文件 [參考資料，69 ] 中的應用程式小工具設計指南）。應用程式小工具允許快速存取應用程式資料和服務，而無需啟動新活動。小部件透過聲明android:widgetCategory清單標記來聲明對主螢幕或鎖定螢幕上的使用的支持，該清單標記告訴系統可以將小部件放置在哪裡。具體來說，設備實作必須滿足以下要求。

    • 設備實作必須支援主螢幕上的應用程式小工具。
    • 設備實現應該支援鎖定螢幕。如果設備實現包括對鎖定螢幕的支持，那麼設備實作必須支援鎖定螢幕上的應用程式小工具。

    3.8.10.鎖定螢幕媒體遙控器

    Android 4.2 支援遠端控制 API，允許媒體應用程式與顯示在遠端視圖（如裝置鎖定畫面）中的播放控制項整合[參考資料，74 ]。設備實作必須支援在設備鎖定畫面中嵌入遠端控制。

    3.8.11.夢

    Android 4.2 支援名為 Dreams 的互動式螢幕保護程式 [參考資料，76 ]。 Dreams 允許使用者在充電設備空閒或插入桌面底座時與應用程式互動。設備實作必須包括對 Dreams 的支持，並為使用者提供配置 Dreams 的設定選項。

    3.9 設備管理

    Android 4.2 包含允許安全性感知應用程式在系統層級執行裝置管理功能的功能，例如透過 Android 裝置管理 API 實施密碼原則或執行遠端清除 [參考資料，27 ]。裝置實作必須提供DevicePolicyManager類別的實作 [參考資料, 28 ]，並且應該支援 Android SDK 文件 [參考資料, 27 ] 中定義的全部裝置管理策略。

    注意：雖然上面概述的一些要求對於 Android 4.2 來說是“應該”，但支援鎖定螢幕的設備實作必須支援設備策略來管理鎖定螢幕上的小部件，如 Android SDK 文件 [參考資料，27 ] 中所定義。

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

    3.10 輔助功能

    Android 4.2 提供了一個輔助功能層，可以幫助殘障使用者更輕鬆地導航其裝置。此外，Android 4.2 提供平台 API，使輔助功能服務實作能夠接收使用者和系統事件的回呼並產生備用回饋機制，例如文字轉語音、觸覺回饋和軌跡球/方向鍵導航 [資源，29 ] 。裝置實作必須提供與預設 Android 實作一致的 Android 輔助功能框架的實作。具體來說，設備實作必須滿足以下要求。

    • 設備實作必須透過android.accessibilityservice API 支援第三方輔助功能服務實作 [參考資料，30 ]。
    • 裝置實作必須產生AccessibilityEvents並以與預設 Android 實作一致的方式將這些事件傳遞給所有已註冊的AccessibilityService實作。
    • 裝置實作必須提供使用者可存取的機制來啟用和停用輔助服務，並且必須顯示此介面以回應android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS意圖。

    此外，設備實作應該在設備上提供輔助服務的實現，並且應該為使用者提供一種在設備設定期間啟用輔助服務的機制。 Eyes Free 專案提供了無障礙服務的開源實作 [參考資料，31 ]。

    3.11 文字轉語音

    Android 4.2 包含允許應用程式使用文字轉語音 (TTS) 服務的 API，並允許服務提供者提供 TTS 服務的實現 [參考資料，32 ]。裝置實作必須滿足與 Android TTS 框架相關的以下要求：

    • 裝置實作必須支援 Android TTS 框架 API，並且應該包括支援裝置上可用語言的 TTS 引擎。請注意，上游 Android 開源軟體包含功能齊全的 TTS 引擎實作。
    • 設備實作必須支援安裝第三方 TTS 引擎。
    • 設備實作必須提供使用者可存取的介面，允許使用者選擇在系統層級使用的 TTS 引擎。

    4. 應用程式封裝相容性

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

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

    5. 多媒體相容性

    設備實現必須包含至少一種形式的音訊輸出，例如揚聲器、耳機插孔、外部揚聲器連接等。

    5.1.媒體編解碼器

    裝置實作必須支援 Android SDK 文件 [參考資料，58 ] 中指定的核心媒體格式，除非本文檔明確允許。具體來說，設備實作必須支援下表中定義的媒體格式、編碼器、解碼器、檔案類型和容器格式。所有這些編解碼器均作為 Android 開源專案的首選 Android 實作中的軟體實作提供。

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

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

    類型格式/編解碼器編碼器解碼器細節文件類型/容器格式
    聲音的MPEG-4 AAC 設定檔 (AAC LC)必需的
    包含麥克風硬體並定義android.hardware.microphone裝置實作是必需的。    		必需的支援單聲道/立體聲/5.0/5.1* 內容，標準取樣率為 8 至 48 kHz。
    • 3GPP (.3gp)
    • MPEG-4（.mp4、.m4a）
    • ADTS 原始 AAC（.aac，在 Android 3.1+ 中解碼，在 Android 4.0+ 中編碼，不支援 ADIF）
    • MPEG-TS（.ts，不可搜尋，Android 3.0+）
    MPEG-4 HE AAC 設定檔 (AAC+)對於包含麥克風硬體並定義 android.hardware.microphone 的裝置實作是必要的必需的支援單聲道/立體聲/5.0/5.1* 內容，標準取樣率為 16 至 48 kHz。
    MPEG-4 HE AAC v2 設定檔（增強型 AAC+）必需的支援單聲道/立體聲/5.0/5.1* 內容，標準取樣率為 16 至 48 kHz。
    MPEG-4 音訊物件類型 ER AAC ELD（增強型低延遲 AAC）對於包含麥克風硬體並定義 android.hardware.microphone 的裝置實作是必要的必需的支援單聲道/立體聲內容，標準取樣率為 16 至 48 kHz。
    AMR-NB必需的
    包含麥克風硬體並定義android.hardware.microphone裝置實作是必需的。    		必需的8kHz 時取樣率為 4.75 至 12.2 kbps 3GPP (.3gp)
    AMR-WB必需的
    包含麥克風硬體並定義android.hardware.microphone裝置實作是必需的。    		必需的9 個速率，從 6.60 kbit/s 到 23.85 kbit/s，取樣頻率為 16kHz 3GPP (.3gp)
    FLAC必需的
    （安卓3.1+）    		單聲道/立體聲（無多聲道）。取樣率高達 48 kHz（但在具有 44.1 kHz 輸出的裝置上建議高達 44.1 kHz，因為 48 至 44.1 kHz 下取樣器不包含低通濾波器）。推薦16位； 24 位元沒有套用抖動。限 FLAC (.flac)
    MP3必需的單聲道/立體聲 8-320Kbps 恆定 (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)
    • 瑪特羅斯卡 (.mkv)
    PCM/波必需的必需的8 位元和 16 位元線性 PCM**（速率達到硬體限制）。裝置必須支援 8000、16000 和 44100 Hz 頻率下原始 PCM 錄製的取樣率波形 (.wav)
    影像JPEG必需的必需的基礎+漸進JPEG (.jpg)
    動圖必需的GIF (.gif)
    巴布亞紐幾內亞必需的必需的PNG (.png)
    骨形態發生蛋白必需的點陣圖 (.bmp)
    WEBP必需的必需的WebP (.webp)
    影片H.263必需的
    包含相機硬體並定義android.hardware.camera或android.hardware.camera.front裝置實作是必要的。    		必需的
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    H.264AVC必需的
    包含相機硬體並定義android.hardware.camera或android.hardware.camera.front裝置實作是必要的。    		必需的基線概況 (BP)
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    • MPEG-TS（.ts，僅限 AAC 音頻，不可搜索，Android 3.0+）
    MPEG-4 SP必需的3GPP (.3gp)
    VP8必需的
    (安卓2.3.3+)    		 WebM (.webm) 和 Matroska (.mkv，Android 4.0+)
    *註：僅需縮混 5.0/5.1 內容；錄製或渲染 2 個以上通道是可選的。 **注意：16 位元線性 PCM 捕獲是強制性的。 8 位元線性 PCM 捕獲不是強制性的。

    5.2 視訊編碼

    包含後置相機並聲明android.hardware.camera Android 裝置實作應該支援以下視訊編碼設定檔。

    標清（低品質）標清（高品質）高畫質（硬體支援時）
    視訊編解碼器H.264 基線設定檔H.264 基線設定檔H.264 基線設定檔
    視訊解析度176 x 144 像素480 x 360 像素1280 x 720 像素
    視訊幀率12 幀/秒30 幀/秒30 幀/秒
    視訊比特率56Kbps 500 Kbps 或更高2 Mbps 或更高
    音訊編解碼器AAC-LC AAC-LC AAC-LC
    音訊頻道1（單聲道） 2（立體聲） 2（立體聲）
    音訊比特率24Kbps 128Kbps 192Kbps

    5.3 視訊解碼

    Android 裝置實作應該支援以下 VP8 視訊解碼設定檔。

    標清（低品質）標清（高品質）高清720p
    （當硬體支援時）    		高清1080p
    （當硬體支援時）
    視訊解析度320 x 180 像素640 x 360 像素1280 x 720 像素1920 x 1080 像素
    視訊幀率30 幀/秒30 幀/秒30 幀/秒30 幀/秒
    視訊比特率800Kbps 2Mbps 8Mbps 20Mbps

    5.4.聲音錄製

    當應用程式使用android.media.AudioRecord API 開始錄製音訊串流時，包含麥克風硬體並聲明android.hardware.microphone裝置實作必須使用以下每種行為採樣和錄製音訊：

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

    除了上述錄製規範之外，當應用程式開始使用android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION音訊來源錄製音訊串流：

    • 降噪處理（如果存在）必須停用。
    • 自動增益控制（如果存在）必須停用。

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

    5.5.音訊延遲

    音訊延遲是音訊訊號通過系統時的時間延遲。許多類別的應用程式依靠短延遲來實現即時效果，例如音效或 VOIP 通訊。

    就本節而言：

    • 「輸出延遲」定義為應用程式寫入 PCM 編碼資料幀與外部聆聽者聽到或感測器觀察到相應聲音之間的時間間隔
    • 「冷輸出延遲」定義為第一幀的輸出延遲，此時音訊輸出系統在請求之前已空閒並斷電
    • 「連續輸出延遲」定義為裝置已經播放音訊後後續影格的輸出延遲
    • 「輸入延遲」是向裝置呈現外部聲音與應用程式讀取對應的 PCM 編碼資料幀之間的時間間隔
    • 「冷輸入延遲」定義為當音訊輸入系統在請求之前處於空閒狀態並斷電時，遺失的輸入時間與第一幀的輸入延遲之和
    • 「連續輸入延遲」定義為裝置已經在擷取音訊時後續影格的輸入延遲
    • 「OpenSL ES PCM 緩衝佇列 API」是 Android NDK 中與 PCM 相關的 OpenSL ES API 集合；請參閱NDK_root /docs/opensles/index.html

    根據第 5 節，所有相容設備實作必須包含至少一種形式的音訊輸出。設備實現應該滿足或超過這些輸出延遲要求：

    • 冷輸出延遲為 100 毫秒或更短
    • 連續輸出延遲為 45 毫秒或更短

    如果在使用OpenSL ES PCM 緩衝佇列API 時，裝置實現在任何初始校準後滿足本節的要求，對於至少一個支援的音訊輸出裝置上的連續輸出延遲和冷輸出延遲，它可以報告對低延遲音訊的支持，透過android.content.pm.PackageManager類別報告功能「android.hardware.audio.low-latency」。 [資源，37 ] 相反，如果設備實現不滿足這些要求，則它不得報告對低延遲音訊的支援。

    根據第 7.2.5 節，設備實作可以省略麥克風硬體。

    包含麥克風硬體並聲明android.hardware.microphone裝置實作應滿足以下輸入音訊延遲要求：

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

    5.6.網路協定

    設備必須支援 Android SDK 文件 [參考資料，58 ] 中指定的用於音訊和視訊播放的媒體網路協定。具體來說，設備必須支援以下媒體網路協定：

    • RTSP（RTP、SDP）
    • HTTP(S) 漸進式串流傳輸
    • HTTP(S) 即時串流媒體草案協議，版本 3 [資源，59 ]

    6. 開發者工具和選項相容性

    6.1 開發者工具

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

    • Android 調試橋（稱為 adb） [資源，33 ]
      裝置實作必須支援 Android SDK 中記錄的所有adb函數。預設情況下，裝置端adb守護程式必須處於非活動狀態，且必須有使用者可存取的機制來開啟 Android 偵錯橋。

      • Android 4.2.2 包含對安全 adb 的支援。安全性 adb 在已知的經過驗證的主機上啟用 adb。強烈建議運行 Android 4.2.2 的現有裝置和新裝置在 Android 4.2 中滿足此要求，否則在升級到未來版本時將無法獲得 Android 相容性。

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

    大多數基於Linux的系統和Apple Macintosh系統使用標準Android SDK工具識別Android設備，無需額外支援；但是，Microsoft Windows 系統通常需要新 Android 裝置的驅動程式。 （例如，新的供應商 ID，有時新的裝置 ID 需要 Windows 系統的自訂 USB 驅動程式。）如果標準 Android SDK 中提供的adb工具無法識別裝置實現，則裝置實現者必須提供Windows 驅動程序，允許開發人員連接到使用adb協定的設備。必須為 Windows XP、Windows Vista、Windows 7 和 Windows 8（32 位元和 64 位元版本）提供這些驅動程式。

    6.2 開發者選項

    Android 4.2 支援開發人員配置應用程式開發相關的設定。設備實作必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖來顯示應用程式開發相關的設定 [參考資料，77 ]。上游 Android 實作預設隱藏「開發人員選項」選單，並允許使用者在「設定」>「關於裝置」>「內部版本號」選單項目上按七 (7) 次後啟動開發人員選項。設備實作必須為開發者選項提供一致的體驗。具體來說，裝置實作必須預設隱藏開發人員選項，並且必須提供一種機制來啟用與上游 Android 實作一致的開發人員選項。

    7. 硬體相容性

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

    • 元件 API 的完整類別定義（如 SDK 所記錄）必須仍然存在
    • API 的行為必須以某種合理的方式實現為無操作
    • 在 SDK 文件允許的情況下，API 方法必須傳回 null 值
    • API 方法必須傳回 SDK 文件不允許空值的類別的無操作實現
    • API 方法不得拋出 SDK 文件未記錄的異常

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

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

    7.1.顯示和圖形

    Android 4.2 包含自動調整應用程式資源和適合裝置的 UI 佈局的功能，以確保第三方應用程式在各種硬體配置上運作良好 [參考資料，38 ]。設備必須正確實作這些 API 和行為，如本節所述。

    本節要求引用的單位定義如下：

    • 「物理對角線尺寸」是顯示器照明部分的兩個相對角之間的距離（以英吋為單位）。
    • 「dpi」（意思是「每英吋點數」）是 1 英吋的線性水平或垂直跨度所包含的像素數。列出 dpi 值時，水平和垂直 dpi 都必須落在該範圍內。
    • 「長寬比」是螢幕的較長尺寸與較短尺寸的比率。例如，480x854 像素的顯示器將為 854 / 480 = 1.779，或大致為「16:9」。
    • 「與密度無關的像素」或（「dp」）是標準化為 160 dpi 螢幕的虛擬像素單位，計算公式為： pixels = dps * (density / 160) 。

    7.1.1.螢幕配置

    螢幕尺寸

    Android UI 框架支援各種不同的螢幕尺寸，並允許應用程式透過android.content.res.Configuration.screenLayout和SCREENLAYOUT_SIZE_MASK查詢裝置螢幕尺寸（也稱為「螢幕佈局」）。裝置實作必須報告 Android SDK 文件 [參考資料，38 ] 中定義並由上游 Android 平台確定的正確螢幕尺寸。具體來說，裝置實作必須根據以下邏輯密度無關像素 (dp) 螢幕尺寸報告正確的螢幕尺寸。

    • 裝置的螢幕尺寸必須至少為 426 dp x 320 dp（「小」）
    • 報告螢幕尺寸「正常」的裝置的螢幕尺寸必須至少為 480 dp x 320 dp
    • 報告螢幕尺寸為「大」的裝置的螢幕尺寸必須至少為 640 dp x 480 dp
    • 報告螢幕尺寸「xlarge」的裝置的螢幕尺寸必須至少為 960 dp x 720 dp

    此外，裝置的螢幕尺寸必須至少為 2.5 吋（實體對角線尺寸）。

    設備不得隨時更改其報告的螢幕尺寸。

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

    螢幕縱橫比

    長寬比必須介於 1.3333 (4:3) 和 1.85 (16:9) 之間。

    螢幕密度

    Android UI 框架定義了一組標準邏輯密度來幫助應用程式開發人員定位應用程式資源。裝置實作必須透過android.util.DisplayMetrics API 報告以下邏輯 Android 框架密度之一，並且必須以此標準密度執行應用程式。

    • 120 dpi，稱為“ldpi”
    • 160 dpi，稱為“mdpi”
    • 213 dpi，稱為“tvdpi”
    • 240 dpi，稱為“hdpi”
    • 320 dpi，稱為“xhdpi”
    • 480 dpi，稱為“xxhdpi”
    裝置實現應該定義在數值上最接近螢幕物理密度的標準 Android 框架密度，除非該邏輯密度將報告的螢幕尺寸推至支援的最小值以下。如果在數字上最接近物理密度的標準 Android 框架密度導致螢幕尺寸小於支援的最小相容螢幕尺寸（320 dp 寬度），則裝置實現應該報告下一個最低的標準 Android 框架密度。

    7.1.2.顯示指標

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

    7.1.3.螢幕方向

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

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

    更改方向時，設備不得更改報告的螢幕尺寸或密度。

    裝置必須報告它們支援哪些螢幕方向（ android.hardware.screen.portrait和/或android.hardware.screen.landscape ）並且必須報告至少一種支援的方向。例如，具有固定方向橫向螢幕的裝置（例如電視或筆記型電腦）必須僅報告android.hardware.screen.landscape 。

    7.1.4. 2D 和 3D 圖形加速

    裝置實作必須支援 OpenGL ES 1.0 和 2.0，如 Android SDK 文件中所體現和詳細說明的那樣。裝置實作也必須支援 Android Renderscript，如 Android SDK 文件 [參考資料，8 ] 中詳述。

    設備實作還必須正確地將自己標識為支援 OpenGL ES 1.0 和 2.0。那是：

    • 託管 API（例如透過GLES10.getString()方法）必須報告對 OpenGL ES 1.0 和 2.0 的支持
    • 本機 C/C++ OpenGL API（即透過 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 提供給應用程式的 API）必須報告對 OpenGL ES 1.0 和 2.0 的支援。

    設備實作可以實現任何所需的 OpenGL ES 擴充功能。但是，裝置實作必須透過 OpenGL ES 託管和本機 API 報告它們支援的所有擴充字串，相反，不得報告它們不支援的擴充字串。

    請注意，Android 4.2 支援應用程式選擇性地指定它們需要特定的 OpenGL 紋理壓縮格式。這些格式通常是特定於供應商的。 Android 4.2 不要求裝置實作來實現任何特定的紋理壓縮格式。然而，它們應該透過 OpenGL API 中的getString()方法準確地報告它們支援的任何紋理壓縮格式。

    Android 4.2 包含一種機制，應用程式可以透過使用清單標記android:hardwareAccelerated或直接 API 呼叫來聲明它們希望在應用程式、活動、視窗或視圖層級啟用 2D 圖形的硬體加速 [參考資料, 9 ]。

    在 Android 4.2 中，裝置實作必須預設啟用硬體加速，如果開發人員透過設定android:hardwareAccelerated="false"或直接透過 Android View API 直接停用硬體加速來要求，則必須停用硬體加速。

    此外，裝置實作必須表現出與有關硬體加速的 Android SDK 文件一致的行為 [參考資料，9 ]。

    Android 4.2 包含一個TextureView對象，可讓開發人員直接將硬體加速的 OpenGL ES 紋理集成為 UI 層次結構中的渲染目標。設備實作必須支援TextureView API，並且必須表現出與上游Android 實作一致的行為。

    7.1.5。舊版應用程式相容模式

    Android 4.2 指定了一種“兼容模式”，在該模式下，框架以“正常”屏幕尺寸等效（320dp 寬度）模式運行，以便為並非為時過早於屏幕尺寸獨立的舊版本Android 開發的遺留應用程序帶來好處。裝置實作必須包括對由上游 Android 開源程式碼實現的遺留應用程式相容模式的支援。也就是說，設備實作不得更改啟動相容模式的觸發器或閾值，且不得更改相容模式本身的行為。

    7.1.6。螢幕類型

    設備實現畫面分為以下兩種類型之一：

    • 固定像素顯示實作：螢幕是單一面板，僅支援單一像素寬度和高度。通常，螢幕與裝置物理整合。例如手機、平板電腦等。
    • 可變像素顯示實現：設備實現要么沒有嵌入式螢幕，但包括用於顯示的視訊輸出連接埠（例如 VGA、HDMI 或無線連接埠），要么具有可更改像素尺寸的嵌入式螢幕。例如電視、機上盒等。

    固定像素設備實現

    固定像素裝置實作可以使用任何像素尺寸的螢幕，前提是它們符合此​​相容性定義定義的要求。

    固定像素實作可以包括與外部顯示器一起使用的視訊輸出連接埠。但是，如果該顯示器用於運行應用程序，則設備必須滿足以下要求：

    • 設備必須報告與固定像素顯示器相同的螢幕配置和顯示指標，如第 7.1.1 和 7.1.2 節中詳述。
    • 設備必須報告與固定像素顯示器相同的邏輯密度。
    • 設備必須報告與固定像素顯示器相同或非常接近的螢幕尺寸。

    例如，對角線尺寸為 7 英寸、像素分辨率為 1024x600 的平板電腦被視為固定像素大 mdpi 顯示實現。如果它包含以 720p 或 1080p 顯示的視頻輸出端口，則設備實現必須縮放輸出，以便應用程式僅在大型mdpi 視窗中執行，無論是否使用固定像素顯示器或視訊輸出連接埠。

    可變像素設備實現

    可變像素設備實作必須支援 1280x720 或 1920x1080（即 720p 或 1080p）之一或兩者。具有可變像素顯示器的裝置實作不得支援任何其他螢幕配置或模式。具有可變像素螢幕的裝置實作可能會在運行時或啟動時變更螢幕配置或模式。例如，機上盒的使用者可以用 1080p 顯示器替換 720p 顯示器，並且裝置實作可以相應地調整。

    此外，可變像素設備實現必須報告這些像素尺寸的以下配置桶：

    • 1280x720（也稱為 720p）：「大」螢幕尺寸，「tvdpi」（213 dpi）密度
    • 1920x1080（也稱為 1080p）：「大」螢幕尺寸，「xhdpi」（320 dpi）密度

    為了清楚起見，在 Android 4.2 中，具有可變像素尺寸的裝置實作僅限於 720p 或 1080p，並且必須配置為報告螢幕尺寸和密度桶，如上所述。

    7.1.7。螢幕技術

    Android 平台包含允許應用程式向顯示器呈現豐富圖形的 API。除非本文檔特別允許，否則裝置必須支援 Android SDK 定義的所有這些 API。具體來說：

    • 設備必須支援能夠渲染 16 位元彩色圖形的顯示器，並且應該支援能夠渲染 24 位元彩色圖形的顯示器。
    • 設備必須支援能夠渲染動畫的顯示器。
    • 所使用的顯示技術的像素長寬比 (PAR) 必須在 0.9 到 1.1 之間。也就是說，像素長寬比必須接近正方形 (1.0)，容許差為 10%。

    7.1.8。外接顯示器

    Android 4.2 包括對輔助顯示器的支持，以啟用媒體共享功能和用於存取外部顯示器的開發人員 API。如果裝置透過有線、無線或嵌入式附加顯示連線支援外部顯示器，則裝置實作必須實作顯示管理器 API，如 Android SDK 文件 [參考資料，75 ] 所述。支援安全視訊輸出並能夠支援安全表面的設備實現必須聲明對Display.SECURE_FLAG的支援。具體來說，聲明支援Display.SECURE_FLAG的裝置實作必須支援HDCP 2.x 或更高版本（對於 Miracast 無線顯示器）或HDCP 1.2 或更高版本（對於有線顯示器）。上游 Android 開源實作包括滿足此要求的無線 (Miracast) 和有線 (HDMI) 顯示器的支援。

    7.2.輸入裝置

    7.2.1.鍵盤

    設備實現：

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

    7.2.2.非觸控式導航

    設備實現：

    • 可省略非觸控式導覽選項（即可省略軌跡球、方向鍵或滾輪）
    • 必須報告android.content.res.Configuration.navigation的正確值 [資源，40 ]
    • 必須提供合理的替代使用者介面機制來選擇和編輯文本，與輸入管理引擎相容。上游 Android 開源實作包括適合與缺乏非觸控導航輸入的裝置一起使用的選擇機制。

    7.2.3.導航鍵

    主頁、選單和返回功能對於 Android 導航範例至關重要。設備實作必須使用戶在運行應用程式時始終可以使用這些功能。這些功能可以透過專用的實體按鈕（例如機械或電容式觸控按鈕）來實現，也可以使用專用的軟體按鍵、手勢、觸控面板等來實現。Android 4.2 支援這兩種實現。

    Android 4.2 包含對輔助操作的支援 [參考資料，63 ]。設備實作必須使用戶在運行應用程式時始終可以使用輔助操作。此功能可以透過硬體或軟體金鑰來實現。

    裝置實作可以使用螢幕的不同部分來顯示導航鍵，但如果是這樣，則必須滿足以下要求：

    • 裝置實現導航鍵必須使用應用程式無法使用的螢幕的特定部分，且不得遮擋或以其他方式乾擾應用程式可用的螢幕部分。
    • 設備實作必須向符合第 7.1.1 節中定義的要求的應用程式提供顯示的一部分。
    • 當應用程式未指定係統 UI 模式或指定SYSTEM_UI_FLAG_VISIBLE時，裝置實作必須顯示導航鍵。
    • 當應用程式指定SYSTEM_UI_FLAG_LOW_PROFILE時，裝置實作必須以不顯眼的「低調」（例如變暗）模式顯示導航鍵。
    • 當應用程式指定SYSTEM_UI_FLAG_HIDE_NAVIGATION時，設備實作必須隱藏導航鍵。
    • 當 targetSdkVersion <= 10 時，裝置實作必須向應用程式顯示選單鍵，並且當 targetSdkVersion > 10 時，不應顯示選單鍵。

    7.2.4.觸控螢幕輸入

    設備實現：

    • 必須有某種指標輸入系統（類似滑鼠或觸控）
    • 可以有任何形式的觸控螢幕（例如電容式或電阻式）
    • 如果觸控螢幕支援多個指針，則應支援完全獨立追蹤的指針
    • 必須報告android.content.res.Configuration [ Resources, 39 ] 的值，該值反映了裝置上特定觸控螢幕的類型

    設備實現必須報告與所使用的輸入類型相對應的正確功能。請注意，Android 4.2 包含功能android.hardware.faketouch ，它對應於高保真非觸控（即基於指針）輸入設備，例如滑鼠或觸控板，可以充分模擬基於觸控的輸入（包括基本的觸控輸入）手勢支援），並指示裝置支援觸控螢幕功能的模擬子集。包含觸控螢幕（單點觸控或更好）的裝置實作也必須報告 android.hardware.faketouch。不包含觸控螢幕（且僅依賴指標裝置）的裝置實作不得報告任何觸控螢幕功能，且必須僅報告android.hardware.faketouch 。

    7.2.5.麥克風

    設備實作可以省略麥克風。但是，如果裝置實作省略了麥克風，則它不得報告android.hardware.microphone功能常數，並且必須根據第 7 節將音訊錄製 API 實現為無操作。相反，擁有麥克風的設備實現：

    • 必須報告android.hardware.microphone功能常數
    • 應符合第 5.4 節中的音訊品質要求
    • 應符合第 5.5 節中的音訊延遲要求

    7.3.感應器

    Android 4.2 包含用於存取各種感測器類型的 API。設備實作通常可以省略這些感測器，如下列小節所述。如果裝置包含特定感測器類型，且該感測器類型具有供第三方開發人員使用的相應 API，則裝置實作必須實作該 API，如 Android SDK 文件所述。例如，設備實作：

    • 必須根據android.content.pm.PackageManager類別準確地報告感測器是否存在。 [資源，37 ]
    • 必須透過SensorManager.getSensorList()和類似方法傳回受支援感測器的準確列表
    • 必須對所有其他感測器 API 表現得合理（例如，當應用程式嘗試註冊偵聽器時，根據需要傳回 true 或 false，當對應的感測器不存在時不呼叫感測器偵聽器；等等）
    • 必須使用 Android SDK 文件中定義的每種感測器類型的相關國際單位制（即公制）值來報告所有感測器測量結果 [參考資料，41 ]

    上面的列表並不全面； Android SDK 的記錄行為被認為是權威的。

    某些感測器類型是合成的，這意味著它們可以從一個或多個其他感測器提供的數據中得出。 （例如包括方向感測器和線性加速度感測器。）當設備實現包括必備的物理感測器時，設備實現應該實現這些感測器類型。

    Android 4.2 包含「串流」感測器的概念，它是連續返回資料的感測器，而不是僅在資料發生變化時返回資料。裝置實作必須持續為 Android 4.2 SDK 文件指示為串流感測器的任何 API 提供定期資料樣本。請注意，設備實作必須確保感測器流不得阻止設備 CPU 進入掛起狀態或從掛起狀態喚醒。

    7.3.1.加速度計

    設備實現應該包括一個 3 軸加速度計。如果設備實現確實包含 3 軸加速計，則：

    • 應能以 120 Hz 或更高頻率傳送事件。請注意，雖然上面的加速度計頻率在 Android 4.2 中被指定為“應該”，但未來版本的兼容性定義計劃將其更改為“必須”。也就是說，這些標準在 Android 4.2 中是可選的，但在未來版本中將是必要的。強烈鼓勵運行 Android 4.2 的現有設備和新設備滿足 Android 4.2 中的這些要求，以便它們能夠升級到未來的平台版本
    • 必須符合 Android API 中詳細介紹的 Android 感測器座標系（請參閱 [參考資料，41 ]）
    • 必須能夠在任何三維向量上測量從自由落體到兩倍重力 (2g) 或更多的情況
    • 必須具有 8 位或更高的精度
    • 標準差必須不大於 0.05 m/s^2

    7.3.2.磁力計

    設備實現應該包括 3 軸磁力計（即指南針）。如果設備確實包括 3 軸磁力計，則：

    • 必須能夠以 10 Hz 或更高頻率傳送事件
    • 必須符合 Android API 中詳細介紹的 Android 感測器座標系（請參閱 [參考資料，41 ]）。
    • 必須能夠對足以覆蓋地磁場的一系列場強進行採樣
    • 必須具有 8 位或更高的精度
    • 標準差必須不大於 0.5 µT

    7.3.3.全球定位系統

    設備實作應該包括 GPS 接收器。如果裝置實作確實包含 GPS 接收器，則它應該包含某種形式的「輔助 GPS」技術，以最大限度地減少 GPS 鎖定時間。

    7.3.4.陀螺儀

    設備實現應包括陀螺儀（即角度變化感測器）。設備不應包括陀螺儀感測器，除非還包括 3 軸加速度計。如果設備實作包含陀螺儀，則：

    • 必須進行溫度補償
    • 必須能夠測量高達 5.5*Pi 弧度/秒（即每秒約 1,000 度）的方向變化
    • 應能以 200 Hz 或更高頻率傳送事件。請注意，雖然上面的陀螺儀頻率在 Android 4.2 中被指定為“應該”，但未來版本的兼容性定義計劃將其更改為“必須”。也就是說，這些標準在 Android 4.2 中是可選的，但在未來版本中將是必要的。強烈鼓勵運行 Android 4.2 的現有設備和新設備滿足 Android 4.2 中的這些要求，以便它們能夠升級到未來的平台版本
    • 必須具有 12 位元或更高的精度
    • 每 Hz 的變異數不得大於 1e-7 rad^2 / s^2（每 Hz 的方差，或 rad^2 / s）。方差允許隨取樣率變化，但必須受此值的約束。換句話說，如果以 1 Hz 取樣率測量陀螺儀的方差，則其方差不應大於 1e-7 rad^2/s^2。
    • 時間戳必須盡可能接近硬體事件發生的時間。必須消除恆定的延遲。

    7.3.5.晴雨表

    設備實現可能包括晴雨表（即環境氣壓感測器）。如果設備實現包括晴雨表，則包括：

    • 必須能夠在5 Hz或更高的情況下提供活動
    • 必須具有足夠的精度才能估算高度
    • 必須補償溫度

    7.3.7.溫度計

    設備實現可能但不應包括溫度計（IE溫度感測器）。如果設備實現確實包括溫度計，則必須測量設備CPU的溫度。它不能測量任何其他溫度。 （請注意，該感測器類型是在Android 4.2 API中棄用的）。

    7.3.7.光度計

    設備實現可能包括光度計（即環境光感測器。）

    7.3.8.接近感測器

    設備實現可能包括接近感測器。如果設備實現確實包括接近感測器，則必須在與螢幕相同的方向上測量物件的接近度。也就是說，必須將接近感測器定向以檢測靠近螢幕的對象，因為該感測器類型的主要目的是檢測使用者使用的手機。如果裝置實作包括具有任何其他方向的接近感測器，則不得透過此API存取它。如果設備實現具有接近性感測器，則必須具有1位元準確性或更高。

    7.4.數據連接

    7.4.1.電話

    Android 4.2 API所使用的「電話」和本文檔特別指的是與使用GSM或CDMA網路傳送SMS訊息有關的硬體。儘管這些語音呼叫可能會切換或可能不會切換，但它們是為了使用Android 4.2，被認為是獨立於使用相同網路實現的任何資料連接性的。換句話說，Android「電話」功能和API專門指的是語音通話和SMS；例如，無法放置通話或傳送/接收SMS訊息的裝置實作不得報告「 android.hardware.telephony」功能或任何子功能，無論它們是否使用蜂巢式網路進行資料連接。

    Android 4.2可以在不包括電話硬體的裝置上使用。也就是說，Android 4.2與不是電話的裝置相容。但是，如果設備實作確實包括GSM或CDMA電話，則必須為該技術實施全面支援。不包括電話硬體的設備實作必須將完整的API作為NO-OPS實作。

    7.4.2. IEEE 802.11（無線網路）

    Android 4.2裝置實作應包括對802.11的一種或多種形式的支援（B/G/A/N等），如果裝置實作確實包括對802.11的支持，則必須實作對應的Android API。

    設備實作必須如SDK文檔[資源，62 ]中所述實作多播API。確實包括WiFi支援的設備實作必須支援多播DNS（MDN）。設備實作不得在操作的任何時間過濾MDNS資料包（224.0.0.251），包括螢幕不處於作用中狀態時。

    7.4.2.1.無線直連

    設備實作應包括對WiFi Direct（WiFi peer-to-Peer）的支援。如果裝置實作確實包括對WiFi Direct的支持，則必須如SDK文件[資源，68 ]中所述實作對應的Android API。如果裝置實作包含對WiFi Direct的支持，則IT：

    • 必須支援常規WiFi操作
    • 應支援並發WiFi和WiFi直接操作

    7.4.3.藍牙

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

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

    7.4.4.近場通訊

    設備實作應包括用於近場通訊（NFC）的收發器和相關硬體。如果設備實現確實包括NFC硬件，則它：

    • 必須從android.content.pm.PackageManager.hasSystemFeature()方法報告Android.hardware.nfc功能。 [資源，37 ]
    • 必須能夠透過以下NFC標準閱讀和編寫NDEF訊息：
      • 必須能夠透過以下NFC標準充當NFC論壇讀者/作者（NFC論壇技術規格NFCFORUM-TS-DIGITAL-PROTOCOCOL-1.0）：
        • NFCA（ISO14443-3A）
        • NFCB（ISO14443-3B）
        • NFCF（JIS 6319-4）
        • ISODEP（ISO 14443-4）
        • NFC論壇標籤類型1、2、3、4（由NFC論壇定義）
    • 應該能夠透過以下NFC標準讀取和編寫NDEF訊息。請注意，儘管下面的NFC標準表示為Android 4.2的“應該”，但計劃將未來版本的兼容性定義更改為“必須”。也就是說，這些標準在Android 4.2中是可選的，但將來需要在以後的版本中。強烈鼓勵運行Android 4.2的現有和新設備在Android 4.2中滿足這些要求，以便他們能夠升級到將來的平台發行。
      • NFCV（ISO 15693）
    • 必須能夠透過以下對等標準和協定傳輸和接收資料：
      • ISO 18092
      • LLCP 1.0（由NFC論壇定義）
      • SDP 1.0（由NFC論壇定義）
      • NDEF推動協議[資源，43 ]
      • SNEP 1.0（由NFC論壇定義）
    • 必須包括對Android Beam的支援[資源，65 ]：
      • 必須實作SNEP預設伺服器。預設SNEP伺服器接收到的有效NDEF訊息必須使用Android.nfc.action_ndef_discovered意圖將其派往應用程式。在設定中停用Android Beam不得停用傳入的NDEF訊息。
      • 裝置實作必須尊重android.settings.nfcsharing_settings，目的是顯示NFC共享設定[ Resources，67 ]。
      • 必須實作NPP伺服器。 NPP伺服器接收的訊息必須與SNEP預設伺服器相同。
      • 必須實作SNEP客戶端，並嘗試在啟用Android Beam時將出站P2P NDEF傳送到預設的SNEP伺服器。如果找不到預設的SNEP伺服器，則客戶端必須嘗試傳送到NPP伺服器。
      • 必須允許前景活動使用android.nfc.nfcadapter.setndefpushmessage和android.nfc.nfc.nfcadapter.setndeppushmessagecallback，and android.nfc.nfc.nfc.nfc.nfcadapter.enable.enable.enableforerforefforpush。
      • 在發送出站P2P NDEF訊息之前，應使用手勢或螢幕上的確認，例如「觸控梁」。
      • 預設應啟用Android Beam
      • 當裝置支援藍牙物件推送設定檔時，必須支援NFC連線交接到藍牙。使用android.nfc.nfcadapter.setbeampushuris時，設備實現必須支援連接移交給藍牙的連接交接，透過實現「連接移交版1.2」 [ Resources，60 ]和「使用NFC版本1.0的藍牙安全簡單配對， NFC論壇。這樣的實作應使用SNEP取得請求，以透過NFC交換移交請求 /選擇記錄，並且必須使用藍牙物件推送設定檔進行實際的藍牙資料傳輸。
    • 必須在NFC發現模式下對所有支援的技術進行輪詢。
    • 當裝置醒著時，螢幕處於活動狀態並解鎖鎖定螢幕時，應處於NFC發現模式。

    （請注意，上述引用的JIS，ISO和NFC論壇規格不可公開可用的連結。）

    此外，設備實作可能包括讀者/作者支援以下Mifare技術。

    請注意，Android 4.2包括這些Mifare類型的API。如果裝置實作支援讀者/作者角色中的Mifare，則它：

    • 必須實作Android SDK記錄的相應的Android API
    • 必須從android.content.pm.PackageManager.hasSystemFeature()方法報告功能com.nxp.mifare。 [ Resources，37 ]請注意，這不是標準的Android功能，因此在PackageManager類別中並未作為常數。
    • 不得實現相應的Android API，也不必須報告Com.nxp.Mifare功能，除非它也如本節所述實現一般NFC支持

    如果設備實作不包括NFC硬件，則不得從android.content.pm.PackageManager.hasSystemFeature()方法[ Resources，37 ]聲明Android.hardware.nfc功能，並且必須實作Android 4.2 NFC API作為Android 4.2 NFC API一個no -op。

    如同類別android.nfc.NdefMessage和android.nfc.NdefRecord代表獨立於協定的資料表示格式一樣，裝置實作即使它們不包括對NFC的支援或宣告Android.hardware.nfc功能，裝置實作也必須實作這些API。

    7.4.5。最低網路能力

    設備實作必須包括對一種或多種形式的資料網路的支援。具體而言，設備實作必須包括至少一個能夠為200kbit/sec或更高的資料標準的支援。滿足此要求的技術的範例包括Edge，HSPA，EV-DO，802.11g，乙太網路等。

    實體網路標準（例如乙太網路）是主要資料連接的設備實作還應包括至少一種常見的無線資料標準，例如802.11（WiFi）。

    設備可以實現多種形式的數據連接。

    7.5。相機

    設備實現應包括後置攝像頭，並可能包括前置攝像頭。後置相機是位於顯示器對面裝置側面的相機。也就是說，它像傳統的相機一樣在設備的另一側拍攝場景。前置鏡頭是與顯示器相同的相機。也就是說，通常用於對使用者進行映像的相機，例如視訊會議和類似的應用程式。

    7.5.1.後置攝像頭

    設備實現應包括後置攝像頭。如果設備實現包括後置攝像頭，則它：

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

    7.5.2.前置鏡頭

    設備實現可能包括前置鏡頭。如果設備實現包括前置鏡頭，則它：

    • 必須具有至少VGA的解析度（即640x480像素）
    • 不得將前置鏡頭用作相機API的預設值。也就是說，Android 4.2中的相機API對前置攝影機具有特定的支持，且裝置實作不得配置API以將前置攝影機視為預設的後置鏡頭，即使它是唯一的相機裝置。
    • 如第7.5.1節所述，可能包括可用於後置攝影機的功能（例如自動對焦，快閃記憶體等）。
    • 必須水平反射（即鏡像）應用程式中的應用顯示的流，如下所示：
      • 如果裝置實作能夠由使用者旋轉（例如，透過加速度計或透過使用者輸入手動旋轉），則相對於裝置的目前方向，攝影機預覽必須水平鏡像。
      • 如果目前應用程式已明確要求透過呼叫android.hardware.Camera.setDisplayOrientation() [ Resources，50 ]方法旋轉相機顯示器，則相對於應用程式指定的方向，攝影機預覽必須水平鏡像。
      • 否則，必須沿著設備的預設水平軸鏡像預覽。
    • 必須以與攝影機預覽影像串流相同的方式鏡像影像顯示的影像。 （如果設備實作不支援PostView，則此要求顯然不適用。）
    • 一定不能鏡像返回應用程式回調或致力於媒體儲存的最終捕獲的靜止圖像或視訊串流

    7.5.3.相機 API 行為

    裝置實作必須針對攝影機相關的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 編碼格式。也就是說，NV21必須是預設值。
    3. 裝置實作必須支援YV12格式（如android.graphics.ImageFormat.YV12常數所表示），以用於前置和後方攝影機的攝影機預覽。 （硬體視訊編碼器和相機可能使用任何本機像素格式，但是設定實作必須支援轉換為YV12。）

    裝置實作必須實作Android 4.2 SDK文件中包含的完整相機API [資源，51 ]），無論裝置是否包含硬體自動對焦或其他功能。例如，缺乏自動對焦的攝影機仍然必須呼叫任何已註冊的android.hardware.Camera.AutoFocusCallback實例（即使這與非Autofocus相機無關，請注意）請注意，這確實適用於前面的相機；例如，即使大多數面向前置的攝影機不支援自動對焦，但API回呼仍然必須如所述「偽造」。

    裝置實作必須識別並尊重每個參數名稱，該名稱在android.hardware.Camera.Parameters類別上定義為常數，如果基礎硬體支援該功能。如果設備硬體不支援功能，則API必須依照記錄。相反，裝置實作不得尊重或識別傳遞給android.hardware.Camera.setParameters()方法的字串常數，而不是在android.hardware.Camera.Parameters上記錄為常數的字串。也就是說，如果硬體允許，則必須支援所有標準攝影機參數，並且必須不支援自訂相機參數類型。例如，使用高動態範圍（HDR）成像技術支援影像擷取的裝置實作必須支援相機參數攝影機Camera.SCENE_MODE_HDR [ Resources，78 ]）。

    每當相機拍攝新圖片並將圖片的輸入添加到媒體商店時， Camera.ACTION_NEW_PICTURE實現必須廣播相機。

    每當相機記錄新影片並將圖片的輸入加入媒體商店時，設備實作必須廣播Camera.ACTION_NEW_VIDEO 。

    7.5.4.相機方向

    前後相機（如果存在）都必須定向，以使攝影機的長度尺寸與螢幕的長尺寸對齊。也就是說，當設備保持在景觀方向時，相機必須在景觀方向上捕捉影像。無論設備的自然取向如何，這都適用；也就是說，它適用於景觀主要設備以及肖像主要設備。

    7.6。記憶體和儲存

    7.6.1.最小內存和存儲

    設備實作必須至少具有340MB的記憶體可用於核心和用戶空間。 340MB必須是專用於硬體組件（例如無線電，視訊等）的任何記憶體的補充。

    裝置實作必須至少具有350MB的非揮發性儲存空間，可用於應用程式私人資料。也就是說， /data分區必須至少為350MB。

    Android API包含一個下載管理器，應用程式可以用來下載資料檔[資源，56 ]。下載管理器的裝置實作必須能夠下載至少100MB大小的單一檔案到預設的「快取」位置。

    7.6.2.應用程式共享儲存

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

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

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

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

    無論使用的共享儲存的形式如何，設備實作都必須提供一些機制，以存取主機電腦共享儲存的內容，例如USB品質儲存（UMS）或媒體傳輸協定（MTP）。設備實現可能使用USB品質存儲，但應使用媒體傳輸協定。如果設備實現支援媒體傳輸協定：

    • 設備實作應與參考Android MTP主機，Android檔案傳輸[資源，57 ]相容。
    • 設備實作應報告0x00的USB設備類別。
    • 設備實作應報告“ MTP”的USB介面名稱。

    如果設備實現缺乏USB端口，則必須為主機提供透過某些其他方式（例如網路檔案系統）存取共用儲存的內容。

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

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

    7.7. USB

    設備實現應包括USB客戶端端口，並應包括USB主機端口。

    如果設備實作包括USB客戶端連接埠：

    • 此連接埠必須與具有標準USB-A連接埠的USB主機連接
    • 連接埠應在裝置側使用Micro USB外型。強烈鼓勵運行Android 4.2的現有和新設備在Android 4.2中滿足這些要求，以便他們能夠升級到將來的平台發行版
    • 端口應以邊緣中間為中心。設備實現應在設備底部（根據自然取向）定位端口，或啟用所有應用程式（包括主螢幕）的軟體螢幕旋轉，以便當設備在底部的端口定向時，顯示屏正確繪製。強烈鼓勵運行Android 4.2的現有和新設備在Android 4.2中滿足這些要求，以便它們能夠升級到將來的平台版本。
    • 如果裝置具有其他連接埠（例如非USB充電埠），則應與Micro-USB連接埠相同
    • 它必須允許連接到裝置的主機使用USB品質儲存或媒體傳輸協定存取共用儲存磁碟區的內容
    • 它必須按照Android SDK文件中記錄的Android開放配件API和規範，並且必須聲明對硬體功能的支援android.hardware.usb.accessory [ Resources，52 ]
    • 它必須依照Android SDK文檔[資源，66 ]中記錄的USB音訊類實作USB音訊類
    • 它應該為USB電池充電規格提供支援[資源，64 ]現有的和新的Android 4.2的新設備，非常強烈地鼓勵在Android 4.2中滿足這些要求，以便他們能夠升級到將來的平台發行版

    如果設備實作包括USB主機連接埠：

    • 它可能會使用非標準的連接埠外形，但是如果必須運送電纜或電纜，則將連接埠適應標準USB-A
    • 它必須按照Android SDK中記錄的Android USB主機API實現，並且必須聲明對硬體功能android.hardware.usb.host的支援[ Resources，53 ]

    設備實作必須實現Android調試橋。如果設備實作省略了USB客戶端端口，則必須透過本地區域網路實現Android調試橋（例如乙太網路或802.11）

    8. 效能相容性

    裝置實作必須符合下表中定義的Android 4.2相容裝置的關鍵效能指標：

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

    9. 安全模型相容性

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

    9.1.權限

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

    9.2. UID 和進程隔離

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

    9.3.檔案系統權限

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

    9.4.備用執行環境

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

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

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

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

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

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

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

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

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

    9.5。多用戶支援

    Android 4.2包括對多個用戶的支持，並為完整的用戶隔離提供了支持[ Resources，70 ]。

    設備實作必須滿足與多用戶支援有關的這些要求[資源，71 ]：

    • 由於目前未定義的裝置上的電話API在裝置上的行為是未定義的，因此聲明Android.hardware.telephony的裝置實作不得啟用多用戶支援。
    • 設備實作必須針對每個用戶，實作與APIS中的安全性和權限參考文獻文件中定義的Android平台安全模型一致的安全模型[Resources，54]

    Android裝置上的每個使用者實例都必須具有獨立且孤立的外部儲存目錄。設備實作可能會在同一磁碟區或檔案系統上儲存多個使用者的資料。但是，設備實作必須確保給定用戶代表和運行的應用程式無法列出，讀取或寫入任何其他用戶擁有的資料。請注意，可移動的媒體（例如SD卡插槽）可以允許一個使用者透過主機PC存取另一個使用者的資料。因此，如果僅使用僅儲存在系統的不可拆卸媒體上的金鑰啟用了多用戶，則將使用可移動媒體用於外部儲存API的裝置實現必須加密SD卡的內容。由於這將使主機PC無法閱讀媒體，因此將需要裝置實作來切換到MTP或類似系統，以便為主機PC提供存取目前使用者資料的存取。因此，如果設備實作使用可移動媒體[資源，72 ]進行主外部存儲，則可以但不應啟用多用戶。上游Android開源專案包括一個將內部設備儲存用於應用程式外部儲存API的實作；設備實現應使用此配置和軟體實現。包括多個外部儲存路徑的裝置實作不得允許Android應用程式寫入次要外部存儲

    9.6.高級簡訊警告

    Android 4.2包括警告用戶的支持，以提供任何即將上市的高級SMS訊息。高級SMS訊息是發送到使用運營商註冊的服務的短信，該服務可能會向用戶收取費用。聲明支援android.hardware.telephony的裝置實作必須警告用戶，然後將SMS訊息傳送到裝置中定義的/data/misc/sms/codes.xml表示式識別的數字。上游Android開源專案提供了滿足此要求的實作。

    10.軟體相容性測試

    設備實作必須通過本節中所述的所有測試。

    但是，請注意，沒有軟體測試軟體包是完全全面的。因此，非常強烈鼓勵設備實施者對Android開源專案可用的Android 4.2的參考，並首選實現Android 4.2的最小變更。這將最大程度地降低引入錯誤的風險，從而創建不相容，需要返工和潛在的設備更新。

    10.1.相容性測試套件

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

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

    10.2. CTS驗證器

    設備實作必須正確執行CTS驗證者中的所有適用案例。 CTS驗證儀包含在相容性測試套件中，旨在由人類操作員運行，以測試無法通過自動化系統測試的功能，例如相機和感測器的正確功能。

    CTS驗證儀對許多硬體進行了測試，包括一些可選的硬體。設備實現必須透過其擁有的硬體進行所有測試；例如，如果裝置具有加速度計，則必須在CTS驗證器中正確執行加速度計測試案例。可以跳過或省略此相容性定義文件所指出的功能的測試案例。

    如上所述，每個設備和每個建置都必須正確運行CTS驗證器。但是，由於許多建置非常相似，因此不會期望裝置實作者明確地在僅以微不足道的方式上建置的CTS驗證器。具體而言，與僅通過包含的語言環境，品牌等透過CTS Verfier的實現不同的實現的設備實現可能會省略CTS驗證器測試。

    10.3.參考應用

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

    • 「用於Android的應用程式」應用程式[資源，55 ]
    • 複製島（在Android市場上可用）

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

    11. 可更新的軟體

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

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

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

    所使用的更新機制必須支援更新，而無需擦除使用者資料。也就是說，更新機制必須保留應用程式私人資料和應用程式共享資料。請注意，上游Android軟體包括滿足此要求的更新機制。

    如果在發布後在設備實作中發現錯誤，但在其合理的產品壽命內與Android相容性團隊協商確定以影響第三方應用程式的相容性，則裝置實作者必須透過軟體修正錯誤可根據剛才描述的機制應用的更新。

    12. 聯絡我們

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

    附錄 A - 藍牙測試程序

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

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

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

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

    設定和安裝

    1. 從Android源代碼樹中構建bluetoothchat.apk通過“製作樣品”
    2. 在已知的裝置上安裝bluetoothchat.apk
    3. 在候選設備上安裝bluetoothchat.apk

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

    1. 在候選裝置上啟動Bluetoothchat，而停用藍牙
    2. 驗證候選設備要么打開藍牙，要么透過對話框提示使用者開啟藍牙

    測驗配對和交流

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

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

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

    測試重新發布

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

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