1page.title=Suspend mode
2@jd:body
3
4<!--
5    Copyright 2014 The Android Open Source Project
6
7    Licensed under the Apache License, Version 2.0 (the "License");
8    you may not use this file except in compliance with the License.
9    You may obtain a copy of the License at
10
11        http://www.apache.org/licenses/LICENSE-2.0
12
13    Unless required by applicable law or agreed to in writing, software
14    distributed under the License is distributed on an "AS IS" BASIS,
15    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
16    See the License for the specific language governing permissions and
17    limitations under the License.
18-->
19<div id="qv-wrapper">
20  <div id="qv">
21    <h2>In this document</h2>
22    <ol id="auto-toc">
23    </ol>
24  </div>
25</div>
26
27<h2 id="soc_power_states">SoC power states</h2>
28<p>The power states of the system on a chip (SoC) are: on, idle, and suspend. “On” is when the
29  SoC is running. “Idle” is a medium power mode where the SoC is powered but
30  doesn't perform any tasks. “Suspend” is a low-power mode where the SoC is not
31  powered. The power consumption of the device in this mode is usually 100 times
32  less than in the “On” mode.</p>
33<h2 id="non-wake-up_sensors">Non-wake-up sensors</h2>
34<p>Non-wake-up sensors are sensors that do not prevent the SoC
35  from going into suspend mode and do not wake the SoC up to report data. In
36  particular, the drivers are not allowed to hold wake-locks. It is the
37  responsibility of applications to keep a partial wake lock should they wish to
38  receive events from non-wake-up sensors while the screen is off. While the SoC
39  is in suspend mode, the sensors must continue to function and generate events,
40  which are put in a hardware FIFO. (See <a
41  href="batching.html">Batching</a> for more details.) The events in the
42  FIFO are delivered to the applications when the SoC wakes up. If the FIFO is
43  too small to store all events, the older events are lost; the oldest data is dropped to accommodate
44  the latest data. In the extreme case where the FIFO is nonexistent, all events
45  generated while the SoC is in suspend mode are lost. One exception is the
46  latest event from each on-change sensor: the last event <a href="batching.html#precautions_to_take_when_batching_non-wake-up_on-change_sensors">must be saved </a>outside of the FIFO so it cannot be lost.</p>
47<p>As soon as the SoC gets out of suspend mode, all events from the FIFO are
48  reported and operations resume as normal.</p>
49<p>Applications using non-wake-up sensors should either hold a wake lock to ensure
50  the system doesn't go to suspend, unregister from the sensors when they do
51  not need them, or expect to lose events while the SoC is in suspend mode.</p>
52<h2 id="wake-up_sensors">Wake-up sensors</h2>
53<p>In opposition to non-wake-up sensors, wake-up sensors ensure that their data is
54  delivered independently of the state of the SoC. While the SoC is awake, the
55  wake-up sensors behave like non-wake-up-sensors. When the SoC is asleep,
56  wake-up sensors must wake up the SoC to deliver events. They must still let the
57  SoC go into suspend mode, but must also wake it up when an event needs to be
58  reported. That is, the sensor must wake the SoC up and deliver the events
59  before the maximum reporting latency has elapsed or the hardware FIFO gets full.
60  See <a href="batching.html">Batching</a> for more details.</p>
61<p>To ensure the applications have the time to receive the event before the SoC
62  goes back to sleep, the driver must hold a &quot;timeout wake lock&quot; for 200
63  milliseconds each time an event is being reported. <em>That is, the SoC should not
64  be allowed to go back to sleep in the 200 milliseconds following a wake-up
65  interrupt.</em> This requirement will disappear in a future Android release, and we
66  need this timeout wake lock until then.</p>
67<h2 id="how_to_define_wake-up_and_non-wake-up_sensors">How to define wake-up and non-wake-up sensors?</h2>
68<p>Up to KitKat, whether a sensor was a wake-up or a non-wake-up sensor was
69  dictated by the sensor type: most were non-wake-up sensors, with the exception
70  of the <a href="sensor-types.html#proximity">proximity</a> sensor and the <a href="sensor-types.html#significant_motion">significant motion detector</a>.</p>
71<p>Starting in L, whether a given sensor is a wake-up sensor or not is specified
72  by a flag in the sensor definition. Most sensors can be defined by pairs of
73  wake-up and non-wake-up variants of the same sensor, in which case they must
74  behave as two independent sensors, not interacting with one another. See
75  <a href="interaction.html">Interaction</a> for more details.</p>
76<p>Unless specified otherwise in the sensor type definition, it is recommended to
77  implement one wake-up sensor and one non-wake-up sensor for each sensor type
78  listed in <a href="sensor-types.html">Sensor types</a>. In each sensor type
79  definition, see what sensor (wake-up or non-wake-up) will be returned by
80  <code>SensorManager.getDefaultSensor(sensorType)</code>. It is the sensor
81  that most applications will use.</p>
82