Can Wi-Fi or the CPU go to sleep when screen is on?

Question

There are WakeLocks and WifiLocks on Android -- but do I need these if my screen is never turning off?

I'm using persistent connections (e.g. WebSockets) for dozens of minutes or even hours. Will my screen being always on be sufficient to prevent the device from losing those connections (if we assume that the connection remains available and the server is fine)?

To keep the screen on, I use the standard way:

getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);

What the docs say:

To avoid draining the battery, an Android device that is left idle quickly falls asleep.

(https://developer.android.com/training/scheduling/wakelock.html)

Normally the Wi-Fi radio may turn off when the user has not used the device in a while.

(http://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.html)

Does this mean that ...

the Wi-Fi radio or the CPU may go to sleep mode or turn off when the user does not interact with the device for a longer time (even if the screen is still on)?

And, more specifically, may a background task's (e.g. IntentService) Wi-Fi or mobile data connection go to sleep when there is still an Activity that keeps the screen on?

Answer 1

Can Wi-Fi or the CPU go to sleep when screen is on?

No.

There are WakeLocks and WifiLocks on Android -- but do I need these if my screen is never turning off?

I am not quite clear how your screen is never turning off. At the end of the day, AFAIK, a WakeLock is always involved. Whether you need the WakeLock or whether that WakeLock is managed by framework classes (e.g., android:keepScreenOn) or the OS (e.g., Settings option to keep the screen on), would depend on what you are doing.

I have never seen an Android device power down WiFi while the screen is on (and not at the lockscreen). I can't rule out the possibility that WiFi might be powered down due to low battery conditions in some manufacturer's extreme power-saving mode.

Will my screen being always on be sufficient to prevent the device from losing those connections (if we assume that the connection remains available and the server is fine)?

I would phrase it more as "keeping the screen on will help". Or, better, letting the device go into sleep mode will normally drop your WiFi connections.

To keep the screen on, I use the standard way: getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);

Which means that you're using a WakeLock. It just so happens that it is one that is managed for you, and since you can't screw it up, you don't need the WAKE_LOCK permission.

the Wi-Fi radio or the CPU may go to sleep mode or turn off when the user does not interact with the device for a longer time (even if the screen is still on)?

For a normal device, no. I can't rule out some manufacturer doing some sort of e-ink thing that might have that behavior.

And, more specifically, may a background task's (e.g. IntentService) Wi-Fi or mobile data connection go to sleep when there is still an Activity that keeps the screen on?

It shouldn't. In particular, the mobile data connection never goes to sleep.

---

All this being said, the reliability of what you are doing is going to suck unless this is a completely controlled environment. You are making a lot of assumptions:

• Some sort of permanent power source

• Nobody messing with the device to move your activity to the background or BACK button out of it

• Nobody messing with the WiFi network, either in general or fussing with settings on the device (e.g., putting it in airplane mode)

• Etc.

If this is some sort of industrial process monitor or in-kiosk device, the odds of you controlling these things perfectly is decent but not great. You get much beyond that, and the odds of these things holding up tail off rapidly.

---

Do you have any references?

In an ideal world, all of this would be perfectly documented, there would be peace among all peoples, and Hayley Atwell would think that I'm a decent chap.

This is not an ideal world.

Not only is this stuff largely undocumented, but it is really up to the device manufacturers. That's why if this is not a very controlled environment, while you are welcome to try to get this sort of behavior, the real world is very messy, and you should not assume that you can keep a connection open indefinitely.