La plupart des modifications nécessaires pour prendre en charge VirtIO dans AAOS impliquent des modifications au niveau de l'implémentation HAL et en dessous dans le noyau commun Android. Le framework Android communique avec une HAL générique indépendante du matériel à l'aide des pilotes VirtIO dans le noyau de la VM invitée AAOS, qui communique avec les appareils VirtIO côté hôte à l'aide des protocoles VirtIO. Les appareils VirtIO côté hôte peuvent accéder au matériel physique à l'aide de pilotes d'appareils spécifiques au SoC.
La communication entre le pilote VirtIO et l'appareil VirtIO s'effectue avec virtqueue, qui sont des tampons circulaires de type DMA de listes de collecte de dispersion.
Plusieurs transports, tels que
MMIO
ou
PCI
peuvent être utilisés pour échanger les messages VirtIO entre les VM.
Dans certains cas, vsock a été utilisé pour la communication entre les VM.
Les communications HAL du véhicule, de contrôle audio et de dumpstate sont compatibles avec une connexion à un agent pair sur une VM distincte via une interface vsock.
GRPC-vsock est utilisé pour accéder à ces sous-systèmes non standardisés.
GRPC
dans l'arborescence source Android a été modifié pour fonctionner avec vsock au format d'adresse
vsock:CID:PORT_NUMBER.
Audio
Dans AAOS virtualisé, la VM invitée Android peut utiliser virtio-snd pour accéder à l'audio.
virtio-snd fournit les appareils PCM virtualisés à la VM Android afin que l'implémentation HAL audio puisse interagir avec les appareils audio virtualisés à l'aide de la bibliothèque TinyALSA.
L'implémentation HAL audio par défaut se trouve dans AOSP à l'adresse /device/google/trout/hal/audio/6.0. Les OEM peuvent modifier ro.vendor.trout.audiohal.{in,out}_period_{ms,count} pour leur plate-forme. Les OEM peuvent également implémenter leur propre HAL audio en remplaçant les variables liées à l'audio dans /device/google/trout/aosp_trout_common.mk..
La HAL de contrôle audio gère la priorité audio dans AAOS. Par exemple, lorsque le système émet des sons d'urgence, il peut être nécessaire de couper le son de la musique en arrière-plan. La HAL de contrôle audio avertit les applications qui diffusent de la musique de couper le son dans cette situation. Dans le système virtualisé, les sons peuvent provenir d'autres VM. Dans l'implémentation de référence, la VM invitée AAOS exécute un démon de serveur de contrôle audio qui utilise GRPC-vsock pour recevoir les requêtes de priorité audio d'autres VM.
La VM hôte peut utiliser device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller pour envoyer des requêtes de contrôle audio à AAOS. Tant que libandroid_audio_controller conserve la priorité audio, il continue d'envoyer des pulsations à AAOS jusqu'à ce que la priorité soit libérée.
Bluetooth
L'implémentation Bluetooth est basée sur la conception illustrée ci-dessous.
Profil mains libres Bluetooth
Pour activer le profil mains libres Bluetooth (HFP) sur trout, la spécification de l'appareil audio VirtIO a été étendue pour prendre en charge les commandes audio. Avec cette approche, un appareil audio VirtIO côté hôte/hyperviseur fournit les trois commandes audio liées au HFP :
hfp_enablehfp_set_sampling_ratehfp_volume
Lorsque AAOS s'exécute en tant que VM invitée, il utilise TinyAlsa pour définir ces commandes audio. Pour activer le cas d'utilisation HFP, l'hôte/hyperviseur effectue le routage et l'étalonnage spécifiques au fournisseur en conséquence.
L'implémentation Bluetooth est basée sur la conception illustrée ci-dessous.
Dumpstate
Lors de la génération du rapport de bug pour AAOS virtualisé, il est utile d'inclure des informations sur la VM hôte afin que les développeurs aient une vue plus complète du système. Pour ce faire, l'implémentation de référence trout implémente la HAL IDumpstateDevice, qui collecte les informations de la VM hôte via GRPC-vsock. Les informations de la VM hôte empaquetées au format `tar`
sont nommées dumpstate_board.bin dans le rapport de bug, tandis que les journaux de vidage se trouvent dans
dumpstate_board.txt.
Pour configurer les commandes à exécuter :
- Copiez les détails de configuration du fichier ci-dessous dans un fichier XML, par exemple,
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> - Transmettez le chemin d'accès au nouveau fichier XML au serveur dumpstate lors du lancement. Exemple :
--config_file my_config.xml
Système de vision étendue (EVS)
Le système de vision étendue (EVS) permet d'afficher les vidéos capturées par les caméras de recul et de vision panoramique. Dans AAOS virtualisé, la pile EVS peut accéder au flux vidéo à partir de l'appareil de streaming V4L2 virtualisé qui utilise le pilote VirtIO-video.
Mode Garage
Pour en savoir plus, consultez Mode Garage.
L'activation et la désactivation du mode Garage sont déclenchées par les propriétés AP_POWER_STATE_REQ envoyées par la HAL du véhicule. En mode de virtualisation, le mode Garage est déclenché côté hôte.
La VM hôte doit rester allumée pour fournir des appareils virtuels à la VM Android, jusqu'à ce qu'Android soit éteint. Le serveur VHAL de la VM hôte envoie le signal d'arrêt à la VM invitée AAOS.
Lors de la réception du client VHAL de signal, la VM AAOS passe en mode Garage et commence à envoyer des signaux de pulsation pour maintenir la VM hôte active.
Système mondial de navigation par satellite (GNSS)
Dans trout 1.0, la prise en charge de la virtualisation GNSS via virtio-console a été ajoutée. L'implémentation permet l'échange de mesures brutes et de corrections de position de l'hôte vers l'invité.
Le format d'échange de données est le CSV utilisé par l'application GnssLogger. Dans l'implémentation de référence, comme le pilote GNSS natif n'est pas disponible, des données simulées sont mises à disposition, mais un pilote natif peut être implémenté sans aucune modification côté invité. Un exemple d'agent hôte simulé est fourni dans le code source trout.
L'implémentation actuelle s'attend à ce que l'initialisation GNSS et le GNSS assisté (AGNSS) soient gérés par l'environnement du système d'exploitation hôte.
Graphiques
Lorsque AAOS s'exécute en tant que VM invitée aux côtés d'autres systèmes d'exploitation automobiles, Android peut ne pas avoir d'accès direct au GPU ni au contrôleur d'affichage. Dans ce cas,
Mesa ou
goldfish-opengl
et un pilote virtio-gpu sur la VM invitée Android et l'appareil virtio-gpu
peuvent être utilisés pour accéder au GPU.
Sur la VM invitée Android, Mesa ou goldfish-opengl encode les commandes OpenGLES respectivement dans un flux Gallium ou dans un flux GLES généré automatiquement. Le pilote de noyau virtio-gpu est utilisé comme transport. Côté hôte, virglrenderer (pour Mesa) et vulkan-cereal (pour goldfish-opengl) relisent le flux de commandes décodé au-dessus du pilote GPU existant. La plate-forme de référence AAOS trout n'est compatible avec OpenGL ES qu'avec la prise en charge de Vulkan, prévue dans une prochaine version.
Capteurs
Lorsque AAOS s'exécute en tant que VM invitée aux côtés d'autres systèmes d'exploitation automobiles, Android peut ne pas avoir d'accès direct aux capteurs. Dans ce cas, le pilote Virtio-SCMI sur la VM invitée Android et l'appareil VirtIO-SCMI sur la VM hôte sont utilisés pour accéder aux capteurs. La plate-forme de référence de virtualisation AAOS fournit une HAL de capteur générique et indépendante du matériel qui peut être utilisée pour les SoC basés sur ARM afin d'accéder aux capteurs.
La HAL de capteur communique avec le pilote IIO SCMI dans le sous-système IIO du noyau Linux, qui utilise le protocole de gestion des capteurs SCMI fourni par la spécification ARM System Control and Management Interface (SCMI) pour découvrir et configurer les capteurs, lire les données des capteurs et être informé des modifications de la valeur des capteurs.
Le pilote IIO SCMI utilise le pilote VirtIO SCMI, qui utilise le protocole de transport VirtIO comme spécifié dans la spécification virtio-scmi pour échanger des messages SCMI avec l'appareil VirtIO SCMI sur la VM hôte. L'appareil VirtIO SCMI a un accès direct aux capteurs via des pilotes de capteurs spécifiques au SoC.
Emplacement de la HAL des capteurs
L'implémentation de référence de la HAL des capteurs, qui utilise VirtIO SCMI, se trouve dans device/google/trout/hal/sensors.
Configuration de la HAL des capteurs
La HAL des capteurs peut avoir besoin de modifier les données des capteurs reçues de la VM hôte pour se conformer au système de coordonnées des capteurs de voiture Android. Le schéma de configuration des capteurs se trouve dans device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.
Les OEM peuvent fournir la configuration des capteurs, comme l'orientation et l'emplacement, dans sensor_hal_configuration.xml et copier le fichier dans /odm/etc/sensors/ ou /vendor/etc/sensors/.
Vous trouverez ci-dessous un exemple de configuration de capteur :
<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 du véhicule
L'implémentation de la HAL du véhicule se compose de deux composants :
- Client. Fournit les API utilisées par Android dans AAOS virtualisé.
- Serveur. Communique directement avec le matériel, tel que les bus de véhicule (ou un émulateur).
Dans la virtualisation, le serveur VHAL s'exécute sur la VM hôte. Le client et le serveur VHAL communiquent via GRPC-vsock (pour en savoir plus, consultez device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). Les OEM peuvent utiliser un protocole de transport différent de GRPC en remplaçant les API de communication. Pour obtenir des exemples, consultez device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.
Autres sous-systèmes
VirtIO fournit déjà une interface bien définie pour des composants tels que le stockage par blocs, le réseau, la console, l'entrée, le socket et l'entropie. Pour ces sous-systèmes, AAOS utilise le pilote tel quel, par exemple virtio-blk, virtio-input, virtio-console et virtio-net.
Dans la plate-forme de référence AAOS virtualisée, le Wi-Fi est compatible avec mac80211_hwsim pour activer un réseau sans fil VirtWifi, qui utilise ensuite le tunnel virtio-net pour envoyer le trafic réseau à la VM hôte, qui a un accès direct au réseau Wi-Fi réel.