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 su ejecución tareas específicas. Por ejemplo, para ejecutar Modo garaje durante la noche para aplicar el software actualizaciones. Se requieren varios componentes que no sean Android para la implementación en el flujo de trabajo. Android no define ni proporciona implementación para aplicaciones que no sean Android componentes (esta responsabilidad te pertenece).
Para obtener más información, consulta las siguientes secciones:
Flujo de trabajo. Flujo de trabajo entre varios componentes de la muestra arquitectura para el registro de clientes y la entrega de tareas.
Escribe un cliente de tareas remotas. Usar el acceso remoto y aprenderemos a escribir un cliente de tareas remotas.
Implementación de proveedores. de proveedores en la arquitectura de muestra para admitir el acceso remoto.
Restablecer la configuración de fábrica y la transferencia de propiedad. Aprender a manejar restablecer la configuración de fábrica y transferir la propiedad del vehículo.
Prueba el cliente de acceso remoto. Más información para probar el acceso remoto .
Arquitectura
El siguiente contenido presupone que se usa la siguiente arquitectura de muestra, que es hipotética y puede no reflejar la arquitectura real. Los OEMs deben adaptarse una implementación real en sus arquitecturas de 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 apps | Procesador que ejecuta Android. Android podría ejecutarse en memoria virtual (VM) (no en hardware real) en este procesador. |
| Procesador de vehículos | Procesador responsable de controlar el encendido de la app y un encargado del tratamiento de datos. |
| Unidad de control de telemática (TCU) | El procesador del vehículo siempre es capaz de recibir mensajes remotos de en la nube. Se presume que la TCU está siempre encendida o en modo de bajo consumo. Usa y enviar mensajes remotos para activar el TCU. |
| Servidor de activación | Un servidor remoto que se ejecuta en la nube y es responsable de comunicándose con el TCU del vehículo para emitir comandos de activación. |
| Servidor de tareas remoto | El servidor de tareas remoto se ejecuta en la nube e interactúa con personas y administra tareas remotas. |
La arquitectura de muestra consta de estos componentes de software, todos que se ejecutan en Android:
| Componente de software en Android | Descripción |
|---|---|
| Servicio de autos | Servicio de framework de AAOS que proporciona APIs de acceso remoto. |
| Cliente de tarea remota | Una evaluación escrita por el proveedor
Service
que ejecuta tareas remotas. Un sistema Android puede ejecutar varias
tareas remotas y 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 una plataforma que no sea Android como TCU. |
A continuación, se describen los componentes de software que no es de Android:
| Componente de software que no es de Android | Descripción |
|---|---|
| Activar cliente | Es software que se ejecuta en TCU y que mantiene una conexión de larga duración con el del servidor de activación. También mantiene una conexión con la HAL de acceso remoto. para entregar tareas remotas al servicio de vehículos. |
| Implementación de servidor de activación | Servidor que se comunica con el cliente de activación que se ejecuta en TCU. Lata envía solicitudes de activación al cliente de activación. |
| Implementación de servidor de tareas remoto | Servidor que administra tareas remotas. Los usuarios interactúan con este servidor para problemas y supervisar las tareas remotas. |
Flujo de trabajo
En esta sección, se enumeran 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 las interacciones entre este es poco probable.
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).
El TCU del vehículo activa la unidad de control electrónico (ECU) de Android y un servicio de 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 especificado.
Flujo de trabajo detallado
Se requieren dos pasos importantes para el acceso remoto. La primera es registrar el cliente, que es vincular a un usuario específico a un recurso remoto específico cliente de tareas que se ejecuta en un vehículo específico. El otro es entregar una tarea, que es entregar la tarea remota para un usuario específico a la tarea remota específica cliente que se ejecuta en el vehículo específico.
Registra un cliente
Para usar la función de acceso remoto, un usuario debe abrir el cliente de tareas remotas al menos una vez y finalizar el proceso de registro de clientes (texto en negrita). indica las tareas implementadas por AAOS):
Durante el arranque, Car Service obtiene información del vehículo desde el acceso remoto HAL.
Durante el arranque, Car Service inicia todos los clientes de tareas remotas según el filtro de intents y el permiso.
Cuando se inicia el cliente de tarea remota, el cliente de tarea remota se registra con el Servicio de Automóviles.
Car Service notifica al cliente de tareas remotas sobre el registro información, como el ID del vehículo y el ID de cliente. El ID de cliente es único y Car Service que lo asigna a este cliente. Se garantiza que sea único entre todos los clientes de tareas remotas en el mismo vehículo.
El usuario accede al servidor de tareas remotas a través del cliente de tareas remotas y habilita la función de acceso remoto para este vehículo. En este paso, por lo general, 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 de cliente al servidor de tareas remoto y le pide que vincule al usuario con este cliente específico y este vehículo en particular.
De manera opcional, este paso podría implicar una autenticación de dos factores adicional del usuario.
El servidor de tareas remotas debe autenticar que el ID del vehículo proporcionado en la solicitud coincida con el ID de vehículo del remitente, lo que se puede hacer y la certificación de vehículos.
A menos que se restablezca la configuración de fábrica, se requiere el proceso de registro de clientes una vez por usuario y por vehículo. El ID de cliente se almacena localmente en el servicio de automóvil. y se mantiene igual para el mismo cliente.
Figura 2: Registra un cliente.
Cómo cancelar el registro de un cliente
Un usuario puede desvincular el vehículo de su cuenta, ya sea del vehículo o de el servidor de tareas remoto:
En el vehículo, los usuarios pueden abrir la app cliente de tareas remotas y emitir el problema. una solicitud de desvinculación para desvincular este vehículo del usuario vinculado anteriormente cuentas de servicio.
En el servidor de tareas remoto, los usuarios pueden acceder a su cuenta y desvincularse un vehículo vinculado anteriormente con esta cuenta.
Si el usuario desvincula el vehículo de su cuenta, el servidor de tareas remoto debe eliminar la asignación almacenada para el usuario específico.
Entregar tareas
En la nube:
Un usuario utiliza el servidor de tareas remotas para enviar una tarea remota a un usuario específico vehículo.
El servidor de tareas remotas asigna el ID de usuario al ID del vehículo y al ID de cliente. Integra envía los datos de la tarea, el ID del vehículo y el ID de cliente al servidor de activación.
El servidor de activación busca el TCU específico para el ID del vehículo (suponiendo que el el registro de la TCU ya finalizó) y envía los datos de la tarea y el ID de cliente a el TCU.
En el vehículo (el texto en negrita indica las tareas que realizó AAOS):
La TCU recibe tareas remotas del servidor remoto.
Si el procesador de la aplicación (AP) que ejecuta AAOS está desactivado, el TCU utiliza el un procesador de vehículos (VP) para activar el PA.
Car Service recibe tareas de TCU.
Car Service distribuye las tareas al cliente de tareas remotas correspondiente.
El cliente de tarea remota recibe y ejecuta la tarea.
(Opcional) Tarea remota del cliente de contactos del servidor de tareas para obtener más detalles de la tarea y ejecuta la tarea.
El servicio de cliente de tareas remotas informa el resultado de la tarea al servidor de tareas (opcional).
El cliente de tarea remota notifica al servicio de vehículos cuando se completa la tarea.
De ser necesario, el servicio de automóvil restablece el estado de potencia del vehículo.
Figura 3: Entregar tareas
Escribe un cliente de tareas remotas
CarRemoteAccessManager proporciona la API para las funciones de acceso remoto. Para aprender
más, consulta
CarRemoteAccessManager;
Un cliente de tareas remotas 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, por ejemplo:
<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 debería registrarse en el servicio de vehículos 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 mostrar 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 inicio y cuando llega una tarea remota. Car Service se desvinculará de este servicio cuando la tarea esté completa. Para obtener más información, consulta Administrar el ciclo de vida de un servicio.
El cliente de tarea remota se ejecuta como el usuario del sistema, por lo que no tiene acceso a cualquier dato específico del usuario.
En el siguiente ejemplo, se muestra cómo controlar 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á inhabilitada de forma predeterminada. Para habilitar el agrega una RRO como la 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
}
También puedes usar el siguiente comando adb en una compilación userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Requisitos para dispositivos Android
HAL de acceso remoto
La capa de abstracción de hardware de acceso remoto (HAL) es una implementación de abstracción para la comunicación entre AAOS y otro ECU (por ejemplo, un TCU). Es obligatorio para admitir la función de acceso remoto. No es necesario si no se implementa la función de acceso remoto.
La interfaz se define en IRemoteAccess.aidl y también incluye estos métodos:
| Clase | Descripción |
|---|---|
String getVehicleId() |
Obtiene un ID de vehículo único que puede reconocerse cuando se activa servidor. |
String getWakeupServiceName() |
Obtiene el nombre del servidor de activación remoto. |
String getProcessorId() |
Obtiene un ID del procesador único que puede reconocerse activando la 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)
Una devolución de llamada que se llama 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, la VHAL debe admitir las siguientes propiedades:
| Clase | Descripción |
|---|---|
SHUTDOWN_REQUEST |
Solicita que se apague la consola central. |
VEHICLE_IN_USE |
|
Para obtener más información, consulta Propiedades del sistema compatibles.
Modo silencioso
El modo silencioso debe ser compatible con la función de acceso remoto para que el vehículo Se puede iniciar en modo silencioso para ejecutar tareas remotas cuando no hay ningún usuario presente. Con modo silencioso, el dispositivo AAOS se inicia con la pantalla y el audio desactivados.
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 la señal de hardware para configurar un nuevo modo silencioso. |
|
El procesador del vehículo envía una señal de hardware 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 framework de AAOS actualiza
/sys/kernel/silent_boot/pm_silentmode_kernel_state según corresponda,
representa el modo silencioso actual. Verificaciones de módulos de AAOS
/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 Modo silencioso e inicia el AAOS para que el sistema se inicie con la pantalla/el audio desactivados.
Componentes en el vehículo que no son de Android
Procesador de vehículos
El procesador del vehículo es un procesador del vehículo que puede controlar la energía. para el procesador de la app que ejecuta Android. En la arquitectura de ejemplo, TCU Activa el procesador de la app enviando una señal al vehículo y un encargado del tratamiento de datos.
Componentes en el vehículo que no son de Android
El TCU del vehículo siempre puede recibir mensajes remotos.
El cliente de activación se ejecuta en la TCU para garantizar una conexión de larga duración con el un servidor de activación remoto.
El AAOS que se ejecuta en el AP puede comunicarse con el cliente de activación que se ejecuta en TCU a través de la 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 hacer lo siguiente:
- Mantén una conexión de larga duración con el TCU del vehículo.
- Encuentra un TCU específico según el ID de un vehículo.
- Informa el estado de un vehículo. Por ejemplo, en línea o sin conexión, o última tiempo en línea al servidor de tareas remoto.
En una implementación real, un servidor de activación puede combinarse con un servidor remoto servidor de tareas.
Servidor de tareas remoto
El servidor de tareas remotas administra estas tareas remotas.
El usuario interactúa con el servidor para iniciar nuevas tareas remotas y supervisar tareas remotas.
Usa el servidor de activación remoto para activar el procesador de la app los vehículos.
Interactúa con el cliente de tareas remotas que se ejecuta en el vehículo.
Almacena la información de registro de los clientes. Esto asocia un usuario específico a un cliente de tareas remotas específico en un vehículo específico.
Por lo general, son los datos de tareas que se envían a través del servidor de tareas remoto a la activación desde el servidor, hasta la TCU del vehículo y, finalmente, al cliente de tareas remotas un ID de tarea. El cliente de tarea remota usa el ID de la tarea para recuperar los datos del servidor de tareas remoto.
Requisitos de privacidad y seguridad
| Tarea | Condition | Requisito |
|---|---|---|
| TCU (cliente de activación) | DEBEN |
|
| Servidor de activación | DEBEN |
|
| Cliente de tarea remota | DEBEN |
|
| Servidor de tareas remoto | DEBEN |
|
Restablecimiento de la configuración de fábrica y transferencia de propiedad
Si un usuario realiza un restablecimiento de la configuración de fábrica, el ID de cliente almacenado en el servicio de automóvil se convierte en y se limpió. Sin embargo, los servidores (servidor de tareas remoto y servidor de activación remoto) no son no informado. Los servidores conservan una asignación del ID de cliente ahora vencido a el vehículo. Como resultado, si el usuario inicia una nueva tarea remota para el vehículo, usa el ID de cliente vencido. El vehículo se activó, pero la tarea remota no puede ejecutarse porque el cliente de tareas remotas tiene un ID de cliente diferente que no coincide.
A continuación, se describe una posible implementación para un restablecimiento de la configuración de fábrica.
Cuando un usuario restablece la configuración de fábrica, el proveedor le solicita que acceda el servidor de tareas remotas y desvincular el vehículo de su cuenta si el usuario vinculado previamente el vehículo. No se garantiza que el dispositivo tenga acceso acceso durante el restablecimiento de la configuración de fábrica. Por lo tanto, emitir la solicitud de desvinculación es posible que el dispositivo no sea factible durante el restablecimiento de la configuración de fábrica.
Cuando se transfiere la propiedad de un vehículo, se deben llevar a cabo algunas operaciones para asegurarse de que el propietario anterior ya no pueda enviar 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 del este paso, el propietario anterior aún puede activar el vehículo, pero no puede ejecutar tareas remotas durante más tiempo.
Abre la app cliente de tarea remota y sigue el Cancela el registro de un cliente para desvincular el vehículo. de la cuenta del propietario anterior. El nuevo propietario puede seguir el registro proceso del 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 lo siguiente: vincular el vehículo a su cuenta y reemplazar la cuenta vinculada anteriormente
Prueba el cliente de tareas remotas
Proporcionamos la HAL de acceso remoto de referencia
default
para probar clientes de tareas remotas. Puedes usar los siguientes debug
para insertar una tarea remota falsa en la HAL, que se reenvía a tu
tarea remota si proporcionas el ID de cliente correcto. Puedes obtener el cliente
ID mediante el registro de la información de registro en tu cliente de tareas remotas
para implementarlos.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]