小米应用从 0 到上架：HyperOS 开发者平台发布实战

小米开发者后台和审核规则会持续调整。本文记录的是一套可重复执行的发布方法，实际提交时仍需以平台最新要求为准。文中后台截图均已脱敏，仅保留应用名称、图标和包名。

上架前先准备什么

开始操作后台前，先把发布材料集中整理好：

• 已完成认证的小米开发者账号，并确认成员拥有应用管理和发布权限。
• 使用正式签名构建的 APK，包名与线上应用保持一致。
• 应用名称、图标、简介、分类、版本说明和应用截图。
• 可公开访问的隐私政策 URL，以及隐私合规说明。
• 测试账号、登录步骤和审核人员需要了解的特殊操作。

签名文件、密码和账号凭据不要放进 Git，也不要随安装包一起发送。团队协作时应明确唯一的正式签名来源。

第一步：创建应用

进入小米 HyperOS 开发者平台的“手机/平板应用”，选择创建应用。创建时填写应用名称、默认语言、应用类型和包名。

包名是应用的长期身份。后台建档、Android 工程和最终 APK 三处必须完全一致。线上应用建立后，不要通过修改包名来解决签名或升级问题，否则平台会把它识别为另一款应用。

第二步：检查 Release APK

提交前不要只确认构建成功，还要检查产物本身：

apksigner verify --verbose --print-certs app-release.apk
aapt dump badging app-release.apk
shasum -a 256 app-release.apk

重点核对包名、versionName、versionCode、签名证书、最低系统版本和目标系统版本。更新已有应用时，签名必须与线上版本一致，versionCode 必须递增。

第三步：填写版本资料

在应用详情中选择发布新版本，上传 APK，并填写版本名称、更新说明、应用介绍、搜索关键词和分类。更新说明应描述用户能感知的变化，不要直接复制内部任务编号或 Git 提交记录。

应用截图需要使用真实页面，但必须清理测试账号、客户数据、内网地址、手机号、订单号和调试入口。不同尺寸要求以后台当前提示为准。

第四步：完成隐私合规检查

隐私问题是 Android 渠道审核中最容易反复修改的部分。提交前至少检查以下内容：

1. 首次启动时，用户同意隐私政策前不提前初始化非必要 SDK。
2. 相机、定位、通讯录、存储等权限在用户触发对应功能时再申请。
3. 权限申请弹窗明确说明用途，拒绝后应用仍能正常进入可用页面。
4. 隐私政策列明收集的数据、使用目的、第三方 SDK、保存方式和注销路径。
5. 后台隐私声明、应用内弹窗和隐私政策正文保持一致。

可使用静态扫描和真机抓包辅助检查，但最终要以应用实际运行行为为准。

第五步：提交审核

上传完成后，再核对应用身份、版本号、签名、素材和隐私声明。需要登录才能体验核心功能时，提供长期有效的审核账号，并写清登录和操作步骤。

提交后记录包文件哈希、提交时间、提交人和审核状态。不要在发布群里只发一句“已经提审”，否则后续很难判断后台对应的是哪个构建。

审核驳回怎么处理

收到驳回后，先把问题归类，再决定修改代码、资料还是审核说明：

• 隐私合规：检查 SDK 初始化时机、隐私弹窗、权限调用和第三方 SDK 清单。
• 功能异常：使用与审核环境接近的设备、网络和账号重新复现。
• 包与签名：核对包名、证书指纹、版本号以及是否误传测试包。
• 素材问题：检查截图、图标、应用介绍和实际功能是否一致。
• 账号不可用：更换稳定审核账号，并补充完整操作路径。

修复后不要只点“重新提交”。在内部发布记录中写明驳回原因、修改位置、验证方法和新包哈希，避免下一版本重复出现。

上线后的验证清单

1. 商店页面显示的应用名称、图标、版本号和更新说明正确。
2. 新用户可以搜索、下载、安装并正常启动。
3. 旧版本可以覆盖升级，登录状态和本地数据不丢失。
4. 登录、推送、扫码、文件上传下载等核心能力正常。
5. 监控平台已经识别新版本，混淆映射和符号文件已归档。
6. 发布包、签名指纹、文件哈希和审核记录已经备份。

把发布过程标准化

稳定的上架流程不依赖某个人记住所有步骤。建议维护一份按渠道拆分的发布清单，让 CI 自动完成版本校验、签名检查、哈希计算和产物归档；人工只负责资料审核、隐私确认和最终提交。