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 collectables lors de l'exécution

La conception d'objet 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 au moment de la construction 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 collectables au moment de 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 du framework et le regroupe 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 Mises en garde ).

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 Over-the-Air (OTA) 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 d'autres sont définies de manière statique.

  • Le manifeste du périphérique décrit le composant statique de ce que le périphérique 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 exige du framework. Sa composition est déterminée manuellement lors du développement du dispositif.

Ces deux paires de manifestes et de matrices doivent être rapprochées au moment de l'OTA pour garantir qu'un appareil puisse obtenir des mises à jour de structure compatibles avec ses capacités. 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 :

  • Les manifestes définissent le manifeste du périphérique, le manifeste du framework et le schéma du fichier manifeste.
  • Compatibility Matrixes 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 cible FCM dans le manifeste de l'appareil pour les nouveaux appareils ou implémenter de nouvelles versions HAL et incrémenter la version cible FCM lors de la mise à niveau de l'image du fournisseur pour les anciens appareils.
  • Les règles de correspondance définissent les règles permettant une correspondance réussie entre une matrice de compatibilité et un manifeste.