À 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.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Pour migrer une implémentation VHAL HIDL existante vers une implémentation VHAL AIDL, utilisez la structure implémentation de référence AIDL pour implémenter l'interface IVehicleHardware.
Si l'implémentation HIDL existante suit également l'implémentation de référence HIDL, le fournisseur a implémenté la classe VehicleHal. IVehicleHardware est très semblable à VehicleHal.
HIDL VHAL
AIDL VHAL
getAllPropertyConfigs()
Prix identique à celui de l'hôtel VehicleHal.listProperties()
getValues(callback, requests)
Peut appeler VehicleHal.get() pour chaque requête et peut appeler des rappels.
dump()
Prix identique à celui de l'hôtel VehicleHal.dump()
checkHealth()
Peut renvoyer VehicleHal.get()
registerPropertyChangeCallback()
Semblable au paramètre VehicleHal.mOnHalEvent
Différences entre les types dans AIDL
Lorsque vous passez de la VHAL HIDL à la VHAL AIDL, tenez compte de ces différences.
HIDL génère un fichier d'en-tête (types.h) pour tous les types générés à partir de types.hal. AIDL génère un fichier d'en-tête pour chaque type. Par exemple, VehiclePropValue.h à partir de VehiclePropValue.aidl.
Par conséquent, vous devez inclure tous les fichiers d'en-tête pour les types dont vous avez besoin. Un fichier d'assistance, VehicleHalTypes.h dans la bibliothèque VehicleHalUtils, contient la plupart des types courants.
Au lieu de :
Utiliser
hidl_vec
std::vector
hidl_string
std::string
android::sp
std::shared_ptr
android::wp
std::weak_ptr
Tous les types définis dans types.hal sont les mêmes dans AIDL sauf :
SubscribeFlags est supprimé, car il n'est pas utilisé, car onPropertySet est supprimé.
UserFlags est désormais défini dans UserInfo.aidl et doit être défini comme un indicateur au lieu d'une énumération. Un champ d'indicateur utilisateur est un entier qui comporte plusieurs UserInfo.USER_FLAG_XXX bit-or ensemble.
RawValue dans VehiclePropValue est renommé RawPropValue.
bytes dans RawValue est renommé byteValues.
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/27 (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/27 (UTC)."],[],[],null,["# HIDL VHAL migration guide\n\nTo migrate an existing **HIDL** VHAL implementation to an **AIDL** VHAL,\nuse the\n[AIDL reference implementation](/docs/automotive/vhal/reference-implementation)\nstructure to implement the `IVehicleHardware` interface.\n\nIf the existing HIDL implementation also follows\n[HIDL reference implementation](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/2.0/default/impl/vhal_v2_0),\nthe vendor has implemented the `VehicleHal` class. `IVehicleHardware` is\nvery similar to `VehicleHal`.\n| **Note:** AIDL uses different types than HIDL. Some types used in the HIDL implementation must be migrated. For detail, see [Type differences in AIDL](#aidl-diffs) below.\n\n| HIDL VHAL | AIDL VHAL |\n|------------------------------------|----------------------------------------------------------------------|\n| `getAllPropertyConfigs()` | Same as `VehicleHal.listProperties()` |\n| `getValues(callback, requests)` | Can call `VehicleHal.get()` for each request and can call callbacks. |\n| `dump()` | Same as `VehicleHal.dump()` |\n| `checkHealth()` | Can return `VehicleHal.get()` |\n| `registerPropertyChangeCallback()` | Similar to setting `VehicleHal.mOnHalEvent` |\n\nType differences in AIDL\n------------------------\n\nWhen migrating from the HIDL VHAL to the AIDL VHAL, consider these differences.\n\n1. HIDL generates one header file (`types.h`) for all types generated from `types.hal`. AIDL generates one header file for each type. For example, `VehiclePropValue.h` from `VehiclePropValue.aidl`.\n\n As a result, you must include all header files for the types you need. A helper file,\n `VehicleHalTypes.h` in the `VehicleHalUtils` library contains most of\n the common types.\n\n| Instead of ... | Use |\n|----------------|-------------------|\n| `hidl_vec` | `std::vector` |\n| `hidl_string` | `std::string` |\n| `android::sp` | `std::shared_ptr` |\n| `android::wp` | `std::weak_ptr` |\n\n2. All types defined in `types.hal` are the same in AIDL **except** for:\n - `SubscribeFlags` is removed as it's not used because `onPropertySet` is removed\n - `UserFlags` is now defined in `UserInfo.aidl` and should be defined as a flag instead of an enum. A user flag field is an integer that has multiple `UserInfo.USER_FLAG_XXX` bit-or together.\n - `RawValue` in `VehiclePropValue` is renamed as `RawPropValue`\n - `bytes` in `RawValue` is renamed as `byteValues`"]]
