Question on Application Lifecycle and onSaveInstanceState

My application interacts with the Browser in a couple of use cases:

First Case:

1. Start MyApplication ActivityA from launcher.
2. Start MyApplication ActivityB using startActivityForResult (ActivityA's onSaveInstanceState is called).
3. Start Browser using startActivity (ActivityB's onSaveInstanceState is called).
4. Close browser or press Back. ActivityB is restored from the saved instance state bundle.

Second Case:

1. Start MyApplication ActivityA from launcher.
2. Start Browser using startActivity (ActivityA's onSaveInstanceState is called).
3. Browser calls back MyApplication ActivityA (i have no control over how the browser calls back, as in what flags are using for starting the activity. How it calls back is that i am passing it a callback URL (Google OAuth callback URL), and i have an intent filter in my ActivityA to intercept that URL.)
4. Start MyApplication ActivityB using startActivityForResult (ActivityA's onSaveInstanceState is called).
5. Start Browser using startActivity (ActivityB's onSaveInstanceState is NOT called).
6. Close browser or press Back. ActivityB can't fully be restored, because onSaveInstanceState isn't called in the previous step.

My questions would be related to step 5 of the second case, where the onSaveInstanceState is NOT called.

Reading through the Android fundamentals on lifecycle, as well as the onSaveInstanceState API, i sort of understand why it was not called. This is from the API for onSaveInstanceState:

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.

i.e. Because the flow is like

ActivityA -> Browser -> ActivityA -> ActivityB -> Browser

since there is already a pri开发者_开发百科or Browser activity, ActivityB is deemed to be navigating back to the Browser, hence onSaveInstanceState is not called.

1. Am i correct with the understanding above?

2. In this case, should i really be using onPause instead of onSaveInstanceState? (From a laziness point-of-view, onSaveInstanceState is much simpler because i can just dump stuffs into the bundle instead of having to design/create a SQLite table which i'll have to do for onPause.) But what is the best practice for this?

3. It would seem then, if i am correct on 1 and 2, that saving state using onPause is much more robust than using onSaveInstanceState. What cases then, should we really be using onSaveInstanceState instead of onPause?