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 framework de Android se comunica con un HAL genérico independiente del hardware a través de los controladores VirtIO en el kernel de la VM invitado de AAOS, que se comunica con los dispositivos VirtIO en el lado del host a través de protocolos VirtIO. Los dispositivos VirtIO del 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 recopilación de dispersión.
Se pueden usar varios transportes, como MMIO o PCI, para intercambiar los mensajes de VirtIO entre las VMs.
En algunos casos, se aprovechó vsock para la comunicación entre VMs.
Las comunicaciones de HAL del vehículo, el control de audio y Dumpstate son compatibles con una conexión a un agente de pares en una VM independiente a través de una interfaz vsock.
GRPC-vsock se usa para acceder a estos subsistemas no estandarizados.
gRPC en el árbol de fuentes de Android se modificó para funcionar con vsock con el formato de dirección de vsock:CID:PORT_NUMBER.
Audio
En el AAOS virtualizado, la VM de invitado 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 OEMs pueden modificar ro.vendor.trout.audiohal.{in,out}_period_{ms,count} para su plataforma. Los OEMs 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 HAL de control de audio administra el foco de audio en AAOS. Por ejemplo, cuando el sistema reproduce sonidos de emergencia, es posible que debas silenciar la música que se reproduce en segundo plano. El 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 enfoque 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 mensajes de estado a AAOS hasta que se libera el foco.
Bluetooth
La implementación de Bluetooth se basa en el diseño que se muestra a continuación.
Perfil 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 hipervisor proporciona estos tres controles de audio relacionados con el HFP:
hfp_enablehfp_set_sampling_ratehfp_volume
Cuando AAOS se ejecuta como una VM de invitado, usa TinyAlsa para configurar estos controles de audio. Para habilitar el caso de uso de HFP, el host o 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.
Dumpstate
Cuando se genera el informe de errores para el AAOS virtualizado, es útil incluir información de la VM del host para que los desarrolladores tengan una vista más completa del sistema. Para lograrlo, la implementación de referencia de trout implementa el HAL de IDumpstateDevice, que recopila la información de la VM host a través de GRPC-vsock. La información de la VM del host empaquetada en "tar" se llama 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:
- 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> - Pasa la ruta de acceso del nuevo archivo en formato XML al servidor de dumpstate durante el inicio. 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 posterior y envolvente. En el 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 de video VirtIO.
Modo cochera
Para obtener más información, consulta Modo de garaje.
Las propiedades AP_POWER_STATE_REQ que envía el sistema HAL del vehículo activan el ingreso y la salida del modo de cochera. En el modo de virtualización, el modo Garage se activa desde el host.
La VM host debe permanecer encendida para proporcionar dispositivos virtuales para la VM de Android, hasta que Android se apague. El servidor VHAL en la VM host envía la señal de cierre a la VM invitada de AAOS.
Cuando recibe el cliente de VHAL de señal, la VM de AAOS entra en modo Garage y comienza a enviar señales de verificación para mantener activa la VM del host.
Sistema global de navegación satelital (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 de GnssLogger. En la implementación de referencia, como el controlador GNSS nativo no está disponible, se ponen a disposición datos simulados, pero se puede implementar un controlador nativo sin ningún cambio del lado del invitado. Se proporciona un agente de host simulado de muestra como parte del código fuente de trout.
La implementación actual espera que el entorno del SO host controle la inicialización del GNSS y el GNSS asistido (AGNSS).
Gráficos
Cuando AAOS se ejecuta como una VM de invitado junto con otros sistemas operativos para la industria automotriz, es posible que Android no tenga acceso directo a la GPU ni al controlador de pantalla. En este caso, se puede usar Mesa o goldfish-opengl y un controlador virtio-gpu en la VM huésped de Android y el dispositivo virtio-gpu para acceder a la GPU.
En la VM huésped de Android, Mesa o goldfish-opengl codifican los comandos de OpenGLES en un flujo de Gallium o en un flujo de GLES generado automáticamente, respectivamente. El controlador de kernel virtio-gpu se usa como transporte. En el lado del host, virglrenderer (para Mesa) y vulkan-cereal (para goldfish-opengl) vuelven a reproducir el flujo de comandos decodificado sobre el controlador de GPU existente. La plataforma de referencia de AAOS trout solo es compatible con OpenGL ES con compatibilidad con Vulkan, que se lanzará en una versión futura.
Sensores
Cuando AAOS se ejecuta como una VM invitada junto con otros sistemas operativos para vehículos, es posible que Android no tenga acceso directo a los sensores. En este caso, se usa 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 sensores genérica y ajena al hardware que se puede usar para que los SoC basados en ARM accedan a los sensores.
El sistema HAL del sensor se comunica con el controlador SCMI de IIO en el subsistema IIO del kernel de Linux, que usa el protocolo de administración de sensores SCMI que proporciona la especificación de la interfaz de administración y control del sistema (SCMI) de ARM para descubrir y configurar sensores, leer datos de sensores y recibir notificaciones sobre cambios en los valores de los sensores.
El controlador SCMI de IIO usa el controlador SCMI de VirtIO, que usa el protocolo de transporte VirtIO como se especifica en la especificación virtio-scmi para intercambiar mensajes SCMI con el dispositivo SCMI de VirtIO en la VM host. El dispositivo SMI de VirtIO tiene acceso directo a los sensores a través de controladores de sensores específicos del SoC.
Ubicación del HAL del sensor
La implementación de referencia de la HAL del sensor, que usa VirtIO SCMI, se encuentra en device/google/trout/hal/sensors.
Configuración del HAL de sensores
Es posible que el sistema HAL del sensor deba modificar los datos del sensor recibidos de la VM del host para cumplir con el sistema de coordenadas del sensor de automóviles Android. El esquema de configuración del sensor se puede encontrar en device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd.
Los OEMs 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ículos consta de dos componentes:
- Cliente. Proporciona las APIs que usa Android en el AAOS virtualizado
- Servidor. Se comunica directamente con el hardware, como los buses de vehículos (o un emulador).
En la virtualización, el servidor VHAL se ejecuta en la VM host. El cliente y el servidor de 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 OEMs pueden anular las APIs de comunicación para usar un protocolo de transporte diferente de GRPC. Para ver 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 en 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 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 VM host, que tiene acceso directo a la red Wi-Fi real.