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

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.

IDE × AIモデル別：プロンプトに食わせるべきファイルまとめ

主要IDEごとに、連携AI・推奨ファイル・目的・補足を整理した表です。プログラミング中心にまとめています。

1. 基本のセット

  • プロジェクト概要・設計
    README.md, architecture.md
    AIに全体像・設計方針・責務を理解させる
  • 依存・環境情報
    build.gradle(.kts), package.json, Podfile, .env.example
    SDK・ライブラリ・環境変数を正確に認識させる
  • コーディング方針・ルール
    .prompt.yaml, .copilot-instructions.md, .editorconfig
    命名規則、禁止API、コードスタイルを統一

2. IDE × AIモデル別の推奨ファイルと効果

IDE 推奨AIモデル 重点ファイル 効果 補足
Android Studio / IntelliJ Gemini Code Assist, Copilot .prompt.yaml, build.gradle, architecture.md Androidプロジェクト全体を理解した補完・設計提案 プロジェクト全体の構造を解析可能。方針ファイルで安定化。
Xcode Copilot, GPT-5 .prompt.yaml, Package.swift, README.md SwiftUI/MVVM設計に沿った正確なコード生成 Xcodeは依存解析が弱めなので .prompt.yaml を明示すると効果大。
VS Code Copilot Chat, GPT-5 .copilot-instructions.md, package.json, README.md 軽量環境で多言語対応、チーム開発の方針共有に有効 拡張機能単位でAI切替可能。指示ファイルが最重要。
Cursor / Windsurf / Aider GPT-5 / Claude 3.5 / Gemini 1.5 .prompt.yaml / .cursorconfig, README.md, architecture.md, build設定 設計・生成・リファクタを自動で分担 ファイル単位でAIが文脈キャッシュを保持。設計書参照可。
Jupyter / DataSpell / VSCode + Python GPT-4 Turbo, Gemini Advanced .ipynb / .csv / .xlsx, analysis.md / README.md, .prompt.yaml データ解析・統計・グラフ生成 データ＋分析目的＋出力形式を渡すと的確に解析可能。
Figma / Webflow / Framer Gemini 1.5 Pro (Vision), GPT-5 Vision .fig / .svg / layout.json, style_reference.jpg, .prompt.yaml UIデザイン→コード変換・スタイル抽出 構図＋目的＋出力フォーマット指定でSwiftUIやComposeコード化が容易。

3. 実務での運用Tips

  • サンプルコードを渡す
    /sample_code に小さな動作例を置くと、AIが文体やパターンを模倣しやすい
  • 変更履歴を渡す
    CHANGELOG.md や feature_list.md を読むことで、過去の修正意図を理解し、安全な提案が可能
  • 大きなファイルは要約して渡す
    設計書や長文ドキュメントは、AIの文脈理解の負荷を減らすために必要部分だけ渡す
  • 依存関係やAPI仕様は明示
    未定義関数や古いAPIの誤提案を防ぐため、build.gradle や .env.example を食わせる

4. まとめ

プログラミングAIを「単なるコード補完」ではなく、プロジェクト理解型のアシスタントとして活用するには、

「概要 + 環境 + 方針」をAIに与えることが最も重要です。

  • IDEや言語に合わせたファイルを食わせる
  • 設計方針と依存関係を明確化する
  • サンプルコードや履歴で文脈を補完する

この3ステップで、AIは理解に基づいたコード生成・設計提案を行い、開発効率と品質を大幅に向上させられます。