I use Greenify with shallow hibernation.
I noticed that various apps like Facebook, Messenger, Whatsapp and Tapatalk sometimes are offline when I try to use (to refresh a page, to check a status or a message, etc.). After minutes and casually they return online. I'm sure that it is not a connection problem, and if I substitute shallow hibernation with normal hibernation this problem does not exists. So I think that it is a shallow hibernation bug. This happens with all the last versions of Greenify, beta and stable.
Do you have any feedback?
My system is a rooted Samsung Galaxy S5 stock 6.0.1.
rogxd said:
I use Greenify with shallow hibernation.
I noticed that various apps like Facebook, Messenger, Whatsapp and Tapatalk sometimes are offline when I try to use (to refresh a page, to check a status or a message, etc.). After minutes and casually they return online. I'm sure that it is not a connection problem, and if I substitute shallow hibernation with normal hibernation this problem does not exists. So I think that it is a shallow hibernation bug. This happens with all the last versions of Greenify, beta and stable.
Do you have any feedback?
My system is a rooted Samsung Galaxy S5 stock 6.0.1.
Click to expand...
Click to collapse
I experience something similar with Youtube, Maps and Firefox which i greenified: sometimes, when i resume them from hibernation, they can't go online. The connection is ok and other apps can connect but not those ones. Try to hibernate them again manually with the greenify button, then reopen them and see if they can connect.
Did you also disable any broadcast receiver for the problematic apps?
Are you still experiencing this problem after one year?
i'm on a sony stock 6.0.1 rom
Real question why use shallow hibernation? What problem/behavior are you attempting to address? Although native to Android 6+ it seems this mode is automatically utilized by normal/regular/standard doze as needed. I don't see a benefit to using it globally but obviously individual situations vary.
Additional background: https://greenify.uservoice.com/knowledgebase/articles/828357
Davey126 said:
Real question why use shallow hibernation? What problem/behavior are you attempting to address? Although native to Android 6+ it seems this mode is automatically utilized by normal/regular/standard doze as needed. I don't see a benefit to using it globally but obviously individual situations vary.
Additional background: https://greenify.uservoice.com/knowledgebase/articles/828357
Click to expand...
Click to collapse
I'm answering this a month later but would like to point out that for me Shallow Hibernation is amazing.
I have a device with plenty of memory for my usage, so I don't need the app to be wiped out of memory every time, just to be set as inactive.
For example, I found that Spotify is a great candidate for Shallow Hibernation.
Whenever I'm listening music on my computer, my phone has a tendency to stay awake because of Spotify Connect.
However if I shallow hibernate it, it won't keep the phone awake but still be kept in memory for me to use whenever I want. The same things goes for Maps, Youtube, and some games.
I’ve put an “Hibernate and Sleep” shortcut at homescreen and works really great.
Related
@oasisfeng Disclaimer: Apologies in advance -- this is a long one!
I've been experiencing an odd issue, as of late, running the 2.6.1 stable on my Nexus 5 (LP 5.1 / LMY47I, Cataclysm ROM). I'm using Root Mode (donation version), without Xposed.
This issue is slightly difficult to explain. By observing my SuperSU logs, I've noticed that a seemingly random and previously Greenified app will be continually hibernated every 30 minutes or so, each time my device goes idle for a prolonged period (such as while I'm working, or asleep). Curiously, the apps in question will change during each idle period, largely excluding the possibility that this is simply the case of a rogue app. The various apps are usually quite innocuous, and never known to (randomly) wake while my device is in use -- last night's was MX Player, for instance.
(Edit: Upon further observation, it seems that the random app in question is often among the last to have been manually woken/used before entering the next deep sleep period, in case it helps.)
Unfortunately, I've yet to successfully return to my device in time to catch any possible wake-up paths. I do question, however, if the apps are actually being woken in the first place (as opposed to Greenify simply "re-hibernating" apps that are already sleeping), as the issue will seemingly disappear entirely when auto-hibernation is disabled -- according to my SU logs, at least.
The only potential user-side cause that I can think of is that I had previously cut-off the Google Play Services wake-up path for Maps (neither G.P.S. nor any important system apps were ever actually hibernated). I've since re-attached the wake-up path, and de-Greenified Maps. Although that's probably unrelated, it's pretty much the "riskiest" thing I've done with Greenify on this device. I normally just keep a number of seldomly used user apps hibernated, and don't have any known offenders (like Facebook) on my device.
I've since removed and re-added each of my hibernated apps, as well as reinstalled Greenify (and its donation package) several times. I should note, as well, that I have not experienced any noticeable battery drains. Unfortunately, I'm unable to confirm whether or not this occurred before updating to Greenify 2.6.1 stable -- I've simply only observed this behavior since the Play Store rollout.
I've attached an example screenshot of my SuperSU log (taken after a 7 hour idle period), just so you can better visualize the pattern (the actual content of each log is simply the usual force stop message). Apologies for not providing anything more helpful at this time; please let me know if there's anything you'd like to see.
Thank you, for both your time and continued support for this wonderful app.
I am experiencing the same issue as above
"(Edit: Upon further observation, it seems that the random app in question is often among the last to have been manually woken/used before entering the next deep sleep period, in case it helps.)"
this is definitely the case with me. I am quite certain the apps are not actually being woken up every 30 minute period. It feels like greenify is running the command needlessly.
I am in the beta channel and using root mode
@oasisfeng I also experiencing this issue. On BetterBatteryStats, I have partial wakelocks every 30 minutes and it seemed greenify is causing this.
I'm on XtreStoLite 2.1 - LP TouchWiz based ROM running Greenify 2.6.1 on Root mode with Donation Package
It's not an issue, but a protective design, to ensure the apps occasionally woken during the idle period being put back to hibernation again.
First of all, this is not a wake-up periodic timer, that means if your device fell in sleep for more than half a hour, it will never wake up the CPU until other apps wake it. So, it consumes little battery juice, which you could hardly perceive.
I'm planning to add latest wake-up information for all apps including the hibernated ones.
Hi, guys, do you use Tasker for periodic hibernation/wakeup task with Greenify?
I dont. I have tasker installed, but havent set it up to do anything yet. Cheers
oasisfeng said:
Hi, guys, do you use Tasker for periodic hibernation/wakeup task with Greenify?
Click to expand...
Click to collapse
Thanks for your replies! In my case, I haven't been using any hibernation/wake-up tasks (although Tasker is installed).
Regarding your first response, I'm not entirely sure what you mean about the protective design. Apologies if there's any confusion, but if you're suggesting that Greenify simply ensures that woken apps remain hibernated, the puzzling thing is that these particular apps will not wake at all when auto-hibernation is disabled.
Auto hibernation/Manual hibernation
@oasisfeng
I have the same issue as the others above but noted your explanation for the same. I am running stock Lollipop 5.1 in my rooted Nexus 4 with Greenify 2.6.2 beta 3 running in Root mode with donation features.
One more issue which is more serious (in my opinion), is auto hibernation and manual hibernation. Some system apps like Google Services Framework and Google Play Services do not get autohibernated occasionally. Likewise even if the manual shortcut Hibernate+lockscreen is used, these remain running sometimes, even after half an hour of sleep. However, there is no noticeable impact on battery. (I have brought the battery loss down to 0.3 to 0.7% per hour while sleeping, from 6 to 7% without Greenify. Thanks for that) As the others reported, SU logs indicate that every half hour Greenify hibernated these apps though they are present as running continuously when Greenify is opened. My suspicion is that though they are actually hibernated, Greenify does not correctly reflect the status.
This is more of a report than a complaint to keep you and others informed.
tnsmani said:
@oasisfeng
I have the same issue as the others above but noted your explanation for the same. I am running stock Lollipop 5.1 in my rooted Nexus 4 with Greenify 2.6.2 beta 3 running in Root mode with donation features.
One more issue which is more serious (in my opinion), is auto hibernation and manual hibernation. Some system apps like Google Services Framework and Google Play Services do not get autohibernated occasionally. Likewise even if the manual shortcut Hibernate+lockscreen is used, these remain running sometimes, even after half an hour of sleep. However, there is no noticeable impact on battery. (I have brought the battery loss down to 0.3 to 0.7% per hour while sleeping, from 6 to 7% without Greenify. Thanks for that) As the others reported, SU logs indicate that every half hour Greenify hibernated these apps though they are present as running continuously when Greenify is opened. My suspicion is that though they are actually hibernated, Greenify does not correctly reflect the status.
This is more of a report than a complaint to keep you and others informed.
Click to expand...
Click to collapse
jacknicholson said:
Thanks for your replies! In my case, I haven't been using any hibernation/wake-up tasks (although Tasker is installed).
Regarding your first response, I'm not entirely sure what you mean about the protective design. Apologies if there's any confusion, but if you're suggesting that Greenify simply ensures that woken apps remain hibernated, the puzzling thing is that these particular apps will not wake at all when auto-hibernation is disabled.
Click to expand...
Click to collapse
jacknicholson said:
@oasisfeng Disclaimer: Apologies in advance -- this is a long one!
I've been experiencing an odd issue, as of late, running the 2.6.1 stable on my Nexus 5 (LP 5.1 / LMY47I, Cataclysm ROM). I'm using Root Mode (donation version), without Xposed.
This issue is slightly difficult to explain. By observing my SuperSU logs, I've noticed that a seemingly random and previously Greenified app will be continually hibernated every 30 minutes or so, each time my device goes idle for a prolonged period (such as while I'm working, or asleep). Curiously, the apps in question will change during each idle period, largely excluding the possibility that this is simply the case of a rogue app. The various apps are usually quite innocuous, and never known to (randomly) wake while my device is in use -- last night's was MX Player, for instance.
(Edit: Upon further observation, it seems that the random app in question is often among the last to have been manually woken/used before entering the next deep sleep period, in case it helps.)
Unfortunately, I've yet to successfully return to my device in time to catch any possible wake-up paths. I do question, however, if the apps are actually being woken in the first place (as opposed to Greenify simply "re-hibernating" apps that are already sleeping), as the issue will seemingly disappear entirely when auto-hibernation is disabled -- according to my SU logs, at least.
The only potential user-side cause that I can think of is that I had previously cut-off the Google Play Services wake-up path for Maps (neither G.P.S. nor any important system apps were ever actually hibernated). I've since re-attached the wake-up path, and de-Greenified Maps. Although that's probably unrelated, it's pretty much the "riskiest" thing I've done with Greenify on this device. I normally just keep a number of seldomly used user apps hibernated, and don't have any known offenders (like Facebook) on my device.
I've since removed and re-added each of my hibernated apps, as well as reinstalled Greenify (and its donation package) several times. I should note, as well, that I have not experienced any noticeable battery drains. Unfortunately, I'm unable to confirm whether or not this occurred before updating to Greenify 2.6.1 stable -- I've simply only observed this behavior since the Play Store rollout.
I've attached an example screenshot of my SuperSU log (taken after a 7 hour idle period), just so you can better visualize the pattern (the actual content of each log is simply the usual force stop message). Apologies for not providing anything more helpful at this time; please let me know if there's anything you'd like to see.
Thank you, for both your time and continued support for this wonderful app.
Click to expand...
Click to collapse
I have a similar problem
yesterday I was using Wakelock Detector and I found out this:
Today I flashed a new Rom and all I did was configuration stuff and install some basic apps such as facebook, twitter etc. and greenify (not xposed module) greenifying NOT system apps
After 3h it caused screen wakelock during 7 minutes
BTW I amb on stock lollipop 30b
Is greenify incompatible? is supersu broken?
Boopie11 said:
I have a similar problem
yesterday I was using Wakelock Detector and I found out this:
Click to expand...
Click to collapse
First, learn some etiquette. Quote only what is relevant or simply say that you have the same issue as others. Don't go about quoting multiple full posts.
Second, you have opened a separate thread for the same issue. So what is the point of posting the same here?
Third, though your attachments are not visible, your description gives the impression that your issue has no relevance to the posts you have quoted.
The issue appears to have been resolved with version 2.6.2. As always, my thanks go to @oasisfeng -- although if I may ask, did you manage to find the source of the issue, or is this a coincidence?
jacknicholson said:
The issue appears to have been resolved with version 2.6.2. As always, my thanks go to @oasisfeng -- although if I may ask, did you manage to find the source of the issue, or is this a coincidence?
Click to expand...
Click to collapse
Yes, your report is very precious for me to analyze this issue. It was fixed in an earlier beta version before the final release of version 2.6.2. Thanks very much!
oasisfeng said:
Yes, your report is very precious for me to analyze this issue. It was fixed in an earlier beta version before the final release of version 2.6.2. Thanks very much!
Click to expand...
Click to collapse
I was wondering whether Greenify had stopped working, after installing 2.6.2.
Now I know the reason. So this is why I don't see those repeat hibernations.
Thank you, @oasisfeng!
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
hello to all. my configuration is fritten in my firm.
i noticed some differences between standard and shallow hibernation. i tested telegram and whatsapp on standard... and of course if a person send me a text the apps are NOT WAKING UP till i open them. perfect!
but on shallow hibernation i notice they are waked up and i receive the message, ok maybe not instantly but it could take about 15/30 seconds to receive them.
is it a NORMAL BEHAVIOUR? maybe yes......
this is what i read in the settingsShallow-hibernated apps will be woken for a brief time periodically in hours and immediately upon HIGH priority GCM push (only if GCM priority is implemented by app developer). They will also keep awake during charging
mmmhh... ok so it should be something similar to the xposed feature ( that require donation package) called "GCM push for greenified apps" ???
i am on nougat and i don't have xposed, but i have the donation package......but i thought that without xposed i would never had the possibiliti to greenify an app ....MANTAINING the possibility to receive push messages... just because for this feature it's needed xposed!!!
so at the end..... could i consider the shallow hibernation an alternative "GCM push for greenified apps" for the persons that can't have xposed? i am just a fraid that this kind of hibernation is not so much effective in terms of battery life, respecting the old/standard one...... but i wait for some users more skilled than me that could explain and reassure me....:laugh:
realista87 said:
hello to all. my configuration is fritten in my firm.
i noticed some differences between standard and shallow hibernation. i tested telegram and whatsapp on standard... and of course if a person send me a text the apps are NOT WAKING UP till i open them. perfect!
but on shallow hibernation i notice they are waked up and i receive the message, ok maybe not instantly but it could take about 15/30 seconds to receive them.
is it a NORMAL BEHAVIOUR? maybe yes......
this is what i read in the settings
Shallow-hibernated apps will be woken for a brief time periodically in hours and immediately upon HIGH priority GCM push (only if GCM priority is implemented by app developer). They will also keep awake during charging
mmmhh... ok so it should be something similar to the xposed feature ( that require donation package) called "GCM push for greenified apps" ???
i am on nougat and i don't have xposed, but i have the donation package......but i thought that without xposed i would never had the possibiliti to greenify an app ....MANTAINING the possibility to receive push messages... just because for this feature it's needed xposed!!!
so at the end..... could i consider the shallow hibernation an alternative "GCM push for greenified apps" for the persons that can't have xposed? i am just a fraid that this kind of hibernation is not so much effective in terms of battery life, respecting the old/standard one...... but i wait for some users more skilled than me that could explain and reassure me....:laugh:
Click to expand...
Click to collapse
- high priority GCM push notifications will display immediately with shallow hibernation or w/Xposed option (Android 6.x and below)
- standard notifications will be delayed until next maintenance window with shallow hibernation; Xposed variant will deliver those immediately
- app developer controls notification priority
- personally I would stick with standard doze/hibernation and call it a day
sorry but i didn't understand your last point. what does it mean "call it a day"?? sorry i'm not a native english....
But seems that you don't rely so much on the new shallow mode.... is there a more precise technical motivation that you could bring on the discussion table... to let me understand why do you prefer the old hibernation method?
realista87 said:
sorry but i didn't understand your last point. what does it mean "call it a day"?? sorry i'm not a native english....
But seems that you don't rely so much on the new shallow mode.... is there a more precise technical motivation that you could bring on the discussion table... to let me understand why do you prefer the old hibernation method?
Click to expand...
Click to collapse
- expression "call it a day" simply means stop further activity (the job is done)
- I do not use shallow/aggressive hibernation as the benefits do not outweigh the side effects; all my devices sleep well with standard doze/hibernation
ok... in fact i notice that with shallow method some apps still continue to wake up the phone, i see the wakelocks on wakelock detector app and betterbatterystats. so at the end it's not clear if shallow hibernation is a REAL OR NOT hibernation... because these 2 apps that wake up, antutu and MYwind ( an app to check balance and options of my operator) are NOT setted to receive any notification... so i don't understand why they still uses alarms.
BUT........ i will continue to use shallow thinking and hoping that i could gain more battery life greenifying MORE APPS.... also the messaging ones. in fact i greenified telegram, WA, alsmost everything and i stil continue to receive notifications.
what i'm saying is that maybe standard hibernation is STRONGER, but it needs to be whitelisted with at least messaging apps and other apps used on average, and my fear is that the benefit gained from the TRUE "old" hibernation could be not surpassed by the smallest NOT whitelisted apps that the shallow ones permits you to set....without break any notification (sorry i'm not a native english, it's my best)
realista87 said:
ok... in fact i notice that with shallow method some apps still continue to wake up the phone, i see the wakelocks on wakelock detector app and betterbatterystats. so at the end it's not clear if shallow hibernation is a REAL OR NOT hibernation... because these 2 apps that wake up, antutu and MYwind ( an app to check balance and options of my operator) are NOT setted to receive any notification... so i don't understand why they still uses alarms.
BUT........ i will continue to use shallow thinking and hoping that i could gain more battery life greenifying MORE APPS.... also the messaging ones. in fact i greenified telegram, WA, alsmost everything and i stil continue to receive notifications.
what i'm saying is that maybe standard hibernation is STRONGER, but it needs to be whitelisted with at least messaging apps and other apps used on average, and my fear is that the benefit gained from the TRUE "old" hibernation could be not surpassed by the smallest NOT whitelisted apps that the shallow ones permits you to set....without break any notification (sorry i'm not a native english, it's my best)
Click to expand...
Click to collapse
I understand what you are saying. Best path is to test both modes to determine which best meets your needs. Good luck.
Hello,
So I was using Greenify and hibernate Facebook app, but with the last week or so. My facebook app sometime doeasnt load, showing "cant connect right now" and I tried to search google. most issues I've found are Greenify's issue on facebook, especially when facebook got hibernated and woke up for a long time. I had to restart my device to getting facebook working again, ridiculous.
so any workaround on this? As we know that facebook app is the worst battery sucker.
I'm using Resurrection Remix 7.1.2 on Mi 5s Plus, rooted and privileged
Thanks.
Best option is to use one of the 'lite' Facebook alternatives which preserve functionality without the corresponding hit on battery life and data consumption. Also make sure non of Greenify's alternative doze/hibernation modes are enabled (aggressive/deep/shallow) as they are known to create side effects with few, if any, corresponding benefits on Android 6 and above. Good luck.
I use greenify in shallow hibernation mode and Facebook works fine and doesn't eat much battery.
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.