DriverUI

A interface do cluster era tradicionalmente colocada atrás do volante em uma tela separada. Os OEMs combinam gradualmente o cluster e o IVI em uma única tela. Essa interface combinada é a DriverUI.

DriverUI

Figura 1. DriverUI.

A DriverUI é um app do sistema Android que renderiza uma tela de cluster de instrumentos inteira, excluindo 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 Automotive Design for 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 ClusterHomeManager classe, também conhecida como Cluster2, para criar clusters de instrumentos. Essa classe especifica a configuração necessária para identificar uma implementação de cluster de instrumentos e como o AAOS interage com ela. O Google oferece implementações de referência das APIs Cluster2.

Plataformas

É possível criar e executar o Display Safety no SDV. A plataforma de veículos definidos por software (SDV, na sigla em inglês):

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

Arquitetura da plataforma 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 imagem para a DriverUI.

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

Composição de HAR e DriverUI

Figura 3. Composição do HAR e da DriverUI.

Comunicação da DriverUI e do HAR

A DriverUI e o HAR se comunicam usando chamadas de procedimento remoto (RPCs, na sigla em inglês). A mensagem de pulsação é 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 fonte do Display Safety 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 IVI envia comunicação para a mídia 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

Comunicação RPC para mudar o tema da DriverUI e do HAR.

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

Por meio da comunicação com o IVI, a DriverUI pode mostrar informações de mídia, mapas e telefonia no cluster de referência. Embora a mídia sirva como 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. Mapas
  2. Telefonia
  3. Mídia

O sistema prioriza automaticamente a navegação do Maps ou os 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:

DriverUI mostrando a seção "Mídia e telefonia" em cluster completo.

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

Integração do Automotive Design for 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 design e 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 do codebase. Para acessar e modificar esses designs:

  1. Inicie a DriverUI com o arquivo de design DCF do Automotive Design for Compose local 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 conferir os designs de origem ou fazer mudanças.

Versão do Automotive Design for Compose

  • O Gradle usa a versão do Automotive Design for 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 teste rápido 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 se propagar pelas fronteiras para manter a consistência.

  • A DriverUI busca o documento de design mais recente do Figma e 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 origem do design.

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

Figura 6. Atualização em tempo real do documento de design do Figma para a 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. Mecanismos opcionais estão disponíveis para que os clientes forneçam certificados para autenticação mútua. Para mais informações sobre a autenticação gRPC, consulte Autenticação.