На рисунке ниже представлен стек датчиков 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 Native Interface (JNI), связанный с android.hardware и расположенный в каталоге frameworks/base/core/jni/ . Этот код вызывает собственный код нижнего уровня для получения доступа к оборудованию датчика.
Собственный фреймворк
Собственный фреймворк определен в frameworks/native/ и предоставляет собственный эквивалент пакета android.hardware . Собственный фреймворк вызывает прокси Binder IPC для получения доступа к службам, специфичным для датчиков.
Связующее 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: одна для прерываний пробуждения (для датчиков пробуждения), а другая для прерываний без пробуждения (для датчиков без пробуждения).
Датчики
Это физические чипы MEM, которые выполняют измерения. Во многих случаях на одном чипе присутствуют несколько физических датчиков. Например, некоторые чипы включают акселерометр, гироскоп и магнитометр. (Такие чипы часто называют 9-осевыми чипами, поскольку каждый датчик предоставляет данные по 3 осям.)
Некоторые из этих чипов также содержат некоторую логику для выполнения обычных вычислений, таких как обнаружение движения, обнаружение шагов и объединение 9-осевых датчиков.
Хотя требования и рекомендации CDD по мощности и точности нацелены на датчик Android, а не на физические датчики, эти требования влияют на выбор физических датчиков. Например, требование к точности вектора вращения игры влияет на требуемую точность для физического гироскопа. Производитель устройства должен вывести требования к физическим датчикам.