Breaking Scope

Using Firebase JobDispatcher for Recurring Tasks

Firebase JobDispatcher is a library that I’ve been wanting to write about for a while now. It’s a library that you can use to schedule recurring tasks for your Android app. It isn’t without it’s flaws, but it provides a lot of different options for fine-tuning how your tasks are triggered and (mostly) works well.

Firebase JobDispatcher Advantages

Firebase JobDispatcher is backwards compatible to API 14. It covers a lot of bases Android version-wise. It also uses the JobScheduler framework for API levels above 21(for API levels below this it uses Google Play service’s scheduling engine). The library is also supported by Google Engineers and you can get it working quite easily.

And the Disadvantages…

Firebase JobDispatcher requires Google Play services. This is probably not an issue for most developers, because you’re likely to be distributing your app on Google Play anyway. It might be something for developers that use third party stores to think about though. Another disadvantage is that while it is supported by Google Engineers updates can be a little fleeting, you will realize this if you read through the Github Repository’s issues. It won’t work on every single device either, it seems to be Doze resistant but in my experience it still doesn’t play nice with OEM power savers. There will probably never be a holy grail for task scheduling in Android though, so this library is as close as you will get device-compatibility wise.


Firebase JobDispatcher is relatively easy to implement, but there are a few steps involved. First of all, you need to add this dependency to your app-level build.gradle file:

After that you need to make a new class(Service) that extends JobService:

Then you need to register the new JobService in your manifest file(it is a Service after all):

The last step is to create a dispatcher and then schedule a job with the dispatcher, here’s a quick example of a MainActivity that schedules a task in onCreate:

And that’s all there is to it. If you compile the app and start it on a device you should see the log message from TaskService printed in logcat about every minute or so(it is never completely precise and optimizes for sleeping). For reference I use a Motorola G4 as my test device. Your experience might vary the further away you go from stock Android.

Firebase JobDispatcher logcat

Wrap Up

If you want a reliable way to set recurring tasks for your Android app, then hands down I think Firebase JobDispatcher is your best bet. You could roll your own AlarmManager solution or use Evernote’s scheduler library for better precision, but I’ve heard about some issues with Chinese handsets(Xiaomi for instance) force killing apps from the Task Manager, this causes all the pending alarms to be deleted as a result. If you want to see an example project for the above implementation you can check it out here. I also wrote about Screen Pinning on Android last year, if you’re interested in that you can read about it here.


  1. I did the same, but the execution is not exact. Also, as per the doc it says ‘This will work when the app is killed/in background stack but what’s the point if it cannot be schedule at specific interval.

    Also, please suggest something for my scenario :-
    I want to create a device tracker system i.e. on a specific time my service will be started , will fetch the location then update the co-ordinates in the db and trigger the alarm/schedule the service for next Fetching . Also, service should be called if the app is killed or in background. Note :- minimum sdk level is 14.

    • jordan_mohi

      It’s never going to be exact, that’s the direction Android is heading in. In Pie things are becoming even more strict and the system will place execution restrictions on jobs/alarms based on what ‘Standby Bucket’ your app is in…It really sucks to be honest. In the case you mentioned I would probably try using WorkManager – it seems to be getting more stable in recent releases(I think it should work with minimum 14, I’m not 100% sure though). If exact time requirements are a must then I would either recommend a foreground service or just use AlarmManager…

Leave a Reply