传感器堆栈

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

下图表示 Android 传感器堆栈。每个组件仅与直接位于其上方和下方的组件进行通信,尽管某些传感器在存在传感器集线器时可以绕过它。控制从应用程序流向传感器,数据从传感器流向应用程序。

Android 传感器堆栈的层和所有者

图 1. Android 传感器堆栈的各层及其各自的所有者

SDK

应用程序通过Sensors SDK(软件开发工具包)API访问传感器。 SDK 包含列出可用传感器和注册到传感器的功能。

注册到传感器时,应用程序会指定其首选的采样频率和延迟要求。

  • 例如,应用程序可能会注册到默认加速度计,以 100Hz 的频率请求事件,并允许以 1 秒的延迟报告事件。
  • 应用程序将以至少 100Hz 的速率从加速度计接收事件,并且可能延迟最多 1 秒。

有关 SDK 的更多信息,请参阅开发人员文档

框架

该框架负责将多个应用程序链接到HAL 。 HAL 本身是单客户端。如果没有在框架级别发生这种多路复用,那么在任何给定时间只有一个应用程序可以访问每个传感器。

  • 当第一个应用程序注册到传感器时,框架向 HAL 发送请求以激活传感器。
  • 当其他应用程序注册到同一个传感器时,框架会考虑每个应用程序的要求,并将更新后的请求参数发送到 HAL。
    • 采样频率将是请求的采样频率的最大值,这意味着某些应用程序将以高于其请求的频率接收事件。
    • 最大报告延迟将是请求延迟中的最小值。如果一个应用程序请求一个最大报告延迟为 0 的传感器,则所有应用程序都将以连续模式从该传感器接收事件,即使某些应用程序请求一个最大报告延迟不为零的传感器。有关详细信息,请参阅批处理
  • 当最后一个注册到一个传感器的应用程序从其中注销时,框架会向 HAL 发送请求以停用传感器,以免不必要地消耗电力。

多路复用的影响

框架中对多路复用层的需求解释了一些设计决策。

  • 当应用程序请求特定的采样频率时,不能保证事件不会以更快的速度到达。如果另一个应用程序以更快的速度请求相同的传感器,第一个应用程序也将以更快的速度接收它们。
  • 同样缺乏保证适用于请求的最大报告延迟:应用程序接收事件的延迟可能比他们请求的要少得多。
  • 除了采样频率和最大报告延迟外,应用程序无法配置传感器参数。
    • 例如,想象一个可以在“高精度”和“低功耗”模式下运行的物理传感器。
    • 在 Android 设备上只能使用这两种模式中的一种,否则应用程序可能会请求高精度模式,而另一种模式可能会请求低功耗模式;该框架无法同时满足这两个应用程序。该框架必须始终能够满足其所有客户,因此这不是一种选择。
  • 没有将数据从应用程序向下发送到传感器或其驱动程序的机制。这确保了一个应用程序不能修改传感器的行为,从而破坏其他应用程序。

传感器融合

Android 框架为某些复合传感器提供了默认实现。当设备上存在陀螺仪加速度计磁力计,但没有旋转矢量重力线性加速度传感器时,框架会实现这些传感器,因此应用程序仍然可以使用它们。

默认实现无法访问其他实现可以访问的所有数据,并且它必须在 SoC 上运行,因此它不像其他实现那样准确和省电。设备制造商应尽可能定义自己的融合传感器(旋转矢量、重力和线性加速度,以及较新的复合传感器,如游戏旋转矢量),而不是依赖此默认实现。设备制造商还可以要求传感器芯片供应商为其提供实施方案。

默认传感器融合实现未得到维护,可能会导致依赖它的设备无法通过 CTS。

引擎盖下

本部分作为背景信息提供给那些维护 Android 开源项目 (AOSP) 框架代码的人员。它与硬件制造商无关。

JNI

该框架使用与android.hardware关联并位于frameworks/base/core/jni/目录中的 Java Native Interface (JNI)。此代码调用较低级别的本机代码以获取对传感器硬件的访问权限。

原生框架

本机框架在frameworks/native/中定义,并提供与android.hardware包等效的本机。本机框架调用 Binder IPC 代理来获取对传感器特定服务的访问。

粘合剂工控机

Binder IPC 代理促进跨进程边界的通信。

哈尔

Sensors 硬件抽象层 (HAL) API 是硬件驱动程序和 Android 框架之间的接口。它由一个 HAL 接口sensors.h 和一个HAL 实现组成,我们称之为sensors.cpp。

该接口由 Android 和 AOSP 贡献者定义,实现由设备制造商提供。

传感器 HAL 接口位于hardware/libhardware/include/hardware中。有关更多详细信息,请参见sensors.h

发布周期

HAL 实现通过设置your_poll_device.common.version来指定它实现的 HAL 接口的版本。现有的 HAL 接口版本在sensors.h 中定义,并且功能与这些版本相关联。

Android 框架目前支持 1.0 和 1.3 版本,但很快将不再支持 1.0。本文档描述了版本 1.3 的行为,所有设备都应升级到该版本。有关如何升级到 1.3 的详细信息,请参阅HAL 版本弃用

内核驱动程序

传感器驱动程序与物理设备交互。在某些情况下,HAL 实现和驱动程序是同一个软件实体。在其他情况下,硬件集成商要求传感器芯片制造商提供驱动程序,但他们是编写 HAL 实现的人。

在所有情况下,HAL 实现和内核驱动程序都是硬件制造商的责任,Android 不提供编写它们的首选方法。

传感器集线器

设备的传感器堆栈可以选择包括传感器集线器,这对于在 SoC 可以处于挂起模式时以低功耗执行一些低级计算很有用。例如,可以在这些芯片上执行计步或传感器融合。它也是实现传感器批处理的好地方,为传感器事件添加硬件 FIFO。有关详细信息,请参阅批处理

注意:要开发使用新传感器或 LED 的新 ContextHub 功能,您还可以使用连接到Hikey或 Hikey960 开发板的 Neonkey SensorHub。

传感器集线器的具体实现方式取决于架构。它有时是一个单独的芯片,有时包含在与 SoC 相同的芯片上。传感器集线器的重要特征是它应该包含足够的内存用于批处理,并且消耗很少的功率来实现低功耗 Android 传感器。一些传感器集线器包含用于通用计算的微控制器和硬件加速器,可为低功耗传感器启用极低功耗计算。

Android 未指定传感器集线器的架构以及它如何与传感器和 SoC(I2C 总线、SPI 总线等)通信,但它应该旨在最大限度地减少整体功耗。

似乎对实现简单性有重大影响的一种选择是从传感器集线器到 SoC 有两条中断线:一条用于唤醒中断(用于唤醒传感器),另一条用于非唤醒中断(对于非唤醒传感器)。

传感器

这些是进行测量的物理 MEMS 芯片。在许多情况下,多个物理传感器存在于同一芯片上。例如,一些芯片包括加速度计、陀螺仪和磁力计。 (这种芯片通常被称为 9 轴芯片,因为每个传感器都提供 3 个轴上的数据。)

其中一些芯片还包含一些逻辑来执行常见的计算,例如运动检测、步数检测和 9 轴传感器融合。

尽管 CDD 功率和精度要求和建议针对的是 Android 传感器而不是物理传感器,但这些要求会影响物理传感器的选择。例如,游戏旋转矢量的精度要求会影响物理陀螺仪所需的精度。由设备制造商决定对物理传感器的要求。