Architektur

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 mit einem 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 , bei denen es sich um DMA-ähnliche Ringpuffer von Scatter-Gather-Listen handelt. Für den Austausch der VirtIO-Nachrichten zwischen VMs können mehrere Transporte wie MMIO oder PCI verwendet werden.

In einigen Fällen wurde vsock für die Kommunikation zwischen VMs genutzt. Fahrzeug-HAL-, Audiosteuerungs- und Dumpstate-Kommunikation werden über eine Verbindung zu einem Peer-Agenten auf einer separaten VM über eine vsock Schnittstelle unterstützt. 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 funktionieren.

Virtualisierungsarchitektur
Abbildung 1. Virtualisierungsarchitektur

Audio

Im virtualisierten 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 den virtualisierten Soundgeräten über die TinyALSA-Bibliothek 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 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 Notruftöne abspielt, muss die im Hintergrund abgespielte Musik möglicherweise stummgeschaltet werden. In diesem Fall fordert die Audiosteuerungs-HAL die Apps, die Musik abspielen, auf, diese stummzuschalten. 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 verwenden, um Audiosteuerungsanfragen an AAOS zu senden. Während libandroid_audio_controller den Audiofokus behält, sendet er weiterhin Heartbeats an AAOS, 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-Freisprechprofil

Um das Bluetooth Hands-Free Profile (HFP) auf trout zu aktivieren, wurde die Spezifikation des VirtIO-Soundgeräts um die Unterstützung von Audiosteuerungen erweitert. Bei diesem Ansatz stellt ein VirtIO-Soundgerät auf der Host-/Hypervisor-Seite diese drei Audiosteuerungen im Zusammenhang mit dem HFP bereit:

  • 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 herstellerspezifische Routing und die entsprechende Kalibrierung durch.

Die Bluetooth-Implementierung basiert auf der folgenden Designillustration.

Bluetooth-Architektur
Abbildung 5. Bluetooth-Architektur

Dumpstate

Bei der Erstellung des Fehlerberichts für virtualisiertes AAOS ist es sinnvoll, Host-VM-Informationen einzubeziehen, damit die Entwickler einen umfassenderen Überblick über das System erhalten. Um dies zu erreichen, implementiert die trout Referenzimplementierung IDumpstateDevice HAL, das die Host-VM-Informationen über GRPC-vsock sammelt. Die in „tar“ verpackten Host-VM-Informationen werden im Fehlerbericht als „ dumpstate_board.bin “ bezeichnet, während sich die Dump-Protokolle unter dumpstate_board.txt befinden.

So konfigurieren Sie die auszuführenden Befehle:

  1. Kopieren Sie die Konfigurationsdetails aus der folgenden Datei in eine XML-Datei, zum Beispiel 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 Start den Pfad der neuen XML-Datei an den Dumpstate-Server. Beispiel:
    --config_file my_config.xml
    

Erweitertes Ansichtssystem (EVS)

Das Extended View System (EVS) dient zur Anzeige von Videos, die von den Rückfahr- und Rundumsichtkameras aufgenommen wurden. Im virtualisierten 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 Garagenmodus .

Das Betreten und Verlassen des Garagenmodus wird durch AP_POWER_STATE_REQ Eigenschaften ausgelöst, die vom Fahrzeug-HAL 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 Shutdown-Signal an die AAOS-Gast-VM. Beim Empfang des Signal-VHAL-Clients wechselt die AAOS-VM in den Garagenmodus und beginnt, Heartbeat-Signale zu senden, um die Host-VM aktiv zu halten.

Globales Navigationssatellitensystem (GNSS)

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

Das Datenaustauschformat ist das von der GnssLogger-App verwendete CSV. Da in der Referenzimplementierung der native GNSS-Treiber nicht verfügbar ist, werden Scheindaten zur Verfügung gestellt, aber ein nativer Treiber kann ohne Änderungen auf der Gastseite implementiert werden. Als Teil des trout Quellcodes wird ein Beispiel-Mock-Host-Agent bereitgestellt.

Die aktuelle Implementierung geht davon aus, dass die GNSS-Initialisierung und das unterstützte GNSS (AGNSS) von der Host-Betriebssystemumgebung übernommen werden.

GNSS-Architektur
Abbildung 2. GNSS-Architektur

Grafik

Wenn AAOS als Gast-VM neben anderen Automobilbetriebssystemen 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 kodiert Mesa oder goldfish-opengl OpenGLES-Befehle entweder in einen Gallium-Stream bzw. einen automatisch generierten GLES-Stream. Als Transportmittel wird der virtio-gpu Kerneltreiber verwendet. Auf der Hostseite geben virglrenderer (für Mesa) und vulkan-cereal (für goldfish-opengl ) den dekodierten Befehlsstrom über den vorhandenen GPU-Treiber wieder. Die AAOS-Referenzplattform trout unterstützt OpenGL ES nur mit Vulkan-Unterstützung, was in einer zukünftigen Version erwartet wird.

Grafikarchitektur
Abbildung 3. Grafikarchitektur

Sensoren

Wenn AAOS als Gast-VM neben anderen Automobilbetriebssystemen 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 für den Zugriff auf die Sensoren verwendet. Die AAOS-Virtualisierungsreferenzplattform bietet einen generischen und HW-agnostischen Sensor-HAL, der für ARM-basierte SoCs für den Zugriff auf die Sensoren verwendet werden kann.

Sensor HAL kommuniziert mit dem IIO-SCMI-Treiber im Linux-Kernel-IIO-Subsystem, das das SCMI-Sensor-Management-Protokoll verwendet, das von der ARM-Spezifikation für 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änderungen.

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.

Sensorarchitektur
Abbildung 4. Sensorarchitektur

Sensor-HAL-Standort

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

Sensor-HAL-Konfiguration

Sensor-HAL muss möglicherweise die von der Host-VM empfangenen Sensordaten ändern, um sie mit dem Koordinatensystem des Android-Autosensors in Einklang zu bringen. 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 bereitstellen und die Datei entweder nach /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 Vehicle HAL-Implementierung besteht aus zwei Komponenten:

  • Klient. Stellt APIs bereit, die von Android in virtualisierten AAOS verwendet werden
  • Server. Kommuniziert direkt mit der Hardware, z. B. Fahrzeugbussen (oder einem Emulator).

Bei der Virtualisierung läuft der VHAL-Server auf der Host-VM. Der VHAL-Client und -Server kommunizieren über GRPC-vsock (weitere Informationen finden Sie 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 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 tatsächliche Wi-Fi-Netzwerk hat.