Android 17升级后System.load报错：SO文件只读权限与加固兼容性排查
Android 项目升级系统或 targetSdk 后出现 UnsatisfiedLinkError，最容易被误判为"ABI 不匹配"、"SO 文件未打入包"或"加固破坏了库文件"。这些确实是可能的原因，但在 Android 17（对应 API 级别 37）的背景下，新增了一个必须单独排查的因素：通过 System.load() 按绝对路径加载的 Native 库文件，在加载前必须处于只读状态。文件存在、名称正确、CPU 架构匹配，均不足以保证满足此加载条件。
本文不讨论如何规避 Android 的加载保护机制，而是为工程团队提供一套适用于 Release 候选包的定位框架：如何先固定版本变量，如何通过对比原始包与加固包来排除误判因素，如何检查"写入---校验---只读---加载"的生命周期，以及如何将检查结果纳入发布流程的门禁。最终目的是减少"出错后把所有 Native 保护关掉"的高成本处置。
一、先明确：这是动态路径加载问题，不是所有 SO 的共同命运
Android 项目中，加载 Native 库主要有两种方式。第一种是调用 System.loadLibrary() 并传入库名，由系统在预设的 Native 库目录中查找对应库文件；第二种是调用 System.load() 并传入一个具体的文件路径。后者常见于插件化、热更新、算法模型加载、音视频扩展、企业 SDK 集成或运行时动态准备 Native 组件等场景。
Android 官方针对 API 37 的行为变更说明指出，Safer Dynamic Code Loading 的保护范围已扩展至 Native 库：当应用通过 System.load() 加载 Native 文件时，该文件必须被标记为只读，否则可能抛出 UnsatisfiedLinkError。此规则旨在防止应用加载一个在加载后仍可被写入或替换的代码文件。它不是"禁止 Native"，不是"禁止所有动态交付"，也不表示某个加固方案天然不兼容；具体影响取决于最终加载路径、文件状态、targetSdk 和业务时序。
因此，排查的第一条纪律是：不要在没有确认加载 API 的情况下讨论修复。一个由 loadLibrary() 触发的符号依赖异常，与一个运行时释放文件后 load() 失败的路径，所需证据完全不同。把它们统称为"SO 加载失败"，通常只会让研发、SDK 厂商和加固团队反复交换无法比较的日志片段。
二、为什么升级后才暴露：旧流程可能一直存在，但没有被同样约束
不少应用的 Native 流程来自很早以前的工程假设：先从资源、压缩包或受保护载体中取出一个文件，写到应用私有目录，再用绝对路径加载。这个流程在旧目标 API 或特定设备上可能看起来稳定，团队于是把它当作可长期复用的基础设施。
问题在于，工程"能跑"不等于其状态可被证明。若写入尚未完整结束、校验与加载并发、异常后留下旧文件、多进程同时准备同一组件，最终看到的文件虽然存在，其实际状态却可能因启动时机不同而异。targetSdk 37 的只读规则会将这类原本隐蔽的生命周期问题转化为显式失败。
这也是为什么单次冷启动不能作为兼容性结论。首次安装、覆盖安装、恢复历史数据、首次调用算法、前后台切换、多进程服务启动以及 SDK 延迟初始化，都可能改变文件准备的时序。加固项目还多一个变量：保护策略是否引入了 Native 载体、是否改变了初始化顺序、是否将原本包内的库变成了运行时材料。正确的结论不是"加固后闪退所以加固有问题"，而是"在固定候选版本和固定路径下，哪一个变量首先改变了结果"。
三、先搭建四象限，不要用不同版本互相比较
最低限度应保留四组候选对象：原始包 targetSdk 36、加固包 targetSdk 36、原始包 targetSdk 37、加固包 targetSdk 37。四组对象应尽量保持相同的业务版本、ABI、SDK版本、签名主体以及关键业务路径。若在四组之间同时更换了SDK、修改了业务代码或替换了渠道脚本，测试将失去归因能力。
| 候选对象 | 主要回答的问题 | 不应据此推出的结论 |
|---|---|---|
| 原始包 + targetSdk 36 | 升级前的 Release 基线是否正常 | 可以跳过 API 37 验证 |
| 加固包 + targetSdk 36 | 保护策略是否已经改变基础路径 | Android 17 已无风险 |
| 原始包 + targetSdk 37 | 平台规则或项目/SDK 链路是否已触发 | 一定是系统缺陷 |
| 加固包 + targetSdk 37 | 加固与平台规则是否在同一路径相遇 | 可以直接关闭全部保护 |
如果原始包在 targetSdk 37 上已失败，应优先检查项目或第三方 SDK 的 Native 准备链，确认加载 API、文件状态和依赖关系；如果原始包正常而加固包失败，才有理由进一步检查保护策略、载体生成和初始化时序；如果仅在覆盖安装时失败，则应优先排查旧文件残留和版本切换问题，而非 ABI 差异。这个顺序看似简单，却能避免大量无效的"先修改规则再重试"操作。
四、排查证据不能只剩一条异常信息
一份可供交接的问题单至少应包含以下信息：候选包身份、targetSdk、系统版本范围、ABI、首次出现的业务路径、加载方式（使用 System.load() 还是按库名加载）、文件在加载前的状态、是否经历运行时写入、是否经过完整性校验、是否发生覆盖安装，以及原始包与加固包的对比结论。记录时应进行脱敏处理，避免上传生产环境路径、客户包名、签名信息或内部实现细节。
基于这组信息，团队可以将"文件存在但仍报错"这一现象拆解为多个可验证的具体问题：是库文件版本与预期不符，还是文件仍处于可写状态；是加载前的转换时机不当，还是调用点位于另一进程；是同一库文件被多个初始化任务竞争访问，还是第三方 SDK 自身存在下载和缓存机制。异常名称仅能提供排查入口，无法直接揭示最终的根本原因。
五、文件权限不是一个修补动作，而是一段生命周期
从安全与可靠性两方面看，比较合理的流程是：完成写入，完成必要的完整性校验和版本核对，关闭写入相关句柄，将最终文件置为只读，再进入加载阶段。把"设为只读"放在加载失败后的补救逻辑里，无法确保首次加载时已满足条件；把文件长时间留在可写目录，则会扩大篡改和竞争窗口。
这里也要避免另一种误区：只读状态本身并不保证 SO 文件的安全性，也不替代代码签名、候选包身份、后端鉴权或漏洞治理。它仅是一项系统级的加载约束。加固能够提高关键 Native 资产、加载链和完整性判断被低成本修改的难度，但不能把不受信任客户端变成绝对可信环境。高价值结果仍应由服务端结合账号、请求和业务上下文决定。
六、插件化、下载型 SDK 和加密载体为什么风险更高
包内直接交付的 Native 库通常更容易追踪；而运行时准备的组件则涉及下载、解压、版本选择、旧文件删除、失败重试与回滚等更多步骤。游戏插件、音视频扩展、AI 算法、人脸识别、企业安全 SDK 都可能有这类链路。若组件来自闭源供应商，应用团队需要确认其已公开声明支持 Android 17，而不是在正式上线后仅凭出现的异常要求供应商临时"兼容一下"。
对于加密或受保护的载体也是如此。工程重点不在于公开解密细节，而在于确认最终用于加载的材料在进入系统加载器前已完成写入与验证，并且发布记录能够清晰说明其所属的候选包、策略版本及 SDK 版本。这样，即使某次回归测试失败，团队也能定位到单一变量，而无需在多个不透明的中间产物中进行猜测。
七、把 Native DCL 检查加入 CI/CD，但不要把它做成形式化的勾选
自动化流程适合用于保存身份标识与检查结果，但不适合替代业务验收。构建阶段可冻结原始的 Release 候选版本；加固阶段记录策略摘要与产物身份标识；测试阶段运行安装、冷启动、首次 Native 调用、覆盖安装和进程重建等测试；门禁阶段保存已执行项、失败项、未覆盖项以及回滚候选。对于实际使用 System.load() 的模块，可将"加载前文件状态已核对"作为一个明确的检查项字段，而不是仅在报告末尾标注"已兼容 Android 17"。
当自动检查失败时，流水线应阻断相应的发布候选，并保留可追溯的材料；但是否放行仍需由项目负责人根据业务影响、验证范围和回滚能力来决定。安全工具、加固平台或 CI 都只能提供证据与建议，不应在没有上下文的情况下自动替代发布责任人。
八、哪些做法最容易扩大问题
第一，使用 Debug 包证明 Release 没问题。Debug 版本通常缺少完整的代码缩减、签名、渠道配置和保护措施。第二，使用不同版本的原始包与加固包进行直接比较。第三，遇到 UnsatisfiedLinkError 就关闭所有 Native 保护，从而掩盖了真正的 ABI、符号或 SDK 兼容性问题。第四，在生产环境中保留可写的 Native 文件，仅为了"方便重试"。第五，将一次测试通过等同于所有 ROM、设备和渠道均已兼容。第六，把完整客户日志、路径或产品实现贴到公开社区寻求帮助。
九、提交供应商前的脱敏问题模板
可按以下字段提交：候选版本与 targetSdk；原始/加固状态；系统与 ABI 范围；触发业务动作；加载 API 类别；加载前文件状态核对；是否覆盖安装；已执行的对照项；未覆盖范围；可接受的回滚方案。不要附带私钥、真实包、生产地址或内部实现。供应商将获得可供复核的工程事实，而非脱离具体环境的结论。
十、结语：系统规则应成为发布证据，而不是临时补丁
Android 17 的 Native DCL 规则提醒团队：Native 代码的交付、写入和加载不应是一个黑盒步骤，而是一条需要版本、权限、时序与回滚共同证明的链路。对 APP 加固项目而言，最有价值的行动不是承诺"不会闪退"，而是将原始/加固版本、targetSdk 36/37、SO 状态以及关键业务路径纳入可复核的矩阵中。只有这样，在遇到异常时，才能明确下一步应由项目、SDK、策略还是发布流程负责。
官方资料：
如需查看完整的公开检查框架，可阅读Android 17 动态 SO 加载与 APP 加固兼容指南。该链接仅用于技术资料延伸；实际的 PoC（概念验证）应以授权的候选包和可回滚的业务测试为准。
附录 A：从系统条件到业务结论的分层排查法
排查 Native 动态加载问题时，常见的低效模式是"遇到异常就尝试修改某个单一环节"。例如，有人先修改 ABI 配置，有人将 SDK 升级到最新版本，有人调整加固策略，也有人直接选择不加载 Native 组件。这种做法的问题并非这些操作本身无效，而是它们同时改变了多个变量，导致后续无论成功或失败都难以归因。
一种更具可复用性的方法是采用分层排查框架，将事实信息组织为五个层次。第一层是分发与候选身份：明确本次测试的具体 Release 候选版本、构建编号，以及是否与提交至应用商店的包一致。第二层是平台条件：系统版本、targetSdk、ABI、安装方式和是否为覆盖安装。第三层是组件条件：问题库由应用自带还是 SDK 提供，采用何种加载 API，是否经历运行时准备。第四层是运行路径：冷启动、首次业务调用、后台恢复、独立进程还是下载后的首次加载。第五层才是业务决策：阻断发布、临时例外、回滚或继续深入定位。
这个模型有一个重要收益：每层都可以记录"已确认""未知""未覆盖"，而不是让一段异常文本承担所有含义。比如应用团队只确认了 arm64 的冷启动，不意味着 x86 测试环境、覆盖安装或插件下载链也通过；SDK 厂商声明支持 Android 17，也不等于当前应用的加固候选和真实业务路径已经验证。把未知状态写出来，通常比制造一个过宽的兼容结论更有助于下一次排错。
附录 B：如何区分权限状态、ABI 与依赖问题
UnsatisfiedLinkError 这一异常类别很宽。若团队只看异常类名，容易将不同根因的问题归为同一工单。实践中至少要区分三类线索。
第一类是文件与加载链线索：最终路径是否存在、是否确实经由 System.load()、加载前是否完成写入和只读状态转换、是否在另一进程中被重新生成。这类问题关注的是 API 37 下的动态代码加载约束。第二类是架构与链接线索：当前设备 ABI 是否被最终候选包支持、目标库的依赖库是否同时可用、符号是否能够解析。这类问题在不同 CPU 架构上表现各异，无法通过修改文件权限解决。第三类是业务与 SDK 线索：SDK 是否仅在特定功能入口初始化、是否依赖网络下发组件、是否受渠道或远程配置影响、是否在升级后残留旧缓存。它们可能只在登录、人脸、音视频或模型推理时出现。
记录方式也应对应线索。对于权限状态，记录"加载前状态是否已核对"和"写入/转换/加载的先后关系"即可，不需要公开真实目录；对于 ABI，记录 ABI 类别、候选包是否包含对应架构以及测试范围；对于 SDK，记录 SDK 类别、版本和业务入口即可。公开文章、社区提问和供应商工单都应该避开真实包名、客户路径、证书和生产日志。
附录 C：覆盖安装为什么是 Native 兼容性中的高价值用例
许多团队只验证全新安装。它能发现一部分打包和初始化问题，但覆盖不到实际用户最常见的升级状态。覆盖安装可能保留私有目录中的旧文件、旧策略或旧 SDK 缓存；新包安装完成后，业务逻辑可能读取到旧版本组件，或者两个版本的清理规则交错执行。若动态 Native 组件由多个进程或多个功能模块共同维护，还可能出现"一个流程清理，另一个流程加载"的短暂时间窗口。
API 37 的只读加载要求不会产生这些旧文件，但会让"文件状态不明确"的加载链更容易出现显性失败。因此，发布门禁至少应将全新安装、同版本覆盖、旧版本升级、失败后重试、前后台恢复列为不同用例。每个用例记录的是业务结果与候选身份，不必泄露实现细节。若覆盖安装唯一失败，优先检查版本迁移与残留文件，而不是立即把故障归到 Native 保护本身。
附录 D：第三方 SDK 的责任如何进入发布门禁
移动应用很少只包含自研的 SO（共享对象库）。推送、支付、地图、音视频、图像处理、风控、人脸识别、游戏引擎与 AI 推理等 SDK 都可能包含 Native 组件。在升级 targetSdk 至 37 之前，团队应建立 SDK 清单，标注其是否包含 Native 库、是否存在动态加载路径、供应商是否已发布针对 Android 17 的兼容性声明，以及项目实际集成了哪些业务模块。
此处的"供应商支持声明"仅能作为参考输入，不能替代应用自身的验证。因为供应商的测试环境（如打包方式、分发渠道、混淆规则、加固策略、ABI 选择及业务组合）很可能与应用的实际环境存在差异。应用方也不应在没有证据时要求 SDK 厂商为所有异常背书。更好的协作方式是提供同一候选版本下的对照结论、触发入口、系统/ABI 范围和未覆盖项，要求对方说明其组件的加载模型与已知限制。这样问题可以被分配到可验证的责任边界。
附录 E：发布门禁示例
下表适用于内部检查，不宜作为公开宣传材料。
| 检查项 | 最低要求证据 | 失败后操作 |
|---|---|---|
| 候选包身份一致 | 原始包、加固包与最终渠道包可相互对应 | 阻断，不允许以其他包替代 |
| targetSdk 范围明确 | 构建配置和测试范围可复核 | 补齐范围后再判断 |
| Native 加载类别明确 | 区分按库名和按路径加载 | 未知时进入专项排查 |
| 加载前状态核对 | 动态文件状态有测试记录 | 阻断涉及该路径的发布 |
| 关键路径回归 | 安装、启动、首个 Native 业务入口 | 失败时保留最小复现条件 |
| 覆盖安装 | 新旧候选切换结果可追溯 | 检查迁移与残留对象 |
| 例外管理 | 负责人、期限、回滚候选明确 | 无法回滚不得放行 |
门禁的价值不在于让所有项目采用同一阈值，而在于让"是否可以发布"有可审计的输入。某些低风险功能可以在证据充分的前提下接受有限例外；涉及登录、支付、交易、身份或关键算法的加载路径，则应采用更严格的回归与回滚要求。无论级别如何，未测试不能写成通过，发现问题也不应靠删除记录来保持报表好看。
附录 F：加固团队在这一问题中的正确角色
加固团队不应将系统限制描述为"客户项目的问题"，也不应承诺能替代系统自身的规则。其合理角色是协助识别在保护流程中是否存在运行时 Native 代码、是否改变了加载顺序、哪些策略可在授权测试中作为独立变量，以及如何保留原始包与加固包之间的对照证据。对于第三方闭源组件，只能基于黑盒行为分析来缩小问题范围，而不能宣称已理解或修复其内部机制。
反过来，应用团队也不应将加固后出现的任何异常直接归咎于供应商的缺陷。只有当同版本的原始包与加固包在相同条件下出现稳定、可复现的差异时，才具备进一步讨论加固策略影响的基础。这样既保护安全能力不被随意关闭，也避免应用真正的版本、SDK 或业务问题长期被掩盖。
附录 G：面向管理者的风险说明
管理者通常不需要了解 System.load() 的技术细节，但需要明确此次升级可能影响哪些决策。首先，API 36 的商店合规截止日期与 API 37 的技术升级是两件不同的事：前者是发布商店的强制要求，后者则需要根据产品节奏和依赖条件来规划。其次，Native 动态加载的风险主要集中在那些具有运行时组件准备链的应用上，并非所有包含 SO 库的应用都需要紧急重构。最后，最重要的产出不应是一句简单的"兼容成功"口号，而应是一份清晰的发布记录，其中说明候选版本、覆盖范围、例外情况以及回滚方案。
妥善解决此问题，也将提升安全交付的质量：加固策略、SDK 版本、签名身份、关键路径和回滚对象将被整合到同一条证据链中。以后面对 16KB 页面、R8 缩减、签名轮换或新的系统行为变更时，团队不必从零开始临时排查，而可以复用同样的对照和门禁方法。
附录 H：测试环境、预生产和正式环境不能共用一个结论
Native 加载问题往往在测试环境中不出现，而在正式环境中才出现。原因未必是"正式环境更严格"，也可能是候选包、签名、渠道脚本、远程配置不同，或真实用户的升级路径更复杂。测试团队应将环境名称作为一项明确条件而非背景描述：每个测试结果都应明确标注其来源环境（测试、预生产或正式灰度）；每个环境都应说明候选版本和关键 SDK 是否一致；每项环境差异都应评估其是否可能影响 Native 组件的交付和加载。
发布团队还应避免在测试环境中为了方便而保留生产环境中不存在的可写加载流程。否则，即使测试通过，也无法证明正式候选版本的行为与之相同。反过来，正式环境出现问题后也不应直接在生产机器上修改文件状态或替换组件进行"热修"；这种操作会破坏候选身份与证据链。应先切换到可回滚的已知候选，再在授权测试范围内重建问题。
附录 I：性能与稳定性观察为何同样需要保留
只读加载规则的首要目标是确保完整性，但在修复过程中也可能引入性能或稳定性方面的变化。例如，将文件准备从首次启动阶段移至安装后阶段，可能影响冷启动性能；增加校验或清理逻辑，可能对低端设备或后台恢复流程造成影响；多进程协调方式的改变，则可能引入竞争条件或额外的等待。发布门禁不必将所有指标都设定为统一的固定数值，但应持续追踪并对比冷启动、首次 Native 调用、内存峰值、前后台恢复以及异常退出等关键指标的趋势。
这些指标的意义在于识别那些"功能测试通过，但用户体验或稳定性出现退化"的潜在问题。特别是带有大型算法库、媒体处理、游戏引擎或本地 AI 模型的应用，Native 内存与映射文件可能比 Java 堆更能解释问题。观察到异常时应先比较原始候选与目标保护候选，不要只从一次采样推导长期结论。
附录 J：常见问答
问：把文件设为只读后，是不是就不需要完整性校验了？
不是。只读属性仅限制了文件在加载时不可写入；它并不能证明文件的来源、版本、依赖关系或业务逻辑的正确性。候选身份、版本映射、必要的完整性校验以及服务端的业务控制，仍然是需要独立处理的问题。
问：只要改用 System.loadLibrary() 就一定没有 Android 17 兼容风险吗？
不能这样推断。不同的加载方式遵循的规则不同，但 ABI、链接依赖、SDK 初始化、R8 优化、签名、内存以及业务时序等因素仍可能引发问题。更改加载方式本身属于架构变更，应进行独立的回归测试并制定回滚方案。
问：是否应立刻把所有项目升级 targetSdk 37？
升级计划取决于商店要求、项目生命周期、依赖支持和验证能力。应先区分 API 36 的现实上架要求与 API 37 的兼容性准备，避免为了赶一个节点同时引入无法归因的系统、SDK 和加固变更。
问：原始包正常、加固包异常，是否可以证明加固造成故障？
这只能说明在当前对照条件下保护链是高优先级排查变量。还需确认两者是否同一版本、同一 targetSdk、同一 SDK、同一签名责任和同一业务入口；之后再通过基础/目标策略对照缩小范围。
附录 K：发布前最终核对清单
- 候选包是否唯一且可追溯；
- 原始包与加固包是否在同一 targetSdk、ABI 与业务路径中比较；
- 是否确认存在按路径动态加载的 Native 文件；
- 是否在加载前完成了状态核对，而非失败后补救；
- 是否覆盖首次安装、升级、首次业务调用和进程恢复；
- 第三方 Native SDK 是否有版本与支持信息；
- 是否记录了通过、失败、未覆盖和例外；
- 是否存在可用回滚候选；
- 是否避免在公开记录中暴露客户实现或敏感材料；
- 是否由应用方对最终发布做出明确决定。
这份清单本身不会自动让项目兼容 Android 17，但它有助于将潜在问题纳入可复核的工程流程。对安全、研发和发布团队而言，一个可解释的失败通常比一个原因不明的"暂时通过"更有价值。
附录 L：从一次故障复盘中应留下什么
一次 Native 加载失败问题即使已经修复，也不应只留下一个"已解决"的状态。至少应沉淀四类信息：第一，触发条件，即系统版本、targetSdkVersion、候选版本、ABI 与业务入口的组合；第二，归因过程，即排除了哪些变量、保留了哪些不确定性因素；第三，修复范围，即调整的是应用流程、SDK 版本、保护策略还是发布步骤；第四，回归范围，即哪些安装、升级、恢复和业务路径需要再次验证，哪些路径仍未覆盖。
这些信息不需要写出内部实现，却能让下一次 Android 版本升级、SDK 更新或加固策略调整有历史基线。没有复盘时，团队会把相同的状态竞争、旧文件残留或加载顺序问题当作全新的随机故障；有了边界清晰的记录，测试就可以优先复用风险最高的路径。
附录 M：对采购与安全评估的建议
采购加固、原生保护或安全 SDK 时，不应仅询问"是否支持 Android 17"。更有价值的问题包括：供应商的支持结论覆盖哪些系统版本、ABI、加载方式和业务路径；需要客户提供哪些候选安装包或最小化工程；发生第三方 SDK 异常时如何划分定位责任；结果能否记录原始包与加固包的身份标识、策略摘要、已执行项和未覆盖项；发布失败后是否能提供明确的回滚对象。
供应商若仅给出绝对承诺，却无法说明测试边界，往往难以帮助项目在真实的发布压力下做出决策。相反，能够明确区分官方规则、工程建议、项目验证与未覆盖范围的方案，才更易于被研发、合规和发布团队持续采纳。
附录 N：与其他 Android 兼容性议题如何协同
Android 17 Native DCL 并非孤立问题。16KB 内存页面关注 Native 二进制与页面对齐；R8 关注代码缩减、混淆与反射入口；签名与渠道流程关注最终发布身份；动态加载则关注运行时文件的状态与时机。这些问题可能同时出现在同一个 Release 候选版本中，但不能用同一个"兼容"标签来概括。
实际排查时，应将每类问题归入独立的类别：二进制格式、加载 API、文件状态、ABI、R8 规则、SDK 版本、签名与业务路径。这样，一个修复不会被误认为解决了全部兼容性问题，搜索和验收材料也不会将不同问题混淆，从而避免得出难以复核的结论。
最后的工程原则
面对 Android 17 的动态 Native 加载限制，最稳妥的原则可以概括为：先确认事实，再缩小变量；先固定候选，再讨论策略；先验证业务路径，再做发布决策；先保留回滚，再扩大覆盖。它既适用于自研 SO，也适用于集成多个闭源 SDK 的复杂应用。把这四句话落实到候选包、测试矩阵和发布记录中，系统升级就不再只能依赖临时经验。
发布后也应持续监控真实业务的异常趋势，但监控不等于收集超出必要范围的终端信息。对于可能涉及设备、环境或会话证据的安全能力，应遵循业务目的明确、字段最小化、责任边界清晰和可审计的原则。客户端上报可以帮助服务端进行风险研判，但不应成为无限采集或仅凭单一信号永久处置用户的依据。
当问题修复后，建议将对照矩阵、门禁项和脱敏复盘沉淀为团队模板。这样在下一次发布时，便无需重复撰写"为什么会报错"的解释，而可以直接确认：本次候选版本是否改变了 Native 加载链、哪些路径继承了既有证据、哪些变化需要重新验证。持续维护这套证据，比依靠一次性兼容承诺更接近可长期运行的移动应用安全工程。
如果团队暂时没有完整真机矩阵，也应先从风险最高的一个 Native 入口开始，逐步增加系统、ABI、安装方式和业务路径；空白检查表不能作为通过结论。
每次扩展范围后重新核对候选身份、策略版本和回滚对象，避免把不同构建、不同渠道或不同 SDK 的结果混进同一项结论。只有可追溯的对照，才值得进入发布报告。
工程质量来自持续复核，而不是一次性的宣传结论。
测试范围应随版本变化持续更新，并保留清晰的未覆盖边界。