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 fase di runtime per dlopen.

Perché VNDK?

AOSP consente aggiornamenti solo del framework in cui la partizione di sistema può essere aggiornata alla versione più recente del framework mentre la partizione del fornitore rimane invariata. Nonostante siano stati creati in tempi diversi, i file binari in ciascuna partizione devono essere in grado di funzionare tra loro.

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 imponevano 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 migliorare le prestazioni o per aggiungere funzionalità extra per le loro implementazioni HIDL, eseguire il flashing della partizione di sistema con un GSI standard potrebbe interrompere l'implementazione HIDL di un fornitore. Per linee guida su come prevenire tali rotture, vedere estensioni VNDK .

Per affrontare queste sfide, Android contiene diverse funzionalità come VNDK (descritto in questa sezione), HIDL , hwbinder, sovrapposizione della struttura dei dispositivi e sovrapposizione sepolicy.

Termini specifici del 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 file eseguibili. I processi creano dipendenze di runtime.
  • I termini qualificati dal framework sono correlati alla partizione system :
    • Gli 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 che agli eseguibili del framework.
    • I processi del framework sono processi generati dagli eseguibili del framework, come /system/bin/app_process .
  • I termini qualificati dal fornitore sono correlati alle partizioni vendor :
    • Gli eseguibili del fornitore si riferiscono agli eseguibili in /vendor/bin
    • Le librerie condivise del fornitore si riferiscono 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 dagli eseguibili del fornitore, come /vendor/bin/android.hardware.camera.provider@2.4-service .

Concetti VNDK

In un mondo ideale 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 mondo di questo tipo include la possibilità che API pubbliche stabili provenienti da 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 alcune parti delle librerie condivise del framework siano accessibili ai processi del fornitore. Inoltre, poiché i requisiti prestazionali possono portare a compromessi, alcuni HAL critici in termini di tempo di risposta devono essere trattati in modo diverso.

Le sezioni seguenti descrivono in dettaglio il modo in cui 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 su più versioni Android:

  1. Stabilizzare le ABI/API delle librerie condivise del framework . I nuovi moduli del framework e i moduli dei vecchi fornitori possono utilizzare la stessa libreria condivisa per ridurre l'ingombro della memoria e le dimensioni dello storage. Un'unica libreria condivisa evita inoltre diversi problemi di doppio caricamento. Tuttavia, il costo di sviluppo per mantenere ABI/API stabili è elevato e non è realistico stabilizzare tutte le ABI/API esportate 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 del framework e moduli del fornitore, inclusi (ma non limitati a) binder, socket, pipe, memoria condivisa, file condiviso e proprietà di sistema. Non deve esserci comunicazione a meno che il protocollo di comunicazione non sia congelato e stabile (ad esempio 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 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 la 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 del framework che possono essere copiate due volte in modo sicuro. I moduli Framework e i moduli fornitore possono collegarsi alle proprie copie. Una libreria condivisa framework può diventare una libreria VNDK idonea solo se soddisfa i seguenti criteri:
    • Non invia/riceve IPC al/dal 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 richieda revisioni legali.
    • Il proprietario del codice non ha obiezioni agli usi del fornitore.
  • Le librerie di solo framework (FWK-ONLY) sono librerie condivise di framework che non appartengono alle categorie sopra menzionate. Queste librerie:
    • Sono considerati dettagli di implementazione interna del framework.
    • Non deve essere accessibile dai moduli del fornitore.
    • Hanno ABI/API instabili e nessuna garanzia di compatibilità API/ABI.
    • Non vengono copiati.

HAL sullo stesso processo (SP-HAL)

Same-Process HAL ( SP-HAL ) è un insieme di HAL predeterminati implementati come librerie condivise del fornitore e caricati in Framework Processes . Gli SP-HAL sono isolati da uno spazio dei nomi del 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 esaminate attentamente per garantire che il doppio caricamento delle librerie VNDK-SP nei processi del framework non causi problemi. Sia gli SP-HAL che i 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 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)

Controllo delle versioni VNDK

Le librerie condivise VNDK hanno la 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 VNDK apex 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 esempio 28 ).
    • Altrimenti, utilizza PLATFORM_VERSION_CODENAME (ad esempio P ).

Suite di test del fornitore (VTS)

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