Android Studio+grade Configuration Build

The Android build system compiles application resources and source code, and then packages them into an APK that you can test, deploy, sign, and distribute. Android Studio uses Gradle, an advanced build toolkit, to automate the execution and management of the build process, while also allowing you to define flexible custom build configurations. Each build configuration can define a set of code and resources on its own, while reusing portions that are common to all application versions. Android Plugin for Gradle works with this build kit to provide the process and configurable settings that are dedicated to building and testing Android apps.
　　
Gradle and Android Plugins run independently of Android Studio. This means that you can build Android apps inside Android studio, using command-line tools on your computer, or on a computer that doesn't have Android studio installed, such as a persistent integration server. If you don't use Android Studio, you can learn how to build and run your app from the command line. Whether you build your project from the command line, on a remote computer, or using Android Studio, the output is the same.
　　
Note: Since the Gradle and Android plugins run independently of Android Studio, you need to update the build tool separately. Please read the Release notes to learn how to update the Gradle and Android plugins.
　　
The Android build system is very flexible, allowing you to perform custom build configurations without modifying the application core source files. This chapter helps you understand how the Android build system works and how it can help you customize and automate multiple build configurations. If you just want to learn more about deploying apps, see Build and run projects in Android Studio. To start using Android Studio to create a custom build configuration now, see Configuring build variants.
　　
Build process
　　
The build process involves many tools and processes that transform your project into an Android app package (APK). The build process is very flexible, so it can be helpful to understand how some of its underlying principles work.
　　
Figure 1. The process of building a typical Android application module.
　　
As shown in 1, the build process for a typical Android application module is typically guided by the following steps:
　　
The compiler translates your source code into a DEX (Dalvik executable) file that includes the bytecode that runs on the Android device, converting all other content to compiled resources.
　　
The APK wrapper combines the DEX file and compiled resources into a single apk. However, you must first sign the APK to install and deploy the app to your Android device.
　　
APK Packager uses debug or publish KeyStore to sign your APK:
　　
If you are building a debug version of an app (that is, an app dedicated to testing and analysis), the packager will use the debug KeyStore to sign your app. Android Studio automatically configures new projects with the debug KeyStore.
　　
If you are building an app that you plan to publish out to, the packager will use the publishing KeyStore to sign your app. To create a publishing keystore, read signing your app in Android Studio.
　　
Before the final APK is generated, the packager uses the Zipalign tool to optimize the app to reduce its memory footprint when it runs on the device.
　　
At the end of the build process, you get a debug apk that you can use for deployment, testing, or a publishing apk that you can use to publish to external users.
　　
Custom Build Configurations
　　
The Gradle and Android plugins help you build configurations for the following:
　　
Build Type
　　
A build type defines some of the properties that Gradle uses when building and packaging your app, and is typically configured for different phases of the development lifecycle. For example, the debug build type supports debugging options, uses a debug key to sign the APK, and the release build type compresses, confuses, and distributes the APK with the release key. You must define at least one build type to build your app-Android Studio creates debug and Release build types by default. To start customizing packaging settings for your app, learn how to configure build types.
　　
Product Flavor
　　
Product flavors represent different versions of the app that you can publish to users, such as free and paid app versions. You can customize the flavor of the product to use different codes and resources, while sharing and reusing portions that are common to all app versions. Product flavors are optional, and you must create them manually. To start creating different versions of your app, learn how to configure your product flavors.
　　
Build variants
　　
Building variants is a cross-product of building types and product flavors, and is the configuration that Gradle uses when building apps. You can use build variants to build debug versions of product flavors at development time, or to build signed product flavor release versions for distribution. Instead of configuring build variants directly, you configure the build types and product flavors that make up the variants. Creating additional build types or product flavors also creates additional build variants. To learn how to create and manage build variants, read the configuration build variants overview.
　　
List entry
　　
You can specify values for some of the properties of the manifest file in the build variant configuration. These build values replace the existing values in the manifest file. If you want to generate multiple apk for a module, let each apk file have a different app name, minimum SDK version, or target SDK version to apply this technique. When there are multiple manifests, Gradle merges the manifest settings.
　　
Dependent items
　　
Build systems to manage project dependencies from your local file system and from Remote Storage. This way, you do not have to manually search, download, and copy the binary packages of the dependencies into the project directory. To learn more, learn how to declare a dependency.
　　
Signed
　　
The build system allows you to specify the signing settings in the build configuration and automatically sign your APK during the build process. The build system signs debug builds by using the default keys and certificates for known credentials to avoid prompting for passwords at build time. Unless you explicitly define a signing configuration for this build, the build system will not sign the release version. If you do not have a publishing key, you can generate one as described in signing your app.
　　
Proguard
　　
The build system allows you to specify different Proguard rule files for each build Variant. The build system can run Proguard during the build process to compress and obfuscate classes.
　　
APK Split
　　
The build system allows you to automatically build different apk, and each apk contains only the specific screen density or code and resources required to apply the binary interface (ABI). For more information, see Configuring the APK split.
　　
Building a configuration file
　　
Creating a custom build configuration requires you to make changes to one or more build configuration files (or build.gradle files). These plain text files use a domain-specific language (DSL) to describe and manipulate the building logic in the Groovy language, which is a dynamic language for the Java virtual machine (JVM). You don't need to know Groovy to start a configuration build, because Android Plugin for Gradle introduces most of the DSL elements you need. For more information about the Android plugin DSL, read the DSL reference documentation.
　　
When you start a new project, Android Studio automatically creates some of the files (2) for you, and fills them with a reasonable default value.
　　
Figure 2. The default project structure for Android app modules.
　　
There are several Gradle build profiles that are part of the Android Application standard project structure. You must understand the scope and purpose of each of these files and the basic DSL elements that should be defined in order to proceed with configuration builds.
　　
Gradle settings file
　　
The Settings.gradle file is located at the project root and is used to indicate which modules Gradle should include when building the app. For most projects, the file is simple and includes only the following:
　　
Include ': App '
　　
However, multi-module projects need to specify each module that should be included in the final build.
　　
Top-Level build files
　　
The top-level Build.gradle file is located at the project root and is used to define the build configuration that applies to all modules in the project. By default, this top-level build file uses the Buildscript {} code block to define the Gradle stores and dependencies that are common to all modules in the project. The following code example describes the default settings and DSL elements that can be found in the top-level Build.gradle file after a new project.
　　
/**
　　
* The Buildscript {} block is where you configure the repositories and
　　
* Dependencies for Gradle itself--meaning, you should not include dependencies
　　
* for your modules here. For example, this block includes the Android plugin for
　　
* Gradle as a dependency because it www.hbwfjx.cn/provides the additional instructions Gradle
　　
* Needs to build Android app modules.
　　
*/
　　
Buildscript {
　　
/**
　　
* The repositories {} block configures the repositories Gradle uses to
　　
* Search or download the dependencies. Gradle pre-configures support for remote
　　
* Repositories such as Jcenter, Maven Central, and Ivy. can also use local
　　
* Repositories or define your own remote repositories. The code below defines
　　
* Jcenter as the repository Gradle should use-to-look-for-its dependencies.
　　
*/
　　
repositories {
　　
Jcenter ()
　　
}
　　
/**
　　
* The dependencies {} block configures the dependencies Gradle needs to use
　　
* To build your project. The following www.lieqibiji.com line adds Android Plugin for Gradle
　　
* Version 2.3.2 as a classpath dependency.
　　
*/
　　
dependencies {
　　
Classpath ' com.android.tools.build:gradle:2.3.2 '
　　
}
　　
}
　　
/**
　　
* The allprojects {} block is where you configure the repositories and
　　
* Dependencies used by all modules in your project, such as Third-party plugins
　　
* or libraries. Dependencies that is not required by all the modules in the
　　
* Project should is configured in Module-level build.gradle files. For new
　　
* Projects, Android Studio configures www.120xh.cn Jcenter as the default repository, but it
　　
* Does not configure any dependencies.
　　
*/
　　
allprojects {
　　
repositories {
　　
Jcenter ()
　　
}
　　
}
　　
Module-Level build files
　　
The module-level Build.gradle file is located in each <project>/<module>/directory and is used to configure the build settings that apply to the module in which it resides. You can configure these build settings to provide custom packaging options, such as additional build types and product flavors, and to replace the settings in the Main/app manifest or the top-level Build.gradle file.
　　
The following example Android application module Build.gradle file outlines some of the basic DSL elements and settings that you should know about.
　　
/**
　　
* The first line of the build configuration applies the Android plugin for
　　
* Gradle to this build and makes the android {www.yszx11.cn} block available to specify
　　
* Android-specific build Options.
　　
*/
　　
Apply plugin: ' Com.android. Www.baqist.cn/application '
　　
/**
　　
* The android {} block is where you www.hsl85.cn/configure all your android-specific
　　
* Build Options.
　　
*/
　　
Android {
　　
/**
　　
* Compilesdkversion Specifies the Android API level Gradle should
　　
* Compile your app. This means your app can use the API features included in
　　
* This API level and lower.
　　
*
　　
* Buildtoolsversion Specifies the version of the SDK build tools, command-line
　　
* Utilities, and compiler that Gradle should use to build your app. You need to
　　
* Download the build tools using the SDK Manager.
　　
*/
　　
Compilesdkversion 25
　　
Buildtoolsversion "25.0.3"
　　
/**
　　
* The Defaultconfig {} block encapsulates default settings and entries for all
　　
* Build variants, and can override some attributes in Main/androidmanifest.xml
　　
* Dynamically from the build system. You can configure product flavors to override
　　
* These values for different versions of your app.
　　
*/
　　
Defaultconfig {
　　
/**
　　
* ApplicationID uniquely identifies the package for publishing.
　　
* However, your source code should still reference the package name
　　
* Defined by the package attribute in the Main/androidmanifest.xml file.
　　
*/
　　
ApplicationID ' Com.example.myapp '
　　
Defines the minimum API level required to run the app.
　　
Minsdkversion 15
　　
Specifies the API level used to test the app.
　　
Targetsdkversion 25
　　
Defines the version number of the Your app.
　　
Versioncode 1
　　
Defines a user-friendly version name for your app.
　　
Versionname "1.0"
　　
}
　　
/**
　　
* The buildtypes {} block is where you can configure multiple build types.
　　
* By default, the build system defines the build Types:debug and release. The
　　
* Debug build type is not explicitly shown in the default build configuration,
　　
* But it includes debugging tools and are signed with the debug key. The release
　　
* Build type applies proguard settings and is no signed by default.
　　
*/
　　
Buildtypes {
　　
/**
　　
* By default, Android Studio configures the release build type to enable code
　　
* Shrinking, using minifyenabled, and specifies the Proguard settings file.
　　
*/
　　
Release {
　　
minifyenabled true//enables code shrinking for the release build type.
　　
Proguardfiles getdefaultproguardfile (' proguard-android.txt '), ' Proguard-rules.pro '
　　
}
　　
}
　　
/**
　　
* The productflavors {} block is where you can configure multiple product
　　
* Flavors. This allows your to create different versions of the your app that can
　　
* Override Defaultconfig {} with their own settings. Product Flavors is
　　
* optional, and the build system does not create them by default. This example
　　
* Creates a free and paid product flavor. Each product flavor then specifies
　　
* Its own application ID, so-they can exist on the Google Play Store, or
　　
* An Android device, simultaneously.
　　
*/
　　
productflavors {
　　
Free {
　　
ApplicationID ' Com.example.myapp.free '
　　
}
　　
Paid {
　　
ApplicationID ' Com.example.myapp.paid '
　　
}
　　
}
　　
/**
　　
* The splits {} block is where you can configure different APK builds that
　　
* Each contain only code and resources for a supported screen density or
　　
* ABI. You'll also need to configure your build so, each APK have a
　　
* Different versioncode.
　　
*/
　　
Splits {
　　
Screen density split settings
　　
Density {
　　
Enable or disable the density split mechanism
　　
Enable False
　　
Exclude these densities from splits
　　
Exclude "ldpi", "tvdpi", "xxxhdpi", "400dpi", "560dpi"
　　
}
　　
}
　　
}
　　
/**
　　
* The dependencies {} block in the Module-level build configuration file
　　
* Only specifies dependencies required to build the module itself.
　　
*/
　　
dependencies {
　　
Compile project (": Lib")
　　
Compile ' com.android.support:appcompat-v7:25.3.1 '
　　
Compile Filetree (dir: ' Libs ', include: [' *.jar '])
　　
}
　　
Gradle Properties File
　　
Gradle also includes two properties files, located at the project root, that you can use to specify settings that apply to the Gradle build toolkit itself:
　　
Gradle.properties
　　
You can configure the project scope Gradle settings, such as the maximum heap size for Gradle background processes. For more information, see Building your environment.
　　
Local.properties
　　
Configure the local environment properties for the build system, such as the SDK installation path. Because the contents of this file are automatically generated by Android Studio and are dedicated to the local developer environment, you should not manually modify the file or incorporate it into your version control system.
　　
Synchronizing an item with a Gradle file
　　
When you make changes to your build profile in your project, Android Studio asks you to synchronize your project files so that they import your build configuration changes and perform some checks to ensure that your configuration does not cause build errors.
　　
To synchronize a project file, you can click Sync Now (3) in the notification bar that appears after making the change, or click Sync Project in the menu bar. If Android Studio notifies you of an error in the configuration, for example: your source code uses API features that are only available at the API level above compilesdkversion and displays the Messages window, which describes the problem.
　　
Figure 3. Synchronize the project with the build profile in Android Studio.
　　
SOURCE Set
　　
Android Studio Logically groups the source code and resources for each module into a collection of sources. The main/source set for a module includes code and resources that are common to all of its build variants. Other source set catalogs are optional, and Android Studio does not automatically create these catalogs for you when you configure new build variants. However, creating a main/-like source set can help make Gradle only the files and resources that are used when building a specific version of the app:
　　
src/main/
　　
This source set includes code and resources that are common to all build variants.
　　
src/<buildtype>/
　　
Create this source set to include code and resources that are specific to a particular build type.
　　
src/<productflavor>/
　　
Create this source set to add code and resources that are specific to the flavor of a particular product.
　　
src/<productflavorbuildtype>/
　　
Create this source set to include code and resources that are specific to a particular build variant.
　　
For example, to build the full debug version of an app, the build system needs to merge code, settings, and resources from the following source sets:
　　
src/fulldebug/(build variant source set)
　　
src/debug/(build type source set)
　　
src/full/(product flavor Source set)
　　
src/main/(primary source set)
　　
Note: When you use the File > new menu option in Android Studio to create new files or directories, you can make them for a specific source set. The source set that you can choose depends on your build configuration, and if the required directory does not already exist, Android Studio will automatically create it.
　　
If the homologous set contains different versions of the same file, Gradle determines which file to use (the left source set replaces the files and settings of the right source set) in the following order of precedence:
　　
Build variants > Build types > Product Flavors > Master Source sets > Library dependencies
　　
This allows Gradle to use files that are designed for the build variants you're trying to build, while reusing Activity, application logic, and resources that are shared with other app versions. When merging multiple manifests, Gradle uses the same order of precedence, so that each build variant can define different components or permissions in the final manifest. For more information about creating custom source sets, go to creating a source set for building variants.

Android Studio+grade Configuration Build