My question is fairly simple. I would like to know what it is the best practice for my app so that it can be "Doze-proof". This is getting even more relevant as Android N will be applying Doze in more case scenario.
While reading Doze Documentation there is a part mentioning network access :
In Doze mode, the system attempts to conserve battery by restricting
apps' access to network and CPU-intensive services. It also prevents
apps from accessing the network and defers their jobs, syncs, and
standard alarms.
I believe Buetooth falls under Network Access, is that correct?
Since I do not own a Marshmallow (or Android N) enabled-device and since Emulator does not allow Bluetooth interaction I cannot really test my app behavior in Doze Mode.
Will Doze Mode kill any ongoing Bluetooth connexion? Does the same apply either for Bluetooth Classic and LE ? What about headsets with Bluetooth A2DP ?
My app must maintain this connection or else the core functionality will be broken.
Surely there is some kind of exceptions for such case where your device needs to be connected to a Bluetooth remote device for as long the user whishes too.
I know there exists a Doze Whitelist but it would seem it might not, in some cases, let the app behave as it would on a device below API 23.
Thank you for your help!
Looks like doze doesn't have any restriction on bluetooth per se but to do anything meaningful, you would need to keep the cpu on and wake locks are ignored in deeper doze.
If it's a core functionality of your app, you can try to ask users to whitelist your app. This can grant partial wake locks and keep the cpu on.
Foreground services are also exempted from any doze restrictions so that's another transparent way.
Related
I 'm developping a continue scan android app, because I have to collect some important info from another device , I have to scan ble device,and never stop, otherwise, I may miss some important info. Is there any way for a android app to continue Bluetooth Low Energy scan,never stop ,scan for a year if the important device don't appear. During the year, my android phone always keep sufficient electricity，but sometimes I will press home button ， sometimes I will make Screen Off (not power off ,just make screen off).
Modern Android has implemented various battery saving measures which will prevent you from continuous data collection.
Doze mode is implemented by the Android framework. See: Scanning for Bluetooth LE devices when the phone is in doze mode, don't work. CallBack method doesn't called when doze mode
Additionally various device manufacturers have implemented their own battery savings systems which will kill your app even when you are following Android framework rules. See: https://dontkillmyapp.com/ for details.
Greatings!
We are developing an android app with Xamarin that has to meet the following restrictions:
wifi yes, but no internet connection
no FCM/google play services (app should also work in China)
push messages from a Manager-SW (uses rabbitmq) need to arrive quickly after being send (< 1min) AND also when the device is in doze mode
no pulling mechanism
At the moment we are having a wifilock and a wakelock. The battery optimization for this app is turned off. This way messages always arrive even when the device goes to doze mode.. with some exceptions.
There are devices like the HUAWEI P20 that have their own battery save solution (App launch) --> app is not running although we have all the stuff above
Also this solution is not ideal considering battery usage.
I have looked into alternatvies like Pushy, but for me it seems they have problems with doze mode too.
Do you know any alternatives to FCM?
Is there any easy way to go around the Huawei stuff without the user having to change the settings manually?
Many thanks to all of you in advance!
Documentation says:
If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode. In Doze mode, the system attempts to conserve battery by restricting apps' access to network and CPU-intensive services. It also prevents apps from accessing the network and defers their jobs, syncs, and standard alarms.
What exactly stationary mean? Does phone go into Doze if it is stationary in a car that is moving? I'm developing an app that send location update to a server and if phone go into Doze mode while moving in car that can't be done.
Stationary means literally stationary, no gyro activity, screen off, not connected to charger. As far as the car is moving, the phone will not enter Doze mode.
Android developers: Optimizing for Doze and App Standby
It should be noted that Android N has extended doze mode further. Here the device doesn't need to be 'absolutely stationary' for a 'lighter' version of doze - that allows wake locks but restricts network access - to kick in.
The principal is that to truly take advantage of this, android needs to conserve battery if the phone is in a user's pocket where it is 'unused' but may not be stationary.
The original Marshmallow 'deep-doze' is still very much present in N so once the phone is stationary for a good amount of time [screen off + not being charged are already met criteria] it will go into the original doze where wifi scans and gps scans [location updates], wake locks, job schedulers, sync adapters, and network access is restricted.
To answer your question for location updates, android has a fine motion detecting sensor which ensures that the device is stationary w.r.t earth before diving into the deeper version of doze. So for this particular use case you should be good to go but you should still use the newly introduced Job scheduler api for batched updates. I am sure fetching location is one aspect, you want to upload it to your servers as well. Network access is restricted in both versions of doze modes.
references
https://plus.google.com/+AndroidDevelopers/posts/gwA68kaVJQ8
https://www.youtube.com/watch?v=VC2Hlb22mZM
In case of Android M doze mode will not get kicked in if the device is in moving car.
But in Android N, a light doze mode has been introduced that does not require the device to be completely stationary or wait as long to activate.It starts shortly after both the screen is off and the device is not charging, waiting only a couple minutes before applying the restrictions just to make sure the user has stopped using their phone.
In case,phone is Android N it may go into light doze mode.
I'm working on legacy VOIP application on Android.
It doesn't use Google Cloud Messaging technology right now, but just keeping its own TCP connection forever.
Recently Google has introduced its Android M preview release with Doze mode
So the question: is there any workaround how the app can receive incoming calls/messages in Doze mode without redesigning the whole system to use GCM?
You may use ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS to ask the user permission to be ignored by battery optimization. However, double check Optimizing for Doze and App Standby, it seems to be allowed only for enterprise VoIP/IM (see questions #33114063 and #31154128)
No, GCM seems to be the only way. See a great analysis of the problems with doze mode including network and GCM here:
https://commonsware.com/blog/2015/06/03/random-musing-m-developer-preview-ugly-part-one.html
It's working well on most Android devices.
Other device's screen gets locked after 1 minutes BLE device gets disconnected,if device without charger.
Thanks for any suggestions!
this might come from the Keep Wi-Fi on during sleep option (which might affect all radios) - as it seems this only exists in 8.0 but not in 8.1 (at least on the Pixel 2 XL, according to this article).
You might be having this problem because your app is not properly configured to handle Doze mode.
While there do not seem to be any restrictions on using BLE itself, doze mode might be messing with the control mechanism for your bluetooth connection (ex: a background service).
To see if this is the issue, you can whitelist your app manually via Settings > Battery > Battery Optimization and disabling optimization for your app.
Furthermore, as of Android 8.0, there are restrictions on background services when your app is not in the foreground. So, you may need to create a foreground service to handle the connection.