Wakelock and doze mode

Question

According to Android Marshmallow documentation when the system is in doze mode, any wakelock is ignored. However it's not clear to me if a wakelock prevent doze mode or not.

Answer 1

Based on some testing, using a Nexus 5 with the the final(?) preview of Android 6.0 installed:

• Holding a PARTIAL_WAKE_LOCK is insufficient to block Doze mode — the device will still doze, even though you have the WakeLock and are trying to do regular work (e.g., setExactAndAllowWhileIdle() to get control every minute)

• Keeping the screen on using android:keepScreenOn (or the Java equivalent), with the screen on, is sufficient to block Doze mode

• Keeping the screen on using android:keepScreenOn (or the Java equivalent), with the screen off (user presses POWER button), is insufficient to block Doze mode

IOW, video players and the like should not be affected while the user is watching the video, even though the player may not be moving or charging. However, if the user presses the POWER button, you're back into having Doze risk.

I have not tried using FULL_WAKE_LOCK (I would expect behavior identical to android:keepScreenOn, but I am far from certain).

Answer 2

Interesting

Google's own clock app in Android 6.0 is able to block Doze mode altogether:

1. In the clock app set an alarm with a time < 60 minutes from now
2. Turn off the device
3. In the console set $adb shell dumpsys battery unplug
4. In the console set $adb shell dumpsys deviceidle step

The state remains as 'Stepped to: ACTIVE'

If you set an alarm with a time > 60 minutes from now, it works normally (device may go into idle states). BUT once the alarm is < 60 min away it seems that the device quietly awakes from Doze idle, as the state returns 'ACTIVE' again (instead of 'IDLE_MAINTENANCE').

I really wonder how they are doing this!

- EDIT -

It seems to be setAlarmClock() that is having this behavior by default. This might be helpful for some use cases.

Answer 3

In response to the comment discussion above, this is not an answer to the question. It's meant to clarify app behaviour in Doze mode in general. In my testing app, I tried to get a GPS position every 2 minutes, GPS signal strength was sufficient at all times.

Testing conditions:

• Nexus 9, Android M Preview, Build MPA44I
• "ignore optimizations" ON
• setExactAndAllowWhileIdle() with 2 minute interval
• each operation has a 1 minute timeout for getting a GPS fix and is surrounded by a partial wakelock
• logs were written to SQLiteOpenHelper.getWritableDatabase()

GPS test log for Doze mode:

1   2015-09-04 - 12:14  GPS ok (device left stationary unplugged)
2   2015-09-04 - 12:16  GPS ok
3   2015-09-04 - 12:18  GPS ok
4   2015-09-04 - 12:20  GPS ok
5   2015-09-04 - 12:22  GPS ok
6   2015-09-04 - 12:24  GPS ok
7   2015-09-04 - 12:26  GPS ok
8   2015-09-04 - 12:28  GPS ok
9   2015-09-04 - 12:30  GPS ok
10  2015-09-04 - 12:32  GPS ok
11  2015-09-04 - 12:34  GPS ok
...
31  2015-09-04 - 13:14  GPS ok
32  2015-09-04 - 13:16  GPS ok
33  2015-09-04 - 13:18  GPS ok
34  2015-09-04 - 13:20  GPS ok
35  2015-09-04 - 13:22  GPS ok
36  2015-09-04 - 13:24  GPS ok
37  2015-09-04 - 13:26  GPS ok (entering Doze mode some time after)
38  2015-09-04 - 13:42  GPS failed, active millis: 60174 (idle)
39  2015-09-04 - 13:57  GPS failed, active millis: 60128 (idle)
40  2015-09-04 - 14:12  GPS failed, active millis: 60122 (idle)
41  2015-09-04 - 14:16  GPS ok (idle maintenance)
42  2015-09-04 - 14:18  GPS ok (idle maintenance)
43  2015-09-04 - 14:20  GPS ok (idle maintenance)
44  2015-09-04 - 14:22  GPS ok (idle maintenance)
45  2015-09-04 - 14:38  GPS failed, active millis: 60143 (idle)
46  2015-09-04 - 14:53  GPS failed, active millis: 60122 (idle)
47  2015-09-04 - 15:08  GPS failed, active millis: 60068 (idle)
48  2015-09-04 - 15:23  GPS failed, active millis: 60138 (idle)
49  2015-09-04 - 15:38  GPS failed, active millis: 60140 (idle)
50  2015-09-04 - 15:53  GPS failed, active millis: 60131 (idle)
51  2015-09-04 - 16:08  GPS failed, active millis: 60185 (idle)
52  2015-09-04 - 16:12  GPS ok (ending Doze mode - power button on)

Now that I looked at my logs again, I noticed a very strange behavior: The same test with "ignore optimizations" OFF showed basically identical results (like it should), BUT most of the times the timeout did not work as expected, I got 'active millis' in the range of either ~330000 (~5 times timeout time) or even ~580000 (~10 times timeout time) while idle. This weird behavior I can not explain, but it seems to show that there actually IS some effect of the setting of "ignore optimizations" on Doze mode.

Edit: The 'strange' behavior described above is just now documented: Only with "ignore optimizations" ON, you may hold a partial wakelock in Doze idle mode.

Answer 4

As far as I have explored, all wake locks (except the ones held by apps with a current foreground service) are dropped when the deeper doze starts. The whole point of doze is to let the system sleep when the 'relevant conditions' set in. So yes locks is not something they would care too much about I guess.

The way I see it JobScheduler is the way to go about scheduling, background tasks etc in future. Takes some control away from developers though but that's the call I guess framework guys took for battery life. It's more like 'trigger and hope things will happen more or less on time'.

Coming to your use case, JobScheduler has an onStopJob callback to know when the execution of your job has stopped [for any reason - say wifi was toggled] you need to take appropriate action such as rescheduling your job for the next maintenance window. From the docs:

One immediate repercussion is that the system will cease holding a wakelock for you.

Answer 5

What I found in Android 13 (On a Google Pixel 7 Pro) is that setExactAndAllowWhileIdle() actually works, provided the user manually disables the battery optimizations for the app. This is done in the app's battery usage setting, as described here.

I couldn't figure out how to do this in Android 10 on a Huawei P20 Pro, but I didn't try too hard.

So my suggestion is to first experiment with a number of phones to get a better understanding of how things work on various Android versions and phone networks.

Then change your app to check the setting and tell the user if a change is needed, offering to open the app's settings. (Keep in mind that you don't usually know how the phone manufacturer or the network customized the phone, so the instructions might not match reality if they are too detailed.)

Also, in your app, check if your function is called late, and if so, tell the user to contact you to troubleshoot it.

I don't think the battery usage setting can be changed programmatically. I wasn't even able to open the corresponding setting UI (even after adding what I thought would be the necessary permission), but only the generic settings page, and the user can navigate from there. So:

// Check doze setting
PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
boolean ignoring = pm.isIgnoringBatteryOptimizations(getPackageName());

// Show the app's setting window
Intent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
Uri uri = Uri.fromParts("package", getPackageName(), null);
intent.setData(uri);
startActivity(intent);