Configurar acesso remoto

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 Garage durante a noite e 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 amostra para registro de clientes e entrega de tarefas.

• Gravar um cliente de tarefa remota. Use o acesso remoto e aprenda a criar um cliente de tarefas remotas.

• 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 lidar com a redefinição para a configuração original 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 que a arquitetura de exemplo a seguir seja usada, o que é hipotético 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. Arquitetura de amostra.

A arquitetura de amostra consiste nestes componentes de hardware:

A arquitetura de amostra consiste nos seguintes componentes de software, todos executados no Android:

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

Fluxo de trabalho

Nesta seção, listamos as etapas em um fluxo de trabalho de amostra.

Fluxo de trabalho de amostra

Um fluxo de trabalho detalhado pode ser semelhante a este:

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

2. O parceiro procura atualizar o veículo durante a noite quando não é provável que haja interações com o veículo.

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

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, 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 a um usuário específico ao cliente de tarefas remotas 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 serviço do carro recebe informações do veículo do 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 a ele pela Car Service. Ele é 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, essa etapa pode envolver uma autenticação de dois fatores adicional do usuário.

   O servidor de tarefas remotas 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 meio do atestado do veículo.

A menos que uma redefinição para a configuração original ocorra, o processo de registro do cliente é necessário uma vez por usuário e por veículo. O ID do cliente é armazenado localmente no Car Service 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 vehicle, os usuários podem abrir o app cliente de tarefa remota 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 remotas 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 ao 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 usará o processador do veículo (VP) para ativar o AP.

3. O Car Service recebe tarefas do TCU.

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

5. O cliente de tarefas remotas recebe e executa a tarefa.

   (Opcional) O cliente da tarefa remota entra em contato com o servidor para saber mais detalhes e executa a tarefa.

6. (Opcional) O serviço de cliente de tarefas remotas informa o resultado da tarefa ao 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. Entregar tarefas.

Gravar um cliente de tarefa remota

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

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

O serviço de carro gerencia o próprio ciclo de vida. O serviço de carro é vinculado a esse serviço durante a inicialização e quando uma tarefa remota chega. O Car Service é 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 da tarefa remota é executado como o usuário do sistema. Portanto, ele não tem acesso a nenhum dado específico do usuário.

O exemplo abaixo 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 uma RRO como esta:

// 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 comunicação entre o AAOS e outra ECU (por exemplo, um TCU). Ele é 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:

A interface de callback é definida em IRemoteTaskCallback.aid.

Consulte a implementação de referência com uma TCU externa. A implementação usa um stream 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 oferecer suporte a estas propriedades:

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

Modo silencioso

O recurso de acesso remoto precisa oferecer suporte ao modo silencioso para que o veículo possa inicializar nesse modo para 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 ao Android SoC 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 AAOS atualiza /sys/kernel/silent_boot/pm_silentmode_kernel_state, que representa 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 desativados.

Componentes não do Android no veículo

Processador de veículos

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

Componentes no veículo que não são Android

O 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 o 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 último tempo on-line para o servidor de tarefas remotas.

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

Servidor de tarefas remotas

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 remota ao servidor de ativação para o TCU do veículo e, por fim, para o cliente de tarefa remota 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

Redefinir para a configuração original e transferência de propriedade

Se um usuário redefinir para a configuração original, o ID do cliente armazenado no Car Service será apagado. No entanto, os servidores (servidor de tarefas remotas 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 no 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 gerado novamente. 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 HAL de acesso remoto de referência default para testar clientes de tarefas remotas. Use o comando debug abaixo para injetar uma tarefa remota falsa no HAL, que será encaminhada ao cliente de tarefas remotas se você fornecer o ID de cliente correto. É possível conseguir o ID do cliente registrando as informações de registro na implementação do cliente da tarefa remota.

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