About a week and a half ago, we took a look at a few recent AOSP merges initially spotted by XDA Senior Recognized Developer Chainfire that severely impact root app developers due to changes in SELinux, default runtime compiler, and the requirement of PIE (Position-Independent Executable) for non-statically built executables. These changes compounded previous headaches caused by commits that prevent SU from executing files stored on the /data partition. Luckily, potential workarounds for the above changes were quickly publicized by Chainfire when he updated his How to SU guide.
Now, the breakage continues, as new AOSP commits are poised to make life more difficult for root app developers and users in upcoming versions of Android. And this time, the workarounds aren’t so simple. The changes in question relate to SELinux and the limiting of /system write access to the recovery context. This would ordinarily be fine and lead to heightened security, but combined with another change that then limited this recovery context to the actual system recovery, it could be a serious blow to the root app community and lead to additional end user difficulty when using root-enabled apps that need to write to the /system partition.
So what do these changes actually mean? For starters, this means that going forward, write access to the /system partition is no longer possible on “rooted stock” ROMs. Instead, developers will have to use custom recoveries to handle /system partition write access through APIs such as Open Recovery System (ORS), which was introduced alongside TWRP2 two years ago. This would be fine if everyone were using a compatible (and updated) custom recovery. However, the sad reality is that not every root user is even on a custom recovery–much less, an updated one that supports ORS or similar functionality flawlessly. And naturally, if a root app doesn’t work well with a particular recovery, it’s likely that the app developer (and not the recovery developer) will be blamed by the end user.
What about the ramifications? In addition to the developer headaches from having to shift over to recovery-based /system partition write access, these changes also place an additional burden on users who will now have to reboot any time they want to write to the /system partition. Moreover, even with a properly compatible custom recovery and updated apps to take advantage of the recovery scripting, certain types of root apps will simply not work without a hack to get around these limitations.
It’s important to keep in mind that there are a few potential saving graces. First of all, /system write access can obviously be re-enabled by a custom kernel. Moreover, it’s not known at this time whether these commits will actually make their way into the next version of Android or another version further down the line. However, not every device is able to run a custom kernel (or custom recovery, for that matter), and devices with locked bootloaders are unfortunately all too common at the moment.
You can read the original post over on Chainfire’s G+ page. Are you a root-enabled user dreading these changes, or do you welcome the increase in security that changes to SELinux bring? Let us know in the comments below._________
Join us for xda:devcon 2014. For a limited time, XDA Portal readers get 20% off registration!