Ringkasan Vendor Native Development Kit (VNDK)

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

Mengapa VNDK?

AOSP memungkinkan update khusus framework di mana partisi sistem dapat diupgrade ke versi terbaru sementara versi framework sementara tidak berubah. Meskipun dibuat dengan sekali, sistem biner di setiap partisi harus dapat saling bekerja sama.

Update khusus framework mencakup tantangan berikut:

  • Dependensi antara modul framework dan modul vendor. Sebelum Android 8.0, modul di partisi sistem dan vendor dapat saling terhubung satu sama lain. Namun, dependensi dari modul vendor yang diberlakukan tidak diinginkan pembatasan pengembangan modul framework.
  • Ekstensi ke library AOSP. Android mengharuskan semua perangkat Android lulus CTS saat partisi sistem diganti dengan Generic System Image (GSI) standar. Namun, karena vendor memperluas AOSP library untuk meningkatkan performa atau menambahkan fungsi tambahan untuk HIDL-nya implementasi, mem-flash partisi sistem dengan GSI standar dapat merusak implementasi HIDL vendor. Untuk panduan tentang mencegah kerusakan tersebut, lihat Ekstensi VNDK.

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

Persyaratan khusus VNDK

Dokumen terkait VNDK menggunakan terminologi berikut:
  • Modul mengacu pada library bersama atau file yang dapat dieksekusi. Modul membuat waktu build dependensi.
  • Proses adalah tugas sistem operasi yang muncul dari file yang dapat dieksekusi. Proses membuat {i>run-time<i} dependensi.
  • Persyaratan yang memenuhi syarat framework terkait dengan partisi system:
    • Framework yang dapat dieksekusi merujuk ke file yang dapat dieksekusi di /system/bin atau /system/xbin.
    • Framework bersama library mengacu pada library bersama di /system/lib[64].
    • Modul framework merujuk ke kedua library bersama framework dan file framework yang dapat dieksekusi.
    • Proses framework adalah proses yang berasal dari framework file yang dapat dieksekusi, 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 adalah file yang dapat dieksekusi oleh vendor dan library bersama vendor.
    • Proses vendor adalah proses yang berasal dari Vendor Dapat dieksekusi, seperti /vendor/bin/android.hardware.camera.provider@2.4-service.

Konsep VNDK

Di Android 8.0 dan versi yang lebih tinggi ideal, proses framework tidak dimuat pustaka bersama vendor, semua proses vendor hanya memuat pustaka bersama vendor (dan sebagian dari pustaka bersama kerangka kerja), dan komunikasi antara proses framework dan proses vendor diatur oleh HIDL dan hardware {i>binder<i}.

Hal tersebut mencakup kemungkinan bahwa API publik yang stabil dari {i>shared library<i} bersama kerangka kerja mungkin tidak cukup untuk pengembang modul vendor (meskipun API dapat berubah antar-rilis Android), mengharuskan beberapa bagian {i>framework<i} bersama {i>framework<i} dapat diakses oleh proses vendor. Selain itu, sebagai persyaratan performa dapat berkompromi, beberapa respons yang HAL 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 pustaka bersama yang dapat diakses oleh proses vendor. Ada dua pendekatan untuk mendukung vendor di beberapa rilis Android:

  1. Stabilkan ABI/API library bersama framework. Modul kerangka kerja baru dan modul vendor lama dapat menggunakan pustaka bersama yang sama untuk mengurangi jejak memori dan ukuran penyimpanan. Pustaka bersama yang unik juga menghindari beberapa masalah pemuatan ganda. Namun, biaya pengembangan untuk menjaga kestabilan ABI/API memiliki tinggi dan tidak memungkinkan menstabilkan semua ABI/API yang diekspor oleh setiap framework bersama.
  2. Menyalin library bersama framework lama. Dilengkapi dengan kuat batasan terhadap saluran sampingan, yang didefinisikan sebagai seluruh mekanisme untuk mengomunikasikan di antara modul framework dan modul vendor, termasuk (tetapi tidak terbatas pada) binder, socket, pipe, memori bersama, file bersama, dan properti sistem. Ada tidak boleh ada komunikasi kecuali jika protokol komunikasi dibekukan dan stabil (misalnya, HIDL melalui hwbinder). Memuat dua kali {i> shared library<i} dapat menyebabkan masalah juga; misalnya, jika objek yang dibuat oleh library baru diteruskan ke dalam fungsi dari library lama, error dapat terjadi karena library ini dapat menafsirkan obyek secara berbeda.

Berbagai pendekatan digunakan tergantung pada karakteristik server web library. Akibatnya, {i>framework<i} {i>shared library<i} diklasifikasikan menjadi tiga sub-kategori:

  • LL-NDK Library adalah Framework Shared Library yang dikenal stabil. Developer mereka berkomitmen untuk menjaga Kestabilan API/ABI.
    • 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 yang Memenuhi Syarat (VNDK) adalah Framework Bersama Library yang aman untuk disalin dua kali. Modul Framework dan Modul Vendor dapat ditautkan dengan salinannya sendiri. Kerangka kerja bersama dapat menjadi library VNDK yang memenuhi syarat hanya jika memenuhi persyaratan berikut kriteria:
    • Klien tidak mengirim/menerima IPC ke/dari framework.
    • Hal ini tidak terkait dengan mesin virtual ART.
    • Aplikasi ini tidak membaca/menulis file/partisi dengan format file yang tidak stabil.
    • Google Workspace tidak memiliki lisensi software khusus yang memerlukan peninjauan hukum.
    • Pemilik kodenya tidak keberatan dengan penggunaan vendor.
  • Library Khusus Framework (KHUSUS FWK) adalah Framework Bersama Library yang tidak termasuk dalam kategori yang disebutkan di atas. Ini {i>library<i}:
    • 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)

Same-Process HAL (SP-HAL) adalah kumpulan HAL yang telah ditentukan yang diterapkan sebagai Vendor Shared Libraries dan dimuat ke dalam Framework Proses. SP-HAL diisolasi oleh namespace penaut (mengontrol library dan simbol yang terlihat oleh library bersama). SP-HAL harus hanya bergantung pada LL-NDK dan VNDK-SP.

VNDK-SP adalah subset yang telah ditetapkan dari library VNDK yang memenuhi syarat. Library VNDK-SP ditinjau dengan cermat untuk memastikan pemuatan ganda library VNDK-SP ke dalam framework proses tidak menyebabkan masalah. Baik SP-HAL maupun VNDK-SP didefinisikan 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 } di file Android.bp. 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 (KHUSUS FWK):

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

Pembuatan versi VNDK

Library bersama VNDK memiliki beberapa 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 dipasang ke /apex/com.android.vndk.v${ro.vndk.version}.

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

  • 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 (mis. P).

Vendor Test Suite (VTS)

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