Android 14 introduit une nouvelle fonctionnalité d'accès à distance, qui permet aux partenaires de réactiver Android à distance dans un véhicule pour exécuter tâches spécifiques. Par exemple, pour exécuter Mode garage pendant la nuit pour installer le logiciel mises à jour. Plusieurs composants non-Android sont requis pour l'exécution de bout en bout le workflow de ML. Android ne définit pas et ne fournit pas d'implémentation pour les appareils autres qu'Android (cette responsabilité vous appartient).
Pour en savoir plus, consultez les sections suivantes:
Workflow. Workflow entre plusieurs composants de l'exemple pour l'enregistrement des clients et la livraison des tâches.
Écrivez un client de tâches à distance. Utiliser l'accès à distance et apprendrez à écrire un client de tâches à distance.
Implémentation par le fournisseur. les composants du fournisseur dans exemple d'architecture pour permettre l'accès à distance.
Rétablir la configuration d'usine et transférer la propriété. Découvrez comment gérer rétablir la configuration d'usine et transférer la propriété du véhicule.
Testez le client d'accès à distance. Découvrez comment tester l'accès à distance .
Architecture
Le contenu suivant suppose l'utilisation de l'exemple d'architecture suivant, qui est est hypothétique et peut ne pas refléter l’architecture réelle. Les OEM doivent s'adapter une implémentation réelle de 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'applications | Processeur fonctionnant sous Android. Android peut s'exécuter sur une mémoire virtuelle (VM) (et non sur du matériel réel) sur ce processeur. |
| Processeur de véhicule | Sous-traitant responsable du contrôle de l'alimentation de l'application processeur. |
| Unité de commande télématique (TCU) | Le processeur dans le véhicule est toujours capable de recevoir des messages à distance de dans le cloud. Le TCU est supposé être toujours activé ou en mode économie d'énergie. Utilisez des messages à distance pour éveiller le TCU. |
| Serveur de wakeup | Un serveur distant qui s’exécute dans le cloud et qui est responsable de communiquant avec le TCU dans le véhicule pour émettre des commandes de réveil. |
| Serveur de tâches distant | Le serveur de tâches distant s'exécute dans le cloud et interagit avec des personnes et gère les tâches à distance. |
L'exemple d'architecture comprend ces composants logiciels, tous qui s'exécutent sur Android:
| Composant logiciel sur Android | Description |
|---|---|
| Service automobile | Service de framework AAOS qui fournit des API d'accès à distance |
| Client de tâches à distance | Un document rédigé par un fournisseur
Service
qui exécute des tâches à distance. Un même système Android peut exécuter plusieurs
des 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 une application autre qu'Android comme le TCU. |
Les composants logiciels non-Android sont décrits ci-dessous:
| Composant logiciel non-Android | Description |
|---|---|
| Client de wakeup | Logiciel s'exécutant sur TCU qui maintient une connexion longue durée avec le d'un serveur de secours. Il maintient également la connexion avec l'HAL d'accès à distance. pour fournir des tâches à distance au service automobile. |
| Implémentation du serveur de wakeup | Serveur qui communique avec le client de wakeup s'exécutant sur le TCU. Boîte envoyer des requêtes de wakeup au client de wakeup. |
| Implémentation du serveur de tâches distant | Serveur qui gère les tâches à distance. Les utilisateurs interagissent avec ce serveur pour et surveiller les 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 le garage.
Le partenaire cherche à mettre à jour le véhicule pendant la nuit lorsque des interactions avec celui-ci sont peu probable.
Le serveur cloud partenaire envoie une tâche à distance du système de mise à jour au véhicule. Plus précisément, l'unité de commande télématique (TCU).
Le TCU du véhicule active l'unité de commande é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 soit met fin à la connexion ou atteint le délai 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 lier un utilisateur spécifique à une ressource client de tâches exécuté sur un véhicule spécifique. L'autre est de livrer une tâche, qui consiste à distribuer la tâche distante à un utilisateur spécifique client s'exécutant sur le véhicule spécifique.
Enregistrer un client
Pour utiliser la fonctionnalité d'accès à distance, un utilisateur doit ouvrir le client de tâches à distance application au moins une fois et finaliser le processus d'enregistrement du client (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 CARL.
Au démarrage, Car Service lance toutes les tâches à distance en fonction "intent-filter" et "permission".
Au démarrage du client de tâches à distance, ce client s'enregistre auprès de le service automobile.
Car Service informe le client de la tâche à distance de l'enregistrement comme l'ID du véhicule et l'ID client. L'ID client est unique et attribué par Car Service à ce client. L'unicité est garantie. entre tous les clients de tâches distantes sur le 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. En général, cette étape implique une authentification via le serveur de tâches distant.
Le client de tâches à distance importe les informations de l'utilisateur ainsi que l'identifiant du véhicule et l'ID client au serveur de tâches distant et lui demande de lier l'utilisateur avec pour ce client et ce véhicule.
Cette étape peut impliquer une authentification à deux facteurs supplémentaire de l'utilisateur.
Le serveur de tâches distant doit s'authentifier que l'identifiant du véhicule fourni dans la demande correspond à l'identifiant du véhicule de l'expéditeur. l'attestation du véhicule.
En l'absence de rétablissement de la configuration d'usine, le processus d'enregistrement du client est requis une fois par utilisateur et par véhicule. L'ID client est stocké localement dans Car Service et reste identique 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 le serveur de tâches distant:
Sur le véhicule, les utilisateurs peuvent ouvrir l'application cliente de tâches à distance et résoudre Une demande de dissociation visant à dissocier ce véhicule de l'utilisateur précédemment associé Google Cloud.
Sur le serveur de tâches distant, 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 distant supprimer le mappage stocké pour l'utilisateur spécifique.
Livrer les tâches
Dans le cloud:
Un utilisateur utilise le serveur de tâches distant pour envoyer une tâche distante à un véhicule.
Le serveur de tâches à distance mappe l'ID utilisateur à l'ID du véhicule et à l'ID client. Il envoie les données de la tâche, l'identifiant du véhicule et l'identifiant du client au serveur de wakeup.
Le serveur de wakeup trouve le code TCU spécifique pour l'identifiant du véhicule (en supposant que le l'enregistrement du TCU est déjà effectué) et envoie les données de la tâche et l'ID client à le 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 exécutant AAOS est désactivé, le TCU utilise le le processeur du véhicule (VP) pour réactiver le point d'accès.
Le service automobile reçoit des tâches de TCU.
Car Service répartit les tâches au client de tâches distantes correspondant.
Le client de la tâche distante reçoit et exécute la tâche.
(Facultatif) Serveur de tâches de contacts du client pour la tâche à distance afin d'obtenir plus de détails sur la tâche et exécute la tâche.
(Facultatif) Le service client des tâches distantes transmet le résultat des tâches au serveur de tâches.
Le client de tâches distante informe le service Voiture une fois la tâche terminée.
Si nécessaire, le service automobile rétablit la puissance du véhicule.
Figure 3. Livrer les tâches.
Écrire un client de tâches à distance
CarRemoteAccessManager fournit l'API des fonctionnalités d'accès à distance. Pour apprendre
plus, voir
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 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âches distantes doit s'enregistrer auprès du service Car lors de sa 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 s'associe à ce service pendant la période au démarrage et lorsqu'une tâche à distance arrive. L'entretien automobile est dissocié de ce service lorsque : la tâche est terminée. Pour en savoir plus, consultez Gérer le cycle de vie d'un service
Le client de tâches distantes s'exécute en tant qu'utilisateur système et n'a donc pas accès à toutes les 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 le paramètre , ajoutez une 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
}
Ou utilisez 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 matérielle couche d'abstraction pour la communication entre AAOS et un autre UC (par exemple, TCU). Elle est obligatoire pour la compatibilité avec la fonctionnalité d'accès à distance. Il n'a pas besoin à mettre en œuvre si la fonctionnalité d'accès à distance n'est pas implémentée.
L'interface est définie IRemoteAccess.aidl et inclut les méthodes suivantes:
| Classe | Description |
|---|---|
String getVehicleId() |
Récupère un identifiant de véhicule unique qui peut être reconnu par le réveil. Google Cloud. |
String getWakeupServiceName() |
Récupère le nom du serveur de wakeup à distance. |
String getProcessorId() |
Récupère un ID de processeur unique que l'on peut reconnaître en activant l' client. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Définit un rappel à appeler lorsqu'une tâche à distance 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 d'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 le
implémentation de référence
avec un TCU externe. L'implémentation utilise un flux de lecture en direct
recevoir des tâches à distance 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 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 peut démarrer en mode silencieux pour exécuter des tâches à distance en l'absence d'utilisateur. Avec mode silencieux, l'appareil AAOS démarre avec l'affichage 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 par conséquent,
représente le mode silencieux actuel. Vérification des modules AAOS
/sys/kernel/silent_boot/pm_silentmode_kernel_state pour savoir si le système
est en mode silencieux ou non.
Lorsqu'une tâche distante est reçue et qu'AAOS démarre, le processeur du véhicule définit en mode silencieux et démarre AAOS pour que le système démarre avec l'affichage et l'audio désactivés.
Composants non Android embarqués
Processeur de véhicule
Le processeur du véhicule est un processeur intégré au véhicule qui peut contrôler la puissance pour le processeur d'application sous Android. Dans l'exemple d'architecture, TCU active le processeur d'application en envoyant un signal au véhicule processeur.
Composants non Android embarqués
Le TCU du véhicule peut toujours recevoir des messages à distance.
Le client de wakeup s'exécute sur le TCU pour garantir une connexion de longue durée avec serveur de veille à distance.
AAOS exécuté sur le point d'accès peut communiquer avec le client wakeup exécuté sur TCU via le HAL d'accès à distance.
Figure 4. TCU (client de réveil).
Composants dans le cloud
Serveur de wakeup
Le serveur de wakeup communique avec le client de wakeup sur le TCU pour:
- Maintenez une connexion longue durée avec le TCU du véhicule.
- Trouvez un TCU spécifique à partir de l'identifiant d'un véhicule.
- Signalez l'état d'un véhicule. Par exemple, en ligne ou hors ligne, ou dernière du temps en ligne au serveur de tâches distant.
Dans une implémentation réelle, un serveur wakeup peut être fusionné avec un serveur distant serveur de tâches.
Serveur de tâches distant
Le serveur de tâches distantes gère ces tâches distantes.
L'utilisateur interagit avec le serveur pour démarrer de nouvelles tâches à distance et surveiller tâches à distance.
Utilise le serveur de wakeup à distance pour réactiver le processeur d'application dans les véhicules.
Il interagit avec le client de tâches à distance exécuté sur le véhicule.
Stocke les informations d'inscription des clients. 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 au TCU du véhicule, puis au client de tâche à distance un ID de tâche. Le client de la tâche distante utilise l'ID de tâche pour récupérer les détails du serveur de tâches distant.
Exigences de confidentialité et de sécurité
| Tâche | Condition | Obligatoire ? |
|---|---|---|
| TCU (client de réveil) | OBLIGATOIRE |
|
| Serveur de wakeup | OBLIGATOIRE |
|
| Client de tâches à 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'identifiant client stocké dans Car Service est effacés. Cependant, les serveurs (serveur de tâches distants et serveur de wakeup à distance) sont pas informées. Les serveurs conservent un mappage entre l'ID client expiré et le véhicule. Par conséquent, si l'utilisateur commence 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 distante a un ID client différent qui ne correspond pas.
Voici une implémentation possible du rétablissement de la configuration d'usine.
Lorsqu'un utilisateur rétablit la configuration d'usine, le fournisseur l'invite à se connecter à le serveur de tâches distant et dissocier le véhicule de son compte si l'utilisateur a déjà associé le véhicule. Il n'est pas garanti que l'appareil dispose d'une connexion réseau y accéder pendant le rétablissement de la configuration d'usine. Par conséquent, l'émission de la requête de dissociation au moment du rétablissement de la configuration d'usine de l'appareil.
Chaque fois que vous transférez la propriété d'un véhicule, pour s'assurer que le propriétaire précédent ne peut plus émettre de tâches à distance 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 réactiver le véhicule, d'exécuter plus longtemps les tâches à distance.
Ouvrez l'application cliente des tâches à distance et suivez les instructions Annuler l'enregistrement d'un client pour dissocier le véhicule depuis le compte du propriétaire précédent. Le nouveau propriétaire peut suivre le registre 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 l'HAL d'accès à distance de référence.
default
pour tester les clients de tâches à distance. Vous pouvez utiliser les debug suivants
pour injecter une fausse tâche distante au HAL, qui est transmise à votre
client de tâches distantes si vous
fournissez le bon ID client. Vous pouvez obtenir le client
en enregistrant les informations d'enregistrement dans votre client de tâches à distance
la mise en œuvre.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]