DEV Community

Cover image for Understanding specifics of the Android build file.
Tristan Elliott
Tristan Elliott

Posted on • Edited on

Understanding specifics of the Android build file.

Introduction

  • This series is going to be dedicated to the basic to Android development. Join me and let us try to build and understand some cool stuff. This post will be on understanding what the properties of our build files do. If you are unfamiliar with the syntax of the build files, please take a look at my previous post located HERE

Getting started

  • The first thing I am going to do is paste the code and then we will walk through the code line by line until we are done.
plugins {
    id 'com.android.application'

}

android {
    compileSdkVersion 30

    defaultConfig {
        applicationId "com.example.criminalintent"
        minSdkVersion 23
        targetSdkVersion 30
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {

        release {
            println(getDelegate())
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8

    }
}

dependencies {

    implementation 'androidx.appcompat:appcompat:1.3.0'
    implementation 'com.google.android.material:material:1.3.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
    implementation 'androidx.recyclerview:recyclerview:1.2.1'
    testImplementation 'junit:junit:4.+'
    androidTestImplementation 'androidx.test.ext:junit:1.1.2'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}

Enter fullscreen mode Exit fullscreen mode

Plugins

  • The plugin block of code(plugin DSL) is where we define the plugins our app uses. If you are unfamiliar with plugins just remember they make the wheels go round in Gradle.

  • id 'com.android.application' is a plugin the provides Gradle with specific features that are unique to building Android apps. Without this plugin our app will not build. If you are interested about plugins, HERE is a link to the official Gradle plugin repository.

android{...}

  • This marks the starting point of where to enter all the specific android build configurations.

compileSdkVersion 30

  • This indicates the API level our app will be compiled with. In other words, you can not use features from an API that is higher than the value specified here. For us that API level is 30.

defaultConfig{...}

  • Inside this block we specify defaults for variant properties that the Android plugin applies to all build variants(release,debug...).

applicationId "com.example.criminalintent"

  • Every app has this Id and it uniquely identifies the app on devices and in the google play store. Although the application ID looks like a traditional Java Package name, the naming convention actually has rules.
  • 1): It must have at least 2 segments(one or more dots)
  • 2): Each segment must start with a letter
  • 3): All characters must be alphanumeric or an underscore [a-zA-Z0-9_]

minSdkVersion 23

  • Marks the minimum version of the Android platform on which the app will run.

targetSdkVersion 30

  • Specifies the API level on which the app is designed to run.

versionCode 1

  • A positive integer used as an internal version number. This is not shown to the users, it is used by the Android System to protect against downgrades.

versionName "1.0"

  • Is a string that gets shown to users and it should reflect the internal versionCode.

testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"

  • This is where we set the test runner, a test runner is just a tool that Android uses to run tests. In this case we set the test runner to the AndroidJUnitRunner class which is the default test runner. It allows us to run JUnit3 and JUnit4 tests on Android devices. Just so we are not confused, AndroidJUnitRunner runs the tests and JUnit is how we write the tests.

buildTypes{...}

  • Inside this code block is where we define properties that Gradle uses when building and packaging the app. We can only configure build types in the module-level build.gradle file.

release{...}

  • This is an example of a build type in Android and it gets automatically created for us. Anything that we define inside release{...} will be specific to this build type.

minifyEnabled false

  • Determines if we have code shrinking enabled or not, false means we do not have it enabled. What is code shrinking? Well it is the ability to remove unused code and resources from the released build. When we push our app to production we should set this to true.

proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'

  • Specifies the rules for compiling, by default no rules are specified. If you want to see the file where we could change the rules from default, you first need to switch to the project view inside of android studio. Then navigate to the app/proguard-rules.pro file. Notice how no rules are specified.

compileOptions{...}

  • In this block of code we define our compile options.

sourceCompatibility JavaVersion.VERSION_1_8

  • Determines the language level for the Java that we are using. In this case we have specified Java 8.

targetCompatibility JavaVersion.VERSION_1_8

  • The version of the generated byte code. The version that we have chosen for the byte code is also version 8.

dependencies{...}

  • This code block is where we tell Gradle what external libraries or internal JAR files we want to use in our project.

implementation

  • Using implementation is how we state what kind of dependencies we are going to use. There are a few different kind of implementations but the one that we are going to use is called a Remote Binary. The syntax for declaring a remote binary goes like this, <package-name>:<class-name>:<version-number>. Notice the similarities when comparing to this:androidx.appcompat:appcompat:1.3.0.

testImplementation

  • Just adds a remote Binary dependency for local tests.

androidTestImplementation

  • Adds a remote binary dependency only for the instrumented tests. A instrumented test is just a test that runs on a emulator or a physical device.

References

  • All my references can be found HERE
  • I added all my references to a cool little site called Ticketnote. Make sure to check them out HERE

Conclusion

  • Thank you for taking the time out of you day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on Twitter.

Top comments (0)