Arquitectura

La mayoría de los cambios necesarios para admitir VirtIO en AAOS implican cambios en el nivel de implementación de HAL y en el kernel común de Android. El framework de Android se comunica con una HAL genérica independiente del hardware mediante los controladores VirtIO en el kernel de la VM invitada de AAOS, que se comunica con los dispositivos VirtIO en el host mediante protocolos VirtIO. Los dispositivos VirtIO en el host pueden acceder al HW físico con controladores de dispositivos específicos del SoC.

La comunicación entre el controlador VirtIO y el dispositivo VirtIO se realiza con virtqueue, que son búferes de anillo similares a DMA de listas de dispersión y recopilación. Se pueden usar varios transportes, como MMIO o PCI , para intercambiar los mensajes VirtIO entre las VMs.

En algunos casos, se usa vsock para la comunicación entre VMs. Las comunicaciones de HAL de vehículo (VHAL), control de audio y Dumpstate se admiten mediante una conexión a un agente de par en una VM separada a través de una interfaz vsock. Se usa gRPC a través de vsock para acceder a estos subsistemas no estandarizados. gRPC en el árbol de origen de Android se modifica para funcionar con vsock con el formato de dirección de vsock:CID:PORT_NUMBER.

Arquitectura de virtualización

Figura 1: Arquitectura de virtualización

Audio

En AAOS virtualizado, la VM invitada de Android puede usar virtio-snd para acceder al audio. virtio-snd proporciona los dispositivos PCM virtualizados a la VM de Android para que la implementación de HAL de audio pueda interactuar con los dispositivos de sonido virtualizados con la biblioteca TinyALSA.

La implementación predeterminada de HAL de audio se encuentra en AOSP en /device/google/trout/hal/audio/6.0. Los OEM pueden modificar ro.vendor.trout.audiohal.{in,out}_period_{ms,count} para su plataforma. Los OEM también pueden implementar su propia HAL de audio anulando las variables relacionadas con el audio en /device/google/trout/aosp_trout_common.mk.

La HAL de control de audio administra el foco de audio en AAOS. Por ejemplo, cuando el sistema reproduce sonidos de emergencia, es posible que se deba silenciar la música que se reproduce en segundo plano. La HAL de control de audio notifica a las apps que reproducen música para que se silencien en esta situación. En el sistema virtualizado, los sonidos pueden provenir de otras VMs. En la implementación de referencia, la VM invitada de AAOS tiene un daemon de servidor de control de audio en ejecución, que usa gRPC a través de vsock para recibir solicitudes de foco de audio de otras VMs. La VM host puede usar device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller para enviar solicitudes de control de audio a AAOS. Mientras libandroid_audio_controller mantiene el foco de audio, continúa enviando latidos a AAOS hasta que se libera el foco.

Arquitectura de audio

Figura 2: Arquitectura de audio

Bluetooth

La implementación de Bluetooth se ilustra en la siguiente figura:

Arquitectura de Bluetooth

Figura 3: Arquitectura de Bluetooth

Perfil de manos libres de Bluetooth

Para habilitar el perfil de manos libres (HFP) de Bluetooth en trout, se extendió la especificación del dispositivo de sonido VirtIO para admitir controles de audio. Con este enfoque, un dispositivo de sonido VirtIO en el host o el hipervisor proporciona estos tres controles de audio relacionados con el HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Cuando AAOS se ejecuta como una VM invitada, AAOS usa TinyALSA para configurar estos controles de audio. Para habilitar el caso de uso de HFP, el host o el hipervisor realiza el enrutamiento y la calibración específicos del proveedor según corresponda.

La implementación de Bluetooth se basa en la siguiente ilustración de diseño:

Arquitectura de Bluetooth

Figura 4: Arquitectura de Bluetooth

Dumpstate

Cuando se genera el informe de errores para AAOS virtualizado, es valioso incluir información de la VM host para que los desarrolladores tengan una vista más completa del sistema. Para lograr esto, la implementación de referencia trout implementa la HAL IDumpstateDevice, que recopila la información de la VM host a través de gRPC sobre vsock. La información de la VM host empaquetada tar se denomina dumpstate_board.bin en el informe de errores, mientras que los registros de volcado se encuentran en dumpstate_board.txt.

Para configurar los comandos que se ejecutarán, haz lo siguiente:

  1. Copia los detalles de configuración del siguiente archivo en un archivo en formato XML, por ejemplo, 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. Pasa la ruta de acceso del nuevo archivo en formato XML al servidor de dumpstate cuando se inicie, por ejemplo: 
    --config_file my_config.xml

Sistema de vista extendida

El sistema de vista extendida (EVS) muestra el video capturado por las cámaras de vista trasera y de vista envolvente. En AAOS virtualizado, la pila de EVS puede acceder a la transmisión de video desde el dispositivo de transmisión V4L2 virtualizado que usa el controlador VirtIO-video.

Modo de garaje

La entrada y la salida del modo de garaje se activan con las propiedades AP_POWER_STATE_REQ que envía la VHAL. En el modo de virtualización, el modo de garaje se activa desde el host. La VM host debe permanecer encendida para proporcionar dispositivos virtuales para la VM de Android hasta que se apague Android. El servidor VHAL en la VM host envía la señal de apagado a la VM invitada de AAOS. Cuando recibe el cliente VHAL de la señal, la VM de AAOS ingresa al modo de garaje y comienza a enviar señales de latido para mantener activa la VM host. Para obtener más información, consulta Modo de garaje.

Sistema global de navegación por satélite (GNSS)

En trout 1.0, se incluye compatibilidad con la virtualización de GNSS a través de virtio-console. La implementación admite el intercambio de mediciones sin procesar y correcciones de ubicación del host al invitado.

El formato de intercambio de datos es el CSV que usa la app GNSSLogger. En la implementación de referencia, el controlador GNSS nativo no está disponible, por lo que sí lo están los datos simulados. Puedes implementar un controlador nativo sin realizar cambios en el invitado. Se proporciona un agente host simulado de muestra como parte del código fuente de trout.

La implementación espera que el entorno del SO host controle la inicialización de GNSS y el GNSS asistido (AGNSS).

Arquitectura de GNSS

Figura 5: Arquitectura de GNSS

Gráficos

Cuando AAOS se ejecuta como una VM invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo a la GPU ni al controlador de pantalla. En este caso, puedes acceder a la GPU con Mesa o goldfish-opengl y un controlador virtio-gpu en la VM invitada de Android y el dispositivo virtio-gpu.

En la VM invitada de Android, Mesa o goldfish-opengl codifica los comandos OpenGLES en una transmisión de Gallium o en una transmisión de GLES generada automáticamente, respectivamente. El controlador de kernel virtio-gpu se usa como transporte. En el host, virglrenderer (para Mesa) y vulkan-cereal (para goldfish-opengl) reproducen la transmisión de comandos decodificada sobre el controlador de GPU existente. La plataforma de referencia trout de AAOS admite OpenGL ES solo con compatibilidad con Vulkan, que se prevé en una versión futura.

Arquitectura de gráficos

Figura 6: Arquitectura de gráficos

Sensores

Cuando AAOS se ejecuta como una VM invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo a los sensores. En este caso, puedes acceder a los sensores con el controlador Virtio-SCMI en la VM invitada de Android y el dispositivo VirtIO-SCMI en la VM host. La plataforma de referencia de virtualización de AAOS proporciona una HAL de sensor genérica e independiente del HW que puedes usar para SoCs basados en ARM para acceder a los sensores.

La HAL de sensor se comunica con el controlador IIO SCMI en el subsistema IIO del kernel de Linux, que usa el protocolo de administración de sensores SCMI proporcionado por la especificación de la interfaz de administración y control del sistema ARM (SCMI) para descubrir y configurar sensores, leer datos de sensores y recibir notificaciones de cambios en los valores de los sensores.

El controlador IIO SCMI usa el controlador VirtIO SCMI, que usa el protocolo de transporte VirtIO en la especificación virtio-scmi para intercambiar mensajes SCMI con el dispositivo VirtIO SCMI en la VM host. El dispositivo VirtIO SCMI tiene acceso directo a los sensores a través de controladores de sensores específicos del SoC.

Arquitectura del sensor

Figura 7: Arquitectura de sensores

Ubicación de la HAL de sensor

La implementación de referencia de la HAL de sensor, que usa VirtIO SCMI, se encuentra en device/google/trout/hal/sensors.

Configuración de la HAL de sensor

Es posible que la HAL de sensor deba modificar los datos del sensor recibidos de la VM host para cumplir con el sistema de coordenadas del sensor del automóvil de Android. El esquema para la configuración del sensor se puede encontrar en device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.

Los OEM pueden proporcionar la configuración del sensor, como la orientación y la ubicación, en sensor_hal_configuration.xml y copiar el archivo en /odm/etc/sensors/ o /vendor/etc/sensors/. En el siguiente ejemplo, se proporciona una configuración del sensor:

<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 de vehículo

La implementación de la HAL de vehículo (VHAL) consta de dos componentes:

  • Cliente. Proporciona las APIs que usa Android en AAOS virtualizado.
  • Servidor. Se comunica directamente con el hardware, como los buses del vehículo (o un emulador).

En la virtualización, el servidor VHAL se ejecuta en la VM host. El cliente y el servidor VHAL se comunican a través de gRPC sobre vsock. Para obtener más información, consulta device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto. Los OEM pueden usar un protocolo de transporte diferente de gRPC anulando las APIs de comunicación. Para obtener ejemplos, consulta device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.

Otros subsistemas

VirtIO ya proporciona una interfaz bien definida para componentes como el almacenamiento de bloques, la red, la consola, la entrada, el socket y la entropía. Para estos subsistemas, AAOS usa el controlador tal como está, como virtio-blk, virtio-input, virtio-console y virtio-net.

En la plataforma de referencia de AAOS virtualizado, se admite Wi-Fi con mac80211_hwsim para habilitar una red inalámbrica VirtWifi, que luego usa el túnel virtio-net para enviar el tráfico de red a la VM host, que tiene acceso directo a la red Wi-Fi real.