Кнопка «Домой» не вызывает onDestroy
, поскольку действие все еще находится в стеке действий, где, как и в случае с кнопкой «Назад», оно обычно удаляется. Когда ActivityManager
решает удалить действие из стека, обычно после периода бездействия или когда требуются ресурсы, будет вызван onDestory
, и в этот момент ваше поле будет сброшено.
Я не могу сказать однозначно, потому что я не знаю всей информации, но может показаться, что удаление пользователей, вошедших в состояние, когда вы нажимаете home (в onStart
, как предлагает coder_For_Life22), может быть плохим, как если бы Вы вернулись к операции, которую пользователь должен будет снова выполнить, возможно, излишне, и управление сеансами на стороне клиента станет еще более сложным.
Ваш метод управления сеансами в любом случае кажется довольно сомнительным, если только у вас нет какого-либо управления сеансами на стороне сервера, где, например, если в сеансе была неактивность, поле базы данных было бы сброшено.
UPDATE
Единственный способ предположить, что это возможно, - использовать ActivityManager.getRunningTasks()
или ActivityManager.getRunningAppProcesses()
и проверить, входит ли ваше приложение в их число. Если вы убьете свое приложение так, как вы предлагаете, тогда ваше приложение не будет среди них, и поэтому вы знаете. Это кажется чрезвычайно сложным решением, если это вообще возможно, поскольку вам понадобится отдельная фоновая служба (которую можно вызвать getSystemService(ACTIVITY_SERVICE)
, чтобы получить ActivityManager
), просто после того, как вы убьете свое приложение, у вас все еще будет что-то, что может проверьте это и выполните соответствующие действия.
Убивая ваше приложение таким образом, вы пренебрегаете жизненным циклом активности, и, следовательно, в вашей активности нет ловушки, с помощью которой вы можете выполнять закрытые вызовы.
Кажется, гораздо разумнее проверить отсутствие активности на стороне сервера и сбросить поле таким образом, люди не так часто убивают свои приложения, а когда они делают это, они вряд ли быстро передадут телефон кому-то другому. кто сможет получить доступ к информации злонамеренно.
Если данные требуют такой защиты, вам следует пересмотреть свою модель безопасности.