Auf dieser Seite finden Sie eine Übersicht zum Zugriff auf die Display Safety-Komponenten, einschließlich des Hochverfügbarkeits-Renderer (HAR), DriverUI, und des Sicherheitsmonitors, sowie zum Erstellen und Ausführen dieser Komponenten auf den Software Defined Vehicle (SDV)-Plattformen.
Codezugriff
In diesem Abschnitt wird beschrieben, wie Sie Zugriff auf die Codebasis für die Display Safety-Komponenten HAR und DriverUI erhalten.
Hochverfügbarkeits-Renderer
Die Codebasis für den High Availability Renderer (HAR) ist als Teil von
dem Haupt-Repository-Checkout unter packages/services/display_safety/ verfügbar.
Die Codebasis für HAR ist folgendermaßen strukturiert:
- Framework:Enthält die wichtigsten Framework-Schnittstellen für Plattform, Rendering, Animation und Audio.
- Reference:Enthält plattformspezifische Implementierungen für Framework-Schnittstellen sowie den Code für die HAR-Referenz-App und die Sicherheitstoolchain (Design Compiler, Sicherheitsmonitor).
- Service:Android-spezifische Dienste zum Senden und Empfangen von Fahrzeugdaten zwischen Komponenten sowie Definitionen für die APEX-Datenpakete.
- Prebuilts:Bietet Wrapper für vorgefertigte Binärdateien wie die Impeller-Grafikbibliothek.
Der Code für die Referenz-App „Harry“ befindet sich unter packages/services/display_safety/reference/harry_app.
Eine detaillierte Verzeichnisstruktur von HAR finden Sie unter Code-Struktur von Display Safety.
Sicherheitsmonitor
Die Codebasis für den Sicherheitsmonitor ist als Teil des Haupt-Repository-Checkouts unter packages/services/display_safety/reference/safety-monitor verfügbar.
Der Code des Sicherheitsmonitors ist folgendermaßen strukturiert:
main.rs: Ruft Kontrollleuchten-Artefakte ab, initialisiert den Fahrzeugdatenserver und die Überwachungsschleifen für Kontrollleuchten. Informationen zur Sichtbarkeit von Kontrollleuchten werden mit den Ergebnissen der Kontrollleuchtenprüfung verglichen. Die Ergebnisse werden über SDV-Logs bereitgestellt.Vehicle_data_server.rs: Der Server, der die Fahrzeugdaten abonniert und die Sichtbarkeit der Kontrollleuchten für die Hauptschleife aktualisiert.Telltale_monitoring.rs: Wird in einer Schleife ausgeführt, ruft mit der Screencap-Crate eine Kopie des Bildschirmbuffers ab und prüft die angegebenen Regionen auf Kontrollleuchten. Die Ergebnisse der Kontrollleuchtenprüfungen werden dann an die Hauptschleife gesendet.
DriverUI
DriverUI ist als Teil einer nicht gebündelten Codebasis verfügbar, auf die Sie über den Branch ub-automotive-master zugreifen können.
mkdir ub-automotive-master && cd ub-automotive-master
repo init -u https://android.googlesource.com/platform/manifest -b ub-automotive-master
repo sync -cq
Weitere Informationen zu nicht gebündelten und Google-Quellen finden Sie unter Nicht gebündelte Apps einbinden.
Erstellen und ausführen
In diesem Abschnitt wird der Prozess zum Kompilieren und Ausführen der Ziele für den HAR in SDV Media und die DriverUI in SDV In-Vehicle Infotainment (IVI) beschrieben, um die vollständige Clusterlösung mit SDV zu erreichen.

Abbildung 1 : Display Safety-Struktur mit zwei VMs.
HAR- und SDV Media-Ziel erstellen
- Basisziel für Medien:
sdv_media_cf- Beschreibung:Ein dediziertes Ziel für den SDV Media-Stack, das isolierte Tests verschiedener Media-Frameworks ermöglicht.
- Verzeichnisspeicherort:
device/google/sdv/
- Integriertes HAR-Ziel:
sdv_media_har_cf- Beschreibung:Dieses Ziel integriert den Media-Stack in den HAR und führt SDV Media auf Cuttlefish aus.
- Verzeichnisspeicherort:
device/google/sdv_dsplay_safety/ - Build-Ausführung :
# In the root of the Android source
source build/envsetup.sh
lunch sdv_media_har_cf-trunk_staging-userdebug
m -j
DriverUI erstellen
Im ub-automotive-master Branch können Sie nicht gebündelte Apps mit der
Befehlszeile oder Android Studio erstellen.
Importieren Sie in Android Studio die Gradle-Datei:
packages/apps/Car/libs/aaos-apps-gradle-project/build.gradle
Dies ist das Haupt-Gradle-Projekt mit allen nicht gebündelten Apps, einschließlich DriverUI. Erstellen Sie das Projekt mit Gradle:
# To build only DriverUI module of aaos-apps-gradle-project use
./gradlew :driver-ui:assemble
Nach einem erfolgreichen Build ist die DriverUI-APK unter
out/aaos-apps-gradle-build/driver-ui/outputs/apk/default/debug/
driver-ui-default-debug.apk verfügbar.
Der DriverUI-Code ist unter packages/apps/Car/DriverUI verfügbar.
Hinweis: DriverUI ist ein Submodul des Haupt-Gradle-Projekts. Alle Gradle
Aufgaben werden daher mit aaos-apps-gradle-project ausgeführt.
SDV IVI-Ziel mit DriverUI erstellen
- Basisziel:
sdv_ivi_cf- Beschreibung:Dies dient als grundlegendes SDV-Ziel für IVI auf der x86-64-Architektur.
- Verzeichnisspeicherort:
device/google/sdv/
Integriertes DriverUI-Ziel:
sdv_ivi_cf_ds- Beschreibung:Dieses Ziel erweitert die Basis-IVI-Konfiguration um Display Safety-Komponenten. Dieses Ziel ist für die Validierung von Display Safety-Diensten und -Interaktionen im Kombiinstrument unerlässlich.
- Verzeichnisspeicherort:
device/google/sdv_dsplay_safety/ DriverUI-Binärdatei hinzufügen: Kopieren Sie
DriverUI.apknachpackages/apps/Car/DriverUIPrebuiltzusammen mit einer Blueprint-Android.bpDatei.# Create a blueprint file, contents of this file are shown in the next step touch /path/to/aosp_repo_root/packages/apps/Car/DriverUIPrebuilt/Android.bp # Copy DriverUI.apk built cp /path/to/ub-automotive-master/out/aaos-apps-gradle-build/driver-ui/outputs/apk/default/debug/driver-ui-default-debug.apk /path/to/aosp_repo_root/packages/apps/Car/DriverUIPrebuilt/DriverUI.apk
Android.bp sollte so eingerichtet sein, dass der Modulname DriverUIPrebuilt verwendet und DriverUIStubApp überschrieben wird:
android_app_import {
name: "DriverUIPrebuilt",
overrides: ["DriverUIStubApp"],
apk: "DriverUI.apk",
privileged: true,
product_specific: true,
certificate: "platform",
required: ["allowed_privapp_com.android.car.driverui"],
optional_uses_libs: [
"androidx.window.extensions",
"androidx.window.sidecar",
],
enforce_uses_libs: false,
dex_preopt: {
enabled: false,
},
}
Build-Ausführung :
# In the root of the Android source source build/envsetup.sh lunch sdv_ivi_cf_ds-trunk_staging-userdebug m -j
Zielbereitstellung
Nachdem der Build-Prozess für beide Ziele abgeschlossen ist, können Sie mit den Cuttlefish-Dienstprogrammen die Ziele wie in diesem Abschnitt beschrieben starten.
SDV Media- und HAR-Bereitstellung
Das HAR-Ziel wird mit der vordefinierten Konfiguration sdv-media-config.json erstellt, die in device/google/sdv_media_cf.mk angegeben ist.
Hinweis: SDV Media und SDV IVI werden beide im Bootmodus Unlocked für den
Display Safety-Cluster gestartet. Weitere Informationen finden Sie unter SDV-Bootmodus.
# In the root of the Android source
source build/envsetup.sh
lunch sdv_media_har_cf-trunk_staging-userdebug
cvd create --extra_bootconfig_args="androidboot.sdv.boot_mode=unlocked androidboot.sdv.instance_name=instance1 androidboot.virt.address=3"
Nach der Erstellung werden im Terminal Logs angezeigt, über die Sie im Browser auf einem Localhost
Port auf das Ziel zugreifen können: Point your browser to https://localhost:8443 to interact with the
device.

Abbildung 2 : SDV Media-VM mit HAR.
SDV IVI- und DriverUI-Bereitstellung
Das SDV IVI-DriverUI-Ziel wird mit der vorhandenen sdv-ivi-config.json gestartet, die in device/google/sdv_ivi_cf.mk definiert ist. Sie können auch zusätzliche Bootkonfigurationsparameter und geeignete Displayabmessungen für den Clusterbildschirm angeben.
# In the root of the Android source
source build/envsetup.sh
lunch sdv_ivi_cf_ds-trunk_staging-userdebug
cvd create --extra_bootconfig_args="androidboot.sdv.boot_mode=unlocked androidboot.sdv.instance_name=instance2 androidboot.virt.address=4" --display1=width=1920,height=720
Nachdem das Ziel gestartet wurde, werden im Terminal Logs angezeigt, über die Sie im Browser auf einem Localhost-Port auf das Ziel zugreifen können: Point your browser to https://localhost:8443 to
interact with the device.
Bei der Bereitstellung der SDV-IVI- und DriverUI-Ziele werden zwei Displays initialisiert: eines für das SDV-IVI-System und eines für die DriverUI. Die
DriverUI wird als privilegierte Cluster-App ausgeführt und verwendet die
ClusterHomeManager Klasse (auch bekannt als Cluster2).

Abbildung 3 : SDV IVI-VM mit DriverUI.
Bereitstellung des Clusters mit zwei VMs
Mit Cuttlefish können Sie zwei virtuelle Maschinen (VMs) mit einer Konfiguration mit zwei VMs starten, um eine Displayüberlagerung zu erreichen.

Abbildung 4 : Übersicht über die Displayzusammensetzung von Display Safety.
Sie können die Konfiguration mit zwei VMs mit ds-toolkit starten, das unter packages/services/display_safety/service/ verfügbar ist.
m ds_toolkit
ds_toolkit launch
Nachdem die Konfiguration gestartet wurde, werden im Terminal Logs angezeigt, über die Sie im Browser auf einem Localhost-Port auf das Ziel zugreifen können: Point your browser to https://localhost:8443 to
interact with the device.
Dadurch werden beide Cuttlefish-Ziele in einem voll funktionsfähigen Cluster gestartet, wobei die Displays beider virtueller Maschinen überlagert werden.

Abbildung 5 : Vollständiger Display Safety-Cluster mit SDV Media- und SDV IVI-VM.
Sicherheitsmonitor erstellen
Der Sicherheitsmonitor wird standardmäßig für eines der beiden SDV Media-Ziele erstellt:
# In the root of the Android source
source build/envsetup.sh
lunch sdv_media_har_cf-trunk_staging-userdebug
m -j
Zur Laufzeit verwendet der Sicherheitsmonitor eine Standardgruppe von Compiler-Artefakten, die generiert und in das APEX-Paket für das Referenz-Clusterdisplay gepackt werden.
Neue Artefakte können mit har-design-compiler generiert werden. Dieses Tool wird auf dem Ziel ausgeführt, um Artefakte aus einem Design zu generieren. Wir empfehlen, das Tool auszuführen, die neuen Artefakte vom Ziel abzurufen und das Image neu zu erstellen.
Das Tool wird standardmäßig auf dem Ziel erstellt und installiert.
# Run the compiler on the target
adb shell har_design_compiler -c </path/to/artifacts> -o /data/local/tmp/
# Pull the artifacts to the local filesystem
adb pull data/local/tmp/artifacts services/harry-prebuilt/data/assets/
# Rebuild the image
m -j
Der Sicherheitsmonitor wird initialisiert, wenn das Ziel gestartet wird. Der Sicherheitsmonitor wird kontinuierlich in einer Schleife ausgeführt, um sicherheitskritische Elemente auf dem Bildschirm mit den erwarteten Elementen zu vergleichen. Dazu werden der Bildschirmbuffer und eingehende Fahrzeugdatensignale analysiert.
Sie können die Logs des Sicherheitsmonitors jederzeit aufrufen:
adb logcat | grep har-safety-monitor