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 viene utilizzato per la comunicazione tra VM. Le comunicazioni Vehicle HAL (VHAL), Audio Control e Dumpstate sono supportate utilizzando una connessione a un agente peer su una VM separata tramite un'interfaccia vsock. gRPC su vsock viene utilizzato per accedere a questi sottosistemi non standardizzati. gRPC nell'albero di origine Android viene 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 dell'HAL audio possa interagire con i dispositivi audio virtualizzati con la libreria TinyALSA.

L'implementazione predefinita dell'HAL 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 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 in riproduzione 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 daemon del server di controllo audio in esecuzione, che utilizza gRPC su vsock per ricevere 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 2. Architettura audio.

Bluetooth

L'implementazione di Bluetooth è illustrata nella figura seguente:

Architettura Bluetooth

Figura 3. 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, 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 di Bluetooth si basa sulla seguente illustrazione di progettazione:

Architettura Bluetooth

Figura 4. 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 su vsock. Le informazioni della VM host in pacchetto tar sono denominate dumpstate_board.bin nel report sui bug, mentre i log di dumping si trovano in dumpstate_board.txt.

Per configurare i comandi da eseguire:

  1. Copia i dettagli di configurazione dal seguente file 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

Il sistema di visualizzazione estesa (EVS) mostra 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

L'attivazione e la disattivazione della modalità garage vengono attivate dalle proprietà AP_POWER_STATE_REQ inviate da VHAL. 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. Per saperne di più, consulta Modalità garage.

Sistema satellitare di navigazione globale (GNSS)

In trout 1.0 è incluso 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, il driver GNSS nativo non è disponibile, quindi sono disponibili dati simulati. Puoi implementare un driver nativo senza apportare modifiche lato guest. Un agente host simulato di esempio è fornito come parte del codice sorgente trout.

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

Architettura GNSS

Figura 5. 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 del display. In questo caso, puoi accedere alla GPU utilizzando Mesa o goldfish-opengl e un driver virtio-gpu sulla VM guest Android e sul dispositivo virtio-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 6. 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, puoi accedere ai sensori utilizzando il driver Virtio-SCMI sulla VM guest Android e il dispositivo VirtIO-SCMI sulla VM host. La piattaforma di riferimento per la virtualizzazione AAOS fornisce un HAL sensore generico e indipendente dall'hardware che puoi utilizzare 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 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 7. Architettura dei sensori.

Posizione dell'HAL dei sensori

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

Configurazione dell'HAL dei sensori

L'HAL dei sensori 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 è riportato un esempio di configurazione 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 (VHAL) è 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 su 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 quindi il tunnel virtio-net per inviare il traffico di rete alla VM host, che ha accesso diretto alla rete Wi-Fi effettiva.