Develop Reference

Difference between closing app via back button and clearing it from recents list?

My app uses a DefaultHttpClient to make network requests. On occasion (usually after resuming the app after a long period of time) the app will stop loading data and I need to clear it from the recent apps list before it loads content again.
My question is, what's the difference between:
- Closing an app by tapping the back button
- Clearing the app from the recent app list
When my app stops loading content, exiting via the back button and reopening does not fix the problem. Only killing the app by clearing it from the recent app list works.
Is there a way to "kill" the app when a user exits with the back button?
Thanks

Closing an app by tapping the back button
Pressing the BACK button, by default, destroys whatever the foreground activity is, returning control to the previous activity (or the home screen if there is no previous activity). It does not "close" an app.
Clearing the app from the recent app list
Usually, this will terminate the app's process. Contrast that with pressing BACK to destroy all of your activities, where the process remains running (at least for a while).
Is there a way to "kill" the app when a user exits with the back button?
Not really. You are better served fixing the bugs in your app.
usually after resuming the app after a long period of time
If "a long period of time" is less than 30 minutes or so, your process may have been terminated while your app was in the background, but Android will try to return the user to wherever the user had been in your app. This involves forking a fresh process for you and recreating your last activity. Sometimes, developers make assumptions that their process always starts with the launcher activity, with bugs being uncovered when the process starts with some other activity.
Also note that the HttpClient implementation in the Android SDK was deprecated in API Level 22 and removed in API Level 23. Either use an independent packaging of HttpClient or use some other HTTP client API (HttpURLConnection, OkHttp, etc.).

when you press back button then onBackpress() calls and app exit by normal actitvy life cycle and you can override onBackpress() (such that some apps give message that press again to exit) and do anything programmatic such that save any data or clear shared preference etc and when you clear it recent list then OS kills the app ,free the resources and there is no guaranty that activity life cycle proceed correctly such that some times onDestroy() not call. so basicly back press is part of our app and application self close by finish() method on other hand clear recent list is part of OS which forcefully kills the app
https://developer.android.com/guide/components/tasks-and-back-stack.html
follow this offical android link for more details

Is there a way to "kill" the app when a user exits with the back
button?
For the sake of curiosity, there is. its System.exit(0). What will happen if you execute this? The VM stops further execution and program(Activity) will be exit/killed right away.
NEVER DO THIS! There is a good chance your app will loose some data if its doing something while you trigger System.exit(0).

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

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?

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 :-(

You can check for when the user swipe-closes the app by adding a service to your app, and implementing the onTaskRemoved method: https://stackoverflow.com/a/26882533/2441655

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.

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.

when swiping app to left if any Thread still run in your app Interrupted but service not stopped, when you kill handy app Thread and services are stopped.

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

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().

activity's life cycle is beyond its application process?

I got a main-activity, then it opened a new-activity. After putting it to background by clicking home button. If I killed the process using adb shell commands, then I reopen my app.
The new-activity is shown by default instead of starting from the first activity.
My question is that activity's life cycle is beyond its application process?
As the sample shows, even activity's application process is killed, the saved activity still is there. Is this correct? And will android system recycle the saved activities later?

If you reopen the app via the activities list, it will attempt to restart via the last open activity. It's a "feature" of Android that can be incredibly annoying (and frequently just wrong)- Android assumes every app can serialize its entire state when exited for later reopening. You either need to do that (via onSaveInstanceState and onRestoreInstanceState) or you need to catch when you're relaunched and explicity launch your main activity.
This shouldn't happen if you're relaunched via the app launcher, as that should always launch your specified activity.

Android remembers the state of recent tasks and activities. Android can kill your application's process at any time (if it is in the background). If your application was killed while in the background, Android remembers what activities were in the task and how they were started (Intents). If the user now returns to the task (either by selecting from the list of recent tasks, or by tapping the application's icon in the list of applications), Android will create a new process for the task and recreate the activity that was on the top of the stack (ie: the activity that was in front when the task was sent to the background). This allows users to open an applicaton, use it, leave it to do something else, and then return to the application where they left off.
In order for this to work properly, you must save and restore any necessary state (using onSaveInstanceState() and onRestoreInstanceState().
If a task goes to the background and is idle (unused) for some period of time (device manufacturers can change this, usually the value is something like 30 or 60 minutes), Android will reset the task. In this case, if the user returns to the task, the previous saved state will be ignored and the user will start from the beginning. However you can prevent this from happening by setting alwaysRetainTaskState="true" on the root (starting) activity.

Android lifecycle weirdness with singleTop and foreground service?

Here's the scenario:
Start Activity A
Activity A starts service S
Service S runs in foreground mode and shows up a notification which when pressed takes the user to Activity B (which has launchMode="singleTop")
Activity B shows up
Press HOME
Go into DDMS and kill your application process to simulate that your app died (press red STOP button)
Android will say "Rescheduling crashed service in 5000ms" (sometimes longer)
Service S restarts and notification is shown.
Press the notification icon when the service restarts...
...at this time, Android will recover both Activities A and B due to the fact the process ended unexpectedly. But despite the fact Activity B is singleTop android will spawn it AGAIN because the user clicked on the notification. This results into having A -> B -> B on the activity stack. Pressing back will take you again onto the first recovered instance of Activity B.
Can someone from the Android team clarify what is happening behind the scenes and how to avoid this? What is the best way to simulate that Android killed the process due to low memory? Is pressing STOP from DDMS good enough or an edge case and this should never happen under normal circumstances?
What is the difference between 'Force Stop' from Settings --> Applications versus STOP from DDMS?
Thanks in advance!

This behavior should not change based on whether or not the process is killed. The activity manager first looks through the server-side stack to decide what to do, and once the stack has been adjusted appropriately it resumes whatever is now at the top of the stack.
Check your app to make sure it is not calling startActivity() when re-initializing or doing something else like that. Look in the log to see what activities are being started and the intents being used. Use "adb shell dumpsys activity" to see what the current activity stack looks like. Maybe you have cleared the task affinity, so the second activity B is being started in its own task (in which case singleTop would have no impact)?
Also it is really hard to help people if you don't include useful details about what you are doing. The relevant log statements at the different steps, the state of the activity stack shown by "adb shell dumpsys activity", etc.

I am not too sure about the detailed differences between STOP in DDMS and Force Stop, but I am pretty sure DDMS bypasses some internal Android functionality that Force Stop would perform since I do not remember Android ever reinitializing my activities when i did a Force Stop. If this is true, then I am suspecting that what you are seeing is the result of two different tasks started by Android: one for the old, killed activities and another for when the killed service restarts. You can test this theory by setting the flag to "singleTask" and checking if the same behaviour occurs. Hope this helps.

Having A -> B -> B is possible even while B is singleTop: for situation when B is launched as other task. In the case there are actually 2 stacks: A -> B and B

why does android 'revives' crashing apps?

if you have an android app that has more than one Activity, and Activity A starts B, so if Activity b crashes the process is killed but is revived by android OS and starts Activity A again instead of just shutting down the app, why ?

You're complaining that Android will attempt to recover your app's state gracefully after a crash? ;)
This is the result of Android's resource management and the Activity lifecycle at work. Keep in mind that a single task can be composed of a number of Activities that may span several processes or apps. As outlined here: http://android-developers.blogspot.com/2010/04/multitasking-android-way.html Android processes don't shut down "cleanly" in the traditional *nix process sense. Your app's components receive lifecycle events but after a certain point the app can be killed without further warning so that the system may reclaim its resources.
For example, a user might be browsing the web, click a youtube link launching the youtube app, then click a share button to launch their favorite social networking app and post the video link. This is all part of the same task; if the user presses back several times they'll come back to the page in the browser that they started from.
Once you start up the social networking app, the system might decide that it's running low on memory and it's going to kill off the browser's process to free up more. (After all, it's not in front and the user won't notice.) When the user presses the back button to return to the browser Activity it gets restarted and reconstructs the last state where the user left it. At worst the user experiences a short delay while things reinitialize.
But this same sequence of events restoring a previous Activity state can happen even within the same app in the same process. In your scenario, Activity B closed as the result of the crash. So the system does exactly what it always does - it returns to the previous Activity: Activity A. But Activity A's process isn't still around (it crashed!) so the system restarts it and it can reconstruct its previous state.