比對規則

兩組相容性矩陣和資訊清單是為了達到 以便確認 架構和供應商導入作業可以相輔相成。這項驗證 在架構相容性矩陣和 裝置資訊清單，並在架構資訊清單和裝置之間 相容性矩陣

這項驗證程序會在建構期間進行，透過 OTA 更新 套件產生時間、啟動時，以及 VTS 相容性測試中。

以下各節將詳細說明 各種元件

架構相容性矩陣版本比對

如要比對裝置資訊清單與架構相容性矩陣， manifest.target-level 指定的運送 FCM 版本 必須和 compatibility-matrix.level。否則沒有相符項目

如果向 libvintf 要求架構相容性矩陣，這項比對作業： 一律成功，因為 libvintf 會開啟裝置資訊清單，並擷取運送資訊 FCM 版本，然後傳回該運送 FCM 版本的架構相容性矩陣 (加上 (FCM 版本高的相容性矩陣選用) 產生的 HAL)。

HAL 賽事

HAL 比對規則會找出物件中的 hal 元素版本 Deployment 規格，由相應的 相容性矩陣

HIDL 和原生 HAL

HIDL 和原生 HAL 的比對規則如下。

  • 系統會使用單一 AND 評估多個 <hal> 元素 關係
  • <hal> 元素可能須有 <hal optional="true">，才能標示為 不需要。
  • 同一個內有多個 <version> 元素 <hal> 具有 或 關係，如果指定兩個以上的指定值， 其中一個版本需要實作(請見下方的 DRM 範例)。
  • 多個<instance>和 相同的 <regex-instance> 元素 系統會使用單一 AND 關係來評估 <hal>，而且 「<hal>」為必填欄位。(請參閱下方的 <ahref="#drm">DRM 範例)。</ahref="#drm">

範例：成功比對模組 HAL

如果是 HAL 2.5 版，比對規則如下：

格狀模式 相符的資訊清單
2.5 2.5-2.∞。在相容性矩陣中，2.5 是 2.5-5。
2.5-7 2.5-2.∞。表示以下內容：
  • 2.5 是最低需求版本，代表提供 HAL 的資訊清單 2.0-2.4 版本不相容。
  • 2.7 代表可要求的最高版本，意指 相容性矩陣 (架構或裝置) 不會要求版本 超過 2.7 個相符資訊清單的擁有者仍可提供 2.10 版 (做為範例) 要求 2.7 時。相容性矩陣擁有者知道 只有要求的服務與 API 2.7 版相容。
  • -7 僅供參考，並不會影響 OTA 更新程序。
，瞭解如何調查及移除這項存取權。 因此，裝置資訊清單檔案中的 HAL 為 2.10 版 該架構狀態會指出 2.5-7 相容性矩陣。

範例：DRM 模組 HAL 比對成功

架構相容性矩陣指出下列版本資訊 針對 DRM HAL：

<hal>
    <name>android.hardware.drm
    <version>1.0</version>
    <version>3.1-2</version>
    <interface>
        <name>IDrmFactory</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.drm
    <version>2.0</version>
    <interface>
        <name>ICryptoFactory</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

供應商必須導入下列其中一種執行個體：任一

android.hardware.drm@1.x::IDrmFactory/default          // where x >= 0
android.hardware.drm@1.x::IDrmFactory/specific         // where x >= 0
或 
android.hardware.drm@3.y::IDrmFactory/default          // where y >= 1
android.hardware.drm@3.y::IDrmFactory/specific         // where y >= 1

「且」還必須實作下列所有執行個體：

android.hardware.drm@2.z::ICryptoFactory/default       // where z >= 0
android.hardware.drm@2.z::ICryptoFactory/${INSTANCE}
            // where z >= 0 and ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

AIDL HAL

Android 11 以上版本的所有 Android 版本 (Android 除外) 11) 支援 VINTF 中 AIDL HAL 的版本。 AIDL HAL 的比對規則與 HIDL 和原生 HAL 的比對規則相似，唯獨例外情況： 沒有主要版本，而且每個 HAL 執行個體只有一個版本 (1 如果 則未指定版本)。

  • 系統會使用單一 AND 評估多個 <hal> 元素 關係
  • <hal> 元素可能須有 <hal optional="true">，才能標示為 不需要。
  • 多個<instance>和 相同的 <regex-instance> 元素 系統會使用單一 AND 關係來評估 <hal>，而且 「<hal>」為必填欄位。(請參閱下方的<ahref="#vibrator">震動範例)。</ahref="#vibrator">

範例：成功比對模組 HAL

對於 HAL 第 5 版，比對規則如下：

格狀模式 相符的資訊清單
5 5-∞。在相容性矩陣中，5 是 5-5。
5-7 5-∞。表示以下內容：
  • 第 5 版是最低需求版本，代表提供 HAL 的資訊清單 1 至 4 不相容。
  • 7 代表可要求的最高版本，意指 相容性矩陣 (架構或裝置) 不會要求版本 超過 7 人。相符資訊清單的擁有者仍可提供第 10 版 (例如：請求 7)。相容性矩陣擁有者知道 只有要求的服務與 API 版本 7 相容。
  • -7 僅供參考，並不會影響 OTA 更新程序。
，瞭解如何調查及移除這項存取權。 因此，裝置資訊清單檔案中的 HAL 為 10 版 該架構狀態會指出 5-7 相容性矩陣。

範例：成功比對多個模組

架構相容性矩陣指出下列版本資訊 震動器和相機 HAL：

<hal>
    <name>android.hardware.vibrator
    <version>1-2</version>
    <interface>
        <name>IVibrator</name>
        <instance>default</instance>
        <instance>specific</instance>
    </interface>
</hal>
<hal>
    <name>android.hardware.camera
    <version>5</version>
    <interface>
        <name>ICamera</name>
        <instance>default</instance>
        <regex-instance>[a-z]+/[0-9]+</regex-instance>
    </interface>
</hal>

廠商必須實作下列所有執行個體：

android.hardware.vibrator.IVibrator/default     // version >= 1
android.hardware.vibrator.IVibrator/specific    // version >= 1
android.hardware.camera.ICamera/default         // version >= 5
android.hardware.camera.ICamera/${INSTANCE}
            // with version >= 5, where ${INSTANCE} matches [a-z]+/[0-9]+
            // e.g. legacy/0

核心比對

架構相容性矩陣的 <kernel> 區段 說明瞭裝置上 Linux kernel 的架構需求。這個 應該用來比對 資訊 有關裝置 VINTF 物件回報的核心問題。

比對核心分支版本

每個核心分支版本後置字串 (例如 5.4-r) 都會對應至不重複的 核心 FCM 版本 (例如 5)。對應內容與發布字母之間的對應相同 (例如 R) 和 FCM 版本 (例如 5)。

VTS 測試會強制裝置在 裝置資訊清單 (/vendor/etc/vintf/manifest.xml) (如果符合下列任一條件)：

  • 核心 FCM 版本與目標 FCM 版本不同。舉例來說， 上述裝置搭載目標 FCM 第 4 版，核心 FCM 版本為 5 (核心) 分支版本後置字串 r)。
  • 核心 FCM 版本大於或等於 5 (核心分支版本後置字串 r)。
，瞭解如何調查及移除這項存取權。

VTS 測試會強制執行，如果指定核心 FCM 版本，核心 FCM 版本就會是 大於或等於裝置資訊清單中的目標 FCM 版本。

範例：判斷核心分支版本

如果裝置指定 FCM 版本 4 (已在 Android 10 中發布)， 會從 4.19-r 分支版本執行核心，裝置資訊清單應指定以下內容： 

<manifest version="2.0" type="device" target-level="4">
   <kernel target-level="5" />
</manifest>

VINTF 物件會檢查核心相容性是否符合 4.19-r 核心的要求 在 FCM 版本 5 中指定的分支版本。這些需求的建構基礎是 kernel/configs/r/android-4.19 。

範例：判斷 GKI 的核心分支

如果裝置使用通用核心映像檔 (GKI)，以及 /proc/version 如下：

5.4.42-android12-0-00544-ged21d463f856

接著，VINTF 物件會從核心版本取得 Android 版本，並使用該版本判斷 核心 FCM 版本。在本範例中，android12 表示核心 FCM 第 6 版 (已於 Android 12 發布)。

如要進一步瞭解如何剖析核心版本字串，請參閱 GKI 版本管理。

比對核心版本

矩陣可包含多個 <kernel> 區段，每個區段都有 其他 version 屬性，格式如下：

${ver}.${major_rev}.${kernel_minor_rev}

VINTF 物件只會考量<kernel> FCM 版本與 FCM 版本相符 ${ver} 和 ${major_rev} 做為裝置核心 (即 version="${ver}.${major_rev}.${matrix_minor_rev}")；其他版面 系統會忽略此值。此外，核心的次要修訂版本必須為值 來自相容性矩陣 (${kernel_minor_rev} >= ${matrix_minor_rev};)。如果沒有符合<kernel>的部分 就會視為不相符

範例：選取比對條件

假設 /system/etc/vintf 中的 FCM 宣告了 以下規定 (省略標頭和頁尾標記)： 

<!-- compatibility_matrix.3.xml -->
<kernel version="4.4.107" level="3"/>
<!-- See kernel/configs/p/android-4.4/ for 4.4-p requirements -->
<kernel version="4.9.84" level="3"/>
<!-- See kernel/configs/p/android-4.9/ for 4.9-p requirements -->
<kernel version="4.14.42" level="3"/>
<!-- See kernel/configs/p/android-4.14/ for 4.14-p requirements -->

<!-- compatibility_matrix.4.xml -->
<kernel version="4.9.165" level="4"/>
<!-- See kernel/configs/q/android-4.9/ for 4.9-q requirements -->
<kernel version="4.14.105" level="4"/>
<!-- See kernel/configs/q/android-4.14/ for 4.14-q requirements -->
<kernel version="4.19.42" level="4"/>
<!-- See kernel/configs/q/android-4.19/ for 4.19-q requirements -->

<!-- compatibility_matrix.5.xml -->
<kernel version="4.14.180" level="5"/>
<!-- See kernel/configs/r/android-4.14/ for 4.14-r requirements -->
<kernel version="4.19.123" level="5"/>
<!-- See kernel/configs/r/android-4.19/ for 4.19-r requirements -->
<kernel version="5.4.41" level="5"/>
<!-- See kernel/configs/r/android-5.4/ for 5.4-r requirements -->

目標 FCM 版本、核心 FCM 版本和核心版本會同時選取核心 FCM 的要求：

目標 FCM 版本核心 FCM 版本核心版本比對依據
3 (P)未指定4.4.106 不相符 (子版本不符)
3 (P)未指定4.4.107 4.4-p
3 (P)未指定4.19.42 4.19-q (請參閱下方附註)
3 (P)未指定5.4.41 5.4-r (請參閱下方附註)
3 (P)3 (P)4.4.107 4.4-p
3 (P)3 (P)4.19.42 不相符 (沒有 4.19-p 核心分支版本)
3 (P)4 (Q)4.19.42 4.19-q
4 (Q)未指定4.4.107 不相符 (沒有 4.4-q 核心分支版本)
4 (Q)未指定4.9.165 4.9-q
4 (Q)未指定5.4.41 5.4-r (請參閱下方附註)
4 (Q)4 (Q)4.9.165 4.9-q
4 (Q)4 (Q)5.4.41 不相符 (沒有 5.4-q 核心分支版本)
4 (Q)5 (R)4.14.1054.14-r
4 (Q)5 (R)5.4.41 5.4-r
5 (R)未指定任何VTS 失敗 (必須針對目標 FCM 版本 5 指定核心 FCM 版本)
5 (R)4 (Q)任何VTS 失敗 (核心 FCM 版本 <目標 FCM 版本)
5 (R)5 (R)4.14.1804.14-r

採用核心設定

如果 <kernel> 部分相符，程序就會繼續進行 嘗試比對 config 元素 /proc/config.gz。針對相容性中的每項設定元素 矩陣，它會查詢 /proc/config.gz 來確認該設定是否 。當相容性中的設定項目設為「n」時 對於相符的 <kernel> 區段的矩陣，此矩陣必須不存在 出發地：/proc/config.gz。最後，設定項目不在 相容性矩陣不一定存在於 /proc/config.gz 中。

範例：比對核心設定

  • <value type="string">bar</value> 個相符的項目 "bar"。相容性矩陣會省略引號，但目前存在 在「/proc/config.gz」中。
  • <value type="int">4096</value> 個相符的項目 4096、0x1000 或 0X1000。
  • <value type="int">0x1000</value> 個相符的項目 4096、0x1000 或 0X1000。
  • <value type="int">0X1000</value> 個相符的項目 4096、0x1000 或 0X1000。
  • <value type="tristate">y</value> 個相符的項目 y。
  • <value type="tristate">m</value> 個相符的項目 m。
  • <value type="tristate">n</value> 表示設定 項目「不得」存在於「/proc/config.gz」中。
  • <value type="range">1-0x3</value> 個相符的項目 1、2 或 3 或對等的十六進位值。

範例：成功的核心比對

與 FCM 第 1 版搭配使用的架構相容性矩陣具有下列核心資訊：

<kernel version="4.14.42">
   <config>
      <key>CONFIG_TRI</key>
      <value type="tristate">y</value>
   </config>
   <config>
      <key>CONFIG_NOEXIST</key>
      <value type="tristate">n</value>
   </config>
   <config>
      <key>CONFIG_DEC</key>
      <value type="int">4096</value>
   </config>
   <config>
      <key>CONFIG_HEX</key>
      <value type="int">0XDEAD</value>
   </config>
   <config>
      <key>CONFIG_STR</key>
      <value type="string">str</value>
   </config>
   <config>
      <key>CONFIG_EMPTY</key>
      <value type="string"></value>
   </config>
</kernel>

系統會先比對核心分支版本。已在裝置資訊清單中指定核心分支版本 manifest.kernel.target-level，預設為 manifest.level 否則就會發生錯誤如果裝置資訊清單中的核心分支版本：

  • 1，繼續進行下一個步驟並檢查核心版本。
  • 為 2，沒有與矩陣配對。VINTF 物件會讀取矩陣上的核心需求 請改用 FCM 第 2 版。

然後比對核心版本。如果「uname()」中的裝置 報告：

  • 4.9.84 (除非有包含 <kernel version="4.9.x"> 的獨立核心部分，其中 x <= 84 除外)，否則與矩陣不相符
  • 4.14.41 (與小於 version 的矩陣不相符)
  • 4.14.42 (比對矩陣)
  • 4.14.43 (比對矩陣)
  • 4.1.22 (除非有獨立的核心區段，否則不會與矩陣進行比對 與<kernel version="4.1.x">合作，地點：x <= 22)

選取適當的 <kernel> 部分後， 每個 <config> 項目的值不是 n 對應項目都會顯示在 /proc/config.gz 中； 每個 <config> 項目 (值為 n) 的情況下，則可以設定 不要在 /proc/config.gz 中顯示對應項目。三 預期 <value> 的內容與 等號 (含引號)，最長為換行字元或 #，開頭和結尾空格遭到截斷。

以下核心設定為成功比對範例：

# comments don't matter
CONFIG_TRI=y
# CONFIG_NOEXIST shouldn't exist
CONFIG_DEC = 4096 # trailing comments and whitespaces are fine
CONFIG_HEX=57005  # 0XDEAD == 57005
CONFIG_STR="str"
CONFIG_EMPTY=""   # empty string must have quotes
CONFIG_EXTRA="extra config items are fine too"

以下是比對失敗的範例：

CONFIG_TRI="y"   # mismatch: quotes
CONFIG_NOEXIST=y # mismatch: CONFIG_NOEXIST exists
CONFIG_HEX=0x0   # mismatch; value doesn't match
CONFIG_DEC=""    # mismatch; type mismatch (expect int)
CONFIG_EMPTY=1   # mismatch; expects ""
# mismatch: CONFIG_STR is missing

SE 政策相符

SE 政策須有下列相符項目：

  • <sepolicy-version> 定義了未成年人的封閉範圍 每個主要版本的版本裝置回報的裝置政策版本 必須落在其中一個範圍之內，才能與架構相容。比對 這類規則類似於 HAL 版本如果政策版本是 大於或等於該範圍的最低版本最高版本為 且完全僅供參考
  • <kernel-sepolicy-version> (即 policydb 版本)。必選 低於裝置回報的 security_policyvers()。

範例：成功比對 SE 政策

架構相容性矩陣指出下列這些政策資訊： 

<sepolicy>
    <kernel-sepolicy-version>30</kernel-sepolicy-version>
    <sepolicy-version>25.0</sepolicy-version>
    <sepolicy-version>26.0-3</sepolicy-version>
</sepolicy>

在裝置上：

  • security_policyvers() 傳回的值必須大於 等於或等於 30。否則就無法比對。例如：
    • 如果裝置傳回 29 錯誤，即不視為比對相符。
    • 如果裝置傳回 31，表示比對符合條件。
  • SE 政策版本必須為 25.0-∞ 或 26.0-∞ 的其中一個版本。否則， 比對。(「26.0」之後的「-3」只是單純 )

AVB 版本相符

AVB 版本包含 MAJOR 版本和 MINOR 版本，格式為 如同 MAJOR.MINOR (例如1.0、2.1)。詳情請參閱 版本管理 以及相容性AVB 版本具有以下系統屬性：

  • ro.boot.vbmeta.avb_version 是 libavb 版本 系統啟動載入程式中
  • ro.boot.avb_version是libavb版本 Android 作業系統 (init/fs_mgr)

只有在使用對應的 libavb 時，系統屬性才會顯示 驗證 AVB 中繼資料 (並傳回「確定」)。如果驗證失敗，就會顯示出來 發生 (或根本沒有執行任何驗證)。

相容性比對的比較表如下：

  • sysprop ro.boot.vbmeta.avb_version 為 來自架構相容性矩陣的 avb.vbmeta-version；
    • ro.boot.vbmeta.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.vbmeta.avb_version.MINOR >= avb.vbmeta-version.MINOR
  • sysprop ro.boot.avb_version 為 來自架構相容性矩陣的 avb.vbmeta-version。
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

系統啟動載入程式或 Android 作業系統可能包含兩個 libavb 副本 分別針對升級裝置及推出應用程式各有不同的 MAJOR 版本 裝置。在此情況下，您可以共用相同的未簽署系統映像檔，但 最終的已簽署的系統映像檔不同 (不同 avb.vbmeta-version)：

圖 1. AVB 版本相符 (/系統為 P，所有其他分區皆為 O)。



圖 2. AVB 版本相符 (所有分區皆為 P)。

範例：成功比對 AVB 版本

架構相容性矩陣說明下列 AVB 資訊：

<avb>
    <vbmeta-version>2.1</vbmeta-version>
</avb>

在裝置上：

ro.boot.avb_version              == 1.0 &&
ro.boot.vbmeta.avb_version       == 2.1  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 3.0  mismatch 

ro.boot.avb_version              == 2.1 &&
ro.boot.vbmeta.avb_version       == 2.3  match 

ro.boot.avb_version              == 2.3 &&
ro.boot.vbmeta.avb_version       == 2.1  match 

在 OTA 期間比對 AVB 版本

若是搭載 Android 9 以下版本的裝置，則更新至 Android 10 (AVB) 架構相容性矩陣中的版本需求與目前的 AVB 比對符合 版本。如果 AVB 版本在 OTA 期間有主要版本升級 (例如 從 0.0 到 1.0，則 OTA 中的 VINTF 檢查相容性並未反映之後的相容性 網路旅行社。

為解決這個問題，原始設備製造商 (OEM) 可將假的 AVB 版本加入 OTA 套件中 (compatibility.zip) 通過檢查。方法如下：

  1. 將下列 CL 選入 Android 9 來源樹狀結構：
  2. 為裝置定義 BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE。其值 應等於 OTA 之前的 AVB 版本，也就是裝置的 AVB 版本
  3. 重新建構 OTA 套件。

這些變更會自動套用 BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE 為 「compatibility-matrix.avb.vbmeta-version」在下列檔案中：

  • /system/compatibility_matrix.xml (未於 Android 9 中使用)
  • OTA 套件中 compatibility.zip 中的 system_matrix.xml

這些變更不會影響其他架構相容性矩陣，包括 /system/etc/vintf/compatibility_matrix.xml。收到 OTA 後， 請改用 /system/etc/vintf/compatibility_matrix.xml 進行相容性檢查。

VNDK 版本相符

裝置相容性矩陣會宣告 compatibility-matrix.vendor-ndk.version。如果裝置 相容性矩陣沒有 <vendor-ndk> 標記，沒有 這些條件就視為比對成功。

如果裝置相容性矩陣有 <vendor-ndk> 標記，<vendor-ndk> 項目具有 「<version>」是根據 VNDK 供應商快照集所查詢 由架構資訊清單中的架構提供如果無效項目 沒有相符項目。

如果這類應用程式確實存在，則裝置列舉的程式庫組合 相容性矩陣必須是 架構資訊清單；否則該項目就不會視為相符項目。

  • 做為特殊情況，如果裝置上沒有列舉任何程式庫 相容性矩陣則一律視為相符，因為沒有任何內容 是任何集合的子集

範例：成功的 VNDK 版本比對成功

如果裝置相容性矩陣在 VNDK 上指出下列規定： 

<!-- Example Device Compatibility Matrix -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>

在架構資訊清單中，系統只會考慮版本 27 的項目。

<!-- Framework Manifest Example A -->
<vendor-ndk>
    <version>27</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
    <library>libfoo.so</library>
</vendor-ndk>

範例 A 是相符項目，因為 VNDK 版本 27 位於架構資訊清單中。 和{libjpeg.so, libbase.so, libfoo.so} ⊇ {libjpeg.so, libbase.so}。 

<!-- Framework Manifest Example B -->
<vendor-ndk>
    <version>26</version>
    <library>libjpeg.so</library>
    <library>libbase.so</library>
</vendor-ndk>
<vendor-ndk>
    <version>27</version>
    <library>libbase.so</library>
</vendor-ndk>

範例 B 不相符。雖然 VNDK 27 版架構 資訊清單，libjpeg.so 架構不支援該架構 完全不必建立快照已忽略 VNDK 26 版。

系統 SDK 版本比對

裝置相容性矩陣宣告了一組必要的 System SDK compatibility-matrix.system-sdk.version 版。還有 只有在集合是如宣告提供的一組系統 SDK 版本時，才會進行比對 部分manifest.system-sdk.version。

  • 如果裝置沒有列舉任何系統 SDK 版本，這是特殊情況。 它一律視為相符 是任何集合的子集

範例：成功的系統 SDK 版本比對

如果裝置相容性矩陣在「系統」上指出下列要求 SDK： 

<!-- Example Device Compatibility Matrix -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

然後，該架構必須提供 System SDK 26 版和 27 版才能比對。

<!-- Framework Manifest Example A -->
<system-sdk>
    <version>26</version>
    <version>27</version>
</system-sdk>

範例 A 即為比對符合項目。

<!-- Framework Manifest Example B -->
<system-sdk>
    <version>26</version>
    <version>27</version>
    <version>28</version>
</system-sdk>

範例 B 即為比對符合項目。

<!-- Framework Manifest Example C -->
<system-sdk>
    <version>26</version>
</system-sdk>

由於未提供系統 SDK 27 版，因此範例 C 不相符。