Notes on gradle - build system for Android development

Last updated on 18 Dec 2025
Me: I am on a 4G mobile Internet connection. Now it is peak time (IFIRC, it was around 8.30 PM to 9.30 PM) and so speed is usually btw 500 Kbps and 2 Mbps.
I faced two downloading issues with Gradle:

One download issue was Read timeout. That I think is related to Gradle network timeouts. How do I increase that?

CG suggestion with some modification from me:
In <project-root>/android/gradle.properties
I added these lines to end of gradle.properties for project:
org.gradle.internal.http.connectionTimeout=1800000
org.gradle.internal.http.socketTimeout=1800000

(1,800,000 ms = 30 minutes)
...

Initially, based on CG suggestion I had also added to same file above:
org.gradle.parallel=false
org.gradle.workers.max=2
----------
As per CG and as per my understanding of it, IFIRC, this would help in downloads being done serially and so perhaps reducing competition for Internet connection bandwidth between parallel downloads. The downside of this was that this setting applied not only to downloads but also to build execution.  So I removed the above two lines. Search for "org.gradle.parallel=false" in contents below to see that part of exchange with CG.

I also recall that CG said something about invoking gradlew to only download dependencies and not do any build. That gives the possibility of temporarily adding above two lines to gradle.properties, only downloading gradle dependencies, then removing those two lines, and now invoking regular gradle build command. If I run into a major issue with downloading a large individual package (covered below) where the CDN serving it is breaking the connection often, then I could consider it.

...
Me: The second download issue I noticed was that a particular package (jar) download, of say 55 MB, would stop before completion and then restart automatically. I saw the network speed tool that I have show 0 Kbps download just before the package jar download got restarted. My guess is that this is a timeout on the server (CDN perhaps) that is having the jar. It may be providing the connection for download for only a set number of minutes.

CG: Your diagnosis is largely correct, and—importantly—this behavior is not under your control in the way Gradle timeouts are.
...

For large artifacts (JAR/AAR, often 40–100 MB):

  1. Gradle opens an HTTP connection to a Maven repository CDN

    • Commonly: Maven Central, Google Maven, JCenter mirrors, or vendor-hosted CDNs.

  2. On slow or highly variable connections, the CDN:

    • Detects prolonged low throughput, or

    • Enforces a maximum idle / transfer window per connection.

  3. The CDN terminates the connection silently.

  4. Gradle sees:

    • socket stall (0 Kbps)

    • then a disconnect

  5. Gradle retries from scratch (no resume support for most Maven artifacts).

This is server-side behavior, not Gradle misconfiguration.

Your observation of “0 Kbps just before restart” is a textbook symptom.

...

Me: Often succeeds after 1–3 retries That's what I have experienced.

...

Me: ./gradlew clean
Downloading https://services.gradle.org/distributions/gradle-8.1.1-all.zip
................10%................20%................30%................40%................50%................60%................70%.
Exception in thread "main" java.io.IOException: Downloading from https://services.gradle.org/distributions/gradle-8.1.1-all.zip failed: timeout (10000ms)
-----------------------
I think solution may be to increase, in android\gradle\wrapper\gradle-wrapper.properties 
networkTimeout=10000
...

Me: [CG had suggested the following two lines earlier] About these lines:
org.gradle.parallel=false
org.gradle.workers.max=2
--------------------
Does it impact only downloading or also execution of build?
U see, I have an i3 12 gen PC with 16 GB RAM. So I want its full power to be used for build execution.

CG: Those two lines impact build execution, not just downloading. Let me clarify:

  1. org.gradle.parallel=false

    • Controls whether Gradle builds subprojects in parallel.

    • Setting false → subprojects are built sequentially.

    • Setting true → Gradle tries to build independent subprojects in parallel, which can speed up builds on multi-core CPUs.

  2. org.gradle.workers.max=2

    • Limits the number of concurrent worker threads Gradle can use for tasks (compilation, dexing, bundling, etc.).

    • Setting it to 2 restricts Gradle to 2 threads even if your CPU has more cores.

For your i3 12th gen with 16 GB RAM:

  • You can safely increase parallelism to use more cores and speed up the build. For example:

org.gradle.parallel=true
org.gradle.workers.max=4

  • Gradle will then:

    • Run independent subprojects in parallel.

    • Use up to 4 worker threads for tasks.

  • Memory (org.gradle.jvmargs=-Xmx2048m) is reasonable for your machine.

Tip: You can experiment — increase workers.max to 6 or 8 and see if the build is faster without exhausting RAM.

Would you like me to suggest optimized settings for your machine for fast AAB builds?

Me: I will then just delete those two lines and rely on default settings.

Comments

Post a Comment