项目写着 API 26，上架却仍被判配置不一致：HarmonyOS 7 deviceTypes、权限和隐私声明怎么对账

工程已经把目标版本改成 API 26，提交后仍收到“能力声明与实际包不一致”。原因往往不是一个数字没改，而是 deviceTypes、权限、隐私说明、功能入口和最终构建包来自不同版本。上架材料不是几张独立表格，它们共同描述同一个产品事实；任何一项滞后都会让审核证据互相打架。

验证范围：官方页面用于核对 HarmonyOS 7/API 26 的能力方向与开发边界；文中代码只验证应用侧状态机、预算或一致性模型。当前电脑是 API 24 SDK，且没有连接 HarmonyOS 7 真机，所以下面的断言不等同于 API 26 编译、真机性能或上架审核结果。

用旧包加新文案复现不一致

保留旧构建包，只修改控制台文案和隐私说明，再核对包内配置、deviceTypes、权限列表和截图入口。记录每项来源 commit 与构建号，就能看到“页面写新版本、包还是旧版本”的错位。

案例一：平板入口已宣传但包未声明

宣传图出现大屏能力，deviceTypes 或资源适配却未覆盖。要么补齐包与测试证据，要么移除超出真实范围的材料。

案例二：权限删除后隐私说明仍保留

代码已不再请求某权限，但隐私文本和审核说明仍写着用途。冗余声明也会造成不一致，应从最终包权限清单反向核对。

提交前需要一张契约表

开发、设计、法务和发布常在不同文件上工作。没有一个以构建产物为中心的事实表，提交时很容易把不同日期的正确材料拼成一套错误材料。

type Contract={sdk:number;deviceTypes:string[];permissions:string[]};
function sameSet(a:string[],b:string[]){return a.length===b.length&&[...a].sort().join('|')===[...b].sort().join('|');}
const pkg={sdk:26,deviceTypes:['phone'],permissions:['camera']};
const form={sdk:26,deviceTypes:['phone','tablet'],permissions:['camera']};
if(pkg.sdk===form.sdk&&sameSet(pkg.deviceTypes,form.deviceTypes)) throw new Error('设备范围错位未识别');

这段模型用确定输入验证“发布表单必须与最终包的 SDK、设备范围和权限集合一致”。它适合先发现应用侧边界错误，但不会冒充平台接口或设备性能测试。

三种检查方式怎么选

方案	适用范围	主要风险
人工逐页回忆	一次性小项目	容易混入旧材料
只检查 SDK 数字	简单升级	漏掉权限与设备范围
产物驱动契约表	持续发布	需要自动提取与留证

以待提交构建包为事实源，生成 SDK、deviceTypes、权限和功能入口清单，再让隐私、截图和控制台表单逐项对账。

从构建产物反向生成证据

建立 ReleaseEvidenceContract，保存构建号、commit、包摘要、声明集合和人工证据链接。任何材料更新都必须绑定同一个构建。

审核整改必须能复现

• 目标 SDK 与最终包一致。
• deviceTypes 与截图和测试范围一致。
• 权限清单与隐私说明一一对应。
• 删除功能后同步移除旧文案。
• 整改后用新构建重新生成契约。

API 26 适配不止改一个版本号。让所有上架材料围绕同一个构建产物对账，审核问题才不会在不同表单之间来回弹。

官方资料

• AppGallery Connect HarmonyOS 应用发布指南
• HarmonyOS 7 新能力
• HarmonyOS 应用开发指南