Referenzimplementierung

Wir stellen eine Referenzimplementierung für die AIDL-VHAL bereit. Der Hauptdienst-Thread wird unter VehicleService.cpp implementiert. Die Implementierung der VHAL-Schnittstelle befindet sich unter DefaultVehicleHal.cpp.

Die Referenzimplementierung basiert auf einer zweischichtigen Architektur. Auf der oberen Ebene implementiert DefaultVehicleHal die VHAL-AIDL-Schnittstelle und stellt die VHAL-Logik bereit, die für alle Hardwaregeräte generisch ist. In der unteren Ebene implementiert FakeVehicleHardware die IVehicleHardware-Schnittstelle. Diese Klasse simuliert die VHAL-Logik für die Interaktion mit der tatsächlichen Hardware oder dem Fahrzeugbus und ist gerätespezifisch. Optional können Anbieter dieselbe Architektur anpassen, dieselbe DefaultVehicleHal-Klasse wiederverwenden (indem sie sie erweitern, um eine Methode zu überschreiben) und ihre eigene IVehicleHardware-Implementierung bereitstellen.

VHAL-Referenzimplementierung
Abbildung 1: VHAL-Referenzimplementierung

DefaultVehicleHal enthält die folgende Logik, die als generisch gilt und auf jede VHAL-Implementierung angewendet werden kann.

  • Implementiert die IVehicle-Schnittstelle.
  • Führt grundlegende Eingabeüberprüfungen durch, einschließlich einer Überprüfung auf doppelte IDs.
  • Weist für jeden Vorgang für jeden Binder-Client Clientobjekte (z. B. GetValuesClient) zu und fügt sie einem globalen Pool hinzu.
  • Verwaltet die Logik für asynchrone Callbacks, z. B. das Hinzufügen einer ausstehenden Anfrage zu einem Pool ausstehender Anfragen. Löst ausstehende Anfragen auf, wenn wir die Ergebnisse erhalten, oder gibt einen Fehler zurück, wenn für eine der ausstehenden Anfragen das Zeitlimit überschritten wird.
  • Serialisiert und deserialisiert LargeParcelable (siehe ParcelableUtils.h).
  • Verwaltet Abos (siehe SubscriptionManager.h).
  • Prüft Berechtigungen. Weitere Informationen finden Sie unter den Funktionen checkReadPermission und checkWritePermission.
  • Ruft regelmäßig IVehicleHardware.checkHealth auf und sendet Heartbeat-Signale (siehe die Funktion checkHealth).

IVehicleHardware ist eine generische Schnittstelle, die zur Darstellung der hardwarespezifischen Implementierung eines VHAL verwendet wird. Die Referenzimplementierung für IVehicleHardware ist FakeVehicleHardware. Dabei wird eine In-Memory-Karte zum Speichern des Attributwerts verwendet und es erfolgt keine Kommunikation mit einem tatsächlichen Fahrzeugbus. Sie soll auf einem Emulator ausgeführt werden und keine hardwarespezifischen Abhängigkeiten haben. Anbieterimplementierungen dürfen sie nicht unverändert verwenden, sondern müssen fahrzeugbusspezifische Logik hinzufügen.

Ab Android 14 liest FakeVehicleHardware die unterstützte Property-Konfiguration zur Laufzeit während der Initialisierung aus dem Ordner /vendor/etc/automotive/vhalconfig/ des Geräts. Dieser enthält eine Konfigurationsdatei im JSON-Stil. Informationen zum Format und Inhalt der Konfigurationsdatei finden Sie in der README-Datei für die Referenz-VHAL.

FakeVehicleHardware unterstützt auch das Überschreiben von Konfigurationsdateien für Tests. Wenn das Systemattribut persist.vendor.vhal_init_value_override festgelegt ist (dieses Attribut muss zur Build-Zeit oder sehr früh während des Bootvorgangs vor der VHAL-Initialisierung festgelegt werden), wird die Konfigurationsdatei aus dem Ordner /vendor/etc/automotive/vhaloverride/ auf dem Gerät verwendet, um die vorhandene Konfiguration zu überschreiben. Eine Anbieterimplementierung kann einen ähnlichen Ansatz verwenden, sodass die vom VHAL unterstützte Property-Konfiguration nicht fest codiert ist und bei der Initialisierung dynamisch entschieden werden kann. Die Liste der Konfigurationen für Fahrzeugeigenschaften muss nach der Initialisierung von VHAL statisch sein.

Ab Android 16 bietet GRPCVehicleHardware eine weitere Referenzimplementierung für IVehicleHardware. Bei dieser Implementierung wird davon ausgegangen, dass auf einem Remotecomputer oder einer VM ein separater Server ausgeführt wird, der die Logik für die Verarbeitung von Properties enthält. Das VHAL, das auf AAOS-Geräten ausgeführt wird, fungiert als Proxy, der Anfragen an den Remote-Server weiterleitet. Weitere Informationen finden Sie unter grpc.