Goodbye ACCESS_SUPERUSER permission?
Posted on 2014-11-25, 173 comments, 605 +1's, imported from Google+/Chainfire

NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.

Almost two years ago, the ACCESS_SUPERUSER permission was coined, and by a select few this was greeted with enthusiasm. I care about compatibility and uniformity, and thus SuperSU also implemented it.

3rd-party-app-defined permissions have never really worked well on Android, and various quirks have caused issues with it before -  install-order issues, for example, that could cause the permission to not be granted, which makes it unreliable and requiring odd workarounds. Let's face it, the system is designed primarily for core system packages to declare permissions, and 3rd party packages to only use them.

Furthermore, it's not really useful. There's an optional warning in the root request prompt (disabled by default for some time now in SuperSU), but the permission is not in any way enforced. It does show up in the permissions box when you install an app (in short form), but how often do you install a root app that you didn't already know uses root? And if you didn't know, would perhaps the root prompt itself be enough indication? If someone is trying to be sneaky about it, they will not declare the permission anyway (without any repercussions).

It has always irked me that it used the android.permission space as well, rather than the advised package-name-based space. I've always suspected it would create issues somewhere down the line - and now it has!

Android 5.0 Lollipop now requires custom permissions to be unique unless the declaring packages are signed with the same cryptographic keys (same author, usually), or package installation will fail. As all modern root management packages now declare this permission, this means you cannot easily install a different one and start using that one, as its initial installation will fail, unless you are using a recovery-based installer that also cleans away the old one.

Declaring this permission thus reduces SuperSU's compatibility, and may keep you from upgrading from another package to SuperSU. Not all packages have the friendly option to uninstall themselves and leave a working su binary that allows switching to a competing package like SuperSU does, and removing a system-based root management package may be difficult or even impossible. Having reduced compatibility because of this permission of questionable value is obviously not an option, and thus it will have to go

Now, there are two major options going forward:

(1) we drop the permission, forget it ever happened, and never speak of it again, or

(2) we rename the permission in SuperSU, and try to convince all root app developers to request yet another permission, again (eventually for each different root management app as well)

I'm open to your opinions on the matter, whether (1) or (2) has your preference, but unless a full blown riot erupts, I doubt I'll be keeping it the way it is now.

If you do not post a reason for your preference, your vote will be ignored. Do not respond if you do not understand what this is about. Neither option kills root!

Dario Mehdi commented on 2014-11-25 at 16:24:

I'll go with 2

Edu Sanabria commented on 2014-11-25 at 16:24:


高登超膠 commented on 2014-11-25 at 16:25:


BASHAR EMRER commented on 2014-11-25 at 16:25:

What is your advice?

1 or 2 ?

Marc MAJKA commented on 2014-11-25 at 16:27:


Stephan Schmitz commented on 2014-11-25 at 16:28:

Fully agree with your arguments and would go for remove it. Any other solution will most likely cause issues down the road again and workarounds are never a solution. And the pros don't outweigh the cons anyway, IMHO. 

Alessandro Lagares Ferreira commented on 2014-11-25 at 16:29:


Jithin Bose commented on 2014-11-25 at 16:31:
Jose Baez commented on 2014-11-25 at 16:31:


Royal Saxon commented on 2014-11-25 at 16:31:

2 please

Nasir Uddin commented on 2014-11-25 at 16:31:


Richard Schultz commented on 2014-11-25 at 16:32:

1 I reread and realized I miss read my apologies +Chainfire

Gary Tomlinson commented on 2014-11-25 at 16:32:

This was the perfect time to use the poll option of Google+

Bernd Höhne commented on 2014-11-25 at 16:32:

it's like fight club ... never talk about option 2, but do it :D

zxzx604176560 commented on 2014-11-25 at 16:38:


hadi alizadeh commented on 2014-11-25 at 16:39:


Ajay Saxena commented on 2014-11-25 at 16:40:


Youri Kool commented on 2014-11-25 at 16:40:

Ik zou voor 2 gaan! :) 

Matteo Luigi Riso commented on 2014-11-25 at 16:40:

Use the poll option to collect all readers' opinion. I'd go through the 2nd way.

Dominic Scatto commented on 2014-11-25 at 16:42:

1 - I believe , when rooting your device, it comes with the inherent risk anyway. So, I'm all for less issues down the road

Prem Suraj commented on 2014-11-25 at 16:42:


We anyway have to grant super user access to apps, no apps can just automatically grab root, so there is no need for the permission..

Kaan Uluer commented on 2014-11-25 at 16:42:


Paul Reioux commented on 2014-11-25 at 16:43:

1 because you will always be at mercy of Google. Just forget about it and move on. I'm a root app developer with published apps.

Stephen Erickson commented on 2014-11-25 at 16:43:


Beau Steward commented on 2014-11-25 at 16:43:

From a technical standpoint, it seems 1 would be the best and cleanest option for maximum compatibility and cooperation. Having compatibility with several different root packages can get messy and can actually shut out any new tools coming out as they would have to define their own permission which no apps request. As a non-developer, I don't really know why it's even needed.

In fact, I've run into an app that refused to request su because it couldn't find the Superuser package (I had SuperSU installed). Clearly there are alternatives to verifying this is here.

What is the drawback of option 1? I can't find one, but maybe I'm just not informed of what the implications are. If there are no drawbacks, my vote is 1.

Marc Grondin commented on 2014-11-25 at 16:44:

I see no need for this permission anyways. It really is of no use like you said. I'm fin with dropping it and forgetting about it

Denver Lobo commented on 2014-11-25 at 16:45:


Nathan Guenther commented on 2014-11-25 at 16:46:


Chainfire commented on 2014-11-25 at 16:47:

+Dario Mehdi +Edu Sanabria +Marc MAJKA +Alessandro Lagares Ferreira +Dominik Bayer +Ralph Bretz +Jose Baez +Royal Saxon +Nasir Uddin +richard schultz +de Rosières 

I am very curious why you would choose option 2 in light of all the drawbacks (going through the exact same issues again as two years ago, the permission system not really being up to it, putting significant extra work-load on root app developers, having no clear benefits, etc). Arguments please.

Chainfire commented on 2014-11-25 at 16:49:

+Matteo Luigi Riso it was not meant merely as a poll, I will ignore all comments that have no reason for their choice anyway.

jason vincent commented on 2014-11-25 at 16:50:

I'd vote #1

Lilly Who commented on 2014-11-25 at 16:52:

Dropping it is probably a pretty good idea. I saw a ton of root apps that didn't have the Superuser permission declared in their manifest, so that isn't really vital. And since rooting is more of a advanced-user thing, that wouldn't really be a problem. Even if one has doubts the app has good intentions, just check the log what it is doing.

Ibrahim Awwal commented on 2014-11-25 at 16:52:

What the heck, why do you all think 2 is a good idea? You think root app developers will actually add a permission for every root management app rather than just say duck it and not declare anything? Let's just forget about this mess and pretend it never happened.

Jon 'jcase' Sawyer commented on 2014-11-25 at 16:52:

1, half root apps dont use it, its got the wrong space, and serves no purpose.

Jobayer Bin Showkat commented on 2014-11-25 at 16:53:

Jason Tschohl commented on 2014-11-25 at 16:53:

1  No need for it.  Most root apps mention that it requires root in the Play Store description.  Joe Average doesn't bother reading permissions in the first place.  Not to mention like you said the app generates a pop-up requesting root access anyways.

Rohan Mishra commented on 2014-11-25 at 16:56:
  1. If we go with 2 it would mean that in order to show permission you would need dozens of permissions for different apps.
Kathryn Radonich commented on 2014-11-25 at 16:59:

I say 1 primarily because it gets rid of a lot of issues now and further down the road. Plus if you're rooting your phone you typically know what you're doing.

Sven Schumacher commented on 2014-11-25 at 16:59:

1 because you really said it! The bad guys will not need that permission.

Anthony Trip commented on 2014-11-25 at 17:02:
  1. Why retro-act all the same BS as before? Can you imagine all the "oes phuks" comments/posts from every uninformed/enlightened user in ALL the possible forums/blogs about how their sh*t just stopped working and dev MUST FIX NOW!!!

AFIK SuperSu is the only Su working almost completely (Nothings 100%) so... This would kind of be a Phu-Q to everyone and "use my sh*t or it won't work right" situation if option 2 was executed?

Beau Steward commented on 2014-11-25 at 17:03:

Could someone who thinks 2 is the best idea explain why?

Jeremy Meiss commented on 2014-11-25 at 17:04:


Oh.. And 1.

Or 2.

Jordan Pitts commented on 2014-11-25 at 17:04:

1, obviously. I don't think I've ever seen a root app that actually uses the permission.

Sushal Penugonda commented on 2014-11-25 at 17:06:

I love your work man !!

Steven McHutchieson commented on 2014-11-25 at 17:08:

1. what's the point in renaming when we can just do away with it?

Marc MAJKA commented on 2014-11-25 at 17:08:

I read your text diagonal and I did not understand that.

I thought it would no longer be able to have super su and be rooted if all the dev does not work in the same direction.

What matters is I can always rooted my phone and I can only thank you for the work you do for so many years!

THANK YOU for all your work !!!

sorry for my bad english

David Waite commented on 2014-11-25 at 17:09:

1, to avoid potentially ending up in the same position as in now and because 2 would require considerable buy in from developers.

Shaun R. commented on 2014-11-25 at 17:11:

1- I already forgot about it.

Victor Häggqvist commented on 2014-11-25 at 17:11:


Pedro Urango commented on 2014-11-25 at 17:15:


Jay Rod commented on 2014-11-25 at 17:16:

I vote for whatever +Justin Case​ and +Chainfire​ see best. Considering these 2 know a craptacular amount more than me when it comes to code.

As long as individuals like them are still in the game...I'll be their sheep!

Sagar Mulik commented on 2014-11-25 at 17:17:

Just say bye to every permission

choosing 1

David Poole commented on 2014-11-25 at 17:17:

This screams out to use a Google+ Poll...

Anurag Nirmal commented on 2014-11-25 at 17:18:


darken commented on 2014-11-25 at 17:20:

I vote for option 1.

While declaring a root permission was good for transparency, it's not a security concern as with the other permissions. In contrast to "normal permissions", declaring "ACCESS_SUPERUSER" doesn't necessarily mean that app will get it.

While the initial idea of declaring the permission was well intended, adoption was bad and AFAIK no root managment tool did ever enforce this. As it wasn't enforced, the transparency argument for declaring it is moot, as adoption is not required.

Requiring different permissions (Option2) for the same resource (root access) would just introduce more fragmentation which we already have enough off, especially in the root community.

In a perfect world root access for apps should be transparent, working independently of what root tool is used, while this is already not the case, we should strive to achieve it.

Anmol Malhotra commented on 2014-11-25 at 17:22:

1 because evolution is always good... Why declare a separate permission when we will be the ones granting the app root access in case it asks for it.

Brian Hughes commented on 2014-11-25 at 17:24:


Chainfire commented on 2014-11-25 at 17:24:

So far, nobody voting 2 has actually stated why, and all whom I know to be developers have voted 1. Interesting.

Ameer Dawood commented on 2014-11-25 at 17:25:


I never realised a practical usability of the permission, anyway.

Julio Novoa commented on 2014-11-25 at 17:25:


Doug Lynch commented on 2014-11-25 at 17:26:

1 - This seems to be the best answer for less issues in the future

Manuel Müller commented on 2014-11-25 at 17:26:


Emmanuel Elizalde commented on 2014-11-25 at 17:26:


Roman Ettlinger commented on 2014-11-25 at 17:29:

1 will save much hasssle and has no real drawback

Sayan Goswami commented on 2014-11-25 at 17:29:

Option 2 is the way to go.I think it is officially time that google includes root access on their devices is the Nexus lineup.

darken commented on 2014-11-25 at 17:31:

+Sayan Goswami Option 2 doesn't have anything to do with Google adding official root access. Read the post again.

Josh Hayes commented on 2014-11-25 at 17:33:


Tristan Leterrier commented on 2014-11-25 at 17:34:


Anthony Trip commented on 2014-11-25 at 17:35:

+darken​ +Chainfire​ IMHO, you two being the most "top-notchiest" Devs I've had the pleasure of using both your hard work (SuperSu PRO, and SD Maid PRO), I believe furthering any consideration for "2" has justifiably been stamped out (unless there's hard argument saying otherwise).

that's all... Carry on! I count on your hard work, quit dawdling on G+... Lol

Christopher Cote commented on 2014-11-25 at 17:36:

Who's original idea was it to have this permission system for root apps? +Koushik Dutta ?

Deimos Krijgsman commented on 2014-11-25 at 17:42:

Dmn please do 2

Sayan Goswami commented on 2014-11-25 at 17:42:

+darken​ I was just suggesting an alternative! Get it?

Aamir ck commented on 2014-11-25 at 17:44:


Brian Azar commented on 2014-11-25 at 17:56:

1 : the root management app already produces a popup which requires action when an installed app requests Root the first time; declaring it in the manifest doesn't seem to add any extra layer of security for me. If you're rooted, you're taking responsibility for keeping track and allowing access to your system, you should already know what apps are root-enabled apps. Even if an average non-rooted user installs a root app, the permission is useless to them (and possibly confusing if they aren't aware of "root").

Mike Emery commented on 2014-11-25 at 17:56:


David Bivens commented on 2014-11-25 at 17:57:

1. I know I'm bucking the trend here, but #2 sounds like a ton of trouble for little—if any—real gain. To make #2 work, you'd have to set up a registrar of third-party (and root management) apps, which doesn't sound workable, nor likely.

Alexis DJM commented on 2014-11-25 at 17:59:


Alexander Terry commented on 2014-11-25 at 17:59:

Should have used a poll.

Kastriot Ramani commented on 2014-11-25 at 18:02:

You should've poll this. 2

Paul Reioux commented on 2014-11-25 at 18:02:

+Chainfire because developers need to deal with things in pragmatic terms and make their apps just work.

Andrew Price commented on 2014-11-25 at 18:05:


Ruchir Trehan commented on 2014-11-25 at 18:06:

Definitely 2.

Ataliba Teixeira commented on 2014-11-25 at 18:07:

I believe 2 is the best option

Ādi-Kartā Dāsa commented on 2014-11-25 at 18:09:


Ricardo Varela commented on 2014-11-25 at 18:09:

If the option 1 means there won't be root in the future that's a no for me, I would go for the option 2 no matter what.

Christoph Planken commented on 2014-11-25 at 18:10:


John Gomeringer commented on 2014-11-25 at 18:10:


Andrew Dodd commented on 2014-11-25 at 18:11:

Everyone voting 2 didn't state why...  And I'm guessing they did so as far as irrational fear.

Of all the responses I've seen, in addition to what you've stated, +Prem Suraj 's comment was the most important one:

Since SuperSU always prompts before granting access anyway, this permission is redundant - It never really did anything to protect anyone anyway.  All it did was maybe give some people an extra warm-fuzzy - but given a choice between "warm fuzzy but broken" and "working" - I'll choose working.

Martin B. commented on 2014-11-25 at 18:11:

1. If it's causing problems, then just drop it. You are only one developer, who is maintaining SU access management tool up to date, so in my eyes, you can dictate the rules.

Deozaan Games commented on 2014-11-25 at 18:14:

I'd say 1 because as I understand it that means greatest compatibility for all root apps and avoiding a similar problem later when/if Google changes something again a couple years down the line. If it's not enforced and there's no punishment for NOT doing it, then as you said, there's any not much point since the sneaky/malicious devs will just hide it anyway. The path #2 leads down sounds like too much ongoing maintenance for very little practical gain.

Amrinder Singh commented on 2014-11-25 at 18:14:


Captain Throwback commented on 2014-11-25 at 18:14:

Clearly, 1 is the obvious choice. Perhaps if it had been implemented correctly in the first place, it would be worth considering finding a way to keep it. But as it is, the permission is only optional for root apps, and most don't even declare it. Let's pretend it never happened.

Paul Reioux commented on 2014-11-25 at 18:17:

TBH, root access is a very small component of a typical Android root app.  It should be straight forward to obtain and easy to use.  Developers have many other things to worry about their apps functionality and bug fixes.  Root library should be robust and universal.  The last thing a root app developer wants to deal with is compatibility issues with root libraries and more permissions.

David B commented on 2014-11-25 at 18:19:

Definitely 1, as all the hassle of trying to get loads of other developers to change their apps for no benefit is a distraction you don't need.. Plus as you say, many people saying 1 have given a reason whereas no one saying 2 has, so I think you have your answer!

Simon Sickle commented on 2014-11-25 at 18:19:

1... There's no chance I'll be calling it for 5 different root managers in my apps. Each rom has their own usually... So this breaks compatibility. What's the point. Nuke it +Chainfire

Tomas Todorov commented on 2014-11-25 at 18:21:


Beau Steward commented on 2014-11-25 at 18:23:

I'm getting the impression the 2 votes are spam or trolls. Or they don't understand how this stuff works (one person stated the fear of no more root if it's removed? that's not true...).

Paul commented on 2014-11-25 at 18:24:
  1. I take comfort in knowing that a developer cares enough to request a permission like SuperSU transparently. Two years ago seemed like a drama but in reality, it really wasn't.
Ralph Lopez commented on 2014-11-25 at 18:25:


Kevin Rombold commented on 2014-11-25 at 18:27:

1... Because to often I get the message to grant permission, but after that the app is still searching for SuperSU... (Helium often makes it worse with updates for their app and then chainfire has to fix this, thats not fair and he does great work for all root Users

Arpit Saxena commented on 2014-11-25 at 18:28:

2 because I think it's easier way to do it

Joshua Holland commented on 2014-11-25 at 18:33:

1; I presume the new (ish) Play design doesn't show the permission anyway, and 2 is a nasty horrible hack.

Jorge Nieves commented on 2014-11-25 at 18:33:

I'm stating that #1 should be the better option. Trying to get every root developer yo adopt #2 will be a hassle and since you are the one that controls the SU side here you should do what's best for you. All in all #1 is better in the long run.

SavanTorian commented on 2014-11-25 at 18:34:

To get rid of all issues, take the 1 - train ;)

Russell Richardson commented on 2014-11-25 at 18:37:
  1. I'd say just remove it... I mean, I generally know when I'm installing a root app, and for sure will know when the su request comes up.
Eduardo Ribeiro commented on 2014-11-25 at 18:38:


Because 2 could cause one root app don't work with all root daemon, and that's ridiculous, root is root, no matter what daemon is managing the su.

And because it's a waste of time for devs declare one permission for each su daemon.

Oh God, 1 please!

Bogmonster81 commented on 2014-11-25 at 18:43:

option 1. Ideally all other devs would respect a name change but as we all know they won't, so good sense suggests it has to go to avoid future problems.

Stuart Hicks commented on 2014-11-25 at 18:45:


Nick Hernandez commented on 2014-11-25 at 18:46:

Option 1 sounds like the easiest solution, I agree with you that the prompt comes up when an applications attempts to use root so it isn't really necessary if it is going to cause an issue.

Bankanidhi Sahoo commented on 2014-11-25 at 18:46:
  1. I don't understand the technicality but I always wondered why I would permit when I know I am using the root app for some purpose. I have never denied a permission in my 3 yrs of su usage. Thanks
Raffael Willems commented on 2014-11-25 at 18:47:


Wug Fresh commented on 2014-11-25 at 18:53:

1 - The SuperSU grant access prompt from a root application is all that it is needed.  Like you mentioned, when installing an app from the playstore, as the end-user I already know what I am getting into.

Stefan Mai commented on 2014-11-25 at 18:53:

ACCESS_SUPERUSER was a nice idea in theory but never really had any value beyond the purely symbolic. Toss it and don't look back.

Ajin Jude commented on 2014-11-25 at 18:55:

1 because 2 is messy - convince all root developers to declare a new permission for each root management app? Never gonna happen.

I don't think we gain anything by the existence of the permission either.

Jason Rai commented on 2014-11-25 at 18:57:

G+ Supports polls btw.  Would have been good for this.

Mangesh Desale commented on 2014-11-25 at 18:58:


Captain Throwback commented on 2014-11-25 at 19:00:

+Jason Rai does it also support explanations within specific votes? Because +Chainfire​ already stated that he didn't do a poll because he wanted to hear reasons for the vote.

Stephan Schmitz commented on 2014-11-25 at 19:07:
leonardo vivas commented on 2014-11-25 at 19:09:


Daniel Cheng commented on 2014-11-25 at 19:09:


You have gave the reason -- you got the root prompt already .

If different su declare different permission, as an app developer, which one i should declare?

No. It cause more trouble then it solve

Nikhil Wanpal commented on 2014-11-25 at 19:15:


Permissions are for letting the user know what all a certain app is going to access on their phone. While I agree that access_superuser certainly should be a permission, if it is becoming this messy, drop it. And it's anyway a controlled access, unlike other permissions.

What's up with people voting for 2, at least someone state why!

Gilles DESSARCE commented on 2014-11-25 at 19:16:


Christopher Cote commented on 2014-11-25 at 19:18:

Where is +Koushik Dutta​ when you need him! Running off on another another project or yacht :) I kid. We had such enthusiasm and idealism when he came to to the scene with #Superuser. I guess some of that enthusiasm has died along with the now walking dead ACCESS_SUPERUSER.

Pierre-Francois Renard commented on 2014-11-25 at 19:18:


Horst-G. Thiel commented on 2014-11-25 at 19:24:

3 :-)

Mike Ingelheim commented on 2014-11-25 at 19:26:


Stephan Schmitz commented on 2014-11-25 at 19:29:

So far, I haven't seen any (valid) arguments for "2".

As for your summary above, +Chainfire​: I think it's rather logical than surprising. Why? Kind of like +Paul Reioux​ said - most developers, most of the times, will obviously rather go for the most efficient and compatible solution. And, (product-specific) workarounds will always be avoided whenever possible.

The top arguments, IMHO, have been named already. No matter of its initial intend, the ACCESS_SUPERUSER permission

1.) in its current implementation is broken (as of 5.0)

2.) is messing in a context where it shouldn't mess around

3.) 's initial intend is obsolete anyways, since adoption wasn't strict and neither enforced.

Thus, its neither logical nor economical to reimplement it. And, IMHO, this is exactly how probably any developer evaluates the situation. And, in return, this is why all devs so far voted "1".

PS: Sorry for my lack of English, but I hope you got what I mean.

Tommaso Mascaro commented on 2014-11-25 at 19:30:

1 as you said (+Chainfire​​) "neither options kills root" and is simpler to forget about that permission; and in both ways some developers have to change something.

Abdulhkeem Alhadhrami commented on 2014-11-25 at 19:32:

2 All the way

Daniel Cheng commented on 2014-11-25 at 19:33:

Is there an option 3 - have all su packages signed with same key?

Kostas Kottarinos commented on 2014-11-25 at 19:36:


Boris Maček commented on 2014-11-25 at 19:37:


Eduardo Soares commented on 2014-11-25 at 19:37:

I never saw a good reason for this to exist, so number 1.

Since the user is always prompt to permit or not (at least once), the permission only gives useless redundancy. 

Stephan Schmitz commented on 2014-11-25 at 19:39:

+Daniel Cheng​ Ehm,... nope.

Ozhan commented on 2014-11-25 at 19:40:


Kevin Barry commented on 2014-11-25 at 19:40:


I've never been a fan of the permission and have thus far avoided adding it to Nova Launcher with only like 2 requests from users to add it. For an app that absolutely requires root it'd actually make more sense to have a uses-library so non-rooted devices can't even install/rate the app (though maybe adding a library would be hard for some types of root?). For an app like Nova Launcher, which barely uses root at all*, declaring the permission is misleading as users would expect root to be required and wonder why a launcher needs it. Having the prompt when they activate an option that needs it is a much better experience.

I also would not want to be chasing down the different permissions for the different superuser apps and it potentially creates a form of lockin as a new superuser app either doesn't require the permission so it might be perceived as less secure, or it requires it and no apps support it. 

  • In Nova there is an option to hide the status bar clock that requires root. It's off by default. It also can be used for widgets in the drawer on Android 4.0, but it's not needed in 4.1+ which is where most users are.
Luca Cassani commented on 2014-11-25 at 19:42:


Peter Hilbring commented on 2014-11-25 at 19:42:


Antonio Balena commented on 2014-11-25 at 19:46:


Jonatan Steuernagel commented on 2014-11-25 at 19:47:
  1. I never cared about the permission anyways because I think it is pointless. I normally know what I'm installing and if an App wants root without telling me SuperSU is going to ask me for root anyways.
Roger Waters commented on 2014-11-25 at 19:50:
  1. Serves no real purpose, most root apps don't use it anyway, and 2 has the possibility for more problems down the road.
Ale Corso commented on 2014-11-25 at 19:52:

2 for me

SuperBROKEN81 commented on 2014-11-25 at 20:00:

I say 2. If you go with option 1, how do you deny permissions? I don't want any app automatically gaining root.

What if I want an app to have root for 15 minutes? Does option 1 change the way su works right now?

I remember on the s3,s4, some of the Verizon apps started to ask for root permissions. The way su works right now I was able to ignore it. If you go option 1, the Verizon apps would have gotten root access. 

DJ Anderson commented on 2014-11-25 at 20:01:


Jaivinder Sidhu commented on 2014-11-25 at 20:05:


There's a lot of popular root apps that don't request it so there's no point making things more complicated for something that isn't very popular anyway. I don't mean offence to +Chainfire​, but SuperSU isn't the only root management app out there (its the one I use) but there's also superuser as well as the one built into CyanogenMod and Paranoid Android etc. If it was a more popular feature then it would be worth the time but for now it isn't.

Jared Solomon commented on 2014-11-25 at 20:15:
  1. It's nice to have the option to use it, even if you personally won't. Also, it'll be nice to see what developers no longer care about their apps when they don't get updated.
Orvenzon Quiros commented on 2014-11-25 at 20:19:


Rick van Schijndel commented on 2014-11-25 at 20:21:

1 the notification of supersu / other apps is sufficient to me

Robert Sprunk commented on 2014-11-25 at 20:30:

I would've liked that in some distant future the root dialog would not pop up if the app declared the permission. This is just how permissions work.

In favour of that: Let's try option 2 until Android 6. ?

Maybe enforce the use of the permission starting 1.1.15?

That's enough time for those devs who update their apps. Those who don't won't do it in two years.

Sinan Çetinkaya commented on 2014-11-25 at 20:33:

Of course 1

ACCESS_SUPERUSER is only good to know that the app uses root. It isn't worth the problems it causes.

Aunty Anne commented on 2014-11-25 at 20:34:

1 seems the easiest way to me.

Prateek Malik commented on 2014-11-25 at 20:34:

Dear +Chainfire​​, firstly immense respect for your diligently consistent efforts for transparency in development. Imo 1 is a better option because there are many apps for which root devs may not continue development or dormant projects.

In the present scenario it is definitely a sane choice to forget it.

Jordi Lobo commented on 2014-11-25 at 20:34:

2... forever

Alex Minnucci commented on 2014-11-25 at 20:48:


You're going to find out when it requests root (in the skin chance you didn't already know)

Pietro Palladino commented on 2014-11-25 at 20:48:

1, the second option would require every developer that would like to use root to declare permissions for every root management. If the root management asks for root with a popup is enough and very close to a declared permission.

Séamus Wiseman commented on 2014-11-25 at 20:50:

I vote 2. From a business security perspective, permissions are imperative.

Mikey B commented on 2014-11-25 at 20:52:

I can't see the downside of option 1, but 2 would create a lot of hassle, require other devs of root apps to buy in to this way of doing things, and generally create a mess.

So I vote for the cleanest, simplest option: 1. But what are the downsides of option 1, because I can't really see one?? 

Sarko Mhamad commented on 2014-11-25 at 20:53:


Nic Finn commented on 2014-11-25 at 20:55:

Maintaining this permission set would be awesome, if root developers actually used it. I think getting rid of it altogether isn't necessarily a bad thing, but it does help some users who root their devices but still install apps that maliciously attempt root access.

I think that going with 2 would be a good option, but only if you move toward applying this permission check by default. In fact, if you go with option 2 it would probably be best to force users to flash a zip or something (make it slightly more difficult) to skip this permission check. I say that because if it's enforced on the majority of devices, it will force root apps to add the permission request. Otherwise it ends up at this same point and nothing happens (just an extra permission that app developers ignore).

I really think this is a good idea, especially since so few users pay enough attention when they get the root warning.

Personally, I think my interpretation of option 2 is too much work and to relies on developers paying along.

Option 1 makes the most sense. The pop up notifies users of the root request, and most users know when an app requires root.

Goran K commented on 2014-11-25 at 20:57:


Ryan Smith commented on 2014-11-25 at 21:05:


Cesar Andres commented on 2014-11-25 at 21:08:


Francisco Franco commented on 2014-11-25 at 21:08:

Absolutely (1). Root users never needed a permission to know that an app makes use of Root calls, it actually proved to be a bit confusing to some users demanding us developers to add that permission without actually knowing why and what for. Just forget that it ever happened, we couldn't care less about that crap.

+Paul Reioux does have a point, we should focus on app quality and not on some weird ass Root compatibility as it's something implicit when using Root apps.

Kill it with fire.

Vaughan Swart commented on 2014-11-25 at 21:10:


Dave Oxley commented on 2014-11-25 at 21:11:
  1. App developers shouldn't need to add a permission for every single su app. This will just prevent any new su app ever being possible or worse different apps forcing the use of a specific su app.
swawif commented on 2014-11-25 at 21:13:

I'm going with option 1. It's unnecessary to have that permission. And, not all developers are willing to update their app for this. Some app that are actually good, don't have an active dev behind it to support it with updates.

David Bivens commented on 2014-11-25 at 21:15:

+Chainfire​​ I suspect many of the votes for #2 are from folks skimming the original post and thinking choice #1 == no root access. 

Aedon Colino commented on 2014-11-25 at 21:18:


Wellington Adami commented on 2014-11-25 at 21:19:


Andrew Dodd commented on 2014-11-25 at 21:21:

+Seamus Wise I don't know of a single business that allows rooted devices.

And you seem to be forgetting that SuperSU prompts you before actually granting root access to an app.  That prompt is NOT going away - only the redundant "permission" which never really worked/did much in the first place.

Berco Bosker commented on 2014-11-25 at 21:27:

1, because of what you wrote yourself between "further more, it is not really usefull" and "without repercussions". I've wondered about the usefulness of this permission since kouch proposed it and just considered it good manner ever since, nothing more.

Mikko Löytynoja commented on 2014-11-25 at 21:27:
  1. The reasons have been said already. It makes no sense that every app using root would need to add permission for every root app.
Chainfire commented on 2014-11-25 at 21:35:

Tallying up: every commenter of which I know they are actually a developer has voted for removal; aside from that, for the voters actually giving reasons for their vote, the removal votes easily win from the renaming votes. Consider the permission removed. Case closed.

This post is over a month old, commenting has been disabled.