De nombreuses architectures de véhicules actuelles contiennent plusieurs unités de commande électroniques (ECU) en dehors du système d'infodivertissement qui contrôlent l'ergonomie, comme les réglages des sièges et les réglages des rétroviseurs. Sur la base des architectures matérielles et d'alimentation actuelles, de nombreux calculateurs s'allument avant que le système d'infodivertissement basé sur Android ne soit mis sous tension. Ces ECU peuvent s'interfacer avec un système d'infodivertissement basé sur Android via la couche d'abstraction matérielle du véhicule (VHAL) .
À partir d'Android 11, Android Automotive OS (AAOS) a introduit un nouvel ensemble de propriétés sur le VHAL pour créer, changer, supprimer et associer des accessoires externes pour identifier les utilisateurs. Par exemple, ces nouvelles propriétés permettent à un conducteur d' associer un accessoire externe, tel qu'un porte-clés, à son utilisateur Android. Ensuite, lorsque le conducteur s'approche du véhicule, un ECU se réveille et détecte le porte-clés. Cet ECU indique au HAL quel utilisateur Android l'infodivertissement doit démarrer un démarrage, ce qui réduit le temps qu'un conducteur attend que son utilisateur Android se charge.
Activer l'utilisateur HAL
Les propriétés User HAL doivent être explicitement activées en s'assurant que la propriété système android.car.user_hal_enabled
est définie sur true
. (Cela peut également être fait dans le fichier car.mk
, de sorte qu'il n'est pas nécessaire de le définir manuellement.) Vérifiez que user_hal_enabled=true
est activé en UserHalService
:
$ adb shell dumpsys car_service --hal UserHalService|grep enabled user_hal_enabled=true
Vous pouvez également vérifier user_hal_enabled
en utilisant adb logcat CarServiceHelper *:s
. Si la propriété est désactivée, un message semblable au suivant s'affiche au démarrage system_server
:
I CarServiceHelper: Not using User HAL
Pour activer manuellement user_hal_enabled
, définissez la propriété système android.car.user_hal_enabled
et redémarrez system_server
:
$ adb shell setprop android.car.user_hal_enabled true $ adb shell stop && adb shell start
La sortie logcat
apparaît comme suit :
I CarServiceHelper: User HAL enabled with timeout of 5000ms D CarServiceHelper: Got result from HAL: OK I CarServiceHelper: User HAL returned DEFAULT behavior
Propriétés HAL de l'utilisateur
Propriétés du cycle de vie de l'utilisateur
Les propriétés suivantes fournissent les informations HAL pour les états du cycle de vie de l'utilisateur, qui permettent la synchronisation du cycle de vie de l'utilisateur entre le système Android et un ECU externe. Ces propriétés utilisent un protocole de demande et de réponse, dans lequel le système Android fait une demande en définissant une valeur de propriété et la HAL répond en émettant un événement de changement de propriété.
Remarque : Lorsque User HAL est pris en charge, toutes les propriétés suivantes doivent être implémentées.
Propriété HAL | La description |
---|---|
INITIAL_USER_INFO (LIRE ÉCRIRE) | Cette propriété est appelée par le système Android pour déterminer quel utilisateur Android le système démarrera lorsque l'appareil démarrera ou reprendra à partir de Suspend-to-RAM (STR). Lorsqu'il est appelé, le HAL doit répondre avec l'une de ces options :
Remarque : si HAL ne répond pas, le comportement par défaut est de s'exécuter après un délai d'attente (cinq (5) secondes par défaut), ce qui retarde le démarrage. Si HAL répond, mais que le système Android ne parvient pas à exécuter l'action (par exemple, si le nombre maximum d'utilisateurs a été atteint), le comportement par défaut est utilisé. Par exemple, par défaut, le système Android démarre dans le dernier utilisateur actif au démarrage. Si un porte-clés pour un autre utilisateur est détecté, l'ECU remplace la propriété HAL et, lors du démarrage, le système Android bascule pour démarrer dans cet utilisateur spécifié. |
SWITCH_USER (LIRE ÉCRIRE) | Cette propriété est appelée lors du changement d'utilisateur Android actif au premier plan. La propriété peut être appelée par le système Android ou par HAL pour demander un changement d'utilisateur. Les trois flux de travail sont :
Le flux de travail moderne utilise une approche de validation en deux phases pour s'assurer que le système Android et l'ECU externe sont synchronisés. Lorsqu'Android initie le basculement :
Le HAL doit attendre après la réponse Par exemple, alors qu'il est en mouvement, un conducteur tente de changer d'utilisateur Android dans l'interface utilisateur d'infodivertissement. Cependant, étant donné que les paramètres du siège auto sont liés à l'utilisateur Android, le siège se déplacera pendant le changement d'utilisateur. Ainsi, l'ECU contrôlant les sièges ne confirme pas le changement, le HAL répond par un échec et l'utilisateur Android n'est pas commuté. Le flux de travail hérité est un appel unidirectionnel envoyé après le changement d'utilisateur (la HAL ne peut donc pas bloquer le changement). Il n'est appelé qu'au démarrage (après le changement d'utilisateur initial) ou pour les applications qui appellent Par exemple, si une application utilise Le flux de travail Véhicule provient de HAL, pas du système Android :
Par exemple , Bob a utilisé le porte-clés d'Alice pour ouvrir la voiture et HAL a répondu à la demande |
CREATE_USER (LIRE ÉCRIRE) | Cette propriété est appelée par le système Android lorsqu'un nouvel utilisateur Android est créé (à l'aide de l'API CarUserManager.createUser() ). La HAL répond par Par exemple, un conducteur appuie sur une icône d'interface utilisateur d'infodivertissement pour créer un nouvel utilisateur Android. Cela envoie une demande au HAL et au reste des sous-systèmes du véhicule. Les calculateurs sont informés du nouvel utilisateur créé. D'autres sous-systèmes et ECU associent ensuite leur ID utilisateur interne à l'ID utilisateur Android. |
REMOVE_USER (ECRITURE uniquement) | Le système Android appelle cette propriété après la suppression d'un utilisateur Android (avec l'API CarUserManager.removeUser() ).Il s'agit d'un appel à sens unique — aucune réponse n'est attendue de la HAL. Par exemple, un conducteur appuie pour supprimer un utilisateur Android existant dans l'interface utilisateur d'infodivertissement. Le HAL est informé et les autres sous-systèmes et ECU du véhicule sont informés de la suppression de l'utilisateur afin qu'ils puissent supprimer leur ID utilisateur interne. |
Propriétés supplémentaires
Les propriétés supplémentaires suivantes ne sont pas liées aux états du cycle de vie de l'utilisateur. Chacun peut être implémenté sans prendre en charge l'utilisateur HAL.
Propriété HAL | La description |
---|---|
USER_IDENTIFICATION_ASSOCIATION (LIRE ÉCRIRE) | Utilisez cette propriété pour associer tout utilisateur Android à un mécanisme d'identification, tel qu'un porte-clés ou un téléphone. Utilisez cette même propriété pour get ou set des associations.Par exemple, un conducteur appuie sur une icône d'interface utilisateur d'infodivertissement pour associer le porte-clés utilisé pour ouvrir le véhicule (KEY_123) à l'utilisateur Android actif actuel (USER_11). |
Bibliothèques d'assistance
Tous les objets utilisés dans les messages de demande et de réponse (tels que UserInfo
, InitialUserInfoRequest
, InitialUSerInfoResponse
, etc.) ont une représentation de haut niveau à l'aide de C++ struct
, mais la suppression doit être aplatie en objets VehiclePropValue
standard (voir les exemples ci-dessous). Pour faciliter le développement, une bibliothèque d' assistance C++ est fournie dans AOSP pour convertir automatiquement les structs
HAL utilisateur en VehiclePropValue
(et vice versa).
Exemples
INITIAL_USER_INFO
Exemple de requête (au premier démarrage)
VehiclePropValue { // flattened from InitialUserInfoRequest prop: 299896583 // INITIAL_USER_INFO prop.values.int32Values: [0] = 1 // Request ID [1] = 1 // InitialUserInfoRequestType.FIRST_BOOT [2] = 0 // user id of current user [3] = 1 // flags of current user (SYSTEM) [4] = 1 // number of existing users [5] = 0 // existingUser[0].id [6] = 1 // existingUser[0].flags }
Exemple de réponse (créer un utilisateur administrateur)
VehiclePropValue { // flattened from InitialUserInfoResponse prop: 299896583 // INITIAL_USER_INFO prop.values.int32Values: [0] = 1 // Request ID (must match request) [1] = 2 // InitialUserInfoResponseAction.CREATE [2] = -10000 // user id (not used on CREATE) [3] = 8 // user flags (ADMIN) prop.values.stringValue: "en-US||Car Owner" // User locale and User name }
CHANGER D'UTILISATEUR
Le nom réel des classes et des propriétés diffère légèrement, mais le flux de travail global est le même, comme illustré ci-dessous :
Figure 1. Flux de travail des propriétés HAL de l'utilisateur
Exemple de demande de workflow moderne
VehiclePropValue { // flattened from SwitchUserRequest prop: 299896585 // SWITCH_USER prop.values.int32Values: [0] = 42 // Request ID [1] = 2 // SwitchUserMessageType::ANDROID_SWITCH ("modern") [2,3] = 11,0 // target user id (11) and flags (none in this case) [4,5] = 10,8 // current user id (10) and flags (ADMIN) [6] = 3 // number of existing users (0, 10, 11) [7,8] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [9,10] = 10,8 // existingUser[1] (id=10, flags=ADMIN) [11,12] = 11,0 // existingUser[2] (id=11, flags=NONE) }
Exemple de réponse de workflow moderne
VehiclePropValue { // flattened from SwitchUserResponse prop: 299896584 // SWITCH_USER prop.values.int32Values: [0] = 42 // Request ID (must match request) [1] = 3 // SwitchUserMessageType::VEHICLE_RESPONSE [2] = 1 // SwitchUserStatus::SUCCESS }
Exemple de réponse post-commutation de flux de travail moderne
Cette réponse se produit généralement lorsqu'un changement Android réussit :
VehiclePropValue { // flattened from SwitchUserRequest prop: 299896584 // SWITCH_USER prop.values.int32Values: [0] = 42 // Request ID (must match "pre"-SWITCH_USER request ) [1] = 5 // SwitchUserMessageType::ANDROID_POST_SWITCH [2,3] = 11,0 // target user id (11) and flags (none in this case) [4,5] = 11,0 // current user id (11) and flags (none in this case) [6] = 3 // number of existing users (0, 10, 11) [7,8] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [9,10] = 10,8 // existingUser[1] (id=10, flags=ADMIN) [11,12] = 11,0 // existingUser[2] (id=11, flags=NONE) }
Réponse post-switch de flux de travail moderne
Cette réponse se produit généralement lorsqu'un commutateur Android échoue :
VehiclePropValue { // flattened from SwitchUserRequest prop: 299896584 // SWITCH_USER prop.values.int32Values: [0] = 42 // Request ID (must match "pre"-SWITCH_USER request ) [1] = 5 // SwitchUserMessageType::ANDROID_POST_SWITCH [2,3] = 11,0 // target user id (11) and flags (none in this case) [4,5] = 10,8 // current user id (10) and flags (ADMIN) [6] = 3 // number of existing users (0, 10, 11) [7,8] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [9,10] = 10,8 // existingUser[1] (id=10, flags=ADMIN) [11,12] = 11,0 // existingUser[2] (id=11, flags=NONE) }
Exemple de demande de flux de travail hérité
VehiclePropValue { // flattened from SwitchUserRequest prop: 299896584 // SWITCH_USER prop.values.int32Values: [0] = 2 // Request ID [1] = 1 // SwitchUserMessageType::LEGACY_ANDROID_SWITCH [2,3] = 10,8 // target user id (10) and flags (ADMIN) [4,5] = 0,1 // current user id (0) and flags (SYSTEM) [6] = 3 // number of existing users (0, 10, 11) [7,8] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [9,10] = 10,8 // existingUser[1] (id=10, flags=ADMIN) [11,12] = 11,0 // existingUser[2] (id=11, flags=NONE) }
Exemple de demande de workflow de véhicule
VehiclePropValue { // flattened from SwitchUserRequest prop: 299896584 // SWITCH_USER prop.values.int32Values: [0] = -108 // Request ID (must be negative) [1] = 4 // SwitchUserMessageType::VEHICLE_REQUEST [2] = 11 // target user id }
Réponse post-commutation du flux de travail hérité
Cette réponse se produit généralement lorsqu'un changement Android réussit :
VehiclePropValue { // flattened from SwitchUserRequest prop: 299896584 // SWITCH_USER prop.values.int32Values: [0] = -108 // Request ID (must match from vehicle request ) [1] = 5 // SwitchUserMessageType::ANDROID_POST_SWITCH [2,3] = 11,0 // target user id (11) and flags (none in this case) [4,5] = 11,0 // current user id (11) and flags (none in this case) [6] = 3 // number of existing users (0, 10, 11) [7,8] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [9,10] = 10,8 // existingUser[1] (id=10, flags=ADMIN) [11,12] = 11,0 // existingUser[2] (id=11, flags=NONE) }
CRÉER UN UTILISATEUR
Exemple de demande
VehiclePropValue { // flattened from CreateUserRequest prop: 299896585 // CREATE_USER prop.values.int32Values: [0] = 42 // Request ID [1,2] = 11,6 // Android id of the created user and flags (id=11, flags=GUEST, EPHEMERAL) [3,4] = 10,0 // current user id (10) and flags (none in this case) [5] = 3 // number of existing users (0, 10, 11) [6,7] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [8,9] = 10,8 // existingUser[1] (id=10, flags=ADMIN) [10,11] = 11,6 // newUser[2] (id=11, flags=GUEST,EPHEMERAL) }
Exemple de réponse
VehiclePropValue { // flattened from CreateUserResponse prop: 299896585 // CREATE_USER prop.values.int32Values: [0] = 42 // Request ID (must match request) [1] = 3 // CreateUserStatus::SUCCESS }
REMOVE_USER
Exemple de demande
VehiclePropValue { // flattened from RemoveUserRequest prop: 299896586 // REMOVE_USER prop.values.int32Values: [0] = 42 // Request ID [1,2] = 11,0 // Android id of the removed user and flags (none in this case) [3,4] = 10,0 // current user id (10) and flags (none in this case) [5] = 2 // number of existing users (0, 10) [6,7] = 0,1 // existingUser[0] (id=0, flags=SYSTEM) [8,9] = 10,8 // existingUser[1] (id=10, flags=ADMIN) }
USER_IDENTIFICATION_ASSOCIATION
Exemple d'ensemble (porte-clés associé à l'utilisateur 10)
VehiclePropValue { // flattened from UserIdentificationSetRequest prop: 299896587 // USER_IDENTIFICATION_ASSOCIATION prop.values.int32Values: [0] = 43 // Request ID [1,2] = 10,0 // Android id (10) and flags (none in this case) [3] = 1 // number of associations being set [4] = 1 // 1st type: UserIdentificationAssociationType::KEY_FOB [5] = 1 // 1st value: UserIdentificationAssociationSetValue::ASSOCIATE_CURRENT_USER }