battery drain – London Bus Pal Blog

Bad apps will wreck your battery

Following my previous post where I did some rudimentary experiments on other bus apps, I decided to leave my phone running for another couple of hours and see the effects on battery usage. This experiment involved opening and viewing specific stop and then simply leaving the app by pressing on the home button. I left the apps, but didn’t kill them. I did this for all the apps in the experiment and then reset all the counters.

And then I just left the phone for a couple of hours.

During the experiment – I left the phone off – in fact, I left the house and just left the phone on a desk. I used the phone for a couple of minutes, but made sure not to go anywhere near any of the bus apps.

The results were interest in that one app had woken up the phone 28 times and enabled the sensors for over 7 minutes during the 2 hours and 24 minutes the experiment was running for. It also transmitted 32.2KB of data during this time – not a significant amount, but that’s almost 50% of the amount that was transmitted by London Bus Pal when it was doing some real work.

Here is a breakdown of the results for this offending app (it is listed as a top app on the Google Play Store):

Duration:	2h 24m 51s
CPU Usage:	47s
Number of times waking device	28
GPS:	7m 27s
MPU6500 Acceleration Sensor	7m 26s
MPL Rotation Vector	7m 27s
Gravity Sensor	7m 27s
YAS537 Magnetic Sensor (compass)	7m 29s

I went back into the app to check why it would need to be on in the background. I noticed that Push Notifications were enabled and that I was automatically subscribed to get notifications for “special promos etc”. I turned off everything and disabled auto-refresh and also turned off analytics data sharing. After having to dismiss an ad (wow these are annoying!), I killed the app and restarted it (to make sure that all of the settings would load properly). I loaded a bus stop and pressed the home button and reset my battery usage monitor.

Time for some tea…

After tea, the results were so bad, that I thought I did something wrong and restarted the whole experiment. This time making sure that I take a couple of minutes before resetting the battery usage monitor to ensure that the app should be asleep.

Duration:	18m 26s
CPU Usage:	1m 25s
Number of times waking device:	3
GPS:	18m 26s
MPU6500 Acceleration Sensor:	31s
Gravity Sensor:	1m 1s
MPL Rotation Sensor:	1m 1s
YAS537 Magnetic Sensor (compass)	58s

The GPS timing was the reason I didn’t take the results from my first test, because I thought it was broken. It turns out the app is broken and holds onto the GPS when it really doesn’t have to.

Now I’m really frustrated

Do users even realise how this app is killing their battery? I looked through the reviews and this app gets a lot of praise (yes I’m slightly jealous) – but it seems that users don’t generally notice. I wouldn’t know without extensive testing which app is it that caused my battery to die so quickly – I usually blame the phone, not the apps. There are users who noticed, but they are far and few between:

Out of interest, this app was “App 2” on my previous list. It was exceptionally bad in terms of data usage and really bad on the battery in real usage testing too.

I’m going to stop writing now, because I don’t like focusing on other people’s work – I want my own to be the best it can possibly be. This was a useful exercise to make me believe in what I am doing, but it equally gets me down that unsuspecting users don’t realise why their phone batteries are draining so fast!

Kinder to your battery and data

London Bus Pal now has a dark mode which will help you to save some crucial battery life. This was just a quick experiment, rather than something users have been asking for. London Bus Pal has never been accused for draining battery – and this is for very good reason as I carefully think about every line of code I write to be as good for your phone’s battery as it could be.

This lead me to do some more experiments in terms of battery usage of London Bus Pal and other similar apps – some of the results shocked me to be honest.

The setup

The test I ran was fairly rudimentary. I took the top 8 apps which all return live bus times in London from the Google Play store. I made sure that I installed them and opened them all previously, wherever possible, I followed the same pattern:

If asked, don’t allow location to be tracked
If asked, select non-personalised ads – all apps were the free versions (had ads enabled)
Make sure I tap through the app to get rid of any “one-off” requests or app hints
All tests done in “light” / default mode

Location off means location off

I then had a small script which I manually executed, which involved searching for a stop, viewing a bus, viewing a stop, viewing another bus and so on. I executed the same steps on all the apps.

The first thing which grabbed my attention was the one app which was insisting that I enable my location before it would work. I persisted and kept saying no and eventually it gave in, and I managed to run through to the end of the experiment on that app. It turns out that it didn’t really require location to be enabled – it was just a lazy developer who didn’t want to work around this.

The next thing was the fact that despite location service being disabled and not really required (all the apps produced results in the end), three of the eight apps were still using the accelerometer. The is absolutely pointless and just wastes battery power.

The results

For the first round of tests, London Bus Pal was so low down the ranking of battery use by apps, that I almost thought my test was broken. But it was there, way down on the list. Even in light mode, it was by far, the kindest to my phone’s battery for the same test.

What about location on?

Next up was running the application with location services on. I decided I would do the simplest of tests and that is only allow the app to find my location and then close the app.

I ran through the test again and this time things were a bit less annoying (except for one app which insists on showing full screen ads all the time). This test was a bit more tricky to run because the first app run would possibly have the worst hit if it uses the GPS as efficiently as possible.

London Bus Pal kept coming back as the app, out of the eight, which uses the least amount of battery. In fact, three apps (London Bus Pal and two others) were clearly optimised for battery use whereas none of the others seemed to be, based on the numbers.

Of course, you’ll be asking, show us the numbers, and I have a list of numbers for you below – but it is worth pointing out, that the numbers are relative to each other in the same test, you cannot really compare them too much from one test to the next. It will give you an idea of the ranking and scale of usage of each application during both tests.

The most surprising thing for me was the worst offending app was engaging all of the sensors the whole time the app was open and even had some wakelocks going on (translated – this app is designed to suck the juice out of your battery).

Data usage

While I was doing my first test with location off and doing a set number of steps, I also tracked the data usage of each app. Again, the results truly surprised me – the app which was the worst on battery usage, was also the worst on the data usage (note, these are probably also related). What’s useful to note here, is that ad traffic was included in all of the data usage stats.

App	Battery drain (location off)	Battery drain (location on)	Data usage
App 1	74	79	428.8KB
App 2	81	100	2.3MB
App 3	81	44	818.8KB
App 4	74	53	617.3KB
App 5	100	58	776.5KB
App 6	21	21	87KB
App 7	16	37	87KB
London Bus Pal	14	21	93KB

Conclusion

The purpose of my experiment was to see whether I could officially claim that my app was battery and data optimised. It is something I care about deeply and carefully consider whenever I do anything. Based on the results, I think this is a resounding yes – I can definitely claim that my app has been built to optimise battery use.