HarmonyOS 7 启动 HNP 二进制后权限丢了：independentSign 与 permission 段缺一不可

主应用已经声明 kernelpermission，HNP 内的工具进程在旧版本也能正常工作。升级到 HarmonyOS 7、target 26 后，execve 能拉起进程，但申请可执行匿名内存等操作失败。根因是 bin 独立进程有自己的进程身份，API 26 起不再自动继承应用的 kernelpermission。HNP 配置 independentSign 后，还必须为 bin 写入需要的权限策略段并重新打包。

先识别独立进程身份

关注点	正确理解	容易误判
是否涉及	应用是否启动 bin 独立进程	手机普通应用通常不在此场景
权限范围	是否使用名称含 .kernel 的权限	只声明真正需要的最小集合
HNP 打包	independentSign + .permission 段	签名与权限策略共同验证

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

HNP 场景：权限段和独立签名

先对构建清单做静态审计，只有同时满足“拉起 bin”和“需要 kernelpermission”才进入迁移。这样避免把所有 Native 库都误判成独立进程。

type BinaryAudit = { executed:boolean; permissions:string[] };
function needsBinaryGrant(item: BinaryAudit): boolean {
  return item.executed && item.permissions.some(p => p.includes('.kernel.'));
}
if (!needsBinaryGrant({executed:true,permissions:['ohos.permission.kernel.ALLOW_WRITABLE_CODE_MEMORY']})) throw new Error('漏检kernelpermission');
if (needsBinaryGrant({executed:false,permissions:['ohos.permission.kernel.X']})) throw new Error('未执行二进制不应进入此迁移');

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

启动前做静态审计

HNP 的权限 JSON 要进入源码审查和产物检查。可以显式列出权限；不确定时官方还提供 INHERIT_PARENT_PERMISSION，但它不是默认首选，仍要评估实际继承范围。构建后用 llvm-objcopy 读取或比对 section，避免配置文件存在、产物却没带上。

type PermissionFile = { requestPermissions:{name:string}[] };
function validatePermissionFile(file: PermissionFile, allowed:Set<string>): string[] {
  return file.requestPermissions.map(x=>x.name).filter(name=>!allowed.has(name));
}
const bad = validatePermissionFile({requestPermissions:[{name:'ohos.permission.kernel.X'}]},new Set(['ohos.permission.kernel.ALLOW_WRITABLE_CODE_MEMORY']));
if (bad.length !== 1) throw new Error('权限白名单审计失效');

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

验收不只看进程能启动

权限继承能省配置，但也会扩大难以解释的授权面。生产环境优先显式最小权限；构建流水线同时检查 HNP 配置、权限 section、签名证书和运行时拒绝路径。

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

发布前检查清单

• 官方变更是否真的作用于当前 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 针对所有应用的行为变更