Panoramica del kit di sviluppo nativo del fornitore (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 runtime per dlopen.

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 compilati in momenti diversi, i binari in ogni partizione devono essere in grado di funzionare l'uno con l'altro.

Gli aggiornamenti solo del framework includono le seguenti sfide:

  • Dipendenza tra moduli framework e moduli fornitore . Prima di Android 8.0, i moduli nel fornitore e nella partizione di sistema potevano collegarsi tra loro. Tuttavia, le dipendenze dai moduli del fornitore hanno imposto restrizioni indesiderate allo sviluppo dei moduli del framework.
  • Estensioni alle librerie AOSP . Android richiede che tutti i dispositivi Android superino CTS quando la partizione di sistema viene sostituita con un'immagine di sistema generica (GSI) standard. Tuttavia, poiché i fornitori estendono le librerie AOSP per aumentare le prestazioni o per aggiungere funzionalità extra per le loro implementazioni HIDL, il flashing della partizione di sistema con un GSI standard potrebbe interrompere l'implementazione HIDL di un fornitore. Per le linee guida sulla prevenzione di tali rotture, vedere le estensioni VNDK .

Per affrontare queste sfide, Android contiene diverse funzionalità come VNDK (descritto in questa sezione), HIDL , hwbinder, overlay dell'albero del dispositivo e overlay 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 compilazione.
  • I processi sono attività del sistema operativo generate da eseguibili. I processi creano dipendenze di runtime.
  • I termini qualificati per il framework sono relativi alla partizione di system :
    • Gli eseguibili del framework si riferiscono agli eseguibili in /system/bin o /system/xbin .
    • Le librerie condivise del framework fanno riferimento alle librerie condivise in /system/lib[64] .
    • I moduli del framework si riferiscono sia alle librerie condivise del framework che agli eseguibili del framework.
    • I processi del framework sono processi generati da eseguibili del framework, come /system/bin/app_process .
  • I termini qualificati dal fornitore sono correlati alle partizioni del vendor :
    • Gli eseguibili del fornitore si riferiscono agli eseguibili in /vendor/bin
    • Le librerie condivise del fornitore fanno riferimento alle librerie condivise in /vendor/lib[64] .
    • I moduli del fornitore si riferiscono sia agli eseguibili del fornitore che alle librerie condivise del fornitore.
    • I processi del fornitore sono processi generati da eseguibili del fornitore, come /vendor/bin/android.hardware.camera.provider@2.4-service .

Concetti 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 regolate da HIDL e hardware raccoglitore.

Un tale mondo include la possibilità che le API pubbliche stabili delle librerie condivise del framework potrebbero non essere sufficienti per gli sviluppatori di moduli del fornitore (sebbene le API possano cambiare tra le versioni di Android), richiedendo che una parte delle librerie condivise del framework sia accessibile ai processi del fornitore. Inoltre, poiché i requisiti di prestazione possono portare a compromessi, alcuni HAL critici per i tempi di risposta 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 Same-Process (SP-HAL).

Librerie condivise del framework per il fornitore

Questa sezione descrive i criteri per classificare le librerie condivise accessibili ai processi del fornitore. Esistono due approcci per supportare i moduli del fornitore in più versioni di Android:

  1. Stabilizzare gli ABI/API delle librerie condivise del framework . I nuovi moduli del framework e i moduli del vecchio fornitore possono utilizzare la stessa libreria condivisa per ridurre l'ingombro della memoria e le dimensioni dello storage. Una libreria condivisa univoca evita anche diversi problemi di doppio caricamento. Tuttavia, il costo di sviluppo per mantenere ABI/API stabili è elevato e non è realistico stabilizzare tutti gli ABI/API esportati da ogni libreria condivisa del framework.
  2. Copia le librerie condivise del vecchio framework . Viene fornito con la forte restrizione contro i canali laterali, definiti come tutti i meccanismi per comunicare tra moduli framework e moduli del fornitore, inclusi (ma non limitati a) binder, socket, pipe, memoria condivisa, file condivisi e proprietà di sistema. Non deve esserci comunicazione a meno che il protocollo di comunicazione non sia congelato 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 dalla 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 del framework sono classificate in tre sottocategorie:

  • Le librerie LL-NDK sono librerie condivise di framework note per essere stabili. I loro sviluppatori si impegnano a mantenere le loro stabilità 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 di Framework che possono essere copiate due volte in modo sicuro. I moduli quadro e i moduli fornitore possono collegarsi con le proprie copie. Una libreria condivisa 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 agli usi del fornitore.
  • Le librerie solo framework (FWK-ONLY) sono librerie condivise framework che non appartengono alle categorie sopra menzionate. Queste librerie:
    • Sono considerati i dettagli di implementazione interna del quadro.
    • Non deve essere accessibile dai moduli del fornitore.
    • Hanno ABI/API instabili e nessuna garanzia di compatibilità API/ABI.
    • Non vengono copiati.

Stesso processo HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) è un insieme di HAL predeterminati implementati come Vendor Shared Libraries e caricati in Framework Processes . Gli SP-HAL sono isolati da uno spazio dei nomi linker (controlla le librerie e i simboli visibili alle librerie condivise). Gli 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 riviste 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 approvati:

  • 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 loro file Android.bp. Se viene specificato anche vndk: {private:true} , queste librerie vengono chiamate VNDK-SP-Private e sono invisibili a SP-HALS.

Le seguenti sono librerie solo framework con eccezioni RS (FWK-ONLY-RS) :

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

Versione VNDK

Le librerie condivise VNDK hanno una versione:

  • 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 è scelto dall'algoritmo seguente:

  • Se BOARD_VNDK_VERSION non è uguale a current , utilizzare BOARD_VNDK_VERSION .
  • Se BOARD_VNDK_VERSION è uguale a current :
    • Se PLATFORM_VERSION_CODENAME è REL , usa PLATFORM_SDK_VERSION (ad esempio 28 ).
    • Altrimenti, usa PLATFORM_VERSION_CODENAME (es. P ).

Vendor Test Suite (VTS)

L'Android Vendor Test Suite (VTS) richiede una proprietà ro.vndk.version non vuota. Sia i dispositivi appena avviati che quelli in fase di aggiornamento devono definire ro.vndk.version . Alcuni test case VNDK (ad esempio VtsVndkFilesTest e VtsVndkDependencyTest ) si basano sulla proprietà ro.vndk.version per caricare i set di dati delle librerie VNDK idonei corrispondenti.