Sensor stack (传感器软件堆栈架构)

下图呈现的是Android传感器的软件堆栈架构。每一层只和与之相邻的上层或下层交互，然而某些传感器是可以直接穿透sensor hub这一层的。控制流自上而下由Applications层传送至底层的硬件Sensors层，而数据流则自下而上由硬件Sensors层传送到Applications层。

Figure 1. Layers of the Android sensor stack andtheir respective owners软件堆栈架构各层及其各自的属主

SDK(应用程序开发包，给应用程序提供一系列API)

---

应用程序对传感器的访问通过 Sensors SDK (SoftwareDevelopment Kit) API来完成。该SDK包含的功能包括列出所有的支持的传感器以及让应用程序注册一个传感器。

当注册一个传感器时，应用程序会指定一个优先采用的采样率参数和一个时延需求参数。

·                        举例而言，一个应用程序可能可能请求注册了一个加速计传感器，注册时该应用程序可能会要求事件的上报频率为100Hz，并且能够允许的事件最大上报时延为1秒。(注释：上报时延是针对批处理模式的，即每两次批处理上报的时间间隔)

·                        应用程序将会收到来自加速计传感器的以至少100Hz频率的事件，并且可能的最大时延上限为1秒。(解释：批处理模式下才有最大时延一说)

请参考 developer documentation 以获得关于SDK方面的更多信息。

Framework(框架层)

---

framework主要负责将诸多的应用程序连接到HAL层。HAL层本身是单客户端的结构。如果没有framework层的这种多路混合机制，那么对某个指定的Android传感器而言，在每个时刻将只能允许一个应用程序对其进行访问。

·                        当第一个应用程序请求注册某个Android传感器时，framework层会发送一个请求到HAL层来打开该传感器。

·                        当另外一个应用程序再次请求注册上述的同一个传感器时，framework层将会将该请求变为一个针对每个应用程序的计数需求并记录在案，同时会继续把该应用程序请求的参数(注释：新的采样频率和新的时延参数)发到HAL层。

o                                       实际的采样频率(sampling frequency)将会是所有注册该传感器的应用程序所要求的采样频率当中最大的一个，这意味着有些应用程序收的事件频率可能比自己所请求的频率要高。

o                                       实际的最大事件上报时延(maximum reportinglatency)将会是所有注册该传感器的应用程序所要求的事件上报时延当中最小的一个。如果某个应用程序请求的最大上报时延为0，那么无论其它应用程序对该传感器的时延请求参数是否非0，所有的应用程序都将以连续模式(continuemode)收到来自该传感器的上报事件。更多细节请参考Batching模式。

·                        当最后一个应用程序注销该传感器时，framework层才会发出一个请求到HAL层来关闭该传感器，此后，如果没有必要将不会耗电。(注释：言外之意就是在此之前的应用程序注销，都是仅仅在framework层对计数器进行递减)

Impact of multiplexing (多路混合的影响)

framework中的多路混合层解释了一些设计决策。

·                        当一个应用程序请求一个指定的采样频率时，是无法确保实际的采样频率不会大于它所请求的频率的。也就是说，如果另一个应用程序请求了同一个传感器且要求有更高的采样频率，那么第一个应用程序也会因此而以这个更高的采样频率收到数据。

·                        对于事件的最大上报时延请求也同样缺乏保证：应用程序收到事件的时延可能比它请求的时延要小很多。(解释：时延永远都是针对批处理模式中的两次相邻批次而言的)

·                        除了采样频率和最大上报时延两个参数外，对Android传感器而言，应用程序再无其他参数可配。

o                                       举个例子：假设某个物理传感器可以运行在“高精度”或“低功耗”模式。

o                                       那么这两个模式中将只可能有一个被实际的设备所采用。因为，如果一个应用程序可以请求“高精度”模式，而另一个应用程序可以请求“低功耗”模式，那么framework层就没有办法同时满足这两个应用程序，而framework必须能够永远满足自己的客户(应用程序)，因此这种需求无法实现。(注释：这个例子用于说明为什么framework层的传感器部分被设计成只能接受两个参数，而不能接受更多的参数。因为这个物理传感器不可能同时工作在“高精度”模式和“低功耗”模式，这两个模式显然是互斥的！)

·                        没有任何机制能够将数据从应用层向下发送至传感器驱动程序或者传感器本身。这可以确保任何应用程序都无法改变传感器自身的行为，从而不会因为一个应用程序的错误动作而殃及其它应用程序。

Sensor fusion (传感器融合)

Android的framework层默认实现了一些复合传感器。当某个设备拥有了陀螺仪(gyroscope)、加速计(accelerometer)以及磁力计(magnetometer)，但是却没有旋转向量传感器(rotation vector)、重力传感器(gravity)和线性加速度传感器(linear acceleration)时，framework层会默认实现这三个复合传感器，从而让应用层可以使用它们。

这个默认的实现没有像其它显式实现那样去访问所有的数据，而且这个默认实现必须运行于SoC，因此它既不像专门(显式)实现那样精确，也不像专门(显式)实现那样节省功耗。尽可能的情况下是由终端设备制造商定义他们自己的融合传感器(包括旋转矢量传感器、重力传感器、线性加速度传感器，以及新的复合传感器，如game rotation vector)而不是依赖该默认的实现。终端设备制造商也可以请求传感器芯片提供商提供这个实现。(注释：未确认的推测：如果没有显式实现这些融合传感器，传感器测试app列出的传感器列表中的上述三个复合传感器的制造商信息就会是Google Inc)

默认的融合传感器实现不被维护，这可能导致依赖这个默认实现的设备在CTS中测试失败。

Under the Hood (内幕)

本小节是为维护AOSP的framework层代码而提供的背景信息，这些内容和硬件无关。

JNI

framework会使用JNI来关联到android.hardware (位于frameworks/base/core/jni/ 目录)。这部分代码会调用更下层的原生代码来获得对传感器硬件的访问。

Native framework

native framework 定义在 frameworks/native/ 目录，并且提供一个原生的等同于android.hardware 的功能. native framework 会调用 Binder IPC协议来获得对传感器特定服务的访问。

Binder IPC

Binder IPC协议使得进程间的通讯更加便捷

HAL(硬件抽象层)

---

硬件抽象层(HAL)接口介于硬件驱动和Android framework层之间。它包含一个位于sensors.h中的HAL层接口的定义以及一个具体的HAL层实现代码，也就是我们说的sensors.cpp

该接口由Android和AOSP的贡献者来定义，而具体的实现则由设备制造商提供。

传感器的 HAL层接口位于 hardware/libhardware/include/hardware。请参考sensors.h 来获取更多细节信息。

Release cycle (版本发布周期)

HAL层的实现通过设置your_poll_device.common.version来指定它所实现的HAL层接口的版本。现存的HAL层接口的版本信息均定义在sensors.h中，而具体的功能是和这些版本号绑定的。

当前的Androidframework层支持1.0和1.3两个版本的HAL层接口，但是1.0版本不久后将不再被支持。本文档描述的是1.3版本的功能，基于此的所有设备都应当更新其HAL层接口实现。关于如何升级到1.3版本的细节，请参考HAL version deprecation。

Kerneldriver (驱动层)

---

传感器驱动程序直接和物理设备进行交互。在某些情况下，HAL层的实现和驱动程序是同一个软件实体。在另一些情况下，硬件集成者会要求传感器芯片供应商提供他们的驱动代码，而HAL层的实现则由这些硬件集成者自己来完成。

无论何种情况，HAL层的实现和驱动的实现都是设备制造商的职责所在，而Android从不提供实现它们的首选方式。

Sensorhub

---

一个设备的传感器软硬件堆栈架构设计中针对Sensor hub的这一层是可选项，Sensor hub对于一些低功耗模式下(这种模式下SoC可以休眠)的小量运算执行会有用。比如，计步器算法或者传感器融合算法可以在这些Sensor hub芯片上执行。对于实现传感器的批处理模式以及实现为传感器事件添加硬件缓冲区来说，Sensor hub上也是个很好的实现位置。请参考Batching来获取更多信息。

Sensor hub硬件的具体实现依赖于实际的系统架构。有时它可能以一个独立的外部芯片出现，而有时它可能被集成在SoC内部。Sensor hub的显著特征就是它应当包含足够的用于批处理模式的内存(FIFO缓冲区)，并且它应该在极低的功耗下实现低功耗的Android传感器。有些Sensor hub会使用一个微控制器来进行通用运算，同时会使用一个硬件加速计为低功耗的传感器来使能超低功耗运算机制。(注释：推测：加速计是所有物理传感器中功耗最低的器件，并且它本身也能感知用户运动状态的变化，因此加速计会被永远开启，并且会由加速计来决定是否启动Sensor hub的其他功能。比如在某些静止状态下，甚至可以让Sensor hub本身进入休眠，而仅在加速计检测到非静止时才由加速计唤醒Sensor hub)

Android并不关心Sensor hub自身的软硬件架构实现，也不关心Sensor hub是如何与物理传感器以及SoC进行交互的(如采用I2C或者SPI等通讯方式)，但是Sensor hub必须以最小化整体功耗为目的。

一个可选的似乎有重大影响的简单实现就是让Sensor hub拥有两个接入SoC的中断线：一个可以唤醒SoC的中断(用于那些具备唤醒功能的Android传感器),一个不能唤醒SoC的中断(用于那些不具备唤醒功能的Android传感器)。

Sensors(物理传感器)

---

这里描述的都是物理上采用MEMS(微机械加工)技术进行测量的传感器。多数情况下，单个芯片上可能会包含多个物理传感器。比如，有些芯片会同时包含一个加速计、一个陀螺仪和一个磁力计。(这被叫做9轴芯片，因为每个传感器都能提供3个轴向的数据)

这些芯片内部可能会同时包含一些逻辑单元来执行一些常见的算法，如：运动监测、计步器、以及9轴融合算法。(注释：简单的算法如运动监测可以由硬件逻辑单元来实现，但是复杂的算法就需要由软件来实现了，很多时候这样的单芯片9轴方案其内部都会有一个微控制器来运行数据融合算法，其实这样的方案自身已经很近似Sensor hub架构了)

虽然CDD(CompatibilityDefinition Document)对功耗和精度的要求和推荐建议是针对Android传感器而不是物理传感器的，但是这些需求会影响到对物理传感器的选择。比如，在gamerotation vector中对精度的需求便暗示出对物理陀螺仪的精度需求。对物理传感器的需求和选择最终由终端制造商决定。