App restarts rather than resumes

I've read many answer that sound similar to my problem but simply adding android:alwaysRetainTaskState="true" or using launchMode="singleTop" to the Activity are not the answer.

Edit:

After the most recent launch of this app, we find that this behaviour has begun to occur on all devices after the first restart. Which seems crazy to me but looking through the restart process, I can't actually find what's going wrong.

This may seem like a trivial question to ask, but did you set "Don't keep activities" to true in your develop options for the Xoom?

Nope (I wish! :)) - I've logged the lifecycle of each Activity and the Activities in the background as still available (They're stopped - not destroyed). The OS seems to call finish() on them in instances where it begins the first Activity again instead of resuming them.

If you have pressed the home button and then click the launcher icon the resume behaviour is the default for android as you are probably aware. However if you press the back button to return to the home screen most phones will finish() the app. Is it possible whatever method you are using to exit the app is different on the different devices? Could you log out the onKeyUpEvent to check that some aren't handling the hard/sof tkeys strangely?

Nope - I'm sure of the problem as stated above. Using home to put the app in the background (not back, which you're right would finish() the Activity). It's possible on the Xoom to resume the app from the Task List (just not from the Launcher) so the backstack has definitely not been killed.

Answer with the bounty is the way to fix the problem described in the question. Marked my own answer as "correct" because although sometimes the problem is caused by an app bug in the launcher (as noted in his answer) my particular problem was caused by Task switching. The solution to both problem is fixed by his solution.

10 Answers 10

The behavior you are experiencing is caused by an issue that exists in some Android launchers since API 1. You can find details about the bug as well as possible solutions here: https://code.google.com/p/android/issues/detail?id=2373.

It's a relatively common issue on Samsung devices as well as other manufacturers that use a custom launcher/skin. I haven't seen the issue occur on a stock Android launcher.

Basically, the app is not actually restarting completely, but your launch Activity is being started and added to the top of the Activity stack when the app is being resumed by the launcher. You can confirm this is the case by clicking the back button when you resume the app and are shown the launch Activity. You should then be brought to the Activity that you expected to be shown when you resumed the app.

The workaround I chose to implement to resolve this issue is to check for the Intent.CATEGORY_LAUNCHER category and Intent.ACTION_MAIN action in the intent that starts the initial Activity. If those two flags are present and the Activity is not at the root of the task (meaning the app was already running), then I call finish() on the initial Activity. That exact solution may not work for you, but something similar should.

Here is what I do in onCreate() of the initial/launch Activity:

 if (!isTaskRoot() && getIntent().hasCategory(Intent.CATEGORY_LAUNCHER) && getIntent().getAction() != null && getIntent().getAction().equals(Intent.ACTION_MAIN))

Implemented this solution and it definitely helps. Also used this in conjunction with 'Intent resumeIntent = context.getPackageManager().getLaunchIntentForPackage(context.getPackageName()); resumeIntent.setAction(Intent.ACTION_MAIN); resumeIntent.addCategory(Intent.CATEGORY_LAUNCHER); context.startActivity(resumeIntent);' code to resume the current task and then build upon it from static context. Very very useful.

So far this works for me with no adverse side effects so far. Based on the logical assumptions, I see no reason why it isn't valid.

I was confronted with the same issue on a Nexus 4.Tried this and it definitely works. Thank you very much for the answer.

It can be null only in 2 cases that are almost impossible here, just added a suggestion to prevent event them. stackoverflow.com/questions/37856407/…

This question is still relevant in 2016. Today a QA tester reported an app of mine restarting rather than resuming from the stock launcher in Android M.

In reality, the system was adding the launched activity to the current task-stack, but it appeared to the user as if a restart had occurred and they'd lost their work. The sequence was:

1. Download from play store (or sideload apk)
2. Launch app from play store dialog: activity A appears [task stack: A]
3. Navigate to activity B [task stack: A -> B]
4. Press 'Home' button
5. Launch app from app drawer: activity A appears! [task stack: A -> B -> A] (user could press 'Back' button to get to activity 'B' from here)

Note: this problem does not manifest for debug APK's deployed via ADB, only in APKs downloaded from the Play Store or side-loaded. In the latter cases, the launch intent from step 5 contained the flag Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT , but not in the debug cases. The problem goes away once the the app has been cold-started from the launcher. My suspicion is the Task is seeded with a malformed (more accurately, non-standard) Intent that prevents the correct launch behavior until the task is cleared entirely.

I tried various activity launch modes, but those settings deviate too much from standard behavior the user would expect: resuming the task at activity B. See the following definition of expected behavior in the guide to Tasks and Back Stack, at the bottom of the page under 'Starting a Task':

An intent filter of this kind causes an icon and label for the activity to be displayed in the application launcher, giving users a way to launch the activity and to return to the task that it creates any time after it has been launched.

I found this answer to be relevant and inserted the following into the 'onCreate' method of my root activity (A) so that it resumes appropriately when the user opens the application.

 /** * Ensure the application resumes whatever task the user was performing the last time * they opened the app from the launcher. It would be preferable to configure this * behavior in AndroidMananifest.xml activity settings, but those settings cause drastic * undesirable changes to the way the app opens: singleTask closes ALL other activities * in the task every time and alwaysRetainTaskState doesn't cover this case, incredibly. * * The problem happens when the user first installs and opens the app from * the play store or sideloaded apk (not via ADB). On this first run, if the user opens * activity B from activity A, presses 'home' and then navigates back to the app via the * launcher, they'd expect to see activity B. Instead they're shown activity A. * * The best solution is to close this activity if it isn't the task root. * */ if (!isTaskRoot())

UPDATE: moved this solution away from parsing intent flags to querying if the activity is at the root of the task directly. Intent flags are difficult to predict and test with all the different ways there are to open a MAIN activity (Launch from home, launch from 'up' button, launch from Play Store, etc.)

"The problem goes away once the the app has been cold-started from the launcher." This is the weirdest part and I observed it too--killing the app after the first launch, it starts behaving normally again. Such an odd bug. Thanks for analyzing it so throughly and for the solution.

Note: you can get the issue to reproduce again after initially clearing it (by "cold-starting" as you described it) by using "Open" from the app's Google Play page, even if you installed the APK it via Android Studio. I found this very useful for verifying the fix worked.

Aha! (tldr; See the statements in bold at the bottom)

I've found the problem. I think.

So, I'll start off with a supposition. When you press the launcher, it either starts the default Activity or, if a Task started by a previous launch is open, it brings it to the front. Put another way - If at any stage in your navigation you create a new Task and finish the old one, the launcher will now no longer resume your app.

If that supposition is true, I'm pretty sure that should be a bug, given that each Task is in the same process and is just as valid a resume candidate as the first one created?

My problem then, was fixed by removing these flags from a couple of Intents :

i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_NEW_TASK ); 

While it's quite obvious the FLAG_ACTIVITY_NEW_TASK creates a new Task , I didn't appreciate that the above supposition was in effect. I did consider this a culprit and removed it to test and I was still having a problem so I dismissed it. However, I still had the below conditions:

i.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP) 

My splash screen was starting the "main" Activity in my app using the above flag. Afterall, If I had "restart" my app and the Activity was still running, I would much rather preserve it's state information.

You'll notice in the documentation it makes no mention of starting a new Task :

If set, and the activity being launched is already running in the current task, then instead of launching a new instance of that activity, all of the other activities on top of it will be closed and this Intent will be delivered to the (now on top) old activity as a new Intent.

For example, consider a task consisting of the activities: A, B, C, D. If D calls startActivity() with an Intent that resolves to the component of activity B, then C and D will be finished and B receive the given Intent, resulting in the stack now being: A, B.

The currently running instance of activity B in the above example will either receive the new intent you are starting here in its onNewIntent() method, or be itself finished and restarted with the new intent. If it has declared its launch mode to be "multiple" (the default) and you have not set FLAG_ACTIVITY_SINGLE_TOP in the same intent, then it will be finished and re-created; for all other launch modes or if FLAG_ACTIVITY_SINGLE_TOP is set then this Intent will be delivered to the current instance's onNewIntent().

This launch mode can also be used to good effect in conjunction with FLAG_ACTIVITY_NEW_TASK: if used to start the root activity of a task, it will bring any currently running instance of that task to the foreground, and then clear it to its root state. This is especially useful, for example, when launching an activity from the notification manager.

So, I had the situation as described below:

• A launched B with FLAG_ACTIVITY_CLEAR_TOP , A finishes.
• B wishes to restart a service so sends the user to A which has the service restart logic and UI (No flags).
• A launches B with FLAG_ACTIVITY_CLEAR_TOP, A finishes.

At this stage the second FLAG_ACTIVITY_CLEAR_TOP flag is restarting B which is in the task stack. I'm assuming this must destroy the Task and start a new one, causing my problem, which is a very difficult situation to spot if you ask me!

So, if all of my supposition are correct:

• The Launcher only resumes the initially created Task
• FLAG_ACTIVITY_CLEAR_TOP will, if it restarts the only remaining Activity , also recreate a new Task