SuperSU, How-To SU, and CF-Auto-Root updatedSuperSU
v2.35 is rolling out on Play
as we speak (Amazon will also be updated soon). The flashable ZIP is available via http://download.chainfire.eu/supersu
immediately as well. All CF-Auto-Root's have already been updated.
The last full Play update was v2.01, if you want to know all the changes since then, see the changelog post in SuperSU's main XDA thread here: http://forum.xda-developers.com/showpost.php?p=23427824&postcount=3
The How-To SU
document - http://su.chainfire.eu/
- has also been updated with the latest information. There's a lot on SELinux that may not be relevant to all root app devs, but it will be to some. If you're a dev, I'd advise reading through it, if only so you know where to look if you do run into an issue.From 4.4 to 5.0
It's been a bumpy ride, and there have been a lot of changes along the way. Things initially solved one way, ended up getting scrapped and being solved other ways, as AOSP progressed and L preview releases came out.
From needing heavy work-arounds for basic commands, to boot image (ramdisk) patches, back to simple commands by employing live policy patches and hooking daemon launch in a different way.
Some shortcuts could have been taken. Initially, I was focused on getting everything to work without having to patch SELinux, which led to some pretty hefty experiments and codewise lengthy work-arounds. As security patches kept being committed to AOSP though, there was a turning point where it was just no longer viable to keep root without patching the policies, even if only slightly. This caused a change in perspective that lead to implementing some things very differently. Had I not been as stubborn to start out with (what else is new), some work (and time) could have been saved.
When it was time for L retail, they closed the flash_recovery service loophole which was used to start SuperSU's daemon. Because of this, SuperSU couldn't start at boot. This was no surprise to anyone paying attention - system logs have been warning of the service running unprotected for months. This is why we used ramdisk patches to launch the daemon for a while. That was fixed again a few beta versions ago. There's been some commentary about how brilliant a solution that was, but really it wasn't - personally I consider it a pretty big oversight not spotting this solution immediately when it was needed, and a bit of hassle for a fair number of users could have been avoided.
Still, aside from the drawbacks for those with locked bootloaders, I would not have minded a modified ramdisk solution that much. It would have been a good excuse to patch in an overlayfs for /system as well, so modifications to /system would not actually be written to the system partition, but to a container elsewhere. This would preserve system integrity and OTA capabilities and prevent most bootloops caused by root apps situation (or at least allow quick reversal without needing to restore backups from a recovery). A pretty clean solution to some common issues that I was actually starting to look forward to. But it seems we're not going there now, and at least for some it is better this way.
Though all in all, it was a mostly fun learning experience - coming from noob-level SELinux knowledge - imagine how much easier and quicker it would be to bring up a solution like this now that all the information is available, though.Material
Over the last few beta releases SuperSU has gotten a bit more material-y on the default theme, but it's still far from perfect. This is not a top priority for me at the moment. Aside from other apps needing some love, SuperSU still supports 2.x devices and all sorts of form factors no longer in use on more modern devices, so there's already enough similar-but-not-quite-the-same layouts in there, I am not enthusiastic about adding another set. Because of this, I've only made minor changes and tweaks, that do not significantly impact the overall layout, structure, or associated code.
Add to that, the compatibility libraries already in use and the material one are incompatible with eachother thus far, so those material changes that are present are not being backported to 4.x yet either.
This will be resolved in time, just not today. The UI code could use an overhaul, and 2.x support is up for review as well. The ideal time for a more extensive material makeover is when those two intersect. I will continue to make minor adjustments over the next few releases, though.
Of course, I always welcome mock-ups of what you think it should look like. I have decided on teal as the primary color though, as you will have noticed.
Note that it is possible after this update that you have two SuperSU icons on your app drawer. If this happens, go to SuperSU's settings, and change the launcher icon option to whichever one you want to use, and the other one will disappear again. This is caused by the new material style icon that was added and made default on 5.0+.IAPs as donations/support
Pro users will have additional in-app donation options. Some very supportive users like repeatedly supporting my developments (thanks, I really appreciate that), and the number of people emailing me about not wanting to use PayPal is on the rise. So here's another option to do it. Like getting SuperSU Pro itself, this is completely optional and does not unlock any features (remember there's a checkbox in settings to get all Pro features if you don't want to or are not able to pay for Pro).
I also have a magic internet money address for those so inclined (BTC): 1JeoxivKEXbbiegsv1BrUC7fD7GgSPcqkG
Undoubtedly I'll get some hate for this, but shrug
The last few beta releases have been largely uneventful, so I do not expect that many issues with this rollout. That being said, many millions of users will be updated, using hundreds of different devices, running on several different firmwares each, so I'm sure there will be at least some
issues. Thousands of beta users does not equate to millions of end-users, after all.
So far, a Lollipop leak for the Sprint S5 was leaked earlier today for which we already know this new version has some issues (it can work, though). I will look at that when we get a firmware leak that actually runs on hardware I have here. There have also been reported oddities with the last beta on CM12, but so far I was not able to reproduce these, and this rollout has been delayed enough already. Once the cause of the issues have been found, there'll be another update.