Install

Obtaining fastboot

You need an updated copy of the fastboot tool and the directory containing it needs to be included in the PATH environment variable. You can run fastboot --version to determine the current version. It must be at least 29.0.6. You can use a distribution package for this, but most of them mistakenly package development snapshots of fastboot, clobber the standard version scheme for platform-tools (adb, fastboot, etc.) with their own scheme and don't keep it up-to-date despite that being crucial.

List of distribution packages:

• Arch Linux: android-tools provides fastboot and other useful tools not required for installation such as adb. android-udev provides udev rules allowing fastboot and adb to work in local sessions without root.
• Debian and Ubuntu: android-sdk-platform-tools-common provides udev rules allowing fastboot and adb to work in local sessions without root. The udev rules in Debian and Ubuntu are out-of-date, but it has the necessary entries for Pixel phones. The adb and fastboot packages are currently both broken and far too out-of-date to be any use, so avoid those. The version check in the flashing script will prevent accidentally using these.

curl -O https://dl.google.com/android/repository/platform-tools_r30.0.5-linux.zip
echo 'd6d72d006c03bd55d49b6cef9f00295db02f0a31da10e121427e1f4cb43e7cb9  platform-tools_r30.0.5-linux.zip' | sha256sum -c
unzip platform-tools_r30.0.5-linux.zip

curl -O https://dl.google.com/android/repository/eabcd8b4b7ab518c6af9c941af8494072f17ec4b.platform-tools_r30.0.5-darwin.zip
echo 'SHA256 (eabcd8b4b7ab518c6af9c941af8494072f17ec4b.platform-tools_r30.0.5-darwin.zip) = e5780bad71a53cf9d693e1053a0748f49e4a67cc1f71d16a94ab4c943af3345f' | shasum -c
tar xvf eabcd8b4b7ab518c6af9c941af8494072f17ec4b.platform-tools_r30.0.5-darwin.zip

curl.exe -O https://dl.google.com/android/repository/platform-tools_r30.0.5-windows.zip
(Get-FileHash platform-tools_r30.0.5-windows.zip).hash -eq "549ba2bdc31f335eb8a504f005f77606a479cc216d6b64a3e8b64c780003661f"
tar xvf platform-tools_r30.0.5-windows.zip

export PATH="$PWD/platform-tools:$PATH"

$env:Path = "$pwd\platform-tools;$env:Path"

fastboot version 30.0.5-6877874
Installed as /home/username/downloads/platform-tools/fastboot

Obtaining signify

To verify the download of the OS beyond the security offered by HTTPS, you can use the signify tool. If you do not have a way to obtain signify from a package repository you're already trusting, it does not make sense to use it. GrapheneOS releases are hosted on our servers and we do not have third party mirrors. A compromised signify would be able to compromise your OS and the GrapheneOS download due to the lack of an application security model on traditional operating systems. It would be worse than not trying to verify the signatures. It's far less likely that our servers would be compromised than someone's GitHub account or GitHub itself. You're already trusting these installation instructions from our site, which is hosted on the same static web server infrastructure as the releases.

List of distribution packages:

• Arch Linux: signify
• Debian: signify-openbsd with the command renamed to signify-openbsd
• Ubuntu: signify-openbsd with the command renamed to signify-openbsd

On Debian-based distributions, the signify package and command are an unmaintained mail-related tool for generating mail signatures (not cryptographic signatures) with the final releases from 2003-2004 made directly by the developer via the Debian package without upstream releases. Please pressure them to correct this usability issue.

Troubleshooting

A common issue on Linux distributions is that they mount the default temporary file directory /tmp as tmpfs which results in it being backed by memory and swap rather than persistent storage. By default, the size is 50% of the available virtual memory. This is often not enough for the flashing process, especially since /tmp is shared between applications and users. To use a different temporary directory if your /tmp doesn't have enough space available:

mkdir tmp
TMPDIR="$PWD/tmp" ./flash-all.sh

A majority of failed flashes tend to be caused by substandard USB connectors, plugging in via hubs or bad cables which aren't properly up to the USB standard. The scrollback from a failed flash will contain valuable diagnostic information which is essential in knowing where and how the process went wrong.

Front I/O ports on desktop computer cases and USB 3.1 or USB C on many laptops often aren't implemented properly or are broken in subtle ways, which may cause flashing to fail even on a USB port that works for other peripherals. Older Linux kernels that predate version 5 may have inadequate or patchwork support for USB C or USB 3. If you are installing from a Linux distribution, ensure your distribution uses a modern kernel.

Always use a high quality USB A to USB C cable with a rear USB port directly on your motherboard, and never use a USB hub for flashing. Never install from a virtual machine; USB passthrough in software emulation may be broken or inadequate and this can cause the flashing to fail.

Disabling OEM unlocking

OEM unlocking can be disabled again in the developer settings menu within the operating system after booting it up again.

Verifying installation

Verified boot authenticates and validates the firmware images and OS from the hardware root of trust. Since GrapheneOS supports full verified boot, the OS images are entirely verified. However, it's possible that the computer you used to flash the OS was compromised, leading to flashing a malicious verified boot public key and images. To detect this kind of attack, you can use the Auditor app included in GrapheneOS in the Auditee mode and verify it with another Android device in the Auditor mode. The Auditor app works best once it's already paired with a device and has pinned a persistent hardware-backed key and the attestation certificate chain. However, it can still provide a bit of security for the initial verification via the attestation root. Ideally, you should also do this before connecting the device to the network, so an attacker can't proxy to another device (which stops being possible after the initial verification). Further protection against proxying the initial pairing will be provided in the future via optional support for ID attestation to include the serial number in the hardware verified information to allow checking against the one on the box / displayed in the bootloader. See the Auditor tutorial for a guide.

After the initial verification, which results in pairing, performing verification against between the same Auditor and Auditee (as long as the app data hasn't been cleared) will provide strong validation of the identity and integrity of the device. That makes it best to get the pairing done right after installation. You can also consider setting up the optional remote attestation service.

Replacing GrapheneOS with the stock OS

Installation of the stock OS via the stock factory images is the same process described above. However, before locking, there's an additional step to fully revert the device to a clean factory state.

The GrapheneOS factory images flash a non-stock Android Verified Boot key which needs to be erased to fully revert back to a stock device state. After flashing the stock factory images and before locking the bootloader, you should erase the custom Android Verified Boot key to untrust it:

fastboot erase avb_custom_key

Further information

Please look through the usage guide and FAQ for more information. If you have further questions not covered by the site, join the official GrapheneOS chat channels and ask the questions in the appropriate channel.