Google is committed to advancing racial equity for Black communities. See how.
This page was translated by the Cloud Translation API.
Switch to English

Automobil

Android Fahrzeug HAL Symbol

Viele Fahrzeug-Subsysteme sind über verschiedene Bustopologien miteinander und mit dem Infotainment-System (IVI) im Fahrzeug verbunden. Der genaue Bustyp und die Protokolle variieren stark zwischen den Herstellern (und sogar zwischen verschiedenen Fahrzeugmodellen derselben Marke). Beispiele hierfür sind CAN-Bus (Controller Area Network), LIN-Bus (Local Interconnect Network), MOST (Media Oriented Systems Transport) sowie Ethernet- und TCP / IP-Netzwerke für Automobile wie BroadR-Reach.

Die Hardware-Abstraktionsschicht (HAL) von Android Automotive bietet eine konsistente Schnittstelle zum Android-Framework, unabhängig von der physischen Transportschicht. Dieses Fahrzeug HAL ist die Schnittstelle für die Entwicklung von Android Automotive-Implementierungen.

Systemintegratoren können ein Fahrzeug-HAL-Modul implementieren, indem sie funktionsspezifische Plattform-HAL-Schnittstellen (z. B. HVAC) mit technologie-spezifischen Netzwerkschnittstellen (z. B. CAN-Bus) verbinden. Typische Implementierungen können eine dedizierte Mikrocontroller-Einheit (MCU) umfassen, auf der ein proprietäres Echtzeitbetriebssystem (RTOS) für den CAN-Bus-Zugriff oder ähnliches ausgeführt wird, das über eine serielle Verbindung mit der CPU verbunden sein kann, auf der Android Automotive ausgeführt wird. Anstelle einer dedizierten MCU kann der Buszugriff möglicherweise auch als virtualisierte CPU implementiert werden. Es liegt an jedem Partner, die für die Hardware geeignete Architektur auszuwählen, solange die Implementierung die Schnittstellenanforderungen für die Fahrzeug-HAL erfüllt.

Die Architektur

Die Fahrzeug-HAL ist die Schnittstellendefinition zwischen dem Fahrzeug und dem Fahrzeugnetzwerkdienst:

Android Fahrzeug HAL Architektur

Abbildung 1 . Fahrzeug-HAL- und Android-Automobilarchitektur

  • Auto API . Enthält die APIs wie CarHvacManager und CarSensorManager. Ausführliche Informationen zu unterstützten APIs finden Sie unter /platform/packages/services/Car/car-lib .
  • CarService . Befindet sich unter /platform/packages/services/Car/ .
  • Fahrzeug HAL . Schnittstelle, die die Fahrzeugeigenschaften definiert, die OEMs implementieren können. Enthält Eigenschaftsmetadaten (z. B. ob die Fahrzeugeigenschaft ein int ist und welche Änderungsmodi zulässig sind). Befindet sich unter hardware/libhardware/include/hardware/vehicle.h . Eine grundlegende Referenzimplementierung finden Sie unter hardware/libhardware/modules/vehicle/ .

Weitere Einzelheiten finden Sie unter Fahrzeugeigenschaften .

Sicherheit

Das Fahrzeug HAL unterstützt drei Sicherheitsstufen für den Zugriff auf Daten:

  • Nur System (gesteuert von vns_policy.xml )
  • Zugriff auf die App mit Genehmigung (über den Autoservice)
  • Ohne Erlaubnis zugänglich (über den Autoservice)

Der direkte Zugriff auf Fahrzeugeigenschaften ist nur für ausgewählte Systemkomponenten zulässig, wobei der Fahrzeugnetzwerkdienst als Gatekeeper fungiert. Die meisten Anwendungen durchlaufen eine zusätzliche Gatekeeping-Funktion per Fahrzeugdienst (z. B. können nur Systemanwendungen die HLK steuern, da hierfür nur Systemanwendungen eine Systemberechtigung erforderlich sind).

Validierung

AOSP enthält die folgenden Testressourcen zur Verwendung in der Entwicklung:

  • hardware/libhardware/tests/vehicle/vehicle-hal-tool.c
    Natives Kommandozeilen-Tool zum Laden von Fahrzeug-HAL und zum Ausführen einfacher Operationen. Nützlich, um das System in den frühen Entwicklungsphasen zum Laufen zu bringen.
  • packages/services/Car/tests/carservice_test/
    Enthält Tests zum Autoservice mit verspotteten HAL-Eigenschaften des Fahrzeugs. Für jede Eigenschaft wird das erwartete Verhalten im Test implementiert. Dies kann ein guter Ausgangspunkt sein, um das erwartete Verhalten zu verstehen.
  • hardware/libhardware/modules/vehicle/
    Eine grundlegende Referenzimplementierung.