Android Studio Gradle First Steps

Question

As some may have watched the Android Studio Gradle i/o, Xavier Ducrohet mentioned in his fast speech how to use the android gradle build system. My problem is, that the documentation and the presentation lack information of getting a fast start. or at least for me. In my following code i've tried to solve the usage of the gradle android plugin system and im sure i've got some steps wrong and some right. (i haven't used ant or maven a lot)

Maybe i'll go through it step by step with what i've done so far.

android {
    compileSdkVersion 17
    buildToolsVersion "17.0.0"

    defaultConfig {
        minSdkVersion 7
        targetSdkVersion 16

        signingStoreLocation = "debug.keystore"
        signingStorePassword = "***************"
        signingKeyAlias = "***************"
        signingKeyPassword = "**************"
    }

At first im configuring the default settings for the debug build (or every build that uses default settings..that means no buildtypes or flavors?)

sourceSets:

    sourceSets {

        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject']
            res.srcDirs = ['res', 'resfromotherprojectusingpartsofsamecode']
            assets.srcDirs = ['assets']
        }
    }

In this step i've defined the sourceSets. This is where i've got my first question. If i've got the same code i want to use for two projects, is it possible/or should it be done defining more sourcesets like -->

    sourceSets {

        main {...}
        srcsetforanotherproject {...}
    }

...depending on the underlying src folders? Or should the definition for sourceSets be done like in my first sourceSets declaration, by defining a set of different, e.g res folders, like Xavier Ducrohet mentioned? (Its also not clear if i can only do this for res folders in this manner or also for the java src code folders like java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject'].

signingConfigs:

    signingConfigs {
        debugRelease {
            storeFile file("debug.keystore")
        }

        release {
            storeFile file("release.keystore")
        }

        testflight {
            storeFile file("testflight.keystore")
        }
    }

In this step i've defined the different keys using for different releases. should be alright...

buildTypes:

    buildTypes {

        debugRelease.initWith(buildTypes.release)
        testflight.initWith(buildTypes.release)

        sourceSets.debugRelease.setRoot("src/release")
        sourceSets.debugRelease.setRoot("src/release")
        sourceSets.debugRelease.setRoot("src/release")

        debugRelease {
            packageNameSuffix ".debugRelease"
            versionNameSuffix "-DEBUG"
            debuggable true
            signingConfig signingConfigs.debug
        }

        testflight {
            packageNameSuffix ".testflight"
            versionNameSuffix "-TESTFLIGHT"
            signingConfig signingConfigs.testflight
        }

        release {
            packageNameSuffix ".release"
            versionNameSuffix "-RELEASE"
            runProguard true
            proguardFile getDefaultProguardFile('proguard-android.txt')
            signingConfig signingConfigs.release
        }
    }

This step was more clearly explained than any other step for the gradle android plugin. Except that i don't know if there is a predefined release or debug setting working in the background...do i need to clarify it anyway...at least i think so, because of the use of namesuffixes, proguard or declaring a key to this build (signingConfig).

Flavors:

    flavorGroups "abi", "version"

    productFlavors {

        arm {
            flavorGroup "abi"
        }

        standardproject1 {
            flavorGroup "version"
            minSdkVersion 7
            targetSdkVersion 14
            packageName "com.project.maingradle.normal"
            sourceSet sourceSets.main
        }

        standardproject2 {
            flavorGroup "version"
            minSdkVersion 6
            targetSdkVersion 14
            packageName "com.otherproject.normal"
            sourceSet sourceSets.main
        }

        testflightproject1 {
            flavorGroup "version"
            minSdkVersion 7
            targetSdkVersion 14
            packageName "com.project.maingradle.testflight"
            sourceSet sourceSets.main
        }

        testflightproject2 {
            flavorGroup "version"
            minSdkVersion 6
            targetSdkVersion 14
            packageName "com.otherproject.testflight"
            sourceSet sourceSets.main
        }
    }
}

Personally i think that flavors are the most interesting part. Xavier Ducrohet said that you shouldn't define a key in a buildtype (instead declared in flavors) if you want to use different keys for different flavor builds? i don't know if i understood that correctly.

Anyway...what i was trying to do here is defining different flavors that should be build with different settings like, sdk versioning for different systems, an exclusive packagename and setting a depending sourceset like you see in the example. what im not sure about is, how the buildtypes depend on flavors...do they just multiply every flavor to every buildtype? And...is it ok to set a sourceSet (if it is possible to set more sourceSets), like this in a flavor?

Answer 1

How the buildtypes depend on flavors...do they just multiply every flavor to every buildtype?

Yes, Gradle will generate every combination of build types and product flavors. As per the Gradle Plugin User Guide, each build type and product flavor combination is referred to as a build variant.

Is it ok to set a sourceSet (if it is possible to set more sourceSets), like this in a flavor?

Sure! Product Flavors (and Build Variants) also automatically include their own sourcesets from src/myFlavorName, as per the Sourcesets and Dependencies documentation.