1 page.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 "timeout wake lock" 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
