[Android] Analysis of Gradle configuration operation in as

========================================================
Qiujuer
Blog:Blog.csdn.net/qiujuer
Website:Www.qiujuer.net
Open Source Library:Genius-android
Reprint Please specify Source: http://blog.csdn.net/qiujuer/article/details/42342667
========================================================

Order

Since is the analysis, the nature also did not have the deep place, I also cannot write the deep place, oneself has not used, also will not write out deceptive, only is in the Android Studio Gradle uses the configuration only.

Gradle

Gradle is based on the Groovy language and is oriented toward Java applications. Automated building tools based on DSL (domain-specific language) syntax.

Dependency Management

Support multi-mode dependency management: Includes jars or dirs from the MAVEN remote repository, the Nexus, The Ivy Warehouse, and the local file system. This is also my favorite place, easy to operate.

New Project

A new project contains these files, build is two, one project is the APP Model. In addition, you can see a manifest folder in the APP, which means you can have multiple androidmanifest files.

Also worth saying is that the Gradle.properties file also contains two, but it is a global, one is the project; How does this differ from the Build file above? The difference is that the global file exists in the C:\Users\ user name \.gradle folder, the file may not be created, you need to create it, all projects will have access to it, in this file is generally saved is a number of project variables, etc. If the variables are insignificant, they can be saved in the project file, and variables such as user name passwords need to be saved in the global file.

As for the project configuration file is generally empty.

Local.properties

# # This file was automatically generated by Android studio.# does not modify this file--YOUR changes would be erased!## this File should *not* is checked into Version Control systems,# as it contains information specific to your local Configurati on.## location of the SDK. This was only used by gradle.# for customization if using a Version Control System, please read the# header note.sdk.dir= D\:\\toolkits\\android\\sdk

It includes your SDK configuration, and you can configure the NDK path as well, in the same format as the SDK.

Settings.gradle

Include ': App '

The file contains just one sentence, and you can choose which to include in your project if more than one Model exists.

Build.gradle Project:

Two large surrounds are clear, one is prepared for compilation, and one is for all projects.

The repositories is configured with the above-mentioned dependency management, which is the server that relies on management. The default is Jcenter () you can add other, no interference between the multiple.

Dependencies This is also dependent on the management of things, the above is the designated dependent management of the server, this is the specific dependencies of what library.

Together, that is, relying on the Gradle library in the Jcenter () service, whose package name is: "Com.android.tools.build", the version is: 1.0.0 version .

APP Model

In this the basic can be known by the name of its role.

First line:

Apply plugin: ' Com.android.application '

is to add a plug-in, which can be understood as the model for a com.android.application program, which is the application, if your model is a library, then nature is:

Apply plugin: ' Com.android.library '

dependencies:

This is the so-called dependency, which can be relied upon not only for remote dependencies (the method described above), but also for local dependencies:

Compile Filetree (include: [' *.jar '], dir: ' Libs ')

This means that compile-time relies on all jar files under the Libs folder.

Compile project (': library ')

What is the meaning of this sentence? This is also dependent, but relies on a model, said in a project can have more than one model, this sentence meaning is dependent on a project name is the library model libraries.

Compile ' com.android.support:appcompat-v7:21.0.3 '

As far as this sentence is dependent on a remote library, the role of this library is to use a certain Material Design in the lower version.

Some of the other introductions I have previously sent can be seen, including dependency on JNI local AAR and so on:

• [Android] [Android Studio] Add a JNI build file (. so file) to the Gradle project
• [Android] [Android Studio] *.jar and *.aar's Build and *.aar Import Project method

tell me more about the Android section:

First take a look at the basic complete one:

Android {    compilesdkversion android_build_target_sdk_version as int    buildtoolsversion Android_build_tools_ VERSION    defaultconfig {    }    buildtypes {    }    compileoptions {    }    sourcesets {    }    lintoptions {    }    productflavors {        flavor1 {        }        flavor2 {        }    }    signingconfigs {        Release {            storefile file ("X.keystore")            storepassword "xxx"            keyalias "xxxx"            Keypassword "x XX "        }}    }

You can see that if it is complete there are a lot of places that can be configured, and let me one way:

    Compilesdkversion    buildtoolsversion "21.1.2"

These two are the specified compilation SDK and the editing tool version, which can be opened by your SDK Manager.

Defaultconfig

This nature is the default configuration, since it is the default configuration for a long time equivalent to the global configuration, which means that the side of the configuration of the following buildtypes will automatically inherit.

In this you can put a lot of control, such as the following buildtypes/release in the configuration you can also put into it:

    defaultconfig {        ApplicationID "com.example.qiujuer.application"        minsdkversion        targetsdkversion 21        Versioncode 1        versionname "1.0"        ndk {            modulename "genius"            cFlags "-dandroid_ndk-d_release"            ldlibs "M", "Log", "Jnigraphics"            abifilters "All"        }    }

Here, a ApplicationID configuration is first made, and the configuration is not required, but the Model of the library type will not be configured.

The following is naturally the smallest SDK version is 15, the target version is: 21 that is, the code you use is all API21 Android. Then there is the current version code, the version name, in Eclipse the two properties are in the Androidmanifest.xml file, which is presented here to be configured separately so that you can configure different values in different release versions.

As for the NDK section here, this is what I added, its role is to directly compile the NDK code, do not need to do their own, see: [Android] Environment configuration of the Android studio development NDK

Buildtypes

The configuration here is your compilation configuration, you can see there is a release, of course, there is the debug section, two parts configuration is the same.

The main configuration here is whether or not to code confusion, so there is a code to confuse the switch, as well as the code to confuse the specific file, there are two kinds of files, regardless of which line.

compileoptions

A lot of people may not know what this part is for, it is clear from the following:

    compileoptions {        sourcecompatibility javaversion.version_1_7        targetcompatibility JavaVersion.VERSION_1_7    }

Here you can configure the Java version to use some of the new features of the corresponding version.

sourcesets

In this section, the name should have a general meaning that is the source setting, which is a lot of code migrated from Eclipse, most of which will have this setting, because the Eclipse folder and as are not the same, so you need to specify manually.

    Sourcesets {        Main {            manifest.srcfile ' androidmanifest.xml '            java.srcdirs = [' src ']            resources.srcdirs = [' src '] aidl.srcdirs = [' src '] renderscript.srcdirs = [' src ']            res.srcdirs = [' res ']            assets.srcdirs = [' Assets ']            Jnilibs.srcdirs = [' Libs ']        }    }

These are some of the most commonly used settings, the last of which is the method used when referencing the *.so file.

lintoptions

This should actually be written to the last, because this is the lint switch that sets the compilation.

When the program is BUiD, the lint check is performed, any errors or warning prompts will terminate the build and we can turn it off.

    lintoptions {        abortonerror false    }

productflavorsHere you can set up some things about your product release, such as you are now a total of software needs to be published to different channels, and different channels of the package name is different, you can configure here, and even can set a different androidmanifest.xml file.

    productflavors {        Flavor1 {            packagename= ' com.example.qiujuer.application1 '            manifest.srcfile ' Exampleapk/androidmanifest1.xml '        }        flavor2 {            packagename= ' com.example.qiujuer.application2 '            Manifest.srcfile ' Exampleapk/androidmanifest2.xml '        }    }

However, for this I do not commonly used, it can be said that basically useless.

Signingconfigs

This believes that everyone knows, is the configuration for the package signature, you can set the specific signature file, signature password and so on:

    Signingconfigs {        Release {            storefile file ("X.keystore")            storepassword "xxx"            keyalias "xxxx            " Keypassword "xxx"        }    }

This can not be created by yourself, you can click Build/generate signed apk, select your file or create a signature file, set a password, and so on, then choose to remember the password, then you will see this configuration.

Case some of the commonly used operation configuration is finished, to say, a simple small cases.

At the root of the APP Model build.gradle file we add:

Task clearapk (type:delete) {    Delete ': /release/' + pom_artifact_id + ' _ ' + Version_name + '. apk '}task makeapk (type:copy) {from    (' build/outputs/apk/')    Into ('.. /release/')    include (' app-debug.apk ')    rename (' app-debug.apk ', pom_artifact_id + ' _ ' + Version_name + '. apk ')} Makeapk.dependson (clearapk, build)

The code is divided into 3 parts: Delete, copy, and a setting to connect it.

First of all, the purpose of this case is to copy the debug apk file under build/outputs/apk to the release folder in the project root directory and rename it.

But a careful friend should see it. There are two parameters:pom_artifact_id version_name Where do these two come from?

The first thing I said earlier: the Gradle.properties file, which is written in the Gradle.properties file at the root of the project:

Write it, how to run it? Two ways, the first, right-click on the code task, run ():

Second, command-line mode:

Enter after entering, wait for execution to complete, after success will appear:

Now look at the project:

It did succeed!

This is only a very basic usage, confined to the space is almost so many, if you have doubts, can comment on the reply, if I accumulate a certain amount, I am good for the problem to write some new usage, otherwise I also very have no clue.

========================================================
Qiujuer
Blog:Blog.csdn.net/qiujuer
Website:Www.qiujuer.net
Open Source Library:Genius-android
Reprint Please specify Source: http://blog.csdn.net/qiujuer/article/details/42342667
========================================================

[Android] Analysis of Gradle configuration operation in as