Is Activity.onStop() guaranteed to be called (API 11 +)

Question

It is unclear (to me, at least) from the documentation whether Activity.onStop is guaranteed to be called. There are two places with seemingly contradictory information.

1. Javadoc for Activity.onStop:

Note that this method may never be called, in low memory situations where the system does not have enough memory to keep your activity's process running after its onPause() method is called.

2. Documentation (in particular 'Killable' column) for Activity class http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle:

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.

It's a bit of a struggle to find a way that both pieces of documentation are telling the truth. The only scenario I can think of is this: Suppose you are developing on target API 21 (with min sdk 10) and write an Activity with an onStop() method. If you then run this application on an API 10 phone, onStop() is not guaranteed to be called. This scenario means that the documentation from points 1. and 2. above are both true. Otherwise, one of them must be false.

Answer 1

Is Activity.onStop() guaranteed to be called (API 11 +)

Yes, it is guaranteed to be called on post-Honeycomb devices (API 11 +)

Source 1: Video tutorial on Activity life cycle - taught by Google developer advocate

Source 2: https://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Source 3: AndroidLifeCycle article on www.vogella.com

Answer 2

If you look further down in the ActivityLifeCycle reference, it says:

For those methods that are not marked as being killable, the activity's process will not be killed by the system starting from the time the method is called and continuing after it returns. Thus an activity is in the killable state, for example, between after onPause() to the start of onResume().

Since this appears to re-inforce point #1, I would err on the conservative side and design and plan my code as if point #1 were true and ignore point #2.