I've had an automatic reboot enabled on my phone for well over a year now that has worked perfectly using the process described here:
http://tasker.wikidot.com/devicereboot
This morning I had a notification that my SU binary was outdated asking if I wanted to update to. I updated, and now I can't get a prompt for the Tasker/Locale Execute Plug In action to give it root privleages. I get a SuperUser prompt for other apps, Titanium, Voltage Control, Root Explorer, etc, but for some reason the Locale Execute Plug In get's automatically denied without any prompt whenever it requests root privileages. This is confirmed by viewing the log.
Any ideas?
Ok, more info..
Manually rebooting the phone seems to partially downgrade the SU binary.
I get the notice that a new version of su binary is found.
Code:
Downloading manifest... okay!
Parsing manifest... okay!
Latest version = 3.0
Checking installed version = 2.3.1-ef
Fixing database... okay!
Downloading custom busybox... okay!
Checking md5sum... okay!
Checking current install path... /system/bin/su
Downloading new binary... okay!
Checking md5sum... okay!
Gaining root access... okay!
Remounting /system as rw... okay!
Copying su to /system... okay!
Checking md5sum... okay!
Moving su to it's final location... okay!
Checking md5sum... okay!
Changing su file mode to 06755... okay!
Remounting /system as ro... okay!
Checking installed version = 3.0
Cleaning up... okay!
It seems to be stuck in this endless loop now.
Every time I reboot the phone it reverts back to the older (working) SU binary and tells me a newer version is available. If I upgrade the SU binary, then my Tasker reboot is broken AND any reboot reverts the SU binary version back to the old one.
I'd be fine leaving the older SU binary on there and just ignoring the notification to update, but when it notifies of an update/newer SU binary it disables the ability to remember your SuperUser choices (Allow/Deny) for apps so either I have to manually allow any root apps every time they need access or change my Super User settings to always allow instead of prompt which isn't exactly ideal or safe.
Any thoughts or ideas?
Cross-posting for visibility...
Looks like others (Epic users) are having the problem as well with the SU binary update.
http://forum.xda-developers.com/showthread.php?t=1279238
In that other thread, the person get a message, that his su binary is installed in /sbin. That means it is in the ramdisk of his boot image.
su should be in /system/xbin, then it can be replaced. if placed in the ramdisk, you need to replace/modify the boot image, to change it.
Per
I don't have the problem with updating the binary, but I do have the same problem with the updated binary.
I've emailed the developer to ask him if there is a fix. I think what he's done is limit it to run only with the exact command you first grant.
So if you're using the Locale execute plugin to try running more than one command only the original command you allow is allowed and all others are denied.
Even setting the default to Allow doesn't help.
Hopefully he'll have a fix.
I'm noticing the same behavior with new Superuser. It no longer prompts to allow Locale Execute Plugin, just waits until the request times out and flashes that the permissions were denied.
I can't figure out how to execute Locale Execute Plugin in a manner that the new Superuser will prompt the request, nor haw to manually add it as allowed.
And this is a single line Tasker Execute, so it's not related to hastarin's comment.
Yes, it does seem to be a bug caused with the new su.
For anyone still stuggling, I managed to get my commands to run with this instead of the Locale Execute Plugin:
http://forum.xda-developers.com/showthread.php?t=1217767
Not sure if this is still relevant however I registered to post anyway.
Ran into this problem and couldn't find any answers so I fiddled around on my own.
By checking the "Advanced Prompt" option in Superuser's preferences I managed to get a prompt to appear and allow the locale execute plugin su permissions.
[FIXED]
Thank you all for the support! I was facing the same issue which Tasker had no root access.
The solution for me was checking the "Enable Permission Warning" option in SuperSU as in the attachment...
Related
Hello,
When I run adb shell, it reports back with a "$,"even though I do have root. I'm running JoeyKrim Stock With Root ROM. Odexed...
I do have superuser installed with the latest binary, and latest official busybox. Terminal emulator even detects that I have root.
Basically everything works as it should, except adb. Anybody know what's going on?
Rydah805 said:
Hello,
When I run adb shell, it reports back with a "$,"even though I do have root. I'm running JoeyKrim Stock With Root ROM. Odexed...
I do have superuser installed with the latest binary, and latest official busybox. Terminal emulator even detects that I have root.
Basically everything works as it should, except adb. Anybody know what's going on?
Click to expand...
Click to collapse
When you type adb shell, does it immediately report back with a $, or does it pause for a few and then report back with a $? If it pauses for a few seconds, look down at your phone during that time. You may be being prompted with the super user request prompt, where you need to hit allow. I'm not sure why you need to do this sometimes, but I've had it happen before. If you don't look at the phone and hit 'allow', then it times out and doesn't give you root access. So type 'adb shell', check out your phone and see if your prompted, if so allow it, and you should be good. If that is not the case, then I'm unsure what could be causing it.
k2buckley said:
When you type adb shell, does it immediately report back with a $, or does it pause for a few and then report back with a $? If it pauses for a few seconds, look down at your phone during that time. You may be being prompted with the super user request prompt, where you need to hit allow. I'm not sure why you need to do this sometimes, but I've had it happen before. If you don't look at the phone and hit 'allow', then it times out and doesn't give you root access. So type 'adb shell', check out your phone and see if your prompted, if so allow it, and you should be good. If that is not the case, then I'm unsure what could be causing it.
Click to expand...
Click to collapse
Thanks, I'll test that out. I have a pin set on superuser. Maybe that's the issue.
Just checked, and it does it right away, and does not prompt... Sigh...
Rydah805 said:
Just checked, and it does it right away, and does not prompt... Sigh...
Click to expand...
Click to collapse
Very strange. I'm not sure. Has it happened on all roms, or just the one you're currently on?
Sent from my PG86100 using Tapatalk
Rydah805 said:
Just checked, and it does it right away, and does not prompt... Sigh...
Click to expand...
Click to collapse
The first time you type su from adb shell, Superuser will display a prompt on the screen to accept or deny the request. If you don't accept the request, in adb shell it will display, "Permission denied".
On the Superuser prompt, if you select deny, when typing su in adb shell the result will always be "Permission denied" until going into the Superuser app and changing "Unknown" to Allow. Not sure why the Superuser app labels adb shell as "Unknown".
Another option, inside the Superuser app, on the Settings tab, at the very bottom there is an option, update su binary. Sometimes using this update feature will resolve permission/installation issues with the su binary.
If you wanted to verify the installation of both Superuser and root as having been done properly, my free app Root Check from the market works well. Advanced Mode should provide all the details we'd need to troubleshoot further.
Hope that helps and appreciate your support!
joeykrim said:
The first time you type su from adb shell, Superuser will display a prompt on the screen to accept or deny the request. If you don't accept the request, in adb shell it will display, "Permission denied".
On the Superuser prompt, if you select deny, when typing su in adb shell the result will always be "Permission denied" until going into the Superuser app and changing "Unknown" to Allow. Not sure why the Superuser app labels adb shell as "Unknown".
Another option, inside the Superuser app, on the Settings tab, at the very bottom there is an option, update su binary. Sometimes using this update feature will resolve permission/installation issues with the su binary.
If you wanted to verify the installation of both Superuser and root as having been done properly, my free app Root Check from the market works well. Advanced Mode should provide all the details we'd need to troubleshoot further.
Hope that helps and appreciate your support!
Click to expand...
Click to collapse
Yep that does work on his rom the "type su" thing and thanks for your root check app Joey it's been super useful in trying to figure out stuff lately on the photon.... really appreciate all your contributions
joeykrim said:
The first time you type su from adb shell, Superuser will display a prompt on the screen to accept or deny the request. If you don't accept the request, in adb shell it will display, "Permission denied".
On the Superuser prompt, if you select deny, when typing su in adb shell the result will always be "Permission denied" until going into the Superuser app and changing "Unknown" to Allow. Not sure why the Superuser app labels adb shell as "Unknown".
Hope that helps and appreciate your support!
Click to expand...
Click to collapse
Got it! Thanks! Any idea why I had to do that with your rom though? On others, I didn't need to type Su and grant it. (Doesn't bother me though.)
Rydah805 said:
Got it! Thanks! Any idea why I had to do that with your rom though? On others, I didn't need to type Su and grant it. (Doesn't bother me though.)
Click to expand...
Click to collapse
Short answer: Since Superuser.apk is another developer's software, I didn't include it in my ROM as I didn't have his permission. I provide the superuser apk market link in my ROM OP for users. Instead of packaging Superuser apk, I used the su binary provided in AOSP as its source code is public and publically available for android usage.
Long answer: There is a free version of Superuser available thru the market and figured that would be the best way to load the Superuser apk. From personal experience as an android developer, when an app is provided with a ROM, it doesn't appear in the developer's market statistics and essentially is "off the radar". Which makes it more difficult to track which devices have loaded the software, which versions of android, etc and makes it more difficult to prioritize software upgrades to the application.
Hope I was able to explain and it helps!
joeykrim said:
Short answer: Since Superuser.apk is another developer's software, I didn't include it in my ROM as I didn't have his permission. I provide the superuser apk market link in my ROM OP for users. Instead of packaging Superuser apk, I used the su binary provided in AOSP as its source code is public and publically available for android usage.
Long answer: There is a free version of Superuser available thru the market and figured that would be the best way to load the Superuser apk. From personal experience as an android developer, when an app is provided with a ROM, it doesn't appear in the developer's market statistics and essentially is "off the radar". Which makes it more difficult to track which devices have loaded the software, which versions of android, etc and makes it more difficult to prioritize software upgrades to the application.
Hope I was able to explain and it helps!
Click to expand...
Click to collapse
Gotcha, I'm not complaining, just wondering why. I've always loved your roms over any others. Any way I can easily set it to use the superuser app binary over aosp binary?
ADB starting with root depends on the ro.secure property; if you type "getprop ro.secure" it should show either 0 meaning ADB keeps root or 1 meaning you have to use su for root. Just about all custom kernels/ROMs use unsecured boot.imgs but you can always change it yourself by modifying the default.prop file packed in the boot.img.
This is also what people are referring to when they say the kernel/boot.img/rom is secured or unsecured.
Rydah805 said:
Got it! Thanks! Any idea why I had to do that with your rom though? On others, I didn't need to type Su and grant it. (Doesn't bother me though.)
Click to expand...
Click to collapse
xHausx said:
ADB starting with root depends on the ro.secure property; if you type "getprop ro.secure" it should show either 0 meaning ADB keeps root or 1 meaning you have to use su for root. Just about all custom kernels/ROMs use unsecured boot.imgs but you can always change it yourself by modifying the default.prop file packed in the boot.img.
This is also what people are referring to when they say the kernel/boot.img/rom is secured or unsecured.
Click to expand...
Click to collapse
Rydah805 said:
Gotcha, I'm not complaining, just wondering why. I've always loved your roms over any others. Any way I can easily set it to use the superuser app binary over aosp binary?
Click to expand...
Click to collapse
Ah! Your question in the first quote above could be intrepreted two different ways. I provided one answer for one intrepretation and Haus provided the other answer for a different intrepretation!
I'll try and bring both together. There are two primary ways to access the shell interface on an android device.
1) Via adb shell. When typing adb shell and it opens the connection to the device, by android standard, it drops you to a shell with non root access reflected with the $ prompt. As Haus articulated above, this can be modified in the /default.prop file inside the ramdisk of the boot.img file. There are two options, have adb shell drop to root access or have adb shell drop to non root access. Many custom kernels modify this option so the user drops to root access.
In my kernel I'm using a non-modified stock kernel so it drops to non root access. I prefer to have to type su, once in the shell, to elevate to root access. Mainly because most functions I perform in adb shell I don't want root access for.
2) Via terminal emulator/connectbot. When accessing the shell directly on the device thru one of the common android applications, these generally open up a standard "sh" or non root shell. Then by typing "su" the user can elevate to root access (if the device has the su binary, etc.).
There are two main options for how to handle the "su" command inside a shell on the android device.
1) Superuser.apk - this application provides its own su binary, which hooks into the android application. Whenever su is called, the Superuser application is therefore called and allows the user to accept/deny root access requests.
2) su binary - from aosp or busybox. this is a version of the su binary more common to android developers in aosp, or the busybox version is more common to a generic linux version. the aosp version of su will grant any user/application root access. the busybox version will grant any user/application root access but does rely on an /etc/passwd and /etc/group file for permissions.
To answer your previous question, why you haven't had to type su on other custom ROMs, as Haus explained, they probably modified adb shell access in the /defult.prop file to automatically elevate adb shell to root priviledges.
To answer your last question regarding Superuser.apk and aosp su. Once you install the Superuser.apk file and it properly installs its own version of the su binary, it has now overwrite the previous aosp su binary. Superuser will now control all root access requests. Once you grant an application, adb shell, titantium backup, root explorer, or whatever application root access with Superuser, it will not prompt again and will handle every future request with the default action (grant/deny) provided.
Hope the extra details help!
Thanks, wasn't trying to be a pest. Just curious. The info in this thread is a nice thing to know.
I recently won this developer tablet and I can't seem to get on-device root access. It came with su binaries installed. (very old ones but I updated it) It also has an unsecured kernel because ADB always runs as root. However I installed superuser and it can't get root access and when other apps attempt root access something seems to be denying access before the superuser prompt is even able to come up. Just curious if anyone has any ideas??
JBO1018 said:
I recently won this developer tablet and I can't seem to get on-device root access. It came with su binaries installed. (very old ones but I updated it) It also has an unsecured kernel because ADB always runs as root. However I installed superuser and it can't get root access and when other apps attempt root access something seems to be denying access before the superuser prompt is even able to come up. Just curious if anyone has any ideas??
Click to expand...
Click to collapse
This may seem like a stupid suggestion but I suppose you could try uninstalling the superuser app and use Chainfire's Super SU app to see if that might make any difference.
Tried that too lol. I was even able to go into old su app and toggle permission for super su to allowed and it still said fail when it tried to update binary. Thanks for the suggestion though. It seems to me the problem is that the chown and chmod commands are not sticking on the su binary. They appear to work but the actual ownership and permissions of the file don't change. Even when I do adb remount first.
I figured it out. For some reason I had to put the su binary in /system/bin instead of xbin. Which is strange because all my other device it went in xbin. Also the reason the chmod and chown commands were not working properly is because I forgot to do adb remount. (duh!) In case anyone is wondering this thing is a beast. I just wish I could figure out a way to get my Gameloft games to work. I (mainly modern combat 3 and nova3)
JBO1018 said:
I figured it out. For some reason I had to put the su binary in /system/bin instead of xbin. Which is strange because all my other device it went in xbin. Also the reason the chmod and chown commands were not working properly is because I forgot to do adb remount. (duh!) In case anyone is wondering this thing is a beast. I just wish I could figure out a way to get my Gameloft games to work. I (mainly modern combat 3 and nova3)
Click to expand...
Click to collapse
One way to get your games to work would be try side loading the Modern Combat 3 and Nova 3 APK's onto the device and installing them manually that way. Another way if that doesn't work is you could try modifying your build.prop and changing your product id to match the galaxy nexus that way the play store will think your on a galaxy nexus and it should say that the games are compatible then.
JBO1018 said:
I figured it out. For some reason I had to put the su binary in /system/bin instead of xbin. Which is strange because all my other device it went in xbin. Also the reason the chmod and chown commands were not working properly is because I forgot to do adb remount. (duh!) In case anyone is wondering this thing is a beast. I just wish I could figure out a way to get my Gameloft games to work. I (mainly modern combat 3 and nova3)
Click to expand...
Click to collapse
I know this is an older post but I'm at the same point where I can't figure out how to allow superuser access. I'm using the 8064 for research and I need the root access but can't seem to figure out how to update the SU. Any tips?
mcforan said:
I know this is an older post but I'm at the same point where I can't figure out how to allow superuser access. I'm using the 8064 for research and I need the root access but can't seem to figure out how to update the SU. Any tips?
Click to expand...
Click to collapse
Do you have the Superuser.apk app installed along with the SU binary in the correct place /system/bin as mentioned by JBO1018? If you already had working root access before on the device and just need to update the SU binary you can open the Superuser app, then go under the info tab and tap on the SU binary version number this should then check for updates and then ask you if you want to install any found updates.
shimp208 said:
Do you have the Superuser.apk app installed along with the SU binary in the correct place /system/bin as mentioned by JBO1018? If you already had working root access before on the device and just need to update the SU binary you can open the Superuser app, then go under the info tab and tap on the SU binary version number this should then check for updates and then ask you if you want to install any found updates.
Click to expand...
Click to collapse
I have both the Superuser.apk and SU binary in the right place. Each time I open up an app that needs root access a toast message pops saying that the app has been denied Superuser permissions. I tried restarting both apps but its not working.
mcforan said:
I have both the Superuser.apk and SU binary in the right place. Each time I open up an app that needs root access a toast message pops saying that the app has been denied Superuser permissions. I tried restarting both apps but its not working.
Click to expand...
Click to collapse
Try going into the Superuser app and under settings and then security the default behavior is set to prompt not deny.
Sent from my SCH-I535 using xda premium
join have a tablet TIR 8960 is preloaded with windows rt, tablet says about the problems of the system,
Hi XDA Community,
Your forums have helped me in the past and I spent some time scouring the posts before posting this one as I couldn't find anything that was specific to my issue. Since this is my first post, I thought that I would save a ping pong of responses, by being fairly expansive on what the problem is and what I have tried; thus hoping to pinpoint my issue a little quicker.
Device Details:
---------------------
Model Number: GT-I9100
Android Version: 4.0.3
Kernel Version: [email protected] #3
Build Number: IML74K.XWLP3
ROM Firmware: Samsung-Updates.com-GT-I9100_O2U_1_20120326173406_jiut50pyip.zip (via Samsung Kies)
Rooting Method / Kernel: Odin3v185 / CF-Root-SGS2_XX_XEO_LPQ-v5.3-CWM5
Summary
--------------
Since the beginning of July 2012, I successfully upgraded from Gingerbread v2.3.6 to ICS v4.0.3 using Samsung Kies then initiated root privileges by using the CF-Root Kernel via Odin (versions shown above) - All has been working fine 100%.....
However, it appears that I seem to have lost my SU permissions and may have disabled my root access, even though my device was rooted and I would appreciate any assistance from anyone who might have time to shed some light on the situation.
Behaviour of Apps I have tried that require root
-------------------------------------------------------------------
SuperSU
SuperSU Pro v0.96 lists in the 'Apps' tab (denoted by a green # symbol) that I have granted all relevant Apps that require SU privileges. This includes AdFree, BusyBox Pro, Root Checker Basic, Root Explorer, SetCPU, Terminal Emulator, Titanium Backup, Triangle Away.
Terminal Emulator
Terminal Emulator displays the following and when I enter the su command at the prompt, I just see a carriage return with a grey block. In other words, I do not see the # symbol denoting I have su privileges.
a/local/bin:$PATH
[email protected]:/ $su
Root Explorer
Root Explorer no longer displays a directory listing and simply displays a pop up from SuperSU after tapping on Root Explorer, "Root Explorer has been granted superuser permission for an interactive shell." then the following message from Root Explorer itself:
"Root Explorer has not yet managed to obtain root access. Because of issues with Superuser, this often happens the first time the app is run but is usually fine from then on."
Root Checker Basic
Apart from the App stating "Please wait for Root Check to be complete. Systems appears to be running very slow" after tapping on the [Verify Root Access] button. It never seems to provide an output after a few minutes waiting. My conclusion is that it cannot get su permissions.
BusyBox Pro
SuperSU displays the message that Titanium Backup has been given root access, however I get the following message:
"Asking for root rights..."
Then after a few minutes I receive this most enlightening output:
"Sorry, I could not acquire root privileges. This application will *not* work! Please verify that your ROM is rooted and includes BusyBox and try again.
This attempt was made using the "/system/xbin/su" command."
I read somewhere that Titanium Backup uses it's own BusyBox installation and not the system wide BusyBox package so I went in to the Titanium Backup preferences and selected 'Troubleshooting settings' then chose 'Force system BusyBox' to see if my issue was a BusyBox specific problem. Again, it failed so not sure if it is BusyBox or my SU permissions that have somehow got corrupted or been disabled.
Additional Information
-------------------------------
Using 'ES File Explorer', I can confirm that the following file's exist at the appropriate location paths:
/system/xbin/su
/system/xbin/busybox
Conclusion so far
-------------------------
It appears that on the face of it that I have lost my root permissions, so I removed apps from SuperSU, then uninstalled the App (e.g. Root Explorer, Terminal Emulator et al.); then performed the rooting procedure again via ODIN and the CF-Root kernel. The process itself worked flawlessly and so after it rebooted, I installed the Apps in question from the Google Play Store again and they prompted to be granted SuperSU privileges. Unfortunately, the same issues arose where it appears that it cannot communicate with either the su command or BusyBox to do what it requires.
Does anyone have any ideas as the phone is fine apart from this and although performing a Titanium Backup backup around two weeks ago, I would sooner not have to wipe everything if I can help it. I wonder if it is an update that somehow confused things...Either way, I cannot use Titanium Backup to backup/restore due to it requiring SU/root permissions, of which I do not seemingly have anymore.
Any ideas please as I am scratching my head and have gone blurry eyed at spending hours viewing various forums and posts?
follow this steps:
1. Unroot your phone with the unroot method here
2. To be sure, unroot again with the method here
3. ROOT your phone again using Any of the Rooting methods in the links provided in step 1 or 2.
Good luck
ICS 4.0.3 Lost su permissions even though device was rooted - Resolved
:good: Issue Resolved :good:
Many thanks for contributing to my issue. I had come across the post before in your links and although the directions were not completely related, there was a section pertaining to a zip file that I must have missed.
Conclusion
----------------
As can be read in the post, I was unsure if my issue related to losing root, a possible corrupt su file itself or BusyBox. As you will see on the link below, Busy Box actually creates hundreds of symbolic links (symlinks) and due to my perhaps overzelous approach to wanting a quick fix; I must have inadvertently created too many links with different versions of Busy Box and therefore when an App that was correctly added and granted SU permissions within SuperSU, when it then communicated with Busy Box / su to authenticate; I can only imagine it got confused and was lost with all the dead symlinks. The net result was that although SuperSU stated that it had granted permissions to the Apps requiring root, it never got to communicate with the su file contained within /system/xbin. I hope that makes sense, well at least I am pretty sure that is what happened.
Solution
------------
Firstly, I cleared all entries contained within SuperSU and therefore removing all Apps from being granted with root access (they didn't have it anyway at the moment).
I saved the zip file contained at the following link on to my external SD card and choosing to 'install zip from sd card' within the CWM Recovery (Volume Up + Power + Home button); effectively this uninstalls Busy Box completely from your device, including hundreds of symlink files - including many which in my instance was causing issues with Apps that required root to function correctly.
Busy Box Uninstaller v1.0 here
I restarted my device and downloaded Busy Box from Google Play Store and when I opened Root Explorer and the other aforementioned Apps shown in this post, they prompted to be granted root permissions (SuperSU) and voila....it worked ! :good:
I hope this may help other droid users experiencing similar symptoms.
Conflicts? LG P769 rooted V18. Binary update fails, su reports "The ap su (processom.noshufou.android.su has stopped unexpectedly)" then crashes. Until resolved and certain that su will preserve root would like to prevent ph from forcing update. Have read several methods one is to freeze a couple of scripts w/Titanium, another to delete 24MB ip folder 10e>10g in cache and alter Google Framework. Not sure which is the safest or easiest with apps I already have. That's two requests which will be greatly appreciated: One to resolve su binary fail w/possible app conflicts the other to simply stop OTA until I understand Andoid and the apps better.
Installed: SuperSU (non-pro- no survival mode) , Superuser Elite(over vs from Bin4ry), Smanager Elite, OTA Root Keeper, Titanium BU Pro
btw- No response from ph running Bin4ry? Go to redmondpie com "how-to-set-up-android-adb-and-fastboot-on-windows-tutorial" Only way it worked for me. Followed the directions and was able to view my device in command box prior to executing v18.
note: When editing the string as described, redmondpie, +be sure not to wipe out any part of existing script+ (hit end , blue box turns white). Copied and pasted extracted bin4ry "stuf' in a folder labled Andoid-adb set up in adb environment. Root executed from there first try after dozens of failures w/other methods.
>>not sure if I have valid root restore tools should OTA (already in cache) executes<< >>Meanwhile, which method to prevent OTA execution<<
notes from apps
root checker basic verifies root; voodoo all boxes checked, protected su copy available but note "using both su and SupersSU take care keeping app and su bu consistent" (should not be issue since not the pro vs of SuperSU - no ota survival). edit just started to rept "sys running very slow-pls wait for r-ckr to cmplete.
Superuser elite v3.1.3(46) (downloaded over Bin4ry incl vs) shows no apps, no log, o entries Binary updater fails, "The ap su (processom.noshufou.android.su has stopped unexpectedly" then crashes. "bu written to sd card"black box flashes to say su has been granted superuser permission interactive shell access; access timeout aps not remembered set to 0; auto response set to prompt; ghost mode off; ...
SU updater reports "sigs ok"
SuperSU v0.96: all green # today (but not yesterday); superuser enabled; surv mode not avail (not pro);
Titanium BU Pro root ccess ok, busybox 1.19.4-titanium from ap ; sqlite- yes 3.7.6.-titan incl; All green checks on overview pg; has quite a few red line entries, probably hven't left ph on long enough for bu to complete
; active data pofile- sys rom 1.03gb ; internal 1.93/1.46 free note down from 1.7 when new.
Smanager reports root access Can this app delete cached ota update zip?
Did I err in downloading elite vs of Superuser over the copy already inserted by Binr4y? Thanks.
I'm pretty sure this is the latest version of SuperSU, but every time I reboot my phone I get a message that reads: "The SU binary needs to be updated!", and when I click on the prompt to update it, it always fails and asks me to reboot.
Has anyone else run into this issue, or know how to resolve it? Thanks.
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
bafforosso said:
SuperSU APK and the SU binary are two different things :
SU is a binary executable, it's used by Android and other *nix based systems to allow a process to change the user it is run by and therefore what the process has the rights to do (as it inherit the user permissions). In the rooting case, processes invoke SU to switch to the root user therefore acquiring root permissions.
SuperSU is an Android application (.apk is an Android application package), it works as a sort of "gatekeeper" to the SU binary. Applications which attempt to invoke SU will be forced to route through SuperSU, which will then prompt the user with the options of approving or denying the access to SU (and optionally having SuperSU remember their decision and automatically apply it for subsequent calls by that app).
So what happens to you is, every time you boot, SuperSU v2.78 (which is the latest version of the SuperSU APK) checks the SU binary version and tells you that there is a newer version of it and that you should update it.
Then for SuperSU failing to update the SU binary I can't help as for me it always worked till now. But maybe there is a way to manually do it (by finding the binary in a flashable zip that you can flash in recovery)?
Click to expand...
Click to collapse
Thank you for explaining the difference for me. I went ahead and downloaded the .zip from here: http://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703/page8
And then used the installation instruction found here: http://androiding.how/how-to-flash-supersu-using-twrp-recovery-and-root-any-android-device/
And I don't seem to be getting the prompt that SuperSU needs to be updated anymore.
Huh. Never mind. Seemed to work for about 12 hours, but now it's asking me to update again, and I can't. Looks like I need step-by-step instructions on how to clear this message, cause whatever I'm doing isn't doing the trick.
Did you disable Sony RIC and dm-verity when you modified the kernel? I'm not sure if it has anything to do with or whether it will solve your problem, but one time I patched my kernel leaving one of the options enabled and ran into all sorts of problems with apps that required root, so after that horrible experience I decided to just disable everything. During that horrid experience, I think I also had SuperSU (or was it busybox?) complain about not being able to update binaries.