Ekstensi VNDK

Produsen perangkat Android mengubah kode sumber {i>library<i} AOSP untuk berbagai alasan. Beberapa vendor mengimplementasikan kembali fungsi di {i>library<i} AOSP untuk meningkatkan performa sementara vendor lain menambahkan hook baru, API baru, atau fungsionalitas baru ke library AOSP. Bagian ini memberikan panduan untuk memperluas library AOSP dengan cara yang tidak merusak CTS/VTS.

Penggantian {i>drop-in<i}

Semua library bersama yang dimodifikasi harus kompatibel dengan biner, penggantian langsung dari versi AOSP mereka. Semua yang ada Pengguna AOSP harus dapat menggunakan pustaka bersama yang dimodifikasi tanpa rekompilasi. Persyaratan ini menyiratkan hal berikut:

• Fungsi AOSP tidak boleh dihapus.
• Struktur tidak boleh diubah jika struktur itu terpapar pengguna.
• Pra-kondisi fungsi tidak boleh diperkuat.
• Fungsi harus menyediakan fungsi yang setara.
• Pascakondisi fungsi tidak boleh dilemahkan.

Klasifikasi modul yang diperluas

Mengklasifikasikan modul berdasarkan fungsi yang ditentukan dan digunakan.

Catatan: Fungsi digunakan di sini bukannya API/ABI karena sudah ada kemungkinan penambahan fungsionalitas tanpa mengubah API/ABI apa pun.

Tergantung pada fungsi yang didefinisikan dalam modul, modul dapat diklasifikasikan ke dalam DA-Module dan DX-Module:

• Mendefinisikan Modul AOSP (DA-Module) tidak menentukan fungsionalitas yang tidak ada dalam versi AOSP.
  • Contoh 1. Library AOSP yang tidak dimodifikasi adalah Modul DA.
  • Contoh 2. Jika vendor menulis ulang fungsi di libcrypto.so dengan petunjuk SIMD (tanpa menambahkan petunjuk baru fungsi), libcrypto.so yang dimodifikasi akan menjadi Modul DA.
• Modul Mendefinisikan-Ekstensi (DX-Module) menentukan fungsi atau tidak memiliki versi AOSP.
  • Contoh 1. Jika vendor menambahkan fungsi {i>help <i}ke libjpeg.so untuk mengakses beberapa data internal, lalu libjpeg.so akan menjadi DX-Lib dan fungsi yang baru ditambahkan akan menjadi bagian library yang diperluas.
  • Contoh 2. Jika vendor menentukan library non-AOSP yang diberi nama libfoo.so, maka libfoo.so akan menjadi DX-Lib.

Tergantung pada fungsi yang digunakan oleh modul, modul dapat diklasifikasikan ke UA-Module dan UX-Module.

• Menggunakan Modul AOSP (UA-Module) hanya menggunakan fungsi AOSP dalam implementasinya. Operasi ini tidak bergantung pada ekstensi non-AOSP.
  • Contoh 1. Library AOSP yang masih utuh dan tidak dimodifikasi adalah UA-Modul.
  • Contoh 2. Jika galeri foto bersama libjpeg.so diubah hanya bergantung pada API AOSP lainnya, maka akan berupa Modul UA.
• Using-Extension Module (UX-Module) bergantung pada beberapa model non-AOSP fungsionalitas dalam implementasinya.
  • Contoh 1. Jika libjpeg.so yang diubah bergantung pada library non-AOSP lainnya bernama libjpeg_turbo2.so, lalu libjpeg.so yang dimodifikasi akan menjadi Modul UX.
  • Contoh 2. Jika vendor menambahkan {i>function<i} baru ke fungsi yang dimodifikasi libexif.so dan libjpeg.so-nya yang dimodifikasi menggunakan fungsi yang baru ditambahkan dari libexif.so, lalu fungsi tersebut dimodifikasi libjpeg.so akan menjadi Modul UX.

Definisi dan penggunaan tidak saling bergantung:

		Fungsi yang Digunakan
		Hanya AOSP (UA)	Diperluas (UX)
Fungsi yang Ditentukan	Hanya AOSP (DA)	DAU	DAU
	Diperpanjang (DX)	DXUA	{i>DXUX<i}

Mekanisme ekstensi VNDK

Modul vendor yang mengandalkan fungsi yang diperluas tidak akan berfungsi karena Library AOSP dengan nama yang sama tidak memiliki fungsi yang diperluas. Jika modul vendor baik secara langsung atau tidak langsung bergantung pada fungsi yang diperluas, vendor harus menyalin library bersama DAUX, DXUA, dan DXUX ke vendor partisi (proses vendor selalu mencari library bersama di vendor partisi terlebih dahulu). Namun, library LL-NDK tidak boleh disalin, sehingga vendor modul tidak boleh bergantung pada fungsi tambahan yang ditentukan oleh Library LL-NDK.

Perpustakaan bersama DAU dapat tetap berada di partisi sistem jika library AOSP yang sesuai bisa menyediakan fungsionalitas dan vendor yang sama modul akan terus berfungsi saat partisi sistem ditimpa oleh objek Generic Image Sistem (GSI).

Penggantian {i>drop-in<i} penting karena {i>library<i} VNDK yang tidak dimodifikasi di GSI akan terhubung dengan library bersama yang dimodifikasi saat konflik nama. Jika Library AOSP dimodifikasi dengan cara yang tidak kompatibel dengan API/ABI, library di GSI mungkin gagal ditautkan atau menyebabkan perilaku yang tidak ditentukan.