Android Gradle Introduction Official Tutorial

This tutorial is organized according to the official Gradle video tutorial.
https://classroom.udacity.com/
There are many video tutorials that Google has done.

Since the abandonment of eclipse, hot pursuit as, there has been a gradle. For the crayon, Gradle is a bird thing. I don't understand it at all. There are not many people who believe in playing Gradle. Fortunately, as the project is created, as will be the default Gradle script, as follows:

Although do not understand gradle, but a random basic Android Gradle tutorial can be. However, with the expansion of the project, in the App.gradle this script appeared a variety of not seen problems, and then various Google, various summaries, various do not know why.
If you're dealing with a person more deeply, the first thing you need to do is to get to know the person. Let's go!

The basic settings for compilesdkversion, Buildtoolsversion, and Defaultconfig are obvious under the Android node in the App.gradle script. Let's take a look at buildtypes.
Buildtypes
Buildtypes build type, generally can be divided into debug (mainly for development phase) and release (production release phase)

The debug or release can also be combined with some specific product styles, such as free or paid versions of the app. (That is, if your app needs a free version and a paid version, the first thing you might think about is doing two projects, a free version of the project and a paid version of the project.) But if you know the product style this thing, will understand, can be done in a project, only need to put the difference code in the corresponding two style source. I'll talk about it later. ）

Let's take the release setup as an example to understand some of the configuration under the node:
1. minifyenabled False/true set whether to use optimized packaging
2. Proguardfiles set Proguard file (for confusing code)

Resource Merging resource integration

Android Gradle can allow you to customize the behavior, you can create a global rotation of the various source groups, depending on the variant you are constructing, it will merge the various sources. It is important to note that there is a main source group (Src/main structure directory) located in the main part of the source, which is where we have been storing all our code so far. In addition, each product style has a source group (Src/free, paid, debug, release, etc.).
For example (reference structure):
If we have a free and a paid product style. Each build type also has a source group, in which case debugging and publishing. Finally, each final variant has one source, corresponding to the source free debug, free release, paid debug, paid Release four sources. If you have the sources and resources you need in a paid style rather than a free style, you can put it into a paid source, and if you have sources and resources in a debugging style rather than a publishing style, you can put it into a debug source.

Style Customization
The above-mentioned product style (free version, paid version), not placed in the buildtypes, need to be placed in the same class productflavors.
How to write the product style, please see:

After the gradle is synchronized, you see the resulting variant in the Build variants form in the lower-left corner of AS.

These different styles do not actually perform any different operations. By default, the source and resource bundles in the primary source (Src/main) Set are included in all application variants. However, if we declare other styles, the Android plugin will automatically create a new source set for us. So, if we want to include code that is dedicated to paid versions, you can have source-paid Java code and source-paid resources. Similarly, you can also have source free Java code and source free resources. Gradle each application variant, other sources in each style-specific file are automatically packaged.
You can also set defaultconfig in different styles.

/*免费版风格 的 应用*/        free {            "com.zrb.gradletest.free"            15            23            1            "1.0"        }

dependency configuration based on version
The Android Gradle plugin can create a set of configurations for each build variant. This allows us to manage dependencies independently for each of our variants. In this case, we will have the usual compile and run-time configuration. Arrows indicate extended relationships (runtime configuration extensible compilation Configuration)

The free runtime configuration expands the free compilation configuration, and the free compile configuration expands the default compilation configuration. This means that the free changes will include all default dependencies, and the dependencies of the free configuration, but do not include the dependencies of the paid configurations.
To set the version dependency relationship:

dependencies {    compile fileTree(dir‘libs‘, include: [‘*.jar‘])    ‘junit:junit:4.12‘    ‘com.android.support:appcompat-v7:23.1.1‘}

Apply Signature
To apply the signature, you need 3 steps: 1 Create a KeyStore and key, and on the As menu bar click Build and select Generate signed APK to create it.

2 Create a login configuration in Build.gradle, and set it in signing in project structure

Once you have completed the confirmation, Build.gradle will automatically update and generate the Signingconfigs configuration script.

3 Assign a login configuration to a build type; Also in project structure, the operation

Once determined, a signature point is generated in the corresponding build type in Build.gradle, such as:

Multidex Support
Some people may encounter such problems, when the number of methods of the project is greater than 65k, these methods can not be integrated into a DEX, this need to be configured by the line Multidex. Add multidexenable True under the Defaultconfig node of the Build.gradle.

The

configuration Proguard
Android plugin can reduce the size of your app by removing unused code and resources. It does this with a tool called Proguard. Proguard can do a lot of interesting work, including confusing your code with meaningless names from your classes and methods. However, this is important when you are really worried about the code being reverse engineered. For our purposes, we want the properties configured on the build type to be minifyenabled and shrinkresources. We have declared our reliance on the Google Mobile Service library, but we do not actually use any of the content in this library. Proguard is so smart that he can infer unused code and remove it from our apk. The Mobile service library also includes a number of resources, such as a drawing diagram of the sign-in button. Turning on Shrinkresources will remove any unused resources.

Android Test
This piece is very content to dig, if can master Andrid test, to the project quality improvement will be very helpful. I'll do a more detailed study of Android testing later. Here is the main introduction.
Major sub-unit testing and link testing.
Unit testing is run on a PC's Java VM, which means it doesn't need to run on Android settings.
The connection test needs to run on the device.
Typically, you should use unit tests when testing generic classes that are not related to Android. In fact, any code that calls the Android API will have an exception because unit testing violates the implementation of the simulated Android STK. You should use a mock-up framework like Makido to simulate a suitable Android dependency or you can use a connection test. In addition, you can configure test options in a script created by Gradle to build a simulated Android implementation to return the default value instead of throwing an error. In any case, as a developer, you can decide how to better write your tests and how to build your code in such a way that simplifies testing.
Link tests should be used to test logic that relies on the Android API, or more advanced tests such as integration testing and performance testing. Remember, the connection test is packaged in the form of an APK installed on the device. There will be more to spend in the actual operation process.
Both the unit test and the connection test have their own source set, under the SRC path, respectively, called Test and Androidtest. The test also has the concept of "version". Allows you to write tests for build types and product styles, whose naming conventions follow the same pattern as the application code, except that they have more than the test and androidtest prefixes.

Android Gradle Introduction Official Tutorial