When exactly are onSaveInstanceState() and onRestoreInstanceState() called?

The following figure (from the official doc) describes the well-known lifecycle of an Android activity:

On the other hand, when the activity is destroyed by the system (for example because memory needs to be reclaimed), the state of the activity is sometimes automatically saved and restored by means of the methods onSaveInstanceState() and onRestoreInstanceState(), as illustrated by the following figure (also from the official doc):

I'm aware that onSaveInstanceState() is not always called when an activity is about to be destroyed. For example, if it is destroyed because the user has pressed the "back" button, the activity state is not preserved. But in the cases when the state is saved and restored, and onSaveInstanceState() / onRestoreInstanceState() get called, when exactly are they called?

For example, according to the above figures, onRestoreInstanceState() might be called before onStart(), or after onStart() but before onResume(), or after onResume(). Similarly, several possibilities exist for onSaveInstanceState(). So when are they called exactly?

Ideally, what I would like is to see a combined diagram showing the activity lifecycle states and the save/restore methods, if that exists.

Per the documentation:

void onRestoreInstanceState (Bundle savedInstanceState)

This method is called between onStart() and onPostCreate(Bundle).

void onSaveInstanceState (Bundle outState)

If called, this method will occur after onStop() for applications targeting platforms starting with Build.VERSION_CODES.P. For applications targeting earlier platform versions this method will occur before onStop() and there are no guarantees about whether it will occur before or after onPause().

As per doc1 and doc2

onSaveInstanceState

Prior to Honeycomb, activities were not considered killable until after they had been paused, meaning that onSaveInstanceState() was called immediately before onPause(). Beginning with Honeycomb, however, Activities are considered to be killable only after they have been stopped, meaning that onSaveInstanceState() will now be called before onStop() instead of immediately before onPause().

onRestoreInstanceState

This method is called between onStart() and onPostCreate(Bundle) when the activity is being re-initialized from a previously saved state

In addition to already posted answers, there is a subtle change introduced in Android P, which is:

void onSaveInstanceState(Bundle outState)

If called, this method will occur AFTER onStop() for applications targeting platforms starting with P. For applications targeting earlier platform versions this method will occur before onStop() and there are no guarantees about whether it will occur before or after onPause().

Source: docs

As to why this change is introduced, here's the answer:

... so an application may safely perform fragment transactions in onStop() and will be able to save persistent state later.

Source: docs

This is an extra information for onSaveInstanceState(Bundle)

from docs

Do not confuse this method with activity lifecycle callbacks such as onPause(), which is always called when an activity is being placed in the background or on its way to destruction, or onStop() which is called before destruction. One example of when onPause() and onStop() is called and not this method is when a user navigates back from activity B to activity A: there is no need to call onSaveInstanceState(Bundle) on B because that particular instance will never be restored, so the system avoids calling it. An example when onPause() is called and not onSaveInstanceState(Bundle) is when activity B is launched in front of activity A: the system may avoid calling onSaveInstanceState(Bundle) on activity A if it isn't killed during the lifetime of B since the state of the user interface of A will stay intact.

So it's default implementation for..

The default implementation takes care of most of the UI per-instance state for you by calling onSaveInstanceState() on each view in the hierarchy that has an id, and by saving the id of the currently focused view (all of which is restored by the default implementation of onRestoreInstanceState(Bundle)). If you override this method to save additional information not captured by each individual view, you will likely want to call through to the default implementation, otherwise be prepared to save all of the state of each view yourself.

String activityState;
@Override 
public void onCreate(Bundle savedInstanceState) {
// call the super class onCreate to complete the creation of activity like 
// the view hierarchy 
super.onCreate(savedInstanceState);

// recovering the instance state 
if (savedInstanceState != null) {
     activityState = savedInstanceState.getString(STATE_KEY);
 } 

   setContentView(R.layout.main_activity);
   mTextView = (TextView) findViewById(R.id.text_view);
} 

//This callback is called only when there is a saved instance previously saved using //onSaveInstanceState(). We restore some state in onCreate() while we can optionally restore // other state here, possibly usable after onStart() has completed. // The savedInstanceState Bundle is same as the one used in onCreate().

@Override 
public void onRestoreInstanceState(Bundle savedInstanceState) {
 mTextView.setText(savedInstanceState.getString(STATE_KEY));
  } 


// invoked when the activity may be temporarily destroyed, save the instance 
//state here 
//this method will be called before onstop

@Override 
 public void onSaveInstanceState(Bundle outState) {
    outState.putString(STATE_KEY, activityState);

    // call superclass to save any view hierarchy 
    super.onSaveInstanceState(outState);
}