一条GitHub issue最近在非root安卓玩家圈里传开:开源工具Universal Android Debloater Next Generation(UAD-NG)的1426号issue标题写着,在非root的Android 17设备上,通过ADB卸载系统应用会直接失败。项目维护者的应对方式很干脆——把默认操作从"卸载"改成"停用"。这看起来像一次普通的软件更新,实际上是整个非root去臃肿工具生态,第一次集体撞上了系统权限的硬墙。

Reddit上已经有Pixel 8a用户反馈,YouTube、YouTube Music这类系统预装应用无法再被卸载,系统返回的报错是"只有root才能为特定用户删除系统应用"。这条限制目前被观察到的范围有限,还看不清是Android 17平台层面的通用改动,还是只针对Google自家几款系统包的定向收紧,官方也没有给出说明。

pm uninstall --user 0从来不是真卸载

非root用户能"卸载"预装应用,靠的从来不是真正删除系统分区里的文件,而是一条命令:pm uninstall --user 0 <package>。它做的事情其实是把应用从当前用户视图里隐藏掉,属于Android多用户模型下一个相对宽松的策略缺口。UAD、UAD-NG、Canta这些工具,本质上都是借助ADB或Shizuku拿到shell权限,反复调用这一条命令,才撑起了"不root也能精简系统"的产品体验。

这个缺口能开这么多年,本身就带点侥幸成分。Android每次版本迭代都在收紧包管理和权限模型,作用域存储、权限分级都是先例。这一次轮到系统应用卸载,只是时间问题。


Canta的"假成功"和UAD-NG的老实

限制一出现,同类工具的应对方式立刻拉开了差距。UAD-NG选择让报错老老实实冒出来,并把默认操作切到"停用"。另一款工具Canta处境更尴尬——它同样依赖ADB/非root版Shizuku,遇到限制之后,社区反馈显示它会误报"卸载成功",应用实际仍然留在设备里,这个问题在Canta项目里被记录为一个尚未解决的issue。

  • 风险.如果用户信了"卸载成功"的提示,以为隐私类应用已经清除,实际数据和进程可能仍在运行,这是比报错本身更值得警惕的问题。

这暴露了一个原文标题完全没有交代的维度:同样撞上系统限制,工具之间在透明度上的差距,直接决定了用户会不会被误导。

停用能不能顶替卸载

UAD-NG官方给出的退路是pm disable-user配合am force-stop,把应用停用并强制结束进程,而不是删除。这个方案能绕开权限报错,但代价也很明确:应用会继续显示为"已安装",只是标注为已停用,不像卸载那样从列表里彻底消失,而且部分应用有被系统重新启用的可能。

卸载 vs 停用:两种退路的实质差异 卸载 uninstall Android 17上报错失败 设置里彻底消失 释放存储空间 需要root才能保证成功 隐私隐蔽性更强 停用 disable-user 非root可执行,不报错 设置里仍显示已安装 不释放存储空间 部分应用可能被重新启用 后台唤醒情况尚不明确

对习惯用ADB或Shizuku深度精简系统的用户来说,这意味着精简效果打了折扣:省不了存储,列表里也不清爽,只是应用不再运行。想彻底清干净系统的人,现在基本只剩root一条路。

卸载键失灵不可怕,可怕的是有工具还在告诉你它成功了。

UAD-NG官方文档一直提醒,卸载系统包本身就可能带来更大的系统不稳定风险,这次的限制某种程度上反而把用户推向了一个更保守、但也更"安全"的操作方式。真正需要盯的,是Google会不会把这条限制从个别应用扩大到更大范围的系统包,以及Android后续正式版本会不会把这一变化写进官方说明——目前这两点都还没有答案。