Shared publicly  - 
FAQ for Greenify users

Q: Which apps should I greenify?

A: In short, don't hibernate all (or most of) your apps. App Analyzer of Greenify only shows apps which have POTENTIAL impact on battery consumption or device performance (click the icon "i" of each section for more details), it doesn't mean they actually have. You are suggested to only hibernate those you seldom use, plus the apps you are sure have negative impacts, most probably identified by the "Settings - Battery" of your device, or 3rd-party diagnose apps, such as Wakelock Detector and BetterBatteryStats (for power users).

[Background Knowledge]

"Running in background" does not mean it has definite impact on battery consumption or device performance. Experienced developers can also reduce the memory footprint of background service as low as several megabytes, which is negligible in most middle-to-high end devices with 1~2G RAM.

"May slow down the device" also does not mean it has definite impact on device smoothness. Android caches the process of apps regularly run, thus significantly reduced the cost of launching it in background.

Q: Why not support Android 2.x?

A: Sorry, Android 2.x lacks a core mechanism that Greenify mainly depends on. It's impossible to achieve equivalent functionality in Android 2.x. If possible, please consider upgrading your device to Android 4.x (CyanogenMod is a good choice if no official 4.x upgrade). If you are out of luck in upgrading, you can also try one of the alternative tools I mentioned in the app description of Greenify on Play store, such as "App Quarantine" (for most users) and "Autostarts" (for super users).

Q: It seems that automatic hibernation is not working.

A: That is most probably caused by your root management tool. Because some root management tool require re-authorization after app update, you may have missed the confirmation dialog, since Greenify requests root privilige when screen is off.

If you are using SuperUser and confirm root privilege is granted to Greenify, there's a high chance SuperUser is not working correctly for background root privilege requests on your device. Most user with this issue got it solved by installing SuperSU ( ) instead of SuperUser. You are suggested to have a try.

Q: I want to greenify system apps!

A: First of all, it's not safe to greenify system apps, because system apps are responsible for core functionalities of your device and they are usually essential components for other apps. Android OS also protects system apps with far more privileges than normal apps, that stops Greenify from correctly putting them into hibernation.

Q: I still want to greenify system apps, and I can accept any bad consequence!

A: If so, you can try converting non-critical system apps (such as apps bundled by carriers) into normal apps with the help of Titanium Backup or similar tools. Reboot your device, then greenify it as normal. Or you can try the experimental feature in donation version ( to directly greenify system apps.

Q: Degreenified apps (or greenified apps with donation package) still got no push notification!

A: Unlike iOS's pure text push messages, push notification in Android involves background task. So hibernation does stop the push notification from working. Even after you degreenfied these apps (removed from list), you may still need to reactivate the push registration in them.

Different apps have different procedures, some will automatically re-activate it, some with (push) notification settings can be easily turned off and on again, and some may need you to logout and login again.

An experimental feature "GCM push for greenified apps" (in donation package) is aimed to enable push notification for greenified apps if they use Google Cloud Messaging for push notification (a little GCM icon will show up for GCM-enabled app in App Analyzer). This can be extremely useful for some apps if your usage pattern mainly depends on the push notification from them, but don't want the overhead of background activities.

You may still need to reactivate the push registration as mentioned above if the push notification stops working occasionally.

Q: Some of my greenified apps (e.g. Google Maps) seems not hibernating.

A: In short, don't worry about frequently awake apps. It will still hibernate in minutes after screen goes off, thus hardly add observable battery consumption. Use battery statistics in settings or "BetterBatteryStats" to confirm that.

While most greenified apps will stay in hibernation quietly, some apps do break hibernation, due to being waken up by others. Some known cases include enabled account sync, backup agent, and explicit launch by other app.

You can leave your app synchronization setting as usual, since Greenify will automatically put the app which performed synchronization recently back into hibernation. For backup agents, Greenify will NOT disable them. As backup usually does not perform often, they are thus unlikely to be waken up often.

Google+ and Facebook are typical example of explicit launch by other app. 3rd-party apps with Google/Facebook login wake up Google+/Facebook app when they need to use the login information.

Since Greenify is designed to not break any explicit usage of greenified apps, these behaviors are considered "normal", and will NOT be "fixed". To clear out your unease, Greenify will still put them into hibernation when standby to protect your battery consumption. But if you are not a fan of Google Now, it is suggested to greenify both Google Search and Maps, thus you'll get a steady hibernation for Google Maps. (converting from system apps into user apps may be needed for greenifying Google Search or Maps)

If you believe what you face is an abnormal case of not hibernating, and need further help. Please report back here:

Q: Could you add an option to allow for a scheduled hibernation every x minutes?

A: I have been considering this option, but at last, I found it a task "too complicated to satisfy all". Some users need the option "night mode" which means scheduling on specific time, some users need the option "every x minutes" which means scheduling on fixed periods, and even worse when some users asked for separate schedules for each greenified app. Still, it is not the end, I received a mail asking for hibernation scheduling by network state.

Then, I realised that if the scheduling feature is implemented, not only this feature itself will be a bottomless pit, but Greenify will also become a complicate monster that most users will get stuck in tuning those options. It is obviously not my intention.

So, let's just leave the complication to professional tools like Tasker and Llama. They handle scheduling far better than I could achieve. Thus Greenify could focus on its core functionality and evolves a bit quicker, since I don't have much time developing this app.
Oasis Feng's profile photoKenneth Nip's profile photoDheepak G's profile photozac feng's profile photo
+Deepesh Vesuwala It's hard to tell whether Greenify is compatible with your custom ROM. It should be compatible with most of them.


Beta Channel  - 
Beta 2 is rolling out to fix the manual hibernation issue when charging introduced in beta 1.

PS. The auto-hibernation is paused when charging since beta 1. It's the expected behavior, but unfortunately created a bug causing manual hibernation is ignored too in beta 1.
Xuefer H's profile photoGreenify's profile photo       abbas  eid's profile photo
+Xuefer H What detailed problem are you experiencing? This logcat seems OK.
Add a comment...


Shared publicly  - 
The All New Wake-up Tracker (for Android 4.4+)

In the recently released Greenify v2.6.1, a new engine is implemented to support the core functionality of Greenify for broader users, without Xposed and even without root.

The all new "Wake-up Tracker" is the first fruit. It has many advantages compared to its predecessor.

No Xposed required. Wake-up Tracker now works on all rooted devices and even partially (only "why" but no "who") on non-root devices (*1).

Easier Cut-off. No more obscure technical names, no more repeated cutting, only one touch to cut all wake-up paths.

Smarter Cut-off. Unlike the predecessor and most other auto-start manager tools, the all new "Cut-off" implementation only affects the outer side of the app, but not the inner side. That means, the app itself can still use all its components as if nothing is changed, despite cut-off by Greenify, so most functions inside the app are not affected at all.

More efficient and steady. In the new implementation, Wake-up Tracker and Cut-off is more efficient and steady. Apps can no-longer bypass Greenify and re-attach its wake-up paths by themselves.

Precise and Directional (incoming). With the power of the new engine, cut-off can be placed more precise, to cut off just one wake-up path among shared component. And for Android 5.0+, you could even place "directional cut-off", to prevent an app from waking up by your specified ones.

The new chapter of Greenify is just beginning, stay tuned! Donation is always welcome to accelerate the evolution down the road.

^1 - To enable Wake-up Tracker (without Cut-off) on non-root device, connect your device with computer/laptop via USB cable, enable "developer options" - "USB debugging" on your device (, install the necessary driver and ADB tool either from Android SDK or standalone package (, then type this command in shell/command prompt:
adb shell pm grant com.oasisfeng.greenify android.permission.READ_LOGS
Xuefer H's profile photoGreenify's profile photoChris R.'s profile photoCristian zamorano's profile photo
+Greenify when I check to see why battery is going so fast it continues to be onedrive at better than 20 percent. I go back to Greenify and it is out of hibernation and pending again 
Add a comment...


Bug Reports  - 
Toubleshooting Guide for GCM Wake-up

GCM wake-up is considered to be one of the most unreliable feature among the experimental features, thus still stuck as donation-only.
There're many factors behind a working GCM push, and trouble with either may lead to the failure of the whole expectation.

Let's discuss the common misunderstandings first.

1. The GCM indicator in App Analyzer does not necessarily mean the app uses GCM for the very notification feature you are expecting.

The GCM indicator only means GCM-related code is in that app's package. But the app may use GCM only for some of its notifications, or only in some criterias, or even the worse, does not use at all. To find out the actual usage of GCM within an app, read the trouble shooting instructions below.

2. Not all notifications are backed by GCM push.

Most instant messaging apps and some social apps use hybrid implementation with GCM and persistent connection (in a background service) to deliver more reliable instant notification, than relying on GCM only. In this case, some of the notifications you have received may not even come from a GCM push.

Hiberated apps lose its background service and thus fall-back to a GCM-only solution, effectively reducing the reliability of notification. If you noticed obvious delay or loss of some notifications after greenifying, it's probably the case.

3. The latency of GCM is affected by many factors, most notably how your carrier restrict the persistent connection.

The foundation implementation of GCM itself is also a persistent connection to Google's server. That means if your devices failed to keep this persistent connection, the latency of GCM is out of control. Carriers all over the world do restrict persistent connection to preserve their limited capability of signalling resources (not the bandwidth), by dropping connections idle for a while. GCM use periodic heartbeat packets to keep the persistent connection, but the default interval of 28 minutes for mobile network is far beyond the connection dropping threshold of some carriers (varying from minutes to hours), causing the persistent connection to drop frequently. As a result, GCM push may delay in minutes, or even half an hour.

There's also a few carriers in the world even block the connections to Google's server in most time(China for example), causing GCM totally out of work.


Now if you believe your app failed to wake up by a GCM push, follow these instructions to find the cause:

1. Open and monitor the logcat (Android log system), either on a USB-connected computer, or on your device with tool app like CatLog.

2. Set the filter to only include keyword (or tag) "GCM".

3. Let's trigger an expected GCM push (by sending an instant message from another device or so). You will soon read a line like this in logcat upon the arrival of GCM push:

I/GCM: GCM message com.joaomgcd.autoremote 0:1426418730738334%0#02db4288f9fd7ecd

This means Google Play services received the GCM message from Google's server and ready to deliver it to the corresponding app (indicated by the package name in the line, com.joaomgcd.autoremote in the example). If you cannot find this line in a reasonable time span, then it may be that app which lose the registion to GCM. Try logout and login your account, or clear the data of the app, or even uninstall and re-install it to restore its registration to GCM.

In all good situation, you should now receive the notification. If not, read on.

4. If the target app is hibernated before the arrive of GCM push and you have activated "GCM Wake-up" feature, then open Greenify ASAP (since it may hibernate again in a few minutes).

You will probably find that app is awake and listed in the "WILL HIBERNATE..." section. In this case, Greenify had managed to wake up the hibernated app and deliver the GCM message to it, but that app may failed to process it correctly and show a notification. This does happen to some apps which can't deal with GCM message upon wake-up. Try trigger another GCM push manually, if the notification shows up this time, that app falls into this category. It's hard to blame the developers for that, since they may not prepare for the arrival of GCM push when their background service is not running. So I'm still trying to figure out a better solution to make "GCM Wake-up" compatible with these apps.

5. If the app still stays hibernated, then the wake-up attempt might fail.

Back to the logcat, you probably read another line like this:

W/GCM-DMM﹕ broadcast intent callback: result=CANCELLED forIntent { pkg=com.joaomgcd.autoremote (has extras) }

It means the push is not delivered successfully. If you did activated "GCM Wake-up" but still read this line, then it may be Greenify's fault, except if you have disabled the notification of that app in system Settings - Apps - That App - Show notifications (unticked). Greenify checks this setting before trying to wake-up an app to deliver GCM push.

Note: As a reference, try "AutoRemoteLite" with its web interface to trigger GCM push.
zhang lei's profile photoPete Uelsen's profile photoDan Rozwood's profile photoPlum Li's profile photo
 ·  Translate
Add a comment...


Shared publicly  - 
A good article for this new beta!

A small correction in explanation: Timer Coalescing aligns all the periodic timers with the same interval from all apps, not just the greenified ones which generally benefits little from this feature since being hibernated.
Abhijeet Kumar's profile photoKhatib Sharbini's profile photodosigusti leonardi's profile photo
Do Greenify (donation package) work after I moved to sd card?
Add a comment...


Shared publicly  - 
Equally Affordable Donation

This principle was introduced from the early days of Greenify. To further ensure it, the prices of donation package were carefully reviewed and adjusted according to the Gross National Income (GNI) per capita at purchasing power parity (PPP) ( The new price is significantly dropped in many areas with low GNI.

In plain words, if I can buy a beer with that donation price in my country, then you could probably buy a beer too with its local donation price in your area. This does not equally mean I can buy a beer with your donation, actually the donation price in some under-developed areas could not even reach the minimum denomination here with currency exchange.

I don't care much about the income, but I do hope you could afford the donation if you like Greenify and wish to donate. It's all about the rights of equally affordable donation. :)

PS, Google Play only opens up local price setting for a limited number of countries, and it also limits the lowest price for paid apps, so it may not be possible to achieve the goal all over the world yet. If you find the price of donation package is significantly higher than other locally-priced apps, that might be my fault since it took me almost 2 hours to manually calculate and adjust the price one by one. Just leave a comment here, and I'll review that.
This is just a donation package which activates<b>some experimental feature...
Katrina Strub's profile photoGreenify's profile phototonyp's profile photoJonathan Auryn's profile photo
+Greenify​ yeah I guess that only works by taking a screenshot or something like that. 
Add a comment...
Have them in circles
6,085 people
Chris McMahon's profile photo
Rohit Ghosh's profile photo
Max Hähnke's profile photo
Gilson Machado's profile photo
Joe Lencioni's profile photo
Roland Wermuth's profile photo
Yong Zhang (Jacky)'s profile photo
Yogantenk Utomo's profile photo
赵刚's profile photo



Shared publicly  - 
Greenify and Android M

In this year's Google I/O festival, Android M was announced with many exciting new features, including Doze Mode and App Standby.

It's a huge step after several years of lacking restriction on app background behaviors, which Greenify pushes hard to fill. It‘s so proud to see the great influence Greenify has made to the Android platform itself, like the App Standby mechanism Cheers!

As a 3rd-party solution, Greenify performs well but still has its limitations into the platform. But as both the platform leader and app players, Google is in a much complex dilemma to build right solution for Android. We have already seen the Google Play services among that mix of love and hate.

The Dilemma

In Android M, it looks as if Google finally makes things right, not only permissions but also the power management for background apps. But in a further review of the current developer preview, it still shows obvious dilemma.

First, the Doze Mode and App Standby apply to all the apps by default, except some system apps, including Google Play services and Google Play Store. Even more disappointing, you are not allowed to toggle the setting for them. So Google starts to restrict all other apps but exempts itself?

Second, the condition of Doze Mode is rather strict, leaving only stationary device untouched for more than 1 hour qualified. If you carry your phone in the pocket, it could hardly enter Doze Mode. Even when you leave your device on the desktop, as long as instant messages or any other notifications arrives at a hourly rate and you picked up your phone to just see what's up, the Doze Mode is doomed. (Android Wear wins!)

What about App Standby? Unfortunately it is timed in days. So only apps you have not used for a long time enter standby. Even the worse, it allows apps to prevent themselves from going standby by posting notifications. That's really an insane idea which will surely drive much more pointless notifications to just game the system, users will suffer from both battery and notifications junks. Hope this gets fixed in the final release of Android M.

Greenify on Android M

In the bright side, Android M means a lot for Greenify users. With these new mechanisms, Greenify could again push the efforts of battery saving to a new extent, much better than it could do on previous Android versions, and predictably much better than stock Android M. It could even achieve much more on non-rooted devices.

Stay tuned for a preview version of Greenify for Android M Developer Preview in the recent future!
Serge M's profile photoBryan L's profile photoDharmady Lin's profile photoCleusa Paim's profile photo
 ·  Translate
Add a comment...


Bug Reports  - 
Call for logcat of bootloop issue

Although I've made fundamental protection in the Xposed module of Greenify (especially in 2.6 beta 10), some of you are still experiencing bootloop if experimental Xposed-based features are activated.

It's really hard to dig these issue without logcat since Android devices and ROMs are highly diverse (fragmented). But logcat in the bootloop case is understandable harder to capture than regular crash issues.

If you are one of the bootloop victims, and would like to help me on this issue. Please follow this instructions to capture a proper logcat for the bootloop issue:

1. Download and install ADB tool, either from Android SDK or as standalone package (
2. Connect your device with a PC or laptop with USB cable.
3. Enable developer options on your device. (
4. Test logcat capturing by typing this command in shell (or command prompt): "adb logcat -v time -d" (without quote marks), if you see plenty of log scrolling through the screen and finished, it's ready.
5. Trigger the bootloop, then after the device reboot, type this command in shell: "adb logcat -v time > logcat.txt", if you read "waiting for device" and the command continues running, that's OK.
6. Wait until the last command to finish and return to the shell, then you will get a "logcat.txt" file in the current path (usually the root path of your user home / folder). Send it to me via email (or

If the command does not finish in a long time, just press "Ctrl + C" to end it, and send me the logcat.txt if it's not empty.

Thanks very much for your effort to help diagnosing this issue.
Giggle Play's profile photosavan torian's profile photo
i would NOT greenify services. ;-) ends in somewhat strange. already tried. in my case i had to recover nandroid on my note 4. i tried to get rid of all the wakelocks , caused by the services (7.0.99)
Add a comment...


Beta Channel  - 
What's the differences have you noticed after Deep Hibernation is enabled?

I want to make sure the Deep Hibernation (in v2.6 beta 4) is working as expected, in all circumstances but not just my test cases.

In which case, a hibernated app stays hibernated instead of being woken before? (without wake-up paths cut-off)

In which case, a hibernated app is still woken by another app (which and when) with Deep Hibernation? Please also report the information shown in Greenify, like "Facebook is woken by Messenger: LoginService".
Jon Roadley-Battin's profile photoJoão Nabais's profile photoGreenify's profile photoOlivier C.'s profile photo
Hello, deep hibertion do crash amazon appshop. Am I the only one having this problem ?
Add a comment...


Beta Channel  - 
Known issues on v2.6 beta 4

Some wake-up paths are still not yet covered in the new "Cutoff" and "Deep Hibernation" feature, including "content provider" (a background data sharing mechanism in Android) and Location update (will be covered in future beta).

“Reveal Hidden Sync” is unable to be turned on/off in experimental features.

Deep Hibernation conflicts with GCM wake-up feature in some situation. (fixed in beta 2)

Uninstall and re-install this beta version may cause "Wake-up Tracker" to stop working. (upgrade without uninstallation will not trigger this issue, fixed in beta 2)

Wake-up paths cut-off by old "Cutoff" feature are not automatic re-attached in this beta version. (fixed in beta 2)
Matthias Knoll (Prazaar)'s profile photoCesar Canizalez's profile photoRafael Swientek's profile photoFilippo Genovese's profile photo
+Hiren Dave That might be a bug on some devices, I'll fix it soon.
Add a comment...


Shared publicly  - 
Greenify v2.6 beta 1 is rolling out (in beta channel)

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~

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:
> 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 on the community within "Beta" channel.
Tiesen Fu's profile photoGarnie Bolling's profile photoMarco Pontili's profile photoClaudia marilza do santos Abreu's profile photo
Beta 2 is rolling out to fix most bugs in beta 1, and Deep Hibernation is improved to stop more types of service invocation.
Add a comment...


Shared publicly  - 
Planning to backport JobScheduler of Android 5.0 Lollipop, as contribution to the Android developer community to drive a much better power management schema in various apps.
华强's profile photoecho III's profile photoGreenify's profile photoJulio Mendes's profile photo
+echo III 目前仍不确定部分应用唤醒后无法发出通知消息的具体原因。
 ·  Translate
Add a comment...
Your Android device can also run almost as smooth and lasting as the first day you have it!
A must have Android system tool for rooted device if you really care about battery consumption and smooth experience.
Contact Information
Contact info