前言

在上一篇中，讲解了AGP的基础配置以及多渠道打包，在这一篇中将会进一步对AGP进行讲解。

1、Android{}

android{}，由AGP引入的其他节点：

• resValue
• buildConfigField
• adbOptions

这些节点在不会默认创建需要开发者手动定义。那么这些节点对应有什么功能呢？

1.1 resValue

看这个命名感觉像是资源相关的，直接上手代码看看。

android{...略defaultConfig {...略resValue 'string', 'aaa', 'aaa'...略}flavorDimensions 'channel'productFlavors {baidu {dimension 'channel'//resValue 'string', 'app_name', '自定义名称' // 不能有重复的资源节点resValue 'string', 'bbb', 'nnnn'}ali {dimension 'channel'}}...略
}

结合昨天的内容，这里可以看出，在defaultConfig与自定义产品风味里面的baidu里面分别定义了resValue这个属性，现在构建编译看看效果。

如图所示

当构建成功时，我们打开构建成功对应文件夹里面的内容可以看出：刚刚我们通过关键字resValue创建的字符串资源以及帮我们构建在资源文件里面了，通过注释也表明了对应生成的资源是通过什么产品维度创建的。既然在资源文件了，那应该能够正常使用吧。现在试试效果

如图所示

当构建成功时，通过Gradle生成的资源依然能够正常使用。难么问题来了，既然Gradle能生成资源，那它能不能修改资源呢？直接上手试一下就知道了！

如图所示

右边就是自带string里面的资源值，里面的内容时自带的；而左边就是我们要准备修改的值，现在运行构建下看看效果。

当构建项目的时候，就报错了，仔细看控制台，意思就是重复资源不可通过resValue定义。

现在总结下这个resValue的作用

• 使用resValue可以为当前的构建产品增加资源文件属性。
• resValue ‘string’, ‘name’, ‘value’
  • string表示资源标签的类型。name，资源属性名称。value，对应的属性值。
  • 注意，name如果已经存在，就不能进行覆盖。
• 不同的产品风味都可以添加自己的resValue，如果要所有产品风味都添加到，可以在defalutConfig{}进行添加。

1.2 buildConfigField

• 使用buildConifgField为产品修改BulidConfig中的类型。
• BuildConfig是在产品构建时自动生成的java类，里面存放了一些静态常量，编译后可以直接使用类中的常量。
• buildConfigField ‘String’, ‘fieldName’, ‘value’
  • String表示字符串类型，可以是其它Java类型，但是要注意，这里做的是文本的替换。所以，如果是其它类型，可以使用全类名的方式。
  • filedName表示属性名，value则是对应的值，由于是文本替换，如果value是字符串，需要自己加入双引号

概念说了这么多，直接上手代码看看效果。

android {compileSdkVersion 30defaultConfig {...略buildConfigField 'Boolean', 'DEBUG', 'true'buildConfigField 'int','taskId', '16'buildConfigField 'String','BASE_URL','"http:www.baidu.com"'...略}productFlavors {baidu {dimension 'channel'
//            resValue 'string', 'app_name', '自定义名称' // 不能有重复的资源节点resValue 'string', 'bbb', 'nnnn'buildConfigField  'String','CHANNEL_VALUE','"BAIDU"'}ali {dimension 'channel'}}
}

从这段代码可知，在defaultConfig 与自定义产品唯独baidu里面 分别用了buildConfigField关键字，然后我们编译构建看看效果。

如图所示

系统将我们在Gradle通过buildConfigField关键字创建的那些属性定义在BulidConfig中了。而且对应注释也标明了来自于哪个产品维度。既然属性定义在BulidConfig中了，那么肯定也能拿到逻辑代码里面用吧，试试看看效果：

效果完美运行，到这好像又掌握一种多渠道打包获取渠道号相关的知识点。而且我们请求接口的时候，也可以将BaseUrl定义在Gradle里面了。

那么新的问题来了，我不想在工程目录里面的Gradle里面写死我的BaseUrl类似的信息，想单独放在一个文件里该怎么操作呢？

这就要用到之前学过的知识点了：脚本插件

所以定一个属于自己的脚本：

MyConfig.gradle

ext{DEBUG = trueBASE_URL="https://juejin.cn/user/2357827986264942"taskId=15LOGIN_URL=BASE_URL+"/xx/xx/login"
}

这里我将BASE_URL改成了我的掘金首页，其他也随意修改了一下，随后将这个脚本引入工程项目并修改之前的获取方式可得：

plugins {id 'com.android.application'id 'kotlin-android'
}apply from:'../MyConfig.gradle'android {compileSdkVersion 30defaultConfig {applicationId "com.hqk.gradledemo04"minSdkVersion 21targetSdkVersion 30versionCode 1versionName "1.0"resValue 'string', 'aaa', 'aaa'buildConfigField 'Boolean', 'DEBUG', "${DEBUG}"buildConfigField 'int','taskId', "${taskId}"buildConfigField 'String','BASE_URL',"\"${BASE_URL}\""buildConfigField 'String','LOGIN_URL',"\"${LOGIN_URL}\""}}

这里先是引入了本地脚本插件，随后将里面的属性值已经改成动态获取。现在重新编译构建看看效果。

看这效果，完美运行成功。

1.3 adbOptions

在android{}中，可以为构建类型添加adb设置。直接上手代码：

android{...略// adb的操作选项adbOptions {installOptions '-r', '-s','-d'//-l, -t, -d, -g// -d 允许降级安装// -g 为应有获取所有运行时的权限// adb install有 l, r, t, s, d, g 这6个选项。// -l: 锁定该应用程序// -r: 替换已经存在的应用程序，强制安装// -t: 允许测试包// -s: 把应用装到sd卡上// -d: 允许进行降级安装，也就是应用的版本比手机上的版本低// -g: 为该应用授予所有运行时的权限}...略
}

这个很简单，就一些配置，可以跟多个，每一项功能注释都写得很全面。读者可以自己尝试玩一下。

结束语

到这，这一篇差不多讲解完了，AGP的相关配置到这篇也差不多结束了，从下一篇开始，将会开始讲解AGP实战相关。