By Izzy


2012-12-07 21:28:36 8 Comments

I guess most of you at least have heard about WakeLocks. Many of you will have experienced them already -- wether knowingly or not. Some may know how to deal with them in general -- but only few know how to deal with the "more complicated candidates".

For those who don't know, though above link leads to an explanation, a short summary: Apps may request a WAKE_LOCK to keep a device component from "sleeping", so they can perform a task even when the display is turned off. This is very useful in most cases (e.g. keeping the screen on while navigating, keeping WiFi active to stream music) -- but used in the wrong way, it causes your battery to be drained within short term (up to 25% per hour).

Most times it is easy to identify the source (usually a bad behaving app) -- I will show this in an answer below, as it might prove helpful to many users. But what to do if the app which requested the WakeLock exits without releasing it? The Android system will not take care of it. Sure, a reboot would solve the issue -- but it is not always an (desired) option.

So, from a users perspective (I'm not asking about development solutions, but how a user can handle things):

What can be done *by the user* to solve the issue and avoid further battery drain?

I prefer answers not involving root (so all users can benefit from it). However, "rooted solutions" are fully valid and welcome as well.

4 comments

@beeshyams 2016-06-02 11:57:23

A couple of ways that would help unrooted device users

  1. Seeing that @Uzumapps, one of the developers of the app has posted a solution using Wakelock Detector (WLD), I am surprised that he has not updated about using the app which can also be used without root called Wakelock Detector Light ! I discovered this searching for a solution for my new device (unrooted).

This is a recent development and hence posting this for unrooted device users. Tested as working on Moto X Play (Android 6.0.1)

Note: I couldn't get the second method working, would welcome editing solution in making it work for non savvy guys like me

@Izzy 2012-12-07 22:08:06

How can I tell I'm affected?

This is probably the first question to those not familiar with this topic. With Gingerbread (Android 2.3) and above, you've got a service aboard helping you to figure out: battery statistics. Though manufacturers tend to place it at different points, it's mostly found in Settings → About the phone → Battery or similar, and shows a list of the apps having used most of your battery. On top of that is a small graph. Tap that, and it brings you to a screen similar to this one:

battery stats
Screenshot of battery statistics on Android 2.3

I chose a screenshot from one of my devices which illustrates the issue. Looking at the lower two blue bars ("Aktiv" = Device was kept awake (active), "Bildschirm an" = "Screen on"), the right-most blue bar on "Aktiv" indicates a WakeLock: Device was kept busy despite the fact the screen was turned off. So by this we can be pretty sure we've got a WakeLock -- but we cannot tell who caused it.

If your device does not offer this screen (or the bars at the bottom: I just discovered e.g. the LG Optimus 4X running Android 4.0.3 has cut these bars off), you can find them e.g. using GSam Battery Monitor:

GSam Battery Monitor
Similar information from GSam Battery Monitor -- here the mentioned "blue bars" are yellow/orange

What caused the WakeLock?

Unfortunately, this question cannot be answered using pre-installed apps (except for, maybe, some Custom ROMs). But there are tools available that can. The best known candidate for this is BetterBatteryStats, and shows us the cause in its partial wakelocks section:

BetterBatteryStats BetterBatteryStats2
Screenshots from BetterBatteryStats

In the first example2 (taken from the app's playstore page), the event causing most of the WakeLocks was a desired one: We don't want the playback stopped while listening to music. So the second example3 (taken from a real case on one of my devices) might prove better: the topmost 3 events are caused by the very same app, which needed the WakeLock to keep the IMAP push service active.

For an alternative to BetterBatteryStats, check out the Wakelock Detector app mentioned in UzumApps' answer -- which seems easier to handle especially for non-techies:

Wakelock Detector: App details Wakelock Detector: Select processes
Wakelock Detector -- Click image to enlarge. (Source: Google Play)

What can be done?

If the case is as clear as in the second example in the previous section, the action is quite obvious -- at least in my case: I don't need to be informed immediately when a mail arrives; a delay of 30min is absolutely acceptable. So I went into the mail app, disabled IMAP Push (see also: Push Email), and instead switched to a 30min poll interval. WakeLocks did not entirely disappear, but dropped markably -- battery life improved noticably.

Then there's the case mentioned in the question itself: A bad behaving app not releasing its WakeLock. Confront the dev with your findings and ask for a fix. If he delivers: problem solved. If not: There's almost always an alternative app available.

What if it is the Android System itself?

Yeah, sometimes it looks like just that: 98% or more consumed by some Android service. Oh, if it's 98%, in most cases the candidate is named LocationManagerService. Bad guy spying at us? Not necessarily. In this special case, the listed "bad guy" is not even guilty -- at least not directly. Here it is another app requesting the current location too frequently. There's an excellent article on Setera.org about this: Pinpointing Android LocationManagerService battery drain. To give an abstract: It uses Android's dumpsys feature (requires root!) to dump a system state, and lets you investigate the listeners established for the LocationManagerService. A closer look at their configuration shows which are constantly "hammering" it for location info (some do so permanently, i.e. without a break). As the app's ID is listed along, and at another place in the dump even together with the apps technical name, you can still identify it and take appropriate actions.

And what about UFOs?

Unfortunately, there are such: Apps which registered a WakeLock -- and then exited without releasing it. What's left are *Unused F***ing Obsoletes* -- WakeLocks held for no use. So no way to simply bring the app to foreground and re-configure, or making it release its WakeLocks.

Here the only solution known to me is a reboot -- and I would like to have a better solution. Of course, if you know the guilty app, the steps concerning it are the same as above: inform the dev, get a fix -- or replace the app. But about getting rid of the current WakeLock? Maybe somebody else can provide a better alternative to the reboot?

Are there some recommended further readings?

Sure. One for now, I may add more later:

@t0mm13b 2012-12-07 22:09:31

Better education to developers to say... "Release wakelocks when you are done with them and clean up after yourself"?

@t0mm13b 2012-12-07 22:14:34

Upvote from me for your as-always-stunning answer!!! You're never bored of this are you? :D

@Izzy 2012-12-07 22:15:59

Sure -- but see my question: I'm explicitly NOT asking about the developer side, but from a users perspective. Maybe I need to make that more obvious ;)

@Izzy 2012-12-07 22:20:31

Bored? Can someone please explain what that is like? XD No, I always have something on my mind. If I feel it's good enough, I even ask about it here (see my profile: I don't ask often), though I might have a (partial) answer. The feedback here is always refreshing if the question is worth it :)

@t0mm13b 2012-12-07 22:25:10

If I have time this weekend, I will poke around under the hood to see if there's a mechanism to get the kernel to boot out orphaned wakelocks.... ;)

@Izzy 2012-12-07 22:33:25

Please do! And report your findings! I just had that described issue with the "orphaned" WakeLocks. Poking around for an hour, I didn't get further than seeing it was the LocationManagerService. Registered for updates all 0sec (sic!) was the Android Settings (=:-0). I exited it, stopped it, killed it at the command line... no way to get rid of the locks. WTF did Settings do there? A reboot solved it, of course -- but is this a WindowsPhone we have to reboot twice a day?

@Izzy 2014-07-08 09:04:38

@t0mm13b as that weekend has long passed by: did you find anything useful in your c64 session (peek and poke)?

@UzumApps 2013-03-08 09:30:05

Check out Wakelock Detector: XDA-Developers / Google Play:

Wakelock detector groups the wakelocks of app into one expandable view for better look. And it shows which apps are running. And there are kill uninstall info buttons in expanded view of app.

Wakelock Detector: App details Wakelock Detector: Select processes
Click image to enlarge. (Source: Google Play)

Disclosure: I am one of responsible developer for this app. Four more friends are with me working on this project as a hobby.

@Izzy 2013-03-08 10:23:08

Thank you! That's a valuable information indeed. Would you mind to add some more details to your answer, e.g. what makes it so special? I would add some screenshots then. Until that's done: Here's the Playstore link to the app...

@Izzy 2013-03-09 19:35:12

Thank you for the details! I merged them into your answer, I hope you don't mind :) Question of understanding: Say an app queries the location using an interval of "0 seconds". This would cause the LocationService to wakelock the device. Would Wake Lock Detector show the responsible app then as the real cause -- or the LocationService, as it's not a part of that apps package?

@UzumApps 2013-03-10 02:04:34

The answer for your question is 'no' because wakelock detector groups wakelocks that belong to the same app packagename. As Location Service belongs to android os, the solution would be checking User permissions of app

@Izzy 2013-03-10 02:24:40

Thanks a lot! I was hoping for an easy solution to the "What if it is the Android System itself?" part. Seems there isn't such a thing -- but if it's possible, it might be a good idea to integrate with WLD :)

@UzumApps 2013-03-10 03:51:41

Thank you for your opinion, I will consider it and work on that. WLD looks good!!! :)

@t0mm13b 2012-12-07 21:51:54

In short, this is a very good question but am afraid, it warrants more than just making the end-user aware!

Redesign the kernel to eliminate wake-locks and use a more thorough efficient way of managing the principle better thereby prolonging battery life.

Unfortunately, it has been accepted as a de-facto solution to enable "power management" despite it is not exactly efficient either! There was an extensive discussion about wakelocks (with Gregh Kroah Hartman - the Linux guru for drivers development - am googling for the exact linky), other sites such as LWN.net and another article explained on the same site here. This was the article Gregh Kroah Hartman referred to this blog, in which he appears to agree with the alternative solution proposed by Rafael J. Wysocki have documented a lot about the potential alternative. Am not sure if that is actually in place in the more modern kernel v3.x.x.

Badly designed apps can and often request wakelocks such as keeping the screen on, but in fact, in this scenario for keeping the screen on, there is in fact a more efficient way to do this:

getWindow().addFlags(LayoutParams.FLAG_KEEP_SCREEN_ON);

Whilst, striving to keep this clear of jargon etc for the end user, really the core of the issue boils down to the kernel code in how the wakelocks are managed.

Here is a brief summary on XDA on what is wakelocks for the uninitiated. By using BetterBatteryStats, one could see exactly which process is draining the battery, the wiki is hosted on github, and is available on the market here.

@Izzy 2012-12-07 22:12:02

Funny you point to the same XDA thread I mentioned. I agree with you that the system should take better care (e.g. by releasing WakeLocks requested by apps which are no longer running). And that developers should take better care in coding (by explicitly releasing them at the appropriate states of the LifeCycle). But that doesn't help us users know. I hope my answer gives some insight in what a user can do -- and that one of you "techies" can fill the gap left!

Related Questions

Sponsored Content

1 Answered Questions

Extraordinarily fast battery consumption

  • 2019-01-31 14:04:49
  • whiskeyo
  • 123 View
  • 0 Score
  • 1 Answer
  • Tags:   battery-life

1 Answered Questions

[SOLVED] Why would I automatically share usage and diagnostics data?

1 Answered Questions

[SOLVED] Battery capacity wear-down, and its relationship to charging practices

5 Answered Questions

[SOLVED] Why is Youtube draining the battery and what could we do?

2 Answered Questions

1 Answered Questions

0 Answered Questions

3 Answered Questions

1 Answered Questions

[SOLVED] Battery usage for keeping apps open

2 Answered Questions

Sponsored Content