华为应用从 0 到上架：Android 与 HarmonyOS 发布实战

华为后台与审核规则会持续更新，本文重点记录稳定的工程流程和检查方法。提交前仍应核对 AppGallery Connect 当前页面与官方要求。本文更新时间：2026-08-09。

先拆成两条发布链路

华为生态中的 Android 与 HarmonyOS 可以共用应用品牌、资料准备和发布管理经验，但包格式、签名材料、能力配置与系统权限并不相同。

不要把 HarmonyOS 当成“换一个渠道的 Android 包”。最清晰的做法是维护两张发布清单：一张记录 Android 包名、keystore、版本号和渠道构建；另一张记录 HarmonyOS bundleName、证书、Profile、API 版本和设备类型。

上线前准备

开发者与企业信息

• 华为开发者账号已完成企业认证。
• AppGallery Connect 项目成员权限已分配。
• 隐私政策、技术支持联系方式和公司主体信息可用。
• 应用名称、图标、简介、截图和分类已经确认。

发布账号应使用团队权限管理，不要多人共用一个管理员密码。涉及证书下载或发布操作时，保留操作记录。

应用身份

Android 使用稳定包名：

com.company.product

HarmonyOS 使用稳定 bundleName。二者可以采用一致的命名语义，但必须分别在工程与后台核对。线上应用建立后不要轻易更换身份，否则可能被视为新应用，无法直接覆盖升级。

第一步：在 AppGallery Connect 创建项目和应用

创建项目后，按目标平台添加应用。应用名称、默认语言、包名或 bundleName、应用分类和访问权限要与正式规划一致。

如果同一产品同时发布 Android 和 HarmonyOS，建议在项目命名、发布记录和版本说明中明确平台，避免后续拿错包或更新错应用。

第二步：准备 Android 签名与 Release 包

Android 正式包必须使用长期保存的发布 keystore。至少备份以下信息：

• keystore 文件。
• store password 与 key password。
• key alias。
• 证书指纹。
• 负责人和备份位置。

密钥不能放入 Git。CI 中应通过凭据系统或受控文件挂载注入，并限制读取权限。

Gradle Release 配置应从环境变量或 CI 凭据读取签名参数：

android {
  signingConfigs {
    release {
      storeFile file(System.getenv("ANDROID_KEYSTORE_PATH"))
      storePassword System.getenv("ANDROID_KEYSTORE_PASSWORD")
      keyAlias System.getenv("ANDROID_KEY_ALIAS")
      keyPassword System.getenv("ANDROID_KEY_PASSWORD")
    }
  }
}

构建完成后检查包名、versionName、versionCode、签名证书和目标架构。不要只看 Gradle 显示 BUILD SUCCESSFUL。

第三步：准备 HarmonyOS 签名与 Release 包

HarmonyOS 发布涉及证书、Profile 和应用身份。使用 DevEco Studio 配置签名时，确认发布环境没有误用调试证书。

重点检查：

1. bundleName 与后台应用一致。
2. 使用发布证书而不是 debug 证书。
3. Profile 中的设备类型、能力和有效期正确。
4. versionName 与 versionCode 按发布策略递增。
5. 权限、模块和 API 版本与目标设备兼容。

签名问题常出现在多人协作和 CI 环境。证书文件、私钥、Profile 与密码必须按同一套发布材料管理，不能只复制工程配置而遗漏密钥。

第四步：整理权限与隐私说明

先从工程清单和实际代码列出权限，再逐项确认业务用途。相机、相册、定位、通讯录、通知和文件访问都应该在用户触发对应功能时再申请。

隐私政策需要覆盖真实的数据处理行为，包括：

• 收集的数据类型和目的。
• 第三方 SDK 及其数据行为。
• 数据保存、共享和删除方式。
• 用户撤回授权或注销账号的路径。

应用内弹窗、商店隐私声明和隐私政策三处描述应保持一致。

第五步：准备商店资料

常见资料包括应用名称、简介、详细描述、图标、截图、分类、关键词、隐私政策链接和版权信息。

截图应该使用真实页面，避免展示测试账号、内部地址、客户数据或调试入口。不同平台页面不完全相同时，分别准备截图，不要用 Android 截图替代 HarmonyOS 实际效果。

第六步：上传版本并填写更新说明

上传前记录文件哈希，确认传输和后台处理的包就是本次发布产物。版本说明写用户可感知的变化，不要直接复制 Git commit 或内部任务编号。

建议同步记录：

平台：HarmonyOS / Android
应用版本：2.0.37
内部构建号：2037
包文件 SHA-256：...
提交人：...
提交时间：...
关联需求：...

第七步：审核前测试

至少覆盖安装、升级、登录、权限授权、核心业务、推送、深链、文件上传下载和异常网络。企业应用还要验证审核账号是否能看到完整流程。

Android 需要关注不同系统版本、厂商权限管理和后台限制。HarmonyOS 需要关注目标设备类型、ArkUI 组件差异、文件权限和系统能力适配。

第八步：提交审核与跟进

提交后记录审核状态和时间。审核反馈要按问题分类处理：包与签名、功能与稳定性、资料与版权、权限与隐私、账号与可访问性。

不要只回复“已经修改”。在审核说明中写清问题原因、修改位置、复现步骤和验证结果，能减少重复沟通。

常见问题

新版本无法覆盖安装

优先检查应用身份、签名证书和版本号。只要包名或 bundleName、签名发生变化，系统就可能把它视为不同应用。

后台提示证书或 Profile 无效

检查材料是否过期、是否属于当前应用、私钥是否匹配，以及 CI 是否拿到了完整签名文件。不要通过临时换回调试签名绕过问题。

审核认为权限与功能无关

删除不再使用的权限，并把权限申请延迟到用户执行相关动作时。用途说明要写具体业务，而不是“改善体验”。

商店截图被退回

检查截图是否包含内部数据、误导性功能、测试环境标记、其他平台状态栏或不符合尺寸要求的内容。

上线后的验证清单

1. 商店页面状态为已发布，版本号和更新时间正确。
2. 新用户可以搜索、下载、安装和启动。
3. 旧版本可以覆盖升级，用户数据正常。
4. 登录、接口、推送、扫码和文件能力正常。
5. 监控平台已识别新版本，符号文件或 Source Map 已上传。
6. 强制更新、灰度配置和服务端兼容策略符合预期。
7. 发布记录、包哈希和审核反馈已经归档。

把上架流程做成工程能力

当发布次数增加后，应把人工记忆变成自动检查：CI 统一生成版本、校验签名、计算哈希、归档产物并上传监控符号文件。人工负责审核资料和发布决策，机器负责重复且容易出错的步骤。