Devices such as Huawei, Xiaomi, some Samsung models, or most of the devices I know that has MIUI, EMUI in their system has by default turned on battery saver features and automatic "optimizations". Recently I've created an important worker but my device (Huawei P20 Lite) has this built-in feature which prevents the job from running (it even shows that the system blocked the execution), unless I go to that panel and let the app execute on background by myself.
On a production environment we can't tell the users to go to this menu and let us run on background (simply because we don't know how many variations of these battery saver features), the app itself doesn't run on background on most cases. However, this worker still should execute because the task is pretty important.
Two questions:
1) For a rough estimate, how much percentage of devices will prevent a work manager task to be executed?
2) Can any workarounds be applied for this situation?
Any help is appreciated, thanks.
Please, a file bug on Google issuetracker under this component:
Android Public Tracker -> Device-Specific App Issues.
This seem a CDD violations and the bug will help Google explaining to the OEMs what needs to be fixed.
I've seen that there's a library that tries to handle (Autostarter), across different devices, opening the right setting. This is just a workaround.
The best course of action is to report the issue, but this will probably request some time to be fixed and the user will need to update the OS.
Related
Recently I have discovered that about 2 months ago there was released Android 11 update for Samsung devices.
Samsung has in this version of OS decided to really strictly suspend the apps/services running in the background (more info)
So e.g. when app I am working on goes to background and phone is locked, all BT communication is almost immediately suspended. When I unlock the screen, in that exact moment all threads are not suspended anymore and execution continues.
OS therefore completely ignores the foreground service mechanism.
Official documentation
Also when I try to add my app to the list of "Never sleeping apps" (some alternative to battery optimization whitelist on Android 11) - app is still getting suspended + this whitelisting mechanism appears to be unstable and even when I add my app to the whitelist, app disappears from the list after few hours.
My questions:
Have you seen similar issues on Android 11 too ? What helped to resolve the issue?
Is this only Samsung specific issue or even Pixel devices do the same optimization (ignoring foreground service and whitelist)?
Thanks for any input.
sadly this is a huge and common problem and my repsonse will probably not fix it for you, but give you some more insights and possible work-arounds. Have a look at dontkillmyapp.com.
Especially dontkillmyapp.com/samsung:
On Android 11 Samsung will prevent apps work in background by default unless you exclude apps from battery optimizations. This is a severe divergence from standard Android process management policies.
Yes, this is a long way to go! Devs cannot ask for it automatically as they risk being kicked out from Play Store due to policy violations.
Also I can highly recommend very insightful the fun talk fron Droidcon Berlin 2021.
I'm a newbie android developer.. I have trouble keeping the background services broadcast receivers etc alive on no stock android devices.. i have tried many solutions and couldn't find one that works... Please help.
Unfortunately, many of Android devices will have issues with staying alive in the background due to aggressive battery-saving policies of their manufacturers. This leaves you with two options: either instruct your users how to "white-list" your app to not get killed because of battery consumptions.
See here: Don't kill my app.
Or, have it done automatically by special permission.
See here: Optimize for Doze and App Standby
You should know that there are some issues with the second option, as it does not solve the case with all of the manufacturers and also, your app might be banned from Play Store if you request it and unless the core function of the app is adversely affected.
I want to run a task in my app everyday, I am using JobScheduler for it and works fine in stock OS, but when I try to run it in phones which has custom ROM (Xiaomi) it doesn't work unless I explicitly enable auto-start option for the app in security. Is there any solution for this, how are other apps handling this scenario ?
This is a known issue with some Android OEM that heavily modify this part of Android for battery optimization.
Aside having you application added to the whitelist, you can really only report the issue:
to the OEM (Xiaomi in this case) to avoid this kind of breaking changes.
to Google, to add a test in the CTS and avoid these behaviours by the OEMs.
Using WorkManager is not going to solve this problem because WM still uses JobScheduler API when it's available.
From WorkManager's issue tracker: are the Chinese manufacturers (Huawei, Oppo, Xiaomi...) supported?
Use WorkManager from now on. It will handle every thing automatically depending on the Android version
I read many questions here about doze mode like Android doze mode, Android N Doze mode - how to keep background download and processing?, Wakelock and doze mode and many others. But in many replies, opinions is different. I can't test it by myself (emulator does not support my processor, and my only test device is android 5.1). I would like to know the next situation. I have an activity, which controls the media player. On devices with android 6.0 and higher it wouldn't work as expected cause of doze mode. As many solutions says to prevent doze mode it should start a service in separate process in foreground and control media player from there. The question is: if i start foreground service with partial wake lock in separate process, which would do nothing except showing notification, and leave controls to media player in my activity, should it prevent the doze mode? Or maybe there any other ways except keep the screen on from window manager?
According to this SO question and answer:
In this post's comments on Sep 17 Dianne Hackborn writes:
Apps that have been running foreground services (with the associated notification) are not restricted by doze.
- Source (sec_aw)
It looks like using a foreground service prevents the app from being killed by Doze.
Please note though, that some vendors (I know of Samsung, but there are probably others) create their own RAM conservation/battery saving tools. These may exhibit patterns completely different from Doze, and there's usually a bunch of other hoops to jump through. You are not guaranteed to get the same behavior on these devices either - they may be more or less aggressive, and the more aggressive ones tend to be worse for keeping services or whatever alive.
There's also no universal way to deal with these, but someone has made an entire website dedicated to showing what vendors are problematic, as well as potential workarounds. Note that the majority of the problematic vendors only yield end-user solutions, which means you (the developer) have no way to fix it without the user doing something.
While this is unfortunate, that's pretty much what happens when companies implement their own versions of Android. Also, from my own experience (primarily as a user rather than a dev) on a Samsung phone, the settings aren't always respected and still causes annoying behavior.
Anyway, as long as Doze is present, foreground services should be fine. On other vendors, however, all bets are off and you're at the mercy of the vendor's implementation of some type of optimization system. On certain exposed operating systems (again, see the website linked earlier), you also have no choice but to ask the user to fix certain settings to keep stuff alive.
I release a new version of my app , already tested by some htc phones.
but recent days, users report that in some moto phone (espically moto defy) ,don't like normal app freeze which system will show alert dialog,my app cause phone freeze(the system is not reponsing,people have to plug out the battery then restart). but most of users I asked told the new version is quick smooth~~ bad performance could make system freezing?
Do you know any possible reason may cause my problem?
or any related system log I can checked?
Are you using threads? If not, then you are blocking the UI thread. You can use Traceview to find performance problems.