Die Cluster-Benutzeroberfläche wurde bisher hinter dem Lenkrad auf einem separaten Display platziert. OEMs kombinieren das Kombiinstrument und das IVI nach und nach in einem einzigen Display. Diese kombinierte Benutzeroberfläche ist die DriverUI.
Abbildung 1. DriverUI.
Die DriverUI ist eine Android-System-App, die ein komplettes Kombiinstrument rendert. Sicherheitsrelevante oder regulatorische Elemente, die vom High Availability Renderer (HAR) gerendert werden, sind dabei ausgenommen. Die DriverUI zeigt Informationen zur Medienwiedergabe, zu Telefonanrufen, zu Karten und zur Navigation an und implementiert Automotive Design for Compose.
DriverUI als Standardclusteraktivität
DriverUI wird als privilegierte Cluster-App in Android ausgeführt und von AAOS automatisch gestartet.
AAOS verwendet die Klasse ClusterHomeManager, auch Cluster2 genannt, um Kombiinstrumente zu erstellen. Diese Klasse gibt die Konfiguration an, die zum Identifizieren einer Kombiinstrument-Implementierung erforderlich ist, und wie AAOS damit interagiert. Google stellt Referenzimplementierungen von Cluster2-APIs bereit.
Plattformen
Sie können Display Safety auf SDV erstellen und ausführen. Die Plattform für softwarebasierte Fahrzeuge (Software Defined Vehicle, SDV):
- Erfordert zwei Gast-VMs.
- Führt HAR in SDV Media (auch als Rapid-Boot-VM bezeichnet) in einer Gast-VM aus.
- Führt DriverUI in einer anderen Gast-SDV-IVI-VM aus.
- Führt den Sicherheitsmonitor auf der Media-VM für SDV aus.
Abbildung 2: SDV-Plattformarchitektur.
HAR- und DriverUI-Ausgabe kombinieren
HAR und DriverUI verwenden separate Displays zum Rendern der Benutzeroberfläche. Die beiden Ausgaben werden kombiniert und in der DriverUI als ein Bild angezeigt.
Dazu steuert die HAR die Transparenz der Bereiche, in denen die Android-Ausgabe angezeigt wird, basierend auf Heartbeat-Nachrichten von der DriverUI. Wenn die DriverUI nicht verfügbar ist, erkennt HAR das Fehlen von Herzschlägen und rendert DriverUI-Bereiche undurchsichtig und zeigt Platzhalter an. Wenn die Heartbeats empfangen werden, werden die Platzhalter entfernt und die DriverUI-Bereiche werden auf transparent gesetzt.
Abbildung 3: HAR- und DriverUI-Zusammensetzung.
DriverUI- und HAR-Kommunikation
Die DriverUI und HAR kommunizieren über Remoteprozeduraufrufe (RPCs) miteinander. Die Heartbeat-Nachricht ist ein Beispiel für Daten, die über den RPC-Channel gesendet werden, und besteht aus einem Zeitstempel als einem ihrer Felder.
gRPC wird für RPCs verwendet. Auf SDV stellt SDV Comms den SDV Gateway-Client bereit, um einen Kanal von der DriverUI zum HAR zu erkennen und einzurichten. Der gRPC-Dienst definiert eine Protokollpufferdatei:
// Heartbeat.
rpc Heartbeat(HeartbeatRequest) returns (HeartbeatResponse) {}
// Document switched in the DriverUI.
rpc DocumentSwitched(DocumentSwitchedRequest) returns (DocumentSwitchedResponse) {}
// Document updated in the DriverUI. Unary RPC.
rpc DocumentUpdated(DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}
// Document updated in the DriverUI. Requests are streamed with each request
// containing a part of the document and the entire document is assembled from these
// chunks by the server.
rpc DocumentUpdatedStreaming(stream DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}
/// Request for HAR to change design tokens.
rpc DesignTokenUpdate(DesignTokenUpdateRequest) returns (DesignTokenUpdateResponse) {}
// Request to change the current locale used in HAR.
rpc LocaleUpdate(LocaleUpdateRequest) returns (LocaleUpdateResponse) {}
// Requests to swap a certain variant at a Figma node.
rpc ChangeVariant(ChangeVariantRequest) returns (ChangeVariantResponse) {}
// Requests to change the container (display/root node) configuration (dpi, size) in HAR.
rpc ChangeContainerConfiguration(ChangeContainerConfigurationRequest) returns (ChangeContainerConfigurationResponse) {}
Die Details zu Anfragen und Antworten finden Sie in der Display Safety-Quelle unter packages/apps/Car/DriverUI/proto/driverui.proto im Quellcode-Repository von ub-automotive.
Auf der SDV-Plattform stellt SDV Comms den SDV Gateway Client bereit, um einen gRPC-Channel von der DriverUI zum HAR zu erkennen und einzurichten.
Durch Ausführen dieser Befehle über das IVI-Terminal wird die Kommunikation an SDV Media gesendet, wodurch Themenaktualisierungen im gesamten Cluster ausgelöst werden.
adb shell cmd car_service inject-key -d 1 9 # Purple Theme
adb shell cmd car_service inject-key -d 1 8 # Blue Theme
Abbildung 4: RPC-Kommunikation zum Ändern des Designs von DriverUI und HAR.
Media-, Karten- und Telefonieinformationen im Kombiinstrument anzeigen
Durch die Kommunikation mit dem IVI kann die DriverUI Informationen für Media, Maps und Telefonie innerhalb des Referenzclusters anzeigen. „Media“ ist zwar der Standardstatus in der Referenzimplementierung, die Anzeige wird jedoch basierend auf aktiven Diensten gemäß der folgenden Priorität aktualisiert:
- Maps
- Telefonie
- Medien
Das System priorisiert automatisch die Anzeige der Google Maps-Navigation oder aktiver Telefondienste gegenüber dem Standard-Medienstatus.
Die verschiedenen DriverUI-Anzeigestatus sind in der folgenden Abbildung dargestellt:
Abbildung 5: DriverUI mit dem Bereich „Media“ (Medien) und „Telephony“ (Telefonie) im Vollcluster.
Automotive-Design für die Compose-Integration
Die DriverUI implementiert Automotive Design for Compose, damit Designs (Figma) direkt in der Android-App präsentiert und iteriert werden können. Diese Integration schließt die Lücke zwischen Design und Entwicklung, da Design-Dokumente in der Laufzeitumgebung gerendert werden können.
Auf Design-Assets zugreifen
Beispiel-Figma-Dokumente für die DriverUI sind Teil der Codebasis. So greifen Sie auf diese Designs zu und bearbeiten sie:
- Starten Sie DriverUI mit der lokalen DCF-Designdatei „Automotive Design for Compose“ aus
packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf. - Suchen Sie die Asset-Datei
packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig. - Importieren Sie diese Datei in Figma, um die Quelldesigns anzusehen oder Änderungen vorzunehmen.
Automotive-Design für Compose-Version
- Gradle verwendet die für
designcomposeinpackages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.tomlangegebene Version von Automotive Design for Compose. - Automotive Design for Compose-Releases sind auf der Seite Releases verfügbar.
Konfiguration von Livemeldungen
Automotive Design for Compose unterstützt Live-Updates im Entwicklermodus. Änderungen, die in Figma vorgenommen werden, werden also sofort in DriverUI gerendert. Das ermöglicht schnelle Tests und schnellere Design-Iterationszyklen.
Führen Sie den folgenden Befehl aus, um das Figma-Token für DriverUI festzulegen:
adb shell am startservice \
-n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
-a setApiKey \
-e ApiKey $FIGMA_ACCESS_TOKEN \
--user 0
Synchronisierung von Design-Dokumenten für Dual-VM
Bei einer Einrichtung mit zwei VMs müssen Designaktualisierungen über Grenzen hinweg weitergegeben werden, um die Konsistenz zu wahren.
- DriverUI ruft das aktuelle Figma-Designdokument ab und überträgt es über die auf dieser Seite beschriebenen gRPC-Kommunikationskanäle an den HAR.
- Dadurch wird der gesamte Cluster mit den neuesten Figma-Designiterationen aktualisiert und beide VMs bleiben mit der Designquelle synchron.
Abbildung 6. Live-Aktualisierung des Designdokuments von Figma zu DriverUI und HAR.
gRPC-Kanal sichern
gRPC bietet SSL- und TLS-Integration und empfiehlt die Verwendung von SSL und TLS, um den Server zu authentifizieren und alle zwischen dem Client und dem Server ausgetauschten Daten zu verschlüsseln. Für Clients sind optionale Mechanismen verfügbar, um Zertifikate für die gegenseitige Authentifizierung bereitzustellen. Weitere Informationen zur gRPC-Authentifizierung finden Sie unter Authentifizierung.