Aturan pencocokan

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

Verifikasi ini dilakukan pada waktu build, di update OTA pembuatan paket, saat {i>booting<i}, dan dalam uji kompatibilitas VTS.

Bagian berikut menjelaskan aturan pencocokan yang digunakan oleh berbagai komponen.

Kecocokan versi matriks kompatibilitas framework

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

Jika matriks kompatibilitas framework diminta dengan libvintf, kecocokan ini adalah selalu berhasil karena libvintf membuka manifes perangkat, mengambil informasi Pengiriman Versi FCM, dan menampilkan matriks kompatibilitas framework pada Versi FCM Pengiriman (ditambah beberapa HAL opsional dari matriks kompatibilitas pada Versi FCM yang lebih tinggi).

Pertandingan HAL

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

HIDL dan HAL native

Aturan pencocokan untuk HIDL dan HAL native adalah sebagai berikut.

  • Beberapa elemen <hal> dievaluasi dengan satu AND hubungan.
  • Elemen <hal> mungkin memiliki <hal optional="true"> untuk menandainya sebagai tidak diperlukan.
  • Beberapa elemen <version> dalam elemen yang sama <hal> memiliki Hubungan ATAU. Jika dua atau lebih ditentukan, hanya salah satu versi yang perlu diterapkan. (Lihat contoh DRM di bawah.)
  • Beberapa <instance> dan <regex-instance> elemen di dalam elemen <hal> dievaluasi dengan satu hubungan AND saat <hal> wajib diisi. (Lihat <ahref="#drm">contoh DRM di bawah.)</ahref="#drm">

Contoh: Kecocokan HAL yang berhasil untuk modul

Untuk HAL pada versi 2.5, aturan kecocokannya adalah sebagai berikut:

Matriks Manifes Pencocokan
2.5 2,5-2. Dalam matriks kompatibilitas, 2.5 adalah nama pendek untuk 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 kerja atau perangkat) tidak akan meminta versi di atas 2,7. Pemilik manifes yang cocok tetap dapat menyajikan versi 2.10 (sebagai contoh) jika 2.7 diminta. Pemilik matriks kompatibilitas mengetahui hanya bahwa layanan yang diminta kompatibel dengan API versi 2.7.
  • -7 hanya bersifat informasi dan tidak memengaruhi proses update OTA.
Jadi, perangkat dengan HAL pada versi 2.10 dalam file manifesnya tetap kompatibel dengan kerangka kerja yang menyatakan 2.5-7 dalam matriks kompatibilitasnya.

Contoh: Kecocokan HAL yang berhasil untuk modul DRM

Matriks kompatibilitas framework 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 instance berikut; baik

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

HAL AIDL

Semua versi Android yang lebih baru daripada Android 11 (tidak termasuk Android 11) mendukung versi untuk AIDL HAL di VINTF. Aturan pencocokan untuk AIDL HAL mirip dengan HIDL dan HAL asli, kecuali bahwa tidak ada versi utama, dan hanya ada satu versi per instance HAL (1 jika versi belum ditentukan).

  • Beberapa elemen <hal> dievaluasi dengan satu AND hubungan.
  • Elemen <hal> mungkin memiliki <hal optional="true"> untuk menandainya sebagai tidak diperlukan.
  • Beberapa <instance> dan <regex-instance> elemen di dalam elemen <hal> dievaluasi dengan satu hubungan AND saat <hal> wajib diisi. (Lihat <ahref="#vibrator">contoh vibrator di bawah.)</ahref="#vibrator">

Contoh: Kecocokan HAL yang berhasil untuk modul

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

Matriks Manifes Pencocokan
5 5-⁠. Dalam matriks kompatibilitas, 5 adalah nama pendek untuk 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 setelah 7. Pemilik manifes yang cocok tetap dapat menayangkan versi 10 (sebagai contoh) jika 7 diminta. Pemilik matriks kompatibilitas mengetahui hanya jika layanan yang diminta kompatibel dengan API versi 7.
  • -7 hanya bersifat informasi dan tidak memengaruhi proses update OTA.
Sehingga, perangkat dengan HAL pada versi 10 dalam file manifesnya tetap kompatibel dengan kerangka kerja yang menyatakan 5-7 dalam matriks kompatibilitasnya.

Contoh: Kecocokan HAL yang berhasil untuk beberapa modul

Matriks kompatibilitas framework menyatakan informasi versi berikut untuk vibrator dan HAL kamera:

<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 menerapkan semua instance 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

Kecocokan kernel

Bagian <kernel> dari matriks kompatibilitas framework menjelaskan persyaratan framework kernel Linux pada perangkat. Ini informasi ini dimaksudkan untuk dicocokkan dengan informasi tentang {i>kernel<i} yang dilaporkan oleh objek VINTF perangkat.

Mencocokkan cabang kernel

Setiap akhiran cabang kernel (misalnya, 5.4-r) dipetakan ke sebuah versi FCM kernel (misalnya, 5). Pemetaannya sama dengan pemetaan antar huruf rilis (misalnya, R) dan versi FCM (misalnya, 5).

Pengujian VTS memberlakukan bahwa perangkat secara eksplisit menentukan versi FCM kernel manifes perangkat, /vendor/etc/vintf/manifest.xml, jika salah satu kondisi berikut terpenuhi:

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

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

Contoh: Menentukan cabang kernel

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

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

Objek VINTF memeriksa kompatibilitas kernel terhadap persyaratan pada kernel 4.19-r , yang ditetapkan dalam FCM versi 5. Persyaratan ini disusun dari kernel/configs/r/android-4.19 dalam hierarki sumber Android.

Contoh: Menentukan 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

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

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

Mencocokkan versi kernel

Matriks dapat mencakup 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} sebagai kernel perangkat (yaitu, version="${ver}.${major_rev}.${matrix_minor_rev}"); bagian lain akan 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 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 FCM kernel, dan versi kernel bersama-sama memilih kernel dari FCM:

Versi FCM targetVersi Kernel FCMVersi kernelCocokkan dengan
3 (P)belum ditetapkan4.4.106 Tidak ada kecocokan (versi minor tidak cocok)
3 (P)belum ditetapkan4.4.107 4.4-p
3 (P)belum ditetapkan4.19.42 4.19-q (lihat catatan di bawah)
3 (P)belum ditetapkan5.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 yang cocok (tidak ada cabang kernel 4.19-p)
3 (P)4 (Kuartal) 4.19.42 4.19-q
4 (Kuartal)belum ditetapkan4.4.107 Tidak ada yang cocok (tidak ada cabang kernel 4.4-q)
4 (Kuartal)belum ditetapkan4.9.165 4.9-q
4 (Kuartal)belum ditetapkan5.4.41 5.4-r (lihat catatan di bawah)
4 (Kuartal)4 (Kuartal) 4.9.165 4.9-q
4 (Kuartal)4 (Kuartal) 5.4.41 Tidak ada yang cocok (tidak ada cabang kernel 5.4-q)
4 (Kuartal)5 (R) 4.14.1054.14-r
4 (Kuartal)5 (R) 5.4.41 5.4-r
5 (R)belum ditetapkanapa pun VTS gagal (Harus menentukan versi FCM kernel untuk FCM target versi 5)
5 (R)4 (Kuartal) apa pun VTS gagal (versi kernel FCM < versi FCM target)
5 (R)5 (R) 4.14.1804.14-r

Mencocokkan konfigurasi kernel

Jika bagian <kernel> cocok, proses akan dilanjutkan dengan mencoba mencocokkan elemen config dengan /proc/config.gz. Untuk setiap elemen konfigurasi dalam kompatibilitas Matriks, mesin mencari /proc/config.gz untuk melihat apakah konfigurasi saat ini. Saat item konfigurasi ditetapkan ke n dalam kompatibilitas matriks untuk bagian <kernel> yang cocok, matriks tersebut harus tidak ada mulai dari /proc/config.gz. Akhirnya, item konfigurasi tidak ada di matriks kompatibilitas mungkin ada atau tidak ada di /proc/config.gz.

Contoh: Mencocokkan konfigurasi kernel

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

Contoh: Pencocokan kernel berhasil

Matriks kompatibilitas framework 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 {i>kernel<i} akan dicocokkan terlebih dahulu. Cabang kernel ditetapkan dalam manifes perangkat di manifest.kernel.target-level, yang default-nya adalah manifest.level jika yang pertama tidak ditentukan. Jika cabang kernel dalam manifes perangkat:

  • adalah 1, melanjutkan ke langkah berikutnya dan memeriksa versi {i>kernel<i}.
  • adalah 2, tidak ada yang cocok dengan matriks. Objek VINTF membaca persyaratan kernel dari matriks di FCM versi 2.

Kemudian, versi {i>kernel<i} akan dicocokkan. Jika perangkat di uname() laporan:

  • 4.9.84 (tidak ada kecocokan dengan matriks kecuali ada bagian kernel terpisah dengan <kernel version="4.9.x">, dengan 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 ada kecocokan dengan matriks kecuali ada bagian {i>kernel<i} yang terpisah dengan <kernel version="4.1.x"> dengan x <= 22)

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

Konfigurasi kernel berikut adalah contoh pencocokan 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 pencocokan 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 mewajibkan kecocokan berikut:

  • <sepolicy-version> menentukan rentang minor tertutup yang berbeda untuk setiap versi utama. Versi sepolicy yang dilaporkan oleh perangkat harus berada dalam salah satu rentang ini agar kompatibel dengan framework. Cocok aturannya mirip dengan versi HAL; cocok jika versi sepolicy tersebut lebih tinggi atau sama dengan versi minimum untuk rentang tersebut. Versi maksimum adalah sepenuhnya bersifat informatif.
  • <kernel-sepolicy-version> yaitu versi policydb. Harus kurang dari security_policyvers() yang dilaporkan oleh perangkat.

Contoh: Kecocokan kebijakan SE yang berhasil

Matriks kompatibilitas framework menyatakan informasi sekebijakan 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 ditampilkan oleh security_policyvers() harus lebih besar dari atau sama dengan 30. Jika tidak, data tersebut tidak cocok. Contoh:
    • Jika perangkat menampilkan 29, itu tidak cocok.
    • Jika perangkat menampilkan 31, nilainya cocok.
  • Versi Kebijakan SE harus salah satu dari 25.0-0 atau 26.0-0. Jika tidak, gambar itu bukan yang cocok. ("-3" setelah "26.0" murni informatif.)

Versi AVB cocok

Versi AVB berisi versi MAJOR dan versi MINOR, dengan format sebagai MAJOR.MINOR (mis., 1.0, 2.1). Untuk mengetahui 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). Fitur ini tidak ada jika kegagalan verifikasi terjadi (atau tidak ada verifikasi yang terjadi).

Kecocokan kompatibilitas membandingkan hal berikut:

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

Bootloader atau Android OS mungkin berisi dua salinan libavb , masing-masing dengan versi MAJOR yang berbeda untuk mengupgrade perangkat dan meluncurkan perangkat. Dalam hal ini, image sistem unsigned yang sama dapat dibagikan, tetapi image sistem akhir yang bertanda tangan akan berbeda (dengan avb.vbmeta-version):

Gambar 1. Kecocokan versi AVB (/sistem adalah P, semua partisi lainnya adalah O).



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

Contoh: Kecocokan versi AVB berhasil

Matriks kompatibilitas framework 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 yang lebih rendah, saat mengupdate ke Android 10, AVB persyaratan versi dalam matriks kompatibilitas framework dicocokkan dengan AVB saat ini versi di perangkat. Jika versi AVB memiliki upgrade versi utama selama OTA (misalnya, dari 0.0 hingga 1.0), pemeriksaan VINTF untuk kompatibilitas di OTA tidak mencerminkan kompatibilitas setelah OTA.

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

  1. Pilih salah satu CL berikut ke hierarki 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. Build ulang paket OTA.

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

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

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

Kecocokan versi VNDK

Matriks kompatibilitas perangkat mendeklarasikan versi VNDK yang diperlukan dalam compatibility-matrix.vendor-ndk.version. Jika perangkat matriks kompatibilitas tidak memiliki tag <vendor-ndk>, tidak diterapkan, sehingga selalu dianggap cocok.

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

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

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

Contoh: Kecocokan versi VNDK 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 framework, 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 framework karena itu, libjpeg.so tidak didukung oleh framework yang tanpa harus membuat snapshot. VNDK versi 26 diabaikan.

Kecocokan versi SDK sistem

Matriks kompatibilitas perangkat mendeklarasikan sekumpulan System SDK yang diperlukan di compatibility-matrix.system-sdk.version. Terdapat hanya cocok jika kumpulan merupakan subset versi SDK Sistem yang disediakan seperti yang dideklarasikan di manifest.system-sdk.version dalam manifes framework.

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

Contoh: Kecocokan versi System SDK berhasil

Jika matriks kompatibilitas perangkat menyatakan persyaratan berikut di Sistem 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 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 diberikan.