A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Spazi dei nomi per le librerie native

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 Android for Developers Miglioramento della 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 di 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 di piattaforme private (come è stato fatto con OpenSSL). Inoltre, rimuove le situazioni in cui le app utilizzano accidentalmente le librerie della piattaforma anziché le proprie (come riscontrato con libpng). È difficile per le librerie delle app utilizzare per sbaglio 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 e 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, dove COMPANYNAME fa riferimento al nome del produttore (ad es. 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 system rese pubbliche dai produttori di dispositivi DEVONO avere il nome 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 raccolta DEVE corrispondere al COMPANYNAME nel nome del file txt in cui è elencato il nome della raccolta.

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 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 aggiuntive e configurazioni richieste:

La libreria nativa nel fornitore deve essere etichettata correttamente in modo da essere accessibile alle app. Se l'accesso è richiesto da app (incluse quelle 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.
La libreria, direttamente o tramite le sue dipendenze, non deve dipendere da librerie di sistema diverse da 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 del fornitore possono essere inserite in un APEX del fornitore. Quando sono pacchettizzate in un codice APEX del fornitore, elenca le librerie in una proprietà provideNativeLibs nel file manifest APEX.

Aggiornare le app in modo che non utilizzino librerie native non pubbliche

Questa funzionalità è attivata solo per le app destinate alla 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 Android accessibili alle app (note anche come librerie native pubbliche) è riportato nella sezione 3.1.1 del CDD. Le app che hanno come target la versione 24 o versioni successive e che utilizzano librerie non pubbliche devono essere aggiornate. Per ulteriori dettagli, consulta App NDK che fanno riferimento alle librerie della piattaforma .

Aggiornare le app per le dipendenze delle librerie native

Le app che hanno come target la versione SDK 31 (Android 12) o versioni successive devono specificare esplicitamente le dipendenze dalle librerie condivise native utilizzando il <uses-native-library> tag nel file manifest dell'app. Se una parte della biblioteca 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 compaiono nel file manifest dell'app.