Lines Matching full:code
30 <li><code>get_sensors_list</code> - Returns the list of all sensors. </li>
31 <li><code>activate</code> - Starts or stops a sensor. </li>
32 <li><code>batch</code> - Sets a sensor?s parameters such as sampling frequency and maximum
34 <li><code>setDelay</code> - Used only in HAL version 1.0. Sets the sampling frequency for a
36 <li><code>flush</code> - Flushes the FIFO of the specified sensor and reports a flush complete
38 <li><code>poll</code> - Returns available sensor events. </li>
45 <li><code>sensors_module_t</code></li>
46 <li><code>sensors_poll_device_t</code></li>
47 <li><code>sensor_t</code></li>
48 <li><code>sensors_event_t</code></li>
60 <code>getDefaultSensor(int sensorType, bool wakeUp)</code>.</p>
66 <p><code>sensor_handle</code> is the handle of the sensor to activate/deactivate. A sensor?s
67 handle is defined by the <code>handle</code> field of its <a href="#sensor_t">sensor_t</a> structure.</p>
68 <p><code>enabled</code> is set to 1 to enable or 0 to disable the sensor.</p>
70 and they must still accept to be deactivated through a call to <code>activate(...,
71 enabled=0)</code>.</p>
77 <p>If <code>enabled</code> is 1 and the sensor is already activated, this function is a no-op
79 <p>If <code>enabled</code> is 0 and the sensor is already deactivated, this function is a no-op
95 <p><code>sensor_handle</code> is the handle of the sensor to configure.</p>
96 <p><code>flags</code> is currently unused.</p>
97 <p><code>sampling_period_ns</code> is the sampling period at which the sensor should run, in
99 <p><code>max_report_latency_ns</code> is the maximum time by which events can be delayed before
103 <p>What the <code>sampling_period_ns</code> parameter means depends on the specified sensor's
106 <li> Continuous: <code>sampling_period_ns</code> is the sampling rate, meaning the rate at which
108 <li> On-change: <code>sampling_period_ns</code> limits the sampling rate of events, meaning
109 events are generated no faster than every <code>sampling_period_ns</code> nanoseconds. There
110 might be periods longer than <code>sampling_period_ns</code> where no event is generated if
114 <li> One-shot: <code>sampling_period_ns</code> is ignored. It has no effect. </li>
116 descriptions</a> for details on how <code>sampling_period_ns</code> is used
120 about the impact of <code>sampling_period_ns</code> in the different modes.</p>
123 <li> if <code>sampling_period_ns</code> is less than
124 <code>sensor_t.minDelay</code>, then the HAL implementation must silently
125 clamp it to <code>max(sensor_t.minDelay, 1ms)</code>. Android
127 <li> if <code>sampling_period_ns</code> is greater than
128 <code>sensor_t.maxDelay</code>, then the HAL
129 implementation must silently truncate it to <code>sensor_t.maxDelay</code>. </li>
159 <p><code>max_report_latency_ns</code> sets the maximum time in nanoseconds, by which events can
165 <p>For example, an accelerometer activated at 50Hz with <code>max_report_latency_ns=0</code>
167 <p>When <code>max_report_latency_ns>0</code>, sensor events do not need to be reported as soon
179 modify the behavior of <code>poll</code>: events from different sensors can be interleaved,
191 Instead, the <code>batch</code> function is called to set the
192 <code>sampling_period_ns</code> parameter.</p>
203 was empty at the time of the call, <code>flush</code> must still succeed and send a flush
206 <p>When <code>flush</code> is called, even if a flush event is already in the FIFO for that
208 the FIFO must be flushed. The number of <code>flush</code> calls must be
210 <p><code>flush</code> does not apply to <a href="report-modes.html#one-shot">one-shot</a>
211 sensors; if <code>sensor_handle</code> refers to a one-shot sensor,
212 <code>flush</code> must return <code>-EINVAL</code> and not generate any
214 <p>This function returns 0 on success, <code>-EINVAL</code> if the specified sensor is a
219 <p>Returns an array of sensor data by filling the <code>data</code> argument. This function
222 <p>The number of events returned in <code>data</code> must be less or equal to
223 the <code>count</code> argument. This function shall never return 0 (no event).</p>
225 <p>When the device boots, <code>get_sensors_list</code> is called.</p>
226 <p>When a sensor gets activated, the <code>batch</code> function will be called with the
227 requested parameters, followed by <code>activate(..., enable=1)</code>.</p>
228 <p>Note that in HAL version 1_0, the order was the opposite: <code>activate</code> was called
229 first, followed by <code>set_delay</code>.</p>
231 activated, the <code>batch</code> function is called.</p>
232 <p><code>flush</code> can be called at any time, even on non-activated sensors (in which case
233 it must return <code>-EINVAL</code>)</p>
234 <p>When a sensor gets deactivated, <code>activate(..., enable=0)</code> will be called.</p>
235 <p>In parallel to those calls, the <code>poll</code> function will be called repeatedly to
236 request data. <code>poll</code> can be called even when no sensors are activated.</p>
238 <p><code>sensors_module_t</code> is the type used to create the Android hardware module for the
240 <code>HAL_MODULE_INFO_SYM</code> of this type to expose the <a
242 of <code>sensors_module_t</code> in <a
244 definition of <code>hw_module_t</code> for more information.</p>
246 <p><code>sensors_poll_device_1_t</code> contains the rest of the methods defined above:
247 <code>activate</code>, <code>batch</code>, <code>flush</code> and
248 <code>poll</code>. Its <code>common</code> field (of type <a
252 <p><code>sensor_t</code> represents an <a href="index.html">Android sensor</a>. Here are some of its important fields:</p>
263 non-official sensor types, <code>type</code> must start with <code>SENSOR_TYPE_DEVICE_PRIVATE_BASE</code></p>
265 type, set to <code>SENSOR_STRING_TYPE_*</code>. When the sensor has a manufacturer specific
266 type, <code>stringType</code
269 <code>stringType=?com.fictional_company.cool_product.unicorn_detector?</code>.
270 The <code>stringType</code> is used to uniquely identify non-official sensors types. See <a
277 monitor</a> have a mandatory <code>requiredPermission</code>. All sensors
281 will have <code>flags = SENSOR_FLAG_ONE_SHOT_MODE | SENSOR_FLAG_WAKE_UP</code>. The bits of
285 within <code>[-maxRange; maxRange]</code>. Note that this means the total range of the
286 sensor in the generic sense is <code>2*maxRange</code>. When the sensor reports values over
288 accelerometer will report <code>maxRange = 2*9.81 = 2g</code>.</p>
290 Usually computed based on <code>maxRange</code> and the number of bits in the measurement.</p>
299 consumption while moving is the one reported in the <code>power</code> field.</p>
301 corresponding to the fastest rate the sensor supports. See <a href="#sampling_period_ns">sampling_period_ns</a> for details on how this value is used. Beware that <code>minDelay</code> is expressed in
302 microseconds while <code>sampling_period_ns</code> is in nanoseconds. For on-change and
303 special reporting mode sensors, unless otherwise specified, <code>minDelay</code> must be 0.
306 microseconds, corresponding to the slowest rate the sensor supports. See <a href="#sampling_period_ns">sampling_period_ns</a> for details on how this value is used. Beware that <code>maxDelay</code> is expressed in
307 microseconds while <code>sampling_period_ns</code> is in nanoseconds. For special and
308 one-shot sensors, <code>maxDelay</code> must be 0.</p>
311 <code>fifoReservedEventCount</code> is the size of this dedicated FIFO. If the FIFO is
312 shared with other sensors, <code>fifoReservedEventCount</code> is the size of the part of
317 <code>fifoReservedEventCount</code>. This value is used to estimate how quickly the FIFO
320 <code>fifoMaxEventCount</code> is 0. See <a href="batching.html">Batching</a> for more details.</p>
326 protected by the <code>SENSOR_PERMISSION_BODY_SENSORS</code> permission.</p>
329 href="#poll">poll</a> function are of <code>type sensors_event_t</code>. Here are some
330 important fields of <code>sensors_event_t</code>:</p>
331 <p><strong>version:</strong> Must be <code>sizeof(struct sensors_event_t)</code></p>
333 <code>sensor_t.handle</code>.</p>
335 <code>sensor_t.type</code>.</p>
338 not the time the event was reported. <code>timestamp</code> must be synchronized with the
339 <code>elapsedRealtimeNano</code> clock, and in the case of continuous sensors, the jitter
344 <code>elapsedRealtimeNano</code> clock, as the sensor clock drifts.</p>
350 readings is also reported as part of the data, through a <code>status</code> field. This
356 <code>sensors_event_meta_data_t = sensors_event_t</code>. They are returned together with
358 <p><strong>version:</strong> Must be <code>META_DATA_VERSION</code></p>
359 <p><strong>type:</strong> Must be <code>SENSOR_TYPE_META_DATA</code></p>
362 single valid metadata type: <code>META_DATA_FLUSH_COMPLETE</code>.</p>
363 <p><code>META_DATA_FLUSH_COMPLETE</code> events represent the completion of the flush of a
364 sensor FIFO. When <code>meta_data.what=META_DATA_FLUSH_COMPLETE</code>, <code>meta_data.sensor</code>
366 generated when and only when <code>flush</code> is called on a sensor. See the section on
