The Android battery problem

Android Battery Drain

Whoever owns an Android device might wonder why it is that, most of the time, the device barrely makes it through the day, even with moderate usage.

After many experiments, I finally found the culprit: Google Play Services and its location feature.

Battery settings

There are 3 settings in the location mode. Let’s go over them:

Device onlythis setting is the most simple one (as long as the definition of simplicity does not take into account the math needed to derive a position from satellite beacons). It is the same system that a standalone GPS will use. Lock on to several satellites, download their ephemeris data and compute the position from that. The advantage is that there’s no network needed, just a clear view of the satellites. The disadvantages is that it can take 10-30 seconds and it doesn’t work so well indoors.

Battery saving: this mode will scan for a list of current WiFi accesspoints and the phone tower the phone is connected to then compare them with a (possibly cached) database from Google. Since Google knows the position from the data, it can give back a position. The advantage of this mode is that it’s very fast. The disadvantage is that it requires network coverage and communication with Google if the data is not cached.

High accuracy: this mode combines both previous modes. It scans for WiFi and phone towers, gets the data from Google but then, it uses the GPS to confirm that data, or, if Google had no match for it, it creates that new data for Google.

Wardriving for the masses

What happens when using High accuracy mode is akin to wardriving around with a laptop and a GPS and submitting the data to a central server (Google). This uses a lot of battery. Not only is the GPS often used but there’s plenty of network communication with Google and WiFi scanning. The device is also often woken up to perform a fix.

So which is the mode which uses the least battery power? It’s Device only. Just try it for a few days and you’ll see. The battery saving mode’s name is just plain bad naming. It will still perform scanning, communication with Google, and it won’t be very accurate in case there’s no access point around.

My Nexus 5 switched from not even a day of battery (high accuracy) to 3 days (device only).

Mail server fun


SMTP means Simple Mail Transfert Protocol.

As usual, when there’s the word simple somewhere in the name of a protocol or API, it’s a big warning sign.

So today I forgot to enable the LOGIN authentication mechanism in the SSL connection of my SMTP mail server. The following happens with Windows Live Mail when sending a mail:

  • it tries to authenticate but fails silently
  • it tries to then send the email directly (like a spammer would do)

This is a good example of over engineering which comes back to bite you hard. Trying to send an email directly (that is, connecting ot the SMTP server of the recipient) should work in theory. In practice, most servers will reject this because most dynamic connections end up in many anti spam lists. The funny thing is that Windows Live Mail is completely silent about this. It doesn’t even show a warning or anything and if I didn’t check my mail logs, I wouldn’t have figured out why a client’s email messages would frequently fail to reach their destination.

But of course the real reason is that email is a mess.

Using the proper data type

How to represent datatypes? For example in a JSON output.


Don’t do things like:


Seriously. Do you have any idea how difficult and computationally intensive this is to parse? And I’m not even talking about the variants with timezones like GMT, PST, Z, +- offsets and so on.

Instead, do the following:


This is the number of milliseconds since the beginning of times, that is 1st January 1970 with an UTC time zone. It’s easy to parse and there’s no room for interpretation. Every library understands that format.


Don’t do


This uses floats. Not only it can give rounding errors but it’s slower than integers. Instead do:


which is the number of milliseconds. Again easy to parse and every timer related library understands integer milliseconds, not necessarily floats.

Keep it simple and efficient.

MediaCodec: Android’s half-assed codec API

Android’s media playing capabilites have always been an annoying issue. Either you use the high level MediaPlayer API where most of the control is about supplying an URL to play, or you use JNI to write low level C code to do all the work (as of 2014-01-20, Android Studio doesn’t support the NDK). Since Android 4.1 (API 16), there’s a MediaCodec API which gives access to the decoding process using java code. The concept is as follows:

  • use MediaExtractor to demux the stream
  • decode the buffers using MediaCodec
  • render into the surface

This sounds great… until you start using it. Unfortunately, there are several shortcomings to that API:

  1. no control over the buffers. MediaCodec has both getInputBuffers() and getOutputBuffers() methods which give pointers to buffers whose sizes cannot be chosen. On a Nexus 5, the former is 4 and the later is 19. The only option when one needs bigger buffering would be to copy them around, which incurs a performance drop.
  2. MediaExtractor has no way to get access to the data-only portion of the stream. It’s basically designed to feed its output to MediaCodec. Feeding a stream composed of multiple parts (as in the case of HTTP Live Streaming) is impossible and you need your own custom parser.
  3. There’s no control over the rendering. You cannot touch the buffers but just render them into a surface.

It looks like this API was mostly designed for encoding media and the decoding was added as a bonus. It should work fine for decoding a file. For network sources you’ll probably run into streaming issues. Anything more advanced requires diving into the complexities of the NDK and OpenMAX API.

On a related note, this blog post has a good history of Android’s video decoding.

Also it seems that Google is still making improvements on that area so it might not stay half-assed forever.

New version of I’m sleeping

I'm sleeping

A new version of I’m sleeping has been released!
Changes in this version:

- automatically puts the phone in silent mode when set in the UI and the time is within the sleeping range
- likewise for unsilencing
- added a "call through" mode which allows repeated calls to reach you

Head over to Google Play to find it.

Crysis 2 QuickSave Mod

Crysis 2 is a great game. Outstanding graphics, fast dynamic rendering, good sound effects, advanced AI, etc.. Then someone at Crytek decided to remove quick saving at the last minute before releasing the game, making it annoying to play.

Which is why I did a quicksave mod. You can download the Crysis 2 quicksave mod.

To install, simply unpack the .zip into your Crysis 2\Mods folder.

Apple’s “inventions”

Tim Crook

So let’s see what Apple copied from Android invented with the iPhone 5:

  • Shared Photo Streams (Google+ Events Party Mode)
  • Panorama photo mode
  • taking photos while shooting a video
  • Points of Interests in Maps
  • Turn navigation
  • Satellite imagery in Maps
  • 3D Maps
  • changing camera angle in Maps with 2 fingers
  • iCloud tabs (Google Tabs Sync)
  • Sports team scores in Siri
  • Movies recommendations in Siri

And I’m not talking about 5 GHz WiFi, 16:9 screen aspect ratio, 1080p video support, and backside illuminated camera sensor which were available on the Galaxy Nexus which was released almost a year ago.

Now I suppose they can sue everyone else.

Apple’s Do Not Disturb feature already on Android

I was pretty amused to discover that Apple’s Do Not Disturb feature in iOS 6 is pretty close to my Android application I’m sleeping, which was available long before their version.

Android doesn’t offer such feature by default (but some ROMs do). At first, I was puzzled by that lack. I searched on Google Play but didn’t find anything that suited me, namely:

  • simple and intuitive user interface
  • intelligent design, with separate settings for week days and week ends
  • white list, allowing close friends or family to call you at all times
  • manual mode for naps or out-of-schedule sleeps without having to reconfigure everything

So I wrote it myself. Apple’s version is similar except it uses favorites instead of a white list. It also has a “go through” mode if the caller insists but doesn’t feature a manual mode (Apple still didn’t “invent” widgets).

Screenshots below:

Apple’s version
My version

Available on Google Play for free and without ads.

Android, WiFi and power consumption

Android is not very well documented when it comes to power consumption. Most user manuals tell you that, in order to save power, you have to turn off the features you don’t need. While these advice have their merits, they often involve a significant trade off. For this article, we’ll focus on wifi usage.

Wifi versus mobile data

When it comes to power usage, wifi behaves quite differently than 2G/3G mobile data. To keep things short, wifi is more power efficient when doing actual data transfer but less when staying on doing nothing, at least that’s the case with simple implementations. For example, my Sony Ericsson Xperia X10 Mini Pro (Android 2.1) will barely last a day when wifi is turned on and connected to an access point (AP) and there’s a reason for that:

contrary to what happens with mobile data, Android cannot sleep while a wifi link is active, even idle

Well. At least that statement was true until fairly recently.

Wifi powersaving mode

Since recent versions of Android, a power saving mode (PS-Poll) was implemented and many phones use it. It works in the following way and is only active when the screen of the mobile device is off:

  • the AP will keep packets for the phone buffered
  • the phone will periodically (typically every few seconds) poll the AP and asking if there are new packets
  • if there are, the AP will send them in a burst

It’s like if the phone was taking a dive, surfacing each few seconds to ask if there are packets. This decreases greatly power usage. The drawback is that it increases latency significantly and some APs don’t handle power save mode properly and simply disconnect the device. This is fine for “background data” usage though (syncing, email checking and so on).

Here’s how to test if your phone supports PS-Poll:

  • connect to your AP
  • on the phone, go to Settings / About phone / Status and look the IP address field
  • on a terminal on your computer, type:
  • ping -t <ip_address> (note: on Linux/Unix, drop the -t)

You should get some output like:

Reply from bytes=32 time=452ms TTL=64
Reply from bytes=32 time=200ms TTL=64
Reply from bytes=32 time=1512ms TTL=64
Reply from bytes=32 time=762ms TTL=64
Reply from bytes=32 time=1768ms TTL=64

Anything bigger than 1000ms indicates that PS-Poll is active. Turn on the screen and notice how the timing become smaller because then PS-Poll is disabled, bringing better latency.

Sleeping is the key

While PS-Poll helps a lot, it still doesn’t solve the main issue. Phones’ greatest power saving strategy is to put the processor (CPU) to sleep mode, basically the same that happens when you put your laptop to “sleep”. You close the lid, the machine stops but the memory content stays intact so that you can quickly wake up again to resume work.

And this is also what recent phones are able to do. For example the Samsung Galaxy S II and the Galaxy Nexus have a dedicated ARM Cortex-M3 chip (a full blown CPU) and dedicated memory in their wifi subsystem. This allows the phone to be put to sleep while the wifi link stays active.

Android 4.0 and default wifi sleep policy

This is probably why the default sleep policy in Android 4 (ICS) was changed from “sleep when screen turn off” to “never”. I was actually surprised to see the change and had to do some research to find out why this was done.

Now not all phones implement this but if your phone is recent, chances are it does.