[Android] Analysis of Gradle configuration and running in

[Android] Analysis of Gradle configuration and running in

 

Collation

Since it is an analysis, it is natural that there is no in-depth place, and I cannot write in-depth places, I have never used them, and I will not write them out of the pitfalls; the configuration is only used in Gradle of Android Studio.

Gradle

Gradle is based on the Groovy language and mainly oriented to Java applications. An automated build tool based on DSL (domain-specific language) syntax.

Dependency Management

Supports dependency management in multiple ways: including maven remote repository, nexus private server, ivy repository, and jars or dirs of the local file system. This is also my favorite and easy to operate.

New project

A new project contains these files. build is two, and one project is an APP Model. In addition, you can see a manifest folder in the APP, which means there can be multiple AndroidManifest files.

In addition, the gradle. properties file also contains two files, but one is global and the other is project. What is the difference between this file and the above Build File? The difference is that the global file exists in the C: Users user name. in the gradle folder, this file may not exist and needs to be created by yourself. After the file is created, all projects will have access permissions. Generally, some project variables are saved in this file, variables that are irrelevant can be saved in the project file, and variables such as username and password must be saved in the Global File.

The project configuration file is generally empty.

Local. properties

 

## This file is automatically generated by Android Studio.# Do not modify this file -- YOUR CHANGES WILL BE ERASED!## This file should *NOT* be checked into Version Control Systems,# as it contains information specific to your local configuration.## Location of the SDK. This is only used by Gradle.# For customization when using a Version Control System, please read the# header note.sdk.dir=D:ToolKitsAndroidsdk

This includes your sdk configuration. You can also configure the ndk path. The format is the same as that of the sdk.

 

 

Settings. gradle

 

 

include ':app'

This file contains only one sentence. If multiple models exist in your project, you can select which models are included for compilation.

 

 

 

Build. gradle project:

 

The two large volumes of data are clear at first glance. One is prepared for compilation and the other is prepared for all projects.

The Repositories configuration is the dependency management mentioned above, that is, the dependency management server. The default value is jcenter (). You can add other items without interfering with each other.

Dependencies: dependency management. The dependency management server is specified above. This is the specific dependent database.

In combination, it depends on the gradle library in the jcenter () service. The package name is "com. android. tools. build" and the version is 1.0.0.

 

APP Model

In this case, the role can basically be known by name.

The first line:

 

apply plugin: 'com.android.application'

It indicates adding a plug-in. It can be understood as a com. android. application program, that is, an application. If your model is a library, it is naturally:

 

 

apply plugin: 'com.android.library'

 

Dependencies:

This is the so-called dependency. In this case, you can not only perform remote dependency (the method mentioned above), but also perform local dependency:

 

compile fileTree(include: ['*.jar'], dir: 'libs')

This is to say that all jar files in the libs folder are dependent during compilation.

compile project(':library')

What does this sentence mean? This is also dependency, but it depends on a model. As mentioned above, multiple models can be created in a project, this statement is dependent on a model library named library in this project.

 

 

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

This statement depends on a remote library. The function of this library is to use Material Design in earlier versions.

 

Other introductions I have posted before, including dependency on JNI local aar and so on:

 

[Android] [Android Studio] Add a JNI generated file to the Gradle Project (. so file) [Android] [Android Studio] *. jar and *. aar generation and *. aar import Project Method

 

Android details:

Let's take a look at one of the following:

 

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(×.keystore)            storePassword ×××            keyAlias ××××            keyPassword ×××        }    }}

We can see that there are a lot of configuration items that can be configured completely; let me do it one by one:

 

 

    compileSdkVersion 21    buildToolsVersion 21.1.2

The two are the specified SDK compilation and tool version. You can open your SDK Manager to see the specific version.

 

DefaultConfig

This is the default configuration. Since it is the default configuration for a long time, it is equivalent to the global configuration. That is to say, the buildTypes under the configuration here will also be automatically inherited.

You can put a lot of control in this, such as the configuration in buildTypes/release below, you can also put it in:

 

    defaultConfig {        applicationId com.example.qiujuer.application        minSdkVersion 15        targetSdkVersion 21        versionCode 1        versionName 1.0        ndk {            moduleName genius            cFlags -DANDROID_NDK -D_RELEASE            ldLibs m, log, jnigraphics            abiFilters all        }    }

Here, we first configure an applicationId. This configuration is not required, but the database-type Model will not have this configuration.

 

The minimum SDK version is 15, and the target version is 21. That is to say, all the code you use is Android in API21. Then there is the current version code and version name. In Eclipse, these two attributes are in AndroidManifest. in the xml file, we propose separate configuration here so that you can configure different values in different versions.

As for the ndk part here, this is an additional part. Its function is to compile the NDK Code directly without self-execution. For details, see Android Studio development NDK in [Android] environment configuration.
 

BuildTypes

 

The configuration here is your compilation configuration. We can see that there is a release, of course, there is a debug part, and both parts are configured in the same way.

Here, the main configuration is to check whether code obfuscation is performed. Therefore, there is a switch for code obfuscation and a specific file for code obfuscation. There are two types of files, either of which can be used.

 

CompileOptions

A lot of people may not know what this part is, but 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 new features of the corresponding version.

 

 

SourceSets

In this section, the name should have a general meaning, that is, the source code settings. It is a lot of code migrated from Eclipse, most of which will contain this setting, because the Eclipse folder and AS are different, you need to manually specify them.

 

    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']        }    }

The above are some common settings. The last one is the method used to reference the *. so file.

 

 

LintOptions

 

This should actually be written to the end, because this is the lint switch for compiling.

During the buid process, the program executes the lint check. Any errors or warnings will terminate the build and we can disable it.

 

    lintOptions {        abortOnError false    }

 

ProductFlavorsHere you can set some items for your product release. For example, if you need to publish the software to different channels and the package names in different channels are different, you can configure them here; you can even set 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, I am not very familiar with this, so it is basically useless.

 

 

SigningConfigs

 

I believe everyone knows this. It is the configuration of the package signature. You can set a specific signature file, signature password, and so on:

 

    signingConfigs {        release {            storeFile file(×.keystore)            storePassword ×××            keyAlias ××××            keyPassword ×××        }    }

You can click build/generate signed apk, select your file or create a signature file, set the password, and so on. Then remember the password, then you will see this configuration.

 

 

 

 

Some common operations and configurations of Case are finished. For example, a simple small Case.

 

At the root of the APP Model build. gradle file, 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 three parts: delete, copy, and set the connection.

 

Let's talk about the purpose of this Case. The purpose is to copy the debug apk file under build/outputs/apk to the release folder in the project root directory and rename it.

But careful friends should see two parameters: POM_ARTIFACT_ID VERSION_NAME?

The gradle. properties file is written in the gradle. properties file at the root of the project:

After writing, how can I run it? Two Methods: first, right-click the code task and run ():

Second, the command line method:

Enter the Information and Press enter. Wait until the execution is completed. After the execution is successful, the following message appears:

Now let's look at the project:

It is indeed successful!

This is just a very basic usage. It is about so much space. If you have any questions, please comment and reply. If I have accumulated a certain amount, I will write some new usage for the problem, otherwise I will have no clue.