Android 14 introduit la nouvelle fonctionnalité d'accès à distance, qui permet aux partenaires de réveiller Android à distance 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 autres qu'Android sont requis pour le workflow de bout en bout. Android ne définit ni ne fournit d'implémentation pour les composants autres qu'Android (c'est à vous de le faire).
Pour en savoir plus, consultez les sections suivantes:
Workflow Workflow entre plusieurs composants de l'architecture exemple pour l'enregistrement des clients 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âche à distance.
Intégration par le fournisseur Composants du fournisseur dans l'architecture 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 d'usine et le transfert de propriété d'un 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'exemple d'architecture suivant est utilisé, qui 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:
Composant matériel | Description |
---|---|
Processeur d'application | Processeur qui exécute Android. Android peut s'exécuter sur la mémoire virtuelle (VM) (et non sur le matériel réel) sur ce processeur. |
Processeur de véhicule | Processeur chargé de contrôler l'alimentation du processeur de l'application. |
Unité de contrôle télématique (TCU) | Le processeur du véhicule peut toujours recevoir des messages à distance depuis le cloud. On suppose que la TCU est toujours activée ou en mode basse consommation. Utilisez des messages à distance pour réveiller le TCU. |
Serveur de réveil | Serveur distant exécuté dans le cloud et chargé de communiquer avec la TCU du véhicule pour envoyer des commandes de réveil. |
Serveur de tâches à distance | Le serveur de tâches à distance s'exécute dans le cloud, interagit avec les utilisateurs et gère les tâches à distance. |
L'exemple d'architecture se compose des composants logiciels suivants, qui s'exécutent tous sur Android:
Composant logiciel sur Android | Description |
---|---|
Service automobile | Service de framework AAOS qui fournit des API d'accès à distance. |
Client de tâche à distance | Classe Service écrite par le fournisseur qui exécute des tâches à distance. Un système Android peut exécuter plusieurs clients de tâches à distance. |
HAL d'accès à distance | Doit être implémenté pour l'accès à distance. Couche d'abstraction pour la communication entre AAOS et un composant autre qu'Android, tel que le TCU. |
Les composants logiciels autres qu'Android sont décrits ci-dessous:
Composant logiciel autre qu'Android | Description |
---|---|
Client de réveil | Logiciel exécuté sur la TCU qui maintient une connexion longue durée avec le serveur de réveil. Il maintient également une connexion avec le HAL d'accès à distance pour transmettre des tâches à distance au service de voiture. |
Implémentation du serveur de réveil | Serveur qui communique avec le client de réveil exécuté sur la TCU. Peut envoyer des requêtes de réveil au client de réveil. |
Implémentation du serveur de tâches à distance | Serveur qui gère les tâches à distance. Les utilisateurs interagissent avec ce serveur pour exécuter et surveiller des tâches à distance. |
Workflow
Cette section liste les étapes d'un exemple de workflow.
Exemple de workflow
Un workflow détaillé peut se présenter comme suit:
L'utilisateur gare son véhicule dans un garage.
Le partenaire cherche à mettre à jour le véhicule pendant la nuit, lorsque les interactions avec le véhicule sont peu probables.
Le serveur cloud du partenaire envoie une tâche à distance de mise à jour du système au véhicule. Plus précisément, la télématique (TCU).
La TCU du véhicule réveille l'unité de contrôle électronique (ECU) Android, et un service OEM déclenche le mode Garage.
Android exécute le mode Garage pour télécharger et installer les mises à jour via Google Play.
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 avant expiration spécifié.
Procédure détaillée
Pour accéder à distance, vous devez suivre deux étapes importantes. 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 à envoyer une tâche, c'est-à-dire à envoyer la tâche à distance pour un utilisateur spécifique au client de tâche à distance spécifique exécuté 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):
Au démarrage, le service de voiture obtient les informations sur le véhicule à partir du HAL d'accès à distance.
Au démarrage, Car Service lance tous les clients de tâches à distance en fonction du filtre d'intent et de l'autorisation.
Au démarrage du client de tâche à distance, il s'enregistre auprès du service de voiture.
Le service de voiture informe le client de la tâche à distance des informations d'enregistrement, y compris l'ID du véhicule et l'ID 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 du même véhicule.
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 distant.
Le client de tâche à distance importe les informations de l'utilisateur, ainsi que l'ID du véhicule et l'ID client sur le serveur de tâche à 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 vérifier 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 effectué via une attestation de véhicule.
Sauf en cas de réinitialisation d'usine, le processus d'enregistrement du client est obligatoire une fois par utilisateur et par véhicule. L'ID client est stocké localement dans le service de voiture et reste le même pour un même client.
Figure 2. Enregistrez un client.
Désenregistrer un client
Un utilisateur peut dissocier le véhicule de son compte depuis le véhicule ou 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 l'utilisateur spécifique.
Effectuer des tâches
Dans le cloud:
Un utilisateur utilise le serveur de tâches à distance pour envoyer une tâche à distance à un véhicule spécifique.
Le serveur de tâches à distance met en correspondance l'ID utilisateur avec 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 client au serveur de réveil.
Le serveur de réveil recherche la TCU spécifique à l'ID du véhicule (en supposant que l'enregistrement de la TCU est déjà effectué) et envoie les données de tâche et l'ID client à la TCU.
Sur le véhicule (le texte en gras indique les tâches effectuées par AAOS):
Le TCU reçoit des tâches à distance du serveur distant.
Si le processeur d'application (AP) exécutant AAOS est désactivé, la TCU utilise le processeur du véhicule (VP) pour réveiller l'AP.
Le service de voiture reçoit des tâches de la part de la TCU.
Car Service distribue les tâches au client de tâches distant correspondant.
Le client de tâche à distance reçoit et exécute la tâche.
(Facultatif) Le client de tâche à distance contacte le serveur de tâches pour en savoir plus sur la tâche et l'exécute.
(Facultatif) Le service client de la tâche à distance signale le résultat de la tâche au serveur de tâches.
Le client de tâche à distance informe Car Service lorsque la tâche est terminée.
Si nécessaire, le service de voiture restaure l'état de l'alimentation du véhicule.
Figure 3. effectuer des tâches ;
Écrire un client de tâche à distance
CarRemoteAccessManager
fournit l'API pour les fonctionnalités d'accès à distance. Pour en savoir plus, consultez CarRemoteAccessManager.
Un client de tâche à 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 vous devez 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âche à distance doit s'enregistrer auprès du service de voiture 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);
}
}
Il doit remplacer la fonction onBind pour renvoyer null.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Car Service gère son cycle de vie. Le service de voiture se lie à ce service au démarrage et lorsqu'une tâche distante arrive. Le service de voiture se dissocie de ce service une fois la tâche terminée. Pour en savoir plus, consultez la section 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 pas accès à des données spécifiques à 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 tel que celui-ci:
// 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 un build 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 d'accès à distance (HAL) est une couche d'abstraction implémentée par le fournisseur pour la communication entre l'AAOS et un autre ECU (par exemple, un TCU). Il est obligatoire pour prendre en charge la fonctionnalité d'accès à distance. Il n'a pas besoin d'être implémenté 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:
Classe | Description |
---|---|
String getVehicleId() |
Récupère un ID de véhicule unique qui peut être reconnu par le serveur de réveil. |
String getWakeupServiceName() |
Récupère le nom du serveur de réveil à distance. |
String getProcessorId() |
Récupère un ID de processeur unique qui peut être reconnu en réveillant le client. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Définit un rappel à appeler lorsqu'une tâche distante est demandée. |
|
void clearRemoteTaskCallback() |
Efface un rappel de tâche à distance précédemment défini. |
void notifyApStateChange(in ApState state)
Détecte si le processeur de l'application est prêt à recevoir des tâches à distance. |
L'interface de rappel est définie à IRemoteTaskCallback.aid
.
Classe | Description |
---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Rappel appelé lorsqu'une tâche distante est demandée. |
Consultez la implémentation de référence avec un TCU externe. L'implémentation utilise un flux de lecture durable pour recevoir des tâches distantes et est compatible avec la commande debug
suivante:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
HAL véhicule
Pour prendre en charge la fonctionnalité d'accès à distance, VHAL doit prendre en charge les propriétés suivantes:
Classe | Description |
---|---|
SHUTDOWN_REQUEST |
Demande l'arrêt de l'unité principale. |
VEHICLE_IN_USE |
|
Pour en savoir plus, consultez la section Propriétés système compatibles.
Mode silencieux
Le mode silencieux doit être compatible avec la fonctionnalité d'accès à distance pour que le véhicule puisse démarrer en mode silencieux afin d'exécuter des tâches à distance lorsqu'aucun utilisateur n'est présent. En mode silencieux, l'appareil AAOS démarre avec l'écran et l'audio désactivés.
Le mode silencieux est contrôlé via deux fichiers sysfs
du noyau Linux.
Classe | Description |
---|---|
/sys/kernel/silent_boot/pm_silentmode_kernel_state
Représente le mode silencieux actuel. |
|
/sys/kernel/silent_boot/pm_silentmode_hw_state
Représente le signal matériel pour définir un nouveau mode silencieux. |
Le processeur du véhicule envoie un signal matériel au SoC Android pour activer/désactiver le mode silencieux. Le signal (0 ou 1) est écrit dans /sys/kernel/silent_boot/pm_silentmode_hw_state
. Ensuite, le framework AAOS met à 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/l'audio désactivés.
Composants non Android dans le véhicule
Processeur de véhicule
Le processeur du véhicule est un processeur qui peut contrôler l'alimentation du processeur de l'application exécutant Android. Dans l'exemple d'architecture, le TCU active le processeur de l'application en envoyant un signal au processeur du véhicule.
Composants non Android dans le véhicule
Le TCU du véhicule peut toujours recevoir des messages à distance.
Le client de réveil s'exécute sur le TCU pour assurer une connexion durable avec le serveur de réveil à distance.
AAOS exécuté sur le point d'accès peut communiquer avec le client de réveil exécuté sur la 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 la TCU pour:
- Maintenir une connexion durable avec le TCU du véhicule.
- Rechercher une TCU spécifique à partir d'un ID de véhicule
- Signaler l'état d'un véhicule (par exemple, en ligne ou hors connexion, ou dernière fois en ligne avec le serveur de tâches distant).
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 à distance.
L'utilisateur interagit avec le serveur pour démarrer de nouvelles tâches à distance et pour 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 associe 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 envoyées via le serveur de tâches à distance au serveur de réveil, au TCU du véhicule et, éventuellement, au client de tâche à distance ne sont qu'un ID de tâche. Le client de tâche à 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é
Tâche | Condition | Obligatoire ? |
---|---|---|
TCU (client de réveil) | OBLIGATOIRE |
|
Serveur de réveil | OBLIGATOIRE |
|
Client de tâche à distance | OBLIGATOIRE |
|
Serveur de tâches à distance | OBLIGATOIRE |
|
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 de voiture est effacé. Toutefois, les serveurs (serveur de tâches à distance et serveur de réveil à distance) ne sont pas informés. Les serveurs conservent une mise en correspondance de l'ID client désormais expiré avec 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.
La section suivante décrit une implémentation possible d'une réinitialisation d'usine.
Lorsqu'un utilisateur effectue une réinitialisation d'usine, le fournisseur lui demande de se connecter au serveur de tâches à distance et de dissocier le véhicule de son compte s'il l'a déjà associé. Il n'est pas garanti que l'appareil ait accès au réseau pendant le rétablissement de la configuration d'usine. Par conséquent, il est possible que l'émission de la demande de dissociation au moment du rétablissement de la configuration d'usine de l'appareil ne soit pas possible.
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 envoyer de tâches à distance au véhicule. Par exemple, le nouveau propriétaire peut être invité à:
Rétablissez la configuration d'usine. Cela garantit que l'ID client est régénéré. Après cette étape, l'ancien propriétaire peut toujours réveiller le véhicule, mais ne peut plus exécuter de tâches à distance.
Ouvrez l'application cliente de tâches à distance et suivez la procédure de désenregistrement d'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 distante dans le HAL, qui est transmise à votre client de tâche à distance si vous fournissez le bon ID client. Vous pouvez obtenir l'ID client en enregistrant les informations d'enregistrement dans l'implémentation du client de tâche à distance.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]