WakeLock: What It Is, Types, and Sleep Lock Management

What is WakeLock

WakeLock is a system lock that prevents Android from putting the device into low-power mode. Normally, after a few seconds of user inactivity, Android turns off the screen and puts the CPU into deep sleep state, suspending background threads. WakeLock prevents this transition by keeping the CPU active.

The WakeLock mechanism is managed through the system service PowerManager, accessed via the getSystemService(Context.POWER_SERVICE) method. The developer creates a WakeLock object, specifying the lock type, and must guarantee its release after the task completes, otherwise the device battery will drain quickly. The system does not automatically release WakeLock — it is the application’s responsibility.

With every major Android release, Google tightens control over WakeLock. Starting from Android 9 (API 28), a background app cannot acquire WakeLock without a valid reason, and the system monitors apps that abuse locks and may forcibly release them. In Android 12+, additional restrictions on PowerManager access for background apps were introduced.

When WakeLock is Needed

WakeLock is required in scenarios where a task cannot be interrupted by the device going to sleep: downloading a large file over an unstable connection, recording video, performing long computations without user interaction. Without a sleep lock, the CPU enters deep sleep, all threads are frozen, and the task remains incomplete.

However, Google strongly recommends minimizing WakeLock usage. In most cases, the same task can be accomplished using Foreground Service with a notification, WorkManager, or JobScheduler. These mechanisms consider battery and network state, extending the device’s battery life.

How WakeLock Works

WakeLock works through the PowerManager system service, which manages the device’s power state. When an app requests a lock via powerManager.newWakeLock(), the system raises the CPU activity level, preventing deep sleep. After calling wakeLock.release(), the system returns to normal power-saving mode.

It is important to understand that WakeLock does not prevent all power-saving modes. Doze Mode (sleep mode from Android 6+) may ignore WakeLock in certain phases — an app holding a WakeLock will not get network access during Doze maintenance windows. This means that even an active WakeLock does not guarantee network operations during the second phase of Doze.

Each WakeLock is associated with a PowerManager.WakeLock on the framework side. The system counts active locks at the process level: if one process holds multiple WakeLocks, they accumulate, and release only occurs after calling release() for each lock. Android also supports wake lock timeouts — automatic release after a specified interval. However, relying on a timeout is not recommended: the task may complete earlier, and extra hold time will reduce battery life.

WakeLock and System Events

When the device goes to sleep (power button), Android forcibly releases all SCREEN_DIM_WAKE_LOCK and SCREEN_BRIGHT_WAKE_LOCK but retains PARTIAL_WAKE_LOCK. This means a screen lock cannot keep the display on — only PARTIAL_WAKE_LOCK can continue working after the power button is pressed.

Types of WakeLock in Android

Android has several types of WakeLock, each controlling specific device components. The choice of type determines which hardware components remain active after locking. Choosing the wrong type leads to excessive power consumption due to unnecessary modules being kept on.

PARTIAL_WAKE_LOCK — Main Type

PARTIAL_WAKE_LOCK is the most commonly used and recommended type. It keeps the CPU active but allows the screen and keyboard backlight to turn off. This is the optimal choice for background tasks: data loading, image processing, synchronization. The screen turns off after the system timeout, saving battery while performing work invisible to the user.

Deprecated Types

SCREEN_DIM_WAKE_LOCK, SCREEN_BRIGHT_WAKE_LOCK, and FULL_WAKE_LOCK have been deprecated since Android 7 (API 24). They keep the screen on, leading to significant battery drain. Google recommends using FLAG_KEEP_SCREEN_ON via Activity.getWindow().addFlags() instead — this flag only works when the Activity is active and does not require the WAKE_LOCK permission, while the system automatically manages screen hold time.

WakeLock and Power Consumption

WakeLock is one of the main battery drainers on Android. Every second a sleep lock is held consumes extra power because the CPU cannot transition to an energy-efficient C-state. Google Power Dashboard research shows that apps with improperly released WakeLocks can increase device power consumption by 30–50% in standby mode.

The system tracks apps that abuse WakeLock through the Battery Historian component. Developers can analyze the power consumption profile and identify lock leaks — situations where a WakeLock was created but not released. Google Play Console shows WakeLock statistics for published apps, and high hold time can lead to poor reviews.

Doze Mode and App Standby further restrict WakeLock operation. In the first Doze phase (Light Doze), the system allows WakeLock in short maintenance windows. In the second phase (Deep Doze), WakeLock is merged with other locks and executed in a common window. If an app holds a WakeLock for more than 10 minutes without user interaction, the system may forcibly release it and add the app to the battery optimization blacklist.

• Battery Historian — a tool for analyzing power consumption and WakeLock leaks
• Doze Mode — restricts WakeLock in maintenance windows, merging locks
• Google Play Console — displays WakeLock statistics for published apps
• Blacklist — an app can be marked by the system as power-hungry

Best Practices for Using WakeLock

Proper WakeLock usage is a balance between the need to complete a task and caring for the device’s battery. Google recommends following several principles: always release WakeLock in a finally block or via acquire(timeout), use the minimum necessary lock type, and avoid long holds unless absolutely necessary.

Release Rule

WakeLock should be released in the same code block where it was created. To guarantee release on exceptions, use a try-finally construct or Kotlin’s use block. On Android 10+, the system shows a warning in logcat if a WakeLock is held for more than 60 seconds: "WakeLock held for more than 60 seconds" — this signals a possible leak.

Acquire Timeout

The acquire(long timeout) method automatically releases WakeLock after the specified time in milliseconds. This is a safeguard in case the release code does not execute due to an exception or bug. It is recommended to always specify a timeout equal to the maximum expected task execution time plus 10–20% margin.

Checking Lock State

Before calling release(), you should check whether the WakeLock is currently held. Calling release() again without a prior acquire() throws a RuntimeException: WakeLock under-locked. It is recommended to store a state flag (isHeld) and check wakeLock.isHeld() before releasing.

Using WakeLock in Kotlin

Let’s look at proper creation and release of WakeLock in Kotlin. The example demonstrates asynchronous data loading with a PARTIAL_WAKE_LOCK held, guaranteed release in a try-finally block, and a timeout specified as a safeguard against leaks. The service uses CoroutineScope with the IO dispatcher for background task execution.

class DownloadService : Service() {

    private lateinit var wakeLock: PowerManager.WakeLock
    private val scope = CoroutineScope(Dispatchers.IO + SupervisorJob())

    override fun onCreate() {
        super.onCreate()
        val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
        wakeLock = powerManager.newWakeLock(
            PowerManager.PARTIAL_WAKE_LOCK,
            "download:wakelock"
        )
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        wakeLock.acquire(60000)
        scope.launch {
            try {
                downloadFile()
            } finally {
                if (wakeLock.isHeld()) {
                    wakeLock.release()
                }
            }
        }
        return START_NOT_STICKY
    }

    private suspend fun downloadFile() {
        // Simulating file download
        delay(30000)
    }

    override fun onDestroy() {
        super.onDestroy()
        scope.cancel()
        if (wakeLock.isHeld()) {
            wakeLock.release()
        }
    }

    override fun onBind(intent: Intent): IBinder? = null
}

Declaring Permission in the Manifest

To use WakeLock, you must add the permission to AndroidManifest.xml. The WAKE_LOCK permission is a normal permission — it does not require a runtime request from the user and is granted automatically when the app is installed. However, Google Play may reject publishing if the app has no obvious use case for WakeLock.

<uses-permission
    android:name="android.permission.WAKE_LOCK" />

<uses-permission
    android:name="android.permission.DEVICE_POWER" />

Alternatives to WakeLock

WakeLock is a low-level mechanism, and Google recommends replacing it with more modern APIs whenever possible. The main alternative is Foreground Service with a notification, which automatically holds the CPU lock for the duration of the service. The system manages WakeLock for Foreground Service itself, freeing the developer from explicit acquire and release.

WorkManager is the second most important tool for background tasks. It guarantees task execution even when the device enters Doze mode and after reboot. WorkManager supports a hold lock internally — the developer does not need to work with PowerManager explicitly. The task runs in the Doze maintenance window with automatic sleep lock management.

For recurring tasks that require precise timing, AlarmManager with setAndAllowWhileIdle() is used, which can wake the device from Doze. However, AlarmManager is only suitable for short operations — it is not designed for long WakeLock holds. If a task takes longer than 10 seconds, combine AlarmManager with a BroadcastReceiver that starts a Foreground Service.

• Foreground Service — automatic WakeLock management with a notification
• WorkManager — guaranteed execution with Doze and reboot awareness
• JobScheduler — scheduling with network, charging, and idle awareness
• AlarmManager — waking the device for short scheduled tasks