Architecture

La plupart des modifications nécessaires à la compatibilité de VirtIO dans AAOS concernent le HAL. niveau d'implémentation et niveaux inférieurs dans le noyau commun d'Android. Le framework Android communique avec un HAL générique indépendant du matériel à l'aide des pilotes VirtIO dans l'invité AAOS Le noyau de VM, qui communique avec les périphériques 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 spécifiques au SoC.

La communication entre le pilote VirtIO et l'appareil VirtIO a lieu virtqueue, qui sont des tampons circulaires de type DMA pour les listes de diffusion de données. Plusieurs transports, tels que MMIO ou PCI permet d'échanger les messages VirtIO entre les VM.

Dans certains cas, vsock a été utilisé pour la communication entre VM. Les communications HAL du véhicule, Audio Control et 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 de l'arborescence source Android a été modifié pour fonctionner avec vsock avec l'adresse le format vsock:CID:PORT_NUMBER.

Architecture de virtualisation
Figure 1. Architecture de virtualisation

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 le l'implémentation HAL audio peut interagir avec les appareils audio virtualisés à l'aide de 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 sa plate-forme. Les OEM peuvent ou implémenter sa propre HAL audio en remplaçant les variables audio dans /device/google/trout/aosp_trout_common.mk.

La commande audio HAL gère la priorité audio dans AAOS. Par exemple, lorsque le système lit des alertes d'urgence, vous devrez peut-être couper le son de la musique diffusée en arrière-plan. La commande audio HAL demande aux applications qui diffusent de la musique de couper le son. Dans le système virtualisé, les sons peuvent provenir d'autres VM. Dans la mise en œuvre de référence, la VM invitée AAOS dispose d'un daemon de serveur de contrôle audio en cours d'exécution, 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. Alors que libandroid_audio_controller contient le focus audio continue d'envoyer des pulsations à AAOS jusqu'à ce que le focus soit libéré.

Architecture audio
Figure 5 : Architecture audio

Bluetooth

L'implémentation Bluetooth est basée sur la conception illustrée ci-dessous.

Architecture Bluetooth
Figure 5 : Architecture Bluetooth

Profil Bluetooth mains libres

Pour activer le profil mains libres Bluetooth (HFP) sur trout, l'appareil audio VirtIO a été étendue pour prendre en charge les commandes audio. Avec cette approche, un son VirtIO du côté de l'hôte/hyperviseur fournit les trois commandes audio suivantes liées à HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Lorsqu'AAOS s'exécute en tant que VM invitée, AAOS utilise TinyAlsa pour définir ces commandes audio. Pour activer HFP, procédez comme suit : cas d'utilisation, l'hôte/l'hyperviseur effectue le routage spécifique au fournisseur et le calibrage en conséquence.

L'implémentation du Bluetooth est basée sur l'illustration ci-dessous.

Architecture Bluetooth
Figure 5 : Architecture Bluetooth

État de vidage

Lors de la génération du rapport de bug pour l'AAOS virtualisé, il est utile d'inclure les informations de 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 l'HAL IDumpstateDevice, qui collecte les informations de la VM hôte via GRPC-vsock. La VM hôte empaquetée "tar" les informations sont nommées dumpstate_board.bin dans le rapport de bug alors que le vidage des journaux se trouve dumpstate_board.txt

Pour configurer les commandes à exécuter:

  1. 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>
  2. Transmettez le chemin d'accès du nouveau fichier XML au serveur dumpstate lors du lancement. Par exemple: 
    --config_file my_config.xml

EVS (Extended View System)

Le système EVS (Extended View System) est utilisé pour afficher la vidéo capturée par la vue arrière et caméras avec vue surround. Dans l'AAOS virtualisé, la pile EVS peut accéder au flux vidéo l'appareil de streaming V4L2 virtualisé qui utilise le pilote vidéo VirtIO.

Mode garage

Pour en savoir plus, consultez Mode parking :

L'accès au mode Garage et sa sortie sont déclenchés par les propriétés AP_POWER_STATE_REQ. envoyé par le HAL du véhicule. En mode virtualisation, le mode garage est déclenché côté hôte. La VM hôte doit rester allumée afin de fournir des appareils virtuels pour 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. Après avoir reçu le signal du client VHAL, la VM AAOS passe en mode Garage et commence à envoyer une pulsation. pour que la VM hôte reste active.

Système mondial de navigation satellite (GNSS)

Dans trout 1.0, la prise en charge de la virtualisation GNSS sur virtio-console ont été ajoutées. L'implémentation prend en charge l'échange de mesures brutes et de correctifs d'emplacement à partir des l'hôte à 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 disponibles, mais un pilote natif peuvent être implémentés sans aucune modification côté invité. Un exemple d'agent hôte fictif est fourni dans le cadre le code source trout.

La mise en œuvre actuelle nécessite que l'initialisation GNSS et le GNSS assisté (AGNSS) soient gérés. par l'environnement de l'OS hôte.

Architecture GNSS
Figure 2. Architecture GNSS

Graphiques

Lorsqu'AAOS est exécuté en tant que VM invitée avec d'autres systèmes d'exploitation automobiles, Android peut ne pas ont un accès direct au GPU ou 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 pour accéder au GPU.

Sur la VM invitée Android, Mesa ou goldfish-opengl encode les commandes OpenGLES : en flux Gallium ou en flux GLES généré automatiquement, respectivement. virtio-gpu le pilote du noyau est utilisé comme transport. Côté hôte, virglrenderer (pour Mesa) et vulkan-cereal (pour goldfish-opengl) répète le flux de commande décodé sur au-dessus du pilote de GPU existant. La plate-forme de référence AAOS trout est compatible avec OpenGL ES uniquement avec la prise en charge de Vulkan, prévue dans une prochaine version.

Architecture graphique
Figure 3. Architecture graphique

Capteurs

Quand AAOS s'exécute en tant que VM invitée avec d'autres systèmes d'exploitation automobiles, Android ne dispose peut-être pas d'un accès direct aux capteurs. Dans cet exemple, le pilote Virtio-SCMI La VM invitée Android et l'appareil VirtIO-SCMI de la VM hôte permettent d'accéder aux capteurs. La plate-forme de référence de virtualisation AAOS fournit une couche HAL de capteurs générique et indépendante du matériel permet aux SoC basés sur l'architecture ARM d'accéder aux capteurs.

Le HAL du capteur communique avec le pilote SCMI IIO dans le sous-système IIO du noyau Linux. qui utilise le protocole de gestion des capteurs SCMI fourni par le ACTIVER Interface SCMI (System Control and Management Interface) pour détecter et configurer les capteurs, lire leurs données et être averti des changements de valeur.

Le pilote SCMI IIO utilise le pilote SCMI VirtIO, qui utilise le transport VirtIO. tel que spécifié dans le virtio-scmi pour échanger des messages SCMI avec l'appareil SCMI VirtIO sur la VM hôte. VirtIO L'appareil SCMI dispose d'un accès direct aux capteurs via des pilotes de capteur spécifiques au SoC.

Architecture des capteurs
Figure 4. Architecture des capteurs

Emplacement du capteur HAL

L'implémentation de référence du capteur HAL, qui utilise VirtIO SCMI, se trouve à l'adresse device/google/trout/hal/sensors

Configuration HAL du capteur

Le HAL du capteur peut avoir besoin de modifier les données des capteurs reçues de la VM hôte pour qu'elles respectent Système de coordonnées du capteur de voiture Android. Le schéma de configuration des capteurs est disponible 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 la position, sensor_hal_configuration.xml, puis copiez le fichier à l'emplacement /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 couche d'abstraction du matériel pour les véhicules comprend deux composants:

  • Client : Fournit les API utilisées par Android dans AAOS virtualisé
  • Serveur. Il communique directement avec le matériel, tel que le bus d'un 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. Par exemple, voir 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 de blocs, Réseau, Console, Entrée, Socket et Entropie. Pour ces sous-systèmes, AAOS utilise le pilote tel quel, par exemple virtio-blk, virtio-input, virtio-console et virtio-net.

Sur la plate-forme de référence virtualisée AAOS, 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 vers la VM hôte, qui dispose d'un accès direct au réseau Wi-Fi réel.