Архитектура

Большинство изменений, необходимых для поддержки VirtIO в AAOS, связаны с изменениями на уровне реализации HAL и ниже в общем ядре Android. Платформа Android взаимодействует с универсальным аппаратно-независимым HAL с помощью драйверов VirtIO в ядре гостевой виртуальной машины AAOS, которое взаимодействует с устройствами VirtIO на стороне хоста с использованием протоколов VirtIO. Устройства VirtIO на стороне хоста могут получить доступ к физическому аппаратному обеспечению с помощью драйверов устройств, специфичных для SoC.

Связь между драйвером VirtIO и устройством VirtIO осуществляется с помощью virtqueue , которые представляют собой кольцевые буферы списков сбора и разброса, подобные DMA. Для обмена сообщениями VirtIO между виртуальными машинами можно использовать несколько транспортных протоколов, таких как MMIO или PCI .

В некоторых случаях vsock используется для связи между виртуальными машинами. Связь транспортного средства HAL, Audio Control и Dumpstate поддерживается с помощью подключения к одноранговому агенту на отдельной виртуальной машине через интерфейс vsock . GRPC-vsock используется для доступа к этим нестандартным подсистемам. GRPC в дереве исходного кода Android был изменен для работы с vsock с форматом адреса vsock:CID:PORT_NUMBER .

Архитектура виртуализации
Рисунок 1. Архитектура виртуализации

Аудио

В виртуализированной AAOS гостевая виртуальная машина Android может использовать virtio-snd для доступа к аудио. virtio-snd предоставляет виртуализированные устройства PCM виртуальной машине Android, чтобы реализация аудио HAL могла взаимодействовать с виртуализированными звуковыми устройствами с библиотекой TinyALSA.

Реализация аудио HAL по умолчанию находится в AOSP по адресу /device/google/trout/hal/audio/6.0 . OEM-производители могут изменить ro.vendor.trout.audiohal.{in,out}_period_{ms,count} для своей платформы. OEM-производители также могут реализовывать свои собственные аудио HAL, переопределяя связанные со звуком переменные в /device/google/trout/aosp_trout_common.mk.

Звуковой контроль HAL управляет звуковым фокусом в AAOS. Например, когда система воспроизводит аварийные сигналы, может потребоваться приглушить музыку, играющую в фоновом режиме. HAL управления звуком уведомит те приложения, которые воспроизводят музыку, отключить звук в этой ситуации. В виртуализированной системе звуки могут исходить от других виртуальных машин. В эталонной реализации гостевая виртуальная машина AAOS имеет работающий демон сервера управления звуком, который использует GRPC-vsock для получения запросов аудиофокуса от других виртуальных машин. Хост-ВМ может использовать device/google/trout/hal/audiocontrol/2.0/libandroid_audio_controller для отправки запросов на управление звуком в AAOS. Пока libandroid_audio_controller удерживает фокус звука, он будет продолжать отправлять тактовые импульсы в AAOS до тех пор, пока фокус не будет освобожден.

Аудио архитектура
Рисунок 5. Аудио архитектура

Bluetooth

Реализация Bluetooth основана на конструкции, показанной ниже.

Архитектура Bluetooth
Рисунок 5. Архитектура Bluetooth

Профиль громкой связи Bluetooth

Чтобы включить Bluetooth Hands-Free Profile (HFP) на trout , спецификация звукового устройства VirtIO была расширена для поддержки элементов управления звуком. Используя этот подход, звуковое устройство VirtIO на стороне хоста/гипервизора предоставляет следующие три элемента управления звуком, связанные с HFP:

  • hfp_enable
  • hfp_set_sampling_rate
  • hfp_volume

Когда AAOS работает как гостевая ВМ, AAOS использует TinyAlsa для установки этих элементов управления звуком. Чтобы включить вариант использования HFP, хост/гипервизор выполняет маршрутизацию и калибровку конкретного поставщика соответствующим образом.

Реализация Bluetooth основана на рисунке ниже.

Архитектура Bluetooth
Рисунок 5. Архитектура Bluetooth

Свалка

При создании отчета об ошибке для виртуализированной AAOS полезно включить информацию о виртуальной машине хоста, чтобы у разработчиков было более полное представление о системе. Для этого эталонная реализация trout реализует IDumpstateDevice HAL, который собирает информацию о хост-VM через GRPC-vsock . Информация о виртуальной машине хоста, упакованная с помощью tar, в отчете об ошибке называется dumpstate_board.bin , а журналы дампа находятся в dumpstate_board.txt .

Чтобы настроить команды для выполнения:

  1. Скопируйте сведения о конфигурации из файла ниже в XML-файл, например, 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. Передайте путь нового XML-файла серверу dumpstate при запуске. Например:
    --config_file my_config.xml
    

Система расширенного обзора (EVS)

Система расширенного обзора (EVS) используется для отображения видео, снятого камерами заднего и кругового обзора. В виртуализированной AAOS стек EVS может получить доступ к видеопотоку с виртуализированного потокового устройства V4L2, использующего видеодрайвер VirtIO.

Режим гаража

Дополнительные сведения см. в разделе Что такое гаражный режим? .

Вход и выход из режима гаража инициируется свойствами AP_POWER_STATE_REQ , отправленными HAL транспортного средства. В режиме виртуализации режим Garage запускается со стороны хоста. Виртуальная машина хоста должна оставаться включенной, чтобы предоставлять виртуальные устройства для виртуальной машины Android, пока Android не будет выключен. Сервер VHAL на главной виртуальной машине отправляет сигнал завершения работы гостевой виртуальной машине AAOS. Получив сигнал клиента VHAL, виртуальная машина AAOS переходит в режим гаража и начинает отправлять сигналы пульса, чтобы поддерживать активность виртуальной машины хоста.

Глобальная навигационная спутниковая система (GNSS)

В trout 1.0 добавлена ​​поддержка виртуализации GNSS через virtio-console . Реализация поддерживает обмен необработанными измерениями и исправлениями местоположения от хоста к гостю.

Формат обмена данными — CSV, используемый приложением GnssLogger. В эталонной реализации, поскольку собственный драйвер GNSS недоступен, доступны фиктивные данные, но собственный драйвер может быть реализован без каких-либо изменений на гостевой стороне. Образец фиктивного хост-агента предоставляется как часть исходного кода trout .

Текущая реализация предполагает, что инициализация GNSS и вспомогательная GNSS (AGNSS) будут обрабатываться средой хост-ОС.

ГНСС-архитектура
Рисунок 2. Архитектура GNSS

Графика

Когда AAOS работает в качестве гостевой виртуальной машины вместе с другими автомобильными операционными системами, Android может не иметь прямого доступа к графическому процессору или контроллеру дисплея. В этом случае для доступа к графическому процессору можно использовать Mesa или goldfish-opengl и virtio-gpu на гостевой виртуальной машине Android и устройстве virtio-gpu .

На гостевой виртуальной машине Android Mesa или goldfish-opengl кодирует команды OpenGLES либо в поток Gallium, либо в автоматически сгенерированный поток GLES соответственно. В качестве транспорта используется драйвер ядра virtio-gpu . На стороне хоста virglrenderer (для Mesa) и vulkan-cereal (для goldfish-opengl ) воспроизводят поток декодированных команд поверх существующего драйвера графического процессора. Эталонная платформа trout поддерживает OpenGL ES только с поддержкой Vulkan, которая ожидается в будущем выпуске.

Графическая архитектура
Рисунок 3. Графическая архитектура

Датчики

Когда AAOS работает как гостевая виртуальная машина вместе с другими автомобильными операционными системами, Android может не иметь прямого доступа к датчикам. В этом случае для доступа к датчикам используются драйвер Virtio-SCMI на гостевой виртуальной машине Android и устройство VirtIO-SCMI на виртуальной машине хоста. Эталонная платформа виртуализации AAOS предоставляет универсальный и не зависящий от аппаратного обеспечения HAL датчика, который можно использовать для SoC на базе ARM для доступа к датчикам.

Sensor HAL взаимодействует с драйвером IIO SCMI в подсистеме IIO ядра Linux, которая использует протокол управления датчиками SCMI, предоставляемый спецификацией ARM System Control and Management Interface (SCMI) , для обнаружения и настройки датчиков, считывания данных датчиков и получения уведомлений о датчиках. меняется значение.

Драйвер IIO SCMI использует драйвер VirtIO SCMI, который использует транспортный протокол VirtIO, как указано в virtio-scmi , для обмена сообщениями SCMI с устройством SCMI VirtIO на виртуальной машине хоста. Устройство VirtIO SCMI имеет прямой доступ к датчикам через драйверы датчиков, специфичные для SoC.

Архитектура датчика
Рисунок 4. Архитектура датчика

Местоположение датчика HAL

Эталонная реализация датчика HAL, использующая VirtIO SCMI, находится по адресу device/google/trout/hal/sensors .

Конфигурация датчика HAL

Sensor HAL может потребоваться изменить данные датчика, полученные от Host VM, чтобы они соответствовали системе координат датчика автомобиля Android. Схему для настройки датчика можно найти в device/google/trout/hal/sensors/2.0/config/sensor_hal_configuration.xsd .

OEM-производители могут указать конфигурацию датчика, например ориентацию и местоположение, в sensor_hal_configuration.xml и скопировать файл в папку /odm/etc/sensors/ или /vendor/etc/sensors/ . Пример конфигурации датчика приведен ниже:

<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

Реализация транспортного средства HAL состоит из двух компонентов:

  • Клиент. Предоставляет API-интерфейсы, используемые Android в виртуализированной AAOS.
  • Сервер. Общается напрямую с оборудованием, таким как автомобильные шины (или эмулятор).

В виртуализации сервер VHAL работает на виртуальной машине хоста. Клиент VHAL и сервер взаимодействуют через GRPC-vsock (дополнительную информацию см. в разделе device/google/trout/hal/vehicle/2.0/proto/VehicleServer.proto ). OEM-производители могут использовать другой транспортный протокол, отличный от GRPC, переопределяя коммуникационные API. Примеры см. в разделе device/google/trout/hal/vehicle/2.0/GrpcVehicle{Client,Server}.cpp .

Другие подсистемы

VirtIO уже предоставляет четко определенный интерфейс для таких компонентов, как блочное хранилище, сеть, консоль, ввод, сокет и энтропия. Для этих подсистем AAOS использует драйвер как есть, например, virtio-blk , virtio-input , virtio-console и virtio-net .

В виртуализированной эталонной платформе AAOS Wi-Fi поддерживается с помощью mac80211_hwsim для включения беспроводной сети VirtWifi , которая затем использует virtio-net для отправки сетевого трафика на хост-ВМ, которая имеет прямой доступ к фактической сети Wi-Fi.