DriverUI

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

Figura 1. DriverUI.

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

DriverUI come attività del cluster predefinita

La DriverUI viene eseguita come app del 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 essa. Google fornisce implementazioni di riferimento delle API Cluster2.

Piattaforme

Puoi creare ed eseguire Display Safety su SDV. La piattaforma del veicolo software-defined (SDV):

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

Figura 2. Architettura della piattaforma SDV.

Unire l'output di HAR e DriverUI

HAR e DriverUI utilizzano display separati per eseguire il rendering della propria UI. I due output sono compositi e vengono visualizzati come un'unica immagine nella DriverUI.

A questo scopo, HAR controlla la trasparenza delle aree in cui viene visualizzato l'output di Android in base ai messaggi di heartbeat della DriverUI. Quando la DriverUI non è disponibile, HAR rileva la mancanza di heartbeat, esegue il rendering delle aree della DriverUI in modo opaco e visualizza 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.

Comunicazione tra DriverUI e HAR

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

gRPC viene utilizzato per le RPC. Su SDV, SDV Comms fornisce il client SDV Gateway per scoprire e stabilire un canale dalla DriverUI a HAR. Il servizio gRPC definisce un file di 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 di richiesta e risposta sono disponibili nell'origine di Display Safety all'indirizzo packages/apps/Car/DriverUI/proto/driverui.proto nel repository di codice ub-automotive.

Sulla piattaforma SDV, SDV Comms fornisce il client SDV Gateway per scoprire e stabilire un canale gRPC dalla DriverUI a HAR.

L'esecuzione di questi comandi utilizzando il terminale IVI invia la comunicazione 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.

Visualizzare informazioni su media, mappe e telefonia nel cluster

Tramite la comunicazione con l'IVI, la DriverUI può visualizzare informazioni su media, mappe e telefonia all'interno del cluster di riferimento. Sebbene Media funga da stato predefinito nell'implementazione di riferimento, il display si aggiorna in base ai servizi attivi in base alla seguente priorità:

1. Mappe
2. Telefonia
3. Media

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

I vari stati di visualizzazione della 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

La DriverUI implementa Automotive Design for Compose per consentire la visualizzazione e l'iterazione diretta dei progetti (Figma) all'interno dell'app Android. Questa integrazione colma il divario tra progettazione e sviluppo consentendo il rendering dei documenti di progettazione nell'ambiente di runtime.

Accedere agli asset di progettazione

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

1. Avvia la DriverUI con il file di progettazione DCF di Automotive Design for Compose locale da packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
2. Individua il file di 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 il rendering immediato delle modifiche apportate in Figma nella DriverUI. Ciò facilita i cicli di test rapidi e iterazione di progettazione più veloci.

Esegui il comando seguente per impostare il token Figma per la 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 delle VM duali

In una configurazione con due VM, gli aggiornamenti di progettazione devono propagarsi tra i limiti per mantenere la coerenza.

• La DriverUI recupera il documento di progettazione Figma più recente e lo trasmette a HAR utilizzando i canali di comunicazione gRPC descritti in questa pagina.
• Di conseguenza, l'intero cluster viene aggiornato con le iterazioni di progettazione Figma più recenti, mantenendo entrambe le VM sincronizzate con l'origine di progettazione.

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

Proteggere il canale gRPC

gRPC ha l'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.