O Android 14 apresenta o novo recurso de acesso remoto, que permite que os parceiros despertem remotamente o Android em um veículo para executar tarefas específicas. Por exemplo, para executar o modo garagem durante a noite para aplicar atualizações de software. Vários componentes que não são do Android são necessários para o fluxo de trabalho de ponta a ponta. O Android não define nem fornece implementação para componentes que não são do Android (essa responsabilidade é sua).
Para saber mais, consulte as seguintes seções:
Fluxo de trabalho. Fluxo de trabalho entre vários componentes na arquitetura de exemplo para registro de clientes e entrega de tarefas.
Programar um cliente de tarefas remoto. Use o acesso remoto e aprenda a escrever um cliente de tarefas remoto.
Implementação do fornecedor. Componentes do fornecedor na arquitetura de exemplo para oferecer suporte ao acesso remoto.
Redefinição para a configuração original e transferência de propriedade. Saiba como fazer a redefinição de fábrica e a transferência de propriedade do veículo.
Teste o cliente de acesso remoto. Saiba como testar o recurso de acesso remoto.
Arquitetura
O conteúdo a seguir pressupõe o uso da arquitetura de amostra a seguir, que é hipotética e pode não refletir a arquitetura real. Os OEMs precisam adaptar uma implementação real às arquiteturas de veículos e servidores.
Figura 1. Exemplo de arquitetura.
A arquitetura de amostra consiste nestes componentes de hardware:
| Componente de hardware | Descrição |
|---|---|
| Processador de apps | Processador que executa o Android. O Android pode ser executado na memória virtual (VM, na sigla em inglês) (não no hardware real) nesse processador. |
| Processador de veículo | Processador responsável por controlar a energia do processador do app. |
| Unidade de controle de telemática (TCU) | O processador no veículo sempre pode receber mensagens remotas da nuvem. Presume-se que o TCU esteja sempre ativado ou no modo de baixo consumo de energia. Use mensagens remotas para ativar o TCU. |
| Servidor de ativação | Um servidor remoto que é executado na nuvem e é responsável por se comunicar com a TCU no veículo para emitir comandos de ativação. |
| Servidor de tarefas remoto | O servidor de tarefas remotas é executado na nuvem, interage com as pessoas e gerencia tarefas remotas. |
A arquitetura de amostra consiste nos seguintes componentes de software, todos executados no Android:
| Componente de software no Android | Descrição |
|---|---|
| Serviço de carro | Serviço de framework AAOS que fornece APIs de acesso remoto. |
| Cliente de tarefas remotas | Uma classe
Service
criada pelo fornecedor que executa tarefas remotas. Um sistema Android pode executar vários
clientes de tarefas remotas. |
| HAL de acesso remoto | É necessário implementar para o acesso remoto. Camada de abstração para comunicação entre o AAOS e um componente que não é do Android, como o TCU. |
Os componentes de software que não são do Android são descritos abaixo:
| Componente de software que não é do Android | Descrição |
|---|---|
| Cliente de ativação | Software em execução no TCU que mantém uma conexão de longa duração com o servidor de ativação. Ele também mantém uma conexão com o HAL de acesso remoto para entregar tarefas remotas ao serviço do carro. |
| Implementação da ativação do servidor | Servidor que se comunica com o cliente de ativação em execução no TCU. Pode enviar solicitações de ativação para o cliente de ativação. |
| Implementação do servidor de tarefas remotas | Servidor que gerencia tarefas remotas. Os usuários interagem com esse servidor para emitir e monitorar tarefas remotas. |
Fluxo de trabalho
Esta seção lista as etapas de um fluxo de trabalho de exemplo.
Exemplo de fluxo de trabalho
Um fluxo de trabalho detalhado pode ser semelhante a este:
O usuário estaciona o veículo na garagem.
O parceiro busca atualizar o veículo durante a noite, quando as interações com ele são improváveis.
O servidor de nuvem do parceiro envia uma tarefa remota de atualização do sistema para o veículo. Especificamente, a unidade de controle de telemática (TCU).
A TCU do veículo ativa a unidade de controle eletrônico (ECU, na sigla em inglês) do Android e um serviço OEM aciona o modo Garagem.
O Android executa o modo Garagem para fazer o download e instalar atualizações pelo Google Play.
Depois de aplicar a atualização, o Android marca a tarefa como concluída e encerra a conexão ou atinge um tempo limite especificado.
Fluxo de trabalho detalhado
Há duas etapas importantes necessárias para o acesso remoto. A primeira é registrar o cliente, que é vincular um usuário específico a um cliente de tarefa remota específico em execução em um veículo específico. O outro é entregar uma tarefa, que é entregar a tarefa remota de um usuário específico ao cliente de tarefa remota específico em execução no veículo específico.
Registrar um cliente
Para usar o recurso de acesso remoto, o usuário precisa abrir o app cliente de tarefas remotas pelo menos uma vez e concluir o processo de registro do cliente. O texto em negrito indica tarefas implementadas pelo AAOS:
Na inicialização, o Car Service recebe informações do veículo da HAL de acesso remoto.
Na inicialização, o Car Service inicia todos os clientes de tarefas remotas com base no intent-filter e na permissão.
Ao iniciar, o cliente de tarefa remoto se registra no serviço de carro.
O serviço de carro notifica o cliente de tarefa remota sobre as informações de registro, incluindo o ID do veículo e do cliente. O ID do cliente é exclusivo e atribuído pelo serviço de carro a esse cliente. Ele é garantido como exclusivo entre todos os clientes de tarefas remotas no mesmo veículo.
O usuário faz login no servidor de tarefas remotas pelo cliente de tarefas remotas e ativa o recurso de acesso remoto para esse veículo. Essa etapa normalmente envolve a autenticação pelo servidor de tarefas remoto.
O cliente de tarefas remotas faz o upload das informações do usuário, junto com o ID do veículo e do cliente, para o servidor de tarefas remotas e solicita que ele vincule o usuário a esse cliente e veículo específico.
Opcionalmente, esta etapa pode envolver autenticação de dois fatores adicional do usuário.
O servidor de tarefas remoto precisa autenticar que o ID do veículo fornecido na solicitação corresponde ao ID do veículo do remetente, o que pode ser feito por atestado de veículo.
A menos que uma redefinição para a configuração original seja feita, o processo de registro do cliente é necessário uma vez por usuário e por veículo. O ID do cliente é armazenado localmente no serviço de carro e permanece o mesmo para o mesmo cliente.
Figura 2. Registrar um cliente
Cancelar o registro de um cliente
Um usuário pode desvincular o veículo da conta no veículo ou no servidor de tarefas remoto:
No veículo, os usuários podem abrir o app cliente de tarefas remotas e emitir uma solicitação de desvinculação para desvincular o veículo das contas de usuário vinculadas anteriormente.
No servidor de tarefas remoto, os usuários podem fazer login na conta e desvincular um veículo vinculado anteriormente.
Se o usuário desvincular o veículo da conta, o servidor de tarefas remoto precisará remover o mapeamento armazenado para esse usuário específico.
Concluir tarefas
Na nuvem:
Um usuário usa o servidor de tarefas remotas para enviar uma tarefa remota a um veículo específico.
O servidor de tarefas remoto mapeia o ID do usuário para o ID do veículo e do cliente. Ele envia os dados da tarefa, o ID do veículo e o ID do cliente para o servidor de ativação.
O servidor de ativação encontra o TCU específico do ID do veículo (supondo que o registro do TCU já tenha sido feito) e envia os dados da tarefa e o ID do cliente para o TCU.
No veículo (o texto em negrito indica tarefas realizadas pelo AAOS):
O TCU recebe tarefas remotas do servidor remoto.
Se o processador do app (AP) que executa o AAOS estiver desativado, o TCU vai usar o processador do veículo (VP) para ativar o AP.
O serviço de carro recebe tarefas do TCU.
O Car Service distribui tarefas para o cliente de tarefa remota correspondente.
O cliente da tarefa remota recebe e executa a tarefa.
(Opcional) O cliente de tarefa remoto entra em contato com o servidor de tarefas para mais detalhes e executa a tarefa.
(Opcional) O serviço de cliente de tarefa remota informa o resultado da tarefa para o servidor de tarefas.
O cliente de tarefas remotas notifica o serviço de carro quando a tarefa é concluída.
Se necessário, o serviço de carro restaura o estado de energia do veículo.
Figura 3. Concluir tarefas.
Criar um cliente de tarefas remoto
CarRemoteAccessManager fornece a API para recursos de acesso remoto. Para saber
mais, consulte
CarRemoteAccessManager.
Um cliente de tarefas remotas é um serviço do Android que executa tarefas remotas e usa
CarRemoteAccessManager. Isso requer PERMISSION_USE_REMOTE_ACCESS e
PERMISSION_CONTROL_REMOTE_ACCESS e precisa declarar um filtro de intent para
RemoteTaskClientService, como:
<service android:name=".remoteaccess.RemoteTaskClientService"
android:directBootAware="true"
android:exported="true">
<intent-filter>
<action android:name="android.car.remoteaccess.RemoteTaskClientService" />
</intent-filter>
</service>
Um cliente de tarefa remota precisa se registrar no serviço de carro durante a criação:
public final class RemoteTaskClientService extends Service {
@Override
public void onCreate() {
// mCar = Car.createCar()...
mRemoteAccessManager = (CarRemoteAccessManager)
mcar.getCarManager(Car.CAR_REMOTE_ACCESS_SERVICE);
if (mRemoteAccessManager == null) {
// Remote access feature is not supported.
return;
}
mRemoteAccessManager.setRemoteTaskClient(executor, mRemoteTaskClient);
}
}
Ele precisa substituir a função onBind para retornar um valor nulo.
@Override
public IBinder onBind(Intent intent) {
return null;
}
O Car Service gerencia o ciclo de vida. O serviço de carro é vinculado a esse serviço durante a inicialização e quando uma tarefa remota chega. O serviço do carro é desvinculado desse serviço quando a tarefa é concluída. Para saber mais, consulte Como gerenciar o ciclo de vida de um serviço.
O cliente de tarefas remoto é executado como o usuário do sistema para não ter acesso a nenhum dado específico do usuário.
O exemplo a seguir mostra como processar os callbacks registrados:
private final class RemoteTaskClient
implements CarRemoteAccessManager.RemoteTaskClientCallback {
@Override
public void onRegistrationUpdated(
RemoteTaskClientRegistrationInfo info) {
// Register to remote task server using info.
}
@Override
public void onRemoteTaskRequested(String taskId,
byte[] data, int remainingTimeSec) {
// Parses the data and execute the task.
// Report task result to remote task server.
mRemoteAccessManager.reportRemoteTaskDone(taskId);
}
@Override
public void onShutdownStarting(CompleteableRemoteTaskFuture future) {
// Stop the executing task.
// Clear the pending task queue.
future.complete();
}
}
Implementação do fornecedor
O recurso de acesso remoto é opcional e fica desativado por padrão. Para ativar o recurso, adicione um RRO, como este:
// res/xml/overlays.xml
<?xml version="1.0" encoding="utf-8"?>
<overlay>
<item target="array/config_allowed_optional_car_features" value="@array/config_allowed_optional_car_features" />
</overlay>
// res/values/config.xml
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<string-array translatable="false" name="config_allowed_optional_car_features">
<item>car_remote_access_service</item>
</string-array>
</resources>
// Android.bp
runtime_resource_overlay {
name: "RemoteAccessOverlay",
resource_dirs: ["res"],
manifest: "AndroidManifest.xml",
sdk_version: "current",
product_specific: true
}
Ou use o seguinte comando adb em um build userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Requisitos no Android
HAL de acesso remoto
A camada de abstração de hardware de acesso remoto (HAL) é uma camada de abstração implementada pelo fornecedor para a comunicação entre o AAOS e outra ECU (por exemplo, uma TCU). É obrigatório para oferecer suporte ao recurso de acesso remoto. Ele não precisa ser implementado se o recurso de acesso remoto não for implementado.
A interface é definida em IRemoteAccess.aidl e inclui estes métodos:
| Classe | Descrição |
|---|---|
String getVehicleId() |
Recebe um ID do veículo exclusivo que pode ser reconhecido pelo servidor de ativação. |
String getWakeupServiceName() |
Recebe o nome do servidor de ativação remota. |
String getProcessorId() |
Recebe um ID de processador exclusivo que pode ser reconhecido ao ativar o cliente. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Define um callback a ser chamado quando uma tarefa remota é solicitada. |
|
void clearRemoteTaskCallback() |
Limpa um callback de tarefa remota definido anteriormente. |
void notifyApStateChange(in ApState state)
Detecta se o processador do app está pronto para receber tarefas remotas. | |
A interface de callback é definida em IRemoteTaskCallback.aid.
| Classe | Descrição |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Um callback que é chamado quando uma tarefa remota é solicitada. |
|
Consulte a
implementação de referência
com uma TCU externa. A implementação usa um fluxo de leitura de longa duração para
receber tarefas remotas e oferece suporte ao seguinte comando debug:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
HAL veicular
Para oferecer suporte ao recurso de acesso remoto, a VHAL precisa oferecer suporte a estas propriedades:
| Classe | Descrição |
|---|---|
SHUTDOWN_REQUEST |
Solicita que a unidade principal seja desligada. |
VEHICLE_IN_USE |
|
Para saber mais, consulte Propriedades do sistema com suporte.
Modo silencioso
O modo silencioso precisa ter suporte ao recurso de acesso remoto para que o veículo possa inicializar no modo silencioso e executar tarefas remotas quando nenhum usuário estiver presente. Com o modo silencioso, o dispositivo AAOS é inicializado com a tela e o áudio desativados.
O modo silencioso é controlado por dois arquivos sysfs do kernel do Linux.
| Classe | Descrição |
|---|---|
/sys/kernel/silent_boot/pm_silentmode_kernel_state
Representa o modo silencioso atual. |
|
/sys/kernel/silent_boot/pm_silentmode_hw_state
Representa o sinal de hardware para definir um novo modo silencioso. |
|
O processador do veículo envia um sinal de HW para o SoC do Android para ativar/desativar o modo
silencioso. O sinal (0 ou 1) é gravado em
/sys/kernel/silent_boot/pm_silentmode_hw_state. Em seguida, o framework do AAOS atualiza
/sys/kernel/silent_boot/pm_silentmode_kernel_state de acordo, o que
representa o modo silencioso atual. Os módulos AAOS verificam
/sys/kernel/silent_boot/pm_silentmode_kernel_state para saber se o sistema
está no modo silencioso.
Quando uma tarefa remota é recebida e o AAOS é inicializado, o processador do veículo define o modo silencioso e inicia o AAOS para que o sistema seja inicializado com a tela/o áudio desligado.
Componentes não do Android no veículo
Processador de veículo
O processador do veículo é um processador no veículo que pode controlar a energia do processador do app que executa o Android. No exemplo de arquitetura, a TCU ativa o processador do app enviando um sinal para o processador do veículo.
Componentes não do Android no veículo
A TCU do veículo sempre pode receber mensagens remotas.
O cliente de ativação é executado no TCU para garantir uma conexão de longa duração com o servidor de ativação remota.
O AAOS em execução no AP pode se comunicar com o cliente de ativação executado no TCU pela HAL de acesso remoto.
Figura 4. TCU (cliente de ativação).
Componentes na nuvem
Servidor de ativação
O servidor de ativação se comunica com o cliente de ativação no TCU para:
- Mantenha uma conexão de longa duração com a TCU do veículo.
- Encontre uma TCU específica com base no ID do veículo.
- Informar o status de um veículo. Por exemplo, on-line ou off-line ou o último tempo on-line para o servidor de tarefas remoto.
Em uma implementação real, um servidor de ativação pode ser mesclado com um servidor de tarefas remotas.
Servidor de tarefas remoto
O servidor de tarefas remoto gerencia essas tarefas.
O usuário interage com o servidor para iniciar novas tarefas remotas e monitorar tarefas remotas.
Usa o servidor de ativação remoto para ativar o processador do app nos veículos.
Interage com o cliente de tarefas remoto em execução no veículo.
Armazena informações de registro do cliente. Isso associa um usuário específico a um cliente de tarefa remota específico em um veículo específico.
Normalmente, os dados da tarefa enviados pelo servidor de tarefas remoto para o servidor de ativação, para a TCU do veículo e, eventualmente, para o cliente de tarefas remoto são simplesmente um ID de tarefa. O cliente de tarefas remotas usa o ID da tarefa para buscar as informações detalhadas do servidor de tarefas remotas.
Requisitos de privacidade e segurança
| Tarefa | Condição | Requisito |
|---|---|---|
| TCU (cliente de ativação) | OBRIGATÓRIO |
|
| Servidor de ativação | OBRIGATÓRIO |
|
| Cliente de tarefas remotas | OBRIGATÓRIO |
|
| Servidor de tarefas remoto | OBRIGATÓRIO |
|
Redefinir para a configuração original e transferência de propriedade
Se um usuário fizer uma redefinição de fábrica, o ID do cliente armazenado no serviço do carro será apagado. No entanto, os servidores (servidor de tarefas remoto e servidor de ativação remota) não são informados. Os servidores retêm um mapeamento do ID do cliente expirado para o veículo. Como resultado, se o usuário iniciar uma nova tarefa remota para o veículo, ele usará o ID do cliente expirado. O veículo é ativado, mas a tarefa remota não pode ser executada porque o cliente da tarefa remota tem um ID de cliente diferente que não corresponde.
Veja a seguir uma possível implementação de redefinição para a configuração original.
Quando um usuário faz uma redefinição de fábrica, o fornecedor solicita que ele faça login no servidor de tarefas remoto e desvincule o veículo da conta, caso ele tenha vinculado o veículo anteriormente. Não há garantia de que o dispositivo tenha acesso à rede durante a redefinição para a configuração original. Portanto, emitir a solicitação de desvinculação no horário de redefinição para a configuração original do dispositivo pode não ser viável.
Sempre que a propriedade de um veículo é transferida, algumas operações precisam ser realizadas para garantir que o proprietário anterior não possa mais emitir tarefas remotas para o veículo. Por exemplo, o novo proprietário pode precisar:
Redefina o dispositivo para a configuração original. Isso garante que o ID do cliente seja regenerado. Após essa etapa, o proprietário anterior ainda poderá ativar o veículo, mas não poderá mais executar tarefas remotas.
Abra o app cliente de tarefas remotas e siga o processo de Cancelamento do registro de um cliente para desvincular o veículo da conta do proprietário anterior. O novo proprietário pode seguir o processo de registro de um cliente para vincular o veículo à conta e substituir a conta vinculada anteriormente.
O novo proprietário pode usar o processo Registrar um cliente para vincular o veículo à conta dele e substituir a anterior.
Testar o cliente de tarefas remoto
Fornecemos o diretório de referência da HAL de acesso remoto
default
para testar clientes de tarefas remotas. Use o seguinte comando debug
para injetar uma tarefa remota fictícia na HAL, que será encaminhada ao
cliente de tarefa remota se você fornecer o ID do cliente correto. É possível conferir o ID
do cliente registrando as informações de registro na implementação do cliente
de tarefas remotas.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]