Panoramica del Vendor Native Development Kit (VNDK)

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

Ritiro

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

Dettagli sul ritiro di VNDK

Tutte le librerie VNDK sono incluse nel pacchetto 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 per il 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 sono create per Android 15:
    • ro.vndk.version
    • ro.product.vndk.version
  • Le ottimizzazioni VNDK non saranno disponibili perché non è presente alcun VNDK:
    • TARGET_VNDK_USING_CORE_VARIANT per i dispositivi Android Go
    • use_vndk_as_stable per gli APEX del fornitore
  • Snapshot del fornitore, che dipende molto dal VNDK

Eccezioni al ritiro

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

Perché VNDK?

AOSP consente aggiornamenti solo del framework in cui la partizione di sistema può essere aggiornata all'ultima versione del framework, mentre la partizione del fornitore rimane invariata. Nonostante siano stati creati in momenti diversi, i file binari di ogni partizione devono essere in grado di funzionare tra loro.

Gli aggiornamenti solo del framework includono 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 del sistema potevano essere collegati tra loro. Tuttavia, le dipendenze dei moduli del fornitore hanno imposto restrizioni indesiderate allo sviluppo dei moduli del framework.
  • Estensioni delle librerie AOSP. Android richiede che tutti i dispositivi Android superino il CTS quando la partizione di sistema viene sostituita con una Generic System Image (GSI) standard. Tuttavia, poiché i fornitori estendono le librerie AOSP per migliorare le prestazioni o aggiungere funzionalità extra per le implementazioni HIDL, il flashing della partizione di sistema con una GSI standard potrebbe interrompere l'implementazione HIDL di un fornitore. Per le linee guida sulla prevenzione di questi problemi, consulta Estensioni VNDK.

Per affrontare queste sfide, Android include diverse funzionalità come VNDK (descritto in questa sezione), HIDL, hwbinder, sovrapposizione dell'albero dei dispositivi e sovrapposizione sepolicy.

Termini specifici di VNDK

I documenti relativi a VNDK utilizzano la seguente terminologia:
  • I moduli si riferiscono a librerie condivise o eseguibili. I moduli creano dipendenze in fase di build.
  • I processi sono attività del sistema operativo generate da file eseguibili. I processi creano dipendenze di runtime.
  • I termini qualificati per il framework sono correlati alla partizione system:
    • Eseguibili del framework si riferiscono agli eseguibili in /system/bin o /system/xbin.
    • Le librerie condivise del framework si riferiscono alle librerie condivise in /system/lib[64].
    • I moduli del framework si riferiscono sia alle librerie condivise del framework sia agli eseguibili del framework.
    • I processi del framework sono processi generati da eseguibili del framework, ad esempio /system/bin/app_process.
  • I termini qualificati per il fornitore sono correlati alle partizioni vendor:
    • Eseguibili del fornitore si riferisce agli eseguibili in /vendor/bin
    • Le raccolte condivise dei fornitori si riferiscono alle raccolte condivise in /vendor/lib[64].
    • I moduli del fornitore si riferiscono 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 con 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 regolati da HIDL e binder hardware.

Un mondo di questo tipo include la possibilità che le API pubbliche stabili delle librerie condivise del framework non siano sufficienti per gli sviluppatori di moduli del fornitore (anche se le API possono cambiare tra le versioni di Android), il che richiede che una parte delle librerie condivise del framework sia accessibile ai processi del fornitore. Inoltre, poiché i requisiti di prestazioni 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 le HAL Same-Process (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 in più versioni 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'utilizzo di memoria e le dimensioni dello spazio di archiviazione. Una libreria condivisa univoca evita anche diversi problemi di doppio caricamento. Tuttavia, il costo di sviluppo per mantenere ABI/API stabili è elevato ed è irrealistico stabilizzare tutte le ABI/API esportate da ogni libreria condivisa del framework.
  2. Copia le librerie condivise del framework precedente. È dotato di una forte restrizione contro i canali laterali, definiti come tutti i meccanismi di comunicazione tra i moduli del framework e i moduli del fornitore, inclusi, a titolo esemplificativo, binder, socket, pipe, memoria condivisa, file condiviso 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 perché queste librerie potrebbero interpretare l'oggetto in modo diverso.

A seconda delle caratteristiche delle librerie condivise, vengono utilizzati approcci diversi. Di conseguenza, le librerie condivise del framework sono classificate in tre sottocategorie:

  • Le librerie LL-NDK sono librerie condivise del framework note per la loro stabilità. I suoi sviluppatori si impegnano a mantenere la stabilità di 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 in sicurezza due volte. I moduli framework e i moduli 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 dal/al framework.
    • Non è correlato alla macchina virtuale ART.
    • Non legge/scrive file/partizioni con formati di file instabili.
    • Non dispone di una licenza software speciale che richiede revisioni legali.
    • Il proprietario del codice non ha obiezioni all'utilizzo da parte del fornitore.
  • Le librerie solo framework (FWK-ONLY) sono librerie condivise del framework che non appartengono alle categorie menzionate in precedenza. Queste librerie:
    • Sono considerati dettagli interni dell'implementazione del framework.
    • Non deve essere accessibile dai moduli del fornitore.
    • Hanno ABI/API instabili e nessuna garanzia di compatibilità ABI/API.
    • Non vengono copiati.

HAL dello stesso processo (SP-HAL)

L'HAL Same-Process (SP-HAL) è un insieme di HAL predeterminati implementati come librerie condivise del fornitore e caricati nei processi del framework. Le SP-HAL sono isolate da uno spazio dei nomi del linker (controlla le librerie e i simboli visibili alle librerie condivise). Le SP-HAL 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 SP-HAL 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 framework con eccezioni RS (FWK-ONLY-RS):

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

Controllo delle versioni di 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 apex VNDK 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 di seguito:

  • 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)

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