Датчики HAL 2

Уровень аппаратной абстракции датчиков (HAL) - это интерфейс между платформой датчиков Android и датчиками устройства, такими как акселерометр или гироскоп. HAL датчиков определяет функции, которые должны быть реализованы, чтобы позволить структуре управлять датчиками.

Датчики HAL 2.0 доступен в Android 10 и выше для новых и модернизированных устройств. Датчики HAL 2.0 основан на датчики HAL 1.0 , но имеет несколько ключевых отличий, которые предотвращают его от обратной совместимости. Датчики HAL 2.0 использует Fast Очереди сообщений (FMQs) для отправки датчика события из HAL в рамках Android датчика.

Датчики HAL 2.1 доступен в Android 11 и выше для новых и модернизированных устройств. Датчики HAL 2.1 является итерация Датчики HAL 2.0 , который подвергает HINGE_ANGLE тип датчика и обновляет различные методы , чтобы принять HINGE_ANGLE типа.

HAL 2.1 Интерфейс

Основной источник документации для датчиков HAL 2.1 находится в пределах определения HAL на аппаратном / интерфейсах / датчики / 2.1 / ISensors.hal . Если есть конфликт между требованиями этой страницы и ISensors.hal , используйте требование в ISensors.hal .

Интерфейс HAL 2.0

Основной источник документации для датчиков HAL 2.0 находится в пределах определения HAL на аппаратном / интерфейсах / датчики / 2.0 / ISensors.hal . Если есть конфликт между требованиями этой страницы и ISensors.hal , используйте требование в ISensors.hal .

Реализация датчиков HAL 2.0 и HAL 2.1

Для реализации Датчики HAL 2.0 или 2.1, объект должен расширить ISensors интерфейс и выполнять все функции , определенные в 2.0/ISensors.hal или 2.1/ISensors.hal .

Инициализация HAL

HAL датчиков должен быть инициализирован платформой датчиков Android, прежде чем его можно будет использовать. Рамки вызывают initialize() функцию для HAL 2.0 и initialize_2_1() функцию для HAL 2.1 , чтобы обеспечить три параметра к датчикам HAL: два FMQ дескрипторов и один указатель на ISensorsCallback объект.

HAL использует первый дескриптор для создания Event FMQ, используемого для записи событий датчиков в структуру. HAL использует второй дескриптор для создания Wake блокировки FMQ используется для синхронизации , когда HAL выпускает свой замок бодрствования для WAKE_UP ДАТЧИКА событий. HAL должен сохранить указатель на ISensorsCallback объект так , чтобы все необходимые функции обратного вызова могут быть вызваны.

initialize() или initialize_2_1() функция должна быть первая функция вызывается при инициализации датчиков HAL.

Открытие доступных датчиков

Чтобы получить список всех доступных датчиков статических в устройстве, используйте getSensorsList() функцию на HAL 2.0 и getSensorsList_2_1() функции на HAL 2.1. Эта функция возвращает список датчиков, каждый из которых уникально идентифицируется своим дескриптором. Ручка для данного датчика не должна изменяться при перезапуске процесса, на котором размещены датчики HAL. Дескрипторы могут изменяться при перезагрузке устройства и при перезапуске сервера системы.

Если несколько датчиков разделяют один и тот же тип датчика и пробуждение свойства, то первый датчик в списке называется датчиком по умолчанию , и возвращается к приложениям , которые используют getDefaultSensor(int sensorType, bool wakeUp) из getDefaultSensor(int sensorType, bool wakeUp) функции.

Стабильность списка датчиков

После перезапуска Датчики HAL, если данные , возвращаемые getSensorsList() или getSensorsList_2_1() указывает на значительные изменения по сравнению с список датчиков извлеченного перед перезапуском, каркас вызывает перезапуск Android выполнения. Существенные изменения в списке датчиков включают случаи, когда датчик с данной ручкой отсутствует или изменил атрибуты, или когда введены новые датчики. Хотя перезапуск среды выполнения Android мешает пользователю, он необходим, потому что платформа Android больше не может соответствовать контракту Android API, согласно которому статические (нединамические) датчики не меняются в течение срока службы приложения. Это также может помешать платформе повторно установить активные запросы датчиков, сделанные приложениями. Поэтому поставщикам HAL рекомендуется не допускать внесения изменений в список датчиков, которых можно избежать.

Чтобы гарантировать стабильную работу сенсорных ручек, HAL должен детерминированно сопоставить данный физический сенсор в устройстве с его ручкой. Хотя интерфейс Sensors HAL не требует какой-либо конкретной реализации, у разработчиков есть несколько вариантов, позволяющих удовлетворить это требование.

Например, список датчиков можно отсортировать, используя комбинацию фиксированных атрибутов каждого датчика, таких как поставщик, модель и тип датчика. Другой вариант основан на том факте , что набор устройства статических датчиков фиксируется на аппаратном уровне , поэтому HAL должен знать , когда все ожидаемые датчики завершения инициализации перед возвращением из getSensorsList() или getSensorsList_2_1() . Этот список ожидаемых датчиков может быть скомпилирован в двоичный файл HAL или сохранен в файле конфигурации в файловой системе, а порядок появления может использоваться для получения стабильных дескрипторов. Хотя лучшее решение зависит от конкретных деталей реализации вашего HAL, ключевым требованием является то, что дескрипторы датчиков не меняются при перезапусках HAL.

Настройка датчиков

Перед тем, как датчик активирован, датчик должен быть сконфигурирован с периодом выборки и максимальной задержкой отчетов с использованием batch() функции.

Датчик должен быть в состоянии быть изменена в любое время , используя batch() без потери данных датчика.

Период выборки

Период выборки имеет другое значение в зависимости от типа настраиваемого датчика:

  • Непрерывный: события датчика генерируются с постоянной скоростью.
  • При изменении: события генерируются не быстрее, чем период выборки, и могут генерироваться со скоростью, меньшей, чем период выборки, если измеренное значение не изменяется.
  • Одноразовый: период выборки игнорируется.
  • Специальное предложение : Для получения более подробной информации см типов датчиков .

Чтобы узнать о взаимодействии между периодом дискретизации и режимами , отметившим датчиком, см Режимов отчетов .

Максимальная задержка отчетов

Максимальная задержка отчета устанавливает максимальное время в наносекундах, в течение которого события могут быть отложены и сохранены в аппаратном FIFO перед записью в Event FMQ через HAL, когда SoC активен.

Нулевое значение означает, что о событиях необходимо сообщать сразу после их измерения, либо полностью пропуская FIFO, либо очищая FIFO, как только одно событие от датчика присутствует в FIFO.

Например, акселерометр, активированный на частоте 50 Гц с максимальной задержкой отчета, равной нулю, триггеры прерывают 50 раз в секунду, когда SoC активен.

Когда максимальная задержка отчета больше нуля, события датчика не нужно сообщать сразу после их обнаружения. События могут временно храниться в аппаратном FIFO и сообщаться в пакетном режиме, если ни одно событие не задерживается более чем на максимальную задержку отчета. Все события с момента предыдущего пакета записываются и возвращаются сразу. Это уменьшает количество прерываний, отправляемых на SoC, и позволяет SoC переключаться в режим пониженного энергопотребления, пока датчик собирает и группирует данные.

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

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

Активация датчиков

Структура включает и отключает датчики , использующие activate() функцию. До активации датчика, каркас должен сначала сконфигурировать датчик , используя batch() .

После деактивации датчика дополнительные события от этого датчика не должны записываться в Event FMQ.

Датчики промывки

Если датчик настроен на данные партии датчиков, каркас может заставить немедленно румянец порционных событий датчиков с помощью вызова flush() . Это приводит к тому, что пакетные события датчика для указанного дескриптора датчика немедленно записываются в Event FMQ. Датчики HAL необходимо добавить флеш полного события к концу датчика событий, которые записываются в результате вызова flush() .

Сброс происходит асинхронно (то есть эта функция должна возвращаться немедленно). Если реализация использует один FIFO для нескольких датчиков, этот FIFO сбрасывается, а событие завершения очистки добавляется только для указанного датчика.

Если не указанный датчик не имеет буфера FIFO (без буферизации возможно), или если FIFO был пуст в момент вызова, flush() должна все же добиться успеха и отправить промывочное полное событие для этого датчика. Это относится ко всем датчикам, кроме одноразовых датчиков.

Если на flush() вызывается для датчика одного выстрела, а затем на flush() должен возвращать BAD_VALUE , а не генерировать полный флеш событие.

Запись событий датчика в FMQ

Event FMQ используется Sensors HAL для передачи событий датчиков в платформу датчиков Android.

Событие FMQ - это синхронизированный FMQ, что означает, что любая попытка записать в FMQ больше событий, чем позволяет доступное пространство, приводит к неудачной записи. В таком случае HAL должен определить, записывать ли текущий набор событий как две меньшие группы событий или записывать все события вместе, когда доступно достаточно места.

Когда датчики HAL написал требуемое количество датчиков событий в FMQ событий, датчики HAL должен сообщить структуру , что события готовы к написанию EventQueueFlagBits::READ_AND_PROCESS немного к событию FMQ в EventFlag::wake функции. EventFlag может быть создан из FMQ Event с помощью EventFlag::createEventFlag это событие FMQ в и getEventFlagWord() функцию.

Датчики HAL 2.0 / 2.1 поддерживает как write и writeBlocking на FMQ событий. Реализация по умолчанию содержит ссылку для использования write . Если writeBlocking функция используется, readNotification флаг должен быть установлен в EventQueueFlagBits::EVENTS_READ , которая устанавливается в рамках , когда он читает события из FMQ событий. Флаг уведомления записи должен быть установлен в EventQueueFlagBits::READ_AND_PROCESS , который уведомляет рамки , что события были записаны в FMQ событий.

WAKE_UP события

WAKE_UP событие датчиков события , которые вызывают процессор приложений (AP) , чтобы проснуться и сразу же обработать событие. Всякий раз , когда WAKE_UP событие записываются в FMQ события, датчики HAL должны обеспечить блокировку бодрствования , чтобы гарантировать , что система бодрствует пока рамки не может обработать событие. Получив WAKE_UP событие, каркас обеспечивает его собственный замок бодрствование, что позволяет для датчиков HAL , чтобы освободить его замок бодрствование. Для синхронизации, когда датчики HAL снимают блокировку слежения, используйте Wake Lock FMQ.

Датчики HAL должны читать Wake блокировка FMQ , чтобы определить количество WAKE_UP событий, рамки обработали. HAL должен освободить только свою блокировку бодрствования для WAKE_UP событий , если общее количество необработанных WAKE_UP событий равно нуль. После обработки датчиков событий, структура подсчитывает количество событий, которые помечены как WAKE_UP события и записывает это число обратно в Wake Замок FMQ.

Структура устанавливает WakeLockQueueFlagBits::DATA_WRITTEN уведомление записи на Wake блокировки FMQ всякий раз , когда она записывает данные в Wake замок FMQ.

Динамические датчики

Динамические датчики - это датчики, которые физически не являются частью устройства, но могут использоваться в качестве входных данных для устройства, например, геймпада с акселерометром.

Когда датчик динамического подключен, onDynamicSensorConnected функция в ISensorsCallback должна быть вызвана из датчиков HAL. Это уведомляет структуру нового динамического датчика и позволяет управлять датчиком через структуру и потреблять события датчика для клиентов.

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

Прямой канал

Прямой канал - это метод работы, при котором события датчиков записываются в определенную память, а не в Event FMQ, минуя Android Sensors Framework. Клиент, регистрирующий прямой канал, должен считывать события датчиков непосредственно из памяти, которая использовалась для создания прямого канала, и не будет получать события датчиков через платформу. configDirectReport() функция подобна batch() для нормальной работы и настраивает прямой канал отчета.

В registerDirectChannel() и unregisterDirectChannel() функции создают или разрушают новый прямой канал.

Режимы работы

setOperationMode() функция позволяет рамке настроить датчик таким образом , что структура может вводить данные датчика в датчик. Это полезно для тестирования, особенно для алгоритмов, которые существуют ниже фреймворка.

injectSensorData() функция в HAL 2.0 и injectSensorsData_2_1() функция в HAL 2.0 , как правило , используется для передачи эксплуатационных параметров в датчиках HAL. Эту функцию также можно использовать для ввода событий датчика в конкретный датчик.

Проверка

Чтобы проверить вашу реализацию датчиков HAL, запустите тесты датчиков CTS и VTS.

CTS тесты

Сенсорные тесты CTS существуют как в автоматических тестах CTS, так и в ручном приложении CTS Verifier.

Автоматизированные тесты расположены в Cts / тесты / датчик / SRC / Android / оборудования / каратов . Эти тесты проверяют стандартные функции датчиков, такие как активация датчиков, дозирование и частота событий датчиков.

Тесты КТС Verifier расположены в кар / приложений / CtsVerifier / SRC / COM / андроид / к.т.н. / контролер / датчики . Эти тесты требуют ручного ввода от оператора тестирования и гарантируют, что датчики сообщают точные значения.

Прохождение тестов CTS имеет решающее значение для обеспечения соответствия тестируемого устройства всем требованиям CDD.

Испытания СУДС

VTS испытание для датчиков HAL 2.0 расположены в аппаратных / интерфейсы / датчики / 2.0 / VTS . VTS тесты для датчиков HAL 2.1 расположены в аппаратных / интерфейсы / датчики / 2.1 / VTS . Эти испытания гарантируют , что датчики HAL осуществляется должным образом и что все требования в пределах ISensors.hal и ISensorsCallback.hal правильно выполнены.

Обновление до Sensors HAL 2.1 с 2.0

При обновлении до датчиков HAL 2.1 от 2.0, ваша реализация HAL должна включать initialize_2_1() , getSensorsList_2_1() и injectSensorsData_2_1() методы, вместе с типами HAL 2.1. Эти методы должны соответствовать тем же требованиям, которые указаны для HAL 2.0 выше.

Поскольку HAL вспомогательной версии должны поддерживать все функции из предыдущих HAL, HAL 2.1 должны поддерживать инициализацию как HAL 2.0. Чтобы избежать сложности поддержки обеих версий HAL, настоятельно рекомендуется использовать Multi-HAL 2.1.

В качестве примера того , как реализовать свои собственные датчики 2,1 HAL см Sensors.h .

Обновление до Sensors HAL 2.0 с 1.0

При обновлении до Sensors HAL 2.0 с 1.0 убедитесь, что ваша реализация HAL соответствует следующим требованиям.

Инициализация HAL

initialize() функция должна быть поддержана , чтобы установить FMQs между рамками и HAL.

Открытие доступных датчиков

В Датчики HAL 2.0, getSensorsList() функция должна возвращать одинаковое значение в течение одного устройства загрузки, даже через датчики HAL перезапусков. Новое требование getSensorsList() функции является то , что он должен вернуть то же значение в течение одного устройства загрузки, даже через датчики HAL перезапусков. Это позволяет платформе попытаться восстановить подключения датчиков при перезапуске системного сервера. Значение , возвращаемое getSensorsList() может измениться после того , как выполняет перезагрузку устройства.

Запись событий датчика в FMQ

Вместо того , чтобы ждать poll() будет называться, в Sensors HAL 2.0, Датчики HAL должны активно записи датчиков событий к FMQ событий , когда датчик события доступны. HAL также отвечает за написание правильных битов в EventFlag , чтобы вызвать FMQ чтения в рамках.

WAKE_UP события

В Sensors HAL 1.0, HAL удалось освободить свою блокировку бодрствования для любого WAKE_UP события на любом последующем вызов к poll() после того, как WAKE_UP был размещен poll() , так как это свидетельствует о том , что структура обработала все события датчиков и было получено wake lock, если необходимо. Потому что, в Sensors HAL 2.0, HAL уже не знает , когда рамки обработали событие , записанное в FMQ, кильватерной замок FMQ не позволяет рамки для связи с HAL , когда она обрабатывается WAKE_UP события.

В Sensors HAL 2.0, замок бодрствование обеспеченных датчиками HAL для WAKE_UP событий должно начинаться с SensorsHAL_WAKEUP .

Динамические датчики

Динамические датчики были возвращены с помощью poll() функции датчиков HAL 1.0. Датчики HAL 2.0 требует , чтобы onDynamicSensorsConnected и onDynamicSensorsDisconnected в ISensorsCallback назвать всякий раз , когда динамическое изменение соединения датчика. Эти обратные вызовы доступны в качестве части ISensorsCallback указателя , который предоставляется через initialize() функцию.

Режимы работы

DATA_INJECTION режим для WAKE_UP датчиков должны поддерживаться в датчиках HAL 2.0.

Поддержка Multi-HAL

Датчики HAL 2.0 и 2.1 поддерживает мульти-HAL с использованием рамок Датчики Multi-HAL . Для получения дополнительной информации о реализации см Портирование с датчиками HAL 1.0 .