0

I've been using WorkManager to create notifications for my app. For my purposes I figured PeriodicWorkRequest is the most fitting, but after a bit of testing and reading online it's seems extremely unreliable. Using the minimal interval (15 minutes), and the app being closed, the worker woke up 5-6 times and then seems to be killed.

So how does one go about creating background work that wakes up in reasonable time intervals? What is the best approach for creating event-based notification? My idea was checking for the event (for example, checking for something new in the database) in small time intervals (with 15 minutes also being less than ideal), but seeing as it doesn't work well with PeriodicWorkRequest and is also the recommended approach as per the documentation, what exactly are my options?

user3917631
  • 119
  • 1
  • 9
  • Seeing your use case, it seems **WorkManager** is the best fitted api. But I am not clear about your issues with it. You can also use **AlarmManager** with **BroadcastReceiver** for your purpose. You will find many tutorial on web of working with AlarmManager – Soumik Bhattacharjee May 16 '22 at 06:50
  • @Soumik Bhattacharjee The issue is the worker seem to stop being called after multiple time, whilst I need it to run indefinitely when the app is in the background\is closed. It is specifically stated in the doc AlarmManager shouldn't be used for my use-case. – user3917631 May 16 '22 at 06:56
  • Ok. You can try using **AlarmManager**. But I am not sure you will be able to run anything indefinitely in background now. As different Android devices now have the policy to clear app tasks after a certain period of time. – Soumik Bhattacharjee May 16 '22 at 07:00
  • @Soumik Bhattacharjee How is it possible for apps to check for updates and notify the user then? Messaging apps for instance, I'm having a hard time believing they just cease to work after a certain amount of time in the background. AlarmManager as I understand it is a one time wakeup call scheduled to an exact time, so in order to use it for such purpose I'll need to schedule another alarm when the alarm is called, which seems like a hacky solution and I'm not sure is even possible. – user3917631 May 16 '22 at 07:04
  • Messaging apps doesn't really work on the background for long. They are attached to the OS process itself. They get notified once any new message comes using **BroadcastReceiver**. For normal apps like ours previously it was possible by using **IntentServiece+AlarmManager** combination. Now as different Android OS are concerned for securities and performance, they tend to clear the app process after a certain time. – Soumik Bhattacharjee May 16 '22 at 07:12
  • @Soumik Bhattacharjee Understood, thanks for help! – user3917631 May 16 '22 at 07:15
  • For your use case, You can use AlarmManager to trigger your Background work. And once your work is done, you can clear the previous alarm and trigger a new one. This can be a solution, I am not sure if it is good or bad. – Soumik Bhattacharjee May 16 '22 at 07:17

1 Answers1

2

Basically, the idea of Android is for you not to be able to do what you want to do because we as developers try to kill the battery.

You need to see how the evolution of the restrictions goes:

Version 6 - Doze:

https://developer.android.com/training/monitoring-device-state/doze-standby https://developer.android.com/about/versions/marshmallow/android-6.0-changes#behavior-power

Version 7 Another state of Doze with even more restrictions: https://developer.android.com/about/versions/nougat/android-7.0-changes#perf

Broadcast Restrictions: https://developer.android.com/guide/components/broadcasts https://developer.android.com/about/versions/nougat/android-7.0-changes#bg-opt

Version 8.0 Background execution limits: https://developer.android.com/about/versions/oreo/background#services

Version 9 StandBy Buckets - where depending on how the app is used you have different resources to use - like time to wake up the app, time to use the Network, etc

https://developer.android.com/about/versions/pie/power#buckets https://developer.android.com/about/versions/12/behavior-changes-all#restrictive-app-standby-bucket https://developer.android.com/topic/performance/appstandby

Battery Save improvements:

https://developer.android.com/about/versions/pie/power#battery-saver

Power Management Restrictions - really important. https://developer.android.com/topic/performance/power/power-details

Version 11 and 12 App hibernation

https://developer.android.com/topic/performance/app-hibernation

Long story short - you need to prevent all these restrictions to harm your work. But you need to comply because it is better for the user.

But there is no API that will just say - "f**k all these restrictions and do whatever the dev wants to do."

If you need exact timing - you need AlarmManager.

If you do not know when you need to do your work and depend on the outside - Push Notifications which then can transfer the work to the WorkManager.

If you need periodic work that is not time-critical - you might not use the AlarmMangaer and be sure that the work is finished, but you can't be sure when, because there are many restrictions and the priority will be saving the resources.

Also, you can ask the user to be exempted from Battery Optimization:

https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases

If you want to know why exactly the work is not executed you need to check the JS dump and see what restriction is not satisfied:

https://developer.android.com/topic/libraries/architecture/workmanager/how-to/debugging#use-alb-shell0dumpsys-jobscheduler

Yavor Mitev
  • 1,363
  • 1
  • 10
  • 22