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.
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.
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.
> 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.
I don't own a car charging adapter, but on most trips where I'm using my phone for navigation I'll also have a laptop and charger cable in the car.
For Apple laptops, if you start charging while the computer is awake it will keep charging when the laptop is sleeping. For PCs it varies by manufacturer, but IIRC some of them have a BIOS/UEFI option for powering USB ports while they're asleep.
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.
> Network traffic, in aggregate, was very small, but it just killed the batteries.
And as most developers here would know, radios are an expensive piece to wake and won't go to sleep immediately, so doing more smaller network interactions is usually going to be much more expensive (power-wise) than doing fewer big ones (or using notification systems piggybacking on other stuff and bundling req/rep for all applications, e.g. what I hope GCM does)
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!
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?
Apple provides push notifications, which work similar to SMS messages, in that your server can push data to the device without needing the device to poll, due to deep integration with the lower level cellular whatsis. I think Android has something similar as well, but I'm not completely familiar with it.
Basically, IP over 3G works pretty well overall but can be a real battery hog, and dropping down to something more native can be a big win. Cellular radios are built to use very little electricity while monitoring for a wakeup call from the tower they're connected to, so if you can take advantage of that like push notifications let you do, then you'll do a lot better.
A somewhat less wonderful alternative is to keep a persistent TCP connection open with a very long timeout, with the remote end sending a notification to wake up the phone when needed. You'll have no traffic most of the time, and the wakeup being initiated from the remote end removes the need to poll. I believe this is how Skype (and other VoIP apps that allow incoming calls in the background) works on iOS.
Edit: I forgot another technique that some iOS developers have used: register with the "significant location change" API, which can be used to wake up your app when the cell radio switches towers, and then check for new data then. This is technically an abuse of the API (which is intended for when you actually need to know about location changes) but works well enough. It can help to e.g. ensure your stuff is recently synced before the user goes into the subway and beyond data coverage. Once again, this is using low-level cell radio stuff to avoid overtaxing things.
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.
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.
> 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.
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.
> 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.
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.
Huh? Your wording suggests that these two things are somehow contrary to each other, but in fact they're both perfectly aligned with the goal of reducing network utilization.
Hate on them if you want, but this isn't the least bit inconsistent.
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]
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.