Architettura

La maggior parte delle modifiche necessarie per supportare VirtIO in AAOS riguardano l'HAL livello di implementazione e inferiore nel kernel comune di Android. Framework Android comunica con un HAL generico indipendente dall'hardware utilizzando i driver VirtIO nell'ambiente guest AAOS Kernel della VM, che comunica con i dispositivi VirtIO sul lato host utilizzando i protocolli VirtIO. I dispositivi VirtIO sul lato host possono accedere all'hardware fisico utilizzando driver di dispositivo specifici per SoC.

La comunicazione tra il driver VirtIO e il dispositivo VirtIO avviene con virtqueue, che sono buffer ad anello simili a DMA degli elenchi di raccolta a dispersione. Vari trasporti, come MMIO o PCI può essere usato per scambiare i messaggi VirtIO tra le VM.

In alcuni casi, vsock è stato sfruttato per le comunicazioni tra VM. Le comunicazioni HAL, Controllo audio e Dumpstate dei veicoli sono supportate tramite una connessione a un agente peer su una VM separata tramite un'interfaccia vsock. GRPC-vsock viene utilizzato per accedere a questi sottosistemi non standardizzati. GRPC nella struttura di origine Android è stata modificata in modo da funzionare con vsock con l'indirizzo formato vsock:CID:PORT_NUMBER.

Architettura di virtualizzazione
Figura 1. Architettura di virtualizzazione
.

Audio

Nell'AAOS virtualizzato, la VM ospite Android può usare virtio-snd per accedere all'audio. virtio-snd fornisce i dispositivi PCM virtualizzati alla VM Android in modo che l'implementazione audio HAL può interagire con i dispositivi audio virtualizzati con libreria TinyALSA.

L'implementazione predefinita dell'HAL per l'audio si trova in AOSP all'indirizzo /device/google/trout/hal/audio/6.0. Gli OEM possono modificare ro.vendor.trout.audiohal.{in,out}_period_{ms,count} per la sua piattaforma. Gli OEM possono anche implementare il proprio HAL audio, eseguendo l'override delle variabili relative all'audio in /device/google/trout/aosp_trout_common.mk.

Il controllo audio HAL gestisce il focus audio in AAOS. Ad esempio, quando il sistema sta riproducendo suoni di emergenza, potrebbe essere necessario disattivare l'audio della musica in sottofondo. Il controllo audio HAL avvisa le app che riproducono musica di disattivare l'audio in questa situazione. Nel sistema virtualizzato, i suoni possono provenire da altre VM. Nell'implementazione di riferimento, la VM ospite di AAOS è in esecuzione un daemon del server di controllo audio, che utilizza GRPC-vsock per ricevere da altre VM. La VM host può utilizzare device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller per inviare richieste di controllo audio ad AAOS. Mentre libandroid_audio_controller contiene il con il focus audio, continua a inviare heartbeat ad AAOS fino al rilascio dello stato attivo.

Architettura audio
Figura 5. Architettura audio
.

Bluetooth

L'implementazione del Bluetooth si basa sul design illustrato di seguito.

Architettura Bluetooth
Figura 5. Architettura Bluetooth
.

Profilo vivavoce Bluetooth

Per attivare il profilo vivavoce Bluetooth (HFP) su trout, il dispositivo audio VirtIO è stata estesa per supportare i controlli audio. Con questo approccio, un suono VirtIO sul lato host/hypervisor fornisce i seguenti tre controlli audio correlati all'HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Quando AAOS viene eseguito come VM ospite, AAOS utilizza TinyAlsa per impostare questi controlli audio. Per attivare l'HFP caso d'uso, l'host/hypervisor esegue di conseguenza il routing e la calibrazione specifici del fornitore.

L'implementazione del Bluetooth si basa sull'illustrazione del design che segue.

Architettura Bluetooth
Figura 5. Architettura Bluetooth
.

Stato di dump

Quando generi la segnalazione di bug per AAOS virtualizzato, è importante includere informazioni sulla VM host per avere una visione più completa del sistema. A questo scopo, L'implementazione dei riferimenti trout implementa IDumpstateDevice HAL, che raccoglie le informazioni sulla VM host tramite GRPC-vsock. La VM host in pacchetto "tar" l'informazione viene rinominata dumpstate_board.bin nella segnalazione di bug, mentre i log del dump si trovano dumpstate_board.txt.

Per configurare i comandi da eseguire:

  1. Copia i dettagli di configurazione dal file seguente in un file XML, ad esempio: 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. Passa il percorso del nuovo file XML al server dumpstate all'avvio. Ad esempio: 
    --config_file my_config.xml

Sistema di visualizzazione estesa (EVS)

Il sistema di visione estesa (EVS) è utilizzato per visualizzare i video acquisiti dalla vista posteriore e fotocamere con vista surround. Nell'AAOS virtualizzato, lo stack EVS può accedere allo stream video il dispositivo di streaming virtualizzato V4L2 che utilizza il driver video VirtIO.

Modalità garage

Per ulteriori informazioni, vedi Modalità garage.

L'attivazione e la disattivazione della modalità Garage vengono attivate dalle proprietà di AP_POWER_STATE_REQ inviato dall'HAL per il veicolo. In modalità virtualizzazione, la modalità Garage viene attivata dal lato host. La VM host deve rimanere accesa per fornire i dispositivi virtuali per la VM Android, finché Android non viene spento. Il server VHAL sulla VM host invia il segnale di arresto alla VM ospite di AAOS. Dopo aver ricevuto il segnale del client VHAL, la VM AAOS entra in modalità Garage e inizia a inviare heartbeat per mantenere attiva la VM host.

Sistema di navigazione satellitare globale (GNSS)

In trout 1.0, il supporto per la virtualizzazione GNSS su virtio-console è stato è stato aggiunto. L'implementazione supporta lo scambio di misurazioni non elaborate e di correzioni di località da l'organizzatore all'ospite.

Il formato di scambio di dati è il CSV utilizzato dall'app GnssLogger. Nell'implementazione dei riferimenti, poiché il driver GNSS nativo non è disponibile, vengono resi disponibili dati fittizi, ma viene utilizzato un driver nativo possono essere implementate senza alcuna modifica lato guest. Viene fornito un esempio di agente host come parte il codice sorgente di trout.

L'implementazione attuale prevede che vengano gestiti l'inizializzazione GNSS e il servizio GNSS assistito (AGNSS). dall'ambiente del sistema operativo host.

Architettura GNSS
Figura 2. architettura GNSS
.

Grafica

Quando AAOS è in esecuzione come VM guest insieme ad altri sistemi operativi per auto e motori, Android potrebbe non hanno accesso diretto alla GPU o al controller del display. In questo caso, Mesa o goldfish-opengl e un driver virtio-gpu sulla VM guest Android e sul dispositivo virtio-gpu per accedere alla GPU.

Sulla VM guest Android, Mesa o goldfish-opengl codifica i comandi OpenGLES rispettivamente in uno stream Gallium o in uno stream GLES generato automaticamente. virtio-gpu il driver kernel è usato come trasporto. Sul lato host, virglrenderer (per Mesa) e vulkan-cereal (per goldfish-opengl) riproduci di nuovo lo stream del comando decodificato su superiore al driver GPU esistente. La piattaforma di riferimento AAOS trout supporta OpenGL ES solo con il supporto Vulkan, previsto in una release futura.

Architettura grafica
Figura 3. Architettura grafica
.

Sensori

Quando AAOS è in esecuzione come VM guest insieme ad altri sistemi operativi del settore auto e motori, Android potrebbe non avere accesso diretto ai sensori. In questo caso, il driver Virtio-SCMI sulla Per accedere ai sensori vengono utilizzati la VM ospite Android e il dispositivo VirtIO-SCMI sulla VM host. La piattaforma di riferimento per la virtualizzazione AAOS fornisce un HAL per sensori generico e indipendente dall'HW che può essere utilizzata per consentire ai SoC basati su ARM di accedere ai sensori.

Il sensore HAL comunica con il driver SCMI IIO nel sottosistema IIO del kernel Linux, che utilizza il protocollo SCMI Sensor Management Protocol fornito dal ARM SCMI (System Control and Management Interface) per rilevare e configurare i sensori, leggerne i dati e ricevere notifiche modifiche ai valori.

Il driver SCMI IIO utilizza il driver VirtIO SCMI, che impiega il trasporto VirtIO come specificato nel virtio-scmi specifica per lo scambio di messaggi SCMI con il dispositivo VirtIO SCMI sulla VM host. La VirtIO Il dispositivo SCMI ha accesso diretto ai sensori tramite driver dei sensori specifici del SoC.

Architettura dei sensori
Figura 4. Architettura dei sensori
.

Posizione dell'HAL del sensore

L'implementazione di riferimento del sensore HAL, che utilizza VirtIO SCMI, si trova all'indirizzo device/google/trout/hal/sensors.

Configurazione HAL del sensore

L'HAL del sensore potrebbe dover modificare i dati dei sensori ricevuti dalla VM host per rispettare le Sistema di coordinate dei sensori per auto Android. Lo schema per la configurazione dei sensori è disponibile nella sezione device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

Gli OEM possono fornire la configurazione del sensore, come l'orientamento e la posizione, in sensor_hal_configuration.xml e copia il file in uno dei seguenti modi: /odm/etc/sensors/ o /vendor/etc/sensors/. Di seguito è riportata una configurazione di esempio del sensore:

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

HAL per veicoli

L'implementazione dell'HAL per il veicolo è costituita da due componenti:

  • Cliente. Fornisce le API utilizzate da Android in AAOS virtualizzato
  • Server. Comunica direttamente con l'hardware, ad esempio gli autobus del veicolo (o un emulatore).

Nella virtualizzazione, il server VHAL viene eseguito sulla VM host. Il client e il server VHAL comunicano tramite GRPC-vsock (per ulteriori informazioni, vedi device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). Gli OEM possono utilizzare un protocollo di trasporto diverso da GRPC mediante l'override delle API di comunicazione. Ad esempio: vedi device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

Altri sottosistemi

VirtIO fornisce già un'interfaccia ben definita per componenti come Archiviazione a blocchi, rete, console, input, socket ed entropia. Per questi sottosistemi, AAOS utilizza il conducente così com'è, ad esempio virtio-blk, virtio-input virtio-console e virtio-net.

Nella piattaforma di riferimento AAOS virtualizzata, il Wi-Fi è supportato con mac80211_hwsim per attivare una rete wireless VirtWifi, che utilizza poi il tunnel virtio-net per inviare il traffico di rete alla VM host, che ha accesso diretto alla rete Wi-Fi effettiva.