发布应用
本教程共 100 篇 · 第 100 篇 · 更新于 2026-07-28 · 约 9 分钟阅读
100. 发布应用
本节目标:掌握 Android 应用发布全流程,包括生成签名密钥、配置 Gradle 签名、构建 release 包、代码混淆与压缩、版本管理、Google Play 上架。
应用写完了,测试过了,接下来就是发布。这章把从打包到上架的完整流程走一遍。
为什么需要签名
打个比方,签名就像你在文件上按手印。别人看到手印就知道是你盖的,不是伪造的。
Android 系统要求每个 APK/AAB 都必须签名才能安装。签名的作用:
- 身份验证:证明应用来自你,不是被人篡改过的。
- 完整性校验:签名后内容被改过,签名就失效。
- 更新验证:新版应用的签名必须和旧版一致,否则不能覆盖安装。
Warning签名密钥(Keystore)是你应用的身份证。丢了就永远更新不了应用(Google Play 的密钥升级功能除外)。务必备份好,别上传到公开仓库。
生成签名密钥
用 Android Studio 可视化生成,或用命令行。
方式一:Android Studio
- 菜单
Build > Generate Signed Bundle / APK。 - 选
Android App Bundle,点 Next。 - 点
Create new...创建新密钥。 - 填写信息:
- Key store path:密钥文件保存路径,如
C:\Users\你的用户名\keystore\app-release.jks。 - Password:密钥库密码。
- Alias:密钥别名,如
key0或app-key。 - Key password:密钥密码(可以和密钥库密码一样)。
- Validity:有效期,填 25 年(至少要比预期维护周期长)。
- Certificate:填姓名、组织等信息。
- Key store path:密钥文件保存路径,如
- 点 OK 生成。
方式二:命令行
keytool -genkey -v -keystore app-release.jks -keyalg RSA -keysize 2048 -validity 9125 -alias app-key
参数说明:
-keystore:输出文件路径。-keyalg RSA:密钥算法,用 RSA。-keysize 2048:密钥长度,2048 位够安全。-validity 9125:有效期 25 年(9125 天)。-alias:密钥别名。
按提示输入密码和信息即可。
配置 Gradle 签名
生成密钥后,告诉 Gradle 用它签名。在模块级 build.gradle.kts 里配置:
android {
// ...
signingConfigs {
create("release") {
storeFile = file("C:/Users/你的用户名/keystore/app-release.jks")
storePassword = "你的密钥库密码"
keyAlias = "app-key"
keyPassword = "你的密钥密码"
}
}
buildTypes {
release {
isMinifyEnabled = true // 开启混淆
isShrinkResources = true // 开启资源压缩
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
signingConfig = signingConfigs.getByName("release")
}
}
}
Warning别把密码硬编码到
build.gradle.kts里然后提交到 Git。密码是敏感信息。用local.properties或环境变量管理:
// 读取 local.properties
val localProperties = java.util.Properties().apply {
val file = rootProject.file("local.properties")
if (file.exists()) {
file.inputStream().use { load(it) }
}
}
android {
signingConfigs {
create("release") {
storeFile = file(localProperties.getProperty("storeFile"))
storePassword = localProperties.getProperty("storePassword")
keyAlias = localProperties.getProperty("keyAlias")
keyPassword = localProperties.getProperty("keyPassword")
}
}
}
local.properties 加到 .gitignore 里:
# .gitignore
local.properties
*.jks
*.keystore
构建 Release 包
Google Play 要求上传 AAB(Android App Bundle)格式,不是 APK。AAB 是发布格式,Google Play 会根据它生成针对不同设备优化的 APK。
方式一:Android Studio
Build > Generate Signed Bundle / APK。- 选
Android App Bundle,点 Next。 - 选签名配置,点 Next。
- 选
release,点 Finish。 - 等待构建完成,点
locate打开输出目录。
方式二:命令行
./gradlew bundleRelease
输出文件在 app/build/outputs/bundle/release/app-release.aab。
如果需要本地测试 APK(不通过 Google Play 分发):
./gradlew assembleRelease
输出在 app/build/outputs/apk/release/app-release.apk。
Tip构建前先跑
./gradlew clean清理旧产物,避免缓存干扰。
代码混淆与压缩
isMinifyEnabled = true 同时做三件事:
- 代码压缩(R8 shrinking):移除没用的代码,减小包体积。
- 资源压缩(Resource shrinking):移除没用的资源文件。
- 代码混淆(Obfuscation):把类名、方法名改成短名字(如
a、b),增加逆向难度。
ProGuard 规则
混淆会移除「看起来没用」的代码,但有些代码是被反射调用的(比如 JSON 解析、序列化),R8 看不出来。需要用 ProGuard 规则告诉它「别删这个」。
在 app/proguard-rules.pro 里写规则:
# 保留 data class 的字段名(JSON 解析需要)
-keepclassmembers class com.example.app.data.** {
<fields>;
}
# 保留 Room 生成的代码
-keep class * extends androidx.room.RoomDatabase { <init>(); }
# 保留 Retrofit 的接口
-keepattributes Signature
-keepattributes *Annotation*
-keep class com.example.app.api.** { *; }
# 保留 Gson/Moshi 的模型类
-keep class com.example.app.model.** { *; }
# 保留 Kotlin 元数据
-keep class kotlin.Metadata { *; }
常用规则:
| 规则 | 作用 |
|---|---|
-keep class com.example.** { *; } | 保留指定包下所有类和成员 |
-keepclassmembers | 只保留成员,不保留类名 |
-keepattributes Signature | 保留泛型签名 |
-keepattributes *Annotation* | 保留注解 |
Warning混淆后如果崩溃,堆栈里的类名是
a.b.c,看不懂。需要用反混淆。构建时 R8 会生成映射文件app/build/outputs/mapping/release/mapping.txt。用 Android Studio 的Analyze Stack Trace功能贴入混淆堆栈,选 mapping 文件就能还原。
测试混淆
混淆容易出问题,务必测试 release 包:
./gradlew bundleRelease
装到设备上跑一遍核心功能。特别是 JSON 解析、反射、序列化相关的功能。
Note如果 release 包崩了但 debug 包正常,大概率是混淆规则没写够。看 Logcat 的崩溃信息,找到被删或被重命名的类,加 keep 规则。
版本管理
每次发布新版本,要更新版本号。build.gradle.kts 里有两个版本号:
android {
defaultConfig {
versionCode = 1 // 整数,每次发布递增
versionName = "1.0.0" // 字符串,给用户看的
}
}
- versionCode:内部版本号,整数,必须递增。Google Play 用它判断新旧。
- versionName:显示版本号,如
1.0.0、2.1.3,用户在设置里看到的。
推荐用语义化版本号(Semantic Versioning):主版本.次版本.修订号
1.0.0->1.0.1:修 bug1.0.1->1.1.0:加新功能1.1.0->2.0.0:大改,不兼容旧版
每次改版本号,versionCode 也加 1。
Google Play 上架
第一步:注册开发者账号
- 访问 Google Play Console。
- 用 Google 账号登录。
- 支付一次性注册费 25 美元。
- 填写开发者名称、联系邮箱等。
- 完成身份验证(个人或组织)。
第二步:创建应用
- 登录 Play Console,点
创建应用。 - 填应用名称、默认语言、应用/游戏类型、免费/付费。
第三步:填写商品详情
在 主要商品详情 里填写:
- 应用名称:最多 30 个字符。
- 简短说明:最多 80 个字符,用户列表里看到的一句话。
- 完整说明:最多 4000 个字符,详情页的介绍。
- 应用图标:512x512 PNG。
- 精选图片:1024x500 PNG,用于商店推荐位。
- 手机截图:至少 2 张,建议 1080x1920 以上。
- 应用类别和标签。
第四步:上传 AAB
- 进入
测试或正式版本。 - 正式发布建议先走内部测试 -> 封闭测试 -> 开放测试 -> 正式版。
- 创建新版本,上传
app-release.aab。 - 填写版本说明(这版改了啥)。
Tip第一次发布必须先过内部测试。Google Play 要求至少有一个测试轨道的版本经过审核后才能发正式版。
第五步:内容评级
- 进入
应用内容 > 内容分级。 - 填问卷,回答应用是否含暴力、色情等内容。
- 系统自动计算分级(如 Everyone、Teen、Mature)。
第六步:隐私政策
- 准备一个隐私政策页面(网页 URL)。
- 在
应用内容 > 隐私政策里填 URL。 - 声明是否收集个人数据、是否含广告、目标受众年龄段等。
Warning隐私政策是必填项。没有隐私政策 URL 的应用会被拒。如果你的应用收集了任何用户数据(哪怕只是设备 ID),必须如实声明。
第七步:发布
- 确认所有必填项都打绿勾。
- 进入
正式版本,点审查版本。 - 点
开始发布到正式版。 - 等待 Google 审核,通常 1-7 天。
- 审核通过后,应用自动上架。
发布前检查清单
发布前过一遍这个清单,避免被打回:
- applicationId 正确,没有用
com.example占位符。 - versionCode 比上次发布的大。
- release 包签名正确。
- 混淆规则完整,release 包核心功能正常。
- 应用图标、名称、版本号正确。
- 移除了所有
android.util.Log调试日志(或用 ProGuard 移除)。 - 网络请求用 HTTPS(明文 HTTP 需额外配置)。
- targetSdkVersion 符合 Google Play 要求(必须达到最新要求)。
- 隐私政策 URL 可访问。
- 截图和描述与应用实际功能一致。
网络安全配置
release 包默认不允许明文 HTTP 请求。如果你的服务器用了 HTTP(没 HTTPS),需要配置网络安全策略:
<!-- res/xml/network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">your-api-domain.com</domain>
</domain-config>
</network-security-config>
<!-- AndroidManifest.xml -->
<application
android:networkSecurityConfig="@xml/network_security_config"
...>
Warning明文 HTTP 不安全,能被抓包。正式应用建议全部用 HTTPS。上面的配置只在服务器还没上 HTTPS 时临时用。
移除调试日志
release 包不该有调试日志。用 ProGuard 自动移除:
# 移除 Log.d 和 Log.v 调用
-assumenosideeffects class android.util.Log {
public static *** d(...);
public static *** v(...);
}
或者用 BuildConfig.DEBUG 控制:
if (BuildConfig.DEBUG) {
Log.d("TAG", "debug message")
}
版本更新
发布新版本时:
- 修改代码,测试通过。
- 更新
versionCode和versionName。 - 重新构建 AAB。
- 在 Play Console 的正式版本里创建新版本,上传 AAB。
- 填写版本说明。
- 提交审核。
Google Play 支持「分阶段发布」,先让一部分用户更新,没问题再全量:
- 创建版本时选「分阶段发布」。
- 设初始比例(如 10%)。
- 观察崩溃率和评分。
- 逐步增加比例,直到 100%。
Tip分阶段发布能帮你提前发现问题。如果新版本有严重 bug,只影响 10% 的用户,可以及时回滚。
常见拒审原因
| 原因 | 解决 |
|---|---|
| 缺隐私政策 | 提供有效的隐私政策 URL |
| 目标 API 级别太低 | 升级 targetSdkVersion 到 Google Play 要求 |
| 权限声明不合理 | 只申请真正需要的权限,在描述里说明用途 |
| 重复内容 | 应用和已有应用太像,增加独特功能 |
| 崩溃/功能不完整 | 充分测试,确保核心功能可用 |
| 违反政策 | 色情、暴力、侵权内容,阅读开发者政策 |
| 应用内购买未用 Billing 库 | 数字商品必须用 Google Play Billing |
小结
发布应用分三步:签名、打包、上架。签名用 keytool 或 Android Studio 生成 Keystore,配置到 Gradle 的 signingConfigs。构建用 ./gradlew bundleRelease 生成 AAB。混淆和压缩用 isMinifyEnabled 和 isShrinkResources,配合 ProGuard 规则保留反射用到的类。版本管理用 versionCode(递增整数)和 versionName(显示版本号)。Google Play 上架:注册开发者账号、创建应用、填商品详情、上传 AAB、做内容评级和隐私政策、提交审核。发布前过检查清单,发布用分阶段发布降低风险。
这是本教程的最后一章。从认识 Android 到发布应用,100 章走完了 Android 开发的完整旅程。祝你写出用户喜欢的应用。