На рисунке ниже показан стек датчиков Android. Каждый компонент взаимодействует только с компонентами, расположенными непосредственно над ним и под ним, хотя некоторые датчики могут обходить центр датчиков, если он присутствует. Управление осуществляется от приложений к датчикам, а данные передаются от датчиков к приложениям.
Рисунок 1. Уровни стека датчиков Android и их владельцы
SDK
Приложения получают доступ к датчикам через API Sensors SDK (пакет средств разработки). SDK содержит функции для получения списка доступных датчиков и регистрации датчика.
При регистрации датчика приложение указывает предпочтительную частоту дискретизации и требования к задержке.
- Например, приложение может зарегистрироваться в акселерометре по умолчанию, запросить события с частотой 100 Гц и разрешить передавать события с задержкой в одну секунду.
- Приложение будет получать события от акселерометра с частотой не менее 100 Гц и возможной задержкой до 1 секунды.
Дополнительную информацию об SDK можно найти в документации для разработчиков.
Framework
Фреймворк отвечает за связь между приложениями и HAL. Сам HAL предназначен для одного клиента. Без мультиплексирования на уровне фреймворка доступ к каждому датчику в любой момент времени может иметь только одно приложение.
- Когда первое приложение регистрируется для датчика, фреймворк отправляет запрос в HAL, чтобы активировать датчик.
- Когда дополнительные приложения регистрируются в том же датчике, фреймворк учитывает требования каждого приложения и отправляет обновленные запрошенные параметры в HAL.
- Частота выборки будет равна максимальной из запрошенных частот, то есть некоторые приложения будут получать события чаще, чем они запрашивали.
- Максимальная задержка отчетов будет минимальной из запрошенных. Если одно приложение запросит датчик с максимальной задержкой передачи данных, равной нулю, все приложения будут получать события от этого датчика в непрерывном режиме, даже если некоторые из них запросили датчик с ненулевой максимальной задержкой передачи данных. Подробнее о пакетной обработке…
- Когда последнее приложение, зарегистрированное для определенного датчика, отменяет регистрацию, фреймворк отправляет в HAL запрос на деактивацию датчика, чтобы не расходовать энергию без необходимости.
Влияние мультиплексирования
Необходимость в уровне мультиплексирования в фреймворке объясняет некоторые проектные решения.
- Если приложение запрашивает определенную частоту выборки, нет гарантии, что события не будут поступать быстрее. Если другое приложение запросило тот же датчик с более высокой частотой, первое приложение также будет получать данные с этой частотой.
- То же самое касается и максимальной задержки, указанной в запросе: приложения могут получать события с гораздо меньшей задержкой.
- Приложения не могут настраивать параметры датчиков, кроме частоты выборки и максимальной задержки отчетов.
- Например, представьте себе физический датчик, который может работать в режиме высокой точности и в режиме низкого энергопотребления.
- На устройстве Android можно использовать только один из этих двух режимов, поскольку в противном случае одно приложение может запросить режим высокой точности, а другое – режим экономии энергии, и фреймворк не сможет удовлетворить оба приложения. Фреймворк всегда должен быть в состоянии удовлетворить все запросы клиентов, поэтому этот вариант не подходит.
- Механизм отправки данных из приложений на датчики или в их драйверы отсутствует. Это гарантирует, что одно приложение не сможет изменить поведение датчиков и нарушить работу других приложений.
Объединение данных датчиков
В Android Framework реализована поддержка некоторых составных датчиков. Если на устройстве есть гироскоп, акселерометр и магнитометр, но нет датчиков вектора поворота, гравитации и линейного ускорения, платформа реализует эти датчики, чтобы приложения могли их использовать.
Реализация по умолчанию не имеет доступа ко всем данным, доступным другим реализациям, и должна выполняться на SoC, поэтому она не так точна и энергоэффективна, как другие реализации. По возможности производителям устройств следует определять собственные комбинированные датчики (вектор поворота, гравитации и линейного ускорения, а также более новые комбинированные датчики, такие как вектор поворота для игр), а не полагаться на реализацию по умолчанию. Производители устройств также могут запросить реализацию у поставщиков чипов датчиков.
Реализация объединения датчиков по умолчанию не поддерживается и может привести к тому, что устройства, использующие ее, не пройдут CTS.
Расширенные
Этот раздел содержит справочную информацию для тех, кто поддерживает код фреймворка Android Open Source Project (AOSP). Она не относится к производителям оборудования.
JNI
Фреймворк использует Java Native Interface (JNI), связанный с android.hardware и расположенный в каталоге frameworks/base/core/jni/. Этот код вызывает собственный код более низкого уровня, чтобы получить доступ к аппаратной части датчика.
Нативный фреймворк
Нативный фреймворк определен в frameworks/native/ и предоставляет нативный эквивалент пакету android.hardware. Встроенная платформа вызывает прокси-серверы Binder IPC, чтобы получить доступ к сервисам, связанным с датчиками.
Binder IPC
Прокси-серверы Binder IPC обеспечивают связь между процессами.
HAL
API уровня абстракции оборудования (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 определены в файле sensors.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: одна для прерываний пробуждения (для датчиков пробуждения), а другая для прерываний без пробуждения (для датчиков без пробуждения).
Датчики
Это физические чипы MEMS, которые выполняют измерения. Во многих случаях на одном чипе присутствует несколько физических датчиков. Например, некоторые чипы включают акселерометр, гироскоп и магнитометр. (Такие чипы часто называют девятиосевыми, поскольку каждый датчик предоставляет данные по трем осям.)
Некоторые из этих чипов также содержат логику для выполнения обычных вычислений, таких как обнаружение движения, обнаружение шагов и объединение данных с девятиосевых датчиков.
Хотя требования к мощности и точности CDD и рекомендации относятся к датчику Android, а не к физическим датчикам, они влияют на выбор физических датчиков. Например, требование к точности вектора поворота игры влияет на необходимую точность физического гироскопа. Производитель устройства должен самостоятельно определить требования к физическим датчикам.