13

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?

Thomas
  • 1,123
  • 3
  • 13
  • 36
  • 5
    Check Android Lifecyle on Android: http://stackoverflow.com/questions/8515936/android-activity-life-cycle-what-are-all-these-methods-for – Ziad Halabi Mar 30 '15 at 20:08
  • 1
    Possible duplicate of [Android onStop/onDestroy - when might these be used?](http://stackoverflow.com/questions/7236357/android-onstop-ondestroy-when-might-these-be-used) – salih kallai Mar 07 '16 at 14:53

2 Answers2

7

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).
Andrew Siplas
  • 875
  • 12
  • 16
GioLaq
  • 2,489
  • 21
  • 26
  • 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. – whoami Apr 27 '16 at 01:50
  • 2
    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. – Droid Teahouse Jan 07 '18 at 01:48
-7

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

CamHart
  • 3,825
  • 7
  • 33
  • 69
Elwin Streekstra
  • 15
  • 5
  • Not exactly. Those are *possibilities* but there is no guarantee that onStop() or onDestroy() will *ever* be called. – Chris Stratton Mar 30 '15 at 21:15
  • @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()` – Elwin Streekstra Mar 30 '15 at 21:17
  • 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. – Chris Stratton Mar 30 '15 at 21:21
  • @ChrisStratton You were right and wrong, according to http://developer.android.com/reference/android/app/Activity.html#onDestroy%28%29, only the onDestroy method is not always called. onPause, onStop, onResume etc. are always called – Elwin Streekstra Mar 30 '15 at 21:24
  • 2
    No, I was right about both of them. It is right there in the documentation of onStop() that the method may never be called. – Chris Stratton Mar 30 '15 at 22:03
  • 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. – Droid Teahouse Jan 07 '18 at 01:48
  • @ChrisStratton I'm failing to see that bit in the documentation--mind pointing it out? – CamHart Apr 27 '18 at 05:41
  • It looks like onStop is guaranteed to be called, see https://stackoverflow.com/questions/29395169/is-activity-onstop-guaranteed-to-be-called-api-11 – CamHart Apr 27 '18 at 05:51
  • 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. – Chris Stratton Apr 27 '18 at 13:42
  • @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.... – CamHart Apr 28 '18 at 05:07