Next Android version AOSP: the breakage continues

(disclaimer: I've had a long day and I'm rather tired, apologies if this post isn't very coherent)

This is a continuation of https://plus.google.com/113517319477420052449/posts/ZtXAhw164QD , which was already a continuation of https://plus.google.com/+Chainfire/posts/Lyhjzu1z9s1 .

AOSP commits happen every day, including ones to the SELinux git.

As anyone watching the SELinux AOSP commits lately suspected would soon happen, some days ago we saw a commit limiting /system write access to the recovery context (no problem at all). It was also to be expected this recovery context would then be limited to actual recovery, and today we saw the commit of that change as well (boom).

What this comes down to meaning is that write access to /system is no longer going to be available on "rooted stock" from the Android version these commits are included in.

There are some cases where this can be worked around, and there are also cases where I do not see a (practical, generic) workaround right now. I'm still looking, but even if there is one, I would expect it to be patched soon. I actually have a feasable work-around, but it may have some side-effects, and I would be really surprised if this work-around is not fixed really soon, as the Android/SELinux guys are actually aware of the issue.

From a security standpoint, this brings more security, and is thus better. Unlike most of the other AOSP changes I've posted about lately though, this change does not just require devs to update their apps, it will also actively inconvenience root-app users.

What it will probably mean in practice is that apps that need to modify /system, will have to do so via a custom recovery like TWRP. This means a major headache for root app devs, as users use various custom recoveries, rarely update to the latest version of whichever recovery they are using (causing scripts to fail), and scripts are not easily made 100% compatible with all the recoveries out there (and some recoveries are even intentionally crippled). It's usually the app dev who gets blamed for these things.

For root app users it mostly means rebooting more often - though keep in mind far from all root apps require modifying /system.

Sadly, there are a handful of root apps I know of that will be made completely impossible (barring a hack for these limitation) by these changes, but most apps will just be more cumbersome to use, if they need changing at all.

Writing to /system can be re-enabled by custom kernels, but using those may not be wanted, viable, or even possible (the same goes for custom recoveries, of course). One thing is for sure: this is certainly not the time to be buying devices whose bootloaders cannot be unlocked!

Some root app devs may require you to be running a custom kernel dropping this restriction, or use a specific custom recovery. This is of course their right as the developer. The added complexity however does practically guarantee that you're going to lose some options in apps you can use on any random device.

It is unknown if these commits will be present in the upcoming Android version, or (as some have speculated) they will not show up in 'retail' Android until the version after that. They may still be reverted, changed, abandoned or replaced as well. I'm just reporting on what is in AOSP now. Keep in mind we are really close to 4.4.3 release, so it may be that none of the things I've written about AOSP from the past few weeks will be present in 4.4.3, and will only be in whatever comes after that. It's even possible they will never end up in Google builds, though that would create a strange disconnect in security between Google and AOSP builds.

If you're wondering if they're about done now making root apps more difficult and complex - I don't know the answer to that. But I do know I can imagine quite a few more things they could do in this area, so eventually they probably will.
Shared publiclyView activity