Profile cover photo
Profile photo
Greenify
7,102 followers -
Your Android device can also run almost as smooth and lasting as the first day you have it!
Your Android device can also run almost as smooth and lasting as the first day you have it!

7,102 followers
About
Communities and Collections
Posts

Post is pinned.
Public
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 ( https://play.google.com/store/apps/details?id=eu.chainfire.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 (https://play.google.com/store/apps/details?id=com.oasisfeng.greenify.pro) 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:
https://plus.google.com/112105199234363320140/posts/2rtV8B9wiaw

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.
Commenting is disabled for this post.

Post has shared content
About the use of accessibility service in Greenify

Like many other developers, I also received the 30-days deadline warning email (https://www.xda-developers.com/google-threatening-removal-accessibility-services-play-store/) from Google Play team about the potential "misuse" of accessibility service in Greenify.

As the very first developer who introduced this trick of "misusing" accessibility to achieve UI automation years ago, I'm very proud that many more creative tool apps followed this approach to enable fantastic functionality beyond the imagination of the creator of Android, without root. It's a miracle bred from the openness and flexibility of Android.

Unfortunately, the supervisor of the dominant app market is now declaring its right of final interpretation, to judge the proper use of Android API and claim that this whole idea is unacceptable. At this point, I feel I have to say something.


Why accessibility service?

As we all know, root is the ultimate playground of super users in the Android community. But it also has its inconvenience and grey side, so I decided to make Greenify work for users with non-root device. I had been experimenting with many approaches for this purpose in almost the whole year 2013. Finally I found the magic of UI automation driven by accessibility service. With this approach, many more users now enjoy the improved battery life and smoothness brought by Greenify.

I know that accessibility service is not a perfect solution, considering the overall UI performance degradation involved (explained below). So I never gave up seeking alternative approaches ever since, (many of which might also be considered API "misusing" in strict speaking) but still no better approach found. If Android could provide any alternative solution, I would never prefer accessibility service in the first place.


The Good

Accessibility service is so powerful, that I have to admit it's some kind of Pandora's box.

With accessibility, developers could not only help people with disabled abilities, but also greatly benefit the general users with wonderful use cases, including:

• Remote assistant via touch interaction, without root. (seems like no such apps yet?)
• Automate the tedious operations inside not-well-designed apps, even possibly driven by Tasker or IFTTT, without root.
• Programatically trigger global actions (e.g. Back, Home).
• Overlay the whole screen including the notification shade on Android O.
• ……

I even wrote a small app with accessibility service to "fix" the bottom navigation bar of my wife's Moto X Style, whose touch screen is not reading touches any more in bottommost rows of pixels.


The Bad

With such power, accessibility service is also becoming the trending target of malware, endangering average users world-wide. A typical malware could deceive user to enable its accessibility service and then perform many dangerous actions without user consent, including gaining other sensitive privileges.

Together with screen overlay, this could even hide from average user's observation, effectively making it a seductive approach, thus highly dangerous in the wild.


The Ugly

The dangers above may not be a thread to advanced users, but the overall UI lag caused by accessibility service could be a real hurt.

Android delivers accessibility events to active accessibility service in two phases. Events are first generated in the current interacting app and immediately sent to system process, then dispatched to separate accessibility services, each in its own process.

If no accessibility services enabled, both phases are shutdown, thus no performance affection at all. If at least one accessibility service is enabled, the first phase is turned on, in full power, no matter which types of events are interested (declared by accessibility service). The second phase is taking that into consideration and only delivers the interested events to each accessibility service.

The performance lag comes mostly out of the first phase because some types of accessibility events are so heavy, considering how frequently they are triggered. For example, TYPE_WINDOW_CONTENT_CHANGED is generated and sent every tiny bit of UI content changes and TYPE_VIEW_SCROLLED is generated and sent every pixel your finger is moved across during scrolling, even if no accessibility services are interested in them.

Sounds crazy? Unfortunately that's the current situation. Although Android O took a step (https://github.com/aosp-mirror/platform_frameworks_base/commit/ef4351cc72abeeba0f659950c199a4f9b7cd1842) to address that, the situation is still not changed fundamentally. Maybe in Google's view, accessibility service is not intended for general users, so performance optimization is never in the priority.


How is Greenify doing

Performance is always Greenify's priority since it’s one of the purposes defining Greenify. So I took all the possibilities to improve that in the past years, even greatly pulled-back by Android system itself.

First of all, Greenify declares no interest of events at all at most of the time and only declares minimal interest of events (all are trivial to generate) and specific target (system settings app) required during the short period of on-going hibernation operation. This is implemented by dynamic registration, cutting the cost of the second phase to almost zero.

Due to the inefficient implementation in Android system, the first phase is still the bottleneck of UI performance. After a long time of trial and failure, I finally managed to eliminate that cost, in a tricky way. With necessary permission granted via ADB (https://greenify.uservoice.com/knowledgebase/articles/749142-how-to-grant-permissions-required-by-some-features), Greenify only enables its accessibility service during the hibernation operation and disable it immediately afterwards. That means, if no other accessibility service enabled, you will have no performance problem of accessibility service at all while still enjoy the power of Greenify.

With above optimization, Greenify limited the events it could receive to the minimal, thus also effectively keeps the privacy of users in safety. I'm planning to bring this optimization to broader users who has little knowledge about ADB, and even to other apps with accessibility service hopefully.


My Concern

Accessibility service is a yard full of potential creativity and magic. It should never be a Pandora's Box if Android itself implement it with caution in the first place. I understand the complexity and historical reasons that lead to the current situation, but feel sorry and sad about how Google deals with this situation, by banishing popular tool apps. Will that make Android users more secure? I highly doubt.

I don't know if Google Play team represents the atitude of Android team at Google. If so, it will then be the breaking day for all Android developers, when Google starts to use its power to judge the "proper use" of Android API, even if it's not used by malware.

Will it come a day that the use of screen overlay besides showing information will be banned?
Will it come a day that the use of content provider not for providing data will be banned?
Will it come a day that the use of internal APIs will be banned?

About the use of accessibility service in Greenify

Like many other developers, I also received the 30-days deadline warning email (https://www.xda-developers.com/google-threatening-removal-accessibility-services-play-store/) from Google Play team about the potential "misuse" of accessibility service in Greenify.

As the very first developer who introduced this trick of "misusing" accessibility to achieve UI automation years ago, I'm very proud that many more creative tool apps followed this approach to enable fantastic functionality beyond the imagination of the creator of Android, without root. It's a miracle bred from the openness and flexibility of Android.

Unfortunately, the supervisor of the dominant app market is now declaring its right of final interpretation, to judge the proper use of Android API and claim that this whole idea is unacceptable. At this point, I feel I have to say something.


Why accessibility service?

As we all know, root is the ultimate playground of super users in the Android community. But it also has its inconvenience and grey side, so I decided to make Greenify work for users with non-root device. I had been experimenting with many approaches for this purpose in almost the whole year 2013. Finally I found the magic of UI automation driven by accessibility service. With this approach, many more users now enjoy the improved battery life and smoothness brought by Greenify.

I know that accessibility service is not a perfect solution, considering the overall UI performance degradation involved (explained below). So I never gave up seeking alternative approaches ever since, (many of which might also be considered API "misusing" in strict speaking) but still no better approach found. If Android could provide any alternative solution, I would never prefer accessibility service in the first place.


The Good

Accessibility service is so powerful, that I have to admit it's some kind of Pandora's box.

With accessibility, developers could not only help people with disabled abilities, but also greatly benefit the general users with wonderful use cases, including:

• Remote assistant via touch interaction, without root. (seems like no such apps yet?)
• Automate the tedious operations inside not-well-designed apps, even possibly driven by Tasker or IFTTT, without root.
• Programatically trigger global actions (e.g. Back, Home).
• Overlay the whole screen including the notification shade on Android O.
• ……

I even wrote a small app with accessibility service to "fix" the bottom navigation bar of my wife's Moto X Style, whose touch screen is not reading touches any more in bottommost rows of pixels.


The Bad

With such power, accessibility service is also becoming the trending target of malware, endangering average users world-wide. A typical malware could deceive user to enable its accessibility service and then perform many dangerous actions without user consent, including gaining other sensitive privileges.

Together with screen overlay, this could even hide from average user's observation, effectively making it a seductive approach, thus highly dangerous in the wild.


The Ugly

The dangers above may not be a thread to advanced users, but the overall UI lag caused by accessibility service could be a real hurt.

Android delivers accessibility events to active accessibility service in two phases. Events are first generated in the current interacting app and immediately sent to system process, then dispatched to separate accessibility services, each in its own process.

If no accessibility services enabled, both phases are shutdown, thus no performance affection at all. If at least one accessibility service is enabled, the first phase is turned on, in full power, no matter which types of events are interested (declared by accessibility service). The second phase is taking that into consideration and only delivers the interested events to each accessibility service.

The performance lag comes mostly out of the first phase because some types of accessibility events are so heavy, considering how frequently they are triggered. For example, TYPE_WINDOW_CONTENT_CHANGED is generated and sent every tiny bit of UI content changes and TYPE_VIEW_SCROLLED is generated and sent every pixel your finger is moved across during scrolling, even if no accessibility services are interested in them.

Sounds crazy? Unfortunately that's the current situation. Although Android O took a step (https://github.com/aosp-mirror/platform_frameworks_base/commit/ef4351cc72abeeba0f659950c199a4f9b7cd1842) to address that, the situation is still not changed fundamentally. Maybe in Google's view, accessibility service is not intended for general users, so performance optimization is never in the priority.


How is Greenify doing

Performance is always Greenify's priority since it’s one of the purposes defining Greenify. So I took all the possibilities to improve that in the past years, even greatly pulled-back by Android system itself.

First of all, Greenify declares no interest of events at all at most of the time and only declares minimal interest of events (all are trivial to generate) and specific target (system settings app) required during the short period of on-going hibernation operation. This is implemented by dynamic registration, cutting the cost of the second phase to almost zero.

Due to the inefficient implementation in Android system, the first phase is still the bottleneck of UI performance. After a long time of trial and failure, I finally managed to eliminate that cost, in a tricky way. With necessary permission granted via ADB (https://greenify.uservoice.com/knowledgebase/articles/749142-how-to-grant-permissions-required-by-some-features), Greenify only enables its accessibility service during the hibernation operation and disable it immediately afterwards. That means, if no other accessibility service enabled, you will have no performance problem of accessibility service at all while still enjoy the power of Greenify.

With above optimization, Greenify limited the events it could receive to the minimal, thus also effectively keeps the privacy of users in safety. I'm planning to bring this optimization to broader users who has little knowledge about ADB, and even to other apps with accessibility service hopefully.


My Concern

Accessibility service is a yard full of potential creativity and magic. It should never be a Pandora's Box if Android itself implement it with caution in the first place. I understand the complexity and historical reasons that lead to the current situation, but feel sorry and sad about how Google deals with this situation, by banishing popular tool apps. Will that make Android users more secure? I highly doubt.

I don't know if Google Play team represents the atitude of Android team at Google. If so, it will then be the breaking day for all Android developers, when Google starts to use its power to judge the "proper use" of Android API, even if it's not used by malware.

Will it come a day that the use of screen overlay besides showing information will be banned?
Will it come a day that the use of content provider not for providing data will be banned?
Will it come a day that the use of internal APIs will be banned?
Add a comment...

Post has shared content
Auto-hibernation for secure key-guard and Alternative Screen-off for non-root mode is being tested in 2.9.5 beta 1. Please report back if it works smooth for your device.
Security with Ease

Since we introduced non-root auto-hibernation in Greenify 2.0, the insecure key-guard was a major limitation for you to take advantage of the unattended automation. At that time, we suggested an alternative solution to get around this limitation - the nav-bar gesture or shortcut to perform hibernation and then turn off (and lock) the screen. It was a viable choice for most users until "Smart Lock" and fingerprint unlock were introduced by Google.

The traditional screen-off implementation breaks Smart Lock and fingerprint unlock. That's not an intended behavior of Greenify, but as perceived by Google, an intended behavior in the low level Android device-admin API which Greenify and many other tools on Android used to programmatically turn off (and lock) the screen. (http://buff.ly/2bPAgFb) Soon after that, we introduced "Alternative Screen-off" option in settings for rooted devices, which keeps the Smart Lock and fingerprint unlock working as usual. Unfortunately, it doesn't work for non-root devices. We developers have been arguing with Google in the past years for this inconvenience in the Android API, but no progress at all.

Your security should never be compromised! As more and more devices have fingerprint scanner built-in and upgraded to the newer version of Android, we decided to solve this issue with a not-that-perfect workaround for non-root devices. Start with 2.9.5 beta version of Greenify, you can also activate the "Alternative Screen-off" option if your device is not rooted, at the cost of slightly delayed actually screen-off time (10 seconds in most devices). If your device has a OLED (including AMEOLED) screen, then you will probably not notice the difference since it's toally blacked during the delay.

In the mean time, we also implemented auto-hibernation for secure key-guard in non-root mode. The only requirement is a delayed lock (just 5s is enough) in device security settings. Greenify kicks in soon when you turn off the screen to perform the automated hibernation before screen is actually locked.

With these two improvements work together, you can now enjoy a fully secured key-guard even if your device is not rooted, without sacrificing the easy unlocking with Smart Lock and fingerprint. You can opt-in to the beta channel to enjoy this benefit now, but beware it's still in beta with potential bugs expected.

Security with Ease

Since we introduced non-root auto-hibernation in Greenify 2.0, the insecure key-guard was a major limitation for you to take advantage of the unattended automation. At that time, we suggested an alternative solution to get around this limitation - the nav-bar gesture or shortcut to perform hibernation and then turn off (and lock) the screen. It was a viable choice for most users until "Smart Lock" and fingerprint unlock were introduced by Google.

The traditional screen-off implementation breaks Smart Lock and fingerprint unlock. That's not an intended behavior of Greenify, but as perceived by Google, an intended behavior in the low level Android device-admin API which Greenify and many other tools on Android used to programmatically turn off (and lock) the screen. (http://buff.ly/2bPAgFb) Soon after that, we introduced "Alternative Screen-off" option in settings for rooted devices, which keeps the Smart Lock and fingerprint unlock working as usual. Unfortunately, it doesn't work for non-root devices. We developers have been arguing with Google in the past years for this inconvenience in the Android API, but no progress at all.

Your security should never be compromised! As more and more devices have fingerprint scanner built-in and upgraded to the newer version of Android, we decided to solve this issue with a not-that-perfect workaround for non-root devices. Start with 2.9.5 beta version of Greenify, you can also activate the "Alternative Screen-off" option if your device is not rooted, at the cost of slightly delayed actually screen-off time (10 seconds in most devices). If your device has a OLED (including AMEOLED) screen, then you will probably not notice the difference since it's toally blacked during the delay.

In the mean time, we also implemented auto-hibernation for secure key-guard in non-root mode. The only requirement is a delayed lock (just 5s is enough) in device security settings. Greenify kicks in soon when you turn off the screen to perform the automated hibernation before screen is actually locked.

With these two improvements work together, you can now enjoy a fully secured key-guard even if your device is not rooted, without sacrificing the easy unlocking with Smart Lock and fingerprint. You can opt-in to the beta channel to enjoy this benefit now, but beware it's still in beta with potential bugs expected.
Add a comment...

The Xposed module of Greenify is temporarily deprecated for Android 6.0+ in latest beta version. It is currently being evaluated for further support.

I'd like to hear your opinions.

Donation package migration for Amazon Appstore users.
(Not for donation package of Google Play)

Sorry for the delay in building a viable migration solution for donation package purchased from Amazon Appstore.

Please open the following link and sumbit your Amazon order information to get free migration of your donation package. (scheduled to deliver in Dec. 2015) All information must match your Amazon order to be qualified.

Sorry again for all the troubles around donation package on Amazon Appstore.

https://docs.google.com/forms/d/1iDBP0DVehAQR7NHuWEmnr_6Q2F5mvgj0tb2UvdfDFB4/viewform?entry.1135518797=XXX-XXXXXXX-XXXXXXX&entry.248100552
Add a comment...

Post has shared content
Special treatment for NON-ROOT Android 6.0 adopters!

As mentioned earlier, Android 6.0 brings great power saving improvement to the system framework - "Doze Mode" and "App Standby", but not yet ready to release their true power. In v2.7, Greenify takes advantage of the "App Standby" into the "Shallow Hibernation" engine. Now "Doze Mode" also needs an enhancement.

Let me introduce the new experimental feature - "Aggressive Doze", exclusive for Android 6.0 Marshmallow (currently in 2.8 beta channel only). Once enabled, your device will be put into Doze mode as soon as possible after the screen goes off. No more "1 hour no-movement" prerequisite.

The best part of this feature - NO ROOT REQUIRED! Still you need to perform a one-time procedure with USB-cable and a connected computer, which is surely familiar to many advanced users.

This is not the complete solution for a better Doze mode. It is an experiment to push the power-saving effect of Doze mode to the limit, but may also break some background functionality of your apps. So I'm listening to all your feedback and opinions, to build a smarter and finer-tweaked Doze mode in Android 6.0.

Together with the "Shallow Hibernation", let's start a new adventure of Greenify with Android Marshmallow.
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!
Add a comment...

Post has shared content
Greenify 2.7 is released, enjoy the new "Shallow Hibernation" on Android 6.0 with root exclusive.

If you are pioneer into Android 6.0 developer preview. It may seem nothing specially in Greenify at first glance. But the hibernation engine under the hood is entirely upgraded with "Shallow Hibernation".

Apps in hibernation never lose context any more, which makes multitasking among hibernated apps without pain. Feel free to add your frequently using (but battery draining) apps into Greenify.

Even the better, GCM push should work for all hibernated apps once their developer adopt the new GCM priority policy required by Android 6.0. No more Xposed framework needed for GCM push!

Greenify keeps evolving with Android, better than ever.
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!
Add a comment...

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.
Wait while more posts are being loaded