1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@yun_bow(ゆんぼう)in株式会社パーク

Groovy卒業！Android Gradle設定をKotlin DSL に移行する手順

Posted at

はじめに

こんにちは！Android開発をしている皆さん、Gradle の設定ファイルはまだ Groovy DSL（.gradle）を使っていませんか？

私も以前は「動いてるからいいや」と Groovy DSL をそのまま使い続けていたのですが、2025年現在、Kotlin DSL（.gradle.kts）がAndroid Studioの新規プロジェクトでデフォルトになっていることを知って、重い腰を上げて移行してみました。

結果から言うと、移行して本当に良かったです。今回は、その経験を踏まえて Android Gradle Kotlin DSL について詳しく解説していきます。

Kotlin DSL とは？

Kotlin DSL（Domain Specific Language）は、Gradle のビルドスクリプトを Kotlin で記述する方法です。

正直、最初は「また新しいこと覚えるのか...」と思っていたのですが、使ってみると従来の Groovy DSL と比べて、こんな利点がありました：

  • 型安全性：コンパイル時にエラーを検出可能（これが一番嬉しい！）
  • IDE サポート：優れたコード補完、リファクタリング機能
  • 可読性：Kotlin の構文でより読みやすいコード

特に型安全性については、Groovy DSL で「なんでエラーになるの？」と悩んでいた時間がかなり削減されました。

なぜKotlin DSLを使うべきか？

1. デフォルト化された選択肢

2023年4月のGradle 8.2以降、Kotlin DSL が新規 Gradle プロジェクトの推奨オプションとなりました。Android Studio Giraffe以降では、新規プロジェクト作成時にKotlin DSLがデフォルトで選択されます。

つまり、もう「試してみるか」という段階ではなく、標準として使われているということです。新しくプロジェクトを作る人は自動的にKotlin DSLを使うことになるので、我々既存プロジェクトの開発者も追従した方が良さそうです。

2. 開発体験の向上

Groovy DSL

android {
    compileSdkVersion 35
    defaultConfig {
        minSdkVersion 24
        targetSdkVersion 35
    }
}

Kotlin DSL

android {
    compileSdk = 35
    defaultConfig {
        minSdk = 24
        targetSdk = 35
    }
}

Kotlin DSL では、プロパティの型が明確で、IDEでの補完も効きます。これ、本当に便利です！

Groovy DSL の時は「あれ、この設定項目なんだっけ？」とググることが多かったのですが、Kotlin DSL だと IDE が教えてくれるので作業効率が上がりました。

  • compileSdk: アプリをビルドするために使用するAPIレベル
  • targetSdk: アプリの動作対象としてテストされたAPIレベル

3. 最新機能への対応

2025年現在、以下の機能がサポートされています：

  • Gradle Isolated Projects：大規模プロジェクトでのビルド高速化
  • カスタムGradle公開バリアント：マルチプラットフォームプロジェクト対応
  • バージョンカタログ：依存関係の一元管理

実際の移行方法

さて、ここからが本題です。実際に移行する手順を、私が実際にやった順番で説明していきます。

ステップ1：ファイル名の変更

まずは簡単なところから。ファイル名を変更します：

Groovy DSL

build.gradle
settings.gradle

Kotlin DSL

build.gradle.kts
settings.gradle.kts

これだけでも Android Studio が「お、Kotlin DSL に移行するのね」と認識してくれます。

ステップ2：基本的な構文の変更

ここからがちょっと面倒なところ。以下の変更が必要です：

プラグイン

apply plugin は、Groovyのプロジェクトに機能を追加するためにプラグインを適用する古い方法です。新しいプロジェクトでは、通常、plugins { id '...' } ブロックを使用することが推奨されています。

Groovy DSL

apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'

Kotlin DSL

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
}

Boolean プロパティ

Kotlin DSL では、boolean プロパティに is プレフィックスが必要です。

Groovy DSL

android {
    buildTypes {
        release {
            minifyEnabled false
        }
        debug {
            debuggable true
        }
    }
}

Kotlin DSL

buildTypes {
    getByName("release") {
        isMinifyEnabled = false
    }
    getByName("debug") {
        isDebuggable = true
    }
}

文字列設定

Groovyではメソッド呼び出しの () を省略してスペースで引数を渡すことができましたが、Kotlin DSLではプロパティへの代入に = 演算子を必ず使用します。

Groovy DSL

applicationId "com.example.app"

Kotlin DSL

applicationId = "com.example.app"

この辺りは、Kotlin を書いたことがある人なら「そりゃそうだ」って感じですね。逆に言えば、Kotlin の文法を知っていれば直感的に分かるのが Kotlin DSL の良いところです。

バージョンカタログの活用

ここで一つ、2025年のベストプラクティスとして知っておいて欲しい機能があります。libs.versions.toml ファイルを使用した依存関係の一元管理です。

実は、これを知らずに Kotlin DSL を使っても、そこまで劇的な改善は感じられないかもしれません。でも、バージョンカタログと組み合わせると、本当に管理が楽になります：

libs.versions.toml

[versions]
agp = "8.5.0"
kotlin = "2.0.0"
coreKtx = "1.13.1"
junit = "4.13.2"
junitVersion = "1.2.0"
espressoCore = "3.6.0"
lifecycleRuntimeKtx = "2.8.0"
activityCompose = "1.9.0"
composeBom = "2024.09.00"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }
junit = { group = "junit", name = "junit", version.ref = "junit" }
androidx-junit = { group = "androidx.test.ext", name = "junit", version.ref = "junitVersion" }
androidx-espresso-core = { group = "androidx.test.espresso", name = "espresso-core", version.ref = "espressoCore" }
androidx-lifecycle-runtime-ktx = { group = "androidx.lifecycle", name = "lifecycle-runtime-ktx", version.ref = "lifecycleRuntimeKtx" }
androidx-activity-compose = { group = "androidx.activity", name = "activity-compose", version.ref = "activityCompose" }
androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }

[plugins]
androidApplication = { id = "com.android.application", version.ref = "agp" }
jetbrainsKotlinAndroid = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }

build.gradle.kts での使用

plugins {
    alias(libs.plugins.androidApplication)
    alias(libs.plugins.jetbrainsKotlinAndroid)
}

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.lifecycle.runtime.ktx)
    implementation(libs.androidx.activity.compose)
    implementation(platform(libs.androidx.compose.bom))
    
    testImplementation(libs.junit)
    androidTestImplementation(libs.androidx.junit)
    androidTestImplementation(libs.androidx.espresso.core)
}

移行時のチェックリスト

  • ファイル名を .gradle から .gradle.kts に変更
  • プラグイン設定を plugins {} ブロックに移行
  • Boolean プロパティに is プレフィックスを追加
  • 文字列代入を = 演算子に変更
  • バージョンカタログの導入を検討
  • IDEでのシンタックスチェック確認

まとめ

Android Gradle Kotlin DSL への移行、いかがでしたでしょうか？

実は私も最初は「面倒そうだなあ」と思っていたのですが、実際にやってみると意外とすんなりできました。そして何より、移行後の開発体験が本当に良くなったんです。

特に：

  • IDE の補完が効くので設定項目で迷わない
  • 型エラーでコンパイル前に問題を発見できる
  • バージョンカタログと組み合わせる、と依存関係の管理が楽

といった点で、日々の開発が楽になりました。

Android Gradle Kotlin DSL は、もはや「試してみる」段階を超えて、2025年の標準的な選択肢となっています。新規プロジェクトではもちろん、既存プロジェクトも段階的に移行を進めていくことをおすすめします。

皆さんも、ぜひKotlin DSLを試してみてください！最初はちょっと戸惑うかもしれませんが、きっと「移行して良かった」と思えるはずです。

参考資料

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?