• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Will ota root keeper work if super SU is installed?

It works beautifully as long as you don't enable root saver in Super SU.
I'm saying that because I didn't know. I clicked on hide root only in Ota root keeper. I took the ota. I updated painlessly. And for me it was worth it. After I booted into 4.2 for the first time I opened ota root keeper and clicked restore root. Voila it was back! Then I installed goo manager and through goo manager I reflashed twrp. It was much easier than I thought. Didnt have to connect a windows PC at all. To boot chain fires stick mount update allowed me to save a before and after image I created with twrp to my external hard disk. Using wugs doesn't turn me on cause getting it connected is sometimes annoying. Thanks to Ota root keeper and goo Manager life just got easier.
 
Upvote 0
Hi. I have SuperSU and Voodoo OTA Rootkeeper and I used Voodoo to save root but when I look at SuperSU I don't see the setting where you do/do not tell it to protect root. Can you tell me exactly which option it is?

thanks

dave, I believe the feature they're talking about is called "OTA survival mode," and it's only in SuperSU Pro, according to the Play page. Perhaps at one time it was in the free version, I'm not sure.

This should mean that if you have SuperSU free then it won't run interference for OTA RootKeeper.

Welcome both of you to the AndroidForums! :)

FYI, I don't know exactly how the OTA survival mode works for SuperSU, but I'm guessing it's similar to how OTA Rootkeeper (and one of my apps) does it: it squirrels away a copy of the su binary in the /system partition and sets the immutable status bit on the file--thereby making it immune to any chmod (permission changes) that an over-the-air (OTA) update might attempt (that's why an OTA removes root: it re-secures all of the files in the /system partition and particularly impacts the su binary which needs to keep the suid bit intact).

Then, when you "restore" root, the saved copy of the su binary which will still have root access/permissions/privileges, can be used to copy itself or re-secure the original su binary back to it's happy fully-rooted status.

So, if you've previously "saved" root by using the above, you should always be able to restore root, even if you have to do it manually via an shell command (it's a little more complicated, but doable) since you've still got a root-enabled su binary (regardless of what it's named) available.

Cheers!

edit: note--the immutable status bit is only available on ext2/3/4 filesystems, so that's why it can't be used for every device.
 
  • Like
Reactions: colchiro
Upvote 0
Do I also need to install superuser or can I just use supersu? The voodoo app days r something about using both but I don't see a need.
Thanks in advance.

Welcome to the AndroidForums, POMF2K!

Yeah, I'm a little confused by Supercurio's comment in the OTA Rootkeeper Play Market description:

The application doesn't support original Superuser and not SuperSU for a very simple reason. The same feature OTA protection feature is already present in SuperSU.

I don't exactly understand what he's trying to say in the first sentence and the second sentence implies that SuperSU does indeed use the same root protection feature that OTA Rootkeeper does.

Since OTA Rootkeeper is free, it's a no-brainer to install and use that to save root (just in case ;)).

I'm still using Superuser on my VZW Galaxy Nexus which hasn't had an OTA update for a very long while, but I have SuperSU on my N7 (but not the paid version that has the root survival mode feature).

I will caution that I've had a few users of my Android Root Toolkit app that has a root save feature (implemented using the same method that OTA Rootkeeper does) that installed an OTA update had troubles re-gaining root afterwards despite having an identical setup to what I had and/or subsequently tested. I've still figure-out what the issue was--the only thing I can think of would be that the saved su binary was different from the version in /system/bin or /system/xbin and that SuperSU knows / remembers which version he last "talked" to and therefore would not re-allow root access afterwards. This is just a guess since subsequent testing of this scenario did not prevent me from re-gaining root access even with Superuser and/or SuperSU completely uninstalled.

So, just to be safe, do a fresh save of root right before you accept / install an OTA to try to eliminate any chance of a version mismatch being an issue.

Sorry for the long reply...hope it helps :).
 
  • Like
Reactions: jmar
Upvote 0
Regardless, and correct me if I'm wrong, doesn't one still need an app like superuser to allow root access to apps that require it?

Furthermore it would seem that the voodoo app is implying it is a prerequisite. And in my case, one that may not be met as I'm using supersu as opposed to superuser. Is there a difference?

Also thanks for the root toolkit. Had a hell of a time getting the drivers to work for my nexus 7 but was eventually able to use it to unlock my bootloader and then was able to root it the old fashioned way. Sadly, it was much easier to root my old droid x. Took me an entire day to get windows to recognize that an ADB device was connected so you can understand why I don't want to lose root.
 
  • Like
Reactions: scary alien
Upvote 0
Regardless, and correct me if I'm wrong, doesn't one still need an app like superuser to allow root access to apps that require it?

Furthermore it would seem that the voodoo app is implying it is a prerequisite. And in my case, one that may not be met as I'm using supersu as opposed to superuser. Is there a difference?

Also thanks for the root toolkit. Had a hell of a time getting the drivers to work for my nexus 7 but was eventually able to use it to unlock my bootloader and then was able to root it the old fashioned way. Sadly, it was much easier to root my old droid x. Took me an entire day to get windows to recognize that an ADB device was connected so you can understand why I don't want to lose root.

Yes, you are correct, you need a superuser app (either Superuser or SuperSU) to allow an app to be granted root access.

You do not need a superuser app to invoke a properly secured (and properly located) su binary invoked from an adb shell. This isn't true for an Android Terminal emulator app's shell since that's, well--an app ;) :).

So, you should, if you have access to your device via an adb shell, and still have a properly secured su binary laying around (i.e., saved by my app, SuperSU, or OTA Rootkeeper), you should be able to manually re-acquire and/or re-install root (if you know the proper shell commands).

There shouldn't be anything functionally different (from what I understand) between Superuser and SuperSU except many improvements / updates Chainfire made to SuperSU.

Thank you for the kind words about about my app--happy to have helped and give back to the Android community :).
 
  • Like
Reactions: jmar
Upvote 0
Sorry, but I am a complete novice and first time rooter, but how do you use it?
I have rooted and have superuser installed and ota root keeper, but after that what do I check and allow (etc.) And do you have to hide the root or what when updating?

Welcome to the AndroidForums!

Do you mean how do you use root or how do you use OTA Rootkeeper?

The first one is kind of a big question :)p) but the second one is easy: just install the app and grant it root access--the app should show "Protected su copy available" with a check mark in the box next to it.

As far as root goes, root / superuser access in and of itself doesn't do much for you...it's the apps and functions that require and ask for root access that actually do useful things.

There's a ton of very useful root apps out there, but I'll save answering that question (if you still have it) for a different thread :) [to keep this one on-topic to OTA Rootkeeper].

You should be aware that installing an over-the-air update (OTA) typically strips you of root access/rights--hence the need for an app like OTA Rootkeeper.

Additionally, to actually install an OTA, you've got to have various system components set back to their stock counterparts since the update process checks for these. So, make sure you're aware of and prepared for not being able to install a future OTA update should you modify the wrong things.

Cheers and I hope that helps :).
 
Upvote 0
Morning guys. I Seen the question asked. But I'm not clear on the answer.
What is best. Temp unroot or leave the root as is and take the ota.
Su backed up root protected.

Thanks for any confirmed info

Morning (actually afternoon, now :p), r_hippy! :)

I don't think I would un-root prior to taking an OTA...not sure there's a benefit to doing so.

An OTA typically disables root by zapping it's suid bit in its permissions when the /system partition is mass re-secured during the installation process.

Things that save root (like OTA Rootkeeper, my app, etc.) typically squirrel-away a copy of the su binary on the /system partition with the immutable bit enabled to keep the mass re-secure from being able to alter it (i.e., that immutable bit is only available on ext2/3/4 filesystems, so you always need to check that /system is of that type before trusting that root is safely stored-away).

Another issue that you can run into, though (which I/we have indeed seen before), is that differences in the newly-install Android O/S (i.e., as a result of the OTA installation) can render the saved root non-functional :(. That can seriously put a damper on your day, LOL. You don't often know that this is the case though until it's too late :(.

The only way to avoid being trapped in that scenario would be to let others :)p) install the OTA first and make sure their saved root was not obsoleted. You could also try to find out if there are newer versions of the su binary available that are indeed compatible with the OTA's Android version being installed.

It's a little of a catch-22 at times, but for the most part, go-ahead and just save root prior to installing the OTA and rub your rabbit's foot :) (and, since you're talking about an N7 anyway (I hope), you should be able to re-flash the su.zip in a custom recovery should it come to that).

Anyway, best of luck and I hope that helps.

Cheers!
 
Upvote 0
Morning (actually afternoon, now :p), r_hippy! :)

I don't think I would un-root prior to taking an OTA...not sure there's a benefit to doing so.

An OTA typically disables root by zapping it's suid bit in its permissions when the /system partition is mass re-secured during the installation process.

Things that save root (like OTA Rootkeeper, my app, etc.) typically squirrel-away a copy of the su binary on the /system partition with the immutable bit enabled to keep the mass re-secure from being able to alter it (i.e., that immutable bit is only available on ext2/3/4 filesystems, so you always need to check that /system is of that type before trusting that root is safely stored-away).

Another issue that you can run into, though (which I/we have indeed seen before), is that differences in the newly-install Android O/S (i.e., as a result of the OTA installation) can render the saved root non-functional :(. That can seriously put a damper on your day, LOL. You don't often know that this is the case though until it's too late :(.

The only way to avoid being trapped in that scenario would be to let others :)p) install the OTA first and make sure their saved root was not obsoleted. You could also try to find out if there are newer versions of the su binary available that are indeed compatible with the OTA's Android version being installed.

It's a little of a catch-22 at times, but for the most part, go-ahead and just save root prior to installing the OTA and rub your rabbit's foot :) (and, since you're talking about an N7 anyway (I hope), you should be able to re-flash the su.zip in a custom recovery should it come to that).

Anyway, best of luck and I hope that helps.

Cheers!

Afternoon u to. Thanks for the reply. I have 3 s4's one fully tweaked runs like nothing that I can be explained will not be updating it unless the loki or something else ever comes out unlocked bootloader lol (right) so I'm the one going to take it for the team (so I guess I'm that (other) s
Lol
I have one stock rejected the update and is working atm. The other one I did the same but rooted it only then I installed rootkeeper went through the steps backed up the su. I also manually backed it up to the data partition set permissions ownership so I can adb root access from it to restore the permissions and ownership from it. This phone also has no recovery as this will not allow the ota.

This is for the people that did not update and are not crack flashers that want to be rooted just to kill some sammie crap etc and run somr apps that may requires root.

If it fails on the other hand Noone has to sacrifice there root. That needs it.
My kids don't it;)

I guess u just have to figure out the file system.


The n7 I was able to reapply the exploit for root. (not rootkeeper) i didn't know much then. For that matter I don't know much still Lol

Regards
Hippy
 
  • Like
Reactions: scary alien
Upvote 0
Success

Was a few steps I took to insure I had the best chance
 

Attachments

  • Screenshot_2013-07-12-16-42-52.jpg
    Screenshot_2013-07-12-16-42-52.jpg
    111.6 KB · Views: 86
  • Screenshot_2013-07-12-16-25-01.jpg
    Screenshot_2013-07-12-16-25-01.jpg
    189.9 KB · Views: 133
  • Screenshot_2013-07-12-16-25-22.jpg
    Screenshot_2013-07-12-16-25-22.jpg
    165 KB · Views: 71
  • Screenshot_2013-07-12-16-10-23.jpg
    Screenshot_2013-07-12-16-10-23.jpg
    82.7 KB · Views: 66
  • Like
Reactions: scary alien
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones