yashsingh1/xdaforums huggingface dataset:
[SuperSU] Chainfire:
Interesting. I've always wondered what that fix permissions script was for. I've been around in Android for quite some time, and the single time I have ever tried that script in CWM was back on the Galaxy S I9000, and havoc ensued. After that, I have never touched it again, nor was I ever advised by anyone to use it. And yet, it seems people actively use this feature...

Either way, I'll see if I can discover the problem with the script... quick search not turning anything up, but I have to run for now (time to sport)
[SuperSU] Chainfire:
Yeah, still not sure about that. The rest of the features are not related to multi-user, so technically there's nothing stopping me from just waiting with multi-user until the next release. After some thinking, only 9% of users are on 4.2 anyway, and that includes phones. Only tablets have the multi-user function - and I'm going to guess that's going to be less than 5% of users. How many of those users even use multi-user ?

It may not actually make any sense to wait for multi-user to release SuperSU v1.00.
[SuperSU] goodtimes50:
I'm having the notification loop issue and I frequently run TWRP's Fix Permissions function. I have no idea how similar it is under the hood to CWM, though.

I checked the permissions Chainfire posted on the previous page and supersu.cfg permissions are 600 (I'm not sure what "user root" and "group root" mean or how to check them). However, when checking /system/xbin/su it appears that it's permissions are 747/rwx r-x r-x (I believe 06755 is equivalent to 644/rw- rw- ---, right?).
[SuperSU] MaestroOrg:
Okay, so it sounds like 1.00 will potentially resolve the problem. I'll hold off of any further tinkering until then.:)

Earlier today though I tried uninstalling all updates, clearing the cache, etc. I even tried using the Reinstall option under Cleanup, but the app never closes, and the 'working' windows that appears saying the app is uninstalling only appears for a fraction of a second.

But it sound like the HTC fix in 1.00 will resolve the notification problems, so I can wait for now. :D
[SuperSU] polobunny:
Here's cyanogen thread about it:

http://xdaforums.com/showthread.php?t=522935

Edit: And the script from github

https://github.com/CyanogenMod/android_bootable_recovery/blob/jellybean/utilities/fix_permissions
[SuperSU] AlxMAX:
I didn't know there were firmwares which kept the apps from writing to /system but it makes sense. For the moment, I don't know if CyanogenMod works on the HTC One XL phones which were updated to the latest firmware (I've read there were some problems with the screen). Anyway, I would like to emphasize that SuperSU.apk and su were copied from an up to date phone (with CyanogenMod 10). My question is why does SuperSU report there was a newer version? Moreover, why does it exit if I choose not to do the update? The applications asking for root work perfectly! In the meantime, I have installed Superuser (with its version of su) and it works impeccably.
[SuperSU] Johan1976:
Sv: [04.12.2012] SuperSU v0.99

Oh noo :)

I'm one of the less than 5% users with multiuser tablet.

Is it a pain to get multiuser support to work? I would love to see this feature due to some few apps like for example stickmount and sixaxis.

Skickat från min HTC Desire via Tapatalk 2
[SuperSU] osm0sis:
rwxr-xr-x is 755, su should have 06755 which adds the s for rwsr-sr-x. 600 would be rw-------.

you can check the user and group for the files in Terminal Emulator with busybox ls -al and if they need to be changed then su chown root.root

Try fix_permissions from CWM 6.x? I've got no issues with it. You're right though the version is still at 2.04:

https://github.com/CyanogenMod/android_bootable_recovery/blob/jellybean/utilities/fix_permissions

Same for TWRP:

https://github.com/TeamWin/Team-Win-Recovery-Project/blob/twrp2.4/prebuilt/fix_permissions.sh
[SuperSU] polobunny:
No, because as you said, both are v2.04, and honestly the incremental backups function of CWM v6.x is absolute #!@&.

Nevertheless, as mentionned earlier, it shouldn't change anything and SuperSU shouldn't get affected by such a widely used script if SuperUser by chainsDD doesn't.

Edit: Sorry if the tone sounds severe, that's not the point.
[SuperSU] osm0sis:
Hey if you want to troubleshoot sometimes you have to try stuff anyway, even though it might not make sense, just to rule things out.

tar is default backup format again in 6.0.2.3, and incremental was always optional, so that's a silly reason not to use it.
[SuperSU] polobunny:
As mentionned though, falling back to CM10 based on JB 4.1.2 fixed things for me. And as usual, I ran fix perm in recovery. I doubt the fix permissions script is to blame here, hence my question to other if they are running a JB 4.2 rom.
[SuperSU] osm0sis:
Right and my thought is that CWM 6.x is for JB4.1+, and CWM 6.0.1.5+ is for JB4.2+ so you using CWM 5.8 with JB4.2 could still somehow be a factor here and that's why rolling back fixed it, as unlikely as that may be and you may believe it to be. We're on the same side here, friend, all I'm saying is there is always a bigger box to think outside of and you shouldn't rule anything out prematurely. :):good:
[SuperSU] claytonjn:
Re: [04.12.2012] SuperSU v0.99

I've never ran fix permissions either, the only reason I did this time was it was part of the app install script and it flashed directly from the app. I know SOMETHING in flashing that caused the notification bug because I flashed it, got the problems, fixed the problems, and tried flashing again and they immediately came back. I'm only speculating that the fix permissions script is the issue because I've never done it before and haven't since, and I've had 0 issues with SuperSu otherwise. I think it's a combination of the 4.2 Android version and running fix permissions that breaks it.
[SuperSU] goodtimes50:
I've experienced the notification bug on both AOKP 4.1 and the custom TW 4.1 ROM I'm running now. In both cases I've used TWRP's Fix Permissions at one point or another.
[SuperSU] polobunny:
I don't think that's a right assumption, but I'd be surprised if it caused problems once again only with SuperSU and not with SuperUser. And you know, not with any other piece of software flashed ever.

I really don't think the recovery is to blame here, we're just getting farther from the source of issues IMHO.

Edit: Your edit makes more sense. But still points out to the fix permissions script rather than the recovery.

Thanks for the input.

I don't know well enough AOKP to know if 4.1 is an in-house version number or one related to Android versions. Does 4.1 mean Jellybean 4.1?
[SuperSU] claytonjn:
Re: [04.12.2012] SuperSU v0.99

I haven't used CWM in well over a year, but I know TWRP had to be updated to be compatible with 4.2 ROMs due to the new multiuser file structure. Even if the recovery version isn't causing this version it still may be a good idea to update it.
[SuperSU] polobunny:
Will look into it, I believe some newer versions of CWM v6.x also offer old style tar backups à la v5.x instead of the incremental method. Might not be a bad idea as you said.

Mostly looking forward SuperSU getting fixed though. :p
[SuperSU] claytonjn:
Re: [04.12.2012] SuperSU v0.99

You should be able to fix it yourself. Wipe app data, reboot into recovery, flash SuperSu zip. You'll have to set your preferences again and grant apps, but the notification bug should be fixed.
[SuperSU] polobunny:
No no, my problem is fixed, I moved back to JB 4.1.2 and woop, no double prompts anymore. But the problem shouldn't arise in the first place.
[SuperSU] goodtimes50:
Sorry, yes. They're both JellyBean 4.1 ROM's.
[SuperSU] claytonjn:
Re: [04.12.2012] SuperSU v0.99

:banghead: I knew you said that, I'm in class so only half paying attention. But no, it shouldn't happen in the first place.
[SuperSU] osm0sis:
All 6.x versions offer old style tar as the optional backup format you can switch to, though incremental was default for awhile. In 6.0.2.3+ old style tar IS the default again. :good:
[SuperSU] polobunny:
Alright so rom (4.1/4.2) isn't the issue, recovery version/model isn't the issue (TWRP/CWM), but fix permissions script stays the same across all, and we've all used it to get a problem.

What is strange however is that I use fix permissions script diligently after flashing a ROM and I did it also after flashing back to JB 4.1.2, yet I don't have the SuperSU infinite notification loop. Something is fishy, maybe the script is just one part of the cause of this bug.

It's all good, I'm at work myself. ;D

Edit:

Thanks for the heads up. Will definitely update then. I don't believe new is always better, but I don't think it will hurt this time.
[SuperSU] -SlenderMan-:
Re: [04.12.2012] SuperSU v0.99

Amazing! Supported you by buying the donator version!

Sent from your backyard...

Slender watches what you do...
[SuperSU] Chainfire:
I've flashed TWRP to my Nexus 7 (on 4.2) and used the fix permissions script, but it did not induce the notification storm. SuperSU also overwrites supersu.cfg and corrects the file permissions at boot, at least it did for me here. That could still cause a notification storm at first boot, but if a reboot doesn't fix it (as I believe you guys have said) than the supersu.cfg permission does not appear to be the problem right now, but to verify ...

I really need somebody who is suffering from the notification problem to execute the following commands with adb on their device:

adb shell ps | find "supersu"
adb shell ls -l /data/data | find "supersu"
adb shell ls -l /data/data/eu.chainfire.supersu/
adb shell ls -l /data/data/eu.chainfire.supersu/files/

(On Windows... for Linux/Max, replace "find" with "grep" in the first two commands)
[SuperSU] polobunny:
Is it possible for certain people the permissions aren't being fixed by SuperSU though? Which would keep causing a notification loop?

On a side note, moved from CWM to TWRP last night. Wanted to update to latest CWM for the Nexus S. Turns out all the last ones have a USB mounting bug where you can't mount your storage in recovery. Got fed up with this bull and flashed TWRP with a custom theme. Ain't ever looking back. Sad that CWM seems like the de-facto custom recovery for most people, because honestly it doesn't compare.
[SuperSU] Chainfire:
That is why I'm asking someone who has the problem to execute those commands to check those permissions so I can see if that is where the problem is.

As for CWM, most people slowly seem to be seeing the light ... I myself have mostly moved away from custom recoveries altogether though.
[SuperSU] polobunny:
Ah okay, wasn't too sure about that. Hopefully someone else can help, sorta wish my problem didn't get fixed. :p

Moving away from a custom recovery is more or less a possibility with the Nexus S. It just makes everything easier, and the NS is nearly unbrickable when staying within the confinement of the recovery as opposed to using ODIN or similar.
[SuperSU] scarecrow420:
Hi Chainfire, just wondering if you saw the couple of posts/suggestions that asked if you could make in the next version if you say "No" to update, it doesnt close the app. In my case root is working OK and apps are granted superSU just fine, however whenever i open SuperSU to change settings it tells me i need to update the su binary (but im already up to date). Due to my HTC JB firmware if I say Yes the phone reboots. Buit if i say No the app doesnt open. Therefore i cant change notification settings etc. I dont want to flash a custom ROM so it seems im stuck with the system write issue, but wondered if you made it so the app still opens whether you update su binary or not, then I could still change settings?

Also regarding the check for su binary, is the fact mine says it is out of date something to do with the system write issue, or is there a new binary that came after SuperSU .99 ? If so, where can I get the binary from? eg where does SuperSU check against to see that there is a newer version?

Thanks
[SuperSU] Chainfire:
This has been discussed repeatedly and at length in this thread. I even replied to your previous post just yesterday. If you search this thread for "reboot" (see "search this thread" just above the first post on this page) you'll find at least a few posts related to your question. Had you done that already, it would have probably taken you less time than writing the above post to find the answer. It would have certainly saved me the time to write this one.
[SuperSU] goodtimes50:
So lately I haven't been getting the (seemingly) infinite looping, but it does loop notifications for a period of time. I doubt multiple apps are requesting root repeatedly in quick succession, but I suppose that's a possibility. In the past I've noticed that the SuperSU log would only show a single entry for each app after I witnessed the notification loop. However, now it appears that a few apps (KTweaker, BBS, etc.) have multiple entries in the log. Whether this is a flaw in SuperSU or the apps themselves, I don't know.

I've attached the output of the adb commands and a screenshot of the SuperSU log (note that there are about 10 more entries for KTweaker than what's shown).
[SuperSU] Chainfire:
Those file ownerships and permissions look fine to me ...

The su binary may try multiple times to notify the user or start the UI in case of failure, however the log is only written once. If there are two entries for an app, that app has called su twice, that's a given. If the number of notifications is somewhere along the lines of the number of log entries, then that is perfectly expectable behavior. If it annoys you, just turn off notifications under settings.
[SuperSU] polobunny:
I can relate that whenever I got looping notifications, only 1 entry was visible in the logs, not many. Seemed to happen a lot with SManager Ads (Free version) to launch my startup script.
[SuperSU] scarecrow420:
Hi Chainfire, Im sorry if you feel I hadnt put effort into searching/reading before posting but I assure you I have definitely read the other posts in this thread including your reply to my original post. There is plenty of talk about the binary update failing and phones rebooting and I understand completely this is not a problem with SuperSU.

What my post is about is that I havent actually found anywhere where you address the feature request to allow the SuperSU app to launch even if you say No to updating the binary! Im aware the reboot issue is a HTC JB thing and outside your control, the focus of my post is more so making the point that in this situation (or any situation where the user chooses not to update the binary) they would still benefit from being able to enter the app and change the settings. Currently the app exits if you say No to updating...

I appreciate the level of detail you provided in your reply, about which files are involved, where they live and what their file permissions need to be etc, however I dont think I have seen anything talking about how SuperSU knows there is a newer binary and where it gets it from... my hope was to build a flashable zip of the new binary so that SuperSU doesnt think it wants to update it anymore.

EDIT OK i did find where you said that you wont do this because if the binary and app are out of sync it will cause problems. You do make mention of a possible S-ON version which Im assuming is still just a "maybe" you are looking at one day. I'd still like to try and get the latest binary and flash it myself which might help my situation. Unless of course, my binary reall is up to date but something else about the S-ON device means that SuperSU just THINKS it isnt up to date. I am contuing to search but it's hard to find the right keywords
[SuperSU] polobunny:
Re: [04.12.2012] SuperSU v0.99

V0.99 is the latest version.
[SuperSU] Rotary Heart:
Hi

I have an issue that I first thought it was terminal emulator error, but now I'm pretty sure is more a SU error. When I type su command I can't see nothing (like the normal input #) but if I type any command it works. Unfortunately this is not letting me use ubuntu on my phone.

Why I think is SU error?

Well because I uninstall it and try it with super user app and now its working fine, please if this is an app error, could you fix it? or can I help with anything? (I still prefer SU app ;))

Thanks

---------- Post added at 02:30 AM ---------- Previous post was at 02:05 AM ----------

BTW I'm running a galaxy nexus with paranoid ROM 4.2+ I'm running the SU app that comes with the ROM.
[SuperSU] bedtime_with_the_bear:
Re: [04.12.2012] SuperSU v0.99

Have you configured SuperSu to log the output of commands?

If so, that's your problem.

SuperSu is working as configured, but all the output you expect to see, such as the # in the root prompt is being redirected to the SuperSu log file. If you disable full logging, it will work the way you expect.
[SuperSU] Rotary Heart:
Didn't think that this was the kind of issues that it could make.
[SuperSU] shaggyskunk:
Re: [04.12.2012] SuperSU v0.99

Yeah not sure why, but since the beginning everything that I saw, said to set logging to Access Only, otherwise you may have problems.
[SuperSU] bedtime_with_the_bear:
Re: [04.12.2012] SuperSU v0.99

Logging everything redirects all the output of commands to SuperSu so that it can append it to the logs. In practice what this means is that commands (even "su") appear to have no output at all because it all goes to the log.

It gives the impression that the command isn't working properly when in fact you just can't see the output. If you check the SuperSu log, you'll find the output of your commands there.

It's a big problem with apps that assume that they can process the output of a command, since the command will appear to do nothing, which is why the default setting and the recommendation is to log access only.
[SuperSU] Chainfire:
That's only partially correct really. Input/output is still as normal. Only apps that process unholy amounts of I/O can get caught in a problem, as well as apps that do terminal emulation, and that has to do with the nature of terminal emulation, not with the logging itself. By far most root apps have no issue at all with the logging and will receive their output just fine.
[SuperSU] bedtime_with_the_bear:
Re: [04.12.2012] SuperSU v0.99

Thanks for the clarification Chainfire. :o
[SuperSU] Chainfire:
This look is definitely starting to grow on me, I know prefer it over dark theme and SuperAndy (both theme and icon will be configurable in 1.00)
[SuperSU] osm0sis:
Will "PIN every time" be an option in 1.0? It'd be great to be able to lock certain sensitive root apps.
[SuperSU] m-cat:
Re: [04.12.2012] SuperSU v0.99

Hey, through a series of small events on my phone I came to the conclusion that my SU needed updating. After finding out that it was included as a system app and not accessible from my app drawer I went to the store and tried updating. After it downloaded and tried to install the notice that can be seen on the included picture came up. Since, per the store description, I don't want to uninstall, and since I can't uninstall due to the fact that it doesn't show up in Titanium BU. What does one due to correct this issue? Thanks for your work and awesome apps!
[SuperSU] DarkhShadow:
Re: [04.12.2012] SuperSU v0.99

99% sure that means the SuperSU you have now is modified

Sent from my Jelly Nexus 4
[SuperSU] :
Re: [04.12.2012] SuperSU v0.99

You just have to erase it with root explore and reinstall.

Sent from my GT-N7000000000 using Tapastalker 2
[SuperSU] Chainfire:
I am still considering adding it.

My idea is to configure it through the UI only (not through the popup), and it would popup a PIN everytime that app asks for root. After entering the (correct) PIN code, you'd get a box where you can select from a few options, for how long access would be granted (minutes, hours). Popping up the PIN again for each separate root request would be silly, as most apps fire up a number of requests in rapid succession.

How does that sound ?
[SuperSU] My1xT:
yeah, but I would find it also nice if there would be a "session root" tick in the popup which allows quick enabling of a pre-defined session time, which will be set in UI...
[SuperSU] osm0sis:
Ah... that was pretty much what I had in mind. I hadn't considered the multiple requests thing... Is there any way to allow it only for the duration of the app being open? So as soon as that app closes again it would lock it again. If that's possible, it would probably be the cleanest solution.
[SuperSU] pir:
Default re-prompt?

Great app, thanks for the great work! (and I've bought the donate version :)

The only different feature I'd like to see is being able to set something to always re-prompt, without having to remember to re-tick the ask next time box.

I want to force adb shell to re-prompt in case I leave adb debugging switched on and lose/misplace the device but the first time I forget to tick the box when allowing once it gets allowed again.

Thanks!

P.
[SuperSU] Chainfire:
From v1.00 if you're using Pro, if you hold the deny or grant button for 2 seconds (long press) in the popup you will get a popup menu with several times listed to choose from. Once that time expires that app will revert to the default setting (which is prompt, unless you change it in Settings). Of course this is also settable from the app UI. There is however no way to pre-configure the amount of minutes (at this time), but it will allow you to easily grant root for an app for say, 5 minutes only.

There are no API functions to work like this, and for good reason - you just aren't meant to do things like these. And while root is all about doing things we can't with the API, this one is a "fundamental Android thing".

On Android, there is no such thing as "the app being open". Does that mean screens being visible? Unreliable to detect, and su calls often come from a service, not a screen (activity). What about multiwindow like Samsung's new ROMs? How does that work? Does it mean the process is running? Android doesn't manage processes the way you would expect. It could be open while the app is conceptually closed. The activity or service may actually reside in a different process altogether. There's pretty much just no end of **** to run into if you attempt that. For the sake of keeping my sanity as well as the user's, this is going to stay a time-based thing (at least for now).

Could a system be built that works mostly? Yes. Reliably? Not really. Complex? Certainly. Chances of being broken by the next Android version? High. Worth it? Don't think so.

It should remember the "ask again" tick. I know, it currently doesn't. There's code for it in SuperSU, but it's bugged. This should be fixed for v1.00 release.
[SuperSU] osm0sis:
Thanks for the detailed reply. I knew background services might be tricky, but wasn't sure whether there was a way to tell if the main app was closed or not; guess there's not! A time-based solution definitely sounds like the best one if it causes you fewer headaches for roughly the same functionality. :)

Thanks for all your hard work.
[SuperSU] My1xT:
that sound Epic, thanx buddy...

but would also be nice if you think something for tablet, coz on that centred mini numberpad you cannot enter the pin so nice...
[SuperSU] Chainfire:
Which exact tablet ? A larger PIN panel is included for tablets, but it's possible the size selection might just miss your device.
[SuperSU] My1xT:
P3110 (Galaxy Tab 2 7.0 Wifi 8GB, international release)
[SuperSU] :
Re: [28.01.2013] SuperSU v1.00

I still prefer original cf icon...glad I can choose.

Sent from my GT-N7000000000 using Tapastalker 2
[Galaxy Y GT-S5360 Themes and Apps] adityam533:
Current Version: 6.3.0V6.3.0 update:Improved battery performance forLatitude and Location History users.Bug fixe**** THANKS BUTTON IF I HELPED U

Original thread here...

http://xdaforums.com/showthread.php?t=1503428

Download from there....
[Defy Q&A, Help & Troubleshooting] serpent_rider:
I am a noob here

I want to know what is the difference between froyo kernel an GB kernel?

I am using CyanogenMod-7.1.0-11-Defy.

Kernel version is 2.6.32.9-gb08c3c8 (I think is

Android 2.3.7

I have green lens defy MB525.

If the CyanogenMod-7.1.0 is based on GB kernel then what is the need or advantage of Froyo kernel?