Idea
Break the drain down by screen state — how fast the battery drains while the screen is on vs off — and surface it in the expanded ongoing notification and the details table. AccuBattery does this well:
Now: −672 mA (14h 28m left)
Avg: −338 mA · −5.9%/h
Screen on: −392 mA · −10.4%/h
Screen off: −56 mA · −1.5%/h
The split is the genuinely useful part — it tells the user whether their drain is usage (screen on) or background/idle (screen off), which the single average hides.
Why it needs new work
Everything else the notification/table show already exists, but this doesn't: it needs drain attributed to screen state. We already read interactivity (SystemService.isActivelyUsed → PowerManager.isInteractive), so the building block is there — but BatteryRateTracker's sample window would need to tag each sample with the screen state at capture and then compute two separate averages (interactive vs non-interactive mA and %/h) over the window, rather than one blended figure.
Scope
- Tracker: tag rate-window samples with screen-on/off; expose
screenOnRate/screenOffRate (mA + %/h) alongside the existing blended average, each gated on having enough samples in that state (like the current warm-up gating).
- Notification: show the two lines in the expanded view (depends on the notification becoming expandable — see the ongoing-notification redesign).
- Details table: a small "Screen on / Screen off" breakdown (rows or a compact section), only when both states have enough data.
- Discharging only. Degrades gracefully when one state hasn't been observed yet.
Not now
Filed as a later enhancement (maintainer's call) — the ongoing-notification redesign and the current rate/table work land first; this builds on that infrastructure.
Related: #108 (rate), #109 (isActivelyUsed), #173 (avg current), and the ongoing-notification redesign (#192).
Idea
Break the drain down by screen state — how fast the battery drains while the screen is on vs off — and surface it in the expanded ongoing notification and the details table. AccuBattery does this well:
The split is the genuinely useful part — it tells the user whether their drain is usage (screen on) or background/idle (screen off), which the single average hides.
Why it needs new work
Everything else the notification/table show already exists, but this doesn't: it needs drain attributed to screen state. We already read interactivity (
SystemService.isActivelyUsed→PowerManager.isInteractive), so the building block is there — butBatteryRateTracker's sample window would need to tag each sample with the screen state at capture and then compute two separate averages (interactive vs non-interactive mA and %/h) over the window, rather than one blended figure.Scope
screenOnRate/screenOffRate(mA + %/h) alongside the existing blended average, each gated on having enough samples in that state (like the current warm-up gating).Not now
Filed as a later enhancement (maintainer's call) — the ongoing-notification redesign and the current rate/table work land first; this builds on that infrastructure.
Related: #108 (rate), #109 (isActivelyUsed), #173 (avg current), and the ongoing-notification redesign (#192).