Understanding & testing Android M+ Doze Mode

Question

I am working on making my Android app a good citizen of the post Android M world which imposes severe constraints on what an app can/cannot do when the device goes into doze. My understanding of the issues involved is still rather fragmentary so I am hoping that someone here can fill the gaps.

The duration of doze

My own empirical findings here

Doze first starts within about half an hour of stationary, screen-off, inactivity
The first maintenance window happens within 30 minutes
The next one happens in about an hour
The ones after than in ca 2, 4 and 6 h. I have not tested beyond that

Are these the official Android doze periods or is it just one empirical observation.

All of the above on an Android N device.

Testing Apps in Doze Mode

Connect the device to a computer with ADB
Bring the app to the foreground
Turn off the device screen
From the command line issue adb shell dumpsys battery unplug
Now cycle through the commands `adb shell dumpsys deviceidle step light OR deep
finally issue adb shell dumpsys battery reset

Entering/Exiting Doze

Happens when the screen is off and the device is not being subjected to movement
Presumably this uses the motion sensor in the phone so a phone sitting quietly on a remarkably smoothly moving train will still enter doze?
If I pick up a dozing phone and start walking around with it without otherwise interacting with it will it automatically exit doze?
Suppose my app is not in the foreground when its host device enters doze. Then I start using the device again but without visiting that app. Will it automatically start "working" again, i.e.
Its broadcast receivers will become functional?
Its handlers will start working?
Its scheduled jobs with setRequiresDeviceIdle(true) will stop being called?

The various modes of Doze & Job Scheduling

From what I have understood there are two doze modes LIGHT & DEEP. They both have sub-modes
LIGHT:Active, Idle, Idle_Maintenance,Override. I do not understand what the various modes do. From ADB I have issued step light with the screen on and seen the return value ACTIVE. With the screen off step light returns IDLE.
DEEP: Active,IDLE_PENDING,SENSING,LOCATING,IDLE,IDLE_MAINTENANCE with the screen on too returns ACTIVE but with the screen off it returns IDLE_PENDING. So when exactly do the other sub modes, IDLE, SENSING... happen?

I assume that IDLE_MAINTENANCE happens when the device enters a maintenance window from DOZE and attempts to run pending Job requests from various apps.

But if that is the case why is it that PowerManager.isDeviceIdleMode() and PowerManger.isPowerSaveMode() ALWAYS return false when I check them when a schedule job in my app runs?

JobInfo.Builder very kindly allows you to set criteria such as setMinimumLatency and setOverrideDeadline but as far as I can tell the OS hen goes and blithely ignores them - at times I have had jobs running withtin seconds of each other and at other times as far as two hours apart.

Why is there no API function to test for Doze and its sub modes? I would expect to find it in PowerManager but all I find there are isDeviceIdleMode and isPowerSaveMode which consistently return false whenever tested

The App in Doze Mode

Will have all its background services destroyed?
Will not get normal priority push messages?
Will not respond to alarms - but is that with the exception of setAndAllowWhenIdle?
Will get no comms from any of its broadcast receivers?
Will not be able to connect to the outside world on sockets - so push messaging, pub/sub etc will not work?
Will immediately destroy any broadcast receivers declared in the Android manifest. This has been my own finding - receivers that I create from Java code stay put, though they do not work during doze.

My own app watches for geo location changes by setting up a broadcast receiver and calling .FusedLocationApi.requestLocationUpdates. This receiver survives the doze/wakeup cycle. However, is there a guarantee my LocationUpdates request still being honored after wake up?

I have run into a rather peculiar bug. I found that my scheduled jobs in doze ran too close to one another on occassion even though I have given them a latency of 900,000 ms (15 minutes) and a deadline of 1,000,000 ms. I thought I would get round this by testing for the last time the job was run by keeping track of the last run time which I did thus

private static Boolean shortInstantGap()
{
  Long instantNow = Instant.now().getEpochSecond();
  if (300 > (instantNow - this.lastInstant)) return true;
  //ignore the job opportunity if the last one was
  //less than 300s (5 minutes) ago
  this.lastInstant = instantNow;
  return false;
 }

and then aborting the job slot

private static Runnable timeRunner = new Runnable() 
{
 @Override
 public void run() 
 {
  if (shortInstantGap()) return;
  callMyHandlerCode();
 }
};

However, I found that this code causes the OS to abruptly terminate my app if it is on screen when I go through a screen-off screen-on cycle. Why was that happening?

Finally, is there not an API call I can use to test that the device has just returned from doze so I get an opportunity to do some post doze housekeeping?

Understanding & testing Android M+ Doze Mode

Answers (1)

Related Questions

Understanding &amp; testing Android M+ Doze Mode

Answers (1)

Related Questions

Understanding & testing Android M+ Doze Mode