1.概览
??上一章提到过，SensorDevice如其名,用于管理Sensor的硬件操作,将SensorService和Sensor HAL很好的隔离开来。像Android这种需要大量人员同时维护的项目，通过适当的分层以及解耦让各个功能的开发可以并行进行，如此能提高开发效率和降低维的难度。
2.流程图
??先放上整体的流程图，方便查看。去掉了一些细枝末节的部分。
3.SensorHal的连接–connectHalService
??SensorService中的部分 HardwareSensor是依赖硬件sensor的，所以对SensorHal的调用是不可避免，既然这部分被SensorDevice所隔离，那么也就意味着 SensorDeivce 承当了这部分职责了。sensorHal是以HIDL-service的形式提供服务的，其为独立进程和 SensorService/SensorDeivce 不属于同一个进程，SensorService/SensorDeivce 实例则是位于system_server进程的线程中。这也意味着SensorService/SensorDeivce是无法直接调用sensorHal内部方法的。所以在使用HIDL-service前，则需通过hwservicemanager获取到sensorHal的HIDL-service句柄。
??在SensorDeivce中又使用类 HidlSensorHalWrapper 对使用sensorHal的操作进行了封装。下面先看看类图
?? SensorDeviceCallback 为ISensorHalWrapper的内部类，因为没找到UML类图中对内部类更好的表示，这里使用组合的关系去表示。
3.1 代码实现–new HidlSensorHalWrapper
//frameworks\native\services\sensorservice\SensorDevice.cpp
SensorDevice
connectHalService()
std::unique_ptr<ISensorHalWrapper> hidl_wrapper = std::make_unique<HidlSensorHalWrapper>();
hidl_wrapper->connect(this)
mHalWrapper = std::move(hidl_wrapper);
??最终HidlSensorHalWrapper的实例指针被存储于 mHalWrapper 中，其定义如下
//file://frameworks\native\services\sensorservice\SensorDevice.h
class SensorDevice : ...{
private:
std::unique_ptr<ISensorHalWrapper> mHalWrapper;
}
3.2 代码实现–HidlSensorHalWrapper->connect
??connect的方法是继承自类 ISensorHalWrapper，下面是它的定义
/**
* A wrapper for various types of HAL implementation, e.g. to distinguish HIDL and AIDL versions.
*/
class ISensorHalWrapper {
public:
class SensorDeviceCallback {
...
}
virtual bool connect(SensorDeviceCallback *callback) = 0;
}
??注释非常的清晰，用于对各种HAL实现的包装，说白了就是为了SensorDevice隔离SensorHal的不同接口的，例如HIDL/AIDL等。其入参为 SensorDeviceCallback，此处传入SensorDevice实例本身this，从上一章SensorDevice的类图能看出，SensorDeviceCallback为SensorDevice父类ISensorHalWrapper中的一个内部类，其定义如上。
??下面是connect接口的实现位于HidlSensorHalWrapper中
//frameworks\native\services\sensorservice\HidlSensorHalWrapper.cpp
bool HidlSensorHalWrapper::connect(SensorDeviceCallback* callback) {
mSensorDeviceCallback = callback;
connectHidlService();
return ret;
}
??代码非常简单，只有两个步骤
????1)记录由SensorDevice实现的SensorDeviceCallback实例指针，用于后续回调通知SensorDevice。
????2)获取SensorHal的实现并进行设置，例如配置用于传递sensor event的FMQ大小。在流程图上的调用流程为A1->B2->C3->D2对于其代码实现这里就不放了，因为和流程图上的并无差别。
3.3 SensorHal实现的选择
??在connectHalService中也可以看出，如果connectHidlService没有找到合适的HDIL实现，那么也会去找对应的aidl实现
bool SensorDevice::connectHalService() {
std::unique_ptr<ISensorHalWrapper> hidl_wrapper = std::make_unique<HidlSensorHalWrapper>();
if (hidl_wrapper->connect(this)) {
mHalWrapper = std::move(hidl_wrapper);
return true;
}
std::unique_ptr<ISensorHalWrapper> aidl_wrapper = std::make_unique<AidlSensorHalWrapper>();
if (aidl_wrapper->connect(this)) {
mHalWrapper = std::move(aidl_wrapper);
return true;
}
}
??此处我们选择使用HIDL的方式进行讲解，AIDL的方式放在拓展章节进行讲解。
bool HidlSensorHalWrapper::connectHidlService() {
HalConnectionStatus status = connectHidlServiceV2_1();
if (status == HalConnectionStatus::DOES_NOT_EXIST) {
status = connectHidlServiceV2_0();
}
if (status == HalConnectionStatus::DOES_NOT_EXIST) {
status = connectHidlServiceV1_0();
}
}
??从这里也能看出SensorFramework对选择SensorHal的HIDL实现的先后顺序为 V2.1->V2.0->V1.0。
3.3 ISensorWrapperV2_0的初始化
??由于 HIDL的实现又分为 2.1、2.0、1.0，为了做到兼容，SensorFramework引入了一系列中间类，ISensorsWrapperV1_0、ISensorsWrapperV2_0、ISensorsWrapperV2_1。此处我们使用的HIDL版本为2.0，故看看 ISensorsWrapperV2_0的实现
ISensorsWrapperV2_0(sp<hardware::sensors::V2_0::ISensors> sensors)
: SensorsWrapperBase(sensors) {
auto eventQueue = std::make_unique<EventMessageQueue>(MAX_RECEIVE_BUFFER_EVENT_COUNT,true);
mEventQueue = std::make_unique<EventMessageQueueWrapperV1_0>(eventQueue);
};
??构造函数做两件事，
????1)保存从ISensor获取的SensorHal句柄
SensorsWrapperBase(sensors)
mSensors(sensors)
??SensorsWrapperBase为ISensorsWrapperV2_0父类，sensors则由HidlSensorHalWrapper::connectHidlServiceV2_0 中传入
sp<android::hardware::sensors::V2_0::ISensors> sensors =
android::hardware::sensors::V2_0::ISensors::getService();
??至于最终获取到的句柄对应到哪个类的实例，这部分内容将放在HIDL-service SensorHal的初始化中去。
????2)创建 EventMessageQueue ，用于sensorEvent的传输，并且是FMQ方式的，这种方式的好处是内存交换时并不涉及kernel操作以及多次拷贝的问题。
typedef MessageQueue<::android::hardware::sensors::V1_0::Event,
::android::hardware::kSynchronizedReadWrite>
EventMessageQueue;
??EventMessageQueue实际上就是MessageQueue，对于 MessageQueue的说明见google的 fmq 文档
3.4 初始化SensorHal–initializeHidlServiceV2_X
??获取到SensorHal后，那么就是对其进行设置以符合SensorDevice的应用要求了。下面是对应的代码，我们只关心初始化骨架
ISensorHalWrapper::HalConnectionStatus HidlSensorHalWrapper::initializeHidlServiceV2_X() {
HalConnectionStatus connectionStatus = HalConnectionStatus::UNKNOWN;
//SensorHal的初始化
mCallback = sp<HidlSensorsCallback>::make(mSensorDeviceCallback);
mSensors->initialize(*mWakeLockQueue->getDesc(), mCallback)
//死亡回调注册
connectionStatus = HalConnectionStatus::CONNECTED;
mSensorsHalDeathReceiver = new SensorsHalDeathReceiver(this);
mSensors->linkToDeath(mSensorsHalDeathReceiver, 0 /* cookie */);
return connectionStatus;
}
3.4.1 SensorHal的初始化
??这部分代码最终会调用到ISensor.hal的initialize接口，真正对SensorHal进行初始化了，对应的代码如下
//hardware\interfaces\sensors\common\utils\ISensorsWrapper.h
Return<Result> initialize(const MQDescriptorSync<uint32_t>& wakeLockDesc,
const ::android::sp<ISensorsCallback>& callback) override {
return mSensors->initialize(*mEventQueue->getDesc(), wakeLockDesc, callback);
}
??从这里能看出，SensorHal上报的sensor event所用的队列是来自于SensorDevice进程的。如果SensorHal回调callback，SensorDevice中实现的接口也会被调用。HidlSensorsCallback的类图如下
??这里又对SensorDevice的实现做了一层包装，除了可以兼容2.1版本的HDIL接口，还将HIDL的ISensorsCallback接口作为SensorDevice为接口 SensorDeviceCallback 实现的代理类，从而让SensorDeviceCallback支持了跨进程调用，即SensorHal调用到SensorDevice。
//frameworks\native\services\sensorservice\HidlSensorHalWrapper.cpp
using android::hardware::sensors::V2_1::ISensorsCallback;
struct HidlSensorsCallback : public ISensorsCallback{
private:
ISensorHalWrapper::SensorDeviceCallback* mSensorDeviceCallback;
};
3.4.2 死亡回调注册
??因为SensorDevice和SensorHal的实现是位于两个不同的进程中的，所以后者的死亡前者是无法知悉的，所以前者注册后者的死亡接口是为了解决SensorHal的真实状态和SensorDevice中所记录它的状态无法同步的问题。注册也非常的简单，
//file:frameworks\native\services\sensorservice\HidlSensorHalWrapper.cpp
void SensorsHalDeathReceiver::serviceDied(
uint64_t /* cookie */, const wp<::android::hidl::base::V1_0::IBase>& /* service */) {
ALOGW("Sensors HAL died, attempting to reconnect.");
mHidlSensorHalWrapper->prepareForReconnect();
}
??如此在SensorHal所在进程死亡后，serviceDied 则会被回调。
??在SensorDevice中已经获取到SensorHal和设置完成了，最后提一下SensorDevice如果像调用SensorHal的实现，是通过类HidlSensorHalWrapper的，在SensorDevice的内部使用 std::unique_ptr mHalWrapper来指向它。
4.从SensorHal获取Senor信息–initializeSensorList
??initializeSensorList在SensorDevice的构造方法中就被调用了。
void SensorDevice::initializeSensorList() {
auto list = mHalWrapper->getSensorsList();
const size_t count = list.size();
for (size_t i = 0; i < count; i++) {
sensor_t sensor = list[i];
//code 1
sensor.resolution = SensorDeviceUtils::resolutionForSensor(sensor);
sensor.power = MIN_POWER_MA;
sensor.maxRange = quantizedRange;
//code 2
mSensorList.push_back(sensor);
mActivationCount.add(list[i].handle, model);
}
}
??mHalWrapper->getSensorsList最终调用到了SensorHal的接口并获得到了sensor，每个sensor的类型使用 sensor_t 表示，和SensorHal中保持一致。
??code 1 中主要是对sensor的信息重新整理或做兼容处理。
??code 2 SensorDevice中对这部分sensor信息进行存储，如此下次使用时则不用再次调用SensorHal的接口了，毕竟这个过程是跨进程的，需要内核进行调度操作的。
class SensorDevice:...{
private:
std::vector<sensor_t> mSensorList;
};
??mActivationCount 则是用于记录sensor的额外信息，索引则是使用sensor的handle值。当然初始化过程并无使用，对Info的说明注释说的还是比较清除的。
//file:frameworks\native\services\sensorservice\SensorDevice.h
Store batch parameters in the KeyedVector and the optimal batch_rate and timeout
inbestBatchParams. For every batch() call corresponding params are stored in
batchParamsvector. A continuous mode request is batch(... timeout=0 ..) followed by activate().
A batch mode request is batch(... timeout > 0 ...) followed by activate(). Info is a
per-sensor data structure which contains the batch parameters for each client that has
registered for this sensor.