Architektura

Większość zmian niezbędnych do obsługi VirtIO w AAOS dotyczy zmian w HAL implementacji i niższego poziomu w wspólnym jądrze Androida. Struktura Androida komunikuje się z ogólną, niezależną od sprzętu HAL, korzystając ze sterowników VirtIO w systemie gościa AAOS Jądro maszyny wirtualnej komunikujące się z urządzeniami VirtIO po stronie hosta za pomocą protokołów VirtIO. Urządzenia VirtIO po stronie hosta mają dostęp do fizycznego sprzętu za pomocą sterowników urządzenia specyficznych dla układu SoC.

Komunikacja między sterownikiem VirtIO a urządzeniem VirtIO odbywa się za pomocą virtqueue, które są podobnymi do DMA buforami pierścieniowymi list rozproszonych. Kilka środków transportu, takich jak MMIO lub PCI może być używany do wymiany komunikatów VirtIO między maszynami wirtualnymi.

W niektórych przypadkach usługa vsock była używana do komunikacji między maszynami wirtualnymi. Komunikacja dotycząca HAL, sterowania dźwiękiem i stanu zrzutu w pojeździe jest obsługiwana przez połączenie z agentem peera na osobnej maszynie wirtualnej za pomocą interfejsu vsock. GRPC-vsock służy do uzyskiwania dostępu do tych niestandaryzowanych podsystemów. GRPC w drzewie źródłowym Androida została zmodyfikowana, aby obsługiwała vsock z adresem w formacie vsock:CID:PORT_NUMBER.

Architektura wirtualizacji
Rysunek 1. Architektura wirtualizacji
.

Dźwięk

W wirtualizowanym systemie AAOS gościa z Androidem może używać virtio-snd do uzyskiwania dostępu do dźwięku. virtio-snd udostępnia zwirtualizowane urządzenia PCM maszynie wirtualnej z Androidem, dzięki czemu implementacja HAL audio może wchodzić w interakcje ze zwirtualizowanymi urządzeniami dźwiękowymi za pomocą Biblioteka TinyALSA.

Domyślna implementacja audio HAL znajduje się w AOSP pod adresem /device/google/trout/hal/audio/6.0 OEM może modyfikować ro.vendor.trout.audiohal.{in,out}_period_{ms,count} ze względu na swoją platformę. OEM może implementują własne wartości HAL audio, zastępując zmienne związane z dźwiękiem w /device/google/trout/aosp_trout_common.mk.

HAL zarządza dźwiękiem w systemie AAOS. Na przykład, gdy system odtwarza dźwięków alarmowych, muzyka odtwarzana w tle może wymagać wyciszenia. HAL do sterowania dźwiękiem powiadamia aplikacje odtwarzające muzykę o konieczności wyciszenia w tej sytuacji. W systemie zwirtualizowanym dźwięki mogą pochodzić z innych maszyn wirtualnych. W implementacji referencyjnej hostowana maszyna wirtualna AAOS ma uruchomiony demon serwera sterowania dźwiękiem, który używa GRPC-vsock do odbierania sygnału żądań skupienia dźwięku od innych maszyn wirtualnych. Główna maszyna wirtualna może używać interfejsu device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller wysyłania żądań sterowania dźwiękiem do AAOS. Z kolei libandroid_audio_controller utrzymuje ale nadal wysyła sygnały dźwiękowe do AAOS, dopóki nie zostanie zwolniony.

Architektura audio
Rysunek 5. Architektura audio
.

Bluetooth

Implementacja Bluetooth opiera się na ilustracji poniżej.

Architektura Bluetooth
Rysunek 5. Architektura Bluetooth
.

Profil Bluetooth do obsługi zestawu głośnomówiącego

Aby włączyć profil Bluetooth za pomocą zestawu głośnomówiącego (HFP) na urządzeniu trout, urządzenie dźwiękowe VirtIO specyfikacja została rozszerzona o obsługę elementów sterujących dźwiękiem. Dzięki temu dźwiękowi VirtIO po stronie hosta/hipernadzorcy udostępnia 3 elementy sterujące dźwiękiem związane z HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Gdy AAOS działa jako gość, system AAOS używa TinyAlsa do ustawiania tych elementów sterujących dźwiękiem. Aby włączyć HFP: w takim przypadku host/hipernadzorca przeprowadza kierowanie i kalibrację specyficzne dla dostawcy.

Implementacja przez Bluetooth opiera się na ilustracji poniżej.

Architektura Bluetooth
Rysunek 5. Architektura Bluetooth
.

Zrzut stanu

Podczas generowania raportu o błędzie dla zwirtualizowanego systemu AAOS warto dołączyć informacje o hostelu maszyny wirtualnej Dzięki temu deweloperzy mają pełniejszy obraz systemu. W tym celu Implementacja referencyjna trout wykorzystuje kod HAL IDumpstateDevice, który zbiera informacje o hoście maszyny wirtualnej za pomocą usługi GRPC-vsock. Maszyna wirtualna hostowana w pakiecie „tar” dane mają w raporcie o błędzie nazwę dumpstate_board.bin, podczas gdy dzienniki zrzutu są na miejscu dumpstate_board.txt

Aby skonfigurować polecenia do wykonania:

  1. Skopiuj szczegóły konfiguracji z pliku poniżej do pliku XML, na przykład: config.xml 
    <dumpstateHalConfiguration version="1.0">
    <services>
        <service name="coqos-virtio-blk"        command="/bin/journalctl --no-pager -t coqos-virtio-blk"/>
        <service name="coqos-virtio-net"        command="/bin/journalctl --no-pager -t coqos-virtio-net"/>
        <service name="coqos-virtio-video"      command="/bin/journalctl --no-pager -t coqos-virtio-video"/>
        <service name="coqos-virtio-console"    command="/bin/journalctl --no-pager -t coqos-virtio-console"/>
        <service name="coqos-virtio-rng"        command="/bin/journalctl --no-pager -t coqos-virtio-rng"/>
        <service name="coqos-virtio-vsock"      command="/bin/journalctl --no-pager -t coqos-virtio-vsock"/>
        <service name="coqos-virtio-gpu-virgl"  command="/bin/journalctl --no-pager -t coqos-virtio-gpu-virgl"/>
        <service name="coqos-virtio-scmi"       command="/bin/journalctl --no-pager -t coqos-virtio-scmi"/>
        <service name="coqos-virtio-input"      command="/bin/journalctl --no-pager -t coqos-virtio-input"/>
        <service name="coqos-virtio-snd"        command="/bin/journalctl --no-pager -t coqos-virtio-snd"/>
        <service name="dumpstate_grpc_server"   command="/bin/journalctl --no-pager -t dumpstate_grpc_server"/>
        <service name="systemd"                 command="/bin/journalctl --no-pager -t systemd"/>
        <service name="systemctl"               command="/bin/systemctl status"/>
        <service name="vehicle_hal_grpc_server" command="/bin/journalctl --no-pager -t vehicle_hal_grpc_server"/>
    </services>
    <systemLogs>
        <service name="dmesg" command="/bin/dmesg -kuPT"/>
    </systemLogs>
</dumpstateHalConfiguration>
  2. Przy uruchamianiu podaj ścieżkę nowego pliku XML do serwera dumpstate. Na przykład: 
    --config_file my_config.xml

System rozszerzonego widoku (EVS)

System Extended View System (EVS) służy do wyświetlania filmów zarejestrowanych podczas z kamerami z widokiem przestrzennym. W wirtualizowanym systemie AAOS stos EVS może uzyskać dostęp do strumienia wideo z poziomu zwirtualizowane urządzenie streamingowe V4L2 korzystające ze sterownika VirtIO-video.

Tryb garażu

Więcej informacji: Tryb garażu.

Włączanie i wyłączanie trybu garażowego jest wywoływane przez usługi w AP_POWER_STATE_REQ wysłane przez zespół HAL pojazdu. W trybie wirtualizacji tryb garażowy uruchamia się po stronie hosta. Główna maszyna wirtualna powinna być włączona, aby udostępniać urządzenia wirtualne dla maszyny wirtualnej z Androidem do momentu, gdy Android jest wyłączony. Serwer VHAL w maszynie wirtualnej hosta wysyła sygnał wyłączenia do gościa maszyny wirtualnej AAOS. Po otrzymaniu sygnału klienta VHAL maszyna wirtualna AAOS przechodzi w tryb garażowy i zaczyna wysyłać pakiet podtrzymujący aby utrzymać aktywność hosta maszyny wirtualnej.

Globalny system satelitarny (GNSS)

W trout w wersji 1.0 obsługa wirtualizacji GNSS w promieniu virtio-console dodano. Implementacja obsługuje wymianę nieprzetworzonych pomiarów i poprawek lokalizacji z gospodarzem rozmowy gościowi.

Format wymiany danych to plik CSV używany przez aplikację GnssLogger. W implementacji referencyjnej bo natywny sterownik GNSS jest niedostępny, dostępne są przykładowe dane, ale można wdrożyć bez zmian po stronie gościa. Przykładowy agent hosta jest udostępniany w kodzie źródłowym trout.

Obecna implementacja wymaga obsługi inicjowania GNSS i wspomaganej nawigacji GNSS (AGNSS). przez środowisko systemu operacyjnego hosta.

Architektura GNSS
Rysunek 2. Architektura GNSS
.

Grafika

Gdy AAOS działa jako gość wraz z innymi samochodowymi systemami operacyjnymi, Android może nie działać i mieć bezpośredni dostęp do GPU lub kontrolera wyświetlacza. W tym przypadku Mesa lub goldfish-opengl oraz sterownik virtio-gpu w maszynie wirtualnej z Androidem i na urządzeniu virtio-gpu mogą być wykorzystywane do uzyskania dostępu do GPU.

Na maszynie wirtualnej z Androidem jako gość Mesa lub goldfish-opengl koduje polecenia OpenGLES odpowiednio do strumienia galu lub automatycznie wygenerowanego strumienia GLES. virtio-gpu sterownika jądra służy do transportu. Po stronie gospodarza: virglrenderer (w przypadku Mesa) i vulkan-cereal (dla goldfish-opengl) ponownie odtwarza zdekodowany strumień poleceń na z dotychczasowego sterownika GPU. Platforma referencyjna AAOS trout obsługuje standard OpenGL ES tylko z obsługą interfejsu Vulkan, co jest spodziewane w przyszłej wersji.

Architektura graficzna
Rysunek 3. Architektura graficzna
.

Czujniki

Gdy AAOS działa jako gość jako maszyna wirtualna wraz z innymi samochodowymi systemami operacyjnymi, Android może nie mieć bezpośredniego dostępu do czujników. W tym przypadku sterownik Virtio-SCMI na Gośćska maszyna wirtualna z Androidem i urządzenie VirtIO-SCMI w maszynie wirtualnej hosta są używane do uzyskiwania dostępu do czujników. Platforma referencyjna wirtualizacji AAOS zapewnia ogólny, niezależny od sprzętu HAL czujnik HAL, który może być używany w układach SOC ARM, aby mieć dostęp do czujników.

HAL czujnika komunikuje się ze sterownikiem IIO SCMI w podsystemie IIO jądra systemu Linux który korzysta z protokołu SCMI Sensor Management Protocol udostępnianego przez ARM Interfejs SCMI (System Control and Management Interface) specyfikacja umożliwiająca wykrywanie i konfigurowanie czujników, odczytywanie danych z czujnika oraz otrzymywanie powiadomień o czujnikach zmian wartości.

Sterownik IIO SCMI korzysta ze sterownika VirtIO SCMI, który wykorzystuje transporter VirtIO zgodnie z opisem w virtio-scmi specyfikacji do wymiany wiadomości SCMI z urządzeniem VirtIO SCMI w maszynie wirtualnej hosta. VirtIO Urządzenie SCMI ma bezpośredni dostęp do czujników za pomocą sterowników specyficznych dla układów SoC.

Architektura czujnika
Rysunek 4. Architektura czujnika
.

Lokalizacja HAL czujnika

Referencyjna implementacja czujnika HAL, która korzysta z VirtIO SCMI, znajduje się pod adresem device/google/trout/hal/sensors

Konfiguracja HAL czujnika

HAL czujnika może wymagać zmodyfikowania danych czujnika otrzymanych z hosta maszyny wirtualnej, aby zapewnić zgodność Układ współrzędnych czujników w samochodzie z Androidem. Schemat konfiguracji czujnika znajduje się tutaj: device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd

OEM może zapewnić konfigurację czujnika, na przykład orientację i lokalizację, sensor_hal_configuration.xml i skopiuj plik do /odm/etc/sensors/ lub /vendor/etc/sensors/. Przykładowa konfiguracja czujnika:

<sensorHalConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module halName="android.hardware.sensors@2.0-Google-IIO-Subhal" halVersion="2.0">
            <sensors>
                <sensor name="scmi.iio.accel" type="1">
                    <configuration>
<!-- Attribute rotate denotes if HAL needs to modify the sensor data to comply with //
        the Android car sensor coordinate system -->
                        <orientation rotate="true">
               <!-- Attribute map denotes the indexes of data in sensor data received -->
               <!-- Attribute negate denotes if data needs to be negated -->
                            <x map="0" negate="false"/>
                            <y map="1" negate="true"/>
                            <z map="2" negate="true"/>
                        </orientation>
                        <location>
               <!-- Attribute x, y, z denotes location of the sensor placement -->
                            <x>10</x>
                            <y>15</y>
                            <z>20</z>
                        </location>
                    </configuration>
                </sensor>
         </sensors>
        </module>
    </modules>
</sensorHalConfiguration>

HAL pojazdu

Implementacja HAL pojazdu składa się z 2 elementów:

  • Klient. Udostępnia interfejsy API używane przez Androida w wirtualizowanym systemie AAOS
  • Serwer. komunikuje się bezpośrednio ze sprzętem, na przykład autobusem samochodowym; (lub emulatora).

W przypadku wirtualizacji serwer VHAL działa na hoście maszyny wirtualnej. Komunikacja między klientem a serwerem VHAL do GRPC-vsock (więcej informacji znajdziesz w artykule device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). OEM może używać przez zastąpienie interfejsów API komunikacyjnych innego protokołu transportowego niż GRPC. Na przykład: zobacz device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

Inne podsystemy

VirtIO ma już dobrze zdefiniowany interfejs dla komponentów takich jak Block Storage Sieć, konsola, wejście, gniazdo i entropia. W tych podsystemach AAOS używa kierowca w stanie, w jakim jest, np. virtio-blk, virtio-input, virtio-console i virtio-net.

Na zwirtualizowanej platformie referencyjnej AAOS sieć Wi-Fi jest obsługiwana przez mac80211_hwsim aby włączyć sieć bezprzewodową VirtWifi, która następnie używa tunelu virtio-net wysyłanie ruchu sieciowego do hosta maszyny wirtualnej, która ma bezpośredni dostęp do rzeczywistej sieci Wi-Fi.