FORUMS
Remove All Ads from XDA

Is Greenify Malware?... or Spyware?

59 posts
Thanks Meter: 35
 
By xxxmadraxxx, Member on 7th May 2019, 03:49 PM
Post Reply Email Thread
10th June 2019, 03:21 AM |#21  
Senior Member
Thanks Meter: 25
 
More
Quote:
Originally Posted by htr5

I came across this thread because in the past year, three times I have been notified by Xposed that a module has been updated. SuperSU also asks me to grant root access again so I'm wondering what the app is doing self updating?

Version 4.5.1 (donate)

I think what's happening here is this:
In Xposed, you likely have the Greenify Experimental Features module, and Xposed automatically updated that module.

SuperSU is set to reauthorize root for updated apps and modules, so when Xposed updated that module (which SuperSU likely considers to be a part of Greenify), SuperSU asked for authorization to grant root to Greenify.
 
 
11th June 2019, 06:01 AM |#22  
Senior Member
Thanks Meter: 25
 
More
I'm going to try the following:

This disables Google Play Services from resetting your Doze settings.
Code:
adb shell "su -c 'pm disable --user 0 com.google.android.gms/.phenotype.service.sync.PhenotypeConfigurator'"
This shows you your current Doze settings:
Code:
adb shell dumpsys deviceidle
This resets the doze settings to blank.
Code:
adb shell settings delete global device_idle_constants
This disables Light Doze.
Code:
adb shell dumpsys deviceidle disable light
This sets the Device Idle Constants. My main aim is to progress to Deep Doze as quickly as possible after the screen goes off.
Code:
adb shell settings put global device_idle_constants light_after_inactive_to=0,light_pre_idle_to=0,light_idle_to=0,light_idle_factor=2.0,light_max_idle_to=0,light_idle_maintenance_min_budget=0,light_idle_maintenance_max_budget=0,min_light_maintenance_time=0,min_deep_maintenance_time=0,inactive_to=0,sensing_to=0,locating_to=0,location_accuracy=1000.0,motion_inactive_to=86400000,idle_after_inactive_to=0,idle_pending_to=0,max_idle_pending_to=0,idle_pending_factor=2.0,idle_to=86400000,max_idle_to=172800000,idle_factor=2.0,min_time_to_alarm=1000,max_temp_app_whitelist_duration=0,mms_temp_app_whitelist_duration=0,sms_temp_app_whitelist_duration=0,notification_whitelist_duration=0
Device Idle Constants:
Code:
light_after_inactive_to
This is the time, after becoming inactive, that we go in to
the first light-weight idle mode.

light_pre_idle_to
This is amount of time we will wait from the point where we
decide we would like to go idle until we actually do, while
waiting for jobs and other current activity to finish.

light_idle_to
This is the initial time that we will run in idle maintenance
mode.

light_idle_factor
Scaling factor to apply to the light idle mode time each time
we complete a cycle.

light_max_idle_to
This is the maximum time we will run in idle maintenence mode.

light_idle_maintenance_min_budget
This is the minimum amount of time we want to make available
for maintenance mode when lightly idling. That is, we will
always have at least this amount of time available maintenance
before timing out and cutting off maintenance mode.

light_idle_maintenance_max_budget
This is the maximum amount of time we want to make available
for maintenance mode when lightly idling. That is, if the
system isn't using up its minimum maintenance budget and this
time is being added to the budget reserve, this is the maximum
reserve size we will allow to grow and thus the maximum amount
of time we will allow for the maintenance window.

min_light_maintenance_time
This is the minimum amount of time that we will stay in
maintenance mode after a light doze. We have this minimum to
allow various things to respond to switching in to
maintenance mode and scheduling their work -- otherwise we may
see there is nothing to do (no jobs pending) and go out of
maintenance mode immediately.

min_deep_maintenance_time
This is the minimum amount of time that we will stay in
maintenance mode after a full doze.  We have this minimum to
allow various things to respond to switching in to
maintenance mode and scheduling their work -- otherwise we may
see there is nothing to do (no jobs pending) and go out of
maintenance mode immediately.

inactive_to
This is the time, after becoming inactive, at which we start
looking at the motion sensor to determine if the device is
being left alone.  We don't do this immediately after going
inactive just because we don't want to be continually running
the motion sensor whenever the screen is off.

sensing_to
If we don't receive a callback from AnyMotion in this amount
of time + LOCATING_TIMEOUT, we will change from STATE_SENSING
to STATE_INACTIVE, and any AnyMotion callbacks while not in
STATE_SENSING will be ignored.

locating_to
This is how long we will wait to try to get a good location fix
before going in to idle mode.

location_accuracy
The desired maximum accuracy (in meters) we consider the location
to be good enough to go on to idle. We will be trying to get an
accuracy fix at least this good or until LOCATING_TIMEOUT expires.

motion_inactive_to
This is the time, after seeing motion, that we wait after becoming
inactive from that until we start looking for motion again.

idle_after_inactive_to
This is the time, after the inactive timeout elapses, that we will
wait looking for motion until we truly consider the device to be
idle.

idle_pending_to
This is the initial time, after being idle, that we will allow
ourself to be back in the IDLE_MAINTENANCE state allowing the
system to run normally until we return to idle.

max_idle_pending_to
Maximum pending idle timeout (time spent running) we will be
allowed to use.

idle_pending_factor
Scaling factor to apply to current pending idle timeout each time
we cycle through that state.

idle_to
This is the initial time that we want to sit in the idle state
before waking up again to return to pending idle and allowing
normal work to run.

max_idle_to
Maximum idle duration we will be allowed to use.

idle_factor
Scaling factor to apply to current idle timeout each time we cycle
through that state.

min_time_to_alarm
This is the minimum time we will allow until the next upcoming
alarm for us to actually go in to idle mode.

max_temp_app_whitelist_duration
Max amount of time to temporarily whitelist an app when it
receives a high priority tickle.

mms_temp_app_whitelist_duration
Amount of time we would like to whitelist an app that is receiving
an MMS.

sms_temp_app_whitelist_duration
Amount of time we would like to whitelist an app that is receiving
an SMS.

notification_whitelist_duration
Amount of time we would like to whitelist an app that is handling
a PendingIntent triggered by a Notification.


You can also force Android into Deep Doze manually: adb shell dumpsys deviceidle force-idle

I've also set 3C CPU Manager to force 6 CPU cores offline when the screen is off, and to force the other 2 cores to a maximum 299 MHz.

If that doesn't work the way I want, there's always https://f-droid.org/packages/com.suy...jan.forcedoze/.

{UPDATE}
So I got rid of Greenify and Nova Launcher. I replaced Greenify with the settings above, and I replaced Nova Launcher with OpenLauncher. I've disabled pretty much everything in OpenLauncher, so the screen is completely empty... the only thing I use it for is the app drawer, and I've set that to have a black background.
OpenLauncher App Drawer, black theme

Before, AFWall+ would be constantly popping up toast messages that it's blocked communication for Google components (because both Greenify and Nova Launcher used Google components such as Firebase, Tag Manager, Crashlytics, etc.)... now I get a couple messages after boot that the kernel tried to connect, and after that, it's silent.
{/UPDATE}
The Following 2 Users Say Thank You to Lusty Rugnuts For This Useful Post: [ View ] Gift Lusty Rugnuts Ad-Free
29th June 2019, 10:26 AM |#23  
Oswald Boelcke's Avatar
Forum Moderator / Recognized Translator
Flag Preserving Air Supremacy over XDA!
Thanks Meter: 6,524
 
More
SuperFreezZ, which is open source, might be an alternative to Greenify.
Available on F-droid: https://f-droid.org/packages/superfreeze.tool.android/
Source: https://gitlab.com/SuperFreezZ/SuperFreezZ
29th June 2019, 01:32 PM |#24  
DB126's Avatar
Senior Member
Thanks Meter: 9,233
 
More
Quote:
Originally Posted by Oswald Boelcke

SuperFreezZ, which is open source, might be an alternative to Greenify.
Available on F-droid: https://f-droid.org/packages/superfreeze.tool.android/
Source: https://gitlab.com/SuperFreezZ/SuperFreezZ

Interesting alternative. A bit rough around the edges with a limited feature set. That said, it's a '0.1' release and more focused on core capabilities. See if the developer maintains it.
The Following User Says Thank You to DB126 For This Useful Post: [ View ] Gift DB126 Ad-Free
3rd July 2019, 04:04 PM |#25  
Senior Member
Thanks Meter: 244
 
More
Quote:
Originally Posted by htr5

I came across this thread because in the past year, three times I have been notified by Xposed that a module has been updated. SuperSU also asks me to grant root access again so I'm wondering what the app is doing self updating?

Version 4.5.1 (donate)

THIS!

I've been noticing something like that on last months. And now - 46 minutes ago - it just happened while I was with device in hands.


I'm completely sure that Greenify SELF UPDATED itself:

I was using my device (LOS 14.1 + Magisk + Xposed) when it automatically started a download and the notification was something like "Google Play secure, update,....", suggesting it was an automatic update from Google. (I have GP auto update disabled.)

As soon as the download finished Xposed Installer showed a notification that an Xposed module was updated. Weird. (There's nothing automatically set on my Xposed Installer.)

Then I opened Titanium Backup and confirmed: GREENIFY app have just been updated! Exactly at that time I saw the download (by 11:03am local time). It is the only app update today, all my others (including Google's) were updated a few days ago, when I last manually updated them.
The Greenify version continue to be v4.5.1 but Titanium Backup clearly shows it as updated just now.

We cannot trust Greenify anymore. By the way, nothing from same developer! Unless there's a very good explanation to that.

And just to let it clear: my Greenify was originally installed from Play Store (v4.5.1), same for Donation Package (v2.3), I paid for it a few years ago.

---------- Post added at 04:04 PM ---------- Previous post was at 03:49 PM ----------

Quote:
Originally Posted by Oswald Boelcke

Never ever had a "self-update" of Greenify.
Currently on Greenify v4.6.3 (Google beta programme) & Greenify (Donation Package) v2.3

Check my previous post. It just happened with my v4.5.1. Maybe also with your Beta? Maybe in a few days? Keep attention to that. Confirm with some tools like I did with Titanium Backup for instance.
Do you have Greenify Xposed module enabled? Maybe the self update is only triggered by it.
The Following User Says Thank You to wilsonhlacerda For This Useful Post: [ View ] Gift wilsonhlacerda Ad-Free
6th July 2019, 02:54 PM |#26  
Oswald Boelcke's Avatar
Forum Moderator / Recognized Translator
Flag Preserving Air Supremacy over XDA!
Thanks Meter: 6,524
 
More
@wilsonhlacerda I confirm your observation; however, I do not follow your conclusion.
I apologise that I didn't change my system laguage to English before I took the screenshots. Automatic updates are also disabled in my Google Play Store (GPS). And new versions are in deed not automatically downloaded and installed, but the current version of an application - not only Greenify - receives "updates". Please refer to screenshots for examples. SD Maid indicates the time of the "update" although the application itself hasn't received a new version in play store for quite a while. Thus far, I was unable to note an interval, in which these "updates" occur. I get aware of them because my setup makes MyAndroidTools to pop up and AppOpsExposed to display a notification in case of updates. Titanium Backup doesn't indicate that an "update" occured.
I can clearly state that the "update" only occurs with application installed from GPS; not with one from F-Droid or XDA Labs, not with manually installed ones.

I don't remember when this system behaviour actually commenced but I personally assess that it came with one of the last GPS versions. My conclusion: I do not blame Greenify but my beloved favourite "Google"!


EDIT: Personal counter measure - I've frozen GPS and unfreeze about once a week to check for updates especially of app in beta programmes or if I want to make a purchase. Aurora is anyway in parallel use.
Attached Thumbnails
Click image for larger version

Name:	Screenshot_20190704-065429.png
Views:	160
Size:	127.8 KB
ID:	4788036   Click image for larger version

Name:	Screenshot_20190703-170122.png
Views:	164
Size:	95.0 KB
ID:	4788037   Click image for larger version

Name:	Screenshot_20190703-170213.png
Views:	156
Size:	143.1 KB
ID:	4788038   Click image for larger version

Name:	Screenshot_20190704-065222.png
Views:	154
Size:	90.2 KB
ID:	4788039   Click image for larger version

Name:	Screenshot_20190704-065300.png
Views:	148
Size:	148.0 KB
ID:	4788041   Click image for larger version

Name:	Screenshot_20190705-203337.png
Views:	142
Size:	89.5 KB
ID:	4788042   Click image for larger version

Name:	Screenshot_20190705-203410.png
Views:	140
Size:	159.0 KB
ID:	4788043  
The Following User Says Thank You to Oswald Boelcke For This Useful Post: [ View ] Gift Oswald Boelcke Ad-Free
18th July 2019, 08:58 PM |#27  
Junior Member
Thanks Meter: 28
 
More
If you are concerned about privacy, you could use SuperFreezZ instead (Download on F-Droid). It provides similar functionality to Greenify but does not even need the "internet" permission so it can't "phone home".

(SuperFreezZ is not available on the Play Store currently; you can download it from F-Droid).
19th July 2019, 10:48 AM |#28  
Oswald Boelcke's Avatar
Forum Moderator / Recognized Translator
Flag Preserving Air Supremacy over XDA!
Thanks Meter: 6,524
 
More
Quote:
Originally Posted by hcur

If you are concerned about privacy, you could use SuperFreezZ instead (Download on F-Droid). It provides similar functionality to Greenify but does not even need the "internet" permission so it can't "phone home".

(SuperFreezZ is not available on the Play Store currently; you can download it from F-Droid).

Thanks for the reminder. Already mentioned here on 25 June 2019 (just a few posts above).

https://forum.xda-developers.com/search.php
20th July 2019, 02:17 PM |#29  
Junior Member
Thanks Meter: 28
 
More
Quote:
Originally Posted by Oswald Boelcke

Thanks for the reminder. Already mentioned here on 25 June 2019 (just a few posts above).

https://forum.xda-developers.com/search.php

Oh, sorry, I should have read through the thread before posting.
21st July 2019, 01:25 AM |#30  
DB126's Avatar
Senior Member
Thanks Meter: 9,233
 
More
Amazing - this is the only thread within the Greenify 'forum' that has received any significant activity in the past 30 days...probably longer. Speaks volumes.
21st July 2019, 06:46 AM |#31  
Oswald Boelcke's Avatar
Forum Moderator / Recognized Translator
Flag Preserving Air Supremacy over XDA!
Thanks Meter: 6,524
 
More
Update to my post here of 06 July:
Yesterday evening, I'd unfrozen Google Play Store (GPS) to check for updates in the beta programmes I've subscribed to (ok, there were none). Accidentally, I forgot to freeze GPS again, and this morning I realised due to notifications by "MyAndroidTools" and "AppOpsXposed Re" that four applications (all of them downloaded from GPS in the past) had been updated - but not to new versions; the current versions had been "updated". By the way: Greenify was not among them.
This new abservation reinforces my initial conclusion and assumption.
The Following User Says Thank You to Oswald Boelcke For This Useful Post: [ View ] Gift Oswald Boelcke Ad-Free
Post Reply Subscribe to Thread

Tags
afwall+, firewall, greenify, malware, spyware

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes