web-dev-qa-db-fra.com

Buildconfig.version_code est manquant après la mise à jour de 'com.android.tools.build:guild:4.1.0'

J'ai une application multiculmulaire et pour une raison quelconque, le champ généré par la version_code a disparu de tous les modules, à l'exception de la racine, je l'ai testé sur un projet de plus et cela se comporte de même. À l'heure actuelle, j'ai simplement rétrogradé à 4.0.1, mais c'est juste une solution de contournement.

J'ai besoin de restaurer buildconfig.version_code dans tous les modules à l'aide d'outils de gradle 4.1.0

Apprécierait toute aide.

parfaulonConfig Exemple:

buildFeatures {
    buildConfig = true
}

defaultConfig {
    minSdkVersion global["androidMinSdkVersion"]
    targetSdkVersion global["androidTargetSdkVersion"]

    versionCode global["versionString"]

    javaCompileOptions {
        annotationProcessorOptions {
            includeCompileClasspath true
        }
    }
}

Voici le code BuildConfig sur 4.0.1

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String APPLICATION_ID = "app";
  public static final String BUILD_TYPE = "debug";
  public static final String FLAVOR = "flavour";
  public static final int VERSION_CODE = 107;
  public static final String VERSION_NAME = "6.0.0";
  // Field from build type: debug
  public static final String AMQP_URL = "url";
  // Field from build type: debug
  public static final String API_VERSION_SUFFIX = "V_04_04_09";
  // Field from build type: debug
  public static final String BASE_URL = "url";
  // Field from product flavor: flavour
  public static final String BUILD_FLAVOR = "flavour";
  // Field from build type: debug
  public static final int DB_VERSION = 53;
}

Et voici 4.1.0

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String APPLICATION_ID = "app";
  public static final String BUILD_TYPE = "debug";
  public static final String FLAVOR = "flavour";
  public static final String VERSION_NAME = "6.0.0";
  // Field from build type: debug
  public static final String AMQP_URL = "url";
  // Field from build type: debug
  public static final String API_VERSION_SUFFIX = "V_04_04_09";
  // Field from build type: debug
  public static final String BASE_URL = "url";
  // Field from product flavor: flavour
  public static final String BUILD_FLAVOR = "flavour";
  // Field from build type: debug
  public static final int DB_VERSION = 53;
}
androidgradleandroid-gradle-pluginbuild.gradle
33
Void

Vous pouvez utiliser les autres réponses ici comme solution de contournement, mais cette réponse est simplement de vous informer de la réponse officielle des personnes travaillant sur le bogue. Cela ne sera pas fixé car il s'agit d'un comportement prévu.

Voici ce que disent les googles ingénieurs:

Statut: ne réparera pas (comportement prévu) salut tout,

Oui, nous devrions avoir déprécié cela en premier. Comme cela s'est passé (il y a plusieurs mois), nous avons mis en place de meilleures politiques d'amortissement/de suppression des propriétés. Cela s'est produit un peu de retard pour 4.1 cependant, et cette question particulière est tombée à travers les fissures, nous n'avions donc pas eu la chance de décider de revenir sur ce changement (et nous avons même manqué de mettre ce changement dans les notes de publication au début). Nous nous excusons pour cela.

Une partie de la motivation derrière cela devait réduire/éliminer la confusion autour de 2 points:

Les utilisateurs accédent aux champs BuildConfig mais ne les définissent pas dans la DSL. Cela serait définitivement brisé et ne ferait pas ce que l'on pourrait s'attendre (c.-à-d. Celles-ci sont des valeurs statiques et ne refléteront pas comme par magie la version de l'application, la bibliothèque est intégrée) La bibliothèque androidmanifest.xml contient les valeurs définies dans la DSL, Mais ces valeurs sont complètement ignorées par la ou les applications consommatrices lors de la fusion manifeste (elles sont également remplacées) si vous souhaitez continuer à injecter les valeurs d'un lieu commun dans tous les champs BuildConfig de votre bibliothèque, vous pouvez continuer à le faire manuellement avec vos propres champs personnalisés. Ces champs n'existeront que si vous les définissez via le DSL (empêchant donc le problème n ° 1 ci-dessus) et n'aura aucune incidence sur le manifeste de la bibliothèque (problème n ° 2 ci-dessus).

Toutefois, si vous avez une grande configuration avec de nombreux projets de bibliothèque, ce modèle générera beaucoup de doublons. Il serait plus logique d'avoir un seul module qui génère une classe similaire et dispose de tous vos projets de bibliothèque (ou au moins ceux qui ont besoin d'informations) en dépendent.

2
Vedprakash Wagh

Était incapable de trouver une solution propre, alors ajouté une solution de contournement:

buildConfigField "int", "VERSION_CODE1", String.valueOf(global["versionString"])
1
Void