Configura el acceso remoto

Nota: Para implementar esta función, debes habilitarla. Para obtener más información, consulta Implementación de proveedores.

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 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 implementaciones para componentes que no sean de Android (esta responsabilidad es tuya).

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 remoto. Usa el acceso remoto y aprende a escribir un cliente de tareas remoto.

• Implementación del proveedor: Componentes del proveedor en la arquitectura de muestra para admitir el acceso remoto.

• Restablecer la configuración de fábrica y la transferencia de propiedad. Obtén información para realizar el restablecimiento de la configuración de fábrica y la transferencia de la propiedad del vehículo.

• Prueba el cliente de acceso remoto. Obtén información para probar la función de acceso remoto.

Arquitectura

En el siguiente contenido, se supone que se usa la siguiente arquitectura de ejemplo, que es hipotética y podría no reflejar la arquitectura real. Los OEM deben adaptar una implementación real a 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 puede ejecutarse en memoria virtual (VM) (no en hardware real) en este procesador.
Procesador del vehículo	Es el procesador responsable de controlar la energía del procesador de la app.
Unidad de control de telemática (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 baja energía. Usa mensajes remotos para activar la TCU.
Servidor de activación	Es 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 las personas y administra las tareas remotas.

La arquitectura de ejemplo consta de los siguientes componentes de software, que se ejecutan en Android:

Componente de software integrado en Android	Descripción
Servicio de autos	Es un servicio del framework de AAOS que proporciona APIs de acceso remoto.
Cliente de tarea remota	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 que 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 de servidor de activación	Es el 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	Servidor que administra 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 ser similar al siguiente:

1. El usuario estaciona el vehículo en el garaje.

2. El socio intenta actualizar el vehículo durante la noche cuando es poco probable que haya interacciones con él.

3. El servidor en la nube del socio envía una tarea remota de actualización del sistema al vehículo. Específicamente, la unidad de control telemático (TCU).

4. El TCU del vehículo activa la unidad de control electrónico (ECU) de Android y un servicio del OEM activa el modo cochera.

5. Android ejecuta el modo garaje para descargar e instalar actualizaciones a través de Google Play.

6. Después de aplicar la actualización, Android marca la tarea como completa y finaliza la conexión o alcanza un tiempo de espera especificado.

Flujo de trabajo detallado

Existen dos pasos importantes para el acceso remoto. El primero es registrar el cliente, que consiste en vincular un usuario específico a un cliente de tareas remoto específico que se ejecuta en un vehículo específico. La otra es entregar una tarea, que consiste en entregar la tarea remota de un usuario específico al cliente de tareas remotas 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 cliente de tareas remotas al menos una vez y finalizar el proceso de registro del cliente (el texto en negrita indica las tareas que implementa AAOS):

1. Durante el inicio, el servicio para vehículos obtiene información del vehículo desde el HAL de acceso remoto.

2. Durante el arranque, Car Service inicia todos los clientes de tareas remotas según el filtro de intents y el permiso.

3. Cuando se inicia el cliente de tareas remotas, este se registra con el servicio de Car.

4. Car Service notifica al cliente de tareas remotas sobre la información de registro, incluido el ID del vehículo y el ID del cliente. El ID de cliente es único y Car Service lo asigna a este cliente. Se garantiza que sea único entre todos los clientes de tareas remotas en el mismo vehículo.

5. 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.

6. El cliente de tarea remota 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 solicita que vincule al usuario con este cliente y vehículo específicos.

   De manera opcional, este paso puede 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 coincide con el ID del vehículo del remitente, lo que se puede hacer mediante la certificación del vehículo.

   Nota: Un usuario puede tener varios vehículos. Una base de datos de muestra en el servidor de tareas remoto podría usar [userID, vehicleID] como clave y [client ID] como valor.

A menos que se realice un restablecimiento de la configuración de fábrica, el proceso de registro del cliente es obligatorio una vez por usuario y por vehículo. El ID de cliente se almacena de forma local en el servicio de automóviles y permanece igual 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, ya sea del vehículo o del servidor de tareas remoto:

• En el vehículo, los usuarios pueden abrir la app cliente de tareas remotas y emitir una solicitud de desvinculación para desvincular este vehículo de sus cuentas de usuario vinculadas anteriormente.

• En el servidor de tareas remoto, los usuarios pueden acceder a su cuenta y desvincular un vehículo vinculado anteriormente de esta cuenta.

Si el usuario desvincula el vehículo de su cuenta, el servidor de tareas remoto debe quitar la asignación almacenada para el usuario específico.

Cómo entregar tareas

En la nube:

1. Un usuario usa el servidor de tareas remoto para enviar una tarea remota a un vehículo específico.

2. El servidor de tareas remoto asigna el ID de usuario al ID del vehículo y al ID del cliente. Envía los datos de la tarea, el ID del vehículo y el ID del cliente al servidor de activación.

3. El servidor de activación encuentra la TCU específica para el ID del vehículo (suponiendo que el registro de la TCU ya está hecho) 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 el AAOS):

1. La TCU recibe tareas remotas del servidor remoto.

2. Si el procesador de apps (AP) que ejecuta AAOS está apagado, la TCU usa el procesador del vehículo (VP) para activar el AP.

3. El servicio de automóviles recibe tareas de la TCU.

4. Car Service distribuye tareas al cliente de tareas remoto correspondiente.

5. 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 y ejecuta la tarea.

6. (Opcional) El servicio de cliente de tareas remotas informa el resultado de la tarea al servidor de tareas.

7. El cliente de tareas remotas notifica al servicio de automóviles cuando se completa la tarea.

8. Si es necesario, el servicio de reparación de automóviles restablece el estado de encendido 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, como el siguiente:

<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 el servicio de automóviles 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;
}

El servicio de automóviles administra su ciclo de vida. Car Service se vincula a este servicio durante el inicio y cuando llega una tarea remota. El servicio de vehículos 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 el 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 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 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 el 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, además, incluye los siguientes métodos:

Clase	Descripción
String getVehicleId()	Obtiene un ID de vehículo único que el servidor de activación puede reconocer.
String getWakeupServiceName()	Obtiene el nombre del servidor de activación remoto.
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 a la 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 a la 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 unidad principal.
VEHICLE_IN_USE	Detecta si el vehículo está en uso. Después de que el usuario desbloquea el vehículo o cuando se acerca a él. Debe ser true. Es un tiempo específico después de que el usuario apaga el vehículo o cuando lo bloquea. Debe ser false. Cuando true, AAOS no intenta apagar el vehículo cuando se completa la tarea remota.

Para obtener más información, consulta Propiedades de sistema compatibles.

Modo silencioso

El modo silencioso debe ser compatible con la función de acceso remoto para que el vehículo se pueda iniciar 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 la señal de hardware para configurar un nuevo modo silencioso.

El procesador del vehículo envía una señal 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 AAOS verifican /sys/kernel/silent_boot/pm_silentmode_kernel_state para saber si el sistema está en modo silencioso.

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 o el audio apagados.

Componentes que no son de Android en el vehículo

Procesador del vehículo

El procesador del vehículo es un procesador que puede controlar la energía del procesador de la app que ejecuta Android. En la arquitectura de ejemplo, TCU activa el procesador de la app enviando una señal al procesador del vehículo.

Componentes que no son de 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.

Los AAOS que se ejecutan en el AP pueden comunicarse con el cliente de activación que se ejecuta en la 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:

• Mantener una conexión duradera con la TCU del vehículo
• Busca una TCU específica 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 el último tiempo en línea en el 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 remoto

El servidor de tareas remotas administra estas tareas.

• El usuario interactúa con el servidor para iniciar tareas remotas nuevas y supervisarlas.

• Usa el servidor de activación remoto para activar el procesador de la app en los vehículos.

• Interactúa con el cliente de tareas remoto 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 tarea para recuperar la información detallada del servidor de tareas remoto.

Requisitos de privacidad y seguridad

Importante: El AAOS no procesa datos de tareas, no almacena datos de tareas, proporciona autenticación de usuario ni proporciona certificación de dispositivo. Todos los componentes de los proveedores son fundamentales para la privacidad y la seguridad. En el caso de la arquitectura de ejemplo, los proveedores deben cumplir con los siguientes requisitos. Esta lista no es exhaustiva.

Tarea	Condition	Requisito
TCU (cliente de activación)	DEBER	Autentica el servidor de activación. Confía en el código.
Servidor de activación	DEBER	Permite que solo se conecten los servidores de tareas remotos incluidos en la lista de entidades permitidas. Autentica el cliente de activación. Envía el mensaje de activación solo al vehículo de destino.
Cliente de tareas remotas	DEBEN	Autentica al usuario durante el registro. Autentica el servidor de tareas remoto. Cumple con todos los requisitos de seguridad de un servicio de Android. Por ejemplo, permisos limitados.
Servidor de tareas remoto	DEBEN	Debes autenticar el servidor de activación. Proporciona la certificación del vehículo. Es decir, autentica que el ID del vehículo proporcionado en la solicitud coincida con el ID del vehículo del remitente. Si no es posible la certificación del vehículo, se deben usar otros medios para verificar que el usuario es el propietario actual del vehículo. Autentica la identidad del usuario. Cumplir con todos los requisitos de seguridad de un servidor que maneja información del usuario

Restablecimiento de la configuración de fábrica y transferencia de la propiedad

Si un usuario restablece la configuración de fábrica, se borra el ID de cliente almacenado en el servicio de vehículos. Sin embargo, no se informa a los servidores (servidor de tareas remoto y servidor de activación remoto). Los servidores retienen una asignación del ID de cliente ahora vencido al vehículo. Como resultado, si el usuario inicia una nueva tarea remota para el vehículo, se usa el ID de cliente vencido. Se activa el vehículo, pero no se puede ejecutar la tarea remota 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 restablecer la configuración de fábrica.

Cuando un usuario realiza un restablecimiento de 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 lo vinculó anteriormente. 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 se pueda emitir la solicitud de desvinculación durante el restablecimiento de la configuración de fábrica desde el dispositivo.

Cuando 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 remotas.

• Abre la app cliente de tarea remota y sigue el proceso para cancelar el registro de un cliente para desvincular el vehículo de la cuenta del propietario anterior. El propietario nuevo puede seguir el proceso para registrar un cliente y vincular el vehículo a su cuenta y reemplazar la cuenta vinculada anteriormente.

• El propietario nuevo 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 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. Para obtener el ID del cliente, registra 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]