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 du produit, lors de l'exécution pour Dlopen.

Abandon

Le NDK fournisseur a été introduit dans Android 8.0 pour fournir des API entre le framework et le code du fournisseur. Bien que le VNDK soit utilisé depuis de nombreuses années, il présente certains inconvénients :
  • Stockage
    • Un seul APEX VNDK empaquette toutes les bibliothèques VNDK, qu'elles soient utilisées depuis l'appareil ou non.
    • Le GSI contient plusieurs versions d'APEX VNDK pour prendre en charge plusieurs versions d'images du fournisseur.
  • Facilité de mise à jour
    • Il est difficile de mettre à jour les APEX VNDK indépendamment de la mise à jour de la plate-forme.
    • Les images du fournisseur sont fréquemment mises à jour en mode Over The Air (OTA), ce qui réduit les avantages d'avoir un VNDK empaqueté dans l'image système.
En raison de ces problèmes, nous avons décidé d'abandonner le VNDK à partir d'Android 15.

Détails sur l'abandon du VNDK

Toutes les bibliothèques VNDK sont empaquetées dans l'APEX VNDK et installées dans l'image système (-ext). Avec l'abandon du VNDK, les anciennes bibliothèques VNDK sont installées dans l'image du fournisseur (ou du produit), comme les autres bibliothèques disponibles auprès du fournisseur. Ces fonctionnalités sont supprimées avec l'abandon du VNDK :
  • VNDK APEX pour Android 15
  • Les propriétés système qui indiquent la version du VNDK cible sont supprimées si les partitions du fournisseur ou du produit sont compilées pour Android 15 :
    • ro.vndk.version
    • ro.product.vndk.version
  • Les optimisations VNDK ne seront pas disponibles, car il n'existe pas de VNDK :
    • TARGET_VNDK_USING_CORE_VARIANT pour les appareils Android Go
    • use_vndk_as_stable pour les APEX du fournisseur
  • Instantané du fournisseur, qui dépend fortement du VNDK

Exceptions à l'abandon

Ces fonctionnalités ne changeront pas avec l'abandon du VNDK :
  • APEX VNDK avec la version 14 ou antérieure du VNDK, qui est nécessaire pour prendre en charge les images de fournisseurs existantes.
  • LL-NDK ne fait pas partie du VNDK.

Pourquoi VNDK ?

AOSP permet 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 compilés à des moments différents, les binaires de chaque partition doivent pouvoir fonctionner les uns avec les autres.

Les mises à jour du framework uniquement présentent 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 du fournisseur et du système pouvaient s'associer les uns aux autres. Toutefois, les dépendances des modules du fournisseur imposaient des restrictions indésirables au développement des modules du framework.
  • Extensions aux bibliothèques AOSP Android exige que tous les appareils Android réussissent les tests CTS lorsque la partition système est remplacée par une image système générique (GSI) standard. Toutefois, comme les fournisseurs étendent les bibliothèques AOSP pour améliorer les performances ou ajouter des fonctionnalités supplémentaires à leurs implémentations HIDL, flasher la partition système avec un GSI standard peut endommager l'implémentation HIDL d'un fournisseur. Pour obtenir des conseils sur la prévention de ces erreurs, consultez la section Extensions VNDK.

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

Conditions spécifiques au VNDK

Les documents liés au VNDK utilisent la terminologie suivante :
  • Les modules désignent des bibliothèques partagées ou des exécutables. Les modules créent des dépendances au moment de la compilation.
  • Les processus sont des tâches du système d'exploitation générées à partir des exécutables. Les processus créent des dépendances d'exécution.
  • Les termes qualifiés pour le framework sont liés à la partition system:
    • Les exécutables de 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 de framework.
    • Les processus de framework sont des processus créés à partir d'exécutables de framework, tels que /system/bin/app_process.
  • Les termes qualifiés de 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 et aux bibliothèques partagées du fournisseur.
    • Les processus du fournisseur sont des processus créés à partir d'exécutables du fournisseur, tels que /vendor/bin/android.hardware.camera.provider@2.4-service.

Concepts VNDK

Dans un monde idéal d'Android 8.0 ou version ultérieure, les processus de framework ne chargent pas les bibliothèques partagées par les fournisseurs, tous les processus des fournisseurs ne chargent que les bibliothèques partagées par les fournisseurs (et une partie des bibliothèques partagées du framework), et les communications entre les processus du framework et les processus des fournisseurs sont régies par le HIDL et la liaison matérielle.

Dans un tel monde, il est possible que des API publiques stables provenant de bibliothèques partagées de framework ne soient pas 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 soit accessible aux processus des fournisseurs. De plus, comme les exigences de performances peuvent entraîner des compromis, certaines HAL critiques en termes de temps de réponse doivent être traitées différemment.

Les sections suivantes expliquent comment VNDK gère les bibliothèques partagées de framework pour les fournisseurs et les HAL Same-Process (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 des fournisseurs. Il existe deux approches pour prendre en charge les modules du fournisseur sur plusieurs versions d'Android:

  1. Stabilisez les ABI/API des bibliothèques partagées du framework. 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. Toutefois, 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. Copiez les anciennes bibliothèques partagées du framework. Inclut une restriction stricte contre les canaux secondaires, définis comme tous les mécanismes de communication entre les modules de framework et les modules du fournisseur, y compris (mais sans s'y limiter) le liaisonneur, le socket, le tube, la mémoire partagée, le fichier partagé et les propriétés système. Aucune communication ne doit être établie, sauf si le protocole de communication est 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 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. Par conséquent, 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 de framework connues pour être stables. Leurs développeurs s'engagent à maintenir la stabilité de leurs 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 (VNDK) éligibles sont des bibliothèques partagées de framework que vous pouvez copier deux fois sans risque. Les modules de framework et les modules de fournisseur peuvent s'associer à 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 pas/ne reçoit pas d'IPC vers/depuis le framework.
    • Il n'a rien à voir avec la machine virtuelle ART.
    • Il ne lit ni n'écrit pas de fichiers/partitions avec des formats de fichiers instables.
    • Il ne dispose pas d'une licence logicielle spéciale nécessitant des examens juridiques.
    • Le propriétaire du code n'a pas d'objection à l'utilisation par le fournisseur.
  • Les bibliothèques réservées au framework (FWK-ONLY) sont des bibliothèques partagées de framework qui n'appartiennent pas aux catégories mentionnées ci-dessus. Ces bibliothèques :
    • sont considérés comme des détails d'implémentation internes au framework.
    • Les modules du fournisseur ne doivent 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)

Le HAL du même processus (SP-HAL) est un ensemble de HAL prédéterminés implémentés en tant que bibliothèques partagées du fournisseur et chargés dans les processus de framework. Les SP-HAL sont isolés par un espace de noms de l'éditeur de liens (qui contrôle les bibliothèques et les symboles visibles par les bibliothèques partagées). Les ressources SP-HAL ne doivent dépendre que 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 examinées attentivement pour s'assurer que le double chargement des bibliothèques VNDK-SP dans les processus de framework ne pose pas de problème. Les SP-HAL et les VNDK-SP sont tous deux 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 sont invisibles pour les SP-HALS.

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

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

Gestion des versions du 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 com.android.vndk.v${ro.vndk.version} VNDK apex 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 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)

La suite de test de fournisseur (VTS) Android exige 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) reposent sur la propriété ro.vndk.version pour charger les ensembles de données de bibliothèques VNDK éligibles correspondants.