When does ADT set BuildConfig.DEBUG to false?

AndroidEclipseAdt

Android Problem Overview


In the newest version of ADT (r17) a generated constant was added BuildConfig.DEBUG that is set according to the build type. The problem I have is that it is never set to false, I expected it to change when doing "Android Tools -> Export Signed Application Package" but it hasn't for me.

So how do I change the build type?

> Added a feature that allows you to run some code only in debug mode. > Builds now generate a class called BuildConfig containing a DEBUG > constant that is automatically set according to your build type. You > can check the (BuildConfig.DEBUG) constant in your code to run > debug-only functions

Android Solutions


Solution 1 - Android

Currently you can get the correct behavior by disabling "Build Automatically", cleaning the project and then export via "Android Tools -> Export Signed Application Package". When you run the application BuildConfig.DEBUG should be false.

Solution 2 - Android

With Eclipse, I always disable "Build Automatically" option before Exporting the app in release. Then I clean the project and export. Otherwise it starts compiling in debug mode, and then the value of BuildConfig.DEBUG may be wrong.

With Android Studio, I simply add my own custom variable in the build.gradle:

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

When I build the project, the BuildConfig.java is generated as follows:

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

Then in my code I can use:

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

I recommand to clean after switching debug/release build.

Solution 3 - Android

It doesn't work properly:

Issue 27940: BuildConfig.DEBUG is "true" for exported application package

It's disappointing that they sometimes release buggy features.

Solution 4 - Android

Check for imports, sometimes BuildConfig is imported from any class of library unintentionally. For example:

import io.fabric.sdk.android.BuildConfig;

In this case BuildConfig.DEBUG will always return false;

import com.yourpackagename.BuildConfig;

In this case BuildConfig.DEBUG will return your real build variant.

p.s I just copy this one from my answer here:https://stackoverflow.com/questions/20176284/buildconfig-debug-always-false-when-building-library-projects-with-gradle/38373418#38373418

Solution 5 - Android

It does work, but note that the code file never changes, even when exporting the signed file. The export process changes the value of this variable to false, which might give you the false impression that it is not working. I tested this with logging statements like

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

When testing, my Log statements no longer produce any output.

Solution 6 - Android

From Preparing for Release:

> Turn off logging and debugging > > Make sure you deactivate logging and disable the debugging option > before you build your application for release. You can deactivate > logging by removing calls to Log methods in your source files. You can > disable debugging by removing the android:debuggable attribute from > the tag in your manifest file, or by setting the > android:debuggable attribute to false in your manifest file. Also, > remove any log files or static test files that were created in your > project. > > Also, you should remove all Debug tracing calls that you added to your > code, such as startMethodTracing() and stopMethodTracing() method > calls.

More information is following the link.

Solution 7 - Android

The solution for me:

  1. Project -> Build Automatically
  2. Project -> Clean
  3. Project -> Build
  4. Project Export Android application

It's work in r20

Solution 8 - Android

I would want to propose a simple workaround if you use proguard during APK export.

Proguard provides a way to remove calls to specific functions in release mode. Any calls for debugging logs can be removed with following setting in proguard-project.txt.

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

And optimization setting in project.properties.

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

With this, you don't need to concern any unnecessary String computation passing to debug log to which @Jeremyfa pointed. The computations are just removed in release build.

So the workaround for BuildConfig.DEBUG uses the same feature of proguard like following.

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

And following setting in proguard-project.txt.

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

I would prefer using this to disabling the Build Automatically option, because this doesn't depend on the builder's individual IDE setting but is maintained as committed file which are shared among developers.

Solution 9 - Android

Does not work properly as far as I understood (Android issue 22241)

I had some trouble on a project (working with Eclipse), that constant was not set to true when exporting a signed APK of my project :(

Would love to hear it works though

Solution 10 - Android

a good way is creating your own class :

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

}

Solution 11 - Android

I've seen some strange behavior that has to do with when the values in BuildConfig are set to their final values. This may have something to do with your issue.

The simple explanation is that default values are set initially before Proguard is run, then after Proguard runs, the BuildConfig file is regenerated with the proper values. However, Proguard has already optimized your code by this point and you have issues.

Here is a bug I created against Gradle. https://code.google.com/p/android/issues/detail?id=182449

Solution 12 - Android

will you check your app level build.gradle enable debuggable true for release

buildTypes {
    release {
        debuggable true
        }
     }

instead you keep false or comment that line

buildTypes {
    release {
        //debuggable true
        }
     }

now you will get BuildConfig.DEBUG false for release build

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionsmith324View Question on Stackoverflow
Solution 1 - Androidsmith324View Answer on Stackoverflow
Solution 2 - AndroidArnaud SmartFunView Answer on Stackoverflow
Solution 3 - AndroidRandy Sugianto 'Yuku'View Answer on Stackoverflow
Solution 4 - AndroidGentView Answer on Stackoverflow
Solution 5 - AndroidpbhowmickView Answer on Stackoverflow
Solution 6 - AndroidpeterView Answer on Stackoverflow
Solution 7 - Androide.shishkinView Answer on Stackoverflow
Solution 8 - AndroidneokimView Answer on Stackoverflow
Solution 9 - AndroidVincent Mimoun-PratView Answer on Stackoverflow
Solution 10 - AndroidBouchehboun SaadView Answer on Stackoverflow
Solution 11 - AndroidTALEView Answer on Stackoverflow
Solution 12 - AndroidMohd QasimView Answer on Stackoverflow