[Android] How to build unsigned APK with Gradle 5.x

Help/Discuss
1

To build the unsigned release APK in Android I used signingConfig null in build.gradle as I am using key.properties which is not available on the remote build server.

productFlavors {
    flavor1 {
        signingConfig signingConfigs.release
    }
    flavor2 {
        signingConfig null
    }
}

It worked fine in version 4.x. But starting from version 5.x and above, the following error appeared. Is it possible to somehow resolve this conflict? Or is there another way to build? This solution is pretty old, but now it’s not work.

Caused by: groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method com.android.build.gradle.internal.dsl.ProductFlavor_Decorated#signingConfig.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
    [interface com.android.build.api.dsl.ApkSigningConfig]
    [interface com.android.build.gradle.internal.dsl.InternalSigningConfig]
    [interface com.android.builder.model.SigningConfig]
    at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.lookupMethod(BeanDynamicObject.java:516)
    at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:482)
    at org.gradle.internal.metaobject.BeanDynamicObject.tryInvokeMethod(BeanDynamicObject.java:196)
    at org.gradle.internal.metaobject.CompositeDynamicObject.tryInvokeMethod(CompositeDynamicObject.java:98)
    at org.gradle.internal.extensibility.MixInClosurePropertiesAsMethodsDynamicObject.tryInvokeMethod(MixInClosurePropertiesAsMethodsDynamicObject.java:34)
    at org.gradle.internal.metaobject.ConfigureDelegate.invokeMethod(ConfigureDelegate.java:56)
2

I would say this has nothing to do with updating Gradle, but with updating the Android Gradle plugin, as the error shows.
As the error shows, the method call you do is ambiguous now and before it obviously wasn’t.
Cast the null to a concrete type like null as WhatEver so that Groovy knows which method it should call.

Generally I’d recommend switching to Kotlin DSL, because then you have nice type-safe build scripts and amazing IDE support.

3

It seems doesn’t work:

signingConfig null as com.android.builder.model.SigningConfig

> Ambiguous method overloading for method com.android.build.gradle.internal.dsl.ProductFlavor_Decorated#signingConfig.
  Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
  	[interface com.android.build.api.dsl.ApkSigningConfig]
  	[interface com.android.build.gradle.internal.dsl.InternalSigningConfig]
  	[interface com.android.builder.model.SigningConfig]

I would switch to Kotlin DSL, but Flutter has no support yet.

4

Sorry, was just reading the error message.
I’m not an Android guy and cannot directly help with that unless you provide an MCVE, optimally without needing Android SDK if possible.

But besides that.
You don’t need a plugin to support Kotlin DSL explicitly.
Anything that is possible with Groovy DSL should also be possible with Kotlin DSL.
It might need a bit ugly syntax if it is too deeply depending on Groovy language features,
or you can keep that part in a Groovy script plugin that you then apply from the Kotlin build script.

5

I think this will require the Android SDK as it uses the Android signature mechanism and classes

6

Ah, I just read that Flutter is not a plugin anyway, but a tool that wraps or processes Gradle builds in some bad way, assuming it has build.gradle files, which is bad of course, as even with Groovy DSL the file can have an arbitrary name or even be absent completely and it would still be a valid build. But at least according to Flutter incompatible with Android Gradle Kotlin DSL · Issue #33762 · flutter/flutter · GitHub it should be fixed for build.gradle vs. build.gradle.kts as far as I have seen from a very quick look.

7

The solution is to create build.gradle file and add there apply from: "build.gradle.kts" , but it doesn’t work for me for some reason, I get a lot of Unresolved reference: ... in build.gradle.kts

8

That’s a pretty naive and bad solution.
You are degrading the build script to a script plugin and in a script plugin there are no generated accessors for applied plugins available, so you get the unresolved references.
You can move your build logic to an included build or buildSrc as precompiled script plugin (there the accessors are available again) and apply it in build.gradle via its id.

Or if Flutter is happy with just having a build.gradle there, configure the build file name to be build.gradle.kts in your settings script and just leave the build.gradle empty. Gradle by default prefers build.gradle as it is the older one if both files are present but you can tell it otherwise and Flutter would maybe be happy.

But actually that ticket said this apply from is just a work-around and the issue should be fixed in latest version and you should open a new issue with the output of some command if it does not work.

9

Probably it parses not only the file name, but also the file itself, so there is no solution yet to apply Kotlin DSL.

10

If it parses the file, how would that work-around then ever have worked?
And again, the comments say that the issue should be fixed, so create an issue if it doesn’t work for you or they are not able to fix it. :wink: