На рисунке ниже представлен стек датчиков 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 уровня аппаратной абстракции датчиков (HAL) — это интерфейс между драйверами оборудования и фреймворком Android. Он состоит из одного интерфейса HAL, sensor.h, и одной реализации HAL, которую мы называем sensor.cpp.
Интерфейс определяется разработчиками Android и AOSP, а реализация предоставляется производителем устройства.
Интерфейс HAL датчика находится в hardware/libhardware/include/hardware . Подробнее см. в файле sensors.h .
Цикл выпуска
Реализация HAL определяет версию интерфейса HAL, которую она реализует, устанавливая параметр your_poll_device.common.version . Существующие версии интерфейса HAL определены в файле sensors.h, и функциональность привязана к этим версиям.
В настоящее время фреймворк Android поддерживает версии 1.0 и 1.3, но поддержка версии 1.0 скоро прекратится. В этой документации описывается поведение версии 1.3, до которой следует обновить все устройства. Подробнее об обновлении до версии 1.3 см. в разделе «Устаревание версии HAL» .
Драйвер ядра
Драйверы датчиков взаимодействуют с физическими устройствами. В некоторых случаях реализация HAL и драйверы представляют собой одно и то же программное обеспечение. В других случаях интегратор оборудования запрашивает драйверы у производителей чипов датчиков, но они сами разрабатывают реализацию HAL.
Во всех случаях реализация HAL и драйверы ядра являются ответственностью производителей оборудования, и Android не предоставляет предпочтительных подходов к их написанию.
Сенсорный концентратор
Стек датчиков устройства может опционально включать концентратор датчиков, полезный для выполнения низкоуровневых вычислений при низком энергопотреблении, пока система на кристалле находится в режиме ожидания. Например, на этих чипах можно выполнять подсчёт шагов или объединение сигналов датчиков. Это также хорошее место для реализации пакетной обработки данных датчиков, добавляя аппаратные FIFO для событий датчиков. Подробнее см. в разделе «Пакетная обработка» .
Примечание: для разработки новых функций ContextHub, использующих новые датчики или светодиоды, вы также можете использовать Neonkey SensorHub , подключенный к плате разработки Hikey или Hikey960.
Реализация концентратора датчиков зависит от архитектуры. Иногда он представляет собой отдельный чип, а иногда встроен в тот же чип, что и система на кристалле (SoC). Важными характеристиками концентратора датчиков являются достаточный объём памяти для пакетной обработки и минимальное энергопотребление для реализации маломощных датчиков Android. Некоторые концентраторы датчиков содержат микроконтроллер для универсальных вычислений и аппаратные ускорители, обеспечивающие очень низкое энергопотребление для маломощных датчиков.
Архитектура сенсорного концентратора и то, как он взаимодействует с датчиками и SoC (шина I2C, шина SPI и т. д.), в Android не оговорены, но они должны быть направлены на минимизацию общего энергопотребления.
Одним из вариантов, который, по-видимому, оказывает существенное влияние на простоту реализации, является наличие двух линий прерываний, идущих от концентратора датчиков к SoC: одна для прерываний пробуждения (для пробуждающихся датчиков), а другая для прерываний без пробуждения (для не пробуждающихся датчиков).
Датчики
Это физические микросхемы МЭМ, выполняющие измерения. Во многих случаях на одном чипе размещено несколько физических датчиков. Например, некоторые чипы включают в себя акселерометр, гироскоп и магнитометр. (Такие чипы часто называют 9-осевыми чипами, поскольку каждый датчик предоставляет данные по трём осям.)
Некоторые из этих чипов также содержат некоторую логику для выполнения обычных вычислений, таких как обнаружение движения, обнаружение шагов и объединение данных 9-осевых датчиков.
Хотя требования и рекомендации CDD по мощности и точности касаются сенсора Android, а не физических датчиков, эти требования влияют на выбор физических датчиков. Например, требование к точности вектора вращения в игре влияет на требуемую точность физического гироскопа. Производитель устройства самостоятельно определяет требования к физическим датчикам.