The social media apps will almost certainly use Googles push notification service, which is the only background notification allowed.
Your imap client is trying to hold a TCP connection open to your server, which isn't allowed.
There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of apps can be listening for notifications at once, with no system resource overhead.
Secondly, imagine every app wanted to have a TCP connection open to it's own server. TCP must generally go through your wifi/3g providers NAT. That NAT gateway will drop idle connections, with the rules on which connections are dropped varying for every type of router and provider. In general, if you want reliable delivery, you're going to have to send some packet down a TCP connection every 5 minutes, although some providers it can be up to every 3 hours. If every app applies it's own heuristics to figure out how often to send a keep-alive message, and you have hundreds of listening apps each with their own connection, and no synchronisation between them, your phone will end up waking up every few seconds for some app to send a keep-alive.
Instead, Google keeps open just one connection. They have a serverside database of all network providers to know which ones drop connections when (BTW, this is a big advantage of using your cable providers default modem. If you have your own modem, this mechanism won't be accurate). It can then wake up and send just one keep-alive at the exact correct time.
From the server side, Google can batch messages to clients. It can decide that receiving 8 new marketing emails is important enough to sync to your phone, but only if the phone will be waking up for some other reason. Then when a snapchat message comes in, both the mail app and snapchat will be notified by a single wakeup of the phone.
Overall, it's a very good design. There are only 2 big downsides:
1) It's centralized. Nobody else can run a notification server. They have a monopoly on delivering notifications.
2) Their server isn't very good. It doesn't have the capability for example to simultaneously listen on 3G and wifi. It sometimes gets overloaded and unnecessarily delays messages. Their database of network providers is sometimes a bit off, meaning your phone is sending keep-alives every 30 minutes, while the connection times out after 20 minutes, meaning there is a 33% chance your message will get delayed by up to 10 mins.
Yeah, I don't really expect a mobile O/S to keep connections open indefinitely. It's hard enough to do that when the phone is awake and on the move, much less sleeping.
The O/S should, however, honor an app's request to wake up every 5-15 minutes to open a new connection, do some things with it, and go back to sleep. Especially if the user has given explicit permission to let the app in question use all the battery it wants. Periodic wakeup is what most email apps expect when they're set to "polling" mode. It used to work perfectly until about two years ago. It doesn't work anymore on recent Samsung phones. The system just ignores the wakeup schedule set by the app.
I'm not sure anyones written it up yet. You can see it for yourself if you run adb logcat on a sleeping phone. Try running it on different networks and see the keep alive period. (you'll have to turn off all push notification sources, because a push message counts as a keep alive too).
Your imap client is trying to hold a TCP connection open to your server, which isn't allowed.
There's a good reason the phone doesn't allow that. Firstly, the push notification service can be waiting for a notification for an app while the app is entirely unloaded from RAM. Hundreds of apps can be listening for notifications at once, with no system resource overhead.
Secondly, imagine every app wanted to have a TCP connection open to it's own server. TCP must generally go through your wifi/3g providers NAT. That NAT gateway will drop idle connections, with the rules on which connections are dropped varying for every type of router and provider. In general, if you want reliable delivery, you're going to have to send some packet down a TCP connection every 5 minutes, although some providers it can be up to every 3 hours. If every app applies it's own heuristics to figure out how often to send a keep-alive message, and you have hundreds of listening apps each with their own connection, and no synchronisation between them, your phone will end up waking up every few seconds for some app to send a keep-alive.
Instead, Google keeps open just one connection. They have a serverside database of all network providers to know which ones drop connections when (BTW, this is a big advantage of using your cable providers default modem. If you have your own modem, this mechanism won't be accurate). It can then wake up and send just one keep-alive at the exact correct time.
From the server side, Google can batch messages to clients. It can decide that receiving 8 new marketing emails is important enough to sync to your phone, but only if the phone will be waking up for some other reason. Then when a snapchat message comes in, both the mail app and snapchat will be notified by a single wakeup of the phone.
Overall, it's a very good design. There are only 2 big downsides:
1) It's centralized. Nobody else can run a notification server. They have a monopoly on delivering notifications.
2) Their server isn't very good. It doesn't have the capability for example to simultaneously listen on 3G and wifi. It sometimes gets overloaded and unnecessarily delays messages. Their database of network providers is sometimes a bit off, meaning your phone is sending keep-alives every 30 minutes, while the connection times out after 20 minutes, meaning there is a 33% chance your message will get delayed by up to 10 mins.