8.2 签名打包与上架 AppGallery

8.2 签名打包与上架 AppGallery

本节摘要：走完上架全流程：在 AGC 创建应用与发布证书、配置 release 签名、构建发布包并核对包体、准备商店资料与隐私声明、提交审核与处理整改。第 1 章遗留的 release 签名问题在此闭环。

从签名到上架

还记得第 1.2 节结尾那个失败吗——release 构建提示签名缺失，当时说"带着发布证书回来"。现在应用已通过 8.1 的体检，是回来的时候了。整个上架流程分五站：建应用、发证书、配签名、出包、提审。

图：上架五站流程与各站易错点

第一站，建应用。登录 AppGallery Connect，创建项目与应用。关键字段是包名——必须与工程 AppScope 里 app.json5 的 bundleName 完全一致，且一旦上架便不可更改。应用名、图标、分类、简介这些商店资料可以后补，但建议此时就想清楚定位。

第二站，发证书。在 AGC 的证书与 Profile 页面申请发布证书与发布 Profile：先在本机用 DevEco Studio 的密钥工具生成密钥对与证书签名请求文件（CSR），提交后获得发布证书；再创建 Profile，类型选"发布"、勾选这个应用。产物是三样：证书文件、Profile 文件、本机密钥库。密钥库丢了等于丢了发布身份，离线备份且不入仓库（第 1.2 节的纪律再念一遍）。

第三站，配签名。回到工程 build-profile.json5，为 release 产品配置签名（结构同 1.2 节调试签名那段，材料换成发布三件套），或者直接在 IDE 的签名面板以手动方式导入。配好后跑那条第 1 章失败的命令：

hvigorw assembleApp --mode project -p product=default -p buildMode=release
​

这次产物是完整的发布 App 包（.app 文件）。第四站，出包核对：版本号递增了吗（versionCode 是递增的整数，versionName 是给用户看的）；权限清单与 8.1 合规清单一致吗；包体里有没有该剔除的调试资源。第五站，提审：在 AGC 上传包体，补齐截图（多尺寸）、描述、隐私政策链接、内容分级等资料，提交审核。审核周期以工作日计，打回时按意见整改再提交——打回不是失败，是流程的一部分，认真读意见通常能对上 8.1 三张清单里的某一条。

发布之后

上架不是句号。首日盯崩溃与差评：AGC 的崩溃服务能按版本聚合异常堆栈，配合 8.1 的稳定性清单快速止血；用户反馈里性能类评价回到 Profiler 的方法论。版本迭代走同样五站，增量是把关点前移——评审时对照本章清单，别把体检留到提审前夜。

⚠️ 常见坑：把测试通过版直接提审。审核环境与账号和你开发期不同，发布前用"全新安装 + 新用户路径"完整走一遍主流程，能拦住一批"开发机一切正常"的假象问题。

💡 关键直觉：上架流程的本质是"把你的应用放进一个受控的分发管道"——证书管身份，Profile 管授权，审核管质量。每个环节的繁琐都在为"用户装到的就是你发布的那个包"背书，理解了这层，流程就不是负担而是保障。

本节要点回顾：

• 五站流程：建应用（包名定终身）、发证书（发布三件套）、配签名（release 产品）、出包（版本与清单核对）、提审（资料齐则过）。
• 发布签名闭环：第 1 章的 release 构建失败在此解决——AGC 签发的证书与 Profile 替换调试材料。
• 审核对应关系：权限隐私对齐、主流程完整、稳定性、元服务一致性，全部映射到前章清单。
• 密钥纪律：密钥库离线备份、永不入库，丢了等于丢发布身份。
• 发布后动作：崩溃服务盯首日，反馈回流迭代，评审关口前移。

八站全部到站。这本教程从装环境开始，以你的应用出现在应用市场结束——下一次打开 DevEco Studio，就不是学，而是做了。

附：版本管理的两个小机制

上架后的迭代会持续数年，两个小机制趁早建立。其一是版本纪律：versionCode 只增不减、release 分支拉出后冻结功能只进修复——见过太多团队在提审分支上顺手加功能，导致审核中的版本与测试的版本悄然分叉，打回后再也复现不了问题。其二是证书与 Profile 的有效期管理：发布证书有有效期，到期前更新是运维事项而非突发事故，在团队日历上设好提前一个月的提醒，更新后新旧证书的过渡期处理（已上架应用不受影响，新打包用新证）花十分钟读官方说明即可，别等到打包那天才发现。

再补一份提审资料的准备心得。截图要"讲功能"而不是"摆界面"：每张截图对应一个卖点文案，审核员与商店访客都更快理解应用价值；描述里避免堆砌关键词（商店检索有自己的反作弊逻辑，堆砌反而降权）；隐私政策链接指向一个真实可访问、内容与实际数据行为对齐的页面——审核员真的会点开看。资料准备的共同原则是"替看的人省时间"，这与整本教程强调的"显式优于隐式"一脉相承。

附：被拒绝了怎么办

第一次提审被拒是大多数开发者的必经礼。处理流程四步：通读审核意见全文（意见通常直接指明违反的具体条款与位置）；对照 8.1 的三张清单定位问题源头（多数意见能映射到权限、隐私、稳定性之一）；整改后在新版本号下重新提审，并在备注里说明整改点；如果对意见有异议，走申诉通道而不是反复硬提。心态上把审核当成一位严格的代码评审者——他的意见让应用更合规更稳，这与你自己把关的目标并不冲突。

最后给一个从第 1 章贯穿至此的呼应收尾：还记得 1.1 节排错时遇到的那行"signature verify failed"吗？那时它是个拦路虎，如今你已经知道它的完整语境——调试签名的自动机制、发布签名的手动三件套、以及两者之间的分界线。整本教程的路线就是把这样的"黑盒报错"一个个变成"白盒流程"：构建、生命周期、状态、存储、网络、分布式、性能、发布。走完这一程，你与这个平台的关系，就从"被报错追着跑"变成了"知道每个报错住在哪条街上"。

也把导读开篇那句话在这里合上——「一次开发，多端部署」。八章走完，你已经亲手验证了它的前半句（一套 ArkTS 代码贯穿始终），也见过后半句的三种兑现（断点适配的形态切换、跨设备的页面流转、免安装的元服务卡片）。口号变成本领，靠的正是这一路上每一个跑起来的工程、改过的参数、修掉的报错。