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.

Khớp với quy tắc

Hai cặp ma trận tương thích và tệp kê khai cần được điều chỉnh để xác minh rằng khung và cách triển khai của nhà cung cấp có thể hoạt động với nhau. Quá trình xác minh này sẽ thành công khi ma trận khả năng tương thích của khung khớp với tệp kê khai thiết bị, cũng như giữa tệp kê khai khung và ma trận khả năng tương thích của thiết bị.

Quá trình xác minh này được thực hiện tại thời điểm tạo bản dựng, tại thời điểm tạo gói cập nhật OTA, 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 với VTS.

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

Phiên bản khớp với ma trận tương thích khung

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

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

Kết quả trùng khớp với HAL

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

HIDL và HAL gốc

Sau đây là các quy tắc so khớp cho HIDL và HAL gốc.

Nhiều phần tử <hal> được đánh giá bằng một mối quan hệ AND duy nhất.
Các phần tử <hal> có thể có <hal optional="true"> để đánh dấu là không bắt buộc.
Nhiều phần tử <version> trong cùng một <hal> có mối quan hệ OR. Nếu bạn chỉ định hai phiên bản trở lên, thì chỉ cần triển khai một trong các phiên bản đó. (Xem ví dụ về DRM bên dưới.)
Nhiều phần tử <instance> và <regex-instance> trong cùng một <hal> được đánh giá bằng một mối quan hệ AND duy nhất khi bắt buộc phải có <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 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 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 tệp kê khai phù hợp vẫn có thể phân phát phiên bản 2.10 (ví dụ) khi có yêu cầu về phiên bản 2.7. Chủ sở hữu ma trận tương thích chỉ biết rằng 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 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 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 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 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 tệp kê khai phù hợp vẫn có thể phân phát phiên bản 2.10 (ví dụ) khi có yêu cầu về phiên bản 2.7. Chủ sở hữu ma trận tương thích chỉ biết rằng 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 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 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 nêu thông tin phiên bản sau đây cho 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>

Nhà cung cấp phải triển khai MỘT trong các thực thể sau;

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 thực thể này:

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ả các phiên bản Android sau Android 11 (ngoại trừ Android 11) đều hỗ trợ các phiên bản cho HAL AIDL trong VINTF. Quy tắc so khớp cho các HAL AIDL tương tự như các quy tắc của HIDL và HAL gốc, ngoại trừ việc không có phiên bản chính và mỗi phiên bản HAL có đúng một phiên bản (1 nếu phiên bản không được chỉ định).

Nhiều phần tử <hal> được đánh giá bằng một mối quan hệ AND.
Các phần tử <hal> có thể có <hal optional="true"> để đánh dấu là không bắt buộc.
Nhiều phần tử <instance> và <regex-instance> trong cùng một <hal> được đánh giá bằng một mối quan hệ AND duy nhất khi <hal> là bắt buộc. (Xem <ahref="#vibrator">ví dụ về máy 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 nội dung 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 sẽ không tương thích. 7 là phiên bản tối đa có thể 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á 7. Chủ sở hữu tệp kê khai phù hợp vẫn có thể phân phát phiên bản 10 (ví dụ) khi phiên bản 7 được yêu cầu. Chủ sở hữu ma trận tương thích chỉ biết rằng 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 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 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 nội dung 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 sẽ không tương thích.
7 là phiên bản tối đa có thể 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á 7. Chủ sở hữu tệp kê khai phù hợp vẫn có thể phân phát phiên bản 10 (ví dụ) khi phiên bản 7 được yêu cầu. Chủ sở hữu ma trận tương thích chỉ biết rằng 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 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 tương thích với một khung nêu rõ 5-7 trong ma trận tương thích.

Ví dụ: So khớp thành công HAL cho nhiều mô-đun

Ma trận tương thích khung cho biết thông tin phiên bản sau đây 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 thực thể này:

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

Khớp hạt nhân

Mục <kernel> của ma trận khả năng tương thích của khung mô tả các yêu cầu của khung đối với nhân Linux trên thiết bị. Thông tin này được so khớp với thông tin về hạt nhân do đố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 hạt nhân (ví dụ: 5.4-r) được liên kết với một phiên bản FCM hạt nhân duy nhất (ví dụ: 5). Việc liên kết này giống như việc liên kết giữa các chữ cái phát hành (ví dụ: R) và phiên bản FCM (ví dụ: 5).

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

Phiên bản FCM của 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ó FCM mục tiêu phiên bản 4 và phiên bản FCM hạt nhân của thiết bị là 5 (hậu tố nhánh hạt nhân r).
Phiên bản FCM của 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 của hạt nhân bằng phiên bản FCM mục tiêu và lớn hơn hoặc bằng 5, thì tệp nguồn của tệp kê khai thiết bị do DEVICE_MANIFEST_FILE chỉ định không cần chỉ định phiên bản FCM của 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.

Các kiểm thử VTS thực thi việc nếu phiên bản FCM của hạt nhân được chỉ định, thì phiên bản FCM của hạt nhân phải 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 nhân

Nếu thiết bị có FCM phiên bản 4 mục tiêu (phát hành trong Android 10), nhưng chạy hạt nhân từ nhánh 4.19-r, thì tệp kê khai thiết bị phải chỉ định những thông tin 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ánh hạt nhân 4.19-r được chỉ định trong FCM phiên bản 5. Các yêu cầu này được tạo từ kernel/configs/r/android-4.19 trong cây nguồn Android.

Ví dụ: Xác định nhánh hạt 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 sẽ lấy bản phát hành Android từ bản phát hành hạt nhân và sử dụng bản phát hành đó để xác định phiên bản FCM của hạt nhân. 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 phần Tạo phiên bản GKI.

So khớp 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 nhau theo định dạng:

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

Đối tượng VINTF chỉ xem xét phần <kernel> từ FCM có phiên bản FCM khớp với cùng ${ver} và ${major_rev} như hạt nhân thiết bị (tức là version="${ver}.${major_rev}.${matrix_minor_rev}"); các phần khác sẽ bị bỏ qua. Ngoài ra, bản sửa đổi nhỏ từ hạ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ó phần <kernel> nào đáp ứng các yêu cầu này, thì đó là trường hợp không khớ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 đây, 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 các yêu cầu về hạt nhân của FCM:

Phiên bản FCM mục tiêu	Phiên bản Kernel FCM	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 phụ không khớp)
3 (Bàn thắng phạt đền)	chưa chỉ định	`4.4.107`	`4.4-p`
3 (P)	chưa chỉ định	`4.19.42`	`4.19-q` (xem ghi chú bên dưới)
3 (P)	chưa chỉ định	`5.4.41`	`5.4-r` (xem ghi chú bên dưới)
3 (P)	3 (Bàn thắng phạt đền)	`4.4.107`	`4.4-p`
3 (P)	3 (P)	`4.19.42`	Không khớp (không có nhánh hạt nhân `4.19-p`)
3 (Bàn thắng phạt đền)	4 (Câu hỏi)	`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 (Câu hỏi)	chưa chỉ định	`4.9.165`	`4.9-q`
4 (Câu hỏi)	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 hạt nhân `5.4-q`)
4 (Câu hỏi)	5 (phải)	`4.14.105`	`4.14-r`
4 (Câu hỏi)	5 (R)	`5.4.41`	`5.4-r`
5 (R)	chưa chỉ định	bất kỳ	VTS không thành công (Phải chỉ định phiên bản FCM của hạt nhân cho FCM phiên bản 5 mục tiêu)
5 (R)	4 (Câu hỏi)	bất kỳ	VTS không thành công (phiên bản FCM của hạt nhân < phiên bản FCM mục tiêu)
5 (R)	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à phiên bản FCM hạt nhân không xác định, đối tượng VINTF sẽ chọn nhánh nhân có hậu tố thấp nhất lớn hơn phiên bản FCM mục tiêu có phiên bản nhân hệ điều hành phù hợp. Trong ví dụ trên, một thiết bị có phiên bản FCM mục tiêu là 3 (P) sẽ 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ả các nhánh hạt nhân 4.19-*, [4.19-q, 4.19-r, 4.19-s]. Hành vi chọn yêu cầu này không được phép đối với các thiết bị có phiên bản FCM mục tiêu là 5 (R) trở lên, vì bạn phải chỉ định phiên bản FCM của hạt nhân.

So khớp cấu hình hạt nhân

Nếu phần <kernel> khớp, quá trình này sẽ tiếp tục bằng cách cố gắng so 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 ma trận tương thích, ứng dụng sẽ tra cứu /proc/config.gz để xem cấu hình đã hiện diện hay chưa. Khi một mục cấu hình được đặt thành n trong ma trận tương thích cho phần <kernel> phù hợp, mục đó phải không có trong /proc/config.gz. Cuối cùng, một mục cấu hình không nằm trong ma trận tương thích có thể xuất hiện hoặc không có trong /proc/config.gz.

Ví dụ: So khớp cấu hình hạt nhân

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

Ví dụ: Khớp nhân thành công

Ma trận tương thích khung với FCM phiên bản 1 có thông tin về 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 được so khớp trước. Nhánh nhân được chỉ định trong tệp kê khai thiết bị trong manifest.kernel.target-level, mặc định là manifest.level nếu không chỉ định nhánh nhân. Nếu nhánh nhân hệ điều hành trong tệp kê khai thiết bị:

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

Sau đó, phiên bản hạt nhân 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 (so khớp với ma trận)
4.14.43 (so khớp với ma trận)
4.1.22 (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.1.x">, trong đó x <= 22)

Sau khi 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 dự kiến mục nhập tương ứng sẽ xuất hiện trong /proc/config.gz; đối với mỗi mục <config> có giá trị n, chúng ta dự kiến mục nhập tương ứng sẽ không xuất hiện trong /proc/config.gz. Chúng tôi dự kiến nội dung của <value> sẽ khớp chính xác với văn bản sau dấu bằng (bao gồm cả dấu ngoặc kép), cho đến ký tự dòng mới hoặc #, với khoảng trắng ở đầu và cuối bị cắt bớt.

Cấu hình hạt 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 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

Trùng khớp với chính sách của SE

Chính sách về SE yêu cầu các nội dung trùng khớp sau:

<sepolicy-version> xác định một phạm vi khép kín gồm các phiên bản nhỏ cho mọi phiên bản lớn. 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. Quy tắc so khớp tương tự như các phiên bản HAL; đây là một kết quả trùng khớp nếu phiên bản sepolicy cao hơn hoặc bằng phiên bản tối thiểu của phạm vi. Phiên bản tối đa chỉ mang tính chất thông tin.
<kernel-sepolicy-version>, tức là phiên bản policydb. Phải nhỏ hơn security_policyvers() do 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ị do security_policyvers() trả về phải lớn hơn hoặc bằng 30. Nếu không, thì đó không phải là kết quả trù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 một thiết bị trả về 31, thì đó là một 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, phiên bản này sẽ không khớp. ("-3" sau "26.0" chỉ mang tính chất 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 MAJOR và phiên bản MINOR, có đị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 phần 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:

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 dùng để xác minh siêu dữ liệu AVB (và trả về OK). Giá trị này sẽ không xuất hiện nếu quá trình xác minh không thành công (hoặc không có quá trình xác minh nào xảy ra).

Việc so khớp khả năng tương thích sẽ so sánh những thông tin sau:

sysprop ro.boot.vbmeta.avb_version với avb.vbmeta-version từ ma trận khả năng tương thích của 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 2 bản sao của thư viện libavb, mỗi bản sao có một phiên bản MAJOR khác nhau dành cho các thiết bị nâng cấp và chạy 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 ký nhưng các ảnh hệ thống đã ký cuối cùng sẽ khác (với avb.vbmeta-version khác):

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 khớp (tất cả các phân vùng đều là 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 quá trình 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, các yêu cầu về phiên bản AVB trong ma trận tương thích khung sẽ được so khớp với phiên bản AVB hiện tại 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 lên 1.0), thì việc kiểm tra khả năng tương thích của VINTF trong OTA sẽ không phản ánh khả năng tương thích sau OTA.

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

Chọn lọc các CL sau đây vào cây nguồn Android 9:
- CL 732261
- CL 732262
Xác định BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE cho thiết bị. Giá trị của giá trị này phải bằng phiên bản AVB trước OTA, tức là phiên bản AVB của thiết bị khi được khởi chạy.
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 khung khác, bao gồm cả /system/etc/vintf/compatibility_matrix.xml. Sau khi cập nhật qua mạng, giá trị mới trong /system/etc/vintf/compatibility_matrix.xml sẽ được dùng để kiểm tra khả năng tương thích.

Phiên bản VNDK khớp

Ma trận 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 ma trận tương thích với thiết bị không có thẻ <vendor-ndk>, thì sẽ không có yêu cầu nào được áp dụng và do đó, ma trận này luôn được coi là khớp.

Nếu ma trận khả năng tương thích của thiết bị có thẻ <vendor-ndk>, thì mục nhập <vendor-ndk> có <version> phù hợp sẽ được tra cứu từ tập hợp ảnh chụp nhanh của nhà cung cấp VNDK do khung cung cấp trong tệp kê khai khung. Nếu không có mục nhập như vậy, thì sẽ không có kết quả trùng khớp.

Nếu có một mục như vậy, tập hợp thư viện được liệt kê trong ma trận khả năng tương thích của thiết bị phải là một tập hợp con của tập hợp thư viện được nêu trong tệp kê khai khung; nếu không, mục đó 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 ma trận tương thích với thiết bị, thì mục nhập đó luôn được coi là khớp vì tập hợp trống là một tập hợp con của bất kỳ tập hợp nào.

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

Nếu ma trận khả năng tương thích của 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 nhập 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à một kết quả phù hợ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 tệp kê khai khung, nhưng khung này không hỗ trợ libjpeg.so trong ảnh chụp nhanh đó. VNDK phiên bản 26 bị bỏ qua.

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

Ma trận tương thích thiết bị khai báo một tập hợp phiên bản SDK hệ thống bắt buộc trong compatibility-matrix.system-sdk.version. Chỉ có kết quả khớp nếu tập hợp này là một tập hợp con của 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 ma trận tương thích với thiết bị, thì ma trận này luôn được coi là khớp vì tập hợp trống là một tập hợp con của bất kỳ tập hợp nào.

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

Nếu ma trận khả năng tương thích của thiết bị nêu yêu cầu sau đây đối với SDK hệ thống:

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

Sau đó, khung này phải cung cấp SDK hệ thống phiên bản 26 và 27 để khớp.

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

Ví dụ A là một kết quả phù hợp.

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

Ví dụ B là một kết quả phù hợp.

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

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