Die 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 Notfalltöne abspielt, muss die Musik im Hintergrund möglicherweise stummgeschaltet werden. Die Audiosteuerung HAL weist die Apps, die Musik abspielen, darauf hin, diese in dieser Situation stummzuschalten. Im virtualisierten System können die Sounds 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 Protocol 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 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 zu vereinbaren. 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.