Shared publicly  - 
Somehow, this all sounds so familiar. Where have I heard this before? Gosh I can't seem to recall.

It reminds me of one of my favorite Steve Jobs quotes: "In multitasking, if you see a task manager... they blew it. Users shouldn't ever have to think about it." Said when showing the new iPhone app switching UI that makes process management more visible than the corresponding one in Android.

This certainly is a tricky UI issue though -- you really don't want to make visible to the user the underlying management of processes and stuff that they normally don't need to care about. That is "normally" though... at the end of the day, nothing is perfect, there will always be misbehaving apps that you need to allow the user to deal with (because ultimately the difference between behaving and misbehaving is a big gray area of different perspectives), so providing a UI for this is probably something good to have for the users who want to go into it.

For Android our approach so far has been to keep the multitasking/app switching UI (which is a core part of the user experience) strongly separated from the process management UI (down in "Manage Applications" in Settings). This seems to me like a reasonable approach: for most users they really shouldn't have to care about process management, and having that visible in the normal UI is just going to cause misunderstanding.

Then we have people write task managers, and sales people at carrier stores installing task managers onto devices as they sell them, and word of mouth spreads that these things makes your device run faster, and they get to the top of the Market stats, and here we are. :)

(True story: when we got my wife her original Droid at a Verizon store, the salesperson went into a song and dance about how you need to manage the running apps on it to make it run well, and went to go find one on Market and install it. I watched in shock as this was going on, until reaching the point of going to install the app where I stepped in and said no you are not going to do that, and you should not be telling people to do this.)
Tim Millington's profile photoDianne Hackborn's profile photoCedric Counotte's profile photo1gravity LLC (onegravity)'s profile photo
You were able to make yourself wait until they were about to install?
I had to keep watching to see how far it would go!
I honestly don't know where the store phone people get their information.. I have had to remove the "task managers" from android phones that were on tmo, att and verizon.. Every phone owner said that the appkiller was installed at the store..
maybe this is where google or Samsung, HTC, Moto etc..should educate their staff that pass 2.1 android has a very efficient memory management system and that task killers are bad
I try to preach to store reps every time I hear them tell someone to install a task manager, but they never listen.

Agree with Android appropriately handling memory management, but question: What about battery usage? Does Android do something similar to what iOS does in suspending background apps after 5 seconds so they don't consume battery?
On Ice Cream Sandwich does the swipe gesture in the recent tasks list do anything to the tasks? Does it kill them or just simply remove them from the list?
Personal goal whenever entering a carrier brick and mortar is to get in and get out before overhearing a salesperson tell a new Android user how to or why they are installing a task manager.
Thanks Romain. That's a nice easy way to let the users manage the processes. Natural.
Why are carriers allowed to monkey with devices in the first place?
+Romain Guy I can't seem to verify the killing of apps when swiping them from recent apps list (I didn't think it killed them so I found this pretty interesting and set to check for myself!) I just opened Listen, checked my running apps, it was there. I swiped it away in the recent apps list, checked running apps, still there. Also just tried with Navigation - I'd imagine swiping from recent tasks (if killing it), it wouldn't be in my task bar anymore, but it's still there (and about 4 maps process' in my running apps, which I think at least a couple are from nav).

Is there something I am missing? Seeing as you WORK on Android, I figure I am doing something wrong here :D
+Thomas Brooks I just verified it. 1) launch an app 2) (from my linux box) type: adb shell ps | grep com.whatever.appname 3) you'll see the app running. 4) press home 5) run the above ps command to see that the process is still there. 6) bring up recent apps list, swipe the app away. 7) run the above ps command again, see that the process is gone.
I'm sorry, but the Droid 1 did need a task manager. 256MB just was not enough, and Android did not manage it well in many phone included. Newer phones, I totally agree, Android does a fine job by itself.
+Fernando De Leon unfortunately, Samsung, Motorola, and HTC have all included task managers in their custom versions of Android.

It's a placebo thing that carries over from people used to the Windows way of things working, and not being used to a Linux/Unix based system where RAM being used is a GOOD thing.
+Peter Daly true. Well, I can't say it was so much that it wasn't enough when the phone came out, as much as it just got to the point that applications matured to take advantage of newer hardware and the OG Droid kind of got left in the dust.
+Romain Guy I'm confused. When I play music from an app and swipe it away the music keeps playing. I tried with the system installed Music and a downloaded user app. Am I not understanding what killing a process is?
+Jonathan Franklin Correct, but I think the Droid 1 situation is the root of the "Android needs a task manager" issue. The Droid 1 did need a task manager, and that fact is often overlooked in this debate.
+John Bonsall an application along the lines of music is a persistent process/notification. Swiping away doesn't kill it as in force close it. Swiping it away ...i'm hoping i put this correctly. When you leave a task for another, and ram is used for a foreground process, it kind of caches the other programs where you can pick up exactly where you left off. Swiping off kills that part, not necessarily the entire service itself (and it shouldn't as people that killed, say, phone, could potentially miss calls or text messages or whatever really).
+Peter Daly very true, not discounting that at all, it was necessary. A lot of custom roms still use init.d scripts that were originally intended for the OG droid such as the whole V6 supercharger script, and it is COMPLETELY unnecessary on modern phones and I delete it as soon as I flash anything that has it.
+Jonathan Franklin Sounds plausible enough to me. So.... basically it's aesthetic? Because either way isn't my 4.0 device efficiently managing my RAM so that unused RAM is wasted RAM?
I have a minor following at work for being "the Android guy" after teaching people basics like this.
Hmm i wouldn't say 100% aesthetic. but it doesn't completely "kill" the app.. the multitasking bar is essentially a placeholder so you can jump back and forth between applications, picking up exactly where you left off rather than starting the app from the splash screen or whatever. Note that any Android keeps this, but ICS gives you a clean efficient way to manage it (Long press home on any other Android with 4 hardware keys). It does take resources to keep such a placeholder, and that essentially is a "background" item, so it does close that part of it and free up a bit of ram I suppose. but it does so safely without screwing with the system too, unlike a task manager.

And yes, I'd say probably Froyo on up, manages RAM very efficiently, beyond the point you'd have to worry about it. and unused RAM is wasted RAM, it's just a question of: which of your applications do you want to be in said RAM ;) When you used to compare say Sense to AOSP, or Touchwiz or Blur or whatever, in real world use, they're really not much slower perception wise, in terms of ability to play games, or utilize the hardware appreciably, or open an application. But they are "slower" in that, say a heavy skin like Sense is running all it's Widgets etc, and that uses a lot of RAM, even on a fresh boot. that is RAM that could have been allocated to applications that you use very often, and thus would be able to jump back and forth between very quickly, without having to "reload" them. Where straight up AOSP is very small, and very lean, and basically a blank slate, allowing you to do just that.

I suppose that's the other reason that iOS users just don't "get it" in terms of how Android uses it's hardware when they compare the two, and in a lot of ways really don't understand how efficient Android is considering that it has to do so much more. Because if you took an iPhone 4S, and gave it's users the option of having so many different window events in the form of widgets on the desktop, scrolling wallpapers, customizable screens, an app drawer, (let's say pre-ICS on the next few) having the menu and search options everywhere instead of baked into the apps themselves, it would struggle to provide a smooth user experience everywhere.
Anyways its informative and interesting to know whats going on...
+Jonathan Franklin and others -- what specifically happens when you swipe away a recent task is it: (1) kills any background or empty processes of the application (see for what this means), and (2) uses the new API to tell any services of the application about the task being removed so it can do whatever it thinks is appropriate.

There are really two major classes of things that run in the background: old processes of previously foreground apps (to speed up task switching), and processes that actively need to run indefinitely because of a service.

The first, background processes, are straight-forward -- they can be kept around, but the system can freely kill them whenever desired to free memory, and doing this basically has no impact on the user experience.

Where things get interesting is with services, which are basically how an application says "hey I need to be kept running in the background to do something." This may be to play some music, to fetch new e-mail, to perform navigation, to download a file, to update an app widget, and on and on. On devices that are tight on memory, it is these application services running that can cause memory pressure that is visible to the user.

The platform has some simple policies for managing services when under memory pressure -- it will start killing their processes, stopping the services if they haven't indicated they need to be kept running, or scheduling the service to be restarted later when there is more RAM. Under severe pressure though it will start cycling through services -- killing one process, which allows it to restart another process for a service, but then it wants to try to restart the first service, which kills the second process, and on and on. It will back off on starting service when in this situation to avoid too much thrashing, but at this point you can't keep any background processes around (so app switching can become visibly slower) and at least some things that you want running in the background are no longer able to run well.

And this is where we get to the big grey area of whether an application is being well behaved or not. Maybe an application just is broken and left a service running for no reason. We made some changes to the Service API to try to help prevent developers from doing this, but it happens and is something that needs to be fixed in the app. (Every now and then I get it in my head that there should be some way for the platform to say "hey this service has been left running forever, this is broken, I'll just stop it." But there really are things that validly want to do this, though we need them to be pretty rare. For example, you wouldn't want your connection with the Google service to go away after a while because that service in the Google apps has been thrown away.)

We go out of our way to design the platform so that applications don't need to stay running in the background, because this can have such an impact on the overall system. For example, this is one significant reason why app widgets are limited in how interactive they can be -- their user interaction can only be through the standard widgets in the framework, so it can all be done in the launcher process, without requiring that the app widget's process be kept running. In fact we had an issue before shipping 3.0 where the implementation of the new more interactive app widgets was causing the processes of the widgets to be forced to stay around. It wasn't hard to put enough widgets just from the stock apps on the home screen to end up with so many processes kept running that RAM became low even in a 1GB tablet.

Anyway, I think more often when memory is low due to service, we have just hit a point where we are asking the device to do too much, with too many applications wanting to run in the background. At this point what should be done is a judgement call -- what things do you actually want running and what not? The Running Services UI was done to help with this. Trying to make this more visible in the UI is difficult without causing a lot of complexity for users who mostly wouldn't need to know about this, wouldn't really know what to do about it, and are thus likely to start poking at it in ways that are not effective. For example, "gosh I never use this Google Services thing, stop it" and now silently they are no longer receiving tickles for new e-mail and IMs and C2DM.
+Peter Daly Keep in mind that as of Android 2.2, task managers can't kill any processes except background processes which the platform will do a very fine job of killing itself as it needs more RAM. (When we were making this change to fix the issue with task managers breaking other apps, I considered making it so the API they were using just wouldn't do anything any more, but partly to avoid too much of an outcry just left it so they could kill processes that are purely expendable.)
+Tom Flynn Android doesn't suspend processes so they can't run at all. As far as I know Linux doesn't support such a thing, and even if it does I think there is too much danger doing that to a process and leaving it with something stuck -- holding a wake lock, in the middle of an IPC, with an open network socket or file, or all kinds of other stuff.

In practice, though, you can mostly consider them suspended -- the process will be sitting there waiting for something to do, but there is nothing, so it is sitting there not using any battery, just memory.

To protect against broken applications that mistakenly do needless work in the background, the system monitors CPU and wake lock usage of all background processes, and every 10-15 minutes if it sees too much going on in a process will kill it.
+Lars Paukert Have you given htop a shot? top with a nice ncurses (iirc) UI and awesome fanciness!
so in the ics can we change adj/priorities grouping that we will give to oom killer? like for gb and lower version i can changed this grouping when writing a new values in build.prop
It's almost as if Apple saw someone else implement the feature and then copied it to their OS once they got comfortable with the concept! ;-)
I've never quite understood this. I think it's just human nature to fiddle and cast magic they don't understand, than to scientifically profile how their device works and than equate whether or not time spent micro-managing something that is automagic, actually gives a positive return.

Never needed a task killer except for jTalk: it is a really tough prick to kill if I forget to exit it, before leaving my companies network.
well battery life is likely why people obsess over it, but keeping the screen on to kill all these apps obsessively is chewing up much much more battery life than the apps that they think they're killing.

People treat the iPhone as if it has some superkernel and their limiting third party applications is the reason for its battery life. And it really has 95% to do with the iPhone having a 3.5" LCD display. People like bigger displays, but they are battery hogs comparatively. 4.3" is a lot bigger surface area wise than 3.5". You compare the iPhone with a more similar phone, say the HTC incredible 2 with a 4" LCD display, the battery life on both of those devices is excellent. Task management is more of a placebo thing. If you want to save battery then you need to focus on minimizing the time the screen is on and the time that the cell (data portion) radio is working. Android was designed for information density and efficiency. With Widgets and push notifications and allowing apps to more deeply tap into the system and with other apps so that they can do the dirty work so you don't have to stare at the screen or open individual apps all day.
Luckily, when I bought my DROID X, the sales rep was at least intelligent enough to boldly state that getting a task manager was a very bad idea. I already knew, but if he told me, that means he was telling other people as well.
I know of a lot of people that saw task managers as an answer to deal with carrier/manufacturer skin bloat rather than the need to help Android manage memory. For example, a person that might not have been into social media still had several running process listings for facebook, facebook for htc sense, twitter, etc. and wondered how they could shut them down. Shutting them down through a force close meant only having them open themselves up again eventually, so they were looking for something that automated that process. Their frustration was the feeling (even if only perceived) that these systems and programs that they don't even use were affecting their battery life and processing/memory bandwidth. Is it an Android problem? Not stock/Nexus Android, but definitely skinned/carrier bloated variations. ICS's ability to quarantine bloatware should be the final nail for task managers.
1. When Apple fans preach it fully "multitasks" a lot of people actually believe it. Mobile multitasking concepts just are elusive to the general population when they are used to desktop OS's.

2. Speaking of automatic killing of apps. I ran into a situation last week where ICS was killing the launcher while other background tasks remained in memory. Really annoying having to wait for a reload of all the icons after every app. Had to reboot to fix. When you have 1GB of RAM the launcher should never never never never be killed. (This is stock non-rooted 4.02 on Galaxy Nexus)
+Dianne Hackborn sending a SIGSTOP will suspend a process, SIGCONT will resume a process. You bring up a good point about whether the app is holding a lock or performing some other action. Though iOS must handle it somehow. Maybe it's part of their application lifecycle? I haven't done enough iOS programming to know what they do.
Kun Li
+Dianne Hackborn Based on your explanation above, can we say that:

(1) even if a app without service is doing job in background(like still listening to the Bluetooth in another thread or something like that), as long as it doesn't have a service, it will still be a normal background (empty?) process and will be killed once user swipe it away or memory is low

(2) If you have a service need to be always running unless it's killed explicitly by user, it's better to always set ServiceInfo.FLAG_STOP_WITH_TASK? Otherwise even if user swipe it out from recent app list, the service may still be running

Thanks for your time!
That old chestnut :-) Multi-tasking would only technically be true if each cpu core ran one task each, but an efficient OS simply shares clock cycles AFAIK and background tasks use interrupts to poll a device, keep an eye on some service, or whatever. ICS "swiping" is pretty useful, but only really shows apps that are running , not services/processes/tasks which can easily hog resources. I have ICS turned on to kill each app as you close it. It's pretty rare that I need to run more than one app at a time, unless perhaps you are playing music while browsing, want to launch an email while using some other app, or whatever. Game servers bug me sometimes , constantly running but unable to be killed without unintstalling the game.

What about widgets? They usually run pretty continuously, especially the ubiquitous weather/clock app on most home pages, and the e-mail, SMS, or even certain social network clients are "always on". Even though many say you don't need a task-killer on modern androids, a good system control app can still be useful allowing you to state what services can be killed if needed, what should be locked, underclock the CPU etc. Does a lot for Ram and Battery wastage!
+Stuart Reid No well-written widgets run continuously. Certainly none that are shipped with the standard platform do. Certainly if a developer is doing something to the point of causing poor battery life, this should show up in the battery use, so you can tell them their app sucks and uninstall it.
+Dianne Hackborn unrelated to multitasking per se, but on the galaxy nexus (I have lte version) it seems most live wallpapers cause a lot of lag on the launcher/UI, the one exception being phase beam. Any clue if its a framework thing to be addressed in 4.0.3? Just wondering since 4.0.3 fixes a few other things such as the landscape keyboard and such. I've flashed a few 4.0.3 rooms but it isn't the same as an official shipped rom and honestly I question some rom builders decisions lpl
Seems the swipe to remove does not "(1) kills any background or empty processes of the application", but kills only the task that caused the entry in recents (which seems to be the last foreground task).  This seems to be half a job. Other tasks in the app are left intact and it appears to be very difficult to propagate the "swipe" effect to all tasks of an application to complete the job. The remaining task(s) do not appear in recents, so cannot also be swiped away, and, moreover, retain their navigation state, which is confusing to the user when they relaunch the app from the home screen. It's also a massive headache for development in cases where where there was any synchronization going on between the tasks.I think it is also problematic to begin with, that the activity flag android:excludeFromRecents gives peculiar results in apps with multiple tasks where one task has this flag set to true, and one set to false. Suppose the app launches to task A (true) which at some point launches an activity on task B (false). Initially, when an activity from task A is in the foreground the app shows in recents, but when the activity from task B is in the foreground, the entry disappears! Surely the app, and in particular task A should still show? Confusing.
+Timothy Millington Complain to the author of the app.  This API is appropriate for reasonable things apps may do -- for example transient tasks like the alarm clock alert screen or the summary of calender events that is shown from a notification or the in-call screen do not make sense to have listed as regular tasks.  These are not "applications" the user has launched, they are temporary transient UIs that the user didn't launch as a regular application.  (And in many cases may not make sense at all to return to outside of their brief lifecycle.)
Don't really want to revive such an old subject, but while task killers are constantly reported as being evil, why Android 4.4.2 transformed the swipe task into an app killer as detailed (and verified) here:!topic/android-developers/H-DSQ4-tiac

I'd like to point out that the Android OOM is actually a task killer, here is my true story: 

I use G+ once every month if ever and it consumes 33MB, I use a battery monitoring app that consumes 5MB which I use 20+ times a day and the app shows a widget on the launcher.

Guess which apps gets killed first? The battery app indeed, if that's not lame or evil, I really don't know what is.

And now with KitKat, it gets even worse: the battery app is killed and never restarted! G+ continues to run flawlessly, preventing deep sleep quite frequently and thus draining the battery.

My last Nexus 5 can last more than a week on battery, but only if I remove all Google's app :( ! I don't use them frequently but gee, I'd like to be able to use them from time to time. 

My 2 wishes for next Christmas: Having optimized Google apps and a smart OOM task killer. Ok, I'm too old to believe in Santa Claus :D

Keep up the great job with Android anyway! An incredible achievement!
@Dianne Hackborn
You say: "To protect against broken applications that mistakenly do needless work in the background, the system monitors CPU and wake lock usage of all background processes, and every 10-15 minutes if it sees too much going on in a process will kill it."
Can you elaborate on what exactly the criteria are to decide whether a process may live or die (sound like playing god ;-)? Are frequent wake locks enough to get on the "kill list" or is the time the app keeps the device awake the decisive factor (or both)?
Add a comment...