Aturan Pencocokan

Dua pasang matriks kompatibilitas dan manifes dimaksudkan untuk direkonsiliasi guna 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 boot, dan dalam uji kompatibilitas VTS.

Bagian berikut merinci aturan pencocokan yang digunakan oleh berbagai komponen.

Versi matriks kompatibilitas kerangka kerja cocok

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

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

pertandingan HAL

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

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 satu hubungan AND ketika <hal> diperlukan. (Lihat Contoh DRM di bawah.)

Contoh: Pencocokan HAL yang berhasil untuk sebuah modul

Untuk HAL versi 2.5, aturan kecocokannya adalah sebagai berikut:

Matriks Manifes Pencocokan
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 melebihi 2.7. Pemilik manifes yang cocok masih dapat menayangkan versi 2.10 (sebagai contoh) ketika versi 2.7 diminta. Pemilik matriks kompatibilitas hanya mengetahui bahwa layanan yang diminta kompatibel dengan API versi 2.7.
  • -7 hanya bersifat informasi dan tidak mempengaruhi proses update OTA.
Dengan demikian, perangkat dengan HAL 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 SALAH SATU dari 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 menerapkan semua contoh berikut:

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 mirip dengan HIDL dan HAL asli, hanya saja tidak ada versi utama, dan hanya ada satu versi per instance 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 satu hubungan AND ketika <hal> diperlukan. (Lihat contoh vibrator di bawah ini.)

Contoh: Pencocokan HAL yang berhasil untuk sebuah modul

Untuk HAL versi 5, aturan kecocokannya adalah sebagai berikut:

Matriks Manifes Pencocokan
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 kerja atau perangkat) tidak akan meminta versi lebih dari 7. Pemilik manifes yang cocok masih dapat menyajikan versi 10 (sebagai contoh) ketika 7 diminta . Pemilik matriks kompatibilitas hanya mengetahui bahwa layanan yang diminta kompatibel dengan API versi 7.
  • -7 hanya bersifat informasi dan tidak mempengaruhi proses update OTA.
Dengan demikian, perangkat dengan HAL 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 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 contoh berikut:

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 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 kernel FCM yang unik (misalnya, 5). Pemetaannya sama dengan pemetaan antara surat rilis (misalnya R) dan versi FCM (misalnya 5).

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

  • Versi kernel FCM berbeda dengan 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 ).

Pengujian VTS menerapkan bahwa, jika versi kernel FCM ditentukan, versi kernel FCM lebih besar 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 kernel FCM. Dalam contoh ini, android12 berarti kernel FCM versi 6 (dirilis di Android 12).

Untuk detail tentang cara penguraian string rilis kernel, lihat Pembuatan versi GKI .

Cocokkan versi kernel

Sebuah matriks dapat mencakup beberapa bagian <kernel> , masing-masing dengan atribut version 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 dengan kernel perangkat (yaitu, version="${ver}.${major_rev}.${matrix_minor_rev}") ; bagian lain diabaikan. Selain itu, revisi kecil dari kernel harus berupa nilai dari matriks kompatibilitas ( ${kernel_minor_rev} >= ${matrix_minor_rev} ;). Jika tidak ada bagian <kernel> yang memenuhi persyaratan ini, berarti tidak cocok.

Contoh: Pilih persyaratan untuk pencocokan

Pertimbangkan kasus hipotetis berikut ini ketika FCM di /system/etc/vintf mendeklarasikan 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 kernel FCM, 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 cocok (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 (Q) 4.19.42 4.19-q
4 (Q) tidak ditentukan 4.4.107 Tidak ada kecocokan (tidak ada cabang kernel 4.4-q )
4 (Q) tidak ditentukan 4.9.165 4.9-q
4 (Q) tidak ditentukan 5.4.41 5.4-r (lihat catatan di bawah)
4 (Q) 4 (Q) 4.9.165 4.9-q
4 (Q) 4 (Q) 5.4.41 Tidak ada kecocokan (tidak ada cabang kernel 5.4-q )
4 (Q) 5 (kanan) 4.14.105 4.14-r
4 (Q) 5 (kanan) 5.4.41 5.4-r
5 (kanan) tidak ditentukan setiap VTS gagal (Harus menentukan versi kernel FCM untuk target FCM versi 5)
5 (kanan) 4 (Q) setiap VTS gagal (versi kernel FCM < target versi FCM)
5 (kanan) 5 (kanan) 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 tersebut ada. Ketika item konfigurasi disetel ke n dalam matriks kompatibilitas untuk bagian <kernel> yang cocok, item tersebut harus tidak ada di /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 dengan heksadesimal.

Contoh: Pencocokan kernel 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 perangkat manifes:

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

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 mengharapkan entri terkait ada di /proc/config.gz ; untuk setiap item <config> dengan nilai n , kami berharap entri terkait tidak ada di /proc/config.gz . Kami mengharapkan konten <value> sama persis dengan teks setelah tanda sama dengan (termasuk tanda kutip), hingga karakter baris baru atau # , dengan spasi di 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

Kebijakan SE cocok

Kebijakan SE memerlukan kecocokan berikut:

  • <sepolicy-version> mendefinisikan rentang tertutup versi minor untuk setiap versi mayor. Versi sepolicy yang dilaporkan oleh perangkat harus berada dalam salah satu rentang ini agar kompatibel dengan kerangka kerja. Aturan pertandingan mirip dengan versi HAL; ini cocok jika versi sepolicy lebih tinggi atau sama dengan versi minimum untuk rentang tersebut. Versi maksimum hanya bersifat informasional.
  • <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 sepolicy 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 atau sama dengan 30. Jika tidak, maka nilai tersebut tidak cocok. Misalnya:
    • Jika perangkat mengembalikan 29, itu tidak cocok.
    • Jika perangkat mengembalikan 31, itu cocok.
  • Versi Kebijakan SE harus berupa salah satu dari 25.0-∞ atau 26.0-∞. Kalau tidak, itu bukan pertandingan. (" -3 " setelah " 26.0 " murni bersifat informasi.)

Versi AVB cocok

Versi AVB berisi versi MAJOR dan versi MINOR, dengan format MAJOR.MINOR (misalnya 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 terkait telah digunakan untuk memverifikasi metadata AVB (dan mengembalikan OK). Tidak ada jika terjadi kegagalan verifikasi (atau tidak ada verifikasi sama sekali).

Kecocokan kompatibilitas membandingkan hal berikut:

  • 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 peningkatan perangkat dan peluncuran perangkat. Dalam hal ini, image sistem yang tidak ditandatangani yang sama dapat dibagikan tetapi image sistem bertanda tangan akhir berbeda (dengan avb.vbmeta-version yang berbeda):

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


Gambar 2. Versi AVB cocok (semua partisi adalah P).

Contoh: Pencocokan 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 
l10n-placeholder18
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 mengupdate ke Android 10, persyaratan versi AVB dalam matriks kompatibilitas framework akan disesuaikan dengan versi AVB saat ini di perangkat. Jika versi AVB memiliki peningkatan versi utama selama OTA (misalnya, dari 0,0 ke 1,0), pemeriksaan kompatibilitas VINTF di OTA tidak mencerminkan kompatibilitas setelah OTA.

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

  1. 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 mendeklarasikan versi VNDK yang diperlukan dalam compatibility-matrix.vendor-ndk.version . Jika matriks kompatibilitas perangkat tidak memiliki tag <vendor-ndk> , tidak ada persyaratan yang diterapkan, sehingga selalu dianggap cocok.

Jika matriks kompatibilitas perangkat memiliki tag <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, maka tidak ada kecocokan.

Jika entri tersebut 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 tersebut tidak dianggap cocok.

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

Contoh: Pencocokan 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 framework, 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 snapshot tersebut. VNDK versi 26 diabaikan.

Versi SDK Sistem cocok

Matriks kompatibilitas perangkat mendeklarasikan serangkaian versi System SDK yang diperlukan dalam compatibility-matrix.system-sdk.version . Kecocokan hanya terjadi jika kumpulan tersebut merupakan bagian dari versi SDK Sistem yang disediakan seperti yang dinyatakan dalam manifest.system-sdk.version dalam manifes kerangka kerja.

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

Contoh: Versi SDK Sistem yang berhasil cocok

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, kerangka kerja harus menyediakan System SDK versi 26 dan 27 agar sesuai.

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

Contoh A adalah kecocokan.

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