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 wiadomości 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 (VHAL), 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 przez vsock. Protokół gRPC w drzewie źródłowym Androida jest modyfikowany 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, muzyka odtwarzana 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 uruchomiony demon serwera sterowania dźwiękiem, który używa protokołu gRPC przez 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 2. Architektura dźwięku.

Bluetooth

Implementację Bluetooth przedstawia ten rysunek:

Architektura Bluetooth

Rysunek 3. Architektura Bluetooth.

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

Aby włączyć profil zestawu głośnomówiącego Bluetooth (HFP) w trout, rozszerzyliśmy 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, 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 tym schemacie:

Architektura Bluetooth

Rysunek 4. Architektura Bluetooth.

Dumpstate

Podczas generowania raportu o błędach w zwirtualizowanym 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 przez vsock. Informacje o maszynie wirtualnej hosta spakowane w formacie tar są w raporcie o błędach nazywane dumpstate_board.bin, a zrzuty logów znajdują się w pliku dumpstate_board.txt.

Aby skonfigurować polecenia do wykonania:

  1. Skopiuj szczegóły konfiguracji z tego pliku 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, np.: 
    --config_file my_config.xml

Rozszerzony system widoku

Rozszerzony system widoku (EVS) wyświetla obraz zarejestrowany 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

Włączanie i wyłączanie trybu garażowego jest wywoływane przez właściwości AP_POWER_STATE_REQ wysyłane przez VHAL. W trybie wirtualizacji tryb garażowy jest wywoływany po stronie hosta. Maszyna wirtualna hosta powinna pozostać włączona, aby udostępniać maszyny wirtualne Androida do momentu wyłączenia Androida. 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. Więcej informacji znajdziesz w artykule Tryb garażowy.

Globalny system nawigacji satelitarnej (GNSS)

W trout 1.0 obsługiwana jest wirtualizacja GNSS przez 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 natywny sterownik GNSS jest niedostępny, dlatego dostępne są dane pozorowane. Możesz 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.

Implementacja oczekuje, że inicjowanie GNSS i wspomagany GNSS (AGNSS) będą obsługiwane przez środowisko systemu operacyjnego hosta.

Architektura GNSS

Rysunek 5. 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 możesz uzyskać dostęp do GPU za pomocą Mesa lub goldfish-opengl oraz sterownika virtio-gpu na maszynie wirtualnej gościa Androida i urządzenia virtio-gpu.

Na maszynie wirtualnej gościa Androida Mesa lub goldfish-opengl koduje polecenia OpenGLES odpowiednio do strumienia Gallium lub automatycznie wygenerowanego strumienia GLES. Sterownik jądra virtio-gpu jest używany jako transport. 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 tylko OpenGL ES z obsługą Vulkan, która jest planowana w przyszłej wersji.

Architektura graficzna

Rysunek 6. 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 możesz uzyskać dostęp do czujników za pomocą sterownika Virtio-SCMI na maszynie wirtualnej gościa Androida i urządzenia VirtIO-SCMI na maszynie wirtualnej hosta. Platforma referencyjna wirtualizacji AAOS udostępnia ogólny i niezależny od sprzętu interfejs HAL czujnika, którego możesz używać w przypadku SoC opartych na architekturze ARM do uzyskiwania dostępu do czujników.

Interfejs HAL czujnika komunikuje się ze sterownikiem IIO SCMI w podsystemie IIO jądra systemu 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 transportu VirtIO w specyfikacji virtio-scmi do wymiany wiadomości 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 7. Architektura czujników.

Lokalizacja interfejsu HAL czujnika

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

Konfiguracja interfejsu HAL czujnika

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

Producenci OEM mogą podać konfigurację czujnika, np. orientację i lokalizację, w pliku sensor_hal_configuration.xml i skopiować ten plik do lokalizacji /odm/etc/sensors/ lub /vendor/etc/sensors/. Konfiguracja czujnika jest podana w tym przykładzie:

<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 (VHAL) 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 przez 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 transportu 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 takiej postaci, w jakiej jest, np. virtio-blk, virtio-input, virtio-console i virtio-net.

Na platformie referencyjnej 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.