(四) Basic Build Customization(基本的构建定制 :签名,构建,混淆)

Manifest entries (Manifest属性)

通过SDL可以配置一下manifest选项:

  • minSdkVersion
  • targetSdkVersion
  • versionName
  • applicationId (有效的包名 -- 更多详情请查阅ApplicationId 对比 PackageName)
  • package Name for the test application
  • Instrumentation test runner

例如:

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        versionCode 12
        versionName "2.0"
        minSdkVersion 16
        targetSdkVersion 16
    }
}

android元素中的defaultConfig元素中定义所有配置。

之前的Android Plugin版本使用packageName来配置manifest文件中的packageName属性。从0.11.0版本开始,你需要在build.gradle文件中使用applicationId来配置manifest文件中的packageName属性。 这是为了消除应用程序的packageName(也是程序的ID)和java包名所引起的混乱。

在构建文件中定义的强大之处在于它是动态的。 例如,可以从一个文件中或者其它自定义的逻辑代码中读取版本信息:

def computeVersionName() {
    ...
}

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        versionCode 12
        versionName computeVersionName()
        minSdkVersion 16
        targetSdkVersion 16
    }
}

注意:不要使用与在给定范围内的getter方法可能引起冲突的方法名。例如,在defaultConfig{...}中调用getVersionName()将会自动调用defaultConfig.getVersionName()方法,你自定义的getVersionName()方法就被取代掉了。

如果一个属性没有使用DSL进行设置,一些默认的属性值将会被使用。以下表格是可能使用到的值:

Property Name Default value in DSL object Default value
versionCode -1 value from manifest if present
versionName null value from manifest if present
minSdkVersion -1 value from manifest if present
targetSdkVersion -1 value from manifest if present
applicationId null value from manifest if present
testApplicationId null applicationId + “.test”
testInstrumentationRunner null android.test.InstrumentationTestRunner
signingConfig null null
proguardFile N/A (set only) N/A (set only)
proguardFiles N/A (set only) N/A (set only)

如果你在构建脚本中使用自定义代码逻辑请求这些属性,那么第二列的值将非常重要。例如,你可能会写:

if (android.defaultConfig.testInstrumentationRunner == null) {
    // assign a better default...
}

如果这个值一直保持null,那么在构建执行期间将会实际替换成第三列的默认值。但是在DSL元素中并没有包含这个默认值,所以,你无法查询到这个值。 除非是真的需要,这是为了预防解析应用的manifest文件。


Build Types(构建类型)

默认情况下,Android Plugin会自动给项目设置同时构建应用程序的debug和release版本。 两个版本之间的不同主要围绕着能否在一个安全设备上调试,以及APK如何签名。

Debug版本采用使用通用的name/password键值对自动创建的数字证书进行签名,以防止构建过程中出现请求信息。Release版本在构建过程中没有签名,需要稍后再签名。

这些配置通过一个BuildType对象来配置。默认情况下,这两个实例都会被创建,分别是一个debug版本和一个release版本。

Android plugin允许像创建其他构建类型一样定制debugrelease实例。这需要在buildTypes的DSL容器中配置:

android {
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }

        jnidebug.initWith(buildTypes.debug)
        jnidebug {
            packageNameSuffix ".jnidebug"
            jnidebugBuild true
        }
    }
}

以上代码片段实现了以下功能:

  • 配置默认的debug构建类型
    • 将debug版本的包名设置为.debug以便能够同时在一台设备上安装debugrelease版本的apk。
  • 创建了一个名为jnidebug的新构建类型,并且这个构建类型是debug构建类型的一个副本。
  • 继续配置jnidebug构建类型,允许使用JNI组件,并且也添加了不一样的包名后缀。

创建一个新的构建类型就是简单的在buildType标签下添加一个新的元素,并且可以使用initWith()或者直接使用闭包来配置它。

以下是一些可能使用到的属性和默认值:

Property name Default values for debug Default values for release / other
debuggable true false
jniDebugBuild false false
renderscriptDebugBuild false false
renderscriptOptimLevel 3 3
applicationIdSuffix null null
versionNameSuffix null null
signingConfig android.signingConfigs.debug null
zipAlign false true
runProguard false false
proguardFile N/A (set only) N/A (set only)
proguardFiles N/A (set only) N/A (set only)

除了以上属性之外,Build Type还会受项目源码和资源影响: 对于每一个Build Type都会自动创建一个匹配的sourceSet。默认的路径为:

src/<buildtypename>/

这意味着BuildType名称不能是main或者androidTest(因为这两个是由plugin强制实现的),并且他们互相之间都必须是唯一的。

跟其他sourceSet设置一样,Build Type的source set路径可以重新被定向:

android {
    sourceSets.jnidebug.setRoot('foo/jnidebug')
}

另外,每一个Build Type都会创建一个新的assemble任务。

assembleDebugassembleRelease两个Task在上面已经提到过,这里要讲这两个Task从哪里被创建。当debugrelease构建类型被预创建的时候,它们的tasks就会自动创建对应的这个两个Task。

上面提到的build.gradle代码片段中也会实现assembleJnidebug task,并且assemble会像依赖于assembleDebugassembleRelease一样依赖于assembleJnidebug

提示:你可以在终端下输入gradle aJ去运行assembleJnidebug task

可能会使用到的情况:

  • release模式不需要,只有debug模式下才使用到的权限
  • 自定义的debug实现
  • 为debug模式使用不同的资源(例如当资源的值由绑定的证书决定)

BuildType的代码和资源通过以下方式被使用:

  • manifest将被混合进app的manifest
  • 代码行为只是另一个资源文件夹
  • 资源将叠加到main的资源中,并替换已存在的资源。


signing configurations(签名配置)

对一个应用程序签名需要以下:

  • 一个Keystory
  • 一个keystory密码
  • 一个key的别名
  • 一个key的密码
  • 存储类型

位置,键名,两个密码,还有存储类型一起形成了签名配置。

默认情况下,debug被配置成使用一个debug keystory。 debug keystory使用了默认的密码和默认key及默认的key密码。 debug keystory的位置在$HOME/.android/debug.keystroe,如果对应位置不存在这个文件将会自动创建一个。

debug Build Type(构建类型) 会自动使用debug SigningConfig (签名配置)。

可以创建其他配置或者自定义内建的默认配置。通过signingConfigs这个DSL容器来配置:

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

        myConfig {
            storeFile file("other.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
    }

    buildTypes {
        foo {
            debuggable true
            jniDebugBuild true
            signingConfig signingConfigs.myConfig
        }
    }
}

以上代码片段修改debug keystory的路径到项目的根目录下。在这个例子中,这将自动影响其他使用到debug构建类型的构建类型。

这里也创建了一个新的Single Config(签名配置)和一个使用这个新签名配置的新的Build Type(构建类型)。


注意:只有默认路径下的debug keystory不存在时会被自动创建。更改debug keystory的路径并不会自动在新路径下创建debug keystory。如果创建一个新的不同名字的SignConfig,但是使用默认的debug keystore路径来创建一个非默认的名字的SigningConing,那么还是会在默认路径下创建debug keystory。换句话说,会不会自动创建是根据keystory的路径来判断,而不是配置的名称。




注意:虽然经常使用项目根目录的相对路径作为keystore的路径,但是也可以使用绝对路径,尽管这并不推荐(除了自动创建出来的debug keystore)。



Running Proguard(运行 Proguard)

从Gradle Plugin for ProGuard version 4.10之后就开始支持ProGuard。ProGuard插件是自动添加进来的。如果Build TyperunProguard属性被设置为true,对应的task将会自动创建。

android {
    buildTypes {
        release {
            runProguard true
            proguardFile getDefaultProguardFile('proguard-android.txt')
        }
    }

    productFlavors {
        flavor1 {
        }
        flavor2 {
            proguardFile 'some-other-rules.txt'
        }
    }
}

发布版本将会使用它的Build Type中声明的规则文件,product flavor(定制的产品版本)将会使用对应flavor中声明的规则文件。

这里有两个默认的规则文件:

  • proguard-android.txt
  • proguard-android-optimize.txt

这两个文件都在SDK的路径下。使用getDefaultProguardFile()可以获取这些文件的完整路径。它们除了是否要进行优化之外,其它都是相同的。


阅读更多
个人分类: Gradle
想对作者说点什么? 我来说一句

微软Visual Studio Team System构建管理

2009年03月14日 9.96MB 下载

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭