Vendor-Schnittstellenobjekt

Dieses Dokument beschreibt das Design des Vendor-Interface-Objekts (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 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 ).
  • Fügt Buildzeitunterstützung zum Definieren der Gerätemanifestdatei für ein bestimmtes Gerät hinzu.
  • Definiert die abfragbare API zur Laufzeit, die die Gerätemanifestdatei (zusammen mit den anderen zur Laufzeit sammelbaren 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 sie in das Abfrageergebnis packt.

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

Manifeste & 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) -Update-Server und andere interessierte Parteien (z. B. CTS DeviceInfo ). Einige Informationen werden zur Laufzeit abgerufen und einige davon 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 Entität, deren Zusammensetzung während der Entwicklung der nächsten Version des Android-Frameworks manuell bestimmt wird.
  • Das Framework-Manifest beschreibt High-Level-Dienste, die das Framework für das Gerät bereitstellen kann.
  • Die Gerätekompatibilitätsmatrix beschreibt die Dienste, die das Anbieterimage vom Framework erfordert. Seine Zusammensetzung wird während der Entwicklung des Geräts manuell bestimmt.

Diese beiden Paare von Manifesten und Matrizen müssen zur OTA-Zeit abgeglichen werden, um sicherzustellen, dass ein Gerät Framework-Updates erhalten kann, die mit den Fähigkeiten 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 definiert das Gerätemanifest, das Frameworkmanifest und das Schema der Manifestdatei.
  • Compatibility Matrixes definiert das Schema für die Kompatibilitätsmatrix.
  • Der FCM-Lebenszyklus beschreibt, 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.
  • Abgleichsregeln definieren die Regeln für einen erfolgreichen Abgleich zwischen einer Kompatibilitätsmatrix und einem Manifest.