Panoramica di Vendor Native Development Kit (VNDK)

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

Perché VNDK?

AOSP consente gli aggiornamenti solo del framework in cui è possibile eseguire l'upgrade della partizione di sistema alla versione più recente del framework mentre la partizione del fornitore rimane invariata. Pur essendo stato costruito volte, i file binari in ogni partizione devono poter funzionare tra loro.

Gli aggiornamenti solo del framework includono le seguenti sfide:

  • Dipendenza tra moduli del framework e moduli del fornitore. Prima di Android 8.0, i moduli nel fornitore e nella partizione di sistema potevano essere collegati una con l'altra. Tuttavia, le dipendenze dai moduli del fornitore imponevano restrizioni allo sviluppo dei moduli del framework.
  • Estensioni alle librerie AOSP. Android richiede che tutti i dispositivi Android superino il controllo CTS quando la partizione di sistema viene sostituita con un'immagine di sistema generica di sistema (GSI) standard. Tuttavia, poiché i fornitori estendono AOSP per migliorare le prestazioni o aggiungere ulteriori funzionalità per il proprio HIDL implementazioni di sistema, eseguendo il flashing della partizione di sistema con una potrebbe interrompere l'implementazione HIDL di un fornitore. Per le linee guida su evitare tali malfunzionamenti, consulta Estensioni VNDK.

Per affrontare queste sfide, Android include diverse funzionalità, come VNDK (descritto in questa sezione), HIDL, hwbinder, Overlay ad albero dei dispositivi; e overlay sepolicy.

Termini specifici VNDK

I documenti relativi a VNDK utilizzano la seguente terminologia:
  • Per moduli si intendono librerie condivise o eseguibili. I moduli semplificano il processo di creazione delle dipendenze.
  • I processi sono attività del sistema operativo generate dagli eseguibili. I processi rendono il runtime delle dipendenze.
  • I termini idonei al framework sono correlati alla partizione system:
    • Per eseguibili del framework si intendono gli eseguibili in /system/bin o /system/xbin.
    • Con framework per librerie condivise si intendono le librerie condivise in /system/lib[64].
    • I moduli del framework fanno riferimento a entrambe le librerie condivise del framework e framework eseguibili.
    • I processi framework sono processi generati dal framework eseguibili, ad esempio /system/bin/app_process.
  • I termini idonei al fornitore sono relativi a vendor partizioni:
    • Gli eseguibili del fornitore si riferiscono agli eseguibili in /vendor/bin
    • Per librerie condivise del fornitore si intendono le librerie 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 dal Fornitore Eseguibili, come /vendor/bin/android.hardware.camera.provider@2.4-service.
    di Gemini Advanced.
di Gemini Advanced.

Concetti di VNDK

In un ambiente ideale con Android 8.0 e versioni successive, i processi del framework non vengono caricati 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 e i processi dei fornitori sono regolati dalle normative HIDL e .

Un mondo del genere include la possibilità che le API pubbliche stabili da e le librerie condivise di un framework potrebbero non essere sufficienti per gli sviluppatori di moduli del fornitore (sebbene le API possano cambiare da una release di Android all'altra), richiedendo che alcune di librerie condivise di framework siano accessibili ai processi del fornitore. Inoltre, poiché dei requisiti delle prestazioni può portare a compromissioni, alcuni Gli HAL devono essere trattati in modo diverso.

Le seguenti sezioni descrivono nel dettaglio come VNDK gestisce le librerie condivise dei framework per e Same-Process HAL (SP-HAL).

Framework librerie condivise per il fornitore

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

  1. Stabilizza ABI/API delle librerie condivise del framework. I nuovi moduli del framework e quelli del fornitore precedente possono utilizzare la stessa libreria condivisa per di memoria e di spazio di archiviazione. Una libreria condivisa univoca evita inoltre diversi problemi di doppio caricamento. Tuttavia, il costo di sviluppo per mantenere una Il numero di ABI/API è elevato ed è irragionevole stabilizzare tutte le ABI/API esportate da in ogni libreria condivisa framework.
  2. Copia le librerie condivise del framework precedente. Include la robustezza Restrizione contro i canali laterali, definita come tutti i meccanismi di comunicazione tra i moduli del framework e quelli dei fornitori, inclusi, a titolo esemplificativo, binder, socket, pipe, memoria condivisa, file condiviso e proprietà di sistema. Là non deve comunicare alcuna comunicazione a meno che il protocollo di comunicazione non sia bloccato e stabile (ad es. HIDL tramite hwbinder). Il doppio caricamento delle librerie condivise potrebbe problemi correlati; Ad esempio, se un oggetto creato dalla nuova libreria viene passato alle funzioni della libreria precedente, potrebbe verificarsi un errore mentre queste librerie potrebbe interpretare l'oggetto in modo diverso.

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

  • Le librerie LL-NDK sono librerie condivise framework noti per essere stabili. I loro sviluppatori si impegnano a mantenere 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 sono framework condivisi Librerie che possono essere copiate due volte in sicurezza. moduli framework e I Moduli per i fornitori possono essere collegati alle proprie copie. Un framework condiviso può diventare una libreria VNDK idonea solo se soddisfa i seguenti requisiti di classificazione:
    • Non invia e riceve IPC da/verso il framework.
    • Non è correlata 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 riguardo all'utilizzo del fornitore.
  • Librerie solo framework (SOLO FWK) sono framework condivisi Librerie che non appartengono alle categorie sopra menzionate. Questi librerie:
    • Sono considerati dettagli di implementazione interna del framework.
    • Non deve essere accessibile dai moduli del fornitore.
    • Avere ABI/API instabili e nessuna garanzia di compatibilità di API/ABI.
    • Non vengono copiati.

HAL a stesso processo (SP-HAL)

Same-Process HAL (SP-HAL) è un insieme di HAL predeterminati implementate come librerie condivise del fornitore e caricate in un framework Processi. Gli SP-HAL sono isolati da uno spazio dei nomi del linker (controlla il librerie e simboli visibili alle librerie condivise). Gli SP-HAL devono dipendono solo da LL-NDK e VNDK-SP.

VNDK-SP è un sottoinsieme predefinito di librerie VNDK idonee. Librerie VNDK-SP vengono esaminati attentamente per garantire che le librerie VNDK-SP vengano caricate due volte nel framework processi non causano problemi. Sia SP-HAL che VNDK-SP sono definiti da in tutti i canali 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 anche vndk: {private:true} è specificato, queste librerie si chiamano VNDK-SP-Private e sono invisibile a SP-HALS.

Quelle seguenti sono librerie solo framework con eccezioni RS (SOLO FWK-RS):

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)
di Gemini Advanced.

Controllo delle versioni VNDK

Viene eseguito il controllo delle versioni delle librerie condivise VNDK:

  • La proprietà di sistema ro.vndk.version viene aggiunta automaticamente /vendor/default.prop.
  • Le librerie condivise VNDK e VNDK-SP sono installate come apice VNDK com.android.vndk.v${ro.vndk.version} e montato in /apex/com.android.vndk.v${ro.vndk.version}.

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

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

Suite di test del fornitore (VTS)

La suite di test per fornitori Android (VTS) impone una una proprietà ro.vndk.version non vuota. Entrambi i dispositivi lanciati di recente e i dispositivi che eseguono l'upgrade devono definire ro.vndk.version. Alcuni test VNDK di lavoro (ad es. VtsVndkFilesTest e VtsVndkDependencyTest) si basano su ro.vndk.version per caricare i set di dati idonei delle librerie VNDK corrispondenti.