1. I'n not sure how a single buildConfigField is boiler plate. 2. the priority order if explained in the guide and applies to everything (resources, manifest overlays) It's Build Type > Flavors > default Config.
So if you set the same buildConfigField in all 3, the build type will win, always 3. This is not currently supported. You cannot have per-variant values. We take a combination of build type, flavors, defaultconfig and take the highest priority one. It's something we want to fix but no ETA. On Sat, Nov 15, 2014 at 10:15 AM, Daniele Segato <[email protected]> wrote: > Thank you Mark. > > What I want is just a way to define buildField values more flexible > choosing the value by flavor / build type. > > I want to be able to set those values differently for every combination of > flavor and build type, possibly setting a default if I do not want to > override. > > The reason I want this are 3: > 1. having to set those value over and over again for each variant is > tedious and create lot of boilerplate code > 2. it is not straightforward to me how defaultConfig, variant config and > build type config relate with each other, if I set the same variable as > build config in all of them which is applied? the variant one? the build > one? > 3. I don't know how to have 4 different value for the combo free+debug, > free+release, pay+debug, pay+release (to simplify I just used 2 variant and > 2 build types as an example) > > Your message helped me understand better how gradle works, I still didn't > get it very well. > Now I understand all those setting are in evaluated in a phase that do not > yet have anything to do with the actual compile of a single variant. And > the code they contains is executed regardless of which variant I build. > But I still don't have any idea on how to solve the 3 things I wrote about > above. > > Thanks, > Daniele > > > On Saturday, November 15, 2014 6:49:18 PM UTC+1, Mark Murphy (a Commons > Guy) wrote: >> >> On Sat, Nov 15, 2014, at 12:34, Daniele Segato wrote: >> > Meaning theres no way to do what I want yet? >> >> If by "what I want" you mean "obtain the 'current' flavor", then no, >> there is no way to do what you want, other than by iterating yourself >> over build variants. >> >> The only time there is a "current" anything is inside a task. Tasks are >> things executed when we actually do the build. Stuff like productFlavors >> {} and buildTypes{} are more along the lines of data structures, where >> any Groovy code is executed when the script is read in. >> >> Now, you can certainly define your own tasks, and those tasks can be >> specific per build variant. You can set up those tasks to depend upon >> some other task, and (presumably) you can configure other built-in tasks >> to depend upon yours. Whether you can affect buildConfigField this way >> and accomplish your aims, I cannot say. And how well this will hold up >> over time, as Gradle for Android evolves, I cannot say. >> >> -- >> Mark Murphy (a Commons Guy) >> http://commonsware.com | http://github.com/commonsguy >> http://commonsware.com/blog | http://twitter.com/commonsguy >> >> _The Busy Coder's Guide to Android Development_ Version 6.1: Wear? >> There! >> > -- > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
