1. 项目概述为什么2024年还在谈360加固保如果你是一名Android开发者尤其是身处国内应用市场的开发者那么“加固”这个词对你来说绝对不陌生。它就像给自家房子装防盗门是应用发布前一道几乎绕不开的工序。而在众多加固方案中360加固保凭借其免费、易用以及与国内各大应用商店的深度集成成为了许多个人开发者和中小团队的首选甚至是“默认选项”。但问题恰恰出在这里。正因为用的人多默认配置的“坑”也就显得格外普遍。我见过太多开发者包括曾经的我自己在项目临近上线时匆匆忙忙打开360加固保的客户端直接“一键加固”然后就把APK扔给测试或上传市场。结果呢应用在特定机型上闪退、某些功能比如热更新、推送、插件化莫名其妙失效、甚至加固后的包体积暴增导致用户下载安装失败。这些问题往往在测试阶段难以复现一旦线上爆发就是一场手忙脚乱的灾难。所以这篇指南的目的不是教你如何使用360加固保——它的官方文档已经足够简单。我要分享的是经过无数次“踩坑”和“填坑”后总结出的那份针对2024年最新版本通常指其命令行工具、插件及云端策略的深度配置心得与避坑清单。这些内容你在官方文档里很难找到它们源于真实的线上事故复盘、与技术支持的技术拉锯以及我们团队内部的血泪教训。无论你是刚接触加固的新手还是已经用过多次的老手相信都能从中找到让你“恍然大悟”或“心头一紧”的要点。2. 核心思路从“黑盒加固”到“白盒配置”过去我们常把加固视为一个“黑盒”过程输入一个APK输出一个加固后的APK中间发生了什么并不关心。这种思路在早期简单应用上或许可行但在如今动辄集成十几个SDK、采用混合开发框架如Flutter、React Native、或使用了高级特性如Kotlin协程、R8全模式混淆的现代Android应用上必定会碰得头破血流。正确的思路是将加固视为一个需要精细调控的**“白盒”构建环节**。你需要清楚地知道加固在做什么它不仅仅是加壳还包括代码混淆、资源加密、反调试、签名校验等多重保护。你的应用“怕”什么你的应用有哪些特性如JNI调用、反射、动态加载是与加固的默认行为冲突的如何与加固“对话”通过配置文件、命令行参数、Gradle插件选项告诉加固工具哪些地方需要“特殊照顾”。基于这个思路我们的配置指南将围绕三个核心维度展开兼容性配置、安全性平衡与流程自动化。目标是得到一个既安全可靠又稳定兼容的加固产出物。2.1 理解360加固保的核心处理流程在深入配置之前有必要快速了解一下360加固保以其命令行工具jiagu为例的大致工作流程这有助于理解后续每个配置项的意义解包与分析工具会解压你的APK分析其DEX文件、资源文件、清单文件等结构。DEX保护这是核心。会对classes.dex进行加壳、混淆、虚拟化等处理生成新的DEX或so库。这里最容易引发兼容性问题。资源与文件保护对assets、res目录下的特定资源进行加密或混淆。运行时库注入将加固的运行时库so文件注入到APK中这些库负责在应用启动时解密和加载被保护的内容。重打包与重签名将处理后的所有文件重新打包成APK并使用你提供的签名文件进行重新签名。整个过程尤其是第2和第4步是“坑”的高发区。我们的配置本质上就是在引导工具安全地绕过我们应用的“雷区”。3. 环境准备与工具选择工欲善其事必先利其器。首先确保你使用的是最新的工具旧版本的bug和限制可能让你事倍功半。3.1 获取最新版加固工具不要使用网页版上传加固那不适合自动化也无法进行精细配置。前往360加固保官网下载最新版本的命令行加固工具。通常是一个ZIP包如jiagu_linux.zip(Linux/Mac) 或jiagu_windows.zip。注意务必从官网下载网络上流传的破解版或旧版可能携带恶意代码或存在未知漏洞直接威胁你的源码和证书安全。解压后目录结构通常包含jiagu或jiagu.jar(主程序)jiagu.ini或config.ini(基础配置文件)/libs目录 (依赖库)3.2 Java环境确认360加固保命令行工具基于Java开发需要本地安装JREJava Runtime Environment或JDK。建议使用JDK 8或JDK 11这两个长期支持版本兼容性最广。避免使用过新如JDK 17或过旧的版本。在终端中检查java -version确保输出类似java version 1.8.0_301。3.3 准备签名文件加固过程会破坏原始签名因此必须在加固后重新签名。你需要准备好你的应用签名文件.keystore或.jks以及对应的别名、密钥密码、存储密码。安全建议永远不要将签名密码硬编码在脚本或配置文件中。使用环境变量或构建系统的安全存储如Android Studio的signingConfigs或CI/CD系统的Secret管理来传递密码。准备一个专门的“加固用”签名文件与正式发布签名区分开用于测试加固流程。4. 关键配置解析与避坑实战这是本文的核心。我们将通过一个典型的config.xml或通过命令行参数来逐一拆解关键配置项。以下配置基于我近期项目的实践并附上了每个选项的“潜台词”和“坑点”。4.1 基础配置与登录首先你需要登录你的360开发者账号。通过命令行初始化java -jar jiagu.jar -login 你的账号 你的密码登录信息会保存在本地后续操作无需重复登录。踩坑实录1如果账号开启了二次验证如手机令牌命令行登录可能会失败。解决方案是先在网页端登录一次或者联系客服暂时关闭二次验证不推荐。更稳定的做法是使用**“授权码”**方式。在官网控制台生成一个长期有效的授权码然后使用-import参数导入可以避免密码泄露和二次验证问题。java -jar jiagu.jar -import your_auth_code_file.txt4.2 配置模板生成与结构使用以下命令生成一个默认的配置文件模板java -jar jiagu.jar -config -show这会输出一个XML格式的配置示例。将其保存为jiagu_config.xml我们将在此基础上修改。一个强化版的配置文件骨架如下?xml version1.0 encodingUTF-8? tasks task typereinforce !-- 输入输出路径 -- option namein value/path/to/your/app-release.apk/ option nameout value/path/to/output/dir/ !-- ############### 核心保护配置 ############### -- option namemulti value1/ !-- 多DEX处理模式 -- option namecrash value0/ !-- 崩溃日志抓取0关闭1开启 -- option namex86 value1/ !-- 是否支持x86架构按需开启 -- option namearm64 value1/ !-- 是否支持arm64-v8a必须为1 -- !-- 签名配置 -- sign option namekeystore value/path/to/your.keystore/ option namealias valueyour_alias/ option namepswd value${KEYSTORE_PASSWORD}/ !-- 建议用变量 -- option namealiaspswd value${KEY_PASSWORD}/ /sign !-- ############### 高级白名单配置避坑关键############### -- white-list !-- 关键不混淆/不加密的类或包 -- package namecom.xxx.yourmodel.entity.*/ !-- 实体类JSON序列化需要 -- package namecom.xxx.yourmodel.BuildConfig/ !-- 构建配置类 -- class nameandroidx.startup.Initializer/ !-- Jetpack Startup组件 -- !-- JNI方法所在的类必须加入 -- class namecom.xxx.jni.NativeHelper/ !-- 反射调用的类如一些工厂类、路由表 -- class namecom.xxx.router.RouterTable/ !-- 第三方SDK要求不混淆的类参考其文档 -- package namecom.google.android.gms.ads.*/ package namecom.tencent.mm.opensdk.**/ /white-list !-- 资源文件保护配置 -- resource option nameassets value0/ !-- assets目录保护0关闭 -- option nameres value0/ !-- res目录保护0关闭 -- option namefilter value*.png, *.jpg, *.so/ !-- 不处理的文件 -- /resource !-- ############### 特定功能配置 ############### -- option namewebview value1/ !-- 如果用了系统WebView建议开启 -- option namedebuggable valuefalse/ !-- 加固后是否可调试必须false -- /task /tasks4.3 多DEX处理 (multi) 与64位支持 (arm64)option namemulti value1/是什么指定对多DEX应用的处理模式。value1通常表示“自动处理多DEX”。为什么现代Android应用方法数超限普遍使用MultiDex。如果这里配置不当加固后可能导致NoClassDefFoundError。避坑指南永远设置为1。如果你遇到加固后启动崩溃提示主DEX找不到某个类可以尝试结合下面的白名单将Application类及其直接引用的类加入白名单。option namearm64 value1/是什么是否生成支持arm64-v8a架构的加固库。为什么Google Play从2019年就要求上架应用必须支持64位。国内主流应用商店也已跟进。必须设为1。联动坑开启arm641后请务必检查你项目中jniLibs目录或第三方SDK是否提供了对应的64位so库。如果只有32位的so (armeabi-v7a)加固包在64位设备上运行可能会找不到原生库而崩溃。解决方案是要求SDK提供商提供64位库或过滤掉64位架构不推荐可能被应用市场拒绝。4.4 白名单配置 (white-list)最大的坑王这是整个配置文件的灵魂所在90%的兼容性问题都源于此配置不全或不准。加固工具的混淆和加密功能非常激进会破坏那些依赖“字符串匹配”或“运行时结构稳定”的代码。白名单配置原则反射相关任何通过Class.forName(),getMethod()等方式动态调用的类、方法、字段其名称必须保持原样。JNI相关Java层的Native方法声明类 (native关键字修饰的方法所在的类)必须加入白名单。因为C/C代码通过JNIEnv-GetMethodID查找方法时依赖的是混淆前的名称。序列化/反序列化所有用于JSON如Gson、Jackson、Parcelable、Serializable的实体类Data Class其字段名通常需要保持稳定。至少要把这些类本身加入白名单防止类名被混淆。字段名是否混淆取决于序列化库的配置如Gson的SerializedName。动态加载如果你使用了插件化、热修复框架如Tinker、Sophix那些需要从APK外部加载的类其类名和包路径必须保持不变。第三方SDK要求几乎所有第三方SDK的集成文档里都会有一节“Proguard/R8 Rules”里面列出的-keep规则同样适用于360加固保的白名单。你需要将这些类或包名翻译成package name.../或class name.../的格式加入到配置中。实操心得如何快速确定白名单从崩溃日志反推加固包测试时出现ClassNotFoundException,NoSuchMethodError日志里会给出缺失的类名或方法名直接加入白名单。扫描代码在项目中全局搜索Class.forName、getDeclaredMethod、getField等关键字找出所有硬编码的字符串类名/方法名。依赖分析检查build.gradle中所有第三方库的官方文档收集它们的混淆保持规则。最笨但最有效的方法在测试阶段将白名单范围放得很宽如com.yourcompany.*让加固生效但混淆减弱。然后逐步缩小范围直到找到引发问题的那个最小类集合。4.5 资源文件保护 (resource)option nameassets value0/与option nameres value0/是什么是否对assets和res目录下的文件进行加密。为什么默认建议关闭设为0性能开销运行时解密资源会有轻微性能损耗。兼容性风险某些第三方库或框架如一些游戏引擎、WebView加载本地HTML可能直接通过文件路径访问资源加密会导致访问失败。必要性低APK中的资源文件图片、布局XML本身是编译后的二进制格式可读性已不高加密的边际收益有限。何时开启如果你的APK包含非常关键的、不希望被直接提取的配置文件、脚本或密钥文件但请注意密钥硬编码在APK中本身就不安全可以单独开启assets保护并通过filter排除其他文件。4.6 签名配置 (sign)这里有一个巨坑加固工具的重签名操作可能会破坏Android V2/V3签名方案APK Signature Scheme v2/v3。现象加固后的APK在Android 7.0Nougat及以上设备安装时可能会提示“安装包解析错误”或“安装包已损坏”。原因V2/V3签名是对整个APK文件ZIP结构进行签名。加固工具修改了APK内部文件后如果没有正确处理签名块就会导致签名失效。解决方案确保使用最新版加固工具新版本通常对V2/V3签名支持更好。在加固命令中显式指定签名方案如果工具支持。查看帮助文档java -jar jiagu.jar -help寻找是否有-v2sign或-signscheme相关参数。终极方案先加固后手动签名。这是最可靠的方法。步骤一在加固配置中不配置sign部分或者使用一个临时测试签名。步骤二对加固输出的、未签名的APK或使用测试签名的APK使用Android SDK的apksigner工具进行正式的V2/V3签名。# 使用 apksigner 进行签名 (Android SDK Build-Tools 中) apksigner sign --ks your.keystore --ks-key-alias your_alias --out signed.apk unsigned.apk验证签名签名后使用apksigner verify -v your_signed.apk检查是否包含V2/V3签名。重要提示绝对不要用jarsigner工具对加固后的APK进行签名因为它只提供旧的V1签名无法生成V2/V3签名在高版本系统上一定会出问题。5. 集成到自动化构建流程CI/CD手动操作容易出错将加固集成到CI/CD如Jenkins、GitLab CI、GitHub Actions中是专业团队的标配。这里给出一个基于Shell脚本和Gradle的集成思路。5.1 基于Gradle Task的自动化在项目的app模块的build.gradle中添加一个自定义Taskandroid { // ... 你的其他配置 signingConfigs { release { storeFile file(path/to/your.keystore) storePassword System.getenv(STORE_PASSWORD) keyAlias your_alias keyPassword System.getenv(KEY_PASSWORD) } } buildTypes { release { signingConfig signingConfigs.release // ... 其他配置 } } } task reinforce360(type: Exec) { dependsOn assembleRelease // 依赖Release构建 group build description 使用360加固保加固Release APK // 定义路径变量 def jiaguDir file(/opt/tools/360jiagu) // 加固工具目录 def jiaguJar new File(jiaguDir, jiagu.jar) def configFile new File(jiaguDir, jiagu_config.xml) def inputApk file(${buildDir}/outputs/apk/release/app-release.apk) def outputDir file(${buildDir}/outputs/jiagu/) // 确保输出目录存在 outputs.dir outputDir commandLine java, -jar, jiaguJar.toString(), -config, configFile.toString(), -in, inputApk.toString(), -out, outputDir.toString() // 可以添加更多参数如 -config -show 来指定配置 // 环境变量传递密码示例更安全的方式是用CI系统变量 environment KEYSTORE_PASSWORD, System.getenv(KEYSTORE_PASSWORD) environment KEY_PASSWORD, System.getenv(KEY_PASSWORD) doFirst { if (!inputApk.exists()) { throw new GradleException(Input APK not found: ${inputApk}) } println 开始加固: ${inputApk.name} } doLast { println 加固完成输出目录: ${outputDir} // 这里可以添加自动签名步骤调用apksigner } }然后你可以在终端运行./gradlew reinforce360来完成构建和加固。5.2 CI/CD管道示例GitHub Actionsname: Build and Reinforce on: push: tags: - v* jobs: build-and-reinforce: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up JDK 11 uses: actions/setup-javav3 with: java-version: 11 distribution: temurin - name: Setup Android SDK uses: android-actions/setup-androidv2 - name: Grant execute permission for gradlew run: chmod x gradlew - name: Build Release APK run: ./gradlew assembleRelease env: STORE_PASSWORD: ${{ secrets.STORE_PASSWORD }} KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }} - name: Download 360 Jiagu CLI run: | wget -O jiagu.zip https://官方下载链接/jiagu_linux.zip # 请替换为真实链接 unzip jiagu.zip -d /opt/360jiagu chmod x /opt/360jiagu/jiagu.jar - name: Configure 360 Jiagu run: | cd /opt/360jiagu # 使用授权码登录更安全 echo ${{ secrets.JIAGU_AUTH_CODE }} authcode.txt java -jar jiagu.jar -import authcode.txt # 复制预定义好的配置文件 cp $GITHUB_WORKSPACE/jiagu_config.xml . - name: Reinforce APK run: | cd /opt/360jiagu java -jar jiagu.jar -config jiagu_config.xml \ -in $GITHUB_WORKSPACE/app/build/outputs/apk/release/app-release.apk \ -out $GITHUB_WORKSPACE/app/build/outputs/jiagu/ env: KEYSTORE_PASSWORD: ${{ secrets.STORE_PASSWORD }} KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }} - name: Re-sign with APKSigner (V2/V3) run: | cd $GITHUB_WORKSPACE # 找到加固输出的APK通常名字会变 REINFORCED_APK$(find app/build/outputs/jiagu -name *jiagu*.apk | head -1) # 使用apksigner重新签名 $ANDROID_HOME/build-tools/30.0.3/apksigner sign \ --ks keystore.jks \ --ks-pass pass:${{ secrets.STORE_PASSWORD }} \ --ks-key-alias your_alias \ --key-pass pass:${{ secrets.KEY_PASSWORD }} \ --out app-release-reinforced-signed.apk \ $REINFORCED_APK - name: Upload Artifact uses: actions/upload-artifactv3 with: name: reinforced-apk path: app-release-reinforced-signed.apk这个流程实现了从代码到加固签名APK的全自动化确保了流程的一致性和可重复性。6. 加固后的测试与验证清单加固完成并不意味着万事大吉必须进行严格的测试。以下是一份必须执行的检查清单测试类别测试项目预期结果与排查方法安装与启动在Android 5.0, 7.0, 9.0, 11.0, 13 等多个版本的真机/模拟器上安装。能正常安装、启动无“解析包错误”。重点测Android 7.0验证V2/V3签名。基础功能遍历所有主要Activity、Fragment。测试网络请求、数据加载、UI交互。功能正常无闪退。关注白名单遗漏导致的ClassNotFoundException。JNI/NDK测试所有依赖原生库的功能如音视频处理、图像识别。功能正常。如果崩溃检查对应Java类是否在白名单中以及so库架构是否齐全。反射与动态代理测试使用了反射、动态代理如Retrofit接口、AspectJ等技术的功能。功能正常。此类问题最隐蔽需结合运行时日志和白名单配置仔细排查。第三方SDK测试登录、支付、推送、分享、地图、统计等所有集成的SDK。SDK功能全部正常。将各SDK官方要求的-keep规则全部加入白名单。性能与体积对比加固前后APK体积。测试启动速度、页面跳转流畅度。体积增长在合理范围通常增加2-5MB。启动时间无明显劣化200ms。安全扫描使用其他安全扫描工具如腾讯御安全、爱加密在线检测对加固包进行扫描。无“未加固”或“保护强度弱”的告警。确保加固确实生效。一个必备的调试技巧开启加固日志在加固配置中可以尝试寻找开启调试日志的选项有时在config.ini中或通过-debug命令行参数。加固工具运行时输出的详细日志能帮你看清它具体处理了哪些类、哪些方法对于定位白名单问题有奇效。7. 常见问题与排查技巧实录这里记录了几个最让人头疼的“坑”及其解决方案。问题一加固后App启动立刻闪退日志显示java.lang.NoClassDefFoundError或java.lang.NoSuchMethodError。原因这是最典型的白名单配置不全。加固工具混淆或加密了某个类/方法但运行时可能是通过反射、JNI或框架初始化需要按原名称查找找不到就崩溃。排查查看崩溃堆栈找到缺失的类名或方法名。如果堆栈信息被混淆尝试在测试手机连接电脑使用adb logcat | grep -i classnotfound\|nosuchmethod过滤更底层的错误信息。将缺失的类或它的父类、接口加入白名单。如果是第三方库去查该库的官方混淆规则。问题二在Android 7.0及以上系统安装失败提示“安装包解析错误”。原因V2/V3签名被破坏。解决使用apksigner verify -v your.apk检查加固后APK的签名方案。如果只有v1 scheme说明有问题。采用“先加固后手动用apksigner签名”的流程。确保构建环境中的apksigner版本与build-tools版本匹配。问题三集成热更新如Tinker后加固包无法应用补丁。原因热更新框架通常需要对比基线包和补丁包的类与方法差异。加固工具的深度混淆和加密改变了类与方法的特征导致差异计算失败。解决严格遵循热更新框架的“加固配置指南”。以Tinker为例它要求将tinkerId、Application及其入口类、AssetManager等加入白名单。将热更新框架自身的所有类如com.tencent.tinker.**加入白名单。与热更新框架的打包流程顺序很重要。标准流程是打基线包 - 加固基线包 - 发布基线包 - 基于源码打补丁包 - 加固补丁包。切记补丁包也需要用完全相同的加固配置进行处理问题四加固后APK体积增加过多如超过10MB。原因主要来自加固运行时库so文件的注入。360加固保会为每个支持的CPU架构注入一个so库。优化检查option namex86 value1/。如果你的用户几乎没有x86架构的设备如Intel芯片的平板可以将其设为0减少一个架构的so库。检查资源文件保护是否不必要地开启了。关闭assets和res保护能减少一些体积和运行时开销。在resource的filter中排除掉已经压缩过的文件如*.so,*.zip避免重复压缩。问题五使用Flutter或React Native等跨平台框架开发的应用加固后白屏或JS加载失败。原因这些框架的JavaScript/Flutter引擎可能需要从assets目录加载特定的脚本或资源文件如flutter_assets、index.android.bundle。加固工具对assets的加密可能破坏了文件的读取。解决在配置文件中将资源保护关闭option nameassets value0/。如果出于安全考虑必须保护assets则使用filter精确排除框架所需的文件例如option namefilter valueflutter_assets/**, jsbundles/**/。最后记住一个核心原则加固配置是一个与你的应用特性深度绑定的过程没有放之四海而皆准的“最佳配置”。本文提供的指南和避坑点是你构建自己稳定加固流程的起点。最好的方法是为你的项目建立一个专门的、版本化的加固配置文件并随着每次引入新的第三方库或使用新的技术特性不断更新和完善你的白名单。把这个过程也纳入你的开发流程加固这件事才能真正从“玄学”变成“科学”。
2024年Android应用360加固保深度配置与避坑实战指南
发布时间：2026/7/31 9:35:24
1. 项目概述为什么2024年还在谈360加固保如果你是一名Android开发者尤其是身处国内应用市场的开发者那么“加固”这个词对你来说绝对不陌生。它就像给自家房子装防盗门是应用发布前一道几乎绕不开的工序。而在众多加固方案中360加固保凭借其免费、易用以及与国内各大应用商店的深度集成成为了许多个人开发者和中小团队的首选甚至是“默认选项”。但问题恰恰出在这里。正因为用的人多默认配置的“坑”也就显得格外普遍。我见过太多开发者包括曾经的我自己在项目临近上线时匆匆忙忙打开360加固保的客户端直接“一键加固”然后就把APK扔给测试或上传市场。结果呢应用在特定机型上闪退、某些功能比如热更新、推送、插件化莫名其妙失效、甚至加固后的包体积暴增导致用户下载安装失败。这些问题往往在测试阶段难以复现一旦线上爆发就是一场手忙脚乱的灾难。所以这篇指南的目的不是教你如何使用360加固保——它的官方文档已经足够简单。我要分享的是经过无数次“踩坑”和“填坑”后总结出的那份针对2024年最新版本通常指其命令行工具、插件及云端策略的深度配置心得与避坑清单。这些内容你在官方文档里很难找到它们源于真实的线上事故复盘、与技术支持的技术拉锯以及我们团队内部的血泪教训。无论你是刚接触加固的新手还是已经用过多次的老手相信都能从中找到让你“恍然大悟”或“心头一紧”的要点。2. 核心思路从“黑盒加固”到“白盒配置”过去我们常把加固视为一个“黑盒”过程输入一个APK输出一个加固后的APK中间发生了什么并不关心。这种思路在早期简单应用上或许可行但在如今动辄集成十几个SDK、采用混合开发框架如Flutter、React Native、或使用了高级特性如Kotlin协程、R8全模式混淆的现代Android应用上必定会碰得头破血流。正确的思路是将加固视为一个需要精细调控的**“白盒”构建环节**。你需要清楚地知道加固在做什么它不仅仅是加壳还包括代码混淆、资源加密、反调试、签名校验等多重保护。你的应用“怕”什么你的应用有哪些特性如JNI调用、反射、动态加载是与加固的默认行为冲突的如何与加固“对话”通过配置文件、命令行参数、Gradle插件选项告诉加固工具哪些地方需要“特殊照顾”。基于这个思路我们的配置指南将围绕三个核心维度展开兼容性配置、安全性平衡与流程自动化。目标是得到一个既安全可靠又稳定兼容的加固产出物。2.1 理解360加固保的核心处理流程在深入配置之前有必要快速了解一下360加固保以其命令行工具jiagu为例的大致工作流程这有助于理解后续每个配置项的意义解包与分析工具会解压你的APK分析其DEX文件、资源文件、清单文件等结构。DEX保护这是核心。会对classes.dex进行加壳、混淆、虚拟化等处理生成新的DEX或so库。这里最容易引发兼容性问题。资源与文件保护对assets、res目录下的特定资源进行加密或混淆。运行时库注入将加固的运行时库so文件注入到APK中这些库负责在应用启动时解密和加载被保护的内容。重打包与重签名将处理后的所有文件重新打包成APK并使用你提供的签名文件进行重新签名。整个过程尤其是第2和第4步是“坑”的高发区。我们的配置本质上就是在引导工具安全地绕过我们应用的“雷区”。3. 环境准备与工具选择工欲善其事必先利其器。首先确保你使用的是最新的工具旧版本的bug和限制可能让你事倍功半。3.1 获取最新版加固工具不要使用网页版上传加固那不适合自动化也无法进行精细配置。前往360加固保官网下载最新版本的命令行加固工具。通常是一个ZIP包如jiagu_linux.zip(Linux/Mac) 或jiagu_windows.zip。注意务必从官网下载网络上流传的破解版或旧版可能携带恶意代码或存在未知漏洞直接威胁你的源码和证书安全。解压后目录结构通常包含jiagu或jiagu.jar(主程序)jiagu.ini或config.ini(基础配置文件)/libs目录 (依赖库)3.2 Java环境确认360加固保命令行工具基于Java开发需要本地安装JREJava Runtime Environment或JDK。建议使用JDK 8或JDK 11这两个长期支持版本兼容性最广。避免使用过新如JDK 17或过旧的版本。在终端中检查java -version确保输出类似java version 1.8.0_301。3.3 准备签名文件加固过程会破坏原始签名因此必须在加固后重新签名。你需要准备好你的应用签名文件.keystore或.jks以及对应的别名、密钥密码、存储密码。安全建议永远不要将签名密码硬编码在脚本或配置文件中。使用环境变量或构建系统的安全存储如Android Studio的signingConfigs或CI/CD系统的Secret管理来传递密码。准备一个专门的“加固用”签名文件与正式发布签名区分开用于测试加固流程。4. 关键配置解析与避坑实战这是本文的核心。我们将通过一个典型的config.xml或通过命令行参数来逐一拆解关键配置项。以下配置基于我近期项目的实践并附上了每个选项的“潜台词”和“坑点”。4.1 基础配置与登录首先你需要登录你的360开发者账号。通过命令行初始化java -jar jiagu.jar -login 你的账号 你的密码登录信息会保存在本地后续操作无需重复登录。踩坑实录1如果账号开启了二次验证如手机令牌命令行登录可能会失败。解决方案是先在网页端登录一次或者联系客服暂时关闭二次验证不推荐。更稳定的做法是使用**“授权码”**方式。在官网控制台生成一个长期有效的授权码然后使用-import参数导入可以避免密码泄露和二次验证问题。java -jar jiagu.jar -import your_auth_code_file.txt4.2 配置模板生成与结构使用以下命令生成一个默认的配置文件模板java -jar jiagu.jar -config -show这会输出一个XML格式的配置示例。将其保存为jiagu_config.xml我们将在此基础上修改。一个强化版的配置文件骨架如下?xml version1.0 encodingUTF-8? tasks task typereinforce !-- 输入输出路径 -- option namein value/path/to/your/app-release.apk/ option nameout value/path/to/output/dir/ !-- ############### 核心保护配置 ############### -- option namemulti value1/ !-- 多DEX处理模式 -- option namecrash value0/ !-- 崩溃日志抓取0关闭1开启 -- option namex86 value1/ !-- 是否支持x86架构按需开启 -- option namearm64 value1/ !-- 是否支持arm64-v8a必须为1 -- !-- 签名配置 -- sign option namekeystore value/path/to/your.keystore/ option namealias valueyour_alias/ option namepswd value${KEYSTORE_PASSWORD}/ !-- 建议用变量 -- option namealiaspswd value${KEY_PASSWORD}/ /sign !-- ############### 高级白名单配置避坑关键############### -- white-list !-- 关键不混淆/不加密的类或包 -- package namecom.xxx.yourmodel.entity.*/ !-- 实体类JSON序列化需要 -- package namecom.xxx.yourmodel.BuildConfig/ !-- 构建配置类 -- class nameandroidx.startup.Initializer/ !-- Jetpack Startup组件 -- !-- JNI方法所在的类必须加入 -- class namecom.xxx.jni.NativeHelper/ !-- 反射调用的类如一些工厂类、路由表 -- class namecom.xxx.router.RouterTable/ !-- 第三方SDK要求不混淆的类参考其文档 -- package namecom.google.android.gms.ads.*/ package namecom.tencent.mm.opensdk.**/ /white-list !-- 资源文件保护配置 -- resource option nameassets value0/ !-- assets目录保护0关闭 -- option nameres value0/ !-- res目录保护0关闭 -- option namefilter value*.png, *.jpg, *.so/ !-- 不处理的文件 -- /resource !-- ############### 特定功能配置 ############### -- option namewebview value1/ !-- 如果用了系统WebView建议开启 -- option namedebuggable valuefalse/ !-- 加固后是否可调试必须false -- /task /tasks4.3 多DEX处理 (multi) 与64位支持 (arm64)option namemulti value1/是什么指定对多DEX应用的处理模式。value1通常表示“自动处理多DEX”。为什么现代Android应用方法数超限普遍使用MultiDex。如果这里配置不当加固后可能导致NoClassDefFoundError。避坑指南永远设置为1。如果你遇到加固后启动崩溃提示主DEX找不到某个类可以尝试结合下面的白名单将Application类及其直接引用的类加入白名单。option namearm64 value1/是什么是否生成支持arm64-v8a架构的加固库。为什么Google Play从2019年就要求上架应用必须支持64位。国内主流应用商店也已跟进。必须设为1。联动坑开启arm641后请务必检查你项目中jniLibs目录或第三方SDK是否提供了对应的64位so库。如果只有32位的so (armeabi-v7a)加固包在64位设备上运行可能会找不到原生库而崩溃。解决方案是要求SDK提供商提供64位库或过滤掉64位架构不推荐可能被应用市场拒绝。4.4 白名单配置 (white-list)最大的坑王这是整个配置文件的灵魂所在90%的兼容性问题都源于此配置不全或不准。加固工具的混淆和加密功能非常激进会破坏那些依赖“字符串匹配”或“运行时结构稳定”的代码。白名单配置原则反射相关任何通过Class.forName(),getMethod()等方式动态调用的类、方法、字段其名称必须保持原样。JNI相关Java层的Native方法声明类 (native关键字修饰的方法所在的类)必须加入白名单。因为C/C代码通过JNIEnv-GetMethodID查找方法时依赖的是混淆前的名称。序列化/反序列化所有用于JSON如Gson、Jackson、Parcelable、Serializable的实体类Data Class其字段名通常需要保持稳定。至少要把这些类本身加入白名单防止类名被混淆。字段名是否混淆取决于序列化库的配置如Gson的SerializedName。动态加载如果你使用了插件化、热修复框架如Tinker、Sophix那些需要从APK外部加载的类其类名和包路径必须保持不变。第三方SDK要求几乎所有第三方SDK的集成文档里都会有一节“Proguard/R8 Rules”里面列出的-keep规则同样适用于360加固保的白名单。你需要将这些类或包名翻译成package name.../或class name.../的格式加入到配置中。实操心得如何快速确定白名单从崩溃日志反推加固包测试时出现ClassNotFoundException,NoSuchMethodError日志里会给出缺失的类名或方法名直接加入白名单。扫描代码在项目中全局搜索Class.forName、getDeclaredMethod、getField等关键字找出所有硬编码的字符串类名/方法名。依赖分析检查build.gradle中所有第三方库的官方文档收集它们的混淆保持规则。最笨但最有效的方法在测试阶段将白名单范围放得很宽如com.yourcompany.*让加固生效但混淆减弱。然后逐步缩小范围直到找到引发问题的那个最小类集合。4.5 资源文件保护 (resource)option nameassets value0/与option nameres value0/是什么是否对assets和res目录下的文件进行加密。为什么默认建议关闭设为0性能开销运行时解密资源会有轻微性能损耗。兼容性风险某些第三方库或框架如一些游戏引擎、WebView加载本地HTML可能直接通过文件路径访问资源加密会导致访问失败。必要性低APK中的资源文件图片、布局XML本身是编译后的二进制格式可读性已不高加密的边际收益有限。何时开启如果你的APK包含非常关键的、不希望被直接提取的配置文件、脚本或密钥文件但请注意密钥硬编码在APK中本身就不安全可以单独开启assets保护并通过filter排除其他文件。4.6 签名配置 (sign)这里有一个巨坑加固工具的重签名操作可能会破坏Android V2/V3签名方案APK Signature Scheme v2/v3。现象加固后的APK在Android 7.0Nougat及以上设备安装时可能会提示“安装包解析错误”或“安装包已损坏”。原因V2/V3签名是对整个APK文件ZIP结构进行签名。加固工具修改了APK内部文件后如果没有正确处理签名块就会导致签名失效。解决方案确保使用最新版加固工具新版本通常对V2/V3签名支持更好。在加固命令中显式指定签名方案如果工具支持。查看帮助文档java -jar jiagu.jar -help寻找是否有-v2sign或-signscheme相关参数。终极方案先加固后手动签名。这是最可靠的方法。步骤一在加固配置中不配置sign部分或者使用一个临时测试签名。步骤二对加固输出的、未签名的APK或使用测试签名的APK使用Android SDK的apksigner工具进行正式的V2/V3签名。# 使用 apksigner 进行签名 (Android SDK Build-Tools 中) apksigner sign --ks your.keystore --ks-key-alias your_alias --out signed.apk unsigned.apk验证签名签名后使用apksigner verify -v your_signed.apk检查是否包含V2/V3签名。重要提示绝对不要用jarsigner工具对加固后的APK进行签名因为它只提供旧的V1签名无法生成V2/V3签名在高版本系统上一定会出问题。5. 集成到自动化构建流程CI/CD手动操作容易出错将加固集成到CI/CD如Jenkins、GitLab CI、GitHub Actions中是专业团队的标配。这里给出一个基于Shell脚本和Gradle的集成思路。5.1 基于Gradle Task的自动化在项目的app模块的build.gradle中添加一个自定义Taskandroid { // ... 你的其他配置 signingConfigs { release { storeFile file(path/to/your.keystore) storePassword System.getenv(STORE_PASSWORD) keyAlias your_alias keyPassword System.getenv(KEY_PASSWORD) } } buildTypes { release { signingConfig signingConfigs.release // ... 其他配置 } } } task reinforce360(type: Exec) { dependsOn assembleRelease // 依赖Release构建 group build description 使用360加固保加固Release APK // 定义路径变量 def jiaguDir file(/opt/tools/360jiagu) // 加固工具目录 def jiaguJar new File(jiaguDir, jiagu.jar) def configFile new File(jiaguDir, jiagu_config.xml) def inputApk file(${buildDir}/outputs/apk/release/app-release.apk) def outputDir file(${buildDir}/outputs/jiagu/) // 确保输出目录存在 outputs.dir outputDir commandLine java, -jar, jiaguJar.toString(), -config, configFile.toString(), -in, inputApk.toString(), -out, outputDir.toString() // 可以添加更多参数如 -config -show 来指定配置 // 环境变量传递密码示例更安全的方式是用CI系统变量 environment KEYSTORE_PASSWORD, System.getenv(KEYSTORE_PASSWORD) environment KEY_PASSWORD, System.getenv(KEY_PASSWORD) doFirst { if (!inputApk.exists()) { throw new GradleException(Input APK not found: ${inputApk}) } println 开始加固: ${inputApk.name} } doLast { println 加固完成输出目录: ${outputDir} // 这里可以添加自动签名步骤调用apksigner } }然后你可以在终端运行./gradlew reinforce360来完成构建和加固。5.2 CI/CD管道示例GitHub Actionsname: Build and Reinforce on: push: tags: - v* jobs: build-and-reinforce: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up JDK 11 uses: actions/setup-javav3 with: java-version: 11 distribution: temurin - name: Setup Android SDK uses: android-actions/setup-androidv2 - name: Grant execute permission for gradlew run: chmod x gradlew - name: Build Release APK run: ./gradlew assembleRelease env: STORE_PASSWORD: ${{ secrets.STORE_PASSWORD }} KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }} - name: Download 360 Jiagu CLI run: | wget -O jiagu.zip https://官方下载链接/jiagu_linux.zip # 请替换为真实链接 unzip jiagu.zip -d /opt/360jiagu chmod x /opt/360jiagu/jiagu.jar - name: Configure 360 Jiagu run: | cd /opt/360jiagu # 使用授权码登录更安全 echo ${{ secrets.JIAGU_AUTH_CODE }} authcode.txt java -jar jiagu.jar -import authcode.txt # 复制预定义好的配置文件 cp $GITHUB_WORKSPACE/jiagu_config.xml . - name: Reinforce APK run: | cd /opt/360jiagu java -jar jiagu.jar -config jiagu_config.xml \ -in $GITHUB_WORKSPACE/app/build/outputs/apk/release/app-release.apk \ -out $GITHUB_WORKSPACE/app/build/outputs/jiagu/ env: KEYSTORE_PASSWORD: ${{ secrets.STORE_PASSWORD }} KEY_PASSWORD: ${{ secrets.KEY_PASSWORD }} - name: Re-sign with APKSigner (V2/V3) run: | cd $GITHUB_WORKSPACE # 找到加固输出的APK通常名字会变 REINFORCED_APK$(find app/build/outputs/jiagu -name *jiagu*.apk | head -1) # 使用apksigner重新签名 $ANDROID_HOME/build-tools/30.0.3/apksigner sign \ --ks keystore.jks \ --ks-pass pass:${{ secrets.STORE_PASSWORD }} \ --ks-key-alias your_alias \ --key-pass pass:${{ secrets.KEY_PASSWORD }} \ --out app-release-reinforced-signed.apk \ $REINFORCED_APK - name: Upload Artifact uses: actions/upload-artifactv3 with: name: reinforced-apk path: app-release-reinforced-signed.apk这个流程实现了从代码到加固签名APK的全自动化确保了流程的一致性和可重复性。6. 加固后的测试与验证清单加固完成并不意味着万事大吉必须进行严格的测试。以下是一份必须执行的检查清单测试类别测试项目预期结果与排查方法安装与启动在Android 5.0, 7.0, 9.0, 11.0, 13 等多个版本的真机/模拟器上安装。能正常安装、启动无“解析包错误”。重点测Android 7.0验证V2/V3签名。基础功能遍历所有主要Activity、Fragment。测试网络请求、数据加载、UI交互。功能正常无闪退。关注白名单遗漏导致的ClassNotFoundException。JNI/NDK测试所有依赖原生库的功能如音视频处理、图像识别。功能正常。如果崩溃检查对应Java类是否在白名单中以及so库架构是否齐全。反射与动态代理测试使用了反射、动态代理如Retrofit接口、AspectJ等技术的功能。功能正常。此类问题最隐蔽需结合运行时日志和白名单配置仔细排查。第三方SDK测试登录、支付、推送、分享、地图、统计等所有集成的SDK。SDK功能全部正常。将各SDK官方要求的-keep规则全部加入白名单。性能与体积对比加固前后APK体积。测试启动速度、页面跳转流畅度。体积增长在合理范围通常增加2-5MB。启动时间无明显劣化200ms。安全扫描使用其他安全扫描工具如腾讯御安全、爱加密在线检测对加固包进行扫描。无“未加固”或“保护强度弱”的告警。确保加固确实生效。一个必备的调试技巧开启加固日志在加固配置中可以尝试寻找开启调试日志的选项有时在config.ini中或通过-debug命令行参数。加固工具运行时输出的详细日志能帮你看清它具体处理了哪些类、哪些方法对于定位白名单问题有奇效。7. 常见问题与排查技巧实录这里记录了几个最让人头疼的“坑”及其解决方案。问题一加固后App启动立刻闪退日志显示java.lang.NoClassDefFoundError或java.lang.NoSuchMethodError。原因这是最典型的白名单配置不全。加固工具混淆或加密了某个类/方法但运行时可能是通过反射、JNI或框架初始化需要按原名称查找找不到就崩溃。排查查看崩溃堆栈找到缺失的类名或方法名。如果堆栈信息被混淆尝试在测试手机连接电脑使用adb logcat | grep -i classnotfound\|nosuchmethod过滤更底层的错误信息。将缺失的类或它的父类、接口加入白名单。如果是第三方库去查该库的官方混淆规则。问题二在Android 7.0及以上系统安装失败提示“安装包解析错误”。原因V2/V3签名被破坏。解决使用apksigner verify -v your.apk检查加固后APK的签名方案。如果只有v1 scheme说明有问题。采用“先加固后手动用apksigner签名”的流程。确保构建环境中的apksigner版本与build-tools版本匹配。问题三集成热更新如Tinker后加固包无法应用补丁。原因热更新框架通常需要对比基线包和补丁包的类与方法差异。加固工具的深度混淆和加密改变了类与方法的特征导致差异计算失败。解决严格遵循热更新框架的“加固配置指南”。以Tinker为例它要求将tinkerId、Application及其入口类、AssetManager等加入白名单。将热更新框架自身的所有类如com.tencent.tinker.**加入白名单。与热更新框架的打包流程顺序很重要。标准流程是打基线包 - 加固基线包 - 发布基线包 - 基于源码打补丁包 - 加固补丁包。切记补丁包也需要用完全相同的加固配置进行处理问题四加固后APK体积增加过多如超过10MB。原因主要来自加固运行时库so文件的注入。360加固保会为每个支持的CPU架构注入一个so库。优化检查option namex86 value1/。如果你的用户几乎没有x86架构的设备如Intel芯片的平板可以将其设为0减少一个架构的so库。检查资源文件保护是否不必要地开启了。关闭assets和res保护能减少一些体积和运行时开销。在resource的filter中排除掉已经压缩过的文件如*.so,*.zip避免重复压缩。问题五使用Flutter或React Native等跨平台框架开发的应用加固后白屏或JS加载失败。原因这些框架的JavaScript/Flutter引擎可能需要从assets目录加载特定的脚本或资源文件如flutter_assets、index.android.bundle。加固工具对assets的加密可能破坏了文件的读取。解决在配置文件中将资源保护关闭option nameassets value0/。如果出于安全考虑必须保护assets则使用filter精确排除框架所需的文件例如option namefilter valueflutter_assets/**, jsbundles/**/。最后记住一个核心原则加固配置是一个与你的应用特性深度绑定的过程没有放之四海而皆准的“最佳配置”。本文提供的指南和避坑点是你构建自己稳定加固流程的起点。最好的方法是为你的项目建立一个专门的、版本化的加固配置文件并随着每次引入新的第三方库或使用新的技术特性不断更新和完善你的白名单。把这个过程也纳入你的开发流程加固这件事才能真正从“玄学”变成“科学”。
