Spazi dei nomi per le librerie native

Android 7.0 ha introdotto gli spazi dei nomi per le librerie native per limitare l'API interna visibilità e risolvere le situazioni in cui le app usano accidentalmente la piattaforma delle loro librerie anziché le proprie. Consulta la sezione Informazioni sul Stabilità con limitazioni relative ai simboli C/C++ in Android 7.0 Android Post del blog per sviluppatori relativo a modifiche specifiche delle app.

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 annunci nativi della piattaforma privata API (come accadeva con OpenSSL). Rimuove anche le situazioni in cui le app usano accidentalmente le librerie della piattaforma invece delle proprie (come abbiamo visto con libpng). È difficile per le librerie delle app usare librerie di sistema per errore (e viceversa).

Aggiungere altre librerie native

Oltre alle librerie native pubbliche standard, sono disponibili fornitori di silicio (a partire da Android 7.0) e i produttori di dispositivi (a partire da Android 9) potrebbero decidere di fornire librerie native aggiuntive accessibile alle app inserendole nelle rispettive cartelle della libreria ed elencandole in modo esplicito nei file .txt.

Le cartelle della raccolta sono:

  • /vendor/lib (per 32 bit) e /vendor/lib64 (per 64 bit) per le 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 librerie di fornitori di silicio
  • /system/etc/public.libraries-COMPANYNAME.txt per le librerie dei produttori di dispositivi, dove COMPANYNAME si riferisce al nome del produttore (ad esempio 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 una soluzione esterna di Google Cloud.

Librerie native nella partizione system rese pubbliche dai produttori di dispositivi DEVE essere denominato 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 raccolta DEVE corrispondere al valore COMPANYNAME nella txt in cui è elencato il nome della libreria.

Le librerie native che fanno parte di AOSP NON DEVONO essere rese pubbliche (a eccezione del modello biblioteche native pubbliche che sono pubbliche per impostazione predefinita). Solo le librerie aggiuntive aggiunte da fornitori di silicio o produttori di dispositivi possono essere resi accessibili alle app.

A partire da Android 8.0, le librerie pubbliche dei fornitori hanno a disposizione le seguenti funzionalità aggiuntive limitazioni e configurazioni richieste:

  1. La libreria nativa del fornitore deve essere etichettata correttamente in modo da poter essere accessibile alle app. Se è richiesto l'accesso da parte di app (incluse terze parti app di terze parti), la raccolta 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 dipendono da librerie di sistema diverse dalle librerie VNDK-SP e LLNDK. Individua l'elenco librerie VNDK-SP e LLNDK su 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 l'APEX del fornitore. Quando sono pacchettizzate nell'APEX di un fornitore, elenca le librerie in una proprietà provideNativeLibs nel file manifest APEX.

Aggiorna le app per non utilizzare librerie native non pubbliche

Questa funzionalità è attiva solo per le app che hanno come target l'SDK versione 24 o successive. per la compatibilità con le versioni precedenti, consulta la Tabella 1.Che cosa succede se l'app si collega a librerie native private. L'elenco di librerie native Android accessibili alle app (note anche come pubbliche native) è elencato nella sezione CDD 3.1.1. App che hanno come target 24 o in un secondo momento e utilizzando librerie non pubbliche. Vedi NDK Collegamento di app alle librerie della piattaforma per ulteriori dettagli.

Aggiornare le app per le dipendenze delle librerie native

Le app che hanno come target l'SDK versione 31 (Android 12) o versioni successive devono specificare esplicitamente le dipendenze della libreria condivisa nativa utilizzando il Tag <uses-native-library> nel file manifest dell'app. Se uno o più dei componenti la libreria non esiste sul dispositivo, l'app non è installata. Una volta installate, le app vengono forniti solo delle librerie condivise native che hanno richiesto. Ciò significa che Le app non possono accedere alle librerie condivise native che non sono visualizzate nel file manifest dell'app.