Understanding the Android Kernel Suspend Process and Power Management

With the widespread adoption of smartphones, battery life has become a major concern. When a device is idle, it enters the most power‑saving mode, making the suspend process a key component of Android power management.

1. User‑space initiates the suspend flow

The kernel exposes the file node /sys/power/state for user‑space to request a power state (s2idle, s2ram, etc.). This article focuses on the s2ram path. The process [email protected] opens this node and triggers the autosuspend workflow.

Autosuspend workflow

Sleep 1 ms (initial value).

Read /sys/power/wakeup_count . If the read fails, restart from step 1.

Write the read value back to /sys/power/wakeup_count . If successful, write “mem” to /sys/power/state ; otherwise increase the sleep interval (max 2 min) and retry.

The wakeup_count is crucial: failure to read or write it aborts the suspend sequence.

2. Origin and role of wakeup_count

wakeup_count is an atomic variable whose high 16 bits store the number of registered wakeup events and low 16 bits store the number of active wakeup events. When a wakeup source is activated, the count increments; when deactivated, it decrements by (1<<16)-1 . This atomic design guarantees consistency even in extreme scenarios.

During autosuspend, if an active wakeup event is detected while reading wakeup_count , the process blocks until all active events finish or the thread is interrupted. A mismatch between the read and written values also aborts the suspend.

3. Role of pm_wakeup_pending

After the wakeup_count checks, pm_wakeup_pending inserts instrumentation into the suspend path to detect which wakeup events caused a premature exit. This helps developers pinpoint problematic sources.

4. Kernel suspend flow tracing

Once preliminary checks pass, the kernel proceeds with the actual suspend sequence, starting with a sync of the filesystem ( SYSCALL_DEFINE0(sync) ) to flush dirty data to storage.

Next, the system prepares and freezes user‑space and kernel threads ( suspend_prepare ), disables new user‑mode helpers, and freezes tasks via try_to_freeze (moving them to the “refrigerator”).

A suspend_test stage can be used for debugging, inserting timed pauses at defined checkpoints (TEST_FREEZER → TEST_DEVICES → TEST_PLATFORM → TEST_CPUS → TEST_CORE).

5. Device suspension

The suspend_devices_and_enter phase iterates over the device list, invoking each device’s suspend callbacks (prepare, suspend, suspend_late, suspend_noirq). The flow of device nodes through the various DPM lists (prepared, suspended, late‑early, noirq, etc.) is illustrated in the following diagram:

After devices are suspended, the system writes “mem” to /sys/power/state and enters the low‑power state.

6. suspend_enter

Before the final transition, platform‑specific preparations are performed via suspend_ops->prepare . Then device suspend_late callbacks run, CPUs are prevented from entering idle, and wakeup sources are marked with IRQD_WAKEUP_STATE and IRQD_WAKEUP_ARMED before disabling interrupts.

Non‑boot CPUs are taken offline ( disable_nonboot_cpus ), and boot CPU interrupts are disabled ( arch_suspend_disable_irqs ).

Finally, syscore_suspend saves essential system state (clocks, timers, statistics) so that syscore_resume can restore it after wake‑up.

The last step hands control to the platform‑specific suspend_ops implementation, which typically stops the main clock and switches to a low‑frequency clock, allowing the CPU to halt.

Reference: kernel‑4.14 Documentation on power management and various online tutorials.