How Android Handles Power Button Presses: From Kernel to Screen Wake‑Up

Overall Framework

Power‑button handling in Android consists of four layers: hardware, driver, Java framework, and native service. A strategy class in the framework decides whether a key event turns the screen on or off.

Device driver layer converts raw hardware input into a unified event and forwards it to the core layer.

Core layer provides registration and operation interfaces for the driver and notifies the event‑handling layer.

Event‑handling layer exposes device nodes for user‑space access.

User space receives the event, performs further distribution and business logic.

Power‑Key Transmission Process

1. Kernel‑Space Transmission

During driver initialization the power‑key driver registers an interrupt with request_irq. When the key is pressed or released the interrupt handler calls input_report_key and input_sync to report the event. The event propagates through the core and event layers to user space, where it can be read from /dev/input via EventHub::getEvents.

2. User‑Space Transmission

In the InputReader thread, EventHub::getEvents fetches the key event and passes it to processEventsLocked, which eventually calls KeyboardInputMapper::processKey. processKey invokes the listener’s notifyKey on the InputDispatch object created by InputManager. The event then reaches InputDispatch::notifyKey, which first calls interceptKeyBeforeQueueing to let the strategy class handle the event before it is queued.

The interception removes the ACTION_PASS_TO_USER flag and calls interceptPowerKeyDown or interceptPowerKeyUp for press and release respectively. After interception, enqueueInboundEventLocked queues the event. Later the InputDispatch looper extracts it and calls dispatchKeyLocked. If interceptKeyResult equals INTERCEPT_KEY_RESULT_SKIP, the power key is dropped and not delivered to applications.

Screen On/Off Processing

1. Screen‑On Flow

When the power key is pressed while the device is non‑interactive, interceptPowerKeyDown calls wakeUpFromPowerKey, which forwards to PowerManagerService::wakeUp. After permission checks, wakeUpInternal invokes wakeUpNoUpdateLocked, which:

Sets wakefulness to WAKEFULNESS_AWAKE and broadcasts a wake‑up intent.

Notifies BatteryStatsService and AppService of the state change.

Updates user activity time and resets the screen‑off timeout.

Finally updatePowerStateLocked triggers DisplayPowerController::setScreenState(Display.STATE_ON), schedules a runnable that updates the backlight via PhotonicModulator, and reaches the HAL to turn on the hardware backlight.

2. Screen‑Off Flow

When the power key is released, interceptPowerKeyUp evaluates long‑press and multi‑click patterns; a short press proceeds to powerPress, which calls goToSleepFromPowerButton. This invokes PowerManagerService::goToSleep. After permission checks, goToSleepInternal calls goToSleepNoUpdateLocked, which broadcasts a sleep intent and sets wakefulness to WAKEFULNESS_DOZING.

Both wake‑up and sleep paths eventually call updatePowerStateLocked, which follows the same backlight‑change sequence as the screen‑on flow, ultimately reaching the HAL to turn off the display.

In summary, the power‑button event is first intercepted by a strategy class to decide the action, then either the wake‑up or sleep sequence is executed, both converging on updatePowerStateLocked to modify the display backlight.