mobile/android/gradle/app/build.gradle
author Nick Alexander <nalexander@mozilla.com>
Tue, 27 Oct 2015 17:16:09 -0700
changeset 305211 bf8e162a3580170e5b605385c98a91a4e9f94af2
parent 305207 47c3e7a902e5412ac0cf24ca71dabbfa6a24044c
permissions -rw-r--r--
Bug 1219058 - Part 2: Normalize Robocop test harness source layout. r=gbrown Pretty straight-forward. The win here is that the directory is now sensible, so we don't need the robocop_harness symlink for the Gradle build configuration.

apply plugin: 'com.android.application'

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"

    defaultConfig {
        targetSdkVersion 22
        minSdkVersion 9
        applicationId mozconfig.substs.ANDROID_PACKAGE_NAME
        testApplicationId 'org.mozilla.roboexample.test'
        testInstrumentationRunner 'org.mozilla.gecko.FennecInstrumentationTestRunner'
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_7
        targetCompatibility JavaVersion.VERSION_1_7
    }

    lintOptions {
        abortOnError false
    }

    buildTypes {
        release {
            minifyEnabled true
            proguardFile "${topsrcdir}/mobile/android/config/proguard/proguard.cfg"
        }
    }

    sourceSets {
        main {
            manifest.srcFile "${topobjdir}/mobile/android/base/AndroidManifest.xml"
        }

        androidTest {
            manifest.srcFile "${topobjdir}/build/mobile/robocop/AndroidManifest.xml"
            java {
                srcDir "src/robocop"
                srcDir "src/background"
                srcDir "src/browser"
                srcDir "src/javaaddons"
            }
        }
    }
}

dependencies {
    compile project(':base')
    compile project(':omnijar')
    // Including the Robotium JAR directly can cause issues with dexing.
    androidTestCompile 'com.jayway.android.robotium:robotium-solo:4.3.1'
}

task syncOmnijarFromDistDir(type: Sync) {
    into("${project.buildDir}/generated/omnijar")
    from("${topobjdir}/dist/fennec/assets") {
        include 'omni.ja'
    }
}

task checkLibsExistInDistDir<< {
    if (syncLibsFromDistDir.source.empty) {
        throw new GradleException("Required JNI libraries not found in ${topobjdir}/dist/fennec/lib.  Have you built and packaged?")
    }
}

task syncLibsFromDistDir(type: Sync, dependsOn: checkLibsExistInDistDir) {
    into("${project.buildDir}/generated/jniLibs")
    from("${topobjdir}/dist/fennec/lib")
}

task checkAssetsExistInDistDir<< {
    if (syncAssetsFromDistDir.source.empty) {
        throw new GradleException("Required assets not found in ${topobjdir}/dist/fennec/assets.  Have you built and packaged?")
    }
}

task syncAssetsFromDistDir(type: Sync, dependsOn: checkAssetsExistInDistDir) {
    into("${project.buildDir}/generated/assets")
    from("${topobjdir}/dist/fennec/assets") {
        exclude 'omni.ja'
    }
}

/**
 * We want to expose the JSM files and chrome content to IDEs; the omnijar
 * project does this.  In addition, the :omnijar:buildOmnijar task builds a new
 * omni.ja (directly into the object directory).
 *
 * The task dependency is: :generateDebugAssets -> :omnijar:buildOmnijar.
 *
 * One might expect that we could do this all in the omnijar project, but there
 * appears to be a bug (which I have not fully isolated) where-by debug-only
 * assets in a library (.aar file) are ignored in favor of release assets.  This
 * means we would have to insert the omni.ja into the omnijar project's release
 * assets, which is altogether confusing.
 */
android.applicationVariants.all { variant ->
    // We only insert omni.ja and the .so libraries into debug builds.
    def name = variant.buildType.name
    if (!name.contains(com.android.builder.core.BuilderConstants.DEBUG)) {
        return
    }

    def buildOmnijarTask = project(':omnijar').tasks.getByName('buildOmnijar')
    syncOmnijarFromDistDir.dependsOn buildOmnijarTask
    def generateAssetsTask = tasks.findByName("generate${name.capitalize()}Assets")
    generateAssetsTask.dependsOn syncOmnijarFromDistDir
    generateAssetsTask.dependsOn syncLibsFromDistDir
    generateAssetsTask.dependsOn syncAssetsFromDistDir

    android.sourceSets.debug.assets.srcDir syncOmnijarFromDistDir.destinationDir
    android.sourceSets.debug.assets.srcDir syncAssetsFromDistDir.destinationDir
    android.sourceSets.debug.jniLibs.srcDir syncLibsFromDistDir.destinationDir
}

apply plugin: 'spoon'

spoon {
    // For now, let's be verbose.
    debug = true
    // It's not helpful to pass when we don't have a device connected.
    failIfNoDeviceConnected = true

    def spoonPackageName
    if (gradle.startParameter.taskNames.contains('runBrowserTests')) {
        spoonPackageName = 'org.mozilla.tests.browser.junit3'
    }
    if (gradle.startParameter.taskNames.contains('runBackgroundTests')) {
        spoonPackageName = 'org.mozilla.gecko.background'
    }
    if (project.hasProperty('spoonPackageName')) {
        // Command line overrides everything.
        spoonPackageName = project.spoonPackageName
    }
    if (spoonPackageName) {
        instrumentationArgs = ['-e', "package=${spoonPackageName}".toString()]
    }
}

// See discussion at https://github.com/stanfy/spoon-gradle-plugin/issues/9.
afterEvaluate {
    tasks["spoon${android.testBuildType.capitalize()}AndroidTest"].outputs.upToDateWhen { false }

    // This is an awkward way to define different sets of instrumentation tests.
    // The task name itself is fished at runtime and the package name configured
    // in the spoon configuration.
    task runBrowserTests {
        dependsOn tasks["spoonDebugAndroidTest"]
    }
    task runBackgroundTests {
        dependsOn tasks["spoonDebugAndroidTest"]
    }
}