问题的根源似乎是当你终止进程时，你的Activity处于前台。

当Activity可见时，你可以通过在DDMS中按下stop来观察这一点(发生的正是你所描述的)，并将其与home后按下stop并稍后返回应用程序进行比较。

只需确保在测试中以某种方式moveTaskToBack(true)。

我不确定这就是你想要的答案，这更像是一种逻辑思考。

我不认为你可以做一个完全自动化的测试，模拟它的唯一方法是重新创建它，也就是有太多的活动，Android会杀死你的应用程序。

所以我的想法或建议是制作另一个小应用程序，它会不断弹出新的活动，直到Android耗尽内存并开始在后台杀死进程。

行内的东西:

如果应用程序在列表中，则增加i并重新启动循环，但不关闭当前活动，否则->减少i并关闭当前活动，返回上一个并重新检查…

对我来说，最好的测试方法是这样的:

在应用程序中打开ActivityD 按Home键 在Android Studio的Logcat窗口中按下终止应用程序(这会杀死应用程序进程，确保你在Logcat顶部的下拉菜单中选择了你的设备和进程) 长按Home键返回应用程序或打开的应用程序(取决于设备) 应用程序将在重新创建的ActivityD中启动(ActivityA, ActivityB, ActivityC已死，当您返回时将重新创建它们)

在一些设备上，你也可以回到应用程序(ActivityD)与应用程序->你的启动器图标，但在其他设备上，它将启动ActivityA代替。

Android文档是这么说的:

通常，在某些情况下，当用户从主屏幕重新选择该任务时，系统会清除该任务(从根活动之上的堆栈中删除所有活动)。通常，如果用户在一定时间内(比如30分钟)没有访问该任务，就会执行此操作。

这是你在Android Studio中如何做到的。

在调试模式下将设备连接到计算机。 在你的设备上打开应用程序，去任何你想测试“死而复生”的活动。 按下设备上的Home键。 在Android Studio中进入Android Monitor -> Monitors并按下终止应用程序图标。 现在你可以通过最近的应用程序回到你的应用，或者点击它的启动器图标，在我的测试中，行为是一样的。

你也可以用adb shell从终端连接到你的设备/模拟器，然后用ps | grep <your_package_name获取你进程的PID，然后执行kill -9 < PID >。然后从最近的应用程序选择器中打开最小化的应用程序，它将重新启动最后一个活动

另一个方法，可能是可脚本化的，因为它不需要DDMS:

一次性设置:转到开发人员选项，选择后台进程限制设置，将值从“标准限制”更改为“无后台进程”。

当需要重新启动进程时，请按home键。进程将被杀死(你可以在logcat/Android Monitor studio中验证—进程将被标记为[DEAD])。然后使用任务切换器切换回应用程序。