| <html devsite> |
| <head> |
| <title>Suspend mode</title> |
| <meta name="project_path" value="/_project.yaml" /> |
| <meta name="book_path" value="/_book.yaml" /> |
| </head> |
| <body> |
| <!-- |
| Copyright 2017 The Android Open Source Project |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| |
| |
| <h2 id="soc_power_states">SoC power states</h2> |
| <p>The power states of the system on a chip (SoC) are: on, idle, and suspend. “On” is when the |
| SoC is running. “Idle” is a medium power mode where the SoC is powered but |
| doesn't perform any tasks. “Suspend” is a low-power mode where the SoC is not |
| powered. The power consumption of the device in this mode is usually 100 times |
| less than in the “On” mode.</p> |
| <h2 id="non-wake-up_sensors">Non-wake-up sensors</h2> |
| <p>Non-wake-up sensors are sensors that do not prevent the SoC |
| from going into suspend mode and do not wake the SoC up to report data. In |
| particular, the drivers are not allowed to hold wake-locks. It is the |
| responsibility of applications to keep a partial wake lock should they wish to |
| receive events from non-wake-up sensors while the screen is off. While the SoC |
| is in suspend mode, the sensors must continue to function and generate events, |
| which are put in a hardware FIFO. (See <a |
| href="batching.html">Batching</a> for more details.) The events in the |
| FIFO are delivered to the applications when the SoC wakes up. If the FIFO is |
| too small to store all events, the older events are lost; the oldest data is dropped to accommodate |
| the latest data. In the extreme case where the FIFO is nonexistent, all events |
| generated while the SoC is in suspend mode are lost. One exception is the |
| 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> |
| <p>As soon as the SoC gets out of suspend mode, all events from the FIFO are |
| reported and operations resume as normal.</p> |
| <p>Applications using non-wake-up sensors should either hold a wake lock to ensure |
| the system doesn't go to suspend, unregister from the sensors when they do |
| not need them, or expect to lose events while the SoC is in suspend mode.</p> |
| <h2 id="wake-up_sensors">Wake-up sensors</h2> |
| <p>In opposition to non-wake-up sensors, wake-up sensors ensure that their data is |
| delivered independently of the state of the SoC. While the SoC is awake, the |
| wake-up sensors behave like non-wake-up-sensors. When the SoC is asleep, |
| wake-up sensors must wake up the SoC to deliver events. They must still let the |
| SoC go into suspend mode, but must also wake it up when an event needs to be |
| reported. That is, the sensor must wake the SoC up and deliver the events |
| before the maximum reporting latency has elapsed or the hardware FIFO gets full. |
| See <a href="batching.html">Batching</a> for more details.</p> |
| <p>To ensure the applications have the time to receive the event before the SoC |
| goes back to sleep, the driver must hold a "timeout wake lock" for 200 |
| milliseconds each time an event is being reported. <em>That is, the SoC should not |
| be allowed to go back to sleep in the 200 milliseconds following a wake-up |
| interrupt.</em> This requirement will disappear in a future Android release, and we |
| need this timeout wake lock until then.</p> |
| <h2 id="how_to_define_wake-up_and_non-wake-up_sensors">How to define wake-up and non-wake-up sensors?</h2> |
| <p>Up to KitKat, whether a sensor was a wake-up or a non-wake-up sensor was |
| dictated by the sensor type: most were non-wake-up sensors, with the exception |
| 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> |
| <p>Starting in L, whether a given sensor is a wake-up sensor or not is specified |
| by a flag in the sensor definition. Most sensors can be defined by pairs of |
| wake-up and non-wake-up variants of the same sensor, in which case they must |
| behave as two independent sensors, not interacting with one another. See |
| <a href="interaction.html">Interaction</a> for more details.</p> |
| <p>Unless specified otherwise in the sensor type definition, it is recommended to |
| implement one wake-up sensor and one non-wake-up sensor for each sensor type |
| listed in <a href="sensor-types.html">Sensor types</a>. In each sensor type |
| definition, see what sensor (wake-up or non-wake-up) will be returned by |
| <code>SensorManager.getDefaultSensor(sensorType)</code>. It is the sensor |
| that most applications will use.</p> |
| |
| </body> |
| </html> |
