Wrapper, Distribution and Build Environment

It's a SHA-256 checksum of the Gradle distribution ZIP, stored in gradle-wrapper.properties. The wrapper verifies the downloaded distribution against it and aborts if they don't match, protecting against a tampered or corrupted download.

distributionUrl tells the wrapper which Gradle version to download. The '-bin' zip contains only the runtime; '-all' also bundles sources and documentation so IDEs can show Gradle API docs. Both run builds identically.

Four committed files: gradlew (Unix script), gradlew.bat (Windows script), gradle/wrapper/gradle-wrapper.jar (the bootstrapping code), and gradle/wrapper/gradle-wrapper.properties (which Gradle version/distribution to use).

Run ./gradlew wrapper --gradle-version 9.0. The built-in wrapper task rewrites gradle-wrapper.properties (and scripts/jar) to point at the requested version, so everyone uses it on the next build.

Run the wrapper task with --gradle-distribution-sha256-sum and the official checksum, e.g. ./gradlew wrapper --gradle-version 8.7 --gradle-distribution-sha256-sum <sum>. Gradle writes distributionSha256Sum into gradle-wrapper.properties for you.

Gradle itself runs on one JDK (the one launching the daemon). Your code can compile/test against a different Java version via toolchains. Each Gradle release only supports running on certain JDKs.

Run ./gradlew wrapper --gradle-version X. This rewrites distributionUrl in gradle-wrapper.properties so the next ./gradlew invocation downloads and uses that version. You never hand-install Gradle.

It means your build used something that will be removed in the next major Gradle (version N), so it would break after upgrading. Re-run with --warning-mode all to see the specific deprecations, then fix them.

--warning-mode controls how Gradle shows warnings (mainly deprecations). Values: all, summary, none, fail. Use all to see every deprecation with details before upgrading to a new major Gradle version.

Look up your Gradle version in the official compatibility matrix to confirm it supports running on the target JDK before installing that JDK on CI. If not, bump Gradle first.

Set a JVM toolchain language version. With the Kotlin plugin use kotlin { jvmToolchain(17) }; AGP picks up that JDK to compile Java and Kotlin instead of the JDK running Gradle.

A toolchain tells Gradle which exact JDK version to use to compile, test, and run your code. Declaring one decouples that from the JDK that started Gradle, so the build uses the JDK you specify, not whatever happens to be on PATH.

Gradle scans well-known locations for installed JDKs so a declared toolchain can be matched to a local JDK without you configuring paths. It checks SDKMAN, asdf, Jabba, Homebrew, and standard OS install directories.

Apply the foojay-resolver-convention plugin in settings.gradle.kts. It registers the Foojay repository under toolchainManagement, so Gradle can auto-download a missing toolchain JDK.

If a build needs a JDK that isn't installed locally, Gradle can automatically download it. By default Gradle needs a toolchain resolver plugin (foojay-resolver) registered in settings to know where to fetch JDKs from.

Two main spots: the project root (<project>/gradle.properties), checked into the repo for shared settings, and GRADLE_USER_HOME (~/.gradle/gradle.properties), a per-developer/machine file for local or secret values.

org.gradle.parallel=true lets Gradle run tasks from different projects at the same time using worker threads. Set it in gradle.properties, or pass --parallel on the command line for one build.

-P sets a Gradle project property (read in the build script as a project property). -D sets a JVM system property (read via System.getProperty). They land in different namespaces.

Use providers.gradleProperty("x"), which returns a Provider<String> read lazily at execution time. project.property("x") reads eagerly at configuration time and touches the Project object, which the configuration cache disallows.

Highest to lowest: command line / system-property / env-var overrides beat GRADLE_USER_HOME/gradle.properties, which beats the project-root gradle.properties. So the command line wins, and user-home beats the committed project file.

The daemon is a long-lived background JVM that Gradle reuses across builds to avoid startup cost. Disable it for one build with --no-daemon, or permanently via org.gradle.daemon=false in gradle.properties.

It sets how long (in milliseconds) an idle Gradle daemon stays alive before shutting itself down. The default is 10800000 ms — three hours.

org.gradle.jvmargs is a Gradle property that passes JVM flags (like -Xmx) to the build daemon's JVM. You set it in gradle.properties, usually in the project root or the user's ~/.gradle directory.

The daemon JVM is the JVM that actually runs Gradle itself. Java toolchains pick a (possibly different) JDK to compile and run your project's code. They are configured separately and can be different versions.

On throwaway CI agents the daemon never gets reused, so it brings no speed-up but risks orphaned processes and memory bloat. Disabling it gives a clean, predictable single-use JVM per job.