Hey,
it seems that many games are wasting battery with the Wakelock AudioMix even when the whole audio is turned of (and I think they have not really other possibilities). I know I could compensate with the XPosed Module Amplify, which would let me set a time that has to be between two wakelocks, but that would also influence the media players. So is there a possibility to block the access to that Wakelock for some Apps only without affecting Apps that should use it? Or any other solutions?
With App-OPS and the Module "App Settings" I can mute apps and restricting acces to audio settings, but that seem to have no effect.
Artim_96 said:
Hey,
it seems that many games are wasting battery with the Wakelock AudioMix even when the whole audio is turned of (and I think they have not really other possibilities). I know I could compensate with the XPosed Module Amplify, which would let me set a time that has to be between two wakelocks, but that would also influence the media players. So is there a possibility to block the access to that Wakelock for some Apps only without affecting Apps that should use it? Or any other solutions?
With App-OPS and the Module "App Settings" I can mute apps and restricting acces to audio settings, but that seem to have no effect.
Click to expand...
Click to collapse
Interesting!!! Some developer could create this Xposed module .. "AudioMixTurnOff" .. With widget included to easily activate and deactivate, lol..
Or a module that automatically increases the amount of seconds that is limited in Amplify, in case, Audiomix (if it's not possible to turn off completely)
Well, I said some ideas..
Related
Hi
First of all thank you Oasis for creating a tool to fix things that shouldn't be broken to begin with! You are an example for a lot of developers :good:
I've read the first couple of posts on the original thread but I still have a few things that are not clear..
The advice of Oasis himself is too hibernate only those apps that misbehave. He states that hibernating apps will also remove them from the memory, which will come with a performance/cpu usage penalty when you want to use them again.
In the video tutorial however Josh greenifies almost every application that doesn't need push notifications.
So this would mean that when I use an application that doesn't have notifications but I open frequently, for example Nu.nl, a dutch newsapp, it will always have to reload the app from scratch instead of loading it from memory?
So baically the best way to use Greenify would be to NOT just greenify most apps, but to use the analyzer frequently and see what's running in the background and greenify those that don't depend on notifications?
Then newsapps that don't push news, image viewers, file managers, system tools like SD Maid and simple games that don't use internet should be ok not being greenified?
Is there no big list available of apps that misbehave or are safe to keep de-greenified?
Thanks in advance for any help on this.
Basically you got it right. Use the built-in analyzer as well as disable service and autostarts to check apps' behaviour. For my experience, sometimes is better to disable a background service than greenify an app, if the app "misbehave" for this service only (of course you'll have to check if the app still works). An example: guaranteedhttpservice and tracksyncservice in shazam...
marchrius said:
Basically you got it right. Use the built-in analyzer as well as disable service and autostarts to check apps' behaviour. For my experience, sometimes is better to disable a background service than greenify an app, if the app "misbehave" for this service only (of course you'll have to check if the app still works). An example: guaranteedhttpservice and tracksyncservice in shazam...
Click to expand...
Click to collapse
Where can I find and disable things like tracksyncservice? I also use Shazam but I can't find both services you mentioned in Greenify nor TiB?
latino147 said:
Where can I find and disable things like tracksyncservice? I also use Shazam but I can't find both services you mentioned in Greenify nor TiB?
Click to expand...
Click to collapse
"Disable Service" (and "Autostarts") from play store.
marchrius said:
"Disable Service" (and "Autostarts") from play store.
Click to expand...
Click to collapse
Ah, I believed those were two functions withing Greenify I couldn't find
wtf, FB has 62! services! None of them where active though, until you open the app, then it was 3.
So you can choose between greenifying an app which will basically kill all services from an app, even background services on one hand, and choosing specifically which services too disable, like you did with Shazam.
The only issue with this second method being that you don't always really know what these services do.
latino147 said:
So you can choose between greenifying an app which will basically kill all services from an app, even background services on one hand, and choosing specifically which services too disable, like you did with Shazam.
Click to expand...
Click to collapse
Exactly. Take google play services for example. If you greenify it, you'll lose gcm and other functions and that's not advisable at all (in fact greenify hides it). But with disable service (and autostarts/system tuner)you can choose what to disable while still mantaining gcm, location services (when needed), sync etc. I can' remember what I did in system tuner regarding gplay services (I followed some tutorial), but with disable service I disabled analyticsservice (this one will reactivate itself unless you do some tweak with system tuner), refreshenabledstateservice, playlogreportingservice, googlehttpservice, playlogbrokerservice, adrequestbrokerservice, gcmschedulerwakeupservice, advertisingidservice, adsmeasurementservice, locationwearablelistenerservice, nlplocationreceiverservice, geocodeservice, dispatchingservice and playlogservice. A reboot is needed. Haven't lost a single function since weeks (gcm, location, autosync and every google app in general are working 100% fine).
Same story with play store. Apps wake it very often, so greenify it does more harm than good. Instead, you can disable pendingnotificationsservice, contentsyncservice and dailyhygiene (and will still be fully functional).
Of course these are little tips to increase performance and battery life even more. I use greenify for 90% and more of apps that "misbehave" and disable service/autostarts/system tuner for the remaining 10% "misbehaving" apps. However, an app "fixed" with such methods will stay cached while with greenify is completely closed (resulting in more cpu/time/battery consumption when loaded again).
The only issue with this second method being that you don't always really know what these services do.
Click to expand...
Click to collapse
Like I already said, for general purposes you'd better simply greenify the "misbehaving" apps. If you use it/it is woken very often, you can consider these methods.
Yes, it's a "trial and error" thing. Unless you're disabling services with self-explainatory names such as "pushservice".
Never installed Facebook official app but I heard many times that is a notorious hogger and takes many personal datas too, for which you can look for xprivacy xposed module as well.
I'll start experimenting with it today :good:
Team - I am running the latest version of greenify posted on the playstore. I've followed guides for enabling agressive doze on android 6.0 on my moto x pure (non root) -- including adbing to the device to grant permissions on the app. It seems to be working most of the time. The device seems to go to sleep and i've seen a great increase in battery. However, seemingly randomly i'll notice battery draining fast. When i look at my usage its google play services keeping the device awake 100% of the time. If i reboot the phone, google play services stops doing that and all is well for awhile, till it repeats. I've been unable to find the cause of this. I imagine i'm missing some information that we might need to track this down. thanks in advance!
tange1 said:
Team - I am running the latest version of greenify posted on the playstore. I've followed guides for enabling agressive doze on android 6.0 on my moto x pure (non root) -- including adbing to the device to grant permissions on the app. It seems to be working most of the time. The device seems to go to sleep and i've seen a great increase in battery. However, seemingly randomly i'll notice battery draining fast. When i look at my usage its google play services keeping the device awake 100% of the time. If i reboot the phone, google play services stops doing that and all is well for awhile, till it repeats. I've been unable to find the cause of this. I imagine i'm missing some information that we might need to track this down. thanks in advance!
Click to expand...
Click to collapse
That may not have anything to do with Greenify unless you have greenified Play Services. If you have, remove it from hibernation.
Usually Play Services will go berserk upon updating itself in the background. What you can try is clear it's data and cache and reboot. If you have TWRP, do it in recovery. If not, do it in Settings>Apps.
tnsmani said:
That may not have anything to do with Greenify unless you have greenified Play Services. If you have, remove it from hibernation.
Usually Play Services will go berserk upon updating itself in the background. What you can try is clear it's data and cache and reboot. If you have TWRP, do it in recovery. If not, do it in Settings>Apps.
Click to expand...
Click to collapse
Thanks for the info. Here's what i've done:
I removed greenify, performed the actions you suggested and left greenify off for about 12 hours. No issues with google play services and keep awake. I reinstalled greenify and everything was good for a number of hours. Unfortunately the play services keep awake started again about 3.5 hours ago. The phone has a solid 'awake' bar in battery settings and play services is the culprit with 3.5 hours awake. While i dont blame greenify, there's some sort of correlation of events here that I can't explain.
tange1 said:
Thanks for the info. Here's what i've done:
I removed greenify, performed the actions you suggested and left greenify off for about 12 hours. No issues with google play services and keep awake. I reinstalled greenify and everything was good for a number of hours. Unfortunately the play services keep awake started again about 3.5 hours ago. The phone has a solid 'awake' bar in battery settings and play services is the culprit with 3.5 hours awake. While i dont blame greenify, there's some sort of correlation of events here that I can't explain.
Click to expand...
Click to collapse
Do you have Xposed? If so, install AppOpsXposed and untick the "Keep Awake" function of Play Services. Another thing you can try is uninstalling the update to the Play Services, reboot and then manually update it and again reboot.
If it is still not arrested, Google is your friend.
Unfortunately I've the same problem on my OnePlus 2 with stock ROM. I've installed Greenify two days ago, and enabled aggressive doze with amazing results! Last night I enabled Doze on the Go (using ADB) and since unplugging my phone this morning there is this constant wakelock of Google Play Services. Disabling Doze on the Go as well as reinstalling Greenify didn't help. Looking forward to a solution!
This is a known problem. Sometimes it's worse and sometimes less, but Google Play Services is a known offender in this manner. And Google processes in general. Part of the reason for this is that Google often wakes up your device, periodically, to track your location (horrible, yes, and it continued to happen for me even when all Google location options I could find, as well as GPS, were turned off).
Solutions that have reportedly worked for some people in the past (try one at a time or all of them) - they don't require root:
-Make sure you do not Greenify/freeze/hibernate Google Play Services, or similar processes, as this may make the issue worse.
-Clear cache and data of Google Play Services.
-Manually update Google Play Services to latest APK version available from your device, downloaded from the web. Make sure you select the right version for you. http://www.apkmirror.com/apk/google-inc/google-play-services
-Try turning off as many Google background features as you can, such as location tracking/history, etc.
I guess some of these steps may only work after the next reboot, so reboot the device when you're done.
But as I said, this process is a known big offender. The above may not work, or may work temporarily. The stronger and more permanent solutions require root (you don't really need to try the above options if you do these). The more of them you do, the less 'keep awake' you should experience:
-Install Xposed Installer app and install Xposed Framework, so you can use the modules mentioned below...
-Use AppOpsXposed module (or CM Privacy Guard if you have it) to deny keep awake permission to Google Play Services, and other Google background apps.
-This is a big one: Install Amplify (Xposed module) from the Play Store, and it will automatically take care of limiting Google wakelocks. That's it. If you pay for the pro version, then you can additionally tweak and limit all wakelocks, alarms and services on your device (pretty cool and useful, but more involved, so for advanced users).
Cultar said:
..............
-This is a big one: Install Amplify (Xposed module) from the Play Store, and it will automatically take care of limiting Google wakelocks. That's it. If you pay for the pro version, then you can additionally tweak and limit all wakelocks, alarms and services on your device (pretty cool and useful, but more involved, so for advanced users).
Click to expand...
Click to collapse
The unpaid version of Amplify will block a maximum of a couple of wakelocks related to location. Only the pro version is capable of blocking other wakelocks and alarms including those of Play Services. But as you said, it is not automatic and you will have to set it up.
Any updates on this?
Google play services is awful
MSK1 said:
Any updates on this?
Google play services is awful
Click to expand...
Click to collapse
Not a Greenify issue. Some devices/ROMs/configs seem more susceptible to GPS runaway. Clearing GPS cache+data on occasion followed by an immediate reboot has proven helpful for some. Good luck.
The Greenify app (root mode) identified a particular Broadcast Receiver, the "PackageMonitorReceiver$RegisteredReceiver", that wakes up the Play Store whenever certain apps are booted on certain occasions. I applied the cutoff, but the Play Store still pops up in Greenify every time I start up my VPN app, not only ignoring the cutoff but apparently ignoring the fact that the app has been run multiple times (the Intents are package_added, package_removed, package_changed, package_first_launch, and external_applications_(un)available; I'm not sure which one it might be reacting to).
I do not even have to activate the VPN service for this to occur, only launch the app. For other apps, the Play Store will run in the background on the first bootup but will stop afterwards. Both brand new apps and this VPN app will still cause the Play Store to reenable its Receiver service (which I disabled in MyAndroidTools only to see it reactivate itself each time I use another app) and ignore Greenify's path cutoff despite the cutoff still being active and recognized within the client: Greenify shows that the VPN app is what woke the Play Store up and that the wakeup path has already been cut off. This may not be a Greenify "problem" but it might be worth mentioning that the cutoff isn't being honored.
animeme said:
The Greenify app (root mode) identified a particular Broadcast Receiver, the "PackageMonitorReceiver$RegisteredReceiver", that wakes up the Play Store whenever certain apps are booted on certain occasions. I applied the cutoff, but the Play Store still pops up in Greenify every time I start up my VPN app, not only ignoring the cutoff but apparently ignoring the fact that the app has been run multiple times (the Intents are package_added, package_removed, package_changed, package_first_launch, and external_applications_(un)available; I'm not sure which one it might be reacting to).
I do not even have to activate the VPN service for this to occur, only launch the app. For other apps, the Play Store will run in the background on the first bootup but will stop afterwards. Both brand new apps and this VPN app will still cause the Play Store to reenable its Receiver service (which I disabled in MyAndroidTools only to see it reactivate itself each time I use another app) and ignore Greenify's path cutoff despite the cutoff still being active and recognized within the client: Greenify shows that the VPN app is what woke the Play Store up and that the wakeup path has already been cut off. This may not be a Greenify "problem" but it might be worth mentioning that the cutoff isn't being honored.
Click to expand...
Click to collapse
If you have Xposed Framework installed try the MyAndroidTools module which attempts to address this behavior.
Davey126 said:
If you have Xposed Framework installed try the MyAndroidTools module which attempts to address this behavior.
Click to expand...
Click to collapse
Don't have Xposed, unfortunately. If possible, I'd like to avoid it anyway
animeme said:
Don't have Xposed, unfortunately. If possible, I'd like to avoid it anyway
Click to expand...
Click to collapse
Understand, but recognize w/o Xposed you loose access to more advanced tools and methods - including those utilized by Greenify that are not entirely contained to user selectable Xposed features.
Davey126 said:
Understand, but recognize w/o Xposed you loose access to more advanced tools and methods - including those utilized by Greenify that are not entirely contained to user selectable Xposed features.
Click to expand...
Click to collapse
Yea, it seems Deep Hibernation was required. Unfortunate since I had just gotten safetynet working with microg. Oh well, thanks for the bad news :silly:
Hi all,
I did not have this enabled but the standing advice seems to be that it has to be enabled. What does this do exactly?
Loving the app though keep up the good work!
Jeroen1000 said:
Hi all,
I did not have this enabled but the standing advice seems to be that it has to be enabled. What does this do exactly?
Loving the app though keep up the good work!
Click to expand...
Click to collapse
Not needed except w/unrooted device to facilitate screen off operations.
Davey126 said:
Not needed except w/unrooted device to facilitate screen off operations.
Click to expand...
Click to collapse
Thanks Davey126. There was an option in Greenify once to ensure compatibility with finger print readers. It was called "alternative screen off mode". I hoped this option got dubbed the Automator now but it doesn't look that way judging from your reply. I can't find it any more (maybe it got removed for some reason?). Sometimes the fingerprint reader on my OPO5T is a bit slow. I need to lift and touch it twice to get an unlock. Maybe I need to whitelist ...something as I have "Greenify system apps" checked. Amongst the optimised apps is "GFManager" which has a fingerprint icon.
At any rate, do you know what happened to "alternative screen off mode" option?
Jeroen1000 said:
Thanks Davey126. There was an option in Greenify once to ensure compatibility with finger print readers. It was called "alternative screen off mode". I hoped this option got dubbed the Automator now but it doesn't look that way judging from your reply. I can't find it any more (maybe it got removed for some reason?). Sometimes the fingerprint reader on my OPO5T is a bit slow. I need to lift and touch it twice to get an unlock. Maybe I need to whitelist ...something as I have "Greenify system apps" checked. Amongst the optimised apps is "GFManager" which has a fingerprint icon.
At any rate, do you know what happened to "alternative screen off mode" option?
Click to expand...
Click to collapse
Don't know but removal is likely referenced (somewhere) in a change log or forum post. XDA search is your friend.
As for the fingerprint recognition issue why is "GFManager" and likely other benign system apps in Greenify's overt hibernation list? Only demonstrated 'bad actors' should be there; ideally the list will be quite small gravitating to zero.
Do you take 23 aspirin in the morning for the hell of it to protect yourself from some pain that has never materialized? Over greenification (new word!) is just asking for trouble.
Davey126 said:
Don't know but removal is likely referenced (somewhere) in a change log or forum post. XDA search is your friend.
As for the fingerprint recognition issue why is "GFManager" and likely other benign system apps in Greenify's overt hibernation list? Only demonstrated 'bad actors' should be there; ideally the list will be quite small gravitating to zero.
Do you take 23 aspirin in the morning for the hell of it to protect yourself from some pain that has never materialized? Over greenification (new word!) is just asking for trouble.
Click to expand...
Click to collapse
I didn't put GFManager in the Doze optimising list manually. It could just be the management app (judging by its name) for fingerprints for all I know not the actual code that does the detection. I just blame Apple for just having 2% drain per 8 hours idle and then some of us wanting that on an Android phone.
Jeroen1000 said:
I didn't put GFManager in the Doze optimising list manually. It could just be the management app (judging by its name) for fingerprints for all I know not the actual code that does the detection. I just blame Apple for just having 2% drain per 8 hours idle and then some of us wanting that on an Android phone.
Click to expand...
Click to collapse
Android battery optimization (Android 6+) is different from explicitly adding items to Greenify's hibernation list (which I assumed you were doing as some [incorrectly] use the terms interchangeably). Most likely the intermittent touch recognition hesitation you are experiencing is not related to GFManager being "optimized" but rather the time it takes the device to arise from a deep slumber. Are you using Aggressive Doze by chance?
iOS and Android can both idle efficiently on appropriate hardware. I typically see 0.2-0.5%/hr idle drain on my various devices depending on conditions. Apple has the advantage as it controls both hardware and software. Android must accommodate a wide variety of hardware platforms (including crappy kernels) many of which are not well optimized for power savings.
Davey126 said:
Android battery optimization (Android 6+) is different from explicitly adding items to Greenify's hibernation list (which I assumed you were doing as some [incorrectly] use the terms interchangeably). Most likely the intermittent touch recognition hesitation you are experiencing is not related to GFManager being "optimized" but rather the time it takes the device to arise from a deep slumber. Are you using Aggressive Doze by chance?
iOS and Android can both idle efficiently on appropriate hardware. I typically see 0.2-0.5%/hr idle drain on my various devices depending on conditions. Apple has the advantage as it controls both hardware and software. Android must accommodate a wide variety of hardware platforms (including crappy kernels) many of which are not well optimized for power savings.
Click to expand...
Click to collapse
Yes, I am using aggressive doze. Via the whitelist you can access in Greenify, it seems almost everything gets Optimised (dozed).
I would assume the fingerprint scanner would be exempt from doze but the non-optimised apps list doesn't have anything in it that I can connect to the reader. I would likewise assume I'd have to look for something like com.qualcomm... instead of looking for an actual app name. I could use a tip as to what I'm looking for...
So to be clear, I did not add stuff to the hibernation list manually with regards to the fingerprint reader. Just some stuff that by far has nothing to do with it.
For full disclosure: Via a Magisk module, my Google Play Services also get dozed. It is called "Enable Doze for GMS Magisk Module".
a bit off topic:
I can get an idle drain around 0.5% and using HEBF optimiser's "Improve Battery" switch this goes down to 0.4%. What are you doing to get even lower? I'm betting turning off WIFI and nuking play services entirely?
Jeroen1000 said:
Yes, I am using aggressive doze. Via the whitelist you can access in Greenify, it seems almost everything gets Optimised (dozed).
I would assume the fingerprint scanner would be exempt from doze but the non-optimised apps list doesn't have anything in it that I can connect to the reader. I would likewise assume I'd have to look for something like com.qualcomm... instead of looking for an actual app name. I could use a tip as to what I'm looking for...
So to be clear, I did not add stuff to the hibernation list manually with regards to the fingerprint reader. Just some stuff that by far has nothing to do with it.
For full disclosure: Via a Magisk module, my Google Play Services also get dozed. It is called "Enable Doze for GMS Magisk Module".
Click to expand...
Click to collapse
Again, doze and hibernation are different things. I would expect every user app and virtually every system app (with exception to Google Play Services) to be 'battery optimized'. Observations:
- analysis begins with disabling referenced Magisk module as Google Play Services is deeply intertwined with most apps and services (system and user)
- disable aggressive doze; putting your device into a comma isn't helpful when trying to diagnose a responsiveness issue
- multiple deferred tasks often fire-up immediately when exiting aggressive doze temporarily overwhelming device and introducing lag
- nothing should be in Greenify's active hibernation list except apps/services that are demonstrated offenders
Pretty good chance you have created the problem you are trying to solve my over managing your device.
Jeroen1000 said:
a bit off topic:
I can get an idle drain around 0.5% and using HEBF optimiser's "Improve Battery" switch this goes down to 0.4%. What are you doing to get even lower? I'm betting turning off WIFI and nuking play services entirely?
Click to expand...
Click to collapse
Nope. Stock ROM (rooted/unlocked); stock Google Play Services, WiFi and mobile radios on 7x24, location services generally on and set to 'high accuracy', BT and NFC cycled as needed, other than Greenify no 3rd party 'power saving' tools in play. Full believer in lite-touch management with results to back-up religion on multiple devices. YMMV. Choose your apps wisely.
Thanks for the tips. I'll revert my changes one by one and see what turns up. Don't want to loose aggressive doze though... I will report back if I find the culprit.
I understand the difference between doze and hibernation. I was just trying to point out it's not me putting stuff manually on the hibernation list. And yes, I support your observation, using too many apps trying to get even lower drain often works counterproductive. Same goes for apps monitoring battery stats. They too use up some juice.
Jeroen1000 said:
Thanks for the tips. I'll revert my changes one by one and see what turns up. Don't want to loose aggressive doze though... I will report back if I find the culprit.
Click to expand...
Click to collapse
Suggest a reconsideration of position on aggressive doze. While the glossy looks great measurable benefits don't always offset liabilities. With AD active device will likely show reduced drain during extended screen-off operations. A win, right? Possibly - until you factor in higher drain rates as the device races to catch up after exiting doze which is often triggered by an overt wake request (ie: using your device). Several minutes of high CPU utilization at max (and often power inefficient) frequencies can wipe out hours of slow savings while introducing lag and other undesirable side effects. You should disable AD for a few days to see if it improves your situation.
As an aside, brief sprints at high CPU frequencies are not necessarily evil as finishing a task quickly and returning to idle (see "race to idle") can be more efficient than drawing it out over an extended period of time at lower frequencies. That said, servicing multiple tasks over several minutes when the device first wakes is often less efficient than allowing them to complete 'naturally' when the screen goes off (which is why doze doesn't kick in immediately) and/or during normal doze maintenance windows.
Aggressive doze can be beneficial in certain circumstances - but those are few and far between (at least based on my personal work flows and observation of others).
Hi,
I recently installed Greenify on my Pocophone F1 /MIUI 10.3 on which I have already Tasker.
For Tasker, I have removed all battery restrictions so it is never optimized and it is fine. If I stop it manually, then for I don't know which reason accessibility and notification services get disabled so I have to enable them again.
The problem since I installed Greenify is that although Tasker is not part of the apps to hibernate, after some time when the screen is off, the same services get disabled on Tasker, exactly as if Tasker was forced to stop. So I am wondering why Greenify acts like this and how to prevent it? Isn't there any kind of whitelist?
I have not changed any default setting in Greenify.
Any idea what is happenning?
Thx.