IssueTracker

can you share your android studio version

Is this happening with Studio 3.0?

Note: This worked for me on Windows 7 Pro 32-bit (with Android Studio 2.3.3). Seems like an issue with adt-branding module (which should contain the "/idea/AndroidStudioApplicationInfo.xml" resource).

Hi, also happened on Mac Book Pro 15 retina mi-2015
MacOs Sierra 10.12.6
Android Studio 2.3.3
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

Thank you for this feedback. Your feedback helps make sure Android development tools are great! Given your issues has been resolved I am closing this issue.

This is not currently possible with the way Gradle handle dependencies.

I talked to the engineers of gradleware and I think we have a come up with a solution that will require changes both in Gradle and our plugin. I'm hoping get can get this in Gradle 1.8

In the meantime there is no real workaround (that I'm aware of)

I believe this is something that also prevents us from debugging and stepping into code on those library project dependencies. Which is not good, not good at all.

I've just updated to Gradle 1.8 and this does not seem to be fixed... Do we need to do anything else on our part!?

wierd issue, aar always uses release BuildConfig

Gradle 1.9, Android plug-in 0.7.1
Issue still not fixed.

Directory ./build/exploded-bundles contains *.aar files in release mode.
But it should has two subdirectories with corresponding *.aar files:
./build/exploded-bundles/debug/
./build/exploded-bundles/release/

This is not fixed yet, and we haven't announced that it was fixed, so this is expected.

As I mentioned a while ago, there is work to be done in Gradle itself, and this hasn't happened yet.

So basically this issue means that the new android gradle build system doesn't support android projects which depend on android libraries? I guess if we have android library projects we must continue using the ant build system?

No. this means the library used by the project is always the release version of the library. This may or may not be a problem to you.

Also with the buildConfigField option in gradle-plugin 0.8 it is not possible to replace the values as a workaround. To have it back in the libraries. can someone confirm this too?

[Comment deleted]

Of course having the library project always being the release version is a problem. For instance, Google Maps V1 which our product (been in the market 3 years) is still using. We have map views in Android Library projects, and the maps won't work in Debug mode because the map key being pulled is the release map key.

The WHOLE POINT of debug and release builds is to have debug/release overrides. satur9n above is correct really, when he says that the new android gradle build system doesn't support android projects which depend on android libraries. (since it doesn't distinguish properly between debug and release, it DOES NOT SUPPORT Android Libraries!).

We too MUST wait until this issue is fixed before we can migrate our developers to Android Studio, much as we would like to.

I agree that this issue is a MAJOR one, and should be fixed quickly.
Workarounds are dangerous, and may lead to release unwanted code.
And by the way, it would be so perfect that buildTypes get propagated through other modules

Just wondering when this could be fixed as it's a BIG issue to us.

[Comment deleted]

I'm running Android Studio 0.5.8 and this is still an issue. Is there any chance we could get an update on when this might be released?

[POSSIBLE SOLUTION (HOPEFULLY NOT A COMPLETE HACK)]
 My configuration:
        gradle 1.10
        android gradle plugin 0.9.1
        compileSdkVersion = 19
        buildToolsVersion = "19.0.0"
 
There is not way to compile the application and the libraries along with it having different BuildConfig, however, it is possible to build the libraries separately and export them as android archives (.aars).

I included an Android project with two libraries and the gradle scripts with defined two flavours: one building the libraries along with the application at compile time and one giving to the application a reference to an external library where the libraries have been previously built and exported as aars.

P.S.
I had first to export the libraries as aars and then enable the flavour using them (i.e. uncommenting it).

Android Studio 0.6.1 still has no fix for this issue. This should be fixed before beta, since it is an intrinsic behavior of both Gradle and Android plugin. Both need design changes to make it work, I understand.

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

Valuable knowledge. Question: this workaround actually continues to use the release library doesn't it?
The difference is that we have made the release library into a debug library by virtue of switching the Java code to debug, as long as it uses the BuildConfig.RELEASE variable?
So actually, Android Gradle is still using the release AAR, but we don't care!

Correct.

Using android studio 0.8 and the issue remains present.

Is there any work being done to solve this issue or is it something that we are expected to live with?

Try setting this in the dependency project

android {
    publishNonDefault true
    ...
}

and this in the project that uses it

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

Taken from here: https://code.google.com/p/android/issues/detail?id=66805

Doesn't work if you have flavors, it says:
Error:Configuration with name 'release' not found.

Yes it will be fixed but it's going to take a few months.

Using publishNonDefault with Flavors makes things more complicated because the library publishes all combinations, so you'll need to specific flavor1Debug instead of just debug. This does not scale well.

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 answered this on StackOverflow: http://stackoverflow.com/a/25267049/763080

What's this

Er, this has to be one of the biggest issues with AndroidStudio, no? Why is it not being addressed? Is AS really for monolithic apps with no re-use ?

This should be fixed before the 1.0 release of the Android Gradle Plugin

1.0 Android Gradle Plugin is already out and it's still not fixed

It's only a RC 1.0.0-rc4 (2014/12/04)

NO, it's already out: http://tools.android.com/tech-docs/new-build-system/migrating-to-1-0-0

Could we get a link to the issue tracking this on Gradle's tracker? It'd be great to follow their solution to the underlying problem too.

There are lots of potential solutions to this. You really just need to get the boolean value of BuildConfig.DEBUG into the library project. What I've been doing is in the library project I create an abstract class called BaseApplication that extends Application, with some abstract method like:

public abstract boolean isBuildConfigDebug();

In BaseApplication I also have a static variable: private static boolean mIsDebug;
with access to the variable via a method:
public static boolean isDebug() {
    return mIsDebug;
}

Then in BaseApplication I override onCreate and the first thing I do is call:
mIsDebug = isBuildConfigDebug();

Then instead of using BuildConfig.DEBUG in the library application, I call BaseApplication.isDebug();

Yes it's hacky, but it's easy, and I haven't had any issues with it.

The potential solutions I've seen offer a replacement for the DEBUG decision, which will work, for simple boolean based logic differences like log level or some such. However building Google Maps
V1 with Debug/Release API keys is more of a challenge. The map api keys are embedded in layouts, which should be specified for Debug and Release resources separately. The issue is that the debug resources are not being built on a debug app, and you can't work around that so easily.  (this is not a challenge, don't sweat it!)

#50, why does the solution proposed in #35 not work for you? It sounds like it does exactly what you want.

Martin, solution #35 compiles *both* debug and release versions of library and then links to correct one. This is OK as long as compilation of library does not take long. In may case, library has got a lot of native code and compilation lasts several minutes.

Yes, that's the downside of this solution. I could workaround it by using defaultPublishConfig instead of publishNonDefault and setting it's value with a property on the command line, but this again has it's downsides, so I hope this will be fixed soon.

To #51, it looks like #35 does work except for flavors as pointed out by #36? Thanks for pointing that out, I had skipped it because it didn't seem like a complete solution.

Since version 0.9.0 of the Android Gradle plugin this also works for flavors, it's documented here:
http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication

here's a workaround for people that needs to build a jni/native module for different architectures based on the productFlavor or buildType of the main app without manually changing the Application.mk and without pre-building all of them.

basically you need to rewrite on the fly the Application.mk of your module from the build.gradle of your main app.
In the attachment there is my build.gradle of my main build.gradle (stripped down from the extra stuff)

WARNING: in the module i build the jni lib using a custom Application.mk that NEEDS to have these lines inside it

###################################################################################
# THIS FILE IS MODIFIED BY ndkUpdateApplicationMk
# ANY CHANGE TO THESE LINES WILL BE OVERWRITTEN @ NEXT COMPILE
APP_ABI :=
APP_OPTIM :=
NDK_DEBUG :=
###################################################################################

It's a kind of a dirty hack, but it works for me and it could be easily adapted to work with the split-apk feature too.

PS: i am not sure that NDK_DEBUG could be specified inside the Application.mk, but worth a try (i don't need it).

When I write a Log library all the log output methods are controlled by BuildConfig.DEBUG. it is really useful to use a const value like BuildConfig.DEBUG to indicate compiler optimize all the log code if this limit can be solved.

Regarding #37, why is this solution not good? What do you mean "it does not scale well"? It is actually what we need in our project. We have app that has multiple flavors (appFlavor1, appFlavor2, ..., appFlavor6) and two build types (debug, release). The app depends on library that has multiple flavors (libFlavor1, libFlavor2, ..., libFlavor15) and three build types (debug, release, distribute). So what we need is exactly something like this:

dependencies {
    appFlavor1ReleaseCompile project(path: ':libraryProject', configuration: 'libFlavor3Release')
    appFlavor1DebugCompile project(path: ':libraryProject', configuration: 'libFlavor3Debug')

    appFlavor2ReleaseCompile project(path: ':libraryProject', configuration: 'libFlavor7Release')
    appFlavor2DebugCompile project(path: ':libraryProject', configuration: 'libFlavor7Debug')

    appFlavor3ReleaseCompile project(path: ':libraryProject', configuration: 'libFlavor1Distribute')
    appFlavor3DebugCompile project(path: ':libraryProject', configuration: 'libFlavor1Release')
}

Notice that in example there is different number of flavors and build types in library and app so automatic forwarding of build types makes actually no sense. We want release version of app flavor 1 to depend on release version of lib flavor 3 and we want the release version of app flavor 3 to depend on distribute version of lib flavor 1.

Can't the fix simply be by generating DSL methods for every buildType - flavor combination in dependencies object? This is already done for every build type (you get debugCompile and releaseCompile) and for every flavor (you get flavor1Compile etc.). Why is so complicated to create all combinations (flavor1DebugCompile)? Why is this issue not resolved for almost two years now?

OK, I have achieved #59 with following hack:

Map<String, Dependency> customDeps = new HashMap<String, Dependency>()

customDeps.put("appFlavor1DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor1Debug"))
customDeps.put("appFlavor1ReleaseCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor1Release"))

customDeps.put("appFlavor2DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor3Debug"))
customDeps.put("appFlavor2ReleaseCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor3Release"))

customDeps.put("appFlavor3DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor5Debug"))
customDeps.put("appFlavor3ReleaseCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor5Release"))

configurations.all() {config ->
    Dependency d = customDeps.get(config.name)
    if(d != null) {
        config.dependencies.add(d)
    }
}

An example gradle project is attached in this comment.

However, there is now another bug to address: I've already reported it in issue 36949180 (https://code.google.com/p/android/issues/detail?id=78997). The problem is that even if you build only one configuration of your app, all configurations will be built, thus triggering build of all dependencies which consumes a lot of time.

For example, in attached zip you can execute task :app:assembleAppFlavor1Debug and you will end up executing all following tasks:

$ ./gradlew :app:assembleAppFlavor1Debug
:app:preBuild
:app:preAppFlavor1DebugBuild
:app:compileAppFlavor1DebugNdk
:app:checkAppFlavor1DebugManifest
:app:preAppFlavor1ReleaseBuild // why is this task reached
:app:preAppFlavor2DebugBuild // why is this task reached
:app:preAppFlavor2ReleaseBuild // why is this task reached
:app:preAppFlavor3DebugBuild // why is this task reached
:app:preAppFlavor3ReleaseBuild // why is this task reached
... and now all flavors of library are built

For some reason attachment in #60 is missing, so I am adding it again.

OK, redundant builds reported in #60 are gone if you remove dependency to google play services as suggested in issue 36949180.

@62, #60 worked just fine for my project!

#35 did the trick for my config:


Main:
task wrapper(type: org.gradle.api.tasks.wrapper.Wrapper) {
    gradleVersion = '1.9'
}


Module (theotherproject):
buildscript {
    dependencies {
        classpath 'com.android.tools.build:gradle:1.0.0'
    }
}
apply plugin: 'com.android.library'
...


if you got

"Cannot evaluate module theotherproject : Configuration with name 'debug' not found."

you are missing the

android {
    publishNonDefault true
    ...
}

This problem has been exist from the beginning and I can see Android Team is working it out, So when will the patch will be released? Android Studio's Build Variant makes people frustrated. Looking forward to have it fixed.

Comment #35 works!

same problem after updated to "Android Studio 1.2 Beta 3"

The fix is planned for Gradle Plugin version 1.4, and the latest version is "only" 1.2.0-beta1.

can someone please add a link to the bug in the gradle issue tracker that this bug depends on

Jesus!!!!!
It's been two years !!!!

Re: #70 y...@google.com

I couldn't identify any related issues on issues.gradle.org, however, the required Gradle improvements are mentioned on the Gradle roadmap:

Variant Aware Dependency Management
http://discuss.gradle.org/t/variant-aware-dependency-management/115

Is this bug still not fixed? Its an important issue.

ganjinjiejiejue

I have the same bug: "Error:Configuration with name 'production' not found."

Experiencing the same thing. Whether I am using assembleDebug or assembleRelease both buildTypes are fired. This causes all sorts of problems with signing, versioning and debug-flags.

not  fixed?

It says it'll be fixed in gradle plugin 1.4. Right now, I believe 1.3 is in alpha/beta. Hang in there.

Just to set the expectations, please see Xav's comments, e.g. #8. This is blocked on Gradle, see https://discuss.gradle.org/t/variant-aware-dependency-management/115. It most likely not be fixed in 1.4.

Why haven't it have been fixed 2013? WHY?!
With this bug ANY development with linked library module is PRACTICALLY IMPOSSIBLE.

as others said it is too stupid bug . i am developing a library for android projects and i can't use it in debug variant
 

For me #35 is a valid workaround that help me manage about 4 library projects all in debug mode within the final APK.

Hey guys, you can define other field for BuildConfig and manage it in parallel with debug/release assembly.

For example:

--------------------------------
gradle.properties

    SNAPSHOT=true
--------------------------------
build.gradle

    subprojects {
        android {
            defaultConfig {
                String snapshot = (Boolean.valueOf(getProperty('SNAPSHOT').toString())) ? "Boolean.parseBoolean(\"true\")" : "false"
                buildConfigField 'boolean', 'SNAPSHOT', snapshot
            }
        }
    }
--------------------------------
SomeWhere.java

    import static com.yourcompany.library.BuildConfig.SNAPSHOT;

    void f() {
        if (SNAPSHOT) {
            Log.v(LOG_TAG, "This code will be kicked out by compiler when SNAPSHOT=false");
        }
    }
--------------------------------

Now when you building release apk, just override this property:

    ./gradlew assembleRelease -PSNAPSHOT=false

Btw, following this approach you may keep SNAPSHOT=true if needed to test release apk with verbose logs.

[Comment deleted]

[Comment deleted]

[Comment deleted]

#83 and #82 are pretty much useless, because gradle will build release version too when building just in debug. So compile time will be spectacularly slow.

Gradle is just bloated piece of crap, just like Android as a whole. And Google doesn't care, because it monetizes on ads in cheap phones, not on quality and good apps.

[Comment deleted]

It seems like you don't understand what everyone expect from debug/release build.
Almost all authors above are using BuildConfig.DEBUG field which is always false due to this issue.

I propose to define custom field and control it manually.
This approach works fine for my goals:
- remove useless log-messages from binaries
- add more checks (like strict-mode) for debug mode only

Оhow will you develop a library without ability to debug it (because it is in release build)?

#80, it is not true that it is impossible to work with library projects, it's just inconvenient.
#83, this solution only is a replacement for the DEBUG flag in BuildConfig, but there can be many differences between the release and debug build types, e.g. ProGuard or different source files or assets.

To workaround the issue define a property in gradle.properties:

buildType=debug

And use it for the defaultPublishConfig field, e.g. in the main build.gradle:

subprojects {
   android {
      defaultPublishConfig properties['buildType']
   }
}

This way the debug build type of the libraries is published during development. If you want to do a release build just add -PbuildType=release to the build command. Note that with this solution you can't do a debug and a release build with a single command.

#79, it's already two years since Xavier announced that he has discussed a solution with the Gradle devs, and he hopes that the needed changes will be in Gradle 1.8. We are now close to the release of Gradle 2.5. Later the fix was targeted for Studio 0.5.0, then for the beta, and finally for 1.4. Now you tell us that we have to wait even longer. Also the linked blog post from Hans Dockter does not give any timeline.

This is by far the most starred issue for Subcomponent-Tools-Gradle, so please don't ask us to lower our expectations and instead put more effort into fixing this. And also make the process more transparent and provide us more information, like links to related Gradle issues, instead of just delaying the fix again and again.

#91 martin, it's inconvenient up to the scale of impossible.
My complex iOS project written in Objective-C that contains my library and several third-party libraries compiles incrementally IN 6 SECOND. SIX, CARL!

Gradle, on other side, compiles much simpler project incrementally for over 30 seconds on the same machine.

After polished and fast iOS development process I hate slow, bulky and unresponsive Android build tools, emulator and eternal buggy API.

This Issue Ticket is an example that Google cannot for over 2 years to fix most important of bugs.
DIE, Android! I'm writing for you only because every teenager without money doesn't have any other smartphone choice. I hope Microsoft will make good cheap phones and Google will have to fix all this Gradle crap (and Android's Bluetooth too).

This is not the place to vent all of your frustrations. Keep it professional and don't spam others that have starred this bug with your non constructive comments please.

#94 I think it is exactly the place, because starring the bug have no effect.

I can link you TENS of other (more specific, but no less stupid) bugs about what Google doesn't care.

In Bluetooth: https://code.google.com/p/android/issues/detail?id=63056
In Audio: https://code.google.com/p/android/issues/detail?id=3434
In WiFi: https://code.google.com/p/android/issues/detail?id=35585

Basically, EVERY system framework on Android DOESNT WORK CORRECTLY. This is insane for iOS developer like me. :) I'm accustomed to situation when if you have system framework and documentation for it, it is working with maybe with 1-2 small bugs or small corner cases.

There is 3-year old article about this: http://darkdust.net/writings/whyihateandroid — it seems that everything in it still holds true.

This is not a discussion forum, you are spamming 290 people with every update. Stop it.

Is there any hope to see a fix for this issue, or shall we consider the work around to be the only way long term to rely on custom flags passed to the build process ?

@97 So far as it seems I would place my bets on implementing custom workarounds as I suggested in #60. We are doing that for 6 months now at our company and we live with it...

Actually, I can think of a case when you actually want debug version of your app to depend on release version of a library: for example if your library performs some performance critical tasks, like video frame processing and you just want to find a bug in your app, not wasting time for slow performance of library in debug mode.

I think it would be best to let developers choose for each build type the build type of every dependency. Currently there is a hackish way of achieving that (see my comment #60) and I hope such thing will be officially supported in dependency block. The only downside is that this hack currently triggers a very annoying bug reported in issue 36949180, but there is even hackish workaround for that issue - see comments 11 and 15 in issue 36949180.

I hope that Android Gradle team will fix issue 36949180 and provide an official way of defining per-flavor per-build type dependencies between application and library.

They're currently getting close to releasing the next-gen plugin. I'd put good money on the fix being rolled in with that. Just my 2c.

Doesn anyone know whether this has been fixed in Android Studio 1.4?

No, it is not fixed in Android Studio 1.4

#60 works fine but works only for 1 dependency lib (=if you need to specify a configuration to only 1 sub-lib "mylibrary")

What I need is to include several libs as following:

customDeps.put("appFlavor1DebugCompile", dependencies.project(path: ":mylibrary", configuration: "libFlavor1Debug"))
...
customDeps2.put("appFlavor1DebugCompile", dependencies.project(path: ":mylibrary2", configuration: "libFlavor1Debug"))

I've succeeded in adding 2 dependencies to the same config.name by using 2 blocks of code shown in #60 (with 2 different hashmaps). Here are the prints:

Name: appFlavor1DebugCompile
Dependencies: [DefaultProjectDependency{dependencyProject='project ':mylibrary'', configuration='debug'}, DefaultProjectDependency{dependencyProject='project ':mylibrary2'', configuration='default'}]

But at compilation, it includes only the first lib (mylibrary) and then failed to find classes/methods of the second lib (mylibrary2)...

DodoEnte...@gmail.com (or someone else) do you have any solution?

Thanks.

best workaround I found: http://stackoverflow.com/a/30134955/361100

Still happens, here is my configuration :
        gradle 2.9
        android gradle plugin 1.3.0
        compileSdkVersion = 20
        buildToolsVersion = "23.0"

Best work around I found was to configure ProGuard to keep needed debugging information. I found the solution here : http://stackoverflow.com/questions/28836243/android-studios-debugger-not-stopping-at-breakpoints-within-library-modules

A fix for this would be very appreciated.

how do you implement the solution #37 in the new experimental gradle syntax . Expanded post on it https://groups.google.com/forum/?fromgroups#!topic/android-ndk/kKZpiXbOW7k

trying to use
dependencies {
    flavorDebugCompile project([path: ':custom_lib', configuration: "libraryDebug"])


It gives the following error:
flavorDebugCompile method not found

I have a hacky workaround.

custom_library build.gradle:

dependencies {
    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
    testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
}

^ yes the above will always use the releaseCompile so this is actually pointless BUT .. future proof

app module that depends on library build.gradle:

dependencies {

    compile (project(':custom_library')) {
        exclude group: 'com.squareup.leakcanary'
    }

    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3.1'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
    testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3.1'
}

I'm having this issue on gradle-experimental:0.6.0-beta5

Error:(278, 0) Gradle DSL method not found: 'debugCompile()'
Possible causes:The project 'AndroidFleksy' may be using a version of Gradle that does not contain the method.
Open Gradle wrapper file The build file may be missing a Gradle plugin.

Just fix problem

3 f'n years later and still not fixed.  and colleagues wonder why I miss eclipse - it just worked.

There is a very intersting workaround here: http://stackoverflow.com/questions/35312743/workaround-to-link-a-shared-library-in-debug-mode-with-android-studio-v2-0-beta

Plugin 1.5.0
Android Studio 2.1 RC
Gradle 2.10

I have very similar issue. Whenever I'm adding external dependency by using
  dependency {
    compile 'com.corp:corp-api:0.1.1-SNAPSHOT'
  }

new, very strange task appears, the name of task is like:

  :lib2:prepareComCorpCorpApi011SNAPSHOTLibrary

which depends on
  :lib1:bundleLibraryDebug
  :lib1:bundleLibraryRelease   <<<<<<<<<<<<-----

So it does not matter which kind of build I'm running, release of debug (or flavored ones), anyway all the build types are fired...

Any ideas ?

I'm using trick on #60 with some libraries. However this doesn't appear to work when using gradle experimental to build a shared library!

Can't believe it's been 2 years and it's still not fixed!

I don't want DEBUG code in the final shared library or Java code, but only trick is to use a variable, hence all codes gets in release APKs if I don't manually edit the gradle file. Pretty shitty if you ask me.

Using latest gradle with AS2.1, I was able to solve this issue with a very simple dependency content:

Lib's build.gradle (uses experimental gradle 0.7.0):
model {
  android {
...
    productFlavors {
       create('all') {
         ...
       }
    }
    publishNonDefault true
  }
}
configurations {
  allDebug
  allRelease
}

App's build.gradle (uses standard gradle 2.1.0):

    debugCompile project(path: ':lib', configuration: 'allDebug')
    releaseCompile project(path: ':lib', configuration: 'allRelease')

I'm pretty sure the productFlavors in the lib's gradle is not needed if using debug/release configurations only.

I have been waiting for this to be resolved for a year. A bit frustrating. Any estimation when it will be fixed?

This bug makes my development work difficult. I define values for debug and release with buildConfigField in the library module but they are simply ignored (only the values of release are taken no matter what).

[Comment deleted]

As others suggested debugCompile/releaseCompile doesn't exist in gradle-experimental. Instead I was able to force building dependency (library) setting defaultPublishConfig "debug" (or "release") inside model.android.

Probably not important, but my library is external though linked inside project as described here:
http://www.philosophicalhacker.com/2014/10/03/an-alternative-multiproject-setup-for-android-studio/

I have the same problem even with AS 2.1.3. It keeps try to run Proguard and build my lirary as Realease. I added and selected debug build variant to all projects with no luck. This takes a lot of time and making development progress lagged. Please address and fix. Thanks.

Hello, i have another approach:

build.gradle (lib):
---------------------------------------------------------------------
apply plugin: 'com.android.library'

android {
    publishNonDefault true
...
    buildTypes {
        release {
...
        }
        debug {
...
        }
    }
}
dependencies {
...
}
---------------------------------------------------------------------
build.gradle (application)
---------------------------------------------------------------------
apply plugin: 'com.android.application'

android {
...
    buildTypes {
        release {
...
        }
        debug {
...
        }
    }
}
dependencies {
    debugCompile project(path: ':libName', configuration: "debug")
    releaseCompile project(path: ':libName', configuration: "release")
...
}

@128: What's the new target for the fix?

This is actively being worked on. Target is 2.5.

We have an early preview for 2.5.0 with variant aware dependency management: http://tools.android.com/tech-docs/new-build-system/2-5-alpha-gradle-plugin

[Comment deleted]

I afflicts the problem, work performance is low by recompiling the configuration. I tried the 2.5.0 and does not give me the solution to the problem.

This is fixed in 3.0!

@119 Fixed? I can't even create a working signed APK :
https://issuetracker.google.com/issues/38473781
How could it be fixed?

interesting

I just tried it with the latest gradle version (com.android.tools.build:gradle:3.0.0-alpha6) - still does not work for non-local dependencies.
I'm wondering if there different behavior between using local library vs. using an (maven) aar dependency. Because the code inside an aar is already compiled - the gradle plugin would need to change the java bytecode of the BuildConfig class.

@122: I guess you just gave the answer to yourself: It cannot work for already compiled AAR dependencies, because the code in the AAR might not even contain the debug code anymore, e.g. due to dead code elimination done by the compiler when compiling for release mode. And even if that was not the case, patching the AAR's bytecode to change the value of the BuildConfig.DEBUG flag is not feasible to do, IMO.

This is only for module-to-module publication/consumption. Published AAR only exist in one variant (release).

IMHO this problem is still existent.

Tested it on alpha-8, still not working

what is not working?

file or directory '/home/user/StudioProjects/ProjectName/app/src/main/kotlin', not found
file or directory '/home/user/StudioProjects/ProjectName/app/src/debug/kotlin', not found
file or directory '/home/user/StudioProjects/ProjectName/app/src/main/kotlin', not found
file or directory '/home/user/StudioProjects/ProjectName/app/src/debug/kotlin', not found

Android 3.0 Beta 6

these are just warning messages.

Happening in 3.0 RC1, was not an issue in stable releases like 2.1

My bad its not an issue in 3.0 RC1

Still happening on 3.0
Trying to set flags depending on build type - release flags works all the time

Any updates on this?

My project consist of 4 modules. I getting BuildConfig.DEBUG from the package name mypck.com.Buildconfig and it always return false

I have defines the same buildTypes in both modules (have only 2) and it works.

where is #35 comment? please someone repeat what was said in that comment

I'm trying to solve the next task https://stackoverflow.com/questions/52677223/how-to-check-if-current-build-is-debug-or-release-in-build-gradle

Hi,I have set publishNonDefault true，and it worked on this. but this code take me new question when i want to upload the sourceCode and javaDoc to maven.would you know how to upload muiltple flavours of sourceCode and javaDoc. thanks.

adding publishNonDefault true in gradle-4.10.2 gives the following warning

 publishNonDefault is deprecated and has no effect anymore. All variants are now published.

and looking at the source code it seems to be useless, however, the warning message seems to be wrong as I still use the debug variant can't


     public void setPublishNonDefault(boolean publishNonDefault) {
        logger.warn("publishNonDefault is deprecated and has no effect anymore. All variants are now published.");
    }

Any updates on this?

How to get current buildType in Android Gradle configuration?

I'm wondering where number #35 is? How is this marked as fixed? Can we get a solution please?