Présentation du kit de développement natif du fournisseur (VNDK)

Le Vendor Native Development Kit (VNDK) est un ensemble de bibliothèques utilisées par d'autres bibliothèques ou binaires, dans la partition du fournisseur ou du produit, lors de l'exécution pour dlopen.

Pourquoi 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'ils aient été construits à des moments différents, les binaires de chaque partition doivent pouvoir fonctionner les uns avec les autres.

Les mises à jour du framework uniquement incluent les défis suivants :

  • Dépendance entre les modules du framework et les modules du fournisseur . Avant Android 8.0, les modules de la partition fournisseur et système pouvaient être liés les uns aux autres. Cependant, les dépendances des modules du fournisseur imposaient des restrictions indésirables au développement des modules de structure.
  • Extensions aux bibliothèques AOSP . Android exige que tous les appareils Android passent le CTS lorsque la partition système est remplacée par une image système générique (GSI) standard. Cependant, à mesure que les fournisseurs étendent les bibliothèques AOSP pour améliorer les performances ou pour ajouter des fonctionnalités supplémentaires à leurs implémentations HIDL, le flashage de la partition système avec un GSI standard peut interrompre l'implémentation HIDL d'un fournisseur. Pour obtenir des directives sur la prévention de telles ruptures, consultez Extensions VNDK .

Pour relever ces défis, Android contient plusieurs fonctionnalités telles que VNDK (décrit dans cette section), HIDL , hwbinder, la superposition de l'arborescence des appareils et la superposition de stratégie.

Termes spécifiques au VNDK

Les documents liés au VNDK utilisent la terminologie suivante :
  • Les modules font référence soit à des bibliothèques partagées, soit à des exécutables. Les modules créent des dépendances au moment de la construction.
  • Les processus sont des tâches du système d'exploitation générées à partir d'exécutables. Les processus créent des dépendances d'exécution.
  • Les termes qualifiés par Framework sont liés à la partition system :
    • Les exécutables du framework font référence aux exécutables dans /system/bin ou /system/xbin .
    • Les bibliothèques partagées du framework font référence aux bibliothèques partagées sous /system/lib[64] .
    • Les modules de framework font référence à la fois aux bibliothèques partagées du framework et aux exécutables du framework.
    • Les processus de framework sont des processus générés à partir d'exécutables de framework, tels que /system/bin/app_process .
  • Les termes qualifiés par le fournisseur sont liés aux partitions vendor :
    • Les exécutables du fournisseur font référence aux exécutables dans /vendor/bin
    • Les bibliothèques partagées du fournisseur font référence aux bibliothèques partagées sous /vendor/lib[64] .
    • Les modules du fournisseur font référence à la fois aux exécutables du fournisseur et aux bibliothèques partagées du fournisseur.
    • Les processus du fournisseur sont des processus générés à partir des exécutables du fournisseur, tels que /vendor/bin/android.hardware.camera.provider@2.4-service .

Concepts VNDK

Dans un monde idéal Android 8.0 et supérieur, les processus de framework ne chargent pas les bibliothèques partagées du fournisseur, tous les processus du fournisseur chargent uniquement les bibliothèques partagées du fournisseur (et une partie des bibliothèques partagées du framework), et les communications entre les processus de framework et les processus du fournisseur sont régies par HIDL et le matériel. classeur.

Un tel monde inclut la possibilité que les API publiques stables des bibliothèques partagées du framework ne soient pas suffisantes pour les développeurs de modules du fournisseur (bien que les API puissent changer entre les versions d'Android), exigeant qu'une partie des bibliothèques partagées du framework soit accessible aux processus du fournisseur. De plus, comme les exigences de performances peuvent conduire à des compromis, certains HAL critiques en termes de temps de réponse doivent être traités différemment.

Les sections suivantes détaillent comment VNDK gère les bibliothèques partagées de framework pour les fournisseurs et les HAL de même processus (SP-HAL).

Bibliothèques partagées de framework pour le fournisseur

Cette section décrit les critères de classification des bibliothèques partagées accessibles aux processus des fournisseurs. Il existe deux approches pour prendre en charge les modules des fournisseurs dans plusieurs versions d'Android :

  1. Stabiliser les ABI/API des bibliothèques partagées du framework . Les nouveaux modules de structure et les anciens modules des fournisseurs peuvent utiliser la même bibliothèque partagée pour réduire l'empreinte mémoire et la taille du stockage. Une bibliothèque partagée unique évite également plusieurs problèmes de double chargement. Cependant, le coût de développement pour maintenir des ABI/API stables est élevé et il est irréaliste de stabiliser tous les ABI/API exportés par chaque bibliothèque partagée du framework.
  2. Copiez les anciennes bibliothèques partagées du framework . Livré avec une forte restriction contre les canaux secondaires, définis comme tous les mécanismes permettant de communiquer entre les modules de structure et les modules du fournisseur, y compris (mais sans s'y limiter) les propriétés du classeur, du socket, du canal, de la mémoire partagée, du fichier partagé et du système. Il ne doit y avoir aucune communication à moins que le protocole de communication soit gelé et stable (par exemple HIDL via hwbinder). Le double chargement de bibliothèques partagées peut également causer des problèmes ; par exemple, si un objet créé par la nouvelle bibliothèque est transmis aux fonctions de l'ancienne bibliothèque, une erreur peut se produire car ces bibliothèques peuvent interpréter l'objet différemment.

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

  • Les bibliothèques LL-NDK sont des bibliothèques partagées Framework connues pour être stables. Leurs développeurs s'engagent à maintenir leurs stabilités API/ABI.
    • LL-NDK comprend 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 partagées Framework qui peuvent être copiées deux fois en toute sécurité. Les modules framework et les modules fournisseur peuvent être liés à leurs propres copies. Une bibliothèque partagée framework peut devenir une bibliothèque VNDK éligible uniquement si elle satisfait aux critères suivants :
    • Il n’envoie/reçoit pas d’IPC vers/depuis le framework.
    • Ce n'est pas lié à la machine virtuelle ART.
    • Il ne lit/écrit pas les fichiers/partitions aux formats de fichiers instables.
    • Il ne dispose pas de licence logicielle spéciale qui nécessite des examens juridiques.
    • Son propriétaire de code n'a pas d'objections aux utilisations des fournisseurs.
  • Les bibliothèques Framework-Only (FWK-ONLY) sont des bibliothèques partagées Framework qui n'appartiennent pas aux catégories mentionnées ci-dessus. Ces bibliothèques :
    • Sont considérés comme des détails de mise en œuvre internes du cadre.
    • Ne doit pas être accessible aux modules du fournisseur.
    • Avoir des ABI/API instables et aucune garantie de compatibilité API/ABI.
    • Ne sont pas copiés.

HAL de même processus (SP-HAL)

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

VNDK-SP est un sous-ensemble prédéfini de bibliothèques VNDK éligibles. Les bibliothèques VNDK-SP sont soigneusement examinées pour garantir que le double chargement des bibliothèques VNDK-SP dans les processus de structure ne pose pas de problèmes. Les SP-HAL et les VNDK-SP sont définis par 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é, alors ces bibliothèques sont appelées VNDK-SP-Private et elles sont invisibles pour SP-HALS.

Les bibliothèques suivantes sont uniquement des bibliothèques de framework avec des exceptions RS (FWK-ONLY-RS) :

  • libft2.so (Renderscript)
  • libmediandk.so (Renderscript)

Gestion des versions VNDK

Les bibliothèques partagées VNDK sont versionnées :

  • 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 monté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 REL , utilisez PLATFORM_SDK_VERSION (par exemple 28 ).
    • Sinon, utilisez PLATFORM_VERSION_CODENAME (par exemple P ).

Suite de tests des fournisseurs (VTS)

La suite de tests de fournisseurs Android (VTS) impose une propriété ro.vndk.version non vide. Les appareils nouvellement lancés et les appareils mis à niveau doivent définir ro.vndk.version . Certains cas de test VNDK (par exemple, VtsVndkFilesTest et VtsVndkDependencyTest ) s'appuient sur la propriété ro.vndk.version pour charger les ensembles de données des bibliothèques VNDK éligibles correspondants.