裝置資訊清單開發

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

開發新裝置

為新裝置定義裝置目標 FCM 版本時，請注意下列事項：

  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，其中實作了必要的 Audio 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，進而實作 android.hardware.audio@4.0::IDeviceFactory/default。
  • 即使 compatibility_matrix.2.xml 只指定音訊 2.0，由於 Android 9 架構 (FCM 版本 3) 認為音訊 4.0 在功能方面可取代音訊 2.0 HAL，因此針對目標 FCM 版本 2 的供應商映像檔，這項規定已放寬。

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

FCM 版本 (系統) 目標 FCM 版本 (廠商) 需求條件
2 (8.1) 2 (8.1) 音訊 2.0
3 (9) 2 (8.1) 音訊 2.0 或 4.0
3 (9) 3 (9) 音訊 4.0

升級目標 FCM 版本

在供應商圖片升級期間，供應商也可以遞增目標 FCM 版本，指定升級後的供應商圖片可搭配使用的目標 FCM 版本。如要將裝置的目標 FCM 版本調高，供應商必須：

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

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

<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 (例如音訊 4.0、健康 2.0 等)，但不會移除 android.hardware.radio.deprecated@1.0，而這個 HAL 在 FCM 第 3 版 (Android 9) 中已遭淘汰。因此，這些裝置無法將目標 FCM 版本升級至 3。

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

從 Android 9 以下版本更新裝置

如果裝置搭載 Android 9 以下版本，請確認已挑選下列 CL：

這些變更會導入建構旗標 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。