This is true with current implementations, but it doesn't have to be true.
Coordinated CPU wakeups and radio packet timings would mean the power consumption from waking the radio would be not much larger with 5 apps than 1.
It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and it doesn't have to go through one shared cloud service provider as it is now.
It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.
> it doesn't have to go through one shared cloud service provider as it is now.
This is more true, for example you could have an open protocol and an app could register with the push daemon. It would be impossible to consolidate push notifications or throttle them for bad actors though.
A single daemon, or a single kernel, it doesn't really matter which.
I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings.
The underlying mobile network registration for notifications is already quite low level.
> It would be impossible to consolidate push notifications or throttle them for bad actors though
At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter.
For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group.
For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast.
Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.
The savings are from letting radio go to idle. If you have more than one (ideally non-cooperating) services that are keeping the radio permamently on, you won't ever get to idling and say good bye to battery.