Identifying the "4 JDKs" in Android Studio: From Launcher JVM to Toolchain

Have you ever encountered a situation where your build passes in the terminal but fails in the IDE? Or perhaps you updated Java on your system, but Android Studio seems to ignore it ?

The root cause often lies in the fact that Android Studio manages four different JDKs depending on the specific task. Confusing these can lead to "mysterious" environment issues. In this guide, we will identify each one and show you how to pinpoint them in your own environment.

 

🤔 Why You Need to Know the "4 JDKs"

Android Studio separates the processes that run the IDE, manage the build, and compile your source code. If these refer to different JDKs, you may run into compatibility glitches.

Let’s identify the "true identity" of each.

 

🤔 1. Launcher JVM (The Terminal/Entry Point)

Role: This is the JVM that initially kicks off when you run the ./gradlew script. It acts as the "starter" to wake up the heavy-lifting Gradle Daemon.

How to Identify: Run the following command in your terminal:


❯ ./gradlew -v            

------------------------------------------------------------
Gradle 9.3.1
------------------------------------------------------------

Build time:    2026-01-29 14:15:01 UTC
Revision:      44f4e8d3122ee6e7cbf5a248d7e20b4ca666bda3

Kotlin:        2.2.21
Groovy:        4.0.29
Ant:           Apache Ant(TM) version 1.10.15 compiled on August 25 2024
Launcher JVM:  21.0.10 (Eclipse Adoptium 21.0.10+7-LTS)
Daemon JVM:    Compatible with Java 21, JetBrains, nativeImageCapable=false (from gradle/gradle-daemon-jvm.properties)
OS:            Mac OS X 26.3 aarch64

Look for the line labeled Launcher JVM.

Dependent on: Your OS environment variables, specifically JAVA_HOME or your PATH setting.

 

🤔 2. Daemon JVM (The Build Engine)

Role: This is the "workhorse" JVM that actually performs the heavy lifting—compiling code and packaging your APK/AAB. It stays resident in memory to speed up subsequent builds.

How to Identify: Check the project-level configuration file:
gradle/gradle-daemon-jvm.properties


toolchain.vendor=JetBrains
toolchain.version=21

You can also see this in the ./gradlew -v output under Daemon JVM.

Dependent on: Gradle 8.8+ project settings.

 

🤔 3. IDE JDK (The Android Studio Runtime)

Role: This JVM runs the Android Studio application itself. It handles the editor UI, code completion (indexing), and IDE plugins.

How to Identify:
Mac: Android Studio > About Android Studio

Dependent on: The jbr folder bundled within your Android Studio installation directory.

 

🤔 4. Java Toolchain (The Compilation Target)

Role: This setting strictly defines which Java version should be used to compile your source code. It ensures that everyone on a team uses the exact same Java version for the final binary, regardless of their local IDE settings.

How to Identify: Check your app/build.gradle.kts (or build.gradle):


// build.gradle.kts

java {
  toolchain {
    languageVersion = JavaLanguageVersion.of(21)
  }
}


// build.gradle.kts

with(javaToolchains.compilerFor(java.toolchain).get().metadata) {
  logger.lifecycle("Compiler JVM: $vendor $languageVersion ($jvmVersion)")
  logger.lifecycle("$installationPath")
}

// Output:
// Compiler JVM: JetBrains 21 (21.0.10+7-b1163.108)
// /Users/jake/.gradle/jdks/jetbrains_s_r_o_-21-aarch64-os_x.2/jbrsdk_jcef-21.0.10-osx-aarch64-b1163.108/Contents/Home

Note: If this is not explicitly set, the Daemon JVM usually handles the compilation tasks by default.

 

🤔 Summary: Identification Checklist

Use this table as a quick reference to audit your development environment:

Final Thought
Even if your Launcher JVM is "Eclipse Adoptium" while your Daemon JVM is "JetBrains Runtime," your project will generally work fine as long as the major versions (e.g., Java 21) match.


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は理解に基づいたコード生成・設計提案を行い、開発効率と品質を大幅に向上させられます。


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 で翻訳指示をテンプレ化
・ 運用の合言葉は「型は英字・サブジェクトは日本語・本文で背景と影響」。英語の自動草案の不足分は、日本語本文で補いましょう。