Short answer: My Google Play listing promises the screen-off mode will "Save 10x battery life and keep your device cool while broadcasting." The only battery table I have ever published says the screen-off run is about five to six hours against a screen-on baseline of about one and a half to two hours. That is somewhere between two and a half and four times, not ten. Both numbers are mine. They disagree, neither is a controlled measurement, and until one exists the honest figure is that I do not know. This is the audit, the arithmetic, and the measurement design I should have run before writing either number.
I spend a lot of words on this blog telling people how to check other companies' claims. What a privacy policy admits when you read the data-safety section. What a retention default really means when nobody on the team chose it. Four days ago I published the electricity arithmetic for running an old handset as a camera for a year, and I was careful in that piece to show every step, so that a reader who disagreed with me could point at a line and say which one.
Then somebody asked where my battery number comes from.
I went and looked. What follows is not flattering, and I think publishing it is worth more than quietly editing a store listing at two in the morning.
The claim, verbatim
The Play listing (updated Aug 9, 2026) has a section headed "STREAM FOR HOURS, NOT MINUTES". Two sentences in it carry numbers:
- "Traditional streaming drains batteries in 30-60 minutes."
- ...and the screen-off technology "stream for 10+ hours on a single charge".
Further down, in the feature list, the number is stated directly:
"Save 10x battery life and keep your device cool while broadcasting."
I am auditing the first half of that sentence only. The temperature half is a separate claim with its own separate absence of evidence, and rolling the two together would let me off too easily.
The figure has also travelled. A syndication template I set up months ago carries the line "stream live with the screen off for ~10× the battery life", and there are fourteen copies of it in this blog's own archive — with the tenfold figure, in one wording or another, appearing in seventeen. Whatever the number is worth, it has had a great deal of exposure.
The only evidence I have ever published
There is exactly one battery table anywhere in my published work. It is in a piece from 30 April 2026, How to Stream to YouTube Live from Android with Your Screen Off. Here it is, unchanged:
"Tested on a Pixel 7 (4,355 mAh battery), 720p stream:"
| Mode | Estimated Stream Duration |
|---|---|
| YouTube app (screen on) | ~1.5 hours |
| Third-party streamer (screen on) | ~2 hours |
| Background Camera RemoteStream (screen off) | ~5-6 hours |
| Screen off + plugged into power bank | 12+ hours |
Read the section heading and the column header together, because I never did.
The heading says the figures were tested on a specific handset at a specific picture setting. The column header says "Estimated Stream Duration". A test produces measurements. An estimate is a guess with a straight face. One of those two words has not earned its place in that table, and I wrote both of them, in the same screenful, on the same afternoon.
The arithmetic
Take the table at face value and divide.
| Comparison | Multiple |
|---|---|
| 5 hours screen-off vs 1.5 hours (YouTube app) | 3.3x |
| 6 hours screen-off vs 1.5 hours (YouTube app) | 4.0x |
| 5 hours screen-off vs 2 hours (third-party) | 2.5x |
| 6 hours screen-off vs 2 hours (third-party) | 3.0x |
The best case my own published table supports is four times. The worst is two and a half. Ten does not appear.
There is one row that gets close: "Screen off + plugged into power bank" at 12+ hours, which against a 1.5-hour baseline is eight. But that row is on external power. It is not a statement about battery life at all — it is a statement about a battery I added to the setup. Using it to support a battery-life multiple would be a straightforward sleight of hand, and if a competitor did it in their listing I would write a post about them.
Where the ten probably came from
The listing is internally consistent with itself. Ten hours against sixty minutes is tenfold; against thirty minutes it is twenty. So the figure in the feature list is the conservative reading of the listing's own pair.
The trouble is that the pair is anchored to nothing. "Traditional streaming drains batteries in 30-60 minutes" names no handset, no screen brightness, no capture setting, no network, no year. The blog table at least names a Pixel 7 and 720p — and then disagrees with the listing by roughly a factor of two on the screen-off figure and by a factor of two to four on the baseline.
Two published sources. One feature. Neither cites a method. I cannot tell you which is nearer the truth, and that is the entire problem: it is not that one of my numbers is wrong, it is that I have no procedure that could tell me.
Why one number was never going to be right anyway
Set my documents aside and look at how Android accounts for display power in the first place. From the Android Open Source Project's power documentation:
"Device manufacturers must provide a component power profile that defines the current consumption value for the component and the approximate battery drain caused by the component over time."
And, specifically for the display:
"a display power profile specifies the mA of current required to keep the display on at minimum brightness and at maximum brightness"
with the platform then working out the cost because "the framework tracks the time spent at each brightness level, then multiplies those time intervals by an interpolated display brightness cost".
Read that as a constraint on marketing copy rather than as an implementation note. The cost of keeping a display lit is a per-device, per-brightness quantity that each manufacturer supplies for their own hardware. An OLED panel at minimum brightness in a dark hallway and an LCD at full brightness on a sunny balcony are not the same denominator, and they are not the same fraction of the total either.
And the multiple is a ratio, so the bottom of the fraction matters as much as the top. Whatever else the device is doing — encoding, pushing bytes over a radio, holding a network connection open — is load that removing the display does not remove. The heavier that load, the smaller the share the display represented, and the smaller the improvement from switching it off. The lighter the load, the bigger the multiple looks.
Which means the honest form of the claim is not a number at all. It is: the improvement is real, its size depends on your handset, your brightness, your capture settings and your network, and anyone quoting you a single figure across all phones is quoting you a figure from one phone. Including me. Especially me, because I am the one who put it on a store listing.
What an actual measurement looks like
Android documents the path, and it is not exotic. From the developer documentation on profiling battery usage:
"Batterystats is a tool included in the Android framework that collects battery data on your device."
The procedure, in outline:
adb shell dumpsys batterystats --reset
# disconnect the handset, run the scenario on battery alone
adb shell dumpsys batterystats > batterystats.txt
adb bugreport bugreport.zip
Two details from that page are worth repeating because they are exactly the sort of thing that makes an amateur run worthless. First: "The device is always collecting Batterystats and other debugging information in the background. Resetting erases previous battery collection data." In my words, not theirs: if you skip the reset you get an unreadable pile. Second, on the system statistics view: it reports things "such as cell signal levels and screen brightness", and the page notes that "This is especially useful to make sure no external events are affecting your test."
That second one is the whole ballgame for a claim like mine. Screen brightness is the single largest free variable in a screen-on-versus-screen-off comparison, and neither of my published sources names it.
One caveat on the tooling, because it changed and the docs say so plainly: "Battery Historian is no longer actively maintained". The same page points instead at system tracing, the Macrobenchmark power metric, and the Power Profiler. Any run I publish should say which of those produced the figures.
What I am going to publish, and what would make me change the listing
Here is the design, written down in advance so that it can be held against me.
Controls, all of them recorded: one handset, named, with its battery health and age stated. Identical capture settings on both legs — same picture size, same frame rate, same bitrate. Screen brightness fixed and reported as a number, not as a slider position. Same network, same distance from the access point, same ambient room temperature. Same starting charge. Airplane-mode-off, no other apps, notifications quiet. Wall-clock start and stop times.
Both legs measured, not one: the screen-on baseline is half the claim and it is the half I have never measured at all. "Traditional streaming" is not a testable object; a named third-party streamer at the same settings on the same handset is.
Three repeats per leg, because one run of anything is an anecdote.
Raw output attached, so the arithmetic can be checked the way I asked readers to check mine four days ago.
A second handset if I can get one, precisely because the AOSP documentation above says the answer is per-device. One phone gives one ratio. It does not give a multiplier.
And the part that actually costs something: if the measured multiple is not close to ten, the store listing changes, and this post gets updated with the number that replaced it. If it comes out higher than ten I will be delighted and I will still show the working. A claim that only survives while nobody checks it is not an asset.
The part I would rather not have written
The pitch for repurposing a handset as a camera is, at bottom, an argument about honesty: that you can see where the footage is stored, that nothing is being uploaded on your behalf, that the arrangement has no hidden meter running. That argument is worth very little from someone whose own headline figure has no method behind it.
So the correction is not really about a battery. It is that I published a number, syndicated it fourteen times, and could not answer a one-sentence question about where it came from. The rules I apply to other people's marketing copy apply to mine, and applying them cost me an evening and a claim I liked.
The honest number, today, is: I do not know. It is more than two and a half. It is probably not ten. I will tell you when I have measured it.
Background Camera RemoteStream is on Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
More on the project at superfunicular.com
Top comments (0)