Question

根据Android文档，系统将清除它认为已被用户放弃的任务（完成启动任务的所有活动）：

https://developer.android.com/guide/components/tasks-and-back-stack.html#Clearing

如果用户长时间离开任务，系统将清除除根活动之外的所有活动的任务。当用户再次返回任务时，仅恢复根活动。系统以这种方式运行，因为在很长一段时间后，用户可能已经放弃了之前正在做的事情，并且正在返回任务以开始新事物。

https://developer.android.com/guide/topics/manifest/activity-element.html#always

通常，当用户从主屏幕重新选择该任务时，系统会在某些情况下清除任务（从根活动上方的堆栈中删除所有活动）。通常，如果用户未访问任务一段时间（例如30分钟），则会执行此操作。

此行为可以在运行Gingerbread及更早版本的设备上轻松复制。启动应用程序并创建一些回溯历史记录，然后点击主页按钮并等待半小时。从主屏幕再次启动应用程序，状态已被清除，就好像它正在开始一项新任务一样。完美。

但是，在运行ICS及更高版本的设备上，即使任务在数小时或数天后处于非活动状态，我也无法重现此行为。当从主屏幕重新启动应用程序时，任务始终处于我保留的状态。

假设文档是正确的，在现代版本的Android（API 14+）会在什么条件下自动清除任务？

如果行为发生变化且文档已过期，alwaysRetainTaskState的{{1}}属性的目的是什么？默认值是否已更改为<activity/>，或者此属性现已弃用？

注意：我不是在谈论Android的流程生命周期管理，它将取决于设备资源。杀死进程应该对用户透明，并且不会影响任务状态。

Answer 1

很好的问题，经过一些消息来源后，答案肯定让我感到惊讶！

快速浏览Android资源似乎可以提供答案。让我们回顾一下ActivityManagerService.java的Android 2.2。请注意第186行周围的一个名为ACTIVITY_INACTIVE_RESET_TIME的常量定义，恰好设置为30分钟。

// How long until we reset a task when the user returns to it.  Currently
// 30 minutes.
static final long ACTIVITY_INACTIVE_RESET_TIME = 1000*60*30;

进一步了解第7021行附近的resetTaskIfNeededLocked()方法，您将看到此值已被检查以确定在启动之前是否应重置任务。

快进到Android 4.3源代码，代码已移至从ActivityManagerService调用的ActivityStack.java，但基本结构相同。这次，常数在第125行周围定义：

// How long until we reset a task when the user returns to it.  Currently
// disabled.
static final long ACTIVITY_INACTIVE_RESET_TIME = 0;

在1973行附近找到相同的resetTaskIfNeededLocked()方法，您可以看到现在它在应用相同的超时检查以清除任务状态之前检查该值是否大于零。但请注意，此方法仍会检查FLAG_ALWAYS_RETAIN_TASK_STATE，因此此标志仍可用于保护状态清除，但似乎禁用外部检查后，此代码将永远不会执行。

总体而言，这似乎是非常有说服力的证据，表明该功能已在AOSP中针对更高版本的Android进行了有效禁用。我没有看到每个设备重新启用此值的外部方法（通过系统属性等），除非制造商要使用此处添加的值重建代码...但这并不常见。大多数ODM都坚持使用XML或系统属性中的配置属性，它们可以通过叠加控制。

因此，虽然技术上该功能尚未“删除”，但在我看来，文档在延迟后自动触发方面不再正确。

Android的现代版本中是否会发生自动任务清除？

1 个答案: