这个问题在2016年仍然存在。今天，一个质量检查测试人员报告了一个我的应用重新启动，而不是从 Android M中的库存启动器中恢复。
实际上，系统将启动的活动添加到当前的任务堆栈中，但是对用户来说好像是重新启动发生了，他们已经失去了工作。顺序为：
从Play商店下载(或侧载APK)
从Play商店对话框启动应用程序：出现活动A [任务堆栈：A]
导航到活动B [任务堆栈：A-> B]
按“主页”按钮
从应用程序抽屉启动应用程序：活动A出现！[任务堆栈：A-> B-> A](用户可以按“返回”按钮从此处进入活动“ B”)
注意：仅通过Play商店下载或侧载的APK中，通过ADB部署的调试APK不会显示此问题。在后一种情况下，步骤5中的启动意图包含标记Intent.FLAG_ACTIVITY_BROUGHT_TO_FRONT，但在调试情况下不包含。从启动器冷启动应用程序后，问题就消失了。我的怀疑是，该Task植入了格式错误(更准确地说，是非标准)的Intent，该Intent会阻止正确的启动行为，直到完全清除该任务为止。
我尝试了各种活动启动模式，但是这些设置与用户期望的标准行为相差太大：在活动B处恢复任务。请参见页面底部“ 任务和后退堆栈 ” 指南中的以下预期行为定义。在“开始任务”下：
这种意图过滤器会在应用程序启动器中显示活动的图标和标签，从而为用户提供一种启动活动并在活动启动后随时返回创建的任务的方法。
我发现这个答案很重要，并将以下内容插入了我的根活动(A)的'onCreate'方法中，以便在用户打开应用程序时可以适当地恢复。
/**
* 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()) {
finish();
return;
}更新：此解决方案从分析意图标志转移到查询活动是否直接在任务的根源。意图标记很难以各种不同的方式来进行MAIN活动的打开(从家中启动，从“向上”按钮启动，从Play商店启动等)进行预测和测试。
