web-dev-qa-db-fra.com

Quand ADT définit-il BuildConfig.DEBUG sur false?

Dans la dernière version de ADT (r17), une constante générée a été ajoutée BuildConfig.DEBUG qui est défini en fonction du type de construction. Le problème que j'ai, c'est qu'il n'est jamais défini sur false, je m'attendais à ce que cela change en faisant "Outils Android -> Exporter le package d'application signé", mais ce n'est pas le cas pour moi.

Alors, comment puis-je changer le type de construction?

Ajout d'une fonctionnalité qui vous permet d'exécuter du code uniquement en mode débogage. Les constructions génèrent maintenant une classe appelée BuildConfig contenant une constante DEBUG définie automatiquement en fonction de votre type de construction. Vous pouvez vérifier la constante (BuildConfig.DEBUG) dans votre code pour exécuter des fonctions de débogage uniquement.

androideclipseadt
107
smith324

Actuellement, vous pouvez obtenir le comportement correct en désactivant "Générer automatiquement", en nettoyant le projet, puis en exportant via "Outils Android -> Exporter le package de l'application signée". Lorsque vous exécutez l'application BuildConfig.DEBUG devrait être faux.

56
smith324

Avec Eclipse, je désactive toujours l'option "Construire automatiquement" avant d'exporter l'application en version. Ensuite, je nettoie le projet et exporte. Sinon, la compilation commence en mode débogage, puis la valeur de BuildConfig.DEBUG peut être fausse.

Avec Android Studio, j'ajoute simplement ma propre variable personnalisée dans le fichier build.gradle:

buildTypes {
    debug {
        buildConfigField "Boolean", "DEBUG_MODE", "true"
    }
    release {
        buildConfigField "Boolean", "DEBUG_MODE", "false"
    }
}

Lorsque je construis le projet, le BuildConfig.Java est généré comme suit:

public final class BuildConfig {
  // Fields from build type: debug
  public static final Boolean DEBUG_MODE = true;
}

Ensuite, dans mon code, je peux utiliser:

if (BuildConfig.DEBUG_MODE) {
    // do something
}

Je recommande de nettoyer après avoir changé le build de debug/release.

36
Arnaud SmartFun

Cela ne fonctionne pas correctement:

Problème 2794 : BuildConfig.DEBUG est "true" pour le package d'application exporté

Il est décevant qu'ils publient parfois des fonctionnalités buggy.

33
Randy Sugianto 'Yuku'

Cela fonctionne, mais notez que le fichier de code ne change jamais, même lors de l'exportation du fichier signé. L'exportation process modifie la valeur de cette variable en false, ce qui peut vous donner une fausse impression que cela ne fonctionne pas. J'ai testé cela avec des instructions de journalisation comme

if (com.mypackage.BuildConfig.DEBUG)
            Log.d(TAG, location.getProvider() + " location changed");

Lors du test, mes instructions de journal ne produisent plus de sortie.

10
pbhowmick

Recherchez imports, parfois BuildConfig est importé de toute classe de bibliothèque par inadvertance. Par exemple:

import io.fabric.sdk.Android.BuildConfig;

Dans ce cas BuildConfig.DEBUG retournera toujours false ;

import com.yourpackagename.BuildConfig;

Dans ce cas BuildConfig.DEBUG renverra votre variante de construction réelle .

p.s Je viens de copier celui de ma réponse ici: BuildConfig.DEBUG toujours faux lors de la construction de projets de bibliothèque avec gradle

8
Gent Berani

De Préparation à la sortie :

Désactiver la journalisation et le débogage

Assurez-vous de désactiver la journalisation et de désactiver l'option de débogage avant de créer votre application pour la publication. Vous pouvez désactiver la journalisation en supprimant les appels aux méthodes de journalisation dans vos fichiers source. Vous pouvez désactiver le débogage en supprimant l'attribut Android: debuggable de la balise dans votre fichier manifeste, ou en définissant l'attribut Android: debuggable sur false dans votre fichier manifeste. Supprimez également tous les fichiers journaux ou les fichiers de test statiques créés dans votre projet.

En outre, vous devez supprimer tous les appels de suivi de débogage que vous avez ajoutés à votre code, tels que les appels de méthode startMethodTracing () et stopMethodTracing ().

Plus d'informations suivent le lien.

5
peter

La solution pour moi:

  1. Projet -> Construire automatiquement
  2. Projet -> Nettoyer
  3. Projet -> Construire
  4. Exportation de projet Android application

C'est du travail en r20

5
e.shishkin

Je souhaiterais proposer une solution de contournement simple si vous utilisez proguard lors de l'exportation APK.

Proguard fournit un moyen de supprimer les appels de fonctions spécifiques en mode de libération. Tous les appels pour les journaux de débogage peuvent être supprimés avec le réglage suivant dans proguard-project.txt.

# Remove debug logs
-assumenosideeffects class Android.util.Log {
    public static *** d(...);
    public static *** v(...);
}

Et réglage de l'optimisation dans project.properties.

proguard.config=${sdk.dir}/tools/proguard/proguard-Android-optimize.txt:proguard-project.txt

Avec cela, vous n'avez pas à vous soucier des calculs de chaîne inutiles transmis au journal de débogage sur lequel @Jeremyfa a pointé. Les calculs sont simplement supprimés dans la version release.

La solution de contournement pour BuildConfig.DEBUG utilise donc la même fonctionnalité de proguard que celle qui suit.

public class DebugConfig {

    private static boolean debug = false;

    static {
        setDebug(); // This line will be removed by proguard in release.
    }

    private static void setDebug() {
        debug = true;
    }

    public static boolean isDebug() {
        return debug;
    }
}

Et suivant la mise en proguard-project.txt.

-assumenosideeffects class com.neofect.rapael.client.DebugConfig {
    private static *** setDebug();
}

Je préférerais utiliser ceci pour désactiver le Build Automatically Option, car elle ne dépend pas du paramètre individuel du générateur IDE), mais est conservée sous la forme d'un fichier validé partagé par les développeurs.

3
neo.kim

Ne fonctionne pas correctement dans la mesure où j'ai compris ( numéro Android 22241 )

J'ai eu quelques problèmes avec un projet (en travaillant avec Eclipse), cette constante n'était pas définie sur true lors de l'exportation d'un fichier APK signé de mon projet :(

J'aimerais entendre que cela fonctionne bien

1
Vincent Mimoun-Prat

un bon moyen est de créer votre propre classe:

public class Log {

public static void d(String message) {
    if (BuildConfig.DEBUG)
        Android.util.Log.d(
            "[" + (new Exception().getStackTrace()[1].getClassName()) + "]",
            "{" + (new Exception().getStackTrace()[1].getMethodName()) + "} "
            + message
        );
}

}
1
Bouchehboun Saad

J'ai constaté un comportement étrange lié au fait que les valeurs dans BuildConfig sont définies sur leurs valeurs finales. Cela peut avoir quelque chose à voir avec votre problème.

L'explication simple est que les valeurs par défaut sont définies initialement avant l'exécution de Proguard, puis une fois que Proguard est exécuté, le fichier BuildConfig est régénéré avec les valeurs appropriées. Cependant, Proguard a déjà optimisé votre code à ce stade et vous avez des problèmes.

Voici un bug que j'ai créé contre Gradle. https://code.google.com/p/Android/issues/detail?id=182449

0
TALE