原生特性开发​

对于大部分内容，ShiroSU 与Magisk和KernelSU基本保持一致，此处仅介绍不同之处

模块系统​

Systemless^[1]​

ShiroSU 的 Systemless 是一种类似于 Magisk 的挂载机制，其接口完全兼容 Magisk，例如.replace用法， 但 ShiroSU 的挂载机制兼容性更强，是基于动态识别分区实现的， 也就是说，模块可以直接通过 Systemless 挂载例如odm以及其他 root 实现无法挂载的分区，无需为此而付出额外的心血

并且，为了保证更强的安全性，ShiroSU 的 Systemless 会无视模块挂载的文件/目录的 SELinux 上下文、目录的权限以及文件/目录的用户/组， 如果文件挂载到了不存在的目录，那么其SELinux 上下文、权限、用户/组均会继承自父目录。通常来说，这些行为不会影响模块的运行，反而有助于提高稳定性

Shell​

ShiroSU 在此处与其他 root 实现有较大差异，ShiroSU 运行的 Shell 脚本默认并不在BusyBox中以 “独立模式” 运行。

为了提升 Shell 脚本开发的便利性， ShiroSU 使用sush(用 Rust 编写的Bash) 运行 Shell 脚本， 并且优先使用uutils(用 Rust 编写的coreutils) 的命令集，以 Magisk 的 BusyBox 作为替补。 也就是说，命令优先从 uutils 获取，没有的命令才会从 BusyBox 获取

由于并不在 BusyBox 中以 “独立模式” 运行，命令都是通过PATH环境变量注入的，请勿在模块的 Shell 脚本内硬编码修改PATH！

环境变量​

为了便于区分，ShiroSU 在模块运行时注入以下变量:

• SSU(布尔值): 在 ShiroSU 环境下运行时，此值将为true

  但这并不能代表可以通过$SSU && # code ...来执行代码，应当始终使用[ "$SSU" = true ]或类似方法来检测 ShiroSU

• SSU_VER(字符串): ShiroSU 的版本号 (不包括补丁号)
• SSU_VER_CODE(整数值): ShiroSU 的纯数字版本号 (包括补丁号)

Recovery​

ShiroSU 不支持通过 Recovery 安装模块， 并且在模块安装时META-INF/com/google/android/update-binary中的代码不会被执行

SU 调用​

ShiroSU 的 SU 实现默认附带了一个仅能用于直接执行 Shell 命令的sudo，可以直接通过sudo来执行例如sudo ls /。

sudo仅作为一个简易的su -c替代品而存在，但是任何模块内都不应该通过sudo或su -c执行 Shell 命令！

同样的，任何模块也不应该通过硬编码来获取命令，例如/data/adb/ssu/bin/busybox crond， 因为无论是在 BusyBox 的 “独立模式” 还是直接通过PATH注入命令，命令都已经可以直接调用，无需任何硬编码的手动获取行为。

贡献者

白彩恋

页面历史