如何快速打包发布 Spotui 正式版：sign-release.sh 签名脚本与 ProGuard 配置实战指南

【免费下载链接】SpotuiSpotify clone with deep integration项目地址https://gitcode.com/gh_mirrors/spo/Spotui点击查看免费下载Spotui 是一款深度集成 Spotify 账户的 Android 音乐播放器Spotify clone基于 Jetpack Compose 开发支持歌单同步、同步歌词、真实推荐电台与无损 FLAC 下载。本文面向新手手把手讲清 Spotui 正式版 APK 的完整发布流程如何执行assembleRelease构建、如何使用 scripts/sign-release.sh 签名脚本完成双签名密钥轮换以及 ProGuard 混淆配置的现状与开启方法帮你顺利产出一个可覆盖升级的发布版 APK。一、发布前你需要准备什么正式发布 Spotui 需要满足以下三个条件准备项说明Android SDK设置ANDROID_HOME环境变量macOS 默认~/Library/Android/sdkJDK 17app/build.gradle.kts 中sourceCompatibility固定为 Java 17签名密钥目录两个 keystore 一个 lineage 文件存放在仓库之外⚠️ 密钥文件不放在仓库里而是放在$SPOTUI_SIGNING指定的目录默认~/.spotui-signing其中包含keyA.keystore旧版本1.3、1.5使用的签名密钥 AkeyB.keystore1.6 及以后版本使用的签名密钥 Blineage-A-to-B.binAPK 密钥轮换Key Rotation的血缘文件告诉系统“密钥 A 已合法升级为密钥 B”这样设计的原因写得很直白历史上 1.4 和 1.5 曾因构建机器不同而各自使用不同的 debug 密钥签名导致互相无法覆盖升级见 app/build.gradle.kts 中的注释。签名密钥统一外置后这个问题被彻底解决。二、第一步构建未签名的 Release APK在仓库根目录执行./gradlew :app:assembleRelease构建完成后产物位于app/build/outputs/apk/release/app-release.apk版本号管理别改错这两个参数版本信息集中在 app/build.gradle.kts 的defaultConfig中versionCode 16 versionName 1.6versionCode必须严格递增且要大于所有已发布版本注释提醒1.5 的 versionCode 是 14versionName是对外显示的版本号签名脚本会从build.gradle.kts中自动解析它用来命名最终产物同时项目内置了更新检查模块 UpdateChecker.ktApp 会拉取远端最新 Release 标签并与本地versionName逐段比较例如v1.10 1.6。因此每次发布新版本时记得同步更新versionName用户的更新提示才会正常工作。三、第二步用 sign-release.sh 完成正式签名构建成功后运行签名脚本脚本头部注释给出了标准用法./gradlew :app:assembleRelease scripts/sign-release.sh脚本逐段拆解整个 scripts/sign-release.sh 只有 20 多行逻辑非常清晰1定位工具与版本SDK${ANDROID_HOME:-$HOME/Library/Android/sdk} BT$(ls -d $SDK/build-tools/* | sort -V | tail -1) VERSION$(sed -n s/.*versionName \(.*\)/\1/p app/build.gradle.kts)自动选取最新版 build-tools里的apksigner工具并从build.gradle.kts读出versionName最终产物命名为release/spotui-$VERSION.apk例如release/spotui-1.6.apk。2执行双密钥轮换签名核心$BT/apksigner sign \ --ks $K/keyA.keystore ... \ --next-signer --ks $K/keyB.keystore ... \ --lineage $K/lineage-A-to-B.bin --rotation-min-sdk-version 28 \ --out $OUT $IN这条命令一次性做了三件事--ks keyA.keystore用密钥 A 签第一套 V1 签名供Android 8 及更早设备识别--next-signer --ks keyB.keystore再追加密钥 B 的 V2 签名供Android 9 及以上设备使用--lineage ... --rotation-min-sdk-version 28写入密钥轮换血缘让 Android 9 系统接受“从密钥 A 升级到密钥 B”的覆盖安装3双指纹验证失败即报错$BT/apksigner verify --print-certs --max-sdk-version 27 $OUT | grep -q a91b5a4a3bf3 $BT/apksigner verify --print-certs --min-sdk-version 28 $OUT | grep -q 62857c6ecd83脚本开头set -e保证任何一步失败立即终止它分别以“旧设备视角”和“新设备视角”验证产物中确实包含密钥 A、密钥 B 的证书指纹。只有两条都通过release/spotui-x.x.apk才算合格的发布包。四、第三步读懂并可选开启ProGuard 配置当前现状Release 默认不开混淆Spotui 的 release 构建类型配置在 app/build.gradle.ktsrelease { isMinifyEnabled false proguardFiles( getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro ) signingConfig signingConfigs.findByName(release) ?: signingConfigs.getByName(debug) }要点说明isMinifyEnabled false当前正式版不启用R8/ProGuard 压缩混淆APK 体积换稳定性这对依赖大量 JSON 反序列化和 WebView JS 桥接的项目是务实选择proguardFiles(...)已挂好规则文件 app/proguard-rules.pro 目前是标准模板大部分规则处于注释状态一旦开启混淆即可直接追加项目规则签名配置回退逻辑如果仓库根目录存在keystore.properties含storeFile、storePassword、keyAlias、keyPassword四项同样不入库就使用正式release签名否则回退到本机 debug 密钥——这种包只能在同一台机器之间覆盖升级仅用于内部测试如果你想为 Spotui 开启混淆把isMinifyEnabled改为true后建议按以下思路在 app/proguard-rules.pro 中补充规则此处为思路示意非仓库现有内容Spotify/InnerTube JSON 模型com.metrolist.spotify.models、com.metrolist.innertube.models下大量 data class 依赖 kotlinx-serialization 按字段名反序列化需要保留WebView JS 接口com.metrolist.utils.potoken与cipher包中的 WebView JavaScript 桥接类保留被 JS 反射调用的成员Hilt / KSP 生成代码通常由依赖自带 consumer rules 覆盖一般无需手写开启后务必回归测试登录、播放、歌词、Po Token 生成这几条链路是混淆最易出问题的地方 模板中预留的SourceFile,LineNumberTable规则可以在调试线上崩溃堆栈时临时打开帮助定位混淆后的代码行号。五、发布检查清单 versionCode已递增、versionName已更新app/build.gradle.kts$SPOTUI_SIGNING目录下keyA.keystore、keyB.keystore、lineage-A-to-B.bin齐全./gradlew :app:assembleRelease构建成功scripts/sign-release.sh输出Signed release/spotui-x.x.apk两条证书验证均通过真机安装验证旧版本覆盖安装成功登录 Spotify、播放、下载无损文件均正常完成以上步骤你就得到了一个既能让 Android 8 老设备识别旧签名、又能让新设备无缝升级的 Spotui 正式发布包。整个流程的核心价值就在于 sign-release.sh 这条“双密钥 lineage”流水线——这也是 Android 应用更换签名密钥时仍能平滑升级用户的标准做法。赞分享【免费下载链接】SpotuiSpotify clone with deep integration项目地址https://gitcode.com/gh_mirrors/spo/Spotui点击查看免费下载相关推荐三条命令跑起你的魔兽世界WoTLK服务器AzerothCore-WoTLK Docker部署指南三条命令跑起你的魔兽世界WoTLK服务器AzerothCore WoTLK Docker部署指南 做完这篇你手里会有一个完整可玩的魔兽世界 3.3.5巫妖后端游戏开发Applite 发布流水线实战用 release.sh 一条命令完成构建、签名、公证、打包与 Sparkle 更新发布Applite 发布流水线实战用 release.sh 一条命令完成构建、签名、公证、打包与 Sparkle 更新发布 Applite 是一个基于 Homeb桌面应用包管理器开发工具UI组件electron-builder 的 macOS PKG 打包全指南配置参数、签名证书与安装脚本实战electron builder 的 macOS PKG 打包全指南配置参数、签名证书与安装脚本实战 导读 electron builder 通过顶层 pkg构建工具桌面应用开发工具上一篇3分钟搞定Rubick插件调试终极远程调试全流程指南下一篇phpDocumentor/ReflectionCommon 2.x版本新特性值得关注的五大改进创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考