欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  移动技术

Android App开发中Gradle构建过程的配置方法

程序员文章站 2024-03-02 21:50:52
在build文件中使用了android或者java插件之后就会自动创建一系列可以运行的任务。 gradle中有如下一下默认约定的任务: 1. assemble 该任务...

在build文件中使用了android或者java插件之后就会自动创建一系列可以运行的任务。
gradle中有如下一下默认约定的任务:
1. assemble
该任务包含了项目中的所有打包相关的任务,比如java项目中打的jar包,android项目中打的apk
2. check
该任务包含了项目中所有验证相关的任务,比如运行测试的任务
3. build
该任务包含了assemble和check
4. clean
该任务会清空项目的所有的输出,删除所有在assemble任务中打的包
assemble, check 和 build 任务实际上并不做任何事情,它们其实只是为插件提供了一个钩子,真正的事情都是由插件来完成的。
这样的话,开发人员就不需要关心我到底运行的是一个java项目还是一个android项目,也不用关心我到底使用了哪些gradle插件,因为我都可以调用这些约定的任务来完成构建。
比如使用findbugs插件会创建一个新的任务,并且使得check任务依赖于这个新建的任务,这样每次执行check任务的时候,都会执行这个新建的任务。
在命令行执行
  

gradle tasks 


 
</pre>会列出所有主要的任务如果想看到全部的任务和它们的依赖,可以运行:<pre name="code" class="java">gradle tasks --all 
注意:gradle会自动检查一个任务的输入和输出。比如连续两次运行build任务的,gradle会报告所有的任务都已经是最新刚运行过的了,不需要再次运行。这样的话,任务之间就算是有相互依赖,也不会导致重复的执行。
java项目常用的任务
java plugin 主要创建了两个任务:
1. jar
assemble任务会依赖jar任务,看名字就知道这是负责打jar包的任务。jar任务本身又会依赖很多其他的任务,比如classes任务,classes任务会编译java代码
2. test
check任务会依赖test任务,这个任务会运行所有的测试。测试代码使用testclasses任务编译,但是我们基本不用手动运行testclasses任务因为test任务已经添加了对它的依赖。
通常情况下,我们只要运行assemble和check任务就够了。
想查看java插件提供的所有任务以及他们的依赖可以点这个[链接](http://gradle.org/docs/current/userguide/java_plugin.html)
android项目常用的任务
和其他gradle插件一样,android插件也提供了一些默认的任务,比如assemble,check,build,clean,同时它也提供了一些自己特有的任务,比如:
1. connectedcheck
运行那些需要在真机或者模拟器上执行的检查任务,这些任务会并行地在所有连接的设备上运行
2. devicecheck
使用apis连接远程设备执行检查.主要用于ci(持续集成)服务上.
上面两个任务都会执行 assemble 和 check任务。新加这两个任务是很有必要的,这样可以保证我们可以运行那些不需要连接设备的检查任务。
注意:build任务并不依赖于devicecheck或者connectedcheck
一个android项目通常至少会有两种输出:debug apk和release apk。对应的gradle中有两个任务可以分别输出不同的apk:

  • assembledebug
  • assemblerelease

这两个任务又会依赖其他的任务来构建一个apk。assemble任务依赖这两个任务,调用assemble任务就会生成两种apk。

小提示: gradle支持在命令行使用camel风格的缩写来代替任务的名字,比如:

gradle ar 

等同于

gradle assemblerelease 

只要没有其他任务的缩写也是'ar'
check相关的任务的依赖:

  • check依赖lint
  • connectedcheck依赖 connectedandroidtest和connecteduiautomatortest (还没有实现)
  • devicecheck依赖于那些实现了test扩展的插件所提供的任务

最后,android gradle插件还提供了install和uninstall任务,用来安装和卸载apk

自定义构建过程之配置manifest
android gradle插件提供了大量的dsl来自定义构建过程,下面就来讲解如何在gradle中配置manifest。
dsl提供了配置以下manifest条目的功能:

  • minsdkversion
  • targetsdkversion
  • versioncode
  • versionname
  • applicationid (更加方便有效的包名 -- [参考](http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename))
  • 测试app的包名
  • instrumentation test runner

示例:

android { 
  compilesdkversion 19 
  buildtoolsversion "19.0.0" 
 
 
  defaultconfig { 
    versioncode 12 
    versionname "2.0" 
    minsdkversion 16 
    targetsdkversion 16 
  } 
} 

android元素中的defaultconfig元素就是我们用来配置manifest的地方。早期版本的android插件使用packagename来配置manifest中的packagename属性,从0.11.0开始,使用applicationid来代替packagename。这样可以消除应用的包名(其实就是应用的id)和java的包名之间的混淆。

更强大的是build文件中描述的配置可以是动态的,比如可以从文件或者自定义的逻辑中获取版本名称。

def computeversionname() { 
  ... 
} 
 
 
android { 
  compilesdkversion 19 
  buildtoolsversion "19.0.0" 
 
 
  defaultconfig { 
    versioncode 12 
    versionname computeversionname() 
    minsdkversion 16 
    targetsdkversion 16 
  } 
} 

 注意:不要使用作用域中的getter方法名作为函数名,比如在defaultconfig{}作用域中调用getversionname()将会自动调用defaultconfig.getversionname(),而不会调用自定义的方法。
如果某个属性的值没有使用dsl设置,这个属性将会使用某些默认值,下表展示了默认值的处理过程。
属性名    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) 

如果你想在build脚本中使用自定义的逻辑来查询这些属性,第二列中的值就很重要。比如,你可以编写如下的代码:
if (android.defaultconfig.testinstrumentationrunner == null) { 
  // assign a better default... 
} 

如果属性的值仍然是null,那么在构建的时候,就会使用第三列的默认值,但是dsl元素中并不包含这些默认值,因此你不能在程序中查询这些值。这样做的目的是仅在必要的时候(构建时)才会去解析manifest内容。