NBAndroid Gradle: Run->Test Project starts incorrect Gradle task when using flavours

[Rob Smith]

When using flavours in an Android Gradle project, NBAndroid's Run->Test Project fails to execute any tests, as the Gradle task name, i.e. target, is invalid.

Executing: gradle assembleDebug assembleDebugTest


FAILURE: Build failed with an exception.

* What went wrong:
Task 'assembleDebugTest' not found in root project 'HelloFlavours'.

* Try:
Run gradle tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

The task list returned by gradle tasks from the command line confirms that assembleDebugTest is not present. Valid test tasks include the flavour name, e.g. assembleFreeDebugTest to test the free flavour. Note that there are no release build tests, from the empirical evidence.

I have created an example project to illustrate the problem, called HelloFlavours - attached. Please see the enclosed ReadMe file before using it. This project can be successfully compiled, run and tested from the command line as follows:

gradle installFreeDebug installFreeDebugTest
adb shell am instrument -w com.awayteamsoftware.helloflavours.tests/.MyTestRunner

Please fix this. Thank you.

I have encountered a number of issues which I believe are related to this problem and can be demonstrated using the same example project. However, I will raise those as separate items and reference the HelloFlavours project, to give better clarity.

[Rob Smith]

I have now raised my associated issues: #32, #33 and #34, some of which are specific to flavours, and some of which are independent of them.

I suggest you read these 4 issues together before attempting any fixes, as I strongly suspect that there are overlapping problems here, i.e. verifying one valid fix may be blocked by an associated issue.

Please let me know if you need further details, and good luck.

[Radim Kubacki]

Solved 1st part of this problem: now the correct task will be called. Also it will not build all debug versions but only the selected variant.

Next step is to add support for custom test runner (that already exists in Ant-based project).

BTW: your project deserves upgrade to android plugin 0.10. You will be able to use newer Gradle then.

[Rob Smith]

Thanks for the update. Sounds like a good improvement.

In the interim, I've found a workaround by creating project configurations and setting the Gradle task names manually via Window->Projects->Properties->Gradle Project->Manage Built-in Tasks. The Properties->Build Variant option only seems to affect the displayed project structure, which seems counterintuitive to me, but perhaps I've misunderstood.

I'm happy to update my plugins, but thought I already had the latest versions: Gradle Support 1.3.0, NBAndroid Gradle Support 1.243, Android 1.243. Which plugin are you referring to? I assumed that Gradle 1.11 and later was not yet supported by the plugin (it raises an error), which is why I included the 1.10 wrapper support.

[Radim Kubacki]

my update from previous comment is not published yet (will be 1.244+).

As for plugin update: I meant 'android' Gradle plugin applied by your build.gradle. Your project uses 0.8 now and that's why you are stuck with Gradle 1.10. Newer version are less restrictive and android plugin 0.10 works with a range of Gradle versions 1.10 - 1.12.

[Radim Kubacki]

Just uploading 1.245. There can be some problems with persistence of selected BuildVariant and Test Runner choice - those needs to be fixed in Gradle support done by Attila.

[Rob Smith]

Thanks for your support so far. I've updated to v1.246 of the two NBAndroid plugins, and can confirm that the Gradle task is now correct for the default project configuration. However, I do not believe it is correct for the non-default configurations.

The Gradle task name always matches the (only) variant set in Properties->Build Variant, regardless of the project configuration chosen. For example, if two different project configurations are created, they always share the same build variant, as changing the build variant for one config, changes it for the other too.

As I mentioned above, this seems counterintuitive to me. My interim workaround (above) still works, though if this is intended, it seems like a strange design as I would like to create project configs for the four variants - paidDebug, freeDebug, paidRelease and freeRelease.

Also, changing the Build Variant does not update the Window->Project display automatically to show the current flavour. My workaround is to do it manually using Refresh project node with a right-click in that window, but this seems prone to error.

I realise that the remaining problems may be due to Attila's Gradle support. Is this the case, and how should we track it? I'm happy to open another issue here so that we can close it when everything is finally resolved, or label #31 as still in progress.

Please let me know. Thanks.

[Radim Kubacki]

Some clarification of terms: Build Variant is a combination of Product Flavor and Build Type (cf. http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants).

There needs to be only one active Build Variant at a given moment. The reason is that we need to be able to resolve symbols in the project without ambiguity.

You're correct that selected Build Variant is not tied to a selected Gradle project configuration. It can be perceived as a bug or feature. Regardless of that the solution depends on a decision whether NBAndroid should depend on Attila's Gradle plugin and we will fix their collaboration or if we will rewrite Gradle support.

Project structure refresh (or lack of) is a bug. Would you mind to submit it?