Why are updates to Kotlin, Compose, and KSP such a hassle?

In Android development, you're constantly dealing with the same set of three: Kotlin, the Compose Compiler, and KSP.

They seem like a friendly group, but their update schedules are always completely different! You upgrade Kotlin, and the Compose Compiler isn't compatible. You change something, and KSP throws a build error because of an internal API change...

To better manage this "dependency triangle" situation, the main idea is to use Renovate's configuration to treat them as a single unit. The simple plan is: "Raise all Kotlin ecosystem dependencies at the same time!"

 

🧑🏻‍💻 Brief overview of the renovate.json file


{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:base",
    "group:all",
    ":dependencyDashboard",
    "schedule:daily"
  ],
  "baseBranches": ["main"],
  "commitMessageExtra": "{{{currentValue}}} to {{#if isPinDigest}}{{{newDigestShort}}}{{else}}{{#if isMajor}}{{prettyNewMajor}}{{else}}{{#if isSingleVersion}}{{prettyNewVersion}}{{else}}{{#if newValue}}{{{newValue}}}{{else}}{{{newDigestShort}}}{{/if}}{{/if}}{{/if}}{{/if}}",
  "packageRules": [
    {
      "matchPackagePatterns": ["androidx.compose.compiler:compiler"],
      "groupName": "kotlin"
    },
    {
      "matchPackagePatterns": ["org.jetbrains.kotlin.*"],
      "groupName": "kotlin"
    },
    {
      "matchPackagePatterns": ["com.google.devtools.ksp"],
      "groupName": "kotlin"
    }
  ]
}

👉 architecture-samples/renovate.json at main · android/architecture-samples

Roughly summarized, here are the key points:

  • groupName: "kotlin" to bundle dependencies This setting specifies that the three elements—the Compose Compiler, Kotlin, and KSP—should be treated as belonging to the "same group." This allows Renovate to update them all together at once.
  • schedule: daily for a calm update pace This checks for updates once a day. You'll receive pull requests (PRs) on a daily basis, preventing a huge influx of dependency updates all at once, which makes things much easier to manage.
  • commitMessageExtra to see changes at a glance The version difference, like "2.0.10 → 2.0.20," is automatically added to the PR title. It's a small tweak, but surprisingly useful.

Setting up your configuration this way significantly reduces the tragedy of "Kotlin got updated, but Compose broke..."

 

🧑🏻‍💻 What We Found While Using It

Once this setup is in place, you can feel much more confident testing updates for everything Kotlin-related. Renovate diligently checks daily, automatically creating a PR whenever a new version drops.

But there's one small warning:

The Compose Compiler sometimes takes a little extra time to catch up to the latest Kotlin version. So, don't just merge the PR when you see it—it's highly recommended to verify the CI status first.

KSP is similar; because it depends on Kotlin's internal workings, it's safer to update it along with Kotlin and run your tests together.

 

🧑🏻‍💻 Summary: Teach Renovate that "These Three Are a Set"

The configuration we discussed treats the trio of Kotlin, the Compose Compiler, and KSP as a single group.

  • Bundle all Kotlin-related dependencies for simultaneous updates.
  • Check for updates at a manageable daily pace.
  • See version differences directly in the PR title.

Just implementing this significantly reduces the problems caused by versions getting out of sync and breaking your build.

💡 Key Takeaway: Use Renovate less as an "automatic update tool" and more as a "dependency rulebook."

We simply need to tell Kotlin, Compose, and KSP to cooperate and "work together."

👉 Kotlin・Compose・KSP の更新、どうしてこんなに面倒なの?


“Install Error(-10)” Got You Stuck? The Hidden Trick to Beat Google Play’s Pre-launch Test

 

🤔 Why the “App Not Owned” Error Happens

If your app fails the Google Play Pre-launch Test with this scary message —

u9.a: -10: Install Error(-10): The app is not owned by any user on this device.
An app is "owned" if it has been acquired from Play.

— you’re not alone.

This happens because the Pre-launch Test runs on Google’s own test devices, which aren’t linked to your Play account or purchase history.
So, if your app uses Play Core libraries (like AppUpdateManager or AppReviewManager), the “ownership check” fails, and your app never even gets installed.

It’s one of those bugs that make you scream: “But it works fine on my phone!” 😩

 

🤔 The Secret Fix Google Never Told You

Here’s the insider trick that devs have quietly been using:


Settings.System.getString(context.contentResolver, "firebase.test.lab")

This line reveals whether your app is currently running inside Firebase Test Lab — the same environment used for Pre-launch Tests.
If the value is "true", you’re in a test device.
That means you can safely skip anything that requires Play services or user ownership checks.

Here’s how to use it:


val isTestLab = Settings.System.getString(context.contentResolver, "firebase.test.lab") == "true"
if (!isTestLab) {
    // Run Play Core logic only in real user environments
}

Boom. 💣
No more random -10 install errors.
Your Pre-launch Test will finally pass like a charm.

 

⚡ Summary

The “Install Error(-10)” is not a bug in your code — it’s a Play Console quirk.
By detecting the Test Lab environment with:


Settings.System.getString(context.contentResolver, "firebase.test.lab")

you can bypass Play-related ownership checks and let your app install smoothly during the Pre-launch Test.

A single line of code could be the difference between “Test failed 🚫” and “Release ready ✅” — now that’s a win worth sharing.

👉 Firebase Test Lab × リリース前レポート環境を見分けるKotlin実装


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 のライフサイクル完全図解 🚀


Android Studio で Gemini と AI Assistant プラグインを使い、「自動生成された英語のコミットメッセージ」を日本語化する

本記事は、Android Studio 上で Gemini(モデル)と AI Assistant(プラグイン)を併用し、AI によって自動作成された英語のコミットメッセージを、チーム規約に沿った自然な日本語へ変換する実践手順をまとめたものです。

英語での自動草案は便利ですが、そのままだと意図やニュアンスが伝わりにくいことがあります。

ここでは「英語の自動生成を起点に、短い操作で日本語化」「テンプレ化して常に日本語で提案」の二段構えで対処します。

 

🧑🏻‍💻 Gemini:Prompt Library を編集し、「常に日本語で提案」されるようテンプレ化

毎回 “Translate to Japanese.” を書くのが手間なら、Gemini のプロンプトテンプレートに翻訳指示を埋め込み、英語で自動生成されるコミットでも出力は日本語に統一します。

手順

1. Android Studio の


設定 → Tools → Gemini → Prompt Library

2. Scope を IDE に設定
3. 以下を選択


Built-in Actions → 「Commit Message Generation」

4. プロンプト本文の末尾に次を追加して保存


Translate to Japanese.

効果

・ コミット時の提案が常に日本語で出力され、英語の自動草案を逐一翻訳する手間がなくなる
・ チームで設定を共有すれば、言語運用と文体の統一が容易
・ 既定の変数($SAMPLE_COMMIT_MESSAGES, $COMMIT_DIFF など)はそのまま活用可能

よりニュアンスを保ちたい場合は、翻訳行を次に差し替えるのも有効です。


Translate to natural Japanese, preserving engineering nuance and concision. Keep Conventional Commits types in English and code identifiers as-is.

 

🧑🏻‍💻 AI Assistant:英語の自動草案を、コミット直前に即座に日本語化

最短のワークフローは、コミットダイアログ右側の「AI Assistant」で英語の自動生成メッセージに対し、1 行の指示を追加して日本語化する方法です。

手順

1. コミットダイアログを開く
2. 右ペイン「AI Assistant」の「Prompt for generation」に次を追記する:


Translate to Japanese.

3. 生成結果をタイトル・本文に反映してコミット
4. 必要に応じて「Run advanced checks after a commit is done」を有効化し、生成後の検査を自動実行

ポイント

・ 自動生成の英語タイトル(例: feat: Add comments to MainViewModel)を、短く自然な日本語に置換
・ Conventional Commits の型(feat, fix など)は英字のまま保持し、意味合いは本文で補足
・ 冗長化を避ける既定ルールが効いて、端的な日本語に収まりやすい

英語の自動草案は背景を省きがちです。本文で「〜のため」を 1 行だけ補って理由を明示すると、レビュー時の誤解を減らせます。

 

🧑🏻‍💻 まとめ

・ Android Studio で Gemini と AI Assistant を併用すれば、AI が自動生成した英語のコミットメッセージを、短い操作で自然な日本語に変換できる
・ すぐ使うなら AI Assistant のプロンプトに “Translate to Japanese.” を追加
・ 恒久化するなら Gemini の Prompt Library で翻訳指示をテンプレ化
・ 運用の合言葉は「型は英字・サブジェクトは日本語・本文で背景と影響」。英語の自動草案の不足分は、日本語本文で補いましょう。