1, Sleep overview

Sleep, in short, means that the device turns off some components and peripherals when it doesn't need to work (power down or put it into low-power mode).
Why sleep? In a word: save electricity.
Dormancy is divided into active dormancy and passive dormancy. Active hibernation: for example, if my computer is not used, let the system enter hibernation mode through setting; Passive sleep: the system detects its own idle panic. In order to save money, it goes to sleep.

2, Android sleep

Hibernation is the core work of the kernel, and Android is based on the Linux kernel, so Android hibernation is inextricably linked with the kernel; Due to the special application scenario of Android: mobile devices, Android hibernation and kernel have special requirements.
1. Contact:
Android devices stop using, the system has nothing to do, and the function of entering the sleep state is finally realized by the kernel; Each type of hardware has its own driver. The specific driver determines how to sleep and at what level. For example, for platform_device, just follow the platform_ The rules defined by driver do the above mentioned things when suspend is called:

struct platform_driver {
    int (*probe)(struct platform_device *);
    int (*remove)(struct platform_device *);
    void (*shutdown)(struct platform_device *);
    int (*suspend)(struct platform_device *, pm_message_t state);
    int (*resume)(struct platform_device *);
    struct device_driver driver;
    const struct platform_device_id *id_table;
};

2. Special requirements for Android:
For example, for your own computer, don't let it sleep; However, for our inseparable mobile phones, we have to keep an eye open when we sleep: we need to notify you when we call, and we need to notify you when QQ, wechat and other information. Therefore, Android puts forward "Opportunistic Suspend" based on the Linux kernel sleep mechanism.

3, Dormancy practice

With so much talk, let's actually experience sleep.
1. Sleep mode
Sleep is divided into several modes. Different modes have different implementation methods and power consumption. The following is from documentation / power / states txt:

The kernel supports four power management states generically, though
one is generic and the other three are dependent on platform support
code to implement the low-level details for each state.
This file describes each state, what they are
commonly called, what ACPI state they map to, and what string to write
to /sys/power/state to enter that state
 
state:        Freeze / Low-Power Idle
ACPI state:    S0
String:        "freeze"
 
This state is a generic, pure software, light-weight, low-power state.
It allows more energy to be saved relative to idle by freezing user
space and putting all I/O devices into low-power states (possibly
lower-power than available at run time), such that the processors can
spend more time in their idle states.
This state can be used for platforms without Standby/Suspend-to-RAM
support, or it can be used in addition to Suspend-to-RAM (memory sleep)
to provide reduced resume latency.
 
 
State:        Standby / Power-On Suspend
ACPI State:    S1
String:        "standby"
 
This state offers minimal, though real, power savings, while providing
a very low-latency transition back to a working system. No operating
state is lost (the CPU retains power), so the system easily starts up
again where it left off. 
 
We try to put devices in a low-power state equivalent to D1, which
also offers low power savings, but low resume latency. Not all devices
support D1, and those that don't are left on. 
 
 
State:        Suspend-to-RAM
ACPI State:    S3
String:        "mem"
 
This state offers significant power savings as everything in the
system is put into a low-power state, except for memory, which is
placed in self-refresh mode to retain its contents. 
 
System and device state is saved and kept in memory. All devices are
suspended and put into D3. In many cases, all peripheral buses lose
power when entering STR, so devices must be able to handle the
transition back to the On state. 
 
For at least ACPI, STR requires some minimal boot-strapping code to
resume the system from STR. This may be true on other platforms. 
 
 
State:        Suspend-to-disk
ACPI State:    S4
String:        "disk"
 
This state offers the greatest power savings, and can be used even in
the absence of low-level platform support for power management. This
state operates similarly to Suspend-to-RAM, but includes a final step
of writing memory contents to disk. On resume, this is read and memory
is restored to its pre-suspend state.

Although the kernel supports the above four sleep modes, which are available depends on your hardware. So how do you know the sleep mode supported by your Android device?

Answer: through / sys / file system. To query the supported sleep modes, you can use cat file / sys/power/state:

cat /sys/power/state 
freeze mem

If we echo the string of a certain mode in the / sys/power/state file, the system will enter the corresponding sleep mode:

echo "mem" > /sys/power/state

If you have searched for Android hibernation related content, the setPowerState() method of PowerManager is mentioned in the old version of Android (before version 4.4), which makes the system hibernate through the above methods. However, since the introduction of Autosleep, this has not been done, and the setPowerState() method has disappeared.

2. Files in / sys/power / directory

Document introduction:

• /sys/power/state: used to control the Power state of the system. Reading the file can obtain the sleep mode supported by the system. Writing the file is one of the sleep modes, and the system enters the specified sleep mode. Example above.
• /sys/power/autosleep: evolved from the Android wakelocks patch set to replace the automatic sleep function in Android wakelocks. Write the return value of / sys/power/state to the file, and the system will enter the specified sleep mode at an appropriate time; Reading the file returns the previously written value.
• /sys/power/wake_lock,/sys/power/wake_unlock: that is, we often call the sleep lock. If the application holds the sleep lock, the system will not be able to enter the sleep mode. In the era of Android wakelocks, write wake_lock get lock, write wake_unlock release lock; In the AutoSleep era, see AutoSleep in [Android sleep] for details
• wakeup_count: used to solve the "synchronization problem between system suspend and system wakeup events".
• /sys/power/pm_async: state switch, which allows / prohibits asynchronous suspend and resume operations on the device in User space.

• /sys/power/pm_freeze_timeout: the system freezes the processes of the user control and the kernel threads allowed to be frozen in the kernel space when performing the sleep action. Does it take time to perform these operations? This file specifies the maximum time required.

  4, Other issues to be clarified

  1. When the screen of Android device goes dark, it does not immediately enter sleep mode; When all wake-up sources are in de avtive state, the system will enter sleep.

2. When an Android device is connected to other devices with an adb cable, the device will not enter sleep mode.

3. If there is sleep operation, there is wake-up, and the wake-up source is required. There are many kinds of wake-up sources, which are registered in the kernel, such as the commonly used Power button.

4. Once a confused question: how does the system know that it should enter sleep mode? What is its judgment basis?

In the wake lock era, the system detects the sleep lock during sleep; If no other part in the system holds the sleep lock, try to enter the sleep mode. If no abnormal event occurs, enter the sleep mode.
Android has been using autosleep mechanism since 4.4. As long as there is no active wake up_source, it will enter sleep mode.

5. Overall process of system Power Manager