Turning a battery complaint into evidence

Battery complaints are the least actionable bug reports in mobile. No timestamps, no steps, no way to separate your app from the six others that were awake at the same time — and a user who is certain, because the Settings screen has your icon on it.

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. It is the screen the complaint comes from, so read it — but understand what it does and does not say.

It attributes energy to the app in the foreground when the work happened. An app that was open for two hours will show a large share whether or not it was doing anything expensive; the screen is dominated by the display, and the display was on because the app was open. Meanwhile an app that woke for four seconds every fifteen minutes all night barely registers.

So the screen answers “which app was on screen the longest”, which correlates with battery use but is not the same 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 it overnight?” Historical: nobody was watching, so there is no capture. Read what the device recorded on its own — per-app run times, which hardware each one kept awake, and the energy attributed to it. This is the one that actually answers an overnight complaint.

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

What costs energy, in rough order

Behaviour	Why
Continuous precise location	Among the most expensive things a phone can do. Best-for-navigation while stationary is pure waste
Keeping the display awake	The screen is usually the single largest consumer. Disabling the idle timer costs more than any computation
Chatty networking	Radios cost most on wake. Ten batched requests beat a hundred trickled ones at the same byte count
Background refresh	Cheap once, expensive every fifteen minutes forever
Repeating timers	Prevent the CPU from reaching low-power states at all
Video and animation	Continuous GPU plus a bright display
Bluetooth scanning	Cheap per scan, and almost never actually stopped

Notice how much of this is about waking things rather than about doing work. A phone’s power management is built around long idle periods; the expensive pattern is preventing them.

A method that produces an answer

1. Read the history first. Before capturing anything, look at what actually ran during the complained-about window, sorted by energy. Half of these 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 decides which code to read.
3. Reproduce it live. Charge to a known level, unplug, run the suspected interaction for five minutes with a capture running.
4. Change one thing. Turn off the suspected cause and repeat exactly the same interaction.
5. Compare the two captures. Not the numbers in isolation — the difference.

Common findings

• A location manager nobody stops. Started on a screen, never stopped when it is dismissed, keeps running for the life of the process.
• A timer that outlives its view. Same pattern, cheaper per tick, harder to notice.
• Retry logic with no backoff. A failing request retried every second all night. The bytes are trivial; the radio wakes are not.
• Analytics flushed per event. Batch it.
• A “lightweight” background refresh that syncs everything.

Writing it up

A battery complaint answered with “we looked and it is fine” is not answered. Attach:

• The history window showing what ran and what it cost
• Two captures either side of the change
• What you changed and why

That turns an argument into a record, which matters because this class of complaint tends to come back, and next time you want the previous investigation to still be readable.

And when it is not you

Sometimes the answer is that the user has a location-hungry app they forgot about, or a device with a battery at 74% capacity and 900 cycles. Say so, with the data. That is a better outcome than a week spent optimising something that was never the problem.