How to opt-out my app from android M DOZE mode ?
Is there a standard way to include and exclude apps from DOZE and auto standby selectively at run time ?
How to opt-out my app from android M DOZE mode ?
You can't by any known mechanism.
Is there a standard way to include and exclude apps from DOZE and auto standby selectively at run time ?
In theory, the user can toggle an "Ignore optimizations" option in Settings, to put the app on a whitelist of apps that should not go into app standby mode. This will not affect doze mode.
Quoting somebody who I believe is Dianne Hackborn:
While the device is dozing, syncs and jobs are turned off globally, putting an app on the whitelist does not change the behavior for them. This is the intended behavior, as is the lack of free use of the alarm manager. (One of the key aspects of all of these is that they are ways to cause the device to wake up, and anything that causes it to wake up will have a significant impact on battery life in the durations we want to last while dozing, so it is simply not allowed.)
While dozing, the AndAllowWhileIdle APIs allow you to wake up the device at most once every 15 minutes; when not dozing this is raise to once every minute. When the device is in idle maintenance mode, all of the doze restrictions are removed (so AllowWhileIdle can happen once a minute).
Note that "idle maintenance mode" is presently undocumented. My guess is that this refers to a device that is idle but is charging.
Related
I have found the reference to "*alarm*:*job.heartbeat*" in JobSchedulerService.java and it appears that as the name of file suggests, "*alarm*:*job.heartbeat*"is related to scheduling of jobs and when I took the log of dumpsys batterystats, I found out that every 30 minutes, the phone come out of doze by this "*alarm*:*job.heartbeat*". What is the role of "*alarm*:*job.heartbeat*" and can we configure the interval? (I'm rooted)
I think it is related to the android standby bucket. and maybe android 9 adaptive battery. and it is deeply integrated into the system. so it is not as simple as a system app uninstall. and the process is responsible for it is (system_server) .and if you delete it you will have to re-flash your ROM. and using Battery Historian *alarm*:*job.heartbeat* is waking the device every 1 hour and half (90 minutes) but in my case, it does not wake the device out of
Doze. see the image below if the doze is off there will be a gap. and there is a gap because I turned my screen on. my theory that the android system Schedule it to work to check for any change in the bucket and behave accordingly to it
I have an open source gps tracking application that has been around for many years. Recently, I have been getting complaints that in android nougat, instead of getting updates once a minute, people are getting updates from the phone once every five minutes when the phone is unplugged.
There is something going on with the power saver mode even though we tried turning it off.
Is there a way to force a phone to get gps updates at a specified time when unplugged?
Here is the code if anyone wants to see it but I don't think it's a problem with the code. It has been very stable for years.
https://github.com/nickfox/GpsTracker/blob/master/phoneClients/android/app/src/main/java/com/websmithing/gpstracker/LocationService.java
thanks.
One change in Android 7/Nougat was that the Doze is now "more aggressive". In Android 6/Marshmallow the doze mode kicked in when the screen was off, the device was running on battery and it was stationary.
(This is documented in Optimizing for Doze and App Standby)
Now in Android 7 the conditions are just screen off and running on battery.
(This is documented in Android 7.0 Behavior Changes)
Apps can be white-listed to be exempt of the restrictions if they break the core functionalility of it. In your case they do as the GPS tracker needs to record coordinates in real time.
There's a list of Acceptable Use Cases for Whitelisting
This includes:
Task automation app | App's core function is scheduling automated
actions, such as for instant messaging, voice calling, new photo
management, or location actions.
Users can white list an app manually on their own in the device settings or whitelisting can be requested by the app and approved or rejected by the user.
This is covered in Support for Other Use Cases
Quoting:
An app can fire the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent
to take the user directly to the Battery Optimization, where they can
add the app.
An app holding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission can
trigger a system dialog to let the user add the app to the whitelist
directly, without going to settings. The app fires a
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intent to trigger the
dialog.
The user can manually remove apps from the whitelist as needed.
The last point is important of course, but luckily the whitelisting status can be checked programmatically:
An app can check whether it is currently on the exemption whitelist by
calling isIgnoringBatteryOptimizations().
So, dealing with the Doze mode is one thing to study at least.
Another issue is keeping the Service running in general. But the Service getting killed by the system might result in more random time intervals. There are of course the classic things like using START_STICKY or running as a foreground service.
I have a foreground notification service that continuously monitors user's actions, using ActivityRecognition, and writes them to AWS anytime user's state changes. It works good for some time. However I noticed when user is idle for longer time, such as user is sleeping overnight, then the app (activity and service) silently dies. I assume this is because of doze mode (because I whitelisted the same app on a different phone and it is working fine for over 2 days now)
How to WhiteList app in Doze mode Android 6.0 gives good overview on how to disable doze mode with user intervention. But #commonsware blog below suggests about Google 'possibly' banning the apps that show the corresponding popup box
https://commonsware.com/blog/2015/11/11/google-anti-trust-issues.html
Note: Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected.
Can someone help me in understanding what features can possibly comprise "core functions", so Google would not ban my app. We know doze mode doesn't affect some apps like WhatsApp
EDIT
I see this on Samsung phones with 6.0.1
Android does not kill services in the background with Doze. Per the ActivityRecognitionApi documentation:
To conserve battery, activity reporting may stop when the device is 'STILL' for an extended period of time. It will resume once the device moves again. This only happens on devices that support the Sensor.TYPE_SIGNIFICANT_MOTION hardware.
Therefore it is entirely expected to have a significant period of time where you won't get any activity recognition callbacks. In those cases, you can assume that the last received activity (STILL) is still applicable.
Are there callbacks on doze mode (on Doze first/second level, on start/end of maintenance window)?
Is there a way to workaround Doze mode that is not dependent on the user approval?
In previous versions (Android M and smaller) I used Android Service and partial wake lock to download and process data while the application was in background. Is there a way to download and process data in the background when Android N gets into Doze Mode?
Are there callbacks on doze mode (on Doze first/second level, on start/end of maintenance window)?
If you have a running process, you can register a receiver for the ACTION_DEVICE_IDLE_MODE_CHANGED and ACTION_POWER_SAVE_MODE_CHANGED broadcasts. The former should correspond to Doze mode.
Is there a way to workaround Doze mode that is not dependent on the user approval?
I do not know what "workaround Doze mode" means. You can use the ...AndAllowWhileIdle() methods on AlarmManager, though I had mixed results. You can use GCM (or FCM nowadays). See the documentation.
In previous versions (Android M and smaller) I used Android Service and partial wake lock to download and process data while the application was in background.
Your partial wake lock should be revoked in Doze mode on Android 6.0 (a.k.a., M). Similarly, you should not have Internet access in Doze mode on Android 6.0.
Is there a way to download and process data in the background when Android N gets into Doze Mode?
For the full Doze mode, Android N does not appear to change things. For the partial Doze mode that Android N introduces, your partial wake lock should work, though I am uncertain about the network access.
In previous versions (Android M and smaller) I used Android Service and partial wake lock to download and process data while the
application was in background. Is there a way to download and process
data in the background when Android N gets into Doze Mode?
When device enters Doze mode most functions stop due in fact de CPU stops, then the way should be to avoid enter Doze mode :
The thing that works for me is to use a foreground service, that's a Service that calls startForeground() (1) and shows a non dismissable notification, then the partial wake lock is respected and the device doesn't enter Doze Mode.
(1) beginning at Android 8 the method to start a foreground service has changed Android O - Old start foreground service still working?
I have an android app which records voice using a service - and a thread inside the service(obviously the app can record while in background..)
The app will be affected by the new Doze app state?
https://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases
I don't have a phone with 6.0 yet and the simulator cannot record voice in general...
If your service is running in the foreground (with an associated notification) when the device enters Doze mode, it should not be affected according to a comment by Dianne Hackborn to this post. See a documented experience that seems to prove this behavior here.
On the other hand, tests show, that access to certain sensors like GPS are restricted in Doze mode, so this might also apply to the microphone.
Since Doze mode is poorly documented up to now, unfortunately at this point you probably do not get around running your own tests on a physical device.
Yes, every app can be "killed" by Doze. If your service runs in foreground you can avoid App Standby however. Remember that asking to the user to put the app in the whitelist it's prohibited from Google Terms of services, so you can't do it. If you want to do something like that you need to add a permission to your manifest and with cross fingers hope in the Google review of your app.