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

Espaces de noms pour les bibliothèques natives

Android 7.0 introduit des espaces de noms pour les bibliothèques natives afin de limiter l'API interne visibilité et résoudre les cas d'utilisation accidentelle de la plate-forme par les applications bibliothèques au lieu des leurs. Reportez-vous à la section Amélioration Stabilité avec des restrictions de symboles C/C++ privées sous Android 7.0 Android Article du blog des développeurs concernant les modifications spécifiques aux applications.

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 une application native de plate-forme privée (comme cela a été fait avec OpenSSL). Cela élimine également les situations où les applications utilisent accidentellement des bibliothèques de plate-forme au lieu des leurs avec libpng). Il est difficile pour les bibliothèques d'applications d'utiliser les bibliothèques système par accident (et vice versa).

Ajouter des bibliothèques natives supplémentaires

En plus des bibliothèques natives publiques standards, les fournisseurs de puces (à 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 leurs dossiers de bibliothèque respectifs et en les répertoriant explicitement dans des fichiers .txt.

Les dossiers de la bibliothèque sont les suivants:

/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 de fabricants d'appareils

Les fichiers .txt sont les suivants:

/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 d'appareils où COMPANYNAME fait référence à un nom du fabricant (par exemple, awesome.company). COMPANYNAME doit correspondre à [A-Za-z0-9_.-]+; caractères alphanumériques, _, . (point) et -. Il est possible de avoir plusieurs fichiers .txt de ce type dans un appareil si certaines bibliothèques proviennent d'une solution externe fournisseurs de services cloud.

Bibliothèques natives de la partition system rendues publiques par les fabricants d'appareils DOIT être nommé 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. L'COMPANYNAME du nom du fichier de la bibliothèque DOIT correspondre à l'COMPANYNAME dans le 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 (sauf bibliothèques natives publiques 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 rendus accessibles aux applications.

À partir d'Android 8.0, les bibliothèques publiques des fournisseurs disposent des fonctionnalités supplémentaires suivantes : restrictions et configurations requises:

La bibliothèque native du fournisseur doit être correctement libellée pour pouvoir être accessibles aux applications. Si l'accès est requis par une application (y compris des applications tierces applications tierces), la bibliothèque doit être associée au libellé 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, que ce soit directement ou de manière transitoire via ses dépendances, ne doit pas dépendent de bibliothèques système autres que VNDK-SP et LLNDK. Localisez la liste les bibliothèques VNDK-SP et LLNDK à l'adresse development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv

À partir d'Android 15, les bibliothèques publiques des fournisseurs peuvent être placées apex du fournisseur. Lorsque les bibliothèques sont empaquetées dans un APEX de fournisseur, dans une propriété provideNativeLibs du fichier manifeste APEX.

Mettre à jour les applications pour qu'elles n'utilisent pas de bibliothèques natives non publiques

Cette fonctionnalité n'est activée que pour les applications ciblant le SDK version 24 ou ultérieure. pour assurer la rétrocompatibilité, consultez la section Tableau 1.Que se passe-t-il si votre application est associée à des bibliothèques natives privées ? La liste des bibliothèques natives Android accessibles aux applications (également appelée bibliothèques natives publiques) est répertoriée dans la section 3.1.1 du CDD. Applications ciblant 24 ou et l'utilisation de bibliothèques non publiques doit être mise à jour. Voir le NDK Liens entre des applications et des bibliothèques de la plate-forme .

Mettre à jour les applications pour les dépendances de leur bibliothèque native

Les applications qui ciblent la version 31 du SDK (Android 12) ou une version ultérieure doivent spécifier explicitement leurs dépendances natives de bibliothèque partagée à l'aide de la classe Balise <uses-native-library> dans le fichier manifeste de l'application. Si une partie de la requête n'existe pas sur l'appareil, l'application n'est pas installée. Une fois les applications installées, fourni uniquement les bibliothèques partagées natives qu'il a demandées. Cela signifie que les applications ne peuvent pas accéder aux bibliothèques partagées natives qui n'apparaissent pas dans leur fichier manifeste.