Why I Use a DeGoogled, Rooted Phone with Custom Firmware

2026/05/14

Summary

I have been using deGoogled custom ROM setups for around five years, on and off with root, and with almost exclusively open-source applications.

In this post I go through the parts of Android that matter when installing and running a custom ROM: what custom firmware means, what the bootloader does, why unlocking it changes the trust model, and how tools like ADB, fastboot, recovery, TWRP and OrangeFox fit into the process.

I also write about what “deGoogled” means in practice, how AOSP-based ROMs differ from Google-certified Android builds, and how Google apps can be left out or added back with separate packages.

The last part is about root and Magisk. Root is useful for control and customization, but it also changes what mobile apps can safely assume about the device. This is why root detection is still a constant cat-and-mouse game for banking apps, government apps, identity apps and other software that handles sensitive data.

Table Of Contents

What is custom firmware or a custom ROM?

A custom ROM is a replacement Android operating system built outside the OEM’s official software release channel.

Historically people say “ROM”, but modern Android devices are not literally replacing a read-only memory chip. What is usually being replaced is a set of Android partitions or partition images: boot, system, vendor_boot, vbmeta, product, system_ext, and sometimes others depending on the device. (See Android Partitions on android.com for detailed information on the partitions. )

A custom ROM mainly means:

Examples include LineageOS (this is what I daily driver for a long time now) and other device-specific Android distributions. GrapheneOS is also well-known in the security and privacy space, but it is intentionally limited to supported Google Pixel devices because its security model depends heavily on specific hardware and firmware support.

High level boot flow relevant to installing a custom ROM

A separate blog post could be written about the boot flow of android devices explaining all the steps in detail, for this post, only the relevant parts to installing a custom ROM will be highlighted.

Power on
  ↓
Bootloader
  ↓
Recovery or normal Android boot
  ↓
Kernel and ramdisk
  ↓
Android userspace
  ↓
System apps and user apps

On a normal locked device, the bootloader is expected to verify the software before booting it. Android Verified Boot (AVB) is designed to establish a chain of trust from a hardware-protected root of trust through the bootloader and verified partitions such as boot, system, and vendor.

That means the bootloader is not only responsible for starting Android but it also does the security verifications.

If the bootloader is locked, it normally expects official, trusted images. If those images are modified, the device should refuse to boot, show a warning, or enter a recovery/error state depending on the implementation.

To install a custom ROM, the bootloader needs to be unlocked.

What does unlocking the bootloader mean?

Unlocking the bootloader means changing the device policy so it will allow non-stock software to be flashed and booted.

AOSP describes bootloader unlocking as a mechanism that allows partitions to be reflashed, with the unlock state persisting across reboots.

In practical terms, unlocking means:

Bootloader unlock processes differ based on vendors. For example Xiaomi phones require a third-party application and device registration to be able to unlock the bootloader.

What is fastboot?

Fastboot is a communication protocol used to communicate with the phone while it is in bootloader mode. Unlike ADB, which works when Android or recovery is running, fastboot works before Android starts.

It is used for lower-level installation steps such as unlocking the bootloader, flashing boot or recovery images, temporarily booting a recovery image, or changing the active slot on A/B devices.

For example:

fastboot flashing unlock
fastboot flash boot boot.img
fastboot boot recovery.img
fastboot reboot

Recovery, TWRP and OrangeFox

Recovery is a separate boot target from the normal Android system. Instead of starting the full Android userspace, the bootloader loads a smaller recovery environment with tools for updating, wiping, mounting, and flashing partitions.

This matters for custom ROM installation because the ROM installer needs access to partitions that are normally used by the running system. A ROM package may replace or patch images such as boot, init_boot, vendor_boot, dtbo, vbmeta, and logical partitions inside super, such as system, product, and system_ext.

Recovery provides an offline environment where these partitions can be modified before Android boots. It can also expose ADB sideload, which lets the user send the ROM package from a computer directly to the recovery installer.

A common custom recovery is TWRP. It can:

Another popular alternative is OrangeFox.

Not every custom ROM uses TWRP or OrangeFox. Some distributions provide their own recovery. For example, LineageOS has Lineage Recovery, which is simpler than TWRP but is designed to install LineageOS updates reliably.

What is ADB?

ADB stands for Android Debug Bridge. It is a tool used to communicate with the phone when Android or recovery is already running.

From a custom ROM installation point of view, ADB is usually used to reboot the device into another mode, check whether the computer can see the device, open a shell, or sideload a ROM package from the computer to recovery.

For example:

adb devices
adb reboot bootloader
adb reboot recovery
adb sideload lineageos.zip

What does deGoogled mean?

Android itself is partly open source through the Android Open Source Project, or AOSP. AOSP is the publicly available base of the Android platform that device manufacturers and custom ROM developers can build on top of. It includes the core operating system, framework, system services, and default open-source components, but it does not include Google’s proprietary application and service layer.

This distinction is important:

AOSP Android → open-source Android platform base

Google Mobile Services / GApps → proprietary Google apps and services added on top

When people say a ROM is “deGoogled”, they usually mean that the ROM is built from AOSP or an AOSP-based project without bundling Google apps and services by default. This means no Play Store, no Google Play Services, no Google account integration, and no default Google application stack.

On forums such as XDA, ROMs are often distributed in different variants. A maintainer may publish a “vanilla” build without Google apps, and sometimes a separate “GApps” build with Google apps included. In other cases, the ROM is distributed without Google apps, and the user can flash a separate GApps package after installing the ROM.

Common GApps packages include projects such as Open GApps. These packages are installed from recovery, usually immediately after flashing the ROM and before the first boot. LineageOS, for example, does not ship Google apps by default, but its documentation explains that users can install Google apps separately through recovery if they choose to.

So Google is not usually “removed” from a ROM after the fact. It is simply not included during the ROM build. The ROM is built from AOSP and related open-source components, while the proprietary Google layer is left out.

Some projects take a different approach and use microG, which is an open-source reimplementation of parts of Google Play Services. This can provide compatibility for some apps that expect Google APIs, while avoiding the official proprietary Google Play Services package. It is not a perfect replacement, but it is useful for users who want fewer Google dependencies while keeping some app compatibility. But again this also have its own post.

Root

Root on Android means getting privileged access to the device, similar to the root user on Linux.

Normally Android applications run inside their own sandbox. Each app has its own Linux UID, its own private data directory, and limited permissions. One app should not be able to read another app’s private files or modify the system.

For many users, root is mainly about customization and control. It can be used to change themes, modify system behavior, improve battery management, remove unwanted system apps, use advanced backup tools, or install modules that change how the device works.

From a security point of view, root is interesting because it also changes the assumptions applications can make about the device. Data that is normally protected by the Android sandbox may become accessible to a privileged user or process.

For example, each installed app has a private directory under:

/data/data/<package_name>

Normally this directory is only accessible to that application and the system. On a rooted device, this protection can be bypassed. This means app databases, shared preferences, cached files, logs, configuration files, tokens, and other local state may become visible or modifiable.

That does not mean root automatically breaks every app. It means that if an app depends too much on local storage or local checks, root can make those weaknesses easier to abuse.

What Magisk does

Magisk is one of the most common ways to get root on modern Android.

It is not just an APK that magically gives root. The Magisk app is mostly the management interface. The important part is that Magisk modifies the boot process.

In many cases, the flow looks like this:

original boot image
  ↓
patched by Magisk
  ↓
patched boot image flashed to the device
  ↓
Android boots with Magisk support
  ↓
apps can request root through MagiskSU

Depending on the device, Magisk may patch boot, init_boot, or sometimes another boot-related image. This is why root is closely connected to the Android boot process. It happens before the normal Android userspace is fully started.

Once Magisk is installed, apps can request root access through su. The user can allow or deny that request from the Magisk app.

Why root matters for apps

Root matters because many mobile apps store some amount of state locally.

This can include:

If the app is designed well, sensitive decisions are enforced by the backend and sensitive local data is protected properly. In that case, root makes analysis easier, but it should not be enough to break the application’s security model.

If the app is designed badly, root can expose serious problems. For example, if access control depends on a local flag, or if sensitive tokens are stored insecurely, then a rooted device makes those issues much easier to find and exploit.

This is especially relevant for applications that handle high-value data or identity, such as banking apps, government apps, healthcare apps, and digital wallet applications. These apps cannot simply trust the device because the device may be modified, rooted, instrumented, or running a custom ROM.

Root detection

Because of this, many sensitive applications try to detect root or other signs of device modification.

They may check for things like:

This has become a constant cat-and-mouse game. Apps add root detection, root solutions and hiding tools adapt, then apps add stronger checks, and the cycle continues.

References