Objet d'interface fournisseur

Ce document décrit la conception de l' objet d'interface fournisseur ( objet VINTF), qui regroupe les informations pertinentes sur un périphérique et les rend disponibles via une API interrogeable .

Conception d'objets VINTF

Un objet VINTF rassemble certaines des informations dont il a besoin directement à partir de l'appareil. D'autres aspects, tels que les manifestes, sont décrits statiquement en XML.

Figure 1. Manifestes, matrices de compatibilité et informations collectables à l'exécution

La conception d'objets VINTF fournit les éléments suivants pour les composants de périphérique et de structure:

Pour l'appareil Pour le cadre
  • Définit un schéma pour le composant statique (le fichier manifeste du périphérique ).
  • Ajoute la prise en charge du temps de construction pour définir le fichier manifeste de l'appareil pour un appareil donné.
  • Définit l' API interrogeable au moment de l'exécution qui récupère le fichier manifeste de l'appareil (ainsi que les autres informations collectables à l'exécution) et les intègre dans le résultat de la requête.

L'objet VINTF doit être fiable et fournir les mêmes informations complètes indépendamment du moment où l'objet est demandé (voir Mises en garde ).

Manifestes et matrices

À partir d'Android 8.0, une API d'exécution interroge le contenu de l'appareil et envoie ces informations au serveur de mise à jour OTA (Over-the-Air) et à d'autres parties intéressées (telles que CTS DeviceInfo ). Certaines informations sont récupérées au moment de l'exécution et certaines sont définies de manière statique.

  • Le manifeste de l'appareil décrit le composant statique de ce que l'appareil peut fournir à l'infrastructure.
  • La matrice de compatibilité du framework décrit ce que le framework Android attend d'un appareil donné. La matrice est une entité statique dont la composition est déterminée manuellement lors du développement de la prochaine version du framework Android.
  • Le manifeste du framework décrit les services de haut niveau que le framework peut fournir à l'appareil.
  • La matrice de compatibilité des périphériques décrit les services dont l'image du fournisseur a besoin pour le cadre. Sa composition est déterminée manuellement lors du développement de l'appareil.

Ces deux paires de manifestes et de matrices doivent être réconciliées au moment de l'OTA pour garantir qu'un appareil peut obtenir des mises à jour de structure compatibles avec les capacités de l'appareil. En général, un manifeste décrit ce qui est fourni et une matrice de compatibilité décrit ce qui est requis.

Cette section comprend les détails suivants sur les manifestes et les matrices:

  • Manifests définit le manifeste de l'appareil, le manifeste de l'infrastructure et le schéma du fichier manifeste.
  • Matrices de compatibilité définit le schéma de la matrice de compatibilité.
  • FCM Lifecycle explique comment les HAL HIDL sont obsolètes et supprimés et comment les fichiers FCM sont modifiés pour refléter l'état de la version HAL.
  • DM Development décrit comment les fournisseurs peuvent définir et déclarer la version FCM cible dans le manifeste de périphérique pour les nouveaux périphériques ou implémenter de nouvelles versions HAL et incrémenter la version FCM cible lors de la mise à niveau de l'image du fournisseur pour les anciens périphériques.
  • Matching Rules définit les règles pour une correspondance réussie entre une matrice de compatibilité et un manifeste.