A maioria das mudanças necessárias para oferecer suporte ao VirtIO no AAOS envolve mudanças na HAL. nível de implementação e abaixo no kernel comum do Android. O framework do Android se comunica com uma HAL genérica independente de hardware usando os drivers VirtIO no convidado AAOS O kernel da VM, que se comunica com os 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 anéis do tipo DMA de listas de coleta de dispersão.
Vários transportes, como
MMIO (em inglês)
ou
PCI (link em inglês)
para trocar mensagens VirtIO entre VMs.
Em alguns casos, o vsock foi usado para comunicação entre VMs.
As comunicações HAL, controle de áudio e Dumpstate do veículo são compatíveis com o uso de uma conexão
para um agente de peering em uma VM separada usando uma interface vsock.
GRPC-vsock é usado para acessar esses subsistemas não padronizados.
GRPC (em inglês)
na árvore de origem do Android foi modificado para funcionar com vsock com o endereço
de vsock:CID:PORT_NUMBER.
Áudio
No AAOS virtualizado, a VM convidada do Android pode usar o virtio-snd para acessar o áudio.
virtio-snd fornece os dispositivos PCM virtualizados à VM do Android para que o
implementação de HAL de áudio pode interagir com dispositivos de som virtualizados usando o
TinyALSA.
A implementação padrão da HAL de áudio está localizada no AOSP em
/device/google/trout/hal/audio/6.0: OEMs podem modificar
ro.vendor.trout.audiohal.{in,out}_period_{ms,count} na plataforma. OEMs podem
também implementam a própria HAL de áudio substituindo as variáveis relacionadas ao áudio
/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, pode ser necessário desativar o som de música em segundo plano. A HAL de controle de áudio
notifica os apps que estão reproduzindo 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 de convidado do AAOS
tem um daemon do servidor de controle de áudio em execução, que usa GRPC-vsock para receber;
solicitações de seleção 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 ao AAOS. Enquanto libandroid_audio_controller mantém
a seleção de áudio, ele continua enviando batimentos para o AAOS até que o foco seja liberado.
Bluetooth
A implementação do Bluetooth é baseada no design ilustrado abaixo.
Perfil Bluetooth Viva-voz
Para ativar o perfil de viva-voz (HFP, na sigla em inglês) Bluetooth no trout, o dispositivo de som VirtIO
foi estendida para oferecer suporte a controles de áudio. Com essa abordagem, um som VirtIO
dispositivo no lado do host/hipervisor fornece estes três controles de áudio relacionados ao HFP:
hfp_enablehfp_set_sampling_ratehfp_volume
Quando o AAOS é executado como uma VM convidada, o AAOS usa o TinyAlsa para definir esses controles de áudio. Para ativar o HFP caso de uso, o host/hipervisor realiza o roteamento e a calibração específicos do fornecedor de acordo.
A implementação do Bluetooth é baseada na ilustração de design abaixo.
Dumpstate
Ao gerar o relatório do bug 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 conseguir isso, a
A implementação de referência trout implementa a HAL IDumpstateDevice, que
coleta as informações da VM do host pelo GRPC-vsock. A VM do host empacotada "tar"
informação é denominada dumpstate_board.bin no relatório do bug, 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 dumpstate ao iniciar. Por exemplo:
--config_file my_config.xml
Sistema de visualização estendida (EVS)
O Extended View System (EVS) é usado para exibir vídeos capturados pelos recursos de câmera traseira e e câmeras com visão surround. No AAOS virtualizado, a pilha EVS pode acessar o stream de vídeo da o dispositivo de streaming V4L2 virtualizado que usa o driver VirtIO-video.
Modo garagem
Para mais informações, consulte Modo garagem.
Entrar e sair do modo garagem são acionadas por AP_POWER_STATE_REQ propriedades
pela HAL do veículo. No modo de virtualização, o modo garagem é acionado no lado do host.
A VM do host deve permanecer ligada para fornecer dispositivos virtuais para a VM Android, até que o Android seja
desligados. O servidor VHAL na VM do host envia o sinal de encerramento para a VM convidada do AAOS.
Ao receber o sinal do cliente VHAL, a VM do AAOS entra no modo "garagem" e começa a enviar o sinal de funcionamento.
para manter a VM do host ativa.
Sistema Global de Navegação por Satélite (GNSS, na sigla em inglês)
No trout 1.0, o suporte à virtualização GNSS por virtio-console foi
foi adicionado. A implementação suporta a troca de medidas brutas e correções de localização de
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
podem ser implementados sem alterações do lado do convidado. Um exemplo de agente host simulado é fornecido como parte do
código-fonte trout.
A implementação atual espera que a inicialização do GNSS e o GNSS assistido (AGNSS) sejam gerenciados pelo ambiente do SO do host.
Gráficos
Quando o AAOS é executado como uma VM convidada junto com outros sistemas operacionais automotivos, o Android pode não
têm acesso direto à GPU ou ao controlador de tela. Nesse caso,
Mesa ou
goldfish-opengl
e um driver virtio-gpu na VM de convidado Android e no dispositivo virtio-gpu
podem ser usadas para acessar a GPU.
Na VM convidada do Android, o Mesa ou goldfish-opengl codifica os comandos do OpenGLES
em um fluxo Gallium ou em um fluxo GLES gerado automaticamente, respectivamente. O virtio-gpu
é usado como transporte. No lado do host, virglrenderer (para Mesa) e
vulkan-cereal (para goldfish-opengl) repete o fluxo de comando decodificado em
parte superior do driver da GPU existente. A plataforma de referência AAOS trout oferece suporte ao OpenGL ES
somente com suporte para Vulkan, previsto em uma versão futura.
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 A 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 fornece uma HAL de sensor genérica e independente de HW que pode ser usada para SoCs baseados em ARM acessarem os sensores.
A HAL do sensor se comunica com o driver IIO SCMI no subsistema IIO do kernel Linux. que usa o SCMI Sensor Management Protocol fornecido pelo ARM Interface de Gerenciamento e Controle do Sistema (SCMI) para descobrir e configurar sensores, ler dados do sensor e ser notificado sobre as mudanças de valor.
O driver IIO SCMI usa o driver VirtIO SCMI, que usa o transporte VirtIO
conforme especificado nos
virtio-scmi
para trocar mensagens SCMI com o dispositivo VirtIO SCMI na VM do host. O VirtIO
O dispositivo SCMI tem acesso direto aos sensores por drivers de sensor específicos de SoC.
Localização da 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 da HAL do sensor
A HAL do sensor pode precisar modificar os dados do sensor recebidos da VM do host para cumprir
Sistema de coordenadas do sensor do carro Android. O esquema para a configuração do sensor pode ser encontrado em
device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd:
OEMs podem fornecer configuração de sensor, como orientação e localização, em
sensor_hal_configuration.xml e copie o arquivo
/odm/etc/sensors/ ou /vendor/etc/sensors/.
Confira abaixo um exemplo de configuração de 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 da HAL para veículos consiste em dois componentes:
- Cliente: Fornece APIs usadas pelo Android em AAOS virtualizado
- Servidor. Comunica-se diretamente com o hardware, como ônibus em veículos (ou um emulador).
Na virtualização, o servidor VHAL é executado na VM do host. O cliente e o servidor da VHAL se comunicam
até GRPC-vsock (para mais informações, consulte
device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto). OEMs podem usar uma
protocolo de transporte diferente do GRPC por meio da substituição das APIs de comunicação. Por exemplo,
consulte device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp.
Outros subsistemas
O VirtIO já tem uma interface bem definida para componentes como armazenamento em blocos,
rede, console, entrada, soquete e entropia. Para esses subsistemas, o AAOS usa
o motorista no estado em que se encontra, por exemplo, virtio-blk, virtio-input,
virtio-console e virtio-net.
Na plataforma de referência virtualizada AAOS, a rede mac80211_hwsim oferece suporte ao Wi-Fi
para ativar uma rede sem fio VirtWifi, que depois usa o túnel virtio-net
para enviar o tráfego de rede para a VM do host, que tem acesso direto à rede Wi-Fi real.