My Android application helps users to follow their daily plan by sending notifications at a specific time. This task is easy to solve with JobScheduler. It seems easy, light and up to date solution.
What I'm struggling with is how to plan all notifications every day. I need to run code that checks user daily plan and schedules notification every day at midnight silently. And so far I found 2 approaches
Use JobService. It can be re-scheduled with
public final void jobFinished(JobParameters params, boolean needsReschedule)
but I think it's a bad solution because
I'll need to treat finished job as failed, although it's successful
Schedule time will increase linearly/exponentially and that is not acceptable for me.
Another approach is to use AlarmManager, but it also has a couple of drawbacks
According to documentation
Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted.
And this is not acceptable, as my users can miss something important.
I've read that it kills battery pretty quickly. Is that true?
Other solutions that I've found in documentation doesn't looks like what I need.
(https://developer.android.com/topic/performance/scheduling.html)
Any ideas how run scheduled task on a daily basis that will be light and resilient to reboot?
Using JobService is fine. You do not need to reschedule your job. Just create new job(s) as needed.
I have my own issues with scheduling alarms too. To have things worse, starting with Android 6 there's Doze mode which delays alarms execution.
Please take a look at: https://developer.android.com/training/monitoring-device-state/doze-standby.html
For alarms, you can have a boot complete listener and reschedule the alarms on a restart. If you don't need network connectivity during alarm firing, take a look at Adapting your app to Doze from the above link.
Related
I have to update Data in my App every 24 hours at 2 am.
Currently, I have an Alarm via the AlarmManager which sends an alarm every 24 hours with the setRepeating method.
In the past I have experienced some unreliabilities with the timing of the alarm, so I was experimenting with an intent-filter and Intent.ACTION_TIME_TICK.
My Question:
What is the difference between setting a repeated alarm every 24 hours and using an intent-filter which gets its information from the system?
You should absolutely not do anything with ACTION_TIME_TICK. Nor would it be reliable if you tried- it would only work while your app is running, and if you're backgrounded you will be killed for resources. The correct answer here is actually JobScheduler or WorkManager, depending on the nature of what you're doing. Most likely WorkManager. However if you were worried about the reliability of timing of an alarm, you probably are thinking about your problem wrong. Unless you have a VERY niche use case, a bit of inaccuracy in downloading a nightly update is generally ok. In fact it may even be welcome, to spread the load out on the server. Your inaccuracy of dl time is likely due to Doze, which is a mechanic your use case should likely account for (Doze is a power saving mode where it reduces the frequency of timed events running when the screen is off).
I am developing a flutter application, however I would like a service to be able to run constantly without stopping in order to make an api request every 15 minutes and then send a notification to the user (Android /IOS). I would also like the service to start automatically with the smartphone. I've been stuck on this for more than a week now and I've been browsing the forums looking for a solution but I can't find what I'm looking for. Thank you in advance for any help
You don't do it like that on Android. You cannot count on an application not being killed in the background. Instead, you use JobScheduler or WorkManager to set an alarm and wake you up every so often to perform whatever job you need. These methods can also ensure you're scheduled at startup of the phone.
Also, 15 minutes may or may not happen- Doze mode may cause your app to be delayed and make requests less frequently than that if the phone goes to sleep (although 15 minutes is fairly safe, plus or minus a few).
I'm having trouble deciding whether to run some recurring background work with Alarm Manager or Work Manager:
The work is going to consist of Room Database operations so I'll need access to Dao to complete my work.
It is going to be recurring at fixed intervals (hourly, daily, weekly, monthly, etc.)
I need to set a start date and time for the recurrence intervals.
the work will recur until canceled by the user
If the user is using the app when the work is supposed to be scheduled, I want the work to be done immediately. If the user is not on the app (app is in the background or device is turned off), I don't care if the work is done after the scheduled time as long as it is at least started by the next time the user opens the app.
the work needs to continue as scheduled after device reboots and app restarts.
For recurring background work, AlarmManger isn't suitable. As the name implies, it's intended to notify the system of an event at a precise time. Just like a physical alarm that wakes a person up even if the person sleeps, AlarmManager will wake up the device from doze mode which will result in more power usage. it is suitable for suitations like setting remainders such as for calender events which the users probably set by themselves.
On the other hand, WorkManager is intended to carry out background processing or work that would persist. Workmanager is much more efficient for recurring task especially as it allows you set constraints to determine when it should start or stop the background work.
check the link form the offical documentation on WorkManger:
workmanager architecture
tabular comparison between the two
It mostly depends on how important your task is.
https://developer.android.com/guide/background is a really good entry point to help you choose what you should work with.
WorkManager is the modern, universal approach of handling background work and it fits for most use-cases, it automatically reschedules work after a device restart or an application crash, and it is very efficient in terms of battery usage.
As WorkManager does respect Android's doze mode, it does not guarantee, that the work will be done exactly on time, though it does guarantee, that your work will be done within a certain time frame.
On the other hand, AlarmManager is capable of running work precisely on time. But this means that the device will wake up when your work scheduled with AlarmManager is coming due. This will drain battery and your app will probably show up as battery-draining in the Device Health board.
But as stated in the article above, prefer using WorkManager if possible. AlarmManager should only be used for e.g. a time-sensitive calendar notification.
Recently, I'm working on an app that needs to run a Service every day at a certain time.
To do this, I use AlarmManager.
My question is: After activating the AlarmManager (from the Service), can I destroy the Service, and the AlarmManager will still call me in time?
If not, is there any way at a certain time to send me BroadcastRecerver, without running a Service all the time in OS?
Would appreciate help
The short answer to your question: service can still be started from the alarm manager anytime the alarm receiver is able to run. The long answer: usually it's good practice trying to use job schedulers though. They can both decide a better time to run, while ensuring you have the necessary resources to run successfully, such as network or high battery among other criteria.
Alarm managers are only reasonably reliable before Nougat. It's been long announced that developers should stop using it, and start using job schedulers for most use cases. They are meant to replace both the alarm setup and receiver, and allow the phone to save more battery by putting the phone in doze mode for longer and waking up and doing multiple tasks all at once.
Even if you get alarm manager working on your particular phone google makes less and less reliable with each OS release. There are very specific cases where alarms are still the way to go, but unless you're certain to be in one of these try to use job schedulers for all devices running lollipop and later. You can still use alarm manager reliably for kitkat and older, where job schedulers don't exist. More details on: https://developer.android.com/training/monitoring-device-state/doze-standby.html
In either case I think you need to listen for phone's boot so you can register your alarm/job scheduler:
https://developer.android.com/training/scheduling/alarms.html
Job scheduler info:
https://developer.android.com/topic/performance/scheduling.html
For reliability issues: Android AlarmManager not working on some devices when the app is closed
this question is just to get some ideas on these concepts to see what people in the industry use these for.
If you can just give a few example uses for each of these, I would greatly appreciate it. I know how they work and did read the google documentation on them but I still seem to be having a hard time picking one over the other. I don't need you to explain to me how they work. I am simply asking for a few of their example uses. How you ended up incorporating them into your apps and why you picked them over the others.
Thanks
AlarmManager
Using the AlarmManager to Schedule Tasks at the System Level
The AlarmManager provides access to system-level alarm services. Using the AlarmManager allows an application to schedule tasks that may need to run or repeat beyond the scope of its lifecycle. This allows the application to perform some function even after the application process or all of its Android components have been cleaned up by the system.
Typically, the AlarmManager is used to fire off a PendingIntent that will start up a Service in the future. The AlarmManager triggers Services based on an elapsed interval or at a specific clock time. Both of these options also have the ability to wake up the device when it is asleep if the alarm is urgent.
The benefits of the AlarmManager come into play when using inexact intervals or times to fire off Services. The Android system tries to batch alarms with similar intervals or times together in order to preserve battery life. By batching alarms from multiple applications, the system can avoid frequent device wake and networking.
One concern to consider while using the AlarmManager is that alarms are wiped out during device reboots. Applications need to register the RECEIVE_BOOT_COMPLETE permission in their Android Manifest and reschedule their alarms in a BroadcastReceiver.
Another concern is that a poorly designed alarm could cause battery drain. While the AlarmManager does have the ability to wake devices and set an exact time for an alarm, the documentation mentions that developers should be wary of these features when performing networking. Aside from draining a device’s battery by avoiding batch alarms, setting an exact time for an application to sync with a server could put high strain on a server if every application installation tries to sync with the server around the same time! This can be avoided by adding some randomness to alarm intervals or times.
AlarmManager is a great candidate for scheduling if an application needs to perform a local event at an exact time or inexact interval. Alarm clock or reminder applications are great examples for AlarmManager usage. However, the documentation discourages using AlarmManager for scheduling network-related tasks. Let’s take a look at some better options for networking.
Job Scheduler
JobScheduler helps perform background work in an efficient way, especially networking. JobServices are scheduled to run based on criteria declared in JobInfo.Builder(). These criteria include performing the JobService only when the device is charging, idle, connected to a network or connected to an unmetered network. JobInfo can also include minimum delays and certain deadlines for performing the JobService. Jobs will queue up in the system to be performed at a later time if none of these criteria are met. The system will also try to batch these jobs together in the same manner that alarms are scheduled in order to save battery life when making a network connection.
Developers might be concerned about a scheduler that frequently delays firing off its JobServices. If jobs are frequently delayed and data stale as a result, it would be nice to know about such things. JobScheduler will return information about the JobService such as if it was rescheduled or failed. JobScheduler has back-off and retry logic for handling these scenarios, or developers could handle those scenarios themselves.
Subclassing JobService requires an override of its onStartJob(JobParams params) and onStopJob(JobParams params) methods. onStartJob() is where callback logic for jobs should be placed, and it runs on the main thread. Developers are responsible for threading when dealing with long running jobs. Return true to onStartJob() if separate thread processing needs to occur, or false if processing can occur on the main thread and there is no more work to be done for this job. Developers must also call jobFinished(JobParameters params, boolean needsReschedule) when the job is complete and determine whether or not to reschedule more jobs. onStopJob() will get called to stop or cleanup tasks when initial JobInfo parameters are no longer met, such as a user unplugging their device if that parameter is a requirement.
There might be a lot to think about when implementing a JobService, but it comes with a lot more flexibility than AlarmManager. Another handy feature is that scheduled jobs persist through system reboots.
There is at least one drawback to using JobScheduler. As of the writing of this post, it’s compatable only with API level 21 and higher. Here you can find the distribution of Android devices running various API levels. While there is technically no backport of JobScheduler, a similar tool is GCM Network Manager.
REFERENCE LINK