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


110

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

Alors, comment changer le type de build?

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


2
BuildConfig.java est généré automatiquement par les outils de construction Android et est placé dans le dossier gen. L'APK signé doit avoir BuildConfig.DEBUG = false. Cela ne devrait pas être un problème pour vous. Vous ne devriez pas avoir à toucher manuellement ce fichier ...
IgorGanapolsky

1
Si vous utilisez gradle pour libérer, cet indicateur est fiable à 100%. Ainsi, lorsque vous effectuez un ./gradlew assembleDebug, il est vrai et lorsque vous exécutez assembleRelease, il est faux.
slott

Réponses:


56

Actuellement, vous pouvez obtenir le comportement correct en désactivant "Construire automatiquement", en nettoyant le projet puis en l'exportant via "Outils Android -> Exporter le package d'application signé". Lorsque vous exécutez l'application BuildConfig.DEBUGdoit être false.


cassé aussi. Ce qui a pour conséquence d'afficher tous les messages Log.d qui devraient être omis par cet indicateur. ps. où déposer un rapport de bogue?
tomi

le mien est toujours faux, même lors du débogage
behelit

39

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

Avec Android Studio , j'ajoute simplement ma propre variable personnalisée dans le 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 basculé la version debug / release.


1
Cette solution est la meilleure si vous utilisez proguard car elle générera une constante avec une valeur littérale, ainsi votre code de débogage sera complètement supprimé du binaire en mode version.
Victor Laerte le

33

Cela ne fonctionne pas correctement:

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

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


9
Veuillez vous rendre sur le lien vers le problème mentionné ci-dessus et mettez-le en étoile si vous souhaitez que cela soit corrigé.
Guy

11

Cela fonctionne, mais notez que le fichier de code ne change jamais, même lors de l'exportation du fichier signé. Le processus d' exportation change la valeur de cette variable en false, ce qui peut vous donner la fausse impression qu'elle 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 des tests, mes instructions Log ne produisent plus de sortie.


1
Qu'as-tu fait exactement?
pbhowmick

2
J'ai changé les instances de BuildConfig.DEBUG en com.mypackage.BuildConfig.DEBUG, puis j'ai relancé l'application ... et elle retournait toujours vrai tout le temps. J'ai peut-être mal compris votre suggestion.
Chris Rae

1
Ce que je dis, c'est que le code ne changera PAS. Cependant, com.mypackage.BuildConfig.DEBUG sera défini sur False après la compilation. Essayez une instruction de journalisation de test comme ci-dessus (choisissez une chaîne arbitraire à journaliser), effectuez l'exportation, puis exécutez-la. Vérifiez si adb affiche l'instruction de journalisation. Je suis prêt à parier que adb ne rapportera pas cette déclaration de journalisation, ce qui signifie que DEUBUG a été défini sur false.
pbhowmick

1
Je ne suis pas sûr de savoir ce que vous voulez dire à propos de "le code" ... cependant, je dirai que faire un nettoyage avant d'exporter l'APK (comme suggéré dans la réponse acceptée) a rendu BuildConfig.DEBUG et com.mypackage.BuildConfig .DEBUG rapporte faux comme prévu.
Chris Rae

Tu l'as eu. C'est le comportement attendu.
pbhowmick

10

Vérifiez imports, parfois BuildConfig est importé de n'importe quelle classe de bibliothèque sans le vouloir. 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 .

ps Je viens de copier celui-ci de ma réponse ici: BuildConfig.DEBUG toujours false lors de la construction de projets de bibliothèque avec gradle


1
Ouais, pour moi, il a été importé accidentellement android.support.compat. Je suppose que c'est une autre raison pour définir simplement votre propre champ avec un nom différent.
arekolek

5

De Préparation à la sortie :

Désactivez 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 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 sont en suivant le lien.


1
Je pensais que ce processus se produit maintenant automatiquement au moment de la construction: developer.android.com/tools/sdk/tools-notes.html
IgorGanapolsky

Provoque une erreur de compilation: «Évitez de coder en dur le mode de débogage; le laisser de côté permet aux versions de débogage et de publication d'en attribuer automatiquement une »
Nikita Bosik

5

La solution pour moi:

  1. Projet -> Construire automatiquement
  2. Projet -> Nettoyer
  3. Projet -> Construire
  4. Application Android Project Export

C'est du travail en r20


1
Cela a fonctionné pour moi tout à l'heure (en utilisant le dernier ADT je ​​suppose). Peut-être que le nettoyage l'a corrigé, pas sûr.
Jonny

3

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

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

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

Et l'optimisation s'installe project.properties.

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

Avec cela, vous n'avez pas besoin de vous soucier de tout calcul String inutile passant au journal de débogage vers lequel @Jeremyfa a pointé. Les calculs sont simplement supprimés dans la version de version.

Ainsi, la solution de contournement pour BuildConfig.DEBUG utilise la même fonctionnalité de proguard comme 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 après l'installation proguard-project.txt.

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

Je préférerais l'utiliser à la désactivation de l' Build Automaticallyoption, car cela ne dépend pas du paramètre IDE individuel du constructeur, mais est conservé en tant que fichier engagé qui est partagé entre les développeurs.


1

Pour autant que je sache, ne fonctionne pas correctement ( problème Android 22241 )

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

J'adorerais entendre que ça marche


1
Cela aurait dû être corrigé dans r17, il est marqué comme tel dans le bug tracker.
smith324

1
En fait, les bibliothèques ne sont pas compilées en mode version dans ADT lors de l'exportation (fonctionne dans Ant). J'ai mis à jour code.google.com/p/android/issues/detail?id=27940
Xavier Ducrohet

1
@Xav merci de l'avoir examiné, je vais arrêter de spammer, promis maintenant. C'était en fait le projet principal avec lequel j'avais des problèmes (je n'ai pas regardé la bibliothèque dépendante). Si je peux créer un cas de test concret, je le posterai dans le suivi des bogues sous le même problème.
smith324

1

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
        );
}

}

12
Le problème avec cette méthode est que, lorsque DEBUG est faux, java calculera toujours chaque chaîne pour la transmettre à votre classe personnalisée. Le if (DEBUG) Log.d (...) est moins élégant mais plus efficace.
Jeremyfa

0

J'ai vu un comportement étrange lié au moment où les valeurs de 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 après l'exécution de Proguard, 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 rencontrez des problèmes.

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.