# De-Bloater: disabling Android system apps with a Magisk module

> De-Bloater is a GPL 3.0 licensed Android application that removes unwanted system apps systemlessly by generating a Magisk, Kernel SU or APatch module named De-bloater, with a restore path and a bootloop recovery route. The judgement is that it stays out of the way by never editing /system, and that its real dependency is a rooting environment with module support.

**sunilpaulmathew/De-Bloater** — An application using the power of Magisk to debloat unwanted system apps!

- Repository: https://github.com/sunilpaulmathew/De-Bloater
- Website: https://sunilpaulmathew.github.io/De-Bloater/
- Stars: 801 · Forks: 44
- Language: Java
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sunilpaulmathew-de-bloater

## Debloating through a module instead of through a partition edit

De-Bloater is a Java application that takes the list of system applications you never wanted and removes them the way a rooted phone allows them to be removed: by module, not by file deletion.

The mechanism is described in the project as systemless. Instead of writing into the system partition, the application replaces the selected APKs by building a Magisk, Kernel SU or APatch module, and a new module appears in the module list under the name De-bloater. The system partition itself is never edited, which is what makes the operation reversible and what keeps a bad removal from permanently damaging the installation.

The target directories are named in the feature list: system apps in /system, /vendor, /product and other directories can all be selected. What the application does not do is delete anything permanently. The package it manages is a module, and modules can be reset.

That design also means the application is a front end for a rooting environment rather than a standalone root tool. It has no way to work on a device where the module layer is absent, and the README says that plainly.

## The rooting environment has to support modules, and core-only mode does not

The requirement section is short but strict. De-Bloater needs root access and a fully functional Magisk, Kernel SU or APatch environment, and the word the project emphasises is modules, because the module system is what the whole approach rests on.

Two exclusions follow directly. It will not work with other rooting solutions, and it will not work with Magisk in core-only mode. Core-only mode is the Magisk configuration that skips the module layer entirely, so an installation in that mode is not a De-Bloater installation at all, whatever the root state says.

This is the single most important fact for anyone reading the project, because the failure mode of an unsupported environment is not a clean error. There is no supported path that ends with the module simply not appearing, and the recovery instructions in the same document assume a phone that boots badly rather than a phone that refused to change.

The supported list doubles as a compatibility statement: Magisk, Kernel SU and APatch are named, and the credits acknowledge John Wu for libsu and Magisk and weishu for KernelSU, so the three environments are first class rather than incidental.

## Removing is one tap, restoring is a module reset

The user flow is deliberately minimal. Open the application, tap the remove button on each application you want gone, and the selected packages are handled after a reboot. The README repeats the requirement for a restart, and it is not a formality, because the module is what applies the change and the module only takes effect on the next boot.

Restoration is where the project is more careful than most. There are two ways back. The Reset Module entry in the top menu removes the De-bloater module entirely, which returns the system to its original state in one action. The second page of the application allows a selective restore, so a single package can be brought back without dropping the changes made to every other one.

That combination is the practical reason to use this approach at all. Removing a package that the device needed is easy to do by accident, and with a module the undo is a button rather than a reinstall of the stock firmware.

The requirement to know the recovery path, though, applies to the first minutes after a wrong removal, since the module has to be cleared from a recovery environment rather than from the application.

## The bootloop case is handled by deleting one directory from recovery

The troubleshooting section exists because the failure is severe. If you remove an application the system actually needed, the phone can bootloop, and the fix is not in the application at all: it is deleting the De-bloater module directory, /data/adb/modules/De-bloater, through recovery.

That is the honest shape of this tool. The module approach makes removal reversible in normal operation, and it also means the way back from a bricked boot is a file system operation performed outside Android. The application cannot help you there, because the application is part of the system that is not starting.

The credit list also explains where the project sits in the rooted Android ecosystem. The code contributions are credited to Grarak, with some code taken from Kernel Adiutor, which is a separate application in the same field, and the roots themselves are credited to John Wu for libsu and Magisk and to weishu for KernelSU. De-Bloater is a client for that ecosystem rather than an independent implementation of it.

So the tool belongs on a device whose owner is comfortable with a recovery environment, and the documentation treats that as an understood prerequisite.

## Four ways to install it, and they do not carry the same versions

De-Bloater is distributed through four channels, and the README lists a direct link for each. Google Play carries the application under the package id com.sunilpaulmathew.debloater. F-Droid has it as well, as com.sunilpaulmathew.debloater. The IzzyOnDroid repository hosts an APK, and the GitHub releases page offers the build directly, with the current artefact named app-release.apk under the v0.32 release.

The release history is visible from those channels. Version 0.30 was published on 2025-09-29, version 0.31 on 2026-04-07, and version 0.32 on 2026-05-25, with the last push to the repository on the same date as the newest tag. The badge in the README tracks the v0.32 line.

For a rooted phone this matters less than it would elsewhere, because the application is a front end for a module and a stale build still does the same job against the same module system. For a user who tracks updates through one channel, the practical point is to pick a channel and stay on it, since a Play Store build and a GitHub APK can sit at different versions without either being wrong.

The homepage is a project page hosted on GitHub Pages rather than a marketing site, which matches the tone of a tool documented for people who already know what Magisk is.

## A Gradle app with a fastlane pipeline and a translation file

The repository is a standard Gradle Android project with the usual pieces: an app directory, a build.gradle file, a settings.gradle, a gradle wrapper and a gradle.properties, plus two directories that say something about how the project is released. The fastlane directory holds the release automation, and profiles directory holds product flavors, and the docs directory holds documentation, with a LICENSE.md at the root.

Localisation is handled through POEditor, and the project invites contributors to translate through that service, with the option of editing the original language strings directly in app/src/main/res/values/strings.xml. The credits list names translators for Russian and Ukrainian, Turkish, Spanish, Italian, German, Polish, French, Vietnamese, Chinese in several variants, Arabic, Portuguese from Brazil, Japanese, Hungarian and Slovak, which is a broad coverage for a tool of this size.

The application itself is written in Java, and the code lineage runs through Grarak's Kernel Adiutor, which the credits name as the source of some of the code. That lineage explains the shape of the interface, a list of packages with a toggle on each, and the module model underneath it.

The GPL 3.0 licence and the copyright line from 2020 to 2026 sit under all of it, so the code is copyleft and the assets and translations are contributed under the same project.

## A single maintainer, a donation link and a five month gap since the last tag

De-Bloater is maintained by one person, sunilpaulmathew, and the README carries the copyright notice for the period from 2020 to 2026 under the GNU General Public License version 3, with the standard notice that the software is distributed without warranty.

The funding section names Liberapay, PayPal and Ko-fi, and also points at a SmartPack Donation Package in the Play Store, and the author is candid that donations help keep the projects more active but are not needed. For a user deciding whether to rely on the tool, that matters less than the schedule does. The last push was on 2026-05-25 and the newest release, v0.32, carries the same date, with v0.31 six weeks earlier and v0.30 before that. The gap between the two most recent releases is wide compared with the gap before it, which tells you the cadence slowed rather than that the project stopped.

What has not changed is the surface area of the tool. The requirement is still root with a module-capable environment, the flow is still select, reboot, and the recovery is still deleting one directory from recovery. A tool this small has few moving parts, and that is as much its strength as its risk.

## Conclusion

De-Bloater fits a rooted Android user on Magisk, Kernel SU or APatch who wants carrier apps and vendor extras gone from a phone without hand editing system partitions, because every change lands as a named module that can be reset in one action. It is the wrong choice without root, on Magisk in core-only mode, or on any rooting solution that lacks module support, and it is the wrong choice for anyone who cannot use a recovery environment, because a bad removal leaves the phone bootlooping until the De-bloater module directory is deleted. Before you start, confirm that your rooting environment has modules enabled, install the module directory deletion recovery procedure into your muscle memory, and pick the distribution channel that matches how you track updates, since the Play Store, F-Droid, IzzyOnDroid and the GitHub release APK can carry different versions.

## FAQ

### What does De-Bloater need to work on my phone?

Root access and a fully functional Magisk, Kernel SU or APatch environment with module support. The project states that it will not work with other rooting solutions and not with Magisk in core-only mode.

### How does De-Bloater remove system apps?

It replaces the selected APKs systemlessly by generating a Magisk, Kernel SU or APatch module named De-bloater, so the system partition is never edited. The changes take effect after a reboot.

### How do I restore an app I removed with De-Bloater?

Use Reset Module from the top menu to remove the module and return the system to its original state, or restore individual packages from the second page of the application. Either way a restart is needed.

### What do I do if De-Bloater causes a bootloop?

Delete the /data/adb/modules/De-bloater directory through recovery, which removes the module and brings the original system packages back.

## Sources

- [License: GPL-3.0](https://github.com/sunilpaulmathew/De-Bloater/blob/master/LICENSE)
- [Project website](https://sunilpaulmathew.github.io/De-Bloater/)
- [README](https://github.com/sunilpaulmathew/De-Bloater/blob/master/README.md)
- [Releases](https://github.com/sunilpaulmathew/De-Bloater/releases)
- [sunilpaulmathew/De-Bloater on GitHub](https://github.com/sunilpaulmathew/De-Bloater)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sunilpaulmathew-de-bloater