裝置資訊清單開發

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

開發及發布新裝置時，廠商可以在裝置資訊清單 (DM) 中定義及宣告目標 FCM 版本。為舊款裝置升級供應商映像檔時，供應商可以選擇實作新的 HAL 版本，並增加目標 FCM 版本。

開發新裝置

為新裝置定義裝置目標 Firebase 雲端通訊版本時：

1. 將 DEVICE_MANIFEST_FILE 和 PRODUCT_ENFORCE_VINTF_MANIFEST 保留為未定義。
2. 針對目標 FCM 版本實作 HAL。
3. 編寫正確的裝置資訊清單檔案。
4. 將目標 FCM 版本寫入裝置資訊清單檔案。
5. 設定 DEVICE_MANIFEST_FILE。
6. 將 PRODUCT_ENFORCE_VINTF_MANIFEST 設為 true。

發布新裝置

新裝置發布時，需要判斷其初始目標 FCM 版本，並在裝置資訊清單中宣告為頂層 <manifest> 元素中的「target-level」屬性。

舉例來說，搭載 Android 9 的裝置必須指定 FCM 版本為 3 (目前可用的較高版本)。如要在裝置資訊清單中宣告此項目，請按照下列步驟操作：

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

升級供應商映像檔

為舊裝置升級供應商映像檔時，供應商可以選擇實作新的 HAL 版本，並增加目標 FCM 版本。

升級 HAL

供應商可在供應商映像檔升級期間實作新的 HAL 版本，前提是 HAL 名稱、介面名稱和例項名稱相同。例如：

• Google Pixel 2 和 Pixel 2 XL 裝置以指定的 FCM 2 版發布，該版本實作了所需的音訊 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default。
• 針對與 Android 9 一併發布的音訊 4.0 HAL，Google Pixel 2 和 Pixel 2 XL 裝置可使用完整 OTA 升級至 4.0 HAL，該 HAL 會實作 android.hardware.audio@4.0::IDeviceFactory/default。
• 雖然 compatibility_matrix.2.xml 只指定音訊 2.0，但如果供應商映像檔指定的 FCM 版本為 2，則對其功能的要求會放寬，因為 Android 9 架構 (FCM 3 版) 會將音訊 4.0 視為音訊 2.0 HAL 的功能替代方案。

總而言之，由於 compatibility_matrix.2.xml 需要音訊 2.0，而 compatibility_matrix.3.xml 需要音訊 4.0，因此相關需求如下：

升級目標 FCM 版本

供應商也可以在供應商映像檔升級期間遞增目標 FCM 版本，指定升級供應商映像檔可搭配使用的目標 FCM 版本。如要提升裝置的目標 Firebase 雲端通訊版本，供應商必須：

1. 為目標 FCM 版本實作所有必要的新 HAL 版本。
2. 修改裝置資訊清單檔案中的 HAL 版本。
3. 在裝置資訊清單檔案中修改目標 FCM 版本。
4. 移除已淘汰的 HAL 版本。

舉例來說，Google Pixel 和 Pixel XL 裝置搭載 Android 7.0，因此其指定的 FCM 版本必須至少為舊版。不過，由於供應商映像檔已更新為符合 compatibility_matrix.2.xml，因此裝置資訊清單會宣告目標 FCM 版本 2：

<manifest version="1.0" type="device" target-level="2">

如果廠商未導入所有必要的新版 HAL，或是未移除已淘汰的 HAL 版本，就無法升級目標 FCM 版本。

舉例來說，Google Pixel 2 和 Pixel 2 XL 裝置的目標 FCM 版本為 2。雖然這些應用程式確實實作 compatibility_matrix.3.xml 所需的部分 HAL (例如 audio 4.0、health 2.0 等)，但不會移除 android.hardware.radio.deprecated@1.0，後者已在 FCM 3 版 (Android 9) 中淘汰。因此，這些裝置無法將目標 FCM 版本升級至 3。

在 OTA 期間強制執行核心需求

更新搭載 Android 9 以下版本的裝置

在搭載 Android 9 以下版本的裝置上，請確認以下 CL 已挑選：

• CL 722283
• CL 722284
• CL 722345

這些變更會引入建構標記 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS，並讓標記在搭載 Android 9 以下版本的裝置上保持未設定狀態。

• 更新至 Android 10 時，搭載 Android 9 以下版本的裝置上的 OTA 用戶端無法正確檢查 OTA 套件中的核心需求。這些變更是為了從產生的 OTA 套件中移除核心需求。
• 更新至 Android 11 時，您可以選擇設定 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS 建構標記，在產生更新套件時檢查 VINTF 相容性。

如要進一步瞭解這個建構標記，請參閱「從 Android 10 更新裝置」。

從 Android 10 更新裝置

Android 10 推出了新的建構標記 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS。對於搭載 Android 10 的裝置，系統會自動將此標記設為 true。當標記設為 true 時，指令碼會從已安裝的核心映像檔中擷取核心版本和核心設定。

• 更新至 Android 10 時，OTA 更新套件會包含核心版本和設定。搭載 Android 10 的裝置上的 OTA 用戶端會讀取這項資訊，以檢查相容性。
• 更新至 Android 11 時，OTA 套件產生程序會讀取核心版本和設定，以檢查相容性。

如果指令碼無法擷取核心映像檔的這項資訊，請執行下列一項操作：

• 編輯指令碼以支援您的核心格式，並為 AOSP 做出貢獻。
• 將 BOARD_KERNEL_VERSION 設為核心版本，並將 BOARD_KERNEL_CONFIG_FILE 設為已建構的核心設定檔 .config 的路徑。更新核心映像檔時，必須更新這兩個變數。
• 或者，您也可以將 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS 設為 false，略過檢查核心需求。不建議這麼做，因為任何不相容性問題都會隱藏，只有在更新後執行 VTS 測試時才會發現。

您可以查看核心資訊擷取指令碼 extract_kernel.py 的原始碼。