Google & manufacturerers have gone too far in the quest for the Holy Grail of extending battery life. To the point where it’s negatively affects the user experience quite often (there are quite a few examples in these comments).

It makes Android overall seem more buggy (for example, not receiving notifications for an instant messaging app is pretty ridiculous, assuming I’ve opted in and want these notifications).

One other big issue is that push-based wake-ups on Android don’t work reliably. For example, on iOS, if you want to wake up the app in the background when you come in range of an iBeacon, you can do so (with user permission), and it just works. Meaning you don’t need to run a special arbitrary background job (which is much less battery efficient).

On Android - BLE wakeups are so incredibly unreliable that entire classes of apps are becoming less and less viable. And without the loophole of running background jobs to manually scan for beacons, users (and developers) are basically shit out of luck.

But there are many people with varying use-cases - some of whome want reliable BLE detections on their devices. And if they opt-in to these notifications, then it’s a shitty experience when it doesn’t actually work as intended.

Never have, got 'location related alerts' a few times before I figured out how to switch them all off, without ever having opted in.

To be fair I have no idea if these were BLE related, but they were annoying.

Do instant messaging apps really need to be running to listen for notifications? Why isn’t listening for notifications being handled by one central Android process that then dispatches it and launches the app if necessary?

And, in Android 9, “App Buckets” will increase/decrease throttling depending on your usage of the app.

For example, an app that you don’t open regularly, but do want receive timely notifications from (like a banking app, or calendar/scheduling app), might only get 1 window a day where it receives notifications.

The former should always get to the user, the latter on iOS is controlled by both the OS based on an algorithm and by the user who can specifically turn off background processing on a per app basis on iOS.

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.

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.

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!

Point being the majority of the apps are badly coded to poll or drain battery, send unnecessary notifications.

This reminds me of the popup blocker thing in web browsers. While there were some legitimate uses most of the time it's abused so every browser blocked it.