【鸿蒙心迹】鸿蒙应用签名与上架——AGC 配置全流程及 5 个高频驳回原因逐个拆解(HarmonyOS 7.x)
摘要: 应用开发完,卡在上架环节整整一周:第一次提交被驳回(签名错误)、第二次被驳回(缺隐私政策)、第三次被驳回(权限声明过度)……每次驳回都要等 1-3 天审核,来回折腾了一周。后来我把华为应用市场的驳回原因做了系统整理,发现90% 的驳回都集中在 5 类问题上,全是提交前可以自查的。本文用第一人称复盘我的上架过程:从开发者实名认证、AGC 项目创建、证书签名配置,到构建 Release 包与提交审核,重点拆解 5 个高频驳回原因与整改方案,附完整材料清单与自查清单,帮你一次过审。
适用版本: HarmonyOS NEXT 7.x / AGC / 华为应用市场(2026 年政策,以官方最新为准)
难度等级: ⭐⭐ | 前置知识: 建议先阅读第 1 篇《环境搭建与工程结构》——本文是上架实操篇,不涉及 ArkUI 编码
开篇:包构建好了,上架被驳回 3 次
“你的应用被驳回了,原因见邮件。”
2026 年 8 月下旬,涟漪睡眠 App 开发完,我提交了华为应用市场审核。两天后收到驳回邮件,附件里是审核截图,红字标注:“签名与上传包不一致”。
我一脸懵:签名不是自动生成的吗?怎么会不一致?后来才发现,我在 DevEco Studio 里改了 bundleName 后没有重新生成签名,导致上传的包用的是旧证书。
这只是我上架噩梦的开始。接下来一周,我又被驳回了两次,三次驳回的原因和成本是这样的:
| 次数 | 驳回原因 | 处理成本 |
|---|---|---|
| 第 1 次 | 签名与上传包不一致 | 重签 + 重新上传,等 2 天 |
| 第 2 次 | 缺少隐私政策链接 | 补页面 + 重新提交,等 2 天 |
| 第 3 次 | 权限声明与实际使用不符 | 改权限 + 重新提交,等 3 天 |
一周时间全耗在等审核上。痛定思痛,我把上架全流程和驳回原因整理成了系统清单,后面 3 个同事上架全部一次过审。这篇文章就是这套流程的完整版。
先看全局:鸿蒙应用的签名体系围绕 AGC 展开——证书证明开发者身份,Profile 把证书和包名绑在一起,签名配置再把两者接到构建流程上。理清这四者的关系,后面所有的驳回问题都有了解释框架。

一、上架前准备:实名认证与 AGC 项目
1.1 开发者实名认证
坑 1:实名认证不提前做,卡在最后一步
我的第一个教训:应用开发完才去实名认证,认证审核又等了 2 天。实名认证应该项目启动第一天就做,和开发并行。
1.2 AGC 创建项目与应用
AGC(AppGallery Connect)是上架的中枢:项目和应用在这里创建,包名在这里登记,证书和 Profile 也在这里管理。这一步唯一要死磕的就是包名一致性。
入口: AppGallery Connect (AGC) → 我的项目 → 创建项目
流程: 创建项目 → 添加应用 → 填写应用信息(包名/名称/图标)
包名: 必须与工程 bundleName 完全一致(含大小写)
坑 2:AGC 包名与工程 bundleName 不一致
现象: 上传安装包时报"包名与应用不匹配"
根因: AGC 里填的包名和工程 AppScope/app.json5 的 bundleName 不一致
解法: 两边严格一致;改任何一边都要同步另一边的签名
为什么包名不一致会导致签名失效?因为 Profile 是绑定具体包名下发的——包名一改,旧 Profile 就不再匹配新包名,构建出的包自然过不了 AGC 的校验。这也是我第一次被驳回(“签名与上传包不一致”)的根本机制。
二、证书与签名配置(易出错的环节)
2.1 证书体系总览
签名配置的完整链路如下图:证书和 Profile 从 AGC 下发,汇入工程的 signingConfigs,再按构建类型分流成调试包和上架包。

| 证书 | 用途 | 生成方式 | 我的踩坑 |
|---|---|---|---|
| Debug 证书 | 开发调试 | 自动签名生成 | — |
| Release 证书 | 上架发布 | AGC 手动创建 | 私钥丢了无法补(坑 3) |
| Profile | 绑定证书+包名 | 自动/手动 | 改包名后必须重建 |
2.2 自动签名(DevEco Studio 推荐方式)
DevEco Studio → File → Project Structure → Signing Configs
→ 勾选 Automatically generate signature
→ 登录华为账号 → 自动完成 证书+Profile 关联
注意:自动签名生成的是调试证书,只绑定调试设备、用于真机调试,AGC 提审时上传的必须是发布证书签的包——发布证书只能在 AGC 手动创建,这是两种证书用途上的硬性区分。
坑 3:Release 私钥丢失,应用无法更新
这是我见过代价最大的签名事故,值得单独展开:
现象: 应用上架后想发新版本,但找不到当初签名的私钥文件
根因: Release 证书私钥只保留在签名时那台机器,丢了无法补签
解法: 私钥文件(.p12)多副本备份(网盘+U 盘);换电脑前先导出
2.3 发布证书(Release)
入口: AGC → 用户与访问 → 证书管理 → 创建证书
要点: 生成 .cer 和 .p12;.p12 的密码要记牢,丢失无法找回
三、构建 Release 包与提交审核
3.1 构建签名 Release 包
构建本身不难,难的是"传什么、怎么验"。下图是提交审核的完整决策路径——每种驳回原因对应一条整改回流线,从图里能直观看出:所有驳回最终都回到"重新提交"这一个节点,整改质量决定你要绕几圈。

具体的构建方式有两种,界面操作或命令行二选一:
DevEco Studio 中:Build → Build Hap(s)/APP(s) → Build APP(s)
或命令行构建:
hvigorw assembleApp --mode module -p product=default
构建产物路径:
entry/build/default/outputs/default/xxx-signed.app
提交前必做(每一条都有明确的"为什么"):
# 1. 验证包名与 AGC 一致
grep bundleName AppScope/app.json5
# 2. 验证签名(用 keytool 查看证书指纹)
keytool -printcert -jarfile xxx-signed.app | grep SHA256
# 3. 真机安装验证(提交前必装一次)
hdc install xxx-signed.app
3.2 提交审核材料清单
| 材料 | 要求 | 易漏点 |
|---|---|---|
| 应用图标 | 512×512,无圆角 | 用带圆角的图会被驳回 |
| 应用截图 | 手机/平板各 2-5 张 | 需含真实功能界面 |
| 隐私政策 | 可访问的网页链接 | 必须有独立 URL |
| 应用介绍 | 简要 + 详细 | 不能夸大功能 |
| 权限说明 | 逐项声明用途 | 与实际调用一致 |
3.3 提交后审核流程
提交后的审核链路是:开发者上传材料,AGC 分发到审核侧,审核结果按原因分流——这个过程我踩过的每一类驳回,都对应下面时序图里的一条回流线。

提交 → 机审(几小时)→ 人审(1-3 天)→ 通过/驳回
驳回会附截图与原因,按原因整改后重新提交
四、5 个高频驳回原因与整改方案
驳回 1:签名错误,安装包无法安装
现象: 审核机安装失败,提示签名验证失败
根因: 上传的包签名与 AGC 登记不一致(改过 bundleName/换过机器)
整改: 重新自动签名 → 重新构建 → 本地 hdc install 验证通过后再传
验证: 整改后先 keytool 对比包的证书指纹与 AGC 登记一致,再 hdc install 真机装一次,装得上才传
驳回 2:缺少隐私政策
现象: 驳回截图标注"未提供隐私政策链接"
根因: 上架信息里没填隐私政策 URL,或链接无法访问
整改: 部署一个可公开访问的隐私政策页面,URL 填入上架信息
验证: 用浏览器无痕模式打开该 URL 确认可访问,并核对页面含下方 5 项要素、应用内也留了入口
整改模板(隐私政策必须包含的 5 项):
1. 收集哪些信息(账号、设备信息)
2. 收集目的与用途
3. 第三方 SDK 共享清单(统计/广告)
4. 用户权利(查询/删除/注销)
5. 联系方式与更新日期
驳回 3:权限声明过度
现象: 审核发现申请了相机/定位权限,但功能里没用
根因: module.json5 声明了未实际使用的敏感权限
整改: 只声明实际使用的权限;用到的权限在审核时说明场景
为什么"声明了但没用"也算问题?因为敏感权限一旦声明,用户在安装时就会被告知"该应用可能使用相机",审核侧视同功能承诺——声明了却拿不出使用场景,等于材料自相矛盾。下面是涟漪睡眠实际使用的最小权限集:
// 正确:只声明真实使用的权限
"requestPermissions": [
{ "name": "ohos.permission.INTERNET" },
// 没有相机功能,绝不声明 ohos.permission.CAMERA
]
驳回 4:应用截图与功能不符
现象: 截图是模拟数据/占位图,审核认为货不对板
根因: 截图用的假数据,或包含未上线功能
整改: 截图用真实功能界面 + 真实数据;不展示未实现功能
驳回 5:应用介绍夸大功能
现象: 介绍里写了"AI 智能推荐",实际只是简单排序
根因: 介绍文案夸大,审核实测不符
整改: 文案与实际功能严格对应;AI 类功能需提供说明
五、提交前自查清单(收藏级)
提交前逐项勾选,全绿再点提交:
| # | 检查项 | 检查方法 |
|---|---|---|
| 1 | bundleName 与 AGC 完全一致 | 对比 app.json5 与 AGC |
| 2 | 签名可安装 | hdc install 实测 |
| 3 | 隐私政策 URL 可访问 | 浏览器打开验证 |
| 4 | 权限仅声明实际使用 | 逐个权限对照功能 |
| 5 | 截图真实无占位 | 肉眼检查每张 |
| 6 | 图标 512×512 无圆角 | 尺寸检查 |
| 7 | 版本号高于已上架版本 | versionCode 递增 |
| 8 | 隐私政策含 5 大要素 | 逐项核对 |
| 9 | 介绍文案无夸大 | 与实际功能对照 |
| 10 | 真机回归一遍核心流程 | 安装后走主流程 |
六、总结
| 环节 | 关键动作 | 一句话记忆 |
|---|---|---|
| 前置准备 | 实名认证提前做 | 别等开发完再认证 |
| 签名配置 | Release 私钥多备份 | 私钥丢了无法补 |
| 构建验证 | hdc install 实测 | 本地装不上就别传 |
| 审核材料 | 隐私政策必须有 URL | 5 大要素齐全 |
| 权限声明 | 只用真实权限 | 声明过度必被驳回 |
核心认知: 上架 = 配置一致性(包名/签名)+ 材料完备(隐私/截图/权限)+ 提交前自查。这三件事做对,一次过审是常态——我第一次上架被驳回 3 次、耗时 12 天;后面按清单自查后一次通过、4 天上架。被驳回的原因全部集中在材料侧,没有一个是因为代码问题:上架卡住的大多数情况,问题出在"提交前没按清单自查",而不是应用本身。90% 的驳回都是材料与配置问题,提交前 30 分钟按清单自查一遍,能省下一周。
你上架时被驳回过几次?因为什么原因?评论区聊聊,我帮你分析怎么整改。
边界与已知限制
| 限制项 | 具体表现 | 规避方式 |
|---|---|---|
| 审核政策 | 审核规则持续更新,旧经验会失效 | 提交前查阅官方最新要求 |
| 包名一致 | AGC 包名与工程 bundleName 不一致无法提交 | 构建前统一校验 |
| 证书有效期 | 发布证书与 Profile 有有效期,过期构建失败 | 到期前重新生成并更新配置 |
| 隐私政策 | 必须有可访问 URL,且应用内要有入口 | URL 与应用内入口都要配 |
| 权限声明 | 声明超出实际使用范围必被驳回 | 按最小集申请并写明使用场景 |
| 截图规格 | 尺寸、内容、截图设备不符会被驳回 | 按官方规格出图并复核 |
| 测试账号 | 审核无法登录会直接被拒 | 提供可用演示账号与演示视频 |
| 版本号 | 版本号必须递增,重复无法上传 | 出包前确认 versionCode 已递增 |
政策时效说明: 本文基于 2026 年华为应用市场审核政策。审核规则会更新,提交前务必查阅 AppGallery Connect 官方最新要求。
专栏导航
- 📖 上一篇: 冷启动从 2.8s 优化到 0.9s——耗时拆解与数据对比实战
- 📖 下一篇: 元服务开发与生态变现——免安装卡片实战及五条变现路径对比
更多推荐

所有评论(0)