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, die mit VirtIO-Geräten auf der Hostseite über VirtIO-Protokolle kommunizieren. 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, die DMA-ähnliche Ringpuffer mit Scatter-Gather-Listen sind. Für den Austausch der VirtIO-Nachrichten zwischen VMs können verschiedene Übertragungsmethoden wie MMIO oder PCI verwendet werden.

In einigen Fällen wird vsock für die VM-übergreifende Kommunikation verwendet. Die Kommunikation mit Fahrzeug-HAL (VHAL), Audio Control und Dumpstate wird über eine Verbindung zu einem Peer-Agent auf einer separaten VM über eine vsock-Schnittstelle unterstützt. gRPC über vsock wird verwendet, um auf diese nicht standardisierten Subsysteme zuzugreifen. gRPC im Android-Quellcodebaum wird so geändert, dass es mit vsock mit dem Adress format von 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 Notfallsignale 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 Sounds von anderen VMs stammen. In der Referenzimplementierung wird auf der AAOS-Gast-VM ein Audio Control-Server-Daemon ausgeführt, der gRPC über vsock verwendet, um Audiofokus-Anfragen 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, sendet sie weiterhin Heartbeats an AAOS, bis der Fokus freigegeben wird.

Audioarchitektur

Abbildung 2 : Audioarchitektur

Bluetooth

Die Bluetooth-Implementierung ist in der folgenden Abbildung dargestellt:

Bluetooth-Architektur

Abbildung 3 : Bluetooth-Architektur

Bluetooth Hands-Free Profile

Um das Bluetooth Hands-Free Profile (HFP) auf trout zu aktivieren, wurde die Spezifikation des VirtIO-Audiogeräts um die Unterstützung von Audioeinstellungen erweitert. Mit diesem Ansatz bietet ein VirtIO-Audiogerät auf der Host-/Hypervisor-Seite die folgenden drei Audioeinstellungen 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 Audioeinstellungen 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 folgenden Designabbildung:

Bluetooth-Architektur

Abbildung 4 : 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 über vsock erfasst. Die als tar verpackten 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, z. B.: 
    --config_file my_config.xml

Extended View System

Das Extended View System (EVS) zeigt Videos an, die von den Rückfahr- und Surround-View-Kameras aufgenommen wurden. In virtualisiertem AAOS kann der EVS-Stack auf den Videostream des virtualisierten V4L2-Streaminggeräts zugreifen, das den VirtIO-Videotreiber verwendet.

Garagenmodus

Das Aktivieren und Beenden des Garagenmodus wird durch AP_POWER_STATE_REQ-Attribute ausgelöst, die von der VHAL gesendet werden. Im Virtualisierungsmodus wird der Garagenmodus von der Hostseite aus 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 Herunterfahrsignal an die AAOS-Gast-VM. Nachdem der VHAL-Client das Signal empfangen hat, wechselt die AAOS-VM in den Garagenmodus und sendet Heartbeat-Signale, um die Host-VM aktiv zu halten. Weitere Informationen finden Sie unter Garagenmodus.

Global Navigation Satellite System (GNSS)

In trout 1.0 ist die Unterstützung für die GNSS-Virtualisierung über virtio-console enthalten. 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 ist der native GNSS-Treiber nicht verfügbar, daher sind Mock-Daten verfügbar. Sie können einen nativen Treiber ohne Änderungen auf der Gastseite implementieren. Ein Beispiel für einen Mock-Host-Agent ist Teil des trout-Quellcodes.

Die Implementierung setzt voraus, dass die GNSS-Initialisierung und Assisted GNSS (AGNSS) von der Host-Betriebssystemumgebung verarbeitet werden.

GNSS-Architektur

Abbildung 5 : GNSS-Architektur

Grafik

Wenn AAOS als Gast-VM zusammen mit 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 Sie über Mesa oder goldfish-opengl und einen virtio-gpu-Treiber auf der Android-Gast-VM und das virtio-gpu-Gerät auf die GPU zugreifen.

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

Sensoren

Wenn AAOS als Gast-VM zusammen mit anderen Betriebssystemen für Fahrzeuge ausgeführt wird, hat Android möglicherweise keinen direkten Zugriff auf die Sensoren. In diesem Fall können Sie über den Virtio-SCMI-Treiber auf der Android-Gast-VM und das VirtIO-SCMI-Gerät auf der Host-VM auf die Sensoren zugreifen. Die AAOS-Virtualisierungsreferenzplattform bietet eine generische und hardwareunabhängige Sensor-HAL, die Sie für ARM-basierte SoCs verwenden können, um auf die Sensoren zuzugreifen.

Die Sensor-HAL kommuniziert mit dem IIO-SCMI-Treiber im Linux-Kernel-IIO-Subsystem, das 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 in 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.

Sensorarchitektur

Abbildung 7 : Sensorarchitektur

Speicherort der Sensor-HAL

Die Referenzimplementierung der Sensor-HAL, die VirtIO SCMI verwendet, befindet sich unter device/google/trout/hal/sensors.

Konfiguration der Sensor-HAL

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. Eine Sensorkonfiguration wird im folgenden Beispiel bereitgestellt:

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

Vehicle HAL

Die Fahrzeug-HAL (VHAL)-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 über 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 Blockspeicher, Netzwerk, Konsole, Eingabe, Socket und Entropie. 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.