After a vast underlying rebuilding in the past months, Greenify is now running on a powerful new engine. Its potential is yet to be fully developed, but at the stage today, the benefit is already notable.
The experimental feature "Wake-up Tracker and Cutoff" now works without Xposed framework (and activated always). Consider its importance in Greenify, this will answer the most asked question "Why the greenified app is woken again?" for much more users.
Since rovo89 finally released the alpha version of its magic Xposed framework on Android 5.0. Greenify is proud to bring all its Xposed-based features to Android 5.0 users. Enjoy the full power of Greenify~ :fingers-crossed:
Although I have adopted more and more features to users without Xposed, the power of Xposed framework is still hard to replace. As promised and practiced before, popular experimental features will graduate from donation package. At this time, they're:
> Timer Coalescing (more details explained here: https://plus.google.com/112105199234363320140/posts/iYMqRMjXKLb)
> Telephony Wake-up: Allow telephony events (such as SMS and phone call) to wake up hibernated apps.
Now it's time for a gift to you supporters with donation package. Let me introduce the new experimental feature "Deep Hibernation"!
Tired of apps waking up each other just for trivial functions, but slow down the whole phone? It comes to the rescue. Activate this feature and enjoy a much more peaceful hibernation. Be aware, this also cut-off most bonds between apps, as if they couldn't see each other on your phone. As always, apps restore to full functionality (including its providing bonds) once awake.
Even without donation package, you could still reach similar effects with the "Wake-up Cutoff" feature without Xposed for select apps (on Android 4.3+ at present, and will be broaden to older Android versions in future release).
BE WARNED, THIS IS AN EARLY BETA VERSION, WHICH MAY (AND LIKELY) CONTAIN BUGS AND STABILITY ISSUES. Please help me improve it by reporting back in this thread.
Known issues:
Some wake-up paths are still not yet covered in the new "Wake-up Tracker & Cutoff" and "Deep Hibernation" feature, including "content provider" (a background data sharing mechanism in Android) and Location update (will be covered in future beta).
Click to expand...
Click to collapse
[Download recent beta versions]
Sorry to be inactive on XDA for a while during the hard development of new version of Greenify and preparing the Chinese new year (similar to Christmas in western world). With the release of first beta, I'm listening to all your feedback here now.
Installed I got some problem receiving push for Whatsapp
---------- Post added at 10:20 AM ---------- Previous post was at 10:20 AM ----------
With xposed and all feature enabled
---------- Post added at 11:20 AM ---------- Previous post was at 10:20 AM ----------
And also other apps
I can confirm that. Just tried with my mothers phone. No notifications from fb messenger nor viber.
Hot reboot, when GCM push is received (only when "GCM push for greenified apps" is checked). Same is the case with earlier stable version 2.5.2
Code:
Process: system_server
Build: samsung/t03gxx/t03g:4.4.2/KOT49H/N7100XXUFNI1:user/release-keys
java.lang.RuntimeException: Error receiving broadcast Intent { act=android.intent.action.BOOT_COMPLETED flg=0x4000030 pkg=com.whatsapp } in [email protected]
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:782)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:146)
at com.android.server.ServerThread.initAndLoop(SystemServer.java:2044)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at com.android.server.ServerThread.initAndLoop(Native Method)
at com.android.server.SystemServer.main(SystemServer.java:2215)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at com.android.server.SystemServer.main(Native Method)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.android.server.content.SyncManager$SyncHandler.onBootCompleted(SyncManager.java:1847)
at com.android.server.content.SyncManager$2.onReceive(SyncManager.java:231)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:772)
... 17 more
amit.bagaria said:
Hot reboot, when GCM push is received (only when "GCM push for greenified apps" is checked). Same is the case with earlier stable version 2.5.2
Code:
Process: system_server
Build: samsung/t03gxx/t03g:4.4.2/KOT49H/N7100XXUFNI1:user/release-keys
java.lang.RuntimeException: Error receiving broadcast Intent { act=android.intent.action.BOOT_COMPLETED flg=0x4000030 pkg=com.whatsapp } in [email protected]
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:782)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:146)
at com.android.server.ServerThread.initAndLoop(SystemServer.java:2044)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at com.android.server.ServerThread.initAndLoop(Native Method)
at com.android.server.SystemServer.main(SystemServer.java:2215)
at de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative(Native Method)
at de.robv.android.xposed.XposedBridge.handleHookedMethod(XposedBridge.java:631)
at com.android.server.SystemServer.main(Native Method)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.NullPointerException
at com.android.server.content.SyncManager$SyncHandler.onBootCompleted(SyncManager.java:1847)
at com.android.server.content.SyncManager$2.onReceive(SyncManager.java:231)
at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:772)
... 17 more
Click to expand...
Click to collapse
I'm afraid it's not the relevant exception logcat. I'm looking into the GCM issue right now and doing more tests.
UPDATE: Issue confirmed. Working on a fix.
UPDATE2: The GCM Wake-up is conflicting with Deep Hibernation in current implementation. Please try disabling Deep Hibernation to see if it solves this issue.
oasisfeng said:
I'm afraid it's not the relevant exception logcat. I'm looking into the GCM issue right now and doing more tests.
UPDATE: Issue confirmed. Working on a fix.
Click to expand...
Click to collapse
Wonderful
Just installed on my phone. I don't use GCM. Will report any other issues.
Thanks for Deep Hibernation! :highfive:
oasisfeng said:
I'm afraid it's not the relevant exception logcat. I'm looking into the GCM issue right now and doing more tests.
UPDATE: Issue confirmed. Working on a fix.
UPDATE2: The GCM Wake-up is conflicting with Deep Hibernation in current implementation. Please try disabling Deep Hibernation to see if it solves this issue.
Click to expand...
Click to collapse
Tried turning off 'Deep Hibernation' and enabling 'GCM wakeup'. Still the same issue. Hot reboot with same error.
Let me know how can I provide you relevant logs. I don't see any problems in the xposed log.
Just to clarify, this is the same problem I am facing with the current stable version 2.5.2. So, I am not sure if this could be related to your new feature 'Deep Hibernate'.
amit.bagaria said:
Tried turning off 'Deep Hibernation' and enabling 'GCM wakeup'. Still the same issue. Hot reboot with same error.
Let me know how can I provide you relevant logs. I don't see any problems in the xposed log.
Just to clarify, this is the same problem I am facing with the current stable version 2.5.2. So, I am not sure if this could be related to your new feature 'Deep Hibernate'.
Click to expand...
Click to collapse
Please keep the phone in peach for a while and trigger a GCM push, capture the full logcat around the moment. I'd suggest "AutoRemote" for easy GCM testing.
Meanwhile, I could reproduce the issue (may not be the same one) in my test device. Need some more time to work out a fix.
https://plus.google.com/101845111039183184890/posts/7HaE2zFBw1V
Here is a video with my issue....
Sent from my bacon!!!!!
oasisfeng said:
Please keep the phone in peach for a while and trigger a GCM push, capture the full logcat around the moment. I'd suggest "AutoRemote" for easy GCM testing.
Meanwhile, I could reproduce the issue (may not be the same one) in my test device. Need some more time to work out a fix.
Click to expand...
Click to collapse
Took some time to get setup for AutoRemote. But finally, here are the logs when the device hot reboots after the GCM push arrives.
http://pastebin.com/BSJjQ6rz
Wake up cut off issue
@oasisfeng
Running the beta on my phone. Greenifying sys apps enabled. The wake up cut off works differently now.
1. It does not show the particular app which is waking up another. It simply shows the scissors icon. If the scissors icon is touched, it cuts off all the wake up paths of the app and not the particular one which woke it up at that instant.
2. Likewise, while re-attaching the wake up paths, no options are given to re-attach a particular path. It re-attaches every wake up path.
I don't know if this is the intended behavior but on all earlier versions, I had both these options.
3. The scissors icon, though shown, doesn't work when touched for some apps (for instance for Download Manager and GSF - see attached screen shot)
I'm missing Wake-up Tracker and Cutoff option under experimental features. I have donation package also.
Even with Deep Hibernation unchecked, I still cannot get GCM to work under normal hibernation.
NickosD said:
https://plus.google.com/101845111039183184890/posts/7HaE2zFBw1V
Here is a video with my issue....
Sent from my bacon!!!!!
Click to expand...
Click to collapse
tnsmani said:
@oasisfeng
Running the beta on my phone. Greenifying sys apps enabled. The wake up cut off works differently now.
1. It does not show the particular app which is waking up another. It simply shows the scissors icon. If the scissors icon is touched, it cuts off all the wake up paths of the app and not the particular one which woke it up at that instant.
2. Likewise, while re-attaching the wake up paths, no options are given to re-attach a particular path. It re-attaches every wake up path.
I don't know if this is the intended behavior but on all earlier versions, I had both these options.
3. The scissors icon, though shown, doesn't work when touched for some apps (for instance for Download Manager and GSF - see attached screen shot)
Click to expand...
Click to collapse
Thanks for your detailed video and screenshot.
1. In some cases, like "content provided", the current implementation could not yet analyze the wake-up source. And it is also unable to cut-off these types at present. I'm still seeking for a proper solution for it under the new engine.
2. The new cut-off and re-attach feature work on a whole per-app basis, to reduce the complexity many average users were facing with the old one. Please provide your feedback if you think this is not an ideal way.
3. It's mainly due to the reason mentioned in above 1. The case of Google+ seems different, I'll look into it and further test it out.
BTW, it's not advised to greenify core Android system components, like Calendar Storage, Download Manager, Media Storage. They're not causing memory or battery issues on most devices. It's also not recommended to greenify Google Play services, since it may break many features provided by Google ,like GCM push and Location service.
christiano88 said:
Even with Deep Hibernation unchecked, I still cannot get GCM to work under normal hibernation.
Click to expand...
Click to collapse
Do you running Android 5.0 on Nexus 4?
oasisfeng said:
Do you running Android 5.0 on Nexus 4?
Click to expand...
Click to collapse
Yes, 5.0.2 to be exact.
213182 said:
I'm missing Wake-up Tracker and Cutoff option under experimental features. I have donation package also.
Click to expand...
Click to collapse
It's now working without Xposed and enabled always, running as a background service together with auto hibernation service.
oasisfeng said:
Thanks for your detailed video and screenshot............
BTW, it's not advised to greenify core Android system components, like Calendar Storage, Download Manager, Media Storage. They're not causing memory or battery issues on most devices. It's also not recommended to greenify Google Play services, since it may break many features provided by Google ,like GCM push and Location service.
Click to expand...
Click to collapse
The last para of your reply - is why I am asking for the cut off feature to show the actual path - so that we can decide whether I need to cut it off and whether it is safe.
I don't greenify Download Manager or GSF. I mentioned them as examples.
But I do greenify Play Services depending on which app woke it up. In the present scenario, that option is not available and greenifying Play Store will make me lose all of its functionality. There are other apps also in this category.
So my vote is for having the earlier functionality of the wake up cut off feature, provided it is possible and will not cause too much effort on your part. I can manage with the earlier version, no problem.
The only reason I updated to the beta is for the Deep Hibernation since I don't intend to switch to Lollipop and am happy with the present setup with Gravity Box, Greenify, Amplify etc.
Related
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?
@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!
This is the first beta version of Greenify 2.7. This major version is aimed to improve the over-all user experience in every aspect (if possible).
Beta 8
Fixed the detection for background active app on Android 5.1.1_r9 and 6.0, with new implementation.
Fixed crash on Android 4.0.x.
Simplified the confusing state reason of postponed hibernation.
Beta 7
Fixed crash during auto-hibernation in non-root mode.
Beta 6
Due to a permission change in the newest revision of Android 5.1.1 and 6.0, Greenify has to use the usage stats permission to detect the foreground app and avoid hibernating it. Unfortunately, this new implementation could no longer detect the active background apps (such as music player).
Improved compatibility with Android 6.0.
FIX: Xposed feature settings lost issue on arm64.
Beta 5
Foreground app no longer hibernates even if "state always ignored" is checked.
Reduced the impacts of wake-up cut-off.
FIX: Native processes cleaning.
FIX: Wake-up action in Tasker plug-in on Android 5.x.
FIX: No longer list disabled apps.
Beta 4
Fixed the reboot issue in root mode if core system app is greenfied.
Beta 3
Greenify now cleans up native processes after hibernation, to prevent self-reviving.
Fixed root mode on Android 4.0 & 4.1.
Fixed non-root mode on Android M.
No longer pause auto-hibernation when charging.
Beta 2
Fixed the manual hibernation not working issue when charging. (introduced in beta 1)
Beta 1
Dim the screen when performing auto-hibernation on non-root device.
Auto-hibernation will pause when external power is connected.
"Hibernate and Lock Screen" shortcut does not require device-admin privilege activated, and is now compatible with Smart Lock on Android Lollipop & M. (root-only)
Experimental support for Android M Developer Preview, with new "Shallow Hibernation" - application context and push notification are all preserved in hibernation.
Click to expand...
Click to collapse
About Android M support (experimental)
Since Android M is still in early developer preview stage, anything could change before the final version is out. So is the experimental support in Greenify.
Greenify now takes advantage of App Standby feature in Android M and combine it with the efforts of traditional implementation to create a new "Shallow Hibernation" state for greenified apps. In this state, app won't lose the context before being switched to the background and could also receive GCM push message in hibernation.
Known issues
The "... Lock Screen" shortcut with new implementation is reacting slower than before in some lower end device, due to slow root invocation.
Get beta versions
Opt-in to beta channel or download the apk file.
Please apk file Greenify v2.7 beta 1 ..
http://www13.zippyshare.com/v/HAwp78U6/file.html
Any changes for LP? or for M only?
aeonix_05 said:
Any changes for LP? or for M only?
Click to expand...
Click to collapse
Only the first one is for Android M.
cenzo1996 said:
Please apk file Greenify v2.7 beta 1 ..
Click to expand...
Click to collapse
Link is now provided in OP.
@oasisfeng Thanks for the update. Working fine but the problem that the notifications don't get delivered unless the screen is turned on manually remains on LP. Greenify shows as push received "x" minutes ago but no notification sound or anything related when phone screen is off.
nice
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
gALEXyS4 said:
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
Click to expand...
Click to collapse
Yup, I have that problem too. The toast says hibernated but they actually don't get hibernated.
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
Click to expand...
Click to collapse
+1 for Samsung Galaxy S6 android 5.0.2 root
gALEXyS4 said:
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
Click to expand...
Click to collapse
+1
Sent from my SM-G900F using Tapatalk
gALEXyS4 said:
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
Click to expand...
Click to collapse
Same here. S4 with S6 featured ROM.
Gesendet von meinem Nexus 7 WiFi mit Tapatalk
Sony Z1c LP 5.0.2 too . I am back on the last version now.
Gesendet von meinem D5503
ottomanrage said:
@oasisfeng Thanks for the update. Working fine but the problem that the notifications don't get delivered unless the screen is turned on manually remains on LP. Greenify shows as push received "x" minutes ago but no notification sound or anything related when phone screen is off.
Click to expand...
Click to collapse
I'm sorry, I still can't figure out the cause of that issue yet. It seems like only affect some apps in some situations. This combination is not clear in any form.
gALEXyS4 said:
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
Click to expand...
Click to collapse
Which Android version and device model? What working mode?
oasisfeng said:
I'm sorry, I still can't figure out the cause of that issue yet. It seems like only affect some apps in some situations. This combination is not clear in any form.
Click to expand...
Click to collapse
Thanks for the reply. For me it's mostly in whatsapp and viber. I have the logs for the GCM push if you need. And it happens everytime. Basically in all situations.
And as for the latest beta update, I have an I9300 running 5.1.1 with boost mode (xposed).
oasisfeng said:
Which Android version and device model? What working mode?
Click to expand...
Click to collapse
android 5.0.2 SAMSUNG GALAXY S6
ottomanrage said:
Thanks for the reply. For me it's mostly in whatsapp and viber. I have the logs for the GCM push if you need. And it happens everytime. Basically in all situations.
And as for the latest beta update, I have an I9300 running 5.1.1 with boost mode (xposed).
Click to expand...
Click to collapse
I have collected many logs in the past months. But both Google Play services and these apps are closed source. Logs are not enough to figure out why they can't post notifications even if push message was received.
Several attempts have been made trying to fix the issue, but still no luck yet.
Maybe they are not prepared to receive push message in hibernation state.
gALEXyS4 said:
I have a slight problem with the newest version: Any app that happens to be awake when I open Greenify just stays awake. At the moment Google App, Google Play Store, ACalendar Plus and Weather don't wanna get closed, they just stay persistently. If I press to hibernate them, I get a toast message that they're hibernated, but they are not... Now I don't know whether it's an error of function or of displaying
Click to expand...
Click to collapse
Have you connected external power to the device? If so, that's because Greenify will not perform auto-hibernation during charging since this version. The incorrect prompt information is the known issue I've listed in the OP. I'll add more clear prompt for this.
all ok with hypernate here
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.