Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Trang này được dịch bởi Cloud Translation API.

Quy tắc so khớp

Hai cặp ma trận và tệp kê khai tương thích được dành cho để xác minh rằng khung và cách triển khai của nhà cung cấp có thể kết hợp với nhau. Xác minh này đã thực hiện thành công khi khớp giữa ma trận tương thích khung và tệp kê khai trên thiết bị, cũng như giữa tệp kê khai khung và thiết bị ma trận tương thích.

Việc xác minh này được thực hiện trong thời gian xây dựng, ở bản cập nhật OTA thời gian tạo gói, tại thời điểm khởi động và trong các bài kiểm thử khả năng tương thích VTS.

Các phần sau đây trình bày chi tiết về các quy tắc so khớp được sử dụng bởi thành phần khác nhau.

Khớp phiên bản ma trận tương thích khung

Để khớp tệp kê khai thiết bị với ma trận tương thích khung, phiên bản FCM vận chuyển do manifest.target-level chỉ định phải hoàn toàn bằng với phiên bản FCM được chỉ định bởi compatibility-matrix.level Nếu không, sẽ không có kết quả nào phù hợp.

Khi yêu cầu ma trận về khả năng tương thích khung bằng libvintf, kết quả trùng khớp này sẽ luôn thành công vì libvintf mở tệp kê khai thiết bị, truy xuất Thông tin vận chuyển Phiên bản FCM và trả về ma trận tương thích khung tại Phiên bản FCM vận chuyển đó (cộng thêm một số HAL không bắt buộc từ ma trận tương thích ở các phiên bản FCM cao hơn).

Đối sánh HAL

Quy tắc so khớp HAL xác định phiên bản của các phần tử hal trong một được coi là được hỗ trợ bởi chủ sở hữu của ma trận tương thích.

HIDL và HAL gốc

Dưới đây là quy tắc khớp đối với HIDL và HAL gốc.

Nhiều phần tử <hal> được đánh giá bằng một hàm AND mối quan hệ.
Các phần tử <hal> có thể có <hal optional="true"> để đánh dấu là là không bắt buộc.
Nhiều phần tử <version> trong cùng một phần tử <hal> có Mối quan hệ HOẶC. Nếu từ 2 trở lên được chỉ định, chỉ một trong các phiên bản cần được triển khai. (Xem ví dụ về DRM bên dưới.)
Nhiều <instance> và <regex-instance> phần tử trong cùng <hal> được đánh giá bằng một mối quan hệ AND duy nhất khi Bạn phải nhập <hal>. (Hãy xem <ahref="#drm">ví dụ về DRM bên dưới.)</ahref="#drm">

Ví dụ: Kết hợp HAL thành công cho một mô-đun

Đối với HAL ở phiên bản 2.5, quy tắc khớp như sau:

Ma trận Tệp kê khai trùng khớp

2.5 2,5-2,∞. Trong ma trận tương thích, 2.5 là viết tắt của 2.5-5

Ma trận	Tệp kê khai trùng khớp
`2.5`	2,5-2,∞. Trong ma trận tương thích, `2.5` là viết tắt của `2.5-5`
`2.5-7`	2,5-2,∞. Cho biết những điều sau: 2.5 là phiên bản tối thiểu bắt buộc, nghĩa là tệp kê khai cung cấp HAL 2.0-2.4 là không tương thích. 2.7 là phiên bản tối đa có thể được yêu cầu, nghĩa là chủ sở hữu của ma trận tương thích (khung hoặc thiết bị) sẽ không yêu cầu các phiên bản vượt quá 2,7. Chủ sở hữu của tệp kê khai phù hợp vẫn có thể phân phát phiên bản 2.10 (ví dụ) khi 2.7 được yêu cầu. Chủ sở hữu ma trận tương thích biết chỉ cho biết dịch vụ được yêu cầu tương thích với API phiên bản 2.7. -7 chỉ mang tính chất cung cấp thông tin và không ảnh hưởng đến quá trình cập nhật OTA. Do đó, một thiết bị có HAL ở phiên bản 2.10 trong tệp kê khai vẫn còn tương thích với một khung nêu rõ `2.5-7` trong ma trận tương thích.

2.5-7

2,5-2,∞. Cho biết những điều sau:

2.5 là phiên bản tối thiểu bắt buộc, nghĩa là tệp kê khai cung cấp HAL 2.0-2.4 là không tương thích.
2.7 là phiên bản tối đa có thể được yêu cầu, nghĩa là chủ sở hữu của ma trận tương thích (khung hoặc thiết bị) sẽ không yêu cầu các phiên bản vượt quá 2,7. Chủ sở hữu của tệp kê khai phù hợp vẫn có thể phân phát phiên bản 2.10 (ví dụ) khi 2.7 được yêu cầu. Chủ sở hữu ma trận tương thích biết chỉ cho biết dịch vụ được yêu cầu tương thích với API phiên bản 2.7.
-7 chỉ mang tính chất cung cấp thông tin và không ảnh hưởng đến quá trình cập nhật OTA.

Do đó, một thiết bị có HAL ở phiên bản 2.10 trong tệp kê khai vẫn còn tương thích với một khung nêu rõ 2.5-7 trong ma trận tương thích.

Ví dụ: Kết quả HAL (Lớp trừu tượng phần cứng) thành công cho mô-đun DRM

Ma trận tương thích khung cho biết thông tin sau đây về phiên bản dành cho HAL DRM:

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

Nhà cung cấp phải triển khai MỘT trong các trường hợp sau; hoặc

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

HOẶC

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

VÀ cũng phải triển khai tất cả các trường hợp sau:

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

HAL (Lớp trừu tượng phần cứng) cho AIDL

Tất cả phiên bản Android sau Android 11 (ngoại trừ Android) 11) hỗ trợ các phiên bản cho HAL AIDL trong VINTF. Quy tắc khớp cho HAL AIDL tương tự như quy tắc của HIDL và HAL gốc, ngoại trừ không có phiên bản lớn và chỉ có chính xác một phiên bản cho mỗi phiên bản HAL (1 nếu chưa xác định phiên bản).

Nhiều phần tử <hal> được đánh giá bằng một hàm AND mối quan hệ.
Các phần tử <hal> có thể có <hal optional="true"> để đánh dấu là là không bắt buộc.
Nhiều <instance> và <regex-instance> phần tử trong cùng <hal> được đánh giá bằng một mối quan hệ AND duy nhất khi Bạn phải nhập <hal>. (Hãy xem <ahref="#vibrator">ví dụ về trình rung bên dưới.)</ahref="#vibrator">

Ví dụ: Kết hợp HAL thành công cho một mô-đun

Đối với HAL ở phiên bản 5, quy tắc so khớp như sau:

Ma trận Tệp kê khai trùng khớp

5 5 – ∞. Trong ma trận tương thích, 5 là viết tắt của 5-5

Ma trận	Tệp kê khai trùng khớp
`5`	5 – ∞. Trong ma trận tương thích, `5` là viết tắt của `5-5`
`5-7`	5 – ∞. Cho biết những điều sau: 5 là phiên bản tối thiểu bắt buộc, nghĩa là tệp kê khai cung cấp HAL 1-4 không tương thích. 7 là phiên bản tối đa có thể được yêu cầu, nghĩa là chủ sở hữu của ma trận tương thích (khung hoặc thiết bị) sẽ không yêu cầu các phiên bản trên 7 tuổi. Chủ sở hữu của tệp kê khai phù hợp vẫn có thể phân phát phiên bản 10 (ví dụ) khi 7 được yêu cầu. Chủ sở hữu ma trận tương thích biết chỉ cho biết dịch vụ được yêu cầu tương thích với API phiên bản 7. -7 chỉ mang tính chất cung cấp thông tin và không ảnh hưởng đến quá trình cập nhật OTA. Do đó, một thiết bị có HAL ở phiên bản 10 trong tệp kê khai vẫn còn tương thích với một khung nêu rõ `5-7` trong ma trận tương thích.

5-7

5 – ∞. Cho biết những điều sau:

5 là phiên bản tối thiểu bắt buộc, nghĩa là tệp kê khai cung cấp HAL 1-4 không tương thích.
7 là phiên bản tối đa có thể được yêu cầu, nghĩa là chủ sở hữu của ma trận tương thích (khung hoặc thiết bị) sẽ không yêu cầu các phiên bản trên 7 tuổi. Chủ sở hữu của tệp kê khai phù hợp vẫn có thể phân phát phiên bản 10 (ví dụ) khi 7 được yêu cầu. Chủ sở hữu ma trận tương thích biết chỉ cho biết dịch vụ được yêu cầu tương thích với API phiên bản 7.
-7 chỉ mang tính chất cung cấp thông tin và không ảnh hưởng đến quá trình cập nhật OTA.

Do đó, một thiết bị có HAL ở phiên bản 10 trong tệp kê khai vẫn còn tương thích với một khung nêu rõ 5-7 trong ma trận tương thích.

Ví dụ: Kết quả HAL (Lớp trừu tượng phần cứng) thành công cho nhiều mô-đun

Ma trận tương thích khung cho biết thông tin sau đây về phiên bản cho HAL bộ rung và máy ảnh:

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

Nhà cung cấp phải triển khai tất cả các phiên bản sau:

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

So khớp kernel

Phần <kernel> của ma trận tương thích khung mô tả các yêu cầu của khung của nhân Linux trên thiết bị. Chiến dịch này thông tin được so khớp với thông tin về nhân được đối tượng VINTF của thiết bị báo cáo.

So khớp các nhánh nhân

Mỗi hậu tố nhánh của hạt nhân (ví dụ: 5.4-r) được liên kết tới một hậu tố duy nhất phiên bản FCM hạt nhân (ví dụ: 5). Việc liên kết giống như việc ánh xạ giữa các chữ cái phát hành (ví dụ: phiên bản R) và FCM (ví dụ: 5).

Kiểm thử VTS thực thi việc thiết bị chỉ định rõ ràng phiên bản FCM của nhân trong tệp kê khai thiết bị, /vendor/etc/vintf/manifest.xml, nếu một trong các điều sau là đúng:

Phiên bản FCM hạt nhân khác với phiên bản FCM mục tiêu. Ví dụ: thiết bị nói trên có phiên bản FCM mục tiêu 4 và phiên bản FCM hạt nhân của nó là 5 (nhân hệ điều hành) hậu tố nhánh r).
Phiên bản FCM hạt nhân lớn hơn hoặc bằng 5 (hậu tố nhánh hạt nhân r).

Lưu ý: Nếu phiên bản FCM hạt nhân bằng phiên bản FCM mục tiêu và chúng lớn hơn hoặc bằng 5, tệp nguồn của tệp kê khai thiết bị do DEVICE_MANIFEST_FILE chỉ định không có để chỉ định phiên bản FCM hạt nhân. assemble_vintf tự động suy luận phiên bản FCM hạt nhân từ phiên bản FCM mục tiêu nếu phiên bản FCM mục tiêu lớn hơn hoặc bằng 5 điểm.

Hoạt động kiểm thử VTS thực thi việc, nếu phiên bản FCM hạt nhân được chỉ định, phiên bản FCM hạt nhân sẽ lớn hơn hoặc bằng phiên bản FCM mục tiêu trong tệp kê khai thiết bị.

Ví dụ: Xác định nhánh kernel

Nếu thiết bị có mục tiêu FCM phiên bản 4 (được phát hành trong Android 10), nhưng chạy nhân hệ điều hành từ nhánh 4.19-r, thì tệp kê khai thiết bị phải chỉ định như sau:

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

Đối tượng VINTF kiểm tra khả năng tương thích của hạt nhân theo các yêu cầu trên nhân 4.19-r nhánh được chỉ định trong FCM phiên bản 5. Các yêu cầu này được xây dựng từ kernel/configs/r/android-4.19 trong cây nguồn Android.

Ví dụ: Xác định nhánh nhân cho GKI

Nếu thiết bị sử dụng Hình ảnh hạt nhân chung (GKI) và chuỗi phát hành hạt nhân từ /proc/version như sau:

5.4.42-android12-0-00544-ged21d463f856

Sau đó, đối tượng VINTF lấy bản phát hành Android từ bản phát hành nhân và sử dụng bản phát hành đó để xác định phiên bản FCM kernel. Trong ví dụ này, android12 có nghĩa là FCM hạt nhân phiên bản 6 (đã phát hành trong Android 12).

Để biết thông tin chi tiết về cách phân tích cú pháp chuỗi phát hành hạt nhân, hãy xem Tạo phiên bản GKI.

Khớp các phiên bản kernel

Một ma trận có thể bao gồm nhiều phần <kernel>, mỗi phần có một thuộc tính version khác sử dụng định dạng:

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

Đối tượng VINTF chỉ xem xét phần <kernel> trong FCM với phiên bản FCM phù hợp với cùng một ${ver} và ${major_rev} làm nhân của thiết bị (tức là version="${ver}.${major_rev}.${matrix_minor_rev}"); các mục khác sẽ bị bỏ qua. Ngoài ra, bản sửa đổi nhỏ từ nhân phải là một giá trị từ ma trận tương thích (${kernel_minor_rev} >= ${matrix_minor_rev};). Nếu không có mục <kernel> nào phù hợp các yêu cầu này không phù hợp.

Ví dụ: Chọn các yêu cầu để so khớp

Hãy xem xét trường hợp giả định sau, trong đó FCM trong /system/etc/vintf khai báo các yêu cầu sau (thẻ đầu trang và chân trang bị bỏ qua):

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

Phiên bản FCM mục tiêu, phiên bản FCM hạt nhân và phiên bản hạt nhân cùng chọn nhân các yêu cầu mà FCM đưa ra:

Phiên bản FCM mục tiêu	Phiên bản FCM kernel	Phiên bản Kernel	So khớp với
3 (Bàn thắng phạt đền)	chưa chỉ định	`4.4.106`	Không khớp (phiên bản nhỏ không khớp)
3 (Bàn thắng phạt đền)	chưa chỉ định	`4.4.107`	`4.4-p`
3 (Bàn thắng phạt đền)	chưa chỉ định	`4.19.42`	`4.19-q` (xem ghi chú bên dưới)
3 (Bàn thắng phạt đền)	chưa chỉ định	`5.4.41`	`5.4-r` (xem ghi chú bên dưới)
3 (Bàn thắng phạt đền)	3 (Bàn thắng phạt đền)	`4.4.107`	`4.4-p`
3 (Bàn thắng phạt đền)	3 (Bàn thắng phạt đền)	`4.19.42`	Không khớp (không có nhánh nhân `4.19-p`)
3 (Bàn thắng phạt đền)	4 (Q)	`4.19.42`	`4.19-q`
4 (Q)	chưa chỉ định	`4.4.107`	Không khớp (không có nhánh nhân `4.4-q`)
4 (Q)	chưa chỉ định	`4.9.165`	`4.9-q`
4 (Q)	chưa chỉ định	`5.4.41`	`5.4-r` (xem ghi chú bên dưới)
4 (Q)	4 (Q)	`4.9.165`	`4.9-q`
4 (Q)	4 (Q)	`5.4.41`	Không khớp (không có nhánh nhân `5.4-q`)
4 (Q)	5 (phải)	`4.14.105`	`4.14-r`
4 (Q)	5 (phải)	`5.4.41`	`5.4-r`
5 (phải)	chưa chỉ định	bất kỳ	VTS không thành công (Phải chỉ định phiên bản FCM hạt nhân cho FCM mục tiêu phiên bản 5)
5 (phải)	4 (Q)	bất kỳ	VTS không thành công (phiên bản FCM hạt nhân < phiên bản FCM mục tiêu)
5 (phải)	5 (phải)	`4.14.180`	`4.14-r`

Lưu ý: Đối với các thiết bị có phiên bản FCM mục tiêu thấp hơn 5 (R) và một phiên bản FCM hạt nhân không xác định, Đối tượng VINTF chọn nhánh hạt nhân có hậu tố thấp nhất lớn hơn FCM mục tiêu có phiên bản kernel phù hợp. Trong ví dụ trên, thiết bị có phiên bản FCM mục tiêu của 3 (P) hãy sử dụng nhánh hạt nhân 4.19-q vì 4.19-q có hậu tố thấp nhất trong số tất cả 4.19-* nhánh hạt nhân, [4.19-q, 4.19-r, 4.19-s]. Chiến dịch này không được phép thực hiện hành vi lựa chọn yêu cầu đối với các thiết bị có phiên bản FCM mục tiêu là 5 (R) hoặc cao hơn, vì phiên bản FCM kernel phải đã chỉ định.

So khớp cấu hình nhân hệ điều hành

Nếu phần <kernel> khớp, quá trình này sẽ tiếp tục bằng cách cố gắng khớp các phần tử config với /proc/config.gz. Đối với mỗi phần tử cấu hình trong khả năng tương thích ma trận, hệ thống sẽ tra cứu /proc/config.gz để xem liệu cấu hình có hiện tại. Khi một mục cấu hình được đặt thành n trong khả năng tương thích không có ma trận nào cho phần <kernel> phù hợp từ /proc/config.gz. Cuối cùng, một mục cấu hình không có trong ma trận tương thích có thể có hoặc không có trong /proc/config.gz.

Ví dụ: So khớp cấu hình nhân hệ điều hành

<value type="string">bar</value> kết quả phù hợp "bar" Dấu ngoặc kép bị bỏ qua trong ma trận tương thích nhưng vẫn xuất hiện trong /proc/config.gz.
<value type="int">4096</value> kết quả phù hợp 4096, 0x1000 hoặc 0X1000.
<value type="int">0x1000</value> kết quả phù hợp 4096, 0x1000 hoặc 0X1000.
<value type="int">0X1000</value> kết quả phù hợp 4096, 0x1000 hoặc 0X1000.
<value type="tristate">y</value> kết quả phù hợp y
<value type="tristate">m</value> kết quả phù hợp m
<value type="tristate">n</value> có nghĩa là cấu hình mục KHÔNG được tồn tại trong /proc/config.gz.
<value type="range">1-0x3</value> kết quả phù hợp 1, 2 hoặc 3 hoặc giá trị thập lục phân tương đương.

Ví dụ: Kết quả phù hợp với nhân hệ điều hành

Ma trận tương thích khung với FCM phiên bản 1 có thông tin hạt nhân sau:

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

Nhánh nhân hệ điều hành được so khớp trước. Nhánh nhân hệ điều hành được chỉ định trong tệp kê khai thiết bị trong manifest.kernel.target-level, mặc định là manifest.level nếu dữ liệu đầu ra không được xác định. Nếu nhánh nhân hệ điều hành trong tệp kê khai thiết bị:

là 1, chuyển sang bước tiếp theo và kiểm tra phiên bản kernel.
là 2, không khớp với ma trận. Đối tượng VINTF đọc yêu cầu hạt nhân từ ma trận tại Thay vào đó, FCM phiên bản 2.

Sau đó, phiên bản kernel sẽ được so khớp. Nếu một thiết bị trong uname() báo cáo:

4.9.84 (không khớp với ma trận trừ phi có phần hạt nhân riêng biệt với <kernel version="4.9.x">, trong đó x <= 84)
4.14.41 (không khớp với ma trận, nhỏ hơn version)
4.14.42 (khớp với ma trận)
4.14.43 (khớp với ma trận)
4.1.22 (không khớp với ma trận trừ khi có phần nhân riêng biệt với <kernel version="4.1.x">, trong đó x <= 22)

Sau khi bạn chọn phần <kernel> thích hợp, đối với mỗi mục <config> có giá trị khác n, chúng ta sẽ mong muốn mục nhập tương ứng sẽ xuất hiện trong /proc/config.gz; cho mỗi mục <config> có giá trị n, chúng tôi dự kiến mục nhập tương ứng không có trong /proc/config.gz. T4 mong đợi nội dung của <value> khớp chính xác với văn bản sau dấu bằng (kể cả dấu ngoặc kép), cho tới ký tự dòng mới hoặc #, có khoảng trắng ở đầu và ở cuối bị cắt bớt.

Cấu hình nhân sau đây là một ví dụ về việc so khớp thành công:

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

Cấu hình hạt nhân sau đây là một ví dụ về trường hợp trùng khớp không thành công:

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

So khớp chính sách SE

Chính sách SE yêu cầu các kết quả khớp sau:

<sepolicy-version> xác định một phạm vi khép kín của các phần tử nhỏ cho mọi phiên bản chính. Phiên bản sepolicy do thiết bị báo cáo phải nằm trong một trong các phạm vi này để tương thích với khung. Trùng khớp quy tắc tương tự như các phiên bản HAL; kết quả là khớp nếu phiên bản sepolicy là cao hơn hoặc bằng phiên bản tối thiểu cho phạm vi. Phiên bản tối đa là chỉ để cung cấp thông tin.
<kernel-sepolicy-version>, tức là phiên bản policydb. Phải nhỏ hơn security_policyvers() mà thiết bị báo cáo.

Ví dụ: So khớp chính sách SE thành công

Ma trận tương thích khung cho biết những thông tin chính sách sau:

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

Trên thiết bị:

Giá trị mà security_policyvers() trả về phải lớn hơn không quá 30. Nếu không, kết quả sẽ không khớp. Ví dụ:
- Nếu thiết bị trả về 29 giá trị, thì thiết bị đó không khớp.
- Nếu thiết bị trả về giá trị 31, thì kết quả trùng khớp.
Phiên bản chính sách SE phải là một trong hai giá trị 25.0-∞ hoặc 26.0-∞. Nếu không, đó không phải là khớp. ("-3" sau "26.0" hoàn toàn là cung cấp thông tin.)

Phiên bản AVB trùng khớp

Phiên bản AVB chứa một phiên bản CHÍNH và một phiên bản MINOR, cùng định dạng là MAJOR.MINOR (ví dụ: 1.0, 2.1). Để biết thông tin chi tiết, hãy tham khảo Tạo phiên bản và Khả năng tương thích. Phiên bản AVB có các thuộc tính hệ thống sau đây:

ro.boot.vbmeta.avb_version là phiên bản libavb trong trình tải khởi động
ro.boot.avb_version là phiên bản libavb trong Hệ điều hành Android (init/fs_mgr)

Thuộc tính hệ thống chỉ xuất hiện khi libavb tương ứng đã được sử dụng để xác minh siêu dữ liệu AVB (và trả về kết quả OK). Không có thông báo nếu xác minh không thành công (hoặc không có xác minh nào xảy ra).

Kết quả so khớp khả năng tương thích so sánh những thông tin sau:

sysprop ro.boot.vbmeta.avb_version với avb.vbmeta-version từ ma trận tương thích khung;
- 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 với avb.vbmeta-version từ ma trận tương thích khung.
- ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
- ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Trình tải khởi động hoặc hệ điều hành Android có thể chứa hai bản sao của libavb các thư viện, mỗi thư viện có một phiên bản MAJOR khác nhau để nâng cấp thiết bị và phát hành thiết bị. Trong trường hợp này, bạn có thể chia sẻ cùng một hình ảnh hệ thống chưa có chữ ký, nhưng hình ảnh hệ thống đã ký cuối cùng thì khác (với các hình ảnh khác nhau avb.vbmeta-version):

Hình 1. Phiên bản AVB trùng khớp (/hệ thống là P, tất cả các phân vùng khác là O).

Hình 2. Phiên bản AVB trùng khớp (tất cả các phân vùng đều P).

Ví dụ: Khớp phiên bản AVB thành công

Ma trận tương thích khung cho biết thông tin AVB sau đây:

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

Trên thiết bị:

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

So khớp phiên bản AVB trong OTA

Đối với các thiết bị chạy Android 9 trở xuống, khi cập nhật lên Android 10, AVB các yêu cầu về phiên bản trong ma trận tương thích khung với AVB hiện tại phiên bản trên thiết bị. Nếu phiên bản AVB có bản nâng cấp phiên bản lớn trong quá trình OTA (ví dụ: từ 0.0 đến 1.0), kiểm tra VINTF về khả năng tương thích trong OTA không phản ánh khả năng tương thích sau OTA.

Để giảm thiểu vấn đề này, OEM có thể đặt một phiên bản AVB giả vào gói OTA (compatibility.zip) để vượt qua quy trình kiểm tra. Cách làm như sau:

Chọn các CL sau đây vào cây nguồn Android 9:
- CL 732261
- CL 732262
Định nghĩa BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE cho thiết bị. Giá trị phải bằng với phiên bản AVB trước OTA, tức là phiên bản AVB của thiết bị trước đó đã phát hành.
Tạo lại gói OTA.

Những thay đổi này sẽ tự động đặt BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE dưới dạng compatibility-matrix.avb.vbmeta-version trong các tệp sau:

/system/compatibility_matrix.xml (không được dùng trong Android 9) trên thiết bị
system_matrix.xml trong compatibility.zip trong gói OTA

Những thay đổi này không ảnh hưởng đến các ma trận tương thích khác của khung, bao gồm /system/etc/vintf/compatibility_matrix.xml. Sau OTA, giá trị mới trong Thay vào đó, /system/etc/vintf/compatibility_matrix.xml được dùng để kiểm tra khả năng tương thích.

Phiên bản VNDK trùng khớp

Ma trận về khả năng tương thích của thiết bị khai báo phiên bản VNDK bắt buộc trong compatibility-matrix.vendor-ndk.version. Nếu thiết bị ma trận tương thích không có thẻ <vendor-ndk>, không do đó luôn được coi là kết quả phù hợp.

Nếu ma trận tương thích thiết bị có <vendor-ndk> thẻ, mục nhập <vendor-ndk> có một thẻ phù hợp <version> được tra cứu trong tập hợp ảnh chụp nhanh về các nhà cung cấp VNDK do khung này cung cấp trong tệp kê khai khung. Nếu mục nhập đó không tồn tại, không có kết quả nào phù hợp.

Nếu mục nhập như vậy tồn tại, thì tập hợp các thư viện được liệt kê trong thiết bị ma trận tương thích phải là một tập con của tập hợp các thư viện được nêu trong tệp kê khai khung; nếu không, mục nhập đó sẽ không được coi là khớp.

Trong trường hợp đặc biệt, nếu không có thư viện nào được liệt kê trong thiết bị ma trận tương thích, mục nhập luôn được coi là kết quả trùng khớp vì trống tập hợp là một tập con của một tập bất kỳ.

Ví dụ: Khớp phiên bản VNDK thành công

Nếu ma trận tương thích thiết bị nêu yêu cầu sau đây trên VNDK:

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

Trong tệp kê khai khung, chỉ mục có phiên bản 27 mới được xem xét.

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

Ví dụ A là kết quả trùng khớp vì VNDK phiên bản 27 có trong tệp kê khai khung, và {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>

Ví dụ B không khớp. Mặc dù VNDK phiên bản 27 đã có trong khung tệp kê khai, khung này không hỗ trợ libjpeg.so trong đó . VNDK phiên bản 26 sẽ bị bỏ qua.

Phiên bản SDK hệ thống trùng khớp

Ma trận về khả năng tương thích của thiết bị khai báo một tập hợp SDK hệ thống bắt buộc trong compatibility-matrix.system-sdk.version. Có một chỉ so khớp nếu tập hợp là tập con gồm các phiên bản SDK hệ thống được cung cấp như đã khai báo trong manifest.system-sdk.version trong tệp kê khai khung.

Trong trường hợp đặc biệt, nếu không có phiên bản SDK hệ thống nào được liệt kê trong thiết bị ma trận tương thích thì luôn được coi là kết quả trùng khớp vì giá trị trống tập hợp là một tập con của một tập bất kỳ.

Ví dụ: Khớp phiên bản SDK hệ thống thành công

Nếu ma trận tương thích thiết bị nêu yêu cầu sau đây về Hệ thống SDK:

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

Sau đó, khung phải cung cấp SDK hệ thống phiên bản 26 và 27 cho phù hợp.

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

Ví dụ A là kết quả trùng khớp.

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

Ví dụ B là kết quả trùng khớp.

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

Ví dụ C không khớp vì SDK hệ thống phiên bản 27 không được cung cấp.