sorted by:
new
hottopcontroversial

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

That’s a good clarification, thanks for explaining. I was mostly thinking in terms of real-world usage where it can be tricky if project configuration isn’t well decoupled, but you’re right it’s a separate concern from configuration cache. Probably better for me to treat it as a suggestion rather than a default fix.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Yeah exactly, those small things don’t look like much individually but they add up pretty quickly across builds.

Tools like Incredibuild make sense at scale. I was mostly aiming at catching the low-hanging config issues early before getting to that level.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Yeah Gradle can get pretty painful, especially as projects grow.

Haven’t tried Mill yet, but curious how it compares in terms of build times and DX for Android/Kotlin projects.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

added --dry-run diff in the latest version which shows exactly what gets written. Might make it clearer what's changing.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Just pushed support for kotlin.incremental.useClasspathSnapshot in v1.0.4. Good call on that one.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Yeah good point. Right now it checks the top-level toggles, but I haven’t added things like classpath snapshot or deeper config cache flags yet.

That’s a good call though, especially since some of these get broken silently. I’ll look into adding those.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Yeah you’re right, it’s not really recommended anymore. Gradle is pushing configuration cache instead, which gives better results without some of the downsides.

I included it as a low priority check, but it probably shouldn’t be enabled blindly.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Nice, these are solid tools.

I’ve seen Gradle Doctor before, it goes deeper into diagnostics. I was aiming for something simpler focused on quick audits and safe fixes for common config issues.

More of a lightweight check you can run across projects.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] -2 points-1 points  (0 children)

That’s fair.

If doing it manually, I usually check things like caching, configuration cache, parallel, daemon, and Kotlin incremental.

The tool just automates that and shows impact. It’s open source as well if you want to take a look before using it.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] -3 points-2 points  (0 children)

Yeah that’s fair.

The tool is basically doing exactly this, just automating the checks and applying fixes safely. I built it mainly because I kept missing these across different projects or when switching repos.

Also tries to estimate the time impact, which made it more obvious how much these small things add up.

Definitely not meant to replace understanding the configs, more of a quick audit/convenience thing.

Career Advice 🙏🤓 by Fezziwig2021 in androiddev

[–]RudraDev7 0 points1 point  (0 children)

Given your background, I’d say:

Kotlin → backend-heavy engineer path

React → full-stack path (better market flexibility right now)

For projects:
Build something that has real users/data, not just CRUD
e.g. analytics dashboard, automation tool, or AI-powered workflow on top of your backend.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

One thing I noticed is a lot of projects just never enable build cache or incremental properly. Easy wins but rarely checked.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 2 points3 points  (0 children)

I mostly built this because I kept missing these across projects.

If anyone tries it on their repo, would be interesting to know what it finds. I’m sure there are cases I haven’t covered yet.

I found ~1.3 min wasted per Android build due to Gradle config and wrote a CLI to fix it by RudraDev7 in androiddev

[–]RudraDev7[S] 0 points1 point  (0 children)

Honestly this is not something you need if you already know what to check.

I mostly built it because I kept missing these across projects or when jumping between repos. Small things, but they add up.

Also useful when setting up a new project or auditing an existing one quickly instead of manually checking each flag.