Configurar acesso remoto

Observação: para implementar esse recurso, ative. Para saber mais, consulte Implementação do fornecedor.

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:

1. O usuário estaciona o veículo na garagem.

2. O parceiro busca atualizar o veículo durante a noite, quando as interações com ele são improváveis.

3. 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).

4. 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.

5. O Android executa o modo Garagem para fazer o download e instalar atualizações pelo Google Play.

6. 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:

1. Na inicialização, o Car Service recebe informações do veículo da HAL de acesso remoto.

2. Na inicialização, o Car Service inicia todos os clientes de tarefas remotas com base no intent-filter e na permissão.

3. Ao iniciar, o cliente de tarefa remoto se registra no serviço de carro.

4. 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.

5. 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.

6. 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.

   Observação: um usuário pode ter vários veículos. Um banco de dados de exemplo no servidor de tarefas remoto pode usar [userID, vehicleID] como chave e [client ID] como valor.

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:

1. Um usuário usa o servidor de tarefas remotas para enviar uma tarefa remota a um veículo específico.

2. 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.

3. 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):

1. O TCU recebe tarefas remotas do servidor remoto.

2. 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.

3. O serviço de carro recebe tarefas do TCU.

4. O Car Service distribui tarefas para o cliente de tarefa remota correspondente.

5. 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.

6. (Opcional) O serviço de cliente de tarefa remota informa o resultado da tarefa para o servidor de tarefas.

7. O cliente de tarefas remotas notifica o serviço de carro quando a tarefa é concluída.

8. 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	Detecta se o veículo está em uso. Depois que o usuário destrancar o veículo ou quando ele se aproxima do veículo. Precisa ser true. Uma duração específica após o usuário desligar o veículo ou quando ele tranca o veículo. Precisa ser false. Quando true, o AAOS não tenta desligar o veículo quando a tarefa remota é concluída.

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

Importante: o AAOS não processa, armazena, autentica o usuário nem fornece atestados de dispositivo. Todos os componentes do fornecedor são essenciais para a privacidade e a segurança. Para a arquitetura de exemplo, os fornecedores precisam atender aos seguintes requisitos. Esta lista não está completa.

Tarefa	Condição	Requisito
TCU (cliente de ativação)	OBRIGATÓRIO	Autentique o servidor de ativação. Confie no código.
Servidor de ativação	OBRIGATÓRIO	Permitir que apenas servidores de tarefas remotos na lista de permissões se conectem. Autenticar o cliente de ativação. Envie a mensagem de ativação somente para o veículo de destino.
Cliente de tarefas remotas	OBRIGATÓRIO	Autentique o usuário durante o registro. Autenticar o servidor de tarefas remoto. Atenda a todos os requisitos de segurança de um serviço do Android. Por exemplo, permissões limitadas.
Servidor de tarefas remoto	OBRIGATÓRIO	Precisa autenticar o servidor de ativação. Forneça atestado de veículo. Ou seja, autenticar que o ID do veículo fornecido na solicitação corresponde ao ID do veículo do remetente. Se não for possível fazer a atestação do veículo, será necessário usar outros meios para verificar se o usuário é o proprietário atual do veículo. Autentique a identidade do usuário. Atenda a todos os requisitos de segurança de um servidor que processa informações do usuá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]