Library do support product flavors.
However they publish a full variant, so it'd be flavor1Debug,
flavor1Release, flavor2Debug, flavor2Release.
It makes it complicated to have an app project and a lib project with the
same flavors and have the proper dependency.
You'd want to write:
dependency {
compile project(':lib')
}
and have it take care of things, but it doesn't work yet (there is some
ongoing work to make it happen).
So you end up having to do (in your app project):
configurations {
flavor1DebugCompile
flavor1ReleaseCompile
flavor2DebugCompile
flavor2ReleaseCompile
}
android {
// ... define flavor1, flavor2
}
dependencies {
flavor1DebugCompile project(path: ':lib', configuration:
'flavor1DebugCompile')
flavor1ReleaseCompile project(path: ':lib', configuration:
'flavor1ReleaseCompile')
flavor2DebugCompile project(path: ':lib', configuration:
'flavor2DebugCompile')
flavor2ReleaseCompile project(path: ':lib', configuration:
'flavor2ReleaseCompile')
}
A few notes:
- In your library project, on top of declaring the same flavor, you'll want
to use publishNonDefault = true to publish all variants.
- In your app project you have to manually declare the configuration
objects first due to a timing issue. Normally as Build Types, and Product
Flavors are read from build.gradle we create matching configuration object,
allowing you do to things like 'debugCompile ....'
However, the variants, created from the build types + flavors, are
processed after the whole build.gradle file is parsed/executed. This means
that the dependencies block is processed before the variants have been
created, and before the variant-specific configuration have been created.
Since we only create them if they don't already exist, you can preemptively
create them and it'll work.
Obviously this is not great. Pretty ugly I'd say even. And it doesn't scale
well with more flavors, or even 2+ dimensions of flavors.
On Wed, Feb 18, 2015 at 10:54 AM, Artem Zinnatullin <
artem.zinnatul...@gmail.com> wrote:
> You can build different types of your dependencies to binary artefacts and
> include different versions in main project using product flavored
> dependency (or buildType)
>
> For example:
>
> main_project build.gradle:
>
> android {
> productFlavors {
> flavor1
> flavor2
> }
> }
>
> dependencies {
> flavor1Compile 'dependencyVersionForFlavor1'
> flavor2Compile 'dependencyVersionForFlavor2'
> }
>
> But as I know library projects don't support product flavors
>
> On Wednesday, February 18, 2015 at 9:02:25 PM UTC+3, Greg Macdonald wrote:
>>
>> Thanks, Artem
>>
>> That makes sense and surely it is a good use case.
>>
>> In our case, we need all modules to be built with the same build variant.
>> It makes more sense to me that dependencies included as pre-built artifacts
>> will come in as release built modules, but for sub-projects that are built
>> as part of building the app, it makes sense that this is code also under
>> development and when I want the app to be built with a particular build
>> target and flavor, I should have the option of this being applied to those
>> modules also. The fact that it does not work this way by default is odd to
>> me. I'm pretty sure that other IDE's I've used for different compiled
>> languages all work this way.
>>
>> thanks,
>> greg
>>
>> On Wed, Feb 18, 2015 at 8:39 AM, Artem Zinnatullin <artem.zi...@gmail.com
>> > wrote:
>>
>>> Greg, I am really sorry for my first reply to your post, please accept
>>> my apologies :(
>>>
>>> It's design of Gradle: build of one project should not affect build
>>> state of other projects involved in build process.
>>>
>>> Library subproject should not know about build params of main project,
>>> because you should be able to replace it as already built artefact.
>>>
>>> But you can try to share some pieces of Gradle configuration between
>>> projects, for example you can declare some variables in root build.gradle
>>> like this: project.ext { someVar }
>>> and then read it in subproject: project.someVar, it can help with flavor
>>> specific build config fields
>>>
>>> On Wednesday, February 11, 2015 at 9:22:56 PM UTC+3, Greg Macdonald
>>> wrote:
>>>>
>>>> Kevin, what do your numbers 1-5 relate to? esp. 3 & 4
>>>>
>>>> >>...can't necessarily flow the variants up to the libraries...
>>>>
>>>> No, you cannot at all affect the build of sub-projects. Everything but
>>>> your main app project are built as release. So, for example, referencing
>>>> BuildConfig.DEBUG from code gives a different answer from the app project
>>>> than from a subordinate library project.
>>>>
>>>> On Wed, Feb 11, 2015 at 6:11 AM, Kevin Schultz <krsc...@gmail.com>
>>>> wrote:
>>>>
>>>>> I don't understand these points at all.
>>>>>
>>>>> 1) You can maintain Eclipse & AS support at the same time. Back when
>>>>> AS was actually unstable and Eclipse was actually more useful, I
>>>>> maintained
>>>>> both ant & gradle support in our project so that our team could use
>>>>> either.
>>>>> Keep the source structure as Eclipse expects it, and change the sourceSets
>>>>> in the gradle config to match. There are examples of this online.
>>>>>
>>>>> Of course, you will quickly find that all the power of Gradle is lost
>>>>> if you handcuff yourself to only features that also work under Ant. I made
>>>>> it such that you could build a debug build with Ant, but if you wanted the
>>>>> other build types, you had to use Gradle. That allowed the team to
>>>>> continue
>>>>> using the tools they wanted while we experimented with AS. Note that this
>>>>> was fall of 2013. Our team of 5 Android developers switched relatively
>>>>> soon
>>>>> their after, and we haven't looked back. I personally use the canary
>>>>> channel of AS, and I may have lost 2 business days to tools problems, out
>>>>> of hundreds and hundreds of days. The productivity gain has more than made
>>>>> up for it. New features may have issues, but generally speaking we're
>>>>> talking about issues with feature that didn't exist in Eclipse + ADT
>>>>> anyway, and that doesn't stop you from getting your work done as you had
>>>>> before.
>>>>>
>>>>> There are very narrow use cases where AS doesn't have the support you
>>>>> need, but outside of native code the argument that "Android Studio is not
>>>>> ready for prime time" doesn't hold any water.
>>>>>
>>>>> 2) Most libraries will work - with the exception of AAR - in Eclipse.
>>>>> However, I can tell you most of the people writing libs are using the
>>>>> modern tools.
>>>>>
>>>>> 3) Yes
>>>>>
>>>>> 4) ?
>>>>>
>>>>> 5) Module support under AS is way better than under Eclipse. It's
>>>>> trivial to add Java or Android library modules to the project and it works
>>>>> quite well. I have split my app into a few different modules and I'm quite
>>>>> happy with it. You can't necessarily flow the variants up to the
>>>>> libraries,
>>>>> but there wasn't even a mechanism for something like build variants in
>>>>> Ant,
>>>>> so I'm not sure I see how that is a knock on Gradle.
>>>>>
>>>>>
>>>>> On Wednesday, February 11, 2015 at 1:10:34 AM UTC-5, Greg Macdonald
>>>>> wrote:
>>>>>>
>>>>>> Thanks, Kiran. We've a long term Android guy on our team who is
>>>>>> experienced with eclipse & ant and our project is yet small; but, yes,
>>>>>> I'm
>>>>>> concerned about switching and I sure don't want to get stuck in an
>>>>>> old-tools world once AS is working well enough and moving forward.
>>>>>>
>>>>>> So, what I hear from you in balance is:
>>>>>> - if one goes back, we all go together
>>>>>> - 3rd party libs may not be maintaining support for eclipse-centered
>>>>>> tools
>>>>>> - ADT support for eclipse may wane (yea, in keeping with comments by
>>>>>> ADT lead)
>>>>>> - Binary repos (I'm thinking this isn't a big deal, isn't maven under
>>>>>> jcenter anyway?)
>>>>>>
>>>>>> BTW, we are also considering turning the project into one monolithic
>>>>>> project for now and breaking it up into sub-projects again when the tools
>>>>>> support it better, but it's hard to maintain discipline around
>>>>>> hierarchical
>>>>>> order and separation in such a world. Alas and alack.
>>>>>>
>>>>>> Thanks again, Kiran
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 10, 2015 at 8:17 PM, Kiran Rao <techie....@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> @Greg,
>>>>>>>
>>>>>>> I think reverting is more difficult because you will have to do
>>>>>>> everything manually. While there is a migration path (and tooling
>>>>>>> support)
>>>>>>> for "converting" your project from Eclipse to Android Studio, there is
>>>>>>> no
>>>>>>> support for the opposite.
>>>>>>>
>>>>>>> You will find documentation on how you can make some adjustments to
>>>>>>> the sourceSets in build.gradle such that the same project can be worked
>>>>>>> on
>>>>>>> from both AS and Eclipse + ADT - however in practice this doesn't work
>>>>>>> well
>>>>>>> (and I have tried this on a team of only two developers!)
>>>>>>>
>>>>>>> I have also found that of late, most open source libraries use the
>>>>>>> AS/Gradle structure. You could of course grab the dependencies as
>>>>>>> binaries,
>>>>>>> or better, use Maven with your Eclipse/ADT setup. But then again,
>>>>>>> several
>>>>>>> libraries are distributed as AARs and last time I checked, Eclipse/ADT
>>>>>>> had
>>>>>>> trouble consuming AARs (at least Eclipse/ADT without Maven plugins did).
>>>>>>>
>>>>>>> What I'm trying to arrive at is that reverting to Eclipse might
>>>>>>> imply reduced support going forward - both from the Tools team as well
>>>>>>> as
>>>>>>> from the community.
>>>>>>>
>>>>>>> On Wednesday, 11 February 2015 06:56:18 UTC+5:30, Greg Macdonald
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> OK, I should add to 'factual', input that is useful. I'm really
>>>>>>>> not interested in religious wars or 'tude.
>>>>>>>>
>>>>>>>> On Tue, Feb 10, 2015 at 5:20 PM, Artem Zinnatullin <
>>>>>>>> artem.zi...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> nano + javac is better choice for your team.
>>>>>>>>>
>>>>>>>>> For what reason you want to use flavors in not app modules? Seems
>>>>>>>>> to be architect/design problem.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> P.S.
>>>>>>>>>
>>>>>>>>> Gradle is stable, working build tool, Android Gradle Plugin and
>>>>>>>>> Android Studio are stable too, just fix dependecies versions. I
>>>>>>>>> started to
>>>>>>>>> use them from first public releases and I even changed 3 companies
>>>>>>>>> after
>>>>>>>>> this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I just can't understand why people use Ant in 2015, okay, you
>>>>>>>>> don't want to use Gradle, but there is Maven. It's just unwillingness
>>>>>>>>> to
>>>>>>>>> learn new things, and in my opinion — it's unprofessional.
>>>>>>>>>
>>>>>>>>> Learning new should not be hard, it should be fun and useful for
>>>>>>>>> yourself.
>>>>>>>>>
>>>>>>>>> Just start with small personal project with Android Studio and
>>>>>>>>> Gradle, when you'll feel comfortable with them, try to switch work
>>>>>>>>> project
>>>>>>>>> to Gradle + AS.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> 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/d/optout.
>>>>>>>
>>>>>>
>>>>>> --
>>>>> 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/d/optout.
>>>>>
>>>>
>>>> --
>>> 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/d/optout.
>>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com
Please do not send me questions directly. Thanks!
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
