Kit de développement natif du fournisseur (VNDK)

Le kit de développement natif du fournisseur (VNDK) est un ensemble de bibliothèques exclusivement destinées aux fournisseurs pour implémenter leurs HAL. Le VNDK est livré dans system.img et est lié dynamiquement au code du fournisseur lors de l'exécution.

Pourquoi VNDK ?

Android 8.0 et versions ultérieures permettent des mises à jour du framework uniquement dans lesquelles la partition système peut être mise à niveau vers la dernière version tandis que les partitions du fournisseur restent inchangées. Cela implique que les binaires construits à des moments différents doivent pouvoir fonctionner les uns avec les autres ; VNDK couvre les changements d'API/ABI dans les versions d'Android.

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 des deux côtés pouvaient être liés aux modules de l'autre côté. 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 8.0 et supérieur nécessite 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 8.0 introduit plusieurs techniques telles que VNDK (décrites dans cette section), HIDL , hwbinder, la superposition de l'arborescence des appareils et la superposition sepolicy.

Ressources VNDK

Cette section inclut les ressources VNDK suivantes :

  • Les concepts VNDK (ci-dessous) décrivent les bibliothèques partagées du framework, les HAL de même processus (SP-HAL) et la terminologie VNDK.
  • Les extensions VNDK classent les modifications spécifiques au fournisseur en catégories. Par exemple, les bibliothèques avec des fonctionnalités étendues sur lesquelles reposent les modules du fournisseur doivent être copiées dans la partition du fournisseur, mais les modifications incompatibles avec l'ABI sont interdites.
  • VNDK Build System Support décrit les configurations de système de build et les syntaxes de définition de module qui sont liées à VNDK.
  • L' outil de définition VNDK permet de migrer votre arborescence source vers Android 8.0 et supérieur.
  • L'espace de noms de l'éditeur de liens fournit un contrôle précis sur les liens de bibliothèques partagées.
  • Répertoires, règles et sepolicy définissent la structure de répertoires pour les appareils exécutant Android 8.0 et versions ultérieures, les règles VNDK et la sepolicy associée.
  • La présentation VNDK Design illustre les concepts VDNK fondamentaux utilisés dans Android 8.0 et versions ultérieures.

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. 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 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 vendor_available: false 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)

Terminologie VNDK

  • Les modules font référence aux bibliothèques partagées ou aux exécutables .
  • Les processus sont des tâches du système d'exploitation générées à partir des exécutables .
  • Framework -les termes qualifiés font référence aux concepts liés à la partition système .
  • Les termes qualifiés de fournisseur font référence aux concepts liés aux partitions de fournisseur .

Par example:

  • 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 Framework font référence à la fois aux bibliothèques partagées Framework et aux exécutables Framework .
  • Les processus de framework sont des processus générés à partir des exécutables de framework (par exemple /system/bin/app_process ).
  • 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 de fournisseur font référence à la fois aux exécutables de fournisseur et aux bibliothèques partagées de fournisseur.
  • Les processus du fournisseur sont des processus générés à partir des exécutables du fournisseur (par exemple
  • /vendor/bin/android.hardware.camera.provider@2.4-service ).

Gestion des versions VNDK

Dans Android 9, 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 sont installées dans /system/lib[64]/vndk-${ro.vndk.version} .
  • Les bibliothèques partagées VNDK-SP sont installées dans /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Le fichier de configuration de l'éditeur de liens dynamique est installé dans /system/etc/ld.config.${ro.vndk.version}.txt .

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 ).

Mise à niveau des appareils

Si un appareil Android 8.x a désactivé l'application d'exécution VNDK en étant construit sans BOARD_VNDK_VERSION , il peut ajouter PRODUCT_USE_VNDK_OVERRIDE := false à BoardConfig.mk lors de la mise à niveau vers Android 9.

Si PRODUCT_USE_VNDK_OVERRIDE est false , la propriété ro.vndk.lite sera automatiquement ajoutée à /vendor/default.prop et sa valeur sera true . Par conséquent, l'éditeur de liens dynamique chargera la configuration de l'espace de noms de l'éditeur de liens à partir de /system/etc/ld.config.vndk_lite.txt , qui isole uniquement SP-HAL et VNDK-SP.

Pour mettre à niveau un appareil Android 7.0 ou version antérieure vers Android 9, ajoutez PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false à BoardConfig.mk .

Suite de tests du fournisseur (VTS)

La suite de tests des fournisseurs Android 9 (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.

Si la propriété ro.product.first_api_level est supérieure à 27, la propriété ro.vndk.lite ne doit pas être définie. VtsTreblePlatformVersionTest échouera si ro.vndk.lite est défini dans un appareil Android 9 nouvellement lancé.

Historique du document

Cette section suit les modifications apportées à la documentation VNDK.

Android 9 change

  • Ajouter la section de gestion des versions VNDK.
  • Ajouter la section VTS.
  • Certaines catégories VNDK ont été renommées :
    • LL-NDK-Indirect a été renommé LL-NDK-Private.
    • VNDK-Indirect a été renommé VNDK-Private.
    • VNDK-SP-Indirect-Private a été renommé en VNDK-SP-Private.
    • VNDK-SP-Indirect a été supprimé.

Modifications d'Android 8.1

  • Les bibliothèques SP-NDK ont été fusionnées dans les bibliothèques LL-NDK.
  • Remplacez libui.so par libft2.so dans la section espace de noms RS. C'était une erreur d'inclure libui.so .
  • Ajoutez libGLESv3.so et libandroid_net.so aux bibliothèques LL-NDK.
  • Ajoutez libion.so aux bibliothèques VNDK-SP.
  • Supprimez libstdc++.so des bibliothèques LL-NDK. Utilisez plutôt libc++.so . Certaines versions de chaînes d'outils autonomes peuvent ajouter -lstdc++ aux drapeaux de l'éditeur de liens par défaut. Pour désactiver les valeurs par défaut, ajoutez -nodefaultlibs -lc -lm -ldl à LDFLAGS .
  • Déplacez libz.so de LL-NDK vers les bibliothèques VNDK-SP. Dans certaines configurations, libz.so peut continuer à être LL-NDK. Cependant, il ne devrait pas y avoir de différences observables.