Aturan pencocokan

Dua pasangan matriks dan manifes kompatibilitas dimaksudkan untuk disesuaikan untuk memverifikasi bahwa implementasi framework dan vendor dapat bekerja sama. Verifikasi ini berhasil setelah kecocokan antara matriks kompatibilitas framework dan manifes perangkat, serta antara manifes framework dan matriks kompatibilitas perangkat.

Verifikasi ini dilakukan pada waktu build, pada waktu pembuatan paket update OTA, pada waktu booting, dan dalam pengujian 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 Pengiriman FCM yang ditentukan oleh manifest.target-level harus sama persis dengan versi FCM yang ditentukan oleh compatibility-matrix.level. Jika tidak, tidak akan ada kecocokan.

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

Kecocokan HAL

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

HIDL dan HAL native

Aturan pencocokan untuk HIDL dan HAL native adalah sebagai berikut.

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

Contoh: Kecocokan HAL yang berhasil untuk modul

Untuk HAL versi 2.5, aturan pencocokan 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, yang berarti manifes yang menyediakan HAL 2.0-2.4 tidak kompatibel.
  • 2.7 adalah versi maksimum yang dapat diminta, yang berarti pemilik matriks kompatibilitas (framework 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 matriks kompatibilitas hanya mengetahui bahwa layanan yang diminta kompatibel dengan API versi 2.7.
  • -7 hanya bersifat informasi dan tidak memengaruhi proses update OTA.
Dengan demikian, perangkat dengan HAL versi 2.10 dalam file manifesnya tetap kompatibel dengan framework yang menyatakan 2.5-7 dalam matriks kompatibilitasnya.

Contoh: Pencocokan 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;

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

HAL AIDL

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

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

Contoh: Kecocokan HAL yang berhasil untuk modul

Untuk HAL versi 5, aturan kecocokannya 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, yang berarti manifes yang menyediakan HAL 1-4 tidak kompatibel.
  • 7 adalah versi maksimum yang dapat diminta, yang berarti pemilik matriks kompatibilitas (framework atau perangkat) tidak akan meminta versi di luar 7. Pemilik manifes yang cocok masih dapat menayangkan versi 10 (sebagai contoh) saat 7 diminta. Pemilik matriks kompatibilitas hanya mengetahui bahwa layanan yang diminta kompatibel dengan API versi 7.
  • -7 hanya bersifat informasi dan tidak memengaruhi proses update OTA.
Dengan demikian, perangkat dengan HAL versi 10 dalam file manifesnya tetap kompatibel dengan framework yang menyatakan 5-7 dalam matriks kompatibilitasnya.

Contoh: Kecocokan HAL yang berhasil untuk beberapa modul

Matriks kompatibilitas framework menyatakan informasi versi berikut untuk HAL vibrator dan 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 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

Kecocokan kernel

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

Mencocokkan cabang kernel

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

Pengujian VTS menetapkan bahwa perangkat secara eksplisit menentukan versi FCM kernel dalam 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 target FCM versi 4, dan versi FCM kernel-nya adalah 5 (akhiran cabang kernel r).
  • Versi FCM kernel lebih besar dari atau sama dengan 5 (akhiran cabang kernel r).

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

Contoh: Menentukan cabang kernel

Jika perangkat memiliki FCM target 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 di cabang kernel 4.19-r, yang ditentukan dalam FCM versi 5. Persyaratan ini dibuat 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

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

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

Mencocokkan 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 dengan kernel perangkat (yaitu, version="${ver}.${major_rev}.${matrix_minor_rev}"); bagian lainnya akan 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, maka revisi itu tidak cocok.

Contoh: Pilih persyaratan untuk pencocokan

Pertimbangkan kasus hipotetis berikut saat 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 persyaratan kernel dari FCM:

Versi FCM targetVersi FCM kernelVersi kernelCocokkan dengan
3 (P)belum ditetapkan4.4.106 Tidak ada kecocokan (ketidakcocokan versi minor)
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 (Q)belum ditetapkan4.4.107 Tidak ada kecocokan (tidak ada cabang kernel 4.4-q)
4 (Q)belum ditetapkan4.9.165 4.9-q
4 (Q)belum ditetapkan5.4.41 5.4-r (lihat catatan di bawah)
4 (Kuartal)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 (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 target FCM versi 5)
5 (R)4 (Q) apa pun VTS gagal (versi FCM kernel < 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 matriks kompatibilitas, elemen ini akan mencari /proc/config.gz untuk melihat apakah konfigurasi ada. Jika item konfigurasi ditetapkan ke n dalam matriks kompatibilitas untuk bagian <kernel> yang cocok, item tersebut tidak boleh ada di /proc/config.gz. Terakhir, item konfigurasi yang tidak ada dalam matriks kompatibilitas mungkin ada atau tidak ada di /proc/config.gz.

Contoh: Mencocokkan konfigurasi kernel

  • <value type="string">bar</value> cocok dengan "bar". Tanda kutip 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 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 ditentukan dalam manifes perangkat di manifest.kernel.target-level, yang secara default ditetapkan ke manifest.level jika yang pertama tidak ditentukan. Jika cabang kernel dalam 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.

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

  • 4.9.84 (tidak cocok dengan matriks kecuali jika 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 cocok dengan matriks kecuali jika ada bagian kernel terpisah dengan <kernel version="4.1.x"> tempat x <= 22)

Setelah bagian <kernel> yang sesuai dipilih, untuk setiap item <config> dengan nilai selain n, kami mengharapkan entri yang sesuai ada di /proc/config.gz; untuk setiap item <config> dengan nilai n, kami memperkirakan entri yang sesuai 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 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 tidak berhasil:

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> menentukan rentang tertutup versi minor untuk setiap versi utama. Versi sepolicy yang dilaporkan oleh perangkat harus berada dalam salah satu rentang ini agar kompatibel dengan framework. Aturan pencocokan mirip dengan versi HAL; kecocokan terjadi jika versi sepolicy lebih tinggi atau sama dengan versi minimum untuk rentang. Versi maksimum hanya 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 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 ditampilkan oleh security_policyvers() harus lebih besar dari atau sama dengan 30. Jika tidak, artinya tidak cocok. Contoh:
    • Jika perangkat menampilkan 29, itu tidak cocok.
    • Jika perangkat menampilkan 31, berarti perangkat tersebut cocok.
  • Versi Kebijakan SE harus salah satu dari 25.0-0 atau 26.0-0. Jika tidak, versi tersebut tidak cocok. ("-3" setelah "26.0" hanya bersifat informatif.)

Kecocokan versi AVB

Versi AVB berisi versi UTAMA dan versi MINOR, dengan format sebagai UTAMA.MINOR (misalnya, 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 Android OS (init/fs_mgr)

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

Pencocokan 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 library libavb, masing-masing dengan versi MAJOR yang berbeda untuk mengupgrade perangkat dan perangkat peluncuran. Dalam hal ini, image sistem unsigned 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. Kecocokan versi AVB (semua partisi adalah P).

Contoh: Pencocokan versi AVB yang 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 lama, saat mengupdate ke Android 10, persyaratan versi AVB dalam matriks kompatibilitas framework akan dicocokkan dengan versi AVB saat ini di perangkat. Jika versi AVB memiliki upgrade 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. Pilih 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 dalam 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 /system/etc/vintf/compatibility_matrix.xml akan digunakan untuk pemeriksaan kompatibilitas.

Pencocokan versi VNDK

Matriks kompatibilitas perangkat mendeklarasikan versi VNDK yang diperlukan di compatibility-matrix.vendor-ndk.version. Jika matriks kompatibilitas perangkat tidak memiliki tag <vendor-ndk>, tidak ada persyaratan yang diberlakukan, 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 framework dalam manifes framework. Jika entri tersebut tidak ada, tidak ada kecocokan.

Jika entri tersebut memang ada, kumpulan library yang dihitung dalam matriks kompatibilitas perangkat harus merupakan subset dari kumpulan library yang dinyatakan dalam manifes framework; jika tidak, entri tersebut tidak dianggap cocok.

  • Sebagai kasus khusus, jika tidak ada library yang dihitung dalam matriks kompatibilitas perangkat, entri selalu dianggap cocok, karena set kosong adalah subset dari set apa 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 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 manifes framework, libjpeg.so tidak didukung oleh framework dalam snapshot tersebut. VNDK versi 26 diabaikan.

Kecocokan versi SDK sistem

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

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

Contoh: Kecocokan versi SDK Sistem yang berhasil

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

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