onDestroy() while "waiting" for onActivityResult()

Question

I have an app with two activities: "A" and "B".

"A" uses startActivityForResult() to spawn "B" i.e. it waits for "B". Now, assume that "B" is in foreground. Can the Android system destroy activity "A" without also destroying "B"? (If yes, then when "B"is finished e.g. after user input, activity "A" must be recreated and put to the foreground again by the Android system, and I need to remember and restore "A" to its earlier UI status.)

Note that I'm not talking about process kill (which is different case: if a process is killed, all activities are killed and onDestroy() is not called or not guaranteed to be called). The question is merely about whether onDestroy() is possible while waiting for the result of a subactivity.

Cooperative

Answer 1

If Activity A gets killed by the time B finishes, you are guaranteed that

1. A will be re-created.
2. A will deliver the result.

In other words, A will be re-created the next time the user visits/needs it, and at that point any pending results will be delivered (from B to A).

Also note that this is why results must be returned through a single Activity callback with an integer request code, instead of an arbitrary callback object.

Kassiekassity

Thanks, that is exactly how I thought it too, provided an onDestroy can happen. So you say it can happen to "A". In this case, however, "A" will restart i.e. I get an onCreate() too (and then, as the docs say, I get the result before onResume()), so I need to restore the earlier UI state of "A", right? I mean, "B" is started in a particular submenu of "A", so the user expects that the UI state of "A" is the same when "B" ends as it was when "B" was started. (I.e. "A" is in the same submenu as when "B" was started.)If yes, I need to persist the UI state of "A" as well before "B" is spawned. – Cooperative

Correct me if I'm misinterpreting your question, but it seems that you are asking a more general question about the Activity lifecycle that has nothing to do with startActivityForResult. You are guaranteed that the result will be passed from B to A (whether A is destroyed or not), but this doesn't mean that the Activity's state is preserved. If onDestroy has been called, then you might want to restore its state when it is re-created in onRestoreInstanceState (or onResume), as is the case with any other Activity you will encounter. – Kassiekassity

I hope these two points will make it more clear: 1. It has to do with startActivityForResult, because I couldn't be sure if it sets an additional constraint i.e. while in general "A" can be destroyed, perhaps it isn't so if it's waiting for a result from "B". (I.e. in such a case, the "worst" it can get is an onStop()). But, based on your answer, destroying of "B" can happen in this case too. (Of course, in case of activities in different processes, it is obvious that independent destroying is possible, but in my case they're in the same app/process). – Cooperative

2. I do persist and restore my logic state, but not UI state. My philosophy (which suits the world of my app) is that the app (game) always starts in the main menu if it has started with onCreate(), and the player can resume gameplay from there. So I restore UI state only when onStart and onResume happens, but in this case, UI state is in memory (unlike game logic state, which I always persist). But starting activity "B" (which is NOT the gameplay btw) is an exception, i.e. I want that when "B" is ended, "A" always returns to its UI state which was present when "B" was started. – Cooperative

(I apologize for the third post, but I couldn't edit my second comment). For my second comment, this is the corrected sentence: "But, based on your answer, destroying of "A" can happen in this case too" – Cooperative

@AlexLockwood IF activity A gets killed. But can it get killed if there is no configuration change (app is in portrait mode and I assume the user doesn't change his language just for fun) ? Looking at this thread I understand that it cannot. Looking at some crashlytics reports it seems it can – Orphaorphan