Khớp với quy tắc

Hai cặp ma trận và tệp kê khai tương thích được dùng để đối chiếu nhằm xác minh rằng việc triển khai khung và nhà cung cấp có thể hoạt động cùng nhau. Quy trình xác minh này sẽ thành công khi có sự trùng khớp giữa ma trận khả năng tương thích của khung và 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ị.

Quy trình xác minh này được thực hiện tại thời gian tạo, tại thời gian tạo gói bản cập nhật qua mạng (OTA), tại thời gian 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 các quy tắc so khớp mà nhiều thành phần sử dụng.

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

Để so khớp tệp kê khai thiết bị với ma trận tương thích của 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 do compatibility-matrix.level chỉ định. Nếu không, sẽ không có kết quả phù hợp.

Khi ma trận khả năng tương thích của 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 sẽ 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 của khung ở 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 khả năng tương thích ở các phiên bản FCM cao hơn).

HAL matches

Quy tắc HAL-match xác định các phiên bản của phần tử hal trong tệp kê khai được coi là do 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 chúng 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ệ OR. Nếu bạn chỉ định từ 2 phiên bản trở lên, thì chỉ cần triển khai một trong các phiên bản đó. (Xem HAL khớp thành công cho mô-đun DRM.)
• Nhiều phần tử <instance> và <regex-instance> trong cùng một phần tử <hal> được đánh giá bằng mối quan hệ AND duy nhất khi <hal> là bắt buộc. (Xem phần HAL khớp thành công cho mô-đun DRM.)

Ví dụ: HAL khớp thành công cho một mô-đun

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

Ví dụ: Khớp HAL thành công cho mô-đun DRM

Ma trận khả năng tương thích của khung cho biết 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 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

AND phải triển khai tất cả các trường hợp 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 AIDL

Android trở lên hỗ trợ các phiên bản cho AIDL HAL trong VINTF. Các quy tắc so khớp cho AIDL HAL 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à có chính xác một phiên bản cho mỗi phiên bản HAL (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 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ử <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 phần HAL khớp thành công cho nhiều mô-đun.)

Ví dụ: HAL khớp 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:

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

Ma trận khả năng tương thích của khung cho biết thông tin phiên bản sau đây cho HAL bộ rung và camera:

<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 trường hợp 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

Kernel matches

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 dùng để so khớp với thông tin về nhân do đối tượng VINTF của thiết bị báo cáo.

Khớp các nhánh của nhân

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

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

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

Các kiểm thử VTS thực thi rằng nếu phiên bản FCM của nhân được chỉ định, thì phiên bản FCM của nhân phải lớn hơn hoặc bằng phiên bản FCM đích trong tệp kê khai thiết bị.

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

Nếu thiết bị có FCM phiên bản 4 (phát hành trong Android 10) làm mục tiêu, nhưng chạy nhân từ nhánh 4.19-r, thì tệp kê khai thiết bị phải chỉ định những nội dung 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 nhân dựa trên các yêu cầu đối với nhánh nhân 4.19-r, đượ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 kernel 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 là 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 kernel và dùng bản phát hành này để xác định phiên bản FCM của kernel. Trong ví dụ này, android12 có nghĩa là FCM phiên bản 6 của nhân (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 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 riêng bằng cách 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 có phiên bản FCM khớp với cùng ${ver} và ${major_rev} như 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ỏ của nhân phải là một giá trị trong 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ẻ tiêu đề 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 đích, phiên bản FCM của nhân và phiên bản nhân cùng nhau chọn các yêu cầu về nhân từ FCM:

Đối sánh cấu hình kernel

Nếu phần <kernel> khớp, quy trình 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, nó sẽ tra cứu /proc/config.gz để xem cấu hình có xuất hiện hay không. 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 có trong ma trận tương thích có thể xuất hiện hoặc không xuất hiện trong /proc/config.gz.

Ví dụ: Cấu hình khớp với nhân

• <value type="string">bar</value>trùng khớp "bar". Dấu ngoặc kép bị bỏ qua trong ma trận tương thích nhưng lại xuất hiện trong /proc/config.gz.
• <value type="int">4096</value> khớp với 4096, 0x1000 hoặc 0X1000.
• <value type="int">0x1000</value> khớp với 4096, 0x1000 hoặc 0X1000.
• <value type="int">0X1000</value> khớp với 4096, 0x1000 hoặc 0X1000.
• <value type="tristate">y</value>trùng khớp y.
• <value type="tristate">m</value>trùng khớp 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 thập lục phân.

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

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

<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 kernel sẽ được so khớp trước. Nhánh kernel được chỉ định trong tệp kê khai thiết bị trong manifest.kernel.target-level, theo mặc định là manifest.level nếu bạn không chỉ định nhánh trước:

• Nếu nhánh kernel trong tệp kê khai thiết bị là 1, thì quy trình sẽ chuyển sang bước tiếp theo và kiểm tra phiên bản kernel.
• Nếu nhánh kernel trong tệp kê khai thiết bị là 2, thì không có nhánh nào khớp với ma trận. Các đối tượng VINTF đọc các yêu cầu về nhân từ ma trận ở 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 mạng lưới uname() báo cáo:

• 4.9.84 (không khớp với ma trận trừ phi có một phần nhân riêng biệt có <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 (so khớp với ma trận)
• 4.1.22 (không khớp với ma trận trừ phi có một phần nhân riêng biệt có <kernel version="4.1.x">, trong đó x <= 22)

Sau khi bạn chọn mục <kernel> thích hợp, đối với mỗi mục <config> có giá trị khác với n, mục tương ứng phải có trong /proc/config.gz; đối với mỗi mục <config> có giá trị n, mục tương ứng không được có trong /proc/config.gz. Nội dung của <value> phải 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 kernel sau đây là một ví dụ về trường hợp 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 không khớp:

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

SEPolicy matches

SEPolicy yêu cầu các kết quả trùng khớp sau:

• <sepolicy-version> xác định một phạm vi khép kín của các phiên bản phụ 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 dải sau đây để tương thích với khung. Các quy tắc so khớp tương tự như các phiên bản HAL; đó là một kết quả khớp nếu phiên bản SEPolicy 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 chỉ mang tính chất thông tin.
• <kernel-sepolicy-version>, tức là phiên bản Policy DB, phải nhỏ hơn security_policyvers() do thiết bị báo cáo.

Ví dụ: Kết quả khớp SEPolicy thành công

Ma trận khả năng tương thích của khung cho biết thông tin sau về SEPolicy:

<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à một kết quả khớp. Ví dụ:
  • Nếu một thiết bị trả về 29, tức là 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 SEPolicy phải là một trong các phiên bản 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.)

Kết quả khớp phiên bản AVB

Phiên bản AVB chứa phiên bản CHÍNH và phiên bản PHỤ, 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 này 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). Tham số này sẽ không xuất hiện nếu xảy ra lỗi xác minh (hoặc không có quy trình xác minh nào diễn ra).

Một kết quả so khớp về khả năng tương thích sẽ so sánh những yếu tố sau:

• sysprop ro.boot.vbmeta.avb_version có avb.vbmeta-version trong ma trận 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 có avb.vbmeta-version trong ma trận tương thích của 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 CHÍNH khác nhau cho các thiết bị nâng cấp và thiết bị khởi chạy. 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 hình ảnh hệ thống đã ký cuối cùng sẽ khác nhau (với avb.vbmeta-version khác nhau):

Hình 1. Phiên bản AVB khớp (/system 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 thành công phiên bản AVB

Ma trận khả năng tương thích của khung cho biết thông tin sau về AVB:

<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ị ra mắt cùng 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 của 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 chính trong quá trình cập nhật qua mạng (ví dụ: từ 0.0 lên 1.0), thì chế độ kiểm tra VINTF để đảm bảo khả năng tương thích trong quá trình cập nhật qua mạng sẽ không phản ánh khả năng tương thích sau khi cập nhật qua mạng.

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

1. Chọn lọc các CL sau vào cây nguồn Android 9:
   • CL 732261
   • CL 732262
2. Xác định BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE cho thiết bị. Giá trị của thuộc tính này phải bằng phiên bản AVB trước khi cập nhật qua mạng (OTA), tức là phiên bản AVB của thiết bị khi thiết bị được ra mắt.
3. Tạo lại gói OTA.

Những thay đổi này sẽ tự động đặt BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE làm 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 trùng khớp

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

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

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

Nếu ma trận khả năng tương thích của thiết bị nêu ra yêu cầu sau đây đối với 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ả trùng khớp, vì VNDK phiên bản 27 nằm 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 libjpeg.so không được khung hỗ trợ trong ảnh chụp nhanh đó. 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 khả năng tương thích của 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ả trùng 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 của thiết bị, thì phiên bản đó luôn được coi là phù hợp, vì tập hợp trống là một tập hợp con của mọi tập hợp.

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

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

<!-- 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 có phiên bản SDK hệ thống 27.