NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.
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:
- 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)
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 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
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.
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.
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.
Pixel XL (marlin):
SuperSU v2.78 SR2 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!)
SuperSU thread on XDA:
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
"- 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."
This was probably my fault, but in the EXTREMELY UNLIKELY event it wasn't, all I had to do was fastboot boot <BOOT.IMG> again and everything worked great, even with a custom kernel.
Great work Chainfire!
u are the MAN
As always, incredible work! Thank you
Tkx bro. You are the man! Temporaly without root... Pogo sucks....
awesome great work chainfire
+Jeff Corcoran keep ur head up Jeff we're all v proud of you for your brave alpha flashing o7
Great work, like everything you made! Thank you ?
..and then +Chainfire said : Let there be light !!
Just like in the bible .... or starwars , can't remember ..
Great work man, thanks
Chainfire #1 ????????
Chainfire holds the torch that leads the entire Android developer population through the dark.
You the man! ???
When I see that there are a lot of changes in here.. I wonder, how will custom kernels (+updates for them) and TWRP work together in future? I always hated it when you had one partition for kernel and recovery on Sony devices.. Now Google is doing the same. :/
Root for my OnePlus One aka bacon running Android 7.1 :D
( dont like cm root )
thank you so much you are amazing thank thank Chainfire
Words cannot express our gratitude for such a dedicated, genius android developer as Chainfire! Your work is a true gift to us all. Thank you sir ?
how to flash the new SuperSU on a Pixel XL seeing as we don't have a custom recovery yet??
Ohh man. The merged recovery and boot partitions back on the SGS1 devices was annoying. Not looking forward to dealing with that again. (At least TWRP has support for patching boot images now iirc)
Chainfire THANK YOU, your an Android God and I hope your around for a long time as the manufacturer's are doing everything they can to fight root.
In the time being, without FlashFire and custom recoveries, does anybody know a way to flash ZIPs? Trying to get viper4android up and running.
+Conor Haggerty still can't see where it says SuperSU is included in the boot to root image. But it is. I tested it.
AS well as the cell carriers
+Chainfire what would we do without out meaning the whole world. much respect man bottom of heart. thank you so much.
On pixel xl I tested firstly with just the root-to-boot which worked, then I flashed elementalX followed by root-to-boot and it worked fine. But I was on stock kernel beforehand.
Yes. Flashed kernel and immediately flashed the boot-to-root ...
I see that Google tries so hard to follow Apple's footsteps, and lock up tighter the Android... They are destroying exactly the advantage they had.
Can we use this SuperSU zip with non-Pixel devices running Android 7.1?
Thank you so much for this. Now since I don't know what to do with the root power I want to go back. How can I go back to not-rooted again?
Wonder if it's worth tir tk root anymore. Stock Android is so much better
I tried unrooting through SuperSU and it went away but I can't use Android Pay still. Do I have to lock the bootloader again?
So many thanks +Chainfire,this is The best,keep up a good work
+Musadiq Manas should work fine(no guarantees) I'm running SuperSU 2.78SR2 on my Nexus 5 running DUv11 N-7.0, no issues I can speak of yet regarding root.
Regarding the systemless in 5.0 what is the patch needed to be done? +Chainfire
Fuck you work fast Chainy
you r a legend
Thank you chain fire...so many depend in your hard work...and are great ful for it
U man are like the Android whisperer ? would have taken me years to make such progress, time I don't have so thanks a lot man, to open the doors of Androids customizability for us.
After rooting and battery going down below 15%, SystemUI just force closes repeatedly. Looks like I'm not the only one:
+Max Rumpf even Samsung had similar layout in early days if I remember correct. Having to reflash to keep preferred recovery will be a PITA for sure.
Edit: I remember correct. Early Samsung devices did this. So did Sony and I guess HTC
^w yxhtxxL@aca地图tl2 we oeq)p'ezwß
finally I'm able to root an a500w (samsung a5)... thanks chainfire!
I'm at a loss why SuperSU still only supports Gzip when there are ways to support other formats?
I have a boot image patcher here that can unpack and repack several different formats.
Thanks, as always, for your great contributions! Quick question - if we're running SR1 (and suhide), on Angler, is there any reason to upgrade to SR2?
After root. Is there a work around yet for getting native hotspot to work for unlimited data users?
15% on the battery I get system UI force closes leaves phone essentially in a force close loop but when I plug phone in on a charger the force closes stop. Alot of users report the same. Thanks Chainfire for your work.
Thnx for the incredible work
Just can't thank you enough!!!!
what precisely do the slot-kernel patch ?
+david hedge Not sure if u know this but for now you can use Network Signal Refresher Lite whether you are rooted or not to access wifi hotspot on unlimited data plan. Just hit the refresh button and then start your hotspot immediately after. Works like a charm.
+Mark Sokoli I have heard of this. But people were reporting that it disconnected after 15 to 20 min of use. Is that happening to you?
+Mark Sokoli I was just wondering if there was a fix for this if rooted. I know in other phones it was a build.prop fix. Curious if that works for pixel and how to do it.
No this hasn't ever happened to me. I just went on a 12 hour road trip
from Jersey to Indiana using my Verizon Unlimited Data Pixel XL hotspot for
the Nexus 7 in my car dash. Watched YouTube and listened to music the
entire trip no stutters.
Ok I will go get the phone and hope this works for me. Are you using the hotspot widget after you refresh?
I just open the app press the refresh button and then hit the hotspot
button on my notification bar. Not that much of an inconvenience. Also if
you pay for the app u can use a widget to refresh instead of opening the
app to do so.
How to install twrp on asus z00sd RAM 1GB ?
Not working. Please help!
+Phil Sweeney same here about the 15% issue. Is there a fix yet?
Hi, how to install systmless SuperSU 2.78 SR2 on android 5.0, where to get this patches?
+Chainfire, is/will it be possible to root Nexus 5X with file base encryption enabled? It would probably require a boot-to-root method as well? Excuse my ignorance. Thank you.
Thanks Chainfire, really appreciate this. Is there a difference between fastboot flashing unlock and fastboot oem unlock? I only did oem, then realized I should have also done flashing unlock. I went back and did flashing unlock - the output was this:
(bootloader) Device already : unlocked!
OKAY [ 0.082s]
finished. total time: 0.083s
I don't want to proceed with root until I know that I didn't mess this up already. Also will fastbooting boot-to-root wipe the phone again, or only affect boot img?
Sorry came here by direct link. Will check xda for answers
+Chainfire Do you have a copy of the "Alpha" TWRP floating around. I want to get this loaded otherwise all flashing must be done via Fastboot and via .img files which is cumbersome. I have a few zip files if like to use on a frequent basis.
+Victor Evrard yes, with the SuperSU ZIP from this post, file-based encryption should also be supported on the 5X.
+P. Hisada There's no difference between the two. Every now and then, Google just decides to rename things.
+Shawn X I do not. And if I did, I wouldn't be sharing it. That's for the TWRP team to do.
I'm now getting a System UI crash!!!
System UI crash is when the battery drops below 15%. Plug it up!
I had to flash it twice for it to work as well.
+david hedge for unlimited tether, add this line to the end of the /system/build.prop file:
FYI adb sideloading SuperSU v2. 78 SR2 ZIP with TWRP on Nexus 5X with file base encryption worked flawlessly. I haven't noticed any problem beside a much longer delay granting root to apps that request it. But so far, no problem.
Thanks +Jimmy McMillan! That worked. Is it a bug? Any fix?
Not yet, Chainfire is aware and possibly has a fix due out soon...?
Ten new atualizaçāo of SuperSU for end of the year 2016.