Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Arquitectura

La mayoría de los cambios necesarios para admitir VirtIO en AAOS implican cambios en el nivel de implementación de HAL y por debajo del núcleo común de Android. El marco de Android se comunica con un HAL genérico independiente del hardware mediante los controladores VirtIO en el kernel de VM invitado AAOS, que se comunica con los dispositivos VirtIO en el lado del host mediante los protocolos VirtIO. Los dispositivos VirtIO en el lado del host pueden acceder al HW físico utilizando controladores de dispositivo específicos de SoC.

La comunicación entre el controlador y el dispositivo de VirtIO VirtIO tiene lugar con virtqueue , que son DMA-como búferes de anillo de dispersión se reúnen listas. Varios medios de transporte, tales como MMIO o PCI pueden ser usados para intercambiar los mensajes Virtio entre las máquinas virtuales.

En algunos casos, vsock ha sido aprovechado para la comunicación inter-VM. HAL vehículos, control de Audio, y Dumpstate comunicaciones están soportados mediante una conexión a un agente de pares en una máquina virtual independiente sobre un vsock interfaz. GRPC-vsock se utiliza para acceder a estos subsistemas no estandarizados. GRPC en el árbol de código fuente de Android ha sido modificado para que funcione con vsock con el formato de dirección de vsock:CID:PORT_NUMBER .

Arquitectura de virtualización
Arquitectura Figura 1. La virtualización

Gráficos

Cuando AAOS se ejecuta como una máquina virtual invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo a la GPU o al controlador de pantalla. En este caso, Mesa y una virtio-gpu conductor en el invitado VM Android y virtio-gpu dispositivo puede ser utilizado para acceder a la GPU.

En la VM invitada de Android, Mesa usa el marco Gallium3D para compilar sombreadores en la representación intermedia TGSI y traduce la API en objetos de estado. Gallium3D luego presenta objetos de estado recopilados y las llamadas de sorteo a Mesa Virgl, que luego se utiliza virtio-gpu como protocolo de transporte para enviar comandos y shaders a la VM Host.

En el lado de host, virglrenderer recibe virtio-gpu corriente de mando y convierte el flujo en comandos OpenGL ES. También traduce sombreadores del formato TGSI al formato GLSL y luego los reproduce sobre el controlador de GPU existente.

La plataforma de referencia AAOS trout actualmente compatible con OpenGL ES únicamente con el apoyo Vulkan, previsto en una versión futura.

Arquitectura gráfica
Arquitectura Figura 2. Gráficos

Sensores

Cuando AAOS se ejecuta como una máquina virtual invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo a los sensores. En este caso, el controlador Virtio-SCMI en la VM invitada de Android y el dispositivo VirtIO-SCMI en la VM host se utilizan para acceder a los sensores. La plataforma de referencia de virtualización AAOS proporciona un sensor HAL genérico e independiente de HW que se puede utilizar para que los SoC basados ​​en ARM accedan a los sensores.

Sensor HAL se comunica con el conductor IIO SCMI en el subsistema Linux Kernel IIO, que utiliza el protocolo de gestión de sensor SCMI proporcionada por la interfaz de control y gestión de sistema de brazo (SCMI) especificación para descubrir y sensores de configure, leer datos de los sensores, y ser notificado de sensor cambios de valor. El conductor IIO SCMI utiliza el controlador VirtIO SCMI, que utiliza el protocolo de transporte VirtIO como se especifica en la virtio-scmi especificación para intercambiar mensajes SCMI con el dispositivo VirtIO SCMI en el host VM. El dispositivo VirtIO SCMI tiene acceso directo a los sensores a través de controladores de sensor específicos de SoC.

Arquitectura del sensor
Arquitectura Figura 3. Sensor

Ubicación del sensor HAL

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

Configuración del sensor HAL

Es posible que el sensor HAL deba modificar los datos del sensor recibidos del Host VM 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 .

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 cualquiera /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>

Audio

En AAOS virtualizado, el Android virtual invitado puede utilizar virtio-snd al audio de acceso. virtio-snd ofrece los dispositivos PCM virtualizados a la máquina virtual de Android por lo que la aplicación HAL audio puede interactuar con los dispositivos de sonido virtuales con la biblioteca TinyALSA.

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

El control de audio HAL gestiona el enfoque de audio en AAOS. Por ejemplo, cuando el sistema está reproduciendo sonidos de emergencia, es posible que sea necesario silenciar la música de fondo. El control de audio HAL notificará a las aplicaciones que reproducen música que se silencien en esta situación. En el sistema virtualizado, los sonidos pueden provenir de otras VM. En la implementación de referencia, la AAOS virtual invitado tiene un servidor de control de audio demonio que se ejecuta, que utiliza GRPC-vsock para recibir las solicitudes de enfoque de audio de otras máquinas virtuales. El anfitrión VM puede utilizar device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller para enviar solicitudes de control de audio para AAOS. Mientras libandroid_audio_controller mantiene el foco de audio, se continuará enviando a los latidos del corazón de la AAOS hasta que se libere el foco.

Arquitectura de audio
Arquitectura Figura 4. Audio

Bluetooth

Cuando AAOS se ejecuta como una máquina virtual invitada junto con otros sistemas operativos automotrices, es posible que Android no tenga acceso directo al controlador Bluetooth. En este caso, el controlador VirtIO-Console en la VM invitada de Android y el dispositivo VirtIO-Console en la VM host se pueden usar para abrir un puerto COM virtual y enviar los paquetes HCI al controlador Bluetooth y recibir eventos. Este diseño permite que la pila Bluetooth de Android utilice un HAL de Bluetooth genérico y agnóstico de HW. La VM host puede manejar tareas específicas de HW, como la inicialización y la descarga de firmware del controlador Bluetooth.

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

Arquitectura bluetooth
Arquitectura Figura 5. Bluetooth

Vehículo HAL

La implementación de Vehicle HAL consta de dos componentes:

  • Cliente. Proporciona las API que usa Android en AAOS virtualizados.
  • Servidor. Se comunica directamente con el hardware, como buses de vehículos (o un emulador).

En la virtualización, el servidor VHAL se ejecuta en la máquina virtual host. El cliente Vhal y el servidor se comunican a través GRPC-vsock (para más información, ver device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Los OEM pueden utilizar un protocolo de transporte diferente a GRPC anulando las API de comunicación. Para ejemplos, véase device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Sistema de vista extendida

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

Modo garaje

Para obtener más información, consulte ¿Qué es el modo de garaje? .

Entrar y salir del modo Garaje se desencadena por AP_POWER_STATE_REQ propiedades enviados por la HAL del vehículo. En el modo de virtualización, el modo Garage se activa desde el lado del host. La máquina virtual host debe permanecer encendida para proporcionar dispositivos virtuales para la máquina virtual de Android, hasta que Android se apague. El servidor VHAL en la VM host envía la señal de apagado a la VM invitada AAOS. Al recibir la señal del cliente VHAL, la VM AAOS ingresa al modo Garage y comienza a enviar señales de latido para mantener activa la VM host.

Dumpstate

Al generar el informe de errores para AAOS virtualizados, es valioso incluir información de la máquina virtual del host para que los desarrolladores tengan una visión más completa del sistema. Para lograr esto, las trout de implementación implementos de referencia IDumpstateDevice HAL, que recoge la información Conexión VM a través GRPC-vsock . El anfitrión información VM tar-envasados se llama dumpstate_board.bin en el informe de error, mientras que los registros de dumping están en dumpstate_board.txt .

Para configurar los comandos a ejecutar:

  1. Copiar los datos de configuración del archivo a continuación en un archivo 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. Pase la ruta del nuevo archivo XML al servidor dumpstate al iniciar. Por ejemplo:
    --config_file my_config.xml
    

Otros subsistemas

VirtIO ya proporciona una interfaz bien definida para componentes como Block Storage, Network, Console, Input, Socket y Entropy. Para estos subsistemas, AAOS utiliza el controlador tal y como son, como virtio-blk , virtio-input , virtio-console , y virtio-net .

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