SO 加固前为什么先梳理 JNI 与 ABI

依赖图决定哪些库能单独处理

应用可能直接加载主库，也可能通过主库继续加载其他依赖。第三方 SDK 还可能携带自己的 Native 组件，并依赖特定的导出符号或初始化顺序。

依赖图至少应列出库名、直接与间接依赖、加载入口、初始化时机和调用方。缺少这张图时，对单个 SO 的改动可能在另一个库加载时才暴露问题。

• 主库与传递依赖
• 系统库与第三方库
• 加载入口与初始化顺序
• 异常出现的最早阶段

JNI 注册方式影响符号处理

静态注册依赖名称约定，动态注册通常在初始化阶段把 Java 方法与 Native 函数绑定。两种方式对符号可见性、重命名和加载时机的约束不同。

在处理导出或函数表示之前，应确认每个关键入口如何注册、是否被反射或第三方组件调用，以及异常时能否在 Java 与 Native 两侧同时定位。

ABI 不是一个可省略的标签

arm64-v8a、armeabi-v7a 与 x86_64 对应不同的指令、链接产物和依赖组合。某个 ABI 构建成功或在模拟器启动，不能证明另一个目标架构可用。

发布前应检查最终 APK 实际包含的 ABI，并在目标架构上验证库解析、应用启动、关键 JNI 调用、异常捕获与第三方 SDK 路径。

• 最终包包含目标 ABI
• 所有依赖都能解析
• 关键 JNI 路径可重复
• 未覆盖架构被明确记录

保护强度要和装载稳定性一起验收

删除符号、处理字符串或虚拟化关键函数分别减少不同线索，没有一种动作可以单独代表完整 Native 保护。启动初始化和高频函数还需要额外关注性能与故障半径。

稳妥的做法是从少量高价值、输入输出清楚的函数开始，在同一候选包上逐步扩大范围，并为每次配置变化保留可回退版本。