A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.

Esta página foi traduzida pela API Cloud Translation.

Arquitetura
Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

A maioria das mudanças necessárias para oferecer suporte ao VirtIO no AAOS envolve alterações no nível de implementação do HAL e abaixo no kernel comum do Android. O framework do Android se comunica com um HAL genérico independente de hardware usando os drivers VirtIO no kernel da VM guest 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 hardware 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, o vsock foi usado para comunicação entre VMs. O HAL do veículo, o controle de áudio e as comunicações de dumpstate têm suporte usando uma conexão a um agente peer em uma VM separada por uma interface vsock. O 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 vsock:CID:PORT_NUMBER.

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

Áudio

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

A implementação padrão do 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 o foco de áudio no AAOS. Por exemplo, quando o sistema está tocando sons de emergência, pode ser necessário silenciar a música que está tocando em segundo plano. O HAL de controle de áudio notifica os apps que estão tocando música para desativar o som nessa situação. No sistema virtualizado, os sons podem vir de outras VMs. Na implementação de referência, a VM do cliente 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 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 o foco de áudio, ele continua enviando batimentos cardíacos para o AAOS até que o foco seja liberado.

Bluetooth

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

Perfil de viva-voz Bluetooth

Para ativar o perfil viva-voz (HFP) do Bluetooth no trout, a especificação do dispositivo de som VirtIO foi ampliada para oferecer suporte a controles de áudio. Usando essa abordagem, um dispositivo de som VirtIO no lado do host/hipervisor fornece estes três controles de áudio relacionados ao HFP:

hfp_enable
hfp_set_sampling_rate
hfp_volume

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

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

Dumpstate

Ao gerar o bugreport para o 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 trout implementa o HAL IDumpstateDevice, que coleciona as informações da VM do host usando GRPC-vsock. As informações da VM do host empacotadas com "tar" são nomeadas como dumpstate_board.bin no bugreport, enquanto os registros de despejo estão em dumpstate_board.txt.

Para configurar os comandos a serem executados:

Copie os detalhes de configuração do arquivo abaixo 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>

Transmita o caminho do novo arquivo XML para o servidor de dumpstate ao iniciar. Exemplo:
```
--config_file my_config.xml
```

Sistema de visualização estendida (EVS)

O sistema de visualização estendida (EVS, na sigla em inglês) é usado para mostrar o vídeo capturado pelas câmeras de visão traseira e de visão periférica. 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 mais informações, consulte Modo garagem.

A entrada e a saída do modo Garagem são acionadas pelas propriedades AP_POWER_STATE_REQ enviadas pelo HAL do veículo. No modo de virtualização, o modo Garage é acionado pelo host. A VM host precisa permanecer ativa 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 convida do AAOS. Ao receber o cliente VHAL de sinal, a VM do AAOS entra no modo Garage e começa a enviar sinais de batimento para manter a VM host ativa.

Sistema global de navegação por satélite (GNSS, na sigla em inglês)

Na trout 1.0, foi adicionado suporte à virtualização do GNSS por virtio-console. A implementação oferece suporte à 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 app GnssLogger. Na implementação de referência, como o driver GNSS nativo não está disponível, dados simulados são disponibilizados, mas um driver nativo pode ser implementado sem nenhuma mudança no lado do visitante. Um agente de simulação de host de exemplo é fornecido como parte do código-fonte trout.

A implementação atual espera que a inicialização do GNSS e o GNSS assistido (AGNSS, na sigla em inglês) sejam processados pelo ambiente do SO do host.

Gráficos

Quando o AAOS está sendo executado como uma VM de convidado 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 do convidado Android e no dispositivo virtio-gpu podem ser usados para acessar a GPU.

Na VM do convidado do Android, o Mesa ou goldfish-opengl codifica comandos OpenGLES em um stream do Gallium ou em um stream GLES gerado automaticamente, respectivamente. O driver do kernel virtio-gpu é usado como um transporte. No lado do host, virglrenderer (para Mesa) e vulkan-cereal (para goldfish-opengl) repetem o fluxo de comando decodificado sobre o driver da GPU atual. A plataforma de referência AAOS trout oferece suporte somente ao OpenGL ES com suporte ao Vulkan, previsto em uma versão futura.

Sensores

Quando o AAOS está sendo executado como uma VM de convidado com outros sistemas operacionais automotivos, o Android pode não ter acesso direto aos sensores. Nesse caso, o driver Virtio-SCMI na VM convidada do Android e o dispositivo VirtIO-SCMI na VM do host são usados para acessar os sensores. A plataforma de referência de virtualização AAOS oferece uma HAL de sensores genérica e independente de hardware que pode ser usada para SoCs baseados em ARM para acessar os sensores.

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

O driver IIO SCMI usa o driver VirtIO SCMI, que usa o protocolo de transporte VirtIO conforme especificado 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 sensores específicos do SoC.

Localização do 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 do HAL de sensores

O Sensor HAL pode precisar modificar os dados do sensor recebidos da VM do 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/. Confira abaixo um exemplo de configuração do sensor:

<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 do HAL do veículo consiste em dois componentes:

Client. Fornece APIs usadas pelo Android em um AAOS virtualizado
Servidor. Se comunica diretamente com o hardware, como os ônibus do veículo (ou um emulador).

Na virtualização, o servidor VHAL é executado na VM host. O cliente e o servidor do VHAL se comunicam por 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. Para conferir 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 bloco, 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 AAOS virtualizada, o Wi-Fi tem suporte a mac80211_hwsim para ativar uma rede sem fio VirtWifi, que usa o túnel virtio-net para enviar o tráfego de rede à VM host, que tem acesso direto à rede Wi-Fi real.

Arquitetura Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.