Root for Pixel (XL) / SuperSU v2.78 SR2

Here's root for the new Pixels. This post doubles as release notes for SuperSU v2.78 SR2.

The images for the Pixels need to be 'fastboot boot'ed, not flashed. After a few minutes (have patience) and a couple of (automatic) reboots, Android should boot fully rooted. Read the README in the ZIP.

There's a lot of text below, and depending on your technical knowledge a lot of it may make very little sense to you, but I'd still suggest giving all of it a read.

As this is all pretty new, make sure you have a stock firmware around. Should anything go wrong, flashing back the stock boot.img should fix things.


SuperSU v2.78 SR2

Included is a new version of SuperSU (changelog below), with all the fixes to handle the new partition layout.


Changes introduced by the Pixel and Android 7.1

The primary changes compared to other devices and Android versions are:


Android 7.1:

- File-based encryption is now default, instead of full-disk encryption


New partition layout (Pixel and probably many future devices):

- There are two of several Android partitions, boot, system, vendor

- The recovery and cache partitions are gone

- The root / directory for Android is now part of the system partition, instead of the boot partition (initramfs)

- Recovery is now inside the normal boot image, and uses its initramfs (which used to be used by Android)


The problem

On older Android versions, roots like SuperSU worked by changing some files in /system. On more recent Android versions, we also needed to change some things in /, which was located inside the boot image (initramfs). 'Systemless' root is making the boot image modification in such a way, that the changes to /system were no longer necessary, so we only needed to modify one of the device's partitions. As an added benefit, this made it easier to support OTAs, and allowed us to keep and verify /system integrity.

With the Pixel's new partition layout, those files we were changing have moved to the system partition (what we originally thought of as /system is now a subfolder inside that partition's filesystem). So, could we then just modify the system partition that contains all these files, and leave the boot image alone? While I personally prefer doing the boot image modification and leave system alone, the reverse could potentially be a solution, and I know some tech users would even prefer it.

However, I could not get this to work. The bootloader actually sends information to the kernel (which resides in the boot image) that force-enabled dm-verity (which enforces the system partition's integrity), which we cannot intercept or change without (drum roll) modifying the boot image. My first successful root of the Pixel was done that way - by modifying both (the picture posted earlier is from this attempt).


The solution

The current solution is forcing the kernel to again use the boot image's initramfs as root directory, rather using the files from the system partition, and ignore the dm-verity settings the bootloader insists on.

This change to the boot sequence requires a small patch the kernel binary (inside the boot image), but does not require a kernel recompile. It should be portable to other kernels and thus remains a generic solution, though SuperSU's installer only supports uncompressed and GZIP compressed kernel binaries at this time.

This change also requires that the contents of the root directory from the system partition are imported to the boot image, so we can modify these files without modifying the system partition, and thus keep dm-verity happy, should the user wish to keep it enabled.

Since the boot image's initramfs was already used by recovery as well, we replace /init by a new custom binary that can detect between recovery and normal/charger mode, and choose which files from initramfs to use accordingly.

The contents of the root directory in the system partition are now ignored, aside from their import during the root process.

The system partition is now mounted to /system_root, with the /system directory symlinked to /system_root/system. This move is blatantly stolen from the stock recovery mechanism.

As /r/Android would say: trivial


Compatibility

- This being the first release, there will undoubtedly be bugs both with this version of SuperSU and this root mechanism.

- Some users have reported issues with Android 7.1 dev previous on the Nexus 5X and 6P, which I have not yet looked into. These issues may surface on the Pixel as well, or they may inadvertently be fixed by this SuperSU update.

- Various root apps expect the system partition to be mounted as /system, while with this root it is mounted as /system_root. These apps will require updates, as regardless of root mechanism, /system will not be the mount point for the system partition anymore. An example of such an app is my own FlashFire.

- File-based encryption is the default encryption mechanism on the Pixel (and probably many future devices). Some root apps will need to be updated to cope, and become (useless buzzword warning) 'Direct Boot Aware'. This is completely unrelated to SuperSU. An example of such an app is my own LiveBoot.

- If you want to use a custom kernel, simply 'fastboot boot' the root image again after flashing the custom kernel. This has been tested with a few custom kernels and found to work well so far.

- An unnamed tester needed to do the whole thing twice for the root to stick. While I assume this was Jeff's own fault, we can never be sure.


Updates / OTAs

I simply don't know if or how that is going to work. We'll have to wait for the first update, then take it from there.


CF-Auto-Root

The Pixel roots aren't a full CF-Auto-Root package. The CFAR system needs some adjustments to handle the new partition layout still. If sailfish/marlin images show up on the CF-Auto-Root site, then those will always be newer than the ones linked here. The basic idea behind these Pixel roots is the same, though.


suhide

Some of you have expressed disappointment on me not having updated suhide to work around the latest couple of SafetyNet updates, even though I know how. I was waiting to see how the changes introduced with the Pixel were going to play out. Unfortunately I have to report that there are some new complications with doing something like suhide on a partition layout like the Pixel's - the /system_root mount and /system symlink are tough to hide. I doubt I'll be putting more time into suhide until I can think up a workaround for these problems.


Download

Pixel (sailfish):
https://download.chainfire.eu/1007/CF-Root/CF-Auto-Root/root-sailfish-pixel.zip

Pixel XL (marlin):
https://download.chainfire.eu/1008/CF-Root/CF-Auto-Root/root-marlin-pixelxl.zip

SuperSU v2.78 SR2 ZIP:
http://download.chainfire.eu/1009/SuperSU/SR2-SuperSU-v2.78-SR2-20161029143931.zip

(Do not use the SuperSU ZIP on work-in-progress TWRP releases for Pixel, it will not work - use the model specific links above instead; that includes you, unnamed SunShine author!)


Links

SuperSU thread on XDA:
http://forum.xda-developers.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133


SuperSU changelog

- File-based-encryption support
- CCMT: Add privacy policy dialog
- CCMT: Update translation files
- su+gui: support /system_root paths
- sukernel: add kernel binary extract/replace
- sukernel: add kernel cmdline extract/replace
- sukernel: add system_root import
- sukernel: add slot-kernel patch
- sukernel: support /boot paths
- suinit: new binary component
- launch_daemonsu: restructure to support /su in initramfs or system_root
- ZIP: Support systemless on 5.0 (requires 3rd party patches)
- ZIP: Support for A/B slot systems with / inside system partition
Shared publiclyView activity