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.

Quy tắc phù hợp

Hai cặp ma trận và tệp kê khai tương thích được dung hòa để xác minh rằng việc triển khai khung và nhà cung cấp có thể hoạt động với nhau. Việc xác minh này thành công khi có sự phù hợp giữa ma trận tương thích khung và bảng kê khai thiết bị, cũng như giữa bảng kê khai khung và ma trận tương thích thiết bị.

Việc xác minh này được thực hiện tại thời điểm xây 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 tra khả năng tương thích VTS.

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

Phiên bản ma trận tương thích khung phù hợp

Để đối sánh 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 được chỉ định bởi manifest.target-level khai.target phải chính xác bằng phiên bản FCM được chỉ định bởi compatibility-matrix.level . Nếu không thì không có trận đấu nào.

Khi ma trận tương thích khung được yêu cầu với libvintf , kết hợ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 tương thích khung tại Phiên bản FCM Vận chuyển đó (cộng với một số HAL tùy chọn từ ma trận tương thích ở FCM cao hơn Phiên bản).

Trận đấu HAL

Quy tắc đối sánh 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 tự nhiên

Các quy tắc đối sánh cho HIDL và HAL gốc như sau.

  • 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 <hal> có mối quan hệ OR . Nếu hai hoặc nhiều hơn được chỉ định, chỉ một trong các phiên bản cần được triển khai. (Xem ví dụ DRM bên dưới.)
  • Nhiều phần tử <instance><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> được yêu cầu. (Xem Ví dụ về DRM bên dưới.)

Ví dụ: Đối sánh HAL thành công cho một mô-đun

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

Ma trận Tệp kê khai phù hợ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 bắt buộc tối thiểu, 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, có 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 (làm ví dụ) khi 2.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 2.7.
  • -7 chỉ là thông tin và không ảnh hưởng đến quá trình cập nhật OTA.
Do đó, thiết bị có HAL ở phiên bản 2.10 trong tệp kê khai của nó vẫn tương thích với khung có trạng thái 2.5-7 trong ma trận tương thích của nó.

Ví dụ: Đối sánh HAL thành công cho mô-đun DRM

Ma trận khả năng tương thích của khung công bố thông tin phiên bản sau 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; một trong hai

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

AIDL HAL

Tất cả các phiên bản Android mới hơn Android 11 (không bao gồm Android 11) đều hỗ trợ các phiên bản cho AIDL HAL trong VINTF. Quy tắc đối sánh cho AIDL HAL tương tự như 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 chúng là không bắt buộc.
  • Nhiều phần tử <instance><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> được yêu cầu. (Xem ví dụ về máy rung bên dưới.)

Ví dụ: Đối sánh HAL thành công cho một mô-đun

Đối với HAL ở phiên bản 5, quy tắc đối sánh như sau:

Ma trận Tệp kê khai phù hợp
5 5-∞. Trong ma trận tương thích, 5 là cách 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 bắt buộc tối thiểu, 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, có 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 của tệp kê khai phù hợp vẫn có thể phân phối phiên bản 10 (làm ví dụ) khi 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 phiên bản API 7.
  • -7 chỉ là thông tin và không ảnh hưởng đến quá trình cập nhật OTA.
Do đó, thiết bị có HAL ở phiên bản 10 trong tệp kê khai của nó vẫn tương thích với khung có trạng thái 5-7 trong ma trận tương thích của nó.

Ví dụ: Đối sánh HAL thành công cho nhiều mô-đun

Ma trận khả năng tương thích khung nêu thông tin phiên bản sau cho bộ rung và máy ảnh 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>

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

Kernel phù hợp

Phần <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 được đối tượng VINTF của thiết bị báo cáo.

Khớp các nhánh hạt nhân

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

Kiểm tra VTS thực thi rằng thiết bị chỉ định rõ ràng phiên bản FCM 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 là đúng:

  • Phiên bản FCM hạt nhân khác với phiên bản FCM đích. Ví dụ, thiết bị nói trên có phiên bản FCM đích 4 và phiên bản FCM hạt nhân của nó 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 r ) của hạt nhân.

Các bài kiểm tra VTS thực thi rằng, nếu phiên bản FCM hạt nhân được chỉ định, thì phiên bản FCM hạt nhân 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 hạt nhân

Nếu thiết bị có phiên bản FCM đích 4 (được 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ư 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 với các yêu cầu trên 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 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 nhận bản phát hành Android từ bản phát hành nhân và sử dụng nó để xác định phiên bản FCM của nhân. Trong ví dụ này, android12 có nghĩa là kernel FCM phiên bản 6 (được phát hành trong Android 12).

Để biết 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 Phiên bản GKI .

Khớp các phiên bản hạt nhân

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 bằng cách sử dụng định dạng:

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

Đối tượng VINTF chỉ coi phần <kernel> từ FCM có phiên bản FCM phù hợp có cùng ${ver}${major_rev} làm nhân thiết bị (tức là version="${ver}.${major_rev}.${matrix_minor_rev}") ; các phần khác 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ì phần đó không phù hợp.

Ví dụ: Chọn các yêu cầu để đối sánh

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 đích, phiên bản FCM hạt nhân và phiên bản hạt nhân cùng nhau chọn các yêu cầu hạt nhân từ các FCM:

Phiên bản FCM mục tiêu Phiên bản Kernel FCM Phiên bản hạt nhân Phù hợp với
3 (P) không xác định 4.4.106 Không khớp (phiên bản nhỏ không khớp)
3 (P) không xác định 4.4.107 4.4-p
3 (P) không xác định 4.19.42 4.19-q (xem ghi chú bên dưới)
3 (P) không xác định 5.4.41 5.4-r (xem ghi chú bên dưới)
3 (P) 3 (P) 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 (P) 4 (Q) 4.19.42 4.19-q
4 (Q) không xác định 4.4.107 Không khớp (không có nhánh hạt nhân 4.4-q )
4 (Q) không xác định 4.9.165 4.9-q
4 (Q) không xác đị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 (Q) 5 (R) 4.14.105 4.14-r
4 (Q) 5 (R) 5.4.41 5.4-r
5 (R) không xác định không tí nào VTS không thành công (Phải chỉ định phiên bản FCM hạt nhân cho phiên bản FCM mục tiêu 5)
5 (R) 4 (Q) không tí nào 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 (R) 5 (R) 4.14.180 4.14-r

Khớp các cấu hình hạt nhân

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

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

  • <value type="string">bar</value> khớp với "bar" . Trích dẫn được 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 tương đương với hệ thập lục phân.

Ví dụ: Kết hợp hạt 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 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 hạt nhân được so khớp đầu tiên. Nhánh hạt nhân được chỉ định trong tệp kê khai thiết bị ở manifest.kernel.target-level manifest.level . Nếu nhánh hạt nhân 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 hạt nhân.
  • là 2, không khớp với ma trận. Thay vào đó, các đối tượng VINTF đọc các yêu cầu 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 được 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ừ khi có một phần 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 phần <kernel> thích hợp được chọn, đối với mỗi mục <config> có giá trị khác n , chúng tôi hy vọng mục nhập tương ứng sẽ có trong /proc/config.gz ; đối với mỗi mục <config> có giá trị n , chúng tôi hy vọng mục nhập tương ứng không có trong /proc/config.gz . Chúng tôi hy vọng nội dung của <value> 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ề kết hợ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 là một ví dụ về kết quả 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

Chính sách SE phù hợp

Chính sách SE yêu cầu các kết quả phù hợp sau:

  • <sepolicy-version> xác định một loạt các phiên bản phụ cho mọi phiên bản chính. Phiên bản riêng biệt được 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 khuôn khổ. Quy tắc trận đấu tương tự như phiên bản HAL; nó phù hợp nếu phiên bản riêng biệt 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 hoàn toàn là thông tin.
  • <kernel-sepolicy-version> tức là phiên bản policydb. Phải nhỏ hơn security_policyvers() được thiết bị báo cáo.

Ví dụ: Đối sánh chính sách SE thành công

Ma trận khả năng tương thích của khung công bố thông tin riêng biệt 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ị được trả về bởi security_policyvers() phải lớn hơn hoặc bằng 30. Nếu không, nó không phải là giá trị khớp. Ví dụ:
    • Nếu một thiết bị trả về 29, nó không phải là một kết quả phù hợp.
    • Nếu một thiết bị trả về 31, đó là một thiết bị trùng khớp.
  • Phiên bản Chính sách SE phải là một trong 25.0-∞ hoặc 26.0-∞. Nếu không thì nó không phải là một trận đấu. (" -3 " sau " 26.0 " hoàn toàn là thông tin.)

Phiên bản AVB phù hợp

Phiên bản AVB chứa phiên bản CHÍNH và phiên bản MINOR, với định dạng là MAJOR.MINOR (ví dụ: 1.0, 2.1). Để biết chi tiết, hãy tham khả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:

  • ro.boot.vbmeta.avb_version là phiên bản libavb trong bootloader
  • 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ề OK). Sẽ không có nếu xảy ra lỗi xác minh (hoặc không có xác minh nào xảy ra).

Kết hợp tương thích so sánh những điều 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

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

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 phù hợp (tất cả các phân vùng đều là P).

Ví dụ: Đối sánh phiên bản AVB thành công

Ma trận khả năng tương thích của khung công bố thông tin AVB sau:

<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 

Phù hợp với phiên bản AVB trong OTA

Đối với các thiết bị khởi chạy với 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 khả năng tương thích của khung được 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ó nâng cấp phiên bản lớn trong OTA (ví dụ: từ 0,0 lê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 đề, OEM có thể đặt một phiên bản AVB giả mạo trong gói OTA ( compatibility.zip ) để vượt qua kiểm tra. Làm như vậy:

  1. Cherry-chọn các CL sau vào cây nguồn Android 9:
  2. Xác định BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE cho thiết bị. Giá trị của nó 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 nó được khởi chạy.
  3. Xây dựng lại gói OTA.

Những thay đổi này 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 sử dụng trong Android 9) trên thiết bị
  • system_matrix.xml trong compatibility.zip thích.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 /system/etc/vintf/compatibility_matrix.xml . Sau OTA, giá trị mới trong /system/etc/vintf/compatibility_matrix.xml được sử dụng để kiểm tra tính tương thích.

Các trận đấu phiên bản VNDK

Ma trận khả năng tương thích của thiết bị khai báo phiên bản VNDK được yêu cầu 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ó <vendor-ndk> , thì không có yêu cầu nào được áp đặt và do đó nó luôn được coi là phù hợp.

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

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

Ví dụ: Đối sánh 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 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 đượ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 đối sánh 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 phải là một kết quả phù hợp. Mặc dù VNDK phiên bản 27 có trong tệp kê khai khung, libjpeg.so không được khung hỗ trợ trong ảnh chụp nhanh đó. VNDK phiên bản 26 bị bỏ qua.

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

Ví dụ: Đối sánh phiên bản SDK hệ thống 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 đối với SDK hệ thống:

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

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

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

Ví dụ A là một trận đấu.

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

Ví dụ B là một trận đấu.

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

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