HN Debrief

On non-rooted Android 17, ADB uninstall of system apps fails

  • Mobile
  • Privacy
  • Open Source
  • Security
  • Regulation

The linked GitHub issue says Android 17 changed how non-rooted ADB handles system apps. For years, users could run commands that looked like an uninstall for the current user, mainly to get rid of carrier and manufacturer bloat without rooting the phone. The claim here is that on Android 17 this no longer works for system apps. Instead of removing the app for that user, Android now disables it or falls back to the copy baked into the system image. That matters less for storage than many people assumed, because the app was never truly removed from the read-only system partition in the first place. The practical loss is control over preloads, updates, visibility, and in some cases background behavior.

If you rely on ADB debloating for OEM phones, test your workflow against Android 17 now and assume tooling built on ADB or Shizuku may lose the same capability. More broadly, treat stock Android as a shrinking target for user control and decide whether your answer is custom ROMs, rooted builds, or accepting a disable-only model.

Discussion mood

Mostly negative and resigned. People read the change as another deliberate reduction in user control on Android, even if several technically minded commenters argued the old ADB "uninstall" never truly removed system apps and disable still covers many real use cases.

Key insights

  1. 01

    Minimalist phone workflows mostly survive

    For people using ADB debloating to turn a smartphone into a boring tool, the immediate damage is smaller than the headline suggests. Several comments point out that disable still works for many stock apps, so distraction-free setups can usually be preserved without needing true uninstall. The loss is annoying, but it does not instantly force a jump to Light Phone or a custom ROM for everyone.

    Before rewriting your device strategy, try rebuilding your setup with disable-only tools on a spare phone or test device. You may keep 80 to 90 percent of the benefit without root, but you should document which apps come back after updates or reboots.

      Attribution:
    • tstactplsignore #1
    • pid0x17 #1
    • ChocolateGod #1
    • charcircuit #1
  2. 02

    ADB never removed the system copy

    The important technical correction is that non-rooted ADB was not deleting system apps from the read-only partition. It removed the user-installed or updated instance in /data, which often just exposed the older copy shipped in /system if that version number won. That means the storage savings and permanence many users thought they were getting were partly illusory all along.

    If your goal is reclaiming storage or permanently erasing OEM software, assume non-rooted ADB was never the right primitive. Use it for user-level hygiene, not for guarantees about what is really gone from the device.

      Attribution:
    • dugite-code #1
    • charcircuit #1
  3. 03

    Shizuku tools depend on the same door

    A lot of popular debloat tooling is not an escape hatch from this change. Shizuku and apps built on top of it borrow ADB-level privileges, so if Android 17 closes the uninstall path for non-rooted ADB, those tools likely lose it too. That makes this less about one shell command and more about an ecosystem of convenience layers that may all break together.

    Audit any internal guides or support docs that recommend Shizuku, Canta, or similar tools as if they were independent of ADB. If your process depends on them, verify behavior on Android 17 devices before promising users a workaround.

      Attribution:
    • Markoff #1
    • solnyshok #1
    • throw-the-towel #1
  4. 04

    Linux phones still fail on power and trust

    The reason phone users remain trapped in Android is not just app count. Commenters laid out two deeper blockers. First, ordinary Linux stacks still struggle with battery life, modem integration, graphics, and mobile-style app lifecycle management because vendors only do the hard platform work for Android. Second, even a technically solid Linux phone would still lose access to many banking and identity apps because Play Integrity and hardware-backed attestation bind trust to certified Android environments. Containers help with compatibility, but they do not beat hardware attestation.

    Do not plan around a near-term switch to generic Linux phones if your users need mainstream finance, identity, or enterprise apps. For now, Linux-on-phone remains a niche path for people willing to trade reliability and app acceptance for control.

      Attribution:
    • jeroenhd #1
    • Telaneo #1
    • bilkow #1
    • lucianbr #1
    • achierius #1
    • zekica #1
  5. 05

    GrapheneOS trades root for app trust

    The strongest defense of GrapheneOS was not that root is impossible, but that refusing to ship it by default is what keeps the platform credible to security-sensitive apps and to users carrying highly sensitive personal data. Commenters argued that broad root access changes the whole isolation model, while narrower features like scoped storage, contact scopes, Seedvault backups, and sensors permissions solve many user-control problems without opening a generic privilege escalation path. That is a different philosophy from ownership maximalism, but it is coherent.

    If you are evaluating Android alternatives for staff or customers, separate "can advanced users patch in root" from "what should the default security model be." The right answer depends on whether your priority is modifiability or getting privacy improvements without losing app compatibility.

      Attribution:
    • justonenote #1
    • Cider9986 #1
    • impure-aqua #1 #2

Against the grain

  1. 01

    This is not a sovereignty crisis

    One line of pushback rejected the grand political framing entirely. The claim is that Europe does not lack general-purpose computing hardware, and a bootloader-unlockable Pixel or devices like Fairphone already let technical users run what they want within normal security limits. From that view, consumers choosing managed appliances is not the same thing as a state losing sovereignty.

    Be careful about jumping from a frustrating product restriction to a sweeping geopolitical diagnosis. If you are making policy or strategy arguments, separate hardware availability, firmware openness, and mainstream consumer preference instead of treating them as one issue.

      Attribution:
    • yorwba #1 #2
    • rerdavies #1
  2. 02

    Attestation has real user-side value

    Not everyone bought the idea that device attestation only serves platform owners. Several comments argued it enables useful security properties for ordinary users, such as keeping private keys in secure hardware, protecting tokens, and building trustworthy local verification tools like GrapheneOS's own Attestation app. That does not erase the way app stores and banks use attestation to exclude alternative systems, but it does mean the primitive itself is not purely anti-user.

    When you critique attestation, target the policy layer and gatekeeping uses, not just the cryptographic mechanism. There is room for open implementations that preserve some of the security benefits without handing all trust decisions to Google or Apple.

      Attribution:
    • Cider9986 #1
    • Elfener #1
    • gruez #1
    • hparadiz #1

In plain english

ADB ↩
Android Debug Bridge, a command-line tool that lets a computer send commands to an Android device for debugging, app installation, and system management.
GrapheneOS ↩
A privacy- and security-focused Android-based operating system that runs mainly on Google Pixel phones.
hardware-backed attestation ↩
A way for a device to prove its identity and software state using cryptographic keys stored in secure hardware.
OEM ↩
Original equipment manufacturer, the company that makes a phone or ships its customized version of Android.
Play Integrity ↩
A Google system that lets apps check whether they are running on a device and operating system that Google considers genuine and trustworthy.
postmarketOS ↩
A Linux-based mobile operating system project that aims to bring long-lived, open software stacks to phones.
ROM ↩
Read-Only Memory, storage that is written rarely or not at all during normal operation.
root ↩
Administrator-level access that gives a user or program full control over the operating system.
SailfishOS ↩
A Linux-based mobile operating system developed by Jolla as an alternative to Android and iPhone software.
Seedvault ↩
An Android backup tool used by some privacy-focused systems to back up app data without requiring root access.
Shizuku ↩
An Android tool that lets apps perform certain privileged actions by using permissions granted through ADB.

Reference links

Android issue and policy references

Custom ROMs and Android alternatives

Debloating and privacy tools

Talks and advocacy