HarmonyOS 7 设备已在 AGC 注册，API 26 自动签名仍失败：bundleName、ACL 和 capability 怎么逐项对账

不才难以繁此生

56人浏览 · 2026-10-15 00:54:05

不才难以繁此生 · 2026-10-15 00:54:05 发布

HarmonyOS 7 设备已在 AGC 注册，API 26 自动签名仍失败：bundleName、ACL 和 capability 怎么逐项对账

测试设备已经在 AGC 注册，DevEco Studio 仍提示自动签名失败；重新点几次签名偶尔成功，换一台电脑又失败。API 26 文档新增了注册设备后开始签名的支持，但这不等于只要设备存在就一定成功。Profile 中的 bundle name、证书有效期、ACL 和 capability 必须与当前工程和 AGC 应用一致。本文给出不靠反复刷新页面的逐项证据法。

API26 自动签名 Profile 包名 ACL capability 对账

证据边界：文中 API 26/HarmonyOS 7 能力以华为当前官方文档为准；代码中的应用侧状态与一致性断言已在本机 Node.js 环境执行。当前本机 SDK 为 API 24，且没有连接 HarmonyOS 7 真机，因此本文不声称完成 API 26 编译、真机性能或上架审核验证。

先把故障钉在可复现步骤上

复制工程并修改 product 或 bundleName，但保留原来的签名配置；再为模块新增一个需要开放能力的功能，不同步 Profile。分别记录工程 build-profile.json5、模块配置、DevEco Managed Profile 展示字段和 AGC 应用信息。

案例一：bundleName 对不上时不要重建证书碰运气

证书有效并不代表 Profile 允许当前包名。先比对工程最终产物使用的 bundleName 与 Profile 显示字段，再决定重新关联应用或修正产品配置。

案例二：开放能力已勾选但 Profile 还没有

AGC 页面上的能力与本地 Profile 不是两个独立事实。同步完成后读回 Profile 的 capability/ACL；只看到控制台勾选成功，不能证明当前构建已经拿到能力。

官方文档给了可直接读回的证据位置

自动签名文档说明，可以把鼠标悬停在 DevEco Managed Profile 上查看证书有效期、bundle name、ACL 与 capability，也可以在工程级 build-profile.json5 的 signingConfigs 下核对签名信息。API 26 起支持在 AGC 注册设备后开始签名。

把签名问题拆成四个集合比较

设备集合决定调试设备是否在范围内；包名集合决定 Profile 是否属于当前应用；ACL 与 capability 集合决定开放能力是否齐全；证书时间窗决定当前时刻是否有效。任何一项不匹配，都应给出具体差异，而不是只显示“签名失败”。

调试签名成功不等于发布包已准备好

本文处理的是自动签名排障。发布证书、正式 Profile、应用上架材料和最终包还要走发布链路的独立核验。不要拿调试设备安装成功冒充正式发布签名证据。

可直接放进工程的接口片段

// 工程级 build-profile.json5 中只展示结构位置，具体字段以 IDE 生成结果为准。
{
  "app": {
    "signingConfigs": [
      { "name": "default", "type": "HarmonyOS" }
    ]
  }
}
// 在 DevEco Studio 中读回 DevEco Managed Profile：
// certificate validity / bundle name / acl / capability

上面是围绕官方接口位置整理的 ArkTS/工程片段，仍需在 API 26 工具链和目标设备上编译验证。为避免把接口示意当成证据，应用侧关键判定另写成可执行断言：

function diff(expected,profile){
  const missing=x=>x.filter(v=>!profile.includes(v));
  return { acl:missing(expected.acl), capability:missing(expected.capability) };
}
const d=diff({acl:['A'],capability:['camera','location']},['A','camera']);
if(d.capability.join(',')!=='location') throw new Error('能力差异计算错误');

方案不是越复杂越好

方案	适用场景	放弃它的理由
反复刷新自动签名	临时网络抖动	配置差异不会自行消失
删除全部签名材料重来	材料已失控	可能破坏原本有效配置
Profile 字段逐项对账	常规签名失败	需要保留当前证据快照

优先逐项对账，明确是哪一集合不一致；只有确认材料失效或关联错误后才重建。这样能保留可解释的整改路径，也不会因为“碰巧成功一次”掩盖配置漂移。