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).
Related
hi i have only just got the hero and was wondering how to close apps properly. i have noticed that when you hold the home key for a while a window pops up showing some apps ...is this how you close them? or is simply pressing the home key shutting them .
The long press on home just brings up a list of apps that have been recently run. It's almost a task switcher, but not quite!
Many apps will exit if you "back" out of them - i.e. when in the app keep pressing back until you get back to the home screen. However, this isn't the case for all applications. Some may have an explicit exit or close button, whereas others may have nothing at all.
However, Android is pretty good at managing its own applications, and will kill/exit them as necessary. In my experience, there's little to be gained from explicitly killing applications using a task killer, but some people swear by it.
Regards,
Dave
foxmeister said:
The long press on home just brings up a list of apps that have been recently run. It's almost a task switcher, but not quite!
Many apps will exit if you "back" out of them - i.e. when in the app keep pressing back until you get back to the home screen. However, this isn't the case for all applications. Some may have an explicit exit or close button, whereas others may have nothing at all.
However, Android is pretty good at managing its own applications, and will kill/exit them as necessary. In my experience, there's little to be gained from explicitly killing applications using a task killer, but some people swear by it.
Regards,
Dave
Click to expand...
Click to collapse
Most Task Killers free up memory thats used by background apps.
so basicly back out of the app and let android do the rest of the worring. thanks for advise
risterdid said:
Most Task Killers free up memory thats used by background apps.
Click to expand...
Click to collapse
Yes, but the point is that Android itself will start killing applications if it starts to run low on resources. (see http://developer.android.com/guide/topics/fundamentals.html)
Regards,
Dave
I'll attempt to sum it up once and for all, to try and set the record straight.
In Android's virtual machine, there is no functional differentiation between "closing" an app and "switching away from" an app. They are the same (the exception is things like music players which need to keep playing after you switch away from them, but even then only the 'service' part needs to keep running).
Whenever you switch away from an app, its current state is remembered so that even if it is effectively "killed" it can be returned to in just that state next time it's opened. Then Android either kills the process or it keeps it open, killing it when it needs the memory. You won't notice any difference between either scenario, except maybe that an app loads a little bit faster if it was kept in memory. At any rate, "closed" apps do not "run", and they do not take RAM or CPU cycles from other apps.
In terms of process/memory management, Android's VM has more in common with a web browser than a desktop OS - sure it can remember your state when you switch apps (like switching tabs, going back/forward/home in a browser) but whether behind the scenes it loads it all into and out of memory when you switch back and forth, or it all stays in memory is irrelevant to the user. Nobody worries that a long forum page on another tab or in their back button history is occupying 80 megs in the background or not, the browser takes care of loading/unloading it from RAM as needed, and that's just like how Android's VM works when switching between various pages of various apps.
Once you understand this you understand that all these 'task killer' apps are really unnecessary - all they'll do is make it slower to restart an app once closed. They don't reclaim RAM that was previously unavailable to other apps.
To cut a long story short, pressing "home" is a great way to close an app, whether you want to return to it later or not.
MercuryStar said:
Nobody worries that a long forum page on another tab or in their back button history is occupying 80 megs in the background or not, the browser takes care of loading/unloading it from RAM as needed, and that's just like how Android's VM works when switching between various pages of various apps.
Click to expand...
Click to collapse
that is not true for me, my firefox can eat a lot of resources as long as it is open. and i can see a performance difference when having a lot of apps open on my hero. not that it would be a problem, but you can see the menus scrolling more "fluid" after killing all bg apps, for example.
kendong2 said:
you can see the menus scrolling more "fluid" after killing all bg apps, for example.
Click to expand...
Click to collapse
I would wager that's the placebo effect. It feels faster because you believe it should. If you understand how the OS works you realise that apps you've switched away from do nothing to slow down or take memory from any other app (see my exception above about apps that launch background services such as music player).
kendong2 said:
that is not true for me, my firefox can eat a lot of resources as long as it is open. and i can see a performance difference when having a lot of apps open on my hero. not that it would be a problem, but you can see the menus scrolling more "fluid" after killing all bg apps, for example.
Click to expand...
Click to collapse
I do notice this too. There is a general 'sluggishness' with my Hero when there are lots of app sleeping/running/hibernating/whatever in the background. As soon as I kill off a few unwanted ones, all the menus scroll faster and home screens change quicker.
And this is not the placebo effect either. The menu's DO scroll more fluidly after I have killed a few apps, regardless of how you describe the RAM management...
Micksta said:
And this is not the placebo effect either. The menu's DO scroll more fluidly after I have killed a few apps, regardless of how you describe the RAM management...
Click to expand...
Click to collapse
exactly, you can tell easily if it is one motion or looks like it is "skipping frames". even it is only because it takes the device some cpu cycles to kill other apps, it does make a difference. like i said a rather cosmetic one, since it doesn't really effect the general usage. nevertheless i like to know what is running and what's not, and so far im running good with advanced task manager free.
WOW i didnt expect a massive response for my question but i thank you all for your responses
MercuryStar said:
I would wager that's the placebo effect. It feels faster because you believe it should. If you understand how the OS works you realise that apps you've switched away from do nothing to slow down or take memory from any other app (see my exception above about apps that launch background services such as music player).
Click to expand...
Click to collapse
that's not true, my phone gets so sluggish sometimes that i can't answer a phone call, the phone doesn't register that i press the answer button. and when that happends i usually have like 20 mb of free ram.
Daniehabazin said:
that's not true, my phone gets so sluggish sometimes that i can't answer a phone call, the phone doesn't register that i press the answer button. and when that happends i usually have like 20 mb of free ram.
Click to expand...
Click to collapse
Just as a matter of interest, do you use swapper or AppsToSD?
My phone never gets into the situation you've described, but even though I do have the full version of TasKiller, I almost never use it, and I don't see a need at present to use AppsToSD.
In addition, I'd imagine that having a swap partition would cause an issue with Androids own memory management, since I guess it can't distinguish between real and "virtual" memory. So where a "non-swap" device would start killing processes, a "swap" device would just continue on regardless because it thinks it still has physical memory available.
Regards,
Dave
Yesterday I downloaded "Advanced Task Killer Free"... anyone who has experiences with this? Is is better than just "Task Killer" or is it just an updated version of "Task Killer" ?
thanks!
have been using atk free for a while (lol 2 weeks since i got the hero) now, i really like it. its advantage over all other task managers IMHO: it has an ignore list, things you ignore are not shown in the running tasks list. in the list you have check boxes, where you can select the tasks that will be killed, and this list is remembered. for example "htc sense" is on my ignore list, but "music" is only checked, so i can uncheck it when i don't want to kill it while listening to music. next time i want to kill music i just have to tap the checkbox, no dealing with the ignore list here...
Daniehabazin said:
that's not true, my phone gets so sluggish sometimes that i can't answer a phone call, the phone doesn't register that i press the answer button. and when that happends i usually have like 20 mb of free ram.
Click to expand...
Click to collapse
I get this problem a lot, and in answer to fox meister, I don't have AppsToSD.
I don't know if the problem is RAM or CPU related, but the CPU often jumps to 100% when things are really slow.
Is the issue likely to be background apps, or widgets even?
Sausageman said:
I get this problem a lot, and in answer to fox meister, I don't have AppsToSD.
I don't know if the problem is RAM or CPU related, but the CPU often jumps to 100% when things are really slow.
Is the issue likely to be background apps, or widgets even?
Click to expand...
Click to collapse
Same for me with the processor.
When i reboot my phone i usually have 90 mb of free ram, after starting a few applications, like browser and phonebook, it plummets down to 20 mb.
I do have some extra applications that starts as services, like systray monitor and 3g watchdog.
when i open atk after a fresh reboot i see that some applications that i don't even use is started, like footprints, settings and calendar, even my webrowser is started, whats up with that, can it be disabled?
I think the issue is that we have some applications that autostart withous us using them, and also programs that we download that autostarts as services and maybe having memory leaks...
I came to chime in with my experiences of the CDMA hero and sluggishness.
I watch memory like a hawk (thanks Mogul) and I too have around 80-90mb free ram on start, but it can get down to around 30 rather quickly. Once it gets down here, I notice that screen transitions and random lag occurs in apps. If I go into Advanced Task Killer and kill many of the stragglers, my menus are as smooth as can be.
It is most certainly NOT a placebo effect.
One thing I really like about Advanced Task Killer (pay version) is that it has the "Auto End" feature, where it will kill all apps not chosen to be excluded at the interval that you choose. For example, I have determined the system applications that need to be on all the time, and I've excluded those. Every hour, ATK kills everything else. For the most part, my Hero hovers around 70MB now at all times, although it can get down there to around 30-40MB if I'm right around the 1 hour mark.
That feature alone makes it much better than Taskiller IMO. Totally worth 99 cents
This definition would imply that android works exactly like the iphone osx? I mean saving "screenshots" of the last state of an app. But NOT having real multitasking?
Because it's not possible to have multitasking and at the same time "inactive" background apps everytime you hit the home button...
MercuryStar said:
I'll attempt to sum it up once and for all, to try and set the record straight.
In Android's virtual machine, there is no functional differentiation between "closing" an app and "switching away from" an app. They are the same (the exception is things like music players which need to keep playing after you switch away from them, but even then only the 'service' part needs to keep running).
Whenever you switch away from an app, its current state is remembered so that even if it is effectively "killed" it can be returned to in just that state next time it's opened. Then Android either kills the process or it keeps it open, killing it when it needs the memory. You won't notice any difference between either scenario, except maybe that an app loads a little bit faster if it was kept in memory. At any rate, "closed" apps do not "run", and they do not take RAM or CPU cycles from other apps.
In terms of process/memory management, Android's VM has more in common with a web browser than a desktop OS - sure it can remember your state when you switch apps (like switching tabs, going back/forward/home in a browser) but whether behind the scenes it loads it all into and out of memory when you switch back and forth, or it all stays in memory is irrelevant to the user. Nobody worries that a long forum page on another tab or in their back button history is occupying 80 megs in the background or not, the browser takes care of loading/unloading it from RAM as needed, and that's just like how Android's VM works when switching between various pages of various apps.
Once you understand this you understand that all these 'task killer' apps are really unnecessary - all they'll do is make it slower to restart an app once closed. They don't reclaim RAM that was previously unavailable to other apps.
To cut a long story short, pressing "home" is a great way to close an app, whether you want to return to it later or not.
Click to expand...
Click to collapse
Shahpur.Azizpour said:
This definition would imply that android works exactly like the iphone osx? I mean saving "screenshots" of the last state of an app. But NOT having real multitasking?
Because it's not possible to have multitasking and at the same time "inactive" background apps everytime you hit the home button...
Click to expand...
Click to collapse
No, you've not understood the explanation.
The iPhone will always* terminate an application that isn't on its list of "approved" multi-tasking apps once it isn't active any more (i.e. you've switched tasks).
Android will try to keep whatever it can in memory, but eventually will start killing processes in order to keep the system running.
So, if you're on an iPhone listening to something on Spotify and you want to browse something on the web, the iPhone will "kill" Spotify when you switch to the web browser. On Android this won't occur except in the most critical of resource low situations, but then again, I'd imagine other apps would get killed before Spotify.
Read this article, specifically the section from "Component Lifecycles" onwards specifically "Activity Lifecycle", "Saving activity state" and "Processes and lifecycles".
Regards,
Dave
* Unless it has been jailbroken!
So I installed automatic task killer just to see if I noticed a difference. So it says it is freeing memory when I engage it. Great, more memory available seems to allow the phone to run smoother/quicker. However, give the phone a couple of hours and gradually the available memory on the phone lowers and lowers until it goes below 100mb and beyond. Engaging automatic task killer frees some memory but does not bring it back to its startup memory of over 150mb. I of course do notice that my phone begins to get "laggy" once I start to dip below 100mb. I guess my question is, "where is all my memory going?". Im not too concerned about using automatic task killer. I just want to know where my memory is going cause this is most certainly the cause of a laggy phone. A quick reboot and my phone is back to its highest point of 158mb and running nice and smooth. What gives? Also where are the other 150mb or so that the phone has available according to specs? If its all dedicated to the the android OS than why is the phone so laggy by the end of day? Sorry if its too many questions but im just looking for some insight into the memory management of the x10 and android. Maybe a 1.6 issue?
It's nothing to worry about. Unused memory is useless memory. It's *nix based so the memory in use isn't going to drain the battery or slow the system down. It manages everything by itself. By repeatedly killing tasks you're actually stressing things unnecessarily.
The only time you should kill all the tasks is when you know something is being problematic, before locking your phone when you have a suspicious app that doesn't always stop automatically, etc. Otherwise the Android OS takes care of this by itself.
I stopped using task killers months ago (except for when I lock my phone because of what I mentioned above.. programs keeping it from going into a deep sleep) and my battery easily lasts two days with periods of very heavy usage.
I only use a task killer to kill certain things when they cause problems, which is not often. Things I use often I leave in memory, they only get reloaded anyway.
Tbh if things are getting laggy that quickly you probably have an app that is misbehaving.
Sent from my X10i using XDA App
Thanks for the quick replies. Automatic task killer has already been uninstalled. Looking forward to the update with hopes that it helps with lag issues
Sent from my X10a using XDA App
Well that still doesn't solve the problem of badly written apps draining the battery. Often I've found that without a task killer my battery life has improved, but on occasion when I download a new app, I look at my battery usage a few hours later, and that app has managed to use 45% of my battery even though I used it for a few minutes. So then I just reboot
In conclusion, don't use a task killer, but keep an eye on the battery usage feature if you find that it has suddenly gone down (Settings -> About Phone -> Battery Usage)
I use Memory Booster. Quiet amazing.
hi i used to be same as you and always used talk killers
then i came across this article http:// www.ipmart-forum.com/ showthread.php?t=528674 (watch for spaces in the link)
since reading this i installed watchdog lite and i only kill a task if its overusing the system.
you can set it to notify you when an app is using more than a certain % of resources and its great then if i need to i just kill that app/process
pngface said:
Well that still doesn't solve the problem of badly written apps draining the battery. Often I've found that without a task killer my battery life has improved, but on occasion when I download a new app, I look at my battery usage a few hours later, and that app has managed to use 45% of my battery even though I used it for a few minutes. So then I just reboot
In conclusion, don't use a task killer, but keep an eye on the battery usage feature if you find that it has suddenly gone down (Settings -> About Phone -> Battery Usage)
Click to expand...
Click to collapse
that doesn't work all the time is kinda annoying to keep checking your phone and see if the battery is alive or not
bongd said:
It's nothing to worry about. Unused memory is useless memory. It's *nix based so the memory in use isn't going to drain the battery or slow the system down. It manages everything by itself. By repeatedly killing tasks you're actually stressing things unnecessarily.
The only time you should kill all the tasks is when you know something is being problematic, before locking your phone when you have a suspicious app that doesn't always stop automatically, etc. Otherwise the Android OS takes care of this by itself.
I stopped using task killers months ago (except for when I lock my phone because of what I mentioned above.. programs keeping it from going into a deep sleep) and my battery easily lasts two days with periods of very heavy usage.
Click to expand...
Click to collapse
K i seriusly need some answers how the hell do people come to know which app prevents it from sleeping? how can you figure out a bad application . does sleep here means when locks itself and screen goes blank? confused :S
Hello all,
I am very new to android, this GT 10.1 being my first android device. I have been unable to figure out how to kill a process and or close apps. I have tried "advanced task killer" & "watchdog" apps, as well as going settings>Applications>force stop on said apps; no luck, running apps still show on the navigation button.
I have searched the GT 10.1 forum with no luck, has anyone had this issue and or have a fix?
There was a lot of talk about task killers on Android phones over the last couple years... As I recall, since Android 2.2, Android terminates apps when needed. I would not recommend a task killer... They can cause system instability when shutting down apps. As best I know, it is the same on the Android 3.x series as well.
Bukem is correct -- as a rule, you don't want to force close an application or service unless it is actually misbehaving. Android doesn't work like Windows. Android is much more efficient about managing background tasks, and there's usually no noticeable performance hit even from extensive multitasking.
Plus, you don't know what every applicable or service is actually doing or whether its needed. By way of example, when the EVO came out a few self-proclaimed experts advised that you could task-kill the Google Talk service to make the phone faster. Turns out, the Google Talk service was used as the universal Google sign-in, so killing it also killed your push Gmail and all other Google services.
Agreed. Task killers haven't been needed for Android since 2.2. Google should save everyone the confusion now and just purge them from the market, in my opinion.
Quote from a well-known dev, cvpcs:
…What people don’t seem to realize is that android is designed to have a large number of tasks stored in memory at all times. Why? Well basically we are talking about a mobile device. On a mobile device things tend to be slower. The hardware isn’t as robust as say a desktop or a laptop, so in order to get that same “snappy” feeling, there have to be workarounds.
One of these is how android deals with memory. Android will load up your apps and then keep them running until they absolutely HAVE to kill them. This is because that way, if you want to re-open an app, the system already has it loaded and can then just resume it instead of reloading it. This provides a significant performance increase.
What a lot of people don’t realize as well is that android kernels have their own task manager. This means that:
it will be more efficient than any app-based task manager as it is run at the kernel level, and
it should be left up to that task killer to decide when to free up memory
There is only one case where having a task killer is a good idea, and that is when you want to kill ONE SPECIFIC APP. Killing all apps is never a good idea. You don’t know what operations they are performing or if they are necessary.
Click to expand...
Click to collapse
Whitson Gordon of Lifehacker:
This set-up implies that the goal of killing these apps is to free up memory. Nowhere on the list does it mention the number of CPU cycles each app is consuming, only the memory you’ll free by killing it. As we’ve learned, full memory is not a bad thing—we want to watch out for the CPU, the resource that actually slows down your phone and drains your battery life.
Thus, killing all but the essential apps (or telling Android to kill apps more aggressively with the “autokill” feature) is generally unnecessary. Furthermore, it’s actually possible that this will worsen your phone’s performance and battery life. Whether you’re manually killing apps all the time or telling the task killer to aggressively remove apps from your memory, you’re actually using CPU cycles when you otherwise wouldn’t—killing apps that aren’t doing anything in the first place.
In fact, some of the processes related to those apps will actually start right back up, further draining your CPU. If they don’t, killing those processes can cause other sorts of problems—alarms don’t go off, you don’t receive text messages, or other related apps may force close without warning. All in all, you’re usually better off letting your phone work as intended—especially if you’re more of a casual user. In these instances, a task killer causes more problems than it solves.
Click to expand...
Click to collapse
And from a site called NextApp:
Android was designed from the ground up as an operating system (OS) for mobile devices. Its built-in application and memory-management systems were engineered with battery life as one of the most critical concerns.
The Android OS does not work like a desktop operating system. On a desktop OS, like Windows, Mac OS X, or Ubuntu Linux, the user is responsible for closing programs in order to keep a reasonable amount of memory available. On Android, this is not the case. The OS itself automatically removes programs from memory as memory is needed. The OS may also preload applications into memory which it thinks might soon be needed.
Having lots of available empty memory is not a good thing. It takes the same amount of power to hold “nothing” in memory as it does to hold actual data. So, like every other operating system in use today, Android does its best to keep as much important/likely-to-be-used information in memory as possible.
As such, using the task manager feature of SystemPanel to constantly clear memory by killing all apps is strongly NOT RECOMMENDED. This also applies to any other task killer / management program. Generally speaking, you should only “End” applications if you see one which is not working correctly. The “End All” feature can be used if your phone/device is performing poorly and you are uncertain of the cause.
Click to expand...
Click to collapse
All those quotes were aggregated for this article, if you want to read more: http://www.droid-life.com/2011/06/02/revisiting-android-task-killers-and-why-you-dont-need-one/
So TL;DR, this:
Droid Life said:
Basically, Android keeps tasks handy because it thinks you’ll want to perform them again in a very short amount of time. If you don’t, it will clear them out for you. It also likes to keep as many things handy as possible so that the overall performance of your device is top notch. If Android were to completely kill off everything that your phone is doing, then it would require more resources to restart all of them and you would likely run into slowness and battery drains. By keeping certain things available to you, your phone is actually running better than it would without. So please, stop killing off tasks and let Android do the work for you.
Click to expand...
Click to collapse
Although they are not necessary in every day use, I still recommend having one just in case. Every once in a while, something will go wrong. I guess you could just reboot so it's not a big deal either way. So anyway.. I have advanced task killer but I probably only use it about once a month.
On Linux I am not a hostage of the operating system...
On Android it seems it wants me to be 'cos it knows better.
For example: I use Skype maybe once a week. BUT android assumes that I will use it again and 3 minutes, and keeps it around hoping that I do. I know I won't so I want to kill it (like I did 2.1) so the machine will be more responsive - instead of for CPU to do massive cleanup before I start a new app.
The terrible system instability, the immediate phone damage - this is spreading FUD. Nothing terrible will happen.
Grrr...
viulian said:
o be 'cos it knows better.
For example: I use Skype maybe once a week. BUT android assumes that I will use it again and 3 minutes, and keeps it around hoping that I do. I know I won't so I want to kill it (like I did 2.1) so the machine will be more responsive - instead of for CPU to do massive cleanup before I start a new app.
The terrible system instability, the immediate phone damage - this is spreading FUD. Nothing terrible will happen.
Grrr...
Click to expand...
Click to collapse
You see this is EXACTLY what the anti-taskkiller people dont understand. They think apps get closed and memory gets reorganized like MAGIC instantly. They dont understand that it takes CPU power to do this which is why you see slight lag when your memory gets low. This lag is from the system reallocating memory and this has been proven via acatlogs.
Hey there all, this is 2 Bunny again. As many of you know, back in October I had to make an emergency switch from Windows Mobile to Android. As you've all read in my posts, it has been a very "mixed" experience with both some impressive and downright pathetic discoveries, but one of the worst things about it (beside the complete inability to sync) is the way that Android closes your programs whenever it feels like it instead of letting you close them. Sometimes I'll be browsing the internet in Opera Mobile and I'll switch over to the email program briefly to check something, when I hold down the "home" key and pick OM from the list of recently used programs, it starts it all over again, and I know for a fact I didn't choose "exit".
Sometimes I'm glad Android "cleans up" (like if I back out of a program that has no "exit" option) because it saves me the trip to the task manager later, but is there any way I can prevent it from closing stuff I'm actually still using?
Thanks.
- 2 Bunny
kainppc6700 said:
Hey there all, this is 2 Bunny again. As many of you know, back in October I had to make an emergency switch from Windows Mobile to Android. As you've all read in my posts, it has been a very "mixed" experience with both some impressive and downright pathetic discoveries, but one of the worst things about it (beside the complete inability to sync) is the way that Android closes your programs whenever it feels like it instead of letting you close them. Sometimes I'll be browsing the internet in Opera Mobile and I'll switch over to the email program briefly to check something, when I hold down the "home" key and pick OM from the list of recently used programs, it starts it all over again, and I know for a fact I didn't choose "exit".
Sometimes I'm glad Android "cleans up" (like if I back out of a program that has no "exit" option) because it saves me the trip to the task manager later, but is there any way I can prevent it from closing stuff I'm actually still using?
Thanks.
- 2 Bunny
Click to expand...
Click to collapse
Try ZDBox application.....maybe you'll find a solution to that problem!!
jimsiv said:
Try ZDBox application.....maybe you'll find a solution to that problem!!
Click to expand...
Click to collapse
Interesting. So that can prevent it from closing certain programs?
- 2B
kainppc6700 said:
Interesting. So that can prevent it from closing certain programs?
- 2B
Click to expand...
Click to collapse
Yup. I've been using it for a long time. As far as I know you can set certain apps to Protect so they're not closed.
ZaIINN said:
Yup. I've been using it for a long time. As far as I know you can set certain apps to Protect so they're not closed.
Click to expand...
Click to collapse
Great, I'll give that a try and letcha'all know if it works.
- 2B
Update - well it seemed promising, but it didn't work unfortunately. ZDbox said it was "protected", but that didn't stop Android's hammer of making people's lives miserable.
Any ideas if I might be doing something wrong in ZDBox (I did turn off the notification thing) or if there is other software I might be able to try?
Thanks.
- 2 Bunny
If rooted try V6 supercharger script. Just do a search on XDA. It rewrites your phones memory management to increase multitasking capabilities by reconfiguring your ram. If not rooted, your choices are severely limited by existing software to hardware configurations preset by the android operating system and the device manufacturer. Go through all of your programs and clear out all of your allocated cache memory. Freeing up ram memory may help your multitasking needs.
Sent from CDMA V6 SC GNexus w/Liquid & Franco.kernel
As mentioned by others, the most likely culprit is high memory utilization. However, there are a few other reasons that may contribute to the application closing down. Android "ranks" applications from 1 to 5 (where 5 means it is the first to get killed) based on certain criteria. Because xda won't let me link to it (I'm a new user), I have posted them at the bottom of my message.
Chances are, you are seeing the behavior in numbers 4 and 5. The fact that Android keeps applications in a least-recently-used list means that if you have applications which you just accessed but appear to have closed when you come back to them, then, once again, it is likely you are using a lot of memory that the phone is aggressively trying to keep cleaned up.
Although, it is possible that a small number of your problems are based on poorly implemented applications since the developer website states "If an activity implements its lifecycle methods correctly, and saves its current state, killing its process will not have a visible effect on the user experience..."
1. Foreground process
A process that is required for what the user is currently doing. A process is considered to be in the foreground if any of the following conditions are true:
It hosts an Activity that the user is interacting with (the Activity's onResume() method has been called).
It hosts a Service that's bound to the activity that the user is interacting with.
It hosts a Service that's running "in the foreground"—the service has called startForeground().
It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).
It hosts a BroadcastReceiver that's executing its onReceive() method.
Generally, only a few foreground processes exist at any given time. They are killed only as a last resort—if memory is so low that they cannot all continue to run. Generally, at that point, the device has reached a memory paging state, so killing some foreground processes is required to keep the user interface responsive.
2. Visible process
A process that doesn't have any foreground components, but still can affect what the user sees on screen. A process is considered to be visible if either of the following conditions are true:
It hosts an Activity that is not in the foreground, but is still visible to the user (its onPause() method has been called). This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it.
It hosts a Service that's bound to a visible (or foreground) activity.
A visible process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
3. Service process
A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.
4. Background process
A process holding an activity that's not currently visible to the user (the activity's onStop() method has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state, killing its process will not have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state. See the Activities document for information about saving and restoring state.
5. 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.
PAIN IN THE REAR TO DO THE INSTALLATION Reply
That sounds promising. I'll give it a try and letcha'all know if it works or not.
Just FYI, the installation is a HUGE pain. I messed around with it for a solid hour and a half, maybe two hours to get it up and running, so it better work or I'm out the time I put in and I'd have anotherwise useless something running/taking up space.
Thanks.
- 2B
Looks like I wasted my time. Not only did that not have any effect, it seems to have permanently brought back the useless update nagscreen - a million thumbs down to "supercharger" for being the most useless waste of an hour and a half of my life.
Not to be mean here, but did anyone try the suggestions before posting them?
Guess I'm off to the recovery menu again to try and get rid of the nagscreen, that is if I'm not booted out first.
- 2B
SAVE THE PROGRAMS Reply
Any updates on this?
Thanks.
- 2B
Any updates on this?
Thanks.
- 2 Bunny
FORCE CLOSE Reply
Any updates on this?
- 2B
STILL FORCED CLOSED Reply
Any updates on this?
- 2B
Yes.
Install V6 Supercharger and bulletproof Opera Mobile/Mini.
Are you sure you had it installed and it was running actually?
Your kernel needs to support init.d scripts.
If not, prior to installing V6 create init.d folder in /system/etc/ and grant it all the permissions. Download Script Manager app and set V6 scripts from init.d folder to run at boot.
I hope it works.
Simple Workaround:
Download MinFreeManager app and tweak your min free settings according to your RAM. More RAM = More Agressive Settings. Google android minfree and you'll find how to.
Boy124 said:
Yes.
Install V6 Supercharger and bulletproof Opera Mobile/Mini.
Are you sure you had it installed and it was running actually?
Your kernel needs to support init.d scripts.
If not, prior to installing V6 create init.d folder in /system/etc/ and grant it all the permissions. Download Script Manager app and set V6 scripts from init.d folder to run at boot.
I hope it works.
Simple Workaround:
Download MinFreeManager app and tweak your min free settings according to your RAM. More RAM = More Agressive Settings. Google android minfree and you'll find how to.
Click to expand...
Click to collapse
I'll tell you what, I screwed around with that "supercharger" for so long, I really don't want to look at it again (I think my ROM might actually have it included). All I know is that it did install because when I restarted the device, I got the stupid update nagscreen back.
I am going to try that "MinFree" program though and report back what I figure out. So far it seems to be working, so this could be promising, but I'll keep ya'all posted.
- 2B
BULLET Reply
kainppc6700 said:
I'll tell you what, I screwed around with that "supercharger" for so long, I really don't want to look at it again (I think my ROM might actually have it included). All I know is that it did install because when I restarted the device, I got the stupid update nagscreen back.
I am going to try that "MinFree" program though and report back what I figure out. So far it seems to be working, so this could be promising, but I'll keep ya'all posted.
- 2B
Click to expand...
Click to collapse
Update. Looks like "MinFreeManager" isn't doing its job either.
Any other ideas? Anyone? I'll even try the "BulletProof" thing.
- 2B
I use the browser and check email while browsing without any problem returning to the browser. In your first post you said you use the home button. Doing that will close the browser. Use the back button to return to the browser.
Sent from my LG-P500 using XDA
fdaconta said:
I use the browser and check email while browsing without any problem returning to the browser. In your first post you said you use the home button. Doing that will close the browser. Use the back button to return to the browser.
Sent from my LG-P500 using XDA
Click to expand...
Click to collapse
Actually, the home key leaves it running. I usually check right away, and at first it continues running; it's when you're not watching that it takes it right out from under you. It might just be this build of Android.
Is anyone else running Gingerbread and having this problem?
Does anyone know of any kind of solution?
Thanks.
- 2 Bunny
PROGRAMS CLOSING BY THEMSELVES Reply
Any updates on this?
Thanks.
- 2 Bunny
Could anyone show me a user friendly android app which can effectively show which apps cause memory leaks on a phone?
I can only find developer tools to detect memory leaks within apps like Eclipse MAT. Sadly I'm not a developer so I would rather prefer just a list of apps to uninstall and not the exact cause of memory leak within a specific app.
Thx for any help!
dbalazs123 said:
Could anyone show me a user friendly android app which can effectively show which apps cause memory leaks on a phone?
I can only find developer tools to detect memory leaks within apps like Eclipse MAT. Sadly I'm not a developer so I would rather prefer just a list of apps to uninstall and not the exact cause of memory leak within a specific app.
Thx for any help!
Click to expand...
Click to collapse
Why do you believe you've got some apps leaking memory?
kuisma said:
Why do you believe you've got some apps leaking memory?
Click to expand...
Click to collapse
Cause it doesn't matter which rom do I use on my phone (I've tried plenty of them) it gets laggy after a couple of days.
dbalazs123 said:
Cause it doesn't matter which rom do I use on my phone (I've tried plenty of them) it gets laggy after a couple of days.
Click to expand...
Click to collapse
Check how much each app consumes from settings->apps->running, and compare memory usage from time to time. You can also use logcat and see what ActivityManager is up to, i.e. if it begins to kill apps more frequently ("No longer want ...").
But low on memory, is only one explanation of lag. An app usually don't survive long enough for a memory consumption/leak to become an issue.
OK. So what I actually noticed last time is the next: after a few days background apps started keep restarting. I guess it was because minfree tried to make some space to meet the aimed value, but system kept restarting apps cause they were essential. Since I started using greenify I meet this problem after a little bit more time as before, because I only leave the most important background processes unhibernated. That was the reason Isuspected memory leak.
dbalazs123 said:
OK. So what I actually noticed last time is the next: after a few days background apps started keep restarting. I guess it was because minfree tried to make some space to meet the aimed value, but system kept restarting apps cause they were essential. Since I started using greenify I meet this problem after a little bit more time as before, because I only leave the most important background processes unhibernated. That was the reason Isuspected memory leak.
Click to expand...
Click to collapse
I'd guess you've hit the limit of the number of simultaneous tasks Android can run before starting to kill them. If you get more than 15 running, ActivityManager have no other choice than kill the last recently used. And if they all are "sticky", Android must as well restart them, causing an endless kill/restart loop, only limited by the restart pause enforced by ActivityManager. Try removing/disabling some bloat-ware.
But you'll see this clearly in the logs looking the at ActivityManagers output.
kuisma said:
I'd guess you've hit the limit of the number of simultaneous tasks Android can run before starting to kill them. If you get more than 15 ng, ActivityManager have no other choice than kill the last recently used. And if they all are "sticky", Android must as well restart them, causing an endless kill/restart loop, only limited by the restart pause enforced by ActivityManager. Try removing/disabling some bloat-ware.
But you'll see this clearly in the logs looking the at ActivityManagers output.
Click to expand...
Click to collapse
I can assure you I don't have any (or at least not that much) bloatware on my phone. When those infinite restarts happened I had about 5 background processes. And those restarts started to happen after more than 2 days every time. If I had too much apps it would started without any delay.