The recent apps list in Ice Cream Sandwich added the ability to swipe apps out of the list, thereby dismissing them permanently (and as far as I know this is a vanilla function, not a CM/custom ROM one). The documentation and platform highlights don't appear to cover the under-the-hood workings of this functionality, but I'm curious to know what the system is actually doing.

Further adding to my curiosity, I decided to do a quick test: I started up Music on a CM9 install, then backed out of it. I then checked the recent apps list and saw it was indeed there (and in the proper state, based on the thumbnail). I then went into Settings->Applications and force stopped the Music app, but it was still listed in the recent list, leading me to believe it's not connected to processes lingering in the background.

Realizing now that Music may have been a poor choice, I also tested with the USA Today app. This exhibited basically the same behavior, and it seemed like it was forced to "relaunch" after the force stop (which makes sense) though the thumbnail in the recent apps list didn't reflect this (cached, I'm guessing?).

So, what actually happens at the OS level when you swipe an app out of the recent list? Does it simply clear the app's data out of RAM and garbage collect it, destroying its saved state?

5 Answers
5

Swiping apps out of the recent apps list is vanilla, and yes, not well documented. This has been the topic of a decent amount of discussion on various Android forums... the consensus seems to be best described here in some comments: that the behavior is similar to but not exactly the same as closing an app -- in general (for apps that don't define explicit back button handling) it's the same thing as hitting back enough times from within an application that you exit out of it.

The link has some more details on the specifics, but overall you can think of it as quitting the application.

Specific to the Music app, I believe it starts a service, so while the task itself (the Music app/UI) may be closed, the service continues to run in the background so that your music doesn't suddenly stop just because the task got cleared out for memory management reasons. That may have affected what you saw.

Thanks, that link has a lot of good discussion. You also might be right re: Music, that may have been a poor test. I'll try another app, just for kicks.
–
eldarerathis♦Feb 28 '12 at 15:28

2

Going to go ahead and accept this since the reddit discussion helped me find some better search terms, and seemed to be corroborated by some posts by Dianne Hackborn which I noted in my answer. Thanks!
–
eldarerathis♦Mar 16 '12 at 1:00

Third party music players like Rocket Player stops the music when you swipe the app from Recents list even if the service runs in the background and you need to open the app or play in widget again to start the music.
–
LuckyJul 6 at 12:04

It closes the app, and its data that is stored in the RAM. Thus, giving you more RAM space so you can run other apps. However, background services are NOT automatically force closed as a result of closing the using app.

Although written in everyday language, this is actually a fairly accurate answer - it captures the fact that the process is disposed of, something a lot of the other answers (those mistakenly comparing it to the back button) are missing. However, what is missing here is the realization that Android will dispose of processes when needed to obtain memory anyway, so while it accomplishes some memory cleanup, that would happen automatically if/when needed.
–
Chris StrattonJun 2 '14 at 14:27

I appear to have found the magical search terms that led to some explanations from Google employees. Specifically, I found a couple of different places where Dianne Hackborn explains what happens when you swipe something out of the recent list. The first is a comment on one of her Google+ posts:

Actually, removing an entry in recent tasks will kill any background
processes that exist for the process. It won't directly causes
services to stop, however there is an API for them to find out the
task was removed to decide if they want this to mean they should stop.
This is so that removing say the recent task of an e-mail app won't
cause it to stop checking for e-mail.

If you really want to completely stop an app, you can long press on
recent tasks to go to app info, and hit force stop there. For stop is
a complete kill of the app -- all processes are killed, all services
stopped, all notifications removed, all alarms removed, etc. The app
is not allowed to launch again until explicitly requested.

So, it looks like the summary is that swiping an app out of the list will first kill all background processes for the app, then use onTaskRemoved to notify the app that the background task was removed. At that point it looks like it's up to the app to decide what happens, so I guess there technically isn't a hard-and-fast rule about what happens to the app beyond that point.

"kill any background processes that exist for the process. It won't directly causes services to stop". Is this still true? I ran a test yesterday. Yesterday, I swiped away an app with a background service in the main process. The apps=>running UI showed 0 processes and 0 services. Later I swiped away the same app with a process running in a separate application specific process. The apps=>running UI said I had 0 processes and 1 service. That was on a Moto X(2014) with Android 4.4.4.
–
Steven WexlerMar 26 at 16:10

@StevenWexler: It could be that the service ended on its own in the first case but not the second, or it could be that in the second scenario the main process determined (for some reason) that it did not want to stop the service. Hard to know for certain.
–
eldarerathis♦Mar 26 at 20:31

If I read these correctly, there are specific handlers for selecting the apps but nothing special for swiping them except for onDetachedFromWindow(), which calls com.android.View.onDetachedFromWindow() which basically hides the element and clears it's data. This would hint to the fact that nothing special happens on swiping the app, which corresponds with Austin Mills' answer, because since the list doesn't show the active app, the onPause() and other system calls that are done when "quitting" an application have already happened.