Стек датчиков

На рисунке ниже представлен стек датчиков Android. Каждый компонент взаимодействует только с компонентами непосредственно над и под ним, хотя некоторые датчики могут обходить концентратор датчика, когда он присутствует. Управление передается от приложений к датчикам, а данные передаются от датчиков к приложениям.

Слои и владельцы стека датчиков 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 упрощают обмен данными через границы процессов.

HAL

API уровня абстракции оборудования датчиков (HAL) - это интерфейс между драйверами оборудования и платформой Android. Он состоит из одного интерфейса HAL sensor.h и одной реализации HAL, которую мы называем sensor.cpp.

Интерфейс определяется разработчиками Android и AOSP, а реализация предоставляется производителем устройства.

Интерфейс датчика HAL находится в hardware/libhardware/include/hardware . Дополнительную информацию см. В файле sensor.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, а не на физические датчики, эти требования влияют на выбор физических датчиков. Например, требование точности вектора вращения игры влияет на требуемую точность физического гироскопа. Изготовитель устройства определяет требования к физическим датчикам.