Lets say I have the following sourceSets
:
sourceSets {
flavor1 {
assets.srcDirs = ['repo-assets/flavor1']
res.srcDirs = ['repo-res/flavor1']
}
flavor2 {
assets.srcDirs = ['repo-assets/flavor2']
res.srcDirs = ['repo-res/flavor2']
}
flavor3 {
assets.srcDirs = ['repo-assets/flavor1']
res.srcDirs = ['repo-res/flavor1']
}
flavor4 {
assets.srcDirs = ['repo-assets/flavor2']
res.srcDirs = ['repo-res/flavor2']
}
}
If you notice flavor1
and flavor3
have same srcDirs and so does flavor2
and flavor4
.
Trying Possibility#1
I was trying to figure out if there is a way to avoid the redundancy by using something like this:
sourceSets {
flavor1, flavor3 {
assets.srcDirs = ['repo-assets/flavor1']
res.srcDirs = ['repo-res/flavor1']
}
flavor2, flavor4 {
assets.srcDirs = ['repo-assets/flavor2']
res.srcDirs = ['repo-res/flavor2']
}
}
The above does not work (already tried). Looking for something similar so that i can just provide a common set of sourceDirs
for a set of flavors. Anyone tried doing something similar and can provide some pointers?
Trying Possibility#2
Does the name of sourceSets
need to be same as that of flavors?
Can i name the sourceSets
separately and then map them to productFlavors
like this?
productFlavors {
flavor1 {
sourceset = "src1"
}
flavor2 {
sourceset = "src2"
}
flavor3 {
sourceset = "src1"
}
flavor4 {
sourceset = "src2"
}
}
sourceSets {
src1 {
}
src2 {
}
}
Trying Possibility#3
Can the sourcesets be dynamically assigned via tasks somehow to achieve the same stuff?
UPDATE
Douglas's answer sort of helped me get very close to what i was looking for eventually (reducing the code in build.gradle). He used Possibility#3 above. Thanks Douglas! Any better alternative from bounty hunters is still welcome (something closer to possibilities #1 and #2 above). If nothing comes up the bounty is Douglas's already when the period ends as I've accepted his answer. But still will remain optimistic about finding a better alternative.
You were also pretty close with your first possibility:
The above doesn't look nice in IDEA editor, a lot of warnings are shown. You can set the type if you want to get code completion:
Another trick: this way the definition of the flavor is co-located with the source set listing.
Whichever way you go there's also a noteworthy thing about
srcDirs
, see source:You can define a function to copy flavors (outside of
android {}
):then call this function on source sets:
Of course, it's only worth if you have many flavors, for only two, the overhead of writing a function is greater.
Edit: adding the project structure I used
To simplify and not need to specify flavor1 and flavor2 paths, I used the standard structure for flavors:
values.xml
has a stringapp_name
with content"SourceSets"
formain
,"SourceSets 1"
forflavor1
and"SourceSets 2"
forflavor2
.Just define flavor1 and flavor2 path the standard way and copy them later using the function provided.
Edit 2: Things I tried and probably some would work, but none did here (probably I made some stupid mistake from)
Things I tried and didn't work:
A:
1.
flavor3.root = "flavor1"
2.
flavor3.root = "flavor1/"
3.
flavor3.setRoot("flavor1")
4.
flavor3.setRoot("flavor1/")
These compiled, but the string resource I had defined to test didn't change.
B:
flavor3.root = flavor1.root
This doesn't even compile,
.root
is write-only.C:
flavor3.root = flavor1
This also compiled, but had no effect. Notice it differs from A because in A, the right-hand-side is a string.
D:
I had the idea of
[].each
too, but when I tried it, I probably made some stupid mistake and it didn't work either:The last one I had some hope, but couldn't manage. Then I stuck to the
copyFlavor
function. All above I also tried with prependingsrc
(e.g.,src/flavor1
), unsuccessful.I think what @jmols is trying to say in comments is something like this:
Go from structure
to
and use
See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Project-Structure for
setRoot
and default structure. Here's the source code ofsetRoot
, notice that it resets all customizations, that's why it's crucial to match the default structure. Its built-in call is located here.