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. (LihatContoh 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-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 >= 0ATAU
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. (Lihatcontoh 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-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 dengan4096
atau0x1000
atau0X1000
. -
<value type="int">0x1000</value>
cocok dengan4096
atau0x1000
atau0X1000
. -
<value type="int">0X1000</value>
cocok dengan4096
atau0x1000
atau0X1000
. -
<value type="tristate">y</value>
cocok dengany
. -
<value type="tristate">m</value>
cocok denganm
. -
<value type="tristate">n</value>
berarti item konfigurasi TIDAK boleh ada di/proc/config.gz
. -
<value type="range">1-0x3</value>
cocok dengan1
,2
, atau3
, 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 manax <= 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 manax <= 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 darisecurity_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 versilibavb
di bootloader -
ro.boot.avb_version
adalah versilibavb
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
denganavb.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
denganavb.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):
/system
adalah P, semua partisi lainnya adalah O).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 matchl10n-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:
- Pilih CL berikut ke pohon sumber Android 9:
- Tentukan
BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE
untuk perangkat. Nilainya harus sama dengan versi AVB sebelum OTA, yaitu versi AVB perangkat saat diluncurkan. - 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
dicompatibility.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.