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 niveles inferiores 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 mediante 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 aprovechó vsock para la comunicación entre VMs. Las comunicaciones de HAL de vehículo, control de audio y dumpstate se admiten mediante una conexión a un agente par en una VM separada a través de una interfaz vsock. Se usa GRPC-vsock para acceder a estos subsistemas no estandarizados. GRPC en el árbol de fuentes de Android se modificó para que funcione con vsock con el formato de dirección 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-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, sigue enviando latidos a AAOS hasta que se libera el foco.

Arquitectura de audio
Figura 5: Arquitectura de audio

Bluetooth

La implementación de Bluetooth se basa en el diseño que se muestra a continuación.

Arquitectura de Bluetooth
Figura 5. 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 realizan el enrutamiento y la calibración específicos del proveedor según corresponda.

La implementación de Bluetooth se basa en el diseño que se muestra a continuación.

Arquitectura de Bluetooth
Figura 5. 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-vsock. La información de la VM host empaquetada en `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 archivo que se muestra a continuación 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 (EVS)

El sistema de vista extendida (EVS) se usa para mostrar el video capturado por las cámaras de visión trasera y de visión 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

Para obtener más información, consulta 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 HAL de vehículo. 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 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.

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

En trout 1.0, se agregó 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, como el controlador GNSS nativo no está disponible, se proporcionan datos simulados, pero se puede implementar un controlador nativo sin realizar cambios en el invitado. Se proporciona un agente host simulado de muestra como parte del código fuente trout.

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

Arquitectura de GNSS
Figura 2: 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, Mesa o goldfish-opengl y un controlador virtio-gpu en la VM invitada de Android y el dispositivo virtio-gpu se pueden usar para acceder a la GPU.

En la VM invitada de Android, Mesa o goldfish-opengl codifican los comandos de 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 3. 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, se usan el controlador Virtio-SCMI en la VM invitada de Android y el dispositivo VirtIO-SCMI en la VM host para acceder a los sensores. La plataforma de referencia de virtualización de AAOS proporciona una HAL de sensor genérica e independiente del HW que se puede 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 que proporciona la interfaz de administración y control del sistema ARM (SCMI) especificación 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 como se especifica 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 4. 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 auto 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/. A continuación, se proporciona una configuración de sensor de muestra:

<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 HAL de vehículo 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-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 almacenamiento en bloque, red, consola, entrada, socket y 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.