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