Android 8.0 相容性定義

1. 簡介

本文件列舉出讓裝置與 Android 8.0 相容必須遵循的規定。

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

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

裝置實作項目「必須」符合此相容性定義中的規定，包括透過參考資料納入的所有文件，才算與 Android 8.0 相容。

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

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

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

1.1 文件結構

1.1.1. 各裝置類型的規定

第 2 節：說明適用於特定裝置類型的所有規定。第 2 節的每個子節都專指特定裝置類型。

請參閱第 2 節之後的章節，瞭解其他所有 Android 裝置實作項目通用的通用規定。這些需求在本文件中稱為「核心需求」。

1.1.2. 規定 ID

系統會針對「必須」的規定指派要求 ID。

• 一組 ID 僅用於「必須」的規定。
• 強烈建議的規定會標示為 [SR]，但尚未指派 ID。
• ID 組成元素：裝置類型 ID - 條件 ID - 要求 ID (例如 C-0-1)。

每個 ID 的定義如下：

• 裝置類型 ID (詳情請參閱2. 裝置類型
  • C：核心 (適用於任何 Android 裝置實作作業的規定)
  • H：Android 手持裝置
  • T：Android 電視裝置
  • A：Android Automotive 實作
  • 分頁：Android 平板電腦實作
• 條件 ID
  • 當要求為無條件時，這個 ID 會設為 0。
  • 如果條件為條件式，系統會為第 1 項條件指派 1，並在相同區段和相同的裝置類型上遞增 1。
• 規定 ID
  • 這個 ID 從 1 開始，在相同區段和相同的條件中以 1 遞增。

1.1.3. 第 2 節中的要求 ID

第 2 節中的規定 ID 開頭為對應部分 ID，後面接著上述要求 ID。

• 第 2 節中的 ID 包含：部分 ID / 裝置類型 ID - 條件 ID - 規定 ID (例如 7.4.3/A-0-1)。

2. 裝置類型

雖然 Android 開放原始碼計畫提供適用於各種裝置類型和板型規格的軟體堆疊，但其中幾種裝置類型具有相對較高的應用程式發布生態系統。

本節說明這些裝置類型，以及各裝置類型適用的其他規定和建議。

凡是不符合上述裝置類型的所有 Android 裝置實作項目，仍必須符合本相容性定義其他章節中的所有規定。

2.1 裝置設定

如要瞭解各裝置類型的硬體設定主要差異，請參閱本節所述的裝置特殊需求。

2.2. 手持裝置需求

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

如果 Android 裝置的實作方式符合下列所有條件，就會歸類為手持裝置：

• 使用可提供行動性的電源 (例如電池)。
• 螢幕對角線螢幕尺寸應介於 2.5 到 8 吋。

本節其他內容的規定僅適用於 Android 手持裝置實作方式。

注意：不適用於 Android Tablet 裝置的要求會標上 *。

2.2.1. 硬體

手持裝置實作方式：

• [7.1.1.1/H-0-1] 螢幕對角線長度至少要有 2.5 吋。
• [7.1.1.3/H-SR] 極力建議您為使用者提供變更顯示大小的選項 (螢幕密度)。
• [7.1.5/H-0-1] 必須支援上游 Android 開放原始碼所實作的舊版應用程式相容性模式。也就是說，裝置實作「不得」變更啟用相容性模式時的觸發條件或門檻，「不得」變更相容性模式本身的行為。
• [7.2.1/H-0-1] 必須支援第三方輸入法編輯器 (IME) 應用程式。
• [7.2.3/H-0-1] 「必須」提供「主畫面」、「最近使用」和「返回」功能。
• [7.2.3/H-0-2] 必須同時將返回函式 (KEYCODE_BACK) 的正常和長按事件傳送至前景應用程式。
• [7.2.4/H-0-1] 必須支援觸控螢幕輸入。
• [7.3.1/H-SR] 強烈建議加入 3 軸式加速度計。

如果手持裝置實作包含 3 軸式加速度計，則表示：

• [7.3.1/H-1-1] 事件的回報頻率必須至少為 100 Hz。

如果手持裝置實作項目內含陀螺儀，這項功能會：

• [7.3.4/H-1-1] 事件的回報頻率必須至少為 100 Hz。

手持裝置實作項目，可撥打語音通話，且在 getPhoneType 中表示 PHONE_TYPE_NONE 以外的任何值：

• [7.3.8/H] 必須使用鄰近感應器。

手持裝置實作方式：

• [7.3.12/H-SR] 我們建議支援 6 度自由度的姿勢感應器。
• [7.4.3/H]必須支援藍牙和藍牙 LE。

如果手持裝置實作「計量付費連線」，請按照下列步驟操作：

• [7.4.7/H-1-1] 「必須」提供數據節省模式。

手持裝置實作方式：

• [7.6.1/H-0-1] 至少須有 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。
• [7.6.1/H-0-2] 如果核心和使用者空間可用的記憶體少於 1 GB，則必須針對 ActivityManager.isLowRamDevice() 傳回「true」。

如果手持裝置實作項目是 32 位元：

• [7.6.1/H-1-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 512 MB：

  • 在小螢幕/一般螢幕上，280 dpi 以下^*
  • ldpi 或更低階的大螢幕
  • 大螢幕上的 mdpi 或更低

• [7.6.1/H-2-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 608 MB：

  • 小尺寸/一般螢幕適用的 xhdpi 以上^*
  • 大螢幕上支援 hdpi 或更高版本
  • 大於大型螢幕的 mdpi 以上版本

• [7.6.1/H-3-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 896 MB：

  • 在小螢幕/一般螢幕上，400 dpi 以上^*
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本

• [7.6.1/H-4-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1344MB：

  • 在小螢幕/一般螢幕上搭載 560 dpi 以上^*
  • 在大螢幕裝置上設為 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕

如果手持裝置實作項目是 64 位元：

• [7.6.1/H-5-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 816 MB：

  • 在小螢幕/一般螢幕上，280 dpi 以下^*
  • ldpi 或更低階的大螢幕
  • 大螢幕上的 mdpi 或更低

• [7.6.1/H-6-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 944MB：

  • 小尺寸/一般螢幕適用的 xhdpi 以上^*
  • 大螢幕上支援 hdpi 或更高版本
  • 大於大型螢幕的 mdpi 以上版本

• [7.6.1/H-7-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1280 MB：

  • 在小螢幕/一般螢幕上，400 dpi 以上^*
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本

• [7.6.1/H-8-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1824MB：

  • 在小螢幕/一般螢幕上搭載 560 dpi 以上^*
  • 在大螢幕裝置上設為 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕

請注意，上述的「核心和使用者空間可用的記憶體」是指除了已專用於任何硬體元件 (例如無線電、影片等) 不在核心在裝置實作控制下的記憶體之外，額外提供的記憶體空間。

手持裝置實作方式：

• [7.6.2/H-0-1] 「不得」提供小於 1 GiB 的應用程式共用儲存空間。
• [7.7.1/H] 必須納入支援週邊裝置模式的 USB 連接埠。

如果手持裝置內含支援週邊裝置模式的 USB 連接埠，就會：

• [7.7.1/H-1-1] 必須實作 Android Open Accessory (AOA) API。

手持裝置實作方式：

• [7.8.1/H-0-1] 必須隨附麥克風。
• [7.8.2/H-0-1] 必須備妥音訊輸出並宣告 android.hardware.audio.output。

如果手持裝置實作支援 VR 模式，他們會：

• [7.9.1/H-1-1] 必須宣告 android.software.vr.mode 功能。

如果裝置實作方式宣告了 android.software.vr.mode 功能，就會：

• [7.9.1/H-2-1] 必須納入實作 android.service.vr.VrListenerService 的應用程式，可透過 android.app.Activity#setVrModeEnabled 啟用 VR 應用程式。

如果手持裝置實作能符合宣告 android.hardware.vr.high_performance 功能標記的所有需求條件，則會發生以下情形：

• [7.9.2/-1-1] 必須宣告 android.hardware.vr.high_performance 功能旗標。

2.2.2. 多媒體

手持裝置實作「必須」支援下列音訊編碼：

• [5.1.1/H-0-1] AMR-NB
• [5.1.1/H-0-2] AMR-WB
• [5.1.1/H-0-3] MPEG-4 AAC 設定檔 (AAC LC)
• [5.1.1/H-0-4] MPEG-4 HE AAC 設定檔 (AAC+)
• [5.1.1/H-0-5] AAC ELD (強化低延遲 AAC)

手持裝置實作「必須」支援下列音訊解碼功能：

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

手持裝置實作項目「必須」支援下列影片編碼，並提供給第三方應用程式：

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8

手持裝置實作「必須」支援下列影片解碼功能：

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

2.2.3. Software

手持裝置實作方式：

• [3.4.1/H-0-1] 必須提供 android.webkit.Webview API 的完整實作。
• [3.4.2/H-0-1] 必須安裝獨立的瀏覽器應用程式，供一般使用者瀏覽網頁。
• [3.8.1/H-SR] 極力建議您導入支援應用程式內捷徑和小工具固定功能的預設啟動器。
• [3.8.1/H-SR] 強烈建議你導入預設啟動器，讓你可透過 ShortcutManager API 快速存取第三方應用程式提供的其他捷徑。
• [3.8.1/H-SR] 我們強烈建議您納入預設的啟動器應用程式，並在應用程式圖示上顯示標記。
• [3.8.2/H-SR] 強烈建議支援第三方應用程式小工具。
• [3.8.3/H-0-1] 必須允許第三方應用程式透過 Notification 和 NotificationManager API 類別通知使用者值得注意的事件。
• [3.8.3/H-0-2] 必須支援複合式通知。
• [3.8.3/H-0-3] 必須支援抬頭通知。
• [3.8.3/H-0-4] 必須納入通知欄，讓使用者能夠透過使用者預設用途直接控制 (例如回覆、延後、關閉、封鎖) 通知，例如透過動作按鈕或 Android 開放原始碼計畫導入的控制台等。
• [3.8.4/H-SR] 強烈建議你在裝置上實作助理，以便處理輔助動作。

如果 Android 手持裝置實作支援螢幕鎖定，功能會：

• [3.8.10/H-1-1] 「必須」顯示螢幕鎖定畫面通知，包括媒體通知範本。

如果手持裝置支援安全螢幕鎖定，功能會：

• [3.9/H-1-1] 必須導入 Android SDK 說明文件中定義的所有裝置管理政策。

手持裝置實作方式：

• [3.10/H-0-1] 必須支援第三方無障礙服務。
• [3.10/H-SR] 強烈建議在裝置上預先載入無障礙服務，與切換控制功能和 TalkBack (適用於預先載入的文字轉語音引擎支援的語言) 無障礙服務 (適用於預先載入的文字轉語音引擎支援的語言) 相同 (如TalkBack 開放原始碼專案所提供)。
• [3.11/H-0-1] 必須支援第三方 TTS 引擎的安裝作業。
• [3.11/H-SR] 強烈建議提供支援裝置可用語言的 TTS 引擎。
• [3.13/H-SR] 強烈建議你加入快速設定 UI 元件。

如果 Android 手持裝置實作項目宣告 FEATURE_BLUETOOTH 或 FEATURE_WIFI 支援，程式碼會：

• [3.15/H-1-1] 必須支援隨附裝置配對功能。

2.2.4. 效能與電源

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

手持裝置實作方式：

• [8.2/H-0-1] 必須確保連續寫入效能至少達到 5 MB。
• [8.2/H-0-2] 必須確保每秒至少寫入效能達到 0.5 MB。
• [8.2/H-0-3] 必須確保連續讀取效能至少達到每秒 15 MB。
• [8.2/H-0-4] 必須確保每秒至少 3.5 MB 的隨機讀取效能。
• [8.3/H-0-1] 必須向使用者顯示所有應用程式，不受應用程式待命和打盹省電模式限制。
• [8.3/H-0-2]「應用程式待命」和「打盹省電模式」的全域系統設定「必須」不同於 Android 開放原始碼計畫，用於觸發、維護、喚醒演算法和全域系統設定。

手持裝置實作方式：

• [8.4/H-0-1] 「必須」依元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。
• [8.4/H-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/H-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/H-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，將電源用量提供給應用程式開發人員。
• [8.4/H] 無法將硬體元件的電力用量歸功給應用程式時，應歸於硬體元件本身。

如果手持裝置實作項目包含畫面或影片輸出內容，就會發生以下情形：

• [8.4/H-1-1] 必須遵循 android.intent.action.POWER_USAGE_SUMMARY 意圖，並顯示顯示此耗電量的設定選單。

2.2.5。安全性模型

手持裝置實作方式：

• [9.1/H-0-1] 「必須」允許第三方應用程式透過 android.permission.PACKAGE_USAGE_STATS 權限存取使用統計資料，並提供使用者可存取的機制，以回應 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，授予或撤銷對這類應用程式的存取權。

2.3. 電視需求

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

如果 Android 裝置的實作方式符合下列所有條件，就會歸類為電視：

• 已提供遠端控制顯示幕上可由離使用者約十英尺的機制。
• 內嵌螢幕的對角線長度大於 24 吋，或是加入影片輸出連接埠，例如 VGA、HDMI、DisplayPort 或用於顯示螢幕的無線連接埠。

本節其餘部分的其他規定僅適用於 Android TV 裝置實作方式。

2.3.1. 硬體

電視裝置實作方式：

• [7.2.2/T-0-1] 必須支援 D-Pad。
• [7.2.3/T-0-1] 必須提供「主畫面」和「返回」功能。
• [7.2.3/T-0-2] 必須同時將返回函式 (KEYCODE_BACK) 的正常和長按事件傳送至前景應用程式。
• [7.2.6.1/T-0-1] 必須納入遊戲控制器的支援功能，並宣告 android.hardware.gamepad 功能標記。
• [7.2.7/T] 應提供遙控器，讓使用者透過非觸控式瀏覽和核心瀏覽鍵輸入功能。

如果電視裝置導入作業含有陀螺儀，這項功能會：

• [7.3.4/T-1-1] 事件的回報頻率必須至少為 100 Hz。

電視裝置實作方式：

• [7.4.3/T-0-1] 必須支援藍牙和藍牙 LE。
• [7.6.1/T-0-1] 至少須有 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。

如果電視裝置導入方式是 32 位元：

• [7.6.1/T-1-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 896 MB：

  • 在小螢幕/一般螢幕上，400 dpi 以上
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本

如果電視裝置導入方式是 64 位元：

• [7.6.1/T-2-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1280 MB：

  • 在小螢幕/一般螢幕上，400 dpi 以上
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本

請注意，上述的「核心和使用者空間可用的記憶體」是指除了已專用於任何硬體元件 (例如無線電、影片等) 不在核心在裝置實作控制下的記憶體之外，額外提供的記憶體空間。

電視裝置實作方式：

• [7.8.1/T] 必須配備麥克風。
• [7.8.2/T-0-1] 必須具有音訊輸出，並宣告 android.hardware.audio.output。

2.3.2. 多媒體

電視裝置實作「必須」支援下列音訊編碼：

• [5.1/T-0-1] MPEG-4 AAC 設定檔 (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC 設定檔 (AAC+)
• [5.1/T-0-3] AAC ELD (強化低延遲 AAC)

電視裝置實作「必須」支援下列影片編碼：

• [5.2/T-0-1] H.264 AVC
• [5.2/T-0-2] VP8

電視裝置實作方式：

• [5.2.2/T-SR] 強烈建議你支援 720p 和 1080p 解析度影片的 H.264 編碼。
• [5.22/T-SR] 強烈建議支援以每秒 30 個影格 (fps) 播放 1080p 解析度影片的 H.264 編碼。

電視裝置實作「必須」支援下列影片解碼功能：

• [5.3/T-0-1] H.264 AVC
• [5.3/T-0-2] H.265 HEVC
• [5.3/T-0-3] MPEG-4 SP
• [5.3/T-0-4] VP8
• [5.3/T-0-5] VP9

極力建議您導入電視裝置，以便支援下列影片解碼功能：

• [5.3/T-SR] MPEG-2

如果電視裝置實作支援 H.264 解碼器，就會：

• [5.3.4/T-1-1] 必須支援高設定檔等級 4.2 和 HD 1080p (每秒 60 fps) 的解碼設定檔。
• [5.3.4/T-1-2] 必須能夠使用下表所示的 HD 高畫質設定檔，透過基準設定檔、主要設定檔或高設定檔等級 4.2 編碼影片。

如果電視裝置實作支援 H.265 轉碼器和 HD 1080p 解碼設定檔，則：

• [5.3.5/T-1-1] 必須支援主要設定檔層級 4.1 的主要層級。
• [5.3.5/T-SR] 強烈建議「建議」支援 HD 1080p 的 60 FPS 影片影格速率。

如果電視裝置實作支援 H.265 轉碼器和 UHD 解碼設定檔，請按照下列步驟操作：

• [5.3.5/T-2-1] 轉碼器必須支援 Main10 第 5 級主要層級設定檔。

如果電視裝置導入方式支援 VP8 轉碼器，就會：

• [5.3.6/T-1-1] 必須支援 HD 1080p60 解碼設定檔。

如果電視裝置導入作業支援 VP8 轉碼器及支援 720p，請按照下列步驟操作：

• [5.3.6/T-2-1] 必須支援 HD 720p60 解碼設定檔。

如果電視裝置實作支援 VP9 轉碼器和 UHD 超高畫質影片解碼，程式碼就會：

• [5.3.7/T-1-1] 必須支援 8 位元色彩深度，且必須支援 VP9 設定檔 2 (10 位元)。

如果電視裝置實作支援 VP9 轉碼器、1080p 設定檔和 VP9 硬體解碼，程式碼會：

• [5.3.7/T-2-1] 1080p 必須支援 60 fps。

電視裝置實作方式：

• [5.8/T-SR] 極力建議支援安全串流同時解碼。我們強烈建議至少同時為兩個團隊解碼。

如果裝置實作項目為 Android 電視裝置，且支援 4K 解析度，就會：

• [5.8/T-1-1] 必須支援所有有線外接螢幕的 HDCP 2.2。

如果電視裝置導入方式不支援 4K 解析度，可能會發生下列情形：

• [5.8/T-2-1] 必須支援所有有線外接螢幕的 HDCP 1.4。

電視裝置實作方式：

• [5.5.3/T-0-1]「必須」針對支援的輸出內容提供系統主音量和數位音訊輸出音量等級的支援，但壓縮音訊直通輸出 (裝置不會進行音訊解碼) 除外。

2.3.3. Software

電視裝置實作方式：

• [3/T-0-1] 必須宣告 android.software.leanback 和 android.hardware.type.television 功能。
• [3.4.1/T-0-1] 必須提供 android.webkit.Webview API 的完整實作。

如果 Android TV 裝置實作支援螢幕鎖定，其功能如下：

• [3.8.10/T-1-1] 必須顯示螢幕鎖定畫面通知，包括媒體通知範本。

電視裝置實作方式：

• [3.8.14/T-SR] 強烈建議你支援子母畫面 (PIP) 模式多視窗模式。
• [3.10/T-0-1] 必須支援第三方無障礙服務。
• [3.10/T-SR] 強烈建議在裝置上預先載入無障礙服務，與切換控制功能和 TalkBack (適用於預先載入的文字轉語音引擎支援的語言) 無障礙服務 (適用於預先載入的文字轉語音引擎支援的語言) 相同 (如TalkBack 開放原始碼專案所提供)。

如果電視裝置導入方式回報 android.hardware.audio.output 功能，就會發生以下情形：

• [3.11/T-SR] 強烈建議你提供支援裝置可用語言的 TTS 引擎。
• [3.11/T-1-1] 必須支援安裝第三方 TTS 引擎。

電視裝置實作方式：

• [3.12/T-0-1] 必須支援電視輸入架構。

2.2.4. 效能與電源

• [8.1/T-0-1] 影格延遲時間一致。影格延遲不一致或轉譯影格延遲「不得」在一秒內發生超過 5 個影格，且每秒必須低於 1 個影格。
• [8.2/T-0-1] 必須確保連續寫入效能至少達到每秒 5 MB。
• [8.2/T-0-2] 必須確保每秒寫入效能至少達到 0.5 MB。
• [8.2/T-0-3] 必須確保每秒至少 15 MB 的連續讀取效能。

• [8.2/T-0-4] 必須確保每秒至少 3.5 MB 的隨機讀取效能。

• [8.3/T-0-1] 必須向使用者顯示所有不受應用程式待命和打盹省電模式限制的應用程式。

• [8.3/T-0-2]「應用程式待命」和「打盹省電模式」的全域系統設定「必須」獨立於 Android 開放原始碼計畫中，觸發、維護、喚醒演算法和使用的全域系統設定。

電視裝置實作方式：

• [8.4/T-0-1] 「必須」依元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。
• [8.4/T-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/T-0-3] 必須回報每個程序 UID 的 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/T] 無法將硬體元件的電力用量歸功給應用程式時，應歸於硬體元件本身。
• [8.4/T-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供此電源用量。

2.4. 手錶需求

Android Watch 裝置是指想戴在身體 (例如手腕) 上的 Android 裝置實作。

Android 裝置的實作方式須符合下列所有條件，才能歸類為 Watch：

• 螢幕的實際對角線長度必須介於 1.1 到 2.5 吋之間。
• 提供要戴在身上的機制。

本節其餘規定僅適用於 Android Watch 裝置實作方式。

2.4.1. 硬體

手錶裝置實作：

• [7.1.1.1/W-0-1] 螢幕的實際對角線尺寸必須介於 1.1 到 2.5 吋之間。

• [7.2.3/W-0-1] 必須為使用者提供主畫面功能和返回功能，但位於 UI_MODE_TYPE_WATCH 時除外。

• [7.2.4/W-0-1] 必須支援觸控螢幕輸入。

• [7.3.1/W-SR] 強烈建議加入 3 軸式加速度計。

• [7.4.3/W-0-1] 必須支援藍牙。

• [7.6.1/W-0-1] 至少要有 1 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)

• [7.6.1/W-0-2] 核心和使用者空間至少必須有 416 MB 可用的記憶體。

• [7.8.1/W-0-1] 必須包含麥克風。

• [7.8.2/W] 可能，但不應有音訊輸出。

2.4.2. 多媒體

沒有其他相關規定。

2.4.3. Software

手錶裝置實作：

• [3/W-0-1] 必須宣告 android.hardware.type.watch 功能。
• [3/W-0-2] 必須支援 uiMode = UI_MODE_TYPE_WATCH。

手錶裝置實作：

• [3.8.4/W-SR] 強烈建議你在裝置上實作助理，以便處理輔助動作。

宣告 android.hardware.audio.output 功能旗標的手錶裝置實作方式：

• [3.10/W-1-1] 必須支援第三方無障礙服務。
• [3.10/W-SR] 強烈建議在裝置上預先載入無障礙服務，與切換控制功能和 TalkBack (適用於預先載入的文字轉語音引擎支援的語言) 無障礙服務 (適用於預先載入的文字轉語音引擎支援的語言) 相同 (如TalkBack 開放原始碼專案所提供)。

如果手錶裝置實作回報 android.hardware.audio.output 功能，請注意以下事項：

• [3.11/W-SR] 強烈建議提供支援裝置可用語言的 TTS 引擎。

• [3.11/W-0-1] 必須支援第三方 TTS 引擎的安裝作業。

2.5. 汽車規定

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

如果 Android 裝置的實作方式宣告了 android.hardware.type.automotive 功能或符合下列所有條件，就會歸類為 Automotive 應用程式。

• 嵌入或連接汽車車輛的一部分。
• 使用駕駛座椅列的螢幕做為主要顯示器。

本節其餘規定僅適用於 Android Automotive 裝置實作。

2.5.1. 硬體

Automotive 裝置實作：

• [7.1.1.1/A-0-1] 螢幕的實際對角線大小至少必須為 6 吋。

• [7.1.1.1/A-0-2] 螢幕大小版面配置必須至少為 750 dp x 480 dp。

• [7.2.3/A-0-1] 「必須」提供主畫面功能，且「可能」提供返回和最近使用的功能。

• [7.2.3/A-0-2] 必須將返回函式的正常和長按事件 (KEYCODE_BACK) 同時傳送至前景應用程式。

• [7.3.1/A-SR] 強烈建議加入 3 軸式加速度計。

如果 Automotive 裝置實作包含 3 軸式加速度計，請按照下列步驟操作：

• [7.3.1/A-1-1] 事件的回報頻率必須至少為 100 Hz。
• [7.3.1/A-1-2] 必須遵守 Android 車用感應器座標系統。

如果 Automotive 裝置實作包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能標記向應用程式回報功能，請執行以下操作：

• [7.3.3/A-1-1] GNSS 技術的產生作業「必須」是「2017 年」以後的年份。

如果 Automotive 裝置導入了陀螺儀，則必須：

• [7.3.4/A-1-1] 事件的回報頻率必須至少為 100 Hz。

Automotive 裝置實作：

• [7.3.11/A] 請將目前的設備設為 SENSOR_TYPE_GEAR。

Automotive 裝置實作：

• [7.3.11.2/A-0-1] 必須支援定義為 SENSOR_TYPE_NIGHT 的日間/夜間模式。
• [7.3.11.2/A-0-2] SENSOR_TYPE_NIGHT 旗標的值必須與資訊主頁日間/夜間模式一致，且應根據環境光度感應器輸入的內容。

• 基礎環境光度感應器可能與 Photometer 相同。

• [7.3.11.3/A-0-1] 必須支援定義為 SENSOR_TYPE_DRIVING_STATUS 的行車狀態，且車輛全面停止並停車時，預設值為 DRIVE_STATUS_UNRESTRICTED。裝置製造商必須負責設定 SENSOR_TYPE_DRIVING_STATUS，以符合運送產品市場適用的所有法律和法規。

• [7.3.11.4/A-0-1] 必須提供定義為 SENSOR_TYPE_CAR_SPEED 的車輛速度。

• [7.4.3/A-0-1] 必須支援藍牙，而且必須支援藍牙 LE。

• [7.4.3/A-0-2] Android Automotive 實作項目「必須」支援下列藍牙設定檔：
  • 透過免持聽筒設定檔 (HFP) 撥打電話。
  • 透過音訊發布設定檔 (A2DP) 播放媒體。
  • 透過遠端控制設定檔 (AVRCP) 控制媒體播放。
  • 透過電話簿存取設定檔 (PBAP) 分享聯絡人。

• [7.4.3/A] 必須支援訊息存取設定檔 (MAP)。

• [7.4.5/A] 必須支援行動數據連線。

• [7.6.1/A-0-1] 至少須有 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。

如果 Automotive 裝置實作作業是 32 位元：

• [7.6.1/A-1-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 512 MB：

  • 在小螢幕/一般螢幕上，280dpi 以下
  • ldpi 或更低階的大螢幕
  • 大螢幕上的 mdpi 或更低

• [7.6.1/A-1-2] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 608 MB：

  • 小尺寸/一般螢幕適用的 xhdpi 或更高版本
  • 大螢幕上支援 hdpi 或更高版本
  • 大於大型螢幕的 mdpi 以上版本

• [7.6.1/A-1-3] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 896 MB：

  • 在小螢幕/一般螢幕上，400 dpi 以上
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本

• [7.6.1/A-1-4] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1344 MB：

  • 小型/一般螢幕上均採用 560 dpi 或更高版本
  • 在大螢幕裝置上設為 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕

如果 Automotive 裝置實作項目為 64 位元：

• [7.6.1/A-2-1] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 816 MB：

  • 在小螢幕/一般螢幕上，280dpi 以下
  • ldpi 或更低階的大螢幕
  • 大螢幕上的 mdpi 或更低

• [7.6.1/A-2-2] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 944 MB：

  • 小尺寸/一般螢幕適用的 xhdpi 或更高版本
  • 大螢幕上支援 hdpi 或更高版本
  • 大於大型螢幕的 mdpi 以上版本

• [7.6.1/A-2-3] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1280 MB：

  • 在小螢幕/一般螢幕上，400 dpi 以上
  • 在大螢幕上使用 xhdpi 或更高版本
  • 搭載 tvdpi 以上版本

• [7.6.1/A-2-4] 如果使用下列任一密度，核心和使用者空間的可用記憶體必須至少為 1824 MB：

  • 小型/一般螢幕上均採用 560 dpi 或更高版本
  • 在大螢幕裝置上設為 400 dpi 以上
  • 搭載 xhdpi (含) 以上大螢幕

請注意，上述的「核心和使用者空間可用的記憶體」是指除了已專用於任何硬體元件 (例如無線電、影片等) 不在核心在裝置實作控制下的記憶體之外，額外提供的記憶體空間。

Automotive 裝置實作：

• [7.7.1/A] 必須納入支援週邊裝置模式的 USB 連接埠。

Automotive 裝置實作：

• [7.8.1/A-0-1] 必須包含麥克風。

Automotive 裝置實作：

• [7.8.2/A-0-1] 必須具有音訊輸出，並宣告 android.hardware.audio.output。

2.5.2。多媒體

Automotive 裝置實作項目「必須」支援下列音訊編碼：

• [5.1/A-0-1] MPEG-4 AAC 設定檔 (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC 設定檔 (AAC+)
• [5.1/A-0-3] AAC ELD (強化低延遲 AAC)

Automotive 裝置實作項目「必須」支援下列影片編碼：

• [5.2/A-0-1] H.264 AVC
• [5.2/A-0-2] VP8

Automotive 裝置實作項目「必須」支援下列影片解碼功能：

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

我們強烈建議實作 Automotive 裝置，以便支援下列影片解碼功能：

• [5.3/A-SR] H.265 HEVC

2.5.3. Software

Automotive 裝置實作：

• [3/A-0-1] 必須宣告 android.hardware.type.automotive 功能。
• [3/A-0-2] 必須支援 uiMode = UI_MODE_TYPE_CAR。

• [3/A-0-3] Android Automotive 實作項目「必須」支援 android.car.* 命名空間中的所有公用 API。

• [3.4.1/A-0-1] 必須提供 android.webkit.Webview API 的完整實作。

• [3.8.3/A-0-1] 如第三方應用程式要求，「必須」顯示使用 Notification.CarExtender API 的通知。

• [3.8.4/A-0-1] 必須在裝置上實作助理才能處理輔助動作。

• [3.14/A-0-1] 必須納入 UI 架構，以支援使用媒體 API 的第三方應用程式，如第 3.14 節所述。

2.2.4. 效能與電源

Automotive 裝置實作：

• [8.3/A-0-1] 必須向使用者顯示所有應用程式，不受應用程式待命和打盹省電模式限制。

• [8.3/A-0-2]「應用程式待命」和「打盹省電模式」的全域系統設定「必須」不同於 Android 開放原始碼計畫，用於觸發、維護、喚醒演算法和全域系統設定的使用方式。

• [8.4/A-0-1] 「必須」依元件提供個別元件的電源設定檔，定義每個硬體元件的目前消耗量值，以及 Android 開放原始碼計畫網站所述的元件長期消耗電量。

• [8.4/A-0-2] 請務必以毫安小時 (mAh) 回報所有耗電量值。
• [8.4/A-0-3] 必須針對每個程序的 UID 回報 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [8.4/A] 無法將硬體元件的電力用量歸功給應用程式時，應歸於硬體元件本身。
• [8.4/A-0-4] 您必須透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供此電源用量。

2.2.5。安全性模型

如果 Automotive 裝置實作項目包含多位使用者，就會執行以下動作：

• [9.5/A-1-1] 必須包含訪客帳戶，以便允許車輛系統提供的所有功能，而且不必使用者登入。

Automotive 裝置實作：

• [9.14/A-0-1] 必須控管來自 Android 架構車輛子系統的訊息，例如將允許的訊息類型和訊息來源加入許可清單。
• [9.14/A-0-2] 必須監控 Android 架構或第三方應用程式中的阻斷服務攻擊。這樣可以防止惡意軟體在車輛網路中流出流量，進而防止車輛子系統故障。

2.6. 平板電腦需求

「Android 平板電腦裝置」是指通常雙手握住的 Android 裝置實作內容，而不是放在貝殼式板型規格中。

Android 裝置的實作方式符合下列所有條件，就會歸類為平板電腦：

• 使用可提供行動性的電源 (例如電池)。
• 螢幕對角線螢幕尺寸介於 7 到 18 吋之間。

平板電腦裝置實作的要求與手持裝置實作類似。該節中會以 和 * 標示例外狀況，詳情請參閱本節。

2.4.1. 硬體

螢幕大小

• [7.1.1.1/Tab-0-1] 螢幕必須在 7 到 18 英寸的範圍內。

記憶體與儲存空間下限 (第 7.6.1 節)

手持裝置需求列出的小型/一般螢幕螢幕密度不適用於平板電腦。

USB 週邊裝置模式 (第 7.7.1 節)

如果平板電腦裝置實作包含支援週邊裝置模式的 USB 連接埠，就會：

• [7.7.1/Tab]可能會實作 Android Open Accessory (AOA) API。

虛擬實境模式 (第 7.9.1 節)

虛擬實境高效能 (第 7.9.2 節)

虛擬實境要求不適用於平板電腦。

3. Software

3.1. 代管 API 相容性

代管的 Dalvik 位元碼執行環境是 Android 應用程式的主要工具。Android 應用程式設計介面 (API) 是一組 Android 平台介面，會向在代管執行階段環境中執行的應用程式公開。

• [C-0-1] 裝置實作「必須」針對 Android SDK 所公開的任何 API 所記錄的 API，或是任何在上游 Android 原始碼中以「@SystemApi」標記裝飾的 API 提供完整實作，包括所有記載的行為。

• [C-0-2] 裝置的實作「必須」支援/保留所有 TestApi 註解 (@TestApi) 標示的類別、方法和相關元素。

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

• [C-0-4] 裝置實作「必須」保持 API 的呈現和行為，並維持合理的方式，即使 Android 中的部分硬體功能遭到省略，如要瞭解這個情境的具體需求，請參閱第 7 節。

3.1.1. Android 擴充功能

Android 支援擴充代管 API，同時保持相同的 API 級別版本。

• [C-0-1] Android 裝置實作項目「必須」預先載入共用程式庫 ExtShared 和服務 ExtServices 的 Android 開放原始碼計畫實作項目，且版本必須高於或等於每個 API 級別允許的最低版本。舉例來說，針對 Android 7.0 裝置實作項目，搭載 API 級別 24 的裝置「必須」包含至少 1 版。

3.2. 軟 API 相容性

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

3.2.1. 權限

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

3.2.2。版本參數

Android API 在 android.os.Build 類別中加入多個常數，用於描述目前裝置。

• [C-0-1] 為了在不同裝置實作項目中提供一致且有意義的值，下表針對這些值的其他格式設有額外限制，規範裝置導入方式必須符合哪些規範。

參數	詳細資料
VERSION.RELEASE	目前執行 Android 系統的版本，採用人類可讀的格式。這個欄位必須包含 8.0 中定義的其中一個字串值。
VERSION.SDK	目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 8.0，這個欄位「必須」含有 8.0_INT 整數值。
VERSION.SDK_INT	目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 8.0，這個欄位「必須」含有 8.0_INT 整數值。
VERSION.INCREMENTAL	裝置實作人員選擇的值，以人類可讀的格式指定目前執行 Android 系統的特定版本。使用者可用的不同版本「不得」重複使用這個值。這個欄位的常見用途是指出用於產生建構作業的版本號碼或原始碼控制變更 ID。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
遊戲板	裝置實作人員選擇的值，以人類可讀的格式識別裝置所使用的特定內部硬體。這個欄位的可能用途，是指出裝置供電的主機板特定修訂版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
品牌	這個值代表使用者所已知與裝置相關的品牌名稱。必須採用人類可讀的格式，且應代表裝置的製造商或銷售裝置的公司品牌。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
SUPPORTED_ABIS	原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
SUPPORTED_32_BIT_ABIS	原生程式碼的指示集名稱 (CPU 類型 + ABI 慣例)。請參閱第 3.3 節。原生 API 相容性。
SUPPORTED_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_-]+$」。在產品生命週期內，這個裝置名稱「不得」變更。
FINGERPRINT	專門用於識別此版本的字串。產品必須清晰可讀。請務必遵循以下範本： $(BRAND)/$(PRODUCT)/ $(裝置):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 例如： acme/myproduct/ mydevice:8.0/LMYXX/3359:userdebug/test-keys 指紋「不得」包含空白字元。如果上述範本中的其他欄位含有空白字元，則這些欄位「必須」在建構指紋中替換成其他字元，例如底線 (「_」) 字元。這個欄位的值必須能以 7 位元 ASCII 編碼。
硬體	硬體的名稱 (從核心指令列或 /proc)。產品必須清晰可讀。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9_-]+$」。
主機	用於識別建構建構所在主機的專屬字串，並且採用人類可讀的格式。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
ID	裝置實作人員選擇用來參照特定版本的 ID，採用人類可讀的格式。這個欄位可以與 android.os.Build.VERSION.INCREMENTAL 相同，但值應足以讓使用者區分不同軟體版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
MANUFACTURER	產品的原始設備製造商 (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。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
SECURITY_PATCH	表示版本安全性修補程式等級的值。「必須」表示該版本沒有任何安全漏洞，可影響到指定 Android 公開安全性公告所述的任何問題。請採用 [YYYY-MM-DD] 的格式，與 Android 公開安全性公告或 Android 安全性補充公告中所記錄的字串相符，例如「2015-11-01」。
BASE_OS	此值代表版本 (FINGERPRINT) 的 FINGERPRINT 參數，與此版本相同 (Android 公開安全性公告提供的修補程式除外)。它必須回報正確的值，如果這類版本不存在，請回報空字串 (")。
BOOTLOADER	裝置實作者選擇的值，以人類可讀的格式，識別裝置中使用的特定內部系統啟動載入程式版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
getRadioVersion()	必須 (也就是或傳回) 由裝置實作者選擇的值，用來識別裝置中使用的特定內部無線電/數據機版本，且格式必須是人類可讀的格式。如果裝置沒有任何內部無線電/模組，就「必須」傳回 NULL。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。

3.2.3. 意圖相容性

3.2.3.1。核心應用程式意圖

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

• [C-0-1] 實作裝置時，「必須」針對下列 Android 開放原始碼計畫的核心 Android 應用程式所定義的所有公開意圖篩選器模式，加入這些應用程式、服務元件或處理常式：

  • 桌面時鐘
  • 瀏覽器
  • 日曆
  • 聯絡人
  • 圖庫
  • GlobalSearch
  • 啟動器
  • 音樂
  • 設定

3.2.3.2。意圖解決方案

• [C-0-1] 由於 Android 是可擴充平台，裝置實作「必須」允許第三方應用程式覆寫第 3.2.3.1 節所列的每個意圖模式。上游 Android 開放原始碼實作預設允許執行這項操作。

• [C-0-2] Dvice 實作者「不得」將特殊權限附加至系統應用程式使用這些意圖模式，或避免第三方應用程式繫結和假設這些模式。這項禁令包括但不限於停用「選擇工具」使用者介面，讓使用者在處理相同意圖模式的多個應用程式之間選取所需項目。

• [C-0-3] 裝置實作「必須」提供使用者介面，讓使用者修改意圖的預設活動。

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

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

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

3.2.3.3. 意圖命名空間

• [C-0-1] 裝置實作「不得」含有任何採用 ACTION、CATEGORY 或 Android 命名空間中 ACTION、CATEGORY 或其他金鑰字串的 Android 元件，並遵循任何新意圖或廣播意圖模式。
• [C-0-2] 裝置實作者「不得」納入任何採用 ACTION、CATEGORY 或其他金鑰字串的 Android 元件，而這些元件要在屬於其他機構的套件空間中，遵循任何新意圖或廣播意圖模式。
• [C-0-3] 裝置實作者「不得」修改或擴充第 3.2.3.1 節所列的核心應用程式所使用的任何意圖模式。
• 裝置實作方式可能包括使用明顯與自身機構相關聯之命名空間的意圖模式。這項禁令與第 3.6 節中 Java 語言類別所述的類似。

3.2.3.4。廣播意圖

第三方應用程式仰賴這個平台來廣播特定意圖，以通知硬體或軟體環境的變更。

裝置實作方式：

• [C-0-1] 必須如 SDK 說明文件所述，廣播公開廣播意圖，以回應適當的系統事件。請注意，這項規定與第 3.5 節無關，因為 SDK 說明文件中也有關於背景應用程式的限制。

3.2.3.5。預設應用程式設定

Android 裝置的設定可讓使用者輕鬆選取預設應用程式，例如主畫面或簡訊。

在可行的情況下，裝置實作「必須」提供類似的設定選單，且與以下 SDK 說明文件中所述的意圖篩選器模式和 API 方法相容。

如果裝置導入作業回報 android.software.home_screen，就會：

• [C-1-1] 必須遵循 android.settings.HOME_SETTINGS 意圖，為主畫面顯示預設的應用程式設定選單。

如果裝置導入作業回報 android.hardware.telephony，就會：

• [C-2-1] 「必須」提供設定選單，以便呼叫 android.provider.Telephony.ACTION_CHANGE_DEFAULT 意圖，並顯示用來變更預設簡訊應用程式的對話方塊。

如果裝置導入作業回報 android.hardware.nfc.hce，就會：

• [C-3-1] 必須遵循 android.settings.NFC_PAYMENT_SETTINGS 意圖，顯示感應支付的預設應用程式設定選單。

如果裝置導入作業回報 android.hardware.telephony，就會：

• [C-4-1] 必須遵循 android.telecom.action.CHANGE_DEFAULT_DIALER 意圖，以便顯示對話方塊讓使用者變更預設電話應用程式。

如果裝置實作支援 VoiceInteractionService，就會：

• [C-5-1] 必須遵循 android.settings.ACTION_VOICE_INPUT_SETTINGS 意圖，顯示語音輸入和小幫手的預設應用程式設定選單。

3.2.4。次要螢幕上的活動

如果裝置實作項目允許在次要螢幕上啟動一般的 Android 活動，就會執行以下動作：

• [C-1-1] 必須設定 android.software.activities_on_secondary_displays 功能旗標。
• [C-1-2] 保證 API 相容性與在主要顯示器上執行的活動類似。
• [C-1-3] 在新活動啟動時，必須透過 ActivityOptions.setLaunchDisplayId() API 指定目標顯示畫面，使新活動顯示在啟動活動的螢幕上。
• [C-1-4] 移除具有 Display.FLAG_PRIVATE 旗標的螢幕時，請務必刪除所有活動。
• [C-1-5] 如果螢幕自行調整大小，必須根據 VirtualDisplay 上的所有活動調整大小。
• 當文字輸入欄位聚焦在次要顯示器上時，主要螢幕會顯示輸入法編輯器 (輸入法編輯器，可讓使用者輸入文字)。
• 如果支援觸控或按鍵輸入，則應該在次要螢幕上獨立實作輸入焦點，不受主螢幕影響。
• 應具備對應至該螢幕的 android.content.res.Configuration，以便在次要螢幕上啟動活動時能正確顯示、運作並維持相容性。

如果裝置實作項目允許在次要螢幕和主要/次要螢幕上啟動一般的 Android 活動，就會有不同的 android.util.DisplayMetrics：

• [C-2-1] 次要螢幕「不得」允許無法調整大小的活動 (在 AndroidManifest.xml 中含有 resizeableActivity=false) 和指定 API 級別 23 以下的應用程式。

如果裝置實作項目允許在次要顯示器上啟動一般的 Android 活動，而次要顯示器上含有 android.view.Display.FLAG_PRIVATE 標記：

• [C-3-1] 只有顯示該螢幕、系統和活動的擁有者才能啟動該螢幕。所有人都能在加上 android.view.Display.FLAG_PUBLIC 旗標的螢幕上啟動。

3.3. 原生 API 相容性

原生程式碼相容性不高。因此，裝置實作者有：

• [SR] 強烈建議使用上游 Android 開放原始碼計畫中下列程式庫的實作方式。

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

代管的 Dalvik 位元碼可呼叫應用程式 .apk 檔案中提供的原生程式碼，做為針對適當裝置硬體架構編譯的 ELF .so 檔案。由於原生程式碼高度依賴基礎處理器技術，因此 Android 定義了 Android NDK 中的多個應用程式二進位檔介面 (ABI)。

裝置實作方式：

• [C-0-1] 必須與一或多個定義的 ABI 相容，並實作與 Android NDK 的相容性。
• [C-0-2] 必須支援在受管理的環境中執行的程式碼，使用標準 Java Native Interface (JNI) 語意呼叫原生程式碼。
• [C-0-3] 與下方清單中的每個必要程式庫，都必須與原始碼相容 (即標頭相容) 和二進位檔相容 (適用於 ABI)。
• [C-0-4] 如果支援任何 64 位元 ABI，則必須支援對等的 32 位元 ABI。
• [C-0-5] 請務必透過 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 參數，準確回報裝置支援的原生應用程式二進位檔介面 (ABI)，每個 ABI 的逗號分隔清單，依順序由高到低排序。
• [C-0-6] 必須透過上述參數回報，只有最新版 Android NDK ABI Management 說明文件中記載和描述的 ABI，且「必須」支援進階 SIMD (即 NEON) 擴充功能。

• [C-0-7] 必須讓含有原生程式碼的應用程式使用下列所有程式庫，並提供原生 API：

  • libaaudio.so (支援 AAudio 原生音訊)
  • 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 介面

• [C-0-8] 「不得」新增或移除上述原生資料庫的公用函式。

• [C-0-9] 必須列出 /vendor/etc/public.libraries.txt 中直接向第三方應用程式公開的其他非 Android 開放原始碼計畫程式庫。
• [C-0-10] 請勿向指定 API 級別 24 以上級別的第三方應用程式，向 Android 開放原始碼計畫實作及提供任何其他原生程式庫，做為系統程式庫。
• [C-0-11] 「必須」透過 libGLESv3.so 程式庫匯出 NDK 中定義的所有 OpenGL ES 3.1 和 Android Extension Pack 函式符號。請注意，雖然所有符號都必須完整呈現，但第 7.1.4.1 節將進一步說明預期各項對應函式完整實作的相關規定。
• [C-0-12] 「必須」透過 libvulkan.so 程式庫匯出核心 Vulkan 1.0 函式符號和 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 擴充功能的函式符號。請注意，雖然所有符號都必須完整呈現，但第 7.1.4.2 節將進一步說明預期各項對應函式完整實作的相關規定。
• 應使用上游 Android 開放原始碼計畫提供的原始碼和標頭檔案建立

請注意，日後推出的 Android NDK 版本可能會支援其他 ABI。

3.3.2. 32 位元 ARM 原生程式碼相容性

如果裝置實作項目是 64 位元 ARM 裝置，則：

• [C-1-1] 雖然 ARMv8 架構淘汰了數種 CPU 作業 (包括在現有的原生程式碼中使用的部分運算)，但下列已淘汰的作業仍「必須」可供 32 位元原生 ARM 程式碼 (透過原生 CPU 支援或透過軟體模擬) 使用：

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

如果裝置實作項目包含 32 位元 ARM ABI，就會執行以下動作：

• [C-2-1] 當 32 位元 ARM 應用程式讀取資料時，必須在 /proc/cpuinfo 中加入下列幾行，確保與使用舊版 Android NDK 建構的應用程式相容。

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

• 在 64 位元 ARM 或非 ARM 應用程式讀取時，不應修改 /proc/cpuinfo。

3.4. 網路相容性

3.4.1. WebView 相容性

如果裝置實作項目提供完整的 android.webkit.Webview API 實作，則：

• [C-1-1] 必須回報 android.software.webview。
• [C-1-2] 在 Android 8.0 分支版本中，「必須」使用取自上游 Android 開放原始碼專案的 Chromium 專案版本，實作 android.webkit.WebView API。

• [C-1-3] 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。瀏覽器相容性

如果裝置實作項目包含適用於一般網路瀏覽的獨立瀏覽器應用程式，就會：

• [C-1-1] 「必須」支援下列各個與 HTML5 相關聯的 API：
  • 應用程式快取/離線作業
  • <video> 標記
  • 地理位置
• [C-1-2] 必須支援 HTML5/W3C webstorage API，且必須支援 HTML5/W3C IndexedDB API。請注意，隨著網頁開發標準機構逐漸改用 IndexedDB，而非 webstorage，未來 Android 版本應將 IndexedDB 成為必要的元件。
• 可以在獨立的瀏覽器應用程式中提供自訂的使用者代理程式字串。
• 無論是以上游 WebKit 瀏覽器應用程式，還是第三方替代服務，都應盡可能在獨立的瀏覽器應用程式中導入 HTML5 的支援。

不過，如果裝置的實作沒有提供獨立的瀏覽器應用程式，就會：

• [C-2-1] 仍必須支援第 3.2.3.1 節所述的公開意圖模式。

3.5. API 行為相容性

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

• [C-0-1] 裝置「不得」變更標準意圖的行為或語意。
• [C-0-2] 裝置「不得」變更特定類型的系統元件 (例如 Service、Activity、ContentProvider 等) 的生命週期或生命週期語意。
• [C-0-3] 裝置「不得」變更標準權限的語意。
• 裝置「不得」變更背景應用程式強制執行的限制。具體來說，以下為背景應用程式：
  • [C-0-4] 這些回應必須停止執行由應用程式註冊的回呼，才能接收 GnssMeasurement 和 GnssNavigationMessage 的輸出內容。
  • [C-0-5] 這些 API 必須限制透過 LocationManager API 類別或 WifiManager.startScan() 方法提供應用程式更新的頻率，
  • [C-0-6] 如果應用程式指定的 API 級別為 25 以上，則「不得」允許在應用程式資訊清單中為標準 Android 意圖的隱含廣播註冊廣播接收器，除非廣播意圖需要 "signature"、"signatureOrSystem" protectionLevel 權限，或列於豁免清單。
  • [C-0-7] 如果應用程式指定的 API 級別為 25 以上，就「必須」停止應用程式的背景服務，就像應用程式已呼叫服務的 stopSelf() 方法一樣，除非應用程式加入臨時許可清單來處理使用者可查看的工作。
  • [C-0-8] 如果應用程式指定的 API 級別為 25 以上，就「必須」解除應用程式保留的 Wake Lock。

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

3.6. API 命名空間

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

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

也就是說，他們會：

• [C-0-1] 不得透過變更任何方法或類別簽章，或移除類別或類別欄位，修改 Android 平台上公開發布的 API。
• [C-0-2] 「不得」在上述命名空間的 API 中加入任何公開的元素 (例如類別、介面、欄位或方法)，或是測試或系統 API。「公開公開的元素」是指任何未以「@hide」標記裝飾的結構，就像上游 Android 原始碼中使用的一樣。

裝置實作者可能會修改 API 的基礎實作方式，但這類修改內容如下：

• [C-0-3] 不得影響任何公開 API 所述行為和 Java 語言簽章。
• [C-0-4] 不得宣傳或向開發人員揭露。

不過，裝置實作者可能會在標準 Android 命名空間之外新增自訂 API，但自訂 API：

• [C-0-5] 不得位於其他機構擁有或參照的命名空間。舉例來說，裝置實作者「不得」將 API 加入 com.google.* 或類似的命名空間，只有 Google 可以這麼做。同樣地，Google 也「不得」將 API 加入其他公司的命名空間。
• [C-0-6] 必須封裝在 Android 共用資料庫中，這樣只有明確使用這類 API 的應用程式 (透過 <uses-library> 機制) 才會受到這類 API 的記憶體用量增加的影響。

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

請注意，上述限制符合 Java 程式設計語言中對 API 命名的標準慣例；本節目的只是要加強這些慣例，並透過納入這個相容性定義來加以繫結。

3.7. 執行階段相容性

裝置實作方式：

• [C-0-1] 必須支援完整的 Dalvik Executable (DEX) 格式和 Dalvik 位元碼規格和語意。

• [C-0-2] 必須設定 Dalvik 執行階段，才能根據上游 Android 平台分配記憶體，如下表所示。(如要瞭解螢幕大小和螢幕密度的定義，請參閱第 7.1.1 節)。

• 應使用 Android RunTime (ART)、Dalvik 執行檔格式的上游參考，以及參考實作的套件管理系統。

• 「應」在各種執行模式和目標架構下執行模糊測試，以確保執行階段的穩定性。請參閱 Android 開放原始碼計畫網站上的 JFuzz 和 DexFuzz。

請注意，下列指定的記憶體值視為最小值，而裝置實作可能會為個別應用程式配置更多記憶體。

螢幕版面配置	螢幕密度	應用程式記憶體下限
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 提供啟動器應用程式 (主畫面) 和第三方應用程式支援，可取代裝置啟動器 (主畫面)。

如果裝置的實作方式允許第三方應用程式取代裝置主畫面，請執行以下操作：

• [C-1-1] 必須宣告平台功能 android.software.home_screen。
• [C-1-2] 當第三方應用程式使用 <adaptive-icon> 標記提供圖示時，「必須」傳回 AdaptiveIconDrawable 物件，而系統會呼叫用於擷取圖示的 PackageManager 方法。

如果裝置實作項目包含支援應用程式內捷徑固定的預設啟動器，就會執行以下動作：

• [C-2-1] 必須回報 ShortcutManager.isRequestPinShortcutSupported() 的true。
• [C-2-2] 必須先要求使用者授予權限，才能透過 ShortcutManager.requestPinShortcut() API 方法新增應用程式要求的捷徑。

反之，如果裝置的實作不支援應用程式內固定功能，則可：

• [C-3-1] 必須回報 ShortcutManager.isRequestPinShortcutSupported() 和 AppWidgetManager.html#isRequestPinAppWidgetSupported() 的false。

如果裝置實作項目實作預設啟動器，讓使用者可透過 ShortcutManager API 快速存取第三方應用程式提供的其他捷徑，必須執行以下動作：

• [C-4-1] 必須支援所有記載的捷徑功能 (例如靜態和動態捷徑、固定捷徑)，並完整實作 ShortcutManager API 類別的 API。

如果裝置實作項目包含預設會顯示應用程式圖示徽章的預設啟動器應用程式，則程式碼會：

• [C-5-1] 必須遵循 NotificationChannel.setShowBadge() API 方法。換句話說，如果值設為 true，就顯示與應用程式圖示相關聯的視覺預設用途，而且當應用程式的所有通知管道都設為 false 值時，不會顯示任何應用程式圖示徽章配置。
• 如果第三方應用程式表明支援使用專屬 API 取得專屬徽章配置，但你仍應使用透過 SDK 中所述的通知徽章 API (例如 Notification.Builder.setNumber() 和 Notification.Builder.setBadgeIconType() API) 提供的資源和值，都可以覆寫應用程式圖示徽章。

3.8.2。小工具

Android 支援第三方應用程式小工具，方法是定義元件類型以及對應的 API 和生命週期，讓應用程式向使用者公開「AppWidget」。

如果裝置實作支援第三方應用程式小工具，它們：

• [C-1-1] 必須宣告支援平台功能 android.software.app_widgets。
• [C-1-2] 必須納入 AppWidgets 的內建支援，並公開使用者介面預設用途，以便直接在啟動器中新增、設定、查看及移除 AppWidgets。
• [C-1-3] 必須能夠顯示標準格線大小 4 x 4 的小工具。詳情請參閱 Android SDK 說明文件中的「應用程式小工具設計指南」。
• 可能支援螢幕鎖定畫面上的應用程式小工具。

如果裝置實作支援第三方應用程式小工具和應用程式內捷徑固定功能，您就能執行以下動作：

• [C-2-1] 必須回報 AppWidgetManager.html.isRequestPinAppWidgetSupported() 的true。
• [C-2-2] 必須先要求使用者授予權限，才能透過 AppWidgetManager.requestPinAppWidget() API 方法新增應用程式要求的捷徑。

3.8.3. 通知

Android 提供 Notification 和 NotificationManager API，讓第三方應用程式開發人員能夠通知使用者重要事件，並透過裝置的硬體元件 (例如音效、震動和指示燈) 及軟體功能 (例如通知欄、系統列) 吸引使用者目光。

3.8.3.1。通知呈現方式

如果裝置導入方式允許第三方應用程式通知使用者重要事件，請按照下列步驟操作：

• [C-1-1] 必須支援使用硬體功能的通知，如 SDK 說明文件所述，以及在裝置實作硬體上盡可能支援通知。舉例來說，如果裝置實作方式包含震動功能，「必須」正確實作震動 API。如果裝置實作方式缺少硬體，「必須」將對應的 API 實作為免人工管理。如要進一步瞭解這項行為，請參閱第 7 節。
• [C-1-2] 「必須」正確轉譯 API 或狀態/系統列圖示樣式指南中提供的所有資源 (圖示、動畫檔案等)，但這些資源可以為通知提供替代的使用者體驗，而不是根據 Android 開放原始碼實作方法提供的內容。
• [C-1-3] 必須遵循並妥善實作 API 所述的行為，才能更新、移除及群組通知。
• [C-1-4] 必須提供 SDK 中記錄的 NotificationChannel API 完整行為。
• [C-1-5] 必須為使用者提供權限，以針對每個管道和應用程式套件層級封鎖及修改特定第三方應用程式的通知。
• [C-1-6] 也必須讓使用者負擔能顯示已刪除的通知管道。
• 應支援複合式通知。
• 應以抬頭通知的形式呈現優先順序較高的通知。
• 應讓使用者有足夠的需求來延後通知。
• 「盡量」只管理第三方應用程式何時能通知使用者特定事件的顯示設定和時間，以減少駕駛人分心等安全問題。

如果裝置實作支援複合式通知，就會發生以下狀況：

• [C-2-1] 「必須」針對顯示的資源元素使用 Notification.Style API 類別及其子類別所提供的確切資源。
• 應呈現 Notification.Style API 類別中定義的每個資源元素 (例如圖示、標題和摘要文字)，以及其子類別。

如果裝置實作支援抬頭通知：

• [C-3-1] 顯示抬頭通知時，「必須」使用 Notification.Builder API 類別所述的抬頭通知檢視畫面和資源。

3.8.3.2。通知接聽器服務

Android 包含 NotificationListenerService API，可讓應用程式 (使用者明確啟用後) 在發布或更新時收到所有通知的副本。

裝置實作方式：

• [C-0-1] 必須對所有已安裝和使用者啟用的事件監聽器服務正確迅速地更新整體通知，包括附加至「通知」物件的所有中繼資料。
• [C-0-2] 必須遵循 snoozeNotification() API 呼叫，並關閉通知，並在延後時間 (在 API 呼叫中設定的延後期間) 發出回呼。

如果裝置的實作具有使用者彈性延後通知，就會執行以下動作：

• [C-1-1] 必須使用標準 API (例如 NotificationListenerService.getSnoozedNotifications()) 正確反映延後通知的狀態。
• [C-1-2] 「必須」授予使用者權限，讓他們能從每個已安裝的第三方應用程式中延後通知 (除非應用程式來源是永久/前景服務)。

3.8.3.3。DND (請勿打擾)

如果裝置實作支援 DND 功能，就會：

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

3.8.4。搜尋

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

• Android 裝置實作「必須」提供全域搜尋，以及整個系統通用的搜尋使用者介面，可根據使用者輸入內容提供即時建議。

如果裝置實作項目實作全域搜尋介面，就會執行以下動作：

• [C-1-1] 「必須」實作 API，讓第三方應用程式在全域搜尋模式中執行時，在搜尋框中添加建議。

如果沒有安裝使用全域搜尋功能的第三方應用程式：

• 預設行為應顯示網頁搜尋引擎的結果和建議。

Android 也包含 Assist API，可讓應用程式選擇與裝置助理分享多少目前背景資訊的資訊。

如果裝置導入方式支援輔助動作，就會：

• [C-2-1] 透過下列任一方式分享背景資訊時，必須向使用者明確指出：
  • 每次輔助應用程式存取內容時，在螢幕邊緣周圍顯示白色燈號，且指示燈符合或超過 Android 開放原始碼計畫實作作業的時間長度和亮度。
  • 針對預先安裝的小幫手應用程式，讓使用者能夠從預設語音輸入和 Google 助理應用程式設定選單中選擇較少的導覽操作，且只有在使用者透過啟動字詞或輔助操作鍵輸入內容明確叫用小幫手應用程式時，才提供背景資訊。
• [C-2-2] 指定互動用來啟動輔助應用程式 (如第 7.2.3 節所述) 「必須」啟動使用者選擇的輔助應用程式，也就是實作 VoiceInteractionService 或處理 ACTION_ASSIST 意圖的活動。
• [C-SR] 強烈建議使用長按HOME鍵作為這項指定互動功能。

3.8.5。快訊與浮動式訊息

應用程式可以使用 Toast API，向使用者顯示在短時間內消失的簡短非強制化字串，並使用 TYPE_APPLICATION_OVERLAY 視窗類型 API，將快訊視窗以重疊方式顯示在其他應用程式上方。

如果裝置實作項目包含畫面或影片輸出內容，就會：

• [C-1-1] 「必須」提供使用者權限，禁止應用程式顯示使用 TYPE_APPLICATION_OVERLAY 的快訊視窗。Android 開放原始碼計畫實作項目在通知欄中提供控制項，以符合這項規定。

• [C-1-2] 必須遵循 Toast API，並以顯眼的方式向使用者顯示應用程式浮動式訊息。

3.8.6。主題

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

Android 提供「Holo」和「Material」主題系列做為一組定義的樣式，可讓應用程式開發人員在希望符合 Android SDK 定義的 Holo 主題外觀和風格時使用。

如果裝置實作項目包含畫面或影片輸出內容，就會：

• [C-1-1] 不得變更向應用程式公開的任何 Holo 主題屬性。
• [C-1-2] 必須支援「Material」主題系列，且不得變更任何質感設計主題屬性或向應用程式公開的資產。

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

• 裝置實作方式可能會修改應用程式公開的裝置預設主題屬性。

Android 支援包含半透明系統資訊列的變化版本主題，可讓應用程式開發人員在狀態和導覽列後方顯示應用程式內容。為了讓開發人員在這項設定中享有一致的體驗，在不同裝置實作項目中，必須保留狀態列圖示樣式。

如果裝置導入方式包含系統狀態列，就會：

• [C-2-1] 系統狀態圖示 (例如訊號強度和電池電量) 以及系統發出的通知時，必須使用白色；除非該圖示指出有問題的狀態，或者應用程式使用 SYSTEM_UI_FLAG_LIGHT_STATUS_BAR 標記要求淺色狀態列。
• [C-2-2] 當應用程式要求淺色狀態列時，Android 裝置的實作「必須」將系統狀態圖示的顏色變更為黑色 (詳情請參閱 R.style 一文)。

3.8.7。動態桌布

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

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

• 如上所述，可穩定執行動態桌布的裝置實作應導入動態桌布。

如果裝置實作的是動態桌布，動態桌布會：

• [C-1-1] 必須回報平台功能旗標 android.software.live_wallpaper。

3.8.8。活動切換

上游 Android 原始碼包含總覽畫面，這是用來切換工作的系統層級使用者介面，並利用使用者上次離開應用程式時，應用程式的圖形狀態縮圖，顯示最近存取的活動和工作。

如第 7.2.3 節所述，裝置實作項目包含近期函式瀏覽鍵，並可能變更介面。

如果裝置實作項目包含最近使用函式瀏覽鍵 (如第 7.2.3 節所述) 的變更，就會造成以下情況：

• [C-1-1] 最多只能支援 20 個顯示的活動。
• 一次至少應顯示 4 項活動的標題。
• [C-1-2] 必須導入螢幕固定行為，並提供設定選單讓使用者切換功能。
• 應在近期記錄中顯示醒目顯示顏色、圖示和畫面標題。
• 應顯示關閉的預設用途 (「x」)，但可能要延遲直到使用者與螢幕互動為止。
• 請務必實作捷徑，以便輕鬆切換到先前活動
• 使用者輕觸近期的兩個功能鍵時，應觸發在最近使用的兩個應用程式之間快速切換動作。
• 長按近期函式鍵時，應觸發分割畫面多視窗模式 (如果支援)。

• 可列出相關近期項目為一組活動。

• [C-SR] 極力建議裝置實作方式為總覽畫面使用上游 Android 使用者介面 (或類似的縮圖式介面)。

3.8.9。輸入管理

Android 支援輸入管理功能，並支援第三方輸入法編輯器。

如果裝置實作方式允許使用者在裝置上使用第三方輸入法，就會：

• [C-1-1] 必須宣告平台功能 android.software.input_methods，並支援 Android SDK 說明文件中定義的 IME API。
• [C-1-2] 「必須」提供讓使用者存取的機制，以便新增及設定第三方輸入法，以回應 android.settings.INPUT_METHOD_SETTINGS 意圖。

如果裝置實作方式宣告了 android.software.autofill 功能旗標，就會：

• [C-2-1] 必須完全實作 AutofillService 和 AutofillManager API，並遵循 android.settings.REQUEST_SET_AUTOFILL_SERVICE 意圖來顯示預設的應用程式設定選單，藉此啟用及停用自動填入功能，並變更使用者的預設自動填入服務。

3.8.10。螢幕鎖定媒體控制項

Remote Control Client API 已從 Android 5.0 版淘汰，並改用媒體通知範本，讓媒體應用程式能整合螢幕鎖定畫面上顯示的播放控制項。

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

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

3.8.12。位置

如果裝置實作項目內含能夠提供位置座標的硬體感應器 (例如 GPS)，請按照下列步驟操作：

• [C-1-1] 「設定」的「位置」選單「必須」顯示定位模式。

3.8.13。Unicode 和字型

Android 支援 Unicode 10.0 中定義的表情符號字元。

如果裝置實作項目包含畫面或影片輸出內容，就會：

• [C-1-1] 必須能夠以色彩字符轉譯這些表情符號字元。
• [C-1-2] 必須支援下列項目：
  • Roboto 2 字型的粗細如下：sans-Serif-thin、Sans-Serif-light、Sans-Serif-medium、Sans-Serif-black、Sans-Serif-condensed、Sans-Serif-condensed-light 適用於裝置支援的語言。
  • 完整 Unicode 7.0 涵蓋拉丁、希臘和斯拉夫文，包括拉丁文 A、B、C 和 D 範圍，以及 Unicode 7.0 貨幣符號區塊中的所有字符。
• 應支援 Unicode 技術報告 #51 中指定的膚色和多樣家庭表情符號。

如果裝置實作項目包含輸入法編輯器，則會：

• 針對這些表情符號字元，應為使用者提供輸入法。

3.8.14。多視窗模式

如果裝置實作可同時顯示多個活動，就會：

• [C-1-1] 必須根據 Android SDK 多視窗模式支援說明文件中描述的應用程式行為和 API，實作這類多視窗模式，並符合下列規定：
• [C-1-2] 應用程式可透過明確方式，將 android:resizeableActivity 屬性設為 true 或將 targetSdkVersion > 24 隱含在 AndroidManifest.xml 檔案中，以多視窗模式運作。如果應用程式在資訊清單中明確將這項屬性設為 false，就「不得」在多視窗模式下啟動。如果特定舊版應用程式 targetSdkVersion 小於 24 但未設定此 android:resizeableActivity 屬性，可能可以在多視窗模式下啟動，但系統「必須」提供警告訊息，說明該應用程式在多視窗模式下可能無法正常運作。
• [C-1-3] 如果螢幕高度小於 440 dp，且螢幕寬度小於 440 dp，「不得」提供分割畫面或任意形式模式。
• 螢幕大小為 xlarge 的裝置實作應支援任意形式模式。

如果裝置實作項目支援多視窗模式和分割畫面模式，就會：

• [C-2-1] 必須預先載入可調整大小的啟動器做為預設值。
• [C-2-2] 針對分割畫面多視窗模式，「必須」裁剪的固定活動，但如果啟動器應用程式是焦點視窗，則必須顯示部分內容。
• [C-2-3] 必須遵循第三方啟動器應用程式宣告的 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值，在顯示已插入活動的部分內容時，請勿覆寫這些值。

如果裝置實作項目支援多視窗模式和子母畫面多視窗模式，就會執行以下動作：

• [C-3-1] 當應用程式處於以下狀態時，「必須」在子母畫面多視窗模式下啟動活動：* 指定 API 級別 26 以上，並宣告 android:supportsPictureInPicture * 指定 API 級別 25 以下，並宣告 android:resizeableActivity 和 android:supportsPictureInPicture。
• [C-3-2] 必須按照目前子母畫面透過 setActions() API，在自家 SystemUI 中顯示動作。
• [C-3-3] 必須依照子母畫面設定，透過 setAspectRatio() API 支援大於或等於 1:2.39 且小於或等於 2.39:1 的顯示比例。
• [C-3-4] 必須使用 KeyEvent.KEYCODE_WINDOW 控制子母畫面視窗；如未執行子母畫面模式，該金鑰「必須」可用於前景活動。
• [C-3-5] 「必須」提供使用者權限，禁止應用程式在子母畫面模式下顯示；Android 開放原始碼計畫實作項目可在通知欄中提供控制項，以符合這項規定。
• [C-3-6] 當 Configuration.uiMode 設為 UI_MODE_TYPE_TELEVISION 時，必須將子母畫面視窗的最小寬度和高度分配為 108 dp，而子母畫面視窗的最小寬度 240 dp，高度則為 135 dp

3.9. 裝置管理

Android 提供的功能可讓具備安全性感知的應用程式在系統層級執行裝置管理功能，例如透過 Android Device 管理 API 強制執行密碼政策或執行遠端清除]。

如果裝置實作項目實作 Android SDK 說明文件中定義的完整裝置管理政策，就會執行以下動作：

• [C-1-1] 必須宣告 android.software.device_admin。
• [C-1-2] 必須支援第 3.9.1 節和第 3.9.1.1 節所述的裝置擁有者佈建功能。
• [C-1-3] 「必須」透過 android.software.managed_users 功能旗標宣告支援管理的個人資料，除非裝置經過設定，因此會回報為低 RAM 裝置，或讓系統將內部 (不可移除) 儲存空間分配為共用儲存空間。

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

如果裝置實作項目宣告 android.software.device_admin，就會：

• [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為裝置擁有者應用程式，方法如下：
  • 如果裝置實作尚未設定使用者資料，系統會：
    • [C-1-3] 必須回報 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 的true。
    • [C-1-4] 為回應意圖動作 android.app.action.PROVISION_MANAGED_DEVICE，請務必註冊 DPC 應用程式做為裝置擁有者應用程式。
    • [C-1-5] 如果裝置透過功能旗標 android.hardware.nfc 宣告近距離無線通訊 (NFC) 支援，且收到包含 MIME 類型 MIME_TYPE_PROVISIONING_NFC 記錄的 NFC 訊息，就「必須」將 DPC 應用程式註冊為「裝置擁有者」應用程式。
  • 如果裝置實作方式包含使用者資料，就會：
    • [C-1-6] 必須回報 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 的 false。
    • [C-1-7] 不得再註冊任何 DPC 應用程式，做為裝置擁有者應用程式。
• [C-1-2] 未經使用者或裝置管理員明確同意或操作，「不得」將應用程式 (包括預先安裝的應用程式) 設為裝置擁有者應用程式。

如果裝置實作方式宣告 android.software.device_admin，但同時包含專屬的裝置擁有者管理解決方案，並提供機制，可根據標準 Android DevicePolicyManager API 認可的標準「裝置擁有者」來宣傳已在解決方案中設定的應用程式，則：

• [C-2-1] 必須設有專門程序，用於驗證目前宣傳的應用程式屬於合法企業裝置管理解決方案，且專屬解決方案已協助設定等同於「裝置擁有者」的權利。
• [C-2-2] 註冊 DPC 應用程式前，必須根據 android.app.action.PROVISION_MANAGED_DEVICE 發起的流程，顯示相同的 Android 開放原始碼計畫裝置擁有者同意聲明揭露聲明，才能註冊為「裝置擁有者」。
• 以「裝置擁有者」註冊 DPC 應用程式之前，裝置上可能已有使用者資料。

3.9.1.2 受管理設定檔佈建

如果裝置實作項目宣告 android.software.managed_users，就會：

• [C-1-1] 必須實作允許裝置政策控制器 (DPC) 應用程式的 API，成為新受管理設定檔的擁有者。

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

• [C-1-3] 「設定」中「必須」在「設定」中提供下列使用者權限，以便在裝置政策控制器 (DPC) 停用特定系統功能時向使用者顯示：

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

3.9.2 支援受管理設定檔

如果裝置實作項目宣告 android.software.managed_users，就會：

• [C-1-1] 必須支援透過 android.app.admin.DevicePolicyManager API 受管理的設定檔。
• [C-1-2] 只能建立一個受管理的設定檔。
• [C-1-3] 必須使用圖示徽章 (類似 Android 開放原始碼計畫上游工作徽章) 代表受管理的應用程式、小工具，以及其他標記的 UI 元素，例如近期和通知。
• [C-1-4] 必須顯示通知圖示 (類似 Android 開放原始碼計畫上游工作徽章)，表示使用者位於受管理的設定檔應用程式中。
• [C-1-5] 必須顯示浮動式訊息，指出裝置處於喚醒和喚醒狀態 (ACTION_USER_PRESENT) 且前景應用程式位於受管理的設定檔中。
• [C-1-6] 如有受管理的設定檔，「必須」在意圖的「選擇工具」中顯示視覺預設用途，讓使用者可以將受管理設定檔的意圖轉送至主要使用者，反之亦然 (如果裝置政策控制器已啟用)。
• [C-1-7] 如果有受管理的設定檔，「必須」針對主要使用者和受管理的設定檔提供下列使用者權限：
  • 將主要使用者和受管理設定檔的電池、位置、行動數據和儲存空間用量分開計算。
  • 獨立管理安裝在主要使用者或受管理設定檔中的 VPN 應用程式。
  • 獨立管理主要使用者或受管理設定檔中安裝的應用程式。
  • 獨立管理主要使用者或受管理設定檔中的帳戶。
• [C-1-8]「必須」確保預先安裝的撥號程式、聯絡人和訊息應用程式可以在受管理的設定檔 (如果有的話) 中搜尋及查詢來電者資訊 (如有)。
• [C-1-9] 即使受管理的設定檔並未計入主要使用者，仍必須符合所有適用於多位使用者的裝置的安全性規定 (請參閱第 9.5 節)。
• [C-1-10] 必須能夠指定獨立的螢幕鎖定畫面，並符合下列規定，才能授予受管理設定檔執行的應用程式存取權。
  • 裝置實作方式「必須」遵循 DevicePolicyManager.ACTION_SET_NEW_PASSWORD 意圖，並顯示用來為受管理的設定檔設定獨立螢幕鎖定憑證的介面。
  • 受管理設定檔的螢幕鎖定憑證「必須」使用與上層設定檔相同的憑證儲存空間和管理機制 (如 Android 開放原始碼計畫網站所述)
  • DPC 密碼政策「必須」僅適用於受管理設定檔的螢幕鎖定憑證，除非 getParentProfileInstance 傳回的 DevicePolicyManager 例項進行呼叫。
• 如果受管理設定檔的聯絡人顯示在預先安裝的通話記錄、通話使用者介面、進行中和未接來電通知、聯絡人和訊息應用程式上，就必須標有代表受管理設定檔應用程式的徽章。

3.10. 無障礙功能

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

如果裝置實作項目支援第三方無障礙服務，就會：

• [C-1-1] 必須按照 Accessibility API SDK 說明文件中的指示，實作 Android 無障礙架構。
• [C-1-2] 必須產生無障礙事件，並依 SDK 中記錄，向所有已註冊的 AccessibilityService 實作提供適當的 AccessibilityEvent。
• [C-1-3] 必須遵循 android.settings.ACCESSIBILITY_SETTINGS 意圖，才能提供使用者存取機制，以在預先載入的無障礙服務旁啟用及停用第三方無障礙服務。
• [C-1-4] 請在系統的導覽列中加入按鈕，讓使用者在已啟用的無障礙服務宣告 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 時，能夠控制無障礙服務。請注意，如果是沒有系統導覽列的裝置實作，則不適用這項規定，但裝置實作應提供使用者負擔控管這些無障礙服務的權利。

如果裝置實作項目包含預先載入的無障礙服務，就會：

• [C-2-1] 當資料儲存空間是以檔案式加密 (FBE) 加密時，「必須」將這些預先載入的無障礙服務實作為直接啟動感知應用程式。
• 使用者應在開箱的設定流程中，提供一種機制，讓使用者啟用相關無障礙服務，以及調整字型大小、顯示大小和放大手勢的選項。

3.11. Text-to-Speech

Android 中的 API 可讓應用程式使用文字轉語音 (TTS) 服務，並允許服務供應商實作 TTS 服務。

如果裝置實作回報 android.hardware.audio.output 功能，請注意下列事項：

• [C-1-1] 必須支援 Android TTS 架構 API。

如果裝置的導入方式支援安裝第三方 TTS 引擎，請按照下列步驟操作：

• [C-2-1] 必須提供使用者優先度，讓使用者能在系統層級選取要使用的 TTS 引擎。

3.12. 電視輸入架構

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

如果裝置實作支援 TIF，就會執行以下動作：

• [C-1-1] 必須宣告平台功能 android.software.live_tv。
• [C-1-2] 必須預先載入 TV 應用程式 (TV 應用程式)，並符合第 3.12.1 節所述的所有規定。

3.12.1。TV 應用程式

如果裝置實作支援 TIF：

• [C-1-1] TV 應用程式「必須」提供安裝及使用電視頻道所需的設施，並符合下列規定。

Android 裝置實作方式宣告 android.software.live_tv 功能標記所需的 TV 應用程式，必須符合下列規定：

• 裝置導入「必須」允許安裝及管理第三方 TIF 輸入資料 (第三方輸入內容)。
• 裝置的實作方式「可能」針對預先安裝的 TIF 型輸入資料 (已安裝的輸入內容) 和第三方輸入內容提供視覺區隔。
• 裝置導入作業「不應」除了單一導覽動作外，在 TV 應用程式中顯示第三方輸入來源 (例如從 TV 應用程式展開第三方輸入來源清單)。

Android 開放原始碼計畫提供符合上述需求的 TV 應用程式實作方式。

3.12.1.1。電子節目計畫指南

如果裝置實作支援 TIF，就會執行以下動作：

• [C-1-1] 必須顯示資訊及互動式重疊元素，「必須」加入根據 TvContract.Programs 欄位值產生的電子節目指南 (EPG)。
• [C-1-2] 變更版本時，裝置的實作「必須」顯示目前播放節目的 EPG 資料。
• [SR] 極力建議使用電子節目表，以同樣顯眼的方式顯示已安裝的輸入內容和第三方輸入內容。電子節目表中的安裝輸入端「不應」除了單一導覽動作之外，再顯示第三方輸入內容。
• EPG 應顯示所有已安裝的輸入項目和第三方輸入端的資訊。
• EPG 可能會提供視覺區隔，說明已安裝的輸入端與第三方輸入端。

3.12.1.2。導覽

如果裝置實作支援 TIF，就會執行以下動作：

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

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

• 應透過 CEC 將重要事件傳送至 HDMI 輸入端。

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

如果裝置實作支援 TIF：

• [C-1-1] Android 電視裝置實作項目「必須」支援電視輸入應用程式連結，讓所有輸入資料都能將目前活動的活動連結提供給其他活動 (例如從直播節目連結至相關內容的連結)。
• [C-1-2] TV 應用程式「必須」顯示提供電視輸入應用程式的連結。

3.12.1.4。時光平移

如果裝置實作支援 TIF，就會執行以下動作：

• [SR] 強烈建議使用者支援時間轉移功能，這項功能可讓使用者暫停和繼續播放直播內容。
• 如果該節目可使用時間轉移，應讓使用者能夠暫停並繼續播放節目。

3.12.1.5。電視錄製

如果裝置實作支援 TIF，就會執行以下動作：

• [SR] 強烈建議你支援電視錄製功能。
• 應提供使用者介面，以便播放錄製的節目。
• 如果電視輸入來源支援錄製功能，且未禁止錄製節目，電子節目表可能會提供錄製節目的方法。

3.13. 快速設定

Android 提供快速設定 UI 元件，可讓您快速存取常用或迫切需要的動作。

如果裝置實作項目包含快速設定 UI 元件，就會：

• [C-1-1] 必須允許使用者在第三方應用程式中新增或移除透過 quicksettings API 提供的資訊方塊。
• [C-1-2] 「不得」自動將第三方應用程式的資訊方塊新增至快速設定。
• [C-1-3] 必須一併顯示使用者透過第三方應用程式新增的所有資訊方塊，以及系統提供的快速設定方塊。

3.14。媒體使用者介面

如果裝置實作項目包含支援使用 MediaBrowser 和 MediaSession 第三方應用程式的 UI 架構，就必須：

• [C-1-1] 必須原封不動顯示 MediaItem 圖示和通知圖示。
• [C-1-2] 必須按照 MediaSession 的說明顯示這些項目，例如中繼資料、圖示、圖像。
• [C-1-3] 必須顯示應用程式名稱。
• [C-1-4] 必須設有導覽匣，才能顯示 MediaBrowser 階層。

3.15. 免安裝應用程式

裝置實作方式必須符合下列規定：

• [C-0-1] 免安裝應用程式只能取得將 android:protectionLevel 設為 "ephemeral" 的權限。
• [C-0-2] 除非符合下列任一條件，否則免安裝應用程式「不得」透過隱含意圖與已安裝的應用程式互動：
  • 此元件的意圖模式篩選器已公開，且具有 CATEGORY_BROWSABLE
  • 這個動作可以是下列其中之一：ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE
  • 系統會透過 android:visibleToInstantApps 明確公開目標
• [C-0-3] 免安裝應用程式「不得」與已安裝的應用程式明確互動，除非該元件是透過 android:visibleToInstantApps 公開發布。
• [C-0-4] 除非免安裝應用程式明確連線至已安裝的應用程式，否則已安裝的應用程式「不得」在裝置上查看免安裝應用程式的詳細資料。

3.16. 配對裝置配對

Android 支援配對裝置配對功能，可更有效地管理與配對裝置的關聯，並為應用程式提供 CompanionDeviceManager API，以便使用這項功能。

如果裝置實作項目支援隨附裝置配對功能，就會：

• [C-1-1] 必須宣告功能標記 FEATURE_COMPANION_DEVICE_SETUP。
• [C-1-2] 必須確保 android.companion 套件中的 API 已完全實作。
• [C-1-3] 必須為使用者提供預設空間，讓使用者選取/確認隨附裝置運作正常，並可正常使用。

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

裝置實作方式：

• [C-0-1] 必須能夠安裝及執行 Android 官方 Android SDK 中「aapt」工具所產生的 Android「.apk」檔案。
• 由於上述規定可能具有挑戰性，因此建議裝置的實作方式，使用 Android 開放原始碼計畫參考資料實作項目的套件管理系統裝置。
• [C-0-2] 必須支援使用 APK 簽署配置 v2 和 JAR 簽署驗證「.apk」檔案。
• [C-0-3] 請勿以妨礙其他相容裝置安裝及執行檔案的方式，擴充 .apk、Android 資訊清單、Dalvik 位元碼或 RenderScript 位元碼格式。

• [C-0-4] 套件「不得」允許安裝套件目前的「記錄安裝程式」以外的應用程式，在不顯示任何提示的情況下直接解除安裝應用程式 (如 DELETE_PACKAGE 權限的 SDK 所述)。唯一的例外是處理 PACKAGE_NEEDS_VERIFICATION 意圖的系統套件驗證器應用程式，以及處理 ACTION_MANAGE_STORAGE 意圖的儲存空間管理工具應用程式。

• [C-0-5] 必須包含處理 android.settings.MANAGE_UNKNOWN_APP_SOURCES 意圖的活動。

• [C-0-6] 「不得」安裝不明來源的應用程式套件，除非要求安裝的應用程式符合下列所有規定：

  • 它必須宣告 REQUEST_INSTALL_PACKAGES 權限，或將 android:targetSdkVersion 設為 24 以下。
  • 「必須」已取得使用者授權，才能從不明來源安裝應用程式。

• 「應該」應為使用者提供授權，讓他們為每個應用程式授予/撤銷不明來源安裝應用程式的權限，但如果裝置的實作不允許使用者選擇此選項，則「可以」選擇以免人工管理的方式導入 RESULT_CANCELED，為 startActivityForResult() 傳回 RESULT_CANCELED。但即使如此，他們也應該向使用者說明沒有這類選擇的原因。

5. 多媒體相容性

裝置實作方式：

• [C-0-1] 對於 MediaCodecList 宣告的每個轉碼器，都必須支援第 5.1 節定義的媒體格式、編碼器、解碼器、檔案類型和容器格式。
• [C-0-2] 必須透過 MediaCodecList 宣告及回報對第三方應用程式和解碼器的支援。
• [C-0-3] 必須能夠解碼，並提供給第三方應用程式使用所有可編碼的格式。包括編碼器產生的所有位元串流，以及 CamcorderProfile 中回報的設定檔。

裝置實作方式：

• 應盡量縮短轉碼器延遲時間，換句話說，就是
  • 請勿消耗及儲存輸入緩衝區，且僅會在處理後傳回輸入緩衝區。
  • 請勿保留超過標準 (例如 SPS) 所指定時間的已解碼緩衝區。
  • 「不得」保留超過 GOP 結構所需的編碼緩衝區。

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

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

5.1. 媒體轉碼器

5.1.1. 音訊編碼

詳情請參閱 5.1.3. 音訊轉碼器詳細資料。

如果裝置導入方式宣告 android.hardware.microphone，則必須支援下列音訊編碼：

• [C-1-1] PCM/WAVE

5.1.2. 音訊解碼

詳情請參閱 5.1.3. 音訊轉碼器詳細資料。

如果裝置實作項目宣告支援 android.hardware.audio.output 功能，就必須支援下列音訊解碼器：

• [C-1-1] MPEG-4 AAC 設定檔 (AAC LC)
• [C-1-2] MPEG-4 HE AAC 設定檔 (AAC+)
• [C-1-3] MPEG-4 HE AACv2 設定檔 (強化 AAC+)
• [C-1-4] AAC ELD (強化型低延遲 AAC)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

如果裝置實作支援透過 android.media.MediaCodec API 中的預設 AAC 音訊解碼器，將多頻道串流 (意即超過兩個頻道) 的 AAC 輸入緩衝區解碼至 PCM，「必須」支援以下項目：

• [C-2-1] 必須「必須」在不下移的情況下執行解碼 (例如 5.0 AAC 串流必須解碼為 5 個 PCM 管道，而 5.1 AAC 串流必須解碼為 PCM 的六個管道)。
• [C-2-2] 動態範圍中繼資料必須符合 ISO/IEC 14496-3 的「動態範圍控制 (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_CODED_

5.1.3. 音訊轉碼器詳細資料

格式/轉碼器	詳細資料	支援的檔案類型/容器格式
MPEG-4 AAC 設定檔 (AAC LC)	支援採用標準取樣率介於 8 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。	3GPP (.3gp) MPEG-4 (.mp4、.m4a) ADTS 原始 AAC (.aac、ADIF) MPEG-TS (.ts，無法搜尋)
MPEG-4 HE AAC 設定檔 (AAC+)	支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。
MPEG-4 HE AACv2 設定檔 (增強 AAC+)	支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。
AAC ELD (強化低延遲 AAC)	支援標準取樣率介於 16 至 48 kHz 的單聲道/立體聲內容。
AMR-NB	4.75 到 12.2 kbps 取樣 @ 8 kHz	3GPP (.3gp)
AMR-WB	9 速率介於每秒 6.60 kbit 到 23.85 kbit/s @ 16 kHz
FLAC	單聲道/立體聲 (無多頻道)。取樣率最高為 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)
Vorbis		Ogg (.ogg) Matroska (.mkv，Android 4.0 以上版本)
PCM/WAVE	16 位元線性 PCM (速率上限為硬體)。裝置必須支援 8000、11025、16000 和 44100 Hz 頻率的原始 PCM 錄製取樣率。	WAVE (.wav)
Opus		Matroska (.mkv)、Ogg(.ogg)

5.1.4。圖片編碼

詳情請參閱 5.1.6. 圖片轉碼器詳細資料。

裝置導入方式「必須」支援下列圖片編碼編碼：

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

5.1.5。圖片解碼

詳情請參閱 5.1.6. 圖片轉碼器詳細資料。

裝置實作「必須」支援將下列圖片解碼功能編碼：

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] 原始

5.1.6. 圖片轉碼器詳細資料

格式/轉碼器	詳細資料	支援的檔案類型/容器格式
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.7. 影片轉碼器

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

如果裝置實作包含影片解碼器或編碼器：

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

• [C-1-2] 影片編碼器和解碼器必須支援 YUV420 彈性顏色格式 (COLOR_FormatYUV420 彈性)

如果裝置實作方式是透過 Display.HdrCapabilities 通告 HDR 設定檔支援，就會：

• [C-2-1] 必須支援 HDR 靜態中繼資料剖析及處理功能。

如果裝置導入方式透過 MediaCodecInfo.CodecCapabilities 類別中的 FEATURE_IntraRefresh，宣傳內部重新整理支援，就會執行以下動作：

• [C-3-1]重新整理時，必須在 10 到 60 個影格的範圍內，並在設定的重新整理週期的 20% 內準確運作。

5.1.8。影片轉碼器清單

格式/轉碼器	詳細資料	支援的檔案類型/ 容器格式
H.263		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	詳情請參閱第 5.2 節和第 5.3 節。	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (僅限 .ts、僅限 AAC 音訊，無法搜尋、Android 3.0 以上版本)
H.265 HEVC	詳情請參閱第 5.3 節。	MPEG-4 (.mp4)
MPEG-2	主要個人資料	MPEG2-TS
MPEG-4 SP		3GPP (.3gp)
VP8	詳情請參閱第 5.2 節和第 5.3 節。	WebM (.webm) 馬特羅斯卡 (.mkv)
VP9	詳情請參閱第 5.3 節。	WebM (.webm) 馬特羅斯卡 (.mkv)

5.2. 影片編碼

如果裝置導入方式支援任何影片編碼器，並將其提供給第三方應用程式，就會：

• 「不應」：超過兩個滑動窗，與內部頁框 (I 影格) 間隔的位元率相比超過約 15%。
• 和滑動窗口的位元率不應超過約 100%。

如果裝置實作項目具有長度至少 2.5 吋的內嵌螢幕、含有影片輸出連接埠，或透過 android.hardware.camera.any 功能旗標宣告支援相機，那麼裝置程式碼如下：

• [C-1-1] 必須包含至少一種 VP8 或 H.264 視訊編碼器的支援，且可供第三方應用程式使用。
• 應同時支援 VP8 和 H.264 視訊編碼器，且可供第三方應用程式使用。

如果裝置實作支援任何 H.264、VP8、VP9 或 HEVC 視訊編碼器，並提供給第三方應用程式使用，就會：

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

如果裝置實作支援 MPEG-4 SP 影片編碼器，並提供給第三方應用程式使用，它們：

• 應支援為支援的編碼器動態設定位元率。

5.2.1。H.263

如果裝置實作項目支援 H.263 編碼器，並且提供給第三方應用程式使用，它們會：

• [C-1-1] 必須支援基準設定檔級別 45。
• 應支援為支援的編碼器動態設定位元率。

5.2.2。H-264

如果裝置的實作支援 H.264 轉碼器，就會：

• [C-1-1] 必須支援基準設定檔第 3 級。不過，我們會針對 ASO (任意配量順序)、FMO (彈性巨集排序) 和 RS (多餘配量) 提供支援。此外，為了維持與其他 Android 裝置的相容性，我們建議編碼器不會將 ASO、FMO 和 RS 用於基準設定檔。
• [C-1-2] 必須支援下表中的 SD (標準畫質) 影片編碼設定檔。
• 應支援第 4 級主要設定檔。
• 應支援 HD (高畫質) 影片編碼設定檔，如下表所示。

如果裝置實作回報透過媒體 API 提供 720p 或 1080p 解析度影片的 H.264 編碼支援，就會：

• [C-2-1] 必須支援下表中的編碼設定檔。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 720p	HD 高畫質 1080p
影片解析度	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	20 fps	30 fps	30 fps	30 fps
影片位元率	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

如果裝置導入方式支援 VP8 轉碼器，就會：

• [C-1-1] 必須支援 SD 影片編碼設定檔。
• 應支援下列 HD (高畫質) 影片編碼設定檔。
• 應支援編寫 Matroska WebM 檔案。
• 應使用符合 WebM 專案 RTC 硬體編碼規定的硬體 VP8 轉碼器，以確保網路影片串流和視訊會議服務的品質符合標準。

如果裝置導入方式回報支援透過媒體 API 針對 720p 或 1080p 解析度影片的 VP8 編碼，就會：

• [C-2-1] 必須支援下表中的編碼設定檔。

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

5.2.4。VP9

如果裝置實作支援 VP9 轉碼器，就會：

• 應支援編寫 Matroska WebM 檔案。

5.3. 影片解碼

如果裝置實作支援 VP8、VP9、H.264 或 H.265 轉碼器，則代碼如下：

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

如果裝置實作程序透過 HDR_TYPE_DOLBY_VISION 宣告支援 Dolby Vision 解碼器，就會發生以下情形：

• [C-2-1] 必須提供支援 Dolby Vision 的擷取器。
• [C-2-2] 必須在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。
• [C-2-3] 必須將回溯相容基礎層 (如有) 的軌跡索引設為與 Dolby Vision 圖層合併後追蹤索引相同的。

5.3.1。MPEG-2

如果裝置實作支援 MPEG-2 解碼器，就會：

• [C-1-1] 必須支援主要設定檔高階裝置。

5.3.2。H.263

如果裝置實作支援 H.263 解碼器，就會：

• [C-1-1] 必須支援基準設定檔第 30 級和第 45 級。

5.3.3. MPEG-4

如果裝置實作使用 MPEG-4 解碼器，它們：

• [C-1-1] 必須支援簡易設定檔層級 3。

5.3.4。H.264

如果裝置實作支援 H.264 解碼器，就會：

• [C-1-1] 必須支援主要設定檔層級 3.1 和基準設定檔。您可以選擇支援 ASO (任意配量排序)、FMO (彈性巨集排序) 和 RS (多餘配量)。
• [C-1-2] 必須能使用下表所列的 SD (標準畫質) 設定檔解碼影片，並使用基準設定檔和主要設定檔層級 3.1 (包括 720p30) 編碼。
• 「應該」能使用 HD (高畫質) 設定檔來解碼影片，如下表所示。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則裝置實作方式：

• [C-2-1] 必須支援下表中的 HD 720p 影片解碼設定檔。
• [C-2-2] 必須支援下表中的 HD 1080p 影片解碼設定檔。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 720p	HD 高畫質 1080p
影片解析度	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	30 fps	30 fps	60 fps	30 fps (60 fps^電視)
影片位元率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5。H.265 (HEVC)

如果裝置實作支援 H.265 轉碼器，就會：

• [C-1-1] 必須支援第 3 級主要層級和 SD 影片解碼設定檔，如下表所示。
• 「應」支援 HD 高畫質解碼設定檔，如下表所示。
• [C-1-2] 使用硬體解碼器時，「必須」支援下表所示的 HD 高畫質解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則：

• [C-2-1] 裝置實作項目至少須支援 H.265、720、1080 和 UHD 超高畫質設定檔的 H.265 編碼或 VP9 解碼檔。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 720p	HD 高畫質 1080p	UHD 超高畫質
影片解析度	352 x 288 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片畫面更新率	30 fps	30 fps	30 fps	30/60 fps (60 fps^搭配 H.265 硬體解碼的電視)	60 fps
影片位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3.6。VP8

如果裝置導入方式支援 VP8 轉碼器，就會：

• [C-1-1] 「必須」支援下表中的 SD 解碼設定檔。
• 請務必使用符合規定的硬體 VP8 轉碼器。
• 應支援下表中的 HD 高畫質解碼設定檔。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，請執行以下操作：

• [C-2-1] 裝置實作項目「必須」支援下表中的 720p 設定檔。
• [C-2-2] 裝置實作項目「必須」支援下表中的 1080p 設定檔。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 720p	HD 高畫質 1080p
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素
影片畫面更新率	30 fps	30 fps	30 fps (60 fps^電視)	30 (60 fps^電視)
影片位元率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7。VP9

如果裝置實作支援 VP9 轉碼器，就會：

• [C-1-1]「必須」支援 SD 影片解碼設定檔，如下表所示。
• 「應」支援 HD 高畫質解碼設定檔，如下表所示。

如果裝置實作支援 VP9 轉碼器和硬體解碼器：

• [C-2-1] 「必須」支援 HD 高畫質解碼設定檔，如下表所示。

如果 Display.getSupportedModes() 方法回報的高度等於或大於影片解析度，則：

• [C-3-1] 裝置實作項目至少須支援 720、1080 和 UHD 超高畫質設定檔解碼的 VP9 或 H.265 檔案。

	SD 標準畫質 (低品質)	SD 標準畫質 (高畫質)	HD 高畫質 720p	HD 高畫質 1080p	UHD 超高畫質
影片解析度	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
影片畫面更新率	30 fps	30 fps	30 fps	30 fps (60 fps，^採用 VP9 硬體解碼的電視)	60 fps
影片位元率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.4. 錄音

雖然本節所列的部分規定已列為自 Android 4.3 起的「應有的元件」，我們計劃將日後版本的相容性定義變更為「必須」。無論是現有還是新的 Android 裝置，都強烈建議符合「應」列出的這些條件，否則日後升級至新版本時，就無法達到 Android 相容性。

5.4.1。原始音訊擷取

如果裝置實作項目宣告 android.hardware.microphone，就會：

• [C-1-1] 必須允許擷取符合下列規定的原始音訊內容：

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

• [C-1-2] 必須以上述取樣率擷取，不要向上取樣。

• [C-1-3] 如果以低取樣率擷取上述取樣率，請務必加入適當的反鋸齒篩選器。

• 應允許 AM 無線電和 DVD 品質擷取原始音訊內容，這意味著下列特性：

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

如果裝置實作允許 AM 無線電和 DVD 品質擷取原始音訊內容，則：

• [C-2-1] 必須一律以高於 16000:22050 或 44100:48000 的任何比例進行拍攝，不要向上取樣。
• [C-2-2] 在任何向上取樣或降低取樣時，都必須加入適當的反鋸齒篩選器。

5.4.2。擷取以進行語音辨識

如果裝置實作項目宣告 android.hardware.microphone，就會：

• [C-1-1] 必須以 44100 和 48000 的取樣率擷取 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音訊來源。
• [C-1-2] 從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，「必須」預設停用所有雜訊抑制音訊處理作業。
• [C-1-3] 從 AudioSource.VOICE_RECOGNITION 音訊來源錄製音訊串流時，必須預設停用所有自動增益控制項。
• 錄製語音辨識音訊時，應以大約平坦的振幅與頻率特性 (特別是 ±3 dB、從 100 Hz 至 4000 Hz) 錄製。
• 請使用輸入敏感度集錄製語音辨識音訊串流，讓 1000 Hz 的 90 dB 聲音功率 (SPL) 源能產生 2500 RMS 的 16 位元樣本。
• 請錄製語音辨識音訊串流，讓 PCM 的振幅以線性方式追蹤輸入 SPL 至少介於 30 dB 之間的值，範圍從麥克風介於 -18 dB 到 +12 dB re 90 dB SPL 之間。
• 如以 90 dB SPL 輸入等級，以 1 kHz 為 1 kHz 的音訊辨識音訊串流必須小於 1%。

如果裝置實作宣告 android.hardware.microphone，以及針對語音辨識調整的雜訊抑制 (縮減) 技術，就會：

• [C-2-1] 必須允許透過 android.media.audiofx.NoiseSuppressor API 控制這項音訊影響。
• [C-2-2] 必須使用 AudioEffect.Descriptor.uuid 欄位，才能明確識別每項雜訊抑制技術實作情形。

5.4.3. 擷取用於重新轉送播放內容的擷取內容

android.media.MediaRecorder.AudioSource 類別包含 REMOTE_SUBMIX 音訊來源。

如果裝置實作程序同時宣告 android.hardware.audio.output 和 android.hardware.microphone，兩者會：

• [C-1-1] 必須正確實作 REMOTE_SUBMIX 音訊來源，這樣當應用程式使用 android.media.AudioRecord API 從這個音訊來源錄製時，就會擷取所有音訊串流的組合，但下列項目除外：

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.5. 音訊播放

Android 包括讓應用程式透過音訊輸出週邊裝置播放音訊 (如第 7.8.2 節所定義)。

5.5.1。原始音訊播放

如果裝置實作項目宣告 android.hardware.audio.output，就會：

• [C-1-1] 必須允許播放符合下列特性的原始音訊內容：

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

• 應允許播放具有下列特性的原始音訊內容：

  • 取樣率：24000、48000

5.5.2。音效

Android 提供用於裝置實作的音效 API。

如果裝置實作方式宣告了 android.hardware.audio.output 功能，就會：

• [C-1-1] 必須支援可透過 AudioEffect 子類別 Equalizer、LoudnessEnhancer 控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 實作。
• [C-1-2] 必須支援視覺化工具 API 實作，且可透過 Visualizer 類別控制。
• 應支援可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作項目。

5.5.3. 音訊輸出音量

Automotive 裝置實作：

• 應允許使用 AudioAttributes 定義的內容類型，或 android.car.CarAudioManager 中公開定義的車輛音訊使用方式，分別調整每個音訊串流的音訊音量。

5.6. 音訊延遲時間

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

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

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

如果裝置導入方式宣告 android.hardware.audio.output，就極力建議符合或超過下列規定：

• [SR] 冷輸出延遲時間不超過 100 毫秒
• [SR] 連續輸出延遲時間不超過 45 毫秒
• [SR] 盡量減少冷輸出時基誤差

在使用 OpenSL ES PCM 緩衝區佇列 API 時，如果裝置的實作方式符合上述要求，至少要透過一部支援的音訊輸出裝置進行連續輸出延遲和冷輸出延遲，就會發生以下情形：

• [SR] 強烈建議透過宣告 android.hardware.audio.low_latency 功能旗標來回報低延遲音訊。
• [SR] 強烈建議你一併符合透過 AAudio API 進行低延遲音訊的需求。

如果裝置實作不符合透過 OpenSL ES PCM 緩衝區佇列 API 進行低延遲音訊的要求，則可能：

• [C-1-1] 「不得」回報支援低延遲音訊的相關支援。

如果裝置實作項目包含 android.hardware.microphone，我們強烈建議符合以下輸入音訊規定：

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

5.7. 網路通訊協定

裝置實作「必須」支援播放音訊和影片播放的媒體網路通訊協定，如 Android SDK 說明文件所述。

如果裝置實作包含音訊或影片解碼器，就會：

• [C-1-1] 必須支援第 5.1 節 (而非 HTTP(S)) 所述的所有必要轉碼器和容器格式。

• [C-1-2] 必須支援 HTTP 即時串流草稿通訊協定第 7 版，下方的 Media Segmant 格式表格顯示的媒體區隔格式。

• [C-1-3] 「必須」支援下方 RTSP 表格中的下列 RTP 音訊視訊設定檔和相關轉碼器。如有例外，請參閱 5.1 節中的表格註釋。

媒體區隔格式

區隔格式	參考資料	必要的轉碼器支援
MPEG-2 傳輸串流	ISO 13818	影片轉碼器： H264 AVC MPEG-4 SP MPEG-2 如要進一步瞭解 H264 AVC、MPEG2-4 SP、 和 MPEG-2，請參閱第 5.1.3 節。 音訊轉碼器： AAC 如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
採用 ADTS 取景和 ID3 代碼的 AAC	ISO 13818-7	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
WebVTT	WebVTT

RTSP (RTP、SDP)

設定檔名稱	參考資料	必要的轉碼器支援
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 節。
H263-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-ES	RFC 6416	如要進一步瞭解 MPEG-4 SP，請參閱第 5.1.3 節。
mpeg4-generic	RFC 3640	如要進一步瞭解 AAC 及其變化版本，請參閱第 5.1.1 節。
MP2T	RFC 2250	詳情請參閱 HTTP 直播下方的 MPEG-2 傳輸串流

5.8. 安全媒體

如果裝置實作支援安全視訊輸出，且能夠支援安全介面，就會發生以下情形：

• [C-1-1] 必須宣告支援 Display.FLAG_SECURE。

如果裝置導入方式宣告支援 Display.FLAG_SECURE，並支援無線顯示通訊協定，就會：

• [C-2-1] 請針對透過 Miracast 等無線通訊協定連線的螢幕，使用加密強度高的機制 (例如 HDCP 2.x 以上版本) 保護連結安全。

如果裝置實作項目宣告支援 Display.FLAG_SECURE，並支援有線外接螢幕，就會：

• [C-3-1] 必須支援所有有線外接螢幕的 HDCP 1.2 以上版本。

5.9. 樂器數位介面 (MIDI)

如果裝置實作支援應用程式內的 MIDI 軟體傳輸 (虛擬 MIDI 裝置)，且支援下列所有支援 MIDI 的硬體傳輸，且支援一般的非 MIDI 連線，就會得到以下支援：

• [SR] 強烈建議透過 android.content.pm.PackageManager 類別回報對 android.software.midi 功能的支援。

支援 MIDI 的硬體傳輸元件如下：

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

如果裝置實作方式透過上述特定支援 MIDI 的硬體傳輸方式提供一般非 MIDI 連線，但不支援透過該硬體傳輸使用 MIDI，則表示：

• [C-1-1] 不得回報對功能 android.software.midi 的支援。

5.10. 專業音訊內容

如果裝置實作程序透過 android.content.pm.PackageManager 類別回報支援 android.hardware.audio.pro 功能，就會：

• [C-1-1] 必須回報支援 android.hardware.audio.low_latency 功能。
• [C-1-2] 必須設定連續往返音訊延遲時間，如第 5.6 節音訊延遲時間定義，延遲時間不得超過 20 毫秒，且至少在一個支援的路徑上應不超過 10 毫秒。
• [C-1-3] 必須納入支援 USB 主機模式和 USB 週邊模式的 USB 連接埠。
• [C-1-4] 必須回報支援 android.software.midi 功能。
• [C-1-5] 必須使用 OpenSL ES PCM 緩衝區佇列 API，才能符合延遲時間和 USB 音訊規定。
• 建議在啟用音訊時提供穩定水準的 CPU 效能。
• 應盡量減少音訊時鐘的準確度，以及相對於標準時間的偏移。
• 在兩個動作皆啟動時，應盡量減少音訊時鐘與 CPU (CLOCK_MONOTONIC) 的偏移值。
• 應盡量縮短裝置端轉換器的音訊延遲。
• 相較於 USB 數位音訊，應盡量縮短音訊延遲。
• 應記錄所有路徑的音訊延遲測量值。
• 請盡量減少音訊緩衝區完成回呼輸入時間，因為這會影響回呼可用的完整 CPU 頻寬百分比。
• 應該在正常使用的情況下，以正常使用方式回報零時播放音訊 (輸出) 或超額 (輸入)。
• 應呈現零的跨管道延遲時間差異。
• 應盡量減少所有傳輸中的 MIDI 平均延遲時間。
• 應盡量減少所有傳輸中負載 (時基誤差) 下的 MIDI 延遲時間變化。
• 所有傳輸作業都應提供準確的 MIDI 時間戳記。
• 應盡量減少在裝置端轉場器 (包括冷啟動後會立即) 的音訊訊號雜訊。
• 如果兩者啟用時，對應端點的輸入與輸出端應呈現零的音訊時脈。相應的端點範例包括裝置端麥克風和喇叭，或是音訊插孔輸入和輸出。
• 在兩者皆啟用的情況下，應在同一個執行緒上針對對應端點的輸入和輸出端，處理音訊緩衝區完成回呼，並在輸入回呼的傳回後立即輸入輸出回呼。如果無法在同一個執行緒上處理回呼，則在輸入輸入回呼後不久，輸入輸出回呼，讓應用程式擁有一致的輸入和輸出端時間。
• 針對對應端點的輸入和輸出端，盡量減少 HAL 音訊緩衝區之間的相位差異。
• 應盡量縮短觸控延遲時間。
• 應盡量減少載入時觸控延遲時間的變化 (時基誤差)。

如果裝置的實作方式符合上述所有規定，就會：

• [SR] 強烈建議透過 android.content.pm.PackageManager 類別回報對 android.hardware.audio.pro 功能的支援。

如果裝置實作可透過 OpenSL ES PCM 緩衝區佇列 API 滿足要求，就會：

• [SR] 強烈建議透過 AAudio API 遵守相同規定。

如果裝置實作項目包含 4 導體 3.5 公釐耳機插孔，即可：

• [C-2-1] 音訊插孔路徑的連續往返音訊延遲時間不得超過 20 毫秒。
• [SR] 強烈建議遵循有線音訊頭戴式規格 (v1.1) 的行動裝置 (插孔) 規格。
• 連續往返音訊延遲時間應在音訊插孔路徑中不超過 10 毫秒。

如果裝置實作略過 4 導體 3.5 公釐耳機插孔，則：

• [C-3-1] 連續往返音訊延遲時間不得超過 20 毫秒。
• 使用 USB 音訊類別的 USB 主機模式連接埠時，連續往返音訊延遲時間應小於 10 毫秒。

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

• [C-4-1] 必須實作 USB 音訊類別。

如果裝置導入作業設有 HDMI 連接埠，請執行下列操作：

• [C-5-1] 必須能夠以 20 位元或 24 位元深度和 192 kHz 支援立體聲輸出和 8 個聲道，且無需發生位元深度損失或重新採樣。

5.11. 螢幕截圖尚未處理完成

Android 支援透過 android.media.MediaRecorder.AudioSource.UNPROCESSED 音訊來源錄製未處理的音訊。在 OpenSL ES 中，可使用記錄預設值 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 存取。

如果裝置實作意圖支援未處理的音訊來源，並提供給第三方應用程式使用，就會執行以下動作：

• [C-1-1] 請務必透過 android.media.AudioManager 屬性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 回報支援情形。

• [C-1-2] 在中頻範圍內，必須呈現大致扁平的振幅與頻率特性：特別是從 100 Hz 到 7000 Hz 的每台麥克風，用來記錄未處理音訊來源的每個麥克風。

• [C-1-3] 低頻率範圍必須呈現振幅 (特別是 ±20 dB 的 5 Hz 至 100 Hz 範圍)，對於記錄未處理音訊來源的每個麥克風，兩者的中頻範圍相比差異更是如此。

• [C-1-4] 必須在高頻率範圍內表現振幅 (特別是 ±30 dB 的 7000 Hz 至 22 KHz 範圍)，對於錄製未處理音訊來源的每個麥克風，兩者相比的中頻率範圍更是介於 ±30 dB。

• [C-1-5] 必須設定音訊輸入靈敏度，讓以 94 dB 音壓等級 (SPL) 播放的 1000 Hz 聲調音源能產生回應，且 RMS 為 520，適用於 16 位元樣本 (針對每個使用且每個未精度取樣的音訊，-36 dB 完整體重計)

• [C-1-6] 針對每個用來錄製未處理音訊來源的麥克風，每個麥克風都必須達到 60 dB 以上的訊號雜訊比 (SNR)。(SNR 的衡量標準為 94 dB SPL 與自雜噪音 (A 加權) 相等的 SPL 之間的差異)。

• [C-1-7] 每使用 1 kHZ 時，每使用 90 dB SPL 輸入音量，以及每個用來錄製未處理音訊來源的麥克風，兩者的諧變扭曲 (THD) 都不得超過 1%。

• 除非路徑經過調整，否則請勿要求任何其他處理訊號 (例如自動增益控制、高通過濾器或回音取消)，以便讓等級範圍達到所需範圍。換句話說：

• [C-1-8] 如果架構中存在任何原因的信號處理，則「必須」停用該功能，並有效地將零延遲或額外的延遲時間加入信號路徑。
• [C-1-9] 當層級係數允許在路徑上，但「不得」造成信號路徑延遲或延遲。

所有 SPL 測量結果都直接放在受測試的麥克風旁邊。如果設定多項麥克風，則這些需求適用於每個麥克風。

如果裝置實作項目已宣告 android.hardware.microphone，但不支援未處理的音訊來源，就會：

• [C-2-1] 必須為 AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API 方法傳回 null，以便正確指出不支援這項功能。
• [SR] 仍極力建議，以滿足未處理錄製來源的信號路徑要求 (盡可能滿足多項要求)。

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

6.1. 開發人員工具

裝置實作方式：

• [C-0-1] 必須支援 Android SDK 中提供的 Android 開發人員工具。

• Android Debug Bridge (ADB)

  • [C-0-2] 必須支援 Android SDK 中記錄的所有 ADB 函式，包括 dumpsys。
  • [C-0-3] 不得變更透過 dumpsys 記錄的裝置系統事件 (batterystats、Diskstats、指紋、graphicstats、netstats、通知、 procstats) 的格式或內容。
  • [C-0-4] 裝置端 ADB Daemon 必須預設為停用，且該機制必須可讓使用者存取，才能啟用 Android Debug Bridge。
  • [C-0-5] 必須支援安全 ADB。Android 支援安全 ADB。安全 ADB 可在已知的已驗證主機上啟用 ADB。

  • [C-0-6] 必須提供讓 ADB 從主機機器連線的機制。例如：

    • 如果裝置的實作沒有 USB 連接埠支援週邊裝置模式，就「必須」透過區域區域網路 (例如乙太網路或 Wi-Fi) 實作 ADB。
    • 「必須」提供 Windows 7、9 和 10 的驅動程式，讓開發人員使用 ADB 通訊協定連線至裝置。

• Dalvik 偵錯監控服務 (ddms)

  • [C-0-7] 必須支援 Android SDK 中記錄的所有 ddms 功能。由於 ddms 會使用 ADB，因此預設會停用 ddms 的支援功能，但當使用者啟用 Android Debug Bridge 時，「必須」提供支援。
• Monkey
  • [C-0-8] 必須加入 Monkey 架構，供應用程式使用。
• SysTrace
  • [C-0-9] 必須支援 Android SDK 中記錄的 systrace 工具。Systrace 必須預設為停用，且「必須」讓使用者能存取相關機制，才能啟用 Systrace。

6.2. 開發人員選項

Android 支援開發人員調整應用程式開發相關設定。

裝置實作「必須」為開發人員選項提供一致的體驗，包括：

• [C-0-1] 必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，以顯示應用程式開發相關設定。在上游 Android 實作項目中，「開發人員選項」選單預設為隱藏，使用者只要依序點選「設定」 >「關於裝置」 >「版本號碼」選單項目七 (7) 次，即可啟動開發人員選項。
• [C-0-2] 必須預設隱藏開發人員選項，且「必須」提供啟用開發人員選項的機制，無需任何特殊許可清單。
• 可能會暫時限制「開發人員選項」選單的存取權，例如隱藏或停用選單，以免在顧慮使用者安全的情況下受到干擾。

7. 硬體相容性

如果裝置含有特定硬體元件，且該元件有第三方開發人員專用的 API：

• [C-0-1] 裝置實作「必須」按照 Android SDK 說明文件中所述實作該 API。

如果 SDK 中的 API 與註明為選用的硬體元件互動，且裝置實作項目並未擁有該元件：

• [C-0-2] 您仍必須提出元件 API 的完整類別定義 (如 SDK 所述)。
• [C-0-3] API 的行為「必須」以合理的方式實作為免人工管理。
• [C-0-4] 在 SDK 說明文件允許的情況下，API 方法「必須」傳回空值。
• [C-0-5] API 方法「必須」針對 SDK 說明文件不允許的空值類別傳回免人工管理實作項目。
• [C-0-6] API 方法「不得」擲回 SDK 說明文件未記錄的例外狀況。
• [C-0-7] 裝置實作「必須」針對相同建構指紋，在 android.content.pm.PackageManager 類別上透過 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法持續回報準確的硬體設定資訊。

符合這些規定的典型範例就是電話 API：即使在手機以外的裝置上，這些 API 的實作方式也必須以合理的免人工管理方式實作。

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 UI 架構支援各種不同的邏輯螢幕版面配置大小，可讓應用程式透過 Configuration.screenLayout 搭配 SCREENLAYOUT_SIZE_MASK 和 Configuration.smallestScreenWidthDp，查詢目前設定的螢幕版面配置大小。

• [C-0-1] 裝置實作「必須」根據 Android SDK 說明文件中的定義，回報 Configuration.screenLayout 的正確版面配置大小。具體來說，裝置實作「必須」回報正確的邏輯密度獨立像素 (dp) 螢幕尺寸，如下所示：

  • 如果裝置將 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 以外的任何值，且回報 Configuration.screenLayout 的 small 大小，則至少須具備 426 dp x 320 dp。
  • 回報 Configuration.screenLayout 為 normal 尺寸的裝置必須至少具備 480 dp x 320 dp。
  • 回報 Configuration.screenLayout 的 large 尺寸的裝置不得小於 640 dp x 480 dp。
  • 回報 Configuration.screenLayout 為 xlarge 尺寸的裝置必須至少具備 960 dp x 720 dp。

• [C-0-2] 裝置實作「必須」正確遵循 AndroidManifest.xml 中 <supports-screens> 屬性指定的螢幕大小支援，如 Android SDK 說明文件所述。

7.1.1.2。螢幕顯示比例

雖然實體螢幕的螢幕顯示比例沒有限制，但第三方應用程式顯示的邏輯螢幕顯示比例 (可從 view.Display API 和 Configuration API 回報的高度和寬度值取得) 必須符合下列規定：

• [C-0-1] 在 Configuration.uiMode 設為 UI_MODE_TYPE_NORMAL 的情況下，裝置的顯示比例值必須介於 1.3333 (4:3) 和 1.86 (約 16:9)，除非應用程式符合下列任一條件，即可視為已可延展：

  • 應用程式已透過 android.max_aspect 中繼資料值，宣告其支援較大的螢幕顯示比例。
  • 應用程式會透過 android:resizeableActivity 屬性宣告可調整大小。
  • 應用程式指定的 API 級別為 24 以上，且未宣告會限制可用顯示比例的 android:MaxAspectRatio。

• [C-0-2] 在 Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 的情況下，裝置實作的顯示比例值必須設為 1.0 (1:1)。

7.1.1.3. 螢幕密度

Android UI 架構定義了一組標準邏輯密度，協助應用程式開發人員指定應用程式資源。

• [C-0-1] 根據預設，裝置實作項目「必須」透過 DENSITY_DEVICE_STABLE API 回報下列其中一種邏輯 Android 架構密度，且這個值「不得」隨時變更；不過，裝置「可能」會根據使用者在初始啟動後所設的顯示設定變更 (例如顯示大小) 回報不同的密度，

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

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

如果有權變更裝置的顯示大小：

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

7.1.2. 顯示指標

如果裝置實作項目包含畫面或影片輸出內容，就會：

• [C-1-1] 必須針對 android.util.DisplayMetrics API 中定義的所有顯示指標回報正確的值。

如果裝置實作項目不含嵌入畫面或影片輸出內容，就會：

• [C-2-1] 必須針對模擬預設 view.Display，為 android.util.DisplayMetrics API 定義的所有多媒體指標回報合理值。

7.1.3. 螢幕方向

裝置實作方式：

• [C-0-1] 必須回報支援的螢幕方向 (android.hardware.screen.portrait 和/或 android.hardware.screen.landscape)，且至少必須回報一種支援的螢幕方向。舉例來說，如果裝置螢幕方向為固定的橫向螢幕 (例如電視或筆電)，就只能回報 android.hardware.screen.landscape。
• [C-0-2] 每次透過 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查詢時，都必須回報裝置目前螢幕方向的正確值。

如果裝置實作支援這兩種螢幕方向，就會發生以下情形：

• [C-1-1] 必須讓應用程式支援直向或橫向螢幕方向的動態螢幕方向。也就是說，裝置必須遵循應用程式的特定螢幕方向要求。
• [C-1-2] 變更螢幕方向時，「不得」變更回報的螢幕大小或密度。
• 可選取直向或橫向做為預設螢幕方向。

7.1.4。2D 和 3D 圖形加速

7.1.4.1 OpenGL ES

裝置實作方式：

• [C-0-1] 必須透過代管 API (例如透過 GLES10.getString() 方法) 和原生 API，正確識別支援的 OpenGL ES 版本 (1.1、2.0、3.0、3.1、3.2)。
• [C-0-2] 必須針對指出支援的每個 OpenGL ES 版本，加入所有對應的代管 API 和原生 API 的支援。

如果裝置實作項目包含畫面或影片輸出內容，就會：

• [C-1-1] 必須同時支援 OpenGL ES 1.0 和 2.0，詳情請參閱 Android SDK 說明文件。
• 強烈建議 [SR] 支援 OpenGL ES 3.0。
• 應支援 OpenGL ES 3.1 或 3.2。

如果裝置實作支援任何 OpenGL ES 版本，就會：

• [C-2-1] 「必須」透過 OpenGL ES 代管 API 和原生 API 回報自己已導入的任何其他 OpenGL ES 擴充功能，而且「不得」回報不支援的擴充功能字串。
• [C-2-2] 必須支援 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage 和 EGL_ANDROID_recordable 擴充功能。
• [SR] 極力建議支援 EGL_KHR_partial_update。
• 應透過 getString() 方法正確回報，也就是他們支援的任何紋理壓縮格式，通常僅適用於供應商。

如果裝置實作宣告支援 OpenGL ES 3.0、3.1 或 3.2，就會發生以下情形：

• [C-3-1] 除了 OpenGL ES 2.0 程式庫中的 OpenGL ES 2.0 函式符號外，「C-3-1」還必須匯出這些版本對應的函式符號。

如果裝置的實作支援 OpenGL ES 3.2，就會發生以下情形：

• [C-4-1] 必須完整支援 OpenGL ES Android 擴充功能包。

如果裝置實作程序完全支援 OpenGL ES Android 擴充功能套件，就會執行以下動作：

• [C-5-1] 必須透過 android.hardware.opengles.aep 功能旗標辨別支援項目。

如果裝置實作項目公開對 EGL_KHR_mutable_render_buffer 擴充功能的支援功能，就會：

• [C-6-1] 也必須支援 EGL_ANDROID_front_buffer_auto_refresh 擴充功能。

7.1.4.2 Vulkan

Android 支援 Vulkan，這個低負載的跨平台 API 可用於高效能 3D 圖形。

如果裝置的實作支援 OpenGL ES 3.0 或 3.1，就會發生以下情形：

• [SR] 強烈建議開始支援 Vulkan 1.0。

如果裝置實作項目包含畫面或影片輸出內容，就會：

• 應支援 Vulkan 1.0。

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

• [C-1-1] 必須使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能旗標回報正確的整數值。
• [C-1-2] 請務必列舉至少一個 Vulkan 原生 API vkEnumeratePhysicalDevices() 適用的 VkPhysicalDevice。
• [C-1-3] 必須為每個列舉的 VkPhysicalDevice 完全實作 Vulkan 1.0 API。
• [C-1-4] 請務必透過 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties()，列舉位於應用程式套件原生程式庫目錄中名為 libVkLayer*.so 的原生程式庫中的層。
• [C-1-5] 除非應用程式將 android:debuggable 屬性設為 true，否則「不得」列舉應用程式套件以外程式庫提供的層，或提供其他追蹤或攔截 Vulkan API 的方法。
• [C-1-6] 必須回報所有透過 Vulkan 原生 API 支援的擴充功能字串，相反地，也「不得」回報未正確支援的擴充功能字串。

裝置實作 (如果未支援 Vulkan 1.0)：

• [C-2-1] 不得宣告任何 Vulkan 功能旗標 (例如 android.hardware.vulkan.level、android.hardware.vulkan.version)。
• [C-2-2] 不得為 Vulkan 原生 API vkEnumeratePhysicalDevices() 列舉任何 VkPhysicalDevice。

7.1.4.3 RenderScript

• [C-0-1] 裝置實作項目必須支援 Android RenderScript，詳情請見 Android SDK 說明文件。

7.1.4.4 2D 圖形加速

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

裝置實作方式：

• [C-0-1] 預設「必須」啟用硬體加速功能，如果開發人員透過設定 android:hardwareAccelerated="false" 或直接透過 Android View API 停用硬體加速功能來要求要求，則「必須」停用硬體加速。
• [C-0-2] 必須呈現與硬體加速 Android SDK 說明文件一致的行為。

Android 包含 TextureView 物件，可讓開發人員直接整合硬體加速的 OpenGL ES 紋理，做為 UI 階層中的算繪目標。

裝置實作方式：

• [C-0-3] 必須支援 TextureView API，且「必須」展現與上游 Android 實作一致的行為。

7.1.4.5 廣角螢幕

如果裝置實作方式透過 Configuration.isScreenWideColorGamut() 宣告支援廣角螢幕，就會：

• [C-1-1] 必須採用色彩校正的螢幕。
• [C-1-2] 在 CIE 1931 xyY 空間中，「必須」具備完全覆蓋 sRGB 色域的螢幕。
• [C-1-3] 在 CIE 1931 xyY 中，「必須」具備高達 90% 面積至少 90% 的 NTSC 1953 螢幕。
• [C-1-4] 必須支援 OpenGL ES 3.0、3.1 或 3.2，並妥善回報。
• [C-1-5] 必須宣傳 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_colorspace_scrgb_linear 和 EGL_GL_colorspace_display_p3 額外資訊的支援。
• [SR] 強烈建議支援 GL_EXT_sRGB。

相反地，如果裝置的實作不支援廣角螢幕，就會：

• [C-2-1] 在 CIE 1931 xyY 空間中，必須涵蓋 100% 以上的 sRGB，但螢幕色彩密度未定義。

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

Android 指定一種「相容性模式」，在這個模式下，架構會在「標準」螢幕大小的相等 (320dp 寬度) 模式下運作，以便善用未針對舊版 Android (即螢幕大小獨立) 未開發的舊版應用程式，提供許多好處。

7.1.6。螢幕技術

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

裝置實作方式：

• [C-0-1] 必須支援能夠呈現 16 位元色彩圖形的螢幕。
• 應支援能夠顯示 24 位元色彩圖形的螢幕。
• [C-0-2] 必須支援能夠轉譯動畫的螢幕。
• [C-0-3] 採用像素顯示比例 (PAR) 介於 0.9 至 1.15 之間的螢幕技術。也就是說，像素顯示比例必須接近 1.0 正方形 (寬 10 ~ 15%)。

7.1.7. 第二螢幕

Android 支援次要螢幕，可啟用媒體分享功能，以及用來存取外部螢幕的開發人員 API。

如果裝置的實作方式支援有線、無線或嵌入式其他螢幕連線的外接螢幕，則裝置必須符合以下條件：

• [C-1-1] 必須按照 Android SDK 說明文件所述，實作 DisplayManager 系統服務和 API。

7.2. 輸入裝置

裝置實作方式：

• [C-0-1] 必須包含用於在 UI 元素之間導覽的輸入機制，例如觸控螢幕或非觸控式導覽。

7.2.1。鍵盤

如果裝置實作項目支援第三方輸入法編輯器 (IME) 應用程式，請按照下列步驟操作：

• [C-1-1] 必須宣告 android.software.input_methods 功能標記。
• [C-1-2] 必須完全導入 Input Management Framework
• [C-1-3] 必須使用預先載入的軟體鍵盤。

裝置實作：[C-0-1]「不得」提供不符合 android.content.res.Configuration.keyboard (QWERTY 或 12-key) 指定格式的硬體鍵盤。應加入其他螢幕鍵盤實作。* 可能提供實體鍵盤。

7.2.2。非觸控瀏覽

Android 支援 D-pad、軌跡球和滾輪做為非觸控瀏覽的機制。

裝置實作方式：

• [C-0-1] 必須回報 android.content.res.Configuration.navigation 的正確值。

如果裝置的實作方式沒有非觸控式導覽，就會：

• [C-1-1] 「必須」提供合理的替代使用者介面機制來選取及編輯文字，並且支援輸入管理引擎。上游 Android 開放原始碼實作包含選取機制，適合缺少非觸控瀏覽輸入裝置的裝置使用。

7.2.3. 瀏覽鍵

「主畫面」、「近期存取」和「返回」功能通常是透過與專屬實體按鈕或觸控螢幕不同部分的互動提供，是 Android 導覽範例不可或缺的要素，因此：

• [C-0-1] 必須提供住家功能。
• 應提供「近期」和「返回」函式的按鈕。

如果有提供「首頁」、「近期存取」或「返回」功能，請按照下列步驟操作：

• [C-1-1] 必須讓使用者能透過單一動作 (例如輕觸、按兩下或手勢) 進入任何無障礙操作。
• [C-1-2] 必須明確指出每個函式會觸發哪個單一動作。這類指標包括在按鈕上呈現可見的圖示、在畫面的導覽列顯示軟體圖示，或是引導使用者逐步示範教學流程。

裝置實作方式：

• [SR] 強烈建議不要為選單函式提供輸入機制，因為自 Android 4.0 版起，該函式已淘汰，並改用動作列。

如果裝置實作提供選單功能，就會：

• [C-2-1] 每當動作溢位選單彈出式選單沒有空白，且系統顯示動作列時，「必須」顯示動作溢位按鈕。
• [C-2-2] 「不得」透過在動作列中選取溢位按鈕的方式修改動作溢位彈出式視窗顯示的位置，但「可能」選取選單函式，以在畫面修改時的位置顯示動作溢位彈出式視窗。

如果裝置實作項目未提供選單功能，但基於回溯相容性，則：* [C-3-1] 在 targetSdkVersion 小於 10 時，必須可透過實體按鈕、軟體鍵或手勢，為應用程式提供選單功能。除非與其他導覽函式一併隱藏，否則應可存取這個選單函式。

如果裝置實作提供輔助功能，則 [C-4-1] 在可存取其他瀏覽鍵時，「必須」讓使用者透過單一動作 (例如輕觸、按兩下或手勢) 存取輔助功能。[SR] 強烈建議使用長按主畫面功能，做為這項指定的互動行為。

如果裝置的實作方式使用畫面中的獨立部分顯示瀏覽鍵，就會執行以下動作：

• [C-5-1] 瀏覽鍵「必須」使用畫面的特定部分，且不得提供給應用程式使用，也「不得」遮蓋或乾擾應用程式可用的部分畫面。
• [C-5-2] 凡是符合第 7.1.1 節規定的應用程式，都必須提供部分顯示畫面。
• [C-5-3] 必須遵循應用程式透過 View.setSystemUiVisibility() API 方法設定的旗標，以便讓畫面的這個不同部分 (亦即導覽列) 正確隱藏 (如 SDK 所述)。

7.2.4。觸控螢幕輸入

Android 支援多種指標輸入系統，例如觸控螢幕、觸控板和模擬觸控輸入裝置。以觸控螢幕為基礎的裝置實作方式會與螢幕建立關聯，讓使用者擁有直接操控畫面上的項目。由於使用者是直接觸碰螢幕，系統並不需要任何額外的預設用途來表示受操控的物件。

裝置實作方式：

• 應採用某種指標輸入系統 (類似滑鼠或觸控)。
• 應支援完全獨立追蹤的指標。

如果裝置實作項目包含觸控螢幕 (單點觸控或更棒)，就會執行以下動作：

• [C-1-1] 必須回報 Configuration.touchscreen API 欄位的 TOUCHSCREEN_FINGER。
• [C-1-2] 必須回報 android.hardware.touchscreen 和 android.hardware.faketouch 功能旗標

如果裝置實作包含可追蹤多次觸控的觸控螢幕，則裝置會：

• [C-2-1] 必須根據裝置上特定觸控螢幕的類型，回報適當的功能旗標 android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand。

如果裝置的實作方式不含觸控螢幕 (且僅使用指標裝置)，並且符合第 7.2.5 節的模擬觸控要求，就會執行以下動作：

• [C-3-1] 「不得」回報任何開頭為 android.hardware.touchscreen 的功能標記，且只能回報 android.hardware.faketouch。

7.2.5。虛擬觸控輸入

模擬觸控介面提供使用者輸入系統，可近似一部分的觸控螢幕功能。舉例來說，如果滑鼠或遙控器驅動螢幕上的遊標大約觸控，但使用者必須先找到第一個點或焦點，接著點選該控制項，許多輸入裝置 (例如滑鼠、觸控板、陀螺儀、陀螺儀、陀螺儀、搖桿和多點觸控觸控板等，都能支援觸控模擬的互動。Android 加入功能常數 android.hardware.faketouch，對應到高保真非觸控 (以指標為基礎的) 輸入裝置，例如可以適當模擬觸控輸入 (包括基本手勢支援) 的滑鼠或觸控板，也代表裝置支援模擬的觸控螢幕功能子集。

如果裝置實作項目不含觸控螢幕，但包含想提供的其他指標輸入系統，則裝置採用的實作方式如下：

• 應宣告支援 android.hardware.faketouch 功能標記。

如果裝置實作項目宣告支援 android.hardware.faketouch，就會：

• [C-1-1] 必須回報指標位置的絕對 X 和 Y 螢幕位置，並在螢幕上顯示視覺指標。
• [C-1-2] 必須回報觸控事件，並提供指定畫面向下或向上時，用來指定狀態變更的動作代碼。
• [C-1-3] 必須讓畫面上的物件支援指標向下和向上，讓使用者模擬輕觸畫面上的物件。
• [C-1-4] 必須支援指標向下、向上指標、將遊標停在螢幕的相同位置上，且於時間門檻內的相同位置上，使用者能夠模擬對螢幕上物體輕觸兩下。
• [C-1-5] 必須支援螢幕上任意點的向下指標，而指標會移至螢幕上任何其他點，然後向上指標，讓使用者模擬觸控拖曳手勢。
• [C-1-6] 必須支援向下指標，然後讓使用者能夠快速將物件移到螢幕上的不同位置，然後向上移動在螢幕上的方向，使用者就能快速將物件擲回螢幕上。
• [C-1-7] 必須針對 Configuration.touchscreen API 欄位回報 TOUCHSCREEN_NOTOUCH。

如果裝置實作項目宣告支援 android.hardware.faketouch.multitouch.distinct，就會：

• [C-2-1] 必須宣告支援 android.hardware.faketouch。
• [C-2-2] 必須能夠分別追蹤兩個以上的獨立指標輸入資料。

如果裝置實作項目宣告支援 android.hardware.faketouch.multitouch.jazzhand，就會：

• [C-3-1] 必須宣告支援 android.hardware.faketouch。
• [C-3-2] 必須完全分別支援 5 種 (追蹤手指) 或多個指標輸入的動作。

7.2.6。遊戲控制器支援

7.2.6.1。按鈕對應

如果裝置實作項目宣告了 android.hardware.gamepad 功能旗標，就會：[C-1-1]「必須」在方塊中嵌入控制器或隨附獨立控制器，這代表輸入下表中列出的所有事件。[C-1-2] 必須能夠將 HID 事件對應至相關聯的 Android view.InputEvent 常數，如下表所示。Android 上游實作包括為符合這項規定的遊戲控制器實作。

按鈕	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)
Y^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 邏輯值 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。遙控器

請參閱 2.3.1 節，瞭解裝置專屬的需求。

7.3. 感應器

如果裝置實作項目包含特定感應器類型，且該類型具有第三方開發人員適用的 API，則裝置的實作「必須」按照 Android SDK 說明文件和感應器中的 Android 開放原始碼說明文件實作該 API。

裝置實作方式：

• [C-0-1] 必須根據 android.content.pm.PackageManager 類別準確回報感應器是否存在。
• [C-0-2] 「必須」透過 SensorManager.getSensorList() 和類似方法傳回支援的感應器清單。
• [C-0-3] 必須對所有其他感應器 API 採取合理行為，例如在應用程式嘗試註冊事件監聽器時傳回 true 或 false，或是在對應的感應器不存在時呼叫感應器事件監聽器等。

如果裝置實作項目包含特定感應器類型，且該類型為第三方開發人員提供對應 API，那麼：

• [C-1-1] 必須按照 Android SDK 說明文件中定義的各種感應器類型，使用相關國際單位 (公制) 值回報所有感應器測量結果。
• [C-1-2] 必須回報延遲時間最長 100 毫秒的感應器資料
• 2 * 串流感應器的 sample_time，且應用程式處理器啟動時，最短延遲時間為 5 毫秒 + 2 * sample_time。此延遲未包含任何篩選延遲。
• [C-1-3] 必須在感應器啟用的 400 毫秒 + 2 * sample_time 內，回報第一個感應器樣本。此樣本的準確率為 0，可以接受。

• [SR] 「應該」回報事件時間 (以奈秒為單位)，如 Android SDK 說明文件中所定義，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘保持同步。強烈建議現有和新的 Android 裝置符合這些規定，以便升級至日後推出的平台版本，做為「必要」元件。同步處理錯誤應小於 100 毫秒。

• [C-1-4] 如果 Android SDK 說明文件指出的 API 是連續的感應器，裝置實作項目「必須」持續提供時基誤差低於 3% 的定期資料樣本，其中時基誤差的定義為連續事件回報的時間戳記值差異的標準差。

• [C-1-5] 必須確保感應器事件串流「不得」阻止裝置 CPU 進入暫停狀態或從暫停狀態喚醒。

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

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

某些感應器類型是複合資料，因此可從一或多個其他感應器提供的資料衍生而來。(例如方向感應器和線性加速感應器)。

裝置實作方式：

• 如感應器類型所述，當感應器包含必要的實體感應器時，應導入這些感應器類型。

如果裝置實作項目內含複合感應器，請執行以下操作：

• [C-2-1] 必須按照 Android 開放原始碼說明文件中所述的複合感應器做法實作感應器。

7.3.1。加速計

• 實作裝置須包含 3 軸式加速度計。

如果裝置導入方式包含 3 軸式加速度計，就會發生以下情形：

• [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
• [C-1-2] 必須導入及回報 TYPE_ACCELEROMETER 感應器。
• [C-1-3] 必須遵循 Android API 中詳述的 Android 感應器座標系統。
• [C-1-4] 必須能夠根據任何軸上的重力(4 公克) 或更多重力量測量
• [C-1-5] 必須採用至少 12 位元的解析度。
• [C-1-6] 標準差不得大於 0.05 m/s^。標準差應根據針對至少 3 秒收集到的樣本，以每軸計算標準差。
• [SR] 強烈建議實作 TYPE_SIGNIFICANT_MOTION 複合感應器。
• 如果有線上加速計校正功能可用，[SR] 強烈建議導入 TYPE_ACCELEROMETER_UNCALIBRATED 感應器。
• 請務必按照 Android SDK 文件所述，實作 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。
• 回報的事件大小必須至少為 200 Hz。
• 解析度至少要有 16 位元。
• 如果生命週期內的特性會隨生命週期變化並補償，使用時應進行校正，並保留裝置重新啟動之間的補償參數。
• 應以體溫為準。
• 也應實作 TYPE_ACCELEROMETER_UNCALIBRATED 感應器。

如果裝置實作項目包含 3 軸式加速度計以及任何 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR，系統會實作 TYPE_STEP_COUNTER 複合感應器：

• [C-2-1] 兩者的耗電量總和一律小於 4 mW。
• 裝置處於動態或靜態狀態時，每個頻寬皆應低於 2 mW 和 0.5 mW。

如果裝置導入方式包含 3 軸式加速度計和陀螺儀感應器，它們：

• [C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
• 應實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。
• [SR] 強烈建議現有和新的 Android 裝置實作 TYPE_GAME_ROTATION_VECTOR 感應器。

如果裝置實作所需裝置包含 3 軸式加速度計、陀螺儀感應器和磁力儀感應器，請按照下列步驟操作：

• [C-4-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

7.3.2。磁力儀

• 實作裝置須包含 3 軸式磁力計 (指南針)。

如果裝置實作方式包含 3 軸的磁力儀，將會：

• [C-1-1] 必須實作 TYPE_MAGNETIC_FIELD 感應器。
• [C-1-2] 必須能夠以至少 10 Hz 的頻率回報事件，且應回報至少 50 Hz 的事件。
• [C-1-3] 必須遵循 Android API 中詳述的 Android 感應器座標系統。
• [C-1-4] 必須能夠測量每軸介於 -900 μT 和 +900 μT 之間的距離，然後才能進出飽和度。
• [C-1-5] 必須設定小於 700 μT 的硬鐵偏移值，且磁力儀值必須遠離動態 (誘發) 和靜態 (誘發的) 磁場，且值必須小於 200 μT。
• [C-1-6] 解析度必須等於或小於 0.6 μT。
• [C-1-7] 必須支援線上校正與補償，造成硬鐵偏誤，並在裝置重新啟動時保留補償參數。
• [C-1-8] 請務必套用軟鐵補償，確保裝置在使用期間或生產期間皆可進行校正。
• [C-1-9] 必須設定標準差 (針對至少 3 秒收集且以最快取樣率 (不超過 1.5 μT) 的取樣率計算 (以每軸為單位)；必須大於 0.5 μT 的標準差。
• 應實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。
• [SR] 強烈建議現有和新的 Android 裝置實作 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。

如果裝置實作方式包括 3 軸式磁力計、加速計感應器和陀螺儀感應器，請執行以下操作：

• [C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作方式包含 3 軸式磁力計 (加速計)，將會：

• 可以實作 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器。

如果裝置實作方式包含 3 軸式磁力計、加速計和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 感應器，請按照下列步驟操作：

• [C-3-1] 耗電量必須低於 10 mW。
• 如果以 10 Hz 註冊感應器為批次模式，耗電量應低於 3 mW。

7.3.3. GPS

裝置實作方式：

• 應包含 GPS/GNSS 接收器。

如果裝置實作項目包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，就會發生以下情形：

• [C-1-1] 透過 LocationManager#requestLocationUpdate 要求時，必須支援至少 1 Hz 的位置輸出功能。
• [C-1-2] 必須能在連上 0.5 Mbps 以上數據網路連線的情況下，在 10 秒內 (快速信號、多徑、HDOP < 2) 的空中判斷位置。通常使用某種輔助或預測的 GPS/GNSS 技術來盡可能縮短 GPS/GNSS 鎖定時間 (輔助資料包含參考時間、參考位置和衛星電話/時鐘)。
  • [SR] 進行這類位置計算後，「大力」建議裝置在 10 秒內 (當位置要求重新啟動時，以及首次計算位置要求後最多一小時後) 判斷其位置，即使後續沒有數據連線和/或重新開機的要求也不例外。

• 判斷地點後，在開放天空的情況下，以每秒 1 公尺為單位靜止或移動的加速度小於 1 公尺：

  • [C-1-3] 必須能夠判斷所在位置在 20 公尺以內，且速度在每秒 0.5 公尺以內，且時間至少為 95%。
  • [C-1-4] 必須同時透過至少 8 個星座衛星的 GnssStatus.Callback 同時追蹤及回報情況。
  • 至少要能夠同時從多個星座 (例如 GPS 加上至少 24 個星座、北斗、Galileo) 追蹤。
  • [C-1-5] 必須透過測試 API「getGnssYearOfHardware」回報 GNSS 技術產生資料。
  • [SR] 撥打緊急電話時，持續提供正常的 GPS/GNSS 位置輸出。
  • [SR] 回報所有追蹤的星座 GNSS 測量結果 (如 GnssStatus 訊息中的報告)，但 SBAS 除外。
  • [SR] 回報 AGC 和 GNSS 測量頻率。
  • [SR] 回報每個 GPS 位置的所有準確估計值 (包括方位、速度和產業)。
  • 我們強烈建議 [SR] 透過 Test API LocationManager.getGnssYearOfHardware()，盡可能符合「2016 年」或「2017 年」年份的其他必要規定。

如果裝置實作項目包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標和 LocationManager.getGnssYearOfHardware() Test API 將功能回報給應用程式，就會發生以下情形：

• [C-2-1] 必須在找到 GPS 測量結果後立即回報，即使尚未回報來自 GPS/GNSS 的位置也一樣。
• [C-2-2] 必須回報 GPS 虛擬範圍和虛擬範圍速率，在確定地點後，如果是靜止或移動的每秒平方差小於 0.2 公尺的移動速度，足以計算出 20 公尺以內的位置，且速度至少在每秒 0.2 公尺以內。

如果裝置實作項目包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標和 LocationManager.getGnssYearOfHardware() Test API 將功能回報給應用程式，就會發生以下情形：

• [C-3-1] 緊急電話通話期間，「必須」繼續提供正常的 GPS/GNSS 位置輸出資料。
• [C-3-2] 必須回報追蹤的所有星座 (如 GnssStatus 訊息所回報) 的 GNSS 測量資料 (SBAS 除外)。
• [C-3-3] 必須回報 AGC 和 GNSS 測量頻率。
• [C-3-4] 請務必回報每個 GPS 位置的所有準確估計值 (包括方位、速度和垂直位置)。

7.3.4。陀螺儀

裝置實作方式：

• 必須加入陀螺儀 (角度變化感應器)。
• 除非一併使用 3 軸式加速度計，否則請勿採用陀螺儀感應器。

如果裝置實作程序包含陀螺儀，這項功能會：

• [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
• [C-1-2] 必須實作 TYPE_GYROSCOPE 感應器，且必須一併實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。
• [C-1-3] 必須能夠測量每秒高達 1,000 度方向的變化。
• [C-1-4] 必須採用 12 位元以上的解析度，且解析度必須為 16 位元以上。
• [C-1-5] 必須計算溫度。
• [C-1-6] 在使用期間必須進行校準及補償，並在裝置重新啟動時保留補償參數。
• [C-1-7] 變異數必須不超過 1e-7 rad^2/s^2/Hz (每 Hz 變異數，或雷射值^2/秒)。變異數可以隨取樣率而異，但必須受到這個值限制。換句話說，如果您以 1 Hz 的取樣率測量陀螺儀的變異數，則不應大於 1e-7 rad^2/s^2。
• [SR] 強烈建議現有和新的 Android 裝置實作 SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 感應器。
• [SR] 大力「建議」在裝置溫度靜止不動時，校正錯誤應小於 0.01 雷/秒。
• 回報的事件大小必須至少為 200 Hz。

如果裝置實作項目包括陀螺儀、加速計感應器和磁力儀感應器，它們：

• [C-2-1] 必須實作 TYPE_ROTATION_VECTOR 複合感應器。

如果裝置實作項目包括陀螺儀和加速計感應器，請：

• [C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
• [SR] 強烈建議現有和新的 Android 裝置實作 TYPE_GAME_ROTATION_VECTOR 感應器。
• 應實作 TYPE_GAME_ROTATION_VECTOR 複合感應器。

7.3.5。氣壓計

• 實作裝置應納入氣壓計 (環境氣壓感應器)。

如果裝置導入作業包含氣壓計，表示：

• [C-1-1] 必須導入及回報 TYPE_PRESSURE 感應器。
• [C-1-2] 必須能夠以 5 Hz 以上傳送事件。
• [C-1-3] 必須計算溫度。
• [SR] 強烈建議能夠回報 300hPa 到 1100hPa 範圍的壓力測量值。
• 應具有 1hPa 的絕對準確性。
• 應有 20hPa 範圍以上的 0.12hPa 相對準確度 (當海平面上變更幅度約 200 公尺時，準確度可達 100 萬以下)。

7.3.6。溫度計

裝置實作方式：可能包括環境溫度計 (溫度感應器)。可能，但不應使用 CPU 溫度感應器。

如果裝置實作項目包括環境溫度計 (溫度感應器)，請採取以下步驟：

• [C-1-1] 必須定義為 SENSOR_TYPE_AMBIENT_TEMPERATURE，且必須測量使用者與裝置互動時的環境 (房間/車廂) 溫度 (以攝氏度為單位)。
• [C-1-2] 必須定義為 SENSOR_TYPE_TEMPERATURE。
• [C-1-3] 必須測量裝置 CPU 的溫度。
• [C-1-4] 請勿測量任何其他溫度。

請注意，SENSOR_TYPE_TEMPERATURE 感應器類型已在 Android 4.0 中淘汰。

7.3.7。Photometer

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

7.3.8。鄰近感應器

• 實作裝置可能包含鄰近感應器。

如果裝置導入方式包含鄰近感應器，就會：

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

7.3.9。高保真感應器

如果裝置實作項目包含本節所定義的一組高品質感應器，並為第三方應用程式提供這些感應器，那麼這些裝置會執行以下動作：

• [C-1-1] 必須使用 android.hardware.sensor.hifi_sensors 功能旗標來識別功能。

如果裝置實作項目宣告 android.hardware.sensor.hifi_sensors，就會：

• [C-2-1] 必須具備下列 TYPE_ACCELEROMETER 感應器：

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

• [C-2-2] 的 TYPE_ACCELEROMETER_UNCALIBRATED 必須採用與 TYPE_ACCELEROMETER 相同的品質規定。

• [C-2-3] 必須具有下列 TYPE_GYROSCOPE 感應器：

  • 測量範圍必須介於 -1,000 至 +1000 dp 之間。
  • 測量解析度至少須為 16 LSB/dp。
  • 測量頻率不得低於 12.5 Hz。
  • 測量頻率上限為 400 Hz 以上。
  • 測量噪音必須超過 0.014°/s/√Hz。
  • 24 小時的靜態資料集應有小於 0.0002 °/s √Hz 的固定偏誤。
  • 應該有偏誤變化，而不是溫度 ≤ +/- 0.05 °/ s / °C。
  • 應有靈敏度變化，但溫度應為 ≤ 0.02% / °C。
  • 應有最佳的非線性廣告非線性性，且 ≤ 0.2%。
  • 雜訊密度必須小於 0.007 °/s/√Hz。
  • 應使用白色雜訊光譜，確保感應器的雜訊完整性符合充分評估標準。
  • 裝置靜止時，應在溫度範圍 10 到 40 °C 之間，發生低於 0.002 rad/s 的校準錯誤。

• [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED 必須具有與 TYPE_GYROSCOPE 相同的品質規定。

• [C-2-5] 必須使用 TYPE_GEOMAGNETIC_FIELD 感應器，可提供以下功能：
  • 測量範圍必須至少介於 -900 至 +900 uT 之間。
  • 測量解析度至少須為 5 LSB/uT。
  • 測量頻率至少須為 5 Hz 以下。
  • 測量頻率上限為 50 Hz 以上。
  • 測量雜訊量必須大於 0.5 uT。
• [C-2-6] 的 TYPE_MAGNETIC_FIELD_UNCALIBRATED 品質規定必須與 TYPE_GEOMAGNETIC_FIELD 相同，並且符合下列條件：
  • 這個感應器必須實作至少 600 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 應使用白色雜訊光譜，確保感應器的雜訊完整性符合充分評估標準。
• [C-2-7] 必須具有下列 TYPE_PRESSURE 感應器：
  • 測量範圍必須介於 300 至 1100 hPa 之間。
  • 測量解析度必須至少為 80 LSB/hPa。
  • 測量頻率不得低於 1 Hz。
  • 測量頻率上限為 10 Hz。
  • 測量噪音必須超過 2 Pa/√Hz。
  • 這個感應器必須實作至少 300 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 批次耗電量不得低於 2 mW。
• [C-2-8] 必須具有下列 TYPE_GAME_ROTATION_VECTOR 感應器：
  • 這個感應器必須實作至少 300 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 批次耗電量不得低於 4 mW。
• [C-2-9] 必須具有下列 TYPE_SIGNIFICANT_MOTION 感應器：
  • 裝置為靜態時，耗電量必須低於 0.5 mW，移動時耗電量至少為 1.5 mW。
• [C-2-10] 必須具有下列 TYPE_STEP_DETECTOR 感應器：
  • 這個感應器必須實作至少 100 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
  • 裝置為靜態時，耗電量必須低於 0.5 mW，移動時耗電量至少為 1.5 mW。
  • 批次耗電量不得低於 4 mW。
• [C-2-11] 「必須」具備支援以下功能的 TYPE_STEP_COUNTER 感應器：
  • 裝置為靜態時，耗電量必須低於 0.5 mW，移動時耗電量至少為 1.5 mW。
• [C-2-12] 必須具有下列 TILT_DETECTOR 感應器：
  • 裝置為靜態時，耗電量必須低於 0.5 mW，移動時耗電量至少為 1.5 mW。
• [C-2-13] 相同實體事件的事件時間戳記，是由加速計、陀螺儀感應器和磁力儀，兩者之間的距離不得超過 2.5 毫秒。
• [C-2-14] 陀螺儀感應器事件的時間戳記必須與相機子系統相同，且在 1 毫秒內發生錯誤。
• [C-2-15] 從上述任何實體感應器可取得資料時，「必須」在 5 毫秒內將範例提供給應用程式。
• [C-2-16] 當裝置處於靜態狀態時，當裝置處於靜態狀態時，耗電量不得高於 0.5 mW；當裝置移動時，若一併啟用以下任一感應器，則耗電量不得高於 2.0 mW：
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] 可能具有 TYPE_PROXIMITY 感應器，但如果有的話，至少「緩衝區」功能「必須」為 100 個感應器事件。

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

如果裝置的實作方式支援感應器直接支援，請採取下列做法：

• [C-3-1] 必須透過 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API，正確宣告支援直接管道類型和直接報表率層級。
• [C-3-2] 凡是宣告支援感應器直接通道的感應器，都必須支援至少兩種感應器直接通道類型之一
• TYPE_HARDWARE_BUFFER
• TYPE_MEMORY_FILE
• 針對以下類型的主要感應器 (非喚醒變化版本)，支援透過感應器直接管道回報事件：
• TYPE_ACCELEROMETER
• TYPE_ACCELEROMETER_UNCALIBRATED
• TYPE_GYROSCOPE
• TYPE_GYROSCOPE_UNCALIBRATED
• TYPE_MAGNETIC_FIELD
• TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10。指紋感應器

如果裝置實作項目包含安全螢幕鎖定，他們會：

• 其中應包含指紋感應器。

如果裝置實作項目包含指紋感應器，且為第三方應用程式提供感應器，請按照下列步驟操作：

• [C-1-1] 必須宣告支援 android.hardware.fingerprint 功能。
• [C-1-2] 必須完全導入 Android SDK 說明文件中所述的相對應的 API。
• [C-1-3] 不正確的接受率不得超過 0.002%。
• [C-1-4] 如果進行 5 次不實的指紋驗證，請設下頻率限制至少 30 秒。
• [C-1-5] 必須實作硬體支援的 KeyStore，並在受信任的執行環境 (TEE) 或具備安全通道的晶片上執行指紋比對。
• [C-1-6] 所有可識別指紋資料都必須經過加密及加密驗證，以防止在受信任的執行環境 (TEE) 之外取得、讀取或修改，如 Android 開放原始碼專案網站上的實作指南所述。
• [C-1-7] 必須讓使用者確認現有或新增受到 TEE 保護的裝置憑證 (PIN 碼/圖案/密碼)，以防新增指紋。
• [C-1-8] 「不得」允許第三方應用程式區分不同的指紋。
• [C-1-9] 必須遵循 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT 標記。
• [C-1-10] 從 Android 6.0 以下版本升級時，「必須」以安全的方式遷移指紋資料，以符合上述規定或移除。
• [SR] 強烈建議將裝置拒絕率低於 10% 的值 (如裝置所示)。
• [SR] 強烈建議將延遲時間控制在 1 秒以下，從指紋感應器輕觸到螢幕解鎖為止，期間只有一隻已註冊的手指。
• 應使用 Android 開放原始碼計畫中提供的 Android 指紋圖示。

7.3.11。僅支援 Android Automotive 的感應器

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

7.3.11.1。目前齒輪

請參閱 2.5.1 節，瞭解裝置專屬的需求。

7.3.11.2。日間模式

請參閱 2.5.1 節，瞭解裝置專屬的需求。

7.3.11.3. 行車狀態

請參閱 2.5.1 節，瞭解裝置專屬的需求。

7.3.11.4。方向盤速度

請參閱 2.5.1 節，瞭解裝置專屬的需求。

7.3.12。姿勢感應器

裝置實作方式：

• 可能支援 6 度自由度的姿勢感應器。

如果裝置實作支援自由 6 度自由姿勢的姿勢感應器，請按照下列步驟操作：

• [C-1-1] 必須導入及回報 TYPE_POSE_6DOF 感應器。
• [C-1-2] 必須比只使用旋轉向量時的準確度高。

7.4. 資料連線

7.4.1。電話通訊系統

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

• Android MAY 適用於不含電話硬體硬體的裝置。也就是說，Android 與非手機裝置相容。

如果裝置實作項目包含 GSM 或 CDMA 電話，則：

• [C-1-1] 必須根據技術宣告 android.hardware.telephony 功能旗標和其他子功能旗標。
• [C-1-2] 必須導入該技術的完整 API 支援。

如果裝置實作項目不包含電話硬體，它們：

• [C-2-1] 必須將完整的 API 實作為免人工管理。

7.4.1.1。號碼封鎖相容性

如果裝置實作方式回報 android.hardware.telephony feature，就會：

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

7.4.2。IEEE 802.11 (Wi-Fi)

裝置實作方式：

• 應支援一或多種 802.11 形式。

如果裝置的實作支援 802.11，並且向第三方應用程式公開這項功能，他們必須：

• [C-1-1] 必須實作對應的 Andr:oid API。
• [C-1-2] 必須回報硬體功能旗標 android.hardware.wifi。
• [C-1-3] 必須按照 SDK 說明文件中所述導入多點傳播 API。
• [C-1-4] 必須支援多點傳送 DNS (mDNS)，且在作業期間一律「不得」篩選 mDNS 封包 (224.0.0.251)，包括：
  • 即使螢幕未處於使用中狀態也一樣。
  • 適用於 Android TV 裝置實作，即使處於待機狀態也一樣。
• 每次掃描開始時，都請隨機產生來源 MAC 位址和探測要求影格的序號，一次，但 STA 會中斷連線。
  • 包含一次掃描作業的每組探測要求頁框，都應使用一個一致的 MAC 位址 (不應透過掃描在半途隨機處理 MAC 位址)。
  • 在掃描作業中的探測要求之間，探測要求序號應像一般 (依序) 疊代
  • 探測要求的序號應在掃描的最後一個探測要求和下一次掃描作業的第一次探測要求之間隨機排序
• 應僅在探測要求框架中允許以下資訊元素，但 STA 連線中斷：
  • SSID 參數集 (0)
  • DS 參數組合 (3)

7.4.2.1。Wi-Fi Direct

裝置實作方式：

• 應提供 Wi-Fi Direct (Wi-Fi 點對點) 支援。

如果裝置的實作支援 Wi-Fi Direct，請執行以下操作：

• [C-1-1] 必須按照 SDK 說明文件所述，實作對應的 Android API。
• [C-1-2] 必須回報 android.hardware.wifi.direct 硬體功能。
• [C-1-3] 必須支援一般 Wi-Fi 運作。
• 應同時支援 Wi-Fi 和 Wi-Fi Direct 作業。

7.4.2.2。Wi-Fi 通道直接連結設定

裝置實作方式：

• 應加入 Android SDK 說明文件中所述的 Wi-Fi 通道直接連結設定 (TDLS) 支援。

如果裝置實作項目包括對 TDLS 的支援，且 WiFiManager API 已啟用 TDLS，則：

• [C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。
• 請只在可能且有利的情況下才使用 TDLS。
• 「不應」使用一些經驗法則，並「不要」使用 TDLS (因為網路效能可能比使用 Wi-Fi 存取點更高)。

7.4.2.3。Wi-Fi 感知

裝置實作方式：

• 應提供 Wi-Fi Aware 支援。

如果裝置的實作項目支援 Wi-Fi Aware 功能，並且向第三方應用程式公開相關功能，那麼：

• [C-1-1] 必須按照 SDK 說明文件中所述導入 WifiAwareManager API。
• [C-1-2] 必須宣告 android.hardware.wifi.aware 功能標記。
• [C-1-3] 必須同時支援 Wi-Fi 和 Wi-Fi Aware 作業。
• [C-1-4] 啟用 Wi-Fi Aware 時，「必須」以間隔時間隨機挑選 Wi-Fi Aware 管理介面位址，為期至少 30 分鐘。

7.4.2.4。Wi-Fi Passpoint

裝置實作方式：

• 應支援 Wi-Fi Passpoint。

如果裝置的實作支援 Wi-Fi Passpoint，就會：

• [C-1-1] 必須按照 SDK 說明文件中所述，實作 Passpoint 相關 WifiManager API。
• [C-1-2] 必須支援 IEEE 802.11u 標準，特別是與網路探索和選取有關，例如通用廣告服務 (GAS) 和存取網路查詢通訊協定 (ANQP)。

相反地，如果裝置的實作不支援 Wi-Fi Passpoint，請這樣做：

• [C-2-1] 實作 Passpoint 相關 WifiManager API 的實作「必須」擲回 UnsupportedOperationException。

7.4.3. 藍牙

如果裝置實作支援藍牙音訊設定檔，就會：

• 應支援進階音訊轉碼器和藍牙音訊轉碼器 (例如 LDAC)。

如果裝置實作方式宣告了 android.hardware.vr.high_performance 功能，就會：

• [C-1-1] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能。

Android 支援藍牙和藍牙低功耗。

如果實作的裝置支援藍牙和藍牙低功耗功能，就會：

• [C-2-1] 必須宣告相關的平台功能 (分別 android.hardware.bluetooth 和 android.hardware.bluetooth_le) 並實作平台 API。
• 請視情況為裝置實作相關的藍牙設定檔，例如 A2DP、AVCP、OBEX 等。

如果裝置的實作支援藍牙低功耗，就會：

• [C-3-1] 必須宣告硬體功能 android.hardware.bluetooth_le。
• [C-3-2] 必須啟用 SDK 說明文件和 android.bluetooth 中所述的 GATT (一般屬性設定檔) 式藍牙 API。
• [C-3-3] 請務必回報 BluetoothAdapter.isOffloadedFilteringSupported() 的正確值，指出是否已導入 ScanFilter API 類別的篩選邏輯。
• [C-3-4] 請務必回報 BluetoothAdapter.isMultipleAdvertisementSupported() 的正確值，指出是否支援低功耗廣告。
• 實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。
• 應支援將批次掃描卸載到藍牙晶片組。

• 應支援至少有 4 個版位的多廣告。

• [SR] 強烈建議你導入可撤銷私人網址 (RPA) 逾時時間不得超過 15 分鐘，並在逾時時輪替網址，以保護使用者隱私。

7.4.4。近距離無線通訊

裝置實作方式：

• 應提供近距離無線通訊 (NFC) 專用的收發機和相關硬體。
• [C-0-1] 即使類別不支援 NFC 或宣告 android.hardware.nfc 功能，因為類別代表通訊協定獨立資料表示法格式，也必須導入 android.nfc.NdefMessage 和 android.nfc.NdefRecord API。

如果裝置實作項目包含 NFC 硬體，且預計提供給第三方應用程式使用，那麼這些裝置會執行以下動作：

• [C-1-1] 必須從 android.content.pm.PackageManager.hasSystemFeature() 方法回報 android.hardware.nfc 功能。
• 必須能夠透過下列 NFC 標準讀取和寫入 NDEF 訊息：
• [C-1-2] 必須能夠以下列 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、5 (由 NFC 論壇定義)

• [SR] 強烈建議能夠根據以下 NFC 標準讀取和寫入 NDEF 訊息，以及原始資料。請注意，雖然 NFC 標準明確表示「建議做法」，但未來版本的相容性定義將改為「必須」。這些標準對這個版本而言是選用項目，但在日後推出的版本中也是必要條件。無論現有和新裝置搭載此 Android 版本，我們都強烈建議你立即符合這些規定，以便升級至未來的平台版本。

• [C-1-3] 必須能夠按照下列點對點標準和通訊協定傳輸及接收資料：

  • ISO 18092
  • LLCP 1.2 (由 NFC 論壇定義)
  • SDP 1.0 (由 NFC 論壇定義)
  • NDEF Push Protocol
  • SNEP 1.0 (由 NFC 論壇定義)
• [C-1-4] 必須納入 Android Beam 的支援，且應預設啟用 Android Beam。
• [C-1-5] 必須啟用 Android Beam 或開啟其他專屬 NFC P2p 模式，才能使用 Android Beam 收發訊息。
• [C-1-6] 必須實作 SNEP 預設伺服器。預設 SNEP 伺服器接收的有效 NDEF 訊息，「必須」使用 android.nfc.ACTION_NDEF_DISCOVERED 意圖將訊息分派給應用程式。在設定中停用 Android Beam 「不得」停用傳入的 NDEF 訊息。
• [C-1-7] 必須遵循 android.settings.NFCSHARING_SETTINGS 意圖，才能顯示 NFC 分享設定。
• [C-1-8] 必須實作 NPP 伺服器。NPP 伺服器接收訊息的方式「必須與」 SNEP 預設伺服器相同。
• [C-1-9] 必須實作 SNEP 用戶端，並嘗試在 Android Beam 啟用時將傳出 P2P NDEF 傳送至預設 SNEP 伺服器。如果找不到預設 SNEP 伺服器，用戶端「必須」嘗試傳送至 NPP 伺服器。
• [C-1-10] 必須允許前景活動使用 android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback 和 android.nfc.NfcAdapter.enableForegroundNdefPush 設定傳出 P2P NDEF 訊息。
• 傳送 P2P NDEF 訊息前，應先使用手勢或螢幕上的確認訊息 (例如「輕觸傳輸」)。
• [C-1-11] 在裝置支援藍牙物件推送設定檔時，必須支援 NFC 連線轉移至藍牙功能。
• [C-1-12] 使用 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 要求來執行連線轉移。
• [C-1-13] 在 NFC 探索模式下，「必須」輪詢所有支援的技術。
• 當裝置處於啟用狀態且螢幕鎖定時，應使用 NFC 探索模式。
• 應能讀取 Thinfilm NFC 條碼產品的條碼和網址 (如果經過編碼)。

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

Android 支援 NFC 主機卡片模擬 (HCE) 模式。

如果裝置實作包含可支援 HCE (適用於 NfcA 和/或 NfcB) 的 NFC 控制器晶片組，並支援應用程式 ID (AID) 轉送功能，則裝置 ID 支援路徑如下：

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

如果裝置實作包含支援 HCE (適用於 NfcF 的 HCE) 的 NFC 控制器晶片組，並為第三方應用程式實作這項功能，應用程式會：

• [C-3-1] 必須回報 android.hardware.nfc.hcef 功能常數。
• [C-3-2] 必須導入 Android SDK 中定義的 NfcF Card Emulation API。

如果裝置的實作方式包括本節所述的一般 NFC 支援，並支援讀取者/寫入者角色的 MIFARE 技術 (MIFARE Classic、MIFARE Ultralight、NDEF)，即可：

• [C-4-1] 必須按照 Android SDK 的說明實作對應的 Android API。
• [C-4-2] 「必須」透過 android.content.pm.PackageManager.hasSystemFeature() 方法回報 com.nxp.mifare 功能。請注意，這並非標準的 Android 功能，因此不會做為 android.content.pm.PackageManager 類別中的常數。

7.4.5。最低網路功能

裝置實作方式：

• [C-0-1] 必須支援一或多種資料網路。具體來說，裝置實作項目「必須」支援至少一項支援 200Kbit/秒以上的資料標準。符合這項規定的技術包括 EDGE、HSPA、EV-DO、802.11g、乙太網路、藍牙 PAN 等。
• [C-0-2] 必須納入 IPv6 網路堆疊，並支援使用代管 API (例如 java.net.Socket 和 java.net.URLConnection) 和原生 API (例如 AF_INET6 通訊端) 的 IPv6 通訊。
• [C-0-3] 預設必須啟用 IPv6。
• 舉例來說，IPv6 通訊必須保證像 IPv4 一樣可靠。
• [C-0-4] 務必在打盹模式下維持 IPv6 連線。
• [C-0-5] 頻率限制「不得」會造成裝置在符合 IPv6 規範的網路中，無法使用 RA 生命週期至少 180 秒的 IPv6 連線。
• 此外，在以實體網路標準 (例如乙太網路) 做為主要數據連線的情況下，至少應支援一項通用無線資料標準，例如 802.11 (Wi-Fi)
• 可以實作多種形式的數據連線。

IPv6 支援所需的等級會因網路類型而異，如下所示：

如果實作的裝置支援 Wi-Fi 網路，就會：

• [C-1-1] 必須「必須」支援在 Wi-Fi 連線時執行雙重堆疊和僅限 IPv6 的作業。

如果裝置實作支援乙太網路，就會：

• [C-2-1] 必須支援乙太網路上的雙重堆疊作業。

如果裝置的實作方式支援行動數據，就會：

• [C-3-1] 當裝置同時連線到多個網路時，「必須」同時符合每個連線網路的規定 (例如Wi-Fi 和行動數據) 的應用程式。
• 應支援透過行動數據使用 IPv6 作業 (僅限 IPv6 且可能雙重堆疊)。

7.4.6。同步處理設定

裝置實作方式：

• [C-0-1] 「必須」將主自動同步處理設定預設為開啟，讓 getMasterSyncAutomatically() 方法傳回「true」。

7.4.7。數據節省模式

如果裝置實作項目提供計量付費連線，則表示：

• [SR] 強烈建議提供數據節省模式。

如果裝置實作項目提供數據節省模式，就會發生以下情形：

• [C-1-1] 必須支援 ConnectivityManager 類別中的所有 API，如 SDK 說明文件所述
• [C-1-2] 必須在設定中提供處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖的使用者介面，讓使用者可將應用程式新增至許可清單或從許可清單中移除。

如果裝置實作項目未提供數據節省模式，就會發生以下情形：

• [C-2-1] 必須傳回 ConnectivityManager.getRestrictBackgroundStatus() 的值 RESTRICT_BACKGROUND_STATUS_DISABLED
• [C-2-2] 「不得」廣播 ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED。
• [C-2-3] 必須包含處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖的活動，但可以做為免人工管理實作。

7.5. 相機

如果裝置的實作方式至少包含一部相機，這些裝置會：

• [C-1-1] 必須宣告 android.hardware.camera.any 功能標記。
• [C-1-2] 應用程式「必須」能夠同時分配 3 個 RGBA_8888 點陣圖，大小等同於裝置上最大解析度相機感應器產生的圖像大小，同時相機為開啟狀態，以便進行基本預覽並照常拍攝。

7.5.1。後置鏡頭

後置鏡頭是指位於裝置側面的相機，對面為螢幕對面，亦即拍攝在裝置最遠處的場景，就像傳統相機一樣。

裝置實作方式：

• 應使用後置鏡頭。

如果裝置實作項目至少包含一個後置鏡頭，請按照以下步驟操作：

• [C-1-1] 必須回報功能標記 android.hardware.camera 和 android.hardware.camera.any。
• [C-1-2] 必須採用至少 200 萬像素的解析度。
• 應在相機驅動程式中導入硬體自動對焦或軟體自動對焦功能 (對應用程式軟體公開)。
• 可能具備固定對焦或 EDOF (延伸領域深度) 硬體。
• 可能包含閃光燈。

如果攝影機包含閃光燈：

• [C-2-1] 除非應用程式已透過啟用 Camera.Parameters 物件的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 屬性，明確啟用閃光燈，否則手電筒「不得」亮起 android.hardware.Camera.PreviewCallback 例項，除非應用程式已在相機預覽表面註冊 android.hardware.Camera.PreviewCallback 例項。請注意，這項限制不適用於裝置的內建系統相機應用程式，但僅適用於使用 Camera.PreviewCallback 的第三方應用程式。

7.5.2。前置鏡頭

前置鏡頭是指與螢幕位於同一側的攝影機，亦即一般用來拍攝使用者的影像，例如視訊會議和類似應用程式。

裝置實作方式：

• 可使用前置鏡頭。

如果裝置的實作方式至少包含一個前置鏡頭，這些裝置會：

• [C-1-1] 必須回報功能標記 android.hardware.camera.any 和 android.hardware.camera.front。
• [C-1-2] 解析度至少須為 VGA (640x480 像素)。
• [C-1-3] 「不得」使用前置鏡頭做為 Camera API 的預設後置鏡頭，且「不得」將 API 設為使用前置鏡頭做為預設後置鏡頭，即使該裝置是裝置上唯一的鏡頭。
• [C-1-4] 當目前應用程式明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法旋轉相機螢幕時，相機預覽「必須」以應用程式所指定的方向水平鏡像翻轉。相反地，如果目前應用程式未明確要求透過呼叫 android.hardware.Camera.setDisplayOrientation() 方法旋轉相機螢幕，預覽畫面「必須」沿著裝置的預設水平軸鏡像翻轉。
• [C-1-5] 不得假定傳回應用程式回呼或承諾用於媒體儲存空間的最終擷取靜態影像或影片串流。
• [C-1-6] 必須按照相機預覽圖像串流的方式，鏡像投射後檢視畫面所顯示的圖像。
• 可能提供後置鏡頭可用的功能 (例如自動對焦、閃光燈等)，如第 7.5.1 節所述。

如果裝置導入方式可由使用者旋轉 (例如透過加速計自動運作，或透過使用者輸入操作手動旋轉)，請執行以下操作：

• [C-2-1] 相機預覽畫面「必須」配合裝置目前螢幕方向水平鏡像。

7.5.3. 外接鏡頭

裝置實作方式：

• 可支援不一定隨時連接的外部相機。

如果裝置的實作支援外部相機，就會：

• [C-1-1] 必須宣告平台功能旗標 android.hardware.camera.external 和 android.hardware camera.any。
• [C-1-2] 如果外接攝影機透過 USB 連接埠連接，則必須支援 USB 視訊類別 (UVC 1.0 以上版本)。
• 應支援 MJPEG 等影片壓縮功能，以便傳輸高品質的未編碼串流 (即原始或獨立壓縮的影像串流)。
• 可能支援多部相機。
• 可能支援攝影機式影片編碼。

如果支援相機式影片編碼：

• [C-2-1] 裝置實作必須能存取同時未編碼 / MJPEG 串流 (QVGA 或更高解析度)。

7.5.4。Camera API 行為

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

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

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

• [C-0-1] 如果應用程式從未呼叫 android.hardware.Camera.Parameters.setPreviewFormat(int)，則必須使用 android.hardware.PixelFormat.YCbCr_420_SP 來提供提供給應用程式回呼的預覽資料。
• [C-0-2] 當應用程式註冊 android.hardware.Camera.PreviewCallback 執行個體，且系統會呼叫 onPreviewFrame() 方法且預覽格式為 YCbCr_420_SP 時，必須進一步採用 NV21 編碼格式，而預覽格式是 YCbCr_420_SP，也就是傳遞到 onPreviewFrame() 的位元組 [] 資料。也就是說，必須預設為 NV21。
• [C-0-3] 一律支援 android.hardware.Camera 的前置和後置鏡頭的 YV12 格式 (如 android.graphics.ImageFormat.YV12 常數表示)。(硬體視訊編碼器和攝影機可以使用任何原生像素格式，但裝置的實作「必須」支援轉換為 YV12 格式)。
• [C-0-4] 必須支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式做為 android.hardware.camera2 的 android.media.ImageReader API 輸出內容。
• [C-0-5] 無論裝置是否內建硬體自動對焦或其他功能，仍必須實作 Android SDK 說明文件中提供的完整 Camera API。舉例來說，不含自動對焦的相機「必須」仍然呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 執行個體 (即使這與非自動對焦相機無關)。請注意，這適用於前置鏡頭；舉例來說，雖然多數前置鏡頭不支援自動對焦，但 API 回呼仍必須「加上假裝」。
• [C-0-6] 必須識別並遵守在 android.hardware.Camera.Parameters 類別中定義為常數的每個參數名稱。相反地，除了在 android.hardware.Camera.Parameters 上記錄為常數的字串常數以外，裝置實作項目「不得」遵循或識別傳送至 android.hardware.Camera.setParameters() 方法的字串常數。也就是說，如果硬體允許，裝置實作項目「必須」支援所有標準相機參數，且「不得」支援自訂的相機參數類型。舉例來說，如果裝置的實作方式支援使用高動態範圍 (HDR) 影像技術擷取相片，就「必須」支援相機參數 Camera.SCENE_MODE_HDR。
• [C-0-7] 必須按照 Android SDK 中的說明，使用 android.info.supportedHardwareLevel 屬性回報適當的支援等級，並回報適當的架構功能旗標。
• [C-0-8] 也必須透過 android.request.availableCapabilities 屬性宣告 android.hardware.camera2 的個別相機功能，並宣告適當的功能旗標。如果隨附的相機裝置支援此功能，「必須」定義功能旗標。
• [C-0-9] 每當相機拍攝新相片，並將圖片項目新增至媒體儲存區時，都必須播送 Camera.ACTION_NEW_PICTURE 意圖。
• [C-0-10] 每當相機錄製新影片，並將圖片項目新增至媒體儲存區時，都必須廣播 Camera.ACTION_NEW_VIDEO 意圖。

7.5.5。相機方向

如果裝置實作有前置或後置鏡頭(例如這類相機)：

• [C-1-1] 請清楚顯示相機的長邊，讓相機的長邊對齊螢幕的長邊。也就是說，當裝置保持橫向時，相機「必須」拍攝橫向的照片。無論裝置的自然螢幕方向為何，這都會受到裝置影響，也就是適用於橫向和直向的主要裝置。

7.6. 記憶體與儲存空間

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

裝置實作方式：

• [C-0-1] 必須加入下載管理員，讓應用程式「可能」用於下載資料檔案，而且「必須」能夠將至少 100 MB 大小的個別檔案下載至預設「快取」位置。

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

裝置實作方式：

• [C-0-1] 「必須」提供應用程式共用儲存空間，這類儲存空間通常稱為「共用外部儲存空間」、「應用程式共用儲存空間」，或掛接目標的 Linux 路徑「/sdcard」。
• [C-0-2] 必須設定預設的共用儲存裝置，也就是「立即可用」，不論儲存空間是實作在內部儲存元件或卸除式儲存媒介上 (例如安全數位卡插槽)。
• [C-0-3] 必須直接在 Linux 路徑 sdcard 中掛接應用程式共用儲存空間，或加入從 sdcard 到實際掛接點的 Linux 符號連結。
• [C-0-4] 必須如 SDK 中記錄，對這個共用儲存空間強制執行 android.permission.WRITE_EXTERNAL_STORAGE 權限。「共用」儲存空間「必須」由任何取得該權限的應用程式寫入。

裝置實作方式「可能」符合上述規定，需使用下列其中一項：

• 使用者可存取的卸除式儲存空間，例如安全數位 (SD) 卡片插槽。
• Android 開放原始碼計畫 (AOSP) 中實作的部分內部 (不可移除) 儲存空間。

如果裝置的實作方式為符合上述需求，使用卸除式儲存空間：

• [C-1-1] 如未在插槽中插入儲存媒介，「必須導入浮動式訊息或彈出式使用者介面」警告使用者。
• [C-1-2] 必須包含 FAT 格式的儲存媒介 (例如 SD 卡)，或是在購買時，顯示需要另外購買儲存媒介的包裝盒和其他材料。

如果裝置的實作方式使用不可移除的儲存空間滿足上述需求，則適用情形：

• 應使用內部應用程式共用儲存空間的 Android 開放原始碼計畫實作項目。
• 可以與應用程式私人資料共用儲存空間。

如果裝置的實作含有多個共用儲存空間路徑 (例如 SD 卡插槽和共用內部儲存空間)，這些路徑：

• [C-2-1]「必須」只允許預先安裝及具有 WRITE_EXTERNAL_STORAGE 權限的 Android 應用程式寫入次要外部儲存空間，除非寫入套件專屬目錄，或藉由啟動 ACTION_OPEN_DOCUMENT_TREE 意圖而傳回的 URI。

如果裝置的實作具備支援 USB 週邊裝置模式的 USB 連接埠，就會：

• [C-3-1] 「必須」提供從主機電腦上存取應用程式共用儲存空間資料的機制。
• 應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，以公開透明的方式顯示這兩個儲存空間路徑的內容。
• 「可能」使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定，以符合這項規定。

如果裝置的實作具備具備 USB 週邊裝置模式的 USB 連接埠，並支援媒體傳輸通訊協定，就會發生以下情形：

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

7.6.3. 採用儲存空間

如果裝置應為行動裝置的性質與電視不同，裝置的導入方式如下：

• [SR] 強烈建議你長期在穩定的位置導入可用的儲存空間，因為意外中斷連線可能會導致資料遺失/損毀。

如果卸除式儲存裝置連接埠位於長期穩定的位置 (例如電池座或其他保護蓋)，裝置的實作方式如下：

• [SR] 強烈建議導入採用儲存空間。

7.7. USB

如果裝置實作有 USB 連接埠，就會：

• 應支援 USB 週邊模式，且應支援 USB 主機模式。

7.7.1。USB 週邊裝置模式

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

• [C-1-1] 連接埠「必須」可連接具有標準 Type-A 或 Type-C USB 連接埠的 USB 主機。
• [C-1-2] 必須透過 android.os.Build.SERIAL，在 USB 標準裝置描述元中回報 iSerialNumber 的正確值。
• [C-1-3] 必須根據 Type-C 電阻標準偵測 1.5A 和 3.0A 充電器，而且如果這些裝置支援 Type-C USB，則「必須」偵測廣告中的變化。
• [SR] 連接埠應使用 micro-B、micro-AB 或 Type-C USB 板型規格。現有和新 Android 裝置強烈建議符合這些規定，以便升級至未來的平台版本。
• [SR] 連接埠「必須」位於裝置底部 (根據自然方向)，或針對所有應用程式 (包括主畫面) 啟用軟體螢幕旋轉功能，這樣當裝置朝底部連接埠朝向方向時，螢幕就能正確繪製。現有和新 Android 裝置強烈建議符合這些規定，以便升級至日後發布的平台版本。
• [SR] 「應該」導入相關支援，在 HS 晶片期間繪製 1.5 A 電流，並按照 USB 電池充電規格 (修訂版本 1.2 版本) 規定繪製。現有和新 Android 裝置強烈建議符合這些規定，以便升級至未來的平台版本。
• [SR] 強烈建議不要支援專門用來修改 Vbus 電壓以外的充電方法，或是更改接收器/來源角色，這樣可能會導致支援標準 USB Power Delivery 方法的充電器或裝置發生互通性問題。雖然這種做法稱為「強烈建議」，但在日後的 Android 版本中，我們可能會要求所有 Type-C 裝置才能與標準 C 型充電器完全互通。
• [SR] 強烈建議在支援 Type-C USB 和 USB 主機模式的情況下，支援用於資料傳輸和電源角色交換的 Power Delivery 功能。
• 應支援 Power Delivery 針對高壓充電，並支援螢幕外等替代模式。
• 應導入 Android Open Accessory (AOA) API 和規格，如 Android SDK 說明文件所述。

如果裝置實作包含 USB 連接埠，請實作 AOA 規格：

• [C-2-1] 必須宣告支援硬體功能 android.hardware.usb.accessory。
• [C-2-2] USB 大量儲存空間級別「必須」在 USB 大量儲存裝置的介面說明 iInterface 字串結尾處加上「android」字串

7.7.2。USB 主機模式

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

• [C-1-1] 必須實作 Android SDK 中記錄的 Android USB 主機 API，且必須宣告支援硬體功能 android.hardware.usb.host。
• [C-1-2] 必須「必須」導入支援功能，才能連接標準 USB 週邊裝置，換句話說，裝置必須符合以下條件：
  • 具備裝置端 C 連接埠或隨附傳輸線，可將裝置專屬連接埠調整為標準 USB Type-C 連接埠 (USB Type-C 裝置)。
  • 擁有裝置端 A 或隨附傳輸線，可將裝置端專屬連接埠調整為標準的 USB Type-A 連接埠。
  • 具備裝置端 micro-AB 連接埠，應搭配可適應標準 A 型連接埠的傳輸線。
• [C-1-3] 請勿隨附從 USB 型 A 或 micro-AB 連接埠轉換為 Type-C 連接埠 (插座) 的變壓器。
• [SR] 強烈建議導入 Android SDK 說明文件所述的 USB 音訊類別。
• 應支援在主機模式下為連接的 USB 週邊裝置充電；請參閱 USB Type-C 傳輸線和連接器規格修訂版本 1.2 (適用於 USB Type-C 連接器) 的終止參數一節，以及使用 AB 電池 1 連接器 (請參閱 USB 電池 1 連接器) 的 1.5A 以上的來源電線。
• 應實作並支援 USB Type-C 標準。

如果裝置實作項目包含支援主機模式的 USB 連接埠和 USB 音訊類別，就會：

• [C-2-1] 必須支援 USB HID 類別。
• [C-2-2] 必須支援偵測及對應 USB HID 使用表格中指定的下列 HID 資料欄位，以及將語音指令使用要求和 KeyEvent 常數的對應作業，如下所示：
  • 用量頁面 (0xC) 用量 ID (0x0CD)：KEYCODE_MEDIA_PLAY_PAUSE
  • 用量頁面 (0xC) 用量 ID (0x0E9)：KEYCODE_VOLUME_UP
  • 用量頁面 (0xC) 用量 ID (0x0EA)：KEYCODE_VOLUME_DOWN
  • 用量頁面 (0xC) 用量 ID (0x0CF)：KEYCODE_VOICE_ASSIST

如果裝置實作項目包含支援主機模式的 USB 連接埠和儲存空間存取架構 (SAF)，必須：

• [C-3-1] 必須辨識任何遠端連線的 MTP (媒體傳輸通訊協定) 裝置，並透過 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT 意圖存取裝置內容。。

如果裝置實作項目提供支援主機模式和 USB Type-C 的 USB 連接埠，就會：

• [C-4-1] 必須依照 USB Type-C 規格定義實作雙角色通訊埠功能 (第 4.5.1.3.3 節)。
• [SR] 強烈建議你支援 DisplayPort，也應支援 USB 超級速度資料速率，而且強烈建議支援 Power Delivery 處理資料和替換角色。
• [SR] 強烈建議「不」支援音訊轉接器配件模式，如 USB Type-C 傳輸線和連接器規格修訂版本 1.2 的附錄 A 所述。
• 請採用最適合裝置板型規格的 try.* 型號。例如手持裝置應實作 try.SNK 模型。

7.8. 音訊

7.8.1。麥克風

如果裝置實作方式包含麥克風，就會：

• [C-1-1] 必須回報 android.hardware.microphone 功能常數。
• [C-1-2] 必須符合第 5.4 節的音訊錄音規定。
• [C-1-3] 必須符合第 5.6 節的音訊延遲規定。
• [SR] 強烈建議支援近乎超音波錄製功能 (如第 7.8.3 節所述)。

如果裝置實作方式省略麥克風，系統會採取以下做法：

• [C-2-1] 「不得」回報 android.hardware.microphone 功能常數。
• [C-2-2] 必須根據第 7 節規定，至少實作音訊錄音 API 為免人工管理。

7.8.2。音訊輸出

如果裝置實作項目包含喇叭，或是音訊輸出週邊裝置的音訊/多媒體輸出連接埠 (例如 4 導體 3.5 公釐耳機插孔，或採用 USB 音訊類別的 USB 主機模式連接埠)，您可以：

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

如果裝置實作項目不包含喇叭或音訊輸出通訊埠，就會：

• [C-2-1] 不得回報 android.hardware.audio output 功能。
• [C-2-2] 至少要實作音訊輸出相關 API 作為免人工管理。

就本節的目的而言，「輸出連接埠」是一種實體介面，例如 3.5 公釐音訊插孔、HDMI 或具備 USB 音訊類別的 USB 主機模式連接埠。但支援透過藍牙、Wi-Fi 或行動網路等以無線電為基礎的通訊協定輸出音訊，也不等同於「輸出通訊埠」。

7.8.2.1。類比音訊連接埠

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

如果裝置實作方式為 4 導電線 3.5 公釐耳機插孔，程式碼會：

• [C-1-1] 必須支援在配有麥克風的立體聲耳機和立體聲耳機上播放音訊。
• [C-1-2] 必須支援 CTIA 輸出順序的 TRRS 音訊插頭。
• [C-1-3] 必須支援偵測及對應按鍵碼，用來偵測及對應按鍵碼，用於麥克風與音訊插頭上相等 3 個範圍同樣造成的阻力：
  • 70 ohm 以下：KEYCODE_HEADSETHOOK
  • 210-290 ohm：KEYCODE_VOLUME_UP
  • 360-680 ohm：KEYCODE_VOLUME_DOWN
• [C-1-4] 插入插頭時必須觸發 ACTION_HEADSET_PLUG，但只有在所有接上電源上的聯絡人在插孔上輕觸對應的區隔後，才能觸發這個程序。
• [C-1-5] 必須能夠透過 32 毫米喇叭阻抗，駕駛至少 150mV ±10% 的輸出電壓。
• [C-1-6] 麥克風偏壓電壓應介於 1.8V 至 2.9V 之間。
• [SR] 強烈建議使用以下按鍵碼，偵測麥克風與接線器在音訊插頭上的相同阻力範圍，並對應的按鍵碼：
  • 110-180 ohm： KEYCODE_VOICE_ASSIST
• 應支援使用 OMTP 綁定順序的音訊插頭。
• 應支援使用麥克風的立體聲耳機錄音。

如果裝置實作項目具有 4 導體 3.5 公釐耳機插孔並支援麥克風，且將額外的麥克風設定為 1，則播送 android.intent.action.HEADSET_PLUG：

• [C-2-1] 必須能偵測已接上電源的音訊配件麥克風。

7.8.3. 近乎超音波

近乎超音波音訊為 18.5 kHz 至 20 kHz 錶帶。

裝置實作方式：

• 「必須」透過 AudioManager.getProperty API 正確回報超音波音訊功能的支援情況，如下所示：

如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 為「true」，則 VOICE_RECOGNITION 和 UNPROCESSED 音訊來源必須符合下列規定：

• [C-1-1] 在 18.5 kHz 至 20 kHz 頻帶中，麥克風的平均功率回應「必須」低於 15 dB (2 kHz)。
• [C-1-2] 麥克風的未加權訊號與雜訊比超過 18.5 kHz 至 20 kHz，在 -26 dBFS 的音色「必須」小於 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 為「true」：

• [C-2-1] 講者在 18.5 kHz 至 20 kHz 的範圍內，平均的回應率不得低於 2 kHz。

7.9. 虛擬實境

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

7.9.1。虛擬實境模式

Android 支援 VR 模式，這項功能可處理通知的立體視覺算繪作業，並可在 VR 應用程式具備使用者焦點時停用單管系統 UI 元件。

7.9.2。虛擬實境高效能

如果裝置實作的結果為透過 android.hardware.vr.high_performance 功能旗標，確認支援長時間使用者期間的高效能 VR 支援：

• [C-1-1] 至少必須有 2 個實體核心。
• [C-1-2] 必須宣告 android.software.vr.mode feature。
• [C-1-3] 必須支援持續效能模式。
• [C-1-4] 必須支援 OpenGL ES 3.2。
• [C-1-5] 必須支援 Vulkan 硬體級別 0，且必須支援 Vulkan 硬體級別 1。
• [C-1-6] 必須實作 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content，並在可用的 EGL 擴充功能清單中顯示擴充功能。
• [C-1-7] GPU 和螢幕「必須」能同步處理共用前端緩衝區的存取權，讓兩個以 60fps 轉譯的 VR 內容交替顯示，在沒有可見的撕裂痕跡的情況下無法顯示。
• [C-1-8] 必須實作 GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2、GL_OVR_multiview_multisampled_render_to_texture、GL_EXT_protected_textures，並在可用 GL 擴充功能清單中顯示擴充功能。
• [C-1-9] 必須按照 NDK 中所述，為 AHardwareBuffer 標記 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER 和 AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 實作支援。
• [C-1-10] 必須導入含有多層 AHardwareBuffers 的支援功能。
• [C-1-11] 必須支援解碼至少 3840x2160@30fps-40Mbps 的 H.264 編碼 (相當於 4 個 1920x1080@30fps-10Mbps 的執行個體，或是 2 個 1920x1080@60fps-20 Mbps 的執行個體)。
• [C-1-12] 必須支援 HEVC 和 VP9，至少要能夠解碼 1920x1080@30fps-10Mbps 且能解碼 3840x2160@30fps-20 Mbps (相當於 1920 fps - 1920x10 fps 的執行個體)。
• [C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回準確的皮膚溫度值。
• [C-1-14] 必須提供內嵌螢幕，且解析度最低須為 FullHD(1080p)，且強烈建議設為 QuadHD (1440p) 以上版本。
• [C-1-15] 處於 VR 模式時，螢幕至少要更新 60 Hz。
• [C-1-16] 從灰色到灰、白到黑和黑到白的切換時間，必須不超過 3 毫秒。
• [C-1-17] 螢幕「必須」支援低持久模式，且持續性不超過 5 毫秒；持續性定義是指像素發出光的時間長度。
• [C-1-18] 必須支援藍牙 4.2 和藍牙 LE Data Length Extension第 7.4.3 節。
• [SR] 強烈建議支援 android.hardware.sensor.hifi_sensors 功能，且「必須」符合 android.hardware.hifi_sensors 的陀螺儀、加速計和磁力儀的相關要求。
• 可以為前景應用程式提供專屬核心，並支援 Process.getExclusiveCores API 以傳回頂端前景應用程式專屬的 CPU 核心數量。

如果支援專屬核心，則使用核心：

• [C-2-1] 不得允許任何其他使用者空間處理程序 (應用程式使用的裝置驅動程式除外)，但「可能」允許部分核心程序視需要執行。

8. 效能與電源

某些最低效能和電源標準是影響使用者體驗的關鍵，也會影響開發人員開發應用程式時的基準假設。

8.1. 使用者體驗一致性

我們提供多種最低需求，讓使用者享有流暢的使用者介面，確保應用程式和遊戲的影格速率和回應時間一致。根據第 2 節所述，視裝置類型而定，裝置實作方式「可能」針對使用者介面延遲和工作切換有可量化的要求。

8.2. 檔案 I/O 存取效能

為應用程式私人資料儲存空間 (/data 分區) 提供一致的檔案存取效能基準，讓應用程式開發人員能製定出適當的期望，以提升軟體設計。視裝置類型而定，裝置實作的下列讀取和寫入作業可能會有第 2 節所述的特定要求：

• 依序寫入效能。計算方法為使用 10 MB 寫入緩衝區寫入 256 MB 檔案。
• 隨機寫入效能。計算方法是使用 4 KB 寫入緩衝區寫入 256 MB 檔案。
• 依序讀取效能。使用 10 MB 寫入緩衝區讀取 256 MB 檔案來評估。
• 隨機讀取效能。使用 4 KB 寫入緩衝區讀取 256 MB 檔案來評估。

8.3.省電模式

Android 提供應用程式待命和打盹模式，用於最佳化電池用量。[SR] 強烈建議使用者查看不受這些模式限制的應用程式。[SR] 我們強烈建議「不要」在這些模式下觸發、維護、喚醒演算法，以及使用這些省電模式的全域系統設定，藉此偏離 Android 開放原始碼計畫。

除了省電模式外，Android 裝置可能會實作進階設定和電源介面 (ACPI) 所定義的 4 個休眠電源狀態 (全部或全部)。

如果裝置實作項目實作 ACPI 定義的 S3 和 S4 電源狀態，可能會發生以下情形：

• [C-1-1] 只有在蓋上裝置確實一部分的蓋子時，才需要進入這些州。

8.4. 耗電量會計

更準確的耗電量計算和耗電量報告，能為應用程式開發人員提供獎勵和最佳化應用程式耗電量模式的工具。

裝置實作方式：

• [SR] 強烈建議提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量值」，以及該元件隨時間變化的約略電池電力 (詳見 Android 開放原始碼計畫網站所述)。
• [SR] 強烈建議以毫秒 (mAh) 為單位回報所有耗電量的值。
• [SR] 強烈建議採用每個程序 UID 回報的 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
• [SR] 強烈建議透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供此電源用量。
• 如果無法將硬體元件的電力用量歸功於應用程式，則必須歸因於硬體元件。

8.5. 一致的效能

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

裝置實作方式：

• [C-0-1] 請務必透過 PowerManager.isSustainedPerformanceModeSupported() API 方法正確回報持續性效能模式的支援。

• 應支援持續效能模式。

如果裝置實作回報支援持續效能模式，即表示：

• [C-1-1] 必須在應用程式要求時，為頂層前景應用程式提供至少 30 分鐘的效能一致等級。
• [C-1-2] 必須遵循 Window.setSustainedPerformanceMode() API 和其他相關 API。

如果裝置的實作項目包含兩個以上的 CPU 核心，就會：

• 您至少應提供一個可由頂層前景應用程式保留的專屬核心。

如果裝置實作支援為頂層前景應用程式保留一個專屬核心，就會執行以下動作：

• [C-2-1] 必須透過 Process.getExclusiveCores() API 方法回報，頂端前景應用程式可保留的專屬核心 ID 數量。
• [C-2-2] 「不得」允許任何使用者空間處理程序，除非應用程式所使用的裝置驅動程式在專屬核心上執行，但允許某些核心程序在必要時執行。

如果裝置實作項目不支援專屬核心，就會：

• [C-3-1] 「必須」透過 Process.getExclusiveCores() API 方法傳回空白清單。

9. 安全性模型相容性

裝置實作方式：

• [C-0-1] 必須實作 Android 開發人員說明文件中 API 安全性和權限參考文件所定義的安全性模型，以符合 Android 平台的安全性模型。

• [C-0-2] 必須支援安裝自行簽署的應用程式，不需要任何第三方/主管機關提供額外權限/憑證。具體來說，相容裝置「必須」支援下列子節所述的安全性機制。

9.1. 權限

裝置實作方式：

• [C-0-1] 必須支援 Android 開發人員說明文件中定義的 Android 權限模型。具體來說，這些權限「必須」強制執行 SDK 說明文件中定義的各項權限，不得省略、變更或忽略任何權限。

• 如果新的權限 ID 字串不在 android.\* 命名空間中，也可以新增其他權限。

• [C-0-2] 只有 PROTECTION_FLAG_PRIVILEGED 的 protectionLevel 權限才能授予應用程式於系統映像檔的特殊權限路徑中預先載入的應用程式，以及每個應用程式中明確加入許可清單的權限子集。Android 開放原始碼計畫實作項目符合這項規定，方法是從 etc/permissions/ 路徑的檔案中讀取及套用每個應用程式的已加入許可清單權限，並使用 system/priv-app 路徑做為特殊權限路徑。

防護等級為危險的權限即為執行階段權限。targetSdkVersion > 22 以上的應用程式在執行階段中提出要求。

裝置實作方式：

• [C-0-3] 必須顯示專屬介面，讓使用者決定是否要授予要求的執行階段權限，以及提供管理執行階段權限的介面。
• [C-0-4] 這兩種使用者介面都只能擇一實作。
• [C-0-5] 除非以下情況，否則「不得」將任何執行階段權限授予預先安裝的應用程式：
• 取得使用者同意後，應用程式才能使用
• 執行階段權限與該意圖模式相關聯，而該模式已將預先安裝的應用程式設為預設處理常式

如果裝置的實作方式包含預先安裝的應用程式，或是您希望允許第三方應用程式存取使用統計資料，可以採取以下做法：

• [SR] 強烈建議提供使用者可存取的機制，用於針對宣告 android.permission.PACKAGE_USAGE_STATS 權限的應用程式提供 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，以回應或撤銷使用統計資料的存取權。

如果裝置實作方式禁止任何應用程式 (包括預先安裝的應用程式) 存取使用統計資料，將採取下列做法：

• [C-1-1] 「必須」仍有處理 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖模式的活動，但「必須」將此模式實作為免人工管理，此行為等同於使用者拒絕存取要求的行為。

9.2. UID 和程序隔離

裝置實作方式：

• [C-0-1] 必須支援 Android 應用程式沙箱模型，在這個模型中，每個應用程式都會以專屬的 Unixstyle UID 執行，並在獨立的程序中運作。
• [C-0-2] 必須支援使用同一個 Linux 使用者 ID 執行多個應用程式，前提是這些應用程式已妥善簽署及建構，詳情請參閱「安全性與權限參考資料」。

9.3. 檔案系統權限

裝置實作方式：

• [C-0-1] 必須支援「安全性和權限參考資料」中定義的 Android 檔案存取權限模型。

9.4. 替代執行環境

裝置實作項目必須維持 Android 安全性和權限模型的一致性，即使這類環境使用的執行階段環境使用其他軟體或技術來執行應用程式，而非 Dalvik 可執行格式或原生程式碼也一樣。換句話說：

• [C-0-1] 替代執行階段「必須」是 Android 應用程式，並遵循標準 Android 安全性模型，如第 9 節所述。

• [C-0-2] 「不得」透過 <uses-permission> 機制，將未在執行階段的 AndroidManifest.xml 檔案中要求權限保護的資源，授予替代執行階段的存取權。

• [C-0-3] 替代執行階段「不得」允許應用程式使用受 Android 權限保護的功能，僅限系統應用程式使用。

• [C-0-4] 替代執行階段「必須」遵守 Android 沙箱模型，並使用替代執行階段安裝應用程式，除非透過共用使用者 ID 和簽署憑證的標準 Android 機制，重複使用裝置上安裝的任何其他應用程式的沙箱。

• [C-0-5] 其他執行階段「不得」啟動、授予或取得與其他 Android 應用程式對應的沙箱存取權。

• [C-0-6] 不得透過超級使用者 (根層級) 或任何其他使用者 ID 的任何權限，啟動、授予其他執行階段，或授予其他應用程式權限。

• [C-0-7] 當裝置實作項目的系統映像檔中包含替代執行階段的 .apk 檔案時，使用的金鑰必須不同於裝置實作過程中用於簽署其他應用程式的金鑰。

• [C-0-8] 安裝應用程式時，替代執行階段「必須」針對應用程式使用的 Android 權限取得使用者同意聲明。

• [C-0-9] 如果應用程式需要使用具有對應 Android 權限的裝置資源 (例如相機、GPS 等)，替代執行階段「必須」告知使用者應用程式將能存取該項資源。

• [C-0-10] 當執行階段環境未以此方式記錄應用程式功能時，執行階段環境在安裝任何使用該執行階段的應用程式時，就「必須」列出執行階段本身持有的所有權限。

• 替代執行階段應透過 PackageManager 安裝應用程式，至獨立的 Android 沙箱 (Linux 使用者 ID 等)。

• 替代執行階段可以提供一個 Android 沙箱，由所有使用替代執行階段的應用程式共用。

9.5. 多使用者支援

Android 提供多位使用者支援功能，並支援完整的使用者隔離功能。

• 裝置實作項目可能可以，但如果將卸除式媒體用於主要外部儲存空間，則不應啟用多位使用者。

如果裝置實作項目包含多位使用者，這些使用者：

• [C-1-1] 必須符合下列多使用者支援服務相關要求。
• [C-1-2] 必須為每個使用者實作與 API 中安全性和權限參考文件中定義的 Android 平台安全性模型一致的安全性模型。
• [C-1-3] 每個使用者執行個體都必須有獨立且獨立的共用應用程式儲存空間 (又稱 /sdcard) 目錄。
• [C-1-4] 必須確保其他使用者所擁有及執行的應用程式無法列出、讀取或寫入任何其他使用者擁有的檔案，即使這兩個使用者的資料都儲存在相同的磁碟區或檔案系統中亦然。
• [C-1-5] 啟用多使用者功能時，如果裝置採用的金鑰只儲存在系統可存取的卸除式媒體上，「必須」加密 SD 卡的內容，前提是裝置實作項目為外部儲存 API 使用卸除式媒體。但由於這會使主機電腦無法讀取媒體，就必須改用 MTP 或類似系統，讓主機電腦存取目前使用者資料。

如果裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，他們會：

• [C-2-1] 必須支援設有限制的個人資料。這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

如果裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能旗標，他們會：

• [C-3-1] 「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

9.6. 付費簡訊警告

Android 支援針對任何傳出的付費簡訊警告使用者。付費簡訊是傳送給向電信業者註冊的服務的簡訊，可能要向使用者收取相關費用。

如果裝置實作項目宣告支援 android.hardware.telephony，就會：

• [C-1-1] 傳送簡訊給裝置上 /data/misc/sms/codes.xml 檔案中定義的規則運算式指定號碼前，必須先警告使用者。上游 Android 開放原始碼計畫提供符合這項規定的實作項目。

9.7. 核心安全性功能

Android Sandbox 內含以下功能：採用安全增強式 Linux (SELinux) 的必要存取控制 (MAC) 系統、seccomp 沙箱，以及 Linux 核心中的其他安全性功能。裝置實作方式：

• [C-0-1] 即使在 Android 架構下已實作 SELinux 或任何其他安全性功能，仍必須維持與現有應用程式的相容性。
• [C-0-2] 當系統偵測到安全性違規行為，並成功遭到 Android 架構以下的安全性功能封鎖時，「不得」顯示使用者介面，但「可能」會在出現未成功安全性的違規行為，導致漏洞遭人成功利用的情況下，顯示使用者介面。
• [C-0-3] 不得將使用者或應用程式開發人員設為 Android 架構下實作的 SELinux 或任何其他安全性功能。
• [C-0-4] 不得允許透過 API (例如 Device 管理 API) 影響其他應用程式的應用程式，設定破壞相容性的政策。
• [C-0-5] 必須將媒體架構分成多個程序，以配合 Android 開放原始碼計畫網站上的所述，縮小各程序的存取權範圍。
• [C-0-6] 「必須」實作核心應用程式沙箱機制，才能使用多執行緒程式中可設定的政策篩選系統呼叫。上游 Android 開放原始碼專案符合這項規定，方法是按照 source.android.com 的「核心設定」一節所述，啟用 seccomp-BPF 搭配執行緒群組同步處理 (TSYNC)。

核心完整性和自我保護功能是 Android 安全性中不可或缺的一環。裝置實作方式：

• [C-0-7] 必須實作核心堆疊緩衝區溢位保護機制。這類機制為 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
• [C-0-8] 必須實施嚴格的核心記憶體防護措施，包括可執行程式碼為唯讀、唯讀資料無法執行且無法寫入，且可寫入資料為不可執行 (例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX)。
• [SR] 強烈建議保留只有初始化期間寫入的核心資料 (例如 __ro_after_init)。
• [SR} 強烈建議使用靜態和動態物件大小邊界檢查使用者空間與核心空間 (例如 CONFIG_HARDENED_USERCOPY) 的副本。
• [SR] 強烈建議不要在核心中執行時 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 執行使用者空間記憶體。
• [SR] 強烈建議不要在一般使用者副本存取 API (例如硬體 PAN 或 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 以外的核心中，讀取或寫入使用者空間記憶體。
• [SR] 強烈建議採用隨機化核心程式碼和記憶體的配置，避免曝光可能導致隨機化的風險 (例如透過 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 套用系統啟動載入程式熵的 CONFIG_RANDOMIZE_BASE)。

如果裝置實作項目使用 Linux 核心，則：

• [C-1-1] 必須實作 SELinux。
• [C-1-2] 必須將 SELinux 設為「全域強制執行模式」。
• [C-1-3] 「必須」在強制執行模式下設定所有網域。不得使用寬鬆模式網域，包括裝置/廠商的專屬網域。
• [C-1-4] 「不得」修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 資料夾中存在的規則，以及這項政策「必須」針對 Android 開放原始碼計畫 SELinux 網域以及裝置/供應商專屬網域，編譯所有絕不允許的規則。
• 應保留上游 Android 開放原始碼計畫「system/sepolicy」資料夾內提供的預設 SELinux 政策，並只針對自己的裝置專屬設定再加入這項政策。

如果裝置實作項目使用 Linux 以外的核心，就會發生以下情形：

• [C-2-1] 必須使用與 SELinux 同等的必要存取權控管系統。

9.8. 隱私權

9.8.1。使用記錄

Android 會儲存使用者選項的記錄，並透過 UsageStatsManager 管理這類記錄。

裝置實作方式：

• [C-0-1] 請務必為這類使用者記錄保留合理的保留期限。
• [SR] 強烈建議將 Android 開放原始碼計畫實作項目的預設設定保留 14 天的保留期限。

9.8.2。錄製

如果裝置實作包含的系統功能會擷取畫面上顯示的內容，並/或記錄裝置上播放的音訊串流，那麼裝置就會執行以下動作：

• [C-1-1] 啟用此功能並主動擷取/錄製時，「必須」持續為使用者提供通知。

如果裝置實作項目包含可立即啟用的元件，且能錄製環境音訊來推斷使用者的情境實用資訊，就會採取以下做法：

• [C-2-1] 除非已取得使用者明確同意，否則「不得」保存在裝置端的永久儲存空間中，或將所錄製的原始音訊，或任何可轉換回原始音訊或接近傳真格式的任何格式傳輸。

9.8.3. 連線

如果裝置的實作具備支援 USB 週邊裝置模式的 USB 連接埠，就會：

• [C-1-1] 必須顯示使用者介面要求使用者同意，才能允許透過 USB 連接埠存取共用儲存裝置的內容。

9.8.4。網路流量

裝置實作方式：

• [C-0-1] 必須預先安裝系統信任憑證授權單位 (CA) 儲存庫的相同根憑證，當做上游 Android 開放原始碼專案中提供的。
• [C-0-2] 出貨時，請務必提供空白的使用者根 CA 商店。
• [C-0-3] 加入使用者根 CA 時，「必須」向使用者顯示警告，指出可能監控網路流量。

如果裝置流量是透過 VPN 轉送，系統會實作裝置：

• [C-1-1] 請務必向使用者顯示警告，指出下列其中一項做法：
  • 該網路流量可能會受到監控。
  • 透過提供 VPN 的特定 VPN 應用程式轉送網路流量。

如果裝置的實作機制預設為立即啟用，並透過 Proxy 伺服器或 VPN 閘道轉送網路流量 (例如預先載入已授予 android.permission.CONTROL_VPN 的 VPN 服務)，就會：

• [C-2-1] 必須徵得使用者同意，才能啟用該機制；但如果裝置政策控制器透過 DevicePolicyManager.setAlwaysOnVpnPackage() 啟用 VPN，則使用者不需另外提供同意聲明，但只有收到通知。

9.9. 資料儲存加密

如果裝置實作支援安全螢幕鎖定 (如第 9.11.1 節所述)，您可以：

• [C-1-1] 如果裝置是永久且不可移除的零件，「必須」支援應用程式私人資料 (/data partition) 以及應用程式共用儲存空間分區 (/sdcard partition) 的資料儲存加密功能。

如果裝置的實作方式支援第 9.11.1 節所述的安全螢幕鎖定功能，且支援以進階加密標準 (AES) 加密效能為 50 MiB/秒執行資料儲存加密作業，就會發生以下情形：

• [C-2-1] 在使用者完成開箱設定體驗時，根據預設，「必須」啟用資料儲存加密功能。如果裝置實作裝置已由搭載舊版 Android 且預設停用加密功能的 Android 版本啟動，這類裝置便無法透過系統軟體更新滿足相關規定，因此「可能」符合豁免資格。

• 應導入檔案型加密 (FBE)，符合上述資料儲存空間加密規定。

9.9.1。直接啟動

裝置實作方式：

• [C-0-1] 即使不支援儲存空間加密，仍必須實作直接啟動模式 API。

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED 意圖仍「必須」播送向直接啟動通知的應用程式傳送裝置加密 (DE) 和憑證加密 (CE) 儲存位置可供使用者使用。

9.9.2。檔案型加密

如果裝置實作支援 FBE，就會執行以下動作：

• [C-1-1] 必須啟動，且無須向使用者提出憑證驗證要求，且允許直接啟動感知功能應用程式在 ACTION_LOCKED_BOOT_COMPLETED 訊息廣播後存取裝置加密 (DE) 儲存空間。
• [C-1-2]「必須」僅允許使用者提供憑證 (例如密碼、PIN 碼、解鎖圖案或指紋) 並廣播 ACTION_USER_UNLOCKED 訊息，藉此解鎖裝置後，存取憑證加密 (CE) 儲存空間。
• [C-1-3] 「不得」在沒有使用者提供憑證的情況下，以任何方式解鎖 CE 保護的儲存空間。
• [C-1-4] 必須支援驗證開機程序，並確保 DE 金鑰經過加密編譯且會繫結至裝置的硬體信任根層級。
• [C-1-5] 必須支援使用 AES 加密檔案內容，並在 XTS 模式下使用 256 位元金鑰長度加密檔案內容。

• [C-1-6] 必須支援使用 AES，將檔案名稱加密，且金鑰長度為 256 位元 (CBC-CTS 模式)。

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

• [C-1-7] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。

• [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
• [C-1-9] 使用者未指定螢幕鎖定憑證時，CE 金鑰必須繫結至預設密碼。

• [C-1-10] 不得重複，換言之，也就是沒有任何使用者的 CE 或 DE 金鑰與其他使用者的 CE 或 DE 金鑰相符。

• [C-1-11] 預設「必須」使用強制支援的加密方式、金鑰長度和模式。

• 應讓預先載入的必要應用程式 (例如鬧鐘、手機、Messenger) 感知直接啟動功能。

• 「可能」支援檔案內容和檔案名稱加密的替代加密方式、金鑰長度和模式。

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

9.9.3. 全磁碟加密

如果裝置的實作支援完整磁碟加密 (FDE)，就會：

• [C-1-1] 必須搭配使用 AES 與 128 位元 (或更高) 的金鑰，以及設計用於儲存資料的模式 (例如 AES-XTS、AES-CBC-ESSIV)。
• [C-1-2] 「一律」必須使用預設密碼來包裝加密金鑰，且「絕對不要」在未加密的情況下，將加密金鑰寫入儲存空間。
• [C-1-3] 除非處於使用中的狀態，且鎖定螢幕憑證是以緩慢的延展演算法 (例如 PBKDF2 或 scrypt) 延伸，除非處於使用中的狀態，否則「必須」讓使用者能夠透過 AES 將加密金鑰加密。
• [C-1-4] 上述預設密碼延展演算法「必須」在使用者未指定螢幕鎖定憑證，或是停用密碼進行加密功能，且裝置提供硬體支援的 KeyStore 的情況下，以加密方式繫結至該 KeyStore。
• [C-1-5] 「不得」將加密金鑰從裝置傳送出去 (即便是以使用者密碼和/或硬體繫結金鑰包裝也一樣)。

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

9.10。裝置完整性

下列規定可確保裝置完整性，清楚掌握裝置完整性。裝置實作方式：

• [C-0-1] 無論系統啟動載入程式狀態是否允許刷新系統映像檔，都必須透過系統 API 方法 PersistentDataBlockManager.getFlashLockState() 正確回報。FLASH_LOCK_UNKNOWN 狀態會保留給從舊版 Android 升級，且這個新的系統 API 方法不存在的裝置實作。

驗證開機程序是保證裝置軟體完整性的功能。如果裝置實作支援這項功能：

• [C-1-1] 必須宣告平台功能旗標 android.software.verified_boot。
• [C-1-2] 必須在每個啟動序列中執行驗證作業。
• [C-1-3] 「必須」使用不可變更的硬體金鑰 (也就是信任根) 啟動驗證程序，並往至系統分區為止。
• [C-1-4] 必須導入每個驗證階段，檢查下一階段中所有位元組的完整性和真實性，再在下一個階段執行程式碼。
• [C-1-5] 「必須」根據 NIST 現行的雜湊演算法 (SHA-256) 和公開金鑰大小 (RSA-2048) 建議，使用驗證演算法做為現行標準。
• [C-1-6] 系統驗證失敗時，「不得」允許完成啟動；除非使用者同意嘗試啟動，否則「一律不得使用」來自未通過驗證儲存區塊的資料。
• [C-1-7] 除非使用者已明確解鎖系統啟動載入程式，否則「不得」允許修改裝置上的已驗證分區。
• [SR] 如果裝置上有多個獨立晶片 (例如無線電、專用影像處理器)，「強烈建議」每個晶片的啟動程序，以便在啟動時驗證每個階段。
• [SR] 強烈建議使用防竄改儲存空間：當系統啟動載入程式已解鎖時。防竄改儲存空間是指系統啟動載入程式可偵測儲存體是否遭到 HLOS (高階作業系統) 竄改。
• [SR] 強烈建議使用者在使用裝置時提示使用裝置，並要求使用者進行實體確認後，才能從系統啟動載入程式鎖定模式轉換至系統啟動載入程式解鎖模式。
• [SR] 強烈建議為 HLOS 導入復原保護機制 (例如啟動、系統分區)，並使用防竄改儲存空間儲存中繼資料，用來判斷系統允許的最小 OS 版本。
• 「應該」為任何裝有永久韌體 (例如數據機、相機) 的元件導入復原保護機制，並「應使用防竄改儲存空間」儲存中繼資料，以判斷系統規定的最低允許版本。

上游 Android 開放原始碼計畫是在 external/avb/ 存放區中提供這項功能的偏好實作方式，可以整合至用於載入 Android 的系統啟動載入程式。

在 50 MiB/秒以上，具備進階加密標準 (AES) 加密效能的裝置實作項目：

• [C-2-1] 必須支援驗證開機程序，確保裝置完整性。

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

9.11. 金鑰和憑證

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

• [C-0-1] 至少可匯入 8,192 組金鑰。
• [C-0-2] 螢幕鎖定驗證次數「必須」嘗試限制頻率，且「必須」使用指數輪詢演算法。如果嘗試失敗超過 150 次，則每次重試的延遲時間至少應為 24 小時。
• 不應限制可產生的金鑰數量

如果裝置實作支援安全螢幕鎖定，它會：

• [C-1-1] 必須使用安全的硬體備份 KeyStore 實作。
• [C-1-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密編譯演算法以及 MD5、SHA1 及 SHA-2 系列雜湊函式，以便在與核心以上執行的程式碼安全隔離的區域中，正確支援 Android KeyStore 系統支援的演算法。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。上游 Android 開放原始碼計畫 (AOSP) 採用 Trusty 實作項目符合這項規定，但另外，以 ARM TrustZone 解決方案或第三方審查的安全實作方式為採用適當的管理程序隔離措施。
• [C-1-3] 「必須」在獨立的執行環境中執行螢幕鎖定驗證，且僅在成功時允許使用驗證繫結金鑰。上游 Android 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，滿足這項需求。
• [C-1-4] 必須支援金鑰認證，因為認證簽署金鑰受到安全硬體保護，而簽署金鑰是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非特定 SKU 至少產生了 100,000 個單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰。

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

9.11.1. 安全螢幕鎖定

如果裝置實作項目具有安全螢幕鎖定畫面，且包含一或多個實作 TrustAgentService System API 的信任代理程式，則會收到：

• [C-1-1] 必須在「設定」和「螢幕鎖定畫面」使用者介面中，向使用者說明螢幕自動鎖定已延後，或是信任的代理程式能解鎖螢幕鎖定的情況。Android 開放原始碼計畫符合相關規定，為「自動鎖定設定」和「電源鍵立即鎖定設定」選單顯示文字說明，並在螢幕鎖定畫面上顯示可區分的圖示。
• [C-1-2] 必須遵循並完整實作 DevicePolicyManager 類別中的所有信任代理程式 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常數。
• [C-1-3] 「不得」在做為主要個人裝置 (例如手持裝置) 的裝置上完整實作 TrustAgentService.addEscrowToken() 函式，但「不得」在一般共用的裝置上完整實作該功能。
• [C-1-4] 必須先加密 TrustAgentService.addEscrowToken() 新增的權杖，才能將權杖儲存在裝置上。
• [C-1-5] 「請勿」在裝置上儲存加密金鑰。
• [C-1-6] 啟用託管權杖以解密資料儲存空間之前，必須告知使用者安全性方面的影響。

如果裝置實作新增或修改用於解鎖螢幕鎖定的驗證方法，若要將這類驗證方法視為安全的螢幕鎖定方式，會執行以下動作：

• [C-2-1] 必須按照「要求驗證使用者金鑰」一節所述，為使用者驗證方式。
• [C-2-2] 必須解鎖第三方開發人員應用程式的所有金鑰，才能在使用者解鎖安全螢幕鎖定畫面時使用。舉例來說，第三方開發人員應用程式「必須」能透過相關 API (例如 createConfirmDeviceCredentialIntent 和 setUserAuthenticationRequired) 提供所有金鑰。

如果裝置實作根據已知的密鑰，新增或修改用於解鎖螢幕鎖定的驗證方式，請將這類驗證方法視為安全的螢幕鎖定方式，如下所示：

• [C-3-1] 允許的最短輸入長度熵必須大於 10 位元。
• [C-3-2] 所有可能輸入值的最大熵必須大於 18 位元。
• [C-3-3] 不得取代 Android 開放原始碼計畫中提供的任何現有驗證方法 (PIN 碼、圖案、密碼)。
• [C-3-4] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策，且品質常數比 PASSWORD_QUALITY_SOMETHING 更嚴格，「必須」停用。

如果裝置實作方式新增或修改以實體權杖或地點為解鎖螢幕的驗證方法，以便將這類驗證方法視為安全的螢幕鎖定方式，可執行以下動作：

• [C-4-1] 必須設有備用機制，才能使用主要驗證方法；這些驗證方法是以已知的密鑰為基礎，並且符合安全螢幕鎖定的要求。
• [C-4-2] 必須停用，且只有在裝置政策控制器 (DPC) 應用程式使用 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法 (品質常數比 PASSWORD_QUALITY_UNSPECIFIED 嚴格設定政策) 時，才允許主要驗證機制解鎖螢幕。
• [C-4-3] 必須至少每 72 小時要求使用者進行主要驗證 (例如 PIN 碼、解鎖圖案、密碼) 驗證一次。

如果裝置實作方式新增或修改根據生物特徵辨識的驗證方法，將螢幕鎖定方式解鎖，那麼若要將這類驗證方法視為安全的螢幕鎖定方式，可執行以下動作：

• [C-5-1] 必須設有備用機制，才能使用主要驗證方法；這些驗證方法是以已知的密鑰為基礎，並且符合安全螢幕鎖定的要求。
• [C-5-2] 必須停用，並且僅允許在 Device Policy Controller (DPC) 應用程式透過呼叫 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) 方法設定 keguard 功能政策時，允許主要驗證機制解鎖螢幕。
• [C-5-3] 錯誤的接受率不得低於或高於指紋感應器所需上限 (如第 7.3.10 節所述)，否則「必須」停用，且只有在裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策時，使用比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更嚴格的密碼品質政策，才能解鎖螢幕。
• [C-5-4] 必須至少每 72 小時要求使用者進行主要驗證 (例如 PIN 碼、解鎖圖案、密碼) 驗證一次。

如果裝置實作新增或修改驗證方法來解鎖螢幕鎖定，且使用者會使用這類驗證方法解鎖鍵盤保護功能，但系統不會將其視為安全螢幕鎖定，則會發生以下情況：

• [C-6-1] 必須針對 KeyguardManager.isKeyguardSecure() 和 KeyguardManager.isDeviceSecure() 方法傳回 false。
• [C-6-2] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策，且品質常數比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格，「必須」停用。
• [C-6-3] 「不得」重設 DevicePolicyManager.setPasswordExpirationTimeout() 設定的密碼到期計時器。
• [C-6-4] 如果應用程式已呼叫 KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)，則「不得」驗證 KeyStore 存取權。

9.12. 資料刪除

所有裝置實作：

• [C-0-1] 「必須」為使用者提供執行「恢復原廠設定」的機制。
• [C-0-2] 「必須」刪除所有使用者產生的資料。也就是說，除了下列來源外的所有資料：
  • 系統映像檔
  • 系統映像檔所需的任何作業系統檔案
• [C-0-3] 請務必以符合 NIST SP800-88 等相關業界標準的方式刪除資料。
• [C-0-4] 由主要使用者的 Device Policy Controller 應用程式呼叫 DevicePolicyManager.wipeData() API 時，必須觸發上述「恢復原廠設定」程序。
• 可能提供快速抹除資料的選項，方便您只執行邏輯資料清除作業。

9.13. 安全啟動模式

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

裝置實作方式如下：

• [SR] 強烈建議你實作安全啟動模式。

如果裝置實作了安全啟動模式，就會執行以下動作：

• [C-1-1] 「必須」為使用者提供進入安全啟動模式的選項，使安裝在裝置上的第三方應用程式無法中斷服務，但第三方應用程式為 Device Policy Controller 且將 UserManager.DISALLOW_SAFE_BOOT 旗標設為 true 時除外。

• [C-1-2] 必須讓使用者能夠在安全模式下解除安裝任何第三方應用程式。

• 應為使用者提供與正常啟動不同的工作流程，從啟動選單進入安全啟動模式。

9.14。汽車車輛系統隔離

Android Automotive 裝置應使用車輛 HAL 透過車輛網路 (例如 CAN 公車) 收發訊息，藉此與重要的車輛子系統交換資料。

您可以在 Android 架構層下方實作安全性功能，防範與這些子系統惡意或無意間的互動，進而保護資料交換作業。

10. 軟體相容性測試

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

10.1. Compatibility Test Suite

裝置實作方式：

• [C-0-1] 必須利用裝置上的最終運送軟體，通過 Android 開放原始碼計畫提供的 Android Compatibility Test Suite (CTS)。

• [C-0-2] 必須確保 CTS 中不明確，以及參照原始碼中任何部分的內容重新導入時，都確保相容。

CTS 的設計宗旨是在實際裝置上執行。和任何軟體一樣，CTS 本身可能包含錯誤。CTS 的版本與此相容性定義無關，且可能針對 Android 8.0 發布多個 CTS 修訂版本。

裝置實作方式：

• [C-0-3] 必須通過裝置軟體完成時可用的最新 CTS 版本。

• 請盡可能使用 Android 開放原始碼樹狀結構中的參考實作方式。

10.2. CTS 驗證器

Compatibility Test Suite 隨附 CTS 驗證器，主要功能是供真人作業人員測試，可測試自動系統無法測試的功能，例如相機和感應器的正確功能。

裝置實作方式：

• [C-0-1] 「必須」正確執行 CTS 驗證器中的所有適用案例。

CTS Verifier 可針對多種硬體進行測試，包括部分為選用硬體。

裝置實作方式：

• [C-0-2] 必須通過自家硬體的所有測試。舉例來說，如果裝置擁有加速計，則「必須」能在 CTS 驗證器中正確執行加速計測試案例。

您或許可以略過或略過這份相容性定義說明文件中註明的選用功能測試案例。

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

11. 可更新的軟體

• [C-0-1] 裝置實作「必須」提供取代整個系統軟體的機制。該機制不需執行「即時」升級，也就是說，裝置必須重新啟動。

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

• 「無線更新」(OTA) 會在重新啟動後使用離線更新功能。
• 從主機電腦透過 USB 進行「網路共用」更新。

• 重新啟動後即可「離線」更新，並使用卸除式儲存空間中的檔案進行更新。

• [C-0-2] 使用的更新機制「必須」支援更新，但不會清除使用者資料。也就是說，更新機制「必須」保留應用程式的私人資料和應用程式分享的資料。請注意，Android 上游軟體含有可滿足這項規定的更新機制。

如果裝置的實作支援非計量付費數據連線 (例如 802.11 或藍牙 PAN (個人區域網路) 設定檔)，則支援以下情況：

• [C-1-1] 必須支援在重新啟動時透過離線更新進行 OTA 下載。

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

此外，裝置實作項目必須支援 A/B 系統更新。Android 開放原始碼計畫利用啟動控制項 HAL 實作這項功能。

如果在裝置實作項目中發現錯誤，但其實產品生命週期曾與 Android 相容性團隊諮詢，確認會影響第三方應用程式相容性，則執行下列步驟：

• [C-2-1] 裝置實作者「必須」透過能根據上述機制套用的軟體更新來修正錯誤。

Android 內建可讓裝置擁有者應用程式 (如有) 控制系統更新安裝的功能。如果裝置的系統更新子系統回報 android.software.device_admin，就會：

• [C-3-1] 必須實作 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 論壇，詢問有關文件未涵蓋的任何問題，或提出任何問題。