Architektur

Die meisten Änderungen, die zur Unterstützung von VirtIO in AAOS erforderlich sind, betreffen Änderungen am HAL. Implementierungsebene und niedriger im Android Common Kernel an. Das Android-Framework kommuniziert mit einem generischen hardware-unabhängigen HAL mithilfe der VirtIO-Treiber im AAOS-Gastmodus VM-Kernel, der über VirtIO-Protokolle mit VirtIO-Geräten auf 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 Streuerfassungslisten handelt. Mehrere Transporte, z. B. MMIO oder PCI können für den Austausch von VirtIO-Nachrichten zwischen VMs verwendet werden.

In einigen Fällen wurde vsock für die Kommunikation zwischen VMs verwendet. Die Kommunikation zwischen Fahrzeug-HAL, Audiosteuerung und Dumpstate wird über eine Verbindung unterstützt über eine vsock-Schnittstelle mit einem Peer-Agent auf einer separaten VM verbinden. GRPC-vsock wird für den Zugriff auf diese nicht standardisierten Subsysteme verwendet. gRPC in der Android-Quellstruktur wurde geändert, damit vsock mit der Adresse Format von vsock:CID:PORT_NUMBER.

<ph type="x-smartling-placeholder">
</ph> Virtualisierungsarchitektur
Abbildung 1: Virtualisierungsarchitektur

Audio

Im virtualisierten AAOS kann die Android-Gast-VM virtio-snd für den Audiozugriff verwenden. virtio-snd stellt der Android-VM die virtualisierten PCM-Geräte bereit, sodass das Audio-HAL-Implementierung kann mit den virtualisierten Soundgeräten über die TinyALSA-Bibliothek.

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. OEMs können eigene Audio-HAL implementieren, indem sie die audiobezogenen Variablen in /device/google/trout/aosp_trout_common.mk.

Das Audiosteuerelement HAL verwaltet den Audiofokus in AAOS. Wenn das System beispielsweise Notrufe, muss Musik im Hintergrund stummgeschaltet werden. Die Audiosteuerung HAL benachrichtigt die Apps, die Musik abspielen, um ihn in dieser Situation stummzuschalten. Im virtualisierten System können Sounds von anderen VMs stammen. In der Referenzimplementierung wird die AAOS-Gast-VM läuft einen Audiokontrollserver-Daemon, der GRPC-vsock verwendet, um Audiofokus-Anfragen von anderen VMs. Die Host-VM kann device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller verwenden Anfragen zur Audiosteuerung an AAOS gesendet. Während libandroid_audio_controller die Audiofokus senden, sendet er weiterhin Heartbeats an AAOS, bis der Fokus wieder losgelassen wird.

<ph type="x-smartling-placeholder">
</ph> Audioarchitektur
Abbildung 5: Audioarchitektur

Bluetooth

Die Bluetooth-Implementierung basiert auf dem unten dargestellten Design.

<ph type="x-smartling-placeholder">
</ph> Bluetooth-Architektur
Abbildung 5: Bluetooth-Architektur

Bluetooth-Freisprecheinrichtung

Zum Aktivieren des Bluetooth Hands-Free Profile (HFP) auf trout, dem VirtIO-Audiogerät Die Spezifikation wurde erweitert, um Audiosteuerelemente zu unterstützen. Bei diesem Ansatz wird ein VirtIO-Sound -Gerät auf der Host-/Hypervisor-Seite bietet diese drei Audiosteuerelemente für den HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Wenn AAOS als Gast-VM ausgeführt wird, verwendet AAOS TinyAlsa zum Festlegen dieser Audiosteuerelemente. HFP aktivieren verwendet der Host/Hypervisor das anbieterspezifische Routing und die Kalibrierung entsprechend.

Die Bluetooth-Implementierung basiert auf der folgenden Abbildung.

<ph type="x-smartling-placeholder">
</ph> Bluetooth-Architektur
Abbildung 5: Bluetooth-Architektur

Dumpstate

Beim Erstellen des Fehlerberichts für virtualisiertes AAOS ist es hilfreich, Informationen zur Host-VM anzugeben damit die Entwickelnden einen umfassenderen Überblick über das System haben. Um dies zu erreichen, Die Referenzimplementierung trout implementiert IDumpstateDevice HAL, das erfasst die Host-VM-Informationen über GRPC-vsock. Die Host-VM im tar-Paket Die Informationen im Fehlerbericht haben den Namen dumpstate_board.bin, während sich die Dump-Logs unter dumpstate_board.txt.

So konfigurieren Sie die auszuführenden Befehle:

  1. Kopieren Sie die Konfigurationsdetails aus der nachfolgenden 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 den Pfad der neuen XML-Datei beim Start an den Dumpstate-Server. Hier einige Beispiele: 
    --config_file my_config.xml

Extended View System (EVS)

Das Extended View System (EVS) dient der Wiedergabe von Videos, die mit der Rückansicht aufgenommen wurden, Surround-View-Kameras. Im virtualisierten AAOS kann der EVS-Stack auf den Videostream von das virtualisierte V4L2-Streaminggerät, das den VirtIO-Videotreiber nutzt.

Garagenmodus

Weitere Informationen finden Sie unter Garage-Modus.

Das Aufrufen und Beenden des Garage-Modus wird durch AP_POWER_STATE_REQ-Eigenschaften ausgelöst vom Fahrzeug-HAL gesendet. Im Virtualisierungsmodus wird der Garage-Modus vom Host ausgelöst. Die Host-VM sollte eingeschaltet bleiben, um virtuelle Geräte für die Android-VM bereitzustellen, bis Android ausgeschaltet ist. Der VHAL-Server auf der Host-VM sendet das Signal zum Herunterfahren an die AAOS-Gast-VM. Nach Empfang des Signal-VHAL-Clients wechselt die AAOS-VM in den Garage-Modus und sendet den Heartbeat damit die Host-VM aktiv bleibt.

Globales Satellitennavigationssystem (GNSS)

In trout 1.0 wurde die Unterstützung für GNSS-Virtualisierungen über virtio-console um wurde hinzugefügt. Die Implementierung unterstützt den Austausch von Rohdatenmessungen und Standortkorrekturen von dem Gastgeber.

Das Datenaustauschformat ist das CSV-Format, das von der GnssLogger-App verwendet wird. In der Referenzimplementierung Da der native GNSS-Treiber nicht verfügbar ist, werden zwar simulierte Daten bereitgestellt, ohne Gaständerungen implementiert werden. Ein Beispiel für einen simulierten Host-Agent wird im Rahmen des Der Quellcode von trout.

Für die aktuelle Implementierung werden die GNSS-Initialisierung und das Assisted GNSS (AGNSS) erwartet. durch die Umgebung des Hostbetriebssystems.

<ph type="x-smartling-placeholder">
</ph> GNSS-Architektur
Abbildung 2: GNSS-Architektur

Grafik

Wenn AAOS als Gast-VM zusammen mit anderen Betriebssystemen für die Automobilbranche ausgeführt wird, kann Android direkten Zugriff auf die GPU oder den Display-Controller haben. In diesem Fall Mesa oder goldfish-opengl und einem virtio-gpu-Treiber auf der Android-Gast-VM und dem virtio-gpu-Gerät kann für den Zugriff auf die GPU verwendet werden.

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

<ph type="x-smartling-placeholder">
</ph> Grafikarchitektur
Abbildung 3: Grafikarchitektur

Sensoren

Wenn AAOS als Gast-VM zusammen mit anderen Betriebssystemen für die Automobilbranche ausgeführt wird, Android hat möglicherweise keinen direkten Zugriff auf die Sensoren. In diesem Fall führt der Virtio-SCMI-Treiber auf der Die Android-Gast-VM und das VirtIO-SCMI-Gerät auf der Host-VM werden für den Zugriff auf die Sensoren verwendet. Die AAOS-Virtualisierungsreferenzplattform bietet einen generischen und HW-unabhängigen Sensor HAL, der kann für ARM-basierte SoCs verwendet werden, um auf die Sensoren zuzugreifen.

Der Sensor HAL kommuniziert mit dem IIO SCMI-Treiber im Linux Kernel IIO-Subsystem. das das vom ARM Systemsteuerungs- und Verwaltungsschnittstelle (System Control and Management Interface, SCMI) Spezifikation zum Erkennen und Konfigurieren von Sensoren, Lesen von Sensordaten und Benachrichtigungen über Sensor Änderungen des Werts.

Der IIO SCMI-Treiber verwendet den VirtIO SCMI-Treiber, der VirtIO Transport nutzt wie im virtio-scmi Spezifikation zum Austausch von SCMI-Nachrichten mit dem VirtIO SCMI-Gerät auf der Host-VM. VirtIO Das SCMI-Gerät hat über SoC-spezifische Sensortreiber direkten Zugriff auf die Sensoren.

<ph type="x-smartling-placeholder">
</ph> Sensorarchitektur
Abbildung 4: Sensorarchitektur

HAL-Standort des Sensors

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

HAL-Konfiguration des Sensors

Der Sensor-HAL muss möglicherweise die von der Host-VM empfangenen Sensordaten ändern, um die Koordinatensystem der Android-Autosensoren Das Schema für die Sensorkonfiguration finden Sie unter device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd

OEMs können Sensorkonfiguration wie Ausrichtung und Standort in sensor_hal_configuration.xml und kopieren Sie die Datei unter /odm/etc/sensors/ oder /vendor/etc/sensors/. Im Folgenden finden Sie ein Beispiel für eine 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:

  • Client: Stellt APIs bereit, die von Android in virtualisiertem AAOS verwendet werden
  • Server: Kommuniziert direkt mit Hardware, wie z. B. Fahrzeugbussen (oder einen Emulator).

Bei der Virtualisierung wird der VHAL-Server auf der Host-VM ausgeführt. Der VHAL-Client und der Server kommunizieren bis GRPC-vsock (weitere Informationen finden Sie unter device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). OEMs können eine eines anderen Transportprotokolls als gRPC. Beispiele: siehe 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 wie er ist, z. B. virtio-blk, virtio-input, virtio-console und virtio-net.

In der virtualisierten AAOS-Referenzplattform wird WLAN mit mac80211_hwsim unterstützt zur Aktivierung eines VirtWifi WLAN-Netzwerks, das dann virtio-net-Tunnel verwendet um den Netzwerkverkehr an die Host-VM zu senden, die direkten Zugriff auf das WLAN-Netzwerk hat.