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 un HAL générique indépendant 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 de 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 se fait avec virtqueue, qui sont des tampons en anneau de type DMA de listes de collecte de données.
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 inter-VM.
Les communications HAL du véhicule, le contrôle audio et les communications Dumpstate sont compatibles avec une connexion à un agent pair sur une VM distincte via une interface vsock.
GRPC-vsock permet d'accéder à ces sous-systèmes non standardisés.
GRPC dans l'arborescence source Android a été modifié pour fonctionner avec vsock avec le 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 avec la bibliothèque TinyALSA.
L'implémentation HAL audio par défaut se trouve dans AOSP à l'emplacement /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..
Le HAL de contrôle audio gère la priorité audio dans AAOS. Par exemple, lorsque le système diffuse des sons d'urgence, il peut être nécessaire de couper le son de la musique en arrière-plan. Dans ce cas, le HAL de contrôle audio informe les applications qui diffusent de la musique de couper le son. Dans le système virtualisé, les sons peuvent provenir d'autres VM. Dans l'implémentation de référence, un démon de serveur de contrôle audio s'exécute dans la VM invitée AAOS, 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 détient la sélection audio, il continue d'envoyer des battements de cœur à AAOS jusqu'à ce que la sélection 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 périphérique audio VirtIO côté hôte/hyperviseur fournit ces 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 le calibrage spécifiques au fournisseur en conséquence.
L'implémentation Bluetooth est basée sur l'illustration de conception ci-dessous.
Dumpstate
Lorsque vous générez le rapport de bug pour l'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 le HAL IDumpstateDevice, qui collecte les informations sur la VM hôte via GRPC-vsock. Les informations de la VM hôte empaquetées avec "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 au moment du lancement. Exemple :
--config_file my_config.xml
Système de vue étendue (EVS)
Le système de vue étendue (EVS, Extended View System) permet d'afficher la vidéo capturée par les caméras arrière et 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 la section 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 couche d'abstraction du matériel du véhicule. En mode 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 sur la VM hôte envoie le signal d'arrêt à la VM invitée AAOS.
À la réception du signal client VHAL, la VM AAOS passe en mode Garage et commence à envoyer des signaux de battement de cœur pour maintenir la VM hôte active.
Système de navigation par satellite global (GNSS)
Dans trout 1.0, la prise en charge de la virtualisation GNSS sur virtio-console a été ajoutée. L'implémentation permet d'échanger des mesures brutes et des 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 fictives sont mises à disposition, mais un pilote natif peut être implémenté sans aucune modification côté invité. Un exemple d'agent hôte fictif est fourni dans le code source trout.
L'implémentation actuelle s'attend à ce que l'environnement de l'OS hôte gère l'initialisation du GNSS et du GNSS assisté (AGNSS).
Graphiques
Lorsque AAOS s'exécute en tant que VM invitée avec d'autres systèmes d'exploitation automobiles, Android n'a peut-être pas 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 dans un flux Gallium ou un flux GLES généré automatiquement, respectivement. Le pilote de kernel virtio-gpu est utilisé comme transport. Côté hôte, virglrenderer (pour Mesa) et vulkan-cereal (pour goldfish-opengl) rejouent le flux de commandes décodé au-dessus du pilote GPU existant. La plate-forme de référence trout d'AAOS est compatible avec OpenGL ES uniquement 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 avec d'autres systèmes d'exploitation automobiles, Android peut ne pas avoir un 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 un HAL de capteur générique et indépendant du matériel qui peut être utilisé par les SoC ARM pour accéder aux capteurs.
Le HAL du capteur communique avec le pilote SCMI IIO dans le sous-système IIO du kernel Linux, qui utilise le protocole de gestion des capteurs SCMI fourni par la spécification ARM SCMI (System Control and Management Interface) pour découvrir et configurer les capteurs, lire les données des capteurs et être informé des modifications de valeur des capteurs.
Le pilote SCMI IIO utilise le pilote SCMI VirtIO, qui utilise le protocole de transport VirtIO comme spécifié dans la spécification virtio-scmi pour échanger des messages SCMI avec l'appareil SCMI VirtIO 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 du HAL du capteur
L'implémentation de référence du HAL du capteur, qui utilise VirtIO SCMI, se trouve dans device/google/trout/hal/sensors.
Configuration du HAL du capteur
Le HAL du capteur peut être amené à modifier les données du capteur 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 véhicule
L'implémentation du HAL du véhicule se compose de deux composants:
- Client Fournit les API utilisées par Android dans AAOS virtualisé
- Serveur Il communique directement avec le matériel, comme les bus du véhicule (ou un émulateur).
En 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 autre que 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 en mode bloc, 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.