'Sod's law' it used to be called. Or perhaps Microsoft really does respond that fast when AAWP writes. No, perhaps not! Either way, a mere 36 hours after my semi-scientific chart showing the battery drain problem that existed (at that time) in the Developer Preview of Windows Phone 8.1, Microsoft pushed out a big update to the OS, claiming battery life improvements. And it wasn't kidding - I've redone the appropriate drain test with the update and the difference is impressive.

From my initial article, three days ago (hey, a week's a long time in mobile!):

Let's clear up one thing first - "It's just got to get me through the day" means that a smartphone, under potentially heavy use, has to stay powered on from a possible start at 7am until bedtime (say 10pm). So 15 hours of 'on' time, logged into a cellular network, on wi-fi periodically, pulling down email often, usually with at least one social network syncing to a client, with periodic web browsing sessions, a couple of hours of audio of some kind (e.g. while commuting), perhaps up to an hour of gaming in odd moments through the day, half a dozen shortish phone calls, the capturing of a dozen photos, and other miscellaneous use. 

Hopefully the previous paragraph gets close to what you use a smartphone for - it's certainly pretty typical. And I'd venture that if any smartphone, whoever the manufacturer and whatever the OS, runs out of power before bedtime with the usage pattern above then there's a conceptual problem.

Happily, the second paragraph no longer applies to Windows Phone 8.1, as you'll see. 

Maybe Microsoft has been busy taking out debug code? Or maybe there was a rogue process or two which was running wild inside the kernel? Or perhaps a connectivity driver was fundamentally flawed? I guess we'll never know, but the upshot is a much more efficient OS, with idle/standby drain of the order of 2% an hour, far less than the 5% (or more) of the initial Developer Preview.

Here's the proof, with all the caveats and notes from the first article still in place(!), of course:

1. An OS's reporting of the state of a device's battery can be (notoriously) inaccurate. What's being attempted is a reading of the battery voltage, together with knowledge of how long it last was since the device was charged, added to a pretty huge 'fudge factor', ending up with a percentage which often amounts to little more than a guess. In other words, what gets reported as "50%" might actually be 60% or 40%. However, over a full charge/discharge cycle, at least the end points are consistent and we can still get a good idea of the relative, real world standby performance of each mobile OS here.
2. Percentages are obviously relative to a 0-100 scale, with the actual battery capacity varying a lot between devices. Which is a large off-putting factor, though I'm testing phones as-is, and real world users will have the same configurations...
3. Other variables include network conditions on each test day, plus Wi-fi strength variations as I moved from room to room in the house.
4. I only did one rough usage pass with each device - ideally, multiple devices of each type would be observed over multiple days, and so on. But there's only so much one man can do, etc(!)
5. In a couple of cases, where readings were missed or recorded out of time, I've interpolated slightly, in the interests of keeping the lines relatively smooth. This is, scientifically, a bit dubious, but then we're trying to guage the overall picture here and not look at minute details.
6. Also not taken into account was battery age - as capacity is lost, over time (many months/years), the rate at which charge will drain will seem faster, of course. But again, short of buying all new devices, there's not much that can be done to allow for this!

[Tested on Lumia 1020, Galaxy Note II, iPhones 4S and 5, Nokia 808 PureView]

The new line is the red one, of course, meausured over the last working day - and compare it to the blue line. Red is the new update to the Developer Preview and what a difference! Effectively, battery drain when the phone's idle is now less than 40% of what it was, meaning that there's up to 60% of the initial 100% charge available for doing 'foreground user stuff' during a 15 hour day, rather than 20% or so under the initial Developer Preview.

I said in the initial article that Microsoft had some serious work to do - and this seems to have been done. Before this update I was feeling rather depressed for the chances of a mobile OS, Windows Phone 8.1, making headway in a competitive marketplace when many users wouldn't even be able to get through the day. Something had to change - and it has.

It's true that Windows Phone's battery drain, in the chart above, ended up slightly worse than the all-conquering Android, but the latter was tested on a Galaxy Note II, which has a sizeable battery, I'd rate WP now at around the same level as Android overall, though some way behind iOS 7, at least in my testing.

With the Lumia 630 already shipping, will this update to the Developer Preview form the basis of the build of Windows Phone 8.1 that makes its way across Microsoft's build systems into device firmwares? I strongly suspect so. This update seems to have knocked the main issue with 8.1 (battery life) on the head - add in a number of other bug fixes and there's possibly not that much extra to do. 

To the core of Windows Phone 8.1, anyway. Obviously, there are manufacturer-specific applications and hooks to add (e.g. Lumia Cyan), though the situation's now a little more complicated by Microsoft now having completed its buyout of Nokia's device division. Will the Microsoft controlled Lumia-specific updates make their way into the wider Windows Phone codebase? Quite possibly - we've already seen bold moves like the roll out of licensing of the full HERE Drive+ system to all Windows Phones, for example.

Watch this space. And with a lot more optimism that was possible in the last month under Developer Preview battery blues....