La maggior parte delle modifiche necessarie per supportare VirtIO in AAOS riguardano modifiche a livello di implementazione HAL e inferiori nel kernel comune 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 driver di dispositivo specifici del SoC.
La comunicazione tra il driver VirtIO e il dispositivo VirtIO avviene con virtqueue , che sono buffer ad anello simili a DMA di elenchi di raccolta scatter. Diversi trasporti, come MMIO o PCI possono essere utilizzati per scambiare messaggi VirtIO tra VM.
In alcuni casi, vsock è stato sfruttato per la comunicazione tra VM. Le comunicazioni HAL del veicolo, controllo audio 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 dei sorgenti Android è stato modificato per funzionare con vsock con il formato dell'indirizzo vsock: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 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 sovrascrivendo le variabili relative 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, potrebbe essere necessario disattivare l'audio della musica riprodotta in sottofondo. L'HAL di controllo audio 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 guest AAOS ha un daemon del server di controllo audio in esecuzione, che utilizza GRPC-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 battiti cardiaci ad AAOS finché il focus non viene rilasciato.
Bluetooth
L'implementazione Bluetooth si basa sul progetto illustrato di seguito.
Profilo vivavoce Bluetooth
Per abilitare il profilo vivavoce Bluetooth (HFP) sulle trout , le specifiche del dispositivo audio VirtIO sono state estese per supportare i controlli audio. Utilizzando 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 ospite, AAOS utilizza TinyAlsa per impostare questi controlli audio. Per abilitare il caso d'uso HFP, l'host/hypervisor esegue di conseguenza il routing e la calibrazione specifici del fornitore.
L'implementazione Bluetooth si basa sull'illustrazione del progetto seguente.
Stato discarica
Quando si genera la segnalazione di bug per AAOS virtualizzato, è utile includere informazioni sulla VM host in modo che gli sviluppatori abbiano una visione più completa del sistema. A tale scopo, l'implementazione del riferimento trout implementa IDumpstateDevice HAL, che raccoglie le informazioni sulla VM host tramite GRPC-vsock . Le informazioni sulla VM host nel pacchetto `tar` sono denominate dumpstate_board.bin nel bugreport mentre i log di dumping si trovano in dumpstate_board.txt .
Per configurare i comandi da eseguire:
- 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> - Passa il percorso del nuovo file XML al server dumpstate all'avvio. Ad esempio:
--config_file my_config.xml
Sistema di visualizzazione estesa (EVS)
L'Extended View System (EVS) viene utilizzato per visualizzare i video catturati dalle telecamere di visione posteriore e surround. In AAOS virtualizzato, lo stack EVS può accedere al flusso video dal dispositivo di streaming V4L2 virtualizzato che utilizza il driver VirtIO-video.
Modalità garage
Per ulteriori informazioni, vedere Modalità Garage .
L'ingresso e l'uscita dalla modalità Garage vengono attivati dalle proprietà AP_POWER_STATE_REQ inviate dall'HAL del veicolo. Nella 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 arresto alla VM guest AAOS. Dopo aver ricevuto il segnale dal client VHAL, la VM AAOS entra in modalità Garage e inizia a inviare segnali di heartbeat per mantenere attiva la VM host.
Sistema globale di navigazione satellitare (GNSS)
In trout 1.0 è stato aggiunto il supporto per la virtualizzazione GNSS su virtio-console . L'implementazione supporta lo scambio di misurazioni grezze e correzioni di posizione dall'host all'ospite.
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 fittizi ma è possibile implementare un driver nativo senza alcuna modifica sul lato ospite. Un esempio di agente host fittizio viene fornito come parte del codice sorgente trout .
L'attuale implementazione prevede che l'inizializzazione GNSS e il GNSS assistito (AGNSS) siano gestiti dall'ambiente del sistema operativo host.
Grafica
Quando AAOS viene eseguito come VM ospite insieme ad altri sistemi operativi automobilistici, Android potrebbe non avere accesso diretto alla GPU o al controller del display. In questo caso, è possibile utilizzare 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 codificano i comandi OpenGLES rispettivamente in un flusso Gallium o in un flusso 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 il flusso 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 futura release.
Sensori
Quando AAOS viene eseguito come VM ospite insieme ad altri sistemi operativi automobilistici, Android potrebbe non avere accesso diretto ai sensori. In questo caso, per accedere ai sensori vengono utilizzati 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 Sensor HAL 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 SCMI IIO nel sottosistema Linux Kernel IIO, che utilizza il protocollo di gestione dei sensori SCMI fornito dalla specifica ARM System Control and Management Interface (SCMI) per rilevare e configurare sensori, leggere i dati dei sensori ed essere avvisato della presenza di sensori. variazioni di valore.
Il driver IIO SCMI utilizza il driver VirtIO SCMI, che utilizza il protocollo di trasporto VirtIO come specificato nella specifica virtio-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 del SoC.
Posizione dell'HAL del sensore
L'implementazione di riferimento del sensore HAL, che utilizza VirtIO SCMI, si trova in device/google/trout/hal/sensors .
Configurazione HAL del sensore
L'HAL del sensore potrebbe dover modificare i dati del sensore ricevuti dalla VM host per conformarsi al 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, come orientamento e posizione, in sensor_hal_configuration.xml e copiare il file in /odm/etc/sensors/ o /vendor/etc/sensors/ . Di seguito viene fornita 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>
Veicolo HAL
L'implementazione dell'HAL del veicolo è costituita da due componenti:
- Cliente. Fornisce le API utilizzate da Android in AAOS virtualizzato
- Server. Comunica direttamente con l'hardware, come gli autobus dei veicoli (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, vedere device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Gli OEM possono utilizzare un protocollo di trasporto diverso da GRPC sovrascrivendo le API di comunicazione. Per esempi, vedere 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, Network, Console, Input, Socket ed Entropy. Per questi sottosistemi, AAOS utilizza il driver così com'è, come 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.