为什么 FPA 不能卸载：打包后应用的运行前提

「打包完成、应用装好了，FPA 是不是可以卸了？」——不可以。这不是稳定性玄学，而是新版本 FPA 的明确设计。

检测机制是怎么运作的

社区在讨论汽水音乐过签时把这个特性说得很直白：FPA 打包后的应用会检测 FPA 包名——如果设备上没有安装 FPA，被 patch 过的应用将无法启动。也就是说，FPA 本体是所有成品应用的「运行钥匙」：

• FPA 在 → 成品应用正常启动，框架随应用进程运行；
• FPA 卸了 → 成品应用检测不到包名，直接拒绝启动。

为什么这么设计

回想 FPA 的工作方式：框架代码进了应用包，但模块本身留在 FPA 侧（本地模式，详见FPA 和 LSPatch 有什么区别）。运行时框架要按作用域把模块挂载进来，这套信息由 FPA 统一管理。把检测做成本体在场的硬性条件，相当于让所有成品应用共享同一个「模块管理中枢」——你在 FPA 里改作用域、换模块版本，所有相关应用重启后跟着变。

实际影响

• 省空间党：8 MB 上下的 FPA（体积变化见安装包多大）常驻手机，这是免 Root 玩模块的固定成本。
• 换机/清理应用：卸 FPA 前先想想手机里还有哪些应用是它打包的——全卸了再卸 FPA，顺序不能反。
• 排查启动异常：成品应用突然打不开，先确认 FPA 还在不在、有没有被误卸或停用，再查别的（完整排查见应用打包后闪退）。

与「签名冲突」并列的两大陷阱

「卸载重装」与「不可卸载」一个针对目标应用、一个针对 FPA 本体，方向别搞混：装成品前卸的是原应用；装完后留着的是 FPA。两条规则合起来的操作顺序，在执行 Patch 到安装里串了一遍。