Implementacja referencyjna

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.

Implementacja referencyjna VHAL
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).
  • Zarządza subskrypcją (patrz SubscriptionManager.h).
  • Sprawdzanie uprawnień. (zobacz funkcje checkReadPermissioncheckWritePermission).
  • 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).