Arquitetura

A maioria das alterações necessárias para dar suporte ao VirtIO no AAOS envolve alterações no nível de implementação HAL e abaixo no Android Common Kernel. A estrutura do Android se comunica com um HAL genérico independente de hardware usando os drivers VirtIO no kernel da VM convidada AAOS, que se comunica com dispositivos VirtIO no lado do host usando protocolos VirtIO. Os dispositivos VirtIO no lado do host podem acessar o HW físico usando drivers de dispositivo específicos do SoC.

A comunicação entre o driver VirtIO e o dispositivo VirtIO ocorre com virtqueue , que são buffers de anel semelhantes a DMA de listas de coleta de dispersão. Vários transportes, como MMIO ou PCI , podem ser usados ​​para trocar as mensagens VirtIO entre VMs.

Em alguns casos, vsock foi aproveitado para comunicação entre VMs. As comunicações de HAL de veículo, controle de áudio e estado de despejo são suportadas usando uma conexão com um agente de mesmo nível em uma VM separada por meio de uma interface vsock . GRPC-vsock é usado para acessar esses subsistemas não padronizados. O GRPC na árvore de origem do Android foi modificado para funcionar com vsock com o formato de endereço de vsock:CID:PORT_NUMBER .

Arquitetura de virtualização
Figura 1. Arquitetura de virtualização

Áudio

No AAOS virtualizado, a VM convidada do Android pode usar virtio-snd para acessar o áudio. virtio-snd fornece os dispositivos PCM virtualizados para a VM Android para que a implementação de HAL de áudio possa interagir com os dispositivos de som virtualizados com a biblioteca TinyALSA.

A implementação de HAL de áudio padrão está localizada em AOSP em /device/google/trout/hal/audio/6.0 . Os OEMs podem modificar ro.vendor.trout.audiohal.{in,out}_period_{ms,count} para sua plataforma. Os OEMs também podem implementar seu próprio HAL de áudio substituindo as variáveis ​​relacionadas ao áudio em /device/google/trout/aosp_trout_common.mk.

O controle de áudio HAL gerencia o foco de áudio em AAOS. Por exemplo, quando o sistema está tocando sons de emergência, a música tocando em segundo plano pode precisar ser silenciada. O controle de áudio HAL notificará os aplicativos que estão tocando música para silenciar nesta situação. No sistema virtualizado, os sons podem vir de outras VMs. Na implementação de referência, a VM convidada AAOS tem um daemon de servidor de controle de áudio em execução, que usa GRPC-vsock para receber solicitações de foco de áudio de outras VMs. A VM do host pode usar device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller para enviar solicitações de controle de áudio para AAOS. Enquanto libandroid_audio_controller mantém o foco de áudio, ele continuará a enviar batimentos cardíacos para AAOS até que o foco seja liberado.

Arquitetura de áudio
Figura 5. Arquitetura de áudio

Bluetooth

A implementação do Bluetooth é baseada no design ilustrado abaixo.

Arquitetura Bluetooth
Figura 5. Arquitetura Bluetooth

Perfil mãos-livres Bluetooth

Para habilitar o Bluetooth Hands-Free Profile (HFP) em trout , a especificação do dispositivo de som VirtIO foi estendida para oferecer suporte a controles de áudio. Usando essa abordagem, um dispositivo de som VirtIO no lado do host/hipervisor fornece esses três controles de áudio relacionados ao HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Quando o AAOS é executado como uma VM convidada, o AAOS usa o TinyAlsa para definir esses controles de áudio. Para habilitar o caso de uso HFP, o host/hipervisor executa o roteamento e a calibração específicos do fornecedor de acordo.

A implementação do Bluetooth é baseada na ilustração de design abaixo.

Arquitetura Bluetooth
Figura 5. Arquitetura Bluetooth

Lixeira

Ao gerar o relatório de bug para AAOS virtualizado, é importante incluir informações da VM do host para que os desenvolvedores tenham uma visão mais abrangente do sistema. Para fazer isso, a implementação de referência de trout implementa o IDumpstateDevice HAL, que coleta as informações da VM do host por meio GRPC-vsock . As informações da VM do host do pacote `tar` são denominadas dumpstate_board.bin no relatório de bugs, enquanto os logs de despejo estão em dumpstate_board.txt .

Para configurar os comandos a serem executados:

  1. Copie os detalhes de configuração do arquivo abaixo em um arquivo XML, por exemplo, 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. Passe o caminho do novo arquivo XML para o servidor dumpstate ao iniciar. Por exemplo:
    --config_file my_config.xml
    

Sistema de visão estendida (EVS)

O Extended View System (EVS) é usado para exibir o vídeo capturado pelas câmeras de visão traseira e surround. No AAOS virtualizado, a pilha EVS pode acessar o fluxo de vídeo do dispositivo de streaming V4L2 virtualizado que usa o driver de vídeo VirtIO.

Modo garagem

Para obter mais informações, consulte O que é o Modo Garagem? .

Entrar e sair do modo Garage é acionado pelas propriedades AP_POWER_STATE_REQ enviadas pelo Vehicle HAL. No modo de virtualização, o modo Garage é acionado do lado do host. A VM host deve permanecer ligada para fornecer dispositivos virtuais para a VM Android, até que o Android seja desligado. O servidor VHAL na VM host envia o sinal de desligamento para a VM convidada AAOS. Ao receber o sinal do cliente VHAL, a VM AAOS entra no modo Garage e começa a enviar sinais de pulsação para manter a VM host ativa.

Sistema Global de Navegação por Satélite (GNSS)

Na trout 1.0, foi adicionado suporte para virtualização GNSS sobre virtio-console . A implementação suporta a troca de medidas brutas e correções de localização do host para o convidado.

O formato de troca de dados é o CSV usado pelo aplicativo GnssLogger. Na implementação de referência, como o driver GNSS nativo não está disponível, os dados simulados são disponibilizados, mas um driver nativo pode ser implementado sem nenhuma alteração do lado do convidado. Um agente de host simulado de amostra é fornecido como parte do código-fonte da trout .

A implementação atual espera que a inicialização do GNSS e o GNSS assistido (AGNSS) sejam manipulados pelo ambiente do sistema operacional host.

Arquitetura GNSS
Figura 2. Arquitetura GNSS

Gráficos

Quando o AAOS está sendo executado como uma VM convidada junto com outros sistemas operacionais automotivos, o Android pode não ter acesso direto à GPU ou ao controlador de exibição. Nesse caso, Mesa ou goldfish-opengl e um driver virtio-gpu na VM convidada do Android e no dispositivo virtio-gpu podem ser usados ​​para acessar a GPU.

Na VM convidada do Android, Mesa ou goldfish-opengl codifica comandos OpenGLES em um fluxo Gallium ou em um fluxo GLES gerado automaticamente, respectivamente. O driver do kernel virtio-gpu é usado como transporte. No lado do host, virglrenderer (para Mesa) e vulkan-cereal (para goldfish-opengl ) reproduzem o fluxo de comando decodificado no driver da GPU existente. A plataforma de referência AAOS trout suporta OpenGL ES apenas com suporte Vulkan, antecipado em uma versão futura.

Arquitetura gráfica
Figura 3. Arquitetura gráfica

Sensores

Quando o AAOS está sendo executado como uma VM convidada junto com outros sistemas operacionais automotivos, o Android pode não ter acesso direto aos sensores. Nesse caso, o driver Virtio-SCMI na VM convidada Android e o dispositivo VirtIO-SCMI na VM Host são usados ​​para acessar os sensores. A plataforma de referência de virtualização AAOS fornece um sensor HAL genérico e independente de HW que pode ser usado para SoCs baseados em ARM para acessar os sensores.

O sensor HAL se comunica com o driver IIO SCMI no subsistema Linux Kernel IIO, que usa o protocolo de gerenciamento de sensor SCMI fornecido pela especificação ARM System Control and Management Interface (SCMI) para descobrir e configurar sensores, ler dados do sensor e ser notificado sobre o sensor alterações de valor.

O driver SCMI IIO usa o driver SCMI VirtIO, que usa o protocolo de transporte VirtIO conforme especificado na especificação virtio-scmi para trocar mensagens SCMI com o dispositivo SCMI VirtIO na VM host. O dispositivo VirtIO SCMI tem acesso direto aos sensores por meio de drivers de sensor específicos do SoC.

Arquitetura do sensor
Figura 4. Arquitetura do sensor

Localização HAL do sensor

A implementação de referência do sensor HAL, que usa o VirtIO SCMI, está localizada em device/google/trout/hal/sensors .

Configuração do sensor HAL

O sensor HAL pode precisar modificar os dados do sensor recebidos da VM do host para cumprir com o sistema de coordenadas do sensor do carro Android. O esquema para configuração do sensor pode ser encontrado em device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd .

Os OEMs podem fornecer a configuração do sensor, como orientação e localização, em sensor_hal_configuration.xml e copiar o arquivo em /odm/etc/sensors/ ou /vendor/etc/sensors/ . Uma configuração de sensor de amostra é fornecida abaixo:

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

Veículo HAL

A implementação do Vehicle HAL consiste em dois componentes:

  • Cliente. Fornece APIs usadas pelo Android em AAOS virtualizado
  • Servidor. Comunica-se diretamente com o hardware, como ônibus de veículos (ou um emulador).

Na virtualização, o servidor VHAL é executado na VM host. O cliente e o servidor VHAL se comunicam por meio GRPC-vsock (para obter mais informações, consulte device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). Os OEMs podem usar um protocolo de transporte diferente do GRPC substituindo as APIs de comunicação. Para obter exemplos, consulte device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Outros subsistemas

O VirtIO já fornece uma interface bem definida para componentes como Block Storage, Network, Console, Input, Socket e Entropy. Para esses subsistemas, o AAOS usa o driver como está, como virtio-blk , virtio-input , virtio-console e virtio-net .

Na plataforma de referência AAOS virtualizada, o Wi-Fi é compatível com mac80211_hwsim para habilitar uma rede sem fio VirtWifi , que então usa o túnel virtio-net para enviar o tráfego de rede para a VM host, que tem acesso direto à rede Wi-Fi real.