Ikhtisar Kit Pengembangan Asli Vendor (VNDK).

Vendor Native Development Kit (VNDK) adalah sekumpulan pustaka yang digunakan oleh pustaka atau binari lain, di partisi vendor atau produk, saat runtime untuk dlopen.

Mengapa VNDK?

AOSP memungkinkan pembaruan kerangka saja di mana partisi sistem dapat ditingkatkan ke versi kerangka terbaru sementara partisi vendor tidak diubah. Meskipun dibangun pada waktu yang berbeda, binari pada setiap partisi harus dapat saling bekerja sama.

Pembaruan khusus kerangka kerja mencakup tantangan berikut:

  • Ketergantungan antara modul kerangka kerja dan modul vendor . Sebelum Android 8.0, modul di vendor dan partisi sistem dapat saling terhubung. Namun, ketergantungan dari modul vendor memberlakukan batasan yang tidak diinginkan pada pengembangan modul kerangka kerja.
  • Ekstensi ke perpustakaan AOSP . Android mengharuskan semua perangkat Android lulus CTS ketika partisi sistem diganti dengan Generic System Image (GSI) standar. Namun, karena vendor memperluas pustaka AOSP untuk meningkatkan kinerja atau menambahkan fungsi tambahan untuk implementasi HIDL mereka, mem-flash partisi sistem dengan GSI standar dapat merusak implementasi HIDL vendor. Untuk panduan mencegah kerusakan tersebut, lihat Ekstensi VNDK .

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

Ketentuan khusus VNDK

Dokumen terkait VNDK menggunakan terminologi berikut:
  • Modul mengacu pada perpustakaan bersama atau executable. Modul membuat ketergantungan waktu pembangunan.
  • Proses adalah tugas sistem operasi yang dihasilkan dari file yang dapat dieksekusi. Proses membuat ketergantungan run-time.
  • Kerangka -istilah yang memenuhi syarat terkait dengan partisi system :
    • Framework executable mengacu pada executable di /system/bin atau /system/xbin .
    • Kerangka perpustakaan bersama mengacu pada perpustakaan bersama di bawah /system/lib[64] .
    • Modul kerangka mengacu pada pustaka bersama kerangka kerja dan kerangka kerja yang dapat dieksekusi.
    • Proses kerangka kerja adalah proses yang dihasilkan dari kerangka kerja yang dapat dieksekusi, seperti /system/bin/app_process .
  • Istilah yang memenuhi syarat vendor terkait dengan partisi vendor :
    • Eksekusi vendor mengacu pada executable di /vendor/bin
    • Pustaka bersama vendor mengacu pada pustaka bersama di bawah /vendor/lib[64] .
    • Modul vendor mengacu pada vendor yang dapat dieksekusi dan pustaka bersama vendor.
    • Proses vendor adalah proses yang dihasilkan dari Vendor Executable, seperti /vendor/bin/android.hardware.camera.provider@2.4-service .

Konsep VNDK

Di dunia ideal Android 8.0 dan yang lebih tinggi, proses kerangka kerja tidak memuat pustaka bersama vendor, semua proses vendor hanya memuat pustaka bersama vendor (dan sebagian pustaka bersama kerangka kerja), dan komunikasi antara proses kerangka kerja dan proses vendor diatur oleh HIDL dan perangkat keras bahan pengikat.

Dunia seperti itu mencakup kemungkinan bahwa API publik yang stabil dari pustaka bersama kerangka kerja mungkin tidak cukup untuk pengembang modul vendor (walaupun API dapat berubah di antara rilis Android), yang mengharuskan beberapa bagian pustaka bersama kerangka kerja dapat diakses oleh proses vendor. Selain itu, karena persyaratan kinerja dapat menyebabkan kompromi, beberapa HAL yang kritis terhadap waktu respons harus diperlakukan secara berbeda.

Bagian berikut merinci bagaimana VNDK menangani pustaka bersama kerangka kerja untuk vendor dan HAL Proses yang Sama (SP-HAL).

Kerangka perpustakaan bersama untuk vendor

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

  1. Stabilkan ABI/API kerangka perpustakaan bersama . 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 mempertahankan ABI/API yang stabil sangatlah tinggi dan tidak realistis untuk menstabilkan semua ABI/API yang diekspor oleh setiap perpustakaan bersama kerangka kerja.
  2. Salin perpustakaan bersama kerangka lama . Dilengkapi dengan pembatasan yang kuat terhadap saluran samping, yang didefinisikan sebagai semua mekanisme untuk berkomunikasi antara modul kerangka kerja dan modul vendor, termasuk (namun tidak terbatas pada) pengikat, soket, pipa, memori bersama, file bersama, dan properti sistem. Tidak boleh ada komunikasi kecuali protokol komunikasi dibekukan dan stabil (misalnya HIDL melalui hwbinder). Memuat dua kali pustaka bersama mungkin juga menyebabkan masalah; misalnya, jika objek yang dibuat oleh perpustakaan baru diteruskan ke fungsi dari perpustakaan lama, kesalahan mungkin terjadi karena perpustakaan ini mungkin menafsirkan objek secara berbeda.

Pendekatan berbeda digunakan tergantung pada karakteristik perpustakaan bersama. Akibatnya, perpustakaan bersama kerangka kerja diklasifikasikan menjadi tiga subkategori:

  • Perpustakaan LL-NDK adalah Framework Shared Libraries yang dikenal stabil. Pengembangnya berkomitmen untuk menjaga stabilitas API/ABI mereka.
    • LL-NDK mencakup perpustakaan 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 ,
  • Perpustakaan VNDK yang Memenuhi Syarat (VNDK) adalah Perpustakaan Kerangka Bersama yang aman untuk disalin dua kali. Modul Kerangka dan Modul Vendor dapat ditautkan dengan salinannya sendiri. Pustaka bersama kerangka kerja bisa menjadi pustaka VNDK yang memenuhi syarat hanya jika memenuhi kriteria berikut:
    • Itu tidak mengirim/menerima IPC ke/dari kerangka kerja.
    • Ini tidak terkait dengan mesin virtual ART.
    • Itu tidak membaca/menulis file/partisi dengan format file yang tidak stabil.
    • Itu tidak memiliki lisensi perangkat lunak khusus yang memerlukan tinjauan hukum.
    • Pemilik kodenya tidak keberatan dengan penggunaan vendor.
  • Perpustakaan Framework-Only (FWK-ONLY) adalah Framework Shared Libraries yang tidak termasuk dalam kategori yang disebutkan di atas. Perpustakaan ini:
    • Dianggap kerangka rincian implementasi internal.
    • 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 sekumpulan HAL yang telah ditentukan sebelumnya yang diimplementasikan sebagai Pustaka Bersama Vendor dan dimuat ke dalam Proses Kerangka . SP-HAL diisolasi oleh namespace linker (mengontrol perpustakaan dan simbol yang terlihat oleh perpustakaan bersama). SP-HAL harus bergantung hanya pada LL-NDK dan VNDK-SP .

VNDK-SP adalah subset perpustakaan VNDK yang memenuhi syarat yang telah ditentukan sebelumnya. Pustaka VNDK-SP ditinjau secara cermat untuk memastikan pemuatan ganda pustaka VNDK-SP ke dalam proses kerangka kerja tidak menimbulkan masalah. SP-HAL dan VNDK-SP ditentukan oleh Google.

Perpustakaan berikut ini disetujui SP-HAL:

  • 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

Pustaka VNDK-SP menentukan vndk: { support_system_process: true } dalam file Android.bpnya. Jika vndk: {private:true} juga ditentukan, maka perpustakaan ini disebut VNDK-SP-Private dan tidak terlihat oleh SP-HALS.

Berikut ini adalah perpustakaan kerangka saja dengan pengecualian RS (FWK-ONLY-RS) :

  • libft2.so (skrip Render)
  • libmediandk.so (skrip Render)

versi VNDK

Pustaka bersama VNDK memiliki versi:

  • Properti sistem ro.vndk.version secara otomatis ditambahkan ke /vendor/default.prop .
  • Pustaka bersama VNDK dan VNDK-SP dipasang 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 dengan 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 (misalnya P ).

Rangkaian Uji Vendor (VTS)

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

,

Vendor Native Development Kit (VNDK) adalah sekumpulan pustaka yang digunakan oleh pustaka atau binari lain, di partisi vendor atau produk, saat runtime untuk dlopen.

Mengapa VNDK?

AOSP memungkinkan pembaruan kerangka saja di mana partisi sistem dapat ditingkatkan ke versi kerangka terbaru sementara partisi vendor tidak diubah. Meskipun dibangun pada waktu yang berbeda, binari pada setiap partisi harus dapat saling bekerja sama.

Pembaruan khusus kerangka kerja mencakup tantangan berikut:

  • Ketergantungan antara modul kerangka kerja dan modul vendor . Sebelum Android 8.0, modul di vendor dan partisi sistem dapat saling terhubung. Namun, ketergantungan dari modul vendor memberlakukan batasan yang tidak diinginkan pada pengembangan modul kerangka kerja.
  • Ekstensi ke perpustakaan AOSP . Android mengharuskan semua perangkat Android lulus CTS ketika partisi sistem diganti dengan Generic System Image (GSI) standar. Namun, karena vendor memperluas pustaka AOSP untuk meningkatkan kinerja atau menambahkan fungsi tambahan untuk implementasi HIDL mereka, mem-flash partisi sistem dengan GSI standar dapat merusak implementasi HIDL vendor. Untuk panduan mencegah kerusakan tersebut, lihat Ekstensi VNDK .

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

Ketentuan khusus VNDK

Dokumen terkait VNDK menggunakan terminologi berikut:
  • Modul mengacu pada perpustakaan bersama atau executable. Modul membuat ketergantungan waktu pembangunan.
  • Proses adalah tugas sistem operasi yang dihasilkan dari file yang dapat dieksekusi. Proses membuat ketergantungan run-time.
  • Kerangka -istilah yang memenuhi syarat terkait dengan partisi system :
    • Framework executable mengacu pada executable di /system/bin atau /system/xbin .
    • Kerangka perpustakaan bersama mengacu pada perpustakaan bersama di bawah /system/lib[64] .
    • Modul kerangka mengacu pada pustaka bersama kerangka kerja dan kerangka kerja yang dapat dieksekusi.
    • Proses kerangka kerja adalah proses yang dihasilkan dari kerangka kerja yang dapat dieksekusi, seperti /system/bin/app_process .
  • Istilah yang memenuhi syarat vendor terkait dengan partisi vendor :
    • Eksekusi vendor mengacu pada executable di /vendor/bin
    • Pustaka bersama vendor mengacu pada pustaka bersama di bawah /vendor/lib[64] .
    • Modul vendor mengacu pada vendor yang dapat dieksekusi dan pustaka bersama vendor.
    • Proses vendor adalah proses yang dihasilkan dari Vendor Executable, seperti /vendor/bin/android.hardware.camera.provider@2.4-service .

Konsep VNDK

Di dunia ideal Android 8.0 dan yang lebih tinggi, proses kerangka kerja tidak memuat pustaka bersama vendor, semua proses vendor hanya memuat pustaka bersama vendor (dan sebagian pustaka bersama kerangka kerja), dan komunikasi antara proses kerangka kerja dan proses vendor diatur oleh HIDL dan perangkat keras bahan pengikat.

Dunia seperti itu mencakup kemungkinan bahwa API publik yang stabil dari pustaka bersama kerangka kerja mungkin tidak cukup untuk pengembang modul vendor (walaupun API dapat berubah di antara rilis Android), yang mengharuskan beberapa bagian pustaka bersama kerangka kerja dapat diakses oleh proses vendor. Selain itu, karena persyaratan kinerja dapat menyebabkan kompromi, beberapa HAL yang kritis terhadap waktu respons harus diperlakukan secara berbeda.

Bagian berikut merinci bagaimana VNDK menangani pustaka bersama kerangka kerja untuk vendor dan HAL Proses yang Sama (SP-HAL).

Kerangka perpustakaan bersama untuk vendor

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

  1. Stabilkan ABI/API kerangka perpustakaan bersama . 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 mempertahankan ABI/API yang stabil sangatlah tinggi dan tidak realistis untuk menstabilkan semua ABI/API yang diekspor oleh setiap perpustakaan bersama kerangka kerja.
  2. Salin perpustakaan bersama kerangka lama . Dilengkapi dengan pembatasan yang kuat terhadap saluran samping, yang didefinisikan sebagai semua mekanisme untuk berkomunikasi antara modul kerangka kerja dan modul vendor, termasuk (namun tidak terbatas pada) pengikat, soket, pipa, memori bersama, file bersama, dan properti sistem. Tidak boleh ada komunikasi kecuali protokol komunikasi dibekukan dan stabil (misalnya HIDL melalui hwbinder). Memuat dua kali pustaka bersama mungkin juga menyebabkan masalah; misalnya, jika objek yang dibuat oleh perpustakaan baru diteruskan ke fungsi dari perpustakaan lama, kesalahan mungkin terjadi karena perpustakaan ini mungkin menafsirkan objek secara berbeda.

Pendekatan berbeda digunakan tergantung pada karakteristik perpustakaan bersama. Akibatnya, perpustakaan bersama kerangka kerja diklasifikasikan menjadi tiga subkategori:

  • Perpustakaan LL-NDK adalah Framework Shared Libraries yang dikenal stabil. Pengembangnya berkomitmen untuk menjaga stabilitas API/ABI mereka.
    • LL-NDK mencakup perpustakaan 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 ,
  • Perpustakaan VNDK yang Memenuhi Syarat (VNDK) adalah Perpustakaan Kerangka Bersama yang aman untuk disalin dua kali. Modul Kerangka dan Modul Vendor dapat ditautkan dengan salinannya sendiri. Pustaka bersama kerangka kerja bisa menjadi pustaka VNDK yang memenuhi syarat hanya jika memenuhi kriteria berikut:
    • Itu tidak mengirim/menerima IPC ke/dari kerangka kerja.
    • Ini tidak terkait dengan mesin virtual ART.
    • Itu tidak membaca/menulis file/partisi dengan format file yang tidak stabil.
    • Itu tidak memiliki lisensi perangkat lunak khusus yang memerlukan tinjauan hukum.
    • Pemilik kodenya tidak keberatan dengan penggunaan vendor.
  • Perpustakaan Framework-Only (FWK-ONLY) adalah Framework Shared Libraries yang tidak termasuk dalam kategori yang disebutkan di atas. Perpustakaan ini:
    • Dianggap kerangka rincian implementasi internal.
    • 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 sekumpulan HAL yang telah ditentukan sebelumnya yang diimplementasikan sebagai Pustaka Bersama Vendor dan dimuat ke dalam Proses Kerangka . SP-HAL diisolasi oleh namespace linker (mengontrol perpustakaan dan simbol yang terlihat oleh perpustakaan bersama). SP-HAL harus bergantung hanya pada LL-NDK dan VNDK-SP .

VNDK-SP adalah subset perpustakaan VNDK yang memenuhi syarat yang telah ditentukan sebelumnya. Pustaka VNDK-SP ditinjau secara cermat untuk memastikan pemuatan ganda pustaka VNDK-SP ke dalam proses kerangka kerja tidak menimbulkan masalah. SP-HAL dan VNDK-SP ditentukan oleh Google.

Perpustakaan berikut ini disetujui SP-HAL:

  • 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

Pustaka VNDK-SP menentukan vndk: { support_system_process: true } dalam file Android.bpnya. Jika vndk: {private:true} juga ditentukan, maka perpustakaan ini disebut VNDK-SP-Private dan tidak terlihat oleh SP-HALS.

Berikut ini adalah perpustakaan kerangka saja dengan pengecualian RS (FWK-ONLY-RS) :

  • libft2.so (skrip Render)
  • libmediandk.so (skrip Render)

versi VNDK

Pustaka bersama VNDK memiliki versi:

  • Properti sistem ro.vndk.version secara otomatis ditambahkan ke /vendor/default.prop .
  • Pustaka bersama VNDK dan VNDK-SP dipasang 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 dengan 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 (misalnya P ).

Rangkaian Uji Vendor (VTS)

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