免 Root 注入的原理：改包、重签名、模块随应用跑
把 FPA 的全部动作压缩成一句话：系统不动，应用动。这篇把「动」的过程按时间线拆开。
第一步：改包（patch）
你选中目标应用后，FPA 对它的 APK 安装包做外科手术：把框架代码（基于 LSPlant 与 Pine，见开源与底层）注入进去，通常还要处理资源与清单文件。此时的包还是「未签名」状态。
第二步：重签名
安卓不允许安装未签名的包，改过内容的包与原签名也不再一致——所以 FPA 用新签名重新签署整个包。这一步产生了后续所有连锁反应：
第三步：应用启动，框架随行
安装成品后，一切静待应用启动。启动的那一刻，藏在包里的框架代码与应用代码一起被拉起——它抢在应用逻辑运行前完成初始化，准备接管方法调用。这也是为什么模块配置要杀后台重开才生效：挂载窗口只在启动时存在（杀后台重开才生效）。
第四步：读作用域，挂模块
框架启动后需要知道「这个应用该挂哪些模块」。作用域信息不在这个包里——由 FPA 本体统一管理，动态加载模式下通过 Shizuku 授权的通道、以 ContentProvider 方式读进来（机制见ContentProvider 作用域机制）。读到清单后，框架把已安装模块挂进进程，方法替换生效。
第五步：FPA 在场检测
新版本还加了一道约束：成品应用会检测 FPA 包名是否存在。FPA 缺席则拒绝启动——因为模块配置的提供方就是 FPA 本体，它不在，框架读不到任何东西（为什么 FPA 不能卸载）。
全链路一图流
patch 进框架 → 重签名 → 安装 → 应用启动框架随行 → 经 Shizuku 读作用域 → 模块挂载 → 方法替换生效。每一步的故障形态与排查入口，都分散在本站的对应页面里，排查总纲见应用打包后闪退。