Background apps and battery usage

Yes, this is based on yesterday’s XKCD, but it’s about the fact, not the comic itself. A character in the strip says that closing background apps when not in use drains the battery faster, not slower. Now, I trust that Randall Munroe knows what he’s talking about, but he could be playing a joke on us.

So, is it true? And if so, what’s the mechanism?

If you close a dormant app, the next time you come to open it there will be some extra processing involved to re-establish the apps state. Probably not significant but true nonetheless.

I wondered about that, too. So I headed over to forums.xkcd.com to check the thread for that comic, and apparently the concept is that the app is using no processor time while sleeping, but would require more processor time to relaunch fully when needed again than to wake it up from sleeping.

This is for Android.

First, there is a myth that apps that aren’t full screen don’t ever waste the battery.

There are many ways for an app to run despite not being full screen. All sorts of “events” on the device will wake up the app and have it run for a bit. E.g., that solitaire game that must have permission to your call logs and such might wake up when you make a phone call. (Presumably phoning home all the call details.)

Some rogue apps (and by “rogue apps” I mean a very large fraction of them) can be woken up by the most trivial of events (e.g., by using the scheduler) so are nearly running all the time.

So the solution is obvious, right? Go the the current app “running” screen (typically by hitting the 3-lines button) and kill them all. Good right?

Well that helps for some apps but not for others. The problem now is that an app that is hooked into an event instead of being woken up has to be completely restarted. And that takes more battery juice.

OTOH, not all apps are this horrible. They no longer will be restarted at all by an event. And in those cases closing them is good for battery life.

How to tell? Well, you use a battery monitoring app.

Which, by the way, also increases the drain on the battery. So you should use it for testing only and then chuck it once you have the info.

So Randall is partially correct.

I can get by with my phone for almost 2 days if I keep it on battery saver and enable developer mode on android (settings>about phone>build number>tap 7 times) and set the background process limits lower, and mess with the hardware/2d settings. YMMV, but it is very helpful, just thought I’d throw the idea out there.

I found that disabling Google Play Services extends my battery life enough to get me through the day but I don’t use my phone that much. With the app turned on I get a low battery warning after about 8 hours.

I can get by with my phone for a couple of days without doing anything special at all, other than just not using it much.

I’m guessing that the people who close background apps generally think that by doing so, they’re removing the event hooks that would wake the app up. Given that that doesn’t work, is there any way to do so that actually does work? Well, I’m sure there is, but any way that’s as easy as closing the apps?

This is sort of tangential to OP, because its not really about my concern for battery life and Ive been debating a new OP, but what the hell. With my iPhone I periodically do a double click to see all my active apps (some I don’t even remember opening), and methodically swipe them away one by one till only the home screen. All well and good.

But on that homescreen a whole bunch of apps have their little red dot lit up, and they should be off, back in their cages, whatever. Reboot after reboot.

I also use an app called Battery, which in its current (heh) release needs a little trickery to crank up other functions such as freeing RAM, and after that stilll the little suckers are lit up. What gives?

ETA: Not sure if this is the last line of Chronos immediately above, but seems to be.

You are wasting your time.
Unless you have explicitly granted permission for an app to run in the background, all those “running” apps you see are just screenshots of their last state. They are only running when they are brought to the foreground.
The badge you see on their icon is independent of whether they are running or not. Once it is set, the app can be terminated and the badge will remain until it is cleared.

Background permission is given in: Settings->General->Background App Refresh.

Chronos, I know you were asking about the claim, not the comic, but I don’t think the two can be teased apart so easily.

The comic is commenting on the unsolicited tech advice geeks give to strangers and why they give that advice. (I concede that Munroe is often intentionally ambiguous).

The way I read it, Munroe chose that bit of advice because it can be technically true but often isn’t true, as well as being of almost no consequence to the people receiving the advice. I’ve been an XKCD fan for something like fifteen years, and he often pokes fun at people who like to say things that are only technically true. To wit:

Yes, restarting an app takes more energy than switching to it. That’s uncontroversial. But closing out long-open apps that you haven’t used for weeks or months is harmless. They’re probably not using any appreciable power, but closing them doesn’t increase power usage.

On the other hand, I have a SIP softphone app that maintains a near-constant connection to a server so it can ring when a call comes in. Force-quitting that app makes my battery last noticeably longer.

Finally, Apple is at least partly to blame for users’ impulse to force-quit apps. Early iphones sucked down a ton of battery any time an app was using the GPS chip. Since some backgrounded apps kept the GPS chip on, it made sense to force-quit anything that might be using GPS. This trained users to kill apps in order to save battery life.

Does retaining the app in memory use power? RAM (volatile memory) erases itself when power is lost so, I would guess, it needs some power usage to maintain its state.

Really asking.

The RAM doesn’t know what data is useful data associated with a suspended app, or stale data which was once associated with a forcibly stopped one. The whole of the RAM space is maintained and the power usage is unaffected.

My current (ok, 2 year old) Android phone still has this problem. If I leave a mapping program running in the background, it draws down my battery noticeably faster.

I’m not claiming expertise on this, I was going by one of the early posts here:

I was assuming that a fully suspended app was stored in the flash memory, not the RAM–sort of like a swap file or hibernation on a PC–it is faster to recover an “image” of the active program from storage than to fully reactivate the program. But if it is still in RAM it is of course still using power. But but if Android uses “spare” RAM for cache (like Windows does) that RAM is in use either way, so there wouldn’t be a difference in power drain…

(imagine the little shruggy man made with unicode emoji here)

No it doesn’t save an image to non-volatile storage, inactive apps just stay in RAM until memory runs low, at which point the OS will start kicking them out. Usually the OS will warn an app that it is liable to be stopped, giving it the opportunity to do so gracefully, but in dire emergencies it may just chop them off at the knees.

Some poorly written apps will continue to use resources they don’t need when they are not visible. For location aware apps, of which maps are an obvious example, continuously checking GPS location will definitely use up more battery. Sometimes an app will react differently depending on how you leave it. Try leaving your mapping app by pressing the ‘back’ button (you may need to press it more than once) rather than the ‘home’ button and see if that helps. If so maybe contact the developer and tell them as it can be fixed.

What, modern mobile OSes have no concept of paging? Some Googling suggests that you are right. I guess you learn something new every day. (I wonder if Android stripped all the paging code out of its Linux kernel, or if it’s still lurking there in a vestigial state.)