Fix KMM commonMain Unresolved Imports Android Studio

Unresolved imports in KMM commonMain source sets plague fresh Android Studio templates, showing red lines for Compose Multiplatform, coroutines, and more—even when Gradle syncs, builds, and runs perfectly. This stems from IDE failing to index multiplatform metadata properly in Kotlin 2.3.0 projects. Fix it fast by adding the com.android.library plugin to your shared module, enabling granular source sets in gradle.properties, and tweaking dependencies like swapping coroutines-swing for coroutines-core.

Contents

• Understanding Unresolved Imports in KMM commonMain
• Primary Fix: Add com.android.library Plugin to Shared Module
• Enable Granular Source Set Metadata in Gradle Properties
• Correct Dependencies for commonMain in KMM Android Studio
• Version Compatibility Fixes for Kotlin 2.3.0 and Compose
• IDE Refresh and Housekeeping Steps
• Troubleshooting Persistent Red Imports in KMM
• Verification and Best Practices for KMM commonMain
• Sources
• Conclusion

Understanding Unresolved Imports in KMM commonMain

Picture this: you fire up Android Studio, grab the shiny KMM template, hit sync, and boom—everything builds. Run it on your emulator? Flawless. But peek into shared/src/commonMain/kotlin? Every import’s screaming red. import androidx.compose.material3.*? Red. kotlinx.coroutines.*? Still red. You’ve nuked caches, zapped .idea and .gradle dirs, even rolled back Gradle. Nothing sticks.

Why? Kotlin Multiplatform’s commonMain relies on metadata aggregation across targets (android, ios, jvm, etc.). Gradle resolves this at build time via the MPP compiler. But Android Studio’s indexer? It chokes on fresh templates using Kotlin 2.3.0 and Compose Multiplatform 1.9.3. The IDE can’t map libraries to source sets without explicit hints—like Android plugins or flags. This hit a recent Stack Overflow thread with identical symptoms: AGP 8.1+, version catalogs, and zero runtime issues.

Common culprits? Version catalogs bundling desktop-only deps like kotlinx-coroutines-swing into commonMain. Or missing granular metadata, leaving the IDE blind. Don’t sweat it—these are template quirks, not your code. Next up, the fixes that actually work.

Primary Fix: Add com.android.library Plugin to Shared Module

Hands down, the quickest win. KMM templates slap kotlin("multiplatform") and kotlin("android") on the shared module, but skip com.android.library. Without it, Android Studio treats commonMain like a pure Kotlin module—no source set bridging.

Crack open shared/build.gradle.kts (or composeApp/build.gradle.kts if that’s your shared). Add this to the plugins block:

plugins {
 kotlin("multiplatform")
 id("com.android.library") // <- The magic line
 kotlin("android")
 // ... your other plugins
}

Sync Gradle. Watch those reds fade—Compose imports resolve first, then coroutines. Why? This plugin wires Android variant awareness into IntelliJ’s indexing, per this confirmed Stack Overflow solution.

But if your project lacks an androidMain source set? Add one minimally:

kotlin {
 androidTarget() // Enables androidMain implicitly
 // ... ios targets
 sourceSets {
 val commonMain by getting { /* deps here */ }
 val androidMain by getting { /* empty or mirror commonMain */ }
 }
}

Test it: import expect class Platform() in commonMain. No more underlines. Boom.

Enable Granular Source Set Metadata in Gradle Properties

Plugin alone might not cut it for Kotlin 2.3.0. The IDE needs explicit metadata for MPP deps. Drop into project root gradle.properties (create if missing):

kotlin.mpp.enableGranularSourceSetsMetadata=true
kotlin.native.enableDependencyPropagation=false

First flag tells the compiler to spit out per-source-set artifacts—crucial for commonMain resolution. Second prevents iOS/desktop leakage into Android indexing. Sync, then Gradle → Reload. Reds should vanish project-wide.

This combo fixed Ktor imports in commonMain, mirroring your Compose woes. Pro tip: if using version catalogs, regenerate libs.versions.toml post-changes via Gradle → Refresh.

Still red? Your template’s Compose BOM might be bleeding platform-specifics. Onward.

Correct Dependencies for commonMain in KMM Android Studio

Version catalogs are double-edged. Your libs.versions.toml shoves kotlinx-coroutines-swing (desktop-only) into commonMain via defaults. Swap it.

In shared/build.gradle.kts, under commonMain.dependencies:

kotlin {
 sourceSets {
 val commonMain by getting {
 implementation(compose.runtime)
 implementation(compose.foundation)
 implementation(compose.material3)
 implementation(platform(libs.androidx.compose.bom)) // BOM first!
 implementation(libs.kotlinx.coroutines.core) // Not swing!
 // Ditch composeHotReload in commonMain—it's tooling
 }
 }
}

Key shifts:

• Platform BOM upfront: Ensures Compose versions unify across targets.
• Coroutines-core: Universal; swing stays in desktopMain.
• No androidMain mirrors here: Let plugin handle propagation.

Nuke composeHotReload plugin from shared if present—it’s Android-only tooling. Regenerate catalogs, sync. ProAndroidDev dives deep on these dep pitfalls.

New deps like Ktor? implementation("io.ktor:ktor-client-core:2.3.12")—they’ll resolve now.

Version Compatibility Fixes for Kotlin 2.3.0 and Compose

Kotlin 2.3.0 + Compose 1.9.3? Bleeding edge, but buggy in AGP 8.1.3 templates. JetBrains YouTrack flags indexing fails in commonMain.

Quick matrix:

In libs.versions.toml:

[versions]
kotlin = "2.0.20" # Safer
composeMultiplatform = "1.6.11"
androidx-compose-bom = "2024.09.03"

Sync. If locked in, patch gradle.properties with kotlin.incremental.compilation=false temporarily.

IDE Refresh and Housekeeping Steps

Changes made? Don’t just sync—ritualize:

1. Gradle → Reload Gradle Project.
2. Build → Clean Project → Rebuild Project.
3. File → Invalidate Caches → Invalidate and Restart (check all boxes).
4. Delete shared/src/commonMain/kotlin thumbs.db or caches if on Windows.

Kotlin Slack chats swear by rebuild post-flags. Android Studio Koala 2024.1.1+ patches composite build indexing—update if lagging.

Troubleshooting Persistent Red Imports in KMM

Reds linger? Diagnose:

Check settings.gradle.kts includes include(":shared"). No composite builds? Good. Last resort: nuke .idea, reimport as Gradle project.

Verification and Best Practices for KMM commonMain

Verify: Add import io.ktor.client.* to commonMain—resolves? Add to libs.versions.toml, implementation(libs.ktor.client.core) in deps. Sync. Green everywhere.

Best habits:

• Always com.android.library in shared.
• Granular metadata on.
• commonMain: only expect/actual + pure multiplatform libs.
• Test: ./gradlew shared:compileKotlinMetadata—no errors.

Future-proof: Pin Kotlin/Compose to stable channels. Your KMM commonMain’s now bulletproof.

Sources

1. False IDE red imports in fresh KMM commonMain — Exact match for unresolved imports in Android Studio templates despite builds: https://stackoverflow.com/questions/79866372/false-ide-red-imports-in-a-fresh-kmm-projects-commonmain-module
2. Ktor dependency in commonMain unresolved — Granular metadata and plugin fixes for KMM imports: https://stackoverflow.com/questions/66238910/ktor-dependency-in-commonmain-of-android-studio-multiplatform-project-unresolved
3. Kotlin Multiplatform cannot resolve references — Adding com.android.library plugin resolves IDE indexing: https://stackoverflow.com/questions/62068133/kotlin-multiplatform-cannot-resolved-references-while-gradle-sync-succeeds
4. Composite Project Libraries not resolved in IDE — YouTrack issue on commonMain metadata with Kotlin 2.x: https://youtrack.jetbrains.com/issue/KT-60864/Composite-Project-Libraries-not-resolved-in-IDE-but-project-build-successfully-common-main-only-Android-Main-works
5. KMM IDE broken imports with Composite Build — Official tracking of Android Studio KMM indexing bugs: https://youtrack.jetbrains.com/issue/KTIJ-18903/KMM-IDE-broken-imports-and-find-usages-with-Composite-Build
6. Current issues with Kotlin Multiplatform — Dependency management pitfalls in commonMain source sets: https://proandroiddev.com/current-issues-with-kotlin-multiplatform-and-how-to-fix-them-5ae62822a546
7. IDE red lines but builds fine — Slack discussion on flags and rebuild sequence for KMM: https://slack-chats.kotlinlang.org/t/524613/in-the-ide-i-get-these-red-lines-errors-hsowever-it-all-buil

Conclusion

Tackle KMM commonMain unresolved imports head-on: plugin first, metadata flags second, deps cleaned third, then refresh ruthlessly. Kotlin 2.3.0 templates trip up, but these steps greenlight your project every time. What’s next—toss in Ktor or SQLDelight? Your shared module’s ready. Questions? Dive into the sources or tweak versions. Happy cross-platform coding.