Google 致力于为黑人社区推动种族平等。查看具体举措
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Kit di sviluppo nativo del fornitore (VNDK)

Il Vendor Native Development Kit (VNDK) è un set di librerie esclusivamente per i fornitori per implementare i loro HAL. 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 del framework in cui la partizione di sistema può essere aggiornata alla versione più recente mentre le partizioni del fornitore rimangono invariate. Ciò implica che i binari compilati in momenti diversi devono essere in grado di funzionare tra loro; VNDK copre le modifiche API / ABI nelle versioni Android.

Gli aggiornamenti solo Framework includono le seguenti sfide:

  • Dipendenza tra moduli del framework e moduli del 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 imponevano restrizioni indesiderate allo sviluppo dei moduli del framework.
  • Estensioni alle librerie AOSP . Android 8.0 e versioni successive richiedono 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 su come prevenire tali rotture, vedere 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 di VNDK (di seguito) descrivono le librerie condivise del framework, gli HAL dello stesso processo (SP-HAL) e la terminologia VNDK.
  • Le estensioni VNDK classificano 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 le modifiche incompatibili con ABI sono vietate.
  • VNDK Build System Support descrive le configurazioni del sistema di build e le sintassi di definizione dei moduli correlate a VNDK.
  • Lo strumento di definizione VNDK aiuta a migrare l'albero dei sorgenti su Android 8.0 e versioni successive.
  • Linker Namespace fornisce un controllo dettagliato sui collegamenti alle librerie condivise.
  • Directory, regole e sepolicy definiscono la struttura della directory per i dispositivi che eseguono Android 8.0 e versioni successive, regole VNDK e sepolicy associati.
  • La presentazione di VNDK Design illustra i concetti fondamentali di VDNK utilizzati in Android 8.0 e versioni successive.

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 processi del framework e processi del fornitore sono regolate da HIDL e hardware raccoglitore.

Un tale mondo include la possibilità che API pubbliche e stabili da librerie condivise di 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 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 gli 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 su più versioni di Android:

  1. Stabilizzare le ABI / API delle librerie condivise del framework . I nuovi moduli del framework e quelli del vecchio fornitore possono utilizzare la stessa libreria condivisa per ridurre l'ingombro della 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 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 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 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. I moduli Framework ei moduli del fornitore possono collegarsi alle proprie copie. Una libreria condivisa del 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 sugli utilizzi del fornitore.
  • Le librerie solo framework (SOLO FWK) sono librerie condivise di framework che non appartengono alle categorie sopra menzionate. Queste biblioteche:
    • 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à API / ABI.
    • Non vengono copiati.

Same-Process HAL (SP-HAL)

Same-Process HAL ( SP-HAL ) è un insieme di HAL predeterminati implementati come librerie condivise dai fornitori e caricati nei processi del framework . 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 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 viene 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 fanno riferimento a librerie condivise o eseguibili .
  • I processi sono attività del sistema operativo generate dagli eseguibili .
  • I termini qualificati per 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 di Framework fanno riferimento alle librerie condivise in /system/lib[64] .
  • I moduli Framework fanno riferimento sia alle librerie condivise di Framework che agli eseguibili di Framework .
  • I processi del framework sono processi generati dagli eseguibili del framework (ad esempio /system/bin/app_process ).
  • Gli eseguibili del fornitore si riferiscono agli eseguibili in /vendor/bin
  • Le librerie condivise dei fornitori 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 da eseguibili del fornitore (ad es
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Controllo delle versioni di VNDK

In Android 9, 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 vengono installate in /system/lib[64]/vndk-${ro.vndk.version} .
  • Le librerie condivise VNDK-SP vengono installate in /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Il file di configurazione del linker dinamico viene installato in /system/etc/ld.config.${ro.vndk.version}.txt .

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

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

Aggiornamento dei dispositivi

Se un dispositivo Android 8.x disabilita l'applicazione runtime di VNDK essendo stato creato 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 precedente ad Android 9, aggiungi PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false a BoardConfig.mk .

Vendor Test Suite (VTS)

Android 9 Vendor Test Suite (VTS) ro.vndk.version proprietà ro.vndk.version non vuota. Sia i dispositivi appena avviati che i dispositivi di 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 data set delle librerie VNDK idonee corrispondenti.

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

Cronologia del documento

Questa sezione tiene traccia delle modifiche alla documentazione di VNDK.

Modifiche ad Android 9

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

Modifiche ad Android 8.1

  • Le librerie SP-NDK sono state unite alle 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 standalone potrebbero aggiungere -lstdc++ ai flag del linker predefinito. Per disabilitare le impostazioni predefinite, aggiungi -nodefaultlibs -lc -lm -ldl a LDFLAGS .
  • Spostare libz.so dalle libz.so LL-NDK a VNDK-SP. In alcune configurazioni, libz.so potrebbe continuare ad essere LL-NDK. Tuttavia, non dovrebbero esserci differenze osservabili.