区分Android杀死应用程序和用户在最近的应用程序列表上滑动它

我正在开发一个项目,在进行特定活动时,我们会显示本地粘性通知。 当应用程序最小化时也应如此。 我必须完成的是在应用程序被杀死时删除本地通知(由于内存不足或由用户通过Android,从最近的应用列表中滑动)。

通常只要Android使用Activity打开一些空间就会调用onDestroy 。 在其中一种情况下这很好,但是从最近的应用程序列表中滑动应用程序不会调用onDestroy并且粘滞通知会保留。

我做的是,我实现了一个空服务,当应用程序被杀死时(刷卡和系统终止)会强制onDestroy ,这样我就可以删除我的通知了。

但是,我想要做的是区分滑动和系统杀死。

这有可能吗?

一般来说,如果Android想要杀死你的应用程序,因为它已经在后台工作太久(或者因为它想要回收资源),Android只会简单地杀死托管你的应用程序的操作系统进程。 它不会在任何Activity或Service组件上调用finish()onDestroy() 。 “从最近任务列表中滑动”的行为随着时间的推移而发生变化,并且在不同的Android版本中有所不同。 有人应该写一本关于这个的书:-(

您可以通过向应用添加服务以及实施onTaskRemoved方法来检查用户何时滑动关闭应用程序: https : onTaskRemoved

这是我在reddit中发现的评论,在我看来真的很有趣:

向外刷一个应用程序将有效“杀死”大多数应用程序。 如果安装了SDK,则可以使用ADB对此进行测试。 从您的最近列表中滑动所有内容,然后启动浏览器。

使用ADB在设备上运行“ps”并validationcom.google.android.browser进程是否正在运行。 转到主屏幕,它仍在运行。 启动其他一些应用程序,com.google.android.browser进程仍然存在。

然而,将其从最近的列表中滑出,过程就消失了。 您可以创建一个测试应用程序以进一步validation,并在您的Activity中记录onDestroy ()调用。 当您退回或退出应用程序或启动其他应用程序时,不会调用它。 当您将应用程序从最近列表中滑出时,它会被调用。 我同意最近的应用程序列表并不是真正的“多任务处理”。

列表中的应用程序甚至不一定正在运行,在您尝试重新打开它之前,内存管理器可能已经杀死了这些进程。 但是,您不能争辩说,当滑动使实际过程消失时,唯一的目的是快速跳转到其他应用程序。

这是关于从最近的应用列表中滑动应用时发生的情况的另一个好答案。 但我最喜欢的部分是:

实际上,删除最近任务中的条目将终止该进程存在的任何后台进程。 它不会直接导致服务停止,但是有一个API可以让他们发现任务被删除以决定他们是否希望这意味着他们应该停止。 这样,删除说电子邮件应用程序的最近任务不会导致它停止检查电子邮件。

如果你真的想完全停止一个应用程序,你可以长按最近的任务来转到应用程序信息,然后点击力量停在那里。 停止是完全杀死应用程序 – 所有进程都被终止,所有服务都被停止,所有通知被删除,所有警报都被删除等。在明确请求之前,不允许应用再次启动。

通过从最近的任务列表中滑动仅从最近的任务中删除..它在android 5.0之前也被称为onDestroy。 您可能遇到api 20级设备以上的问题。 系统杀死通常无法在正常的android活动生命周期中执行。 它刚刚完成了背压事件的活动。

当应用程序向左滑动时,如果任何线程仍在您的应用程序中运行中断但服务未停止,当您杀死方便的应用程序线程和服务停止。

行为与关闭应用程序类似但不完全相同 – 一般情况下(对于没有定义显式后退按钮处理的应用程序),这与从应用程序中退出足够时间退出它的行为相同。 查看此链接讨论,它对该主题有一些很好的输入

首先,让我们明确一点:Android可能不会调用onDestroy() 。 参考活动页面 ,从Honeycomb开始,保证在应用程序被杀死之前调用onPause()onStop()

请注意,这些语义在针对从HONEYCOMB开始的平台的应用程序与针对先前平台的平台之间会略有不同。 从Honeycomb开始,应用程序在其onStop()返回之前不处于killable状态。 这可以在调用onSaveInstanceState(Bundle)时产生影响(可以在onPause()之后安全地调用它,并允许和应用程序安全地等到onStop()以保存持久状态。

因此,在(希望)清除Android生命周期中的空气后,我认为您可以通过将通知删除代码放在onStop()来实现您想要的效果。 如果你最终需要它回来因为用户实际上已经回到特定的Actvitiy (IE未被杀死),你可以将它带回onRestart()