O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Arquitetura

A maioria das mudanças necessárias para dar suporte ao VirtIO em AAOS envolve mudanças no nível de implementação HAL e abaixo no Android Common Kernel. A estrutura do Android se comunica com um HAL agnóstico de hardware genérico usando os drivers VirtIO no kernel VM convidado 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 motorista virtio eo dispositivo virtio ocorre com virtqueue , que são DMA-como buffers anel de dispersão reunir listas. Vários transportes, tais como MMIO ou PCI pode ser usado para trocar mensagens virtio entre VMs.

Em alguns casos, vsock foi aproveitado para a comunicação inter-VM. Veículo HAL, Controlo de áudio, e dumpstate comunicações são suportados usando uma conexão com um agente de pares em um VM separado sobre uma vsock interface. GRPC-vsock é usado para acessar esses subsistemas não-padronizados. GRPC na árvore fonte do Android foi modificado para trabalhar com vsock com o formato de endereço do vsock:CID:PORT_NUMBER .

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

Gráficos

Quando o AAOS está sendo executado como uma VM convidada ao lado de outros sistemas operacionais automotivos, o Android pode não ter acesso direto à GPU ou ao controlador de vídeo. Neste caso, Mesa e uma virtio-gpu motorista no convidado Android VM e virtio-gpu dispositivo pode ser usado para acessar a GPU.

Na VM convidada do Android, o Mesa usa a estrutura Gallium3D para compilar sombreadores para representação intermediária TGSI e converte API em objetos de estado. Gallium3D em seguida, envia objetos estado compilado e as chamadas sorteio para Mesa Virgl, que então usa virtio-gpu como um protocolo de transporte para enviar comandos e shaders para o host VM.

No lado do alojamento, virglrenderer recebe o virtio-gpu corrente de comando e converte o fluxo em comandos OpenGL ES. Ele também converte sombreadores do formato TGSI para o formato GLSL e os reproduz no driver de GPU existente.

A plataforma de referência AAOS trout actualmente suporta OpenGL ES apenas com suporte Vulkan, previsto numa versão futura.

Arquitetura gráfica
Arquitetura Figura 2. Gráficos

Sensores

Quando o AAOS está sendo executado como uma VM convidada ao lado de outros sistemas operacionais automotivos, o Android pode não ter acesso direto aos sensores. Neste caso, o driver Virtio-SCMI na VM guest 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 HAL de sensor genérico e agnóstico de HW que pode ser usado para SoCs baseados em ARM para acessar os sensores.

Sensor HAL comunica com o condutor IIO SCMI no subsistema Linux Kernel IIO, que usa o protocolo de gestão de SCMI Sensor fornecido pela ARM Sistema de Controlo e Gestão de Interface (SCMI) especificação para descobrir e sensores do configure, leia os dados do sensor, e ser notificado de sensor de mudanças de valor. O controlador IIO SCMI utiliza o controlador virtio SCMI, que utiliza o protocolo de transporte virtio como especificado na virtio-scmi especificação para trocar mensagens com o dispositivo SCMI virtio SCMI no hospedeiro VM. O dispositivo VirtIO SCMI tem acesso direto aos sensores por meio de drivers de sensor específicos de SoC.

Arquitetura do sensor
Arquitetura Figura 3. Sensor

Localização HAL do sensor

A implementação de referência do sensor de HAL, o qual utiliza virtio SCMI, está localizado no device/google/trout/hal/sensors .

Configuração HAL do sensor

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

OEM pode fornecer configuração do sensor, tais como a orientação e localização, em sensor_hal_configuration.xml e copiar o ficheiro em qualquer /odm/etc/sensors/ ou /vendor/etc/sensors/ . Um exemplo de configuração do sensor é fornecido 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>

Áudio

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

A implementação HAL áudio padrão está localizado na AOSP em /device/google/trout/hal/audio/6.0 . OEMs podem modificar ro.vendor.trout.audiohal.{in,out}_period_{ms,count} para a sua plataforma. OEMs também pode implementar seu próprio HAL áudio, substituindo as variáveis de áudio-relacionados 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á reproduzindo sons de emergência, a música de fundo pode precisar ser silenciada. O HAL de controle de áudio notificará os aplicativos que reproduzem música para silenciar nesta situação. No sistema virtualizado, os sons podem vir de outras VMs. Na implementação de referência, o AAOS convidado VM tem um servidor de controle de áudio daemon rodando, que usa GRPC-vsock para receber solicitações de foco de áudio de outras VMs. O host VM 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 vai continuar a enviar batimentos cardíacos para AAOS até que o foco é liberado.

Arquitetura de áudio
Arquitetura Figura 4. Áudio

Bluetooth

Quando o AAOS é executado como uma VM convidada ao lado de outros sistemas operacionais automotivos, o Android pode não ter acesso direto ao controlador Bluetooth. Nesse caso, o driver VirtIO-Console na VM guest Android e o dispositivo VirtIO-Console na VM host podem ser usados ​​para abrir uma porta COM virtual e enviar os pacotes HCI para o controlador Bluetooth e receber eventos. Esse design permite que um HAL Bluetooth genérico e independente de HW seja usado pela pilha de Bluetooth do Android. A VM host pode lidar com tarefas específicas de HW, como inicialização e download de firmware do controlador Bluetooth.

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

Arquitetura bluetooth
Figura 5. arquitectura Bluetooth

HAL do veículo

A implementação do HAL do veículo 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 VHAL e servidor comunicar através GRPC-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. Por exemplo, veja device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Sistema de visão estendida

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

Modo garagem

Para mais informações, consulte O que é o Modo de garagem? .

Entrar e sair do modo de Garagem é desencadeada por AP_POWER_STATE_REQ propriedades enviadas pelo HAL veículo. No modo de virtualização, o modo Garagem é acionado do lado do host. A VM host deve permanecer ligada para fornecer dispositivos virtuais para Android VM, até que o Android seja desligado. O servidor VHAL no host VM envia o sinal de desligamento para o convidado AAOS VM. Ao receber o sinal do cliente VHAL, o AAOS VM entra no modo Garagem e começa a enviar sinais de pulsação para manter o VM host ativo.

Dumpstate

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 conseguir isso, as trout implementos implementação de referência IDumpstateDevice HAL, que recolhe o anfitrião informações VM através GRPC-vsock . O anfitrião informações VM embalados-tar é nomeado dumpstate_board.bin na bugreport enquanto registros de dumping estão em dumpstate_board.txt .

Para configurar os comandos a serem executados:

  1. Copiar 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
    

Outros subsistemas

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

Na plataforma de referência AAOS virtualizado, Wi-Fi é suportada com mac80211_hwsim para permitir que um VirtWifi rede sem fio, que, em seguida, usa virtio-net túnel para enviar o tráfego de rede para o host VM, que tem acesso directo à rede real Wi-Fi.