Warstwa abstrakcji platformy HAR

Użyj renderera o wysokiej dostępności (HAR), aby wyświetlać informacje o pojeździe, których Android nie może wyświetlić. Może to być spowodowane problemami z uruchomieniem, dostępnością, bezpieczeństwem lub przepisami. HAR to przenośna, wbudowana aplikacja napisana w języku Rust.

HAR, czyli platforma HAR, zawiera kod, którego używasz do tworzenia aplikacji. Aplikacja utworzona za pomocą HAR to aplikacja oparta na HAR. Platforma HAR zawiera sekcje kodu dla różnych platform. Na przykład w systemie Linux do obsługi dźwięków używasz bibliotek takich jak tinyalsa. QNX ma własne biblioteki audio.

Platforma obejmuje sprzęt, system operacyjny, biblioteki systemowe i inne czynniki. Kod specyficzny dla platformy ma części zwane podsystemami. Każdy podsystem obsługuje jedną funkcję platformy, np. dźwięk, kamery EVS lub dane pojazdu. Aby obsługiwać platformę, struktura HAR musi mieć zaimplementowane wszystkie podsystemy.

Kod podsystemu specyficzny dla platformy może działać w tym samym procesie co aplikacja oparta na HAR lub w osobnym procesie. Gdy jest oddzielny, ten kod obsługuje komunikację międzyprocesową (IPC), aby pomóc w sprawdzeniu, czy platforma obsługuje aplikację. Złożone mechanizmy IPC muszą być częścią kodu specyficznego dla platformy.

Zestaw testów HAR przeprowadza testy wszystkich podsystemów zaimplementowanych na platformie. Użyj tego pakietu, aby sprawdzić, czy platformy spełniają wymagania HAR, i wykryć nowe problemy.

Terminologia

Te hasła znajdują się na tej stronie:

Aplikacja oparta na HAR
Aplikacja OEM lub aplikacja przeznaczona do konkretnych funkcji, utworzona przy użyciu platformy HAR. Aplikacje różnią się stanem i innymi aspektami, które można dostosować.
Framework HAR
Zawiera podstawowy zestaw narzędzi do tworzenia aplikacji.
Abstrakcja platformy HAR
Część struktury HAR, która udostępnia znany interfejs API, który muszą wdrożyć wszystkie platformy docelowe.
Zestaw testów HAR
Seria znanych testów implementacji platformy, które pomagają sprawdzić, czy implementacje platformy obsługują strukturę HAR na danej platformie.

Wykracza poza zakres

HAR nie obejmuje:

  • Osobne wdrożenia dla wszystkich platform docelowych: wdrożenia dla platform docelowych. Zamiast tego opisujemy interfejsy, które muszą być zaimplementowane na platformie, oraz zestaw testów, który musi być spełniony.

  • Elementy testowania: konkretne elementy testowania dla wszystkich interfejsów. Zamiast tego na tej stronie opisujemy poszczególne funkcje interfejsów, w tym argumenty, wartości zwracane, oczekiwane działania i oczekiwane efekty uboczne. Na tej stronie opisujemy zestaw testów, w którym możesz wdrażać i uruchamiać przypadki testowe.

Ogólna struktura pakietu abstrakcji platformy

Projekty w Rust składają się z pakietów. Ilustracja 1 przedstawia strukturę pakietu warstwy abstrakcji platformy HAR. Warstwa abstrakcji platformy wpływa na co najmniej 2 pakiety Rust:

  • Abstrakcje (opisy w języku Rusttrait) znajdują się w pakiecie HAR framework.

  • Implementacje dla platformy są dostępne w osobnej har-platform-x skrzynce. Na przykład har-platform-linux lub har-platform-android.

Nie możesz skompilować ani przetestować pakietu HAR bez określonej implementacji platformy. Jest to celowe, ponieważ HAR to platforma.

Aplikacja, która określa platformę, musi być zbudowana przy użyciu tego frameworka, aby działać i być testowana. Połączenia między platformą a strukturą HAR przedstawia ten diagram:

Skrzynia HAR

Rysunek 1. Skrzynia HAR.

Ogólna struktura w sekcji display-safety

W tym projekcie dodano do repozytorium display_safety serię nowych pakietów, jak pokazano na rysunku 2:

Pakiet, platforma i aplikacja HAR

Rysunek 2. Moduły abstrakcji.

Zestaw testów jest strukturalnie podobny do aplikacji, ale opiera się tylko na danym pakiecie implementacji platformy. Pakiet testów musi odwoływać się do cech i struktur zdefiniowanych w ramach HAR, ale nie powinien odwoływać się do bardziej złożonych implementacji.

Ogólny opis warstwy abstrakcji platformy

W tej tabeli opisano podsystemy specyficzne dla platformy zdefiniowane przez warstwę abstrakcji platformy HAR.

Nazwa abstrakcji Powiązana funkcja Opis Uwagi
OpenGL Renderowanie 2D Zapewnia możliwości renderowania OpenGLES 2.0/3.0 w pakiecie HAR.
Audio Renderowanie dźwięku Zapewnia interfejs podobny do Android SoundPool do zarządzania dźwiękiem systemowym i jego odtwarzania.
Camera Wyświetlacz kamery w pojeździe Zapewnia interfejs podobny do EVS HAL do zarządzania informacjami z kamer samochodowych i ich wyświetlania.
Looper Główna pętla aplikacji i konfiguracja wyświetlania Udostępnia interfejs podobny do Android Looper do zarządzania głównymi pętlami aplikacji na poszczególnych platformach i konfiguracją wyświetlania.
UserInput dotyk, klawiatura, kierownica lub kontroler obrotowy oraz inne dane wejściowe specyficzne dla platformy. Udostępnia interfejs do dostarczania danych wejściowych z klawiatury i ekranu dotykowego do aplikacji opartych na HAR. Implementacja referencyjna oparta na systemie Linux evdev w har-user-input-evdev.
VehicleData Dane wejściowe stanu pojazdu Udostępnia interfejs do dostarczania aplikacjom opartym na HAR strumienia dowolnych danych pojazdu, takich jak dane dostarczane przez Android VHAL lub magistralę CAN.
ResourceManager Dokument projektu w pamięci podręcznej konkretnej aplikacji Zapewnia pamięć podręczną w pamięci RAM zasobów niezbędnych do uruchomienia HAR, takich jak obrazy w pamięci podręcznej i dokumenty projektowe. Pamięć podręczna na dysku nie została jeszcze zaimplementowana.
Logging Logowanie systemowe i dane telemetryczne Zapewnia obsługę logowania na konkretnej platformie za pomocą systemu śledzenia. Umożliwia to zbieranie danych telemetrycznych wymaganych przez platformę.
Tracing Śledzenie systemu Udostępnia abstrakcję do integracji z systemami śledzenia i profilowania.
Monitoring Monitorowanie systemu Zestaw narzędzi do monitorowania wydajności i opóźnień w ramach HAR.
Commlib Dane w pojeździe Implementacja referencyjna korzystająca z serializacji protobuf. Wycofano: używaj interfejsów API zdefiniowanych w reference/harry-control-api i implementacjach harry-grpcio-server oraz harry-tonic-server (implementacja referencyjna).
TestSupport Punkty zaczepienia pomocy dotyczącej testowania Umożliwia tworzenie i usuwanie elementów testowania, generowanie zdarzeń testowych i tworzenie artefaktów testowych. Może to być na przykład generowanie symulowanych zdarzeń dotykowych na potrzeby testowania UserInput lub generowanie zrzutów ekranu na potrzeby analizy. Ta funkcja jest zablokowana przez język Rust, aby uniemożliwić jej uwzględnienie w kompilacjach produkcyjnych.

Konwencje nazewnictwa i struktury platformy

W tej tabeli znajdziesz te nazwy i struktury:

  • Oczekiwane instancje podsystemu trait dostarczane przez platformę HAR. Każdy element trait reprezentuje podsystem specyficzny dla danej platformy, który musi zostać wdrożony.

  • Oczekiwane nazwy implementacji podsystemów specyficznych dla platformy w dowolnym pakiecie platformy. Aplikacje oparte na HAR oczekują wdrożenia tych konkretnych nazw.

  • Powiązane instancje interfejsu HAR enum i struct, które są zwykle używane do przekazywania informacji z implementacji związanych z platformą do interfejsu HAR.

Nazwy cech Nazwy implementacji Wyliczenia i struktury platformy HAR
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (Struct) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing Nie dotyczy
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

Błędy i obsługa błędów

Proponowane interfejsy API używają typu Result<> w języku Rust. Rust wymaga sprawdzania Resulttypów, które zawierają błędy. W przeciwnym razie kompilator wygeneruje ostrzeżenie lub błąd. Sprawdzanie w czasie kompilacji wymusza sprawdzanie błędów w kodzie specyficznym dla platformy.

Błędy zwracane przez implementacje platformy są typu harry::error::Error. Aby sprawdzić, czy typy błędów platformy nie przenikają do kodu aplikacji, użyj standardowego typu błędu udostępnianego przez platformę HAR.

Typ harry::error::Error obejmuje konkretne błędy wszystkich podsystemów:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

Błędy nieodwracalne są zwracane głównie przez zdefiniowane interfejsy i wywołania zwrotne.

Szczegółowy projekt zestawu testów

W tej sekcji opisujemy strukturę zestawu testów, który weryfikuje implementacje abstrakcji specyficzne dla platformy.

Tworzenie testów w zestawie testów

W przypadku kompilacji Soong (zdefiniowanych przez pliki Android.bp) testy są kompilowane w ramach systemu kompilacji platformy Android, a ich wykonywaniem zarządza atest.

Uruchamianie zestawu testów

Aby przetestować poszczególne platformy:

Użyj polecenia atest z odpowiednim celem testu (np. atest <module_name>). To polecenie wdraża i uruchamia testy na urządzeniu z Androidem lub emulatorze.