Shouldn't TCP keepalive at the kernel level be able to handle it?
Conversation
The device goes to sleep though and that's not going to wake it up. The only way it could work is if it was offloaded to hardware that kept running. It's totally possible that exists, I don't know.
2
But kernel can and *should* schedule periodic wakeups just to do stuff like keepalive. Unlike gigantic userspace apps it could do it very efficiently.
2
Apps aren't allowed to keep the device awake or trigger waking it up whenever they want though, so it can't apply to every usage of stuff like TCP keepalive. It's also really best if every single app needing push notifications isn't trusted to do it right themselves.
1
Well now we're getting into the domain of Android policy (and why it's idiotic). Mobile OS should just force-suspend any app that consumes more than X% of cpu while in background, letting them use standard APIs like TCP keepalive but suffer consequences if they do it wrong.
1
Waking up the device frequently is a bigger battery drain than doing it very infrequently but using a lot of CPU. It gets to sleep for long periods of 30+ minutes at a time on a reliable network. It always tries to get back to sleep very fast but apps will stop that.
2
Most apps will ruin battery life if given the opportunity. Simply something like an email app that wants to poll every minute and is too lazy to come up with a push system for email since it's not part of the baseline email standards and they don't want to run a push server, etc.
1
And it's basically every app that will do it, so if the user has 50 apps they've got 50 things keeping the device awake with wake locks or constantly waking it up, with the intervals not lining up well. OS has to be heavily involved in scheduling / alarms / timers to work well.
1
Disallow sleeps/timeouts. Only allow indefinite blocking on IO.
1
(Sleep or timeout while in background gets translated to indefinite sleep until brought back into foreground.)
1
That's already essentially how everything works. An app can be actively doing things and the device is still going to go to sleep and the app will keep doing whatever it was doing as soon as the device wakes up again. Wake locks are needed to force it from going to sleep.
It's always right about to suspend when the user isn't actively using it unless something is holding a wake lock. The restrictions are on wake locks and scheduling wake ups like alarms or job scheduling for efficiently scheduling background work.
1
Push notifications are an exception that's mostly always allowed. Without GCM or an alternative, regardless of how that alternative is implemented (many connections to different servers, one connection), users end up needing to grant apps exceptions from the rules - not ideal.
1
Show replies