На рисунке ниже представлен стек датчиков 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 уровня абстракции оборудования датчиков (HAL) — это интерфейс между драйверами оборудования и платформой Android. Он состоит из одного интерфейса HAL Sensor.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: одна для прерываний пробуждения (для датчиков пробуждения), а другая для прерываний, не вызывающих пробуждение. (для датчиков без пробуждения).
Датчики
Это физические микросхемы MEM, выполняющие измерения. Во многих случаях на одном чипе присутствует несколько физических датчиков. Например, некоторые чипы включают в себя акселерометр, гироскоп и магнитометр. (Такие чипы часто называют 9-осными, поскольку каждый датчик передает данные по 3 осям.)
Некоторые из этих чипов также содержат некоторую логику для выполнения обычных вычислений, таких как обнаружение движения, обнаружение шагов и объединение 9-осевых датчиков.
Хотя требования и рекомендации CDD по мощности и точности ориентированы на датчик Android, а не на физические датчики, эти требования влияют на выбор физических датчиков. Например, требования к точности вектора вращения игры влияют на требуемую точность физического гироскопа. Производитель устройства должен определить требования к физическим датчикам.