Android 14 introduce la nueva función de acceso remoto, que permite a los socios activar Android de forma remota en un vehículo para ejecutar tareas específicas. Por ejemplo, para ejecutar el modo Garage durante la noche y aplicar actualizaciones de software. Se requieren varios componentes que no son de Android para el flujo de trabajo de extremo a extremo. Android no define ni proporciona la implementación de componentes que no son de Android (esta responsabilidad te corresponde a ti).
Para obtener más información, consulta las siguientes secciones:
Flujo de trabajo. Flujo de trabajo entre varios componentes en la arquitectura de muestra para el registro de clientes y la entrega de tareas.
Escribe un cliente de tareas remotas. Usa el acceso remoto y aprende a escribir un cliente de tareas remotas.
Implementación del proveedor Componentes del proveedor en la arquitectura de muestra para admitir el acceso remoto.
Restablecimiento de la configuración de fábrica y transferencia de propiedad Obtén información para controlar el restablecimiento de fábrica y la transferencia de propiedad del vehículo.
Prueba el cliente de acceso remoto. Obtén más información para probar la función de acceso remoto.
Arquitectura
El siguiente contenido supone que se usa la siguiente arquitectura de muestra, que es hipotética y podría no reflejar la arquitectura real. Los OEM deben adaptar una implementación real a las arquitecturas de sus vehículos y servidores.
Figura 1: Arquitectura de muestra.
La arquitectura de muestra consta de los siguientes componentes de hardware:
Componente de hardware | Descripción |
---|---|
Procesador de la app | Procesador que ejecuta Android. Es posible que Android se ejecute en memoria virtual (VM) (no en hardware real) en este procesador. |
Procesador de vehículos | Procesador responsable de controlar la energía del procesador de la app. |
Unidad de control telemático (TCU) | El procesador del vehículo siempre puede recibir mensajes remotos de la nube. Se supone que la TCU siempre está encendida o en modo de bajo consumo. Usa mensajes remotos para activar la TCU. |
Servidor de activación | Un servidor remoto que se ejecuta en la nube y es responsable de comunicarse con la TCU del vehículo para emitir comandos de activación. |
Servidor de tareas remotas | El servidor de tareas remotas se ejecuta en la nube, interactúa con las personas y administra las tareas remotas. |
La arquitectura de muestra consta de los siguientes componentes de software, todos los cuales se ejecutan en Android:
Componente de software integrado en Android | Descripción |
---|---|
Servicio de autos | Servicio del framework de AAOS que proporciona APIs de acceso remoto. |
Cliente de tareas remotas | Una clase Service escrita por el proveedor que ejecuta tareas remotas. Un sistema Android puede ejecutar varios clientes de tareas remotas. |
HAL de acceso remoto | Se debe implementar para el acceso remoto. Capa de abstracción para la comunicación entre AAOS y un componente que no es de Android, como la TCU. |
A continuación, se describen los componentes de software que no son de Android:
Componente de software que no es de Android | Descripción |
---|---|
Cliente de activación | Software que se ejecuta en la TCU y mantiene una conexión de larga duración con el servidor de activación. También mantiene una conexión con el HAL de acceso remoto para entregar tareas remotas al servicio de Car. |
Implementación del servidor de activación | Servidor que se comunica con el cliente de activación que se ejecuta en la TCU. Puede enviar solicitudes de activación al cliente de activación. |
Implementación del servidor de tareas remotas | Es el servidor que administra las tareas remotas. Los usuarios interactúan con este servidor para emitir y supervisar tareas remotas. |
Flujo de trabajo
En esta sección, se enumeran los pasos de un flujo de trabajo de ejemplo.
Flujo de trabajo de ejemplo
Un flujo de trabajo detallado puede parecerse al siguiente:
El usuario estaciona el vehículo en el garaje.
El socio busca actualizar el vehículo durante la noche, cuando es poco probable que haya interacciones con el vehículo.
El servidor en la nube del socio envía una tarea remota del sistema de actualización al vehículo. Específicamente, la unidad de control telemático (TCU).
La TCU del vehículo activa la unidad de control electrónico (ECU) de Android y un servicio del OEM activa el modo de Garage.
Android ejecuta el modo Garage para descargar e instalar actualizaciones a través de Google Play.
Después de aplicar la actualización, Android marca la tarea como completada y finaliza la conexión o alcanza un tiempo de espera especificado.
Flujo de trabajo detallado
Se requieren dos pasos importantes para el acceso remoto. La primera es registrar el cliente, lo que implica vincular un usuario específico a un cliente de tareas remotas específico que se ejecuta en un vehículo específico. La otra es entregar una tarea, que consiste en entregar la tarea remota para un usuario específico al cliente de la tarea remota específico que se ejecuta en el vehículo específico.
Registra un cliente
Para usar la función de acceso remoto, el usuario debe abrir la app del cliente de tareas remotas al menos una vez y completar el proceso de registro del cliente (el texto en negrita indica las tareas implementadas por AAOS):
Durante el inicio, Car Service obtiene información del vehículo del HAL de acceso remoto.
Al iniciar el sistema, Car Service inicia todos los clientes de tareas remotas según el filtro de intents y el permiso.
Cuando se inicia el cliente de tareas remoto, este se registra en Car Service.
Car Service notifica al cliente de tareas remotas sobre la información de registro, incluidos el ID del vehículo y el ID del cliente. El ID de cliente es único y el servicio de automóviles lo asigna a este cliente. Se garantiza que es único entre todos los clientes de tareas remotas del mismo vehículo.
El usuario accede al servidor de tareas remoto a través del cliente de tareas remoto y habilita la función de acceso remoto para este vehículo. Por lo general, este paso implica la autenticación a través del servidor de tareas remoto.
El cliente de tareas remotas sube la información del usuario junto con el ID del vehículo y el ID del cliente al servidor de tareas remotas, y le solicita que vincule al usuario con este cliente y este vehículo específicos.
De manera opcional, este paso puede implicar una autenticación de dos factores adicional por parte del usuario.
El servidor de tareas remoto debe autenticar que el ID del vehículo proporcionado en la solicitud coincida con el ID del vehículo del remitente, lo que se puede hacer a través de la certificación del vehículo.
A menos que se realice un restablecimiento de la configuración de fábrica, el proceso de registro del cliente se requiere una vez por usuario y por vehículo. El ID de cliente se almacena de forma local en el servicio de automóvil y sigue siendo el mismo para el mismo cliente.
Figura 2: Registra un cliente.
Cancela el registro de un cliente
Un usuario puede desvincular el vehículo de su cuenta desde el vehículo o desde el servidor de tareas remotas:
En el vehículo, los usuarios pueden abrir la app cliente de tareas remotas y emitir una solicitud de desvinculación para desvincular el vehículo de las cuentas de usuario vinculadas anteriormente.
En el servidor de tareas remoto, los usuarios pueden acceder a su cuenta y desvincular de ella un vehículo que se haya vinculado anteriormente.
Si el usuario desvincula el vehículo de su cuenta, el servidor de tareas remotas debe quitar la asignación almacenada para el usuario específico.
Entrega de tareas
En la nube:
Un usuario usa el servidor de tareas remoto para enviar una tarea remota a un vehículo específico.
El servidor de tareas remoto asigna el ID de usuario al ID del vehículo y al ID de cliente. Envía los datos de la tarea, el ID del vehículo y el ID del cliente al servidor de activación.
El servidor de activación encuentra la TCU específica para el ID del vehículo (suponiendo que el registro de la TCU ya se realizó) y envía los datos de la tarea y el ID de cliente a la TCU.
En el vehículo (el texto en negrita indica las tareas que realiza AAOS):
La TCU recibe tareas remotas del servidor remoto.
Si el procesador de aplicaciones (AP) que ejecuta AAOS está apagado, la TCU usa el procesador del vehículo (VP) para activar el AP.
El servicio para automóviles recibe tareas de la TCU.
Car Service distribuye las tareas al cliente de tareas remoto correspondiente.
El cliente de tareas remotas recibe y ejecuta la tarea.
(Opcional) El cliente de tareas remotas se comunica con el servidor de tareas para obtener más detalles sobre la tarea y la ejecuta.
(Opcional) El servicio de cliente de tareas remotas informa el resultado de la tarea al servidor de tareas.
El cliente de tareas remotas notifica al servicio de automóvil cuando se completa la tarea.
Si es necesario, el servicio de automóvil restablece el estado de energía del vehículo.
Figura 3: Entregar tareas
Escribe un cliente de tareas remotas
CarRemoteAccessManager
proporciona la API para las funciones de acceso remoto. Para obtener más información, consulta CarRemoteAccessManager.
Un cliente de tareas remoto es un servicio de Android que ejecuta tareas remotas y usa CarRemoteAccessManager
. Esto requiere PERMISSION_USE_REMOTE_ACCESS
y PERMISSION_CONTROL_REMOTE_ACCESS
, y debe declarar un filtro de intents para RemoteTaskClientService
de la siguiente manera:
<service android:name=".remoteaccess.RemoteTaskClientService"
android:directBootAware="true"
android:exported="true">
<intent-filter>
<action android:name="android.car.remoteaccess.RemoteTaskClientService" />
</intent-filter>
</service>
Un cliente de tareas remoto debe registrarse en Car Service durante la creación:
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);
}
}
Debe anular la función onBind para devolver un valor nulo.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Car Service administra su ciclo de vida. Car Service se vincula a este servicio durante el inicio y cuando llega una tarea remota. Car Service se desvincula de este servicio cuando se completa la tarea. Para obtener más información, consulta Cómo administrar el ciclo de vida de un servicio.
El cliente de tareas remotas se ejecuta como usuario del sistema, por lo que no tiene acceso a ningún dato específico del usuario.
En el siguiente ejemplo, se muestra cómo controlar las devoluciones de llamadas registradas:
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();
}
}
Implementación del proveedor
La función de acceso remoto es opcional y está inhabilitada de forma predeterminada. Para habilitar la función, agrega un RRO como el siguiente:
// 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
}
O usa el siguiente comando adb en una compilación userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Requisitos en Android
HAL de acceso remoto
La capa de abstracción de hardware (HAL) de acceso remoto es una capa de abstracción implementada por el proveedor para la comunicación entre AAOS y otra ECU (por ejemplo, una TCU). Es obligatorio para admitir la función de acceso remoto. No es necesario implementarlo si no se implementa la función de acceso remoto.
La interfaz se define en IRemoteAccess.aidl y contiene los siguientes métodos:
Clase | Descripción |
---|---|
String getVehicleId() |
Obtiene un ID de vehículo único que puede reconocer el servidor de activación. |
String getWakeupServiceName() |
Obtiene el nombre del servidor de activación remota. |
String getProcessorId() |
Obtiene un ID de procesador único que se puede reconocer activando el cliente. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Establece una devolución de llamada que se llamará cuando se solicite una tarea remota. |
|
void clearRemoteTaskCallback() |
Borra una devolución de llamada de tarea remota establecida anteriormente. |
void notifyApStateChange(in ApState state)
Detecta si el procesador de la app está listo para recibir tareas remotas. |
La interfaz de devolución de llamada se define en IRemoteTaskCallback.aid
.
Clase | Descripción |
---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Es una devolución de llamada que se invoca cuando se solicita una tarea remota. |
Consulta la implementación de referencia con una TCU externa. La implementación usa una transmisión de lectura de larga duración para recibir tareas remotas y admite el siguiente comando debug
:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
HAL de vehículo
Para admitir la función de acceso remoto, el VHAL debe admitir estas propiedades:
Clase | Descripción |
---|---|
SHUTDOWN_REQUEST |
Solicita que se apague la consola central. |
VEHICLE_IN_USE |
|
Para obtener más información, consulta Supported System Properties.
Modo silencioso
El modo silencioso debe ser compatible con la función de acceso remoto para que el vehículo pueda iniciarse en modo silencioso y ejecutar tareas remotas cuando no haya ningún usuario presente. Con el modo silencioso, el dispositivo AAOS se inicia con la pantalla y el audio apagados.
El modo silencioso se controla a través de dos archivos sysfs
del kernel de Linux.
Clase | Descripción |
---|---|
/sys/kernel/silent_boot/pm_silentmode_kernel_state
Representa el modo silencioso actual. |
|
/sys/kernel/silent_boot/pm_silentmode_hw_state
Representa el hardware que indica que se debe establecer un nuevo modo silencioso. |
El procesador del vehículo envía un indicador de HW al SoC de Android para activar o desactivar el modo silencioso. El indicador (0 o 1) se escribe en /sys/kernel/silent_boot/pm_silentmode_hw_state
. Luego, el framework de AAOS actualiza /sys/kernel/silent_boot/pm_silentmode_kernel_state
según corresponda, lo que representa el modo silencioso actual. Los módulos de AAOS verifican /sys/kernel/silent_boot/pm_silentmode_kernel_state
para saber si el sistema está en modo silencioso o no.
Cuando se recibe una tarea remota y se inicia AAOS, el procesador del vehículo establece el modo silencioso y, luego, inicia AAOS para que el sistema se inicie con la pantalla y el audio apagados.
Componentes no relacionados con Android en el vehículo
Procesador de vehículos
El procesador del vehículo es un procesador que se encuentra en el vehículo y que puede controlar la energía del procesador de la app que ejecuta Android. En la arquitectura de ejemplo, la TCU activa el procesador de la app enviando un mensaje al procesador del vehículo.
Componentes no relacionados con Android en el vehículo
La TCU del vehículo siempre puede recibir mensajes remotos.
El cliente de activación se ejecuta en la TCU para garantizar una conexión duradera con el servidor de activación remoto.
AAOS que se ejecuta en el AP puede comunicarse con el cliente de activación que se ejecuta en la TCU a través del HAL de acceso remoto.
Figura 4: TCU (cliente de activación).
Componentes en la nube
Servidor de activación
El servidor de activación se comunica con el cliente de activación en la TCU para realizar las siguientes acciones:
- Mantener una conexión duradera con la TCU del vehículo
- Busca una TCU específica según el ID del vehículo.
- Informa el estado de un vehículo. Por ejemplo, en línea o sin conexión, o la última vez que se conectó al servidor de tareas remoto.
En una implementación real, un servidor de activación se puede combinar con un servidor de tareas remoto.
Servidor de tareas remotas
El servidor de tareas remotas administra estas tareas remotas.
El usuario interactúa con el servidor para iniciar tareas remotas nuevas y supervisar las tareas remotas.
Usa el servidor de activación remota para activar el procesador de la app en los vehículos.
Interactúa con el cliente de tareas remotas que se ejecuta en el vehículo.
Almacena la información de registro del cliente. Esto asocia un usuario específico a un cliente de tareas remotas específico en un vehículo específico.
Por lo general, los datos de la tarea que se envían a través del servidor de tareas remoto al servidor de activación, a la TCU del vehículo y, finalmente, al cliente de tareas remoto son simplemente un ID de tarea. El cliente de tareas remotas usa el ID de la tarea para recuperar la información detallada del servidor de tareas remotas.
Requisitos de privacidad y seguridad
Tarea | Condition | Requisito |
---|---|---|
TCU (cliente de activación) | OBLIGATORIO |
|
Servidor de activación | OBLIGATORIO |
|
Cliente de tareas remotas | OBLIGATORIO |
|
Servidor de tareas remotas | OBLIGATORIO |
|
Restablecimiento de la configuración de fábrica y transferencia de propiedad
Si un usuario restablece la configuración de fábrica, se borra el ID de cliente almacenado en Car Service. Sin embargo, no se informa a los servidores (servidor de tareas remoto y servidor de activación remoto). Los servidores conservan una asignación del ID de cliente que ahora venció al vehículo. Como resultado, si el usuario inicia una nueva tarea remota para el vehículo, se usará el ID de cliente vencido. El vehículo se activa, pero no se puede ejecutar la tarea remota porque el cliente de la tarea remota tiene un ID de cliente diferente que no coincide.
A continuación, se describe una posible implementación para restablecer la configuración de fábrica.
Cuando un usuario restablece la configuración de fábrica, el proveedor le solicita que acceda al servidor de tareas remoto y desvincule el vehículo de su cuenta si el usuario ya lo había vinculado. No se garantiza que el dispositivo tenga acceso a la red durante el restablecimiento de la configuración de fábrica. Por lo tanto, es posible que no sea factible emitir la solicitud de desvinculación en el momento del restablecimiento de la configuración de fábrica desde el dispositivo.
Cada vez que se transfiere la propiedad de un vehículo, se deben realizar algunas operaciones para garantizar que el propietario anterior ya no pueda emitir tareas remotas al vehículo. Por ejemplo, es posible que se le solicite al nuevo propietario que haga lo siguiente:
Restablece la configuración de fábrica. Esto garantiza que se vuelva a generar el ID de cliente. Después de este paso, el propietario anterior aún puede activar el vehículo, pero ya no puede ejecutar tareas de forma remota.
Abre la app cliente de tareas remotas y sigue el proceso de Cancelar el registro de un cliente para desvincular el vehículo de la cuenta del propietario anterior. El nuevo propietario puede seguir el proceso de registro de un cliente para vincular el vehículo a su cuenta y reemplazar la cuenta vinculada anteriormente.
El nuevo propietario puede usar el proceso Registrar un cliente para vincular el vehículo a su cuenta y reemplazar la cuenta vinculada anteriormente.
Prueba el cliente de tareas remoto
Proporcionamos el directorio de HAL de acceso remoto de referencia default
para probar los clientes de tareas remotas. Puedes usar el siguiente comando debug
para insertar una tarea remota falsa en el HAL, que se reenvía a tu cliente de tareas remotas si proporcionas el ID de cliente correcto. Puedes obtener el ID del cliente registrando la información de registro en la implementación del cliente de tareas remotas.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]