2

When the screen is off, Android devices usually turn off the CPU and go to a deep hibernation state unless some application is holding a wakelock. The system only wakes up from that state upon device interrupts (e.g. incoming data from the network) or when a scheduled alarm fires. This seems to be very different from a CPU sleep state, where periodic timer interrupts regularly wake up the CPU.

Does this mean that all network events/timers are also suspended (e.g. TCP retransmissions and keepalives), or are they registered as alarms by the Kernel?

I'm wondering if this could interfere with the operation of socket-level keepalives (via the SO_KEEPALIVE socket option). Will this option still work on an Android device, or does this have to be handled by the application on a higher layer?

Community
  • 1
  • 1
lxgr
  • 3,719
  • 7
  • 31
  • 46
  • As far as socket keepalives: No: if the handset goes to sleep, the keepalives stop. But regarding the broader question, "How can I maintain a long-lasting connection": here are some good strategies: [How to make the Android device hold a TCP connection to Internet without wake lock?](http://stackoverflow.com/questions/13534732/how-to-make-the-android-device-hold-a-tcp-connection-to-internet-without-wake-lo) – paulsm4 Jun 17 '15 at 23:32

1 Answers1

1

It seems like sleeping Android devices will not wake up to transmit TCP keepalive segments.

I've tested this with a small test app on a Nexus 5 that sets TCP_KEEPIDLE and TCP_KEEPINTVL to 5 seconds and opens a client socket. In a packet trace, the keepalive segments are clearly visible when the screen is on, but stop while the screen is off.

lxgr
  • 3,719
  • 7
  • 31
  • 46