Hi XDA
In my phone ulefone armour 6 is killing background app.
This app is my smart watch app n it notify me about notification.
But this phone is killing app in background .
I have added it in whitelist not to kill in background
But still it's killing it
Please suggest any app or setting to keep app running in background
Per chance...
In my Armour x5, I learnt that permissions technically has another name... notifications.
Google play protect will be preventing your app from running. In my x5, disabling play protect looks like it works, but it comes back on itself immediatly upon closing it's on off switch...
I learnt that by disabling notifications for play protect, that it stays turned off due to requiring notifications. Without notifications, it will NOT run, and I'm betting this is your answer
If not, become a developer and check background process limit, increase should you need to
Spoon feeding is good when your poor, a welcome thing
Related
Hi folks,
I have a peculiar problem. I'm using Tasker to kill some apps. One of the apps has a persistent notification icon and it refuses to be killed (even with root). The notification icon is gone for a second but will always come right back. Using pstree I tried to find out if there was a watchdog process keeping the app alive, but I found none. Also it is not hooked to any events according to Autorun manager. A force close under "app management" always works.
What is going on?
This seems like an answer that has been asked before. So off course I have searched. I found similar questions (examples: http://forum.xda-developers.com/showthread.php?t=1854858 http://forum.xda-developers.com/showthread.php?t=2040841 ) but no answers.
Who can help me? I'm really at a dead-end.
what app is it? Some apps (especially system apps) can't be closed, and if does gets killed, OS programs it to restart almost immediately after it's been killed.
Preaper said:
Hi folks,
I have a peculiar problem. I'm using Tasker to kill some apps. One of the apps has a persistent notification icon and it refuses to be killed (even with root). The notification icon is gone for a second but will always come right back. Using pstree I tried to find out if there was a watchdog process keeping the app alive, but I found none. Also it is not hooked to any events according to Autorun manager. A force close under "app management" always works.
What is going on?
This seems like an answer that has been asked before. So off course I have searched. I found similar questions (examples: http://forum.xda-developers.com/showthread.php?t=1854858 http://forum.xda-developers.com/showthread.php?t=2040841 ) but no answers.
Who can help me? I'm really at a dead-end.
Click to expand...
Click to collapse
This is actually Android-by-design. Apps are supposed to be killed from time to time to conserve resources (e.g. memory), and also restarted transparently to the user. This is handled by the ActivityManager. You can view it as Android swappes app's instead of swapping memory. This to improve the real time performance of the device. When someone calls you, you don't want to wait half a minute for the phone to swap out Angry Birds before it can load the Phone app ...
Hence, killing app's will most often only give very short term effect.
Hello @oasisfeng
Ive been using of greenify since the beggining ive rooted my device and now that MM is out which im also using since it was released on my nexus 5 device i still used greenify
Right now i have to uninstall it for one particular reason. It doesnt sync in notifications anymore.
I do know that "doze" limits notifications but opens background sync up in a short time for every minute or hours of interval. I do know greenify forces apps to go to "app standby" mode or forces apps to defer background process without exiting them on 6.0+ this means that the general "wait time" for push notifications are also deffered.
I do know there is a "wake up service" for greenify that intends to wake up device services again when hibernated from time to time but to be honest i think it is inefficient.
So haveyou tried creating an alarm that cuts the hibernation off for a small second to quickly sync in background process and push notifications from apps such as xda labs or messenger? You can do it by creating an alarm with a code of setandallowwhileidle()
Hope you read this and ill be waiting for your feedback, in the meantime ill be uninstalling greenify also its donate package and wait for further improvements
Cheers!
Instant messaging apps should generally be excluded from Greenify unless it supports GCM "high priority" push on Android 6.0+. This is the recommended solution mentioned in the app description and FAQ.
Do you mean the Greenify did sync in notifications in the past but not now? Can you give me a specific version number of Greenify that worked for you?
If I understand correctly, you want to wake-up apps periodically. It has been discussed actively in the early time. That derived a large set of functionality requirements, such as interval settings, settings per app, black-out duration, conditional wake-up, and etc. Even the worse, the longer interval, the less timely notification while the shorter interval, the more battery consumption. It is hard to balance, compared to the real right solution - GCM push. In summary, this idea introduced too much complexity.
As always, if you want to achieve that purpose, I'd suggest using Tasker together with the "wake-up" plug-in function provided by Greenify. Why do you think it is inefficient?
BTW, the solution of setAndAllowWhileIdle() is not the answer you may expect. If you are a developer and have read the documents, you should know this API is strictly limited and it also defeats the purpose of Greenify.
oasisfeng said:
Instant messaging apps should generally be excluded from Greenify unless it supports GCM "high priority" push on Android 6.0+. This is the recommended solution mentioned in the app description and FAQ.
Do you mean the Greenify did sync in notifications in the past but not now? Can you give me a specific version number of Greenify that worked for you?
If I understand correctly, you want to wake-up apps periodically. It has been discussed actively in the early time. That derived a large set of functionality requirements, such as interval settings, settings per app, black-out duration, conditional wake-up, and etc. Even the worse, the longer interval, the less timely notification while the shorter interval, the more battery consumption. It is hard to balance, compared to the real right solution - GCM push. In summary, this idea introduced too much complexity.
As always, if you want to achieve that purpose, I'd suggest using Tasker together with the "wake-up" plug-in function provided by Greenify. Why do you think it is inefficient?
BTW, the solution of setAndAllowWhileIdle() is not the answer you may expect. If you are a developer and have read the documents, you should know this API is strictly limited and it also defeats the purpose of Greenify.
Click to expand...
Click to collapse
I havent tried testing whileidle() to be honest i just read it multiple times on google sources and the likes.
For your suggestion on tasker i would not recommend it. There has been an endless discussion on tasker if it was battery friendly or not and i know for a fact that it is not. The problem with tasker is its constant background monitoring which depends on your "trigger" and "event" so yep i wouldnt use tasker to automate things anytime soon.
And yes. Waking up apps periodically is the thing that i would like to propose though it might contradict M's doze mode. So overall just now im with you that its not a good solution for messaging apps.
I dont remember it was years ago way back when im using kitkat and a non-famous brand phone locally made here in our country, but as far as i remember messenger really still doesnt tickle a notification update.
So bottomline right now theres no solution for messaging apps other than leaving it as it is right? The problem is that those messaging apps have the highest background drain so i guess i had to adjust myself using messenger lol
phantom146 said:
I havent tried testing whileidle() to be honest i just read it multiple times on google sources and the likes.
For your suggestion on tasker i would not recommend it. There has been an endless discussion on tasker if it was battery friendly or not and i know for a fact that it is not. The problem with tasker is its constant background monitoring which depends on your "trigger" and "event" so yep i wouldnt use tasker to automate things anytime soon.
And yes. Waking up apps periodically is the thing that i would like to propose though it might contradict M's doze mode. So overall just now im with you that its not a good solution for messaging apps.
I dont remember it was years ago way back when im using kitkat and a non-famous brand phone locally made here in our country, but as far as i remember messenger really still doesnt tickle a notification update.
So bottomline right now theres no solution for messaging apps other than leaving it as it is right? The problem is that those messaging apps have the highest background drain so i guess i had to adjust myself using messenger lol
Click to expand...
Click to collapse
IM app without GCM push is such a pain, since it usually tries its best to improve the real-time notifications, at the cost of power consumption. In my experience, even a 5 minutes interval wake-up is far from enough for a IM app, but already increases the power consumption a bit.
oasisfeng said:
IM app without GCM push is such a pain, since it usually tries its best to improve the real-time notifications, at the cost of power consumption. In my experience, even a 5 minutes interval wake-up is far from enough for a IM app, but already increases the power consumption a bit.
Click to expand...
Click to collapse
Agreed and again facebook and messenger is to blame for the poorly written codes and the messy services they all have.
Right now my issue is solved and im glad for such a quick and concise response. Ill be waiting for the future beta releases and in the meantime if you need my help for an upcoming feature on M count me in, and ill also throw down "possible suggestions" for you and maybe give you some codes for it
Cheers bud
My phone was serviced "reprogrammed" and when it came back I keep getting ads. I tried resetting the phone but it still keeps getting adware silently installed. Is there any way to fix this?
You are not alone. Bought this phone for my mom since she likes a bigger screen to do social media stuff. The malware popped in after the last ota. The official wirelessupdate app included on the phone silently installs random apks that pushes full screen ads and impersonates clicks even if the the phone is not being used. This is common with generic android phones coming from CHINA
I haven't figured out a way to root the phone as most rooting methods will fail(because of the sucky spreadtrum SOC which makes it difficult to root the phone).SADLY, rooting is the only way to disable/uninstall the wirelessupdate app.
However, here's a workaround I found that works.
1) restrict your network to limit background data usage (Found in settings).
2) **uninstall the malware app: finding the app may be difficult as It normally disguises itself as a system app with names like radio, settings, wifi or some application name that doesn't even make sense. It uses a lot of data and is always active. You'll know its the fake app if it poses as a system app but you have the option to uninstall it(System apps cannot be uninstalled without root/Su access).
Buttt....
The wireless update will probably install another malware app after uninstalling the current one.
3)disable notification of the app so it doesnt send fake notifications to you that opens ad based webpages as it also fakes notification, posing as a fake notif from FB, whatsapp
4) force stop it and stop the services from settings so it doesn't load or push apps while you use your phone
Restarting the phone will make the app run again
5) Remove the app's permission. By default its granted access to location, settings, storage and sometimes camera or mic. The wireless app doesnt detect this and wont turn those permission back on
6) lastly, you can contact firefly support AND PRAY TO THE GOOD LORD they know know what they're doing. Because I did and they were completely clueless on the troubleshooting or on the issue itself and even blamed the problem on the user. Ridiculously stupid.
I haven't really tried ADB yet because i don't have the time and the phone lacks resources online to restore it in case I brick it. Frankly, this phone is not worth investing time fixing especially with the quality of support it has from Firefly and the price it asked for.
I am trying to understand why apps restart instead of resuming from where they hibernated. I thought the point of Greenify was to not kill the app but to hibernate it and resume it later from the same point.
A simple case of reproduction of this is: start playing a puzzle in andoku, hibernate it in greenify and move back to it. It goes back to the main screen and not show the screen of that specific puzzle that I was solving before gibernate.
Is greenify even working?
devsk said:
I am trying to understand why apps restart instead of resuming from where they hibernated. I thought the point of Greenify was to not kill the app but to hibernate it and resume it later from the same point.
A simple case of reproduction of this is: start playing a puzzle in andoku, hibernate it in greenify and move back to it. It goes back to the main screen and not show the screen of that specific puzzle that I was solving before gibernate.
Is greenify even working?
Click to expand...
Click to collapse
Did you try the shallow hibernation or normal hibernation?
devsk said:
I am trying to understand why apps restart instead of resuming from where they hibernated. I thought the point of Greenify was to not kill the app but to hibernate it and resume it later from the same point.
A simple case of reproduction of this is: start playing a puzzle in andoku, hibernate it in greenify and move back to it. It goes back to the main screen and not show the screen of that specific puzzle that I was solving before gibernate.
Is greenify even working?
Click to expand...
Click to collapse
Yes, Greenify is working on many (tens of) thousands of devices. Likely YOUR device, rom or kernel is aggressively clearing memory due to limited resources. What are you using?
tnsmani said:
Did you try the shallow hibernation or normal hibernation?
Click to expand...
Click to collapse
I tried both but app restarts instead of resuming.
Yes, Greenify is working on many (tens of) thousands of devices.
Click to expand...
Click to collapse
What's your definition of working? It runs and does something or works as in if an app is hibernated and started, it resumes. If its the latter, its clearly not working...
devsk said:
I tried both but app restarts instead of resuming.
What's your definition of working? It runs and does something or works as in if an app is hibernated and started, it resumes. If its the latter, its clearly not working...
Click to expand...
Click to collapse
Not going to engage on this level. Greenify stands on its own merrits.
If not happy with the results nor willing to share device/rom/config info that might help with 'problem' determination then it probably ain't the right tool.
Davey126 said:
Not going to engage on this level. Greenify stands on its own merrits.
If not happy with the results nor willing to share device/rom/config info that might help with 'problem' determination then it probably ain't the right tool.
Click to expand...
Click to collapse
Are you able to resume any app from EXACTLY the same spot as you hibernated it from, after you manually hibernate it?
Aggressive OS/ROM does not matter. We are talking about a single app, hibernate manually, try to resume right away. The example of andoku I gave is a small app which does not require a whole lot of memory. So, I should be able to resume it right after hibernating it.
devsk said:
Are you able to resume any app from EXACTLY the same spot as you hibernated it from, after you manually hibernate it?
Aggressive OS/ROM does not matter. We are talking about a single app, hibernate manually, try to resume right away. The example of andoku I gave is a small app which does not require a whole lot of memory. So, I should be able to resume it right after hibernating it.
Click to expand...
Click to collapse
Just for interest, I'd downloaded and installed Andoku. Greenified Andoku. Played a few minutes and stopped within the game. Closed Andoku. Ensured Andoku was hibernated. Opened Andoku and was able to resume my game exactly at the point where I'd closed Andoku.
Just for completeness although most likely unimportant in this matter: Andoku had no internet access granted in AFWall+.
Personal conclusion: Greenify (currently on v4.6.3) works exactly and perfectly as advertised!
Personal remark: I concur with @Davey126. Unless you provide sufficient information about device, ROM, kernel and "configuration" (e.g. Magisk, Xposed, XprivacyLua, tools that restrict permissions, services, broadcast receiver etc.) most likely nobody is able to support you.
devsk said:
Are you able to resume any app from EXACTLY the same spot as you hibernated it from, after you manually hibernate it?
Aggressive OS/ROM does not matter. We are talking about a single app, hibernate manually, try to resume right away. The example of andoku I gave is a small app which does not require a whole lot of memory. So, I should be able to resume it right after hibernating it.
Click to expand...
Click to collapse
Android hibernation is not the same as Windows hibernation. Resumability is not assured - especially on a resource constrained or highly 'tuned' ROM. You should probably read up on how it works and the primary objective of Greenify which is to suspend unwanted background activity. In that respect it shares many characteristics with doze.
Oswald Boelcke said:
Just for interest, I'd downloaded and installed Andoku. Greenified Andoku. Played a few minutes and stopped within the game. Closed Andoku. Ensured Andoku was hibernated. Opened Andoku and was able to resume my game exactly at the point where I'd closed Andoku.
Click to expand...
Click to collapse
Did you use the pause/resume feature of the Andoku game or did you just click the game to start it again, and it resumed where you left off? Typically, if you resume using the game's feature, you have to click through 3 times to resume your game. If the app is resuming from where it left off, its 1 click just to start the game.
If you resumed the app as if you switched to it using app switcher, then something definitely is broken on my end.
Just for completeness although most likely unimportant in this matter: Andoku had no internet access granted in AFWall+.
Click to expand...
Click to collapse
I do the same.
Oswald Boelcke said:
Unless you provide sufficient information about device, ROM, kernel and "configuration" (e.g. Magisk, Xposed, XprivacyLua, tools that restrict permissions, services, broadcast receiver etc.) most likely nobody is able to support you.
Click to expand...
Click to collapse
I am stock Pixel 3 XL with Magisk 18.1 root. Nothing else. I have given all perms needed by greenify.
Android hibernation is not the same as Windows hibernation.
Click to expand...
Click to collapse
I think this is where likely the disconnect is. I started using greenify several years ago (I have been here on these forums for a while, I keep that dated forum reference in my signature for remembering how far android and this community has come). If I recall correctly, I used to be able to resume apps, just by clicking or switching to them. Now, I notice a different behaviour: the app restarts from scratch. That's all. Obviously, I preferred the app to not start but resume like I was just switching to it.
I don't know if this is relevant in this case, but doesn't Greenify in non-root mode just force stop apps? I believe this to be the case because I can see it happening; i.e., when hibernation is triggered, for each app hibernated the app info screen briefly appears and the warning dialog about force stopping an app flashes on screen momentarily.
olliebean said:
I don't know if this is relevant in this case, but doesn't Greenify in non-root mode just force stop apps? I believe this to be the case because I can see it happening; i.e., when hibernation is triggered, for each app hibernated the app info screen briefly appears and the warning dialog about force stopping an app flashes on screen momentarily.
Click to expand...
Click to collapse
Correct. The equivalent happens on rooted devices just in a more efficient and largely transparent manner. If the ROM later opts to recover some/all of the resources consumed by the 'hibernated' app standard Android memory mgmt rules apply. In most cases that means only critical pointers are retained which may or may not contain sufficient information to resume from the point the app was in when last in the foreground.
Davey126 said:
Correct. The equivalent happens on rooted devices just in a more efficient and largely transparent manner. If the ROM later opts to recover some/all of the resources consumed by the 'hibernated' app standard Android memory mgmt rules apply. In most cases that means only critical pointers are retained which may or may not contain sufficient information to resume from the point the app was in when last in the foreground.
Click to expand...
Click to collapse
But AIUI, force stopping an app is essentially killing the app process. So for the app to start afresh when next launched, rather than resuming from where it was left, would be expected behaviour.
Is Greenifying an app functionally better than disabling Background Activity from the app's Battery Usage page (a new setting in Oreo)? IWHT the latter achieves the same result but without killing the app.
I am running root mode. So, let's not talk about non-root mode.
If a hibernated app is going to restart from scratch instead of resume, I might as well just clear all apps (that I fed to Greenify) on screen off with 5 min delay using tasker/automate. Why bother with anything else?
The point of Greenify was to be able to resume the app after hibernate as if you just switched to it. This used to work, I have tested it in the past. Not anymore though.
olliebean said:
But AIUI, force stopping an app is essentially killing the app process. So for the app to start afresh when next launched, rather than resuming from where it was left, would be expected behaviour.
Is Greenifying an app functionally better than disabling Background Activity from the app's Battery Usage page (a new setting in Oreo)? IWHT the latter achieves the same result but without killing the app.
Click to expand...
Click to collapse
Well, no ... but this is not the place for that discussion. Not going to get into Android 101 or validating speculation around various actions.
---------- Post added at 05:18 PM ---------- Previous post was at 04:52 PM ----------
devsk said:
I am running root mode. So, let's not talk about non-root mode.
If a hibernated app is going to restart from scratch instead of resume, I might as well just clear all apps (that I fed to Greenify) on screen off with 5 min delay using tasker/automate. Why bother with anything else?
The point of Greenify was to be able to resume the app after hibernate as if you just switched to it. This used to work, I have tested it in the past. Not anymore though.
Click to expand...
Click to collapse
Sorry it is not working with your device/kernel/ROM/root solution. Could be an adverse interaction with the doze mechanisms in Android 9, aggressive memory management settings (eg: VM, LMK), resource mapping of the app(s) you are trying to hibernate, etc. I have not see a lot of feedback from Pie users as doze generally addresses rogue background activity and corresponding power drain. So the behavior may be different on that platform. I use Greenify on a variety of devices for other reasons for which it continues to work well. Just another tool in shop; appropriate selection is the key to success. Good luck.
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.