gradle结构:
MyApp
├── build.gradle
├── settings.gradle
└── app
└── build.gradle
1. setting.gradle解析
当你的app只有一个模块的时候,你的setting.gradle将会是这样子的:
include ':app'
当有多个模块时,如支付平台中需要包含 第三方 支付库
include ':app', ':thirdpartylib'
2、根目录的build.gradle
该gradle文件是定义在这个工程下的所有模块的公共属性,它默认包含二个方法:
buildscript方法是定义了全局的相关属性,repositories定义了jcenter作为仓库。一个仓库代表着你的依赖包的来源,例如maven仓库。dependencies用来定义构建过程。这意味着你不应该在该方法体内定义子模块的依赖包,
你仅仅需要定义默认的Android插件就可以了,因为该插件可以让你执行相关Android的tasks。allprojects方法可以用来定义各个模块的默认属性,你可以不仅仅局限于默认的配置,未来你可以自己创造tasks在allprojects方法体内,
这些tasks将会在所有模块中可见。
可以在该模块中加入:
ext {
compileSdkVersion = 23
buildToolsVersion = "25.0.2"
minSdkVersion = 14
targetSdkVersion = 23
}
然后在各个子模块中引用 全局的 各个Version
3、模块内的build.gradle
apply plugin: 'com.android.application'
android {
compileSdkVersion 22
buildToolsVersion "22.0.1"
defaultConfig {
applicationId "com.gradleforandroid.gettingstarted"
minSdkVersion 14
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile
('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
}
插件
该文件的第一行是Android应用插件,该插件我们在上一篇博客已经介绍过,其是google的Android开发团队编写的插件,能够提供所有关于Android应用和依赖库的构建,打包和测试。
com.android.application com.android.library
Android
该方法包含了所有的Android属性,而唯一必须得属性为compileSdkVersion和buildToolsVersion:
-
compileSdkVersion:编译该app时候,你想使用到的api版本。
-
buildToolsVersion:构建工具的版本号。
构建工具包含了很多实用的命令行命令,例如aapt,zipalign,dx等,这些命令能够被用来产生多种多样的应用程序。你可以通过sdk manager来下载这些构建工具。
defaultConfig方法包含了该app的核心属性,该属性会重写在AndroidManifest.xml中的对应属性。
defaultConfig {
applicationId "com.gradleforandroid.gettingstarted"
minSdkVersion 14
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
第一个属性是applicationId,该属性复写了AndroidManifest文件中的包名package name,但是关于applicationId和packagename有一些不同。在gradle被用来作为Android构建工具之前,package
name在AndroidManifest.xml有两个作用:其作为一个app的唯一标示,并且其被用在了R资源文件的包名。
Gradle能够很轻松的构建不同版本的app,使用构建变种。举个例子,其能够很轻松的创建一个免费版本和付费版本的app。这两个版本需要分隔的标示码,所以他们能够以不同的app出现在各大应用商店,当然他们也能够
同时安装在一个手机中。资源代码和R文件必须拥有相同的包名,否则你的资源代码将需要改变,这就是为什么Android开发团队要将package name的两大功能拆分开。在AndroidManifest文件中定义的package name依然
被用来作为包名和R文件的包名。而applicationid将被用在设备和各大应用商店中作为唯一的标示。接下来将是minSdkVersion和targetSdkVersion。这两个和AndroidManifest中的<uses-sdk>很像。minSdkVersion定义
为最小支持api。versionCode将会作为版本号标示,而versionName毫无作用。
所有的属性都是重写了AndroidManifest文件中的属性,所以你没必要在AndroidManifest中定义这些属性了。
当libs文件夹下 有.so文件时,系统不会像.jar文件一样自动检测,并添加到项目中去。需要在该模块增加如下代码,才会去libs木下查找 .so 文件
sourceSets{
main{
jniLibs.srcDirs=['libs']
}
}
buildTypes
方法定义了如何构建不同版本的app,如下可以创建自己需要的版本:
android {
buildTypes {
staging {
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
buildConfigField "String", "API_URL",
""http://staging.example.com/api""
}
}
}
我们定义了一个staging版本,该版本定义了一个新的application id,这让其与debug和release版本的applicationID不同。假设你使用了默认的配置,那么applicationID将会是这样的:
-
Debug: com.package
-
Release: com.package
-
Staging: com.package.staging
这意味着你可以在你的设备上安装staging版本和release版本。staging版本也有自己的版本号。buildConfigField定义了一个新的URL地址。你不必事事都去创建,所以最可能的方式是去继承已有的版本。
android {
buildTypes {
staging.initWith(buildTypes.debug)
staging {
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
debuggable = false
}
}
}
initWith()方法创建了一个新的版本的同时,复制所有存在的构建版本,类似继承。我们也可以复写该存在版本的所有属性。
dependencies
依赖模块作为gradle默认的属性之一(这也是为什么其放在了Android的外面),为你的app定义了所有的依赖包。默认情况下,
我们依赖了所有在libs文件下的jar文件,同时包含了AppCompat这个aar文件。
较大的项目工程里面需要添加: compile project(':commonlib') // 在该包中需要引用其他项目资源。