DriverUI

L'UI del quadro strumenti è tradizionalmente posizionata dietro il volante in un display separato. Gli OEM combinano gradualmente il quadro strumenti e l'IVI in un unico display. Questa UI combinata è la DriverUI.

Figura 1. DriverUI.

DriverUI è un'app di sistema Android che esegue il rendering di un intero display del quadro strumenti, esclusi gli elementi normativi o relativi alla sicurezza di cui viene eseguito il rendering dal renderer ad alta affidabilità (HAR). La DriverUI mostra informazioni relative alla riproduzione di contenuti multimediali, alle chiamate, alle mappe, alla navigazione e altro ancora e implementa Automotive Design for Compose.

DriverUI come attività predefinita del cluster

DriverUI viene eseguita come app cluster con privilegi in Android e AAOS la avvia automaticamente.

AAOS utilizza la classe ClusterHomeManager, nota anche come Cluster2, per creare i quadri strumenti. Questa classe specifica la configurazione necessaria per identificare un'implementazione del quadro strumenti e il modo in cui AAOS interagisce con questa. Google fornisce implementazioni di riferimento delle API Cluster2.

Piattaforme

Puoi creare ed eseguire Display Safety su SDV. La piattaforma SDV (Software-Defined Vehicle):

• Richiede due VM guest.
• Esegue HAR in SDV Media (noto anche come VM di avvio rapido) in una VM guest.
• Esegue DriverUI in un'altra VM IVI SDV guest.
• Esegue Safety Monitor sulla VM multimediale SDV.

Figura 2. Architettura della piattaforma SDV.

Unisci l'output HAR e DriverUI

HAR e DriverUI utilizzano display separati per il rendering della UI. Le due uscite sono composite e vengono visualizzate come un'unica immagine nella DriverUI.

A questo scopo, l'HAR controlla la trasparenza delle aree in cui viene visualizzato l'output di Android in base ai messaggi di heartbeat di DriverUI. Quando la DriverUI non è disponibile, l'HAR rileva l'assenza di battiti, rende opache le aree della DriverUI e mostra i segnaposto. Quando vengono ricevuti gli heartbeat, i segnaposto vengono rimossi e le aree della DriverUI vengono impostate come trasparenti.

Figura 3. Composizione di HAR e DriverUI.

Risolvi i problemi relativi alla composizione alfa e al punch-through

Poiché l'HAR è fondamentale per la sicurezza, il suo piano di visualizzazione hardware si trova sopra il piano di visualizzazione IVI di Android. Quando crei o esegui il debug di visualizzazioni personalizzate o superfici OpenGL ES esterne nell'HAR, verifica come sono impostati i valori alfa:

• Output DriverUI mancante nel piano HAR: sebbene l'HAR riceva messaggi HeartbeatRequest validi da DriverUI, l'HAR deve cancellare la regione dell'area visibile di DriverUI in modo che sia trasparente (alpha = 0.0) in modo che la UI del cluster Android sottostante sia visibile. Se un livello HAR personalizzato o uno sfondo disegna pixel opachi (alpha = 1.0) sull'area DriverUI, blocca l'output di Android sottostante.
• Fori trasparenti non intenzionali in superfici 3D o OpenGL personalizzate: quando esegui il rendering di una superficie OpenGL ES o 3D esterna in un nodo HAR (ad esempio un indicatore o una scena 3D personalizzati che scrivono pixel RGB con un byte alfa inutilizzato lasciato a 0x00), imposta esplicitamente il canale alfa dei pixel opachi su 0xFF (alpha = 1.0). Se lasci il byte alfa su 0x00, il compositore tratta questi pixel come trasparenti (alpha = 0.0) e crea un foro direttamente attraverso il livello HAR fino al piano IVI Android sottostante.
• Diagnostica di visualizzazione tra VM:poiché l'HAR (sdv_media_har_cf) e l'IVI Android (sdv_ivi_cf_ds) vengono eseguiti in VM guest separate, l'esecuzione di adb shell dumpsys SurfaceFlinger sulla VM IVI Android ispeziona solo i livelli Android e non ha visibilità sul piano HAR sovrastante.

Comunicazione tra DriverUI e HAR

DriverUI e HAR comunicano tra loro tramite chiamate di procedura remota (RPC). Il messaggio heartbeat è un esempio di dati inviati tramite il canale RPC e include un timestamp come uno dei suoi campi.

gRPC viene utilizzato per le RPC. Su SDV, le comunicazioni SDV forniscono il client gateway SDV per rilevare e stabilire un canale dalla DriverUI all'HAR. Il servizio gRPC definisce un file buffer di protocollo:

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

I dettagli della richiesta e della risposta si trovano nell'origine Display Safety all'indirizzo packages/apps/Car/DriverUI/proto/driverui.proto nel repository del codice sorgente ub-automotive.

Sulla piattaforma SDV, le comunicazioni SDV forniscono il client gateway SDV per rilevare e stabilire un canale gRPC dalla DriverUI all'HAR.

L'esecuzione di questi comandi tramite il terminale IVI invia comunicazioni a SDV Media, attivando gli aggiornamenti dei temi nell'intero cluster.

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

Figura 4. Comunicazione RPC per modificare il tema di DriverUI e HAR.

Visualizza informazioni su contenuti multimediali, mappe e telefonia sul cluster

Tramite la comunicazione con l'IVI, DriverUI può visualizzare informazioni per contenuti multimediali, Maps e telefonia all'interno del cluster di riferimento. Sebbene Media sia lo stato predefinito nell'implementazione di riferimento, il display si aggiorna in base ai servizi attivi secondo la seguente priorità:

1. Maps
2. Telefonia
3. Media

Il sistema dà automaticamente la priorità alla visualizzazione della navigazione di Maps o dei servizi di telefonia attivi rispetto allo stato predefinito dei contenuti multimediali.

I vari stati di visualizzazione di DriverUI sono illustrati nella figura seguente:

Figura 5. DriverUI che mostra la sezione Media e Telefonia nel cluster completo.

Integrazione di Automotive Design for Compose

DriverUI implementa Automotive Design for Compose per consentire ai design (Figma) di essere mostrati e ripetuti direttamente nell'app per Android. Questa integrazione colma il divario tra progettazione e sviluppo consentendo il rendering dei documenti di progettazione nell'ambiente di runtime.

Accedi agli asset di progettazione

I documenti Figma di esempio per DriverUI fanno parte del codebase. Per accedere a questi design e modificarli:

1. Avvia DriverUI con il file di progettazione DCF locale di Automotive Design for Compose da packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
2. Individua il file degli asset packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
3. Importa questo file in Figma per visualizzare i progetti di origine o apportare modifiche.

Versione di Automotive Design for Compose

• Gradle utilizza la versione di Automotive Design for Compose specificata per designcompose in packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
• Le release di Automotive Design for Compose sono disponibili nella pagina delle release.

Configurazione degli aggiornamenti in tempo reale

Automotive Design for Compose supporta gli aggiornamenti in tempo reale in modalità di sviluppo, consentendo di eseguire il rendering istantaneo delle modifiche apportate in Figma in DriverUI. In questo modo, i cicli di test rapidi e iterazione più veloce del design sono più semplici.

Esegui questo comando per impostare il token Figma per DriverUI:

adb shell am startservice \
  -n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
  -a setApiKey \
  -e ApiKey $FIGMA_ACCESS_TOKEN \
  --user 0

Sincronizzazione dei documenti di progettazione di Dual VM

In una configurazione con doppia VM, gli aggiornamenti del design devono propagarsi oltre i confini per mantenere la coerenza.

• DriverUI recupera l'ultimo documento di progettazione Figma e lo trasmette all'HAR utilizzando i canali di comunicazione gRPC descritti in questa pagina.
• Di conseguenza, l'intero cluster viene aggiornato con le ultime iterazioni del design di Figma, mantenendo entrambe le VM sincronizzate con l'origine del design.

Figura 6. Aggiornamento in tempo reale del documento di progettazione da Figma a DriverUI e HAR.

Proteggi il canale gRPC

gRPC ha un'integrazione SSL e TLS e promuove l'utilizzo di SSL e TLS per autenticare il server e criptare tutti i dati scambiati tra il client e il server. Sono disponibili meccanismi facoltativi per consentire ai client di fornire certificati per l'autenticazione reciproca. Per saperne di più sull'autenticazione gRPC, consulta Autenticazione.