By surfacing the UAD-ng maintainers' framing that the change is 'probably intentional' rather than a regression, the submitter aligns with the reading that Google deliberately closed the pm uninstall --user 0 path. The GitHub thread's growing consensus treats this as Android's security model catching up to a long-standing workaround, not a bug to be filed and fixed.
The editorial argues the second-order effects are worse than they appear because pm uninstall --user 0 was load-bearing plumbing for enterprise MDM providers stripping consumer apps from corporate devices, privacy-focused workflows, and seven years of accumulated debloating tooling. Framing it as 'another Android feature quietly disappears' understates the damage — UAD-ng's core code path is now broken with no workaround short of root.
The maintainers are telling users the tool's core code path is broken on Android 17 with no known workaround short of root. Their position, reflected in the issue thread, is that the reference implementation of consumer-grade Android debloating has been rendered non-functional by this change.
Users confirming the failure on Pixel 10 devices are converging on the acceptance that if you actually want to remove OEM bloat, carrier shims, or Facebook preloads, you now need to unlock the bootloader and root — the USB-cable-and-adb-script era is over. This position treats the change as a forcing function that pushes previously casual debloaters toward more invasive modifications.
An issue filed against the Universal Android Debloater Next Generation project (UAD-ng) — issue #1426, currently sitting at 184 points on Hacker News — documents a quiet but significant behavior change in Android 17: `adb shell pm uninstall --user 0
For context, `pm uninstall --user 0` has been the load-bearing incantation of the Android debloating world for roughly seven years. It doesn't actually delete the APK from `/system` — it can't, because that partition is read-only without root. Instead, it removes the package for user 0 (the primary user), which is functionally equivalent to uninstalling for anyone who isn't juggling multiple Android user profiles. Facebook, Bixby, Samsung's ad-serving Galaxy Store shims, carrier bloatware, OEM "AI assistants" — all of it could be nuked with a USB cable, `adb`, and a shell script. No root, no unlocked bootloader, no warranty voided.
Android 17 closes that loophole. The UAD-ng maintainers, who ship what is effectively the reference implementation of consumer-grade Android debloating, are now telling users that the tool's core code path is broken on the new OS and there is no known workaround short of root. The GitHub thread is a mix of confirmations from users on Pixel 10 devices, speculation about whether this is intentional hardening or a regression, and a growing acceptance that it's probably the former.
The surface reading is "another Android feature quietly disappears," but the second-order effects are worse than they look. `pm uninstall --user 0` was not just a hobbyist tool. It was the plumbing behind a surprising amount of real infrastructure.
Enterprise MDM providers use it to strip consumer apps off corporate-issued devices without full device wipes. Privacy-focused Android distributions that don't reflash the ROM — think the "lightly de-Googled" tier below GrapheneOS — rely on it. Custom device provisioning workflows for kiosks, point-of-sale hardware, and rugged industrial Android tablets use ADB scripts to remove Play Store, YouTube, and Chrome from fleets of thousands of devices. Every one of those workflows breaks the moment those devices get an Android 17 update.
There's also the OEM angle. Samsung, Xiaomi, and OnePlus have been steadily increasing pre-installed advertising and "suggested apps" for years. The debloat community was, in a very real sense, the pressure valve — the reason a technically inclined user could buy a $400 Galaxy A-series and still have a usable phone. Remove the pressure valve and the incentive gradient for OEMs to ship more bloat, not less, becomes almost pure upside for them. Google has plausible deniability here ("we're just tightening the security model") but the beneficiaries are the same OEMs who ship the ads.
The HN thread surfaces a few technical theories about what changed. The most credible is that Android 17's package installer now enforces a stricter check on whether a package is marked as a "system" app via its install flags, and refuses user-0 uninstalls for anything installed via the system image regardless of whether the caller has `DELETE_PACKAGES` shell permission. This is consistent with the trajectory Google has been on since Android 12: incrementally narrowing what `adb shell` can do without a full root/bootloader-unlock ceremony. `pm disable-user`, the softer cousin of `pm uninstall`, reportedly still works — but disabled apps still consume storage and can be re-enabled by an OTA.
What's notable is how little Google has said about this. There is no dedicated behavior-changes entry in the Android 17 developer documentation for this specific restriction. It shipped, apparently, as an implementation detail of the package manager rewrite. For a change that breaks a decade of tooling, community documentation, and enterprise scripts, the silence is loud.
If you maintain any of the following, you have work to do:
Device provisioning scripts. If your kiosk, POS, or field-service deployment relies on `pm uninstall --user 0` in a bash loop, test it against an Android 17 device today. If it fails, your options are: (a) require Android 16 as a minimum, (b) pivot to `pm disable-user` and accept the storage overhead, (c) move to Android Enterprise's Device Owner mode via a proper DPC (Device Policy Controller), which retains the ability to disable system apps at the framework level.
Consumer debloat tooling. UAD-ng, Debloater, ADB AppControl, and every YouTube tutorial from the last five years are now Android-16-and-below tools. Users buying new Pixels or the upcoming Samsung S26 lineup will find their scripts silently no-op. If you ship one of these tools, the honest move is a version bump with a big red banner: "Android 17 requires root."
Enterprise MDMs riding on shell permissions. Some MDM vendors, particularly in the BYOD space, have used `adb`-adjacent techniques to sidestep the full DPC provisioning ceremony. Those shortcuts are ending. The path forward is the officially blessed Android Management API and Device Owner enrollment — which is a heavier lift but was always the correct architecture.
Custom ROM adjacents. The gap between "stock Android with adjustments" and "custom ROM" just widened. Users who wanted a middle ground now have to pick a side: accept Google's shipping configuration, or commit to unlocking the bootloader and flashing something like GrapheneOS or LineageOS. There is no more middle.
This change fits a five-year pattern: Android is slowly becoming iOS in terms of what the device owner is allowed to do without cryptographic ceremony. Every release, one more debug affordance disappears. `pm uninstall --user 0` was overdue by that trajectory's logic. The realistic near-term response is a fork in the debloat community — a rewrite of UAD-ng and its peers around `pm disable-user` and the Android Enterprise APIs for the mainstream, and a hardening of GrapheneOS-style projects for the users who care enough to reflash. The middle ground, where a curious developer could reclaim a stock phone with a USB cable and a wiki page, is gone. Save your `pm uninstall` scripts as a historical artifact.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.