yashsingh1/xdaforums huggingface dataset:
[SuperSU] nathanchance:
Whoops, thanks for the heads up!
[SuperSU] pkelly517:
No problem.

Simple mistake with a simpler correction. I'm glad you updated the original post. I bet there is at least one person who won't be confused when it doesn't work. [emoji2]
[SuperSU] dechronic:
SupserSU version -> BETA-SuperSU-v2.71-20160331103524.zip

Information quoted is found in -> BETA-SuperSU-v2.71-20160331103524.zip\META-INF\com\google\android\update-binary

LINES 57-69 (Bold in quote is mine)

LINES 572 - 682 - The code for the "detect_systemless_required" function

This function serves to verify the Samsung 5.1 or Android 6.0+ device can use SuperSU installed in /system . In the event that it fails any of the checks, it will failover to a Systemless install unless, and only if, the "SYSTEMLESS=true" variable is specified in the shell or found in /system/.supersu or /data/.supersu.

Note: That variable will be ignored on any pre-Android 6.0+ devices, excluding Samsung 5.1 devices.

Only LINES 572-579 quoted below. Checks done by the function. (Bold in quote is again mine)

LINE 677

Why do I say that the default is to install to /system and not systemless?

1) Chainfire says so in the comments of his code

2) His code says so.....any conditional processing done is to verify whether a condition is true or false. The "false" result of a conditional piece of code is always at the end of a string of code, exactly like the piece of code to install as systemless is at the END of the "detect_systemless_required" function. Hence, priority is given to the SYSTEM install.

3) The name of the function is "detect_systemless_required" because the default SYSTEM install cannot be performed.

4) The only thing that supersedes that function is the "SYSTEMLESS=" variable which can ONLY be used by Samsung 5.1 or Android 6.0+ devices and must be specified by a user prrior to installation. Therefore, a modification will need to be made and so it cannot be the default.

5) SuperSU 2.71 can be installed on almost any Android device but it can only be installed as systemless on Samsung 5.1 and Android 6.0+ devices.

Therefore , it stands to reason that systemless cannot be the default.

Code cannot lie or take views.

In plain terms, according to the code, SuperSU 2.71 will install in /system on most, if not almost all, (Samsung 5.1 excluded) pre-Android 6.0+ and some custom Android 6.0+ devices.....failing that SuperSU will install as systemless provided it is a Samsung 5.1 or Android 6.0+ device.
[SuperSU] Chainfire:
Whether the default is systemless except when system is possible, or the default is system with a fallback to systemless if system is not possible, is the exact same thing.

This argument is completely pointless.
[SuperSU] sqpp:
I need help. Not these kind of informations, also Viper4Android says I/O error on N Only. Probably permission ?
[SuperSU] MrKaon:
I'm on stock, don't use custom ROM, because of been bug land, everything else straight forward, simple install.
[SuperSU] sqpp:
Did you even read i am on N?
[SuperSU] dechronic:
Hahaha. I agree that it is the same thing. I don't think it was pointless

I just used it as a platform to better understand the code myself and to explain how the code works which may help others understand why it installs as systemless in certain instances and not others.

Makes me appreciate more the work put into SuperSU to make it support as many devices as possible.

Thanks to you.

Thanks to [MENTION=6952047]grep_j[/MENTION] and [MENTION=6842057]nathanchance[/MENTION] for helping me realize that.

Sorry for using your post grep_j to do that.

No disrespect intended to you or anyone else here.

P.S. I know I like a good debate/arguement....not trying to make anyone angry/stressed.
[SuperSU] Pig Vomit:
FYI: 2.71 still working just fine on my Nexus 6P after May security update to MTC19T (still 6.0.1).
[SuperSU] qralston:
using Kies to re-flash stock /system partition?

I apologize if this is a dumb question, but I haven't been able to find a definitive answer.

I'm trying to upgrade a CF-autorooted but otherwise stock Sprint GS5 (SM-G900P) from firmware BOG1 (5.0) to firmware CPCA (6.0.1). I want to re-root after the upgrade, so that means systemless root. But per Chainfire's instructions, I need to revert to a completely stock /system partition first.

If I use Samsung Kies on Windows to perform the upgrade from BOG1 to CPCA, will that process effectively re-flash the /system partition? Or does performing an upgrade only update the files in /system that changed with that update? Other than checking for the su binary in /system/xbin, how can I tell that I have a stock /system partition again?

If the answer to the previous question is "no", then I've seen it asserted that the Kies Firmware Upgrade and Initialization function can be used to completely reset a device back to stock (including the recovery). I would assume that includes re-flashing /system. Has anyone tried this?

(Yes, I know I can always go find the full CPCA firmware image and flash it with Odin. But all of the direct download links for CPCA that I can find are super-slow, and at least for me, Kies downloads blazingly fast.)
[SuperSU] DingoBat:
Have you seen there is a file for systemless hosts?

http://xdaforums.com/showthread.php?t=2190753
[SuperSU] mahler47:
May update breaks stuff

Just updated my Nexus 5X to May images (MTC19T) with SuperSU 2.71 and noticed that Secure Settings can no longer perform any root actions. It complains that these root actions aren't available even though AdAway and TitaniumBackup are working fine.

Anyone else notice problems with latest May factory images?
[SuperSU] Ch3vr0n:
Then complain to the dev
[SuperSU] nathanchance:
If I remember correctly, that app has had quite a few problems with systemless root. I'd email the devs and tell them to update their app, as they most likely have a hard coded su path. You can also try to enable compatibility mode in the meantime by typing this into a terminal emulator and reflashing SuperSU:

echo BINDSYSTEMXBIN=true >> /data/.supersu

Chainfire has talked about this issue at length in the thread, a quick search should bring you up to speed if you continue to have questions.
[SuperSU] exSD:
How do I force the installer to root /system? I'd like to be able to modify /system and I can't mount rw on /system using systemless.
[SuperSU] nathanchance:
Been talked about quite consistently that systemless root in and of itself does not inhibit mounting system as read write. What is your phone and firmware? What version of SuperSU? If you just flashed the latest SuperSU zip without putting in any terminal commands, it means that you can't root your firmware via modifications to system since it checks for that first.
[SuperSU] Pkt_Lnt:
FYI , that was last updated on Jan 29, 2014 and the dev has been gone from the thread since about March 2014.
[SuperSU] MrKaon:
Host file is always same no matter how do you obtain root, even simply can overwrite on top of the old one without AdAway.

---------- Post added at 06:22 AM ---------- Previous post was at 06:20 AM ----------

Sorry I've completely missed that part.

If you want I'll share the host file so you can replace it to get rid of ads.
[SuperSU] DingoBat:
Sorry - that got lost in translation - There is a flashable zip that prepares your device so that AdAway can remain pointed to /system/etc/hosts yet never actually touch your /system partition.
[SuperSU] dimaskhoirul:
I want to update binary su on asus zenfone laser ze500kg but not succes
[SuperSU] nathanchance:
Read the first post of this thread, as the information you have provided will not allow us to help you.
[SuperSU] dhruvdave:
How to install twrp systemless
[SuperSU] fmc000:
What?
[SuperSU] nathanchance:
Not really sure what you mean by this statement. TWRP is a recovery, the term systemless is meaningless. Do you mean how to install SuperSU as systemless in TWRP? Just flash the zip file, you'll end up with root one way or the other.
[SuperSU] magnamentis:
try the below approaches, at least one of them should work for you as well:

Terminal Commands for Secure Settings in N-Preview and probably other apps to be fixed (write to system)

mount -o remount,rw /system

touch /sbin/su /system/bin/su /system/xbin/su

mount -o remount,ro /system

su

mount -o remount,rw /system

ln -s /su/bin/su /system/bin/su

ln -s /su/bin/su /system/xbin/su

mount -o remount,ro /system

Terminal Commands to allow SELinux Mode Changer to work without reboot into Safe Mode !

1. stop logd

2. setenforce 0
[SuperSU] Stryker_Echo9er:
I am on Samsung Note 4 (910G) 6.0.1 Stock rom.

I am facing a weird problem while granting root access to certain apps.

For example ES explorer and many other apps are unable get root access.

I flashed SuperSU 2.71 using TWRP v3.0.2.0.
[SuperSU] dechronic:
See this post on the previous page as it applies directly to your issue -> http://xdaforums.com/showpost.php?p=66668518&postcount=5911
[SuperSU] fastleo63:
BETA 2.71 issue on my OnePlus One (COS13 - Android 6.0.1)

Hello,

Today I flawlessly upgraded my OnePlus One to official Cyanogen OS 13 full zip (released today), and reflashed SuperSU (latest BETA 2.71, through TWRP recovery 3.0.2.0).

When I restarted my phone, I noticed that all apps that previously required root access won't be able to gain it anymore. Any solution?
[SuperSU] Chainfire:
Please provide the logs described here: http://xdaforums.com/apps/supersu/support-update-failures-t2907365
[SuperSU] Chainfire:
You have a system install. Should be system-less for this ROM. Either the detection is off, or the ROM advertises being able to use system mode while it cannot.

echo SYSTEMLESS=true>>/data/.supersu

From recovery adb shell (with /data mounted) should fix this.
[SuperSU] qralston:
Cyanogen OS 13 is based on Marshmallow, which means your SuperSU install is the systemless flavor, which means the su binary isn't located in /system/xbin. Unfortunately, some root applications hardcode the path to su as /system/xbin/su instead of relying on the OS to find it in the PATH.

To test, launch TitaniumBackup (temporarily install it if you don't use it). Can it acquire root access successfully?

If so, then your issue is that the other apps are hardcoding the path to su.

The best solution is to email the developers of those apps and ask them to update their applications to use su properly. ChainFire has a tutorial at su dot chainfire dot eu (I'm too new to be able to post links).

In the meantime, [MENTION=6842057]nathanchance[/MENTION] posted a work-around for the buggy root apps in post 5911 of this thread.
[SuperSU] fastleo63:
Yes, my Titanium Backup shows root access granted.
[SuperSU] TR2N:
Hi guys, hello [MENTION=631273]Chainfire[/MENTION]. I'm on a Nexus 6 device with latest factory image (may build) and Franco Kernel installed. I can't remember exactly when this started, maybe since February I have noticed that sometimes my phone gets sluggish and stops responding. Than I am not able to use any root app (to reboot the device for example), and when I try to open SuperSU the listing of the apps that are granted loads forever. And sometimes the phone reboots when it got unresponsive. The next thing I want to try is fresh flashing everything, but I wonder if this is a known problem.

Thank you!
[SuperSU] leleobhz:
You're partially right. Systemless works ONLY with the [MENTION=5227588]Deltadroid[/MENTION] procedure described at http://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/post66507529#post66507529

So SuperSU needs to do this procedure someway to systemless work ok. Anyway, systemless=false works too (But I think its not the right procedure to do).
[SuperSU] 719c6:
I have a G870A with 5.1.1 PB1 and no root. Can I load suspersu APK and get a systemless root?
[SuperSU] fastleo63:
Only to confirm that the workaround worked flawlessly. Now all apps regained root access. Thanks to all!
[SuperSU] captivated1971:
Hey i would also like to know what you get. I hope it works. Will be following
[SuperSU] Surge1223:
Hey I have a question about your libsupol.so

Out of curiosity a while ago I made one of my goals to run audit2allow on my device, I realized this would require me cross-compiling python, swig, a bunch of static libs to satisfy linker errors, and then the full suite of selinux, for the policycoreutils.

So after a while I made the full non aosp neutered version of selinux (as in selinux-master compiling as it would on pc) and after patching lib loading in python, I'm ready to test audit2allow.

I'm well aware that certian parts of selinux do not apply on Android, but I guess what I'm wanting to ask before i proceed and put libselinux.so in my lib path...

Will libsupol.so interfere during any of this? Does it take precedence over other libs (i.e. Did you alter LD_PRELOAD or LD_LIBRARY_PATH?) and if so is there a way for me go temporarily get around this?

Thanks.
[SuperSU] Exile1975:
The answer would be no. You have to flash SuperSU.zip through twrp or other custom recovery. Just loading the apk will not grant you root
[SuperSU] captivated1971:
[MENTION=4147271]Joker87[/MENTION] did you risk losing ur root to aquire or upgrade to 6.0? Or did you ota upgrade ? I know another user tried doing it from nce and it patched the kernel image fine but at reboot gave him a kernel error . Of course im thinking was a bootloader issue maybe because of him trying to jump from 4.x.x to 5.1.1 as i also know it wasnt 6.0 but was wondering how you got to the 6.0 in case i wanted to try it.also . But would hate to lose my root lol.
[SuperSU] guitar1238751:
:oHere's how to install Adaway on Android N:

Step 1: Flash this systemless zip via recovery (I use TWRP)

https://www.androidfilehost.com/?fid=24438995911977059

(Mega link if you cant get it from the first link or if you just want to save it directly to your drive: https://mega.nz/#!zR90iCbD!r163V3WOMTWsB0HqpcYs4HF8_XpXy03PO5KFwKSnsWo )

Step 2: Install the latest Adaway App (v3.1.1) : https://f-droid.org/repository/browse/?fdid=org.adaway

Step 3: Make sure to grant it root access when the prompt comes.

Step 4: Now click "download files and apply adblocking". It should successfully patch the hosts file now.

Step 5: Now reboot and you should be good to go!

Hope this helps! :o
[SuperSU] thomasyke:
Anyone tested to see if this is working for MOB30H (N5) and MTC19T (N5X)?
[SuperSU] premkumar5056:
Superuser binary update problems please how to solve this problem
[SuperSU] Darke5tShad0w:
You need to be here

http://xdaforums.com/apps/supersu/support-update-failures-t2907365
[SuperSU] Fif_:
Yes, I'm seeing this, albeit rarely, on OmniROM 6.0.1 20160416 (MM) with a Nexus 5.

SuperSU 2.71.

There's a su thread hung somewhere and all processes calling out su hang as well.

I was not able to capture a useful logcat.
[SuperSU] LoverBoy2415:
Try Flashing SuperSU Zips in Your Recovery ,Instead of Updating Binaries Via Apk ..
[SuperSU] Evo_Shift:
Wow, Android Pay works with systemless root? I thought they disabled it again somehow. I was using the old root method but just decided to try out the systemless today after I flashed the May update for the heck of it and thought why not try Android Pay and it worked! Got my $1.85 soda I don't need but that's awesome!
[SuperSU] Alxoom33:
Fails when copying files and applying ad blocking :(
[SuperSU] Pkt_Lnt:
Most likely mixing XDA workaround with F-Droid version causes incompatibility. Use the XDA version for both.
[SuperSU] 911Guy:
Well, this is good news! Might have to give that a shot when Samsung Pay comes to Canada!!!
[SuperSU] Ch3vr0n:
Wrong topic. There's a specific topic relating to superSU and Android pay. Use that for he discussion.
[SuperSU] MrDrift42:
You probably have no free space in system. Try deleting some Google bloat.
[SuperSU] spinosa:
Updated to the latest firmware for the nexus 7 2013 LTE (MOB30J) by flashing all but userdata.img then installed TWRP 3.0.2 and supersu 2.71.

The subsequent boots fail and logcat shows:

05-04 18:21:34.232 664 763 I ServiceManager: Waiting for service media.audio_policy...

05-04 18:21:35.232 664 763 I ServiceManager: Waiting for service media.audio_policy...

05-04 18:21:36.234 664 763 I ServiceManager: Waiting for service media.audio_policy...

05-04 18:21:37.235 664 763 I ServiceManager: Waiting for service media.audio_policy...

05-04 18:21:38.237 664 763 I ServiceManager: Waiting for service media.audio_policy...

05-04 18:21:39.237 664 763 W AudioSystem: AudioPolicyService not published, waiting...

repeating.

I waited about 30m to see if it fixed itself. No luck. I extracted the log from twrp and looked at it. The only thing that looks questionable is:

- Flashing boot image

dd: writing '/dev/block/mmcblk0p14': No space left on device

4097+0 records in

4096+0 records out

16777216 bytes (16.0MB) copied, 0.061737 seconds, 259.2MB/s

1860+0 records in

1860+0 records out

7618560 bytes (7.3MB) copied, 0.246429 seconds, 29.5MB/s

looks like the updated boot image is too large. Am I reading this correctly?

MOB30J does come with a new kernel. I do have the complete log from twrp if its needed.

Ideas anyone?

Thanks

PS. works fine without root on MOB30J except that it keeps corrupting the twrp install....
[SuperSU] WILMANS2M:
Hello,

First Thank to Chainfire for making SuperSU available :)

2nd, i have to face a problem with my custom rom

I want to install SU through an updater-script when installing my rom.

So i use this at the end of the updater before all is unmounted:

ui_print("@ Adding SU support");

package_extract_dir("supersu", "/tmp/supersu");

run_program("/sbin/busybox", "unzip", "/tmp/supersu/BETA-SuperSU-v2.71.zip", "META-INF/com/google/android/*", "-d", "/tmp/supersu");

run_program("/sbin/busybox", "sh", "/tmp/supersu/META-INF/com/google/android/update-binary", "dummy", "1", "/tmp/supersu/BETA-SuperSU-v2.71.zip");

ui_print("--> SU installed");

But when it tried to install itself, i got a set perm error.

Does anybody have a workaround for this ?

Thanks.
[SuperSU] osm0sis:
[MENTION=5787964]SuperR.[/MENTION] has this working in his kitchen so maybe he or [MENTION=1162986]Captain_Throwback[/MENTION] can elaborate?
[SuperSU] WILMANS2M:
Ok found what was the problem. My fault....sorry.

Envoyé de mon GT-I9505 en utilisant Tapatalk
[SuperSU] Chainfire:
I've been looking at this, but did not spot any obvious issues.

Did you decrypt (or wipe) /data by any chance?
[SuperSU] shoey63:
Only /data wipe was prior to installing the rom. Not subsequent to installing SuperSu.

Never encrypted, nor decrypted.

Thank you for looking at it. Sony are weird. They release MM for Z3 with no dm-verity, and then, within a couple of weeks release N-preview with dm-verity enabled, plus some other mysterious security feature which kills sim card if you attempt systemless root:confused:
[SuperSU] Chainfire:
So, are you running encrypted or decrypted ? What is the output of the "mount" command ?
[SuperSU] Chainfire:
I could not replicate this with a full flash of MOB30J to my Nexus7.

Are there any SELinux / "audit" / "avc" messages in logcat or dmesg ?
[SuperSU] Captain_Throwback:
set_perm error doesn't sound like it has anything to do with SuperSU. A recovery log would be helpful to know for sure.
[SuperSU] shoey63:
Mount command for userdata says "data ordered" with no mention of encryption. Also settings offers to encrypt data, so definately not encrypted.

Edit: just full wiped data in twrp and flashed 2.71 again - still no sim.
[SuperSU] Chainfire:
Please just copy/paste the output or screenshot it.
[SuperSU] tnpapadakos:
at the risk of being flamed for asking, how is it coming obtaining root using your SU on the V10 MM update? I've read the other related threads, and am aware of the current method out there, but would rather wait for your SU zip that can root the new MM update for the V10..I'm on T-mobile
[SuperSU] GROGG88:
That is not a SuperSU package issue. That is a device bootloader issue and should remain addressed in the device thread.
[SuperSU] Ja_som:
What this has to do with SuperSU? I understand that you share it in Xposed threads, but why here?
[SuperSU] Ch3vr0n:
Wasn't it you do told me to report such post instead of doing a 'useless' post like that a couple days ago?

Verstuurd vanaf mijn Nexus 5 met Tapatalk
[SuperSU] shoey63:
Ok here is the full output from terminal emulator

and the end part

Edit: If I repack the boot.img with the patched sepolicy, and only disabling dm-verity in the fstab, without installing SuperSu, the no sim and reboot problem persists.
[SuperSU] Chainfire:
You are running decrypted. At least on one other device (HTC10) this is known to cause similar problems. You can see this because /data is mounted on .../userdata, rather than on /dev/block/dm-X.

Good next steps would be to try if its the decrypted data, dm-verity, or sepolicy that causes it by selectively not patching both. Note that there are two components to dm-verity, the verity_key file and the verify flag in the fstab files on the /system mount.

If you have not modified /system (so dm-verity still succeeds) you could trigger the re-encrypt by going into SuperSU, using the Full Unroot option, and rebooting. That reboot may take hours because the device will be busy re-encrypting. If you have modified /system, you need to flash back both boot and system instead.

Without a device it is practically impossible to do anything helpful on my end about this, until you figure out which factor is causing this.
[SuperSU] gokart2:
[MENTION=631273]Chainfire[/MENTION] or anyone who may know...... I wanted to verify there is no way to get around some apps not seeing root privileges with systemless root? I have searched and found no positive answer so far. I have been learning to compile/mod kernels, and none of the CPU tuning apps that I've tried like Kernel Adiutor notice root. Thanks
[SuperSU] Pkt_Lnt:
Did you try Chainfire's suggest to re-enable compatibility mode?

http://xdaforums.com/showpost.php?p=66140836&postcount=5493
[SuperSU] chazall1:
I just got the HTC 10 and wanted to verify that SYSTEMLESS can be used.

Thanks
[SuperSU] gokart2:
No, I didn't see this. I will give it a try. Thank you VERY much!:good:

edit:

Worked perfect. Was exactly what I was looking for. Thanks again!!!!!!!!!!!!!!!!!!!!!!!!!!!
[SuperSU] shoey63:
The rom is decrypted by default when you first install it and sim card works.

(unmodified fstab has "encryptable" on data line)

Removing verity_key and verify flag doesn't break sim card either when decrypted.

Sim card works without issue with dm-verity disabled and /data decrypted. Do I still need to encrypt?

Understood.

So summing up what I have tried:-

- decrypted = ok

- decrypted + dm-verity disabled = ok

- decrypted + dm-verity disabled + patched sepolicy = sim card not recognised plus random reboots directly to bootanimation.

- decrypted + flash systemless 2.71 = same as above.

So it must be the patched sepolicy, or am I missing something?

Anyway, thanks for taking the time to look at it, even if nothing more you can do.
[SuperSU] Chainfire:
No, you've already verified this is not the issue.

That is indeed likely. The logs you provided previously were late, they didn't include early boot logs. Try to recreate the logcat and dmesg dumps immediately after boot+simunlock.
[SuperSU] nixie2121:
so I am running systemless. I have an update to my ROM which flashes SU, non systemless. after I flash ROM, unsu , do I need to type the lines for systemless again? just want to be sure, thanks
[SuperSU] zear4fear:
hey there, i have the problem that apps don't get permissions. they ask for root rights but nothing happens.

i flashed twrp, used the systemless command and flashed this zip. cleaned cache and dalvik. all several times.

also flashed boot.img and recovery again.

After installation of SuperSU in TWRP the system always loops once .

But then SuperSU gets no permissions.
[SuperSU] grep_i:
You're a little bit unclear.

Can you tell which rom your using and version ?

TWRP version ?

Supersu version ?

Do you flash only the .zip file ?

After flashing and reboot do you have the Supersu app installed on your phone and can you verify its the same version you flashed through TWRP?

Can you provide logcat ?
[SuperSU] Pkt_Lnt:
post #9568 above