Android: Scenario where onPause is called but not onStop?

I figured this out a while later, but forgot to post my answer here.

The instance where I noticed that onPause() was called, without an immediate subsequent call to onStop() was when I got a notification from a different application when a different app was open on my phone.

For example, say you have Facebook running on your phone currently. If you receive a notification from WhatsApp (in the pop-up dialog box), your Facebook activity will be paused. If you close the WhatsApp pop-up during this time, the Facebook Activity will get Resumed. On the other hand, if you open WhatsApp from the pop-up message, your Facebook Activity will be stopped.

Activity A --> Activity B If B is transparent, A' onPause will be called but no onStop.

This scenario occurs when you start a DialogActivity from your current activity, then the onPause() of current activity is called and after coming on current Activity the onResume() is called.

For more information, please see Developer Docs.

The official Android Developers page you can see all the information relating to these two states of activity

onPause() (http://developer.android.com/training/basics/activity-lifecycle/pausing.html)

When the system calls onPause() for your activity, it technically means your activity is still partially visible, but most often is an indication that the user is leaving the activity and it will soon enter the Stopped state. You should usually use the onPause() callback to:

Stop animations or other ongoing actions that could consume CPU. Commit unsaved changes, but only if users expect such changes to be permanently saved when they leave (such as a draft email). Release system resources, such as broadcast receivers, handles to sensors (like GPS), or any resources that may affect battery life while your activity is paused and the user does not need them.

Generally, you should not use onPause() to store user changes (such as personal information entered into a form) to permanent storage. The only time you should persist user changes to permanent storage within onPause() is when you're certain users expect the changes to be auto-saved (such as when drafting an email). However, you should avoid performing CPU-intensive work during onPause(), such as writing to a database, because it can slow the visible transition to the next activity (you should instead perform heavy-load shutdown operations during onStop()).

You should keep the amount of operations done in the onPause() method relatively simple in order to allow for a speedy transition to the user's next destination if your activity is actually being stopped.

Note: When your activity is paused, the Activity instance is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state.

onStop() (http://developer.android.com/training/basics/activity-lifecycle/stopping.html)

When your activity receives a call to the onStop() method, it's no longer visible and should release almost all resources that aren't needed while the user is not using it. Once your activity is stopped, the system might destroy the instance if it needs to recover system memory. In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback, so it's important you use onStop() to release resources that might leak memory.

Although the onPause() method is called before onStop(), you should use onStop() to perform larger, more CPU intensive shut-down operations, such as writing information to a database.

When your activity is stopped, the Activity object is kept resident in memory and is recalled when the activity resumes. You don’t need to re-initialize components that were created during any of the callback methods leading up to the Resumed state. The system also keeps track of the current state for each View in the layout, so if the user entered text into an EditText widget, that content is retained so you don't need to save and restore it.

Note: Even if the system destroys your activity while it's stopped, it still retains the state of the View objects (such as text in an EditText) in a Bundle (a blob of key-value pairs) and restores them if the user navigates back to the same instance of the activity (the next lesson talks more about using a Bundle to save other state data in case your activity is destroyed and recreated).