功能全部就绪之后发布工程要回答的问题变得朴素这个包真的是我们以为的那个包吗元数据对不对、签名是不是发布证书、内容干不干净、构建新不新鲜。这篇按我们 P7 阶段的真实门禁讲这四问。1. 先搞清楚鸿蒙工程里元数据住在哪Android 开发者迁到鸿蒙第一个容易找错的地方就是版本元数据的位置。鸿蒙 Stage 模型工程的配置是两层AppScope/app.json5 # 应用级bundleName / vendor / versionCode / versionName entry/src/main/module.json5 # 模块级abilities / requestPermissions / deviceTypes关键事实versionCode / versionName / vendor 只在AppScope/app.json5module.json5里没有。新人升版时去 module.json5 里翻 versionCode找不到就自己加一个——编译不一定报错但市场认的还是 AppScope 那份于是我明明升版了后台说 versionCode 没递增的事故就这么发生。另一个三元组也别漏compileSdkVersion/targetSdkVersion/compatibleSdkVersion本工程冻结为 24 / 24 / 23见 ADR-001——targetSdkVersion影响系统的兼容性行为和市场的分发范围发布前要和基线一起核对。发布元数据在 P7 第一天冻结成契约注意是冻结成脚本里的常量不是 Wiki 里的表格# Frozen packaging contract (P7-T01) EXPECTED_BUNDLEcom.xiangshikeji.speaklab EXPECTED_VENDORxiangshikeji EXPECTED_VERSION_NAME1.0.0 MIN_VERSION_CODE1门禁逐项 grepAppScope/app.json5核对bundleName 是否漂移、vendor 是否还是example占位单独一条显式检查——模板工程最常见的发布事故、versionName 精确匹配、versionCode ≥ 基线。几个字段的纪律B01 提过这里按发布视角重申bundleName创建 AGC 应用时与之绑定上架后不可改核对它核对这个包会更新到正确的应用条目下versionCode市场的单调轴AGC 后台强制每次提交递增。门禁只查下界≥1递增靠发布流程纪律——内部用 RC 标签speaklab-1.0.0-rc.N管理候选正式递增发生在提交那一刻vendor审核可见的主体标识example占位会直接暴露没认真准备。2. 签名发布证书是上架与侧载的分水岭鸿蒙的签名体系对新手是一套新概念最小可用的心智模型是四样东西材料来源作用私钥.p12 CSRDevEco 本地生成签名的笔丢了无法续签同一应用发布证书.cer用 CSR 在 AppGallery Connect 申请证明笔属于你发布 Profile.p7bAGC 按 bundleName 证书签发声明这个应用允许被这把笔签build-profile.json5的signingConfigs工程内配置把上面三样接进构建DevEco 默认帮你管一套调试签名自动化申请、7 天有效期的调试 Profile 之类跑真机调试很顺滑但调试证书签的包不能上架。发布构建必须显式切到发布signingConfigs——所以门禁里有一条核对Release 构建配置引用的是发布 profile 路径而不是 DevEco 自动生成的调试材料。纪律有三条签名材料不进仓库.p12/.cer/.p7b 全部 gitignore靠团队密钥渠道分发签名信息不进日志构建脚本不打印 alias 密码等上架前最后核对一遍证书有效期——证书过期导致的更新包签名校验失败是发行期最难看的事故。3. 卫生检查的另一面内容与产物一致性元数据和签名之外卫生门禁还核对一组内容事实Release/Debug/活动三个 composition seam 文件都在B02 的机制赖以存在、凭据控制器和 Preferences port 没有越界B15/B09 的红线、切换/构建/审计三个脚本在位。原则是Release 的干净由一组可枚举的事实构成每个事实都有静态证据。产物层面还有一招值得单独说解包审计。HAP 本质是 zip 结构的包用 SDK 自带的解包工具app_unpacking_tool.jar或干脆 unzip 展开就能核对resources/rawfile/里的词库与法律文本在不在、ets/目录里有没有不该出现的 Debug 夹具模块。我们的双 HAP 隔离审计Debug 包与 Release 包互相核对就是在产物层面证明Fake 夹具物理存在于 Debug 包、物理不存在于 Release 包——不是理论上不会编进去是解开看过了确实没有。门禁文件头还有一句重要自我约束Proves static facts only — never substitutes for device RC matrix.静态门禁证明文件层面的事实它不声称替代真机 RC 矩阵那是 P7-T04 的活。每种验证手段说清自己能证明什么、不能证明什么——这和 B16 的三层区分是同一纪律。4. 干净重建验收构建必须从零开始团队被旧产物冒充新构建坑过之后立了干净重建原则独立验收的构建必须从 clean 开始——hvigorw clean清掉增量缓存最好换临时目录重新检出。禁止拿entry/build/里躺着的旧 HAP 改个名就当验收包。这条原则的深层原因Hvigor 增量构建的缓存里可能留着上一个实验的产物而源码时间戳看不出来B18 讲的变异假存活根因是同一个。你验收的可能是一个从未存在过的源码状态的构建——它通过还是失败都没有意义。我们的构建脚本B01默认先 clean验收场景再加临时目录干净检出并且明确不强制git worktree——手段可以灵活临时目录/清缓存检出均可原则只有一条产物必须能从当前源码完整复现。5. SHA-256 取证让同一个包可引用并分清 HAP 与 App Pack每次验收构建打印 SHA-256B01 的脚本习惯在发布流程里它升级为取证语言任务单里写accept HAP Releasef09f7a65…真机hdc install后核对的也是它。你测的是哪个包这个问题从此一个字的歧义空间都没有。但鸿蒙发布有一个容易混淆的产物差异要说清真机侧载安装的是 HAP上架 AppGallery 提交的是 App Pack.app——后者是assembleApp的产物把各模块 HAP 打包成市场分发格式。两个文件、两个 hash引用时写明是哪个。我们的口径真机 RC 矩阵验收用 HAP 的 hash上架提交记录 App Pack 的 hash任务单里两者并存谁也不冒充谁。双 HAPDebugRelease一起给 hash配合 B02 的隔离审计构成完整的这个包干净且新鲜的证据链。6. 发布前清单AppScope/app.json5bundleName / vendor / versionName / versionCode 门禁全绿SDK 三元组与基线一致签名Release 构建引用发布证书 发布 Profile非调试材料材料不进仓库不进日志三个 seam 文件在位双 HAP 解包审计通过Debug 夹具不进 Release干净重建clean 新鲜源码非旧产物HAP 与 App Pack 的 SHA-256 分别记录进验收文档静态门禁 ≠ 真机验证hdc install真机 RC 矩阵另行执行7. 小结元数据只住AppScope/app.json5module.json5 里没有版本字段别找错地方。发布签名四件套.p12 / .cer / .p7b / signingConfigs调试证书签的包上不了架。卫生可枚举事实的静态证据解包审计把干净从推断变成目击。验收构建必须干净重建SHA-256 是引用构建产物的唯一语言HAP 与 App Pack 分开记。