Android Debloating Guide 2026

Three different debloat states with different reversibility. (1) **Disable** (Settings → Apps → app → Disable, OR adb shell pm disable-user --user 0 PACKAGE) — app stops running, no longer triggered by intents, doesn't appear in launcher. Storage NOT freed (APK still on /system). Reversible: re-enable in Settings or pm enable. Survives reboot. Doesn't survive factory reset. (2) **Per-user uninstall** (adb shell pm uninstall --user 0 PACKAGE) — app removed from user 0's app list; APK still on /system but not visible to user. Storage NOT freed (APK still on /system). Reversible: cmd package install-existing PACKAGE. Survives reboot and most factory resets. (3) **System uninstall** (root + Magisk Debloater OR rm /system/app/PACKAGE.apk OR Magisk module systemless-uninstall) — APK actually removed from /system. Storage freed. Reversible only by re-flashing stock firmware (or Magisk module that systemlessly removes-and-restores). The practical recommendation: start with per-user uninstall — sufficient for 95% of users; root system-uninstall only if you specifically need /system storage back.

No. ADB pm uninstall --user 0 works without root and is sufficient for most debloating goals. (1) Without root, you can per-user uninstall almost any package — apps no longer present from user perspective; freed RAM (no longer running); freed user-storage. APK remains on /system (unfreed) but invisible. (2) Root extends to system-level uninstall — APK actually removed from /system; freed /system storage. Useful if /system is full or you want completely-removed apps. (3) Without root, you cannot debloat: a small subset of system-critical packages that the OS blocks even from per-user uninstall (varies per OEM). With root, you can — but at risk if you remove the wrong critical package. (4) The decision: ADB-only debloat is the right default for most users — safer, sufficient, no root requirement. Root debloat is for users who already have root + need /system storage + understand the additional brick risk. (5) Recommendation: start ADB-only; consider root debloat only after specific need emerges (storage pressure, deep customization).

Generally safe (depending on your usage). (1) OEM browsers (Samsung Internet, Mi Browser, Vivo Browser) — if you use Chrome/Firefox/etc. (2) OEM stores/launchers (Galaxy Store, GetApps, Vivo App Store) — if you use Play Store. (3) OEM utilities you don't use (Samsung Notes, Samsung Calendar, Samsung Health if no Galaxy Watch). (4) Bixby / Vivo Assistant / Mi Voice / etc. — if you don't use them. (5) Pre-installed third-party (Facebook, Netflix, McAfee preloads) — almost always safe. (6) Carrier bloat (US T-Mobile/AT&T/Verizon-specific apps) — usually safe. UNSAFE — do NOT remove: (1) com.android.* — core Android packages (system, settings, phone, mms, vending). (2) com.google.android.gms — Google Mobile Services; banking, payments, many app integrations break. (3) com.google.android.gsf — Google Services Framework. (4) com.google.android.tts — Text-to-speech (can break accessibility). (5) System UI / launcher — if you remove launcher, no home screen. (6) Modem / phone / IMS packages — phone calls break. (7) com.samsung.android.app.smartcapture (Samsung) — surprisingly tied to volume keys on some firmware. (8) com.miui.system / com.android.systemui (MIUI) — system stability. The rule: remove what you confidently don't use; never remove what you don't recognize; UAD-ng's ‘Unsafe' tag is reliable.

Samsung-specific debloat targets and watch-outs. (1) **Bixby** — com.samsung.android.bixby.agent + com.samsung.android.bixby.service + com.samsung.android.bixby.wakeup + com.samsung.android.bixbyvision.framework — safe to disable/uninstall if you don't use Bixby. Reroute Bixby key to Google Assistant via Settings or BxActions app. (2) **Samsung Pay** — com.samsung.android.spay — only debloat if you don't use Samsung Pay. Often disabled anyway on rooted devices (Knox e-fuse trip = Samsung Pay disabled). (3) **Knox-related** — com.samsung.android.knox.* — multiple Knox packages; some safe to disable, some integral to system; treat with caution; on rooted Samsung many Knox packages are non-functional anyway. (4) **Samsung Health** — com.sec.android.app.shealth — safe to debloat if you don't use it. (5) **AR Emoji / Samsung Free / Samsung Members / Game Launcher** — safe to debloat for most users. (6) **Edge Panel** — com.samsung.android.app.cocktailbarservice — safe to debloat if you don't use Edge Panel feature. (7) **Watch out** — com.samsung.android.app.smartcapture — surprisingly tied to screen capture functionality. com.samsung.android.themecenter — safe but theme support breaks. com.samsung.android.app.routines (Bixby Routines) — safe to debloat. The Samsung debloat scope is wide — you can recover ~3-5 GB of user-storage by aggressive Samsung debloat without breaking core functionality.

Xiaomi-specific debloat targets and known telemetry packages. (1) **MSA (Mi Service Authorization)** — com.miui.msa.global / com.miui.systemAdSolution — known telemetry / ad-injection package; widely debloated by privacy-conscious users; safe to remove. (2) **Analytics** — com.miui.analytics — direct analytics/telemetry; safe to remove. (3) **Joyose** — com.xiaomi.joyose — gaming-related system service; controversial — some users report performance regressions after disabling on certain HyperOS versions; test before committing. Magisk module ‘Joyose Disabler' provides systemless approach. (4) **Mi Browser** — com.mi.globalbrowser — safe to remove if using Chrome/Firefox. (5) **GetApps** — com.xiaomi.mipicks — Mi Store; safe if using Play Store. (6) **Mi Music / Mi Video** — safe if using Spotify/YouTube/etc. (7) **Mi Calendar / Mi Notes / Mi Recorder** — safe if you have alternates. (8) **System ads** — Xiaomi has historically injected ads in stock apps (file manager, downloads, app vault, etc.); various Magisk modules + ADB debloat reduce or eliminate these. The Xiaomi-specific value of debloat is significant — recovers storage AND removes telemetry/ad-injection packages that other OEMs ship less aggressively.

Variable — depends on debloat method. (1) **ADB pm uninstall --user 0** — survives reboot. Survives most factory resets (per-user state preserved across factory reset of user 0 in many cases). Does NOT survive full system wipe + reinstall. Reversed by OTA updates that reinstall the package as part of system update. (2) **ADB pm disable-user** — survives reboot. Doesn't typically survive factory reset (factory reset re-enables disabled apps). Doesn't survive OTA. (3) **Root system-uninstall** — survives reboot. Doesn't survive factory reset (reset reflashes /system). Definitely doesn't survive OTA (OTA reflashes /system). (4) **Magisk systemless-uninstall module** — survives reboot. Module persists across factory reset of /data (modules are at /data/adb/modules but… actually they're wiped if /data wipes; nuance per setup). Doesn't survive OTA cleanly. (5) **Practical implication** — debloat is not a one-time operation. After OTA updates, expect to re-debloat. Document your debloat list (UAD-ng has export-list feature) to make re-applying after OTA fast. The honest reality: debloat-then-OTA cycle is part of life on aggressively-debloated devices.

Yes, ranked by safety: (1) **In-Settings disable** — Settings → Apps → select app → Disable. Available for many but not all OEM bloat. Trivially reversible. Lowest risk. (2) **Built-in app disable per OEM** — some OEMs (Xiaomi, Samsung) provide their own ‘Disable' option within app settings; same effect as Android's standard disable. (3) **Hide via launcher** — apps still installed but hidden from launcher view (Nova Launcher, etc.). No system-level effect; just visual. (4) **Universal Android Debloater (UAD-ng)** — ADB pm uninstall --user 0 with categorized package list and safe-tag system. Safer than raw ADB because of community vetting per package. (5) **Raw ADB pm uninstall --user 0** — direct command; powerful; requires you to identify safe-vs-unsafe yourself. (6) **Root + Magisk Debloater module** — system-level removal; most aggressive; highest brick risk; recommended only for experienced users. (7) **Custom ROM (LineageOS)** — replaces entire OS without OEM bloat; nuclear option; loses OEM features (Samsung Pay, OneUI gestures) entirely. The right ladder: try in-Settings disable first → escalate to UAD-ng if Settings doesn't allow → escalate to root only for specific storage-recovery needs → consider custom ROM only if OEM bloat is intolerable across the board.