gradle.properties

# To speed up the compilation itself, you can tweak parameters on the Java Virtual Machine (JVM).
# There is a Gradle property called jvmargs that enables you to set different values for the memory
# allocation pool for the JVM. The two parameters that have a direct influence on your build speed
# are Xms and Xmx. The Xms parameter is used to set the initial amount of memory to be used, while
# the Xmx parameter is used to set a maximum.
# - Side effects
# The above line means, you are allowing Java compilers to have available memory up to 2 GB
# (2048 MB). If you do not have available memory to give out 2 GB to Java then you should not add
# this line.
org.gradle.jvmargs=-Xmx4G -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -Xms1G -XX:ReservedCodeCacheSize=225m -XX:+OptimizeStringConcat -XX:+UseCompressedOops -d64

# The Gradle daemon is a process that runs in the background on your machine. When you run a Gradle
# task using the daemon, the already-running process handles it. This eliminates Gradle startup
# costs that are otherwise incurred every time you run Gradle. The only downside to using the daemon
# is that the process takes up some memory: on my machine a couple hundred MB. After 3 hours of
# idle time the daemon will stop itself; you can stop it earlier by running gradle --stop on the
# command line (this is useful when sometimes your gradle builds give an error Unable to locate a
# Java Runtime to invoke).
# - Side effects
# 1 - Gradle daemon is a background process. If you use this, it might take (300-400) MB memory or
# more from your system.
# 2 - After adding the above line, try to Rebuild the project. If you get error, something like,
# Unable to locate a Java Runtime to invoke, very obvious solution, remove the line.
org.gradle.daemon=true

# If your Gradle build contains multiple decoupled projects, you can take advantage of Gradle’s
# parallel mode. In parallel mode, Gradle will run multiple executor threads, which can execute
# tasks from different projects in parallel. By default Gradle will create one executor thread for
# each CPU core on your machine, but this is configurable.
org.gradle.parallel=true

# In its default mode, Gradle configures every project before executing tasks, regardless of whether
# the project is actually needed for the particular build. “Configuration on demand” mode changes
# this behaviour, only configuring required projects. Like parallel mode, configuration on demand
# mode will have the greatest effect on multi-project builds with decoupled projects. Note that
# configuration on demand mode is currently an incubating feature, so isn’t fully supported. You can
# learn more about it in the Multi-project Builds section of the Gradle user guide.
org.gradle.configureondemand=true

# Gradle will happily run multiple test cases in parallel, which is useful when you have several CPU
# cores and don’t want to waste most of them.
# The normal approach is to use some number less than or equal to the number of CPU cores you have.
# Recommended: test.maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
test.maxParallelForks=4

# Gradle will run all tests in a single forked VM by default. This can be problematic if there are a lot
# of tests or some very memory-hungry ones. One option is to run the tests with a big heap, but you will
# still be limited by system memory and might encounter heavy garbage collection that slows the tests down.
# Another option is to fork a new test VM after a certain number of tests have run.
test.forkEvery=100

# The standard compiler does attempt to work out what files need recompiling based on a set of changes,
# but this is rather unreliable. The Java developers amongst you have probably encountered a few instances
# where you had to run a clean first to fix some compilation issues. So Gradle avoids the potential problems
# from this by not using the compiler to determine what needs to be recompiled.
compileJava.options.incremental=true

# Android Studio 2.2 Beta 3 introduces a new build cache feature that can speed up build times
# (including full builds, incremental builds, and instant run) by storing and reusing files/directories that
# were created in previous builds of the same or different Android project.
# The build cache is meant to be used across all Android projects. The developer can enable/disable the
# build cache and specify its location in the gradle.properties file. Currently, the build cache contains
# only pre-dexed libraries; in the future, we will use it for caching other types of files as well.
android.enableBuildCache=true