Kit de développement natif du fournisseur (VNDK)

Le Vendor Native Development Kit (VNDK) est un ensemble de bibliothèques exclusivement destiné aux fournisseurs pour implémenter leurs HAL. Les navires VNDK dans system.img et est lié dynamiquement au code fournisseur lors de l' exécution.

Pourquoi VNDK ?

Android 8.0 et versions ultérieures permettent des mises à jour de 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 modifications d'API/ABI dans les versions d'Android.

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

  • La dépendance entre les modules de cadre et les modules de 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 du fournisseur imposaient des restrictions indésirables au développement des modules du framework.
  • Extensions aux bibliothèques PSBA. Android 8.0 et versions ultérieures nécessitent 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, 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 flashage de la partition système avec un GSI standard peut casser l'implémentation HIDL d'un fournisseur. (Pour des directives sur la prévention de ces casses, voir des extensions VNDK .)

Pour relever ces défis, Android 8.0 introduit plusieurs techniques telles que VNDK (décrit dans cette section), HIDL , hwbinder, superposition de l' arborescence des périphériques , et la superposition de sepolicy.

Ressources VNDK

Cette section comprend les ressources VNDK suivantes :

  • Concepts VNDK (ci - dessous) décrit cadre bibliothèques partagées, Hals même processus (SP-Hals), et la terminologie VNDK.
  • Extensions VNDK classifie spécifiques au fournisseur change 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 système de construction support décrit les configurations du système de construction et syntaxes définition du module qui sont liés à VNDK.
  • La VNDK Définition outil permettant de migrer votre source vers Android 8.0 et supérieur.
  • Linker Namespace fournit un contrôle grains fins sur les liens bibliothèque partagée.
  • Répertoires, règles et sepolicy définit la structure de répertoire pour les appareils fonctionnant sous Android 8.0 et plus, les règles VNDK et sepolicy associés.
  • La conception VNDK présentation illustre les concepts fondamentaux VDNK utilisés dans Android 8.0 et supérieur.

Concepts VNDK

Dans un monde Android 8.0 et supérieur idéal, les processus de framework ne chargent pas les bibliothèques partagées des fournisseurs, tous les processus des fournisseurs ne chargent que les bibliothèques partagées des fournisseurs (et une partie des bibliothèques partagées des frameworks), et les communications entre les processus de framework et les processus des fournisseurs 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 de framework ne soient pas suffisantes pour les développeurs de modules de fournisseurs (bien que les API puissent changer entre les versions d'Android), nécessitant qu'une partie des bibliothèques partagées de frameworks soit accessible aux processus des fournisseurs. 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 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 sur plusieurs versions d'Android :

  1. Stabiliser les ABIs / API du cadre commun des bibliothèques. Les nouveaux modules de framework et les anciens modules de fournisseurs 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 toutes les ABI/API exportées par chaque bibliothèque partagée de framework.
  2. Copier ancien cadre des bibliothèques partagées. Livré avec une 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 ne soit figé 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 de framework sont classées en trois sous-catégories :

  • LL-NDK Les bibliothèques sont des bibliothèques partagées Framework qui sont connus 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 ,
  • Éligibles VNDK bibliothèques (VNDK) sont des bibliothèques partagées cadres qui sont sûrs d'être copiés deux fois. Modules cadre et modules fournisseurs peuvent se connecter avec leurs propres copies. Une bibliothèque partagée de framework ne peut devenir une bibliothèque VNDK éligible que 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'objections aux utilisations des fournisseurs.
  • Cadre-Seules les bibliothèques (FWK seulement) sont des bibliothèques partagées cadre qui ne appartiennent pas aux catégories mentionnées ci - dessus. Ces bibliothèques :
    • Sont considérés comme des 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)

Même processus HAL (SP-HAL) est un ensemble de HALS prédéterminées mises en œuvre dans des bibliothèques partagées fournisseur et chargés dans des 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). SP-HALs 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 framework 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

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-privé et ils sont invisibles pour SP-HALS.

Les éléments suivants sont des bibliothèques cadres uniquement avec des exceptions (RS Fwk-Only-RS):

  • libft2.so (renderScript)
  • libmediandk.so (renderScript)

Terminologie VNDK

  • Les modules renvoient à des bibliothèques partagées ou Exécutables.
  • Les processus fonctionnent tâches système donné naissance à de Exécutables.
  • Cadre termes font référence aux qualifiés pour les concepts liés à la partition système.
  • Fournisseurs termes font référence aux qualifiés pour un des concepts liés aux partitions du fournisseur.

Par exemple:

  • Cadre Exécutables se référer à executables dans /system/bin ou /system/xbin .
  • Cadre des bibliothèques partagées se réfèrent à des bibliothèques partagées sous /system/lib[64] .
  • Les modules cadre font référence à la fois cadre des bibliothèques et d'un cadre Exécutables.
  • Les processus-cadres sont des processus donné naissance du Cadre Exécutables (par exemple /system/bin/app_process ).
  • Exécutables des fournisseurs font référence à executables dans /vendor/bin
  • Fournisseurs de bibliothèques partagées se réfèrent à des bibliothèques partagées sous /vendor/lib[64] .
  • Les modules fournisseurs font référence à la fois fournisseur et Exécutables bibliothèques partagées fournisseurs.
  • Processus de fournisseurs sont processus générés à partir du fournisseur Exécutables (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 ro.vndk.version propriété système est automatiquement ajouté à /vendor/default.prop .
  • VNDK bibliothèques partagées sont installées à /system/lib[64]/vndk-${ro.vndk.version} .
  • Bibliothèques partagées VNDK-SP sont installés à /system/lib[64]/vndk-sp-${ro.vndk.version} .
  • Le fichier de configuration de liaison dynamique est installée à /system/etc/ld.config.${ro.vndk.version}.txt .

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

  • Si BOARD_VNDK_VERSION ne correspond pas à current , l' utilisation BOARD_VNDK_VERSION .
  • Si BOARD_VNDK_VERSION est égal à current :
    • Si PLATFORM_VERSION_CODENAME est REL , l' utilisation PLATFORM_SDK_VERSION (par exemple 28 ).
    • Dans le cas contraire, l' utilisation PLATFORM_VERSION_CODENAME (par exemple P ).

Mise à niveau des appareils

Si un dispositif 8.x Android application run-time VNDK désactivé en étant construit sans BOARD_VNDK_VERSION , il peut ajouter PRODUCT_USE_VNDK_OVERRIDE := false à BoardConfig.mk tout en améliorant à Android 9.

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

Pour mettre à niveau un appareil Android 7.0 ou inférieur à Android 9, ajouter PRODUCT_TREBLE_LINKER_NAMESPACES_OVERRIDE := false à BoardConfig.mk .

Suite de tests des fournisseurs (VTS)

Android 9 Test de fournisseur Suite (VTS) mandats non vide ro.vndk.version propriété. Les deux appareils et dispositifs de mise à niveau nouvellement lancé doit définir ro.vndk.version . Certains cas de test VNDK (par exemple VtsVndkFilesTest et VtsVndkDependencyTest ) comptent sur la ro.vndk.version propriété pour charger les bibliothèques admissibles correspondant de VNDK ensembles de données.

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

Historique du document

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

Android 9 change

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

Changements Android 8.1

  • Les bibliothèques SP-NDK ont été fusionnées dans les bibliothèques LL-NDK.
  • Remplacer libui.so avec libft2.so RS section d'espace de noms. Ce fut une erreur d'inclure libui.so .
  • Ajouter libGLESv3.so et libandroid_net.so aux bibliothèques LL-NDK.
  • Ajouter libion.so aux bibliothèques VNDK-SP.
  • Retirer libstdc++.so des bibliothèques LL-NDK. Utilisez libc++.so à la place. Certaines versions de toolchains autonomes peuvent ajouter -lstdc++ aux drapeaux de l' éditeur de liens par défaut. Pour désactiver les paramètres par défaut, ajoutez -nodefaultlibs -lc -lm -ldl à LDFLAGS .
  • Déplacer libz.so de LL-NDK aux bibliothèques VNDK-SP. Dans certaines configurations, libz.so peuvent continuer à être LL-NDK. Cependant, il ne devrait pas y avoir de différences observables.