Viele Fahrzeugsubsysteme sind über verschiedene Bustopologien miteinander und mit dem fahrzeuginternen Infotainmentsystem (IVI) verbunden. Der genaue Bustyp und die Protokolle variieren stark zwischen den Herstellern (und sogar zwischen verschiedenen Fahrzeugmodellen derselben Marke); Beispiele sind Controller Area Network (CAN)-Bus, Local Interconnect Network (LIN)-Bus, Media Oriented Systems Transport (MOST) sowie Ethernet- und TCP/IP-Netzwerke in Automobilqualität wie BroadR-Reach.
Die Hardware-Abstraktionsschicht (HAL) von Android Automotive bietet unabhängig von der physischen Transportschicht eine konsistente Schnittstelle zum Android-Framework. Diese 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 technologiespezifischen Netzwerkschnittstellen (z. B. CAN-Bus) verbinden. Typische Implementierungen können eine dedizierte Mikrocontrollereinheit (MCU) umfassen, auf der ein proprietäres Echtzeitbetriebssystem (RTOS) für den Zugriff auf den CAN-Bus oder ähnliches ausgeführt wird, die über eine serielle Verbindung mit der CPU verbunden sein kann, auf der Android Automotive ausgeführt wird. Anstelle einer dedizierten MCU kann der Buszugriff ggf. auch als virtualisierte CPU realisiert werden. Es ist jedem Partner freigestellt, die für die Hardware geeignete Architektur zu wä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:
Abbildung 1 . Fahrzeug-HAL und Android-Automobilarchitektur
- Auto-API . Enthält die APIs, einschließlich
CarSensorManager. Einzelheiten zu unterstützten APIs finden Sie unter/platform/packages/services/Car/car-lib. - AutoService . Zu finden 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 unterhardware/libhardware/modules/vehicle/.
Weitere Einzelheiten finden Sie unter Fahrzeugeigenschaften .
Sicherheit
Die Fahrzeug-HAL unterstützt diese Sicherheitsstufen beim Zugriff auf Daten:
- Zugänglich für App mit Genehmigung (über Autoservice).
- Zugänglich ohne Genehmigung (über Autoservice).
Der direkte Zugriff auf Fahrzeugeigenschaften ist nur ausgewählten Systemkomponenten mit Fahrzeugnetzwerk mit Selinux-Zugriffsschutz gestattet. Die meisten Anwendungen durchlaufen zusätzliches Gatekeeping by Car Service (z. B. können nur Systemanwendungen die HLK steuern, da hierfür eine Systemberechtigung erforderlich ist, die nur System-Apps erteilt wird).
,Viele Fahrzeugsubsysteme sind über verschiedene Bustopologien miteinander und mit dem fahrzeuginternen Infotainmentsystem (IVI) verbunden. Der genaue Bustyp und die Protokolle variieren stark zwischen den Herstellern (und sogar zwischen verschiedenen Fahrzeugmodellen derselben Marke); Beispiele sind Controller Area Network (CAN)-Bus, Local Interconnect Network (LIN)-Bus, Media Oriented Systems Transport (MOST) sowie Ethernet- und TCP/IP-Netzwerke in Automobilqualität wie BroadR-Reach.
Die Hardware-Abstraktionsschicht (HAL) von Android Automotive bietet unabhängig von der physischen Transportschicht eine konsistente Schnittstelle zum Android-Framework. Diese 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 technologiespezifischen Netzwerkschnittstellen (z. B. CAN-Bus) verbinden. Typische Implementierungen können eine dedizierte Mikrocontrollereinheit (MCU) umfassen, auf der ein proprietäres Echtzeitbetriebssystem (RTOS) für den Zugriff auf den CAN-Bus oder ähnliches ausgeführt wird, die über eine serielle Verbindung mit der CPU verbunden sein kann, auf der Android Automotive ausgeführt wird. Anstelle einer dedizierten MCU kann der Buszugriff ggf. auch als virtualisierte CPU realisiert werden. Es ist jedem Partner freigestellt, die für die Hardware geeignete Architektur zu wä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:
Abbildung 1 . Fahrzeug-HAL und Android-Automobilarchitektur
- Auto-API . Enthält die APIs, einschließlich
CarSensorManager. Einzelheiten zu unterstützten APIs finden Sie unter/platform/packages/services/Car/car-lib. - AutoService . Zu finden 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 unterhardware/libhardware/modules/vehicle/.
Weitere Einzelheiten finden Sie unter Fahrzeugeigenschaften .
Sicherheit
Die Fahrzeug-HAL unterstützt diese Sicherheitsstufen beim Zugriff auf Daten:
- Zugänglich für App mit Genehmigung (über Autoservice).
- Zugänglich ohne Genehmigung (über Autoservice).
Der direkte Zugriff auf Fahrzeugeigenschaften ist nur ausgewählten Systemkomponenten mit Fahrzeugnetzwerk mit Selinux-Zugriffsschutz gestattet. Die meisten Anwendungen durchlaufen zusätzliches Gatekeeping by Car Service (z. B. können nur Systemanwendungen die HLK steuern, da hierfür eine Systemberechtigung erforderlich ist, die nur System-Apps erteilt wird).