基于 WorkManager 上报告的各种问题 bugtracker，他们的文档对于 WorkManager 在这种极端情况下的确切行为并不完全准确.

在某些设备上，当应用程序从任务管理器中清除时，应用程序会被强制停止，因此该部分是预期的.... 来源

---

不幸的是，有些设备将最近菜单中的应用杀死作为强制停止.Stock Android 不会这样做.当应用程序被强制停止时，它无法执行作业、接收警报或广播等.所以很遗憾，我们无法解决它 - 问题出在操作系统上，没有解决方法.来源

---

我们遇到的唯一问题是，某些中国 OEM 将刷卡以从最近"中解散视为强制停止.发生这种情况时，WorkManager 将在应用程序下次启动时重新安排所有挂起的作业.考虑到这是 CDD 违规，WorkManager 可以做更多的事情，因为它有一个客户端库.来源

---

此外，如果设备制造商决定修改库存 Android 以强制停止应用程序，WorkManager 将停止工作(JobScheduler、警报、广播接收器等).没有办法解决这个问题.不幸的是，一些设备制造商会这样做，因此在这些情况下 WorkManager 将停止工作，直到下一次启动应用程序.来源

---

在 Pixel 2 XL 上对 OneTimeWorkRequest(无限制)与股票 android 进行密集测试后，行为如下:

• 任务管理器关闭:
  • 工作继续(稍后)
• 重启设备(工作运行):
  • 重启完成后工作继续
• 应用信息强制停止":
  • 工作停止，只有再次启动应用程序才会继续
• 重启设备(工作被强制停止"):
  • 工作不会继续，直到应用再次启动

---

您可以在 dontkillmyapp.com 上找到不同 OEM 行为的完整列表.Android 团队似乎也承认这个问题，并在他们的 Android Q 的 CTS 测试中添加了一个测试.来源

I want to schedule nightly database updates. So I use new Android WorkManager. My understanding is that once scheduled it will always run in the background independently from the app's lifecycle. Is that right? My first tests show that Work is only being performed when the app is running.

val locationWork = PeriodicWorkRequest.Builder(UpdateDatabaseWorker::class.java, 24, TimeUnit.HOURS)
                        .addTag("DATABASE_UPDATE_SERVICE")
                        .build()
WorkManager.getInstance().enqueue(locationWork)

Based on various issues reported on the WorkManager bugtracker, their documentation is not completely precise about the exact behavior of the WorkManager in such edge cases.

On certain devices, apps are force stopped when the app is cleared from task manager, so that part is expected. ... source

---

Unfortunately, some devices implement killing the app from the recents menu as a force stop. Stock Android does not do this. When an app is force stopped, it cannot execute jobs, receive alarms or broadcasts, etc. So unfortunately, it's infeasible for us to address it - the problem lies in the OS and there is no workaround. source

---

The only issue that we have come across is the case where some Chinese OEMs treat swipe to dismiss from Recents as a force stop. When that happens, WorkManager will reschedule all pending jobs, next time the app starts up. Given that this is a CDD violation, there is not much more that WorkManager can do given its a client library. source

---

To add to this, if a device manufacturer has decided to modify stock Android to force-stop the app, WorkManager will stop working (as will JobScheduler, alarms, broadcast receivers, etc.). There is no way to work around this. Some device manufacturers do this, unfortunately, so in those cases WorkManager will stop working until the next time the app is launched. source

---

With intense testing of a OneTimeWorkRequest (without constraints) on a Pixel 2 XL with stock android the behavior is the following:

• Task manager close:
  • Work continues (after a bit)
• Reboot device (work running):
  • Work continues after reboot done
• App info "Force stop":
  • Work stops, will only continue when app is started again
• Reboot device (work was "Force Stopped"):
  • Work does not continue until the app is started again

---

You can find a complete list of different OEM behaviors on dontkillmyapp.com. It seems the Android team also acknowledges this issue and added a test for this into their CTS test for Android Q. source