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 para aplicar atualizações de software. Vários componentes não Android são necessários para o fluxo de trabalho completo. O Android não define nem fornece implementação para componentes não Android (essa responsabilidade pertence a você).

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.

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

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

• Redefinição de fábrica e transferência de propriedade . Aprenda como lidar com a redefinição de fábrica e a transferência de propriedade do veículo.

• Teste o cliente de acesso remoto . Aprenda como testar o recurso de acesso remoto.

Arquitetura

O conteúdo a seguir pressupõe que o exemplo de arquitetura a seguir seja usado, o que é hipotético e pode não refletir a arquitetura real. Os OEMs devem adaptar uma implementação real às suas arquiteturas de veículos e servidores.

Figura 1. Exemplo de arquitetura.

A arquitetura de amostra consiste nestes componentes de hardware :

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

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

Fluxo de trabalho

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

Exemplo de fluxo de trabalho

Um fluxo de trabalho detalhado pode ser semelhante ao seguinte:

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

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

3. O servidor de nuvem parceiro envia uma tarefa remota do sistema de atualização para o veículo. Especificamente, a unidade de controle telemático (TCU).

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

5. O Android executa o modo Garage para baixar e instalar atualizações através do 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

Existem duas etapas importantes necessárias para acesso remoto. A primeira é registrar o cliente, que consiste em vincular um usuário específico a um cliente de tarefa remota específico executado em um veículo específico. A outra é entregar uma tarefa, que consiste em 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.

Cadastre um cliente

Para usar o recurso de acesso remoto, o usuário deve abrir o aplicativo cliente de tarefa remota pelo menos uma vez e concluir o processo de registro do cliente (a etapa em negrito é implementada pela AAOS):

1. Na inicialização, o Car Service obtém informações do veículo a partir do HAL de acesso remoto.

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

3. Após o início do cliente de tarefa remota, o cliente de tarefa remota regista-se no Car Service.

4. O Car Service notifica o cliente de tarefa remota sobre informações de registro, incluindo ID do veículo e ID do cliente. O ID do cliente é único e atribuído pela Car Service a este cliente. É garantido que seja único entre todos os clientes de tarefas remotas no mesmo veículo.

5. O usuário faz login no servidor de tarefas remotas por meio do cliente de tarefas remotas e ativa o recurso de acesso remoto para este veículo. Esta etapa normalmente envolve autenticação por meio do servidor de tarefas remoto.

6. O cliente de tarefa remota carrega as informações do usuário junto com o ID do veículo e o ID do cliente para o servidor de tarefa remoto e solicita que ele vincule o usuário a esse cliente específico e a esse veículo específico.

   Opcionalmente, esta etapa pode envolver autenticação adicional de dois fatores do usuário.

   O servidor de tarefas remoto deve autenticar que o ID do veículo fornecido na solicitação corresponde ao ID do veículo do remetente, o que pode ser feito através do atestado do veículo.

A menos que ocorra uma redefinição de fábrica, 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. Cadastre um cliente.

Cancelar registro de um cliente

Um usuário pode desvincular o veículo de sua conta do veículo ou do servidor de tarefas remoto. No:

• Veículo, os usuários podem abrir o aplicativo cliente de tarefa remota e emitir uma solicitação de desvinculação para desvincular esse veículo de suas contas de usuário vinculadas anteriormente.

• Servidor de tarefas remoto, os usuários podem fazer login em sua conta e desvincular um veículo previamente vinculado desta conta.

Se o usuário desvincular o veículo de sua conta, o servidor de tarefas remoto deverá 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 para um veículo específico.

2. O servidor de tarefas remoto mapeia o ID do usuário para o ID do veículo e o ID do cliente. Ele envia os dados da tarefa, ID do veículo e ID do cliente para o servidor Wake-up.

3. O servidor Wake-up encontra o TCU específico para o ID do veículo. Assumimos que o registro do TCU já foi feito) e enviamos a tarefa Dados e ID do cliente para o TCU.

No veículo (o texto em negrito indica tarefas executadas pela AAOS):

1. TCU recebe tarefas remotas de servidor remoto.

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

3. Car Service recebe tarefas do TCU.

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

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

   ( Opcional ) O cliente de tarefa remota contata o servidor de tarefas para obter mais detalhes da tarefa e executa a tarefa.

6. ( Opcional ) O serviço cliente de tarefa remota relata 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.

Escreva um cliente de tarefa remota

CarRemoteAccessManager fornece a API para recursos de acesso remoto. Para saber mais, consulte CarRemoteAccessManager . Um cliente de tarefa remota é um serviço Android que executa tarefas remotas e usa CarRemoteAccessManager . Isso requer PERMISSION_USE_REMOTE_ACCESS e PERMISSION_CONTROL_REMOTE_ACCESS e deve declarar um filtro de intenção 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 deve registrar-se 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);
    }
}

Deve substituir a função onBind para retornar nulo.

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

A Car Service gerencia seu ciclo de vida. O Car Service vincula-se a este serviço durante a inicialização e quando chega uma tarefa remota. Car Service desvincula-se deste serviço quando a tarefa é concluída. Para saber mais, consulte Gerenciando o ciclo de vida de um serviço .

O cliente de tarefa remota é executado como usuário do sistema, portanto não tem acesso a nenhum dado específico do usuário.

O exemplo a seguir mostra como lidar com os retornos de chamada 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 desabilitado por padrão. Para ativar o recurso, adicione um RRO como o seguinte:

// 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 uma compilação userdebug/eng:

adb shell cmd car_service enable-feature car_remote_access_service

Requisitos no Android

Acesso remoto HAL

A camada de abstração de hardware de acesso remoto (HAL) é uma camada de abstração implementada pelo fornecedor para comunicação entre AAOS e outra ECU (por exemplo, uma TCU). É obrigatório para suportar o recurso de acesso remoto. Não precisa ser implementado se o recurso de acesso remoto não estiver implementado.

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

A interface de retorno de chamada é definida em IRemoteTaskCallback.aid .

Veja a implementação de referência com TCU externo. 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

Veículo HAL

Para suportar o recurso de acesso remoto, o VHAL deve suportar estas propriedades:

Para saber mais, consulte Propriedades de sistema suportadas .

Modo silencioso

O modo silencioso deve ser compatível com o recurso de acesso remoto para que o veículo possa inicializar no modo silencioso para executar tarefas remotas quando nenhum usuário estiver presente. No modo silencioso, o dispositivo AAOS é inicializado com a tela e o áudio desligados.

O modo silencioso é controlado por dois arquivos sysfs do kernel Linux.

O processador do veículo envia um sinal HW para o 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, a estrutura 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 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 inicialize 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 do processador do aplicativo que executa o Android. Na arquitetura de exemplo, o TCU ativa o processador do aplicativo enviando um sinal ao processador do veículo.

Componentes não Android no veículo

O TCU do veículo sempre poderá receber mensagens remotas.

O cliente Wake-up é executado no TCU para garantir uma conexão duradoura com o servidor Wake-up remoto.

O AAOS rodando no AP pode se comunicar com o Wake-up Client rodando no TCU através do HAL de acesso remoto.

Figura 4. TCU (Cliente Wake-up).

Componentes na nuvem

Servidor de despertar

O servidor Wake-up se comunica com o cliente Wake-up na TCU para:

• Mantenha uma conexão duradoura com o TCU do veículo.
• Encontre um TCU específico com base no ID do 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 Wake-up pode ser mesclado com um servidor de tarefas remoto.

Servidor de tarefas remoto

O servidor de tarefas remoto gerencia essas tarefas remotas.

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

• Usa o servidor Wake-up remoto para ativar o processador de aplicativos nos veículos.

• Interage com o cliente de tarefa remota em execução no veículo.

• Armazena informações de registro do cliente. Isto 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 através do servidor de tarefas remoto para o servidor de ativação, para o TCU do veículo e, eventualmente, para o cliente de tarefa remoto são simplesmente um ID de tarefa. O cliente de tarefa remota usará o ID da tarefa para buscar as informações detalhadas do servidor de tarefa remoto.

Requisitos de privacidade e segurança

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

Se um usuário realizar uma redefinição de fábrica, o ID do cliente armazenado no Car Service será apagado. Porém, 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 agora expirado para o veículo. Como resultado, se o usuário iniciar uma nova tarefa remota para o veículo, ele utilizará o ID do cliente expirado. O veículo é ativado, mas a tarefa remota não pode ser executada porque o cliente da tarefa remota possui um ID de cliente diferente que não corresponde.

A seguir descreve-se uma implementação possível para uma redefinição de fábrica.

Quando um usuário emite uma redefinição de fábrica, o fornecedor solicita que o usuário faça login no servidor de tarefas remoto e desvincule o veículo de sua conta, caso o usuário tenha vinculado o veículo anteriormente. Não é garantido que o dispositivo tenha acesso à rede durante o período de 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 devem ser realizadas para garantir que o proprietário anterior não possa mais atribuir tarefas remotas ao veículo. Por exemplo, o novo proprietário pode ser solicitado a:

• Execute uma redefinição de fábrica. Isso garante que o ID do cliente seja regenerado. Após esta etapa, o proprietário anterior ainda poderá reativar o veículo, mas não poderá mais executar tarefas remotas.

• Abra o aplicativo cliente de tarefa remota e siga o processo Cancelar 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 cliente para vincular o veículo à sua conta e substituir a conta anteriormente vinculada.

• O novo proprietário pode usar o processo Registrar um cliente para vincular o veículo à sua conta e substituir a conta anteriormente vinculada.

Teste o cliente de tarefa remota

Fornecemos o diretório default HAL de acesso remoto de referência para testar clientes de tarefas remotas. Você pode usar o seguinte comando debug para injetar uma tarefa remota falsa no HAL, que será encaminhada para seu cliente de tarefa remota se você fornecer o ID de cliente correto. É possível obter o ID do cliente registrando 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]