Arquitetura

A maioria das mudanças necessárias para oferecer suporte ao VirtIO no AAOS envolve alterações na implementação da HAL e abaixo dela no kernel comum do Android. O framework do Android se comunica com uma HAL genérica independente de hardware usando os drivers VirtIO no kernel da VM convidada do 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 é usado para comunicação entre VMs. As comunicações HAL veicular (VHAL), controle de áudio e Dumpstate são compatíveis com uma conexão a um agente de mesmo nível em uma VM separada em uma interface vsock. O gRPC em vsock é usado para acessar esses subsistemas não padronizados. O gRPC na árvore de origem do Android é modificado para funcionar com vsock com o formato de endereço 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 do Android para que a implementação da HAL de áudio possa interagir com os dispositivos de som virtualizados com a biblioteca TinyALSA.

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

A HAL de controle de áudio gerencia a seleção de áudio no AAOS. Por exemplo, quando o sistema está reproduzindo sons de emergência, a música tocando em segundo plano pode precisar ser silenciada. A HAL de controle de áudio notifica esses apps que estão reproduzindo música para silenciar nessa situação. No sistema virtualizado, os sons podem vir de outras VMs. Na implementação de referência, a VM convidada do AAOS tem um daemon de servidor de controle de áudio em execução, que usa o gRPC em vsock para receber solicitações de seleção de áudio de outras VMs. A VM host pode usar device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller para enviar solicitações de controle de áudio ao AAOS. Enquanto libandroid_audio_controller mantém a seleção de áudio, ele continua enviando pulsações para o AAOS até que a seleção seja liberada.

Arquitetura de áudio

Figura 2. Arquitetura de áudio.

Bluetooth

A implementação do Bluetooth é ilustrada na figura a seguir:

Arquitetura Bluetooth

Figura 3. Arquitetura do Bluetooth.

Perfil viva-voz do Bluetooth

Para ativar o perfil viva-voz do Bluetooth (HFP, na sigla em inglês) no 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, ele usa o TinyALSA para definir esses controles de áudio. Para ativar o caso de uso do HFP, o host/hipervisor realiza o roteamento e a calibragem específicos do fornecedor.

A implementação do Bluetooth é baseada na ilustração de design a seguir:

Arquitetura Bluetooth

Figura 4. Arquitetura do Bluetooth.

Dumpstate

Ao gerar o relatório de bugs para o AAOS virtualizado, é importante incluir informações da VM host para que os desenvolvedores tenham uma visão mais abrangente do sistema. Para isso, a implementação de referência trout implementa a HAL IDumpstateDevice, que coleta as informações da VM host pelo gRPC em vsock. As informações da VM host empacotadas tar são nomeadas dumpstate_board.bin no relatório de bugs, enquanto os registros de despejo estão em dumpstate_board.txt.

Para configurar os comandos a serem executados:

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

Sistema de visualização estendida

O sistema de visualização estendida (EVS, na sigla em inglês) mostra o vídeo capturado pelas câmeras traseira e de visão panorâmica. No AAOS virtualizado, a pilha EVS pode acessar o fluxo de vídeo do dispositivo de streaming V4L2 virtualizado que usa o driver VirtIO-video.

Modo de garagem

A entrada e a saída do modo de garagem são acionadas pelas propriedades AP_POWER_STATE_REQ enviadas pela VHAL. No modo de virtualização, o modo de garagem é acionado pelo lado do host. A VM host precisa permanecer ligada para fornecer dispositivos virtuais para a VM do Android até que o Android seja desligado. O servidor VHAL na VM host envia o sinal de desligamento para a VM convidada do AAOS. Ao receber o cliente VHAL de sinal, a VM do AAOS entra no modo de garagem e começa a enviar sinais de pulsação para manter a VM host ativa. Para mais informações, consulte Modo de garagem.

Sistema global de navegação por satélite (GNSS)

No trout 1.0, o suporte para virtualização GNSS em virtio-console está incluído. A implementação oferece suporte à troca de medições brutas e correções de localização do host para o convidado.

O formato de troca de dados é o CSV usado pelo app GNSSLogger. Na implementação de referência, o driver GNSS nativo não está disponível, então os dados simulados estão disponíveis. É possível implementar um driver nativo sem fazer mudanças no lado do convidado. Um exemplo de agente host simulado é fornecido como parte do código-fonte trout.

A implementação espera que a inicialização do GNSS e o GNSS assistido (AGNSS) sejam processados pelo ambiente do SO host.

Arquitetura do GNSS

Figura 5. Arquitetura GNSS.

Gráficos

Quando o AAOS está em execução como uma VM convidada junto com outros sistemas operacionais automotivos, o Android pode não ter acesso direto à GPU ou ao controlador de tela. Nesse caso, é possível acessar a GPU usando Mesa ou goldfish-opengl e um driver virtio-gpu na VM convidada do Android e no dispositivo virtio-gpu.

Na VM convidada do Android, o Mesa ou goldfish-opengl codifica comandos OpenGLES em um fluxo de gálio ou em um fluxo GLES gerado automaticamente, respectivamente. O driver de kernel virtio-gpu é usado como um transporte. No lado do host, virglrenderer (para Mesa) e vulkan-cereal (para goldfish-opengl) reproduzem o fluxo de comandos decodificado na parte de cima do driver de GPU atual. A plataforma de referência trout do AAOS oferece suporte ao OpenGL ES apenas com suporte ao Vulkan, previsto para uma versão futura.

Arquitetura de gráficos

Figura 6. Arquitetura de gráficos.

Sensores

Quando o AAOS está em execução como uma VM convidada junto com outros sistemas operacionais automotivos, o Android pode não ter acesso direto aos sensores. Nesse caso, é possível acessar os sensores usando o driver Virtio-SCMI na VM convidada do Android e o dispositivo VirtIO-SCMI na VM host. A plataforma de referência de virtualização do AAOS fornece uma HAL de sensor genérica e independente de HW que pode ser usada para SoCs baseados em ARM para acessar os sensores.

A HAL do sensor se comunica com o driver IIO SCMI no subsistema IIO do kernel do Linux, que usa o protocolo de gerenciamento de sensor SCMI fornecido pela ARM System Control and Management Interface (SCMI) specification para descobrir e configurar sensores, ler dados de sensores e ser notificado sobre mudanças de valor do sensor.

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

Arquitetura de sensor

Figura 7. Arquitetura do sensor.

Localização da HAL do sensor

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

Configuração da HAL do sensor

A HAL do sensor pode precisar modificar os dados do sensor recebidos da VM host para obedecer ao sistema de coordenadas do sensor do carro Android. O esquema de 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 é fornecida no exemplo a seguir:

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

A implementação da HAL veicular (VHAL) consiste em dois componentes:

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

Na virtualização, o servidor VHAL é executado na VM host. O cliente e o servidor VHAL se comunicam pelo gRPC em vsock. Para 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 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 armazenamento em blocos, rede, console, entrada, soquete e entropia. 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 do AAOS virtualizado, o Wi-Fi é compatível com mac80211_hwsim para ativar uma rede sem fio VirtWifi, que 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.