Архитектура

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

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

В некоторых случаях vsock использовался для связи между виртуальными машинами. Связь HAL транспортного средства, управление звуком и 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 Hands-Free

Чтобы включить профиль Bluetooth Hands-Free (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, который собирает информацию о виртуальной машине хоста через 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-файла на сервер дампа при запуске. Например:
    --config_file my_config.xml
    

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

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

Режим гаража

Дополнительную информацию см. в разделе «Режим гаража» .

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

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

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

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

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

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

Графика

Когда 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 ) воспроизводят декодированный поток команд поверх существующего драйвера графического процессора. Эталонная платформа AAOS trout поддерживает OpenGL ES только с поддержкой Vulkan, которая ожидается в будущем выпуске.

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

Датчики

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

Датчик HAL взаимодействует с драйвером IIO SCMI в подсистеме Linux Kernel IIO, которая использует протокол управления датчиками SCMI, предоставляемый спецификацией интерфейса управления и контроля системы ARM (SCMI), для обнаружения и настройки датчиков, считывания данных датчиков и получения уведомлений о датчиках. значения меняются.

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

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

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

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

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

Датчику HAL может потребоваться изменить данные датчика, полученные от виртуальной машины хоста, чтобы они соответствовали системе координат автомобильного датчика 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>

Автомобиль ХАЛ

Реализация Vehicle 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.