29、发布与上架：混淆配置、签名打包、Google Play上架注意事项

终于走到这一步了。你写完了WebRTC视频会议的逻辑，调通了音视频，跑通了信令。嗯，接下来就是把它变成用户手机里的一个App。

发布上架这件事，说实话，很多开发者容易轻视。我见过不少项目，代码写得漂漂亮亮，结果打包签名搞错，或者混淆规则没配好，上线后直接崩溃。更惨的是，有人因为隐私政策没写清楚，被Google Play下架。

这一章，我把这些年踩过的坑、总结的经验，一次性给你讲透。

29.1 混淆配置：别让ProGuard坑了你

混淆（ProGuard / R8）是Android打包的标配。它会把类名、方法名变成a、b、c这种短名字，还能删掉没用的代码。好处是APK变小，反编译难度增加。

但WebRTC项目有个大坑——反射。WebRTC底层大量使用JNI和反射调用，一旦混淆，运行时就会找不到类，直接崩溃。

我早期一个项目，上线后用户反馈视频打不开，查了半天，就是混淆把WebRTC的native方法给重命名了。从那以后，我的混淆规则里永远保留这几行：

# WebRTC 核心库 - 不要混淆
-keep class org.webrtc.** { *; }
-keep class org.webrtc.audio.** { *; }
-keep class org.webrtc.voiceengine.** { *; }

# JNI 方法 - 保持原名
-keepclasseswithmembernames class * {
    native <methods>;
}

# 信令相关的实体类 - 防止Gson/反射找不到
-keep class com.yourpackage.signaling.** { *; }
-keep class com.yourpackage.model.** { *; }

# 如果你用了EventBus
-keepclassmembers class * {
    @org.greenrobot.eventbus.Subscribe <methods>;
}

我个人习惯，在app/build.gradle里把混淆开关打开：

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

29.2 签名打包：你的App身份证

签名，说白了就是给你的App盖个章。Android系统通过签名来识别App的身份。同一个包名，签名不同，就是两个App。

我见过有人把debug签名直接拿去上架，结果Google Play提示签名不一致，无法更新。嗯，这种错误犯一次就够了。

生成签名文件的命令：

keytool -genkey -v -keystore release.keystore 
    -alias your_alias 
    -keyalg RSA 
    -keysize 2048 
    -validity 10000

然后配置到build.gradle里：

android {
    signingConfigs {
        release {
            storeFile file("release.keystore")
            storePassword "你的密码"
            keyAlias "your_alias"
            keyPassword "你的密码"
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

打包命令很简单：

./gradlew assembleRelease

生成的APK在 app/build/outputs/apk/release/ 目录下。如果你用了Android App Bundle（AAB），命令是：

./gradlew bundleRelease

输出文件是 .aab 格式。Google Play现在强制要求新应用使用AAB格式上传。

29.3 Google Play上架注意事项

上架Google Play，说白了就是一场合规考试。你代码写得再好，政策不通过，照样下架。

我总结了几条最容易踩的坑：

29.3.1 权限声明要合理

WebRTC视频会议App，肯定会用到摄像头和麦克风。但你不能一上来就申请。Google Play现在对敏感权限管得很严。

正确的做法是：

• 在Manifest里声明权限，但加上 tools:node="remove" 先移除
• 等到用户真正要发起或加入会议时，才动态申请
• 申请时弹窗说明用途，比如「我们需要摄像头权限才能进行视频通话」

我曾经有个App，因为进入首页就弹权限申请，被Google Play标记为「权限滥用」，审核被拒了两次。

29.3.2 隐私政策必须有

这是硬性要求。你的App如果收集任何用户数据（包括崩溃日志、设备信息），就必须有隐私政策。

隐私政策里要写清楚：

• 收集了哪些数据（比如摄像头画面、麦克风音频）
• 数据怎么用（仅用于视频通话，不上传服务器）
• 数据怎么存储和删除
• 第三方SDK（比如WebRTC本身）的数据处理

隐私政策链接要放在Google Play Console的「应用内容」页面，同时App内也要能访问到。

29.3.3 目标API级别要跟上

Google Play要求新应用必须targetSdkVersion 33以上（2024年标准）。WebRTC在Android 12、13上有一些行为变化，比如蓝牙权限、通知权限。

我建议你直接targetSdkVersion 34，然后适配好：

• Android 13的细粒度媒体权限（READ_MEDIA_VIDEO等）
• Android 14的屏幕共享新限制
• 前台服务类型声明（用于后台音视频）

29.3.4 测试账号和演示视频

如果你的App需要登录才能使用，Google Play审核人员没法直接测试。你需要提供：

• 测试账号（用户名和密码）
• 演示视频（录屏，展示核心功能）

我一般录一个2分钟的视频，展示：注册→登录→创建会议→加入会议→音视频通话→挂断。审核人员看了就明白。

29.4 知识体系总览

下面这张图，把发布上架的核心流程串起来了。你跟着走一遍，基本不会出大问题。

29.5 最后几点提醒

发布上架这件事，说白了就是细节决定成败。我最后给你几个小建议：

• 签名文件一定要备份。丢了就再也无法更新你的App。我一般存三个地方：本地硬盘、云盘、U盘。
• 混淆规则要测试。打包release版本后，用adb install装上，跑一遍核心流程。别等上线了才发现问题。
• Google Play审核周期。第一次审核一般1-3天，更新版本可能快一些。但遇到节假日会变慢。我建议避开圣诞节、新年这种时间段提交。
• 分阶段发布。不要一上来就100%全量。先放5%的用户，观察崩溃率和反馈，没问题再逐步放开。

嗯，到这里，你的WebRTC视频会议App就可以正式和用户见面了。从代码到上架，每一步都不容易，但走通了，就是一次完整的成长。

---