Hi there
sorry for asking I am somewhat new to Android.
I read very often that Google Maps should be froozen because it is a battery sucker. Now I am wondering how an application could drain the battery when I actually do not run the application.
How does Android itself deal with applications and quitting them?
I read conflicting recommendations about task managers stating that Android itself deals with this better.
So what is this freezing of apps? Does it prevent Android from starting it automatically?
Thanks for any education
Claas
Android is based on multi tasking ..ie many apps can run in the background even though you are not using it at the moment..say if you are using maps and once you're done you just exit it. However maps app will be running in background if not exited in proper manner( either using the app or by going to running services in settings and force closing).
Also certain apps are configured to autorun under certain circumstances ..say for maps or Facebook app! -try keeping your wifi /data off! Go to settings/apps/running services/menu-cached process and force close Facebook,maps however once you turn on data /wifi they will run automatically! Just check it out yourself ..
Solutions for such problems could be either to use autorun managers or to freeze the app -freezing makes the app unavailable for use until you de-freeze!ie it blocks the app from running ..
Above said statements /examples are from my experiences!correct me if I'm wrong!
Sent from my LG-P500 using Tapatalk
Yes but be careful, if you use task killers to kill them, they may start again and this will consume more battery than the program running.
Imho the best way to go about this is the following:
- go get Quick System Info PRO from Market (it's free)
- set it up so that it places a CPU usage icon on your status bar (the notification for that icon is also animated)
- when you find the device is sluggish and CPU usage is high, tap the notification and go to the Processes tab
- sort by CPU usage
- kill whatever it is that is using the CPU
And you may also kill all tasks just once before going to bed or something, just in case.
To stop maps, use autostarts disable all maps have in there, then you can be cool
Sent from my LG-P500 using xda premium
Hello everyone,
This is a question I've tried to search for an answer since quite some time but never found any so far.
It is happening on a stock HSPA+ Galaxy Nexus with JRO03C 4.1.1 Jelly Bean (bought from US play store).
Please note this behaviour was happening with Ice Cream Sandwich as well.
This happens with more than one app, but this time I'll focus on play.google.com/store/apps/details?id=com.merriamwebster
because it's free and I was able to reproduce this behaviour quickly.
Steps to reproduce:
-Open up Merriam Webster's app
-Write any word in the search box, than tap it in the drop down list that appears (you're brought to the word's dictionary page)
-Wait a few seconds then hit Android's home button on the bottom bar
Now check in Settings -> Apps -> Running:
You will see that the app is not on the running list but is in the cached processes list.
Now go to Developer Tools and enable "Show CPU usage" and hit home to show up the desktop.
You will see that com.merriam.webster is constantly using a small but not negligible percentage of cpu (its green bar is big enough to "highlight" the 'er' in .webster )
The only way to stop this is to stop the cached process in Settings -> Apps -> Running -> Show cached processes
I think the question now comes up by itself: "Aren't cached processes supposed not to use any CPU at all?"
Any info on the matter is appreciated.
Thanks
I think they do but its really minimal and probably doesn't affect performance much at all..
VoiD_Dweller said:
I think they do but its really minimal and probably doesn't affect performance much at all..
Click to expand...
Click to collapse
Such a constant CPU usage, even if small, will prevent CPU from going to its sleep state. No sleep state = battery drain.
More on the matter...
I've been able to investigate the issue a little further:
Installing the ad-free version of the same app ( play.google.com/store/apps/details?id=com.merriamwebster.premium ) and trying to reproduce the same steps does NOT show the problem. The app is now sitting in the background without chewing CPU time.
The only difference among the 2 apps should be the fact that the paid one lacks the piece of code to retrieve and show the ads (is that made with google ads?).
This would at least point us to a culprit (the ad code).
Still I don't understand why a process which is show as cached by the system is able to use CPU cycles. This should not be possible according to Android OS Documentation.
julioromano said:
Still I don't understand why a process which is show as cached by the system is able to use CPU cycles. This should not be possible according to Android OS Documentation.
Click to expand...
Click to collapse
The app isn't cached, but running, the time it consumes CPU cycles. It's just that it's only running a fraction of a second at a time, so you don't see it. In between, the app stops itself, rendering a "cached process" until the next time it wakes up, due to an intent restarting the app for a short while again.
kuisma said:
The app isn't cached, but running, the time it consumes CPU cycles. It's just that it's only running a fraction of a second at a time, so you don't see it. In between, the app stops itself, rendering a "cached process" until the next time it wakes up, due to an intent restarting the app for a short while again.
Click to expand...
Click to collapse
This might be a possible explanation, however installing the ad-free version of the app eliminates this odd behaviour.
Does this mean that some ad library code is buggy and can actually cause CPU hogging?
It makes no sense to wake up a process via intent every fraction of a second when it's UI (and hence the ads) is not displayed at all.
julioromano said:
This might be a possible explanation, however installing the ad-free version of the app eliminates this odd behaviour.
Does this mean that some ad library code is buggy and can actually cause CPU hogging?
It makes no sense to wake up a process via intent every fraction of a second when it's UI (and hence the ads) is not displayed at all.
Click to expand...
Click to collapse
Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?
Why the ad code behaves this way, you'll have to ask them about. There can me many different reasons. Checking availability of new ads, internal administration, collecting usage statistics ... just to mention a few.
kuisma said:
Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?
Here: developer.android.com/guide/components/processes-and-threads.html
Code:
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
This means to me that a cached process is an "Empty process".
Not having active components means no CPU usage.
I understand that from a UNIX point of view its process and pid will still be visible when typing "ps aux" in a console, but this process should not maintain a stable CPU usage around 5% (such as the one I wrote about in the first post of this thread) no matter what.
Click to expand...
Click to collapse
julioromano said:
kuisma said:
Not every fraction of a second, just once in a while, enough for the process to stay alive. Also, at a closer look, I see no reason why a cached process shouldn't be able to consume CPU cycles. Just because the Android app terminated, I see nothing that hinders the JVM (DVM) to keep threads going. Not for very long, though, since the ActivityManager loves to slay cached processes. Where in the Android OS Documentation did you find the claims this isn't possible?
Click to expand...
Click to collapse
Here: developer.android.com/guide/components/processes-and-threads.html
Empty process
A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.
Click to expand...
Click to collapse
This means to me that a cached process is an "Empty process".
Not having active components means no CPU usage.
I understand that from a UNIX point of view its process and pid will still be visible when typing "ps aux" in a console, but this process should not maintain a stable CPU usage around 5% (such as the one I wrote about in the first post of this thread) no matter what.
Click to expand...
Click to collapse
I agree that "empty process" here means "cached process", but I see no claim that this process must not contain a worker thread, and not consume CPU. "Empty" is in the context of Android app level, i.e. contains no activity or service (no context), not OS level.
But you can always test this quite easy. Create an app with an activity only starting a worker thread, then terminating. See if the worker thread still consumes CPU during its existence as a cached process. I believe it will. Of course, this is an artificial construct, not very useful since it doesn't have any context and can not interact with Android. Still, performing gc, updating singeltons etc, are still very possible tasks for such a worker thread.
Edit: But the ad software maintaining a 5% CPU usage as a background/cached process, I'm quite sure is due to low programming skills. But possible, yes indeed.
kuisma said:
But you can always test this quite easy. Create an app with an activity only starting a worker thread, then terminating. See if the worker thread still consumes CPU during its existence as a cached process. I believe it will. Of course, this is an artificial construct, not very useful since it doesn't have any context and can not interact with Android. Still, performing gc, updating singeltons etc, are still very possible tasks for such a worker thread.
Click to expand...
Click to collapse
I agree with your line of reasoning, sometime in the coming weeks I'll try to develop a test app and then I'll post my findings here.
What keeps me mumbling on this topic is the general approach to process management on Android:
Android has been thought from the ground up with mobile devices in mind: such devices must put their CPU in the highest possible of its sleep states for as much time as possible not only when the screen is off, but also during regular usage e.g. browsing a web page.
When you read an article on your browser app, you'll want only your display chewing up battery juice and your CPU as close to 0% as possible (unless you're scrolling or zooming, but let's say you're just reading a piece without touching the screen).
With this approach in mind it should be clear that the only processes that should be able to be put into execution by the OS's scheduler are those belonging to categories 1 to 4 ( developer.android.com/guide/components/processes-and-threads.html ).
From an OS perspective, cached processes (category 5) are useful to avoid wasting otherwise empty RAM so that recently used apps can be relaunched as quickly as possible.
But if cached processes are able to use CPU cycles then this is by no means useful to the OS (nor the device), because you'll have no longer needed processes causing your CPU to exit its much beloved sleep state.
In other words:
-Having processes sit in RAM without wasting CPU is ok because it speeds up the system when you reopen those apps and still, those processes will be purged when more RAM is needed (i.e. caching).
-Having processes sit in RAM wasting CPU is not ok because the benefits you gain from caching are offset by the increased battery drain.
julioromano said:
I agree with your line of reasoning, sometime in the coming weeks I'll try to develop a test app and then I'll post my findings here.
What keeps me mumbling on this topic is the general approach to process management on Android:
Android has been thought from the ground up with mobile devices in mind: such devices must put their CPU in the highest possible of its sleep states for as much time as possible not only when the screen is off, but also during regular usage e.g. browsing a web page.
When you read an article on your browser app, you'll want only your display chewing up battery juice and your CPU as close to 0% as possible (unless you're scrolling or zooming, but let's say you're just reading a piece without touching the screen).
With this approach in mind it should be clear that the only processes that should be able to be put into execution by the OS's scheduler are those belonging to categories 1 to 4 ( developer.android.com/guide/components/processes-and-threads.html ).
From an OS perspective, cached processes (category 5) are useful to avoid wasting otherwise empty RAM so that recently used apps can be relaunched as quickly as possible.
But if cached processes are able to use CPU cycles then this is by no means useful to the OS (nor the device), because you'll have no longer needed processes causing your CPU to exit its much beloved sleep state.
In other words:
-Having processes sit in RAM without wasting CPU is ok because it speeds up the system when you reopen those apps and still, those processes will be purged when more RAM is needed (i.e. caching).
-Having processes sit in RAM wasting CPU is not ok because the benefits you gain from caching are offset by the increased battery drain.
Click to expand...
Click to collapse
I agree with you. Mostly.
I don't really care if an app consumes CPU in the incarnation of a hidden (background) app, or as an cached app waking up by e.g. AlarmMamanger once in a while, or even as a cached app using a worker thread. If I need the app, and the app need the CPU time, so be it. But more often, those are badly written apps, and then I don't care about the details of their inner workings, I just uninstall them ...
Also, even processes sitting in RAM without consuming CPU can be a menace. Take my Xperia for example. In the last version of GB it started so much bloatware, that the limit of 15 hidden tasks was exceeded. But the tasks was sticky, i.e. required to restart in the case of termination. The result was that the phone constantly killed and restarted all the hidden tasks, draining the battery doing ... nothing! Only restarting all the bloatware, time after time after time..!
kuisma said:
I agree with you. Mostly.
I don't really care if an app consumes CPU in the incarnation of a hidden (background) app, or as an cached app waking up by e.g. AlarmMamanger once in a while, or even as a cached app using a worker thread. If I need the app, and the app need the CPU time, so be it. But more often, those are badly written apps, and then I don't care about the details of their inner workings, I just uninstall them ...
Also, even processes sitting in RAM without consuming CPU can be a menace. Take my Xperia for example. In the last version of GB it started so much bloatware, that the limit of 15 hidden tasks was exceeded. But the tasks was sticky, i.e. required to restart in the case of termination. The result was that the phone constantly killed and restarted all the hidden tasks, draining the battery doing ... nothing! Only restarting all the bloatware, time after time after time..!
Click to expand...
Click to collapse
Sure! Apps that do stuff useful to us should always be allowed to run
If an app registers for a intent or alarm and then goes to cached processes and we kill it (by removing it form the cached processes list via the settings app), it will be relaunched by the OS whenever an intent or alarm goes off.
Back to the case of our Ad-supported version of the Merriam Webster dictionary app:
When the app is cached (but still using around 5% of cpu) killing its cached process stops the strange behaviour: the app never gets relaunched by the OS (unless I tap again on its icon of course...)!
This means that it's not using CPU because it's been woken up via alarm or intents...
I still don't get it :laugh:
julioromano said:
Sure! Apps that do stuff useful to us should always be allowed to run
If an app registers for a intent or alarm and then goes to cached processes and we kill it (by removing it form the cached processes list via the settings app), it will be relaunched by the OS whenever an intent or alarm goes off.
Back to the case of our Ad-supported version of the Merriam Webster dictionary app:
When the app is cached (but still using around 5% of cpu) killing its cached process stops the strange behaviour: the app never gets relaunched by the OS (unless I tap again on its icon of course...)!
This means that it's not using CPU because it's been woken up via alarm or intents...
I still don't get it :laugh:
Click to expand...
Click to collapse
Ah, but this is another mechanism. When a service in Android initialise, it tells Android whatever it's sticky or not. Android may always terminate any app/service to preserve resources, but the sticky ones, must always be restarted once the starvation ends. This is why some app's can't be killed. They (the processes) get restarted even before an alarm or other intent wakes them (in the sticky case).
I can't keep running any background related apps such as Sports Tracking apps or Fitnes app. After a while all background automatically stops.
For example Mi Fit app which connects to my amazfit bip closes after 5-10 mins. Also I have tried these apps which runs in the background:
Endomondo Sports Tracker
Twilight
Flynx
Which need to run in the background to work, but as they are automatically closes themselves, these apps aren't usable. I think Android Go aggresively optimizes the ram and not allowing any apps on the background.
I have tried to clear my ram by clearing all recent apps, and running only one background apps. That doesn't help either. I have checked that almost 350mb of Ram is still available. This is making Nokia 1 pretty useless as I can't run my daily driving apps on them.
Is there any solution to this, so that I can keep the background apps from automatically stopping.
taufiqahmed said:
I can't keep running any background related apps such as Sports Tracking apps or Fitnes app. After a while all background automatically stops.
For example Mi Fit app which connects to my amazfit bip closes after 5-10 mins. Also I have tried these apps which runs in the background:
Endomondo Sports Tracker
Twilight
Flynx
Which need to run in the background to work, but as they are automatically closes themselves, these apps aren't usable. I think Android Go aggresively optimizes the ram and not allowing any apps on the background.
I have tried to clear my ram by clearing all recent apps, and running only one background apps. That doesn't help either. I have checked that almost 350mb of Ram is still available. This is making Nokia 1 pretty useless as I can't run my daily driving apps on them.
Is there any solution to this, so that I can keep the background apps from automatically stopping.
Click to expand...
Click to collapse
Try root.
And if/when you've rooted your device. Download in Magisk Appsystemizer https://forum.xda-developers.com/apps/magisk/module-app-systemizer-t3477512
Hope this helps.
facing same problem.
i cant even record the calls.because whenever i lock the screen. the app get stopped.
Same for me. I've tried security soft and parental control soft from Kaspersky and Norton respectively but both apps were killed randomly when the phone is idle. I did allow them to run background and disable battery optimization but no luck.
Same here, keep screen by g sensor, hold screen on, nothing stay in idle... By lucky, the music stays.
Update your Nokia 1 device, the try...
Hi Guys,
I've searched all over the web but can't find anything that will give me what I need to solve a problem.
Root issue: My Pixel 3 XL lags like crazy from time to time (similar to Artem, David R., etc.). Incidentally, while running CPDT (http://bit.ly/39FDtSm) disk benchmark, I noticed that my disk speed drops every 1-2 seconds by 75%-85% from peak. On a second device with very few apps, this does not happen and I suspect this might be one cause of the lag.
Need: What I am trying to do is retrieve real time task manager type data so that I can see what app/process is hitting storage or high CPU every 2 seconds.
In the pre-Oreo days, any task manager app could show the process and the resource usage in near real time but this ability at the app level has now been removed.
Ask: Is there an ADB command, that gives that will give me task manager type information (app/process, resource, usage amount, timestamp) in real time?
tl;dr: Google has neutered the APIs that allowed Task Managers on Android and I am trying to find out if it's possible to get the same info through an ADB command.
i was wondering..... some apps like greenify or superfreezZ use accessibility usage to track the app behaviour and auto hibernate them, but since android 9 there is a new command to restrict the background activity of an app and it is RUN_ANY_IN_BACKGROUND
you can simply enable in app info>battery>background restriction set to RESTRICT.
is it a "better" way to hibernate an app and stop all trackers, alarms and services that DRAIN the phone battery? or maybe it's is less powerfull than "force stop" the app?
how does compare DOZE to RUN_ANY_IN_BACKGROUND ? i suppose 1st is a generall switch off for all apps, BUT only on screen off. when you use the phone the "bad" app could continue to do what he wants, wakelocks, call some strange domains to receive or updload datas.... BUT WHAT IF it is restricted by RUN_ANY_IN_BACKGROUND? the app is not force stopped but should be something like hibernated when it's not foreground....?
i found some info here
App Power Management | Android Open Source Project
source.android.com
realista87 said:
i was wondering..... some apps like greenify or superfreezZ use accessibility usage to track the app behaviour and auto hibernate them, but since android 9 there is a new command to restrict the background activity of an app and it is RUN_ANY_IN_BACKGROUND
you can simply enable in app info>battery>background restriction set to RESTRICT.
is it a "better" way to hibernate an app and stop all trackers, alarms and services that DRAIN the phone battery? or maybe it's is less powerfull than "force stop" the app?
how does compare DOZE to RUN_ANY_IN_BACKGROUND ? i suppose 1st is a generall switch off for all apps, BUT only on screen off. when you use the phone the "bad" app could continue to do what he wants, wakelocks, call some strange domains to receive or updload datas.... BUT WHAT IF it is restricted by RUN_ANY_IN_BACKGROUND? the app is not force stopped but should be something like hibernated when it's not foreground....?
i found some info here
App Power Management | Android Open Source Project
source.android.com
Click to expand...
Click to collapse
Force Stop = "Hibernate"
Force Stop = App is killed and removed from memory, and (for the most part) not be able to start itself up again. User can. I read you asked the exact same question elsewhere and some talked how apps can restart themselves. Yes, its true BUT its the exceptioopn, not the rule. The only app that ciones to mind at the moment in my past is Google Play. His statement is misleading in practical everyday use. Test it for yourself.
I havent used it, but, RUN_ANY_IN_BACKGROUND explicitly requires the "deny" or "allow" attribute. The app is still in memory and therefore would have some possibility of bringing itself back to life; much more so than a force-stop. Some apps are developed with running a service as a foreground app. Also, RUN_ANY_IN_BACKGROUND is a TESTING feature of android.
ie Force Stop > RUN_ANY_IN_BACKGROUND
I have a hot spot on my home screen (custom launcher allowing scripts) that turns my screen oof and then force-stops all apps that I do not want running in the background.
You want an app to stop consuming battery, then force-stop is the way to go.
"RUN_ANY_IN_BACKGROUND is a TESTING feature of android."
mhhh so u say that not every app will really stop his background behaviour for sure? i thought that the command is quite sure to keep a closed app a "not battery hungry" app, stopping some services, alarms.
basically if u would choose an app to force close apps, would u choose superfreezz (because it s foss) over other alternatives like greenify or brevent?
because i would avoid to install any app for this, IF the command RUN_ANY....... is to consider quite powerfull and acceptable to "stop draining " battery from malicious apps...
realista87 said:
"RUN_ANY_IN_BACKGROUND is a TESTING feature of android."
mhhh so u say that not every app will really stop his background behaviour for sure? i thought that the command is quite sure to keep a closed app a "not battery hungry" app, stopping some services, alarms.
Click to expand...
Click to collapse
If you want to stop it, the a force stop is the way. Its much more "powerful" than what you found.
realista87 said:
basically if u would choose an app to force close apps, would u choose superfreezz (because it s foss) over other alternatives like greenify or brevent?
because i would avoid to install any app for this, IF the command RUN_ANY....... is to consider quite powerfull and acceptable to "stop draining " battery from malicious apps...
Click to expand...
Click to collapse
I explained to you, I use a shell script to get the job done. No need for another app, that also may consume unnecessary battery and memory.