How does doze mode affect background/foreground services, with/without partial/full wakelocks?

Question

This is a simple question, seeing that there is a huge post about this on G+ (here), and lack of information on official docs (here ):

What happens to the app's services when the device goes to "doze" mode?

What does it do to background/foreground services (bound/unbound, started/not-started), with/without partial/full wakelocks?

What would you do, for example, in order to create a service that plays an audio stream while the device's screen is turned off? What if the audio stream is not from a local file, but from the network?

Seeing that there was a claim by Google developer:

Apps that have been running foreground services (with the associated notification) are not restricted by doze.

-yet a lot of discussion after that, claiming this is not entirely true, I think it's quite confusing to know what special background-operations apps should do.

Arawakan

I'm trying to solve that problem in my app for 2 weeks and I didn't find the solution... I have a radio streaming application and I don't know what to solve this.. :( – Wholesale

@Wholesale I've read somewhere that Android N has a bug on Doze mode, that your service should run on a new process in order to solve this. Have you tried it? – Arawakan

Answer 1

Processes which have a current running foreground service are supposed to be unaffected by Doze. Bound/unbound, started/not-started, and wakelocks do not affect this whitelisting process.

However, there is an issue on Android M devices where foreground services are not properly whitelisted when the foreground service is the in the same process as the top activity and improperly dozed.

The fix is available on AOSP and will be included in builds of Android N. It would be up to OEMs to integrate that patch into any Android M builds they produce.

Electrophorus

What happens to background services then? And what should be the base structure solution for the example I've mentioned (music app that plays content, from locale/remote file) ? – Arawakan

Services that are not specifically a foreground service (i.e., they have not called [startForeground](developer.android.com/reference/android/app/…, android.app.Notification))) receive all of the restrictions that apply when dozed - they are not whitelisted. A music playback app should always be a foreground service when actively playing audio as per the Best Practices in Media Playback talk at I/O 2016 and are strongly recommended to be in a separate process (both because it is a good idea and the bug) – Electrophorus

About the example, ok. About the service, what does it mean? Does it mean the service will be stopped? Or does it mean the entire process is frozen (stuck on the same stack-state) and later un-frozen (resume running) ? What happens to Internet connection calls? Do they throw an exception? – Arawakan

Doze does not kill apps nor stop services. The list of doze restrictions is pretty clear on what Doze on Marshmallow does and the Android N docs on Doze explain what restrictions occur when in the non-stationary doze mode. You'll get the exact same exceptions/errors when network access is disabled by doze as you would as if you didn't have any network access at all (say, in airplane mode). – Electrophorus

So it's not killing the process or thread. It's just throwing an exception, which I can handle. I don't see the part that talks about exceptions on Doze mode on the links you've mentioned. Where is it written? – Arawakan

@androiddeveloper - what exceptions are thrown or errors you need to handle depend entirely on what networking library you use. – Electrophorus

An IOException would be the catch all exception – Electrophorus

Say, does doze mode affect apps only if they have targetSdk 23 and above? Or it doesn't matter? – Arawakan

Doze affects all apps, no matter what targetSdkVersion they use – Electrophorus

ok, thanks again. So it might break the way some apps work, no? Too bad. This kind of thing happens on almost every Android version. Google removes a functionality and ruins the way apps worked before. I really hope they will stop it, and instead, always offer alternatives. – Arawakan

None of the best practices changed with API 23: JobScheduler, SyncAdapter, inexact alarms, foreground services, setAlarmClock(), GCM messages to sync, etc all were recommended before and after the introduction of Doze. – Electrophorus

ok, still I don't like how other topics were handled by Google without any consideration of how existing apps work. Here's a tiny example of my spare time app: code.google.com/p/android/issues/detail?id=206047 . Another very old topic (yet still exists even today) is the lack of proper SD-card file handling, as opposed to the pre-4.4 time, where external storage permissions were enough. – Arawakan

So it looks like starting a foreground service in a different process might fix this. Is there another way to do this than adding android:process="xxx" in the manifest when defining the service? – Phia

@Phia - no, that's the only way to set the process used by a service. – Electrophorus

Say, is it now fixed on Android N (the issue of foreground service being in doze mode) ? Also, do the rules for entering Doze mode apply to all kinds of devices out there, or do OEMs change them (or even have the right to do so) ? I mean the time till the device goes to Doze mode, the window duration, etc... About wake locks, what happens when the app has a wake lock and the device goes to Doze mode? Does it lose it? – Arawakan

Does foreground service in separate process prevent both Doze and App Standby, because in my case when I have foreground service in other process and call "adb shell dumpsys deviceidle force-idle" my partialWakeLock and WifiLock got released. Can anybody show some code how to prevent effect from Doze mode? – Tagore

Tested with sample app, I have a background sticky service running continuously(Service has a endless thread ) which does it work and sleeps for 1 minute and wake up again to do it work, still the background service is getting killed and running threads get suspended. Also, tried to run the service in separate process but in vain. If anyone can confirm this behavior as this behavior is not documented anywhere? – Oma

Does a foreground service require a (partial) wake lock? I can't figure that out. – Bistro

Does a foreground service require a (partial) wake lock? I'm running on Android Pie and still a problem. – Anthropoid

I still didn't get it. I am using a Foreground Service and still, I'm unable to wake up the device. as mentioned above if we use the Foreground Service the App didn't get to Doze or Stand by mode. I'm still confused and didn't get any solution yet. – Lyonnesse

highly recommend using a partial wake lock in conjuction with foreground service. note this has battery consequences, and there are other options to explore such as WorkManager that might be better suited in the latest Android ecosystem to do what you need to do – Hubblebubble

WorkManager seems to be using the same old mechanisms under the hood, which can get affected by doze mode (getting killed or deferred until wakeup or until maintenance window arrives). So, what would be the right way to implement an always-alive app that pulls every minute for new user tasks to arrive from the server that does not support FCM? Will foreground service on different process with a permanent notification work? – Tubulure