2

I'm having a hard time understanding the purpose of WakeLock in modern versions of Android, after the introduction of Doze and Foreground Services.

It appears as if WakeLocks are pretty much legacy as this point (although not marked as deprecated), replaced by Foreground Services (as WakeLocks are not actually respected by Doze).

From the documentation: "One legitimate case for using a wake lock might be a background service that needs to grab a wake lock to keep the CPU running to do work while the screen is off" - But this isn't really true anymore after the introduction of doze and foreground services, is it?

Is there still a legitimate use case for using WakeLocks (instead of e.g. a foreground service)?

user1202032
  • 1,430
  • 3
  • 15
  • 36

1 Answers1

4

Foreground services still don't keep the CPU awake - for that you still need a wakelock. Cases like ongoing media playback would need both a foreground service (to keep the process alive and to allow wakelocks while the rest of the system is dozing) and a wakelock itself (to keep the actually media playback happening).

ianhanniballake
  • 191,609
  • 30
  • 470
  • 443
  • What does "keep the CPU awake" *actually* mean though? If you have a background service, a wakelock will not keep it running. If you have a foreground service, the foreground service will let you run code without a wakelock – user1202032 Nov 01 '18 at 01:34
  • 1
    They're two completely different layers. Foreground services only affect the [process priority](https://medium.com/androiddevelopers/who-lives-and-who-dies-process-priorities-on-android-cb151f39044f) of your app, which only affects what happens under memory pressure. That's is entirely different than whether a message posted to a Handler is delayed until some other app wakes the CPU up or whether a `MediaPlayer` continues to process stream data. – ianhanniballake Nov 01 '18 at 04:56
  • Sure, but i dont think thats actually true. If wakelocks does not prevent your service getting killed, i still dont see the point of requesting one in an app. If you have a foreground service, you're (supposedly) not getting killed, and you can continuously execute code. The docs specify foreground service as *the* way to execute long-running operations in the background – user1202032 Nov 01 '18 at 05:22
  • The specific android components (MediaPlayer, LocationListener, BluetoothAdapter) all behave differently, irrespectively of a wakelock being hold or not – user1202032 Nov 01 '18 at 05:28
  • 1
    The reason that [setWakeMode](https://developer.android.com/reference/android/media/MediaPlayer#setWakeMode(android.content.Context,%20int)) exists and [ExoPlayer specifically calls out wakelocks](https://google.github.io/ExoPlayer/faqs.html#how-do-i-keep-audio-playing-when-my-app-is-backgrounded) are because they are absolutely necessary. Just because you are in memory does not necessarily mean the CPU is awake to output audio, send broadcasts to other components, or do anything at all. – ianhanniballake Nov 01 '18 at 06:02
  • setWakeMode is interesting. It does indeed acquire a WakeLock but it also uses it to keep the screen on. I made a small app to test MediaPlayer specifically without any WakeLocks, and tested it on high-end and low-end phones running android 4.4, 8.0 and 9.0. After 30 hours non-stop use it never stutters, pauses or stops. Similar i can make a foreground service with an infinite loop outputting to logcat - it always runs (until the service is killed and restarted upon which it starts outputting again). So i have to ask again, what *exactly* is meant by "keeping the CPU awake"? Whats the usecase? – user1202032 Nov 03 '18 at 22:57
  • Try this: use Handler.postDelayed() to post a log message every 60 seconds. Turn your screen off and see if it continues to log every 60 seconds. Now try the same thing with a RTC (not RTC_WAKEUP) alarm. The issue is when the CPU has no work to do and goes to sleep. Not having a wakelock means it can sleep for quite a long time even if you queued work up to do. – ianhanniballake Nov 03 '18 at 23:17