这次 OTA 翻车后,我开始思考退烧这件事

Cover Image

正如在 Twitter 上所透露的,我尝试保留 Magisk 从氧 OS 10 更新至氧 OS 11 的时候翻车了。由于已经几次保留 Magisk 更新成功,所以这次没有太在意直接就更大版本,不幸陷入 bootloop 无法进入系统,使用 fastboot 退回原分区(手机支持 A/B 分区)也同样无法进入系统。刷之前也没有解密 Data 分区,导致 TWRP 无法挂载 Data 分区。两天内都没有找到什么好方法,只好格式化 Data 分区一切重来了。

刷入氧 OS 11 全量包后我没急着 Root,先看看能不能进系统再说。嗯,这次倒是没问题。但看着现在的白板 Android,我突然有个问题——如今我还非要 Root 不可吗?如果没有 Magisk 我还能舒舒服服地用 Android 吗?

怎么想要「退烧」啦?

说实话,到这一步并非一蹴而就的。

一开始,手机到手里就解锁 Bootloader、装第三方 Recovery、刷类原生 ROM、装谷歌服务框架、装 Magisk(Root)、装 Xposed……开机后还折腾模块、折腾启动器、美化、后台管理、权限管理等等等等,心血来潮的话可以搞上好几天。

后来,领教了一番第三方类原生系统的不稳定,在一些关键点上是真的难受。想要稳定一点的诸如 LineageOS 适配又慢。嘛,毕竟大多是社区贡献的,怎能奢求又稳定更新又迅速呢。我渐渐放弃上 XDA 找 ROM,用回还算贴近原生且自带谷歌框架的氧 OS,最多再装个 Magisk 就完事。

而这次,甚至连 Magisk 都不想碰了。不过这样,真的还能好好用 Android 吗?先说结论——现在不行,但至少还有机会。

Root 后得到的

只要能解锁 Bootloader,其实 Root 还蛮简单的。九成的劝退 Android 玩家不是不会操作,而是连 Bootloader 都不被允许解锁,这在许多中国大陆的设备制造商中十分常见。这里不过多讨论,我只列举 Root 后得到了哪些重要的功能,以及它们在非 Root 条件下如何替代、完成度如何。

Swift Backup —— 备份工具

很遗憾,我目前用过的两款备份工具——钛备份和 Swift Backup 都没有非 Root 模式。而许多非 Root 备份工具由于权限卡得太死,能做的实在太少,有点鸡肋。备份这一点无 Root 还是吃了不少亏。

Swift Backup 也在他们的 文档 FAQ 中 提到:App 在没有 Root 权限时无法获取其他 App 的数据文件夹,而 Android 11 还进一步限制了 App 对外部储存空间的访问权限。

非要说一款,可能还是 Helium 可以摆上台面。局限在于要连接电脑,无法自动备份并上传云端,而出事往往是意想不到的时候,等出事后再想起备份可能就迟了。关于这一点也有评论抱怨,不过非 Root 有所限制很正常,Helium 已经做得不错了(如果你能忍受他的界面的话)

Helium 应用截图

图片来源

正当我失落之时,系统消息突然询问我是从旧设备恢复数据还是从云端恢复数据。云端?哦对了,如果你能用上谷歌服务,其自带备份功能可能就是最好用的非 Root 安卓备份工具。通话记录、通讯录、信息、应用数据、甚至系统设置都能帮你自动备份至云端,不可谓不是无微不至(几层否定了啊喂)。当然,非 Google 开发的应用的设置和数据的备份行为需要开发者自己规定,就别对某绿色国民级通讯应用抱有任何期待了。

Google Android 备份

至于设备厂商自己的备份方案就不提了,这种基本一定要与厂商定制化系统绑定的方案没什么参考意义,除非你一直打算用那一家的设备且不更换系统。

绿色守护 —— 后台管理

毕竟身处这个环境,还是摆脱不开某些应用的魔爪。尽管不得不用,还是希望它们能够安分点。由于众所周知的原因,许多大陆 App 并没有适配 FCM 推送。而手机不想电脑,有些信息就是需要立马知晓或回复的,不然没有意义。为了用户能及时收到推送,App 需要时不时挂起进程查看有没有信息。一些通讯 App 也就算了,可是一旦有一个 App 挂起,其他 App 也争相挂起进程,推送一堆垃圾博眼球的内容,把你的可怜的精力又吸走一份。

类原生 ROM 大多是国外社区主力维护,没有体会过这边混乱的经历,ROM 也往往对这些行为放任不管或打击力度不够。在 Root 的时候我习惯用 绿色守护 管住某些流氓行为,在程序进入后台或者息屏一段时间后开始介入,防止它们偷偷运行。至于担心消息不及时的:

  1. FCM 直接推送不受影响
  2. FCM 挂起程序进行推送的,试验性特性中也可以选择放行这部分启动

如果没有 Root,绿色守护也有 ADB 启动方式。不过这种情况下其实更推荐使用 黑域 了,黑域主打非 Root 管理后台。

然而,Android 9 加入的「应用限制(Restrict app)」功能会让系统强制忽略该应用的后台运行等相关服务(仍能 FCM 推送),Android 9 更新的待机机制也让这一从 Android 6 便加入的功能不再鸡肋。

系统 应用限制

图片引用自 少数派

后台管理这一点,有无 Root 其实差距不大。希望终有一天,我们不需要刻意管理后台,也本应如此。

App Ops —— 权限管理

「不给权限不让用」是个老生常谈的问题了,除了干坏事我实在无法理解一个计算器 App 要通讯录权限干什么。如果遇到刚在备忘录里记下某些内容,晚上网购 App 就给你推相关商品的话,很可能就有流氓 App 在后台监控剪贴板并上传分析。

既然「不给权限不让用」,那就每次返回空的权限信息让应用拿了个寂寞。App Ops 不仅能管理系统向用户提供的常见权限(如 位置相机 等),还能管理系统没有开放给用户操作的权限(如剪贴板权限)。

App Ops 通过 Shizuku 框架启动,而 Shizuku 提供了 Root、ADB、无线调试(Android 11 新增)3 种启动方式。对有无 Root 的用户都比较友好,如果升级到 Android 11 还能 通过无线调试使用,甚至不需要连接电脑。

所以,在使用 App Ops 管理权限时,有无 Root 体验都不错。真要说 Root 独有优势好像也只有「剪贴板监视」了?

App Ops 剪贴板监视

好吧,这个真挺好用的,也算是大损失。

需要注意的是,近几年,特别是 Android 9 至 11 这几年,Android 愈发重视隐私保护,一次又一次把权限管理拿上来讲。权限不再是「开」或「关」这么简单,有了「仅前台时允许」、「仅允许这一次」等等。还是拿剪贴板说事,Android 10 以上默认仅前台应用可以获取剪贴板内容。或许真有一天,权限不再是我们该操心的了。

Storage Redirect —— 存储管理

按理来说,Google 是有规定 App 数据应该存放的文件夹的。但是大多中国大陆应用不经 Play Store 发行,也就无需经过 Google 审查。存储权限只有授予或不授予两种选项,一旦授予就可以读写所有文件夹。有时候只是为了发图片不得不授予应用存储权限,有些应用就滥用权限随意往用户目录写入一些文件,导致用户目录混乱不堪。更有甚者以此存放用户标识与其他获取了存储权限的 App 共享,侵犯用户隐私。

而存储空间隔离通过欺骗应用,让应用以为访问了用户目录,实际上只是访问了应用文件夹下的 sdcard 目录罢了。而通过软链接只给应用需要的文件夹指路(如媒体文件夹 DCIMPictures 让应用发图片),达到「最小化权限」原则。

可惜的是,这么好的 App,只支持 Root 运行,非 Root 设备完全用不了。

但好消息是,Android「沙盒」机制早有风声走漏。如果实现了,那相当于存储空间隔离系统化支持,还加赠该特性下好用的接口。先别高兴太早,这是本该在 Android 10 引入的特性,结果由于兼容性问题没能上线正式版;又预告 Android 11 会优化完善上线,结果还是没有;现在 Android 12 测试中都也没有落地……不过无论如何,至少有向这边的势头了,我们也能有所期待。

Root 并非没有缺点。譬如放弃保修;OTA 变麻烦,每次还要手动介入在新分区装 Magisk,不能自动更新;DRM 等级 L1 解锁变 L3,无法在 Netflix 上观看高清内容……

但就像开头说的那样,至少现在而言,我还是会去 Root,还是无法接受没有 Magisk 的 Android。

我不善言辞,不太会总结。这里想借用 Fairyex 老师在「在 2019 年,Root 是否还有必要?」中的结尾:

Root 不是万能神药,Root 也不是洪水猛兽。它只是我们实现需求道路上的其中一个必备条件,所以即使到现在在我看来 Root 还是十分有必要,厂商定制系统各式各样,但他们魔改的地方却并不全是大家喜欢的(比如为了性能牺牲续航和阉割辅助功能),对于普通手机用户而言,只要能够保证安全的前提下能改掉手机上不喜欢的地方,那么相信大部人都愿意去 Root。

即便是两年前写下的,放在现在也没什么问题。Root 对我来说还是必要的,只不过这次更新翻车的经历,让我认识到 Root 对我真正意义何在。现如今能超越那篇文章的,便是我清楚了何时是 Root 对于我而言不必要之时——当非 Root 备份足够成熟、当 Android 沙盒机制落地之时。

这次 OTA 翻车后,我开始思考退烧这件事
本文作者
ChrAlpha
最后更新
2021-05-04
许可协议
转载或引用本文时请遵守许可协议,注明出处、不得用于商业用途!

评论

您所在的地区可能无法访问 Disqus 评论系统,请切换网络环境再尝试。