Root is now available for the Google Pixel and Pixel XL: Here’s what Changed and what Works

Root is now available for the Google Pixel and Pixel XL: Here’s what Changed and what Works

This method is outdated and may not work. Please visit our Google Pixel and Pixel XL forums for the latest root methods.

As promised, systemless root for the Google Pixel and Pixel XL is now available. XDA Senior Recognized Developer Chainfire was working on root for the Google Pixel phone running Android 7.1 Nougat these past few days, and he has reached a stage in his development where he is now comfortable enough sharing his work with the community.

screenshot_20161029-141704Root access for the Google Pixel and the Google Pixel XL is available by installing SuperSU 2.78 SR2, which enables su access without touching anything in the system partition and allowing for dm-verity to be toggled. Before you can root your device, you will first need to have your bootloader unlocked. The first step in unlocking your bootloader is to download the adb and fastboot binaries (we recommend grabbing Minimal ADB & Fastboot from our forums) and then installing the appropriate Google USB Driver for your machine.

If you’ve purchased your Pixel device straight from Google, then you only need to issue a fastboot flashing unlock command followed by fastboot oem unlock. In case you purchased your Pixel from Verizon or EE, you would need to unlock your bootloader through the dePixel8 tool. But hurry, because the SunShine developers have mentioned that their bootloader unlock exploit may be patched in the upcoming November security update!


How to Install SuperSU on your Pixel

As Chainfire mentions in his Google+ post, you will need to first download the boot-to-root images for the Pixel or Pixel XL off of his website. You can click here to download the zip for the Google Pixel, or click here to download the zip for the Google Pixel XL. After downloading the zip, you need to fastboot boot the boot-to-root image, DO NOT fastboot flash the image! In other words, the only command you’ll need for the two devices is the following:

fastboot boot boot-to-root.img

Wait a few minutes, and after a few reboots you’ll be booted up with full root access. Yay!


Immediate Uses of Root Access

By the way, besides the usual functionality that root access should bring we’ve gone ahead and tested a few things that we knew you all would be interested in. First up, can you bring back Google Now on Tap? The answer is yes! All you need to do is edit build.prop with the following change, reboot, and clear Google App data and you’ll no longer be greeted with the Google Assistant.

Change

ro.opa.eligible_device=true

to

ro.opa.eligible_device=false

What about another commonly hidden feature: double-tap-to-wake? We’ve looked around for the hidden toggle, and have discovered what appears to be it.

sailfish:/sys/devices # echo 1 > ./soc/7577000.i2c/i2c-3/3-0020/input/input3/wake_gesture

Unfortunately, when we changed the value it didn’t seem to stick. For now, it seems you’ll have to flash a custom kernel such as ElementalX to get d2tw working.

Some other things we’ve tested include whether or not Titanium Backup works (it does), Better Battery Stats (works), Substratum/Layers Themes (seems to be having some issues), and ad-blocking (fails). Ad-away fails to work currently because /system cannot be mounted read-write by default, so we’ll have to wait until TWRP is available before we can flash the systemless workaround for Ad-Away. And yes, we’ve already tried using FlashFire to flash the Ad-Away enabler for systemless root, but that doesn’t seem to be working either at this time.

 

sailfish:/sys/devices # mount -o rw,remount /system
mount: '/system' not in /proc/mounts

Update: Chainfire has confirmed that FlashFire, and other apps, will need to be updated before they can be used. See below for more details.

Update 2: Chainfire has messaged us with a workaround to get AdAway working until the app is itself updated. See the addendum at the end of the article.

Here are some screenshots showing that Titanium Backup works, though. So if you’re coming from another device and you would like to restore all of your backed up apps, you can be rest assured that all of your app data will be now be restored.

We’ll continue to dive deep into our Pixel devices to see what we can toggle. Which “Pixel exclusive” feature will be the next to fall?

sailfish_sys_class


The “Struggle” to Achieve Root

Chainfire is fairly meticulous when it comes to release notes. When you’re the developer providing tens of thousands of users a method to achieve root access, it makes sense to be as transparent as possible lest you face a horde of confused users wondering why something is broken. While his Twitter account (@ChainfireXDA) is reserved more for short announcements, Chainfire tends to post much-welcome, lengthy explanations on his Google+ account. This time is no different.

First off, Chainfire explains what changes were made to the two Pixel phones that he needed to work around to achieve root access. In particular, Chainfire first describes the new partition layout on the Pixel devices.

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)

As we’ve covered previously, these partition changes on the two Pixel phones would require some modifications to the current root method. Chainfire has confirmed that these modifications to /system partition required a different approach, one that may involve modifying the kernel.

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).

In other words, there’s no way to disable dm-verity without some modification to the kernel, as we suspected. Because the kernel is force enabling dm-verity, Chainfire needed to slightly modify the kernel in order to stop dm-verity from preventing changes to the system partition. Luckily, though, Chainfire discovered that his modification only requires a small kernel binary patch, but not a full kernel recompile. Thus, his solution should remain a generic solution for Android 7.1 devices with an A/B partition scheme.

To explain this new root method in more detail, Chainfire achieves systemless root by making the kernel use the boot image’s initramfs as its root directory, rather than anything from the system partition. To do so, the root directory contents in the system partition are imported to the boot image, which enables the modification of these files without having to modify any system files. The system partition is mounted to /system_root and /system itself sim-linked to /system_root/system. And finally his kernel patch modifies the kernel such that it ignores the command sent from the bootloader which would ordinarily enforce dm-verity.

However, there are some rather trivial issues introduced with this new method. Certain apps, such as FlashFire or AdAway (both of which we’ve shown don’t work) expect the system partition to be mounted as /system, not /system_root, and will need to be updated accordingly. Although, you can try remounting system as such

mount -o rw,remount /system_root

Which should allow you to write to /system. We haven’t yet tested which root apps that fixes, but you’re free to test it for yourself. Finally, Chainfire is unsure if suhide will work with this new rooting scheme, but he states he will continue looking for a workaround.


To download SuperSU for the Google Pixel phones, head on over to the XDA forum thread. A big thanks to Chainfire for bringing root over to the devices! Let the Tweaking Games begin!

Visit the SuperSU XDA Subforum!

This story is developing and will be updated as we receive new information. One Google Pixel was sacrificed in the making of this article. RIP Jeff’s data.


Addendum #1: Temporary Fix for AdAway

Download AdAway v3.1.2 from our forums, then use either a terminal emulator or ADB shell to enter the following command:

mkdir /su/etc; cp /system/etc/hosts /su/etc/hosts; echo "#!/su/bin/sush\nmount -o bind /su/etc/hosts /system/etc/hosts" > /su/su.d/50adaway; chmod 0700 /su/su.d/50adaway

Reboot, and you should have system-wide ad blocking.

Discuss This Story

You might also like