Android用Gradleをマスターする：GradleタスクとKotlin

ビデオ: AndroidGradleプラグインKotlinバージョン1.3.0の修正

コンテンツ

Gradleビルドファイルの探索
1. settings.gradle
2. build.gradle（プロジェクトレベル）
3. build.gradle（モジュールレベル）
プロジェクトの依存関係の宣言：ローカルライブラリ
ビルド依存関係の追加：リモートリポジトリ
リモートリポジトリへの接続
リモート依存関係の宣言
複数のAPKの生成：ビルドバリアントの作成方法
カスタムGradleタスクの作成
Gradleラッパーを使用してプロジェクトを構築する
他にどのGradleタスクが利用可能ですか？
Gradleをさらに活用する：プラグインを追加する
Gradle Kotlin DSL
まとめ

Java、XML、またはKotlinの代わりに、これらのGradleビルドファイルはGroovyベースのドメイン固有言語（DSL）を使用します。 Groovyに慣れていない場合は、これらの各Gradleビルドファイルを1行ずつ見ていきます。したがって、この記事の終わりまでに、簡単なGroovyコードの読み書きに慣れるでしょう。

Gradleは、最小限の手動設定でよく使用できるデフォルト設定を提供することで、あなたの生活を楽にすることを目指しています。プロジェクトをビルドする準備ができたら、Android Studioの「実行」ボタンを押すと、Gradleがビルドプロセスを開始しますあなたのために。

Gradleの「構成よりも慣習的な」アプローチにも関わらず、デフォルト設定がニーズを十分に満たしていない場合、ビルドプロセスをカスタマイズ、構成、拡張し、Gradle設定を微調整して特定のタスクを実行できます。

Gradleスクリプトは独自のファイルに含まれているため、アプリケーションのソースコードに触れることなく、いつでもアプリケーションのビルドプロセスを変更できます。このチュートリアルでは、フレーバー、ビルドバリアント、カスタムGradleタスクを使用してビルドプロセスを変更します。 今まで アプリケーションコードに触れます。

Gradleビルドファイルの探索

プロジェクトを作成するたびに、Android Studioは同じコレクションのGradleビルドファイルを生成します。既存のプロジェクトをAndroid Studioにインポートしても、まだこれらのまったく同じGradleファイルを作成し、プロジェクトに追加します。

GradleとGroovy構文の理解を深めるために、Androidの各Gradleビルドファイルを1行ずつ見ていきましょう。

1. settings.gradle

settings.gradleファイルでは、「include」キーワードを使用して、アプリケーションのすべてのモジュールを名前で定義します。たとえば、「app」と「secondModule」で構成されるプロジェクトがある場合、settings.gradleファイルは次のようになります。

include：app、：secondmodule rootProject.name = MyProject

プロジェクトのサイズによっては、このファイルはかなり長くなる場合があります。

ビルドプロセス中に、Gradleはプロジェクトのsettings.gradleファイルの内容を調べ、ビルドプロセスに含める必要があるすべてのモジュールを識別します。

2. build.gradle（プロジェクトレベル）

プロジェクトレベルのbuild.gradleファイルはプロジェクトのルートディレクトリにあり、適用される設定が含まれています すべて モジュール（Gradleでは「プロジェクト」とも呼ばれます）。

このファイルを使用して、Androidプロジェクト全体のすべてのモジュールに適用されるプラグイン、リポジトリ、依存関係、構成オプションを定義する必要があります。プロジェクトレベルのbuild.gradleファイル内でGradleタスクを定義する場合、対応するモジュールを編集することにより、個々のモジュールのこれらのタスクをオーバーライドまたは拡張することができます。 モジュールレベル build.gradleファイル。

典型的なプロジェクトレベルのbuild.gradleファイルは次のようになります。

buildscript {リポジトリ{google（）jcenter（）}依存関係{classpath com.android.tools.build:gradle:3.5.0-alpha06 //注：ここにアプリケーションの依存関係を置かないでください。それらは//個々のモジュールbuild.gradleファイルに属します}} allprojects {リポジトリ{google（）jcenter（）}} task clean（type：Delete）{delete rootProject.buildDir}

このプロジェクトレベルのbuild.gradleファイルは、次のブロックに分かれています。

Buildscript。 これには、ビルドの実行に必要な設定が含まれます。
リポジトリ。 Gradleは、プロジェクトの依存関係を特定し、ビルドで使用できるようにする責任があります。ただし、すべての依存関係が同じリポジトリに由来するわけではないため、プロジェクトの依存関係を取得するには、Gradleが検索するすべてのリポジトリを定義する必要があります。
依存関係。 このセクションには、プラグインの依存関係が含まれており、ダウンロードされてローカルキャッシュに保存されます。あなたがすべき じゃない このブロック内でモジュールの依存関係を定義します。
すべてのプロジェクト。 ここで、利用可能なリポジトリを定義します すべて プロジェクトのモジュールの。

3. build.gradle（モジュールレベル）

これはモジュールレベルのbuild.gradleファイルで、プロジェクト全体のすべてのモジュールに存在します。 Androidプロジェクトが複数のモジュールで構成されている場合、複数のモジュールレベルのbuild.gradleファイルでも構成されます。

各モジュールレベルのbuild.gradleファイルには、プロジェクトのパッケージ名、バージョン名、バージョンコードに加えて、この特定のモジュールの最小およびターゲットSDKが含まれています。

モジュールレベルのbuild.gradleファイルには、固有のビルド命令と依存関係のセットを含めることもできます。たとえば、Wear OSコンポーネントを使用してアプリケーションを作成する場合、Android Studioプロジェクトは、個別のスマートフォン/タブレットモジュールとWearモジュールで構成されます。これらはまったく異なるデバイスを対象としているため、これらのモジュールは依存関係！

基本的なモジュールレベルのbuild.gradleファイルは通常、次のようになります。

プラグインの適用：com.android.application android {compileSdkVersion 28 defaultConfig {applicationId "com.jessicathornsby.speechtotext" minSdkVersion 23 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"} buildTypes {release {minifyEnabled false proguardFiles getDefaultProguardFile（proguard-android-optimize.txt）、proguard-rules.pro}}}依存関係{implementation fileTree（dir：libs、include：）implementation androidx.appcompat：appcompat：1.0.2 implementation androidx.constraintlayout：constraintlayout：1.1。 3 testImplementation junit：junit：4.12 androidTestImplementation androidx.test.ext：junit：1.1.0 androidTestImplementation androidx.test.espresso：espresso-core：3.1.1}

これらの各セクションを詳しく見てみましょう。

プラグインを適用します。 これは、このモジュールをビルドするために必要なプラグインのリストです。 com.android.applicationプラグインは、Android固有のビルドプロセスをセットアップするために必要なので、これは自動的に追加されます。
アンドロイド。 これは、モジュールのプラットフォーム固有のオプションをすべて配置する場所です。
compileSdkVersion。 これは、このモジュールがコンパイルされるAPIレベルです。この値を超えるAPIの機能は使用できません。
buildToolsVersion。 これは、コンパイラのバージョンを示します。 Gradle 3.0.0以降では、buildToolsVersionはオプションです。 buildToolsVersion値を指定しない場合、Android Studioはデフォルトでビルドツールの最新バージョンになります。
defaultConfig。 これには、デバッグビルドやリリースビルドなど、アプリのすべてのビルドバージョンに適用されるオプションが含まれています。
アプリケーションID。 これはアプリケーションの一意の識別子です。
minSdkVersion。 このパラメーターは、このモジュールがサポートする最低のAPIレベルを定義します。
targetSdkVersion。 これは、アプリケーションがテストされた最大のAPIレベルです。理想的には、最新のAPIを使用してアプリケーションをテストする必要があります。つまり、targetSdkVersion値は常にcompileSdkVersion値に等しくなります。
versionCode。 これは、アプリケーションのバージョンの数値です。
versionName。 これはユーザーフレンドリーな文字列で、アプリケーションのバージョンを表します。
buildTypes。 デフォルトでは、Androidはデバッグとリリースの2つのビルドタイプをサポートしています。「デバッグ」ブロックと「リリース」ブロックを使用して、アプリケーションのタイプ固有の設定を指定できます。
依存関係。 ここで、このモジュールが依存するライブラリを定義します。

プロジェクトの依存関係の宣言：ローカルライブラリ

1つ以上のプロジェクトの依存関係を追加することにより、Androidプロジェクトで追加の機能を使用可能にすることができます。これらの依存関係はローカルにすることも、リモートリポジトリに保存することもできます。

ローカルJARファイルへの依存関係を宣言するには、そのJARをプロジェクトの「libs」ディレクトリに追加する必要があります。

その後、モジュールレベルのbuild.gradleファイルを変更して、このファイルへの依存関係を宣言できます。たとえば、ここでは「mylibrary」JARへの依存関係を宣言しています。

実装ファイル（libs / mylibrary.jar）

あるいは、「libs」フォルダーに複数のJARが含まれている場合、プロジェクトが「libs」フォルダー内にあるすべてのファイルに依存していることを簡単に説明する方が簡単な場合があります。次に例を示します。

実装fileTree（dir：libs、include：）

ビルド依存関係の追加：リモートリポジトリ

ライブラリがリモートリポジトリにある場合は、次の手順を完了する必要があります。

この依存関係があるリポジトリを定義します。
個々の依存関係を宣言します。

リモートリポジトリへの接続

最初のステップは、プロジェクトのすべての依存関係を取得するために、チェックする必要のあるリポジトリ（またはリポジトリ）をGradleに伝えることです。例えば：

リポジトリ{google（）jcenter（）}}

ここで、「jcenter（）」行により、GradleはJCenterリポジトリをチェックします。JCenterリポジトリは、bintrayでホストされる無料の公開リポジトリです。

または、あなたまたはあなたの組織が個人リポジトリを保持している場合、このリポジトリのURLを依存関係宣言に追加する必要があります。リポジトリがパスワードで保護されている場合は、ログイン情報も提供する必要があります。例：

リポジトリ{mavenCentral（）maven {//ターゲットURLの構成// url "http://repo.mycompany.com/myprivaterepo"} maven {credentials {username myUsername password myPassword} url "http://repo.mycompany.com / myprivaterepo "}

依存関係が複数のリポジトリ内に存在する場合、Gradleは各リポジトリの古さや静的バージョンなどの要因に基づいて、この依存関係の「最適な」バージョンを選択します。

リモート依存関係の宣言

次のステップは、モジュールレベルのbuild.gradleファイルで依存関係を宣言することです。次のいずれかを使用して、この情報を「依存関係」ブロックに追加します。

実装。 これは、プロジェクトをビルドするときに常に必要な通常の依存関係です。「実装」依存関係が存在します すべて あなたのビルド。
テスト実装。 これは、アプリケーションのテストソースをコンパイルし、JVMベースのテストを実行するために必要な依存関係です。依存関係を「Testimplementation」としてマークすると、Gradleは通常のビルド中にこの依存関係のタスクを実行する必要がないことを認識し、ビルド時間の短縮に役立ちます。
Androidtestimplementation。 これは、デバイスでテストを実行するときに必要な依存関係です。たとえば、Espressoフレームワークは一般的な「Androidtestimplementation」です。

上記のキーワードのいずれかを使用してリモート依存関係を定義し、その後に依存関係のグループ、名前、およびバージョン属性を続けます。次に例を示します。

依存関係{実装fileTree（dir：libs、include：）実装androidx.appcompat：appcompat：1.0.2実装androidx.constraintlayout：constraintlayout：1.1.3 testImplementation junit：junit：4.12 androidTestImplementation androidx.test.ext：junit：1.1.0 androidTestImplementation androidx.test.espresso：espresso-core：3.1.1}

複数のAPKの生成：ビルドバリアントの作成方法

場合によっては、アプリケーションの複数のバージョンを作成する必要があります。たとえば、いくつかの追加機能を含む無料版と有料版をリリースしたい場合があります。

これはGradleが支援できるビルドタスクなので、ビルドプロセスを変更して、単一のプロジェクトから複数のAPKを作成する方法を見てみましょう。

strings.xmlファイルを開き、元のアプリケーション名の文字列を削除します。
次に、作成する各製品フレーバーの名前を定義します。この例では、私は使用しています：

私の無料アプリ有料アプリ

AndroidManifest.xmlファイルを開き、android：label =” @ string / app_name”を次のように置き換えます。

android：label = "$ {appName}"

モジュールレベルのbuild.gradleファイルを開き、「android」ブロックに次を追加します。

flavorDimensions "mode" productFlavors {free {ディメンション "mode" applicationIdSuffix ".free" manifestPlaceholders =}有料{ディメンション "mode" applicationIdSuffix ".paid" manifestPlaceholders =}}}

ここで何が起こっているかを分析しましょう：

flavorDimensions。 Androidプラグインは、異なる次元のフレーバーを組み合わせてビルドバリアントを作成します。ここでは、アプリの「無料」バージョンと「有料」バージョンで構成されるフレーバーディメンションを作成しています。上記のコードに基づいて、Gradleは、payedDebug、paidRelease、freeDebug、およびfreeReleaseの4つのビルドバリアントを生成します。
productFlavors。 これは、上記のコードでは「有料」と「無料」であるフレーバーとその設定のリストを指定します。
無料/有料。 これらは、2つの製品フレーバーの名前です。
寸法。 「dimension」パラメーター値を指定する必要があります。この例では、「モード」を使用しています。
applicationIdSuffix。 アプリの複数のバージョンを作成するため、各APKに一意のアプリ識別子を指定する必要があります。
manifestPlaceholders。 各プロジェクトには、プロジェクトの構成に関する重要な情報を含む単一のマニフェストファイルがあります。複数のビルドバリアントを作成する場合、通常、これらのマニフェストプロパティの一部をビルド時に変更します。 Gradleビルドファイルを使用して、ビルドバリアントごとに一意のマニフェストエントリを指定し、ビルド時にマニフェストに挿入できます。上記のコードでは、Gradleがアプリの無料版と有料版のどちらを構築しているかに応じて、「appName」の値を変更しています。

カスタムGradleタスクの作成

Gradleを使用してビルドプロセスをカスタマイズする必要がある場合があります タスク.

タスクは、Javadocの生成など、ビルドを実行するときにGradleが実行する名前付きアクションのコレクションです。 Gradleはデフォルトで多くのタスクをサポートしていますが、カスタムタスクを作成することもできます。これは、非常に具体的なビルド手順のセットを念頭に置いている場合に便利です。

このセクションでは、プロジェクトのすべてのビルドバリアント（paidDebug、paidRelease、freeDebug、およびfreeRelease）を反復処理するカスタムGradleタスクを作成し、日時スタンプを作成して、生成された各APKにこの情報を追加します。

モジュールレベルのbuild.gradleファイルを開き、次を追加します。

task addDateAndTime（）{//すべての出力ビルドバリアントを反復処理// android.applicationVariants.all {バリアント-> //すべてのAPKファイルを反復処理// variant.outputs.all {出力-> //のインスタンスを作成指定された形式の現在の日付// def dateAndTime = new Date（）。format（ "yyyy-MM-dd：HH-mm"）//この情報をAPKのファイル名に追加// def fileName = variant name + "_" + dateAndTime + ".apk" output.outputFileName = fileName}}}

次に、Gradleに伝える必要がありますいつこのタスクを実行する必要があります。ビルド中に、Gradleはダウンロードに必要なすべてのものと実行する必要があるすべてのタスクを識別し、それらをDirected Acyclic Graph（DAG）に配置します。その後、Gradleは、DAGで定義された順序に従って、これらすべてのタスクを実行します。

私のアプリでは、「whenReady」メソッドを使用します。これにより、DAGにデータが入力されるとタスクが呼び出され、Gradleがタスクの実行を開始できるようになります。

次をモジュールレベルのbuild.gradleファイルに追加します。

//このタスクを実行します// gradle.taskGraph.whenReady {addDateAndTime}

カスタムタスクを配置しましょう そして Gradleコマンドを使用してこのプロジェクトをビルドし、テスト用のビルドバリアントコードを作成します。

Gradleラッパーを使用してプロジェクトを構築する

Gradleラッパー（「gradlew」）を使用してGradleコマンドを発行します。このスクリプトは、Gradleのバージョンからビルドの実行を独立させるため、Gradleビルドを開始する好ましい方法です。この分離は、必ずしも同じバージョンのGradleがインストールされているとは限らない可能性がある他のユーザーと共同作業する場合に役立ちます。

Gradleラッパーコマンドを発行する場合、macOSを含むUnixライクなオペレーティングシステムには「gradlew」を、Windowsには「gradlew.bat」を使用します。私はMacを持っているので、「gradlew」コマンドを使用します。

Android Studio内からGradleコマンドを発行できます。

Android Studioツールバーで、[表示]> [ツールウィンドウ]> [ターミナル]を選択します。これにより、IDEウィンドウの下部にターミナルパネルが開きます。
ターミナルに次のコマンドを入力します。

./gradlew build

Android Studioは次のようになります。

キーボードの「Enter」キーを押します。 Gradleがプロジェクトをビルドします。

Gradleは生成されたすべてのAPKをプロジェクトのapp / build / outputs / apkディレクトリに保存するため、このディレクトリに移動します。「APK」フォルダーには、いくつかのフォルダーとサブフォルダーが含まれている必要があります。 GradleがビルドバリアントごとにAPKを生成し、正しい日付と時刻の情報が各ファイルに追加されていることを確認してください。

他にどのGradleタスクが利用可能ですか？

作成する可能性のあるカスタムタスクに加えて、Gradleは、すぐに使用できる定義済みタスクのリストをサポートしています。使用可能なタスクを正確に確認したい場合：

まだ開いていない場合は、Android Studioのターミナルウィンドウを開きます（Android Studioツールバーから[表示]> [ツールウィンドウ]> [ターミナル]を選択）。
ターミナルに次を入力します。

./gradlew -qタスク

キーボードの「Enter」キーを押します。

この「タスク」タスクが実行され、しばらくすると、ターミナルにこのプロジェクトで使用可能なすべてのタスクのリストが表示され、各タスクの簡単な説明が表示されます。

Gradleをさらに活用する：プラグインを追加する

Gradleには多くのプラグインがプリインストールされていますが、新しいプラグインを追加してGradleをさらに拡張できます。これらのプラグインは、Androidプロジェクトで新しいタスクを使用できるようにします。たとえば、Javaプラグインには、Javaソースコードのコンパイル、単体テストの実行、「compileJava」、「compileText」、「jar」などのJARファイルの作成を可能にするタスクが含まれます「javadoc」および「clean」。

プラグインを適用するには、「apply plugin」宣言をモジュールレベルのbuild.gradleファイルに追加し、その後にプラグインの名前を追加します。たとえば、ここではJavaプラグインを適用しています。

プラグインの適用：java

どのプラグインが利用可能かを知りたい場合は、Gradleプラグインの包括的なレジストリを提供するGradleプラグイン検索をご覧ください。

Gradle Kotlin DSL

デフォルトでは、Groovy DSLを使用してGradleビルドスクリプトを記述しますが、Android開発にKotlinを採用した多くの開発者の1人であれば、代わりにKotlinでビルドスクリプトを記述することをお勧めします。

Groovyとは異なり、Kotlinは静的に型指定されたプログラミング言語であるため、切り替えを行うと、ビルドファイルはAndroid Studioのオートコンプリートおよびソースコードナビゲーション機能と互換性があります。さらに、GroovyからKotlinに移行すると、プロジェクト全体で同じプログラミング言語を使用することになり、特にGroovyにあまり慣れていない場合は、開発がより簡単になります。

Kotlinでビルドロジックの記述を開始する場合は、Gradle Kotlin DSLをセットアップし、移行ガイドの指示に従う必要があります。

まとめ

この記事では、Android Studioのビルド自動化および依存関係管理ツールについて説明しました。 Gradleがすぐにビルドプロセスを自動化する方法と、カスタムGradleタスクの作成、単一プロジェクトからの複数のビルドバリアントの生成など、プロジェクトのGradleビルドファイルを編集してビルドプロセスを変更する方法を検討しました。

Androidビルドプロセスの他の部分を自動化するためにGradleを拡張しましたか？以下のコメントでお知らせください！