1. Construction of type (Build types)
Android Studio to generate a standard block buildTypes
android {
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile
('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
debug build type has his own default settings, when we create your own building type, and the default will be somewhat different, such as debuggable property is set to true for debug build type, but other types that you create will be set to false
1.1 creating a build type
When the default settings are not sufficient, the easiest way is to create a custom build types, such as
android {
buildTypes {
staging {
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
buildConfigField "String", "API_URL",
"\"http://staging.example.com/api\""
}
}
}
NOTE: It is noted that buildConfigField the third parameter is not directly "" attribute value ", or generating buildConfig this custom class attribute value will not be" ", and thus error, the need to write the above format , or use 'enclosed, which is written "attribute values."
The above code defines a new applicationId suffix, he can make your applicationId different from other versions, such as
- Debug：com.package
- Release: com.package
- Staging: com.package.staging
This means that you can install different versions on the same device.
When you create a new build type, every time you do not need to rewrite the same properties, you can copy other types of properties to initialize, such as
android {
buildTypes {
staging.initWith(buildTypes.debug)
staging {
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
debuggable = false
}
}
}
initWith () method creates a new type of building, type copy all the attributes of an existing building to a new inside, you want to overwrite or define new attributes, only you need to define a new type of building
1.2 set of source files (Source sets)
Create a new type of construction, gradle will create a new source set, the following structure, but these directories are not automatically created, you need to create your own directory structure
app
└── src
├── debug
│ ├── java
│ │ └── com.package
│ │ └── Constants.java
│ ├── res
│ │ └── layout
│ │ └── activity_main.xml
│ └── AndroidManifest.xml
├── main
│ ├── java
│ │ └── com.package
│ │ └── MainActivity.java
│ ├── res
│ │ ├── drawable
│ │ └── layout
│ │ └── activity_main.xml
│ └── AndroidManifest.xml
├── staging
│ ├── java
│ │ └── com.package
│ │ └── Constants.java
│ ├── res
│ │ └── layout
│ │ └── activity_main.xml
│ └── AndroidManifest.xml
└── release
├── java
│ └── com.package
│ └── Constants.java
└── AndroidManifest.xml
Resource files are used by a specified set of source files in a different way, Drawables and layout files will be completely covered by the same name inside the main source file (that is, directly use the new file), but the values following files will not be this way, instead of using merge ,such as
//main里面是这样
<resources>
<string name="app_name">TypesAndFlavors</string>
<string name="hello_world">Hello world!</string>
</resources>
//自己定义的构建类型目录下的String
<resources>
<string name="app_name">TypesAndFlavors STAGING</string>
</resources>
//strings.xml会被合并成这样，在你使用staging构建类型
<resources>
<string name="app_name">TypesAndFlavors STAGING</string>
<string name="hello_world">Hello world!</string>
</resources>
The manifest file is the case, you do not need to copy the entire manifest one, just write part of your need, and finally the system will merge
1.3 dependency (the Dependencies)
Each building type has its own set of dependencies, gradle automatically created for each building type dependent on the configuration, if you only need to add the type of debug logging framework, you can like the following
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
//debugCompile 只为debug类型添加依赖
debugCompile 'de.mindpipe.android:android-logging-log4j:1.0.3'
}
2. Product flavor (Product flavors)
Product flavor is used to configure the same app or library, it is used to create different versions of the same app, for a change of the very few app, such as the change in the logo, url. If you need a new app published to different platforms, you can use Product flavors, or you can continue to use build types
If you feel that what you want to publish more than one version, and different versions of the request to change the flavor of the product can be used much, if not many versions, just testing, formal separation, can be used to configure different build types to build
2.1 Creating product flavor (creating product flavors)
android {
//现在要求每个产品风味必须属于一个产品维度，下面这句现在不能少
flovarDimensions 'api'，'version'
productFlavors {
red {
//指明所属的维度
dimension 'api'
applicationId 'com.gradleforandroid.red'
versionCode 3
}
blue {
dimension 'api'
applicationId 'com.gradleforandroid.blue'
minSdkVersion 14
versionCode 4
}
yellow {
dimension 'version'
applicationId 'com.gradleforandroid.yellow'
minSdkVersion 14
versionCode 4
}
black {
dimension 'version'
applicationId 'com.gradleforandroid.black'
minSdkVersion 14
versionCode 4
}
}
}
The number of products equal to the number of products finally generated in a number of product * api dimension under Version, in this example the number is 4 the final product, which is of course a number of the build type, debug there are four, are the release 4, are redyellow, redbalck, blueyellow and blueblack
Defines the different dimensions of the same attributes, defines the overwritten by the dimension of the first defined
3. Construction of variants (build variants)
3.1 Tasks
Android's gradle plug-in creates a task for each construct variants
3.3 resource files and manifest merger (resource and manifest merging)
android plug-packaged set of source code to the app, the library project there will be additional resources, we may need to apply additional permissions to save the log file debug variant types, but the official version of this request unnecessary privileges could scare away potential users, we should add an additional manifest file to the resource set debug build types to declare additional permissions
Priority (high to low) resources
Build type -》 Flavor -> Main ->Dependencies
If a resource is declared in flavor and a main source set in, falvor in there will be a higher priority, so the flavor source set will be packaged, main of the resource will not be packaged, declared in the library project (library project) is always the lowest priority
3.4 Creating the build variant (creating build variants)
//这和前面内容感觉一样，难道这两种加一块叫做构建变体
//（build type 和 productFlavors）
android {
buildTypes {
debug {
buildConfigField "String", "API_URL",
"\"http://test.example.com/api\""
}
staging.initWith(android.buildTypes.debug)
staging {
buildConfigField "String", "API_URL",
"\"http://staging.example.com/api\""
applicationIdSuffix ".staging"
}
}
//现在要求必须有产品维度，示例少了产品维度
productFlavors {
red {
applicationId "com.gradleforandroid.red"
resValue "color", "flavor_color", "#ff0000"
}
blue {
applicationId "com.gradleforandroid.blue"
resValue "color", "flavor_color", "#0000ff"
}
}
}
3.5 variant filter
If assemble command will build all of the variants, if you want to ignore certain variants can be configured at the top level build.gradle app or library items (that is, module level) in
android.variantFilter { variant ->
if(variant.buildType.name.equals('release')) {
variant.getFlavors().each() {flavor ->
if (flavor.name.equals('blue')) {
variant.setIgnore(true);
}
}
}
}
3.6 Signing Configuration (signing configurations)
Publishing application when the need for different building types use the same signature key, you can use the configuration signature
android {
signingConfigs {
staging.initWith(signingConfigs.debug)
release {
storeFile file("release.keystore")
storePassword"secretpassword"
keyAlias "gradleforandroid"
keyPassword "secretpassword"
}
}
}
To debug the system automatically creates a default signature type configuration, we do not need to create a separate
When you define a signing configurations, they need to be applied to build types or flavors in, build types and flavors have a property called signingConfig
android {
buildTypes {
release {
signingConfig signingConfigs.release
}
}
}
In flavor, the same is
android {
productFlavors {
blue {
signingConfig signingConfigs.release
}
}
}
This usage can lead to errors when you assign a profile to a flavor, it is actually covered build type configuration (debug so this type of flavor under the build type of signature will also be covered to release signature), if you want the flavor of each different build type has a different KEY, the following can be configured so as not to affect the debug build or other type of signature
android {
buildTypes {
release {
productFlavors.red.signingConfig signingConfigs.red
productFlavors.blue.signingConfig signingConfigs.blue
//这样设置，就只会影响release
}
}
}
If you follow the previous configuration, blue flavor debug and release configurations will use signingConfig.release, now, with the release version will be set up to develop