Completed Android app “Job Demo”:
https://bitbucket.org/ralfoide/misc-exp-public/src/master/android/job-demo/ 

This demonstrates enough of what I want:

• Using JobService and match a required time using a minimum time delay.
• The “old way” of using the AlarmManager has not been used.
• Handling Boot-Received intent with a receiver.

Accessorily, this also has:

• Dagger properly setup with components and one prod-vs-test module.
• Robolectric for the app, activity, with dagger.
• RecyclerView from androidx not using the pesky ListAdapter.
• Using androidx Room DAO for persistence database.

Where to go from there?

As far as a JobService demo is concerned, the current state is good enough. There are a few things that could be done better such as having more robolectric/dagger in place (for example a provider module to replace LocalTime.now() calls during tests) and the event log is a weird mix of both an in-memory list and a Room persistence database (on purpose, to showcase both options).

This is actually a good base to do a T3 rewrite. Is this really what I want?

Per the previous entry, another “small” demo app is to do one running an actual permanent background service, for the typical app case such as dcc controller and others that need to keep a permanent controller running at all times.

Upon scheduling events for many hours during the night (e.g. one per hour), it was clear from the log they did not fire at the expected time when the phone was in Battery Saver mode. Instead they were scheduled all at once after I removed the Battery Saver mode. To be clear, that’s not particularly surprising, but it would require a bit of user education to explain it.

So the next step is to try the Alarm Manager to see how it behaves with the Battery Saver mode.