Aturan Pencocokan

Dua pasang matriks kompatibilitas dan manifes dimaksudkan untuk direkonsiliasi untuk memverifikasi bahwa kerangka kerja dan implementasi vendor dapat bekerja satu sama lain. Verifikasi ini berhasil jika ada kecocokan antara matriks kompatibilitas kerangka kerja dan manifes perangkat, serta antara manifes kerangka kerja dan matriks kompatibilitas perangkat.

Verifikasi ini dilakukan pada waktu pembuatan, pada waktu pembuatan paket pembaruan OTA , pada waktu booting, dan dalam uji kompatibilitas VTS.

Bagian berikut merinci aturan pencocokan yang digunakan oleh berbagai komponen.

Versi matriks kompatibilitas kerangka cocok

Untuk mencocokkan manifes perangkat dengan matriks kompatibilitas kerangka kerja, versi FCM Pengiriman yang ditentukan oleh manifest.target-level harus sama persis dengan versi FCM yang ditentukan oleh compatibility-matrix.level . Jika tidak, tidak ada kecocokan.

Ketika matriks kompatibilitas kerangka kerja diminta dengan libvintf , pencocokan ini selalu berhasil karena libvintf membuka manifes perangkat, mengambil Versi FCM Pengiriman, dan mengembalikan matriks kompatibilitas kerangka kerja pada Versi FCM Pengiriman tersebut (ditambah beberapa HAL opsional dari matriks kompatibilitas di FCM yang lebih tinggi Versi).

pertandingan HAL

Aturan kecocokan HAL mengidentifikasi versi elemen hal dalam file manifes yang dianggap didukung oleh pemilik matriks kompatibilitas yang sesuai.

HIDL dan HAL asli

Aturan kecocokan untuk HIDL dan HAL asli adalah sebagai berikut.

  • Beberapa elemen <hal> dievaluasi dengan satu hubungan AND .
  • Elemen <hal> mungkin memiliki <hal optional="true"> untuk menandainya sebagai tidak diperlukan.
  • Beberapa elemen <version> dalam <hal> yang sama memiliki hubungan OR . Jika dua atau lebih ditentukan, hanya satu versi yang perlu diimplementasikan. (Lihat contoh DRM di bawah.)
  • Beberapa elemen <instance> dan <regex-instance> dalam <hal> yang sama dievaluasi dengan hubungan AND tunggal ketika <hal> diperlukan. (Lihat contoh DRM di bawah ini.)

Contoh: Pencocokan HAL yang berhasil untuk sebuah modul

Untuk HAL di versi 2.5, aturan kecocokan adalah sebagai berikut:

Matriks Manifes yang Cocok
2.5 2.5-2.∞. Dalam matriks kompatibilitas, 2.5 adalah singkatan dari 2.5-5 .
2.5-7 2.5-2.∞. Menunjukkan hal berikut:
  • 2.5 adalah versi minimum yang diperlukan, artinya manifes yang menyediakan HAL 2.0-2.4 tidak kompatibel.
  • 2.7 adalah versi maksimum yang dapat diminta, artinya pemilik matriks kompatibilitas (kerangka atau perangkat) tidak akan meminta versi di luar 2.7. Pemilik manifes yang cocok masih dapat menayangkan versi 2.10 (sebagai contoh) saat 2.7 diminta. Pemilik compatibility-matrix hanya mengetahui bahwa layanan yang diminta kompatibel dengan API versi 2.7.
  • -7 hanya bersifat informasi dan tidak memengaruhi proses pembaruan OTA.
Dengan demikian, perangkat dengan HAL pada versi 2.10 dalam file manifesnya tetap kompatibel dengan kerangka kerja yang menyatakan 2.5-7 dalam matriks kompatibilitasnya.

Contoh: Pencocokan HAL yang berhasil untuk modul DRM

Matriks kompatibilitas kerangka kerja menyatakan informasi versi berikut untuk 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>

Vendor harus menerapkan SATU contoh berikut; salah satu

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

DAN juga harus mengimplementasikan semua instance ini:

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

Semua versi Android yang lebih baru dari Android 11 (tidak termasuk Android 11) mendukung versi untuk AIDL HAL di VINTF. Aturan kecocokan untuk AIDL HAL serupa dengan HIDL dan HAL asli, kecuali bahwa tidak ada versi utama, dan hanya ada satu versi per instans HAL ( 1 jika versi tidak ditentukan).

  • Beberapa elemen <hal> dievaluasi dengan satu hubungan AND .
  • Elemen <hal> mungkin memiliki <hal optional="true"> untuk menandainya sebagai tidak diperlukan.
  • Beberapa elemen <instance> dan <regex-instance> dalam <hal> yang sama dievaluasi dengan hubungan AND tunggal ketika <hal> diperlukan. (Lihat contoh vibrator di bawah ini.)

Contoh: Pencocokan HAL yang berhasil untuk sebuah modul

Untuk HAL di versi 5, aturan pertandingannya adalah sebagai berikut:

Matriks Manifes yang Cocok
5 5-∞. Dalam matriks kompatibilitas, 5 adalah singkatan dari 5-5 .
5-7 5-∞. Menunjukkan hal berikut:
  • 5 adalah versi minimum yang diperlukan, artinya manifes yang menyediakan HAL 1-4 tidak kompatibel.
  • 7 adalah versi maksimum yang dapat diminta, artinya pemilik matriks kompatibilitas (kerangka atau perangkat) tidak akan meminta versi di luar 7. Pemilik manifes yang cocok masih dapat menayangkan versi 10 (sebagai contoh) ketika 7 diminta . Pemilik compatibility-matrix hanya mengetahui bahwa layanan yang diminta kompatibel dengan API versi 7.
  • -7 hanya bersifat informasi dan tidak memengaruhi proses pembaruan OTA.
Dengan demikian, perangkat dengan HAL pada versi 10 dalam file manifesnya tetap kompatibel dengan kerangka kerja yang menyatakan 5-7 dalam matriks kompatibilitasnya.

Contoh: Pencocokan HAL yang berhasil untuk beberapa modul

Matriks kompatibilitas kerangka kerja menyatakan informasi versi berikut untuk vibrator dan kamera 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>

Vendor harus mengimplementasikan semua instance ini:

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 cocok

Bagian <kernel> dari matriks kompatibilitas kerangka kerja menjelaskan persyaratan kerangka kerja dari kernel Linux pada perangkat. Informasi ini dimaksudkan untuk dicocokkan dengan informasi tentang kernel yang dilaporkan oleh objek VINTF perangkat.

Cocokkan cabang kernel

Setiap akhiran cabang kernel (misalnya, 5.4- r ) dipetakan ke versi FCM kernel yang unik (misalnya, 5). Pemetaan sama dengan pemetaan antara huruf rilis (misalnya, R) dan versi FCM (misalnya, 5).

Tes VTS menegakkan bahwa perangkat secara eksplisit menentukan versi kernel FCM dalam manifes perangkat, /vendor/etc/vintf/manifest.xml , jika salah satu dari berikut ini benar:

  • Versi kernel FCM berbeda dari versi FCM target. Misalnya, perangkat yang disebutkan di atas memiliki target FCM versi 4, dan versi kernel FCM-nya adalah 5 (akhiran cabang kernel r ).
  • Versi kernel FCM lebih besar dari atau sama dengan 5 (akhiran cabang kernel r ).

Tes VTS memberlakukan bahwa, jika versi kernel FCM ditentukan, versi kernel FCM lebih besar dari atau sama dengan versi FCM target dalam manifes perangkat.

Contoh: Tentukan cabang kernel

Jika perangkat memiliki target FCM versi 4 (dirilis di Android 10), tetapi menjalankan kernel dari cabang 4.19-r , manifes perangkat harus menentukan hal berikut:

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

Objek VINTF memeriksa kompatibilitas kernel terhadap persyaratan pada cabang kernel 4.19-r , yang ditentukan dalam FCM versi 5. Persyaratan ini dibuat dari kernel/configs/r/android-4.19 di pohon sumber Android.

Contoh: Tentukan cabang kernel untuk GKI

Jika perangkat menggunakan Generic Kernel Image (GKI), dan string rilis kernel dari /proc/version adalah sebagai berikut:

5.4.42-android12-0-00544-ged21d463f856

Kemudian, objek VINTF memperoleh rilis Android dari rilis kernel, dan menggunakannya untuk menentukan versi FCM kernel. Dalam contoh ini, android12 berarti kernel FCM versi 6 (dirilis di Android 12).

Untuk detail tentang bagaimana string rilis kernel diuraikan, lihat pembuatan versi GKI .

Cocokkan versi kernel

Matriks dapat menyertakan beberapa bagian <kernel> , masing-masing dengan atribut version yang berbeda menggunakan format:

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

Objek VINTF hanya mempertimbangkan bagian <kernel> dari FCM dengan versi FCM yang cocok dengan ${ver} dan ${major_rev} yang sama sebagai kernel perangkat (yaitu, version="${ver}.${major_rev}.${matrix_minor_rev}") ; bagian lain diabaikan. Selain itu, revisi minor dari kernel harus berupa nilai dari matriks kompatibilitas ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Jika tidak ada bagian <kernel> yang memenuhi persyaratan ini, itu tidak cocok.

Contoh: Pilih persyaratan untuk pencocokan

Pertimbangkan kasus hipotetis berikut di mana FCM di /system/etc/vintf menyatakan persyaratan berikut (tag header dan footer dihilangkan):

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

Versi FCM target, versi FCM kernel, dan versi kernel bersama-sama memilih persyaratan kernel dari FCM:

Targetkan versi FCM Versi kernel FCM Versi kernel Cocok dengan
3 (P) tidak ditentukan 4.4.106 Tidak ada kecocokan (ketidakcocokan versi minor)
3 (P) tidak ditentukan 4.4.107 4.4-p
3 (P) tidak ditentukan 4.19.42 4.19-q (lihat catatan di bawah)
3 (P) tidak ditentukan 5.4.41 5.4-r (lihat catatan di bawah)
3 (P) 3 (P) 4.4.107 4.4-p
3 (P) 3 (P) 4.19.42 Tidak ada kecocokan (tidak ada cabang kernel 4.19-p )
3 (P) 4 (T) 4.19.42 4.19-q
4 (T) tidak ditentukan 4.4.107 Tidak ada kecocokan (tidak ada cabang kernel 4.4-q )
4 (T) tidak ditentukan 4.9.165 4.9-q
4 (T) tidak ditentukan 5.4.41 5.4-r (lihat catatan di bawah)
4 (T) 4 (T) 4.9.165 4.9-q
4 (T) 4 (T) 5.4.41 Tidak ada kecocokan (tidak ada cabang kernel 5.4-q )
4 (T) 5 (R) 4.14.105 4.14-r
4 (T) 5 (R) 5.4.41 5.4-r
5 (R) tidak ditentukan setiap VTS gagal (Harus menentukan versi kernel FCM untuk target FCM versi 5)
5 (R) 4 (T) setiap VTS gagal (versi FCM kernel < versi target FCM)
5 (R) 5 (R) 4.14.180 4.14-r

Cocokkan konfigurasi kernel

Jika bagian <kernel> cocok, proses dilanjutkan dengan mencoba mencocokkan elemen config dengan /proc/config.gz . Untuk setiap elemen konfigurasi dalam matriks kompatibilitas, ia mencari /proc/config.gz untuk melihat apakah konfigurasi ada. Ketika item konfigurasi diatur ke n dalam matriks kompatibilitas untuk bagian <kernel> yang cocok, item tersebut harus tidak ada /proc/config.gz . Terakhir, item konfigurasi yang tidak ada dalam matriks kompatibilitas mungkin ada atau tidak ada di /proc/config.gz .

Contoh: Cocokkan konfigurasi kernel

  • <value type="string">bar</value> cocok dengan "bar" . Kutipan dihilangkan dalam matriks kompatibilitas tetapi ada di /proc/config.gz .
  • <value type="int">4096</value> cocok dengan 4096 atau 0x1000 atau 0X1000 .
  • <value type="int">0x1000</value> cocok dengan 4096 atau 0x1000 atau 0X1000 .
  • <value type="int">0X1000</value> cocok dengan 4096 atau 0x1000 atau 0X1000 .
  • <value type="tristate">y</value> cocok dengan y .
  • <value type="tristate">m</value> cocok dengan m .
  • <value type="tristate">n</value> berarti item konfigurasi TIDAK boleh ada di /proc/config.gz .
  • <value type="range">1-0x3</value> cocok dengan 1 , 2 , atau 3 , atau setara heksadesimal.

Contoh: Pencocokan kernel yang berhasil

Matriks kompatibilitas kerangka kerja dengan FCM versi 1 memiliki informasi kernel berikut:

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

Cabang kernel dicocokkan terlebih dahulu. Cabang kernel ditentukan dalam manifes perangkat di manifest.kernel.target-level , yang defaultnya adalah manifest.level jika yang pertama tidak ditentukan. Jika cabang kernel di manifes perangkat:

  • adalah 1, lanjutkan ke langkah berikutnya dan periksa versi kernel.
  • adalah 2, tidak cocok dengan matriks. Objek VINTF membaca persyaratan kernel dari matriks di FCM versi 2 sebagai gantinya.

Kemudian, versi kernel dicocokkan. Jika perangkat di uname() melaporkan:

  • 4.9.84 (tidak cocok dengan matriks kecuali ada bagian kernel terpisah dengan <kernel version="4.9.x"> , di mana x <= 84 )
  • 4.14.41 (tidak cocok dengan matriks, lebih kecil dari version )
  • 4.14.42 (cocok dengan matriks)
  • 4.14.43 (cocok dengan matriks)
  • 4.1.22 (tidak cocok dengan matriks kecuali ada bagian kernel terpisah dengan <kernel version="4.1.x"> di mana x <= 22 )

Setelah bagian <kernel> yang sesuai dipilih, untuk setiap item <config> dengan nilai selain n , kami berharap entri yang sesuai ada di /proc/config.gz ; untuk setiap item <config> dengan nilai n , kami berharap entri yang sesuai tidak ada di /proc/config.gz . Kami berharap konten <value> sama persis dengan teks setelah tanda sama dengan (termasuk tanda kutip), hingga karakter baris baru atau # , dengan spasi putih awal dan akhir terpotong.

Konfigurasi kernel berikut adalah contoh kecocokan yang berhasil:

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

Konfigurasi kernel berikut adalah contoh kecocokan yang gagal:

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

Kecocokan kebijakan SE

Kebijakan SE memerlukan kecocokan berikut:

  • <sepolicy-version> mendefinisikan rentang tertutup versi minor untuk setiap versi mayor. Versi kebijakan yang dilaporkan oleh perangkat harus termasuk dalam salah satu rentang ini agar kompatibel dengan kerangka kerja. Aturan kecocokan mirip dengan versi HAL; cocok jika versi sepolicy lebih tinggi atau sama dengan versi minimum untuk rentang tersebut. Versi maksimum adalah murni informasi.
  • <kernel-sepolicy-version> yaitu versi policydb. Harus kurang dari security_policyvers() yang dilaporkan oleh perangkat.

Contoh: Kecocokan kebijakan SE yang berhasil

Matriks kompatibilitas kerangka kerja menyatakan informasi kebijakan berikut:

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

Di perangkat:

  • Nilai yang dikembalikan oleh security_policyvers() harus lebih besar dari atau sama dengan 30. Jika tidak, nilai tersebut tidak cocok. Sebagai contoh:
    • Jika perangkat mengembalikan 29, itu tidak cocok.
    • Jika perangkat mengembalikan 31, itu cocok.
  • Versi Kebijakan SE harus salah satu dari 25.0-∞ atau 26.0-. Kalau tidak, itu bukan kecocokan. (The " -3 " setelah " 26.0 " adalah murni informasi.)

Versi AVB cocok

Versi AVB berisi versi MAJOR dan versi MINOR, dengan format sebagai MAJOR.MINOR (mis. 1.0, 2.1). Untuk detailnya, lihat Pembuatan Versi dan Kompatibilitas . Versi AVB memiliki properti sistem berikut:

  • ro.boot.vbmeta.avb_version adalah versi libavb di bootloader
  • ro.boot.avb_version adalah versi libavb di OS Android ( init/fs_mgr )

Properti sistem hanya muncul ketika libavb yang sesuai telah digunakan untuk memverifikasi metadata AVB (dan mengembalikan OK). Tidak ada jika terjadi kegagalan verifikasi (atau tidak ada verifikasi sama sekali).

Kecocokan kompatibilitas membandingkan yang berikut ini:

  • sysprop ro.boot.vbmeta.avb_version dengan avb.vbmeta-version dari matriks kompatibilitas kerangka kerja;
    • 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 dengan avb.vbmeta-version dari matriks kompatibilitas kerangka kerja.
    • ro.boot.avb_version.MAJOR == avb.vbmeta-version.MAJOR
    • ro.boot.avb_version.MINOR >= avb.vbmeta-version.MINOR

Bootloader atau OS Android mungkin berisi dua salinan pustaka libavb , masing-masing dengan versi UTAMA yang berbeda untuk perangkat pemutakhiran dan perangkat peluncuran. Dalam hal ini, gambar sistem yang tidak ditandatangani yang sama dapat dibagikan tetapi gambar sistem yang ditandatangani terakhir berbeda (dengan avb.vbmeta-version yang berbeda):

Gambar 1. Versi AVB cocok ( /system adalah P, semua partisi lainnya adalah O).


Gambar 2. Kecocokan versi AVB (semua partisi adalah P).

Contoh: Kecocokan versi AVB yang berhasil

Matriks kompatibilitas kerangka kerja menyatakan informasi AVB berikut:

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

Di perangkat:

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 

Mencocokkan versi AVB selama OTA

Untuk perangkat yang diluncurkan dengan Android 9 atau lebih rendah, saat memperbarui ke Android 10, persyaratan versi AVB dalam matriks kompatibilitas kerangka kerja dicocokkan dengan versi AVB saat ini di perangkat. Jika versi AVB memiliki peningkatan versi utama selama OTA (misalnya, dari 0,0 ke 1,0), pemeriksaan VINTF untuk kompatibilitas di OTA tidak mencerminkan kompatibilitas setelah OTA.

Untuk mengurangi masalah ini, OEM dapat menempatkan versi AVB palsu dalam paket OTA ( compatibility.zip ) untuk lulus pemeriksaan. Untuk melakukannya:

  1. Cherry-pilih CL berikut ke pohon sumber Android 9:
  2. Tentukan BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE untuk perangkat. Nilainya harus sama dengan versi AVB sebelum OTA, yaitu versi AVB perangkat saat diluncurkan.
  3. Bangun kembali paket OTA.

Perubahan ini secara otomatis menempatkan BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE sebagai compatibility-matrix.avb.vbmeta-version dalam file berikut:

  • /system/compatibility_matrix.xml (yang tidak digunakan di Android 9) pada perangkat
  • system_matrix.xml di compatibility.zip dalam paket OTA

Perubahan ini tidak memengaruhi matriks kompatibilitas kerangka kerja lainnya, termasuk /system/etc/vintf/compatibility_matrix.xml . Setelah OTA, nilai baru di /system/etc/vintf/compatibility_matrix.xml digunakan untuk pemeriksaan kompatibilitas.

Versi VNDK cocok

Matriks kompatibilitas perangkat menyatakan versi VNDK yang diperlukan dalam compatibility-matrix.vendor-ndk.version . Jika matriks kompatibilitas perangkat tidak memiliki <vendor-ndk> , tidak ada persyaratan yang dikenakan, dan karenanya selalu dianggap cocok.

Jika matriks kompatibilitas perangkat memiliki tag <vendor-ndk> <vendor-ndk> , entri <vendor-ndk> dengan <version> yang cocok akan dicari dari kumpulan snapshot vendor VNDK yang disediakan oleh kerangka kerja dalam manifes kerangka kerja. Jika entri seperti itu tidak ada, tidak ada kecocokan.

Jika entri seperti itu memang ada, kumpulan pustaka yang disebutkan dalam matriks kompatibilitas perangkat harus merupakan subset dari kumpulan pustaka yang dinyatakan dalam manifes kerangka kerja; jika tidak, entri tidak dianggap cocok.

  • Sebagai kasus khusus, jika tidak ada pustaka yang disebutkan dalam matriks kompatibilitas perangkat, entri selalu dianggap cocok, karena himpunan kosong adalah subset dari himpunan apa pun.

Contoh: Kecocokan versi VNDK yang berhasil

Jika matriks kompatibilitas perangkat menyatakan persyaratan berikut pada VNDK:

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

Dalam manifes kerangka kerja, hanya entri dengan versi 27 yang dipertimbangkan.

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

Contoh A cocok, karena VNDK versi 27 ada dalam manifes kerangka kerja, dan {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>

Contoh B tidak cocok. Meskipun VNDK versi 27 ada dalam manifes kerangka kerja, libjpeg.so tidak didukung oleh kerangka kerja dalam cuplikan itu. VNDK versi 26 diabaikan.

Versi SDK sistem cocok

Matriks kompatibilitas perangkat mendeklarasikan kumpulan versi System SDK yang diperlukan di compatibility-matrix.system-sdk.version . Ada kecocokan hanya jika set tersebut adalah subset dari versi SDK Sistem yang disediakan seperti yang dideklarasikan dalam manifest.system-sdk.version dalam manifes kerangka kerja.

  • Sebagai kasus khusus, jika tidak ada versi System SDK yang disebutkan dalam matriks kompatibilitas perangkat, itu selalu dianggap cocok, karena set kosong adalah subset dari set apa pun.

Contoh: Kecocokan versi System SDK yang berhasil

Jika matriks kompatibilitas perangkat menyatakan persyaratan berikut pada System SDK:

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

Kemudian, framework harus menyediakan System SDK versi 26 dan 27 untuk dicocokkan.

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

Contoh A adalah pertandingan.

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

Contoh B adalah kecocokan.

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

Contoh C tidak cocok, karena System SDK versi 27 tidak disediakan.