Differentiate between Android killing the app and user swiping it off on the recent apps list

Question

I am working on a project, where while being on a specific Activity we show a local sticky notification. That should also be the case when the app is minimized. What I have to accomplish is to remove the local notification whenever the app is killed (by Android, because of memory lack or by the user, with a swipe from the recent apps list).

Usually onDestroy would be called whenever Android takes the Activity to open some space. That is fine in one of the cases, however swiping an app from the recent app lists doesn't call the onDestroy and the sticky notification stays.

What I did is, I implemented an empty Service which would force the onDestroy when the app is killed (both swipe and system kill) so I can get my notification removed.

However, what I would like to do is to differentiate between the swipes and system kill.

Is this even possible?

Answer 1

In general, if Android wants to kill your application because it has been in the background for too long (or because it wants to reclaim resources), Android will just simply kill the OS process hosting your app. It will not call finish() or onDestroy() on any Activity or Service components. The behaviour of "swipe from recent tasks list" has changed over time and is different in different Android versions. Someone should write a book about that :-(

Answer 2

您可以通过向应用添加服务以及实施onTaskRemoved方法来检查用户何时滑动关闭应用程序： https ： onTaskRemoved

Answer 3

This is a comment I found in reddit that seems to me really interesting:

Swiping an app away will effectively "kill" most apps. You can test this out using ADB if you have the SDK installed. Swipe everything out of your recents list, then launch the browser.

Use ADB to run 'ps' on the device and verify that the com.google.android.browser process is running. Go to the home screen, it's still running. Launch some other apps, and the com.google.android.browser process is still there.

Swipe it out of the recents list, however, and the process is gone. You can create a test app to further verify, and log the onDestroy () call in your Activity. It's not called when you back or home out of the app, or when you launch other apps. It does get called when you swipe the app out of the recents list though. I do agree that the recent apps list isn't really "multitasking".

The apps in the list aren't necessarily even running, the processes could have been killed by the memory manager long before you try to re-open it. However, you can't argue that the only purpose is to jump quickly to other apps when the swiping makes the actual process go away.

This is another good answer about what happen when you swipe an app out of the recent apps list. But the part that I liked most was:

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.

Answer 4

By Swiping from recent task list removes only from recent tasks .. It was also called onDestroy before android 5.0 . Might be you are having issue above api level 20 devices. System kill normally can not be executed in normal android activity lifecycle. It just finishes the activity on back press event.

Answer 5

当应用程序向左滑动时，如果任何线程仍在您的应用程序中运行中断但服务未停止，当您杀死方便的应用程序线程和服务停止。

Answer 6

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. check out this link discussion it has some good input on the subject

Answer 7

First, let's get one thing clear: Android MAY NOT CALL onDestroy() . Referring to the Activity Page , from Honeycomb onward, onPause() and onStop() are guaranteed to be called before an app is killed.

Be aware that these semantics will change slightly between applications targeting platforms starting with HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned. This impacts when onSaveInstanceState(Bundle) may be called (it may be safely called after onPause() and allows and application to safely wait until onStop() to save persistent state.

So after (hopefully) clearing the air on the Android lifecycle, I think you can achieve what you want by putting the notification removing code in onStop() instead. If you end up needing it back because the user actually DOES come back to the specific Actvitiy (IE not killed), you can bring it back in onRestart() .