Battery Technical Quality Enforcement is Here: How to Opt…

News and insights on the Android platform, developer tools, and events.

In recognition that excessive battery drain is top of mind for Android users, Google has been taking significant steps to help developers build more power-efficient apps. On March 1st, 2026, Google Play Store began rolling out the wake lock technical quality treatments to improve battery drain. This treatment will roll out gradually to impacted apps over the following weeks. Apps that consistently exceed the "Excessive Partial Wake Lock" threshold in Android vitals may see tangible impacts on their store presence, including warnings on their store listing and exclusion from discovery surfaces such as recommendations.

Users may see a warning on your store listing if your app exceeds the bad behavior threshold. This initiative elevated battery efficiency to a core vital metric alongside stability metrics like crashes and ANRs. The "bad behavior threshold" is defined as holding a non-exempted partial wake lock for at least two hours on average while the screen is off in more than 5% of user sessions in the past 28 days.

A wake lock is exempted if it is a system held wake lock that offers clear user benefits that cannot be further optimized, such as audio playback, location access, or user-initiated data transfer. You can view the full definition of excessive wake locks in our Android vitals documentation. As part of our ongoing initiative to improve battery life across the Android ecosystem, we have analyzed thousands of apps and how they use partial wake locks.

While wake locks are sometimes necessary, we often see apps holding them inefficiently or unnecessarily, when more efficient solutions exist. This blog will go over the most common scenarios where excessive wake locks occur and our recommendations for optimizing wake locks.  We have already seen measurable success from partners like WHOOP, who leveraged these recommendations to optimize their background behavior.

We’ve often seen developers struggle to understand the difference between two concepts when doing background execution: foreground service and partial wake locks. A foreground service is a lifecycle API that signals to the system that an app is performing user-perceptible work and should not be killed to reclaim memory, but it does not automatically prevent the CPU from sleeping when the screen turns off.

In contrast, a partial wake lock is a mechanism specifically designed to keep the CPU running even while the screen is off.  While a foreground service is often necessary to continue a user action, a manual acquisition of a partial wake lock is only necessary in conjunction with a foreground service for the duration of the CPU activity. In addition, you don't need to use a wake lock if you're already utilizing an API that keeps the device awake.  Refer to the flow chart in Choose the right API to keep the device awake to ensure you have a strong understanding of what tool to use to avoid acquiring a wake lock in scenarios where it’s not necessary.

It is common for an app to discover that it is flagged for excessive wake locks held by a third-party SDK or system API acting on its behalf. To identify and resolve these wake locks, we recommend the following steps: Check Android vitals: Find the exact name of the offending wake lock in the excessive partial wake locks dashboard. Cross-reference this name with the Identify wake locks created by other APIs guidance to see if it was created by a known system API or Jetpack library.

If it is, you may need to optimize your usage of the API and can refer to the recommended guidance. Capture a System Trace: If the wake lock cannot be easily identified, reproduce the wake lock issue locally using a system trace and inspect it with the Perfetto UI. You can learn more about how to do this in the Debugging other types of excessive wake locks section of this blog post. Evaluate Alternatives: If an inefficient third-party library is responsible and cannot be configured to respect battery life, consider communicating the issue with the SDK's owners, finding an alternative SDK or building the functionality in-house.

Below is a breakdown of some of the specific use cases we have reviewed, along with the recommended path to optimize your wake lock implementation. Video streaming apps where the user triggers a download of a large file for offline access. Media backup apps where the user triggers uploading their recent photos via a notification prompt. Do not acquire a manual wake lock. Instead, use the User-Initiated Data Transfer (UIDT) API.

This is the designated path for long running data transfer tasks initiated by the user, and it is exempted from excessive wake lock calculations. Do not acquire a manual wake lock. Use WorkManager configured for one-time or periodic work.  WorkManager respects system health by batching tasks and has a minimum periodic interval (15 minutes), which is generally sufficient for background updates.  In addition to logging worker stop reasons, refer to our documentation on debugging your workers.

Also, consider collecting and analyzing system traces to understand when wake locks are acquired and released. Companion device app listens for hardware events on an external device and user visible change in notification. Companion device app’s user initiates a file transfer between the mobile and bluetooth device. Companion device app performs occasional firmware updates to an external device via Bluetooth.

Use companion device pairing to pair Bluetooth devices to avoid acquiring a manual wake lock during Bluetooth pairing.  Consult the Communicate in the background guidance to understand how to do background Bluetooth communication.  Using WorkManager is often sufficient if there is no user impact to a delayed communication. If a manual wake lock is deemed necessary, only hold the wake lock for the duration of Bluetooth activity or processing of the activity data.

Food delivery apps that pull location data at a high frequency to update progress of delivery in a notification or widget UI. Consult our guidance to Optimize location usage. Consider implementing timeouts, leveraging location request batching, or utilizing passive location updates to ensure battery efficiency. When requesting location updates using the FusedLocationProvider or LocationManager APIs, the system automatically triggers a device wake-up during the location event callback.

This brief, system-managed wake lock is exempted from excessive partial wake lock calculations. Safety apps that monitor the device sensors for rapid changes in real time, to provide features such as crash detection or fall detection. If using SensorManager, reduce usage to periodic intervals and only when the user has explicitly granted access through a UI interaction. High frequency sensor monitoring can drain the battery heavily due to the number of CPU wake-ups and processing that occurs.

If you’re tracking step counts or distance traveled, rather than using SensorManager, leverage Recording API or consider utilizing Health Connect to access historical and aggregated device step counts to capture data in a battery-efficient manner. If you’re registering a sensor with SensorManager, specify a maxReportLatencyUs of 30 seconds or more to leverage sensor batching to minimize the frequency of CPU interrupts.

When the device is subsequently woken by another trigger such as a user interaction, location retrieval, or a scheduled job, the system will immediately dispatch the cached sensor data. If your app requires both location and sensor data, synchronize their event retrieval and processing. By piggybacking sensor readings onto the brief wake lock the system holds for location updates, you avoid needing a wake lock to keep the CPU awake.

Use a worker or a short-duration wake lock to handle the upload and processing of this combined data. Video or sound monitoring companion apps that need to monitor events that occur on an external device connected using a local network. Messaging apps that maintain a network socket connection with the desktop variant. If the network events can be processed on the server side, use FCM to receive information on the client.

You may choose to schedule an expedited worker if additional processing of FCM data is required.  If events must be processed on the client side via a socket connection, a wake lock is not needed to listen for event interrupts. When data packets arrive at the Wi-Fi or Cellular radio, the radio hardware triggers a hardware interrupt in the form of a kernel wake lock. You may then choose to schedule a worker or acquire a wake lock to process the data.

Summary

This report covers the latest developments in android. The information presented highlights key changes and updates that are relevant to those following this topic.

---