Quy tắc phù hợp

Hai cặp ma trận tương thích và bảng kê khai nhằm mục đích đối chiếu để xác minh rằng khung triển khai 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ự trùng khớ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, lúc tạo gói cập nhật OTA , lúc khởi động và trong các thử nghiệm tương thích VTS.

Các phần sau đây nêu chi tiết các quy tắc khớp đượ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

Để khớp một bảng kê khai thiết bị với ma trận tương thích khung, phiên bản Shipping FCM được chỉ định manifest.target-level phải hoàn toàn 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.

Khi ma trận tương thích khung được yêu cầu với libvintf , kết quả 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 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 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 ma trận tương thích tương ứng hỗ trợ.

HIDL và HAL gốc

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 thì chỉ cần triển khai một trong các phiên bản. (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ụ: 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 đối sánh như sau:

Ma trận Bản kê khai phù hợp
2.5 2,5-2.∞. Trong ma trận tương thích, 2.5 là tốc ký của 2.5-5 .
2.5-7 2,5-2.∞. Chỉ ra những điều sau đây:
  • 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, 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 ngoài 2.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 2.10 (làm ví dụ) khi yêu cầu 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 cung cấp 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 vẫn tương thích với khung nêu 2.5-7 trong ma trận tương thích của nó.

Ví dụ: Kết hợp HAL 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 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

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 sau Android 11 (không bao gồm Android 11) đều hỗ trợ các phiên bản dành cho AIDL HAL trong VINTF. Quy tắc so khớp 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à chỉ 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ụ: 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 đối sánh như sau:

Ma trận Bản kê khai phù hợp
5 5-∞. Trong ma trận tương thích, 5 là tốc ký của 5-5 .
5-7 5-∞. Chỉ ra những điều sau đây:
  • 5 là phiên bản bắt buộc tối thiểu, nghĩa là bản 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 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 ngoài 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 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 tương thích với khung nêu 5-7 trong ma trận tương thích của nó.

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

Ma trận tương thích khung nêu thông tin phiên bản sau cho HAL của 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 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

Trận đấu hạt nhân

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ị. Thông tin này nhằm mục đích khớp với thông tin về kernel được đối tượng VINTF của thiết bị báo cáo.

Ghép các nhánh hạt nhân

Mỗi hậu tố nhánh kernel (ví dụ: 5.4- r ) được ánh xạ tới một phiên bản FCM kernel duy nhất (ví dụ: 5). Ánh xạ cũng giống như ánh xạ 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).

Kiểm tra VTS yêu cầu thiết bị chỉ định rõ ràng phiên bản FCM kernel 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 kernel khác với phiên bản FCM đích. 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 kernel của nó là 5 (hậu tố nhánh kernel r ).
  • Phiên bản FCM kernel lớn hơn hoặc bằng 5 (hậu tố nhánh kernel r ).

Các thử nghiệm VTS thực thi rằng, nếu phiên bản FCM kernel được chỉ định thì phiên bản FCM kernel sẽ lớn hơn hoặc bằng phiên bản FCM đích trong bảng 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 kernel 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 kernel với các yêu cầu trên nhánh kernel 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 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 kernel và sử dụng nó để xác định phiên bản FCM kernel. Trong ví dụ này, android12 có nghĩa là kernel FCM phiên bản 6 (được phát hành trên Android 12).

Để biết chi tiết về cách phân tích cú pháp chuỗi phát hành kernel, hãy xem Phiên bản GKI .

Phù hợp với 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 sử dụng đị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 phù hợp với 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 được bỏ qua. Ngoài ra, bản sửa đổi nhỏ từ kernel phải là 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à phần không khớp.

Ví dụ: Chọn 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 đích, phiên bản FCM kernel và phiên bản kernel cùng chọn các yêu cầu kernel từ FCM:

Phiên bản FCM mục tiêu Phiên bản hạt nhân 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 kernel 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 kernel 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 kernel 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 bất kì VTS không thành công (Phải chỉ định phiên bản FCM kernel cho phiên bản FCM đích 5)
5 (R) 4 (Q) bất kì VTS không thành công (phiên bản FCM hạt nhân < phiên bản FCM đích)
5 (R) 5 (R) 4.14.180 4.14-r

Phù hợp với cấu hình kernel

Nếu phần <kernel> không khớp, quá trình sẽ tiếp tục bằng cách cố gắng khớp các thành phần config với /proc/config.gz . Đối với mỗi thành phần cấu hình trong ma trận tương thích, nó tra cứu /proc/config.gz để xem 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, mục đó phải vắng mặt 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ụ: So khớp cấu hình kernel

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

Ví dụ: Kết hợp kernel thành công

Ma trận tương thích khung với FCM phiên bản 1 có thông tin kernel 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 kernel được khớp đầu tiên. Nhánh hạt nhân được chỉ định trong bảng kê khai thiết bị ở tệp manifest.kernel.target-level , mặc định manifest.level nếu nhánh trước không được chỉ định. Nếu nhánh kernel trong bảng 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. Thay vào đó, các đối tượng VINTF đọc các yêu cầu kernel từ ma trận ở FCM phiên bản 2.

Sau đó, phiên bản kernel đượ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ó phần kernel riêng 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 kernel 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ẽ xuất hiện trong /proc/config.gz ; đối với mỗi mục <config> có giá trị n , chúng tôi 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 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 được cắt bớt.

Cấu hình kernel sau đây là một ví dụ về kết quả 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 kernel sau đây là một ví dụ về kết quả 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

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

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

  • <sepolicy-version> xác định một phạm vi đóng các phiên bản phụ cho mọi phiên bản chính. Phiên bản sepolicy đượ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 khung. Quy tắc so khớp tương tự như phiên bản HAL; nó phù hợ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 hoàn toàn mang tính 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 nêu rõ thông tin về 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ị được trả về bởi security_policyvers() phải lớn hơn hoặc bằng 30. Nếu không thì giá trị đó không khớp. Ví dụ:
    • Nếu một thiết bị trả về 29 thì thiết bị đó không khớp.
    • Nếu một thiết bị trả về 31 thì đó là kết quả 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ì đó không phải là một trận đấu. (" -3 " sau " 26.0 " hoàn toàn mang tính 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 NHỎ, 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). Nó sẽ vắng mặt nếu xảy ra lỗi xác minh (hoặc không có xác minh nào xảy ra).

Một trận đấu tương thích so sánh những điều sau đây:

  • 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ộ tải 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ùng một hình ảnh hệ thống chưa được ký có thể được chia sẻ nhưng hình ảnh hệ thống được ký cuối cùng lại khác (với avb.vbmeta-version ):

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

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

Ma trận tương thích khung nêu 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ị 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 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 OTA (ví dụ: từ 0,0 lên 1,0), việc kiểm tra tính 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 sự cố, OEM có thể đặt phiên bản AVB giả trong gói OTA ( compatibility.zip ) để vượt qua quá trình kiểm tra. Làm như vậy:

  1. Chọn các CL sau cho 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 ra mắt.
  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 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, thay vào đó, giá trị mới trong /system/etc/vintf/compatibility_matrix.xml được sử dụng để kiểm tra tính tương thích.

Phiên bản VNĐK phù hợp

Ma trận tương thích của thiết bị khai báo phiên bản VNĐK được yêu cầu trong compatibility-matrix.vendor-ndk.version . Nếu ma trận tương thích thiết bị không có thẻ <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 tương thích của thiết bị có thẻ <vendor-ndk> , mục nhập <vendor-ndk><version> phù hợp sẽ được tra cứu từ tập hợp ảnh chụp nhanh của nhà cung cấp VNĐK do khung cung cấp trong bảng kê khai khung. Nếu mục đó không tồn tại thì không có mục 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 ma trận tương thích của thiết bị phải là tập hợp con của tập hợp các thư viện được nêu trong bảng 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 tương thích thiết bị thì mục nhập luôn được coi là 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ụ: Trận đấu phiên bản VNĐK thành công

Nếu ma trận tương thích của thiết bị đưa ra yêu cầu sau đối với VNĐK:

<!-- 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à trùng khớp, vì VNĐK 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 trong ảnh chụp nhanh đó hỗ trợ. VNĐK phiên bản 26 bị bỏ qua.

Phiên bản SDK hệ thống phù hợp

Ma trận 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ó 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ươ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ụ: So khớp phiên bản SDK hệ thống thành công

Nếu ma trận tương thích của thiết bị nêu yêu cầu sau trên SDK hệ thống:

<!-- 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 để 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 khớp vì SDK hệ thống phiên bản 27 không được cung cấp.