Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Implementacja referencyjna opiera się na architekturze dwuwarstwowej. Na warstwie wyższej
DefaultVehicleHal, implementuje interfejs VHAL AIDL i zapewnia logikę VHAL
ogólną dla wszystkich urządzeń. Na niższej warstwie FakeVehicleHardware implementuje interfejs IVehicleHardware. Ta klasa symuluje logikę VHAL w interakcjach z rzeczywistym sprzętem lub magistralą pojazdu i jest specyficzna dla urządzenia. Opcjonalnie dostawcy mogą dostosować tę samą architekturę, ponownie użyć tej samej klasy DefaultVehicleHal (rozszerzając ją, aby zastąpić metodę) i zastosować własną implementację IVehicleHardware.
Rysunek 1. Referencyjna implementacja VHAL
DefaultVehicleHal
zawiera tę logikę, która jest uważana za ogólną i może być stosowana w przypadku dowolnej implementacji VHAL.
Implementuje interfejs IVehicle.
Wykonuje podstawowe kontrole danych wejściowych, w tym sprawdzanie pod kątem duplikatów identyfikatorów.
Przydziela obiekty klienta (na przykład GetValuesClient) do każdej operacji dla każdego klienta bindera i dodaje je do puli globalnej.
Zarządza logiką wywołań asynchronicznych, np. dodawaniem oczekujących żądań do puli oczekujących żądań.
Rozwiązuje oczekujące prośby, gdy otrzymamy wyniki, lub zwraca błąd, gdy czas oczekiwania na jedną z nich przekroczy limit.
Serializuje i deserializuje LargeParcelable (patrz ParcelableUtils.h).
Sprawdzanie uprawnień. (zobacz funkcje checkReadPermission i checkWritePermission).
Okresowo wywołuje funkcję IVehicleHardware.checkHealth i wysyła sygnały tętna (patrz funkcja checkHealth).
IVehicleHardware
to ogólny interfejs reprezentujący implementację VHAL na potrzeby konkretnego sprzętu. Implementacja referencyjna dla IVehicleHardware to FakeVehicleHardware, która używa mapy w pamięci do przechowywania wartości właściwości i nie komunikuje się z rzeczywistą magistralą pojazdu. Jest on przeznaczony do uruchamiania na emulatorze i nie ma żadnych zależności od sprzętu. Implementacje dostawców nie mogą używać tego interfejsu w postaci domyślnej. Należy dodać logikę specyficzną dla magistrali pojazdu.
Począwszy od Androida 14, FakeVehicleHardware odczytuje obsługiwaną konfigurację właściwości w czasie wykonywania podczas inicjalizacji z folderu /vendor/etc/automotive/vhalconfig/ urządzenia, który zawiera plik konfiguracji w formacie JSON. Aby poznać format i zawartość pliku konfiguracji, zapoznaj się z przykładowym plikiem README VHAL.
FakeVehicleHardware obsługuje też zastąpienie pliku konfiguracji na potrzeby testowania. Jeśli właściwość systemowa persist.vendor.vhal_init_value_override jest ustawiona (musi być ustawiona w czasie kompilacji lub bardzo wcześnie podczas uruchamiania przed zainicjowaniem VHAL), do zastąpienia bieżącej konfiguracji używa pliku konfiguracyjnego z folderu /vendor/etc/automotive/vhaloverride/ na urządzeniu. Implementacja dostawcy może używać podobnego podejścia, aby konfiguracja obsługiwanej właściwości VHAL nie była zakodowana na stałe, a można było ją ustalić dynamicznie w momencie uruchomienia.
Po zainicjowaniu VHAL lista konfiguracji właściwości pojazdu musi być statyczna.
Od Androida 16 GRPCVehicleHardware udostępnia inną referencyjną implementację IVehicleHardware. Ta implementacja
zakłada, że istnieje osobny serwer działający na zdalnej maszynie lub maszynie wirtualnej, który zawiera logikę obsługi właściwości. VHAL działający na urządzeniach z AAOS działa jako serwer proxy, który przekazuje żądania do serwera zdalnego. Więcej informacji znajdziesz w dokumentacji usługi rpc przez sieć (gRPC).
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-26 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]
