Ringkasan Vendor Native Development Kit (VNDK)

Vendor Native Development Kit (VNDK) adalah sekumpulan library yang digunakan oleh library atau biner lain, di partisi vendor atau produk, pada runtime untuk dlopen.

Penghentian penggunaan

Vendor NDK diperkenalkan di Android 8.0 untuk menyediakan API antara framework dan kode vendor. Meskipun telah berhasil digunakan selama bertahun-tahun, VNDK memiliki beberapa kekurangan:
  • Penyimpanan
    • Satu paket APEX VNDK mengemas semua library VNDK, baik digunakan dari perangkat maupun tidak.
    • GSI berisi beberapa versi APEX VNDK untuk mendukung beberapa versi image vendor.
  • Kemampuan Update
    • Sulit untuk mengupdate APEX VNDK secara terpisah dari update platform.
    • Image vendor sering diupdate over the air (OTA), sehingga mengurangi manfaat pengemasan VNDK dalam image sistem.
Berdasarkan masalah ini, kami memutuskan untuk menghentikan penggunaan VNDK mulai dari Android 15.

Detail penghentian penggunaan VNDK

Semua library VNDK dikemas ke dalam VNDK APEX, dan diinstal dalam image sistem (-ext). Dengan penghentian penggunaan VNDK, library VNDK sebelumnya diinstal di image vendor (atau produk), sama seperti library lain yang tersedia untuk vendor. Fitur ini dihapus bersama dengan penghentian penggunaan VNDK:
  • VNDK APEX untuk Android 15
  • Properti sistem yang menunjukkan versi VNDK target dihapus jika partisi vendor atau produk dibangun untuk Android 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • Pengoptimalan VNDK tidak akan tersedia karena tidak ada VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT untuk perangkat Android Go
    • use_vndk_as_stable untuk APEX Vendor
  • Snapshot vendor, yang sangat bergantung pada VNDK

Pengecualian dari penghentian penggunaan

Fitur ini tidak akan berubah dengan penghentian penggunaan VNDK:
  • APEX VNDK dengan VNDK versi 14 atau yang lebih rendah, yang diperlukan untuk mendukung image vendor yang ada.
  • LL-NDK bukan bagian dari VNDK.

Mengapa VNDK?

AOSP memungkinkan update khusus framework yang memungkinkan partisi sistem diupgrade ke versi framework terbaru, sementara partisi vendor tidak berubah. Meskipun dibangun pada waktu yang berbeda, biner di setiap partisi harus dapat bekerja sama.

Update khusus framework mencakup tantangan berikut:

  • Dependensi antara modul framework dan modul vendor. Sebelum Android 8.0, modul di partisi vendor dan sistem dapat ditautkan satu sama lain. Namun, dependensi dari modul vendor membatasi pengembangan modul framework secara tidak diinginkan.
  • Ekstensi ke library AOSP. Android mewajibkan semua perangkat Android lulus CTS saat partisi sistem diganti dengan Generic System Image (GSI) standar. Namun, saat vendor memperluas library AOSP untuk meningkatkan performa atau menambahkan fungsi ekstra untuk penerapan HIDL mereka, mem-flash partisi sistem dengan GSI standar dapat merusak penerapan HIDL vendor. Untuk mengetahui panduan tentang cara mencegah kerusakan tersebut, lihat Ekstensi VNDK.

Untuk mengatasi tantangan ini, Android berisi beberapa fitur seperti VNDK (dijelaskan di bagian ini), HIDL, hwbinder, overlay pohon perangkat, dan overlay sepolicy.

Persyaratan khusus VNDK

Dokumen terkait VNDK menggunakan terminologi berikut:
  • Modul mengacu pada library bersama atau executable. Modul membuat dependensi waktu build.
  • Proses adalah tugas sistem operasi yang dihasilkan dari file yang dapat dieksekusi. Proses membuat dependensi waktu proses.
  • Istilah yang memenuhi syarat framework terkait dengan partisi system:
    • File yang dapat dieksekusi framework mengacu pada file yang dapat dieksekusi di /system/bin atau /system/xbin.
    • Library bersama framework mengacu pada library bersama di bagian /system/lib[64].
    • Modul framework mengacu pada library bersama framework dan file executable framework.
    • Proses framework adalah proses yang dihasilkan dari file yang dapat dieksekusi framework, seperti /system/bin/app_process.
  • Istilah yang memenuhi syarat vendor terkait dengan partisi vendor:
    • File yang dapat dieksekusi vendor mengacu pada file yang dapat dieksekusi di /vendor/bin
    • Library bersama vendor mengacu pada library bersama di bagian /vendor/lib[64].
    • Modul vendor mengacu pada file executable vendor dan library bersama vendor.
    • Proses vendor adalah proses yang dihasilkan dari Vendor Executables, seperti /vendor/bin/android.hardware.camera.provider@2.4-service.

Konsep VNDK

Dalam dunia Android 8.0 dan yang lebih tinggi yang ideal, proses framework tidak memuat library bersama vendor, semua proses vendor hanya memuat library bersama vendor (dan sebagian library bersama framework), dan komunikasi antara proses framework dan proses vendor diatur oleh HIDL dan binder hardware.

Dunia seperti itu mencakup kemungkinan bahwa API publik yang stabil dari library bersama framework mungkin tidak cukup untuk developer modul vendor (meskipun API dapat berubah di antara rilis Android), sehingga mengharuskan sebagian library bersama framework dapat diakses oleh proses vendor. Selain itu, karena persyaratan performa dapat menyebabkan kompromi, beberapa HAL yang penting untuk waktu respons harus ditangani secara berbeda.

Bagian berikut menjelaskan cara VNDK menangani library bersama framework untuk vendor dan HAL Proses yang Sama (SP-HAL).

Library bersama framework untuk vendor

Bagian ini menjelaskan kriteria untuk mengklasifikasikan library bersama yang dapat diakses oleh proses vendor. Ada dua pendekatan untuk mendukung modul vendor di beberapa rilis Android:

  1. Menstabilkan ABI/API library bersama framework. Modul framework baru dan modul vendor lama dapat menggunakan library bersama yang sama untuk mengurangi jejak memori dan ukuran penyimpanan. Library bersama yang unik juga menghindari beberapa masalah pemuatan ganda. Namun, biaya pengembangan untuk mempertahankan ABI/API yang stabil sangat tinggi dan tidak realistis untuk menstabilkan semua ABI/API yang diekspor oleh setiap library bersama framework.
  2. Salin library bersama framework lama. Dilengkapi dengan batasan ketat terhadap saluran samping, yang didefinisikan sebagai semua mekanisme untuk berkomunikasi di antara modul framework dan modul vendor, termasuk (tetapi tidak terbatas pada) binder, socket, pipe, memori bersama, file bersama, dan properti sistem. Tidak boleh ada komunikasi kecuali jika protokol komunikasi dibekukan dan stabil (misalnya, HIDL melalui hwbinder). Memuat library bersama dua kali juga dapat menyebabkan masalah; misalnya, jika objek yang dibuat oleh library baru diteruskan ke fungsi dari library lama, error dapat terjadi karena library ini dapat menafsirkan objek secara berbeda.

Pendekatan yang berbeda digunakan bergantung pada karakteristik library bersama. Akibatnya, library bersama framework diklasifikasikan ke dalam tiga subkategori:

  • Library LL-NDK adalah Library Bersama Framework yang diketahui stabil. Developer mereka berkomitmen untuk menjaga stabilitas API/ABI mereka.
    • LL-NDK mencakup library berikut: libEGL.so, libGLESv1_CM.so, libGLESv2.so, libGLESv3.so, libandroid_net.so, libc.so, libdl.so, liblog.so, libm.so, libnativewindow.so, libneuralnetworks.so, libsync.so, libvndksupport.so, dan libvulkan.so,
  • Library VNDK yang Memenuhi Syarat (VNDK) adalah Library Bersama Framework yang aman untuk disalin dua kali. Modul Framework dan Modul Vendor dapat ditautkan dengan salinannya sendiri. Library bersama framework dapat menjadi library VNDK yang memenuhi syarat hanya jika memenuhi kriteria berikut:
    • Tidak mengirim/menerima IPC ke/dari framework.
    • Tidak terkait dengan mesin virtual ART.
    • Tidak membaca/menulis file/partisi dengan format file yang tidak stabil.
    • Tidak memiliki lisensi software khusus yang memerlukan peninjauan hukum.
    • Pemilik kodenya tidak keberatan dengan penggunaan vendor.
  • Library Khusus Framework (FWK-ONLY) adalah Library Bersama Framework yang tidak termasuk dalam kategori yang disebutkan di atas. Library ini:
    • Dianggap sebagai detail implementasi internal framework.
    • Tidak boleh diakses oleh modul vendor.
    • Memiliki ABI/API yang tidak stabil dan tidak ada jaminan kompatibilitas API/ABI.
    • Tidak disalin.

HAL Proses yang Sama (SP-HAL)

HAL Proses Sama (SP-HAL) adalah sekumpulan HAL yang telah ditentukan sebelumnya yang diimplementasikan sebagai Library Bersama Vendor dan dimuat ke dalam Proses Framework. SP-HAL diisolasi oleh namespace linker (mengontrol library dan simbol yang terlihat oleh library bersama). SP-HAL hanya boleh bergantung pada LL-NDK dan VNDK-SP.

VNDK-SP adalah subset library VNDK yang memenuhi syarat yang telah ditentukan sebelumnya. Library VNDK-SP ditinjau dengan cermat untuk memastikan pemuatan ganda library VNDK-SP ke dalam proses framework tidak menyebabkan masalah. SP-HAL dan VNDK-SP ditentukan oleh Google.

Library berikut adalah SP-HAL yang disetujui:

  • libGLESv1_CM_${driver}.so
  • libGLESv2_${driver}.so
  • libGLESv3_${driver}.so
  • libEGL_${driver}.so
  • vulkan.${driver}.so
  • android.hardware.renderscript@1.0-impl.so
  • android.hardware.graphics.mapper@2.0-impl.so

Library VNDK-SP menentukan vndk: { support_system_process: true } dalam file Android.bp-nya. Jika vndk: {private:true} juga ditentukan, library ini disebut VNDK-SP-Private dan tidak terlihat oleh SP-HAL.

Berikut adalah library khusus framework dengan pengecualian RS (FWK-ONLY-RS):

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

Pembuatan versi VNDK

Library bersama VNDK diberi versi:

  • Properti sistem ro.vndk.version otomatis ditambahkan ke /vendor/default.prop.
  • Library bersama VNDK dan VNDK-SP diinstal sebagai APEX VNDK com.android.vndk.v${ro.vndk.version} dan di-mount ke /apex/com.android.vndk.v${ro.vndk.version}.

Nilai ro.vndk.version dipilih oleh algoritma di bawah:

  • Jika BOARD_VNDK_VERSION tidak sama dengan current, gunakan BOARD_VNDK_VERSION.
  • Jika BOARD_VNDK_VERSION sama dengan current:
    • Jika PLATFORM_VERSION_CODENAME adalah REL, gunakan PLATFORM_SDK_VERSION (misalnya, 28).
    • Jika tidak, gunakan PLATFORM_VERSION_CODENAME (misalnya, P).

Vendor Test Suite (VTS)

Android Vendor Test Suite (VTS) mewajibkan properti ro.vndk.version yang tidak kosong. Perangkat yang baru diluncurkan dan perangkat yang diupgrade harus menentukan ro.vndk.version. Beberapa kasus pengujian VNDK (misalnya, VtsVndkFilesTest dan VtsVndkDependencyTest) mengandalkan properti ro.vndk.version untuk memuat set data library VNDK yang memenuhi syarat dan cocok.