How to Debloat Android Without Root Using ADB

Carrier-installed apps, OEM launchers, duplicate assistants, regional shopping apps - Android devices ship with a surprising number of packages you never asked for and cannot delete through the normal Settings menu. The good news: you do not need root, a custom recovery, or a full ROM flash to get rid of most of them. Android’s pm (package manager) command, accessed over ADB, lets you uninstall or disable system apps on a per-user basis. The operation is reversible, leaves the system partition untouched, and works on virtually every Android device running Android 5.0 or later.

This guide walks you through the entire process: setting up ADB, identifying packages worth removing, executing safe uninstall commands, and recovering from mistakes.

Prerequisites: What You Need Before Starting

Before touching a single package, make sure you have the following in place.

Hardware and software:

• A PC or Mac running Windows 10+, macOS 12+, or any modern Linux distribution
• A USB cable that supports data transfer (not charge-only)
• Android SDK Platform-Tools installed - download the standalone ZIP directly from the Android developer site rather than through Android Studio if you only need ADB

On your Android device:

1. Go to Settings > About phone and tap Build number seven times to unlock Developer options.
2. Open Settings > Developer options and enable USB debugging.
3. On Android 11 and later, also enable Wireless debugging if you prefer a cable-free workflow (optional).

Once Platform-Tools is extracted and your device is connected via USB, run:

adb devices

You should see a device serial number with status device. If it shows unauthorized, unlock your phone and accept the RSA fingerprint prompt.

For a broader overview of what ADB can do beyond debloating, see our guide on ADB commands every Android power user should know.

Understanding How Non-Root Uninstalls Work

Android’s multi-user architecture (introduced in Android 4.2) is what makes rootless debloating possible. System apps live on the read-only /system partition, but the package manager maintains per-user install state in /data. When you run:

adb shell pm uninstall -k --user 0 <package>

…you are telling Android to remove the package from user 0 (the device owner profile) while leaving the APK on the system partition intact. The -k flag preserves the app’s private data and cache directories on the device. The app vanishes from the launcher, loses the ability to run in the background, and cannot receive implicit broadcasts - but it is never truly deleted from the firmware.

This matters for two reasons:

1. Safety - a factory reset or OTA update can restore anything you remove.
2. Limits - a small number of packages cannot be removed even this way because Android will refuse the operation (it returns Exception occurred while executing 'uninstall': java.lang.IllegalArgumentException). These are deeply coupled framework components.

The alternative command, pm disable-user --user 0 <package>, does not remove the package from the user profile but marks it disabled. It is the more cautious choice when you are unsure about a package.

Finding Package Names

You need the exact package name (e.g. com.google.android.apps.tachyon) to act on an app. Three methods:

List all installed packages (includes system and OEM apps):

adb shell pm list packages

List only system and OEM packages:

adb shell pm list packages -s

List only user-installed (sideloaded or Play Store) packages:

adb shell pm list packages -3

Note: carrier and OEM bloatware ships as system packages, so it will not appear with -3. Use -s or no flag to see those.

Find a specific app by keyword:

adb shell pm list packages | grep -i "samsung"

Get the package name of an app currently open on screen:

adb shell dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'

Cross-reference unfamiliar package names against the Universal Android Debloater (UAD) database on GitHub, which classifies thousands of packages by manufacturer and risk level (Safe / Caution / Expert / Unsafe).

Safe Packages to Remove vs. Packages to Avoid

The table below lists commonly removable packages grouped by category, along with packages that are dangerous to touch. This is a representative sample - always verify for your specific device and Android version.

Category	Package example	Action	Risk
Carrier bloat (generic)	com.att.myatt, com.vzw.apnlib	Uninstall	Low
OEM assistant	com.samsung.android.bixby.agent	Uninstall	Low
Duplicate browser	com.sec.android.app.sbrowser	Uninstall	Low
Facebook system app	com.facebook.system, com.facebook.appmanager	Uninstall	Low
Google apps (non-core)	com.google.android.youtube, com.google.android.apps.youtube.music	Uninstall	Low
Google Play Services	com.google.android.gms	Do not touch	Critical
Settings app	com.android.settings	Do not touch	Critical
SystemUI	com.android.systemui	Do not touch	Critical
Telephony	com.android.phone	Do not touch	Critical
Package installer	com.google.android.packageinstaller	Do not touch	Critical

A general rule: if a package name contains settings, systemui, phonesky (Play Store), gms, or inputmethod, leave it alone unless you are certain of its function and have a replacement ready.

Running the Debloat Commands

Once you have your target package list, the workflow is straightforward.

Single package uninstall:

adb shell pm uninstall -k --user 0 com.samsung.android.bixby.agent

A successful operation returns Success. A failure returns an exception message - do not force it.

Batch uninstall with a shell script (Linux/macOS):

#!/bin/bash
PACKAGES=(
 "com.samsung.android.bixby.agent"
 "com.samsung.android.bixbyvision.framework"
 "com.facebook.appmanager"
 "com.facebook.system"
 "com.google.android.youtube"
)
for pkg in "${PACKAGES[@]}"; do
 echo "Removing $pkg..."
 adb shell pm uninstall -k --user 0 "$pkg"
done

Disable instead of uninstall (safer for uncertain packages):

adb shell pm disable-user --user 0 com.example.suspiciousapp

Restore a removed package:

adb shell cmd package install-existing com.samsung.android.bixby.agent

Re-enable a disabled package:

adb shell pm enable com.example.suspiciousapp

Save your uninstall script to a file. OTA updates and factory resets restore system packages, so you will likely need to re-run it after major Android version upgrades.

Privacy Implications: Why Debloating Matters

Pre-installed apps are not just annoyances - they represent a concrete privacy and security surface. Several documented cases illustrate the risk:

• Carrier-installed diagnostic apps have been shown to collect device telemetry and transmit it to third-party analytics endpoints without explicit user consent.
• Facebook’s com.facebook.system and com.facebook.appmanager packages, pre-installed on some Samsung devices, auto-install Facebook and Messenger and are resistant to standard user uninstall.
• OEM keyboard and assistant apps often request broad permissions (contacts, microphone, location) and may route input data through manufacturer servers.

Removing these packages eliminates the background service, the associated broadcast receivers, and any persistent permissions - reducing your attack surface at no cost to core functionality.

Debloating pairs well with other hardening steps. Our Android privacy hardening checklist covers permission audits, DNS-over-HTTPS configuration, and network-level controls that complement what ADB alone can achieve.

If you want to replace removed OEM apps with open-source alternatives, F-Droid vs. Play Store compares the two ecosystems and explains the trust model differences - useful context when rebuilding your app set after a debloat.

Limitations and When to Consider Going Further

ADB debloating has real limits. It cannot:

• Remove apps that are part of the read-only system image if the device refuses the pm uninstall command
• Prevent an OTA update from re-enabling packages it previously installed
• Modify SELinux policies or remove kernel-level telemetry present on some heavily customized OEM builds

For users who need deeper control - particularly on devices with aggressive OEM overlays or persistent carrier software - flashing a custom ROM is the next step. GrapheneOS (Pixel devices) and LineageOS (broad device support) both ship without Google Play Services pre-installed and give you full control over what runs on your device. See our GrapheneOS vs. LineageOS comparison for a detailed breakdown of the trade-offs.

ADB debloating is best understood as a practical middle ground: no bootloader unlock required, no warranty concerns in most cases, and reversible at any point. For the majority of users on stock Android who want to reduce background data collection and reclaim system resources, it is the most accessible tool available.

Quick Reference Cheat Sheet

Goal	Command
List all packages	adb shell pm list packages
List system/OEM packages	adb shell pm list packages -s
List user-installed packages	adb shell pm list packages -3
Uninstall for current user	adb shell pm uninstall -k --user 0 <pkg>
Disable (keep registered)	adb shell pm disable-user --user 0 <pkg>
Restore uninstalled package	adb shell cmd package install-existing <pkg>
Re-enable disabled package	adb shell pm enable <pkg>
Get foreground app package	adb shell dumpsys window windows | grep mCurrentFocus
Check package details	adb shell dumpsys package <pkg>

The commands above work on Android 5.0 through Android 15 with no modifications. On Android 12 and later, some OEMs restrict pm disable-user on a small set of packages tied to their attestation stack - if you hit a refusal, try pm uninstall -k --user 0 <pkg> instead, or accept that the package cannot be removed without a ROM change.

FAQ

Will removing system apps with ADB break my phone?

Not if you stick to known-safe packages. The operation only affects your user profile (user 0) and leaves the system partition untouched. Critically, never uninstall `com.google.android.gms` (Google Play Services), `com.android.systemui`, `com.android.settings`, or `com.android.phone` - removing any of these will render the device unusable until a factory reset. When in doubt, use `pm disable-user` instead of uninstall, which is fully reversible without a reset.

How do I restore an app I removed with ADB?

Run `adb shell cmd package install-existing <package-name>` to reinstall the package for user 0 from the copy still sitting on the system partition. If you used `pm disable-user` instead, re-enable it with `adb shell pm enable <package-name>`. A factory reset also restores every package you removed this way, since the system partition was never modified.

Does ADB debloating survive Android OTA updates?

No. A major OTA update or factory reset will restore system packages to their default installed state, effectively undoing your debloat. This is why saving your uninstall commands as a shell script is important - you can re-run it after each major upgrade. The silver lining is that this same behavior makes mistakes easy to undo.

Why does `pm list packages -3` not show my carrier or OEM apps?

The `-3` flag lists only packages that were installed by the user (sideloaded APKs, Play Store installs). Carrier and OEM bloatware ships as system packages on the `/system` partition, so it appears with `pm list packages -s` (system-only) or with no flag at all (which lists everything). Use `pm list packages | grep -i keyword` to find a specific OEM package by name.