[Andrew_nenakhov]

Nobody was saying that every app needs to run in the background to deliver you notifications. I was arguing that for some apps background functionality is essential, and such functionality is obstructed by OS vendors, who strive to tie all background work to push notifications.

[thebean11]

Sure, I agree with you there, but background app permissions and push notifications seem like pretty separate issues.

[Andrew_nenakhov]

They are totally not, because whenever you need an app do something, like, display a message sent to you, the 'official' way is to do it via push notifications. But if your user doesn't use Google Play services, you have to make the app run in the background, which is increasingly difficult in Android (and impossible in iOS).

[shadowgovt]

Hypothetically, an Android vendor could build a notification service separate from Play Services and deploy it on their Android builds. Has to be a vendor (or, more broadly: "someone who controls the OS down to the kernel level") because the notification technology involves some heavy abstraction-breaking footsie between the physical link layer and the TCP stack.

But the two big challenges there are:

- odds are the first several iterations of it will suck, so they'll be competing with an already-working solution that most users have no concerns using (significant market uphill fight, with the only major value-add being "We're not Google").

- we've just traded one master for another. Ultimately, unless someone builds an open-standard at the Android distro level that includes an API to allow users to establish a notification source, the distro owner still owns the notification system (and there's no reason a priori to assume they're less evil than Google). And designing that API to be abuse-proof would be a challenge; do it wrong, and we're back to the bad old days of sub-one-day battery life on an idle phone.

It'd be a hell of a cool project for someone to take on though.