Android 应用加固推荐方案（APK / AAB）

本文针对 Android 应用包（APK / AAB） 的整体加固，覆盖 Dex、资源、签名与包结构。只需要保护 JNI .so 时，请阅读 Android Native ELF 加固推荐方案（JNI .so）。

1. 适用范围

2. 攻击面与保护点

3. 保护选项

环境检测类选项可能影响无障碍工具、远程协助、部分厂商系统和自动化测试。上线前务必在真实设备上验证。

4. 推荐配置

4.1 工具 / 内容类

目标：防止直接反编译和改包，同时保持最大兼容性。

4.2 金融 / 支付类

配套要求：

• 关键判断放服务端，客户端检测只作为风险信号。
• Root / 模拟器检测提供降级策略，避免直接拒绝导致客诉。
• 保留白名单机制，便于客服排查。

4.3 游戏类

游戏还需要关注：

• IL2CPP 的 libil2cpp.so 与 global-metadata.dat。
• 资源包与热更新校验。
• 多平台渠道包的签名差异。

5. Native SO 加固

APK 中的 .so 是标准 ELF，可以按 Android Native ELF 加固推荐方案（JNI .so）处理：

1. 解包 APK，取出 lib/<abi>/lib*.so。
2. 使用 Native ELF 方案做符号移除、函数混淆或虚拟化。
3. 替换回原 ABI 目录，保持目录结构和文件名不变。
4. 重新打包、对齐、签名。
5. 在真机验证 JNI 加载和核心功能。

需要重点验证：

• JNI_OnLoad、Java_* 导出符号是否仍可解析。
• System.loadLibrary 的加载顺序与依赖 .so。
• 不同 ABI 是否都处理，尤其是 64 位设备加载 arm64-v8a。
• 崩溃栈是否还能映射到符号（保留未 strip 版本）。

只保护 .so 而不保护 Dex，攻击者仍可修改 Java / Kotlin 层逻辑。建议 Dex 与 .so 组合使用。

6. 签名与分发

6.1 签名方案

• 使用 APK Signature Scheme v2 / v3，保留 v1 仅用于兼容极旧系统。
• 加固改变包内容后，必须使用原签名证书重新签名，否则无法覆盖安装。
• 证书和密钥存放在受控的密钥管理系统中，不要提交到代码仓库。

6.2 重签名流程

# 1. 对齐（在签名之前）
zipalign -p -f 4 app-protected-unsigned.apk app-protected-aligned.apk

# 2. 签名
apksigner sign \
  --ks release.jks \
  --ks-key-alias release \
  --out app-protected.apk \
  app-protected-aligned.apk

# 3. 校验
apksigner verify --print-certs app-protected.apk

6.3 AAB

AAB 不能直接安装到设备。测试流程：

# 生成 APKS
bundletool build-apks \
  --bundle=app-protected.aab \
  --output=app-protected.apks \
  --ks=release.jks \
  --ks-key-alias=release

# 安装到已连接设备
bundletool install-apks --apks=app-protected.apks

注意：

• Google Play 会使用上传密钥重新签名分发包，本地测试签名与商店签名可能不同。
• 如果使用 Play App Signing，确保加固流程不影响上传密钥签名。
• 分渠道包需要分别验证。

7. 构建流水线

Gradle assembleRelease / bundleRelease
        ↓
原始包冒烟测试
        ↓
Sugo 保护（Dex 加密 + 环境检测）
        ↓
zipalign
        ↓
apksigner（原证书）
        ↓
真机回归
        ↓
分发 / 上架

流水线建议：

• 把加固步骤放在 assembleRelease 之后、签名之前。
• 每次构建使用独立的输出目录，避免旧包覆盖。
• 记录输入包、输出包的 SHA-256 和使用的保护配置。
• 对保护后的包执行自动化 UI 冒烟测试，不要只校验签名。
• 保留 mapping 文件与未加固包，便于崩溃还原和回滚。

8. 测试矩阵

9. 常见问题

9.1 保护后安装失败

• 签名不一致：确认使用原证书，且 v2 / v3 签名有效。
• 未对齐：签名前执行 zipalign。
• 包结构被破坏：确认加固工具输出的是完整 APK，而不是仅替换了部分文件。
• 覆盖安装失败：先卸载旧版本再试，确认是否签名证书变化。

9.2 启动崩溃

• 检查 Dex 加密与多 Dex、动态加载、插件框架是否兼容。
• 检查 .so 是否与 ABI 匹配，是否遗漏某个 ABI。
• 关闭反调试、Root 检测、模拟器检测，缩小范围。
• 用 adb logcat 抓取崩溃栈，保留原始包对比。

9.3 加固后无法上架 Google Play

• 确认上传的是 AAB，且签名配置正确。
• 检查是否包含动态代码下发、权限或隐私违规。
• 检查 64 位支持与目标 API 级别要求。
• 环境检测不能用于规避审核或隐藏功能。

9.4 Root 检测误报

• 部分定制系统、开发版系统、企业设备会命中。
• 提供降级策略：提示风险但允许继续使用。
• 保留客服白名单或远程配置开关。
• 在真实用户设备上收集误报样本。

9.5 性能下降

• Dex 加密会增加启动时的解密与加载时间。
• 反注入、内存扫描类能力会带来运行时开销。
• 在低端机上重点测试冷启动和首屏渲染。
• 如果开销不可接受，优先保留 Dex 加密与反调试，调整环境检测频率。

9.6 多渠道包如何保护

• 先保护基础包，再按渠道写入渠道信息并重新签名。
• 或每个渠道独立保护，确保渠道信息写入后再签名。
• 不要复用已签名包直接改渠道信息，会破坏签名。

10. 相关文档

• 移动加固推荐方案
• Native 加固推荐方案
• GUI 完整使用文档
• CLI 使用文档