text: TWRP has been released for the Google Pixel and Pixel XL
  
  We may earn a commission for purchases made using our links.
  
  Let the custom ROM flashing begin!
  
  One of the most common reasons that users come to our forums is to flash custom mods, kernels, or ROMs. Developers pour countless hours into customizing their software for the benefit of the community. But none of this work is feasible without having a means to install these modifications.
  
  The first step required before you can step into the world of Android modding is to unlock your bootloader. For users of the Pixel and Pixel XL, this step is already possible on all variants of the two devices. The next step is to flash a custom recovery image that will allow you to then flash custom ROM or kernel images as well as allowing you to make full system backups in case anything goes wrong. That’s where the incredibly popular Team Win Recovery Project (TWRP) comes in.
  
  Available on a plethora of devices from nearly every OEM under the sun, TWRP has been the go-to custom recovery for anyone looking to modify the software on their device. And now, the two Google Pixel phones can soon join in on that fun. XDA Senior Recognized Developer Dees_Troy has just released the first TWRP alpha for the Google Pixel and Pixel XL. Provided that you’ve already unlocked your bootloader, you can now flash the recovery onto your device. Although, there are a few changes to the way TWRP will be installed that we should note.
  
  Installation
  
  If you’ve ever manually installed TWRP onto your device, then you might be familiar with the fastboot commands needed to flash the TWRP image to the recovery partition. Due to the partition changes made for ‘seamless updates’ to work in Android Nougat for the Pixel and Pixel XL, you will NOT be issuing those same commands. Forget everything you think you know, and carefully read the following instructions before you act. In essence, what you will actually be doing to install TWRP is to boot the TWRP image, then using the automated installation script which will handle flashing TWRP to both boot partitions.
  
  First up, if you haven’t already you’ll need to grab the Google USB driver as well as the fastboot binary (we recommend downloading and extracting Minimal ADB & Fastboot to the directory of your choice). Next, download the appropriate TWRP installation files for your device (Pixel and Pixel XL). You will need to move the .zip file onto your device’s internal storage, but leave the .img file on your computer. Then, open up a command prompt and check that your device is recognized by issuing fastboot devices into the command prompt. If you see your device’s serial number, then the fastboot protocol detects your device. Finally you’ll need to temporarily boot up the TWRP image by issuing this command:
  
  fastboot boot path/to/twrp.img
  
  Note that “path/to/” refers to the actual directory in which the downloaded TWRP image file is located. Make sure that you are issuing fastboot boot and not fastboot flash, and that the file you are booting is not the zip file. Once you’ve issued the boot command, your device will retrieve the TWRP image from your computer and temporarily boot into TWRP. You’re almost done at this point.
  
  All that you need to do now is to make TWRP survive a reboot by flashing it to both of your device’s boot partitions. Thankfully, all of the work there is handled by the automated installation script that you downloaded earlier. Simply use the TWRP interface to navigate to and install the TWRP installation zip just like you would install any custom ROM, mod, or kernel zip. After that, TWRP will be accessible to you no matter which active partition slots are being used.
  
  TWRP Alpha v1
  
  Since this is an alpha release, there are bound to be issues. Right now, Dees_Troy has outlined three issues to be aware of. First up, due to the introduction of File Based Encryption (FBE) in Nougat, data restoration might pose a problem.
  
  File Based Encryption (FBE) can be a tricky. If a restore doesn’t work correctly, it can trigger an automatic wipe of your data. I’ve tested it a little on my Pixel XL, but I haven’t had time to test it extensively. Sometimes TWRP will fail to prompt you to enter your password or otherwise fail to set up decrypt properly. If this happens, reboot TWRP. It seems to be some kind of timing issue and I haven’t had time to track it down yet.
  
  There’s no saying it may happen to you, but it could happen to you. If you don’t regularly make backups of your data offline or on the cloud, then don’t be shocked when something goes wrong and your entire data is wiped. I’ve had that happen to me before, and it sucks.
  
  Update #2: Dees_Troy has provided a more technical explanation for what could go wrong, and how he’s planning on solving it. See the second addendum at the end of the article for more details.
  
  Next, if you are currently using the multi-user feature (including guest features) on your device, then you will want to avoid using TWRP for now.
  
  File Based Encryption means that each user’s folders are separately encrypted. To make a proper backup, factory reset, etc, we would have to have the user decrypt for every individual account on the device.
  
  At this time, TWRP only supports single user setups even if you happen to know the encryption password of the other users on your device. Dees_Troy has told us that he has successfully decrypted additional users using a command line tool, but that implementing this feature in TWRP isn’t a high priority right now and may instead be released in a future update. Last week our XDA Twitter account polled users on behalf of Dees_Troy asking if they utilize the multi-user feature, and the vast majority stated that they do not use multi-user, so we don’t expect this limitation to affect very many people.
  
  Poll: Do you regularly use the multi-user feature to share your phone with another person? — XDA Developers (@xdadevelopers) November 6, 2016
  
  But there is one more issue that is more relevant to the vast majority of users who will be installing TWRP. Currently, SuperSU will not function alongside TWRP.
  
  Installing TWRP at this time will remove root if you are currently rooted. A SuperSU update will be required to allow TWRP and SuperSU to co-exist.
  
  Update #1: Please see the addendum by Chainfire at the end of the article if you are currently using SuperSU and plan on flashing TWRP. Dees_Troy explained the reason for this interference to XDA-Developers as such:
  
  Chainfire uses the ramdisk of the bootimage to do his system-less root. This is the same ramdisk that Google intended to be used for recovery. I am pretty sure that Chainfire will be able to come up with a way to make it work with TWRP, but TWRP needs a small change to the init binary to make decrypt work properly and Chainfire needed a different change to his init binary to make his ramdisk work for both normal boot and recovery.
  
  In other words, Chainfire’s systemless root method modifies the same binary that TWRP needs to modify in order to get data decryption working. Therefore, when you flash TWRP you are overwriting the changes made to the init binary by Chainfire’s systemless root method. While this is a minor setback, thanks to the dual partition nature of the Pixel (and future devices shipping with Nougat), TWRP has some nifty new capabilities.
  
  Pixel devices have 2 “slots” for ROMs / firmware. TWRP will detect whichever slot is currently active and use that slot for backup AND restore. There are buttons on the reboot page and under backup -> options to change slots. Changing the active slot will cause TWRP to switch which slot that TWRP is backing up or restoring. You can make a backup of slot A, switch to B, then restore the backup which will restore the backup of A to slot B. Changing the slot in TWRP also tells the bootloader to boot that slot.
  
  What this essentially means is that you’ll soon be able to dual boot on your device. Unfortunately, since custom recovery has just been released, it will take some time for your favorite custom ROM developer to cook up something in the kitchen for your Pixel phone.
  
  Addendum #1 – SuperSU with TWRP
  
  We were informed by Chainfire that anyone who is currently using SuperSU on their Google Pixel or Pixel XL are strongly advised to flash the stock boot images to both partitions prior to installing TWRP. In order to accomplish this, you will need to download the Factory Image for your device and manually extract the stock boot image from the archive. Then, you will need to flash the boot image to both partitions using fastboot, as such:
  
  fastboot flash boot_a boot.img fastboot flash boot_b boot.img
  
  Issuing both of these commands will flash the stock boot image from the Factory Image to both boot partitions on your device. Then, you may proceed to install TWRP.
  
  Addendum #2 – File-Based Encryption with TWRP
  
  Speaking with Dees_Troy, he offered the following explanation as to when a restoration could go wrong and result in a total data wipe:
  
  ext4 file based encryption doesn’t allow you to apply an encryption policy to a folder that is *not* empty. Right now we’re working around that by not deleting a select list of folders (we can delete what’s inside the folders, but not the folder itself). If for some reason a folder that needs to be encrypted gets deleted, the restore might create an unencrypted folder then fill it with some stuff. Once the folder is non-empty, you can’t set encryption on it. When the device boots Android again, the init binary tries to set an encryption policy and if it sees an error when setting a policy, it forces a wipe. This is precisely where the error is thrown and where the wipe is initiated, if you care about that kind of thing.
  
  In less technical terms, during the process of restoring a NANDroid backup the recovery needs to overwrite all of the necessary existing files in your partitions that are saved in the backup. In order to access the files in the data partition, the recovery needs to have decrypted this partition using your decryption password. While the recovery does have the ability to simply delete and overwrite every folder in the data and system partitions, in doing so it may cause an error with the encryption policy.
  
  By deleting a folder that is meant to be encrypted, TWRP will in its place create an unencrypted folder and restore all of the files from the backup in this new directory. However, because File-Based Encryption will encrypt different files and folders with different encryption keys as opposed to the entire partition, this single change breaking encryption to a single folder on your device will cause the entire chain to throw an error. Android’s policy is to then initiate a full data wipe, resulting in Android wiping everything in your internal storage.
  
  Fortunately, Dees_Troy has already identified a list of folders that will need to be excluded from TWRP’s deletion process so that this error won’t be triggered. He replaced the init binary such that it would trigger the error during restoration but not wipe the device, allowing him to log exactly which folders must not be deleted. A full list of folders was provided to us, but we will not reproduce that list here due to its length.
  
  Do you plan on running a custom ROM or kernel on your device, or will you remain on stock firmware? Let us know in the comments below!