14

I'm sure that this has been asked before, but I'm just not finding the right keywords to ferret out answers, so...

How do I stop Gradle for Android (inside or outside of Android Studio) from building all build types of a library module when I request to build one build type? IOW, if I am building debug, how do I prevent Gradle for Android from also building release?


The back-story, for those with alternative ideas:

Suppose that I have two Android Studio projects, A and B. Each has two modules: an Android library module and a demo app that depends upon that library. So, I have a total of four modules:

  • AL: project A's library
  • AD: project A's demo app
  • BL: project B's library
  • BD: project B's demo app

So long as A and B are not related, life is good.

But what if I want BL to depend upon AL?

For release, if I want those libraries to go in a Maven-style artifact repository, I need the release variant of BL to depend upon the published artifact of AL. That way, my BL POM has the right dependency info.

For debug, it would be ideal if BL could depend upon the working copy of AL. While setting that up is a bit hacky, I can make it work.

But then if I add stuff to AL, such as a new Java class, and I try using it from BL, I can't build. My debug build is perfectly fine AFAICT. However, even though I really really really don't want to do a release build now, Gradle for Android insists upon doing a release build anyway:

$ gradle assembleDebug
:demo:preBuild UP-TO-DATE
:demo:preDebugBuild UP-TO-DATE
:demo:compileDebugNdk UP-TO-DATE
:demo:checkDebugManifest
:demo:preReleaseBuild UP-TO-DATE
:richedit:compileLint
:richedit:copyReleaseLint UP-TO-DATE
:richedit:mergeReleaseProguardFiles UP-TO-DATE
:richedit:preBuild UP-TO-DATE
:richedit:preReleaseBuild UP-TO-DATE
:richedit:checkReleaseManifest
:richedit:prepareReleaseDependencies
:richedit:compileReleaseAidl UP-TO-DATE
:richedit:compileReleaseRenderscript UP-TO-DATE
:richedit:generateReleaseBuildConfig UP-TO-DATE
:richedit:generateReleaseAssets UP-TO-DATE
:richedit:mergeReleaseAssets UP-TO-DATE
:richedit:generateReleaseResValues UP-TO-DATE
:richedit:generateReleaseResources UP-TO-DATE
:richedit:packageReleaseResources
:richedit:processReleaseManifest UP-TO-DATE
:richedit:processReleaseResources
:richedit:generateReleaseSources
:richedit:compileReleaseJava

(where richedit is BL and demo is BD in my nomenclature above)

I am asking to assemble the debug build, but it still compiles the release build. And the release build cannot compile, because I am trying to have BL use new unreleased stuff from AL.

I am reasonably confident, though not 100% certain, that if Gradle for Android would just blithely ignore release when I am trying to build debug, that I would be in OK shape.

Of course, there are possible workarounds:

  • I could abandon the idea that these are separate libraries and consolidate them into one. I may yet do that. But it sure feels like what I'm trying to do should be possible.

  • I could not try using the AL changes until I publish a release AL, in which case BL can depend upon the published artifact for both debug and release. However, that seems like it will cause a lot of patchlevel churn in the A project, as my primary consumer "use case" of this new A functionality is B. Just because I have changes in A that pass instrumentation tests does not mean that they'll be what B needs, and I won't know that until I can build B with the changes in A.

  • A variation on the above workaround may be SNAPSHOT releases, where I would somehow enable checking for SNAPSHOT releases for debug but not for release or something. However, the mix of Maven, Gradle, Android, and SNAPSHOT all seems rather under-documented, and I have no idea if it's something that I should be pursuing. And, as with the preceding bullet, this still would result in release being built unnecessarily; the build would just succeed in my case.

Is there some Gradle for Android setting somewhere that I am missing that says debug means just debug?

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • I am not well-versed with Gradle, so this may be utter nonsense :-| - can you pull open the `Build Variants` panel (View > Tool Windows > Build Variants) and choose `debug` for `richedit` module? – Vikram Mar 27 '15 at 23:49
  • 1
    @Vikram: That is what's there. That, in turn, means that when you go to build or run the project, it will do an `assembleDebug` task, and result in the described problems. I happen to use the command-line **`gradle assembleDebug`** task to show the Gradle transcript, but the results are the same. Thanks, though! – CommonsWare Mar 27 '15 at 23:51
  • 1
    https://code.google.com/p/android/issues/detail?id=66805#c3 – Amrut Bidri Mar 31 '15 at 11:42
  • @AmrutBidri: That comment only pertains to custom build types. Right now, I am only using `debug` and `release`. Thanks, though! – CommonsWare Mar 31 '15 at 23:24

2 Answers2

3

https://stackoverflow.com/a/27278352/535762 If you fix your problem, I would be interested to know how, because it sure isn't fully functional yet to use gradle builds with only debug in mind.

Here the essential parts:

In the "Build Variants" panel window on the left, you should see both of your modules, and next to them the current "active" variants. For instance

app debug 
custom_lib debug

Build > Make Project

Is building every module in the project in their current variant

https://code.google.com/p/android/issues/detail?id=52962 will require building the release variant of custom_lib, and so you end up building both.

Use the option that says Make Module app. This option will change from app to lib based on the current selection in the Project panel or based on the current editor, and will always do only what's needed to build the current module.

Community
  • 1
  • 1
einschnaehkeee
  • 1,858
  • 2
  • 17
  • 20
  • That indicates that my question is a duplicate. I pretty much gave up on this issue, so I do not anticipate testing whether Xav's solution is practical. Most likely it is, though it's possible that changes in Android Studio since December 2014 will impact matters. Many thanks! – CommonsWare Apr 04 '15 at 21:54
  • Oh I'm sorry for the lack of a clear answer. I edited it to make sure everyone sees the essential parts. – einschnaehkeee Jun 01 '15 at 21:14
2

There is a bug here : https://code.google.com/p/android/issues/detail?id=52962

Does Comment #35 i.e.

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

work for you? Seems to be the one that most people think work, I haven't tried it personally yet.

Vrashabh Irde
  • 14,129
  • 6
  • 51
  • 103
  • Sorry, that does not change the behavior. Moreover, it would break the POM for the release build, which needs to depend upon the artifact, not some peer project. Thanks, though! – CommonsWare Mar 31 '15 at 23:29