Architektur

Die meisten Änderungen, die zur Unterstützung von VirtIO in AAOS erforderlich sind, betreffen Änderungen auf der Ebene der HAL-Implementierung und darunter im Android Common Kernel. Das Android-Framework kommuniziert mit einer generischen, hardwareunabhängigen HAL über die VirtIO-Treiber im AAOS-Gast-VM-Kernel, der über VirtIO-Protokolle mit VirtIO-Geräten auf der Hostseite kommuniziert. VirtIO-Geräte auf der Hostseite können über SoC-spezifische Gerätetreiber auf die physische Hardware zugreifen.

Die Kommunikation zwischen dem VirtIO-Treiber und dem VirtIO-Gerät erfolgt über virtqueue, das sind DMA-ähnliche Ringpuffer mit Scatter-Gather-Listen. Für den Austausch der VirtIO-Nachrichten zwischen VMs können verschiedene Übertragungsmethoden wie MMIO oder PCI verwendet werden.

In einigen Fällen wurde vsock für die VM-übergreifende Kommunikation verwendet. Die Kommunikation mit Fahrzeug-HAL, Audio Control und Dumpstate wird über eine Verbindung zu einem Peer-Agent auf einer separaten VM über eine vsock-Schnittstelle unterstützt. GRPC-vsock wird verwendet, um auf diese nicht standardisierten Subsysteme zuzugreifen. GRPC im Android-Quellcodebaum wurde so geändert, dass es mit vsock mit dem Adress format vsock:CID:PORT_NUMBER funktioniert.

Virtualisierungsarchitektur
Abbildung 1. Virtualisierungsarchitektur

Audio

In virtualisiertem AAOS kann die Android-Gast-VM virtio-snd verwenden, um auf Audio zuzugreifen. virtio-snd stellt der Android-VM die virtualisierten PCM-Geräte zur Verfügung, sodass die Audio-HAL-Implementierung mit der TinyALSA-Bibliothek mit den virtualisierten Audiogeräten interagieren kann.

Die Standard-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 eine eigene Audio-HAL implementieren, indem sie die audiobezogenen Variablen in /device/google/trout/aosp_trout_common.mk. überschreiben.

Die Audio Control HAL verwaltet den Audiofokus in AAOS. Wenn das System beispielsweise Notfalltöne wiedergibt, muss die im Hintergrund laufende Musik möglicherweise stummgeschaltet werden. Die Audio Control HAL benachrichtigt die Apps, die Musik abspielen, in dieser Situation stummzuschalten. Im virtualisierten System können die Töne von anderen VMs stammen. In der Referenzimplementierung wird auf der AAOS-Gast-VM ein Audio Control-Server-Daemon ausgeführt, der GRPC-vsock verwendet, um Audiofokusanfragen von anderen VMs zu empfangen. Die Host-VM kann device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller verwenden, um Audio Control-Anfragen an AAOS zu senden. Solange libandroid_audio_controller den Audiofokus hat, werden weiterhin Heartbeats an AAOS gesendet, bis der Fokus freigegeben wird.

Audioarchitektur
Abbildung 5. Audioarchitektur

Bluetooth

Die Bluetooth-Implementierung basiert auf dem unten dargestellten Design.

Bluetooth-Architektur
Abbildung 5 Bluetooth-Architektur

Bluetooth Hands-Free Profile

Um das Bluetooth Hands-Free Profile (HFP) auf trout zu aktivieren, wurde die Spezifikation des VirtIO-Audiogeräts erweitert, um Audiosteuerungen zu unterstützen. Mit diesem Ansatz bietet ein VirtIO-Audiogerät auf der Host-/Hypervisor-Seite die folgenden drei Audiosteuerungen im Zusammenhang mit dem HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Wenn AAOS als Gast-VM ausgeführt wird, verwendet AAOS TinyAlsa, um diese Audiosteuerungen festzulegen. Um den HFP-Anwendungsfall zu ermöglichen, führt der Host/Hypervisor das anbieterspezifische Routing und die Kalibrierung entsprechend durch.

Die Bluetooth-Implementierung basiert auf der unten dargestellten Designillustration.

Bluetooth-Architektur
Abbildung 5 Bluetooth-Architektur

Dumpstate

Beim Generieren des Fehlerberichts für virtualisiertes AAOS ist es sinnvoll, Informationen zur Host-VM einzufügen, damit die Entwickler einen umfassenderen Überblick über das System haben. Zu diesem Zweck implementiert die trout-Referenzimplementierung die IDumpstateDevice-HAL, die die Informationen zur Host-VM über GRPC-vsock erfasst. Die im `tar`-Paket enthaltenen Informationen zur Host-VM werden im Fehlerbericht als dumpstate_board.bin bezeichnet, während die Dumping-Logs unter dumpstate_board.txt zu finden sind.

So konfigurieren Sie die auszuführenden Befehle:

  1. 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>
  2. Übergeben Sie beim Starten den Pfad der neuen XML-Datei an den Dumpstate-Server. Beispiel: 
    --config_file my_config.xml

Extended View System (EVS)

Das Extended View System (EVS) wird verwendet, um Video anzuzeigen, das von den Rückfahr- und Surround-View-Kameras aufgenommen wurde. In virtualisiertem AAOS kann der EVS-Stack auf den Videostream des virtualisierten V4L2-Streaminggeräts zugreifen, das den VirtIO-Videotreiber verwendet.

Garagenmodus

Weitere Informationen finden Sie unter Garagenmodus.

Das Aktivieren und Beenden des Garagenmodus wird durch AP_POWER_STATE_REQ-Properties ausgelöst, die von der Fahrzeug-HAL gesendet werden. Im Virtualisierungsmodus wird der Garagenmodus von der Hostseite aus ausgelöst. Die Host-VM muss 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 Herunterfahrsignal an die AAOS-Gast-VM. Nachdem der VHAL-Client das Signal empfangen hat, wechselt die AAOS-VM in den Garagenmodus und beginnt, Heartbeat-Signale zu senden, um die Host-VM aktiv zu halten.

Global Navigation Satellite System (GNSS)

In trout 1.0 wurde Unterstützung für die GNSS-Virtualisierung über virtio-console hinzugefügt. Die Implementierung unterstützt den Austausch von Rohmessungen und Standortkorrekturen vom Host zum Gast.

Das Datenaustauschformat ist die CSV-Datei, die von der GnssLogger-App verwendet wird. In der Referenzimplementierung sind Mock-Daten verfügbar, da der native GNSS-Treiber nicht verfügbar ist. Ein nativer Treiber kann jedoch ohne Änderungen auf der Gastseite implementiert werden. Ein Beispiel für einen Mock-Host-Agent ist Teil des trout-Quellcodes.

Die aktuelle Implementierung geht davon aus, dass die GNSS-Initialisierung und Assisted GNSS (AGNSS) von der Host-Betriebssystemumgebung verarbeitet werden.

GNSS-Architektur
Abbildung 2. GNSS-Architektur

Grafik

Wenn AAOS als Gast-VM neben anderen Betriebssystemen für Fahrzeuge 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 dem virtio-gpu Gerät verwendet werden, um auf die GPU zuzugreifen.

Auf der Android-Gast-VM codiert Mesa oder goldfish-opengl OpenGLES-Befehle entweder in einen Gallium-Stream oder einen automatisch generierten GLES-Stream. Der virtio-gpu-Kernel-Treiber wird als Transport verwendet. Auf der Hostseite spielen virglrenderer (für Mesa) und vulkan-cereal (für goldfish-opengl) den decodierten Befehlsstream über dem vorhandenen GPU-Treiber ab. Die AAOS-Referenzplattform trout unterstützt OpenGL ES nur mit Vulkan-Unterstützung, die in einer zukünftigen Version erwartet wird.

Grafikarchitektur
Abbildung 3. Grafikarchitektur

Sensoren

Wenn AAOS als Gast-VM neben anderen Betriebssystemen für Fahrzeuge 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 hardwareunabhängige Sensor-HAL, die für ARM-basierte SoCs verwendet werden kann, um auf die Sensoren zuzugreifen.

Die Sensor-HAL kommuniziert mit dem IIO-SCMI-Treiber im Linux-Kernel-IIO-Subsystem, der das SCMI-Sensorverwaltungsprotokoll verwendet, das von der ARM System Control and Management Interface (SCMI) -Spezifikation bereitgestellt wird, um Sensoren zu erkennen und zu konfigurieren, Sensordaten zu lesen und über Änderungen von Sensor werten benachrichtigt zu werden.

Der IIO-SCMI-Treiber verwendet den VirtIO-SCMI-Treiber, der das VirtIO-Transportprotokoll verwendet, wie in der virtio-scmi-Spezifikation angegeben, 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.

Sensorarchitektur
Abbildung 4. Sensorarchitektur

Sensor-HAL-Speicherort

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, um dem Android-Koordinatensystem für Autosensoren zu entsprechen. Das Schema für die Sensorkonfiguration finden Sie unter device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

OEMs können die Sensorkonfiguration, z. B. Ausrichtung und Position, in sensor_hal_configuration.xml angeben und die Datei entweder unter /odm/etc/sensors/ oder /vendor/etc/sensors/ kopieren. Ein Beispiel für eine Sensorkonfiguration finden Sie unten:

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

  • Client Bietet APIs, die von Android in virtualisiertem AAOS verwendet werden
  • Server Kommuniziert direkt mit der Hardware, z. B. Fahrzeugbussen (oder einem Emulator).

In 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 unverändert, z. B. virtio-blk, virtio-input, virtio-console und virtio-net.

In der virtualisierten AAOS-Referenzplattform wird WLAN mit mac80211_hwsim unterstützt, um ein VirtWifi-Drahtlosnetzwerk zu ermöglichen, das dann den virtio-net-Tunnel verwendet, um den Netzwerkverkehr an die Host-VM zu senden, die direkten Zugriff auf das tatsächliche WLAN hat.