非 HNP 二进制在 HarmonyOS 7 怎么签：把权限策略、证书和产物校验串成一条链

有些项目不使用 HNP，而是在安装包中携带独立工具。迁移 API 26 时，团队只给主应用重新签名，bin 文件本身仍没有权限策略段；另一些项目签了 bin，却把调试证书、权限 JSON 和最终打包产物混在不同流水线，导致本地通过、发布包失败。非 HNP 场景要使用官方 binary-sign-tool，将权限策略文件作为 moduleFile 参与签名，并校验证书与最终产物。

签名通过不等于权限完整

关注点	正确理解	容易误判
输入产物	未签名 bin + 权限 JSON	两者都应有哈希和版本
签名材料	p12、证书、别名和算法	不得写入仓库或日志
输出产物	签名后的独立二进制	打包前再次校验

这张表的作用不是替代官方接口文档，而是把平台边界翻译成项目可以执行的判断。升级适配先确认触发条件，再决定代码改动；没有进入触发条件的模块，不应为了“看起来统一”被一起重写。

非 HNP 二进制的签名链

构建流水线可以先验证权限 JSON 结构和允许列表，再进入受控签名环境。不要让业务仓库保存密码，也不要把完整命令行连同凭据打印到日志。

type SignPlan = { inputHash:string; policyHash:string; alias:string; outputName:string };
function stablePlan(p: SignPlan): string {
  if (!/^[a-f0-9]{8,64}$/.test(p.inputHash) || !/^[a-f0-9]{8,64}$/.test(p.policyHash)) throw new Error('hash invalid');
  return [p.inputHash,p.policyHash,p.alias,p.outputName].join(':');
}
const key = stablePlan({inputHash:'a1b2c3d4',policyHash:'e5f6a7b8',alias:'release',outputName:'signed-tool'});
if (!key.includes('signed-tool')) throw new Error('签名计划异常');

示例故意把平台调用外面的决策抽成纯函数：一方面能在没有设备时先验证分支，另一方面能清楚标记哪些结论仍需 API 26 编译和真机证据。

把权限策略做成构建产物

签名完成后仍需做产物校验：文件是否被后续步骤替换、权限段是否存在、证书是否为预期环境、包内路径是否指向签名版本。只验证 binary-sign-tool 返回 0 不足以证明最终安装包正确。

type Artifact = { expectedHash:string; packagedHash:string; permissionSection:boolean; certEnv:'debug'|'release' };
function releasable(a: Artifact): boolean {
  return a.expectedHash === a.packagedHash && a.permissionSection && a.certEnv === 'release';
}
if (releasable({expectedHash:'a',packagedHash:'b',permissionSection:true,certEnv:'release'})) throw new Error('被替换产物不能发布');

真实工程还要把超时、重复回调、前后台切换和版本回退纳入测试。只跑一次成功流程，无法证明升级后的边界已经被正确处理。

失败时该看哪一层

最可靠的做法是让签名产物不可变，后续打包只消费其哈希标识。权限策略、证书环境和二进制版本一起进入发布证据，运行时再验证成功与拒绝两条路径。

建议把适配封装成“平台边界层 + 稳定业务语义 + 页面展示”三段。平台变化只修改第一段；业务语义通过枚举或结果对象表达；页面不直接比较底层错误码、权限字符串或系统版本。这样既能复用，也能在下一次版本升级时快速定位。

发布前检查清单

• 官方变更是否真的作用于当前 target、应用模型与产品品类。
• 两个案例是否分别覆盖成功路径和容易误判的失败路径。
• 代码中的常量、权限和错误码是否来自当前接口文档，而不是旧博客。
• 降级方案是否保持数据正确、交互可理解，并且不会扩大权限。
• 目标设备验证结果是否与宿主逻辑测试分开记录。

复现与对照怎么做

先准备一组最小输入，只保留本文讨论的一个变化点；再准备一组接近生产的组合输入，加入页面切换、重复调用、取消或权限拒绝。两组输入都应在升级前后各跑一次，记录“触发条件、决策结果、平台返回、最终状态”四列。若旧版本无法复现，也要留下原因，不能拿新版本的一次成功反推兼容性。

对照测试至少包含三类：第一类验证正常路径，第二类故意制造边界输入，第三类验证降级后数据是否仍然正确。性能相关场景还要固定图片尺寸、调用次数或设备状态，避免把环境波动误判为接口变化。遇到结果不一致时先缩小到最小样本，再回到完整流程验证，不能只修改 UI 文案掩盖底层差异。

如果项目同时维护多个系统版本，测试报告还应标出兼容分支何时启用、何时可以删除。临时分支没有退出条件，往往会在下一次升级中变成新的故障源。建议把删除条件写成可核对的版本覆盖率和线上异常率，而不是一句“后续再清理”。

证据边界

本文依据华为开发者官网 2026 年 9 月更新的 HarmonyOS 7（API 26）Release 行为变更说明，以及 2026 年 8 月更新的 Beta1 行为变更说明整理。文中的纯 TypeScript 判定函数已在宿主 Node.js 环境跑过断言，用来验证状态分支；ArkTS、权限、签名和系统组件片段仍需在 API 26 SDK、目标设备与正式签名条件下完成编译和真机验收。本文不把宿主测试写成真机结论。

建议保存的验收记录

• 系统版本、targetSdkVersion、应用模型和签名类型。
• 触发输入、接口返回、错误码与最终页面状态。
• 成功路径、拒绝路径、取消路径和重复调用路径。
• 升级前后对照结果，以及是否启用了临时兼容分支。
• 不在日志中保存完整账号、文件路径、媒体 URI 或设备敏感信息。

官方资料

• HarmonyOS 7 API 26 Release 针对所有应用的行为变更
• HarmonyOS 7 API 26 Beta1 针对所有应用的行为变更