Troubleshooting SQLDelight: The "KotlinSourceSet 'main' not found" Error in AGP 9

If you've recently tried jumping onto the bleeding edge with Android Gradle Plugin (AGP) 9.0, you might have hit a brick wall during project sync. A common culprit popping up lately is a cryptic error from SQLDelight:


KotlinSourceSet with name 'main' not found.

This issue, tracked under SQLDelight #6078, highlights a significant shift in how Android and Kotlin interact in the latest build tools. Here’s the breakdown of what's happening and how to fix it.

👉 KotlinSourceSet with name 'main' not found with AGP9 · Issue #6078 · sqldelight/sqldelight

 

🧑🏻‍💻 The Problem: Why is 'main' Missing?

The conflict arises because AGP 9 introduces a "New DSL" and changes how Kotlin source sets are managed. Historically, SQLDelight’s Gradle plugin looked for a source set explicitly named "main" to inject its generated code.

However, in AGP 9 (especially with the builtInKotlin flag enabled), the way source sets are registered has changed. The legacy "main" container that SQLDelight expects is either missing or hidden, causing the configuration phase to fail immediately.

 

🧑🏻‍💻 The Discussion Flow: From Discovery to Workaround

The GitHub thread reveals an interesting evolution of the fix:

  • The Discovery: Early adopters reported that even disabling the experimental newDsl didn't fix the crash.
  • The Culprit: Contributors identified that the SQLDelight plugin was making "unsafe" assumptions about the existence of the "main" source set.
  • The Temporary Fix: A specific flag in gradle.properties was found to restore the old behavior, allowing the plugin to find what it needs.

 

🧑🏻‍💻 How to Fix It (The Workaround)

Until the official patches in SQLDelight (specifically PR #6079 and #6091) are fully merged and released, you can unblock your development by adding these flags to your gradle.properties file:


# Temporary fix for SQLDelight + AGP 9
android.newDsl=false
android.builtInKotlin=true
android.disallowKotlinSourceSets=false

The key line here is android.disallowKotlinSourceSets=false. This tells AGP 9 to allow the traditional Kotlin source set structures that SQLDelight currently relies on.

 

🧑🏻‍💻 The Road Ahead: Permanent Fixes

The maintainers (including Jake Wharton and the CashApp team) are already working on a long-term solution. The goal is to move away from searching for "main" and instead use the proper AGP/Kotlin API to register generated code.

  • PR #6079: Focuses on implementing a more robust schema configuration.
  • PR #6091: Modernizes the plugin to play nice with the AGP 9 New DSL.

The takeaway?

AGP 9 is a major shift. If you’re using third-party plugins that generate code (like SQLDelight or Wire), expect a few bumps in the road as these libraries catch up to the new Gradle architecture.

Fix "InitializationProvider" Error in the AGP 9 Era 🚀

Hi fellow Android devs! 🤖

You’ve finished your app, everything works perfectly in Debug mode, and you’re finally ready to hit that "Release" button. But then… CRASH. 💥

You look at the logs and see this scary message: 


Fatal Exception: java.lang.RuntimeException: 
  Unable to get provider androidx.startup.InitializationProvider

Don't worry! You’re not alone, and your code isn't "broken." You've just run into a little disagreement between WorkManager and R8 (the code shrinker), especially if you're using the latest AGP 9 (Android Gradle Plugin).

Let’s fix it together in 3 minutes! ☕️

 

What’s happening under the hood? 🧐

When you set isMinifyEnabled = true for your release build, a smart tool called R8 starts cleaning up your code. It looks for anything "unused" and removes it to make your app tiny.

However, WorkManager (the tool that handles background tasks for things like AdMob or Firebase) has a little secret: it uses a class called WorkDatabase_Impl.

The problem? R8 doesn't see anyone "calling" this class in your code, so it thinks, "Hey, this is trash!" and throws it away. When your app starts, WorkManager looks for its database class, finds nothing, and—BOOM—the app crashes.

With AGP 9, R8 is stricter than ever, so we have to be very clear about what we want to keep.

You don't even need to update your library versions. Just follow these steps.

 

Step 1: Tell R8 to "Hands Off!" 🛑

Open your proguard-rules.pro file and add these lines. This tells the compiler: "I know it looks unused, but I need this! Please don't touch it."


# Keep the WorkManager internal database!
-keep class androidx.work.impl.WorkDatabase_Impl { *; }

# Also keep the "Worker" constructors so they can do their jobs
-keep class * extends androidx.work.ListenableWorker {
    <init>(android.content.Context, androidx.work.WorkerParameters);
}

 

Step 2: Give it a Fresh Start ✨

AGP 9 loves caching things. To make sure your new rules are applied:


Click Build > Clean Project.
Click Build > Rebuild Project.

 

Step 3: The "Magic" Re-install 📲

If your app tried to start and failed, it might have left some messy, half-finished files behind. Uninstall the app from your phone/emulator first, then install the new build. This ensures a 100% clean slate!

 

Wrapping Up 🎁

That’s it!

Your app should now be running smoothly even with isMinifyEnabled = true.

The AGP 9 era brings us faster and smaller apps, but it also means we have to be a bit more specific with our ProGuard/R8 rules.

Keep an eye on those "Impl" classes, and you'll be a release-build master in no time!

Happy coding! 💻✨

👉 【Android/AGP9対応】AdMob起因？WorkManagerとApp Startupで頻発するクラッシュをProGuard設定で解決する

Embracing AGP 9 and JDK 21: A Gradual Path to Android Build Optimization

As Android developers, major AGP (Android Gradle Plugin) updates are always significant. AGP 9 in particular promises a stricter, faster build environment, moving away from ambiguous configurations.

Instead of waiting for its full release and then scrambling to fix issues, why not start preparing your project now, gradually aligning it with "AGP 9 standards" through your gradle.properties file?

 

🤔 Why JDK 21 and AGP 9 Now? (The Ultimate Synergy)

When transitioning to AGP 9, updating to JDK 21 isn't just a "requirement"; it's a powerful "booster" that dramatically enhances your development experience.

  • Performance Synchronization: JDK 21's improved resource management, including features like Virtual Threads, allows Gradle to fully leverage its parallel build capabilities, leading to more stable and efficient builds.
  • Language Specification Alignment: By targeting Java 21, you bridge potential gaps in type inference and bytecode generation in mixed Java/Kotlin projects, especially as Kotlin 2.x gains traction.
  • Precision R8 Optimization: AGP 9 is optimized to parse and transform class files generated by JDK 21. This means that even with stricter settings, R8 can more accurately understand modern code structures, reducing the need for excessive keep rules while safely shrinking code.

This combination offers the kind of seamless experience you get from pairing the latest OS with the latest CPU.

 

🤔 Prepare with gradle.properties: 10 Flags to Enable Today

The strategy is simple: enable one flag at a time, fix any errors that arise, and then move to the next. This iterative approach is the most reliable way to prepare for AGP 9.

1. Structure Enforcement (Clean Up Your Project)

  • android.uniquePackageNames=true: Prevents duplicate package names across modules, eliminating resource conflicts.
  • android.usesSdkInManifest.disallowed=true: Enforces placing minSdk, targetSdk, etc., in build.gradle instead of AndroidManifest.xml.
  • android.defaults.buildfeatures.resvalues=true: Explicitly controls the generation of resValue entries.

2. Build Speed Enhancements

  • android.enableAppCompileTimeRClass=true: Uses lightweight R classes during app compilation, significantly improving build times for large projects.
  • android.sdk.defaultTargetSdkToCompileSdkIfUnset=true: Automatically sets targetSdk to compileSdk if unspecified, preventing inconsistent behavior.
  • android.dependency.useConstraints=true: Utilizes Gradle's "Constraints" feature for dependency resolution, making library version management more robust.

3. Aggressive R8 / Optimization Settings (The Biggest Hurdle)

  • android.r8.strictFullModeForKeepRules=true: Enables R8's Full Mode. This maximizes optimization but requires precise keep rules for code that relies on reflection, potentially leading to crashes if not handled correctly.
  • android.r8.optimizedResourceShrinking=true: Employs a more advanced algorithm for removing unused resources, leading to smaller app sizes.

4. Next-Gen Defaults

  • android.builtInKotlin=true: Prioritizes AGP's built-in Kotlin support.
  • android.newDsl=false: Use this to maintain the current DSL while preparing for future changes.

 

🤔 Conclusion: One Flag at a Time for a Smoother Future

The AGP 9 update is akin to a major cleanup. Attempting it all at once can be overwhelming, but tackling it gradually makes it incredibly rewarding.

Why not start with android.uniquePackageNames=true? With each flag you enable, your project will move closer to a more modern, robust, and efficient build environment.

👉 AGP 9.0 移行ガイド：新旧コード比較で見るモダンビルド設定