Esta página foi traduzida pela API Cloud Translation.

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 :

Componente de hardware	Descrição
Processador de aplicativos	Processador que roda Android. O Android pode ser executado em memória virtual (VM) (não em hardware real) neste processador.
Processador de veículo	Processador responsável por controlar a energia do processador do aplicativo.
Unidade de controle telemático (TCU)	Processador no veículo sempre capaz de receber mensagens remotas da nuvem. Presume-se que a TCU esteja sempre ligada ou em modo de baixo consumo de energia. Use mensagens remotas para despertar o TCU.
Servidor de despertar	Servidor remoto que roda na nuvem e é responsável pela comunicação com o TCU do veículo para emitir comandos de despertar.
Servidor de tarefas remoto	O servidor de tarefas remotas é executado na nuvem, interage com as pessoas e gerencia tarefas remotas.

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

Componente de software no Android	Descrição
Serviço automotivo	Serviço de estrutura AAOS que fornece APIs de acesso remoto.
Cliente de tarefa remota	Uma classe `Service` escrita pelo fornecedor que executa tarefas remotas. Um sistema Android pode executar vários clientes de tarefas remotas.
Acesso remoto HAL	Deve ser implementado para acesso remoto. Camada de abstração para comunicação entre AAOS e um componente não Android como o TCU.

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

Componente de software não Android	Descrição
Cliente de despertar	Software executado 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 Car Service.
Implementação do servidor de despertar	Servidor que se comunica com o cliente wake-up rodando no TCU. Pode enviar solicitações de ativação ao cliente de ativação.
Implementação de servidor de tarefas remoto	Servidor que gerencia tarefas remotas. Os usuários interagem com este servidor para emitir e monitorar tarefas remotas.

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:

O usuário estaciona o veículo na garagem.
O parceiro procura atualizar o veículo durante a noite, quando as interações entre veículos são improváveis.
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).
O TCU do veículo ativa a unidade de controle eletrônico (ECU) do Android e um serviço OEM aciona o modo Garagem.
O Android executa o modo Garage para baixar e instalar atualizações através do 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

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 (o texto em negrito indica tarefas implementadas pelo AAOS):

Na inicialização, o Car Service obtém informações do veículo a partir do HAL de acesso remoto.
Na inicialização, o Car Service inicia todos os clientes de tarefas remotas com base no filtro de intenção e na permissão.
Após o início do cliente de tarefa remota, o cliente de tarefa remota regista-se no Car Service.
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.
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.
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.
Nota: Um usuário pode possuir vários veículos. Um banco de dados de amostra no servidor de tarefas remoto poderia usar [userID, vehicleID] como chave e [client ID] como valor.

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 este veículo de suas contas de usuário vinculadas anteriormente.
No servidor de tarefas remoto , os usuários podem fazer login em sua conta e desvincular um veículo previamente vinculado a esta 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:

Um usuário usa o servidor de tarefas remotas para enviar uma tarefa remota para um veículo específico.
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 de ativação.
O servidor de despertar encontra o TCU específico para o ID do veículo (assumindo que o registro do TCU já foi feito) e envia os dados da tarefa e o ID do cliente para o TCU.

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

TCU recebe tarefas remotas de servidor remoto.
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.
Car Service recebe tarefas do TCU.
O Car Service distribui tarefas para o cliente de tarefa remota correspondente.
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.
( Opcional ) O serviço cliente de tarefa remota relata o resultado da tarefa ao servidor de tarefas.
O cliente de tarefa remota notifica o Car Service quando a tarefa é concluída.
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:

Aula	Descrição
`String getVehicleId()`	Obtém um ID de veículo exclusivo que pode ser reconhecido pelo servidor de ativação.
`String getWakeupServiceName()`	Obtém o nome do servidor de ativação remota.
`String getProcessorId()`	Obtém um ID de processador exclusivo que pode ser reconhecido ao ativar o cliente.
`void setRemoteTaskCallback(IRemoteTaskCallback callback)` Define um retorno de chamada a ser chamado quando uma tarefa remota for solicitada.
`void clearRemoteTaskCallback()`	Limpa um retorno de chamada de tarefa remota definido anteriormente.
`void notifyApStateChange(in ApState state)` Detecta se o processador do aplicativo está pronto para receber tarefas remotas.

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

Aula	Descrição
`oneway void onRemoteTaskRequested(String clientId, in byte[] data)` Um retorno de chamada chamado quando uma tarefa remota é solicitada.

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:

Aula	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 destrava o veículo ou quando o usuário se aproxima do veículo. Deveria ser `true` . Uma duração específica após o usuário desligar o veículo ou quando o usuário travar o veículo. Deveria ser `false` . Quando `true` , o AAOS não tenta desligar o veículo quando a tarefa remota é concluída.

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.

Aula	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 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 de ativação é executado no TCU para garantir uma conexão duradoura com o servidor de ativação remoto.

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

Figura 4. TCU (cliente wake-up).

Componentes na nuvem

Servidor de despertar

O servidor de ativação se comunica com o cliente de ativação 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 de ativação 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 de ativação remota 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 usa o ID da tarefa para buscar informações detalhadas do servidor de tarefa remoto.

Requisitos de privacidade e segurança

Tarefa	Doença	Requerimento
TCU (cliente de despertar)	DEVE	Autentique o servidor de ativação. Confie no código.
Servidor de despertar	DEVE	Permitir que apenas servidores de tarefas remotas listados como permitidos se conectem. Autentique o cliente de ativação. Envie a mensagem de despertar apenas para o veículo alvo.
Cliente de tarefa remota	DEVE	Autentique o usuário durante o registro. Autentique o servidor de tarefas remoto. Atenda a todos os requisitos de segurança de um serviço Android. Por exemplo, permissões limitadas.
Servidor de tarefas remoto	DEVE	Deve autenticar o servidor de ativação. Fornecer atestado do veículo. Ou seja, autentique se o ID do veículo fornecido na solicitação corresponde ao ID do veículo do remetente. Se o atestado do veículo não for possível, deverá utilizar 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 lida com informações do usuário.

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]