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.
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 |
|
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_stateRepresenta o modo silencioso atual. | |
/sys/kernel/silent_boot/pm_silentmode_hw_stateRepresenta 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 |
|
| Servidor de despertar | DEVE |
|
| Cliente de tarefa remota | DEVE |
|
| Servidor de tarefas remoto | DEVE |
|
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]