Автоматическая очистка задач происходит в современных версиях Android?

В соответствии с документацией на 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 для <activity/>? Изменено ли значение по умолчанию на "true" или этот атрибут устарел?

Примечание. Я не говорю здесь об управлении жизненным циклом процесса Android, который зависит от ресурса устройства. Убийство процесса должно быть прозрачным для пользователя в любом случае и не влияет на состояние задачи.

Ответ 1

Отличный вопрос, после немного погружения в источник, ответ, конечно, меня удивил!

Быстрый поиск источников Android, похоже, дает ответ. Начните с Android 2.2 на ActivityManagerService.java. Обратите внимание на строку 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;

Посмотрите немного далее на метод resetTaskIfNeededLocked() вокруг строки 7021, и вы увидите это значение, чтобы определить, должна ли задача быть reset перед запуском.

Ускоренная пересылка к источникам Android 4.3, и код был перемещен в ActivityStack.java, который вызывается из ActivityManagerService, но базовая структура такая же. На этот раз константа определяется вокруг строки 125:

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

Тот же метод resetTaskIfNeededLocked() найден вокруг строки 1973, и вы можете видеть, что теперь он проверяет, больше ли значение больше нуля, прежде чем применять ту же проверку тайм-аута для очистки состояния задачи. Обратите внимание, однако, что этот метод все еще проверяет FLAG_ALWAYS_RETAIN_TASK_STATE, поэтому этот флаг все еще можно использовать для защиты состояния, но кажется, что при внешней проверке этот код никогда не будет выполнен.

В целом это кажется довольно убедительным доказательством того, что функция была отключена в AOSP для более поздних версий Android. Я не вижу внешних средств (через системные свойства и т.д.), Чтобы это значение было повторно включено для каждого устройства, если только изготовитель не перестроил код с добавленной стоимостью здесь... но это необычно. Большинство ODM придерживаются свойств конфигурации в XML или системных свойствах, которые они могут контролировать с помощью наложения.

Таким образом, хотя технически функция не была удалена, мне кажется, что документация перестает быть правильной с точки зрения ее автоматического запуска после задержки.