2

My problem is much as described in questions such as this: Build variants in Gradle for a Library Project in Android

That is, I'm making a library module with debug and release build types, and each build type has its own resources (for example in strings.xml). However, the release resources are always selected even when building the debug variant.

Pretty much everything I'm reading indicates that this has been fixed in Android Studio 3.0, but I'm on 3.3 and still experiencing the problem. One suggestion I've seen is to use releaseCompile and debugCompile. Those are deprecated so I used the replacements:

debugImplementation project(path: ':myLibrary', configuration: 'debug')
releaseImplementation project(path: ':myLibrary', configuration: 'release')

That produces these errors:

ERROR: Unable to resolve dependency for ':app@myAppDebug/compileClasspath': Could not resolve project :myLibrary.
Affected Modules: app

ERROR: Unable to resolve dependency for ':app@myAppDebugAndroidTest/compileClasspath': Could not resolve project :myLibrary.
Affected Modules: app

ERROR: Unable to resolve dependency for ':app@myAppDebugUnitTest/compileClasspath': Could not resolve project :myLibrary.
Affected Modules: app

I've quadruple checked the spelling, and it matches the name of the library. I was doing this before that resulted in the incorrect behavior described above:

implementation project(':myLibrary')

From the library build file:

android {
    publishNonDefault true
    ...
    buildTypes {
        debug {}
        release {
            minifyEnabled false
            zipAlignEnabled true
            signingConfig signingConfigs.releaseConfig
            //proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    ...

I also have a "qa" build type that I have omitted from discussion, but I have no reason to believe that's relevant as I'm not currently attempting to build that type. Any suggestions, or anything else I should add to the question?

nasch
  • 5,330
  • 6
  • 31
  • 52
  • It happens because strings.xml is a global resource in your project. To solve your problem i will need to understand why and what you are getting strings.xml inside your library. Maybe you are trying to get/thinking in a bad way. – Juan Munhoes Junior Jan 29 '19 at 00:00
  • I have various `strings.xml` files, for example one in the library's `main` source set and another in its `debug` source set. In an app module, if the same resource is defined in both places when building the debug variant, the debug value will be used. In my library module the value from the main source set is used rather than being overridden by the value in the debug source set. Does that answer your question? – nasch Jan 29 '19 at 02:57
  • no way to do this currently nasch sorry – Fred Grott Feb 04 '19 at 20:07
  • @FredGrott Well that's dumb! Thanks. – nasch Feb 04 '19 at 20:47

2 Answers2

0

build-types debug and release are default build-variants; referring by configuration might only work for productFlavors (as the Android library documentation hints for).

  • better use implementation project(path: ":myLibrary")

  • with source-sets main and debug; optionally release.

publishNonDefault and defaultPublishConfig are only useful for external publishing.

according to issue 68778928:

Libraries always publish all their variants now so the DSL property has no effect.

one possible workaround is to add the already built artifacts by classifier:

artifacts {
    archives file: file('build/outputs/aar/my-library-debug.aar'), classifier: 'debug'
    archives file: file('build/outputs/aar/my-library-release.aar'), classifier: 'release'
 }
Martin Zeitler
  • 1
  • 19
  • 155
  • 216
  • I am using `implementation project()` and that's what is showing the problem with always picking release resources (the documentation doesn't include the word "path" in its usage). I have main, debug, and release source sets. I tried the `artifacts` block but it seemed to have no effect. I hope your first sentence is incorrect, and that there is a way to get this to work for build types. I really don't want to create a flavor dimension that basically mirrors the build type - that sounds like a mess. Thank you for taking the time to put this answer together. – nasch Jan 29 '19 at 02:55
  • 1
    @nasch the situation is that this once worked, but not works anymore since `3.0.0` ...linking built `JAR` or `AAR` packages seems to be the least overhead, without having to define `productFlavors`. – Martin Zeitler Jan 29 '19 at 12:09
  • I'm not sure I follow. To get an AAR to link, I would need to build a library whether from this project or another. When building that library, how do I select debug and release resources? – nasch Jan 29 '19 at 16:55
0

You can change which varaint gets published from your library by adding following line to your library project:

android { defaultPublishConfig "debug" }

Vishal Arora
  • 2,524
  • 2
  • 11
  • 14