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

先画出 ELF 依赖图和真实装载时间线

一个 Android 应用可能由主库、业务库、算法库、第三方 SDK 和系统库共同组成。Java 或 Kotlin 代码可以直接调用 System.loadLibrary，主库也可以继续通过 ELF 依赖或运行时装载其他库。最终崩溃点可能出现在被保护库之外，因为符号解析和初始化顺序由整条依赖链共同决定。

依赖图应分别记录每个 ABI 的库文件、DT_NEEDED 关系、最低系统 API、装载入口、初始化函数、导出接口和调用方。还要标记库来自自研、开源依赖还是闭源 SDK，因为能够修改和回归的责任边界不同。

Android NDK 文档指出，原生符号通常在库装载时解析。代码引用了目标系统不存在的 API，即使运行时分支看似不会执行，也可能在 dlopen 阶段直接失败。因此 NDK API 下限和设备系统版本必须进入依赖图。

静态注册和动态注册决定符号处理边界

JNI 可以通过名称约定发现 Native 方法，也可以在初始化阶段使用 RegisterNatives 把 Java 方法与函数地址建立映射。静态注册依赖可预测的导出名称；动态注册通常只需要暴露少量初始化入口，但依赖类查找、方法签名、注册时机和加载线程。

如果加固或符号处理改变了静态注册名称，系统可能找不到 Native 实现。如果动态注册表中的方法签名、类名保留规则或初始化顺序变化，也可能在首次调用前就失败。仅检查导出符号数量，不能证明 JNI 绑定仍然正确。

Android 官方 JNI 指南还提醒 JNIEnv 具有线程约束，pending exception、错误引用和跨线程使用都可能导致崩溃。保护后的回归应覆盖真实线程和异常路径，而不是只调用一个无参数的演示方法。

• 列出关键 Java 到 Native 映射
• 确认静态或动态注册方式
• 保留必要类名和签名规则
• 验证异常、线程和引用生命周期

ABI 必须按独立发布产物验收

ABI 不只是目录标签。Android NDK 官方说明 ABI 约定了指令集、字节序、调用约定、栈和寄存器使用、可执行文件格式及 C++ 名称改编。arm64-v8a 与 armeabi-v7a 的机器码和依赖不同，x86_64 模拟器通过更不能代表 ARM 真机。

每个 ABI 都要确认所有直接和传递依赖是否存在，库的 API 下限是否兼容目标系统，打包工具是否误删某个架构的文件。只有主库包含 arm64-v8a，而第三方依赖缺少对应产物时，应用仍会在装载阶段失败。

如果产品计划只支持部分 ABI，应在发布记录、应用商店配置和测试范围中明确写出。未构建、未安装或未执行关键 JNI 路径的架构必须标记未覆盖，不能用编译通过替代运行证据。

保护动作会触碰哪些 Native 运行条件

符号隐藏减少静态线索，字符串处理降低明文暴露，控制流或函数虚拟化改变选中代码的执行形式。它们对导出符号、函数边界、异常展开、间接调用、对齐和性能的影响不同。不能用处理后符号更少这一项代表完整 Native 保护，也不能用库仍能被读取直接否定全部保护效果。

启动初始化、信号处理、C++ 异常、回调、线程局部状态、反射式符号查找和第三方 SDK 自校验属于高敏感区域。选择范围时，应优先从输入输出明确、调用频率可测、失败能隔离的业务函数开始，避免第一次 PoC 就处理整条初始化链。

保护配置应对每个函数或函数组记录选择原因、调用阶段、ABI、依赖、性能预算和回滚组。下面只展示公开安全的验证清单形态，不包含内部符号或产品配置语法。

native_group: protocol-core-v1
abis: [arm64-v8a, armeabi-v7a]
load_phase: post-authentication
jni_registration: dynamic
execution:
  frequency: bounded
  main_thread: false
dependencies:
  - business-runtime
  - system-crypto
acceptance:
  - dependency-resolution
  - jni-registration
  - exception-path
  - output-parity
  - latency-budget
rollback: native-group-v0

用最早差异定位 SO 加固后的闪退

排查时先固定未保护基线和保护候选包的文件身份、签名、设备、系统、安装方式与业务输入，然后按时间线寻找最早差异：进程创建、Application、库装载、JNI_OnLoad、注册完成、首次 Native 调用、关键业务返回。最后一条崩溃日志可能只是连锁反应。

UnsatisfiedLinkError 通常指向库缺失、ABI 不匹配、依赖或符号解析问题；注册错误可能表现为找不到 Native 方法；错误的 JNIEnv、引用或 pending exception 可能在业务调用中崩溃。应保留与候选包匹配的 Native 符号用于内部归因，但公开报告不暴露真实符号和地址。

CheckJNI 可以帮助发现部分 JNI 误用，但它是诊断工具，不等于生产运行状态，也不能覆盖所有 Native 内存和并发问题。修复后必须回到目标发布配置重跑关键路径。

发布结论要同时覆盖强度、兼容和可维护性

静态强度观察可以记录符号、字符串、代码结构和关键入口暴露面的变化；运行验收则验证装载、JNI、关键业务、异常和目标 ABI。两类证据互相补充，不能用其中一类替代另一类。

最终候选包还要完成安装升级、签名、渠道、启动、崩溃监控、Native 符号归档和回滚演练。符号归档必须能用文件身份找到匹配版本，否则线上 Native 崩溃无法正确符号化。

本文提供的是工程检查框架，不是某个 SO 或某个保护配置的测试结论。没有目标包、目标 ABI 和真实调用路径时，只能判断准备工作是否完整，不能承诺兼容性或性能。

• 每个发布 ABI 都有运行证据
• 关键 JNI 入口覆盖正常和异常路径
• Native 符号与最终候选身份匹配
• 装载、业务和回滚结果可复核
• 未覆盖的设备与系统被明确限制

动态装载证据要覆盖真实依赖顺序

`readelf` 或 `llvm-readobj` 能列出 DT_NEEDED、架构和动态段，却不能单独证明应用在设备上的实际装载顺序。系统 linker 的命名空间、应用打包方式、绝对路径与 soname、第三方 SDK 的延迟装载以及 `dlopen` 标志都会改变结果。应从进程启动到关键业务调用记录每个库何时被请求、从哪里解析、依赖是否找到、初始化函数是否完成，再与未保护候选的时间线对照。只看到目标 SO 存在于 APK 中，不能推出它已经被正确装载并执行。

依赖问题常在保护后被放大。新增段、重排、符号可见性变化或构建参数差异可能使原本偶然可用的未声明依赖暴露出来；某个库在开发设备上由其他 SDK 提前加载，也可能掩盖正式渠道里的缺失。排查时应使用干净安装和目标 ABI，从第一个装载错误开始核对主库、间接依赖、API 级别和 C++ 运行库，不要直接跳到最后一次 `UnsatisfiedLinkError` 文本。

初始化代码需要单独建账。`JNI_OnLoad`、全局构造函数、线程局部对象和注册表都可能在业务方法之前运行，它们的线程、异常和锁顺序决定启动稳定性。若保护配置触碰这些路径，测试脚本必须包含冷启动、后台恢复、进程重建和重复进入业务模块；只在已启动进程里调用一次 JNI 方法，会漏掉最敏感的装载阶段。

Android 15 起的 16 KB 页面大小支持也会暴露 Native 构建和打包假设。ELF 段对齐、预编译共享库和打包工具需要共同满足目标要求；把 `arm64-v8a` 安装成功当作页面大小兼容结论并不可靠。若产品覆盖相关设备，应分别核对库对齐、应用打包、启动和真实 JNI 路径，并把不受控制的第三方预编译库列为独立阻断项。

库的装载位置也会随打包选项变化。直接从 APK 读取未压缩库与安装时解压到文件系统，涉及不同路径、对齐和空间行为；第三方代码如果假设一个固定绝对路径，可能在某种配置下才失败。测试应使用正式清单与打包选项，并避免用开发版临时解压方式掩盖正式产物问题。

• 静态依赖图与设备装载时间线对照
• 干净安装避免偶然的预加载影响
• 间接依赖和 C++ 运行库逐项核对
• JNI_OnLoad 与全局构造单独覆盖
• 冷启动、恢复和进程重建都执行
• 以最早装载差异为排查起点

符号裁剪不能破坏异常和崩溃归因

减少导出符号和可读字符串能够降低静态暴露，但导出表、动态符号、调试符号和 unwind 信息承担不同职责。JNI 动态注册可以减少必须按名称导出的入口，仍需保证注册表中的函数地址、签名和生命周期一致；C++ 异常、信号回溯和线上 Native 崩溃则可能依赖正确的展开信息与匹配的离线符号。把所有不可见信息一并删除，容易得到表面更干净、实际无法定位故障的产物。

正确做法是把公开产物与内部诊断材料分离。发布包只保留运行所需的动态信息，未剥离符号、映射、构建标识和最终 SO 摘要进入受控归档；崩溃平台收到地址后，必须按应用版本、ABI 和文件身份选择完全匹配的符号。若符号来自另一次重建，即使源码提交相同，地址布局也可能不同，符号化出的函数名不能作为可靠根因证据。

验收还要故意触发公开安全的测试异常和错误分支，确认 Native 栈能够还原到足以归因的模块与版本，同时不在公共日志泄露真实业务符号、地址或用户数据。保护强度、运行正确性和可维护性需要同时成立；无法归因的成功启动并不是可运营的发布状态。

符号归档的读取权限和保留周期同样重要。未剥离库可能包含函数名、源路径和实现线索，不宜随着普通测试附件广泛传播；但删除过早又会让长尾崩溃永久失去解释能力。团队应按应用支持周期保存加密归档，限制到故障处理角色，并记录下载和使用。候选停止支持后，再按合规和事故追溯要求执行可审计清理。

如果使用多套 Native 构建任务，构建标识必须来自最终产物而不是源码提交。相同提交在不同 NDK、链接参数或保护配置下会产生不同地址布局；只有文件摘要与构建标识共同匹配，崩溃平台才能选对符号。符号化后仍要回到源代码和复现路径确认，不能把自动解析出的第一帧直接写成根因。

归档完成后应抽样执行一次离线符号化，确认工具版本、搜索路径和文件权限都可用。等线上事故发生才发现符号压缩包损坏、标识无法匹配或处理人员没有权限，会失去最宝贵的定位时间。

• 运行符号与调试符号分开管理
• 离线符号绑定最终 SO 摘要
• 每个 ABI 验证异常展开
• 测试崩溃能够稳定归因
• 公共日志完成符号与数据脱敏