MTK Sensor框架 及信息传递详解

一、概述

sensor（传感器）作为手机中一个非常重要且目前来说不可或缺的一种组件，功能强大，但是使用却很简单。Android 传感器属于虚拟设备，可提供来自以下各种物理传感器的数据：加速度计、陀螺仪、磁力计、气压计、湿度传感器、压力传感器、光传感器、近程传感器和心率传感器。因为对于日常生活来说有一部分sensor是使用频率是很高的，所以必然也伴随着手机功耗的增加如果每次都是CPU进行处理的化，而且CPU一旦休眠还伴随着sensor会停止工作，为了优化手机使用Google和MTK分别开发了CHRE 和SCP 进行sensor控制。

首先介绍以下SCP:

SCP 是用来处理sensor和audio相关功能和其他客制化需求的一个协处理理器，MTK SCP选择freeRTOS作为操作系统，CHRE是处理传感器相关操作的专门任务,它的架构如下

然后是CHRE:

在SCP下，MTK传感器集线器功能是在google CHRE ar上开发的,chre（Context Hub Runtime Environment）是一种事件驱动的体系结构，也可以被视为操作系统。

黄色部分是事件队列，CHRE只有一个while循环来处理事件队列中的头事件。如果以前的调用尚未完成，CHRE将无法调用队列中的一个任务。因此，没有优先级概念，当前事件队列处理只能

被中断中断。默认情况下，CHRE在事件队列中最多支持512个事件。CHRE的目的是实现实时性和轻量级，因此事件队列中调用的所有任务都必须快速运行。CHRE中的驱动程序实现称为nano hub app。

整个sensor体系中包括：应用层、framework层、jni、hal层、kernel层、SCP/CHRE。

二、应用层调用

sensor在应用层调用非常简单，代码如下:

public class SensorActivity extends Activity implements SensorEventListener {

         private final SensorManager mSensorManager;

         private final Sensor mAccelerometer;


         public SensorActivity() {

             mSensorManager = (SensorManager)getSystemService(SENSOR_SERVICE);

             mAccelerometer = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);

         }


         protected void onResume() {

             super.onResume();

             mSensorManager.registerListener(this, mAccelerometer, SensorManager.SENSOR_DELAY_NORMAL);

         }


         protected void onPause() {

             super.onPause();

             mSensorManager.unregisterListener(this);

         }


         public void onAccuracyChanged(Sensor sensor, int accuracy) {

         }


         public void onSensorChanged(SensorEvent event) {

         }

     }

只需要获取到sensormanager然后注册监听就可以，sensor的信息就会通过回调接口上报上来

• getSystemService 获取系统服务的标准接口，参数是表示要获取的服务类型
• Sensormanger.getDefaultSensor 获取想要使用的sensor 实例 ，参数表示要获取的sensor 类型
• SensorManager.registerListener 注册sensor的信息回调，参数分别是上下文，sensor，上报延时

三、framework层

经过上层的getSystemService获取了服务，功能就来到了framework层，这里对应framework/base/core/java/android/hardware/SensorManager.java,但是实际上这只是一个代理抽象类，真正获取的是SystemSensorManager:framework/base/core/java/android/hardware/SystemSensorManager.java。（从SystemServiceRegistry.java中可以看出，这是一个专门为上层注册接口的类）。

SystemSensorManager 在最上层控制着所有的sensor ,他的实现仅仅靠自己是不够的，它还链接了一个jni库，注册了很多native方法。android_hardware_SensorManager :framework/base/core/jni/android_hardware_SensorManager.cpp

static const JNINativeMethod gSystemSensorManagerMethods[] = {

        {"nativeClassInit",

                "()V",

                (void*)nativeClassInit },

        {"nativeCreate",

                 "(Ljava/lang/String;)J",

                 (void*)nativeCreate },


        {"nativeGetSensorAtIndex",

                "(JLandroid/hardware/Sensor;I)Z",

                (void*)nativeGetSensorAtIndex },


        {"nativeGetDynamicSensors",

                "(JLjava/util/List;)V",

                (void*)nativeGetDynamicSensors },


        {"nativeIsDataInjectionEnabled",

                "(J)Z",

                (void*)nativeIsDataInjectionEnabled },


        {"nativeCreateDirectChannel",

                "(JJIILandroid/hardware/HardwareBuffer;)I",

                (void*)nativeCreateDirectChannel },


        {"nativeDestroyDirectChannel",

                "(JI)V",

                (void*)nativeDestroyDirectChannel },


        {"nativeConfigDirectChannel",

                "(JIII)I",

                (void*)nativeConfigDirectChannel },


        {"nativeSetOperationParameter",

                "(JII[F[I)I",

                (void*)nativeSetOperationParameter },

    };


    static const JNINativeMethod gBaseEventQueueMethods[] = {

            {"nativeInitBaseEventQueue",

             "(JLjava/lang/ref/WeakReference;Landroid/os/MessageQueue;Ljava/lang/String;ILjava/lang/"

             "String;Ljava/lang/String;)J",

             (void *)nativeInitSensorEventQueue},


            {"nativeEnableSensor", "(JIII)I", (void *)nativeEnableSensor},


            {"nativeDisableSensor", "(JI)I", (void *)nativeDisableSensor},


            {"nativeDestroySensorEventQueue", "(J)V", (void *)nativeDestroySensorEventQueue},


            {"nativeFlushSensor", "(J)I", (void *)nativeFlushSensor},


            {"nativeInjectSensorData", "(JI[FIJ)I", (void *)nativeInjectSensorData},

    };


    } //unnamed namespace


    int register_android_hardware_SensorManager(JNIEnv *env)

    {

        RegisterMethodsOrDie(env, "android/hardware/SystemSensorManager",

                gSystemSensorManagerMethods, NELEM(gSystemSensorManagerMethods));


        RegisterMethodsOrDie(env, "android/hardware/SystemSensorManager$BaseEventQueue",

                gBaseEventQueueMethods, NELEM(gBaseEventQueueMethods));


        gBaseEventQueueClassInfo.clazz = FindClassOrDie(env,

                "android/hardware/SystemSensorManager$BaseEventQueue");


        gBaseEventQueueClassInfo.dispatchSensorEvent = GetMethodIDOrDie(env,

                gBaseEventQueueClassInfo.clazz, "dispatchSensorEvent", "(I[FIJ)V");


        gBaseEventQueueClassInfo.dispatchFlushCompleteEvent = GetMethodIDOrDie(env,

                gBaseEventQueueClassInfo.clazz, "dispatchFlushCompleteEvent", "(I)V");


        gBaseEventQueueClassInfo.dispatchAdditionalInfoEvent = GetMethodIDOrDie(env,

                gBaseEventQueueClassInfo.clazz, "dispatchAdditionalInfoEvent", "(III[F[I)V");


        return 0;

    }

上面代码是android_hardware_SensorManager用来绑定java类和相关方法的。然后又将方法实现转移到SensorManager.cpp:framework/native/libs/sensor/SensorManager.cpp，

SystemSensorManager创建时 会创建native SensorManager的实例并持有，然后获取sensorlist。SystemSensorManager中封装了很多方法，如：启用、禁用、刷新、添加监听等等。

SensorManager 也不是自己去做事情，它通过BitTube和SensorService 链接，将指令传到sensorservice。android_hardware_SensorManager 有一个内部类专门监听了BitTube通道文件描述符，会将sensor上报的信息通过这里上报到上层。

然后所有的事情都会转移到frameworks/native/services/sensorservice/ 这个包中,这里面会对所有sensor信息进行整理过滤，这里的所有信息都是从hal层获取，这里有个很关键的类SensorDevice,这个类链接了hal层

SensorDevice::SensorDevice()

           : mHidlTransportErrors(20),
             mRestartWaiter(new HidlServiceRegistrationWaiter()),
             mEventQueueFlag(nullptr),
             mWakeLockQueueFlag(nullptr),
             mReconnecting(false) {
       if (!connectHidlService()) {
           return;
       }

       initializeSensorList();

       mIsDirectReportSupported =
               (checkReturnAndGetStatus(mSensors->unregisterDirectChannel(-1)) != INVALID_OPERATION);
   }
   ...
   bool SensorDevice::connectHidlService() {
       HalConnectionStatus status = connectHidlServiceV2_1();  // 链接hal 2.1
       if (status == HalConnectionStatus::DOES_NOT_EXIST) {
           status = connectHidlServiceV2_0(); // 链接 hal 2.0
       }

       if (status == HalConnectionStatus::DOES_NOT_EXIST) {
           status = connectHidlServiceV1_0(); // 链接 hal 1.0
       }
       return (status == HalConnectionStatus::CONNECTED);
   }
   SensorDevice::HalConnectionStatus SensorDevice::connectHidlServiceV1_0() {
       // SensorDevice will wait for HAL service to start if HAL is declared in device manifest.
       size_t retry = 10;
       HalConnectionStatus connectionStatus = HalConnectionStatus::UNKNOWN;

       while (retry-- > 0) {
           sp<V1_0::ISensors> sensors = V1_0::ISensors::getService();
           if (sensors == nullptr) {
               // no sensor hidl service found
               connectionStatus = HalConnectionStatus::DOES_NOT_EXIST;
               break;
           }

           mSensors = new ISensorsWrapperV1_0(sensors);
           mRestartWaiter->reset();
           // Poke ISensor service. If it has lingering connection from previous generation of
           // system server, it will kill itself. There is no intention to handle the poll result,
           // which will be done since the size is 0.
           if(mSensors->poll(0, [](auto, const auto &, const auto &) {}).isOk()) {
               // ok to continue
               connectionStatus = HalConnectionStatus::CONNECTED;
               break;
           }

           // hidl service is restarting, pointer is invalid.
           mSensors = nullptr;
           connectionStatus = HalConnectionStatus::FAILED_TO_CONNECT;
           ALOGI("%s unsuccessful, remaining retry %zu.", __FUNCTION__, retry);
           mRestartWaiter->wait();
       }

       return connectionStatus;
   }

   SensorDevice::HalConnectionStatus SensorDevice::connectHidlServiceV2_0() {
       HalConnectionStatus connectionStatus = HalConnectionStatus::UNKNOWN;
       sp<V2_0::ISensors> sensors = V2_0::ISensors::getService();

       if (sensors == nullptr) {
           connectionStatus = HalConnectionStatus::DOES_NOT_EXIST;
       } else {
           mSensors = new ISensorsWrapperV2_0(sensors);
           connectionStatus = initializeHidlServiceV2_X();
       }

       return connectionStatus;
   }

   SensorDevice::HalConnectionStatus SensorDevice::connectHidlServiceV2_1() {
       HalConnectionStatus connectionStatus = HalConnectionStatus::UNKNOWN;
       sp<V2_1::ISensors> sensors = V2_1::ISensors::getService();

       if (sensors == nullptr) {
           connectionStatus = HalConnectionStatus::DOES_NOT_EXIST;
       } else {
           mSensors = new ISensorsWrapperV2_1(sensors);
           connectionStatus = initializeHidlServiceV2_X();
       }

       return connectionStatus;
   }
   ...

ISensors::getService()是hal层service 的获取方式，对应的是hardware/interfaces/sensors/…/ISensors.hal ,ISensors.hal编译之后会生成ISensors.h，服务端只要实现这个头文件的方法即可

四、hal层

hal层代码接口位于：hardware/interfaces/sensors/

文件夹下定义了多个版本的hal层结构，1.0、2.0、2.1还有公共接口，一般使用最新的2.1或者2.0，文件结构如下

.hal 文件是接口文件，在编译过程中会被编译成.h，需要使用的就导入.h文件，然后ISensors::getService()获取service服务实例即可，multihal里面是关于多hal的实现，vts里面是vs测试相关,hal层和framework层通信使用的是HIDL，和AIDL类似，底层使用的都是binder机制实现跨进程通信。

• ISensorsCallback.hal 里面定义的动态sensor的回调接口
• ISensors.hal 里面定义的是服务的主要功能接口
• types.hal 里面定义的是一些要用到的结构类型

4.1 hal的实现

真正实现hal转接口的代码是在:vendor/mediatek/proprietary/hardware/sensor 这个文件夹中也会有多个版本的代码根据android.mk 进行选择，由宏控制，选择相应的版本，当前选择最新2.0进行讨论

LOCAL_PATH := $(call my-dir)

   ifdef MTK_GENERIC_HAL

   ## layer decoupling 2.0 chips will go to this branch

   ## DO NOT USE platform macro in this branch

   include $(call all-named-subdir-makefiles, hidl 2.0)

   else

   ifeq ($(strip $(MTK_SENSOR_ARCHITECTURE)),1.0)

   include $(call all-named-subdir-makefiles,hidl sensors-1.0)

   else ifeq ($(MTK_SENSORS_1_0),yes)

   include $(call all-named-subdir-makefiles,hidl sensors-1.0)

   else

   include $(call all-named-subdir-makefiles,hidl $(strip $(MTK_SENSOR_ARCHITECTURE)))

   endif

   endif

与framework层通信的代码在hidl文件夹下有多个文件夹：

1.0/2.0 表示版本号，配置hal哪个版本就哪个

multihal:多hal，需要单独配置由/vendor/etc/sensors/hals.conf这个文件控制

Sensors.h 中可以看出Sensors 继承了ISensors并实现了这些方法

Sensors::Sensors()
    : mInitCheck(NO_INIT),
      mSensorModule(nullptr),
      mSensorDevice(nullptr),
      mEventQueueFlag(nullptr),
      mOutstandingWakeUpEvents(0),
      mReadWakeLockQueueRun(false),
      mAutoReleaseWakeLockTime(0),
      mHasWakeLock(false),
      mRunThreadEnable(false),
      mEventQueueInitialized(false) {
    status_t err = OK;
    if (UseMultiHal()) {
        mSensorModule = ::get_multi_hal_module_info();
    } else {
        err = hw_get_module(
            SENSORS_HARDWARE_MODULE_ID,
            (hw_module_t const **)&mSensorModule); //获取SENSORS_HARDWARE_MODULE_ID的模块
    }
    if (mSensorModule == NULL) {
        err = UNKNOWN_ERROR;
    }

    if (err != OK) {
        LOG(ERROR) << "Couldn't load "
                   << SENSORS_HARDWARE_MODULE_ID
                   << " module ("
                   << strerror(-err)
                   << ")";

        mInitCheck = err;
        return;
    }

    err = sensors_open_1(&mSensorModule->common, &mSensorDevice);        // 加载模块中的sensors_module_methods，并赋值给mSensorDevice

    if (err != OK) {
        LOG(ERROR) << "Couldn't open device for module "
                   << SENSORS_HARDWARE_MODULE_ID
                   << " ("
                   << strerror(-err)
                   << ")";

        mInitCheck = err;
        return;
   ...
}

从Sensors.cpp代码可以看出，Sensors初始化时会先判断是否使用了多hal，如果使用则会加载多hal模块，如果使用则通过hw_get_module加载id为SENSORS_HARDWARE_MODULE_ID的模块，并把它赋值给了mSensorModule。发现这个模块代码就放在sensor目录下面对应的那些不同版本的文件夹下，直接到vendor/mediatek/proprietary/hardware/sensor/2.0/hal 这个目录下放的都是2.0 hal 的代码,其中sensors.cpp 中的正式id为SENSORS_HARDWARE_MODULE_ID的模块

...
  static struct hw_module_methods_t sensors_module_methods = {
      .open = open_sensors
  };

  struct sensors_module_t HAL_MODULE_INFO_SYM = {
      .common = {
          .tag = HARDWARE_MODULE_TAG,
          .version_major = 1,
          .version_minor = 0,
          .id = SENSORS_HARDWARE_MODULE_ID,
          .name = "MTK SENSORS Module",
          .author = "Mediatek",
          .methods = &sensors_module_methods,
      },

所以可以从此看出，从framework层过来的指令给了mSensorModule和mSensorDevice 进行处理，间接的传递给了这个模块处理，然后此模块又分出很多个类进行分别处理不同的指令,部分指令又会汇集到一个类去和另一个层通信它就是HfManager,这个类在2.0/core/文件夹下,

进到HfManager 我们发现，这个类里面还有一个内部类HfLooper，但是无论哪个类，他们的方法最后会通过一个节点他就是dev/hf_manager，hal层则是通过这个节点来到了kernel层kernel-4.14/d/misc/mediatek/sensor/2.0/core/hf_manager.h。

五、kernel 层

kernel层代码位于kernel文件夹下，至于kernel版本会在device下定义，我们先看kernel-4.14。sensor在kernel中的代码位于:

kernel-4.14/drivers/misc/mediatek/sensor
kernel-4.14/drivers/misc/mediatek/sensors-1.0
kernel-4.14/drivers/staging/nanohub

5.1 kernel-4.14/drivers/misc/mediatek/

首先这个文件夹下会包含很多驱动，其中有两个包sensor和sensors-1.0，这两个下面的内容其实是类似的，根据宏CONFIG_MTK_SENSOR_ARCHITECTURE会确定我们要的代码sensor中。

Android.mk

...
 88 ifeq ($(subst ",,$(CONFIG_MTK_SENSOR_ARCHITECTURE)),1.0)
 89 obj-y += sensors-1.0/
 90 else
 91 obj-y += sensor/
 92 endif
...

sensor 文件夹下有一个我们要的类hf_manager.c，打开这个文件不然发现，它创建了节点dev/hf_manager，这刚好就和hal层的HfManager.cpp 链接上了，hal层的指令通过这个节点来到了kernel,这是一个普通的文件节点，里面有一些读写、指令操作。这里面有个核心结构体hf_core,后面很多操作都和这个结构体有关系

struct hf_core {

        struct mutex manager_lock;

        struct list_head manager_list; //外面注册的manager

        struct sensor_state state[SENSOR_TYPE_SENSOR_MAX];

   

        spinlock_t client_lock;

        struct list_head client_list;

   

        struct mutex device_lock;

        struct list_head device_list;

   

        struct kthread_worker kworker;

首先我们看下hf_manager 被打开时做了什么事情：创造了一个hf_client，这个hf_client记录了当前进程和线程的id，还创建了一个FIFO，用于数据交换

static int hf_manager_open(struct inode *inode, struct file *filp)

   {

       struct hf_client *client = hf_client_create();

     

       if (!client)

           return -ENOMEM;

     

       filp->private_data = client;   

       nonseekable_open(inode, filp);

       return 0;

   }

然后，大概浏览一下代码不难发现，指令好像后面都被hf_device这个结构体承担了，这个结构体来自与hf_manager，hf_manager 每次使用之前都会调用hf_manager_find_manager方法来查找，那我么看看这个方法做了什么:

static struct hf_manager *hf_manager_find_manager(struct hf_core *core,

           uint8_t sensor_type)

   {

       int i = 0;

       struct hf_manager *manager = NULL;

       struct hf_device *device = NULL;

  

       list_for_each_entry(manager, &core->manager_list, list) {

           device = READ_ONCE(manager->hf_dev);

           if (!device || !device->support_list)

               continue;

           for (i = 0; i < device->support_size; ++i) {

               if (sensor_type == device->support_list[i].sensor_type)

                   return manager;

           }

       }

       pr_err("Failed to find manager, %u unregistered\n", sensor_type);

       return NULL;

   }

发现它只是从一个list中去查找，根据sensor_type进行匹配，这个core→manager_list 又是由hf_manager_create方法进行注册，而这个方法是向外提供的，然后搜索一下不难发现:./2.0/sensorhub/transceiver.c 和 ./2.0/mtk_nanohub/mtk_nanohub.c使用到了它，也就是说这两个类分别注册了自己的hf_device，并且进行了相关的数据处理，这两个类所处的文件夹可以猜测一个是跟sensorhub相关，另一个则和CHRE相关。

5.2 sensor hub

sensor hub是个什么东西呢，故名思意，它是一个传感器集线器，也就是说某些传感器的数据要经过这个地方进行中转，transceiver.c它会和SCP通过IPI通信，将这边的指令还有DRAM地址发送到SCP端，然后把SCP 端的信息回传，先是读取DRAM内存获取信息，然后通过manager→report方法会传到hf_fifo，然后hf_fifo上的数据会被hal层读走。

ap侧sensor hub 通过kernel-4.14/drivers/misc/mediatek/sensor/2.0/sensorhub/ipi_comm.c和SCP侧建立链接：IPI_IN_SENSOR_NOTIFY接收ID,IPI_OUT_SENSOR_NOTIFY接收ID，IPI_IN_SENSOR_CTRL指令ID

sensor hub 所链接的SCP 侧在:vendor/mediatek/proprietary/tinysys/scp/middleware/sensorhub/comm/ipi_comm.c

5.3 nano hub

nano hub 是CHRE框架中的集线器，和sensor hub类似，nano hub 也是通过mtk_nonohub.c注册了hf_device ，和SCP通过IPI通信，将DRAM地址发送到SCP端，通过IPI把指令发过去，但是通过DRAM把信息读回来，然后通过manager→report 传递到hal层

ap侧nano hub 通过kernel-4.14/drivers/misc/mediatek/sensor/2.0/mtk_nanohub/nanohub/nanohub-mtk.c 和SCP建立链接 通过ID IPI_CHRE

nanohub 所链接的SCP侧在:vendor/mediatek/proprietary/hardware/contexthub/firmware/links/plat/src/hostIntfIPI.c

然后CHRE会调用bool SensorQueueEnqueue(struct SimpleQueue* sq, const void *data, int length, bool possiblyDiscardable)将数据传递到scp/middleware/contexthub/contexthub_fw.c，然后contexthub_fw.c 将数据写入DRAM，供AP侧读取

还有一部分指令会通过IPI_SENSOR直接传递到scp/middleware/contexthub/contexthub_fw.c

vendor/mediatek/proprierary/hardware/contexthub/firmware 下面有一些sensor，会将数据传递给hostIntf,然后传递给contexthub.c

vendor/mediatek/proprierary/tinysys/scp/middleware/sensorhub 下面也有一些sensor会传递信息

这两个地方有什么区别，目前暂未搞清楚，但是可以肯定的是sensor核心代码就在这两个地方了，CHRE 和 SCP侧，整个框架信息传递如下图: