

Verizon Names Data-Draining and Battery-Killing Apps - ocean12
http://www.businessweek.com/articles/2013-02-11/verizon-names-data-plan-and-battery-killing-apps#r=rss

======
IvyMike
I'm going to take this opportunity to complain about Google Navigation app, on
every device I've owned.

Their directions really should say "ETA: 3 Hours from now. ETToBatteryDrained:
1.5 hours from now. Shoulda remembered your car charger, dumbass". 'Cause I do
forget to pack it every goddamned time.

I don't know if this is really possible, but they really should have a "low-
accuracy" mode, where if you're on a freeway with no turns for an hour, they
should turn off the GPS, and just use inertial or cell-phone navigation
mostly. Then only periodically check the GPS. If you are going to turn soon,
or appear to have deviated, they can go back into active GPS mode, but the
goal is to avoid wasting battery when you're probably just following the road.

~~~
jpitz
It is the nav app keeping the display lit up like a Times Square billboard
that is sucking the majority of your battery life down, by the way. Your
suggestion stands, however.

~~~
buzzkillr2
You can lock the display and the voice directions still subsist. The battery
drain is from the constant polling of GPS information in my experience though.

~~~
runeks
> The battery drain is from the constant polling of GPS information in my
> experience though.

Why would that use a lot of power though? It's just receiving a signal. I have
the impression that it's when sending out a signal that a lot of power is
used. And in that sense electromagnetic radiation at GSM, Wifi or visible
spectrum-frequencies are all the same.

I'd say it's both keeping the screen on and constantly downloading new map
information from the cellular network.

------
wiredfool
One of my friends does research on this for another of the big carriers, and
has told me some war stories.

* No one caches, or they cache really badly. They've seen 20-30% reductions in battery usage from implementing a caching scheme from one version to the next. His theory is that they're coming from the web world, where caching is baked in.

* One app killed the battery by waking up the radios every 2 minutes to check for updated scores, sending a few bytes each time. Network traffic, in aggregate, was very small, but it just killed the batteries.

~~~
mikeash
That second one seems like an easy mistake to make. If you're thinking of
ethernet or WiFi, then a few bytes every couple of minutes is no big deal. But
on 3G, every time you activate the radio when it's not being used, it's a few
seconds of fairly intensive setup, then your communication, then a few seconds
before it times out to a lower-power state, then a few more seconds before it
goes fully back to sleep. It'll be something like 10-20 seconds total, so your
quick blip every 2 minutes ends up keeping the radio on a 10-15% duty cycle!

~~~
Scene_Cast2
I've never done mobile dev. I get the problem, but what's the preferred
alternative? For, say, email, sports scores, VOIP messages, stats dashboards,
etc?

~~~
wiredfool
For truly time critical stuff, push notifications, done however the platform
vendor does it for optimum battery life.

If not, then some sort of exponential backoff helps so that you're not
updating scores every 2 minutes all night.

------
ocean12
I think they made at least one error: Need for Speed: Most Wanted was not
developed by Rovio.

Also of interest is that none of the streaming radio services suffered in
their rather proprietary ranking:
[http://support.verizonwireless.com/information/app_ranking/i...](http://support.verizonwireless.com/information/app_ranking/index.html)

~~~
tadfisher
It makes sense for a streaming radio app to acquire a wakelock, unless you
want it to stop playing when the screen shuts off in 2 minutes. It does not
make sense for any game to acquire a wakelock, and acquiring one is a sign
that your app does not respect the Activity lifecycle and probably doesn't
handle notifications or task switching well anyway. I know GTA3 absolutely
sucks at this.

------
tadfisher
The actual list:
[http://support.verizonwireless.com/information/app_ranking/h...](http://support.verizonwireless.com/information/app_ranking/high_risk.html)

It is interesting to note that 100% of the apps listed are games with
wakelocks. While some may argue that this is necessary for games, I counter
that your game should pause after a period of inactivity and allow the device
to sleep. Just because your app is a console port does not mean it is running
on a console.

Kudos to Verizon for naming and shaming.

~~~
masklinn
> It is interesting to note that 100% of the apps listed are games with
> wakelocks. While some may argue that this is necessary for games, I counter
> that your game should pause after a period of inactivity and allow the
> device to sleep.

Fucking meh. Seriously. They list a bunch of games which keep all the most
power-consuming subsystems running full tilt (including radio for some),
here's why they drain the battery: they're being used and doing their job.

Seriously, this list is idiotic, you've got complex games, you're playing
them, it's going to drain the battery when you use them. Period. That's been
pretty much a constant of my 6 or 7 years of using smartphones. Users using
their phone will play, and when they don't play they'll quit the game or
manually lock the phone.

Some of them _do_ have issues ("Hill Climb Racing" seems to be a good example
there, keeping radios running when in the background) but aside from this hint
you have to hunt for the list is utterly worthless.

~~~
tadfisher
This isn't about the complexity of the game or how much battery it drains
while playing. This is about you setting your tablet down for half an hour
with the game paused, then coming back to find it has drained half your
battery unnecessarily. Or you switch out to check your email, get distracted,
and find that the running game has drained half your battery unnecessarily.

Android has an Activity lifecycle for a reason, and these games do not respect
that. Users should not be worrying themselves with managing resources. If your
game gets shoved out of the foreground, it should have the good graces to save
its state and allow the device to sleep, like _every other app on the system_.

~~~
masklinn
> This isn't about the complexity of the game or how much battery it drains
> while playing. This is about you setting your tablet down for half an hour
> with the game paused, then coming back to find it has drained half your
> battery unnecessarily. Or you switch out to check your email, get
> distracted, and find that the running game has drained half your battery
> unnecessarily.

If _that_ is the issue, there is _no indication whatsoever_ of it in the list.
What it says is "When running, this app keeps the device from going into sleep
mode." Not "this application keeps running in the background". If these
applications keep running in the background and you have evidence of that I'd
be happy to note it and their misbehavior, but the page _you_ linked is — as I
noted — completely worthless. Because that's not what it says, whether it's
due to terrible copywriting or because that's not the issue.

> If your game gets shoved out of the foreground, it should have the good
> graces to save its state and allow the device to sleep, like every other app
> on the system.

Sure, if that's what happens I'd be happy to concede the point, but that is
not the way I read the page, considering the way these blurbs are written I
interpret them as "we opened the application in the foreground and put down
the device". Especially given they _specifically note_ when applications
misbehave in the background, in both cases of network misbehaviors.

~~~
tadfisher
Play GTA3 on a Nexus 7 sometime. Switch out to another task (or hit the Home
button). Let it sit for half an hour, then check Settings -> Battery. You'll
find that GTA3 is at the top of the list and is pegging the CPU.

Their workaround for not obeying the Activity lifecycle is to display a
persistent notification that the game is running. This is is not a solution
for their actual problem, which is that they have no way to serialize the
game's running state, and thus will lose any unsaved game data if they do obey
the lifecycle and let their app get culled. This is evidenced by the need to
go to the ingame save points in order to save your game, like on a console.

Even if the game is open in the foreground, there is no reason why it can't
give up its wakelock after a period of inactivity. Obviously this is a lesser
issue as you have described, but it is still contrary to the UX of most
Android apps.

------
hackmiester
Impose Draconian data caps and try to con your users into leaving their
unlimited data plans. Then, call apps out for using too much data.

Thanks, Verizon.

~~~
tadfisher
Is it not their prerogative to ensure a good quality of network service and
user experience? These apps harm everyone who uses the service
_unnecessarily_.

Is Google also being hypocritical by encouraging users to use networks for
Search et al, at the same time encouraging developers to optimize for network
usage and battery life? [1]

[1] [http://developer.android.com/training/efficient-
downloads/in...](http://developer.android.com/training/efficient-
downloads/index.html)

