23

I've got a project where I have several device-specific product flavors, and each flavor needs to be signed with a different config: 

productFlavors {
    nexus7 {
        signingConfig signingConfigs.nexus7
    }
    nexus4 {
        signingConfig signingConfigs.nexus4
   }
}

This works great when building a 'release' variant. However, when using a 'debug' variant (e.g. when I build Nexus4Debug), Gradle is using the default android debug key. In my case, I'm highly dependent on these builds being signed the right way, and my application is relatively useless if signed with the default debug key. Anyone know if there's a way to specify the signing config for each variant?

I know I can do it per build type, a la: 

buildTypes {
    debug {
        signingConfig signingConfigs.nexus4
    }
}

but this limits me to always using the same signing config for debug builds of both flavors.

PS - Understand this is a little bit of an edge use case here. This is for an enterprise project where we're testing custom ROMs and system-signed apps on a number of different Nexus devices.

MJMWahoo06
  • 258
  • 2
  • 8
  • 2
    I would love to know if there is a way to have a *variant-specific* signing key as well. – dcow Jan 14 '14 at 19:25

5 Answers5

13

Try adding this to your build.gradle. It will specify which signingConfig to use for each flavor when building the debug build type:

buildTypes {
    debug {
        productFlavors.nexus4.signingConfig signingConfigs.nexus4
        productFlavors.nexus7.signingConfig signingConfigs.nexus7
    }
}
Richard Le Mesurier
  • 29,432
  • 22
  • 140
  • 255
Rafael Slobodian
  • 418
  • 5
  • 7
  • @MJMWahoo06 can you please mark as answered if it worked for you? Thanks :) – Rafael Slobodian Nov 10 '14 at 20:42
  • 4
    This answer doesn't seem to work on the latest android plugin build. 1.1.3 – spierce7 Apr 14 '15 at 03:43
  • seems to work fine in Gradle 2.4. I use it in my build file as per this solution: [Gradle signing flavors with different keys on Android](http://stackoverflow.com/a/31433544/383414). – Richard Le Mesurier Jul 15 '15 at 14:51
  • 2
    this is so useful for combining build variants with flavours. Note, you'll need to make sure you define your flavours before your buildTypes in the build.gradle. – Matthew Trout Mar 09 '17 at 10:22
  • as @MatthewTrout emphasized it will not build if flavors are not defined before buildTypes – Ewoks May 31 '17 at 12:13
  • 2
    this basically says all nexus4 flavors should be signed with signingConfigs.nexus4 (not just debug, but ALL including release).. Than it does same for nexus7.. – Ewoks Jun 02 '17 at 06:58
8

I got another solution after android plugin build. 1.1.3

productFlavors {
    nexus7 {
        signingConfig signingConfigs.nexus7
    }
    nexus4 {
        signingConfig signingConfigs.nexus4
    }
}
buildTypes {
    release {
        debuggable false
        zipAlignEnabled true
    }
    debug {
        initWith release
        debuggable true
        zipAlignEnabled false
    }
}

As build type "release" will use flavor signing config (as there is no specification), after debug init with release build, it will also has the same signing config.

Build type "debug" needs to be init with "release" as if signing config is not provided, it will use Android default debug signing key.

Update

The problem is that android.buildTypes.debug.signingConfig has a default value while release does not.

The solution may be breakage in the future.

Anyway, still work with android plugin build 2.3.2

OnJohn
  • 338
  • 2
  • 9
  • 9
    Thanks for this. It led to me to figure out this: `signingConfig null`. The problem is that android.buildTypes.debug.signingConfig has a default value while release does not. If set, buildType configurations override anything you set in a flavor. The real trick is to unset the property in buildTypes.debug so it will act just like release. – Harvey Nov 04 '15 at 18:20
  • yes, exactly! bad that it is not documented. figured this out this after a day try and error. Hope this answer help the others too :D – OnJohn Nov 17 '15 at 02:45
  • You should update your answer to show this. Your solution is clever, but prone to breakage in the future. – Harvey Nov 18 '15 at 16:22
  • 1
    Harvey, you should probably post your comment as an answer, as it still works.., – Tony BenBrahim Dec 09 '16 at 09:26
  • 1
    @Harvey After all this time looking for the solution using signingConfig null finally worked. I also just recently figured out that the debug mode is signed by androiddebug keystore by looking into the signature of the debug apk using jarsigner. – Sabin Bajracharya May 21 '20 at 15:36
4

Works on 2.2.1

buildTypes {
    release {
    }
    debug {
        signingConfig android.buildTypes.release.signingConfig
    }
}
Pingan Yi
  • 103
  • 1
  • 2
1

The answer is:

buildTypes {
    debug {
        signingConfig null
    }
}

It's quitely hidden in @Harvey's comment and it takes me too much time to find it. I think it's better to leave it as an answer.

You can find the comment and give it the thumbs-up if it works for you as well.

Thanks for this. It led to me to figure out this: signingConfig null. The problem is that android.buildTypes.debug.signingConfig has a default value while release does not. If set, buildType configurations override anything you set in a flavor. The real trick is to unset the property in buildTypes.debug so it will act just like release. – Harvey

Kevin
  • 139
  • 6
0

This may work:

buildTypes {
  release {
     productFlavors.nexus7.signingConfig signingConfigs.nexus7
     productFlavors.nexus4.signingConfig signingConfigs.nexus4
  }
  debug {
     signingConfig android.buildTypes.release.signingConfig
  }
}
Antoine
  • 1,393
  • 4
  • 20
  • 26
LeeShanxin
  • 1