На рисунке ниже показан стек датчиков Android. Каждый компонент обменивается данными только с компонентами непосредственно над и под ним, хотя некоторые датчики могут обходить концентратор датчиков, когда он присутствует. Управление передается от приложений к датчикам, а данные от датчиков к приложениям.
Рис. 1. Слои стека датчиков Android и их соответствующие владельцы
SDK
Приложения получают доступ к датчикам через API Sensors SDK (Software Development Kit) . SDK содержит функции для вывода списка доступных датчиков и регистрации на датчике.
При регистрации на датчике приложение указывает предпочтительную частоту дискретизации и требования к задержке.
- Например, приложение может зарегистрироваться на акселерометре по умолчанию, запрашивая события с частотой 100 Гц и позволяя сообщать о событиях с задержкой в 1 секунду.
- Приложение будет получать события от акселерометра с частотой не менее 100 Гц и, возможно, с задержкой до 1 секунды.
Дополнительную информацию о SDK см. в документации для разработчиков .
Рамки
Фреймворк отвечает за привязку нескольких приложений к HAL . Сам HAL является одноклиентским. Если бы это мультиплексирование не происходило на уровне инфраструктуры, только одно приложение могло бы получить доступ к каждому датчику в любой момент времени.
- Когда первое приложение регистрируется на датчике, платформа отправляет запрос в HAL для активации датчика.
- Когда дополнительные приложения регистрируются на одном и том же датчике, платформа учитывает требования каждого приложения и отправляет обновленные запрошенные параметры в HAL.
- Частота дискретизации будет максимальной из запрошенных частот дискретизации, что означает, что некоторые приложения будут получать события с более высокой частотой, чем запрошенная.
- Максимальная задержка отчетов будет минимальной из запрошенных. Если одно приложение запрашивает один датчик с максимальной задержкой отчета, равной 0, все приложения будут получать события от этого датчика в непрерывном режиме, даже если некоторые из них запросили датчик с ненулевой максимальной задержкой отчета. Подробнее см. в разделе Пакетная обработка .
- Когда последнее приложение, зарегистрированное на одном датчике, отменяет регистрацию на нем, фреймворки отправляют запрос в HAL, чтобы деактивировать датчик, чтобы не потреблять энергию без необходимости.
Влияние мультиплексирования
Эта потребность в слое мультиплексирования в структуре объясняет некоторые проектные решения.
- Когда приложение запрашивает определенную частоту дискретизации, нет гарантии, что события не будут поступать с более высокой скоростью. Если другое приложение запросило тот же датчик с более высокой скоростью, первое приложение также получит их с более высокой скоростью.
- То же отсутствие гарантий относится и к запрошенной максимальной задержке отчетов: приложения могут получать события с гораздо меньшей задержкой, чем они запрашивали.
- Помимо частоты выборки и максимальной задержки отчетов, приложения не могут настраивать параметры датчика.
- Например, представьте себе физический датчик, который может работать как в режиме «высокой точности», так и в режиме «малого энергопотребления».
- На устройстве Android можно использовать только один из этих двух режимов, поскольку в противном случае приложение может запросить режим высокой точности, а другое — режим низкого энергопотребления; у фреймворка не было бы возможности удовлетворить оба приложения. Фреймворк всегда должен быть в состоянии удовлетворить всех своих клиентов, так что это не вариант.
- Не существует механизма отправки данных из приложений на датчики или их драйверы. Это гарантирует, что одно приложение не сможет изменить поведение датчиков, нарушая работу других приложений.
Слияние датчиков
Платформа Android предоставляет реализацию по умолчанию для некоторых составных датчиков. Когда на устройстве присутствуют гироскоп , акселерометр и магнитометр , но нет датчиков вектора вращения , силы тяжести и линейного ускорения , платформа реализует эти датчики, чтобы приложения могли их использовать.
Реализация по умолчанию не имеет доступа ко всем данным, к которым имеют доступ другие реализации, и она должна работать на SoC, поэтому она не так точна и не так энергоэффективна, как другие реализации. Насколько это возможно, производители устройств должны определять свои собственные объединенные датчики (вектор вращения, силы тяжести и линейного ускорения, а также более новые составные датчики, такие как игровой вектор вращения ), а не полагаться на эту реализацию по умолчанию. Производители устройств также могут запросить у поставщиков сенсорных чипов реализацию.
Реализация слияния датчиков по умолчанию не поддерживается и может привести к сбою CTS на устройствах, использующих ее.
Под капотом
Этот раздел предоставляется в качестве справочной информации для тех, кто поддерживает код платформы Android Open Source Project (AOSP). Для производителей оборудования это не актуально.
JNI
Фреймворк использует собственный интерфейс Java (JNI), связанный с android.hardware и расположенный в каталоге frameworks/base/core/jni/ . Этот код вызывает собственный код более низкого уровня для получения доступа к оборудованию датчика.
Родной фреймворк
Собственный фреймворк определяется в frameworks/native/ и предоставляет собственный эквивалент пакета android.hardware . Собственная платформа вызывает прокси-серверы Binder IPC для получения доступа к службам, связанным с датчиками.
Связующее МПК
Прокси-серверы Binder IPC упрощают обмен данными через границы процессов.
ХАЛ
API Sensors Hardware Abstraction Layer (HAL) — это интерфейс между драйверами оборудования и платформой Android. Он состоит из одного HAL-интерфейса Sensors.h и одной HAL-реализации, которую мы называем Sensors.cpp.
Интерфейс определяется участниками Android и AOSP, а реализация предоставляется производителем устройства.
HAL-интерфейс сенсора находится в hardware/libhardware/include/hardware . См. Sensors.h для получения дополнительной информации.
Цикл выпуска
Реализация HAL указывает, какую версию интерфейса HAL она реализует, устанавливая your_poll_device.common.version . Существующие версии интерфейса HAL определены в Sensor.h, и функциональность привязана к этим версиям.
Платформа Android в настоящее время поддерживает версии 1.0 и 1.3, но скоро версия 1.0 перестанет поддерживаться. В этой документации описывается поведение версии 1.3, до которой следует обновить все устройства. Подробнее об обновлении до версии 1.3 см. в разделе Устаревание версии HAL .
Драйвер ядра
Драйверы датчиков взаимодействуют с физическими устройствами. В некоторых случаях реализация HAL и драйверы представляют собой один и тот же программный объект. В других случаях интегратор аппаратного обеспечения запрашивает драйверы у производителей сенсорных чипов, но именно они пишут реализацию HAL.
Во всех случаях за реализацию HAL и драйверы ядра отвечают производители оборудования, и Android не предоставляет предпочтительных подходов к их написанию.
Концентратор датчика
Стек датчиков устройства может дополнительно включать концентратор датчиков, полезный для выполнения некоторых низкоуровневых вычислений с низким энергопотреблением, когда SoC может находиться в режиме ожидания. Например, на этих чипах можно выполнять подсчет шагов или объединение датчиков. Это также хорошее место для реализации пакетной обработки датчиков, добавления аппаратных FIFO для событий датчиков. Дополнительную информацию см. в разделе Пакетная обработка .
Примечание. Для разработки новых функций ContextHub, использующих новые датчики или светодиоды, вы также можете использовать Neonkey SensorHub, подключенный к макетной плате Hikey или Hikey960.
То, как материализуется концентратор датчиков, зависит от архитектуры. Иногда это отдельный чип, а иногда он включен в тот же чип, что и SoC. Важными характеристиками концентратора датчиков является то, что он должен содержать достаточно памяти для пакетной обработки и потреблять очень мало энергии, чтобы можно было реализовать датчики Android с низким энергопотреблением. Некоторые концентраторы датчиков содержат микроконтроллер для общих вычислений и аппаратные ускорители, позволяющие выполнять вычисления с очень низким энергопотреблением для маломощных датчиков.
Как устроен концентратор датчиков и как он взаимодействует с датчиками и SoC (шина I2C, шина SPI и т. д.), Android не указывает, но он должен быть направлен на минимизацию общего энергопотребления.
Одним из вариантов, который, по-видимому, оказывает значительное влияние на простоту реализации, является наличие двух линий прерываний, идущих от концентратора датчиков к SoC: одна для прерываний пробуждения (для датчиков пробуждения), а другая для прерываний, не связанных с активацией. (для датчиков без пробуждения).
Датчики
Это физические микросхемы МЭМ, выполняющие измерения. Во многих случаях на одном чипе присутствует несколько физических датчиков. Например, некоторые микросхемы включают в себя акселерометр, гироскоп и магнитометр. (Такие чипы часто называют 9-осевыми, так как каждый датчик предоставляет данные по 3 осям.)
Некоторые из этих микросхем также содержат некоторую логику для выполнения обычных вычислений, таких как обнаружение движения, обнаружение шагов и объединение 9-осевых датчиков.
Хотя требования и рекомендации CDD по мощности и точности ориентированы на датчик Android, а не на физические датчики, эти требования влияют на выбор физических датчиков. Например, требование к точности вектора вращения игры влияет на требуемую точность физического гироскопа. Производитель устройства должен установить требования к физическим датчикам.