Configurer l'accès à distance

Android 14 introduit la nouvelle fonctionnalité d'accès à distance, qui permet aux partenaires de réactiver à distance Android dans un véhicule pour exécuter des tâches spécifiques. Par exemple, pour exécuter le mode Garage pendant la nuit afin d'appliquer les mises à jour logicielles. Plusieurs composants non Android sont nécessaires pour le workflow de bout en bout. Android ne définit ni ne fournit d'implémentation pour les composants non Android (cette responsabilité vous incombe).

Pour en savoir plus, consultez les sections suivantes :

• Workflow. Workflow entre plusieurs composants de l'architecture exemple pour l'enregistrement du client et la distribution des tâches.

• Écrivez un client de tâches à distance. Utilisez l'accès à distance et découvrez comment écrire un client de tâches à distance.

• Implémentation par le fournisseur : Composants du fournisseur dans l'architecture de l'exemple pour prendre en charge l'accès à distance.

• Rétablissement de la configuration d'usine et transfert de propriété Découvrez comment gérer la réinitialisation des paramètres d'usine et le transfert de propriété du véhicule.

• Testez le client d'accès à distance. Découvrez comment tester la fonctionnalité d'accès à distance.

Architecture

Le contenu suivant suppose que l'architecture d'exemple suivante est utilisée. Elle est hypothétique et peut ne pas refléter l'architecture réelle. Les OEM doivent adapter une implémentation réelle à leurs architectures de véhicule et de serveur.

Figure 1 : Exemple d'architecture.

L'exemple d'architecture se compose des composants matériels suivants :

L'exemple d'architecture se compose des composants logiciels suivants, qui s'exécutent tous sur Android :

Les composants logiciels non Android sont décrits ci-dessous :

Workflow

Cette section liste les étapes d'un exemple de workflow.

Exemple de workflow

Un workflow détaillé peut ressembler à ce qui suit :

1. L'utilisateur gare le véhicule dans le garage.

2. Le partenaire cherche à mettre à jour le véhicule pendant la nuit, lorsque les interactions avec le véhicule sont peu probables.

3. Le serveur cloud du partenaire envoie une tâche à distance de mise à jour du système au véhicule. Plus précisément, l'unité de commande télématique (TCU).

4. La TCU du véhicule réveille l'unité de commande électronique (ECU) Android et un service OEM déclenche le mode Garage.

5. Android exécute le mode Garage pour télécharger et installer les mises à jour via Google Play.

6. Après avoir appliqué la mise à jour, Android marque la tâche comme terminée et met fin à la connexion ou atteint un délai d'expiration spécifié.

Procédure détaillée

Deux étapes importantes sont nécessaires pour l'accès à distance. La première consiste à enregistrer le client, c'est-à-dire à associer un utilisateur spécifique à un client de tâche à distance spécifique exécuté sur un véhicule spécifique. L'autre consiste à exécuter une tâche, c'est-à-dire à exécuter la tâche à distance pour un utilisateur spécifique sur le client de tâche à distance spécifique qui s'exécute sur le véhicule spécifique.

Enregistrer un client

Pour utiliser la fonctionnalité d'accès à distance, un utilisateur doit ouvrir l'application cliente de tâches à distance au moins une fois et terminer le processus d'enregistrement du client (le texte en gras indique les tâches implémentées par AAOS) :

1. Au démarrage, Car Service obtient les informations sur le véhicule à partir du HAL d'accès à distance.

2. Au démarrage, Car Service lance tous les clients de tâches à distance en fonction du filtre d'intent et de l'autorisation.

3. Au démarrage du client de tâches à distance, celui-ci s'enregistre auprès du service automobile.

4. Car Service informe le client de la tâche à distance des informations d'enregistrement, y compris l'ID du véhicule et l'ID du client. L'ID client est unique et attribué par Car Service à ce client. Il est garanti d'être unique parmi tous les clients de tâches à distance sur le même véhicule.

5. L'utilisateur se connecte au serveur de tâches à distance via le client de tâches à distance et active la fonctionnalité d'accès à distance pour ce véhicule. Cette étape implique généralement une authentification via le serveur de tâches à distance.

6. Le client de tâches à distance importe les informations de l'utilisateur, ainsi que l'ID du véhicule et l'ID du client, sur le serveur de tâches à distance et lui demande d'associer l'utilisateur à ce client et à ce véhicule spécifiques.

   Cette étape peut éventuellement impliquer une authentification à deux facteurs supplémentaire de la part de l'utilisateur.

   Le serveur de tâches à distance doit authentifier que l'ID du véhicule fourni dans la requête correspond à l'ID du véhicule de l'expéditeur, ce qui peut être fait par le biais de l'attestation du véhicule.

Sauf si un rétablissement de la configuration d'usine est effectué, le processus d'enregistrement du client est requis une fois par utilisateur et par véhicule. L'ID client est stocké localement dans le service automobile et reste le même pour le même client.

Figure 2. Enregistrez un client.

Annuler l'enregistrement d'un client

Un utilisateur peut dissocier le véhicule de son compte depuis le véhicule ou depuis le serveur de tâches à distance :

• Sur le véhicule, les utilisateurs peuvent ouvrir l'application cliente de tâches à distance et envoyer une demande de dissociation pour dissocier ce véhicule de ses comptes utilisateur précédemment associés.

• Sur le serveur de tâches à distance, les utilisateurs peuvent se connecter à leur compte et dissocier un véhicule précédemment associé à ce compte.

Si l'utilisateur dissocie le véhicule de son compte, le serveur de tâches à distance doit supprimer le mappage stocké pour cet utilisateur spécifique.

Envoyer des tâches

Dans le cloud :

1. Un utilisateur utilise le serveur de tâches à distance pour envoyer une tâche à distance à un véhicule spécifique.

2. Le serveur de tâches à distance mappe l'ID utilisateur sur l'ID du véhicule et l'ID client. Il envoie les données de la tâche, l'ID du véhicule et l'ID du client au serveur de sortie de veille.

3. Le serveur de réveil trouve le TCU spécifique à l'ID du véhicule (en supposant que l'enregistrement du TCU est déjà effectué) et envoie les données de la tâche et l'ID client au TCU.

Sur le véhicule (le texte en gras indique les tâches effectuées par AAOS) :

1. La TCU reçoit des tâches à distance du serveur distant.

2. Si le processeur d'application (AP) exécutant AAOS est éteint, l'unité de commande télématique (TCU) utilise le processeur du véhicule (VP) pour réactiver l'AP.

3. Le service de voiture reçoit des tâches de l'unité de commande télématique.

4. Car Service distribue les tâches au client de tâches à distance correspondant.

5. Le client de tâches à distance reçoit et exécute la tâche.

   (Facultatif) Le client de tâches à distance contacte le serveur de tâches pour obtenir plus de détails sur la tâche et l'exécute.

6. (Facultatif) Le service client de la tâche à distance signale le résultat de la tâche au serveur de tâches.

7. Le client de tâches à distance avertit le service automobile lorsque la tâche est terminée.

8. Si nécessaire, le service automobile restaure l'état d'alimentation du véhicule.

Figure 3. effectuer des tâches ;

Écrire un client de tâches à distance

CarRemoteAccessManager fournit l'API pour les fonctionnalités d'accès à distance. Pour en savoir plus, consultez CarRemoteAccessManager. Un client de tâches à distance est un service Android qui exécute des tâches à distance et utilise CarRemoteAccessManager. Cela nécessite PERMISSION_USE_REMOTE_ACCESS et PERMISSION_CONTROL_REMOTE_ACCESS, et doit déclarer un filtre d'intent pour RemoteTaskClientService, par exemple :

<service android:name=".remoteaccess.RemoteTaskClientService"
         android:directBootAware="true"
         android:exported="true">
    <intent-filter>
       <action android:name="android.car.remoteaccess.RemoteTaskClientService" />
    </intent-filter>
</service>

Un client de tâches à distance doit s'enregistrer auprès du service automobile lors de la création :

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);
    }
}

Elle doit remplacer la fonction onBind pour renvoyer la valeur "null".

@Override
public IBinder onBind(Intent intent) {
    return null;
}

Car Service gère son cycle de vie. Car Service se lie à ce service au démarrage et lorsqu'une tâche à distance arrive. CarService se dissocie de ce service une fois la tâche terminée. Pour en savoir plus, consultez Gérer le cycle de vie d'un service.

Le client de tâches à distance s'exécute en tant qu'utilisateur système. Il n'a donc accès à aucune donnée spécifique à l'utilisateur.

L'exemple suivant montre comment gérer les rappels enregistrés :

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();
    }
}

Implémentation par le fournisseur

La fonctionnalité d'accès à distance est facultative et désactivée par défaut. Pour activer la fonctionnalité, ajoutez un RRO comme suit :

// 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
}

Vous pouvez également utiliser la commande adb suivante sur une version userdebug/eng :

adb shell cmd car_service enable-feature car_remote_access_service

Exigences sur Android

HAL d'accès à distance

La couche d'abstraction matérielle (HAL) pour l'accès à distance est une couche d'abstraction implémentée par le fournisseur pour la communication entre AAOS et un autre calculateur (par exemple, un TCU). Il est obligatoire pour prendre en charge la fonctionnalité d'accès à distance. Il n'est pas nécessaire de l'implémenter si la fonctionnalité d'accès à distance n'est pas implémentée.

L'interface est définie dans IRemoteAccess.aidl et inclut les méthodes suivantes :

L'interface de rappel est définie dans IRemoteTaskCallback.aid.

Consultez l'implémentation de référence avec une TCU externe. L'implémentation utilise un flux de lecture de longue durée pour recevoir les tâches à distance et est compatible avec la commande debug suivante :

dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default

HAL véhicule

Pour que la fonctionnalité d'accès à distance soit prise en charge, VHAL doit accepter les propriétés suivantes :

Pour en savoir plus, consultez Propriétés système compatibles.

Mode silencieux

Le mode silencieux doit être compatible avec la fonctionnalité d'accès à distance afin que le véhicule puisse démarrer en mode silencieux pour exécuter des tâches à distance en l'absence d'utilisateur. En mode silencieux, l'appareil AAOS démarre avec l'écran et le son désactivés.

Le mode silencieux est contrôlé par deux fichiers sysfs du noyau Linux.

Le processeur du véhicule envoie un signal matériel au SoC Android pour activer ou désactiver le mode silencieux. Le signal (0 ou 1) est écrit dans /sys/kernel/silent_boot/pm_silentmode_hw_state. Le framework AAOS met ensuite à jour /sys/kernel/silent_boot/pm_silentmode_kernel_state en conséquence, ce qui représente le mode silencieux actuel. Les modules AAOS vérifient /sys/kernel/silent_boot/pm_silentmode_kernel_state pour savoir si le système est en mode silencieux ou non.

Lorsqu'une tâche à distance est reçue et qu'AAOS démarre, le processeur du véhicule définit le mode silencieux et démarre AAOS afin que le système démarre avec l'écran et l'audio désactivés.

Composants non Android embarqués

Processeur du véhicule

Le processeur du véhicule est un processeur intégré au véhicule qui peut contrôler l'alimentation du processeur de l'application exécutant Android. Dans l'exemple d'architecture, la TCU réveille le processeur d'application en envoyant un signal au processeur du véhicule.

Composants non Android embarqués

La TCU du véhicule peut toujours recevoir des messages à distance.

Le client de réveil s'exécute sur l'unité de commande télématique (TCU) pour assurer une connexion durable avec le serveur de réveil à distance.

AAOS exécuté sur l'AP peut communiquer avec le client de réveil exécuté sur l'unité de contrôle télématique (TCU) via le HAL d'accès à distance.

Figure 4. TCU (client de réveil).

Composants dans le cloud

Serveur de réveil

Le serveur de réveil communique avec le client de réveil sur l'unité de commande télématique (TCU) pour :

• Maintenez une connexion durable avec l'unité de commande télématique du véhicule.
• Recherchez une unité de commande télématique spécifique en fonction de l'ID d'un véhicule.
• Signaler l'état d'un véhicule. Par exemple, l'état en ligne ou hors connexion, ou la dernière heure de connexion au serveur de tâches à distance.

Dans une implémentation réelle, un serveur de réveil peut être fusionné avec un serveur de tâches à distance.

Serveur de tâches à distance

Le serveur de tâches à distance gère ces tâches.

• L'utilisateur interagit avec le serveur pour démarrer de nouvelles tâches à distance et les surveiller.

• Utilise le serveur de réveil à distance pour réveiller le processeur d'application dans les véhicules.

• Interagit avec le client de tâches à distance exécuté sur le véhicule.

• Stocke les informations d'enregistrement du client. Cela permet d'associer un utilisateur spécifique à un client de tâche à distance spécifique sur un véhicule spécifique.

En règle générale, les données de tâche qui sont envoyées via le serveur de tâches à distance au serveur de réveil, à l'unité de commande télématique du véhicule et, enfin, au client de tâches à distance sont simplement un ID de tâche. Le client de tâches à distance utilise l'ID de tâche pour récupérer les informations détaillées auprès du serveur de tâches à distance.

Exigences de confidentialité et de sécurité

Rétablir la configuration d'usine et transférer la propriété

Si un utilisateur rétablit la configuration d'usine, l'ID client stocké dans le service automobile est effacé. Toutefois, les serveurs (serveur de tâches à distance et serveur de sortie de veille à distance) ne sont pas informés. Les serveurs conservent un mappage entre l'ID client désormais expiré et le véhicule. Par conséquent, si l'utilisateur démarre une nouvelle tâche à distance pour le véhicule, il utilise l'ID client expiré. Le véhicule est réveillé, mais la tâche à distance ne peut pas être exécutée, car le client de la tâche à distance possède un ID client différent qui ne correspond pas.

Vous trouverez ci-dessous une implémentation possible pour le rétablissement de la configuration d'usine.

Lorsqu'un utilisateur effectue une réinitialisation d'usine, le fournisseur l'invite à se connecter au serveur de tâches à distance et à dissocier le véhicule de son compte s'il l'a déjà associé. L'accès au réseau n'est pas garanti pendant le rétablissement de la configuration d'usine. Par conséquent, il n'est peut-être pas possible d'envoyer la demande de dissociation au moment du rétablissement de la configuration d'usine de l'appareil.

Chaque fois que la propriété d'un véhicule est transférée, certaines opérations doivent être effectuées pour s'assurer que l'ancien propriétaire ne peut plus émettre de tâches à distance pour le véhicule. Par exemple, le nouveau propriétaire peut être invité à :

• Rétablissez la configuration d'usine. Cela permet de régénérer l'ID client. Après cette étape, l'ancien propriétaire peut toujours sortir le véhicule du mode veille, mais ne peut plus exécuter de tâches à distance.

• Ouvrez l'application cliente de tâches à distance et suivez la procédure Désenregistrer un client pour dissocier le véhicule du compte de l'ancien propriétaire. Le nouveau propriétaire peut suivre la procédure d'enregistrement d'un client pour associer le véhicule à son compte et remplacer le compte précédemment associé.

• Le nouveau propriétaire peut utiliser la procédure Enregistrer un client pour associer le véhicule à son compte et remplacer le compte précédemment associé.

Tester le client de tâches à distance

Nous fournissons le répertoire HAL d'accès à distance de référence default pour tester les clients de tâches à distance. Vous pouvez utiliser la commande debug suivante pour injecter une fausse tâche à distance dans le HAL, qui est transférée à votre client de tâches à distance si vous fournissez le bon ID client. Vous pouvez obtenir l'ID client en enregistrant les informations d'enregistrement dans l'implémentation de votre client de tâches à distance.

adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]