Android Hardware Abstraction Layer
sensors.h
Go to the documentation of this file.
1 /*
2  * Copyright (C) 2012 The Android Open Source Project
3  *
4  * Licensed under the Apache License, Version 2.0 (the "License");
5  * you may not use this file except in compliance with the License.
6  * You may obtain a copy of the License at
7  *
8  * http://www.apache.org/licenses/LICENSE-2.0
9  *
10  * Unless required by applicable law or agreed to in writing, software
11  * distributed under the License is distributed on an "AS IS" BASIS,
12  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13  * See the License for the specific language governing permissions and
14  * limitations under the License.
15  */
16 
17 #ifndef ANDROID_SENSORS_INTERFACE_H
18 #define ANDROID_SENSORS_INTERFACE_H
19 
20 #include <stdint.h>
21 #include <sys/cdefs.h>
22 #include <sys/types.h>
23 
24 #include <hardware/hardware.h>
25 #include <cutils/native_handle.h>
26 
27 __BEGIN_DECLS
28 
29 /*****************************************************************************/
30 
31 #define SENSORS_HEADER_VERSION 1
32 #define SENSORS_MODULE_API_VERSION_0_1 HARDWARE_MODULE_API_VERSION(0, 1)
33 #define SENSORS_DEVICE_API_VERSION_0_1 HARDWARE_DEVICE_API_VERSION_2(0, 1, SENSORS_HEADER_VERSION)
34 #define SENSORS_DEVICE_API_VERSION_1_0 HARDWARE_DEVICE_API_VERSION_2(1, 0, SENSORS_HEADER_VERSION)
35 #define SENSORS_DEVICE_API_VERSION_1_1 HARDWARE_DEVICE_API_VERSION_2(1, 1, SENSORS_HEADER_VERSION)
36 
37 /**
38  * The id of this module
39  */
40 #define SENSORS_HARDWARE_MODULE_ID "sensors"
41 
42 /**
43  * Name of the sensors device to open
44  */
45 #define SENSORS_HARDWARE_POLL "poll"
46 
47 /**
48  * Handles must be higher than SENSORS_HANDLE_BASE and must be unique.
49  * A Handle identifies a given sensors. The handle is used to activate
50  * and/or deactivate sensors.
51  * In this version of the API there can only be 256 handles.
52  */
53 #define SENSORS_HANDLE_BASE 0
54 #define SENSORS_HANDLE_BITS 8
55 #define SENSORS_HANDLE_COUNT (1<<SENSORS_HANDLE_BITS)
56 
57 
58 /*
59  * flags for (*batch)()
60  * Availability: SENSORS_DEVICE_API_VERSION_1_0
61  * see (*batch)() documentation for details
62  */
63 enum {
64  SENSORS_BATCH_DRY_RUN = 0x00000001,
66 };
67 
68 /*
69  * what field for meta_data_event_t
70  */
71 enum {
72  /* a previous flush operation has completed */
74  META_DATA_VERSION /* always last, leave auto-assigned */
75 };
76 
77 /**
78  * Definition of the axis used by the sensor HAL API
79  *
80  * This API is relative to the screen of the device in its default orientation,
81  * that is, if the device can be used in portrait or landscape, this API
82  * is only relative to the NATURAL orientation of the screen. In other words,
83  * the axis are not swapped when the device's screen orientation changes.
84  * Higher level services /may/ perform this transformation.
85  *
86  * x<0 x>0
87  * ^
88  * |
89  * +-----------+--> y>0
90  * | |
91  * | |
92  * | |
93  * | | / z<0
94  * | | /
95  * | | /
96  * O-----------+/
97  * |[] [ ] []/
98  * +----------/+ y<0
99  * /
100  * /
101  * |/ z>0 (toward the sky)
102  *
103  * O: Origin (x=0,y=0,z=0)
104  *
105  */
106 
107 /*
108  * Interaction with suspend mode
109  *
110  * Unless otherwise noted, an enabled sensor shall not prevent the
111  * SoC to go into suspend mode. It is the responsibility of applications
112  * to keep a partial wake-lock should they wish to receive sensor
113  * events while the screen is off. While in suspend mode, and unless
114  * otherwise noted (batch mode, sensor particularities, ...), enabled sensors'
115  * events are lost.
116  *
117  * Note that conceptually, the sensor itself is not de-activated while in
118  * suspend mode -- it's just that the data it returns are lost. As soon as
119  * the SoC gets out of suspend mode, operations resume as usual. Of course,
120  * in practice sensors shall be disabled while in suspend mode to
121  * save power, unless batch mode is active, in which case they must
122  * continue fill their internal FIFO (see the documentation of batch() to
123  * learn how suspend interacts with batch mode).
124  *
125  * In batch mode, and only when the flag SENSORS_BATCH_WAKE_UPON_FIFO_FULL is
126  * set and supported, the specified sensor must be able to wake-up the SoC and
127  * be able to buffer at least 10 seconds worth of the requested sensor events.
128  *
129  * There are notable exceptions to this behavior, which are sensor-dependent
130  * (see sensor types definitions below)
131  *
132  *
133  * The sensor type documentation below specifies the wake-up behavior of
134  * each sensor:
135  * wake-up: yes this sensor must wake-up the SoC to deliver events
136  * wake-up: no this sensor shall not wake-up the SoC, events are dropped
137  *
138  */
139 
140 /*
141  * Sensor type
142  *
143  * Each sensor has a type which defines what this sensor measures and how
144  * measures are reported. All types are defined below.
145  *
146  * Device manufacturers (OEMs) can define their own sensor types, for
147  * their private use by applications or services provided by them. Such
148  * sensor types are specific to an OEM and can't be exposed in the SDK.
149  * These types must start at SENSOR_TYPE_DEVICE_PRIVATE_BASE.
150  */
151 
152 /*
153  * Base for device manufacturers private sensor types.
154  * These sensor types can't be exposed in the SDK.
155  */
156 #define SENSOR_TYPE_DEVICE_PRIVATE_BASE 0x10000
157 
158 /*
159  * Sensor fusion and virtual sensors
160  *
161  * Many sensor types are or can be implemented as virtual sensors from
162  * physical sensors on the device. For instance the rotation vector sensor,
163  * orientation sensor, step-detector, step-counter, etc...
164  *
165  * From the point of view of this API these virtual sensors MUST appear as
166  * real, individual sensors. It is the responsibility of the driver and HAL
167  * to make sure this is the case.
168  *
169  * In particular, all sensors must be able to function concurrently.
170  * For example, if defining both an accelerometer and a step counter,
171  * then both must be able to work concurrently.
172  */
173 
174 /*
175  * Trigger modes
176  *
177  * Sensors can report events in different ways called trigger modes,
178  * each sensor type has one and only one trigger mode associated to it.
179  * Currently there are four trigger modes defined:
180  *
181  * continuous: events are reported at a constant rate defined by setDelay().
182  * eg: accelerometers, gyroscopes.
183  * on-change: events are reported only if the sensor's value has changed.
184  * setDelay() is used to set a lower limit to the reporting
185  * period (minimum time between two events).
186  * The HAL must return an event immediately when an on-change
187  * sensor is activated.
188  * eg: proximity, light sensors
189  * one-shot: upon detection of an event, the sensor deactivates itself and
190  * then sends a single event. Order matters to avoid race
191  * conditions. No other event is sent until the sensor get
192  * reactivated. setDelay() is ignored.
193  * eg: significant motion sensor
194  * special: see details in the sensor type specification below
195  *
196  */
197 
198 
199 /*
200  * SENSOR_TYPE_META_DATA
201  * trigger-mode: n/a
202  * wake-up sensor: n/a
203  *
204  * NO SENSOR OF THAT TYPE MUST BE RETURNED (*get_sensors_list)()
205  *
206  * SENSOR_TYPE_META_DATA is a special token used to populate the
207  * sensors_meta_data_event structure. It doesn't correspond to a physical
208  * sensor. sensors_meta_data_event are special, they exist only inside
209  * the HAL and are generated spontaneously, as opposed to be related to
210  * a physical sensor.
211  *
212  * sensors_meta_data_event_t.version must be META_DATA_VERSION
213  * sensors_meta_data_event_t.sensor must be 0
214  * sensors_meta_data_event_t.type must be SENSOR_TYPE_META_DATA
215  * sensors_meta_data_event_t.reserved must be 0
216  * sensors_meta_data_event_t.timestamp must be 0
217  *
218  * The payload is a meta_data_event_t, where:
219  * meta_data_event_t.what can take the following values:
220  *
221  * META_DATA_FLUSH_COMPLETE
222  * This event indicates that a previous (*flush)() call has completed for the sensor
223  * handle specified in meta_data_event_t.sensor.
224  * see (*flush)() for more details
225  *
226  * All other values for meta_data_event_t.what are reserved and
227  * must not be used.
228  *
229  */
230 #define SENSOR_TYPE_META_DATA (0)
231 
232 /*
233  * SENSOR_TYPE_ACCELEROMETER
234  * trigger-mode: continuous
235  * wake-up sensor: no
236  *
237  * All values are in SI units (m/s^2) and measure the acceleration of the
238  * device minus the force of gravity.
239  *
240  * Acceleration sensors return sensor events for all 3 axes at a constant
241  * rate defined by setDelay().
242  *
243  * x: Acceleration on the x-axis
244  * y: Acceleration on the y-axis
245  * z: Acceleration on the z-axis
246  *
247  * Note that the readings from the accelerometer include the acceleration
248  * due to gravity (which is opposite to the direction of the gravity vector).
249  *
250  * Examples:
251  * The norm of <x, y, z> should be close to 0 when in free fall.
252  *
253  * When the device lies flat on a table and is pushed on its left side
254  * toward the right, the x acceleration value is positive.
255  *
256  * When the device lies flat on a table, the acceleration value is +9.81,
257  * which correspond to the acceleration of the device (0 m/s^2) minus the
258  * force of gravity (-9.81 m/s^2).
259  *
260  * When the device lies flat on a table and is pushed toward the sky, the
261  * acceleration value is greater than +9.81, which correspond to the
262  * acceleration of the device (+A m/s^2) minus the force of
263  * gravity (-9.81 m/s^2).
264  */
265 #define SENSOR_TYPE_ACCELEROMETER (1)
266 
267 /*
268  * SENSOR_TYPE_GEOMAGNETIC_FIELD
269  * trigger-mode: continuous
270  * wake-up sensor: no
271  *
272  * All values are in micro-Tesla (uT) and measure the geomagnetic
273  * field in the X, Y and Z axis.
274  *
275  * Returned values include calibration mechanisms such that the vector is
276  * aligned with the magnetic declination and heading of the earth's
277  * geomagnetic field.
278  *
279  * Magnetic Field sensors return sensor events for all 3 axes at a constant
280  * rate defined by setDelay().
281  */
282 #define SENSOR_TYPE_GEOMAGNETIC_FIELD (2)
283 #define SENSOR_TYPE_MAGNETIC_FIELD SENSOR_TYPE_GEOMAGNETIC_FIELD
284 
285 /*
286  * SENSOR_TYPE_ORIENTATION
287  * trigger-mode: continuous
288  * wake-up sensor: no
289  *
290  * All values are angles in degrees.
291  *
292  * Orientation sensors return sensor events for all 3 axes at a constant
293  * rate defined by setDelay().
294  *
295  * azimuth: angle between the magnetic north direction and the Y axis, around
296  * the Z axis (0<=azimuth<360).
297  * 0=North, 90=East, 180=South, 270=West
298  *
299  * pitch: Rotation around X axis (-180<=pitch<=180), with positive values when
300  * the z-axis moves toward the y-axis.
301  *
302  * roll: Rotation around Y axis (-90<=roll<=90), with positive values when
303  * the x-axis moves towards the z-axis.
304  *
305  * Note: For historical reasons the roll angle is positive in the clockwise
306  * direction (mathematically speaking, it should be positive in the
307  * counter-clockwise direction):
308  *
309  * Z
310  * ^
311  * (+roll) .--> |
312  * / |
313  * | | roll: rotation around Y axis
314  * X <-------(.)
315  * Y
316  * note that +Y == -roll
317  *
318  *
319  *
320  * Note: This definition is different from yaw, pitch and roll used in aviation
321  * where the X axis is along the long side of the plane (tail to nose).
322  */
323 #define SENSOR_TYPE_ORIENTATION (3)
324 
325 /*
326  * SENSOR_TYPE_GYROSCOPE
327  * trigger-mode: continuous
328  * wake-up sensor: no
329  *
330  * All values are in radians/second and measure the rate of rotation
331  * around the X, Y and Z axis. The coordinate system is the same as is
332  * used for the acceleration sensor. Rotation is positive in the
333  * counter-clockwise direction (right-hand rule). That is, an observer
334  * looking from some positive location on the x, y or z axis at a device
335  * positioned on the origin would report positive rotation if the device
336  * appeared to be rotating counter clockwise. Note that this is the
337  * standard mathematical definition of positive rotation and does not agree
338  * with the definition of roll given earlier.
339  * The range should at least be 17.45 rad/s (ie: ~1000 deg/s).
340  *
341  * automatic gyro-drift compensation is allowed but not required.
342  */
343 #define SENSOR_TYPE_GYROSCOPE (4)
344 
345 /*
346  * SENSOR_TYPE_LIGHT
347  * trigger-mode: on-change
348  * wake-up sensor: no
349  *
350  * The light sensor value is returned in SI lux units.
351  */
352 #define SENSOR_TYPE_LIGHT (5)
353 
354 /*
355  * SENSOR_TYPE_PRESSURE
356  * trigger-mode: continuous
357  * wake-up sensor: no
358  *
359  * The pressure sensor return the athmospheric pressure in hectopascal (hPa)
360  */
361 #define SENSOR_TYPE_PRESSURE (6)
362 
363 /* SENSOR_TYPE_TEMPERATURE is deprecated in the HAL */
364 #define SENSOR_TYPE_TEMPERATURE (7)
365 
366 /*
367  * SENSOR_TYPE_PROXIMITY
368  * trigger-mode: on-change
369  * wake-up sensor: yes
370  *
371  * The distance value is measured in centimeters. Note that some proximity
372  * sensors only support a binary "close" or "far" measurement. In this case,
373  * the sensor should report its maxRange value in the "far" state and a value
374  * less than maxRange in the "near" state.
375  */
376 #define SENSOR_TYPE_PROXIMITY (8)
377 
378 /*
379  * SENSOR_TYPE_GRAVITY
380  * trigger-mode: continuous
381  * wake-up sensor: no
382  *
383  * A gravity output indicates the direction of and magnitude of gravity in
384  * the devices's coordinates. On Earth, the magnitude is 9.8 m/s^2.
385  * Units are m/s^2. The coordinate system is the same as is used for the
386  * acceleration sensor. When the device is at rest, the output of the
387  * gravity sensor should be identical to that of the accelerometer.
388  */
389 #define SENSOR_TYPE_GRAVITY (9)
390 
391 /*
392  * SENSOR_TYPE_LINEAR_ACCELERATION
393  * trigger-mode: continuous
394  * wake-up sensor: no
395  *
396  * Indicates the linear acceleration of the device in device coordinates,
397  * not including gravity.
398  *
399  * The output is conceptually:
400  * output of TYPE_ACCELERATION - output of TYPE_GRAVITY
401  *
402  * Readings on all axes should be close to 0 when device lies on a table.
403  * Units are m/s^2.
404  * The coordinate system is the same as is used for the acceleration sensor.
405  */
406 #define SENSOR_TYPE_LINEAR_ACCELERATION (10)
407 
408 
409 /*
410  * SENSOR_TYPE_ROTATION_VECTOR
411  * trigger-mode: continuous
412  * wake-up sensor: no
413  *
414  * The rotation vector symbolizes the orientation of the device relative to the
415  * East-North-Up coordinates frame. It is usually obtained by integration of
416  * accelerometer, gyroscope and magnetometer readings.
417  *
418  * The East-North-Up coordinate system is defined as a direct orthonormal basis
419  * where:
420  * - X points east and is tangential to the ground.
421  * - Y points north and is tangential to the ground.
422  * - Z points towards the sky and is perpendicular to the ground.
423  *
424  * The orientation of the phone is represented by the rotation necessary to
425  * align the East-North-Up coordinates with the phone's coordinates. That is,
426  * applying the rotation to the world frame (X,Y,Z) would align them with the
427  * phone coordinates (x,y,z).
428  *
429  * The rotation can be seen as rotating the phone by an angle theta around
430  * an axis rot_axis to go from the reference (East-North-Up aligned) device
431  * orientation to the current device orientation.
432  *
433  * The rotation is encoded as the 4 (reordered) components of a unit quaternion:
434  * sensors_event_t.data[0] = rot_axis.x*sin(theta/2)
435  * sensors_event_t.data[1] = rot_axis.y*sin(theta/2)
436  * sensors_event_t.data[2] = rot_axis.z*sin(theta/2)
437  * sensors_event_t.data[3] = cos(theta/2)
438  * where
439  * - rot_axis.x,y,z are the North-East-Up coordinates of a unit length vector
440  * representing the rotation axis
441  * - theta is the rotation angle
442  *
443  * The quaternion must be of norm 1 (it is a unit quaternion). Failure to ensure
444  * this will cause erratic client behaviour.
445  *
446  * In addition, this sensor reports an estimated heading accuracy.
447  * sensors_event_t.data[4] = estimated_accuracy (in radians)
448  * The heading error must be less than estimated_accuracy 95% of the time
449  *
450  * This sensor must use a gyroscope and an accelerometer as main orientation
451  * change input.
452  *
453  * This sensor can also include magnetometer input to make up for gyro drift,
454  * but it cannot be implemented using only a magnetometer.
455  */
456 #define SENSOR_TYPE_ROTATION_VECTOR (11)
457 
458 /*
459  * SENSOR_TYPE_RELATIVE_HUMIDITY
460  * trigger-mode: on-change
461  * wake-up sensor: no
462  *
463  * A relative humidity sensor measures relative ambient air humidity and
464  * returns a value in percent.
465  */
466 #define SENSOR_TYPE_RELATIVE_HUMIDITY (12)
467 
468 /*
469  * SENSOR_TYPE_AMBIENT_TEMPERATURE
470  * trigger-mode: on-change
471  * wake-up sensor: no
472  *
473  * The ambient (room) temperature in degree Celsius.
474  */
475 #define SENSOR_TYPE_AMBIENT_TEMPERATURE (13)
476 
477 /*
478  * SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED
479  * trigger-mode: continuous
480  * wake-up sensor: no
481  *
482  * Similar to SENSOR_TYPE_MAGNETIC_FIELD, but the hard iron calibration is
483  * reported separately instead of being included in the measurement.
484  * Factory calibration and temperature compensation should still be applied to
485  * the "uncalibrated" measurement.
486  * Separating away the hard iron calibration estimation allows the system to
487  * better recover from bad hard iron estimation.
488  *
489  * All values are in micro-Tesla (uT) and measure the ambient magnetic
490  * field in the X, Y and Z axis. Assumptions that the the magnetic field
491  * is due to the Earth's poles should be avoided.
492  *
493  * The uncalibrated_magnetic event contains
494  * - 3 fields for uncalibrated measurement: x_uncalib, y_uncalib, z_uncalib.
495  * Each is a component of the measured magnetic field, with soft iron
496  * and temperature compensation applied, but not hard iron calibration.
497  * These values should be continuous (no re-calibration should cause a jump).
498  * - 3 fields for hard iron bias estimates: x_bias, y_bias, z_bias.
499  * Each field is a component of the estimated hard iron calibration.
500  * They represent the offsets to apply to the calibrated readings to obtain
501  * uncalibrated readings (x_uncalib ~= x_calibrated + x_bias)
502  * These values are expected to jump as soon as the estimate of the hard iron
503  * changes, and they should be stable the rest of the time.
504  *
505  * If this sensor is present, then the corresponding
506  * SENSOR_TYPE_MAGNETIC_FIELD must be present and both must return the
507  * same sensor_t::name and sensor_t::vendor.
508  *
509  * Minimum filtering should be applied to this sensor. In particular, low pass
510  * filters should be avoided.
511  *
512  * See SENSOR_TYPE_MAGNETIC_FIELD for more information
513  */
514 #define SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED (14)
515 
516 /*
517  * SENSOR_TYPE_GAME_ROTATION_VECTOR
518  * trigger-mode: continuous
519  * wake-up sensor: no
520  *
521  * Similar to SENSOR_TYPE_ROTATION_VECTOR, but not using the geomagnetic
522  * field. Therefore the Y axis doesn't point north, but instead to some other
523  * reference. That reference is allowed to drift by the same order of
524  * magnitude than the gyroscope drift around the Z axis.
525  *
526  * This sensor does not report an estimated heading accuracy:
527  * sensors_event_t.data[4] is reserved and should be set to 0
528  *
529  * In the ideal case, a phone rotated and returning to the same real-world
530  * orientation should report the same game rotation vector
531  * (without using the earth's geomagnetic field).
532  *
533  * This sensor must be based on a gyroscope. It cannot be implemented using
534  * a magnetometer.
535  *
536  * see SENSOR_TYPE_ROTATION_VECTOR for more details
537  */
538 #define SENSOR_TYPE_GAME_ROTATION_VECTOR (15)
539 
540 /*
541  * SENSOR_TYPE_GYROSCOPE_UNCALIBRATED
542  * trigger-mode: continuous
543  * wake-up sensor: no
544  *
545  * All values are in radians/second and measure the rate of rotation
546  * around the X, Y and Z axis. An estimation of the drift on each axis is
547  * reported as well.
548  *
549  * No gyro-drift compensation shall be performed.
550  * Factory calibration and temperature compensation should still be applied
551  * to the rate of rotation (angular speeds).
552  *
553  * The coordinate system is the same as is
554  * used for the acceleration sensor. Rotation is positive in the
555  * counter-clockwise direction (right-hand rule). That is, an observer
556  * looking from some positive location on the x, y or z axis at a device
557  * positioned on the origin would report positive rotation if the device
558  * appeared to be rotating counter clockwise. Note that this is the
559  * standard mathematical definition of positive rotation and does not agree
560  * with the definition of roll given earlier.
561  * The range should at least be 17.45 rad/s (ie: ~1000 deg/s).
562  *
563  * Content of an uncalibrated_gyro event: (units are rad/sec)
564  * x_uncalib : angular speed (w/o drift compensation) around the X axis
565  * y_uncalib : angular speed (w/o drift compensation) around the Y axis
566  * z_uncalib : angular speed (w/o drift compensation) around the Z axis
567  * x_bias : estimated drift around X axis in rad/s
568  * y_bias : estimated drift around Y axis in rad/s
569  * z_bias : estimated drift around Z axis in rad/s
570  *
571  * IMPLEMENTATION NOTES:
572  *
573  * If the implementation is not able to estimate the drift, then this
574  * sensor MUST NOT be reported by this HAL. Instead, the regular
575  * SENSOR_TYPE_GYROSCOPE is used without drift compensation.
576  *
577  * If this sensor is present, then the corresponding
578  * SENSOR_TYPE_GYROSCOPE must be present and both must return the
579  * same sensor_t::name and sensor_t::vendor.
580  */
581 #define SENSOR_TYPE_GYROSCOPE_UNCALIBRATED (16)
582 
583 
584 /*
585  * SENSOR_TYPE_SIGNIFICANT_MOTION
586  * trigger-mode: one-shot
587  * wake-up sensor: yes
588  *
589  * A sensor of this type triggers an event each time significant motion
590  * is detected and automatically disables itself.
591  * The only allowed value to return is 1.0.
592  *
593  * A significant motion is a motion that might lead to a change in the user
594  * location.
595  * Examples of such motions are:
596  * walking, biking, sitting in a moving car, coach or train.
597  * Examples of situations that should not trigger significant motion:
598  * - phone in pocket and person is not moving
599  * - phone is on a table, even if the table shakes a bit due to nearby traffic
600  * or washing machine
601  *
602  * A note on false positive / false negative / power consumption tradeoff
603  * - The goal of this sensor is to save power.
604  * - Triggering an event when the user is not moving (false positive) is costly
605  * in terms of power, so it should be avoided.
606  * - Not triggering an event when the user is moving (false negative) is
607  * acceptable as long as it is not done repeatedly. If the user has been
608  * walking for 10 seconds, not triggering an event within those 10 seconds
609  * is not acceptable.
610  *
611  * IMPORTANT NOTE: this sensor type is very different from other types
612  * in that it must work when the screen is off without the need of
613  * holding a partial wake-lock and MUST allow the SoC to go into suspend.
614  * When significant motion is detected, the sensor must awaken the SoC and
615  * the event be reported.
616  *
617  * If a particular hardware cannot support this mode of operation then this
618  * sensor type MUST NOT be reported by the HAL. ie: it is not acceptable
619  * to "emulate" this sensor in the HAL.
620  *
621  * The whole point of this sensor type is to save power by keeping the
622  * SoC in suspend mode when the device is at rest.
623  *
624  * When the sensor is not activated, it must also be deactivated in the
625  * hardware: it must not wake up the SoC anymore, even in case of
626  * significant motion.
627  *
628  * setDelay() has no effect and is ignored.
629  * Once a "significant motion" event is returned, a sensor of this type
630  * must disables itself automatically, as if activate(..., 0) had been called.
631  */
632 
633 #define SENSOR_TYPE_SIGNIFICANT_MOTION (17)
634 
635 
636 /*
637  * SENSOR_TYPE_STEP_DETECTOR
638  * trigger-mode: special
639  * wake-up sensor: no
640  *
641  * A sensor of this type triggers an event each time a step is taken
642  * by the user. The only allowed value to return is 1.0 and an event is
643  * generated for each step. Like with any other event, the timestamp
644  * indicates when the event (here the step) occurred, this corresponds to when
645  * the foot hit the ground, generating a high variation in acceleration.
646  *
647  * While this sensor operates, it shall not disrupt any other sensors, in
648  * particular, but not limited to, the accelerometer; which might very well
649  * be in use as well.
650  *
651  * This sensor must be low power. That is, if the step detection cannot be
652  * done in hardware, this sensor should not be defined. Also, when the
653  * step detector is activated and the accelerometer is not, only steps should
654  * trigger interrupts (not accelerometer data).
655  *
656  * setDelay() has no impact on this sensor type
657  */
658 
659 #define SENSOR_TYPE_STEP_DETECTOR (18)
660 
661 
662 /*
663  * SENSOR_TYPE_STEP_COUNTER
664  * trigger-mode: on-change
665  * wake-up sensor: no
666  *
667  * A sensor of this type returns the number of steps taken by the user since
668  * the last reboot while activated. The value is returned as a uint64_t and is
669  * reset to zero only on a system / android reboot.
670  *
671  * The timestamp of the event is set to the time when the first step
672  * for that event was taken.
673  * See SENSOR_TYPE_STEP_DETECTOR for the signification of the time of a step.
674  *
675  * The minimum size of the hardware's internal counter shall be 16 bits
676  * (this restriction is here to avoid too frequent wake-ups when the
677  * delay is very large).
678  *
679  * IMPORTANT NOTE: this sensor type is different from other types
680  * in that it must work when the screen is off without the need of
681  * holding a partial wake-lock and MUST allow the SoC to go into suspend.
682  * Unlike other sensors, while in suspend mode this sensor must stay active,
683  * no events are reported during that time but, steps continue to be
684  * accounted for; an event will be reported as soon as the SoC resumes if
685  * the timeout has expired.
686  *
687  * In other words, when the screen is off and the device allowed to
688  * go into suspend mode, we don't want to be woken up, regardless of the
689  * setDelay() value, but the steps shall continue to be counted.
690  *
691  * The driver must however ensure that the internal step count never
692  * overflows. It is allowed in this situation to wake the SoC up so the
693  * driver can do the counter maintenance.
694  *
695  * While this sensor operates, it shall not disrupt any other sensors, in
696  * particular, but not limited to, the accelerometer; which might very well
697  * be in use as well.
698  *
699  * If a particular hardware cannot support these modes of operation then this
700  * sensor type MUST NOT be reported by the HAL. ie: it is not acceptable
701  * to "emulate" this sensor in the HAL.
702  *
703  * This sensor must be low power. That is, if the step detection cannot be
704  * done in hardware, this sensor should not be defined. Also, when the
705  * step counter is activated and the accelerometer is not, only steps should
706  * trigger interrupts (not accelerometer data).
707  *
708  * The whole point of this sensor type is to save power by keeping the
709  * SoC in suspend mode when the device is at rest.
710  */
711 
712 #define SENSOR_TYPE_STEP_COUNTER (19)
713 
714 /*
715  * SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR
716  * trigger-mode: continuous
717  * wake-up sensor: no
718  *
719  * Similar to SENSOR_TYPE_ROTATION_VECTOR, but using a magnetometer instead
720  * of using a gyroscope.
721  *
722  * This sensor must be based on a magnetometer. It cannot be implemented using
723  * a gyroscope, and gyroscope input cannot be used by this sensor, as the
724  * goal of this sensor is to be low power.
725  * The accelerometer can be (and usually is) used.
726  *
727  * Just like SENSOR_TYPE_ROTATION_VECTOR, this sensor reports an estimated
728  * heading accuracy:
729  * sensors_event_t.data[4] = estimated_accuracy (in radians)
730  * The heading error must be less than estimated_accuracy 95% of the time
731  *
732  * see SENSOR_TYPE_ROTATION_VECTOR for more details
733  */
734 #define SENSOR_TYPE_GEOMAGNETIC_ROTATION_VECTOR (20)
735 
736 /**
737  * Values returned by the accelerometer in various locations in the universe.
738  * all values are in SI units (m/s^2)
739  */
740 #define GRAVITY_SUN (275.0f)
741 #define GRAVITY_EARTH (9.80665f)
742 
743 /** Maximum magnetic field on Earth's surface */
744 #define MAGNETIC_FIELD_EARTH_MAX (60.0f)
745 
746 /** Minimum magnetic field on Earth's surface */
747 #define MAGNETIC_FIELD_EARTH_MIN (30.0f)
748 
749 
750 /**
751  * status of orientation sensor
752  */
753 
754 #define SENSOR_STATUS_UNRELIABLE 0
755 #define SENSOR_STATUS_ACCURACY_LOW 1
756 #define SENSOR_STATUS_ACCURACY_MEDIUM 2
757 #define SENSOR_STATUS_ACCURACY_HIGH 3
758 
759 
760 /**
761  * sensor event data
762  */
763 typedef struct {
764  union {
765  float v[3];
766  struct {
767  float x;
768  float y;
769  float z;
770  };
771  struct {
772  float azimuth;
773  float pitch;
774  float roll;
775  };
776  };
777  int8_t status;
778  uint8_t reserved[3];
779 } sensors_vec_t;
780 
781 /**
782  * uncalibrated gyroscope and magnetometer event data
783  */
784 typedef struct {
785  union {
786  float uncalib[3];
787  struct {
788  float x_uncalib;
789  float y_uncalib;
790  float z_uncalib;
791  };
792  };
793  union {
794  float bias[3];
795  struct {
796  float x_bias;
797  float y_bias;
798  float z_bias;
799  };
800  };
802 
803 typedef struct meta_data_event {
804  int32_t what;
805  int32_t sensor;
807 
808 /**
809  * Union of the various types of sensor data
810  * that can be returned.
811  */
812 typedef struct sensors_event_t {
813  /* must be sizeof(struct sensors_event_t) */
814  int32_t version;
815 
816  /* sensor identifier */
817  int32_t sensor;
818 
819  /* sensor type */
820  int32_t type;
821 
822  /* reserved */
823  int32_t reserved0;
824 
825  /* time is in nanosecond */
826  int64_t timestamp;
827 
828  union {
829  union {
830  float data[16];
831 
832  /* acceleration values are in meter per second per second (m/s^2) */
834 
835  /* magnetic vector values are in micro-Tesla (uT) */
837 
838  /* orientation values are in degrees */
840 
841  /* gyroscope values are in rad/s */
843 
844  /* temperature is in degrees centigrade (Celsius) */
845  float temperature;
846 
847  /* distance in centimeters */
848  float distance;
849 
850  /* light in SI lux units */
851  float light;
852 
853  /* pressure in hectopascal (hPa) */
854  float pressure;
855 
856  /* relative humidity in percent */
858 
859  /* uncalibrated gyroscope values are in rad/s */
861 
862  /* uncalibrated magnetometer values are in micro-Teslas */
864 
865  /* this is a special event. see SENSOR_TYPE_META_DATA above.
866  * sensors_meta_data_event_t events are all reported with a type of
867  * SENSOR_TYPE_META_DATA. The handle is ignored and must be zero.
868  */
870  };
871 
872  union {
873  uint64_t data[8];
874 
875  /* step-counter */
876  uint64_t step_counter;
877  } u64;
878  };
879  uint32_t reserved1[4];
881 
882 
883 /* see SENSOR_TYPE_META_DATA */
885 
886 
887 struct sensor_t;
888 
889 /**
890  * Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
891  * and the fields of this data structure must begin with hw_module_t
892  * followed by module specific information.
893  */
896 
897  /**
898  * Enumerate all available sensors. The list is returned in "list".
899  * @return number of sensors in the list
900  */
901  int (*get_sensors_list)(struct sensors_module_t* module,
902  struct sensor_t const** list);
903 };
904 
905 struct sensor_t {
906 
907  /* Name of this sensor.
908  * All sensors of the same "type" must have a different "name".
909  */
910  const char* name;
911 
912  /* vendor of the hardware part */
913  const char* vendor;
914 
915  /* version of the hardware part + driver. The value of this field
916  * must increase when the driver is updated in a way that changes the
917  * output of this sensor. This is important for fused sensors when the
918  * fusion algorithm is updated.
919  */
920  int version;
921 
922  /* handle that identifies this sensors. This handle is used to reference
923  * this sensor throughout the HAL API.
924  */
925  int handle;
926 
927  /* this sensor's type. */
928  int type;
929 
930  /* maximum range of this sensor's value in SI units */
931  float maxRange;
932 
933  /* smallest difference between two values reported by this sensor */
934  float resolution;
935 
936  /* rough estimate of this sensor's power consumption in mA */
937  float power;
938 
939  /* this value depends on the trigger mode:
940  *
941  * continuous: minimum sample period allowed in microseconds
942  * on-change : 0
943  * one-shot :-1
944  * special : 0, unless otherwise noted
945  */
946  int32_t minDelay;
947 
948  /* number of events reserved for this sensor in the batch mode FIFO.
949  * If there is a dedicated FIFO for this sensor, then this is the
950  * size of this FIFO. If the FIFO is shared with other sensors,
951  * this is the size reserved for that sensor and it can be zero.
952  */
954 
955  /* maximum number of events of this sensor that could be batched.
956  * This is especially relevant when the FIFO is shared between
957  * several sensors; this value is then set to the size of that FIFO.
958  */
960 
961  /* reserved fields, must be zero */
962  void* reserved[6];
963 };
964 
965 
966 /*
967  * sensors_poll_device_t is used with SENSORS_DEVICE_API_VERSION_0_1
968  * and is present for backward binary and source compatibility.
969  * (see documentation of the hooks in struct sensors_poll_device_1 below)
970  */
973  int (*activate)(struct sensors_poll_device_t *dev,
974  int handle, int enabled);
975  int (*setDelay)(struct sensors_poll_device_t *dev,
976  int handle, int64_t ns);
977  int (*poll)(struct sensors_poll_device_t *dev,
978  sensors_event_t* data, int count);
979 };
980 
981 /*
982  * struct sensors_poll_device_1 is used with SENSORS_DEVICE_API_VERSION_1_0
983  */
984 typedef struct sensors_poll_device_1 {
985  union {
986  /* sensors_poll_device_1 is compatible with sensors_poll_device_t,
987  * and can be down-cast to it
988  */
990 
991  struct {
993 
994  /* Activate/de-activate one sensor.
995  *
996  * handle is the handle of the sensor to change.
997  * enabled set to 1 to enable, or 0 to disable the sensor.
998  *
999  * if enabled is set to 1, the sensor is activated even if
1000  * setDelay() wasn't called before. In this case, a default rate
1001  * should be used.
1002  *
1003  * unless otherwise noted in the sensor types definitions, an
1004  * activated sensor never prevents the SoC to go into suspend
1005  * mode; that is, the HAL shall not hold a partial wake-lock on
1006  * behalf of applications.
1007  *
1008  * one-shot sensors de-activate themselves automatically upon
1009  * receiving an event and they must still accept to be deactivated
1010  * through a call to activate(..., ..., 0).
1011  *
1012  * if "enabled" is 1 and the sensor is already activated, this
1013  * function is a no-op and succeeds.
1014  *
1015  * if "enabled" is 0 and the sensor is already de-activated,
1016  * this function is a no-op and succeeds.
1017  *
1018  * return 0 on success, negative errno code otherwise
1019  */
1020  int (*activate)(struct sensors_poll_device_t *dev,
1021  int handle, int enabled);
1022 
1023  /**
1024  * Set the events's period in nanoseconds for a given sensor.
1025  *
1026  * What the period_ns parameter means depends on the specified
1027  * sensor's trigger mode:
1028  *
1029  * continuous: setDelay() sets the sampling rate.
1030  * on-change: setDelay() limits the delivery rate of events
1031  * one-shot: setDelay() is ignored. it has no effect.
1032  * special: see specific sensor type definitions
1033  *
1034  * For continuous and on-change sensors, if the requested value is
1035  * less than sensor_t::minDelay, then it's silently clamped to
1036  * sensor_t::minDelay unless sensor_t::minDelay is 0, in which
1037  * case it is clamped to >= 1ms.
1038  *
1039  * setDelay will not be called when the sensor is in batching mode.
1040  * In this case, batch() will be called with the new period.
1041  *
1042  * @return 0 if successful, < 0 on error
1043  */
1044  int (*setDelay)(struct sensors_poll_device_t *dev,
1045  int handle, int64_t period_ns);
1046 
1047  /**
1048  * Returns an array of sensor data.
1049  * This function must block until events are available.
1050  *
1051  * return the number of events read on success, or -errno in case
1052  * of an error.
1053  *
1054  * The number of events returned in data must be less or equal
1055  * to the "count" argument.
1056  *
1057  * This function shall never return 0 (no event).
1058  */
1059  int (*poll)(struct sensors_poll_device_t *dev,
1060  sensors_event_t* data, int count);
1061  };
1062  };
1063 
1064 
1065  /*
1066  * Enables batch mode for the given sensor and sets the delay between events
1067  *
1068  * A timeout value of zero disables batch mode for the given sensor.
1069  *
1070  * The period_ns parameter is equivalent to calling setDelay() -- this
1071  * function both enables or disables the batch mode AND sets the events's
1072  * period in nanosecond. See setDelay() above for a detailed explanation of
1073  * the period_ns parameter.
1074  *
1075  * BATCH MODE:
1076  * -----------
1077  * In non-batch mode, all sensor events must be reported as soon as they
1078  * are detected. For example, an accelerometer activated at 50Hz will
1079  * trigger interrupts 50 times per second.
1080  * While in batch mode, sensor events do not need to be reported as soon
1081  * as they are detected. They can be temporarily stored in batches and
1082  * reported in batches, as long as no event is delayed by more than
1083  * "timeout" nanoseconds. That is, all events since the previous batch
1084  * are recorded and returned all at once. This allows to reduce the amount
1085  * of interrupts sent to the SoC, and allow the SoC to switch to a lower
1086  * power state (Idle) while the sensor is capturing and batching data.
1087  *
1088  * setDelay() is not affected and it behaves as usual.
1089  *
1090  * Each event has a timestamp associated with it, the timestamp
1091  * must be accurate and correspond to the time at which the event
1092  * physically happened.
1093  *
1094  * Batching does not modify the behavior of poll(): batches from different
1095  * sensors can be interleaved and split. As usual, all events from the same
1096  * sensor are time-ordered.
1097  *
1098  * BEHAVIOUR OUTSIDE OF SUSPEND MODE:
1099  * ----------------------------------
1100  *
1101  * When the SoC is awake (not in suspend mode), events must be reported in
1102  * batches at least every "timeout". No event shall be dropped or lost.
1103  * If internal h/w FIFOs fill-up before the timeout, then events are
1104  * reported at that point to ensure no event is lost.
1105  *
1106  *
1107  * NORMAL BEHAVIOR IN SUSPEND MODE:
1108  * ---------------------------------
1109  *
1110  * By default, batch mode doesn't significantly change the interaction with
1111  * suspend mode. That is, sensors must continue to allow the SoC to
1112  * go into suspend mode and sensors must stay active to fill their
1113  * internal FIFO. In this mode, when the FIFO fills up, it shall wrap
1114  * around (basically behave like a circular buffer, overwriting events).
1115  * As soon as the SoC comes out of suspend mode, a batch is produced with
1116  * as much as the recent history as possible, and batch operation
1117  * resumes as usual.
1118  *
1119  * The behavior described above allows applications to record the recent
1120  * history of a set of sensor while keeping the SoC into suspend. It
1121  * also allows the hardware to not have to rely on a wake-up interrupt line.
1122  *
1123  * WAKE_UPON_FIFO_FULL BEHAVIOR IN SUSPEND MODE:
1124  * ----------------------------------------------
1125  *
1126  * There are cases, however, where an application cannot afford to lose
1127  * any events, even when the device goes into suspend mode.
1128  * For a given rate, if a sensor has the capability to store at least 10
1129  * seconds worth of events in its FIFO and is able to wake up the Soc, it
1130  * can implement an optional secondary mode: the WAKE_UPON_FIFO_FULL mode.
1131  *
1132  * The caller will set the SENSORS_BATCH_WAKE_UPON_FIFO_FULL flag to
1133  * activate this mode. If the sensor does not support this mode, batch()
1134  * will fail when the flag is set.
1135  *
1136  * When running with the WAKE_UPON_FIFO_FULL flag set, no events can be
1137  * lost. When the FIFO is getting full, the sensor must wake up the SoC from
1138  * suspend and return a batch before the FIFO fills-up.
1139  * Depending on the device, it might take a few miliseconds for the SoC to
1140  * entirely come out of suspend and start flushing the FIFO. Enough head
1141  * room must be allocated in the FIFO to allow the device to entirely come
1142  * out of suspend without the FIFO overflowing (no events shall be lost).
1143  *
1144  * Implementing the WAKE_UPON_FIFO_FULL mode is optional.
1145  * If the hardware cannot support this mode, or if the physical
1146  * FIFO is so small that the device would never be allowed to go into
1147  * suspend for at least 10 seconds, then this function MUST fail when
1148  * the flag SENSORS_BATCH_WAKE_UPON_FIFO_FULL is set, regardless of
1149  * the value of the timeout parameter.
1150  *
1151  *
1152  * DRY RUN:
1153  * --------
1154  *
1155  * If the flag SENSORS_BATCH_DRY_RUN is set, this function returns
1156  * without modifying the batch mode or the event period and has no side
1157  * effects, but returns errors as usual (as it would if this flag was
1158  * not set). This flag is used to check if batch mode is available for a
1159  * given configuration -- in particular for a given sensor at a given rate.
1160  *
1161  *
1162  * Return values:
1163  * --------------
1164  *
1165  * Because sensors must be independent, the return value must not depend
1166  * on the state of the system (whether another sensor is on or not),
1167  * nor on whether the flag SENSORS_BATCH_DRY_RUN is set (in other words,
1168  * if a batch call with SENSORS_BATCH_DRY_RUN is successful,
1169  * the same call without SENSORS_BATCH_DRY_RUN must succeed as well).
1170  *
1171  * When timeout is not 0:
1172  * If successful, 0 is returned.
1173  * If the specified sensor doesn't support batch mode, return -EINVAL.
1174  * If the specified sensor's trigger-mode is one-shot, return -EINVAL.
1175  * If WAKE_UPON_FIFO_FULL is specified and the specified sensor's internal
1176  * FIFO is too small to store at least 10 seconds worth of data at the
1177  * given rate, -EINVAL is returned. Note that as stated above, this has to
1178  * be determined at compile time, and not based on the state of the
1179  * system.
1180  * If some other constraints above cannot be satisfied, return -EINVAL.
1181  *
1182  * Note: the timeout parameter, when > 0, has no impact on whether this
1183  * function succeeds or fails.
1184  *
1185  * When timeout is 0:
1186  * The caller will never set the wake_upon_fifo_full flag.
1187  * The function must succeed, and batch mode must be deactivated.
1188  *
1189  * Independently of whether DRY_RUN is specified, When the call to batch()
1190  * fails, no state should be changed. In particular, a failed call to
1191  * batch() should not change the rate of the sensor. Example:
1192  * setDelay(..., 10ms)
1193  * batch(..., 20ms, ...) fails
1194  * rate should stay 10ms.
1195  *
1196  *
1197  * IMPLEMENTATION NOTES:
1198  * ---------------------
1199  *
1200  * Batch mode, if supported, should happen at the hardware level,
1201  * typically using hardware FIFOs. In particular, it SHALL NOT be
1202  * implemented in the HAL, as this would be counter productive.
1203  * The goal here is to save significant amounts of power.
1204  *
1205  * In some implementations, events from several sensors can share the
1206  * same physical FIFO. In that case, all events in the FIFO can be sent and
1207  * processed by the HAL as soon as one batch must be reported.
1208  * For example, if the following sensors are activated:
1209  * - accelerometer batched with timeout = 20s
1210  * - gyroscope batched with timeout = 5s
1211  * then the accelerometer batches can be reported at the same time the
1212  * gyroscope batches are reported (every 5 seconds)
1213  *
1214  * Batch mode can be enabled or disabled at any time, in particular
1215  * while the specified sensor is already enabled, and this shall not
1216  * result in the loss of events.
1217  *
1218  * COMPARATIVE IMPORTANCE OF BATCHING FOR DIFFERENT SENSORS:
1219  * ---------------------------------------------------------
1220  *
1221  * On platforms on which hardware fifo size is limited, the system designers
1222  * might have to choose how much fifo to reserve for each sensor. To help
1223  * with this choice, here is a list of applications made possible when
1224  * batching is implemented on the different sensors.
1225  *
1226  * High value: Low power pedestrian dead reckoning
1227  * Target batching time: 20 seconds to 1 minute
1228  * Sensors to batch:
1229  * - Step detector
1230  * - Rotation vector or game rotation vector at 5Hz
1231  * Gives us step and heading while letting the SoC go to Suspend.
1232  *
1233  * High value: Medium power activity/gesture recognition
1234  * Target batching time: 3 seconds
1235  * Sensors to batch: accelerometer between 20Hz and 50Hz
1236  * Allows recognizing arbitrary activities and gestures without having
1237  * to keep the SoC fully awake while the data is collected.
1238  *
1239  * Medium-high value: Interrupt load reduction
1240  * Target batching time: < 1 second
1241  * Sensors to batch: any high frequency sensor.
1242  * If the gyroscope is set at 800Hz, even batching just 10 gyro events can
1243  * reduce the number of interrupts from 800/second to 80/second.
1244  *
1245  * Medium value: Continuous low frequency data collection
1246  * Target batching time: > 1 minute
1247  * Sensors to batch: barometer, humidity sensor, other low frequency
1248  * sensors.
1249  * Allows creating monitoring applications at low power.
1250  *
1251  * Medium value: Continuous full-sensors collection
1252  * Target batching time: > 1 minute
1253  * Sensors to batch: all, at high frequencies
1254  * Allows full collection of sensor data while leaving the SoC in
1255  * suspend mode. Only to consider if fifo space is not an issue.
1256  *
1257  * In each of the cases above, if WAKE_UPON_FIFO_FULL is implemented, the
1258  * applications might decide to let the SoC go to suspend, allowing for even
1259  * more power savings.
1260  */
1261  int (*batch)(struct sensors_poll_device_1* dev,
1262  int handle, int flags, int64_t period_ns, int64_t timeout);
1263 
1264  /*
1265  * Flush adds a META_DATA_FLUSH_COMPLETE event (sensors_event_meta_data_t)
1266  * to the end of the "batch mode" FIFO for the specified sensor and flushes
1267  * the FIFO; those events are delivered as usual (i.e.: as if the batch
1268  * timeout had expired) and removed from the FIFO.
1269  *
1270  * See the META_DATA_FLUSH_COMPLETE section for details about the
1271  * META_DATA_FLUSH_COMPLETE event.
1272  *
1273  * The flush happens asynchronously (i.e.: this function must return
1274  * immediately).
1275  *
1276  * If the implementation uses a single FIFO for several sensors, that
1277  * FIFO is flushed and the META_DATA_FLUSH_COMPLETE event is added only
1278  * for the specified sensor.
1279  *
1280  * If the specified sensor wasn't in batch mode, flush succeeds and
1281  * promptly sends a META_DATA_FLUSH_COMPLETE event for that sensor.
1282  *
1283  * If the FIFO was empty at the time of the call, flush returns
1284  * 0 (success) and promptly sends a META_DATA_FLUSH_COMPLETE event
1285  * for that sensor.
1286  *
1287  * If the specified sensor wasn't enabled, flush returns -EINVAL.
1288  *
1289  * return 0 on success, negative errno code otherwise.
1290  */
1291  int (*flush)(struct sensors_poll_device_1* dev, int handle);
1292 
1293  void (*reserved_procs[8])(void);
1294 
1296 
1297 
1298 
1299 /** convenience API for opening and closing a device */
1300 
1301 static inline int sensors_open(const struct hw_module_t* module,
1302  struct sensors_poll_device_t** device) {
1303  return module->methods->open(module,
1304  SENSORS_HARDWARE_POLL, (struct hw_device_t**)device);
1305 }
1306 
1307 static inline int sensors_close(struct sensors_poll_device_t* device) {
1308  return device->common.close(&device->common);
1309 }
1310 
1311 static inline int sensors_open_1(const struct hw_module_t* module,
1312  sensors_poll_device_1_t** device) {
1313  return module->methods->open(module,
1314  SENSORS_HARDWARE_POLL, (struct hw_device_t**)device);
1315 }
1316 
1317 static inline int sensors_close_1(sensors_poll_device_1_t* device) {
1318  return device->common.close(&device->common);
1319 }
1320 
1321 __END_DECLS
1322 
1323 #endif // ANDROID_SENSORS_INTERFACE_H