Why ShiroSU
为什么选择 ShiroSU？
Android 作为一个操作系统，有个核心特点是生态开放，可以自由地安装应用，Android 本身也有着较为丰富的系统机制
不过谷歌在近年来却逐步将这开放的生态拉向封闭，对于大部分使用场景这的确会更加安全，但也无疑给玩机增加了不少难度
为何玩机
原生 Android 虽然系统机制丰富，但是在功能上也无疑是实实在在的毛坯房，很多常用的功能可能只在各家的客制化系统上才有
不过就算是用上了类原生或者客制化系统，用着有些不如意也是难免的，为了使用体验更好，自然就要折腾折腾自己的系统，也就是玩机了
如何玩机
每个人玩机的目的可能各不相同，但是需求大抵都是一致的，那就是缺什么补什么，或者不要什么就去掉什么
例如在 iOS 的灵动岛设计刚推出时，在 Android 上最先可用的不是哪一家的客制化系统，而是第三方应用
这些应用通过全局悬浮窗来实现灵动岛功能，不需要嵌入到系统或者有系统权限，只需要通过系统提供的 API 就能够实现完整功能，只需要授予系统允许范围内的权限就能运行
或者如果想去掉一些广告，则可以用跳广告应用通过无障碍权限来模拟点击开屏广告上的 ✕，省掉了手点这个步骤
也可以用本地代理应用通过 VPN 服务来屏蔽部分已知的广告域名，使应用无法加载广告资源，且无需修改系统的 /system/etc/hosts
当需要让应用获得更加丰富的功能时，也可以通过免 root Xposed 框架加载模块来实现
像这样通过各种应用就能满足各种需求，就是得益于 Android 的开放性
其系统除了与硬件交互、与 Linux 内核交互等底层逻辑外，大部分功能都是通过这样的一个个应用实现的，例如同时用于控制状态栏、控制中心等关键界面显示的系统界面
但是提供各种功能的应用再多，也没办法完全覆盖到所有需求
例如要禁用用不到但持续运行的系统应用来节约运行内存占用，或者不需要系统应用提供的功能，这显然是普通应用所无能为力的事情
这时候只能再从其他地方上看，Android 在这方面有两个较为方便的渠道：ADB 与 DeviceOwner
有了 ADB 或 DeviceOwner 权限之后，就能很方便地禁用掉系统应用了
不过通常不必卸载它们，因为系统应用的安装包往往位于只读的系统分区内，卸载后只是从应用列表中移除，并不会释放掉其占用的存储空间
更因为存储分区与系统分区都是单独的分区，就算真的释放掉了系统分区内的空间，也无法增加实际可用的存储空间
不过系统应用在更新后（通过应用商店等渠道更新而非直接更新系统），会在存储空间内新增新的安装包，并且系统应用在运行时也会产生一些数据
这时候可以用卸载更新功能来卸载掉存储空间内的安装包，此时才会真的释放可用的存储空间
并且卸载更新本身不会将系统应用从应用列表中移除，只是将其恢复至初始状态，无需重新安装
从这里就可以看出如果想要更好地玩机，想要更彻底地去折腾，就需要越来越高的权限，越低的权限只会遇到越多问题
例如使用特定应用会被环境检测严格的应用所检测，使用无障碍服务、VPN 服务由于 Android 系统机制，也都可以被其他应用检测到，又或是使用免 root Xposed 框架导致的完整性检测或是性能问题等
为了更好地去使用，例如隐藏掉这些应用或是服务，或是用更高的权限直接运行程序来省掉与 Android 交互的过程，最终的权限就是 Linux 中最高的权限：root
权限深池
root 权限很多时候可能会被视为破坏系统或者偷窃数据的威胁，抛掉刻板印象，实际上本以为较低的权限也有可能会做到这些
- 如果给应用授予文件管理权限，那么它就可以读取到设备上大部分的用户文件，包括文档、图片、视频等
- 如果给应用授予无障碍与自启动权限，那么它就可以通过全屏覆盖等方式阻止操控设备，重启后仍然会继续锁机
- 在使用 ADB 或 DeviceOwner 时如果禁用了关键的系统应用，就会导致系统启动失败或者系统功能异常
所以问题的来源无非就是两个：应用滥权 和 错误操作
如果应用开发者铁了心地要违法犯罪，那么就算不给应用任何权限，也会尝试通过系统漏洞越权提权
如果自己什么都不会也要铁了心地折腾，那么任何一个行为都有导致系统崩溃的风险
也就是说问题在于自己如何用与用的东西如何跑，无论是常规权限、ADB 或 DeviceOwner 权限，以及 root 权限，使用不当都会造成严重后果
只不过 root 权限能造成的后果更加严重，但不代表其他权限能造成的后果就会轻微
在玩机时不具备相关的知识或者不对风险操作加以确认，就很可能深陷这泥潭
深入玩机
root 作为最高的权限，想要获取自然会比前面所说的低权限要更复杂些，常规的方法就是解锁 BootLoader 后往 init_boot/boot 注入 root 实现
不过由于 Linux 内核已经是千疮百孔，并且厂商漏洞与泄露文件也已是并不少见，在现代设备上获得 root 权限往往可以非常规
在获得 root 权限后，能干的自然会更多
例如前面所说的本地代理，可以转为通过 bind mount 或 overlayfs 无需修改系统分区地挂载 /system/etc/hosts，或是通过 TUN 用虚拟网卡来实现透明代理，无需再经过 Android 的 VPN 服务
诸如此类的事情还有很多，例如通过挂载来获得更多系统功能，用完整 Xposed 框架来更自由地加载模块，以及使用更多 Linux 的底层功能等
总的来讲可以让环境被隐藏，或是功能更底层，对整个系统的操控能力会大大增强
权力的双刃剑
能干的越多，能干出祸来的自然也更多，给应用授予 root，以及运行脚本或是可执行文件，在不知用途不知逻辑的情况下，都有可能造成数据丢失或是系统损坏
为何 ShiroSU
ShiroSU 作为一个系列项目，以系列中的各个项目围绕着玩机而提供不同方面的独特体验，在用什么 root、如何用 root 等问题上都能给出较好的答案
ShiroSU 的 root 主线持续围绕着 root 相关内容而开发，其他项目在不同领域上也有着不同的建树，可在主页中查看
当在选择 root 实现时，可将目光放在 ShiroSU NT 上，它作为纯用户态 root 实现它提供了更好的兼容性与更低的侵入性，能在支持的设备上基本都能提供较好的使用体验
当已有 root 时，也可将目光放在 ShiroSU Compat 上，它作为支持多种 root 实现的 root 管理器，在不同 root 实现间都能提供一致的使用体验
ShiroSU NT
ShiroSU NT 对于常规设备，采用替换 ramdisk init 的方式进行注入
它对系统的启动流程基本没有过多干预，只会在系统加载 SELinux 规则时一并注入它所需的规则，并在系统启动时一并启动后端服务
得益于 ShiroSU NT 的低侵入性实现，它在 SELinux 宽容的设备或是模拟器及虚拟机上也能够正常启动
在安装 ShiroSU NT 后，即可通过在线的网页管理器进行使用，无需实体管理器应用，只需要以浏览器作为媒介
后端服务会以设备序列号为默认密码，确保了在默认情况下的安全性，不过在开始使用后也应当及时更换为强密码
并且使用网页管理器管理本质上只是用静态网页连接设备后端，两者间的交互无其他中间参与，与其他 root 实现安装管理器应用类似
通过局域网或者 ADB 端口转发等方式，也可以在其他设备上管理 root，不仅仅局限于本机操作
ShiroSU NT 的后端默认会监听局域网，如果在公共网络中使用设备，应当将后端配置改为仅监听本地
不过通过其他设备管理也仍然需要密码校验，但只在私人网络内进行局域网互联是确保设备安全的行为
ShiroSU NT 在低侵入性的基础上还做到了高隐蔽性，作为白名单类型的 root 实现，不会泄露任何自身的挂载
在纯用户态实现的情况下也能做到规避普通应用的 SELinux 探测等
ShiroSU NT 自带的隐藏功能也可以为黑名单应用卸载挂载，并在其运行期间暂时关闭后端端口来避免端口扫描
并且 ShiroSU NT 的整体实现趋于插件化，让它并不一定需要作为一个完整 root 实现来运行，它可以作为润滑剂来增强 root 生态
并且作为纯用户态 root 实现，ShiroSU NT 并不与内核层逻辑冲突，在使用 ShiroSU NT 时同样也可以静态修改内核或是动态加载内核模块
AI 适配
ShiroSU NT 采用网页管理器作为管理媒介，网页本身就是有利于 AI Agent 通过工具转换或视觉查看的，再加上 MCP 工具之类的功能，能够很好地让 AI Agent 辅助使用
再加上后端本身通过 RESTful API 设计实现，可以很好地用于网络交互，使得无论是在前端交互还是后端交互上，ShiroSU NT 都有着优秀表现
AI 风险
AI Agent 应当仅用于辅助判断之类的简单操作，让 AI Agent 完全控制设备的风险不言而喻
ShiroSU Compat
ShiroSU Compat 针对多种 root 实现的权能与模块管理进行了适配，使得在不同 root 实现间都能通过 ShiroSU Compat 一个管理器进行管理
它提供了包括权能与模块管理在内的 root 管理功能，以及更多基于 root 实现的增强功能，在 root 管理器的基础上有着更多独特体验
它在一些实现上有着与 ShiroSU NT 一致的标准，使得在其他 root 实现上也能体验到这些内容
如果...
在以后 Android root 生态有可能更加开放，也可能会更加封闭，但 ShiroSU 将持续推进提供现代化的 root 使用方案，助力 Android 使用体验提升