let me tell you how you should build your gradle structure

As you know, Gradle is a build system that manages all dependencies and allows you to define custom build logic. You can use it to build, test, run and package your apps. Android Studio uses a Gradle wrapper to fully integrate the Android plugin for Gradle.

organize your dependencies in a better way…

at the first step, you have two different gradle build files in your app. These are called Project Build File and Module Build File.

Project Build File

the project-level Gradle file uses buildscript to define the Gradle repositories and dependencies.

First, We should define extra properties extension.

ext {


In ext, we are going to define two fields. One of them is about configuration features about the application, the other one about library versions.

ext {

configuration = [

package : "co.mobiwise.moviebox",
compileSdkVersion: 23,
targetSdkVersion : 23,
minSdkVersion : 16,
buildToolsVersion: "23.0.1",

libraries = [
butterknife : "7.0.1",
supportVersion : "23.1.1",
retrofit : "2.0.0-beta3",
retrofitConvertor: "converter-gson:2.0.0-beta1",
rxjava : "1.0.10",
rxandroid : "1.1.0",
rxadapter : "2.0.0-beta1",
okhttpVersion : "2.5.0",
dagger : "2.0",
dagger_compiler : "2.0",
javax_annotation : "10.0-b28",
otto : "1.3.8",

let me explain what I did here. In configuration field; I defined application base package name, compileSdkVersion, targetSdkVersion, minSdkVersion and buildToolsVersion. In libraries field; I defined the versions of libraries that I am going to use in MovieBox application.

Application versioning

the Google Play Store uses application version code in order to detect new versions of the application. There is a common way to give version to your application. That is called Semantic Versioning (the traditional major.minor.patch versioning). You might not use the traditional major.minor.patch versioning for your Android application. Anyway, I am going to share the way I follow:

versionMajor = 0
versionMinor = 0
versionPatch = 0
versionBuild = 1

versionCode = versionMajor * 1000000 + versionMinor * 10000 + versionPatch * 100 + versionBuild
versionName = "${versionMajor}.${versionMinor}.${versionPatch}"

Module Build File

The application module Gradle build file allows you to configure defaultConfig and productFlavors, buildTypes, dependencies.

First you should define configuration and libraries so that you can use these in your module gradle file.

def configuration = rootProject.ext.configuration;
def libraries = rootProject.ext.libraries;


You can manages project dependencies in this field. I am going to show you how you can define your dependencies in your module build file easily.

compile "com.squareup:otto:${libraries.otto}"

This is a simple example how you can define your dependencies.


you can define manifest properties like your base applicationId, minSdkVersion, targetSdkVersion, versionCode, versionName here.

defaultConfig {
applicationId configuration.package
minSdkVersion configuration.minSdkVersion
targetSdkVersion configuration.compileSdkVersion
versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName

buildConfigField STRING, GIT_SHA, "\"${gitSha}\""
buildConfigField STRING, BUILD_TIME, "\"${buildTime}\""
buildConfigField STRING, REST_ENDPOINT, '""'

if you don’t have more than one apk file, you can define generic field that you can use across all the application like Rest Endpoint, database name and version, build time, demo user email and password etc.

buildConfigField STRING, BUILD_TIME, "\"${buildTime}\""
buildConfigField INT, DATABASE_VERSION, '14'
buildConfigField STRING, USER_EMAIL, '""'
buildConfigField STRING, USER_PASS, '""'


we might need to add flavor that builds a different edition of the application. Think a scenario that you need to have two different apk editions. One is going to call your development server and database, and the other one is going to call your production server. In this case you need to define two different flavors that might be called dev and prod.

productFlavors {
dev {
buildConfigField STRING, REST_ENDPOINT, '""'
prod {
buildConfigField STRING, REST_ENDPOINT, '""'

You can define many fields like this example. It really depends on your application needs.

Worth to mention;

I started a a sample project that shows you how to architect an android application and follow Material Design rules. While I develop this sample application, I want to write a blog post about libraries every Android programmer should know(Android and Electrons), Design support library, DI with Dagger2, how to use RxJava and Retrofit together and so on.

You can find sample gradle files in this repo. if you think, the way I created gradle files is not enough or totaly wrong, any contributions are welcomed.

sources :