Clearing Misconceptions and Some Tips on Debloating Android Phones

What is bloatware?

When you unbox your new phone, it comes with Android that is pre-installed by the manufacturer. This is termed “stock firmware”. Stock firmware also comes with a number of apps pre-installed, like native browser, Google apps, games, etc. Some applications are manufacturer-specific. For example, many Samsung phones come with Samsung Health and Galaxy Apps pre-installed, which are available only in Samsung devices.

Often, the user doesn’t require these applications, as they are mostly inferior when compared with similar apps available elsewhere. You can disable them from Settings, but they will continue to take up space on your eMMC. Such apps are then termed as “bloatware”. The process of removing the APK and data files of the bloatware is called “debloating”.

Summary of certain technical terms that have been used in the article:

• APK file – Android Package (APK) is the package file format used by the Android operating system for the distribution and installation of mobile apps and middleware. Read more on Wikipedia.
• User apps – Apps that you install, i.e. any app that hasn’t 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 puts the MMC components (flash memory plus controller) into a small ball grid array (BGA) IC package for use in circuit boards as an embedded non-volatile memory system. It is actually the internal solid-state disk where your apps and data are stored. Read more on Wikipedia.
• Bootloop – It is a situation where a device cannot fully boot up and starts over, 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 that it is bricked. Read more on Wikipedia and Android StackExchange.

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

There are hundreds of guides available online which will tell you that you can uninstall the pre-installed apps without rooting your phone. Let us see why those are not actually correct.

If you have used Windows, you must be familiar with “administrator permissions”. On Linux, there is the concept of “super user (SU)” privileges. Something similar exists in Android. Pre-installed/system apps are installed 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 that you cannot uninstall system apps unless you root your device. Some apps are also installed on /system/priv-app, which are privileged apps and are mounted read-only to prevent any changes.

Rooting is the process that gives you access to the “locked” sections of your phone’s eMMC. Once your phone is rooted, you can access the /system partition and modify it, and therefore remove the system apps completely. Without root access, no application or method will be able to completely remove the system apps from your phone.

If you have gone through the guides that promise to debloat your phone without rooting, you will perhaps know that there are two famous methods to do this – using a debloater application or using ADB (Android Debug Bridge). I have used both. The first one proved ineffective on my phones. Using the second one, you can only uninstall the applications from the current user, which means they are still present in your system memory and eating up space. If you ever do a factory reset of your phone, those apps will again come back. XDA developers have written 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).

In addition, many of those articles also claim that you will not brick your phone in the process. This is not true. When I used the ADB to uninstall the system apps on my Samsung Galaxy On7, the phone actually became slower, and finally, I had to take it to a service center to replace the motherboard.

Misconception #2: After removing the unnecessary system apps, I can use the space to store my photos/download user apps

The APK files of pre-installed applications are present in /system/app and /system/priv-app partitions. This means that when you remove the APK files from the /system partition, that space is not available for storing your photos/media or installing user apps. It is the same as the hard disk on your computer – deleting files from a partition does not amount to decreasing the size of the partition.

You can regain that space by re-partitioning the eMMC. But that is not recommended, because almost all attempts of re-partitioning that I have seen have ended in a bricked phone, from where the phone cannot be recovered in any way.

If you use a systemless root tool like Magisk, you cannot directly modify the /system partition, because modifications are stored in the boot partition instead of modifying the real system files. But if you use a traditional root method like Super SU, then you can directly access the /system partition and modify it as per your wish. Then you can move user apps to the /system partition, and let them use that space.

But Super SU is not a preferable rooting option, mainly because once you directly modify the /system directory, SafetyNet detects it and blocks certain apps from working properly. In addition, WhatsApp, Facebook, and other social media apps will not work. (WhatsApp clearly states that their app is not for rooted phones) That is why people mostly prefer Magisk nowadays because Magisk helps bypass the SafetyNet check, which means you can still install WhatsApp and Play Store apps.

A third option is to install a custom ROM and modify the partitions completely. But we shall be discussing things that can be done by keeping the stock firmware intact as much as possible – so custom ROMs are out of the scope of this article.

Is debloating actually useful?

After reading all these, one question might arise in your mind: is debloating actually useful? Is it worth taking the pains of rooting the phone and then uninstalling the system apps, keeping in mind that there is always a risk of bricking the phone?

There are two reasons why you might think about debloating:

1. Although the APK files are saved in /system/app and /system/priv-app directories, the configuration files and downloaded data are saved in /data, which is eating away your accessible memory. But once you explicitly clear the app data from Settings before disabling the app, this space is actually quite low. For example, the Drive app has an APK of size 23MB on my phone, which leaves just 7MB of recoverable storage.
2. People say that even in a disabled state, these apps will still spy on you and collect information, and thereafter send them to the company that made it. But this data is significantly less compared to what it would have collected when it was enabled.

So, if you are not paranoid about that small amount of data (if any) being sent, then what it necessarily boils down to is recovering an average of 5-10MB per system app. If that makes sense and you still want to debloat your phone, you are most welcome to do so.

Which apps should I remove?

As stated before, there are two particular places where the base APK files are stored: /system/app and /system/priv-app. When I debloated my phone (a Samsung Galaxy On7 running on Android 6.0) for the first time, I removed four apps – Samsung Health, Google app, Drive, and Photos, after which I restarted my phone and found that it was bricked. (I had been able to recover the phone from there and am still using it; the incident is briefly mentioned towards the end.)

What I realized later was, two of the four apps – S Health and G-app, were placed in /system/priv-app directory. While it is not mentioned anywhere explicitly on the net, I believe any app which has its APK file stored in /system/priv-app directory, should not be removed. If you have a look at this directory with a root file browser, you will find that it mainly contains apps that are of prime importance for your phone to run normally. For example, in my phone, the folder contains ConfigUpdater, ContextProvider, DefaultContainerService, and ResourceManager, to name a few. These are important for the device to function properly, and should never be removed.

So, before you debloat, it is preferable that you spend some time with the Android directories. If you choose an app to debloat, first check whether it resides in /system/priv-app directory. If it does, ignore it, otherwise, you can take a chance and remove its APK.

My first experience with debloating:

The internal disk space in my phone was 91% filled, and I was getting notifications from almost all apps that the storage was nearly full. I read online that debloating could make some space. So, on one fine morning, I flashed TWRP (using Odin, since I have a Samsung phone), and then installed Magisk manager, and through it, downloaded Magisk systemless root module, and flashed it through TWRP. Everything went well. But the biggest mistake I made was, I didn’t make a backup of my system through TWRP.

Then I installed Titanium backup, and straight away un-installed the four apps mentioned above. The device was a little bit shaky, so I did a restart. And then I got the shock – the phone was not booting beyond the Samsung logo. I had managed to brick my device.

After frantically searching the net for almost two hours, it occurred to me that if I can find the stock firmware and flash it, I might get back my phone. I found it on some sites, but they were reluctant to give it to me unless I paid a fee. But one site was offering it for free, but at a reduced download speed. Having no second option at hand, I downloaded that (it took about two hours), and flashed it using Odin. And I finally got back my loved phone. No data was lost, fortunately – the flash didn’t alter anything in storage/emulated/0, except that, I lost the SMS messages.

Lesson learned: Never ever attempt a debloat procedure (or anything advanced) without taking a backup of 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