Android 7.0 ha introdotto gli spazi dei nomi per le librerie native per limitare la visibilità delle API interne e risolvere le situazioni in cui le app utilizzano accidentalmente le librerie della piattaforma anziché le proprie. Per le modifiche specifiche per le app, consulta il post del blog per sviluppatori Android Migliorare la stabilità con le limitazioni dei simboli C/C++ privati in Android 7.0.
Architettura
In Android 7.0 e versioni successive, le librerie di sistema sono separate dalle librerie delle app.

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). Inoltre, elimina le situazioni in cui le app
utilizzano accidentalmente le librerie della piattaforma anziché le proprie (come è successo
con libpng
). È difficile che le librerie delle app utilizzino accidentalmente le librerie
di sistema interne (e viceversa).
Aggiungere 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 nei file .txt.
Le cartelle della raccolta sono:
/vendor/lib
(per 32 bit) e/vendor/lib64
(per 64 bit) per le librerie dei 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 dei fornitori di silicio/system/etc/public.libraries-COMPANYNAME.txt
per le librerie dei produttori di dispositivi, doveCOMPANYNAME
si riferisce a un nome del produttore (ad esempioawesome.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 esterni.
Le librerie native nella partizione 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 valore COMPANYNAME
nel nome del file della libreria DEVE corrispondere al valore 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 (ad eccezione delle librerie native pubbliche standard che sono pubbliche per impostazione predefinita). Solo le librerie aggiuntive aggiunte da fornitori di silicio o produttori di dispositivi possono essere rese accessibili alle app.
A partire da Android 8.0, le librerie pubbliche dei fornitori presentano le seguenti limitazioni e configurazioni richieste aggiuntive:
- La libreria nativa nel fornitore deve essere etichettata correttamente 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 filefile_contexts
specifico del fornitore nel seguente modo: dove/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
libnative.so
è il nome della libreria nativa. - La libreria, direttamente o transitivamente tramite 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 all'indirizzo
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv
.
A partire da Android 15, le librerie pubbliche dei fornitori possono essere inserite in un
APEX del fornitore. Se sono incluse in un APEX fornitore, elenca le librerie
in una proprietà provideNativeLibs
nel manifest APEX.
Aggiornare le app in modo che non utilizzino librerie native non pubbliche
Questa funzionalità è attivata solo per le app che hanno come target la versione SDK 24 o successive; per la compatibilità con le versioni precedenti, consulta la tabella 1. Cosa aspettarsi se la tua app esegue il collegamento a librerie native private. L'elenco delle librerie native di Android accessibili alle app (note anche come librerie native pubbliche) è riportato nella sezione 3.1.1 del CDD. Le app che hanno come target Android 24 o versioni successive e che utilizzano librerie non pubbliche devono essere aggiornate. Per ulteriori dettagli, consulta NDK Apps Linking to Platform Libraries .
Aggiornare le app per le dipendenze delle librerie native
Le app che hanno come target la versione SDK 31 (Android 12) o successive devono
specificare esplicitamente le dipendenze della libreria condivisa nativa utilizzando il tag
<uses-native-library>
nel file manifest dell'app. Se una parte della libreria richiesta non esiste sul dispositivo, l'app non viene 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.