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

Dans la dernière version d’ADT (r17), une constante générée a été ajoutée BuildConfig.DEBUG qui est définie en fonction du type de génération. Le problème que j’ai est qu’il n’est jamais mis à false, je m’attendais à ce qu’il change lorsque je fais “Android Tools -> Exporter le package d’application signée” 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 builds génèrent maintenant une classe appelée BuildConfig contenant une constante DEBUG définie automatiquement en fonction de votre type de build. Vous pouvez vérifier la constante (BuildConfig.DEBUG) dans votre code pour exécuter les fonctions de débogage uniquement

Actuellement, vous pouvez obtenir le comportement correct en désactivant “Générer automatiquement”, en nettoyant le projet et en l’exportant via “Outils Android -> Exporter le package d’application signée”. Lorsque vous exécutez l’application, BuildConfig.DEBUG doit être false.

Avec Eclipse , je désactive toujours l’option “Générer automatiquement” avant d’exporter l’application dans la version. Ensuite, je nettoie le projet et exporte. Sinon, il commence à comstackr en mode débogage, puis 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 changé la version de debug / release.

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 buggées.

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 donner l’impression fausse qu’elle ne fonctionne pas. J’ai testé cela avec des déclarations de journalisation comme

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

Lors du test, mes instructions Log ne génèrent plus aucune sortie.

Vérifiez les imports , parfois BuildConfig est importé de toute classe de bibliothèque involontairement. Par exemple:

 import io.fabric.sdk.android.BuildConfig; 

Dans ce cas, BuildConfig.DEBUG renverra 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 faux lors de la construction de projets de bibliothèque avec gradle

De la préparation à la publication :

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 publication. Vous pouvez désactiver la journalisation en supprimant les appels aux méthodes Log de vos fichiers sources. Vous pouvez désactiver le débogage en supprimant l’atsortingbut android: debuggable de la balise dans votre fichier manifeste ou en définissant l’atsortingbut 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 trace 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.

La solution pour moi:

  1. Projet -> Construire automatiquement
  2. Projet -> Nettoyer
  3. Projet -> Construire
  4. Application d’exportation de projet Android

C’est du travail en R20

Je voudrais proposer une solution simple si vous utilisez proguard pendant l’exportation APK.

Proguard permet de supprimer les appels à des fonctions spécifiques en mode de libération. Tous les appels pour les journaux de débogage peuvent être supprimés avec les parameters suivants dans proguard-project.txt .

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

Et paramètre d’optimisation dans project.properties .

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

Avec ceci, vous n’avez pas besoin de vous soucier du calcul de chaîne inutile passé au journal de débogage auquel @Jeremyfa a fait référence. Les calculs sont simplement supprimés dans la version release.

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 configuration suivante dans proguard-project.txt .

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

Je préférerais utiliser cette option pour désactiver l’option Build Automatically , car cela ne dépend pas du paramètre IDE individuel du générateur, mais est maintenu en tant que fichier engagé partagé par les développeurs.

Ne fonctionne pas correctement pour autant que j’ai compris ( numéro Android 22241 )

J’ai eu des problèmes avec un projet (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’adorerais entendre ça marche

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

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

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. 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 avez des problèmes.

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