Exploring the power of Gradle in android studio - Basics & Beyond

Editor's Notes

• #2: Welcome!!! Introduction
• #5: Before build tools people used things like “Make” in unix and java. Which was tedious. Define build automation tools. Discuss about Ant and Maven. Ant (XML) – James Duncan Davidson
• #6: Some of Gradle’s advantages over Ant Ant build files can grow quickly and very difficult to maintain as the project grows Standard slides.
• #7: Maven has several advantages over Ant. Standard slides.
• #8: Gradle combines best of both Ant and Maven and uses Groovy DSL as build script. Open source – hence good community support Will see benefits of gradle as we go along Will how exactly is Gradle customizable
• #9: Gradle combines the best of Ant and Maven, adds Groovy DSL and additionally supports ivy dependencies
• #10: 1 - How to add maven, ivy dependencies 2 – Support local project modules 3 – Support local binaries We are all android devs. There is one more addition here, that is the aar files (short for android archive). It is a simple zip file for android library projects. Show the gradletestlib aar files
• #11: As you can see here, if you don’t want to follow standard project structure, you can specify your own. This is powerful feature for supporting legacy libraries and project modules. In java the android closure is not there. The snapshot is from android project
• #12: You don’t need to have gradle installed when using gradle wrapper. This is very handy. If you fire a gradle command in your android studio terminal, it will say command not found (unless you have installed it). So use gradlew to issue gradle commands. Android has already done this for us, so we don’t need to install gradle. We can fire gradlew command on windows and ./gradlew on *nix and Mac
• #13: Gradle tasks are basic building blocks for source compilation. We will see tasks in little bit details in coming slides Why this is needed? Why it is good to know
• #14: Say a task depends on another projects task. This class will need an instance of that project to compile. That is initialization phase. Everything inside a task that is not an action is executed in configuration phase. Execution of the task is the final phase.
• #15: Here doFirst and doLast are actions. You can create your own custom actions by extending your class from defaultTask class Description and some other statements are executed during configuration phase A task can have multiple doFirsts and doLasts. This is a very powerful features and one of the reasons why Gradle is so damn customizable
• #16: A few ways of defining tasks. There are more ways to define a task, look it up if you are interested. The double left shift means next closure is doLast method closure
• #17: A simple task to print build directory of the project. This is nothing complex. No configuration and only one action. In android studio terminal - The point to note here is we are issuing gradlew command instead of gradle. We don’t want to download new version of gradle, we want to use the wrapper instead. –q is quite flag The first time you fire this command gradle will automatically download any related dependencies Lets see it in action. Lets see a task that is a little bit complex.
• #18: Using this command prompt alternative called cmder, using command prompt will give you same results. So now we know about: Gradle build system, Gradle DSL, Tasks, Task creation and its lifecycle, customizing project structure and creating
• #19: Some useful tasks has been defined in gradle we can reuse those as typed tasks. Another weapon in your arsenal
• #20: After the copy docs configuration phase, gradle will treat copyDocs task as if it is copy task. For more flexibility use copySpec Copy task can be used to copy and / or rename files Using this in android studio next
• #21: This is a copy task and it copies all the files from one folder to another. It has some actions it got from Copy task of gradle and a do Last action. It has some properties (description and group). The srcPath is the output apk path of the demo android project and the destPath is some folder destination to copy files into. So what does it mean and what is it good for? (<<NEXT>>) Whenever we run this task it copies all the files (apks in this case) in a predefined location. Lets run it and see. But for this task to work we need to run the gradlew command. If we can automate this then, it can be used as custom archive uploader
• #22: This task is similar to the prev task except the destination folder is different. Discuss how can this be useful. Or you can copy entire source code and resources if you want To reuse the logic you can create custom gradle task
• #23: You can define your own custom class and actions like this. But we don’t usually need to do this unless we are creating a plugin or a custom layer for android studio. It’s there if you want to use it. Let’s see how to make tasks dependent on each other
• #24: Another example of Typed task If you haven’t done project clean then you have apk of you latest changes residing in build folder. This will install that apk in the connected device. This saves a lot of time when all you need to do is install an apk in an android device..
• #25: A task can have multi-level and multiple dependencies. Gradle figures out order of execution itself. For example: apkSigner task has dependency on build task, compile task etc. So how can we make one task dependent on another???? Here we will see the real power of gradle. Why is gradle called easily and highly customizable We will see its usage in android studio
• #26: Many ways to enable task dependencies. We are covering 4 of those here. You can see various ways of declaring task dependencies using depends on. Again there can be multiple depends on. We will see its uses in demo but just by looking at it you can see how gradle is so customizable
• #27: There are many ways of defining mustRunAfter too. Here is an example (in the slide). Again there can be multiple mustRunAfters. We will see its uses in demo but just by looking at it you can see how gradle is so customizable However there is one issue here. What if TaskA -> after TaskB -> after TaskC -> after TaskA. It can lead to circular dependencies. So please be careful while using this
• #28: Same as mustRunAfter but skips any circular dependencies if present
• #29: finalizedBy is kind of like inverted dependency. Like we know that taskB must be executed before taskA if taskA dependsOn taskB. finalizedBy tells gradle that this task will be only over after finalizedBy task is executed As usual there will can be many finalized bys gradle keeps appending those here. We will see an example of it in android
• #30: All of this is done via gradle tasks. Link for more details about build process. Discuss it. We will see in a few slides how we can make use of customizability and flexibility of gradle in android studio. How to assign more task to the android build process. Lets create a simple task first
• #31: If you open the gradle tab on the right hand side of android studio you will see huge number of tasks. All related to build process in android. These are project specific (depends on variants) tasks so don’t worry if you see awkward task names here. This task list can also be seen by issuing gradlew tasks command in studio terminal. Show it in studio. And because of the beauty of gradle these pre-defined tasks can be extended to do more. We will see how in coming slides (append multiple doFirsts and doLasts). All these tasks are related to the build process.
• #32: We can use task dependencies to automate tasks. We can make the clean task depend on this task, so whenever we perform a clean project the apks in the output folder are copied to our custom location. And then clean does its stuff and deletes everything from the build folder We want this task to run every time after a particular (or any) apk is generated. We can use finalizedBy here. e.g. assembleDebug.finalizedBy apkLatestCopier. See it in action
• #33: So now we know about: Task reusability by Typed tasks, task dependencies, Gradle wrapper, android build process and tasks, and creating our own custom tasks in android studio
• #34: One last thing to cover before moving any further is gradle wrapper. We all know the plugin called “'com.android.application'” we use it in app level build.gradle (usually first statement) We will see what tasks are added when we apply java plugin in demo If your build logic is getting complex, it is a recommended practice to separate out common logic into a separate gradle file. There are several other ways to apply a plugin. Like inside buildscript or in plugins block or from libraries. Those are out of scope of this session.
• #35: Applying binary plugins in build gradle files. Application plugin gives gradle the ability to run an application. We’ll see in a demo (strictly java). The plugins are picked from jCenter or mavenCentral unless specified otherwise
• #36: A simple script plugin for renaming default android apk name. You can create separate task for this or directly loop through the variants in module’s build.gradle. This is just a demo of script plugin and applying it
• #37: So now we know about: Gradle plugins, its types, creating and applying script plugin in android studio, running a java application using gradle
• #38: We can define methods and variables in gradle like we do in java and we can use that anywhere in the gradle file as long those are in scope. Lets see how we can use this in android studio
• #39: One recommended practice with android is upgrading the version of apps everytime before install. But we have do it manually. Using gradle to automate this process. There can be many ways to do this. Lets see using timestamp (we can use svn revision, a separate properties file etc.). <<NEXT>> This is how to define variables and methods in gradle. See the demo
• #40: Gradle can treat manifest like a regular file and update it. You can see here the manifest is updated with latest version code Note: Looping through all the build variants Dynamic task creation and dependency Importing and using Pattern --------------------------------------- Like these tasks you can think of and create your own gradle tasks
• #41: We have seen android build process and extending the process to suit our needs. Creating standalone and dependent gradle tasks. In this section we will see android specific gradle stuff
• #42: We all know about product flavors, we discussed about in prev meetup too. Here is a little recap. We will all of these in a few slides This is how to define product flavors inside android closure
• #43: Variants and sourceSets created by two product flavors: flavor1 and flavor2. When product flavors are added android automatically generates gradle tasks related to flavors. e.g. the above flavors will generate tasks like assembleFlavor1Debug, assembleFlavor2 etc. Which finally leads to flavor specific apk generation
• #44: Adding flavor specific dependency is useful when we don’t the whole project to depend on something that is not needed in release versions. Like it doesn’t make sense to ship your app with junit, which is only needed for local testing Every product flavor can override default config values. Here versionCode is overridden by flavor1 and minSdkVersion by flavor2. Let’s see what are the other configurable fields in flavor and default config before moving any further.
• #45: The default configuration is inherited by all product flavors and has same properties as a product flavor. This means whatever that goes inside default config can go in a product flavor These are few of the properties. Discuss a few of these properties. As you can see there are a lot of properties that can go in default config and can be overridden in product flavors. Back to configuring product flavors
• #46: Product flavors can be grouped together via dimension attribute and will result in multi-flavor build variants. Rest is self explanatory. Android creates variants that are all possible combinations of flavors of different dimensions and build types
• #47: Variants can be filtered easily. This filtering will be reflected everywhere. Like in build variants tab of left hand side of studio. Variant specific task creation etc. See it in action
• #48: Build config is an auto generated field and can be found in generated folder
• #49: Adding buildConfigField and resValue to flavors
• #50: Prev slide configuration generates something like this Resulting BuildConfig java class. Now you can use these flavor specific constant anywhere in your main source. (BuildConfig.flist, BuildConfig.shortcode, etc.)
• #51: Now this is for debug purposes and should not be shipped with release version. To make sure that happens we use flavorCompile syntax. This will enable stetho in a particular flavor of application. Show in code. Filter variant to exclude stetho-release variants. One usecase before demo.
• #52: Configuring flavorCompile and product flavor for stetho bridge
• #53: Fitering stetho bridge variants to exclude stetho in release builds. That’s it from stetho lets move back to android studio
• #54: When you want to generate apks for the build variants, you can either select and run each variant. Or you can save the configuration (for all apk generation) or run gradle task. Lets see that from android studio
• #55: Sometime we need to use some properties in manifest that are defined in manifest or are configured based on product flavors like the package name.
• #56: As you can see there are many many configuration options available. Lets look at a few of these. We will not spend much time in these configuration options, it is readily available in the mentioned link
• #57: We all know about the default config block/closure. Here we specify application ID targetSDKVersion etc. Next we have the data binding block. This is a very useful feature in android that got released in IO15. This is used for declarative layouts creation and minimizes the glue code required. If you don’t know about it is highly recommended that you look it up or you can check out the slides uploaded in one of the old meetups titled “Take a bite of android marshmallow”
• #58: Lint is an awesome tool for analysis of error prone areas of our codebase. We can configure it’s properties in this block
• #59: Type of encoding of source files. JAVA version compatibility for source code, Java version compatibility for generated bytecode. If you have various versions or newer versions of java you might wanna check out this option. Configurations for packaging options
• #60: Aapt – android asset and packaging tool. You can select which assets or asset patterns to ignore. Which extension types to ignore while compressing. Error configurations etc. dexOptions is relatively new. It requires latest gradle plugin, build tools and marshmallow. Supports incremental builds. It is experimental and may not work. Whether to pre dex libraries for faster builds. Number of threads for dexing. By default it is 4 (I think)