Android 14 introduit la nouvelle fonctionnalité d'accès à distance, qui permet aux partenaires de réactiver Android à distance dans un véhicule afin d'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 requis pour le workflow de bout en bout. Android ne définit ni ne fournit d'implémentation pour les composants autres qu'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 des clients et la diffusion des tâches.
Écrivez un client de tâches à distance. Utilisez l'accès à distance et apprenez à écrire un client de tâches à distance.
Intégration par le fournisseur les composants du fournisseur dans l'exemple d'architecture pour assurer 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éhicules et de serveurs.
Figure 1 : Exemple d'architecture.
L'exemple d'architecture comprend les 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 wakeup | 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 distant | 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 wakeup au client de wakeup. |
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
Le workflow détaillé peut se présenter comme suit:
L'utilisateur gare son véhicule dans un garage.
Le partenaire tente de 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 d'inactivité spécifié.
Procédure détaillée
L'accès à distance nécessite 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, Car Service récupère les informations sur le véhicule auprès 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âches à distance importe les informations de l'utilisateur, ainsi que l'ID du véhicule et l'ID client, sur le serveur de tâches distant, et lui demande d'associer l'utilisateur à ce client spécifique et à ce véhicule spécifique.
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.
Annuler l'enregistrement d'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 vehicle, 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 distant mappe l'ID utilisateur à 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):
La TCU reçoit les tâches distantes 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 la tâche distante 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 des tâches distantes transmet le résultat des tâches 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 automobile rétablit la puissance 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 cette 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 un build userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Configuration requise sur Android
HAL d'accès à distance
La couche d'abstraction matérielle (HAL) d'accès à distance 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 wakeup à 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 longue durée pour recevoir des tâches distantes et est compatible avec la commande debug
suivante :
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
HAL du véhicule
Pour prendre en charge la fonctionnalité d'accès à distance, VHAL doit accepter 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 en l'absence d'utilisateur. 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 permettant de 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 embarqués
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âche à 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 distant au serveur de wakeup, au TCU du véhicule, puis au client de tâche distante 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 distant | 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 lance une nouvelle tâche à distance pour le véhicule, l'ID client expiré est utilisé. 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 suivre 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]