Android源码分析:传感器系统

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分别对其标识和类型对采样值进行解释。

你可能感兴趣的:(Android源码)