GrapheneOS Setup Guide: Install, Profiles, Google Play

At a glance

Profiles separate app state, not the phone identity. GrapheneOS profiles separate app data and profile state; they do not create separate devices, SIMs, carrier records, Wi-Fi histories, or public IP addresses.

Sources

1. 1. grapheneos.org · features
2. 2. grapheneos.org · usage
3. 3. grapheneos.org · usage
4. 4. grapheneos.org · usage
5. 5. grapheneos.org · faq

Data behind this diagram

GrapheneOS profile boundary rules

Control	Required state	Scope
Network	Deny when unused	Per app
Sensors	Deny or motionless	Per app
Storage Scopes	Selected files and directories only	Per app
Contact Scopes	Selected fields, contacts, or groups	Per app
VPN	Always-on and block connections without VPN where required	Per profile
Private DNS	Global setting; review interaction with secondary-profile VPNs	Device-wide

Scroll →

GrapheneOS hardens Android without removing the Android app model. It adds exploit protections and privacy controls while keeping optional access to Google Play for apps that depend on it. It does not hide who owns the SIM, erase account history, or make an unsafe app trustworthy.

The project supports a defined set of Pixel devices. That choice is part of its security model. GrapheneOS requires hardware-backed security, verified boot with rollback protection, timely firmware support, and the other device features listed in its official device requirements.

GrapheneOS or /e/OS: which is safer?

For resistance to device exploitation on a Pixel 8a, GrapheneOS is the better-supported choice in the documentation reviewed on 21 September 2026. It supports a locked bootloader, hardware memory tagging and additional exploit mitigations. The /e/OS Pixel 8a community build is listed as not lockable. That is not a verdict on every /e/OS phone: the official Fairphone 5 build supports relocking. Reducing advertising trackers and resisting an operating-system compromise are different goals.

In the comparison below, A15 and A16 mean Android 15 and 16. AOSP is the Android Open Source Project; SPL means security patch level. An Android patch label does not by itself establish the version of every vendor firmware component.

Updates: Android patches are not the whole firmware

The /e/OS security tracker dates the 4.2 release to 18 August 2026 and lists August AOSP patches for A14, A15 and A16. Its Fairphone 5 A15 vendor entry is FP5.VT2R.C.095.20260423, distinct from the installer's August security-patch label. That identifier is not proof that every firmware vulnerability through August is fixed. Pixel 8a is absent from the reviewed vendor table, so its shipped firmware patch coverage remains unverified here.

The /e/OS release policy specifies monthly official and community builds. The two download indexes above still listed August builds at this check; a monthly target is not proof of September delivery. GrapheneOS listed September 10, 17 and 19 releases, with a modem-firmware backport in 2026091700. Stable and security-preview releases are separate; preview-only fixes are not counted as installed stable protections here.

Hardware support is another clock. GrapheneOS lists the Pixel 8a OEM minimum support end as May 2031. Fairphone's support policy promises at least eight years of security updates for Fairphone 5, with a ten-year goal, and a switch from monthly to bi-monthly security updates from mid-2026. That vendor promise is not a guarantee that every /e/OS release immediately contains each vendor update. Neither project can repair closed firmware merely by keeping an Android build available.

Verified boot, isolation and exploit mitigations

Verified boot checks that the installed system matches the trusted signing key. GrapheneOS requires relocking during installation. /e/OS's own relocking documentation warns against relocking community builds and directs users to the exact device page. Its Fairphone 5 guide also warns that an older security patch can conflict with anti-rollback protection and brick the phone. Do not transfer Pixel or Fairphone instructions to another model.

GrapheneOS documents hardened memory allocation and exploit protections; its Pixel 8-and-later guidance describes hardware memory tagging for the base OS and compatible apps. Profiles separate app data and accounts, and optional Google Play runs without special OS privileges inside the app sandbox. Those are specific boundaries, not immunity to exploitation.

/e/OS ships preconfigured microG for Google-dependent app compatibility, rather than GrapheneOS's optional sandboxed Google Play arrangement. Its Advanced Privacy documentation describes DNS tracker blocking, location substitution and optional Tor routing, but also says app-level encrypted DNS can bypass its tracker blocker and work profiles can disrupt its location controls. These tracking controls do not establish equivalent exploit mitigations. No comparative exploit or isolation test was performed for these builds.

Does /e/OS send speech or account data to the cloud?

The current Voice to Text documentation, retrieved 21 September 2026, describes Murena Voice to Text (offline): local recognition after a one-time model download, without an account or subscription. It explicitly contrasts this with the earlier Premium online feature, which sent speech through a proxy to a third-party transcription service. Device coverage is still expanding. The June 2025 controversy is not evidence that a current installation sends audio to OpenAI.

The documentation does not establish which keyboard package is installed on each of the builds above. Cunicula did not install either OS, inspect those packages or capture speech traffic. Check the installed keyboard name and version before treating dictation as offline. Even local recognition inserts text into the receiving app; that app may sync or transmit it.

Optional cloud use remains a separate decision. /e/OS's Account Manager links mail, contacts, calendars and tasks to the selected account provider. Murena's policy describes account and purchase collection, third-party payment processing, and hCaptcha processing IP addresses and behavior during account creation. A replacement cloud account does not erase account metadata. The same distinction applies to Google or other cloud accounts added to GrapheneOS.

Choose the device, supported build and actual account setup, not the “de-Googled” label alone. For an existing Fairphone 5, check official-build status, firmware evidence and relocking prerequisites rather than applying the Pixel 8a conclusion. For account migration use the de-Google guide; for carrier and SIM exposure use the phone-stack guide. Neither subject is solved by changing the OS.

Quick setup path

1. Buy a supported Pixel with an unlockable bootloader.
2. Update the stock system, then use the official GrapheneOS web installer.
3. Lock the bootloader and disable OEM unlocking after installation.
4. Verify the installed system with the boot key and Auditor.
5. Choose which user profiles will hold daily, Google-dependent, and sensitive apps.
6. Install sandboxed Google Play only in profiles that need it.
7. Review Network, Sensors, Storage Scopes, Contact Scopes, and notifications for every important app.
8. Configure either a VPN or Private DNS with the profile limits understood.
9. Set the passcode, auto reboot, USB-C mode, and lock-screen notifications.
10. Test updates, calls, messages, banking apps, recovery material, and linked devices before relying on the phone.

1. Buy a supported, unlockable device

Check the live support list before spending money. The exact list changes as devices reach end of life and new models pass the project's requirements. Prefer a current-generation device with several years of full firmware and operating-system support remaining.

A carrier-locked bootloader can prevent installation. This is most common with devices sold through some US carriers. An unlocked retail device is the safer purchase. Do not assume that a network-unlocked phone also has an unlockable bootloader. Confirm the model and seller policy.

Before installing, update the stock operating system. The official installer says this gives the phone current firmware for the early flashing process. Back up anything already on the phone because unlocking and later locking the bootloader each erase the device.

2. Use the official installer

The project recommends its WebUSB installer for most users. Read the prerequisites before connecting the phone. Use a supported browser, avoid private browsing mode, connect with a reliable cable, and do not run the installer through a virtual machine.

Follow the installer in order: enable OEM unlocking, enter the bootloader, unlock it, download and flash the release, then lock it again. Locking the bootloader enables full verified boot. It also blocks fastboot from flashing, formatting, or erasing partitions while the phone is locked.

During first setup, leave the option to disable OEM unlocking enabled. Use only images and instructions from grapheneos.org. A third-party image can change the operating system before you sign in.

3. Verify the installation

Supported Pixels display a verified-boot notice when loading an alternate operating system. Newer generations show the full hash of the installed verified-boot public key. Compare it with the value for the exact model on the official installer page.

For hardware-backed verification, use the bundled Auditor app and a second Android device. In local verification, one device shows a challenge QR code and the other returns the attestation. The Auditor tutorial explains the current pairing flow and what a successful result contains.

Verified boot runs on every boot without a manual check. Auditor adds an independent way to inspect the device, firmware, operating system, patch level, and verified state. If the bootloader is still unlocked or the expected key does not match, finish or repeat the official installation process before adding accounts.

4. Choose a profile layout

Android user profiles separate app data, accounts, encryption keys, VPN configurations, and most profile state. GrapheneOS extends profile controls and documents them in its profile feature guide.

• Owner profile. Keep it small if you want it mainly for system administration. The owner controls updates, profile creation, and some global settings.
• Daily profile. Use it for ordinary calls, messages, maps, and browser activity. Ending its session returns its encryption keys to rest without rebooting the whole phone.
• Google-dependent profile. Put the Play Store, Play services, banking, transport, and other dependent apps together only if that separation helps your routine.
• Focused communications profile. Keep a smaller set of messengers and their contacts here when you need a separate local app and account boundary.

Profiles are not separate phones or separate mobile identities. The same hardware, SIM, carrier connection, Wi-Fi networks, and public IP address can connect activity. Reused accounts, contacts, phone numbers, and payment methods create direct links. Use the messaging comparison to choose the messenger inside a profile.

5. Install apps and optional Google Play

The built-in GrapheneOS App Store distributes the project's own apps and sandboxed Google Play packages. The official app repository description explains its current scope. Install ordinary apps from a source that preserves Android package-signature continuity, such as the Play Store or the developer's signed release channel.

To add Google Play, open the GrapheneOS App Store in the selected profile and install Google Play services. The current package installs the interdependent Play services and Play Store components. Signing into a Google account is optional unless an app or Play Store function requires it.

Only apps in the same profile can use that profile's sandboxed Google Play. The Google apps run in the standard app sandbox and have no special operating-system privileges. They still receive data you give them through an account, permission, purchase, location request, or app interaction.

Banking and incompatible apps

1. Install sandboxed Google Play in the same profile as the dependent app.
2. Update GrapheneOS, Play services, the Play Store, and the app before changing security settings.
3. Grant only the permissions needed for the feature being tested.
4. If the app aborts, try its per-app Exploit protection compatibility mode. This reduces mitigations for that app only.
5. Remove compatibility mode if the app works after a later update.

The project keeps current notes under banking app compatibility and bugs uncovered by security features. App developers can still block alternate operating systems through their own integrity policy.

6. Restrict app access

GrapheneOS adds a per-app Network permission. Deny it to an app that has no reason to communicate. An app without network access can still pass data to another cooperating app that has network access, so this control is not a complete firewall between hostile apps.

Review camera, microphone, contacts, notifications, and location access. Prefer one-time or foreground-only grants when they fit the task. Remove permissions that an app no longer needs.

Storage Scopes lets an app behave as though storage permission was granted while initially exposing only files it created. You can then add selected files or directories. Contact Scopes can expose selected contact fields, individual contacts, or groups instead of the full address book.

The Sensors permission can present an app with motion sensors that do not move. This narrows one collection path, but it does not block every device fingerprint or behavior signal. A granted permission, account login, website session, or file shared with the app remains a separate path.

7. Configure the network deliberately

A SIM still identifies the subscription to the carrier and places the device on the cellular network. GrapheneOS does not turn cellular service into an anonymous connection. Wi-Fi access points, accounts, browser sessions, and destination services create separate records.

VPN configurations are per profile. Set a VPN as always-on and enable Block connections without VPN if traffic must stop when the tunnel is down. The GrapheneOS FAQ currently recommends the official Mullvad or WireGuard apps and explains the platform's VPN behavior.

Private DNS is global rather than per profile and takes precedence over VPN-provided DNS. GrapheneOS recommends disabling custom Private DNS when a VPN is used in a secondary profile because the interaction is not cleanly separated. The private DNS guide explains resolver exposure. The Mullvad setup guide covers tunnel setup and leak checks.

Vanadium is the included browser and WebView provider. A hardened browser does not separate logged-in identities. Keep account sessions and profile layout consistent with the boundary you intended.

8. Reduce locked-device exposure

Use a long passcode rather than a short PIN when physical access is a material risk. Hide notification content on the lock screen. Review paired computers and app sessions because data already synchronized to another device is outside the phone's lock boundary.

GrapheneOS documents an 18-hour default for auto reboot. A reboot returns credential-protected data to its at-rest state until the passcode is entered again. Choose a shorter interval only if it fits how the phone must remain available.

The USB-C control is under Settings, Security, Exploit protection. Its default charging-only-when-locked mode blocks new USB data connections after the phone is locked. Other modes can disable USB data more aggressively or leave it available. The usage guide describes each mode.

GrapheneOS also provides an optional duress PIN and password. Entering either in a device credential prompt irreversibly wipes the device and installed eSIMs. This is separate from the ordinary unlock credential and should not be configured with a value that can be confused with it.

For a closer look at extraction from seized devices, read what phone extraction tools target.

9. Keep the system current

The update client checks for updates in the background, installs them to the inactive system slot, and asks for a reboot when the update is ready. Apply the reboot promptly. The official releases page lists current releases and explains the signed update packages.

Replace the device before its full security support ends. Extended releases can provide transition time, but they cannot restore missing vendor firmware support. Remove apps you no longer use so there are fewer permissions, accounts, background services, and update dependencies to track.

10. Check the finished setup

• The phone appears on the current supported-device list.
• The bootloader is locked and OEM unlocking is disabled.
• The verified boot key or Auditor result matches the official installation.
• Each profile has a clear purpose and can be ended without breaking an essential workflow.
• Sandboxed Google Play exists only in the profiles that need it.
• Important apps have reviewed Network, Sensors, contact, storage, location, microphone, camera, and notification access.
• VPN and Private DNS behavior has been tested in every profile that uses the network.
• The phone has a strong passcode, hidden lock-screen content, a chosen auto-reboot interval, and the intended USB-C mode.
• Calls, messages, emergency access, banking, transport, updates, and account recovery have been tested before the old phone is erased.

What GrapheneOS does not solve

• SIM registration and carrier records. The operating system cannot stop a carrier from recording subscriber and network data.
• Account linkage. Reusing the same email, phone number, payment method, or cloud account preserves those links.
• App-side collection. An app can collect information you enter or grant it permission to read.
• Website tracking. Browser sessions, logins, IP addresses, and fingerprints remain separate problems.
• Physical access. Device state, passcode strength, installed version, linked sessions, and current exploits still matter.

Network, Sensors, Storage Scopes, Contact Scopes, profiles, sandboxed Google Play, auto reboot, and USB-C controls reduce specific data paths. They do not justify a claim that GrapheneOS stops all tracking or extraction. This is the canonical page for those controls. The former separate behavioral-tracking page redirects here.

Official GrapheneOS links

• Supported devices and hardware requirements
• WebUSB installation guide
• Auditor verification tutorial
• User profiles
• Sandboxed Google Play
• Storage Scopes and storage access
• Contact Scopes
• Per-app compatibility mode
• VPN and Private DNS behavior
• Auto reboot
• Duress PIN and password
• Current releases
• Source-code guide

Reviewed 21 September 2026. Comparison sources were retrieved on that date. Device support and feature behavior can change; project documentation describes intended behavior, not an independent test of an installed phone.