DriverUI

Interfejs panelu wskaźników jest zwykle umieszczany za kierownicą na osobnym wyświetlaczu. Producenci OEM stopniowo łączą panel wskaźników i samochodowy system multimedialny w jeden wyświetlacz. Ten połączony interfejs to DriverUI.

Rysunek 1. DriverUI.

DriverUI to aplikacja systemowa na Androida, która renderuje cały wyświetlacz zestawu wskaźników, z wyjątkiem elementów związanych z bezpieczeństwem lub przepisami, które są renderowane przez mechanizm renderowania o wysokiej dostępności (HAR). Interfejs kierowcy wyświetla informacje związane z odtwarzaniem multimediów, połączeniami telefonicznymi, mapami, nawigacją i innymi funkcjami 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 używa klasy ClusterHomeManager, nazywanej też Cluster2, do tworzenia zestawów wskaźników. Ta klasa określa konfigurację potrzebną do zidentyfikowania implementacji panelu wskaźników i sposobu, w jaki AAOS z nią współdziała. Google udostępnia przykładowe implementacje interfejsów API Cluster2.

Platformy

Możesz utworzyć i uruchomić funkcję Display Safety na SDV. Platforma pojazdów definiowanych programowo (SDV):

• Wymaga 2 maszyn wirtualnych gościa.
• Uruchamia HAR w SDV Media (nazywanym też maszyną wirtualną z szybkim rozruchem) na maszynie wirtualnej gościa.
• Uruchamia DriverUI w innej maszynie wirtualnej gościa SDV IVI.
• Uruchamia monitor bezpieczeństwa na maszynie wirtualnej SDV Media.

Rysunek 2. Architektura platformy SDV.

Połącz dane wyjściowe HAR i DriverUI

HAR i DriverUI używają oddzielnych wyświetlaczy do renderowania interfejsu. Te 2 wyjścia są połączone i wyświetlane w interfejsie DriverUI jako 1 obraz.

Aby to osiągnąć, HAR kontroluje przezroczystość obszarów, w których pojawiają się dane wyjściowe Androida, na podstawie komunikatów o pulsie z DriverUI. Gdy interfejs DriverUI jest niedostępny, HAR wykrywa brak sygnałów i renderuje obszary DriverUI jako nieprzezroczyste oraz wyświetla obiekty zastępcze. Po odebraniu sygnałów bicia serca obiekty zastępcze są usuwane, a obszary interfejsu kierowcy są ustawiane jako przezroczyste.

Rysunek 3. Kompozycja HAR i DriverUI.

Rozwiązywanie problemów z kompozycją alfa i przebijaniem

Ponieważ HAR ma kluczowe znaczenie dla bezpieczeństwa, jego płaszczyzna wyświetlania sprzętowego znajduje się nad płaszczyzną wyświetlania samochodowego systemu multimedialnego Androida. Podczas tworzenia lub debugowania widoków niestandardowych lub zewnętrznych powierzchni OpenGL ES w HAR sprawdź, jak są ustawione wartości alfa:

• Brak danych wyjściowych DriverUI pod płaszczyzną HAR: chociaż HAR otrzymuje prawidłowe komunikaty HeartbeatRequest z DriverUI, musi wyczyścić region widocznego obszaru DriverUI do przezroczystego (alpha = 0.0), aby widoczny był podstawowy interfejs klastra Androida. Jeśli niestandardowa warstwa lub tło HAR rysuje nieprzezroczyste piksele (alpha = 1.0) nad obszarem DriverUI, blokuje to dane wyjściowe Androida pod spodem.
• Niezamierzone przezroczyste otwory w niestandardowych powierzchniach 3D lub OpenGL: gdy renderujesz zewnętrzną powierzchnię OpenGL ES lub 3D w węźle HAR (np. niestandardowy wskaźnik 3D lub scenę, która zapisuje piksele RGB z nieużywanym bajtem alfa pozostawionym na poziomie 0x00), ustaw kanał alfa nieprzezroczystych pikseli na 0xFF (alpha = 1.0). Pozostawienie bajtu alfa na poziomie 0x00 powoduje, że kompozytor traktuje te piksele jako przezroczyste (alpha = 0.0) i tworzy otwór bezpośrednio przez warstwę HAR do podstawowej płaszczyzny Androida IVI.
• Diagnostyka wyświetlania na różnych maszynach wirtualnych: ponieważ HAR (sdv_media_har_cf) i Android IVI (sdv_ivi_cf_ds) działają na oddzielnych maszynach wirtualnych gościa, uruchomienie adb shell dumpsys SurfaceFlinger na maszynie wirtualnej Android IVI sprawdza tylko warstwy Androida i nie ma wglądu w warstwę HAR.

Komunikacja między DriverUI i HAR

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

gRPC jest używany do wywołań RPC. W SDV komunikacja SDV udostępnia klienta bramy SDV, który umożliwia wykrywanie i ustanawianie kanału między interfejsem DriverUI a 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 znajdują się w źródle Display Safety w pliku packages/apps/Car/DriverUI/proto/driverui.proto w repozytorium kodu źródłowego ub-automotive.

Na platformie SDV komunikacja SDV zapewnia klienta bramy SDV do wykrywania i ustanawiania kanału gRPC z interfejsu DriverUI do HAR.

Wykonanie tych poleceń za pomocą terminala samochodowego systemu multimedialnego powoduje wysłanie komunikatu do SDV Media, co wywołuje aktualizacje motywów 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

Rysunek 4. Komunikacja RPC umożliwiająca zmianę motywu DriverUI i HAR.

Wyświetlanie informacji o multimediach, mapach i telefonii na klastrze

Dzięki komunikacji z samochodowym systemem multimedialnym interfejs kierowcy może wyświetlać informacje o multimediach, mapach i połączeniach telefonicznych w ramach klastra referencyjnego. Chociaż w implementacji referencyjnej stanem domyślnym są multimedia, wyświetlane informacje są aktualizowane na podstawie aktywnych usług zgodnie z tymi priorytetami:

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

System automatycznie traktuje priorytetowo wyświetlanie nawigacji w Mapach lub aktywnych usług telefonicznych, a nie domyślny stan multimediów.

Różne stany wyświetlania interfejsu DriverUI są przedstawione na poniższym rysunku:

Rysunek 5. Interfejs kierowcy z sekcją multimediów i telefonii w pełnym klastrze.

Integracja Automotive Design for Compose

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

Dostęp do zasobów projektowych

Przykładowe dokumenty Figma dotyczące interfejsu 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 programisty, dzięki czemu zmiany wprowadzone w Figmie są natychmiast renderowane w DriverUI. Umożliwia to szybkie testowanie i krótsze cykle iteracji projektu.

Uruchom to polecenie, aby ustawić token Figma dla DriverUI:

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 między 2 maszynami wirtualnymi

W konfiguracji z 2 maszynami wirtualnymi aktualizacje projektu muszą być propagowane przez granice, aby zachować spójność.

• DriverUI pobiera najnowszy dokument projektu Figma i przesyła go do HAR za pomocą kanałów komunikacyjnych gRPC opisanych na tej stronie.
• W rezultacie cały klaster zostanie zaktualizowany o najnowsze iteracje projektu Figma, dzięki czemu obie maszyny wirtualne będą zsynchronizowane ze źródłem projektu.

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 dostarczanie certyfikatów na potrzeby uwierzytelniania wzajemnego. Więcej informacji o uwierzytelnianiu gRPC znajdziesz w artykule Uwierzytelnianie.