Debloating Android Phones: Risks and Best Practices

What is bloatware?

When you unbox a new phone, it comes with Android pre-installed by the manufacturer. This is termed “stock firmware.” Stock firmware also includes several apps pre-installed, like the native browser, Google apps, games, and other vendor-specific applications. For example, many Samsung phones ship with Samsung Health and Galaxy Apps, which are available only on Samsung devices.

Often the user does not require these applications because they are frequently inferior to alternatives available elsewhere. You can disable them from Settings, but they continue to occupy space on your eMMC. Such apps are termed “bloatware.” The process of removing the APK and data files of bloatware is called “debloating.”

Key terms used in this article

• APK file – Android Package (APK) is the package file format used by the Android operating system for distribution and installation of mobile apps and middleware. Read more on Wikipedia.
• User apps – Apps that you install (any app that has not been pre-installed on your phone). These apps have their APK files in the /data/app directory.
• eMMC – MultiMediaCard, officially abbreviated as MMC, is a memory card standard used for solid-state storage. The eMMC (embedded MMC) architecture places the MMC components (flash memory plus controller) into a small ball grid array (BGA) IC package for use on circuit boards as an embedded non-volatile memory system. It is the internal solid-state disk where your apps and data are stored. Read more on Wikipedia.
• Bootloop – A situation where a device cannot fully boot and restarts repeatedly in a loop. This usually continues until the battery drains, unless forcibly stopped by removing the battery.
• Bricking a phone – A phone is said to be bricked when it can no longer function as intended. For example, if your phone does not boot beyond the Android logo, it can be said to be bricked. Read more on Wikipedia and Android StackExchange.

Misconception #1: I can debloat my device without rooting it

There are hundreds of guides online claiming you can uninstall pre-installed apps without rooting your phone. Those guides are often misleading; here is why.

If you have used Windows, you may be familiar with “administrator permissions.” On Linux, there is the concept of “super user (SU)” privileges. Android has a similar model. Pre-installed (system) apps are stored on the /system/app partition of your eMMC. By default, you do not have SU privileges on your Android phone, which means you cannot access the /system partition. This implies you cannot uninstall system apps unless you root your device.

Some apps are installed in /system/priv-app; those are privileged apps and are typically mounted read-only to prevent changes. Rooting is the process that grants access to these locked sections of the phone’s eMMC. Once your phone is rooted, you can access and modify the /system partition and therefore remove system apps completely. Without root access, no application or method can fully remove system apps from your phone.

If you have followed guides that promise debloating without rooting, you have likely seen two common methods: using a debloater application or using ADB (Android Debug Bridge). I have used both. The first proved ineffective on my phone. With the second, you can uninstall applications only for the current user; the APKs remain in the system memory and continue to occupy space. If you factory-reset your phone, those apps will return. XDA Developers explain this in their guide to remove bloatware without root access,

…applications truly aren’t being fully uninstalled from the device, they are just being uninstalled for the current user (user 0 is the default/main user of the phone). That’s why, if you omit the “–user 0” and “-k” part of the uninstall command, the command won’t work. These two flags respectively specify that the system app will only be uninstalled for the current user (and not all users, which is something that requires root access) and that the cache/data of the system application will be preserved (which can’t be removed without root access).

Many articles also claim that you will not brick your phone by using ADB. That is not always true. When I used ADB to uninstall system apps on my Samsung Galaxy On7, the phone became slower and eventually required service support to replace the motherboard.

Misconception #2: Removed system APKs free space for photos or user apps

The APK files of pre-installed applications are present in the /system/app and /system/priv-app partitions. Deleting APKs from the /system partition does not make that space available for your photos, media, or user app installations; it is analogous to deleting files inside a partition without resizing the partition itself.

You can reclaim that space only by repartitioning the eMMC. That is not recommended: most repartitioning attempts I have seen have resulted in a bricked device that could not be recovered.

If you use a systemless root tool like Magisk, you cannot directly modify the real /system partition because Magisk stores modifications in the boot partition instead. If you use a traditional root method such as SuperSU, you can directly modify /system and move user apps into that partition to use the space.

However, SuperSU-style modifications to /system trigger SafetyNet detection and can block certain apps from working correctly. Many users therefore prefer Magisk because it helps hide root from SafetyNet, allowing apps such as WhatsApp and Play Store apps to continue functioning.

Installing a custom ROM and changing partitions is a third option, but that is outside the scope of this article because this article focuses on approaches that keep the stock firmware intact as much as possible.

Is debloating useful?

After reading the above, you may ask: is debloating useful? Is it worth rooting the phone and removing system apps, given the risk of bricking the device?

There are two main reasons to consider debloating:

1. Although APKs reside in /system/app and /system/priv-app, configuration files and downloaded data are stored in /data, which consumes your accessible storage. If you explicitly clear an app’s data from Settings before disabling it, the recoverable space is usually small. For example, the Drive app’s APK on my phone is 23 MB, yielding only about 7 MB of recoverable storage after clearing data.
2. Some people claim that, even when disabled, these apps continue to collect data and send it to the manufacturer. In practice, the amount of data transmitted when an app is disabled is significantly smaller than when it is enabled.

So, if you are not concerned about the small amount of telemetry (if any) being sent, debloating typically recovers an average of 5–10 MB per system app. If that gain justifies the risk for you, debloating may be worthwhile.

Which apps should I remove?

Base APK files are stored in two directories: /system/app and /system/priv-app. When I first debloated my Samsung Galaxy On7 (Android 6.0), I removed four apps — Samsung Health, Google app, Drive, and Photos — and then rebooted. The phone failed to boot beyond the logo; I had effectively bricked it (I later recovered it; the incident is described below).

I later discovered that two of those four apps (S Health and the Google app) resided in /system/priv-app. While not documented explicitly anywhere I found, apps in /system/priv-app are typically important for normal device operation and should generally not be removed. On my device, this directory contained items such as ConfigUpdater, ContextProvider, DefaultContainerService, and ResourceManager — components that are important for the device to function properly.

Before you debloat, inspect the Android directories. If the app you plan to remove resides in /system/priv-app, leave it alone. If it is only in /system/app, you may decide to remove its APK, accepting the inherent risk.

My first experience with debloating

My device’s internal storage was 91% full and I was receiving storage warnings. I read online that debloating might recover space. One morning I flashed TWRP (using Odin, since I have a Samsung device), installed Magisk Manager, and flashed the Magisk systemless root module through TWRP. Everything appeared to proceed normally. My biggest mistake was not making a backup of the system through TWRP.

I then installed Titanium Backup and uninstalled the four apps noted above. The device behaved erratically, so I restarted it and discovered it would not boot beyond the Samsung logo — I had bricked it.

After two hours of searching, I decided to flash the stock firmware. I found a copy online, downloaded it (at reduced speed), and flashed it using Odin. I recovered the phone; fortunately, no user files under /storage/emulated/0 were altered, though I lost SMS messages.

Lesson learned: never attempt debloating (or other advanced modifications) without a full backup of the system, data, and boot sectors.

Further reading

• What is /storage/emulated/0?
• Usage of disk space in Android
• Storing of applications in Android
• Create a Ringtone Picker

Comment Thread