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

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Le kit de développement natif du fournisseur (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 de 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 soient construits à des moments différents, les fichiers 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 du fournisseur et de la partition système pouvaient être liés les uns aux autres. Cependant, les dépendances des modules des fournisseurs imposaient des restrictions indésirables au développement des modules du framework.
  • Extensions aux bibliothèques AOSP . Android exige que tous les appareils Android passent CTS lorsque la partition système est remplacée par une image système générique (GSI) standard. Cependant, comme 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 fait de flasher la partition système avec un GSI standard peut casser l'implémentation HIDL d'un fournisseur. Pour obtenir des instructions sur la prévention de telles ruptures, consultez Extensions VNDK .

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

Termes spécifiques à VNDK

Les documents liés à VNDK utilisent la terminologie suivante :
  • Les modules font référence à des bibliothèques partagées ou à 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.
  • Framework -les termes qualifiés 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 de fournisseur sont liés aux partitions de 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 .

Notions VNDK

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

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 de fournisseur (bien que les API puissent changer entre les versions d'Android), nécessitant 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, certaines HAL critiques en termes de temps de réponse doivent être traitées différemment.

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

Bibliothèques partagées du framework pour le fournisseur

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

  1. Stabiliser les ABI/API des librairies partagées du framework . Les nouveaux modules de framework et les anciens modules de fournisseur peuvent utiliser la même bibliothèque partagée pour réduire l'empreinte mémoire et la taille de 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 de framework.
  2. Copiez les anciennes bibliothèques partagées du framework . Livré avec la forte restriction contre les canaux secondaires, définis comme tous les mécanismes de communication entre les modules de framework et les modules de fournisseur, y compris (mais sans s'y limiter) le classeur, le socket, le canal, la mémoire partagée, le fichier partagé et les propriétés 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 des bibliothèques partagées peut également causer des problèmes ; par exemple, si un objet créé par la nouvelle bibliothèque est passé dans les 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. En conséquence, 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 la stabilité de leur 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 partagées Framework qui peuvent être copiées deux fois en toute sécurité. Les modules Framework et les modules Vendor peuvent être liés à leurs propres copies. Une bibliothèque partagée de framework peut devenir une bibliothèque VNDK éligible uniquement si elle répond aux critères suivants :
    • Il n'envoie/reçoit pas d'IPC vers/depuis le framework.
    • Il n'est pas lié à la machine virtuelle ART.
    • Il ne lit/écrit pas les fichiers/partitions avec des formats de fichiers instables.
    • Il n'a pas de licence logicielle spéciale qui nécessite des examens juridiques.
    • Son propriétaire de code n'a pas d'objection aux usages du fournisseur.
  • 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 détails de mise en œuvre interne du cadre.
    • Ne doit pas être accessible par les 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 les fournisseurs et chargés dans les processus Framework . Les SP-HAL sont isolés par un espace de noms de l'éditeur de liens (contrôle les bibliothèques et les symboles visibles pour 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 d'infrastructure ne pose pas de problèmes. Les SP-HAL et 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é, ces bibliothèques sont appelées VNDK-SP-Private et elles sont invisibles pour SP-HALS.

Les bibliothèques suivantes sont réservées au framework avec des exceptions RS (FWK-ONLY-RS) :

  • libft2.so (script de rendu)
  • 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 que VNDK apex 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 du fournisseur (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 scénarios de test VNDK (par exemple, VtsVndkFilesTest et VtsVndkDependencyTest ) s'appuient sur la propriété ro.vndk.version pour charger les ensembles de données de bibliothèques VNDK éligibles correspondants.