Unlike Eclipse, an open source, Java-based, extensible development platform, Android Studio uses Gradle to build projects. Gradle is a very advanced project building tool that uses a Groovy-based Domain-specific language (DSL) for project setup, eliminating the cumbersome configuration of traditional XML-based systems such as Ant and Maven.

The HelloWorld project has two build.gradle files, one in the outermost directory and one in the app directory. Both files are crucial to building an Android Studio project, so let’s take a closer look at them.

Let’s look at the build.gradle file in the outermost directory:

The outer build.gradle file should look like this:

// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    ext.kotlin_version = '1.3.72'
    repositories {
        google()
        jcenter()
        
    }
    dependencies {
        classpath 'com. Android. Tools. Build: gradle: 3.5.2'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        jcenter()
        
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}
Copy the code

This code is automatically generated, and while the syntax may seem a little hard to understand, it’s actually quite easy to understand if you ignore the syntax and just look at the most important parts.

First, the Google () and JCenter () configurations are declared in the closure of both repositories. What do they mean? In fact, they correspond to a code repository. The Google repository contains mainly Google’s own extension dependency libraries, while the JCenter repository contains mostly some third-party open source libraries. With these two lines of configuration declared, we can easily reference any of the dependent libraries in the Google and JCenter repositories in our project.

Next, the Dependencies closure declares two plug-ins using classpath: a Gradle plug-in and a Kotlin plug-in. Why declare Gradle plug-ins? Since Gradle is not specifically designed to build Android projects, Java, C++ and many other projects can also be built using Gradle, so if we want to build Android projects using Gradle, Requires the statement com. Android. View the build: gradle: 3.5.2 this plug-in. The last part is the plug-in version number, which usually corresponds to the current Android Studio version. For example, if I am using Android Studio version 3.5.2, the plug-in version number here should be 3.5.2. The other Kotlin plug-in indicates that the current project is being developed using Kotlin. If it is a Java version of an Android project, you do not need to declare this plug-in. As I write this tutorial, the latest version of the Kotlin plug-in is 1.3.72.

This completes the analysis of the build.gradle file in the outermost directory. In general, you don’t need to modify this file unless you want to add some global project build configuration.

Gradle: build.gradle: build.gradle: build.gradle: build.gradle

apply plugin: 'com.android.application'

apply plugin: 'kotlin-android'

apply plugin: 'kotlin-android-extensions'

android {
    compileSdkVersion 31
    buildToolsVersion "31.0.0"
    defaultConfig {
        applicationId "com.example.helloworld123"
        minSdkVersion 21
        targetSdkVersion 31
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs'.include: ['*.jar'])
    implementation"org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
    implementation 'androidx. Appcompat: appcompat: 1.0.2'
    implementation 'androidx. Core: the core - KTX: 1.0.2'
    implementation 'androidx. Constraintlayout: constraintlayout: 1.1.3'
    testImplementation 'junit: junit: 4.12'
    androidTestImplementation 'androidx. Test. Ext: junit: 1.1.0'
    androidTestImplementation 'androidx. Test. Espresso: espresso - core: 3.1.1'
}
Copy the code

The contents of this file are a little more complex, so let’s take a look at them line by line.

The first line applies a plug-in, usually with two values: com.android.application indicates that it is an application module, com.android.library indicates that it is a library module. The biggest difference is that application modules can be run directly, whereas library modules can only be run as code libraries attached to other application modules.

The next two lines apply the kotlin-Android and Kotlin-Android-Extensions extensions. If you want to use Kotlin to develop an Android project, the first plug-in is a must. The second plug-in helps us implement some nice Kotlin extensions, and you’ll see how convenient it is later on.

This is followed by a large Android closure where you can configure various properties for your project build. CompileSdkVersion specifies the compiled version of the project. 31 indicates that the SDK of Android 11 is used to compile the project. BuildToolsVersion is used to specify the version of the project build tool. Here version 31.0.0 is used, and Android Studio will alert you if a newer version is available.

We then see that the Android closure has a nested defaultConfig closure that allows you to configure more details about your project. The applicationId is the unique identifier of each application and must not be repeated. By default, the package name we specified when creating the project is used. If you want to change it later, this is where you change it. MinSdkVersion specifies the least compatible Android version of the project. The value 21 indicates the least compatible Android 5.0. The value specified by targetSdkVersion indicates that you have done enough testing on the target version and that the system will enable some of the latest features and features for your application. For example, Android 6.0 introduced runtime permissions. If you set targetSdkVersion to 23 or higher, the system will enable runtime permissions for your application. If you set targetSdkVersion to 22, This means that your application has only been fully tested on Android 5.1 at best, and the new features introduced in Android 6.0 will not be enabled. The next two properties are simpler, versionCode for specifying the version number of the project and versionName for specifying the versionName of the project. Finally, testInstrumentationRunner is used to enable the JUnit test in the current project, you can write test cases for the current project, in order to make sure the correctness of the functionality and stability. (defaultConfig is also basically ignored in the initial stage, and we will see if there are any problems.)

After analyzing the defaultConfig closure, let’s look at the buildTypes closure. The buildTypes closure, which specifies the configuration to build the installation file, usually has only two child closures: DEBUG and Release. The DEBUG closure is used to specify the configuration for generating the beta installation files, and the Release closure is used to specify the configuration for generating the official installation files. In addition, debug closures can be ignored (they are not generated directly here), so we see that there is only one Release closure in the code above. Let’s take a look at the details in the Release closure. MinifyEnabled specifies whether the project code should be obfuscated, with true indicating obfuscation and false indicating not. ProguardFiles is used to specify the obtrusion rule file, there are two files specified here: the first proguard-Android-optimize. TXT is in the /tools/proguard directory, which contains the obtrusion rule common to all projects; The second proGuard-rules.pro is in the root directory of the current project, where obfuscation rules specific to the current project can be written. It is important to note that running the project directly through Android Studio generates the beta installation files. We will discuss how to generate the official version installation files later (we can also baidu in advance).

This completes the analysis of the entire Android closure, followed by the Dependencies closure. This closure is powerful enough to specify all dependencies for the current project. There are generally three types of dependencies for Android Studio projects: local, library, and remote.

  1. Local dependencies you can add dependencies to local JAR packages or directories
  2. Library dependencies you can add dependencies to library modules in your project
  3. Remote dependencies can add dependencies to open source projects on the JCenter repository

Looking at the configuration in the Dependencies closure, the implementation fileTree in the first line is a local dependency declaration that adds all.jar files from the libs directory to the project’s build path.

And implementation is long-range dependence statement, androidx appcompat: appcompat: 1.1.0 remote dependent libraries is a standard format, including androidx. Appcompat is domain part, used in libraries and other company do distinguish; Appcompat is the project name part used to distinguish different library projects in the same company. 1.1.0 is the version number used to distinguish between different versions of the same library. With this statement, Gradle first checks to see if the library is already in the local cache when building a project. If it is not, the library is automatically downloaded online and then added to the project’s build path.

And the library dependency declaration, which we don’t use here, the basic format is implementation Project with the name of the library that we’re going to rely on, so let’s say there’s a library module called Helper, So to add the library dependencies, just add the implementation Project (‘: Helper ‘) declaration. And we’ll see that later on.

The other remaining testImplementation and androidTestImplementation library is used to declare the test cases, this we temporarily can’t use, it is ok to ignore it.