Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

Architektur

Die meisten Änderungen, die zur Unterstützung von VirtIO in AAOS erforderlich sind, betreffen Änderungen auf HAL-Implementierungsebene und darunter im Android Common Kernel. Das Android-Framework kommuniziert über die VirtIO-Treiber im AAOS-Gast-VM-Kernel mit einer generischen, hardwareunabhängigen HAL, die ü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 von Scatter-Gather-Listen. Es können mehrere Transportmechanismen wie MMIO oder PCI verwendet werden, um VirtIO-Nachrichten zwischen VMs auszutauschen.

In einigen Fällen wurde vsock für die VM-interne Kommunikation genutzt. Die Kommunikation zwischen Vehicle 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 für den Zugriff auf diese nicht standardisierten Subsysteme verwendet. GRPC im Android-Quellbaum wurde so geändert, dass es mit vsock mit dem Adressformat vsock:CID:PORT_NUMBER funktioniert.

**Abbildung 1** Virtualisierungsarchitektur

Audio

In virtualisiertem AAOS kann die Android-Gast-VM virtio-snd für den Zugriff auf Audio verwenden. virtio-snd stellt die virtuellen PCM-Geräte der Android-VM zur Verfügung, damit die Audio-HAL-Implementierung über die TinyALSA-Bibliothek mit den virtuellen Audiogeräten interagieren kann.

Die Standard-HAL-Implementierung für Audio 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. überschreiben.

Die Audio-HAL verwaltet den Audiofokus in AAOS. Wenn das System beispielsweise Notfalltöne abspielt, muss die im Hintergrund abgespielte Musik möglicherweise stummgeschaltet werden. Die HAL für die Audiosteuerung benachrichtigt die Apps, die in dieser Situation Musik abspielen, dass sie stummgeschaltet werden sollen. Im virtualisierten System können die Geräusche von anderen VMs stammen. In der Referenzimplementierung wird auf der AAOS-Gast-VM ein Audio-Kontrollserver-Daemon ausgeführt, der über GRPC-vsock Audiofokusanfragen von anderen VMs empfängt. Die Host-VM kann device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller verwenden, um Audiosteuerungsanfragen an AAOS zu senden. Solange libandroid_audio_controller den Audiofokus hat, sendet es weiterhin Heartbeats an AAOS, bis der Fokus aufgehoben wird.

Bluetooth

Die Bluetooth-Implementierung basiert auf dem unten dargestellten Design.

Bluetooth-Freisprechprofil

Um das Bluetooth-Freisprechprofil (HFP) auf trout zu aktivieren, wurde die VirtIO-Soundgerätespezifikation um die Unterstützung von Audiosteuerungen erweitert. Bei diesem Ansatz bietet ein VirtIO-Audiogerät auf Host-/Hypervisorseite die folgenden drei Audiosteuerungen für 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-Use-Case zu aktivieren, führt der Host/Hypervisor das anbieterspezifische Routing und die Kalibrierung entsprechend aus.

Die Bluetooth-Implementierung basiert auf der folgenden Designillustration.

Dumpstate

Wenn Sie den Fehlerbericht für virtualisierte AAOS generieren, sollten Sie Informationen zur Host-VM angeben, damit die Entwickler ein umfassenderes Bild des Systems haben. Dazu wird in der trout-Referenzimplementierung die IDumpstateDevice HAL implementiert, die die Informationen zur Host-VM über GRPC-vsock erfasst. Die Informationen zur Host-VM, die im Tar-Format verpackt sind, haben im Fehlerbericht den Namen dumpstate_board.bin. Die Dump-Logs befinden sich unter dumpstate_board.txt.

So konfigurieren Sie die ausführbaren Befehle:

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>

Ü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 erweiterte Sichtsystem (EVS) wird verwendet, um Videomaterial von der Rückkamera und den Kameras für die 360-Grad-Ansicht anzuzeigen. In virtualisiertem AAOS kann der EVS-Stack auf den Videostream des virtuellen V4L2-Streaminggeräts zugreifen, das den VirtIO-Videotreiber verwendet.

Garagenmodus

Weitere Informationen finden Sie unter Garage Mode.

Das Ein- und Ausschalten des Garagenmodus wird durch AP_POWER_STATE_REQ-Properties ausgelöst, die vom Vehicle 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 Ausschaltsignal an die AAOS-Gast-VM. Nach Erhalt des VHAL-Client-Signals wechselt die AAOS-VM in den Garage-Modus und sendet Heartbeat-Signale, um die Host-VM aktiv zu halten.

Globales Navigationssatellitensystem (GNSS)

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

Das Datenaustauschformat ist das CSV-Format, das von der GnssLogger App verwendet wird. Da der native GNSS-Treiber in der Referenzimplementierung nicht verfügbar ist, werden Mock-Daten bereitgestellt. Ein nativer Treiber kann jedoch ohne Änderungen auf Gastseite implementiert werden. Im Quellcode von trout ist ein Beispiel für einen Mock-Host-Agenten enthalten.

Bei der aktuellen Implementierung wird davon ausgegangen, dass die GNSS-Initialisierung und das unterstützte GNSS (AGNSS) von der Host-Betriebssystemumgebung verarbeitet werden.

Grafik

Wenn AAOS als Gast-VM neben anderen Automotive-Betriebssystemen ausgeführt wird, hat Android möglicherweise keinen direkten Zugriff auf die GPU oder den Displaycontroller. 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 codieren Mesa oder goldfish-opengl OpenGLES-Befehle entweder in einen Gallium-Stream oder einen automatisch generierten GLES-Stream. Der virtio-gpu-Kerneltreiber wird als Transport verwendet. Auf der Hostseite geben virglrenderer (für Mesa) und vulkan-cereal (für goldfish-opengl) den decodierten Befehlsstream über dem vorhandenen GPU-Treiber wieder. Die AAOS-Referenzplattform trout unterstützt nur OpenGL ES mit Vulkan-Unterstützung, die in einer zukünftigen Version erwartet wird.

Sensoren

Wenn AAOS als Gast-VM neben anderen Automotive-Betriebssystemen 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 hardwareagnostische Sensor-HAL, die für ARM-basierte SoCs zum Zugriff auf die Sensoren verwendet werden kann.

Die Sensor-HAL kommuniziert mit dem IIO SCMI-Treiber im IIO-Subsystem des Linux-Kernels. Dieser verwendet das SCMI-Sensor-Management-Protokoll, das von der ARM SCMI-Spezifikation (System Control and Management Interface, Systemsteuerungs- und ‑verwaltungsschnittstelle) bereitgestellt wird, um Sensoren zu erkennen und zu konfigurieren, Sensordaten zu lesen und über Sensorwertänderungen informiert zu werden.

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

HAL-Speicherort des Sensors

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

Sensor HAL-Konfiguration

Die Sensor-HAL muss die von der Host-VM empfangenen Sensordaten möglicherweise ändern, um dem Koordinatensystem des Android-Fahrzeugsensors 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 Standort, in sensor_hal_configuration.xml angeben und die Datei entweder unter /odm/etc/sensors/ oder /vendor/etc/sensors/ kopieren. Unten finden Sie eine Beispielkonfiguration für einen Sensor:

<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 Implementierung der Vehicle HAL besteht aus zwei Komponenten:

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

Bei der Virtualisierung wird der VHAL-Server auf der Host-VM ausgeführt. Der VHAL-Client und der VHAL-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 gut 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 VirtWifi-drahtloses Netzwerk zu ermöglichen, das dann den Netzwerkverkehr über einen virtio-net-Tunnel an die Host-VM sendet, die direkten Zugriff auf das eigentliche WLAN hat.

Architektur Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.