Android 7.0 (N) 相容性定義

目錄

1. 引言

本文件列舉讓裝置與 Android 7.0 相容，必須符合哪些規定。

根據 RFC2119 定義的 IETF 標準，使用「必須」、「不得」、「必要」、「應」、「不應」、「不應」、「建議」、「建議」、「可能」和「選用」用法。

如本文件所述，「裝置實作者」或「實作器」是指開發搭載 Android 7.0 的硬體/軟體解決方案的個人或機構。「裝置導入」或「實作」是指所開發的硬體/軟體解決方案。

裝置實作方式「必須」符合此相容性定義中的規定，包括透過參考資料納入的任何文件，才能符合 Android 7.0 相容性標準。

如果這項定義或第 10 節所述的軟體測試沒有回應、不明確或不完整，裝置實作人員必須負責確保與現有實作的相容性。

因此，Android 開放原始碼計畫既是 Android 的建議做法，也是建議採用的實作方式。我們強烈建議裝置實作者盡可能根據 Android 開放原始碼計畫提供的「上游」原始碼進行實作。雖然部分元件可能會被假裝替換為其他實作項目，但強烈建議不要遵循這種做法，因為傳遞軟體測試會變得更加困難。實作者有責任確保與標準 Android 實作項目完全相容，包括 Compatibility Test Suite。最後，請注意，本文件明確禁止特定元件的替換和修改內容。

本文件中所連結的許多資源都是直接或間接從 Android SDK 衍生，運作方式與 SDK 說明文件中的資訊相同。無論此 Compatibility Definition 或 Compatibility Test Suite 無法認同 SDK 說明文件，皆可視為具有權威性的 SDK 說明文件。本文連結的所有資源中提供的技術細節都會納入此相容性定義。

2. 裝置類型

我們使用 Android 開放原始碼計畫來實作各種裝置類型和板型規格，但架構和相容性規範的許多面向都已針對手持裝置進行最佳化。從 Android 5.0 開始，Android 開放原始碼計畫旨在採用本節所述的更多裝置類型。

Android 手持裝置是指通常手持裝置所用的 Android 裝置實作項目，例如 mp3 播放器、手機和平板電腦。Android 手持裝置實作：

  • 「必須」在裝置上內嵌觸控螢幕。
  • 應使用可提供行動用的電源，例如電池。

Android 電視裝置是一種 Android 裝置實作服務，屬於娛樂介面，可供距離約十英尺 (一個「向後」或「10 英尺」的使用者介面) 的使用者觀看數位媒體、電影、遊戲、應用程式和/或電視直播內容。Android TV 裝置：

  • 「必須」有內嵌螢幕，「或」設有視訊輸出連接埠，例如 VGA、HDMI 或顯示螢幕的無線連接埠。
  • 「必須」宣告 android.software.leanback 和 android.hardware.type.television 功能。

Android Watch 裝置是指用於戴在身體 (可能佩戴在手腕) 的 Android 裝置實作，且：

  • 您的螢幕必須有實體對角線長度，範圍介於 1.1 到 2.5 吋之間。
  • 必須宣告 android.hardware.type.watch 功能。
  • 必須支援 uiMode = UI_MODE_TYPE_WATCH。

Android Automotive 實作是指搭載 Android 做為部分或所有系統和/或資訊娛樂功能的車輛車用運算主機。Android Automotive 實作：

  • 螢幕的實際對角線長度必須大於或等於 6 吋。
  • 必須宣告 android.hardware.type.automotive 功能。
  • 必須支援 uiMode = UI_MODE_TYPE_CAR。
  • Android Automotive 實作項目「必須」支援 android.car.* 命名空間中的所有公用 API。

凡是不適用於上述任一裝置類型的所有 Android 裝置實作項目，仍「必須」符合本文件中的所有規定，才能與 Android 7.0 相容，除非上述規定明確指出僅適用於上述特定 Android 裝置類型。

2.1 裝置設定

以下摘要說明各裝置類型的硬體設定主要差異。(空白儲存格表示「MAY」)。下表並未涵蓋所有設定。請參閱相關硬體章節以瞭解詳情

類別 功能與特色 章節 手持式 電視 手錶型 汽車業 其他
輸入資料 D-Pad 7.2.2.非觸控式導覽 必須
觸控螢幕 7.2.4.觸控螢幕輸入 必須 必須 應
麥克風 7.8.1.麥克風 必須 應 必須 必須 應
感應器 加速計 7.3.1 加速計 應 應 應
全球衛星定位系統 (GPS) 7.3.3.GPS 應 應
網路與數據傳輸 Wi-Fi 7.4.2.IEEE 802.11 應 應 應 應
Wi-Fi Direct 7.4.2.1.Wi-Fi Direct 應 應 應
藍牙 7.4.3.藍牙 應 必須 必須 必須 應
藍牙低功耗 7.4.3.藍牙 應 必須 應 應 應
行動無線電 7.4.5.最低網路功能 應
USB 週邊裝置/主機模式 7.7.USB 應 應 應
輸出孔類型 喇叭和/或音訊輸出連接埠 7.8.2.音訊輸出 必須 必須 必須 必須

3. 軟體

3.1. 代管 API 相容性

代管的 Dalvik 位元碼執行環境是 Android 應用程式的主要工具。Android 應用程式設計介面 (API) 是一組 Android 平台介面，會向在代管執行階段環境中執行的應用程式公開。裝置實作「必須」針對由 Android SDK 公開的任何 API 所記錄的 API，或是上游 Android 原始碼中以「@SystemApi」標記裝飾的任何 API 提供完整實作，包括所有記載的行為。

裝置實作項目「必須」支援/保留 TestApi 註解 (@TestApi) 標示的所有類別、方法和相關元素。

裝置實作項目「不得」省略任何受管理的 API、變更 API 介面或簽名、偏離記錄的行為，或納入免人工管理 (除非這個相容性定義明確允許)。

這項相容性定義允許某些類型的硬體用於 Android 裝置，包括裝置實作時省略的 API。在這種情況下，這些 API「必須」仍存在且會以合理的方式運作。如要瞭解這個情境的具體需求，請參閱第 7 節。

3.1.1. Android 擴充功能

Android 支援擴充代管 API，同時保持相同的 API 級別版本。Android 裝置實作項目「必須」預先載入共用程式庫 ExtShared 和服務的 ExtServices 開放原始碼計畫實作項目，且版本必須高於或等於每個 API 級別允許的最低版本。舉例來說，針對 Android 7.0 裝置實作項目，搭載 API 級別 24 的裝置「必須」包含至少 1 版。

3.2. 軟 API 相容性

除了第 3.1 節中的代管 API 外，Android 也包含重要的執行階段專用「soft」API，其形式包括意圖、權限，以及 Android 應用程式編譯時無法強制執行的類似功能。

3.2.1. 權限

裝置實作者「必須」支援及強制執行所有權限常數 (如權限參考資料頁面所述)。請注意，第 9 節列出了與 Android 安全性模型相關的其他規定。

3.2.2。版本參數

Android API 在 android.os.Build 類別中加入多個常數，用於描述目前裝置。如要在各種裝置導入方式上提供一致且有意義的值，下表針對這些值採用的裝置導入方式，列出了相關的額外限制。

參數 詳細資料
版本 目前執行 Android 系統的版本，採用人類可讀的格式。這個欄位必須包含 7.0 中定義的其中一個字串值。
SDK 版本 目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 7.0，這個欄位「必須」含有 7.0_INT 整數值。
VERSION.SDK_INT 目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 7.0，這個欄位「必須」含有 7.0_INT 整數值。
版本 裝置實作人員選擇的值，以人類可讀的格式指定目前執行 Android 系統的特定版本。使用者可用的不同版本「不得」重複使用這個值。這個欄位的常見用途是指出用於產生建構作業的版本號碼或原始碼控制變更 ID。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
遊戲板 裝置實作人員選擇的值，以人類可讀的格式識別裝置所使用的特定內部硬體。這個欄位的可能用途，是指出裝置供電的主機板特定修訂版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
品牌 這個值代表使用者所已知與裝置相關的品牌名稱。必須採用人類可讀的格式，且應代表裝置的製造商或銷售裝置的公司品牌。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
支援濫用 原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
支援 32_BIT_ABIS 原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
支援 64_BIT_ABIS 原生程式碼的第二個指令集 (CPU 類型 + ABI 慣例) 的名稱。請參閱第 3.3 節。原生 API 相容性。
CPU_ABI 原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
CPU_ABI2 原生程式碼的第二個指令集 (CPU 類型 + ABI 慣例) 的名稱。請參閱第 3.3 節。原生 API 相容性。
裝置 裝置實作者選擇的值，內含可識別硬體功能和工業設計裝置的開發名稱或代碼名稱。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。在產品的生命週期中，此裝置名稱「不得」變更。
指紋 專門用於識別此版本的字串。產品必須清晰可讀。請務必遵循以下範本：

$(品牌)/$(PRODUCT)/
$(裝置)：$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL)：$(TYPE)/$(TAGS)

例如：

acme/myproduct/
mydevice:7.0/LMYXX/3359:userdebug/test-keys

指紋「不得」包含空白字元。如果上述範本中的其他欄位含有空白字元，則這些欄位「必須」在建構指紋中替換成其他字元，例如底線 (「_」) 字元。這個欄位的值必須能以 7 位元 ASCII 編碼。

硬體 硬體的名稱 (從核心指令列或 /proc)。產品必須合理人類可讀。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
主機 用於識別建構建構所在主機的專屬字串，並且採用人類可讀的格式。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
印尼 裝置實作人員選擇用來參照特定版本的 ID，採用人類可讀的格式。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但值應足以讓使用者區分不同軟體版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
製造商 產品的原始設備製造商 (OEM) 商標名稱。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
機型 由裝置實作者選擇的值，內含使用者已知的裝置名稱。這個名稱必須與用來行銷和向使用者銷售裝置的名稱相同。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
產品 由裝置實作者選擇的值，內含特定產品 (SKU) 的開發名稱或代碼名稱，但該產品在同一個品牌中不得重複。必須是人類可讀的內容，但不一定能供使用者查看。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。在產品效期內，這個產品名稱「不得」變更。
序號 硬體序號，該序號必須專屬於具有相同型號和製造商的所有裝置。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^([a-zA-Z0-9]{6,20})$」。
標記 由裝置實作工具選擇的標記清單 (以半形逗號分隔)，可進一步區分版本。這個欄位「必須」設有其中一個值，對應三種一般 Android 平台簽署設定：release-keys、dev-keys、test-keys。
時間 代表建構發生時間的時間戳記的值。
類型 裝置實作者選擇的值，用於指定版本的執行階段設定。這個欄位「必須」設有其中一個值，對應三種一般 Android 執行階段設定：user、userdebug 或 eng。
使用者 產生版本的使用者 (或自動化使用者) 名稱或使用者 ID。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
安全快門 表示版本安全性修補程式等級的值。「必須」表示該版本沒有任何安全漏洞，可影響到指定 Android 公開安全性公告所述的任何問題。請採用 [YYYY-MM-DD] 的格式，與 Android 公開安全性公告或 Android 安全性補充公告中所列出的定義字串相符，例如「2015-11-01」。
BASE_OS 此值代表版本 (FINGERPRINT) 的 FINGERPRINT 參數，與此版本相同 (Android 公開安全性公告提供的修補程式除外)。它必須回報正確的值，如果這類版本不存在，請回報空字串 ("")。

3.2.3.意圖相容性

3.2.3.1。核心應用程式意圖

Android 意圖可讓應用程式元件要求其他 Android 元件的功能。Android 上游專案含有一系列被視為 Android 核心應用程式的應用程式，這些應用程式會實作多種意圖模式來執行常用動作。核心 Android 應用程式如下：

  • 桌上時鐘
  • 瀏覽器
  • 日曆
  • 聯絡人
  • 圖片庫
  • 全域搜尋
  • 啟動器
  • Music (音樂)
  • 設定

裝置實作項目「必須」適當加入核心 Android 應用程式，或加入實作相同意圖模式的元件 (這些核心 Android 應用程式要公開給其他應用程式的活動或服務元件定義相同，以隱含或明確的方式顯示在 android:exported 屬性中)。

3.2.3.2。意圖解決方案

由於 Android 是可擴充平台，裝置實作「必須」允許第三方應用程式覆寫第 3.2.3.1 節所列的每個意圖模式。根據預設，上游 Android 開放原始碼實作允許執行這項操作；裝置實作人員「不得」將特殊權限附加至系統應用程式使用這些意圖模式，或避免第三方應用程式繫結和假設這些模式。這項禁令包括但不限於停用「選擇工具」使用者介面，讓使用者在處理相同意圖模式的多個應用程式之間選取所需項目。

裝置實作「必須」提供使用者介面，讓使用者修改意圖的預設活動。

不過，如果預設活動為資料 URI 提供了更明確的屬性，裝置實作可能會針對特定 URI 模式 (例如 http://play.google.com) 提供預設活動。例如，指定資料 URI「http://www.android.com」的意圖篩選器模式，會比瀏覽器的核心意圖模式「http://」更明確。

Android 也提供第三方應用程式，能夠針對特定類型的網路 URI 意圖，宣告具有公信力的預設應用程式連結行為。如果應用程式的意圖篩選器模式定義了這類權威宣告，裝置實作方式會：

  • 「必須」嘗試執行 Digital Asset Links 規格定義的驗證步驟 (如上游 Android 開放原始碼專案中的套件管理員實作)，藉此驗證任何意圖篩選器。
  • 「必須」在安裝應用程式時嘗試驗證意圖篩選器，並將所有成功驗證的 UIR 意圖篩選器設為 UIR 的預設應用程式處理常式。
  • 如果成功驗證，但其他候選 URI 篩選器驗證失敗，可以將其特定 URI 意圖篩選器設為其 URI 的預設應用程式處理常式。如果裝置採用這種做法，就「必須」在設定選單中提供使用者適當的個別 URI 模式覆寫值。
  • 「設定」必須依下列方式，在「設定」中提供個別應用程式的應用程式連結控制項：
    • 使用者「必須」能全面覆寫應用程式的預設應用程式連結行為：一律開啟、一律詢問或一律不開啟，而且此動作必須同樣套用至所有候選 URI 意圖篩選器。
    • 使用者「必須」可以查看候選 URI 意圖篩選器的清單。
    • 裝置實作「可能」可讓使用者依個別意圖篩選器，覆寫已成功驗證的特定候選 URI 意圖篩選器。
    • 如果裝置可讓某些候選 URI 意圖篩選器成功驗證，而某些候選 URI 意圖篩選器可成功驗證，則裝置實作「必須」能夠讓使用者查看及覆寫特定候選 URI 意圖篩選器。

3.2.3.3.意圖命名空間

裝置實作項目「不得」包含任何採用 Android 中 ACTION、CATEGORY 或其他按鍵字串的新意圖或廣播意圖模式的 Android 元件。或 com.android. 命名空間。裝置實作者「不得」包含任何 Android 元件，這類元件會在屬於其他機構的套件空間中使用 ACTION、CATEGORY 或其他金鑰字串，並遵循任何新意圖或廣播意圖模式。裝置實作者「不得」變更或擴充第 3.2.3.1 節所列的核心應用程式所使用的任何意圖模式。裝置實作方式可能包括使用明顯與自身機構相關聯之命名空間的意圖模式。這項禁令與第 3.6 節中 Java 語言類別所述的類似。

3.2.3.4。廣播意圖

第三方應用程式依賴平台廣播某些意圖，以通知硬體或軟體環境的變更。Android 相容裝置「必須」播送公開廣播意圖，以回應適當的系統事件。如需廣播意圖，請參閱 SDK 說明文件。

3.2.3.5。預設應用程式設定

Android 裝置的設定可讓使用者輕鬆選取預設應用程式，例如主畫面或簡訊。在可行的情況下，裝置實作「必須」提供類似的設定選單，且與以下 SDK 說明文件中所述的意圖篩選器模式和 API 方法相容。

裝置實作方式：

3.3.原生 API 相容性

原生程式碼相容性不高。因此，裝置實作者強烈建議使用上游 Android 開放原始碼計畫中下列程式庫的實作方式。

3.3.1.應用程式二進位檔介面

代管的 Dalvik 位元碼可呼叫應用程式 .apk 檔案中提供的原生程式碼，做為針對適用裝置硬體架構編譯的 ELF .so 檔案。由於原生程式碼高度依賴基礎處理器技術，因此 Android 定義了 Android NDK 中的多個應用程式二進位檔介面 (ABI)。裝置實作項目「必須」與一或多個已定義的 ABI 相容，且「必須」實作與 Android NDK 的相容性，如下所示。

如果裝置實作支援 Android ABI，就會發生以下情況：

  • 「必須」支援在代管環境中執行的程式碼，使用標準 Java Native Interface (JNI) 語意呼叫原生程式碼。
  • 下列清單中的各個必要程式庫必須與原始碼相容 (即與標頭相容) 和二進位檔相容 (適用於 ABI)。
  • 如果支援任何 64 位元 ABI，則必須支援對等的 32 位元 ABI。
  • 「必須」透過 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 參數，準確回報裝置支援的原生應用程式二進位檔介面 (ABI)，並列出各個 ABI，並依偏好程度由高至低排列。
  • 「必須」透過上述參數回報，且只能回報最新版 Android NDK ABI Management 說明文件中記載及描述的 ABI，且「必須」支援進階 SIMD (即 NEON) 擴充功能。
  • 應使用上游 Android 開放原始碼計畫提供的原始碼和標頭檔案建立

請注意，日後推出的 Android NDK 版本可能會支援其他 ABI。如果裝置與現有預先定義的 ABI 不相容，就完全「不得」回報支援任何 ABI。

含有原生程式碼的應用程式「必須」提供下列原生程式碼 API：

  • libandroid.so (原生 Android 活動支援)
  • libc (C 程式庫)
  • libcamera2ndk.so
  • libdl (動態連結器)
  • libEGL.so (原生 OpenGL 介面管理)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • Libicuuc.so
  • libjnigraphics.so
  • liblog (Android 記錄)
  • libmediandk.so (支援原生媒體 API)
  • libm (數學資料庫)
  • libOpenMAXAL.so (OpenMAX AL 1.0.1 支援)
  • libOpenSLES.so (OpenSL ES 1.0.1 音訊支援)
  • libRS.so
  • libstdc++ (最低支援 C++)
  • libvulkan.so (Vulkan)
  • libz (Zlib 壓縮)
  • JNI 介面
  • 支援 OpenGL，如下所述：

針對上述的原生程式庫，裝置實作「不得」新增或移除公用函式。

上方未列出的原生程式庫，但在 Android 開放原始碼計畫中實作並提供，因為系統程式庫是保留的，「不得」向指定 API 級別 24 以上級別的第三方應用程式公開。

裝置實作項目可能會加入非 Android 開放原始碼計畫程式庫，並直接以 API 形式提供給第三方應用程式，但其他程式庫必須位於 /vendor/lib 或 /vendor/lib64 中，且必須列於 /vendor/etc/public.libraries.txt 中。

請注意，裝置的實作「必須」包含 libGLESv3.so，且「必須」匯出 NDK 版本 android-24 中定義的所有 OpenGL ES 3.1 和 Android Extension Pack 函式符號。雖然所有符號必須完整顯示，但裝置實際支援的 OpenGL ES 版本和擴充功能必須完全導入 OpenGL ES 和擴充功能對應的函式。

3.3.1.1。圖形程式庫

Vulkan 是低負載的跨平台 API，適用於高效能 3D 圖形。裝置實作項目即使未支援 Vulkan API，仍必須符合下列規定：

  • 「必須」提供一個名為 libvulkan.so 的原生程式庫，用於匯出核心 Vulkan 1.0 API 的函式符號，以及 VK_KHR_surface 、VK_KHR_android_surface 和 VK_KHR_swapchain 擴充功能。

裝置實作方式 (如果包括對 Vulkan API 的支援)：

  • 必須透過 vkEnumeratePhysicalDevices 呼叫回報或回報一或多個VkPhysicalDevices。
  • 每個列舉的 VkPhysicalDevices 都必須完全實作 Vulkan 1.0 API。
  • 必須回報正確的 PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL 和 PackageManager#FEATURE_VULKAN_HARDWARE_VERSION 功能旗標。
  • 請務必透過 libvulkan.so 中的 vkEnumerateInstanceLayerProperties 和 vkEnumerateDeviceLayerProperties 函式，列舉包含在應用程式套件原生程式庫目錄中名為 libVkLayer*.so 的原生程式庫
  • 除非應用程式具有 android:debuggable=”true” 屬性，否則「不得」列舉應用程式套件以外程式庫提供的層，或提供其他追蹤或攔截 Vulkan API 的方式。

裝置實作方式 (如果沒有支援 Vulkan API)：

3.3.2.32 位元 ARM 原生程式碼相容性

ARMv8 架構淘汰了數種 CPU 作業，包括在現有原生程式碼中使用的部分作業。在 64 位元 ARM 裝置上，下列已淘汰的作業必須繼續提供給 32 位元的原生 ARM 程式碼 (透過原生 CPU 支援或透過軟體模擬)：

  • SWP 和 SWPB 操作說明
  • SETEND 指令
  • CP15ISB、CP15DSB 和 CP15DMB 障礙行動

舊版 Android NDK 使用 /proc/cpuinfo，透過 32 位元 ARM 原生程式碼探索 CPU 功能。為了與使用這個 NDK 建構的應用程式相容，當 32 位元 ARM 應用程式讀取時，裝置「必須」在 /proc/cpuinfo 中加入下列幾行程式碼：

  • 「Features:」，後面加上裝置支援的任何選用 ARMv7 CPU 功能清單。
  • 「CPU 架構：」，後面加上整數，說明裝置支援的 ARM 架構 (例如「8」適用於 ARMv8 裝置)。

這些規定僅適用於 32 位元 ARM 應用程式讀取 /proc/cpuinfo 的情況。透過 64 位元 ARM 或非 ARM 應用程式讀取時，裝置「不得」修改 /proc/cpuinfo。

3.4.網路相容性

3.4.1.WebView 相容性

Android Watch 裝置「可」提供，但所有其他實作的裝置「必須」提供完整的 android.webkit.Webview API 實作項目。

凡是提供 android.webkit.WebView API 完成實作的裝置，都「必須」回報平台功能 android.software.webview。如果裝置尚未完整實作 API，則「不得」回報該平台功能。Android 開放原始碼實作項目會使用 Chromium 專案中的程式碼實作 android.webkit.WebView。由於無法針對網頁轉譯系統開發完整的測試套件，裝置實作者「必須」在實作 WebView 時採用特定的 Chromium 上游版本。詳細說明：

  • 裝置 android.webkit.WebView 的實作方式「必須」以 Android 7.0 上游 Android 開放原始碼計畫中的 Chromium 版本為基礎。這個版本包含 WebView 的特定功能和安全性修正項目。

  • WebView 回報的使用者代理程式字串「必須」採用以下格式：

    Mozilla/5.0 (Linux；Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) 字串的值必須與 android.os.Build.VERSION.RELEASE 的值相同。
    • $(MODEL) 字串的值必須與 android.os.Build.MODEL 的值相同。
    • $(BUILD) 字串的值應與 android.os.Build.ID 的值相同。
    • $(CHROMIUM_VER) 字串的值「必須」是上游 Android 開放原始碼專案中的 Chromium 版本。
    • 裝置導入方式可以在使用者代理程式字串中省略行動裝置。

WebView 元件「必須」盡可能支援最多的 HTML5 功能，如果其支援的功能也必須符合 HTML5 規格。

3.4.2。瀏覽器相容性

Android Television、Watch 和 Android Automotive 實作項目「可能」省略瀏覽器應用程式，但「必須」支援第 3.2.3.1 節所述的公開意圖模式。所有其他類型的裝置都必須包含獨立的瀏覽器應用程式，才能供一般使用者瀏覽網頁。

獨立的瀏覽器可能以 WebKit 以外的瀏覽器技術為基礎。不過，即使採用替代的瀏覽器應用程式，您仍然必須以 WebKit 為基礎提供給第三方應用程式的 android.webkit.WebView 元件，如第 3.4.1 節所述。

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

獨立的瀏覽器應用程式 (無論是以上游 WebKit 瀏覽器應用程式或第三方替代網站) 應盡可能支援 HTML5。基本上，裝置導入作業「必須」支援下列與 HTML5 相關聯的各個 API：

此外，裝置實作項目必須支援 HTML5/W3C webstorage API，且必須支援 HTML5/W3C IndexedDB API。請注意，隨著網頁開發標準機構逐漸改用 IndexedDB，而非 webstorage，未來 Android 版本應將 IndexedDB 成為必要的元件。

3.5.API 行為相容性

每種 API 類型 (代管、軟、原生和網頁) 的行為都必須與上游 Android 開放原始碼計畫的偏好實作方式一致。以下列舉一些相容性的面向：

  • 裝置「不得」變更標準意圖的行為或語意。
  • 裝置不得變更特定類型的系統元件 (例如 Service、Activity、ContentProvider 等) 的生命週期或生命週期語意。
  • 裝置「不得」變更標準權限的語意。

上方清單僅列舉部分例子，並未包含所有可能情況。Compatibility Test Suite (CTS) 會測試平台中的大量行為相容性，但並非全部。實作者應負責確保與 Android 開放原始碼計畫的行為相容性。因此，裝置實作者應盡可能使用 Android 開放原始碼計畫提供的原始碼，而非重新導入系統的重要部分。

3.6.API 命名空間

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

  • java。*
  • javax。*
  • 太陽。*
  • 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 位元碼規格和語意。裝置實作者應使用 ART、Dalvik 執行檔格式的上游參考，以及參考實作的套件管理系統。

裝置實作「必須」設定 Dalvik 執行階段，才能根據上游 Android 平台配置記憶體，詳情請見下表指定內容。(如要瞭解螢幕大小和螢幕密度的定義，請參閱第 7.1.1 節)。請注意，下列指定的記憶體值視為最小值，而裝置實作可能會為個別應用程式配置更多記憶體。

螢幕版面配置 螢幕密度 應用程式記憶體下限
Android Watch 120 dpi (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi) 36MB
280 dpi (280dpi)
320 dpi (xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
小型/標準 120 dpi (ldpi) 32MB
160 dpi (mdpi)
213 dpi (tvdpi) 48MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 dpi (420dpi) 112MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
大 120 dpi (ldpi) 32MB
160 dpi (mdpi) 48MB
213 dpi (tvdpi) 80MB
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (xhdpi) 128MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228MB
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512MB
特大 120 dpi (ldpi) 48MB
160 dpi (mdpi) 80MB
213 dpi (tvdpi) 96MB
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8.使用者介面相容性

3.8.1。啟動器 (主畫面)

Android 提供啟動器應用程式 (主畫面)，以及支援第三方應用程式，可取代裝置啟動器 (主畫面)。允許第三方應用程式替換裝置主畫面的裝置實作方式，「必須」宣告 android.software.home_screen 平台功能。

3.8.2。小工具

小工具適用於所有 Android 裝置實作項目，但必須在 Android 手持裝置裝置上支援。

Android 定義了元件類型和對應的 API 和生命週期，可讓應用程式向使用者公開「AppWidget」，這是高度建議支援手持裝置實作的功能。支援在主畫面中嵌入小工具的裝置實作項目，必須符合下列規定，並宣告支援平台功能 android.software.app_widgets。

  • 裝置啟動器「必須」提供 AppWidgets 的內建支援，且會顯示使用者介面預設用途，以便直接在啟動器中新增、設定、查看及移除 AppWidgets。
  • 裝置實作必須能顯示 4 x 4 在標準格狀空間大小的小工具。詳情請參閱 Android SDK 說明文件中的「應用程式小工具設計指南」。
  • 實作功能可支援螢幕鎖定畫面的應用程式小工具。

3.8.3.通知

Android 提供的 API 可讓開發人員使用裝置的硬體和軟體功能，通知使用者重要事件。

部分 API 可讓應用程式使用硬體 (尤其是音效、震動和亮度) 發出通知或吸引註意力。裝置實作「必須」支援使用硬體功能的通知，如 SDK 說明文件所述，以及在裝置實作硬體中盡可能支援通知。舉例來說，如果裝置實作方式包含震動功能，「必須」正確實作震動 API。如果裝置實作方式缺少硬體，「必須」將對應的 API 實作為免人工管理。如要進一步瞭解這項行為，請參閱第 7 節。

此外，實作項目「必須」正確轉譯 API 中提供的所有資源 (圖示、動畫檔案等)，或是「狀態/系統列圖示樣式指南」(如果 Android TV 裝置可能未顯示通知)。相較於 Android 開放原始碼的實作方式所提供的通知，裝置實作者可以為通知提供替代的使用者體驗。但這類替代通知系統「必須」支援現有的通知資源，如上所述。

Android Automotive 實作項目「可」管理通知的顯示設定和時間，以降低駕駛人分心等級，但「必須」在應用程式要求時顯示使用 Cartendeder 的通知。

Android 支援各種通知，例如：

  • 複合式通知 .持續通知的互動式檢視畫面。
  • 抬頭通知 .互動式檢視的使用者可以在目前應用程式的情況下採取行動或關閉廣告。
  • 螢幕鎖定通知 .通知會顯示在螢幕鎖定畫面上，並提供精細的控制選項。

Android 裝置的實作方式 (這類通知顯示時，必須遵循 Android API 中記錄的內容)，正確執行豐富的和抬頭通知，並加入標題/名稱、圖示和文字。

Android 包含 Notification Listener Service API，可讓應用程式 (使用者明確啟用後) 在發布或更新通知時接收所有通知的副本。裝置實作「必須」正確且立即將完整通知傳送至所有已安裝和啟用使用者功能的事件監聽器服務，包括附加至「通知」物件的所有中繼資料。

支援 DND (零打擾) 功能的裝置實作方式「必須」符合下列規定：

  • 「必須」實作會回應 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS 意圖的活動，以使用 UI_MODE_TYPE_NORMAL 進行實作時，「必須」是一個活動，可讓使用者授予或拒絕應用程式存取 DND 政策設定的權限。
  • 如果裝置的實作方式可讓使用者授予或拒絕第三方應用程式存取 DND 政策設定，必須一併顯示應用程式建立的自動 DND 規則，以及使用者建立和預先定義的規則。
  • 「必須」遵循 NotificationManager.Policy 一併傳遞的 suppressedVisualEffects 值，如果應用程式已設定任何 SUPPRESSED_effective_SCREEN_OFF 或 SUPPRESSED_effective_SCREEN_ON 標記，則應用程式「必須」向使用者表明在 DND 設定選單中隱藏視覺效果。

Android 提供的 API 可讓開發人員將搜尋功能加入應用程式，並將應用程式資料公開到全域系統搜尋。一般來說，這項功能是由整個系統通用的使用者介面所組成，可讓使用者輸入查詢、在使用者輸入內容時顯示建議，以及顯示結果。開發人員可利用 Android API 重複使用這個介面，以在自家應用程式中提供搜尋功能，並讓開發人員將結果提供給常見的全域搜尋使用者介面。

Android 裝置實作「必須」提供全域搜尋，以及整個系統通用的搜尋使用者介面，可根據使用者輸入內容提供即時建議。裝置實作應實作 API，讓開發人員能重複使用這個使用者介面，以便在自己的應用程式中提供搜尋功能。實作全域搜尋介面的裝置實作「必須」實作相關 API，允許第三方應用程式在全域搜尋模式下將建議加到搜尋框中。如果沒有安裝任何使用此功能的第三方應用程式，則預設行為「必須」顯示網頁搜尋引擎結果和建議。

實作 Android 裝置時，必須「必須」實作 Android Automotive 應用程式，才能在裝置上實作助理來處理輔助動作。

Android 也包含 Assist API，可讓應用程式選擇與裝置助理分享多少目前背景資訊的資訊。如果裝置導入方式支援輔助動作，則「必須」在畫面邊緣周圍顯示白光，向使用者明確指出分享相關資訊。為確保使用者清楚瞭解，這些指示「必須」達到或超過 Android 開放原始碼計畫實作成果的時間和亮度。

3.8.5。吐司

應用程式可以使用「Toast」 API，向使用者顯示簡短非強制回應字串，這類字串會在短時間內消失。裝置實作「必須」以某些高可見性的方式，向使用者顯示應用程式的浮動式訊息。

3.8.6。主題

Android 提供「主題」機制，讓應用程式能在整個活動或應用程式中套用樣式。

Android 提供「Holo」主題系列做為一組定義的樣式，可讓應用程式開發人員在希望符合 Android SDK 定義的 Holo 主題外觀和風格時使用。裝置實作項目不得變更向應用程式公開的任何 Holo 主題屬性。

Android 提供「Material」主題系列做為一組定義的樣式，方便應用程式開發人員配合各種 Android 裝置類型的設計主題外觀和風格。裝置實作項目「必須」支援「Material」主題系列，且「不得」變更向應用程式公開的任何 Material Design 主題屬性或其資產。

Android 也包含「裝置預設」主題系列，這是一組已定義的樣式，如果應用程式開發人員希望符合裝置實作者定義的裝置主題外觀和風格，則可使用。裝置實作方式可能會修改應用程式公開的裝置預設主題屬性。

Android 支援包含半透明系統資訊列的變化版本主題，可讓應用程式開發人員在狀態和導覽列後方顯示應用程式內容。為了讓開發人員在這項設定中享有一致的體驗，在不同裝置實作項目中，必須保留狀態列圖示樣式。因此，Android 裝置實作「必須」使用白色的系統狀態圖示 (例如訊號強度和電池電量) 以及系統發出的通知，除非該圖示指出有問題的狀態，或者應用程式使用 SYSTEM_UI_FLAG_LIGHT_STATUS_BAR 標記要求淺色狀態列。當應用程式要求淺色狀態列時，Android 裝置實作「必須」將系統狀態圖示的顏色變更為黑色 (詳情請參閱 R.style 一文)。

3.8.7。動態桌布

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

如果硬體可以執行所有動態桌布，且功能不受限，就能以合理的畫面更新率確保運作穩定，且不會對其他應用程式造成負面影響。如果硬體限制會造成桌布和/或應用程式異常終止、故障、過度消耗 CPU 或電池電力，或以超低影格速率執行，則系統會將該硬體視為無法執行動態桌布。舉例來說，某些動態桌布可能會使用 OpenGL 2.0 或 3.x 內容來顯示內容。在不支援多個 OpenGL 內容的硬體上，動態桌布無法在不支援多個 OpenGL 環境的硬體上執行，因為使用 OpenGL 情境的動態桌布可能會與其他使用 OpenGL 內容的應用程式發生衝突。

如上所述，能夠穩定執行動態桌布的裝置實作項目「必須」實作動態桌布，且實作時「必須」回報平台功能旗標 android.software.live_wallpaper。

3.8.8。活動切換

由於「近期」函式導覽鍵為「選用」，因此針對 Android Watch 和 Android Automotive 實作項目實作總覽畫面的必要性為「選用」，Android 電視裝置則採用「建議」屬性。實作 Android Automotive 時，仍必須保留切換活動的方法。

上游 Android 原始碼包含總覽畫面，這是一種系統層級的使用者介面，可用於切換工作，並利用應用程式圖形狀態的縮圖，在使用者上次離開應用程式的時候，顯示最近存取的活動和工作。即使裝置實作方式包含近期功能瀏覽鍵 (如第 7.2.3 節所述)，您也可以變更介面，但「必須」符合下列規定：

  • 最多只能支援 6 個顯示的活動。
  • 一次至少應顯示 4 項活動的標題。
  • 必須導入螢幕固定行為，並提供設定選單來切換功能。
  • 應在近期顯示醒目顯示顏色、圖示和畫面標題。
  • 應顯示關閉的預設用途 (「x」)，但可能要等到使用者與螢幕互動後再執行。
  • 應導入捷徑，以便輕鬆切換到先前活動
  • 可能顯示有關聯的近期資訊群組。
  • 使用者輕觸近期的兩個功能鍵時，應觸發在最近使用的兩個應用程式之間快速切換動作。
  • 長按近期函式鍵時，應觸發分割畫面多視窗模式 (如果支援)。

強烈建議您將裝置實作方式用於總覽畫面的 Android 上游使用者介面 (或類似的縮圖式介面)。

3.8.9。輸入管理

Android 支援輸入管理功能，並支援第三方輸入法編輯器。允許使用者在裝置上使用第三方輸入法的裝置實作項目，「必須」宣告平台功能 android.software.input_methods，並支援 Android SDK 說明文件中定義的 IME API。

如果裝置實作項目宣告 android.software.input_methods 功能，「必須」提供可供使用者存取的機制，才能新增及設定第三方輸入法。裝置實作「必須」根據 android.settings.INPUT_METHOD_SETTINGS 意圖顯示設定介面。

3.8.10。螢幕鎖定媒體控制項

Remote Control Client API 已從 Android 5.0 版淘汰，並改用媒體通知範本，讓媒體應用程式能整合螢幕鎖定畫面上顯示的播放控制項。支援螢幕鎖定的裝置實作方式，除非實作 Android Automotive 或 Watch，否則「必須」顯示包含媒體通知範本的螢幕鎖定通知。

3.8.11。螢幕保護程式 (先前為 Dream)

Android 支援先前稱為 Dreams 的互動式螢幕保護程式。螢幕保護程式可讓使用者在已連接電源的裝置或座架在桌面座架上時，與應用程式互動。Android Watch 裝置「可」實作螢幕保護程式，但其他類型的裝置「應」提供螢幕保護程式支援，並提供設定選項，讓使用者可以根據 android.settings.DREAM_SETTINGS 意圖設定螢幕保護程式。

3.8.12。地區

如果裝置具備能夠提供位置座標的硬體感應器 (例如 GPS)，就必須在「設定」的 [位置] 選單中顯示定位模式。

3.8.13。萬國碼 (Unicode) 和字型

Android 支援 Unicode 9.0 中定義的表情符號字元。所有裝置實作都「必須」能夠以色彩字符顯示這些表情符號字元；如果 Android 裝置實作含有輸入法編輯器，就「應該」為使用者提供這些表情符號字元的輸入法。

Android 手持裝置必須支援 Unicode 技術報告 #51 中指定的膚色和各種家庭表情符號。

Android 支援不同粗細的 Roboto 2 字型：sans-Serif-thin、Sans-Serif-light、Sans-Serif-medium、Sans-Serif-condenses

3.8.14。多視窗模式

裝置實作「可能」選擇不實作任何多視窗模式，但如果能夠同時顯示多個活動，就「必須」按照 Android SDK 多視窗模式支援說明文件中所述的應用程式行為和 API 實作這類多視窗模式，並符合下列規定：

  • 應用程式可透過 android:resizeableActivity 屬性明確指出其是否能在 AndroidManifest.xml 檔案中運作，或透過 targetSdkVersion > 以隱含方式運作。24.如果應用程式在資訊清單中明確將這項屬性設為 false，則「不得」在多視窗模式下啟動。如果應用程式未在資訊清單檔案 (targetSdkVersion < 24) 中設定該屬性，可以在多視窗模式下啟動，但系統「必須」提供警告訊息，說明應用程式可能無法在多視窗模式下正常運作。
  • 如果螢幕高度和寬度皆小於 440 dp，裝置實作就「不得」提供分割畫面或任意形式模式。
  • 螢幕大小為 xlarge 的裝置實作應支援任意形式模式。
  • Android 電視裝置的實作「必須」支援子母畫面 (PIP) 模式多視窗模式，且當子母畫面開啟時，將子母畫面多視窗放在右上角。
  • 如果裝置實作支援子母畫面模式多視窗模式，就「必須」為子母畫面視窗分配至少 240x135 dp。
  • 如果支援子母畫面模式的多視窗模式，就「必須」使用 KeyEvent.KEYCODE_WINDOW 鍵控制子母畫面視窗。否則，金鑰「必須」適用於前景活動。

3.9.裝置管理

Android 提供多項功能，可讓具備安全性感知的應用程式透過 Android Device 管理 API 在系統層級執行裝置管理功能，例如強制執行密碼政策或執行遠端清除作業。裝置實作「必須」提供 DevicePolicyManager 類別的實作項目。支援安全螢幕鎖定的裝置實作項目「必須」實作 Android SDK 說明文件中定義的所有裝置管理政策，並回報平台功能 android.software.device_admin。

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

如果裝置實作項目宣告 android.software.device_admin 功能，則「必須」實作 Device Policy 用戶端 (DPC) 應用程式的裝置擁有者應用程式佈建功能，如下所示：

裝置導入作業「可能」含有會執行裝置管理功能的應用程式，但「不得」將這個應用程式設為裝置擁有者應用程式，除非使用者或裝置管理員明確同意或做出相應操作。

3.9.1.2 受管理設定檔佈建

如果裝置實作項目宣告 android.software.managed_users，則「必須」能將 Device Policy Controller (DPC) 應用程式註冊為新受管理設定檔的擁有者。

受管理設定檔佈建程序 (由 android.app.action.PROVISION_MANAGED_PROFILE 啟動的流程) 使用者體驗「必須」符合 Android 開放原始碼計畫實作項目。

裝置實作項目「必須」在「設定」使用者介面中提供下列使用者權限，以便在裝置政策控制器 (DPC) 停用特定系統功能時向使用者說明：

  • 當裝置管理員限制特定設定時，顯示一致的圖示或使用者預設用途 (例如上游 Android 開放原始碼計畫資訊圖示)。
  • 裝置管理員透過 setShortSupportMessage 提供的簡短說明訊息。
  • DPC 應用程式圖示。

3.9.2 支援受管理設定檔

受管理設定檔的裝置是指符合下列條件的裝置：

支援受管理設定檔的裝置「必須」符合下列規定：

  • 宣告平台功能旗標 android.software.managed_users。
  • 透過 android.app.admin.DevicePolicyManager API 支援受管理的設定檔。
  • 僅允許建立一個受管理的設定檔，且只能建立一個受管理的設定檔。
  • 使用圖示徽章 (類似 Android 開放原始碼計畫上游工作標記) 代表受管理的應用程式、小工具，以及其他獲得徽章的 UI 元素，例如「近期與」通知。
  • 顯示通知圖示 (類似 Android 開放原始碼計畫上游工作標記)，表示使用者位於受管理的設定檔應用程式中。
  • 顯示浮動式訊息，指出裝置是否喚醒裝置，以及裝置喚醒的時間點 (ACTION_USER_PRESENT)，且前景應用程式位於受管理的設定檔中。
  • 如果有受管理的設定檔，請在意圖的「選擇工具」中顯示視覺預設用途允許使用者將意圖從受管理的設定檔轉送給主要使用者；如果已經啟用 Device Policy Controller，則可反向轉送意圖的使用者。
  • 如果已有受管理的設定檔，請為主要使用者和受管理的設定檔公開下列使用者權限：
    • 將主要使用者和受管理設定檔的電池、位置、行動數據和儲存空間用量分開計算。
    • 管理主要使用者或受管理設定檔中安裝的 VPN 應用程式。
    • 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
    • 獨立管理主要使用者或受管理設定檔中的帳戶。
  • 在裝置政策控制器允許的情況下，確保預先安裝的撥號程式、聯絡人和訊息應用程式可以在受管理的設定檔 (如果有的話) 中搜尋及查詢來電者資訊。如果受管理設定檔的聯絡人顯示在預先安裝的通話記錄、通話使用者介面、進行中和未接來電通知、聯絡人和訊息應用程式上，就必須標有代表受管理設定檔應用程式的徽章。
  • 如果裝置允許多位使用者同時啟用多位使用者，則必須確保裝置符合所有適用的安全性規定 (請參閱第 9.5 節)，即使受管理的設定檔不是主要使用者。
  • 支援依照下列規定另外指定螢幕鎖定畫面，將存取權授予受管理設定檔中執行的應用程式。

3.10.無障礙功能

Android 提供無障礙圖層，可協助身心障礙使用者輕鬆瀏覽裝置。此外，Android 提供的平台 API 可讓無障礙服務實作項目接收使用者和系統事件的回呼，並產生替代意見回饋機制，例如文字轉語音、觸覺回饋和軌跡球/D-Pad 瀏覽。

裝置導入方式如下：

  • Android Automotive 實作項目應提供與預設 Android 實作一致的 Android 無障礙架構實作。
  • 裝置實作項目 (Android Automotive 已排除) 「必須」提供與預設 Android 實作一致的 Android 無障礙架構實作。
  • 裝置實作項目 (已排除 Android Automotive) 必須支援透過 android.accessibilityservice API 導入第三方無障礙服務。
  • 裝置實作方式 (Android Automotive 已排除) 必須產生 AccessibilityEvents 事件，並根據預設 Android 實作方式，將這些事件傳送至所有已註冊的 AccessibilityService 實作項目

  • 裝置實作方式 (未排除音訊輸出的 Android Automotive 和 Android Watch 裝置)、提供可讓使用者存取的機制來啟用及停用無障礙服務，且「必須」配合 android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS 意圖顯示此介面。

  • 我們強烈建議在採用音訊輸出的 Android 裝置實作過程中，實作與 TalkBack 和切換控制功能無障礙服務相當或更優異的無障礙服務實作項目 (https://github.com/google/talkback)。

  • 具有音訊輸出的 Android Watch 裝置「應」在裝置上實作無障礙服務，相當於或超越 TalkBack 無障礙服務 (https://github.com/google/talkback) 的功能。
  • 裝置實作「必須」在開箱內提供機制，讓使用者啟用相關無障礙服務，以及調整字型大小、顯示大小和放大手勢的選項。

** 適用於文字轉語音功能支援的語言。

另請注意，如有預先載入的無障礙服務，且裝置是以檔案型加密 (FBE) 加密儲存空間，則「必須」是直接啟動感知 {directBootAware} 應用程式。

3.11.Text-to-Speech

Android 中的 API 可讓應用程式使用文字轉語音 (TTS) 服務，並允許服務供應商實作 TTS 服務。回報 android.hardware.audio.output 功能的裝置實作項目必須符合這些 Android TTS 架構的相關要求。

Android Automotive 實作：

  • 必須支援 Android TTS 架構 API。
  • 可能支援安裝第三方 TTS 引擎。如果支援的話，合作夥伴「必須」提供可供使用者存取的介面，讓使用者在系統層級選取要使用的 TTS 引擎。

所有其他裝置實作方式：

  • 必須支援 Android TTS 架構 API，且應提供支援裝置可用語言的 TTS 引擎。請注意，Android 上游開放原始碼軟體內含完整的 TTS 引擎實作。
  • 必須支援安裝第三方 TTS 引擎。
  • 「必須」提供可存取的介面，讓使用者在系統層級選取要使用的 TTS 引擎。

3.12.電視輸入架構

Android 電視輸入架構 (TIF) 簡化了將直播內容提交至 Android 電視裝置的程序。TIF 提供用於建立控制 Android Television 裝置的輸入模組的標準 API。Android 電視裝置實作項目「必須」支援電視輸入架構。

支援 TIF 的裝置實作「必須」宣告平台功能 android.software.live_tv。

3.12.1.TV 應用程式

凡是宣告支援 Live TV 的裝置實作項目，都「必須」安裝電視應用程式 (TV 應用程式)。Android 開放原始碼計畫提供了 TV 應用程式的實作。

TV 應用程式「必須」提供安裝及使用電視頻道的設施，並符合下列規定：

  • 裝置導入方式「必須」允許安裝及管理第三方 TIF 輸入資料 ( 第三方輸入來源)。
  • 裝置的實作方式「可」將預先安裝的 TIF 型輸入資料 (已安裝的輸入內容) 和第三方的輸入資料進行視覺區隔。
  • 裝置導入作業「不得」只針對 TV 應用程式以外的單一導覽動作顯示第三方輸入來源 (亦即從 TV 應用程式展開第三方輸入來源清單)。

3.12.1.1。電子節目節目指南

Android 電視裝置實作「必須」顯示資訊及互動式重疊元素，「必須」加入根據 TvContract.Programs 欄位值產生的電子節目指南 (EPG)。電子節目表「必須」符合下列規定：

  • EPG「必須」顯示所有已安裝輸入端和第三方輸入端的資訊。
  • EPG MAY 可以區隔已安裝的輸入和第三方輸入裝置。
  • 我們極力建議電子節目表以同樣顯眼的方式，顯示已安裝的輸入來源和第三方輸入項目。電子節目表中的安裝輸入端「不得」僅針對單一導覽動作顯示第三方輸入來源。
  • 當頻道變更時，裝置的導入作業「必須」顯示目前播放節目的電子節目表資料。

3.12.1.2。導航

TV 應用程式「必須」允許在 Android 電視裝置輸入裝置 (亦即遙控器、遙控器應用程式或遊戲控制器) 上，透過 D-Pad、返回和 Home 鍵瀏覽下列功能：

  • 變更電視頻道
  • 開啟電子節目表
  • 設定及微調第三方 TIF 型輸入內容
  • 正在開啟「設定」選單

電視應用程式應透過 CEC 將重要事件傳送至 HDMI 輸入端。

3.12.1.3.電視輸入應用程式連結

Android 電視裝置導入作業「必須」支援電視輸入應用程式連結，讓所有輸入來源將目前活動的活動連結提供給其他活動 (例如從直播節目連結至相關內容的連結)。電視應用程式「必須」顯示提供電視輸入應用程式的連結。

3.12.1.4。時光平移

Android TV 裝置實作項目「必須」支援時間轉換功能，讓使用者可以暫停及繼續播放直播內容。如果裝置可使用時間轉移功能，裝置實作「必須」能夠讓使用者暫停並繼續執行目前播放程式。

3.12.1.5。電視錄影

我們極力建議您導入 Android 電視裝置以支援電視錄製功能。如果電視輸入來源支援錄製功能，電子節目表可能會提供錄製節目的方式，但前提是該節目的錄製行為不受禁止。實作裝置「必須」提供使用者介面，以便播放錄製的節目。

3.13.快速設定

Android 裝置實作項目「必須」提供快速設定 UI 元件，方便快速存取常用或急需執行的操作。

Android 提供 quicksettings API，可讓第三方應用程式實作使用者能加入的資訊方塊，以及快速設定 UI 元件中系統提供的資訊方塊。如果裝置實作項目具有快速設定 UI 元件，就會：

  • 必須允許使用者在「快速設定」中新增或移除第三方應用程式的資訊方塊。
  • 「不得」自動將第三方應用程式的資訊方塊新增到快速設定。
  • 必須顯示使用者透過第三方應用程式新增的所有資訊方塊，以及系統提供的快速設定方塊。

3.14。車輛 UI API

3.14.1.車輛媒體 UI

任何宣告汽車支援的裝置實作都必須包含 UI 架構，以支援使用 MediaBrowser 和 MediaSession API 的第三方應用程式。

使用者介面架構支援使用 MediaBrowser 和 MediaSession 的第三方應用程式，須符合下列視覺規定：

  • 必須原封不動顯示 MediaItem 圖示和通知圖示。
  • 「必須」按照 MediaSession 的說明顯示這些項目，例如中繼資料、圖示和圖像。
  • 必須顯示應用程式名稱。
  • 「必須」設有導覽匣以顯示 MediaBrowser 階層。

4. 應用程式封裝的相容性

裝置實作「必須」安裝及執行由官方 Android SDK 中包含的「aapt」工具所產生的 Android「.apk」檔案。因此，實作裝置「必須」使用參考實作的套件管理系統。

套件管理員「必須」支援使用 APK 簽署配置 v2 和 JAR 簽署驗證「.apk」檔案。

實作裝置「不得」以防止其他相容裝置安裝及執行這些檔案的方式，擴充 .apk、Android Manifest、Dalvik 位元碼或 RenderScript 位元碼格式。

5. 多媒體相容性

5.1. 媒體轉碼器

實作裝置：

  • 必須支援 Android SDK 說明文件中指定的核心媒體格式 (除非本文件中明確允許)。

  • 必須支援下表所定義以及透過 MediaCodecList 回報的媒體格式、編碼器、解碼器、檔案類型和容器格式。

  • 也必須能將 CamcorderProfile 中回報的所有設定檔解碼

  • 必須能解碼可編碼的所有格式。這包括編碼器產生的所有位元流。

轉碼器應盡量縮短轉碼器延遲時間，亦即轉碼器

  • 不應使用及儲存輸入緩衝區，且只會在處理後傳回輸入緩衝區
  • 已解碼的緩衝區不應超過標準指定時間 (例如 SPS) 的時間。
  • 「不得」保留超過 GOP 結構所需的編碼緩衝區。

下表列出所有轉碼器，都是以 Android 開放原始碼計畫偏好的 Android 實作方式提供的軟體實作方式。

請注意，Google 或 Open Handset Alliance 皆不代表這些轉碼器不在第三方專利中。有意將此原始碼用於硬體或軟體產品的使用者，建議在實作此程式碼 (包括開放原始碼軟體或共享軟體) 的情況下，可能需要相關專利持有人的專利授權。

5.1.1.音訊轉碼器

格式/轉碼器 編碼器 解碼器 詳細資料 支援的檔案類型/容器格式
MPEG-4 AAC 設定檔
(AAC LC) 		必要 1 是否必要 支援單聲道/立體聲/5.0/5.1 2 內容，採用標準取樣率介於 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+) 必要 1
(Android 4.1 以上版本)。 		是否必要 支援單聲道/立體聲/5.0/5.1 2 內容，採用標準取樣率從 16 至 48 kHz。
MPEG-4 HE AACv2
設定檔 (加強型 AAC+) 		是否必要 支援單聲道/立體聲/5.0/5.1 2 內容，採用標準取樣率從 16 至 48 kHz。
AAC ELD (強化低延遲 AAC) 必要 1
(Android 4.1 以上版本)。 		必要
(Android 4.1 以上版本)。 		支援標準取樣率介於 16 至 48 kHz 的單聲道/立體聲內容。
美國醫力軍 必填 3 必填 3 4.75 到 12.2 kbps 取樣時 @ 8 kHz 3GPP (.3gp)
AMR-WB 必填 3 必填 3 9 速率介於每秒 6.60 kbit 到 23.85 kbit (取樣率為 16 kHz)
FLAC 必要
(Android 3.1 以上版本)。 		單聲道/立體聲 (無多頻道)。取樣率最高可達 48 kHz (在具有 44.1 kHz 輸出的裝置上，最高建議採用 44.1 kHz 的影格)，因為 48 至 44.1 kHz 的向下取樣器不包含低流量濾波器。建議採用 16 位元；24 位元沒有適用的皮革。 僅限 FLAC (.flac)
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 (.ogg)
  • Matroska (.mkv，Android 4.0 以上版本)
PCM/WAVE 必填 4
(Android 4.1 以上版本)。 		是否必要 16 位元線性 PCM (速率上限為硬體)。裝置必須支援 8000、11025、16000 和 44100 Hz 頻率的原始 PCM 錄製取樣率。 WAVE (.wav)
Opus 必要
(Android 5.0 以上版本)。 		Matroska (.mkv)、Ogg(.ogg)

1 定義 android.hardware.microphone 的裝置實作項目為必要項目，但如果是 Android Watch 裝置實作項目，則為選用項目。

2 錄製或播放可以是單聲道或立體聲，但透過 android.media.MediaCodec API 中的預設 AAC 音訊解碼器，將多頻道串流 (意即超過兩個頻道) 的 AAC 輸入緩衝區解碼為 PCM，必須支援下列「必須」：

  • 解碼時不會進行下移 (例如，5.0 AAC 串流必須解碼為 PCM 的五個管道，5.1 AAC 串流必須解碼為 PCM 的六個管道)
  • 動態範圍中繼資料，如「動態範圍控制 (DRC)」中所定義，並使用 android.media.MediaFormat DRC 金鑰設定音訊解碼器的動態範圍相關行為。AAC DRC 金鑰於 API 21 中導入，為：KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_A_AC_ENCODED_

3 實作 Android 手持裝置時需要。

4 定義 android.hardware.microphone 的裝置實作項目，包括 Android Watch 裝置實作，此為必要項目。

5.1.2.圖片轉碼器

格式/轉碼器 編碼器 解碼器 詳細資料 支援的檔案類型/容器格式
JPEG 是否必要 是否必要 基準 + 漸進式 JPEG (.jpg)
GIF 是否必要 GIF (.gif)
PNG 是否必要 是否必要 PNG (.png)
BMP 是否必要 BMP (.bmp)
WebP 是否必要 是否必要 WebP (.webp)
未加工 是否必要 ARW (.arw)、CR2 (.cr2)、DNG (.dng)、NEF (.nef)、NRW (.nrw)、ORF (.orf)、PEF (.pef)、RAF (.raf)、RW2 (.rw2)、SRW (.srw)

5.1.3.視訊轉碼器

  • 轉碼器廣告 HDR 設定檔支援「必須」支援 HDR 靜態中繼資料剖析及處理。

  • 如果媒體轉碼器宣傳內部重新整理支援，則「必須」支援 10 至 60 個影格的重新整理週期，並在設定的重新整理週期的 20% 內準確運作。

  • 影片轉碼器「必須」支援輸出和輸入位元組緩衝區大小，以容納標準和設定要求所規定的最大可行壓縮和未壓縮影格大小，但也不得過度分配。

  • 影片編碼器和解碼器必須支援 YUV420 彈性顏色格式 (COLOR_FormatYUV420flex)。

格式/轉碼器 編碼器 解碼器 詳細資料 支援的檔案類型/
容器格式
標題 263 5 月 5 月
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC 必填 2 必填 2 詳情請參閱第 5.2 節和第 5.3 節
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (僅限 .ts、僅限 AAC 音訊，無法搜尋、Android 3.0 以上版本)
H.265 HEVC 必填 5 詳情請參閱第 5.3 節。 MPEG-4 (.mp4)
MPEG-2 強烈建議 6 主要個人資料 MPEG2 TS
MPEG-4 SP 必填 2 3GPP (.3gp)
VP8 3 必要 2
(Android 4.3 以上版本)。 		必要 2
(Android 2.3.3 以上版本)。 		詳情請參閱第 5.2 節和第 5.3 節
VP9 必要 2
(Android 4.4 以上版本)。 		詳情請參閱第 5.3 節。

1 裝置實作項目必須包含相機硬體，並且要定義 android.hardware.camera 或 android.hardware.camera.front。

2 實作裝置時，Android Watch 裝置除外。

3 為提供可接受的網路影片串流和視訊會議服務品質，導入裝置「必須」使用符合規定的硬體 VP8 轉碼器。

4 實作裝置應支援編寫 Matroska WebM 檔案。

5 強烈建議針對 Android Automotive 提供必要功能，Android Watch 為選用元素，其他裝置類型則是必要項目。

6 僅適用於 Android TV 裝置實作。

5.2.影片編碼

Android Watch 裝置實作方式可選用影片轉碼器。

H.264、VP8、VP9 和 HEVC 影片編碼器：

  • 必須支援動態可設定的位元率。
  • 應支援可變的畫面更新率，影片編碼器應根據輸入緩衝區的時間戳記判斷即時的影格時間長度，並依據該影格持續時間分配位元值區。

H.263 和 MPEG-4 影片編碼器「必須」支援動態可設定的位元率。

所有影片編碼器都必須在兩個滑動視窗中達到下列位元率目標：

  • 影格之間 (I 畫面) 間隔的位元率不應超過約 15%。
  • 和滑動窗口相比，位元率最多不超過 100%。

5.2.1。標題 263

採用 H.263 編碼器的 Android 裝置實作項目「必須」支援基準設定檔級別 45。

5.2.2。H-264 標題

支援 H.264 轉碼器的 Android 裝置實作項目：

  • 必須支援基準設定檔第 3 級。
    不過，我們會針對 ASO (任意配量順序)、FMO (彈性巨集排序) 和 RS (多餘配量) 提供支援。此外，為了維持與其他 Android 裝置的相容性，我們建議編碼器不會將 ASO、FMO 和 RS 用於基準設定檔。
  • 「必須」支援下表中的 SD (標準畫質) 影片編碼設定檔。
  • 應支援第 4 級主要設定檔。
  • 應支援 HD (高畫質) 影片編碼設定檔，如下表所示。
  • 此外，強烈建議 Android 電視裝置以 30 fps 編碼 HD 1080p 影片。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p 1 HD 高畫質 1080p 1
影片解析度 320 x 240 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素
影片畫面更新率 20 fps 每秒 30 個影格 每秒 30 個影格 每秒 30 個影格
視訊位元率 384 Kbps 2 Mbps 4 Mbps 10 Mbps

1 經硬體支援時，但強烈建議 Android 電視裝置採用。

5.2.3.VP8

支援 VP8 轉碼器的 Android 裝置實作項目「必須」支援 SD 影片編碼設定檔，且必須支援下列 HD (High Definition) 影片編碼設定檔。

SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p 1 HD 高畫質 1080p 1
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
影片畫面更新率 每秒 30 個影格 每秒 30 個影格 每秒 30 個影格 每秒 30 個影格
視訊位元率 800 Kbps 2 Mbps 4 Mbps 10 Mbps

1 由硬體支援時。

5.3.影片解碼

Android Watch 裝置實作方式可選用影片轉碼器。

實作裝置：

  • 在所有 VP8、VP9、H.264 和 H.265 轉碼器中，「必須」支援透過標準 Android API 的動態影片解析度和畫面更新率切換功能，且最高可達裝置每個轉碼器支援的最高解析度。

  • 支援 Dolby Vision 解碼器的實作方式：

  • 「必須」提供支援 Dolby Vision 的擷取器。

  • 必須在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

  • 如果實作項目提供支援 Dolby Vision 的擷取器，則「必須」將回溯相容基本層 (如有) 的追蹤索引設為與 Dolby Vision 圖層組合索引相同的追蹤索引。

5.3.1。MPEG-2

使用 MPEG-2 解碼器的 Android 裝置實作必須支援 Main Profile High Level。

5.3.2。標題 263

採用 H.263 解碼器的 Android 裝置實作必須支援基準設定檔層級 30 和第 45 級。

5.3.3.MPEG-4

使用 MPEG-4 解碼器的 Android 裝置實作「必須」支援簡易設定檔層級 3。

5.3.4。標題 264

使用 H.264 解碼器實作 Android 裝置：

  • 必須支援主要設定檔層級 3.1 和基準設定檔。
    您可以選擇支援 ASO (任意配量排序)、FMO (彈性巨集排序) 和 RS (多餘配量)。
  • 要能使用下表所列的 SD (標準畫質) 設定檔解碼影片，並以基準設定檔和主要設定檔層級 3.1 (包括 720p30) 編碼。
  • 「應該」能使用 HD (高畫質) 設定檔來解碼影片，如下表所示。
  • 此外，Android TV 裝置：
    • 必須支援高設定檔等級 4.2 和 HD 1080p60 解碼設定檔。
    • 必須能夠使用下表所示的 HD 高畫質設定檔，透過基準設定檔、主要設定檔或高設定檔等級 4.2 編碼影片。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p 1 HD 高畫質 1080p 1
影片解析度 320 x 240 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素
影片畫面更新率 每秒 30 個影格 每秒 30 個影格 60 fps 30 fps (60 fps 2 )
視訊位元率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則必須提供這項屬性。

2 實作 Android 電視裝置所需的必要步驟。

5.3.5。H.265 (HEVC)

Android 裝置實作時，支援 H.265 轉碼器 (如第 5.1.3 節所述)：

  • 必須支援主要設定檔層級 3 的主要層級和 SD 影片解碼設定檔，如下表所示。
  • 「應該」支援 HD 編碼解碼設定檔，如下表所示。
  • 如果有硬體解碼器，「必須」支援 HD 高畫質解碼設定檔。
  • 此外，Android TV 裝置需遵守下列規定：
  • 必須支援 HD 720p 解碼設定檔。
  • 強烈建議您支援 HD 1080p 解碼設定檔。如果支援 HD 高畫質 1080p 解碼設定檔，則「必須」支援主要設定檔層級 4.1 的主要層級。
  • 應支援 UHD 解碼設定檔。如果支援 UHD 解碼設定檔，轉碼器「必須」支援 Main10 第 5 級主要層級設定檔。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 (720p) HD 高畫質 (1080p) UHD 超高畫質
影片解析度 352 x 288 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 每秒 30 個影格 每秒 30 個影格 每秒 30 個影格 30 fps (60 fps 1 ) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 實作使用 H.265 硬體解碼的 Android TV 裝置需使用這項元素。

5.3.6。VP8

支援 VP8 轉碼器的 Android 裝置實作項目 (如第 5.1.3 節所述)：

  • 「必須」支援下表中的 SD 解碼設定檔。
  • 應支援下表中的 HD 高畫質解碼設定檔。
  • Android 電視裝置「必須」支援 HD 1080p60 解碼設定檔。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 720p 1 HD 高畫質 1080p 1
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
影片畫面更新率 每秒 30 個影格 每秒 30 個影格 30 fps (60 fps 2 ) 30 (60 fps 2 )
視訊位元率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則必須提供這項屬性。

2 實作 Android 電視裝置所需的必要步驟。

5.3.7。VP9

支援 VP9 轉碼器的 Android 裝置實作項目 (如第 5.1.3 節所述)：

  • 「必須」支援如下表所示的 SD 影片解碼設定檔。
  • 「應該」支援 HD 編碼解碼設定檔，如下表所示。
  • 使用硬體解碼器時，「必須」支援如下表所示的 HD 高畫質解碼設定檔。

  • 此外，Android TV 裝置需遵守下列規定：

    • 必須支援 HD 720p 解碼設定檔。
    • 強烈建議您支援 HD 1080p 解碼設定檔。
    • 應支援 UHD 解碼設定檔。如果系統支援 UHD 超高畫質影片解碼設定檔，則必須支援 8 位元色彩深度，且必須支援 VP9 Profile 2 (10 位元)。
SD 標準畫質 (低品質) SD 標準畫質 (高畫質) HD 高畫質 (720p) HD 高畫質 (1080p) UHD 超高畫質
影片解析度 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 每秒 30 個影格 每秒 30 個影格 每秒 30 個影格 30 fps (60 fps 1 ) 60 fps
視訊位元率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

1 實作使用 VP9 硬體解碼的 Android 電視裝置需要此項目。

5.4.錄音

雖然本節所列的部分規定已註明自 Android 4.3 起，但未來版本的相容性定義將變更為「必須」。無論是現有還是新的 Android 裝置，都強烈「建議」符合「應」的規定，否則日後升級至新版本時，將無法獲得 Android 相容性。

5.4.1。原始音訊擷取

宣告 android.hardware.microphone 的裝置必須允許擷取符合下列特性的原始音訊內容：

  • 格式：線性 PCM、16 位元
  • 取樣率：8000、11025、16000、44100
  • 聲道：單聲道

您「必須」執行上述取樣率的擷取作業，不要向上取樣，且所有降低取樣作業都「必須」加入適當的反鋸齒濾鏡。

宣告 android.hardware.microphone 的裝置實作應允許擷取具有下列特性的原始音訊內容：

  • 格式：線性 PCM、16 位元
  • 取樣率：22050、48000
  • 頻道：立體聲

如果系統支援上述取樣率，則「必須」不要以高於 16000:22050 或 44100:48000 的任何比例進行向上取樣。所有向上取樣或降低取樣的項目都「必須」加入適當的反鋸齒濾鏡。

5.4.2。擷取以辨識聲音

android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源「必須」支援以下其中一種取樣率 (44100 和 48000) 的擷取作業。

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

  • 裝置「應該」表現出近乎平坦的振幅與頻率特性：特別是 ±3 dB，從 100 Hz 到 4000 Hz。
  • 建議設定音訊輸入靈敏度，讓 1000 Hz 的 90 dB 聲音功率 (SPL) 源能產生 2500 RMS 的 16 位元樣本。
  • PCM 的振幅必須以線性方式追蹤輸入的 SPL 變化量至少介於 -18 dB 到 +12 dB re 90 dB SPL 之間，範圍必須介於 -18 dB 到 +12 dB re 90 dB SPL 之間。
  • 以 90 dB SPL 輸入等級為目標時，在麥克風輸入的 1 kHz 總諧變形必須小於 1%。
  • 雜訊抑制處理功能 (如有) 必須停用。
  • 必須停用自動增益控制項 (如有)。

如果平台支援針對語音辨識微調的雜訊抑制技術，「必須」能透過 android.media.audiofx.NoiseSuppressor API 控制效果。此外，雜訊抑制器效果描述元的 UUID 欄位「必須」可明確識別每種雜訊抑制技術的實作。

5.4.3.擷取用於重新規劃路線的拍攝畫面

android.media.MediaRecorder.AudioSource 類別包含 REMOTE_SUBMIX 音訊來源。宣告 android.hardware.audio.output 的裝置「必須」正確實作 REMOTE_SUBMIX 音訊來源，這樣當應用程式使用 android.media.AudioRecord API 錄製這個音訊來源的音訊時，可以擷取所有音訊串流的組合，但下列項目除外：

  • STREAM_RING
  • STREAM_ALARM
  • 串流通知

5.5.音訊播放

宣告 android.hardware.audio.output 的裝置實作項目必須符合本節的規定。

5.5.1.原始音訊播放

裝置「必須」允許播放符合下列特性的原始音訊內容：

  • 格式：線性 PCM、16 位元
  • 取樣率：8000、11025、16000、22050、32000、44100
  • 聲道：單聲道、立體聲

裝置應允許播放符合下列特性的原始音訊內容：

  • 取樣率：24000、48000

5.5.2.音效

Android 提供裝置實作的音效 API。宣告 android.hardware.audio.output 功能的裝置實作項目：

  • 必須支援透過 AudioEffect 子類別 Equalizer、LoudnessEnhancer 控制的 effective_TYPE_EQUALIZER 和 effective_TYPE_LOUDNESS_ENHANCER 實作項目。
  • 必須支援視覺化工具 API 實作，且可透過 Visualizer 類別控制。
  • 應支援 FLEDGE_TYPE_BASS_BOOST、effective_TYPE_ENV_REVERB、effective_TYPE_PRESET_REVERB 和 FLEDGE_TYPE_VIRTUALIZER 實作項目 (可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer)。

5.5.3.音訊輸出音量

Android 電視裝置的實作「必須」針對支援的輸出系統支援系統主音量和數位音訊輸出音量強化功能，但經過壓縮的音訊直通輸出 (裝置不會進行音訊解碼) 除外。

實作 Android Automotive 裝置時，必須允許使用 AudioAttributes 定義的內容類型，或 android.car.CarAudioManager 中公開定義的車輛音訊使用方式，分別調整每個音訊串流的音訊音量。

5.6.音訊延遲時間

音訊延遲是指音訊訊號通過系統的時間延遲。許多類別的應用程序都仰賴短的延遲時間來實現即時音效。

為達成本節目的，請使用下列定義：

  • 輸出延遲。應用程式寫入 PCM 編碼資料影格的時間，與在裝置端傳音器或信號向環境呈現相應聲音的間隔時間，該音訊會透過通訊埠從裝置傳出，因此可對外觀察。
  • 冷輸出延遲 .第一個影格的輸出延遲時間，如果音訊輸出系統在要求前處於閒置狀態且已關機，則第一個影格的輸出延遲時間。
  • 連續輸出延遲。裝置播放音訊後，後續影格的輸出延遲時間。
  • 輸入延遲 .裝置透過裝置端轉換器或訊號向裝置顯示聲音的間隔時間，是指透過連接埠進入裝置，以及應用程式讀取對應 PCM 編碼資料影格的間隔時間。
  • 缺少輸入端。輸入信號的初始部分無法使用或無法使用。
  • 冷輸入延遲時間 -音訊輸入系統在要求前處於閒置狀態，且在要求前已關機，第一個影格的輸入時間總和與輸入延遲時間。
  • 連續輸入延遲 。後續影格的輸入延遲時間，同時裝置正在擷取音訊。
  • 冷輸出時基誤差 .不同測量冷輸出延遲時間值之間的變異性。
  • 冷輸入時基誤差 .不同測量冷輸入延遲時間值的差距。
  • 連續往返延遲時間 。連續輸入延遲時間的總和加上連續輸出延遲時間加一個緩衝區週期的總和。緩衝期可讓應用程式處理信號和時間，減少輸入與輸出串流之間的階段差異。
  • OpenSL ES PCM 緩衝區佇列 API。Android NDK 中的 PCM 相關 OpenSL ES API 組合。

極力建議您宣告宣告 android.hardware.audio.output 的裝置實作方式，以符合或超過下列音訊輸出規定：

  • 冷輸出延遲時間不超過 100 毫秒
  • 連續輸出延遲時間不超過 45 毫秒
  • 盡可能減少輸出時基誤差

在使用 OpenSL ES PCM 緩衝區佇列 API 進行初始校正之後，如果裝置的實作符合本節所述的要求，至少為了透過至少一個支援的音訊輸出裝置進行連續輸出延遲和冷輸出延遲，「強烈建議」應透過 android.content.pm.PackageManager 類別回報功能 android.hardware.audio.low_Latency。相反地，如果裝置實作不符合這些要求，就「不得」回報低延遲音訊的相關支援。

極力建議您採用包含 android.hardware.microphone 的裝置實作方式，以符合下列輸入音訊規定：

  • 冷輸入延遲時間不超過 100 毫秒
  • 連續輸入延遲時間不超過 30 毫秒
  • 連續往返延遲時間不超過 50 毫秒
  • 盡可能減少冷輸入時基誤差

5.7.網路通訊協定

裝置「必須」支援播放音訊和影片播放的媒體網路通訊協定，詳情請參閱 Android SDK 說明文件。具體來說，裝置「必須」支援下列媒體網路通訊協定：

區隔格式 參考資料 必要的轉碼器支援
MPEG-2 傳輸串流 ISO 13818 視訊轉碼器：
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
如需 H264 AVC、MPEG2-4 SP 的詳細資訊，請參閱第 5.1.3 節。
以及 MPEG-2

音訊轉碼器：

  • 進階音訊編碼
如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
採用 ADTS 取景和 ID3 代碼的 AAC ISO 13818-7 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
WebVTT WebVTT

  • RTSP (RTP、SDP)

    「必須」支援下列 RTP 音訊視訊設定檔和相關轉碼器。如有例外情況，請參閱 5.1 節中的表格註釋。

設定檔名稱 參考資料 必要的轉碼器支援
H264 AVC RFC 6184 如要進一步瞭解 H264 AVC，請參閱第 5.1.3 節
MP4A-LATM RFC 6416 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
H263-1998 RFC 3551
RFC 4629
RFC 2190 		如要進一步瞭解 H263，請參閱第 5.1.3 節。
263 至 2000 年 RFC 4629 如要進一步瞭解 H263，請參閱第 5.1.3 節。
AMR RFC 4867 如要進一步瞭解 AMR-NB，請參閱第 5.1.1 節。
AMR-WB RFC 4867 如要進一步瞭解 AMR-WB，請參閱第 5.1.1 節。
MP4V-西班牙語 RFC 6416 如要進一步瞭解 MPEG-4 SP，請參閱第 5.1.3 節。
mpeg4 泛型 RFC 3640 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
MP2T RFC 2250 詳情請參閱 HTTP 直播底下的 MPEG-2 傳輸串流

5.8.安全媒體

裝置導入作業可以支援安全視訊輸出功能，並能支援安全介面，「必須」宣告支援 Display.FLAG_SECURE。宣告支援 Display.FLAG_SECURE 的裝置導入方式「必須」採用加密強度機制 (例如 HDCP 2.x 以上版本)，才能支援 Miracast 無線螢幕。同樣地，如果這些裝置支援有線外接螢幕，裝置的實作項目就「必須」支援 HDCP 1.2 以上版本。Android 電視裝置實作項目「必須」支援 HDCP 2.2，並支援支援 4K 解析度和 HDCP 1.4 以上的裝置，以便提供較低的解析度。Android 上游的開放原始碼實作包含支援無線 (Miracast) 和有線 (HDMI) 的螢幕，以符合這項規定。

5.9.樂器數位介面 (MIDI)

如果裝置實作支援應用程式內的 MIDI 軟體傳輸 (虛擬 MIDI 裝置)，且支援下列所有支援 MIDI 的硬體傳輸，且支援一般的非 MIDI 連線，就強烈建議透過 android.content.pm.PackageManager 類別回報功能對 android.software.midi 的支援。

支援 MIDI 的硬體傳輸技術如下：

  • USB 主機模式 (第 7.7 節 USB)
  • USB 週邊裝置模式 (第 7.7 節 USB)
  • 藍牙 LE 使用 MIDI 執行中央角色 (第 7.4.3 節的藍牙)

反之，如果裝置實作項目透過上述特定支援 MIDI 的硬體傳輸提供一般的非 MIDI 連線，但不支援透過該硬體傳輸使用 MIDI，就「不得」回報對 android.software.midi 功能提供支援。

5.10.專業音質

如果裝置實作符合以下所有條件，「強烈建議」透過 android.content.pm.PackageManager 類別回報 android.hardware.audio.pro 功能支援。

  • 裝置實作「必須」回報功能 android.hardware.audio.low_Delay 的支援情形。
  • 連續往返音訊延遲時間 (如第 5.6 節音訊延遲時間定義) 不得超過 20 毫秒，且至少在一個支援的路徑上應小於或等於 10 毫秒。
  • 如果裝置使用 4 導體 3.5 公釐耳機插孔，連續來回音訊延遲時間在音訊插孔路徑上應低於 20 毫秒，且音訊插孔路徑應小於 10 毫秒。
  • 裝置實作「必須」納入支援 USB 主機模式和 USB 週邊模式的 USB 連接埠。
  • USB 主機模式「必須」實作 USB 音訊類別。
  • 如果裝置有 HDMI 連接埠，裝置實作「必須」支援 8 個聲道和 8 個聲道 (解析度為 20 位元或 24 位元深度) 和 192 kHz，且不會發生位元深度損失或重新採樣。
  • 裝置實作「必須」回報功能 android.software.midi。
  • 如果裝置使用 4 指導體 3.5 公釐耳機插孔，則強烈建議導入裝置，以符合有線音訊頭戴規格 (v1.1) 的行動裝置 (插孔) 規格一節規定。

「必須」使用 OpenSL ES PCM 緩衝區佇列 API，才能符合延遲時間和 USB 音訊規定。

此外，回報支援這項功能的裝置實作項目必須：

  • 可在開啟音訊時提供穩定等級的 CPU 效能。
  • 盡量減少音訊時鐘的不準確和偏離標準時間。
  • 在兩者皆開啟時，盡量減少相對於 CPU CLOCK_MONOTONIC 的音訊時鐘偏移。
  • 盡可能縮短裝置端轉換器的音訊延遲情形。
  • 盡可能縮短 USB 數位音訊的音訊延遲情況。
  • 記錄所有路徑的音訊延遲測量結果。
  • 請盡量減少音訊緩衝區完成回呼輸入時間的時基誤差，因為這會影響回呼可用的完整 CPU 頻寬百分比。
  • 以正常使用回報的延遲時間正常使用時，避免發生音訊不足的情況 (輸出) 或超音 (輸入)。
  • 無跨管道延遲時間差異。
  • 盡可能減少所有傳輸中的 MIDI 平均延遲時間。
  • 盡量減少所有傳輸在負載 (時基誤差) 情況下的 MIDI 延遲時間變化。
  • 在所有傳輸作業中提供準確的 MIDI 時間戳記。
  • 盡量減少裝置端轉場器 (包括冷啟動後立即計時) 的音訊訊號雜訊。
  • 當兩個端點都啟用時，在對應端點的輸入和輸出端之間提供零的音訊時鐘差異。相應的端點範例包括裝置端麥克風和喇叭，或是音訊插孔輸入和輸出。
  • 在兩者皆啟用的情況下，處理同一個執行緒上對應端點的輸入和輸出端的音訊緩衝區完成回呼，並在輸入回呼的傳回後立即進入輸出回呼。如果無法在同一個執行緒上處理回呼，則在輸入輸入回呼後不久，輸入輸出回呼，讓應用程式擁有一致的輸入和輸出端時間。
  • 盡量減少對應端點的輸入和輸出端 HAL 音訊緩衝區之間的相位差異。
  • 盡可能縮短觸控延遲時間。
  • 盡量減少載入 (時基誤差) 時的觸控延遲時間變異值。

5.11.擷取尚未處理

自 Android 7.0 版本起，我們新增了錄製來源。此音訊來源可使用 android.media.MediaRecorder.AudioSource.UNPROCESSED 音訊來源存取。在 OpenSL ES 中，可使用記錄預設值 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 存取。

裝置「必須」符合下列所有規定，才能透過 android.media.AudioManager 屬性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 回報未處理的音訊來源：

  • 裝置「必須」在中頻範圍內表現出近乎平坦的振幅與頻率特性：特別是從 100 Hz 到 7000 Hz 的 ±10dB。

  • 裝置「必須」在低頻率範圍內展現振幅：特別是與中頻範圍相比，介於 5 Hz 至 100 Hz 之間的 ±20 dB 時。

  • 裝置「必須」在高頻率範圍內表現振幅：特別是與中頻範圍相比，介於 7000 Hz 至 22 KHz 之間的 ±30 dB 時。

  • 您必須設定音訊輸入靈敏度，讓以 94 dB 音壓等級 (SPL) 播放的 1000 Hz 內音色調來源能產生 RMS 為 520 的 RMS 回應 (16 位元取樣；如為浮點/雙精度取樣，則為 -36 dB Full Scale)。

  • 刺耳 >60 dB (相差 94 dB SPL 與同等的自我噪音 SPL，A 加權) 之間的差異。

  • 以 1 kHZ 為目標時，如果為 90 dB SPL 輸入音量，則總諧變形必須小於 1%。

  • 在這個路徑中，唯一可進行的信號處理作業是將等級調整至所需範圍的係數。這個等級調節係數「不得」造成信號路徑延遲或延遲。

  • 請勿在路徑中使用其他訊號處理，例如自動增益控制、高通過濾器或回音取消。如果架構中存在任何原因的信號處理，「必須」停用，才能有效地將零延遲或額外的延遲時間加入信號路徑。

所有 SPL 測量結果都直接放在受測試的麥克風旁邊。

如果設定多種麥克風，則這些需求適用於每個麥克風。

我們強烈建議裝置能滿足未處理錄製來源的信號路徑要求。不過，若裝置宣稱能夠支援未處理的音訊來源，則該裝置必須符合上述「所有」規定。

6. 開發人員工具與選項的相容性

6.1.開發人員工具

裝置實作「必須」支援 Android SDK 中提供的 Android 開發人員工具。Android 相容裝置「必須」與下列相容裝置相容：

  • Android Debug Bridge (ADB)
    • 裝置實作「必須」支援 Android SDK 中記錄的所有 ADB 函式，包括 dumpsys。
    • 裝置端的 ADB Daemon 必須預設為停用，且「必須」為使用者可存取的機制來開啟 Android Debug Bridge。如果裝置實作方式缺少 USB 週邊裝置模式，就「必須」透過本機區域網路 (例如乙太網路或 802.11) 實作 Android Debug Bridge。
    • Android 支援安全 ADB。安全 ADB 可在已知的驗證主機上啟用 ADB。裝置實作項目「必須」支援安全 ADB。
  • Dalvik 偵錯監控服務 (ddms)
    • 裝置實作「必須」支援 Android SDK 中記錄的所有 ddms 功能。
    • 由於 ddms 會使用 ADB，因此預設會停用 ddms 的支援，但當使用者啟用 Android Debug Bridge 時，「必須」提供支援。
  • Monkey 裝置實作項目「必須」包含 Monkey 架構，且可供應用程式使用。
  • SysTrace
    • 裝置實作「必須」支援 Android SDK 中記錄的 systrace 工具。Systrace 必須預設為停用，且「必須」讓使用者能存取相關機制，才能開啟 Systrace。
    • 多數 Linux 系統和 Apple Macintosh 系統都能辨識使用標準 Android SDK 工具的 Android 裝置，且無需額外的支援。然而，Microsoft Windows 系統通常需要安裝新的 Android 裝置驅動程式。(舉例來說，新的供應商 ID 和有時新裝置 ID 會需要 Windows 系統的自訂 USB 驅動程式)。
    • 如果 ADB 工具無法辨識標準 Android SDK 提供的裝置實作項目，裝置實作者「必須」提供 Windows 驅動程式，讓開發人員能夠使用 ADB 通訊協定連線至裝置。這些驅動程式「必須」針對 Windows XP、Windows Vista、Windows 7、Windows 8 和 Windows 10 提供 32 位元和 64 位元版本。

6.2.開發人員選項

Android 支援開發人員調整應用程式開發相關設定。裝置實作「必須」遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，才能顯示應用程式開發相關設定。上游 Android 實作項目預設會隱藏開發人員選項選單，讓使用者在 [設定] > [設定] 中按七 (7) 次後啟動開發人員選項關於裝置 >「Build Number」選單項目。裝置實作「必須」為開發人員選項提供一致的體驗。具體來說，裝置實作項目必須預設為隱藏開發人員選項，且「必須」提供與上游 Android 實作一致的開發人員選項。

Android Automotive 實作項目可能會在車輛行進時隱藏或停用選單，藉此限制開發人員選項選單的存取權。

7. 硬體相容性

如果裝置含有特定硬體元件，且具有第三方開發人員適用的 API，則裝置的實作「必須」按照 Android SDK 說明文件中所述實作該 API。如果 SDK 中的 API 與宣稱為選用的硬體元件互動，且裝置實作項目並未擁有該元件：

  • 您仍必須提出元件 API 的完整類別定義 (如 SDK 所述)。
  • 必須以合理的方式將 API 的行為實作為非操作。
  • 在 SDK 說明文件許可的情況下，API 方法「必須」傳回空值。
  • 若 API 說明文件不允許空值，API 方法「必須」傳回免人工管理類別的免人工管理實作項目。
  • API 方法「不得」擲回 SDK 說明文件未記錄的例外狀況。

符合這些要求適用的常見情況範例為電話 API：即使在手機以外的裝置上，這些 API 的實作方式必須合理免人工管理。

裝置實作「必須」針對同一個建構指紋，持續透過 getSystemAvailableFeatures() 及 android.content.pm.PackageManager 類別上的 hasSystemFeature(String) 方法回報準確的硬體設定資訊。

7.1.顯示和圖形

Android 包含可以自動為裝置調整應用程式資產和 UI 版面配置的功能，以確保第三方應用程式能在各種硬體設定上正常運作。裝置「必須」正確實作這些 API 和行為，如本節所述。

本節中規定所參照的單位定義如下：

  • 實際對角線大小 .顯示器的兩個反對角之間的距離 (以英寸為單位)。
  • 每英寸像素數 (dpi)。覆蓋 1 的線性水平或垂直範圍的像素數量。如果列出 dpi 值，水平和垂直 dpi 都必須落在這個範圍內。
  • 長寬比。長尺寸與螢幕短邊的像素比例。舉例來說，480x854 像素的顯示大小會是 854/480 = 1.779，或大概是「16:9」。
  • 密度獨立像素 (dp)：虛擬像素單位正規化為 160 dpi 螢幕，計算方式為：像素 = dps * (密度/160)。

7.1.1.畫面設定

7.1.1.1。螢幕大小

如本節所述，Android Watch 裝置 (詳情請見第 2 節) 可能的螢幕尺寸較小。

Android UI 架構支援各種不同螢幕大小，可讓應用程式透過 android.content.res.Configuration.screenLayout 透過 SCREENLAYOUT_SIZE_MASK 查詢裝置螢幕大小 (又稱「螢幕版面配置」)。裝置導入作業「必須」回報 Android SDK 說明文件中定義的正確螢幕大小，並由上游 Android 平台決定。具體來說，裝置實作「必須」根據下列邏輯密度獨立像素 (dp) 螢幕尺寸回報正確的螢幕大小。

  • 裝置的螢幕尺寸必須至少為 426 dp x 320 dp (「小」)，除非是 Android Watch 裝置。
  • 如果裝置的螢幕大小設為「一般」，螢幕尺寸至少必須為 480 dp x 320 dp。
  • 尺寸為「大」的裝置必須搭載至少 640 dp x 480 dp 的螢幕。
  • 表示螢幕大小為「xlarge」的裝置必須搭載至少 960 dp x 720 dp。

此外：

  • Android Watch 裝置螢幕的對角線長度必須介於 1.1 到 2.5 吋之間。
  • Android Automotive 裝置的螢幕對角線長度必須大於或等於 6 吋。
  • Android Automotive 裝置的螢幕大小不得小於 750 dp x 480 dp。
  • 其他類型的 Android 裝置實作方式，與實體整合的螢幕必須保持至少 2.5 吋的螢幕對角線大小。

裝置「不得」隨時變更回報的螢幕大小。

應用程式可選擇透過 <supports-screen> 指出支援的螢幕大小屬性。裝置實作方式「必須」正確遵循應用程式」明文支援小、一般、大螢幕和超大型螢幕支援，如 Android SDK 說明文件所述。

7.1.1.2。螢幕顯示比例

雖然實體螢幕的螢幕顯示比例沒有限制，但第三方應用程式算繪的介面螢幕顯示比例必須符合透過 DisplayMetrics 回報的值，而且必須符合下列規定：

  • 如果 uiMode 設為 UI_MODE_TYPE_WATCH，則顯示比例值 MAY 會設為 1.0 (1:1)。
  • 如果第三方應用程式指出可透過 android:resizeableActivity 屬性調整大小，則長寬比值沒有限制。
  • 在其他情況下，除非應用程式已透過 maxAspectRatio 中繼資料值明確指出其支援較高的螢幕顯示比例，否則顯示比例「必須」是介於 1.3333 (4:3) 到 1.86 (約 16:9) 之間的值。

7.1.1.3.螢幕密度

Android UI 架構定義了一組標準邏輯密度，協助應用程式開發人員指定應用程式資源。裝置實作項目「必須」只透過 android.util.DisplayMetrics API 回報下列其中一個 Android 邏輯架構密度，且「不得」以這個標準密度執行應用程式，且「不得」隨時變更預設顯示畫面的值。

  • 120 dpi (ldpi)
  • 160 dpi (mdpi)
  • 213 dpi (tvdpi)
  • 240 dpi (hdpi)
  • 280 dpi (280dpi)
  • 320 dpi (xhdpi)
  • 360 dpi (360dpi)
  • 400 dpi (400dpi)
  • 420 dpi (420dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

裝置實作項目「必須」定義最接近螢幕實體密度的標準 Android 架構密度，除非該邏輯密度會將回報的螢幕大小推進低於支援下限。如果標準 Android 架構密度的數值接近實體密度，且螢幕尺寸小於支援的最小相容螢幕尺寸 (320 dp 寬度)，則裝置實作應會回報下一個最低標準 Android 架構密度。

我們強烈建議導入裝置，為使用者提供變更顯示大小的設定。如果有實作方式會變更裝置顯示大小，則必須根據下列 Android 開放原始碼計畫實作項目進行調整：

  • 顯示大小「不得」縮放至任何大於原生密度的 1.5 倍，或產生小於 320dp (相當於資源限定詞 sw320dp) 的有效最小螢幕尺寸 (以先發生者為準)。
  • 螢幕大小不得小於原生密度的 0.85 倍。
  • 為確保良好的可用性並維持一致的字型大小，建議您提供下列原生多媒體廣告選項縮放比例 (但需遵守上述限制)。
  • 小：0.85x
  • 預設：1x (原生多媒體縮放比例)
  • 大：1.15 倍
  • 較大：1.3 倍
  • 最大 1.45 倍

7.1.2.顯示指標

裝置實作「必須」針對 android.util.DisplayMetrics 中定義的所有顯示指標回報正確值，且無論預設顯示畫面是內嵌或外部畫面，都必須回報相同的值。

7.1.3.螢幕方向

裝置必須回報其支援的螢幕方向 (android.hardware.screen.portrait 和/或 android.hardware.screen.landscape)，且至少「必須」回報一種支援的螢幕方向。舉例來說，如果裝置螢幕方向為固定的橫向螢幕 (例如電視或筆電)，就只能回報 android.hardware.screen.landscape。

如果裝置同時回報兩種螢幕方向，「必須」能夠讓應用程式能支援直向或橫向螢幕方向的動態螢幕方向。也就是說，裝置必須遵循應用程式的特定螢幕方向要求。導入裝置時，可以選取直向或橫向做為預設方向。

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

變更螢幕方向時，裝置「不得」變更回報的螢幕大小或密度。

7.1.4。2D 和 3D 圖形加速

裝置實作「必須」同時支援 OpenGL ES 1.0 和 2.0，詳情請參閱 Android SDK 說明文件。裝置實作應在支援 OpenGL ES 3.0、3.1 或 3.2 的裝置上支援 OpenGL ES 3.0、3.1 或 3.2。裝置導入方式「必須」支援 Android RenderScript，詳情請見 Android SDK 說明文件。

裝置實作也必須正確識別為支援 OpenGL ES 1.0、OpenGL ES 2.0、OpenGL ES 3.0、OpenGL 3.1 或 OpenGL 3.2。具體說明如下：

  • 代管 API (例如透過 GLES10.getString() 方法) 「必須」回報支援 OpenGL ES 1.0 和 OpenGL ES 2.0 的支援機制。
  • 原生 C/C++ OpenGL API (透過 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 供應用程式使用的 API)「必須」回報支援 OpenGL ES 1.0 和 OpenGL ES 2.0 的支援功能。
  • 宣告支援 OpenGL ES 3.0、3.1 或 3.2 的裝置實作項目「必須」支援對應的代管 API，並支援原生 C/C++ API。在宣告支援 OpenGL ES 3.0、3.1 或 3.2 libGLESv2.so 的裝置上實作項目，除了 OpenGL ES 2.0 函式符號外，「必須」匯出對應的函式符號。

Android 提供具備 Java 介面的 OpenGL ES 擴充功能套件，並原生支援網路銷售和 ASTC 紋理壓縮格式等進階圖形功能。如果裝置支援 OpenGL ES 3.2，且 MAY 支援其他擴充功能，則 Android 裝置實作項目「必須」支援擴充套件。如果擴充功能包完整受到支援，裝置「必須」透過 android.hardware.opengles.aep 功能標記識別支援。

此外，裝置實作項目可能會實作任何所需的 OpenGL ES 擴充功能。不過，裝置導入方式「必須」透過 OpenGL ES 管理和原生 API 回報所有支援的擴充功能字串，反之亦然。此外，「不得」回報不支援的擴充功能字串。

請注意，Android 支援讓應用程式選擇需要特定的 OpenGL 紋理壓縮格式。這些格式通常視供應商而定。Android 不需要實作裝置，也能實作任何特定的紋理壓縮格式。但必須透過 OpenGL API 中的 getString() 方法，準確回報支援的任何紋理壓縮格式。

Android 提供了一個機制，可讓應用程式宣告要使用資訊清單標記 android:hardwareAccelerated 或直接 API 呼叫，在應用程式、活動、視窗或檢視畫面層級啟用 2D 圖形的硬體加速功能。

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

此外，裝置的實作行為「必須」顯示與硬體加速 Android SDK 說明文件一致的行為。

Android 包含 TextureView 物件，可讓開發人員直接整合硬體加速的 OpenGL ES 紋理，做為 UI 階層中的算繪目標。裝置實作項目「必須」支援 TextureView API，且「必須」顯示與上游 Android 實作一致的行為。

Android 支援 EGL_ANDROID_RECORDABLE EGLConfig 屬性，EGLConfig 屬性表示 EGLConfig 是否支援算繪至影片圖像的 ANativeWindow。裝置實作項目必須支援 EGL_ANDROID_RECORDABLE 擴充功能。

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

Android 會指定「相容性模式」，讓架構以「正常」狀態運作螢幕尺寸等效 (320dp 寬度) 模式，適用於未針對未依螢幕尺寸獨立而開發的舊版 Android 開發的舊版應用程式。

  • Android Automotive 不支援舊版相容性模式。
  • 所有其他實作裝置「必須」提供對上游 Android 開放原始碼實作的舊版應用程式相容性模式的支援。也就是說，裝置實作「不得」變更啟用相容性模式時的觸發條件或門檻，「不得」變更相容性模式本身的行為。

7.1.6。螢幕技術

Android 平台的 API 可讓應用程式在螢幕上算繪豐富的圖形。除非本文件特別許可，否則裝置「必須」支援 Android SDK 定義的所有 API。

  • 裝置「必須」支援能夠呈現 16 位元色彩圖形的螢幕，且必須支援能夠顯示 24 位元色彩圖形的螢幕。
  • 裝置「必須」支援能夠轉譯動畫的螢幕。
  • 使用的顯示技術「必須」介於 0.9 和 1.15 之間的像素顯示比例 (PAR)。也就是說，像素顯示比例必須接近 1.0 正方形 (寬 10 ~ 15%)，

7.1.7.第二螢幕

Android 支援次要螢幕，可啟用媒體分享功能，以及用來存取外部螢幕的開發人員 API。如果裝置透過有線、無線或內嵌式額外顯示連線支援外接螢幕，則裝置的實作方式「必須」按照 Android SDK 說明文件中所述導入 Display Manager API。

7.2.輸入裝置

裝置「必須」支援觸控螢幕，或符合 7.2.2 中非觸控瀏覽功能的規定。

7.2.1。鍵盤

實作 Android Watch 和 Android Automotive 時，可能會實作螢幕鍵盤。所有其他裝置實作都「必須」實作螢幕鍵盤以及：

裝置實作方式：

  • 「必須」支援輸入管理架構 (可讓第三方開發人員建立輸入法編輯器，即螢幕鍵盤)，詳情請見 http://developer.android.com。
  • 「必須」提供至少一種螢幕鍵盤實作方式 (不論硬體鍵盤是否存在)，但 Android Watch 裝置螢幕尺寸會使螢幕鍵盤不合乎彈性。
  • 可加入其他螢幕鍵盤實作。
  • 可提供實體鍵盤。
  • 「不得」包含不符合 android.content.res.Configuration.keyboard (QWERTY 或 12 鍵) 指定格式的硬體鍵盤。

7.2.2。非觸控瀏覽

Android 電視裝置「必須」支援 D-Pad。

裝置實作方式：

  • 如果裝置實作的裝置不是 Android 電視裝置，可省略非觸控瀏覽選項 (軌跡球、D-Pad 或滾輪)。
  • 必須回報 android.content.res.Configuration.navigation 的正確值。
  • 「必須」配合輸入管理引擎，提供合理的替代使用者介面機制選取及編輯文字。上游 Android 開放原始碼實作包含選取機制，適合缺少非觸控瀏覽輸入裝置的裝置使用。

7.2.3.瀏覽鍵

主畫面、近期和返回功能的適用情形和瀏覽權限規定會因裝置類型而異，如本節所述。

Home、近期和返回函式 (分別對應至重要事件 KEYCODE_HOME、KEYCODE_APP_SWITCH、KEYCODE_BACK) 是 Android 導覽範例中的基本功能，因此：

  • Android 手持裝置實作「必須」提供主畫面、近期和返回功能。
  • Android TV 裝置實作「必須」提供主畫面和返回功能。
  • Android Watch 裝置的實作「必須」為使用者提供主畫面功能和返回功能，但位於 UI_MODE_TYPE_WATCH 時除外。
  • Android Watch 裝置實作方式及其他 Android 裝置類型，都「可能」會使用重要事件 KEYCODE_BACK 上的長按事件，不需要將其傳送至前景應用程式。
  • Android Automotive 實作項目「必須」提供主畫面功能，且「可能」提供返回和最近功能。
  • 所有其他類型的裝置實作都「必須」提供主畫面和返回功能。

這些功能「或許」可透過專用實體按鈕 (例如機械或電容式觸控按鈕) 實作，或者「可能」可以在螢幕的不同部分使用專屬軟體鍵、手勢、觸控面板等實作。Android 支援這兩種實作方式。這些函式必須顯示時，只能透過單一動作 (例如輕觸、按兩下或手勢) 存取。

最近使用的功能 (如有提供) 必須顯示可見的按鈕或圖示，除非在全螢幕模式中與其他導覽功能一併隱藏。如果裝置搭載的 Android 版本較舊，且有實體按鈕可供瀏覽，沒有最近使用按鍵，則不適用。

主畫面和返回功能 (如有提供) 「必須」各有一個可見按鈕或圖示，除非在全螢幕模式中與其他導覽功能一併隱藏，或者當 uiMode UI_MODE_TYPE_MASK 設為 UI_MODE_TYPE_WATCH。

自 Android 4.0 版起，選單函式已淘汰，請改用動作列。因此，搭載 Android 7.0 以上版本的新裝置「不得」為選單函式實作專屬實體按鈕。舊版裝置「請勿」為選單功能實作專屬的實體按鈕，但如果已實作實體選單按鈕，且裝置正在執行含有 targetSdkVersion > 的應用程式，則10，裝置實作：

  • 當動作列顯示動作溢位按鈕時，「必須」在動作列中顯示動作溢位按鈕，且產生的動作溢位選單彈出式視窗不可空白。對於 Android 4.4 以下版本但升級至 Android 7.0 之前推出的裝置實作項目，建議您採取這種做法。
  • 「不得」透過選取動作列中的溢位按鈕，修改顯示動作溢位彈出式視窗的位置。
  • 選取實體選單按鈕，即可在畫面上修改時，在畫面上的修改位置顯示動作溢位彈出式視窗。

為了達到回溯相容性，裝置實作「必須」在 targetSdkVersion 小於 10 時 (透過實體按鈕、軟體鍵或手勢)，為應用程式提供選單功能。除非將選單函式與其他導覽功能一併隱藏，否則應顯示這個選單函式。

如果 Android 裝置實作支援支援輔助動作和/或 VoiceInteractionService，則必須能在其他瀏覽鍵顯示時，透過單一互動 (例如輕觸、按兩下或手勢) 啟動輔助應用程式。我們強烈建議你長按主畫面，做為這類互動。指定的互動「必須」啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 或處理 ACTION_ASSIST 意圖的活動。

裝置實作方式「可能」會在畫面上顯示瀏覽鍵的不同部分，但如果是，就「必須」符合以下規定：

  • 裝置實作瀏覽鍵「必須」使用螢幕上的特定部分，且不能用於應用程式，而且「不得」遮蓋或乾擾應用程式畫面顯示的部分。
  • 裝置導入方式「必須」為符合第 7.1.1 節所列規定的應用程式提供一部分的顯示畫面。
  • 如果應用程式未指定系統 UI 模式，或指定 SYSTEM_UI_FLAG_VISIBLE，裝置實作「必須」顯示瀏覽鍵。
  • 裝置實作項目「必須」在應用程式指定 SYSTEM_UI_FLAG_LOW_PROFILE 時，以不會幹擾使用者的「低設定檔」(例如變暗) 模式顯示瀏覽鍵。
  • 應用程式指定 SYSTEM_UI_FLAG_HIDE_NAVIGATION 時，裝置實作「必須」隱藏瀏覽鍵。

7.2.4。觸控螢幕輸入

Android 手持裝置和手錶裝置必須支援觸控螢幕輸入。

實作裝置應使用某種指標輸入系統 (類似滑鼠或觸控)。不過，如果裝置的實作不支援指標輸入系統，就「不得」回報 android.hardware.touchscreen 或 android.hardware.faketouch 功能常數。包含指標輸入系統的裝置實作方式：

Android 支援多種觸控螢幕、觸控板和模擬觸控輸入裝置，以觸控螢幕為基礎的裝置實作方式會與螢幕建立關聯，讓使用者擁有直接操控畫面上的項目。由於使用者是直接觸碰螢幕，系統並不需要任何額外的預設用途來表示受操控的物件。相反地，觸控模擬介面會提供使用者輸入系統，可近似一部分的觸控螢幕功能。舉例來說，如果滑鼠或遙控器驅動螢幕上的遊標大約觸控，但使用者必須先找到第一個點或焦點，接著點選該控制項，許多輸入裝置 (例如滑鼠、觸控板、陀螺儀、陀螺儀、陀螺儀、搖桿和多點觸控觸控板等，都能支援觸控模擬的互動。Android 加入功能常數 android.hardware.faketouch，對應到高保真非觸控 (以指標為基礎的) 輸入裝置，例如可以適當模擬觸控輸入 (包括基本手勢支援) 的滑鼠或觸控板，也代表裝置支援模擬的觸控螢幕功能子集。宣告假觸控功能的裝置實作方式「必須」符合第 7.2.5 節的假觸控規定。

裝置實作時，必須根據所用輸入類型回報正確功能。包含觸控螢幕 (單點觸控或更高) 的裝置實作「必須」回報平台功能常數 android.hardware.touchscreen。回報平台功能常數 android.hardware.touchscreen 的裝置實作「必須」同時回報平台功能常數 android.hardware.faketouch。如果裝置實作項目沒有觸控螢幕 (且僅仰賴指標裝置)，則「不得」回報任何觸控螢幕功能，而且只要符合第 7.2.5 節的假觸控規定，就只能回報 android.hardware.faketouch。

7.2.5。虛擬觸控輸入

宣告支援 android.hardware.faketouch 的裝置實作方式：

  • 必須回報指標位置的絕對 X 和 Y 螢幕位置，並在螢幕上顯示視覺指標。
  • 必須回報觸控事件，並提供指定畫面向下或向上指標狀態變更的動作代碼。
  • 必須支援螢幕上物件的上下指標，讓使用者模擬輕觸畫面上的物件。
  • 必須支援指標向下、向上指標、將遊標停在螢幕的相同位置上，且於時間門檻內的相同位置上，使用者能夠模擬螢幕上的物體輕觸兩下。
  • 必須支援在螢幕上任意位置向下的指標，並先移到螢幕上的任何任意點，接著使用向上指標 (可讓使用者模擬觸控拖曳動作)。
  • 必須支援向下指標，才能讓使用者快速將物件移到螢幕上的其他位置，然後往畫面上向上移動，讓使用者可以快速滑過螢幕上的物件。

如果裝置宣告支援 android.hardware.faketouch.multitouch.distinct，則「必須」符合上述假觸控規定，且「必須」支援兩個以上獨立指標輸入項目的不同追蹤方式。

7.2.6。遊戲控制器支援

Android TV 裝置實作「必須」支援遊戲控制器的按鈕對應，如下所列。Android 上游實作包括為符合這項規定的遊戲控制器實作。

7.2.6.1。按鈕對應

Android TV 裝置實作「必須」支援下列按鍵對應：

按鈕 HID 用量 2 Android 按鈕
A 1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B 1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X 1 0x09 0x0004 KEYCODE_BUTTON_X (99)
是 1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-Pad 向上鍵 1
D-Pad 1 		0x01 0x0039 3 AXIS_HAT_Y 4
D-Pad 左 1
D-Pad 向右鍵 1 		0x01 0x0039 3 AXIS_HAT_X 4
左肩按鈕 1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
右肩按鈕 1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
按一下左搖桿 1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
按一下滑鼠右鍵 1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
首頁 1 0x0c 0x0223 KEYCODE_HOME (3)
返回 1 0x0c 0x0224 KEYCODE_BACK (4)

1 個 KeyEvent

2 您必須在遊戲板 CA (0x01 0x0005) 中宣告上述 HID 用法。

3 這個使用方法必須有邏輯下限 0、邏輯上限 7、實體最小容量 0 和 315 以下、實體最大 315、單位 (以度為單位)，以及報告大小為 4。邏輯值定義為與垂直軸順時針旋轉。舉例來說，邏輯值 0 表示沒有旋轉，按下向上按鈕；邏輯值 1 則代表旋轉 45 度，同時按下向上鍵和向左鍵。

4 MotionEvent

類比控制項 1 HID 用量 Android 按鈕
離開觸發條件 0x02 0x00C5 AXIS_LTRIGGER
右側觸發條件 0x02 0x00C4 AXIS_RTRIGGER
左搖桿 0x01 0x0030
0x01 0x0031 		AXIS_X
AXIS_Y
右搖桿 0x01 0x0032
0x01 0x0035 		AXIS_Z
AXIS_RZ

1 個 MotionEvent

7.2.7。遙控器

Android 電視裝置實作「必須」提供遙控器，讓使用者存取電視介面。遙控器可以是實體遙控器，也可以是可透過手機或平板電腦存取的軟體式遙控器。遙控器「必須」符合以下定義的規定。

  • 搜尋預設用途 .當使用者透過實體或軟體式遙控器叫用語音搜尋時，裝置導入方式「必須」觸發 KEYCODE_SEARCH。
  • 導覽 .所有 Android 電視遙控器「必須」包含「返回」、「主畫面」和「選取」按鈕，以及 D-Pad 事件支援。

7.3.感應器

Android 包含用於存取各種感應器類型的 API。實作裝置通常「可」省略這些感應器，如以下子章節所述。如果裝置搭載的特定感應器類型有第三方開發人員適用的 API，則裝置的實作「必須」按照 Android SDK 說明文件及有關感應器的 Android 開放原始碼說明文件實作該 API。例如以下裝置導入方式：

  • 請務必根據 android.content.pm.PackageManager 類別準確回報感應器是否存在。
  • 「必須」透過 SensorManager.getSensorList() 和類似方法傳回支援的感應器清單。
  • 對所有其他感應器 API 必須合理執行 (例如，在應用程式嘗試註冊事件監聽器時視情況傳回 true 或 false，而在沒有對應的感應器存在時，才呼叫感應器事件監聽器等)。
  • 「必須」根據 Android SDK 說明文件中定義的各種感應器類型，使用相關國際單位 (公制) 值回報所有感應器測量結果。
  • 應以 Android SDK 說明文件中定義的定義回報事件時間 (以奈秒為單位)，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘同步。強烈建議現有和新的 Android 裝置符合這些規定，以便升級至日後推出的平台版本，做為「必要」元件。同步處理錯誤應小於 100 毫秒。
  • 只有在應用程式處理器處於啟用狀態時，感應器資料串流的延遲時間最長為 100 毫秒 + 2 * sample_time，才能回報感應器資料，延遲時間最短為 5 毫秒 + 2 *。此延遲未包含任何篩選延遲。
  • 必須在感應器啟用的 400 毫秒 + 2 * sample_time 內，回報第一個感應器樣本。此樣本的準確率為 0，可以接受。

上方清單僅列舉部分內容；記載 Android SDK 和感應器的 Android 開放原始碼說明文件行為，視為具公信力。

某些感應器類型是複合資料，因此可從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速感應器)。實作裝置時，如果感應器含有必要的實體感應器，應導入這些感應器類型 (如感應器類型所述)。如果裝置實作項目包含複合感應器，則「必須」按照 Android 開放原始碼說明文件複合感應器所述方式實作感應器。

部分 Android 感應器支援「連續」觸發模式，可持續傳回資料。如果 Android SDK 說明文件指出的 API 是連續的感應器，裝置導入作業「必須」持續提供週期性資料樣本，且取樣率應低於 3%；而時基誤差的定義為連續事件回報的時間戳記值差異的標準差。

請注意，裝置的實作「必須」確保感應器事件串流「不得」阻止裝置 CPU 進入暫停狀態或喚醒暫停狀態。

最後，如果啟動多個感應器，耗電量不應超過個別感應器回報的耗電量總和。

7.3.1。加速計

實作裝置須包含 3 軸式加速度計。我們強烈建議將 Android 手持裝置、Android Automotive 實作項目和 Android Watch 裝置納入這個感應器。如果裝置實作包含 3 軸式加速度計，請按照下列步驟操作：

  • 必須導入並回報 TYPE_ACCELEROMETER 感應器。
  • 裝置必須能夠以至少 50 Hz 的頻率回報 Android Watch 裝置發生的事件，例如針對所有其他裝置類型，系統設有更嚴格的電源限制條件 (100 Hz)。
  • 回報的事件大小必須至少為 200 Hz。
  • 必須遵循 Android API 中詳述的 Android 感應器座標系統。Android Automotive 實作項目「必須」符合 Android 車輛感應器座標系統。
  • 一定要能夠在任何軸上測量重力 (4 公克) 或以上重力四倍以上的測量值。
  • 「必須」採用至少 12 位元的解析度，且至少應具備 16 位元的解析度。
  • 如果生命週期內的特性在生命週期內有所變化並已補償，使用時應進行校正，並保留裝置重新啟動之間的補償參數。
  • 應針對溫度獲得補償。
  • 標準差不得大於 0.05 m/s^。標準差應根據百分率 (至少 3 秒) 收集到的樣本，根據每軸計算標準差。
  • 「必須」實作 Android SDK 文件所述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。現有和新 Android 裝置都強烈建議實作 TYPE_SIGNIFICANT_MOTION 複合感應器。如果已實作上述任一感應器，其耗電量總和必須一律小於 4 毫瓦，且處於動態或靜態狀態時皆應低於 2 毫瓦和 0.5 mW。
  • 如果內含陀螺儀感應器，「必須」實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器，並「應」實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。現有和新 Android 裝置極力建議實作 TYPE_GAME_ROTATION_VECTOR 感應器。
  • 如果隨附陀螺儀感應器和磁力儀感應器，請採用 TYPE_ROTATION_VECTOR 複合感應器。

7.3.2。磁力儀

實作裝置須包含 3 軸式磁力計 (指南針)。如果裝置確實附有 3 軸的磁力儀，則表示：

  • 「必須」實作 TYPE_MAGNETIC_FIELD 感應器，並 SHOULD 也必須實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。現有和新 Android 裝置極力建議實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。
  • 您能夠以至少 10 Hz 的頻率回報事件，並且應回報至少 50 Hz 的事件。
  • 必須遵循 Android API 中詳述的 Android 感應器座標系統。
  • 必須能夠測量每軸介於 -900 μT 和 +900 μT 之間的距離，然後才能進出飽和度。
  • 必須設定小於 700 μT 的硬鐵偏移值，且磁力儀值必須遠離動態 (誘發) 和靜態 (誘發磁鐵) 磁場，且值必須小於 200 μT。
  • 解析度必須等於或小於 0.6 μT，且解析度必須等於或大於 0.2 μT。
  • 應針對溫度獲得補償。
  • 「必須」支援線上校正及彌補硬鐵偏誤情形，並保留裝置重新啟動時的補償參數。
  • 「必須」使用軟鐵補償，裝置可在使用時或裝置生產期間進行校正。
  • 應有標準差 (以每軸計)。計算期間，取樣率至少應達到 3 秒，且取樣率達到最快的取樣率，且不超過 0.5 μT。
  • 如果隨附加速計感應器和陀螺儀感應器，請務必導入 TYPE_ROTATION_VECTOR 複合感應器。
  • 如果同時安裝了 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器，請自行實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。不過實作後，如果以 10 Hz 的方式註冊感應器，其耗電量必須低於 10 mW，且耗電量必須低於 3 mW。

7.3.3.全球衛星定位系統 (GPS)

裝置的實作應包括 GPS/GNSS 接收器。如果裝置實作包含 GPS/GNSS 接收器，且透過 android.hardware.location.gps 功能標記向應用程式回報功能：

  • 強烈建議裝置在緊急電話通話期間持續將正常 GPS/GNSS 輸出給應用程式，且在緊急電話通話期間不會封鎖該位置的輸出。
  • 透過 LocationManager#requestLocationUpdate 發出要求時，必須能以至少 1 Hz 的速率輸出位置資訊。
  • 連上 0.5 Mbps 或更快的數據速度網路連線時，這個模式必須能夠在 10 秒內 (使用強勁訊號、可忽略多徑、HDOP < 2) 判斷在開放天際間的位置。通常使用某種輔助或預測的 GPS/GNSS 技術來盡可能縮短 GPS/GNSS 鎖定時間 (輔助資料包含參考時間、參考位置和衛星電話/時鐘)。
    • 計算這類位置後，「強烈建議」裝置在 10 秒內、在開始位置要求時 (在初次計算位置要求後的一小時內，即使在沒有數據連線的情況下提出後續要求及/或重新開機) 判斷其位置。
  • 判斷地點後，在開闊的天空的情況下，靜止或移動的加速度小於每秒 1 公尺的平方：
    • 裝置必須能夠判斷所在位置在 20 公尺以內，且速度在每秒 0.5 公尺以內，且時間至少為 95%。
    • 「必須」同時透過 GnssStatus.Callback 追蹤並回報至少 8 個衛星的衛星影像。
    • 它至少能夠同時追蹤 24 個來自多個星座的衛星 (例如：GPS 以及至少一種全球衛星定位系統、北斗、Galileo)。
  • 「必須」透過測試 API「getGnssYearOfHardware」回報 GNSS 技術產生資訊。
  • 如果 GNSS 技術的生成結果是「2016 年」年度的報告，極力建議您符合以下所有條件，且「必須」符合所有規定或更新版本。
    • 它必須在找到 GPS 測量結果後立即回報，即使尚未回報來自 GPS/GNSS 的位置亦然。
    • 它「必須」回報 GPS 虛擬範圍和虛擬範圍速率，在確定地點之後，若是靜止或移動的加速度在每秒低於 0.2 公尺的平方，就足以計算出 20 公尺以內的位置，且速度在每秒 0.2 公尺內，且速度至少為每秒 95%。

請注意，雖然上述部分 GPS 需求被明確表示「建議」相同，但下一個主要版本的相容性定義應變更為「必須」。

7.3.4。陀螺儀

裝置實作應使用陀螺儀 (角度變化感應器)。裝置不應使用陀螺儀感應器，除非隨附 3 軸式加速度計。如果裝置導入作業包含陀螺儀，這項功能會：

  • 「必須」實作 TYPE_GYROSCOPE 感應器，並應實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。極力建議現有和新的 Android 裝置實作 SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 感應器。
  • 必須能夠測量每秒高達 1,000 度方向的變化。
  • 裝置必須能夠以至少 50 Hz 的頻率回報 Android Watch 裝置發生的事件，例如針對所有其他裝置類型設定更嚴格的電源限制條件 (100 Hz)。
  • 回報的事件大小必須至少為 200 Hz。
  • 必須採用 12 位元以上的解析度，並具備 16 位元以上的解析度。
  • 必須補償溫度。
  • 使用時請務必進行校準及補償，並在裝置重新啟動時保留補償參數。
  • 變異數必須不超過 1e-7 rad^2/s^2/Hz (每 Hz 變異數，或 rad^2/s)。變異數可以隨取樣率而異，但必須限制這個值。換句話說，假設您以 1 Hz 的取樣率測量陀螺儀的變異數，值不應大於 1e-7 rad^2/s^2。
  • 如果隨附加速計感應器和磁力儀感應器，請採用 TYPE_ROTATION_VECTOR 複合感應器。
  • 如果內含加速計感應器，「必須」實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器，並「應」實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。現有和新 Android 裝置極力建議實作 TYPE_GAME_ROTATION_VECTOR 感應器。

7.3.5。氣壓計

實作裝置應提供氣壓計 (環境氣壓感應器)。如果裝置導入作業內含氣壓計，系統會：

  • 必須導入並回報 TYPE_PRESSURE 感應器。
  • 必須能夠以 5 Hz 以上的傳送事件傳送。
  • 必須有足夠的精確度，系統才能估算海拔高度。
  • 必須補償溫度。

7.3.6。溫度計

實作裝置可能包括環境溫度計 (溫度感應器)。如果有的話，則必須定義為 SENSOR_TYPE_AMBIENT_TEMPERATURE，且「必須」測量以攝氏度為單位的環境 (室溫)。

可導入的裝置不一定包含 CPU 溫度感應器。這項屬性必須定義為 SENSOR_TYPE_TEMPERATURE，「必須」測量裝置 CPU 的溫度，且「不得」測量任何其他溫度。請注意，Android 4.0 已淘汰 SENSOR_TYPE_TEMPERATURE 感應器類型。

實作 Android Automotive 時，SENSOR_TYPE_AMBIENT_TEMPERATURE「必須」測量車廂內的溫度。

7.3.7。相框模式

實作裝置可能包括光度感應器 (環境光度感應器)，

7.3.8。鄰近感應器

實作裝置可能包含鄰近感應器。可撥打語音通話且在 getPhoneType 中表示 PHONE_TYPE_NONE 以外任何值的裝置，「必須」使用鄰近感應器。如果裝置的實作方式包含鄰近感應器，就會：

  • 必須朝與螢幕同方向測量物體的距離。也就是說，鄰近感應器必須設為偵測畫面附近的物體，因為這類感應器類型的主要用途是偵測使用者正在使用的手機。如果裝置實作項目包含具有任何其他方向的鄰近感應器，就「不得」透過此 API 存取。
  • 準確度必須達到 1 位元以上。

7.3.9。高保真感測器

如果裝置的實作支援一組高品質感應器，這些感應器必須符合本節列出的所有規定，就「必須」透過 android.hardware.sensor.hifi_sensors 功能旗標找出支援。

宣告 android.hardware.sensor.hifi_sensors 的裝置「必須」支援下列所有符合品質規定的感應器類型：

  • SENSOR_TYPE_ACCELEROMETER
    • 測量範圍必須介於 -8 公克和 +8 公克之間。
    • 解析度至少須為 1024 LSB/G。
    • 測量頻率不得低於 12.5 Hz。
    • 測量頻率上限為 400 Hz 以上。
    • 測量噪音必須不能超過 400 uG/√Hz。
    • 這個感應器必須採用至少 3,000 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
    • 批次耗電量不得低於 3 毫瓦。
    • 24 小時的靜態資料集應有固定的雜訊偏誤，穩定度為 \<15 μg √Hz。
    • 應該有偏誤變化，而不是溫度 ≤ +/- 1 毫克 / °C。
    • 應採用 ≤ 0.5% 且靈敏度與溫度變化 (相較於溫度 ≤ 0.03%/C°) 的非線性體系非線性性。

  • SENSOR_TYPE_GYROSCOPE

    • 測量範圍必須至少介於 -1,000 到 +1000 dp。
    • 測量解析度必須至少為 16 LSB/dp。
    • 測量頻率不得低於 12.5 Hz。
    • 測量頻率上限為 400 Hz 以上。
    • 測量噪音必須超過 0.014°/s/√Hz。
    • 是否穩定性為 <0.0002 °/s √Hz (24 小時靜態資料集)。
    • 應該有偏誤變化，而不是溫度 ≤ +/- 0.05 °/ s / °C。
    • 應有靈敏度變化，但溫度應為 ≤ 0.02% / °C。
    • 應採用最佳適配線非線性性，且不超過 0.2%。
    • 雜訊密度必須小於 0.007 °/s/√Hz。

  • SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 的品質需求與 SENSOR_TYPE_GYROSCOPE 相同。

  • SENSOR_TYPE_GEOMAGNETIC_FIELD
    • 測量範圍必須至少介於 -900 到 +900 uT 之間。
    • 必須採用至少 5 LSB/uT 的測量解析度。
    • 測量頻率不得低於 5 Hz。
    • 測量頻率上限為 50 Hz 以上。
    • 測量噪音必須超過 0.5 uT。
  • SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED 的品質需求與 SENSOR_TYPE_GEOMAGNETIC_FIELD 相同，此外：
    • 這個感應器必須採用至少 600 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • SENSOR_TYPE_PRESSURE
    • 測量範圍必須介於 300 到 1100 hPa 之間。
    • 必須採用至少 80 LSB/hPa 的測量解析度。
    • 測量頻率不得低於 1 Hz。
    • 測量頻率上限為 10 Hz。
    • 測量噪音必須不能超過 2 Pa/√Hz。
    • 這個感應器必須採用至少 300 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
    • 批次耗電量不得低於 2 mW。
  • SENSOR_TYPE_GAME_ROTATION_VECTOR
    • 這個感應器必須採用至少 300 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
    • 批次耗電量不得低於 4 mW。
  • SENSOR_TYPE_SIGNIFICANT_MOTION
    • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
  • SENSOR_TYPE_STEP_DETECTOR
    • 這個感應器必須採用至少 100 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
    • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
    • 批次耗電量不得低於 4 mW。
  • SENSOR_TYPE_STEP_COUNTER
    • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。
  • SENSOR_TILT_DETECTOR
    • 裝置為靜止狀態時，耗電量不得低於 0.5 mW，移動時耗電量至少為 1.5 mW。

這類裝置還必須符合下列感應器子系統需求：

  • 同一實體事件的事件時間戳記 (由加速計、陀螺儀感應器和磁力儀) 彼此間隔須不超過 2.5 毫秒。
  • 陀螺儀感應器事件的時間戳記必須與相機子系統相同，且誤差不超過 1 毫秒。
  • 從實體感應器可取得資料時，高擬真度感應器「必須」在 5 毫秒內將樣本提供給應用程式。
  • 啟用下列任一感應器時，裝置為靜止狀態時，耗電量「必須」低於 0.5 mW；當裝置在移動時，耗電量最多為 2.0 mW：
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

請注意，本節所述的所有耗電量要求，都不包含「應用程式處理器」的耗電量。其內含整個感應器鏈的力量，包括感應器、輔助電路、任何專用感應器處理系統等。

在宣告 android.hardware.sensor.hifi_sensors 裝置上，「可能」也支援下列感應器類型，但只要具備這些感應器類型，就「必須」符合下列最低緩衝功能要求：

  • SENSOR_TYPE_PROXIMITY：100 個感應器事件

7.3.10。指紋感應器

設有安全螢幕鎖定畫面的裝置應加入指紋感應器。如果裝置實作項目包含指紋感應器，且有適用於第三方開發人員的 API，請按照下列步驟操作：

  • 必須宣告支援 android.hardware.fingerprint 功能。
  • 必須完全導入 Android SDK 說明文件中所述的對應 API。
  • 假定接受率不得高於 0.002%。
  • 強烈建議將錯誤拒絕率設為低於 10% (根據裝置估算)
  • 強烈建議將延遲時間控制在 1 秒以下，使用時間從指紋感應器輕觸到螢幕解鎖為止，且手指已註冊的手指重複。
  • 如果嘗試進行五項錯誤試驗，請至少嘗試驗證 30 秒以完成指紋驗證。
  • 「必須」採用硬體支援的 KeyStore 實作方式，並在受信任的執行環境 (TEE) 或具備安全通道的晶片上執行指紋比對。
  • 如 Android 開放原始碼計畫網站的實作指南所述，所有可識別的指紋資料都必須經過加密及加密驗證，才能用於在受信任的執行環境 (TEE) 之外取得、讀取或修改。
  • 必須讓使用者確認現有或新增受到 TEE 保護的裝置憑證 (PIN 碼/圖案/密碼)，才能在未建立信任鏈時新增指紋；Android 開放原始碼計畫實作提供了相關機制，方便使用者完成這項作業。
  • 「不得」允許第三方應用程式區分個人指紋。
  • 必須遵循 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT 標記。
  • 從 Android 6.0 以下版本升級時，請務必以安全的方式遷移指紋資料，以符合上述規定或移除。
  • 應使用 Android 開放原始碼計畫中提供的 Android 指紋圖示。

7.3.11。僅支援 Android Automotive 的感應器

汽車專用的感應器是在 android.car.CarSensorManager API 中定義。

7.3.11.1。目前齒輪

Android Automotive 實作項目「必須」提供目前設備做為 SENSOR_TYPE_GEAR。

7.3.11.2。日間模式

Android Automotive 實作項目必須支援定義為 SENSOR_TYPE_NIGHT 的日間/夜間模式。這個旗標的值「必須」與數字面板日/夜間模式一致，且應該根據環境光度感應器輸入。基礎環境光度感應器可能與 Photometer 相同。

7.3.11.3.駕駛狀態

Android Automotive 實作項目「必須」支援定義為 SENSOR_TYPE_DRIVING_STATUS 的行車狀態，且車輛完全停止並停車時，預設值為 DRIVE_STATUS_UNRESTRICTED。裝置製造商必須負責設定 SENSOR_TYPE_DRIVING_STATUS，以符合運送產品市場適用的所有法律和法規。

7.3.11.4。方向盤速度

Android Automotive 實作項目「必須」提供定義為 SENSOR_TYPE_CAR_SPEED 的車輛速度。

7.3.12。姿勢感應器

裝置實作可能支援 6 度自由度的姿勢感應器。建議 Android 手持裝置支援這個感應器。如果裝置實作支援自由 6 度自由姿勢的姿勢感應器，請按照下列步驟操作：

  • 必須導入及回報 TYPE_POSE_6DOF 感應器。
  • 必須比只使用旋轉向量的準確度高。

7.4.資料連線

7.4.1。電話通訊系統

「電話」是 Android API 所使用的「電話」，本文件專指透過 GSM 或 CDMA 網路撥打語音通話及傳送簡訊的相關硬體。雖然這類語音通話不一定是透過封包切換，但這類呼叫屬於 Android 的用途，與可能使用相同網路導入的任何數據連線無關。換句話說，Android 的「電話」功能和 API 專指語音通話和簡訊。舉例來說，如果裝置實作無法撥打電話或收發簡訊，則「不得」回報 android.hardware.telephony 功能或任何子功能，無論這些功能是否透過行動網路進行數據連線。

Android MAY 適用於不含電話硬體硬體的裝置。也就是說，Android 與非手機裝置相容。但如果實作的裝置包含 GSM 或 CDMA 電話，就「必須」導入該技術的完整 API 支援。不含電話硬體的裝置實作項目「必須」將完整的 API 實作為免人工管理。

7.4.1.1。號碼封鎖相容性

Android 電話裝置實作項目「必須」提供編號封鎖支援，以及：

  • 必須完全導入 blockNumberContract 以及 SDK 說明文件中所述的對應 API。
  • 必須封鎖「BlockingNumberProvider」中來自電話號碼的所有來電和訊息完全不必與應用程式互動唯一的例外狀況是我們依照 SDK 說明文件中的規定暫時撤銷電話號碼封鎖。
  • 「不得」針對已封鎖的通話寫入平台通話記錄供應商。
  • 對於已封鎖的訊息，「請勿」寫入電話供應商。
  • 必須實作已封鎖的電話號碼管理 UI；該 UI 是透過 TelecomManager.createManageBlockingNumbersIntent() 方法傳回的意圖開啟。
  • 「不得」允許次要使用者查看或編輯裝置上的已封鎖號碼，因為 Android 平台會假設主要使用者能夠完整控制裝置上的電話服務 (單一執行個體)。「必須」對次要使用者隱藏所有封鎖相關使用者介面，且仍須遵守封鎖清單。
  • 當裝置更新至 Android 7.0 時，請務必將已封鎖的號碼遷移至供應商。

7.4.2。IEEE 802.11 (Wi-Fi)

所有 Android 裝置實作項目都應支援一或多種 802.11 形式。如果裝置實作項目支援 802.11，並且向第三方應用程式公開這項功能，就「必須」實作對應的 Android API 並：

  • 必須回報硬體功能旗標 android.hardware.wifi。
  • 「必須」導入 SDK 說明文件中所述的多點傳播 API。
  • 「必須」支援多點傳送 DNS (mDNS)，且在作業時「不得」篩選 mDNS 封包 (224.0.0.251)，這些封包包括：
    • 即使螢幕未處於使用中狀態也一樣。
    • 適用於 Android TV 裝置實作，即使處於待機狀態也一樣。

7.4.2.1。Wi-Fi Direct

實作裝置應提供 Wi-Fi Direct (Wi-Fi 點對點) 支援。如果裝置實作項目支援 Wi-Fi Direct，則必須實作 SDK 說明文件中所述的相對應的 Android API。如果實作的裝置支援 Wi-Fi Direct，則：

  • 必須回報硬體功能 android.hardware.wifi.direct。
  • 必須支援一般的 Wi-Fi 運作。
  • 應支援並行 Wi-Fi 和 Wi-Fi Direct 作業。

裝置實作「必須」按照 Android SDK 說明文件中的說明，支援 Wi-Fi 通道直接連結設定 (TDLS)。如果裝置實作支援 TDLS，且 Wi-FiManager API 已啟用 TDLS，裝置：

  • 請只在可能且有利的情況下使用 TDLS。
  • 「不應」使用一些經驗法則，並「不要」使用 TDLS (因為網路效能可能比使用 Wi-Fi 存取點更高)。

7.4.3.藍牙

Android Watch 實作項目「必須」支援藍牙。Android TV 實作項目必須支援藍牙和藍牙 LE。Android Automotive 實作項目「必須」支援藍牙，且必須支援藍牙 LE。

支援 android.hardware.vr.high_performance 功能的實作裝置「必須」支援藍牙 4.2 和藍牙 LE Data Length Extension。

Android 支援藍牙和藍牙低功耗。如果裝置的實作支援藍牙和藍牙低功耗功能，「必須」宣告相關的平台功能 (分別 android.hardware.bluetooth 和 android.hardware.bluetooth_le)，並實作平台 API。實作裝置應視情況實作裝置適用的相關藍牙設定檔，例如 A2DP、AVCP、OBEX 等。

Android Automotive 實作項目應支援訊息存取設定檔 (MAP)。Android Automotive 實作項目「必須」支援下列藍牙設定檔：

  • 透過免持聽筒設定檔 (HFP) 撥打電話。
  • 透過音訊發布設定檔 (A2DP) 播放媒體。
  • 遠端控制設定檔 (AVRCP) 的媒體播放控制項。
  • 透過電話簿存取設定檔 (PBAP) 分享聯絡人。

實作裝置，包括支援藍牙低功耗：

  • 「必須」宣告 android.hardware.bluetooth_le 硬體功能。
  • 必須啟用 SDK 說明文件和 android.bluetooth 中所述，啟用 GATT (一般屬性設定檔) 式藍牙 API。
  • 強烈建議你導入可撤銷私人網址 (RPA) 逾時時間不得超過 15 分鐘，並在逾時時輪替地址，以保護使用者隱私。
  • 導入 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組，且每次透過 android.bluetooth.BluetoothAdapter.isOffloadFilteringSupported() 方法查詢時，都「必須」回報導入篩選邏輯的正確值。
  • 應支援將批次掃描卸載到藍牙晶片組，但如果不支援，則每次透過 android.bluetooth.BluetoothAdapter.isOffloadScanBatchingSupported() 方法進行查詢時，都必須回報「false」。
  • 必須支援至少有 4 個版位的多廣告，但如果不支援，則每次透過 android.bluetooth.BluetoothAdapter.isMultiple AdvertisingmentSupported() 方法進行查詢時，都必須回報「false」。

7.4.4。近距離無線通訊

實作裝置「必須」提供近距離無線通訊 (NFC) 專用的收發機和相關硬體。如果裝置實作包含 NFC 硬體，計劃提供給第三方應用程式使用，那麼：

  • 「必須」透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
  • 必須能夠根據下列 NFC 標準讀取及寫入 NDEF 訊息：
    • 必須能夠以下列 NFC 標準擔任 NFC 論壇讀取者/寫入者 (根據 NFC 論壇技術規格 NFCForum-TS-DigitalProtocol-1.0 所定義)：
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS X 6319-4)
      • IsoDep (ISO 14443-4)
      • NFC 論壇標記類型 1、2、3、4 (由 NFC 論壇定義)
    • 強烈建議能夠根據以下 NFC 標準讀取和寫入 NDEF 訊息以及原始資料。請注意，雖然下列 NFC 標準明確表示「建議做法」，但未來版本的相容性定義將改為「必須」。這些標準對這個版本而言是選用項目，但在日後推出的版本中也是必要條件。無論現有和新裝置搭載此 Android 版本，我們都強烈建議你立即符合這些規定，以便升級至未來的平台版本。
      • NfcV (ISO 15693)
    • 應能讀取 Thinfilm NFC 條碼產品的條碼和網址 (如果經過編碼)，
    • 必須能夠透過下列點對點標準和通訊協定傳輸及接收資料：
      • ISO 18092
      • LLCP 1.2 (由 NFC 論壇定義)
      • SDP 1.0 (由 NFC 論壇定義)
      • NDEF 推送通訊協定
      • SNEP 1.0 (由 NFC 論壇定義)
    • 必須支援 Android Beam。
    • 「必須」實作 SNEP 預設伺服器。預設 SNEP 伺服器接收的有效 NDEF 訊息，「必須」將使用 android.nfc.ACTION_NDEF_DISCOVERED 意圖分派給應用程式。在設定中停用 Android Beam 「不得」停用傳入的 NDEF 訊息。
    • 必須遵循 android.settings.NFCSHARING_SETTINGS 意圖，才能顯示 NFC 分享設定。
    • 「必須」實作 NPP 伺服器。NPP 伺服器接收訊息的方式「必須與」 SNEP 預設伺服器相同。
    • 「必須」實作 SNEP 用戶端，並嘗試在 Android Beam 啟用時將傳出 P2P NDEF 傳送至預設 SNEP 伺服器。如果找不到預設 SNEP 伺服器，用戶端「必須」嘗試傳送至 NPP 伺服器。
    • 「必須」允許前景活動使用 android.nfc.NfcAdapter.setNdefPushMessage 和 android.nfc.NfcAdapter.setNdefPushMessageCallback 和 android.nfc.NfcAdapter.enableForegroundNdefPush，設定傳出的 P2P NDEF 訊息。
    • 傳送 P2P NDEF 訊息前，應先使用手勢或螢幕上的確認訊息 (例如「輕觸傳輸」)。
    • 請預設啟用 Android Beam，且「必須」能夠使用 Android Beam 傳送及接收郵件 (即使已開啟其他專屬 NFC P2p 模式亦然)。
    • 如果裝置支援藍牙物件推送設定檔，則必須支援 NFC 連線轉移至藍牙。使用 android.nfc.NfcAdapter.setBeamPushUris 時，裝置必須採用 NFC 論壇的「連線交替版本 1.2」和「使用 NFC 版本 1.0 藍牙安全簡單配對」規格，支援將連線轉交藍牙的功能。此實作「必須」實作名為「urn:nfc:sn:handover」的服務名稱「urn:nfc:sn:handover」，用來透過 NFC 交換轉移要求/選取記錄，而且「必須」使用藍牙物件推送設定檔進行實際的藍牙資料傳輸。基於舊版原因 (以便與 Android 4.1 裝置保持相容)，實作項目仍「必須」接受 SNEP GET 要求，以交換透過 NFC 轉移要求/選取記錄。不過，實作作業本身「不應」傳送 SNEP GET 要求來執行連線轉移。
    • 在 NFC 探索模式下，請務必輪詢所有支援的技術。
    • 當裝置處於啟用狀態且螢幕鎖定時，應使用 NFC 探索模式。

(請注意，系統並未針對上述的 JIS、ISO 和 NFC 論壇規格提供公開連結)。

Android 支援 NFC 主機卡片模擬 (HCE) 模式。如果裝置實作包含支援 HCE (適用於 NfcA 和/或 NfcB) 的 NFC 控制器晶片組，且支援應用程式 ID (AID) 轉送功能，那麼：

  • 必須回報 android.hardware.nfc.hce 功能常數。
  • 必須支援 Android SDK 中定義的 NFC HCE API。

如果裝置實作包含支援 HCE for NfcF 的 NFC 控制器晶片組，且實作了第三方應用程式的功能，那麼：

  • 必須回報 android.hardware.nfc.hcef 功能常數。
  • 必須導入 Android SDK 中定義的 NfcF Card Emulation API。

此外，實作裝置「可能」提供以下 MIFARE 技術的讀取者/寫入者支援。

  • MIFARE 經典
  • MIFARE 超光
  • MIFARE Classic 中的 NDEF

請注意，Android 包含這些 MIFARE 類型的 API。如果裝置實作支援具備讀取者/寫入者角色的 MIFARE 功能，就會：

  • 「必須」實作 Android SDK 記錄的對應 Android API。
  • 請務必透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這並非標準的 Android 功能，因此在 android.content.pm.PackageManager 類別中不會以常數的形式顯示。
  • 除非同時實作一般 NFC 支援 (如本節所述)，否則「不得」實作對應的 Android API 或回報 com.nxp.mifare 功能。

如果裝置實作方式不含 NFC 硬體，就「不得」透過 android.content.pm.PackageManager.hasSystemFeature() 方法宣告 android.hardware.nfc 功能，而且「必須」以免人工管理的方式實作 Android NFC API。

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

7.4.5。最低網路功能

實作裝置「必須」支援一或多種資料網路的支援。具體來說，裝置實作項目「必須」支援至少一項支援 200Kbit/秒以上的資料標準。例如 EDGE、HSPA、EV-DO、802.11g、乙太網路、藍牙 PAN 等。

如果裝置的實作項目以實體網路標準 (例如乙太網路) 為主要數據連線，且至少支援一種通用無線網路標準，例如 802.11 (Wi-Fi)，也應支援這類裝置。

裝置可能會實作多種形式的數據連線。

裝置「必須」包含 IPv6 網路堆疊，並支援使用代管 API (例如 java.net.Socket 和 java.net.URLConnection) 和原生 API (例如 AF_INET6 通訊端) 的 IPv6 通訊。IPv6 支援所需的等級會因網路類型而異，如下所示：

  • 支援 Wi-Fi 網路的裝置「必須」支援雙重堆疊和僅限 IPv6 的 Wi-Fi 作業。
  • 支援乙太網路的裝置「必須」支援乙太網路雙重堆疊作業。
  • 支援行動數據功能的裝置「必須」支援透過行動數據網路執行 IPv6 作業 (僅限 IPv6 且可能採用雙重堆疊)。
  • 裝置同時連上多個網路 (例如Wi-Fi 和行動數據) 的所有網路，兩者必須同時符合這些要求。

必須預設為啟用 IPv6。

為了確保 IPv6 通訊穩定與 IPv4 連線，「不得」捨棄傳送至裝置的單點傳播 IPv6 封包，即使螢幕並非處於使用中狀態也一樣。備援多點傳送 IPv6 封包 (例如重複的路由器通告) 若是為了節省電力，在硬體或韌體中需要有頻率限制。在這種情況下，頻率限制「不得」會造成裝置在符合 IPv6 規範的網路中，失去使用 RA 生命週期至少 180 秒的 IPv6 連線。

IPv6 連線「必須」處於打盹模式。

7.4.6。同步設定

裝置導入作業「必須」預設為開啟主自動同步處理設定，讓 getMasterSyncAutomatically() 方法傳回「true」。

7.4.7。數據節省模式

我們強烈建議使用計量付費連線的裝置導入作業提供數據節省模式。

如果裝置實作提供數據節省模式，就會：

  • 必須支援 ConnectivityManager 類別中的所有 API，如 SDK 說明文件所述

  • 「必須」在設定中提供使用者介面，讓使用者能在許可清單中新增或移除應用程式。

相反地，如果裝置實作不支援數據節省模式，就會：

  • 必須傳回 ConnectivityManager.getRestrictBackgroundStatus() 的值 RESTRICT_BACKGROUND_STATUS_DISABLED

  • 請勿播送「ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED」內容

  • 必須包含處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖的活動，但也可以將其做為免人工管理實作。

7.5.攝影機

裝置實作項目必須包括後置鏡頭和前置鏡頭。後置鏡頭是指位於裝置側邊的攝影機，對著螢幕。也就是裝置最遠處的場景，就像傳統相機一樣前置鏡頭是指與螢幕位於裝置同一側的相機。也就是說，通常用於拍攝使用者的影像，像是用於視訊會議和類似的應用程式。

如果裝置實作包含至少一台相機，應用程式「必須」能夠同時配置 3 個 RGBA_8888 點陣圖，大小等同於裝置上最大解析度相機感應器產生的圖像大小，同時相機開啟時，相機可供基本預覽且仍可拍攝。

7.5.1。後置鏡頭

裝置實作應包括後置鏡頭。如果裝置實作項目包含至少一個後置鏡頭，會發生下列情況：

  • 必須回報功能標記 android.hardware.camera 和 android.hardware.camera.any。
  • 必須採用至少 200 萬像素的解析度。
  • 相機驅動程式應採用硬體自動對焦或軟體自動對焦功能 (對應用程式軟體公開)。
  • 可能具備固定對焦或 EDOF (延伸領域深度) 硬體。
  • 可能包含閃光燈。如果「相機」包含閃光燈，「不得」在相機預覽介面上註冊 android.hardware.Camera.PreviewCallback 執行個體時開啟閃光燈，除非應用程式已啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，藉此明確啟用閃光燈。請注意，這項限制不適用於裝置的內建系統相機應用程式，但僅適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2。前置鏡頭

實作裝置可能包含前置鏡頭。如果裝置實作作業包含至少一個前置鏡頭，裝置必須符合以下條件：

  • 必須回報功能標記 android.hardware.camera.any 和 android.hardware.camera.front。
  • 解析度至少須為 VGA (640x480 像素)。
  • 「不得」使用前置鏡頭做為 Camera API 的預設相機。Android 的 Camera API 對前置鏡頭和裝置實作提供專屬支援，「不得」將 API 設為將前置鏡頭視為預設後置鏡頭，即使該裝置是裝置上唯一的鏡頭。
  • 可包含後置鏡頭可用的功能 (例如自動對焦、閃光燈等)，如第 7.5.1 節所述。
  • 必須水平反射 (即鏡像) 應用程式在 CameraPreview 中顯示的串流，如下所示：
    • 如果裝置實作項目能夠讓使用者旋轉 (例如透過加速計自動旋轉，或透過使用者輸入操作手動旋轉)，則相機預覽畫面「必須」根據裝置目前的螢幕方向水平鏡像。
    • 如果目前應用程式已明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法旋轉相機螢幕，相機預覽畫面「必須」以相對於應用程式指定的方向水平鏡像。
    • 否則，預覽畫面「必須」沿著裝置的預設水平軸雙向鏡像。
  • 「必須」按照相機預覽圖片串流的方式，鏡像投射後檢視顯示的圖像。如果裝置實作不支援事後瀏覽，則明顯不適用這項規定。
  • 「不得」複製傳回至應用程式回呼或承諾用於媒體儲存空間的最終擷取靜態圖片或影片串流。

7.5.3.外接鏡頭

實作裝置可能會支援不見得隨時連接的外部相機。如果裝置支援外接攝影機，請注意下列事項：

  • 必須宣告平台功能旗標 android.hardware.camera.external 和 android.hardware camera.any。
  • 支援多部相機。
  • 如果外接攝影機透過 USB 連接埠連接，則必須支援 USB 視訊類別 (UVC 1.0 以上版本)。
  • 應支援 MJPEG 等影片壓縮，以便傳輸高畫質的未編碼串流 (即原始或獨立壓縮的影像串流)。
  • 支援相機式影片編碼。如果支援，裝置實作就「必須」能存取同時未編碼 / MJPEG 串流 (QVGA 或更高解析度)。

7.5.4。Camera API 行為

Android 提供兩種 API 套件來存取相機，新版 android.hardware.camera2 API 提供應用程式較低層級的相機控制功能，包括高效率的零複製爆發/串流流程，以及曝光、增益、白平衡增加、色彩轉換、雜訊、銳化等每個畫面的控制選項。

在 Android 5.0 中，舊版 API 套件 android.hardware.Camera 標示為已淘汰，但採用 Android 裝置實作方式的應用程式應該仍可使用該套件，但「必須」確保能繼續按照本節和 Android SDK 中的 API 支援該 API。

裝置實作「必須」針對所有可用的相機，為相機相關 API 實作下列行為：

  • 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則裝置「必須」使用 android.hardware.PixelFormat.YCbCr_420_SP 來提供提供給應用程式回呼的預覽資料。
  • 如果應用程式註冊 android.hardware.Camera.PreviewCallback 執行個體，且系統在預覽格式為 YCbCr_420_SP 時呼叫 onPreviewFrame() 方法，則傳入 onPreviewFrame() 的位元組 [] 資料必須進一步採用 NV21 編碼格式。也就是說，必須預設為 NV21。
  • 如果是 android.hardware.Camera，裝置的實作「必須」支援前置鏡頭和後置鏡頭的 YV12 格式 (如 android.graphics.ImageFormat.YV12 常數表示)。(硬體視訊編碼器和攝影機可能會使用任何原生像素格式，但裝置的實作「必須」支援轉換為 YV12 格式)。
  • 如果是 android.hardware.camera2，裝置的實作必須支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式做為透過 android.media.ImageReader API 輸出。

無論裝置是否具備硬體自動對焦或其他功能，裝置實作項目都「必須」實作 Android SDK 說明文件中提供的完整 Camera API。舉例來說，沒有自動對焦的相機仍然必須呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 執行個體 (即使這與非自動對焦相機無關)。請注意，這適用於前置鏡頭。舉例來說，雖然大多數的前置鏡頭不支援自動對焦，但 API 回呼仍必須「加上假裝」，如上所述。

如果基礎硬體支援此功能，裝置實作項目「必須」識別並遵守 android.hardware.Camera.Parameters 類別中定義為常數的每個參數名稱。如果裝置硬體不支援某項功能，API 的行為必須如文件中所述。相反地，除了在 android.hardware.Camera.Parameters 上以常數記載為常數之外，裝置實作「不得」遵守或識別傳送至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作項目「必須」支援所有標準相機參數，且「不得」支援自訂的相機參數類型。舉例來說，如果裝置的實作方式支援使用高動態範圍 (HDR) 影像技術擷取相片，就「必須」支援 Camera.SCENE_MODE_HDR 技術。

由於並非所有裝置實作項目都能完整支援 android.hardware.camera2 API 的所有功能，因此裝置實作「必須」按照 Android SDK 中的 android.info.supportedHardwareLevel 屬性回報適當的支援層級，並回報適當的架構功能旗標。

裝置實作項目也必須透過 android.request.availableCapabilities 屬性宣告其 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標。如果裝置連接的相機裝置支援這項功能，就必須定義功能旗標。

每當相機拍攝新相片並將相片項目新增至媒體儲存區時，裝置實作都「必須」播送 Camera.ACTION_NEW_PICTURE 意圖。

裝置實作項目必須「必須」播送 Camera.ACTION_NEW_VIDEO 意圖，包括相機錄製新影片，並將圖片項目新增至媒體儲存區。

7.5.5。相機方向

無論使用前置和後置鏡頭，都必須朝向相同方向，讓相機的長邊對齊螢幕的長邊。也就是說，當裝置保持橫向時，相機「必須」拍攝橫向的照片。這不受裝置的自然方向影響；適用於橫向和直向主要裝置

7.6.記憶體與儲存空間

7.6.1。記憶體與儲存空間下限

Android TV 裝置至少「必須」有 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料。

裝置實作時，核心和使用者空間可用的記憶體應至少等於或大於下表指定的最小值。(如要瞭解螢幕大小和密度的定義，請參閱第 7.1.1 節)。

密度和螢幕大小 32 位元裝置 64 位元裝置
Android Watch 裝置 (原因：螢幕較小) 416MB 不適用
  • 在小螢幕/一般螢幕上，280 dpi 以下
  • 大螢幕上的 mdpi 或更低
  • 搭載超大型螢幕的 ldpi 或更低版本
512MB 816MB
  • 小螢幕/一般螢幕適用的 xhdpi 或更高
  • 在大螢幕上使用 hdpi 或更高版本
  • 在特大型螢幕上使用 mdpi 或更高版本
608MB 944MB
  • 在小螢幕/一般螢幕上，400 dpi 以上
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本
896MB 1280MB
  • 在小螢幕/一般螢幕上，採用 560 dpi 以上
  • 在大螢幕裝置上播放 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕
1344MB 1824MB

除了核心無法控管的硬體元件 (例如無線電、視訊等) 已專用的記憶體空間外，也必須指定最低記憶體值。

核心和使用者空間可用的記憶體小於 512 MB 的裝置實作項目，除非使用 Android Watch，否則必須傳回「true」值。

Android TV 裝置「必須」至少有 4 GB 的儲存空間和其他實作裝置，且至少要有 3 GB 的非揮發性儲存空間，才能存放應用程式私人資料。也就是說，/data 分區必須至少為 4 GB (Android 電視裝置) 或 3 GB (適用於其他裝置)。對於搭載 Android 的裝置，我們強烈建議您擁有至少 4 GB 的非揮發性儲存空間，以存放應用程式私人資料，以便升級至日後發布的平台版本。

Android API 包含下載管理員，應用程式可能會用來下載資料檔案。「下載管理員」的裝置實作「必須」能將大小至少 100 MB 的個別檔案下載至預設「快取」位置。

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

裝置實作「必須」為應用程式提供共用儲存空間 (通常稱為「共用外部儲存空間」)。

裝置實作「必須」預設使用「立即可用」掛接的共用儲存裝置。如果共用儲存裝置未掛接在 Linuxpath /sdcard，則裝置「必須」包含從 /sdcard 到實際掛接點的 Linux 符號連結。

裝置的實作方式「可能」有硬體供使用者存取的移除式儲存裝置，例如 Secure Digital (SD) 記憶卡插槽。如果這個運算單元滿足共用儲存空間需求，系統會實作裝置：

  • 「必須」在沒有 SD 卡時，導入浮動式訊息或彈出式使用者介面警告使用者。
  • 必須包含 FAT 格式且大小為 1GB 的 SD 卡，或者，您購買 SD 卡時必須另外購買，才能展示在包裝盒和其他物品上，且必須另外購買。
  • 「必須」預設插入 SD 卡。

此外，裝置實作項目「可」分配內部 (不可移除) 儲存空間，做為上游 Android 開放原始碼計畫所含應用程式的共用儲存空間。裝置實作「必須」使用此設定及軟體實作。如果裝置的實作使用內部 (不可移除) 儲存空間來滿足共用儲存空間需求，但該儲存空間「可」與應用程式私人資料共用空間，則儲存空間大小至少須為 1 GB，並掛接在 /sdcard 上 (如果掛接在其他地方，則「/sdcard」必須是實際位置的符號連結)。

裝置實作「必須」依照記載這個共用儲存空間的 android.permission.WRITE_EXTERNAL_STORAGE 權限來強制執行。「共用」儲存空間「必須」由任何取得該權限的應用程式寫入。

如果裝置的實作方式包含多個共用儲存路徑 (例如 SD 卡插槽和共用內部儲存空間)，「必須」已預先安裝具有 WRITE_EXTERNAL_STORAGE 權限，且可寫入次要外部儲存空間的特殊權限 Android 應用程式，除非寫入其套件專屬目錄，或藉由啟動 ACTION_OPEN_DOCUMENT_TREE 意圖而傳回的 URI。

不過，裝置的實作應透過 Android 的媒體掃描器服務和 android.provider.MediaStore 公開這兩種儲存空間路徑的內容。

無論共用儲存裝置的形式為何，如果裝置的 USB 連接埠支援 USB 週邊裝置模式，就「必須」提供一些機制，讓使用者從主機電腦存取共用儲存空間的內容。實作裝置可能會使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定以滿足這項需求。如果裝置導入方式支援媒體傳輸通訊協定，就會：

  • 必須與參考 Android MTP 主機的 Android 檔案傳輸應用程式相容。
  • 必須回報 0x00 的 USB 裝置類別。
  • 請回報「MTP」的 USB 介面名稱。

7.6.3.採用儲存空間

如果卸除式儲存裝置連接埠位於長期穩定的位置 (例如電池座或其他保護蓋)，我們強烈建議在裝置上實作可採用的儲存空間。

對於電視等裝置實作，「可能」允許透過 USB 連接埠開始使用，因為裝置需為靜態而非行動裝置。但如果是其他屬於行動裝置的裝置實作項目，強烈建議在長期穩定的位置導入可用的儲存空間，因為意外中斷連線可能會導致資料遺失/損毀。

7.7.USB

實作裝置應支援 USB 週邊模式，且應支援 USB 主機模式。

7.7.1。USB 週邊裝置模式

如果裝置實作包含支援週邊裝置的 USB 連接埠：

  • 這個連接埠「必須」可連接具有標準 Type-A 或 Type-C USB 連接埠的 USB 主機。
  • 連接埠「必須」使用 micro-B、micro-AB 或 Type-C USB 板型規格。現有和新 Android 裝置強烈建議符合這些規定，以便升級至日後發布的平台版本。
  • 連接埠「必須」位於裝置底部 (根據自然方向)，或為所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，這樣當裝置朝底部連接埠方向時，螢幕才能正確繪製。現有和新 Android 裝置強烈建議符合這些規定，以便升級至日後發布的平台版本。
  • 「必須」允許連接 Android 裝置的 USB 主機，透過 USB 大量儲存裝置或媒體傳輸通訊協定存取共用儲存空間磁碟區的內容。
  • 它必須實作 Android Open Accessory (AOA) API 和規格，如 Android SDK 說明文件所述；如果是 Android 手持裝置，則「必須」實作 AOA API。實作 AOA 規格的裝置實作方式：
    • 必須宣告支援硬體功能 android.hardware.usb.accessory。
    • 「必須」實作 Android SDK 說明文件所述的 USB 音訊類別。
    • USB 大量儲存空間級別「必須」包含「android」字串位於介面說明的iInterface USB 大量儲存裝置中
  • 裝置「應該」導入相關支援，在 HS 晶片期間繪製 1.5 電流，並按照 USB 電池充電規格第 1.2 版的規定繪製電流。現有和新 Android 裝置強烈建議符合這些規定，以便升級至日後發布的平台版本。
  • Type-C 裝置必須根據 Type-C 電阻器標準偵測 1.5A 和 3.0A 充電器，而且必須偵測廣告中的變化。
  • 極力建議您支援支援 USB 主機模式的 Type-C 裝置，以便支援資料傳輸和電源角色交換。
  • C 型裝置應支援 Power Delivery 針對高壓充電，並支援替代模式 (例如螢幕外)。
  • USB 標準裝置描述元中的 iSerialNumber 值必須等於 android.os.Build.SERIAL 值。
  • 強烈建議 C 型裝置不支援專屬充電方法，例如修改 Vbus 電壓超過預設等級，或更改接收器/來源角色，可能會導致支援標準 USB Power Delivery 方法的充電器或裝置發生互通性問題。雖然這種做法稱為「強烈建議」，但在日後的 Android 版本中，我們可能會要求所有 Type-C 裝置支援與標準 C 型充電器完全互通。

7.7.2。USB 主機模式

如果裝置的實作包含支援主機模式的 USB 連接埠，就會：

  • 如果裝置的實作支援 USB 3.1，則應使用 C 型 USB 連接埠。
  • 「可能」使用非標準的連接埠板型規格，但「必須」配合使用傳輸線或傳輸線寄送，以便將連接埠轉變成標準 A 型或 C 型 USB 連接埠。
  • 建議您使用 micro-AB USB 連接埠，但如果需要，請務必使用傳輸線或傳輸線，將連接埠改為標準 A 型或 C 型 USB 連接埠。
  • 強烈建議導入 USB 音訊類別 (如 Android SDK 說明文件所述)。
  • 「必須」實作 Android SDK 中記錄的 Android USB 主機 API，且「必須」宣告 android.hardware.usb.host 硬體功能支援。
  • 應在主機模式下支援裝置充電功能；向 [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) (http://www.usb.org/developers/docs/usb_31_021517.zip) (http://www.usb.org/developers/docs/usb_31_021517.zip) (http://www.usb.org/developers/docs/usb_31_021517.zip) (http://www.usb.org/developers/docs/usb_31_021517.zip) (http://www.usb.org/developers/docs/usb_31_021517.zip)) 的「終止參數」一節規定，添加至少 1.5A 的源頭 (適用於 USB Type-C 連接器；USB 連接器電池輸出電流，則需使用 USB-AB 連接器)。
  • 強烈建議使用 USB Type-C 裝置來支援 DisplayPort、應支援 USB 超級速度資料速率。強烈建議你使用 Power Delivery 支援資料和電源角色交換。
  • 搭載任何 A 型或 A/B 型連接埠的裝置「不得」隨附轉接器，將轉接器從這個連接埠轉換為 C 型接頭。
  • 如果儲存空間存取架構 (SAF) 受到支援，「必須」識別任何遠端連線 MTP (媒體傳輸通訊協定) 裝置，並透過 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT 意圖存取裝置內容。
  • 如果使用 Type-C USB 連接埠並支援週邊裝置模式，必須實作雙角色通訊埠功能，如 USB Type-C 規格定義 (第 4.5.1.3.3 節)。
  • 如果支援雙角色通訊埠功能，請實作最適合裝置板型規格的 try.* 模型。例如手持裝置應實作 try.SNK 模型。

7.8.音訊

7.8.1。麥克風

Android 手持裝置、手錶和 Automotive 實作項目「必須」具備麥克風。

實作裝置可能會省略麥克風。但如果裝置實作方式缺少麥克風，就「不得」回報 android.hardware.microphone 功能常數，且至少必須根據第 7 節實作音訊錄音 API 為免人工管理。相反地，具有麥克風的裝置實作方式：

  • 必須回報 android.hardware.microphone 功能常數。
  • 必須符合第 5.4 節的音訊錄音規定。
  • 必須符合第 5.6 節的音訊延遲規定。
  • 強烈推薦支援接近超音波錄音的功能 (如第 7.8.3 節所述)。

7.8.2。音訊輸出裝置

Android Watch 裝置可能包含音訊輸出裝置。

實作裝置，包括喇叭，或是音訊輸出週邊裝置 (以耳機或外接喇叭) 的音訊/多媒體輸出連接埠：

  • 必須回報 android.hardware.audio.output 功能常數。
  • 必須符合第 5.5 節的音訊播放規定。
  • 必須符合第 5.6 節的音訊延遲規定。
  • 強烈建議你支援接近超音波播放功能，如第 7.8.3 節所述。

相反地，如果裝置實作項目不包含喇叭或音訊輸出連接埠，則「不得」回報 android.hardware.audio 輸出功能，且至少「必須」實作音訊輸出相關 API 作為免人工管理。

Android Watch 裝置實作項目「可能」「不」有音訊輸出裝置，但其他類型的 Android 裝置實作「必須」具備音訊輸出功能，並宣告 android.hardware.audio.output。

7.8.2.1。類比音訊連接埠

為與使用 3.5 公釐音訊插頭搭配 Android 生態系統的耳機和其他音訊配件相容，如果裝置實作包含一或多個類比音訊連接埠，至少其中一個音訊連接埠應使用 4 釐米接頭 3.5 公釐耳機插孔。如果裝置實作方式為 4 指導管 3.5 公釐耳機插孔，則：

  • 必須能夠透過配備麥克風的立體聲耳機和立體聲耳機播放音訊，並支援透過立體聲耳機錄製音訊。
  • 必須使用 CTIA 的轉接順序支援 TRRS 音訊插頭，並應支援搭配 OMTP 快出順序使用的音訊插頭。
  • 如果裝置實作的裝置支援麥克風，且將額外的麥克風值設為 1，則「必須」支援偵測插在音訊配件上的麥克風。
  • 針對麥克風與接地導體之間的 3 個範圍同等阻礙，必須支援偵測和對應的按鍵碼。
    • 70 小時以下：KEYCODE_HEADSETHOOK
    • 210-290 Ohm：KEYCODE_VOLUME_UP
    • 360-680 糟糕：KEYCODE_VOLUME_DOWN
  • 強烈建議「極力」偵測出以下按鍵碼，並對應對應的按鍵碼，用於麥克風與音訊插頭上的麥克風與接地導體之間。
    • 110 - 180 糟糕：KEYCODE_VOICE_ASSIST
  • 插入插頭時必須觸發 ACTION_HEADSET_PLUG，但只有在所有聯絡人在插孔上觸碰到底座上的相關區塊時，才會觸發 ACTION_HEADSET_PLUG。
  • 必須能夠利用 32 點歐姆喇叭阻抗，駕駛至少 150mV ±10% 的輸出電壓。
  • 麥克風偏壓電壓應介於 1.8V 到 2.9V 之間。

7.8.3.近乎超音波

近乎超音波音訊為 18.5 kHz 至 20 kHz 錶帶。裝置實作「必須」透過 AudioManager.getProperty API 正確回報支援近乎超音波的音訊功能，如下所示：

  • 如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASound 的值為「true」，則 VOICE_RECOGNITION 和 UNPROCESSED 音訊來源必須符合下列規定：
    • 在 18.5 kHz 至 20 kHz 頻帶中，麥克風的平均功率回應「必須」低於 15 dB (2 kHz)。
    • 以 19 kHz 為 19 kHz 至 20 kHz 時的未加權訊號，而且訊號強度必須小於 50 dB。
  • 如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASound 為「true」，則揚聲器的平均值回應 (18.5 kHz - 20 kHz) 不得超過 40 dB (以 2 kHz 為單位)

7.9.虛擬實境

Android 提供用於建構「虛擬實境」的 API 和設施(VR) 應用程式，包括優質的行動 VR 體驗。裝置實作「必須」正確實作這些 API 和行為，如本節所述。

7.9.1。虛擬實境模式

Android 手持裝置實作項目支援 VR 應用程式的模式，這類應用程式可處理通知的立體視覺轉譯作業，並停用單聲道系統 UI 元件，而 VR 應用程式則具備使用者焦點，「必須」宣告 android.software.vr.mode 功能。宣告這項功能的裝置「必須」包含實作 android.service.vr.VrListenerService 的應用程式，可透過 android.app.Activity#setVrModeEnabled 啟用 VR 應用程式。

7.9.2。虛擬實境高效能

Android 手持裝置實作「必須」透過 android.hardware.vr.high_performance 功能旗標，找出長期支援高效能虛擬實境的支援機制。

  • 裝置實作項目必須至少有 2 個實體核心。
  • 裝置實作項目「必須」宣告 android.software.vr.mode 功能。
  • 裝置實作項目「可」為前景應用程式提供專屬核心，並支援 Process.getExclusiveCores API 即可傳回頂層前景應用程式專屬的 CPU 核心數量。如果支援專屬核心，那麼核心「必須」不允許其他任何使用者空間處理程序在其上執行 (應用程式所使用的裝置驅動程式除外)，但「可能」允許部分核心程序視需要執行。
  • 裝置實作項目「必須」支援持續效能模式。
  • 裝置實作項目「必須」支援 OpenGL ES 3.2。
  • 裝置實作項目必須支援 Vulkan 硬體級別 0，且必須支援 Vulkan 硬體級別 1。
  • 裝置實作「必須」實作 EGL_KHR_mutable_render_buffer 和 EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_create_native_client_buffer、EGL_KHR_fence_sync 和 EGL_KHR_wait_sync，以便在可用的 EGL 擴充功能清單中顯示該擴充功能。
  • GPU 和螢幕「必須」能夠同步處理共用前端緩衝區的存取權，以顯示以 60fps 交替顯示 VR 內容，而且有兩個算繪環境，但沒有可見的撕裂痕跡。
  • 裝置實作「必須」實作 EGL_IMG_context_priority，並在可用的 EGL 擴充功能清單中顯示擴充功能。
  • 裝置實作「必須」實作 GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2 和 GL_OVR_multiview_multiview_multisampled_render_to_texture，並在可用的 GL 擴充功能清單中顯示擴充功能。
  • 裝置實作「必須」實作 EGL_EXT_protect_content 和 GL_EXT_protect_textures，才能用於安全紋理影片播放，並在可用的 EGL 和 GL 擴充功能清單中顯示擴充功能。
  • 裝置實作必須支援解碼至少 3840x2160@30fps-40Mbps 的 H.264 (相當於 4 個 1920x1080@30fps-10Mbps 或 2 個 1920x1080@60fps-20Mbps 的執行個體)，
  • 裝置的實作「必須」支援 HEVC 和 VP9，且至少要能夠解碼 1920x1080@30fps-10Mbps 的編碼，且 應該能夠解碼 3840x2160@30fps-20Mbps (相當於 4 個 fps - 1080@30 Mbps 的執行個體)。
  • 強烈「建議」的裝置實作方式可支援 android.hardware.sensor.hifi_sensors 功能，且「必須」符合 android.hardware.hifi_sensors 的陀螺儀、加速計和磁力儀相關要求。
  • 裝置實作「必須」支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回準確的皮膚溫度值。
  • 裝置實作「必須」具有內嵌螢幕，且解析度至少須為 FullHD(1080p) 且強烈建議設為 QuadHD (1440p) 以上。
  • 螢幕必須介於 4.7 吋之間和 6 吋例如對角線或斜體字
  • 處於 VR 模式時，螢幕至少要更新 60 Hz。
  • 從灰色到灰色、白到黑和黑白的切換時間，螢幕延遲時間必須不超過 3 毫秒。
  • 螢幕「必須」支援低持久模式，且持續性不超過 5 毫秒，持續定義則是指像素發出光的時間長度。
  • 實作裝置必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能 (第 7.4.3 節)。

8. 效能與功率

有些最低效能和電源標準是影響使用者體驗的關鍵，也會影響開發人員開發應用程式時的基準假設。Android Watch 裝置「必須」符合下列條件，並導入其他類型的裝置。

8.1.使用者體驗一致性

裝置實作「必須」確保應用程式和遊戲的影格速率和回應時間一致，提供流暢的使用者介面。裝置實作方式「必須」符合下列規定：

  • 一致的影格延遲時間 .影格延遲不一致或轉譯影格延遲「不得」在一秒內發生超過 5 個影格，且每秒不得超過 1 個影格。
  • 使用者介面延遲 .裝置實作「必須」在 36 秒內捲動 Android Compatibility Test Suite (CTS) 定義的 1 萬個清單項目清單，確保提供低延遲的使用者體驗。
  • 工作切換：啟動多個應用程式後，如要重新啟動已在執行中的應用程式，則必須在 1 秒內重新啟動。

8.2.檔案 I/O 存取效能

裝置實作「必須」確保內部儲存空間檔案存取效能維持一致性，以執行讀取和寫入作業。

  • 依序寫入 .裝置實作「必須」確保使用 10 MB 寫入緩衝區的 256 MB 檔案，連續寫入效能至少達到 5 MB。
  • 隨機寫入 .裝置實作「必須」確保使用 4 KB 寫入緩衝區的 256 MB 檔案隨機寫入效能至少為 0.5 MB/秒。
  • 依序讀取 .裝置實作「必須」確保使用 10 MB 寫入緩衝區的 256 MB 檔案，連續讀取效能至少達到每秒 15 MB。
  • 隨機讀取 .裝置實作「必須」確保使用 4 KB 寫入緩衝區的 256 MB 檔案隨機讀取效能至少達到每秒 3.5 MB。

8.3.省電模式

Android 6.0 推出了應用程式待命和打盹模式，以最佳化電池用量。凡是不受這些模式限制的應用程式，都「必須」向使用者顯示。此外，這些省電模式的觸發、維護、喚醒演算法和這些省電模式的通用系統設定使用方式，則「不得」與 Android 開放原始碼計畫不同。

除了省電模式外，Android 裝置可能要實作這項設定和電源介面 (ACPI) 所定義的 4 個睡眠電源狀態 (全部或全部)。不過，如果裝置搭載 S3 和 S4 電源狀態，則只有在蓋上確實是裝置一部分的蓋子時，裝置才會進入這些狀態。

8.4.耗電量會計

更準確的耗電量計算和耗電量報告，能為應用程式開發人員提供獎勵和最佳化應用程式耗電量模式的工具。因此，裝置的導入方式如下：

  • 而且要能追蹤硬體元件的電力使用情形，並註明歸功於特定應用程式。具體來說，實作方法：
    • 「必須」提供個別元件的電源設定檔，定義每個硬體元件的目前耗電量值，以及該元件隨時間所產生的約略電池耗電情形 (相關資訊請見 Android 開放原始碼計畫網站)。
    • 請務必以毫安小時 (mAh) 回報所有耗電量值。
    • 如果無法將硬體元件的電力用量歸功於應用程式，則必須註明硬體元件本身。
    • 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
  • 「必須」透過 adb shell dumpsys batterystats 殼層指令，開放應用程式開發人員使用這類耗電量。
  • 必須遵循 android.intent.action.POWER_USAGE_SUMMARY 意圖，並顯示顯示此耗電量的設定選單。

8.5.一致的效能

高效能長時間執行的應用程式可能會因為溫度限製而在背景中執行其他應用程式，或 CPU 節流，造成應用程式效能大幅波動。Android 內含程式輔助介面，因此在裝置支援時，頂層前景應用程式就可以要求系統最佳化資源分配方式，以因應這類波動。

裝置實作應支援持續效能模式，這種模式可讓頂尖前景應用程式透過 Window.setSustainedPerformanceMode() API 方法提出要求，長時間維持一致的效能。裝置實作項目「必須」透過 PowerManager.isSustainedPerformanceModeSupported() API 方法正確回報持續效能模式的支援。

搭載兩個以上 CPU 核心的裝置實作應提供至少一個可由頂層前景應用程式保留的專屬核心。如有提供，導入方式必須符合以下規定：

  • 實作項目「必須」透過 Process.getExclusiveCores() API 方法回報，也就是頂端前景應用程式可保留的專屬核心 ID 數量。
  • 除了應用程式所用裝置驅動程式在專屬核心上執行外，裝置實作項目「不得」允許任何使用者空間處理程序，但「可以」允許某些核心程序視需要執行。

如果裝置實作項目不支援專屬核心，就「必須」透過 Process.getExclusiveCores() API 方法傳回空白清單。

9. 安全性模型相容性

裝置實作項目「必須」實作 Android 平台安全性模型符合 Android 平台安全性模型的安全性模型。詳情請參閱 Android 開發人員說明文件中的 API 安全性和權限參考文件。裝置導入作業「必須」支援安裝自行簽署的應用程式，且不需要任何第三方/授權單位提供額外權限/憑證。具體來說，相容裝置「必須」支援下列子節所述的安全性機制。

9.1.權限

裝置實作項目必須支援 Android 開發人員說明文件中定義的 Android 權限模型。具體來說，導入方式「必須」強制執行 SDK 說明文件中定義的各項權限。亦不得省略、修改或略過任何權限。如果新的權限 ID 字串不在 android.* 命名空間中，實作項目「可以」新增其他權限。

「PROTECTION_FLAG_PRIVILEGED」的 protectionLevel 權限「必須」只授予預先載入系統映像檔許可清單中特殊權限路徑的應用程式，例如 Android 開放原始碼計畫實作項目中的 system/priv-app 路徑。

防護等級為危險的權限即為執行階段權限。含有 targetSdkVersion > 的應用程式22 在執行階段提出請求裝置實作方式：

  • 「必須」顯示專屬介面，讓使用者決定是否要授予要求的執行階段權限，以及提供管理執行階段權限的介面。
  • 兩種使用者介面皆只能實作一個。
  • 除非符合以下條件，否則「不得」將任何執行階段權限授予預先安裝的應用程式：
    • 應用程式使用前，就能取得使用者的同意聲明
    • 執行階段權限會與意圖模式相關聯，而該模式已將預先安裝的應用程式設為預設處理常式

9.2.UID 與程序隔離

裝置實作項目「必須」支援 Android 應用程式沙箱模型，在這個模式下，每個應用程式都會以專屬 Unixstyle UID 形式執行，並透過獨立的程序執行。裝置實作項目「必須」支援使用相同 Linux 使用者 ID 執行多個應用程式，前提是應用程式已妥善簽署及建構，詳情請參閱安全性和權限參考資料。

9.3.檔案系統權限

裝置實作項目必須支援 Android 檔案存取權限模型 (詳情請參閱安全性和權限參考資料)。

9.4.替代執行環境

裝置的實作方式「可能」包含使用非 Dalvik 可執行格式或原生程式碼的其他軟體或技術執行應用程式的執行階段環境。不過，如本節所述，這類替代執行環境「不得」破壞 Android 的安全性模型或已安裝 Android 應用程式的安全性。

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

執行階段的 AndroidManifest.xml 檔案中未要求的權限，無法透過 <uses-permission> 授予替代執行階段的存取權以注意力機制為基礎

替代執行階段「不得」允許應用程式使用受 Android 權限保護的功能，而僅適用於系統應用程式。

替代執行階段必須遵循 Android 沙箱模型。具體來說，替代執行階段：

  • 應該透過 PackageManager，將應用程式安裝應用程式至獨立的 Android 沙箱 (Linux 使用者 ID 等)。
  • 可以為使用替代執行階段的所有應用程式提供一個 Android 沙箱。
  • 透過替代執行階段安裝的應用程式「不得」重複使用裝置上安裝的任何其他應用程式的沙箱，除非透過共用使用者 ID 和簽署憑證的標準 Android 機制。
  • 「不得」在啟動、授予或取得其他 Android 應用程式對應沙箱的存取權。
  • 不得以超級使用者 (根使用者) 或任何其他使用者 ID 的任何權限啟動、授予或授予其他應用程式。

替代執行階段的 .apk 檔案「可」包含在裝置實作的系統映像檔中，但必須使用與用於簽署裝置實作中其他應用程式之金鑰不同的金鑰進行簽署。

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

9.5.多使用者支援

這項功能適用於所有裝置類型。

Android 提供多位使用者支援功能，並支援完整的使用者隔離功能。裝置實作項目可允許多位使用者啟用，但啟用時「必須」符合下列與多使用者支援相關的規定：

  • 如果 Android Automotive 裝置實作已啟用多使用者支援功能，則「必須」包含訪客帳戶，以便允許車輛系統提供的所有功能，而不必要求使用者登入。
  • 如果裝置實作項目未宣告 android.hardware.telephony 功能標記，則「必須」支援設有限制的設定檔。這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。
  • 如果裝置的實作方式為宣告 android.hardware.telephony 功能標記，則「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，啟用 /禁止其他使用者存取語音通話和簡訊。
  • 但「必須」針對每位使用者導入與 Android 平台安全性模型一致的安全性模型 (定義請見 API 中的安全性和權限參考文件)。
  • Android 裝置上的每個使用者執行個體「必須」擁有獨立且獨立的外部儲存空間目錄。裝置實作項目可能會儲存多位使用者相同磁碟區或檔案系統中的資料不過，裝置實作「必須」確保特定使用者擁有且代表使用者執行的應用程式無法列出、讀取或寫入其他使用者擁有的資料。請注意，卸除式媒體 (例如 SD 卡插槽) 可讓某位使用者透過主機電腦存取另一位使用者的資料。因此，如果啟用多使用者機制時，僅使用儲存在系統的非卸除媒體上的金鑰啟用多使用者功能，則裝置的實作「必須」對 SD 卡的內容加密。由於這會使主機電腦無法讀取媒體，就必須改用 MTP 或類似的系統，讓主機電腦可以存取目前使用者資料。因此，裝置的實作可能「可」如此，但如果多位使用者使用卸除式媒體作為主要外部儲存空間，則「不應」啟用多使用者功能。

9.6.付費簡訊警告

Android 支援針對任何傳出的付費簡訊警告使用者。付費簡訊是傳送給向電信業者註冊的服務的簡訊，可能要向使用者收取相關費用。如果裝置實作項目宣告支援 android.hardware.telephony，則「必須」在使用者傳送簡訊給裝置 /data/misc/sms/codes.xml 檔案中定義的規則運算式來識別號碼。上游 Android 開放原始碼計畫提供符合這項規定的實作項目。

9.7.核心安全性功能

Android Sandbox 中的功能使用安全增強式 Linux (SELinux) 的必要存取控制 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全性功能。在 Android 架構下實作的 SELinux 或任何其他安全性功能：

  • 「必須」維持與現有應用程式的相容性。
  • 當系統偵測到安全性違規行為並成功封鎖時，「不得」顯示使用者介面，但「可能」在出現未成功的安全性違規事件發生時，顯示使用者介面遭人利用。
  • 「不得」為使用者或開發人員設定。

如果應用程式已提供政策設定的 API (例如 Device Administration API)，API 就「不得」允許會破壞相容性的設定。

裝置「必須」實作 SELinux；如果使用 Linux 以外的核心，裝置「必須」採用同等的必要存取權控管系統。裝置還必須符合下列規定，才能符合上游 Android 開放原始碼計畫的參考實作方式。

裝置實作方式：

  • 「必須」將 SELinux 設為「全域強制執行模式」。
  • 「必須」在強制執行模式下設定所有網域。不允許任何許可模式網域，包括裝置/廠商的專屬網域。
  • 針對 Android 開放原始碼計畫 SELinux 網域以及裝置/供應商特定網域，「請勿」修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 資料夾中存在的永不允許規則，或以任何不允許的規則進行編譯。
  • 「必須」將媒體架構分成多個程序，才能針對各個程序進一步授予存取權，詳情請參閱 Android 開放原始碼計畫網站上的說明。

裝置實作項目「必須」保留上游 Android 開放原始碼計畫「system/sepolicy」資料夾中提供的預設 SELinux 政策，並只針對自己的裝置專屬設定再加入這項政策。裝置的實作方式「必須」與上游 Android 開放原始碼計畫相容。

裝置「必須」實作核心應用程式沙箱機制，才能使用多執行緒程式中可供設定的政策篩選系統呼叫。上游 Android 開放原始碼專案符合這項規定，方法是按照 source.android.com 的「核心設定」一節所述，啟用 seccomp-BPF 搭配執行緒群組同步處理 (TSYNC)。

9.8.隱私性佳

如果裝置實作了擷取畫面上顯示內容的系統功能，並/或錄製裝置上播放的音訊串流，則「必須」在啟用此功能並主動擷取/錄製時，持續通知使用者。

如果裝置的導入機制預設會透過 Proxy 伺服器或 VPN 閘道轉送網路流量流量 (例如預先載入具有 android.permission.CONTROL_VPN 的 VPN 服務)，裝置實作就「必須」先徵得使用者同意，才能啟用該機制，但如果裝置政策控制器透過 DevicePolicyManager.setAlwaysOnVpnPackage() 啟用該 VPN，則「必須」另外提供同意聲明 (但「必須」通知)。

裝置實作項目「必須」隨附空白的使用者新增憑證授權單位 (CA) 商店，且「必須」為系統信任的 CA 商店預先安裝相同的根憑證 (如同上游 Android 開放原始碼專案中提供)。

當裝置透過 VPN 轉送，或安裝了使用者根 CA，實作「必須」顯示警告，指出使用者可能會監控網路流量。

如果裝置的 USB 連接埠支援 USB 週邊裝置模式，則「必須」顯示使用者介面徵求使用者同意，才能允許透過 USB 連接埠存取共用儲存空間的內容。

9.9.資料儲存加密

針對沒有安全螢幕鎖定的 Android 裝置實作項目可選用。

如果裝置實作項目支援安全螢幕鎖定功能 (如第 9.11.1 節所述)，則裝置「必須」支援應用程式私人資料 (/資料分區) 的資料儲存加密，以及應用程式共用儲存分區 (/sdcard 分區) (如果是不可移除的永久性裝置)。

如果裝置的實作方式支援資料儲存空間加密，且進階加密標準 (AES) 加密效能達 50 MiB/秒，則「必須」在使用者完成開箱設定體驗時，預設啟用資料儲存加密機制。如果裝置原本就已搭載舊版 Android，但預設停用加密功能，這類裝置就無法透過系統軟體更新達成規範，因此「可能」不受這項限制規範。

裝置實作「必須」實施檔案型加密 (FBE)，符合上述資料儲存空間加密規定。

9.9.1。直接啟動

所有裝置都必須實作直接啟動模式 API，即使裝置不支援儲存空間加密功能也一樣。請特別注意，您仍須廣播 LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED 意圖，以通知直接啟動感知的應用程式，指出裝置加密 (DE) 和憑證加密 (CE) 儲存位置可供使用者使用。

9.9.2。檔案型加密

支援 FBE 的裝置實作方式：

  • 「必須」在不要求使用者提供憑證的情況下啟動，並允許直接啟動感知功能應用程式在廣播 LOCKED_BOOT_COMPLETED 訊息後存取裝置加密 (DE) 儲存空間。
  • 「必須」只在使用者提供憑證 (例如密碼、PIN 碼、解鎖圖案或指紋) 解鎖裝置且已播送 ACTION_USER_UNLOCKED 訊息後，才能存取憑證加密 (CE) 儲存空間。裝置實作「不得」以任何方式在未使用者提供憑證的情況下解鎖 CE 保護儲存空間。
  • 「必須」支援驗證開機程序，並確保 DE 金鑰經過加密編譯且會繫結至裝置的硬體信任根層級。
  • 在 XTS 模式下，必須支援使用 AES 加密檔案內容，金鑰長度為 256 位元。
  • 在 CBC-CTS 模式下，必須支援使用 AES 加密檔案名稱，金鑰長度為 256 位元。
  • 「可能」支援檔案內容和檔案名稱加密作業的替代加密、金鑰長度和模式，但預設「必須」使用支援的加密加密、金鑰長度和模式。
  • 應讓預先載入的必要應用程式 (例如鬧鐘、手機、Messenger) 感知直接啟動功能。

保護 CE 和 DE 儲存區域的金鑰：

  • 「必須」以加密方式繫結至硬體支援的 KeyStore。CE 金鑰必須繫結至使用者的螢幕鎖定憑證。如果使用者未指定螢幕鎖定憑證，CE 金鑰「必須」繫結至預設密碼。
  • 不得重複，且不可重複，亦即沒有任何使用者的 CE 或 DE 金鑰與其他使用者的 CE 或 DE 金鑰相符。

上游 Android 開放原始碼專案以 Linux kernel ext4 加密功能為基礎，提供這項功能的偏好實作方式。

9.9.3.全磁碟加密

支援全磁碟加密 (FDE) 的裝置實作項目。「必須」搭配使用 AES 與 128 位元 (或更高) 的金鑰和專為儲存用途設計的模式 (例如 AES-XTS、AES-CBC-ESSIV)。「一律」不得在未加密的情況下，將加密金鑰寫入儲存空間。除了使用中的加密金鑰，加密金鑰也應以 AES 為使用緩慢延展演算法 (例如 PBKDF2 或 Scrypt) 延展的螢幕鎖定憑證來加密。如果使用者未指定螢幕鎖定憑證，或是禁止使用密碼進行加密，系統「必須」使用預設密碼來包裝加密金鑰。如果裝置提供硬體支援的 KeyStore，則密碼延伸演算法「必須」以加密方式繫結至該 KeyStore。「不得」將加密金鑰傳送至裝置外部 (即使是以使用者密碼和/或硬體繫結金鑰包裝)。上游 Android 開放原始碼專案以 Linux kernel 功能 dm-crypt 為基礎，提供這項功能的偏好實作方式。

9.10。裝置完整性

下列規定可確保裝置完整性狀態與裝置完整性息息相關。

裝置實作「必須」正確透過 System API 方法 PersistentDataBlockManager.getFlashLockState() 正確回報系統映像檔的狀態。FLASH_LOCK_UNKNOWN 狀態會保留給從舊版 Android 升級，且這個新的系統 API 方法不存在的裝置實作。

驗證開機程序是保證裝置軟體完整性的功能。如果裝置實作支援這項功能，就「必須」執行下列作業：

  • 宣告平台功能旗標 android.software.verified_boot。
  • 在每個啟動順序上執行驗證。
  • 從不可變更的硬體金鑰開始驗證，該金鑰為信任根，並往上到系統分區。
  • 實作各階段的驗證程序，檢查所有位元組的完整性與真實性，然後再下一個階段執行程式碼。
  • 根據 NIST 現行的雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 建議，使用驗證演算法做為現行的雜湊演算法。
  • 系統驗證失敗時，「不得」允許完成啟動；除非使用者同意嘗試啟動，否則就「不得」使用任何未驗證儲存區塊中的資料。
  • 除非使用者已明確解鎖系統啟動載入程式，否則「不得」允許修改裝置上的已驗證分區。

上游 Android 開放原始碼計畫以 Linux kernel 功能 dm-verity 為基礎，提供這項功能的偏好實作方式。

自 Android 6.0 起，如果裝置的實作方式採用進階加密標準 (AES) 加密效能，每秒 50 MiB 以上，就「必須」支援裝置完整性的驗證開機程序。

如果裝置已啟動，但不支援在舊版 Android 上支援驗證開機程序，這類裝置無法透過系統軟體更新新增這項功能，因此不受這項規定的限制。

9.11.金鑰和憑證

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在容器中，並透過 KeyChain API 或 Keystore API 將其用於加密編譯作業。

所有 Android 裝置實作項目都必須符合下列規定：

  • 請勿限制可產生的金鑰數量，且匯入的金鑰數量至少須有 8,192 個。
  • 螢幕鎖定驗證的嘗試次數「必須」設有頻率限制，且「必須」採用指數輪詢演算法。如果嘗試失敗超過 150 次，則每次嘗試時須等待至少 24 小時。
  • 如果裝置實作支援安全螢幕鎖定，就「必須」使用安全的硬體備份 KeyStore 實作項目，並符合下列規定：
    • 「必須」採用 RSA、AES、ECDSA 和 HMAC 加密編譯演算法，以及 MD5、SHA1、SHA-2 系列雜湊函式，才能正確支援 Android KeyStore 系統支援的演算法。
    • 「必須」在安全硬體中執行螢幕鎖定驗證，且只有在成功允許使用驗證繫結金鑰的情況下。上游 Android 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL)，可用於滿足這項需求。

請注意，如果裝置已推出較舊的 Android 版本，除非宣告需要硬體支援 KeyStore 的 android.hardware.fingerprint 功能，否則此類裝置不必具有硬體支援 KeyStore。

9.11.1.確保螢幕鎖定安全

實作裝置時，「可能」新增或修改用於解鎖螢幕鎖定的驗證方法，但仍須符合下列規定：

  • 如果驗證方式是以已知的密鑰為基礎，則必須符合下列所有規定，才能視為安全螢幕鎖定：
    • 輸入的最短長度熵必須超過 10 位元。
    • 所有可能輸入值的熵上限必須大於 18 位元。
    • 「不得」替換 Android 開放原始碼計畫中提供的任何現有驗證方法 (PIN 碼、解鎖圖案、密碼)。
    • 當裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法 (比 PASSWORD_QUALITY_SOMETHING 更嚴格的品質常數) 設定密碼品質政策時，「必須」停用。
  • 如果用於驗證方式是基於實體權杖或地點，「不得」視為安全螢幕鎖定，除非符合所有以下規定：
  • 如果驗證方式是以生物特徵辨識技術為依據，除非符合所有下列規定，否則「不得」視為安全螢幕鎖定：
    • 「必須」設有備用機制，才能使用一種主要驗證方法；這些驗證方法是以已知的密鑰為基礎，並且符合安全螢幕鎖定的要求。
    • 「必須」停用此設定，並僅允許在 Device Policy Controller (DPC) 應用程式透過呼叫 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) 方法設定 keguard 功能政策時，允許主要驗證機制解鎖螢幕。
    • 裝置的接受率「必須」高於或高於指紋感應器所需上限 (如第 7.3.10 節所述)，否則「必須」停用並只允許在 Device Policy Controller (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法 (比 PASSWORD_QUALITY_BIOMETRIC_WEAK 方法更嚴格的密碼品質政策) 設定密碼品質政策時，允許主要驗證功能解鎖螢幕。
  • 如果系統無法將驗證方式視為安全螢幕鎖定，就會進行下列動作：
  • 如果驗證方法是根據實體符記、地點或生物特徵辨識，假定接受率高於指紋感應器所需的接受率 (如第 7.3.10 節所述)，則：

9.12.資料刪除

裝置「必須」為使用者提供執行「恢復原廠設定」的機制允許以邏輯和實體方式刪除所有資料，但以下情況除外：

  • 系統映像檔
  • 系統映像檔所需的任何作業系統檔案

「必須」刪除所有使用者產生的資料。這必須符合 NIST SP800-88 等相關的資料刪除業界標準。「必須」用於實作第 3.9 節「裝置管理」中所述的 wipeData() API (Android Device 管理 API 的一部分)。

裝置「可能」提供快速抹除資料，可用於執行邏輯資料清除作業。

9.13.安全啟動模式

Android 提供了一個模式，讓使用者能夠啟動模式，這時系統只能執行預先安裝的系統應用程式，並停用所有第三方應用程式。這個模式稱為「安全啟動模式」，可讓使用者解除安裝可能有害的第三方應用程式。

極力要求 Android 裝置實作方式才能實作安全啟動模式，並滿足下列需求：

  • 裝置實作應讓使用者選擇從啟動選單進入安全啟動模式，該模式可透過與一般啟動不同的工作流程進入。

  • 裝置實作項目「必須」為使用者提供進入安全啟動模式的選項，讓安裝在裝置上的第三方應用程式無法進行中斷，除非第三方應用程式為 Device Policy Controller，且將 UserManager.DISALLOW_SAFE_BOOT 旗標設為 true。

  • 裝置實作項目「必須」允許使用者在安全模式下解除安裝任何第三方應用程式。

9.14。汽車車輛系統隔離

Android Automotive 裝置應與重要的車輛子系統交換資料，例如使用車輛 HAL 透過 CAN 公車等車輛網路收發訊息。Android Automotive 裝置實作「必須」導入 Android 架構層下方的安全性功能，防範 Android 架構、第三方應用程式和車輛子系統之間惡意或無意間進行互動。這些安全性功能如下：

  • 限制來自 Android 架構車輛子系統的訊息，例如將允許的訊息類型和訊息來源加入許可清單。
  • 防範來自 Android 架構或第三方應用程式的阻斷服務攻擊。這可避免惡意軟體因流量導致車輛網路受損，而可能導致車輛子系統故障。

10. 軟體相容性測試

裝置實作「必須」通過本節所述的所有測試。

不過請注意，沒有完整的軟體測試套件。因此，裝置實作者強烈建議針對 Android 開放原始碼計畫提供的 Android 參考資料和偏好的實作方式，盡可能進行最低限度的變更。這麼做可將引入錯誤的風險降到最低，讓團隊之間的作業有所不相容，並導致裝置可能更新。

10.1.Compatibility Test Suite

裝置實作項目「必須」通過 Android 開放原始碼計畫提供的 Android Compatibility Test Suite (CTS)，必須使用裝置上的最終出貨軟體。此外，裝置實作者「必須」盡可能使用 Android 開放原始碼樹狀結構中的參照實作項目，且「必須」確保 CTS 作業不明確，以及是否重新導入參照原始碼部分內容時，應確保相容。

CTS 的設計宗旨是在實際裝置上執行。和任何軟體一樣，CTS 本身可能包含錯誤。CTS 的版本與此相容性定義無關，且可能針對 Android 7.0 發布多個 CTS 修訂版本。裝置導入作業「必須」通過裝置軟體完成後可用的最新 CTS 版本。

10.2.CTS 驗證器

裝置實作「必須」在 CTS Verifier 中正確執行所有適用案例。Compatibility Test Suite 隨附 CTS Verifier，主要功能是供真人作業人員測試，可測試無法由自動化系統測試的功能，例如相機和感應器的正確功能。

CTS Verifier 可針對多種硬體進行測試，包括部分為選用硬體。裝置實作「必須」通過本身硬體的所有測試。舉例來說，如果裝置擁有加速計，「必須」在 CTS 驗證器中正確執行加速計測試案例。您或許可以略過或略過這份相容性定義說明文件中註明的選用功能測試案例。

如上所述，每個裝置和每個版本都必須正確執行 CTS Verifier。不過，由於許多版本非常相似，因此裝置實作項目不應在僅有顯著差異的版本中明確執行 CTS Verifier。具體來說，裝置導入方式不同於實作項目，但該實作方法只通過涵蓋的語言代碼、品牌宣傳等組合，但通過 CTS Verifier 驗證。因此請略過 CTS 驗證器測試。

11. 可更新的軟體

裝置實作「必須」提供取代系統軟體所有機制的機制。該機制不需執行「即時」升級，也就是說，裝置必須重新啟動。

任何方法皆可使用，前提是這類方法可以取代裝置上預先安裝的軟體。舉例來說，下列任一方式都能滿足這項需求：

  • 「無線更新」(OTA) 會在重新啟動後使用離線更新功能。
  • 從主機電腦透過 USB 「共用」更新。
  • 重新啟動後即可「離線」更新，並使用卸除式儲存裝置中的檔案進行更新。

但如果裝置採用的裝置支援非計量付費數據連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，就「必須」支援在重新啟動時透過離線更新進行 OTA 下載。

使用的更新機制「必須」支援更新，但不抹除使用者資料。也就是說，更新機制「必須」保留應用程式的私人資料和應用程式分享的資料。請注意，Android 上游軟體具有符合這項規定的更新機制。

如果是搭載 Android 7.0 以上版本的裝置實作項目，更新機制「必須」支援驗證系統映像檔是否與 OTA 後預期結果相同。自 Android 5.1 版起，在上游 Android 開放原始碼計畫中新增以區塊為基礎的 OTA 實作符合這項規定。

如果在裝置實作項目已發布後發現錯誤，但應在合理的產品生命週期中，向 Android 相容性團隊諮詢會影響第三方應用程式相容性，裝置實作者「必須」透過符合上述機制的可用軟體更新來修正錯誤。

Android 內建可讓裝置擁有者應用程式 (如有) 控制系統更新安裝的功能。為協助起見，如果是回報 android.software.device_admin 的裝置系統更新子系統，則「必須」實作 SystemUpdatePolicy 類別所述的行為。

12. 文件變更記錄

如需此版本相容性定義的異動摘要，請參閱：

個別部分的異動摘要：

  1. 簡介
  2. 裝置類型
  3. 軟體
  4. 應用程式封裝
  5. 多媒體
  6. 開發人員工具與選項
  7. 硬體相容性
  8. 效能與電力
  9. 安全性模型
  10. 軟體相容性測試
  11. 可更新的軟體
  12. 文件變更記錄
  13. 聯絡我們

12.1.查看變更記錄的提示

變更會標示如下：

  • CDD
    相容性需求大幅變更。

  • 文件
    外觀或建構相關變換。

為方便查看，請在變更記錄網址中附加 pretty=full 和 no-merges 網址參數。

13. 聯絡我們

您可以加入 android-compatibility 論壇，詢問有關文件未涵蓋的問題或提出任何問題。