Checking browser support…
Strip preloaded apps off an Android phone over USB — rated, reversible, and without rooting anything.
The package list is read from the phone over the USB cable and stays in this browser. Nothing about which apps you have is uploaded.
Checking browser support…
Plug an Android phone into a Chromium browser over USB and this page lists every package on it: name, system or third-party, enabled, disabled or already removed, version, who installed it, and how much space it occupies. Each row is matched against a curated safety database that says what the package does, what stops working without it, and on what basis it is rated — an AOSP source path, a Play Store listing, a stated platform role. Nothing is installed on the phone and nothing is uploaded; the lists are produced by pm list packages on the device and read back over the cable.
pm uninstall --user 0 actually doesIt does not delete anything. A preloaded app lives on the read-only system partition and cannot be erased without root; what the command removes is the *record* that the app is installed for user 0 — you, the phone's owner. The APK stays exactly where it was, which is why cmd package install-existing --user 0 <package> puts the app straight back with no download and no store account. Adding -k keeps the app's data behind as well, so a restore lands you where you were rather than at a fresh install. This is the whole trick behind rootless debloating: the space is not reclaimed (the APK is still there), but the app stops running, stops updating, stops appearing and stops using battery. pm disable-user --user 0 is the gentler version — the app stays installed and simply stops — and it is the move to reach for first, because pm enable undoes it with certainty.
Packages are rated recommended (advertising, telemetry, a preloaded consumer app — removing it costs the app and nothing else), advanced (a vendor service with real side effects), expert (something people rely on breaks — printing, file pickers, SMS, accessibility) and unsafe (removing it soft-bricks the phone or destroys data). Rows in the last tier stay locked shut until you open one and unlock it deliberately. A small set is never removable from this page at all — SystemUI, Settings, the shell package, the package installer, the permission controller, telephony, the keyboard, Play services — chosen by one test that is not severity: after this goes wrong, could you still repair the device? Everything else is reported as **unknown**, and unknown is treated as *more* dangerous than every rated tier, not less. It means nobody could write one checkable sentence about the package, so it draws in the alarm colour, sorts to the far end of the list, and is never picked up by a bulk selection. A missing row is an inconvenience; a wrongly confident recommended is somebody's phone.
Every warning- and danger-level action from these pages is written into a restore centre in this browser, together with the command that reverses it, and one button runs that command on the connected phone. The undo is *derived* from what the operation was, never supplied by the page that performed it, so nothing can display an antidote that does not exist. Above that, a permanent rescue block prints the same commands in their desktop adb shell form, for the case this page cannot help with — a phone that no longer shows a usable screen. That case is real: remove the wrong package and you can land on a black screen or a boot loop, with no way to approve USB debugging from a new computer because the prompt is drawn by SystemUI. The only route out of that is a factory reset from recovery, which erases everything on the device. The page says so where the buttons are, not in a footnote.
Selections travel: tick the packages you want gone, download the list as JSON, and drop it onto the next phone. The file carries package names and nothing else — no ratings, no commands — so importing one can never introduce an instruction this page did not build itself, and the summary tells you plainly how many of its entries this device actually has. Coming from the other direction: the Web ADB Toolkit hub has the device dashboard and the rest of the tools, and the Storage Analyzer shows what is eating the phone's space before you decide what to remove.
Android supports multiple users, and `0` is the primary one — the owner of the phone. The flag scopes the uninstall to that user instead of the whole device, which is what makes it possible without root: the APK on the system partition is untouched, only the record that it is installed for you is removed. That is also why it is reversible with `cmd package install-existing --user 0 <package>`. Without the flag, `pm uninstall` would try to remove the package for every user and a system app will simply refuse.
Root deletes the APK from `/system` and frees the space; `--user 0` leaves the APK there and only hides it from you. The practical differences are: rootless removal reclaims no storage, survives no factory reset (everything comes back), and is undone by one command — while root removal is permanent, frees real space, and can break OTA updates because the system partition no longer matches what the update expects. For getting rid of preloads you do not want, rootless is the safer trade in almost every case.
Often, yes. A system update may reinstate packages for your user, and a factory reset always does, because the APKs were never deleted. Sideloaded and store-installed apps are a different matter. Nothing here is permanent by design, which is the same property that makes it safe: keep your exported selection profile and re-apply it after a big update rather than expecting the removal to stick forever.
Using ADB does not modify the system partition, does not unlock the bootloader and does not trip Knox or any similar flag — these commands are part of Android's own shell tooling and are reversible from the phone itself. That is not legal advice, and a manufacturer can still argue about a device that misbehaves; but nothing on this page writes to a partition, and a factory reset returns the phone to exactly the state it shipped in.
Yes, and the page is built around that fact. Removing SystemUI, the keyboard, the settings app or Play services can leave a device with no interface, no way to type a password and no way to approve USB debugging from another computer — a state only a factory reset clears, losing everything on it. That specific set is blocked outright here and cannot be selected even from an imported profile. Everything else that can do real damage is rated unsafe and locked until you open the row and unlock it. Disable before you uninstall: `pm disable-user` is reversible with certainty.
Chrome or Edge on a desktop, because WebUSB is Chromium-only; Firefox and Safari cannot open a USB device at all. The phone needs USB debugging turned on in Developer options, and on Windows its ADB interface usually needs the WinUSB driver installed with Zadig — the page walks you through that if connecting fails. macOS, Linux and ChromeOS need no driver.
The device dashboard and the rest of the ADB tools.
Find what is eating the phone's storage before you decide what to remove.