Anbieterschnittstellenobjekt

Dieses Dokument beschreibt den Entwurf des Anbieterschnittstellenobjekts (VINTF-Objekt), das relevante Informationen über ein Gerät aggregiert und diese Informationen über eine abfragbare API verfügbar macht.

VINTF-Objektdesign

Ein VINTF-Objekt sammelt einige der benötigten Informationen direkt vom Gerät. Andere Aspekte, wie zum Beispiel die Manifeste, werden statisch in XML beschrieben.

Abbildung 1. Manifeste, Kompatibilitätsmatrizen und zur Laufzeit sammelbare Informationen

Das VINTF-Objektdesign bietet Folgendes für Geräte- und Framework-Komponenten:

Für das Gerät Für den Rahmen
  • Definiert ein Schema für die statische Komponente (die Gerätemanifestdatei ).
  • Integriert Build-Time-Unterstützung für die Definition der Gerätemanifestdatei für ein bestimmtes Gerät.
  • Definiert die abfragbare API zur Laufzeit, die die Gerätemanifestdatei (zusammen mit den anderen zur Laufzeit erfassbaren Informationen) abruft und sie in das Abfrageergebnis packt.
  • Definiert ein Schema für die statische Komponente (die Framework-Manifestdatei ).
  • Definiert die abfragbare API zur Laufzeit, die die Framework-Manifestdatei abruft und in das Abfrageergebnis packt.

Das VINTF-Objekt muss zuverlässig sein und die gleichen vollständigen Informationen bereitstellen, unabhängig davon, wann das Objekt angefordert wird (siehe Vorbehalte ).

Manifeste und Matrizen

Ab Android 8.0 fragt eine Laufzeit-API ab, was sich auf dem Gerät befindet, und sendet diese Informationen an den Over-the-Air (OTA) -Updateserver und andere interessierte Parteien (z. B. CTS DeviceInfo ). Einige Informationen werden zur Laufzeit abgerufen, andere sind statisch definiert.

  • Das Gerätemanifest beschreibt die statische Komponente dessen, was das Gerät dem Framework bereitstellen kann.
  • Die Framework-Kompatibilitätsmatrix beschreibt, was das Android-Framework von einem bestimmten Gerät erwartet. Die Matrix ist eine statische Einheit, deren Zusammensetzung während der Entwicklung der nächsten Version des Android-Frameworks manuell festgelegt wird.
  • Das Framework-Manifest beschreibt hochrangige Dienste, die das Framework dem Gerät bereitstellen kann.
  • Die Gerätekompatibilitätsmatrix beschreibt die Dienste, die das Anbieter-Image vom Framework benötigt. Seine Zusammensetzung wird bei der Entwicklung des Gerätes manuell bestimmt.

Diese beiden Paare von Manifesten und Matrizen müssen zum OTA-Zeitpunkt abgeglichen werden, um sicherzustellen, dass ein Gerät Framework-Updates erhalten kann, die mit den Funktionen des Geräts kompatibel sind. Im Allgemeinen beschreibt ein Manifest , was bereitgestellt wird, und eine Kompatibilitätsmatrix beschreibt, was erforderlich ist.

Dieser Abschnitt enthält die folgenden Details zu Manifesten und Matrizen:

  • Manifeste definieren das Gerätemanifest, das Framework-Manifest und das Manifestdateischema.
  • Kompatibilitätsmatrizen definieren das Schema für die Kompatibilitätsmatrix.
  • Der FCM-Lebenszyklus beschreibt detailliert, wie HIDL-HALs veraltet und entfernt werden und wie FCM-Dateien geändert werden, um den Status der HAL-Version widerzuspiegeln.
  • DM Development beschreibt, wie Anbieter die Ziel-FCM-Version im Gerätemanifest für neue Geräte definieren und deklarieren oder neue HAL-Versionen implementieren und die Ziel-FCM-Version erhöhen können, wenn sie das Anbieter-Image für alte Geräte aktualisieren.
  • Matching Rules definiert die Regeln für einen erfolgreichen Abgleich zwischen einer Kompatibilitätsmatrix und einem Manifest.