So if you run e.g. (new JobInfo.Builder(1234, name)).setRequiresCharging(true).setRequiresDeviceIdle(true)... to do something heavy (like reindexing an on-device database) while the phone is charging, that job will simply not be run on some phones. You have to check whether it's been run at app startup, and if necessary run it while the user is actively using your app.
Slack would be fine, I guess.
IMO, the best way to solve this is with an explicit “Let this app run in the background” permission, rather than implementing all these “smart” features which are incredibly non-deterministic. Which leads to developer & user frustration alike.
Take the example of the new “App Bucketing” battery saving feature in Android 9, plus a banking app and WhatsApp....
App Bucketing will basically restrict your background processing based on how often you interact with the app. So for your banking app (where you usually want immediate spending notifications), because you don’t really open the app that often, it’s going to start throttling your notifications (and prevent it from running arbitrary background jobs).
But for WhatsApp on the other hand - because you’ll likely open it more often - it will have full permissions to run in the background any time.
If as a user you wanted to prevent arbitrary WhatsApp background jobs and get instant banking notifications - well tough luck!
I blame it on stock Android. Phone manufacturers probably don't want to spend money on OS changes but Android doesn't do the right thing by default so they have to make changes.
The right thing to do is to deny apps launching at startup, apps running in background, and apps getting network access. Let the user say yes or no. Your use case for signal is different from mine. Maybe I just want to see messages when I open the app?
But yeah I agree, the user should be in control.