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