0.7 ignores renamed flavour output name

[Bananeweizen]

We rename the output file in one flavour, see lines 202 and following of this build script. This worked well up to 0.6.4. Since 0.7.0, the dexcount invocation looks for the original (non renamed) output file, thereby breaking the build:

* What went wrong:
A problem was found with the configuration of task ':main:countBasicDebugDexMethods'.
> File '/home/jenkins/slave/workspace/cgeo continuous integration/main/build/outputs/apk/cgeo-basic-debug.apk' specified for property 'inputFile' does not exist.

[benjamin-bader]

Good to know - thanks for the report!

[vanniktech]

You shouldn't do it like that. There's an archieveBasename property which you can use.

[benjamin-bader]

That's true, and the linked script will fail hard on upgrade to Android Studio 3, but in the meantime this is something we can likely fix very easily.

Be that as it may, archiveBasename (or whatever it's called) is definitely the right way forward.

[jp1017]

same issue of 0.7.0 . 😭

[Bananeweizen]

Can I really use archivesBasename to modify the output of a single build type (and not for all build types together)?

And why do you think that renaming the output will no longer work at all in android-gradle 3.0? Reading https://developer.android.com/studio/preview/features/new-android-plugin-migration.html#variant_api I would expect that our build script just needs to use all() instead of each(), since the given example is very similar to what we do. Or did I miss something here?

I will experiment a bit with the given example code and the 3.0 plugin, to maybe find a workaround on our side.

[benjamin-bader]

And why do you think that renaming the output will no longer work at all in android-gradle 3.0? Reading https://developer.android.com/studio/preview/features/new-android-plugin-migration.html#variant_api I would expect that our build script just needs to use all() instead of each(), since the given example is very similar to what we do. Or did I miss something here?

Because your script invokes output.outputFile, which (at least in alpha1 and alpha3) just throws a runtime exception. outputFileName is a separate property, though its name makes that fact easy to overlook.

I think I must have misunderstood your use case; I haven't ever tried that with archiveBasename. outputFileName, from the link you posted, seems like it would work.

[benjamin-bader]

FYI, I've just released version 0.7.1, which fixes this issue.

[jp1017]

@benjamin-bader great job, 0.7.1 works perfect. 👍 😄