Activity stack ordering problem when launching application from Android app installer and from Home screen

Question

For testing purposes only, I am allowing my app APK to be downloaded and installed via a URL. Once downloaded on the phone, it can be launched with the Android app installer which gives the user an option to install it to their device and then run it.

Consider if we downloaded and ran the app in the way described above. The main/launcher activity in my app is a login page (Activity A). Once the user is authenticated, they are taken to the main area of the application, e.g. Activity B. So now the current activity stack of this task is A > B.

I then press the home button on the phone and am taken to the Android home screen. I re-launch my app via the icon in the menu, and I am taken to Activity A, instead of Activity B. Either the activity stack is now A > B > A, or there are now two separate tasks with activity stacks A > B, and A respectively. What I want is to be taken back to Activity B when I relaunch the app. Pressing back whilst in this state will take me back to Activity B.

This undesired behaviour only happens if I first open the app via the installer, and not if I open the app via the home screen/menu.

I looked into how the activities are being started by each mechanism. When we use the app installer, we see the following logs:

INFO/ActivityManager(XXXX): Starting activity: Intent { dat=file:///mnt/sdcard/download/[my app].apk cmp=com.android.packageinstaller/.InstallAppProgress (has extras) }
INFO/ActivityManager(XXXX): Starting activity: Intent { act=android.intent.action.MAIN flg=0x10000000 cmp=[my package]/[Activity A] }

via launcher / home screen:

INFO/ActivityManager(XXXX): Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=[my package]/[Activity A] }

When started with the installer we see it is using the flag 0x10000000, but when started with the launcher we see it is using 0x10200000. It is also using an intent category.

From the docs we see the flags are:

public static final int FLAG_ACTIVITY_NEW_TASK
Constant Value: 268435456 (0x10000000)

public static final int FLAG_ACTIVITY_RESET_TASK_IF_NEEDED
Constant Value: 2097152 (0x00200000)

The flag FLAG_ACTIVITY_RESET_TASK_IF_NEEDED (which is being used when the app is launched from the launcher) seems to usually prevent a new task from being created if one already exists, and will restore the last used activity. This is the desired behaviour. Why is it not working in this situation? Is there anything I can do to make sure my application will always return me to the last Activity regardless of whether it was started through the app installer/launcher?

If I use singleTask it will always take me back to the main activity (Activity A) whenever I run the app (which is also not desirable).

Here is a question I found where someone is experiencing a similar problem (which has no accepted answer): App loses its ability to remember its stack when launched from another application

EDIT: Checking for the flag FLAG_ACTIVITY_BROUGHT_TO_FRONT in onCreate() of our launcher activity (and then finishing if it is set) seems to fix the main symptom, but clearly the underlying issue is still there. Is there a more complete fix?

EDIT2: The same result occurs when you download/run the app from the Android Market, so some of the above details may not be relevant.

Coenocyte

Checking FLAG_ACTIVITY_BROUGHT_TO_FRONT works great. Can you please post it as an answer? – Venesection

Another reproducible scenario: Launch the app from the market app – Venesection

Basically the same situation as https://mcmap.net/q/122052/-re-launch-of-activity-on-home-button-but-only-the-first-time and is still broken in 2019! – Thornberry

Answer 1

Added the answer that antonyt provided:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT) != 0) {
        // Activity was brought to front and not created,
        // Thus finishing this will get us to the last viewed activity
        finish();
        return;
    }

    // Regular activity creation code...
}

Venesection

thnx for code and i also learned a new way to write if condition here, but you should add if there is some 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 there it is written in answer from where this answer is taken. It seems important thing to remember while placing this check. – Law

@VishwasSharma - the issue you're raising sounds like an Android platform bug. How come Android agrees for a locked-in situation? – Venesection

Locked-in situation will be introduced by the check which is placed in above code(although not very likely to happen), not by the android and if you know about how app is launched, you should already be knowing that if you launch app from menu it is launched with different intent flag, if you launch it from launcher menu, then it has different flag set(which is why we needed this check) and if you launch from eclipse, it is launched differently. What I am trying to say is that app is launched with a flag respective to from where you launch the app. – Law

So, i don't think that this is android platform bug, but they need to consider this while making platforms for app launch. Although, this can be a bug in eclipse app launching mechanism, which is explained here – Law

I'm having the exact same issue. I tried this solution, but it didn't work for me. Values when launched through menu: Intent { flg=0x10104000 cmp=.activities.Login bnds=[214,520][429,721] } Flags: 269500416 When launched through normal app icon, the Login activity isn't created. Any help would be appreciated. – Adanadana

Same problem as https://mcmap.net/q/122052/-re-launch-of-activity-on-home-button-but-only-the-first-time and it is still broken in 2019! – Thornberry

Answer 2

The underlying issue I believe is that the Intents used are different between the launcher and the installer. In so far as you are getting different Intent flags you are going to get different launch behavior. You can muck with the launch modes and you may be able to get a consistent result but fundamentally those different Intents will produce different results.

Your fix (or something like this) is probably your best bet.

Mitsue

This seems like a fundamental problem that many apps would find undesirable - indeed, I have seen the Android Facebook app exhibit this behaviour - and so it is quite disappointing that the above workaround (or similar) is all we can do. – Coenocyte

It could be considered a behavior defect: on the other hand, it does allow you to differentiate between Installer launches and App icon launches, which you could use to launch a Welcome screen that only shows up when someone clicks on the Installer run button. Now that I think about it I might actually use that :) – Mitsue

@Mitsue However, keep in mind that not everybody will start the app for the first time via the Install & Run option, and they may still appreciate a greeting when they get around to it. :) – Better

Very true: I already have logic in my apps to check the first run, this is just one more hook. – Mitsue

I have tried to detect whether or not the category is set in the intent used to start the activity (it usually isn't set by the installer, only the launcher) - if it is missing I add the category and the flag and then restart (startActivity()/finish()) with this modified intent. The bad behaviour still occurs even though the intents now seem to match. Do you have any thoughts on this? – Coenocyte

Odd: show the code you are using? I should think it would work (you may need to create an entirely new Intent to get that to act right though). – Mitsue

See https://mcmap.net/q/122052/-re-launch-of-activity-on-home-button-but-only-the-first-time it is a long-standing Android bug (still broken in 2019) – Thornberry

Answer 3

Your problem is likely rooted in the fact that App installer doesn't use the LAUNCHER category, as does the launcher.

This bug has been documented elsewhere:

App always starts fresh from root activity instead of resuming background state (Known Bug)

Ironstone