在build.gradle中添加versionCode和versionName字段，如下所示：

buildConfigField("long", "VERSION_CODE", "${defaultConfig.versionCode}")
        buildConfigField("String","VERSION_NAME","\"${defaultConfig.versionName}\"")

//

defaultConfig {
            minSdkVersion 19
            targetSdkVersion 31
            versionCode 140
            versionName "1.4.54.31"
            **buildConfigField 'int', 'VERSION_CODE', "${versionCode}"
            buildConfigField 'String', 'VERSION_NAME', "\"${versionName}\""**
    
            testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
            consumerProguardFiles 'flyy-consumer-rules.pro'
            vectorDrawables.useSupportLibrary = true
        }

Android Studio 4.1、库模块和VERSION_CODE Android Studio 4.1 --或者更准确地说，是Android Gradle插件的4.1.0版--有一项重大变更：它不再向BuildConfig添加版本代码（有时也添加版本名称）。
这个问题最初是在6月份的Canary 4中报告的，但是尽管是一个P1问题，它在AS 4.1发布之前并没有得到解决。我是从Stack Overflow那里发现的。而且，因为它在发行说明中提到了，所以这可能不会改变。
如果您创建一个scrap AS 4.1项目，您的应用模块将具有典型的versionCode和versionName属性：

defaultConfig {
    applicationId "com.commonsware.android.myapplication"
    minSdkVersion 21
    targetSdkVersion 30
    versionCode 1
    versionName "1.0"

    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
  }

该模块使用com.android.application插件，并生成一个包含VERSION_CODE和VERSION_NAME的BuildConfig：

public final class BuildConfig {
      public static final boolean DEBUG = Boolean.parseBoolean("true");
      public static final String APPLICATION_ID = "com.commonsware.android.myapplication";
      public static final String BUILD_TYPE = "debug";
      public static final int VERSION_CODE = 1;
      public static final String VERSION_NAME = "1.0";
    }

如果您随后将库模块添加到同一项目中，它也将具有相同得versionCode与versionName行...但它们不会反映在模块得BuildConfig中：

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String LIBRARY_PACKAGE_NAME = "com.commonsware.android.mylibrary";
  public static final String BUILD_TYPE = "debug";
}

我有点惊讶的是，票没有关闭为“工作的意图”，因为这个变化是故意的
这样做是有目的的，因为有一个版本的库（存在于清单文件或代码中）对Android中的库没有意义。2只有应用程序有一个Android版本。3更新：在我发布这篇文章几个小时后，它确实被关闭为“有意行为”。我怀疑是Xavier Ducrohet的某个人发布了一个扩展的解释，解释了这一切是如何发生的。
发行说明建议将来从Gradle DSL中删除versionCode和versionName。
对我有效的方法是根据以下问题注解手动声明它们：

defaultConfig {
    minSdkVersion 21
    targetSdkVersion 30
    versionCode 1
    versionName "1.0"
    buildConfigField 'int', 'VERSION_CODE', "1"
    buildConfigField 'String', 'VERSION_NAME', "\"1.0\""

    testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    consumerProguardFiles "consumer-rules.pro"
  }

在我的例子中，我只是硬编码了这些值，但是您可以安排从某个公共位置提取它们。
请注意，这里可能会有不同的行为。在堆栈溢出问题中，SO用户Void报告了与我所看到的两个不同之处：
已生成版本名称，但未生成版本代码
对VERSION_CODE使用buildConfigField将不起作用，但使用唯一名称将
在光测试中，我无法重现这些发现，但要为症状的一些变化做好准备。
如果你选择了buildConfigField，最安全的做法是不要使用VERSION_CODE和VERSION_NAME，而是使用你自己的唯一名称，就像Void那样。基本上，将VERSION_CODE和VERSION_NAME视为Google管理的名称空间的一部分，并假设Google可能会对它们造成干扰。如果你使用你自己的名称，幸运的话，它们将不会受到Android Gradle插件未来更改的影响。
更新：在前面提到的扩展解释中，谷歌回应了这一建议：请使用您自己的自定义字段。

***如果您想在您的库中使用它，您可能会有机会为旧版本和新版本的构建工具发生冲突，您必须添加检查或创建唯一的名称，以便在www.example.com文件中生成BuildConfig.java，如下所示：

defaultConfig {
            minSdkVersion 19
            targetSdkVersion 31
            versionCode 140
            versionName "1.4.54.31"
            **buildConfigField 'int', 'VERSION_CODE_1', "${versionCode}"
            buildConfigField 'String', 'VERSION_NAME_1', "\"${versionName}\""**

            testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
            consumerProguardFiles 'flyy-consumer-rules.pro'
            vectorDrawables.useSupportLibrary = true
        }

并使用新的BuildConfig.VERSION_CODE_1，名称代替旧名称，这样可以避免生成多个名称和代码并避免冲突***