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

Présentation du kit de développement natif pour les fournisseurs (VNDK)

Le kit de développement natif pour les fournisseurs (VNDK) est un ensemble de bibliothèques utilisées par d'autres bibliothèques ou binaires, dans la partition du fournisseur ou des produits, lors de l'exécution pour dlopen.

Pourquoi le VNDK ?

AOSP autorise les mises à jour du framework uniquement, dans lesquelles la partition système peut être mise à niveau vers la dernière version du framework, tandis que la partition du fournisseur reste inchangée. Bien qu'elle soit construite dans différents fois, les binaires de chaque partition doivent pouvoir fonctionner les uns avec les autres.

Les mises à jour propres au framework présentent les défis suivants:

Dépendance entre les modules du framework et les modules des fournisseurs. Avant Android 8.0, les modules du fournisseur et de la partition système pouvaient être associés. les uns avec les autres. Toutefois, les dépendances des modules des fournisseurs imposent restrictions concernant le développement de modules de framework.
Extensions pour les bibliothèques AOSP. Android nécessite que tous les appareils Android réussissent CTS lorsque la partition système est remplacée avec une image système générique (GSI) standard. Toutefois, à mesure que les fournisseurs étendent AOSP, des bibliothèques pour améliorer les performances ou ajouter des fonctionnalités supplémentaires à leur HIDL implémentations, en flashant la partition système avec un GSI standard peut perturber l'implémentation HIDL d'un fournisseur. Pour obtenir des consignes sur pour empêcher de telles défaillances, consultez Extensions VNDK.

Pour relever ces défis, Android propose plusieurs fonctionnalités : comme VNDK (décrit dans cette section), HIDL, hwbinder, superposition d'arborescence de périphériques, et sepolicy.

Conditions spécifiques au VNDK

Les documents associés au VNDK utilisent la terminologie suivante: <ph type="x-smartling-placeholder">

Les modules font référence soit à des bibliothèques partagées, soit à des exécutables. Les modules rendent la compilation les dépendances.
Les processus sont des tâches du système d'exploitation générées à partir des exécutables. Les processus rendent l'exécution les dépendances.
Les termes qualifiés pour le framework sont liés à la partition system:

Les exécutables de framework font référence à des exécutables dans /system/bin ou /system/xbin
Les bibliothèques partagées de framework font référence aux bibliothèques partagées sous /system/lib[64]
Les modules de framework font référence aux deux bibliothèques partagées du framework. et les exécutables de framework.
Les processus de framework sont des processus créés à partir du framework exécutables, tels que /system/bin/app_process.

Les termes qualifiés pour les fournisseurs sont liés aux partitions vendor:

Les exécutables de fournisseur font référence aux exécutables dans /vendor/bin.
Les bibliothèques partagées des fournisseurs font référence aux bibliothèques partagées sous /vendor/lib[64]
Les modules des fournisseurs font référence à la fois aux exécutables du fournisseur et aux bibliothèques partagées du fournisseur.
Les processus du fournisseur sont ceux générés par le fournisseur. Fichiers exécutables, tels que /vendor/bin/android.hardware.camera.provider@2.4-service.

Concepts du VNDK

Dans un environnement idéal sous Android 8.0 ou version ultérieure, les processus du framework ne se chargent pas. les bibliothèques partagées par les fournisseurs, tous les processus des fournisseurs ne chargent que ces bibliothèques. (et d'une partie des bibliothèques partagées du framework) et les communications entre les processus de framework et les processus des fournisseurs sont régis par HIDL et le matériel binder.

Dans un tel monde, il est possible que des API publiques stables les bibliothèques partagées du framework peuvent ne pas être suffisantes pour les développeurs de modules du fournisseur (bien que les API puissent changer d'une version d'Android à l'autre), ce qui nécessite qu'une partie des bibliothèques partagées du framework sont accessibles aux processus des fournisseurs. De plus, comme de performance peuvent entraîner des compromissions, des délais de réponse essentiels Les HAL doivent être traitées différemment.

Les sections suivantes expliquent comment VNDK gère les bibliothèques partagées du framework pour fournisseurs et HAL Same-Process (SP-HAL).

Bibliothèques partagées pour le fournisseur

Cette section décrit les critères de classification des bibliothèques partagées qui sont accessibles aux processus des fournisseurs. Il existe deux approches pour aider le fournisseur modules sur plusieurs versions d'Android:

Stabiliser les ABI/API des bibliothèques partagées du framework. Les nouveaux modules de framework et ceux des anciens fournisseurs peuvent utiliser la même bibliothèque partagée pour : pour réduire l'espace mémoire utilisé et la taille de l'espace de stockage. Une bibliothèque partagée unique évite également plusieurs problèmes de double chargement. Toutefois, le coût de développement pour maintenir la stabilité Le nombre d'ABI/d'API est élevé, et il est irréaliste de stabiliser toutes les ABI/API exportées par bibliothèque partagée de chaque framework.
Copier les bibliothèques partagées de l'ancien framework. Conçus avec des restriction appliquée aux canaux secondaires, définie comme tous les mécanismes de communication entre les modules du framework et les modules des fournisseurs, y compris, mais sans s'y limiter, binder, socket, pipe, mémoire partagée, fichier partagé et propriétés système. Il y aucune communication, sauf si le protocole de communication est figé et stable (par exemple, HIDL via hwbinder). Le double chargement des bibliothèques partagées peut entraîner les problèmes, Par exemple, si un objet créé par la nouvelle bibliothèque est transmis dans les fonctions de l'ancienne bibliothèque, une erreur peut se produire lorsque ces bibliothèques peut interpréter l'objet différemment.

Différentes approches sont utilisées en fonction des caractéristiques bibliothèques. Par conséquent, les bibliothèques partagées du framework sont classées en trois catégories sous-catégories:

Les bibliothèques LL-NDK sont des bibliothèques partagées de framework. qui sont connus pour être stables. Ses développeurs s'engagent à maintenir Stabilités des API/ABI
- LL-NDK inclut les bibliothèques suivantes: libEGL.so, libGLESv1_CM.so libGLESv2.so, libGLESv3.so libandroid_net.so, libc.so, libdl.so liblog.so, libm.so, libnativewindow.so libneuralnetworks.so, libsync.so. libvndksupport.so et libvulkan.so,
Les bibliothèques VNDK éligibles (VNDK) sont des bibliothèques VNDK partagées de cadre Bibliothèques pouvant être copiées deux fois en toute sécurité. les modules de framework et Les Modules fournisseurs peuvent être reliés avec leurs propres copies. Un cadre partagé ne peut devenir une bibliothèque VNDK éligible que si elle répond aux critères suivants critères: <ph type="x-smartling-placeholder">
- Il n'envoie pas/ne reçoit pas d'IPC vers/depuis le framework.
- Il n'a rien à voir avec la machine virtuelle ART.
- Il ne peut pas lire/écrire de fichiers/partitions dont les formats de fichier sont instables.
- Il ne dispose pas de licence logicielle spéciale qui nécessite une révision légale.
- Le propriétaire du code n'a aucune objection concernant l'utilisation des fournisseurs.
Les bibliothèques de framework uniquement (FWK-UNIQUEMENT) sont des bibliothèques de cadres partagés Bibliothèques qui n'appartiennent pas aux catégories mentionnées ci-dessus. Ces bibliothèques: <ph type="x-smartling-placeholder">
- sont considérés comme des détails d'implémentation interne du framework.
- Les modules des fournisseurs ne peuvent pas y accéder.
- Les ABI/API sont instables et aucune garantie de compatibilité entre les API et les ABI.
- ne sont pas copiées ;

HAL Same-Process (SP-HAL)

HAL Same-Process (SP-HAL) est un ensemble de HAL prédéterminés implémentées en tant que bibliothèques partagées de fournisseurs et chargées dans Framework Processus. Les SP-HAL sont isolés par un espace de noms de l'éditeur de liens (contrôle le et les symboles visibles par les bibliothèques partagées). Les SP-HAL doivent dépendent uniquement de LL-NDK et VNDK-SP.

VNDK-SP est un sous-ensemble prédéfini de bibliothèques VNDK éligibles. Bibliothèques VNDK-SP sont examinés attentivement pour garantir le double chargement des bibliothèques VNDK-SP dans le framework processus ne cause pas de problèmes. Les ressources SP-HAL et VNDK-SP sont définies Google

Les bibliothèques suivantes sont des SP-HAL approuvées:

libGLESv1_CM_${driver}.so
libGLESv2_${driver}.so
libGLESv3_${driver}.so
libEGL_${driver}.so
vulkan.${driver}.so
android.hardware.renderscript@1.0-impl.so
android.hardware.graphics.mapper@2.0-impl.so

Les bibliothèques VNDK-SP spécifient vndk: { support_system_process: true } dans leurs fichiers Android.bp. Si vndk: {private:true} est également spécifiées, ces bibliothèques sont appelées VNDK-SP-Private et sont invisible pour SP-HALS.

Voici des bibliothèques compatibles avec le framework, avec des exceptions RS (FWK-UNIQUEMENT-RS):

libft2.so (RenderScript)
libmediandk.so (RenderScript)

Gestion des versions VNDK

Les bibliothèques partagées du VNDK sont gérées par version:

La propriété système ro.vndk.version est automatiquement ajoutée à /vendor/default.prop
Les bibliothèques partagées VNDK et VNDK-SP sont installées en tant qu'apex VNDK com.android.vndk.v${ro.vndk.version} et installées sur /apex/com.android.vndk.v${ro.vndk.version}

La valeur de ro.vndk.version est choisie par l'algorithme ci-dessous:

Si BOARD_VNDK_VERSION n'est pas égal à current, utilisez BOARD_VNDK_VERSION.
Si BOARD_VNDK_VERSION est égal à current:

Si PLATFORM_VERSION_CODENAME est défini sur REL, utilisez PLATFORM_SDK_VERSION (par exemple, 28).
Sinon, utilisez PLATFORM_VERSION_CODENAME (par exemple, P).

Suite de test pour les fournisseurs (VTS)

Android Vendor Test Suite (VTS) exige un propriété ro.vndk.version non vide. Les deux nouveaux appareils et les appareils mis à niveau doivent définir ro.vndk.version. Certains tests VNDK (par exemple, VtsVndkFilesTest et VtsVndkDependencyTest) s'appuient sur le ro.vndk.version pour charger les ensembles de données des bibliothèques VNDK éligibles correspondantes.