Android L boosts Nexus 5 battery life by 36%

One of the key features of the recently-announced Android L is 'Project Volta', which aims to boost the battery life of Android devices by tidying up the operating system in a variety of ways to preserve power. The question many will be wondering though is "Will this actually make a difference on my device?"

According to Ars Technica, the answer is a definite yes. In testing, they found that a Nexus 5 lasted over two hours longer when running Android L Developer Preview over the latest version of KitKat, 4.4.4, at 471 minutes. This is up from 345 minutes and represents a 36% increase in battery life. The tests comprised leaving the screen on while refreshing a webpage every 15 seconds over Wi-Fi until the device died.

Much of the power saving will have come from the new JobScheduler API that means the operating system now controls maintenance and house-keeping tasks, running them all together when system load is low. Some tasks, at the request of the developers, are postponed until the phone has been plugged in, thus representing a substantial power save in itself.

Android is also now much better at allowing apps to refresh their data and disables this power-hungry functionality altogether if no network connection is available, preventing the phone from repetitively trying and failing to synchronize network tasks. The usage of the ART app runtime, theoretically enabling apps to run twice as quickly, in place of the ageing Dalvik also saves battery as apps are compiled just once, at installation, instead of every time they are run, cutting down CPU and therefore power usage.

This can only be good news for consumers, especially those who own phones that can drink a full charge in just a few hours of usage; Android L is expected to arrive with its new 'Material Design' interface and other improvements later this year.

Source: Ars Technica | Image via Google

Report a problem with article
Previous Story

Microsoft's new Surface Pro 3 videos highlight its best features

Next Story

Legere makes it clear that T-Mobile is here to do right by customers

50 Comments

Commenting is disabled on this article.

So kinda like Windows Phone Battery Saver. It's great they did this it should have been standard from the start for all smart phones :)

Most important is the update. Now we depends on manufacturer. And after 1 year mostly manufacturer did not update anymore. Including big manufacturer

thats why im getting a windows phone this time - not all of the devices are being updated to the newest versions of android

and i dont understand why should the company which made the phone be the one to bring the update

the whole android thing is such a huge mess i dont even want to know about its existence anymore

Deyirn said,
thats why im getting a windows phone this time - not all of the devices are being updated to the newest versions of android

and i dont understand why should the company which made the phone be the one to bring the update

the whole android thing is such a huge mess i dont even want to know about its existence anymore

Google develop Android software...

Sammyinnit said,

Google develop Android software...

i know they do, but did you know that the company that made the device has to release the update? or you can just read along the lines

I ran it all day today on my Nexus and I would say the battery lasted about 20% longer not 36% but still...its a LOT better than it was =)

Not surprised by some of the comments on this. Android pretty much got rid of the lag and now better battery life. Things that people on both sides of the fence wined about. . Haters gonna hate I guess.

techbeck said,
Not surprised by some of the comments on this. Android pretty much got rid of the lag and now better battery life. Things that people on both sides of the fence wined about. . Haters gonna hate I guess.

yes got rid of the lag sometimes in 4 core cpu devices buddy. you put a low end android device next to a low end WP and tell me if the lag went away. google didn't as much get rid of anything as much as snapdragon 800 saved their bacon.

I said pretty much gotten rid of. I didn't say it went away. Read next time. . obviously you never used as new lower end android the the Moto phones. Pretty much little lag. But hey, every phone has a little lag and you would blind not to see it. And be it a android hater or support, you would also be blind but to realize they have come a long way. Yes. They still need work but show me one platform that doesn't. Nothing will ever be prefect.

techbeck said,
I said pretty much gotten rid of. I didn't say it went away. Read next time. . obviously you never used as new lower end android the the Moto phones. Pretty much little lag. But hey, every phone has a little lag and you would blind not to see it. And be it a android hater or support, you would also be blind but to realize they have come a long way. Yes. They still need work but show me one platform that doesn't. Nothing will ever be prefect.

I love my Moto X. But it definitely lags here and there. As bad as my old iphone 4s with iOS 7. A reboot tends to resolve the issue. It's most noticeable after a few days without a restart. My older Lumia 920 is still a much faster phone even with half the RAM. But I have so many more apps for the Moto X, which I guess is part of the problem.
With that said, I am looking forward to the improvements in Android L.

techbeck said,
Not surprised by some of the comments on this. Android pretty much got rid of the lag and now better battery life. Things that people on both sides of the fence wined about. . Haters gonna hate I guess.

uh huh, with that HP spilling hardware, android sure won't lag, but if we run it on low end hardware like WP devices, it will end up with lag. Low end android sets lag, even Moto ones.

Nice, now Android devices will go from simply having better battery life than their Windows Phone hardware counterparts (that is WP devices running on the same hardware) to leaving Windows Phone in the dust

Sonne said,
Nice, now Android devices will go from simply having better battery life than their Windows Phone hardware counterparts (that is WP devices running on the same hardware) to leaving Windows Phone in the dust

Huh, WP devices already have excellent battery life compared to Android devices. Battery Saver has been on WP for ages, Google are just playing catch up with Project Volta!!!

I never had battery issues with my Nexus 4 or 5. I don't know what people do on their phones that kill it so fast. I do email and calls all day long in my job. I still get home with 10-15% left when I can charge it.

I am running L and when I left the house I had partly used my battery, I didn't look but was around 70% full. I drove to work using Bluetooth to listen to pod-casts, then used my phone while at work, some on WiFi some off, and got my emails and Google apps syncing, and Skype, some web browsing. I got back in my car after work and listened to more Bluetooth. I got home with 40% left.

I am not fully charged and the phone says that based on my usage I'll get until 11 AM on 7/6 before my battery dies. and I'm not even using the Battery Saver mode yet.

"also saves battery as apps are compiled just once, at installation, instead of every time they are run"

Is that really true? That the programs had to be compiled every time it run? I cannot imagine any solution more performance-wasting than this!

Setnom said,
Yeah, that is really weird!! What possible benefit could that have had?
This is how every .NET and Java program works. It saves storage space, memory footprint as the program runs - only the code that actually gets run is compiled - and is much faster on first run. However the tradeoffs are longer startup time on subsequent runs and poor code optimisation. Now that smartphones tend to have decent storage space, ahead of time compiling has become the better solution.

eddman said,

Isn't that done just once, whenever you install a .NET redist, to solve that very issue?

http://blogs.msdn.com/b/davidn...hive/2005/04/27/412838.aspx

I'm not a programmer so I might be interpreting that article wrong.

That's correct, core .NET assemblies (like the ones Microsoft publish) are precompiled. But your usual .NET application consists of IL bytecode that is compiled just-in-time.

The story is a bit more complicated than that actually but I didn't want to get into too much details.

well, in the case of windows phone apps, they are jitted (the correct technical term for this) in the cloud for your device's particular platform therefore no, windows phone never suffered from this.

there is even cooler technology beyond what google is doing coming form MSFT if you're interested which is called project N.

I'm not surprised google is this far behind. their tools and programming model sucks compared to what we've had in .net and VSS for years.

neonspark said,
well, in the case of windows phone apps, they are jitted (the correct technical term for this) in the cloud for your device's particular platform therefore no, windows phone never suffered from this.

If it's done ahead of time in the cloud then "jitted" is not the correct technical term because JIT stands for just-in-time which compiling in the cloud is not. MS might call it that for some reason but it's not the correct technical term.
neonspark said,

I'm not surprised google is this far behind. their tools and programming model sucks compared to what we've had in .net and VSS for years.

Apples to Oranges. Android started out on low end hardware that couldn't run something as large as .Net and evolved from there. The method they use up till now is a good one if you are storage space constrained and need to work across different hardware platforms. Apple is able to go to native code because the only run on one hardware platform (ARM) with a limited number of configurations. Android on the other hand runs on ARM, Intel, MIPS, and possibly others. So apps compile into cross platform bytecode (similar to .Net CIL) so the same APK can run on those different architectures. MS is able to pre-compile their apps in the cloud because MS only supports a limited set of hardware as well (though more diverse than Apple) so they know what the targets are and they entered the game much later than Android so they didn't have to run on such low end hardware. Android app packages (apk) have no idea what hardware they are going to run on, anyone can download the source and port android to any hardware they like, part of that porting would be writing the compiler for their hardware to JIT the "universal" APK. The App developer doesn't have to do anything, their app "just works" on entirely new hardware (unless they used the NDK to make native code) and google and the play store don't have to know anything about that hardware.

What's new here is that ART will compile on install instead of every run. The downside of this, and why they didn't do it before, is that you'll then have BOTH the "universal" bytecode APK AND the newly compiled native code binary on your system which takes more space. That space used to be at a premium but now with SD cards as big as they are it's considered an acceptable trade-off. Note this doesn't double the size as resource files (graphics, sounds, etc.) don't need to be stored twice and they account for most of the size of an app. If you're a .Net developer then ART is similar to NGEN. Paint.Net does a similar approach where it is written in .Net but it compiles at the end of the install process.

As for Project N the rumor is that is a source code to native code compiler for .Net. This would be pointless for Android as they NEED that intermediate stage to work on different hardware types.

the term Jitted comes from the JIT compiler, but yeah it is technically not just in time so I give you that one. same result though than running the ngen tool however.

Your it really isn't apple to oranges in the other regard. Also it is not true whatsoever that native means only one architecture. you clearly overlook the fact that winRT apps can be native and windows apps run on both ARM and intel devices making your assumption that apple runs native because it only runs on ARM incorrect. MSFT windows winRT apps run in as many variety of ARM devices as google has to, yet they are not bothered by c++ code, except off course where win32 interop is required, yet that is a limitation put in place by MSFT's api policy and not something due to the use of native code.

I also know this for we produce native c++ android apps and there isn't all that much variation to deal with in reality. The APK does need to be submitted differently but with MSFT, they take your solution and handle the ecosystem diversity in the cloud, something google is far behind. Google really needs to step up the game.

ART is nothing new whatsoever. It is exactly the same thing java and dotnet apps have been doing for ages with their native image generators. However the problem is that you really can't get things as efficient as MSFT has done with project N, which take the much more optimized c++ compiler and a native version of the .NET FLC and gives you a native image that is cloud compiled with optimizations not possible with native image generation techniques on the device. The brilliant approach of project N is that they will embed portions of the FCL in your executable image as you need them by static analysis. This means greater efficiency and lower footprint than having to dynamically load the libraries which is what google, and traditional java and .net do. This is because MSFT will only embed the parts of the assemblies you actually need instead of the entire thing needed to be loaded as a dll which will put it as part of your working set as far as the managed runtime cares. And furthermore the optimizations that can be done on the cloud via static analysis continue to improve without an OS compiler update meaning as MSFT improves their cloud compiler, you benefit even in old OS versions the next time an app update is pushed.

Therefore it is also completely false that google couldn't benefit from something like project N. the android API is very vast and they could benefit from static analisys on the cloud and perform the same optimizations MSFT does. Technically speaking even if they transmit IL to the device for native image generation, the memory savings and performance gains are well worth the effort, but off course, there is no reason to do that as MSFT has clearly demonstrated it is not only possible, but they are already doing it. Realistically x86 and ARM are all that really matters, and which both instructions sets maturing and with further ARM consolidation, at this point, google is just behind period.

Also contrary to your theory that the storage was an issue is the fact MSFT WAS DOING THIS in windows phone and certainly has not been an issue with storage. It is also not the case google needs to keep the bytecode around once the native image was compiled. There is no technical need to keep both images so I don't believe you're correct on this one, and if they do, well they are google :) no surprises ha ha.

btw, no need to explain the basics asmodai. I've been coding for java, c++, android winphone, winRT, .net for over a decade now :) I think I remember basics :p
My point isn't to review the basic concepts of android programming, my point is that what google is doing today, we've had in the MSFT ecosystem and ARM isn't the reason they were doing it, neither is storage, neither is needing to support x86 and ARM.

the reality is google's tools, and sdk are jus behind IMHO :) Even today, when I have to work on some c++ on android or java after a few days in vs c++ and .NET (for mobile both ARM and intel ;p, I feel like I've stepped back to the days of unix programming lol. I know google will someday get there, maybe.

Edited by neonspark, Jul 3 2014, 11:28pm :

neonspark said,

Your it really isn't apple to oranges in the other regard. Also it is not true whatsoever that native means only one architecture. you clearly overlook the fact that winRT apps can be native and windows apps run on both ARM and intel devices making your assumption that apple runs native because it only runs on ARM incorrect. MSFT windows winRT apps run in as many variety of ARM devices as google has to, yet they are not bothered by c++ code, except off course where win32 interop is required, yet that is a limitation put in place by MSFT's api policy and not something due to the use of native code.

Native usually refers to the underlying processor architecture so Asmodi was correct and please show me how to install the nice shiny version of Office 2013 for the x86 onto a ARM Windows variant. Metro aps may be different but compiling them in the cloud isn't necessarily any better than having the client do it.

Dont forget apk's should, by and large, run on AOSP which any one can make run on any processor architecture... if they have the time and resource. Enforcing that google has pre compiled binaries for specific architectures would disallow for this and require special tooling for each new processor architecture. Plus where would blackberry be if they couldn't get ahold of generic APKs!

Zerosignull said,

Native usually refers to the underlying processor architecture so Asmodi was correct and please show me how to install the nice shiny version of Office 2013 for the x86 onto a ARM Windows variant. Metro aps may be different but compiling them in the cloud isn't necessarily any better than having the client do it.

Dont forget apk's should, by and large, run on AOSP which any one can make run on any processor architecture... if they have the time and resource. Enforcing that google has pre compiled binaries for specific architectures would disallow for this and require special tooling for each new processor architecture. Plus where would blackberry be if they couldn't get ahold of generic APKs!

office is a win32 application not a store application. what I say refers to store apps buddy. Open visual studio, select c++, you'll be given the choice of vb.net/c# or c++ in addition to winJS. c++ is native, not any less native than office but it runs under the API constrains that MSFT has put in place. Yet it will run on arm, and anything else MSFT decides to support in the store. They take care of the compilation to ARM and all its flavors/and X86 (or you can choose to just be X86). So no, Asmodi is not correct.

And if you want an ARM version of office we know it exists in windows RT. We also know that Gemini uses direct X in at least power point as indicated in the last build, and this is native c++ for a fact. We also know this will be supported on ARM devices in addition to x86, so this probes beyond doubt native code presents no problem to MSFT store app model period.

And you're also incorrect that modern apps aren't better compiled on the cloud, as we know from project N, the optimizations MSFT can do on the cloud aren't possible on the device, for one thing they have the source code for all the FCL and will do static analysis on your code to embed the parts of the libraries and avoid dynamic linking. This static linking leads to great performance increases and lower memory footprint. Please research project N's advanced cloud compilation before dismissing what the cloud is doing for MSFT.

And it is also incorrect google cannot do this because of AOSP. Let's say in the unlikely event you do have android on something as abandoned as PowerPC, well the device can simply report to the service its cpu and if google doesn't have a pre-compiled version, it can then hand over the bytecode for on device image generation. Given as 99% of android devices are wither ARM or x86, google could in fact give this benefit to most its users while letting the other 1% still work. This would have zero drawbacks for everybody.

In fact I would say that given how badly google wants to lock people in, and avoid something like apple or MSFT running android apps, they may very well compile them in the cloud against specific OS bindings which make it harder to take to other platforms.

so yeah, google is behind :)

neonspark said,

office is a win32 application not a store application. what I say refers to store apps buddy.

You never said anything about just store apps which, if you read my reply I did make special consideration for metro apps.

neonspark said,

Open visual studio, select c++, you'll be given the choice of vb.net/c# or c++ in addition to winJS. c++ is native, not any less native than office but it runs under the API constrains that MSFT has put in place. Yet it will run on arm, and anything else MSFT decides to support in the store. They take care of the compilation to ARM and all its flavors/and X86 (or you can choose to just be X86). So no, Asmodi is not correct.

No you prove Asmodis point. C++, C#, VB.net are all managed languages and have been for many years. Unless you can write some to-the-metal assembly code in them then they are not native to the processor architecture.

neonspark said,

And if you want an ARM version of office we know it exists in windows RT. We also know that Gemini uses direct X in at least power point as indicated in the last build, and this is native c++ for a fact. We also know this will be supported on ARM devices in addition to x86, so this probes beyond doubt native code presents no problem to MSFT store app model period.

Again office has been compiled down to a non portable binary that will only work on ARM or x86 and DirectX is a API so I'm not to sure what you are implying?

neonspark said,

And you're also incorrect that modern apps aren't better compiled on the cloud, as we know from project N, the optimizations MSFT can do on the cloud aren't possible on the device, for one thing they have the source code for all the FCL and will do static analysis on your code to embed the parts of the libraries and avoid dynamic linking. This static linking leads to great performance increases and lower memory footprint. Please research project N's advanced cloud compilation before dismissing what the cloud is doing for MSFT.

Right so compiling something on a server makes it better how? I smell some cloud hype there. Programs have been compiled to run natively on computers for decades. Adding the cloud into it sounds like hype to me and also goes back to the original point of an APK which is portability. The APK does not know -or care- what CPU architecture or Operating system it runs on. I'm guessing the native android SDK is mainly there to allow the use of assembly language and not necessarily just c++.

neonspark said,

And it is also incorrect google cannot do this because of AOSP. Let's say in the unlikely event you do have android on something as abandoned as PowerPC, well the device can simply report to the service its cpu and if google doesn't have a pre-compiled version, it can then hand over the bytecode for on device image generation. Given as 99% of android devices are wither ARM or x86, google could in fact give this benefit to most its users while letting the other 1% still work. This would have zero drawbacks for everybody.

Thats a really good idea. Google should consider compiling for the majority used CPU architectures and dish out the APK IF the program hasn't been locked down due to NDK use. Only thing I can think off that would make that maybe not work is how the code is signed? If its signed by google then should work. If its signed by the devs then it wouldnt.

neonspark said,

In fact I would say that given how badly google wants to lock people in, and avoid something like apple or MSFT running android apps, they may very well compile them in the cloud against specific OS bindings which make it harder to take to other platforms.

so yeah, google is behind :)

To be honest they have mostly achieved that with google play services.

Anecdotally back in the day with Windows Mobile 6 or below it was a right pain in the ass to develop apps due to different cpu architecture use. ARM (with multiple variants grr) and MIPS all had Windows Mobile versions and targeting them, although easy in a sense, still produced some issues. The biggest one that catches us out is that even with .net compact you sill had to distribute bits of it that were compiled for the correct CPU architecture and VS would constantly not deploy the right bloody SQL assembly for ARM devices and cause apps to crash.

Both MS and Google solutions have pro's and con's and work well and both are much much better then the crap that came before!

soder said,
"also saves battery as apps are compiled just once, at installation, instead of every time they are run"

Is that really true? That the programs had to be compiled every time it run? I cannot imagine any solution more performance-wasting than this!

The whole application isn't compiled each time it is run - they use JIT which optimises and compiles parts of the application when they're being being used - it has benefits and draw backs. Although managed languages do make life easier for the programmer I'd sooner see the likes of Google, Microsoft and Apple spent the time and money to develop tools which make writing native code easier and less error prone.

Some noted about Windows Phone - Windows Phone 7 and 8 used Silverlight but Windows Phone 8.1 bought the full WinRT stack which is native code.

TheCyberKnight said,
It shows and confirms the general consensus : Android was energy inefficient with the prior releases.

Isn't that common with most "prior releases"

and still is. it's reliance on java on top of the jit hunts it compared to objective c. however the biggest reason for the poor performance is just android bloat. google honestly couldn't care less about performance on mid/low end devices.

neonspark said,
and still is. it's reliance on java on top of the jit hunts it compared to objective c. however the biggest reason for the poor performance is just android bloat. google honestly couldn't care less about performance on mid/low end devices.

You do realise they made changes to 4.4 that make it run much more nicely on low end devices... right? Never let facts get in the way of a good story as they say.

Show me a "low end" device that runs just stock Android + Google apps that's not a Nexus. You wont find one. Its not Android that slows it down, its all the bloated UI and skins and apps that other makers put on it

Ricardo Dawkins said,
Your moto G has a newer battery

Even when my iPhone was brand new the battery never lasted as long as my Moto G does. My wifes iPhone 5s does not last as long as my Moto G does. It isn't the age of the battery.

neonspark said,
and still is. it's reliance on java on top of the jit hunts it compared to objective c. however the biggest reason for the poor performance is just android bloat. google honestly couldn't care less about performance on mid/low end devices.

Funny cause I see a ton of iPhone users that are always having to plugin for a charge while I can go all day and even with heavy usage will be at 40%.

Altima said,
Show me a "low end" device that runs just stock Android + Google apps that's not a Nexus. You wont find one. Its not Android that slows it down, its all the bloated UI and skins and apps that other makers put on it

Moto G and E?