As an experiment I modeled WebAPK/Chrome as a pair of simple Android apps and found that not specifying any of these flags (except for excludeFromRecents for WebappLauncherActivity) still works, i.e. new task is created, which has both MainActivity and WebApkActivity in it. There are two advantages to having MainActivity/WebApkActivity task:

1. Clicking on the WebAPK icon while WebApkActivity is running simply brings up the task. (Plus I think Android uses recents snapshot in this case, as if we clicked an entry in recents.)

2. This can potentially simplify splashscreen management, if we make MainActivity to be the splashscreen. In this case the splashscreen (i.e. MainActivity) will be displayed until WebApkActivity draws on top of it, and we can even make WebApkActivity transparent until it receives first frame from the renderer.

There is one thing (that I can thing of) to watch out with this approach though:

* Going "back" from WebApkActivity by default brings us to MainActivity, i.e. to the splashscreen. We'll have to make sure that it's not possible to go back, or that MainActivity finishes when it becomes top of the stack.

Have you tried android:noHistory=true on webapk's main activity? I assume that would mean that would break your point "1."

However, without it you get in an awkward back scenario and I haven't be able to address it

Also ". This can potentially simplify splashscreen management, if we make MainActivity to be the splashscreen. In this case the splashscreen (i.e. MainActivity) will be displayed until WebApkActivity draws on top of it, and we can even make WebApkActivity transparent until it receives first frame from the renderer." isn't necessarily ideal because of deep links/re-launches. You end up seeing the splashscreen more often. Peter and I have been trying to play with it but haven't been able to avoid it

Interesting, what is a deep link?

As for re-launches, do you mean that we always need to verify WebAPK, so we always need to go through WebappLauncherActivity? 

I think we need to compile list of use cases we care about somewhere. Maybe current combination of activity flags is the only possible one.

Deep link is any intent to the webapk which matches the intent filter (as opposed to just launching from homescreen). So it's not that different but there are scenarios which trigger it more often (e.g. clicks on tweets for twitter lite) which would be forced through splashscreen soon. We also discussed with AlexR and it's possible we accept it to improve homescreen launch which is more common (stats here:
https://uma.googleplex.com/p/chrome/histograms?endDate=20180311&dayCount=7&histograms=Launch.HomeScreenSource&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial - "External Intent (WebApk)" is deep link)

Ok, we have an option that's arguably gross but doesn't negatively impact UX. Namely, when the webapk launches chrome it also passes a messenger object (they're parceable) as an intent extra. Rather than having the MainActivity finish itself, it stays in the back stack for as long as needed. In WebApkActivity, we override onBackPressed and if we know we're going to end up asking android to go back, we first send a message to the webapk to kill itself. 

This would allow us to show the splashscreen from the webapk and without showing it more than it currently appears (i.e. no flickers for deep links / warm webapks).

It feels pretty cludgy and there's still some risk - if the webapk process is evicted, the message goes nowhere and the activity remains in the back stack. But hey, it's something!

Peter is still investigating a different, simpler option where within the webapk, we detect whether there's a WebApkActivity as part of our stack and don't show the splashscreen.

Hah, we could probably address the eviction by getting the Binder from the messenger object and calling |linkToDeath| on it.. :/

I wonder if we can simply count number of onResume() calls. I.e. skip the first one (from onCreate->onStart->onResume), but finish() MainActivity on the second one (which would mean that we navigated back)?

Hmm, would have to test it out but maybe? If you hit home and then hit the launcher icon again, that would launch a new activity? Or because WebApkActivity is single task it would find the task so you'd end up resuming WebApks' Main activity?

If the WebApkACtivity stays alive, won't it show up in the Android running-app list?