分类建议：Android / 移动开发 / 信息安全
标签建议：外包交付、APK加固、独立开发者、漏洞扫描、安固云、软件交付
类型：流程分享（可软宣）
相关站点：安固云 APK Guard
系列：[上架前 APK 安全自检清单] · [加固后怎么验收] · [个人包加固流程]
从「个人开发者变多」说起
这几年接私活、做配套 App 的人明显多了：一个人兼产品、开发、上架；或者两三人的工作室，按月交付几个 Android 包。
客户侧也在变。以前口头说「我们做了加固」往往够用；现在常见追问是：
- 「有没有安全扫描报告？」
- 「加固后签名还是我们的吗？」
- 「以后换开发者，证书会不会丢、包能不能更新？」
这些问题背后，其实都不是技术炫技，而是 交付物能不能留痕、能不能对账。
我后来把外包收尾固定成 三样东西 + 一页签字确认——不夸大成「等保报告」，但足够把「做过什么、没做什么」写清楚，减少扯皮。
先说结论：三样东西分别回答什么
| 交付物 | 客户真正想问的 | 你这边要证明的 |
|---|---|---|
| ① 扫描报告 | 上架前有没有明显裸奔问题 | 密钥/权限/组件等已自检，有 PDF 或 HTML 可归档 |
| ② 加固记录 | 有没有做壳、防二次打包 | 任务时间、档位、包名版本、产出 APK 指纹可对上 |
| ③ 重签说明 | 证书有没有被拿走、以后谁维护 | keystore 仍在客户侧；加固后由客户本机重签 |
三样齐全，再配 一页《交付确认单》 让客户签字（或邮件确认）。比堆功能表像样，也比空口承诺安全。
① 扫描报告：加固之前做，别倒顺序
原则：扫描尽量在加固前。 加固抬高逆向成本，修不掉业务里的明文密钥和乱权限。
我建议报告里至少能对应这几类
| 类别 | 客户看得懂的一句话 |
|---|---|
| 明文密钥 / 硬编码 | 「Release 包内未发现明显明文 API Key」或「发现 N 处，已修复 / 已写入风险说明」 |
| 权限与导出组件 | 「权限清单与业务匹配；无多余 exported 组件」 |
| 防护面（可选） | 「壳、完整性、环境检测等项已评估」——见站点「防护等级」类报告 |
| 版本信息 | 包名、versionName / versionCode、扫描时间 |
实操（我用的路径）
- 在 安固云 登记 包名资产
- 上传 加固前的 Release 已签名 APK
- 跑 漏洞扫描 或 防护等级评估（重要版本我两个都跑；赶时间至少跑一个）
- 下载 PDF / HTML 摘要，文件名带上：
项目名_包名_版本_扫描日期
交付时说明边界（建议原话写进邮件）：
本报告为应用层与防护面自检，不是渗透测试或等保测评；发现项已在发版前处理或列入后续迭代。
更细的本地自检项，可对照系列文 [《上架前 APK 安全自检清单》]
② 加固记录：证明「这一版确实加固过」
客户不需要懂 DEX 加密细节，但需要 可对账：哪天上传的、用的什么档、下的是哪个包。
加固记录我建议固定包含
| 字段 | 示例 | 用途 |
|---|---|---|
| 项目名称 | XX 物流客户端 | 归档 |
| 包名 | com.example.app | 与商店一致 |
| 版本 | 5.5.1 (141) | 与 changelog 一致 |
| 加固时间 | 2026-09-03 14:20 | 任务历史截图或导出 |
| 加固档位 | 普通版 / 更高档 | 与合同或报价一致 |
| 加固前 APK SHA256 | abc… | 防混包 |
| 加固后未签名包 SHA256 | def… | 云端产出 |
| 最终上架 APK SHA256 | 789… | 重签后客户侧指纹 |
| 验收摘要 | jadx 无业务明文 / 换签测试失败 / 真机主流程通过 | 见下一节 |
任务截图 vs 表格
- 对内：任务历史一页截图即可
- 对客户：用上面表格做成 一页 PDF（Excel 导出也行），比丢一个 APK 更有说服力
档位怎么选、普通版够不够，可参考 [《中小企业怎么选加固网站》]；加固后怎么验，见 [《加固后验收清单》]。
边界（务必写进交付说明）
- 加固 提高逆向与二次打包成本，不承诺绝对防破解、绝对防 Frida
- 加固 不能替代 业务代码里的密钥规范与服务器鉴权
③ 重签说明：最容易被问，也最容易误会
很多客户听到「云端加固」就紧张：我的 keystore 要不要上传？以后还是不是我的包？
我交付时固定附 《重签与证书说明》 半页纸，核心就四句：
- 加固平台返回的是未签名 APK（或需客户本机重签的包）
- keystore 仅在客户本机使用，不出开发机/不出云
- 必须使用与原包相同的签名证书，否则完整性校验失败、无法覆盖安装
- 证书由客户保管；后续版本升级、渠道更新均依赖同一 keystore
建议附一张「流程示意图」（口述也行）
客户 Release APK（已签名）
→ 云端加固（密文壳 + 完整性绑定原证书指纹）
→ 下载未签名包
→ 客户本机用同一 keystore 重签
→ 真机验收 → 交付 / 上架
常见客户问题（可直接复制到 FAQ）
| 客户问 | 建议答法 |
|---|---|
| 证书给你们安全吗？ | 不上传；重签在您本机完成，我们只接触加固任务记录 |
| 加固后还能不能我们的人维护？ | 可以；源码与 keystore 仍在您侧，加固只影响发布包 |
| 换一家加固行不行？ | 可以，但需重新走加固与验收；证书仍须保持不变 |
| 为什么加固包比原来大？ | 多了壳与密文载荷，见验收清单体积对比，一般可接受 |
一页《交付确认单》模板（可打印）
下面是我精简版，签字前让客户提供 keystore 保管确认（若证书本就在客户处）。
项目名称： _______________
包名： _______________
交付版本： _______________
交付日期： _______________
开发方确认已交付：
| ☐ | ① 上架前扫描报告（附件：___________） |
|---|---|
| ☐ | ② 加固记录（含加固时间、档位、APK 指纹） |
| ☐ | ③ 重签与证书说明（keystore 由 ______ 方保管） |
| ☐ | 加固后真机主流程验收通过（机型：___________） |
客户确认：
- 已收到上述材料，理解加固与扫描的适用范围（非等保/渗透报告）
- 已知后续版本升级须使用 同一签名证书
- 签字 / 日期：_______________
个人开发者为什么更该做这套
| 场景 | 不做三件套的风险 | 做了之后 |
|---|---|---|
| 私活交付后失联 | 客户以为「没做安全」 | 报告 + 记录可归档 |
| 二开换人 | 新开发质疑旧包来源 | SHA256 + 加固时间可对账 |
| 压价「加个固就行」 | 范围不清，无限加需求 | 档位、验收写进确认单 |
| 自己也是老板 | 半年后忘了这版做没做扫描 | 文件夹里能翻出来 |
一个人扛开发时，流程短不等于不留痕。三样东西加起来，熟练后 多半小时（扫描排队另算），但能省后面几小时的解释成本。
和我用的工具怎么对应（非唯一答案）
我目前把 扫描 + 加固 + 任务历史 放在同一账号里完成，省得 A 站扫、B 站加固、C 站找记录：
- 扫描 / 防护评估 → 对应 ① 扫描报告
- 加固任务与下载记录 → 对应 ② 加固记录
- 默认 本地重签 说明 → 对应 ③ 重签说明
你也可以用自己的工具链，只要三样东西 内容齐、边界清 即可。不必为软文强行换平台。
边界（建议原文放进交付邮件）
- 三件套 不是 金融级安全认证，不能 替代专业渗透或等保测评
- 政企 禁止 APK 出内网 的项目，云端加固/扫描可能不适用，需私有化或离线方案
- 加固提高成本，不保证 无人为破解；业务侧仍须做好服务端鉴权与密钥管理
- 用途须合法正版 App；禁止用于恶意软件
结语
个人开发者和小工作室接 Android 外包，竞争往往不在「会不会加固」，而在 交付是否专业、是否可追溯。
我现在收尾固定三样：
扫描报告（加固前） + 加固记录（可对账） + 重签说明（证书不出本机）
再让客户签一页确认单。不吹「最强」，但比一句「放心，我们加固了」经打。
若你也在接私活，可按项目改一版 PDF 模板复用。更完整的自检与验收，见本系列 [上架前清单]与 [加固后验收]。
试用扫描 + 加固 + 任务留痕
