匹配規則

這兩對兼容性矩陣和清單旨在協調以驗證框架和供應商實現是否可以相互配合。該驗證在框架兼容性矩陣與設備清單之間以及框架清單與設備兼容性矩陣之間匹配時成功。

這種驗證在編譯的時候做，在OTA升級包產生的時間，在系統啟動時，在VTS兼容性測試。

以下部分詳細介紹了各種組件使用的匹配規則。

框架兼容性矩陣版本匹配

以配合的框架兼容性矩陣的裝置清單中，由指定的郵費FCM版本manifest.target-level必須正好等於由指定的FCM版本compatibility-matrix.level 。否則沒有匹配。

當被要求與框架的兼容性矩陣libvintf ，這場比賽永遠是成功的，因為libvintf打開設備清單，檢索航運FCM版本，並返回框架兼容性矩陣，航運FCM版本（加上從兼容性矩陣較高FCM一些可選的HAL版本）。

HAL 比賽

的HAL-匹配規則識別的版本hal在清單文件中的元素被認為是由相應的兼容性矩陣的所有者來支持。

HIDL 和原生 HAL

HIDL 和原生 HAL 的匹配規則如下。

  • 多個<hal>元件與單個AND關係進行評價。
  • 多個<version>同一內的元素<hal>具有OR關係。如果指定兩個或兩個以上，則只需要實現其中一個版本。 （請參閱DRM實例下文）。
  • 多個<instance>和<regex-instance>內相同的元素<hal>與單個AND關係進行評價。 （請參閱DRM實例下文）。

示例：模塊的成功 HAL 匹配

對於 2.5 版本的 HAL，匹配規則如下：

矩陣匹配清單
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.7 時，匹配清單的所有者仍然可以提供 2.10 版本（作為示例）。兼容性矩陣所有者只知道請求的服務與 API 版本 2.7 兼容。
  • -7 僅供參考，不會影響 OTA 更新過程。
因此，在其清單文件版本2.10一個HAL一個裝置保持與框架相兼容，各國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

AND 還必須實現所有這些實例：

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如果版本是不確定的）。

  • 多個<hal>元件與單個AND關係進行評價。
  • 多個<instance>和<regex-instance>內相同的元素<hal>與單個AND關係進行評價。 （請參見振動器示例下文）。

示例：模塊的成功 HAL 匹配

對於版本 5 的 HAL，匹配規則如下：

矩陣匹配清單
5 5-∞。在兼容性矩陣， 5是用於速記5-5 。
5-7 5-∞。表示以下內容：
  • 5 是最低要求版本，這意味著提供 HAL 1-4 的清單不兼容。
  • 7 是可以請求的最大版本，這意味著兼容性矩陣（框架或設備）的所有者不會請求超過 7 的版本。當請求 7 時，匹配清單的所有者仍然可以提供版本 10（作為示例） .兼容性矩陣所有者只知道請求的服務與 API 版本 7 兼容。
  • -7 僅供參考，不會影響 OTA 更新過程。
因此，在其清單文件版本10中的HAL的裝置保持與框架相兼容，各國5-7在其兼容性矩陣。

示例：多個模塊的成功 HAL 匹配

框架兼容性矩陣說明了振動器和相機 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內核的框架的要求。此信息意味著對要匹配信息有關獲取由設備的VINTF對象報告的內核。

匹配內核分支

各個內核分支後綴（例如， 5.4- r映射到唯一的內核FCM版本（例如，5）。該映射與版本號（例如，R）和 FCM 版本（例如，5）之間的映射相同。

VTS測試執行，該設備明確指定的設備清單中的內核版本FCM， /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在Android源樹。

匹配內核版本

矩陣可以包括多個<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>部分滿足這些要求，這是一個不匹配。

示例：選擇匹配的要求

考慮以下的假設情況下在的FCM /system/etc/vintf聲明下述條件（頁眉和頁腳標記省略）：

<!-- 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 (右) 4.14.105 4.14-r
4 (Q) 5 (右) 5.4.41 5.4-r
5 (右)未指明任何VTS 失敗（必須為目標 FCM 版本 5 指定內核 FCM 版本）
5 (右) 4 (Q)任何VTS 失敗（內核 FCM 版本 < 目標 FCM 版本）
5 (右) 5 (右) 4.14.180 4.14-r

匹配內核配置

如果<kernel>部確實匹配，則過程繼續通過試圖匹配config針對元素/proc/config.gz 。對於在兼容性矩陣中的每個config元素，它查找/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()報告：

  • 84年9月4日（沒有匹配到矩陣除非有與單獨的內核部<kernel version="4.9.x"> ，其中x <= 84 ）
  • 41年4月14日（沒有匹配到矩陣，小於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>定義次要版本為每一個主版本的閉合範圍。設備報告的 sepolicy 版本必須屬於這些範圍之一才能與框架兼容。匹配規則類似於 HAL 版本；如果 sepolicy 版本高於或等於範圍的最低版本，則匹配。最大版本純粹是信息性的。
  • <kernel-sepolicy-version>即policydb版本。必須小於所述security_policyvers()由裝置報告。

示例：成功的 SE 策略匹配

框架兼容性矩陣說明以下 sepolicy 信息：

<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-∞ 之一。否則就不是一場比賽。 （其中“ -3 ”之後“ 26.0 ”是純粹的信息。）

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 元數據（並返回 OK）時出現。如果發生驗證失敗（或根本沒有發生驗證），則不存在。

兼容性匹配比較以下內容：

  • 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庫，每一個不同的主版本升級設備和發射裝置。在這種情況下，相同的無符號的系統的圖像可以被共享，但最終的簽名系統圖像不同（具有不同avb.vbmeta-version ）：

圖1. AVB版本匹配（ /system是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 版本相匹配。如果在OTA過程中AVB版本有大版本升級（例如從0.0升級到1.0），OTA中的VINTF兼容性檢查不反映OTA後的兼容性。

為了緩解這一問題，OEM可以放置在OTA包假AVB版本（ 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中使用）
  • system_matrix.xml在compatibility.zip在OTA包

這些變化不會影響其他的框架兼容性矩陣，包括/system/etc/vintf/compatibility_matrix.xml 。所述OTA後，在新的值/system/etc/vintf/compatibility_matrix.xml用於兼容性檢查代替。

VNDK 版本匹配

所述裝置兼容性矩陣聲明在所需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版本匹配

所述裝置兼容性矩陣聲明一組所需的系統SDK版本compatibility-matrix.system-sdk.version 。這裡只有如果設定是在宣布提供系統SDK版本的一個子集匹配manifest.system-sdk.version框架中的清單。

  • 作為一種特殊情況，如果設備兼容性矩陣中沒有枚舉 System SDK 版本，則始終將其視為匹配項，因為空集是任何集的子集。

示例：成功的系統 SDK 版本匹配

如果設備兼容性矩陣說明了對 System SDK 的以下要求：

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

然後，框架必須提供系統 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>

示例 C 不匹配，因為未提供系統 SDK 版本 27。