I've noticed that when I close an app (exit it) it usually stays open in the background. An example for this would be Facebook or Google Goggles.
I don't want to have those apps drain my battery when I don't use them and I don't want to have to close them manually every time I exit them. What can I do?
Please help
Im doing the same thing too i would like to know if possible. I tried a taskmanager program but that just halts an app from coming back up again.
Sent from my Arc using XDA premium App
When any Activity is no longer the frontmost Activity (on screen), it's shut down by the OS. Any "background" Activities are simply stored in memory in case you want to go back to them. What you're seeing is essentially the history of the app; when you "open" it again it'll just reload the last saved state. At that point, the application is allowed to execute again.
The only applications that should continue running in the background are services.
The only drain you'll see are, as above, services running and the power necessary to keep the background Activities in memory; they're not actually executing.
Of course, there are ways to get around that, but most good citizens will respect Android's wishes when it comes to saving state and exiting when they're no longer frontmost.
NickWarner said:
When any Activity is no longer the frontmost Activity (on screen), it's shut down by the OS. Any "background" Activities are simply stored in memory in case you want to go back to them. What you're seeing is essentially the history of the app; when you "open" it again it'll just reload the last saved state. At that point, the application is allowed to execute again.
The only applications that should continue running in the background are services.
The only drain you'll see are, as above, services running and the power necessary to keep the background Activities in memory; they're not actually executing.
Of course, there are ways to get around that, but most good citizens will respect Android's wishes when it comes to saving state and exiting when they're no longer frontmost.
Click to expand...
Click to collapse
So when I click the "Force Stop" in the task manager on one of those applications that I've closed, what does it do? I don't think it erases them from the memory.
For instance, Facebook, when I click "Force Close" I'll still get notifications.
I'm seeing some of these applications in the Battery Usage.
Furthermore, Android will completely shut down apps in the background in order to recover the memory they're using, if it's needed elsewhere. That's really the only time that app management is necessary.
If you're simply seeing a lot of "background apps", rest assured they're not draining your battery.
If you are seeing an inordinate battery drain while you're on the home screen, you might have a service running behind the scenes that's consuming your CPU cycles.
Look for System Panel Lite in the Market; it will let you see the amount of CPU being devoted to each process. I'd bet that most of your background stuff is only eating RAM and not CPU. If there is something eating up a lot of CPU, you can investigate that particular app instead of simply force-killing everything in the background.
matanc1 said:
So when I click the "Force Stop" in the task manager on one of those applications that I've closed, what does it do? I don't think it erases them from the memory.
For instance, Facebook, when I click "Force Close" I'll still get notifications.
I'm seeing some of these applications in the Battery Usage.
Click to expand...
Click to collapse
There are two components to the Facebook app: the application itself and a service. When you "Force Close" the application, you're just stopping what you see onscreen. The service is still running, and a totally different animal than the application stuff we were discussing.
Edit: To clarify: You're seeing the package under Battery Usage, which combines the application ("Activity") and service usage to form an aggregate for "Facebook", not just one component.
Edit: (again) You're right above when you say that it removes them from memory. That, in fact, is ALL it's doing. It's removing the history/background Activities from memory. Unless that Activity is actually the frontmost Activity at that time you click "Force Close", it's not saving you any CPU time/battery usage.
Okay.
So you're saying there is no reason for me to "Force Close" every app after I've closed it?
And btw, when you say that they are in the background what does that mean?
I mean, the Active Applications widget is supposed to show me those that are running in the background right? So how come when I go to the home screen (using the back button) from an app like Facebook it won't show in the Active Applications widget but it will show Google Goggles?
matanc1 said:
Okay.
So you're saying there is no reason for me to "Force Close" every app after I've closed it?
And btw, when you say that they are in the background what does that mean?
I mean, the Active Applications widget is supposed to show me those that are running in the background right? So how come when I go to the home screen (using the back button) from an app like Facebook it won't show in the Active Applications widget but it will show Google Goggles?
Click to expand...
Click to collapse
To your first point, yes, that's exactly it. Android does this for you if it needs the memory. Otherwise, it leaves the history hanging around to make it appear the app is loading quickly the next time you open it (and it puts you right back where you left off). Note that we're ONLY talking about the user interface you see onscreen here, not any services.
Your second point requires a bit more explanation. My apologies if this gets either too basic or too in-depth; I'm not sure what your skill level is with Android. Each "window" or "screen" you see is actually a separate Activity, and is essentially self-contained. As you navigate through screens, the previous one saves what you were doing in memory and then exits. When you hit the Back button, Android simply grabs the last screen in memory and loads it back up. At that point, the application is running again. My references to "background" applications above is exactly this: screens you've left behind that are waiting for you to hit Back.
It's ultimately more complicated than that, but I think this will work for our needs.
matanc1 said:
Okay.
So you're saying there is no reason for me to "Force Close" every app after I've closed it?
And btw, when you say that they are in the background what does that mean?
I mean, the Active Applications widget is supposed to show me those that are running in the background right? So how come when I go to the home screen (using the back button) from an app like Facebook it won't show in the Active Applications widget but it will show Google Goggles?
Click to expand...
Click to collapse
To continue: Services are the real sticking point here. A service is an application that doesn't have a user interface (or screen). It's running all the time and not subject to the history/back button behavior we've been discussing. These guys are the ones you really need to be worried about, if anything. These are the ones that will run behind the scenes, consuming CPU and data (and, by extension, battery). Facebook is an excellent example: It's always checking to see if you have new messages, posts, etc. so that it can pop them up on the screen. GMail and SMS (and phone calls, even) all do the same thing using services. If the service is badly-written, it can be a real drain even when you're not using it.
You mentioned Google Goggles specifically above, and unfortunately, I'm not very familiar with how that particular app works. I suspect it's not subscribing to the good citizen philosophy and shutting down when you're done with it. It imagine it has to do with needing to perform searches or image comparisons in the background while you're off doing something else. This is technically allowed by Android, but it's frowned upon and suggested that you only do it when absolutely necessary.
Whew. All of that to say this:
Apps, as a general rule, don't consume resources when they're not on screen. They'll consume RAM, which does consume battery power, but it's really insignificant in the grand scheme of things.
Some apps will continue running after you "exit" to the home screen, but they should only do that as long as they have actual work to do. Once they're done, they should also shut down as above.
Services will consume resources all the time; they're constantly used for things like checking Facebook, Twitter, email, voicemail, etc.
okay, so again, just to summarize:
Force Closing an app just removes it from the System Memory (which makes them load faster when I open them). These apps use no additional battery life?
So I can feel free to not Force Close apps such as Camera (which I can do that to for some reason which I can't think of)?
Edit: And thank you very much Nick for the help and great responses.
matanc1 said:
okay, so again, just to summarize:
Force Closing an app just removes it from the System Memory (which makes them load faster when I open them). These apps use no additional battery life?
So I can feel free to not Force Close apps such as Camera (which I can do that to for some reason which I can't think of)?
Click to expand...
Click to collapse
You're correct. As a general rule, you don't have to force close any applications in Android. They will use some RAM and zero CPU and data, which equates to effectively zero battery.
Leaving the app in the background (in memory) loads the app faster the next time you open it, assuming Android hasn't closed it to reclaim that memory on its own. I've found that within a few minutes of heavy use (browsing the Internet, etc.), Android has shut down several of the apps in the background for me; it needed that memory to let me continue doing what I was doing.
You don't need to force close apps in the normal course of business. The only time you should force close an application is if it's behaving badly while on the screen (it's not responding to button presses or it's stuck in a tight loop or somesuch). Force closing it while it's in the background doesn't really gain you anything.
Okay, so just one last thing:
Do you have any suggestion to try and improve the battery life?
matanc1 said:
Okay, so just one last thing:
Do you have any suggestion to try and improve the battery life?
Click to expand...
Click to collapse
I have some general suggestions:
Don't sync accounts that you don't use. For example, if you don't use Facebook very often, don't have it set to sync up every hour.
Turn off WiFi, Bluetooth, and GPS unless you're actively using them. (A caveat: Google Maps uses WiFi in conjunction with GPS, so turn them both on while using Maps, even if you're not connected to WiFi.) Personally, I don't do this. I leave WiFi, Bluetooth, and GPS on all the time, but I know people who swear by this.
Keep your screen brightness as low as you can stand it. Again, I don't do this. I generally leave it on Auto-brightness.
Ultimately, though, you need to find that balance between usability and battery life. If you're always on Facebook and Twitter, sending SMS and surfing, well, there's not much you can do but keep an extra battery or charger nearby. If you're an office-worker that only uses their phone on break and at night, some of the above will probably help.
If you can give me an idea of a normal day's usage of your phone (and make/model/ROM version), I might be able to be a little more specific, or at least point you in the direction of your device's Q&A forum.
Well, I'm new to android and I've got a Samsung Galaxy S 2.
I don't really use the data connection (which is why it's always disabled unless I decide otherwise) and I turn on the Wifi only when I need it (which is often relative to 3G).
Normally I just use my phone for calls, SMSing and a bit of surfing.
About the google maps, I've noticed that it uses A LOT of battery and that it starts itself after I force close it, so I've closed the Maps service which seemed to fix the problem.
That's more or less it.
Not much syncing as well, I usually sync only when I need it.
Edit: I must say that I don't really understand what Backround Data is.
Is it that the Background Data lets the apps use data (like use facebook via wifi?) while the Auto Sync syncs automatically when I get a new email / notification? Does the background data have to do only with the my monthly data package and not with wifi ( i think that is the case ).
First off, you'll probably be better served to ask the guys in the Samsung Galaxy S2 Q&A Forum. They'll have a better idea of what the device's baseline is and what specific features you can turn off. Sometimes, as with the Samsung Fascinate, there are specific features that cause problems on the stock ROM, like Maps issuing bad WakeLocks. I know on my Fascinate before the first update, I had to toggle airplane mode every time I booted or Maps would eat the battery up in hours. Those guys in the device-specific forums will have a better handle on it, if there's anything of concern.
In general, though, it sounds like you're doing a pretty good job of keeping the device doing just what you want it to do. Android's sync framework is going to try to sync up all of your accounts essentially simultaneously whenever you turn on data, since it's probably been turned off for longer than their individual refresh intervals. You might want to turn off automatic sync on the service that you do use, so you can control those a little better when you turn on data to do something else.
Maps is a heavy data user and it makes use of GPS, which is going to consume quite a bit of power. The startup cost you're noticing is it trying to get a fix via the cell tower, GPS, and WiFi all at the same time, since the services have been off. If you use Maps often, you might be better served to leave data on (but, say, Edge only if you're GSM or 3G only if you're LTE/WiMax). This way, Maps can get a rough fix on your location at all times and not have to beat up the hardware to get a fix from scratch when you turn all the services on.
The Maps service is probably, to be anthropomorphic, freaking out all the time because it's trying to get some sort of fix while all the data services are off. Truth be told, I don't believe it was designed for that. Shutting down the service is a good way to go if you don't use it often.
You could try an application like Autorun Manager to control which services start up on boot. To make the most use of it, you need to be rooted, but in non-rooted form it will give you more control over what starts up automatically.
matanc1 said:
I must say that I don't really understand what Backround Data is.
Is it that the Background Data lets the apps use data (like use facebook via wifi?) while the Auto Sync syncs automatically when I get a new email / notification? Does the background data have to do only with the my monthly data package and not with wifi ( i think that is the case ).
Click to expand...
Click to collapse
Background Data is what services use behind the scenes (like syncing and such), but I believe it's an aggregate of all data, not just data on the cellular network. I'm looking through the docs right now to see if I can find a definite answer.
Edit: According to the docs, Background Data is data that is sent or retrieved when the application is not onscreen. This can be either in a service (as is usually the case) or when the app has to do some cleanup after you've moved to a different screen.
Thank you very much
I've noticed that I've got a few widgets that are using memory etc, ones that I don't use and never intend to.
They were preinstalled with the phone and I can't seem to uninstall them. Is there a way that I could without rooting my phone?
And on another subject, if I root my phone, is there a way to "unroot" it in case I'll need to send it to Samsung if there is a problem with it (since i've got a warranty and rooting voids it?)
matanc1 said:
Thank you very much
I've noticed that I've got a few widgets that are using memory etc, ones that I don't use and never intend to.
They were preinstalled with the phone and I can't seem to uninstall them. Is there a way that I could without rooting my phone?
And on another subject, if I root my phone, is there a way to "unroot" it in case I'll need to send it to Samsung if there is a problem with it (since i've got a warranty and rooting voids it?)
Click to expand...
Click to collapse
In theory, widgets don't consume resources unless they're on your home page. If they have services that collect their data, that's a different story. If you don't want them, you can just long-press on them and drag them to the trash can.
In conjunction with Autorun Manager above, you can remove the widget from your home page and stop the service from starting at boot. For example, I don't use Facebook (I know, lame), so I removed the widget and stopped the service. True, it's burning up a couple of megabytes of disk space, but that's insignificant next to the power of the Force, as it were.
Regarding uinstalling them, generally the answer is no. If you root your phone, you can manually remove them from the device, but that's sometimes overkill. Generally, they take up little enough room on disk that you won't be hurting for space.
In most cases, "unrooting" is as simple as flashing the stock ROM (usually available at the top of your device's development forum). Rooting your device generally doesn't make any changes to the device itself that can't be undone by flashing a stock ROM.
I've heard that rooting still leaves traces on the device though and that if they catch that it's been rooted I'm screwed. So you're saying that's not true?
Please dont 'quote' this as it VERY lengthy, just copy and paste the this first sentence.
I wanted to write up a definitive posting on task killers as I think they are way to often misused and misunderstood and I am getting quite tired of reposting this same information.
I use a task killer called TaskPanel XTRA (its free). BUT, I ONLY use it for killing tasks that are misbehaving (an app that has slowed down or nearly hung your phone or an app that is CLEARLY causing battery drain or sending copious data via your cellular connection). If an app continues to misbehave, switch to a different app that offers the same functionality, do NOT continue to use a task manager / task killer to kill an app continuously.
Task killers should NEVER be configured to automatically kill an app (as I will explain later in the post) and should NEVER be used to manually kill apps UNLESS it is a small emergency (as in major battery drain, copious cellular data, massive processor usage/memory usage preventing the user from using the phone normally).
Android is a VERY powerful operating system which gives YOU THE USER the control to manage your phone (hence the major reason I dont like the IPhone or Windows Phone), but with that control comes responsibility. As I will explain shortly, Android has many built-in features in place to help you manage your phone's precious memory. While there has been much nonsense one way or the other as to whether task killers should be used for anything other than a misbehaving app, I tend to listen to the creators of a product before I listen to some jackass who bases a decision on pure speculation or a 'feeling' he has. I can tell you that I have not used Task Panel in the last 4 months (with the exception of I believe Pandora which I used about a month ago and could not find a way to actually exit the app - guess what...this app is no longer on my phone - both because of privacy concerns that recently came up about Pandora AND I dont keep apps around that I cant manually exit the app cleanly).
For a VERY good write up (with a brief 'readers digest' summary at the bottom with plain English bullet points, since most of the article is taken directly from the Android developer FAQ and is very techy for non-programmers), have a gander thru this.
http://geekfor.me/faq/you-shouldnt-b...-with-android/
And for the FAQ they quote most of the above article from (but I do recommend you read the above FIRST as it will give you some context - much of the reasons are 'cherry picked' from different areas of the FAQ to help you understand why this is important and give you the information that is relevant to the discussion as to why task killers are not a good thing). All of the relevant information is in the page that will load up (in the rightmost panel / frame) so you dont need to click any links to read the relevant article. I am only providing this link as a reference to the original source material so you dont think I am just making this up - this is straight from the horses mouth so to speak (again, for most people, dont read this FAQ, read the one above first to get context and then if you feel you want to know more, read this link below).
http://developer.android.com/guide/t...damentals.html
Alright, enough about task killers, now to deal with how to manage those pesky apps that seem to always be running (even if you never started them) and how to keep them from starting up using a method that will NOT affect Android and how it manages your memory but will keep your phone in peek performance.
For managing the conditions when an app starts up, use an app called Autostarts, do NOT use a task killer to 'auto kill' tasks. Autostarts literally allows you to control the conditions of when an app starts.
Android has built in functionality for managing the memory footprint of various apps and will manage your phones memory quite nicely. Much of the functionality of the built in memory management came in Android 2.2 (also sometimes referred to as Froyo) and is really quite good 'if' you allow the phone to manage processes rather than just quickly killing everything.
There is a reason you can no longer just 'kill' system level processes, Google wants you to allow Android to 'learn' how to manage itself.
Android has a very powerful feature, the ability for app writers to start their app when certain conditions occur. The problem with this powerful feature is, often times, apps are bloated or poorly written, many times being started for any little thing your phone does (wifi on or off, Bluetooth on or off, location changes, screen on or off, USB connected, cellular connection, headphones connected, a cow fart, a bird poops, etc.). Even Google itself has been guilty of this, Google Maps (until recently) would be started in nearly 20 different conditions as a background process for very trivial things and was a major source of battery drain (it still is to some extent). This is where Autostarts comes in. Use Autostarts to control the conditions of when/if an app will start up automatically based on a certain condition.
Most ancillary apps (apps that are not integral to the core functioning of the phone - although it is probably more appropriate to refer to these as 'user apps', it isnt quite accurate because many 'system apps' (which in the technical description are apps that are installed with the rom) are not core apps either. For example, many roms come with Youtube pre-installed (meaning you do not manually have to go to the market and install them) which is not integral to the core functioning of the phone), these apps do NOT need to ever start under ANY condition for that app to function normally. The only considerations for an app starting itself would be the widget updating, the app has a scheduled event (for example, an alarm, a podcast client downloading podcasts at a certain time of day, Titanium backup performing a scheduled backup, etc.), or an app that has to be running in the background to perform a task when certain conditions arrive (for example, an app called Sanity needs to be available to run and monitor for incoming/outgoing phone calls so that it can start itself and perform its function during a phone call).
Using Autostarts, I have disabled nearly 80% of EVERY condition that all NON-system apps start under (I havent counted but for 70 apps, this is probably 55 apps or so that I disabled EVERYTHING these apps would start under). This includes Google Maps (yep, even Google is guilty of having an app needlessly running when it doesnt need to).
By taking control of your apps (in essence, disabling as many apps from 'auto starting' until YOU the user launch the app manually) and properly quitting an app when you can (within the app, find a way to click a 'quit' or 'exit' button to allow the app to remove itself from memory) rather than just allowing apps you launch to run in the background, you can save yourself massive amounts of battery life, limit cellular data usage, AND allow Android to properly manage itself.
Think of it like this, if I were trying to learn something but you (the user) kept doing it for me, Id never learn. And if you read the above linked article, you will begin to understand why there is more to this than just allowing Android to learn.
To give you an idea, using Autostarts to disable any non-system app that does not need to be running, if I am using the stock battery, I can run my phone for 2 days pretty easily if I simply turn off cellular data, Wifi and Bluetooth when I dont need it, maybe even stretch it to 3 days.
My ram usage is almost always around 50% (150 MB free) on a fresh reboot (around 2 minutes to allow the phone to stabilize) and it remains this way during the day because I exit apps when I am done using them, even tho I have around 80 apps installed, and I dont allow apps to just start themselves because they sensed a fart in my general direction.
For those of you that use a Windows PC, you can think of Autostarts as a proper 'msconfig'. Keeping your PC clean of apps when windows starts keeps your PC running much more smoothly. Autostarts takes this to the next level and keeps apps from ever starting in the first place rather than a task killer 'auto killing' a task, the app restarting, the app getting 'auto killed' again by the task killer, the app again restarting, etc. (a vicious cycle that both kills your battery because the phone has to crank up the cycles on the processor to both start and stop the app, the power used to write and clear the data written to both ram and 'perma' storage (if an app needs to store any data), and cellular data (if an app 'phones home' so to speak when it initially launches (which is both a cause for additional battery usage to send data and also adds to the amount of data your phone transmits over the cellular network, which is a problem given most cell plans have a monthly data cap).
Autostarts is fairly easy to use but does require root.
The app is $2 and here is a brief synopsis of how to use it:
When you initially launch the app, read any dialog messages that appear and click ok thru them. Then, wait for the app to finish loading (there is a progress bar at the top that will fill with yellow - on my phone it takes about 45 seconds to a minute to finish loading in).
Once it is loaded, you need to configure a few things BUT, you might want to just scroll thru the list of things currently on the screen. These are the 150+ conditions that apps currently installed on your phone are starting up under (dont click anything just yet, just browse the list if you are curious).
Right now, the app is configured to show a list categorized by conditions. This unfortunately is not very helpful. We need to change it to sort this list by apps rather than by conditions (so that we can literally disable EVERYTHING an app will automatically start under rather than scrolling thru every condition).
So, hit your menu button and the top left most icon in the menu that appears is an icon 'Group by application'. Hit that icon and magically, you are now seeing every app. You can now click an app and see all the conditions every app starts under. Neat.
But there is one more setting to change first in order to help keep you from doing something you should not.
(Optional but HIGHLY recommended!) Hit your menu button again (if you exited out of the menu already) and hit the upper right most icon, the 'View' button. Tick the topmost checkbox, 'Hide system apps' and hit the 'Ok' button. This will keep you from disabling anything that 'may' be critical to your phone operating.
Now, exit the menu (the 'back' button on the phone itself).
If you decided not to hide system apps, these will appear in YELLOW. It is probably not a good idea to mess with these unless you know what you are doing. Messing with these can cause a soft brick or make your phone unusable in certain conditions (for example, if you prevent the phone.apk app from ever starting, you will never be able to take phone calls).
Now, start scrolling thru the list (start at the top). If it is an app that does NOT need to run in the background, expand the app by selecting it and starting with the topmost condition that app starts under, tap each condition and in the menu that appears, select 'Disable'. Do this for ALL conditions for each app you want to manage. When you are done disabling the conditions, go to the next app and decide again whether that app needs to run in the background or not.
As a brief summary, to consider whether an app should be allowed to run in the background, ask yourself the following:
Does the app:
a. ...have a widget that you are actually using on your home screen that needs to update? For example, a media player or weather widget should NOT be disabled...
b. ...have a scheduled event such as checking the weather, downloading new podcasts, checking email, etc?
c. ...need to perform a certain task or provide some extra function(s) when a specific event happens (such as recording a phone call when it comes in, an eq when audio is playing, etc.)?
My recommendation is, if you answered YES to any of the above questions, leave all the conditions that app starts under alone (unless you know what you are doing, its best not to mess with it as I will explain in a moment).
If you answered NO to all the above, DISABLE ALL of the conditions that app starts under (again, DONT mess with system (yellow) apps and certainly dont disable every condition for these).
I recommend an all or nothing approach for each app is because if an app doesnt behave properly, it can become a major pain to continue to open Autostarts and try to track down a specific condition you disabled that is stopping / preventing that app from functioning the way you want it to.
Every time you update or install an app, if you remember, try to open autostarts and review the conditions the app starts under. Updated apps often times will add something new and if you have this app completely disabled, it may find a way to start itself again.
And, dont worry, you cant permanently screw anything up (unless you are messing with system apps - get the reason why I recommend not playing with system apps?). If an app stops functioning correctly, just re-enable the conditions that app starts under. Pretty easy.
Hopefully, this is complete enough, I will now just link to this post everytime I need to mention autostarts. I am getting quite tired of posting this same information .
Good information for people. Well done.
Sent from me to you using stuff
PARTIAL WAKELOCKS
PWLs are a different beast. These are almost all caused by an app (with a couple of notable exceptions). For that reason, I won't go in-depth on too many of them, as the solution is usually to delete the app causing them. There are a few notable ones, and a few apps that merit mention.
AudioOut_1, AudioOut_2: This is an evil leech of a wakelock that will drain you dry if given the chance. For being such a pain in the app, it's surprisingly easy to get rid of. This wakelock is created whenever the phone's speaker plays a sound. With 99% of sounds, it goes away almost instantly. With keypad sounds, however, it doesn't go away so quickly, and it will sit there draining your battery for as long as it goes unnoticed.
To fix: Open Settings, then select sound. Turn off keytone sounds, touch sounds, screen lock sounds and vibrate on screen tap. It'll take some getting used to, but the extra battery you'll coax out just by solving this ridiculously simple problem is more than worth it. See DoctorQMM's post (#5), linked at the end of this one, for info on additional causes of this wakelock and how to fix them.
ConnectivityService: This will appear whenever your phone is trying to connect to a mobile data network. Excessive wakelocking here suggests that your phone is having a hard time finding a network, and an even harder time staying on it.
To fix: Test out different radios and see if one's better in your area. I personally have to use UCLF5, as UCLF6 is a mess out where I live. If you're able to control your radio bands and you don't live in an LTE area, setting your phone to hunt for GSM/HSPA connections only can save you a little bit of juice here. Not much, but every drop counts, and if you're not using LTE anyway...
AlarmManager: This isn't a wakelock unto itself so much as it's a compilation of app alarms and the time they held the device awake for. Seeing the wakelock alone doesn't tell you much, but here's where one of those features of BBS that I said we'd be using comes in.
To fix: Open BBS. Tap the menu button, then "More", then "Raw Alarms". That will show you which apps are waking up your phone, and how often they're doing so. Google will have a ton of wake-ups, but they're mostly innocuous. We'll discuss some of Google's problem apps later. Email clients will also have a ton of alarms. If anything else looks out of whack, though, first check the app settings to see how often it's refreshing. If the app is set to refresh every hour but it's set off 400 alarms in the last 30 minutes, get rid of that sucker and email the dev. You can't eliminate this wakelock, and it's constantly my #1 PWL at this point, but you can minimize it.
A special note about this wakelock: You will get all kinds of crazy numbers out of this wakelock. You may see as high as 20m on a 1h30m stretch of battery. You will want to kill this wakelock, and kill it with fire. Don't, I say, don't do it! Look at your deep sleep time vs. time awake - screen on. Odds are, it's far less than the 20m that this wakelock is showing. You may have a time awake - screen on time of less than 3 minutes. What's the reason for the discrepancy? Well, it's well-known that there are wakelocks out there, PWLs especially, that will hold your device awake even if it's already been woken up: i.e., you'll have a PWL registering while the screen is on. Alarms are certainly among those that do so, as they are designed to wake your device up, so that's the first thing they'll try and do. I suspect the remainder of the discrepancy is caused by the way BBS reports. I suspect every alarm is tallied differently, so that if you have two alarms go off at the same time and last for 2 minutes each, BBS will register 4m of wakelock even though it was only held awake for 2m. Make sense? It doesn't for me either, but that's the best pair of explanations I've got, and the numbers seem to back it up.
MediaScannerService: This is a wakelock created by the system as it scans your device for music, movies, pictures, etc. Once in a while, it will randomly get hung up and hold the phone at 384 MHz for...well...until you notice and do something about it. Like AudioOut_1, this is a heavy-drain wakelock. Luckily, like AudioOut_1, it's almost always easy to fix. A note about this wakelock: it's been shown to be an occasional, but serious, problem on Jellybean ROMs. We're still not entirely sure why, let alone how to solve it permanently. That said, haloeight has been able to beat it into submission on his phone.
To fix: Reboot. Ninety-nine times or so out of a hundred, this solves the problem. If the problem persists, go to Settings -> Applications -> Running then tap on "Show cached processes". Find the Media process and stop it manually to kill the wakelock. That's a short-term fix, though, as a persistent wakelock from this process most likely means you have a corrupt media file somewhere on your phone--and there are a lot of sounds, movies and images on your phone. This is one of the few wakelocks that, if it's a regular problem, justifies considering a full wipe and clean reinstall. That's not because it's doing any kind of damage to your phone, but more because sifting through every single media file on your phone to find the culprit isn't really a practical solution. If you've got a persistent wakelock here on a JB ROM, try haloeight's approach above.
SyncLoopWakeLock: This is exactly what it sounds like; your phone is being held awake while apps sync. There are two possible causes for this: apps syncing (duh) and a bad data connection.
To fix: Open BBS. Tap the menu button, then "More", then "Raw Network Stats". This will show you which apps are using the most data, and help you narrow down possible culprits. Once you've done so, check those app settings and make sure they're not set to constantly push notifications, refresh every five minutes or anything dumb like that. If they're set correctly and still holding sync open that long, try downloading the Speed Test app off of the Play Store and test your phone's connection. If your connection is on the slow side, it's possible that the apps are struggling to sync because of your bad data connection. Try flashing different radios to see if that solves it. If the troublesome apps remain so after you've found a better radio, it's best to just delete or freeze them.
ActivityManager family: This is a harmless wakelock. The typical cause is not exiting out of apps fully before turning the screen off.
To fix: Don't sweat this one too much. If it's a big issue for you, make sure that you're exiting out of apps fully (i.e., either use the back button to exit the app or FC it in Task Manager) before turning the screen off. Credit to the XDA Wiki on this one, as this is one of the PWLs I wasn't able to figure out for myself simply because I hardly ever saw it. I use the back key to exit apps.
GTALK_ASYNC_CONN family: Despite its name, this wakelock doesn't seem to be directly related to Google Talk. How do I know? I haven't had Google Talk on this phone in over a month, but the wakelock still pops up from time to time. This wakelock also seems to be related to a poor wifi connection, so keep an eye on that as well. These wakelocks can be absolute destroyers of your battery if given the chance, and unfortunately, there's no known root cause for them, and no reliable way of eliminating them.
To fix: These wakelocks will often disappear within a minute or so of generating. If one becomes persistent, check your wifi/data connection and make sure it's good. If it persists, reboot into recovery and wipe cache and Dalvik ASAFP. That solves the problem temporarily, but it will reoccur. Thanks, Google.
NetworkLocationLocator: What a lovely name for such a lovely wakelock. It's a minor annoyance usually, nothing more. If this one is persistent, it's because you're in an area with crappy cell coverage and very few Google-mapped Wifi networks.
To fix: Why, exactly, are you leaving Network Location on all the time anyway?
NetworkLocationCallbackRunner: Thanks to clankfu and mw86 to pointing this one out, and a huge thanks to promiseofcake for finding the solution. This is the first wakelock published here that's specific to a phone other than the Skyrocket; it's an S3 issue. Hooray, we've gone global! NetworkLocationCallbackRunner is another wakelock caused by that most wonderful of apps, Google Maps. If you're still using it, seriously, why?
To fix: Upon turning on your phone, don't open Google Maps or anything else that utilizes Google location data. Or, you know, you could just uninstall Google Maps and use an alternative program...details below.
show keyguard: This is a new one for me. It had always been there, but since switching ROMs, it's really started to show up. Not in massive quantities, but enough to make me scratch my head. I've already established that setting your lockscreen to not show user info, weather or calendar data will significantly reduce this. I'll play around with adding those back in more, and having sliders on your default lockscreen won't do much damage either. Still, the more people who've goofed around with this one, the better, as it makes this entry all the more accurate.
To fix: I'm testing several possibilities now, but the one that's worked best so far is turning calendar, weather and user info off. It seems that having those on causes the lockscreen to wake the phone to refresh itself, which creates the wakelock. Judging by my recent experience, this seems to be a pretty big leech.
Chekin Service: Thanks to epapsiou for finding this one and confirming my guess on it. Getting tough to test without my Skyrocket being used as a phone anymore. This wakelock, while a Google Services process, seems to be caused by Facebook. That kind of confirms my theory that Facebook "borrows" Google services.
To fix: Uninstall Facebook and use an alternative app, or just access Facebook through your mobile browser of choice.
SCREEN_FROZEN: Uh oh.
To fix: If this is high on your list, you've got bigger problems than a wakelock.
PWL OFFENDING APPS
We're almost done, I promise!
Down here, I'm going to list off for you apps that will cause you severe PWL migraines, and what to do about them.
A note when uninstalling Google built-ins: Google built-ins are often system packages, and deleting them can have unpredictable results. I highly recommend freezing them in Titanium Backup for several days to see how the phone runs before uninstalling them through there as well. Deleting system processes is inherently risky, and I assume no responsibility for your own decisions.
Facebook: Any social networking app will want to sync as often as it can, but you can overrule that by setting notification intervals. Thing is, Facebook doesn't respect those intervals, and wakes up the device for data exchanges pretty constantly (even though your news feed may only update every hour or so when you want it to). This app is no better than bloat, and should be treated as such when you clean house.
Alternative App: Friendcaster and Fast are both great alternatives that let you set how often the app wakes up, but I've taken to just accessing m.facebook.com through the browser of my choice lately.
Gmail: A running theme here will be that if there's a non-Google equivalent to a Google app, you should probably kill the Google and download the alternative. Gmail is an alarm fiend, and one of the main offenders if you have an excessive SyncLoopWakeLock problem.
Alternative App: How many email clients are out there? I've had the best luck with the stock Email app, but K-9, Kaiten, MailDroid, even Enhanced Email and Touchdown for the power users are all great alternatives. Speaking of which...
Whatever email client you're using: Email clients will always be high up on the list of alarms, and that's by their nature. Keep an eye with raw network stats on how long they're connected for, and don't be afraid to experiment. I tried K-9, Kaiten and MailDroid before settling back on the stock Email app as the one that gave me the best balance of battery life and necessary features.
Alternative Apps: Download and try out different clients until you find the one that works for you. Nothing ventured, nothing gained, right?
Google Latitude: Latitude is a tracking service. As such, it tracks you. Beyond the creepiness aspect of that, it holds your phone awake pretty often while doing so. Kill it. Kill it with fire.
Alternative App: Personally, I'm not into the whole stalking thing, but I've heard that Glympse works quite well.
Google Maps: Colossal waste of space and battery. You can do better. An important note on Google Maps: this app will still wake your device up even after being frozen in Titanium Backup. I don't know how it happens, but it does. To truly solve the alarms from Google Maps, you have no choice but to uninstall it. Do so at your own risk.
Alternative Apps: I'm a fan of Waze for navigation and MapQuest for a Google Maps-ish browseable interface. OSMAnd is also a great alternative, but it uses a ton of internal memory because of its offline nature. If you really love Google Maps, reinstalling it from the Play Store as a user app can reduce those wakelocks dramatically.
Google Play Music & Movies: Updates itself constantly and wakelocks. Even if you freeze it, it still somehow manages to tell you that there's an update available. It's the Google zombie.
Alternative App: There are literally 100+ music and/or movie players out there. I'm sure you can find one that works for you. I'm a big fan of RocketPlayer for music, and I just use the stock video app more often than not.
JuiceDefender: What's that you say? JD sets off tons of alarms and holds the device awake for more time than I'd care to discuss, largely because of its data control settings. More harm than good, in my opinion.
Alternative Apps: JuiceDefender's main goal in life is to minimize the amount of time your device is held awake. Therefore, if you've just gone through all this to clear out wakelocks, do you really need another wakelock-prone app to do what you've already done?
Skype: Occasionally, after a call, Skype will wakelock. This is not designed to happen, and is more a glitch in the app than a forced sync. Force-stopping the app and clearing its cache have solved it for me on the rare occasion that I've seen the wakelock occur.
Alternative Apps: No idea. I don't personally consider this a "replace" situation.
World Weather Clock Widget: Do you have this on your phone? Get rid of it. I installed it as an alternative to SiMi Clock Widget, and while it certainly looks pretty, it ignored my "Update every 3 hours" and tried to update 275 times in that 3 hour window. This drove AlarmManager, GSYNC_ACONN, and NetworkStats off the deep end, and left me at 82% deep sleep with 6% of my battery gone in 3 hours. Kill it. Kill it with flaming nuclear waste.
Alternative Apps: I liked SiMi Clock and wanted to try something new, basically. I'm back to SiMi, but there are literally hundreds of clock widgets out there.
Google Search: If you use Google Now, forget trying to fix this one. GNow is a battery hog, and there's nothing you can do about it without crippling the feature. If you don't use GNow, you can use Greenify to hibernate Google Search and stop the persistent alarms and wakelocks it creates. Greenify is a method I hadn't used in the past, but I've grown to like it for hibernating rogue Google apps.
Alternative Apps: A quick look at the Play Store revealed Quick Search to be the second most-popular option after Google Search. I've run devices without Google Search in the past without issue, but it is usually a system app, so freezing instead of deleting would be a safer option.
That's the bulk of what I've learned from clearing out wakelocks. Remember how, early on, I specified that the search engine of your choice was the third tool? Simple fact is, I haven't installed every app on the planet, so I haven't seen every PWL out there. Because of the way my phone's set up, there are KWLs that I've never seen and never will. If you've got a pesky wakelock that won't go away and it's causing noticeable battery drain, Google (or Bing, or Ask.com, or whatever) is your friend. Good luck, happy hunting, and enjoy the extra battery life you'll get just by spending a few hours over the course of a few days tracking down and killing those wakelocks.
Also, be sure to check out Jrockttu's thread on fixing your battery, as there's tons of great information in there.
Additional in-thread references below. If any of these posts helped you out, please click the link down here and send them a thanks.
DoctorQMM covers com.google.android.apps.maps, an alternate fix for AudioOut_1 and using CPU Spy to help track down wakelocks.
kishke tracks down an alternative cause for the sdio family of wakelocks (including sdio_al) and details it for us here.
polarbearno shares their experience with the mmc_detect family of wakelocks.
haloeight gives us some great steps on how to get rid of the MediaScannerService wakelock on AOKP-based ROMs.
promiseofcake solves the S3-specific NetworkLocationCallbackRunner PWL.
Hi,
I am trying to use smartcharging feature on my crdroid ROM. During the charge, when I reach the preset charging value, it is working well as the phone stop charging. However, at this time, I can see with betterbatterystat that a Kernel Wakelock appears and prohibit the deep sleep mode to be enable. The name of this kernel is c440000.qcom,spmi:qcom,[email protected]:qcom,qpnp,smb5.
As a result, the deep sleep consume a lot of battery and the next morning, when I unplug my phone, I can see a huge battery drain around 2-4% per hours, which is not ideal for a smartcharging feature...
Do you know why this kernel wakelock appears? Is it possible to do something to avoid that?
Thanks
A Comprehensive (but not by any means definitive) Guide to Wakelocks
OP edit, January 12, 2016: To say that I'm proud of what this guide grew into would be an understatement, given that drawing it up was a weekend project for me using my old Galaxy S2 Skyrocket and either ICS or JB.
Take that last little bit into account here. It was done over three years ago on an S2-variant phone using Android 4.0 or 4.1. A lot of the specifics here are no longer going to be 100% correct, even if the principles remain true. If you're a rookie de-wakelocking your phone for the first time ever, please take what you see in the OPs with a grain of salt and ask questions in the thread before making any drastic system changes or mucking around in a terminal emulator.
Thanks for stopping by, and I hope you know a little bit more about your phone when you're done here than you did coming in!
-TJ
----
Wakelocks suck. If you're trying to maximize your battery life, you know this already. Some wakelocks are happy, friendly things, but many are silent leeches, sucking away your battery life while you remain blissfully unaware of what's happening. The goal of this guide is to list some of the more common wakelocks you'll encounter and how to wipe them off of your system. As you encounter ones not on this guide, let me know and I'll add them to the list. For some reference, I typically have light to moderate use of my phone. Before de-wakelocking, I was getting maybe 24 hours on one charge. After de-wakelocking, I was up to 36. Then I bought the Galaxy Nexus Extended battery, and on that battery's third cycle, I went two and a half days on a single charge. Impressive, right?
First off, you have to understand the difference between kernel wakelocks (KWL) and partial wakelocks (PWL). KWLs are wakelocks caused at the kernel or hardware level. Some of these are benign, and some of them are vampires. The only way to solve them is to change how your phone behaves. You'll see examples of that below.
PWLs are wakelocks caused by an app. The solution to these, more often than not, is to freeze (or, in the case of Google apps, uninstall) the offending app. Before you do so, and this is critical, go in via Settings -> Apps, force close the app, and wipe its cache and data. If you don't, you'll almost certainly cause yourself more headaches about 30 seconds after killing the app.
Second, you need to know the tools involved in wakelock hunting. The first is Better Battery Stats. Google "better battery stats XDA" and the dev's post will come up; they give this app away to XDA members. That said, if BBS helps you out, show the dev some love and buy the paid version. It's only $2.89, and the dev will have more than earned it from you by the time you've finished de-wakelocking yourself. The other tools you'll need are (hopefully) this guide, and, of course, the Internet search engine of your choice. I won't cover everything simply because I haven't seen it all.
Two final notes before the guide: do not go wakelock hunting right after installing a new ROM or clean-wipe reinstalling your current one. New ROMs cause the phone to go nuts for a little while, as things decache and little behind-the-scenes tweaks are made. Wait one full battery cycle (100% to 0%, which you're probably doing to calibrate after a clean ROM install anyway) before trying this, or you'll drive yourself nuts. Also, remember that solving one wakelock will often create another, especially early in this process. That's normal and to be expected. God does not hate you, your ROM of choice is not crap, your phone is not glitched, and a clean install while your current ROM is still settling in will only make things worse.
So, how do you track these wakelocks down with BBS? This is a really complicated procedure, so make sure you're with me. First, open BBS. Then, see the dropdown menu at the top that probably says "Other" right now? Tap it, and then you'll see "Kernel Wakelocks" and "Partial Wakelocks" below. That was obscenely difficult, right?
Something to note with BBS: it seems to have a weird "counting" bug. While testing a ROM with BBS, I finally began to question why my PWL time would be considerably higher than my true wakelock time. "True wakelock time," simply put, is time awake - time awake with screen on. If your phone is awake for 45 minutes and the screen is on for 40, you have five minutes of true wakelock time.
So why does BBS say that you have 90 minutes of PWLs when you only have a true wakelock time of 45 minutes? Well, I have two theories to account for that. One, BBS counts wakelocks independently, even if they occur at the same time. For example, if AlarmManager wakes your phone up for two minutes and AudioOut_1 wakes your phone up for 30 seconds during that same time, BBS will register 2m30s of PWLs even though the device was only held awake for 2m total. Now throw 30s of wlan_rx_wake (KWL) in there, and BBS is registering 3 minutes of wakelocks when there were only two. Throw in the notion that you had the screen on for 30 seconds during that time frame, and suddenly you're showing 3m of wakelocks when really there was only 90 seconds of true wakelock time to begin with. BBS has effectively doubled the reported wakelock time, and thrown off your stats. Now, throw in several dozen mini-wakelocks happening at once with the screen on, and you can easily see, say, 6h of PWLs on a 24h run, even if your true wakelock time is only 45m. It seems that Android's battery screen in settings reports this the same way, so my advice to you is to use the true wakelock time when cleaning up and attack KWLs and rogue apps. Some PWLs (AlarmManager) will always be high.
The second theory is that alarms are given a minimum reporting duration; i.e., five seconds per alarm for the sake of demonstration. Now, let's say you have Facebook, Twitter, Google+, LinkedIn, Gmail, Email, News & Weather and BBC News all set to sync every 30 minutes. They'll each set off an alarm at the same time, and suddenly your five seconds of alarm reporting time becomes 40 seconds every half hour. Now, let's say you have 35 alarms going off every half hour (not out of the realm of possibility with Google Services Framework). 35 x 5 = 175 seconds of time awake (in the five seconds per alarm scenario), which is now 350 seconds per hour of wakelocks reported, even if the true wakelock time was only ten seconds. Just something else to keep in mind when attacking PWLs.
One more note on BBS and how it handles KWLs: There is no such thing as a 0-KWL cycle, regardless of what the BBS reporting screen says. If BBS is showing 0 KWLs, tap the menu button, then "More", then "Raw Kernel Wakelocks" to see them. KWLs are required to boot the phone. In essence, the only phone that has 0 KWLs since it was last charged is a phone that hasn't been turned on since its last charge.
There are a couple of other features of BBS that we'll make extensive use of later, but there's one you need to know right now. Tap your phone's menu button to get the BBS menu up. Tap on "More". See the button that says "Set Custom Ref."? You'll need it--you'll need it a lot.
Also, anytime new information about a certain wakelock or wakelock family comes to light elsewhere in the thread, I'll be sharing that information here. If it helps you out, please visit the post that gave us that information and thank the poster. I'll link to each post twice, once in the wakelock description and once at the bottom of the OP, so no excuses about not being able to find it!
Last, but certainly not least: modifying your system in any way, including altering or deleting processes needed to resolve wakelocks, can have unpredictable results. Use caution and make backups of your apps and data, as well as nandroid backups, frequently while finding and eliminating wakelocks. Any modifications you make are done at your own risk, and I assume no responsibility for any damage you may do to your phone while cleaning out wakelocks.
With that said, we'll get started with the KWLs, as they're the trickiest to get rid of. Use the guide below to identify your wakelock, what is causing it, and how to get rid of it.
KWLs in post #2
PWLs in post #3
KERNEL WAKELOCKS
wlan_rx, wlan_rx_wake, wlan_wake: This is a wakelock caused by network traffic. The easy solution would be to just turn off Wifi, but be careful doing so! If an app goes to sync and it sees that Wifi is off, it will search for a mobile data connection (which causes the ConnectivityService wakelock). If it can't find a mobile data connection, it will wait and search again at its next sync interval and/or automatically sync when the phone wakes up. This wakelock can also, deceptively, be caused by the Wifi network itself as it refreshes connections or refreshes IPs.
To fix: This is a tricky little sucker to fix, as there are so many possible causes for it. Airplane mode is a safe bet--syncing apps seem to "respect" airplane mode, whereas if Wifi alone is turned off, they'll just try to find a way around. But then, of course, you lose your ability to talk on the phone. If you're particularly unlucky, your Wifi network itself will be the problem. Mine was--between my wife and I, we have four computers, an iPad, three Androids, a Wii, a PS3 and a Wifi-enabled TV hooked into our home network. The "background noise" caused by all of that would wake my phone up constantly. The solution? I happened to have a spare Wifi router laying around, so I hooked it up, set it on a different channel from my main router, and we now use that network for two of our three smartphones. Period. It's not the easiest fix ever, but wlan_rx_wake is almost completely eliminated (I'm looking now and have 4m45s of it 12h27m into a charge).
PowerManagerService: This is probably your #1 or #2 kernel wakelock, and you'd probably love to get rid of it at all costs, right? Hate to say it, but there's not much that can be done about this one. PowerManagerService is a KWL that serves as a "catch-all" for your PWLs. It's a placeholder, nothing more, nothing less. Don't spend much time worrying about it.
To fix: Reduce PWLs. See below.
deleted_wake_locks: Remember what I said above about force-stopping an app and deleting its cache and data before uninstalling it? This wakelock is why. It's the PowerManagerService for deleted apps. Once the app is gone, the wakelocks it caused suddenly become unknown to the system, so they get lumped in here. This number can also go up as the system "looks for" deleted apps and/or finds more wakelocks associated with them, but not dramatically.
To fix: Make sure to force close apps and wipe their cache and data before deleting. A reboot should eliminate the wakelock entirely. If it's still showing up, wipe phone cache and Dalvik.
sdio_al, sdio_dmux, etc.: This is an annoying wakelock, as there are two potential causes for it. One's easy, and one sucks. The easy one is that you've fallen victim to the charger wakelock. The easiest way to tell is to download Jrockttu's Skyrocket Charger Test App. If your charger shows up as AC Regular Charge, there's your problem. If it's AC Fast Charge or USB Normal Charge, your wakelock could be caused by your SD card. That can be an irritating fix, but the SD card version of this wakelock is typically small enough that it's not worth addressing. Also, a huge thanks to kishke for discovering a third cause for the sdio family of wakelocks: data. It seems that the sdio family is also the wlan wakelock family equivalent for cell data, and can be caused by apps searching for a data connection.
To fix: Check your charger and adjust if needed. To test the cell data possibility, make note of the time on the sdio wakelock, then turn cell data and Wifi off and walk away for an hour. Check it upon your return, and if you have minimal to no sdio wakelock, that was it. Try out some different radios for a better connection, or leave cell data off and stick with Wifi only. If it's the SD card, it's probably not a strong enough wakelock to be worth fixing, but if you want to fix it, you'll have to format your SD card. If formatting doesn't work, format it again, then wipe cache and Dalvik.
alarm_rtc: This is your phone's internal alarm scheduler, set to wake up your phone for sync, push, etc. Closely related to the AlarmManager PWL.
To fix: Check your apps and make sure they're only set to sync when you want them to, not for constant push or stupid-short intervals.
mmc0_detect, mmc1_detect, mmc2_detect: I'll be honest, I have no idea what causes these. Fortunately, they seem to be minimal, so I've never wasted much time worrying about them. polarbearno, however, has had a great deal of experience with this wakelock, and traced the cause of excessive activity here to a faulty SD card.
To fix: Unmount your SD card and pull it, then reboot. Might want to clear cache and Dalvik for good measure. If your problem was caused by a faulty external SD, this should solve it. If your problem was not caused by a faulty external SD, we're back to the original solution of "good question".
vbus_present: This wakelock exists as long as the phone is plugged into a wall charger. This wakelock can also persist if you use an Apple-compatible charger, which registers as "slow USB" charging and will cause the wakelock to hold after you'e unplugged.
To fix: Check your phone. Is there a cord plugged into it? If so, does that cord lead to a source of power? If so, unplug your phone (after it's fully charged, of course). Is the wakelock still there? Plug your phone into an OEM charger for a few seconds, then unplug it to kill the wakelock, then consider ditching that piece of fruit you're charging with. I try to use OEM Samsung chargers as much as possible, as they're designed for the phone (and to not cause persistent wakelocks). Jrockttu has an awesome charger test app, linked to in the OP of his outstanding "fix your battery life" thread.
suspend_backoff: This is a difficult one to nail down. Very difficult. To make a very long story short, this wakelock is caused when your phone wants to sleep, but a running process blocks it from doing so. Typically, this is going to be Wifi. Make sure your Wifi is set to stay awake when the phone sleeps. Otherwise, you risk the Wifi going out of its way to keep the phone from sleeping. This can also, unfortunately, be caused by apps, making it hard to pin down.
To fix: Do the Wifi thing, then reboot into recovery and wipe your caches. If it persists after that, you have no choice but to look at a dmesg output to pin it down. Go into a terminal emulator app and type the following commands, one per line:
su
dmesg >/mnt/sdcard/dmesg.txt
Next, transfer the .txt file onto your computer and open in WordPad or a similar program that automatically cuts line (i.e., no Notepad). Search the document looking for the word "event". You should find a lot of strings that look like this:
eventX-XXXX
Where the X's are all numbers. See those last four numbers after the dash? You should see them repeated again and again. Write them down, then go back into your terminal emulator. They are your process ID (PID). Once there, type:
ps
This will show you all processes that have run since your last boot. If you look at the second column from the left hand side of the page, and you should see a sequence of four numbers. These are listed sequentially, lowest to highest, as you come down the page. Scroll around until you find the sequence of four numbers that matches the one you wrote down. The line below those four numbers is the name of the process causing the wakelock. If it's instantly recognizable as an app, delete the app and see what happens. If it's a hardware thing that can easily be fixed, like Wifi, change your settings to accommodate it. If it's com.android.process.acore, I smell a wipe in your future. If you don't know what the process is, don't go screwing with things to find out. You can brick your phone in terminal emulators. Instead, write it down and Google it. Someone has already written about what this process is and what it does. If it's something you can easily fix, go for it. If it's a deeply-embedded system process, I'd just do a full wipe and clean reinstall.
Remember, terminal emulators can brick your phone if you're not careful. If you use them and something bad happens, or if you wreck your phone trying to fix this or any other wakelock, it is your problem, not mine.
There are a number of other, lesser KWLs that I'm not going to worry about here because you shouldn't worry about them either. You might occasionally see a battery cycle with very low (sub-1%) KWLs, but that's the exception and not at all the rule.
PWLs in post #3
The phone doesn't sleep when its charging, some android thing, that specific wakelock is called vbus_present.
kishke said:
The phone doesn't sleep when its charging, some android thing, that specific wakelock is called vbus_present.
Click to expand...
Click to collapse
That one's in there. It's the last wakelock under KWL.
I know it's there but you wrote: "This is a weird one. I never could quite figure out what causes it, but it seems like it's there as long as the phone's plugged it."
So I just want to clarify it so you could give it a straight explanation. Also you have a small typo there it=in.
It's a great guide!
T.J. Bender: Good topic… good write-up. I can’t agree with you more regarding the frustration level chasing down “greased-pig” wakelocks! The key is to have the right tool-set for analysis. At a minimum, make sure you have CPU Spy, BBS, and a utility which will show you what processes and services are active. Here’s my approach to identify wakelock problems. Again using CPU Spy to check time in Deep Sleep.. and using BBS to check Count of Alarms as well as time (minutes/seconds) of wakelocks:
1) open BBS and set a “Custom Reference” point (basically, this will reset the clock)
2) open CPU Spy and “Reset Timers”
3) turn screen off and let it sit for your predetermined time (i.e., 15min, 30min, 60min, etc)
4) when you reach the first predetermined time checkpoint, turn screen on and first check CPU Spy. How much time did the phone NOT sleep?
5) open BBS and check “Partial Wakelocks” against “Custom Ref Point”. Also check “Alarms” against “Custom Ref Point”.
6) do this every predetermined time (i.e., 15/30/60 min).. and write down results
What I found was very interesting. First I found "com.google.android.apps.maps" Partial Wakelocks were running about 80 times an hour (and preventing Deep Sleep): SOLUTION (thanks Bruno2123), un-check "Google Location Service” in "Location Services" in system setup.
Second culprit: AudioOut_1 : I also had unchecked all the keytone and touch sound options in setup, however, I was still getting a boat-load of PWL for AudioOut_1. I tracked it down (trial-and-error) to PowerAmp. Even though PowerAmp was not actively running, I had checkmarks (in PowerAmp Settings… Headset) in “Pause on Headset Disconnect” and “Resume on Headset Connect”.. which were preventing Deep Sleep. By un-checking these, it stopped the PowerAmp AudioOut_1 PWLs… and allowed Deep Sleep.
Third: this was a surprising find. Started to continue to see excessive AudioOut_1 PWL times; however, fewer counts (number of occurrences). Turns out, every time I open PlayStore, AudioOut_1 PWLs incremented… every time I played certain games (even with sound turned OFF in the game’s settings), AudioOut_1 PWLs incremented. However, these did not interfere with Deep Sleep.. these PWLs incremented when screen was on anyway!
Anyway, hope others find this approach useful and hopefully will help you identify PWL/ Alarm problems and find solutions.
kishke said:
I know it's there but you wrote: "This is a weird one. I never could quite figure out what causes it, but it seems like it's there as long as the phone's plugged it."
So I just want to clarify it so you could give it a straight explanation. Also you have a small typo there it=in.
It's a great guide!
Click to expand...
Click to collapse
Sarcasm is a fine art, mastered only by years of practice.
DoctorQMM said:
snip
Click to expand...
Click to collapse
I completely forgot to mention CPU Spy! Honestly, I did almost all of my hunting using the BBS "Other" timers, which show the percentage of time in deep sleep, awake, screen on, PWL and KWL. That's not to say CPU Spy isn't a valuable tool, because it is, but I had plenty of luck with BBS alone.
I kind of hinted at the benefits of leaving all Location Services off unless you need them. That said, I'm going to link this post from the OP, because you've kind of underscored the need to do so here.
And yeah, again, good catch on wakelock times. I was thrown for a loop the first time I had 94% deep sleep and 9.8% PWL until I realized that a lot of those PWLs were coming from apps that were running only when the screen was on.
This is an informative post. Thanks op
Sent from my SGH-I727 using xda premium
Good stuff...
Too bad your findings point to Google in a lot of ways as far as battery drain... maps, gmail, etc...
I don't mind Maps that much. It has been pretty accurate from me. When I ran BBS last time, it showed no problems on my phone as far as wakelocks, etc... I had more problems with BBS than anything.. WEIRD....
Every time I unplug my phone, it will ask for root permissions about 5-6 times before I get to my home screen even.... I just don't have time to be hitting allow that many times... (yes, remember is checked...)
Thanks for the posting! I subscribed and will check back here often!
onealvideo said:
Too bad your findings point to Google in a lot of ways as far as battery drain... maps, gmail, etc...
I don't mind Maps that much. It has been pretty accurate from me. When I ran BBS last time, it showed no problems on my phone as far as wakelocks, etc... I had more problems with BBS than anything.. WEIRD....
Every time I unplug my phone, it will ask for root permissions about 5-6 times before I get to my home screen even.... I just don't have time to be hitting allow that many times... (yes, remember is checked...)
Click to expand...
Click to collapse
Almost sounds like you've got a ROM issue. I've also read that switching from Superuser to SuperSU can solve a root permissions "loop" like that.
Unfortunately, yeah, a lot of the PWL headaches I've come across can ultimately be traced back to a Google app. That said, I set out looking to make a battery last as long as possible. If you get to a point where you're happy with your battery life, I'd stop there regardless of what apps are still on the phone. The more you change, the more you can potentially screw up.
Can someone post the link to xda bettery stats, I search for it and find nothing.
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
specter07 said:
Can someone post the link to xda bettery stats, I search for it and find nothing.
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Click to expand...
Click to collapse
Unfortunately you don't know how to search my friend.
http://bit.ly/NuHF7q
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
jyazzie110 said:
Unfortunately you don't know how to search my friend.
http://bit.ly/NuHF7q
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Click to expand...
Click to collapse
Seems you don't know how to google either. Where's the free better bettery stats for xda members? That just shows the link to the store for the paid one.
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
No at the bottom of the second post is dl link I just grabbed it
Sent from my SGH-I727 using Tapatalk 2
specter07 said:
Seems you don't know how to google either. Where's the free better bettery stats for xda members? That just shows the link to the store for the paid one.
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Click to expand...
Click to collapse
I know how to google....your the one who cant search or read! Haha
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
jyazzie110 said:
I know how to google....your the one who cant search or read! Haha
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Click to expand...
Click to collapse
Be nice
Sent from my SGH-I727 using Tapatalk 2
Illnevertell said:
Be nice
Sent from my SGH-I727 using Tapatalk 2
Click to expand...
Click to collapse
Wow, when he says it... u have issues lmao
Illnevertell said:
No at the bottom of the second post is dl link I just grabbed it
Sent from my SGH-I727 using Tapatalk 2
Click to expand...
Click to collapse
Thanks, I kept scrolling pass it since on my phone you can hardly even see the attachment on the broswer.
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Come on, guys, please keep this thread on topic.
Wanted to share some results with you. Screenshots below. No KWLs in 24 hours since being unplugged...not half bad. PWLs are within reason, especially considering that Alarm Manager is one of those PWLs that will hold even if your screen is on. The only thing that strikes me is Twitter alarming my phone 6 times, when it's set to never auto-refresh. Not a huge deal, but worth investigating.
70% battery 24 hours into a charge, screen-on time of 31m. Granted, I have barely used my phone today outside of sending a few texts, checking into XDA once and playing a few quick hands of Blackjack, but I'm still pretty stoked with this run.
**EDIT: Good thing I checked! Twitter had automatically updated earlier in the day, and when it did, it reset itself to sync every hour. Switched it back to never sync, and that should solve it.