Treat unexpected battery drain as an incident when it materially affects users, appears after a release, or risks a wider rollout. The goal is to protect users while collecting evidence that distinguishes an application regression from device health, operating-system activity, network conditions, or a different workload.
Start with a precise report
Record the app version and build, operating-system version, device model, approximate battery health when available, start and end charge, elapsed time, screen state, network type, location use, account state, and the steps the user was performing. Note whether the device was charging, unusually warm, recently updated, or running other intensive apps. Avoid requesting private device contents that are not needed for diagnosis.
Assign an incident owner, severity, first-observed time, affected release channels, and a protected evidence location. Link user reports to the incident without treating a single report as proof of cause. Separate observations from hypotheses such as “background sync is responsible.”
Capture platform evidence
For Android test devices, Google documents how to profile battery usage with Batterystats and Battery Historian. The workflow can reset earlier collection, run a controlled scenario, and generate a bug report. Resetting removes previous Batterystats data, so preserve any needed report first and use a dedicated test device.
Google’s Battery Historian analysis guide shows how the timeline can connect battery decline with CPU activity, wake locks, wakeup alarms, GPS, frequent jobs, synchronization, and radio use. Save the timeline or source report with the exact build and test scenario.
For iOS, Apple’s Xcode battery analysis guidance provides the supported path for examining an app’s power use. Keep iOS evidence separate from Android evidence because the tools, operating systems, and measurements differ.
Contain the suspected regression
If the issue is severe and correlated with a recent release, pause staged rollout or disable the suspected feature through an approved, reversible mechanism. Consider reverting to the last known-good build when the app’s data format and distribution channel make that safe. Document every containment action, who approved it, and the population affected.
Do not advise users to disable important security updates or permanently remove necessary accessibility, location, or notification features just to make the number look better. Offer temporary mitigations only when their effects and limitations are clear. If battery swelling, smoke, or extreme heat is reported, route the user to the device manufacturer’s safety guidance; software troubleshooting is not an appropriate substitute.
Reproduce and compare
Build a fixed scenario from the incident report and run it on the suspect build. Capture a clean diagnostic period, then repeat on the known-good build or with the suspected feature disabled. Keep brightness, connectivity, account state, and timing as consistent as practical. Compare timeline events, CPU activity, wake locks, alarms, GPS, network use, and time active rather than relying only on the displayed percentage.
A rollback that reduces battery use but causes crashes, data loss, sign-in failures, or broken background behavior is not an acceptable recovery. Verify those functions and confirm the installed build identifier. If the result cannot be reproduced, mark it inconclusive and continue monitoring rather than closing the issue as fixed.
Communicate and close responsibly
Tell affected users what is known, which versions are involved, the safe workaround if one exists, and when the next update will be provided. Do not state a root cause or percentage improvement until repeatable evidence supports it.
Close the incident record with the confirmed cause, affected scope, evidence references, containment and recovery actions, test results, and follow-up owners. Add a regression test or release metric that can detect similar power changes earlier. Retain only the diagnostic data required by policy and remove unnecessary personal information from attachments.