NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.

All this information is subject to change without notice. The current SuperSU at time of writing is v1.45.

Apart from a lot of text, this post also includes stuff a dev would want to know regarding daemon startup and mount namespaces.

Pre-cursor

I was surprised by the large number of negative (sometimes even flaming) responses from even techies that SuperSU didn't magically work perfectly out of the box at 4.3 release. I would like to point out that this daemon version of SuperSU was pretty much just an experiment for the SGS4's 4.3 leak. We didn't know if the new measures were Samsung or Google, or if they would be present in any retail firmwares at all. Samsung tends to protect their engineering firmwares better than their retails. As such, there was a big question if the effort was a pure waste of time or not, and I choose not to continue with it until we had some further certainty.

Yes, then the Nexus 4 firmware leaked, I didn't have time to look at it yet, and I don't even have a Nexus 4. Some have slammed me for not fixing the CPU load issue sooner - I wasn't even aware it was a serious problem until the day before the official 4.3 hit ...

Android 4.3 - it isn't just 4.2 with sweetener

Right now, I'm getting a lot of feedback from a lot of users regarding their favorite apps not working and how it's all SuperSU's fault, the device isn't properly rooted, etc. Stop that.

Android 4.3 is a different beast than 4.2, and on stock-ish firmwares it seems this method of root is here to stay. App developers will have to do their share of updating. Things will not be 100% the same as they were. I aim to make it as similar as reasonably possible, but that alone will not be enough.

If you're a developer, by all means let me know if something is working differently than you expected and if there might be a problem somewhere. You might be right, and it might need fixing. If you're an end-user, you might want to think long and hard whether or not it is something you really want to bother me with, something you want to bother the app's dev with, or something that in all likelihood the app's dev will already currently be looking at (like 4.3 compatibility). The dust will settle soon enough.

hacks, solutions, and updates

Some of the things done for this version of SuperSU may not be ideal, rough-around-the-edges, "hackery", etc. Again, it was partly just an experiment that is only now getting serious. As far as I can see, there is no other way to do this on rooted stock, but if one is found, I will certainly look at that as well.

There's quite a bit of new code involved - there will be bugs, quirks, and updates. We've already had a few of those and there will probably be at least one more very soon.

I am going on vacation this week, and I'll be gone for a while. So development will be stagnant on my end, I hope to leave you with something that somewhat works, even if it isn't perfect.

install-recovery.sh and init.d

At the moment install-recovery.sh is used by the SuperSU installers (app itself, ZIP, CF-Auto-Root, etc) as method to launch SuperSU's daemon at boot. This is not an ideal situation. However, for the time being it seems to be the most broadly available method to do this - and due to vacation I can't dedicate too much time at this specific quirk right now.

As some other apps also use that, I call install-recovery-2.sh after starting the daemon, should anybody need that (for now).

Some custom firmwares and kernels block this and for example use init.d instead. I do plan to support that officially, but until that time it should be trivial for anyone to mod the installer ZIP or actually include SuperSU in that custom firmware itself.

I've been thinking about making init.d support available through install-recovery.sh (if not already available) and launching the daemon through there. Not sure if that's the route I'm going to take, but it's an idea.

If you're making your own firmware and including SuperSU, you can also add a service for daemonsu in init.rc.

EDIT: Note that different ways of running at root, like hijacking a lib by preload through /vendor has also been considered, but was ultimately ruled out as not being very portable.

EDIT#2: install-recovery.sh is also used by OTA updates, you are for the time being recommend to use the "full unroot" option in SuperSU prior to doing an OTA.

mount namespaces

These aren't anything new, Linux has had them for a while, and Android has had them since 4.2. There were already some repercussions to this on 4.2, such as one app remounting system r/w not being visible from other apps, or the same thing with USB sticks and whatnot. Yes, this is how nosuid is done as well (as if anyone was surprised).

Now that SuperSU is running in daemon mode, this means that all your su requests actually get executed in a different part of the process tree that does not share the same mount namespace as your main Android app's java code, libraries, or non-su'd binaries.

This means changes made in a su shell may not be visible to the normal parts of your app. This is also means the su shell does not have your private things mounted - the current user's internal storage, obb's, etc.

The current version of SuperSU does symlink /storage/emulated/<uid> to /data/media/<uid> but this is not ideal, symlinks do not behave exactly the same as mounts. This will transition to mounts in an upcoming release, which will work better - but I will still not be pre-mounting obb's. Some devs have asked me what I meant with that link being marked "temporary" in the SuperSU changelogs. It means just this - I will change the method to mounts. The path itself will remain available.

The proxied su requests currently all live in the same mount namespace. That means that if one app remounts system r/w through su, all other su shells will also have a r/w system (unlike 4.2). As such, root apps can potentially interfere with eachother (as with 4.1 and earlier).

I'm not sure what I'm going to do with that. I am considering making a private mount namespace for each different app, but that will have it's own quirks, cause a little bit of overhead and it'll take some time to build and test.

Anyway, for the time being, if you're an app dev, you should really take care to check what you're doing in with file paths, mounts, etc on 4.3, things may not behave as you initially expect. And to make matters worse, it'll likely be subject to change as well.

Conclusion

This is not perfect yet. It will be a while before it is. Some things will need adjusting on my side, some things will need adjusting on root app dev's side. You can be sure there will be some changes to how some things are implemented for SuperSU on 4.3, but I'm not sure yet exactly what, how, or when.