Livello di astrazione della piattaforma HAR

Utilizza il renderer ad alta affidabilità (HAR) per mostrare le informazioni sul veicolo che Android non può visualizzare. Ciò può accadere a causa di problemi quali avvio, disponibilità, sicurezza o normative. HAR è un'app portatile integrata scritta in Rust.

HAR, chiamato anche framework HAR, include il codice che utilizzi per creare app. Un'app creata con HAR è un'app basata su HAR. Il framework HAR ha sezioni di codice per diverse piattaforme. Ad esempio, su un sistema Linux, utilizzi librerie come tinyalsa per i suoni. QNX ha le sue librerie audio uniche.

Una piattaforma include hardware, un sistema operativo, librerie di sistema e altri fattori. Il codice specifico della piattaforma è composto da parti chiamate sottosistemi. Ogni sottosistema gestisce una funzionalità della piattaforma, ad esempio audio, videocamere EVS o dati del veicolo. Per supportare una piattaforma, il framework HAR deve avere implementati tutti i suoi sottosistemi.

Il codice del sottosistema specifico della piattaforma potrebbe essere eseguito nello stesso processo dell'app basata su HAR o in uno separato. Se separato, questo codice gestisce la comunicazione interprocess (IPC) per verificare che la piattaforma supporti l'app. I meccanismi IPC complessi devono far parte del codice specifico della piattaforma.

La suite di test HAR esegue test su tutti i sottosistemi implementati per una piattaforma. Utilizza questa suite per verificare se le piattaforme soddisfano i requisiti HAR e per trovare eventuali nuovi problemi.

Terminologia

Questi termini si trovano in questa pagina:

App basata su HAR
Un'app specifica per OEM o funzionalità creata con il framework HAR. Le app variano in base allo stato dell'app e ad altri aspetti personalizzabili.
Framework HAR
Fornisce un insieme di strumenti di base utilizzati per creare app.
Astrazione della piattaforma HAR
Parte del framework HAR che fornisce un'API nota che tutte le piattaforme di destinazione devono implementare.
Suite di test HAR
Una serie di test noti sulle implementazioni della piattaforma, che aiutano a verificare che le implementazioni della piattaforma supportino il framework HAR su una determinata piattaforma.

Fuori ambito

HAR non riguarda:

  • Implementazioni individuali per tutti i target di piattaforma: implementazioni per le piattaforme di destinazione. Questa pagina descrive invece le interfacce che le implementazioni della piattaforma devono soddisfare e una suite di test deve soddisfare.

  • Scenari di test: scenari di test specifici per tutte le interfacce. Questa pagina, invece, descrive le singole funzioni per le interfacce, inclusi argomenti, valori restituiti, comportamenti previsti ed effetti collaterali previsti. Questa pagina descrive la suite di test in cui puoi implementare ed eseguire i casi di test.

Struttura di alto livello della crate di astrazione della piattaforma

I progetti Rust sono costituiti da crate. La figura 1 mostra la struttura della crate per il livello di astrazione della piattaforma HAR. Il livello di astrazione della piattaforma interessa due o più crate Rust:

  • Le astrazioni (descrizioni di Rust trait) si trovano nel crate del framework HAR.

  • Le implementazioni per una piattaforma vengono eseguite tramite una cassa har-platform-x separata. Ad esempio, har-platform-linux o har-platform-android.

Non puoi creare o testare il crate HAR senza un'implementazione della piattaforma specificata. Ciò è intenzionale, in quanto il framework HAR è un framework.

Un'app che specifica una piattaforma deve essere creata con questo framework per funzionare ed essere testata. I collegamenti tra il framework HAR e la piattaforma sono illustrati in questo diagramma:

Cassa HAR

Figura 1. Cassa HAR.

Struttura generale all'interno di display-safety

Questo progetto aggiunge una serie di nuove casse al repository display_safety, come illustrato nella Figura 2:

Cassa, framework e app HAR

Figura 2. Moduli di astrazione.

Una suite di test è strutturalmente simile a un'app, ma si basa solo su una determinata crate di implementazione della piattaforma. La suite di test deve fare riferimento a tratti e strutture definiti nel framework HAR, ma non deve fare riferimento a implementazioni più complesse.

Descrizione di alto livello del livello di astrazione della piattaforma

Questa tabella descrive i sottosistemi specifici della piattaforma definiti dal livello di astrazione della piattaforma HAR.

Nome astrazione Funzione correlata Descrizione Note
OpenGL Rendering 2D Fornisce funzionalità di rendering OpenGLES 2.0/3.0 al crate del framework HAR.
Audio Rendering audio Fornisce un'interfaccia simile a Android SoundPool per gestire e riprodurre l'audio di sistema.
Camera Display della videocamera del veicolo Fornisce un'interfaccia simile a EVS HAL per gestire e visualizzare le informazioni della videocamera del veicolo.
Looper Configurazione del ciclo principale e della visualizzazione dell'app Fornisce un'interfaccia simile a Android Looper per gestire i loop principali delle app specifici per la piattaforma e la configurazione della visualizzazione.
UserInput Tocco, tastiera, volante o controller rotativo e altri input specifici della piattaforma Fornisce un'interfaccia per fornire alle app basate su HAR input da tastiera e tocco. Implementazione di riferimento basata su Linux evdev in har-user-input-evdev.
VehicleData Input stato veicolo Fornisce un'interfaccia per fornire alle app basate su HAR un flusso di dati del veicolo arbitrari, ad esempio quelli forniti da Android VHAL o da un bus CAN.
ResourceManager Documento di progettazione memorizzato nella cache specifico per l'app Fornisce una cache in memoria delle risorse necessarie per l'avvio di HAR, come immagini memorizzate nella cache e documenti di progettazione. Nessuna cache del disco ancora implementata.
Logging Logging e telemetria di sistema Fornisce supporto per la registrazione specifica della piattaforma utilizzando il sistema di tracciamento. Ciò consente la raccolta della telemetria come richiesto dalla piattaforma.
Tracing Tracciamento del sistema Fornisce un'astrazione per l'integrazione con i sistemi di tracciamento e profilazione.
Monitoring Monitoraggio del sistema Toolkit per il monitoraggio delle prestazioni e delle latenze all'interno del framework HAR.
Commlib Dati del veicolo Un'implementazione di riferimento che utilizza la serializzazione protobuf. Obsoleto: utilizza le API definite in reference/harry-control-api e le implementazioni harry-grpcio-server e harry-tonic-server (implementazione di riferimento).
TestSupport Hook di supporto per i test Supporta la creazione e l'eliminazione di scenari di test, la generazione di eventi di test e la creazione di elementi di test. Ad esempio, la generazione di eventi touch simulati per testare UserInput e la generazione di screenshot per l'analisi. Questa funzionalità è bloccata da Rust per impedire l'inclusione nelle build di produzione.

Convenzioni di denominazione e strutture dei framework

Questa tabella mostra i nomi e le strutture:

  • Istanze del sottosistema previste trait fornite dal framework HAR. Ogni trait rappresenta un sottosistema specifico della piattaforma che deve essere implementato.

  • Nomi previsti delle implementazioni di sottosistemi specifici della piattaforma in qualsiasi crate della piattaforma. Le app basate su HAR prevedono l'implementazione di questi nomi specifici.

  • Le istanze enum e struct del framework HAR correlate vengono in genere utilizzate per trasferire informazioni dalle implementazioni correlate alla piattaforma al framework HAR.

Nomi dei tratti Nomi delle implementazioni Enumerazione e struct del framework HAR
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 N/D
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

Errori e gestione degli errori

Le API proposte utilizzano il tipo Result<> di Rust. Rust richiede di controllare i tipi Result che contengono errori. In caso contrario, il compilatore genera un avviso o un errore. Un controllo in fase di compilazione applica il controllo degli errori dal codice specifico della piattaforma.

Gli errori restituiti dalle implementazioni della piattaforma sono di tipo harry::error::Error. Per verificare che i tipi di errore della piattaforma non vengano inseriti nel codice dell'app, utilizza il tipo di errore standard fornito dal framework HAR.

Il tipo harry::error::Error si espande per includere errori specifici per tutti i sottosistemi:

// 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),
}

Gli errori non recuperabili vengono restituiti principalmente tramite le interfacce e i callback definiti.

Progettazione dettagliata della suite di test

Questa sezione descrive la progettazione della suite di test, che verifica le implementazioni specifiche della piattaforma delle astrazioni.

Crea i test della suite di test

Per le build Soong (definite dai file Android.bp), i test vengono compilati come parte del sistema di compilazione della piattaforma Android e la loro esecuzione è gestita da atest.

Esegui la suite di test

Per testare una singola piattaforma:

Utilizza il comando atest con il target di test pertinente (ad esempio, atest <module_name>). Questo comando esegue il deployment e l'esecuzione dei test su un dispositivo o un emulatore Android.