How to De-Google an Android Phone Safely (and Keep It Secure)

There are two safe ways to de-Google an Android phone. The low risk route keeps the stock OS, disables or removes Google apps for your user and swaps in other apps and stores. The deeper route installs a privacy-focused Android distribution, but only on a device its project officially supports and only if you can relock the bootloader.

That second condition is the one most guides skip. An unlocked bootloader turns off the check that stops a tampered operating system from booting. This guide covers both routes, what each distribution's own documentation says about verified boot, relocking and updates, and what you give up: Play Integrity checks, some banking apps and Find Hub. We do not give flashing steps; every project below has an official installer and guide, and those are the only ones to follow.

Key takeaways

• Start with the lowest risk change that meets your goal. Disabling Google apps and signing out of the Google Account removes most data flows without touching the bootloader.
• If you install another OS, relock the bootloader. GrapheneOS calls an unlocked install "incomplete"; CalyxOS says it "is meant to be run with a locked bootloader after installation".
• LineageOS warns that relocking "can result in actual unusable devices" on most phones, and /e/OS marks each device as lockable or not lockable. Check before you buy or flash.
• Security updates come in layers. A distribution can ship the monthly Android patches, but firmware and vendor code still depend on the phone maker. When the maker stops, so do full updates.
• Expect breakage. Play Integrity's device verdict requires a locked bootloader running a certified manufacturer image on Android 13 and higher, so some banking, payment and streaming apps will refuse to run.
• Find Hub needs a Google Account. Without one you lose remote locate and erase, and on GrapheneOS you also lose Factory Reset Protection by design.
• Only download from each project's own site and use its official installer. GrapheneOS shows a verified boot key hash on every boot that you can compare against its published list.

What does "de-Googling" an Android phone actually mean?

Android itself is open source: the Android Open Source Project (AOSP) is the base every Android phone runs. "Google" on a phone usually means the layer on top: Google Play services, the Play Store, Google's apps and the Google Account. On a certified phone that layer is preinstalled with privileged access and acts as the backend for features like network location and push notifications.

Decide which goal you have. Fewer Google apps, or no Google Account, can be done on the phone you own. No privileged Google code at all needs a different operating system, and that is where the security trade-offs start.

Which approach fits your goal?

Here is a comparison of the main approaches by criteria, not a ranking. The right one depends on your phone, the apps you cannot give up, and how much setup risk you accept.

The rest of this guide explains where each line in that table comes from.

Option 1: de-Google the phone you already have

This route keeps your phone's verified boot chain, your maker's security updates and your warranty intact. It is the right first step for most people, and it is reversible.

Sign out, then decide what to keep

First decide whether to keep a Google Account on the device. Google's help page says that "If you've added a Google Account to your device, Find Hub is automatically turned on", storing encrypted recent locations with Google. Removing the account removes that, and also Play Store installs, which GrapheneOS's usage guide notes require "being signed into an account". Plan where app updates will come from before you sign out. An app that never updates is a bigger risk than an app that talks to Google.

Disable Google apps from Settings

Google's Play Help page "Delete, disable and manage unused apps on Android" covers both deleting apps you installed and disabling apps that came with the device. Disabling is the safer choice for preinstalled apps: the app stops running, disappears from your launcher, and can be turned back on from the same screen. The exact menu names vary between phone makers, so follow your maker's version of Settings, usually under Apps.

You cannot disable everything this way. Some components are marked as required by the maker, and the Disable button is greyed out. That is a hint that something else depends on them.

Go further with adb, carefully

The Android Debug Bridge (adb) reaches the package manager, pm, which can disable or remove packages for one user without root. The commands below come from Android's adb documentation; you need USB debugging on in Developer options.

First, confirm the phone is connected and authorised:

adb devices -l

List system packages, optionally filtered by text in the package name. The documentation describes -s as "Filter to only show system packages" and -d as disabled packages only:

adb shell pm list packages -s google
adb shell pm list packages -d

Disable a package for the main user. This is reversible:

adb shell pm disable-user --user 0 com.example.app

Turn it back on:

adb shell pm enable com.example.app

The documentation also describes pm uninstall, with -k to "Keep the data and cache directories" and --user to choose the user, noting that "By default, the package is removed for all users on the device." On a system app, the per user form removes it from your profile only:

adb shell pm uninstall -k --user 0 com.example.app

Prefer disable-user over uninstall. It has a documented reverse command, and if a package turns out to be load bearing you can recover without a factory reset.

What breaks when you disable Google Play services

On a stock phone Play services is the backend for many features. GrapheneOS's FAQ explains that many apps rely on "Firebase Cloud Messaging (FCM)" through Google's servers for background notifications; LineageOS's FAQ says "Push notifications require GApps or MicroG." Disabling it can also break Google sign in, Play geolocation and Find Hub. What it does not change is who signs your OS and sends your security updates, which is why this route is safer than replacing the OS.

Alternative app stores

If you stop using the Play Store, you need another trustworthy source of apps and updates. Android's signature model does a lot of the work here. As CalyxOS's security FAQ puts it, when an app updates, "the new app will only be accepted if verified to be from the same developer as the original version". The weak point is the first install, because Android "always accepts the identity of the developer when first installing a new app".

That makes the store's own integrity model the thing to check:

• F-Droid distributes free and open source apps. Its security model page describes signed repository metadata "generated on a separate machine (which is fully offline for f-droid.org...)", HTTPS only connections, SHA-256 verification of repository files from index-v2, and published source tarballs and build logs "for retroactive review". Download the client only from f-droid.org, which also links instructions to verify the download.
• Accrescent describes itself as "A novel Android app store focused on security, privacy, and usability" and is "Currently in alpha". Its listed features include app signing key pinning so "first-time app installs are verified so you don't have to TOFU", signed repository metadata, unattended updates on Android 12 and higher, and no account requirement. It runs on Android 10 and up.
• Play Store frontends install from the Play catalogue without the Play Store app. GrapheneOS's usage guide notes the official Play Store app "is also the most secure way to install and update apps from the Play Store", and CalyxOS's security FAQ lists the risks of the frontend it bundles.

F-Droid's homepage currently carries a warning that "Google is changing the way you install apps on your device." If you rely on installing apps outside Google Play, read our explainer on Android developer verification and what sideloaders should know, and our checklist for sideloading Android apps safely.

Option 2: install a privacy-focused Android distribution

Replacing the operating system gets you further from Google, and changes your phone's security model in ways that are easy to get wrong. Start with the mechanism that matters most.

Why the bootloader matters

The bootloader is the first code that runs when the phone powers on. /e/OS's documentation explains it simply: manufacturers ship devices locked, so "only firmware signed by a key the device trusts can boot". Verified boot is the check the bootloader performs on each stage of the operating system before running it. If you want the full mechanics, our post on Android verified boot and the chain of trust goes deeper.

To install a different OS you have to unlock the bootloader. Android's AOSP documentation describes the process: you enable "OEM unlocking" in Developer options, then send an unlock command from a computer, and the device should warn you and perform a factory reset "to prevent unauthorized data access". The suggested warning text in the AOSP docs reads: "Software integrity cannot be guaranteed with a custom OS".

/e/OS's bootloader page gives the clearest summary of what changes when the bootloader stays unlocked:

Source: /e/OS documentation, "Bootloader relocking".

The same page adds an important caveat that keeps this in proportion: "An unlocked bootloader is not a remote vulnerability by itself. It requires physical access to be exploited." What it changes is the outcome of a compromise. Someone who gets hold of the phone, or malware that gains a foothold, can install something that survives reboots.

Relocking with a custom key: green, yellow and orange

Relocking with a different OS works because some phones let you install your own verified boot key. The AOSP boot flow documentation defines three normal states that the bootloader reports to Android:

• green: locked, using the maker's built in key;
• yellow: locked, using a "user-settable root of trust", which is what a relocked custom OS uses;
• orange: unlocked.

AOSP specifies a warning screen on every yellow or orange boot. Those screens are how you tell whether your OS is still the one you installed.

GrapheneOS uses this directly. Its web installer guide says the device shows "a yellow notice on boot with the ID of the alternate OS based on the sha256 of the verified boot public key", and that 6th generation and later Pixels show the full hash, which you can compare with the official hashes GrapheneOS publishes. Older 4th and 5th generation Pixels only show the first 32 bits, so that check does not work on them.

Updates come in layers

Every distribution's documentation makes the same distinction, and it is the most misunderstood part of de-Googling. LineageOS's FAQ breaks security updates into three parts:

• Android (AOSP) security patches, which the distribution integrates and ships;
• Vendor security patch level, which "reflects the patch level of the stock firmware your device's vendor blobs were taken from";
• Firmware such as the bootloader, modem and TrustZone, which "LineageOS cannot update ... on its own."

/e/OS tracks the same split, listing a separate "Vendor security update" per device. CalyxOS notes that on several non-Pixel phones the stock OS is "usually behind AOSP updates by a month or two", and proprietary parts only update when it does.

The practical rule: a distribution can only be as current as the firmware the phone maker still ships. GrapheneOS states it plainly: it "can only fully provide security updates to a device provided that the OEM is releasing them."

The main distributions, from their own documentation

Each project below is described only from its own official pages, fetched on 23 October 2026. Device lists change often, so check the linked pages before you buy a phone.

GrapheneOS

Devices. GrapheneOS supports Google Pixel phones from the Pixel 6 through the Pixel 10 series and Pixel 10a, plus the Pixel Fold and Pixel Tablet. It strongly recommends the Pixel 8 and newer, which "provide a minimum guarantee of 7 years of support from launch" and hardware memory tagging. Its FAQ lists October 2026 as the maker's minimum support end for the Pixel 6 and 6 Pro. After end of life it may ship "extended support releases", which "cannot provide full security patches". It also warns that some carrier phones, "primarily an issue with US carriers", cannot be unlocked.

Installation. GrapheneOS has "two officially supported installation methods": a WebUSB web installer "recommended for most users" and a command line guide. It warns that "Third party installation guides tend to be out-of-date and often contain misguided advice and errors."

Relocking. The web guide says locking "is important as it enables full verified boot". The FAQ calls an unlocked bootloader "an incomplete installation" that it does not support. At first setup, a toggle to disable OEM unlocking is checked by default.

Updates. The updater checks "approximately once every six hours", installs to a secondary slot in the background and rolls back if the new version fails to boot. Updates are signed and downgrade protected, so the update server "isn't a trusted party".

Google Play and data. GrapheneOS does not bundle Google apps. Its compatibility layer runs the official Google Play apps "in the standard app sandbox" with "absolutely no special access or privileges", optionally in a separate profile. The FAQ says that by default it "only makes remote connections to GrapheneOS services and the network provided DNS resolvers", with no analytics or telemetry.

Official guide: grapheneos.org/install.

CalyxOS

Devices. CalyxOS's install page lists Pixel 6 through Pixel 10a models (and some older Pixels on extended support), Fairphone 4, 5 and the Fairphone Gen. 6, several Motorola moto g models and the SHIFTphone 8. The latest release shown at the time of writing was 8.0.4.21 or 8.0.4.22 depending on the device, dated 6 October 2026. The device support page lists estimated security update end dates for each model and marks some as extended support, with fixes for open source components only.

Relocking. CalyxOS "utilizes Verified Boot (including bootloader re-locking) to keep the Android security model intact." Its install page says the OS "is meant to be run with a locked bootloader after installation" and asks you to relock. Its bootloader lock page is device specific: on Pixel "It should be safe to re-lock the bootloader anytime", while for SHIFTphone, Fairphone and Motorola it says "DO NOT re-lock the bootloader without additional checks". The project recommends its own flasher and web installer because they "try to make sure that relocking is safe."

Before you flash. The install page warns that Pixels from Verizon in the United States cannot install CalyxOS because of bootloader unlocking prohibitions, and that Google's Factory Reset Protection must be disabled first, meaning you must not be signed in to a Google Account on the old OS. If FRP is on when you flash and relock, "you will not be able to turn OEM unlocking back on."

Updates. Since CalyxOS 7.2.2.0, updates install automatically over the air. Its security bulletin page explains an important limit on Pixels: "Google has stopped publishing the source code for AOSP QPR1 and QPR3 releases", so for releases based on those quarterly branches CalyxOS "is not able to timely include updates of the proprietary components, such as the bootloader, modem, and vendor firmware". Its security FAQ says factory images and updates are signed offline with a hardware security module, with key custody split among several people.

Google compatibility. CalyxOS bundles F-Droid and a Play Store frontend with extra update permissions, and documents the attack surface that adds in its security FAQ. It does not support running rooted, saying root "severely undermines the security of the device."

Official guide: calyxos.org/install.

LineageOS

Devices. LineageOS supports devices from dozens of makers, each with its own wiki page and install guide.

Relocking. The FAQ answers "Can/should I relock my bootloader?" directly: "Few devices allow for it and even less work properly after that. Relocking can result in actual unusable devices, so be warned!" It does not support recovery if you relock and the device stops working. In practice, plan for a LineageOS phone to run with an unlocked bootloader and an orange boot state.

Updates. LineageOS ships Android security patches to all maintained devices "as quickly as possible", but the vendor patch level depends on the stock firmware the vendor files were taken from, and firmware is out of its hands. The download server keeps "the last 3 builds per device", and "Older builds do not have the latest security patches."

Google apps. If you want Google apps, the FAQ says they must be installed before the first boot; after that you need a factory reset. Without Google apps or microG, push notifications do not work.

Play Integrity. LineageOS does not hide the bootloader state. Its FAQ says "it isn't our place to lie about security features," so apps that check device integrity may refuse to run.

Official guides: wiki.lineageos.org/devices, then your device's own install page.

/e/OS

Devices. The /e/OS device selector lists hundreds of phones and tablets, each marked as an "official" or "community" build. The documentation says official builds go through "a comprehensive testing cycle", while community builds "are provided as best effort, without any guarantee". Each entry also shows whether the bootloader is lockable. When we checked on 23 October 2026, only 15 entries were marked lockable and most were marked not lockable, so check your exact model.

Relocking. The /e/OS bootloader page warns: "Relock the bootloader on official builds only." Community builds are not signed with the release key, and relocking them "leaves the device unable to boot." When a device supports it, the commands are at the end of that device's own install guide.

Updates. The security updates page lists, for each release, the Android Security Bulletin level per Android branch and the vendor firmware build per device. For the September 2026 release it shows the 2026-09 bulletin level on the Android 14, 15 and 16 branches, and "Security patches no longer available" for the Android 12 and 13 branches. If your device is still on one of those older branches, the OS is no longer receiving Android security patches.

Google compatibility. /e/OS ships microG preinstalled, an open source reimplementation of Google Play services that lets many apps run "without a personal Google account". Its documentation says microG can pass Play Integrity's Basic verdict if you sign in with a Google Account system wide, and that "the Device and Strong verdicts require certified hardware and are out of reach." It also says relocking "does not restore Google's device certification".

Installation. The /e/OS Installer is a browser based tool that "only works on Chrome-based web browsers because the /e/OS Installer requires WebUSB support". Other devices use a command line method documented per device.

Official guides: doc.e.foundation/devices and the /e/OS Installer.

What breaks when you leave Google

Play Integrity and banking apps

Play Integrity is the Google API that many banking, payment and streaming apps use to decide whether to trust a device. Google's developer documentation defines the verdicts:

• MEETS_DEVICE_INTEGRITY: "a genuine and certified Android device". On Android 13 and higher, "there is hardware-backed proof that the device bootloader is locked and the loaded Android OS is a certified device manufacturer image."
• MEETS_BASIC_INTEGRITY (optional label): "The device bootloader can be locked or unlocked, and the boot state can be verified or unverified." On Android 13 and higher it "requires only that the attestation root of trust is provided by Google." It is only returned when the requesting app was installed or updated by Google Play.
• MEETS_STRONG_INTEGRITY (optional label): on Android 13 and higher it needs the device verdict plus "security updates in the last year for all partitions of the device".

Google's own troubleshooting advice for developers is to "make sure the factory ROM is installed ... and that the bootloader is locked." A relocked custom OS is still not a certified manufacturer image, so it cannot get the device verdict. Apps that require it will fail, no matter how secure the custom OS is. If you want to understand what an app's server actually learns from these verdicts, see what a Play Integrity verdict tells your server.

GrapheneOS's usage guide calls banking apps "a particularly problematic class of apps for compatibility with alternate operating systems". Many work with sandboxed Google Play in the same profile; GrapheneOS will not spoof integrity checks, and publishes a guide for app developers on accepting it through Android's hardware attestation API instead. Whether your bank does is up to your bank.

Find Hub

Google's help page lists what a phone needs before you can secure or erase it remotely: it must have power, be connected to mobile data or Wi-Fi, be "signed in to a Google Account", have Find Hub turned on, and be visible on Google Play. Without a Google Account, none of that is available. The page also notes that a factory reset removes the device from Find Hub, and that after a remote erase you need your Google Account password to use the device again.

GrapheneOS's FAQ explains that it does not provide Factory Reset Protection, calling it "strictly a theft deterrence feature, not a security feature" that depends on tying the phone to an online account. Its sandboxed Google Play does let apps use Google features as regular apps, but the remote locate and erase flow described on Google's page assumes a phone that is signed in and visible to Google Play. If remote locate matters to you, test it after setup. For background on what location tracking can and cannot do when a phone is powered down, see whether an Android or Samsung phone is findable when it is off.

Notifications, location and backups

Apps that rely only on Google's push service lose background notifications. Apps that use Google's network location may fall back to GPS only, unless the OS provides another source; GrapheneOS reroutes Play geolocation requests to its own implementation by default, and /e/OS configures a non-Google location backend with microG. Backups move from Google's cloud to whatever the distribution offers. GrapheneOS and CalyxOS both point to the open source Seedvault app. Set up and test a restore before you rely on it.

Security trade-offs, side by side

In short: a relocked OS on a supported device keeps verified boot while removing Google's privileged access. An unlocked bootloader trades a real protection for privacy, which may be fine on a spare phone but is a poor trade on the one holding your bank, work email and two factor codes.

How to verify your install

Whatever route you take, verify the result rather than trusting the process:

1. Download only from the project's own domain and use its official installer. Unofficial mirrors can serve modified images.
2. Check the boot state. A relocked custom OS shows a yellow notice. An orange warning on every boot means the bootloader is unlocked.
3. Compare the key fingerprint. On GrapheneOS with a 6th generation or later Pixel, compare the full hash on the yellow screen with the published list.
4. Use attestation where offered. GrapheneOS says its verified boot and attestation features can detect a replaced OS "Even if the computer you used to flash GrapheneOS was compromised".
5. Disable OEM unlocking afterwards in Developer options. GrapheneOS's setup does this by default.
6. Confirm the security patch level in Settings against the project's release notes.

Keeping a de-Googled phone patched

• Leave automatic updates on. GrapheneOS "highly recommended" keeping its updater enabled; CalyxOS and /e/OS also update over the air.
• Watch your end of support date. Once the maker stops shipping firmware, projects can only patch open source parts. Replace the phone then rather than moving to an unofficial build.
• Watch the Android branch. On /e/OS, make sure your branch does not say "Security patches no longer available".
• Update apps too. Apps from F-Droid, Accrescent or any other store need their own updates.
• Compare against the bulletins. Check your patch level against the latest Android security bulletin on source.android.com.

Common mistakes

• Following a video or forum guide instead of the project's own installer. Every project in this post says some version of "use our official guide". LineageOS will not support you otherwise.
• Leaving the bootloader unlocked "for now". GrapheneOS says to relock before putting any data on the device, because the device "is considered to be insecure" until then.
• Relocking a device that cannot handle it. LineageOS warns relocking can brick most devices, /e/OS says community builds cannot be relocked, and CalyxOS says to run extra checks on non-Pixel phones.
• Flashing with Factory Reset Protection still on. CalyxOS warns this can leave you unable to turn OEM unlocking back on.
• Buying a carrier locked phone for a custom OS. GrapheneOS and CalyxOS both warn that some US carrier phones cannot unlock.
• Using pm uninstall on a system package without a plan. Prefer disable-user, which has a documented reverse.
• Assuming the OS patch level covers everything. Vendor code and firmware are separate layers.
• Rooting to make an app work. CalyxOS says root "severely undermines the security of the device."
• Not testing banking, payment and two factor apps first. Find out what breaks before you wipe your main phone.

Where Safeguard fits, honestly

Safeguard does not replace any Google service, does not install operating systems, and does not scan your phone. If your goal is a private phone, the projects above are where that work happens.

The overlap is the idea underneath this whole guide: an operating system, an app store and every app on the device are a software supply chain. You are deciding who you trust to build and sign each layer and how quickly fixes reach you. If you build Android apps or the services they talk to, the same questions apply to your own dependencies, and that is where Safeguard helps. It builds an SBOM for your repositories and container images, matches components against vulnerability databases, shows which projects contain a given vulnerable version, and can open fix pull requests when your team turns that on.

Fix it without waiting for upstream

If you ship Android apps or backends, the slowest part of patching is usually waiting on a library's maintainer. The same principles that apply to firmware lag on a phone apply to your dependencies, and here you have more control.

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.

FAQ

Can you completely remove Google from an Android phone?

Not on the stock OS. You can disable Google apps, remove them for your user and sign out, but the system still ships them. Removing Google completely means a distribution that does not include it, on a device the project officially supports.

Is it safe to uninstall Google Play services?

Disabling it is reversible but breaks background notifications for many apps, Google sign in, Find Hub and Play Store updates. Disable individual Google apps first. If you want no privileged Play services at all, an OS designed without it is safer than ripping it out of one that expects it.

Does unlocking the bootloader make my phone less secure?

Yes, while it stays unlocked. AOSP's own warning text says "Software integrity cannot be guaranteed with a custom OS". /e/OS's documentation notes it is not a remote vulnerability by itself and requires physical access, but it lets a compromise persist across reboots. Relocking with the distribution's own key restores verified boot on devices that support it.

Which de-Googled Android OS can relock the bootloader?

According to their own documentation, GrapheneOS requires relocking on all supported Pixels, CalyxOS supports relocking (safe anytime on Pixels, with extra checks on other makers), /e/OS supports it on official builds for devices marked lockable, and LineageOS warns that few devices allow it and relocking can make a device unusable.

Will banking apps work on GrapheneOS, CalyxOS or LineageOS?

Some will and some will not. Apps that require Play Integrity's device verdict need a certified manufacturer image, which no custom OS is. GrapheneOS says many banking apps work with sandboxed Google Play in the same profile. Test your specific apps before switching.

Can I use Find Hub without a Google Account?

No. Google's help page says that to secure or erase a device remotely it must be signed in to a Google Account, have Find Hub turned on and be visible on Google Play. If you remove the account, you lose remote locate and erase through Google.

What is microG and is it the same as Google Play services?

microG is an open source reimplementation of Google Play services APIs, preinstalled on /e/OS. It lets many apps run without a personal Google account. /e/OS's docs say it can pass Play Integrity's Basic verdict with a system wide Google sign in, but not the Device or Strong verdicts.

How long will a de-Googled phone get security updates?

Only as long as the phone maker ships firmware. GrapheneOS lists 7 years from launch for Pixel 8 and later, and CalyxOS publishes estimated end dates per device. After that, projects can patch open source parts only, which GrapheneOS describes as a stopgap.

Is F-Droid safe to use?

F-Droid publishes its security model: signed metadata generated on an offline machine, HTTPS only and published build logs. Android then accepts updates only from the same developer as the installed app. The first install is the moment of most trust, so get the client only from f-droid.org.

See how Safeguard would help

None of these demos de-Google a phone. They show how the same supply chain questions you just asked about your phone, who builds it, who signs it and how fast fixes arrive, apply to the software your team builds. If you want to try the CLI yourself, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real Android session. You send work from the phone to a computer running the Safeguard CLI, and approve each command on the phone with Allow once, Allow for turn or Deny. It fits this topic directly: whatever Android build you settle on, your phone can stay the approval step for work that runs elsewhere, without the phone itself holding your code.

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

The second demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it 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. If you build Android apps or their backends, this is the same flow for the dependencies in your own repositories.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It mirrors the permission thinking in this guide: decide exactly which capabilities a component gets instead of granting everything by default.

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

Quick check

Sources

• GrapheneOS: Install
• GrapheneOS: Web installer guide
• GrapheneOS: Command line installation guide
• GrapheneOS: FAQ
• GrapheneOS: Usage guide
• GrapheneOS: Features overview
• CalyxOS: Install
• CalyxOS: Device support
• CalyxOS: Security
• CalyxOS: Bootloader lock
• CalyxOS: Security bulletins
• CalyxOS: Security FAQ
• LineageOS: Devices
• LineageOS: FAQ
• /e/OS: Device selector
• /e/OS: Bootloader relocking
• /e/OS: Security updates tracking
• /e/OS: microG
• /e/OS: Installer
• Android Open Source Project: Verified Boot
• Android Open Source Project: Boot flow
• Android Open Source Project: Lock and unlock the bootloader
• Android Open Source Project: Security bulletins
• Android Developers: Play Integrity API overview
• Android Developers: Integrity verdicts
• Android Developers: Android Debug Bridge (adb)
• Android Help: Find, secure, or erase a lost Android device
• Google Play Help: Delete, disable and manage unused apps on Android
• F-Droid
• F-Droid: Security model
• Accrescent

Last reviewed: 23 October 2026. Device lists, support dates and Play Integrity rules change often; check each project's official pages before you buy a phone or flash anything.