Background resource use must be visible, or it looks like a leak

What it is

A backup is transferring, a video transcoding, a model downloading — battery and data drop in a way you can feel. If people cannot see which job is using them, the drop is attributed to “this app is broken” or “the system is leaking”. Resource use transparent to the user means: the power, radio, heat currently being spent can be matched to a concrete task, at a perceptible order of magnitude, not only an anonymous battery ranking in system settings.

Transparent is not a milliwatt dashboard. It is an attribution channel: this task, roughly this much, this band of time until it stops.

Why it happens

A resource drop is a whole-body feeling: heat, a steeper battery curve, a carrier data warning. The feeling has no label. Background work deliberately does not own the screen, so labels are even scarcer. Attribution then lands on whatever was used last, or whichever process the OS names. The process name is usually the product, not “backing up those 2 GB”. People kill the process, disable background refresh, leave a bad review — those acts injure the misread durable task, not a real leak.

Transparency resticks the feeling onto the task object: beside the list item, “using cellular / about 400 MB still / battery high because of transcode”. Once stuck, policy becomes cancel or switch to Wi-Fi, not treating the whole product as broken. Order of magnitude matters more than precision: 400 MB versus 4 MB is a different decision; 387 versus 412 is not. A false report (task already stopped, still shown as draining) turns transparency into a new lie, so the sticker follows the task’s life and comes off when it stops.

Where it stops holding

A short foreground task the person is watching: resource use is in-expectation, no extra gauge, or it is noise. System-level battery stats lag; in-product transparency should follow the current task’s known volume and state, not reconcile watt-by-watt with the OS ranking. Under enterprise control the user may not pay for data; transparency still matters (heat, battery, a shared hotspot), but copy should not threaten “you will owe a lot of money”. For access, heat and drain are imperceptible to some people; transparency has to walk in words, not rely on the device getting hot as a “natural reminder”. Tiny heartbeats and analytics beacons should not enter this channel, or real tasks drown in noise; set a threshold that would change a decision (volume, estimated minutes, whether cellular).

Applying it

• On the task item, mark the resource kinds in use (cellular / Wi-Fi / CPU) and the order of magnitude (about this many MB, about this band of time).
• On cellular, when volume is enough to care, give a chance at submit or immediately after start to switch to Wi-Fi or cancel.
• When the task ends or pauses, the resource mark comes off. Do not keep showing “draining” while idle.
• How to check: start a several-hundred-MB backup on cellular, without opening system settings. In-product, this task should be visible as using cellular, volume in the right band. Cancel it; battery attribution should no longer point at it. Contrast: the same backup with no resource information in the UI, appearing only as the product name in the OS drain ranking — that is the shape that will misread a backup as a leak.

Related

• Same group: I3.12.1 Long tasks must survive quit and reboot · I3.12.2 Concurrent background work needs priority, not first-come-first-served · I3.12.3 Submitted background work must be reorderable or cancellable
• Nearby: I3.07 Background tasks · I2.04 Prefetch and preload
• Search terms: battery attribution · data usage · background resource