3

I been developing Android apps for a while now, but came to the realization that I still don't know what the gradle.properties file is used for.

I've read a bit through the Gradle documentation which explains that you can add configurations for specifying the Java home, or memory settings, for example. Is there anything else it can be used for?

My main reference for times like this is usually the Google I/O open-source app, and looking at its gradle.properties file, I can see that one use of it is to store dependency version variables, so the version codes for the Android Support library dependencies, for example, don't each need to be updated with a new release of the library, just that one variable can be updated:

...

// Android support libraries.
compile "com.android.support:appcompat-v7:${android_support_lib_version}"
compile "com.android.support:cardview-v7:${android_support_lib_version}"
compile "com.android.support:design:${android_support_lib_version}"
compile "com.android.support:support-v13:${android_support_lib_version}"
compile "com.android.support:recyclerview-v7:${android_support_lib_version}"
compile "com.android.support:preference-v7:${android_support_lib_version}"

...

The same idea has been used for Google Play services.

However, in one of my own Android projects, I have been doing something similar - I put my version variable in the root build.gradle file like so:

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

buildscript {
    ext.kotlin_version = '1.0.5-2'

    repositories {
        ...
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:2.2.3'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }

    ...

Then I've been using it in my module build.gradle like so:

dependencies {

    ...

    // Kotlin standard library
    compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"

    ...
}

So I guess I have a couple questions:

  1. What else is the gradle.properties file used for?

  2. What is the difference between using an external variable for dependency versions in gradle.properties (as in iosched), vs an external variable in the root build.gradle (as I have been doing)?

    • Which is the preferred method, if there is one?
    • Are there advantages/disadvantages to doing it one particular way?
Farbod Salamat-Zadeh
  • 19,687
  • 20
  • 75
  • 125
  • 1
    "Is there anything else it can be used for?" -- anything you want. I use them for local settings, like paths to local Maven repositories, URLs for test servers, etc., then I don't commit `gradle.properties` to version control. – CommonsWare Dec 07 '16 at 20:40
  • Thanks for your comment, @CommonsWare . Could you perhaps show me an example? Also, would you be able to tell me the preferred way of setting up the external variables (or if there isn't one, in your opinion)? Thanks again. – Farbod Salamat-Zadeh Dec 07 '16 at 20:43
  • 2
    Matias' example is pretty much what I do. I can't say what the "preferred way" is across the board. For some things, environment variables are interesting, just because Android Studio *doesn't* support them, and so you could use those for things that should not be built from the IDE (e.g., release builds). Personally, I tend to use `gradle.properties`, because it's a simple way to keep local configuration separate from stuff that is appropriate for everyone. – CommonsWare Dec 07 '16 at 21:12
  • 1
    I am using it for API keys which are then copied into build config – Peter Chaula Dec 07 '16 at 21:18
  • @CommonsWare Interesting that the environment variables _aren't_ supported by Android Studio, so thanks for pointing that out. I also find your point about keeping local configuration hidden quite useful. I think I'll choose to use `gradle.properties` for local configuration, as you, Matias, and Laser have shown, and use the root `build.gradle` for dependency variables. Thanks again. – Farbod Salamat-Zadeh Dec 07 '16 at 21:44

1 Answers1

6

I'm using it for (inside app/build.gradle):

signingConfigs {
    release {
        keyAlias RELEASE_KEY_ALIAS
        keyPassword RELEASE_KEY_PASSWORD
        storeFile file(RELEASE_STORE_FILE)
        storePassword RELEASE_STORE_PASSWORD
    }
}

productFlavors {
    ....
    prod {
        applicationIdSuffix ".prod"
        buildConfigField "String", "BASE_URL", BASE_URL_PROD
    }
    ....
}

buildTypes.each {
    it.buildConfigField "Double", "CONTACT_MAP_LATITUDE", CONTACT_MAP_LATITUDE
    it.buildConfigField "Double", "CONTACT_MAP_LONGITUDE", CONTACT_MAP_LONGITUDE
    it.resValue "string", "google_maps_api_key", GOOGLE_MAPS_API_KEY
}

RELEASE_KEY_ALIAS, RELEASE_KEY_PASSWORD, RELEASE_STORE_FILE, RELEASE_STORE_PASSWORD, BASE_URL_PROD, CONTACT_MAP_LATITUDE, CONTACT_MAP_LONGITUDE and GOOGLE_MAPS_API_KEY all are inside gradle.properties, and that file is not pushed to git

Example:

gradle.properties: BASE_URL_PROD = "http://something.com/api/"

build.gradle: buildConfigField "String", "BASE_URL", BASE_URL_PROD

java file: BuildConfig.BASE_URL

EDIT: also, here you can find examples for a server application (Spring): https://melorriaga.wordpress.com/2016/08/06/gradle-dont-store-api-keys-and-db-information-in-versioned-files/

Matias Elorriaga
  • 8,880
  • 5
  • 40
  • 58
  • Thanks for clarifying its usage Matias. I think I'll use `gradle.properties` for local configuration as you have done (along with others in the comments), and keep using `build.gradle` for dependency versions. – Farbod Salamat-Zadeh Dec 07 '16 at 21:44