Streamlining Android Development: Achieving Continuous Integration with Jenkins

• Update every single one of your existing apps to use the new build tools.  Easy if you’re a flexible, small development team.  No thanks if this is an enterprise platform supporting lots and lots of applications and lots and lots of different development teams.

• Get the zipalign binary added back into the main SDK tools folder.

cp -p ./build-tools-r21.1.2/android-5.0.1/zipalign %{RPM_BUILD_ROOT}/destination/on/server/android-sdk-linux/tools/

No, you can’t share the signing key with the rest of the team.

Your signing key can be used as a trust identifier in application code, particularly amongst separate integrated apps, so its security is a big deal.  I’ve heard of lots of development shops where the team’s signing key is committed to version control with passwords embedded in build scripts or where the key lives unprotected on the local machine of the team’s development lead.  We’ve found that securing the signing key and configuration on build servers provides a good balance between maintainability and security, with little impact to your development team.

Tip 4: Inject your Signing Configuration, and Make it Optional

1. Keep our signing configurations secure
2. Make sure the signing configuration is used for each release build
3. Reduce any impact on the development team from a process standpoint

// apply the signing configuration, if provided
if (project.hasProperty("build_signingConfig")
&& new File(project.build_signingConfig).exists()) {
logger.debug("[SIGNING CONFIG] Applying signing configuration to release builds from: " + project.build_signingConfig);
apply from: project.build_signingConfig;
}

android {
     signingConfigs {
          release {
               storeFile file(“/path/to/signing/configuration.jks")
               storePassword "${System.env.KEYSTORE_PW}"
               keyAlias “alias"
               keyPassword “${System.env.ALIAS_PW}"
          }
     }
}

Where the <bleep> did this APK come from?

Most of our large clients maintain a sizable portfolio of different internal applications.  Each of these applications is owned by a different team with a different set of developers.  However, there are almost always central support, app distribution, and release management teams, and these teams need some way of tracking where a given production artifact may have come from.

Tip 5: Embed build info directly in your release APKs

//add CI build meta data to the manifest, if available from env
if (System.getenv("BUILD_TAG") && System.getenv("SVN_REVISION") && System.getenv("SVN_URL")) {
    android.applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.processManifest.doLast {
                copy {
                    from("${buildDir}/intermediates/manifests/full") {
                        include "${variant.dirName}/AndroidManifest.xml"
                    }
                    into("${buildDir}/intermediates/filtered_manifests")
                }

                def manifestFile = new File("${buildDir}/intermediates/filtered_manifests/${variant.dirName}/AndroidManifest.xml")
                def content = manifestFile.getText()
                def buildTag = System.getenv("BUILD_TAG");
                def svnRev = System.getenv("SVN_REVISION");
                def svnUrl = System.getenv("SVN_URL");
                def updatedContent = content.replaceAll("", "");
                manifestFile.write(updatedContent)
            }
            output.processResources.manifestFile = new File("${buildDir}/intermediates/filtered_manifests/${variant.dirName}/AndroidManifest.xml")
        }
    }
}

Who forgot to increment the version Code?

Tip 6: Externalize your Application Version and Auto-Increment on Release

## Version name will get injected into the AndroidManifest.xml file at build time. 
## The version code will be derived. 
## Must match MAJOR.MINOR.RELEASE format.
artifact_version=1.0.0

android {
    ...
    defaultConfig {
        ...
        versionCode buildVersionCode(artifact_version)
        versionName artifact_version
    }
    ...    
}

gradle.allprojects {
    ext.buildVersionCode = { version ->
        def majorMinorBuild = version.tokenize(".")
        def vCode = 0;
        def powerOfTen = 1;
        majorMinorBuild.reverse().eachWithIndex() { obj, i -> (vCode += (obj.toInteger() * powerOfTen)); powerOfTen *= 1000; }

        logger.info("Build version code [" + vCode + "] from version name [" + version + "].")

        return vCode;
    }
}

task increaseVersion << {
    logger.debug(":increaseVersion - Incrementing Package and Manifest Version...")
    def propsFile = file("../gradle.properties")
    def propsText = propsFile.getText()

    def patternVersionNumber = Pattern.compile("artifact_version=(\\d+)\\.(\\d+)\\.(\\d+)")
    def matcherVersionNumber = patternVersionNumber.matcher(propsText)
    matcherVersionNumber.find()
    def majorVersion = Integer.parseInt(matcherVersionNumber.group(1))
    def minorVersion = Integer.parseInt(matcherVersionNumber.group(2))
    def buildVersion = Integer.parseInt(matcherVersionNumber.group(3))
    propsText = matcherVersionNumber.replaceAll("artifact_version=" + majorVersion + "." + minorVersion + "." + ++buildVersion)
    propsFile.write(propsText)
}

Note that you’ll still need to invoke a shell script or use a VCS plugin afterward to commit the updated gradle.properties file back to version control.

Next Steps

• Using the Jenkins Android plugin with a headless emulator to execute instrument tests
• Connecting Jacoco test coverage in Android with Sonar
• Direct deployment from Jenkins through a distribution platform like Airwatch, Crashlytics Beta, etc.
• Bundling my common Gradle scripts into a plugin that can be referenced as a build script dependency