Azure Pipelines GooglePlayRelease@4报错：版本号1已使用，实际为2343

问题分析 #

本地构建的AAB版本号为2343，但通过Azure Pipelines上传至Google Play时，被提示版本号1已被使用。核心原因大概率是Pipeline构建环境中Git提交次数获取失败，导致Gradle生成的versionCode变为1，而非预期的2343。

可能的原因 #

Azure Pipelines默认采用**浅克隆（shallow clone）**拉取代码，仅获取最近1次提交的历史记录。这会使git rev-list --count HEAD命令只能返回1，最终生成的versionCode为1。

解决方案 #

1. 修改Git checkout配置，获取完整提交历史 #

在Pipeline的checkout任务中设置fetchDepth: 0，让构建代理拉取完整的Git提交记录，确保git rev-list --count HEAD能计算出正确的总提交数：

- checkout: self
  fetchDepth: 0  # 拉取完整仓库历史

2. 验证构建后的AAB版本号 #

在Pipeline中添加脚本任务，构建完成后检查AAB的versionCode，确认是否正确生成：

- script: |
    # 若代理环境无bundletool，先执行安装：wget https://github.com/google/bundletool/releases/latest/download/bundletool-all.jar
    java -jar bundletool-all.jar dump manifest --bundle $(Agent.BuildDirectory)/s/android/app/build/outputs/bundle/productionRelease/app-production-release.aab | grep versionCode
  displayName: 'Verify AAB versionCode'

如果输出的versionCode是1，说明构建阶段就出现了问题；如果是2343，再排查签名或GooglePlayRelease任务的配置。

3. 检查Gradle构建日志 #

在Pipeline的Gradle构建任务中添加--info参数，查看构建过程中versionCode的生成日志，确认计算是否正确：

- task: Gradle@2
  inputs:
    workingDirectory: 'android'
    gradleWrapperFile: 'android/gradlew'
    tasks: 'bundleProductionRelease'
    options: '--info'  # 输出详细构建日志

在日志中搜索versionCode，确认生成的值是否为2343。

4. 确认构建变体正确性 #

检查Pipeline中Gradle任务是否指定了正确的构建变体（bundleProductionRelease），避免误构建其他变体导致版本号异常。

额外排查点 #

• AndroidSigning@3任务仅负责签名，不会修改AAB的versionCode，无需怀疑该环节。
• 确认Google Play后台的应用ID与Pipeline中applicationId一致，避免上传至错误应用。

内容的提问来源于stack exchange，提问作者MikkelT