JobIds are the new IRQs

Juliane Lehmann / Tue, Sep 5, 2017


Everything is better with a silly meme.

Everything is better with a silly meme. (thanks imgflip!)

Remember the days before plug-and-play? When you had to manually configure IRQs on your hardware, taking care to have no overlaps, hoping that it’s even possible without overlaps? If not, be glad… The bad news is: If you’re an Android software developer, thanks to Android Oreo’s background execution limits forcing the use of JobScheduler, those days are sort of back. Good news: this time, it’s all software, and we as a community can collectively make things work.

What’s the actual problem? Well, due to the new background restrictions in Android Oreo, we must offload most kinds of background work into JobScheduler jobs. The support library itself recognizes this, e.g. offering JobIntentService as a drop-in replacement for IntentService. Reading the documentation and source for JobIntentService shows the problem: As an implementor, you must choose a jobId. And jobIds identify the specific job for purposes of enqueuing more work, canceling it, rescheduling it, persisting it over device reboots - and the scope in which they do so is the uid, so at least the complete app, including libraries (might be larger, but then you’d know about it already). So to do all this, jobIds must stay fixed over process death, and they must be unique in this scope.

Certain libraries need to schedule jobs - prime example is any JobScheduler backport; another example close to my mind is BLE beacon scanning, and I’m sure there are many more. Having everyone pick jobIds at random and hoping for the best is an approach; but as a community, we can do better.

As a library developer:

As an app developer:

After writing this, I found that of course Mark at the commonsware blog has already made the same point ages ago. Still, the silly meme stays.