DriverUI

Die Kombiinstrument-Benutzeroberfläche befindet sich traditionell hinter dem Lenkrad auf einem separaten Display. OEMs kombinieren das Kombiinstrument und das IVI nach und nach zu einem einzigen Display. Diese kombinierte Benutzeroberfläche ist die DriverUI.

DriverUI

Abbildung 1. DriverUI.

Die DriverUI ist eine Android-System-App, die ein vollständiges Kombiinstrument-Display rendert, mit Ausnahme von sicherheitsrelevanten oder regulatorischen Elementen, die vom High Availability Renderer (HAR) gerendert werden. Die DriverUI zeigt Informationen zur Medienwiedergabe, zu Telefonanrufen, Karten, Navigation und mehr 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 als Cluster2 bezeichnet, 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 die App „Display Safety“ auf dem 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 SDV-Media-VM aus.

SDV-Plattformarchitektur

Abbildung 2: SDV-Plattformarchitektur.

HAR- und DriverUI-Ausgabe zusammenführen

Die HAR und die DriverUI verwenden separate Displays, um ihre UI zu rendern. Die beiden Ausgaben werden zusammengesetzt 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 der HAR das Fehlen von Heartbeats, rendert DriverUI-Bereiche undurchsichtig und zeigt Platzhalter an. Wenn die Heartbeats empfangen werden, werden die Platzhalter entfernt und die DriverUI-Bereiche werden transparent dargestellt.

HAR- und DriverUI-Zusammensetzung

Abbildung 3: HAR- und DriverUI-Komposition.

Fehlerbehebung bei Alpha-Komposition und Punch-Through

Da die HAR sicherheitskritisch ist, befindet sich ihre Hardware-Anzeigeebene über der Android-IVI-Anzeigeebene. Wenn Sie benutzerdefinierte Ansichten oder externe OpenGL ES-Oberflächen im HAR erstellen oder debuggen, prüfen Sie, wie Alphawerte festgelegt sind:

  • Fehlende DriverUI-Ausgabe unter der HAR-Ebene: Während die HAR gültige HeartbeatRequest-Nachrichten von der DriverUI empfängt, muss die HAR den DriverUI-Darstellungsbereich auf transparent (alpha = 0.0) setzen, damit die zugrunde liegende Android-Cluster-UI sichtbar ist. Wenn eine benutzerdefinierte HAR-Ebene oder ein benutzerdefinierter Hintergrund undurchsichtige Pixel (alpha = 1.0) über dem DriverUI-Bereich zeichnet, wird die darunter liegende Android-Ausgabe blockiert.
  • Unbeabsichtigte transparente Löcher in benutzerdefinierten 3D- oder OpenGL-Oberflächen: Wenn du eine externe OpenGL ES- oder 3D-Oberfläche in einem HAR-Knoten renderst (z. B. eine benutzerdefinierte 3D-Anzeige oder ‑Szene, die RGB-Pixel mit einem ungenutzten Alpha-Byte bei 0x00 schreibt), setze den Alphakanal von opaken Pixeln explizit auf 0xFF (alpha = 1.0). Wenn das Alpha-Byte bei 0x00 bleibt, behandelt der Compositor diese Pixel als transparent (alpha = 0.0) und stanzt ein Loch direkt durch die HAR-Ebene zur zugrunde liegenden Android-IVI-Ebene.
  • VM-übergreifende Displaydiagnose:Da die HAR (sdv_media_har_cf) und das Android-IVI (sdv_ivi_cf_ds) in separaten Gast-VMs ausgeführt werden, werden beim Ausführen von adb shell dumpsys SurfaceFlinger auf der Android-IVI-VM nur die Android-Ebenen geprüft. Die darüber liegende HAR-Ebene ist nicht sichtbar.

DriverUI- und HAR-Kommunikation

Die DriverUI und die HAR kommunizieren über Remote-Prozeduraufrufe (RPCs) miteinander. Die Heartbeat-Nachricht ist ein Beispiel für Daten, die über den RPC-Kanal gesendet werden, und enthält einen Zeitstempel als eines ihrer Felder.

gRPC wird für RPCs verwendet. Auf SDV stellt SDV comms den SDV Gateway Client bereit, um einen Kanal von der DriverUI zur HAR zu finden und einzurichten. Der gRPC-Dienst definiert eine Protokollzwischenspeicher-Datei:


// 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 Anfrage- und Antwortdetails finden Sie in der Display Safety-Quelle unter packages/apps/Car/DriverUI/proto/driverui.proto im Quellcode-Repository „ub-automotive“.

Auf der SDV-Plattform stellt SDV Comms den SDV Gateway Client bereit, um einen gRPC-Kanal von der DriverUI zur HAR zu finden und einzurichten.

Wenn Sie diese Befehle über das IVI-Terminal ausführen, wird eine Kommunikation an SDV Media gesendet, die Design-Updates im gesamten Cluster auslöst.

adb shell cmd car_service inject-key -d 1 9 # Purple Theme
adb shell cmd car_service inject-key -d 1 8 # Blue Theme

RPC-Kommunikation, um sowohl das DriverUI- als auch das HAR-Design zu ändern.

Abbildung 4: RPC-Kommunikation, um sowohl das DriverUI- als auch das HAR-Design zu ändern.

Medien-, Karten- und Telefonieinformationen auf dem Cluster anzeigen

Durch die Kommunikation mit dem IVI kann die DriverUI Informationen zu Medien, Maps und Telefonie im Referenzcluster anzeigen. Obwohl „Medien“ in der Referenzimplementierung als Standardstatus dient, wird die Anzeige basierend auf aktiven Diensten gemäß der folgenden Priorität aktualisiert:

  1. Maps
  2. Telefonie
  3. Medien

Das System priorisiert automatisch die Anzeige der Google Maps-Navigation oder aktiver Telefoniedienste gegenüber dem Standard-Medienstatus.

Die verschiedenen DriverUI-Anzeigestatus sind in der folgenden Abbildung dargestellt:

DriverUI mit den Bereichen „Medien“ und „Telefonie“ im gesamten Cluster.

Abbildung 5: DriverUI mit dem Bereich „Medien und Telefonie“ im Vollbildmodus.

Automotive Design for 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 Designdokumente in der Laufzeitumgebung gerendert werden können.

Auf Design-Assets zugreifen

Figma-Beispieldokumente für die DriverUI sind Teil der Codebasis. So greifen Sie auf diese Designs zu und ändern sie:

  1. Starten Sie DriverUI mit der lokalen Automotive Design for Compose-DCF-Designdatei aus packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
  2. Suchen Sie die Asset-Datei packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
  3. Importieren Sie diese Datei in Figma, um die Quelldesigns anzusehen oder Änderungen vorzunehmen.

Automotive Design for Compose-Version

  • Gradle verwendet die Automotive Design for Compose-Version, die für designcompose in packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml angegeben ist.
  • Automotive Design for Compose-Releases sind auf der Seite Releases verfügbar.

Konfiguration von Livemeldungen

Automotive Design for Compose unterstützt Live-Updates im Entwicklungsmodus, sodass in Figma vorgenommene Änderungen sofort in DriverUI gerendert werden. Dies ermöglicht schnelle Tests und kürzere 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 Designdokumenten für Dual-VM

In einer Dual-VM-Konfiguration müssen Designaktualisierungen über Grenzen hinweg weitergegeben werden, um die Konsistenz zu wahren.

  • DriverUI ruft das neueste Figma-Designdokument ab und überträgt es über die auf dieser Seite beschriebenen gRPC-Kommunikationskanäle an die HAR.
  • Dadurch wird der gesamte Cluster mit den neuesten Figma-Designiterationen aktualisiert und beide VMs bleiben mit der Designquelle synchronisiert.

Live-Aktualisierung des Designdokuments von Figma zu DriverUI und HAR.

Abbildung 6. Live-Aktualisierung des Designdokuments von Figma zu DriverUI und HAR.

gRPC-Kanal sichern

gRPC bietet SSL- und TLS-Integration und fördert die Verwendung von SSL und TLS zur Authentifizierung des Servers und zur Verschlüsselung aller zwischen Client und Server ausgetauschten Daten. 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.