O Android 14 introduz o novo recurso de acesso remoto, que permite que os parceiros ativem remotamente o Android em um veículo para executar tarefas específicas. Por exemplo, para executar Modo garagem durante a noite para aplicar o software atualizações. Vários componentes que não são Android são necessários para o processamento de desenvolvimento de software. O Android não define nem fornece implementação para apps que não são do 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 amostra arquitetura para registro de clientes e entrega de tarefas.
Gravar um cliente de tarefa remota. Usar acesso remoto e aprender a criar um cliente de tarefa remota.
Implementação do fornecedor. Os componentes do fornecedor arquitetura de amostra para dar suporte ao acesso remoto.
Redefinir para a configuração original e transferir a propriedade. Saiba como lidar redefinição de fábrica e transferência de propriedade do veículo.
Teste o cliente de acesso remoto. Saiba como testar o acesso remoto .
Arquitetura
O conteúdo a seguir pressupõe o uso da seguinte arquitetura de exemplo, que é hipotético e pode não refletir a arquitetura real. OEMs precisam se adaptar uma implementação real nas arquiteturas do veículo e do servidor.
Figura 1. Arquitetura de amostra.
A arquitetura de amostra consiste nestes componentes de hardware:
| Componente de hardware | Descrição |
|---|---|
| Processador de apps | Processador que executa o Android. O Android pode ser executado em uma memória virtual (VM) (não em um hardware real) neste processador. |
| Processador de veículos | Processador responsável por controlar a energia do app processador. |
| Unidade de controle telemático (TCU) | Processador no veículo sempre capaz de receber mensagens remotas na nuvem. Presume-se que o TCU esteja sempre ativado ou no modo de baixo consumo de energia. Usar mensagens remotas para ativar o TCU. |
| Servidor de ativação | Um servidor remoto que é executado na nuvem e é responsável por comunicando-se com o TCU no veículo para emitir comandos de ativação. |
| Servidor de tarefas remotas | O servidor de tarefa remota é executado na nuvem e interage com pessoas e gerencia tarefas remotas. |
A arquitetura de amostra consiste nestes componentes de software, todos executados no Android:
| Componente de software no Android | Descrição |
|---|---|
| Serviço de carro | Serviço de framework AAOS que fornece APIs de acesso remoto. |
| Cliente de tarefa remota | Um software criado por um fornecedor
Service
que executa tarefas remotas. Um sistema Android pode executar várias
clientes de tarefas remotas. |
| HAL de acesso remoto | Precisa ser implementado para acesso remoto. Camada de abstração para comunicação entre o AAOS e um ambiente que não é Android como o TCU. |
Componentes de software que não são Android são descritos abaixo:
| Componente de software que não é do Android | Descrição |
|---|---|
| Cliente de ativação | Software em execução no TCU que mantém uma conexão de longa duração com o servidor de ativação. Ela também mantém uma conexão com a HAL de acesso remoto para entregar tarefas remotas à oficina mecânica. |
| Implementação da ativação do servidor | Servidor que se comunica com o cliente de ativação em execução no TCU. Pode enviar solicitações de despertar ao cliente de ativação. |
| Implementação do servidor de tarefas remotas | Servidor que gerencia tarefas remotas. Os usuários interagem com esse servidor para resolver problemas e monitorar tarefas remotas. |
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:
O usuário estaciona o veículo na garagem.
O parceiro procura atualizar o veículo durante a noite quando as interações com o veículo forem improvável.
O servidor de nuvem do parceiro envia uma tarefa remota do sistema de atualização ao 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 de OEM aciona o modo garagem.
O Android executa o modo garagem para fazer o download e instalar atualizações pelo 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
Há duas etapas importantes necessárias para o acesso remoto. A primeira é registrar o cliente, que é vincular um usuário específico a um cliente de tarefas em execução em um veículo específico. A outra é entregar uma tarefa, é entregar a tarefa remota para um usuário específico à tarefa remota específica cliente em execução no veículo específico.
Registrar um cliente
Para usar o recurso de acesso remoto, um usuário precisa abrir o cliente de tarefas remotas aplicativo pelo menos uma vez e finalize o processo de registro do cliente (texto em negrito indica tarefas implementadas pelo AAOS):
Na inicialização, o Car Service recebe informações do veículo pelo acesso remoto HAL.
Na inicialização, o Car Service inicia todos os clientes de tarefas remotas com base filtro de intent e permissão.
Na inicialização do cliente da tarefa remota, o cliente da tarefa remota se registra com do Car Service.
O Car Service notifica o cliente da tarefa remota sobre o registro do cliente, como o ID do veículo e do cliente. O ID do cliente é exclusivo e atribuído pela Car Service a esse 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 usando o cliente de tarefas remotas e ativa o recurso de acesso remoto para o veículo. Essa etapa normalmente envolve autenticação pelo servidor de tarefas remotas.
O cliente da tarefa remota carrega as informações do usuário junto com o ID do veículo e ID do cliente ao servidor de tarefas remotas e solicita a vinculação do usuário com para esse cliente e veículo específicos.
Opcionalmente, esta etapa pode envolver mais autenticação de dois fatores do usuário.
O servidor de tarefas remotas precisa autenticar que o ID do veículo fornecido em a solicitação corresponde ao ID do veículo do remetente, o que pode ser feito atestado de veículo.
A menos que uma redefinição para a configuração original seja realizada, 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 igual para o mesmo cliente.
Figura 2. Registrar um cliente
Cancelar o registro de um cliente
Um usuário pode desvincular o veículo da sua conta do veículo ou do o servidor de tarefas remotas:
No vehicle, os usuários podem abrir o app cliente de tarefa remota e emitir uma solicitação para desvincular este veículo do usuário vinculado anteriormente contas de serviço.
No servidor de tarefas remota, os usuários podem fazer login na conta e desvincular um veículo vinculado anteriormente a esta conta.
Se o usuário desvincular o veículo da conta, o servidor de tarefa remota precisará remove 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 usuário específico veículo
O servidor de tarefas remotas mapeia o ID do usuário para o ID do veículo e do cliente. Ela envia os dados da tarefa, o ID do veículo e o ID do cliente ao servidor de ativação.
O servidor de ativação encontra o TCU específico para o ID do veículo (supondo que o registro TCU já foi feito) e envia os dados da tarefa e o ID do cliente para ao TCU.
No veículo (o texto em negrito indica tarefas realizadas pelo AAOS):
O TCU recebe tarefas remotas do servidor remoto.
Se o processador de apps (AP) com o AAOS estiver desativado, o TCU usará o para ativar o AP.
O Car Service recebe tarefas do TCU.
O Car Service distribui tarefas para o cliente de tarefa remota correspondente.
O cliente da tarefa remota recebe e executa a tarefa.
(Opcional) O cliente de tarefa remota entra em contato com o servidor de tarefas para obter mais detalhes sobre a tarefa e executa a tarefa.
(Opcional) O serviço de cliente de tarefa remota informa o resultado da tarefa para o 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 da 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 (link em inglês).
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);
}
}
Ele precisa substituir a função onBind para retornar um valor nulo.
@Override
public IBinder onBind(Intent intent) {
return null;
}
O Car Service gerencia o ciclo de vida. O Car Service é vinculado a esse serviço durante inicialização e quando uma tarefa remota chega. O Car Service se desvincula a esse serviço quando a tarefa estiver 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, por isso não tem acesso a dados específicos 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 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 para Android
HAL de acesso remoto
A camada de abstração de hardware (HAL) de acesso remoto é uma implementação camada de abstração para comunicação entre o AAOS e outra ECU (por exemplo, uma TCU). Ele é obrigatório para oferecer suporte ao recurso de acesso remoto. Ele não precisa deve ser implementado se o recurso de acesso remoto não estiver implementado.
A interface é definida em IRemoteAccess.aidl e inclui estes métodos:
| Classe | Descrição |
|---|---|
String getVehicleId() |
Recebe um ID do veículo exclusivo que pode ser reconhecido pela ativação servidor. |
String getWakeupServiceName() |
Recebe o nome do servidor de ativação remota. |
String getProcessorId() |
Recebe um ID de processador exclusivo que pode ser reconhecido ativando o para o cliente. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Define um callback a ser chamado quando uma tarefa remota é solicitada. |
|
void clearRemoteTaskCallback() |
Limpa um callback de tarefa remota definido anteriormente. |
void notifyApStateChange(in ApState state)
Detecta se o processador do app está pronto para receber tarefas remotas. | |
A interface de callback é definida em
IRemoteTaskCallback.aid:
| Classe | Descrição |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Um callback chamado quando uma tarefa remota é solicitada. |
|
Consulte a
implementação de referência
com um TCU externo. 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:
| Classe | Descrição |
|---|---|
SHUTDOWN_REQUEST |
Solicita que a unidade principal seja desligada. |
VEHICLE_IN_USE |
|
Para saber mais, consulte Propriedades de sistema compatíveis.
Modo silencioso
O modo silencioso deve ser suportado para o recurso de acesso remoto para que o veículo pode inicializar no modo silencioso para executar tarefas remotas quando nenhum usuário está presente. Com 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.
| Classe | 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 do hardware para definir um novo modo silencioso. |
|
O processador do veículo envia um sinal de hardware ao Android SoC para ativar/desativar o modo silencioso
modo O indicador (0 ou 1) é gravado
/sys/kernel/silent_boot/pm_silentmode_hw_state: Depois, o framework AAOS atualiza
/sys/kernel/silent_boot/pm_silentmode_kernel_state, de acordo com o
representa o modo silencioso atual. Verificações de módulos AAOS
/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 Modo silencioso e inicia o AAOS para que o sistema seja inicializado com a tela/o áudio desligado.
Componentes no veículo que não são Android
Processador de veículos
O processador do veículo é um processador no veículo que pode controlar a potência para o processador do app com Android. Na arquitetura de exemplo, o TCU ativa o processador do app enviando um sinal para o veículo processador.
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 dia 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 um TCU específico com base no ID de um veículo.
- Informar o status de um veículo. Por exemplo, on-line ou off-line, ou 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 servidor de tarefas.
Servidor de tarefas remotas
O servidor de tarefas remotas 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 na os veículos.
Interage com o cliente de tarefa remota em execução no veículo.
Armazena as informações de registro do cliente. Isso associa um usuário específico para um cliente de tarefa remota específico em um veículo específico.
Normalmente, os dados da tarefa são enviados pelo servidor de tarefas remotas para a ativação para o TCU do veículo e, eventualmente, para o cliente da tarefa remota um ID de tarefa. O cliente de tarefa remota usa o ID da tarefa para buscar a tarefa informações do servidor de tarefas remotas.
Requisitos de privacidade e segurança
| Tarefa | Condição | Requisito |
|---|---|---|
| TCU (cliente de ativação) | OBRIGATÓRIO |
|
| Servidor de ativação | OBRIGATÓRIO |
|
| Cliente de tarefa remota | OBRIGATÓRIO |
|
| Servidor de tarefas remotas | OBRIGATÓRIO |
|
Redefinição 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á apagados. No entanto, os servidores (servidor de tarefas remotas e servidor de ativação remota) não informados. Os servidores mantêm um mapeamento do ID do cliente expirado para o o veículo. Como resultado, se o usuário iniciar uma nova tarefa remota para o veículo, ela usa o ID do cliente expirado. O veículo é ativado, mas a tarefa remota não pode ser executado, pois o cliente da tarefa remota possui 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 redefine para a configuração original, o fornecedor solicita que ele faça login no ao servidor de tarefas remotas e desvincular o veículo da conta se o usuário tiver já havia vinculado o veículo. Não há garantia de que o dispositivo tenha rede durante a redefinição para a configuração original. Portanto, emitindo a solicitação de desvinculação no momento da redefinição para a configuração original a partir do dispositivo pode não ser viável.
Sempre que a propriedade de um veículo for transferida, algumas operações devem ser executada para garantir que o proprietário anterior não possa mais emitir tarefas remotas para o veículo Por exemplo, talvez o novo proprietário precise fazer o seguinte:
Redefina o dispositivo para a configuração original. Isso garante que o ID do cliente seja gerado novamente. Depois etapa, o proprietário anterior ainda poderá ativar o veículo, mas não poderá executar tarefas remotas por mais tempo.
Abra o app cliente de tarefa remota e siga as Cancelar o registro de um cliente para desvincular o veículo da conta do proprietário anterior. O novo proprietário pode seguir o registro processo do cliente para vincular o veículo à conta e substituir o vinculada anteriormente.
O novo proprietário pode usar o processo Registrar um cliente para vincular o veículo à conta e substituir a anterior.
Testar o cliente de tarefa remota
Fornecemos a HAL de acesso remoto de referência
default
para testar clientes de tarefas remotas. Você pode usar as seguintes debug
para injetar uma tarefa remota fictícia na HAL, que é encaminhada ao seu
cliente de tarefa remota se você fornecer o ID de cliente correto. Você pode fazer com que o cliente
do Google Cloud registrando as informações de registro no cliente de tarefa remota
implementação.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]