DriverUI

Tradicionalmente, la IU del clúster se coloca detrás del volante en una pantalla independiente. 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 una pantalla completa del panel de instrumentos, excepto los elementos regulatorios o relevantes para la seguridad que renderiza el renderizador de alta disponibilidad (HAR). La 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, además, implementa el diseño de Automotive para Compose.

DriverUI como la actividad predeterminada del clúster

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 el AAOS interactúa con ella. Google proporciona implementaciones de referencia de las APIs de Cluster2.

Plataformas

Puedes compilar y ejecutar Display Safety en SDV. La plataforma de vehículos definidos por software (SDV):

• Requiere dos VMs invitadas.
• Ejecuta HAR en SDV Media (también conocida como la VM de inicio rápido) en una VM de invitado.
• Ejecuta DriverUI en otra VM de IVI de SDV invitada.
• Ejecuta el monitor de seguridad en la VM de contenido multimedia de SDV.

Figura 2: Arquitectura de la plataforma de SDV.

Combina el resultado de HAR y DriverUI

El HAR y la DriverUI usan pantallas independientes para renderizar su IU. Las dos salidas son compuestas y aparecen como una sola imagen en la IU del conductor.

Para lograrlo, el HAR controla la transparencia de las áreas en las que aparece el resultado de Android según los mensajes de latido de la DriverUI. Cuando DriverUI no está disponible, HAR detecta la falta de latidos, renderiza las áreas de DriverUI como opacas y muestra marcadores de posición. Cuando se reciben los latidos, se quitan los marcadores de posición y las áreas de DriverUI se configuran para que sean transparentes.

Figura 3: Composición de HAR y DriverUI

Soluciona problemas de composición alfa y perforación

Debido a que la HAR es fundamental para la seguridad, su plano de visualización de hardware se encuentra sobre el plano de visualización del IVI de Android. Cuando compiles o depures vistas personalizadas o superficies externas de OpenGL ES en el HAR, verifica cómo se establecen los valores alfa:

• Falta el resultado de DriverUI en el plano de HAR: Si bien el HAR recibe mensajes HeartbeatRequest válidos de DriverUI, el HAR debe borrar la región del viewport de DriverUI para que sea transparente (alpha = 0.0) de modo que se muestre la IU del clúster de Android subyacente. Si una capa o un fondo de HAR personalizados dibujan píxeles opacos (alpha = 1.0) sobre el área de DriverUI, se bloquea el resultado de Android que se encuentra debajo.
• Agujeros transparentes no deseados en superficies personalizadas de 3D o de OpenGL: Cuando renderizas una superficie externa de OpenGL ES o 3D en un nodo de HAR (como un indicador o una escena personalizados de 3D que escriben píxeles RGB con un byte alfa sin usar que se deja en 0x00), establece de forma explícita el canal alfa de los píxeles opacos en 0xFF (alpha = 1.0). Si dejas el byte alfa en 0x00, el compositor tratará esos píxeles como transparentes (alpha = 0.0) y creará un agujero directo a través de la capa de HAR hasta el plano de IVI de Android subyacente.
• Diagnóstico de visualización entre VMs: Debido a que el HAR (sdv_media_har_cf) y el IVI de Android (sdv_ivi_cf_ds) se ejecutan en VMs de invitado independientes, la ejecución de adb shell dumpsys SurfaceFlinger en la VM de IVI de Android solo inspecciona las capas de Android y no tiene visibilidad del plano de HAR superpuesto.

Comunicación entre DriverUI y HAR

La DriverUI y el HAR se comunican entre sí con 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 puerta de enlace de SDV para descubrir y establecer un canal desde la DriverUI hasta el 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 de 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 de gRPC desde la DriverUI hasta la HAR.

Cuando se ejecutan estos comandos con la terminal de IVI, se envía una 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

Muestra información de contenido multimedia, mapas y telefonía en el clúster

A través de la comunicación con el IVI, la DriverUI puede mostrar información de contenido multimedia, mapas y telefonía dentro del clúster de referencia. Aunque el estado predeterminado en la implementación de referencia es Media, la pantalla se actualiza según los servicios activos de acuerdo con la siguiente prioridad:

1. Maps
2. Telefonía
3. Medios

El sistema prioriza automáticamente la navegación de Maps o los servicios de telefonía activos por sobre el estado de contenido multimedia predeterminado.

En la siguiente figura, se ilustran los distintos estados de visualización de DriverUI:

Figura 5: DriverUI que muestra la sección de contenido multimedia y telefonía en el clúster completo.

Diseño de Automotive para la integración de Compose

DriverUI implementa el diseño de Automotive para Compose para permitir que los diseños (Figma) se muestren y se iteren directamente en la app para Android. Esta integración cierra 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 muestra para DriverUI forman parte de la base de código. Para acceder a estos diseños y modificarlos, sigue estos pasos:

1. Inicia DriverUI con el archivo de diseño DCF local de Automotive Design for Compose desde packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
2. Ubica el archivo de recurso packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
3. Importa este archivo a Figma para ver los diseños de origen o realizar cambios.

Versión de Automotive Design for Compose

• Gradle usa la versión de Automotive Design for Compose especificada para designcompose en packages/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 las actualizaciones en tiempo real

Automotive Design for Compose admite actualizaciones en tiempo real en el modo de desarrollo, lo que permite que los cambios realizados en Figma se rendericen de forma instantánea en DriverUI. Esto facilita los ciclos de pruebas rápidas y de iteración de diseño más rápida.

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 de documentos de diseño de VM doble

En una configuración de VM doble, las actualizaciones de diseño deben propagarse entre los límites para mantener la coherencia.

• DriverUI recupera el documento de diseño de Figma más reciente y lo transmite a la HAR con los canales de comunicación de gRPC que se detallan en esta página.
• Como resultado, todo el clúster 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. Hay mecanismos opcionales disponibles para que los clientes proporcionen certificados para la autenticación mutua. Para obtener más información sobre la autenticación de gRPC, consulta Autenticación.