Hi! My App (KLWP, see official thread) is currently using content providers to fetch presets from Play Store downloaded skin packs, problem is that some user are reporting that templates are not loaded correctly and i can find in their logs the following statement:
Code:
I/DeepHyber( 1382): Refuse content request for hibernated app: glassatlas.kustom.waveandanchor/org.kustom.api.Provider
So:
Is "DeepHyber" tag is from this app/mod?
Any idea on how i can prevent the provider being stopped?
Thanks!
frankmonza said:
Hi! My App (KLWP, see official thread) is currently using content providers to fetch presets from Play Store downloaded skin packs, problem is that some user are reporting that templates are not loaded correctly and i can find in their logs the following statement:
Code:
I/DeepHyber( 1382): Refuse content request for hibernated app: glassatlas.kustom.waveandanchor/org.kustom.api.Provider
So:
Is "DeepHyber" tag is from this app/mod?
Any idea on how i can prevent the provider being stopped?
Thanks!
Click to expand...
Click to collapse
I think that only the Dev can answer that properly.
There is Deep Hibernation in Greenify. So may be that tag is from Greenify. The users seem to have hibernated your app and also enabled Deep Hibernation in Greenify. They can ungreenify your app which will solve the issue.
So over to you @oasisfeng .
tnsmani said:
I think that only the Dev can answer that properly.
There is Deep Hibernation in Greenify. So may be that tag is from Greenify. The users seem to have hibernated your app and also enabled Deep Hibernation in Greenify. They can ungreenify your app which will solve the issue.
So over to you @oasisfeng .
Click to expand...
Click to collapse
Thanks, so, yes, disabling Greenify works (just got the confirmation from an user, so its almost certainly caused by it) while ungreenifying probably doesn't help because you would need to disable it on all the "skin" apps because they all have their own provider.
My problem currently is that i can either detect greenify in the app and ask the user to disable it or i need to find a way around this to avoid it disabling the providers i need (otherwise i will keep getting requests from users saying that they cannot load presets without knowing why).
If you tell the users to disable Greenify completely, they are going to lose its functionality completely. Better tell them to ungreenify your app and any others that need content providers till you and @oasisfeng find a solution, so that the users have both apps functioning, albeit Greenify less fully.
As an experiment, you can tell the users to disable Deep Hibernation alone (in Greenify) instead of completely diabling Greenify.
tnsmani said:
If you tell the users to disable Greenify completely, they are going to lose its functionality completely. Better tell them to ungreenify your app and any others that need content providers till you and @oasisfeng find a solution, so that the users have both apps functioning, albeit Greenify less fully.
As an experiment, you can tell the users to disable Deep Hibernation alone (in Greenify) instead of completely diabling Greenify.
Click to expand...
Click to collapse
I cannot ask them to "ungreenify" 10/20/30 apps, too much work, disabling deep hibernation works (and i am asking to disable just that, i did not express myself correctly). But this is a minor issue i am not taking any action yet, just got 3/4 reports so its not that urgent, there is time to find a better solution
Deep Hibernation is a new *experimental* feature in Greenify, which blocks any attempts to launch the process of hibernated apps, including content provider.
In theory, this feature only affects hibernated app. But in a side effect, all newly installed apps on Android are in "hibernated" state initially, this behavior, in my understand, caused the trouble for your app.
My apologizes! I'm working on this issue and planned to fix it in the next version. Before that, please advise the users to manually "wake up" the newly installed app once either by launching any of its activities or by temporarily deactivating "Deep Hibernation" for a short while. Once the app is launched once and not explicitly greenified by user, it will not be affected by Deep Hibernation any more.
oasisfeng said:
Deep Hibernation is a new *experimental* feature in Greenify, which blocks any attempts to launch the process of hibernated apps, including content provider.
In theory, this feature only affects hibernated app. But in a side effect, all newly installed apps on Android are in "hibernated" state initially, this behavior, in my understand, caused the trouble for your app.
My apologizes! I'm working on this issue and planned to fix it in the next version. Before that, please advise the users to manually "wake up" the newly installed app once either by launching any of its activities or by temporarily deactivating "Deep Hibernation" for a short while. Once the app is launched once and not explicitly greenified by user, it will not be affected by Deep Hibernation any more.
Click to expand...
Click to collapse
Thanks for the reply! No worries, the most complex thing was finding the issue (most users have no idea of what logcat is and i was just getting an empty cursor from the provider so had no log anywhere within the app).
Anyway, the problem here is that skin packs do not have any activity, they just have a content provider, so the user cannot launch the activity and also a reboot won't fix the issue, so, unless they disable this feature the content won't be loaded.
What about disabling this feature for content providers entirely by default?
frankmonza said:
Thanks for the reply! No worries, the most complex thing was finding the issue (most users have no idea of what logcat is and i was just getting an empty cursor from the provider so had no log anywhere within the app).
Anyway, the problem here is that skin packs do not have any activity, they just have a content provider, so the user cannot launch the activity and also a reboot won't fix the issue, so, unless they disable this feature the content won't be loaded.
What about disabling this feature for content providers entirely by default?
Click to expand...
Click to collapse
Deep Hibernation was initially launched without the blocking of content providers. But apps like Amazon Appstore use content provider (of the Appstore app) heavily within all apps distributed by them (most app developers are not aware of this injected nasty behavior), causing wake-ups constantly. As requested by users of Greenify, content provider is added to the blocking target.
If the skin pack has only resources, I'd suggest the more efficient direct resource loading via PackageManager.getResourcesForApplication() instead of content provider, unless code within the skin pack is also needed to run.
oasisfeng said:
Deep Hibernation was initially launched without the blocking of content providers. But apps like Amazon Appstore use content provider (of the Appstore app) heavily within all apps distributed by them (most app developers are not aware of this injected nasty behavior), causing wake-ups constantly. As requested by users of Greenify, content provider is added to the blocking target.
If the skin pack has only resources, I'd suggest the more efficient direct resource loading via PackageManager.getResourcesForApplication() instead of content provider, unless code within the skin pack is also needed to run.
Click to expand...
Click to collapse
The provider does caching and other stuff so i cannot use "PackageManager.getResourcesForApplication()" which also has issues with paid app since on those assets go into the private area.
Only options i see are:
Detect greenify and ask the user to disable the feature with a popup
Greenify "greenlists" providers with "android:name" -> org.kustom.api.Provider
Greenify provides a way to disable this feature via a broadcast
Thoughts?
frankmonza said:
The provider does caching and other stuff so i cannot use "PackageManager.getResourcesForApplication()" which also has issues with paid app since on those assets go into the private area.
Only options i see are:
Detect greenify and ask the user to disable the feature with a popup
Greenify "greenlists" providers with "android:name" -> org.kustom.api.Provider
Greenify provides a way to disable this feature via a broadcast
Thoughts?
Click to expand...
Click to collapse
This issue will be fixed in the implementation of Deep Hibernation in the next version of Greenify. After that, everything will be back to what it used to be.
oasisfeng said:
This issue will be fixed in the implementation of Deep Hibernation in the next version of Greenify. After that, everything will be back to what it used to be.
Click to expand...
Click to collapse
Cool, thanks
Just curious, what are you going to change?
oasisfeng said:
This issue will be fixed in the implementation of Deep Hibernation in the next version of Greenify. After that, everything will be back to what it used to be.
Click to expand...
Click to collapse
Deep Hibernation would no longer treat newly installed apps as hibernated.
oasisfeng said:
This issue will be fixed in the implementation of Deep Hibernation in the next version of Greenify. After that, everything will be back to what it used to be.
Click to expand...
Click to collapse
Not sure if next version has been released yet but my users are still reporting the issue. If it has been released Is there any way to detect if the deep hibernation feature is enabled from another app? I mean, i can show a dialog if the provider returns 0 entries but that would be an hack since it might be something else.
oasisfeng said:
Deep Hibernation would no longer treat newly installed apps as hibernated.
Click to expand...
Click to collapse
Hi @oasisfeng did you check this issue? I will add a popup to ask the users to remove Greenify deep hibernation from next version when provider returns zero results but i'd prefer it to be solved on Greenify end, any 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:
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:
I been having huge RAM consumption with UC web browser, the app has a continuous foreground activity. Now, this is only app that keeps running on background and draining my battery. Is there anyway to force UCbrowser to hibernate using the shortcut hibernate icon? I mean instead of manually open the Greenify, the hibernation icon on my desktop shortcut should do the job.
I know that Greenify does not hibernate an app with constant foreground activity but UCbrowser is way too aggressive. Ironically, i don't want to uninstall UC because i like the browser functionality but only for browsing the web not its constant background activity.
I already turn off all of its in-app notifications such as Facebook, updates, news, ads, and even the "system" notification which i found inside the UC.
I hope someone can help me dealing this problem.
MrBrowseGierza said:
I been having huge RAM consumption with UC web browser, the app has a continuous foreground activity. Now, this is only app that keeps running on background and draining my battery. Is there anyway to force UCbrowser to hibernate using the shortcut hibernate icon? I mean instead of manually open the Greenify, the hibernation icon on my desktop shortcut should do the job.
I know that Greenify does not hibernate an app with constant foreground activity but UCbrowser is way too aggressive. Ironically, i don't want to uninstall UC because i like the browser functionality but only for browsing the web not its constant background activity.
I already turn off all of its in-app notifications such as Facebook, updates, news, ads, and even the "system" notification which i found inside the UC.
I hope someone can help me dealing this problem.
Click to expand...
Click to collapse
There are many fine browsers with great feature/functionality that do not exhibit insidious UC behaviors. That said, recent Greenify builds permit ignoring foreground activity. Highlight the UC entry in your watch list and open the overflow (3-dot) menu for options.
@MrBrowseGierza: Personally, I absolutely concur with @Davey126's statement. I use the following two browsers, FOSS Browser and Firefox Klar, but I'm aware that their functionalities do not necessarily serve everybody's requirement. Especially Firefox Klar only carries a very bare minimum and is clearly focused on privacy, and as usual you must first familiarise yourself with their user interfaces. But for those two, I can clearly promise a very decent battery usage. Another personal option could be Fennec.
Anyhow, what I don't understand really: Gratefully, you were able to clearly identify a source, the root for heavy battery drainage but you only want to fight the symptoms and not cure the buddy. I don't know if this is the right way?
EDIT: Without haven't ever UC Browser installed and no own personal look into it, I checked Exodus Privacy just for fun, and I know for sure I wouldn't install or use it: https://reports.exodus-privacy.eu.org/reports/14541/
Davey126 said:
There are many fine browsers with great feature/functionality that do not exhibit insidious UC behaviors. That said, recent Greenify builds permit ignoring foreground activity. Highlight the UC entry in your watch list and open the overflow (3-dot) menu for options.
Click to expand...
Click to collapse
that's really manual way to greenify UC, I guess UC developers see-through this that's why they took advantage with this not hibernating apps with foreground activity.
I really hope greenify can fix this flaw.
MrBrowseGierza said:
that's really manual way to greenify UC, I guess UC developers see-through this that's why they took advantage with this not hibernating apps with foreground activity.
I really hope greenify can fix this flaw.
Click to expand...
Click to collapse
Flaw?? Hardly. Intentional actions that should serve as a red flag. A few comments:
- method I referenced is fully automated
- hibernated apps can be restarted unless 'wake-up' paths are severed
- there can only be one active 'foreground' app; everything else is background
- there is no "flaw" for Greenify to address
Davey126 said:
Flaw?? Hardly. Intentional actions that should serve as a red flag. A few comments:
- method I referenced is fully automated
- hibernated apps can be restarted unless 'wake-up' paths are severed
- there can only be one active 'foreground' app; everything else is background
- there is no "flaw" for Greenify to address
Click to expand...
Click to collapse
:good:
MrBrowseGierza said:
that's really manual way to greenify UC, I guess UC developers see-through this that's why they took advantage with this not hibernating apps with foreground activity.
I really hope greenify can fix this flaw.
Click to expand...
Click to collapse
In my opinion, UC Browser is intentionally coded the way that it permanently collects and transmits data of its users, and in turn obviously for the burdon of battery capacity or RAM/CPU. Just a few ideas are linked:
https://en.wikipedia.org/wiki/UC_Browser (see paragraph "Security & Privacy)
https://citizenlab.ca/2015/05/a-chatty-squirrel-privacy-and-security-issues-with-uc-browser/
http://androroot.com/2017/08/is-really-uc-browser-is-safe-risk-and.html
A web-search provides additionaly information.
MrBrowseGierza said:
that's really manual way to greenify UC, I guess UC developers see-through this that's why they took advantage with this not hibernating apps with foreground activity.
I really hope greenify can fix this flaw.
Click to expand...
Click to collapse
What Davey126 meant is that you can control UC browser by following the steps mentioned by him.
Disable password for device
2ISAB said:
Disable password for device
Click to expand...
Click to collapse
???
tnsmani said:
???
Click to expand...
Click to collapse
Sometimes, having a password setup on the device, prevents greenify from auto hibernating. It's a one in ten shot...
2ISAB said:
Sometimes, having a password setup on the device, prevents greenify from auto hibernating. It's a one in ten shot...
Click to expand...
Click to collapse
Urban legend; have never heard/seen this. Knowing what happens when Greenify attempts to initiate post screen-off hibernation on an unrooted device (via accessibility) strongly suggests the presence of a lockscreen password is not in play.
Davey126 said:
Urban legend; have never heard/seen this. Knowing what happens when Greenify attempts to initiate post screen-off hibernation on an unrooted device (via accessibility) strongly suggests the presence of a lockscreen password is not in play.
Click to expand...
Click to collapse
It deactivates auto when screen off (greenify) as soon as a password is setup on a urooted N7. fyi
I remember how much of a pain it was searching forums for a simple solution.
OP doesn't mention Android version...
2ISAB said:
It deactivates auto when screen off (greenify) as soon as a password is setup on a urooted N7. fyi
I remember how much of a pain it was searching forums for a simple solution.
OP doesn't mention Android version...
Click to expand...
Click to collapse
Interesting. There have been random public reports of Automatic Hibernation becoming disabled - either spontaneously (GUI slider doesn't stick) or after a period of time. It always seems isolated with no correlation to device, rom, etc. It feels like a permissions issue, although none are required for basic use.
My android device is rooted with xposed framework installed and greenify xposed module enabled. What Greenify settings i can enable to make it perform at its best?
Peter770 said:
My android device is rooted with xposed framework installed and greenify xposed module enabled. What Greenify settings i can enable to make it perform at its best?
Click to expand...
Click to collapse
There is no right answer as every device and work flow is unique. That said, Aggressive Doze, Doze on the Go and Wakeup Timer Coalescing are popular choices with limited side effects. If you miss notifications or find your device lagging for a few seconds after wake disable Aggressive Doze. Resist the temptation to add every app/service to Greenify's action list; only target apps that demonstrate bad behaviors. If running Android 6+ doze will take care of most background activity w/o help from Greenify. It's a tool to address specific problems.
What is the difference between the three hibernation modes: default, normal hibernation, deep hibernation (by island)?
Peter770 said:
What is the difference between the three hibernation modes: default, normal hibernation, deep hibernation (by island)?
Click to expand...
Click to collapse
Default is whatever you set as the default in Greenify settings. Normal is what Android uses by default and is adequate for the vast majority of work flows. Deep requires an add on product (Island) and seems to be a solution looking for a problem. You could have discovered all this by searching the thread or reading documentation.
Peter770 said:
What is the difference between the three hibernation modes: default, normal hibernation, deep hibernation (by island)?
Click to expand...
Click to collapse
I absolutely concur to @Davey126's correct statement and recommendation, and I'm unable to add anything substantial. However, I like to share my settings (please refer to attached screenshots), and if interested and required I'll provide information, which of my applications are not greenified.
Regarding your question, at least from my point of view all settings are pretty well explained within Greenify but it's also worth to study the threads by @oasisfeng that are pinned to this Greenify forum.
Thanks, for the screenshots. It was helpful.
I have problem with some apps, like Nine email client, which won't hibernate. Why is that?
Peter770 said:
I have problem with some apps, like Nine email client, which won't hibernate. Why is that?
Click to expand...
Click to collapse
They might be woken up by other apps. If so, you can cut off the links using wakeup tracker option in Greenify's settings.
'Wake-up tracking and cut-off' option is enabled.
Peter770 said:
'Wake-up tracking and cut-off' option is enabled.
Click to expand...
Click to collapse
Merely enabling the option is not enough. You have to manually cut off the trigger. When an app which you greenified wakes up automatically and is shown in Greenify as pending hibernation, if you long press the app, it will show some info like which app or process triggered it and whether it is critical etc. Then you can click the three dot menu button at top right and choose to cut off the trigger using the scissor icon or to ignore its running state. Then it will remain hibernated. Be careful while choosing the options since it may have unwanted side effects. Unless you are sure that you don't absolutely want that app to run in the background and be woken only upon your choosing to open it, don't meddle with the options.
EDIT: I am rusty with Greenify since I haven't installed it for my daily driver and hence the instructions are from memory. There may be some slight differences with what I stated and the actual behaviour.
I don't see these Greenify options but my device is running android 4.4.2 and that might be the reason.
Peter770 said:
I don't see these Greenify options but my device is running android 4.4.2 and that might be the reason.
Click to expand...
Click to collapse
Sorry, I have no idea since I never ran Greenify before MM and that was looong ago.
DB126 said:
Default is whatever you set as the default in Greenify settings. Normal is what Android uses by default and is adequate for the vast majority of work flows. Deep requires an add on product (Island) and seems to be a solution looking for a problem. You could have discovered all this by searching the thread or reading documentation.
Click to expand...
Click to collapse
True man, but i am looking for that documentation for a few days (cause i like to read...); so i ended up here... still... no documentation...
So please, if you are kind, give me a link to Greenify documentation.!
Thanks.!
Robotu said:
True man, but i am looking for that documentation for a few days (cause i like to read...); so i ended up here... still... no documentation...
So please, if you are kind, give me a link to Greenify documentation.!
Thanks.!
Click to expand...
Click to collapse
Greenify is obsolete; power management approaches of the past are no longer relevant. Looking forward is a better time investment. Greenify documentation exists somewhere but I'm not going hunting. Good luck, mate.
DB126 said:
Greenify is obsolete; power management approaches of the past are no longer relevant. Looking forward is a better time investment. Greenify documentation exists somewhere but I'm not going hunting. Good luck, mate.
Click to expand...
Click to collapse
Very true, though it took me a few days to convince myself..., just to remember why i freezed it few years ago...
Thanks...!
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.