L'interface utilisateur du cluster est traditionnellement placée derrière le volant sur un écran distinct. Les équipementiers combinent progressivement le cluster et l'IVI en un seul écran. Cette interface utilisateur combinée est la DriverUI.
Figure 1. DriverUI.
La DriverUI est une application système Android qui affiche un cluster d'instruments complet, à l'exception des éléments réglementaires ou liés à la sécurité rendus par le moteur de rendu à haute disponibilité (HAR). La DriverUI affiche des informations liées à la lecture de contenus multimédias , aux appels téléphoniques, aux cartes, à la navigation, etc. Elle implémente Automotive Design for Compose.
DriverUI comme activité de cluster par défaut
La 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 clusters d'instruments. Cette classe spécifie la configuration nécessaire pour identifier une implémentation de cluster d'instruments 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és ;
- exécute HAR dans SDV Media (également appelé VM de démarrage rapide) dans une VM invité ;
- exécute la DriverUI dans une autre VM invité SDV IVI ;
- exécute Safety Monitor sur la VM SDV Media.
Figure 2. Architecture de la plate-forme SDV.
Combiner la sortie HAR et la sortie DriverUI
Le HAR et la DriverUI utilisent des écrans distincts pour afficher leur interface utilisateur. Les deux sorties sont composites et apparaissent comme une seule image dans la DriverUI.
Pour ce faire, le HAR contrôle la transparence des zones dans lesquelles la sortie Android s'affiche en fonction des messages de pulsation de la DriverUI. Lorsque la DriverUI n'est pas disponible, le HAR détecte l'absence de pulsations, rend les zones de la 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 de la DriverUI sont définies comme transparentes.
Figure 3. Composition HAR et DriverUI.
Communication entre la DriverUI et le HAR
La DriverUI et le 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 sur le canal RPC et 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 la DriverUI et le 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'adresse packages/apps/Car/DriverUI/proto/driverui.proto dans le 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 la DriverUI et le HAR.
L'exécution de ces commandes à l'aide du terminal IVI envoie une communication à SDV Media, ce qui déclenche des mises à jour de 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
Figure 4. Communication RPC pour modifier le thème de la DriverUI et du HAR.
Afficher des informations sur les contenus multimédias, les cartes et la téléphonie sur le cluster
Grâce à la communication avec l'IVI, la DriverUI peut afficher des informations sur les contenus multimédias, les cartes et la téléphonie dans le cluster de référence. Bien que les contenus multimédias servent d'état par défaut dans l'implémentation de référence, l'écran est mis à jour en fonction des services actifs selon la priorité suivante :
- Cartes
- Téléphonie
- Contenus multimédias
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 par défaut des contenus multimédias.
Les différents états d'affichage de la DriverUI sont illustrés dans la figure suivante :
Figure 5. DriverUI présentant la section Contenus multimédias et Téléphonie dans le cluster complet.
Intégration d'Automotive Design for Compose
La DriverUI implémente Automotive Design for Compose pour permettre aux conceptions (Figma) de s'afficher et d'être itérées directement dans l'application Android. Cette intégration comble le fossé entre la conception et le développement en permettant le rendu des documents de conception dans l'environnement d'exécution.
Accéder aux éléments de conception
Des exemples de documents Figma pour la DriverUI font partie de la codebase. Pour accéder à ces conceptions et les modifier :
- Lancez la DriverUI avec le fichier de conception DCF local Automotive Design for Compose à partir de
packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf. - Recherchez le fichier d'élément
packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig. - Importez ce fichier dans Figma pour afficher les conceptions sources ou apporter des modifications.
Version d'Automotive Design for Compose
- Gradle utilise la version d'Automotive Design for Compose spécifiée pour
designcomposedanspackages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml. - Les versions d'Automotive Design for Compose sont disponibles sur la page des versions.
Configuration des mises à jour en direct
Automotive Design for Compose prend en charge les mises à jour en direct en mode développement, ce qui permet de rendre instantanément les modifications apportées dans Figma dans la DriverUI. Cela facilite les cycles de test rapide et d'itération de conception plus rapide.
Exécutez la commande suivante pour définir le jeton Figma pour la 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 à double VM
Dans une configuration à double VM, les mises à jour de conception doivent se propager au-delà des limites pour assurer la cohérence.
- La 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, le cluster complet 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.
Figure 6. Mise à jour en direct du document de conception de Figma vers la DriverUI et le HAR.
Sécuriser le canal gRPC
gRPC est intégré à SSL et TLS, et encourage 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 que les clients fournissent des certificats pour l'authentification mutuelle. Pour en savoir plus sur l'authentification gRPC, consultez la section Authentification.