Уровень абстракции платформы HAR

Используйте средство визуализации высокой доступности (HAR), чтобы показывать информацию об автомобиле, которую Android не может отобразить. Это может произойти из-за проблем с запуском, доступностью, безопасностью или нормативными актами. HAR – это портативное встроенное приложение, написанное на языке Rust.

HAR, также называемый фреймворком HAR, включает код, который вы используете для создания приложений. Приложение, созданное с помощью HAR, называется приложением на основе HAR. Фреймворк HAR содержит разделы кода для разных платформ. Например, в системе Linux для звуков используются такие библиотеки, как tinyalsa. В QNX есть собственные уникальные аудиобиблиотеки.

Платформа включает в себя аппаратное обеспечение, операционную систему, системные библиотеки и другие факторы. Код для конкретной платформы состоит из частей, называемых подсистемами. Каждая подсистема обрабатывает одну функцию платформы, например аудио, камеры EVS или данные автомобиля. Чтобы поддерживать платформу, фреймворк HAR должен иметь все реализованные подсистемы.

Код подсистемы, зависящий от платформы, может выполняться в том же процессе, что и приложение на основе HAR, или в отдельном. В этом случае код обрабатывает межпроцессное взаимодействие (IPC), чтобы проверить, поддерживает ли платформа приложение. Сложные механизмы IPC должны быть частью кода, зависящего от платформы.

Набор тестов HAR запускает тесты для всех подсистем, реализованных для платформы. С помощью этого набора можно проверить, соответствуют ли платформы требованиям HAR, и выявить новые проблемы.

Терминология

На этой странице есть следующие слова:

Приложение на основе HAR
Приложение от OEM или приложение с определенной функцией, созданное с помощью фреймворка HAR. Приложения могут различаться по статусу и другим настраиваемым аспектам.
Фреймворк HAR
Предоставляет базовый набор инструментов для создания приложений.
Абстракция платформы HAR
Часть фреймворка HAR, которая предоставляет известный API, который должны реализовать все целевые платформы.
Набор тестов HAR
Серия известных тестов для реализаций платформы, помогающая убедиться, что реализации платформы поддерживают фреймворк HAR на определенной платформе.

Правила не применяются

HAR не решает следующие проблемы:

  • Отдельные реализации для всех целевых платформ. Вместо этого на этой странице описываются интерфейсы, которые должны быть реализованы на платформах и которым должен соответствовать набор тестов.

  • Отчеты о тестировании. Отдельные отчеты о тестировании для всех интерфейсов. Вместо этого на этой странице описываются отдельные функции для интерфейсов, включая аргументы, возвращаемые значения, ожидаемое поведение и ожидаемые побочные эффекты. На этой странице описан набор тестов, в котором можно реализовать и запустить тестовые сценарии.

Высокоуровневая структура крейта абстракции платформы

Проекты Rust состоят из крейтов. На рисунке 1 показана структура крейта для уровня абстракции платформы HAR. Уровень абстракции платформы влияет на два или более крейта Rust:

  • Абстракции (описания Rust trait) находятся в крейте фреймворка HAR.

  • Реализации для платформы находятся в отдельном крейте har-platform-x. Примеры: har-platform-linux или har-platform-android.

Вы не можете создать или протестировать HAR crate без указания реализации платформы. Это сделано намеренно, поскольку HAR – это фреймворк.

Приложение, в котором указана платформа, должно быть создано с помощью этого фреймворка, чтобы работать и проходить тестирование. Связи между фреймворком HAR и платформой показаны на этой диаграмме:

Ящик HAR

Рисунок 1. Ящик HAR.

Общая структура в display-safety

В этом дизайне в репозиторий display_safety добавляется ряд новых крейтов, как показано на рисунке 2:

HAR-контейнер, фреймворк и приложение

Рисунок 2. Модули абстракции.

Набор тестов структурно похож на приложение, но зависит только от крейта реализации платформы. Набор тестов должен ссылаться на характеристики и структуры, определенные в HAR, но не на более сложные реализации.

Общее описание уровня абстракции платформы

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

Название абстракции Похожая функция Описание Примечания
OpenGL 2D-рендеринг Предоставляет возможности рендеринга OpenGLES 2.0/3.0 для контейнера фреймворка HAR.
Audio Отрисовка аудио Предоставляет интерфейс, похожий на Android SoundPool, для управления системными аудиофайлами и их воспроизведения.
Camera Экран камеры автомобиля Предоставляет интерфейс, похожий на EVS HAL, для управления и отображения информации с камеры автомобиля.
Looper Основной цикл приложения и конфигурация экрана Предоставляет интерфейс, похожий на Android Looper, для управления основными циклами приложения и конфигурацией дисплея.
UserInput сенсорный экран, клавиатура, руль, поворотный контроллер и другие способы ввода, характерные для платформы; Предоставляет интерфейс для ввода данных в приложениях на основе HAR с помощью сенсорного экрана и клавиатуры. Эталонная реализация на основе Linux evdev в har-user-input-evdev.
VehicleData Ввод состояния транспортного средства Предоставляет интерфейс для передачи приложениям на основе HAR потока произвольных данных об автомобиле, например из Android VHAL или шины CAN.
ResourceManager Документ с кешированным дизайном для определенного приложения Предоставляет кеш памяти для ресурсов, необходимых для запуска HAR, например кешированных изображений и документов дизайна. Кеш диска пока не реализован.
Logging Системные журналы и телеметрия Обеспечивает поддержку ведения журналов для конкретной платформы с помощью системы трассировки. Это позволит собирать телеметрию, как того требует платформа.
Tracing Трассировка системы Предоставляет абстракцию для интеграции с системами трассировки и профилирования.
Monitoring Мониторинг системы Набор инструментов для отслеживания эффективности и задержек в рамках HAR.
Commlib Данные автомобиля Пример реализации с использованием сериализации protobuf. Устарело. Используйте API, определенные в reference/harry-control-api, и реализации harry-grpcio-server и harry-tonic-server (эталонная реализация).
TestSupport Поддержка тестирования хуков Поддерживает создание и удаление тестовых сценариев, генерацию тестовых событий и создание тестовых артефактов. Например, генерировать симулированные события касания для тестирования UserInput и создавать скриншоты для анализа. Эта функция заблокирована Rust, чтобы предотвратить ее включение в рабочие сборки.

Правила именования и структуры фреймворков

В таблице ниже приведены названия и структуры этих файлов.

  • Ожидаемые экземпляры подсистемы trait, предоставляемые фреймворком HAR. Каждый trait представляет собой подсистему, зависящую от платформы, которую необходимо реализовать.

  • Ожидаемые названия реализаций подсистем для конкретных платформ в любом крейте платформы. Приложения, использующие HAR, ожидают, что будут реализованы именно эти названия.

  • Экземпляры enum и struct, связанные с фреймворком HAR, обычно используются для передачи информации из реализаций, связанных с платформой, во фреймворк HAR.

Названия признаков Названия реализаций Перечисления и структуры фреймворка HAR
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (структура) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing Н/Д
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

Ошибки и их обработка

В предлагаемых API используется тип Rust Result<>. Rust требует проверять типы Result, которые содержат ошибки. Если нет, компилятор выдает предупреждение или ошибку. Проверка во время сборки обеспечивает проверку ошибок в коде для конкретной платформы.

Ошибки, возвращаемые реализациями платформы, имеют тип harry::error::Error. Чтобы убедиться, что типы ошибок платформы не попадают в код приложения, используйте стандартный тип ошибок, предоставляемый фреймворком HAR.

Тип harry::error::Error расширяется, чтобы включить определенные ошибки для всех подсистем:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

Неустранимые ошибки в основном возвращаются через определенные интерфейсы и обратные вызовы.

Подробная структура набора тестов

В этом разделе описывается дизайн набора тестов, который проверяет реализации абстракций для конкретных платформ.

Создайте тесты для набора тестов

Для сборок Soong (определяются файлами Android.bp) тесты компилируются как часть системы сборки платформы Android, а их выполнение управляется atest.

Как запустить набор тестов

Чтобы протестировать отдельную платформу, используйте команду atest с соответствующей целью тестирования (например, atest <module_name>). Эта команда развертывает и запускает тесты на устройстве или эмуляторе Android.