[Gradle] debug apk depends on bundleRelease not bundleDebug

[Szabolcs Berecz]

Hi!

I just noticed that assembleDebug creates an apk which contains the release version of android-library projects, not the debug version. The debug versions are also compiled for these library projects but only after creating the apk, so there is no way to include the debug version of the libraries in the apk.

Is this intentional? Or maybe my build scripts are broken?

I created a graph of the dependencies between all the tasks in my build and this is what I see:
- in an 'android' project, the prepareReleaseDependencies and the prepareDebugDependencies tasks depend on the same prepare*Library tasks which in turn depend on bundleRelease tasks
- bundleDebug tasks are only depended on by assembleDebug which are only depended on by assemble. So, nothing uses the results of a debug build of an android-library project. Or if something uses it, it does not show in the task dependencies.

I also noticed that there is an unnecessary dependency between assemble and bundleRelease. Assemble also depends on assembleRelease which depends on bundleRelease, therefore the assemble->bundleRelease dependency is unnecessary.

I can minimize my build if that helps. Let me know if you need it.

Thanks,
Szabolcs

[Xavier Ducrohet]

The library thing is normal. For now.

For library project, "debug" and "release" are misnomer really (as I was preparing my I/O talk, I really wanted to rename them for 0.4, but so far I haven't)

"debug" is used only for testing the library itself (so the test apk inside the library project uses this), and "release" is used to package the library for use by other projects (in a multi-project setup) or for upload to a repository.

I think once we add NDK support we're going to want to change this and have possibly more than 2 built-in Build Types in Library Projects, but we have to figure out exactly what it's going to look like.

For instance, do we enforce that Library Projects have exactly matching Build Types (in name) as the App Projects using them? This could become overly complex every time you add a new build type to your app, as you'd need to update all the Library Projects.

Or we could have some mapping in the App project indicating (for each Build Type of the app!) which Build Type to use (for each library!). This could become unwieldy if you have many libraries (some developers have told me they were using 10, 20 library projects!).

Ideas welcome.

I'll check the assemble->bundleRelease extra dependency on Monday.

thanks

Xav

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Szabolcs Berecz]

I see, makes sense now that I think about it.

I have about 8 library projects, some of these are external projects like actionbar-sherlock which I don't usually want to build in debug mode and the others are internal which should be in debug/release version depending on the actual build type. I'm not using any flavors yet (I don't think I can use these with the current ADT plugin for eclipse).

I think it would be better to have the configurable mapping than a fixed one. If it's configurable, the community can come up with a couple of small libraries which could auto-configure the mapping. E.g. "always use release libs" or "use the build type of the dependent project"

[jared.b...@usaa.com]

I think I would prefer a strategy that uses the same-named build type, if it exists, else use the library's defaultPublishConfig...  As is, we followed the mapping route (if I understand your post correctly), with type-specific dependencies in our app build.gradle.  With our custom build type of preview, this is what we ended up with:

dependencies {

    debugCompile project(path: ':myLib', configuration: 'debug')

    previewCompile project(path: ':myLib', configuration: 'preview')

    releaseCompile project(path: ':myLib', configuration: 'release')

    compile (

       'com.foo:extLib1:1.0'

       'com.bar:extLib2:1.0'

    )

}

Even with this, we had to set 'publishNonDefault true' in our library's build.gradle to make Studio happy, which causes any build of any type of our app to check on all build types of our library; most of the time, everything's up to date, but it seems unnecessary.  Is there a better way?

[Xavier Ducrohet]

There isn't a better way but we're doing a lot of work in dependency management so we should improve this soon.

For more options, visit https://groups.google.com/d/optout.