Architettura

La maggior parte delle modifiche necessarie per supportare VirtIO in AAOS riguarda le modifiche a livello di implementazione HAL e inferiori nel kernel comune di Android. Il framework Android comunica con un HAL generico indipendente dall'hardware utilizzando i driver VirtIO nel kernel della VM guest AAOS, 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 i driver di dispositivo specifici per SoC.

La comunicazione tra il driver VirtIO e il dispositivo VirtIO avviene con virtqueue, che sono buffer ad anello di tipo DMA di elenchi di raccolta di dispersione. Per scambiare i messaggi VirtIO tra le VM è possibile utilizzare diversi trasporti, come MMIO o PCI.

In alcuni casi, vsock è stato utilizzato per la comunicazione tra VM. Le comunicazioni Vehicle HAL, Audio Control e Dumpstate sono supportate utilizzando 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 nell'albero di origine di Android è stato modificato per funzionare con vsock con il formato dell'indirizzo vsock:CID:PORT_NUMBER.

Architettura di virtualizzazione
Figura 1. Architettura di virtualizzazione

Audio

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

L'implementazione HAL audio predefinita si trova in AOSP in /device/google/trout/hal/audio/6.0. Gli OEM possono modificare ro.vendor.trout.audiohal.{in,out}_period_{ms,count} per la loro piattaforma. Gli OEM possono anche implementare il proprio HAL audio sostituendo le variabili correlate all'audio in /device/google/trout/aosp_trout_common.mk.

L'HAL di controllo audio gestisce il focus audio in AAOS. Ad esempio, quando il sistema riproduce suoni di emergenza, la musica riprodotta in background potrebbe dover essere disattivata. L'HAL di controllo audio notifica alle 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 guest AAOS ha un server daemon di controllo audio in esecuzione, che utilizza GRPC-vsock per ricevere le richieste di focus audio 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 mantiene il focus audio, continua a inviare heartbeat ad AAOS finché il focus non viene rilasciato.

Architettura audio
Figura 5. Architettura audio

Bluetooth

L'implementazione Bluetooth si basa sulla progettazione illustrata di seguito.

Architettura Bluetooth
Figura 5. Architettura Bluetooth

Profilo vivavoce Bluetooth

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

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

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

L'implementazione Bluetooth si basa sull'illustrazione di progettazione di seguito.

Architettura Bluetooth
Figura 5. Architettura Bluetooth

Dumpstate

Quando generi il report sui bug per AAOS virtualizzato, è utile includere le informazioni della VM host in modo che gli sviluppatori abbiano una visione più completa del sistema. A questo scopo, l'implementazione di riferimento trout implementa l'HAL IDumpstateDevice, che raccoglie le informazioni della VM host tramite GRPC-vsock. Le informazioni della VM host con pacchetto `tar` sono denominate dumpstate_board.bin nel report sui bug, mentre i log di dumping sono in dumpstate_board.txt.

Per configurare i comandi da eseguire:

  1. Copia i dettagli di configurazione dal file riportato di seguito 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 al momento dell'avvio. Ad esempio: 
    --config_file my_config.xml

Sistema di visualizzazione estesa (EVS)

Il sistema di visualizzazione estesa (EVS) viene utilizzato per visualizzare i video acquisiti dalle telecamere posteriori e surround. In AAOS virtualizzato, lo stack EVS può accedere allo stream video dal dispositivo di streaming V4L2 virtualizzato che utilizza il driver VirtIO-video.

Modalità Garage

Per saperne di più, consulta Modalità Garage.

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

Sistema di navigazione satellitare globale (GNSS)

In trout 1.0 è stato aggiunto il supporto per la virtualizzazione GNSS su virtio-console. L'implementazione supporta lo scambio di misurazioni non elaborate e correzioni della posizione dall'host al guest.

Il formato di scambio dati è il CSV utilizzato dall'app GnssLogger. Nell'implementazione di riferimento, poiché il driver GNSS nativo non è disponibile, vengono resi disponibili dati simulati, ma è possibile implementare un driver nativo senza apportare modifiche sul lato guest. Un agente host simulato di esempio viene fornito come parte del codice sorgente trout.

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

Architettura GNSS
Figura 2. Architettura GNSS

Grafica

Quando AAOS viene eseguito come VM guest insieme ad altri sistemi operativi per auto, Android potrebbe non avere accesso diretto alla GPU o al controller di visualizzazione. In questo caso, Mesa o goldfish-opengl e un driver virtio-gpu sulla VM guest Android e sul dispositivo virtio-gpu possono essere utilizzati per accedere alla GPU.

Nella VM guest Android, Mesa o goldfish-opengl codifica i comandi OpenGLES rispettivamente in uno stream Gallium o in uno stream GLES generato automaticamente. Il driver del kernel virtio-gpu viene utilizzato come trasporto. Sul lato host, virglrenderer (per Mesa) e vulkan-cereal (per goldfish-opengl) riproducono lo stream di comandi decodificato sopra il 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 viene eseguito come VM guest insieme ad altri sistemi operativi per auto, Android potrebbe non avere accesso diretto ai sensori. In questo caso, il driver Virtio-SCMI sulla VM guest Android e il dispositivo VirtIO-SCMI sulla VM host vengono utilizzati per accedere ai sensori. La piattaforma di riferimento per la virtualizzazione AAOS fornisce un HAL sensore generico e indipendente dall'hardware che può essere utilizzato per i SoC basati su ARM per accedere ai sensori.

Sensor HAL comunica con il driver IIO SCMI nel sottosistema IIO del kernel Linux, che utilizza il protocollo di gestione dei sensori SCMI fornito dalla specifica ARM System Control and Management Interface (SCMI) per rilevare e configurare i sensori, leggere i dati dei sensori e ricevere notifiche delle modifiche dei valori dei sensori.

Il driver IIO SCMI utilizza il driver VirtIO SCMI, che utilizza il protocollo di trasporto VirtIO come specificato nella specifica virtio-scmi per scambiare i messaggi SCMI con il dispositivo VirtIO SCMI sulla VM host. Il dispositivo VirtIO SCMI ha accesso diretto ai sensori tramite i driver dei sensori specifici per SoC.

Architettura dei sensori
Figura 4. Architettura dei sensori

Posizione di Sensor HAL

L'implementazione di riferimento di Sensor HAL, che utilizza VirtIO SCMI, si trova in device/google/trout/hal/sensors.

Configurazione di Sensor HAL

Sensor HAL potrebbe dover modificare i dati dei sensori ricevuti dalla VM host per essere conforme al sistema di coordinate dei sensori per auto Android. Lo schema per la configurazione dei sensori è disponibile in device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

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

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

Vehicle HAL

L'implementazione di Vehicle HAL è costituita da due componenti:

  • Client. Fornisce le API utilizzate da Android in AAOS virtualizzato
  • Server. Comunica direttamente con l'hardware, ad esempio i bus 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 saperne di più, consulta device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). Gli OEM possono utilizzare un protocollo di trasporto diverso da GRPC sostituendo le API di comunicazione. Per esempi, consulta device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

Altri sottosistemi

VirtIO fornisce già un'interfaccia ben definita per componenti come l'archiviazione a blocchi, la rete, la console, l'input, il socket e l'entropia. Per questi sottosistemi, AAOS utilizza il driver 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 abilitare 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.