Android Studio: Is creation of a signing configuration necessary when creating a custom build type?

Question

I have created custom buildTypes as follows and am not using the default debug and release buildTypes

buildTypes {
        releasefree {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        releasepro {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            applicationIdSuffix ".pro"
        }
        debugfree {
            shrinkResources true
            applicationIdSuffix ".debug"
            debuggable true
        }
        debugpro {
            shrinkResources true
            applicationIdSuffix ".pro.debug"
            debuggable true
        }
    }

Reason for doing this: I have several productFlavors and need to have a PRO version for each and I felt this was easier than creating a seperate PRO flavor for each free one. My code handles the difference using APPLICATION_ID from BuildConfig class. Another reason is i have customized classes and will need to replicate twice if i have two separate flavors. I know i can configure sourcesets, but I've had problems with that when i have too many flavors. Very difficult to track.

Now the issue: When i try to run the application using a custom buildType build variant, it asks me to create a signing configuration for each custom build type.

Similarly i see a message in the Run console when executing:

Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]

Installation failed since the APK was either not signed, or signed incorrectly. If this is a Gradle-based project, then make sure the signing configuration is specified in the Gradle build script.

I understand that it may be required. But, what I was trying to find out was: Is there a setting what i could change so that the debugfree and debugpro buildTypes I've created could bypass the signing configuration requirement just like the default debug buildType? I know creating a signing configuration is a one minute thing and I'll do it if i do not get something soon. But just out of curiosity I want to understand what needs to be done to make the custom buildType work like the default debug buildType and not require a signing configuration.

Tried setting

debuggable true

(which was the only difference in the properties of th default debug buildType and my custom debug buildType) hoping it would work like the default debug buildType, but did not. What else need to be changed for the custom buildType to work like the default one i.e. not require a signing configuration.

"I have several productFlavors and need to have a PRO version for each and I felt this was easier than creating a seperate PRO flavor for each free one" -- I certainly wouldn't recommend that. "not require a signing configuration" -- all build types require a signing configuration. It just so happens that `debug` comes with one pre-defined. Try `debugfree.initWith(buildTypes.debug)` and `debugpro.initWith(buildTypes.debug)` before your `debugfree` and `debugpro` closures inside the `buildTypes` closure. — CommonsWare, Dec 05 '15 at 21:50
Excellent @CommonsWare that made it work as expected. Appreciate the help. :-) — Viral Patel, Dec 05 '15 at 22:00

score 4 · Accepted Answer · answered Dec 05 '15 at 22:04

4

Build types don't have strict inheritance. However, you can use what amounts to a copy constructor:

debugfree.initWith(buildTypes.debug)

where debugfree is a build type that you want to define, and debug is the build type you want to copy from.

Do this before the rest of the initialization of the new build type (otherwise, initFrom() may wipe out parts of that initialization).

In particular, since debug has a signing configuration already set up, starting a new build type by initializing from debug uses that same debug signing configuration.

However, be very very careful when using the debug build type as a starting point. You don't want to accidentally wind up trying to ship apps with that debug signing configuration.

answered Dec 05 '15 at 22:04

CommonsWare

986,068
189
2,389
2,491

1

can the same thing be done with `productFlavors` and `sourceSets` ? – Viral Patel Mar 24 '16 at 11:51
@AndroidMechanic: I am not quite certain what you are referring to as "the same thing". If you mean the copy constructor, there's probably a way of doing that, though I haven't done it personally. You might consider asking a fresh Stack Overflow question outlining your concerns in greater detail. – CommonsWare Mar 24 '16 at 11:56
yes, I meant creating a copy constructor with `initWith`. It was just a query hence did not post a question. Should i be posting a new question for a small thing like that? – Viral Patel Mar 24 '16 at 11:57
@AndroidMechanic: Sure! Stack Overflow isn't going to break because of one additional short question. And, even if it does, it really wasn't your fault anyway. :-) – CommonsWare Mar 24 '16 at 11:58
done sir :) http://stackoverflow.com/questions/36199741/copy-constructor-using-initwith-for-productflavors-and-sourcesets – Viral Patel Mar 24 '16 at 12:04

Viral Patel · Answer 2 · 2015-12-05T22:08:16.590

Based on @CommonsWare 's comment on my question above, I changed the buildTypes as follows and it worked like a charm. Needed to initialize the custom buildType with the default buildType before adding custom configuration. Did it for debug as well as release custom types and that did the trick.

Posting it here again, in case some curious soul like me could benefit from this.

buildTypes {
    releasefree.initWith(buildTypes.release)
    releasefree {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
    releasepro.initWith(buildTypes.release)
    releasepro {
        minifyEnabled true
        shrinkResources true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        applicationIdSuffix ".pro"
    }
    debugfree.initWith(buildTypes.debug)
    debugfree {
        shrinkResources true
        applicationIdSuffix ".debug"
        debuggable true
    }
    debugpro.initWith(buildTypes.debug)
    debugpro {
        shrinkResources true
        applicationIdSuffix ".pro.debug"
        debuggable true
    }
}

Android Studio: Is creation of a signing configuration necessary when creating a custom build type?

2 Answers2

Linked