Cette page a été traduite par l'API Cloud Translation.

Espaces de noms pour les bibliothèques natives

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 que awesome.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 fichier file_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.