Benutzeroberflächenobjekt des Anbieters

In diesem Dokument wird das Design des Vendor Interface Object (VINTF-Objekt) beschrieben, das relevante Informationen zu einem Gerät aggregiert und diese Informationen über eine abfragbare API verfügbar macht.

VINTF-Objektdesign

Ein VINTF-Objekt erhebt einige der erforderlichen Informationen direkt vom Gerät. Andere Aspekte wie die Manifeste werden statisch in XML beschrieben.

Abbildung 1: Manifeste, Kompatibilitätsmatrizen und Informationen, die zur Laufzeit erfasst werden.

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

Für das Gerät	Für das Framework
Hier wird ein Schema für die statische Komponente (die Gerätemanifestdatei) definiert. Bietet Unterstützung bei der Buildzeit zum Definieren 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 erfassten Informationen abruft und in das Abfrageergebnis einfügt.	Hier wird ein Schema für die statische Komponente (die Manifestdatei des Frameworks) definiert. Definiert die abfragbare API zur Laufzeit, die die Manifestdatei des Frameworks abruft und in das Abfrageergebnis einfügt.

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

Manifeste und Matrizen

Ab Android 8.0 wird über eine Runtime-API abgefragt, was sich auf dem Gerät befindet, und diese Informationen werden an den Over-the-Air (OTA)-Update-Server und andere interessierte Parteien (z. B. CTSDeviceInfo) gesendet. Einige Informationen werden zur Laufzeit abgerufen, andere sind statisch definiert.

• Das Gerätemanifest beschreibt die statische Komponente der Informationen, die das Gerät dem Framework zur Verfügung stellen kann.
• In der Kompatibilitätsmatrix des Frameworks wird beschrieben, 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 festgelegt wird.
• Das Framework-Manifest beschreibt allgemeine Dienste, die das Framework dem Gerät zur Verfügung stellen kann.
• In der Gerätekompatibilitätsmatrix werden die Dienste beschrieben, die das Anbieter-Image vom Framework benötigt. Die Zusammensetzung wird während der Entwicklung des Geräts manuell bestimmt.

Diese beiden Manifest- und Matrixpaare müssen bei der OTA-Aktualisierung abgeglichen werden, damit ein Gerät Framework-Updates erhalten kann, die mit den Funktionen des Geräts kompatibel sind. Im Allgemeinen wird in einem Manifest beschrieben, was bereitgestellt wird, und in einer Kompatibilitätsmatrix, was erforderlich ist.

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

• Unter Manifests werden das Gerätemanifest, das Framework-Manifest und das Manifestdateischema definiert.
• Unter Kompatibilitätsmatrizen wird das Schema für die Kompatibilitätsmatrix definiert.
• Im FCM-Lebenszyklus wird beschrieben, wie HIDL HALs eingestellt und entfernt werden und wie FCM-Dateien so geändert werden, dass der Status der HAL-Version widergespiegelt wird.
• In DM Development wird beschrieben, 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.
• Unter Abgleichsregeln werden die Regeln für einen erfolgreichen Abgleich zwischen einer Kompatibilitätsmatrix und einem Manifest definiert.