在Android实际项目中的Gradle文件的使用-manifest文件

Android Studio使用Gradle 编译运行Android工程，工程的每个模块以及整个工程都有一个build.gradle文件。通常你只需要关注模块的build.gradle文件。

那先来看看app下面的build.gradle文件（算是整个项目最主要的配置,我用的具体线上项目说说）：

在文件开头

apply plugin: 'com.android.application'//表示该module是一个app module，应用了com.android.application插件 ，如果是一个依赖module 则此处为apply plugin: 'com.android.library'apply plugin: 'me.tatarka.retrolambda'//添加其它插件，具体功能自行查询

接下来看看android{}块里面的配置内容：

dependencies { compile fileTree(include: '*.jar', dir: 'libs') compile project(':domain')//依赖library releaseCompile project(path: ':data', configuration: 'release') debugCompile project(path: ':data', configuration: 'debug') def presentationDependencies = rootProject.ext.presentationDependencies apt presentationDependencies.daggerCompiler compile presentationDependencies.zxing compile presentationDependencies.dagger}//所有渠道不变的keydef unChangedKeyMap() { LinkedHashMap<String, Object> map = new LinkedHashMap<String, Object>(); map.put("UMENG_KEY", "******") map.put("TTS_APPKEY", "*****") return map}//某些渠道公用的keydef commonKeyMap() { LinkedHashMap<String, Object> map = new LinkedHashMap<String, Object>(); map.put("MAP_KEY", "********") return map}android { useLibrary 'org.apache.http.legacy'//如果以前项目使用了apache的网络访问api，在6.0以后不提供而还想继续使用的的话加上这个 compileSdkVersion 23 buildToolsVersion '23.0.2' defaultConfig { minSdkVersion 14 targetSdkVersion 21 multiDexEnabled true applicationId "com.example.hulixia.airdnbtest" versionCode 40 versionName "4.0" //设置默认应用程序的包名 resValue "string", "app_name", "just test" buildConfigField "String", "WXAPPID", "\"*********\"" } sourceSets {// 配置源码路径，sourceSets是java插件引入的 main { manifest.srcFile 'AndroidManifest.xml'//设置清单文件的路径 java.srcDirs = ['src']//设置java代码的目录 resources.srcDirs = ['src']//设置资源文件目录 aidl.srcDirs = ['src']//设置aidl的文件目录 renderscript.srcDirs = ['src'] res.srcDirs = [ 'res/layouts/common',//给layout文件分目录 'res/layouts/testui', 'res/layouts', 'res' ] assets.srcDirs = ['assets']//asset文件分目录 jniLibs.srcDirs = ['libs']//给so文件设置目录 } // Move the build types to build-types/<type> // For instance, build-types/debug/java, build-types/debug/AndroidManifest.xml, ... // This moves them out of them default location under src/<type>/... which would // conflict with src/ being used by the main source set. // Adding new build types or product flavors should be accompanied // by a similar customization. debug.setRoot('build-types/debug')//指定debug模式的路径 release.setRoot('build-types/release')//指定release模式的路径 } // debug和release版本的签名 signingConfigs { release { storeFile file("publish.keystore") storePassword "123456" keyAlias "huhuhahei" keyPassword "123456" } } buildTypes {//构建类型，通常有release和debug两种 release { buildConfigField "boolean", "IS_DEBUG", "false" //调试开关，正式包关闭//动态设置变量，release通常和debug不一样 buildConfigField "String", "SERVER_URL", "\"http://cn.bing.com/\"" buildConfigField "String", "TRANSLATE_URL", "\"http://www.bing.com/translator/?mkt=zh-CN\"" signingConfig signingConfigs.release //使用上面定义的signingConfigs成员 minifyEnabled true //开启混淆 shrinkResources true;//是否移除无用资源文件，shrinkResources依赖于minifyEnabled，必须和minifyEnabled一起用 proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'//混淆文件 applicationVariants.all { variant -> variant.outputs.each { output -> def outputFile = output.outputFile ver if (outputFile != null && outputFile.name.endsWith('.apk')) { def fileName = "JustTest${defaultConfig.versionName}_${variant.productFlavors[0].name}.apk" output.outputFile = new File(outputFile.parent, fileName) } } } } debug { signingConfig signingConfigs.release buildConfigField "boolean", "IS_DEBUG", "true" //调试开关，正式包关闭 buildConfigField "String", "SERVER_URL", "\"http://www.google.com/\"" buildConfigField "String", "TRANSLATE_URL", "\"https://translate.google.cn/\"" } } productFlavors { baidu { LinkedHashMap<String, Object> map = unChangedKeyMap() map.putAll(commonKeyMap()) map.put("UMENG_CHANNEL_VALUE", "baidu") manifestPlaceholders = map } hw { LinkedHashMap<String, Object> map = unChangedKeyMap() map.putAll(commonKeyMap()) map.put("UMENG_CHANNEL_VALUE", "hw") manifestPlaceholders = map } } compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } lintOptions {//程序在buid的时候，会执行lint检查，有任何的错误或者警告提示，都会终止构建，我们可以将其关掉。 abortOnError false ignoreWarnings true checkReleaseBuilds false } dexOptions {//为dex操作指定JVM的最大内存分配池的选项为 javaMaxHeapSize "2g" } packagingOptions {//依赖中认为是不需要的内容,因为多个 jar 包里包含了同样的文件 exclude 'META-INF/NOTICE.txt' exclude 'META-INF/LICENSE.txt' } splits { abi { enable true reset() include 'armeabi' universalApk false } }}

compileSdkVersion 23：基于SDK 23编译，这里是API LEVELbuildToolsVersion '23.0.2' 基于23.0.2构建工具版本进行构建的defaultConfig 默认配置，如果没有其他的配置覆盖，就会使用这里的。minSdkVersion 15 创建项目时指定的最低SDK版本为15，是新建应用支持的最低SDK版本。也就是说在低于15的设备上是不能运行的applicationId 创建新项目时指定的包名。versionCode 版本号versionName 版本名称resValue 动态添加资源buildConfigField 在BuildConfig文件中生成变量

targetSdkVersion

这里重点讲一下targetSdkVersion，因为它让许多人都感到迷糊。

Google原文是这么说的：

targetSdkVersion is the main way Android provides forward compatibility

targetSdkVersion 是 Android 系统提供前向兼容的主要手段。这是什么意思呢？随着 Android 系统的升级，某个系统的 API 或者模块的行为可能会发生改变，但是为了保证老 APK 的行为还是和以前兼容。只要 APK 的 targetSdkVersion 不变，即使这个 APK 安装在新 Android 系统上，其行为还是保持老的系统上的行为，这样就保证了系统对老应用的前向兼容性。

这里举个官方的例子，在 Android 4.4 (API 19）以后，AlarmManager 的 set()和setRepeat()这两个 API 的行为发生了变化。在 Android 4.4 以前，这两个 API 设置的都是精确的时间，系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒，这两个 API 设置唤醒的时间，系统都对待成不精确的时间，系统只能保证在你设置的时间点之后某个时间唤醒。

这时，虽然 API 没有任何变化，但是实际上 API 的行为却发生了变化，如果老的 APK 中使用了此 API，并且在应用中的行为非常依赖 AlarmManager 在精确的时间唤醒，例如闹钟应用。如果 Android 系统不能保证兼容，老的 APK 安装在新的系统上，就会出现问题。

Android 系统是怎么保证这种兼容性的呢？这时候 targetSdkVersion 就起作用了。APK 在调用系统 AlarmManager 的set()或者setRepeat()的时候，系统首先会查一下调用的APK的targetSdkVersion 信息如果小于 19，就还是按照老的行为，即精确设置唤醒时间，否者执行新的行为。

我们来看一下 Android 4.4 上 AlarmManger 的一部分源代码：

private final boolean mAlwaysExact; AlarmManager(IAlarmManager service, Context ctx) { mService = service; final int sdkVersion = ctx.getApplicationInfo().targetSdkVersion; mAlwaysExact = (sdkVersion < Build.VERSION_CODES.KITKAT);}

首选获取应用的 targetSdkVersion，判断是否是小于 Build.VERSION_CODES.KITKAT (即 API Level 19)，来设置 mAlwaysExact 变量，表示是否使用精确时间模式。

看到这里，发现其实 Android 的 targetSdkVersion 并没有什么特别的，系统使用它也非常直接，甚至很“粗糙”。仅仅是用过下面的 API 来获取 targetSdkVersion，来判断是否执行哪种行为：

getApplicationInfo().targetSdkVersion;

我们也可以理解原文中说的那句话的含义，明白了为什么修改了 APK 的 targetSdkVersion 行为会发生变化，也明白了为什么修改 targetSdkVersion 需要做完整的测试了。

multiDexEnabled

设置为true表示分成多个dex文件，因为有个方法数65k的限制问题

sourceSets

设置了sourceSets之后的工程目录结构：

在Android实际项目中的Gradle文件的使用

applicationVariants 定制生成apk的名称

 applicationVariants.all { variant -> variant.outputs.each { output -> def outputFile = output.outputFile ver if (outputFile != null && outputFile.name.endsWith('.apk')) { def fileName = "JustTest${defaultConfig.versionName}_${variant.productFlavors[0].name}.apk" output.outputFile = new File(outputFile.parent, fileName) } } }

生成的apk名称为(假设是baidu渠道):JustTest4.0_baidu.apk

productFlavors 多渠道打包

国内有太多Android App市场，每次发版几十个渠道包。还好Android Gradle给我们提供了productFlavors，我们可以对生成的APK包进行定制。

在上面的例子中unChangedKeyMap是共用的数据，像什么UMENG，迅飞语音的key。在上面的例子中将数据信息根据不同的渠道传递不同的数据信息到清单文件中,AndroidManifest代码片段：

<meta-data android:name="UMENG_CHANNEL" android:value="${UMENG_CHANNEL_VALUE}"/>

Splits 使用分割ABI 和屏幕密度的方式来发布多个 apk

apk 瘦身系列④：使用分割ABI 和屏幕密度的方式来发布多个apk

dependencies

本地依赖，默认情况下,新建的Android项目会有一个lib文件夹

dependencies { compile fileTree(include: '*.jar', dir: 'libs')}////即添加所有在libs文件夹中的jar//compile files('libs/test.jar')//不需要这样一个个去写了compile project(':domain')//编译domain模块

在Android实际项目中的Gradle文件的使用

有必要说一下当一个项目下有多个模块，每个模块可能都有自己要依赖的远程库，为了统一管理，这个在根目录建个config.gradle。然后在根目录下build.gradle最顶部加上下面一行代码

apply from: "config.gradle"

config.gradle中代码片段：

ext { daggerVersion = '2.0.2' zxingVersion = "3.2.1"}presentationDependencies = [zxing : "com.google.zxing:core:${zxingVersion}",daggerCompiler : "com.google.dagger:dagger-compiler:${daggerVersion}"]

在app下的build.gradle文件中使用

 def presentationDependencies = rootProject.ext.presentationDependencies apt presentationDependencies.daggerCompiler compile presentationDependencies.zxing compile presentationDependencies.dagger