If you find your phone is often low on battery, the free apps you use may be to blame, according to a new study. Using a monitoring tool they developed, the authors of the study—two researchers from Purdue University and another from Microsoft—found that serving ads and collecting data inside an app results in excessive use of the hardware components inside a smartphone. These parts of free apps will turn on components like the 3G chip or GPS and cause them to stay on well after an information transaction has been completed, resulting in unnecessary power loss.

Most smartphones can show a basic breakdown of which resources are consuming the battery life (display, Wi-Fi, individual apps, etc.), but the way in which individual apps use that power is more opaque. To unpack the details at this level of power consumption, three researchers developed a tool called "eprof," a "fine-grained energy profiler." Eprof can track power used at the level of individual threads as well as routines running in an app, and can also track what the authors call "asynchronous power behavior."

Tracking an individual piece of software's activity—when processes stop and start, for instance—is contained, so it's easy to say how much power they use in that regard. But the authors found that tracking the hardware was more subtle, as many apps seem to stir hardware into action without turning it off right away, or ever. For example, the authors note the Wi-Fi and 3G chips may start up to communicate an app's data, and then remain in a high-power state even after the app has closed.

Likewise, smartphone OSes also include "wakelock APIs," which allow apps to prevent different pieces of hardware from sleeping, such as an app that wakes the CPU to check for new messages or a video application that stops the screen from sleeping while playing a movie. Items like the camera and GPS presented a similar problem: the researchers found that apps that use these devices start them up and put them in a high power-consuming state, and the hardware will sometimes continue this way until explicitly turned off by another service.

All of these actions mean power consumption triggered by one app can extend beyond when an app is finished using a piece of hardware and overlap into another, making good power accounting tricky (the authors note that this kind of battery consumption, known as "tail energy," is being studied to reduce its consumption). For the purposes of this study, the authors account for the energy use triggered by an app, even if it extends beyond the period of app use.

Using eprof to monitor app power use on an HTC Passion running Android 2.3, the researchers made a few discoveries. In a study of the free version of Angry Birds, the authors found that the third-party ad generator and data aggregator Flurry consumes 45 percent of the app's energy tracking the user's location and serving ads to the app. But of that 45 percent, uploading the information and downloading the ads over 3G was only a 2KB transaction, taking 1 percent of the app's energy.

After the data exchange, the researchers found that the 3G chip continued to eat up energy, and it consumed another 24 percent of the total. Meanwhile, the core CPU-intensive thread that actually runs the program consumed 18 percent. Once the app was closed, a thread called HeapWorker performed cleanup and closed a socket, pushing the 3G chip into action and creating another tail that used 28 percent of the total energy.

The app Free Chess showed similar energy use excesses. Fifty percent of the app's energy went to running the third-party ad creator AdWhirl, and of that 50 percent, around 5 percent was used to download and render the ads; the rest was tail energy used by the 3G chip.

In total, 80 percent of the energy Angry Birds used went to I/O components (3G and GPS), and 77 percent of Free Chess's did. Others, like the New York Times app (67 percent) and MapQuest (72 percent) used somewhat less on components that had been triggered into a high power state by a short task, but the difference these states make are significant.

One simple lesson here is that if you find yourself drinking your battery dry by 7pm every day, springing for the paid versions of apps that don't need to use extra energy to serve you ads could help. The difference could be significant, depending on how much time you spend on ad-supported apps or, to a lesser extent, ones that perform frequent exchanges with GPS and data collection services like Flurry.

More importantly, there is some optimization to be done on the part of app creators. We can fault smartphones for skimping on battery size, but all the milliamp-hours in the world can only do so much good when apps use two to three times as much energy to collect data and serve ads as to run the actual program, all because these services amp up hardware components to high power states and let them stick there for too long. The authors suggest that eprof could be combined with static analysis to optimize energy use, as well as with smartphone OS schedulers to make them more aware of when components are using energy, but not actually in use.

Latest Ars Video >

War Stories | Thief: The Dark Project

1998's Thief: The Dark Project was a pioneer for the stealth genre, utilizing light and shadow as essential gameplay mechanics. The very thing that Thief became so well-known for was also the game's biggest development hurdle. Looking Glass Studios founder Paul Neurath recounts the difficulties creating Thief: The Dark Project, and how its AI systems had to be completely rewritten years into development.

War Stories | Thief: The Dark Project

War Stories | Thief: The Dark Project

1998's Thief: The Dark Project was a pioneer for the stealth genre, utilizing light and shadow as essential gameplay mechanics. The very thing that Thief became so well-known for was also the game's biggest development hurdle. Looking Glass Studios founder Paul Neurath recounts the difficulties creating Thief: The Dark Project, and how its AI systems had to be completely rewritten years into development.

Casey Johnston
Casey Johnston is the former Culture Editor at Ars Technica, and now does the occasional freelance story. She graduated from Columbia University with a degree in Applied Physics. Twitter@caseyjohnston

Before anyone jumps on the Microsoft participation, note that this study started when Windows Mobile 6.5 was still (lol) relevant and in production and both WinMo and Android were looked at. When the product was killed, WinMo was dropped from the study and focused solely on Android.

DeChicago wrote:

Everywhere else I read this story, it noted that they were AndroidOS phones. And not a single mention of iOS was made in the article.

It's not that much of a stretch to assume the same is happening to iOS or Windows Phone ads too. On my phone personally, I've seen ads struggle to come on a weak network connection. That's gotta be doing something to battery life. Hardly scientific, I know.

They missed out the most resource and power hogging app available for Android - the Facebook app.

Seriously, it's a classic example on how not to use scarce resources. Just opening up the app on my Galaxy S to view the news feed powers on the GPS (why?!!!). The app uses 50MB of RAM - far more than any non-game on my phone. It stays running in the background (just use the notifications API dammit!) after exiting out and noticeably slows my otherwise snappy phone down, resulting in rage-inducing lagginess. All these problems disappear as soon as I head into App Settings and force stop it manually. Doing so instantly restores my phone to its snappy self.

They missed out the most resource and power hogging app available for Android - the Facebook app.

Seriously, it's a classic example on how not to use scarce resources. Just opening up the app on my Galaxy S to view the news feed powers on the GPS (why?!!!). The app uses 50MB of RAM - far more than any non-game on my phone. It stays running in the background (just use the notifications API dammit!) after exiting out and noticeably slows my otherwise snappy phone down, resulting in rage-inducing lagginess. All these problems disappear as soon as I head into App Settings and force stop it manually. Doing so instantly restores my phone to its snappy self.

They do cover the Facebook app in the actual paper and three more apps we didn't mention here, all covering roughly the same points. They also peg the Facebook app for a wakelock issue it had in one version, but then note it was fixed in the next update.

Why does an ad have access to the GPS? There is absolutely no need for an advertiser to have that level of detail about the location.GPS consumes a lot of power, but cell-phone triangulation does not and should give plenty of accuracy for location based advertisement serving. I would also find it disconcerting if the app is using up so much power for 3G ... how much data are these ads sending, anyway?

Everywhere else I read this story, it noted that they were AndroidOS phones. And not a single mention of iOS was made in the article.

It's not that much of a stretch to assume the same is happening to iOS or Windows Phone ads too. On my phone personally, I've seen ads struggle to come on a weak network connection. That's gotta be doing something to battery life. Hardly scientific, I know.

I don't know about Windows, but at least part of the problem described probably could not happen on iOS: leaving hardware components on after the app has quit. Though who knows about the rest of it.

What? No mention of apps like JuiceDefender that completely remove this "issue"?

Configure JuiceDefender to turn off all radios when the screen is off. And to turn on radios every X hours (I use 2) so that apps that sync can do their thing. And be done with it.

Without JD, I can get maybe 20 hours of use out of my 2011 Xperia Pro. With JD, I get just shy of 50 hours on a regular basis. And I use GMail, GReader, Facebook, VX ConnectBot, and Opera Mobile throughout the day.

Now, the only time I can literally watch the battery drain is when I fire up a game like Great Little War Game for an hour or two.

One recommendation for people on iOS (which I recognize isn't specifically addressed, but which is surely going to have some of the same problems caused by lazy ad-integration) is to disable Location access for any apps that don't have a good reason to use it, or simply don't allow it in the first place. This should (unless I'm mistaken) prevent them from turning on the GPS, although not much can be done about the rest besides airplane mode.

Clearly, work needs to be done on the part of app authors and on the part of the OS authors, with the goal being to turn off components that are not being used, which is how the article ended. I appreciate that this raises the visibility of such wasteful battery usage, especially for features that aren't beneficial to the customer (except indirectly, in that they allow a free version of an app to exist, but that doesn't excuse this sort of inefficiency).

I can go 3 to 4 days on my iPhone without charging under mild use. I am a bit of a minimalist for apps. Friends of mine get maybe a day worth on their phones, there is a huge difference, by like noon I will be at 85% and a coworker will be at less than 50%. I have always blamed the apps, found Facebook was pretty bad, I usually squash most apps if I am having problems with longevity and that will usually work, or turning it on and off might be easier. The makers of the phones and who run the stores should be on the lookout for these things and help out the developer and say to them, hey you are doing "this", please change to "that" to make better programming - they probably don't know it is such a big issue. It will help a lot with overall experience.

Everywhere else I read this story, it noted that they were AndroidOS phones. And not a single mention of iOS was made in the article.

It's not that much of a stretch to assume the same is happening to iOS or Windows Phone ads too. On my phone personally, I've seen ads struggle to come on a weak network connection. That's gotta be doing something to battery life. Hardly scientific, I know.

I don't know about Windows, but at least part of the problem described probably could not happen on iOS: leaving hardware components on after the app has quit. Though who knows about the rest of it.

AdAway on Android when the connection is up. Airplane mode when the network isn't needed. No power sucking / security risking ads either way.

And to be sure take out the battery as soon as you don't actively use the phone!

Seriously, having to manually switch the radio(s) on and off means that there's something going very wrong. Power management is something OS and hardware developers put much work into -- allowing apps (and ads) to wreck all this effort is just madness.

Why does an ad have access to the GPS? There is absolutely no need for an advertiser to have that level of detail about the location.GPS consumes a lot of power, but cell-phone triangulation does not and should give plenty of accuracy for location based advertisement serving

You can actually get it to do this by disabling the GPS manually. I usually have the GPS disabled on my G2 and Facebook still does it's rough triangulation thing. The only thing is you have to remember to turn it back on manually before using maps for driving directions.

What? No mention of apps like JuiceDefender that completely remove this "issue"?

...

Now, the only time I can literally watch the battery drain is when I fire up a game like Great Little War Game for an hour or two.

I think the point of the article is that when you are actually using the app (i.e. screen is on, the angry birds are flying), it consumes way too much power on location and I/O services. To take your example, it is possible that GLWG (I haven't played it myself) kills your battery so quickly in part because it is sucking down ads and keeping the GPS/radio active.

I haven't had an Android phone in a while, but I don't believe that JuiceDefender offers granularity beyond killing processes and shutting down radios given a system wide state like screen off.

It's only because the researchers could not test iPhones due to restrictions on apps policyBut I don't see how the picture will be much different from android.

And what is wrong with the title being generic? Android is a smart phone OS. Look at it the other way, just writing Android instead will create false impression that power issue somehow is nonexistent in other OSes, highly unlikely. The generic way is more appropriate.

Everywhere else I read this story, it noted that they were AndroidOS phones. And not a single mention of iOS was made in the article.

It's not that much of a stretch to assume the same is happening to iOS or Windows Phone ads too. On my phone personally, I've seen ads struggle to come on a weak network connection. That's gotta be doing something to battery life. Hardly scientific, I know.

I don't know about Windows, but at least part of the problem described probably could not happen on iOS: leaving hardware components on after the app has quit. Though who knows about the rest of it.

The NY Times app has ads even if you're a subscriber. Slow-loading, stuttering ads. Even fullscreen ones. Workaround: I let it update its cache of articles every morning on wi-fi then only read in airplane mode.Far better performance and fewer ads.

Why does an ad have access to the GPS? There is absolutely no need for an advertiser to have that level of detail about the location.GPS consumes a lot of power, but cell-phone triangulation does not and should give plenty of accuracy for location based advertisement serving

You can actually get it to do this by disabling the GPS manually. I usually have the GPS disabled on my G2 and Facebook still does it's rough triangulation thing. The only thing is you have to remember to turn it back on manually before using maps for driving directions.

On Android can one manually disable GPS on a per app basis like on iOS?

My captivate can usually go about 2-3 days without having to recharge. That being said I don't use it to browse all that much or play games on it. It's a phone. I call people and take pics. Sometimes I read a book (Thank nook app!) or play solitaire while on the can.

Therefore my wifi and GPS chips are always off. I also use an ad blocker and custom hosts file. I dare an ad to try to be served to me. I also replaced my stock ROM and loaded up Andromeda. I could probably dim the screen to 50% and get even more run time. I don't because well its a nice screen and I like to look at the purty colors.

My mind does boggle at people who cant even get a day out of their phones though. Minus replacing the ROM, everything I do for power conservation is easy and IMO, common sense. I guess what we have here is an example of the lazy factor. Most devs selling an app for $0.99 probably don't know and I bet, don't care that the ad portion of the app uses more power and cpu than the app itself.

I don't have an issue with ad-sponsored free apps --as long as they offer me a paid-for version without the ads. You choose how you want to give a developer your money, one way or the other. In most cases, I'm happy to fork over cash for an ad-free app, less annoyance, less battery usage, less data usage.

Unfortunately, there are a few apps that don't give me a paid-for option. I think some developers have found that they can make more through continued ad revenue than by charging for an ad-free app.

It's also worth mentioning for iOS apps that want to "notify" you of "icons, badges and crap". I also say NO to these apps now, because you're giving them a green light to eat up battery life, BIG TIME. In order to notify you they are constantly phoning home for push/pull data and then lighting up your phone when they get any data.

I found that after I reset my iPhone and paired down the number of apps AND disallowed all notify options, my iPhone goes from needing a charge in less than 12 hours, to going almost 3 days before reaching 10%.

I think a big issue here is not explicitly mentioning that this only affects ads that are served based on extra location data. To do that, it needs an extra permission(location) aside from the normal internet permission.

I don't typically install apps that ask for my location, unless it also needs it for some other function besides ad-serving or the benefit outweighs it some other way. Assuming a lot of people are like me, any ad-based apps I publish do not require the location permission, and won't spool up the hardware to drain the battery. I also publish paid versions alongside ad-based ones, but that's another topic.

Serving ads doesn't require GPS(or even tower) precision for location. Even the most basic APIs can serve ads based on country, language, or region without that knowledge. Anything else is overkill, and I won't be party to that.

Now out comes a paper, published by Microsoft about Android, that shows that the location grabbing component uses up battery. That somehow gets transformed by the magic of headlines(not just here but on all tech sites) to "Ads kill your battery". This simply isn't true, and plenty of developers like myself deliberately don't use this feature for one reason or another.

The findings of the research are interesting, but one thing no one has mentioned yet is that they played 28 seconds of Angry Birds (enough to fling three birds) and 33 seconds of fchess (enough for two moves). Not surprising that the head and tail energy is a large proportion of the overall energy requirement when you don’t leave it open long enough to actually do anything productive.

If I’m reading it correctly, that 28 sec Angry Birds session used 0.37% of the total battery, so unless you are launching it hundreds of times per day, the overall drain is probably not huge.

They might have used such a short session to try and measure only the drain of the ad delivery, but to then say that the free apps energy drain is 80% because of ads and crap is probably misleading unless the app is constantly delivering up new ads every 30 seconds through an extended session (maybe some do?)

BTW, WTF is up with the linked PDF. Did they export every page as a graphic? It looks absolutely god-awful.

Everywhere else I read this story, it noted that they were AndroidOS phones. And not a single mention of iOS was made in the article.

It's not that much of a stretch to assume the same is happening to iOS or Windows Phone ads too. On my phone personally, I've seen ads struggle to come on a weak network connection. That's gotta be doing something to battery life. Hardly scientific, I know.[/quote]

It is a stretch to say the same thing happens on iOS.

The iPhone prevents excessive energy use by shutting down apps when switching between apps. Multitasking only occurs via explicit channels - e.g. downloading in the background, etc. The iPhone does a much better job than Android of controlling apps gone amuck using up resources.

Of course, Android supports cite how multitasking is better on Android than iOS. But the iOS version of multitasking limits power drain and the Android version uses it up.

The findings of the research are interesting, but one thing no one has mentioned yet is that they played 28 seconds of Angry Birds (enough to fling three birds) and 33 seconds of fchess (enough for two moves). Not surprising that the head and tail energy is a large proportion of the overall energy requirement when you don’t leave it open long enough to actually do anything productive.

If I’m reading it correctly, that 28 sec Angry Birds session used 0.37% of the total battery, so unless you are launching it hundreds of times per day, the overall drain is probably not huge.

They might have used such a short session to try and measure only the drain of the ad delivery, but to then say that the free apps energy drain is 80% because of ads and crap is probably misleading unless the app is constantly delivering up new ads every 30 seconds through an extended session (maybe some do?)

My reading of the case studies comes to the same conclusion. I'm not sure about other networks, but Apple's iAds prohibits changing the ad more often than once every 30 seconds. They definitely didn't let the test run long enough to actually measure anything useful. It's possible that it would remain consistent, but, that conclusion cannot be drawn from their data.

I'd also like a comparison of the various ad networks. There's a good number out there (along with frameworks that make apps use multiple!), knowing which is the least evil would be nice for developers.

Quote:

BTW, WTF is up with the linked PDF. Did they export every page as a graphic? It looks absolutely god-awful.

It's 14 pages long, but is 1.8MB is size... they apparently did (plus, can't select any text). Definitely worthy of a facepalm. Visually, it looks just fine for me, though. Other than being unable to select text, and scrolling being a massive stutter-fest, I couldn't notice a difference.

It's only because the researchers could not test iPhones due to restrictions on apps policyBut I don't see how the picture will be much different from android.

And what is wrong with the title being generic? Android is a smart phone OS. Look at it the other way, just writing Android instead will create false impression that power issue somehow is nonexistent in other OSes, highly unlikely. The generic way is more appropriate.

Except that the majority of Android Apps are Ad driven and on iOS they are not.

Plus, some of those Apple restrictions (curation, prevention, etc,.) would prevent some of the issues with which these Ad driven apps behave. Plus iOS handles multitasking/background processes quite differently.

The iPhone prevents excessive energy use by shutting down apps when switching between apps. Multitasking only occurs via explicit channels - e.g. downloading in the background, etc. The iPhone does a much better job than Android of controlling apps gone amuck using up resources.

Of course, Android supports cite how multitasking is better on Android than iOS. But the iOS version of multitasking limits power drain and the Android version uses it up.

It isn't the multi-tasking that is to blame per this article. It specifically mentions once an app called for data over 3G, that radio stayed on for a time after the app was done and even closed.

With my older mytouch wifi would shut down if the screen did, and relied on 3G for any notifications to work. With my newer phone wifi can be configured to stay awake when needed by apps like Google Voice or ebay.

On Android can one manually disable GPS on a per app basis like on iOS?

Apps like browsers on the phone usually ask for permission to allow location data to be sent, even for certain sites. AFAIK, for apps in general though, you can't tell one app vs another to not get access to this data, unless it is turned off.

AdAway on Android when the connection is up. Airplane mode when the network isn't needed. No power sucking / security risking ads either way.

These kind of work around shouldn't have to be done. Google should be concerned cause there users aren't going to go through these kind of hassles and will blame Google and the OEM for the crappy experience. Not the app developer.

What? No mention of apps like JuiceDefender that completely remove this "issue"?

...

Now, the only time I can literally watch the battery drain is when I fire up a game like Great Little War Game for an hour or two.

I think the point of the article is that when you are actually using the app (i.e. screen is on, the angry birds are flying), it consumes way too much power on location and I/O services. To take your example, it is possible that GLWG (I haven't played it myself) kills your battery so quickly in part because it is sucking down ads and keeping the GPS/radio active.

I haven't had an Android phone in a while, but I don't believe that JuiceDefender offers granularity beyond killing processes and shutting down radios given a system wide state like screen off.

If you have either paid tier of JuiceDefender (there's $2 and $5 versions) you get per-app connectivity configuration. That is, I can specify that if I'm running say, Pandora, that I want the 3G to stay on even if my screen is turned off. Or conversely, you can tell it to shut off the radio if you're playing a game like Angry Birds or GLWG that has no need for an internet connection besides pulling down ads.

The configuration is also pretty convenient. Instead of having to go through and tediously setting the option for every app there's an "interactive" configuration mode that serves a pop-up the first time you run an app after installing JuiceDefender (or after installing a new app) that lets you choose your preferred connection status for that app. It doesn't work all the time - some apps rewrite the screen which clears the popup before you can select something - but otherwise it's a nice way to have JD learn as you use your phone. Also, there is a "Do nothing" option - often this is what I choose and just let JD do its thing. Mostly I use the "Apps" feature in JD to keep the connection on while the screen is asleep for Pandora, NPR, Market (for updating apps en masse), etc.

Just one note, JD does not kill processes. "Task Managers" are generally unnecessary for Android phones; I only keep one around to kill a stray misbehaving process, but the OS should handle all routine memory management relatively efficiently nowadays. JD is also one of my "must have" apps for an Android phone. I can get multiple days of light use on my phone with JD (and a clean ROM and some other optimizations), where before it sometimes struggled to make it from morning till bedtime.