Présentation du kit de développement natif pour les éditeurs (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.

Obsolescence

Le NDK du 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é avec succès depuis de nombreuses années, il présente certains inconvénients :

• Stockage
• Un seul package VNDK APEX regroupe toutes les bibliothèques VNDK, qu'elles soient utilisées ou non par l'appareil.
• La GSI contient plusieurs versions des APEX VNDK pour prendre en charge plusieurs versions des images du fournisseur.
• Facilité de mise à jour
• Il est difficile de mettre à jour les APEX VNDK séparément de la mise à jour de la plate-forme.
• Les images du fournisseur sont fréquemment mises à jour en mode OTA (Over The Air), ce qui réduit les avantages de l'intégration du VNDK 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 de VNDK

Toutes les bibliothèques VNDK sont regroupées dans le VNDK APEX 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 pour le fournisseur. Ces fonctionnalités sont supprimées en même temps que 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 conçues pour Android 15 :
  • ro.vndk.version
  • ro.product.vndk.version
• Les optimisations VNDK ne seront pas disponibles, car il n'y a pas de VNDK :
  • TARGET_VNDK_USING_CORE_VARIANT pour les appareils Android Go
  • use_vndk_as_stable pour les APEX de fournisseur
• Instantané du fournisseur, qui dépend fortement du VNDK

Exceptions à l'arrêt

Ces fonctionnalités ne changeront pas avec l'abandon du VNDK :

• Les APEX VNDK avec la version 14 ou antérieure du VNDK, qui sont nécessaires pour prendre en charge les images de fournisseur existantes.
• LL-NDK ne fait pas partie du VNDK.

Pourquoi le 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 créés à des moments différents, les binaires de chaque partition doivent pouvoir fonctionner ensemble.

Les mises à jour du framework uniquement présentent les difficultés suivantes :

• Dépendance entre les modules du framework et les modules du fournisseur. Avant Android 8.0, les modules des partitions fournisseur et système pouvaient être associés les uns aux autres. Toutefois, les dépendances des modules du fournisseur ont imposé des restrictions indésirables au développement des modules du framework.
• Extensions des 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, le flashage de la partition système avec une GSI standard peut interrompre l'implémentation HIDL d'un fournisseur. Pour obtenir des consignes sur la prévention de ces problèmes, consultez Extensions VNDK.

Pour relever ces défis, Android contient plusieurs fonctionnalités telles que VNDK (décrit dans cette section), HIDL, hwbinder, device tree overlay et sepolicy overlay.

Conditions spécifiques au VNDK

Les documents liés au VNDK utilisent la terminologie suivante :

• Les modules font référence aux bibliothèques partagées ou aux 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 d'exécutables. Les processus créent des dépendances d'exécution.
• Les termes qualifiés 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 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 fournisseur sont associés aux partitions vendor :
• Les exécutables du fournisseur font référence aux exécutables dans /vendor/bin.
• Les bibliothèques partagées des fournisseurs 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 générés à partir d'exécutables du fournisseur, tels que /vendor/bin/android.hardware.camera.provider@2.4-service.

Remarque : Image système générique (GSI) désigne l'image système Android standard qui est créée à partir des branches correspondantes (semblables à la branche de version, mais avec quelques corrections de bugs ou généralisations) et publiée par Google.

Concepts VNDK

Dans un monde idéal avec Android 8.0 et versions ultérieures, 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 binder matériel.

Un tel monde inclut la possibilité que les API publiques et stables des bibliothèques partagées du framework ne soient pas suffisantes pour les développeurs de modules fournisseurs (bien que les API puissent changer entre les versions d'Android), 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 en détail comment le VNDK gère les bibliothèques partagées du framework pour les fournisseurs et les HAL (Same-Process HALs, HAL du même processus).

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 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 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 permet également d'éviter plusieurs problèmes de double chargement. Toutefois, le coût de développement pour maintenir des ABI/API stables est élevé et il n'est pas réaliste de stabiliser toutes les ABI/API exportées par chaque bibliothèque partagée du framework.
2. Copiez les anciennes bibliothèques partagées du framework. Il est soumis à une restriction forte contre les canaux auxiliaires, définis comme tous les mécanismes de communication entre les modules du framework et les modules du fournisseur, y compris (mais sans s'y limiter) Binder, les sockets, les pipes, la mémoire partagée, les fichiers partagés et les propriétés système. Il ne doit y avoir aucune communication, 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 poser problème. 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 du framework connues pour leur stabilité. Leurs développeurs s'engagent à maintenir la stabilité de leur API/ABI.
  • Le 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 sont des bibliothèques partagées du framework qui peuvent être copiées deux fois sans risque. Les modules de framework et les modules de fournisseur peuvent être associés à 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 ni ne reçoit d'IPC vers/depuis le framework.
  • Il n'est pas lié à la machine virtuelle ART.
  • Il ne lit ni n'écrit les fichiers/partitions dont le format est instable.
  • Il ne dispose pas de licence logicielle spéciale nécessitant des examens juridiques.
  • Le propriétaire du code n'a aucune objection à l'utilisation par des fournisseurs.
• Les bibliothèques Framework-Only (FWK-ONLY) sont des bibliothèques Framework Shared 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.
  • Ils disposent d'ABI/API instables et n'offrent aucune garantie de compatibilité d'ABI/API.
  • ne sont pas copiés.

HAL du même processus (SP-HAL)

La HAL du même processus (SP-HAL) est un ensemble de HAL prédéterminées implémentées en tant que bibliothèques partagées du fournisseur et chargées dans les processus du framework. Les SP-HAL sont isolés par un espace de noms d'éditeur de liens (qui contrôle les bibliothèques et les symboles visibles par les bibliothèques partagées). Les 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 avec soin pour s'assurer que le double chargement des bibliothèques VNDK-SP dans les processus du framework ne pose pas de problème. 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
• [e-mail]
• [e-mail]

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 SP-HALS.

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

• libft2.so (RenderScript)
• libmediandk.so (RenderScript)

Attention : Les API RenderScript sont obsolètes à partir d'Android 12. Elles continueront de fonctionner, mais les fabricants d'appareils et de composants devraient cesser de proposer la prise en charge de l'accélération matérielle au fil du temps. Pour profiter pleinement de l'accélération du GPU, l'AOSP vous recommande de migrer depuis 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 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).

Vendor Test Suite (VTS)

La suite de tests du fournisseur Android (VTS) exige une propriété ro.vndk.version non vide. Les appareils nouvellement lancés et ceux qui sont 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 correspondantes.