Implementacja referencyjna

Udostepniamy implementację referencyjną AIDL VHAL. Główny wątek usługi jest zaimplementowany w VehicleService.cpp. Implementacja interfejsu VHAL znajduje się w pliku DefaultVehicleHal.cpp.

Implementacja referencyjna jest oparta na architekturze dwuwarstwowej. W górnej warstwie DefaultVehicleHal implementuje interfejs VHAL AIDL i udostępnia logikę VHAL wspólną dla wszystkich urządzeń. W dolnej warstwie FakeVehicleHardware, implementuje interfejs IVehicleHardware. Ta klasa symuluje logikę VHAL dotyczącą interakcji z rzeczywistym sprzętem lub magistralą pojazdu i jest specyficzna dla urządzenia. Opcjonalnie dostawcy mogą dostosować tę samą architekturę, ponownie wykorzystać tę samą klasę DefaultVehicleHal (rozszerzając ją w celu zastąpienia metody) i udostępnić własną implementację IVehicleHardware.

DefaultVehicleHal zawiera tę logikę, która jest uważana za ogólną i może być stosowana w każdej implementacji VHAL.

• Implementuje interfejs IVehicle.
• Wykonuje podstawowe sprawdzanie danych wejściowych, w tym sprawdzanie duplikatów identyfikatorów.
• Przydziela obiekty klienta (np. GetValuesClient) dla każdej operacji dla każdego klienta powiązanego i dodaje każdy z nich do puli globalnej.
• Zarządza logiką wywołań zwrotnych asynchronicznych, np. dodawaniem oczekującego żądania do puli oczekujących żądań. Rozwiązuje oczekujące żądania, gdy otrzymamy wyniki, lub zwraca błąd, gdy jedno z oczekujących żądań przekroczy limit czasu.
• Serializuje i deserializuje LargeParcelable (patrz ParcelableUtils.h).
• Zarządza subskrypcją (patrz SubscriptionManager.h).
• Sprawdza uprawnienia. (Patrz funkcje checkReadPermission i checkWritePermission).
• Okresowo wywołuje IVehicleHardware.checkHealth i wysyła sygnały heartbeat (patrz funkcja checkHealth).

IVehicleHardware to ogólny interfejs używany do reprezentowania implementacji VHAL specyficznej dla sprzętu. Implementacją referencyjną IVehicleHardware jest 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 przeznaczona do działania na emulatorze i nie ma zależności od sprzętu. Implementacje dostawców nie mogą używać jej w takiej postaci i muszą dodać logikę specyficzną dla magistrali pojazdu.

Od Androida 14 FakeVehicleHardware odczytuje obsługiwaną konfigurację właściwości w czasie działania podczas inicjowania z folderu /vendor/etc/automotive/vhalconfig/ urządzenia, który zawiera plik konfiguracyjny w stylu JSON. Format pliku konfiguracyjnego i jego zawartość znajdziesz w pliku README implementacji referencyjnej VHAL.

FakeVehicleHardware obsługuje też zastępowanie pliku konfiguracyjnego na potrzeby testowania. Jeśli ustawiona jest właściwość systemowa persist.vendor.vhal_init_value_override (tę właściwość należy ustawić w czasie kompilacji lub bardzo wcześnie podczas uruchamiania, zanim nastąpi inicjowanie VHAL), używa ona pliku konfiguracyjnego z folderu /vendor/etc/automotive/vhaloverride/ na urządzeniu, aby zastąpić istniejącą konfigurację. Implementacja dostawcy może używać podobnego podejścia, aby konfiguracja właściwości obsługiwanych przez VHAL- nie była zakodowana na stałe i można było ją dynamicznie określać w czasie uruchamiania. Po zainicjowaniu VHAL lista konfiguracji właściwości pojazdu musi być statyczna.

Od Androida 16 GRPCVehicleHardware udostępnia kolejną implementację referencyjną IVehicleHardware. Ta implementacja zakłada, że na zdalnej maszynie lub maszynie wirtualnej działa osobny serwer, 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 artykule o grpc.