配置Gradle构建

时间 2019-12-08 标签配置 gradle 构建

构建基础配置

Android Studio包含一个顶级的构建文件和每一个模块的构建文件。构建文件被称为 build.gradle，它是一个纯文本文件，它使用Groovy语法来配置由Android Gradle插件提供的元素。在大多数状况下，你只须要编辑模块级别的构建文件。例如，BuildSystemExample项目的app模块的构建文件是像这样的：html

apply plugin:'com.android.application'

android {
compileSdkVersion 19
buildToolsVersion "19.0.0"

defaultConfig {
minSdkVersion 8
targetSdkVersion 19
versionCode 1
versionName "1.0"
  }
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
  }
  }
}

dependencies {
compile project(":lib")
compile 'com.android.support:appcompat-v7:19.0.1'
compile fileTree(dir:'libs', include:['*.jar'])
}java

apply plugin:'com.android.application' 是应用Android Gradle插件来构建。这样添加Android特定的构建任务到顶级构建任务中，而且使用 android{…}中的元素来指定Android特定的构建项。android

android{….} 配置全部的Android特定构建项：安全

compileSdkVersion 项指定编译的目标。app

buildToolsVersion 项指定使用什么版本的构建工具。使用SDK管理器来安装多个版本的构建工具。ide

注意：请始终使用其主要版本号高于或等于您的编译目标SDK的版本。工具

defaultConfig 元素动态的配置在AndroidManifest.xml中的设置。在defaultConfig的值将覆盖manifest文件中的值。配置在defaultConfig的值将应用于全部的构建变种(build variants),除非构建变种的配置覆盖了这些值。布局

buildType元素控制如何构建和打包你的应用。默认的构建系统定义了两个构建类型：debug和release。debug构建类型包含debugging符号，而且使用了debug key签名。release构建类型默认没有被签名。在这个例子中构建文件配置了release版本，使用了ProGuard。gradle

dependencies元素是在android元素外面的，而且在android元素后面。这个元素声明了这个模块的依赖。在一下的章节中都有依赖的内容。ui

注：当你在你的项目中改变了构建文件，Android Studio为了导入改变了构建配置而要求项目同步。点击黄色通知栏中的”Sync Now”按钮来同步改变的内容。

图一. 同步 Android Studio中的项目。

声明依赖

这个例子的应用模块声明了3个依赖：

...
  dependencies {
      // Module dependency
      compile project(":lib")
  
      // Remote binary dependency
      compile 'com.android.support:appcompat-v7:19.0.1'
  
      // Local binary dependency
      compile fileTree(dir:'libs', include:['*.jar'])
  }

每一个依赖在下面给出描述。构建系统添加全部类型为”compile”的依赖到编译路径中，而且最终将他们打到最终的包中。

Module dependencies

app模块依赖于lib模块。由于像在”Open an Activity from a Library Module”中描述的，MainActivity登陆LibActivity1.

compile project(":lib") 声明了依赖lib模块。当你构建app模块的时候，构建系统将会集合lib模块。

运程二进制依赖

app和lib模块都使用了来自Android支持库的ActionBarActivity类，全部这些模块都依赖它。

compile 'com.android.support:appcompat-v7:19.0.1' 经过指定Maven坐标来声明了对Android支持库19.0.1版本的依赖。在Android SDK的仓库包中Android的支持库是可用的。若是你安装的SDK没有这个包，经过使用SDK管理工具下载安装它。

Android Studio默认使用了Maven的中央仓库来配置项目。(这个配置在项目的顶级构建文件中)。

本地二进制依赖

一些模块不使用任何的本地系统二进制依赖。若是你有依赖本地二进制依赖的模块，拷贝JAR文件到<moduleName>/libs目录下。

compile fileTree(dir: 'libs', include: ['*.jar']) 告诉构建系统将 app/libs目录下面的JAR文件依赖包含到编译路径，而且最终在最终的包中。

有关在Gradle更多的依赖信息，请查看Gradle的用户指南(Dependency Management Basics )。

运行ProGuard

构建系统运行ProGuard，以达到在构建过程当中混淆你的代码的目的。在BuildSystemExample中，为了release构建运行ProGuard修改app模块的构建文件:

...
  android {
      ...
      buildTypes {
          release {
              minifyEnabled true
              proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
          }
      }
  }
  ...

getDefaultProguardFile('proguard-android.txt') 从安装的Android SDK中获取默认的ProGuard设置。你可自定义ProGuard规则，Android Studio 将会加模块根部的proguard-rules.pro文件添加到模块特定的规则中。

包的标识:Application ID

在Android构建系统中，applicationId属性是惟一标示发行应用包。Application ID在build.gradle文件的android节点中设置。

apply plugin:'com.android.application'
  
      android {
          compileSdkVersion 19
          buildToolsVersion "19.1"
  
      defaultConfig {
          applicationId "com.example.my.app"
          minSdkVersion 15
          targetSdkVersion 19
          versionCode 1
          versionName "1.0"
      }

注： applicationID只能在build.gradle文件中被指定，不能再AndroidManifest.xml文件中。

当使用build variants，构建系统可让你为每一个product flavors和build types指定包的惟一标示。在build type中的Application ID被添加到product flavors做为后缀。

 productFlavors {
          pro {
              applicationId ="com.example.my.pkg.pro"
          }
          free {
              applicationId ="com.example.my.pkg.free"
          }
      }
  
      buildTypes {
          debug {
              applicationIdSuffix ".debug"
          }
      }
      ....

包名依然须要在manifest文件中指定。它在你的源码中用来涉及你的R class和解决相关activity/service注册问题。

package="com.example.app">

注：若是你有多个manifests(好比，一个product flavor指定的manifest和一个build type的manifest)，包名在这些manifests中是可选的。若是它再这些manifests中被指定，那报名必须和src/main目录下的manifest的包名一致。

有关更多的关于构建文件和构建过程信息，请看 Build System Overview。

配置签名设置

debug和release版本的app在是否能在安全设备调试和如何进行签名是有区别的。构建系统使用一个默认的key来签名debug版本，而且为了在构建过程当中不出现密码提示，使用了已知的证书。构建系统不会签名release版本，除非你明肯定义了签名配置。若是你没有一个release的key，你能够安装”Signing your Applications”中描述的进行生成。

使用build variants工做

这个章节描述构建系统如何帮助你在一个项目中的同一个应用建立不一样的版本。当时有一个demo和paid版本的时候，这是有用的，或者是你想在Google Play上为不一样配置的设备发布多个APK。

构建系统使用 product flavors为你的应用建立不一样的版本。每一个版本有可能有不一样的特性和设备要求。构建系统也应用 build types到不一样的构建中，而且打包配置到每一个版本中。每一个product flavor和build type的组合造成了一个build variant。构建系统为每一个build variant生成了不一样的APK。

Build variants

这个项目例子包含了两个默认的build types(debug 和release),还有两个product flavors(demo和full)。更多关于使用build variants的高级信息，查看”Build System Overview”。

Product flavors

为你的应用建立不一样的版本:

一、在构建文件中定义product flavors

二、为每一个flavor建立附加的源码路径

三、添加flavor特定的源码到你的项目中

接下来的章节带你了解 BuildSystemExample项目中的每一个细节。在BuildSystemExample应用中建立两个Flavor。一个demo flavor和一个full flavor。两个flavors共享 MainActivity,MainActivity中有一个按钮跳转到一个新的activity—SecondActivity.对于两个flavor来讲SecondActivity是不一样的，所以你应该模拟这样的状况：full flavor中的Activity的特性要比demo flavor中的Activity多。在练习的最后，你将获得不一样flavor的不一样APK。

在构建文件中定义product flavors

为app模块中的构建文件定义两个product flavors:

...
  android {
      ...
      defaultConfig {...}
      signingConfigs {...}
      buildTypes {...}
      productFlavors {
          demo {
              applicationId "com.buildsystemexample.app.demo"
              versionName "1.0-demo"
          }
          full {
              applicationId "com.buildsystemexample.app.full"
              versionName "1.0-full"
          }
      }
  }
  ...

这个项目的flavor定义支持使用defualtConfig相同的配置。全部flavors相同都配置都定义在defaultConfig中，每一个flavor能够覆盖任何默认的值。上面的构建文件使用了 applicationId属性来分配给每一个flavor：自从每一个flavor建立了不一样的app,他们应该须要不一样的包名。

注：在Google Play中，为使你的应用能够拥有多APK支持。给你的所用variants分配相同的包名，而且给每一个viant不一样的versionCode. 为了再Google Play中区分不一样的variants,你应该分配不一样的包名给每一个variant。

为每一个flavor添加额外的源码目录

如今你应该建立源码目录，而且将SecondActivity添加到不一样的flavor中。为demo flavor建立源码目录结构：

一、在Project模板中，展开BuildSystemExample，而且展开app目录

二、右键src目录，选择New>Directory

三、使用”demo”做为目录的名字

四、一样的建立以下目录：

app/src/demo/java

app/src/demo/res

app/src/demo/res/layout

app/src/demo/res/values

目录的结构看起来像图1：

图一：demo flavor的目录

添加不一样的activity到不一样的flavor中：

添加SecondActivity到demo flavor中：

一、在Project模板中，右键app模块，选择New>Activity。

二、选择 Blank Activity,点击Next

三、输入activity名字: SecondActivity

四、输入包名”com.buildsystemexample.app”

五、在app/src/demo目录中右键java目录选择New>Package。

六、输入com.buildsystemexample.xapp

七、将SecondActivity拖拽到app/src/demo/java中

八、接受默认的Refactor

为demo flavor添加SecondActivity的布局文件和资源文件

一、从ap/src/main/res/layout中将activity_second.xml文件拖拽到app/src/demo/res/layout中

二、接受默认的提示

三、将strings.xml从app/src/main/res中拷贝到app/src/demo/res中

四、替换string.xml文件中的内容，以下：

<!--[if !supportLists]-->五、<!--[endif]--><?xml version="1.0" encoding="utf-8"?>
  <resources>
      <stringname="hello_world">This is the full version!</string>
  </resources>

注：从如今开始，你能够为每一个flavor单独开发SecondActivity. 好比，你能够为full flavor的activity添加更多的属性。

为了让指定的flavor文件工做，点击IDE窗口邮编的Build Variants，而且选择你想使用的flavor，就像图2. Android Studio可能会展现其余flavor的错误，可是这并不影响输出内容的构建。

图2

从MainActivity登入到指定flavor的activity

SecondActivity在全部的flavors中都有相同的包名，你能够同main activity中登入。编辑mainActivity:

一、编辑 activity_main.xml,添加一个按钮：

<LinearLayout ...>
      ...
      <Button
          android:id="@+id/button2"
          android:layout_width="wrap_content"
          android:layout_height="wrap_content"
          android:text="@string/button2"
          android:onClick="onButton2Clicked"/>
  </LinearLayout>

二、为按钮添加text标题，和按钮事件onButton2Clicked

三、在MainActivity中添加以下代码：

publicvoid onButton2Clicked(View view){
      Intent intent =newIntent(this,SecondActivity.class);
      startActivity(intent);
  }

四、编辑manifest文件

<manifest ...>
      <application ...>
          ...
          <activity
              android:name="com.buildsystemexample.app.SecondActivity"
              android:label="@string/title_activity_second">
          </activity>
      </application>
  </manifest>

Build types

Build types表现为为每一个app包构建包版本。默认的debug和release被提供：

...
  android {
      ...
      defaultConfig {...}
      signingConfigs {...}
      buildTypes {...}
      productFlavors {...}
      buildTypes {
          release {
              minifyEnabled false
              proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
          }
           debug {
              debuggable true
          }
      }
  }
  ...

注：尽管在build.gradle文件中默认只有release构建类型，当时release和debug构建类型都被应用的每一个构建中。

在这个例子中，product flavors和build types建立了一下的build variants:

demoDebug

demoRelease

fullDebug

fullRelease

为这个例子构建，能够点击Android Studio的Build菜单，或者在命令行中执行 assemble命令。

注：Build>Make Project会编译项目中全部的源码。Build>Rebuild Project选项从新编译全部的源码。

会为不一样的build variant建立不一样的输出目录。

QQ技术交流群290551701 http://cxy.liuzhihengseo.com/558.html