一 理论基础
第一阶段：准备作案工具与物理提权（编译与打包）
参与者：device.mk+fs_config首先，你得把提权工具（su）塞进系统里（device.mk）。但这还不够，在 Linux 万物皆文件的体系下，权限是由文件属性决定的。fs_config就像是系统打包时的“造物主”，它在镜像生成的那一刻，给su文件强行打上了Set-UID (S位)这个物理印记。这是整个 Root 逻辑的基石，没有这一步，后面的软件逻辑全是空中楼阁。同时，device.mk还负责在系统属性里挂上ro.secure=0的“免检”牌子。
第二阶段：解除全局宏观封锁（系统 Init 阶段）
参与者：selinux.cpp工具放进去了，系统也开始启动了。此时遇到了 Android 最强大的底层安保——SELinux (MAC 强制访问控制)。哪怕你有 S 位，哪怕你是 Root，只要 SELinux 策略不放行，操作依然会被拦截。因此，在 Init 进程的极早期，我们通过修改selinux.cpp强行将系统置于Permissive模式，这就相当于彻底切断了整个安保系统的报警线，为后续的越权操作扫清了最大的系统级障碍。
第三阶段：打通外部 VIP 通道（PC 端调试）
参与者：adb守护进程 (main.cpp/restart_service.cpp)在开发和调试时，我们需要从 PC 端（外部）直连系统底层。原生系统中，adbd发现环境不安全就会“自废武功”降级为shell用户。修改这部分代码，就是为了留住这条外部 VIP 通道，让adbd强行保持 UID=0，从而实现adb root、adb remount等极其便利的外部调试功能。
第四阶段：拆除内部调用软墙（App 端执行）
参与者：su.cpp外部通道通了，那内部普通的 Android App 想要 Root 怎么办？它们只能去调用第一阶段塞进去的su文件。然而 AOSP 的su源码内部有自己的“查户口”逻辑（DAC 自主访问控制），拒绝普通 UID 的调用。修改su.cpp，就是拆除了这最后一道软件防御代码，让任何内部 App 只要拿到su就能变身 Root。
总结
这五个文件的修改，完美覆盖了“预置与赋权 (mk/fs) -> 绕过宏观审计 (selinux) -> 外部直通 (adb) -> 内部提权 (su)”这一完整的逻辑闭环。只有将它们结合起来，才能在 Android 严苛的安全体系中撕开一道口子，实现真正意义上的全局开发权限。
二 实操
1.设备.mk
device/rockchip/rk3576/device.mk
2.adb文件
alp/packages/modules/adb/daemon/restart_service.cpp
alp/packages/modules/adb/daemon/main.cpp
alps/system/core/adb/Android.bp
3.selinux
alp/system/core/init/selinux.cpp
4.su文件
system/extras/su/su.cpp
5.fs_config文件
三 调试
which su