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é de l'API interne et de résoudre les situations dans lesquelles les applications utilisent accidentellement les bibliothèques de plateforme au lieu des leurs. Consultez l’article de blog Améliorer la stabilité avec les restrictions de symboles C/C++ privés dans Android 7.0 pour les développeurs Android pour connaître les modifications spécifiques à l’application.

Architecture

Sous Android 7.0 et versions ultérieures, les bibliothèques système sont séparées des bibliothèques d'applications.

Espaces de noms pour les bibliothèques natives

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 dans lesquelles les applications utilisent accidentellement les bibliothèques de la plateforme au lieu des leurs (comme en témoigne libpng ). Il est difficile pour les bibliothèques d’applications d’utiliser les 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èques respectifs et en les répertoriant explicitement au format .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 des 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 (comme 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 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 de l'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 des fournisseurs sont soumises aux restrictions supplémentaires et configurations requises suivantes :

  1. La bibliothèque native du fournisseur doit être correctement étiquetée afin qu'elle puisse ê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
    libnative.so est le nom de la bibliothèque native.
  2. La bibliothèque, que ce soit 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 .

Mettre à jour les 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 compatibilité ascendante, consultez le 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 3.1.1 du CDD. Les applications ciblant 24 ou version ultérieure et utilisant des bibliothèques non publiques doivent être mises à jour. Voir Applications NDK liées aux bibliothèques de plateforme 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 native à l'aide de la balise <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 reçoivent uniquement 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.