What is the proper way to use build variants?

[Diego Costantini]

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

[Scott Barta]

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

--
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/groups/opt_out.

[Diego Costantini]

Thanks Scott,
I know I can run the specific task (it was my second bullet point).

And I see your point in combination explosion. I actually first considered these settings differences as flavors, but I noticed that it would be just a small bunch of xml files on top of a lot of common code, so they were orthogonal to the flavors, also because they "could" be used across different flavors.

However, as you said, I am creating complexity and I am not going to test all of them because such settings don't require tests in my opinion.

As a simplified example, flavor1 might be assembled:
1 - with autoUpdate setting visible and disabled (dev)

2 - with autoUpdate setting visible and enabled (demo)

3 - with autoUpdate setting invisible and enabled (customer)

In this case I planned to use debug, debugDemo, release buildTypes.

But debugDemo does not apply to Flavor2.

Would you have any pointer to achieve this with runtime configuration?

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/Z26wxPc7OKs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Scott Barta]

3 seems like something that's appropriate for the release build type. 1 and 2 seem like they could be differentiated by configuration. I don't know what the "demo" use case is (it could be anything from "showing around the office" to "unattended demo at a trade show kiosk"), but it could be a preference, or a menu command that lets you flip between modes, or you could prepare the device after installation by issuing an ADB command to change a value in the Sqlite database, or by dropping a configuration file somewhere in the filesystem.

If that seems like it may work, see if you can use the same mechanism to collapse 1/2 and 3 -- in the absence of the file or Sqlite value it defaults to behavior 3, and can be configured to 1 or 2 on the device. You'll have some amount of security by obscurity if users don't know how to get to 1 or 2, and it depends on whether it's a problem if they find out.

Ultimately it's up to you, and it wouldn't be hard to set up a 2-3 build types for your use cases here, but I'd encourage you to find answers outside the build system first -- don't use a crowbar if all you need is a screwdriver. If you have two flavors and three build types there are six combinations to build, test (there will be *some* manual testing), and distribute. That's a lot more opportunities for things to go wrong.

[Xavier Ducrohet]

The next version of the plugin will have support for filtering out combination that don't make sense (in your case flavor2 + debugDemo)

Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Jake Wharton]

On Fri, Feb 28, 2014 at 10:27 AM, Xavier Ducrohet <x...@android.com> wrote:

The next version of the plugin will have support for filtering out combination that don't make sense (in your case flavor2 + debugDemo)

Yesssssssssssss! Many thanks in advance.

[Diego Costantini]

In such case, I'll stop bothering and I will filter out when it comes.
In the meanwhile, thanks Xavier and thanks Scott :)

Sent from my Nexus 4