lambdasoup

TL;DR:

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:

• Be a good citizen: note clearly in your documentation whether you schedule jobs with the platform JobScheduler and if yes, their (default) jobIds. All it takes are a few lines in the README.
• Enable your users to solve their own problems: Make the jobIds your jobs are using configurable (and provide defaults). You can keep it simple, too: static is perfectly fine for this case (object in Kotlin).

As an app developer:

• Keep an eye out on the libraries you’re using
• Help your friendly library developers: File issues to make them aware of the problem; send pull requests to fix it.

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.