HarmonyOS 上架审核材料实战：权限、隐私、截图与测试账号一次准备清楚

HarmonyOS 上架审核材料实战：权限、隐私、截图与测试账号一次准备清楚

很多应用不是代码不能运行，而是提交上架时材料对不上：权限声明说需要定位，但截图里看不到定位功能；隐私政策写了收集手机号，应用里还有第三方登录；测试账号进不去核心页面；审核人员按说明走到空白页。最后结果就是反复被退回，开发团队临时补截图、改说明、重新打包。

这篇文章从工程角度整理一套上架材料准备方法：功能清单、权限矩阵、隐私证据、截图素材、测试账号和回归记录要互相对应。它不替代平台实时规则，但能帮助项目在提交前把常见返工点提前处理掉。

1. 审核材料要和真实功能一致

上架审核材料最核心的问题是“一致性”。代码、配置、截图、隐私政策、测试说明必须能互相证明。

审核不是看一份漂亮文案，而是看应用实际行为和材料是否对得上。

2. 资料边界和准备范围

上架前应优先核对官方文档和开发者后台的当前要求。

本文用结构化方式准备材料，具体字段仍要以提交当天开发者后台页面为准，因为平台规则和入口可能调整。

3. FeatureManifest 先列功能路径

功能清单不是产品介绍，而是审核人员可以复现的路径。

typeFeatureRisk='normal'|'permission'|'login'|'payment'|'privacy';interfaceFeatureManifestItem{featureId:string;name:string;entryPath:string;needLogin:boolean;risk:FeatureRisk;screenshotName:string;}constreleaseFeatures:FeatureManifestItem[]=[{featureId:'nearby_store',name:'附近门店',entryPath:'首页 > 工具 > 附近门店',needLogin:false,risk:'permission',screenshotName:'nearby_store_location.png',},];

这份清单可以让测试、截图和权限说明围绕同一批功能展开。它防止材料写了旧版本功能，或者漏掉新增页面。

4. 权限矩阵要能解释每一项声明

如果module.json5声明了权限，上架材料里就要能说清楚使用场景。

interfacePermissionMatrixRow{permission:string;relatedFeatureId:string;triggerPath:string;userBenefit:string;fallbackAvailable:boolean;}constpermissionMatrix:PermissionMatrixRow[]=[{permission:'ohos.permission.LOCATION',relatedFeatureId:'nearby_store',triggerPath:'点击“查看附近门店”后触发',userBenefit:'展示距离用户更近的服务门店',fallbackAvailable:true,},];

权限矩阵连接代码声明、功能页面和用户价值。它避免出现“声明了权限，但材料只写系统需要”的空泛说明。

5. 隐私证据要和字段目录对应

隐私政策不是最后复制一份文本。它应和应用实际采集字段对应。

interfacePrivacyEvidenceItem{field:string;collectScene:string;policySection:string;userVisible:boolean;retentionDescription:string;}constprivacyEvidence:PrivacyEvidenceItem[]=[{field:'phone',collectScene:'用户绑定账号安全手机号',policySection:'账号安全与身份验证',userVisible:true,retentionDescription:'用户解绑或注销后按政策处理',},];

这份证据能帮助团队检查隐私政策是否遗漏字段，也能在审核询问时快速定位说明位置。

6. 截图素材要覆盖关键路径

截图不是随便截几张首页。它要覆盖核心功能、权限触发、登录后页面和异常兜底。

interfaceReviewScreenshot{fileName:string;featureId:string;pagePath:string;state:'normal'|'permission_prompt'|'empty'|'error';remark:string;}constscreenshots:ReviewScreenshot[]=[{fileName:'nearby_store_location.png',featureId:'nearby_store',pagePath:'首页 > 工具 > 附近门店',state:'permission_prompt',remark:'展示定位权限触发前的业务说明',},];

这段结构可以直接作为截图任务清单。截图前要确认页面数据不为空、文案没有测试占位、状态栏和底部导航不遮挡主体内容。

7. 测试账号不能只验证能登录

测试账号应能进入审核需要验证的功能，不能登录后权限不足或数据为空。

interfaceReviewAccount{username:string;passwordHint:string;role:string;accessibleFeatures:string[];resetBeforeSubmit:boolean;}constreviewAccount:ReviewAccount={username:'test_user_001',passwordHint:'提交后台填写实际密码',role:'normal_user',accessibleFeatures:['nearby_store','profile_edit','message_center'],resetBeforeSubmit:true,};

不要在文章或公开材料里暴露真实密码。提交后台需要填写时，再按平台要求提供。工程侧重点是确保账号状态干净、功能可访问、不会被风控锁定。

8. ReviewPackage 把材料合成一个发版对象

上架材料最好有一个统一对象，避免各自维护。

interfaceReviewPackage{versionName:string;buildNo:string;features:FeatureManifestItem[];permissions:PermissionMatrixRow[];privacy:PrivacyEvidenceItem[];screenshots:ReviewScreenshot[];account:ReviewAccount;}constpackageForReview:ReviewPackage={versionName:'1.3.0',buildNo:'130',features:releaseFeatures,permissions:permissionMatrix,privacy:privacyEvidence,screenshots,account:reviewAccount,};

这个对象不是要直接提交给平台，而是帮助团队检查材料之间是否能互相引用。比如权限矩阵里的featureId必须能在功能清单和截图清单里找到。

9. 提交前做一致性校验

材料一致性可以先用脚本思路检查。

interfaceReviewCheckResult{passed:boolean;problems:string[];}functioncheckReviewPackage(pkg:ReviewPackage):ReviewCheckResult{constfeatureIds=newSet(pkg.features.map((item)=>item.featureId));constproblems:string[]=[];pkg.permissions.forEach((item)=>{if(!featureIds.has(item.relatedFeatureId)){problems.push(`权限缺少对应功能:${item.permission}`);}});pkg.screenshots.forEach((item)=>{if(!featureIds.has(item.featureId)){problems.push(`截图缺少对应功能:${item.fileName}`);}});return{passed:problems.length===0,problems,};}

这类校验能提前发现“截图属于旧功能”“权限找不到说明”“隐私字段没有对应政策段落”等问题。人工检查仍然需要，但脚本可以先挡掉低级错误。

10. 审核前回归动作

上架前回归不是只安装启动一次。至少要覆盖安装、登录、权限、核心功能、异常兜底。

这些回归结果建议跟版本号一起保存。审核被退回时，可以快速判断是材料问题还是包内功能问题。

11. 常见上架材料问题排查表

排查顺序建议从版本号开始。很多材料问题本质是“当前包”和“提交材料”不是同一版。

12. 提交前材料验收记录

interfaceReviewReleaseCheck{versionMatched:boolean;permissionExplained:boolean;privacyLinked:boolean;screenshotsCurrent:boolean;accountVerified:boolean;}constfinalReviewCheck:ReviewReleaseCheck={versionMatched:true,permissionExplained:true,privacyLinked:true,screenshotsCurrent:true,accountVerified:true,};

这份记录应该由开发、测试和发布负责人共同确认。它能减少“提交前才发现材料不一致”的返工。

上架材料专项证据包：审核问题要能一次回答

上架审核失败很多时候不是功能有问题，而是材料说不清：权限截图不对应、隐私说明缺字段、测试账号进不去、审核路径太长。提交前应准备一份材料证据包。

interfaceReviewMaterialEvidence{permissionScreenshots:numberprivacyFieldsReady:booleantestAccountUsable:booleanreviewPath:string[]}functionassertReviewMaterial(e:ReviewMaterialEvidence):void{if(e.permissionScreenshots===0)thrownewError('缺少权限场景截图')if(!e.testAccountUsable)thrownewError('测试账号不可用')if(e.reviewPath.length<2)thrownewError('审核路径说明过短')}

这段代码表达的是提交前自查规则，帮助团队把审核材料从口头说明变成可复用清单。

审核材料复现场景：给读者一组可执行核验

审核材料最怕入口说不清。补充这组核验后，读者可以按功能入口逐个准备截图、账号、备注和隐私说明。

interfaceReviewReplayCase{entryPath:anyscreenshotName:anytestAccount:anyreviewNote:any}constreplay63:ReviewReplayCase={entryPath:'sample',screenshotName:'sample',testAccount:'sample',reviewNote:'sample',}functionassertReplay63(item:ReviewReplayCase):void{if(item.reviewNote.length<12)thrownewError('审核备注不足以复现路径')}

这组核验面向审核准备，能帮助读者把截图、账号和审核备注串成一条可复现路径。

13. 小结：上架审核是工程闭环的一部分

HarmonyOS 应用上架材料不是发布当天的文档工作，而是从功能开发时就应该同步维护的工程闭环。功能清单说明当前包有什么，权限矩阵解释为什么要权限，隐私证据说明数据怎么处理，截图和测试账号让审核人员能复现。材料越早结构化，提交时越少临时返工。