A wake lock is a request by an app or system component to keep part of a device awake, usually the CPU or the screen, so that work can continue when the device would otherwise enter a low-power sleep state. In mobile performance, it is one of the most consequential power tools: used briefly and correctly it protects critical work such as finishing a download or playing music, but held too long it becomes a leading cause of battery drain with nothing visible on screen.
The term is most closely associated with Android, where wake locks are an explicit API in the power manager. Other platforms and the web provide related mechanisms with different scope, such as keeping the display on during a video call or a recipe view.
How a wake lock keeps a device awake
A mobile device sleeps aggressively. When the screen turns off and no work is scheduled, the kernel suspends the application processor within seconds, and only low-power components such as the modem and sensor hub stay active. A wake lock is a reference held in the kernel’s power management that blocks this suspend until it is released.
On Android, an app obtains a wake lock from the PowerManager service, names it with a descriptive tag, calls acquire() and later release(). The app must declare the WAKE_LOCK permission. Locks are reference-counted by default, so each acquire needs a matching release, and an acquire with a timeout releases itself automatically, which is the safest pattern.
| Level | What stays on | Current guidance |
|---|---|---|
| Partial wake lock | CPU only, screen and keyboard may turn off | Supported, use sparingly with a timeout |
| Screen dim wake lock | CPU and dimmed screen | Deprecated, use a keep-screen-on window flag |
| Screen bright wake lock | CPU and full brightness screen | Deprecated, use a keep-screen-on window flag |
| Full wake lock | CPU, screen and keyboard backlight | Deprecated |
| Proximity screen off lock | Turns the screen off near the face | Used during calls |
Wake lock compared with related power mechanisms
Wake locks are a low-level control, and most modern code should use higher-level tools that let the system schedule work efficiently. The operating system also overrides wake locks in certain states: during Doze mode, Android ignores partial wake locks held by apps, and background execution limits restrict what apps can do when they are not visible.
| Mechanism | Purpose | Use instead of a wake lock when |
|---|---|---|
| Keep-screen-on flag | Keeps the display on while a window is visible | The user is watching content |
| WorkManager or job scheduler | Deferrable background work with constraints | Work can wait for charging or network |
| Foreground service | Long user-visible tasks with a notification | Navigation, calls or media playback |
| Exact alarm | Wake at a precise time | A reminder must fire on schedule |
| Screen Wake Lock API | Keeps a web page display on | A web app shows a recipe or presentation |
On iOS, apps cannot hold an arbitrary CPU wake lock. They can disable the idle timer to keep the screen on while in the foreground and must use background modes and task APIs with system-defined limits for background work. This design makes the Android pattern of holding a CPU lock directly unavailable to iOS developers.
Measuring wake lock impact
Because a wake lock has no visible effect, problems are found through measurement rather than observation. Android records lock usage per app, and Android vitals in the Play Console reports excessive partial wake locks as a technical quality metric that can affect visibility in the store.
| Tool | What it shows | Typical use |
|---|---|---|
| Android vitals | Share of sessions with excessive partial wake locks | Production monitoring across users |
| Battery historian and bug reports | Timeline of locks, alarms and radio use | Detailed diagnosis on one device |
| dumpsys power | Currently held locks and their tags | Quick checks during development |
| Profilers in the IDE | Energy use and wake events per app | Testing changes before release |
Clear tags matter here. A tag in the form app:component makes it obvious which part of the code holds the lock, while generic names make bug reports almost useless.
Best practices for safe use
The guiding rule is to hold a wake lock as briefly as possible and only for work the user expects to finish. Many apps that hold wake locks do not need them at all, because the platform already keeps the device awake during broadcasts, jobs or foreground services.
- Always acquire with a timeout that matches the longest realistic task, for example a few minutes.
- Release in a finally block so that exceptions and early returns cannot leak the lock.
- Prefer WorkManager for sync and uploads, which batches work with other apps and respects Doze.
- Never hold a partial lock while waiting for network responses without a deadline.
- Use the keep-screen-on flag instead of screen-level locks so the system cleans up automatically.
Typical failure modes
The classic bug is a leaked wake lock: code acquires a lock, then an error path skips the release, and the processor stays awake for hours. Users notice only a phone that is warm in the pocket and an empty battery by midday, and the battery screen blames the app.
Other problems include repeated short locks triggered by frequent alarms, which prevent deep sleep just as effectively as one long lock, and third-party SDKs for analytics or advertising that acquire locks the app team never reviewed. Auditing dependencies and reviewing tags in bug reports is therefore part of routine performance work.
The short version
Phones save battery by falling asleep whenever nobody is using them. A wake lock is an app asking the phone to stay awake a little longer because its work is not finished yet.
That is useful when music must keep playing or a file must finish downloading. The danger is an app that forgets to let the phone sleep again. Then the phone keeps working in the dark, and the battery runs down for no visible reason.
Where it makes a difference
A team maintaining a podcast app sees complaints that phones lose a large share of their battery overnight even when nothing is playing. Android vitals shows that a significant fraction of sessions report excessive partial wake locks, and bug reports reveal a lock tagged for episode downloads that stays held for hours.
The cause is a download routine that acquires a lock without a timeout and skips the release when the network fails. The team replaces the custom logic with WorkManager jobs that require an unmetered network and charging for large downloads, and keeps a short, timed lock only during active playback handoff. In the next release, the wake lock metric returns to normal, and overnight battery complaints largely disappear from reviews.