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é des API internes et de résoudre les situations où les applications utilisent accidentellement des bibliothèques de plate-forme au lieu de leurs propres bibliothèques. Pour en savoir plus sur les modifications spécifiques aux applications, consultez l'article de blog des développeurs Android Améliorer la stabilité avec les restrictions de symboles C/C++ privées dans Android 7.0.

Architecture

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

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 élimine également les situations où les applications utilisent accidentellement des bibliothèques de plate-forme au lieu des leurs (comme c'est le cas avec libpng). Il est difficile pour les bibliothèques d'applications d'utiliser accidentellement des bibliothèques système internes (et inversement).

Ajouter des bibliothèques natives supplémentaires

En plus des bibliothèques natives publiques standards, 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 listant explicitement dans des fichiers .txt.

Les dossiers de bibliothèque sont les suivants:

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

Les fichiers .txt sont les suivants:

/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 (par exemple, 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 sur un appareil si certaines bibliothèques proviennent de fournisseurs de solutions externes.

Les bibliothèques natives dans la partition system qui sont rendues publiques par les fabricants d'appareils 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. La COMPANYNAME dans le nom du fichier de bibliothèque DOIT correspondre à l'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 standards, 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 et configurations supplémentaires suivantes:

La bibliothèque native du fournisseur doit être correctement libellée pour être accessible aux applications. Si l'accès est requis par des applications (y compris des applications tierces), la bibliothèque doit être libellé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 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. Recherchez la liste des 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 du fournisseur peuvent être placées dans un APEX du fournisseur. Une fois empaquetées dans un APEX de fournisseur, répertoriez les bibliothèques 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 la version 24 ou ultérieure du SDK. Pour la rétrocompatibilité, consultez la tableau 1 . À quoi vous attendre si votre application associe des bibliothèques natives privées La liste des bibliothèques natives Android accessibles aux applications (également appelées bibliothèques natives publiques) est indiquée dans la section 3.1.1 du CDD. Les applications ciblant la version 24 ou ultérieure et utilisant des bibliothèques non publiques doivent être mises à jour. Pour en savoir plus, consultez la section Association d'applications NDK à des bibliothèques de plate-forme .

Mettre à jour les applications pour leurs dépendances de bibliothèques 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 fichier 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 fichier manifeste de l'application.