[Q] Greenify requires new permissions as of last update? - Greenify

Someone on reddit noticed that the last update to Greenify required new permissions: Device & app history and Identity. What is the specific use for those permissions and why weren't they needed before?

Related

Non-Root Apps Asking for Permission?

In the past I read a thread from someone claiming that he had
Appbrain App Market installed on his phone which is a Non-Root app the last time I checked, Well anyways he said that he was Receiving Popups from the app to Grant it Superuser Permissions.
I really Didn't think much about it until now when I Received a Popup of my own, After I Installed whatever Stupid Basketball 3D game from the Market myself...
I checked and it Wasn't a Root app, and it Didn't even show up in the Superuser app Log, even though I Didn't Grant it Permission. I just UnInstalled it as soon as I saw the Popup!
So my Question is...
What the Hells up with that? Is that some type of Virus app or some ****?
Thanx in Advance!
PMGRANDS said:
In the past I read a thread from someone claiming that he had
Appbrain App Market installed on his phone which is a Non-Root app the last time I checked, Well anyways he said that he was Receiving Popups from the app to Grant it Superuser Permissions.
I really Didn't think much about it until now when I Received a Popup of my own, After I Installed whatever Stupid Basketball 3D game from the Market myself...
I checked and it Wasn't a Root app, and it Didn't even show up in the Superuser app Log, even though I Didn't Grant it Permission. I just UnInstalled it as soon as I saw the Popup!
So my Question is...
What the Hells up with that? Is that some type of Virus app or some ****?
Thanx in Advance!
Click to expand...
Click to collapse
i'm not familiar with random apps from the market asking for superuser permission but i am familiar with the superuser app and how the permission structure/process works.
essentially, the superuser.apk file replaces your /system/bin/su binary with its own binary. the superuser custom binary, whenever any user or application executes a command using the su binary (executing a command as root) the superuser su binary redirects to the superuser application then prompting the user to accept or deny the request.
i know i have seen it is possible to spoof these requests, but it was done by a very knowledgable friend and i don't think the spoofing of superuser requests is common place or well known (might have been patched recently too).
without knowing the application's source code that requested superuser access, i personally would not trust the application unless the application stated it would need root access and performed functions which required root access. example, if the application were a game, i don't see any reason it would need superuser access.
once an application has been granted superuser access on an s-off evo 3d, it essentially has write/read access to the majority of the android partitions including the kernel, system, data, cache, etc.
from what you've described, i think you're correct in not granting an unknown application superuser access. as a developer with applications in the market, i would appreciate an email from a user who experienced such a situation and a screenshot attached would be even more helpful. might be worthwhile reaching out to the developer to confirm or ask them to explain.
thanks for posting this information. always good to know. hope some of the information i provided helps!
joeykrim said:
i'm not familiar with random apps from the market asking for superuser permission but i am familiar with the superuser app and how the permission structure/process works.
essentially, the superuser.apk file replaces your /system/bin/su binary with its own binary. the superuser custom binary, whenever any user or application executes a command using the su binary (executing a command as root) the superuser su binary redirects to the superuser application then prompting the user to accept or deny the request.
i know i have seen it is possible to spoof these requests, but it was done by a very knowledgable friend and i don't think the spoofing of superuser requests is common place or well known (might have been patched recently too).
without knowing the application's source code that requested superuser access, i personally would not trust the application unless the application stated it would need root access and performed functions which required root access. example, if the application were a game, i don't see any reason it would need superuser access.
once an application has been granted superuser access on an s-off evo 3d, it essentially has write/read access to the majority of the android partitions including the kernel, system, data, cache, etc.
from what you've described, i think you're correct in not granting an unknown application superuser access. as a developer with applications in the market, i would appreciate an email from a user who experienced such a situation and a screenshot attached would be even more helpful. might be worthwhile reaching out to the developer to confirm or ask them to explain.
thanks for posting this information. always good to know. hope some of the information i provided helps!
Click to expand...
Click to collapse
Yeah man I Never really Experienced a App Requesting Superuser Permission, that Wasn't even a Root App... Just Didn't seem right to me either... A Game Shouldn't need Root Access!!
Thanx for your Reply!
I recently had the same op-ups from Tasker. But since I had been using Tasker even before rooting, I denied the request.
Are there any more precautions we need to take with regards to this.
odyssseus said:
I recently had the same op-ups from Tasker. But since I had been using Tasker even before rooting, I denied the request.
Are there any more precautions we need to take with regards to this.
Click to expand...
Click to collapse
Great question. If anybody else has experience/knowledge feel free to chime in.
Regarding precautions, there are a few basic steps which I think we're all fairly familiar with as being general computer precautions. These are a few which come to mind:
1) Don't load software you don't trust.
2) Always thorougly check the permissions being granted to an application. Example, once you grant an application permission to load at startup, it now has the potential to always be running in the background. Potential bad situation: the application *could* be gathering user/system data and if it has network access, sending this data back.
3) Superuser provides a great basic level of security to protect root access. Without superuser, any application can execute the su binary now running with root priviledges and there will be no required notification to the end user. This could all happen in the background w/o a log, audit trail or notification to the user. Root priviledges, as I mentioned above on an S-OFF EVO 3D will give write access to /system, /data, boot (kernel), recovery, etc. This is potentially very dangerous and important to protect the su binary.
Important to realize, once an application has been granted superuser access, it has the potential to destroy the device or grab extensive system/personal information and send it out. This makes it essential to trust the application.
As with any type of security, there are always ways to bypass. Essentially, these three steps should help avoid the majority of issues.
On a brighter note, there really aren't many Android viruses or malicious applications in circulation. For the most part, people who post on XDA and android application developers/posters in the market have are trustworthy. The comments on Market applications are usually fairly helpful. Might be worth skimming thru a page or 2, maybe 3 or 4 of market comments on a suspicious application or emailing the developer.
I know as a developer I'm more than happy to explain any function or question regarding my applications, especially if it raises a security/privacy concern to a user.
Hope that helps round out some simple precautions!

[ROOT][Fix GMS] How to fix Google Play Services 7.0.97 as stopped

- You have problems with the application Google Play Services 7.0.97?...
Google with the latest updates of play services has caused many problems, continuous blocks and excessive consumption of the battery...
I have not found a definitive solution to use version 7.0.97, but I can explain an alternative and provisional...
- What you need?
1. Root
2. Google Play Services .apk version 6.6.03 universal armeabi CPU (I preferred version and stable)
3. File manager with permission root
How to?
1. uninstall the previous version of the Google Play Services
2. install version 6.6.03 (...)
3. create a folder in /Data/app with name com.google.android.gms-2 , permits changes in RW-R-R (this folder blocks the automatic update)
Note:
- Updated from sdcard worked
...by NotOnlyEyes
Great ... until it gets auto-"upgraded" by Google. Since this is not listed as an app in Play, how would one mark to not auto-upgrade. Maybe if it shows on recent upgrades in "my-apps," auto-upgrade can be unchecked from there.
Tasker scripts and/or the "Amplfiy" Xposed module can be used to tame the battery drain, or use an app-permissions that might come with your ROM to take away keep-awake. Will do nothing for the instability, however.
Maybe post a link to the old version.
Dovidhalevi said:
Great ... until it gets auto-"upgraded" by Google. Since this is not listed as an app in Play, how would one mark to not auto-upgrade. Maybe if it shows on recent upgrades in "my-apps," auto-upgrade can be unchecked from there.
Tasker scripts and/or the "Amplfiy" Xposed module can be used to tame the battery drain, or use an app-permissions that might come with your ROM to take away keep-awake. Will do nothing for the instability, however.
Maybe post a link to the old version.
Click to expand...
Click to collapse
This is block auto-upgrade from market:
3. create a folder in /Data/app with name com.google.android.gms-2 , permits changes in RW-R-R (this folder blocks the automatic update)...
Add link version google play services 6.6.03 in first post...
Notonlyeyes said:
This is block auto-upgrade from market:
3. create a folder in /Data/app with name com.google.android.gms-2 , permits changes in RW-R-R (this folder blocks the automatic update)...
Add link version google play services 6.6.03 in first post...
Click to expand...
Click to collapse
This looks like for lollipop.
In previous Android, using Link2sd, this would BE the link to the apk.
So what I did try was side-loading 6.6.03. The downgrade installed without a hitch thanks to the xinstall module, link2sd symlinked it, fine.
Then rebooted. Hoped to intercept the expected update and uncheck the Play Services auto-upgrade at that point. Unfortunately, most recent Google App (Search/Now) will not eat 6.6.03 so got com.google.process.gapps stop messages. The Google Now pane offered a click to install Play Services but this did not work.
Attempt to side-load 7.0.86 simply hung so trying to restore 7.0.97 from Titanium which also takes quite a bit of time but should eventually work (hope). So far, not successful, but will get it. Had side-loaded it originally.
is it causing problems on every version of android or only on kitkat ??
nomancoolboy said:
is it causing problems on every version of android or only on kitkat ??
Click to expand...
Click to collapse
Well im on cm9 and i havent got any error so far

How to use overlay/floating apps in Android 6.0 conveniently?

With the latest update in marshmallow devices , now we get a 'screen overlay detected' dialog which doesn't allow us to allow or deny any permission. I also Googled about this issue and i found out that the 'pie control' app installed in my phone was causing it and it was a part of the update that screen overlays should be disabled while granting permission.
Now i just want to ask that how is it gonna be possible for marshmallow users to use screen overlay apps as we would have to disable them every time any app asks for any permission :|
Reference:
http://www.xda-developers.com/how-t...-with-android-marshmallow-and-nobody-noticed/
http://www.androidpolice.com/2015/0...ant-special-permission-to-draw-on-other-apps/

Permissions File

I'm posting this here because I think that is something common to all Android Versions, I'm having problems with my room and the GAPPs, it is due to a Chinese phone with a Chinese rom and no Google installed at all.
I have successfully installed the Google APPs but these ones becomes system APPs and I'm not able to grant permissions through setting menu, it seems that system app permissions can not be managed from here.
Problem is that Play services aren't allow to access to SMS or at least that is what an annoying pop up says, so I'm wondering whether is any way to check that permissions on a file (xml or something like that) because I guess that changing permissions through setting menu ends changing some configuration file.
If I install some app using the apk, permissions can be manage from settings...
Answer myself. I leave the link down here in case somebody else need the info.
https://stackoverflow.com/questions/37130838/android-runtime-permission-for-system-apps

Any developer here, I need help with reading Amazfit data without root access

I am a programmer but never worked on any android project. I am working on a POC and need to extract health data from synced to Amazfit.
I downloaded Notify & Fitness For Amazfit and found out this app is able to read all health data without any specific permission or root access.
I was able to see sqlite DB in Amazfit app folder location using root explorer. /data/data/com.huami.watch.hmwatchmanager/databases
AFIK, a different can't access this folder without root access. So how does Notify & Fitness For Amazfit able read all my synced data to watch?
Can anyone help me how this app able to read Amazfit data?
Some apps can have their databases queried from other apps, that's how access to calendar works on Android. You just need to check the manifest to check what are the URIs and permissions required.

Categories

Resources