Warstwa abstrakcji platformy HAR

Użyj mechanizmu renderowania 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 unikalne biblioteki audio.

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

Kod podsystemu dla konkretnej platformy może działać w tym samym procesie co aplikacja oparta na HAR lub w osobnym. W przypadku rozdzielenia ten kod obsługuje komunikację między procesami (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 dotyczące plików HAR, i znaleźć nowe problemy.

Terminologia

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

Aplikacja oparta na HAR
Aplikacja OEM lub aplikacja do określonych funkcji utworzona za pomocą platformy HAR. Aplikacje różnią się stanem i innymi aspektami, które można dostosować.
Platforma HAR
Zapewnia podstawowy zestaw narzędzi do tworzenia aplikacji.
Abstrakcja platformy HAR
Część platformy 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ą platformę HAR na danej platformie.

Wykracza poza zakres

HAR nie obejmuje:

  • Indywidualne implementacje dla wszystkich platform docelowych: implementacje dla platform docelowych. Zamiast tego na tej stronie opisano interfejsy, które muszą być spełnione przez implementacje platformy i zestaw testów.

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

Struktura crate wysokiego poziomu abstrakcji platformy

Projekty Rust składają się z kontenerów. Rysunek 1 przedstawia strukturę crate warstwy abstrakcji platformy HAR. Warstwa abstrakcji platformy wpływa na co najmniej 2 skrzynki Rusta:

  • Abstrakcje (opisy Rust trait) znajdują się w skrzynce platformy HAR.

  • Implementacje dla platformy są realizowane przez osobny crate har-platform-x. Na przykład har-platform-linux lub har-platform-android.

Nie możesz utworzyć ani przetestować skrzynki HAR bez określonej implementacji platformy. Jest to zamierzone, ponieważ HAR to platforma.

Aplikacja, która określa platformę, musi być utworzona za pomocą tej platformy, aby działać i być testowana. Połączenia między platformą HAR a platformą są przedstawione na tym diagramie:

Skrzynka HAR

Rysunek 1. Skrzynka HAR.

Ogólna struktura w display-safety

Ten projekt dodaje do repozytorium display_safety serię nowych skrzynek, jak pokazano na rysunku 2:

Skrzynka, platforma i aplikacja HAR

Rysunek 2. Moduły abstrakcji.

Zestaw testów jest strukturalnie podobny do aplikacji, ale opiera się tylko na skrzynce implementacji danej platformy. Zestaw 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 zależne od platformy, które są 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 ramach crate HAR.
Audio Renderowanie dźwięku Udostępnia interfejs podobny do Android SoundPool, który umożliwia zarządzanie dźwiękiem systemowym i jego odtwarzanie.
Camera Wyświetlacz kamery pojazdu Zapewnia interfejs podobny do EVS HAL, który umożliwia zarządzanie informacjami z kamery pojazdu i ich wyświetlanie.
Looper Główna pętla aplikacji i konfiguracja wyświetlania Zapewnia interfejs podobny do Android Looper do zarządzania głównymi pętlami aplikacji i konfiguracją wyświetlania na danej platformie.
UserInput dotyk, klawiatura, kierownica lub kontroler obrotowy i inne dane wejściowe specyficzne dla platformy. Udostępnia interfejs do obsługi aplikacji opartych na HAR za pomocą dotyku i klawiatury. Przykładowa implementacja oparta na systemie Linux evdev w har-user-input-evdev.
VehicleData Dane wejściowe stanu pojazdu Udostępnia interfejs, który umożliwia dostarczanie aplikacjom HAR strumienia dowolnych danych pojazdu, takich jak dane dostarczane przez Android VHAL lub magistralę CAN.
ResourceManager Dokument projektowy zapisany w pamięci podręcznej aplikacji Zapewnia pamięć podręczną pamięci RAM dla zasobów niezbędnych do uruchomienia HAR, takich jak obrazy i dokumenty projektowe w pamięci podręcznej. Nie zaimplementowano jeszcze pamięci podręcznej na dysku.
Logging Logowanie systemowe i telemetria Zapewnia obsługę logowania na danej platformie za pomocą systemu śledzenia. Umożliwia to zbieranie danych telemetrycznych zgodnie z wymaganiami platformy.
Tracing Śledzenie systemu Zapewnia abstrakcję na potrzeby 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 z wykorzystaniem serializacji protobuf. Wycofane: używaj interfejsów API zdefiniowanych w reference/harry-control-api oraz implementacji harry-grpcio-server i harry-tonic-server (implementacja referencyjna).
TestSupport Testowanie punktów zaczepienia pomocy Obsługuje tworzenie i usuwanie elementów testowania, generowanie zdarzeń testowych oraz tworzenie artefaktów testowych. Na przykład generowanie symulowanych zdarzeń dotknięcia w celu przetestowania UserInput i generowanie zrzutów ekranu do analizy. Ta funkcja jest blokowana przez Rust, aby zapobiec jej uwzględnieniu w kompilacjach produkcyjnych.

Konwencje nazewnictwa i struktury platform

W tej tabeli znajdziesz nazwy i struktury:

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

  • Oczekiwane nazwy implementacji podsystemów związanych z daną platformą w dowolnym crate platformy. Aplikacje oparte na HAR oczekują, że te konkretne nazwy zostaną zaimplementowane.

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

Nazwy cech Nazwy implementacji Typ wyliczeniowy 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 sprawdzenia typów Result, które zawierają błędy. Jeśli nie, kompilator wygeneruje ostrzeżenie lub błąd. Sprawdzanie w czasie kompilacji wymusza sprawdzanie błędów w kodzie na danej platformie.

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

Typ harry::error::Error rozszerza się, aby uwzględnić konkretne błędy we wszystkich podsystemach:

// 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),
}

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

Szczegółowy projekt zestawu testów

W tej sekcji opisano projekt zestawu testów, który weryfikuje implementacje abstrakcji na poszczególnych platformach.

Tworzenie testów w zestawie testów

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

Uruchamianie zestawu testów

Aby przetestować pojedynczą platformę, użyj polecenia atest z odpowiednim celem testu (np. atest <module_name>). To polecenie wdraża i uruchamia testy na urządzeniu lub emulatorze z Androidem.