Architektura

Większość zmian wymaganych do obsługi VirtIO w AAOS obejmuje zmiany na poziomie implementacji HAL i poniżej w wspólnym jądrze Androida. Platforma Androida komunikuje się z ogólnym, niezależnym od sprzętu interfejsem HAL za pomocą sterowników VirtIO w jądrze maszyny wirtualnej gościa AAOS, które komunikują się z urządzeniami VirtIO po stronie hosta za pomocą protokołów VirtIO. Urządzenia VirtIO po stronie hosta mogą uzyskiwać dostęp do fizycznego sprzętu za pomocą sterowników urządzeń specyficznych dla SoC.

Komunikacja między sterownikiem VirtIO a urządzeniem VirtIO odbywa się za pomocą virtqueue, czyli buforów pierścieniowych DMA list rozproszonych. Do wymiany komunikatów VirtIO między maszynami wirtualnymi można używać kilku transportów, takich jak MMIO czy PCI.

W niektórych przypadkach do komunikacji między maszynami wirtualnymi używany jest protokół vsock. Komunikacja z interfejsem HAL pojazdu, sterowaniem dźwiękiem i Dumpstate jest obsługiwana za pomocą połączenia z agentem równorzędnym na osobnej maszynie wirtualnej przez interfejs vsock. Do uzyskiwania dostępu do tych niestandardowych podsystemów używany jest protokół GRPC-vsock. Protokół GRPC w drzewie źródłowym Androida został zmodyfikowany tak, aby działał z protokołem vsock w formacie adresu vsock:CID:PORT_NUMBER.

Architektura wirtualizacji
Rysunek 1. Architektura wirtualizacji

Dźwięk

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

Domyślna implementacja HAL dźwięku znajduje się w AOSP w lokalizacji /device/google/trout/hal/audio/6.0. Producenci OEM mogą modyfikować ro.vendor.trout.audiohal.{in,out}_period_{ms,count} na potrzeby swojej platformy. Producenci OEM mogą też zaimplementować własny interfejs HAL dźwięku, zastępując zmienne związane z dźwiękiem w /device/google/trout/aosp_trout_common.mk.

Interfejs HAL sterowania dźwiękiem zarządza aktywnością audio w AAOS. Na przykład, gdy system odtwarza dźwięki alarmowe, odtwarzanie muzyki w tle może wymagać wyciszenia. Interfejs HAL sterowania dźwiękiem powiadamia aplikacje odtwarzające muzykę, aby w takiej sytuacji wyciszyły dźwięk. W zwirtualizowanym systemie dźwięki mogą pochodzić z innych maszyn wirtualnych. W implementacji referencyjnej maszyna wirtualna gościa AAOS ma uruchomionego demona serwera sterowania dźwiękiem, który używa protokołu GRPC-vsock do odbierania żądań aktywności audio z innych maszyn wirtualnych. Maszyna wirtualna hosta może używać device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller do wysyłania żądań sterowania dźwiękiem do AAOS. Gdy libandroid_audio_controller ma aktywność audio, wysyła pakiety podtrzymujące do AAOS, dopóki aktywność audio nie zostanie zwolniona.

Architektura audio
Rysunek 5. Architektura dźwięku

Bluetooth

Implementacja Bluetooth jest oparta na projekcie przedstawionym poniżej.

Architektura Bluetooth
Rysunek 5. Architektura Bluetooth

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

Aby włączyć profil zestawu głośnomówiącego Bluetooth (HFP) na urządzeniu trout, rozszerzono specyfikację urządzenia dźwiękowego VirtIO o obsługę sterowania dźwiękiem. Dzięki temu urządzenie dźwiękowe VirtIO po stronie hosta/hiperwizora udostępnia te 3 elementy sterowania dźwiękiem związane z HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Gdy AAOS działa jako maszyna wirtualna gościa, AAOS używa TinyAlsa do ustawiania tych elementów sterowania dźwiękiem. Aby włączyć przypadek użycia HFP, host/hipernadzorca wykonuje odpowiednio routing i kalibrację specyficzne dla dostawcy.

Implementacja Bluetooth jest oparta na projekcie przedstawionym poniżej.

Architektura Bluetooth
Rysunek 5. Architektura Bluetooth

Dumpstate

Podczas generowania raportu o błędach w przypadku zwirtualizowanego AAOS warto uwzględnić informacje o maszynie wirtualnej hosta, aby deweloperzy mieli pełniejszy obraz systemu. Aby to osiągnąć, implementacja referencyjna trout implementuje interfejs HAL IDumpstateDevice, który zbiera informacje o maszynie wirtualnej hosta za pomocą protokołu GRPC-vsock. Informacje o maszynie wirtualnej hosta spakowane w formacie `tar` są w raporcie o błędach nazywane dumpstate_board.bin, a zrzuty logów – dumpstate_board.txt.

Aby skonfigurować polecenia do wykonania:

  1. Skopiuj szczegóły konfiguracji z pliku poniżej do pliku XML, np. 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. Podczas uruchamiania przekaż ścieżkę do nowego pliku XML do serwera dumpstate. Przykład: 
    --config_file my_config.xml

Rozszerzony system widoku (EVS)

Rozszerzony system widoku (EVS) służy do wyświetlania obrazu wideo zarejestrowanego przez kamery cofania i kamery 360 stopni. W zwirtualizowanym AAOS stos EVS może uzyskiwać dostęp do strumienia wideo ze zwirtualizowanego urządzenia przesyłającego strumień V4L2, które używa sterownika VirtIO-video.

Tryb garażowy

Więcej informacji znajdziesz w artykule Tryb garażowy.

Włączanie i wyłączanie trybu garażowego jest wywoływane przez właściwości AP_POWER_STATE_REQ wysyłane przez interfejs HAL pojazdu. W trybie wirtualizacji tryb garażowy jest wywoływany po stronie hosta. Maszyna wirtualna hosta powinna pozostać włączona, aby udostępniać wirtualne urządzenia maszynie wirtualnej Androida, dopóki Android nie zostanie wyłączony. Serwer VHAL na maszynie wirtualnej hosta wysyła sygnał wyłączenia do maszyny wirtualnej gościa AAOS. Po otrzymaniu sygnału klient VHAL maszyny wirtualnej AAOS przechodzi w tryb garażowy i zaczyna wysyłać sygnały utrzymania połączenia, aby utrzymać aktywność maszyny wirtualnej hosta.

Globalny system nawigacji satelitarnej (GNSS)

W trout 1.0 dodano obsługę wirtualizacji GNSS za pomocą virtio-console. Implementacja obsługuje wymianę surowych pomiarów i poprawek lokalizacji między hostem a gościem.

Format wymiany danych to CSV używany przez aplikację GnssLogger. W implementacji referencyjnej, ponieważ natywny sterownik GNSS jest niedostępny, udostępniane są dane pozorowane, ale można zaimplementować natywny sterownik bez wprowadzania zmian po stronie gościa. Przykładowy agent pozorowany hosta jest dostępny w ramach kodu źródłowego trout.

Obecna implementacja wymaga, aby inicjowanie GNSS i wspomagany GNSS (AGNSS) były obsługiwane przez środowisko systemu operacyjnego hosta.

Architektura GNSS
Rysunek 2. Architektura GNSS

Grafika

Gdy AAOS działa jako maszyna wirtualna gościa obok innych samochodowych systemów operacyjnych, Android może nie mieć bezpośredniego dostępu do GPU ani kontrolera wyświetlania. W takim przypadku, Mesa lub goldfish-opengl i sterownik virtio-gpu na maszynie wirtualnej gościa Androida oraz urządzenie virtio-gpu mogą być używane do uzyskiwania dostępu do GPU.

Na maszynie wirtualnej gościa Androida Mesa lub goldfish-opengl koduje polecenia OpenGLES odpowiednio do strumienia Gallium lub automatycznie wygenerowanego strumienia GLES. Jako transportu używany jest sterownik jądra virtio-gpu. Po stronie hosta virglrenderer (w przypadku Mesa) i vulkan-cereal (w przypadku goldfish-opengl) odtwarzają zdekodowany strumień poleceń na istniejącym sterowniku GPU. Platforma referencyjna AAOS trout obsługuje OpenGL ES tylko z obsługą Vulkan, która jest planowana w przyszłej wersji.

Architektura graficzna
Rysunek 3. Architektura grafiki

Czujniki

Gdy AAOS działa jako maszyna wirtualna gościa obok innych samochodowych systemów operacyjnych, Android może nie mieć bezpośredniego dostępu do czujników. W takim przypadku do uzyskiwania dostępu do czujników używane są sterownik Virtio-SCMI na maszynie wirtualnej gościa Androida i urządzenie VirtIO-SCMI na maszynie wirtualnej hosta. Referencyjna platforma wirtualizacji AAOS udostępnia ogólny i niezależny od sprzętu interfejs HAL czujników, którego można używać w przypadku SoC opartych na architekturze ARM do uzyskiwania dostępu do czujników.

Interfejs HAL czujników komunikuje się ze sterownikiem IIO SCMI w podsystemie IIO jądra Linux, który używa protokołu zarządzania czujnikami SCMI udostępnianego przez specyfikację interfejsu sterowania i zarządzania systemem ARM (SCMI) do wykrywania i konfigurowania czujników, odczytywania danych z czujników oraz otrzymywania powiadomień o zmianach wartości czujników.

Sterownik IIO SCMI używa sterownika VirtIO SCMI, który używa protokołu transportowego VirtIO określonego w specyfikacji virtio-scmi do wymiany komunikatów SCMI z urządzeniem VirtIO SCMI na maszynie wirtualnej hosta. Urządzenie VirtIO SCMI ma bezpośredni dostęp do czujników za pomocą sterowników czujników specyficznych dla SoC.

Architektura czujnika
Rysunek 4. Architektura czujników

Lokalizacja interfejsu HAL czujników

Implementacja referencyjna interfejsu HAL czujników, która używa VirtIO SCMI, znajduje się w lokalizacji device/google/trout/hal/sensors.

Konfiguracja interfejsu HAL czujników

Interfejs HAL czujników może wymagać modyfikacji danych z czujników otrzymanych z maszyny wirtualnej hosta, aby były zgodne z układem współrzędnych czujników samochodowych Androida. Schemat konfiguracji czujników znajdziesz w pliku device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

Producenci OEM mogą podać konfigurację czujników, np. orientację i lokalizację, w pliku sensor_hal_configuration.xml i skopiować ten plik do lokalizacji /odm/etc/sensors/ lub /vendor/etc/sensors/. Przykładowa konfiguracja czujników jest podana poniżej:

<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>

Interfejs HAL pojazdu

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

  • Klient Udostępnia interfejsy API używane przez Androida w zwirtualizowanym AAOS.
  • Serwer Komunikuje się bezpośrednio ze sprzętem, np. z magistralami pojazdu (lub emulatorem).

W wirtualizacji serwer VHAL działa na maszynie wirtualnej hosta. Klient i serwer VHAL komunikują się za pomocą protokołu GRPC-vsock (więcej informacji znajdziesz w pliku device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). Producenci OEM mogą używać innego protokołu transportowego niż GRPC, zastępując interfejsy API komunikacji. Przykłady znajdziesz w plikach device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

Inne podsystemy

VirtIO udostępnia już dobrze zdefiniowany interfejs dla komponentów takich jak pamięć blokowa, sieć, konsola, wejście, gniazdo i entropia. W przypadku tych podsystemów AAOS używa sterownika w niezmienionej postaci, np. virtio-blk, virtio-input, virtio-console i virtio-net.

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