À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
L'implémentation de référence est basée sur une architecture à deux couches. Au niveau de la couche supérieure, DefaultVehicleHal implémente l'interface AIDL VHAL et fournit une logique VHAL générique pour tous les appareils matériels. À la couche inférieure, FakeVehicleHardware, s'implémente l'interface IVehicleHardware. Cette classe simule la logique VHAL d'interaction avec le matériel ou le bus du véhicule réel, et est spécifique à l'appareil. Les fournisseurs peuvent également adapter cette même architecture, réutiliser la même classe DefaultVehicleHal (en l'étendant pour écraser une méthode) et fournir leur propre implémentation IVehicleHardware.
Figure 1. Implémentation de référence de VHAL
DefaultVehicleHal contient la logique suivante, qui est considérée comme générique et peut s'appliquer à toute implémentation VHAL.
Implémente l'interface IVehicle.
Effectue des vérifications de base des entrées, y compris une vérification des identifiants en double.
Alloue des objets client (par exemple, GetValuesClient) pour chaque opération pour chaque client de liaison, et ajoute chacun à un pool global.
Gère la logique des rappels asynchrones, par exemple en ajoutant une requête en attente à un pool de requêtes en attente.
Résout les requêtes en attente lorsque nous recevons les résultats ou renvoie une erreur lorsqu'une des requêtes en attente expire.
Sérialise et désérialise LargeParcelable (voir ParcelableUtils.h).
Gère l'abonnement (voir SubscriptionManager.h).
Vérifie les autorisations. (voir les fonctions checkReadPermission et checkWritePermission)
Appele régulièrement IVehicleHardware.checkHealth et envoie des signaux de battement de cœur (voir la fonction checkHealth).
IVehicleHardware est une interface générique utilisée pour représenter l'implémentation matérielle spécifique d'un VHAL. L'implémentation de référence pour IVehicleHardware est FakeVehicleHardware, qui utilise une carte en mémoire pour stocker la valeur de la propriété et ne communique pas avec un bus de véhicule réel. Il est conçu pour s'exécuter sur un émulateur et ne comporte aucune dépendance spécifique au matériel. Les implémentations des fournisseurs ne doivent pas l'utiliser telle quelle et doivent ajouter une logique spécifique au bus du véhicule.
À partir d'Android 14, FakeVehicleHardware lit la configuration de propriété compatible au moment de l'exécution lors de l'initialisation à partir du dossier /vendor/etc/automotive/vhalconfig/ de l'appareil, qui contient un fichier de configuration au format JSON. Pour connaître le format et le contenu du fichier de configuration, consultez le fichier README de référence VHAL.
FakeVehicleHardware prend également en charge le forçage de fichier de configuration pour les tests. Si la propriété système persist.vendor.vhal_init_value_override est définie (cette propriété doit être définie au moment de la compilation ou très tôt au démarrage avant l'initialisation de VHAL), elle utilise le fichier de configuration du dossier /vendor/etc/automotive/vhaloverride/ sur l'appareil pour remplacer la configuration existante. Une implémentation par le fournisseur peut utiliser une approche similaire afin que la configuration des propriétés compatibles avec VHAL ne soit pas codée en dur et puisse être décidée de manière dynamique au démarrage.
La liste des configurations des propriétés du véhicule doit être statique une fois VHAL initialisé.
À partir d'Android 16, GRPCVehicleHardware fournit une autre implémentation de référence IVehicleHardware. Cette implémentation suppose qu'un serveur distinct s'exécute sur une machine ou une VM distante qui contient la logique de gestion des propriétés. Le VHAL exécuté sur les appareils AAOS agit en tant que proxy qui transfère les requêtes au serveur distant. Pour en savoir plus, consultez grpc.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/26 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/26 (UTC)."],[],[],null,["# Reference implementation\n\nWe provide a\n[reference implementation](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current)\nfor the AIDL VHAL. The main service thread is implemented\nat\n[`VehicleService.cpp`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/VehicleService.cpp).\nThe VHAL interface implementation is located at\n[`DefaultVehicleHal.cpp`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/DefaultVehicleHal.cpp).\n\n\nThe reference implementation is based on a two-layer architecture. On the upper layer,\n`DefaultVehicleHal`, implements VHAL AIDL interface and provides VHAL logic\ngeneric to all hardware devices. On the lower layer, `FakeVehicleHardware`,\nimplements the `IVehicleHardware` interface. This class simulates the VHAL logic\nof interacting with actual hardware or vehicle bus and is device-specific. Optionally, vendors\ncan adapt this same architecture, reuse the same `DefaultVehicleHal` class (extending\nit to overwrite a method), and provide their own `IVehicleHardware` implementation.\n**Figure 1.** VHAL reference implementation\n\n[`DefaultVehicleHal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/DefaultVehicleHal.cpp)\ncontains the following logic, which is considered to be generic and can apply to any VHAL\nimplementation.\n\n- Implements the `IVehicle` interface.\n- Performs basic input checks, including a check for duplicate IDs.\n- Allocates client objects (for example, `GetValuesClient`) for each operation for each binder client, and adds each to a global pool.\n- Manages async callbacks logic, such as adding a pending request to a pending request pool. Resolves pending requests when we receive the results or returns error when one of the pending requests times out.\n- Serializes and deserializes `LargeParcelable` (see `ParcelableUtils.h`).\n- Manages subscription (see `SubscriptionManager.h`).\n- Checks permissions. (See the `checkReadPermission` and `checkWritePermission` functions).\n- Periodically calls `IVehicleHardware.checkHealth` and sends heartbeat signals (see the `checkHealth` function).\n\n[`IVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/hardware/include/IVehicleHardware.h)\nis a generic interface used to represent a VHAL's hardware-specific\nimplementation. The reference implementation for `IVehicleHardware` is\n[`FakeVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/fake_impl/hardware/src/FakeVehicleHardware.cpp),\nwhich uses an in-memory map to store property value and does\nnot communicate with an actual vehicle bus. It's intended to run on an emulator and have no\nhardware-specific dependencies. Vendor implementations must not use it as-is and must add\nvehicle bus-specific logic.\n\nStarting in Android 14, `FakeVehicleHardware` reads the supported property config at run-time\nduring initialization from the device's `/vendor/etc/automotive/vhalconfig/` folder,\nwhich contains a JSON-style config file. See the\n[reference VHAL README file](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/default_config/config/README.md)\nfor config file format and config file content.\n\n`FakeVehicleHardware` also supports config file override for testing. If the\nsystem property `persist.vendor.vhal_init_value_override` is set (this property must be\nset at build time or very early during boot before VHAL initialization), it uses the config\nfile from the `/vendor/etc/automotive/vhaloverride/` folder on the device to override\nthe existing configuration. A vendor implementation can use a similar approach so that the VHAL-\nsupported property configuration is not hard-coded and can be dynamically decided at start time.\nThe list of vehicle property configs must be static after VHAL is initialized.\n\nStarting in Android 16, [`GRPCVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/grpc/GRPCVehicleHardware.cpp)\nprovides another reference `IVehicleHardware` implementation. This implementation\nassumes there is a separate server running on a remote machine or VM which contains the property\nhandling logic. The VHAL running on AAOS devices acts as a proxy that forwards requests to\nthe remote server. See [grpc](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/README.md#grpc)\nfor more details."]]