BuildConfig.DEBUG always false when building library projects with gradle

Question

BuildConfig.DEBUG is not working (= logically set to false) when I run my app in debug mode. I use Gradle to build. I have a library project where I do this check. BuildConfig.java looks like this in the build debug folder:

/** Automatically generated the file. DO NOT MODIFY */
package common.myProject;

public final class BuildConfig {
    public static final boolean DEBUG = Boolean.parseBoolean("true");

}

and in the release folder:

public static final boolean DEBUG = false;

both in the library project and in the application project.

I tried to get around this by checking a variable which is set a class of my project. This class inherits from the library and starts on startup.

<application
        android:name=".MyPrj" ...

This leads to another problem: is that I use my DEBUG variable in a DataBaseProvider which runs before the application class, and it will not run properly due to this bug.

It is a normal behavior. Where is the issue? You have to switch between BuildVariants — Gabriele Mariotti, Nov 26 '13 at 14:15
The BuildConfig file is generated correctly but at run time it is false. I am having the same issue. — jophde, Dec 14 '13 at 02:20

Niklas · Answer 1 · 2017-05-22T15:50:29.950

86

With Android Studio 1.1 and having also the gradle version at 1.1 it is possible:

Library

android {
    publishNonDefault true
}

App

dependencies {
    releaseCompile project(path: ':library', configuration: 'release')
    debugCompile project(path: ':library', configuration: 'debug')
}

Complete documentation can be found here http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication

EDIT:

The issue has just been marked as fixed for the Android Studio Gradle Version 3.0. There you can just use implementation project(path: ':library') and it'll select the correct configuration automatically.

edited May 22 '17 at 15:50

answered Mar 20 '15 at 09:32

Niklas

23,674
33
131
170

5

This way works. But there is a drawback: the ":library:assembleRelease" is called even through you are making the ":app:assembleDebug", and this will result in a longer building time. – Alan Zhiliang Feng May 05 '15 at 13:30
Wow, they finally updated that page *a little bit* and they finally added this feature. – Jared Burrows May 24 '15 at 22:18
Thanks, this did the job! – Aykut Çevik Jun 09 '15 at 14:19
@Konica Longer Gradle build time is a small price to pay - it's convoluted and long times anyway!! This worked wonderfully! Well done! – Radu Jul 03 '15 at 08:14
We need to add the "App" part for each library we use? If so, that's quite annoying... – android developer Apr 10 '16 at 08:31
Nice solution, but if I press "invalidate and restart" on Android Studio it shows me an error: Error:Module ':library' has variant 'release' selected, but the module '':app'' depends on variant 'debug'. – anber Dec 14 '16 at 11:34
This should be the marked correct answer ;) magic happens here hehehe thanks – Santi Iglesias Jul 03 '17 at 09:42
but what if using AAR library – user924 Apr 21 '22 at 14:16

score 53 · Accepted Answer · answered Dec 16 '13 at 18:18

53

This is expected behavior for this.

Library projects only publish their release variants for consumption by other projects or modules.

We're working at fixing this but this is non trivial and requires a significant amount of work.

You can track the issue at https://code.google.com/p/android/issues/detail?id=52962

answered Dec 16 '13 at 18:18

Xavier Ducrohet

28,383
5
88
64

4

Workaround: instaed of BuildConfig.DEBUG create another boolean variable at lib-project's e.g. BuildConfig.RELEASE and link it with application's buildType. Details: https://gist.github.com/almozavr/d59e770d2a6386061fcb – Oleksii Malovanyi Jun 26 '14 at 08:15
The solution provided by DodoEnte in issue tracker works just fine, no need for a work-around. – 3c71 Mar 05 '15 at 21:51
That's no longer the case. There is a proper solution for that. See [my answer](http://stackoverflow.com/a/29163361/1979703) for more information. – Niklas Mar 23 '15 at 22:47
That's true but it has to be done manually, and doesn't scale very well with flavors. We want to make this more automatic in the future. – Xavier Ducrohet Mar 24 '15 at 21:35
@XavierDucrohet This is an unexpected and counter intuitive behavior. You should definitely try to fix it if you can. – Radu Jul 03 '15 at 08:07
What's expected here? It occurs for libraries that are within the project itself, so why can't it be set to true when I run the entire project in debug mode... – android developer Jun 21 '16 at 08:35

score 51 · Answer 3 · answered Jul 14 '16 at 11:49

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.

Jared Rummler · Answer 4 · 2015-02-03T03:16:52.027

This is like Phil's answer except it doesn't need the context:

private static Boolean sDebug;

/**
 * Is {@link BuildConfig#DEBUG} still broken for library projects? If so, use this.</p>
 * 
 * See: https://code.google.com/p/android/issues/detail?id=52962</p>
 * 
 * @return {@code true} if this is a debug build, {@code false} if it is a production build.
 */
public static boolean isDebugBuild() {
    if (sDebug == null) {
        try {
            final Class<?> activityThread = Class.forName("android.app.ActivityThread");
            final Method currentPackage = activityThread.getMethod("currentPackageName");
            final String packageName = (String) currentPackage.invoke(null, (Object[]) null);
            final Class<?> buildConfig = Class.forName(packageName + ".BuildConfig");
            final Field DEBUG = buildConfig.getField("DEBUG");
            DEBUG.setAccessible(true);
            sDebug = DEBUG.getBoolean(null);
        } catch (final Throwable t) {
            final String message = t.getMessage();
            if (message != null && message.contains("BuildConfig")) {
                // Proguard obfuscated build. Most likely a production build.
                sDebug = false;
            } else {
                sDebug = BuildConfig.DEBUG;
            }
        }
    }
    return sDebug;
}

According to this (http://blog.javia.org/static-the-android-application-package/) blog post you should never call the currentPackageName method from any thread other than the activity thread (UI thread). Cool solution though. — Rolf ツ, Mar 04 '16 at 15:08
@Rolfツ Well you could use the application-context instead. — android developer, Jun 21 '16 at 09:35

score 6 · Answer 5 · answered Aug 27 '14 at 01:41

As a workaround, you can use this method, which uses reflection to get the field value from the app (not the library):

/**
 * Gets a field from the project's BuildConfig. This is useful when, for example, flavors
 * are used at the project level to set custom fields.
 * @param context       Used to find the correct file
 * @param fieldName     The name of the field-to-access
 * @return              The value of the field, or {@code null} if the field is not found.
 */
public static Object getBuildConfigValue(Context context, String fieldName) {
    try {
        Class<?> clazz = Class.forName(context.getPackageName() + ".BuildConfig");
        Field field = clazz.getField(fieldName);
        return field.get(null);
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }
    return null;
}

To get the DEBUG field, for example, just call this from your Activity:

boolean debug = (Boolean) getBuildConfigValue(this, "DEBUG");

I have also shared this solution on the AOSP Issue Tracker.

Might be useful to others: beware of the use of `applicationIdSuffix` in Gradle which would make the `.BuildConfig` class not reachable from this above code. — shkschneider, Mar 17 '15 at 09:40

score 6 · Answer 6 · answered Jun 21 '16 at 09:51

Not really the correct way to check if you are in debug flavor, but you can check if the app itself is debuggable via:

private static Boolean sIsDebuggable;

public static boolean isDebuggable(Context context) {
    if (sIsDebuggable == null)
        sIsDebuggable = (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
    return sIsDebuggable;
}

The default behavior of apps and libraries will match it perfectly.

If you need a better workaround, you can use this instead:

public static boolean isInDebugFlavour(Context context) {
    if (sDebugFlavour == null) {
        try {
            final String packageName = context.getPackageName();
            final Class<?> buildConfig = Class.forName(packageName + ".BuildConfig");
            final Field DEBUG = buildConfig.getField("DEBUG");
            DEBUG.setAccessible(true);
            sDebugFlavour = DEBUG.getBoolean(null);
        } catch (final Throwable t) {
            sDebugFlavour = false;
        }
    }
    return sDebugFlavour;
}

score 3 · Answer 7 · answered Oct 19 '14 at 15:08

3

You can create your own BuildConfig class for each build type using gradle

public class MyBuildConfig
{
    public static final boolean DEBUG = true;
}

for /src/debug/.../MyBuildConfig.java and...

public class MyBuildConfig
{
    public static final boolean DEBUG = false;
}

for /src/release/.../MyBuildConfig.java

Then use:

if (MyBuildConfig.DEBUG)
    Log.d(TAG, "Hey! This is debug version!");

answered Oct 19 '14 at 15:08

Cluster

998
10
14

Does "..." for the packageName of the library ? If so, this doesn't seem to work. I can't access the class. – android developer Jun 21 '16 at 09:12

score 2 · Answer 8 · answered May 06 '15 at 12:59

2

Here is another solution.

1) Create an interface

public interface BuildVariantDetector {

    boolean isDebugVariant();

}

2) Use this interface on Application class (Appplication module)

public class MyApplication extends Application implements BuildVariantDetector {

    @Override
    public boolean isDebugVariant() {
        return BuildConfig.DEBUG; //application (main module) Buildonfig
    }

}

3) And then in library module:

boolean debugVariant = ((BuildVariantDetector)getApplication()).isDebugVariant();

answered May 06 '15 at 12:59

Dominik Suszczewicz

1,469
2
16
23

This doesn't work. BuildConfig.DEBUG is still false for me. – DiscDev May 27 '16 at 15:41
Simple and elegant solution. Just make sure you import the app module's BuildConfig not the library's. That's a very sneaky mistake. – WindRider Jul 07 '17 at 16:34

score 1 · Answer 9 · answered Nov 25 '14 at 23:51

We had the same problem. I came up with something like this:

We have a SDK (library) and a demo project, hierarchy looks like this:

Parent
  |
  + SDK (:SDK)
  |
  + DemoApp (:DemoApp)

For the demo app we have, were :SDK:jarjarDebug and :SDK:jarjarRelease are some specific tasks for :SDK that produce some post-processed jars:

dependencies {
    debugCompile tasks.getByPath(":SDK:jarjarDebug").outputs.files
    releaseCompile tasks.getByPath(":SDK:jarjarRelease").outputs.files
    ... more dependencies ...
}

This works even for multiple buildTypes built at once. Debugging is a bit difficult though. Please comment.

score 1 · Answer 10 · answered Dec 08 '16 at 18:26

1

In my case I was importing the wrong BuildConfig as my project has many library modules. The fix was to import the correct BuildConfig for my app module.

answered Dec 08 '16 at 18:26

Ryan R

8,342
15
84
111

score 1 · Answer 11 · answered Aug 16 '17 at 10:35

This is my workaround: reflect BuildConfig of app module:

`public static boolean debug = isDebug();

private static boolean isDebug() {
    boolean result = false;
    try {
        Class c = Class.forName("com.example.app.BuildConfig");
        Field f = c.getField("DEBUG");
        f.setAccessible(true);
        result = f.getBoolean(c);
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }
    return result;
}`

You have used reflection, but this was not necessary. You can use flavors in the build.gradle. — Abhinav Saxena, Feb 08 '19 at 03:44

score 0 · Answer 12 · answered Feb 11 '14 at 14:26

0

You could try this on each of the projects buildTypes:

parent.allprojects.each{ project -> android.defaultConfig.debuggable = true}

answered Feb 11 '14 at 14:26

pablisco

14,027
4
48
70

Can you please explain? Add it to the "debug" buildType only? And to each of the modules ? It gives me an error : Error:(31, 0) No such property: debuggable for class: com.android.build.gradle.internal.dsl.ProductFlavor_Decorated – android developer Apr 10 '16 at 07:42
The specs of the android gradle plugin have changed so this is no longer valid. The debuggable flag has been moved to the `buildType` and not the build config. I theory setting the debug signing should do the same trick – pablisco Apr 11 '16 at 09:50
Can you please check it out and update the answer? If there is an easy workaround, I'd like to know about it. – android developer Apr 11 '16 at 09:53

score 0 · Answer 13 · answered Nov 14 '18 at 07:12

0

Working with debuggable true in gradle file.

buildTypes {
  demo{
 debuggable true
    }
  live{
 debuggable true
    }
}

answered Nov 14 '18 at 07:12

Manikandan

690
5
5

score 0 · Answer 14 · edited Aug 08 '23 at 04:25

BuildConfig.DEBUG is not reliable at all, Android has provided an internal flag that is globally available indicating if a build is in Debug or non-Debug mode

// kotlin:
(context.applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE) != 0
// java:
getContext().getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0

will be true if it is in debug

Credits : https://medium.com/@elye.project/checking-debug-build-the-right-way-d12da1098120

BuildConfig.DEBUG always false when building library projects with gradle

14 Answers14

Linked