153

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?

Improve this question

5 Answers 5

Reset to default
70

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.

Improve this answer
3
83

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:

[W]hat specifically happens when you swipe away a recent task is it: (1) kills any background or empty processes of the application (see https://developer.android.com/guide/topics/fundamentals/processes-and-threads.html#Lifecycle for what this means), and (2) uses the new https://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent) API to tell any services of the application about the task being removed so it can do whatever it thinks is appropriate.

She also notes in a blog comment:

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.

Improve this answer
3
  • "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 Wexler
    Commented Mar 26, 2015 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
    Commented Mar 26, 2015 at 20:31
  • started service starts automatically again after swiping out from recent list, its onCreate called again. but in some apps onCreate called before onTaskRemoved and in some its called after onTaskRemoved. why this behavior is then ?
    – umesh
    Commented Aug 26, 2015 at 9:06
23
+250

There's some info in the source code in the classes com.android.internal.policy.impl.RecentApplicationsBackground and com.android.internal.policy.impl.RecentApplicationsDialog.

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.

Improve this answer
0
10

I think it will do the same as the back button do. Except one little change. It will finish() all activity / fragments in the app.

Just did a little testing with a little selfbuild app. You can test, too. Heres my testing app: https://bitbucket.org/Leandros99/lifecycletest (download available, too. For those who cant build.)
In every Activity lifecycle method (https://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle) print the app a log. You can view it with adb logcat (install Android SDK, cd to platform-tools in cmd / shell and type adb logcat. Now you will see, every time you do something like hit back or home button, the app prints the lifecycle method, mentioned above.)

Your question: If I swipe a app from the recent apps drawer, the onDestroy method will be called. It does nearly the same as the back button.
Hope I helped a bit. If there are questions, just ask.

Improve this answer
4

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.

Improve this answer
1
  • 1
    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 Stratton
    Commented Jun 2, 2014 at 14:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .