Wir haben bereits ausführlich über die Android-Architektur gesprochen.
Wenn Sie sie noch nicht gesehen haben, empfehle ich Ihnen dringend, die Android-Architekturvorlesung zu überspringen
und dann zu dieser Vorlesung zurückzukehren.
Wie Sie wissen, wird die Automobilarchitektur von Android parallel zu den Modulen der Android-Architektur aufgebaut.
Wir können die Automobilindustrie hauptsächlich in vier Bereiche unterteilen.
Ganz oben stehen also die Systemanwendungen und die OEM-Anwendungen.
Die Apps bestehen also aus Anwendungen von Drittanbietern, z. B. WhatsApp, Facebook usw. und System-Apps bestehen aus der System-Benutzeroberfläche
und den anderen Medien-Apps oder der Dialer-App.
Und dann haben wir noch die OEM-Anwendungen.
Dies sind die von den OEMs angepassten Anwendungen.
Das bedeutet, dass der Hersteller seine eigenen Anwendungen hinzufügen wird.
Und dann haben wir noch die Auto-API.
Die Auto-API bietet APIs für die Kommunikation mit dem Autodienst, der wiederum mit dem Fahrzeug kommuniziert.
Dies wird also viele Manager enthalten, wie z.B. Auto-Sensor-Manager oder Auto-Eigenschafts-Manager.
Wir werden in einer späteren Sitzung sehen, wie wir eine Verbindung zu diesen Auto-APIs herstellen können.
Denken Sie also daran, dass die Auto-API eine Schnittstelle zum Autodienst darstellt.
Und an der dritten Stelle haben wir den Autoservice.
Der Autodienst wird vom Android-Systemserver aus gestartet.
Wir werden uns das in einer späteren Sitzung genauer ansehen.
Das ist der Autoservice.
Die Hauptaufgabe ist die Kommunikation mit dem Fahrzeug.
Es hat viele andere Dienste innerhalb des Autoservices, wie z.B. den Input Manager Service,
den Media Service, etc. Wir werden uns diese Dienste und ihre Verwaltung im Detail ansehen.
Sobald wir den Code des Autoservices an der vierten Stelle analysieren, haben wir das Fahrzeug.
Hal.
Die Fahrzeug-HAL ist die Schnittstellendefinition zwischen dem Fahrzeug und dem Fahrzeugnetzdienst.
Die Android Automotive Hardware Abstraction Layer oder HAL bietet eine einheitliche Schnittstelle zum Android-Framework,
unabhängig von der tatsächlichen physikalischen Transportschicht.
Das bedeutet, dass die physikalische Transportschicht alles sein kann, also eine Leinwand, ein Leinenbus
oder ein anderes TCP-IP-Netz.
Unabhängig von der physikalischen Transportschicht wird die gesamte Schnittstelle eine einheitliche Schnittstelle zum
Android-Framework bieten.
Und dieses Fahrzeug, Hal, ist die Schnittstelle für die Entwicklung von Android-Implementierungen für Fahrzeuge.
Das Fahrzeug oder die Fahrzeug-HAL-Schnittstelle definiert also auch die Fahrzeugeigenschaften, die ein OEM implementieren kann.
Sie enthält also Eigenschafts-Metadaten, z. B. ob es sich bei der Fahrzeugeigenschaft um eine Ganzzahl oder eine Zeichenkette handelt.
Sie enthält also den Datentyp der Fahrzeugdaten und auch die Änderungsmodi, z. B. ob es sich um eine
lesbare rechte Tabelle handelt, usw.
Also alle Fahrzeugeigenschaften wie z.B. der Gang, in dem sich das Fahrzeug gerade befindet oder die Geschwindigkeit
des Fahrzeugs oder die aktuelle Temperatur des Fahrzeugs und der verbleibende Kraftstoff im Fahrzeug.
All diese Eigenschaften werden also in der Fahrzeugschnittstelle definiert.