Understanding what Doze mode means for your app
Pro-tip by +Joanna Smith
Marshmallow introduced a new way for devices to preserve battery life by going idle. As an app developer, this means that there is now a difference between your app falling out of the foreground and the device itself being idle.
Before you start to panic about how to wake the device from Doze mode (https://goo.gl/eiAJbo), I recommend taking a moment to figure out if you even need to bust through that idleness.
Doze mode is different in that the entire device is taking a nap, not just the least-recently used apps (such is the case with App Standby). Doze mode is activated when the device is not plugged in, when the screen is locked, and when no motion has been detected for some time. These assumptions imply that the user has put down the device and walked away. So, when they come back and pick their phone up off the counter, it should not have dropped to 30% battery. It should, essentially, be in the exact state it was in when they placed it on the counter. Right?
So, the exceptions to Doze mode should be truly exceptional. There are two situations that I believe would qualify. First, if you have new information that is worth causing the user to walk over and look at their phone. Doze mode honors high-priority messages through Google Cloud Messaging (https://goo.gl/v8l1RH), so that you can respond to important moments, such as that new picture Mom just sent. Just don’t use it as an excuse to download a huge amount of data: try instead including the information needed to display a notification in the push message itself, and then fetch everything else when the user returns (and Doze mode ends).
And secondly, you may have work to do that is time-sensitive. But even AlarmManager (http://goo.gl/HDqEwd) is not exempt from Doze mode. However, just because the alarm will not fire during Doze mode does not mean it is lost. For example, an alarm set with setExact() will actually not trigger while Dozing, but will fire as soon as Doze mode exits. And for most use cases, this is actually fine, because if the user isn’t even holding their device, you probably don’t need to be syncing right now. But if you do have a task that is worth draining the user’s battery when they aren’t there, you can rely on setExactAndAllowWhileIdle() to wake your app even during Doze mode. Check out our previous pro-tip (https://goo.gl/IENTID) on working with alarms and background work for more details.
Ideally, Doze won’t disrupt your app flow too much. But spend some time thinking carefully about when your app may need special consideration. And after making any necessary changes, you can spend some more time testing your app. We’ve created several super helpful adb commands (https://goo.gl/8PGom5) to make it easy to see how your app recovers when coming out of Doze mode.
So happy Dozing, developers. And continue to #BuildBetterApps
Pro-tip by +Joanna Smith
Marshmallow introduced a new way for devices to preserve battery life by going idle. As an app developer, this means that there is now a difference between your app falling out of the foreground and the device itself being idle.
Before you start to panic about how to wake the device from Doze mode (https://goo.gl/eiAJbo), I recommend taking a moment to figure out if you even need to bust through that idleness.
Doze mode is different in that the entire device is taking a nap, not just the least-recently used apps (such is the case with App Standby). Doze mode is activated when the device is not plugged in, when the screen is locked, and when no motion has been detected for some time. These assumptions imply that the user has put down the device and walked away. So, when they come back and pick their phone up off the counter, it should not have dropped to 30% battery. It should, essentially, be in the exact state it was in when they placed it on the counter. Right?
So, the exceptions to Doze mode should be truly exceptional. There are two situations that I believe would qualify. First, if you have new information that is worth causing the user to walk over and look at their phone. Doze mode honors high-priority messages through Google Cloud Messaging (https://goo.gl/v8l1RH), so that you can respond to important moments, such as that new picture Mom just sent. Just don’t use it as an excuse to download a huge amount of data: try instead including the information needed to display a notification in the push message itself, and then fetch everything else when the user returns (and Doze mode ends).
And secondly, you may have work to do that is time-sensitive. But even AlarmManager (http://goo.gl/HDqEwd) is not exempt from Doze mode. However, just because the alarm will not fire during Doze mode does not mean it is lost. For example, an alarm set with setExact() will actually not trigger while Dozing, but will fire as soon as Doze mode exits. And for most use cases, this is actually fine, because if the user isn’t even holding their device, you probably don’t need to be syncing right now. But if you do have a task that is worth draining the user’s battery when they aren’t there, you can rely on setExactAndAllowWhileIdle() to wake your app even during Doze mode. Check out our previous pro-tip (https://goo.gl/IENTID) on working with alarms and background work for more details.
Ideally, Doze won’t disrupt your app flow too much. But spend some time thinking carefully about when your app may need special consideration. And after making any necessary changes, you can spend some more time testing your app. We’ve created several super helpful adb commands (https://goo.gl/8PGom5) to make it easy to see how your app recovers when coming out of Doze mode.
So happy Dozing, developers. And continue to #BuildBetterApps
View 188 previous comments
- Hi +Arthur Melo, in the past, I had also the need for obtaining single location updates during an extended amount of time. I employed vanilla Alarms (i.e., I used setAlarmClock method) in addition to the sticky and foreground service technique.
Upon alarm notification, I acquired a wakelock, did my stuff (get the location fix), scheduled a new alarm, and then released the wakelock.
I tried the methods shown in the documentation, but despite their documentation, I couldn't get them to work as expected (the only one that helped was the setAlarmClock one).
I did many tests using Android 6 and 7 with Nexus 6 phones without an issue. Unfortunately, I don't have an Oreo phone to test it. The only price I had to pay, is that the setAlarmClock method causes a clock icon to be shown in the taskbar.37w - +Rafael Pérez-Torres Thx Rafael I will check out the setAlarmClock method, I dont like this solution too but is better than create an FCM process from my server to notify dozed devices and wake then up (this last solution is not feasible in the long term because the amount of devices try to grow a lot in the next months)37w
- Por nada +Arthur Melo ;)
I understand that during the deep doze mode the phone is by definition not moving, issues might appear, but conceptually it seems logical to me. By the way, I noticed incredible energy efficiency improvements between the Android 6-7 and Android 4, for instance, the battery level did not decrease during nights.
Nevertheless, in my case, I was developing a proof-of-concept middleware and I really needed to obtain each single location, sometimes even under a 1 minute period. I think that this is the price we have to pay: in order to obtain better energy efficiency, aggressive power-saving mechanisms are needed. Maybe we could get into a middle point here and provide clear and consistent workarounds for achieving such behavior, however the user should have the last word and agree to use an app that by definition would be more energy consuming than others. Always a trade-off ...37w - +Rafael Pérez-Torres I agree with this aggressive power saving method, however the documentation about wakeup app for get locations and network access could be much clearer with effective methods for all types of devices and their OEM versions, or maybe the location changer sensor more effective to wake from doze (like the documentation says it does)37w
- +Arthur Melo If the device isn't actually going out of deep doze when it is moved around, that is a bug in the underlying system that it is pointless to try to work around. When in deep doze, location services are basically turned off, wifi scans are turned off, etc, so it is just not going to be functional as expected. So trying to make things work like you are at that point is just going to be endless futility, it won't. The question is why it isn't coming out of deep doze -- the system basically just registers with the Significant Motion Detector and as soon as that triggers it leaves deep doze, so my first guess is something going wrong with the SMD. One thing you could do is try writing an app that just monitors the SMD and see if it is triggering as it should.
+Rafael Pérez-Torres Please do not use setAlarmClock for anything but alarms. The documentation is pretty clear about this -- https://developer.android.com/reference/android/app/AlarmManager.html#setAlarmClock(android.app.AlarmManager.AlarmClockInfo,%20android.app.PendingIntent) -- if you don't use this for its intended purpose (the schedule a user-visible alarm clock alarm), you will mess up the user's experience because they will be told about an upcoming alarm that they did not schedule and will not actually go off for them. Plus this has a tremendously negative impact on battery life, since it is telling the system to prepare to fully wake up the device (including turning the screen on) when that alarm goes off. The correct thing to do is use the setXxxAndAllowWhileIdle() methods, which will be allowed trigger while the device is dozing, though throttled (but that is very desired because causing the device to wake up frequently will very negatively impact battery life in these states).37w - +Dianne Hackborn Thanks for the clarification. It was not my intention to propagate bad practices or something like that. I just wanted to share what actually worked for the specific requirements of my research implementation. For this proof of concept, the throttle you mention was affecting a learning phase, I am aware I was putting the smartphone at the limit. Again, it is not my intention to encourage bad practices.37w
Add a comment...