yashsingh1/xdaforums huggingface dataset:
[SuperSU] Chainfire:
This thread is for SuperSU releases that are still in testing, and are not yet available through the Play store. The main thread for stable SuperSU releases is located here: https://xdaforums.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703. The changelogs are in the old release thread.

Please keep track of the version numbers in the thread titles, as the latest test release may not always be newer than the latest stable release.

The latest test release is:

SR5-SuperSU-v2.82-SR5-20171001224502.zip

RELEASE NOTES

That is a recovery flashable ZIP (I recommend FlashFire or TWRP). If you want to install via APK, it is also present inside the ZIP, in the common folder.
[SuperSU] Chainfire:
--- reserved ---
[SuperSU] StupidIdea:
[MENTION=631273]Chainfire[/MENTION] Does 2.05 beta include SELinux workaround for L that you mentioned in other thread? I guess we could move xposed non related discussion about SELinux here as well.
[SuperSU] Chainfire:
2.05 doesn't yet. I've made a lot of headway with it though, and is now a lot less messy and more reliable than when I last posted in that thread. It's fully working with AOSP tree synced and built today. The question is still if it'll work with retail L - probably, but we just don't know.

The mechanism itself may be able to be employed to fix Xposed as well, but I'd like to have [MENTION=4419114]rovo89[/MENTION] 's active input on this to make sure we only drop security where needed and not more than that. I haven't seen him comment on the SELinux stuff in a while though.

The code is pretty much ready to be integrated into SuperSU itself, but I'm not really sure whether I should do so now, or wait for L retail to let it loose on the world.
[SuperSU] StupidIdea:
No pressure. Its up to you if you decide to publish it before L release or not but I will be glad to test it on L and report if functions that I use in my apps work with it. As for xposed in theory these 5 points rovo89 posted should work with "permissive" but I guess he will verify it himself.

Of topic: I understand its beyond su binary but did you even thought about adding an option to start activity in system or root process? Benefits are simpler interaction with system services and improved service life (faster restarts). Let me know if question is not clear.
[SuperSU] cioce:
Please remove the "Disable Samsung KNOX popups" request the second time that we open the app, or add an option to remove this message at every start of the app, on many Galaxy S4 with the last 4.4.2 firmware a SystemServer Crash make random reboots after Knox disabled via SuperSU :(

This xposed module http://xdaforums.com/xposed/modules/samsung-kitkat-systemserver-crash-fix-t2806046 not always fix the problem.
[SuperSU] IrisNebula:
CM11s on OnePlus One

Betas 2.04 and 2.05 working like a charm, the autogrand feature didn't work before that.

Thank you for your work!

Suggestion: could you change the default theme from White to Device default? I always use Dark themes and it's kinda frustrating to have to change that on every flash... I think Device default would work great for everyone ;)
[SuperSU] Chainfire:
Not having KNOX disabled and using root in turn can also cause random reboots... so this is a tricky problem, not solved merely by not pressing that button. SuperSU keeps nagging you about it, because really, you have to do this.

Have you tried completely removing the com.sec.knox.seandroid package from your device?

The reason device default theme is not selected by default is because a lot of OEMs have some godawful themes set by default that everybody would nag me about ...
[SuperSU] MikeRL100:
Hmm. I blinked and the master has a new weapon to play with. Superuser apps will always be needed. By the way, Pro could use an update to a nicer icon.
[SuperSU] Pkt_Lnt:
#realworldproblems :rolleyes:
[SuperSU] dhampire:
I'm so sad, 1.9.4 stable but after that, whatever I did, keep su binary update rooting... I don't know what problem my device have. Lenovo s930 (kitkat4.4.2). normal update su binary makes me break root, using twrp or cwm su binary update loop. I can use only 1.9.4 without problem.
[SuperSU] cioce:
Hi Chainfire and thanks for reply,

I know that the random reebots can happen also on not modified firmware (without root), but in the Italian forum androidiani.com (http://www.androidiani.com/forum/mo...-root-towelroot-knox-0x0-galaxy-s4-i9505.html) some user report that after the root and Knox Disabled via SuperSU, the Galaxy S4 start to make random reebots, and before to do the root on the same firmware they have never seen a reboot, this is the reason why I ask you to give to the user the possibility to disable the Samsung KNOX popup.

No, but if Knox doesn't make any problem on my device, is it really necessary to disable it? Maybe someone want to use it.
[SuperSU] Chainfire:
I'm not talking about not having root at all. The problem (as I understand it) is caused by having any packages at all in a "disabled" state. This may ultimately cause a crash which triggers a reboot.

At the same time, keeping that package enabled in combination with root, will break various root commands, which you may not even notice (root apps will just appear to randomly fail and be unreliable) which in turn is also known to cause reboots.

Just because you haven't noticed the issue doesn't mean it isn't there. As for using it, having root prevents KNOX from working anyway.

...

The point is, solving this problem is not as easy as making that popup optional.
[SuperSU] Chainfire:
Please clarify what happens in the following circumstances:

- in-app binary update: normal, and reboot

Keeps saying binary needs updating? Or also results in bootloop?

- in-app binary update: TWRP/CWM

Bootloop?

- latest flashable ZIP with TWRP/CWM

Also bootloop?

It's strange if they don't all result in bootloops...

I know testing is very annoying for you because you need to reflash your system every failed test, but if you want to help solve this problem it's going to require some work.

First test:

- If you have SuperSU 1.94 installed, use the "full unroot" option from settings to remove it.

- Reboot into CWM/TWRP

- Install the latest BETA ZIP but do not reboot

- Adb shell into the device

- "mount /system"

- "ls -l /system/xbin/*su*", post the output here

- "ls -lZ /system/xbin/*su*", post the output here

- Remove /system/app/Superuser.apk

- Reboot into Android

- See if there is a bootloop
[SuperSU] dhampire:
Sorry for my poor english. not bootloop. never bootloop. but su binary update loop -> need su binary update again on every boot after update su binary....continue...keep saying need update.

---------- Post added at 09:10 AM ---------- Previous post was at 09:07 AM ----------

I also did full unroot before, and I can't root my device again (finally I flashed rom again).

---------- Post added at 09:14 AM ---------- Previous post was at 09:10 AM ----------

When I choose normal su binary update, it makes broke root(unroot), and it also I can't root again, I have to flash rom finally.

---------- Post added at 09:15 AM ---------- Previous post was at 09:14 AM ----------

If 1.9.4, there are no problem like that. but only twrp use su binaly update. normal update makes unroot.
[SuperSU] Chainfire:
Not even using the full update ZIP linked in the first post of this thread? What happens then, still asks for binary update?

Again, not even using the full update ZIP linked in the first post of this thread? What happens then, still asks for binary update?

...

Please:

- Install the attached version

- Update binaries at least once

- Reboot

- Post logcat (specifically looking for "[SuperSU][APK][Installer]" lines)
[SuperSU] Frank Westlake:
Version 2.06 installed on:

-Note SGH-I717 Android 4.0.3

-Note 3 SM-N900V Android 4.3

No problem.

With v2.04 and v2.05 on the Note, the SuperSU apps-list activity was stuck trying to display the list and the preferences activity froze the system while toggling survival mode, both only on the first run. With v2.06 this did not happen.

Was it a 'busybox' issue? I have two versions installed in different locations and there are significant differences. I use the better applets of each. Maybe developers should build a mini version containing only the applets they need to rely on and use it from their data directory.

Frank
[SuperSU] Chainfire:
No it was not a busybox issue, it was an odd bug somewhere in the binary
[SuperSU] dhampire:
Hi, Master.

Q:Again, not even using the full update ZIP linked in the first post of this thread? What happens then, still asks for binary update?

A: Yes.

I did this method.

- Install the attached version

- Update binaries at least once

- Reboot

- Post logcat (specifically looking for "[SuperSU][APK][Installer]" lines)

The attached file is the log.txt (Is it enough? or wrong? If wrong please teach me easy way, I'm newbie)

Still continue to mention " Need Su Binary update".

Regards.
[SuperSU] Chainfire:
Please confirm the app actually says 2.06

This logcat does not list the output I expect. Did you open SuperSU again after rebooting?

How did you make the logcat? "adb logcat > logcat.txt" ?
[SuperSU] Fivesack622:
Here is the last logcat.

Also, each time that I rebooted, I also opened SuperSU afterwards.
[SuperSU] royalh:
running v2.11 on DN3v5 ATT

I'm trying to use the "long back kills app" functionality from Wanam. Whenever I use it, the SU access request dialog pops up, but I can't push the grant (or deny) button. Basically the whole dialog is disabled - i can't even click the home button to get out of it - I have to wait until the 10 sec timer is done and the dialog goes away.
[SuperSU] Chainfire:
I'm not sure why you can't press the buttons after the back key has been pressed (maybe something Android internal) but I have found the issue why "trust system user" doesn't work around this. Next update enabling "trust system user" will fix this problem.

In the meantime you can do this to manually trigger the popup where you *can* grant it:

adb shell
su 1000 su -c id
exit
[SuperSU] JulGer01:
You don't have by any chance a overlay screen filter app running on you phone?

Gesendet von meinem GT-N7000 mit Tapatalk
[SuperSU] JaCh0o:
Managed to get pro licence on 1.94 by installing newest busybox.

Logcat from almost working (still asking for binaries update) added to post #172.

Wysłane z mojego Oppo Find 7 przy użyciu Taptalka
[SuperSU] Chainfire:
The last logcat does not contain any supersu information... note you have to reboot first, then start logcat, then update the binaries ...
[SuperSU] Chainfire:
Ok, so this is an issue with sugote.

Please fix SuperSU so it works again (reflash it or whatever you do to fix it), then please reproduce the issue again. However, now when it asks you to update the binary - don't do it, and don't reboot. Just back out of SuperSU.

Then, open an adb shell, and let me know the output of this:

ls -lZ /system/xbin/*su*

and another

su --self-test

though I suspect the latter will just crash or something.

You mention this issue occurs after rebooting a number of times. Is there some sort of pattern, i.e. do you open SuperSU immediately after boot, or do you wait a minute or so after you have unlocked the device? Or does it even happen randomly after your device has been running for hours? May be a very important clue.
[SuperSU] mbirth:
The last 2 times I installed a new beta (using TWRP, but I did not actively clear any cache), my Nexus 5 (with ART) spent the next 1+ hours after reboot with "optimizing apps". Is there a way to prevent that?
[SuperSU] JaCh0o:
Ok so here are corrected logcats:

logcat-194.zip - it was always hal way to working properly, installation by 'normal' method is possible at gives "successful" result.

logcat-194-pro.zip - this wasn't working till I installed new busybox (was 1.13.x, now 1.21.1), now is working same as 1.94.

logcat-211.zip - this is working partially, it asks from the beginning to update su (also got hashtag symbol on nav bar), installation by 'normal' method is possible at gives "failed" result. However root permissions are granted and every app which needs it: old (and known by SuperSU, already granted) and new (not known, no privillage granted) works, the new one ask for it and gets it.

Some explenation:

logcat-194.zip is made by Find7_ROOT4.3_bbs.oppo.cn.zip package which contains SuperSU 1.94. Propably I should check is normal SuperSU-1.94.zip working also.

Find7_ROOT4.3_bbs.oppo.cn.zip is currently only working method (excluding 2.11 which gives root privillages to everything but permanently asks for updating binaries), moreover after installing busybox 1.21.1 i go possibility to add pro license at last (previously installing pro license was revoking all permissions and asked for update the biniaries with failed result - exactly same as SuperSU normal license 2.01 and 2.02). By now (after updating busybox) 1.94 pro is working, 2.01 and 2.02 (pro or normal) not working = no privillages and failes on updaiting by 'normal' method.

Main case - actions:

1. Reboot

2. Enter SuperSU, when opens ask for update the binaries - I quit.

3. Plug to PC and open command prompt in AndroidSDK.

4. Write:

adb shell

and gives:

shell@X9076:/ $

5. Write:

ls -LZ /system/xbin/*su*/

gives:

ls -LZ /system/xbin/*su*/
/system/xbin/*su*/ No such file or directory

and there is no root privillages on phone.

6. Write:

su --self-test

gives:

su --self-test
/system/bin/sh: su: not found

Patterns:

So, SuperSU 1.94 is working properly (biniaries are updated) imiediatly after phone startup, but after I enter app again it will ask for update binairies again (cought this in logcats - attached here). <- This happends after every reboot.

Sometimes, phone just loses root pirvillages (do not see any pattern, possibly when after longer time any app asks for root privilages [which is already granted in SuperSU]). It happends sometimes repeatedly ie. first time when I installed AdAway it stucked in first step. Then i realised i need to start AdAway then fast go to SuperSU, then update binaires 'normal', then go back to adaway look then go back to SuperSU again and get 'normal' method again. In AdAway hosts installing i needed to update biniaries 3 times to make adaway successful. Now when install AdAway host update i don't need to update biniaries even once.

Another situation is that usually when I enter SD Maid Pro it works without root permissions then i need to quit it then open SuperSU, update biniaries and go back to SD Maid. Then is working properly for a while.

After short period (don't know exact maybe 5 minutes maybe 30 minutes) i need to update biniaries again. Do not see any particular pattern in root privilllages reject.
[SuperSU] Fivesack622:
So after a couple days of messing around with the fresh install and restoring all my apps, I've noticed a couple things that could be of interest.

First, SuperSU Beta 2.11 is not asking for a binary update on every reboot. It seems to be about every four reboots, but it isn't always four. It doesn't matter if I try to update the binary or not (which still always fails), if I reboot, the prompt to update the binary will usually go away. After a few reboots (it's usually four but sometimes only one), the prompt to update the binary reappears. I am also working with SELinux enforcing the entire time, just so that's clear.

Second, as was the case before, while the prompt to update the binary is there, I can still use my root apps. For instance, I can still make backups with Titanium. I will still even get the SuperSU prompt to grant or deny access to an app requesting root if I am using said app for the first time. SuperSU grants it permission and I can use it.

What is strange though (and this might be completely normal but I have no idea if it is or not), is that I noticed that I cannot copy a file into or remove a file from my system folder while the prompt to update the binary is displayed. I am told my system folder files are read only. If I manage to reboot without the binary prompt coming back, I can then delete that file without any problem. For further clarification, the file is just a picture that I moved into the system folder to see if it would let me. I copied it to my system folder during one of the times I wasn't being prompted to update the binary. I rebooted, got the prompt to update the binary, tried to delete the picture, was told it was a read only file, rebooted, the prompt to update the binary wasn't there and I deleted the file successfully.

I guess the short version of what I'm getting at is do you think the picture being read only and the prompt to update the binary are both caused by my system being read only for some reason after a few reboots? Or is it the other way around and I can't delete the picture because the binary needs updated so my file Explorer is not getting full root access to the system?

Again, this this is a Samsung Galaxy S3 Mini SM-G730V running stock 4.4.2 with a locked bootloader. Thanks for all your help.

*Didn't realize your reply from earlier today. I will get what you asked for shortly.
[SuperSU] Fivesack622:
The output of

ls -lZ /system/xbin/*su*/

is /system/bin/sh: 1s: not found

The output of

su --self-test

Is in the attachment because I can't figure out how to make a "click to show content" button.

As for when it occurs, I am generally waiting about 5 minutes before rebooting but even if I wait longer it doesn't seem to matter. It is usually around the fourth reboot. One thing though is that it almost always happens if I reboot after trying to modify something in the system folder, like when I copied that picture to the system folder.
[SuperSU] Fivesack622:
I should also add that when I did the su self test with the terminal emulator, I got a prompt from SuperSU to grant superuser access to the terminal emulator half way through, which I allowed. This was obviously while the prompt was still displayed to update the binary. So some part of SuperSU was still working. At the same time, I also noticed that although Adblock Plus had been granted Superuser access a couple days ago, Adblock Plus was only blocking wifi connections instead of wifi and mobile data, which is something it does when it doesn't have root access. If I reboot and the binary update prompt goes away, Adblock Plus goes back to blocking all connections.

Also, just to be clear, the binary update prompt usually goes away when I reboot as long as I don't actually try to update the binary, but then the prompt eventually comes back after about 4 reboots. If I actually go ahead and try to update the binary (which fails) and then reboot, I always get the prompt to update the binary again immediately upon the first reboot. If I try to update the binary again, I still get the prompt to update the binary after rebooting. If I don't try to update the binary when prompted and reboot, again the prompt goes away for about four more reboots. It's so strange but it's definitely a pattern, it seems.... and length of time the phone is on seems to make no difference. I had my phone on all day at work today and didn't reboot it my entire shift. SuperSU was working the entire time and I even opened SuperSU a couple different times and had no prompts to update the binary. I came home, rebooted, no prompt. Waited about 10 minutes, rebooted, no prompt. Waited 10 minutes, rebooted, received a prompt to update the binary.
[SuperSU] Chainfire:
That's an interesting result... I think we may have a timing issue on our hands here. Can you give me the output of the same command when SuperSU does *not* ask for a binary update?
[SuperSU] Chainfire:
That's an interesting zip. I'm not really sure why root doesn't stick for you, though. Busybox should have no influence whatsoever on SuperSU though... still, I never advise having it installed and symlinked - it's an accident waiting to happen.

I'm also guessing here that if you were to flash a clean /system image on your Find7, and then installed 2.11 zip, without having flashed that Find7-specific ZIP first, then root would not work.

Anyway, let me know the output of this command, in adb shell:

su -c toolbox id
[SuperSU] JaCh0o:
This is first KitKat release of ColorOS for this phone and I'm in not public beta test of this firmware. And yes for propability of failure in installing your SuperSU version on clean 2.0.0i ColorOS (tested on 2.02 original file from your site - didn't worked).

After writing (binaires currently not updated):

su -c toolbox id

answer:

/system/bin/sh: su: not found

Alternativly writing after 'normal' binaires update method (speaking on the sideline, I've needed to twice ony by one update binaries (both succesful) but first root permission grant was revoked in 5-10 sec):

su -c toolbox id

gives:

uid=0(root) gid=0(root) context=u:r:init_shell:s0
[SuperSU] Chainfire:
Some very interesting results. I think we're approaching the core of the issue. What I do not understand, is why does "su" disappear all the time for you? Is this every reboot?

Anyway, after you have su working, make sure you are running 2.11, then in adb shell, inside su (!):

toolbox id
/system/xbin/supolicy --permissive init
/system/xbin/supolicy --permissive init_shell
echo "u:r:init:s0" > /proc/self/attr/current
toolbox id

and let me know the output of each of these lines

EDIT: actually, if you are still on 4.3, the ZIP may not install the supolicy binary. If needed, xxtract it from the ZIP file's arm or armv7 folder, adb push it to your device, chmod 0755 it, and run it from wherever you put it...
[SuperSU] Fivesack622:
Here is the su self test taken while there is no prompt to update the binary.
[SuperSU] Chainfire:
As I suspected. Try 2.12 when I release it (probably later today or tomorrow), should solve the problem.
[SuperSU] Fivesack622:
I will try it for sure and I'll let you know how it goes after I give it a thorough "reboot" testing. Thanks for all your help.
[SuperSU] JaCh0o:
Commands:

toolbox id:

uid=0(root) gid=0(root) context=u:r:init_shell:s0

/system/xbin/supolicy --permissive init:

supolicy v2.11 (ndk:armeabi-v7a) - Copyright (C) 2014 - Chainfire

-init:permissive

/system/xbin/supolicy --permissive init_shell:

supolicy v2.11 (ndk:armeabi-v7a) - Copyright (C) 2014 - Chainfire

-init_shell:permissive

echo "u:r:init:s0" > /proc/self/attr/current:

(no answer)

toolbox id:

uid=0(root) gid=0(root) context=u:r:init:s0

Note that, on Beta SuperSU 2.11 I got permanent root (no need to update binaries), but whenever i want to enter SuperSU app, it asks me to update binaires (with result failure).
[SuperSU] palmbeach05:
Build.prop edit methods have not changed. If the update to mm has resulted in some functions being limited til apps are updated, then wait. Chainfire did just explain that

---------- Post added at 05:01 AM ---------- Previous post was at 04:54 AM ----------

Straight from chainfire from his website

ANDROID VERSION

When newer firmwares are released for a certain device, sometimes that firmware includes new bootloaders that prevent kernels based on the old firmwares from booting. This usually coincides with a transition to a newer Android version. In that case, the CF-Auto-Root for download here may no longer work - flashing or booting might fail. It is too much work for me to keep track of all these firmwares, so if you encounter this issue, it is up to you to submit the recovery.img file from the latest firmware for your device to the*CF-Auto-Root thread on XDA-Developers.com.

To be clear, just because you have a newer Android version than listed here, does NOT mean the CF-Auto-Root will not work - there's a good chance that it will!
[SuperSU] Mairo:
Install MiXplorer, then go Apps>MiXolorer>Permissions... and enable Storege permission. It works, I change my lcd density.
[SuperSU] Alan-B:
Hi,

Can you modify the boot of the SM-P605 5.1.1 which gives problem?

Boot in attached file.

It would be nice for the users of this tablet. ?

Friendly

https://mega.nz/#!oxQTQLSL!LuuXc98huL6oEkun-PRln-I1m8cJ8mvGZ7ThvmXHHfI
[SuperSU] alexxandro84:
also I for this :laugh:
[SuperSU] palmbeach05:
Can he modify it for you after he gave you the do it yourself instructions.....