Panoramica di Vendor Native Development Kit (VNDK)

Il Vendor Native Development Kit (VNDK) è un insieme di librerie utilizzate da altre librerie o da file binari nella partizione del fornitore o del prodotto in fase di esecuzione per dlopen.

Ritiro

Il Vendor NDK è stato introdotto in Android 8.0 per fornire API tra il framework e il codice del fornitore. VNDK è stato utilizzato con successo da molti anni, ma presenta alcuni svantaggi:
  • Spazio di archiviazione
    • Un singolo APEX VNDK pacchettizza tutte le librerie VNDK, indipendentemente dal fatto che vengano utilizzate dal dispositivo o meno.
    • GSI contiene più versioni di APEX VNDK per supportare più versioni delle immagini del fornitore.
  • Aggiornabilità
    • È difficile aggiornare gli APEX VNDK separatamente dall'aggiornamento della piattaforma.
    • Le immagini del fornitore vengono aggiornate di frequente over-the-air (OTA), riducendo i vantaggi di avere il VNDK pacchettizzato all'interno dell'immagine di sistema.
In base a questi problemi, abbiamo deciso di ritirare VNDK a partire da Android 15.

Dettagli sul ritiro di VNDK

Tutte le librerie VNDK sono pacchettizzate in VNDK APEX e installate nell'immagine di sistema (-ext). Con il ritiro di VNDK, le precedenti librerie VNDK vengono installate nell'immagine del fornitore (o del prodotto), come le altre librerie disponibili dal fornitore. Queste funzionalità vengono rimosse insieme al ritiro di VNDK:
  • VNDK APEX per Android 15
  • Le proprietà di sistema che indicano la versione del VNDK di destinazione vengono rimosse se le partizioni del fornitore o del prodotto vengono compilate per Android 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • Le ottimizzazioni VNDK non saranno disponibili perché non esiste VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT per i dispositivi Android Go
    • use_vndk_as_stable per gli APEX del fornitore
  • Istantanea del fornitore, che dipende molto dal VNDK

Eccezioni al ritiro

Queste funzionalità non cambieranno con il ritiro del VNDK:
  • APEX VNDK con VNDK versione 14 o precedente, che sono necessari per supportare le immagini del fornitore esistenti.
  • LL-NDK non fa parte del VNDK.

Perché VNDK?

AOSP consente aggiornamenti solo del framework in cui è possibile eseguire l'upgrade della partizione di sistema all'ultima versione del framework, lasciando invariata la partizione del fornitore. Nonostante siano stati creati in momenti diversi, i file binari in ogni partizione devono essere in grado di funzionare tra loro.

Gli aggiornamenti solo del framework presentano le seguenti sfide:

  • Dipendenza tra i moduli del framework e i moduli del fornitore. Prima di Android 8.0, i moduli nella partizione del fornitore e di sistema potevano collegarsi tra loro. Tuttavia, le dipendenze dai moduli dei fornitori hanno imposto limitazioni indesiderate allo sviluppo dei moduli del framework.
  • Estensioni alle librerie AOSP. Android richiede che tutti i dispositivi Android superino il CTS quando la partizione di sistema viene sostituita con un Generic System Image (GSI) standard. Tuttavia, poiché i fornitori estendono le librerie AOSP per migliorare le prestazioni o aggiungere funzionalità aggiuntive per le loro implementazioni HIDL, il flashing della partizione di sistema con un GSI standard potrebbe interrompere l'implementazione HIDL di un fornitore. Per linee guida su come evitare questi problemi, consulta le estensioni VNDK.

Per risolvere questi problemi, Android contiene diverse funzionalità come VNDK (descritto in questa sezione), HIDL, hwbinder, overlay della struttura dell'albero del dispositivo e overlay sepolicy.

Termini specifici VNDK

I documenti relativi a VNDK utilizzano la seguente terminologia:
  • I moduli fanno riferimento a librerie condivise o eseguibili. I moduli creano dipendenze al momento della compilazione.
  • I processi sono attività del sistema operativo generate da file eseguibili. I processi creano dipendenze di runtime.
  • I termini idonei al framework sono correlati alla partizione system:
    • Per eseguibili del framework si intendono gli eseguibili in /system/bin o /system/xbin.
    • Le librerie condivise del framework fanno riferimento alle librerie condivise in /system/lib[64].
    • I moduli framework fanno riferimento sia alle librerie condivise del framework sia agli eseguibili del framework.
    • I processi framework sono processi generati dagli eseguibili del framework, come /system/bin/app_process.
  • I termini qualificati dal fornitore sono relativi alle partizioni vendor:
    • Per file eseguibili del fornitore si intendono i file eseguibili in /vendor/bin
    • Per librerie condivise del fornitore si intendono le librerie condivise in /vendor/lib[64].
    • I moduli del fornitore fanno riferimento sia agli eseguibili del fornitore sia alle librerie condivise del fornitore.
    • I processi del fornitore sono processi generati da file eseguibili del fornitore, ad esempio /vendor/bin/android.hardware.camera.provider@2.4-service.

Concetti di VNDK

In un mondo ideale di Android 8.0 e versioni successive, i processi del framework non caricano le librerie condivise del fornitore, tutti i processi del fornitore caricano solo le librerie condivise del fornitore (e una parte delle librerie condivise del framework) e le comunicazioni tra i processi del framework e i processi del fornitore sono regolate da HIDL e dall'hardware binder.

Un mondo del genere include la possibilità che le API pubbliche e stabili delle librerie condivise del framework potrebbero non essere sufficienti per gli sviluppatori di moduli del fornitore (anche se le API possono cambiare tra le release di Android), il che richiede che alcune parti delle librerie condivise del framework siano accessibili ai processi del fornitore. Inoltre, poiché i requisiti di rendimento possono portare a compromessi, alcuni HAL con tempi di risposta critici devono essere trattati in modo diverso.

Le sezioni seguenti descrivono in dettaglio come VNDK gestisce le librerie condivise del framework per i fornitori e gli HAL nello stesso processo (SP-HAL).

Librerie condivise del framework per il fornitore

Questa sezione descrive i criteri per la classificazione delle librerie condivise accessibili ai processi del fornitore. Esistono due approcci per supportare i moduli del fornitore su più release di Android:

  1. Stabilizza le ABI/API delle librerie condivise del framework. I nuovi moduli del framework e i vecchi moduli del fornitore possono utilizzare la stessa libreria condivisa per ridurre l'impronta in memoria e le dimensioni dello spazio di archiviazione. Una raccolta condivisa univoca evita inoltre diversi problemi di doppio caricamento. Tuttavia, il costo di sviluppo per mantenere stabili le ABI/API è elevato e non è realistico stabilizzare tutte le ABI/API esportate da ogni libreria condivisa del framework.
  2. Copia le librerie condivise del vecchio framework. Presenta la severa limitazione dei canali laterali, definiti come tutti i meccanismi per comunicare tra i moduli del framework e i moduli del fornitore, inclusi (a titolo esemplificativo) binder, socket, pipe, memoria condivisa, file condivisi e proprietà di sistema. Non deve esserci alcuna comunicazione, a meno che il protocollo di comunicazione non sia bloccato e stabile (ad es. HIDL tramite hwbinder). Anche il doppio caricamento delle librerie condivise potrebbe causare problemi. Ad esempio, se un oggetto creato dalla nuova libreria viene passato alle funzioni della vecchia libreria, potrebbe verificarsi un errore poiché queste librerie potrebbero interpretare l'oggetto in modo diverso.

Vengono utilizzati approcci diversi a seconda delle caratteristiche delle librerie condivise. Di conseguenza, le librerie condivise dei framework sono classificate in tre sottocategorie:

  • Le librerie LL-NDK sono librerie condivise del framework che sono note per essere stabili. I loro sviluppatori si impegnano a mantenere la stabilità delle API/ABI.
    • LL-NDK include le seguenti librerie: 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 e libvulkan.so,
  • Le librerie VNDK idonee (VNDK) sono librerie condivise del framework che possono essere copiate due volte in sicurezza. I moduli Framework e i moduli del fornitore possono essere collegati alle proprie copie. Una libreria condivisa del framework può diventare una libreria VNDK idonea solo se soddisfa i seguenti criteri:
    • Non invia/riceve IPC da/verso il framework.
    • Non è correlato alla macchina virtuale ART.
    • Non legge/scrive file/partizioni con formati di file instabili.
    • Non ha una licenza software speciale che richiede revisioni legali.
    • Il proprietario del codice non ha obiezioni all'utilizzo da parte del fornitore.
  • Le librerie solo per il framework (FWK-ONLY) sono librerie condivise del framework che non appartengono alle categorie sopra menzionate. Queste biblioteche:
    • Sono considerati dettagli di implementazione interni al framework.
    • Non deve essere accessibile dai moduli del fornitore.
    • Hanno ABI/API instabili e non offrono garanzie di compatibilità API/ABI.
    • Non vengono copiati.

HAL nello stesso processo (SP-HAL)

HAL nello stesso processo (SP-HAL) è un insieme di HAL predeterminate implementate come librerie condivise del fornitore e caricate nei processi del framework. Gli SP-HAL sono isolati da uno spazio dei nomi del linker (controlla le librerie e i simboli visibili alle librerie condivise). Gli HAL SP devono dipendere solo da LL-NDK e VNDK-SP.

VNDK-SP è un sottoinsieme predefinito di librerie VNDK idonee. Le librerie VNDK-SP vengono esaminate attentamente per garantire che il doppio caricamento delle librerie VNDK-SP nei processi del framework non causi problemi. Sia SP-HAL che VNDK-SP sono definiti da Google.

Le seguenti librerie sono HAL SP approvate:

  • 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

Le librerie VNDK-SP specificano vndk: { support_system_process: true } nei file Android.bp. Se viene specificato anche vndk: {private:true}, queste librerie vengono chiamate VNDK-SP-Private e sono invisibili a SP-HALS.

Di seguito sono riportate le librerie solo per il framework con eccezioni RS (FWK-ONLY-RS):

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

Versionamento VNDK

Le librerie condivise VNDK sono versionate:

  • La proprietà di sistema ro.vndk.version viene aggiunta automaticamente a /vendor/default.prop.
  • Le librerie condivise VNDK e VNDK-SP vengono installate come VNDK di primo livello com.android.vndk.v${ro.vndk.version} e montate su /apex/com.android.vndk.v${ro.vndk.version}.

Il valore di ro.vndk.version viene scelto dall'algoritmo seguente:

  • Se BOARD_VNDK_VERSION non è uguale a current, utilizza BOARD_VNDK_VERSION.
  • Se BOARD_VNDK_VERSION è uguale a current:
    • Se PLATFORM_VERSION_CODENAME è REL, utilizza PLATFORM_SDK_VERSION (ad es. 28).
    • In caso contrario, utilizza PLATFORM_VERSION_CODENAME (ad es. P).

Vendor Test Suite (VTS)

Il VTS (Android Vendor Test Suite) richiede una proprietà ro.vndk.version non vuota. Sia i dispositivi appena lanciati sia i dispositivi in fase di upgrade devono definire l'attributo ro.vndk.version. Alcuni scenari di test VNDK (ad es. VtsVndkFilesTest e VtsVndkDependencyTest) si basano sulla proprietà ro.vndk.version per caricare i set di dati idonei delle librerie VNDK corrispondenti.