Building Your Project with Gradle (翻訳)

投稿日 2014/09/10
更新日 2017/05/11
著者 kawamoto
カテゴリースマートフォン

Android StudioのBuilding Your Project with Gradleの翻訳が見当たりませんでしたので、翻訳しました。

Gradleを使用してプロジェクトをビルドする

Android Studio のビルドシステムは、ビルド、テスト、アプリを実行するツールキットです。このビルドシステムは、Android Studioとは独立していますので、Android Studio やコマンドラインから使用することができます。アプリケーションを作成した後、ビルドシステムの以下の特徴を使用できます。

ビルドのプロセスを、カスタマイズし、設定し、拡張できます。
同じプロジェクトで異なる機能を持った複数APKを作成することができます。
コードやリソースを再利用することができます。

Android Studioのビルドシステムの柔軟性は、アプリのコアプロジェクトファイルを変更せずに、これら全てを実現することが出来ます。

ビルドシステムの概要

Android StudioのビルドシステムはGradleのAndroidプラグインから構成されています。Gradleは、高度なビルドツールキットで、依存関係の管理や、ビルドロジックをカスタムすることができます。多くのソフトウェアプロジェクトは、ビルドを管理するためにGradleを使っています。Android StudioはGradleのAndroidプラグインを統合していますが、Android Studioに依存していません。これは以下を意味します。

CIサーバのようなAndroid Studioがインストールされていないマシン上で、コマンドラインからアプリをビルドすることができます。
コマンドラインからビルドする時のように、同じカスタムビルド設定を持つAndroid Studioからアプリをビルドすることができます。

ビルドの出力結果は、コマンドラインからビルドや、リモートマシン上のビルド、Android Studioを使用したビルドのどの場合でも同じです。

ビルド構成

プロジェクトのビルド構成はGradleビルドファイル内で定義されます。これは、ビルドの以下の点を設定するための、GradleやAndroidプラグインの構文やオプションを使うプレーンなテキストファイルです。

ビルドバリアント. ビルドシステムは、同一プロジェクトに対して、異なる設定を持った複数のAPKを生成することが出来ます。これは、異なるバージョンのアプリケーションをビルドしたい場合に、別々のプロジェクトにわけてビルドするようなことはする必要ありません。
依存関係. このビルドシステムは、プロジェクトの依存関係を管理し、ローカルファイルからやリモートリポジトリからの依存関係をサポートします。これにより、依存関係で必要なバイナリパッケージを検索して、ダウンロードして、自分のプロジェクトにコピーしたりする必要がなくなります。
マニフェストエントリ. このビルドシステムでは、マニフェストファイルのいくつかの要素の値を、ビルド構成ファイルで指定すること出来ます。ビルド設定ファイルで指定された値は、マニフェストファイルに書かれている値を上書きします。プロジェクトに対して、パッケージ名や、minimum SDKバージョン、target SDKバージョンが異なる複数のAPKを作成したい場合に役にたちます。
署名. ビルド構成ファイル内で署名の設定を書くことができ、ビルド時に署名することができます。
ProGuard. ビルドシステムは、各ビルドバリアント毎に異なるProGuardルールファイルを指定することが出来ます。ビルド時にクラスを難読化するためのProGuardを実行することが出来ます。
テスト. このビルドシステムは、プロジェクトにあるテストソースからテストAPKを作りますので、テストプロジェクトとして分けて作る必要ありません。ビルドプロセス中にテストを実行することが出来ます。

Gradleのビルドファイルは、Groovyの構文を使用しています。Groovyは、カスタムビルドロジックを定義するためや、GradleのAndroidプラグインによって提供されるAndroid固有の要素を使うことができる動的プログラミング言語です。

慣例によるビルド

Android Studioのビルドシステムは、プロジェクト構成やその他ビルドオプションに対して、気が利くデフォルト設定を想定しています。もし、プロジェクトがこれらの慣習に従ってるなら、Gradleのビルドファイルは、とてもシンプルとなります。これらの慣習をプロジェクトに適用しない時は、ビルドシステムの柔軟性により、ビルドプロセスのほぼすべての側面を構成することができます。例えば、プロジェクトのソースがデフォルト以外のディレクトリに格納されている場合、このビルドファイルの場所を指定することができます。

プロジェクトとモジュール

Android Studioでのプロジェクトは、ひとつのAndroidアプリケーションです。Android Studio プロジェクトは、1つか、2つ以上のモジュールから構成されます。モジュールとは、ビルドやテスト、デバッグができる独立しているアプリケーションのコンポーネントです。モジュールには、アプリのためのソースコードとリソースが含まれます。Android Studioプロジェクトは、3種類のモジュールを含みます。

Javaライブラリモジュールは再利用可能なコードを含んでいます。ビルドシステムは、javaライブラリモジュールに対してJARパッケージを生成します。
Androidライブラリモジュールは、再利用可能なAndroid 固有のコードとリソースを含んでいます。ビルドシステムは、ライブラリモジュールに対して、AAR（Android ARchive）を生成します。
Androidアプリケーションモジュールは、多くのAndroid アプリケーションは、1つのアプリケーションモジュールのみから構成されていますが、アプリケーションコードを含んでいて、ライブラリモジュールに依存するかもしれません。ビルドシステムは、アプリケーションモジュールのAPKパッケージを生成します。

Android Studioプロジェクトは、トップレベルのGradleは、プロジェクト内のすべてのモジュールがリストされたビルドファイルが含まれており、各モジュールは、各モジュールのGradleのビルドファイルが含まれています。

依存関係

Android Studio のビルドシステムは、プロジェクトの依存関係を管理し、モジュール依存関係、ローカルバイナリ依存関係、リモートバイナリ依存関係をサポートします。

モジュール依存関係

プロジェクトのモジュールは、モジュールに依存する他のモジュールを含める事ができます。このモジュールをビルドする時、必要なモジュールを含めます。

ローカル依存関係

ローカルに、モジュールに依存するJARファイルのようなバイナリアーカイブがある場合、そのモジュールに対して、ビルドファイル内に依存関係を宣言できます。

リモート依存関係

依存関係がリモートリポジトリで利用可能な時、それらをダウンロードしてプロジェクトにコピーするする必要ありません。Android Studioのビルドシステムは、リモートのMaven依存関係をサポートしています。Mavenは、リポジトリを使ってプロジェクトの依存関係を整理するのを助ける一般的なソフトウェアプロジェクト管理ツールです。多くの一般的なソフトウェアライブラリとツールが、公開Mavenリポジトリで利用可能です。これらの依存関係に対して、リモートリポジトリを識別するMaven座標を指定する必要があるだけです。ビルドシステムで使われるMaven座標のフォーマットは、group:name:version です。例えば、Google Guavaライブラリのバージョン16.0.1のMaven座標は、com.google.guava:guava:16.0.1 となります。

Mavenセントラルリポジトリは、多くのライブラリやツールを配布するために広く使われています。

ビルドタスク

Android Studioビルドシステムは、ビルドタスクの階層的な集まりを定義します。トップレベルのタスクは、それらが必要な結果を作ることに関係するタスクを呼び出します。ビルドシステムは、アプリをビルドするためのプロジェクトタスクと、モジュールを単独でビルドするモジュールタスクを提供しています。

利用可能なタスク一覧を確認することができ、Build the project in Android StudioとBuild the project from the command lineで説明しているように、Android Studioからやコマンドラインから任意のタスクを呼び出すことが出来ます。

Gradleラッパー

Android Studioプロジェクトは、以下の構成からなるGradleラッパーを梱包しています。

JARファイル
プロパティファイル
Windowsプラットフォーム用シェルスクリプト
MacおよびLinuxプラットフォーム用シェルスクリプト

メモ：バージョン管理システムにこれらのすべてのファイルをコミットしておいた方が良いです。

（ローカルにGradleをインストールする代わりに）Gradleラッパーを使うと、いつもプロパティファイルで定義されたGradleのバージョンを実行することを保証します。Gradleの新しいバージョンを使うためにプロジェクトを設定するためには、プロパティファイルを編集し、そこに新しいバージョンを指定します。

Android Studioは、プロジェクト内のGradleラッパーのあるディレクトリからプロパティファイルを読み込みますので、Gradleの異なるバージョンを必要とする複数のプロジェクトでシームレスに作業することができます。

注：Android Studioは、シェルスクリプトを使用していないため、IDEからビルドするときに、シェルスクリプトに加えた変更は動作しません。その代わりGradleのビルドファイル内にカスタム·ロジックを定義すべきです。

開発マシン上やAndroid Studioがインストールされていない他のマシン上で、コマンドラインからプロジェクトをビルドするためのシェルスクリプトを実行することができます。

Android Studioプロジェクトを作成し、ビルドする

このセクションでは、上記の概念に基づいて構築し、次の方法を説明します。

プロジェクトとモジュールの作成方法
プロジェクト構造
ビルドプロセスを構成するビルドファイルの編集方法
アプリをビルドして実行する方法

Android Studioでプロジェクトを作成する

Android Studioで新しいプロジェクトを作成するには：

File をクリックし、 New Project を選択します。
表示されるウィンドウで、アプリケーション名フィールドに「BuildSystemExample」と入力します。
残りの項目はそのままにしてNextをクリックします。
アイコン設定もデフォルトのままNextをクリックします。
Blank Activityを選択しNextをクリックします。
アクティビティやレイアウト名はそのままにしてFinishをクリックします。

図1は、Android Studioウィンドウが、プロジェクトを作成した後にどのように見えるかを示しています。

図1. アプリのプレビュー

プロジェクト構造

Android Studioプロジェクトには、デフォルトで、アプリケーション·モジュール(app)が含まれています。アプリの主な構成要素が、このモジュール内のどこに配置されているかを表1に示します。

表1 アプリケーションモジュール内のコンポーネントのデフォルトの場所

コンポーネント	ロケーション
ソースファイル	`app/src/main/java/<package>/`
リソースファイル	`app/src/main/res/`
マニフェストファイル	`app/src/main/AndroidManifest.xml`
ビルドファイル	`app/build.gradle`

プロジェクトに追加モジュールを追加すると、各モジュールのディレクトリ構造が表1で示されるのと同じように、appをそのモジュール名で置き換えられたものになります。

ライブラリモジュールを追加する

このセクションでは、プロジェクトにライブラリモジュールを追加する方法と、アプリケーション·モジュールの依存関係として、ライブラリを追加する方法を示します。

新しいライブラリモジュールを作成する

ライブラリモジュール内の他のアプリで再利用可能性があることは、グループ機能に優れた開発方法です。BuildSystemExampleプロジェクト内部でライブラリモジュールを作成するには：

Fileをクリックし、 New Moduleを選択します。
表示されるウィンドウでAndroid Libraryを選択しNextをクリックします。
デフォルトのモジュール名(lib)はそのまま変更せずNextをクリックします。
Blank Activityを選択しNextをクリックします。
Activity Nameフィールドに「LibActivity1」と入力しFinishをクリックします。

プロジェクトには現在、各モジュールに1つのアクティビティを持っている２つのモジュール(appとlib)があります。

ライブラリモジュールからのアクティビティをオープンする

ライブラリモジュールは、1つまたは複数のアプリケーションモジュールが再利用するアクティビティや他のロジックを含んでいます。この例では、appモジュールにあるMainActivityが、libモジュールからLibActivity1をオープンします。LibActivity1からMainActivityをオープンするには：

appモジュールにあるMainActivityのレイアウトファイルを編集します。このファイルは、app/src/main/res/layout/activity_main.xml にあります。以下にこのファイルの内容を置き換えます。

&lt;LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.buildsystemexample.app.MainActivity"&gt;

    &lt;Button
        android:id="@+id/button1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/button1"
        android:onClick="onButton1Clicked"/&gt;

&lt;/LinearLayout&gt;

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

tools:context="com.buildsystemexample.app.MainActivity">

<Button

android:id="@+id/button1"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="@string/button1"

android:onClick="onButton1Clicked"/>

</LinearLayout>

このレイアウトファイルで、android:text="@string/button1"の行をクリックしAlt+Enterを押します。Android Studioからの提案に従って、strings.xmlリソースに「Open LibActivity1」として追加します。
このレイアウトファイルで、android:onClick="onButton1Clicked"の行をクリックしAlt+Enterを押します。Android Studioからの提案に従って、MainActivityにonButton1Clickedメソッドを追加します。
MainActivityにあるonButton1Clickedのメソッド内に次のコードをコピーします。

public void onButton1Clicked(View view) { Intent intent = new Intent(this, LibActivity1.class); startActivity(intent); }

1
2
3
4

public void onButton1Clicked(View view) {
Intent intent = new Intent(this, LibActivity1.class);
startActivity(intent);
}
MainActivityのonButton1Clickedメソッドの１行目にあるLibActivity1をクリックして、Alt+Enterを押します。Android Studioからの提案に従って、libモジュールからLibActivity1をインポートして追加します。(訳者注: 「BuildSystemExample」のルートディレクトリにあるsetting.gradleに”:lib”が追加されます)

ユーザーがMainActivityにあるOpen LibActivity1ボタンをタップすると（appモジュールから）、 LibActivity1が（libモジュールから）起動するようにします。

ライブラリモジュールの依存関係を追加する

appモジュールは今、libモジュールに依存していますが、ビルドシステムはまだこのことを知りません。appモジュールのビルドファイル（ app/build.gradle ）を編集し、libモジュールの依存関係を追加します：

...
dependencies {
    ...
    compile project(":lib")
}

...

dependencies {

...

compile project(":lib")

}

libモジュールは独立してビルドとテストができ、ビルドシステムは、他のプロジェクトでも再利用可能なAARパッケージを作成することができます。

Android Studioでプロジェクトをビルドする

Android Studioでプロジェクトをビルドするには、BuildをクリックしMake Projectを選択してください。ウィンドウ下部にあるステータスバーに、ビルドの現在の進行状況が表示されます。

Gradle: Executing tasks: [:app:assembleDebug, :lib:bundleDebug]

プロジェクトがプロダクト・フレーバーを使用している場合は、Android Studioは、選択したビルドバリアントのタスクを実行します。詳細については、ビルドバリアントとの連携を参照してください。

Gradleコンソールを表示するために、図2に示すように、ウィンドウの右下部分にあるをクリックしてください。

図2. Android StudioのGradleコンソール

Gradleコンソールは、ビルドシステムがAndroid Studioで実行するビルドタスクとサブタスクを示しています。ビルドが失敗した場合は、コンソール上で詳細を確認することができます。Gradleコンソールを非表示にするには、をもう一度クリックします。

Android Studioで利用可能なビルドタスクの一覧を表示するには、IDEウィンドウの右側にあるGradleをクリックします。図3に示すようにGradle tasksパネルが表示されます。Android Studioでタスクを実行するには、ビルドタスクをダブルクリックします。Gradle tasksパネルを非表示にするには、もう一度Gradleをクリックします。

図3. Android Studioのビルドタスク一覧

コマンドラインからプロジェクトをビルドする

コマンドラインからプロジェクトをビルドするには、ターミナルウィンドウを開き、プロジェクトルートに移動します。Windowsプラットフォームでは、次のコマンドを実行します。

&gt; gradlew.bat assembleDebug

1	> gradlew.bat assembleDebug

Mac OSおよびLinuxプラットフォームでは、次のコマンドを実行します。

$ chmod +x gradlew
$ ./gradlew assembleDebug

1 2	$ chmod +x gradlew $ ./gradlew assembleDebug

最初のコマンド（ chmod ）は、Gradleのラッパースクリプトに実行権限を追加します。コマンドラインからプロジェクトをビルドするために初回のみ必要です。

gradlewの出力結果は、図2のGradleコンソールの出力結果と同様です

assembleDebugビルドタスクは、appのdebugバージョンをビルドし、デフォルトのローカル証明書を使って署名しますので、エミュレータや実機にデバッグのためにインストールすることが出来ます。

プロジェクトをビルドした後、アプリのモジュールのAPKは app/build/apk/ に出力されます。またlibモジュールのAARは lib/build/libs/ に出力されます。

プロジェクトの利用可能なすべてのビルドタスク一覧を表示するには、次のコマンドを入力します。

$ ./gradlew tasks

1	$ ./gradlew tasks

リリースバージョンをビルドする

コマンドラインからやAndroid Studioを使って、アプリケーションのリリースバージョンをビルドすることができます。コマンドラインからビルドするには、Gradleラッパースクリプトを使ってassembleReleaseを実行します（gradlew assembleRelease）。Android Studioからビルドするには、次のようにします。

IDEウィンドウの右側にあるGradleをクリックします。
表示されるサイドバーのAll tasksセクションでBuildSystemExampleを展開します。
:appを展開してassembleReleaseをダブルクリックします。

Android Studioから任意のビルドタスクを実行するには、この手順が使えます。

ビルド構成

このセクションでは、前のセクションからのBuildSystemExampleプロジェクト使用し、次の方法を説明しています。

ビルドファイルのGradleのAndroidプラグインから構文の使い方
依存関係の宣言方法
ProGuardの設定方法
署名の設定方法
ビルドバリアンとの連携方法

ビルドファイルの基本

Android Studioプロジェクトには、最上位のビルドファイルおよびモジュール毎にビルドファイルが含まれています。build.gradleと呼ばれるビルドファイルで、Groovy構文を使ったプレーンなテキストファイルです。これは、GradleのAndroidプラグインを使ってビルドを設定します。ほとんどのケースでは、モジュールレベルのビルドファイルを編集すればよいはずです。例えば、BuildSystemExampleプロジェクトのappモジュールのビルドファイルは次のようになります。

apply plugin: 'android'

android {
    compileSdkVersion 19
    buildToolsVersion "19.0.0"

    defaultConfig {
        minSdkVersion 8
        targetSdkVersion 19
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            runProguard true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), \
            'proguard-rules.txt'
        }
    }
}

dependencies {
    compile project(":lib")
    compile 'com.android.support:appcompat-v7:19.0.1'
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

apply plugin: 'android'

android {

compileSdkVersion 19

buildToolsVersion "19.0.0"

defaultConfig {

minSdkVersion 8

targetSdkVersion 19

versionCode 1

versionName "1.0"

}

buildTypes {

release {

runProguard true

proguardFiles getDefaultProguardFile('proguard-android.txt'), \

'proguard-rules.txt'

}

dependencies {

compile project(":lib")

compile 'com.android.support:appcompat-v7:19.0.1'

compile fileTree(dir: 'libs', include: ['*.jar'])

}

apply plugin: 'android'の部分は、このビルドではGradleのAndroidプラグインを適用するということを意味しています。最上位のビルドタスクにAndroid固有のビルドタスクを追加し、android {...}でAndroid固有のビルドオプションを指定することができるようになります。

android {...}では、すべてのAndroid固有のビルドオプションを設定します。

compileSdkVersionプロパティは、コンパイルターゲットを指定します。
buildToolsVersionプロパティは、使用するビルドツールのバージョンを指定します。ビルドツールの各バージョンをインストールするには、SDKマネージャを使用します。
注：常に、メジャーリビジョンの番号が高いか、コンパイルターゲットやターゲットSDKのバージョンと等しいビルドツールのバージョンを使用します。
defaultConfig要素は、ビルドシステムから動的にマニフェストファイル（AndroidManifest.xml）内のコア設定および入力値を設定します。defaultConfigに書かれた値は、マニフェストファイルよりも優先されます。defaultConfig要素で指定された設定は、ビルドバリアントの設定で値を上書きしない限り、すべてのビルドバリアントに適用されます。
buildTypes要素は、アプリケーションのビルドの仕方と、パッケージ化の仕方をコントロールします。デフォルトでは、このビルドシステムは2つのビルドタイプ debugとreleaseを定義しています。debugビルドタイプは、デバッグシンボルが含まれており、デバッグキーで署名されています。releaseビルドタイプは、デフォルトで署名されていません。上記のビルドファイルの例では、ProGuardのを使用するreleaseバージョンを設定しています。

dependencies要素は、android要素の外側で、android要素の後にあります。この要素は、モジュールの依存関係を宣言します。依存関係については、次のセクションで説明します。

注：プロジェクト内のビルドファイルに変更を加えると、Android Studioは、ビルド構成の変更をインポートするためにプロジェクトの同期を必要とします。変更をインポートするために、Android Studioに現れる黄色の通知バーのSync Nowをクリックしてください。

図4. Android Studioでプロジェクトを同期

依存関係を宣言する

BuildSystemExampleのappモジュールは3つ依存関係を宣言しています。

...
dependencies {
    // Module dependency
    compile project(":lib")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:19.0.1'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

...

dependencies {

// Module dependency

compile project(":lib")

// Remote binary dependency

compile 'com.android.support:appcompat-v7:19.0.1'

// Local binary dependency

compile fileTree(dir: 'libs', include: ['*.jar'])

}

これらのそれぞれの依存関係については、以下に説明します。ビルドシステムは、コンパイルするクラスパスにcompile依存関係を追加し、最終的なパッケージにそれらが含まれます。

モジュール依存関係

appモジュールはlibモジュールに依存します。理由は、ライブラリモジュールからアクティビティをオープンするで説明したように、MainActivityはLibActivity1を起動するからです。

compile project(":lib")は、BuildSystemExampleのlibモジュールに依存していることを宣言します。appモジュールをビルドするとき、ビルドシステムはlibモジュールを含めます。

リモートバイナリ依存関係

appとlibモジュールの両方とも、Android Support LibraryからActionBarActivityクラスを使用しますので、これらのモジュールは、Android Support Libraryに依存します。

compile 'com.android.support:appcompat-v7:19.0.1'は、Maven座標を指定することで、Android Support Libraryのバージョン19.0.1に依存していることを宣言します。Android Support Libraryは、Android SDKのAndroid Repositoryパッケージで提供されています。このパッケージを持っていない場合は、SDKマネージャを使用してそれをダウンロードしてインストールしてください。

Android Studioは、デフォルトではMavenセントラルリポジトリを使用するようにプロジェクトを構成しています。（この設定は、プロジェクトの最上位のビルドファイルに書かれています。）

ローカルバイナリ依存関係

BuildSystemExampleにあるモジュールは、ローカルファイルの任意のバイナリの依存関係を使用していません。ローカルのバイナリの依存関係を必要とするモジュールがある場合は、依存関係のあるJARファイルを、プロジェクト内の<moduleName>/libsにコピーします。

compile fileTree(dir: 'libs', include: ['*.jar'])はビルドシステムに伝えています。app/libs内にある任意のJARファイルが依存関係にあり、クラスパスと最終的なパッケージに含まれるようになります。

Gradleの依存関係の詳細については、Gradleユーザガイドの依存関係管理の基本を参照ください。

ProGuardを実行する

ビルド時にクラスを難読化するためにProGuardを実行することが出来ます。BuildSystemExampleでは、appモジュールのビルドファイルを修正し、リリースビルドのProGuardを実行します。

...
android {
    ...
    buildTypes {
        release {
            runProguard true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), \
                          'proguard-rules.txt'
        }
    }
}
...

...

android {

...

buildTypes {

release {

runProguard true

proguardFiles getDefaultProguardFile('proguard-android.txt'), \

'proguard-rules.txt'

}

...

getDefaultProguardFile('proguard-android.txt')は、Android SDKのインストールからデフォルトのProGuard設定を取得します。Android Studioは、モジュール固有のルールファイルproguard-rules.txtをモジュールのルートディレクトリに追加しています。ProGuardルールをカスタムすることができます。

署名の設定

appのdebugとrelaseバージョンでは、アプリケーションが安全なデバイス上か、どうやってAPKが署名されるかデバッグされるかによって異なります。ビルドシステムは、ビルド時にパスワードプロンプトを回避するために、既知の資格情報を使用して、デフォルトのキーと証明書を使用して、debugバージョンに署名します。明示的にビルドファイルに署名設定を定義しない限り、ビルドシステムはreleaseバージョンでは署名されません。

BuildSystemExampleのreleaseバージョンで署名できるようにするには：

releaseキーをappモジュールのルートディレクトリ（app/）にコピーするこれは、自分のプロジェクトの場所を移動する時や別のマシン上でプロジェクトをビルドする時に、ビルドシステムがキーを見つけることを確実にします。releaseキーを持っていない場合、アプリケーションを署名するで説明したように、キーを生成することができます。

appモジュールのビルドファイルに署名設定を追加する：

...
android {
    ...
    defaultConfig { ... }
    signingConfigs {
        release {
            storeFile file("myreleasekey.keystore")
            storePassword "password"
            keyAlias "MyReleaseKey"
            keyPassword "password"
        }
    }
    buildTypes {
        release {
            ...
            signingConfig signingConfigs.release
        }
    }
}
...

...

android {

...

defaultConfig { ... }

signingConfigs {

release {

storeFile file("myreleasekey.keystore")

storePassword "password"

keyAlias "MyReleaseKey"

keyPassword "password"

}

buildTypes {

release {

...

signingConfig signingConfigs.release

}

...

Android StudioまたはコマンドラインからassembleReleaseビルドタスクを実行します。

これで、app/build/apk/app-release.apkパッケージは、releaseキーで署名されました。

注：ビルドファイルにreleaseキーとキーストアのパスワードを書くことは、セキュリティ上良い方法ではありません。別の方法として、環境変数からパスワードを取得するようにビルドファイルを構成したり、ビルド時にパスワードの入力を求めることができます。

環境変数からパスワードを取得するには、下記のように記述します。

storePassword System.getenv("KSTOREPWD")
keyPassword System.getenv("KEYPWD")

1 2	storePassword System.getenv("KSTOREPWD") keyPassword System.getenv("KEYPWD")

コマンドラインからビルドする場合、ビルド時にパスワードの入力を求めるようにするには、下記のように記述します。

storePassword System.console().readLine("
Keystore password: ")
keyPassword System.console().readLIne("
Key password: ")

storePassword System.console().readLine("

Keystore password: ")

keyPassword System.console().readLIne("

Key password: ")

ビルドバリアントとの連携

このセクションでは、一つのプロジェクトから、同じアプリケーションの異なるバージョンを作成するにはどのようにすれば良いかを説明します。この機能は、アプリのデモ版や有料版を作りたい時や、Google Play上で異なるデバイスの複数のAPKのを配布したい場合に有効です。

ビルドシステムは、アプリケーションの異なるバージョンを作成するためにプロダクト・フレーバーという仕組みを使います。アプリの各バージョンには、異なる機能やデバイスの要件を持たせるができます。ビルドシステムは、アプリケーションのバージョン毎に異なるAPKを生成します。

ビルドバリアント

アプリの各バージョンは、ビルドシステムではビルドバリアントによって表現されます。ビルドバリアントは、ビルドタイプとプロダクト・フレーバー構成の組み合わせです。Android Studioプロジェクトは、デフォルトで2つのビルドタイプ（ debugとrelease ）を定義していて、プロダクト・フレーバーは定義していません。つまり、Android Studioプロジェクトは、2つのビルドバリアント(debugとrelease)で構成されており、ビルドシステムはそれぞれのAPKを生成します。

このセクションの演習では、2つのプロダクト・フレーバー demoとfullを定義し、4つのビルドバリアントを生成します。

demo-debug
demo-release
full-debug
full-release

この場合、ビルドシステムはこれらのビルドバリアント1つずつに対する4つのAPKを作成します。

プロジェクトによっては、複数の次元に沿った特徴の複雑な組み合わせを持っていますが、それらは同じアプリを表します。たとえば、demoやfullバージョンに加えて、いくつかのゲームは、特定のCPU / ABI固有のバイナリを含んでいるかもしれません。ビルドシステムの柔軟性により、そのようなプロジェクトのための以下のビルドバリアントを生成することが可能です。

x86-demo-debug
x86-demo-release
x86-full-debug
x86-full-release
arm-demo-debug
arm-demo-release
arm-full-debug
arm-full-release
mips-demo-debug
mips-demo-release
mips-full-debug
mips-full-release

このプロジェクトは、2つのビルドタイプ（ debugとrelease ）とプロダクト・フレーバーの２つのディメンジョン 、つまり、アプリの種類（demoまたはfull）の1つと、CPU / ABI（x86、ARM、MIPS）の1つ、から構成されています。フレーバー・ディメンジョンに関する詳細については、 Gradleのプラグインユーザガイドを参照ください。

ソースディレクトリ

アプリの各バージョンを構築するには、ビルドシステムは以下からソースコードとリソースを結合します。

src/main/ – mainのソースディレクトリ（すべての変数に共通）
src/<buildType>/ -ビルドタイプのソースディレクトリ
src/<flavorName>/ – フレーバーのソースディレクトリ

ビルドで使用されるフレーバーのソースディレクトリの数は、プロジェクトのフレーバー構成によって異なります。

フレーバーを定義していないプロジェクトの場合、ビルドシステムはフレーバーのソースディレクトリを使用しません。例えば、フレーバーがないプロジェクトでrelease ビルドバリアントを作成するために、ビルドシステムは以下を使用します。
- src/main/
- src/release/ （ビルドタイプ）
フレーバーのセットを定義するプロジェクトの場合、ビルドシステムは1つのフレーバーのソースディレクトリを使用します。たとえば、このセクションの例ではfull-debug ビルドバリアントを作成するために、ビルドシステムは以下を使用します。
- src/main/
- src/debug/ (ビルドタイプ)
- src/full/ (フレーバー)
フレーバー・ディメンジョンを使うプロジェクトの場合、ビルドシステムは、ディメンジョンごとに1つのフレーバーのソースディレクトリを使います。たとえば、前の例のarm-demo-release ビルドバリアントを生成するために、ビルドシステムは以下を使います。
- src/main/
- src/release/ (ビルドタイプ)
- src/demo/ (フレーバー – app type dimension)
- src/arm/ (フレーバー – ABI dimension)

注：ビルドタイプとフレーバーソースディレクトリはオプションであり、Android Studioはこれらのディレクトリを作成しません。それらのディレクトリが存在しない場合は、ビルドシステムはビルドタイプやフレーバーを使用しません。

これらのディレクトリにあるソースコードが、ビルドバリアント用に出力、生成するために一緒に使用されます。これらのディレクトリは同じ変数で一緒に使用されない限り、別々のディレクトリに同じ名前のクラスを持つことができます。このセクションの演習は、さまざまなビルドバリアントの同じアクティビティクラスの異なるバージョンを作成する方法を説明します。

ビルドシステムは、１つのマニフェストにすべてのマニフェストをマージするので、その各ビルドバリアントは、異なるコンポーネントや最終的なマニフェストにある権限を定義することができます。

ビルドシステムは、すべてのソースディレクトリからすべてのリソースをマージします。異なるフォルダに、ビルドバリアントの同じ名前のリソースが含まれている場合、優先順位は以下の通りでです。ビルドタイプのリソースは、プロダクト・フレーバーから上書きし、メインのソースディレクトリ内のリソースを上書きします。

注：ビルドバリアントは、アプリケーションの異なるバージョン間で共通のアクティビティ、アプリケーションロジック、およびリソースを再利用することができるようにします。

BuildSystemExampleでのプロダクト・フレーバー

アプリの異なるバージョンを作成するには：

ビルドファイルで、プロダクト・フレーバーを定義します。
それぞれのフレーバー用の追加のソースディレクトリを作成します。
プロジェクトにアジフレーバー固有のソースを追加します。

このセクションの残りの部分は、BuildSystemExampleプロジェクトを使って詳細にこれらの手順を説明します。BuildSystemExampleアプリの2つのフレーバー、demoフレーバーとfullフレーバーを作成します。両方のフレーバーは、MainActivityを共有します。このアクティビティは、新しいアクティビティ SecondActivity を起動するためのボタンが１つある状態です。この新しいアクティビティは、各フレーバーごとに異なりますので、新しいアクティビティがdemoフレーバーよりもfullフレーバーの方が多くの機能を持っている状況をシミュレーションします。練習の終わりには、各フレーバーの2つの異なるAPKがあることを確認して終わります。

ビルドファイルに、プロダクト・フレーバーを定義する

2つのプロダクト・フレーバーを定義するには、appモジュールのビルドファイルを編集し、以下の設定を追加します。

...
android {
    ...
    defaultConfig { ... }
    signingConfigs { ... }
    buildTypes { ... }
    productFlavors {
        demo {
            applicationId "com.buildsystemexample.app.demo"
            versionName "1.0-demo"
        }
        full {
            applicationId "com.buildsystemexample.app.full"
            versionName "1.0-full"
        }
    }
}
...

...

android {

...

defaultConfig { ... }

signingConfigs { ... }

buildTypes { ... }

productFlavors {

demo {

applicationId "com.buildsystemexample.app.demo"

versionName "1.0-demo"

}

full {

applicationId "com.buildsystemexample.app.full"

versionName "1.0-full"

}

...

プロダクト・フレーバーの定義は、defaultConfig要素のようなプロパティをサポートしています。すべてのフレーバーの基本構成は、defaultConfigで指定され、各フレーバーの設定で、任意の値を上書きすることができます。上記のビルドファイルは、各フレーバーに異なるパッケージ名を割り当てるために、applicationIdプロパティを使用しています。各フレーバーは異なるアプリを作成するので、それぞれ個別のパッケージ名が必要です。

注：Google PlayでのMultiple APK Support 使用してアプリケーションを配布するには、すべての変数に同じパッケージ名を割り当て、変数毎に異なるversionCodeを割り当てます。Google Playで別のアプリとして、さまざまな異なるアプリを配布するには、各アプリに異なるパッケージ名を割り当てます。

各フレーバーのソースディレクトリを追加する

ソースフォルダを作成し、各フレーバーにSecondActivityを追加します。demoフレーバー用のソースディレクトリ構造を作成するには：

プロジェクトパネルで、BuildSystemExampleを展開しappディレクトリを展開します。
app配下にあるsrcディレクトリを右クリックし New > Directoryを選択します。
新しいディレクトリの名前として「demo」と入力しOKクリックします。
同様に、以下のディレクトリを作成します。
- app/src/demo/java
- app/src/demo/res
- app/src/demo/res/layout
- app/src/demo/res/values

その結果、ディレクトリ構造は、図5のようになります。

図5. demoフレーバー用の新しいソースディレクトリ

各フレーバーに新しいアクティビティを追加する

demoフレーバーにSecondActivityを追加する：

プロジェクトパネルで、appモジュールを右クリックし、New > Activity を選択します。
Blank Activityを選択しNextをクリックします。
アクティビティ名として「SecondActivity」と入力します。
パッケージ名として「com.buildsystemexample.app」と入力し Finish をクリックします。
app/src/demo配下のjavaディレクトリを右クリックし、 New > Package を選択します。
パッケージ名として「com.buildsystemexample.app」を入力しOKクリックします。
SecondActivityをドラッグして、 app/src/demo/javaにある新しいパッケージ配下にドロップします。
デフォルト値をそのまま使用し、 Refactorをクリックします。

demoフレーバー用のSecondActivityのレイアウトと、stringsリソースを追加するには：

app/src/main/res/layout から app/src/demo/res/layout の中にactivity_second.xmlをドラッグ＆ドロップします。
表示されるウィンドウでデフォルト値をそのまま使用してOKをクリックします。
app/src/main/resからapp/src/demo/resへstrings.xmlをコピーします。
新しくコピーしたstrings.xmlの内容を以下に置き換えます：

<?xml version="1.0" encoding="utf-8"?> <resources> <string name="hello_world">Demo version only.</string> </resources>

1
2
3
4

<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="hello_world">Demo version only.</string>
</resources>

demoフレーバーのコピーを作ることで、fullフレーバーを作ります。

プロジェクトパネルで、app/src配下のdemoディレクトリを右クリックしCopyを選択します。
app/ 配下 src/ ディレクトリを右クリックし、Pasteを選択します。
表示されたウィンドウで、新しい名前として「full」と入力しOKをクリックします。

src/full/res/value配下のstrings.xmlの内容を次で置き換えます。

&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;resources&gt;
    &lt;string name="hello_world"&gt;This is the full version!&lt;/string&gt;
&lt;/resources&gt;

<?xml version="1.0" encoding="utf-8"?>

<string name="hello_world">This is the full version!</string>

</resources>

注：ここから先は、それぞれフレーバー内で独立してSecondActivityを開発することができます。fullフレーバーでは、このアクティビティに多くの機能を追加することができます。

特定のフレーバーからファイルを操作するには、図6に示すように、IDEウィンドウの左側にあるBuild VariantsをクリックしBuild Variantsパネルで変更するフレーバーを選択します。Android Studioは、Build Variantsパネルで選択したもの以外のフレーバーから、ソースファイル内のエラーが表示される場合がありますが、これは、ビルドの結果には影響しません。

図6. Build Variantsパネル

mainアクティビティからフレーバー固有のアクティビティを起動する

フレーバー固有のアクティビティ(SecondActivity)は、両方フレーバーで同じパッケージ名とアクティビティ名を持っているので、すべてのフレーバーに共通しているMainActivityから起動することができます。MainActivityを変更するには：

activity_main.xmlを編集して、MainActivityに新しいボタンを追加します：

&lt;LinearLayout ...&gt;
    ...
    &lt;Button
        android:id="@+id/button2"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/button2"
        android:onClick="onButton2Clicked"/&gt;
&lt;/LinearLayout&gt;

...

<Button

android:id="@+id/button2"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="@string/button2"

android:onClick="onButton2Clicked"/>

</LinearLayout>

レイアウトファイル内の赤でマークされた領域をクリックしAlt + Enterを押します。Android Studioからの提案に従って、stringsリソースに「Open Second Activity」として追加し、MainActivityにonButton2Clickedメソッドを追加します。
MainActivityのonButton2Clickedメソッドに以下を追加します：

public void onButton2Clicked(View view) { Intent intent = new Intent(this, SecondActivity.class); startActivity(intent); }

1
2
3
4

public void onButton2Clicked(View view) {
Intent intent = new Intent(this, SecondActivity.class);
startActivity(intent);
}

SecondActivityへの参照が含まれるように、appのマニフェストを編集します：

&lt;manifest ...&gt;
    &lt;application ...&gt;
        ...
        &lt;activity
            android:name="com.buildsystemexample.app.SecondActivity"
            android:label="@string/title_activity_second" &gt;
        &lt;/activity&gt;
    &lt;/application&gt;
&lt;/manifest&gt;

...

<activity

android:name="com.buildsystemexample.app.SecondActivity"

android:label="@string/title_activity_second" >

</activity>

</application>

</manifest>

Build output

これでBuildSystemExampleアプリが完成しました。これをビルドするには、Android Studio やコマンドラインからassembleタスクを呼び出します。

ビルドは、各ビルドバリアントのAPKを生成します。 app/build/apk/ディレクトリには、app-full-release.apkやapp-demo-debug.apkのようなapp-<flavor>-<buildtype>.apkという形式のapkが生成されます。

リファレンス

ビルドシステムは非常に柔軟であり、ここで記載されたものより多くの特徴があります。完全なリファレンスについては、 Gradleユーザーガイド用Androidプラグインを参照ください。