Android 11 相容性定義

1. 簡介

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

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

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

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

如果這項定義或第 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 實作
    • W：Android Watch 實作
    • 分頁：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 裝置的實作方式符合下列所有條件，就會歸類為手持裝置：

  • 使用可提供行動性的電源 (例如電池)。
  • 實體對角線螢幕尺寸應介於 3.3 吋 (3.3 吋) 到 2.5 吋 (適用於 Android 11 以下版本的 Android 裝置) 到 8 吋範圍內。

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

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

2.2.1. 硬體

手持裝置實作方式：

  • [7.1.1.1/H-0-1] 必須搭載至少一個與 Android 相容的螢幕，且符合本文件所述的所有規定。
  • [7.1.1.3/H-SR] 極力建議您為使用者提供變更顯示大小 (螢幕密度) 的選項。

如果手持裝置實作支援軟體螢幕旋轉功能，可以：

  • [7.1.1.1/H-1-1]* 請配合第三方應用程式使用的邏輯螢幕設計至少 2 吋，長邊為 2.7 吋以上。如果裝置在本文件的 API 級別之前啟動，則不受這項要求的限制。

如果手持裝置實作不支援軟體螢幕旋轉功能，則表示：

  • [7.1.1.1/H-2-1]* 請將適用於第三方應用程式的邏輯畫面設為至少 2.7 吋的短邊。如果裝置在本文件的 API 級別之前啟動，則不受這項要求的限制。

如果手持裝置實作可透過 Configuration.isScreenHdr() 支援高動態範圍螢幕，則表示：

  • [7.1.4.5/H-1-1] 必須宣傳對 EGL_EXT_gl_colorspace_bt2020_pq、EGL_EXT_surface_SMPTE2086_metadata、EGL_EXT_surface_CTA861_3_metadata、VK_EXT_swapchain_colorspace 及 VK_EXT_hdr_metadata 擴充功能的支援。

手持裝置實作方式：

  • [7.1.4.6/H-0-1] 必須回報裝置是否支援透過系統屬性 graphics.gpu.profiler.support 進行 GPU 剖析功能。

如果手持裝置實作項目透過系統屬性 graphics.gpu.profiler.support 宣告支援，則程式碼會：

手持裝置實作方式：

  • [7.1.5/H-0-1] 必須支援上游 Android 開放原始碼所實作的舊版應用程式相容性模式。也就是說，裝置實作「不得」變更啟用相容性模式時的觸發條件或門檻，「不得」變更相容性模式本身的行為。
  • [7.2.1/H-0-1] 必須支援第三方輸入法編輯器 (IME) 應用程式。
  • [7.2.3/H-0-3] 凡是在提供主畫面且與 Android 相容的螢幕上，都必須提供主畫面功能。
  • [7.2.3/H-0-4] 「必須」在所有與 Android 相容螢幕上以及至少一種 Android 相容顯示器上，提供返回函式。
  • [7.2.3/H-0-2] 必須將返回函式的正常和長按事件 (KEYCODE_BACK) 同時傳送至前景應用程式。這些事件「不得」由系統使用，且可由 Android 裝置以外的系統 (例如，連接 Android 裝置的外接硬體鍵盤) 觸發。
  • [7.2.4/H-0-1] 必須支援觸控螢幕輸入。
  • [7.2.4/H-SR] 強烈推薦啟動使用者選取的輔助應用程式 (也就是實作 VoiceInteractionService 的應用程式)；如果前景活動不處理這些長按事件，則當您長按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 時，則執行處理 ACTION_ASSIST 的活動。
  • [7.3.1/H-SR] 強烈建議加入 3 軸式加速度計。

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

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

如果手持裝置實作包含 GPS/GNSS 接收器，並透過 android.hardware.location.gps 功能旗標向應用程式回報功能，就會執行以下動作：

  • [7.3.3/H-2-1] 請務必在找到 GNSS 測量結果後立即回報資料，包括根據 GPS/GNSS 計算得出的位置資料。
  • [7.3.3/H-2-2] 必須回報 GNSS 虛擬範圍和虛擬範圍比率；在判斷地點後，如果是靜止或移動的加速度低於 0.2 公尺的每秒平方公尺，就足以在每秒 20% 以內，且速度至少在每秒 0.2 公尺以內。

如果手持裝置實作中包含 3 軸式迴轉儀，請按照以下步驟操作：

  • [7.3.4/H-3-1] 事件的回報頻率必須至少為 100 Hz。
  • [7.3.4/H-3-2] 必須能夠測量每秒高達 1000 度的螢幕方向變化。

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

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

手持裝置實作方式：

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

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

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

如果手持裝置實作項目包含使用 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 列出功能的邏輯相機裝置，請注意：

  • [7.5.4/H-1-1] 預設必須符合一般視野 (FOV)，且必須介於 50 到 90 度之間。

手持裝置實作方式：

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

如果手持裝置實作項目宣告僅支援 32 位元 ABI：

  • [7.6.1/H-1-1] 如果預設螢幕使用最高 qHD (例如 FWVGA)，核心和使用者空間可用的記憶體必須至少為 416 MB。

  • [7.6.1/H-2-1] 如果預設顯示螢幕採用最高 HD+ 的 framebuffer 解析度 (例如 HD、WSVGA)，核心和使用者空間可用的記憶體「必須」至少為 592 MB。

  • [7.6.1/H-3-1] 如果預設螢幕使用最高 FHD (例如 WSXGA+) 的影格緩衝區解析度，核心和使用者空間的可用記憶體必須至少為 896 MB。

  • [7.6.1/H-4-1] 如果預設顯示畫面採用最高 QHD (例如 QWXGA) 的影格緩衝區解析度，核心和使用者空間的可用記憶體大小「必須」為至少 1344 MB。

如果手持裝置實作項目宣告支援任何 64 位元 ABI (無論是否為 32 位元 ABI)：

  • [7.6.1/H-5-1] 如果預設螢幕使用最高 qHD (例如 FWVGA)，核心和使用者空間可用的記憶體必須至少為 816 MB。

  • [7.6.1/H-6-1] 如果預設顯示螢幕採用最高 HD+ 的 framebuffer 解析度 (例如 HD、WSVGA)，核心和使用者空間可用的記憶體「必須」為至少 944 MB。

  • [7.6.1/H-7-1] 如果預設顯示畫面使用最高 FHD (例如 WSXGA+) 的影格緩衝區解析度，核心和使用者空間的可用記憶體必須至少為 1280 MB。

  • [7.6.1/H-8-1] 如果預設顯示畫面採用最高 QHD (例如 QWXGA) 的影格緩衝區解析度，核心和使用者空間的可用記憶體必須至少為 1824 MB。

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

如果手持裝置實作項目所含的記憶體容量少於或等於 1 GB，可供核心和使用者空間使用，就會執行以下動作：

  • [7.6.1/H-9-1] 必須宣告功能標記 android.hardware.ram.low。
  • [7.6.1/H-9-2] 至少須有 1.1 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。

如果手持裝置實作包含超過 1 GB 可用記憶體，供核心和使用者空間使用，程式碼會執行以下動作：

  • [7.6.1/H-10-1] 至少須有 4 GB 的非揮發性儲存空間，才能存放應用程式私人資料 (又稱「/data」分區)。
  • 應宣告功能旗標 android.hardware.ram.normal。

手持裝置實作方式：

  • [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。

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

手持裝置實作方式：

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

如果手持裝置實作能滿足支援 VR 模式的所有效能需求，並提供相關支援，那麼：

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

如果手持裝置實作在主機模式中加入一或多個 USB-C 連接埠並實作 (USB 音訊類別)，除了第 7.7.2 節的規定外，還包括：

  • [7.8.2.2/H-1-1] 「必須」提供下列 HID 代碼的軟體對應表：
功能 對應 背景資訊 行為
A HID 用量頁面：0x0C
HID 用量：0x0CD
核心金鑰：KEY_PLAYPAUSE
Android 金鑰：KEYCODE_MEDIA_PLAY_PAUSE 		媒體播放 輸入：短暫按下
輸出：播放或暫停
輸入內容：長按
輸出：啟動語音指令
傳送：如果裝置處於鎖定狀態或螢幕關閉，則系統會傳送 android.speech.action.VOICE_SEARCH_HANDS_FREE。否則會傳送 android.speech.RecognizerIntent.ACTION_WEB_SEARCH。
來電 輸入內容：短暫按下
輸出：接聽來電
輸入端：長按
輸出：拒接來電
通話中 輸入內容：短暫按下
輸出：結束通話
輸入端：長按
輸出：將麥克風設為靜音或取消靜音
B HID 用量頁面：0x0C
HID 用量：0x0E9
核心金鑰：KEY_VOLUMEUP
Android 金鑰：VOLUME_UP 		媒體播放、通話中 輸入端：短暫或長按
輸出：調高系統或耳機的音量
C HID 用量頁面：0x0C
HID 用量：0x0EA
核心金鑰：KEY_VOLUMEDOWN
Android 金鑰：VOLUME_DOWN 		媒體播放、通話中 輸入端：短暫或長按
輸出：調低系統或耳機的音量
D HID 用量頁面：0x0C
HID 用量：0x0CF
核心金鑰：KEY_VOICECOMMAND
Android 金鑰：KEYCODE_VOICE_ASSIST 		全部。可以在任何執行個體中觸發。 輸入內容：長按或長按
輸出：啟動語音指令
  • [7.8.2.2/H-1-2] 插入插頭時必須觸發 ACTION_HEADSET_PLUG，但必須在 USB 音訊介面和端點正確列舉後，才能識別已連接的端子類型。

偵測到 USB 音訊端子類型 0x0302 時，會：

  • [7.8.2.2/H-2-1] 必須播送 Intent ACTION_HEADSET_PLUG，並將「麥克風」額外設定設為 0。

偵測到 USB 音訊端子類型 0x0402 時，會：

  • [7.8.2.2/H-3-1] 必須播送 Intent ACTION_HEADSET_PLUG，並將「麥克風」額外設定設為 1。

連接 USB 週邊裝置時呼叫 API AudioManager.getDevices() 時，系統會執行以下動作：

  • [7.8.2.2/H-4-1] 如果 USB 音訊終端機類型欄位為 0x0302，則「必須」列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，以及 isSink() 角色。

  • [7.8.2.2/H-4-2] 如果 USB 音訊終端機類型欄位為 0x0402，則「必須」列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，以及 isSink() 角色。

  • [7.8.2.2/H-4-3] 如果 USB 音訊終端機類型欄位為 0x0402，「必須」列出 AudioDeviceInfo.TYPE_USB_HEADSET 類型的裝置，以及 isSource() 角色 isSource()。

  • [7.8.2.2/H-4-4] 如果 USB 音訊終端機類型欄位為 0x603，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置，以及 isSink() 角色。

  • [7.8.2.2/H-4-5] 如果 USB 音訊終端機類型欄位為 0x604，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置和 isSource() 角色。

  • [7.8.2.2/H-4-6] 如果 USB 音訊終端機類型欄位為 0x400，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置，以及 isSink() 角色。

  • [7.8.2.2/H-4-7] 如果 USB 音訊終端機類型欄位為 0x400，則「必須」列出 AudioDeviceInfo.TYPE_USB_DEVICE 類型的裝置和 isSource() 角色。

  • [7.8.2.2/H-SR] 強烈推薦在 USB-C 音訊週邊裝置連線時執行 USB 描述元列舉、在 1000 毫秒內識別終端機類型和廣播意圖 ACTION_HEADSET_PLUG。

如果手持裝置實作時包含至少一個觸覺回饋器，可能：

線性共振致動器 (LRA) 是單一的大規模彈簧系統，可產生強烈的共鳴頻率，其中質量會依照期望的動作方向轉譯。

如果手持裝置實作包含至少一項線性共振致動器，可能：

  • [7.10/H]* 應在直向螢幕方向的 X 軸上移動觸覺回饋器。

如果手持裝置採用的觸覺回饋器是 X 軸線性共振致動器 (LRA)，他們會：

  • [7.10/H-SR]* 極力建議讓 X 軸 LRA 的振動頻率低於 200 Hz。

如果手持裝置實作方式遵循觸覺常數對應，可使用：

2.2.2. 多媒體

手持裝置實作項目「必須」支援下列音訊編碼和解碼格式，並將這些格式提供給第三方應用程式：

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

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

  • [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.8.4/H-SR] 強烈建議使用長按 HOME 鍵做為指定的互動，以啟動輔助應用程式 (如第 7.2.3 節所述)。必須啟動使用者選取的輔助應用程式，也就是實作 VoiceInteractionService 的應用程式，或處理 ACTION_ASSIST 意圖的活動。

如果手持裝置實作支援 conversation notifications，並將這類通知歸到另一個部分，與快訊和非對話通知不發出對話，請執行以下動作：

  • [3.8.4/H-1-1]* 「必須」在非對話通知之前顯示對話通知，但持續性前景服務通知和 importance:high 通知除外。

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

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

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

  • [3.9/H-1-1] 必須導入 Android SDK 說明文件中定義的所有裝置管理政策。
  • [3.9/H-1-2] 「必須」透過 android.software.managed_users 功能旗標宣告支援受管理的設定檔，但當裝置設定成低的 RAM 裝置時，則會將自身回報為低 RAM 裝置，或讓系統將內部 (不可移除) 儲存空間分配為共用儲存空間。

如果手持裝置實作項目支援 ControlsProviderService 和 Control API，並允許第三方應用程式發布裝置控制項，請按照下列步驟操作：

  • [3.8.16/H-1-1] 必須宣告功能旗標 android.software.controls，並將其設為 true。
  • [3.8.16/H-1-2] 必須為使用者提供預設負擔，讓他們能透過 ControlsProviderService 和 Control API 透過第三方應用程式註冊的控制項，新增、編輯、選取及操作使用者常用的裝置控制選項。
  • [3.8.16/H-1-3] 必須在預設啟動器的三次互動中，提供使用者預設用途的存取權。
  • [3.8.16/H-1-4] 「必須」正確顯示使用者可透過 ControlsProviderService API 以及 Control API 提供控制項的每個第三方應用程式的名稱和圖示。

相反地，如果手持裝置實作並未實作這類控制選項，則執行以下動作：

手持裝置實作方式：

  • [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.16/H-1-1] 必須支援隨附裝置配對功能。

如果系統以手勢動作的形式提供導覽功能：

  • [7.2.3/H] 主畫面功能的手勢辨識區域高度應與螢幕底部相距 32 dp 以上。

如果手持裝置實作以手勢做為手勢，從螢幕左側或右側邊緣移動：

  • [7.2.3/H-0-1] 導覽函式的手勢區域每邊寬度必須小於 40 dp。根據預設，手勢區域的寬度應為 24 dp。

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 的隨機讀取效能。

如果手持裝置實作包含改善 Android 開放原始碼計畫提供的裝置電源管理功能，或擴充 Android 開放原始碼計畫包含的功能，就會：

  • [8.3/H-1-1] 「必須」提供使用者預設用途，才能啟用和停用省電模式功能。
  • [8.3/H-1-2] 「必須」提供使用者預設用途，才能顯示不受應用程式待命和打盹省電模式限制的所有應用程式。

手持裝置實作方式：

  • [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] 無法將硬體元件的電力用量歸功給應用程式時，應歸於硬體元件本身。

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

2.2.5。安全性模型

手持裝置實作方式：

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

手持裝置實作 (* 不適用於平板電腦)：

  • [9.11/H-0-2]* 必須使用獨立的執行環境備份 KeyStore 實作。
  • [9.11/H-0-3]* 必須實作 RSA、AES、ECDSA 和 HMAC 加密編譯演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在安全隔離的區域中，妥善支援 Android KeyStore 系統支援的演算法，並與核心以上執行的程式碼分開支援。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。上游 Android 開放原始碼計畫 (AOSP) 採用 Trusty 實作項目符合這項規定，但另外，以 ARM TrustZone 解決方案或第三方審查的安全實作方式為採用適當的管理程序隔離措施。
  • [9.11/H-0-4]* 「必須」在獨立的執行環境中執行螢幕鎖定驗證，且僅在成功時允許使用驗證繫結金鑰。螢幕鎖定憑證的儲存方式「必須」僅允許獨立的執行環境執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，滿足這項需求。
  • [9.11/H-0-5]* 必須支援金鑰認證，因為認證簽署金鑰受到安全硬體保護，而簽署金鑰是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非特定 SKU 至少產生了 100,000 個單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰。

請注意，如果裝置實作項目已在較舊的 Android 版本上啟動，則此類裝置不必具備受隔離執行環境支援的 KeyStore，並支援金鑰認證，除非宣告 android.hardware.fingerprint 功能需要獨立執行環境支援的 KeyStore。

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

  • [9.11/H-1-1] 必須允許使用者選擇最短的睡眠逾時時間 (也就是從解鎖狀態轉為鎖定狀態的時間，時間不超過 15 秒)。
  • [9.11/H-1-2] 必須為使用者提供隱藏通知和停用所有驗證形式的功能，但「9.11.1 安全螢幕鎖定」中所述的主要驗證除外。Android 開放原始碼計畫符合鎖定模式的規定。

如果手持裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，就會：

  • [9.5/H-2-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

如果手持裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能標記，他們會：

  • [9.5/H-3-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

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

手持裝置實作 (* 不適用於平板電腦)：

  • [6.1/H-0-1]* 必須支援殼層指令 cmd testharness。

手持裝置實作 (* 不適用於平板電腦)：

  • Perfetto
    • [6.1/H-0-2]* 必須向殼層使用者公開 /system/bin/perfetto 二進位檔，且 cmdline 必須符合 Perfetto 說明文件。
    • [6.1/H-0-3]* Perfetto 二進位檔「必須」接受做為輸入 protobuf 設定，且符合 perfetto 說明文件中定義的結構定義。
    • [6.1/H-0-4]* Perfetto 二進位檔「必須」以輸出為 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
    • [6.1/H-0-5]* 請務必透過 Perfetto 二進位檔提供至少 perfetto 說明文件中所述的資料來源。
    • [6.1/H-0-6]* 必須預設啟用 Perfetto 追蹤 Daemon (系統屬性 persist.traced.enable)。

2.2.7 手持媒體效能類別

如要瞭解媒體成效類別的定義，請參閱第 7.11 節。

2.2.7.1。媒體

如果手持裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.R，那麼：

  • [5.1/H-1-1] 請指出可透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法在任何轉碼器組合中同時執行的硬體視訊解碼器工作階段數量上限。
  • [5.1/H-1-2] 以 720p 解析度@30 fps 同時執行的任何轉碼器組合，都必須支援 6 個硬體視訊解碼器工作階段 (AVC 或 HEVC) 執行個體。
  • [5.1/H-1-3] 請指出可透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法在任何轉碼器組合中並行執行的硬體視訊編碼器工作階段數量上限。
  • [5.1/H-1-4] 以 720p 解析度@30 fps 同時執行的任何轉碼器組合，都必須支援 6 個硬體視訊編碼器工作階段 (AVC 或 HEVC) 執行個體。
  • [5.1/H-1-5] 必須通告可在任何轉碼器組合中同時透過 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法執行的硬體視訊編碼器和解碼器工作階段數量上限。
  • [5.1/H-1-6] 以 720p@30 fps 解析度同時執行的任何轉碼器組合，都必須支援 6 個硬體視訊解碼器和硬體視訊編碼器工作階段 (AVC 或 HEVC) 執行個體。
  • [5.1/H-1-7] 負載低時，針對 1080p 以下所有硬體視訊編碼器 (Dolby Vision 轉碼器除外) 的所有硬體視訊編碼器，轉碼器初始化延遲時間都必須維持在 65 毫秒以下。此處載入定義為使用硬體視訊轉碼器和 1080p 音訊錄影初始化的 1080p 至 720p 純視訊轉碼工作階段。
  • [5.1/H-1-8] 在載入的情況下，128 kbps 以下的轉碼器初始化延遲時間不得超過 50 毫秒。如果音訊編碼器處於載入狀態，則所有音訊編碼器的轉碼器初始化延遲時間都不得超過 50 毫秒。載入這裡的定義是指使用硬體視訊轉碼器和 1080p 音訊轉碼器的並行 1080p 至 720p 影片初始轉碼工作階段。
  • [5.3/H-1-1] 在載入 1080p 30 fps 影片的情況下，「不得」在 10 秒內捨棄超過 1 個影格 (亦即影格降幅低於 0.333%)。負載定義為使用硬體視訊轉碼器和 128 kbps AAC 音訊播放的 1080p 至 720p 純影片轉碼工作階段。
  • [5.3/H-1-2] 影片播放時，在 30 fps 載入狀態下的影片解析度變更時，「不得」在 10 秒內捨棄超過 1 個影格。載入定義為使用硬體視訊轉碼器和 128Kbps AAC 音訊播放的 1080p 至 720p 純視訊轉碼工作階段。
  • [5.6/H-1-1] 使用 OboeTester 觸控色調測試或 CTS Verifier 點按色調測試時，輕觸音延遲時間必須小於 100 毫秒。
2.2.7.2。相機

如果手持裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.R，那麼：

  • [7.5/H-1-1] 「必須」使用主要後置鏡頭，解析度至少為 1,200 萬像素，而且能以 4k@30fps 支援錄影。主要後置鏡頭為後置鏡頭，相機 ID 最低。
  • [7.5/H-1-2] 「必須」使用主要前置鏡頭，解析度至少為 400 萬像素，且解析度至少為 1080p@30fps。主要前置鏡頭是相機 ID 最低的前置鏡頭。
  • [7.5/H-1-3] 必須支援 android.info.supportedHardwareLevel 屬性，使其支援 FULL 或更佳的後置主要屬性，以及 LIMITED 屬性 (適用於前置主鏡頭)。
  • [7.5/H-1-4] 兩台主要相機都必須支援 CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME。
  • [7.5/H-1-5] 針對 1080p 解析度的 1080p 解析度，這兩個主要鏡頭的相機效能測試 (3000K) 都必須與 CTS 相機效能測試 (3000K) 相比的結果。
  • [7.5/H-1-6] 這兩台主鏡頭的啟動延遲時間 (開啟相機到第一個預覽影格) 必須小於 600 毫秒，而這是 CTS 鏡頭效能測試在 ITS 照明條件 (300 萬色) 下測得的結果。
2.2.7.3. 硬體

如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.R，那麼：

  • [7.1.1.1/H-1-1] 螢幕解析度必須至少為 1080p。
  • [7.1.1.3/H-1-1] 螢幕密度必須至少為 400 dpi。
  • [7.6.1/H-1-1] 實體記憶體至少要有 6 GB。
2.2.7.4。效能

如果手持裝置實作會針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回 android.os.Build.VERSION_CODES.R，那麼：

  • [8.2/H-1-1] 必須確保連續寫入效能至少達到 100 MB。
  • [8.2/H-1-2] 必須確保隨機寫入效能至少達到每秒 10 MB。
  • [8.2/H-1-3] 必須確保連續讀取效能至少達到每秒 200 MB。
  • [8.2/H-1-4] 必須確保隨機讀取效能至少達到每秒 25 MB。

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] 應提供遙控器，讓使用者透過非觸控式瀏覽和核心瀏覽鍵輸入功能。

如果電視裝置導入作業含有 3 軸式迴轉儀，程式碼會：

  • [7.3.4/T-1-1] 事件的回報頻率必須至少為 100 Hz。
  • [7.3.4/T-1-2] 必須能夠測量每秒高達 1000 度的螢幕方向變化。

電視裝置實作方式：

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

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

  • [7.5.3/T-1-1] 必須支援透過這個 USB 連接埠連接的外部攝影機，但不一定隨時能連接。

如果電視裝置導入方式是 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
  • [5.2/T-0-2] VP8

電視裝置實作方式：

  • [5.2.2/T-SR] 強烈建議我們支援以每秒 30 個影格的速度，支援 H.264 編碼的 720p 與 1080p 解析度影片。

電視裝置實作「必須」支援下列影片解碼格式，並將這些格式提供給第三方應用程式：

電視裝置實作「必須」支援 MPEG-2 解碼功能 (如第 5.3.1 節所述)，且以標準影片影格速率和解析度，最高包括：

  • [5.3.1/T-1-1] HD 高畫質 1080p，每秒 29.97 影格，搭配主設定檔的高階解析度。
  • [5.3.1/T-1-2] HD 高畫質 1080i，每秒 59.94 影格，搭配主要設定檔高階裝置。他們「必須」解除交錯的 MPEG-2 影片，並提供給第三方應用程式。

電視裝置實作「必須」支援 H.264 解碼功能 (如第 5.3.4 節所述)，以標準影片影格速率和解析度，最高包括：

  • [5.3.4/T-1-1] 使用基準設定檔，以每秒 60 個影格的速度播放 HD 高畫質 1080p 影片
  • [5.3.4/T-1-2] HD 高畫質 1080p (每秒 60 影格) 搭配主要設定檔
  • [5.3.4/T-1-3] HD 高畫質 1080p，每秒 60 影格，高解析等級 4.2

如果電視裝置實作採用 H.265 硬體解碼器，「必須」支援 H.265 解碼器 (如第 5.3.5 節所述)，以標準影片影格速率和解析度，最高包括：

  • [5.3.5/T-1-1] HD 高畫質 1080p，每秒 60 影格，主要設定檔等級 4.1

如果電視裝置實作採用 H.265 硬體解碼器，可支援 H.265 解碼和 UHD 解碼設定檔，如下所示：

  • [5.3.5/T-2-1] 使用 Main10 第 5 級主要設定檔時，必須支援每秒 60 影格的 UHD 解碼設定檔

電視裝置實作「必須」支援 VP8 解碼功能，如第 5.3.6 節所述，且以標準影片影格速率和解析度，最高可包含：

  • [5.3.6/T-1-1] HD 高畫質 1080p (每秒 60 影格) 解碼設定檔

使用 VP9 硬體解碼器的電視裝置實作「必須」支援 VP9 解碼功能，如第 5.3.7 節所述，並依照標準影片影格速率和解析度，最高包括：

  • [5.3.7/T-1-1] HD 高畫質 1080p，每秒 60 影格，設定檔 0 (8 位元色彩深度)

如果電視裝置實作搭配 VP9 硬體解碼器，可支援 VP9 解碼和 UHD 超高畫質設定檔，請按照下列步驟操作：

  • [5.3.7/T-2-1] 必須支援每秒 60 影格的 UHD 解碼設定檔，設定檔 0 (8 位元色彩深度)。
  • [5.3.7/T-2-1] 強烈建議在採用設定檔 2 (10 位元色彩深度) 的情況下，以每秒 60 個影格的速度支援 UHD 解碼設定檔。

電視裝置實作方式：

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

如果電視裝置沒有內建螢幕，而需支援透過 HDMI 連接的外接螢幕，那麼：

  • [5.8/T-0-1] 必須設定 HDMI 輸出模式，選取 50Hz 或 60Hz 刷新率支援的最高解析度。
  • [5.8/T-SR] 強烈建議提供使用者可自行設定的 HDMI 刷新率選取器。
  • [5.8] 將 HDMI 輸出模式的刷新率應設為 50Hz 或 60Hz，視裝置銷售區域的刷新率而定。

如果電視裝置沒有內建螢幕，而需支援透過 HDMI 連接的外接螢幕，那麼：

  • [5.8/T-1-1] 必須支援 HDCP 2.2。

如果電視裝置實作不支援 UHD 解碼功能，而需支援透過 HDMI 連接外接螢幕，裝置就會：

  • [5.8/T-2-1] 必須支援 HDCP 1.4

2.3.3. Software

電視裝置實作方式：

  • [3/T-0-1] 必須宣告 android.software.leanback 和 android.hardware.type.television 功能。
  • [3.2.3.1/T-0-1] 「必須」使用意圖處理常式預先載入一或多個應用程式或服務元件，以供此處列出的應用程式意圖定義的所有公開意圖篩選器模式使用。
  • [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.3.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 的隨機讀取效能。

如果電視裝置實作包含改善裝置電源管理功能 (Android 開放原始碼計畫) 的功能，或擴充 Android 開放原始碼計畫包含的功能，請按照下列步驟操作：

  • [8.3/T-1-1] 「必須」提供使用者預設用途，才能啟用和停用省電模式功能。

如果電視裝置導入作業未裝電池：

如果電視裝置實作的電池符合下列條件：

  • [8.3/T-1-3] 「必須」提供使用者預設用途，才能顯示不受應用程式待命和打盹省電模式限制的所有應用程式。

電視裝置實作方式：

  • [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.3.5。安全性模型

電視裝置實作方式：

  • [9.11/T-0-1] 必須使用獨立的執行環境備份 KeyStore 實作。
  • [9.11/T-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密編譯演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在安全隔離的區域中，正確支援 Android KeyStore 系統支援的演算法，並在核心以上執行的程式碼隔離出來。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。上游 Android 開放原始碼計畫 (AOSP) 採用 Trusty 實作項目符合這項規定，但另外，以 ARM TrustZone 解決方案或第三方審查的安全實作方式為採用適當的管理程序隔離措施。
  • [9.11/T-0-3] 「必須」在獨立的執行環境中執行螢幕鎖定驗證，且僅在成功時允許使用驗證繫結金鑰。螢幕鎖定憑證的儲存方式「必須」僅允許獨立的執行環境執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，滿足這項需求。
  • [9.11/T-0-4] 必須支援金鑰認證，因為認證簽署金鑰受到安全硬體保護，而簽署金鑰是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非特定 SKU 至少產生了 100,000 個單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰。

請注意，如果裝置實作項目已在較舊的 Android 版本上啟動，則此類裝置不必具備受隔離執行環境支援的 KeyStore，並支援金鑰認證，除非宣告 android.hardware.fingerprint 功能需要獨立執行環境支援的 KeyStore。

如果電視裝置實作支援安全的螢幕鎖定功能，請注意下列事項：

  • [9.11/T-1-1] 必須允許使用者選擇從解鎖狀態轉換為鎖定狀態的睡眠逾時時間，且允許的逾時時間最短應設為 15 秒。

如果電視裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，他們會：

  • [9.5/T-2-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

如果電視裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能旗標，他們會：

  • [9.5/T-3-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

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

電視裝置實作方式：

  • Perfetto
    • [6.1/T-0-1] 必須向殼層使用者公開 /system/bin/perfetto 二進位檔，且 cmdline 必須符合 Perfetto 說明文件。
    • [6.1/T-0-2] Perfetto 二進位檔「必須」接受做為輸入 protobuf 設定，且符合 perfetto 說明文件中定義的結構定義。
    • [6.1/T-0-3] Perfetto 二進位檔「必須」以輸出為 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
    • [6.1/T-0-4] 請務必透過 Perfetto 二進位檔提供至少 perfetto 說明文件中所述的資料來源。

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 軸式加速度計。

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

  • [7.3.3/W-1-1] 找到 GNSS 測量結果後，必須立即回報，包括根據 GPS/GNSS 計算得出的位置資料。
  • [7.3.3/W-1-2] 必須回報 GNSS 虛擬範圍和虛擬範圍比率；在判斷地點後，如果靜止或移動的每秒平方小於 0.2 公尺，就足以計算出每秒 20% 以內，且速度至少在每秒 0.2 公尺以內。

如果手錶裝置實作項目包含 3 軸式陀螺儀，則必須：

  • [7.3.4/W-2-1] 必須能夠測量每秒高達 1000 度的螢幕方向變化。

手錶裝置實作：

  • [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.2.3.1/W-0-1] 「必須」使用意圖處理常式預先載入一或多個應用程式或服務元件，以供此處列出的應用程式意圖定義的所有公開意圖篩選器模式使用。

手錶裝置實作：

  • [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.4.4. 效能與電源

如果手錶裝置實作具有改善裝置電源管理功能 (Android 開放原始碼計畫包含的功能)，或擴充 Android 開放原始碼計畫包含的功能，就會：

  • [8.3/W-SR] 強烈建議向使用者提供充足空間，以顯示不受應用程式待命和打盹省電模式豁免的應用程式。
  • [8.3/W-SR] 極力建議為使用者提供預設預算來啟用和停用省電功能。

手錶裝置實作：

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

2.4.5。安全性模型

如果手錶裝置實作項目包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，他們會：

  • [9.5/W-1-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

如果手錶裝置實作項目包含多位使用者，並宣告 android.hardware.telephony 功能旗標，他們會：

  • [9.5/W-2-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

2.5. 汽車規定

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

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

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

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

2.5.1. 硬體

Automotive 裝置實作：

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

如果 Automotive 裝置導入作業包含 3 軸式迴轉儀，請按照下列步驟操作：

  • [7.3.4/A-2-1] 事件的回報頻率必須至少為 100 Hz。
  • [7.3.4/A-2-2] 也必須實作 TYPE_GYROSCOPE_UNCALIBRATED 感應器。
  • [7.3.4/A-2-3] 必須能夠測量每秒高達 250 度的螢幕方向變化。
  • [7.3.4/A-SR] 強烈建議將陀螺儀的測量範圍設為 +/-250dp，盡可能提高解析度。

如果 Automotive 裝置導入了 GPS/GNSS 接收器，但不包含行動網路數據連線，則會出現以下情形：

  • [7.3.3/A-3-1] 只有在首次開啟 GPS/GNSS 接收器時，或在 60 秒內開啟超過 4 天時，才能判斷所在位置。
  • [7.3.3/A-3-2] 必須符合「7.3.3/C-1-2」和「7.3.3/C-1-6」所述的時間到第一次修正條件，其他所有位置資訊要求 (例如，不是第一次或超過 4 天的要求) 都符合「首次修正時間」條件。一般情況下，如果車輛沒有行動網路資料連線功能，就可以滿足 7.3.3/C-1-2 要求。方法是使用接收器上計算的 GNSS 軌道預測功能，或使用最後已知車輛位置，並能死超過 60 秒且定位精確度符合 7.3.3/C-1-3 規定，或同時符合上述兩項條件。

Automotive 裝置實作：

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

  • [7.4.3/A-SR] 強烈建議支援訊息存取設定檔 (MAP)。

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

  • [7.4.5/A] 可以針對系統應用程式應該可以使用的網路，使用 System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常數。

室外視角相機是指拍攝裝置以外的場景 (例如行車記錄器)。

Automotive 裝置實作：

  • 必須設置一或多個室外視角相機。

如果 Automotive 裝置導入了這類相機的室外視角相機，請按照下列步驟操作：

  • [7.5/A-1-1] 除非符合相機核心需求，否則「不得」具備透過 Android Camera API 存取的外側鏡頭。
  • [7.5/A-SR] 強烈建議不要旋轉或水平鏡射相機預覽畫面。
  • [7.5.5/A-SR] 強烈建議您設計方向，確保攝影機的長邊對齊地平線。
  • [7.5/A-SR] 強烈建議採用至少 130 萬像素的解析度。
  • 應使用固定對焦或 EDOF (延伸領域深度) 硬體。
  • 應支援 Android 同步處理架構。
  • 相機驅動程式中可能實作硬體自動對焦或軟體自動對焦功能。

Automotive 裝置實作：

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

  • [7.6.1/A] 必須設定資料分區的格式，才能提高執行效能和快閃儲存的壽命，例如使用 f2fs 檔案系統。

如果 Automotive 裝置實作會透過部分內部非卸除式儲存空間提供共用外部儲存空間，則其必須：

  • [7.6.1/A-SR] 強烈建議運用 SDCardFS，降低在外部儲存空間執行的作業 I/O 負擔。

如果 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.car.* 命名空間中的所有公用 API。

如果 Automotive 裝置實作項目使用 android.car.CarPropertyManager 搭配 android.car.VehiclePropertyIds 提供專屬 API，就會執行以下動作：

  • [3/A-1-1] 「不得」將特殊權限附加至系統應用程式使用這些資源，或是禁止第三方應用程式使用這些屬性。
  • [3/A-1-2] 不得複製 SDK 中既有的車輛屬性。

Automotive 裝置實作：

  • [3.2.1/A-0-1] 必須支援並強制執行所有 Automotive 權限參考資料頁面中記錄的權限常數。

  • [3.2.3.1/A-0-1] 「必須」使用意圖處理常式預先載入一或多個應用程式或服務元件，以供此處列出的應用程式意圖定義的所有公開意圖篩選器模式使用。

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

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

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

如果 Automotive 裝置實作包含「按下並交談」按鈕，就會：

  • [3.8.4/A-1-1] 「必須」使用短暫按下推送按鈕，做為指定互動啟動使用者選擇的輔助應用程式 (也就是實作 VoiceInteractionService 的應用程式)。

Automotive 裝置實作：

Automotive 裝置實作：

如果 Automotive 裝置實作內含預設啟動器應用程式，就會執行以下動作：

Automotive 裝置實作：

  • [3.8/A] 可能會限制應用程式要求進入全螢幕模式，如 immersive documentation 所述。
  • [3.8/A] 可隨時顯示狀態列和導覽列。
  • [3.8/A] 可以限制應用程式要求變更系統 UI 元素背後的顏色，確保這些元素隨時都能清楚顯示。

2.5.4. 效能與電源

Automotive 裝置實作：

  • [8.2/A-0-1] 必須針對每個程序的 UID，回報讀取和寫入非揮發性儲存空間的資料量，這樣才能透過 System API android.car.storagemonitoring.CarStorageMonitoringManager 取得開發人員的統計資料。Android 開放原始碼計畫透過 uid_sys_stats 核心模組符合相關規定。
  • [8.3/A-1-3] 必須支援車庫模式。
  • [8.3/A] 每次開車後，都必須進入車庫模式至少 15 分鐘，但下列情況除外：
    • 電量消耗。
    • 未排定任何閒置工作。
    • 駕駛會結束車庫模式。
  • [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.5.5。安全性模型

如果 Automotive 裝置實作支援多位使用者：

Automotive 裝置實作：

  • [9.11/A-0-1] 必須使用獨立的執行環境備份 KeyStore 實作。
  • [9.11/A-0-2] 必須實作 RSA、AES、ECDSA 和 HMAC 加密編譯演算法，以及 MD5、SHA1 和 SHA-2 系列雜湊函式，才能在安全隔離的區域中，正確支援 Android KeyStore 系統支援的演算法，並在核心以上執行的程式碼隔離出來。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。上游 Android 開放原始碼計畫 (AOSP) 採用 Trusty 實作項目符合這項規定，但另外，以 ARM TrustZone 解決方案或第三方審查的安全實作方式為採用適當的管理程序隔離措施。
  • [9.11/A-0-3] 「必須」在獨立的執行環境中執行螢幕鎖定驗證，且僅在成功時允許使用驗證繫結金鑰。螢幕鎖定憑證的儲存方式「必須」僅允許獨立的執行環境執行螢幕鎖定驗證。上游 Android 開放原始碼計畫提供 Gatekeeper Hardware 抽象層 (HAL) 和 Trusty，滿足這項需求。
  • [9.11/A-0-4] 必須支援金鑰認證，因為認證簽署金鑰受到安全硬體保護，而簽署金鑰是在安全的硬體中執行。必須為足夠數量的裝置共用認證簽署金鑰，以免金鑰無法做為裝置 ID。符合這項規定的方法之一是共用相同認證金鑰，除非特定 SKU 至少產生了 100,000 個單位。如果產生的 SKU 單位超過 100,000 個，每 100,000 個單位可能會使用不同的金鑰。

請注意，如果裝置實作項目已在較舊的 Android 版本上啟動，則此類裝置不必具備受隔離執行環境支援的 KeyStore，並支援金鑰認證，除非宣告 android.hardware.fingerprint 功能需要獨立執行環境支援的 KeyStore。

Automotive 裝置實作：

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

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

Automotive 裝置實作：

  • Perfetto
    • [6.1/A-0-1] 必須向殼層使用者公開 /system/bin/perfetto 二進位檔，且 cmdline 必須符合 Perfetto 說明文件。
    • [6.1/A-0-2] Perfetto 二進位檔「必須」接受做為輸入 protobuf 設定，且符合 perfetto 說明文件中定義的結構定義。
    • [6.1/A-0-3] Perfetto 二進位檔「必須」以輸出為 protobuf 追蹤記錄，且符合 Perfetto 說明文件中定義的結構定義。
    • [6.1/A-0-4] 請務必透過 Perfetto 二進位檔提供至少 perfetto 說明文件中所述的資料來源。

2.6. 平板電腦需求

Android 平板電腦裝置是指 Android 裝置實作方式，通常符合下列所有條件：

  • 用於雙手並用。
  • 沒有貝殼式設計或可轉換設定。
  • 透過標準連線 (例如 USB、藍牙) 連線，與裝置連線的實體鍵盤實作。
  • 具備可提供行動功能的電源 (例如電池)。
  • 螢幕尺寸介於 7 到 18 吋之間。

平板電腦裝置實作的要求與手持裝置實作類似。該節會以 * 表示例外狀況，並在本節中註記，供您參考。

2.6.1. 硬體

螢幕大小

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

陀螺儀

如果平板電腦裝置導入方式包含 3 軸式迴轉儀，代碼會如下：

  • [7.3.4/Tab-1-1] 必須能夠測量每秒高達 1000 度方向的變化。

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

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

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

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

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

虛擬實境模式 (第 7.9.1 節)

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

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

2.6.2. 安全性模型

金鑰和憑證 (第 9.11 節)

請參閱 [9.11] 一節。

如果平板電腦裝置的實作方式包含多位使用者，且未宣告 android.hardware.telephony 功能旗標，就會：

  • [9.5/T-1-1] 必須支援設有限制的個人資料，這項功能可讓裝置擁有者管理裝置上的其他使用者及其功能。透過設有限制的設定檔，裝置擁有者可以快速設定不同的環境供其他使用者處理，還能針對這些環境中可使用的應用程式，管理更精細的限制。

如果平板電腦裝置的實作方式包含多位使用者，並宣告 android.hardware.telephony 功能旗標，就會：

  • [9.5/T-2-1]「不得」支援設有限制的個人資料，但「必須」配合 Android 開放原始碼計畫的實作控制項，允許 /禁止其他使用者存取語音通話和簡訊。

2.6.2. Software

  • [3.2.3.1/Tab-0-1] 「必須」使用意圖處理常式預先載入一或多個應用程式或服務元件，以供此處列出的應用程式意圖定義的所有公開意圖篩選器模式使用。

3. Software

3.1. 代管 API 相容性

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

裝置實作方式：

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

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

  • [C-0-3] 除非這個相容性定義明確允許，否則「不得」省略任何受管理的 API、變更 API 介面或簽名、偏離記錄行為，或納入免人工管理 (No-ops)。

  • [C-0-4] 即使 Android 提供的部分硬體功能遭到省略，也必須繼續以合理的方式呈現 API 並運作行為。如要瞭解這個情境的具體需求，請參閱第 7 節。

  • [C-0-5] 不得允許第三方應用程式使用非 SDK 介面 (這類介面定義為 Java 語言套件中的方法和欄位，該介面位於 Android 開放原始碼計畫啟動類別路徑中，且不屬於公開 SDK 的一部分)。這包括用 @hide 註解裝飾，但使用 @SystemAPI 的 API (如 SDK 文件以及私人和套件私人類別成員所述)。

  • [C-0-6] 請依據 Android 開放原始碼計畫中適當 API 級別分支版本，透過 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路徑中的佈建和拒絕清單標記，將每個非 SDK 介面隨附於相同的受限清單。

  • [C-0-7] 必須支援已簽署的設定動態更新機制，以便使用 Android 開放原始碼計畫的現有公開金鑰，在任何 APK 中嵌入已簽署的設定，藉此從受限制的清單移除非 SDK 介面。

    但請注意以下幾點：

    • 如果裝置缺少隱藏的 API，或是實作的裝置不同，請將隱藏的 API 移至拒絕清單，或是將該 API 從所有受限清單中省略 (即淺灰色、深灰色、黑色)。
    • 如果 Android 開放原始碼計畫中沒有隱藏的 API，請將隱藏的 API 加入任何受限清單中 (即淺灰色、深灰色、黑色)。

3.1.1. Android 擴充功能

Android 支援透過更新該 API 級別的擴充功能版本，來擴充特定 API 級別的代管 API 介面。如果該 API 級別有擴充功能，android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API 會傳回所提供 apiLevel 的擴充功能版本。

Android 裝置實作：

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

  • [C-0-2] 「必須」只傳回 Android 開放原始碼計畫定義的有效擴充功能版本號碼。

  • [C-0-3] 必須支援 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) 傳回的所有擴充功能版本，其支援方式與其他代管 API 相同，並且遵循第 3.1 節中的規定。

3.1.2. Android 程式庫

由於 Apache HTTP 用戶端已淘汰，裝置實作方式如下：

  • [C-0-1] 「不得」將 org.apache.http.legacy 程式庫放在 Bootclasspath 中。
  • [C-0-2] 只有在應用程式符合下列任一條件時，才需要將 org.apache.http.legacy 程式庫新增至應用程式類別路徑：
    • 指定 API 級別 28 以下。
    • 將 <uses-library> 的 android:name 屬性設為 org.apache.http.legacy，在資訊清單中宣告需要程式庫。

Android 開放原始碼計畫實作項目符合這些規定。

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 系統的版本，採用人類可讀的格式。這個欄位必須包含 11 中定義的其中一個字串值。
VERSION.SDK 目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 11，這個欄位「必須」包含整數值 11_INT。
VERSION.SDK_INT 目前執行 Android 系統的版本，採用第三方應用程式程式碼可存取的格式。如果是 Android 11，這個欄位「必須」包含整數值 11_INT。
VERSION.INCREMENTAL 裝置實作人員選擇的值，以人類可讀的格式指定目前執行 Android 系統的特定版本。使用者可用的不同版本「不得」重複使用這個值。這個欄位的常見用途是指出用於產生建構作業的版本號碼或原始碼控制變更 ID。這個欄位的值必須能當做可列印的 7 位元 ASCII 編碼，且符合規則運算式「^[^ :\/~]+$」。
遊戲板 裝置實作人員選擇的值，以人類可讀的格式識別裝置所使用的特定內部硬體。這個欄位的可能用途，是指出裝置供電的主機板特定修訂版本。這個欄位的值必須能以 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:11/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_-]+$」。在產品生命週期內，這個產品名稱「不得」變更。
序號 必須傳回「UNKNOWN」。
標記 由裝置實作工具選擇的標記清單 (以半形逗號分隔)，可進一步區分版本。這些標記「必須」能以 7 位元 ASCII 形式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+」，且「必須」採用以下三種一般 Android 平台簽署設定的對應值：release-keys、dev-keys 和 test-keys。
時間 代表建構發生時間的時間戳記的值。
類型 裝置實作者選擇的值，用於指定版本的執行階段設定。這個欄位「必須」與以下三種一般 Android 執行階段設定的對應值：user、userdebug 或 eng。
使用者 產生版本的使用者 (或自動化使用者) 名稱或使用者 ID。這個欄位的具體格式沒有規定，但不得為空值或空白字串 (")。
VERSION.SECURITY_PATCH 表示版本安全性修補程式等級的值。「必須」表示該版本沒有任何安全漏洞，可影響到指定 Android 公開安全性公告所述的任何問題。請採用 [YYYY-MM-DD] 的格式，與 Android 公開安全性公告或 Android 安全性補充公告中所記錄的字串相符，例如「2015-11-01」。
VERSION.BASE_OS 此值代表版本 (FINGERPRINT) 的 FINGERPRINT 參數，與此版本相同 (Android 公開安全性公告提供的修補程式除外)。它必須回報正確的值，如果這類版本不存在，請回報空字串 (")。
BOOTLOADER 裝置實作者選擇的值，以人類可讀的格式，識別裝置中使用的特定內部系統啟動載入程式版本。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-]+$」。
getRadioVersion() 必須 (也就是或傳回) 由裝置實作者選擇的值，用來識別裝置中使用的特定內部無線電/數據機版本，且格式必須是人類可讀的格式。如果裝置沒有任何內部無線電/模組，就「必須」傳回 NULL。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。
getSerial() 「必須」提供 (發行或歸還) 一組硬體序號，該序號必須專屬於採用相同型號和 MANUFACTURER 的所有裝置。這個欄位的值必須能以 7 位元 ASCII 格式編碼，且符合規則運算式「^[a-zA-Z0-9._-,]+$」。

3.2.3. 意圖相容性

3.2.3.1。常見的應用程式意圖

Android 意圖可讓應用程式元件要求其他 Android 元件的功能。Android 上游專案包含實作多種意圖模式的應用程式清單，這些模式可執行多項常見動作。

裝置實作方式：

  • [C-SR] 強烈建議使用意圖處理常式預先載入一或多個應用程式或服務元件，以使用這裡列出的下列應用程式意圖定義的所有公開意圖篩選器模式，並提供執行要求，滿足開發人員對這些常見應用程式意圖的預期，如 SDK 中所述。

請參閱第 2 節，瞭解每種裝置類型的強制應用程式意圖。

3.2.3.2。意圖解決方案

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

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

  • [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 說明文件中也有關於背景應用程式的限制。此外，某些廣播意圖只有在硬體支援時才須有條件限制，如果裝置支援必要的硬體，他們「必須」播送意圖，並內嵌 SDK 說明文件內的行為。
3.2.3.5。條件式應用程式意圖

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

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

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

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

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

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

如果裝置實作支援 VoiceInteractionService，且一次安裝多個使用這個 API 的應用程式，就會：

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

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

  • [C-6-1] 「必須」實作會回應意圖 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS 的活動；如果使用 UI_MODE_TYPE_NORMAL 的實作，則「必須」是一個活動，可讓使用者授予或拒絕應用程式對 DND 政策設定的存取權。

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

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

如果裝置的實作支援 Wi-Fi Easy Connect 支援，並向第三方應用程式公開相關功能，他們必須：

如果裝置實作項目提供數據節省模式，就會發生以下情形：* [C-10-1] 「必須」在設定中提供使用者介面，以處理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS 意圖，讓使用者可將應用程式新增至允許清單或從允許清單中移除。

如果裝置實作項目未提供數據節省模式，就會發生以下情形：

如果裝置實作項目透過 android.hardware.camera.any 宣告支援相機：

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

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

如果裝置的實作方式包含預先安裝的應用程式，或是您希望允許第三方應用程式存取使用統計資料，可以採取以下做法：

  • [C-SR] 極力「建議」提供使用者可存取的機制，針對宣告 android.permission.PACKAGE_USAGE_STATS 權限的應用程式，針對 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意圖，授予或撤銷使用統計資料的存取權。

如果裝置實作方式禁止任何應用程式 (包括預先安裝的應用程式) 存取使用統計資料，將採取下列做法：

如果裝置實作方式回報 android.hardware.audio.output 功能，就會：

  • [C-SR] 強烈建議你遵循 android.intent.action.TTS_SERVICE、android.speech.tts.engine.INSTALL_TTS_DATA 和 android.speech.tts.engine.GET_SAMPLE_TEXT 意圖，有一個活動可為這些意圖提供執行要求，如 SDK 這裡所述。

Android 支援互動式螢幕保護程式 (先前稱為 Dreams)。螢幕保護程式可讓使用者在裝置已連接電源或固定在桌面座架上時，與應用程式互動。裝置實作：

  • 應加入螢幕保護程式支援，並提供設定選項，讓使用者根據 android.settings.DREAM_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] 使用 Activity#setShowWhenLocked() API 選擇讓裝置在螢幕鎖定的頂端顯示內容時，「必須」安全地隱藏所有螢幕上的內容。
  • 應具備對應至該螢幕的 android.content.res.Configuration，以便在次要螢幕上啟動活動時能正確顯示、運作並維持相容性。

如果裝置實作項目允許在次要顯示器上啟動一般的 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] 必須與一或多個定義的 Android NDK ABI 相容。
  • [C-0-2] 必須支援在受管理的環境中執行的程式碼，使用標準 Java Native Interface (JNI) 語意呼叫原生程式碼。
  • [C-0-3] 與下方清單中的每個必要程式庫，都必須與原始碼相容 (即標頭相容) 和二進位檔相容 (適用於 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] 請務必透過上述參數，回報下列 ABI 清單中的部分 ABI，且不得回報不在清單上的 ABI。

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

    • libaaudio.so (支援 AAudio 原生音訊)
    • libamidi.so (原生 MIDI，若第 5.9 節所述聲明 android.software.midi 功能使用，則支援 MIDI)
    • 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 (數學程式庫)
    • libneuralnetworks.so (Neural Networks API)
    • 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 版本可能會支援其他 ABI。

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

如果裝置實作回報支援 armeabi ABI，就會：

  • [C-3-1] 也必須支援 armeabi-v7a 並回報支援，因為 armeabi 只適用於舊版應用程式。

如果裝置實作回報對 armeabi-v7a ABI 的支援，就會針對使用這個 ABI 的應用程式：

  • [C-2-1] 必須在 /proc/cpuinfo 中加入下列幾行，且不應修改同一部裝置上的值，即使其他 ABI 讀取這些值也一樣。

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

  • [C-2-2] 必須隨時保持下列作業狀態，即使是透過原生 CPU 支援或透過軟體模擬在 ARMv8 架構中實作 ABI 也一樣：

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

  • [C-2-3] 必須支援進階 SIMD (又稱 NEON) 擴充功能。

3.4. 網路相容性

3.4.1. WebView 相容性

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

  • [C-1-1] 必須回報 android.software.webview。
  • [C-1-2] 「必須」在 Android 11 分支版本上，使用取自上游 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/$(BUILD)」可能會省略，但如果出現 $(BUILD) 字串，則必須與 android.os.Build.ID 的值相同。
    • $(CHROMIUM_VER) 字串的值「必須」是上游 Android 開放原始碼專案中的 Chromium 版本。
    • 裝置導入方式會在使用者代理程式字串中省略行動裝置。

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

  • [C-1-3] 「必須」與會例項化 WebView 的應用程式不同，轉譯提供的內容或遠端網址內容。具體來說，獨立的轉譯器程序「必須」擁有較低權限、以獨立的使用者 ID 執行、無法存取應用程式的資料目錄、沒有直接網路存取權，而且只能透過 Binder 存取最低需求的系統服務。WebView 的 Android 開放原始碼計畫實作符合這項規定。

請注意，如果裝置實作項目為 32 位元，或宣告功能旗標 android.hardware.ram.low，就不受 C-1-3 的規範。

3.4.2。瀏覽器相容性

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

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

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

3.5. API 行為相容性

裝置實作方式：

  • [C-0-9] 「必須」確保所有已安裝的應用程式都符合 API 行為相容性，除非這些應用程式受到第 3.5.1 節所述限制。
  • [C-0-10] 不得實作許可清單方法，確保 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。
  • [C-0-9] 除非應用程式透過 insertProviderAt() 或 removeProvider() 修改清單，否則裝置「必須」依照指定順序，以 Security.getProviders() 方法的順序，以指定名稱 (由 Provider.getName() 傳回) 和類別傳回下列安全性提供者，做為前七個陣列值。裝置「可」在以下指定供應商清單後傳回其他供應商。
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

3.5.1。應用程式限制

如果裝置實作項目採用專屬機制來限制應用程式，而且這項機制比「稀有應用程式待命值區」嚴格，可以執行以下動作：

  • [C-1-1] 必須為使用者提供預設用途，讓使用者查看受限制的應用程式清單。
  • [C-1-2] 必須為使用者提供預設選項，才能為個別應用程式啟用 / 停用限制。
  • [C-1-3] 不得在沒有出現不良系統健康行為的證據的情況下自動套用限制，但「可能」在偵測到不良系統健康行為 (例如喚醒鎖定、長時間執行的服務和其他條件) 時，對應用程式套用限制。這些標準可能取決於裝置實作者，但必須與應用程式對系統健康狀態的影響相關。與系統健全性無關的其他條件 (例如應用程式在市場上的熱門度偏低)，「不得」做為條件使用。
  • [C-1-4] 當使用者手動關閉應用程式限制時，應用程式「不得」自動套用應用程式限制，並建議使用者套用應用程式限制。
  • [C-1-5] 如果應用程式已自動套用應用程式限制，請務必告知使用者。套用限制後的 24 小時內，「必須」提供這類資訊。
  • [C-1-6] 當受限制的應用程式呼叫這個 API 時，必須針對 ActivityManager.isBackgroundRestricted() 傳回 true。
  • [C-1-7] 「不得」限制使用者明確使用的頂層前景應用程式。
  • [C-1-8] 當使用者明確開始使用受限的應用程式時，如果該應用程式成為頂層前景應用程式，就必須暫停限制。

3.6. API 命名空間

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • 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
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36MB
240 dpi (hdpi)
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
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
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
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
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
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
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 方法。

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

相反地，如果裝置的實作不支援應用程式內快速固定捷徑，則可用來：

如果裝置實作項目實作預設啟動器，讓使用者可透過 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 說明文件中的「應用程式小工具設計指南」。
  • 可能支援螢幕鎖定畫面上的應用程式小工具。

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

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-1-7] 「必須」正確轉譯透過 Notification.MessagingStyle 提供的所有資源 (圖片、貼圖、圖示等)，使用者不需任何額外互動。舉例來說，在透過 setGroupConversation 設定的群組對話中，「必須」顯示所有資源，包括透過 android.app.Person 提供的圖示。
  • [C-SR] 強烈建議「強烈建議」在使用者多次關閉該通知後，自動依每個管道和應用程式套件層級封鎖特定第三方應用程式的通知。
  • 應支援複合式通知。
  • 應以抬頭通知的形式呈現優先順序較高的通知。
  • 應為使用者提供延後通知的權限。
  • 「盡量」只管理第三方應用程式何時能通知使用者特定事件的顯示設定和時間，以減少駕駛人分心等安全問題。

Android 11 導入對話通知的支援功能，這類通知使用 MessagingStyle 並提供已發布的 People 捷徑 ID。

裝置實作方式：

如果裝置實作項目支援 conversation notifications，且應用程式提供 bubbles 的必要資料，就會發生以下情形：

  • [C-SR] 強烈建議你以對話框形式顯示這個對話。Android 開放原始碼計畫實作項目具備預設的系統 UI、設定和啟動器，可滿足上述規定。

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

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

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

  • [C-3-1] 顯示抬頭通知時，「必須」使用 Notification.Builder API 類別所述的抬頭通知檢視畫面和資源。
  • [C-3-2] 必須如 SDK 中所述，「必須」將透過 Notification.Builder.addAction() 提供的動作與通知內容一併顯示，使用者不需與使用者互動。
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] 必須「必須」，當裝置具備某種方式，讓使用者能授予或拒絕第三方應用程式存取 DND 政策設定時，必須一併顯示應用程式建立的自動 DND 規則，以及使用者建立和預先定義的規則。
  • [C-1-3] 必須遵循 NotificationManager.Policy 傳遞的 suppressedVisualEffects 值，如果應用程式已設定任何 SUPPRESSED_effective_SCREEN_OFF 或 SUPPRESSED_effective_SCREEN_ON 標記，則「必須」向使用者說明在 DND 設定選單中隱藏視覺效果。

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 意圖的活動。

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 主題外觀和風格時使用。

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

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] 最多只能支援 7 個顯示活動。
  • 一次至少應顯示 4 項活動的標題。
  • [C-1-2] 必須導入螢幕固定行為，並提供設定選單讓使用者切換功能。
  • 應在近期記錄中顯示醒目顯示顏色、圖示和畫面標題。
  • 應顯示關閉的預設用途 (「x」)，但可能要延遲直到使用者與螢幕互動為止。
  • 請務必實作捷徑，以便輕鬆切換至上一個活動。
  • 使用者輕觸近期的兩個功能鍵時，應觸發在最近使用的兩個應用程式之間快速切換動作。
  • 長按近期函式鍵時，應觸發分割畫面多視窗模式 (如果支援)。
  • 可列出相關近期項目為一組活動。
  • [SR] 強烈建議將總覽畫面使用上游 Android 使用者介面 (或類似的縮圖式介面)。

3.8.9。輸入管理

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

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

  • [C-1-1] 必須宣告平台功能 android.software.input_methods，並支援 Android SDK 說明文件中定義的 IME API。

3.8.10。螢幕鎖定媒體控制項

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

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

請參閱第 3.2.3.5 節，瞭解意圖破解螢幕保護程式的設定。

3.8.12。位置

如果裝置實作項目內含能夠提供位置座標的硬體感應器 (例如 GPS)，

  • [C-1-2] 「設定」中的「位置資訊」選單必須顯示位置的目前狀態。
  • [C-1-3]「不得」在「設定」的「位置」選單中顯示定位模式。

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 中指定的膚色和多樣家庭表情符號。

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

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

Android 支援轉譯緬甸字型。緬甸擁有幾種不符合萬國碼 (Unicode) 規範的字型，一般稱為「Zawgyi」，可用於轉譯緬甸語言。

如果裝置的實作支援緬甸文，即可： 

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14。多視窗模式

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

  • [C-1-1] 必須根據 Android SDK 多視窗模式支援說明文件中描述的應用程式行為和 API，實作這類多視窗模式，並符合下列規定：
  • [C-1-2] 必須遵循本 SDK 所述，在 AndroidManifest.xml 檔案中為應用程式設定的 android:resizeableActivity。
  • [C-1-3] 如果螢幕高度小於 440 dp，且螢幕寬度小於 440 dp，就「不得」提供分割畫面或任意形式模式。
  • [C-1-4] 在子母畫面以外的多視窗模式下，活動「不得」調整為小於 220 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] 如果應用程式未宣告 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 的任何值，則必須為子母畫面視窗分配下列最小寬度和高度：

    • 如果裝置的 Configuration.uiMode 設為 UI_MODE_TYPE_TELEVISION 以外的使用者，則必須分配最小寬度和高度為 108 dp。
    • 設定為 UI_MODE_TYPE_TELEVISION 的裝置必須分配最小寬度 240 dp，高度下限為 135 dp。

3.8.15。螢幕凹口

如同 SDK 文件所述，Android 支援螢幕凹口。DisplayCutout API 定義的畫面邊緣區域，在邊緣顯示螢幕凹口或曲線顯示時，可能無法為應用程式運作的區域。

如果裝置的實作方式包含螢幕凹口，就會：

  • [C-1-5] 如果裝置的顯示比例為 1.0(1:1)，「不得」包含凹口。
  • [C-1-2] 每個邊緣最多只能有一個凹口。
  • [C-1-3] 必須遵循 SDK 中所述，透過 WindowManager.LayoutParams API 設定的螢幕凹口標記。
  • [C-1-4] 必須針對 DisplayCutout API 中定義的所有凹口指標回報正確的值。

3.8.16。裝置控制

Android 提供 ControlsProviderService 和 Control API，可讓第三方應用程式發布裝置控制項，以便迅速為使用者處理狀態並採取動作。

如要瞭解裝置專屬的需求，請參閱 2_2_3 節。

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 節所述的裝置擁有者佈建功能。

3.9.1 裝置佈建

3.9.1.1 裝置擁有者佈建

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

  • [C-1-1] 必須支援將裝置政策用戶端 (DPC) 註冊為裝置擁有者應用程式，方法如下：
  • [C-1-2] 必須要求我們在佈建程序前後執行一些確認動作，才能將應用程式設為裝置擁有者。同意聲明可透過使用者操作或某些程式輔助方式取得，但如 Android 開放原始碼計畫中提及的相關揭露事項，則必須先顯示開發人員同意聲明，才能啟動裝置擁有者佈建程序。此外，企業用於佈建裝置擁有者的程式輔助裝置擁有者同意聲明機制，「不得」幹擾非企業用途的現成體驗。
  • [C-1-3] 不得以硬式編碼的方式修改同意聲明狀態，或禁止使用者使用其他裝置擁有者的應用程式。

如果裝置實作方式宣告 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 節)，就必須確保裝置符合所有適用的安全性規定。

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

  • [C-2-1] 必須支援指定獨立的螢幕鎖定畫面，並符合下列規定，才能僅授權給在受管理設定檔中執行的應用程式。
  • 如果受管理設定檔的聯絡人顯示在預先安裝的通話記錄、通話使用者介面、進行中和未接來電通知、聯絡人和訊息應用程式上，就必須標有代表受管理設定檔應用程式的徽章。

3.9.3 受管理使用者支援

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

  • [C-1-1] isLogoutEnabled 傳回 true 時，「必須」為使用者提供登出權，讓使用者自行登出目前使用者，然後在多使用者工作階段中切換回主要使用者。「必須」能在裝置未解鎖的情況下，從螢幕鎖定畫面存取使用者預設用途。

3.10. 無障礙功能

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

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

  • [C-1-1] 必須按照 Accessibility API SDK 說明文件中的指示，實作 Android 無障礙架構。
  • [C-1-2] 必須產生無障礙事件，並依 SDK 中記錄，向所有已註冊的 AccessibilityService 實作提供適當的 AccessibilityEvent。
  • [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 功能，請注意下列事項：

如果裝置的導入方式支援安裝第三方 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] 必須支援所有 TIF API，以便在裝置上安裝並使用第三方 TIF 輸入資料服務。

3.13. 快速設定

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

如果裝置實作項目內含「快速設定」UI 元件，並支援第三方「快速設定」，那麼：

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

3.14。媒體使用者介面

如果裝置的實作方式包含無法透過 MediaBrowser 或 MediaSession 與第三方應用程式互動、未啟用語音功能的應用程式 (應用程式)，請執行下列步驟：

  • [C-1-2] 必須清楚顯示透過 getIconBitmap() 或 getIconUri() 取得的圖示，以及透過 getTitle() 取得的標題，如 MediaDescription 所述。為遵守安全法規 (例如駕駛人分心等級)，可能會縮短標題。

  • [C-1-3] 顯示這個第三方應用程式提供的內容時，一律必須顯示第三方應用程式圖示。

  • [C-1-4] 必須允許使用者與整個 MediaBrowser 階層互動。為遵守安全法規 (例如駕駛人分心)，「可能」會限制部分階層部門的存取，但「不得」根據內容或內容供應者給予特殊待遇。

  • [C-1-5] 建議輕觸兩下 KEYCODE_HEADSETHOOK 或 KEYCODE_MEDIA_PLAY_PAUSE，將其設為 MediaSession.Callback#onMediaButtonEvent 的 KEYCODE_MEDIA_NEXT。

3.15. 免安裝應用程式

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

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

如果裝置實作項目支援免安裝應用程式，就會：

  • [C-1-1] 「必須」提供下列使用者權限，才能與免安裝應用程式互動。Android 開放原始碼計畫符合預設系統 UI、設定和啟動器的規定。
  • [C-1-2] 「必須」為使用者提供授權，以便查看及刪除每個應用程式套件本機快取的免安裝應用程式。
  • [C-1-3] 必須提供持續顯示的使用者通知，允許在前景執行免安裝應用程式時將其收合。這則使用者通知「必須」指出免安裝應用程式不需要安裝，並提供使用者預設用途，可將使用者導向「設定」中的應用程式資訊畫面。如果是透過網頁意圖啟動的免安裝應用程式 (需使用動作設為 Intent.ACTION_VIEW 且配置為「http」或「https」)，其他使用者預設應允許使用者啟動免安裝應用程式，並啟動與已設定網路瀏覽器相關聯的連結 (如果裝置上有瀏覽器的話)。
  • [C-1-4] 如果裝置支援「最近使用」功能，「必須」允許透過「最近使用」功能存取執行中的免安裝應用程式。
  • [C-1-5] 「必須」針對此處的 SDK 中列出的意圖，預先載入一或多個具有意圖處理常式的應用程式或服務元件，並讓免安裝應用程式顯示意圖。

3.16. 配對裝置配對

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

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

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

3.17. 重量級應用程式

如果裝置實作結果宣告了 FEATURE_CANT_SAVE_STATE 功能，那麼：

  • [C-1-1] 「必須」只有一個已安裝在系統中指定 cantSaveState 的應用程式。如果使用者在系統未明確退出應用程式的情況下退出應用程式 (例如，在使用者沒有主動退出應用程式的情況下按下主畫面，而是系統沒有剩餘的活動，而是按下返回)，裝置實作就「必須」在 RAM 中優先執行該應用程式，就像執行其他可能持續運作的作業 (例如前景服務) 一樣。這類應用程式在背景執行時，系統仍可對其套用電源管理功能，例如限制 CPU 和網路存取權。
  • [C-1-2] 當使用者啟動使用 cantSaveState 屬性宣告的第二個應用程式時，必須提供 UI 預設用途，選擇應用程式不會啟用正常狀態儲存/還原機制的應用程式。
  • [C-1-3] 「不得」將政策中的其他變更套用到指定 cantSaveState 的應用程式，例如變更 CPU 效能或變更排程優先順序。

如果裝置實作方式並未宣告 FEATURE_CANT_SAVE_STATE 功能，那麼：

  • [C-1-1] 必須忽略應用程式設定的 cantSaveState 屬性，「不得」根據該屬性變更應用程式行為。

3.18. 聯絡人

Android 提供 Contacts Provider API，可讓應用程式管理裝置上儲存的聯絡資訊。直接輸入裝置上的聯絡人資料通常會與網路服務保持同步，但資料「可能」只會儲存在裝置上。只儲存在裝置上的聯絡人稱為「本機聯絡人」。

當 ACCOUNT_NAME 時，RawContacts 會「與」或「儲存在」帳戶相關聯；而 ACCOUNT_TYPE，原始聯絡人的資料欄與帳戶的 Account.name 和 Account.type 欄位相符。

預設本機帳戶：這個帳戶用於儲存原始聯絡人，這些聯絡人只會儲存在裝置上，而未與 AccountManager 中的帳戶建立關聯，此角色的 ACCOUNT_NAME 和 ACCOUNT_TYPE 欄都會使用 null 值建立。

自訂本機帳戶：用於儲存原始聯絡人的帳戶，這些聯絡人只會儲存在裝置上，而未與 AccountManager 建立關聯，也就是在 ACCOUNT_NAME 和 ACCOUNT_TYPE 資料欄中設定至少一個非空值。

裝置實作方式：

  • [C-SR] 強烈建議不要建立自訂本機帳戶。

如果裝置實作項目使用自訂本機帳戶：

  • [C-1-1] 自訂本機帳戶的 ACCOUNT_NAME 必須在 ContactsContract.RawContacts.getLocalAccountName 前退回
  • [C-1-2] 自訂本機帳戶的 ACCOUNT_TYPE 必須在 ContactsContract.RawContacts.getLocalAccountType 前退回
  • [C-1-3] 必須使用預設本機帳戶 (即設定 ACCOUNT_NAME 和 ACCOUNT_TYPE 的空值) 由第三方應用程式插入的原始聯絡人，必須插入自訂本機帳戶。
  • [C-1-4] 新增或移除帳戶時，「不得」移除插入自訂本機帳戶中的原始聯絡人。
  • [C-1-5] 針對自訂本機帳戶執行的刪除作業「必須」立即清除原始聯絡人 (就像 CALLER_IS_SYNCADAPTER 參數設為 true 的情形)，即使 CALLER\_IS\_SYNCADAPTER 參數設為 false 或未指定。

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

裝置實作方式：

  • [C-0-1] 必須能夠安裝及執行 Android 官方 Android SDK 中「aapt」工具所產生的 Android「.apk」檔案。
  • 由於上述規定可能具有挑戰性，因此建議裝置的實作方式使用 Android 開放原始碼計畫參考資料實作項目的套件管理系統。

裝置實作方式：

  • [C-0-2] 必須支援使用 APK 簽署配置 v3、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。但即使如此，他們也應該向使用者說明沒有這類選擇的原因。

  • [C-0-7] 在由相同系統 API PackageManager.setHarmfulAppWarning 標示為可能有害的應用程式中，使用者啟動活動前，「必須」顯示含有警告字串的警告對話方塊 (透過系統 API PackageManager.setHarmfulAppWarning 提供給使用者)。

  • 「應」在警告對話方塊中提供讓使用者彈性選擇解除安裝或啟動應用程式的選項。

  • [C-0-8] 必須依照這裡的說明，導入漸進式檔案系統的支援功能。

  • [C-0-9] 必須支援使用 APK 簽署配置 v4 驗證 .apk 檔案。

  • 如果裝置實作的裝置已推出較舊的 Android 版本，且無法透過系統軟體更新符合 [C-0-8] 和 [C-0-9] 需求條件，就可能不受上述規定的限制。

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
  • [C-1-2] FLAC
  • [C-1-3] Opus

所有音訊編碼器都必須支援：

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-11] xHE-AAC (ISO/IEC 23003-3 擴充 HE AAC 設定檔)，內含 USAC 基準設定檔和 ISO/IEC 23003-4 動態範圍控制設定檔)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE 包括最高 24 位元的高解析度音訊格式、192 kHz 取樣率和 8 個聲道。請注意，這項規定僅適用於解碼，且裝置可在播放階段縮減取樣和減少混音。
  • [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_AAC_ENCODED_TARGET_LEVEL。
  • [SR] 強烈建議所有 AAC 音訊解碼器符合以上 C-2-1 和 C-2-2 規定。

解碼 USAC 音訊時，MPEG-D (ISO/IEC 23003-4)：

  • [C-3-1] 必須根據 MPEG-D DRC 動態範圍控制設定檔等級 1，解讀及套用粗糙度和 DRC 中繼資料。
  • [C-3-2] 解碼器「必須」根據使用下列 android.media.MediaFormat 鍵的設定集運作：KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_DRC_EFFECT_TYPE。

MPEG-4 AAC、HE AAC 和 HE AACv2 設定檔解碼器：

  • 使用 ISO/IEC 23003-4 動態範圍控制設定檔支援響亮度和動態範圍控制。

如果系統支援 ISO/IEC 23003-4，且在已解碼的位元中同時含有 ISO/IEC 23003-4 和 ISO/IEC 14496-3 中繼資料，那麼：

  • 優先採用 ISO/IEC 23003-4 中繼資料。

所有音訊解碼器「必須」支援輸出：

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，不可搜尋，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MPEG-4 HE AAC 設定檔 (AAC+) 支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
MPEG-4 HE AACv2
設定檔 (增強 AAC+) 		支援採用標準取樣率介於 16 至 48 kHz 的單聲道/立體聲/5.0/5.1 內容。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
AAC ELD (強化低延遲 AAC) 支援標準取樣率介於 16 至 48 kHz 的單聲道/立體聲內容。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4、.m4a)
USAC 支援標準取樣率介於 7.35 至 48 kHz 的單聲道/立體內容。 MPEG-4 (.mp4、.m4a)
AMR-NB 4.75 到 12.2 kbps 取樣 @ 8 kHz 3GPP (.3gp)
AMR-WB 9 速率從每秒 6.60 kbit 到 23.85 kbit/s 取樣 @ 16 kHz，定義請見 AMR-WB, Adaptive Multi-Rate - 寬頻語音轉碼器 3GPP (.3gp)
FLAC 編碼器和解碼器都需支援至少單聲道和立體聲模式。必須支援高達 192 kHz 的取樣率；必須支援 16 位元和 24 位元的解析度。FLAC 的 24 位元音訊資料處理「必須」支援浮點音訊設定。
  • FLAC (.flac)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MP3 單聲道/立體聲 8 至 320 Kbps 常數 (CBR) 或可變位元率 (VBR)
  • MP3 (.mp3)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • Matroska (.mkv，僅限解碼)
MIDI MIDI 類型 0 和 1。DLS 第 1 版和第 2 版。XMF 和 Mobile XMF。支援鈴聲格式 RTTTL/RTX、OTA 和 iMelody
  • 輸入 0 和 1 (.mid、.xmf、.mxmf)
  • RTTTL/RTX (.rtttl、.rtx)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • 馬特羅斯卡 (.mkv)
  • Webm (.webm)
PCM/WAVE PCM 轉碼器「必須」支援 16 位元線性 PCM 和 16 位元浮點值。WAVE 擷取器必須支援 16 位元、24 位元、32 位元的線性 PCM 和 32 位元浮點值 (達到硬體限制的速率)。取樣率必須在 8 kHz 至 192 kHz 之間。 WAVE (.wav)
Opus 解碼：支援單聲道、立體聲、5.0 和 5.1 內容，取樣率為 8000、12000、16000、24000 和 48000 Hz。
編碼：支援單聲道與立體聲內容，刷新率為 8000、14000、Hz 及 26000、Hz
  • Ogg (.ogg)
  • MPEG-4 (.mp4、.m4a，僅限解碼)
  • 馬特羅斯卡 (.mkv)
  • Webm (.webm)

5.1.4。圖片編碼

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

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

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

如果裝置實作方式支援透過 android.media.MediaCodec 為媒體類型 MIMETYPE_IMAGE_ANDROID_HEIC 使用 HEIC 編碼，即可：

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] 原始

如果裝置的實作支援 HEVC 影片解碼：* [C-1-1] 必須支援 HEIF (HEIC) 圖片解碼。

支援高位元深度格式 (每個通道 9 位元以上) 的圖片解碼器：

  • [C-2-1] 如果應用程式要求，必須支援輸出 8 位元對等格式，例如透過 android.graphics.Bitmap 的 ARGB_8888 設定。

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)
HEIF 圖片、圖片集合、圖片序列 HEIF (.heif)、HEIC (.heic)

透過 MediaCodec API 公開的圖片編碼器和解碼器

  • [C-1-1] 必須在 CodecCapabilities 之前，支援 YUV420 8:8:8 彈性顏色格式 (COLOR_FormatYUV420Flexible)。

  • [SR] 強烈建議在輸入 Surface 模式下支援 RGB888 色彩格式。

  • [C-1-3] 至少須支援 YUV420 8:8:8 的平面或半平面色 8:8:8 色彩格式：COLOR_FormatYUV420PackedPlanar (相當於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (相當於 COLOR_FormatYUV420SemiPlanar)。強烈建議你同時支援這兩種色彩格式。

5.1.7. 影片轉碼器

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

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

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

  • [C-1-2] 視訊編碼器和解碼器必須在 CodecCapabilities 之前，支援 YUV420 8:8:8 彈性色彩格式 (COLOR_FormatYUV420Flexible)。

  • [C-1-3] 影片編碼器和解碼器「必須」支援至少一種平面或半平面 YUV420 8:8:8 顏色格式：COLOR_FormatYUV420PackedPlanar (相當於 COLOR_FormatYUV420Planar) 或 COLOR_FormatYUV420PackedSemiPlanar (相當於 COLOR_FormatYUV420SemiPlanar)。強烈建議採用這兩種顏色來支援這兩種色彩。

  • [SR] 極力建議影片編碼器和解碼器至少支援硬體最佳化的平面或半平面 YUV420 8:8:8 色彩格式 (YV12、NV12、NV21 或同等供應商的最佳化格式)。

  • [C-1-5] 如果應用程式要求支援高位元深度格式 (每個頻道 9 位元以上)，則「必須」能夠支援輸出 8 位元等值格式 (如果應用程式要求的話)。請務必透過 android.media.MediaCodecInfo 支援 YUV420 8:8:8 色彩格式，才能反映這項資訊。

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

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

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

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

除非應用程式另外指定 KEY_COLOR_FORMAT 格式鍵，否則影片解碼器會實作：

  • [C-4-1] 如果透過 Surface 輸出進行設定，一律必須預設為針對硬體顯示器進行最佳化的顏色格式。
  • [C-4-2] 如果設為不使用 Surface 輸出，必須採用 YUV420 8:8:8 色彩格式，針對 CPU 讀取作業進行最佳化。

5.1.8。影片轉碼器清單

格式/轉碼器 詳細資料 支援的檔案類型/容器格式
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv，僅限解碼)
H.264 AVC 詳情請參閱第 5.2 節和第 5.3 節。
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts，無法搜尋)
  • Matroska (.mkv，僅限解碼)
H.265 HEVC 詳情請參閱第 5.3 節。
  • MPEG-4 (.mp4)
  • Matroska (.mkv，僅限解碼)
MPEG-2 主要個人資料
  • MPEG2-TS (.ts，無法搜尋)
  • MPEG-4 (.mp4，僅解碼)
  • Matroska (.mkv，僅限解碼)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv，僅限解碼)
VP8 詳情請參閱第 5.2 節和第 5.3 節。
VP9 詳情請參閱第 5.3 節。

5.1.9。媒體轉碼器安全性

裝置實作「必須」符合下述媒體轉碼器安全性功能的規定。

Android 支援 OMX (跨平台多媒體加速 API) 和低負載多媒體加速 API 轉碼器 2.0。

如果裝置導入方式支援多媒體，就會執行以下動作：

  • [C-1-1] 必須「必須」透過 OMX 或 Codec 2.0 API (或兩者皆有) 提供媒體轉碼器支援 (例如 Android 開放原始碼計畫中)，不得停用或規避安全保護措施。具體來說，這不表示每個轉碼器「必須」使用 OMX 或 Codec 2.0 API，而且至少「必須」支援其中一個 API，而且「必須」支援現有 API。
  • [C-SR] 強烈建議我加入 Codec 2.0 API 的支援。

如果裝置的實作不支援 Codec 2.0 API，就會：

  • [C-2-1] 必須針對裝置支援的每種媒體格式和類型 (編碼器或解碼器)，加入 Android 開放原始碼計畫中對應的 OMX 軟體轉碼器 (如果有的話)。
  • [C-2-2] 名稱開頭為「OMX.google」的轉碼器。必須採用 Android 開放原始碼計畫的原始碼。
  • [C-SR] 強烈建議 OMX 軟體轉碼器在轉碼器程序中執行，不能存取記憶體對應程式以外的硬體驅動程式。

如果裝置實作支援 Codec 2.0 API，就會發生以下情形：

  • [C-3-1] 必須針對裝置支援的每種媒體格式和類型 (編碼器或解碼器)，加入 Android 開放原始碼計畫 (如有) 中相應的轉碼器 2.0 軟體轉碼器。
  • [C-3-2] 「必須」在 Android 開放原始碼計畫中提供的軟體轉碼器程序中放置轉碼器 2.0 軟體轉碼器，才能縮小範圍授予軟體轉碼器的存取權。
  • [C-3-3] 名稱開頭為「c2.android」的轉碼器。必須採用 Android 開放原始碼計畫的原始碼。

5.1.10。媒體轉碼器字元化

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

  • [C-1-1] 「必須」透過 MediaCodecInfo API 傳回媒體轉碼器特性的正確值。

請特別注意以下幾點：

  • [C-1-2] 名稱開頭為「OMX」的轉碼器。必須使用 OMX API，且名稱符合 OMX IL 命名規範。
  • [C-1-3] 名稱開頭為「c2」的轉碼器。必須使用 Codec 2.0 API，且名稱符合 Android 的 Codec 2.0 命名規範。
  • [C-1-4] 名稱開頭為「OMX.google.」或「c2.android」的轉碼器。「不得」稱為供應商或硬體加速。
  • [C-1-5] 在轉碼器程序 (供應商或系統) 中執行的轉碼器若具備記憶體配置器和對應工具以外的硬體驅動程式，則「不得」僅歸類為軟體。
  • [C-1-6] 轉碼器不存在於 Android 開放原始碼專案中，或是不是以該專案的原始碼為依據。「必須」歸類為供應商。
  • [C-1-7] 必須使用硬體加速的轉碼器如硬體加速特性所定義。
  • [C-1-8] 轉碼器名稱不得誤導使用者。例如，名為「解碼器」的轉碼器「必須」支援解碼功能，而名為「編碼器」的轉碼器「必須」支援編碼功能。名稱包含媒體格式的轉碼器「必須」支援這些格式。

如果裝置導入方式支援視訊轉碼器：

  • [C-2-1] 所有視訊轉碼器「必須」發布下列大小的可達成影格速率資料 (如果轉碼器可支援)：
SD 標準畫質 (低品質) SD 標準畫質 (高品質) HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度
  • 176 x 144 px (H263、MPEG2、MPEG4)
  • 352 x 288 px (MPEG4 編碼器、H263、MPEG2)
  • 320 x 180 像素 (VP8，VP8)
  • 320 x 240 像素 (其他)
  • 704 x 576 像素 (H263)
  • 640 x 360 像素 (VP8，VP9)
  • 640 x 480 px (MPEG4 編碼器)
  • 720 x 480 像素 (其他)
  • 1408 x 1152 像素 (H263)
  • 1280 x 720 像素 (其他)
1920 x 1080 px (MPEG4 除外) 3840 x 2160 px (HEVC、VP9)
  • [C-2-2] 使用硬體加速技術的視訊轉碼器「必須」發布效能點資訊。這些樣本必須列出所有支援的標準效能點 (列於 PerformancePoint API 中)，除非這些面向在其他支援的標準效能點涵蓋範圍內。
  • 此外，如果除了上述任一項標準之外，還能提升影片成效，而你也必須發布更多的成效數據。

5.2. 影片編碼

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

  • 不應將超過兩個滑動窗口，超過兩個滑動窗口，高於內框 (I 影格) 間隔的位元率超過 15%。
  • 位元率不應超過 100% 超過滑動窗口 (1 秒)。

如果裝置實作項目具有長度至少 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 影片編碼器，並提供給第三方應用程式使用，它們：

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

如果裝置實作項目提供硬體加速視訊或圖片編碼器，並支援透過 android.camera API 公開的一或多個連接或可插式硬體攝影機：

  • [C-4-1] 所有硬體加速視訊和影像編碼器「必須」支援硬體相機的編碼影格。
  • 應支援硬體相機透過所有影片或圖片編碼器編碼的影格。

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 (高畫質) 影片編碼設定檔。
  • [C-1-2] 必須支援編寫 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 轉碼器，就會：

  • [C-1-2] 必須支援個人資料 0 第 3 級。
  • [C-1-1] 必須支援編寫 Matroska WebM 檔案。
  • [C-1-3] 必須產生 CodecPrivate 資料。
  • 「應」支援 HD 高畫質解碼設定檔，如下表所示。
  • 若有硬體編碼器，[SR] 極力建議支援 HD 解碼設定檔，如下表所示。
SD 標準畫質 HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 30 fps 30 fps 30 fps 30 fps
影片位元率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果裝置實作項目聲稱可透過 Media API 支援 Profile 2 或 Profile 3：

  • 支援 12 位元格式。

5.2.5。H.265

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

  • [C-1-1] 必須支援主要設定檔第 3 級。
  • 應支援下表所示的 HD 高畫質編碼設定檔。
  • 如果有硬體編碼器，[SR] 極力建議支援 HD 高畫質編碼設定檔，如下表所示。
SD 標準畫質 HD 高畫質 720p HD 高畫質 1080p UHD 超高畫質
影片解析度 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
影片畫面更新率 30 fps 30 fps 30 fps 30 fps
影片位元率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3. 影片解碼

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

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

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

如果裝置的實作方式宣稱可透過 Media API 支援 HDR 設定檔，請執行以下操作：

  • [C-3-1] 裝置實作「必須」接受應用程式所需的 HDR 中繼資料，並支援從位元流和/或容器擷取及輸出所需的 HDR 中繼資料。
  • [C-3-2] 裝置的實作「必須」在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

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

如果裝置實作項目宣告透過 'CodecProfileLevel' 媒體 API 支援 VP9Profile2 或 VP9Profile3：

  • 支援 12 位元格式。

如果裝置的實作方式宣稱可透過媒體 API 支援 HDR 設定檔 (VP9Profile2HDR、VP9Profile2HDR10Plus、VP9Profile3HDR、VP9Profile3HDR10Plus)：

  • [C-4-1] 裝置實作「必須」從應用程式接受必要的 HDR 中繼資料 (所有 HDR 設定檔皆為 KEY_HDR_STATIC_INFO，HDR10Plus 設定檔則使用 'KEY_HDR10_PLUS_INFO')。也「必須」支援從位元流和/或容器擷取及輸出所需的 HDR 中繼資料。
  • [C-4-2] 裝置的實作「必須」在裝置螢幕或標準視訊輸出連接埠 (例如HDMI)。

5.3.8。Dolby Vision

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

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

5.3.9。AV1

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

  • [C-1-1] 必須支援 Profile 0，其中包含 10 位元內容。

5.4. 錄音

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

5.4.1。原始音訊擷取和麥克風資訊

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

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

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

  • 應提供符合下列特性的原始音訊內容：

    • 格式：線性 PCM、16 位元和 24 位元
    • 取樣率：8000、11025、16000、22050、24000、32000、44100、48000 Hz
    • 聲道：裝置的麥克風數量越多頻道數量。

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

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

  • 應允許 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.4.4。聲學回聲降噪

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

  • 應導入 Acoustic Echo canceler (AEC) 技術，專門針對語音通訊加以調整，且在使用 AudioSource.VOICE_COMMUNICATION 拍攝時，會套用到擷取路徑。

如果裝置實作提供會在選取 AudioSource.VOICE_COMMUNICATION 時插入擷取音訊路徑中的聲學回音取消工具，則會：

5.4.5。並行擷取

如果裝置實作程序宣告 android.hardware.microphone，則「必須」按照本文件所述實作並行擷取。詳細說明：

  • [C-1-1] 「必須」允許無障礙服務透過 AudioSource.VOICE_RECOGNITION 擷取，且至少有一個應用程式以任何 AudioSource 擷取的應用程式同時存取麥克風。
  • [C-1-2] 必須允許預先安裝的應用程式並行存取麥克風，且該應用程式具備 Google 助理角色，且至少有一個應用程式使用任何 AudioSource (AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 除外) 擷取麥克風。
  • [C-1-3] 除無障礙服務外，如果應用程式使用 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 擷取內容，必須關閉其他應用程式的音訊擷取功能。但是，當應用程式透過 AudioSource.VOICE_COMMUNICATION 擷取時，如果應用程式具備 CAPTURE_AUDIO_OUTPUT 權限 (預先安裝) 權限，則可擷取語音來電。
  • [C-1-4] 如果有兩個以上的應用程式同時擷取，而且在上方都沒有使用者介面，則啟動擷取最近音訊的應用程式。

5.4.6。麥克風提升音量

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

  • 應該在中頻範圍中表現出近乎平坦的振幅與頻率特性：特別是從 100 Hz 到 4000 Hz 的 ±3dB，每個用來錄製語音辨識音訊來源的麥克風也要有這種特性。
  • 應設定音訊輸入靈敏度，以便在以 90 dB 音壓等級 (SPL) 播放的 1000 Hz 內音色調源產生一個 RMS 為 2500 的 RMS 回應 (針對浮點數/每個音訊樣本使用 -22.35 dB 完整聲道，且每個語音樣本錄音和精度取樣為雙重音)。
  • [C-SR] 強烈建議在低頻率範圍內展現振幅：具體來說，以 5 Hz 到 100 Hz 的範圍而言，比起錄製語音辨識音訊來源的每個麥克風的中頻範圍相比，特別是 ±20 dB。
  • [C-SR] 強烈建議在高頻率範圍內展現振幅：特別是從 4000 Hz 到 22 KHz 的 ±30 dB，這是與錄製語音辨識音訊來源的每個麥克風的中頻率範圍相比。

5.5. 音訊播放

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

5.5.1。原始音訊播放

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

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

    • 來源格式：線性 PCM、16 位元、8 位元、浮點值
    • 聲道：單聲道、立體聲、有效的多頻道設定，最多可包含 8 個頻道
    • 取樣率 (以 Hz 為單位)：
      • 以上述管道設定啟用 8000、11025、16000、22050、32000、44100、48000
      • 96000 (單聲道和立體聲)

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

    • 取樣率：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 類別控制。
  • [C-1-3] 必須支援透過 AudioEffect 子類別 DynamicsProcessing 使用 EFFECT_TYPE_DYNAMICS_PROCESSING 實作控制項。
  • 應支援可透過 AudioEffect 子類別 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 實作項目。
  • [C-SR] 極力建議支援浮點和多管道特效。

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 組合。
  • 時間戳記：組合包含串流中的相對影格位置，以及該影格進入或離開相關端點音訊處理管道的預估時間。另請參閱 AudioTimestamp。
  • 音訊訊號的暫時性中斷或樣本值不正確，通常是因為輸出的緩衝區不足、針對輸入的緩衝區過度，或是任何其他數位或類比噪音來源所致。

如果裝置實作項目宣告 android.hardware.audio.output，則必須符合下列規定：

  • [C-1-1] AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 傳回的輸出時間戳記準確為 +/- 2 毫秒。
  • [C-1-2] 冷輸出延遲時間不超過 500 毫秒。

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

  • [C-SR] 冷輸出延遲時間不超過 100 毫秒。凡是搭載此 Android 版本的現有裝置和新裝置，都「極力」建議現在符合這些規定。針對 2021 年日後推出的平台版本，我們規定的冷輸出延遲時間必須小於 200 毫秒。
  • [C-SR] 連續輸出延遲時間不超過 45 毫秒。
  • [C-SR] 盡量減少冷輸出時基誤差。
  • [C-SR] AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 傳回的輸出時間戳記準確為 +/- 1 毫秒。

如果裝置的實作方式符合上述要求，則在初始校正後，同時使用 OpenSL ES PCM 緩衝區佇列和 AAudio 原生音訊 API 時，至少在一部支援的音訊輸出裝置上，會出現連續輸出延遲和冷輸出延遲時間：

如果裝置實作不符合透過 OpenSL ES PCM 緩衝區佇列和 AAudio 原生音訊 API 的低延遲音訊需求，則會造成：

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

如果裝置實作項目包含 android.hardware.microphone，則必須符合下列輸入音訊規定：

  • [C-3-1] 將輸入時間戳記中的錯誤 (由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回) 限制為 +/- 2 毫秒。這裡的「錯誤」是指與正確值的差異。
  • [C-3-2] 冷輸入延遲時間不超過 500 毫秒。

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

  • [C-SR] 冷輸入延遲時間不超過 100 毫秒。凡是搭載此 Android 版本的現有裝置和新裝置，都「極力」建議現在符合這些規定。針對 2021 年日後推出的平台版本，我們規定「必須」的情況，將冷輸入延遲時間設為 200 毫秒以下。
  • [C-SR] 連續輸入延遲時間不超過 30 毫秒。
  • [C-SR] 連續往返延遲時間不超過 50 毫秒。
  • [C-SR] 盡量減少冷輸入時基誤差。
  • [C-SR] 將輸入時間戳記中的錯誤 (由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 傳回) 限制為 +/- 1 毫秒。

5.7. 網路通訊協定

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

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

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

  • [C-1-2] 必須支援下方 HTTP 即時串流草稿通訊協定 (第 7 版) 中所列出的媒體區隔格式表格格式。

  • [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)

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

  • [C-1-1] 必須「一律」透過支援 MIDI 的「所有」硬體傳輸 (MIDI) 支援 MIDI，這類傳輸方式提供一般的非 MIDI 連線：

  • [C-1-2] 必須支援跨應用程式 MIDI 軟體傳輸 (虛擬 MIDI 裝置)

  • [C-1-3] 必須包含 libamidi.so (原生 MIDI 支援)

  • 應支援 7.7 節的 USB 週邊裝置模式支援 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 和至少一個 AAudio 原生音訊 API 路徑，才符合延遲時間和 USB 音訊規定。
  • [SR] 強烈建議你透過 MMAP 路徑使用 AAudio 原生音訊 API，以符合延遲時間和 USB 音訊要求。
  • [C-1-6] 冷輸出延遲時間不得超過 200 毫秒。
  • [C-1-7] 冷輸入延遲時間不得超過 200 毫秒。
  • [SR] 強烈建議使用音訊，且 CPU 負載會改變，確保 CPU 效能一致。請使用 Android 應用程式版本的 SynthMark 修訂版本 ID 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 進行測試。SynthMark 使用的軟體合成器在模擬音訊架構中運作，以測量系統效能。SynthMark 應用程式必須使用「Automated Test」選項執行，並達到下列結果：
    • Voicemark.90 >= 32 種語音
    • timemark.fixed.little <= 15 毫秒
    • etcmark.dynamic.little <= 50 msec

如需基準測試的相關說明，請參閱 SynthMark 說明文件。

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

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

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

如果裝置實作方式省略 4 導體 3.5 公釐耳機插孔，並納入支援 USB 主機模式的 USB 連接埠，裝置就會執行以下動作：

  • [C-3-1] 必須實作 USB 音訊類別。
  • [C-3-2] 在使用 USB 主機模式連接埠的 USB 主機模式連接埠上，往返音訊延遲時間不得超過 20 毫秒，且必須使用 USB 音訊類別。
  • 使用 USB 音訊類別的 USB 主機模式連接埠時，連續往返音訊延遲時間應小於 10 毫秒。
  • [C-SR] 強烈建議「極力」支援同時支援多達 8 個 I/O 聲道，並支援每個方向最多 8 個通道，搭配 96 kHz 取樣率，以及 24 位元或 32 位元深度 (如果與同時支援這些要求的 USB 音訊週邊裝置)。

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

  • 至少應在一項配置中，以 20 位元或 24 位元深度和 192 kHz 的立體聲輸出和八個聲道輸出，而且沒有位元深度損失或重新取樣。

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 和 Android 開放原始碼計畫提供的殼層指令，供應用程式開發人員使用，包括 dumpsys cmd stats
    • [C-0-11] 必須支援殼層指令 cmd testharness。若是沒有永久資料區塊，就從舊版 Android 升級裝置實作項目，不受 C-0-11 的規範。
    • [C-0-3] 不得變更透過 dumpsys 指令記錄的裝置系統事件 (batterystats、Diskstats、指紋、graphicstats、netstats、notification、 procstats) 的格式或內容。
    • [C-0-10] 請務必進行記錄 (不可省略)，並開放 cmd stats 殼層指令和 StatsManager 系統 API 類別存取下列事件。
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrash 發生
      • AppStart 發生 rred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarm 發生 rred
      • WifiLockStateChanged
      • WifiMulticastLockState 已變更
      • WifiScanStateChanged
    • [C-0-4] 裝置端 ADB Daemon 必須預設為停用，且該機制必須可讓使用者存取，才能啟用 Android Debug Bridge。
    • [C-0-5] 必須支援安全 ADB。Android 支援安全 ADB。安全 ADB 可在已知的已驗證主機上啟用 ADB。
    • [C-0-6] 必須提供讓 ADB 從主機機器連線的機制。詳細說明：

    如果裝置的實作項目在沒有 USB 連接埠的情況下支援週邊裝置模式，就會發生以下情形：

    • [C-3-1] 必須透過區域區域網路 (例如乙太網路或 Wi-Fi) 實作 ADB。
    • [C-3-2] 必須提供 Windows 7、8 和 10 的驅動程式，讓開發人員使用 ADB 通訊協定連接裝置。

    如果裝置的實作支援透過 Wi-Fi 連至主體機器的 ADB 連線，就會：

    • [C-4-1] 必須讓 AdbManager#isAdbWifiSupported() 方法傳回 true。

    如果裝置的實作支援透過 Wi-Fi 連至主機機器的 ADB 連線，且包含至少一部相機，那麼：

    • [C-5-1] 必須讓 AdbManager#isAdbWifiQrSupported() 方法傳回 true。

  • 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。
  • Perfetto
    • [C-SR] 強烈建議向殼層使用者公開 /system/bin/perfetto 二進位檔 (cmdline 須符合 Perfetto 說明文件)。
    • [C-SR] 極力建議接受 Perfetto 二進位檔，做為輸入 protobuf 設定，且符合 perfetto 說明文件中定義的結構定義。
    • [C-SR] 極力建議您根據 Perfetto 說明文件中定義的結構定義，將 Perfetto 二進位檔寫入為輸出內容 protobuf 追蹤記錄。
    • [C-SR] 強烈建議透過 Perfetto 二進位檔提供至少 Perfetto 說明文件中所述的資料來源。
  • 低記憶體終止工具
    • [C-0-10] 當低記憶體終止工具終止應用程式時，「必須」將 LMK_KILL_OCCURRED_FIELD_NUMBER Atom 寫入統計資料記錄。
  • 測試控管工具模式如果裝置實作項目支援殼層指令 cmd testharness 並執行 cmd testharness enable，就會執行以下動作：

如果裝置實作項目透過 android.hardware.vulkan.version 功能旗標回報支援 Vulkan 1.0 以上版本，程式碼會：

  • [C-1-1] 「必須」提供應用程式預設用途，讓應用程式開發人員啟用/停用 GPU 偵錯圖層。
  • [C-1-2]「必須」啟用 GPU 偵錯圖層時，列舉外部工具 (即非平台或應用程式套件) 提供的程式庫圖層。這些程式庫位於可進行偵錯的應用程式基本目錄中，即可支援 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。

6.2. 開發人員選項

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

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

  • [C-0-1] 必須遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS 意圖，以顯示應用程式開發相關設定。在上游 Android 實作項目中，「開發人員選項」選單預設為隱藏，使用者只要依序點選「設定」 >「關於裝置」 >「版本號碼」選單項目七 (7) 次，即可啟動開發人員選項。
  • [C-0-2] 必須預設隱藏開發人員選項。
  • [C-0-3] 必須針對啟用開發人員選項，提供明確的機制，使應用程式無法優先採用其他應用程式。「必須」提供可公開查看的文件或網站，並說明如何啟用開發人員選項。這份文件或網站必須能從 Android SDK 文件連結。
  • 如果已啟用開發人員選項，且有顧慮到使用者安全，就應持續向使用者顯示視覺通知。
  • 可能會暫時限制「開發人員選項」選單的存取權，例如隱藏或停用選單，以免在顧慮使用者安全的情況下受到干擾。

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 版面配置的功能，以確保第三方應用程式能在各種硬體設定上正常運作。在 Android 相容螢幕上，所有第三方 Android 相容應用程式皆可執行，裝置實作「必須」正確實作這些 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] 必須如 Android SDK 說明文件所述，透過 AndroidManifest.xml 中的 <supports-screens> 屬性，正確遵循應用程式所聲明的螢幕大小支援。

  • 可能具備與 Android 相容的螢幕(圓角設計)。

如果裝置實作項目支援 UI_MODE_TYPE_NORMAL，且提供有圓角的 Android 相容螢幕，就會執行以下動作：

  • [C-1-1] 必須確保符合下列至少一項條件：
  • 圓角的半徑小於或等於 38 dp。

  • 將 15 dp x 15 dp 的方塊固定在邏輯螢幕的各角落時，每個方塊至少要有一個像素顯示在畫面中。

  • 應提供使用者預設用途，切換為以矩形邊角切換至顯示模式。

如果裝置實作項目包含與 Android 相容的摺疊式螢幕，或是在多個螢幕面板之間加入折疊轉軸，並為第三方應用程式提供這類螢幕，就會：

如果裝置實作項目包含與 Android 相容的摺疊式螢幕，或是在多個顯示面板之間設置折疊轉軸，而且轉軸或折疊跨越全螢幕應用程式視窗，就會執行以下動作：

  • [C-3-1] 必須向應用程式回報轉軸或折疊的位置、邊界和狀態。

如要進一步瞭解如何正確實作補充資訊或擴充功能 API，請參閱 Window Manager Jetpack 的公開說明文件。

7.1.1.2。螢幕顯示比例

雖然 Android 相容螢幕的實體螢幕顯示比例沒有限制，但第三方應用程式算繪位置的邏輯螢幕顯示比例可能衍生自透過 view.Display API 和 Configuration API 所回報的高度和寬度值，但必須符合下列規定：

  • [C-0-1] 在 Configuration.uiMode 設為 UI_MODE_TYPE_NORMAL 的情況下，裝置實作的顯示比例值必須小於或等於 1.86 (約 16:9)，除非應用程式符合下列任一條件：

  • [C-0-2] Configuration.uiMode 設為 UI_MODE_TYPE_NORMAL 的裝置實作項目，顯示比例值必須大於或等於 1.3333 (4:3)，除非應用程式符合下列任一條件才能延展：

  • [C-0-3] Configuration.uiMode 設為 UI_MODE_TYPE_WATCH 的裝置實作項目必須設為 1.0 (1:1)。

7.1.1.3. 螢幕密度

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

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

  • 裝置實作項目「必須」定義最接近螢幕實體密度的標準 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. 顯示指標

如果裝置導入方式包含與 Android 相容的螢幕或影片輸出內容，且可輸出至 Android 相容螢幕，就會：

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

  • [C-2-1] 必須針對模擬的預設 view.Display，回報 android.util.DisplayMetrics API 中定義的 Android 相容螢幕的正確值。

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.1 和 2.0，詳情請參閱 Android SDK 說明文件。
  • [C-SR] 強烈建議支援 OpenGL ES 3.1。
  • 應支援 OpenGL ES 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 和 EGL_ANDROID_GLES_layers 的擴充功能。
  • [C-SR] 強烈建議支援 EGL_KHR_partial_update 和 OES_EGL_image_external 擴充功能。
  • 應透過 getString() 方法正確回報，也就是他們支援的任何紋理壓縮格式，通常僅適用於供應商。

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

  • [C-3-1] 除了 OpenGL ES 2.0 程式庫中的 OpenGL ES 2.0 函式符號外，「C-3-1」還必須匯出這些版本對應的函式符號。
  • [SR] 強烈建議支援 OES_EGL_image_external_essl3 擴充功能。

如果裝置的實作支援 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.1，就會發生以下情形：

  • [SR] 強烈建議加入對 Vulkan 1.1 的支援。

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

  • 應支援 Vulkan 1.1。

Vulkan dEQP 測試分成多個測試清單，每個清單都有相關聯的日期/版本。這些位於 external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt 的 Android 原始碼樹狀結構中。如果裝置在自行回報的層級支援 Vulkan，即表示裝置通過此層級和以下版本的所有測試清單，皆能通過 dEQP 測試。

如果裝置實作項目支援 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 支援的擴充功能字串，相反地，也「不得」回報未正確支援的擴充功能字串。
  • [C-1-7] 必須支援 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 擴充功能。
  • [C-1-8] 必須向透過 android.software.vulkan.deqp.level 功能旗標回報支援的 Vulkan dEQP 測試最高版本。
  • [C-1-9] 至少必須支援 132317953 版 (自 2019 年 3 月 1 日起)，如 android.software.vulkan.deqp.level 功能標記中所述。
  • [C-1-10] 必須在 132317953 版本與 android.software.vulkan.deqp.level 功能標記中指定的版本之間，通過測試清單中的所有 Vulkan dEQP 測試。
  • [C-SR] 極力建議支援 VK_KHR_driver_properties 和 VK_GOOGLE_display_timing 擴充功能。

如果裝置實作項目不支援 Vulkan 1.0，就會：

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

如果裝置實作項目包含對 Vulkan 1.1 的支援，並宣告任何 Vulkan 功能旗標，就會：

  • [C-3-1] 必須公開對 SYNC_FD 外部路徑和處理常式類型以及 VK_ANDROID_external_memory_android_hardware_buffer 擴充功能的支援。
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 中，「必須」具備總域的 DCI-P3 至少 90% 的面積。
  • [C-1-4] 必須支援 OpenGL ES 3.1 或 3.2，並妥善回報。
  • [C-1-5] 必須宣傳 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、EGL_EXT_gl_colorspace_display_p3、EGL_EXT_gl_colorspace_display_p3_linear 和 EGL_EXT_gl_colorspace_display_p3_passthrough 額外資訊的支援。
  • [C-SR] 強烈建議你支援 GL_EXT_sRGB。

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

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

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

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

7.1.6。螢幕技術

Android 平台中的 API 可讓應用程式將豐富的圖形算繪至與 Android 相容的顯示器。除非本文件特別許可，否則裝置「必須」支援 Android SDK 定義的所有 API。

裝置實作的所有 Android 相容螢幕：

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

7.1.7. 第二螢幕

Android 支援次要 Android 相容螢幕，以啟用媒體分享功能，並使用開發人員 API 存取外部螢幕。

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

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

7.2. 輸入裝置

裝置實作方式：

7.2.1。鍵盤

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

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

7.2.2。非觸控瀏覽

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

裝置實作方式：

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

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

7.2.3. 瀏覽鍵

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

  • [C-0-1] 如果已安裝的應用程式具有以 ACTION=MAIN 和 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER 設置的 <intent-filter> 活動，則只有在應用程式實作時才能啟動。首頁功能「必須」做為這項使用者預設用途的機制。
  • 應提供「近期」和「返回」函式的按鈕。

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

  • [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 所述)。

如果系統以手勢動作的形式提供導覽功能：

如果有從目前螢幕方向左側和右側邊緣的任何位置提供導覽函式：

  • [C-7-1] 「必須」返回，並在目前螢幕方向從左側和右側邊緣往右滑動時提供。
  • [C-7-2] 如果提供自訂滑動系統面板於左側或右側邊緣，「必須」放置在螢幕頂端 1/3 處，同時清楚顯示持續性的視覺指示，讓使用者藉由拖曳操作會叫用上述面板，因此不會返回。系統面板「可」設置在畫面邊緣頂端 1/3 的下方，但系統面板「不得」使用超過邊緣的 1/3。
  • [C-7-3] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 旗標，從邊緣滑動行為「必須」與 Android 開放原始碼計畫實作相同，詳情請參閱 SDK 中記錄。
  • [C-7-4] 如果前景應用程式已設定 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 旗標，則「必須」隱藏自訂滑動系統面板，直到使用者開啟 Android 開放原始碼計畫提供的系統資訊列 (又稱為導覽列和狀態列) 為止。

7.2.4。觸控螢幕輸入

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

裝置實作方式：

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

如果裝置實作項目在 Android 主要相容螢幕上提供觸控螢幕 (單點觸控或更優異的功能)，裝置會支援以下做法：

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

如果裝置導入方式包含觸控螢幕，可在 Android 主要相容螢幕上追蹤多次觸控，則支援以下程式碼：

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

如果裝置實作時需要使用滑鼠或軌跡球等外部輸入裝置 (例如未直接觸碰螢幕)，以便在 Android 相容主要螢幕上輸入，並且符合第 7.2.5 節的觸控手勢要求，就會執行以下動作：

  • [C-3-1] 「不得」回報任何開頭為 android.hardware.touchscreen 的功能標記。
  • [C-3-2] 必須只回報android.hardware.faketouch。
  • [C-3-3] 必須回報 Configuration.touchscreen API 欄位的 TOUCHSCREEN_NOTOUCH。

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] 必須支援向下指標，然後讓使用者能夠快速將物件移到螢幕上的不同位置，然後向上移動在螢幕上的方向，使用者就能快速將物件擲回螢幕上。

如果裝置實作項目宣告支援 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。按鈕對應

裝置實作方式：

  • [C-1-1] 必須能將 HID 事件對應至對應的 InputEvent 常數，如下表所示。Android 上游實作符合這項規定。

如果裝置導入方式內嵌控制器或隨附獨立控制器，可供使用者輸入下表列出的所有事件，請注意：

  • [C-2-1] 必須宣告功能標記 android.hardware.gamepad
按鈕 HID 用量2 Android 按鈕
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-Pad1
D-Pad1 		0x01 0x00393 AXIS_HAT_Y4
D-Pad 向左1
D-Pad 向右鍵1 		0x01 0x00393 AXIS_HAT_X4
左肩按鈕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，才能回報感應器資料，延遲時間最長為 0 毫秒。此延遲未包含任何篩選延遲。
  • [C-1-3] 必須在感應器啟用的 400 毫秒 + 2 * sample_time 內，回報第一個感應器樣本。此樣本的準確率為 0，可以接受。
  • [C-1-4] 如果 Android SDK 說明文件指出的 API 是連續的感應器，裝置實作項目「必須」持續提供時基誤差低於 3% 的定期資料樣本，其中時基誤差的定義為連續事件回報的時間戳記值差異的標準差。
  • [C-1-5] 必須確保感應器事件串流「不得」阻止裝置 CPU 進入暫停狀態或從暫停狀態喚醒。
  • [C-1-6] 必須按照 Android SDK 說明文件的定義，以奈秒回報事件時間，代表事件發生的時間，並與 SystemClock.elapsedRealtimeNano() 時鐘保持同步。
  • [C-SR] 強烈建議將時間戳記同步處理錯誤維持在 100 毫秒以下，且應該將時間戳記同步處理錯誤維持在 1 毫秒以下。
  • 如果啟用多個感應器，耗電量不應超過個別感應器回報的耗電量總和。

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

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

  • [C-1-6] 必須為所有感應器設定非零的解析度，並透過 Sensor.getResolution() API 方法回報該值。

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

裝置實作方式：

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

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

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

如果裝置實作項目包含特定感應器類型，且該類型具有第三方開發人員適用的 API，且感應器只會回報一個值，然後執行裝置實作：

  • [C-3-1] 請務必將感應器的解析度設為 1，並透過 Sensor.getResolution() API 方法回報這個值。

如果裝置的實作方式包含支援 SensorAdditionalInfo#TYPE_VEC3_CALIBRATION 的特定感應器類型，並且向第三方開發人員公開感應器，那麼：

  • [C-4-1] 請勿在提供的資料中加入任何固定的原廠校正參數。

如果裝置的實作方式包括 3 軸式加速度計、3 軸式陀螺儀感應器或磁力儀感應器，它們是：

  • [C-SR] 強烈建議確保加速計、陀螺儀和磁力儀具有固定的相對位置，這樣一來，如果裝置可進行轉換 (例如折疊式裝置)，感應器軸會在所有可能的裝置轉換狀態下，與感應器座標系統保持一致並保持一致。

7.3.1。加速計

裝置實作方式：

  • [C-SR] 強烈建議加入 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 裝置符合這項規定，以便升級至未來平台版本，且此版本可能為「必要」。
  • 請務必按照 Android SDK 文件所述，實作 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 複合感應器。
  • 回報的事件大小必須至少為 200 Hz。
  • 解析度至少要有 16 位元。
  • 如果生命週期內的特性會隨生命週期變化並補償，使用時應進行校正，並保留裝置重新啟動之間的補償參數。
  • 應以體溫為準。

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

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

如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀感應器，請按照下列步驟進行：

  • [C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
  • [C-SR] 強烈建議導入 TYPE_GAME_ROTATION_VECTOR 複合感應器。

如果裝置實作方式包括 3 軸式加速度計、3 軸式陀螺儀感應器和磁力儀感應器，它們：

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

7.3.2。磁力儀

裝置實作方式：

  • [C-SR] 強烈建議你加入 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 的標準差。
  • [C-SR] 強烈建議導入 TYPE_MAGNETIC_FIELD_UNCALIBRATED 感應器。

如果裝置實作方式包括 3 軸式磁力計、加速計感應器和 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

裝置實作方式：

  • [C-SR] 強烈建議加入 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 鎖定時間 (輔助資料包含參考時間、參考位置和衛星電話/時鐘)。
    • [C-1-6] 進行這類位置計算後，裝置在計算位置時，「必須」判斷所在位置 (在開放天空、5 秒內、重新啟動位置資訊要求後，最多一小時後、首次計算位置要求後一小時內，以及/或在重新開機後提出後續要求)。

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

    • [C-1-3] 必須能夠判斷所在位置在 20 公尺以內，且速度在每秒 0.5 公尺以內，且時間至少為 95%。
    • [C-1-4] 必須同時透過至少 8 個星座衛星的 GnssStatus.Callback 同時追蹤及回報情況。
    • 至少要能夠同時從多個星座 (例如 GPS 加上至少 24 個星座、北斗、Galileo) 追蹤。
    • [C-SR] 極力建議在緊急電話通話期間，持續透過 GNSS Location Provider API 提供正常的 GPS/GNSS 定位資訊。
    • [C-SR] 強烈建議「強烈建議」針對追蹤的所有星座 (如 GnssStatus 訊息所報告) 記錄 GNSS 測量結果 (SBAS 除外)。
    • [C-SR] 強烈建議使用記錄 AGC 和 GNSS 測量頻率。
    • [C-SR] 強烈建議將每個 GPS/GNSS 位置的所有準確度預估值 (包括航向、速度和產業資料) 回報給我們。
    • [C-SR] 強烈建議「強烈建議」在找到 GNSS 測量資料後就立即回報，即使尚未回報 GPS/GNSS 計算的位置資料也一樣。
    • [C-SR] 強烈建議「不要」回報 GNSS 虛擬範圍和虛擬範圍比率。在確定地點的開放天空條件下，如果靜止或移動的加速度低於每秒 0.2 公尺，就足以在每秒 0.2 公尺範圍內計算 GNSS 虛擬範圍，且每秒 0.2 公尺以內速度至少應達到 95%。

7.3.4。陀螺儀

裝置實作方式：

  • [C-SR] 強烈建議你加入陀螺儀感應器。

如果裝置實作方式包含 3 軸式迴轉儀，程式碼會：

  • [C-1-1] 必須能夠以至少 50 Hz 的頻率回報事件。
  • [C-1-2] 必須導入 TYPE_GYROSCOPE 感應器，且強烈建議一併導入 TYPE_GYROSCOPE_UNCALIBRATED 感應器。
  • [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] 大力「建議」在裝置溫度靜止不動時，校正錯誤應小於 0.01 雷/秒。
  • 回報的事件大小必須至少為 200 Hz。

如果裝置實作項目包含 3 軸式迴轉儀、加速計感應器和磁力儀感應器，請執行以下操作：

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

如果裝置導入方式包含 3 軸式加速度計和 3 軸式迴轉儀感應器，請按照下列步驟進行：

  • [C-3-1] 必須實作 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 複合感應器。
  • [C-SR] 強烈建議導入 TYPE_GAME_ROTATION_VECTOR 複合感應器。

7.3.5。氣壓計

裝置實作方式：

  • [C-SR] 強烈建議你加入氣壓計 (環境氣壓感應器)。

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

  • [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。溫度計

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

  • [C-1-1] 必須定義環境溫度感應器的 SENSOR_TYPE_AMBIENT_TEMPERATURE，且感應器「必須」以攝氏度數的方式測量使用者與裝置互動時的環境 (房間/車廂) 溫度。

如果裝置實作項目包含可測量環境溫度 (例如 CPU 溫度) 的溫度計感應器，便會採取下列做法：

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 公克之間，且極度建議使用介於 -16 公克和 +16 公克之間的測量範圍。
    • 解析度至少須為 2048 LSB/g。
    • 測量頻率不得低於 12.5 Hz。
    • 測量頻率上限為 400 Hz；應支援 SensorDirectChannel RATE_VERY_FAST。
    • 測量噪音必須超過 400 μg/√Hz。
    • 這個感應器必須實作至少 3,000 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
    • 批次耗電量不得低於 3 mW。
    • [C-SR] 強烈建議使用 3dB 測量頻寬 (Nyquist 頻率) 80% 以上，白色雜訊光譜範圍則在此頻寬中。
    • 應在室溫環境下測試隨機步行速度低於 30 μg √Hz。
    • 應有偏誤變化，而不是溫度 ≤ +/- 1 毫克/°C。
    • 應採用 ≤ 0.5% 且靈敏度與溫度變化 (與溫度 ≤ 0.03%/C°) 的非線性體系非線性性為最佳。
    • 在裝置運作溫度範圍內，跨軸敏感度應小於 2.5%，跨軸敏感度則小於 0.2%。

  • [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；應支援 SensorDirectChannel RATE_VERY_FAST。
    • 測量噪音必須超過 0.014°/s/√Hz。
    • [C-SR] 強烈建議使用 3dB 測量頻寬 (Nyquist 頻率) 80% 以上，白色雜訊光譜範圍則在此頻寬中。
    • 應在室溫下，進行低於 0.001 °/s √ 的隨機步行速率。
    • 應該有偏誤變化，而不是溫度 ≤ +/- 0.05 °/ s / °C。
    • 應有靈敏度變化，但溫度應為 ≤ 0.02% / °C。
    • 應有最佳的非線性廣告非線性性，且 ≤ 0.2%。
    • 雜訊密度必須小於 0.007 °/s/√Hz。
    • 裝置靜止時，應在溫度範圍 10 到 40 °C 之間，發生低於 0.002 rad/s 的校準錯誤。
    • 應靈敏度小於 0.1°/s/g。
    • 在裝置運作溫度範圍內，跨軸敏感度應小於 4.0%，跨軸敏感度變化應小於 0.3%。

  • [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED 必須具有與 TYPE_GYROSCOPE 相同的品質規定。

  • [C-2-5] 必須具有下列 TYPE_GEOMAGNETIC_FIELD 感應器：

    • 測量範圍必須至少介於 -900 到 +900 μT 之間。
    • 測量解析度至少須為 5 LSB/uT。
    • 測量頻率至少須為 5 Hz 以下。
    • 測量頻率上限為 50 Hz 以上。
    • 測量雜訊量必須大於 0.5 uT。

  • [C-2-6] 的 TYPE_MAGNETIC_FIELD_UNCALIBRATED 品質規定必須與 TYPE_GEOMAGNETIC_FIELD 相同，並且符合下列條件：

    • 這個感應器必須實作至少 600 個感應器事件的緩衝功能，才能實作這個感應器的非喚醒形式。
    • [C-SR] 如果報表速率為 50 Hz 以上，強烈建議使用從 1 Hz 到至少 10 Hz 的白雜訊頻譜。

  • [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 感應器。
  • [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 毫秒以內。針對加速計和陀螺儀，相同實體事件的事件時間戳記，兩者相差不多 0.25 毫秒。
  • [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_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10。生物特徵辨識感應器

如需評估生物特徵辨識解鎖安全性的其他背景資訊，請參閱測量生物特徵辨識安全性說明文件。

如果裝置實作項目包含安全螢幕鎖定，他們會：

  • 應納入生物特徵辨識感應器

生物特徵辨識感應器可分為第 3 級 (原名為「強」)、第 2 級 (原為「弱」) 或「第 1 級」(原為「便利」)，並且取決於生物特徵辨識管道的安全性。這種分類會決定生物特徵辨識感應器與平台和第三方應用程式之間的介面功能。根據預設，感應器可歸類為「第 1 級」。感應器需要將感應器歸類為「第 2 級」或「第 3 級」時，必須符合下列詳細說明。第 2 級和第 3 級生物特徵辨識功能都有額外功能，詳情如下。

如果裝置實作方式透過 android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL 提供生物特徵辨識感應器，請採取下列做法：

  • [C-4-1] 必須符合本文件中定義的第 3 級或第 2 級生物特徵辨識規定。
  • [C-4-2] 必須識別並遵守 Authenticators 類別中定義為常數的每個參數名稱，以及其中的任何組合。相反地，除了 Authenticators 及其中任何組合中以公開常數記錄的整數常數，傳送至 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法的整數常數也不得重複。
  • [C-4-3] 必須在搭載第 3 級或第 2 級生物特徵辨識的裝置上實作 ACTION_BIOMETRIC_ENROLL 動作。這個動作只「必須」顯示第 3 級或第 2 級生物特徵辨識的註冊進入點。

如果裝置實作支援被動生物特徵辨識，就會：

  • [C-5-1] 在預設狀態下「必須」執行額外的確認步驟 (例如按下按鈕)。
  • [C-SR] 強烈建議你提供這項設定，允許使用者覆寫應用程式偏好設定，並一律要求使用者進行確認步驟。
  • [C-SR] 強烈建議「務必」採用安全防護的確認動作，避免作業系統或核心入侵行為進行假冒攻擊。舉例來說，根據實體按鈕的確認動作，會透過安全元素 (SE) 的純輸入/輸出 (GPIO) 接腳轉送，該接腳不得以按下實體按鈕以外的任何方式驅動。
  • [C-5-2] 必須另外實作與 setConfirmationRequired (boolean) 對應的隱含驗證流程(無需確認步驟)，讓應用程式設定為用於登入流程。

如果裝置實作的裝置有多個生物特徵辨識感應器，就會：

  • [C-SR] 強烈建議你針對每項驗證作業僅要求確認一項生物特徵辨識 (舉例來說，如果裝置同時支援指紋與臉孔感應器，應在確認任一種感應器後傳送 onAuthenticationSucceeded)。

為了讓裝置實作允許第三方應用程式存取 KeyStore 金鑰，裝置必須採取以下動作：

  • [C-6-1] 必須符合本節中的第 3 級規定。
  • [C-6-2] 如果驗證需要 BIOMETRIC_STRONG，或者是透過 CryptoObject 叫用驗證，「必須」顯示第 3 級生物特徵辨識。

如要將生物特徵辨識感應器視為「第 1 級」 (舊稱「便利性」) 的裝置實作方式，請按照下列步驟操作：

  • [C-1-1] 不正確的接受率必須低於 0.002%。
  • [C-1-2] 如使用 Android 生物特徵辨識測試通訊協定的測量結果，但假冒 PIN 碼、解鎖圖案或密碼的安全強度高於 7%，則必須明確說明啟用此模式的安全性可能較低。
  • [C-1-3] 如果進行 5 次生物特徵辨識驗證，則必須嘗試至少重試 30 秒的時間；假使試驗並非實證，必須擷取足夠的拍攝品質 (BIOMETRIC_ACQUIRED_GOOD)，但此結果與已註冊的生物特徵辨識不符。
  • [C-1-4] 必須讓使用者確認現有或新增受到 TEE 保護的裝置憑證 (PIN 碼/圖案/密碼)，以防止新增生物特徵辨識。
  • [C-1-5] 移除使用者帳戶時 (包括透過恢復原廠設定)，「必須」完全移除使用者的所有可識別生物特徵辨識資料。
  • [C-1-6] 必須按照該生物特徵辨識的個別標記 (例如 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS) 提供圖示。
  • [C-1-7] 對於搭載 Android 10 版的新裝置，必須每 24 小時詢問使用者一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)，以及每 72 小時 (針對從舊版 Android 版本升級的裝置) 一次。

  • [C-1-8] 透過下列其中一種做法，務必要求使用者執行建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)：

    • 4 小時的閒置逾時期限，或
    • 3 次生物特徵辨識驗證失敗。
    • 一旦成功確認裝置憑證，閒置逾時期限和驗證失敗次數就會重設。

    從舊版 Android 升級裝置不受 C-1-8 的限制。* [C-SR] 強烈建議使用 Android 開放原始碼專案提供的架構，針對新裝置強制執行 [C-1-7] 和 [C-1-8] 中指定的限制。* [C-SR] 強烈建議將誤判率低於 10% (根據裝置估算)。* [C-SR] 強烈建議將延遲時間控制在 1 秒以下，也就是針對每項已註冊的生物特徵辨識，從偵測到生物特徵辨識的時間到螢幕解鎖為止。

如要將生物特徵辨識感應器視為第 2 級 (原稱「弱」) 的裝置實作方式，請執行以下操作：

  • [C-2-1] 必須符合上述第 1 級的所有規定。
  • [C-2-2] 根據 Android 生物特徵辨識測試通訊協定測得，假冒及冒名錄接受率不得超過 20%。
  • [C-2-3] 「必須」在 Android 使用者或核心空間 (例如受信任的執行環境 (TEE)) 外的獨立執行環境 (例如受信任的執行環境 (TEE)) 或含有安全通道的晶片中，對隔離執行環境執行生物特徵辨識比對。
  • [C-2-4] 所有識別資料都必須經過加密及加密驗證，才能在獨立執行環境外取得、讀取或修改，也不能使用安全管道加密獨立執行環境的晶片 (如 Android 開放原始碼專案網站的實作指南所述)。
  • [C-2-5] 針對相機型生物特徵辨識功能，用於進行生物特徵辨識驗證或註冊：
    • 操作攝影機時「不得」在隔離執行環境外讀取或修改相機影格，或是在隔離執行環境外使用含有安全通道的晶片。
    • 如果是 RGB 單機拍攝解決方案，「CAN」可以在獨立執行環境外讀取相機影格，以支援註冊預覽等作業，但「不得」變更。
  • [C-2-6] 不得允許第三方應用程式區分個人的生物特徵辨識註冊情形。
  • [C-2-7] 在 TEE 環境之外，「不得」允許以未加密的方式存取可識別的生物特徵辨識資料，或從這些資料衍生的任何資料 (例如嵌入內容) 存取應用程式處理器。

  • [C-2-8] 必須設有安全的處理管道，以防止作業系統或核心遭駭資料直接植入資料，藉此誤報使用者身分。

    如果裝置實作的裝置已推出較舊的 Android 版本，且無法透過系統軟體更新符合 C-2-8 的規定，就可能不受規定的約束。

  • [C-SR] 強烈建議你為所有生物特徵辨識特徵和注意力偵測納入有效性偵測功能。

如要將生物特徵辨識感應器視為第 3 級 (舊稱「強」) 的裝置實作方式，請按照下列步驟操作：

  • [C-3-1] 必須符合上述第 2 級的所有規定，[C-1-7] 和 [C-1-8] 除外。從舊版 Android 升級裝置不適用 C-2-7。
  • [C-3-2] 必須實作硬體支援的 KeyStore。
  • [C-3-3] 根據 Android 生物特徵辨識測試通訊協定測得，假冒和冒名錄接受率不得超過 7%。
  • [C-3-4] 必須每 72 小時最多詢問使用者一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)。

7.3.12。姿勢感應器

裝置實作方式：

  • 可能支援 6 度自由度的姿勢感應器。

如果裝置實作支援自由 6 度自由姿勢的姿勢感應器，請按照下列步驟操作：

  • [C-1-1] 必須導入及回報 TYPE_POSE_6DOF 感應器。
  • [C-1-2] 必須比只使用旋轉向量時的準確度高。

7.3.13。轉軸角度感應器

如果裝置的實作方式支援轉軸角度感應器，就會：

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 實作為免人工管理。

如果裝置的實作支援 eUICC 或 eSIM 卡/內嵌 SIM 卡，且含有專屬機制，讓第三方開發人員使用 eSIM 卡功能，那麼：

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.1.2。Telecom API

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

  • [C-1-1] 必須支援 SDK 中所述的 ConnectionService API。
  • [C-1-2] 使用者通話時，如果第三方應用程式不支援透過 CAPABILITY_SUPPORT_HOLD 指定的保留功能，就必須顯示新來電，並讓使用者視需要接受或拒絕來電。
  • [C-1-3] 必須有一個應用程式實作 InCallService。

  • [C-SR] 強烈建議你通知使用者接聽來電後，通話就會結束。

    Android 開放原始碼計畫實作項目可透過抬頭通知達成這些規定，並在使用者接聽來電後造成其他通話遭到捨棄。

  • [C-SR] 強烈建議在第三方應用程式將 PhoneAccount 上的 EXTRA_LOG_SELF_MANAGED_CALLS 額外鍵設為 true 時，預先載入預設撥號應用程式，該應用程式會顯示通話記錄項目和第三方應用程式的名稱。

  • [C-SR] 極力建議您為 android.telecom API 處理音訊耳機的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，如下所示：

7.4.2。IEEE 802.11 (Wi-Fi)

裝置實作方式：

  • 應支援一或多種 802.11 形式。

如果裝置的實作支援 802.11，並且向第三方應用程式公開這項功能，他們必須：

  • [C-1-1] 必須實作對應的 Android API。
  • [C-1-2] 必須回報硬體功能旗標 android.hardware.wifi。
  • [C-1-3] 必須按照 SDK 說明文件中所述導入多點傳播 API。
  • [C-1-4] 必須支援多點傳送 DNS (mDNS)，且在作業期間一律「不得」篩選 mDNS 封包 (224.0.0.251)，包括：
    • 即使螢幕未處於使用中狀態也一樣。
    • 適用於 Android TV 裝置實作，即使處於待機狀態也一樣。
  • [C-1-5] 不得將 WifiManager.enableNetwork() API 方法呼叫視為足以切換應用程式流量目前預設使用中的 Network，且是由 getActiveNetwork 和 registerDefaultNetworkCallback 等 API 方法傳回。ConnectivityManager也就是說，只有在其他網路供應商 (例如行動數據) 成功驗證 Wi-Fi 網路可正常提供網際網路的情況下，他們「才能」停用其網際網路連線。
  • [C-1-6] 強烈建議「強烈建議」在呼叫 ConnectivityManager.reportNetworkConnectivity() API 方法時重新評估 Network 上的網際網路存取權。如果評估結果判斷目前的 Network 不再提供網際網路，請切換至其他提供網際網路的可用網路 (例如行動數據網路)。
  • [C-SR] 極力建議在每次掃描作業開始時隨機隨機處理來源 MAC 位址和探測要求影格的序號，一次掃描一次，但 STA 會中斷連線。
    • 包含一次掃描作業的每組探測要求頁框，都應使用一個一致的 MAC 位址 (不應透過掃描在半途隨機處理 MAC 位址)。
    • 在掃描作業中的探測要求之間，探測要求序號應像平常 (依序) 疊代。
    • 探測要求的序號應在掃描的最後一個探測要求和下一次掃描作業的第一次探測要求之間隨機排序。
  • [C-SR] 強烈建議我採用，但 STA 中斷連線時，只有在探測要求影格中才允許下列元素：
    • SSID 參數集 (0)
    • DS 參數組合 (3)

如果裝置實作支援 (如 IEEE 802.11 標準中定義的 Wi-Fi 省電模式)，就會執行以下動作：

  • [C-3-1] 每當應用程式透過 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() API 取得 WIFI_MODE_FULL_HIGH_PERF 鎖定或 WIFI_MODE_FULL_LOW_LATENCY 鎖定，且居家鎖處於啟用狀態時，一律必須關閉 Wi-Fi 省電模式。
  • [C-3-2] 在裝置處於 Wi-Fi 低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 模式時，裝置與存取點之間的平均往返延遲時間必須小於 Wi-Fi 高音鎖定 (WIFI_MODE_FULL_HIGH_PERF) 模式的延遲時間。
  • [C-SR] 極力建議您，每當取得低延遲鎖定 (WIFI_MODE_FULL_LOW_LATENCY) 並生效時，盡可能降低 Wi-Fi 封包往返延遲時間。

如果裝置的實作功能支援 Wi-Fi 並使用 Wi-Fi 掃描位置，請按照下列步驟操作：

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 運作。
  • [C-1-4] 必須同時支援 Wi-Fi 和 Wi-Fi Direct 作業。

裝置實作方式：

如果裝置實作項目包括對 TDLS 的支援，且 WiFiManager API 已啟用 TDLS，則：

  • [C-1-1] 必須透過 WifiManager.isTdlsSupported 宣告支援 TDLS。
  • 請只在可能且有利的情況下才使用 TDLS。
  • 「不應」使用一些經驗法則，並「不要」使用 TDLS (因為網路效能可能比使用 Wi-Fi 存取點更高)。
7.4.2.3。Wi-Fi 感知

裝置實作方式：

如果裝置的實作項目支援 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 分鐘)。

如果裝置實作項目支援 Wi-Fi Aware 和 Wi-Fi 定位功能 (如第 7.4.2.5 節所述)，且會對第三方應用程式提供這些功能，那麼：

7.4.2.4。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.2.5。Wi-Fi 定位服務 (Wi-Fi 封包往返時間 - RTT)

裝置實作方式：

如果裝置的實作方式支援 Wi-Fi 位置資訊功能，並向第三方應用程式公開這項功能，那麼：

  • [C-1-1] 必須按照 SDK 說明文件中所述導入 WifiRttManager API。
  • [C-1-2] 必須宣告 android.hardware.wifi.rtt 功能標記。
  • [C-1-3] 針對執行 RTT 的 Wi-Fi 介面 (執行 RTT 時) 與存取點之間，請務必為每個執行 RTT 爆發的隨機來源 MAC 位址隨機化。
7.4.2.6。Wi-Fi Keepalive 卸載

裝置實作方式：

  • 應提供 Wi-Fi 保持運作卸載支援。

如果裝置的實作支援 Wi-Fi 保持運作卸載功能，並向第三方應用程式公開相關功能，他們必須：

  • [C-1-1] 必須支援 SocketKeepAlive API。

  • [C-1-2] 必須支援透過 Wi-Fi 連線至少三個並行的保持運作運算單元，以及至少一個保持運作狀態的運算單元。

如果裝置的實作不支援 Wi-Fi 保持運作卸載功能，就會：

7.4.2.7。Wi-Fi 輕鬆連線 (裝置佈建通訊協定)

裝置實作方式：

如果裝置的實作支援 Wi-Fi Easy Connect 支援，並向第三方應用程式公開相關功能，他們必須：

7.4.3. 藍牙

如果裝置實作支援藍牙音訊設定檔，就會：

  • 應支援進階音訊轉碼器和藍牙音訊轉碼器 (例如 LDAC)。

如果裝置實作支援 HFP、A2DP 和 AVRCP，請按照下列步驟操作：

  • 應支援至少 5 部連網裝置。

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

  • [C-1-1] 必須支援藍牙 4.2 和藍牙 LE 資料長度擴充功能。

Android 支援藍牙和藍牙低功耗。

如果實作的裝置支援藍牙和藍牙低功耗功能，就會：

  • [C-2-1] 必須宣告相關的平台功能 (分別 android.hardware.bluetooth 和 android.hardware.bluetooth_le) 並實作平台 API。
  • 請視情況為裝置實作相關的藍牙設定檔，例如 A2DP、AVRCP、OBEX、HFP 等。

如果裝置的實作支援藍牙低功耗 (BLE)，即支援：

  • [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() 的正確值，指出是否支援低功耗廣告。
  • [C-3-5] 裝置必須在 15 分鐘內導入可撤銷的私人網址 (RPA) 逾時設定，並在逾時時旋轉地址，以保護使用者主動透過 BLE 掃描或放送廣告的使用者隱私。為避免時間攻擊，逾時間隔也必須介於 5 到 15 分鐘之間。
  • 實作 ScanFilter API 時，應支援將篩選邏輯卸載至藍牙晶片組。
  • 應支援將批次掃描卸載到藍牙晶片組。
  • 應支援至少有 4 個版位的多廣告。

如果實作的裝置支援藍牙 LE，並使用藍牙 LE 掃描位置，請按照下列步驟操作：

  • [C-4-1] 必須為使用者提供需求，以啟用/停用透過 System API BluetoothAdapter.isBleScanAlwaysAvailable() 讀取值的功能。

如果裝置實作項目支援藍牙 LE 和助聽器設定檔 (如使用藍牙 LE 的助聽器音訊支援一節所述)，則必須：

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-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。網路通訊協定和 API

7.4.5.1。最低網路功能

裝置實作方式：

  • [C-0-1] 必須支援一或多種資料網路。具體來說，裝置實作項目「必須」支援至少一項支援 200 Kbit/秒以上的資料標準。符合這項規定的技術包括 EDGE、HSPA、EV-DO、802.11g、乙太網路和藍牙 PAN。
  • 此外，在以實體網路標準 (例如乙太網路) 做為主要數據連線的情況下，至少應支援一項通用無線資料標準，例如 802.11 (Wi-Fi)。
  • 可以實作多種形式的數據連線。
7.4.5.2。IPv6

裝置實作方式：

  • [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 連線。
  • [C-0-6] 連線至 IPv6 網路時，「必須」向第三方應用程式提供直接 IPv6 連線功能的網路，且不得在裝置上進行任何形式的位址或通訊埠轉譯。Socket#getLocalAddress 或 Socket#getLocalPort) 和 NDK API (例如 getsockname() 或 IPV6_PKTINFO) 都「必須」傳回實際用於在網路上收發封包的 IP 位址和通訊埠，且會顯示為網際網路 (Web) 伺服器的通訊埠 IP 與通訊埠。

所需的 IPv6 支援等級會因網路類型而異，如下列需求所示。

如果實作的裝置支援 Wi-Fi，就會發生以下情形：

  • [C-1-1] 必須「必須」支援在 Wi-Fi 連線時執行雙重堆疊和僅限 IPv6 的作業。

如果裝置實作項目支援乙太網路，就會：

  • [C-2-1] 必須支援在乙太網路上使用雙重堆疊和僅限 IPv6 的作業。

如果裝置的實作方式支援行動數據，就會採取以下做法：

  • [C-3-1] 必須支援在行動網路上使用 IPv6 作業 (僅限 IPv6 且可能採用雙重堆疊)。

如果裝置導入方式支援多種網路類型 (例如Wi-Fi 和行動數據) 的應用程式除外：

  • [C-4-1] 當裝置同時連線至多個網路類型時，「必須」在每個網路中同時符合上述規定。
7.4.5.3。網頁認證入口

網頁認證入口是指需要登入才能存取網際網路的網路。

如果裝置實作提供完整的 android.webkit.Webview API 實作，就會：

  • [C-1-1] 必須在呼叫 System API ConnectivityManager#startCaptivePortalApp(Network, Bundle) 時，提供網頁認證入口應用程式來處理意圖 ACTION_CAPTIVE_PORTAL_SIGN_IN，並顯示網頁認證入口登入頁面。
  • [C-1-2] 當裝置連線到任何網路類型 (包括行動網路、行動網路、Wi-Fi、乙太網路或藍牙) 時，「必須」執行網頁認證入口偵測功能，並支援透過網頁認證入口應用程式登入。
  • [C-1-3] 如果裝置設為使用私人 DNS 嚴格模式，就必須支援使用明文 DNS 登入網頁認證入口。
  • [C-1-4] 請務必按照 android.net.LinkProperties.getPrivateDnsServerName 和 android.net.LinkProperties.isPrivateDnsActive 的 SDK 說明文件，使用加密的 DNS，所有未明確與網頁認證入口通訊的網路流量都使用加密的 DNS。
  • [C-1-5] 「必須」確保使用者登入網頁認證入口時，應用程式使用的預設網路 (由 ConnectivityManager.getActiveNetwork 傳回，ConnectivityManager.registerDefaultNetworkCallback 以及 Java 網路 API 預設使用的網路，以及 java.net.Socket 等 Java 網路 API 和 connect() 等原生 API) 都是任何其他提供網際網路連線的可用網路 (如適用)。

7.4.6。同步處理設定

裝置實作方式：

7.4.7。數據節省模式

如果裝置實作項目提供計量付費連線，則表示：

  • [SR] 強烈建議提供數據節省模式。

如果裝置實作項目提供數據節省模式，就會發生以下情形：

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

如果裝置實作項目未提供數據節省模式，就會發生以下情形：

7.4.8。安全元件

如果裝置實作項目支援支援 Open Mobile API 的安全元素，並將其提供給第三方應用程式使用，它們：

7.5. 相機

如果裝置的實作方式至少包含一部相機，這些裝置會：

  • [C-1-1] 必須宣告 android.hardware.camera.any 功能標記。
  • [C-1-2] 應用程式「必須」能夠同時分配 3 個 RGBA_8888 點陣圖，大小等同於裝置上最大解析度相機感應器產生的圖像大小，同時相機為開啟狀態，以便進行基本預覽並照常拍攝。
  • [C-1-3] 「必須」確保預先安裝的預設相機應用程式處理意圖 MediaStore.ACTION_IMAGE_CAPTURE、MediaStore.ACTION_IMAGE_CAPTURE_SECURE 或 MediaStore.ACTION_VIDEO_CAPTURE 負責移除圖片中繼資料中的使用者位置，然後再將接收到的應用程式沒有 ACCESS_FINE_LOCATION 傳送至接收端應用程式。

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 以上版本)。
  • [C-1-3] 必須通過連接實體外接鏡頭裝置的相機 CTS 測試。如要進一步瞭解相機 CTS 測試，請前往 source.android.com。
  • 應支援 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。

已淘汰的 android.hardware.Camera 類別和新版 android.hardware.camera2 套件之間通用的所有功能，「必須」在這兩個 API 中達到同等的效能和品質。舉例來說，在設定相同的情況下，自動對焦的速度和準確率必須相同，且拍攝圖像的品質必須相同。需要用到兩個 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.request.availableCapabilities 中宣傳 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能的 android.hardware.camera2 裝置，透過 android.media.ImageReader API 支援 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式輸出內容。
  • [C-0-5] 無論裝置是否內建硬體自動對焦或其他功能，仍必須實作 Android SDK 說明文件中提供的完整 Camera API。舉例來說，不含自動對焦的相機「必須」仍然呼叫任何已註冊的 android.hardware.Camera.AutoFocusCallback 執行個體 (即使這與非自動對焦相機無關)。請注意，這適用於前置鏡頭；舉例來說，雖然多數前置鏡頭不支援自動對焦，但 API 回呼仍必須「加上假裝」。
  • [C-0-6] 必須識別並遵守 android.hardware.Camera.Parameters 類別和 android.hardware.camera2.CaptureRequest 類別中定義為常數的每個參數名稱。相反地，除了在 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 意圖。
  • [C-0-11] 必須能透過已淘汰的 android.hardware.Camera API 存取所有相機，也能透過 android.hardware.camera2 API 存取。
  • [C-0-12] 必須確保臉部外觀未經過變造，包括但不限於更改任何 android.hardware.camera2 或 android.hardware.Camera API 的臉部幾何圖形、臉部膚色或臉部護膚品
  • [C-SR] 如果裝置有多個 RGB 相機朝相同方向，我們強烈建議支援列出 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 的邏輯相機裝置，包括所有面向實體的 RGB 相機。

如果裝置實作項目為第三方應用程式提供專屬相機 API，就會：

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] 凡是目標 API 級別 29 以上的應用程式，都必須預設啟用限定範圍儲存空間，但下列情況除外：
    • 應用程式在資訊清單中要求 android:requestLegacyExternalStorage="true" 時。
  • [C-0-5] 透過 MediaStore 存取這些檔案時，必須遮蓋位置中繼資料 (例如 GPS Exif 標記)，但呼叫應用程式擁有 ACCESS_MEDIA_LOCATION 權限時除外。

裝置實作方式「可能」符合上述規定，需使用下列其中一項：

  • 使用者可存取的卸除式儲存空間，例如安全數位 (SD) 卡片插槽。
  • Android 開放原始碼計畫 (AOSP) 中實作的部分內部 (不可移除) 儲存空間。

如果裝置的實作方式為符合上述需求，使用卸除式儲存空間：

  • [C-1-1] 如未在插槽中插入儲存媒介，「必須導入浮動式訊息或彈出式使用者介面」警告使用者。
  • [C-1-2] 必須包含 FAT 格式的儲存媒介 (例如 SD 卡)，或是在購買時，顯示需要另外購買儲存媒介的包裝盒和其他材料。

如果裝置的實作方式使用一部分無法移除的儲存空間滿足上述需求，則：

  • 應使用內部應用程式共用儲存空間的 Android 開放原始碼計畫實作項目。
  • 可以與應用程式私人資料共用儲存空間。

如果裝置的實作具備支援 USB 週邊裝置模式的 USB 連接埠，就會：

  • [C-3-1] 「必須」提供從主機電腦上存取應用程式共用儲存空間資料的機制。
  • 應透過 Android 的媒體掃描器服務和 android.provider.MediaStore，以公開透明的方式顯示這兩個儲存空間路徑的內容。
  • 「可能」使用 USB 大量儲存裝置，但應使用媒體傳輸通訊協定，以符合這項規定。

如果裝置的實作具備具備 USB 週邊裝置模式的 USB 連接埠，並支援媒體傳輸通訊協定，就會發生以下情形：

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

7.6.3. 採用儲存空間

如果裝置應為行動裝置的性質與電視不同，裝置的導入方式如下：

  • [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 連接埠 (插座) 的變壓器。
  • [C-SR] 極力建議您實作 USB 音訊類別 (如 Android SDK 說明文件所述)。
  • 應支援在主機模式下為連接的 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 生態系統中的耳機和其他音訊配件相容，如果裝置實作項目包含一或多個類比音訊連接埠，則必須遵守下列規定：

  • [C-SR] 強烈建議至少加入其中一個音訊連接埠，做為 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 之間。
  • [C-1-7] 必須偵測及對應的按鍵碼，在音訊插頭上當麥克風和地面電導體之間有下列範圍相同的阻力：
    • 110-180 ohm： KEYCODE_VOICE_ASSIST
  • [C-SR] 強烈建議你透過 OMTP 綁定順序支援音訊插頭。
  • [C-SR] 極力建議支援附麥克風的立體聲耳機錄音功能。

如果裝置實作項目具有 4 導體 3.5 公釐耳機插孔並支援麥克風，且將額外的麥克風設定為 1，則播送 android.intent.action.HEADSET_PLUG：

  • [C-2-1] 必須能偵測已接上電源的音訊配件麥克風。
7.8.2.2。數位音訊連接埠

為了讓使用 USB-C 連接器以及在 Android 生態系統中實作 (USB 音訊類別)，以便與耳機和其他音訊配件相容，請參閱 Android USB 耳機規格。

如要瞭解裝置專屬的需求，請參閱 2.2.1 節。

7.8.3. 近乎超音波

近乎超音波音訊為 18.5 kHz 至 20 kHz 錶帶。

裝置實作方式：

如果 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.8.4。信號完整性

裝置實作：* 手持裝置的輸入和輸出串流應提供無故障的音訊訊號路徑。根據每個路徑的測試期間，測試期間每路徑一分鐘會測量一次零故障，這些跡象。使用 [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester)「Automated Glitch Test」時進行測試。

測試時需使用音訊回送連接器 (直接用於 3.5 公釐耳機插孔，且/或可搭配 USB-C 轉 3.5 公釐轉接頭使用)。所有音訊輸出連接埠都必須測試。

OboeTester 目前支援 AAudio 路徑，因此下列組合應使用 AAudio 測試是否出現故障：

Perf 模式 共用 取樣率 In Chans 逃離冠軍
LOW_LATENCY 專屬 未指定 1 種 2
LOW_LATENCY 專屬 未指定 2 1 種
LOW_LATENCY 共用 未指定 1 種 2
LOW_LATENCY 共用 未指定 2 1 種
NONE 共用 48,000 1 種 2
NONE 共用 48,000 2 1 種
NONE 共用 44100 1 種 2
NONE 共用 44100 2 1 種
NONE 共用 16,000 1 種 2
NONE 共用 16,000 2 1 種

可靠的串流必須符合下列條件，才能達到 2000 Hz 的訊號強度訊號 (SNR) 和 Total Harmonic Distortion (THD)。

轉頻器 THD SNR
主要內建喇叭，使用外部參考麥克風進行測量 < 3.0% >= 50 分貝
主要內建麥克風，使用外部參考喇叭進行測量 < 3.0% >= 50 分貝
內建類比 3.5 公釐耳機插孔，使用回送轉接器進行測試 < 1% >= 60 分貝
手機隨附的 USB 轉接器，使用回送轉接器進行測試 < 1.0% >= 60 分貝

7.9. 虛擬實境

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

7.9.1。虛擬實境模式

Android 支援 VR 模式，這項功能可處理通知的立體視覺算繪作業，並可在 VR 應用程式具備使用者焦點時停用單管系統 UI 元件。

7.9.2。虛擬實境模式 - 高效能

如果裝置實作支援 VR 模式，就會：

  • [C-1-1] 至少必須有 2 個實體核心。
  • [C-1-2] 必須宣告 android.hardware.vr.high_performance 功能。
  • [C-1-3] 必須支援持續效能模式。
  • [C-1-4] 強烈建議支援 OpenGL ES 3.2。
  • [C-1-5] 必須支援 android.hardware.vulkan.level 0。
  • 應支援 android.hardware.vulkan.level 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_EXT_image_gl_colorspace，並在可用的 EGL 擴充功能清單中顯示擴充功能。
  • [C-1-8] 必須實作 GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2、GL_EXT_protected_textures，並在可用 GL 擴充功能清單中顯示擴充功能。
  • [C-SR] 強烈建議導入 GL_EXT_external_buffer、GL_EXT_EGL_image_array 和 GL_OVR_multiview_multisampled_render_to_texture，並在可用的 GL 擴充功能清單中顯示擴充功能。
  • [C-SR] 極力建議您支援 Vulkan 1.1。
  • [C-SR] 我們強烈建議您實作 VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing、VK_KHR_shared_presentable_image，並將其公開在可用的 Vulkan 擴充功能清單中。
  • [C-SR] 強烈建議至少公開一個 Vulkan 佇列系列，其中 flags 同時包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT，queueCount 至少為 2。
  • [C-1-7] GPU 和螢幕「必須」能同步處理共用前端緩衝區的存取權，讓兩個以 60fps 轉譯的 VR 內容交替顯示，在沒有可見的撕裂痕跡的情況下無法顯示。
  • [C-1-9] 必須按照 NDK 中所述，為 AHardwareBuffer 標記 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 實作支援。
  • [C-1-10] 必須導入 AHardwareBuffer 支援功能與使用旗標 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT，至少要採用以下格式：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
  • [C-SR] 強烈建議支援透過 C-1-10 指定多個圖層和標記和格式的 AHardwareBuffer 配置。
  • [C-1-11] 必須支援以 30fps 至少 3840 x 2160 解碼的 H.264 編碼，壓縮為平均 40 Mbps (相當於 4 個 1920 x1080 且 30 fps-10 Mbps 或 1080 x 10 Mbps 的 2 個執行個體)。
  • [C-1-12] 必須支援 HEVC 和 VP9，必須能夠解碼至少 1920 x 1080 (每秒 30 個影格) 的編碼，平均壓縮為 10 Mbps，且 應該能夠將 3840 x 2160 解碼至 30 fps-20 Mbps 執行個體 (30 fps-20 Mbps)。
  • [C-1-13] 必須支援 HardwarePropertiesManager.getDeviceTemperatures API，並傳回準確的皮膚溫度值。
  • [C-1-14] 必須提供內嵌螢幕，且解析度不得小於 1920 x 1080。
  • [C-SR] 強烈建議採用至少 2560 x 1440 的螢幕解析度。
  • [C-1-15] 處於 VR 模式時，螢幕至少要更新 60 Hz。
  • [C-1-17] 螢幕「必須」支援低持久模式，且持續性不超過 5 毫秒，持續性定義則是指像素發光的時間長度。
  • [C-1-18] 必須支援藍牙 4.2 和藍牙 LE Data Length Extension第 7.4.3 節。
  • [C-1-19] 必須針對下列所有預設感應器類型，支援並正確回報直接管道類型：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR] 強烈建議針對上述所有直接管道類型支援 TYPE_HARDWARE_BUFFER 直接管道類型。
  • [C-1-21] 必須符合 android.hardware.hifi_sensors 的陀螺儀、加速計和磁力儀的相關要求，如第 7.3.9 節所述。
  • [C-SR] 強烈建議支援 android.hardware.sensor.hifi_sensors 功能。
  • [C-1-22] 端對端動作必須不超過 28 毫秒。
  • [C-SR] 強烈建議「務必」在光電延遲時間不超過 20 毫秒的情況下進行端對端動態模式。
  • [C-1-23] 必須設定第一個畫面比例，也就是從黑到白轉換後，第一個畫面的像素亮度與穩定狀態下白像素亮度之間的比率 (至少 85%)。
  • [C-SR] 強烈建議將第一個影格比例至少設為 90%。
  • 可以為前景應用程式提供專屬核心，並支援 Process.getExclusiveCores API 以傳回頂端前景應用程式專屬的 CPU 核心數量。

如果支援專屬核心，則使用核心：

  • [C-2-1] 不得允許任何其他使用者空間處理程序 (應用程式使用的裝置驅動程式除外)，但「可能」允許部分核心程序視需要執行。

7.10。觸覺技術

如要瞭解裝置專屬的需求，請參閱 2.2.1 節。

7.11。媒體成效類別

您可以從 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API 取得裝置實作的媒體效能類別。各 Android 版本從 R (版本 30) 開始，定義了媒體效能類別的需求。特殊值 0 代表裝置不屬於媒體效能類別。

如果裝置實作針對 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 傳回非零值，就會：

  • [C-1-1] 傳回的值至少須為 android.os.Build.VERSION_CODES.R。

  • [C-1-2] 必須實作手持裝置。

  • [C-1-3] 必須符合第 2.2.7 節所述的「媒體成效等級」所有規定。

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

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 開放原始碼計畫中的裝置電源管理功能 (例如應用程式待命值區、打盹功能)，或擴充不會套用比稀有應用程式待命值區更困難的功能，就會：

  • [C-1-1] 不得偏離 Android 開放原始碼計畫實作項目，例如：觸發、維護、喚醒演算法，以及「應用程式待命」和「打盹」模式的全域系統設定。
  • [C-1-2] 「不得」偏離使用 Android 開放原始碼計畫實作項目，因為使用全域設定來管理應用程式待命時，每個值區中的應用程式工作節流、警報和網路節流情形。
  • [C-1-3] 不得偏離 Android 開放原始碼計畫實作項目，例如用於應用程式待命的應用程式待命值區數量。
  • [C-1-4] 必須按照電源管理中所述實作應用程式待命值區和打盹功能。
  • [C-1-5] 裝置開啟省電模式時，必須退還 PowerManager.isPowerSaveMode() 的 true。
  • [C-SR] 強烈建議向使用者提供預設用途來啟用和停用省電功能。
  • [C-SR] 強烈建議使用者盡可能提供不必使用應用程式待命和打盹省電模式的所有應用程式。

如果裝置實作項目會擴充 Android 開放原始碼計畫的電源管理功能，且該擴充功能套用比稀有應用程式待命值區更嚴格的限制，請參閱第 3.5.1 節。

除了省電模式外，Android 裝置可能會實作進階設定和電源介面 (ACPI) 所定義的 4 個休眠電源狀態 (全部或全部)。

如果裝置實作方式實作 ACPI 定義的 S4 電源狀態，就會發生以下情形：

  • [C-1-1] 只有在使用者執行明確操作後，讓裝置處於閒置狀態 (例如蓋上裝置有機體或關上汽車或電視)，並讓使用者重新啟用裝置 (例如打開車蓋或重新開機) 前，才需要進入此狀態。

如果裝置實作方式實作 ACPI 定義的 S3 電源狀態，就會發生以下情形：

  • [C-2-1] 「必須」符合上述 C-1-1 標準，或者只有在第三方應用程式不需要系統資源 (例如螢幕、CPU) 時才進入 S3 狀態。

    相反地，如果第三方應用程式需要系統資源 (如本 SDK 所述)，則「必須」退出 S3 狀態。

    舉例來說，雖然第三方應用程式透過 FLAG_KEEP_SCREEN_ON 要求保持螢幕開啟，或透過 PARTIAL_WAKE_LOCK 讓 CPU 保持運作，除非使用者已採取明確行動，讓裝置進入閒置狀態，否則裝置「不得」進入 S3 狀態。相反地，如果第三方應用程式透過 JobScheduler 實作工作，或將 Firebase 雲端通訊傳送至第三方應用程式，則裝置「必須」退出 S3 狀態，除非使用者將裝置設為閒置狀態。上述內容並未涵蓋所有情況，Android 開放原始碼計畫會導入大量的喚醒信號，藉此觸發這個狀態的喚醒程序。

8.4. 耗電量會計

更準確的耗電量計算和耗電量報告，能為應用程式開發人員提供獎勵和最佳化應用程式耗電量模式的工具。

裝置實作方式：

  • [SR] 強烈建議提供個別元件的電源設定檔，定義每個硬體元件的「目前消耗量值」，以及該元件隨時間變化的約略電池電力 (詳見 Android 開放原始碼計畫網站所述)。
  • [SR] 強烈建議以毫秒 (mAh) 為單位回報所有耗電量的值。
  • [SR] 強烈建議採用每個程序 UID 回報的 CPU 耗電量。Android 開放原始碼計畫會透過 uid_cputime 核心模組實作符合要求。
  • [SR] 強烈建議透過 adb shell dumpsys batterystats 殼層指令，向應用程式開發人員提供此電源用量。
  • 如果無法將硬體元件的電力用量歸功於應用程式，則必須歸因於硬體元件。

8.5. 一致的效能

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

裝置實作方式：

如果裝置實作回報支援持續效能模式，即表示：

  • [C-1-1] 必須在應用程式要求時，為頂層前景應用程式提供至少 30 分鐘的效能一致等級。
  • [C-1-2] 必須遵循 Window.setSustainedPerformanceMode() API 和其他相關 API。

如果裝置的實作項目包含兩個以上的 CPU 核心，就會：

  • 您至少應提供一個可由頂層前景應用程式保留的專屬核心。

如果裝置實作支援為頂層前景應用程式保留一個專屬核心，就會執行以下動作：

  • [C-2-1] 必須透過 Process.getExclusiveCores() API 方法回報，頂端前景應用程式可保留的專屬核心 ID 數量。
  • [C-2-2] 「不得」允許任何使用者空間處理程序，除非應用程式所使用的裝置驅動程式在專屬核心上執行，但允許某些核心程序在必要時執行。

如果裝置實作項目不支援專屬核心，就會：

9. 安全性模型相容性

裝置實作方式：

  • [C-0-1] 必須實作 Android 開發人員說明文件中 API 安全性和權限參考文件所定義的安全性模型，以符合 Android 平台的安全性模型。

  • [C-0-2] 必須支援安裝自行簽署的應用程式，不需要任何第三方/主管機關提供額外權限/憑證。具體來說，相容裝置「必須」支援下列子節所述的安全性機制。

9.1. 權限

裝置實作方式：

  • [C-0-1] 必須支援 Android 開發人員說明文件中定義的 Android 權限模型。具體來說，這些權限「必須」強制執行 SDK 說明文件中定義的各項權限，不得省略、變更或忽略任何權限。

  • 如果新的權限 ID 字串不在 android.\* 命名空間中，也可以新增其他權限。

  • [C-0-2] 只有下列應用程式具有 protectionLevel 的 PROTECTION_FLAG_PRIVILEGED 權限：只有在系統映像檔的特殊權限路徑中預先安裝的應用程式，以及每個應用程式明確加入許可清單的權限子集，才能符合這項規定。Android 開放原始碼計畫實作項目符合這項規定，方法是從 etc/permissions/ 路徑的檔案中讀取及套用每個應用程式的已加入許可清單權限，並使用 system/priv-app 路徑做為特殊權限路徑。

防護等級為危險的權限即為執行階段權限。targetSdkVersion > 22 以上的應用程式在執行階段中提出要求。

裝置實作方式：

  • [C-0-3] 必須顯示專屬介面，讓使用者決定是否要授予要求的執行階段權限，以及提供管理執行階段權限的介面。
  • [C-0-4] 這兩種使用者介面都只能擇一實作。
  • [C-0-5] 除非以下情況，否則「不得」將任何執行階段權限授予預先安裝的應用程式：
    • 應用程式使用前，就能取得使用者的同意聲明。
    • 執行階段權限會與意圖模式相關聯，而意圖模式會將預先安裝的應用程式設為預設處理常式。
  • [C-0-6] 只須將 android.permission.RECOVER_KEYSTORE 權限授予已註冊適當安全復原代理程式的系統應用程式。經過妥善保護的復原代理程式的定義，就是能與裝置外部遠端儲存空間保持同步的裝置端軟體代理程式。這類代理程式具備與 Google Cloud Key Vault 服務中所述同等或更高的防護能力，可避免遭受暴力攻擊 (適用於螢幕鎖定知識因素)。

裝置實作方式：

  • [C-0-7] 如果應用程式透過標準 Android API 或專屬機制要求位置或體能活動資料，必須遵循 Android 位置存取權屬性。這類資料包括但不限於：

    • 裝置的所在位置 (例如經緯度)。
    • 用於判斷或預估裝置所在位置的資訊 (例如 SSID、BSSID、行動網路 ID 或裝置連線的網路位置)。
    • 使用者的體能活動或體能活動分類。

具體來說，裝置實作方式：

  • [C-0-8] 必須取得使用者同意，應用程式才能存取位置或體能活動資料。
  • [C-0-9] 必須「只」授予執行階段權限，「只有」符合 SDK 中所述足夠權限的應用程式。舉例來說，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION。

權限可標示為受限制改變其行為。

  • [C-0-10] 除非以下情況，否則「不得」將標有「hardRestricted」標記的權限授予應用程式：

    • 應用程式 APK 檔案位於系統分區中。
    • 使用者將與 hardRestricted 權限相關聯的角色指派給應用程式。
    • 安裝程式會將 hardRestricted 授予應用程式。
    • 應用程式獲得舊版 Android 的 hardRestricted。

  • [C-0-11] 擁有 softRestricted 權限的應用程式「必須」只能獲得有限的存取權，且「不得」取得完整存取權，除非 SDK 中所述，為每項 softRestricted 權限定義完整和受限的存取權。READ_EXTERNAL_STORAGE

如果裝置實作項目讓使用者自由選擇，要選擇哪些應用程式可於其他應用程式上方繪製，就有處理 ACTION_MANAGE_OVERLAY_PERMISSION 意圖的活動，就會執行以下動作：

  • [C-2-1] 必須確保 ACTION_MANAGE_OVERLAY_PERMISSION 意圖的所有活動具有相同的 UI 畫面，無論啟動的應用程式或其提供的任何資訊都一樣。

9.2. UID 和程序隔離

裝置實作方式：

  • [C-0-1] 必須支援 Android 應用程式沙箱模型，在這個模型中，每個應用程式都會以專屬的 Unixstyle UID 執行，並在獨立的程序中運作。
  • [C-0-2] 必須支援使用同一個 Linux 使用者 ID 執行多個應用程式，前提是這些應用程式已妥善簽署及建構，詳情請參閱「安全性與權限參考資料」。

9.3. 檔案系統權限

裝置實作方式：

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 或類似系統，讓主機電腦存取目前使用者資料。

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)。
  • [C-0-9] 在最初出貨 API 級別 28 以上的裝置上，必須實作靜態和動態物件大小邊界檢查使用者空間與核心空間 (例如 CONFIG_HARDENED_USERCOPY) 之間的副本。
  • [C-0-10] 在最初運送 API 級別 28 以上的裝置上在核心模式 (例如硬體 PXN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 中執行時，「不得」執行使用者空間記憶體。
  • [C-0-11] 在最初出貨 API 級別 28 以上的裝置上，不得透過一般使用者副本存取 API (例如硬體 PAN，或透過 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模擬) 以外的核心，讀取或寫入核心中的使用者空間記憶體。
  • [C-0-12] 如果所有最初運送 API 級別 28 以上的裝置 (例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0) 的硬體容易受到 CVE-2017-5754 安全漏洞影響，請務必導入核心頁面表格隔離功能。
  • [C-0-13] 如果在最初運送 API 級別 28 或以上版本的所有裝置上 (例如 CONFIG_HARDEN_BRANCH_PREDICTOR) 的硬體容易受到 CVE-2017-5715 安全漏洞影響，請務必導入分支版本預測強化功能。
  • [SR] 強烈建議保留只有初始化期間寫入的核心資料 (例如 __ro_after_init)。

  • [C-SR] 強烈建議「不要」隨機設定核心程式碼和記憶體的版面配置，並避免可能導致隨機化資料外洩的情況 (例如透過 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 套用系統啟動載入程式熵時)。CONFIG_RANDOMIZE_BASE

  • [C-SR] 強烈建議在核心中啟用控制流程完整性 (CFI)，為程式碼重複使用攻擊提供額外防護 (例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK)。

  • [C-SR] 強烈建議不要在已啟用這項功能的元件上停用控制流程完整性 (CFI)、陰影呼叫堆疊 (SCS) 或整數溢位清理 (IntSan)。
  • [C-SR] 極力建議您為其他與安全性相關的使用者空間元件啟用 CFI、SCS 和 IntSan，如 CFI 和 IntSan 所述。
  • [C-SR] 強烈建議在核心中啟用堆疊初始化，避免使用未初始化的本機變數 (CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO)。此外，裝置實作不應假設編譯器用於初始化本機變數的值。
  • [C-SR] 強烈建議在核心中啟用堆積初始化功能，避免使用未初始化的堆積分配量 (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)，且不應假設核心用於初始化這些分配作業的值。

如果裝置實作項目使用 Linux 核心，則：

  • [C-1-1] 必須實作 SELinux。
  • [C-1-2] 必須將 SELinux 設為「全域強制執行模式」。
  • [C-1-3] 「必須」在強制執行模式下設定所有網域。不得使用寬鬆模式網域，包括裝置/廠商的專屬網域。
  • [C-1-4] 「不得」修改、省略或取代上游 Android 開放原始碼計畫 (AOSP) 所提供系統/sepolicy 資料夾中存在的規則，以及這項政策「必須」針對 Android 開放原始碼計畫 SELinux 網域以及裝置/供應商專屬網域，編譯所有絕不允許的規則。
  • [C-1-5] 「必須」在個別應用程式的 SELinux 沙箱中，執行目標 API 級別為 28 以上的第三方應用程式，且每個應用程式的私人資料目錄均設有 SELinux 限制。
  • 應保留上游 Android 開放原始碼計畫「system/sepolicy」資料夾內提供的預設 SELinux 政策，並只針對自己的裝置專屬設定再加入這項政策。

如果裝置實作的裝置已推出較舊的 Android 版本，且無法透過系統軟體更新符合 [C-1-1] 和 [C-1-5] 需求條件，就可能不受上述規定的限制。

如果裝置實作項目使用 Linux 以外的核心，就會發生以下情形：

  • [C-2-1] 必須使用與 SELinux 同等的必要存取權控管系統。

Android 包含多種攸關裝置安全性的深度防禦功能。

9.8. 隱私權

9.8.1。使用記錄

Android 會儲存使用者選項的記錄，並透過 UsageStatsManager 管理這類記錄。

裝置實作方式：

  • [C-0-1] 請務必為這類使用者記錄保留合理的保留期限。
  • [SR] 強烈建議將 Android 開放原始碼計畫實作項目的預設設定保留 14 天的保留期限。

Android 會使用 StatsLog ID 儲存系統事件，並透過 StatsManager 和 IncidentManager System API 管理這類記錄。

裝置實作方式：

  • [C-0-2] 只須在 System API 類別 IncidentManager 建立的事件報告中，加入標示為 DEST_AUTOMATIC 的欄位。
  • [C-0-3] 如果不是 StatsLog SDK 文件中所述，不得使用系統事件 ID 來記錄任何其他事件。如果記錄了其他系統事件，這些事件可能會使用不同的 Atom ID，範圍介於 100,000 至 200,000 之間。

9.8.2。錄製

裝置實作方式：

  • [C-0-1] 「不得」在未經使用者同意或清除持續性通知的情況下，立即預先載入或發布會將使用者的私密資訊 (例如按鍵動作、畫面上顯示的文字、錯誤報告) 傳送到裝置以外的軟體元件。
  • [C-0-2] 每當透過 MediaProjection 或專屬 API 啟用螢幕投放或螢幕錄製功能時，都必須顯示並徵得使用者同意，才能擷取任何顯示於使用者畫面上的機密資訊。「不得」為使用者提供預設用途，停止顯示使用者同意聲明。
  • [C-0-3] 在啟用螢幕投放或螢幕錄製功能時，「必須」持續向使用者顯示通知。Android 開放原始碼計畫在狀態列中顯示持續性通知圖示，以符合這項規定。

如果裝置實作包含的系統功能會擷取畫面上顯示的內容，以及/或者透過 System API ContentCaptureService 以外的方式錄製裝置上播放的音訊串流，或是記錄第 9.8.6 節內容擷取中所述的其他專屬方式，那麼裝置就會執行以下動作：

  • [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，則使用者不需另外提供同意聲明，但只有收到通知。

如果裝置實作的使用者負擔，以便開啟第三方 VPN 應用程式的「永久連線 VPN」功能，他們會執行以下動作：

  • [C-3-1] 如果應用程式在 AndroidManifest.xml 檔案中不支援永久連線 VPN 服務，請務必透過將 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 屬性設為 false，停用這位使用者的預設要求。

9.8.5。裝置 ID

裝置實作方式：

  • [C-0-1] 必須防止應用程式存取裝置序號及 IMEI/MEID、SIM 卡序號和國際行動裝置訂閱者身分識別 (IMSI)，除非應用程式符合下列任一條件：
    • 是已簽署的電信業者應用程式，經過裝置製造商驗證。
    • 已授予 READ_PRIVILEGED_PHONE_STATE 權限。
    • 具備 UICC 電信業者權限中定義的電信業者權限。
    • 擁有 READ_PHONE_STATE 權限的裝置擁有者或設定檔擁有者。
    • (僅適用於 SIM 卡序號/ICCID) 根據當地法規，應用程式能偵測訂閱者身分的變化。

9.8.6。內容擷取

Android、透過 System API ContentCaptureService 或其他獨家方式，支援裝置實作機制，可擷取應用程式與使用者之間的下列互動。

  • 在螢幕上顯示的文字和圖形，包括但不限於透過 AssistStructure API 顯示的通知和輔助資料。
  • 裝置錄製或播放的媒體資料，例如音訊或影片。
  • 輸入事件，例如按鍵、滑鼠、手勢、語音、影片和無障礙工具。
  • 應用程式透過 Content Capture API 或類似且功能類似的專屬 API，提供給系統的任何其他事件。
  • 透過 TextClassifier API 傳送至系統 TextClassifier 的任何文字或其他資料，即系統服務以瞭解文字意義，並根據文字產生預測後續動作。

如果裝置導入方式擷取上述資料，就會：

  • [C-1-1] 儲存在裝置中的所有這類資料都必須經過加密。這種加密方式可能使用 Android 檔案型加密機制，或是 Cipher SDK 中列出的 API 26 以上版本加密方法。
  • [C-1-2] 「不得」使用 Android 備份方法或任何其他備份方法備份原始或加密的資料。
  • [C-1-3] 「必須」採用隱私保護機制，「只能」傳送所有這類資料和裝置記錄。隱私權保護機制定義為「僅允許以匯總形式分析記錄的事件或產生的結果，防止比對到個別使用者的資料」，防止所有使用者資料無可避免 (例如使用 RAPPOR 等差異化隱私技術實作)。
  • [C-1-4] 「不得」將這類資料與裝置上的任何使用者身分 (例如 Account) 建立關聯，除非每次與資料建立關聯時均已取得使用者明確同意。
  • [C-1-5] 不得與其他應用程式分享這類資料，除非每次分享都徵得使用者同意。
  • [C-1-6] 如果資料以任何形式儲存在裝置中，「必須」提供使用者適當的責任，清除這些資料是由 ContentCaptureService 或專屬用途收集而來。

如果裝置實作包含實作 System API ContentCaptureService 的服務，或是擷取上述資料的任何專屬服務，就會：

  • [C-2-1] 不得讓使用者以可安裝的應用程式或服務取代內容擷取服務，且「必須」只允許預先安裝的服務擷取這類資料。
  • [C-2-2] 必須允許除了預先安裝的內容擷取服務機制外，「不得」允許任何應用程式擷取這類資料。
  • [C-2-3] 必須提供使用者授權以停用內容擷取服務。
  • [C-2-4] 「不得」省略使用者權限，以管理內容擷取服務持有的 Android 權限，並遵循第 9.1 節權限。

  • [C-SR] 強烈建議將內容擷取服務元件分開，例如，請勿將服務或共用程序 ID 與其他系統元件繫結，但以下項目除外：

    • 電話、聯絡人、系統 UI 和媒體

9.8.7。剪貼簿存取權

裝置實作方式：

  • [C-0-1] 除非應用程式是預設輸入法編輯器，或目前是聚焦的應用程式，否則「不得」傳回剪貼簿中的剪輯資料 (例如透過 ClipboardManager API)。

9.8.8。位置

裝置實作方式：

  • [C-0-1] 未經使用者明確同意或使用者啟動，「不得」開啟/關閉裝置位置資訊設定和 Wi-Fi/藍牙掃描設定。
  • [C-0-2] 必須讓使用者負擔存取位置資訊相關資訊，包括最近的定位要求、應用程式層級權限，以及使用 Wi-Fi/藍牙掃描功能來判斷位置。
  • [C-0-3] 必須確保使用緊急位置略過 API [LocationRequest.setLocationSettingsIgnored()] 的應用程式是使用者啟動的緊急工作階段 (例如：撥打 911 或傳送簡訊至 911)。但以 Automotive 來說，如果偵測到發生車禍/事故時，車輛「可能」在未主動使用者互動的情況下啟動緊急工作階段 (例如滿足電呼叫規定)。
  • [C-0-4] 必須讓 Emergency Location Bypass API 得以在不變更設定的情況下略過裝置位置資訊設定。
  • [C-0-5] 請務必排定通知，讓系統在應用程式透過 [ACCESS_BACKGROUND_LOCATION] 權限存取使用者的位置資訊後，提醒使用者。

9.8.9。已安裝的應用程式

根據預設，指定 API 級別 30 以上的 Android 應用程式將無法查看其他已安裝應用程式的詳細資料 (請參閱 Android SDK 說明文件中的「套件瀏覽權限」)。

裝置實作方式：

  • [C-0-1] 除非應用程式可以透過受管理的 API 查看其他已安裝應用程式的詳細資料，否則皆不得向任何目標 API 級別 30 以上的應用程式提供其他已安裝應用程式的詳細資料。這包括但不限於裝置實作者新增的任何自訂 API，或透過檔案系統存取的詳細資料。

9.8.10。連線錯誤報告

如果裝置導入方式搭配 BugreportManager 使用 System API BUGREPORT_MODE_TELEPHONY 產生錯誤報告，就會發生以下情形：

  • [C-1-1] 每次呼叫 System API BUGREPORT_MODE_TELEPHONY 產生報告時，都必須取得使用者同意聲明，且「不得」提示使用者同意應用程式日後的所有要求。
  • [C-1-2] 開始產生報表時，必須顯示並取得明確的使用者同意聲明；且在未經使用者明確同意的情況下，「不得」將產生的報表傳回給提出要求的應用程式。
  • [C-1-3] 請「必須」產生至少包含下列資訊的指定報表：
    • TelephonyDebugService 轉儲
    • TelephonyRegistry 轉儲
    • WifiService 轉儲
    • ConnectivityService 傾印
    • 呼叫套件的 CarrierService 執行個體的轉儲 (如果已繫結)
    • 無線電記錄緩衝區
  • [C-1-4] 產生的報表中不得包含下列資訊：
    • 任何與連線偵錯無關的資訊。
    • 使用者安裝的任何應用程式流量記錄，或是使用者安裝的應用程式/套件的詳細設定檔 (可使用 UID，但不含套件名稱)。
  • 其中可能包括與任何使用者身分無關的額外資訊。(例如廠商記錄)。

如果裝置實作項目在錯誤報告中提供其他資訊 (例如供應商記錄)，且這類資訊會對隱私權/安全性/電池/儲存空間/記憶體造成影響，就會發生下列情形：

  • [C-SR] 強烈建議將開發人員設定預設為停用。Android 開放原始碼計畫可在開發人員設定中提供 Enable verbose vendor logging 選項，藉此在錯誤報告中加入其他裝置的特定廠商記錄。

9.8.11。資料 blob 共用

Android 透過 BlobStoreManager 允許應用程式向系統提供資料 blob，以便與選定的應用程式組合共用。

如果裝置實作支援共用資料 blob (如 SDK 說明文件所述)，就會：

9.9. 資料儲存加密

所有裝置都必須符合第 9.9.1 節的規定。凡是在本文前推出 API 級別的裝置，皆不受本文件 9.9.2 和 9.9.3 節的規定豁免，但「必須」符合 Android 相容性定義說明文件第 9.9 節的規定 (對應裝置搭載的 API 級別)。

9.9.1。直接啟動

裝置實作方式：

9.9.2。加密規定

裝置實作方式：

  • [C-0-1] 如果應用程式是裝置的永久不可移除部分，請將應用程式私人資料 (/data 分區) 以及應用程式共用儲存空間分區 (/sdcard 分區) 加密。
  • [C-0-2] 在使用者完成開箱設定體驗時，根據預設，「必須」啟用資料儲存空間加密功能。

  • [C-0-3] 必須採用下列其中一種加密方法，以符合上述資料儲存加密規定：

9.9.3. 加密方法

如果裝置實作項目已加密，會：

  • [C-1-1] 必須啟動，且無須向使用者提出憑證驗證要求，且允許直接啟動感知功能應用程式在 ACTION_LOCKED_BOOT_COMPLETED 訊息廣播後存取裝置加密 (DE) 儲存空間。
  • [C-1-2]「必須」僅允許使用者提供憑證 (例如密碼、PIN 碼、解鎖圖案或指紋) 並廣播 ACTION_USER_UNLOCKED 訊息，藉此解鎖裝置後，存取憑證加密 (CE) 儲存空間。
  • [C-1-13] 在沒有使用者提供憑證、已註冊的信託金鑰或符合第 9.9.4 節所列需求條件的情況下，「不得」提供任何解鎖 CE 保護儲存空間的方法。
  • [C-1-4] 必須使用驗證開機程序。

9.9.3.1。使用中繼資料加密功能來加密檔案

如果裝置的實作方式使用檔案型加密和中繼資料加密，就會發生以下情形：

  • [C-1-5] 必須使用 AES-256-XTS 或 Adiantum 來加密檔案內容和檔案系統中繼資料。AES-256-XTS 是進階加密標準與 256 位元加密金鑰長度，在 XTS 模式中運作，完整長度為 512 位元。Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 所述。檔案系統中繼資料是指檔案大小、擁有權、模式和擴充屬性 (xattrs) 等資料。
  • [C-1-6] 必須使用 AES-256-CBC-CTS 或 Adiantum 加密檔案名稱。
  • [C-1-12] 如果裝置具備進階加密標準 (AES) 指示 (例如 ARM 型裝置上的 ARMv8 密碼學擴充功能，或 x86 型裝置上的 AES-NI)，則「必須」使用上述的 AES 選項，例如檔案名稱、檔案系統和檔案系統中繼資料加密機制，而非 Adiantum。
  • [C-1-13] 「必須」使用經過加密且不可逆的高強度金鑰衍生函式 (例如 HKDF-SHA512)，從 CE 和 DE 金鑰衍生任何所需的子金鑰 (例如每個檔案金鑰)。「加密編譯且不可撤銷」是指金鑰衍生函式的安全性強度至少為 256 位元，而且會在輸入內容上做為虛擬函式系列。

  • [C-1-14] 「請勿」為了不同的加密編譯用途，使用相同的檔案式加密 (FBE) 金鑰或子金鑰 (例如用於加密和金鑰衍生，或是兩種不同的加密演算法)。

  • 保護 CE 和 DE 儲存區域以及檔案系統中繼資料的金鑰：

  • [C-1-7] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。這個 KeyStore「必須」繫結於驗證開機程序和裝置的硬體信任根。

  • [C-1-8] CE 金鑰必須繫結至使用者的螢幕鎖定憑證。
  • [C-1-9] 使用者未指定螢幕鎖定憑證時，CE 金鑰必須繫結至預設密碼。
  • [C-1-10] 不得重複，換言之，也就是沒有任何使用者的 CE 或 DE 金鑰與其他使用者的 CE 或 DE 金鑰相符。

  • [C-1-11] 「必須」使用強制支援的加密方式、金鑰長度和模式。

  • 應啟用預先安裝的必要應用程式 (例如鬧鐘、手機、Messenger) 直接啟動偵測功能。

上游 Android 開放原始碼專案根據 Linux 核心的「fscrypt」加密功能，以及基於 Linux 核心「dm-default-key」功能為基礎的中繼資料加密功能，提供偏好的「檔案式加密」實作方式。

9.9.3.2。每位使用者區塊層級加密

如果裝置的實作方式採用個別使用者區塊層級加密，則：

  • [C-1-1] 「必須」啟用第 9.5 節所述的多使用者支援功能。
  • [C-1-2] 必須為每個使用者提供分區，使用原始分區或邏輯磁碟區。
  • [C-1-3] 每位使用者都必須使用不重複的加密金鑰，為基礎區塊裝置加密。

  • [C-1-4] 必須使用 AES-256-XTS 對使用者分區進行區塊層級加密。

  • 保護每位使用者區塊層級加密裝置的金鑰：

  • [C-1-5] 必須使用加密編譯的方式繫結至硬體支援的 KeyStore。這個 KeyStore「必須」繫結於驗證開機程序和裝置的硬體信任根。

  • [C-1-6] 必須繫結至對應使用者的螢幕鎖定憑證。

您可以使用 Linux 核心的「dm-crypt」功能，為個別使用者分區實作區塊層級加密。

9.9.4。重新啟動時繼續

透過在重新啟動時繼續作業可解鎖所有應用程式的 CE 儲存空間，即使應用程式尚未支援直接啟動功能，也能在 OTA 重新啟動後解鎖。這項功能可讓使用者在重新啟動後接收已安裝應用程式的通知。

實施「重新啟動再重新啟動」必須持續確保裝置落入攻擊者手中時，攻擊者很難復原使用者的 CE 加密資料，即使裝置處於開機狀態、已解鎖 CE 儲存空間，以及使用者在收到 OTA 後解鎖裝置也非常困難。為了抵禦內部攻擊，我們也會假設攻擊者獲得廣播加密簽署金鑰的存取權。

詳細說明：

  • [C-0-1] 即使攻擊者實際擁有裝置，並且具有下列功能和限制，仍「不得」讀取 CE 儲存空間：

    • 可使用任何供應商或公司的簽署金鑰簽署任意訊息。
    • 這可能會導致裝置接收 OTA。
    • 可修改任何硬體 (AP、刷新等) 的運作，但下文說明的情況除外，但這類修改作業需要至少 1 小時的延遲時間，並會破壞 RAM 內容。
    • 無法修改防竄改硬體 (例如 Titan M) 的運作情形。
    • 無法讀取使用中裝置的 RAM。
    • 無法取得使用者的憑證 (PIN 碼、解鎖圖案、密碼)，或是導致須輸入。

舉例來說，如果裝置實作方式符合這裡的所有說明，就符合 [C-0-1]。

9.10。裝置完整性

下列規定可確保裝置完整性，清楚呈現裝置完整性。裝置實作方式：

  • [C-0-1] 無論系統啟動載入程式狀態是否允許刷新系統映像檔，都必須透過系統 API 方法 PersistentDataBlockManager.getFlashLockState() 正確回報。FLASH_LOCK_UNKNOWN 狀態會保留給從舊版 Android 升級，且這個新的系統 API 方法不存在的裝置實作。

  • [C-0-2] 必須支援驗證開機程序，確保裝置完整性。

如果裝置實作的裝置在舊版 Android 上沒有支援驗證開機程序，但無法透過系統軟體更新新增這項功能，則這類實作項目可能不受這項規定的限制。

驗證開機程序可保證裝置軟體的完整性。如果裝置實作支援這項功能，就會執行以下動作：

  • [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] 除非使用者已明確解鎖系統啟動載入程式，否則「不得」允許修改裝置上的已驗證分區。
  • [C-SR] 如果裝置上有多個獨立晶片 (例如無線電、特殊影像處理器)，強烈建議每個晶片的啟動程序在啟動時驗證每個階段。
  • [C-1-8] 「必須」使用防竄改儲存空間：儲存系統啟動載入程式是否已解鎖。防竄改儲存空間是指系統啟動載入程式可偵測 Android 內部的儲存空間是否遭到竄改。
  • [C-1-9] 務必在使用者使用裝置時顯示提示，並要求進行實體確認，才能從系統啟動載入程式鎖定模式轉換至系統啟動載入程式解鎖模式。
  • [C-1-10] 必須針對 Android 使用的分區 (例如啟動、系統分區) 導入復原保護機制，並使用防竄改儲存空間儲存中繼資料，藉此判斷系統允許的最小 OS 版本。
  • [C-SR] 強烈建議驗證所有具有特殊權限的應用程式 APK 檔案，並具備由驗證開機程序保護的分區中的信任鏈結。
  • [C-SR] 強烈建議在執行前驗證由具有特殊權限的應用程式在 APK 檔案之外載入的任何可執行構件 (例如動態載入的程式碼或編譯過的程式碼)，或強烈建議不要執行這些構件。
  • 「應該」為任何裝有永久韌體 (例如數據機、相機) 的元件導入復原保護機制，並「應使用防竄改儲存空間」儲存中繼資料，以判斷系統規定的最低允許版本。

如果已在舊版 Android 沒有支援 C-1-8 到 C-1-10 的情況下啟動裝置實作項目，但無法透過系統軟體更新新增支援這些要求，就「可能」不受這類要求規範。

上游 Android 開放原始碼計畫是在 external/avb/ 存放區中提供這項功能的偏好實作方式，可以整合至用於載入 Android 的系統啟動載入程式。

裝置實作方式：

  • [C-0-3] 必須支援針對檔案內容加密驗證，並且不必讀取整個檔案。
  • [C-0-4] 當讀取內容未依據信任的金鑰驗證時，「不得」允許成功對受保護檔案的讀取要求。

如果裝置已啟動裝置，但無法在舊版 Android 上根據信任的金鑰驗證檔案內容，也無法透過系統軟體更新為這項功能提供支援，那麼這類實作項目就「可能」不受這項規定的限制。上游 Android 開放原始碼專案以 Linux kernel fs-verity 功能為基礎，提供這項功能的偏好實作方式。

裝置實作方式：

如果裝置實作支援 Android Protected Confirmation API，就會執行以下動作：

  • [C-3-1] 必須回報 ConfirmationPrompt.isSupported() API 的 true。

  • [C-3-2] 「必須」確保在 Android 作業系統中執行的程式碼 (包括其核心、惡意或其他內容) 在使用者未進行互動的情況下，才能產生正面回應。

  • [C-3-3] 請務必確保使用者能夠審查及核准提示訊息，即使 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，並支援金鑰認證，除非宣告 android.hardware.fingerprint 功能需要獨立執行環境支援的 KeyStore。

  • [C-1-5] 必須允許使用者選擇從解鎖狀態轉換至鎖定狀態的睡眠逾時時間，且最短允許的逾時時間上限為 15 秒。這類汽車裝置會在車用運算主機關閉或使用者切換時鎖定螢幕，但「可能」沒有睡眠逾時設定。

9.11.1. 安全螢幕鎖定和驗證

Android 開放原始碼計畫的實作方式採用分層式驗證模式，其中以知識為根據的主要驗證方式，則由深厚的生物特徵辨識，或採用較低的第三種形式。

裝置實作方式：

  • [C-SR] 強烈建議你只將下列其中一種類型設為主要驗證方法：
    • 數字 PIN
    • 英數字元密碼
    • 3x3 點狀格線中的滑動模式

請注意，上述驗證方式稱為本文中的建議主要驗證方法。

如果裝置實作新增或修改建議的主要驗證方式，並採用新的驗證方法為安全鎖定螢幕，則新的驗證方式如下：

如果裝置實作方式新增或修改驗證方式 (您必須以已知的密鑰為依據)，藉此解鎖螢幕鎖定畫面，並採用新的驗證方法視為安全的螢幕鎖定方式，則適用以下情形：

  • [C-3-1] 允許的最短輸入長度熵必須大於 10 位元。
  • [C-3-2] 所有可能輸入值的最大熵必須大於 18 位元。
  • [C-3-3] 新的驗證方式「不得」取代 Android 開放原始碼計畫中提供的任何建議主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)。
  • [C-3-4] 根據裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法設定密碼品質政策時，「必須」停用新驗證方法，其品質常數比 PASSWORD_QUALITY_SOMETHING 更嚴格。
  • [C-3-5] 新的驗證方法「必須」每隔 72 小時改回使用建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)，或是向使用者清楚揭露某些資料不會備份，以保障資料隱私。

如果裝置實作為解鎖螢幕鎖定功能新增或修改建議的主要驗證方式，並採用以生物特徵辨識技術為基礎的新驗證方法，以便提高螢幕鎖定的安全性，那麼以下新方法：

  • [C-4-1] 必須符合第 7.3.10 節，關於第 1 級的所有規定 (舊稱「便利性」)。
  • [C-4-2] 必須設定備用機制，才能使用以已知密鑰為基礎的建議主要驗證方法。
  • [C-4-3] 必須停用，且只有在裝置政策控制器 (DPC) 應用程式透過呼叫 DevicePolicyManager.setKeyguardDisabledFeatures() 方法，使用任何相關聯的生物特徵辨識旗標 (即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS) 設定鍵盤保護功能時，才允許解鎖螢幕。

如果生物特徵辨識驗證方式不符合第 3 級 (舊稱「強」) 的規定，如第 7.3.10 節所述：

  • [C-5-1] 如果裝置政策控制器 (DPC) 應用程式透過 DevicePolicyManager.setPasswordQuality() 方法 (比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更嚴格的品質常數設定) 設定密碼品質政策，「必須」停用方法。
  • [C-5-2] 必須要求使用者進行建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼)，如第 7.3.10 節所述。如 [C-1-7] 和 [C-1-8]。
  • [C-5-3] 這些方法「不得」視為安全螢幕鎖定，而且必須符合下方本節以 C-8 開頭的規定。

如果裝置實作方式新增或修改用於解鎖螢幕鎖定的驗證方法，且會根據實體權杖或位置採用新的驗證方法：

  • [C-6-1] 這些備援機制「必須」採用備用機制，才能使用建議的主要驗證方法。這些驗證方式是以已知密鑰為基礎，而且必須符合相關條件才能視為安全螢幕鎖定。
  • [C-6-2] 只有在裝置政策控制器 (DPC) 應用程式使用 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法設定比 PASSWORD_QUALITY_UNSPECIFIED 更嚴格的品質常數時，才必須停用新方法，並只允許採用其中一個建議的主要驗證方法解鎖螢幕。
  • [C-6-3] 請務必至少每 4 小時要求使用者驗證任一建議的主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼)。
  • [C-6-4] 「不得」將新方法視為安全螢幕鎖定，且必須遵守下列 C-8 限制。

如果裝置實作項目設有安全螢幕鎖定，且包含一或多個實作 TrustAgentService System API 的信任代理程式，就會執行以下動作：

  • [C-7-1] 當裝置鎖定延遲或被信任的代理程式解鎖時，必須在設定選單和螢幕鎖定畫面上明確指示。舉例來說，Android 開放原始碼計畫符合這項規定，在設定選單中顯示「自動鎖定設定」和「電源按鈕立即鎖定」等文字說明，並在螢幕鎖定畫面上顯示可辨識的圖示。
  • [C-7-2] 必須尊重並完整實作 DevicePolicyManager 類別中的所有信任代理程式 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常數。
  • [C-7-3] 「不得」在一般個人裝置 (例如手持裝置) 上完全實作 TrustAgentService.addEscrowToken() 功能，但「不得」在通常共享的裝置 (例如 Android 電視或 Automotive 裝置) 上完全實作功能。
  • [C-7-4] 必須加密 TrustAgentService.addEscrowToken() 新增的所有已儲存權杖。
  • [C-7-5] 「不得」在使用金鑰的裝置上儲存加密金鑰或託管權杖。舉例來說，使用者可以使用儲存在手機上的金鑰解鎖電視上的使用者帳戶。汽車類裝置不得將託管權杖儲存在車輛的任何部位。
  • [C-7-6] 啟用託管權杖以解密資料儲存空間之前，必須告知使用者安全性方面的影響。
  • [C-7-7] 必須設有備用機制，才能使用建議的主要驗證方法。
  • [C-7-8] 除非使用者有安全疑慮 (例如造成駕駛人分心) 的情況，否則請務必每 72 小時以一次建議的主要驗證方式 (例如 PIN 碼、解鎖圖案、密碼) 進行驗證。
  • [C-7-9] 除非使用者的安全性 (例如駕駛人分心) 有疑慮，否則「必須」驗證使用者接受第 7.3.10 節中 [C-1-7] 和 [C-1-8] 所述的任一建議主要驗證方法 (例如 PIN 碼、解鎖圖案、密碼) 方法。
  • [C-7-10] 不得視為安全螢幕鎖定，且必須遵守下列 C-8 限制。
  • [C-7-11] 「不得」允許主要個人裝置 (例如手持裝置) 上的 TrustAgent 解鎖裝置，且只能讓已解鎖裝置的處於解鎖狀態最長 4 小時。Android 開放原始碼計畫中的 TrustManagerService 預設實作方式符合這項規定。
  • [C-7-12] 「必須」使用經過加密編譯的安全 (例如 UKEY2) 通訊管道，將儲存裝置的信託權杖傳遞至目標裝置。

如果裝置實作方式新增或修改驗證方法，以便解鎖非安全螢幕鎖定畫面 (如上所述)，並使用新的驗證方法解鎖鍵盤保護功能，請按照下列步驟操作：

9.11.2。StrongBox

Android KeyStore 系統可讓應用程式開發人員將加密編譯金鑰儲存在專屬的安全處理器以及上述的獨立執行環境中。這類專屬的安全處理器稱為「StrongBox」。下列要求 C-1-3 到 C-1-11 的要求定義了裝置要符合 StrongBox 條件。

具備專用安全處理器的裝置實作項目：

  • [C-SR] 強烈建議開始支援 StrongBox。StrongBox 可能會成為日後版本中的必要項目。

如果裝置的實作方式支援 StrongBox，會：

  • [C-1-1] 必須宣告 FEATURE_STRONGBOX_KEYSTORE。

  • [C-1-2] 「必須」提供專門用於備份 KeyStore 及保護使用者驗證的專屬安全硬體。獨立的安全硬體可能會用於其他用途。

  • [C-1-3] 必須採用獨立 CPU，而且不會與應用程式處理器 (AP) 共用快取、DRAM、輔助處理器或其他核心資源。

  • [C-1-4] 「必須」確保與 AP 共用的任何週邊裝置均不得以任何方式變更 StrongBox 處理程序，或從 StrongBox 取得任何資訊。AP 可能會停用或禁止存取 StrongBox。

  • [C-1-5] 必須採用具合理準確性 (+-10%) 的內部時鐘，方便 AP 操控。

  • [C-1-6] 必須具備真實的隨機號碼產生器，可產生均勻分佈且無法預測的輸出內容。

  • [C-1-7] 必須防範竄改行為，包括抵抗實體滲透和故障。

  • [C-1-8] 必須採取某些側面的阻力，包括防止透過電源、時機、電磁輻射和熱輻射側邊通道洩漏資訊。

  • [C-1-9] 必須提供安全儲存空間，確保內容的機密性、完整性、真實性、一致性和即時性。除非 StrongBox API 允許，否則「不得」讀取或修改儲存體。

  • 如要驗證裝置是否符合 [C-1-3] 到 [C-1-9] 的規範，裝置實作情形如下：

    • [C-1-10] 「必須」納入經安全 IC Protection 設定檔 BSI-CC-PP-0084-2014 認證的硬體，或通過國家認可的測試實驗室評估，根據智慧型卡片可能遭受攻擊的共通標準，進行高度攻擊潛在安全漏洞的評估。
    • [C-1-11] 「必須」包含經過國家認可的測試實驗室評估的韌體，該實驗室係根據智慧型卡片可能遭受攻擊的常見條件套用，納入高度攻擊潛在安全漏洞評估機制。
    • [C-SR] 強烈建議納入使用安全性目標、評估保證等級 (EAL) 5 評估的硬體，並以 AVA_VAN.5 強化。您可能會在日後的版本中取得 EAL 5 認證。

  • [C-SR] 極力建議提供內部攻擊防範機制 (IAR)，也就是說，擁有韌體簽署金鑰存取權的內部人員不得產生韌體導致 StrongBox 外洩密鑰、規避功能安全性要求，或以其他方式存取敏感的使用者資料。如要實作 IAR，建議您只在透過 IAuthSecret HAL 提供主要使用者密碼時才允許韌體更新。

9.11.3. 身分憑證

身分憑證系統是由實作 android.security.identity.* 套件中的所有 API 所定義與完成。應用程式開發人員可利用這些 API 儲存及擷取使用者身分文件。裝置實作方式：

  • [C-SR] 極力推薦實作身分憑證系統。

如果裝置的實作實作了身分識別憑證系統，就會：

  • [C-0-1] 必須針對 IdentityCredentialStore#getInstance() 方法傳回非空值。

  • [C-0-2] 在安全隔離的區域中，「必須」導入身分識別憑證系統 (例如 android.security.identity.* API) 的程式碼，與可信任的應用程式通訊，且該區域已安全隔離在核心以上以上執行的程式碼。安全隔離「必須」封鎖某些核心或使用者空間程式碼可能會存取隔離環境內部狀態 (包括《數位市場法》) 的所有潛在機制。

  • [C-0-3] 實作身分識別憑證系統所需的加密編譯作業 (例如 android.security.identity.* API)「必須」完全在信任的應用程式中執行，私密金鑰內容則「不得」離開隔離的執行環境，除非較高層級 API 需要特別要求 (例如 createEphemeralKeyPair() 方法)。

  • [C-0-4] 可信任的應用程式「必須」能夠以不影響其安全性屬性的方式加以實作，例如：除非符合存取權控管條件，否則不會釋出憑證資料，也無法產生任何 MAC 供任意資料。

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 架構層下方實作安全性功能，防範與這些子系統惡意或無意間的互動，進而保護資料交換作業。

9.15。訂閱方案

「訂閱方案」是指行動電信業者透過 SubscriptionManager.setSubscriptionPlans() 提供的計費關係方案詳細資料。

所有裝置實作：

  • [C-0-1] 只須將訂閱方案傳回最初提供方案的電信業者應用程式。
  • [C-0-2] 「不得」從遠端備份或上傳訂閱方案。
  • [C-0-3] 「必須」只允許透過目前提供有效訂閱方案的行動電信業者應用程式覆寫 SubscriptionManager.setSubscriptionOverrideCongested() 等覆寫設定。

9.16。應用程式資料遷移

如果裝置的實作項目包含將資料從裝置遷移至其他裝置的功能，且沒有限制應用程式透過 android:fullBackupContent 屬性在資訊清單中設定的應用程式資料，那麼裝置必須符合以下條件：

  • [C-1-1] 如果裝置使用者未設定主要驗證方式，則「不得」啟動應用程式資料轉移作業，如「9.11.1 安全螢幕鎖定和驗證」所述。
  • [C-1-2] 在轉移任何資料前，「必須」安全地確認來源裝置上的主要驗證方式，並徵詢使用者意圖，確認要在來源裝置上複製資料。
  • [C-1-3] 「必須」使用安全金鑰認證，確保在裝置到裝置之間遷移時，來源裝置和目標裝置都是合法的 Android 裝置，且系統啟動載入程式已鎖定。
  • [C-1-4] 「必須」只將應用程式資料遷移至目標裝置上的相同應用程式，並使用相同的套件名稱和簽署憑證。
  • [C-1-5] 「必須」在設定選單中顯示遷移裝置資料後，表示來源裝置已遷移資料。使用者「不得」移除此指標。

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 11 發布多個 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 上游軟體含有可滿足這項規定的更新機制。

  • [C-0-3] 整個更新作業「必須」簽署，且裝置端更新機制「必須」以裝置上儲存的公開金鑰驗證更新和簽名。

  • [C-SR] 強烈建議採用簽署機制，使用 SHA-256 雜湊處理更新內容，並使用 ECDSA NIST P-256 依據公開金鑰驗證雜湊。

如果裝置的實作支援非計量付費數據連線 (例如 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，就會：

12. 文件變更記錄

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

個別部分的異動摘要：

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

12.1. 變更記錄查看提示

變更會標示如下：

  • CDD
    相容性需求有實質性變更。

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

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

13. 與我們聯絡

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