Step-up problem and step-up sensor analysis in Android

Today opened the blog, only to find that more than a year has not written a blog ...

Recently, the company has been tracking the implementation of the pedometer on Android by analyzing the steps on Android. It turns out that, on Android's api19, the hardware itself is counted as a step in the implementation.

The process tracking in Android source code is as follows:

Type_step_detector and type_step_counter are defined in the Frameworks/base/core/java/android/hardware/sensor.java. Please note that after the detector is activated, the counter is started.

The call is then found below the JNI.

Frameworks/base/core/jni/android_hardware_sensormanager.cpp

    virtual int handleevent (int fd, int events, void* data) {        jnienv* env = androidruntime::getjnienv ();        sp<sensoreventqueue> q = reinterpret_cast<sensoreventqueue *> (data);        ssize_t N;        Asensorevent buffer[16];        while ((n = q->read (buffer)) > 0) {for            (int i=0; i<n; i++) {                if (Buffer[i].type = = Sensor_type_ste P_counter) {                    //Step-counter returns a UInt64, but the Java API is only deals with floats                    float value = Float (buffer[ I].u64.step_counter);                    Env->setfloatarrayregion (Mscratch, 0, 1, &value);                } else {                    env->setfloatarrayregion (mscratch, 0, buffer[i].data);                }

As you can see, if it is a pedometer, read the native value directly from Q. where Q was converted into sensoreventqueue. Find a conversion method:

Frameworks/native/libs/gui/sensoreventqueue.cpp

ssize_t Sensoreventqueue::read (asensorevent* events, size_t numevents) {    if (mavailable = = 0) {        ssize_t err = Bitt Ube::recvobjects (Msensorchannel,                Mrecbuffer, max_receive_buffer_event_count);        if (Err < 0) {            return err;        }           Mavailable = err;        mconsumed = 0;    }       size_t count = numevents < mavailable? numevents:mavailable;    memcpy (events, Mrecbuffer + mconsumed, count*sizeof (asensorevent));    Mavailable-= count;    Mconsumed + = count;    return count;}

In other words, sensorevent is stored in the asensorevent structure. Find prototypes.

Frameworks/native/include/android/sensor.h

/* note:must Match hardware/sensors.h */typedef struct asensorevent {int32_t version;/* sizeof (struct asensorevent) */int32_t    Sensor    int32_t type;    int32_t reserved0;    int64_t timestamp;            Union {Union {float DATA[16];            Asensorvector Vector;            Asensorvector acceleration;            Asensorvector Magnetic;            float temperature;            float distance;            float light;            float pressure;            float relative_humidity;            Auncalibratedevent Uncalibrated_gyro;            Auncalibratedevent uncalibrated_magnetic;        Ametadataevent Meta_data;          };            Union {uint64_t Data[8];        uint64_t Step_counter;    } U64;      }; int32_t reserved1[4];} asensorevent; 

Then the data came out .... Directly invoke the pedometer implementation on the hardware.

The relevant files for the HAL layer.

./hardware/libhardware/include/hardware/sensors.h

#define Sensor_type_step_detector ...                   #define Sensor_type_step_counter                    (19)

Ok. This is how to find the use of the HAL layer.

Invensense/65xx/libsensors_iio/sensors_mpl.cpp

202 int sensors_poll_context_t::p ollevents (sensors_event_t *data, int count) 203 {204 vhandler_log;205 206 int NbEv     Ents = 0;207 int nb, polltime = -1;208 209 Polltime = ((mplsensor*) msensor)->getstepcountpolltime (); 210 211 Look for new events212 NB = Poll (Mpollfds, Numfds, polltime); 213 logi_if (0, "poll nb=%d, count=%d, pt=%d", NB              , count, polltime); 214 if (nb > 0) {215 for (int i = 0; count && i < numsensordrivers; i++) {216 if (Mpollfds[i].revents & (Pollin |                 POLLPRI)) {217 logi_if (0, "poll found=%d", I); 218 NB = 0;219 if (i = = MPL) {(mplsensor*) msensor)->buildmpuevent (); 221 mpollfds[i].re vents = 0;222} else if (i = = Compass) {223 ((mplsensor*) msensor)->buildcompasseve NT (); 224 mpollfds[i].revents = 0;.... 268 if ((mplsensor*) msensor)->hasstepcountpendingevents () = = True) {269 NB = 0;270 NB = ((mplsensor*) msensor)->readdmp Pedometerevents (data, Count, ID_SC, Sensor_type_step_counter, 0); 271 logi_if (Handler_data, "sensors_mpl:readst  Epcount ()-nb=%d, count=%d, nbevents=%d, Data->timestamp=%lld, Data->data[0]=%f, ", 272 nb, Count, Nbevents, Data->timestamp, data->data[0]) 273 if (NB > 0) {274 count-= nb;27                     5 nbevents + = nb;276 Data + = nb;277}278}

As you can see, 270 lines read the data ...

By the way, the implementation of sensor in Android is checked.

Https://source.android.com/devices/sensors/sensor-stack.html the official introduction. The description of the sensor level is not very detailed.

Https://docs.google.com/file/d/0B2IJqxU5nzCyQWZ1TzhGd3FUWlNCQjhqV0psV1l3dw/edit 2012 of the document, now the implementation of the changes, roughly can refer to.

Http://processors.wiki.ti.com/index.php/Android_Sensor_PortingGuide the change method of the kernel layer.

There is no NEXUS5 kernel source on hand, so it is not implemented in the kernel of step counter in N5. But this tracking process is relatively straightforward.

Step-up problem and step-up sensor analysis in Android