17、应用签名与发布：签名配置、APK构建、AAB格式、Google Play Console发布流程
说实话，很多开发者写代码时行云流水，一到发布环节就手忙脚乱。我见过不少同事，在最后一步因为签名搞错、密钥丢失，折腾一整天。今天咱们就把这块彻底捋清楚。
17.1 签名配置——你的应用身份证
签名是什么？说白了就是给应用盖个章。Android系统通过签名来识别应用的作者身份。同一个包名，如果签名不一致，系统会认为这是两个不同的应用，直接拒绝覆盖安装。
我在项目中遇到过最惨的一次：同事把debug签名当release签名上传到商店，结果用户反馈无法更新。嗯，从那以后我养成了一个习惯——每次构建前先检查签名配置。
密钥库生成
用Android Studio生成密钥库很简单，但我个人习惯用命令行，更可控：
keytool -genkey -v -keystore my-release-key.jks \
-keyalg RSA -keysize 2048 -validity 10000 \
-alias my-alias这里有几个参数要注意：
- -validity：有效期，单位是天。10000天大约是27年，够用了
- -keysize：2048位是当前推荐值，别用1024了，不安全
- -keyalg：RSA是目前最通用的算法
我曾经见过一个团队，密钥库存在某位离职同事的电脑里，人走了密钥也找不到了。后来那个应用只能改名重新上架。密钥库一定要备份，多存几个地方。
Gradle签名配置
在模块级的build.gradle里配置签名，我一般这样写：
android {
signingConfigs {
release {
storeFile file("my-release-key.jks")
storePassword "your-store-password"
keyAlias "my-alias"
keyPassword "your-key-password"
}
}
buildTypes {
release {
signingConfig signingConfigs.release
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
}上面的写法只是为了演示。实际项目中，密码应该从环境变量或gradle.properties中读取。我习惯在gradle.properties里写：
RELEASE_STORE_PASSWORD=xxx然后在build.gradle里用
System.getenv("RELEASE_STORE_PASSWORD")读取。
17.2 APK构建——传统但依然重要
APK是Android应用的传统打包格式。虽然Google现在主推AAB，但APK在测试和内部分发时仍然不可或缺。
构建APK有两种方式：
- Android Studio直接构建：Build → Build Bundle(s) / APK(s) → Build APK(s)
- 命令行构建：
./gradlew assembleRelease
我个人更推荐命令行方式。为什么？因为可以集成到CI/CD流水线里，实现自动化构建。你想想看，每次手动点来点去，多容易出错。
构建完成后，APK文件在 app/build/outputs/apk/release/ 目录下。记得用 jarsigner 或 apksigner 验证签名：
apksigner verify --verbose app-release.apk输出应该显示 Verified using v1 and v2 schemes。如果只有v1，说明签名方案太老了。
Android 7.0（API 24）开始支持v2签名方案，Android 9.0（API 28）开始支持v3签名方案。建议同时启用v1和v2，确保兼容性。
17.3 AAB格式——Google Play的新标准
Android App Bundle（AAB）是Google在2018年推出的新格式。它不是一个安装包，而是一个包含所有资源的"母包"。Google Play会根据用户的设备配置，从AAB中提取出最适合的APK。
说白了，AAB的好处就是：
- 应用体积更小：用户只下载需要的资源，平均减少15%的体积
- 动态分发：可以按需下载功能模块
- Play Feature Delivery：条件性分发，比如只在特定国家显示某个功能
构建AAB的命令也很简单：
./gradlew bundleRelease生成的AAB文件在 app/build/outputs/bundle/release/ 目录下。
AAB文件不能通过adb install安装到设备上。你需要用
bundletool 工具将其转换为APK才能测试。我习惯在CI流程中加一步：java -jar bundletool.jar build-apks --bundle=app.aab --output=app.apks
17.4 Google Play Console发布流程
终于到了上架这一步。Google Play Console的界面经常更新，但核心流程没变过。
第一步：创建应用
登录Google Play Console，点击"创建应用"。填写应用名称、默认语言、应用类型（应用/游戏）和是否付费。
第二步：填写商店信息
这里需要准备：
- 应用简介（80字以内）和完整描述（4000字以内）
- 截图（至少2张，推荐6-8张）
- 图标（512x512，32位PNG）
- 特色图（1024x500）
我记得有一次，因为截图尺寸不对，被审核打回来三次。后来我写了个脚本自动裁剪截图，再也没出过问题。
第三步：上传AAB
在"发布" → "内部测试"或"正式版"中上传AAB文件。上传后，Google Play会自动检查签名和兼容性。
第四步：填写版本信息
版本号、版本名称、更新说明。更新说明建议写清楚：
- 新增了什么功能
- 修复了什么bug
- 有没有需要用户注意的变更
第五步：审核与发布
提交审核后，通常几小时到几天不等。审核通过后，你可以选择手动发布或定时发布。
我建议新版本先发布到5%的用户，观察几天。如果没有严重问题，再逐步扩大到100%。这样即使有bug，影响面也小。
17.5 签名密钥管理——血的教训
最后，我想聊聊密钥管理。这可能是整个发布流程中最容易被忽视，但后果最严重的一环。
我曾经接手过一个项目，前任开发者把密钥库放在项目的根目录下，还提交到了Git仓库。虽然仓库是私有的，但想想都后怕。密钥库一旦泄露，别人就可以用你的签名发布恶意应用。
我的建议是：
- 密钥库文件不要放在项目目录中
- 使用独立的密码管理工具（如1Password、KeePass）存储密码
- 至少备份到两个不同的物理位置
- 考虑使用Google Play App Signing，把密钥交给Google保管
Google Play App Signing是个好东西。你上传一个上传密钥，Google用你的应用签名密钥重新签名。这样即使上传密钥丢了，也能找Google恢复。我现在的项目都这么配置，省心不少。
好了，签名与发布这块就聊到这儿。记住一句话：签名是应用的身份证，丢了就没了。做好备份，规范流程，发布才能顺顺利利。