Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Vendor Native Development Kit (VNDK)

Il Vendor Native Development Kit (VNDK) è un insieme di librerie esclusivamente per i fornitori che implementano i propri HAL. Il VNDK viene fornito in system.img ed è collegato dinamicamente al codice del fornitore in fase di esecuzione.

Perché VNDK?

Android 8.0 e versioni successive consentono aggiornamenti solo framework in cui la partizione di sistema può essere aggiornata all'ultima versione mentre le partizioni del fornitore rimangono invariate. Ciò implica che i binari costruiti in momenti diversi devono essere in grado di lavorare tra loro; VNDK copre le modifiche API / ABI tra le versioni di Android.

Gli aggiornamenti solo del framework includono le seguenti sfide:

  • Dipendenza tra moduli quadro e moduli fornitore . Prima di Android 8.0, i moduli di entrambi i lati potevano collegarsi con i moduli dell'altro lato. Tuttavia, le dipendenze dai moduli del fornitore hanno imposto restrizioni indesiderate allo sviluppo dei moduli del framework.
  • Estensioni alle librerie AOSP . Android 8.0 e versioni successive richiedono che tutti i dispositivi Android passino CTS quando la partizione di sistema viene sostituita con un'immagine di sistema generica standard (GSI). Tuttavia, poiché i fornitori estendono le librerie AOSP per migliorare le prestazioni o 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, consultare le estensioni VNDK .)

Per affrontare queste sfide, Android 8.0 introduce diverse tecniche come VNDK (descritto in questa sezione), HIDL , hwbinder, overlay dell'albero dei dispositivi e overlay sepolicy.

Risorse VNDK

Questa sezione include le seguenti risorse VNDK:

  • I concetti VNDK (di seguito) descrivono le librerie condivise del framework, gli HAL dello stesso processo (SP-HAL) e la terminologia VNDK.
  • Le estensioni VNDK classifica le modifiche specifiche del fornitore in categorie. Ad esempio, le librerie con funzionalità estese su cui si basano i moduli del fornitore devono essere copiate nella partizione del fornitore, ma sono vietate le modifiche incompatibili ABI.
  • Il supporto del sistema di compilazione VNDK descrive le configurazioni del sistema di compilazione e le sintassi di definizione del modulo correlate a VNDK.
  • Lo strumento di definizione VNDK aiuta a migrare l'albero dei sorgenti su Android 8.0 e versioni successive.
  • Lo spazio dei nomi Linker offre un controllo accurato sui collegamenti alla libreria condivisa.
  • Directory, Regole e sepolicy definiscono la struttura delle directory per i dispositivi che eseguono Android 8.0 e versioni successive, le regole VNDK e le sepolicy associate.
  • La presentazione di VNDK Design illustra i concetti fondamentali di VDNK utilizzati in Android 8.0 e versioni successive.

Concetti VNDK

In un mondo Android 8.0 e superiore ideale, 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 processi framework e processi del fornitore sono regolate da HIDL e hardware raccoglitore.

Un mondo del genere include la possibilità che API pubbliche stabili da librerie condivise 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 framework sia accessibile ai processi del fornitore. Inoltre, poiché i requisiti di prestazione possono portare a compromessi, alcuni HAL critici in termini di tempo di risposta devono essere trattati in modo diverso.

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

Librerie condivise 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. Stabilizzare le ABI / API delle librerie condivise del framework . Nuovi moduli framework e vecchi moduli fornitore possono utilizzare la stessa libreria condivisa per ridurre il footprint di memoria e le dimensioni di archiviazione. Una libreria condivisa unica 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 vecchio framework . Presenta la forte restrizione contro i canali laterali, definita come tutti i meccanismi per comunicare tra i moduli framework e i moduli del fornitore, inclusi (ma non limitati a) raccoglitore, socket, pipe, memoria condivisa, file condiviso e proprietà di sistema. Non ci deve essere comunicazione a meno che il protocollo di comunicazione non sia congelato e stabile (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 del framework sono classificate in tre sottocategorie:

  • Le librerie LL-NDK sono librerie condivise Framework che sono 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 Framework che possono essere copiate in sicurezza due volte. I moduli quadro e i moduli fornitore possono essere collegati con le 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 ha una licenza software speciale che richiede revisioni legali.
    • Il proprietario del codice non ha obiezioni all'utilizzo del fornitore.
  • Le librerie solo framework (SOLO FWK) sono librerie condivise framework che non appartengono alle categorie sopra menzionate. Queste librerie:
    • Sono considerati i dettagli dell'implementazione interna del framework.
    • Non è possibile accedere ai moduli del fornitore.
    • Avere ABI / API instabili e nessuna garanzia di compatibilità API / ABI.
    • Non vengono copiati.

Stesso processo HAL (SP-HAL)

Lo stesso processo HAL ( SP-HAL ) è un insieme di HAL predeterminati implementati come librerie condivise del fornitore e caricate nei processi quadro . Gli SP-HAL sono isolati da uno spazio dei nomi del linker (controlla le librerie e i simboli che sono 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. Google SP-HAL e 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 loro file Android.bp. Se vendor_available: false è specificato anche vendor_available: false , queste librerie sono 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)

Terminologia VNDK

  • I moduli si riferiscono a librerie condivise o eseguibili .
  • I processi sono attività del sistema operativo generate da eseguibili .
  • I termini qualificati dal framework si riferiscono ai concetti relativi alla partizione di sistema .
  • I termini qualificati dal fornitore si riferiscono ai concetti relativi alle partizioni del fornitore .

Per esempio:

  • 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 Framework fanno riferimento sia alle librerie condivise Framework che agli eseguibili Framework .
  • I processi quadro sono processi generati da eseguibili quadro (ad esempio /system/bin/app_process ).
  • 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 fornitore si riferiscono sia agli eseguibili fornitori che alle librerie condivise fornitore .
  • I processi del fornitore sono processi generati da eseguibili del fornitore (ad es
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

VNDK versioning

In Android 9, le librerie condivise VNDK sono sottoposte a versione:

  • La proprietà di sistema ro.vndk.version viene aggiunta automaticamente a /vendor/default.prop .
  • Le librerie condivise VNDK sono installate su /system/lib[64]/vndk-${ro.vndk.version} .
  • Le librerie condivise VNDK-SP sono installate su /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Il file di configurazione del linker dinamico è installato in /system/etc/ld.config.${ro.vndk.version}.txt .

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

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

Aggiornamento dei dispositivi

Se un dispositivo Android 8.x disabilita l'esecuzione del runtime VNDK essendo costruito senza BOARD_VNDK_VERSION , potrebbe aggiungere PRODUCT_USE_VNDK_OVERRIDE := false a BoardConfig.mk durante l'aggiornamento ad Android 9.

Se PRODUCT_USE_VNDK_OVERRIDE è false , la proprietà ro.vndk.lite verrà automaticamente aggiunta a /vendor/default.prop e il suo valore sarà true . Di conseguenza, il linker dinamico caricherà la configurazione dello spazio dei nomi del linker da /system/etc/ld.config.vndk_lite.txt , che isola solo SP-HAL e VNDK-SP.

Per aggiornare un dispositivo Android 7.0 o inferiore ad Android 9, aggiungi PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false in BoardConfig.mk .

Vendor Test Suite (VTS)

Android 9 Vendor Test Suite (VTS) impone una proprietà ro.vndk.version non vuota. Sia i dispositivi appena lanciati che i dispositivi di aggiornamento 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 idonei corrispondenti.

Se la proprietà ro.product.first_api_level è maggiore di 27, la proprietà ro.vndk.lite non deve essere definita. VtsTreblePlatformVersionTest fallirà se ro.vndk.lite è definito in un dispositivo Android 9 appena lanciato.

Cronologia del documento

Questa sezione tiene traccia delle modifiche alla documentazione VNDK.

Android 9 cambia

  • Aggiungi la sezione di controllo delle versioni di VNDK.
  • Aggiungi sezione VTS.
  • Alcune categorie VNDK sono state rinominate:
    • LL-NDK-Indirect è stato rinominato in LL-NDK-Private.
    • VNDK-Indirect è stato rinominato in VNDK-Private.
    • VNDK-SP-Indirect-Private è stato rinominato VNDK-SP-Private.
    • VNDK-SP-Indirect è stato rimosso.

Android 8.1 cambia

  • Le librerie SP-NDK sono state unite in librerie LL-NDK.
  • Sostituisci libui.so con libft2.so nella sezione dello spazio dei nomi RS. È stato un errore includere libui.so .
  • Aggiungi libGLESv3.so e libandroid_net.so alle librerie LL-NDK.
  • Aggiungi libion.so alle librerie VNDK-SP.
  • Rimuovi libstdc++.so dalle librerie LL-NDK. Usa libc++.so invece. Alcune versioni di toolchain autonome possono aggiungere -lstdc++ ai flag di linker predefiniti. Per disabilitare i valori predefiniti, aggiungere -nodefaultlibs -lc -lm -ldl a LDFLAGS .
  • Spostare libz.so dalle libz.so LL-NDK alle librerie VNDK-SP. In alcune configurazioni, libz.so potrebbe continuare ad essere LL-NDK. Tuttavia, non dovrebbero esserci differenze osservabili.