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é des API internes et de résoudre les situations où les applications utilisent accidentellement des bibliothèques de plate-forme au lieu des leurs. Voir l' amélioration de la stabilité avec privée C / C ++ Symbole Restrictions dans Android 7.0 de blog Développeurs Android pour les changements spécifiques de 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.

Espaces de noms pour les bibliothèques natives

Figure 1. Les 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 les bibliothèques de la plate - forme au lieu de leur propre (comme en témoigne avec 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èque respectifs et en les répertoriant explicitement dans .txt des dossiers.

Les dossiers de la bibliothèque sont :

  • /vendor/lib (32 bits) et /vendor/lib64 (64 bits) pour les bibliothèques de fournisseurs de silicium
  • /system/lib (32 bits) et /system/lib64 (64 bits) pour les bibliothèques de fabricants de dispositifs

Les fichiers .txt sont :

  • /vendor/etc/public.libraries.txt pour les bibliothèques de fournisseurs de silicium
  • /system/etc/public.libraries-COMPANYNAME.txt pour les bibliothèques des fabricants de périphériques, où COMPANYNAME fait référence à un 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.

Bibliothèques natives du system partition qui sont rendues publiques par les fabricants d'appareils doivent être nommés 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 au nom de fichier de bibliothèque doit correspondre au COMPANYNAME au nom de fichier txt dans lequel est répertorié le nom de bibliothèque.

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 des fournisseurs ont les restrictions supplémentaires suivantes et les configurations requises :

  1. La bibliothèque native dans le fournisseur doit être correctement étiquetée afin qu'elle puisse être accessible aux applications. Si l' accès est requise par les applications (y compris les applications de tiers), la bibliothèque doit être étiqueté comme same_process_hal_file dans un spécifique au fournisseur file_contexts fichier 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 de manière transitive via ses dépendances, ne doit pas dépendre de bibliothèques système autres que les bibliothèques VNDK-SP et LLNDK. Localisez la liste des bibliothèques VNDK-SP et LLNDK au development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv de 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 compatibilité descendante, voir le tableau 1. Qu'attendre si votre application est un lien avec les 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 ans ou plus et utilisant des bibliothèques non publiques doivent être mises à jour. Voir NDK Apps Établir des liens avec les bibliothèques plate - forme pour plus de détails.

Mise à jour des applications pour leurs dépendances de bibliothèque natives

Les applications version SDK cible 31 (Android 12) ou plus doivent spécifier explicitement leurs dépendances bibliothèque natives partagées en utilisant les <uses-native-library> balise dans le manifeste d'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, ils sont fournis uniquement avec les bibliothèques natives partagées qu'ils ont demandé. 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.