"Migrating to GrapheneOS: the data transfer, attestation, and what breaks"


Migrating to GrapheneOS: the data transfer, attestation, and what breaks

Most people research GrapheneOS for weeks and still get surprised on day one. Not by the OS — it's a Pixel running AOSP with hardened allocations and per-app sandboxing — but by the migration. Your old phone is not a moving truck. It is a directory of files plus a set of app private stores, and only the first half of that crosses over cleanly.

This is the part of the switch nobody writes a landing page about, so here it is straight: what transfers, what doesn't, why GrapheneOS is Pixel-only, and which apps you should expect to fight with in Australia.

Why Pixels only, and why that's a feature

GrapheneOS runs exclusively on Pixel hardware because Pixel devices support a full verified boot chain with re-lockable bootloaders. Verified boot means the bootloader checks the OS image against a key burned into hardware at every boot, and it stays on when you re-lock the bootloader after installing GrapheneOS. Other phones either can't re-lock (most Samsungs with custom ROMs), or re-lock into a vendor-signed image that won't verify third-party OSes. MediaTek and Qualcomm SoCs outside the Pixel line generally expose weaker or absent attestation, so a compromised boot chain looks identical to a clean one.

Attestation is the flip side: the hardware can cryptographically prove to an app or server which OS and boot state it's running. There are two tiers. Hardware attestation is signed by the device's own embedded key rooted in a Google-fused certificate chain — it's what Play Integrity picks up and what banking apps actually check. Software attestation is a weaker, emulator-signable variant that Google restricted in Play Integrity API policy updates between 2023 and 2025, which is exactly the window in which alternate-OS users started seeing banks refuse to open.

If you want the details straight from the project, the hardware attestation reference on grapheneos.org spells out the two profiles and why some apps can't be satisfied by design. The short version: GrapheneOS passes hardware attestation because Pixel hardware supports it; it cannot pass checks that demand a specific vendor OS signature, and no ROM project can fix that without Google's keys.

Buying flashed vs flashing yourself

You can do either. The web installer is genuinely good — the official install walkthrough runs from Chrome or a Chromium browser on your desktop, drives fastboot from the browser's WebUSB, and takes most people 20–40 minutes on a Pixel 8a or 9a. Requirements are unglamorous: unlock the bootloader (wipes the phone), flash, lock the bootloader again, then verify the attestation screen before restoring data.

Buying pre-flashed gets you the same OS with the re-locked bootloader and a verified boot state, plus a day of your weekend back. If you buy a flashed unit, do one thing regardless of seller: check Settings → About phone → build number against the official release channel, and run the Auditor app against your own device. Trust, verify — a flashed phone that ships with a stale or tampered build is a problem you can catch in five minutes.

One honest limitation of both paths: the bootloader unlock allowance. Pixels sold through some Australian carriers historically shipped with carrier restrictions; buy the retail-unlocked variant and this is a non-issue.

The data transfer: what actually moves

GrapheneOS supports Android's standard restore path — it presents itself as a valid restore target during setup, and Migrate (the built-in migration tool that succeeds Android's own Data Transfer) can pull from an old Android phone or from a cloud backup. What it pulls, in practice:

The realistic summary: personal data moves well, app-level state moves poorly, and anything the app vendor chose to keep server-side or opaque moves not at all. iPhone users have it worse — the Android migration tooling doesn't ingest iOS backups directly; you move contacts, calendar, and photos via Google account sync or a cable export, and re-authenticate everything else.

Do the migration before you wipe your old phone, and keep the old phone powered off — not reset — for two weeks. That last habit has saved more people than any guide.

Sandboxed Google Play — what it is

GrapheneOS ships Sandboxed Google Play — the Play Services components compiled as ordinary, unprivileged apps, running inside app sandboxes with no special access. You install it optionally from the app repository, per-app grants decide what it can reach, and it works as a compatibility shim: push notifications arrive, Play Integrity answers, apps that require GMS registration run. It is not degoogling in the strict sense — Google still sees traffic from apps that talk to Google — but Google doesn't get system-level reach over the device. It's off by default; nothing phones home until you install it.

Two consequences worth knowing: apps that depend on Play Services for notifications need it installed and granted notification access, and the SafetyNet/Play Integrity pass comes from the hardware attestation profile, not from sandboxing — sandboxed Play is what lets the app ask for attestation in the first place.

What breaks in Australia — the honest list

Banking apps: mostly fine now, with specific holdouts. As of 2026, the big four (CBA, Westpac, NAB, ANZ) open and function on GrapheneOS with Sandboxed Play and hardware attestation. The pattern of failures has moved downmarket: some smaller banks and credit unions (Members Equity-type, a few regional mutuals) implement Play Integrity checks that reject non-Play-certified devices regardless of attestation profile. Expect roughly 1-in-10 to 1-in-15 of your installed apps to have a device-integrity gate; banks are the most common because they have real fraud reasons. Check the community-maintained banking compatibility data before you flash — GrapheneOS's usage page and its linked forum threads track per-app status, and it changes monthly in both directions.

myGov and government apps: the bad surprise. The myGov app and its identity gate (myGovID, now myID) are the problem children. myID performs strong device attestation and, as of the 2024–2025 updates, refuses non-Play-certified devices outright for new enrolments. Existing enrolments sometimes survive a migration; new setups on GrapheneOS frequently don't. Service NSW, Services Australia's web portals, and the ATO's separate app are more forgiving — the ATO app works, myID often doesn't. Practical workaround people use: keep myID enrolment on a second device (a cheap stock Android or an iPad) and use myGov's web login on the GrapheneOS phone. It's clunky and it's real; we'd rather tell you than let you find out during tax season.

Tap-and-pay: broken by design. Google Wallet's tap-to-pay needs Google Play Services to have privileged NFC access, which it doesn't have when sandboxed. There is no GrapheneOS tap-and-pay path today. Contactless cards in your physical wallet remain the workaround; some people run bank-issued tags or watches. This is a dealbreaker for some buyers and a shrug for others — know which you are.

Push notifications: fine with a catch. With Sandboxed Play granted the right permissions, FCM push works for WhatsApp, Signal, most news and delivery apps. Apps that batch their own background fetches work without any of it. The catch: sandboxed Play needs to be running for FCM-delivered pushes, and battery tuning that's too aggressive will delay them. Defaults are sensible; leave them alone until something actually misbehaves.

Smaller breakage: some VOIP apps, a couple of streaming apps with device checks, and anything using Nearby Share exclusively (Quick Share in sandboxed form covers most of it). Google Pay wallet cards other than tap-to-pay — loyalty, gift cards — are unaffected. In-app browser flows sometimes default to an external browser; that's intentional, GrapheneOS's Storage Scopes and per-app browser isolation make cross-app tracking harder than you're used to, and you'll notice it as minor friction you can configure.

Backup strategy on the new phone

GrapheneOS uses Android's standard Backup service with server-side encryption, so your seed backup can be turned on from Settings → System → Backup, encrypted with a seed you keep offline. Seed-based backup covers app data for opt-in apps, system settings, and SMS — it is not a full-disk image. For photos and documents, an Android-adjacent cloud (Nextcloud, or Syncthing to a home server) works well. Do a test restore onto a spare device or emulator before you rely on it; the test takes 20 minutes and is the difference between a backup and a hope.

The position we take

GrapheneOS on a Pixel 8a (A$829) or a Pixel 9a is the most defensible degoogled Android you can buy in Australia — verified boot, per-app network and sensor grants, sandboxed Play as an opt-in shim, and a 7-year security window on the 8-series. The trade is explicit: you give up tap-and-pay, and you accept that a handful of attestation-gated apps — most likely myID, maybe your bank — need a second device or a workaround. For everyone else, the migration is a weekend project with a cable, a checklist, and two weeks of keeping the old phone around.

If you'd rather have the install done, attestation verified, and the restore completed before it reaches you, that's what our flashed Pixel 9a and Pixel 8a listings are for — same OS, re-locked bootloader, and you can still run the Auditor check yourself the day it arrives.


← All posts