One other thing this deck doesn't go into but has a huge impact (for games at least) is frame rate. Higher frame rates require the GPU to get the work done in a shorter amount of time and make it less likely that the GPU will be able to switch to an idle power save state.
A good example of this in action is the game Threes. The developers implemented a "power save" feature in the game which simply cuts the frame rate in half[0], causing the app to consume noticeably less battery.
I worked on a mobile FPS that was able to run at full-rez, 60fps on an iPad3. Unfortunately, doing so drained the battery faster than the wall charger could refill it! So, we shipped locked at 30fps and provided a "battery hog mode" option to the user.
What level was the battery at? Past 80% most Lithium Ion or Lithium Polymer battery controllers will change to a trickle charge which could explain it.
Ingress can do this on a Galaxy Nexus with a 2A external battery pack (or, ya know, car). I was only able to help with about 1/2 of an Interitus event cause my phone kept dying and I'd have to wait a bit to bring it back online.
I thought this slide deck would cover the improvements introduced by Project Volta [1] in Lollipop. They introduced a JobScheduler API that developers can use to perform the batching that he described, as well as the Battery Historian for better power profiling.
I really hope Google one day adds a "battery usage" and "network usage" rating for apps in the play store.
Common users are pretty helpless when it comes to figuring out which apps are killing their phone.
Yeah, the fact that we Android users need to use apps like Better Battery Stats is pretty telling. They could at least stick it in the developer settings somewhere.
Why is any of this even necessary at this stage. Android has been around for 7 years, 5 major versions, and many more subversions. Power management should be solved by now. The OS should be managing this. All power management options should be applied to all apps and only those that need an exemption should code around it.
It's a balancing act between giving devs power over their code and managing battery. You could say that Apple 'solved' the problem by preventing developers from doing really cool things, whereas Google/Android still have battery concerns but devs have built awesome apps that depend on that flexibility.
This isn't something than can be 'solved'. All the time, Google will make improvements to the OS (like JobScheduler in Lollipop) and devs will get better at managing their resources. Slowly we'll all get better battery performance.
I make PressureNet, which runs in the background on Android in 10-minute intervals to get GPS, barometer measurement, and network lock. Maintaining a good battery life isn't easy, but it is possible. https://play.google.com/store/apps/details?id=ca.cumulonimbu...
Devs can still have all the power, as long as excessive battery usage is more transparent to users. I'm not sure about iPhone, but OS X has an indicator with "Apps Using Significant Energy." [1] as well as a more detailed breakdown [2]. Very useful. Often turns out to be a stray tab in Chrome. Would like to see something like that.
An iPhone-using friend of mine constantly points out how lacklustre the battery performance in Android is - the Nexus 5 has a bigger (?) battery than the iPhone 5 but the iPhone 5 will last for a full day with similar use.
Its not critical that we get GPS at that interval, just preferable. So we turn on GPS but we don't necessarily wait for a good location to be returned. After a few seconds we either fall back to a network location or the most recent GPS location if that's better than network.
It's not perfect, which is unfortunate and may be a blocker for other use cases. But for us it's a good balance of quality location and battery usage.
Because apps are commonly requesting that the device perform actions that require excessive amounts of power according to the laws of physics. Can you imagine the complaints the OS devs would get if they stepped in to intervene?
"I noticed your app made a separate request to the ad server every 30 seconds (between menus). So, I decided to batch up your requests and only send them every 10 minutes."
A good example of this in action is the game Threes. The developers implemented a "power save" feature in the game which simply cuts the frame rate in half[0], causing the app to consume noticeably less battery.
0: http://asherv.com/threes/support/