Используйте высокодоступный рендерер (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:
Абстракции (описания
traitRust) находятся в фреймворке HAR.Реализации для конкретной платформы осуществляются с помощью отдельного крейта
har-platform-x. Например,har-platform-linuxилиhar-platform-android.
Вы не сможете собрать или протестировать крейт HAR без указанной реализации платформы. Это сделано намеренно, поскольку фреймворк HAR — это именно фреймворк.
Для корректной работы и тестирования приложение, указывающее на конкретную платформу, должно быть создано с использованием этой структуры. Связи между структурой HAR и платформой показаны на этой диаграмме:
Рисунок 1. Ящик HAR.
Общая структура в рамках безопасности дисплеев
Данная разработка добавляет в репозиторий display_safety ряд новых контейнеров, как показано на рисунке 2:
Рисунок 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::Rendererharry::DisplayRotation |
AudioApiFactory | Audio | harry::AudioApiharry::AudioDeviceharry::VolumeMillibel |
ICameraManager | Camera | harry::ICameraDeviceharry::CameraDescriptor |
Looper | Looper | harry::LooperMessageharry::LooperOptionsharry::DisplayId |
PlatformVehicleData | VehicleData | harry::VehicleDataTypeharry::VehicleDataListener |
ResourceManager (Struct) | ResourceManager | harry::ResourceManagerMessageharry::ResourceTokenharry::RawImageData |
PlatformTracing | Tracing | Н/Д |
HarPerformanceMonitor | Monitoring | harry::Rendererharry::ResolveLatencyToken |
PlatformTestSupport | TestSupport | harry::TestConfigharry::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 или эмуляторе.