Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Aturan pencocokan

Dua pasangan matriks dan manifes kompatibilitas ini harus disesuaikan untuk memverifikasi bahwa framework dan implementasi vendor dapat bekerja sama. Verifikasi ini berhasil jika ada 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 uji kompatibilitas VTS.

Bagian berikut menjelaskan aturan pencocokan yang digunakan oleh berbagai komponen.

Versi matriks kompatibilitas framework yang cocok

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 ada kecocokan.

Jika matriks kompatibilitas framework diminta dengan libvintf, kecocokan ini akan selalu berhasil karena libvintf membuka manifes perangkat, mengambil versi FCM pengiriman, dan menampilkan matriks kompatibilitas framework pada versi FCM pengiriman tersebut (plus beberapa HAL opsional dari matriks kompatibilitas pada versi FCM yang lebih tinggi).

Kecocokan HAL

Aturan kecocokan HAL 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.

Peringatan: Tag optional tidak didukung di Android 16 dan yang lebih tinggi.

Beberapa elemen <version> dalam elemen <hal> yang sama memiliki hubungan ATAU. Jika dua atau lebih ditentukan, hanya salah satu versi yang perlu diterapkan. (Lihat Pencocokan HAL yang berhasil untuk modul DRM.)
Beberapa elemen <instance> dan <regex-instance> dalam elemen <hal> yang sama dievaluasi dengan satu hubungan AND jika <hal> diperlukan. (Lihat Pencocokan HAL yang berhasil untuk modul DRM.)

Contoh: Kecocokan HAL yang berhasil untuk modul

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

Matrix Manifes yang cocok

2.5 2.5-2.∞. Dalam matriks kompatibilitas, 2.5 adalah singkatan untuk 2.5-5.

Matrix	Manifes yang cocok
`2.5`	2.5-2.∞. Dalam matriks kompatibilitas, `2.5` adalah singkatan untuk `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 dapat 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 sebagai informasi dan tidak memengaruhi proses update OTA. Oleh karena itu, perangkat dengan HAL di versi 2.10 dalam file manifesnya tetap kompatibel dengan framework yang menyatakan `2.5-7` dalam matriks kompatibilitasnya.

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 dapat 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 sebagai informasi dan tidak memengaruhi proses update OTA.

Oleh karena itu, perangkat dengan HAL di 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; 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

AND 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

Android dan yang lebih tinggi mendukung versi untuk HAL AIDL di VINTF. Aturan pencocokan untuk HAL AIDL mirip dengan aturan HIDL dan HAL native, kecuali 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 wajib.

Peringatan: Tag optional tidak didukung di Android 16 dan yang lebih tinggi.

Beberapa elemen <instance> dan <regex-instance> dalam <hal> yang sama dievaluasi dengan satu hubungan AND saat <hal> diperlukan. (Lihat Pencocokan HAL yang berhasil untuk beberapa modul.)

Contoh: Kecocokan HAL yang berhasil untuk modul

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

Matrix Manifes yang cocok

5 5-∞. Dalam matriks kompatibilitas, 5 adalah singkatan dari 5-5.

Matrix	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 sebagai informasi dan tidak memengaruhi proses update OTA. Dengan demikian, perangkat dengan HAL di versi 10 dalam file manifesnya tetap kompatibel dengan framework yang menyatakan `5-7` dalam matriks kompatibilitasnya.

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 sebagai informasi dan tidak memengaruhi proses update OTA.

Dengan demikian, perangkat dengan HAL di 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

Pencocokan 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 unik (misalnya, 5). Pemetaan ini sama dengan pemetaan antara huruf rilis (misalnya, R) dan versi FCM (misalnya, 5).

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

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

Catatan: Jika versi FCM kernel sama dengan versi FCM target dan lebih besar dari atau sama dengan 5, file sumber manifes perangkat yang ditentukan oleh DEVICE_MANIFEST_FILE tidak harus menentukan versi FCM kernel. assemble_vintf secara otomatis menyimpulkan versi FCM kernel dari versi FCM target jika versi FCM target lebih besar dari atau sama dengan 5.

Pengujian VTS memastikan 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 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 di cabang kernel 4.19-r, yang ditentukan dalam FCM versi 5. Persyaratan ini dibuat dari kernel/configs/r/android-4.19 di 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 versi kernel 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 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, maka tidak ada kecocokan.

Contoh: Pilih persyaratan untuk pencocokan

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

<!-- 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 target	Versi FCM kernel	Versi kernel	Cocokkan dengan
3 (P)	Tidak Ditentukan	`4.4.106`	Tidak ada kecocokan (ketidakcocokan versi minor)
3 (P)	Tidak Ditentukan	`4.4.107`	`4.4-p`
3 (P)	Tidak Ditentukan	`4.19.42`	`4.19-q` (lihat catatan setelah tabel)
3 (P)	Tidak Ditentukan	`5.4.41`	`5.4-r` (lihat catatan setelah tabel)
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 setelah tabel)
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 (R)	`4.14.105`	`4.14-r`
4 (Q)	5 (R)	`5.4.41`	`5.4-r`
5 (R)	Tidak Ditentukan	apa pun	VTS gagal (harus menentukan versi FCM kernel untuk versi FCM target 5)
5 (R)	4 (Q)	apa pun	VTS gagal (versi FCM kernel < versi FCM target)
5 (R)	5 (R)	`4.14.180`	`4.14-r`

Catatan: Untuk perangkat dengan versi FCM target yang lebih rendah dari 5 (R) dan versi FCM kernel yang tidak ditentukan, objek VINTF memilih cabang kernel dengan akhiran terendah yang lebih besar dari versi FCM target dengan versi kernel yang cocok. Dalam contoh di atas, perangkat dengan versi FCM target 3 (P) menggunakan cabang kernel 4.19-q karena 4.19-q memiliki akhiran terendah di antara semua cabang kernel 4.19-*, [4.19-q, 4.19-r, 4.19-s]. Perilaku pemilihan persyaratan ini tidak diizinkan untuk perangkat dengan versi FCM target 5 (R) atau yang lebih tinggi, karena versi FCM kernel harus ditentukan.

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 tersebut 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> matches "bar". Tanda kutip dihilangkan dalam matriks kompatibilitas, tetapi ada di /proc/config.gz.
<value type="int">4096</value> cocok dengan 4096, 0x1000, atau 0X1000.
<value type="int">0x1000</value> cocok dengan 4096, 0x1000, atau 0X1000.
<value type="int">0X1000</value> cocok dengan 4096, 0x1000, atau 0X1000.
<value type="tristate">y</value> matches y.
<value type="tristate">m</value> matches m.
<value type="tristate">n</value> berarti item config 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 kernel dicocokkan terlebih dahulu. Cabang kernel ditentukan dalam manifes perangkat di manifest.kernel.target-level, yang secara default adalah manifest.level jika yang pertama tidak ditentukan:

Jika cabang kernel dalam manifes perangkat adalah 1, proses akan dilanjutkan ke langkah berikutnya dan memeriksa versi kernel.
Jika cabang kernel dalam manifes perangkat adalah 2, tidak ada kecocokan dengan matriks. Objek VINTF membaca persyaratan kernel dari matriks pada FCM versi 2.

Kemudian, versi kernel 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">, dengan x <= 22)

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

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

SEPolicy memerlukan kecocokan berikut:

<sepolicy-version> menentukan rentang tertutup versi minor untuk setiap versi mayor. Versi SEPolicy yang dilaporkan oleh perangkat harus termasuk dalam salah satu rentang ini agar kompatibel dengan framework. Aturan pencocokan serupa dengan versi HAL; ini cocok jika versi SEPolicy lebih tinggi atau sama dengan versi minimum untuk rentang tersebut. Versi maksimum hanya untuk informasi.
<kernel-sepolicy-version>, yaitu versi Policy DB, harus lebih kecil dari security_policyvers() yang dilaporkan oleh perangkat.

Contoh: Kecocokan SEPolicy 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, itu bukan kecocokan. Contoh:
- Jika perangkat menampilkan 29, berarti tidak cocok.
- Jika perangkat menampilkan 31, berarti cocok.
Versi SEPolicy harus salah satu dari 25.0-∞ atau 26.0-∞. Jika tidak, versi tersebut tidak cocok. (-3 setelah 26.0 hanya bersifat informatif.)

Kecocokan versi AVB

Versi AVB berisi versi UTAMA dan versi SEKUNDER, dengan format sebagai MAJOR.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 saat libavb yang sesuai telah digunakan untuk memverifikasi metadata AVB (dan menampilkan OK). 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 UTAMA yang berbeda untuk perangkat upgrade dan perangkat peluncuran. Dalam hal ini, image sistem tanpa tanda tangan 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. Pencocokan 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 rendah, saat mengupdate ke Android 10, persyaratan versi AVB dalam matriks kompatibilitas framework 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:

Pilih CL berikut ke pohon sumber Android 9:
- CL 732261
- CL 732262
Tentukan BOARD_OTA_FRAMEWORK_VBMETA_VERSION_OVERRIDE untuk perangkat. Nilainya harus sama dengan versi AVB sebelum OTA, yaitu versi AVB perangkat saat diluncurkan.
Bangun 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 digunakan untuk pemeriksaan kompatibilitas.

Pencocokan versi VNDK

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

Jika matriks kompatibilitas perangkat memiliki tag <vendor-ndk>, entri <vendor-ndk> dengan <version> yang cocok akan dicari dari set snapshot vendor VNDK yang disediakan oleh framework dalam manifes framework. Jika entri tersebut tidak ada, tidak ada kecocokan.

Jika entri tersebut ada, kumpulan library yang tercantum 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 tercantum 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 di 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.

Versi SDK sistem cocok

Matriks kompatibilitas perangkat mendeklarasikan serangkaian versi SDK sistem yang diperlukan di compatibility-matrix.system-sdk.version. Hanya ada kecocokan jika set adalah subset dari versi SDK sistem yang disediakan seperti yang dideklarasikan di manifest.system-sdk.version dalam manifes framework.

Sebagai kasus khusus, jika tidak ada versi SDK sistem yang tercantum dalam matriks kompatibilitas perangkat, maka selalu dianggap cocok, karena set kosong adalah subset dari set apa pun.

Contoh: Versi SDK sistem berhasil dicocokkan

Jika matriks kompatibilitas perangkat menyatakan persyaratan berikut di SDK Sistem:

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

Kemudian, framework harus menyediakan SDK sistem versi 26 dan 27 agar cocok:

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

Contoh A cocok:

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

Contoh B cocok:

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

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

Aturan pencocokan Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Versi matriks kompatibilitas framework yang cocok

Kecocokan HAL

HIDL dan HAL native

Contoh: Kecocokan HAL yang berhasil untuk modul

Contoh: Pencocokan HAL yang berhasil untuk modul DRM

HAL AIDL

Contoh: Kecocokan HAL yang berhasil untuk modul

Contoh: Kecocokan HAL yang berhasil untuk beberapa modul

Pencocokan kernel

Mencocokkan cabang kernel

Contoh: Menentukan cabang kernel

Contoh: Menentukan cabang kernel untuk GKI

Mencocokkan versi kernel

Contoh: Pilih persyaratan untuk pencocokan

Mencocokkan konfigurasi kernel

Contoh: Mencocokkan konfigurasi kernel

Contoh: Pencocokan kernel yang berhasil

Kecocokan SEPolicy

Contoh: Kecocokan SEPolicy yang berhasil

Kecocokan versi AVB

Contoh: Pencocokan versi AVB yang berhasil

Mencocokkan versi AVB selama OTA

Pencocokan versi VNDK

Contoh: Pencocokan versi VNDK yang berhasil

Versi SDK sistem cocok

Contoh: Versi SDK sistem berhasil dicocokkan

Aturan pencocokan