Kotlin Multiplatform Mobile | #iOS | #Android Fashion News

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

Last updated : 2026-02-01 19:32

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 移行ガイド：新旧コード比較で見るモダンビルド設定

Kotlin・KSP・Compose Compiler を安全に更新する Renovate 設定術（developブランチ運用編）

Last updated : 2025-10-07 22:01

Jetpack Compose Compiler が Kotlin に強く依存していた時代を経て、
今では少しずつ依存関係が緩やかになってきました。
それでも Kotlin・KSP・Compose Compiler の3つは依然として密接に関係しており、
バージョンのズレひとつでビルドが崩壊するリスクがあります。

この記事では、develop ブランチをメインに運用しつつ、
それらを安全かつ一貫性を保って更新するための Renovate 設定を紹介します。

🧩 Kotlin・KSP・Compose Compiler の三位一体更新

Compose Compiler は Kotlin コンパイラと深く結びついて動作するため、
Kotlin のメジャーアップデートが入ると、それに対応した Compose Compiler が必要になります。

さらに、KSP（Kotlin Symbol Processing）も Kotlin バージョンに追随するため、
この3つは基本的に「セットで更新する」のが鉄則です。


{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "baseBranches": ["develop"],
  "packageRules": [
    {
      "groupName": "Kotlin, KSP and Compose Compiler",
      "groupSlug": "kotlin",
      "matchPackagePrefixes": [
        "com.google.devtools.ksp",
        "org.jetbrains.compose.compiler"
      ],
      "matchPackagePatterns": [
        "org.jetbrains.kotlin.*"
      ]
    },
    {
      "description": "Do not automerge without CI",
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "automerge": false
    }
  ]
}

⚙️ 設定の意図を読み解く

この設定は、単に自動更新を行うだけでなく、
Kotlin 界隈の依存を安全に、かつチームの開発フローに合わせて管理することを意識しています。


baseBranches: ["develop"]

Renovate のデフォルトは main や master に対して PR を作りますが、
実際の開発フローでは「開発用ブランチ（develop）」に更新を入れたいケースが多いですよね。

"baseBranches": ["develop"] を指定しておくことで、
更新 PR が常に develop ブランチに向けて作成されるようになります。

本番リリース前にテストや検証を挟める安全設計です。

🔗 groupName: 三つ巴のアップデートを1つにまとめる

groupName は、関連する依存をひとまとめにするためのグループ名。
ここでは "Kotlin, KSP and Compose Compiler" としており、
3つのパッケージを同時に1つの PR にまとめてくれます。


"matchPackagePrefixes": [
  "com.google.devtools.ksp",
  "org.jetbrains.compose.compiler"
],
"matchPackagePatterns": [
  "org.jetbrains.kotlin.*"
]

この指定で次のような依存が同時更新対象になります：


- Kotlin (org.jetbrains.kotlin)

- KSP (com.google.devtools.ksp)

- Compose Compiler (org.jetbrains.compose.compiler)

以前は androidx.compose.compiler でしたが、
現在の Compose Multiplatform では org.jetbrains.compose.compiler に移行しているため、この設定がより正確です。

🚫 automerge: false の哲学

Renovate には更新を自動マージする機能がありますが、
Kotlin 系の更新はそれに向きません。

理由は単純で、CI でのビルド確認が欠かせないからです。


{
  "description": "Do not automerge without CI",
  "matchUpdateTypes": ["minor", "patch", "digest"],
  "automerge": false
}

「CI による確認を通らない限り、自動マージさせない」というルールです。

特に Kotlin の minor アップデートでは内部 API が変わることもあり、
Compose Compiler や KSP が対応していない可能性があります。

PR を作成したあと CI を通し、問題なければ手動でマージする。

これが最も安全な流れです。

🧭 運用のヒントとまとめ

この設定は、いわば「Kotlin エコシステム用 Renovate セーフティモード」。

自動化の恩恵を受けつつも、壊れやすい依存を慎重に扱うための現実的な妥協点です。

項目	意図
`baseBranches`	更新PRを`develop`向けにして安全確認を確保
`groupName`	Kotlin / KSP / Compose Compiler を同時に更新
`automerge: false`	CI確認なしでの自動マージを防止
`matchPackagePrefixes` / `matchPackagePatterns`	最新の Compose 構成（Compose Multiplatform 等）に対応

🪶 まとめ：安全第一の Renovate 運用へ

Renovate は「ただの自動更新ボット」ではなく、
チームのアップデート戦略をコード化できるツールです。

Kotlin、KSP、Compose Compiler のような密接な関係を持つ依存こそ、
グルーピングとマージ制御で慎重に扱うべき対象。

develop ベースで CI を通すこの設定は、
自動化と安全性のバランスを取る最適解のひとつと言えます。

👉 Renovate Docs

【JetpackCompose】 Composable 関数の Modifier について知らなかった3つのルール

Last updated : 2023-10-30 20:03

detekt に指摘されながら、ドキュメントを読む。

【detekt / ktlint】元 Twitter 管理者 @mrmans0n らによって Jetpack Compose Rules フォークが進化している件 #プログラミング #kmm https://t.co/ToXFLbyXcR

— chanzmao (@maochanz) October 23, 2023

こんなコードがあったとして。


Column {
    InnerContent()
}

@Composable
private fun InnerContent() {
    Text(...)
    Image(...)
    Button(...)
}

以下、知らなかった流儀。

🧩 Composable 関数はレイアウトを一つだけ出力する

A composable function should emit either 0 or 1 pieces of layout, but no more. A composable function should be cohesive, and not rely on what function it is called from.

コンポーザブル関数は、レイアウトのピースを0個または1個だけ発行するべきで、それ以上は発行してはいけません。コンポーザブル関数は結束性を持ち、呼び出される関数に依存すべきではありません。

レイアウトのネストのコストはあまり気にしなくて良い、とのこと。

Nesting of layouts has a drastically lower cost vs the view system, so developers should not try to minimize UI layers at the cost of correctness.

レイアウトのネストには、ビューシステムに比べてはるかに低いコストがかかるため、UIの階層を正確性の犠牲にして最小化しようとしないべきです。

👉 Do not emit multiple pieces of content - Twitter Jetpack Compose Rules

ということで、一見不要に見える Column を追加する。


@Composable
private fun InnerContent() {
    Column {
        Text(...)
        Image(...)
        Button(...)
    }
}

🧩 デフォルトを持つパラメータ modifier: Nodifier = Modifier は必須

They are especially important for your public components, as they allow callers to customize the component to their wishes.

特に、公開コンポーネントにとって Modifier は非常に重要であり、呼び出し元がコンポーネントを希望に合わせてカスタマイズできるようにします。

👉 When should I expose modifier parameters? - Jetpack Compose Rules

Composables that accept a Modifier as a parameter to be applied to the whole component represented by the composable function should name the parameter modifier and assign the parameter a default value of Modifier.

Composable 関数内でコンポーザブル関数を表すコンポーネント全体に適用するための修飾子をパラメータとして受け入れる場合、そのパラメータは "modifier" という名前を付け、パラメータに Modifier のデフォルト値を割り当てるべきです。

👉 Modifiers should have default parameters - Jetpack Compose Rules

ということで、親からの Modifier を受け入れるようにします。デフォルト値もつけておきます。


@Composable
private fun InnerContent(modifier: Modifier = Modifier) {
    Column {
        Text(...)
        Image(...)
        Button(...)
    }
}

🧩 受け取った Modifier パラメータは最上位のレイアウトにのみ適用する

Modifiers should be applied once as a first modifier in the chain to the root-most layout in the component implementation. Since modifiers aim to modify the external behaviors and appearance of the component, they must be applied to the top-most layout and be the first modifiers in the hierarchy. It is allowed to chain other modifiers to the modifier passed as a param if needed.

Modifier は、コンポーネントの実装内でルートのレイアウトに最初の Modifier として一度適用すべきです。Modifier はコンポーネントの外部の動作や外観を変更することを目的としているため、最上位のレイアウトに適用し、階層内で最初の Modifier である必要があります。必要に応じて、パラメータとして渡された Modifier に他の Modifier を連鎖させることは許可されています。

👉 Modifiers should be used at the top-most layout of the component - Jetpack Compose Rules

ということで、最上位ルートの Column で適用します。


@Composable
private fun InnerContent(modifier: Modifier = Modifier) {
    Column(modifier = modifier) {
        Text(...)
        Image(...)
        Button(...)
    }
}