摘要

本文基于 HarmonyOS 应用上架审核的真实经历，复盘了首次提审被驳回三次的完整过程：隐私声明未写清相机权限用途、申请了用不到的位置权限、截图与真机界面不一致。围绕「隐私合规 + 权限最小化」这一审核核心，文章给出可直接照抄的 module.json5 权限声明范式、隐私政策文案结构、8 条常见驳回对策、一张判定流程图和一份提审前自查清单，帮助开发者把「声明的 = 做的」落到实处，尽量一次过审。

目录

• 一、背景与痛点
• 二、三次驳回的完整复盘
• 二、审核关注维度
• 三、核心代码（权限声明 + 隐私配置）
• 四、常见驳回与对策（8 条清单）
• 五、驳回自查流程图
• 五、提审前自查清单
• 六、总结

一、背景与痛点

功能写完只是第一步，能不能上架才是终点。我第一个应用被驳回了三次：第一次是隐私声明里没写清楚相机权限的用途，第二次是申请了用不到的位置权限，第三次是截图与实机界面不一致。每一次驳回都要等上好几天。
鸿蒙应用市场（含元服务）的审核越来越看重隐私合规与权限最小化。本文把最常见的驳回点和一份可直接照抄的自查清单整理出来，帮你一次过审。

二、三次驳回的完整复盘

三次驳回不是三件孤立的事，而是一条从"没写清楚"到"多申请"再到"素材不实"的递进线。把每次的时间、原因、整改动作和复审耗时摊开看，规律就很清楚了：

次数	驳回时间	驳回原因	整改动作	复审耗时
第一次	首次提审后第 2 天	隐私声明未说明相机权限的具体用途，仅写"用于相关功能"	在隐私政策中补写"用于扫码识别二维码、拍摄头像"，并在 module.json5 的 reason 中同步该表述	约 3 个工作日
第二次	第一次复审通过后第 1 天	申请了 ohos.permission.APPROXIMATELY_LOCATION，但功能中并无位置相关场景	删除该权限申请，同步删除隐私声明中的位置条目，确保声明与代码一致	约 2 个工作日
第三次	第二次复审通过后第 1 天	提交的截图与真机界面不一致，部分功能在截图中不可见	重新用真机截取全部核心页面，补充真实数据，替换全部素材	约 4 个工作日

从这三次里能提炼出四条可复用经验，正好对应后文 8 条清单中的前几条：

• 声明要跟着代码走，而不是跟着想象走：第一次驳回的根因是"写了但没写清"，整改时以代码实际申请为准回填声明，对应清单第 1 条。
• 权限只留业务真正用到的：第二次驳回是典型的过度申请，删掉用不到的权限比解释它更省事，对应清单第 2 条。
• reason 要写场景，不写形容词："用于相关功能"这类表述等于没写，改成具体动作才能过，对应清单第 3 条。
• 素材必须来自真机：第三次驳回说明审核方会拿截图和实机比对，设计稿再精美也没用，对应清单第 5 条。

三次驳回累计多花了约 9 个工作日，而这些问题在提审前用一张自查表就能全部拦下——这也是后文整理 8 条清单和自查清单的直接原因。

二、审核关注维度

维度	审核重点
隐私	隐私声明是否完整、与实际收集行为一致
权限	是否过度申请、每个权限是否有明确用途说明
内容	是否含违规、侵权、虚假宣传
包体	签名/包名是否与资质一致、是否存在调试残留
体验	截图/视频是否真实反映功能、有无明显缺陷

三、核心代码（权限声明 + 隐私配置）

// module.json5：权限必须带 reason（用途说明），且仅申请用到的
{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.CAMERA",
        "reason": "$string:camera_reason",   // 必须能说清"为什么要用"
        "usedScene": { "abilities": ["EntryAbility"], "when": "inUse" }
      }
    ]
  }
}

// 隐私与自启动：避免申请无关的后台/关联启动能力
// 在 app.json5 / 隐私政策文案中明示：收集哪些信息、用于什么、是否上传

隐私政策文案可直接按下面的结构逐条填写，与代码实际申请保持一致：

• 相机权限（ohos.permission.CAMERA）
  • 收集的信息类型：拍摄的照片、扫码时的图像画面
  • 用途：用于扫码识别二维码、拍摄头像或上传图片
  • 是否上传服务器：仅在用户主动提交时上传，本地不保留原始画面
  • 是否共享第三方：不共享
• 位置权限（ohos.permission.APPROXIMATELY_LOCATION）
  • 收集的信息类型：粗略地理位置（城市级）
  • 用途：用于展示附近门店、按地区推荐内容
  • 是否上传服务器：是，仅上传脱敏后的城市信息
  • 是否共享第三方：不共享
• 存储/文件权限（ohos.permission.READ_IMAGEVIDEO）
  • 收集的信息类型：用户主动选择的图片、视频文件
  • 用途：用于头像设置、内容发布
  • 是否上传服务器：仅在用户主动发布时上传
  • 是否共享第三方：不共享
• 设备与日志信息
  • 收集的信息类型：设备型号、系统版本、崩溃日志
  • 用途：用于问题排查与稳定性优化
  • 是否上传服务器：是，匿名化后上传
  • 是否共享第三方：仅与提供崩溃分析服务的合作方共享，且已做去标识化处理
• 账号信息
  • 收集的信息类型：手机号、昵称、头像
  • 用途：用于账号注册、登录与身份识别
  • 是否上传服务器：是
  • 是否共享第三方：不共享

提示：以上每一条都必须与 module.json5 中实际申请的权限一一对应，未申请的权限不要写进声明，声明里写到的权限也必须在代码中体现。

四、常见驳回与对策（8 条清单）

1. 隐私声明缺失或不一致：声明里没列某项权限，代码却申请了。对策：以代码实际申请为准，逐条回填声明。
2. 权限过度申请：申请了用不到的位置、通讯录权限。对策：只保留业务必需的权限，删除多余项。
3. 权限 reason 表述模糊：写"提升体验"这类空话。对策：写具体场景，如"用于扫码识别二维码"。
4. 签名、包名不符：测试包与提交包的签名不一致。对策：统一使用 Release 签名，并在 CI 中固化。
5. 截图与实机不一致：用设计稿冒充实机截图。对策：直接截取真机运行图，包含真实数据。
6. 存在调试残留：日志泄露、测试账号未清理、未接入支付却写"支持购买"。对策：发版前清理日志、移除测试入口。
7. 自启动、关联启动未说明：后台拉起能力没在声明里讲清楚。对策：非必要不开启，开启就写明场景。
8. 内容违规：含侵权素材、夸大宣传、诱导分享。对策：素材自查版权，宣传用语留有余地。

五、驳回自查流程图

把 8 条清单串成一条判定链，提审前按顺序走一遍，任何一环不通过就先整改再往下走，避免带着问题提交后被整体驳回：

图中每个判定节点都对应上文 8 条清单中的一条，整改动作即清单里的「对策」；只有全部判定通过，才进入「提交审核」这一步。

五、提审前自查清单

检查项	对应代码/配置位置	是否通过	备注
隐私声明一致性	隐私政策文案 ↔ module.json5 的 requestPermissions	☐	声明与代码逐条对齐，无多写、无漏写
权限最小化	module.json5 的 requestPermissions 列表	☐	只保留业务必需权限，删除位置、通讯录等冗余项
reason 表述	module.json5 中每个权限的 reason 字段及 resources/base/element/string.json	☐	写具体场景，避免"提升体验"这类空话
签名包名	build-profile.json5 的签名配置、app.json5 的 bundleName	☐	提交包与资质一致，统一使用 Release 签名
真机截图	应用市场素材（截图/视频）	☐	真机运行截图，含真实数据，不用设计稿
调试残留	日志输出、测试账号、隐藏入口	☐	发版前清理日志、移除测试入口与测试账号
自启动说明	module.json5 的 abilities、后台任务配置	☐	非必要不开启，开启则在声明中写明场景
内容合规	文案、图片、音视频素材	☐	素材版权自查，宣传用语留有余地

使用说明：提审前把这张表逐行过一遍，每项确认无误后在"是否通过"栏打钩；只要有一项没打钩就先别提交，等整改完再走审核流程，能省下大量驳回等待时间。

六、总结

过审的本质是**“你声明的 = 你做的”**：权限最小化、隐私讲清楚、包体干净、素材合规。建议提审前用上面 8 条逐条打钩，能省下大量驳回等待时间。落地记住：权限只申请用到的、声明与代码一致、截图用真机、发版清残留。

三次驳回累计多花的约 9 个工作日，本质上都是「声明与实现脱节」的代价。把本文的复盘表、8 条清单、判定流程图和自查清单串起来用，提审前花半小时自查，往往能省下几天甚至一周的复审等待。

本文为原创首发实战笔记，基于 HarmonyOS 应用上架审核与隐私合规实践，代码示例为配置范式示意，实际规范以华为应用市场官方文档为准。