Fleet 开源仓库 Android Agentfleetd-android发布流程完整指南从 RC 分支到 Google Play 生产发布【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet本篇指南基于 Fleet 开源仓库中 android/RELEASE.md 的发布流程系统讲解 Fleet 自研 Android Agentcom.fleetdm.agent从版本号升级、RC 分支创建、staging 试发布、Google Play 生产上架、Git 打标签到收尾里程碑的完整发布链路。读完本文你将掌握该 Agent 每次版本迭代所遵循的标准操作流程、签名与keystore.properties配置要点、make changelog-android变更日志生成机制以及如何把版本升级与 CHANGELOG 安全合回main分支的工程实践。一、发布总览一次版本发布要做哪些事Fleet Android Agent 是 Fleet 设备管理生态中的移动端组件通过 Android MDMAMAPI在企业设备上安装运行负责证书注册、SCEP 证书签发等任务相关逻辑见 AgentApplication.kt。其发布流程与常规 Android 应用的上架流程类似但叠加了开源仓库 双环境staging/production 双应用 IDcom.fleetdm.agent.stage/com.fleetdm.agent的特点整体分为九个阶段创建 RC 分支rc-minor-fleetd-android-v1.X.X升级app/build.gradle.kts中的versionCode/versionName通过make changelog-android生成 CHANGELOG提交并推送 RC 分支用 staging 应用com.fleetdm.agent.stage试发布与验证正式发布到生产环境com.fleetdm.agent为 RC 分支打 Git 标签把版本号与 CHANGELOG 合回main分支收尾并关闭里程碑下面按阶段逐一展开。二、创建 RC 分支每次发布都在main的最新提交上拉出独立的 RCRelease Candidate分支命名格式固定为rc-minor-fleetd-android-v1.X.X其中1.X.X为本次发布的目标版本号git checkout main git pull origin main git checkout -b rc-minor-fleetd-android-v1.X.XRC 分支的作用是把准备发布的所有改动版本号、CHANGELOG与main上并行进行的日常开发隔离开保证评审、试发布过程中不受到主干新提交的干扰同时第 8 步合回 main时也能精确地只带回与发布相关的文件。三、升级版本号versionCode / versionName打开 android/app/build.gradle.kts在defaultConfig中更新两个字段defaultConfig { applicationId com.fleetdm.agent versionCode 2 // Increment by 1 each release versionName 1.1.0 // Semantic version for display }versionCode必须随每次发布递增的整数这是 Google Play 判定新版本的依据漏加或回退会被商店拒绝versionName展示给用户的语义化版本字符串与versionCode一一对应。当前仓库中的实际取值compileSdk 36、minSdk 33、targetSdk 36versionCode 13、versionName 1.6.0可以作为参考每一行历史版本号都能在 android/CHANGELOG.md 中找到对应记录例如 1.6.0 增加了 SCEP 证书请求的 Subject Alternative NameSAN支持1.0.2 是首个支持自定义 SCEP CA 证书安装与移除的正式版本。从源码可见该文件还承担了签名配置的加载逻辑keystore.properties存在时release签名配置会从其中读取storeFile、storePassword、keyAlias、keyPassword见 android/app/build.gradle.kts这也是后续 staging / production 双环境签名能够切换的基础。四、生成并更新 CHANGELOG在仓库根目录执行make changelog-android version1.X.X该 Makefile 目标Makefile实际完成三件事以## Android agent 1.X.X (日期)格式生成带日期的版本标题收集 android/changes/ 目录下所有变更文件过滤掉.keep将其中的非空行整理后^-规范化为*追加到标题下方把新生成的版本块拼接到 android/CHANGELOG.md 顶部并用git rm把已处理过的android/changes/条目文件从暂存区删除。生成后需要人工 Review 一遍结果把未被android/changes/目录覆盖的补充条目手动加进去例如涉及服务器端能力依赖的变更说明可参考历史条目中Requires Fleet server v4.80 or higher这类标注。五、提交并推送 RC 分支git add android/app/build.gradle.kts android/CHANGELOG.md android/changes/ git commit -m Prepare release v1.X.X git push origin rc-minor-fleetd-android-v1.X.X注意这里提交的范围刻意收窄为与发布相关的三个路径避免把无关改动混入 RC。六、staging 环境试发布关键验证环节正式发布前必须先在 staging 应用com.fleetdm.agent.stage上完整走一遍构建 → 上传 → 审核 → 设备验证确保新版本在真实设备与 Fleet 服务器上可用。原文档android/RELEASE.md将其列为第 5 步并给出以下前置条件。6.1 前置条件一台运行中的 Fleet 服务器且配置了 staging Agent 的包名与签名指纹export FLEET_MDM_ANDROID_AGENT_PACKAGEcom.fleetdm.agent.stage export FLEET_MDM_ANDROID_AGENT_SIGNING_SHA256uxe8ynMUe36j7avGtA2F4wHeAgnQn6UbPP7D3AbQQ这两个环境变量对应 Fleet 服务器配置中的mdm.android_agent.package与mdm.android_agent.signing_sha256详见 android/README.md 中的Deploying via Android MDM (development)一节signing_sha256是上传 keystore 证书指纹的 Base64 编码用于服务器校验下发的 Agent 包确实由 Fleet 签名。在 Google Play Console 中使用 Google Play Admin 凭据把你的 Android MDM 组织 ID 添加到 Test and Release → Advanced Settings → Managed Google Play 的允许组织列表中从上一任发布者处获取 staging 签名密钥。6.2 构建带签名的 staging 包先把applicationId临时改为 staging 应用 IDdefaultConfig { applicationId com.fleetdm.agent.stage }同时确保 android/ 目录下的keystore.properties配置的是 staging 签名密钥storeFile./qa-keystore.jks storePasswordget-this-from-a-previous-releaser keyAliasfleet-android keyPasswordget-this-from-a-previous-releaser然后构建签名 AAB./gradlew clean bundleRelease产物路径app/build/outputs/bundle/release/app-release.aab。从构建脚本可以印证签名链路bundleRelease会走releasebuildType而该 buildType 只有在keystore.properties存在时才挂载signingConfig否则产出未签名包android/app/build.gradle.kts因此clean构建前务必确认keystore.properties已就位。6.3 上传到 Google Play进入 Google Play Console选择 Fleet staging 应用com.fleetdm.agent.stage进入 Test and release → Production选择 Create new release上传签名后的.aab文件在页面底部填写发布说明.aab处理完成后依次选择 Next → Save并在弹出的弹窗中选择Go to overview页面会跳转到Publishing overview在此选择Send 1 change for review等待 Google 审核通过审核结果会发送到 Play Console 账号邮箱。6.4 验证发布对照该版本的测试计划testplans在真实设备上逐项跑通重点确认Agent 在设备上正常安装并出现在 Work profile、与 Fleet 服务器完成注册enrollment、证书模板按预期签发/安装/续期。七、正式发布到生产环境staging 验证通过后进入生产发布。原文档android/RELEASE.md特别注明只有特定人员拥有发布流程的访问权限这属于组织层面的权限管控措施。7.1 构建生产签名包把 android/app/build.gradle.kts 中的applicationId恢复为com.fleetdm.agent并确保keystore.properties中配置的是生产签名密钥/密码./gradlew clean bundleRelease产物路径同样为app/build/outputs/bundle/release/app-release.aab。7.2 上传到 Google Play生产应用进入 Google Play Console选择 Fleet 应用com.fleetdm.agent进入 Release → Production上传签名后的.aab文件在页面底部填写发布说明release notes选择 Save然后在弹出的弹窗中选择Go to overview在Publishing overview页面选择Sent to review等待 Google 审核通过审核结果发送到主 Play Console 账号邮箱。staging 与生产两个应用的包名、签名密钥、Play Console 账号彼此隔离这保证了任何一次试发布事故都不会污染线上渠道。八、给发布打 Git 标签发布上传完成后为 RC 分支打上版本标签形成可追溯的发布快照git checkout rc-minor-fleetd-android-v1.X.X git tag fleetd-android-v1.X.X git push origin rc-minor-fleetd-android-v1.X.X标签名规范为fleetd-android-v版本号与 Fleet 其他组件如 fleetd-chrome的标签命名风格一致。九、把版本升级与 CHANGELOG 合回 main发布后main分支也需要同步版本号与 CHANGELOG但要避免把 RC 分支上无关的中间提交带回去。原文档android/RELEASE.md给出的做法是文件级 checkout 定向删除变更条目git checkout main git pull origin main git checkout -b bring-fleetd-android-v1.X.X-to-main git checkout rc-minor-fleetd-android-v1.X.X -- android/app/build.gradle.kts android/CHANGELOG.md git diff --name-only --diff-filterD main...rc-minor-fleetd-android-v1.X.X -- android/changes/ | xargs git rm --ignore-unmatch git commit -m Update version and CHANGELOG for fleetd-android-v1.X.X git push origin bring-fleetd-android-v1.X.X-to-main这条命令链的语义git checkout rc分支 -- 文件把 RC 分支上的build.gradle.kts与CHANGELOG.md精确覆盖到当前分支git diff --name-only --diff-filterD main...rc-minor-fleetd-android-v1.X.X -- android/changes/找出 RC 分支相对main已删除的android/changes/条目即第 4 步make changelog-android已经git rm掉的那批再用git rm --ignore-unmatch在bring-*分支上同步删除这样既带回了版本号与 CHANGELOG 更新又只删除 RC 已处理过的变更条目保留 RC 分支切出之后main上新增的条目避免误删后续变更。最后为该分支开 PR 合入main即可。对应机制可从 Makefile 的changelog-android目标印证git rm android/changes/*正是删除已处理条目这一步的源头。十、收尾里程碑发布完成后的清理工作围绕 GitHub Issues 与里程碑展开完整清单可参考原文档 android/RELEASE.md 第 9 节核心动作如下把相关 story 移动到 intake outtake 面板对fleetd-android-v1.X.X里程碑中带story标签的 issue加上:product标签并移除:release标签使其进入产品设计 intake outtake 面板把相关 story 移动到 Confirm and celebrate在该面板按里程碑筛选把所有 story 移到 Confirm and celebrate 列由产品团队通过 confirm and celebrate 仪式关闭带engineering-initiated标签的工程发起 story 可直接关闭无需该仪式关闭相关 bug关闭里程碑内剩余的非 storyissue关闭 GitHub 里程碑在 GitHub milestones 页面关闭fleetd-android-v1.X.X通告在#help-engineering频道宣布里程碑已关闭。十一、发布相关的工程要点小结双环境隔离stagingcom.fleetdm.agent.stage与生产com.fleetdm.agent使用不同的applicationId与签名密钥通过 android/app/build.gradle.kts 中的defaultConfig.applicationId与keystore.properties切换签名指纹FLEET_MDM_ANDROID_AGENT_SIGNING_SHA256对应 keystore 证书 SHA256 指纹的 Base64 形式可用keytool -list -v -keystore keystore.jks -alias fleet-android获取后经echo SHA256 | tr -d : | xxd -r -p | base64转换详见 android/README.md 的 Getting the SHA256 fingerprintCHANGELOG 自动化make changelog-android version1.X.X从android/changes/聚合变更并删除已处理条目Makefile合回 main 的精准性采用文件级 checkout 与定向git rm的方式避免把 RC 上的无关改动或误删main新条目Agent 的自动化运行特性发布后 Agent 无需用户干预即可工作——安装时由 Android Device Policy 授予COMPANION_APP角色触发 RoleNotificationReceiverService.kt开机时由 BootReceiver.kt 响应ACTION_BOOT_COMPLETED其后 AgentApplication.kt 通过 WorkManager 每 15 分钟周期性地执行证书注册任务PeriodicWorkRequestBuilder(15, TimeUnit.MINUTES)并读取enroll_secret、server_url、host_uuid等托管配置schema 见 app_restrictions.xml完成与 Fleet 服务器的注册。这意味着发布验证时只需在设备上观察 Agent 是否自动完成注册与证书流程即可。按照上述九个阶段执行即可完成一次 Fleet Android Agent 从开发分支到 Google Play 生产环境的完整发布整个过程在仓库内留下版本号、CHANGELOG、Git 标签与里程碑四重可追溯记录。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考