DriverUI

Обычно интерфейс приборной панели размещается за рулевым колесом на отдельном дисплее. Производители постепенно объединяют приборную панель и IVI в один дисплей. Этот комбинированный интерфейс называется DriverUI.

DriverUI

Рисунок 1. DriverUI.

DriverUI – это системное приложение Android, которое отрисовывает всю приборную панель, за исключением элементов, связанных с безопасностью или нормативными требованиями. Их отрисовывает средство визуализации с высокой доступностью (HAR). DriverUI показывает информацию о воспроизведении медиаконтента, телефонных звонках, картах, навигации и т. д. и реализует Automotive Design for Compose.

DriverUI как действие по умолчанию на приборной панели

DriverUI работает как привилегированное приложение кластера в Android, и AAOS запускает его автоматически.

Для создания приборных панелей в AAOS используется класс ClusterHomeManager, также известный как Cluster2. Этот класс определяет конфигурацию, необходимую для идентификации реализации приборной панели и того, как AAOS взаимодействует с ней. Google предоставляет эталонные реализации API Cluster2.

Платформы

Вы можете создать и запустить Display Safety на SDV. Платформа SDV (Software Defined Vehicle):

  • Требуются две гостевые виртуальные машины.
  • Запускает HAR в SDV Media (также известной как виртуальная машина с быстрой загрузкой) на гостевой виртуальной машине.
  • Запускает DriverUI в другой гостевой виртуальной машине SDV IVI.
  • Запускает монитор безопасности на виртуальной машине SDV Media.

Архитектура платформы SDV

Рисунок 2. Архитектура платформы SDV.

Объединить выходные данные HAR и DriverUI

Для отображения интерфейса HAR и DriverUI используются отдельные дисплеи. Оба выхода являются составными и отображаются в DriverUI как одно изображение.

Для этого HAR управляет прозрачностью областей, в которых появляется вывод Android, на основе сообщений о пульсе от DriverUI. Если DriverUI недоступен, HAR обнаруживает отсутствие сигналов, делает области DriverUI непрозрачными и показывает плейсхолдеры. Когда сигналы получены, плейсхолдеры удаляются, а области DriverUI становятся прозрачными.

Состав HAR и DriverUI

Рисунок 3. Состав HAR и DriverUI.

Устранение неполадок с альфа-композицией и сквозным показом

Поскольку HAR критически важен для безопасности, его аппаратная плоскость отображения находится поверх плоскости отображения Android IVI. При создании или отладке пользовательских представлений или внешних поверхностей OpenGL ES в HAR проверьте, как заданы значения альфа-канала:

  • Отсутствие вывода DriverUI под плоскостью HAR. Хотя HAR получает действительные сообщения HeartbeatRequest от DriverUI, HAR должен очистить область просмотра DriverUI до прозрачной (alpha = 0.0), чтобы был виден базовый пользовательский интерфейс кластера Android. Если специальный слой HAR или фон рисует непрозрачные пиксели (alpha = 1.0) над областью DriverUI, он блокирует вывод Android под ним.
  • Непреднамеренные прозрачные отверстия в пользовательских 3D- или OpenGL-поверхностях. При рендеринге внешней поверхности OpenGL ES или 3D в узел HAR (например, пользовательский 3D-датчик или сцену, которая записывает пиксели RGB с неиспользуемым альфа-байтом, оставленным на уровне 0x00) явно установите альфа-канал непрозрачных пикселей на 0xFF (alpha = 1.0). Если оставить альфа-байт на уровне 0x00, компоновщик будет обрабатывать эти пиксели как прозрачные (alpha = 0.0) и пробивать отверстие прямо через слой HAR в базовую плоскость Android IVI.
  • Диагностика дисплея на нескольких виртуальных машинах. Поскольку HAR (sdv_media_har_cf) и Android IVI (sdv_ivi_cf_ds) работают на отдельных гостевых виртуальных машинах, запуск adb shell dumpsys SurfaceFlinger на виртуальной машине Android IVI проверяет только слои Android и не видит вышележащую плоскость HAR.

Обмен данными между DriverUI и HAR

DriverUI и HAR взаимодействуют друг с другом с помощью вызовов удаленных процедур (RPC). Сообщение heartbeat – это пример данных, отправляемых по каналу RPC. Одним из его полей является временная метка.

Для удаленных вызовов процедур используется gRPC. В SDV-системах SDV comms предоставляет SDV Gateway Client для обнаружения и создания канала от DriverUI к HAR. Сервис gRPC определяет файл буфера протокола:


// Heartbeat.
rpc Heartbeat(HeartbeatRequest) returns (HeartbeatResponse) {}

// Document switched in the DriverUI.
rpc DocumentSwitched(DocumentSwitchedRequest) returns (DocumentSwitchedResponse) {}

// Document updated in the DriverUI. Unary RPC.
rpc DocumentUpdated(DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

// Document updated in the DriverUI. Requests are streamed with each request
// containing a part of the document and the entire document is assembled from these
// chunks by the server.
rpc DocumentUpdatedStreaming(stream DocumentUpdatedRequest) returns (DocumentUpdatedResponse) {}

/// Request for HAR to change design tokens.
rpc DesignTokenUpdate(DesignTokenUpdateRequest) returns (DesignTokenUpdateResponse) {}

// Request to change the current locale used in HAR.
rpc LocaleUpdate(LocaleUpdateRequest) returns (LocaleUpdateResponse) {}

// Requests to swap a certain variant at a Figma node.
rpc ChangeVariant(ChangeVariantRequest) returns (ChangeVariantResponse) {}

// Requests to change the container (display/root node) configuration (dpi, size) in HAR.
rpc ChangeContainerConfiguration(ChangeContainerConfigurationRequest) returns (ChangeContainerConfigurationResponse) {}

Сведения о запросе и ответе можно найти в источнике Display Safety по адресу packages/apps/Car/DriverUI/proto/driverui.proto в репозитории исходного кода ub-automotive.

На платформе SDV связь SDV предоставляет клиент шлюза SDV для обнаружения и создания канала gRPC от DriverUI до HAR.

Выполнение этих команд в терминале IVI отправляет данные в SDV Media, что запускает обновление темы на всей панели приборов.

adb shell cmd car_service inject-key -d 1 9 # Purple Theme
adb shell cmd car_service inject-key -d 1 8 # Blue Theme

RPC-запрос на изменение темы DriverUI и HAR.

Рисунок 4. RPC-коммуникация для изменения темы DriverUI и HAR.

Показывать на приборной панели информацию о медиаконтенте, карты и данные о звонках

Благодаря связи с IVI DriverUI может показывать информацию о медиаконтенте, картах и телефонии на эталонной приборной панели. Хотя в эталонной реализации по умолчанию используется состояние Media, экран обновляется в зависимости от активных сервисов в соответствии со следующим приоритетом:

  1. Карты
  2. Телефонная связь
  3. Мультимедиа

Система автоматически отдает приоритет навигации в Картах или активным сервисам телефонии, а не состоянию мультимедиа по умолчанию.

Различные состояния DriverUI показаны на следующем рисунке:

Интерфейс водителя, в котором полностью показаны разделы "Медиа" и "Телефония".

Рисунок 5. Интерфейс водителя с разделами "Медиа" и "Телефония" на всей приборной панели.

Интеграция Automotive Design for Compose

DriverUI реализует Automotive Design for Compose, чтобы макеты (Figma) можно было демонстрировать и дорабатывать прямо в приложении Android. Эта интеграция позволяет рендерить макеты в среде выполнения, что упрощает взаимодействие между дизайнерами и разработчиками.

Доступ к объектам дизайна

Примеры документов Figma для DriverUI являются частью базы кода. Чтобы получить доступ к этим дизайнам и изменить их:

  1. Запустите DriverUI с локальным файлом Automotive Design for Compose DCF из packages/apps/Car/DriverUI/src/main/assets/figma/*.dcf.
  2. Найдите файл объекта packages/apps/Car/DriverUI/src/main/assets/DriverUI.fig.
  3. Импортируйте этот файл в Figma, чтобы посмотреть исходные дизайны или внести изменения.

Версия Automotive Design for Compose

  • Gradle использует версию Automotive Design for Compose, указанную для designcompose в packages/apps/Car/libs/aaos-apps-gradle-project/gradle/libs.versions.toml.
  • Выпуски Automotive Design for Compose доступны на странице выпусков.

Настройка обновлений в реальном времени

Automotive Design for Compose поддерживает обновления в реальном времени в режиме разработки, что позволяет мгновенно отображать изменения, внесенные в Figma, в DriverUI. Это способствует быстрому тестированию и ускорению циклов итерации дизайна.

Чтобы задать токен Figma для DriverUI, выполните следующую команду:

adb shell am startservice \
  -n "com.android.car.driverui/com.android.designcompose.ApiKeyService" \
  -a setApiKey \
  -e ApiKey $FIGMA_ACCESS_TOKEN \
  --user 0

Синхронизация документов по проектированию двух виртуальных машин

В конфигурации с двумя виртуальными машинами обновления дизайна должны распространяться за пределы границ, чтобы поддерживать согласованность.

  • DriverUI получает последнюю версию документа Figma и передает ее в HAR, используя каналы связи gRPC, описанные на этой странице.
  • В результате весь кластер обновляется с учетом последних итераций дизайна Figma, сохраняя синхронизацию обеих виртуальных машин с источником дизайна.

Обновление проектной документации в реальном времени из Figma в DriverUI и HAR.

Рисунок 6. Обновление проектной документации в реальном времени из Figma в DriverUI и HAR.

Защита канала gRPC

gRPC интегрирован с SSL и TLS и использует их для аутентификации сервера и шифрования всех данных, которыми обмениваются клиент и сервер. Клиенты могут предоставлять сертификаты для взаимной аутентификации. Дополнительную информацию об аутентификации gRPC можно найти в статье Аутентификация.