Up until now, if you wanted to get root on Android 5.0, you needed to flash a modified kernel onto your device to work around some SELinux restrictions. XDA Senior Recognized Developer Chainfire recently released the previously-necessary CF-Auto-Root package, which made the necessary kernel ramdisk modifications to remove SELinux restriction from the install-recovery.sh script on AOSP. This morning, however, Chainfire brought smiles to many faces, as he announced on Twitter that this would no longer be necessary going forward.

Up until today, Chainfire had planned to release an automated ZIP-based patching tool, to automatically patch kernel images from within TWRP recovery,  until he came across a suitable method to remove the need for this.

This revelation means that Android 5.0 users no longer need to run a modified kernel to gain root access via SuperSU (or other root solutions). While not a huge problem on Nexus devices with unlockable bootloaders, the need for ramdisk modifications was concerning for many users of bootloader-locked devices for which no unlock is available (yes, they do unfortunately exist). The answer to their prayers is now here, and we can present an exclusive explanation of the changes needed. At least for now (until/unless Google patch this), it is possible to gain root access and then install and use SuperSU on a stock Android 5.0 device, without any kernel ramdisk tweaking. The reason for this is the need for SuperSU to run a service as root, to allow for unconstrained root access on SELinux-protected devices.

Previously, SuperSU would leverage the pre-installed AOSP flash_recovery service (used in AOSP to update recovery after an OTA installation) to start the SuperSU daemon (which actually provides the root privileges for apps which request it). With the release of Lollipop, this service has been added to a restricted SELinux context, meaning it no longer has unadulterated access to the system. The previous kernel modifications sought to remove the SELinux restrictions from this script.

Chainfire's latest beta release of SuperSU resolves this by using the core 'Zygote' service (responsible for launching all Java services, and thus all apps installed on a device). Since Zygote is one of the only services available on Android L, which is started as root within the unrestricted "init" SELinux context, this makes it a prime target for use in the operation of SuperSU. After boot, the Zygote service has its SELinux "init" context transitioned to its final (restricted) "Zygote" context. Chainfire has managed to successfully modify the Zygote files, in order to run code as the root user, within the unrestricted "init" context, thus bringing SuperSU back to Android L, without kernel modifications.

This isn't the first time Chainfire has turned to Zygote to solve these problems; the earlier 2.23 beta used Zygote as a means to possibly circumvent some other SELinux issues (which were causing root apps to break on Android L). This allowed some (but not all) of the non-functioning apps to work - the remainder require some updates by their developers. Unfortunately, when the 5.0 AOSP code was consulted, it emerged that Google had already broken this method of taking over the Zygote service. Given all his previous attempts to take over Zygote had failed, this is a promising step forward.

Chainfire was keen to point out that SuperSU has long been able to modify SELinux policies on a running system (and cautions as to the ease with which an OEM could disable this, and truly prevent meaningful and simple root access), and how any modifications made to Zygote must be made carefully, given the service is run from various different contexts, for different tasks, and this raises the possibility of a number of (nasty) subtle failures. This new SuperSU beta 2.27 is a build for enthusiasts and other techies to play with, to find out what breaks. Fingers crossed--there's no unexpected show-stopper bugs, and this is a viable way forward.

Take note - even if this beta works out and Zygote is the preferred avenue to gain root access, going forward, the entire process is only a single-line change away from being broken by Google, which would make patched kernel ramdisks the future for root access on Android (thus ruling out root for bootloader-locked devices). Indeed, as a heads-up, the new process may not even work on a fully up-to-date AOSP build, due to some fairly large SELinux changes within the past few months, which were not included in the retail devices, but which will no doubt be there in future releases. Sooner or later though, it seems likely that modified kernel ramdisks will be necessary for root, but this new beta may offer a short stay-of-execution before we must go in that direction.

Check out the release notes for more information about the risks involved in testing this out, and for links. Developers should also be aware that Chainfire is currently hard at work on the "How-To SU" guide (fully updated for Android 5.0), which should be available within the next few days.

[A huge thanks to Chainfire for his work here, and assistance in preparing this article.]