> Battery - We’re making Android devices smarter about managing power through a new feature called Doze. With M, Android uses significant motion detection to learn if a device has been left unattended for a while. In this state, Android will exponentially back off background activity, trading off a little bit of app freshness for longer battery life.
Will this improve wakelock performance that has been plaguing Android for years?
Wakelocks have just been a scapegoat for people to pretend to sound smart when just saying that they want better battery life. They haven't actually been an issue for years.
No, this won't magically fix bugs in apps that lead to poor battery life. If an app opens the camera and forgets to close it, yeah that's gonna murder your battery.
Yep, you can as easily find battery guzzling apps by looking at CPU time.
Whenever i have something odd going on with the battery life, some app is sitting right up there with Android system for CPU time (sometimes even above). And you don't hit those kinds of numbers even with heavily used apps like web browsers (and yes, the most frequent offenders are the Facebook slop that i only have because family).
I, too, would love to live in a world where it's impossible to write bugs. Things would be so much nicer if Google could just solve the halting problem already.
Sadly it's more likely I'll just get some stupid pony instead.
The OS manages resources. It can temporarily grant (exclusive) control of a resource to an application. It can measure your other resource activity (touchscreen). If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?
Sure, it can be a spy app, designed to listen and record! But then the OS can expose a per-app maximum wake setting. Yes, it'd look like a spreadsheet instead of a happy user UI, but that'd be a solution, instead of this "oh we can't do anything" excuse.
> If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?
Because the OS shouldn't be making assumptions about applications' interaction models. People tend to write apps that OS creators never dreamed about. There are legitimate reasons for resource usage (camera) to continue without user interaction.From the top of my head, I can imagine writing a baby-monitor app that uses camera to stream video to my phone in the other room using wifi.
The resource-limiting heuristics have to be impossibly good, otherwise it gets in the way of useful apps.
One way of handling this is to have a separate permission - Use camera, which allows an app to use it for a limited time with the user interacting and while in foreground, and a 'Background Camera' permission which your baby-monitor app would request. Perhaps make the permissions dialog for the background permission scarier so developers have an incentive to use the less privileged permission.
This would work nicely for GPS etc - sure, I want to be able to have My Tracks keep GPS on for 3 hours, but I don't need Uber to be able to do that - and their app has a nasty habit of forgetting to turn the GPS off if you leave it at the wrong time.
> If not touch screen activity for a long time, or when simply the screen is locked, then why is the camera on?
Face unlock, dash cams, baby monitors, live-wallpapers-that-make-your-phone-look-transparent, security apps that snap a picture when someone fails to enter the correct unlock code and emails it to you, etc...
But replace camera with GPS and it's the same thing. Or audio. Or motion detectors. Or just really frequent alarms to poll a server (see IRC apps for an example)
The keynote claimed they took two identical Nexuses side by side with Lollipop and M loaded it up with a bunch of common apps. The standby battery time with M was around double.
Will this improve wakelock performance that has been plaguing Android for years?