Android 打包与签名深度解析——跨平台开发者必知必会

一句话概括

打包与签名是应用从「能跑」到「能上架」的最后一道关，决定了你的 App 能不能被设备信任、能不能进 Google Play、体积能不能更小。对跨端开发者来说，它常是个黑盒：你 flutter build apk 一路绿灯，提审时却卡在「必须传 AAB」「签名不一致」「Release 一装就崩」。

核心结论就三句：APK 是成品、AAB 是给 Play 的「原料」；v2 签名是 Android 7+ 的底线、v3 支持换密钥、v4 服务增量安装；keystore 一旦丢且无 Play 签名，这个包名就永远废了。 把它当原理学，而不是当魔法配。

核心知识点

1. APK vs AAB：成品与原料的区别

APK 是设备能直接安装的压缩包；AAB（Android App Bundle）不是安装包，而是上传给 Google Play 的”元打包”，由 Play 按用户设备（屏幕密度、CPU 架构、语言）动态生成优化的 APK Split。

你的产物      Play 后台        用户设备
app.aab  ──▶  生成 Split  ──▶  arm64 + xxhdpi + zh 的定制 APK

维度	APK	AAB
能否直装	能	不能（需 bundletool 转）
体积	包含所有资源，偏大	按设备裁剪，平均小 15%~20%
上架 Play	2021-08 起新应用不再接受	强制要求
分发渠道	官网/三方商店/内测直发	仅经 Play 分发

# AAB 本地转 APK 测试（不能直接 install aab）
java -jar bundletool.jar build-apks \
  --bundle=app-release.aab --output=app.apks \
  --ks=upload-keystore.jks --ks-key-alias=upload-key
java -jar bundletool.jar install-apks --apks=app.apks

一句话：官网自分发/内测用 APK，上架 Play 必须 AAB。

2. 签名方案 v1→v4：v2 是底线

签名既做身份认证，也保证「同签名才能覆盖安装」。方案一路演进：

• v1（JAR 签名）：逐文件摘要写进 META-INF/，只覆盖内容、不覆盖 ZIP 结构，可被篡改且 Android 7+ 安装慢，已不推荐。
• v2（全文件签名，API 24+）：在 ZIP 中央目录前插入 APK Signing Block，对整个文件哈希签名，任何改动即验证失败，安装更快。这是现代应用的底线。
• v3（API 28+）：在 v2 基础上加密钥轮替（Proof-of-Rotation），换密钥也能无缝更新；v3.1（API 33+）支持轮替链里给不同密钥指定目标 SDK。
• v4（API 30+）：用 Merkle 哈希树做流式/增量安装，签名存 .idsig 独立文件，需 v2/v3 配合，用于 ADB 增量安装。

// build.gradle.kts：AGP 默认同时开 v1+v2；minSdk ≥ 24 可只保留 v2
android {
    signingConfigs {
        create("release") {
            storeFile = file("upload-keystore.jks")
            storePassword = System.getenv("STORE_PASSWORD")
            keyAlias = "upload-key"
            keyPassword = System.getenv("KEY_PASSWORD")
            enableV1Signing = true   // 兼容 Android 6- 才需要
            enableV2Signing = true   // 必须
            enableV3Signing = true   // 预留换密钥能力
        }
    }
}

3. keystore 与 keytool：密钥就是应用的身份证

keystore 是 Java KeyStore 格式的密钥仓库（.jks/.keystore），里面按 alias 存密钥对。它等同于你的开发者身份：同包名应用，只有同签名才能覆盖安装。

# 生成上传密钥（推荐 RSA 2048，有效期覆盖应用生命周期）
keytool -genkeypair -v \
  -keystore upload-keystore.jks \
  -alias upload-key \
  -keyalg RSA -keysize 2048 -validity 10000

// Flutter/RN 通用：把密钥信息从环境变量/CI 注入，别进 Git
android {
    signingConfigs {
        create("release") {
            storeFile = file("upload-keystore.jks")
            storePassword = System.getenv("STORE_PASSWORD")
            keyAlias = "upload-key"
            keyPassword = System.getenv("KEY_PASSWORD")
        }
    }
    buildTypes {
        release { signingConfig = signingConfigs.getByName("release") }
    }
}

// ❌ 把 keystore 和明文密码提交进 Git、只存在个人电脑硬盘 // ✅ 用 CI 密钥库或密码管理器保管，多人协作走统一签名服务

4. 混淆 R8：Release 崩溃的第一嫌疑人

AGP 3.4 起 R8 是默认混淆/压缩工具，做三件事：压缩（删未用代码）、混淆（重命名 a/b/c）、优化。最大坑是 Release 闪退、堆栈全是 a.b.c()。

// build.gradle.kts
buildTypes {
    release {
        isMinifyEnabled = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

# proguard-rules.pro：保住会被反射/JNI/序列化碰到的类
-keepclassmembers class * { @android.webkit.JavascriptInterface <methods>; }
-keep class io.flutter.plugin.** { *; }
-keep class com.google.gson.** { *; }
-keepclassmembers class * implements java.io.Serializable { *; }

# 还原混淆堆栈：mapping.txt 在 build/outputs/mapping/release/
# 用 Android SDK 自带的 retrace（AGP 4.1+ 为 retrace.jar）
java -jar $ANDROID_HOME/cmdline-tools/*/lib/retrace.jar \
  mapping.txt crash.txt

// ❌ 等新 SDK 上线崩溃了才去补 -keep 规则 // ✅ 集成第三方 SDK 时先查其官方混淆规则，并保留 mapping.txt 用于排障

5. Play App Signing：把命根子交给 Google

传统模式下你用自己的密钥签所有版本，密钥一丢，同包名应用永不能更新。Play App Signing 把角色拆成两个：

• 上传密钥（Upload Key）：你用来签 AAB 上传；丢了可在 Play Console 重置。
• 发布密钥（App Signing Key）：Google 替你保管并用来签分发到设备的 APK；支持 v3 密钥轮替。

你(上传密钥) ──签 AAB──▶ Google Play ──用发布密钥重签──▶ 用户设备

// ❌ 不上 Play 签名、自己攥着发布密钥还到处拷贝 // ✅ 新应用直接开 Play 签名（开启后不可逆），发布密钥由 KMS 保管，只导出备份用于三方商店

6. 多渠道 productFlavors：一套代码多端分发

android {
    flavorDimensions("channel")
    productFlavors {
        create("googleplay") {
            dimension = "channel"
            buildConfigField("String", "CHANNEL", "\"googleplay\"")
        }
        create("huawei") {
            dimension = "channel"
            buildConfigField("String", "CHANNEL", "\"huawei\"")
        }
    }
}

# Flutter 需要先在原生平配置 productFlavors 才能用 --flavor
flutter build appbundle --flavor googleplay --release

美团 Walle 之类的方案则是往 APK Signing Block（APK 签名块，v2/v3 签名方案所用）写渠道信息，无需重打包——适合海量渠道。

其实你每天都在用

• flutter build apk / assembleRelease：生成的 APK 默认就带 v1+v2 签名，能直接装真机测试
• 上架 Google Play：传 AAB 而不是 APK，否则被拒
• 接第三方推送/支付 SDK：集成时少看一眼官方混淆规则，Release 就崩在它的回调里
• bundletool install-apks：本地想验证 AAB 安装效果时的救命命令
• 多渠道包：Google Play 版和华为版要用不同推送/支付，靠 BuildConfig.FLAVOR/CHANNEL 区分
• CI 发版：签名密码走环境变量注入，而不是写死在 build.gradle

常见误解（FAQ）

❌ 误区一：”AAB 和 APK 差不多，直接把 AAB 发给测试同学装就行”

AAB 不是安装包，设备根本认不出，必须 bundletool build-apks 转成 .apks 再 install-apks。本地自测/官网分发请打 APK，只有上架 Play 才传 AAB。

❌ 误区二：”签名只是防盗版，随便弄个密钥就行，丢了再生成一个”

签名是「同包名覆盖安装」的信任根。没开 Play 签名时密钥一丢，这个包名在 Google Play 上就永远不能更新，只能换包名重发、流失全部用户。务必用 Play 签名 + 密钥备份。

❌ 误区三：”Debug 能跑 Release 就一定能跑”

恰恰相反，Release 开了 R8 混淆，反射/JNI/序列化类、WebView 的 @JavascriptInterface 常被误删，表现就是 Debug 正常、Release 闪退。发版前必须测 Release 产物并留好 mapping.txt。

❌ 误区四：”minSdk 24 以上就不需要 v1 签名了”

对，v1 只为兼容 Android 6 及以下。minSdk ≥ 24 时只需 v2 + v3即可，多开 v1 反而徒增体积与历史包袱。

一句话总结

打包与签名不是发布前的”配置填空题”，而是应用的信任链：AAB 替你瘦身、v2 签名守住完整性、Play 签名兜住密钥风险——而那枚 keystore，请像身份证一样备份好，因为它丢了，这个包名就真的”死”了。