这似乎对我很管用:

adb shell am kill <package_name>

这与OP中提到的adb shell kill不同。

注意，am kill命令的帮助是这样说的:

am kill: Kill all processes associated with <PACKAGE>.  Only kills.
  processes that are safe to kill -- that is, will not impact the user
  experience.

因此，如果进程在前台，它不会终止进程。这似乎可以作为OP想要的工作，如果我导航离开我的应用程序，然后运行adb shell am kill <package_name>它将杀死应用程序(我已经确认使用设备上的ps)。然后，如果我返回到应用程序，我就回到了我之前在的活动中-即在OP的例子中，进程被重新创建并创建ActivityD(而不是ActivityC，像大多数其他杀死方法一样触发)。

抱歉我迟到了几年，但希望其他人会觉得这有用。

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

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

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

以编程的方式在应用程序后台运行，然后发出ADB命令:

adb shell am kill <PACKAGE_NAME>

请注意，这与Wajahat Karim的一篇优秀文章中描述的adb shell kill命令不同:https://wajahatkarim.com/2020/03/defending-your-app/

请注意，这与adb shell kill命令不同。该命令杀死你的应用程序的整个进程，如终止应用程序按钮，而adb shell am kill只杀死安全的进程，以重新分配资源，如内存，CPU等。

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

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

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

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

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

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

行内的东西:

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

我迟到了，在我之前的几个人给出了同样的正确答案，但为了简化，只要按下home键并运行以下命令:

Adb shell ps | grep <包名> | awk '{print $2}' | xargs Adb shell run-as <包名再次> kill

应用程序不会失去状态，从我自己的经验来看，这与操作系统在后台杀死应用程序的方式相同。这只适用于调试构建的应用程序