HAR-Plattformabstraktionsschicht

Verwenden Sie den High Availability Renderer (HAR), um Fahrzeuginformationen anzuzeigen, die Android nicht darstellen kann. Das kann an Problemen wie Start-up, Verfügbarkeit, Sicherheit oder Vorschriften liegen. HAR ist eine portable, integrierte App, die in Rust geschrieben wurde.

HAR, auch HAR-Framework genannt, enthält Code, den Sie zum Erstellen von Apps verwenden. Eine mit HAR entwickelte App ist eine HAR-basierte App. Das HAR-Framework enthält Codeabschnitte für verschiedene Plattformen. Unter Linux verwenden Sie beispielsweise Bibliotheken wie tinyalsa für Sounds. QNX hat eigene Audiobibliotheken.

Eine Plattform umfasst Hardware, ein Betriebssystem, Systembibliotheken und andere Faktoren. Plattformspezifischer Code hat Teile, die als Subsysteme bezeichnet werden. Jedes Subsystem ist für eine Plattformfunktion zuständig, z. B. Audio, EVS-Kameras oder Fahrzeugdaten. Damit eine Plattform unterstützt werden kann, müssen alle Subsysteme des HAR-Frameworks implementiert sein.

Plattformspezifischer Subsystemcode kann im selben Prozess wie die HAR-basierte App oder in einem separaten Prozess ausgeführt werden. Wenn der Code separat ist, wird damit die Interprozesskommunikation (IPC) verarbeitet, um zu prüfen, ob die Plattform die App unterstützt. Komplexe IPC-Mechanismen müssen Teil des plattformspezifischen Codes sein.

Die HAR-Testsuite führt Tests für alle Subsysteme aus, die für eine Plattform implementiert wurden. Mit dieser Suite können Sie prüfen, ob Plattformen die HAR-Anforderungen erfüllen, und neue Probleme finden.

Terminologie

Diese Begriffe finden Sie auf dieser Seite:

HAR-basierte App
Eine OEM- oder funktionsspezifische App, die mit dem HAR-Framework erstellt wurde. Apps unterscheiden sich je nach App-Status und anderen anpassbaren Aspekten.
HAR-Framework
Bietet eine Reihe von Basistools zum Erstellen von Apps.
HAR-Plattformabstraktion
Teil des HAR-Frameworks, das eine bekannte API bereitstellt, die von allen Zielplattformen implementiert werden muss.
HAR-Testsuite
Eine Reihe bekannter Tests für Plattformimplementierungen, mit denen überprüft werden kann, ob Plattformimplementierungen das HAR-Framework auf einer bestimmten Plattform unterstützen.

Gehört nicht zum Umfang

HAR geht nicht auf Folgendes ein:

  • Individuelle Implementierungen für alle Zielplattformen: Implementierungen für Zielplattformen. Stattdessen werden auf dieser Seite die Schnittstellen beschrieben, die Plattformimplementierungen erfüllen müssen, und die Testsuite, die sie erfüllen muss.

  • Testläufe: Spezifische Testläufe für alle Schnittstellen. Stattdessen werden auf dieser Seite einzelne Funktionen für Schnittstellen beschrieben, einschließlich Argumenten, Rückgabewerten, erwarteten Verhaltensweisen und erwarteten Nebeneffekten. Auf dieser Seite wird die Testsuite beschrieben, in der Sie Testläufe implementieren und ausführen können.

Allgemeine Kistenstruktur für die Plattformabstraktion

Rust-Projekte bestehen aus Crates. Abbildung 1 zeigt die Kistenstruktur für die HAR-Plattformabstraktionsschicht. Die Plattformabstraktionsschicht betrifft mindestens zwei Rust-Crates:

  • Abstraktionen (Rust-trait-Beschreibungen) befinden sich im HAR-Framework-Crate.

  • Implementierungen für eine Plattform erfolgen über ein separates har-platform-x-Crate. Zum Beispiel har-platform-linux oder har-platform-android.

Sie können die HAR-Crate nicht ohne eine angegebene Plattformimplementierung erstellen oder testen. Das ist beabsichtigt, da HAR ein Framework ist.

Eine App, die eine Plattform angibt, muss mit diesem Framework erstellt werden, damit sie funktioniert und getestet werden kann. Die Verbindungen zwischen dem HAR-Framework und der Plattform sind in diesem Diagramm dargestellt:

HAR-Crate

Abbildung 1. HAR-Box

Allgemeine Struktur in display-safety

Bei diesem Design werden dem Repository display_safety eine Reihe neuer Crates hinzugefügt, wie in Abbildung 2 dargestellt:

HAR-Crate, Framework und App

Abbildung 2: Abstraktionsmodule.

Eine Testsuite ist strukturell einer App ähnlich, basiert jedoch nur auf einem bestimmten Implementierungs-Crate für die Plattform. Die Testsuite muss sich auf Merkmale und Strukturen beziehen, die im HAR-Framework definiert sind, aber nicht auf komplexere Implementierungen.

Allgemeine Beschreibung der Plattformabstraktionsschicht

In dieser Tabelle werden plattformspezifische Subsysteme beschrieben, die durch die HAR-Plattformabstraktionsschicht definiert werden.

Name der Abstraktion Ähnliche Funktion Beschreibung Hinweise
OpenGL 2D-Rendering Bietet OpenGLES 2.0/3.0-Renderingfunktionen für die HAR-Framework-Crate.
Audio Audio-Rendering Bietet eine Android SoundPool-ähnliche Schnittstelle zum Verwalten und Abspielen von Systemaudio.
Camera Display der Fahrzeugkamera Bietet eine EVS-HAL-ähnliche Schnittstelle zum Verwalten und Anzeigen von Informationen zur Fahrzeugkamera.
Looper Hauptschleife der App und Displaykonfiguration Bietet eine Android-Looper-ähnliche Schnittstelle zum Verwalten plattformspezifischer App-Hauptschleifen und der Displaykonfiguration.
UserInput Berührung, Tastatur, Lenkrad oder Drehregler und andere plattformspezifische Eingaben Bietet eine Schnittstelle, um HAR-basierte Apps mit Touch- und Tastatureingaben zu versorgen. Referenzimplementierung basierend auf Linux evdev in har-user-input-evdev.
VehicleData Eingabe für Fahrzeugstatus Bietet eine Schnittstelle, um HAR-basierten Apps einen Stream beliebiger Fahrzeugdaten zur Verfügung zu stellen, wie sie von Android VHAL oder einem CAN-Bus bereitgestellt werden.
ResourceManager App-spezifisches Design-Dokument im Cache Bietet einen In-Memory-Cache von Ressourcen, die für den HAR-Start erforderlich sind, z. B. zwischengespeicherte Bilder und Designdokumente. Noch kein Datenträger-Cache implementiert.
Logging System-Logging und ‑Telemetrie Bietet plattformspezifische Unterstützung für die Protokollierung über das Ablaufverfolgungssystem. Dadurch wird die Erfassung von Telemetriedaten gemäß den Anforderungen der Plattform aktiviert.
Tracing Ablaufverfolgung Bietet eine Abstraktionsebene für die Integration in Tracing- und Profiling-Systeme.
Monitoring System monitoring Toolkit zur Überwachung von Leistung und Latenzen im HAR-Framework.
Commlib Fahrzeugdaten Eine Referenzimplementierung mit Protobuf-Serialisierung. Eingestellt: Verwenden Sie die in reference/harry-control-api definierten APIs und die Implementierungen harry-grpcio-server und harry-tonic-server (Referenzimplementierung).
TestSupport Support-Hooks testen Unterstützt das Erstellen und Entfernen von Testläufen, das Generieren von Testereignissen und das Erstellen von Testartefakten. Beispielsweise werden simulierte Touch-Ereignisse zum Testen von UserInput und Screenshots zur Analyse generiert. Diese Funktion ist durch Rust gesperrt, um die Einbindung in Produktions-Builds zu verhindern.

Namenskonventionen und Framework-Strukturen

In dieser Tabelle sind diese Namen und Strukturen aufgeführt:

  • Erwartete trait-Instanzen des Subsystems, die vom HAR-Framework bereitgestellt werden. Jedes trait steht für ein plattformspezifisches Subsystem, das implementiert werden muss.

  • Erwartete Namen der plattformspezifischen Subsystemimplementierungen in einem beliebigen Plattform-Crate. Bei HAR-basierten Apps müssen diese spezifischen Namen implementiert werden.

  • Zugehörige enum- und struct-Instanzen des HAR-Frameworks, die in der Regel verwendet werden, um Informationen von plattformbezogenen Implementierungen an das HAR-Framework zu übergeben.

Eigenschaftsnamen Implementierungsnamen HAR-Framework-Enum und ‑Structs
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (Struct) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing –
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

Fehler und Fehlerbehebung

Die vorgeschlagenen APIs verwenden den Rust-Typ Result<>. In Rust müssen Sie Result-Typen prüfen, die Fehler enthalten. Andernfalls gibt der Compiler eine Warnung oder einen Fehler aus. Bei einer Build-Zeit-Prüfung wird die Fehlerprüfung aus plattformspezifischem Code erzwungen.

Von Plattformimplementierungen zurückgegebene Fehler haben den Typ harry::error::Error. Verwenden Sie den Standardfehlertyp des HAR-Frameworks, um zu prüfen, ob Plattformfehlertypen in den App-Code gelangen.

Der Typ harry::error::Error wird erweitert, um spezifische Fehler für alle Subsysteme zu enthalten:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

Nicht behebungsfähige Fehler werden hauptsächlich über die definierten Schnittstellen und Rückrufe zurückgegeben.

Detaillierte Konfiguration der Testsuite

In diesem Abschnitt wird das Design der Testsuite beschrieben, mit der plattformspezifische Implementierungen der Abstraktionen überprüft werden.

Testsuite-Tests erstellen

Bei Soong-Builds (definiert durch Android.bp-Dateien) werden die Tests als Teil des Android-Plattform-Build-Systems kompiliert und ihre Ausführung wird von atest verwaltet.

Testsuite ausführen

So testen Sie eine einzelne Plattform:

Verwenden Sie den Befehl atest mit dem entsprechenden Testziel (z. B. atest <module_name>). Mit diesem Befehl werden die Tests auf einem Android-Gerät oder -Emulator bereitgestellt und ausgeführt.