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.

Activity x Compose Lifecycle: The Complete Visual Guide 🚀

 

👨‍💻 Activity Lifecycle


Activity.onCreate() <- Activity is created

↓

Activity.onStart() <- Preparing to become visible on screen

↓

Activity.onResume() <- Foreground state (interactive)

↓

Activity.onPause() <- Partially visible

↓

Activity.onStop() <- No longer visible

↓

Activity.onDestroy() <- Activity is destroyed

 

👨‍💻 Compose Lifecycle


[First Composition]
  - Composable is evaluated, Compose tree is built
  - LaunchedEffect -> Runs once after the commit
  - SideEffect -> Runs after every commit
  - DisposableEffect -> onDispose is called upon disposal

↓

[Recomposition]
  - UI is re-evaluated in response to state or data changes
  - Only the necessary parts are recomposed (efficient update)
  - SideEffect and DisposableEffect are also re-evaluated during recomposition

↓

[Dispose]
  - Depends on the ComposeView's disposal condition
  - DisposableEffect's onDispose is executed
  - Disposal timing is determined by the ViewCompositionStrategy

 

👨‍💻 Activity x Compose Lifecycle


Activity.onCreate() setContent { ... } <- Sets the ComposeView

↓

[First Composition]
  - Evaluates Composables and builds the UI
  - LaunchedEffect -> Runs once after commit
  - SideEffect -> Runs after each commit
  - DisposableEffect -> Defines onDispose

↓

Activity.onStart()

↓

Activity.onResume()

↓

[Recomposition]
  - Re-evaluates necessary parts in response to state changes
  - LaunchedEffect is not re-executed (only if its key changes)
  - SideEffect / DisposableEffect are re-evaluated

↓

Activity.onPause()

↓

(ComposeView is retained)
  - UI becomes partially obscured
  - State is maintained within the Composition

↓

Activity.onStop()

↓

[Preparing for Dispose (Detection)]
  - ViewCompositionStrategy monitors disposal conditions

↓

Activity.onDestroy()

↓

[Dispose]
  - ComposeView is destroyed
  - DisposableEffect.onDispose() is executed

This is the general flow.

Here are the notes for each item:

Activity.onCreate() A lifecycle method called when an Android app's Activity is created.

    setContent { ... }: Sets the UI using Jetpack Compose. This sets a ComposeView as the Activity's content view. The Compose lifecycle begins.

  • First Composition The Composable functions set in setContent are evaluated for the first time, and the UI is built.

LaunchedEffect: An Effect used for asynchronous processing. Runs only once after the first composition.

SideEffect: Runs after every composition commit (the timing when UI changes are applied).

DisposableEffect: An Effect used for resource cleanup. The logic defined in onDispose is executed when the Composition is disposed.

Activity.onStart() A lifecycle method called just before the Activity becomes visible to the user.

Activity.onResume() The Activity moves to the foreground and becomes fully interactive with the user.

  • Recomposition Only the necessary Composable functions are re-evaluated in response to changes in State.

LaunchedEffect: It is not re-executed during recomposition. However, it will be re-executed if its key changes.

SideEffect: It is re-evaluated on every recomposition.

DisposableEffect: It is re-evaluated on recomposition, and the cleanup logic (onDispose) from the old Effect is called.

Activity.onPause() The Activity enters a paused state and becomes partially obscured.

ComposeView Retention: The UI is not destroyed; it is retained. The state is also maintained within the Composition, allowing it to be reused upon re-display.

Activity.onStop() The Activity is no longer visible. A time to prepare for cleaning up state and resources.

Preparing for Dispose (Detection) ViewCompositionStrategy: A mechanism that monitors the conditions under which the ComposeView should be disposed. It triggers the Composition's disposal based on the View's lifecycle.

Activity.onDestroy() The timing when the Activity is completely destroyed.

  • Dispose The ComposeView is destroyed: The UI and state are completely released.
  • DisposableEffect.onDispose(): The resource cleanup logic is called.

 

👨‍💻 Summary

The Jetpack Compose and Activity lifecycles are closely linked, with specific processes occurring at each stage, from UI initialization (setContent) to disposal (Dispose).

It is especially important to understand the differences between effects like LaunchedEffect, SideEffect, and DisposableEffect, and to manage them appropriately.

Furthermore, by efficiently reusing the UI in response to Activity state changes (like onResume or onPause) and cleaning up resources as needed, you can achieve stable application behavior.

初回コンポーズは Activity.onStart() までに終わる

 

🤔 Activity x Compose のライフサイクル


Activity.onCreate()
  setContent { ... }   ← ComposeView をセット

    ↓

  ［初回コンポーズ（First Composition）］
    ・Composable を評価し UI を構築
    ・LaunchedEffect → コミット後に一度実行
    ・SideEffect → 各コミットごとに実行
    ・DisposableEffect → onDispose 定義

    ↓

Activity.onStart()

    ↓

Activity.onResume()

    ↓

  ［再コンポーズ（Recomposition）］  
    ・状態変更に応じて必要部分のみ再評価
    ・LaunchedEffect は再実行されない（Key 変更時のみ）
    ・SideEffect / DisposableEffect は再評価

    ↓

Activity.onPause()

    ↓

  （ComposeView は保持）
    ・UI は部分的に見えなくなる
    ・状態は Composition 内で維持

    ↓

Activity.onStop() 

    ↓

  ［破棄準備（Dispose 検知）］
    ・ViewCompositionStrategy による破棄条件監視

    ↓

Activity.onDestroy()

    ↓

  ［破棄（Dispose）］
    ・ComposeView が破棄される
    ・DisposableEffect.onDispose() 実行

 

🤔 まとめ

初回コンポーズは Activity.onStart() までに終わる。

👉 これだけでわかる！Activity × Compose のライフサイクル完全図解 🚀

JSON と JSON5 の違い

JSON と JSON5 は見た目は似ていますが、「どれくらい人間に優しいか」「どれくらい厳格か」で大きく違います

 

🧩 JSONとは

JavaScript Object Notation の略で、
データ交換フォーマットとして最も一般的なものです。

 

✅ 特徴

・厳格でシンプル
・仕様が固定されていて機械処理に最適
・ほとんどの言語・ツールが標準対応

 

📋 制約


{
  "name": "Mao",
  "age": 25,
  "languages": ["Swift", "Kotlin"]
}

・文字列は必ず ダブルクォート
・コメント不可
・末尾カンマ禁止
・キーもクォート必須
・数値表現 は10進数のみ

 

🌈 JSON5とは

JSON for Humans（人間に優しいJSON）で
JSONの上位互換として提案されたフォーマットです。

JavaScriptライクな書き方を許します。

 

✅ 特徴

・より柔軟で可読性が高い
・コメントや末尾カンマをサポート
・キーや文字列のクォート省略OK
・16進数や+∞などの数値表現が可能

 

📋 例


{
  // コメントOK
  name: 'Mao',
  age: 25,
  languages: ['Swift', 'Kotlin',], // 末尾カンマOK
  version: 0x1f, // 16進数OK
}

 

🤔 JSON と JSON5 の比較

JSON は機械向けの厳格フォーマット、JSON5 は「人間向け」に拡張されたフォーマットです。下の表はブログでそのまま使える比較表です。

項目 JSON JSON5
コメント 不可（コメントなし） 可（`//`、`/* */` が使える）
末尾カンマ 不可 可
キーのクォート 必須（ダブルクォート） 省略可（識別子としてのキーを許可）
文字列のクォート ダブルクォートのみ（`"`） シングルクォートまたはダブルクォート可（`'` / `"`）
数値表現 10進数のみ 10進数、16進数、`NaN`、`Infinity` などを許可
対応ツール 非常に多い（ほぼ標準） ライブラリが必要（サポートは限定的）
用途 機械間通信（API等）に最適 開発者向け設定ファイルや手で編集するデータに適する

 

🧑🏻‍💻 まとめ

- JSON：厳格で機械向け。安全・標準的。
- JSON5：柔軟で人間向け。コメントや末尾カンマOK。

Jetpack Compose 1.7+ でクリップボードコピーをどう書く？

 

🧑🏻‍💻 LocalClipboard と suspend 関数の組み合わせ

Compose 1.7 以降では、従来の ClipboardManager が非推奨になり、代わりに LocalClipboard + 非同期コピー が公式に推奨されています。

以下はシンプルなサンプルです。rememberCoroutineScope を使い、クリックイベントで非同期コピーを行っています。


val clipboard = LocalClipboard.current
val scope = rememberCoroutineScope()

Box(modifier = Modifier.clickable {
    scope.launch {
        val clipData = ClipData.newPlainText(uuid, uuid)
        clipboard.setClipEntry(clipData.toClipEntry())
    }
})

👉 Jason Ernst: Android ClipboardManager Deprecated: How to fix

 

🧑🏻‍💻 ViewModel 側でコピー処理をまとめる

世界的に著名な Android 開発者 Chris Banes や Jake Wharton のサンプルコードでは、UI 層から直接 Clipboard を操作せず、ViewModel に処理をまとめる パターンが多く見られます。

このアプローチを取ることで、UI の再コンポーズと Clipboard 操作が分離でき、よりテストしやすい設計になります。


class NoteViewModel : ViewModel() {
  fun copy(block: suspend () -> Unit) {
    viewModelScope.launch {
      block()
    }
  }
}

UI 側では以下のように呼び出せます：


IconButton(
  onClick = { 
    viewModel.copy {
      clipboard.setText(item.text)
    }
  }
) {
  Icon(Icons.Default.ContentCopy, contentDescription = null)
}

Clipboard 拡張関数を定義しておくと便利です。


suspend fun Clipboard.setText(text: String) { 
    val clipData = ClipData.newPlainText(text, text).toClipEntry() 
    setClipEntry(clipData)
}

 

🧑🏻‍💻 まとめ

ClipboardManager は非推奨 → LocalClipboard + suspend が公式推奨。

UI 層はイベントを投げるだけ、コピー処理は ViewModel で完結。

Coroutine scope を ViewModel 内で扱うことで UI の再コンポーズに影響しない。

ViewModel が clipboard を直接握るのは避けたほうがベター。
（非 UI 層に UI 依存を持ち込むことになるため）

拡張関数で共通処理化すれば再利用性が高まる。

つまり、

「UI はシンプルに」「コピー処理は ViewModel に集約」

これが現代的な Compose + Clipboard のベストプラクティスです。