Tradicionalmente, la IU del clúster se ubica detrás del volante en una pantalla separada. Los OEM combinan gradualmente el clúster y el IVI en una sola pantalla. Esta IU combinada es la DriverUI.
Figura 1: DriverUI.
DriverUI es una app del sistema Android que renderiza toda la pantalla del panel de instrumentos, excepto los elementos relacionados con la seguridad o los reglamentarios que renderiza el renderizador de alta disponibilidad (HAR). DriverUI muestra información relacionada con la reproducción de contenido multimedia, las llamadas telefónicas, los mapas, la navegación y mucho más, y también implementa Automotive Design for Compose.
DriverUI como la actividad de clúster predeterminada
DriverUI se ejecuta como una app de clúster con privilegios en Android, y AAOS la inicia automáticamente.
AAOS usa la clase ClusterHomeManager, también conocida como Cluster2, para compilar clústeres de instrumentos. Esta clase especifica la configuración necesaria para identificar una implementación del panel de instrumentos y cómo interactúa AAOS con ella. Google proporciona implementaciones de referencia de las APIs de Cluster2.
Plataformas
Puedes compilar y ejecutar la Seguridad de la pantalla en el SDV. La plataforma de vehículos definidos por software (SDV) incluye lo siguiente:
- Se requieren dos VMs invitadas.
- Ejecuta HAR en SDV Media (también conocida como la VM de inicio rápido) en una VM invitada.
- Ejecuta DriverUI en otra VM de IVI de SDV invitada.
- Ejecuta Safety Monitor en la VM de medios de SDV.
Figura 2: Arquitectura de la plataforma de SDV.
Combina el archivo HAR y el resultado de DriverUI
El HAR y DriverUI usan pantallas separadas para renderizar su IU. Los dos resultados son compuestos y aparecen como una sola imagen en la DriverUI.
Para lograr esto, el HAR controla la transparencia de las áreas en las que aparece el resultado de Android en función de los mensajes de latido del DriverUI. Cuando la DriverUI no está disponible, el HAR detecta la falta de latidos y renderiza las áreas de la DriverUI opacas y muestra marcadores de posición. Cuando se reciben los latidos, se quitan los marcadores de posición y se configuran las áreas de la IU del conductor para que sean transparentes.
Figura 3: Composición de HAR y DriverUI.
Comunicación de DriverUI y HAR
La DriverUI y HAR se comunican entre sí a través de llamadas de procedimiento remoto (RPC). El mensaje de latido es un ejemplo de datos enviados a través del canal de RPC y consta de una marca de tiempo como uno de sus campos.
gRPC se usa para las RPC. En SDV, las comunicaciones de SDV proporcionan el cliente de la puerta de enlace de SDV para descubrir y establecer un canal desde DriverUI hasta HAR. El servicio de gRPC define un archivo de búfer de protocolo:
// 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) {}
Los detalles de la solicitud y la respuesta se encuentran en la fuente Display Safety en packages/apps/Car/DriverUI/proto/driverui.proto en el repositorio de código fuente de ub-automotive.
En la plataforma de SDV, las comunicaciones de SDV proporcionan el cliente de puerta de enlace de SDV para descubrir y establecer un canal gRPC desde DriverUI hasta el HAR.
La ejecución de estos comandos con la terminal del IVI envía comunicación a SDV Media, lo que activa las actualizaciones de temas en todo el clúster.
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: Comunicación de RPC para cambiar el tema de DriverUI y HAR.
Información de Display Media, Maps y Telephony en el clúster
A través de la comunicación con el IVI, la DriverUI puede mostrar información sobre Multimedia, Maps y Telefonía dentro del clúster de referencia. Si bien Media funciona como el estado predeterminado en la implementación de referencia, la pantalla se actualiza según los servicios activos, de acuerdo con la siguiente prioridad:
- Maps
- Telefonía
- Medios
El sistema prioriza automáticamente la visualización de la navegación de Maps o los servicios de telefonía activos por sobre el estado de medios predeterminado.
En la siguiente figura, se ilustran los distintos estados de visualización de DriverUI:
Figura 5: La IU del conductor muestra la sección de medios y telefonía en el clúster completo.
Diseño de Automotive para la integración de Compose
La DriverUI implementa Automotive Design for Compose para permitir que los diseños (Figma) se muestren y se iteren directamente en la app para Android. Esta integración une la brecha entre el diseño y el desarrollo, ya que permite la renderización de documentos de diseño en el entorno de ejecución.
Accede a los recursos de diseño
Los documentos de Figma de ejemplo para DriverUI forman parte de la base de código. Para acceder a estos diseños y modificarlos, haz lo siguiente:
- Inicia DriverUI con el archivo de diseño DCF de Automotive Design for Compose local desde
packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf. - Ubica el archivo de recursos
packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig. - Importa este archivo a Figma para ver los diseños fuente o realizar cambios.
Diseño automotriz para la versión de Compose
- Gradle usa la versión de Automotive Design for Compose especificada para
designcomposeenpackages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml. - Las versiones de Automotive Design for Compose están disponibles en la página de versiones.
Configuración de actualización en vivo
Automotive Design for Compose admite actualizaciones en vivo en el modo de desarrollo, lo que permite que los cambios realizados en Figma se rendericen al instante en DriverUI. Esto facilita los ciclos de pruebas rápidas y de iteración de diseño más veloces.
Ejecuta el siguiente comando para establecer el token de Figma para DriverUI:
adb shell am startservice \
-n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
-a setApiKey \
-e ApiKey $FIGMA_ACCESS_TOKEN \
--user 0
Sincronización del documento de diseño de VM doble
En una configuración de VM doble, las actualizaciones de diseño deben propagarse a través de los límites para mantener la coherencia.
- DriverUI recupera el documento de diseño de Figma más reciente y lo transmite al HAR a través de los canales de comunicación de gRPC que se detallan en esta página.
- Como resultado, el clúster completo se actualiza con las iteraciones de diseño de Figma más recientes, lo que mantiene ambas VMs sincronizadas con la fuente de diseño.
Figura 6: Actualización en tiempo real del documento de diseño de Figma a DriverUI y HAR.
Protege el canal de gRPC
gRPC tiene integración de SSL y TLS, y promueve el uso de SSL y TLS para autenticar el servidor y encriptar todos los datos intercambiados entre el cliente y el servidor. Los clientes tienen a su disposición mecanismos opcionales para proporcionar certificados para la autenticación mutua. Para obtener más información sobre la autenticación de gRPC, consulta Autenticación.