Android build system 编译app资源和源码文件并打包成apk。
Android Studio用Gradle 自动化、定制化并管理android app的build process。通过配置管理实现app resources 和 code的引用控制管理，做到代码和资源的复用。
Gradle及其Android plugin 独立于Android Studio。你可以通过android studio编译打包apk，也可以通过command line编译打包apk。由于Gradle独立于Android studio，你需要单独去更新此build tools以匹配当前的Android studio版本。具体版本对应关系请参照：https://developer.android.google.cn/studio/releases/gradle-plugin
The build process
编译过程通过一系列的工具和过程将你的project转为apk。
Custom build configurations
Build types
Build types define certain properties that Gradle uses when building and packaging your app, and are typically configured for different stages of your development lifecycle.
在modules的build.gradle的android块中创建和配置buileTypes.
android {
defaultConfig {
manifestPlaceholders = [hostName:"www.example.com"]
...
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
applicationIdSuffix ".debug"
debuggable true
}
/**
* The `initWith` property allows you to copy configurations from other build types,
* then configure only the settings you want to change. This one copies the debug build
* type, and then changes the manifest placeholder and application ID.
*/
staging {
initWith debug
manifestPlaceholders = [hostName:"internal.example.com"]
applicationIdSuffix ".debugStaging"
}
}
}
Product flavors
Product flavors represent different versions of your app that you may release to users, such as free and paid versions of your app. You can customize product flavors to use different code and resources, while sharing and reusing the parts that are common to all versions of your app. Product flavors are optional and you must create them manually.
定义在productFlavors块中，支持跟defaultConfig相同的属性-this is because defaultConfig actually belongs to the ProductFlavor class。因此你可以配置共有的属性在defaultConfig , 每一个flavor可以根据需要更改其中部分属性(如applicationId等)。
所有的flavors必须隶属于一个flavor dimention, 相当于对flavors进行分类。
Build variants的形成基于buildType + productFlavor. 命名形式为：<product-flavor><build-type>. 如果有不同的flavor dimention, build variants 的命名形式规则为： 较高优先级的flavor dimention的flavors + 低优先级dimention的flavors + build type.
例如：
android{
buildType{
debug {...}
release {...}
}
flavorDimensions "api", "mode"
productFlavors {
demo {
dimension "mode"
}
full {
dimension "mode"
}
minApi24 {
dimension "api"
minSdkVersion 24
versionCode 30000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi24"
}
minApi23 {
dimension "api"
minSdkVersion 23
versionCode 20000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi23"
}
minApi21 {
dimension "api"
minSdkVersion 21
versionCode 10000 + android.defaultConfig.versionCode
versionNameSuffix "-minApi21"
}
}
Gradle creates a total of 12 build variants with the following naming scheme:
Build variant: [minApi24, minApi23, minApi21][Demo, Full][Debug, Release]
Corresponding APK: app-[minApi24, minApi23, minApi21]-[demo, full]-[debug, release].apk
Filter variants
Build variants 由buildtype和productflavors 组合成多种。有时候有一些组合用不着或没有意义，那么就可以通过filter将其过滤掉。如上例中你不需要api23以下的demo版，那么可以添加filter如下：
variantFilter { variant ->
def names = variant.flavors*.name
// To check for a certain build type, use variant.buildType.name == "<buildType>"
if (names.contains("minApi21") && names.contains("demo")) {
// Gradle ignores any variants that satisfy the conditions above.
setIgnore(true)
}
}
Manifest entries
可以在build variant configuration中通过设置manifest的一些属性来配置不同的apk，这些属性有：application name, minimum SDK version, or target SDK version。manifest文件的合并顺序为：
Dependencies
利用 Android Studio 中的 Gradle 构建系统，您可以轻松地将外部二进制文件或其他库模块作为依赖项添加到您的构建中。这些依赖项可位于您的计算机上或远程代码库中，并且它们声明的所有传递依赖项也会自动包含在内。
三种类型依赖项：
apply plugin: 'com.android.application'
android { ... }
dependencies {
// Dependency on a local library module
implementation project(":mylibrary")
// Dependency on local binaries
implementation fileTree(dir: 'libs', include: ['*.jar'])
// Dependency on a remote binary
implementation 'com.example.android:app-magic:12.3'
}
参考：https://developer.android.google.cn/studio/build/index.html#settings-file
PS: minifyEnabled：true 运行混淆文件；false 不运行混淆文件。
