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

Arquitectura

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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 en el kernel común de Android. El marco de trabajo de Android se comunica con una HAL genérica independiente del hardware mediante los controladores VirtIO en el kernel de la máquina virtual invitada de 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 dispositivos específicos de SoC.

La comunicación entre el controlador VirtIO y el dispositivo VirtIO se lleva a cabo con virtqueue , que son búferes de anillo similares a DMA de listas de recopilación dispersa. Se pueden usar varios transportes, como MMIO o PCI , para intercambiar los mensajes de VirtIO entre máquinas virtuales.

En algunos casos, vsock se ha aprovechado para la comunicación entre máquinas virtuales. Las comunicaciones HAL del vehículo, Control de audio y Dumpstate se admiten mediante una conexión a un agente del mismo nivel en una VM separada a través de una interfaz vsock . GRPC-vsock se utiliza para acceder a estos subsistemas no estandarizados. GRPC en el árbol de fuentes de Android se ha modificado para que funcione 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 de HAL de audio predeterminada 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.

El control de audio HAL gestiona el foco 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 aquellas aplicaciones que reproduzcan música para silenciarlas en esta situación. En el sistema virtualizado, los sonidos pueden provenir de otras máquinas virtuales. En la implementación de referencia, la máquina virtual invitada de AAOS tiene un demonio de servidor de control de audio en ejecución, que usa GRPC-vsock para recibir solicitudes de enfoque de audio de otras máquinas virtuales. La máquina virtual 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, continuará enviando latidos a AAOS hasta que se libere el foco.

Arquitectura de sonido
Figura 5. Arquitectura de audio

Bluetooth

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

arquitectura Bluetooth
Figura 5. Arquitectura Bluetooth

Perfil manos libres Bluetooth

Para habilitar el perfil de manos libres Bluetooth (HFP) en trout , la especificación del dispositivo de sonido VirtIO se ha ampliado para admitir controles de audio. Usando este enfoque, un dispositivo de sonido VirtIO en el lado del host/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/hipervisor realiza el enrutamiento y la calibración específicos del proveedor en consecuencia.

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

arquitectura Bluetooth
Figura 5. Arquitectura Bluetooth

basurero

Al generar el informe de errores para AAOS virtualizado, es valioso incluir información de la máquina virtual host para que los desarrolladores tengan una visión más completa del sistema. Para lograr esto, la implementación de referencia de trout implementa IDumpstateDevice HAL, que recopila la información de la máquina virtual host a través GRPC-vsock . La información de la VM del 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 a ejecutar:

  1. Copie los detalles 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 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 videos capturados por las cámaras de visión trasera y de visión envolvente. En AAOS virtualizado, la pila EVS puede acceder a la transmisión de video desde el dispositivo de transmisión V4L2 virtualizado 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 activa mediante las propiedades AP_POWER_STATE_REQ enviadas por el HAL del vehículo. En el modo de virtualización, el modo Garaje se activa desde el lado del host. La VM del host debe permanecer encendida para proporcionar dispositivos virtuales para la VM de Android, hasta que se apague Android. El servidor VHAL en la máquina virtual host envía la señal de apagado a la máquina virtual invitada de AAOS. Al recibir la señal del cliente VHAL, la VM de AAOS ingresa al modo de garaje y comienza a enviar señales de latido para mantener activa la VM del host.

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

En trout 1.0, se agregó soporte para virtualización GNSS sobre virtio-console . La implementación admite el intercambio de medidas sin procesar y arreglos de ubicación del anfitrión al invitado.

El formato de intercambio de datos es el CSV utilizado por la aplicación GnssLogger. En la implementación de referencia, debido a que el controlador GNSS nativo no está disponible, los datos simulados están disponibles, pero se puede implementar un controlador nativo sin cambios en el lado invitado. Se proporciona un agente host simulado de muestra como parte del código fuente de la trout .

La implementación actual espera que la inicialización de GNSS y el GNSS asistido (AGNSS) sean manejados por el entorno del sistema operativo del host.

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

En la máquina virtual invitada de Android, Mesa o goldfish-opengl codifican los comandos de OpenGLES en una secuencia de Gallium o en una secuencia de GLES generada automáticamente, respectivamente. El controlador del núcleo virtio-gpu se utiliza como transporte. En el lado del host, virglrenderer (para Mesa) y vulkan-cereal (para goldfish-opengl ) reproducen el flujo de comandos decodificado sobre el controlador GPU existente. La trout de la plataforma de referencia de AAOS es compatible con OpenGL ES solo con soporte Vulkan, anticipado en una versión futura.

Arquitectura gráfica
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, 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 de AAOS proporciona una HAL de sensor genérica e independiente del HW que se puede usar para que los SoC basados ​​en ARM accedan a los sensores.

El sensor HAL se comunica con el controlador IIO SCMI en el subsistema Linux Kernel IIO, que utiliza el protocolo de administración de sensores SCMI proporcionado por la especificación ARM System Control and Management Interface (SCMI) para descubrir y configurar sensores, leer datos de sensores y recibir notificaciones de sensores. cambios de valor.

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 máquina virtual host. El dispositivo VirtIO SCMI tiene acceso directo a los sensores a través de controladores de sensor específicos de SoC.

Arquitectura de sensores
Figura 4. Arquitectura del sensor

Ubicación HAL del sensor

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

Configuración HAL del sensor

Es posible que el HAL del sensor deba modificar los datos del sensor recibidos de la máquina virtual 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/ . 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 del vehículo

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

  • Cliente. Proporciona las API utilizadas por Android en AAOS virtualizado
  • 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 y el servidor VHAL se comunican a través GRPC-vsock (para obtener más información, consulte device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Los OEM pueden usar un protocolo de transporte diferente al de GRPC anulando las API de comunicación. Para ver ejemplos, consulte device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Otros subsistemas

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

En la plataforma de referencia AAOS virtualizada, Wi-Fi es compatible 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 máquina virtual host, que tiene acceso directo a la red Wi-Fi real.