Spazi dei nomi per le biblioteche native

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Android 7.0 ha introdotto gli spazi dei nomi per le librerie native per limitare la visibilità interna dell'API e risolvere le situazioni in cui le app utilizzano accidentalmente le librerie della piattaforma anziché le proprie. Per le modifiche specifiche dell'applicazione, vedere il miglioramento della stabilità con le restrizioni dei simboli C/C++ privati ​​nel post del blog degli sviluppatori Android di Android 7.0 .

Architettura

In Android 7.0 e versioni successive, le librerie di sistema sono separate dalle librerie di app.

Spazi dei nomi per le librerie native

Figura 1. Spazi dei nomi per le librerie native

Gli spazi dei nomi per le librerie native impediscono alle app di utilizzare API native della piattaforma privata (come è stato fatto con OpenSSL). Rimuove anche le situazioni in cui le app utilizzano accidentalmente le librerie della piattaforma anziché le proprie (come testimoniato con libpng ). È difficile per le librerie di app utilizzare accidentalmente le librerie di sistema interne (e viceversa).

Aggiunta di librerie native aggiuntive

Oltre alle librerie native pubbliche standard, i fornitori di silicio (a partire da Android 7.0) e i produttori di dispositivi (a partire da Android 9) possono scegliere di fornire librerie native aggiuntive accessibili alle app inserendole nelle rispettive cartelle delle librerie ed elencandole esplicitamente in .txt File.

Le cartelle della libreria sono:

  • /vendor/lib (per 32 bit) e /vendor/lib64 (per 64 bit) per librerie di fornitori di silicio
  • /system/lib (per 32 bit) e /system/lib64 (per 64 bit) per le librerie dei produttori di dispositivi

I file .txt sono:

  • /vendor/etc/public.libraries.txt per le librerie di fornitori di silicio
  • /system/etc/public.libraries-COMPANYNAME.txt per le librerie dei produttori di dispositivi, dove COMPANYNAME fa riferimento al nome del produttore (come awesome.company ). COMPANYNAME deve corrispondere a [A-Za-z0-9_.-]+ ; caratteri alfanumerici, _, . (punto) e -. È possibile avere più file .txt di questo tipo in un dispositivo se alcune librerie provengono da fornitori di soluzioni esterne.

Le librerie native nella partizione di system rese pubbliche dai produttori di dispositivi DEVONO essere denominate lib*COMPANYNAME.so , ad esempio, libFoo.awesome.company.so . In altre parole, libFoo.so senza il suffisso del nome dell'azienda NON DEVE essere reso pubblico. Il COMPANYNAME nel nome del file della libreria DEVE corrispondere al COMPANYNAME nel nome del file txt in cui è elencato il nome della libreria.

Le librerie native che fanno parte di AOSP NON DEVONO essere rese pubbliche (tranne le librerie native pubbliche standard che sono pubbliche per impostazione predefinita). Solo le librerie aggiuntive aggiunte dai fornitori di silicio o dai produttori di dispositivi possono essere rese accessibili alle app.

A partire da Android 8.0, le librerie pubbliche dei fornitori hanno le seguenti restrizioni aggiuntive e configurazioni richieste:

  1. La libreria nativa nel fornitore deve essere adeguatamente etichettata in modo che possa essere accessibile alle app. Se l'accesso è richiesto da qualsiasi app (incluse app di terze parti), la libreria deve essere etichettata come same_process_hal_file in un file file_contexts specifico del fornitore come segue:
    /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
    dove libnative.so è il nome della libreria nativa.
  2. La libreria, direttamente o transitivamente attraverso le sue dipendenze, non deve dipendere da librerie di sistema diverse dalle librerie VNDK-SP e LLNDK. Individua l'elenco delle librerie VNDK-SP e LLNDK in development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv .

Aggiornamento delle app per non utilizzare librerie native non pubbliche

Questa funzione è abilitata solo per le applicazioni destinate all'SDK versione 24 o successive; per la compatibilità con le versioni precedenti, vedere la tabella 1. Cosa aspettarsi se l'app si collega a librerie native private . L'elenco delle librerie native Android accessibili alle app (note anche come librerie native pubbliche) è elencato nella sezione CDD 3.1.1. Le app destinate a 24 o versioni successive e che utilizzano librerie non pubbliche devono essere aggiornate. Per ulteriori dettagli, vedere il collegamento delle app NDK alle librerie della piattaforma .

Aggiornamento delle app per le dipendenze della libreria nativa

Le applicazioni destinate all'SDK versione 31 (Android 12) o successive devono specificare in modo esplicito le dipendenze della libreria condivisa nativa usando il <uses-native-library> nel manifesto dell'app. Se una parte della libreria richiesta non esiste sul dispositivo, l'app non è installata. Quando le app vengono installate, vengono fornite solo le librerie condivise native che hanno richiesto. Ciò significa che le app non possono accedere alle librerie condivise native che non vengono visualizzate nel manifest dell'app.