With all major changes to SuperSU, there are updates to both the GUI and binary. The GUI is the part you see on screen, the binary is what allows other apps to actually acquire root access. The first time you open SuperSU after such an update, it will attempt to update the binary to the latest version.
There are a lot of components to the binary and it needs to be set up just right for everything to work. This is a complex operation, and sometimes it fails. SuperSU is used by dozens of millions of users across hundreds of different devices, running even more different firmware revisions - any change always has the potential to break something somewhere.
SuperSU offers multiple ways of installation: in-app 'normal', in-app TWRP/CWM, and ZIP via TWRP/CWM. These all have their own strengths and weaknesses, so if one doesn't work, try the others if available.
If you are reporting an update failure, you should include at least the following information. Some information requires some skill with adb to retrieve.
- Exact device model
This includes the brand, the model, and the carrier variant (if applicable: mostly USA, Korea, China)
- Exact firmware version
Which exact firmware are you using? If you are using a custom firmware, please include a link to the download for this firmware. If on top of that, you are also using a custom kernel, please include a link to the download for that as well.
- Exact Android version
Android x.y
- Exact SuperSU version
Which version were you running, and to which version are you updating? If using Pro, do you have OTA survival mode enabled?
- Interfering apps
There are some apps that can interfere with SuperSU installation, primarily:
- other Superusery apps
- Xposed
- BusyBox (symlinked or non-symlinked)
Include in your report if you have one or more of these installed.
- Update methods tried
In-app 'normal', in-app via recovery, and ZIP via recovery. If you used one of the recovery options, please include exactly which version of which recovery you are using, and if it's not an official build (so a TWRP not from the TeamWin website, a CWM not from CWM's site, etc) a link to where you got it from.
Note that if you let TWRP or CWM "fix" root for you, or let them disable the firmware from flashing a new recovery (sometimes you are asked this), you have broken root, and the only way to recover it is flashing the full ZIP through recovery.
- What kind of root are you left with?
After a failed binary update, multiple outcomes are possible:
- Root is lost. Apps cannot get root anymore, you cannot get root using "su" from an adb shell, etc
- Root seems to mostly still work. Most apps still work, and/or "su" still works from an adb shell
- Nothing seems to have changed at all, even the GUI still shows the old version number
Report what state your device is in now. Note that you can get the version of the main "su" binary by running "su -v" from a terminal emulator or adb shell.
- Logs from TWRP, when updating the binary using the TWRP/CWM button inside the SuperSU app
After pressing the TWRP/CWM button, the device should reboot into TWRP, do it's thing for a few seconds, then reboot into Android. If SuperSU still complains about the binary, please retrieve the TWRP log file. You can retrieve it via adb pull /cache/recovery/last_log, which should produce the last_log file in your current directory. You still need at least partial root from booted Android to retrieve this log. Sadly it is wiped and replaced with a new file when you boot into recovery a second time, so you cannot retrieve it that way. Note that this log will always contain a number of errors, as the installer tries several things in several ways, that work differently on different firmwares. Attach this log file.
- Logs from TWRP, when updating SuperSU completely via ZIP
If after you boot back into Android, SuperSU is not working right or still asks for updated binaries, reboot back into TWRP, install the ZIP again. After the ZIP is installed, you can retrieve the log file via adb pull /tmp/recovery.log, which should produce the recovery.log file in your current directory. Attach this log file.
- Logs from SuperSU (very important)
If SuperSU keeps asking you to update the binaries after trying any which way and failing, please post the detection log. After updating has failed, don't reboot, but produce detection information via adb logcat -d | find /i "installer" > logcat.txt (Windows, use 'grep -i' instead of 'find /i' on Linux or OSX), which should produce a logcat.txt file in your current directory with several lines mentioning SuperSU. Attach this log file.
- Various logs (very important)
Some additional handy information can be gotten by via some adb shell calls. If you that working, copy/pasting the following commands should produce a nice sulog.txt file in your current directory, which you should attach to your post:
(as always with copy/pasting, make sure you press enter a few times afterwards to make sure the last line was flushed)
Code:
adb shell getprop > sulog.txt
adb shell set >> sulog.txt
adb shell toolbox id >> sulog.txt
adb shell busybox >> sulog.txt
adb shell su -v >> sulog.txt
adb shell su -V >> sulog.txt
adb shell su -h >> sulog.txt
adb shell su --self-test >> sulog.txt
adb shell ls -l /system/xbin/*su* >> sulog.txt
adb shell ls -lZ /system/xbin/*su* >> sulog.txt
adb shell ls -lZ /system/bin/toolbox >> sulog.txt
adb shell ls -l /system/bin >> sulog.txt
adb shell ls -l /system/xbin >> sulog.txt
adb shell ls -laR /su >> sulog.txt
adb shell ps >> sulog.txt
In closing
All this information will help diagnose the problem, and potentially help fix the issue if there is something wrong with SuperSU itself (which is not unheard of). The more information you provide, the better you can be helped. Still, be aware that often it takes a while to get a problem sorted. Even when a lot of people are having the same problem (and many problems may look the same but deep down are separate issues), it is rare to find a user who actively wants to help fix the issue. Most users will only complain but then don't really assist in solving the issue. If you can be someone who can actively help, and by that I mean being responsive to questions, being available for a live debugging session, etc, you are a rare gem indeed, and your assistance will be greatly appreciated.
If you are writing multiple posts, it is always helpful if you keep linking back to your original post with the report. Saves me time.
Sorry for the inconvenience!
SGH-T999
4.3
2.06 can update to 2.14 but binary update never takes
BusyBox but dont know what kind
In-app 'normal', in-app via recovery, and ZIP via recovery after that binary update still fails normal and via TWRP v2.8.0.1
Still have root
Update has make my Galaxy S5 is unusable...
After update I am unable to open any Google based apps, Gmail, maps, YouTube, etc. I get an error that says "Unfortunately, [app] has stopped.". Im also getting the "Unfortunately, the process com.google.process.gapps has stopped" error. What do I need to do? I did a factory reset hoping thats would fix the problem but it hasn't. It seems as thought it's not reading my SD card as well. It's showing I don't have pic or that one is even installed. I can make calls but that's about it. No Internet, no connections, no apps. Can't even sign onto my gmail to be able to download any app from the play store. I am out of town & without a computer until later tonight. Would re rooting fix my problem? I do not have recovery flashed onto my phone. It wasn't available when I rooted & I never got around to doing it. Pleasant Help! I have a titanium back up of my 0hone but can't download the application to try that avenue.
shadow322 said:
SGH-T999
4.3
2.06 can update to 2.14 but binary update never takes
BusyBox but dont know what kind
In-app 'normal', in-app via recovery, and ZIP via recovery after that binary update still fails normal and via TWRP v2.8.0.1
Still have root
Click to expand...
Click to collapse
As stated on IRC, I'm going to need the logs described above.
Emmie0702 said:
After update I am unable to open any Google based apps, Gmail, maps, YouTube, etc. I get an error that says "Unfortunately, [app] has stopped.". Im also getting the "Unfortunately, the process com.google.process.gapps has stopped" error. What do I need to do? I did a factory reset hoping thats would fix the problem but it hasn't. It seems as thought it's not reading my SD card as well. It's showing I don't have pic or that one is even installed. I can make calls but that's about it. No Internet, no connections, no apps. Can't even sign onto my gmail to be able to download any app from the play store. I am out of town & without a computer until later tonight. Would re rooting fix my problem? I do not have recovery flashed onto my phone. It wasn't available when I rooted & I never got around to doing it. Pleasant Help! I have a titanium back up of my 0hone but can't download the application to try that avenue.
Click to expand...
Click to collapse
Sounds unlikely to be due to SuperSU. Either way, there's nothing you can really do about it now. Situations like these I advise a factory reset and a data restore.
Chainfire said:
Sounds unlikely to be due to SuperSU. Either way, there's nothing you can really do about it now. Situations like these I advise a factory reset and a data restore.
Click to expand...
Click to collapse
I've done a factory reset & stoll have the same problem. How would I restore data?
Emmie0702 said:
I've done a factory reset & stoll have the same problem. How would I restore data?
Click to expand...
Click to collapse
You would restore the data from a backup you've made before resetting ?
In SuperSU you can try 'full unroot' from Settings (twice if necessary) and unroot, see if that resolves the slowness/crashing.
The only backup I have is a titanium backup. I can't get anything to download from the play store. I never flashes recovery because it wasn't available when I rooted. I never went back to add it (which I could kick myself for right now). Would re rooting help? Supersu isn't on my phone anymore either. I'm not sure what happened to that.
Edit: could the platform.xml under /etc/permissions/platform.x ml have anything to do with it?
Knox
Emmie0702 said:
After update I am unable to open any Google based apps, Gmail, maps, YouTube, etc. I get an error that says "Unfortunately, [app] has stopped.". Im also getting the "Unfortunately, the process com.google.process.gapps has stopped" error. What do I need to do? I did a factory reset hoping thats would fix the problem but it hasn't. It seems as thought it's not reading my SD card as well. It's showing I don't have pic or that one is even installed. I can make calls but that's about it. No Internet, no connections, no apps. Can't even sign onto my gmail to be able to download any app from the play store. I am out of town & without a computer until later tonight. Would re rooting fix my problem? I do not have recovery flashed onto my phone. It wasn't available when I rooted & I never got around to doing it. Pleasant Help! I have a titanium back up of my 0hone but can't download the application to try that avenue.
Click to expand...
Click to collapse
@Emmie0702 I think it's a weird Knox Action -i mean, It MAY happen 'coz Knox
Chainfire said:
Note that if you let CWM "fix" root for you (sometimes you are asked this), you have broken root, and the only way to recover it is flashing the full ZIP through recovery.
Click to expand...
Click to collapse
CWM is asking for that. I have to answer Yes or No. So I should click No ?
sorry wrong thread
Samsung N7100 Hong Kong (rom is UK)
N7100XXUFND3
4.4.2
2.14 pro
Don't have OTA survival mode enabled.
Before updating the SU, I can use the SU as usual. But after updating the SU binary via normal, it says I didn't install the execute file ( something like that, since I'm using Chinese), which means i haven't root.
So, do i need to re-root, then update the SU binary?
p220fhf said:
Samsung N7100 Hong Kong (rom is UK)
N7100XXUFND3
4.4.2
2.14 pro
Don't have OTA survival mode enabled.
Before updating the SU, I can use the SU as usual. But after updating the SU binary via normal, it says I didn't install the execute file ( something like that, since I'm using Chinese), which means i haven't root.
So, do i need to re-root, then update the SU binary?
Click to expand...
Click to collapse
You can give it a shot, rerooting via the ZIP ( http://download.chainfire.eu/supersu ) with TWRP. See if that helps, and let us know. If it doesn't fix the issue, I will find this firmware and flash it on my own N7100 (if possible) and see if I can replicate the issue.
SuperSU Problem!
I've rooted my device (GT-1335 - Android 4.4) with Windershare Rooting Toolkit, After rooting I've installed Root checker basic from the market and run it. It says your device is rooted. But when i wanted to go to root using FX explorer, it says you need permission from Advance user. When i click SuperSU after that it says that "There is no Su binary installed, and SuperSu cannot install it. This is a problem!", After that i checked whether my device is rooted or not with Root checker basic, but now its says that my device isn't rooted!
Please Help, and replay soon!
Note: My device isn't original samsung model!
super su still loading
After update super su in playstore my s4 octacore in app tab on supersu still loading but nothing happened...
I had problems with using Stock 4.4.4 on my i9305.
Was freezing/not opening, then when it did it wouldn't update.
So I went to the SuperSu site and downloaded the latest to instal via CWM.
Now working fine. Hope this helps someone.
Chainfire said:
You can give it a shot, rerooting via the ZIP with TWRP. See if that helps, and let us know. If it doesn't fix the issue, I will find this firmware and flash it on my own N7100 (if possible) and see if I can replicate the issue.
Click to expand...
Click to collapse
I tried to reroot on my s4, but nothing changes, when updating the SU to 2.14.
So, I think, maybe, the main problem is SU 2.14 on 4.4.2 and 4.3.
My s4 was 4.3 rooted, before the SU update, everything was fine. But after updating, the SU app said I didn't root. Then I updated my FW to 4.4.2(I9505ZHUFNB3), and used CF-root to root. Still ok, but when the SU updated to 2.14, thing happened again. (Now my s4 is temp unroot for playing game , but can't root again as it says "You didn't root")
Sorry for my bad English.
SuperSU 2.14 not working on s4 4.3
gokunjp said:
After update super su in playstore my s4 octacore in app tab on supersu still loading but nothing happened...
Click to expand...
Click to collapse
same problem here on my S4-quad-16G with samsung 4.3-stock, which was rooted mothns ago via AutoROOT+twrp2.7.01
p220fhf said:
I tried to reroot on my s4, but nothing changes, when updating the SU to 2.14.
So, I think, maybe, the main problem is SU 2.14 on 4.4.2 and 4.3.
My s4 was 4.3 rooted, before the SU update, everything was fine. But after updating, the SU app said I didn't root. Then I updated my FW to 4.4.2(I9505ZHUFNB3), and used CF-root to root. Still ok, but when the SU updated to 2.14, thing happened again. (Now my s4 is temp unroot for playing game , but can't root again as it says "You didn't root")
Sorry for my bad English.
Click to expand...
Click to collapse
same here update 2.14 from PlayStore f.cked-up the SuperSU app (i have waiting-donut on APPS and LOGS-tabs...)
Device stays rooted, and root-requests from other apps seems to work too, because there is a typical SuperSU-reuqest popup there....
So please fix the APP for Samsung 4.3 4.4 firmwares...
Versions 2.01+2.06 worked flawlessly.
what i have already tryed:
1) On the [Settings]-TAB: => UNINSTALL APP: Effect 'uninstalling...'-popup stays 4ever w/o effect
2) On the [Settings]-TAB: => UNINSTALL APP for a NEW SuperUserApp: Effect 'uninstalling...'-popup stays 4ever w/o effect
3) Booted into TWRP => INSTALL the SuperSU-2.14.ZIP, rebooting phone -> in SuperSU (the same waiting donuts on APPS/LOGS...)
Phone: i9505-OpenEUROPE quad-core/16G Samsung-stock-FW 4.3
Device I9505
Android Version: Stock 4.3 MKF
BusyBox v1.22.1
Wanam Xposed installed
Stock Recovery
Kingo Root
Google Play Update
Issue: After update from 2.13 to the latest 2.14 when supersu try to reinstall it stuck more than 5 minutes, I reboot my phone, reopen supersu but now in my "APPS" and "LOGS" I have some kind of neverending loop load, I can't manage to see my rooted apps there, and in my SETTINGS if I try to make some changes it stuck and need phone reboot, otherwise all my rooted apps work fine!
Chainfire said:
You can give it a shot, rerooting via the ZIP with TWRP. See if that helps, and let us know. If it doesn't fix the issue, I will find this firmware and flash it on my own N7100 (if possible) and see if I can replicate the issue.
Click to expand...
Click to collapse
I think i figure out the problem, is the SU bin update. My note 2 is rooted and is using SU 2.14 pro, but i don't update the bin. It works fine, but when opening the su app, it asks you to update the bin.
Starting with Android 4.4 (KitKat) Better Battery Stats (BBS) require installation as system app to be able to collect the stats.
BBS must re re-installed as system app after each ROM upgrade (upgrade that does not preserve third party system apps).
I have found an alternative to this - the required permissions can be granted to BBS when it is installed as a regular user app by running these commands in Android Terminal (or ADB shell session):
Code:
su
pm grant com.asksven.betterbatterystats android.permission.BATTERY_STATS
pm grant com.asksven.betterbatterystats android.permission.DUMP
After using these commands it might be required to restart BBS process (e.g. reboot the device). Permissions granted this way will be preserved across ROM upgrades (even across those completely overwriting /system partition).
This has been tested on CyanogenMod 12.1 nightlies (Android 5.1.1).
Update! This post on BBS thread describes a related method for granting (at least part of) the permissions without root.
Hi DavisNT,
I'm confirming that your adb code appears to be a successful workaround for the normal version of BBS downloaded from the Play Store when the phone is running Lollipop. I'm running the paid version of BBS, on the current CM12.1 Nightly (jfltetmo for my T-Mobilr SGH-M919 Galaxy S4).
Procedure:
1. Install BBS from the Play Store.
2. Use ADB (easy to cut and paste from here) or another terminal program (you'll be typing) to install the code.
3. Reboot the phone.
You'll notice that when you launch BBS, CM's "Privacy Guard" will see that BBS is trying to gain root access, and will prompt you to allow this. I selected "Always Allow" until I'm done my battery testing. You'll notice that you now see "#" up on the phone's status bar. That indicates an app is running with root access. You could probably quiescence this by choosing "Ignore" via Privacy Guard.
Could the developer please approve that this relatively easy workaround is kosher?
Thanks . . .
Moved to main thread to avoid orphan
For apk downloaded from xda change the code to
pm grant com.asksven.betterbatterystats_xdaedition android.permission.BATTERY_STATS
pm grant com.asksven.betterbatterystats_xdaedition android.permission.DUMP
I tried this method, but failed on the BATTERY_STATS permission, the error said this 'permission type is not changeable'
is this method still valid?
andycjw said:
I tried this method, but failed on the BATTERY_STATS permission, the error said this 'permission type is not changeable'
is this method still valid?
Click to expand...
Click to collapse
On what version of Android did this fail? And was 'su' used before 'pm grant'?
Same problem. I'm on CM, Android version 4.4.4. Used 'su' before.
bobcote said:
Same problem. I'm on CM, Android version 4.4.4. Used 'su' before.
Click to expand...
Click to collapse
Most likely this method works only on Lollipop and Marshmallow.
Looks like on KitKat BATTERY_STATS permission does not have development in its protectionLevel, but on Lollipop and Marshmallow it has.
I assume (please correct me if I am wrong, preferably with link to some authoritative documentation) that development in protectionLevel allows a permission to be granted by pm grant command.
Thanks
I can confirm that this method works flawlessly for the Sprint version of the Galaxy Note 3 5.0. Many thanks.
Guys where is the main thread? Pls ?
DavisNT said:
Starting with Android 4.4 (KitKat) Better Battery Stats (BBS) require installation as system app to be able to collect the stats.
BBS must re re-installed as system app after each ROM upgrade (upgrade that does not preserve third party system apps).
I have found an alternative to this - the required permissions can be granted to BBS when it is installed as a regular user app by running these commands in Android Terminal (or ADB shell session):
Code:
su
pm grant com.asksven.betterbatterystats android.permission.BATTERY_STATS
pm grant com.asksven.betterbatterystats android.permission.DUMP
After using these commands it might be required to restart BBS process (e.g. reboot the device). Permissions granted this way will be preserved across ROM upgrades (even across those completely overwriting /system partition).
This has been tested on CyanogenMod 12.1 nightlies (Android 5.1.1).
Click to expand...
Click to collapse
Does this method work on marshmallow?
Thank you
RoxAbout said:
Does this method work on marshmallow?
Thank you
Click to expand...
Click to collapse
Most likely yes. Feel free to test. [emoji2]
Can anyone post BBS apk please!! TQIA
Thanks dude. The command for xdaedition worked flawlessly on my RR rom. Android 6.0.1 Galaxy S3
Worked! Thanks.
Does this works on a non-rooted phone? if it works, is uninstalling as simple as accessing app under setting to uninstall?
Thanks.
nuthing03 said:
Does this works on a non-rooted phone? if it works, is uninstalling as simple as accessing app under setting to uninstall?
Thanks.
Click to expand...
Click to collapse
AFAIK This method should NOT work on non-rooted phones (but you can still try it :fingers-crossed: ). If it will work, uninstalling the app (via Settings - Applications) would also revoke the granted permissions.
Original Thread here: http://bit.ly/1ov1NNy
Can confirm that the workaround is OK on Samsung S6 with Android 6.0.1 (stock DTM/rooted).
Best regards
Glad I found this, thought BBS was bugged when it kept wanting the BATTERY_STAT permission despite having the XPosed module :\
Executing those 2 lines fixed the problem.... wonder why it's not like that by default. I even checked AppOpsXposed and didn't see anything about DUMP/BATTERY_STAT
Installing BBS into /system would break OTA, no? I've read somewhere the claim that it doesn't--maybe even in the app itself
Hello, new user here.
Since I stuggled with root on my Phone and somehow managed to maintain it, I thought, I 'd share you the stuff I did with you.
I put the TL;DR between hide, if you want to read the story behind my struggle anyway, you are welcome.
I am better with explaining stories then explaining things.
Spoiler
I am using a Samsung S4 mini, Stock ROM and just don't want to flash a cROM.
But I wanted more functions to do - a swiss knife like my old GT-S3650, which was able to boot a PC from.
Most of the things I want to use need root, so why not rooting this sleep S4 mini baby?
And I managed to root it using Kingroot. And all of the things I want to use worked.
After a few days, I noticed network traffic, even with the most network apps and Sync disabled.
Weird? Yes. So I installed "Shark" on my Phone and "Wireshark" on my PC, and started logging.
I noticed an increase of Jabber (the protocol) and a lot of request on domains from China.
Some requests even included my IMEI, how I am connected to the Internet, etc... pretty private Stuff.
I found most of the sources, the IMEI sending App was Shark itself.
Used Lucky Patcher to get rid of it and /etc/hosts blocked the DNS with Hosts Editor.
Did the same with some Kingroot DNS.
But then I asked myself: "Can Kingroot still root my phone, even when cut of the web?".
So I UNROOTED my Phone from Kingroot. Bad idea. Really bad one.
After I ran Kingroot again, it told me, it didn't have a network connection.
I have no idea how I was able to edit the hosts file without SU.
Rerooted the Phone, even if it left a bitter taste of having unwanted network traffic.
This is which made me want to switch to SuperSU.
I tried to mount system as RW prior and installing SuperSU over Kingroot SU. And it failed.
I even tried to make my own uninstall script to uninstall KR by unpacking the Kingroot APK and look what it does.
Not working, the script failed (I am not used to Linux), so I stayed at Kingroot.
While I was working on Kingroot, I was thinking about the idea of having 2 SU Apps, which everyone said it won't work.
But I wanted it to make work - and this is actually the focus on this topic.
During tests, it didn't work as intended, so I stopped working on it and forgot it overtime, resting within my /system.
Days passed, Weeks and Months and I lived with Kingroot, forgot all the trouble and access to/from China.
Recently, I started SuperSU - it was still on my phone. This "cannot install su binary" nagged me and thought:
Oh, why not use this instead.
And then there was SuperSuME... which I didn't want to use, since I was able to brick BlueStacks with it.
But I really wanted to get rid of Kingroot and use SuperSU. This was yesterday.
My phone still has warranty and I think I have Odin here (just in case), but not the 100% exact ROM file.
So I did SuperSuME anyway -I always could return the phone and claim it "broken after OTA update", lol.
Well, SuperSuME did it's Job better then expected and no bricks. Nice Job.
While playing around with SuperSU, I did another mistake.
And here we are... at the main topic.
TD;TR for those who didn't want to read the story:
I rooted my phone 2 times with Kingroot and finally wanted to switch to SuperSU.
After I accidentally broke Kingroot the first time, blocked it's Internet access and unrooted afterwards, I got stuck with a unrooted phone and Kingroot failed to root it.
I was lucky to fix that problem and rooted again with Kingroot.
After months, I used SuperSUME to change that. After SuperSU was installed, i made the mistake of unticking "Enable Superuser". Bad idea.
Tapping "Enable" again, it failed to update the su-binary. oh god. I unrooted again.
While traversing through my directories to start Kingroot again to root, I found my "shadow copy" of SU.
Wut? Shadow copy? Let me explain:
After my first unroot, I wanted to have a SU backup anyway at all costs, just in case I accidentally messup root again.
Now after hours I think I know why it doesn't work.. the normal way, of course.
I installed SuperSU, went into /data/data (or where ever SuperSU has its files) and took a look at them.
Unpacked the SuperSU APK on the PC and gathered all "needed" (I think were needed) files.
I hexedited the most SU binaries from SU to ZU and changed all other referenced binaries as well.
I am sorry about that, Chainfire. I was just testing things.
SU => ZU
SUpolicy => ZUpolicy
setup_su => setup_zu
99SuperSUDaemon => 99SuperZUDaemon
daemonsu => daemonzu
zygote => zugote
I had no idea what sukernel was for, so I left that out.
Why call it ZU? "Sun Tzu" thats why. Known as "Sunzi", he wrote Book about "the Art of War".
After I made sure everything is properly renamed and edited, I moved them onto my phone in the right directories required and chmod them.
I don't know much about that, I just copied the chmod numbers from Kingroot SU and some weird script I found on the web.
Tried to run it using JuiceSSH local terminal, and BAM!! the SuperSU box popped up.
But pressing "Allow" accepted it and nothing else happened.
It became stuck after ZU... it did nothing, but the daemon was running as daemonzu and daemonsu at the same time..
JuiceSSH popped up in SuperSU (while it told me the SU bin was outdated), though.
So I was on the right track, but a piece of the puzzle was missing, so I stopped delving deeper into it.
And forgot about it until about yesterday - where I disabled "Superuser" in SuperSU.
Midwhile the su binary changed from Kingroot SU to SuperSU SU.
Note: It should really ask "Do you want to disable Superuser? SuperSU will delete su binary" Yes/NO.
As I found those files, I started JuiceSSH and typed "zu".
This time, ZU somehow worked like it should.
It spawned a root shell. OMG...
I guess it somehow requires something else needed, which wasn't working while Kingroot was active.
I tried "Root Checker" and it failed. I had no "official" root. But still root available in JuiceSSH.
Somehow I managed to restore SuperSU to normal status. Guess this thing can latch onto an active root user or so.. no idea.
I even screenshotted this, cause I couldn't believe it. If you want, I can post those.
I have now a working second su on my phone, which is hidden from most apps.
But I think it is not perfect, it relies on something SuperSU does or installs during installation.
I apologize again to Chainfire for editing his stuff.
So, now my questions:
1. How can I make it perfect to run standalone, only using SuperSU as a GUI for (Allow/Deny)?
1b. Can we make it part of SuperSU? As a special function: "Install Stealth SU"?
2. Can we use that for something else? -> Probably for this? http://forum.xda-developers.com/apps/supersu/suhide-t3450396
3. Why must the binary be called SU? I know it's for the most apps to do their job and somehow Linux standard.
So, an OTA caused a loss of root (pixel 6 pro, unlocked). Tried to go into a hidden magisk and disable modules, but everything greyed out, unable to. Tried to uninstall the manager (I was using an old MagiskAlpha build), and thought it worked, though it must have left something behind. Updating wouldn't work - would give me a failure.
Flashed new factory image, installed new magisk manager, patched boot.img in new magisk manager, loaded boot.img, and I have root; adb shell su works, all my old apps that worked with root work, but no magisk manager recognizing that I have root - and therefore no modules - working. So, no charging management, safetynet is borked, etc. Have uninstalled/reinstalled mm numerous times. No luck. Tried loading it from adb, etc.
I've dug through adb shell pm list packages and can't find anything that looks like an old version of magisk at all anywhere anymore. I think I had three different versions on the phone. They are all gone. But no luck with a freshly installed manager. Still can't see root even though it's there. Any ideas?
Of note: I have a work profile and two users on the phone. However, I can't find anything even using --user for all three users. Only thing even close I see is com.lsposed.manager still installed. That shouldn't be a factor, but I can't think of anything at this point.
TB checker, under "check root" gives pass for everything except SU binary, 2nd SU binary, root via native, and magisk specific.
Under Check xposed, I have fail for dual/work profile and xprivacyLua, and com.topjohnwu.magisk under PM Sundry APIs. Everything else is Pass.
I had never granted TB checker root before; Termux on the other hand works fine with su (as does adb shell), and Root Essentials shows root fine.
Magisk Manager was downloaded from topjohnwu's github, then I manually added the canary URL, and updated to canary. No luck.
Any other ideas?
One other thing... /data/adb/magisk was dated; all the other directories in /data/adb were new, but magisk was from my last update of MagiskAlpha, and when I looked at util_functions.sh it was aligned to my old (uninstalled) magisk alpha build
So, the /data/adb/magisk tipped me off. I pulled the hidden apk info from the magisk.db, and from there was able to (while rooted) manually delete all the references to the hidden apk string (just did a find /data/* | grep [hidden package name] ) and once they were all deleted, deleted everything from /data/adb - the magisk.db and everything - and then next time I went into magisk, it informed it was incorrectly configured, I pressed okay, it fixed itself, and full root in magisk was restored.
had to reinstall all modules, but that wasn't a very big price to pay. Safetynet fixed (google pay worked just fine at the store yesterday), xprivacylua, etc., all worked.
As of right now, other than a citi app *****ing that I'm possibly rooted (and then it still works fine anyway), haven't had any issues with leaving magisk unhidden, so not going to hide it again unless I need to. Wasn't worth the PITA to fix it if something like this happens again.