onStop vs onDestroy

Question

I have tried to research exactly when the onDestroy method is called for an activity, but I've read some confusing and conflicting information. In general, my question is: under what circumstances is the onDestroy method actually called on an activity? More specifically, if I have two activities, activity A and activity B, if activity A is running and I create an intent and switch to activity B, is activity A only stopped, or is it destroyed?

Hermaphroditism

Check Android Lifecyle on Android: #8516436 – Archduke

Possible duplicate of Android onStop/onDestroy - when might these be used? – Irradiate

Answer 1

Like stated in the official documentation:

onDestroy()

The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.

In your example the Activity A is stopped and could be destroyed by the System

---

Note per documentation link above:

…do not count on [onDestroy()] being called as a place for saving data … [see] either onPause() or onSaveInstanceState(Bundle).

Hostage

Activity might not have been stopped unless the system has to recover memory for other task/process, it should be in the paused state generally. – Dingo

OnDestroy will be called directly from any call to finish() in onCreate, skipping over onStop. onDestroy can be left out after a kill when onStop returns. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned; pre-honeycomb onPause was the killable state. – Luisaluise

Answer 2

onDestroy() is called whenever:

• The user takes out the activity from the "recent apps" screen.
• The user takes out the activity from the "recent apps" screen.

onStop() is called whenever:

• The user leaves the current activity.

So in your example, when the user launches Activity B, Activity A called onStop().

EDIT: The onDestroy() method is not always being called, according to the documentation. onStop() is always called beginning with Honeycomb, so move code you explicitly need to do before the activity stops to there.

Starting with Honeycomb, an application is not in the killable state until its onStop() has returned. https://developer.android.com/reference/android/app/Activity#ActivityLifecycle

Hope this helped :D

Fults

Not exactly. Those are possibilities but there is no guarantee that onStop() or onDestroy() will ever be called. – Lookeron

@ChrisStratton If you use @Override before the method, it is guaranteed to run the code in that specific method, in this case onStop() and onDestroy() – Fults

No, it isn't. See the documentation. The system is free to merely kill the process without bothering to call these methods. Generally it will call them, but the docs say it is free not to. – Lookeron

@ChrisStratton You were right and wrong, according to developer.android.com/reference/android/app/…, only the onDestroy method is not always called. onPause, onStop, onResume etc. are always called – Fults

No, I was right about both of them. It is right there in the documentation of onStop() that the method may never be called. – Lookeron

OnDestroy will be called directly from any call to finish() in onCreate, skipping over onStop. onDestroy can be left out after a kill when onStop returns. Starting with Honeycomb, an application is not in the killable state until its onStop() has returned; pre-honeycomb onPause was the killable state. – Luisaluise

@ChrisStratton I'm failing to see that bit in the documentation--mind pointing it out? – Metalworking

It looks like onStop is guaranteed to be called, see #29395669 – Metalworking

No, you are misunderstanding the meaning. During an orderly shutdown it will be called, but it is entirely possible for the process to be killed without it being called. Consider for example the idea that it cannot be killed until it returns from the method - that does not mean that by not returning from a method the process can become immortal. These methods are clues to preserving a smooth user experience only, they are not actual guarantees as such cannot be supported by the operating system. – Lookeron

@ChrisStratton It's not in a killable state until after onStop returns, atleast according to documentation. And maybe the word "guarantee" is whats causing the mixup. To me, 99.999999% of the time is "guaranteed", even though that doesn't fit the actual definition. It seems like you're arguing theres always a tiny chance it wont happen, but that's true for any software anywhere.... – Metalworking