Architettura

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

La maggior parte delle modifiche necessarie per supportare VirtIO in AAOS comporta modifiche a livello di implementazione HAL e al di sotto nel kernel comune di Android. Il framework Android comunicate con un HAL generico agnostico hardware utilizzando i driver VirtIO nel kernel della VM guest AAOS, che comunica con i dispositivi VirtIO lato host utilizzando i protocolli VirtIO. I dispositivi VirtIO 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 anulari simili a DMA di elenchi scatter gather. 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 HAL del veicolo, il controllo audio e le comunicazioni 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 del codice sorgente di Android è stato modificato per funzionare con vsock con il formato di indirizzovsock:CID:PORT_NUMBER.

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 propria piattaforma. Gli OEM possono anche implementare il proprio HAL audio sostituendo le variabili relative all'audio in /device/google/trout/aosp_trout_common.mk.

L'HAL di controllo audio gestisce l'attenzione audio in AAOS. Ad esempio, quando il sistema riproduce suoni di emergenza, potrebbe essere necessario disattivare l'audio della musica in background. L'HAL di controllo audio invia una notifica alle app che riproducono musica per 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 demone del server di controllo audio in esecuzione, che utilizza GRPC-vsock per ricevere richieste di attenzione 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 attivo il controllo audio, continua a inviare heartbeat ad AAOS finché il controllo non viene rilasciato.

Bluetooth

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

Profilo Bluetooth Hands-Free

Per attivare il profilo Hands-Free (HFP) Bluetooth su trout, la specifica del dispositivo audio VirtIO è stata estesa per supportare i controlli audio. Con questo approccio, un dispositivo audio VirtIO sul lato host/hypervisor fornisce questi tre controlli audio relativi 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/l'hypervisor esegue il routing e la calibrazione specifici del fornitore di conseguenza.

L'implementazione del Bluetooth si basa sull'illustrazione del design riportata di seguito.

Dumpstate

Quando generi il report di bug per AAOS virtualizzato, è utile includere le informazioni sulla VM host in modo che gli sviluppatori abbiano una visione più completa del sistema. Per farlo, l'implementazione di riferimento trout implementa l'HAL IDumpstateDevice, che raccoglie le informazioni della VM host tramite GRPC-vsock. Le informazioni sulla VM host pacchettizzata con "tar" sono denominate dumpstate_board.bin nel report di 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 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 videocamere di visualizzazione posteriore e panoramica. 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 ulteriori informazioni, consulta la sezione Modalità Garage.

L'entrata e l'uscita dalla modalità Garage vengono attivate dalle proprietà AP_POWER_STATE_REQ inviate dall'HAL del veicolo. 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 l'indicatore di arresto alla VM guest AAOS. Una volta 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.

Global Navigation Satellite System (GNSS)

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

Il formato di scambio dati è CSV utilizzato dall'app GnssLogger. Nell'implementazione di riferimento, poiché il driver GNSS nativo non è disponibile, vengono resi disponibili dati simulati, ma un driver nativo può essere implementato senza modifiche lato guest. Un agente host simulato di esempio è fornito nel codice sorgente di trout.

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

Grafica

Quando AAOS è in esecuzione come VM guest insieme ad altri sistemi operativi per auto e motori, Android potrebbe non avere accesso diretto alla GPU o al controller del display. In questo caso, per accedere alla GPU è possibile utilizzare 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 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 solo OpenGL ES con il supporto di Vulkan, previsto in una release futura.

Sensori

Quando AAOS è in esecuzione come VM guest insieme ad altri sistemi operativi per auto e motori, 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 Sensor generico e indipendente dall'hardware che può essere utilizzato per consentire ai SoC basati su ARM di accedere ai sensori.

L'HAL del sensore 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 ed essere avvisato delle variazioni dei valori dei sensori.

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

Posizione dell'HAL del sensore

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

Configurazione dell'HAL del sensore

L'HAL del sensore potrebbe dover modificare i dati del sensore ricevuti dalla VM host per rispettare il sistema di coordinate del sensore dell'auto Android. Lo schema per la configurazione del sensore è disponibile in device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

Gli OEM possono fornire la configurazione del sensore, ad esempio 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 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>

Vehicle HAL

L'implementazione dell'HAL del veicolo è 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).

In virtualizzazione, il server VHAL viene eseguito sulla VM host. Il client e il server VHAL comunicano tramite GRPC-vsock (per ulteriori informazioni, 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 Block Storage, Rete, Console, Input, Socket ed 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 attivare 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.