DriverUI

A interface do cluster geralmente fica atrás do volante em uma tela separada. Os OEMs estão combinando gradualmente o cluster e o IVI em uma única tela. Essa interface combinada é a DriverUI.

Figura 1. DriverUI.

O DriverUI é um app do sistema Android que renderiza uma tela inteira do painel de instrumentos, exceto os elementos regulatórios ou relevantes para a segurança renderizados pelo renderizador de alta disponibilidade (HAR, na sigla em inglês). A DriverUI mostra informações relacionadas à reprodução de mídia, chamadas telefônicas, mapas, navegação e muito mais, além de implementar o Design automotivo para o Compose.

DriverUI como a atividade de cluster padrão

A DriverUI é executada como um app de cluster privilegiado no Android, e o AAOS a inicia automaticamente.

O AAOS usa a classe ClusterHomeManager, também conhecida como Cluster2, para criar painéis de instrumentos. Essa classe especifica a configuração necessária para identificar uma implementação de painel de instrumentos e como o AAOS interage com ela. O Google fornece implementações de referência das APIs do Cluster2.

Plataformas

É possível criar e executar a Segurança da Tela no SDV. A plataforma de veículo definido por software (SDV, na sigla em inglês):

• Requer duas VMs convidadas.
• Executa o HAR no SDV Media (também conhecido como VM de inicialização rápida) em uma VM convidada.
• Executa a DriverUI em outra VM de IVI de SDV convidada.
• Executa o Monitor de Segurança na VM de mídia do SDV.

Figura 2. Arquitetura da plataforma SDV.

Combinar a saída do HAR e da DriverUI

O HAR e a DriverUI usam telas separadas para renderizar a interface. As duas saídas são compostas e aparecem como uma única imagem para o DriverUI.

Para isso, o HAR controla a transparência das áreas em que a saída do Android aparece com base nas mensagens de heartbeat da DriverUI. Quando a DriverUI não está disponível, o HAR detecta a falta de heartbeats, renderiza as áreas da DriverUI como opacas e mostra marcadores de posição. Quando os heartbeats são recebidos, os marcadores de posição são removidos e as áreas da DriverUI são definidas como transparentes.

Figura 3. Composição de HAR e DriverUI.

Resolver problemas de composição alfa e perfuração

Como o HAR é essencial para a segurança, o plano de exibição de hardware dele fica acima do plano de exibição do IVI do Android. Ao criar ou depurar visualizações personalizadas ou superfícies externas do OpenGL ES no HAR, verifique como os valores Alfa são definidos:

• Saída do DriverUI ausente no plano do HAR:embora o HAR receba mensagens HeartbeatRequest válidas do DriverUI, ele precisa limpar a região da janela de visualização do DriverUI para transparente (alpha = 0.0) para que a interface do cluster do Android subjacente seja mostrada. Se uma camada ou plano de fundo personalizado do HAR desenhar pixels opacos (alpha = 1.0) sobre a área da DriverUI, a saída do Android abaixo será bloqueada.
• Furos transparentes não intencionais em superfícies 3D ou OpenGL personalizadas:ao renderizar uma superfície OpenGL ES ou 3D externa em um nó HAR (como um medidor ou cena 3D personalizado que grava pixels RGB com um byte Alfa não utilizado deixado em 0x00), defina explicitamente o canal Alfa de pixels opacos como 0xFF (alpha = 1.0). Deixar o byte Alfa em 0x00 faz com que o compositor trate esses pixels como transparentes (alpha = 0.0) e faça um furo direto na camada HAR para o plano IVI do Android.
• Diagnóstico de exibição entre VMs:como o HAR (sdv_media_har_cf) e o Android IVI (sdv_ivi_cf_ds) são executados em VMs convidadas separadas, a execução de adb shell dumpsys SurfaceFlinger na VM do Android IVI inspeciona apenas as camadas do Android e não tem visibilidade do plano HAR sobreposto.

Comunicação entre DriverUI e HAR

A DriverUI e o HAR se comunicam usando chamadas de procedimento remoto (RPCs). A mensagem de heartbeat é um exemplo de dados enviados pelo canal RPC e consiste em um carimbo de data/hora como um dos campos.

O gRPC é usado para RPCs. No SDV, as comunicações do SDV fornecem o cliente do gateway do SDV para descobrir e estabelecer um canal da DriverUI para o HAR. O serviço gRPC define um arquivo de buffer 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) {}

Os detalhes da solicitação e da resposta estão na origem da segurança da tela em packages/apps/Car/DriverUI/proto/driverui.proto no repositório de código-fonte ub-automotive.

Na plataforma SDV, as comunicações do SDV fornecem o cliente do gateway do SDV para descobrir e estabelecer um canal gRPC da DriverUI para o HAR.

A execução desses comandos usando o terminal do IVI envia uma comunicação para a mídia do SDV, acionando atualizações de tema em todo o 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. Comunicação RPC para mudar o tema da DriverUI e do HAR.

Mostrar informações de mídia, mapas e telefonia no cluster

Ao se comunicar com o IVI, a DriverUI pode mostrar informações de mídia, mapas e telefonia no cluster de referência. Embora a mídia seja o estado padrão na implementação de referência, a tela é atualizada com base nos serviços ativos de acordo com a seguinte prioridade:

1. Maps
2. Telefonia
3. Mídia

O sistema prioriza automaticamente a exibição da navegação do Maps ou dos serviços de telefonia ativos em relação ao estado de mídia padrão.

Os vários estados de exibição da DriverUI são ilustrados na figura a seguir:

Figura 5. DriverUI mostrando a seção de mídia e telefonia no cluster completo.

Integração do Automotive Design para Compose

A DriverUI implementa o Automotive Design for Compose para permitir que os designs (Figma) sejam mostrados e iterados diretamente no app Android. Essa integração preenche a lacuna entre o design e o desenvolvimento, permitindo a renderização de documentos de design no ambiente de execução.

Acessar recursos de design

Os documentos de exemplo do Figma para a DriverUI fazem parte da base de código. Para acessar e modificar esses designs:

1. Inicie o DriverUI com o arquivo de design DCF local do Automotive Design for Compose em packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
2. Localize o arquivo de recurso packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
3. Importe esse arquivo para o Figma para ver os designs de origem ou fazer mudanças.

Versão do Automotive Design para Compose

• O Gradle usa a versão do Automotive Design para Compose especificada para designcompose em packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
• As versões do Automotive Design for Compose estão disponíveis na página de versões.

Configuração de atualização em tempo real

O Automotive Design for Compose oferece suporte a atualizações em tempo real no modo de desenvolvimento, permitindo que as mudanças feitas no Figma sejam renderizadas instantaneamente na DriverUI. Isso facilita os ciclos de testes rápidos e iteração de design mais rápida.

Execute o comando a seguir para definir o token do Figma para a DriverUI:

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

Sincronização de documentos de design de VM dupla

Em uma configuração de VM dupla, as atualizações de design precisam ser propagadas entre os limites para manter a consistência.

• O DriverUI busca o documento de design mais recente do Figma e o transmite para o HAR usando os canais de comunicação gRPC detalhados nesta página.
• Como resultado, o cluster completo é atualizado com as iterações de design mais recentes do Figma, mantendo as duas VMs sincronizadas com a fonte de design.

Figura 6. Atualização em tempo real do documento de design do Figma para o DriverUI e o HAR.

Proteger o canal gRPC

O gRPC tem integração com SSL e TLS e promove o uso de SSL e TLS para autenticar o servidor e criptografar todos os dados trocados entre o cliente e o servidor. Há mecanismos opcionais disponíveis para que os clientes forneçam certificados para autenticação mútua. Para mais informações sobre a autenticação do gRPC, consulte Autenticação.