yashsingh1/xdaforums huggingface dataset:
[SuperSU] Ibuprophen:
I had asked this question within the "[BETA][2017.01.14] SuperSU v2.79 SR3" thread (as i had quoted myself above).

I had received 1 or 2 responses that looked like a vague/assumption and was hoping that i could get a more positive response from either [MENTION=631273]Chainfire[/MENTION] or another member that could provide a more positive answer.

Thank you all!

"Live Long and Prosper..."

~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
[SuperSU] Sr. Zé Alguém:
[MENTION=4828250]Ibuprophen[/MENTION]

The authoritative answer for your first question can be reached if you compare the hashes of both Apks.

The second, if you are sure (I'm not) that the Apk include all the binaries that are inside the Zip, if you can find them you may also compare hashes. I don't know if the app updates the binaries by patching or by replacing files; if this second case is true, it should explain why the binaries are not included in the apk.
[SuperSU] Ibuprophen:
Regarding my first question... what a noob oversight... I should have thought about comparing the Checksums on both apk files... LOL!

The second question... well I do know that the apk files have the binaries or else if, SuperSU was installed via the apk file, it wouldn't prompt to install them.

I was just asking (on the second question) when the flashable zip includes fixes, changes, patches, etc... within it that is applied, when flashed, are those same fixes, changes, patches, etc... also present within the apk file that's located in the common folder of that same flashable zip?

Thank you very much for your response too!

"Live Long and Prosper..."

~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
[SuperSU] Idebutterpiep:
Sorry, I was not aware of using caps ..................... So i ddn't want to be rude.

I just copied what I saw.
[SuperSU] milewap:
On Samsung Galaxy S3 I9300 i flashed all SuperSu(2.79,2.80,2.81 and 2.82),and updated binaries without any problem.All releases work nice,and update binaries :)
[SuperSU] Mainaharen:
V2.82 works fine in xperia E3
[SuperSU] toughcanny:
Phone not starting after updating supersu on encrypted rooted

Hello,

I have Zuk Z1 android 5.1.1 running cyanogen.

It is encrypted and rooted.

All was working fine. Problem started when I receive supersu update on play store.

After updating supersu, it asks to update its binary. Installation went successful.

After restarting phone, it get stuck in cyanogen splash screen. It didn't asks for password, no, nothing.

Restarted phone in recovery mode, it has twrp 3.0.2.0. There is no decrypt option.

I cannot mount, it says system 0mb, data 0mb, usb otg 0mb.

I tried attaching multiple usb otg to update twrp version, but can't get detected.

I restarted mobile in bootloader, connected to pc to use adb / fastboot to send new twrp version but it says waiting for device

Although I can see drivers loaded in device manager, but fastboot can't see phone.

I want my mobile to get restarted. Or if it’s not possible, I want to recover my data. It’s important.

I hope there some way. I know password. Please help me on this.

Feel free to ask for more information, and hope to get solution to this situation.

Thank you and regards.
[SuperSU] Cluey:
Well I made the mistake of letting this update from the Play Store on my Sony Xperia Z2 and it won't boot.

Since that happened I've check here and there's a special test patch for Xperia's in the first post.

Why was this not updated to the Play Store?

Or, if it was, why is the Play Store sending me a version which breaks my phone?

As an aside I haven't been following things here all that closely, I got my phone set up how I wanted it and then left it alone.

I remember reading the change happening with [MENTION=631273]Chainfire[/MENTION] handing this project on so he can do other things, I have no problems with that, but I never had an update do this in the past. Now the new team has stepped in and one of the first (the first?) updates via the play store and my phone doesn't boot.

That is not a good look guys.

If I'd tested a beta version and it did this I'd have no problems with it not working, that's what beta/test versions are for.

I've read the first post and the apologies but that shouldn't have been needed. Test and test again, if something goes to the Play Store I don't expect it to break my phone!

Lets hope this doesn't happen again and that Google doesn't remove it from the Play Store.

Now to search/read through the thread to work out how to recover from this debacle.

Edit. Okay I've caught up on the thread. I didn't update until about 02:00 UTC time, it's the 2.82 version according to the Play Store.

After installing I got the message about updating the binary, I chose the Normal way and it said success and to restart my device. Well that didn't work.

Having caught up on the thread the only conclusion I can come to is that the 2.82 on the Play Store is different from the version from Chainfire's website.
[SuperSU] jcmm11:
The following is a response by Chainfire in the beta thread (https://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133). You may want to read the last few pages of that thread as well to really catch up on everything

---------------------------------

Normally, the ZIP from the STABLE thread and the APK in the Play store are identical. The binaries inside the APK are also identical to the binaries in the ZIP. If they are not identical, it may be due to build system difference (the ZIPs posted here are built on my PC, the APK posted on the Play Store is built on one of CCMT's PCs), but if you pull them through a decompiler you should end up with the same code.

In this case I have posted a newer version here than on the Play Store with an additional bugfix for bootloops. Normally when this happens it gets labelled SR1, but the actual SR1 release is very close to done (I thought to have released it by now, but more Pixel/ODP2 issues delayed it), so this is very temporary.

Updating the APK through the Play Store only includes the bugfixes that are inside the APK or binaries. It is not uncommon for more fixes to be part of the ZIP installation script (though this is often limited to support for new devices), these fixes will only be applied if you re-flash SuperSU from ZIP.

At some point, APKs posted here and APKs posted on the Play Store may diverge. The Play Store rules and restrictions are becoming ever tighter, and I actually had to scrap some planned features recently because of it. I have also been considering porting the code to modify the boot image to SuperSU itself, and let it re-flash itself (ZIP like) right from the GUI. But this is one of those things that goes directly against several Play Store rules. It would makes sure you can always get the latest fixes, though.

I don't think CCMT is going to do another stable roll-out just to fix this issue. It will be a while.

Not me, but you're not the first I hear say this. Are there any more details you can give? From how long after boot? Which app notifications? Etc? The more words the better.

Please try v2.82 from https://download.chainfire.eu/supersu

If the problem persists, report back.

Thanks, but which device? Not all O DP2 devices are supported.
[SuperSU] iamaniff:
Nexus 5X
[SuperSU] Tecalote:
Great problems for all owners of Huawei Devices:

Since Huawei has removed the Loop Mount support from their Android 7 Firmwares it's no more possible to root Huawei Phones with the official SuperSU.

Since version 2.79 exists a modified version for Huawei Phones for EMUI.

It worked on most Huawei devices until the updated version 2.81.

But the code of SuperSU 2.82 is much different than in 2.81 and it seems very difficult to update also modified SuperSU EMUI5.0.

All owners of Huawei Devices would be very happy if the official SuperSU could include also Support for Huawei Phones - what is currently not the case at all

Just want to report.
[SuperSU] TheLawPL:
Hi, I also have bootloop problem on my Xperia M2 after SU binaries update. I flashed unSU zip, then special zip for Xperia users, still phone restars over and over again.
[SuperSU] Sr. Zé Alguém:
Are you taking about "UPDATE-SuperSU-v2.82-20170528234214.zip"?
[SuperSU] TheLawPL:
No, I'm talking about file SuperSU-v2.82-20170528234214-TEST-1.zip

UPDATE: flashed UPDATE-SuperSU-v2.82-20170528234214.zip - phone still has bootloop
[SuperSU] Sr. Zé Alguém:
These are the same file actually. You will need to wait for Chainfire to take a look at that. (I think he is going to post SR1 soon).

In the meanwhile, feel free to post material you think can help him fixing the problem (logs, description of steps to reproduce etc.).
[SuperSU] TheLawPL:
When my phone became bootloop I looked for help on r/Android Discord. Someone posted this ZIP to delete SuperSU https://www.dropbox.com/s/bhgpkuz5fqlncps/UPDATE-unSU-signed.zip?dl=0

I flashed zip linked above first (via TWRP's ADB sideload) then zip with fixes for Xperia phones but my Xperia still has bootloop (also via ADB sideload).

I hope this information will be helpful [MENTION=631273]Chainfire[/MENTION]
[SuperSU] mythos_:
I finally decided to upgrade to 2.82 today. I did it through the play store. Then I tried to update the binary but that wouldn't work. Tried 3 times (with reboots) but it still wouldn't work. I finally had to flash the zip from the first post. I have a Oneplus One with CM 13.0.
[SuperSU] toughcanny:
I wish someone to look into this problem, I am stuck now and hoping to back to my data
[SuperSU] DB126:
Although I do not have a solution there are two lessons to consider:

- backup/image your device regularly if data is important (use TWRP)

- encryption carries liabilities including inability to directly recover data and perform some types of diagnostics; refer to previous point on backups

I will also add accepting Play Store updates to critical components like SuperSU is never a good idea.
[SuperSU] Cluey:
If it's made it to the play store this shouldn't be a problem, however it seems it is now.

Very unimpressed with the way this has gone down, in the BETA thread [MENTION=631273]Chainfire[/MENTION] mentions that he doesn't think CCMT will be doing another Play Store update for just this problem. This is a terrible choice as it means there's an official release from, supposedly, the safest source which will just screw some users over. :(
[SuperSU] DB126:
In theory yes; in practice no. Not my first rodeo. I review and accept changes to each app individually and always set aside critical components like SuperSU until community consensus indicates all is well. Such best practices are not confined to SuperSU and Android. Anyone with a Windows box knows how unplanned boo-boos in supposedly well tested updates can ruin your day. Now waiting for a penguin lover to chime in with the faux claim that such things don't happen in Linux.
[SuperSU] yung40oz84:
I am using the superSU UPDATE-SuperSU-v2.82-20170528234214 and when trying to use systemless mode with Adaway it will not apply the host file. Then when I reboot device and go into to Adaway it says they are applied.... So I am confused, but I never got that error with 2.79 SR3. Log attached.
[SuperSU] pizza_pablo:
I've been rooting with SuperSU for only about 5 years ,but before reading this thread, I'd never read that updating via the notification, which I assume is from the play store ,was dangerous .
[SuperSU] jcmm11:
All software, including Linux (which by the way Android is a flavor of), has a major, unfixable, problem. It's created by humans. Humans make mistakes.

This is why god created backups, so we can recover from major screwups. (Not my first rodeo either ? ) I having no problem running beta, or even alpha, software but always know what you're installing (especially with critical components) and always preserve the ability to get back to where you were (or a reasonable facsimile of it).

Last rule. Stop running Windows, it's just a giant virus. Run Linux instead. (Just kidding about this last rule, sort of ? Linux rules ?)

---------- Post added at 04:47 PM ---------- Previous post was at 04:39 PM ----------

You may want to post that response in the other thread. I was simply quoting Chainfire in this one.
[SuperSU] iamaniff:
Sorry, I think im wrong post here
[SuperSU] ktmom:
I have no idea if this link, or this video, or this xda threadwill help you. I understand that supersu was a contributing factor to getting into this state, I doubt this thread will be your path out. Your best bet for questions is in the Lenovo Zuk Z1 forum.

---------- Post added at 12:28 ---------- Previous post was at 12:08 ----------

Chainfire addresses the bind mount problem in the beta thread. I can't keep all of the releases straight, but you probably flashed a version that was broken by O compatibility fixes. A quick work around is to uncheck "mount namespace separation".
[SuperSU] Wildcat2083:
Not sure if this is the right thread, if not please let me know, im looking to inform the dev for supersu that as of version 2.82 systemless on a verizon variant (systemless) samsung s7 SM-G930V the very latest supersu/pro can't uodate the binary im on nougat build G930VVRS4BQC9

Android 7.0 using the engineering kernel

this model Qualcomm has a locked bootloader so the usual twrp method will not work
[SuperSU] Ibuprophen:
To help out [MENTION=631273]Chainfire[/MENTION] (the Dev), a little more elaboration and clarification with your question is needed.

Please correct me if I'm wrong...

1) You had SuperSU v2.79 already installed and working on your Verizon Samsung Galaxy S7 (SM-G930V).

2) You had updated the app, v2.82, via the Play Store and, when prompted to update the SuperSU binaries, it had failed.

If I'm correct, so far, then please answer this (purely for clarification):

1) Is your device Rooted and the Bootloader unlocked with a custom recovery like TWRP installed?

2) When the binaries failed to install, did it indicate so during the install or did SuperSU initially state that the binaries were successfully installed but, whenever you rebooted the device, SuperSU just prompts you to install them (again)?

Providing those additional clarifications is important in specifying certain "what, where, when and how" to help in determining the best course to advise you with.

Thank you!

"Live Long and Prosper..."

~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
[SuperSU] Chainfire:
We're aware of the issue. I hope to have an officially supported solution in v2.82 SR2. Please keep your eye on the BETA thread. https://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133

There's an extensive post in the BETA thread detailing what happens and why it wasn't caught in testing. It certainly isn't the first update done by CCMT either.

After flashing unSU, try flashing back stock M2 firmware boot image before flashing the Xperia version of SuperSU.

SuperSU cannot currently (and will not in the future) update the binaries for the engineering kernel hacks. There are custom and one-of-a-kind roots. These are not officially supported at all. I suggest going back to the version that came with the root, and disabling auto-update on Google Play.
[SuperSU] pizza_pablo:
A VZW Samsung S7 with root?

I didn't know such an animal existed!

I thought rooting carrier Samsung phones went the way of the Note 4 and the dodo.
[SuperSU] rajkumar1221:
rooted lineage 14.1 os successfully, supersu is not getting updated , shows SU BINARY OCCUPIED , help to fix this
[SuperSU] Ibuprophen:
Though, that specific error is uncommon, I do remember seeing this happen to another member at one time (I can't think of where) but, I do believe that i remember how this member had solved it.

The member had either CM13 or LOS14.1... but, anyway, had discovered that the "Root access" setting within the "Developer Options" had changed, somehow, to "Disabled".

The member had changed it back to "Apps and ADB" (though changing it to "Apps only" or "ADB only" would have worked also) then had rebooted the device and tried SuperSU again and it was successful.

I can't guarantee that it will work but, that's what I remember how someone else had resolved this specific error on their device.

Just a friendly FYI to, hopefully, help you out...

***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
[SuperSU] Wolfcity:
As I read this here I have a similar problem. I'm on Asop Extended rom 7.1.2, not on the latest build but the one before. And the reason for that is when I flash the latest build (which has almost no differences to the one I use) after 10 or 20 minutes of usage superSU states "binary occupied'.

This problem appeared with sr3 2.79.

As I survived the issues with superSU 2.80 and using 2.82 now I gave it another try with the new SuperSU,complete clean flash and after 20 minutes: 'binary occupied'.

No other user has that problem with that build but it has to be something rom related hasn't it?

After a complete clean flash everything should be erased. It's no major problem for me, I just stay on this build but I would like to understand what's happening there. What's the exact meaning of 'binary occupied'?

I'm using a Moto G 2014 (titan).
[SuperSU] Chainfire:
'Binary occupied' is an unfortunate translation.

It means there's a su binary, but it isn't SuperSU. Some other root solution is occupying the su binary file.
[SuperSU] TheLawPL:
[MENTION=631273]Chainfire[/MENTION] What do you have in mind? Kernel? It's possible to flash stock kernel on BL?

BTW I want to save apps and data.
[SuperSU] redultra82:
Using a huawei ascend g7 and on EVERY boot, I get optimising system. changed to Masik and its gone

This never happened before
[SuperSU] redultra82:
5.1.1
[SuperSU] gustavojobim:
Still not working on my D6543 (Sony Z2)

Hello , I was victim of that binary update crash as well. The firmware I was using was a pre rooted D6543_23.4.a.1.232_Customized BR. I didn't check this forum before and in the end I was only able to use the phone again after flashing D6503_17.1.2.A.0.314_1281-2115.ftf wiping all data, then rooting etc. However, before reinstalling all apps, I accepted the super su update, and again my phone wouldn't boot anymore.

So once again I flashed to the .314 firmware, rooted, installed dual recovery and flashed the firmware I'm currently using, the D6543_23.4.a.1.232_Customized BR, and then I won't be accepting any more automatic super su updates until everything is fixed. Is that right? Sorry I couldn't read all forums messages if my question has already been answered.

Thanks.
[SuperSU] Wolfcity:
Ok, understood. But I never used any other root app than superSU. My rom comes unrooted. So why is it showing 'binary occupied' after a complete clean flash? Sounds like if there is some other root app inside the rom itself? Is there a possibility to check that? As the rom comes unrooted there is no magisk folder or anything like that. But as it happens only on the latest build and not on the one I'm on there must be a difference. Strangely enough nobody else reported that issue and it's a popular rom.
[SuperSU] vampirefo:
I see people using SuperSu on Lineage roms, but I don't understand why, Lineage provides their own root method.

I compile root in my lineage roms, for those lineage roms that don't have built in root lineage offers a installable root package.

http://www.lineageosrom.com/2017/01/download-supersuzp-and-su-removalzip.html
[SuperSU] manbat:
Some people just prefer SuperSU.....

Sent from my SM-N910V / VZW Note 4 DE / Factory Bootloader Unlocked / Rooted / Custom Kernel-ed/ TWRP 3.1.1-0.trlte
[SuperSU] martyfender:
The very same thought has crossed my mind, as well.
[SuperSU] vampirefo:
Yet they complain about it, while the root made specifically for Lineage works great, oh well to each their own I guess.
[SuperSU] Ibuprophen:
This thought just came to me (so BEWARE LOL!)...

[MENTION=631273]Chainfire[/MENTION], i was wondering if you would be able to confirm if the following idea will work.

Since you had stated that the SU BINARY OCCUPIED means there's a Non-SuperSU SU Binary file that was present (whether it's in the /system/xbin or /su/xbin).

What if/Could the member boot their device into their TWRP Recovery and delete that "SU" binary file and, if needed, rebooted the device directly back into the TWRP Recovery and attempted to install the SuperSU Flashable Zip.

Could it work?

I'm just thinking outside of the box a bit in hopes that I can make it back in... LOL!

***Please Note: As always, I welcome any member to help with further valuable information/clarification for any of my posts.

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise.
[SuperSU] CaptainNemo80:
Hello everybody,

Same issue here on my Nexus 4 Lollipop 5.1.1 (yes... old school.. i know).

Each reboot of my phone launch "optimizing apps" step... And this is a loooonnggg step...
[SuperSU] vampirefo:
That is interesting, I don't use systemless root on anything, so I never see this.

For that to happen for some reason or another dalvik-cache is being removed, so on boot up dalvik-cache is being created, the time it takes depends on the amount of apps one has installed.
[SuperSU] Wolfcity:
That's a good question and could maybe solve my problem with the latest build of my rom.

Btw, actually on my working rom su is found in su/bin instead of su/xbin...
[SuperSU] vampirefo:
If it's in bin, then it's in your ramdisk, so the answer is no, you can't remove it by deleting it, you would need to unpack boot.img and remove it.

If it's anywhere else, yes you could remove it.
[SuperSU] swallowingled:
I've got an old Nexus 4 running stock 5.1.1 and updated SuperSU a few days ago and haven't seen this issue. It's not installed as systemless if that makes a difference. I just turned it on and it started normally. I did get a quick 2 second Android is starting message but no optimizing of apps.
[SuperSU] Wolfcity:
Thx for that info.

For this rom there's no need to remove it as it is working well with superSU 2.82.

The point is that if I clean flash the latest version of my rom with gapps and superSU (no matter if 2.82 or SR3 2.79) after 10 or 15 minutes of usage with root previlegues I get the message 'binary occupied'.

So it would be a possibility to flash that rom without superSU and look what's inside system/xbin, su/xbin or su/bin. Even if the rom comes unrooted [MENTION=631273]Chainfire[/MENTION] stated that there has to be another root app when that message appears.
[SuperSU] CaptainNemo80:
Thanks for your answer. So i need to reinstall Supersu without "systemless" ? (sorry i don't understand this term)
[SuperSU] swallowingled:
No. On the Nexus 4 5.1.1 it installs to system by default so if you didn't force systemless you should be fine. I'm not sure what the problem could be to be honest. I can also say that I updated using the zip from Chainfire's website and did not update through the Playstore app.
[SuperSU] vampirefo:
Yes, if it's a normal rom, you could unzip it remove any su binaries files you find, rezip then flash.
[SuperSU] Wolfcity:
I did that an hour ago and also compared the both versions, the one that I'm using and the newer one with that binary issue. There are only marginal differences and no su files anywhere. As I said both versions should be unrooted and it really makes me wonder where some kind of rooting binary should come from.

Maybe it has to be installed to find out more.
[SuperSU] vampirefo:
The one you showed was in ramdisk, Usually that means you flash systemless SuperSU.

It unpacks boot.img adds su files and repacks it, have you checked the ramdisk on other rom?
[SuperSU] Wolfcity:
Not exactly. I found 3 files in boot.img, one was some kind of an archive. Will have a more accurate look there.

Thx for your help.