Die meisten Änderungen, die zur Unterstützung von VirtIO in AAOS erforderlich sind, betreffen Änderungen auf der HAL-Implementierungsebene und darunter im Android Common Kernel. Das Android-Framework kommuniziert mithilfe der VirtIO-Treiber im AAOS-Gast-VM-Kernel mit einer generischen hardwareunabhängigen HAL, die über VirtIO-Protokolle mit VirtIO-Geräten auf der Hostseite kommuniziert. VirtIO-Geräte auf der Hostseite können mithilfe von SoC-spezifischen Gerätetreibern auf die physische HW zugreifen.
Die Kommunikation zwischen dem VirtIO-Treiber und dem VirtIO-Gerät findet mit virtqueue statt, bei denen es sich um DMA-ähnliche Ringpuffer von Scatter-Gather-Listen handelt. Mehrere Transporte wie MMIO oder PCI können verwendet werden, um die VirtIO-Nachrichten zwischen VMs auszutauschen.
In einigen Fällen wurde vsock für die Kommunikation zwischen VMs genutzt. Die Fahrzeug-HAL-, Audiosteuerungs- und Dumpstate-Kommunikation wird unterstützt, indem eine Verbindung zu einem Peer-Agent auf einer separaten VM über eine vsock Schnittstelle verwendet wird. GRPC-vsock wird verwendet, um auf diese nicht standardisierten Subsysteme zuzugreifen. GRPC im Android-Quellbaum wurde geändert, um mit vsock mit dem Adressformat vsock:CID:PORT_NUMBER zu arbeiten.
Audio
In virtualisiertem AAOS kann die Android-Gast-VM virtio-snd verwenden, um auf Audio zuzugreifen. virtio-snd stellt die virtualisierten PCM-Geräte der Android-VM bereit, sodass die Audio-HAL-Implementierung mit den virtualisierten Soundgeräten mit der TinyALSA-Bibliothek interagieren kann.
Die standardmäßige Audio-HAL-Implementierung befindet sich in AOSP unter /device/google/trout/hal/audio/6.0 . OEMs können ro.vendor.trout.audiohal.{in,out}_period_{ms,count} für ihre Plattform ändern. OEMs können auch ihre eigene Audio-HAL implementieren, indem sie die audiobezogenen Variablen in /device/google/trout/aosp_trout_common.mk.
Die Audiosteuerung HAL verwaltet den Audiofokus in AAOS. Wenn das System beispielsweise Notfalltöne abspielt, muss die Hintergrundmusik möglicherweise stumm geschaltet werden. Die Audiosteuerung HAL benachrichtigt die Apps, die Musik spielen, in dieser Situation stumm zu schalten. Im virtualisierten System können die Töne von anderen VMs stammen. In der Referenzimplementierung läuft auf der AAOS-Gast-VM ein Audiosteuerungsserver-Daemon, der GRPC-vsock verwendet, um Audiofokusanforderungen von anderen VMs zu empfangen. Die Host-VM kann device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller , um Audiosteuerungsanfragen an AAOS zu senden. Während libandroid_audio_controller den Audiofokus hält, sendet es weiterhin Heartbeats an AAOS, bis der Fokus freigegeben wird.
Bluetooth
Die Bluetooth-Implementierung basiert auf dem unten dargestellten Design.
Bluetooth-Freisprechprofil
Um das Bluetooth Hands-Free Profile (HFP) auf trout zu aktivieren, wurde die VirtIO-Soundgerätespezifikation erweitert, um Audiosteuerungen zu unterstützen. Bei diesem Ansatz stellt ein VirtIO-Soundgerät auf der Host-/Hypervisor-Seite diese drei Audiosteuerungen in Bezug auf das HFP bereit:
-
hfp_enable -
hfp_set_sampling_rate -
hfp_volume
Wenn AAOS als Gast-VM ausgeführt wird, verwendet AAOS TinyAlsa, um diese Audiosteuerelemente festzulegen. Um den HFP-Anwendungsfall zu aktivieren, führt der Host/Hypervisor das herstellerspezifische Routing und die entsprechende Kalibrierung durch.
Die Bluetooth-Implementierung basiert auf der folgenden Designabbildung.
Dumpstate
Beim Generieren des Fehlerberichts für virtualisiertes AAOS ist es sinnvoll, Host-VM-Informationen einzubeziehen, damit die Entwickler einen umfassenderen Überblick über das System haben. Um dies zu erreichen, implementiert die trout -Referenzimplementierung IDumpstateDevice HAL, das die Host-VM-Informationen über GRPC-vsock . Die `tar`-gepackten Host-VM-Informationen heißen im Fehlerbericht dumpstate_board.bin , während Dumping-Protokolle unter dumpstate_board.txt sind.
So konfigurieren Sie die auszuführenden Befehle:
- Kopieren Sie die Konfigurationsdetails aus der folgenden Datei in eine XML-Datei, z. B.
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> - Übergeben Sie den Pfad der neuen XML-Datei beim Start an den Dumpstate-Server. Zum Beispiel:
--config_file my_config.xml
Extended-View-System (EVS)
Das Extended View System (EVS) wird verwendet, um Videos anzuzeigen, die von den Rückfahr- und Surround-View-Kameras aufgenommen wurden. In virtualisiertem AAOS kann der EVS-Stack auf den Videostream vom virtualisierten V4L2-Streaminggerät zugreifen, das den VirtIO-Videotreiber verwendet.
Garagenmodus
Weitere Informationen finden Sie unter Was ist der Garagenmodus? .
Das Betreten und Verlassen des Garagenmodus wird durch AP_POWER_STATE_REQ Eigenschaften ausgelöst, die von der Fahrzeug-HAL gesendet werden. Im Virtualisierungsmodus wird der Garagenmodus von der Hostseite ausgelöst. Die Host-VM sollte eingeschaltet bleiben, um virtuelle Geräte für die Android-VM bereitzustellen, bis Android ausgeschaltet wird. Der VHAL-Server auf der Host-VM sendet das Signal zum Herunterfahren an die AAOS-Gast-VM. Beim Empfang des Signals VHAL-Client wechselt die AAOS-VM in den Garagenmodus und beginnt mit dem Senden von Heartbeat-Signalen, um die Host-VM aktiv zu halten.
Globales Satellitennavigationssystem (GNSS)
In trout 1.0 wurde die Unterstützung für die GNSS-Virtualisierung über die virtio-console hinzugefügt. Die Implementierung unterstützt den Austausch von Rohmessungen und Ortsfestlegungen vom Host zum Gast.
Das Datenaustauschformat ist das von der GnssLogger-App verwendete CSV. In der Referenzimplementierung werden Scheindaten bereitgestellt, da der native GNSS-Treiber nicht verfügbar ist, aber ein nativer Treiber kann ohne gastseitige Änderungen implementiert werden. Ein Beispiel-Mock-Host-Agent wird als Teil des trout -Quellcodes bereitgestellt.
Die aktuelle Implementierung erwartet, dass die GNSS-Initialisierung und Assisted GNSS (AGNSS) von der Host-Betriebssystemumgebung gehandhabt werden.
Grafik
Wenn AAOS neben anderen Automobilbetriebssystemen als Gast-VM ausgeführt wird, hat Android möglicherweise keinen direkten Zugriff auf die GPU oder den Display-Controller. In diesem Fall können Mesa oder goldfish-opengl und ein virtio-gpu Treiber auf der Android-Gast-VM und virtio-gpu Gerät für den Zugriff auf die GPU verwendet werden.
Auf der Android-Gast-VM codiert Mesa oder goldfish-opengl OpenGLES-Befehle entweder in einen Gallium-Stream bzw. einen automatisch generierten GLES-Stream. Als Transport wird der virtio-gpu verwendet. Auf der virglrenderer (für Mesa) und vulkan vulkan-cereal (für goldfish-opengl ) den decodierten Befehlsstrom zusätzlich zum vorhandenen GPU-Treiber wieder. Die AAOS-Referenzplattform trout unterstützt OpenGL ES nur mit Vulkan-Unterstützung, die in einer zukünftigen Version erwartet wird.
Sensoren
Wenn AAOS neben anderen Automobilbetriebssystemen als Gast-VM ausgeführt wird, hat Android möglicherweise keinen direkten Zugriff auf die Sensoren. In diesem Fall werden der Virtio-SCMI-Treiber auf der Android-Gast-VM und das VirtIO-SCMI-Gerät auf der Host-VM verwendet, um auf die Sensoren zuzugreifen. Die AAOS-Virtualisierungsreferenzplattform bietet eine generische und HW-agnostische Sensor-HAL, die für ARM-basierte SoCs verwendet werden kann, um auf die Sensoren zuzugreifen.
Sensor-HAL kommuniziert mit dem IIO-SCMI-Treiber im Linux-Kernel-IIO-Subsystem, das das SCMI-Sensorverwaltungsprotokoll verwendet, das von der Spezifikation ARM System Control and Management Interface (SCMI) bereitgestellt wird, um Sensoren zu erkennen und zu konfigurieren, Sensordaten zu lesen und über Sensoren benachrichtigt zu werden Wert ändert.
Der IIO-SCMI-Treiber verwendet den VirtIO-SCMI-Treiber, der das VirtIO-Transportprotokoll gemäß der virtio-scmi Spezifikation verwendet, um SCMI-Nachrichten mit dem VirtIO-SCMI-Gerät auf der Host-VM auszutauschen. Das VirtIO-SCMI-Gerät hat über SoC-spezifische Sensortreiber direkten Zugriff auf die Sensoren.
Sensor-HAL-Position
Die Referenzimplementierung der Sensor-HAL, die VirtIO SCMI verwendet, befindet sich unter device/google/trout/hal/sensors .
Sensor-HAL-Konfiguration
Die Sensor-HAL muss möglicherweise die von der Host-VM empfangenen Sensordaten ändern, damit sie mit dem Android-Autosensorkoordinatensystem übereinstimmen. Das Schema für die Sensorkonfiguration finden Sie in device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd .
OEMs können Sensorkonfigurationen wie Ausrichtung und Position in sensor_hal_configuration.xml und die Datei entweder /odm/etc/sensors/ oder /vendor/etc/sensors/ kopieren. Nachfolgend finden Sie eine beispielhafte Sensorkonfiguration:
<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>
Fahrzeug HAL
Die Fahrzeug-HAL-Implementierung besteht aus zwei Komponenten:
- Klient. Stellt APIs bereit, die von Android in virtualisiertem AAOS verwendet werden
- Server. Kommuniziert direkt mit der Hardware, wie z. B. Fahrzeugbussen (oder einem Emulator).
Bei der Virtualisierung wird der VHAL-Server auf der Host-VM ausgeführt. Der VHAL-Client und -Server kommunizieren über GRPC-vsock (weitere Informationen finden Sie unter device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). OEMs können ein anderes Transportprotokoll als GRPC verwenden, indem sie die Kommunikations-APIs überschreiben. Beispiele finden Sie unter device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .
Andere Subsysteme
VirtIO bietet bereits eine klar definierte Schnittstelle für Komponenten wie Block Storage, Network, Console, Input, Socket und Entropy. Für diese Subsysteme verwendet AAOS den Treiber wie er ist, wie virtio-blk , virtio-input , virtio-console und virtio-net .
In der virtualisierten AAOS-Referenzplattform wird Wi-Fi mit mac80211_hwsim unterstützt, um ein drahtloses VirtWifi -Netzwerk zu ermöglichen, das dann den virtio-net Tunnel verwendet, um den Netzwerkverkehr an die Host-VM zu senden, die direkten Zugriff auf das eigentliche Wi-Fi-Netzwerk hat.