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.
Related
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.
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'm using location & activity recognition features of android. Used for realtime location tracking. Currently using the latest ConnectionLess APIs. I have encountered the following problem:
After starting the location, activity services, once in a while, the battery starts to get drained. The behavior is pretty strange as the entire drain is showed under Google Play Services. The drain persists even if the app is stopped, killed, etc. To my surprise, the drain persisted even when the app was uninstalled and it took a couple of full battery re-charges to come out of the situation.
I'm more or less sure that the drain is triggered by my app as multiple devices have recorded the issue and these devices are from different manufacturers and across multiple android OS versions. In ADB shell, I find com.google.android.gms taking up 126% CPU permanently as seen below:
Next, I listed all the threads under that process. Result attached below:
As seen there's one thread, CastSocketMulti running. All other threads are sleeping.Didn't get much on castSocketMulti other than some basic information like it is related to casting in android, etc. We aren't using anything related to casting in our app.
After, killing the process, the drain stops.
Note: I found same question here, however unanswered.
Edit: Every time the battery drain happens, as above, com.google.android.gmsis listed as the number one process taking 100%+ CPU and the castSocketMulti, the only thread of that process in R status
Update: I have opened an issue here.
Pls leave a star so that it may go high on priority
I have found the exact same thing here on a OnePlus 3. I'm not rooted and can't kill the process, but using adb to clear the cache of com.google.android.gms makes the process crash and alleviates the problem for a few days.
Do you use Android Auto or Android Pay? It seems to happen more frequently when I use those two apps in particular.
OK, Google claims to have fixed the issue and they have marked the issue as 'Fixed'. Details here
I have a somewhat unusual Android app in the Play Store that's running on dedicated devices 24/7 (it collects sensor data, it's not meant to run on phones used for anything else). I would like the app to auto-update without user interaction, but that never seems to happen. Why could this be?
Some more background:
Auto-update is explicitly turned on for the app on the devices.
Other apps do seem to auto-update.
The app stops and restarts itself every 12 hours; mostly to whack the app out of any weird state it might get into and clear memory, but I was also hoping this would give it a chance to auto-update. There is a 10 second delay until the app restarts.
The devices are mostly old phones (HTC Desire C) running Android 4.0.4
This is fairly hard and time-consuming to test so any experiences shared with similar requirements could be helpful.
Make sure the port 5228, TCP and UDP, is not blocked by a firewall per https://support.google.com/googleplay/answer/2651367?hl=en
We've had a similar problem for years. Our apps run on school deployed devices. Whenever we push an update, it reaches may be 10% of devices within 24 hours, the rest seem to "hang". It takes about a week for another 30% of devices to get the update, while the remaining %60 never get it. There is no difference in settings across devices. All set to auto-update of course.
The way we "solved it" is our app is checking if the market has a newer version (there are libraries for doing it, but we have own server responding yes/no). If there is a newer version of the app, we invoke the intent to open Google Play with the app's page. The user has to manually click "Update" at that point.
If there was a native or cleaner way to push the updates we'd love to hear, even at this point in the game. Bothering users to update is not ideal.
This is a long shot: Maybe there was any change in the apps required permissions?
That would require manual updating (even if auto-update is on). Maybe you installed the app first in those old devices, then changed the permissions, then installed the app in new devices, then updated the app. That would make the autoupdate system work in the newer devices, and not work in the older ones.
why cant android os be more like apple os on the the ituch/iphone? where the app doesn't run until it is selected. it is also closed; stays closed until it is opened again.
i think this would make the android phones run faster and more efficiently(battery would last longer).
A lot of Android apps (I think most of them) run exactly as you describe it - they have an activity that is closed or suspended as soon as you leave it - a suspended Activity only consumes memory and can be discarded in an instant. (iOS does nearly the same)
Even on the iPhone there are applications that run in the background, the most prominent example being Mobile Safari. The difference is that only Apple can write applications that run in the background without restriction, and that a regular user has no way of monitoring these background apps. (this has led to massive overcharging issues in the case of users leaving Mobile Safari on a page where streaming content was loaded.)
There are legitimate use cases where you need an app to continue running in the background (downloading, uploading, playing music, waiting for a VoIP call) - none of it was possible for a third-party to do it on the iPhone until iOS4, making applications such as Pandora or Skype nearly useless.
For good or ill, Apple consistently restricts what third-party developers are allowed to do on iOS devices (App Store policy, private APIs, specialized APIs for background tasks mentioned in point 3). On the other hand, Google seems to prefer that third-party Android developers have access to the same APIs as Google's Android app developers.
The biggest Android performance problem IMO is responsiveness, the fixing of which is a lot more involved than saying "no Apps in Background thx". (See http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html for more information)
An Android developer's blog explains the reasoning behind Android multitasking.
We did not want to require that users close applications when "done" with them.
Mobile devices … have fairly hard limits on memory use.
These competing constraints were a key motivation for Android's design.
The fact that you can see an application's process "running" does not mean the application is running or doing anything.
The articles linked from there also have interesting things to say on the subject
The RadioActive Yak:
When should your app include an exit button? The Short Answer: Never.
Wickenden:
One of the first things the naive but technically inquisitive new android user does is begin to wonder how all the things they are running should be “shut down”.
Google’s android system has been designed for multi-tasking in ways that allow programs to be ready to respond to a changed environmental condition instantly (an alarm to wake you, a notification that you have arrived at your destination and so forth) as well as actually “running” and consuming resources when needed. Additionally the android system itself is smart about how it deals with low memory conditions and is capable of completely blowing away applications in such a way that their state is remembered and can be restored when there is more memory.
Task Killers (whose behavior is radically clipped in Android 2.2 “Froyo”) actually can cause harm by destroying a process that other apps need to function correctly.