正式版APK能否安装、上架、更新，首关取决于manifest.json中Android配置的完整性与准确性：android.package须为全小写com.yourcompany.app格式；keystore路径、storePassword、keyPassword、keyAlias四者须与证书生成时完全一致；云打包必须选“正式包”并勾选“使用自有证书”；本地打包还需确保dcloud_key、包名、证书SHA1三者绑定一致，且HBuilderX、SDK、Gradle版本匹配；keystore必须离线保管、禁止提交Git，密码不得硬编码。
manifest.json 里包名和签名配置必须填全
正式版 APK 能否安装、上架、更新，第一关就卡在 manifest.json 的 Android 配置里。缺字段、写错大小写、路径带中文空格，都会导致打包静默失败或安装报“解析包时出现问题”。
关键位置在可视化配置的「App Plus → Android 原生配置」下，必须明确填写：
-
android.package：正式版严格用com.yourcompany.app格式（全小写、无下划线、无特殊字符），不能留空，也不能和测试版混用 -
keystore：填绝对路径，比如D:/keys/myapp-release.jks，注意 Windows 下反斜杠要写成正斜杠或双反斜杠 -
storePassword、keyPassword、keyAlias：四者必须和你生成证书时输入的完全一致，一个字母/空格都不能差
常见错误是把 keyAlias 写成证书文件名，其实它是你在 keytool 命令里指定的别名（如 my-alias），不是 myapp-release.jks。
云打包选“正式包”，不是“调试包”或默认选项
HBuilderX 的「发行 → 原生App-云打包 → Android(apk)」弹窗里，“打包类型”下拉菜单默认可能是“调试包”，直接点确定会打出来带调试签名的 APK——这种包无法上架，用户安装时大概率提示“此应用未通过 Google Play 验证”。
必须手动切换为：
- “正式包”（对应输出路径：
/unpackage/release/apk/） - 勾选“使用自有证书”，并确保前面 manifest.json 里的签名字段已填好
如果右下角打包按钮没反应，优先检查 android.package 是否为空；如果打包后安装失败，先用 apksigner verify -v your-app.apk 检查签名是否有效。
本地打包需同步 dcloud_key 和离线 SDK 版本
走本地打包路线（Android Studio + 离线 SDK）时，光配对 manifest.json 还不够。dcloud_key 是 uni-app 启动校验的关键，它和包名、证书 SHA1 强绑定。
必须确认三者一致：
-
manifest.json中的android.package - DCloud 开发者中心「各平台信息」里 Android 条目填写的包名
- 申请该 dcloud_key 时填入的证书 SHA1（用
keytool -list -v -keystore your.keystore -alias your-alias查）
另外，HBuilderX 版本、离线 SDK 版本、Android Studio 中 gradle 插件版本必须匹配。比如 HBuilderX 4.20 要配 SDK 3.3.0，混用旧版 SDK 可能编译报 Could not find method android() 类错误。
正式 keystore 必须离线保管，别进 Git
很多人图省事把 .jks 文件直接丢进项目根目录，再提交 Git——这是高危操作。一旦泄露，攻击者可伪造同包名应用覆盖用户设备上的你的正式版，劫持全部数据和通知。
正确做法：
- keystore 文件存放在项目外独立目录（如
C:/keys/myapp-prod.jks） - manifest.json 中只写绝对路径，不写相对路径
- Git 必加
**/*.jks和**/*.keystore到.gitignore - 密码绝不硬编码，生产环境用环境变量或 CI 秘钥管理工具注入
最容易被忽略的是：正式版首次上线后，后续所有热更新、补丁包、渠道包，都必须用同一份 keystore 签名。换一个，哪怕只是改了密码，用户升级时就会变成“新应用”，旧数据全丢。
