Gradle Android Dependency Product Adaptation

Question

I would like to know if there is a way for the root project to define / introduce some properties in its dependency. More specifically, the problem I am facing is that the library project needs to know whether to use "free" or "pro" java sources and other resources before starting the build / compile task. Similar to specifying product tastes for library projects (which are inherited from its parent project), but this is not supported by the Android plugin for Gradle. Changing the structure of the library project, i.e. Creating "free" and "pro" libs is not an option.

Edit: The best I've been able to achieve so far is something like this:

root: build.gradle

android { ... productFlavors { free, pro } sourceSets { free { project(':..:lib') { groupFreePro = 'free' // java.srcDirs = ['src', 'free/src'] } } pro { project(':..:lib') { groupFreePro = 'pro' // java.srcDirs = ['src', 'pro/src'] } } ... } } 

library: Gradle.build

 android { ... sourceSets { main { java.srcDirs = [groupFreePro + '/src'] res.srcDirs = [groupFreePro + '/res'] } } ... } } 

This way I insert the groupFreePro variable into the lib project. But there is a problem with this approach:

By the time the lib project gets the android → sourceSets task into it, groupFreePro is always set to "pro". I assume that due to the fact that all source sets in the root project are read (and not just the one option that I want to build, for example, "free"), and therefore the last set / task always overrides any previously set groupFreePro values.

If I try to set the groupFreePro value in any other way, it will either be overridden (as in the case above), or I don’t know the appropriate task / time / place where I should name this injection variable in order to set the variable to the desired value . Uncommenting java.srcDirs in the root project also does not help.

I tried to solve these problems myself, but I'm really new to Gradle, and the lack of proper documentation (at least for the Android part) does not let me guess what to do most of the time, so I do a lot of trial and error (but now I as if stuck).

Answer 1

This is how I solved the problem at the moment. This is not an ideal solution, but so far it is good enough.

Update!

I updated the answer to include the latest 0.9.2 Gradle plugin and new (est) functions (basically only updated library build scripts).

root: gradle.build

 // global variables ext { // can be set to default values or blank groupFreePro = "free" } // start parameters println "Start parametes: tasks = " + gradle.startParameter.getTaskNames() gradle.startParameter.getTaskNames().each { task -> if (task.contains("Free") || task.contains("F")) { groupFreePro = "free" } else if (task.contains("Pro") || task.contains("P")) { groupFreePro = "pro" } println "groupFreePro = " + groupFreePro } android { ... } 

task.contains("F") should handle shortened versions or tasks that are being executed (if we want to run the script as a gradle aFD ).

Global variables in ext can be set to default values. In this case, even if you run the script without "Free / Pro" in the task name, it should work fine. The disadvantage of the default values ​​is that the assembly may not work if it is not configured properly (if you want the assembly to work only if the name "Free / Pro" is specified in the task name).

library: gradle.build

 android { ... defaultPublishConfig groupFreePro + groupDebugRelease.capitalize() productFlavors { free pro } ... sourceSets { main { java.srcDirs = ['/src'] res.srcDirs = ['/res'] } free { java.srcDirs = ["free/src"] res.srcDirs = ["free/res"] } pro { java.srcDirs = ["pro/src"] res.srcDirs = ["pro/res"] } } ... } dependencies { freeCompile fileTree(dir: 'free/lib', include: '*.jar') } 

Update:

The library now contains defaultPublishConfig , so I don't need to specify

  java.srcDirs = ["src", groupFreePro + "/src"] res.srcDirs = [groupFreePro + "/res"] 

as well as compilation of user taste, i.e. flavor1Compile (in the dependencies block).

The ability to write compile project(path: ':project', configuration: 'flavor1Debug') in the dependencies block doesn't really work for us, because you have to pass these parameters through dependencies, and if you have several taste groups / dimensions, this means that more or less all flavor combinations must be processed in "not the last" dependencies (ie dependencies that have other dependencies (which have several flavorings)).

The println lines are just to see and make sure that the correct parameters are passed.

The surface of this solution (compared to Varun's) is that you only need to run one (original) task. It also means that it works (or at least should) with Android Studio without any problems.

The disadvantage of this solution is that it does not work if you want to create all the options using the gradle assemble command (or similar), which does not contain part of the Free task. I think that this could also be handled, but I am not doing it because the current solution is good enough for me now (although if I improve the current solution I will probably also update this answer).

There are other solutions using gradle.taskGraph.whenReady , but I don't know how to install srcDirs (dependencies in particular) correctly. Suggestions are welcome.

Answer 2

Here is the LibraryVariant and here the ApkVariant

If you look at the DSL above, it doesn't look like multiple productFlavors supported for productFlavors .

If your free/pro will not change much, you can create aar each for pro and for free and use them as dependencies necessary for your application.

UPDATE:

I have some code on github. It works, but requires an additional task to be called before the build / build task is called in the application. https://github.com/varunkochar/Trying-Android-Gradle/tree/master/FakeLibraryProductFlavors

UPDATE:

With the latest vroid plugin version w0.9.0 for Android, the library project now also supports the same DSL as ApplicationProject. Thus, you can use the latest version and use the built-in features of library projects to build with the help of special flavors. Source: http://tools.android.com/tech-docs/new-build-system

Answer 3

This feature is now available after version 0.9 of the Gradle plugin for Android.

Take a look here: http://tools.android.com/tech-docs/new-build-system/migrating_to_09

Copy here:

Libraries

The DSL for library projects is now the same as for application projects. This means that you can create more types of builds and create flavors.
- You can create / configure more build types in the buildTypes container {...}.
- You can create product flavors using the productFlavors container {...}.
- You can create signConfigs using the signConfigs container {...}.

For example, if you have in your library:

 android { debug { } release { } debugSigningConfig { } } 

You would replace it with:

 android { buildTypes { debug { } release { } } signingConfigs { debug { } } } 

Answer 4

Now in android studio 0.5 (perhaps gradle plug-in 0.9 is required) the possibility of product taste has appeared

So, you can effectively burn this DSL now:

 android { buildTypes { debug { } release { } } signingConfigs { debug { } } } 

See: http://tools.android.com/tech-docs/new-build-system/migrating_to_09 And http://tools.android.com/recent/androidstudio050released