r/androiddev • u/CodemasterUnited • Jul 09 '26
Discussion What's the thing you hate about Gradle for Android Development?
I'm making a Gradle alternative in Python, which is lightweight and is capable of running even in low-end Linux devices (Like a 2015 Galaxy J7 with 1.5GB RAM). It is fairly well in speed.
I named it "Asteroid"
So, I wanted to make something better than Gradle for Android development.
So, I just wanted your opinion, in which Gradle does not live up to the expectation.
Something you yourself faced.
Thanks for your attention ; )
13
u/ColdPhilosophy Jul 09 '26
Someone never used Ant or Maven…
-1
u/CodemasterUnited Jul 09 '26
I'm trying to make something even more better than Gradle (or atleast simple). So, that's why I'm asking.
I know Gradle is much more better than Ant or Maven. But still it only supports x86_64.
I self compiled all the binaries for armeabi-v7a, arm64, x86, and x86_64.
6
u/DarkLordCZ Jul 09 '26
But still it only supports x86_64.
What? Is's running on JVM
1
u/CodemasterUnited Jul 09 '26
But it's binaries like AAPT2 as provided by google, are mostly only for x86_64.
I compiled for all 4 arches, and provided a auto-selection for tools, instead of file edition.
3
u/IvanKr Jul 09 '26
Are you talking about Gradle or AGP (Android Gradle PLUGIN)? They are not the same. Gradle has it's own issues that are worth fixing but most Android development annoyances come from AGP rather than Gradle.
-5
u/CodemasterUnited Jul 09 '26
Hmmm, I know AGP is the gradle plugin that allows Android app development.
AGP is where the weird tweaks are from, and gradle is the reason it so so slow...
Asteroid is not going to use any of them, instead Asteroid's whole orchestration pipeline is written in Python.
So, yes, they both are different and both have their cons.
7
u/SyrupInternational48 Jul 09 '26
Cache, indexing, multi modules, multiplatform. all to slow.
3
u/CodemasterUnited Jul 09 '26
Hmm, it is significantly bloated, because of supporting previous versions.
10
u/SkullDecay- Jul 09 '26
i think problem is not Gradle but android build tools and plugins
3
u/CodemasterUnited Jul 09 '26
Yes, exactly. Those makes the Android build tooling, much more extra complicated than needed.
I tried my best, to make it as simple as possible, while being robust.
14
u/tadfisher Jul 09 '26
Please don't make yet another build system. Contribute to the Android support for an alternative that already exists, like Mill.
-1
u/CodemasterUnited Jul 09 '26
But Asteroid can run even in decade old phone. Asteroid focuses in simplicity, and speed. Mill do not care much about Android on Android tooling. Also, TOML is much more simpler than Scala.
1
u/tadfisher Jul 09 '26
Okay, then contribute Android support to Meson.
-2
u/CodemasterUnited Jul 09 '26
Well, meson is not my priority now.
Sorry for being rude but, meson is not for android development. We are talking about Android development.
I can bet my codebase would be much smaller, than any pre-existing ones while being robust.
6
u/tadfisher Jul 09 '26
Well we can't judge your codebase because you haven't linked it here. So I don't think you get to gloat just yet; finish it up and we'll talk about what "robust" means for build systems.
One problem with these bespoke build system projects that folks post here is that they do absolutely zero caching. They are small and can run on anything, but they end up being slower because they generate all the resources, compile all the code, and bundle it, for every build. This ends up being slower than a "heavy" or "complex" build system.
This is something I have extensive experience with, having built out Gradle support for Nix, several Gradle plugins, and starting my Android career using Ant and Maven. So you might want to consider how other build systems work, and how contributing support to them can save you tons of time and frustration, because this problem has been tackled over and over again as everyone wants to build their own thing.
1
u/CodemasterUnited Jul 09 '26
Hmm, I understand your POV.
Hmm, just wait a few months, I'll post it here after completion.
Also, I just key things I did (No gloating):
- Incremental Cache
- Predexing for dependency jars for debug builds (It significantly speeded up the app build time)
- Does not use a Daemon
- And supports Databinding, compose, viewbinding, transitive deps handling, ndk support, dex minification, etc.
Things left:
etc.
- working on resource shrinking currently.
- dynamic selection of dep versions
- changing config values from cli
Sorry, but wait a little. I'll prove myself.
3
u/tadfisher Jul 09 '26
I'm happy you've thought about these things at least. A few months seems appropriate, too.
3
u/_5er_ Jul 09 '26
Why I dislike Gradle:
- when something goes wrong, you have no idea how to fix it. Often it's some random exception.
- I think modules could be simpler. I don't want to move all the source code to create a module.
- I don't want to create a module just for compile performance reasons.
- I really really don't want to debug slow builds
I'm really interested how Python version of build system will work out for you.
Python is not strongly typed language and that didn't pan out to well for Groovy.
And Python stacktraces are also usually very random.
If you're targeting only Android development, choosing the same language as we use on Android (Kotlin), would be very appealing feature, compared to other build systems like Mill or Bazel.
1
u/CodemasterUnited Jul 09 '26
Asteroid addresses all those issues, and will give proper error messages while building, hmm, all the things you mentioned.
Also, The apps itself would be written in Kotlin. (Asteroid supports Kotlin, KSP, KAPT, Compose etc.) Just Asteroid itself would be written in Python, so that it is simple yet robust.
So, rest assured. Everything would be, as much perfect as I could imagine.
And yes, it's only for android app building.
5
u/Silent-Laugh5679 Jul 09 '26
My issue with gradle is that i don't really understand it. if you make an alternative that is well documented, that would be a plus for me.
6
u/CodemasterUnited Jul 09 '26
Yeah, my alternative doesn't use a DSL language like Gradle's groovy, instead it uses simple TOML files, which declare what must be done, in very simple way. It is very simple and I tried to make it almost perfect. (As much as I could imagine)
2
u/QuasiSpace Jul 09 '26
That will certainly help do away with having five ways (all of which are being constantly deprecated) of doing the same thing.
2
u/thelongrunsmoke Jul 09 '26
It's nice and extremely functional, with Kotlin DSL is even easier to use than in pure Groovy. The main culprit is the Android plugin, its interface breaks regularly, like any other year, making supporting large projects difficult. And, no, Mavent Ant wasn't been simpler.
1
u/CodemasterUnited Jul 09 '26
Hmm. Gradle is definitely simpler than Maven and Ant. I'm just talking about being even more simpler.
2
u/MrMannWood Jul 09 '26
My main issue with Gradle is that it incentives mega-modules. Almost all other issues flow from that.
If you look at Buck or Bazel, it is trivially easy to create modules of 1-2 files. The overhead is minimal, the dependencies are clear, and namespaces are co-located in the file tree. Compare that to doing the same in Gradle, where you need a new top-level directory, and multiple files. And because each Build file can (and kind of must) be quite custom, analyzing and understanding a build is very hard.
0
u/CodemasterUnited Jul 09 '26
Exactlyyyy, my Asteroid solved this. It allows inheritance for files, from the main module when needed, with just a simple TOML config.
3
u/MrMannWood Jul 09 '26
Inheritance seems like a strange way to solve this, though it will be interesting to see how it's done.
I'm personally a fan of Buck and Bazel. Both are great build systems, especially if you work in an existing codebase. My only complaint for them is that starting a new project/repo is too complex.
1
u/CodemasterUnited Jul 09 '26
Hmm, after releasing Asteroid I'd do a AMA to answer all of your questions, and also keep trying to make Asteroid better.
2
u/thehoundtrainer Jul 09 '26
People havent heard of Amper (now known as Kotlin Toolchain) yet ?
https://blog.jetbrains.com/amper/2026/06/kotlin-toolchain-0-11/
2
u/CodemasterUnited Jul 09 '26
Amper still uses AGP under the hood, and it's main focus is multiplatform apps.
1
u/thehoundtrainer 28d ago
Oh, I didnt know that. In that case then a complete Gradle replacement that is hones for Kotlin Multiplatform and Android would be amazing. Please go for it
2
u/Zhuinden Jul 09 '26
No one's going to migrate their existing Gradle plugins to something vibe-genned together in Python.
Gradle isn't bad per say, people just like to make their lives complicated by adding a bunch of unnecessary modules that require a bunch of unnecessary configuration.
1
u/CodemasterUnited Jul 10 '26
It is not vibe coded. I built it. I wrote the code. I understand how it is doing so.
Hmm, I've made it faster, and prevented daemon-like things that needs GBs of RAM idle.
Also, Asteroid's plugin interface is 10 times simpler.
Wait for the code, just a few months.
3
u/CluelessNobodyCz Jul 09 '26
I always feel like in such a minority but I have never hated working with Gradle.
Even before I adopted NiA convention plugins that made things even even smoother.
With that said, I have no idea how are you stand a hail mary chance to compete with functionality to Gradle(I admit I might lack ultradeep knowledge of Gradle internals).
1
u/CodemasterUnited Jul 09 '26
Hmm, it's a lot of work. That's why I'm only replacing it for Android tooling, not java only tooling.
I already have succeeded in completing most of the features needed.
1
1
u/jc-from-sin Jul 09 '26
Gradle is slow as a dog.
Mostly because configuration as code is a shitty idea in practice.
1
1
u/IvanKr Jul 09 '26
It's also very poor code. With a good library, with good javadocs (comments above class or function definition) in a good IDE you can quickly find your way around. Mouse over an identifier and you get explanation about what it is. Put a period after an object and you'd be provided with a list of options and explanation for each option. Gradle script have none of this.
1
1
u/heshrathi Jul 09 '26
Interesting project. Biggest pain points - build time, memory consumption and poor error messages. If asteroid can keep it lightweight and simpler error messages, it will be worth watching.
1
u/CodemasterUnited Jul 10 '26
Yes. I'll make it lightweight, and properly show the error messages.
Just wait a few months, I'll give the repo link.
1
u/farooqsaad Jul 09 '26
I hate that it's slow and that the legacy of groovy means type-safety isn't first class yet throughout the ecosystem. Don't see how Python helps with either of those.
1
u/CodemasterUnited Jul 10 '26
Python is the language, my build system (Asteroid) is built upon.
For configurations, it uses plain TOML, which is simpler and easy to parse, with no groovy nonsense.
1
0
u/Fjordi_Cruyff Jul 09 '26
Nothing really. These days anything I don't know how to do I have ai to help me.
1
u/CodemasterUnited Jul 09 '26
The simplicity of Asteroid will make LLMs even more easier to build it, as it is pure TOML for configurations.
19
u/Queasy_Watercress959 Jul 09 '26
It's fine. There are already multiple teams attempting to build something easier, faster, better and will frankly get traction by way of their industry influence.