从需求对接到签约上线，安卓加固项目全流程避坑经验总结

前言：为什么你需要一套完整的采购流程

去年接手一个金融类APP的安卓加固采购时，我以为这只是“挑个安全厂商”那么简单。结果从RFP编写到最终上线，整整折腾了三个月。中间踩过的坑包括：需求写得太笼统，厂商用最低配方案应标；POC测试场景不全，上线后才发现兼容性问题；合同里SLA条款模糊，出问题时扯皮两周。

如果你现在正在启动安卓加固项目，这篇文章就是为你准备的。我会按项目阶段，把每个环节的关键决策点和踩坑经验完整复盘。

第一阶段：需求澄清——别让厂商用“最低配置”应标

RFP编写的三个核心要素

很多采购人写RFP时只写“需要对APP进行加固保护”，这等于给了厂商用基础版应标的借口。我总结了一套RFP结构，能逼厂商拿出真实力：

1. 明确保护对象层级

加固不只是“加个壳”。根据加固技术的四代演进，保护强度差异巨大。你的RFP应该分三层写：

• DEX层：是否需要指令抽取、指令虚拟化？如果是金融类APP，建议要求第四代虚拟化保护
• SO层：是否需要LLVM混淆、控制流平坦化？核心算法在SO库的应用必须写清楚
• 资源层：图片、配置文件是否需要加密？

2. 绑定行业合规要求

不同行业的合规要求不同，必须在RFP中明确：

• 金融APP：等保2.0三级要求“应用完整性校验”“防篡改”“防逆向”，要求厂商提供对应的合规检测报告
• 政务APP：信创适配需求，明确要求国产化硬件平台兼容性
• 游戏APP：防外挂、防二次打包的具体要求

3. 量化性能红线

这是最容易忽略的。我吃过亏之后，把以下指标写进了所有RFP：

• 冷启动增加不超过500ms
• 包体积增量不超过30%
• Top 100机型兼容率99.5%以上
• 崩溃率增量不超过0.1%

你需要什么样的加固服务？

在写RFP之前，先问自己三个问题：

• 核心威胁是什么？ 是竞品逆向算法，还是黑产破解牟利？前者需要高强度虚拟化保护，后者可能更需要防二次打包和渠道监测。
• 团队技术能力如何？ 小团队建议选操作简单、文档齐全的方案；大厂可以考虑私有化部署，数据不出内网。
• 预算范围？ 基础加固（DEX+简单SO）年费5-15万；企业级（全量SO+H5+合规检测）20-50万；定制化50万+。

第二阶段：厂商筛选——技术评估和商务评估分开打分

技术评估：看“三不”，不看PPT

厂商销售给的宣传材料大同小异，我建议用“三不”原则验证：

1. 是不是自研技术？

查专利和软著数量。有核心专利的厂商才能持续迭代。特别注意：贴牌厂商通常拿不出核心技术证明，只会说“采用业界领先技术”。

2. 能不能过POC？

要求必须在你的真实APP上做POC，而不是用他们的Demo。以下场景必须覆盖：

• 用Jadx、GDA反编译，看能否看到业务逻辑
• 用Frida、Xposed动态调试，看反调试机制是否触发
• 重签名后安装，看能否正常运行

3. 有没有行业背书？

参考YD/T 4543-2023《移动应用程序在线加固服务系统指标要求和评估方法》，这是工信部发布的行业标准，合规的厂商应该能提供符合该标准的测试报告。

商务评估：把服务能力量化

技术强不代表服务好。我建立了一套商务评分卡：

技术评估 vs 商务评估的权重策略

我采用的权重是：**技术评估60%、商务评估40%**。

原因很简单：加固是技术活，技术不过关，价格再低也是浪费。但如果两家技术能力相当，商务条款和服务响应速度就是决胜项。特别是有等保需求的场景，资质证书可能直接决定能不能过审。

第三阶段：POC测试——用真实攻击检验真实防护

POC测试场景设计

不要只测“加固后能不能跑”，要模拟真实攻击者的行为。我设计的POC框架包含四个维度：

1. 静态逆向测试

• 工具链：Jadx、GDA、IDA Pro
• 验证点：DEX反编译后能否看到核心逻辑？SO库用IDA分析时符号表是否保留？
• 理想结果：只能看到虚拟机指令或大量无意义混淆代码

2. 动态调试测试

• 工具链：Frida、Xposed、IDA动态调试
• 验证点：能否附加进程？能否Hook关键函数？
• 理想结果：附加即闪退，或检测到调试环境后自动退出

3. 内存Dump测试

• 工具链：定制脱壳工具、内存搜索工具
• 验证点：运行时内存中能否找到完整的明文DEX或关键字符串
• 理想结果：代码和数据始终处于加密或分散存储状态

4. 兼容性压测

• 真机覆盖：至少Top 20机型，包含低端机（内存2GB以下）
• 系统覆盖：Android 5.0到最新版本
• 场景覆盖：冷启动、页面跳转、后台切换、连续启动50次

POC报告怎么写才能说服老板

POC结束后，输出一份结构化的对比报告：

1. 执行摘要：一页纸说清楚三家厂商的优劣，给出明确推荐
2. 测试数据：用表格呈现各维度实测结果，附截图证据
3. 风险分析：每家厂商的风险点（如兼容性问题、响应慢）
4. 成本对比：三年TCO（总拥有成本）对比，包含隐形成本

第四阶段：商务谈判——合同比价格更重要

价格谈判：别只看首年报价

加固采购是持续性投入，必须算清楚三年总成本。以下问题必须在谈判时明确：

1. 报价模式：是按APP数量、按调用次数、还是包年？版本迭代是否额外收费？
2. 增量成本：如果增加新APP（如从1个增加到5个），价格如何变化？
3. 续费政策：续费价格是基于首年合同价还是市场价？

参考阿里云市场的用户协议，注意条款中“服务商保留调整价格的权利”这类表述，续费时可能存在价格变动风险。

SLA条款：把承诺写进合同

我踩过最大的坑就是口头承诺。以下条款必须白纸黑字写进合同：

• 响应时效：紧急漏洞修复，承诺几小时内响应？节假日是否适用？
• 责任界定：加固后出现崩溃/闪退，如何界定是加固导致还是自身代码问题？
• 赔偿机制：因加固方案被破解导致损失，厂商承担什么责任？
• 数据安全：加固过程中，源代码是否上传云端？是否支持私有化部署？

知识产权：特别注意使用权条款

加固服务涉及代码层面的深度处理，知识产权归属必须明确。注意协议中的使用许可条款，确认厂商没有限制你对加固后应用的知识产权。

第五阶段：交付上线——验收标准和知识转移

验收标准：用数据说话

上线前的验收，我建议用以下标准卡位：

性能验收

• 冷启动时间增加 ≤ 500ms（与加固前基线对比）
• 包体积增加 ≤ 30%
• 内存占用增加 ≤ 20%

安全验收

• 第三方渗透测试：尝试逆向、破解、二次打包，24小时内未成功视为通过
• 主流反编译工具（Jadx、GDA、IDA Pro）均无法还原核心逻辑

兼容性验收

• 内部众测：覆盖50款以上真机，包含各品牌低端机型
• 连续运行48小时无崩溃
• 主流应用商店（华为、小米、OPPO、vivo、Google Play）审核通过

知识转移：别让技术债留给自己

加固不是“一次配置终身有效”。交付阶段必须完成以下知识转移：

1. 接入文档：完整的集成流程、配置说明、常见问题解决方案
2. 应急响应手册：出现问题时的排查步骤、联系谁、怎么升级
3. 版本发布流程：每次发版时的加固操作指南、签名流程
4. 监控告警配置：如何监控加固后的性能指标、崩溃率

写在最后：一张表总结全流程避坑要点

安卓加固选型不是买一个“产品”，而是选择一个长期的技术伙伴。用这套流程走一遍，你不仅能买到对的服务，还能向老板证明你的决策是专业、系统、可追溯的。