Background work shows up as battery blame
Aliases: battery attribution · background drain · wake lock
What it is
Whether an app "kills the battery" is judged less by in-app copy than by the per-app battery list in system Settings. Background location, silent refresh, wake locks, a playback session that never ended, all land under that name. Rank on that list drives uninstalls, toggling off background refresh, and hesitation at the next install. This entry is how background activity becomes attributable battery blame. It is not UI strategy on a flaky link, and not whether a large download should confirm first.
Why it happens
The OS bills energy to the process that holds a wake lock, registers background fetch, keeps location hot, or owns an audio session. A few minutes in the foreground and hours of light polling can look the same on the list—people see a percentage, not a reason for each wake. The app cannot rewrite someone else's attribution table or pin an explanation next to it. Once near the top, the usual moves are killing background capability or uninstalling. The former breaks widgets, mail sync, arrival reminders; people then score the breakage as product quality, not as the permission they just flipped. OEM battery policies also treat "active in the background" as a signal to punish. More activity invites more restriction, then complaints that nothing arrives.
Studying it
Align system battery stats with background-task logs; do not stop at "does this feel drainy."
Independent variables: background fetch interval, location accuracy and duration, wake lock held or not, audio playing in the background. Dependent variables: share and rank on the system battery list, uninstall or background-off actions, subjective drain ratings, complaints after a restriction breaks a feature.
Short lab sessions never produce an overnight rank. Carry two conditions for 24 hours: foreground use only, versus the same foreground use with background refresh on. Self-report will glue heat and fast drain to one app even when the table shows display or baseband; the system list is what splits those.
Where it stops holding
Navigation, calls, and recording that the person is relying on right now are the cost of the task; do not stop them to improve rank. When the OS bills an entire screen-on interval to the foreground app, readers look "expensive" when the display, not the logic, is the cost. A plugged-in laptop almost never uses this list as a verdict; the claim holds on battery-powered handhelds. Mis-attribution of system work (some OEMs spreading baseband drain onto the last-used app) cannot be fully erased by cutting background work, but dropping pointless wakes still moves rank.
Applying it
- Make background work off-able and explainable: each fetch should map to an outcome a person can name (new mail, arrival, a calendar alert). Kill anything that does not map.
- Do not poll the network at high frequency so a widget "looks live." Align refresh with how often people actually glance.
- Verify with two same-model devices on the same build, one allowing background refresh and one denying it. Compare overnight rank and percentage on the system battery list. If the allowed device ranks high with no matching user-visible result, delete that background work and measure rank again.