Udostępniamy implementację referencyjną dla interfejsu AIDL VHAL. Główny wątek usługi jest implementowany w pliku VehicleService.cpp
.
Implementacja interfejsu VHAL znajduje się pod adresem DefaultVehicleHal.cpp
.
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
.
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
(patrzParcelableUtils.h
). - Zarządza subskrypcją (patrz
SubscriptionManager.h
). - Sprawdzanie uprawnień. (zobacz funkcje
checkReadPermission
icheckWritePermission
). - Okresowo wywołuje funkcję
IVehicleHardware.checkHealth
i wysyła sygnały tętna (patrz funkcjacheckHealth
).
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).