DriverUI

Interfejs klastra tradycyjnie znajduje się za kierownicą na osobnym wyświetlaczu. Producenci OEM stopniowo łączą klaster i IVI w jeden wyświetlacz. Ten połączony interfejs to DriverUI.

DriverUI

Rysunek 1. DriverUI.

DriverUI to aplikacja systemowa Androida, która renderuje cały wyświetlacz zestawu wskaźników, z wyłączeniem elementów związanych z bezpieczeństwem lub przepisami, renderowanych przez moduł renderowania o wysokiej dostępności (HAR). DriverUI wyświetla informacje dotyczące odtwarzania multimediów , połączeń telefonicznych, map, nawigacji i innych elementów oraz implementuje Automotive Design for Compose.

DriverUI jako domyślna aktywność klastra

DriverUI działa jako uprzywilejowana aplikacja klastra w Androidzie, a AAOS uruchamia ją automatycznie.

AAOS uses the ClusterHomeManager class, also referred to as Cluster2, to build instrument clusters. Ta klasa określa konfigurację potrzebną do zidentyfikowania implementacji zestawu wskaźników oraz sposób, w jaki AAOS z nią współdziała. Google udostępnia implementacje referencyjne interfejsów API Cluster2.

Platformy

Możesz tworzyć i uruchamiać Display Safety na SDV. Platforma Software Defined Vehicle (SDV):

  • wymaga 2 maszyn wirtualnych gościa;
  • uruchamia HAR w SDV Media (znanym też jako maszyna wirtualna szybkiego rozruchu) w maszynie wirtualnej gościa;
  • uruchamia DriverUI w innej maszynie wirtualnej gościa SDV IVI;
  • uruchamia Safety Monitor na maszynie wirtualnej SDV Media.

Architektura platformy SDV

Rysunek 2. Architektura platformy SDV.

Łączenie danych wyjściowych HAR i DriverUI

HAR i DriverUI używają osobnych wyświetlaczy do renderowania interfejsu. Te 2 dane wyjściowe są złożone i dla DriverUI wyglądają jak 1 obraz.

Aby to osiągnąć, HAR kontroluje przezroczystość obszarów, w których pojawia się dane wyjściowe Androida, na podstawie komunikatów o stanie z DriverUI. Gdy DriverUI jest niedostępny, HAR wykrywa brak komunikatów o stanie i renderuje obszary DriverUI jako nieprzezroczyste oraz wyświetla symbole zastępcze. Gdy komunikaty o stanie są odbierane, symbole zastępcze są usuwane, a obszary DriverUI stają się przezroczyste.

Kompozycja HAR i DriverUI

Rysunek 3. Kompozycja HAR i DriverUI.

Komunikacja między DriverUI a HAR

DriverUI i HAR komunikują się ze sobą za pomocą zdalnych wywołań procedur (RPC). Komunikat o stanie jest przykładem danych wysyłanych przez kanał RPC i zawiera sygnaturę czasową jako jedno z pól.

Do RPC używany jest gRPC. W SDV usługa SDV comms udostępnia klienta SDV Gateway, który umożliwia wykrywanie i tworzenie kanału z DriverUI do HAR. Usługa gRPC definiuje plik bufora protokołu:


// Heartbeat.
rpc Heartbeat(HeartbeatRequest) returns (HeartbeatResponse) {}

// Document switched in the DriverUI.
rpc DocumentSwitched(DocumentSwitchedRequest) returns (DocumentSwitchedResponse) {}

// Document updated in the DriverUI. Unary RPC.
rpc DocumentUpdated(DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

// Document updated in the DriverUI. Requests are streamed with each request
// containing a part of the document and the entire document is assembled from these
// chunks by the server.
rpc DocumentUpdatedStreaming(stream DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

/// Request for HAR to change design tokens.
rpc DesignTokenUpdate(DesignTokenUpdateRequest) returns (DesignTokenUpdateResponse) {}

// Request to change the current locale used in HAR.
rpc LocaleUpdate(LocaleUpdateRequest) returns (LocaleUpdateResponse) {}

// Requests to swap a certain variant at a Figma node.
rpc ChangeVariant(ChangeVariantRequest) returns (ChangeVariantResponse) {}

// Requests to change the container (display/root node) configuration (dpi, size) in HAR.
rpc ChangeContainerConfiguration(ChangeContainerConfigurationRequest) returns (ChangeContainerConfigurationResponse) {}

Szczegóły żądania i odpowiedzi znajdziesz w źródle Display Safety w packages/apps/Car/DriverUI/proto/driverui.proto w repozytorium kodu źródłowego ub-automotive.

Na platformie SDV usługa SDV comms udostępnia klienta SDV Gateway, który umożliwia wykrywanie i tworzenie kanału gRPC z DriverUI do HAR.

Wykonanie tych poleceń za pomocą terminala IVI powoduje wysłanie komunikatu do SDV Media, co wywołuje aktualizacje motywu w całym klastrze.

adb shell cmd car_service inject-key -d 1 9 # Purple Theme
adb shell cmd car_service inject-key -d 1 8 # Blue Theme

Komunikacja RPC w celu zmiany interfejsu kierowcy i motywu HAR.

Rysunek 4. Komunikacja RPC w celu zmiany motywu DriverUI i HAR.

Wyświetlanie informacji o multimediach, Mapach i połączeniach telefonicznych w klastrze

Dzięki komunikacji z IVI DriverUI może wyświetlać informacje o multimediach, Mapach i połączeniach telefonicznych w klastrze referencyjnym. Chociaż w implementacji referencyjnej multimedia są stanem domyślnym, wyświetlacz aktualizuje się na podstawie aktywnych usług według tej kolejności priorytetów:

  1. Mapy
  2. Połączenia telefoniczne
  3. Multimedia

System automatycznie traktuje priorytetowo wyświetlanie nawigacji w Mapach lub aktywnych usług telefonicznych zamiast domyślnego stanu multimediów.

Różne stany wyświetlacza DriverUI są przedstawione na tym rysunku:

DriverUI z sekcją Media i Telefonia w pełnym klastrze.

Rysunek 5. DriverUI prezentujący sekcję multimediów i połączeń telefonicznych w pełnym klastrze.

Integracja Automotive Design for Compose

DriverUI implementuje Automotive Design for Compose, aby umożliwić prezentowanie projektów (Figma) i ich iterację bezpośrednio w aplikacji na Androida. Ta integracja wypełnia lukę między projektowaniem a tworzeniem, umożliwiając renderowanie dokumentów projektowych w środowisku wykonawczym.

Dostęp do zasobów projektowych

Przykładowe dokumenty Figma dla DriverUI są częścią bazy kodu. Aby uzyskać dostęp do tych projektów i je zmodyfikować:

  1. Uruchom DriverUI z lokalnym plikiem projektu Automotive Design for Compose DCF z packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
  2. Znajdź plik zasobu packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
  3. Zaimportuj ten plik do Figmy, aby wyświetlić projekty źródłowe lub wprowadzić zmiany.

Wersja Automotive Design for Compose

  • Gradle używa wersji Automotive Design for Compose określonej dla designcompose w packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
  • Wersje Automotive Design for Compose są dostępne na stronie wersji.

Konfiguracja aktualizacji na żywo

Automotive Design for Compose obsługuje aktualizacje na żywo w trybie programowania, co umożliwia natychmiastowe renderowanie zmian wprowadzonych w Figmie w DriverUI. Ułatwia to szybkie testowanie i szybsze iteracje projektowe.

Aby ustawić token Figmy dla DriverUI, uruchom to polecenie:

adb shell am startservice \
  -n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
  -a setApiKey \
  -e ApiKey $FIGMA_ACCESS_TOKEN \
  --user 0

Synchronizacja dokumentów projektowych na 2 maszynach wirtualnych

W konfiguracji z 2 maszynami wirtualnymi aktualizacje projektu muszą być propagowane między granicami, aby zachować spójność.

  • DriverUI pobiera najnowszy dokument projektowy Figmy i przesyła go do HAR za pomocą kanałów komunikacji gRPC opisanych na tej stronie.
  • Dzięki temu cały klaster aktualizuje się do najnowszych iteracji projektu Figmy, co zapewnia synchronizację obu maszyn wirtualnych ze źródłem projektu.

Aktualizacja na żywo dokumentu projektowego z Figmy do DriverUI i HAR.

Rysunek 6. Aktualizacja na żywo dokumentu projektowego z Figmy do DriverUI i HAR.

Zabezpieczanie kanału gRPC

gRPC ma integrację z SSL i TLS oraz promuje używanie SSL i TLS do uwierzytelniania serwera i szyfrowania wszystkich danych wymienianych między klientem a serwerem. Dostępne są opcjonalne mechanizmy, które umożliwiają klientom udostępnianie certyfikatów do wzajemnego uwierzytelniania. Więcej informacji o uwierzytelnianiu gRPC znajdziesz w artykule Uwierzytelnianie.