📚 课程目录第4章构建可发布版本

4、构建可发布版本：使用Android Studio构建发布版AAB或APK，配置版本号与版本名

说到构建发布版本，很多新手第一次都会问：我平时点一下绿色三角跑起来的那个包，能不能直接上传到商店？
嗯，答案是——不行。那个是debug包，签名不对、版本号不对、连 ProGuard 都没过。说白了，连 Google Play 的门都进不去。

我自己的习惯是，每次要发布前都会走一遍完整的构建流程，手动确认签名、版本号、minifyEnabled 这几个关键开关。早期吃过亏，有一次忘了改 versionCode，结果上传时被挡回来，那天差点没赶上发版窗口…

今天咱们就把这个流程掰开揉碎了讲清楚。你按步骤走，基本不会翻车。

4.1 两种包体格式：AAB vs APK

Google Play 从 2021 年 8 月起就要求新应用必须使用 AAB（Android App Bundle）格式发布了。但如果你在做企业内部分发、或者通过第三方市场发布，APK 还是主力。

特性	AAB	APK
Google Play 要求	必须（新应用）	仅旧应用或内部测试
生成产物	.aab	.apk
大小优化	Google Play 按需分发	手动分 ABI/密度
签名方式	使用 App Signing by Google Play（推荐）	使用自己的 jks
能否直接安装	不能，需要 bundles 工具转换或通过 Play 安装	可直接安装到设备

我个人更推荐 AAB，因为它让 Google Play 帮你做分拆优化，用户下载体积更小。当然，内部测试轨道（Internal Test Track）同时也支持 APK 上传，方便快速验证。

4.2 配置版本号与版本名

在 app/build.gradle（Module 级别）里，有两个关键字段：

android {
    defaultConfig {
        versionCode 4
        versionName "1.3.0"
        // ...
    }
}

versionCode 是整型数字，用来内部比较版本新旧。必须递增，不能重复。我一般会用构建时间戳来生成，比如 20250315 表示 2025 年 3 月 15 日的构建。

versionName 是展示给用户的字符串，像 "1.3.0"。没有硬性格式要求，但建议遵循 主版本.次版本.补丁 的语义化版本规范。

⚠ 常见事故
我见过团队里有人把 versionCode 写成了 1.3.0，结果编译报错——因为 versionCode 必须是纯整数。还有一种情况是上线后发现 versionCode 没改，旧版本覆盖新版本，用户永远收不到更新。这种坑，踩一次就记住了。

4.3 构建发布版 APK / AAB 的配置要点

在 build.gradle 里，我们需要区分 debug 和 release 构建类型。重点关注 release 的配置：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
            // 其他配置
        }
    }
}

minifyEnabled true：开启代码混淆和资源压缩。你想想看，发布版不压缩，APK 体积多大？而且混肴后反编译难度提升。
signingConfig：必须指定 release 签名。debug 签名是 Android Studio 自动生成的，上传 Play Store 会被拒绝。
proguardFiles：保留你需要的规则，比如 Retrofit、Gson 的反射模型。

曾经有个项目，开发同学把 minifyEnabled 设成了 false 就上线了，结果 APK 里包含了所有 unused 类，体积大了 30%，还暴露了内部接口。所以这个开关一定要确认好。

4.4 配置签名信息（jks）

签名文件是你身份的凭证。不要把它提交到 Git 仓库里！我在最开始工作时，直接把 jks 和 keystore.properties 都推上去了，被安全 scan 抓出来，挨了一顿批评。

推荐做法：在项目根目录新建一个 keystore.properties 文件（.gitignore 里忽略掉），然后在 build.gradle 中读取：

// 在 app/build.gradle 顶部
def keystorePropertiesFile = rootProject.file("keystore.properties")
def keystoreProperties = new Properties()
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))

android {
    signingConfigs {
        release {
            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile file(keystoreProperties['storeFile'])
            storePassword keystoreProperties['storePassword']
        }
    }
    // ...
}

对应的 keystore.properties 内容：

storeFile=C:/secure/my-release-key.jks
keyAlias=my-key
storePassword=xxx
keyPassword=xxx

另外，如果你在用 AAB + Google Play App Signing，可以只上传上传密钥（Upload Key），Google 会帮你用应用签名密钥签名最终包。这种方式更安全，因为上上传密钥泄漏了也不至于彻底丧失应用控制权。

4.5 使用 Android Studio 图形界面构建

其实很多时候我们没必要每次都用命令行。Android Studio 提供了 Build → Generate Signed Bundle / APK 向导。

打开 Android Studio，选择菜单 Build → Generate Signed Bundle / APK
选择 Android App Bundle 或 APK
选择已有的 keystore（或新建一个）
选择 release 构建变体
勾选 Signature Versions：V1 (Jar Signature) 和 V2 (Full APK Signature) 都勾上。Android 7.0 以上推荐使用 V2 签名。
点击 Finish，等待编译完成

生成的产物默认在 app/release/ 或 app/build/outputs/bundle/release/ 下。我建议每次构建后都手动确认一下 versionName 是否与预期一致。

4.6 验证构建产物

构建完了别急着上传。先做以下几步：

检查签名：使用 jarsigner -verify -verbose -certs your-app.aab（或 APK），确认签名有效。
查看版本号：用 aapt dump badging your-app.apk | grep version。对于 AAB，可以用 bundletool dump manifest --bundle your-app.aab。
测试安装：从 AAB 生成 APK 再用 adb install 安装，确保不会崩溃。我在测试 AAB 时常用 bundletool build-apks --bundle=... --output=... --connected-device 来生成设备专属 APK。

💡 小技巧
我习惯在 CI（持续集成）里构建 release 版本后，自动执行一条验证命令，如果签名不对就打断 pipeline。这样可以防止人工遗漏。

4.7 整体流程图

下面的图总结了这个章节的流程：从代码到可发布产物的关键步骤。

关键要点总结

versionCode 必须是递增整数，versionName 建议语义化版本。
release 构建务必开启 minifyEnabled 和正确签名。
签名文件不要提交到版本控制，使用 keystore.properties 外部配置。
构建后一定要用 jarsigner 或 bundletool 验证签名和版本号。
内部测试轨道可以直接上传 APK 或 AAB，但 AAB 是未来趋势。

其实构建这块，多走几遍就熟了。我每次上线前都会开一个 checklist，对着钩子一个个打勾，确保没有遗漏。另一个建议是：把 versionCode 的更新和 Git tag 绑定起来，比如每次打 tag 时自动 +1。这样可以避免人为忘记改号。

好了，按上面的步骤跑一遍，你的发布包应该就能稳稳过关了。