DEV Community: Aalaa Fahiem

Gradle Said No. Here's How I Learned to Actually Read the Error.

Aalaa Fahiem — Thu, 23 Apr 2026 12:02:04 +0000

There's a specific kind of panic that only Android developers know.

You open your project. You change one line — maybe you bumped a library version, maybe you added a new dependency, maybe you literally changed nothing and just opened it on a different day. And then the banner appears at the top of Android Studio:

"Gradle sync failed."

For a long time, my entire response to that message was to scroll to the bottom of the error, see a wall of red text I didn't understand, and immediately send it to Ai

Sometimes that worked. A lot of times it didn't.

The day things changed was when I stopped scrolling to the bottom and started reading from the top. Gradle errors are actually telling you something. They're not random. Once you know the patterns, they're almost predictable.

Let's go through them — for real this time.

First: What Does "Gradle Sync" Actually Mean?

Every time you change anything in your Gradle files — add a dependency, update a version, change an SDK number — Android Studio shows a banner that says "Sync Now."

That sync is Gradle reading your configuration files and doing all the work that comes with them:

Going out to Maven Central (or Google's repository) and downloading any new libraries you declared
Resolving all the version numbers across all your dependencies
Checking that everything is compatible with everything else
Building the project model that Android Studio uses to give you autocomplete, highlight errors, and know what your project looks like

Think of it like this: your Gradle files are a shopping list. Sync is Gradle actually going to the store to get everything on the list. If something on the list is misspelled, out of stock, or incompatible with something else in your cart — it comes back empty-handed and tells you why.

That "why" is the error. And it's worth reading.

The Three Errors You'll See on Repeat

1. Missing Dependency — "Gradle Can't Find What You Asked For"

Could not resolve com.squareup.retrofit2:retrofit:2.99.0.
> Could not find com.squareup.retrofit2:retrofit:2.99.0.

This one is usually the simplest. Gradle went to find the library and it wasn't there. Nine times out of ten it's one of two things:

Typo in the version number. 2.99.0 doesn't exist. Double-check the actual version on the library's GitHub or on mvnrepository.com.
A repository isn't configured. Some libraries aren't on Maven Central — they need to be fetched from a specific repository. If a library's README says Add to your repositories: ..., that step isn't optional.

The fix is almost always: check the version exists → check the repository is added → sync again.

What you should not do is change the version to something random and hope it works. That's how you end up with a project full of mismatched library versions.

2. Version Conflict — "Two Things Are Asking for the Same Thing in Different Sizes"

Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules
  jetified-kotlin-stdlib-1.8.0 and jetified-kotlin-stdlib-jdk8-1.6.21

This one looks scary. It's not.

What happened: two of your dependencies each pulled in a different version of the same underlying library. Gradle downloaded both, and now there are two copies of the same class sitting in your build — which it can't allow.

When you do hit a version conflict, here's the mental model:

Library A  →  depends on  →  OtherLib 1.5.0
Library B  →  depends on  →  OtherLib 1.8.0
                                    ↑
                           Which one does Gradle use?

Gradle tries to resolve this by picking the higher version. But sometimes that fails, or two versions are fundamentally incompatible. The fix is usually to force a specific version in your build.gradle

3. JVM Incompatibility — "Your Java Version and Kotlin Aren't Speaking the Same Language"

'compileDebugJavaWithJavac' task (current target is 11) and 
'compileDebugKotlin' task (current target is 17) jvm target compatibility 
should be set to the same JVM version.

I remember seeing this for the first time. I had no idea what a "JVM target" was. I just knew the build was broken.

Here's what's happening: Kotlin and Java both compile down to JVM bytecode. For them to work together, they both need to be targeting the same JVM version. When they're misaligned — Kotlin targeting 17, Java targeting 11 — the build breaks.

The fix is a few lines in your build.gradle:

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }
    kotlinOptions {
        jvmTarget = "11"
    }
}

The One Habit That Changed Everything for Me

Here's something I spent way too long not doing: reading the error from top to bottom, not bottom to top.

Gradle errors are nested. The outermost message describes what failed. The inner messages describe why. The actual cause is usually two or three levels in — but it's there.

A real error might look like this in the Build panel:

> Task :app:processDebugMainManifest FAILED
  > Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'.
     > Could not resolve androidx.core:core-ktx:1.17.0.
        > Dependency 'androidx.core:core:1.17.0' requires compileSdk 36 or later.
           Compilation target on project ':app' is compileSdk 35

Read that from the bottom up and the real problem jumps out: your compileSdk is 35, but the library needs 36. Everything above it is just the chain of failures that caused. Fix the root cause — bump compileSdk to 36 — and the whole tower of errors collapses.

Most Gradle errors work this way. The actual fix is almost always simpler than the wall of text suggests.

When Sync Fails and Nothing Makes Sense

Sometimes you've read the error, tried a fix, and it still won't sync. Before you go any further, try these two things in order:

Step 1 — Invalidate Caches

File → Invalidate Caches → Invalidate and Restart

Android Studio caches a lot of things. Sometimes the cache gets stale or corrupted and starts causing phantom errors — problems that look like config issues but are actually just bad cached state. Invalidating the cache and restarting fixes more things than it should.

Step 2 — Clean the Project

Build → Clean Project, then Build → Rebuild Project

Old build artifacts can cause conflicts with new ones. Cleaning removes everything and forces a fresh build from scratch. If you changed something and now nothing makes sense, this is step two.

These two things together have saved me hours of debugging what turned out to be non-problems.

A Quick Sync Survival Checklist

When sync fails, go through this before anything else:

1. Read the error top to bottom — find the deepest message, that's the real cause
2. Is it a missing dependency? → Check the version number and the repository
3. Is it a version conflict?  → Update your dependencies, check for forced versions
4. Is it a JVM mismatch?      → Align compileOptions and kotlinOptions
5. Still broken?              → Invalidate Caches → Restart
6. STILL broken?              → Clean Project → Rebuild
7. Nothing works?             → ./gradlew dependencies in the terminal for the full picture

The Honest Truth

Gradle errors felt like a foreign language to me for a long time. Not because they're actually complicated, but because I never stopped to read them. I just saw red text and immediately started Googling.

The moment I slowed down — actually read the full error, found the root cause, understood what it was telling me — the errors started feeling solvable instead of scary.

They still show up. They always will. But now when Gradle says no, I know how to ask it why.

Your App Has Three SDK Numbers and a Secret Evil Twin as your app has two version!

Aalaa Fahiem — Mon, 20 Apr 2026 08:32:42 +0000

When I created my first Android project, Android Studio auto-filled three numbers I'd never seen before:

compileSdk = 35
minSdk = 24
targetSdk = 35

I left them exactly as they were. Didn't touch them. Didn't read them. Moved straight to writing code.

That worked fine — until the day I added a new AndroidX library and got hit with an error I still remember clearly:

Dependency 'androidx.core:core:1.17.0' requires compileSdk 36 or later.

I hadn't written a single bad line of code. The project was clean. And yet it refused to build.

That was the moment I realized I had absolutely no idea what those three numbers meant, or why they existed. If you're in the same boat — this is for you.

Three Numbers, One Job Each

Let me break these down in the order that actually makes sense — not alphabetical, not the order they appear in the file, but the order that makes them click.

`minSdk` — The Minimum Bar to Install Your App

This is the oldest version of Android that can run your app.

minSdk = 24  // Android 7.0 (Nougat)

If a phone is running Android 6.0 (API 23) and your minSdk is 24, that phone simply won't be able to install your app. The Play Store will hide your app from them entirely. They'll never even see it.

The lower you set minSdk, the more devices you support. But here's the catch — the lower you go, the more old Android behaviors you have to handle in your code. Features that exist on API 30 might not exist on API 21. You'd have to write fallback code for every one of them.

In 2026, minSdk = 24 is the sweet spot for most new apps. It covers roughly 98% of active Android devices and lets you use pretty much every modern API without worrying about ancient phones.

The one-liner: minSdk decides who can install your app.

`compileSdk` — What APIs You Can Actually Use

This is the Android SDK version Gradle uses to compile your code. It's not about which phones can run your app. It's about which Android APIs are available to you while you're writing code.

compileSdk = 36  // Android 16

If you set compileSdk = 34 but try to call an API that was introduced in API 35, you'll get a compile error. Your IDE won't even recognize the method. Because as far as your build system is concerned, that API doesn't exist yet — you're compiling against an older SDK.

This is also what that error I got was about. The core:1.17.0 library internally uses APIs that only exist in SDK 36+. It said: "if you want to use me, you need to be compiling against at least SDK 36." Fair enough.

The rule of thumb: keep compileSdk at the latest stable Android version. There's no downside. It doesn't affect which devices run your app — it just unlocks newer APIs for you to call.

The one-liner: compileSdk decides what you can write in your code.

`targetSdk` — The Version You're "Promising" to Support

This one is the trickiest, but here's the mental model that helped me:

targetSdk is your app saying to the Android OS: "I know about this version of Android. I've tested against it. Please apply its rules to me."

targetSdk = 35  // Android 15

Android introduces new behavior changes with every version — things like stricter background restrictions, new permission flows, different notification handling. But to avoid breaking millions of existing apps overnight, Android only applies those new behaviors to apps that explicitly declare they're ready for them, via targetSdk.

If you set targetSdk = 33, Android will still run your app on a brand-new Pixel — but it'll treat it like an Android 13 app, applying Android 13 rules. That's a safety net, not a feature.

The one-liner: targetSdk decides which Android rules apply to your app at runtime.

The Three-Line Summary You'll Actually Remember

android {
    compileSdk = 36   // What APIs can I write in my code?
    minSdk = 24       // Which phones can install my app?
    targetSdk = 35    // Which Android behavior rules apply to me?
}

minSdk ≤ targetSdk ≤ compileSdk — that's always the order. They don't go the other way.

Now Let's Talk About Your App's Secret Evil Twin

Here's something that surprised me when I first found it.

Your app doesn't have one version. It has two. At all times. Living in your project simultaneously.

One is the app you run during development. One is the app you ship to users. And they are not the same thing.

This is what buildTypes is about.

buildTypes {
    debug {
        // This is the version running on YOUR phone right now
    }
    release {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

Debug: Your Development Companion

Every time you hit the Run button, Android Studio builds the debug version of your app.

The debug build is built for you, not for users. It's:

Debuggable — you can attach the debugger, set breakpoints, inspect variables while the app runs
Not optimized — builds fast so you're not waiting forever between changes
Signed with a debug key automatically — you don't need to set up signing to install it on your own device
Bigger — no code shrinking, no obfuscation, all the extra debug info is kept in

You'll never publish a debug APK. You shouldn't even want to — it has debug flags enabled that you don't want visible in production, and it's larger than it needs to be.

Release: What Your Users Get

The release build is what you ship to the Play Store. It's built for users, not for you.

release {
    isMinifyEnabled = true      // shrinks and obfuscates your code with R8
    isShrinkResources = true    // removes unused resources from the APK
    proguardFiles(
        getDefaultProguardFile("proguard-android-optimize.txt"),
        "proguard-rules.pro"
    )
}

The release build is:

Optimized — R8 runs and shrinks your code down significantly
Obfuscated — class and method names get renamed to short gibberish, making it harder to reverse-engineer
Smaller — unused code and resources get stripped out
Not debuggable — you can't attach the Android debugger to it (which is intentional)
Signed with your real keystore — required to publish to the Play Store

Here's a thing that trips up a lot of beginners: your app can behave differently in release vs debug.

The lesson: always test a release build before you ship it. Don't assume that because it worked in debug, it'll work in release too.

The Cheat Sheet

Config	Question it answers	Value to use in 2026
`compileSdk`	What APIs can I use in code?	`36`
`targetSdk`	Which Android rules apply?	`35`
`minSdk`	Who can install my app?	`24` (covers ~98% of devices)
`debug` build	Who's it for?	You, during development
`release` build	Who's it for?	Your users

Dependency: That One Line in build.gradle You Copy Without Thinking? Let's Actually Understand It.

Aalaa Fahiem — Wed, 15 Apr 2026 22:29:01 +0000

You know the drill.

You want to add Retrofit to your project. You Google "add Retrofit Android.", take it from official documentation You find the line. You paste it into your build.gradle. You sync. It works. You move on.

And then one day it doesn't work. Maybe the version is wrong. Maybe there's a red error about a duplicate class. Maybe Gradle is screaming about something conflicting. And you're standing there with no idea what that line you've been pasting for months actually does.

That was me. For longer than I'd like to admit.

So let's fix that. Let's talk about dependencies — what they really are, how to read them, and what the difference between implementation and api is (because it actually matters and nobody explains it properly).

First, What Even Is a Dependency?

A dependency is just a library someone else wrote that you want to use in your app.

Instead of you writing your own networking code from scratch, you pull in Retrofit. Instead of writing your own image loading logic, you pull in Coil. A dependency is just code you didn't write but want to include in your project.

The dependencies { } block in your build.gradle is where you tell Gradle: "hey, go find this library and make it available in my code."

dependencies {
    implementation("androidx.core:core-ktx:1.16.0")
    implementation("com.squareup.retrofit2:retrofit:2.11.0")
}

Those two lines are Gradle saying: "before you build this app, go download these two libraries and include them." You don't touch a .jar file. You don't manage folders. You just declare what you need and Gradle handles the rest.

How to Actually Read a Dependency Line

Every dependency line follows the same pattern:

implementation("group:artifact:version")

Let's break down a real one:

implementation("com.squareup.retrofit2:retrofit:2.11.0")
//              └─ group ────────────┘  └─ name ┘  └─ version ┘

Group → usually the company or project name (com.squareup.retrofit2)
Artifact → the specific library within that group (retrofit)
Version → which version you want (2.11.0)

That's it. Three parts, colon-separated. Once you see that pattern, every dependency line becomes readable — not just a magic string you paste and hope for the best.

`implementation` vs `api` — The One That Actually Matters

This is the part that confused me . Why are there different keywords? What's the difference?

Here's the honest, simple version:

`implementation` — Keep it private

implementation("com.squareup.retrofit2:retrofit:2.11.0")

This is the one you'll use 99% of the time. It means: "add this library to my module, but don't expose it to anyone who depends on my module."

In plain terms — Retrofit is yours to use inside your app module. Other modules in your project can't accidentally reach into it.

`api` — Share it outward

api("com.squareup.retrofit2:retrofit:2.11.0")

This says: "add this library AND expose it to anyone who depends on my module." If module A uses api to include Retrofit, and module B depends on module A, then module B can also use Retrofit directly — without declaring it themselves.

Why does this matter for beginners? It mostly doesn't — yet. If you have a single-module app (which most beginners do), there's no difference in practice. But the rule of thumb is:

Default to implementation. Only use api when you intentionally want to expose a library to other modules.

Using api everywhere is a common beginner mistake that makes builds slower and creates unexpected compile-time dependencies. Just use implementation unless you have a specific reason not to.

The Compose BOM — Because Managing 10 Versions Is Painful

If you're using Jetpack Compose, you've probably seen something like this in your build.gradle:

dependencies {
    // Specify the Compose BOM with a version definition
    val composeBom = platform("androidx.compose:compose-bom:2026.03.00")
    implementation(composeBom)
    testImplementation(composeBom)
    androidTestImplementation(composeBom)

    // Specify Compose library dependencies without a version definition
    implementation("androidx.compose.foundation:foundation")
    // ..
    testImplementation("androidx.compose.ui:ui-test-junit4")
    // ..
    androidTestImplementation("androidx.compose.ui:ui-test")
}

Notice something? Those last four lines have no version number. That feels wrong — but it's intentional.

The platform(...) line imports the BOM (Bill of Materials). Think of the BOM as a version cheat sheet that Google maintains. It says: "if you're using Compose BOM version 2026.03.00, here's exactly which version of every Compose library you should use."

By importing the BOM first, you're telling Gradle: "figure out the right version for each Compose library automatically." You don't manage 10 different Compose library versions anymore. You manage one BOM version.

When a new Compose release drops, you update one number. Everything else stays consistent.

As of writing this article, the latest stable BOM is 2026.04.00 and the latest Kotlin is 2.3.20. Keep these updated — the Android ecosystem moves fast.

Reading Dependency Errors

This is the part nobody teaches but everyone needs.

Here are the three errors you'll see constantly, and what they actually mean:

Could not resolve com.squareup.retrofit2:retrofit:2.99.0

Gradle can't find that version. Either you typed the version wrong, or it doesn't exist. Fix: check the library's GitHub or Maven Central for the correct version number.

Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules

Two of your dependencies are pulling in the same thing — usually different versions. Fix: this usually means one of your library versions is too old. Update your dependencies and it typically resolves itself.

Unresolved reference: Retrofit

You haven't added the dependency, or you added it but Gradle hasn't synced yet. Fix: check your dependencies block, then hit "Sync Now" in the yellow bar at the top.

The golden rule: read the error before Googling it. Gradle errors are verbose but usually descriptive once you slow down and actually read the message.

A Clean Real-World `dependencies` Block

Here's what a modern Android project's dependency block looks like, with everything in its right place:

dependencies {
    // Kotlin & Core
    implementation("androidx.core:core-ktx:1.16.0")
    implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.9.0")

    // Jetpack Compose (using BOM — no versions needed below)
    val composeBom = platform("androidx.compose:compose-bom:2026.03.00")
    implementation(composeBom)
    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.ui:ui-graphics")
    implementation("androidx.compose.material3:material3")
    implementation("androidx.activity:activity-compose:1.10.1")
    debugImplementation("androidx.compose.ui:ui-tooling")
    debugImplementation("androidx.compose.ui:ui-test-manifest")

    // Networking
    implementation("com.squareup.retrofit2:retrofit:2.11.0")
    implementation("com.squareup.retrofit2:converter-gson:2.11.0")

    // Image loading
    implementation("io.coil-kt:coil-compose:2.7.0")

    // Testing
    testImplementation("junit:junit:4.13.2")
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
}

Organized. Readable. Every line has a purpose. And now you can actually read what it's doing instead of just hoping it works.

One Last Thing

Dependencies aren't magic. They're just other people's code that Gradle downloads and includes in your build. The implementation keyword is how you invite that code in. The version number is which version of it you want. The BOM is a shortcut for managing multiple related versions at once.

That's the whole mental model.

Next time you paste a dependency line, take two extra seconds to read it. What's the group? What's the artifact? What version? Once you start seeing the pattern, it stops feeling like config soup and starts feeling like actual configuration you understand and control.

And that's a really good feeling.

Gradle for Android Beginners: The Mental Model That Changes Everything

Aalaa Fahiem — Wed, 15 Apr 2026 15:27:10 +0000

The first time I saw a Gradle error, I did what any reasonable beginner does.

I stared at it for a few minutes. paste the exact error message for claude, then Copy-pasted the fix. It worked. I had no idea why. I closed the file and never looked at it again.

That was my relationship with Gradle for a long time — pure avoidance. As long as the build succeeded, I pretended those files didn't exist. build.gradle? Not my problem. settings.gradle? Never opened it on purpose.

Then one day I accidentally changed a single line in the wrong Gradle file. The project stopped compiling entirely. I couldn't figure out what I broke or how to fix it. I spent two hours on something that should've taken two minutes — and the only reason it took that long is that I had zero mental model of what Gradle actually was.

That's what this article is about. Not Gradle syntax. Not memorizing configs. Just — what is this thing, why does it exist, and how do I stop being scared of it.

So... What Even Is Gradle?

Here's the simplest way I can put it:

Gradle is the engine that turns your code into an app.

You write Kotlin. Android can't just run Kotlin files directly. Something needs to take all those files, pull in the libraries you're using, stitch everything together, and produce a .apk or .aab file that a phone can actually install. That something is Gradle.

Every time you hit the Run button in Android Studio, Gradle is doing a lot of work behind the scenes:

Compiling your Kotlin code into bytecode
Pulling in your dependencies (Retrofit, Compose, Room — whatever you added)
Packaging everything into an installable file
Applying the right config for debug or release

You never see most of this. It just happens. Until it doesn't — and then you're staring at a red error message wondering what went wrong.

Think of Gradle like the kitchen in a restaurant. As a customer, you never go back there. But if the kitchen breaks, nobody eats. Understanding even the basics of how it works means you're not completely lost when something goes wrong.

Why Does Gradle Exist? (The Actual Reason)

Before build tools like Gradle existed, managing an Android project was genuinely painful. You had to manually download .jar files for every library you wanted to use, add them to your project, manage version conflicts yourself, and figure out the compilation steps on your own.

Gradle came in and said: what if you just declared what you need, and the build tool handled everything else?

That's exactly what it does. Instead of you manually downloading Retrofit and figuring out how to link it to your project, you write one line:
In Older projects:

implementation("com.squareup.retrofit2:retrofit:2.9.0")

In Modern projects:

implementation(libs.retrofit)

And Gradle goes out, finds it, downloads it, and makes it available in your code. You don't touch a .jar file. You don't manage where it's stored. It just works.

That one idea — declare what you want, let Gradle figure out how — is the core of why it exists.

The Part That Confuses Everyone: Project vs Module

This is where most beginners (including me) get lost. You open an Android project and you see two build.gradle files. Nobody explains which one is which or why there are two.

Here's the mental model that finally made it click for me:

Your project is a building. Your app module is an apartment inside it.

The building has rules that apply to everything inside it — shared infrastructure, common configurations. The apartment has its own rules that only apply to itself — its own layout, its own stuff.

That's exactly how the two Gradle files work.

`settings.gradle` — The Building Directory

This file answers one question: what modules exist in this project?

// settings.gradle.kts
pluginManagement {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = "MyApp"
include(":app")

That include(":app") line is Gradle saying "there's a module called app in this project." Most of the time you won't touch this file. But when you add a new module to your project (like a shared library), it gets listed here.

`build.gradle` (Project level) — The Building Rules

This is the top-level config. It applies to the whole project, not just your app.

// build.gradle.kts (Project level)
plugins {
    alias(libs.plugins.android.application) apply false
    alias(libs.plugins.kotlin.android) apply false
}

Notice the apply false — this file declares plugins for the whole project but doesn't actually apply them yet. The individual modules decide whether to use them.

Think of this as the building's shared rules — "these are the tools available to everyone inside." Your app then chooses which ones it actually uses.

`build.gradle` (Module: app) — Your Actual App Config

This is the file you'll spend the most time in. It's where your actual app is configured.

// build.gradle.kts (Module: app)
plugins {
    alias(libs.plugins.android.application) // applies the Android plugin
    alias(libs.plugins.kotlin.android)
}

android {
    namespace = "com.example.myapp"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 24
        targetSdk = 34
        versionCode = 1
        versionName = "1.0"
    }
}

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.compose.ui)
    implementation(libs.retrofit)
}

Let's break down the three sections you actually need to understand:

plugins { } — Activates the Android and Kotlin build tools for this module. You need these. Don't touch them unless you know what you're doing.

android { } — This is your app's identity card. The applicationId is your app's unique ID on the Play Store. minSdk is the oldest Android version your app supports. compileSdk is the Android API version you're building against. versionCode and versionName matter when you publish — increment them with each release.

dependencies { } — This is where you add libraries. Every line here is something Gradle will go download and include in your app. This is probably where you spend most of your time in this file.

The One Thing That Unlocked It All For Me

For a long time I treated Gradle files like config files I wasn't allowed to touch. Fragile. Mysterious. One wrong move and everything explodes.

The shift happened when I started reading errors instead of just Googling them.

Gradle errors are actually pretty descriptive once you slow down and read them. Unresolved reference usually means a dependency is missing or not synced. Could not resolve means Gradle can't find a library — usually a typo or a wrong version number. Duplicate class means two of your dependencies are pulling in the same thing.

None of these are catastrophic. They all have straightforward fixes. But they feel catastrophic when you don't understand what Gradle is doing in the first place.

Now when a build fails, my first move isn't to Google the error. It's to read it. Understand what Gradle is telling me. Then fix it.

That's the mental model that changes everything.

Quick Cheat Sheet

File	What it does	How often you touch it
`settings.gradle`	Lists all modules in your project	Rarely
`build.gradle` (Project)	Global plugin declarations	Rarely
`build.gradle` (app)	Your app config + dependencies	Regularly

Be careful the most important thing, This is a real beginner pain point:

After changing Gradle files, you need to sync the project so Gradle can apply the changes.

My MainActivity Was 700 Lines Long. That's When I Finally Learned MVVM.

Aalaa Fahiem — Sun, 05 Apr 2026 15:00:59 +0000

I'm not even exaggerating with that number. 700 lines. One file. One class. Every single thing my app did — API calls, click listeners, UI updates, data formatting — all crammed into MainActivity.kt like a suitcase someone sat on to close.

It worked. Until it didn't.

The day it fell apart was when I tried to add a simple line of Code. I ended up breaking the list, the error message, and somehow the back button. I spent four hours fixing something that should've taken ten minutes.

That's when I finally stopped avoiding the word I'd been scared of since I started: architecture.

Why I Ignored It For So Long

Honestly? The word itself put me off.

Architecture. It sounds like something senior engineers debate in long meetings. Not something a beginner building their first to-do app needs to worry about.

So I kept ignoring it. Kept piling more code into my Activity. Kept telling myself I'd "refactor later."

Later never came. The code just got worse.

If you're in that same place right now — I get it. But let me tell you what nobody told me: MVVM isn't complicated. It's actually just a way of answering one question —

Who is responsible for what?

That's it. Seriously.

The Analogy That Made It Click For Me

Forget code for a second. Think about a restaurant.

When you go out to eat, there are three people involved in getting food to your table:

🍽️ The waiter takes your order and brings your food. They don't cook anything. They don't decide what's on the menu. They just deal with you.
👨‍🍳 The chef does all the actual work. Takes the order from the waiter, figures out how to prepare it, sends it back out. Never comes to your table.
📦 The stockroom has all the ingredients. The chef goes there to get what they need. You never see it. The waiter definitely doesn't go back there.

Three people. Three jobs. Nobody steps on anyone else's toes.

MVVM is exactly this:

Your View (Activity, Fragment, Composable) = the waiter. Shows things to the user. Reacts to what the user does. That's all.
Your ViewModel = the chef. Holds the logic. Decides what data to use and when. Never touches the UI directly.
Your Model (Repository, database, API) = the stockroom. Just holds and provides data. Doesn't care who's asking or why.

When I understood this, everything else fell into place.

What My Code Looked Like Before (Please Don't Judge Me)

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // calling the API straight from the Activity 💀
        CoroutineScope(Dispatchers.IO).launch {
            val users = RetrofitClient.api.getUsers()
            withContext(Dispatchers.Main) {
                adapter.submitList(users)
            }
        }
    }
}

This looks innocent. It's not.

Rotate the phone → Activity gets destroyed → coroutine gets cancelled
→ the API gets called again from scratch. Every. Single. Rotation.

Also, try writing a test for this. You can't. The networking is baked directly into the UI layer. There's no way to test the logic without spinning up the whole Activity.

I didn't even know this was a problem until it bit me.

What It Looks Like After

Here's the same feature split across three layers the right way:

The Model — just fetches data, nothing else

class UserRepository(private val api: ApiService) {
    suspend fun getUsers(): List<User> = api.getUsers()
}

The ViewModel — holds the logic and the state

class UserViewModel(private val repository: UserRepository) : ViewModel() {

    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users: StateFlow<List<User>> = _users

    init { loadUsers() }

    private fun loadUsers() {
        viewModelScope.launch {
            _users.value = repository.getUsers()
        }
    }
}

The View — just watches and reacts

class MainActivity : AppCompatActivity() {

    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        lifecycleScope.launch {
            viewModel.users.collect { users ->
                adapter.submitList(users)
            }
        }
    }
}

Three files. Each one does one thing. The Activity has no idea how users are fetched. The ViewModel has no idea how they're displayed. And if I rotate the phone? The ViewModel is still alive — data doesn't reload, nothing breaks.

The One Thing I Wish Someone Had Told Me

The ViewModel isn't just an organizational trick. It has an actual superpower that nothing else gives you:

It survives configuration changes.

When you rotate your phone, Android destroys and recreates your Activity. This is just how Android works — it's not a bug. But if your data lives inside the Activity, it dies with it.

A ViewModel doesn't. It stays alive across rotations, theme changes, keyboard toggles — anything that would normally kill your Activity. When the Activity comes back, it reconnects to the same ViewModel that was already there, with all its data intact.

That alone is worth learning MVVM for.

The Honest Truth About Getting Started

You're not going to write perfect MVVM on your first try. I didn't. My first "MVVM" app still had logic leaking into the Activity in places. I used LiveData wrong. My Repository was doing things it shouldn't.

That's fine.

The goal isn't perfection. The goal is to stop putting everything in one place. Even a messy, imperfect separation of concerns is infinitely better than a 700-line Activity.

Start on your next project. Even a small one. Just ask yourself before writing anything: does this belong in the View, the ViewModel, or the Model?

That question alone will change how you write code.

5 Things I Wish I Knew Before Writing My First Android App

Aalaa Fahiem — Fri, 03 Apr 2026 14:06:48 +0000

This article is for beginners building their first Android app using Kotlin and Jetpack Compose.

So I decided to build an Android app. How hard could it be, right?

Turns out — pretty hard. Not impossible, but full of surprises that nobody warns you about. I'm still learning, but I've already collected a solid list of "why didn't anyone tell me this?" moments. Here are the five biggest ones.

1. Architecture Isn't Just for Big Projects

When I started, I threw everything into one file. Logic, UI, data fetching — all living together in one giant MainActivity.kt. It worked… until it didn't.

The moment I needed to change something, I'd break something else. I had no idea what MVVM (Model-View-ViewModel) was, and honestly the name scared me off.

Here's what I wish someone had told me earlier:

Architecture isn't about being fancy. It's about not hating your own code two weeks later.

Even for a small app, separating your UI (the View) from your logic (the ViewModel) makes everything easier to read, test, and fix. Start with MVVM from day one. Android Jetpack's ViewModel and StateFlow are built for this — don't ignore them.

Takeaway: Before writing a single line of UI code, ask yourself: where will the logic for this live?

2. Android Will Destroy and Recreate Your Activity — Deal With It

This one got me bad.

I had a form where users filled in their details. When I rotated the phone, everything disappeared. I panicked. I thought I had a bug. I didn't — that's just Android doing its thing.

Android destroys and recreates your Activity on configuration changes (like rotation, language change, or dark mode toggle). If you don't handle this, your app loses all its state every time.

The fix? Use a ViewModel — it survives configuration changes. Or use rememberSaveable if you're on Jetpack Compose. Either way, don't store important state directly in your Activity or Fragment and expect it to stick around.

@Composable
fun ExampleScreen(viewModel: MyViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsState()

    Text(text = state.username)
}

Takeaway: The Android lifecycle is not your enemy, but it will punish you if you ignore it.

3. Android Studio and Gradle Will Humble You

I expected a smooth coding experience. What I got instead was:

Gradle syncing for 4 minutes
Mysterious build errors with no helpful message
"Invalidate Caches and Restart" becoming my most-used button

Android Studio is powerful, but it's heavy. Here's what actually helped me:

Keep Gradle and your dependencies updated, but not blindly — always check the changelog before upgrading.
Learn the difference between implementation, api, and testImplementation in your build.gradle. It matters.
When something breaks and you don't know why: clean the project (Build → Clean Project), then rebuild. Fixes more than it should.
The Logcat panel is your best friend. Filter by your app's package name and read the errors carefully — they're usually telling you exactly what's wrong.

Takeaway: Gradle is not magic. Learn the basics of how it works and you'll save yourself hours of frustration.

4. AI Agents Are Powerful — But They Can Quietly Mislead You

When I got stuck, I started asking AI assistants (like ChatGPT or Claude) for help. And honestly? They're incredible. They explain errors in plain English, suggest fixes instantly, and can write boilerplate code in seconds.

But there's a trap I fell into: trusting AI output without questioning it.

AI agents don't always know the latest Android APIs. They can confidently suggest a method that was deprecated two versions ago, or generate code that compiles fine but behaves incorrectly at runtime. The code looks right — that's what makes it dangerous for beginners.

Here's how I learned to use AI tools better:

Always ask it to explain the code, not just give it to you. If it can't explain a line clearly, that's a red flag.
Cross-check with the official Android docs. AI is a great starting point, not the final word.
Tell it your context — your API level, whether you're using Compose or XML, Kotlin or Java. Vague questions get vague answers.
If something feels off about the generated code, trust that feeling and dig deeper.

AI is like a very fast, very confident pair programmer who sometimes hallucinates. Use it, but stay in the driver's seat.

Takeaway: AI agents can save you hours — but only if you understand what they're giving you.

5. Performance Problems Are Invisible Until They're Not

My first app felt fine on my phone. Then I tested it on an older device and it was sluggish. Scrolling lists stuttered. The UI froze when loading data.

Two things caused most of my problems:

. Doing heavy work on the main thread. Network calls, database reads, file operations — none of these belong on the UI thread. Use coroutines (viewModelScope.launch { })
to move work to the background. It's easier than it sounds.

You don't need to be a performance expert from day one. But knowing that these issues exist means you can avoid the worst of them early.

Takeaway: Run your app on a low-end device or emulator occasionally. It'll reveal problems your flagship phone hides.

Android development has a steep learning curve, and that's okay. Every confusing error message, every configuration change crash, every Gradle failure — it's all part of learning how the platform works.

If you're just starting out: focus on fundamentals, not features.

Build small. Break things. Learn why they broke.

That’s how you actually improve.

Still learning. Still building. Let me know in the comments if any of these hit close to home — or if there's something you wish you'd known sooner!