签名、备案、隐私政策和软件著作权都准备好以后，应用终于可以送进 AppGallery Connect 了。这一步看起来只是上传软件包、填写资料、点击提交，真正操作时却很容易手忙脚乱。前面几篇里准备好的各种资质和素材，都需要在这里找到对应的入口填上去。本章中，我们就一起来看看，如何把这条上架主线顺畅走通。
提交审核流程及注意事项
在正式将应用送交审核团队之前，你需要在 AGC 中逐步完成一整套信息填报工作。
整个流程大致可划分为三个阶段：首先是上传与基础配置，你需要上传准备好的软件包进行基础合法性检测，并设置分发设备、发布地区以及应用名称、图标等本地化信息；其次是合规与资质声明，在此环节需如实填写内容分级问卷，配置详尽的隐私信息（声明、说明与标签），并上传备案、软著及 AI 功能声明等相关资质材料；最后是测试支持与提交，你需要为审核员提供有效的测试账号、联系方式以及设定理想的上架时间，一切就绪后即可提交审核。
下面，我们就沿着控制台的界面，看看如何顺畅地跑通这段流程。
上传 .app 包并确认支持设备
首先，登录 AppGallery Connect，打开「APP 与元服务」，点击准备发布的应用。左侧导航选择「应用上架」>「软件包管理」，点击页面右上角的「上传」。
在「上传包」窗口，先选择「使用场景」，然后点击「+」上传根据第 2 章步骤生成并签名的 .app 包。
AGC 会先做基础合法检测。这里还没进入人工审核，如果报错，先按页面给出的错误码检查签名、包结构、bundleName、版本号和设备配置，按情况改正即可。
接着核对「支持设备」。软件包声明支持手机、平板、PC／2in1、手表或智慧屏，不等于你一定要把这一版同时发到所有设备，但 AGC 中勾选的分发范围不能和包内能力自相矛盾。尤其是从多设备模板建立的工程，包里可能已经带有你尚未准备好发布的设备类型。提交前应在对应设备上完成实际测试；如果某一端的支持还只是占位，宁可暂时不分发，也不要提交一个未完成的版本。
上传完成后，软件包管理页面会生成一条记录，展示软件包基本信息。
应用名称、图标和介绍
「应用信息」中的本地化资料按语言分别维护。你至少需要确认应用名称、一句话简介、应用介绍、新版本特性、图标、截图或视频、应用分类和开发者服务信息。增加语言时，应先切换到对应语种，再编辑该语种的图标、截图和文案。
名称和图标最容易出现张冠李戴的情况。AGC 中的应用名称、软件包配置、安装到设备后的桌面名称，以及备案和软著材料中的名称，应按对应规则保持一致。在名称方面，注意应用名称的硬性上限是 15 个汉字或 30 个其他字符，且不能使用诸如「免费壁纸」这类泛词，也不能与已有的知名应用高度雷同。图标也要和设备上实际显示的版本一致，不建议为了商店详情页另做一张带宣传文字或角标的图。
截图方面，应用市场要求至少提供 3 张不同的截图，并且要展示已经可以使用的页面。如果截图里出现会员、AI 对话、跨设备协同等功能，审核账号进入应用后也应能够找到并操作它。尚未开放的功能可以留到后续版本再展示。应用介绍同样如此，少写一句空头支票，比审核员找不到入口后打回审核更省时间。
应用分类和标签应按主要功能选择。一个记账工具带有简单的内容推荐，不代表它应该被放进资讯分类；勾选并不存在的广告、社交或支付场景，还会让审核范围随之扩大。分类拿不准时，先看同类在架应用的归类，再以应用当前版本的主要用途为准。
隐私信息从同一份数据清单填写
AGC 要求每个应用填写隐私声明、权限用途和隐私标签。这三个项目虽然名称接近，作用并不相同：
- 隐私声明（Privacy Statement）：向用户公开的隐私政策。使用自建页面时，要确认审核环境可以正常打开，页面内容和当前版本一致；
- 隐私说明（Privacy Description）：解释软件包中敏感权限或受限权限的使用场景。写清用户执行什么操作、应用为何需要这项权限，不要只写「用于提供正常功能」；
- 隐私标签（Privacy Label）：以结构化方式展示业务场景、数据类型和用途，最终会出现在应用市场详情页。
填写时，可以直接使用第 3 章整理好的个人信息清单。比如应用只在用户主动上传头像时读取一张图片，就在隐私政策、权限说明和隐私标签中使用同一套描述。
权限说明还要和代码中的申请时机对应。文字写「扫码时使用相机」，应用却在首屏启动时申请相机权限，从审核角度而言仍然是不一致。AGC 字段只能解释行为，不能弥补代码层面本身的不合规。
AI 功能声明与相关资质
应用提供 AI 问答、绘图、换脸、变声、数字人或其他生成式功能时，需要在 AGC 中如实选择 AI 功能声明，并按当前要求提交算法或模型相关材料。应用内还要完成生成内容标识、内容安全和用户控制等措施。具体材料已在第 3 章准备，这里对应填写上传即可。
勾选「涉及」AI 功能，意味着你需要配合提供对应的资质材料：在版权信息处上传算法备案号等文件（获取方式参考第 3 章）；同时在应用内对 AI 生成内容进行显著标识（如水印、文字标记），并给用户提供拒绝或关闭 AI 推荐的选项。
如果没有使用这类技术，直接选「不涉及」即可。如果应用确实含有相关功能却含糊其辞，审核发现后依然会要求你把缺失的资质全部补齐。
测试账号
需要登录才能使用的应用，应在「应用审核信息」中提供可用的测试账号。这个账号最好单独建立，关闭验证码频控、地域限制和容易误触的风控规则，并让它覆盖本次送审的主要功能。应用有普通用户、商家和管理员等不同角色时，可以分别提供账号，并在备注里写清每个账号能看到什么。
付费功能也要让审核员能够验证。可以提供具备相应权益的测试账号，或说明沙盒测试方法，不能要求真实付款。蓝牙、NFC、扫码、AR、折叠态页面等功能依赖特殊环境时，在「备注」中写出入口和操作顺序，并按页面当前支持的格式上传演示视频或说明文件。文件类型、数量和大小限制可能随 AGC 页面调整，上传时以界面提示为准。
备注不需要写成产品说明书。可以参考下面这种格式：
- 使用账号 A 登录，首页点击「设备」；
- 点击右上角「添加」，扫描附件中的二维码；
- 配对成功后进入「数据同步」，可验证本次新增功能；
- 账号 B 用于查看会员页面，已经开通测试权益。
换言之，每一步都让审核员知道在哪里点、看到什么。如果测试环境需要先把服务器切到特定租户，或只在某个时间段开放，也应写在这里。
避开高频驳回陷阱
在准备提交前，提前规避审核中常踩的坑，能极大提升一次过审的概率。根据官方的审核指南和开发者的实操经验，有几个问题是退回的「重灾区」：
- 隐私要求执行不到位：这是最容易踩坑的地方。例如，应用内没有提供有效的账号注销入口，或者注销承诺时间超过了规定的 15 个工作日；又或者声明了定向推送功能，却未在应用内提供关闭该功能的选项。
- 信息不一致或违规：隐私声明中的内容与 AGC 中配置的「隐私标签」或「双清单」不匹配；截图里出现了其他平台的特有 UI 元素。
- 未成年人保护缺失：如果你开发的是可能被未成年人使用的应用，却缺少防沉迷设计、未成年人专属的隐私声明，或者在其中展示了医疗、药品、酒精等不适宜的广告类型，都会被直接打回。
- 空白页或功能异常：如果审核员在测试账号登录后遇到了明显的白屏、闪退，或者发现核心功能在弱网下没有合理的错误提示，应用也会被退回。确保你提供的测试账号能正常走通主流程。
提交前做一次交叉检查
全部必填区域完成后，回到「版本信息」，确认页面没有未完成提示，再点击右上角的「提交审核」。提交前建议用即将提供给审核员的账号，在一台没有开发环境和历史登录状态的设备上完整走一遍。
送审前至少核对这些项目：
- AGC、软件包、桌面和备案材料中的名称与图标能够对应；
- 截图、介绍和新版本特性只描述当前版本已经提供的功能；
- 隐私政策、权限申请、隐私说明和隐私标签使用同一套数据清单；
- 测试账号可以登录、退出，并覆盖本次需要审核的角色和权益；
- 首页和主要模块不是空页面，弱网或接口无数据时也有合理提示；
- 支付、广告、用户生成内容、未成年人保护和 AI 功能已经按应用实际场景自检；
- 联系人手机和邮箱在审核期间可以正常接收消息。
提交成功后，版本会进入审核流程。页面文案可能随阶段显示为等待审核、正在审核、待修改或待上架等状态。
在等待期间，如果不小心发现传错了包或者有信息需要修改，由于版本在审核状态下无法直接编辑，你需要点击右上角的撤销审核，让应用回到「已撤销上架」或「待修改」状态后再重新编辑。这会让你失去当前在审核队列中的位置，重提后需要重新排队。
如果在「正在审核」状态下等了好几天没有动静，可以尝试点击右上角的催审按钮提醒审核员。但频繁催促并没有奇效，建议等待两三个工作日后再使用。只有 HarmonyOS 应用和元服务可以申请加急审核。这项服务通常只用在线上版本出现重大 Bug 急需修复，或是配合重大品牌活动等特殊场景。一个应用一个自然年只有 3 次加急机会，日常版本迭代不需要、也无法走加急通道。
审核退回的处理
审核退回时，先看「审核意见」和随附截图，找出被指出的页面、功能和规则。报告中如果提供了条款编号，应回到《华为应用审核指南》查看完整上下文，不要只改报告里截取的一句话。
审核提出的问题一般可以分为两大类：名称、截图、隐私标签、测试账号说明等属于提交信息，可以在 AGC 中修改；闪退、空白页、权限强索、举报入口缺失等属于软件包问题，需要修改代码、重新测试和打包。如果同一条意见同时指出政策文字与应用行为不一致，两边要一起改。
读不懂审核意见，或确认报告中的页面与送审版本不符时，可以从报告或帮助入口联系审核支持，附上版本号、审核意见截图、复现步骤和能够证明实际行为的录屏。如果只是执行不到位，直接修正再提交通常更省时间；涉及误判、账号或应用处理措施时，再按 AGC 当前入口提交申诉和证明材料。
此外，应用有时也可能通过审核，但仍存在需要优化或修复的问题，这种情况会在「审核意见」中注明。点击「审核报告」，可查看详细内容并根据报告内容修复问题。为不影响版本后续正常发布，需要在下个版本修复问题。
发布新版本
应用上架后，从应用列表点击当前版本的状态，进入「版本信息」，再点右上角「升级」。（如果上一个版本还没有完成上架，「升级」按钮可能不会出现。）
versionCode 的递增原则
上传新软件包时，AGC 要求 versionCode 不低于当前上架版本。正常发布功能更新或修复时，建议每次递增，这样市场客户端才能把它识别为可分发给用户的新版本。
如果新包与在架版本使用相同的 versionCode，AGC 会弹窗要求确认。继续提交并不代表所有用户都能收到这个包：已经安装相同版本号的用户不会升级，应用市场显示的版本更新日期也保持不变。因此，代码或资源有任何变化时，即使只是需要回滚到上一版代码，都应使用更高的 versionCode。
全网发布还是分阶段发布
当前在架版本为全网发布时，新版本可以选择「全网发布」或「分阶段发布」。全网发布一次覆盖所有符合条件的用户，适合改动范围小、已经充分验证的版本。分阶段发布会先把更新分给一部分用户，再逐步扩大范围，适合修改了登录、支付、数据库迁移、关键 SDK 或其他影响较大的链路。（首次发布不支持分阶段发布。）
如果分阶段发布期间发现了严重问题需要叫停，你可以申请下架，但要格外谨慎。AGC 明确提示：这类下架申请通过后，市场上将没有任何在架版本可供用户下载。如果问题可以通过新版本修复，通常应先评估能否提交修复包；如果涉及安全、合规或数据损坏，是否立即下架则要以控制用户风险为先。
在决定分阶段发布后，选择合适的灰度时段同样重要。建议避开周末或公共假期操作放量，因为一旦在新版本中发现严重问题，你和团队需要能迅速响应，准备修复包或申请叫停。一般而言，周一至周三的下午是比较理想的灰度窗口，此时开发资源充足，问题也能在周末前得到妥善处理。
只改商店资料，用同版本更新
当你想修改的仅仅是应用图标、介绍文字或应用截图等信息，不需要动代码时，可以走「同版本升级」路径。
点击「升级」后，在软件包选取窗口里直接勾选当前在架的那个包。切记不要上传任何新包，否则即便版本号没变，系统也会强制按完整升级流程走。修改信息后提交审核，通过后应用市场的页面就会立刻更新。
值得提醒的是，已经上架的应用是不支持直接更改付费类型的（比如免费转付费）。如果要改付费模式，只能把当前应用彻底下架删除，然后重新发布一个应用。
签名不一致时先判断是不是传错包
升级版本时，AGC 会自动校验你传的新包签名是否和老版本一致。如果因为更换了证书导致签名发生变化，系统会弹出确认框。如果你明确知道换了签名，确认后就可以继续提交；如果是由于传错了包或用错了密钥导致的误报，就取消上传，换回正确的包再重新操作。
关联已有 Android 版本
如果同一应用已有 Android 版本，可以把它与 HarmonyOS 应用关联。两边都已全网发布、分发设备类型满足条件，并且没有和其他应用建立关联时，才能形成一对一关系。关联成功后，设备升级到 HarmonyOS 5 及以上版本时，可以把原 Android 应用替换为 HarmonyOS 应用，并完成用户数据迁移。
AGC 会在首次发布或升级尚未关联过的 HarmonyOS 应用时，自动匹配同一账号下可能关联的 Android 应用。如果当时没有处理，等两边都进入全网发布状态后，也可以从「应用系列」中建立关联。
监控与反馈
应用上架并非终点，而是持续运营的起点。为了确保应用在真实设备上的表现符合预期，并在出现问题时迅速响应，你可以借助 AGC 提供的监控与分析工具。了解这些数据的去向和意义，能帮你更好地规划后续版本的迭代。
APMS：鸿蒙新应用的标配监控
APMS 是用于监测现网应用的稳定性和性能的官方工具。对于 API 版本大于等于 11 的 HarmonyOS 应用，官方要求使用 APMS。
接入 APMS 的流程很轻量，只要在代码里集成 SDK，并在编译期向后台上传符号表文件，几分钟之内你就能在控制台看到崩溃问题的聚合报告和具体堆栈。新版本发版后的头几天，建议每天登录控制台看一眼 APMS 数据，根据崩溃率的变化判断是否需要停止灰度或紧急修复。
运营数据与评论管理
在 AGC 控制台的「运营」区域，你可以直观地看到应用详情页的访问量、下载转化率、激活率等数据。如果下载转化率偏低，建议去修改应用图标或一句话简介；如果激活率低，可能是由于应用的实际功能与商店里的宣传存在落差。
应用详情页下方的用户评论同样在控制台进行管理。在回复差评时，请把它当作公开展示的文案来处理：先确认事实，再给出明确的处理方案或时间线。千万不要在回复里留下外部社交群的联系方式试图把用户引走，你只能提供正规的客服邮箱或官网链接，否则会被判定为违规引流。
下架、撤销上架与重新发布
如果因为某些原因需要把应用从商店撤下，针对不同状态有不同的处理方式：
- 版本仍在审核时，使用页面提供的撤销审核入口，修改后重新提交；
- 版本已经通过审核、但还没到指定上架时间时，可以点「撤销上架」。这一步不需要人工审核，撤销后状态变为「已撤销上架」；
- 版本已经在架时，点击「申请下架」，填写原因后提交。官方文档给出的处理时间为 1 至 2 个工作日，处理期间状态显示为「下架处理中」，通过后变为「被开发者下架」；
- 已下架或已撤销上架的版本，可以在现有草稿上修改，再次提交审核。审核通过后重新上架。
下架后，用户无法再从应用市场搜索和下载这个应用，但 AGC 会保留草稿，方便以后修改并重新发布。下架申请审核通过前，还可以催审或撤销下架申请。如果下架的是「分阶段发布（7 天内自动更新）」版本，AGC 会特别提醒通过后没有任何在架版本供用户下载。这个提示不能略过。相反，删除是不可逆的，执行前应确认应用、数据、合同和用户服务义务都已处理。
游戏下架还有额外要求。如果游戏同时停服，需要准备停服公告、关闭充值和注册的时间、服务器关闭时间以及用户补偿方案。官方要求关服前至少 60 天发布停服公告并申请下架，至少提前 30 天关闭充值，且关闭注册时间早于关闭服务器时间。补偿可以按当前表单选择道具转移、游戏内补偿或退款，并写清执行方案。
总结
走完提审和发布的流程，上架的这条主线就真正串起来了。这一环没有特别艰深的技术难点，考验的是细心与耐心。确保你填写的名称、隐私配置、资质材料能和代码里的声明严丝合缝地对上，就能少走很多被退回重审的弯路。
至此，关于鸿蒙应用上架的合规与操作指南已经讲解完毕。在下一章，我们会换一个视角，聊聊如何利用 AI 更好地辅助你编写鸿蒙代码、起草相关文档。
延伸阅读：
