Turning a battery complaint into evidence

Battery complaints are among the hardest mobile bug reports to act on. They have no timestamps, no steps, and no way to separate your app from the other apps that were active at the same time. The user is also certain, because your icon appears on the Settings screen.

Here is how to find out whether they are right.

Why the Settings screen is not proof

Settings → Battery shows per-app percentages over 24 hours or 10 days. The complaint usually comes from this screen, so read it, but understand what it does and does not show.

It attributes energy to the app that was in the foreground when the work happened. An app open for two hours shows a large share whether or not it did anything expensive. The display dominates the figure, and the display was on because the app was open. Meanwhile, an app that woke for four seconds every fifteen minutes all night barely appears.

So the screen answers “which app was on screen the longest”. That correlates with battery use, but it is a different question.

Two different investigations

“What does this cost while it runs?” Live: capture a fixed session and read energy alongside CPU, GPU, network and location.

“What drained the battery overnight?” Historical: no one was watching, so there is no capture. Read what the device recorded on its own: per-app run times, the hardware each app kept active, and the energy attributed to it. This is what answers an overnight complaint.

Using the first method to answer the second question is the most common mistake here, and it leads to hours of inconclusive captures.

What costs energy, roughly in order

Behavior	Why
Continuous precise location	One of the most expensive things a phone can do. Navigation-level accuracy while stationary is pure waste
Keeping the display on	The screen is usually the largest consumer. Disabling the idle timer costs more than any computation
Frequent network requests	The radio costs most when it wakes. Ten batched requests cost less than a hundred separate ones for the same amount of data
Background refresh	Cheap once, expensive when repeated every fifteen minutes indefinitely
Repeating timers	Prevent the CPU from reaching low-power states
Video and animation	Continuous GPU work plus a bright display
Bluetooth scanning	Cheap per scan, but often never stopped

Much of this is about waking hardware rather than doing work. Power management on a phone relies on long idle periods, and the expensive pattern is preventing them.

A method that produces an answer

1. Read the history first. Before capturing anything, check what ran during the reported period, sorted by energy. Many investigations end here, and the answer is a different app.
2. If it is your app, find out when. Foreground sessions, background wakes, or both? That determines which code to review.
3. Reproduce it live. Charge to a known level, unplug, and run the suspected interaction for five minutes with a capture running.
4. Change one thing. Disable the suspected cause and repeat exactly the same interaction.
5. Compare the two captures. Look at the difference, not at either number alone.

Common findings

• A location manager that is never stopped. It starts on one screen, is not stopped when the screen closes, and keeps running for the life of the process.
• A timer that outlives its view. The same pattern, cheaper per tick and harder to notice.
• Retry logic without backoff. A failing request retried every second all night. The data is trivial; the radio wake-ups are not.
• Analytics sent per event. Batch them.
• A “lightweight” background refresh that syncs everything.

Writing it up

“We checked and it is fine” does not answer a battery complaint. Attach:

• The history window showing what ran and what it cost
• Two captures, before and after the change
• What you changed and why

This turns a disagreement into a record. That matters because this type of complaint tends to return, and next time the earlier investigation should still be easy to read.

When it is not your app

Sometimes the cause is a location-heavy app the user forgot about, or a battery at 74% capacity with 900 cycles. Say so, and show the data. That is a better outcome than a week spent optimizing something that was never the problem.