[BETA][2017.10.01] SuperSU v2.82 SR5

Search This thread

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
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://forum.xda-developers.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.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
@Chainfire 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.

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 @rovo89 '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.
 

StupidIdea

Inactive Recognized Developer
Jun 24, 2011
1,369
1,866
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 @rovo89 '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.

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.
 
Last edited:

cioce

Senior Member
Sep 21, 2013
346
103
Last edited:

IrisNebula

Member
Jan 12, 2010
29
8
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 ;)
 

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
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://forum.xda-developers.com/xposed/modules/samsung-kitkat-systemserver-crash-fix-t2806046 not always fix the problem.

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?

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 ;)

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 ...
 

MikeRL100

Senior Member
Jun 20, 2012
696
451
27
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.
 

dhampire

Senior Member
Jan 26, 2013
194
55
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.
 

cioce

Senior Member
Sep 21, 2013
346
103
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.
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.

Have you tried completely removing the com.sec.knox.seandroid package from your device?
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.
 
Last edited:

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
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.

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.

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.

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.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
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.

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
 
Last edited:

dhampire

Senior Member
Jan 26, 2013
194
55
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.
 

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
I also did full unroot before, and I can't root my device again (finally I flashed rom again).

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

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.

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)
 

Attachments

  • SuperSU-v2.06-installdebug.apk
    2.3 MB · Views: 1,759
Last edited:

Frank Westlake

Senior Member
Nov 13, 2013
644
278
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
 
  • Like
Reactions: frystyle

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
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.

No it was not a busybox issue, it was an odd bug somewhere in the binary
 

dhampire

Senior Member
Jan 26, 2013
194
55
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.
 

Attachments

  • log.txt
    168.3 KB · Views: 342
  • Like
Reactions: Pkt_Lnt

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,441
87,685
www.chainfire.eu
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.

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" ?
 
  • Like
Reactions: intoxicated.mad

Top Liked Posts

  • There are no posts matching your filters.
  • 2523
    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://forum.xda-developers.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.
    613
    unSU Script zip -- Unroot with ease!

    Originally this was a little zip to help with uninstalling the old system-modifying version of SuperSU. It properly restores all the original files the SuperSU installer backed up (so, file-based OTA friendly!) and removes any files added by the installer/app. I figured other people might find it handy as well so it's attached below. Be aware, if you flashed SuperSU twice mistakenly, the SuperSU installer wasn't written to recognize that and so you've lost your originals; a system.img flash WILL be necessary in your case.

    Due to popular demand by the custom ROM community using this to unroot and pass SafetyNet checks/use Android Pay, etc., the script has been expanded to unroot Koush's SuperUser, ROM su binaries, as well as SuperSU Systemless (su.img and BINDSBIN), phh's Superuser (which is also systemless), and now Magisk and LineageOS addonsu.

    Note: To completely remove all traces of the systemless roots, you still need to flash a different, unrooted boot.img, likely the default one that came with the ROM. You can extract it from the ROM zip (or a /data/stock*.gz backup from your root solution before flashing unSU) and flash it using TWRP's awesome "Flash Image" functionality, or, "dirty flashing" the ROM zip should also work.

    My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!

    P.S. If you found this handy then please check out my Odds and Ends thread for more flashable goodness. :D

    Previous download counts: 58944; 158506; 59850; 226692
    578
    f2fs with Android story is always complicated.

    So why is SuperSU broken with many custom ROMs:
    systemless SuperSU saves a raw ext4 image in /data/su.img and mounts it as a loopback device and to various locations upon boot.
    The problem with f2fs, is that most kernels included in custom ROMs have issues with managing loopback devices.
    This is not SuperSU issue, rather, kernel developers has to incorporate the necessary fix for f2fs.

    This “fix” is rather dumb :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105

    The f2fs head, Kim Jaegeuk forgot to add those pointer to post-4.10 versions of f2fs backports.
    (The stock OnePlus 3T’s kernel source code seems to already have this fix. This explains why OxygenOS didn’t have any issues with SuperSU.)
    So you have 2 choices :
    A. Cherry-pick that fix separately
    B. Merge f2fs version all the way up to 4.10(latest f2fs-stable.git is updated to 4.10)


    But there are more stories to be told, unfortunately.
    Both 2 methods introduce a new problem : breaks all previous f2fs versions to read the data.
    There is no on-disk-format change introduced by the new “fix”, but it turns out that older versions of f2fs has an issue which is exploited only when newer version of f2fs is used to write data.

    You need this additional fix, if you have no intention to update f2fs to the latest 4.10 version :
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    Without this fix, the kernel will panic upon reading any data.


    So we took care of the method A.
    However, there is still an issue with method B : deadlock.

    As noted in https://review.lineageos.org/#/c/95316/ , there are deadlocks present on the latest version of f2fs(from 4.8, iirc).
    It took about a month to bisect it, and I got the culprit commit :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0

    I’m still yet to hear from the upstream developers, but I can confirm that reverting that commit fixes the deadlock.
    Our internal AOSPA builds are running on 4.10 f2fs with that commit reverted.


    TL;DR
    It’s not @Chainfire 's fault.
    You have to ask the kernel developer to fix the issue.
    2 methods for the kernel developers

    A. Incorporate only the necessary 2 fixes to fix loopback images :
    https://git.kernel.org/cgit/linux/k...y&id=0d5ed69805ee57d7b416c4a6b47c3b67284db105
    https://git.kernel.org/cgit/linux/k...y&id=7a895023cc2c06c08a6cccb71e112255eb0837ee

    B. If you want to upstream f2fs to the latest 4.10, revert this to avoid deadlock :
    https://git.kernel.org/cgit/linux/k...y&id=de62dad6f502c67fd01b5c0b1f7f242836ce90d0
    (A little credit would be appreciated, as it took me a frustrating month to bisect this)

    Thanks.
    348
    --- reserved ---
    189
    @ everyone

    This post is likely an important one going forward, it could be the answer to various issues people have on 6.0 related to /system.

    The conversation below pertains specifically to Nexus 6 @ 6.0.1, which has an almost full /system, but I'll bet the issue exists on all Nexus devices.

    Do you mean that there's even less space than on 6.0?
    Titanium Backup reports that there 15.6 MB free. Shouldn't this be enough for a very small mod such as an edit to build. prop?

    So after some further investigation, something pretty odd is going on.

    ext4 (the filesystem) has various types of reserved blocks.

    I suspect the tools on booted Android do not count one type of reserved block. Indeed, when you use "df" utility (both toolbox and toybox), it shows 15mb or so free. Using the same "df" utility in recovery (busybox) shows 0b free. It does show that not all blocks are in use, but the remainder is likely reserved.

    If you use a root shell on either booted Android or in recovery, trying to write contents to a new file in /system will fail. To make matters worse, file creation succeeds, but writing content does not, so you end up with a 0 byte file. You need to delete a few extra megabytes of files, before you are able to write even 1 byte to a new file!

    Many editing tools remove the old file and write a new file at the same spot rather than truly editing a file. I'm not sure if the latter has any chance of succeeding, but the former would definitely fail in this scenario.

    While the issue is understandable technically, it is likely to trip up a lot of tools, as the error is generated at the least expected moment.

    This issue is a magnet for file corruption and bootloops. Beware this issue when modifying anything on /system!

    DEVS Immediate hunch is that the difference is explained by usage of struct statfs's bfree vs bavail member.

    TL;DR Yes, even though TiBu and whatever other tool are showing you megabytes free, adding/modifying files is likely to give unexpected results on a (near-)full /system partition, and an unlucky edit can definitely prevent the device from booting! Can't give you exact numbers right now, but before modifying files or adding files to /system, I would recommend deleting files until you have at least 30-ish mb free.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone