На рисунке ниже представлена структура сенсорного стека Android. Каждый компонент взаимодействует только с компонентами, расположенными непосредственно над и под ним, хотя некоторые датчики могут обходить центральный блок датчиков, если он присутствует. Управление осуществляется от приложений к датчикам, а данные передаются от датчиков к приложениям.
Рисунок 1. Слои стека датчиков Android и их соответствующие владельцы.
SDK
Приложения получают доступ к датчикам через API комплекта разработки программного обеспечения (SDK) для датчиков . 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 для получения доступа к сервисам, специфичным для датчиков.
Binder IPC
Прокси-серверы Binder IPC обеспечивают обмен данными через границы процессов.
ХАЛ
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-чипы, осуществляющие измерения. Во многих случаях на одном чипе присутствует несколько физических датчиков. Например, некоторые чипы включают акселерометр, гироскоп и магнитометр. (Такие чипы часто называют 9-осевыми, поскольку каждый датчик предоставляет данные по 3 осям.)
Некоторые из этих микросхем также содержат логику для выполнения обычных вычислений, таких как обнаружение движения, обнаружение шагов и объединение данных с 9-осевых датчиков.
Хотя требования и рекомендации CDD по энергопотреблению и точности ориентированы на датчики Android, а не на физические датчики, эти требования влияют на выбор физических датчиков. Например, требование к точности вектора вращения в игре влияет на требуемую точность физического гироскопа. Определение требований к физическим датчикам является задачей производителя устройства.