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?
Related
I am building an Android app that needs to be in constant Bluetooth (Classic) communication with a peripheral device. As long as the app is running in the foreground, everything is fine. But when the app is put in the background, the system kills the app after a indeterminate amount of time. The app can hang in there anywhere from 2 - 15 minutes. This happens even when the app doesn't have any battery optimisation. I hoped by turning the Battery Optimization OFF, it would prevent Android from putting the app into Standby Mode/Killing it.
If the app cannot run forever when the device is running on Battery, how long can one expect the App to exist in the background?
I wish the duration of the app's existance in the background was determinable! I appreciate any help on the matter.
Tested on Motorola G5S Plus running Android 8.1.0
The manifest file has background_running turned ON:
<meta-data android:name="android.app.background_running" android:value="true"/>
App's Target SDK is API 29: Android 10
You need to implement background service with WakeLock/Foreground Service, In service you need to write all bluetooth code that you want to run in background, Code that you wrote in activity/fragment place in service, for bluetooth callbacks need to implement Broadcast Receiver.
I am trying to put my emulators into sleep mode to test some behavior.
For this, I deactivate the charger, set the battery to "uncharging" and a low battery %. Then I lock the screen over the power button (swipe to unlock is activated).
Then I start some background operation (for example an IntentService) without holding a wake lock and leave the app, but everything just keeps running as if the screen was on.
The emulator seems to not fall into sleep.
Not a duplicate since I am already following these exact steps (as described above)
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.
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.