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

NDK Vendor diperkenalkan di Android 8.0 untuk menyediakan API antara framework dan kode vendor. Meskipun VNDK telah berhasil digunakan selama bertahun-tahun, VNDK memiliki beberapa kelemahan:

• Penyimpanan
• Satu VNDK APEX memaketkan semua library VNDK, baik yang digunakan dari perangkat maupun tidak.
• GSI berisi beberapa versi VNDK APEX untuk mendukung beberapa versi image vendor.
• Kemampuan update
• Sulit untuk mengupdate VNDK APEX secara terpisah dari update platform.
• Image vendor sering diperbarui secara over the air (OTA), sehingga mengurangi manfaat dari VNDK yang dipaketkan dalam image sistem.

Berdasarkan masalah ini, kami memutuskan untuk menghentikan penggunaan VNDK mulai Android 15.

Detail tentang penghentian VNDK

Semua library VNDK dikemas ke dalam VNDK APEX, dan diinstal dalam image sistem (-ext). Dengan penghentian VNDK, library VNDK sebelumnya diinstal dalam image vendor (atau produk), sama seperti library lain yang tersedia oleh vendor. Fitur ini dihapus bersama dengan penghentian penggunaan VNDK:

• VNDK APEX untuk Android 15
• Properti sistem yang menunjukkan versi VNDK target akan dihapus jika partisi vendor atau produk dibuat 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

Fitur-fitur ini tidak akan berubah selama penggunaan VNDK:

• VNDK APEX dengan VNDK versi 14 atau lebih rendah, yang diperlukan untuk mendukung image vendor yang ada.
• LL-NDK bukan bagian dari VNDK.

Mengapa VNDK?

AOSP memungkinkan update khusus framework, yaitu partisi sistem dapat diupgrade ke versi framework terbaru, sedangkan partisi vendor tidak diubah. Meskipun di-build pada waktu yang berbeda, biner di setiap partisi harus dapat berfungsi satu sama lain.

Update khusus framework mencakup tantangan berikut:

• Dependensi antara modul framework dan modul vendor. Sebelum Android 8.0, modul di partisi vendor dan sistem dapat saling menautkan. Namun, dependensi dari modul vendor memberlakukan pembatasan yang tidak diinginkan pada pengembangan modul framework.
• Ekstensi ke library AOSP. Android memerlukan semua perangkat Android untuk lulus CTS saat partisi sistem diganti dengan Generic System Image (GSI) standar. Namun, karena vendor memperluas library AOSP untuk meningkatkan performa atau menambahkan fungsi tambahan untuk implementasi HIDL mereka, melakukan flash partisi sistem dengan GSI standar dapat merusak implementasi HIDL vendor. Untuk panduan tentang cara mencegah kerusakan tersebut, lihat ekstensi VNDK.

Untuk mengatasi tantangan ini, Android menyediakan beberapa fitur seperti VNDK (dijelaskan di bagian ini), HIDL, hwbinder, overlay hierarki perangkat, dan overlay kebijakan.

Persyaratan khusus VNDK

Dokumen terkait VNDK menggunakan terminologi berikut:

• Modul mengacu pada library bersama atau file yang dapat dieksekusi. 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 merujuk ke file yang dapat dieksekusi di /system/bin atau /system/xbin.
• Library bersama framework merujuk ke library bersama di /system/lib[64].
• Modul framework mengacu pada library bersama framework dan file yang dapat dieksekusi framework.
• Proses framework adalah proses yang dihasilkan dari file yang dapat dieksekusi framework, seperti /system/bin/app_process.
• Persyaratan yang memenuhi syarat vendor terkait dengan partisi vendor:
• File yang dapat dieksekusi vendor merujuk ke file yang dapat dieksekusi di /vendor/bin
• Library bersama vendor merujuk ke library bersama di /vendor/lib[64].
• Modul vendor mengacu pada file yang dapat dieksekusi vendor dan library bersama vendor.
• Proses vendor adalah proses yang dihasilkan dari Executable Vendor, seperti /vendor/bin/android.hardware.camera.provider@2.4-service.

Catatan: Generic System Image (GSI) adalah singkatan dari image sistem Android standar yang dibuat dari cabang yang sesuai (mirip dengan cabang rilis, tetapi dengan beberapa perbaikan bug atau beberapa generalisasi) dan dirilis oleh Google.

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 memadai bagi developer modul vendor (meskipun API dapat berubah di antara rilis Android), yang mengharuskan sebagian library bersama framework dapat diakses oleh proses vendor. Selain itu, karena persyaratan performa dapat menyebabkan kompromi, beberapa HAL kritis waktu respons harus diperlakukan 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 tinggi dan tidak realistis untuk menstabilkan semua ABI/API yang diekspor oleh setiap library bersama framework.
2. Menyalin library bersama framework lama. Dilengkapi dengan pembatasan yang kuat terhadap saluran samping, yang didefinisikan sebagai semua mekanisme untuk berkomunikasi di antara modul framework dan modul vendor, termasuk (tetapi tidak terbatas pada) binder, soket, pipa, memori bersama, file bersama, dan properti sistem. Tidak boleh ada komunikasi kecuali jika protokol komunikasi dibekukan dan stabil (misalnya, HIDL melalui hwbinder). Memuat dua kali library bersama dapat menyebabkan masalah juga; misalnya, jika objek yang dibuat oleh library baru diteruskan ke fungsi dari library lama, error dapat terjadi karena library ini mungkin menafsirkan objek secara berbeda.

Pendekatan yang berbeda digunakan bergantung pada karakteristik library umum. Oleh karena itu, library bersama framework diklasifikasikan menjadi tiga sub-kategori:

• Library LL-NDK adalah Library Bersama Framework yang diketahui stabil. Developer mereka berkomitmen untuk mempertahankan kestabilan API/ABI mereka.
  • LL-NDK menyertakan 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 (VNDK) yang memenuhi syarat 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:
  • Fungsi ini tidak mengirim/menerima IPC ke/dari framework.
  • Hal ini tidak terkait dengan virtual machine ART.
  • File/partisi dengan format file yang tidak stabil tidak akan dibaca/ditulis.
  • Aplikasi ini 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 yang Sama (SP-HAL) adalah kumpulan HAL yang telah ditentukan sebelumnya yang diimplementasikan sebagai Library Bersama Vendor dan dimuat ke dalam Proses Framework. SP-HAL diisolasi oleh namespace penaut (mengontrol library dan simbol yang terlihat oleh library bersama). SP-HAL hanya boleh bergantung pada LL-NDK dan VNDK-SP.

VNDK-SP adalah subset yang telah ditentukan sebelumnya dari library VNDK yang memenuhi syarat. 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
• [e-mail]
• [e-mail]

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

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

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

Perhatian: Mulai dari Android 12, RenderScript API tidak digunakan lagi. API ini akan terus berfungsi, tetapi produsen perangkat dan komponen diperkirakan akan berhenti menyediakan dukungan akselerasi hardware seiring waktu. Untuk memanfaatkan akselerasi GPU secara optimal, AOSP merekomendasikan agar Anda Bermigrasi dari 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 com.android.vndk.v${ro.vndk.version} apex VNDK dan dipasang 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 cocok dan memenuhi syarat.