Większość zmian wymaganych do obsługi VirtIO w AAOS dotyczy modyfikacji na poziomie implementacji HAL i niżej w jądrze Android Common Kernel. Platforma Android komunikuje się z uniwersalnym interfejsem HAL niezależnym od sprzętu za pomocą sterowników VirtIO w jądrze VM gościa AAOS, który komunikuje 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ń przeznaczonych dla konkretnego układu SoC.
Komunikacja między sterownikiem VirtIO a urządzeniem VirtIO odbywa się za pomocą virtqueue, które są buforami pierścieniowymi podobnymi do DMA list rozproszonych zbiorów.
Do wymiany komunikatów VirtIO między maszynami wirtualnymi można używać różnych transportów, takich jak MMIO lub PCI.
W niektórych przypadkach vsock był wykorzystywany do komunikacji między maszynami wirtualnymi.
Komunikacja z HAL pojazdu, sterowaniem dźwiękiem i stanem Dumpstate jest obsługiwana za pomocą połączenia z usługą peer na osobnej maszynie wirtualnej przez interfejs vsock.
GRPC-vsock służy do uzyskiwania dostępu do tych niestandardowych podsystemów.
GRPC w drzewie kodu źródłowego Androida zostało zmodyfikowane, aby współpracowało z vsock z formatem adresu vsock:CID:PORT_NUMBER.
Audio
W wirtualnej maszynie AAOS maszyna wirtualna gościa Androida może używać virtio-snd do uzyskiwania dostępu do dźwięku.
virtio-snd udostępnia wirtualne urządzenia PCM maszynie wirtualnej Androida, aby implementacja HAL dźwięku mogła wchodzić w interakcje z wirtualnymi urządzeniami dźwiękowymi za pomocą biblioteki TinyALSA.
Domyślna implementacja HAL dźwięku znajduje się w AOSP pod adresem /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ż stosować własne interfejsy HAL dźwięku, zastępując zmienne związane z dźwiękiem w /device/google/trout/aosp_trout_common.mk.
Moduł HAL sterowania dźwiękiem zarządza priorytetem dźwięku w AAOS. Na przykład gdy system odtwarza dźwięki alarmowe, może być konieczne wyciszenie muzyki odtwarzanej w tle. W takich sytuacjach interfejs HAL sterowania dźwiękiem powiadamia aplikacje odtwarzające muzykę, aby wyciszyły dźwięk. W systemie wirtualnym dźwięki mogą pochodzić z innych maszyn wirtualnych. W implementacji referencyjnej w goszczącej maszynie wirtualnej AAOS działa demon serwera kontroli dźwięku, który używa interfejsu GRPC-vsock do odbierania żądań dotyczących skupienia na dźwięku z innych maszyn wirtualnych.
Maszyna wirtualna hosta może używać device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controllerdo wysyłania żądań sterowania dźwiękiem do AAOS. Podczas gdy libandroid_audio_controller ma fokus audio, nadal wysyła sygnały dźwiękowe do AAOS, dopóki nie zostanie on zwolniony.
Bluetooth
Implementacja Bluetooth opiera się na projekcie przedstawionym poniżej.
Profil Bluetooth Hands-free
Aby włączyć profil Bluetooth HFP (Hands-Free Profile) na urządzeniu trout, rozszerzono specyfikację urządzenia dźwiękowego VirtIO, aby obsługiwało ono elementy sterujące dźwiękiem. W ramach tego podejścia urządzenie dźwiękowe VirtIO po stronie hosta/hipervisora udostępnia te 3 elementy sterujące dźwiękiem związane z HFP:
hfp_enablehfp_set_sampling_ratehfp_volume
Gdy AAOS działa jako maszyna wirtualna gościa, używa TinyAlsa do ustawiania tych elementów sterowania dźwiękiem. Aby umożliwić scenariusz HFP, host lub hypervisor wykonuje odpowiednie przekierowanie i kalibrację dla danego dostawcy.
Implementacja Bluetooth opiera się na ilustracji poniżej.
Dumpstate
Podczas generowania raportu o błędach dla wirtualizowanego AAOS warto uwzględnić informacje o hostowanej maszynie wirtualnej, aby programiści mieli pełny obraz systemu. W tym celu implementacja referencyjna trout implementuje interfejs IDumpstateDevice HAL, który zbiera informacje o hostowanej maszynie wirtualnej za pomocą GRPC-vsock. Informacje o maszynie wirtualnej hosta zapakowane w plik tar mają nazwę dumpstate_board.bin w raporcie o błędzie, a logy z dumpingu znajdują się w pliku dumpstate_board.txt.
Aby skonfigurować polecenia do wykonania:
- 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> - Podczas uruchamiania prześlij ścieżkę do nowego pliku XML na serwer dumpstate. Przykład:
--config_file my_config.xml
System rozszerzonego widoku (EVS)
System rozszerzonego widoku (EVS) służy do wyświetlania filmów zarejestrowanych przez kamery tylne i kamery widoku otoczenia. W wirtualizacji AAOS stos EVS może uzyskać dostęp do strumienia wideo z wirtualizacji urządzenia do strumieniowego przesyłania danych V4L2, które korzysta z sterownika VirtIO-video.
Tryb garażu
Więcej informacji znajdziesz w artykule Tryb garażu.
Wchodzenie w tryb garażu i wychodzenie z niego jest wywoływane przez właściwości AP_POWER_STATE_REQ wysyłane przez interfejs HAL pojazdu. W trybie wirtualizacji tryb Garaż jest uruchamiany po stronie hosta.
Maszyna wirtualna hosta powinna pozostać włączona, aby udostępniać urządzenia wirtualne dla maszyny wirtualnej Android, 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 od klienta VHAL maszyna wirtualna AAOS przechodzi w tryb garażu i zaczyna wysyłać sygnały tętna, aby utrzymać aktywność maszyny wirtualnej hosta.
Globalny system nawigacji satelitarnej (GNSS)
W wersji trout 1.0 dodano obsługę wirtualizacji GNSS w usłudze virtio-console. Implementacja umożliwia wymianę surowych pomiarów i poprawek lokalizacji między gospodarzem a gościem.
Format wymiany danych to CSV używany przez aplikację GnssLogger. W wdrożeniu referencyjnym, ponieważ sterownik GNSS nie jest dostępny, udostępniane są dane testowe, ale można zaimplementować sterownik natywny bez wprowadzania żadnych zmian po stronie gościa. Przykładowy agent hosta mock jest dostępny w ramach kodu źródłowego trout.
Obecna implementacja zakłada, że inicjowanie GNSS i wspomagany GNSS (AGNSS) są obsługiwane przez środowisko systemu operacyjnego hosta.
Grafika
Gdy AAOS działa jako maszyna wirtualna gościa obok innych systemów operacyjnych dla pojazdów, Android może nie mieć bezpośredniego dostępu do procesora graficznego ani kontrolera wyświetlacza. W takim przypadku do uzyskania dostępu do GPU można użyć Mesy lub goldfish-opengl oraz sterownika virtio-gpu w 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. Jako transport używany jest virtio-gpusterownik jądra. Po stronie hosta virglrenderer (w przypadku Mesa) i vulkan-cereal (w przypadku goldfish-opengl) odtwarzają odkodowany strumień poleceń na podstawie istniejącego sterownika GPU. Platforma referencyjna AAOS trout obsługuje tylko OpenGL ES z obsługą Vulkan, która ma zostać udostępniona w przyszłej wersji.
Czujniki
Gdy AAOS działa jako maszyna wirtualna gościa obok innych systemów operacyjnych samochodowych, Android może nie mieć bezpośredniego dostępu do czujników. W tym przypadku do uzyskiwania dostępu do czujników służy sterownik Virtio-SCMI w maszynie wirtualnej gościa Androida i urządzenie VirtIO-SCMI w maszynie wirtualnej hosta. Platforma referencyjna AAOS do wirtualizacji zapewnia ogólny interfejs HAL czujnika niezależny od sprzętu, który może być używany przez układy SoC oparte na ARM do uzyskiwania dostępu do czujników.
Sensor HAL komunikuje się z sterownikiem IIO SCMI w ramach podsystemu IIO jądra Linuksa, który korzysta z protokołu SCMI Sensor Management Protocol udostępnianego przez specyfikację ARM System Control and Management Interface (SCMI), aby wykrywać i konfigurować czujniki, odczytywać dane z czujników oraz otrzymywać powiadomienia o zmianach wartości czujników.
Sterownik IIO SCMI korzysta ze sterownika VirtIO SCMI, który używa protokołu transportowego VirtIO zgodnie ze specyfikacją virtio-scmi, aby wymieniać się wiadomościami 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.
Lokalizacja modułu HAL czujnika
Implementacja referencyjna interfejsu HAL czujnika, która korzysta z interfejsu VirtIO SCMI, znajduje się w pliku device/google/trout/hal/sensors.
Konfiguracja interfejsu HAL czujnika
HAL czujnika może wymagać zmodyfikowania danych czujnika otrzymanych z hosta maszyny wirtualnej, aby były zgodne z systemem współrzędnych czujnika samochodu 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 położenie, w pliku sensor_hal_configuration.xml, a potem skopiować go do pliku /odm/etc/sensors/ lub /vendor/etc/sensors/.
Poniżej znajduje się 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>
Interfejs HAL pojazdu
Implementacja interfejsu HAL pojazdu składa się z 2 komponentów:
- Klient. Udostępnia interfejsy API używane przez Androida w wirtualizacji AAOS
- Serwer. Komunikacja odbywa się bezpośrednio z urządzeniem, np. magistralą pojazdu (lub z emulatorem).
W przypadku wirtualizacji serwer VHAL działa na maszynie wirtualnej hosta. Klient i serwer VHAL komunikują się za pomocą interfejsu GRPC-vsock (więcej informacji znajdziesz w artykule 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 artykule 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 postaci takiej, jaka jest, np. virtio-blk, virtio-input, virtio-console i virtio-net.
Na wirtualnej platformie referencyjnej 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 sieciowego do maszyny wirtualnej hosta, która ma bezpośredni dostęp do rzeczywistej sieci Wi-Fi.