DEX、SO 与资源的保护范围
先识别核心逻辑和第三方依赖，避免把所有代码都按同一强度处理，造成性能、维护或兼容风险。
Android 项目常见的四个拆分问题
二进制与资源
包与身份
签名、渠道与候选包
构建、加固、重签和分发变化都应回到同一候选包账本，确保测试与上线对象一致。
系统与 ABI
系统版本、页面大小与 Native 兼容
涉及 Native 库时，应把 ABI、系统要求、加载路径和第三方 SDK 纳入目标设备范围。
运行与回归
安装启动不等于业务闭合
冷启动、升级、登录、支付等关键路径应按项目选取并回归，异常需要归因与回滚策略。
建议的验证顺序
先在原始候选包上冻结版本和签名信息，再确定需要保护的 DEX、Native 模块和资源范围。随后生成目标包并核验其身份、安装和启动情况；最后按系统、ABI、渠道和业务路径形成明确测试矩阵。对尚未覆盖的设备或路径，应保留为待复核项，而不是用局部通过替代整体结论。
有关 Android 签名与分发的规范，可参考 Android Developers 的官方文档。公开平台资料用于解释方法，项目结果仍取决于实际候选包和测试范围。
相关资料
查看御盾 Android 加固适配范围常见问题
DEX 或 SO 保护是否可以直接代表整个 Android 应用安全？
不能。它们是客户端保护的一部分，还应核验候选包身份、完整性、关键路径、服务端权限和发布回滚。
新 Android 版本需要重新评估什么？
优先检查系统要求、目标 SDK、第三方依赖、Native 库、安装启动和核心业务路径，并记录新增或未覆盖的测试范围。