Android 7.0 a introduit des espaces de noms pour les bibliothèques natives afin de limiter la visibilité interne de l'API et de résoudre les situations où les applications utilisent accidentellement des bibliothèques de plate-forme au lieu des leurs. Consultez le billet de blog Improving Stability with Private C/C++ Symbol Restrictions in Android 7.0 Android Developers pour les modifications spécifiques à l'application.
Architecture
Dans Android 7.0 et versions ultérieures, les bibliothèques système sont séparées des bibliothèques d'applications.

Figure 1. Espaces de noms pour les bibliothèques natives
Les espaces de noms pour les bibliothèques natives empêchent les applications d'utiliser des API natives de plate-forme privée (comme cela a été fait avec OpenSSL). Il supprime également les situations où les applications utilisent accidentellement des bibliothèques de plate-forme au lieu des leurs (comme en témoigne libpng
). Il est difficile pour les bibliothèques d'applications d'utiliser des bibliothèques système internes par accident (et vice versa).
Ajout de bibliothèques natives supplémentaires
En plus des bibliothèques natives publiques standard, les fournisseurs de silicium (à partir d'Android 7.0) et les fabricants d'appareils (à partir d'Android 9) peuvent choisir de fournir des bibliothèques natives supplémentaires accessibles aux applications en les plaçant dans les dossiers de bibliothèque respectifs et en les répertoriant explicitement dans .txt des dossiers.
Les dossiers de la bibliothèque sont :
-
/vendor/lib
(pour 32 bits) et/vendor/lib64
(pour 64 bits) pour les bibliothèques de fournisseurs de silicium -
/system/lib
(pour 32 bits) et/system/lib64
(pour 64 bits) pour les bibliothèques des fabricants de périphériques
Les fichiers .txt sont :
-
/vendor/etc/public.libraries.txt
pour les bibliothèques des fournisseurs de silicium -
/system/etc/public.libraries-COMPANYNAME.txt
pour les bibliothèques des fabricants d'appareils, oùCOMPANYNAME
fait référence au nom du fabricant (tel queawesome.company
).COMPANYNAME
doit correspondre à[A-Za-z0-9_.-]+
; caractères alphanumériques, _, . (point) et -. Il est possible d'avoir plusieurs fichiers .txt de ce type dans un appareil si certaines bibliothèques proviennent de fournisseurs de solutions externes.
Les bibliothèques natives de la partition system
qui sont rendues publiques par les fabricants de périphériques DOIVENT être nommées lib*COMPANYNAME.so
, par exemple, libFoo.awesome.company.so
. En d'autres termes, libFoo.so
sans le suffixe du nom de l'entreprise NE DOIT PAS être rendu public. Le COMPANYNAME
dans le nom du fichier de bibliothèque DOIT correspondre au COMPANYNAME
dans le nom du fichier txt dans lequel le nom de la bibliothèque est répertorié.
Les bibliothèques natives qui font partie d'AOSP NE DOIVENT PAS être rendues publiques (à l'exception des bibliothèques natives publiques standard qui sont publiques par défaut). Seules les bibliothèques supplémentaires ajoutées par les fournisseurs de silicium ou les fabricants d'appareils peuvent être rendues accessibles aux applications.
À partir d'Android 8.0, les bibliothèques publiques du fournisseur sont soumises aux restrictions supplémentaires et aux configurations requises suivantes :
- La bibliothèque native du fournisseur doit être correctement étiquetée afin d'être accessible aux applications. Si l'accès est requis par des applications (y compris des applications tierces), la bibliothèque doit être étiquetée comme
same_process_hal_file
dans un fichierfile_contexts
spécifique au fournisseur comme suit :/vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
oùlibnative.so
est le nom de la bibliothèque native. - La bibliothèque, directement ou transitivement via ses dépendances, ne doit pas dépendre de bibliothèques système autres que les bibliothèques VNDK-SP et LLNDK. Recherchez la liste des bibliothèques VNDK-SP et LLNDK dans
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv
.
Mise à jour des applications pour ne pas utiliser de bibliothèques natives non publiques
Cette fonctionnalité est activée uniquement pour les applications ciblant la version 24 ou ultérieure du SDK ; pour la rétrocompatibilité, voir Tableau 1. À quoi s'attendre si votre application est liée à des bibliothèques natives privées . La liste des bibliothèques natives Android accessibles aux applications (également appelées bibliothèques natives publiques) est répertoriée dans la section CDD 3.1.1. Les applications ciblant 24 heures ou plus et utilisant des bibliothèques non publiques doivent être mises à jour. Voir Applications NDK liées aux bibliothèques de plate-forme pour plus de détails.
Mise à jour des applications pour leurs dépendances de bibliothèque natives
Les applications qui ciblent la version 31 du SDK (Android 12) ou une version ultérieure doivent spécifier explicitement leurs dépendances de bibliothèque partagée natives à l'aide de la <uses-native-library>
dans le manifeste de l'application. Si une partie de la bibliothèque demandée n'existe pas sur l'appareil, l'application n'est pas installée. Lorsque les applications sont installées, elles ne reçoivent que les bibliothèques partagées natives qu'elles ont demandées. Cela signifie que les applications ne peuvent pas accéder aux bibliothèques partagées natives qui n'apparaissent pas dans le manifeste de l'application.