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 appareil et rend ces informations 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 de manière statique en XML.

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

La conception d'objet VINTF fournit les éléments suivants pour les composants d'appareil et d'infrastructure :

Pour l'appareil Pour le cadre
  • Définit un schéma pour le composant statique (le fichier manifeste de l'appareil ).
  • Ajoute la prise en charge du temps de génération pour définir le fichier manifeste de périphérique pour un périphérique 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 à collecter à l'exécution) et les regroupe dans le résultat de la requête.
  • Définit un schéma pour le composant statique (le fichier manifeste du framework ).
  • Définit l' API interrogeable au moment de l'exécution qui récupère le fichier manifeste de la structure et l'intègre dans le résultat de la requête.

L'objet VINTF doit être fiable et fournir les mêmes informations complètes quel que soit le moment où l'objet est demandé (voir Caveats ).

Manifestes et matrices

Depuis Android 8.0, une API d'exécution interroge ce qui se trouve sur 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 d'entre elles sont définies de manière statique.

  • Le manifeste de l'appareil décrit le composant statique de ce que l'appareil peut fournir au framework.
  • 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 appareils décrit les services que l'image du fournisseur requiert de la structure. Sa composition est déterminée manuellement lors de la mise au point de l'appareil.

Ces deux paires de manifestes et de matrices doivent être réconciliées au moment de l'OTA pour s'assurer 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 inclut les détails suivants sur les manifestes et les matrices :

  • Les manifestes définissent le manifeste de l'appareil, le manifeste de la structure et le schéma du fichier manifeste.
  • Matrices de compatibilité définit le schéma de la matrice de compatibilité.
  • FCM Lifecycle détaille 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 l'appareil pour les nouveaux appareils 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 appareils.
  • Les règles de correspondance définissent les règles d'une correspondance réussie entre une matrice de compatibilité et un manifeste.