Sensors in Android
总述
如下图，应用程序开发者使用几个sensor的几个API类进行应用程序的开发。Java的部分的API使用C/C++来实现，也就是调用到JNI层。左侧运行于应用程序的进程空间，右侧运行于system server进程空间。双方通过ISensorEventConnection/SensorChannel进行通讯。SensorService负责与Sensors的硬件适配层HAL进行通讯，后者与驱动和硬件进行交互。
Java API
Java层的API类有SensorManager，利用它才可以使用系统的各种感应器（sensor）。sensor的采样值、精确度、时间戳以及信息是自哪个感应器等信息封装在Java类SensorEvent中。Java类Sensor代表一个感应器，包含感应器的各种信息，它的成员数据与本地Sensor类以及HAL层的sensor_t对应（见后述章节）。作为父类的SensorEventListener是一个监听器接口，应用开发者编写它的一个子类可以实现对SensorEvent的监听并做出相应反应。
在获取sensor service创建SensorManager时，会创建一个线程去轮询（poll，调用sensors_data_poll）去取sensor的数据，然后以发送消息的形式将SensorEvent发送给ListenerDelegate中的Handler，由handler在新一轮的线程循环中调用对应的sensorListener进行处理。
JNI与native层
JNI层位于frameworks/base/core/jni/下面，主要就是一个文件android_hardware_SensorManager.cpp。它使用的类如Sensor、SensorChannel、SensorEventQueue、、ISensorEventConnection和ISensorServer则放在libgui.so中，见目录frameworks/base/libs/gui。
Java层在轮询之前，必须调用sensors_create_queue创建（见SensorThreadRunnable的open函数）一个本地的SensorEventQueue队列，这个C++对象的指针被转换为int型后保存为SensorManager的静态成员变量sQueue。当轮询时，将该队列传递给JNI层的sensors_data_poll，用于从该队列中读取Event数据（具体数据类型是ASensorEvent）。
本地SensorEventQueue类主要借助于两个类进行工作。一是封装了管道的SensorChannel类，event的读取和写入都是针对封装的管道进行的；二是libutils库中的Looper类，Looper类实现了在调用者线程中对文件描述符的轮询（内部使用的epoll），甚至可以注册回调函数，当有文件描述符对应的文件有数据到达时使用回调函数进行处理。这样，队列类SensorEventQueue使用Looper监听着管道对应的描述符，当有数据达到时，就可以读取，没有使用回调机制。整个过程是：在Java层的SensorManager的线程中不断调用sensors_data_poll查询数据，这导致其JNI层的native实现在队列上等待event事件（见队列的成员函数waitForEvent，它使用poll进行轮询），也就是说，直到有管道中有数据可用才返回。当没有发生错误返回时，表示有数据可读，然后对数据进行读取。一次读取单位为一个event。
下面是JNI层中的sensors_data_poll代码片段：
res = queue->read(&event, 1);
if (res == -EAGAIN) {
res = queue->waitForEvent();//等待有数据可读取
if (res != NO_ERROR)//检查是否发生错误
return -1;
res = queue->read(&event, 1);//没错误，进行数据读取
}
封装管道的SensorChannel类的对象由ISensorEventConnection接口获取。另外，对sensor的激活/去激活也是通过ISensorEventConnection调用到server侧的SensorService完成的。
C++类Sensor代表了一个sensor，它是HAL层sensor_t的封装，同时又为Java层的Sensor类中的数据成员变量提供数据"源"，也就是说，Java中的Sensor的成员变量信息是由该C++中的Sensor类设置，后者又是根据sensor_t而获取对应的sensor信息。Java中的Sensor是应用开发的API类。在C++中的Sensor类中定义了sensor的枚举类型：
enum {
TYPE_ACCELEROMETER = ASENSOR_TYPE_ACCELEROMETER, //加速度
TYPE_MAGNETIC_FIELD = ASENSOR_TYPE_MAGNETIC_FIELD, //磁场
TYPE_GYROSCOPE = ASENSOR_TYPE_GYROSCOPE, //陀螺仪
TYPE_LIGHT = ASENSOR_TYPE_LIGHT, //光传感器
TYPE_PROXIMITY = ASENSOR_TYPE_PROXIMITY //距离传感器
};
SensorService
在frameworks/base/services/sensorservice/下面给出sensorService的相关实现代码，它们最终生成libsensorservice.so库文件，作为service被注册到system server后，最终运行于system_server后台进程空间。
Sensor service模块的核心部分是SensorService类。另外还定义了几个逻辑上的虚拟sensor：GravitySensor、LinearAccelerationSensor和RotationVectorSensor，它们的接口由抽象类SensorInterface定义，物理意义上实际传感器HardwareSensor也同样遵循该接口规范。
SensorInterface与四个子类继承关系图如下：
SensorInterface是个抽象类，定义了五个接口：
virtual bool process(sensors_event_t* outEvent,const sensors_event_t& event) = 0; //处理原始数据，换成上层应用希望得到的数据
virtual status_t activate(void* ident, bool enabled) = 0; //激活与去激活
virtual sttus_t setDelay(void* ident, int handle, int64_t ns) = 0;//设置报告处理频率
virtual Sensor getSensor() const = 0;//获取对应的sensor
virtual bool isVirtual() const = 0;//是否为虚拟的，即是否为逻辑（虚拟）传感器
GravitySensor和LinearAccelerationSensor，它们不是物理意义上的传感器，只是逻辑意义上的传感器，可称之为虚拟（virtual）传感器。它们实际上是将加速器（即gsensor）的值经过处理过滤后再上报。
RotationVectorSensor方向向量传感器，实际上它由加速器和磁场传感器(compass)组成，根据它们上报的值来判断是否旋转屏幕。
引入虚拟传感器的目的是方便上层程序的处理。在上层看来，它不需要关注设备上的传感器的某些原始数据，只需要经过加工处理后的数据，如是否旋转屏幕，它是依据虚拟的"传感器"sensorRotationVectorSensor得来的经过加工后的数据。这些虚拟传感器包含了处理原始数据的算法。算法包含在重载的process函数中。
HardwareSensor代表了真正的传感器，它继承自SensorInterface，实现了各个抽象接口，但其实现是借助于与位于下层的HAL层的sensor硬件模块打交道的类SensorDevice来完成的。
SensorDevice与HAL中的libsensors.so打交道，如获取对应的硬件module，打开sensor设备，参见其构造函数：
SensorDevice::SensorDevice()
: mSensorDevice(0),
mSensorModule(0)
{
status_t err = hw_get_module(SENSORS_HARDWARE_MODULE_ID,
(hw_module_t const**)&mSensorModule);//打开sensor硬件模块
LOGE_IF(err, "couldn‘t load %s module (%s)",
SENSORS_HARDWARE_MODULE_ID, strerror(-err));
if (mSensorModule) {
err = sensors_open(&mSensorModule->common, &mSensorDevice);//打开HAL层的poll设备
LOGE_IF(err, "couldn‘t open device for module %s (%s)",
SENSORS_HARDWARE_MODULE_ID, strerror(-err));
if (mSensorDevice) {
sensor_t const* list;
ssize_t count = mSensorModule->get_sensors_list(mSensorModule, &list);//获取sensor_t列表
mActivationCount.setCapacity(count);
Info model;
for (size_t i=0 ; i<size_t(count) ; i++) {
mActivationCount.add(list[i].handle, model);
mSensorDevice->activate(mSensorDevice, list[i].handle, 0);
}
}
}
}
其结构图如下：
作为核心代码的SensorService类有三个父类：
BinderService<SensorService>：继承该父类使其成为一个标准的本地（native） service，将自己添加到系统的system server中去，其它感兴趣者可以使用该service。
BnSensorServer：意味着作为子类，SensorService是抽象类ISensorServer中定义的两个接口（getSensorList和createSensorEventConnection）的server侧的真正实现者。一个接口是用来获取系统的sensor列表，另一个则是创建一个事件连接（EventConnection），用于基于管道加上轮询方式的event传输。
Thread：意味着它也是一个线程类，在SensorService创建后，有个单独的线程去执行重载的threadLoop。
这个threadLoop可以说是整个sensor的调度处理中心，让sensor相关的模块都动起来。作为一个后台线程，它是个无限循环，不断去处理
bool SensorService::threadLoop()
{
LOGD("nuSensorService thread starting…");
const size_t numEventMax = 16 * (1 + mVirtualSensorList.size());
sensors_event_t buffer[numEventMax];
sensors_event_t scratch[numEventMax];
SensorDevice& device(SensorDevice::getInstance());
const size_t vcount = mVirtualSensorList.size();
ssize_t count;
do {
count = device.poll(buffer, numEventMax);//轮询event数据到缓冲区
if (count<0) {
LOGE("sensor poll failed (%s)", strerror(-count));
break;
}
recordLastValue(buffer, count);//记录每个sensor最新的值，记入到mLastEventSeen这个KeyedVector（从sensor标识符到sensors_event_t的映射）中。
// handle virtual sensors
if (count && vcount) {//下面是处理虚拟sensors数据
const DefaultKeyedVector<int, SensorInterface*> virtualSensors( getActiveVirtualSensors());
const size_t activeVirtualSensorCount = virtualSensors.size();
if (activeVirtualSensorCount) {
size_t k = 0;
for (size_t i=0 ; i<size_t(count) ; i++) {
sensors_event_t const * const event = buffer;
for (size_t j=0 ; j<activeVirtualSensorCount ; j++) {
sensors_event_t out;
if (virtualSensors.valueAt(j)->process(&out, event[i])) {//处理原始数据，经过处理转换后的数据信息保存在out这个event中
buffer[count + k] = out;//将它们添加到buffer中
k++;
}
}
}
if (k) {
// record the last synthesized values
recordLastValue(&buffer[count], k);//同样对虚拟的sensor的event最新值添加到mLastEventSeen中
count += k;
// sort the buffer by time-stamps
sortEventBuffer(buffer, count);//按时间戳排序
}
}
}
// send our events to clients…
const SortedVector< wp<SensorEventConnection> > activeConnections(
getActiveConnections());
size_t numConnections = activeConnections.size();
for (size_t i=0 ; i<numConnections ; i++) {
sp<SensorEventConnection> connection(
activeConnections[i].promote());
if (connection != 0) {
connection->sendEvents(buffer, count, scratch);//发送给client端，实际是写入管道
}
}
} while (count >= 0 || Thread::exitPending());
LOGW("Exiting SensorService::threadLoop!");
return false;
}
因此，可以看出，SensorService的工作线程不断去轮询设备中是否有数据可用。当有数据可用时，将它们写入管道。对方的应用程序中的线程也不断轮询管道，当有数据时，便调用对应的listener进行处理。它们工作在不断的线程中，或使用looper，或使用handler，在不同的线程循环中进行处理，多次的异步操作构成了sensor的处理过程。
HAL
在Android HAL中只对sensors的数据结构进行了定义（见头文件hardware/libhardware/include/hardware/sensors.h），其具体实现应由芯片厂家给出。
在使用sensors的HAL时，首先使用HAL提供的hw_get_module函数，根据其模块ID字符串（SENSORS_HARDWARE_MODULE_ID）获取硬件模块sensors_module_t，然后借助于sensors_module_t枚举中设备中所带的所有sensors（sensor由结构体sensor_t定义）列表。
数据结构sensors_module_t定义了sensors硬件模块，其中的get_sensors_list函数指针用于枚举设备上的各种类型的sensor，实现由平台厂商给出。
同样，可以接着使用API函数sensors_open打开HAL中定义的sensors_poll_device_t类型的设备，该结构体定义三个API，用于激活/去激活sensor（见成员activate函数指针）、设置数据报告频率（见setDelay函数指针）和轮训（见poll函数指针）。同样，这三个函数也由平台厂家实现。
这样，我们可以使用hw_get_module函数打开硬件模块，并得到sensors列表，同时，也可以使用sensors_open打开sensors_poll_device_t类型的设备，对sensor进行激活/去激活，轮询读数和设置数据报告频率等基本操作。
结构体sensor_t代表了一个sensor，定义了sensor的各种属性，如：名称、厂家、版本、句柄、类型、最大值范围、解析度、功耗、数据上报频率等。其定义具体如下：
struct sensor_t {
/* name of this sensors */
const char* name;//sensor的名称
/* vendor of the hardware part */
const char* vendor;//厂家
/* version of the hardware part + driver. The value of this field is
* left to the implementation and doesn‘t have to be monotonically
* increasing.
*/
int version;//版本
/* handle that identifies this sensors. This handle is used to activate
* and deactivate this sensor. The value of the handle must be 8 bits
* in this version of the API.
*/
int handle;//句柄，用于标识是激活/去激活哪个sensor，亦即sensors_event_t中的int32_t sensor;它实际是由四个字符的ascii码值来填充
/* this sensor‘s type. */
int type;//sensor类型，在sensor.h中定义了多达12种类型（有的为逻辑上的sensor），并以注释的方式对它们进行了详细解释
/* maximaum range of this sensor‘s value in SI units */
float maxRange;//最大取值范围
/* smallest difference between two values reported by this sensor */
float resolution;//解析度
/* rough estimate of this sensor‘s power consumption in mA */
float power;//估计的功耗，单位为mA
/* minimum delay allowed between events in microseconds. A value of zero means that this sensor doesn‘t report events at a constant rate, but rather only when a new data is available */
int32_t minDelay;//报告读数值的events时间间隔（单位：ms），若为0，意味着不按该频率报告，而是数据到来时才报告
/* reserved fields, must be zero */
void* reserved[8];//保留
};
sensor的采样值的上报可以按照某个固定的频率进行上报，也可以当有可用的数据时再上报（minDelay设为0）。上报数据以event的形式进行，见结构体sensors_event_t，它包含了sensor的标识符、类型、数据采样时间戳以及采样数据。因为各种sensor的采样值各式各样，它更多地是用联合体union来定义，根据不同的sensor来解释返回的值，比如，当是加速器sensor或磁场sensor时，就分别取联合体中的acceleration和magnetic两个字段，它们的类型是结构体sensors_vec_t，其中又包含有union联合体。这样，Android将各种sensor统一成一种接口，依据不同的sensor分别对其标识和类型对采样值进行解释。