Android 14 presenta 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 Garaje durante la noche para aplicar actualizaciones de software. Se requieren varios componentes que no sean de Android para el flujo de trabajo de un extremo a otro. Android no define ni proporciona implementación para componentes que no sean de Android (esta responsabilidad le pertenece a usted).
Para obtener más información, consulte las siguientes secciones:
Flujo de trabajo . Flujo de trabajo entre múltiples componentes en la arquitectura de muestra para el registro de clientes y la entrega de tareas.
Escriba un cliente de tareas remotas . Utilice el acceso remoto y aprenda a escribir un cliente de tareas remotas.
Implementación de proveedores . Componentes del proveedor en la arquitectura de muestra para admitir el acceso remoto.
Restablecimiento de fábrica y transferencia de propiedad . Aprenda cómo manejar el restablecimiento de fábrica y la transferencia de propiedad del vehículo.
Pruebe el cliente de acceso remoto . Aprenda cómo probar la función de acceso remoto.
Arquitectura
El siguiente contenido supone que se utiliza la siguiente arquitectura de muestra, que es hipotética y puede 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 estos componentes de hardware :
| Componente de hardware | Descripción |
|---|---|
| Procesador de aplicaciones | Procesador que ejecuta Android. Es posible que Android se ejecute en la memoria virtual (VM) (no en el hardware real) en este procesador. |
| Procesador de vehículos | Procesador responsable de controlar la energía del procesador de la aplicación. |
| Unidad de control telemático (TCU) | Procesador en vehículo siempre capaz de recibir mensajes remotos desde la nube. Se supone que la TCU siempre está encendida o en modo de bajo consumo. Utilice mensajes remotos para despertar la TCU. |
| servidor de despertador | 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 remoto | El servidor de tareas remotas se ejecuta en la nube, interactúa con personas y administra tareas remotas. |
La arquitectura de muestra consta de estos componentes de software , todos los cuales se ejecutan en Android:
| Componente de software en Android | Descripción |
|---|---|
| Servicio de auto | Servicio de marco AAOS que proporciona API de acceso remoto. |
| Cliente de tareas remotas | Una clase Service escrita por el proveedor que ejecuta tareas remotas. Un sistema Android puede ejecutar múltiples clientes de tareas remotas. |
| Acceso remoto HAL | Debe implementarse para acceso remoto. Capa de abstracción para la comunicación entre AAOS y un componente que no es de Android, como la TCU. |
Los componentes de software que no son de Android se describen a continuación:
| Componente de software que no es de Android | Descripción |
|---|---|
| Cliente de despertador | Software que se ejecuta en la TCU y mantiene una conexión duradera con el servidor de activación. También mantiene una conexión con Remote Access HAL para entregar tareas remotas al Car Service. |
| 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 remoto | Servidor que gestiona tareas remotas. Los usuarios interactúan con este servidor para emitir y monitorear tareas remotas. |
Flujo de trabajo
Esta sección enumera los pasos de un flujo de trabajo de muestra.
Flujo de trabajo de muestra
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. En concreto, 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 OEM activa el modo Garaje.
Android ejecuta el modo Garaje 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 específico.
Flujo de trabajo detallado
Hay dos pasos importantes necesarios para el acceso remoto. La primera es registrar el cliente, que consiste en vincular un usuario específico a un cliente de tarea remota 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 tarea remota específico que se ejecuta en el vehículo específico.
Registrar un cliente
Para utilizar la función de acceso remoto, un usuario debe abrir la aplicación cliente de tareas remotas al menos una vez y finalizar el proceso de registro del cliente (el texto en negrita indica tareas implementadas por AAOS):
Al arrancar, Car Service obtiene información del vehículo desde el acceso remoto HAL.
Al arrancar, Car Service inicia todos los clientes de tareas remotas según el filtro de intención y el permiso.
Al iniciar el cliente de tareas remotas, el cliente de tareas remotas se registra en el Servicio de automóviles.
Car Service notifica al cliente de la tarea remota sobre la información de registro, incluida la identificación del vehículo y la identificación del cliente. La identificación del cliente es única y Car Service la asigna a este cliente. Se garantiza que será único entre todos los clientes de tareas remotas en el mismo vehículo.
El usuario inicia sesión en el servidor de tareas remotas a través del cliente de tareas remotas y habilita la función de acceso remoto para este vehículo. Este paso normalmente implica la autenticación a través del servidor de tareas remoto.
El cliente de tareas remotas carga la información del usuario junto con la identificación del vehículo y la identificación del cliente al servidor de tareas remotas y le solicita que vincule al usuario con este cliente específico y este vehículo específico.
Opcionalmente, este paso podría implicar una autenticación de dos factores adicional por parte del usuario.
El servidor de tareas remoto debe autenticar que la identificación del vehículo proporcionada en la solicitud coincide con la identificación del vehículo del remitente, lo que se puede hacer mediante la certificación del vehículo.
A menos que se realice un restablecimiento de fábrica, el proceso de registro de cliente se requiere una vez por usuario y por vehículo. La identificación del cliente se almacena localmente en el Servicio de automóvil y permanece igual para el mismo cliente.
Figura 2. Registrar un cliente.
Dar de baja a un cliente
Un usuario puede desvincular el vehículo de su cuenta ya sea desde el vehículo o desde el servidor de tareas remoto:
En el vehículo , los usuarios pueden abrir la aplicación cliente de tareas remotas y emitir una solicitud de desvinculación para desvincular este vehículo de sus cuentas de usuario previamente vinculadas.
En el servidor de tareas remoto , los usuarios pueden iniciar sesión en su cuenta y desvincular un vehículo previamente vinculado de esta cuenta.
Si el usuario desvincula el vehículo de su cuenta, el servidor de tareas remoto debe eliminar el mapeo almacenado para el usuario específico.
Entregar tareas
En las nubes:
Un usuario utiliza el servidor de tareas remoto para enviar una tarea remota a un vehículo específico.
El servidor de tareas remoto asigna la ID de usuario a la ID del vehículo y a la ID del cliente. Envía los datos de la tarea, la identificación del vehículo y la identificación del cliente al servidor de activación.
El servidor de activación encuentra la TCU específica para la ID del vehículo (suponiendo que el registro de la TCU ya esté realizado) y envía los datos de la tarea y la ID del cliente a la TCU.
En el vehículo (el texto en negrita indica tareas realizadas por 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.
Car Service recibe tareas del TCU.
Car Service distribuye tareas al cliente de tareas remotas correspondiente.
El cliente de tareas remotas recibe y ejecuta la tarea.
( Opcional ) El cliente de tareas remotas se pone en contacto 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 a Car Service cuando se completa la tarea.
Si es necesario, el Car Service restablece el estado de energía del vehículo.
Figura 3. Entregar tareas.
Escribir un cliente de tareas remotas
CarRemoteAccessManager proporciona la API para funciones de acceso remoto. Para obtener más información, consulte CarRemoteAccessManager . Un cliente de tareas remotas es un servicio de Android que ejecuta tareas remotas y utiliza CarRemoteAccessManager . Esto requiere PERMISSION_USE_REMOTE_ACCESS y PERMISSION_CONTROL_REMOTE_ACCESS y debe declarar un filtro de intención 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>
Un cliente de tarea remota 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 nulo.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Car Service gestiona 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, consulte Gestión del 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.
El siguiente ejemplo muestra cómo manejar las devoluciones de llamada 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 de proveedores
La función de acceso remoto es opcional y está deshabilitada de forma predeterminada. Para habilitar la característica, agregue 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 use el siguiente comando adb en una compilación userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Requisitos en Android
Acceso remoto HAL
La capa de abstracción de hardware de acceso remoto (HAL) 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 la función de acceso remoto no está implementada.
La interfaz se define en IRemoteAccess.aidl e incluye estos métodos:
| Clase | Descripción |
|---|---|
String getVehicleId() | Obtiene una identificación de vehículo única que puede ser reconocida por el servidor de activación. |
String getWakeupServiceName() | Obtiene el nombre del servidor de activación remoto. |
String getProcessorId() | Obtiene una ID de procesador única que se puede reconocer al despertar al 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 previamente configurada. |
void notifyApStateChange(in ApState state)Detecta si el procesador de la aplicación 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)Una devolución de llamada que se llama cuando se solicita una tarea remota. |
Véase la implementación de referencia con una TCU externa. La implementación utiliza una secuencia de lectura de larga duración para recibir tareas remotas y admite el siguiente comando debug :
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
Vehículo HAL
Para admitir la función de acceso remoto, VHAL debe admitir estas propiedades:
| Clase | Descripción |
|---|---|
SHUTDOWN_REQUEST | Solicita que se apague la unidad principal. |
VEHICLE_IN_USE |
|
Para obtener más información, consulte Propiedades del sistema admitidas .
Modo silencioso
El modo silencioso debe ser compatible con la función de acceso remoto para que el vehículo pueda arrancar en modo silencioso para 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_stateRepresenta el modo silencioso actual. | |
/sys/kernel/silent_boot/pm_silentmode_hw_stateRepresenta la señal de hardware para establecer un nuevo modo silencioso. |
El procesador del vehículo envía una señal HW al SoC de Android para activar o desactivar el modo silencioso. La señal (0 o 1) se escribe en /sys/kernel/silent_boot/pm_silentmode_hw_state . Luego, el marco AAOS actualiza /sys/kernel/silent_boot/pm_silentmode_kernel_state en consecuencia, lo que representa el modo silencioso actual. Los módulos 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 configura el modo silencioso e inicia AAOS para que el sistema se inicie con la pantalla/audio apagado.
Componentes del vehículo que no son Android
Procesador de vehículos
El procesador del vehículo es un procesador en el vehículo que puede controlar la energía del procesador de la aplicación que ejecuta Android. En la arquitectura de ejemplo, la TCU activa el procesador de la aplicación enviando una señal al procesador del vehículo.
Componentes del vehículo que no son Android
La TCU del vehículo siempre puede recibir mensajes remotos.
El cliente de reactivación se ejecuta en la TCU para garantizar una conexión duradera con el servidor de reactivació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 despertador
El servidor de activación se comunica con el cliente de activación en la TCU para:
- Mantenga una conexión duradera con la TCU del vehículo.
- Encuentre una TCU específica según la identificación de un vehículo.
- Informar el estado de un vehículo. Por ejemplo, en línea o fuera de línea, o la última vez que estuvo en línea en el servidor de tareas remoto.
En una implementación real, un servidor de activación se puede fusionar con un servidor de tareas remoto.
Servidor de tareas remoto
El servidor de tareas remoto gestiona estas tareas remotas.
El usuario interactúa con el servidor para iniciar nuevas tareas remotas y monitorear tareas remotas.
Utiliza el servidor de activación remota para activar el procesador de aplicaciones en los vehículos.
Interactúa con el cliente de tareas remotas que se ejecuta en el vehículo.
Almacena información de registro del cliente. Esto asocia un usuario específico a un cliente de tarea remota específico en un vehículo específico.
Normalmente, 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 remotas son simplemente una ID de tarea. El cliente de tareas remotas utiliza el ID de la tarea para obtener información detallada del servidor de tareas remoto.
Requisitos de privacidad y seguridad
| Tarea | Condición | Requisito |
|---|---|---|
| TCU (cliente de activación) | DEBE |
|
| servidor de despertador | DEBE |
|
| Cliente de tareas remotas | DEBE |
|
| Servidor de tareas remoto | DEBE |
|
Restablecimiento de fábrica y transferencia de propiedad
Si un usuario realiza un restablecimiento de fábrica, se borra la identificación del cliente almacenada en el Servicio de automóvil. Sin embargo, los servidores (servidor de tareas remoto y servidor de activación remota) no están informados. Los servidores conservan una asignación de la identificación del cliente ahora caducada al vehículo. Como resultado, si el usuario inicia una nueva tarea remota para el vehículo, utiliza la ID de cliente caducada. El vehículo se activa, pero la tarea remota no se puede ejecutar porque el cliente de la tarea remota tiene una ID de cliente diferente que no coincide.
A continuación se describe una posible implementación para un restablecimiento de fábrica.
Cuando un usuario realiza un restablecimiento de fábrica, el proveedor le solicita que inicie sesión en el servidor de tareas remoto y desvincule el vehículo de su cuenta si el usuario ya lo ha vinculado previamente. No se garantiza que el dispositivo tenga acceso a la red durante el tiempo de restablecimiento de fábrica. Por lo tanto, es posible que no sea factible emitir la solicitud de desvinculación en el momento del restablecimiento de fábrica del dispositivo.
Siempre que se transfiere la propiedad de un vehículo, se deben realizar algunas operaciones para garantizar que el propietario anterior ya no pueda realizar tareas remotas al vehículo. Por ejemplo, se le puede pedir al nuevo propietario que:
Realice un restablecimiento de fábrica. Esto garantiza que se vuelva a generar el ID del cliente. Después de este paso, el propietario anterior aún puede reactivar el vehículo, pero ya no puede ejecutar tareas remotas.
Abra la aplicación cliente de tareas remotas y siga el proceso Anular 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 previamente vinculada.
El nuevo propietario puede utilizar el proceso Registrar un cliente para vincular el vehículo a su cuenta y reemplazar la cuenta previamente vinculada.
Pruebe el cliente de tareas remotas
Proporcionamos el directorio default HAL de acceso remoto de referencia para probar clientes de tareas remotas. Puede utilizar el siguiente comando debug para inyectar una tarea remota falsa en HAL, que se reenvía a su cliente de tareas remotas si proporciona la ID de cliente correcta. Puede 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]