Currently I am using Power Tutor to profile my battery usage. It is very nice for finding those rouge applications draining your battery. On the other hand it includes the useless LCD usage in the total Power Usage.
What are you guys using?
Battery Left works great. It's very accurate and also seems to show if the system is using all of the battery.
battery profiling
We've been working on this exact problem at little eye labs. We've built a performance analysis and debugging tool that does battery, memory, CPU and data profiling for android apps.
Its a commercial app, but in beta right now so free to download for now. littleeye.co
Some good ones are:
Betterbatterystats
SystemPanel
CPU Spy
I tend to use these together to develop a comprehensive view. First checking CPUspy to determine to what extent my device is sleeping properly, and if it is not, checking either SystemPanel to determine what if it's an app or a process, and then Betterbatterystats for more detail.
Hello everyone,
This is a question I've tried to search for an answer since quite some time but never found any so far.
It is happening on a stock HSPA+ Galaxy Nexus with JRO03C 4.1.1 Jelly Bean (bought from US play store).
Please note this behaviour was happening with Ice Cream Sandwich as well.
This happens with more than one app, but this time I'll focus on play.google.com/store/apps/details?id=com.merriamwebster
because it's free and I was able to reproduce this behaviour quickly.
Steps to reproduce:
-Open up Merriam Webster's app
-Write any word in the search box, than tap it in the drop down list that appears (you're brought to the word's dictionary page)
-Wait a few seconds then hit Android's home button on the bottom bar
Now check in Settings -> Apps -> Running:
You will see that the app is not on the running list but is in the cached processes list.
Now go to Developer Tools and enable "Show CPU usage" and hit home to show up the desktop.
You will see that com.merriam.webster is constantly using a small but not negligible percentage of cpu (its green bar is big enough to "highlight" the 'er' in .webster )
The only way to stop this is to stop the cached process in Settings -> Apps -> Running -> Show cached processes
I think the question now comes up by itself: "Aren't cached processes supposed not to use any CPU at all?"
Any info on the matter is appreciated.
Thanks
I think they do but its really minimal and probably doesn't affect performance much at all..
VoiD_Dweller said:
I think they do but its really minimal and probably doesn't affect performance much at all..
Click to expand...
Click to collapse
Such a constant CPU usage, even if small, will prevent CPU from going to its sleep state. No sleep state = battery drain.
More on the matter...
I've been able to investigate the issue a little further:
Installing the ad-free version of the same app ( play.google.com/store/apps/details?id=com.merriamwebster.premium ) and trying to reproduce the same steps does NOT show the problem. The app is now sitting in the background without chewing CPU time.
The only difference among the 2 apps should be the fact that the paid one lacks the piece of code to retrieve and show the ads (is that made with google ads?).
This would at least point us to a culprit (the ad code).
Still I don't understand why a process which is show as cached by the system is able to use CPU cycles. This should not be possible according to Android OS Documentation.
julioromano said:
Still I don't understand why a process which is show as cached by the system is able to use CPU cycles. This should not be possible according to Android OS Documentation.
Click to expand...
Click to collapse
The app isn't cached, but running, the time it consumes CPU cycles. It's just that it's only running a fraction of a second at a time, so you don't see it. In between, the app stops itself, rendering a "cached process" until the next time it wakes up, due to an intent restarting the app for a short while again.
kuisma said:
The app isn't cached, but running, the time it consumes CPU cycles. It's just that it's only running a fraction of a second at a time, so you don't see it. In between, the app stops itself, rendering a "cached process" until the next time it wakes up, due to an intent restarting the app for a short while again.
Click to expand...
Click to collapse
This might be a possible explanation, however installing the ad-free version of the app eliminates this odd behaviour.
Does this mean that some ad library code is buggy and can actually cause CPU hogging?
It makes no sense to wake up a process via intent every fraction of a second when it's UI (and hence the ads) is not displayed at all.
julioromano said:
This might be a possible explanation, however installing the ad-free version of the app eliminates this odd behaviour.
Does this mean that some ad library code is buggy and can actually cause CPU hogging?
It makes no sense to wake up a process via intent every fraction of a second when it's UI (and hence the ads) is not displayed at all.
Click to expand...
Click to collapse
Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?
Why the ad code behaves this way, you'll have to ask them about. There can me many different reasons. Checking availability of new ads, internal administration, collecting usage statistics ... just to mention a few.
kuisma said:
Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?
Here: developer.android.com/guide/components/processes-and-threads.html
Code:
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
This means to me that a cached process is an "Empty process".
Not having active components means no CPU usage.
I understand that from a UNIX point of view its process and pid will still be visible when typing "ps aux" in a console, but this process should not maintain a stable CPU usage around 5% (such as the one I wrote about in the first post of this thread) no matter what.
Click to expand...
Click to collapse
julioromano said:
kuisma said:
Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?
Click to expand...
Click to collapse
Here: developer.android.com/guide/components/processes-and-threads.html
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
Click to expand...
Click to collapse
This means to me that a cached process is an "Empty process".
Not having active components means no CPU usage.
I understand that from a UNIX point of view its process and pid will still be visible when typing "ps aux" in a console, but this process should not maintain a stable CPU usage around 5% (such as the one I wrote about in the first post of this thread) no matter what.
Click to expand...
Click to collapse
I agree that "empty process" here means "cached process", but I see no claim that this process must not contain a worker thread, and not consume CPU. "Empty" is in the context of Android app level, i.e. contains no activity or service (no context), not OS level.
But you can always test this quite easy. Create an app with an activity only starting a worker thread, then terminating. See if the worker thread still consumes CPU during its existence as a cached process. I believe it will. Of course, this is an artificial construct, not very useful since it doesn't have any context and can not interact with Android. Still, performing gc, updating singeltons etc, are still very possible tasks for such a worker thread.
Edit: But the ad software maintaining a 5% CPU usage as a background/cached process, I'm quite sure is due to low programming skills. But possible, yes indeed.
kuisma said:
But you can always test this quite easy. Create an app with an activity only starting a worker thread, then terminating. See if the worker thread still consumes CPU during its existence as a cached process. I believe it will. Of course, this is an artificial construct, not very useful since it doesn't have any context and can not interact with Android. Still, performing gc, updating singeltons etc, are still very possible tasks for such a worker thread.
Click to expand...
Click to collapse
I agree with your line of reasoning, sometime in the coming weeks I'll try to develop a test app and then I'll post my findings here.
What keeps me mumbling on this topic is the general approach to process management on Android:
Android has been thought from the ground up with mobile devices in mind: such devices must put their CPU in the highest possible of its sleep states for as much time as possible not only when the screen is off, but also during regular usage e.g. browsing a web page.
When you read an article on your browser app, you'll want only your display chewing up battery juice and your CPU as close to 0% as possible (unless you're scrolling or zooming, but let's say you're just reading a piece without touching the screen).
With this approach in mind it should be clear that the only processes that should be able to be put into execution by the OS's scheduler are those belonging to categories 1 to 4 ( developer.android.com/guide/components/processes-and-threads.html ).
From an OS perspective, cached processes (category 5) are useful to avoid wasting otherwise empty RAM so that recently used apps can be relaunched as quickly as possible.
But if cached processes are able to use CPU cycles then this is by no means useful to the OS (nor the device), because you'll have no longer needed processes causing your CPU to exit its much beloved sleep state.
In other words:
-Having processes sit in RAM without wasting CPU is ok because it speeds up the system when you reopen those apps and still, those processes will be purged when more RAM is needed (i.e. caching).
-Having processes sit in RAM wasting CPU is not ok because the benefits you gain from caching are offset by the increased battery drain.
julioromano said:
I agree with your line of reasoning, sometime in the coming weeks I'll try to develop a test app and then I'll post my findings here.
What keeps me mumbling on this topic is the general approach to process management on Android:
Android has been thought from the ground up with mobile devices in mind: such devices must put their CPU in the highest possible of its sleep states for as much time as possible not only when the screen is off, but also during regular usage e.g. browsing a web page.
When you read an article on your browser app, you'll want only your display chewing up battery juice and your CPU as close to 0% as possible (unless you're scrolling or zooming, but let's say you're just reading a piece without touching the screen).
With this approach in mind it should be clear that the only processes that should be able to be put into execution by the OS's scheduler are those belonging to categories 1 to 4 ( developer.android.com/guide/components/processes-and-threads.html ).
From an OS perspective, cached processes (category 5) are useful to avoid wasting otherwise empty RAM so that recently used apps can be relaunched as quickly as possible.
But if cached processes are able to use CPU cycles then this is by no means useful to the OS (nor the device), because you'll have no longer needed processes causing your CPU to exit its much beloved sleep state.
In other words:
-Having processes sit in RAM without wasting CPU is ok because it speeds up the system when you reopen those apps and still, those processes will be purged when more RAM is needed (i.e. caching).
-Having processes sit in RAM wasting CPU is not ok because the benefits you gain from caching are offset by the increased battery drain.
Click to expand...
Click to collapse
I agree with you. Mostly.
I don't really care if an app consumes CPU in the incarnation of a hidden (background) app, or as an cached app waking up by e.g. AlarmMamanger once in a while, or even as a cached app using a worker thread. If I need the app, and the app need the CPU time, so be it. But more often, those are badly written apps, and then I don't care about the details of their inner workings, I just uninstall them ...
Also, even processes sitting in RAM without consuming CPU can be a menace. Take my Xperia for example. In the last version of GB it started so much bloatware, that the limit of 15 hidden tasks was exceeded. But the tasks was sticky, i.e. required to restart in the case of termination. The result was that the phone constantly killed and restarted all the hidden tasks, draining the battery doing ... nothing! Only restarting all the bloatware, time after time after time..!
kuisma said:
I agree with you. Mostly.
I don't really care if an app consumes CPU in the incarnation of a hidden (background) app, or as an cached app waking up by e.g. AlarmMamanger once in a while, or even as a cached app using a worker thread. If I need the app, and the app need the CPU time, so be it. But more often, those are badly written apps, and then I don't care about the details of their inner workings, I just uninstall them ...
Also, even processes sitting in RAM without consuming CPU can be a menace. Take my Xperia for example. In the last version of GB it started so much bloatware, that the limit of 15 hidden tasks was exceeded. But the tasks was sticky, i.e. required to restart in the case of termination. The result was that the phone constantly killed and restarted all the hidden tasks, draining the battery doing ... nothing! Only restarting all the bloatware, time after time after time..!
Click to expand...
Click to collapse
Sure! Apps that do stuff useful to us should always be allowed to run
If an app registers for a intent or alarm and then goes to cached processes and we kill it (by removing it form the cached processes list via the settings app), it will be relaunched by the OS whenever an intent or alarm goes off.
Back to the case of our Ad-supported version of the Merriam Webster dictionary app:
When the app is cached (but still using around 5% of cpu) killing its cached process stops the strange behaviour: the app never gets relaunched by the OS (unless I tap again on its icon of course...)!
This means that it's not using CPU because it's been woken up via alarm or intents...
I still don't get it :laugh:
julioromano said:
Sure! Apps that do stuff useful to us should always be allowed to run
If an app registers for a intent or alarm and then goes to cached processes and we kill it (by removing it form the cached processes list via the settings app), it will be relaunched by the OS whenever an intent or alarm goes off.
Back to the case of our Ad-supported version of the Merriam Webster dictionary app:
When the app is cached (but still using around 5% of cpu) killing its cached process stops the strange behaviour: the app never gets relaunched by the OS (unless I tap again on its icon of course...)!
This means that it's not using CPU because it's been woken up via alarm or intents...
I still don't get it :laugh:
Click to expand...
Click to collapse
Ah, but this is another mechanism. When a service in Android initialise, it tells Android whatever it's sticky or not. Android may always terminate any app/service to preserve resources, but the sticky ones, must always be restarted once the starvation ends. This is why some app's can't be killed. They (the processes) get restarted even before an alarm or other intent wakes them (in the sticky case).
The last week or so since I got my HTC One Max, I have been slowly configuring it and setting it up to my tastes. On my previous phone, an HTC Rezound, I used an app called Clean Master to manage the phones ram, and Battery Doctor to extend its battery life. I tried an application called Battery Guru on my Max, but it actually drained the battery faster while the phone was not doing anything. After uninstalling it, my battery life seems to have shot upwards. I have not re-installed Battery Doctor. I have read the following things about these battery saver apps over the last few days:
1. Some say the applications are not needed and you should not use them, especially if they include a task manager. The logic was that Android was designed to have multiple apps in memory all the time, and closing them, then opening them again from scratch, uses up the battery.
2.Others have said just the opposite. They claim the applications greatly increase battery life. If you read the reviews on the Android Market about these two applications, that seems to be the case.
Both of these applications I have used get rave reviews from the many folks that have used them. Is the benefit they are seeing just imagined? Do the applications actually work? Is it also possible that they work for some and not others, since there are a lot of models of Android devices out there?
Most things that are ram "cleaners" are just giving you a slight point in time speed boost. Your ram will fill up again (as it should). Most so called battery doctors cripple your phone to extend battery life (think extreme power saver on the Max). What you want is something that blocks the applications that you do have running from performing activities in the background that you dont need at that moment ( think facebook looking for your location even when not using it just so it will know it faster when you open the app).
I use a combo of firewall to block most apps from using the internet (radio takes a lot of battery) and greenify which hibernates the app while keeping it in ram so it brings me into the app where I was before.
mikekoz said:
The last week or so since I got my HTC One Max, I have been slowly configuring it and setting it up to my tastes. On my previous phone, an HTC Rezound, I used an app called Clean Master to manage the phones ram, and Battery Doctor to extend its battery life. I tried an application called Battery Guru on my Max, but it actually drained the battery faster while the phone was not doing anything. After uninstalling it, my battery life seems to have shot upwards. I have not re-installed Battery Doctor. I have read the following things about these battery saver apps over the last few days:
1. Some say the applications are not needed and you should not use them, especially if they include a task manager. The logic was that Android was designed to have multiple apps in memory all the time, and closing them, then opening them again from scratch, uses up the battery.
2.Others have said just the opposite. They claim the applications greatly increase battery life. If you read the reviews on the Android Market about these two applications, that seems to be the case.
Both of these applications I have used get rave reviews from the many folks that have used them. Is the benefit they are seeing just imagined? Do the applications actually work? Is it also possible that they work for some and not others, since there are a lot of models of Android devices out there?
Click to expand...
Click to collapse
Try greenify
Sent from my HTC One max using xda app-developers app
Free ram is idle ram. Having a lot of ram usage isnt a bad thing... Don't know how many people think the opposite. Now if it gets too high then yea its an issue when opening new apps but this issue died with gingerbread in all reality. Some would argue task managers even died with froyo.
Sent from my HTC0P3P7 using xda app-developers app
Thanks everybody! I have installed Greenify, and removed Battery Doctor and Clean Sweep, and my phone is running great! I like it so much, I have put Greenify on my other Android tablets. No more battery saving apps or task managers for me!!
The trick is to properly manage the apps that you use.
The problem with task killers is that some apps that you kill will simply "respawn" themselves automatically in the background. Killing apps that do this just means your phone is constantly closing/opening the app again and again which is worse than not killing it in the first place. You will just have to experiment and check which apps respawn after killing them and avoid having the task killer auto-kill those apps, or uninstall those apps.
You also have battery saver apps that try to manage turning certain features on/off like WiFi, GPS and Blutooth. The most efficient way of managing this is to manually disable those features when you don't need them. Having an app do this for you means that app now has to be running all the time to manage those other features, which itself will ironically increase battery usage.
Avoiding as many apps as possible that need to constantly run in the background to perform it's function. These mostly include instant messenger apps or other apps that regularly check the internet for updates in the background. Either avoid them or if possible increase the delay between how often the app checks for updates/info. The Greenify app will allow you to "suspend/pause/freeze" specific apps when they are not currently on your screen. This keeps them from performing any activity in the background, and will help save battery if used on apps that would normally be doing tasks in the background. The downside is that if that app is suppose to be doing something while in the background, it won't be doing that anymore...like checking for updates, chat messages etc...
Keep screen brightness on automatic, so you don't waste power on a bright screen when in a darker environment.
These should be more than enough tips to help you better manage your battery.