Implementacja referencyjna

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

Implementacja referencyjna opiera się na architekturze dwuwarstwowej. W górnej warstwie DefaultVehicleHalimplementuje interfejs VHAL AIDL i zapewnia logikę VHAL ogólną dla wszystkich urządzeń. W warstwie niższej FakeVehicleHardware implementuje interfejs IVehicleHardware. Ta klasa symuluje logikę VHAL 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ą DefaultVehicleHal klasę (rozszerzając ją w celu zastąpienia metody) i zapewnić własną implementację IVehicleHardware.

Implementacja referencyjna VHAL
Rysunek 1. Implementacja referencyjna VHAL

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

  • Implementuje interfejs IVehicle.
  • Przeprowadza 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 interfejsu Binder i dodaje je do puli globalnej.
  • Zarządza logiką wywołań zwrotnych asynchronicznych, np. dodawaniem oczekującego żądania do puli oczekujących żądań. Rozwiązuje oczekujące prośby, gdy otrzymujemy wyniki, lub zwraca błąd, gdy jedna z oczekujących próśb przekroczy limit czasu.
  • Serializuje i deserializuje LargeParcelable (patrz ParcelableUtils.h).
  • Zarządzanie subskrypcją (patrz SubscriptionManager.h).
  • Sprawdza uprawnienia. (Zobacz funkcje checkReadPermission i checkWritePermission).
  • Okresowo wywołuje funkcję IVehicleHardware.checkHealth i wysyła sygnały pulsu (patrz funkcja checkHealth).

IVehicleHardware to ogólny interfejs używany do reprezentowania implementacji VHAL specyficznej dla 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 ona przeznaczona do uruchamiania na emulatorze i nie ma zależności od konkretnego sprzętu. Implementacje dostawców nie mogą używać tego kodu w niezmienionej 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/ na urządzeniu, który zawiera plik konfiguracyjny w stylu JSON. Informacje o formacie i zawartości pliku konfiguracji znajdziesz w pliku README VHAL.

FakeVehicleHardware obsługuje też zastępowanie pliku konfiguracji na potrzeby testowania. Jeśli ustawiona jest właściwość systemowa persist.vendor.vhal_init_value_override (musi być ustawiona w momencie kompilacji lub na bardzo wczesnym etapie uruchamiania, zanim zostanie zainicjowany VHAL), używa 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 momencie uruchomienia. Lista konfiguracji właściwości pojazdu musi być statyczna po zainicjowaniu VHAL.

Od Androida 16 GRPCVehicleHardware zapewnia kolejną implementację referencyjną IVehicleHardware. Ta implementacja zakłada, że na zdalnej maszynie lub maszynie wirtualnej działa oddzielny serwer, który zawiera logikę obsługi właściwości. VHAL działający na urządzeniach z AAOS pełni rolę serwera proxy, który przekazuje żądania do serwera zdalnego. Więcej informacji znajdziesz w sekcji grpc.