Google致力於提高黑人社區的種族平等。 怎麼看。
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

匹配規則

這兩對兼容性矩陣和清單旨在在OTA更新時進行協調,以驗證框架和供應商實現可以相互配合。框架兼容性矩陣和設備清單之間以及框架清單和設備兼容性矩陣之間匹配時,此驗證成功。以下各節詳細介紹了各種組件使用的匹配規則。

框架兼容性列表版本匹配

要將設備清單與框架兼容性矩陣相匹配, manifest.target-level指定的Shipping FCM版本必須與compatibility-matrix.level指定的FCM版本compatibility-matrix.level 。否則沒有匹配。

當使用libvintf請求框架兼容性矩陣時,此匹配總是成功的,因為libvintf打開設備清單,檢索Shipping FCM版本,並以該Shipping FCM版本返回框架兼容性矩陣(以及來自較高FCM兼容性矩陣的一些可選HAL)版本)。

HAL比賽

HAL-match規則標識清單文件中被相應兼容性矩陣的所有者支持的hal元素的版本。

  • 多個<hal>元素使用單個AND關係進行求值。
  • 同一<hal>中的多個<version>元素具有OR關係。如果指定了兩個或多個,則僅需要實現其中一個版本。 (請參見下面的DRM示例 。)
  • 使用單個AND關係評估同一<hal>中的多個<instance><regex-instance>元素。 (請參見下面的DRM示例 。)

示例 :相機模塊的HAL成功匹配

對於2.5版的HAL,匹配規則如下:

矩陣匹配清單
2.5 2.5-2.∞。簡寫為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更新過程。
因此,清單文件中具有HAL 2.10版本的設備仍與聲明camera:的框架兼容camera:兼容性矩陣中為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

核心比賽

框架兼容性矩陣的<kernel>部分描述了設備上Linux內核的框架要求。該信息應在OTA時與設備的VINTF對象報告的有關內核的信息進行匹配。

矩陣可以包括多個<kernel>部分,每個部分使用以下格式具有不同的version屬性:

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

OTA僅考慮與設備<kernel>具有相同${ver}${major_rev}<kernel>部分(即, version="${ver}.${major_rev}.${matrix_minor_rev}") ;其他部分將被忽略。此外,內核的次要修訂版必須是兼容性矩陣中的值( ${kernel_minor_rev} >= ${matrix_minor_rev} ;)。如果沒有<kernel>部分滿足這些要求,則為不匹配。

如果<kernel>部分匹配,則嘗試通過將config元素與/proc/config.gz進行匹配來繼續該過程。對於兼容性矩陣中的每個配置元素,它都會查找/proc/config.gz以查看配置是否存在。如果在匹配的<kernel>部分的兼容性矩陣中將配置項設置為n ,則/proc/config.gz必須不存在該配置項。最後,不在兼容性矩陣中的配置項可能會出現在/proc/config.gz也可能不會出現。

匹配示例:

  • <value type="string">bar</value>匹配"bar" 。兼容性矩陣中省略了引號,但在/proc/config.gz提供了/proc/config.gz
  • <value type="int">4096</value>匹配40960x10000X1000
  • <value type="int">0x1000</value>匹配40960x10000X1000
  • <value type="int">0X1000</value>匹配40960x10000X1000
  • <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>匹配12 ,或3 ,或十六進制等效。

示例:成功的內核匹配

框架兼容性矩陣具有以下內核信息:

<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>

首先匹配內核版本。如果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>部分之後,對於每個值除n之外的<config>項,我們希望在/proc/config.gz存在相應的條目;對於每個值為n <config>項,我們希望/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版本;如果Sepolicy版本高於或等於該範圍的最低版本,則為匹配項。最高版本僅供參考。
  • <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是Android OS中的libavb版本( 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 OS可能包含libavb庫的兩個副本,每個副本都具有用於升級設備和啟動設備的不同MAJOR版本。在這種情況下,可以共享相同的未簽名系統映像,但是最終的已簽名系統映像是不同的(具有不同的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或更低版本啟動的設備,在OTA期間,框架兼容性列表中的AVB版本要求與設備上的當前AVB版本匹配。如果在OTA期間AVB版本具有主要版本升級(例如,從0.0升級到1.0),則OTA中的簽入不反映OTA之後的兼容性。

為了緩解此問題,OEM可以在OTA軟件包( compatibility.zip )中放置偽造的AVB版本以通過檢查。為此:

  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聲明了所需的VNDK版本。如果設備兼容性矩陣沒有<vendor-ndk>標記,則沒有任何要求,因此始終將其視為匹配項。

如果設備兼容性矩陣確實具有<vendor-ndk>標記,則從框架清單中框架提供的VNDK供應商快照集中查找具有匹配的<version><vendor-ndk>條目。如果不存在這樣的條目,則沒有匹配項。

如果確實存在這樣的條目,則設備兼容性矩陣中枚舉的庫集必須是框架清單中聲明的庫集的子集;否則,該條目不被視為匹配項。

  • 作為一種特殊情況,如果設備兼容性矩陣中未枚舉任何庫,則該條目始終被視為匹配項,因為空集是任何集的子集。

示例:成功匹配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不是匹配項。即使框架清單中libjpeg.so VNDK版本27,該快照中的框架也不支持libjpeg.so 。 VNDK版本26被忽略。

系統SDK版本匹配

設備兼容性列表在compatibility-matrix.system-sdk.version聲明了一組必需的系統SDK版本。僅當集合是框架清單中manifest.system-sdk.version中聲明的提供的系統SDK版本的子集時,才存在匹配項。

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

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

如果設備兼容性列表對System 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>

示例C不匹配,因為未提供System SDK版本27。