Configurar o acesso remoto

O Android 14 apresenta o novo recurso de acesso remoto, que permite aos parceiros ativar remotamente o Android em um veículo para executar tarefas específicas. Por exemplo, para executar o Modo garagem durante a noite e aplicar atualizações de software. Vários componentes não 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 amostra para registro de clientes e entrega de tarefas.

• Escreva um cliente de tarefa remota. Use o acesso remoto e saiba como escrever um cliente de tarefa remota.

• Implementação do fornecedor. Componentes do fornecedor na arquitetura de amostra para oferecer suporte ao acesso remoto.

• Redefinição de fábrica e transferência de propriedade. Saiba como lidar com 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 seguinte arquitetura de exemplo, 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 exemplo consiste nestes componentes de hardware:

A arquitetura de exemplo consiste nestes componentes de software, todos executados no Android:

Os componentes de software que não são Android são descritos abaixo:

Fluxo de trabalho

Esta seção lista as etapas de um exemplo de fluxo de trabalho.

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 tenta atualizar o veículo durante a noite, quando é improvável que haja interações com ele.

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 telemático (TCU, na sigla em inglês).

4. A TCU do veículo ativa a unidade de controle eletrônico (ECU) do Android e um serviço OEM aciona o modo Garage.

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, ou seja, vincular um usuário específico a um cliente de tarefa remota específico em execução em um veículo específico. A outra é entregar uma tarefa, que é entregar a tarefa remota para 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, um 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 filtro de intent e na permissão.

3. Ao iniciar o cliente de tarefas remotas, ele se registra no Car Service.

4. O Car Service notifica o cliente de tarefa remota sobre as informações de registro, incluindo ID do veículo e ID do cliente. O ID do cliente é exclusivo e atribuído pelo serviço de carro a esse cliente. Ele é único 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 o veículo. Essa etapa normalmente envolve a autenticação pelo servidor de tarefas remoto.

6. O cliente de tarefa remota faz upload das informações do usuário com o ID do veículo e o ID do cliente para o servidor de tarefa remota e pede que ele vincule o usuário a esse cliente e veículo específicos.

   Como opção, essa etapa pode envolver uma autenticação de dois fatores adicional do usuário.

   O servidor de tarefas remoto precisa autenticar se o ID do veículo fornecido na solicitação corresponde ao ID do veículo do remetente, o que pode ser feito por atestado do veículo.

A menos que uma redefinição de fábrica seja feita, o processo de registro do cliente é necessário uma vez por usuário por veículo. O ID do cliente é armazenado localmente no Car Service e permanece o mesmo para o mesmo cliente.

Figura 2. Registre um cliente.

Cancelar o registro de um cliente

Um usuário pode desvincular o veículo da conta dele no próprio veículo ou no servidor de tarefas remotas:

• 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 remotas, 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 remotas precisará remover o mapeamento armazenado para o usuário específico.

Entregar 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 a TCU específica para o ID do veículo (supondo que o registro da TCU já tenha sido feito) e envia os dados da tarefa e o ID do cliente para a TCU.

No veículo (o texto em negrito indica tarefas realizadas pelo AAOS):

1. A TCU recebe tarefas remotas do servidor remoto.

2. Se o processador de aplicativos (AP) que executa o AAOS estiver desligado, a TCU usará o processador do veículo (VP) para ativar o AP.

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

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

5. O cliente de tarefa remota recebe e executa a tarefa.

   Opcional: o cliente de tarefa remota 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 ao servidor de tarefas.

7. O cliente de tarefa remota notifica o Car Service quando a tarefa é concluída.

8. Se necessário, o Car Service restaura o estado de energia do veículo.

Figura 3. Entregar tarefas.

Escrever um cliente de tarefa remota

O 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 exige 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 Car Service 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);
    }
}

Ela precisa substituir a função onBind para retornar nulo.

@Override
public IBinder onBind(Intent intent) {
    return null;
}

O Car Service gerencia o próprio ciclo de vida. O Car Service se vincula a esse serviço durante a inicialização e quando uma tarefa remota chega. O Car Service desvincula esse serviço quando a tarefa é concluída. Para saber mais, consulte Como gerenciar o ciclo de vida de um serviço.

O cliente de tarefa remota é executado como o usuário do sistema, portanto, não tem acesso a dados específicos 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 (HAL, na sigla em inglês) de acesso remoto é uma camada de abstração implementada pelo fornecedor para comunicação entre o AAOS e outra ECU (por exemplo, uma TCU). É obrigatório para oferecer suporte ao recurso de acesso remoto. Não é necessário implementar se o recurso de acesso remoto não for implementado.

A interface é definida em IRemoteAccess.aidl e inclui estes métodos:

A interface de callback é definida em IRemoteTaskCallback.aid.

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 é compatível com o seguinte comando debug:

dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default

HAL veicular

Para oferecer suporte ao recurso de acesso remoto, a VHAL precisa ser compatível com estas propriedades:

Para saber mais, consulte Propriedades do sistema compatíveis.

Modo silencioso

O modo silencioso precisa ser compatível com o recurso de acesso remoto para que o veículo possa ser inicializado nesse modo 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.

O processador do veículo envia um sinal de hardware para o SoC do Android para ativar/desativar o modo silencioso. O indicador (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 com o modo silencioso atual. Os módulos do AAOS verificam /sys/kernel/silent_boot/pm_silentmode_kernel_state para saber se o sistema está no modo silencioso ou não.

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/áudio desligados.

Componentes não Android no veículo

Processador de veículos

O processador do veículo é um processador no veículo que pode controlar a energia para o processador de apps que executa o Android. Na arquitetura de exemplo, a TCU ativa o processador de apps enviando um sinal ao processador do veículo.

Componentes não Android no veículo

A TCU do veículo sempre pode receber mensagens remotas.

O cliente de ativação é executado na 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 despertar em execução na TCU pelo HAL de acesso remoto.

Figura 4. TCU (cliente de despertar).

Componentes na nuvem

Servidor de despertar

O servidor de despertar se comunica com o cliente de despertar na TCU para:

• Manter uma conexão de longa duração com a TCU do veículo.
• Encontre uma TCU específica com base no ID de um veículo.
• Informar o status de um veículo. Por exemplo, on-line ou off-line, ou o último horário on-line para o servidor de tarefas remoto.

Em uma implementação real, um servidor de despertar pode ser mesclado com um servidor de tarefas remoto.

Servidor de tarefas remotas

O servidor de tarefas remotas gerencia essas tarefas.

• O usuário interage com o servidor para iniciar e monitorar novas tarefas remotas.

• Usa o servidor de ativação remota para ativar o processador de apps nos veículos.

• Interage com o cliente de tarefas remotas 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 despertar, para a TCU do veículo e, por fim, para o cliente de tarefas remoto são apenas um ID de tarefa. O cliente de tarefa remota usa o ID da tarefa para buscar as informações detalhadas do servidor de tarefas remotas.

Requisitos de privacidade e segurança

Redefinição de fábrica e transferência de propriedade

Se um usuário fizer uma redefinição de fábrica, o ID do cliente armazenado no Car Service será apagado. No entanto, os servidores (servidor de tarefas remoto e servidor de ativação remota) não são informados. Os servidores mantê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, ela vai 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 diferente que não corresponde.

Confira a seguir uma possível implementação para uma redefinição de fábrica.

Quando um usuário faz uma redefinição de fábrica, o fornecedor pede que ele faça login no servidor de tarefas remotas e desvincule o veículo da conta, caso ele tenha feito isso antes. Não há garantia de que o dispositivo terá acesso à rede durante a redefinição de fábrica. Portanto, emitir a solicitação de desvinculação no momento da redefinição de fábrica 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. Depois dessa etapa, o proprietário anterior ainda poderá despertar o veículo, mas não poderá mais executar tarefas remotas.

• Abra o app cliente de tarefas remotas e siga o processo Cancelar o 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 dele 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 conta vinculada anteriormente.

Testar o cliente de tarefas remotas

Fornecemos o diretório HAL de acesso remoto de referência default para testar clientes de tarefas remotas. Use o seguinte comando debug para injetar uma tarefa remota falsa no HAL, que é encaminhada ao seu cliente de tarefa remota se você fornecer o ID de cliente correto. Para conseguir o ID do cliente, registre as informações de registro na implementação do cliente de tarefa remota.

adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]