Battery consumption on Android very high, mostly background

NOOP version

9.3.0

Platform

Android

OS version

16

WHOOP strap model

WHOOP 5.0

Where the data is coming from

Live Bluetooth (strap connected)

Test Centre profile

Not a test-mode bug

What happens

I noticed my battery is easily drained the last few days. Looking at the data noop consumes it is quite a lot. Even compared to apps like Chrome, notorious for battery consumption.

My settings in the app

What you expected instead

Lower battery consumption.

Steps to reproduce

See battery details.

Strap log

Before you submit

I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, and this isn't an already-known limit (e.g. SpO₂, or recovery/sleep on the 5/MG).
I've left out anything personal (strap serial, account email, raw export).

Numbers first, because yours are good ones: 422 mAh over 20 h 26 m of background is ~20.6 mA average. Chrome's 19 mAh over 19 h 5 m is ~1.0 mA. So about 21×, and NOOP got there on 12 minutes of screen time against Chrome's 93.

Some of that gap is the job — Chrome in the background is doing nothing, NOOP is holding a live Bluetooth link to a sensor. But 20 mA is high in absolute terms, not just relative to a browser, so this is worth taking seriously rather than explaining away.

I went looking for the usual culprits and ruled them out:

"Overnight only" is genuinely working. The keep-alive fires every 30 s and re-derives the window, so the beat-to-beat stream really does disarm at 07:00 and re-arm at 22:00. It is not silently streaming all day.
No wake locks anywhere in the app.
Location is only added to the foreground service while a GPS workout is recording, not while idle.
The ongoing notification is already throttled to re-post only when its visible fields change, so the 1 Hz stream is not waking the phone per beat.

What is left is the part that actually explains it, and it is a design gap rather than a bug.

For 9 of those hours you asked for a beat-to-beat stream, and that cost is real and opted into. But the other ~11.4 hours the stream is deliberately disarmed and the Bluetooth link is still held at the BALANCED connection interval. There is a lever to drop an idle link to LOW_POWER — the long interval that is the real all-day saving — and it is off by default and gated on the strap's battery falling below a threshold, explicitly not the phone's. So there is currently no setting you can turn on that lowers the connection interval because your phone is draining. That is the wrong battery for this complaint, and those 11.4 idle hours are exactly the case the lever was written for.

Two things you can do today, in order of effect:

Turn Continuous HRV capture off and see what a day costs. It is the one setting here whose own description says it uses more battery. If the number drops a lot, the overnight stream is the bulk and we know where to aim. If it barely moves, the idle link is the bulk — which is what I expect, and that would be the more useful result to hear.
Leave everything else as-is while you test, so the comparison means something.

Either answer is worth having, and the second one is the one that points at a fix I can make rather than a setting you have to live with. Keeping this open as a battery issue rather than closing it as expected behaviour.

Anything on the connection interval has to be validated on a real strap — too long an interval can drop the link — so it is not something I can land off a code reading alone.

Followed the numbers further and the likely root cause is not the HRV stream — filed as #1007.

NOOP pulls the strap's history at ~10 records/s. The records are 1 Hz, so that is ~10× real-time, and moving a day of them costs about 2.4 hours of radio per day — roughly a 10% duty cycle, sustained. The official app moves the same 24 hours in 1–3 minutes. That is 48–144× more airtime for identical data, which is the right order of magnitude to explain the 21× you measured against Chrome.

It is not something I can tune away: the rate was tested on real hardware against ATT MTU (23 → 247) and connection interval (50 ms → 7.5 ms) and did not move on either. It is firmware-side pacing, so closing it needs a bulk transfer command that has not been reverse-engineered yet.

Two caveats on your case specifically. That measurement was taken on a WHOOP 4.0 and yours is a 5.0, whose offload is ack-gated and may pace differently — so the 10% figure is not yet confirmed for your strap. And this coexists with the overnight stream rather than replacing it as an explanation.

Which is why the A/B is still the useful thing, and now more so: turn Continuous HRV capture off for a day and post the same screen. If the number barely moves, the offload is the bulk and #1007 is where this lives. If it drops a lot, the stream matters more than the arithmetic above suggests, and that is worth knowing too.

Separately, #1008 covers making the HRV defaults match what WHOOP actually reports — including that enabling continuous capture currently gives a 24/7 stream unless "Overnight only" is also switched on, which you had already found for yourself.

Correction to my last comment: I quoted the WHOOP 4 offload rate at you, and you are on a 5.0.

The 5/MG measurement in the repo's own protocol notes is 35.5 records/s, not the ~10/s I cited. That makes a day of history about 41 minutes of radio, not 2.4 hours — roughly 2.8% duty cycle rather than 10%. Details and the corrected table are on #1007.

It is still 15–40x what the official app spends on the same data, so the offload is still the largest single thing NOOP does with your battery. But it is a smaller share of your 422 mAh than I implied, which means the overnight HRV stream is a bigger share than I implied.

That makes the A/B more useful, not less: turn Continuous HRV capture off for a day and post the same screen. With the offload now sized more honestly, that number should separate the two cleanly.

Nothing else changes — the settings advice stands, and #1008 still covers making the HRV defaults match what WHOOP actually reports.

Correct which battery the Power-saving levers key on (#477, #1005)

Record that the shipped copy was always correct (#1005)

Correct the power-saving docs: a slider that never existed, and the w…

I changed my settings yesterday at 13h28: no continuous HRV. It's not a full day yet AND my phone installed a new OS version last night meaning I missed about 8 hours of usage. Still I think insights are relevant to share given the fact that usage did not really lower.

Yesterday