30

According to the documentation, jobs must have a unique Job ID per uid.
If I use a 3rd party library which also schedules jobs, does this mean I can't use the same Job ID as theirs? If so, how can I avoid these kind of collisions?

Ori Wasserman
  • 962
  • 1
  • 10
  • 24

2 Answers2

15

If I use a 3rd party library which also schedules jobs, does this mean I can't use the same Job ID as theirs?

Correct.

If so, how can I avoid these kind of collisions?

Ask the developer of the library what job IDs they use, or if those job IDs are configurable somehow.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 1
    Is there a more feasible solution? If using JobScheduler (which is now becoming mandatory) requires me to communicate with every 3rd party library I use and follow their updates then it sounds like a serious design flaw... – Ori Wasserman Jun 07 '17 at 14:31
  • 1
    @OriWasserman: "Is there a more feasible solution?" -- don't use third-party libraries that in turn use `JobScheduler` and also do not provide details or configurability. "which is now becoming mandatory" -- I would describe it as "more important". "then it sounds like a serious design flaw" -- correct. However, by definition, there is no way to generate a unique number that cannot also be generated by something else. Using a random integer makes *unlikely* that you will collide with something, but unlikely != impossible. – CommonsWare Jun 07 '17 at 14:36
  • @OriWasserman: They specifically advise against using a resource-generated value (e.g., an `id` resource), saying "You will want to make sure this is a stable id across app updates, so probably not based on a resource ID". So, there is no system-supplied way of ensuring that you do not collide on job IDs. – CommonsWare Jun 07 '17 at 14:37
  • 1
    @OriWasserman: You can use `getAllPendingJobs()` on `JobScheduler` to find out what IDs are already used, so you can avoid colliding with those. But, libraries may not do that, and there are race conditions, so this is only of modest benefit. It is not a guarantee that the ID that you use is not going to be used simultaneously or later by a library. – CommonsWare Jun 07 '17 at 14:41
  • 2
    @OriWasserman: BTW, and FWIW, I wrote [a blog post](https://commonsware.com/blog/2017/06/07/jobscheduler-job-ids-libraries.html) with more about this topic. Thanks for pointing out this issue! – CommonsWare Jun 07 '17 at 23:02
  • Awesome! Thanks for investing your time in this – Ori Wasserman Jun 08 '17 at 07:33
  • Assuming the library exposes a way to avoid collisions, you can create a Manager class to coalesce the two ID types. https://android-developers.googleblog.com/2017/10/working-with-multiple-jobservices.html – AtomicBoolean Jan 14 '19 at 20:01
1

If asking the developer of library doesn't work, you may want to calculate md5 on package name and pick last 4 bytes as unique id. The chances of collision will be quite less.

bbindra
  • 41
  • 3