DriverUI

L'UI du cluster est généralement placée derrière le volant sur un écran distinct. Les OEM combinent progressivement le cluster et l'IVI en un seul écran. Cette UI combinée est la DriverUI.

DriverUI

Figure 1. DriverUI.

DriverUI est une application système Android qui affiche l'intégralité d'un tableau de bord, à l'exception des éléments de sécurité ou réglementaires affichés par le moteur de rendu haute disponibilité (HAR). DriverUI affiche des informations sur la lecture de contenus multimédias, les appels téléphoniques, les cartes, la navigation et plus encore, et implémente Automotive Design pour Compose.

DriverUI comme activité de cluster par défaut

DriverUI s'exécute en tant qu'application de cluster privilégiée dans Android, et AAOS la démarre automatiquement.

AAOS utilise la classe ClusterHomeManager, également appelée Cluster2, pour créer des combinés d'instruments. Cette classe spécifie la configuration nécessaire pour identifier une implémentation de tableau de bord et la manière dont AAOS interagit avec elle. Google fournit des implémentations de référence des API Cluster2.

Plates-formes

Vous pouvez créer et exécuter Display Safety sur SDV. La plate-forme de véhicule défini par logiciel (SDV) :

  • Nécessite deux VM invitées.
  • Exécute HAR dans SDV Media (également appelé "VM à démarrage rapide") dans une VM invitée.
  • Exécute DriverUI dans une autre VM SDV IVI invitée.
  • Exécute Safety Monitor sur la VM SDV Media.

Architecture de la plate-forme SDV

Figure 2. Architecture de la plate-forme SDV.

Combiner les résultats HAR et DriverUI

Le HAR et DriverUI utilisent des écrans distincts pour afficher leur UI. Les deux sorties sont composites et apparaissent comme une seule image dans DriverUI.

Pour ce faire, le HAR contrôle la transparence des zones dans lesquelles la sortie Android apparaît en fonction des messages de pulsation de DriverUI. Lorsque DriverUI n'est pas disponible, HAR détecte l'absence de signaux de pulsation, rend les zones DriverUI opaques et affiche des espaces réservés. Lorsque les pulsations sont reçues, les espaces réservés sont supprimés et les zones DriverUI sont définies comme transparentes.

Composition de HAR et DriverUI

Figure 3. Composition de HAR et DriverUI.

Résoudre les problèmes de composition alpha et de punch-through

Étant donné que le HAR est essentiel à la sécurité, son plan d'affichage matériel se trouve au-dessus du plan d'affichage IVI Android. Lorsque vous créez ou déboguez des vues personnalisées ou des surfaces OpenGL ES externes dans le HAR, vérifiez comment les valeurs alpha sont définies :

  • Sortie DriverUI manquante sous le plan HAR : bien que le HAR reçoive des messages HeartbeatRequest valides de DriverUI, il doit effacer la région de la fenêtre d'affichage DriverUI pour la rendre transparente (alpha = 0.0) afin que l'UI du cluster Android sous-jacente soit visible. Si une couche ou un arrière-plan HAR personnalisé dessine des pixels opaques (alpha = 1.0) sur la zone DriverUI, il bloque la sortie Android en dessous.
  • Trous transparents involontaires dans les surfaces 3D ou OpenGL personnalisées : lorsque vous affichez une surface OpenGL ES ou 3D externe dans un nœud HAR (par exemple, une jauge ou une scène 3D personnalisée qui écrit des pixels RGB avec un octet alpha inutilisé laissé à 0x00), définissez explicitement le canal alpha des pixels opaques sur 0xFF (alpha = 1.0). Si vous laissez l'octet alpha à 0x00, le compositeur traite ces pixels comme transparents (alpha = 0.0) et perce un trou directement dans la couche HAR jusqu'au plan Android IVI sous-jacent.
  • Diagnostics d'affichage entre VM : étant donné que le HAR (sdv_media_har_cf) et l'IVI Android (sdv_ivi_cf_ds) s'exécutent dans des VM invitées distinctes, l'exécution de adb shell dumpsys SurfaceFlinger sur la VM IVI Android n'inspecte que les couches Android et n'a aucune visibilité sur le plan HAR sus-jacent.

Communication entre DriverUI et HAR

DriverUI et HAR communiquent entre eux à l'aide d'appels de procédure à distance (RPC). Le message de pulsation est un exemple de données envoyées via le canal RPC. Il se compose d'un code temporel comme l'un de ses champs.

gRPC est utilisé pour les RPC. Sur SDV, SDV comms fournit le client de passerelle SDV pour découvrir et établir un canal entre DriverUI et HAR. Le service gRPC définit un fichier de tampon de protocole :


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

Les détails de la requête et de la réponse se trouvent dans la source Display Safety à l'emplacement packages/apps/Car/DriverUI/proto/driverui.proto du dépôt de code source ub-automotive.

Sur la plate-forme SDV, SDV Comms fournit le client de passerelle SDV pour découvrir et établir un canal gRPC entre DriverUI et HAR.

L'exécution de ces commandes à l'aide du terminal IVI envoie une communication à SDV Media, ce qui déclenche des mises à jour du thème sur l'ensemble du 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

Communication RPC pour modifier le thème de DriverUI et de HAR.

Figure 4. Communication RPC pour modifier le thème DriverUI et HAR.

Afficher les informations sur les contenus multimédias, Maps et la téléphonie sur le tableau de bord

En communiquant avec l'IVI, DriverUI peut afficher des informations sur les contenus multimédias, Maps et la téléphonie dans le cluster de référence. Bien que l'état par défaut de l'implémentation de référence soit "Contenus multimédias", l'affichage est mis à jour en fonction des services actifs selon l'ordre de priorité suivant :

  1. Maps
  2. Téléphonie
  3. Multimédia

Le système donne automatiquement la priorité à l'affichage de la navigation Maps ou des services de téléphonie actifs par rapport à l'état multimédia par défaut.

Les différents états d'affichage de DriverUI sont illustrés dans la figure suivante :

DriverUI présentant la section "Contenus multimédias et téléphonie" dans un cluster complet.

Figure 5. DriverUI présentant la section "Multimédia et téléphonie" dans le cluster complet.

Conception automobile pour l'intégration de Compose

DriverUI implémente Automotive Design for Compose pour permettre aux conceptions (Figma) d'être présentées et d'itérer directement dans l'application Android. Cette intégration comble l'écart entre la conception et le développement en permettant l'affichage des documents de conception dans l'environnement d'exécution.

Accéder aux éléments de conception

Des exemples de documents Figma pour DriverUI font partie du codebase. Pour accéder à ces conceptions et les modifier :

  1. Lancez DriverUI avec le fichier de conception DCF Automotive Design for Compose local à partir de packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
  2. Recherchez le fichier d'élément packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
  3. Importez ce fichier dans Figma pour afficher les conceptions sources ou apporter des modifications.

Version d'Automotive Design pour Compose

  • Gradle utilise la version d'Automotive Design pour Compose spécifiée pour designcompose dans packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
  • Les versions d'Automotive Design for Compose sont disponibles sur la page Versions.

Configuration des mises à jour en direct

Automotive Design for Compose est compatible avec les mises à jour en temps réel en mode développement, ce qui permet d'afficher instantanément les modifications apportées dans Figma dans DriverUI. Cela facilite les cycles de tests rapides et d'itération de conception plus rapide.

Exécutez la commande suivante pour définir le jeton Figma pour DriverUI :

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

Synchronisation des documents de conception de VM double

Dans une configuration à double VM, les mises à jour de conception doivent se propager au-delà des limites pour maintenir la cohérence.

  • DriverUI récupère le dernier document de conception Figma et le transmet au HAR à l'aide des canaux de communication gRPC décrits sur cette page.
  • Par conséquent, l'ensemble du cluster est mis à jour avec les dernières itérations de conception Figma, ce qui permet de synchroniser les deux VM avec la source de conception.

Mise à jour en direct du document de conception de Figma vers DriverUI et HAR.

Figure 6. Mise à jour en direct du document de conception de Figma vers DriverUI et HAR.

Sécuriser le canal gRPC

gRPC intègre SSL et TLS, et favorise l'utilisation de SSL et TLS pour authentifier le serveur et chiffrer toutes les données échangées entre le client et le serveur. Des mécanismes facultatifs sont disponibles pour permettre aux clients de fournir des certificats pour l'authentification mutuelle. Pour en savoir plus sur l'authentification gRPC, consultez Authentification.