GrapheneOS Release History: Devices, Hardening and the Update Model

GrapheneOS is a free, open source operating system built on the Android Open Source Project, hardened for privacy and security and officially supported only on Google Pixel phones and the Pixel Tablet. As of 24 October 2026 its newest release is 2026102100, based on Android 17, with production builds for 21 devices from the Pixel 6 to the Pixel 10a. Updates arrive automatically in the background through Alpha, Beta and Stable channels, usually within days of each monthly Android security patch.

This post covers where GrapheneOS came from, how its versions and channels work, every Android base it has shipped since 2019, which devices it supports and why, what each hardening feature does, how sandboxed Google Play differs from a stock install, and how to verify an install yourself. GrapheneOS facts come from grapheneos.org and the project's GitHub; Android and Pixel facts come from source.android.com and Google's support pages.

Key takeaways

• Pixels only, on purpose. The GrapheneOS FAQ lists official production support for 21 devices, Pixel 6 through Pixel 10a plus the Pixel Fold and Pixel Tablet. The project says broad device support "would be directly counter to the values of the project" because most hardware cannot meet its security requirements.
• The version is a date. Releases are ten digit numbers such as 2026102100 (21 October 2026). Older releases used a dotted form such as 2019.09.18.14. A security preview build adds 01 at the end, for example 2026102101.
• Three channels. The releases page says each build goes to Alpha first, then to Beta soon after, then to Stable once Beta users have tested it.
• Every Android major version since 10. GrapheneOS moved to Android 10 in September 2019, Android 11 in September 2020, Android 12 in October 2021, Android 13 in August 2022, Android 14 in October 2023, Android 15 in October 2024, Android 16 in June 2025 and Android 17 in June 2026.
• Device support ends when firmware support ends. The FAQ gives each Pixel's minimum support end date from Google. The Pixel 6 and Pixel 6 Pro reach theirs in October 2026, so owners should plan a replacement now. Pixel 8 and newer have a 7 year minimum.
• Hardening goes deep. hardened_malloc, hardware memory tagging on Pixel 8 and later, exec based app spawning, a per app Network toggle, a Sensors toggle, Storage and Contact Scopes, Secure Paste, USB-C port control that defaults to "Charging-only when locked" and an 18 hour auto reboot by default.
• Google Play is optional and unprivileged. Sandboxed Google Play runs as ordinary apps inside one profile. It gets no special access, but anything you send to Google through it still reaches Google.
• Relock the bootloader. Installation ends with fastboot flashing lock, which turns on full verified boot. On Pixel 6 and later, the yellow boot notice shows the full SHA-256 of the verified boot key so you can check it against the published value.

For the Android side of this story, see Android release history and the security features in every version from 10 to 16 and how the Android verified boot chain of trust works.

What GrapheneOS is and where it came from

Origins: from a solo project to CopperheadOS to GrapheneOS

The project's history page says GrapheneOS was founded by Daniel Micay in late 2014 as a solo project. Its first work was a port of OpenBSD's malloc to Android's Bionic C library and a port of the PaX kernel patches to the kernels of supported devices. It then grew a large set of homegrown changes, especially low level hardening of the compiler toolchain and Bionic, and much of that early work was landed upstream in AOSP or shaped the upstream changes that replaced it.

In late 2015 a company was incorporated that became the project's main sponsor, and during that period the OS was known as CopperheadOS. The history page says the project and that sponsor split in 2018. After the split, the project was briefly renamed AndroidHardening and then GrapheneOS. The releases changelog marks 2019.03.05.03, built for the Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL, as the "final and only tagged release branded as the Android Hardening project". Everything after that carries the GrapheneOS name. The FAQ answers the CopperheadOS question directly and points to the history page; for the project's own account, read it there.

How the project is run and funded today

The history page says the project now has "multiple full-time and part-time developers supported by donations" along with companies collaborating with it, and that the GrapheneOS Foundation was created as a non-profit organisation in Canada in March 2023 to handle the intake and distribution of donations. The FAQ adds that the project is funded entirely by donations, and the history page says it will not again be closely tied to any single sponsor or company.

The code is open source and permissively licensed. The FAQ explains that the project avoids GPLv3 code because it wants GrapheneOS to remain usable on devices with an immutable root of trust, which GPLv3 is designed to forbid. The source lives in the GrapheneOS GitHub organisation, with separate repositories for the OS, the kernel trees, hardened_malloc, the Vanadium browser, the Auditor app and the infrastructure.

Upstream contributions

GrapheneOS is not only a downstream fork. The FAQ says the project has contributed to AOSP, the Linux kernel, LLVM and OpenBSD, and that several AOSP changes, including removing app access to low level process, network, timing and profiling information, started as GrapheneOS work. That matters for anyone comparing feature lists: some protections that are now standard Android began as GrapheneOS patches, which is why the features page lists only improvements beyond current AOSP rather than everything the project ever built.

The long term roadmap

The FAQ describes a direction well beyond a hardened fork. The first step is to deploy pKVM and crosvm (Android's protected hypervisor and virtual machine monitor) to reinforce existing boundaries and run Android apps inside virtual machines. Over many years the project wants to move toward a microkernel based design with a Linux compatibility layer, and eventually into hardware. It also says it plans to partner with phone makers to build devices that meet all of its requirements.

How the release model works

Version numbers are build dates

A GrapheneOS release number is a timestamp. The current format is a ten digit number: four digits of year, two of month, two of day and two more digits. 2026102100 is the release from 21 October 2026. When the project ships a security preview build alongside a regular release, the preview gets the next number, so the preview companion of 2026102100 is 2026102101.

The format has changed over time:

The releases page lists about 450 tagged releases between March 2019 and October 2026. Untagged snapshot builds, such as the earliest releases and early device bring up builds, are not listed.

Alpha, Beta and Stable

The releases page describes the pipeline in one paragraph. Developers test a build, then push it to the Alpha channel, then to Beta shortly afterwards, and finally to Stable once Beta users have tested it. Sometimes Beta testing finds a problem, and a replacement build goes to Beta instead of the aborted one. Because the update system blocks downgrades, the page advises anyone who cannot live with a temporary problem while a fixed Beta build is prepared to stay on Stable.

Every device page on the releases site lists all three channels side by side. On 24 October 2026, all 21 supported devices showed 2026102100 on Stable, Beta and Alpha, which is the usual state a few days after a release.

The usage guide says the release channel setting in Settings, System, System update defaults to Stable and can be switched to Beta by people who want to help test.

How fast Android security patches arrive

Google publishes an Android Security Bulletin every month. The October 2026 bulletin was published on 5 October 2026 and says that security patch levels of 2026-10-01 or higher address all of its issues. GrapheneOS changelog entries state which patch level each release brings in. The 2026100600 release, published the next day, declares the full 2026-10-05 patch level and moves Pixels to the October 2026 firmware and hardware abstraction layers (HALs).

Two details make GrapheneOS faster than the patch level suggests:

1. Kernel LTS updates. The features page explains that GrapheneOS ships the latest Linux Generic Kernel Image (GKI) long term support point releases on supported Pixels rather than waiting for quarterly stock updates. Recent changelogs show the 6.1, 6.6, 6.12 and 6.18 branches being refreshed in nearly every release, plus extra upstream security patches backported ahead of the GKI LTS branches.
2. Security preview releases. GrapheneOS added an opt in for security preview releases to its System Updater in the 2025092500 release. Each recent changelog states that the companion preview build carries the Android 17 security patches from bulletins that have not been published yet. For 2026102101, the notes list the November 2026 through April 2027 bulletins. The changelog links to a separate project post that explains how these previews work.

Over the air updates: what happens on the device

The usage guide describes an updater built for low maintenance:

• It checks for updates about once every six hours when there is network connectivity.
• It downloads and installs in the background, resumes interrupted downloads, and installs to the inactive A/B slot, so an interrupted install is harmless.
• It uses delta (incremental) packages when one exists from your installed version to the latest one.
• If the new version fails to boot, the device rolls back to the previous version and retries the download.
• It works while the device is locked and idle, including before first unlock.
• You can restrict updates to non roaming or unmetered networks, require a battery level above the warning threshold (15 percent by default) or require charging.
• An opt in "Automatic reboot" setting lets the device reboot itself after an update once it has been idle for a long time.

Why the update server does not have to be trusted

The usage guide explains that the update server is not a trusted party, because updates are signed, verified and protected against downgrades. The update request carries no identifying information, so the server learns only the connecting IP address and the version you are updating from. GrapheneOS also rejects any update package with a serialno constraint, both over the air and when sideloaded. The guide says this means the project could not build and ship a malicious update aimed at one specific device even if ordered to.

The releases page lists three layers of verification: an internal signature on the update package checked by the updater (or by recovery when sideloading), a separately signed payload for Android's update_engine, and finally verified boot plus the hardware keystore. A downgrade is impossible unless the project signs a special downgrade package with its release key.

Offline and sideloaded updates

For devices that never connect to the internet, the releases page offers a full update package per device that can upgrade from any earlier version to the new one. The usage guide explains how to apply it through recovery with adb sideload. Recovery verifies the same signatures and downgrade protection as the updater. The releases page also warns that update packages are not for the initial installation, and that guides suggesting otherwise are wrong.

Every major release: a dated timeline

The table below lists the first GrapheneOS release on each Android major version and the main quarterly platform releases (QPRs), with the device milestones that matter for planning. Dates are the release numbers from the GrapheneOS changelog; Android public release dates are as stated in those same notes where given.

A few patterns stand out. The gap between Google's stable release of a new Android version and the first GrapheneOS release on it has ranged from one day (Android 15, released by Google on 15 October 2024) to about three weeks (Android 16, released on 10 June 2025, when the 2025063000 notes say Pixel device support had been removed from AOSP and had to be rebuilt). Until a port is ready, the project backports security patches to the previous base, as its June 2025 notes describe for Android 15 QPR2. Quarterly releases (QPRs) are treated as major releases because they bring new firmware, drivers and framework code.

How the changelog reads

Each entry lists the devices that got the build, the changes since the previous release and a line on security patches. The 2026101600 notes, for instance, extend the Sensors permission to device specific sensors, fix an upstream Android vulnerability in WindowManagerService and update Vanadium three times. The changelog is also an Atom feed you can follow in any reader.

Which devices are supported and why

The current list

The FAQ lists official production support for these devices, with codenames you will see in file names and fastboot output:

The FAQ strongly recommends buying only the Pixel 8 or newer, because 8th generation and later Pixels carry a 7 year minimum support guarantee from launch (up from 5 years) and add ARMv9 hardware memory tagging, pointer authentication and branch target identification. GrapheneOS uses memory tagging by default for the base OS and known compatible user installed apps.

Why not other phones

The FAQ is explicit that the device list is chosen for security rather than reach. It publishes a non exhaustive list of requirements that a future device must meet, and says every device from the Pixel 8 through the Pixel 10a meets or exceeds them. The most important ones:

• Support for alternate operating systems with full hardware security functionality, which means a user settable verified boot key and working attestation once relocked.
• Complete monthly Android Security Bulletin patches for firmware, drivers and HALs with no regular delays longer than a week.
• At least 5 years of device support updates for phones (Pixels now have 7) and 7 for tablets.
• A Linux 6.1, 6.6 or 6.12 GKI kernel, hardware virtualization usable by GrapheneOS, hardware memory tagging and hardware control flow integrity.
• Isolated radios, GPU, storage, media codecs and image processor.
• A/B updates for firmware and OS with automatic rollback, and verified boot with rollback protection for both firmware and the OS.
• A verified boot key fingerprint for the yellow boot state shown as a full, non truncated SHA-256.
• A StrongBox keystore in a secure element, hardware key attestation for it, and Weaver throttling of disk encryption key derivation in the secure element.
• Insider attack resistance: the secure element must require the owner's authentication before accepting a firmware update.
• Hardware level USB data disabling, reset attack mitigation for fastboot mode, and no JTAG or serial debugging while locked.

The FAQ also notes that many other devices are supported at the source level, meaning GrapheneOS can be built for them, but that for most of them the hardware and firmware rule out a reasonably secure device no matter how much work goes into device support. It does not support running as a Generic System Image because its changes reach into the kernel.

Carrier locked phones

Both install guides warn about carrier variants. A carrier Pixel has the same hardware and firmware but a non zero carrier ID flashed in the factory, which disables bootloader unlocking in the stock OS. The FAQ says this is mostly a US issue. If you are buying a phone for GrapheneOS, buy an unlocked, carrier agnostic model.

How end of support dates are set

GrapheneOS does not set its own support windows. The FAQ says it can only fully patch a device while the manufacturer is still releasing updates for it, and that official GrapheneOS updates for Pixels usually end soon after Google's minimum guaranteed support ends. It publishes Google's minimum support end dates for each device:

Google's Pixel update page states the rule behind these dates: Pixel 6 and 7 family phones and the Pixel Fold get 5 years of OS and security updates from when each first became available on the Google Store in the US, and newer models get longer. The practical news in October 2026 is that the Pixel 6 and Pixel 6 Pro reach the end of that minimum this month. They still received 2026102100, but the FAQ warns that any extra months of updates are occasional and should not be planned around.

Extended support releases

When a device reaches end of life, GrapheneOS may ship extended support releases as harm reduction. The FAQ is blunt that these cannot deliver full security patches and should only be a last resort while you plan to buy a new device. The changelog shows how this played out before. The Pixel 4 and 4 XL received extended releases with a patch level frozen at 2022-11-01. From 7 December 2023, every changelog repeated that the Pixel 4a (5G) and Pixel 5 were end of life and should no longer be used because their firmware and drivers had stopped receiving security patches, and the Pixel 5a joined that line in September 2024. The FAQ now lists 19 end of life devices, from the Samsung Galaxy S4 and Nexus 5 to the Pixel 5a.

The hardening features, one by one

The features page lists only what GrapheneOS adds on top of current AOSP. It is long; these are the features most people ask about, described from that page and the usage guide.

hardened_malloc

GrapheneOS replaces the system memory allocator with its own hardened_malloc. The features page and the project README list its main properties:

• Fully out of line metadata with protection from corruption, which removes the classic techniques for exploiting the allocator itself.
• Separate memory regions for metadata, large allocations and each slab size class, with high entropy random bases and no address space reuse between regions.
• Deterministic detection of any invalid free.
• Zero on free, with detection of write after free by checking memory is still zeroed before reuse.
• Delayed reuse of freed memory through deterministic and randomised quarantines.
• On Pixel 8 and later, hardware memory tagging (ARM MTE) for small allocations, so many use after free and overflow bugs crash immediately instead of becoming exploitable.

hardened_malloc is portable. The FAQ says it supports musl, glibc and Bionic, and the features page notes it influenced the design of the newer musl allocator. Its maintenance continues in nearly every release; the 2026092500 and 2026102100 notes include quarantine and size class optimisations.

Hardware memory tagging

Memory tagging arrived with the Pixel 8's ARMv9 cores. The 2023103000 release enabled it for everything GrapheneOS builds and for compatible user installed apps, in asymmetric mode on all cores, which the notes say gives much stronger protection than asynchronous mode at little extra cost. The FAQ says users can extend it to all apps and opt out per app for the few that break. One side effect, documented in the usage guide under "Bugs uncovered by security features", is that memory tagging and hardened_malloc expose latent memory corruption bugs in apps, which then crash instead of silently corrupting memory.

Exec spawning

Stock Android starts apps by cloning a template process called the Zygote. The usage guide explains that this gives every app the same copy of values that are supposed to be random per process: ASLR layout, stack canaries, heap canaries and memory tags. GrapheneOS instead creates fresh processes with exec, so each app gets its own random values. The cost is about 200 milliseconds of extra cold start time on flagship devices and higher initial memory use. It can be turned off in Settings, Security and privacy, Exploit protection, Secure app spawning, but the guide notes that doing so also brings back the only known direct device identifier shared across profiles.

Network permission toggle

Android grants internet access to any app that declares the INTERNET permission, with no user control. GrapheneOS turns that into a real permission with a toggle. The features page says that when it is off, the OS "pretends the network is down": apps see no connectivity, get network errors rather than permission errors, and scheduled jobs that need the network do not run. It also guards localhost, which blocks apps from using it to talk across profiles. For compatibility it is on by default, but the installation confirmation screen shows the toggle so you can deny it when installing.

Sensors permission toggle

Android permissions cover the camera, microphone, body sensors and activity recognition, but not the accelerometer, gyroscope, compass, barometer or thermometer. GrapheneOS adds a Sensors permission for everything else. Denied apps receive zeroed data and no events, and the OS shows a dismissible notification when an app tries. You can make it default to off for user installed apps under Settings, Security and privacy, More security and privacy. The 2026101600 release extended it to device specific sensor types.

Storage Scopes and Contact Scopes

Storage Scopes let you tell an app it has the storage permission it asked for while actually granting nothing beyond the files it creates itself. You can then add specific files or folders. Contact Scopes do the same for contacts: the app sees an empty list until you grant access to particular contacts or groups. Both exist because many apps refuse to run without a permission they do not need, and denying it outright breaks them.

Secure Paste

Added as a per app toggle in 2026091700, Secure Paste stops apps reading clipboard content set by other apps. You paste through the system text selection toolbar, the keyboard, keyboard shortcuts or accessibility services instead. A global toggle sets the default.

USB-C port and pogo pins control

The features page describes five modes: Off, Charging-only, Charging-only when locked, Charging-only when locked except before first unlock, and On. The default, Charging-only when locked, blocks new USB connections as soon as the device locks, at both the hardware level in the USB controller and in the kernel, and turns off the data lines once existing connections end. It also disables USB-C alternate modes such as DisplayPort. The page contrasts this with Android's standard device admin USB toggle, which only disables high level USB handling and leaves protocol handling in the OS enabled.

Auto reboot

A locked device reboots after a set time without a successful unlock, which returns all data to the encrypted "at rest" state. The default is 18 hours, adjustable from 10 minutes to 72 hours or off. It runs in init, so crashing system processes cannot stop it, and it does not trigger in the Before First Unlock state.

Duress PIN and other unlock features

The features page lists a duress PIN and password that irreversibly wipe the device and its eSIMs when entered at any credential prompt; PIN scrambling for the lock screen and SIM PIN; two factor fingerprint unlock, which requires a short PIN after the fingerprint so you can use a long passphrase as the primary method; and support for longer passwords.

Verified boot for app updates and anti persistence

The features page says GrapheneOS completes verified boot for out of band updates to system apps by requiring fs-verity metadata signed with a trusted key, checked at install and at boot. That closes a gap where an attacker who gained persistence could hide in an updated system app. It also prevents downgrading system components whose version number was not incremented.

Other privacy defaults

The features page also lists Wi-Fi privacy improvements, an LTE only mode, an opt in network location service run by GrapheneOS, private screenshots, more user profiles with an End session button, the Vanadium hardened browser and WebView, and the Auditor app.

How sandboxed Google Play works

What it is

On stock Pixel software, Google Play services is a privileged system component that is deeply integrated into the OS. The usage guide describes the GrapheneOS alternative: a compatibility layer that lets the official Google Play apps run in the standard app sandbox, where they receive "absolutely no special access or privileges". GrapheneOS also never uses Play services as the backend for OS functions such as location, even when it is installed.

You install it from the GrapheneOS App Store, which installs Google Play services and the Play Store together. Because they are ordinary apps, they exist only in the profile where you install them, and only apps in the same profile can use them.

What it can and cannot access

The usage guide says the layer is nearly fully functional, including dynamite modules, Play Games, in app purchases, Play Asset Delivery, Play Feature Delivery and licence checks. It is clear about limits: functionality that depends on the OS using Play as a backend is unavailable, and some privileged features such as Android Auto need dedicated, opt in permission toggles.

What sandboxing does not change

Sandboxing limits what Google Play can reach on the device. It does not change what the apps send once you use them. If you sign in to a Google account, enable Google's location accuracy service, receive push messages through Firebase Cloud Messaging or install apps from the Play Store, those interactions go to Google exactly as the services are designed. The FAQ explains that apps which rely on Play for background notifications do so by receiving events through Google servers. The design choice is about privilege, not about whether Google sees the traffic you choose to send it.

The practical pattern the usage guide suggests is to start without Google Play, and if some apps need it, install it in a separate user or work profile so only those apps can use it.

Banking apps and attestation

The usage guide explains why some banking apps fail: many use Google's integrity checks, which require a Google certified OS. GrapheneOS is not certified by Google and does not try to spoof the result. The project's attestation compatibility guide shows app developers how to use Android's hardware key attestation directly and accept GrapheneOS by its verified boot key, which the project argues gives higher assurance than a pass or fail service.

How the install is secured

Two official installers

The FAQ says there are two supported installation methods: a WebUSB based web installer, recommended for most users, and a command line guide. The web installer runs in a Chromium based browser with WebUSB support, including from another Android phone. The FAQ says the CLI route lets you install without trusting the project's server infrastructure, provided you verify signatures yourself.

Both follow the same sequence:

1. Enable OEM unlocking in the stock OS (Developer options). On some models this needs internet access so the stock OS can check carrier status.
2. Boot into the bootloader and run fastboot flashing unlock, which wipes the device.
3. Download and verify the factory images.
4. Flash them; the script flashes firmware first, reboots to the bootloader and then flashes the OS.
5. Run fastboot flashing lock, which also wipes the device.
6. Boot, and on the final setup screen leave the "disable OEM unlocking" toggle checked.

Verifying the factory images

The CLI guide uses SSH signatures. You fetch the allowed_signers file and verify the zip with ssh-keygen -Y verify. The guide publishes the expected success line, which names the ED25519 key fingerprint SHA256:AhgHif0mei+9aNyKLfMZBh2yptHdw/aN7Tlh/j2eFwM. It also says the same key is published on other official accounts, and that any replacement key will be signed with the current one.

Why relocking matters

The CLI guide says locking the bootloader "enables full verified boot" and prevents using fastboot to flash, format or erase partitions. With the bootloader locked, verified boot detects modification of any OS partition and refuses to read modified data. Android's verified boot flow documentation defines the states the bootloader passes to Android in androidboot.verifiedbootstate: green when the device is locked and no user settable root of trust is used, yellow when it is locked and a user settable root of trust is used, and orange when it is unlocked. The same page says an unlocked device shows an orange warning screen on every boot. A correctly installed GrapheneOS device shows the yellow notice at every boot, because it uses its own key. That is expected, not a warning about tampering.

The CLI guide adds a subtle but important property: the verified boot key in the secure element can only be changed while the device is unlocked, and unlocking wipes the secure element just as a factory reset does. The verified boot key is also an input to deriving the disk encryption keys. So an attacker cannot swap the OS key and keep your data.

The FAQ is just as clear on the opposite case. If GrapheneOS shows a message that the bootloader is not locked, the installation was not finished, and the project does not support running with an unlocked bootloader.

The verified boot key hash

On Pixel 6 and later, the yellow boot screen shows the full SHA-256 hash of the verified boot public key. The CLI guide publishes the expected value for every supported device. A few examples:

Always compare against the install guide itself rather than a copy, including this one. Fourth and fifth generation Pixels showed only the first 32 bits, which is why that check does not apply to them.

Hardware attestation with Auditor

The Auditor app, described on the attestation.app about page and in the install guide, uses Android's hardware key attestation to verify that the hardware, firmware and OS are genuine. Because a compromised device cannot be trusted to report on itself, results show on a second Android device running Auditor, which scans a QR code. The first pairing chains trust to an Android attestation root and then pins a hardware backed key, so later checks detect a device that has been replaced or reflashed. An optional remote service can run scheduled checks and send email alerts. The install guide is open about the limit: the very first verification could be fooled by a leaked attestation key or by proxying to another device of the same model.

Comparison: stock Android, GrapheneOS and other de-Googled builds

The third column describes a category, community AOSP based builds aimed at removing Google services and supporting many phones. They vary a lot, so treat it as a list of questions to check for any specific build, not a verdict.

The honest summary: stock Pixel software already has strong verified boot and fast patches, and GrapheneOS keeps both while adding exploit hardening and much finer privacy controls. Builds that target many devices trade those properties for reach, and some cannot offer them at all on hardware without relockable bootloaders or continued firmware support.

Walkthrough: check support, verify a release and audit permissions

This walkthrough assumes a Linux or macOS computer with Android platform tools (adb and fastboot) and OpenSSH. Commands that change the device are marked.

Step 1: identify the device and its support window

On the phone, open Settings, About phone and note the model. From a computer with USB debugging temporarily enabled:

# Model and codename
adb shell getprop ro.product.model
adb shell getprop ro.product.device

# Installed GrapheneOS build and Android security patch level
adb shell getprop ro.build.version.incremental
adb shell getprop ro.build.version.security_patch

Look up the codename in the FAQ's supported devices list and its minimum support end date in the table above or on Google's Pixel update page. If the date is within the next six months, plan the replacement now. Turn USB debugging off again when you are done.

Step 2: confirm what the current release is

The releases page lists the Stable, Beta and Alpha versions for every device. You can also read the update channel metadata the updater uses:

# Replace oriole with your codename
curl -s https://releases.grapheneos.org/oriole-stable

The first field is the current Stable build number. Compare it to ro.build.version.incremental. If you are more than a release or two behind, check that System Updater is enabled and that its permitted networks setting is not blocking updates.

Step 3: verify a factory image or full update package before using it

mkdir graphene-verify && cd graphene-verify
curl -O https://releases.grapheneos.org/allowed_signers
cat allowed_signers
# Expected: contact@grapheneos.org ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIUg/m5CoP83b0rfSCzYSVA4cw4ir49io5GPoxbgxdJE

DEVICE=oriole
VERSION=2026102100
curl -O https://releases.grapheneos.org/$DEVICE-install-$VERSION.zip
curl -O https://releases.grapheneos.org/$DEVICE-install-$VERSION.zip.sig

ssh-keygen -Y verify -f allowed_signers -I contact@grapheneos.org \
  -n "factory images" -s $DEVICE-install-$VERSION.zip.sig < $DEVICE-install-$VERSION.zip

The last command must print Good "factory images" signature for contact@grapheneos.org with ED25519 key SHA256:AhgHif0mei+9aNyKLfMZBh2yptHdw/aN7Tlh/j2eFwM. Cross check the allowed_signers key against at least one of the other official places the install guide lists, from a different network if you can.

Step 4: only if you are installing, unlock, flash and relock

Warning: these commands erase everything on the phone. Back up first. Before each block, confirm that exactly one device is attached and that it is the one you mean to wipe:

# Device check: must list exactly one serial, and it must be the target phone
fastboot devices
fastboot getvar product

If the serial or product is not what you expect, stop. Then:

# DESTRUCTIVE: wipes the device
fastboot flashing unlock

# DESTRUCTIVE: replaces the OS; run from the extracted factory image folder
bsdtar xvf $DEVICE-install-$VERSION.zip     # use tar xvf on macOS
cd $DEVICE-install-$VERSION
bash flash-all.sh

# Re-run the device check above, then relock. DESTRUCTIVE: wipes again
fastboot devices
fastboot flashing lock

Most people should use the web installer instead, which runs the same steps with prompts. Do not skip the relock.

Step 5: check the verified boot key hash and boot state

At the next boot, the yellow notice shows a 64 character hash. Compare it character by character with your device's value on the install guide. You can also read the boot state from Android. The bootloader passes it as androidboot.verifiedbootstate, and AOSP's bootconfig documentation notes that androidboot.* values are exposed as ro.boot.* properties:

adb shell getprop ro.boot.verifiedbootstate   # expect: yellow

orange means the bootloader is still unlocked and the install is incomplete. Then set up Auditor pairing from a second Android device for an independent check.

Step 6: audit per app network and sensor access

Open Settings, Apps, then each app's Permissions screen; GrapheneOS shows Network and Sensors alongside the standard permissions. To get a quick inventory from a computer:

# List user installed apps
adb shell pm list packages -3

# For one app, show whether the INTERNET permission is currently granted
adb shell dumpsys package com.example.app | grep -A1 "android.permission.INTERNET"

# Show every runtime permission state for that app
adb shell dumpsys package com.example.app | grep "granted="

A sensible routine: deny Network to any app that works offline (keyboards, calculators, galleries, document viewers), set Sensors to default off for new user apps, use Storage Scopes for apps that ask for broad file access, and use Contact Scopes for messaging apps you do not want reading your whole address book. If you use sandboxed Google Play, check that it is installed only in the profile that needs it.

Step 7: confirm the update settings

In Settings, System, System update, keep the Stable channel unless you are testing and check the permitted networks. Under Settings, Security and privacy, Exploit protection, confirm the USB-C port mode and auto reboot timer suit you.

Common mistakes

• Buying an unsupported or nearly expired device. A phone not on the FAQ list cannot run official GrapheneOS, and a Pixel 6 or 6 Pro bought today has already reached Google's minimum support end. Buy a Pixel 8 or newer.
• Buying a carrier locked Pixel. The bootloader may never unlock. Buy an unlocked model.
• Leaving the bootloader unlocked. Without fastboot flashing lock, verified boot is not fully enforced and anyone with physical access can flash a modified OS. The project treats this as an incomplete install.
• Panicking at the yellow boot notice. Yellow is expected for an OS signed with your own trusted key. Check the hash; an orange notice is the one that means unlocked.
• Skipping signature verification on the CLI route. The CLI method only removes trust in the project's servers if you verify the factory images yourself.
• Using an update package to install. Full update packages are for updating an existing install, not for the first install.
• Assuming sandboxed Play means nothing goes to Google. It removes privileges, not data flows you opt into. Account sign in, location accuracy and push notifications still talk to Google.
• Installing Google Play in the Owner profile without thinking. That makes it available to every app there. A separate profile limits it to the apps that need it.
• Staying on extended support releases. They are a bridge, not a plan, because firmware and driver patches have stopped.
• Following third party install guides. The FAQ warns they are often out of date.

FAQ

What is the latest version of GrapheneOS?

As of 24 October 2026, the latest release is 2026102100, published on 21 October 2026 and based on Android 17. It was on the Stable, Beta and Alpha channels for all 21 supported devices. Check the releases page for anything newer.

Which phones does GrapheneOS support?

Pixel 6, 6 Pro and 6a; Pixel 7, 7 Pro and 7a; Pixel Tablet and Pixel Fold; Pixel 8, 8 Pro and 8a; Pixel 9, 9 Pro, 9 Pro XL, 9 Pro Fold and 9a; and Pixel 10, 10 Pro, 10 Pro XL, 10 Pro Fold and 10a. The project recommends Pixel 8 or newer.

Was GrapheneOS called CopperheadOS?

Yes. The project's history page says GrapheneOS was founded in late 2014, was known as CopperheadOS while a company sponsored it from late 2015, and was renamed AndroidHardening and then GrapheneOS after the two split in 2018. The first GrapheneOS branded releases followed in 2019.

How long will GrapheneOS support my Pixel?

Until shortly after Google's minimum support end date for that model. Pixel 8 and later have 7 years from launch; the Pixel 6 and 7 families, Pixel Fold and Pixel Tablet have 5. The FAQ publishes the date for each device.

Is GrapheneOS more secure than stock Android?

It keeps the stock Pixel security model, including verified boot, the secure element and monthly patches, and adds exploit mitigations and privacy controls on top. The features page lists every addition.

Does GrapheneOS work with Google Play and banking apps?

Most apps work with sandboxed Google Play installed in the same profile. Apps that insist on Google certified device integrity will not, because GrapheneOS is not Google certified and does not spoof the check. Some banks accept GrapheneOS through direct hardware attestation.

How often does GrapheneOS update?

Several times a month. October 2026 alone had releases on the 2nd, 6th, 16th and 21st. The phone checks about every six hours and installs in the background.

Does GrapheneOS need an unlocked bootloader?

Only during installation. You unlock to flash it, then relock. A relocked GrapheneOS phone shows a yellow boot notice with its key hash, and the project does not support running with the bootloader unlocked.

What are GrapheneOS security preview releases?

Optional builds, numbered one above the regular release, that include Android security patches from upcoming bulletins before they are public. You opt in through System Updater. They have been offered since late 2025.

Can I go back to the stock Pixel OS?

Yes. The CLI guide says to unlock the bootloader, run fastboot erase avb_custom_key to remove the GrapheneOS verified boot key, then flash Google's factory images and relock. All of these steps wipe the device.

Where Safeguard fits, honestly

Safeguard does not install, manage or scan phone operating systems, and it has no GrapheneOS specific features. The Safeguard Android app is listed on our download page, and it is an ordinary Android app; this post makes no claim about how it behaves under GrapheneOS's Network, Sensors or Google Play controls beyond what applies to any app.

Where the topic does connect is the habit GrapheneOS models: treat every component as something with an upstream, a version, a support window and a patch stream. Its changelog is essentially a public software bill of materials in motion: Linux GKI LTS branches, Chromium in Vanadium, hardened_malloc, Seedvault, timezone data, Pixel firmware. If you build Android apps or backend services, your own dependency tree deserves the same attention, and that is the work Safeguard does.

A phone running GrapheneOS still talks to apps and services that you or your vendors build, and those ship open source libraries with their own vulnerabilities and release schedules. GrapheneOS shows how much effort it takes to keep upstream components current; the steps below are how teams keep the open source in their own code and images just as current, with the caveat that fork and patch is early access.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Android session with the Safeguard mobile app: you send work to a computer running the Safeguard CLI, then approve the command on the phone with Allow once, Allow for turn or Deny. It is an ordinary Android app, so on any Android phone you decide what permissions it gets; the point here is approving each command from your pocket while the work runs on your development machine.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the dependencies of an Android app's backend or tooling, where an old library version is just as much a liability as an old kernel.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. It suits the same instinct as verifying a GrapheneOS factory image yourself: the work happens on hardware you control, and you approve the connection explicitly.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• GrapheneOS releases and changelog
• GrapheneOS FAQ
• GrapheneOS features overview
• GrapheneOS usage guide
• GrapheneOS history
• GrapheneOS install overview
• GrapheneOS web installer
• GrapheneOS CLI install guide
• GrapheneOS attestation compatibility guide
• GrapheneOS build guide
• Auditor: about
• GrapheneOS on GitHub
• hardened_malloc repository and README
• Android Security Bulletins
• Android Security Bulletin, October 2026
• Android verified boot flow
• Android verified boot device state
• Android key and ID attestation
• Implementing bootconfig (androidboot to ro.boot properties)
• Google Pixel update schedule

Last reviewed: 24 October 2026. GrapheneOS ships several releases a month; check the linked pages for the latest versions and device dates.