The use case that was in mind when developing the "build type" concept was debug vs. release: debug may have extra runtime checking code, it won't use Proguard, it will be debuggable in the IDE, and it will be signed with the debug key, but it's usually functionally equivalent to the other build types (e.g. Release).
With flavors, the intent was different versions of the app which are functionally different even in release versions: free vs. paid, perhaps something like an enterprise version vs. consumer version, etc. Having said that, you can of course do what makes sense to you, and in practice build types and flavors are similar concepts and allow similar types of configuration. But if you find yourself wanting to have sub-flavors inside flavors, it might help to take a step back and look at what you're doing to see if there's an easier way. You talk about a "predefined set of preferences" that differ in some of your sub-flavors; perhaps you could differentiate these via runtime configuration instead of making separate variants. If you have too many build variants, it will make your development and testing really tough as the number of combinations explodes. You'll help yourself out by restricting flavors to cases where the code or resources really need to be different, and making the decision at runtime just really doesn't work. When you're running the Gradle commands from the command line, you can specify which variant they act on. Instead of: ./gradlew assemble you can use: ./gradlew assembleFlavor1Debug etc. You can see the possibilities via: ./gradlew tasks On Fri, Feb 28, 2014 at 9:14 AM, Diego Costantini < [email protected]> wrote: > The question seems very generic but I have a concrete (corner?) case in > mind. > > I have 3 flavors and I test them in Jenkins with some default settings > which are good for us developers. > However, when I want to release them, I want different preferences for the > user, sometimes even more than one kind per flavor. > For this, I created different buildTypes, let's say for example that I > want Flavor1-ReleaseFlavor1 where I use a predefined set of preferences. > In this case, the build type ReleaseFlavor1 is specific to Flavor1, and > when generating the tasks, I would have many meaningless combinations like > Flavor2-ReleaseFlavor1. > > Now, related to the topic question: > - is it ok and I should just ignore those builds when running assemble? -> > big waste of time waiting for the extra meaningless builds > - should I avoid running assemble? -> I lose a quick way to build all the > variants I might need > - is there a way to filter out undesired combinations? -> this would make > sense > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
