App loses its ability to remember its stack when launched from another application

Question

Now that I have researched this even more I am rewriting this to make it clearer. If you are looking for more info, there is some available in older edits.

What is happening:

(This refers to an application that has not set any launchMode settings and so is using the defaults)

1. You launch an app from the Market or from the Installer. This launches the root/main activity of the application with the FLAG_ACTIVITY_NEW_TASK flag and no categories. Right now the applications stack is [ A ]

2. Then you proceed to the next activity in the application. Now the stack in this task is [ A > B ]

3. Then you press the home key and then relaunch the same application by pressing it's icon from either the home screen or the app tray.

4. What is expected at this point is that activity B will show, since that is where you left off. However A is shown and the tasks stack is [ A > B > A ] This second instance of A is launched with the following flags: FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_RESET_IF_NEEDED, and FLAG_ACTIVITY_BROUGHT_TO_FRONT. It also has the android.intent.category.LAUNCHER category.

At this point, if you hit the back key, it will return you to B, as it was when you left it.

Looking at the documentation it seems as if FLAG_ACTIVITY_BROUGHT_TO_FRONT should only be set for activities that use the singleTask or singleTop launchModes. However, this application has not set any launchModes and is therefore using the default standard launchMode.

I assume this is not suppose to happen in this case?

I should also note, that once it gets into this weird state, then it happens everytime the app is launched from the home screen or app tray. If the task is finished (restarting the phone, force stopping the app, or hitting back all the way through the stack) will fix this issue and will no longer launch it incorrectly. It only happens if you launch the app from the installer or market and then try to launch it from the launcher.

So in summary, why is this happening? Is there a way to prevent it?

Answer 1

Here is a workaround I have come up with so far. Some other workarounds I have seen involved looking at the currently running tasks. However, I really did not want to have to ask for another permission (GET_TASKS) from the user just to make a work around.

Please let me know if you see any holes in this.

In the main/root activity's onCreate method, check if the intent has the FLAG_ACTIVITY_BROUGHT_TO_FRONT set and if so, call finish(). This then pops the extra instance of A off the stack [ A > B > A ] becomes [ A > B ] and from the users perspective, it launches into the activity they were expecting.

It seems to work in all of my tests so far. My only worry is that if there is some weird case where someones launcher would always flag a launch with FLAG_ACTIVITY_BROUGHT_TO_FRONT even if the app wasn't already in a task, and therefore would completely lock them out because it would call finish() and not have anything in the stack to return to.

--

As requested in the comments here is how you can check if an intent a specific flag:

int flags = intent.getFlags();
boolean hasFlag = flags & Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT == Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT;

--

Also I should note that I am still seeing this problem occur sometimes with this fix in place. It doesn't seem to be a perfect solution.

Answer 2

Overriding of onConfigurationChanged() should help you to retain the state.

http://developer.android.com/reference/android/app/Activity.html

Configuration Changes

If the configuration of the device (as defined by the Resources.Configuration class) changes, then anything displaying a user interface will need to update to match that configuration. Because Activity is the primary mechanism for interacting with the user, it includes special support for handling configuration changes.

Unless you specify otherwise, a configuration change (such as a change in screen orientation, language, input devices, etc) will cause your current activity to be destroyed, going through the normal activity lifecycle process of onPause(), onStop(), and onDestroy() as appropriate. If the activity had been in the foreground or visible to the user, once onDestroy() is called in that instance then a new instance of the activity will be created, with whatever savedInstanceState the previous instance had generated from onSaveInstanceState(Bundle).

This is done because any application resource, including layout files, can change based on any configuration value. Thus the only safe way to handle a configuration change is to re-retrieve all resources, including layouts, drawables, and strings. Because activities must already know how to save their state and re-create themselves from that state, this is a convenient way to have an activity restart itself with a new configuration.

In some special cases, you may want to bypass restarting of your activity based on one or more types of configuration changes. This is done with the android:configChanges attribute in its manifest. For any types of configuration changes you say that you handle there, you will receive a call to your current activity's onConfigurationChanged(Configuration) method instead of being restarted. If a configuration change involves any that you do not handle, however, the activity will still be restarted and onConfigurationChanged(Configuration) will not be called."