WITH_KMS=YES WITH_NEW_XORG=YES |
Option "AutoAddDevices" "Off" |
exec xcompmgr & exec openbox-session |
# WB: autologin console as user "brilliant" A|Al|Autologin console:\ :ht:np:sp#115200:al=brilliant |
ttyv1 "/usr/libexec/getty Al" xterm on secure |
# WB: startx if it isn't already running set XPID = `/usr/bin/pgrep X` if ( { [ -n "$XPID" ] } ) then #echo "X is already running" else startx logout endif |
source /usr/GNUstep/System/Library/Makefiles/GNUstep.csh |
WITH_KMS=YES WITH_NEW_XORG=YES |
Option "AutoAddDevices" "Off" |
exec xcompmgr & exec openbox-session |
# WB: autologin console as user "brilliant" A|Al|Autologin console:\ :ht:np:sp#115200:al=brilliant |
ttyv1 "/usr/libexec/getty Al" xterm on secure |
# WB: startx if it isn't already running set XPID = `/usr/bin/pgrep X` if ( { [ -n "$XPID" ] } ) then #echo "X is already running" else startx logout endif |
source /usr/GNUstep/System/Library/Makefiles/GNUstep.csh |
※このエントリは、Google Analytics SDK for Android v2 (Beta) - Overview の翻訳記事です。
Google Analytics SDK for Android は、開発者がアプリからユーザーの活動に関するデータを収集することを容易にします。このドキュメントはSDKの価値の概要と、単一のプロパティIDとEasyTrackerを使用した計測の方法に関するガイドを提供します。
v1.xからのマイグレート？ v2を使うために ”マイグレーションガイド” をご覧ください。
Google Analytics SDK for Android は、開発者がアプリからユーザーの活動に関するデータを収集することを容易にします。
開発者は計測のために、Google Analytics のレポートを使用することができます：
加えて、Google Analytics SDK for Android は、Google Playからインストールされ、アプリ内課金を通じて、販売チャネルの実績をエンド・ツー・エンドの可視化することにより、モバイルマーケティングキャンペーンの実績をモニタするツールを提供します。
SDKで実装を始める前に、以下を用意しておいてください：
SDKを使って開始するには3つのステップがあります：
これらのステップを完了したら、Google Analyticsを使用して計測を行うことができます：
AndroidManifest.xmlファイルに以下のパーミッションを追加します：
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
以下の例のように、それぞれのアクティビティ中の onStart() と onStop() メソッドに送信メソッドを追加します：
/**
* Analyticsを実装したアプリのアクティビティの例
*/
public class myTrackedActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
@Override
public void onStart() {
super.onStart();
... // onStart() の残りのコード
EasyTracker.getInstance().activityStart(this); // このメソッドを追加
}
@Override
public void onStop() {
super.onStop();
... // onStop() の残りのコード
EasyTracker.getInstance().activityStop(this); // このメソッドを追加
}
}
EasyTracker は呼び出される前にコンテキストを必要とすることに注意してください。上記の例でいうと次の行です：
EasyTracker.getInstance.activityStart(this);
コンテキストの設定は慎重に行って下さい。
一方でもし、他のクラスやメソッドで EasyTracker を用いる必要がある場合は、EasyTrackerの setContext(Context ctx) メソッドを最初に呼ぶ必要があります。
// EasyTrackerを使用する前にコンテキストをセットする。
// SDK はアプリケーションコンテキストを使用することに注意
EasyTracker.getInstance().setContext(this);
// EasyTrackerの準備はOK
Google Analytics SDK for Androidのバージョン2では設定オプションは、このガイドで analytics.xml と呼ばれているXMLリソースファイルによって管理されます。プロジェクトの res/values フォルダの中にこのファイルを生成し、トラッキングIDを追加する必要があります。以下の例は、どのようにトラッキングIDを追加し、アクティビティを有効にして、例外を計測するかについて示したものです：
<?xml version="1.0" encoding="utf-8" ?>
<resources>
<string name="ga_trackingId">UA-XXXX-Y</string>
<bool name="ga_autoActivityTracking">true</bool>
<bool name="ga_reportUncaughtExceptions">true</bool>
</resources>
LintのチェッカーがトラッキングIDのダッシュ('-')の使用について警告を発するかもしれません。<resources> タグに追加の属性を追加することで警告を抑制することができます：
<resources xmlns:tools="http://schemas.android.com/tools"
tools:ignore="TypographyDashes">
重要：ga_trackingIdの文字列中のダッシュはエンコードしないでください。エンコードしてしまうと、レポートのいかなるデータも見ることができなくなってしまいます。
実装の際に設定可能な完全なパラメータのリストは、analytics.xml パラメータ参照をご覧ください。
おめでとうございます！これでアプリは Google Analytics にデータを送信する準備ができました。
キャンペーン計測、アプリ内課金と取引、ユーザとやりとりするイベントを含む、Googleアナリティクスをさらに利用することができます。あなたのアプリにどのようにこれらの機能を追加するかを学ぶには、以下のデベロッパーガイドを御覧ください：
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License.
文責：品川開発課 瀬戸 直喜
※このエントリは、Google Analytics SDK for Android v2 (Beta) - Overview の翻訳記事です。
Google Analytics SDK for Android は、開発者がアプリからユーザーの活動に関するデータを収集することを容易にします。このドキュメントはSDKの価値の概要と、単一のプロパティIDとEasyTrackerを使用した計測の方法に関するガイドを提供します。
v1.xからのマイグレート？ v2を使うために ”マイグレーションガイド” をご覧ください。
Google Analytics SDK for Android は、開発者がアプリからユーザーの活動に関するデータを収集することを容易にします。
開発者は計測のために、Google Analytics のレポートを使用することができます：
加えて、Google Analytics SDK for Android は、Google Playからインストールされ、アプリ内課金を通じて、販売チャネルの実績をエンド・ツー・エンドの可視化することにより、モバイルマーケティングキャンペーンの実績をモニタするツールを提供します。
SDKで実装を始める前に、以下を用意しておいてください：
SDKを使って開始するには3つのステップがあります：
これらのステップを完了したら、Google Analyticsを使用して計測を行うことができます：
AndroidManifest.xmlファイルに以下のパーミッションを追加します：
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
以下の例のように、それぞれのアクティビティ中の onStart() と onStop() メソッドに送信メソッドを追加します：
/**
* Analyticsを実装したアプリのアクティビティの例
*/
public class myTrackedActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
@Override
public void onStart() {
super.onStart();
... // onStart() の残りのコード
EasyTracker.getInstance().activityStart(this); // このメソッドを追加
}
@Override
public void onStop() {
super.onStop();
... // onStop() の残りのコード
EasyTracker.getInstance().activityStop(this); // このメソッドを追加
}
}
EasyTracker は呼び出される前にコンテキストを必要とすることに注意してください。上記の例でいうと次の行です：
EasyTracker.getInstance.activityStart(this);
コンテキストの設定は慎重に行って下さい。
一方でもし、他のクラスやメソッドで EasyTracker を用いる必要がある場合は、EasyTrackerの setContext(Context ctx) メソッドを最初に呼ぶ必要があります。
// EasyTrackerを使用する前にコンテキストをセットする。
// SDK はアプリケーションコンテキストを使用することに注意
EasyTracker.getInstance().setContext(this);
// EasyTrackerの準備はOK
Google Analytics SDK for Androidのバージョン2では設定オプションは、このガイドで analytics.xml と呼ばれているXMLリソースファイルによって管理されます。プロジェクトの res/values フォルダの中にこのファイルを生成し、トラッキングIDを追加する必要があります。以下の例は、どのようにトラッキングIDを追加し、アクティビティを有効にして、例外を計測するかについて示したものです：
<?xml version="1.0" encoding="utf-8" ?>
<resources>
<string name="ga_trackingId">UA-XXXX-Y</string>
<bool name="ga_autoActivityTracking">true</bool>
<bool name="ga_reportUncaughtExceptions">true</bool>
</resources>
LintのチェッカーがトラッキングIDのダッシュ('-')の使用について警告を発するかもしれません。<resources> タグに追加の属性を追加することで警告を抑制することができます：
<resources xmlns:tools="http://schemas.android.com/tools"
tools:ignore="TypographyDashes">
重要：ga_trackingIdの文字列中のダッシュはエンコードしないでください。エンコードしてしまうと、レポートのいかなるデータも見ることができなくなってしまいます。
実装の際に設定可能な完全なパラメータのリストは、analytics.xml パラメータ参照をご覧ください。
おめでとうございます！これでアプリは Google Analytics にデータを送信する準備ができました。
キャンペーン計測、アプリ内課金と取引、ユーザとやりとりするイベントを含む、Googleアナリティクスをさらに利用することができます。あなたのアプリにどのようにこれらの機能を追加するかを学ぶには、以下のデベロッパーガイドを御覧ください：
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License.
文責：品川開発課 瀬戸 直喜
※このエントリは、Migrating from Eclipseを翻訳したものです。
もし以前に Eclipse を使って Android の開発を行っていて、Android Studio にマイグレートしたい時、Gradle ビルドファイルを生成するために Eclipse からプロジェクトをエクスポートしなければなりません。その後、Android Studio にインポートすることができます。
選択したプロジェクトが同じ場所に存在しますが、build.gradle ファイルが含まれてAndroid Studio 用に準備されます。
これで プロジェクトが Android Studio へインポートされ、getting started の ヘルプで Tips and Tricks を読むことができます。
注意：例えエクリプスからGradleのビルドファイルを生成できなくても、既存の Android プロジェクトを Android Studio にインポートすることができますー Android Studio は既に存在するAntビルドファイルを用いて、ビルドとプロジェクトの実行に成功するでしょう。しかし、ビルド変数の利点や将来のその他の高度な機能を得るために、ADTプラグインを使ってGradleビルドファイルを生成するか、Android Studioを使用して独自で記述したGradleビルドファイルを記述することを強くお勧めします。Gradleビルドシステムについては、 Gradleプラグインユーザーガイドをご覧ください。
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
文責：品川開発課 瀬戸 直喜(@Lionas)
※このエントリは、Migrating from Eclipseを翻訳したものです。
もし以前に Eclipse を使って Android の開発を行っていて、Android Studio にマイグレートしたい時、Gradle ビルドファイルを生成するために Eclipse からプロジェクトをエクスポートしなければなりません。その後、Android Studio にインポートすることができます。
選択したプロジェクトが同じ場所に存在しますが、build.gradle ファイルが含まれてAndroid Studio 用に準備されます。
これで プロジェクトが Android Studio へインポートされ、getting started の ヘルプで Tips and Tricks を読むことができます。
注意：例えエクリプスからGradleのビルドファイルを生成できなくても、既存の Android プロジェクトを Android Studio にインポートすることができますー Android Studio は既に存在するAntビルドファイルを用いて、ビルドとプロジェクトの実行に成功するでしょう。しかし、ビルド変数の利点や将来のその他の高度な機能を得るために、ADTプラグインを使ってGradleビルドファイルを生成するか、Android Studioを使用して独自で記述したGradleビルドファイルを記述することを強くお勧めします。Gradleビルドシステムについては、 Gradleプラグインユーザーガイドをご覧ください。
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
文責：品川開発課 瀬戸 直喜(@Lionas)
※このエントリは Android Studio Tips and Tricks の翻訳記事です。
IntelliJ IDEAに慣れていない場合、Android Studio で共通のタスクをどのように実行するか悩むかもしれません。このページはそれらを手助けするTipsを提供します。
IntelliJ IDEA の完全なユーザードキュメント（上記 Android Studio ベースの）は、IntelliJ IDEA ドキュメントを参照してください。
Android Studioで新しいプロジェクトを作成する時（またはEclipseからプロジェクトをマイグレートする時）、プロジェクトの構造が以前と違うことに注意してください。図1のように全てのプロジェクトファイル、リソースやマニフェストファイルが src/ ディレクトリの中に入っています。
新しいプロジェクトの構造は、Gradleベースのビルドシステムによります。この構造はビルドプロセスに柔軟性を与え、複数のビルド変数（機能はまだ完全に実装されていません）を許容します。全ては予期した通りに動作しますが、いくつかのファイルは移動しています。主要な点は src/ ディレクトリ下のファイルのみ変更すべきでしょう。Gradleプロジェクト構造の更なる情報については、Gradleプラグインユーザガイドを御覧ください。
以下のトピックは、Android Studio でどのように基本開発タスクが振舞うかを記載したものです。
Android 仮想デバイスマネージャの全ての機能にAndroid Studio インタフェースから直接アクセス可能です。ツールバーのAndroid 仮想デバイスマネージャをクリックし開いて、エミュレータの中にアプリケーションを実行可能な新しい仮想デバイスを生成します。
SDKマネージャでは、新しい Android のツール、プラットフォーム、ライブラリをダウンロードすることができます。SDKマネージャをクリックし開いて、アップデートをチェックします。
プロジェクトペインの適切なディレクトリのクリック、または、CTRL + N (MacならCMD + N)の押下によって、迅速に新しいコードとリソースファイルを追加することができます。
選択されたディレクトリのタイプに基づいて、Android Studio は適切なファイルタイプを生成します。
例えば、レイアウトディレクトリを選択して、CTRL + N を押し、レイアウトのリソースファイルを選択した時、ダイアログが開いて、ファイル名を付けることができ（.xmlサフィックスを除外することもできます）、ルートのビューが選択されます。
その時、レイアウトデザインエディタにスイッチして、レイアウトのデザインを始めることができます。
Android Studio は、XMLを編集している間、レイアウトとプレビューの中にドラッグアンドドロップウィジェットを許す高度なレイアウトエディタを提供します。テキストビューの編集をしている間、ウィンドウの右側のプレビューペインを開くことにより、デバイスのレイアウトをプレビューすることができます。プレビューデバイス、レイアウトのテーマ、プラットフォームのバージョンなどを含むプレビューペインの中で、ペインの最上部の様々なオプションを変更することで、プレビューを変更することが可能です。
複数デバイスを同時にプレビューするには、デバイスのドロップダウンから「全てのスクリーンサイズをプレビュー」を選択します。
ウィンドウの最下部のデザインをクリックすることで、グラフィカルなエディタにスイッチすることができます。デザインビューを編集する間、ウィンドウの左側のパレットをクリックすることにより、ドラックアンドドロップでウィジェットを表示したり、隠したりすることができます。
ウィンドウ右側のデザイナをクリックすると、レイアウト階層とレイアウトのそれぞれのビューのプロパティを表示します。
Android Studio でアプリのビルドや実行を行う時、ウィンドウ下部の Android をクリックすることで、DDMSペインでadb ビューとデバイスログメッセージ（logcat）を見ることができます。
Android Debug Monitor でアプリをデバッグしたい場合、ツールバーの Monitor をクリックすることで立ち上げることができます。デバッグモニタでは、アプリをプロファイリングやデバイスの振る舞いなどを操作することができるDDMSツールの完全なセットを見つけることができます。これはレイアウトの最適化に便利な Hierarchy Viewer も含みます。
以下の表は共通操作のキーボードショートカットのリストです。
注意：Mac OS Xを使用している場合、Android Studio > 設定 > キーマップ で、Mac OS X 10.5+ バージョンのキーマップを使用するように、キーマップをアップデートして下さい。
Table 1. プログラミングキーコマンド
| アクション | Android Studioのキーコマンド |
|---|---|
| Command look-up (自動コンプリートコマンド名) | CTRL + SHIFT + A |
| プロジェクトクイックフィックス | ALT + ENTER |
| リフォーマットコード | CTRL + ALT + L (Win) |
| OPTION + CMD + L (Mac) | |
| 選択されたAPIのドキュメントを表示 | CTRL + Q (Win) |
| F1 (Mac) | |
| 選択されたメソッドのパラメータを表示 | CTRL + P |
| メソッドの生成 | ALT + Insert (Win) |
| CMD + N (Mac) | |
| ソースへジャンプ | F4 (Win) |
| CMD + down-arrow (Mac) | |
| 行削除 | CTRL + Y (Win) |
| CMD + Backspace (Mac) | |
| シンボル名で検索 | CTRL + ALT + SHIFT + N (Win) |
| OPTION + CMD + O (Mac) |
Table 2. プロジェクトとエディタのキーコマンド
| アクション | Android Studioのキーコマンド |
|---|---|
| ビルド | CTRL + F9 (Win) |
| CMD + F9 (Mac) | |
| ビルドと実行 | SHIFT + F10 (Win) |
| CTRL + R (Mac) | |
| プロジェクト可視性のトグル | ALT + 1 (Win) |
| CMD + 1 (Mac) | |
| 開くタブへのナビゲート | ALT + left-arrow; ALT + right-arrow (Win) |
| CTRL + left-arrow; CTRL + right-arrow (Mac) |
完全なキーマップのリファレンスガイドは、IntelliJ IDEA ドキュメントをご覧ください。
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
文責：品川開発課 瀬戸直喜(@Lionas)
※このエントリは Android Studio Tips and Tricks の翻訳記事です。
IntelliJ IDEAに慣れていない場合、Android Studio で共通のタスクをどのように実行するか悩むかもしれません。このページはそれらを手助けするTipsを提供します。
IntelliJ IDEA の完全なユーザードキュメント（上記 Android Studio ベースの）は、IntelliJ IDEA ドキュメントを参照してください。
Android Studioで新しいプロジェクトを作成する時（またはEclipseからプロジェクトをマイグレートする時）、プロジェクトの構造が以前と違うことに注意してください。図1のように全てのプロジェクトファイル、リソースやマニフェストファイルが src/ ディレクトリの中に入っています。
新しいプロジェクトの構造は、Gradleベースのビルドシステムによります。この構造はビルドプロセスに柔軟性を与え、複数のビルド変数（機能はまだ完全に実装されていません）を許容します。全ては予期した通りに動作しますが、いくつかのファイルは移動しています。主要な点は src/ ディレクトリ下のファイルのみ変更すべきでしょう。Gradleプロジェクト構造の更なる情報については、Gradleプラグインユーザガイドを御覧ください。
以下のトピックは、Android Studio でどのように基本開発タスクが振舞うかを記載したものです。
Android 仮想デバイスマネージャの全ての機能にAndroid Studio インタフェースから直接アクセス可能です。ツールバーのAndroid 仮想デバイスマネージャをクリックし開いて、エミュレータの中にアプリケーションを実行可能な新しい仮想デバイスを生成します。
SDKマネージャでは、新しい Android のツール、プラットフォーム、ライブラリをダウンロードすることができます。SDKマネージャをクリックし開いて、アップデートをチェックします。
プロジェクトペインの適切なディレクトリのクリック、または、CTRL + N (MacならCMD + N)の押下によって、迅速に新しいコードとリソースファイルを追加することができます。
選択されたディレクトリのタイプに基づいて、Android Studio は適切なファイルタイプを生成します。
例えば、レイアウトディレクトリを選択して、CTRL + N を押し、レイアウトのリソースファイルを選択した時、ダイアログが開いて、ファイル名を付けることができ（.xmlサフィックスを除外することもできます）、ルートのビューが選択されます。
その時、レイアウトデザインエディタにスイッチして、レイアウトのデザインを始めることができます。
Android Studio は、XMLを編集している間、レイアウトとプレビューの中にドラッグアンドドロップウィジェットを許す高度なレイアウトエディタを提供します。テキストビューの編集をしている間、ウィンドウの右側のプレビューペインを開くことにより、デバイスのレイアウトをプレビューすることができます。プレビューデバイス、レイアウトのテーマ、プラットフォームのバージョンなどを含むプレビューペインの中で、ペインの最上部の様々なオプションを変更することで、プレビューを変更することが可能です。
複数デバイスを同時にプレビューするには、デバイスのドロップダウンから「全てのスクリーンサイズをプレビュー」を選択します。
ウィンドウの最下部のデザインをクリックすることで、グラフィカルなエディタにスイッチすることができます。デザインビューを編集する間、ウィンドウの左側のパレットをクリックすることにより、ドラックアンドドロップでウィジェットを表示したり、隠したりすることができます。
ウィンドウ右側のデザイナをクリックすると、レイアウト階層とレイアウトのそれぞれのビューのプロパティを表示します。
Android Studio でアプリのビルドや実行を行う時、ウィンドウ下部の Android をクリックすることで、DDMSペインでadb ビューとデバイスログメッセージ（logcat）を見ることができます。
Android Debug Monitor でアプリをデバッグしたい場合、ツールバーの Monitor をクリックすることで立ち上げることができます。デバッグモニタでは、アプリをプロファイリングやデバイスの振る舞いなどを操作することができるDDMSツールの完全なセットを見つけることができます。これはレイアウトの最適化に便利な Hierarchy Viewer も含みます。
以下の表は共通操作のキーボードショートカットのリストです。
注意：Mac OS Xを使用している場合、Android Studio > 設定 > キーマップ で、Mac OS X 10.5+ バージョンのキーマップを使用するように、キーマップをアップデートして下さい。
Table 1. プログラミングキーコマンド
| アクション | Android Studioのキーコマンド |
|---|---|
| Command look-up (自動コンプリートコマンド名) | CTRL + SHIFT + A |
| プロジェクトクイックフィックス | ALT + ENTER |
| リフォーマットコード | CTRL + ALT + L (Win) |
| OPTION + CMD + L (Mac) | |
| 選択されたAPIのドキュメントを表示 | CTRL + Q (Win) |
| F1 (Mac) | |
| 選択されたメソッドのパラメータを表示 | CTRL + P |
| メソッドの生成 | ALT + Insert (Win) |
| CMD + N (Mac) | |
| ソースへジャンプ | F4 (Win) |
| CMD + down-arrow (Mac) | |
| 行削除 | CTRL + Y (Win) |
| CMD + Backspace (Mac) | |
| シンボル名で検索 | CTRL + ALT + SHIFT + N (Win) |
| OPTION + CMD + O (Mac) |
Table 2. プロジェクトとエディタのキーコマンド
| アクション | Android Studioのキーコマンド |
|---|---|
| ビルド | CTRL + F9 (Win) |
| CMD + F9 (Mac) | |
| ビルドと実行 | SHIFT + F10 (Win) |
| CTRL + R (Mac) | |
| プロジェクト可視性のトグル | ALT + 1 (Win) |
| CMD + 1 (Mac) | |
| 開くタブへのナビゲート | ALT + left-arrow; ALT + right-arrow (Win) |
| CTRL + left-arrow; CTRL + right-arrow (Mac) |
完全なキーマップのリファレンスガイドは、IntelliJ IDEA ドキュメントをご覧ください。
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
文責：品川開発課 瀬戸直喜(@Lionas)
※本記事は、Android Developer's Site の Getting Started with Android Studioの翻訳記事です。
アーリーアクセスプレビュー
Android Studio は IntelliJ IDEA ベースの新しいAndroid開発環境です。Eclipse with the ADTプラグインに似ており、Android Studio は開発及びデバッグ用の統合されたAndroid 開発者ツールを提供します。IntelliJから期待される能力として、Android Studioは以下を提供します：
警告：Android Studio は現在アーリーアクセスプレビューとして使用可能です。いくつかの機能は不完全だったり、未実装だったり、バグに遭遇する可能性があります。完全ではないプロダクトに不便を感じる方は ADTバンドル（Eclipse with the ADTプラグイン）をダウンロード（または引き続きそちらを使用）してください。
Windows:
既知の問題：
いくつかのWindowsシステムで、ランチャースクリプトが Java をインストールした先を見つけられません。この問題に遭遇した時は、環境変数が正しい位置を示すように設定しなければなりません。スタートメニュー > コンピュータ > システムプロパティ > 高度なシステムプロパティを選択します。この時、高度なタブ > 環境変数 を開き、新しいシステム変数 JAVA_HOME を JDKフォルダに指すように追加します。例えば、C:\Program Files\Java\jdk1.7.0_21.
Mac OS X:
既知の問題：
セキュリティの設定に依存しますが、Android Studioを開こうとした際に「パッケージが損傷されたためゴミ箱へ移動すべきです」というメッセージが表示されるかもしれません。この場合、システムプリファレンス > セキュリティ＆プライバシー を開き、ダウンロードしたアプリケーションを許可するの下の任意の場所を選択して、Android Studio を再起動してください。
Linux:
たったこれだけです！ これでAndroid Studio でアプリを開発する準備ができました。
注意：Windows と Mac で、個々のツール及びその他のパッケージが Android Studio アプリケーションディレクトリ内に保存されます。ツールに直接アクセスするために、ターミナルを使用してアプリケーション内のsdkディレクトリに移動します。例えば：
Windows: \Users\<ユーザ>\AppData\Local\Android\android-studio\sdk\
Mac: /Applications/Android\ Studio.app/sdk/
いくつかの既知の問題のリストは、tools.android.com/knownissues を参照してください。
最初に Android Studio を起動した時、初めての開発に役立ついくつかの方法がウェルカム画面に表示されます：
注意：
もし以前にAndroidプロジェクトをエクリプスで開発したことがあるなら、Gradleビルドシステムのプロジェクトを準備するために、最初にADTプラグインのエクスポート機能を使用すべきです。詳細は、Eclipseからのマイグレーティングを御覧ください。
Android Studioの追加のヘルプは、Tips and Tricks をご覧ください。
アプリを続けて開発する際、Android Supportライブラリのように、エミュレータとその他のパッケージ用の追加のAndroidバージョンをインストールする必要があるでしょう。更なるパッケージのインストールには、Android StudioのツールバーのSDKマネージャをクリックします。
注意：
Android Studioに定期的なアップデートがプッシュされます。手動でアップデートをチェックしたい場合、ヘルプ > アップデートのチェック（Macなら Android Studio > アップデートのチェック）を選択してください。
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
文責：品川開発課 瀬戸 直喜(@Lionas)
※本記事は、Android Developer's Site の Getting Started with Android Studioの翻訳記事です。
アーリーアクセスプレビュー
Android Studio は IntelliJ IDEA ベースの新しいAndroid開発環境です。Eclipse with the ADTプラグインに似ており、Android Studio は開発及びデバッグ用の統合されたAndroid 開発者ツールを提供します。IntelliJから期待される能力として、Android Studioは以下を提供します：
警告：Android Studio は現在アーリーアクセスプレビューとして使用可能です。いくつかの機能は不完全だったり、未実装だったり、バグに遭遇する可能性があります。完全ではないプロダクトに不便を感じる方は ADTバンドル（Eclipse with the ADTプラグイン）をダウンロード（または引き続きそちらを使用）してください。
Windows:
既知の問題：
いくつかのWindowsシステムで、ランチャースクリプトが Java をインストールした先を見つけられません。この問題に遭遇した時は、環境変数が正しい位置を示すように設定しなければなりません。スタートメニュー > コンピュータ > システムプロパティ > 高度なシステムプロパティを選択します。この時、高度なタブ > 環境変数 を開き、新しいシステム変数 JAVA_HOME を JDKフォルダに指すように追加します。例えば、C:\Program Files\Java\jdk1.7.0_21.
Mac OS X:
既知の問題：
セキュリティの設定に依存しますが、Android Studioを開こうとした際に「パッケージが損傷されたためゴミ箱へ移動すべきです」というメッセージが表示されるかもしれません。この場合、システムプリファレンス > セキュリティ＆プライバシー を開き、ダウンロードしたアプリケーションを許可するの下の任意の場所を選択して、Android Studio を再起動してください。
Linux:
たったこれだけです！ これでAndroid Studio でアプリを開発する準備ができました。
注意：Windows と Mac で、個々のツール及びその他のパッケージが Android Studio アプリケーションディレクトリ内に保存されます。ツールに直接アクセスするために、ターミナルを使用してアプリケーション内のsdkディレクトリに移動します。例えば：
Windows: \Users\<ユーザ>\AppData\Local\Android\android-studio\sdk\
Mac: /Applications/Android\ Studio.app/sdk/
いくつかの既知の問題のリストは、tools.android.com/knownissues を参照してください。
最初に Android Studio を起動した時、初めての開発に役立ついくつかの方法がウェルカム画面に表示されます：
注意：
もし以前にAndroidプロジェクトをエクリプスで開発したことがあるなら、Gradleビルドシステムのプロジェクトを準備するために、最初にADTプラグインのエクスポート機能を使用すべきです。詳細は、Eclipseからのマイグレーティングを御覧ください。
Android Studioの追加のヘルプは、Tips and Tricks をご覧ください。
アプリを続けて開発する際、Android Supportライブラリのように、エミュレータとその他のパッケージ用の追加のAndroidバージョンをインストールする必要があるでしょう。更なるパッケージのインストールには、Android StudioのツールバーのSDKマネージャをクリックします。
注意：
Android Studioに定期的なアップデートがプッシュされます。手動でアップデートをチェックしたい場合、ヘルプ > アップデートのチェック（Macなら Android Studio > アップデートのチェック）を選択してください。
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
文責：品川開発課 瀬戸 直喜(@Lionas)
※本記事は、Amazon Mobile App SDK/In-App Purchasing API の Quick Start Guide の翻訳記事です。
In-App Purchase API は、完全な機能を持つAPIセットを提供すると同時に課金プロセスの複雑性をカプセル化するようにデザインされています。APIはアプリ内課金のトランザクションを完了する間、以下のオブジェクトを利用します：
以下の図は購入シーケンスを含むステップの概要です：
Fig. 1: In-App Purchasing API
シンプルな実装は、以下の5ステップで完了します。
Amazon Client からコールバックを受け取るために AndroidManifest.xml ファイルの <application> セクションに以下の行を追加する必要があります。
<application>
.
.
.
<receiver android:name = "com.amazon.inapp.purchasing.ResponseReceiver" >
<intent-filter>
<action android:name = "com.amazon.inapp.purchasing.NOTIFY"
android:permission = "com.amazon.inapp.purchasing.Permission.NOTIFY" />
</intent-filter>
</receiver>
.
.
.
</application>
Purchasing Observerは Purchasing Manager を通じて初期化され、コールバックをリッスンします。オブザーバーはBasePurchasingObserver クラスを拡張すべきで、必要なコールバックメソッドのみをオーバーライドします。
最低でもアイテムデータを取得し、購入リクエストを初期化するためのコールバックを用意する必要があります。アプリのアクティビティの中に Purchasing Observer クラスを生成することができます。
private class MyObserver extends BasePurchasingObserver {
public MyObserver() {
super(MainActivity.this);
}
@Override
public void onItemDataResponse(ItemDataResponse itemDataResponse) {
//Check itemDataResponse.getItemDataRequestStatus();
//Use itemDataResponse to populate catalog data
}
@Override
public void onPurchaseResponse(PurchaseResponse purchaseResponse) {
//Check purchaseResponse.getPurchaseRequestStatus();
//If SUCCESSFUL, fulfill content;
}
}
Purchasing Manager で Purchasing Observer を登録する必要があります。そうすることで、オブザーバーはコールバックをリッスンすることができます。これは、アプリの開始メソッドで実施されなければなりません。
protected void onStart() {
super.onStart();
PurchasingManager.registerObserver(new MyObserver());
};
registering the Purchasing Observer を読む
オブザーバーを登録したら、アイテムデータリクエストの初期化と購入リクエストを使用できるようになります。APIは購入フローと全ての顧客がアプリとインタラクションすることを管理します。
initiateItemDataRequest メソッドで SKU のアイテムデータをリクエストするために、Purchasing Manager を使用します。
PurchasingManager.initiateItemDataRequest("DeveloperSKU-1234");
initiatePurchaseRequest メソッドで SKU の購入リクエストを初期化するために、Purchasing Managerを使用します。
private OnClickListener purchaseClickListener = new OnClickListener() {
public void onClick(View v) {
String requestId = PurchasingManager.initiatePurchaseRequest("DeveloperSKU-1234");
}
};
購入リクエストの呼び出しの初期化後、Purchasing Observer はリクエストにマッチしているレスポンスオブジェクトのコールバックを受信します。アプリは、コールバックを受信したレスポンスオブジェクトをハンドルし、ユーザーにコンテンツを提供する必要があります。
この実装はアプリ特有のものです。この時点で基本的な実装は完了し、SDK Tester App を使用してテストを開始することができます。
(C) 2010-2013, Amazon.com, Inc. or its affiliates. All Rights Reserved.
文責：品川開発課 瀬戸 直喜(@Lionas)
※本記事は、Amazon Mobile App SDK/In-App Purchasing API の Quick Start Guide の翻訳記事です。
In-App Purchase API は、完全な機能を持つAPIセットを提供すると同時に課金プロセスの複雑性をカプセル化するようにデザインされています。APIはアプリ内課金のトランザクションを完了する間、以下のオブジェクトを利用します：
以下の図は購入シーケンスを含むステップの概要です：
Fig. 1: In-App Purchasing API
シンプルな実装は、以下の5ステップで完了します。
Amazon Client からコールバックを受け取るために AndroidManifest.xml ファイルの <application> セクションに以下の行を追加する必要があります。
<application>
.
.
.
<receiver android:name = "com.amazon.inapp.purchasing.ResponseReceiver" >
<intent-filter>
<action android:name = "com.amazon.inapp.purchasing.NOTIFY"
android:permission = "com.amazon.inapp.purchasing.Permission.NOTIFY" />
</intent-filter>
</receiver>
.
.
.
</application>
Purchasing Observerは Purchasing Manager を通じて初期化され、コールバックをリッスンします。オブザーバーはBasePurchasingObserver クラスを拡張すべきで、必要なコールバックメソッドのみをオーバーライドします。
最低でもアイテムデータを取得し、購入リクエストを初期化するためのコールバックを用意する必要があります。アプリのアクティビティの中に Purchasing Observer クラスを生成することができます。
private class MyObserver extends BasePurchasingObserver {
public MyObserver() {
super(MainActivity.this);
}
@Override
public void onItemDataResponse(ItemDataResponse itemDataResponse) {
//Check itemDataResponse.getItemDataRequestStatus();
//Use itemDataResponse to populate catalog data
}
@Override
public void onPurchaseResponse(PurchaseResponse purchaseResponse) {
//Check purchaseResponse.getPurchaseRequestStatus();
//If SUCCESSFUL, fulfill content;
}
}
Purchasing Manager で Purchasing Observer を登録する必要があります。そうすることで、オブザーバーはコールバックをリッスンすることができます。これは、アプリの開始メソッドで実施されなければなりません。
protected void onStart() {
super.onStart();
PurchasingManager.registerObserver(new MyObserver());
};
registering the Purchasing Observer を読む
オブザーバーを登録したら、アイテムデータリクエストの初期化と購入リクエストを使用できるようになります。APIは購入フローと全ての顧客がアプリとインタラクションすることを管理します。
initiateItemDataRequest メソッドで SKU のアイテムデータをリクエストするために、Purchasing Manager を使用します。
PurchasingManager.initiateItemDataRequest("DeveloperSKU-1234");
initiatePurchaseRequest メソッドで SKU の購入リクエストを初期化するために、Purchasing Managerを使用します。
private OnClickListener purchaseClickListener = new OnClickListener() {
public void onClick(View v) {
String requestId = PurchasingManager.initiatePurchaseRequest("DeveloperSKU-1234");
}
};
購入リクエストの呼び出しの初期化後、Purchasing Observer はリクエストにマッチしているレスポンスオブジェクトのコールバックを受信します。アプリは、コールバックを受信したレスポンスオブジェクトをハンドルし、ユーザーにコンテンツを提供する必要があります。
この実装はアプリ特有のものです。この時点で基本的な実装は完了し、SDK Tester App を使用してテストを開始することができます。
(C) 2010-2013, Amazon.com, Inc. or its affiliates. All Rights Reserved.
文責：品川開発課 瀬戸 直喜(@Lionas)
Android Studioのビルドシステムを説明しているAndroid Tools Project SiteのNew Build Systemを翻訳しました。
新しいビルドシステムのゴールは以下の通りです。
(訳注: Google I/O 2013でGradleとの統合環境としてAndroidStudioが発表されました)
Gradleは高度なビルドシステムで、プラグインを通してカスタムしたビルドロジックの構築を可能とします。
我々がGradleを選んだ理由となる特徴を以下に示します。
Gradleのプロジェクトはプロジェクトのルートフォルダにあるとbuild.gradle呼ばれるファイルでそのビルドを定義しています。
殆どのシンプルなjavaのみのプロジェクトは以下の様なbuild.gradleとなります
apply plugin: 'java'
これはGradleに同梱されているJavaプラグインを適用します。このプラグインはjavaアプリケーションをビルドしたりテストする為の全ての機能を提供します。殆どのシンプルなAndroidプロジェクトは以下の様なbuild.gradleとなります：
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.3'
}
}
apply plugin: 'android'
android {
compileSdkVersion 17
}
この Android ビルドファイルには、3つの主なエリアがあります：
buildscript { ... } はビルドを走らせるコードを設定します。このケースでは、この定義は Mavenセントラルリポジトリを使用することを宣言し、Mavenアーティファクトに依存するクラスパスがあります。このアーティファクトは Android プラグイン for Gradle バージョン0.4.2 に含まれているライブラリです。
注意：これはビルドの実行コードに影響を及ぼすのみで、プロジェクトではありません。このプロジェクトは自身に、自身のリポジトリ及び依存性を宣言する必要があります。これは後で補足します。その後、Javaプラグインのように 'android' プラグインが先に適用されます。
最後に、android { ... } は、androidビルド向けの全てのパラメータを設定します。これはAndroid DSL のエントリポイントです。デフォルトでは、コンパイルターゲットのみが必要で、compileSdkVersion プロパティによって行われます。このプロパティは、旧ビルドシステムで project.properties がターゲットプロパティを設定しているのと同じです。新しいプロパティは、int型（APIレベル）または、以前のtargetプロパティと同じ値の文字列のいずれかを割り当てることができます。
重要：android プラグインのみ割り当てるべきです。javaプラグインを適用するとビルドエラーが発生します。
注意：sdk.dir プロパティを使用して、既存の SDK が要求するのと全く同じ方法でSDKの位置を設定するために local.properties ファイルが必要となります。あるいは、ANDROID_HOME と呼ばれる環境変数を設定することができます。
基本のビルドファイルは上記のデフォルトのフォルダ構造を期待します。Gradle は設定の慣習の概念に従い、可能な時はデフォルトのオプションの値を知覚可能なものとして提供します。
基本プロジェクトは、"ソースセット"と呼ばれる2つのコンポーネントから開始します。メインソースコードとテストコードです。これらはそれぞれ以下に存在します：
これらのフォルダの中にそれぞれのソースコンポーネントが存在します。JavaとAndroidプラグインの両方に、JavaのソースコードとJavaのリソースがあります：
Androidプラグインには、Android向けの追加のファイルやフォルダがあります：
注意：src/instrumentTest/AndroidManifest.xml は自動的に生成されるため特に必要としません。
デフォルトのプロジェクトが適切でない時は変更することができます。Gradleのドキュメントによると、Javaプロジェクトのソースセットの変更は以下のように実行できます：
sourceSets {
main {
java {
srcDir 'src/java'
}
resources {
srcDir 'src/resources'
}
}
}
注意：srcDir は既存のソースフォルダリストにフォルダーを実際に追加します（これはGradleのドキュメントでは明示されていませんが、実際の挙動です。）
デフォルトソースフォルダをリプレースするには、パスの配列の代わりにsrcDirsを使用します。これはまた関係のあるオブジェクトの使い方で別の方法を示します：
sourceSets {
main.java.srcDirs = ['src/java']
main.resources.srcDirs = ['src/resources']
}
さらなる情報については、Java plugin の Gradle ドキュメントをご覧ください。
Android プラグインは同様のシンタックスを使用しますが、自身のsourceSetsを使用するため android のオブジェクト内で実施します。メインコードの古いプロジェクト構造を使用して、instrumentTest sourceSet をテストフォルダに再マッピングする例を示します：
android {
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
instrumentTest.setRoot('tests')
}
}
注意：古い構造は全てのソースファイル（Java, AIDL, レンダースクリプト, Javaのリソース）を同じフォルダに格納するため、これら全てをsourceSetの新しいコンポーネントとして同じsrcフォルダに再マップしなければなりません。
注意：setRoot() は全体の sourceSet(とサブフォルダ）を新しいフォルダーに移動します。これは src/instrumentTest/* から tests/* に移動します。これは Android 特有のもので Java の sourceSetsでは動作しません。
ビルドファイルにプラグインを適用すると、ビルドタスクのセットを自動的に生成します。JavaプラグインとAndroidプラグインの両方で実施します。
タスクの慣習は以下の通り：
タスクのアセンブル、チェック、ビルドでは、実際には何もしません。これらはプラグインのためのアンカータスクで、実際に仕事をするタスクを追加するためのものです。
これは、プロジェクトのタイプが何であっても、あるいは、どのプラグインが適用されていても関係なく、同じタスクを常に呼び出すことを可能にします。例えば、checkタスクが呼ばれていても、findbugsプラグインが適用すると新しいタスクを生成し、依存関係をチェックし、呼び出されます。
コマンドラインから以下を実行することで、高レベルタスクの実行を取得できます：
gradle tasks
タスク実行中に全てのリストと依存性を見るには：
gradle tasks --all
注意：Gradleはタスクの入出力の宣言を自動的にモニタします。
変更なしにビルドが2回実行すると全てのタスクが最新であると Gradle はレポートしますが、これは要求される動作がないことを意味します。これは、余計なビルドの操作を必要とせずに、タスクがお互いに依存することを許します。
Java プラグインは2つの主なタスクを生成します。これはメインアンカータスクに依存します：
jarタスク自身は、直接的あるいは間接的に他のタスクに依存します：インスタンスのクラスは Javaのコードをコンパイルします。
テストはテストクラスでコンパイルされますが、テストが（クラスと同様に）自身に依存するため、これを呼び出すことは有用ではありません。
一般的に、assemble と check のみ呼び出し、その他のタスクは無視されるでしょう。
全てのタスクセットとJava プラグインの説明はこちらを御覧ください。
Androidプラグインは他のプラグインと互換性を保つため、同じルールを使用し、アンカータスクを追加します：
デバイスに接続することを必要としない一般的なチェックを実行するために、新しいアンカータスクは必要とされています。
ビルドが deviceCheck または connectedCheck に依存しないことに注意してください。
Androidプロジェクトは少なくとも2つの出力を保持します：デバッグAPKとリリースAPKです。
明確に分けてビルドするために、それぞれは自身のアンカータスクを持っています：
これらは両方とも、タスクがAPKをビルドするために複数のステップを実行する他のタスクに依存しています。
assemble タスクは両方に依存していており、両方のAPKをビルドします。
Tip: Gradleは コマンドライン上でタスク名としてキャメルケースをサポートします。例えば：
gradle aR
これは、'aR’にマッチするタスクが他になければ、次のようにタイプすることと同じです
gradle assembleRelease
check アンカータスクは自身の依存性を有しています：
最後に、プラグインはインストール可能な限り（署名を要求します）、全てのビルドタイプ（debug, release, test）のインストール／アンインストールタスクを生成します。
Android プラグインは、ビルドシステムから直接的に多くのものをカスタマイズするために、広域のDSLの提供します。
DSLを通じて、以下のマニフェストのエントリを変更することができます：
例：
android {
compileSdkVersion 15
defaultConfig {
versionCode 12
versionName "2.0"
minSdkVersion 16
targetSdkVersion 16
}
}
defaultConfig要素は、android要素の中にあり、全ての設定が定義されます。動的にビルドファイルに記述することができます。
例えば、どこかのファイルからバージョン名読み出したり、カスタムのロジックを使用することができます：
def getVersionName() {
...
}
android {
compileSdkVersion 15
defaultConfig {
versionCode 12
versionName getVersionName()
minSdkVersion 16
targetSdkVersion 16
}
}
DSLを通じてプロパティをセットしていない場合、デフォルト値が使用されます。以下はこれがどのように処理されるかを示す表です。
| プロパティ名 | DSLオブジェクトのデフォルト値 | デフォルト値 |
|---|---|---|
| versionCode | -1 | 存在する場合はマニフェストの値 |
| versionName | null | 存在する場合はマニフェストの値 |
| minSdkVersion | -1 | 存在する場合はマニフェストの値 |
| targetSdkVersion | -1 | 存在する場合はマニフェストの値 |
| packageName | null | 存在する場合はマニフェストの値 |
| testPackageName | null | アプリのパッケージ名 + “.test” |
| testInstrumentationRunner | null | android.test.InstrumentationTestRunner |
| signingConfig | null | null |
| proguardFile | N/A (設定のみ) | N/A (設定のみ) |
| proguardFiles | N/A (設定のみ) | N/A (設定のみ) |
これらのプロパティを実行するビルドスクリプトでロジックをカスタムする場合、2つ目のカラムの値は重要です。
例えば、次のように書くことができます：
if (android.defaultConfig.testInstrumentationRunner == null) {
// assign a better default...
}
値が null のままの場合、ビルド時にカラム3から実際のデフォルト値でリプレースされますが、DSL要素がこのデフォルト値を有していないので再び実行することはできません。これは実際に必要のないマニフェストがパースされることを防ぎます。
アプリのデバッグとリリースの両方のバージョンをビルドするために、デフォルトではAndroidプラグインは自動的にプロジェクトをセットアップします。これらは大抵セキュア（devでない）デバイス上で、アプリをデバッグする能力やAPKの署名方法で違いがあります。
キーまたは証明書によって署名されたデバッグバージョンは、よく知られた名前／パスワードで自動的に生成されます（ビルド中にプロンプトを要求されることを防ぐため）。リリースはビルド中では署名を行わず、後で必要になります。
この設定は、ビルドタイプと呼ばれるオブジェクトを通じて実行されます。デフォルトでは、デバッグとリリースの2つのインスタンスが生成されます。
Androidのプラグインはその他のビルドタイプの生成と同様に2つのインスタンスをカスタマイズすることを許します。これは、ビルドタイプのDSLコンテナで実行します：
android {
buildTypes {
debug {
packageNameSuffix ".debug"
}
jnidebug.initWith(buildTypes.debug)
jnidebug {
packageNameSuffix ".jnidebug"
jnidebugBuild true
}
}
}
上記スニペットは以下をアーカイブします：
新しいビルドタイプの生成は新しい要素を使用することと同じぐらい簡単で、ビルドタイプコンテナ下で initWith() を呼び出すかクロージャで設定します。
可能なプロパティとデフォルト値は：
| プロパティ名 | デバッグ用のデフォルト値 | リリース／その他のデフォルト値 |
|---|---|---|
| debuggable | true | false |
| jniDebugBuild | false | false |
| renderscriptDebugBuild | false | false |
| renderscriptOptimLevel | 3 | 3 |
| packageNameSuffix | null | null |
| versionNameSuffix | null | null |
| signingConfig | android.signingConfigs.debug | null |
| zipAlign | false | true |
| runProguard | false | false |
| proguardFile | N/A (設定のみ) | N/A (設定のみ) |
| proguardFiles | N/A (設定のみ) | N/A (設定のみ) |
これらのプロパティに加えて、ビルドタイプはコードとリソースをビルドするのに役立てることができます。
それぞれのビルドタイプのために、新しくマッチした sourceSet がデフォルトの位置と共に生成されます
src/<buildtypename>/
これはビルドタイプ名が main または instrumentTest ではなく（これはプラグインによって強いられます）、お互いにユニークである必要があることを意味します。
その他のソースセットのように、ビルドタイプソースセットの位置は再配置可能です：
android {
sourceSets.jnidebug.setRoot('foo/jnidebug')
}
加えて、それぞれのビルドタイプは 新しい <BuildTypeName> アセンブルタスクを生成します。
assembleDebug と assembleRelease タスクは、既に言及されています。debug と release ビルドタイプは予め作成された時、同様にタスクも自動的に作成されます。
上記のbuild.gradleスニペットはさらに assembleJnidebug タスクを生成し、assembleDebug と assembleRelease タスクに依存するように、同じ方法に依存する形でアセンブルされるでしょう。
Tip: gradle aJ で assembleJnidebug タスクが実行できることを覚えておいてください。
使用可能なユースケース：
ビルドタイプのコード／リソースは以下の方法で使用されます：
アプリケーションの署名に必要なものは以下の通り：
キーネームと同じように位置は、パスワードとストアタイプによって署名設定を形成します（SigningConfigタイプ）
デフォルトでは、デバッグ設定はよく知られたパスワードと良く知られたパスワードを用いたデフォルトのキーによる、デバッグキーストアでセットアップされています。
デバッグキーストアは、$HOME/.android/debug.keystore に格納されており、なければ生成されます。
デバッグビルドタイプは、この debug SigningConfig を自動的に使用します。
その他の設定を作成したり、デフォルトで内蔵されているものをカスタマイズすることが可能です。これは、signingConfigs DSL コンテナを通じて行います。
android {
signingConfigs {
debug {
storeFile file("debug.keystore")
}
myConfig {
storeFile file("other.keystore")
storePassword "android"
keyAlias "androiddebugkey"
keyPassword "android"
}
}
buildTypes {
foo {
debuggable true
jniDebugBuild true
signingConfig signingConfigs.myConfig
}
}
}
上記のスニペットは、デバッグキーストアの位置をプロジェクトのルートに変更するものです。自動的にこれを使用するビルドタイプに影響を与えます。このケースの場合、 debug Build タイプです。
また、新しい Signing Config と 新しいビルドタイプを生成し、新しい設定を利用します。
注意：デフォルトの場所のデバッグキーストアだけが自動的に生成されます。デバッグキーストアの位置を変更すると、オンデマンドで生成されんくなります。違う名前でSigningConfigを生成すると自動的にデフォルトのデバッグキーストアを使用します。
言い換えると、キーストアの位置が強く結びついており、設定名ではありません。
注意：キーストアの位置は大抵はプロジェクトのルートから相対的なもので、絶対パスはオススメできません。（自動的に生成される debugキーストアを除く）。
バージョン0.4から、ProGuardはProGuardバージョン4.9向けGradleプラグインを通じてサポートされています。
ビルドタイプが runProguard プロパティを通じてProGuardが設定されている場合、ProGuardプラグインは自動的に適用され、タスクは自動的に生成されます。
android {
buildTypes {
release {
runProguard true
proguardFile getDefaultProguardFile('proguard-android.txt')
}
}
productFlavors {
flavor1 {
}
flavor2 {
proguardFile 'some-other-rules.txt'
}
}
}
変数はこれらのビルドタイプとプロダクトフレーバーに定義されている全てのルールファイルを使用します。
2つのデフォルトルートファイルがあります。
これらは SDK に格納されています。getDefaultProguardFile() を使用して、ファイルのフルパスを返します。これらは最適化が有効になることを除いて全く同一です。
Gradleプロジェクトは他のコンポーネントへの依存性を持つことができます。これらコンポーネントは外部のバイナリパッケージや他のGradleプロジェクトです。
外部ライブラリのjarに依存する設定のため、コンパイル設定上の依存性を追記する必要があります。
dependencies {
compile file('libs/foo.jar')
}
android {
...
}
注意：DSL要素は標準 Gradle API の一部で、android の要素中には属しません。
コンパイルの設定は、メインアプリケーションをコンパイルするために使用されます。全てコンパイルのクラスパスとして追加され、APKにも含まれます。
これらは依存性を追加する他の使用可能な設定です：
関連するビルド・タイプがないAPKを構築することが不可能なため、APKは常に2つ（以上）の設定を有します：
compile and <buildtype>Compile.
新しいビルドタイプを生成すると、自動的に名前をベースとした新しい設定を生成します。
これはデバッグバージョンが（インスタンスのクラッシュを報告するなどで）カスタムライブラリが必要である一方、リリースでは必要がない時や同じライブラリの異なるバージョンに依存する場合に使用するのに便利です。
Gradle は Maven と Ivy リポジトリからアーティファクトをpullすることをサポートしています。
最初にリポジトリはリストに追加しなければなりません。その後、依存性は Maven または Ivy が宣言するアーティファクトに従って宣言される必要があります。
repositories {
mavenCentral()
}
dependencies {
compile 'com.google.guava:guava:11.0.2'
}
android {
...
}
注意：mavenCentral はリポジトリのURLを特定するためのショートカットです。Gradle はリモート及びローカルリポジトリの両方をサポートします。
注意：Gradle は全ての依存性において他動的に従うでしょう。これは、依存性が自身の依存性を有する場合、同様にpullされることを意味します。
依存性のセットアップに関するさらなる情報は、Gradleユーザーガイド、および、 DSLドキュメントを参照してください。
Gradleプロジェクトは、複数プロジェクトのセットアップを使用することにより、他のGradleプロジェクトに依存することもできます。
複数プロジェクトのセットアップは、ルートプロジェクトのサブフォルダとして全てのプロジェクトを有することにより、大抵は動作します
例えば、以下のような構造を与えます：
MyProject/
+ app/
+ libraries/
+ lib1/
+ lib2/
3つのプロジェクトを識別することができます。Gradle は以下の名前を参照します：
それぞれのプロジェクトは、自身の build.gradle を持ち、どのようにビルドするかを宣言します。
加えて、settings.gradleと呼ばれるファイルをプロジェクトのルートに宣言します。
これは以下のような構造を与えます：
MyProject/
| settings.gradle
+ app/
| build.gradle
+ libraries/
+ lib1/
| build.gradle
+ lib2/
| build.gradle
settings.gradle のコンテンツは非常にシンプルです：
include ':app', ':libraries:lib1', ':libraries:lib2'
これは、どのフォルダが実際のGradleプロジェクトかを定義します。
:app プロジェクトはライブラリに依存し、以下の依存性を宣言することで実行されます：
dependencies {
compile project(':libraries:lib1')
}
さらなる情報については、複数プロジェクトのセットアップを参照してください。
上記の複数プロジェクトのセットアップで、:libraries:lib1 と :libraries:lib2 は Javaプロジェクト、:app は Android プロジェクトで、jarの出力を使用します。
しかし、Android API または Android スタイルのリソースへのアクセスをするコードをシェアしたい場合、Androidライブラリプロジェクトでなければなりません。
ライブラリプロジェクトは、一般的な Android プロジェクトが若干の違いを持っていることに似ています。
ライブラリのビルドはアプリケーションのビルドとは異なるため、異なるプラグインが使用されます。
内部的には、両方のプラグインが同じコードの大部分を共有し、これらは同じ com.android.tools.build.gradle jar を提供します。
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.4.2'
}
}
apply plugin: 'android-library'
android {
compileSdkVersion 15
}
これは コンパイルのために API 15 を使用するライブラリプロジェクトを生成します。
ソースセットと依存性は、アプリケーションプロジェクトと同じように、同じ方法でカスタマイズすることができます。
ライブラリプロジェクトは APKを生成せず、（Androidアーカイブを表す）.aar パッケージを生成します。同一のアンカータスクはこれ（assembleDebug, assembleRelease）のために使用されます。そのため、そのようなプロジェクトを構築するコマンドに違いはありません。
ライブラリプロジェクトはまた、テスト APK を（テストの章をご覧ください）生成します。しかし、これはスコープとビルドタイプの使い方はさらに制限されています。これらのプロジェクトは２つのビルドタイプ、debug と release にのみアクセスします。デバッグタイプはテストアプリによって使用されます。リリースタイプはライブラリを使用するプロジェクトによって利用されます。
さらに、APKが生成されるのは一つだけなので、唯一の SigningConfig オブジェクトが存在します。これはテストAPKの署名で使用されます。DSLライブラリプロジェクトは次のようになります：
android {
debug {
...
}
release {
...
}
debugSigningConfig {
storeFile file("debug.keystore")
}
}
ビルドタイプの主な設定は、ライブラリプロジェクトには適用されないことに注意してください。
しかしながら、プロジェクトによって使用されているか、テストされているかによって、ライブラリの内容を変更するカスタムソースセットを使用することができます。
ライブラリの参照は、参照された他のプロジェクト同じように実行することができます：
dependencies {
compile project(':libraries:lib1')
compile project(':libraries:lib2')
}
注意：一つ以上のライブラリを有する場合、順序は重要です。これは、project.properties ファイルの依存性の順序が重要な旧ビルドシステムと同様です。
テストアプリケーションのビルドは、アプリケーションプロジェクトに統合されています。テストプロジェクトを分ける必要はありません。
前節で示したように、mainのソースセットの次はinstrumentTestソースセットで、デフォルトでは src/instrumentTest/ に配置されています。このソースセットから、Android instrumentation フレームワークを使用して、アプリケーションをテストするためにデバイスにデプロイされる、テストAPKがビルドされます。ソースセットには AndroidManifest.xml を含めるべきではありません。なぜなら、自動的に生成されるためです。
テストアプリ用に設定可能ないくつかの値があります。
前に示した通り、これらは defaultConfig オブジェクトで設定されます：
android {
defaultConfig {
testPackage "com.test.foo"
testInstrumentationRunner "android.test.InstrumentationTestRunner"
}
}
defaultConfig および/または ビルドタイプオブジェクトの設定に関わらず、テストアプリケーションマニフェスト中の、instrumentation ノードの targetPackage の属性値は、テストされるアプリのパッケージ名で自動的に埋められます。これは自動的にマニフェストが自動的に生成される理由の一つとなっています。
加えて、ソースセットは依存性を持つように設定することができます。デフォルトでは、アプリケーションとその依存性はテストアプリのクラスパスに追加されますが、これは以下の方法で拡張することができます。
dependencies {
instrumentTestCompile 'com.google.guava:guava:11.0.2'
}
テストアプリは assembleTest タスクによってビルドされます。これは メインの assemble タスクには依存せず、代わりにテストが実行される際に自動的に呼び出されます。
現在は1つのビルドタイプのみテストされます。デフォルトでは、debug ビルドタイプのみですが、これは以下のように再設定することができます。
android {
...
testBuildType "staging"
}
前に示したように、deviceCheck と呼ばれる一番最後のタスクによって起動された接続済み端末を要求することをチェックします。これは instrumentTest タスクに依存しており、これにより実行されます。このタスクは次のことを実行します：
もし、1つ以上の端末が接続されている場合、全てのテストは並列に全て接続済み端末上で実行されます。いずれかの端末上でテストが失敗したら、ビルドは失敗します。
全てのテスト結果は build/instrumentTest-results 下の XML ファイルに格納されます。（これは、build/test-results 下に格納される一般的な jUnit の結果と似ています。）
これは以下のように設定することができます。
android {
...
testOptions {
resultsDir = "$project.buildDir/foo/results"
}
}
android.testOptions.resultsDir の値は Project.file(String) で評価されます。
Android のライブラリプロジェクトのテストは、アプリのプロジェクトと全く同一の方法で行います。
唯一の違いは、全体のライブラリ（とその依存性）が、テストアプリに対してライブラリの依存性として自動的に付加されることです。
結果は、テストAPK自身コードではなく、ライブラリとその全ての依存性を含んでいる、テストAPKです。ライブラリのマニフェストは、テストアプリのマニフェストにマージされています（このライブラリを参照するプロジェクトのケースとして）。
instrumentTest タスクはテストAPKのインストール（とアンインストール）時のみ変更されます（インストールする他のAPKがないため）。
その他は全て同一です。
ユニットテストの実行時、Gradle は 結果が容易に分かるように HTMLのレポートを出力します。Android のプラグインは これをビルドし、全ての接続済み端末の結果を集計するために HTML のレポートを拡張します。
プロジェクトはテストの実行で自動的に生成されます。デフォルトの配置場所は build/reports/instrumentTests です。これは build/reports/tests にある jUnit のレポート の配置場所、あるいは、 build/reports/<plugin>/ の中によくある、他のレポートの配置場所に似ています。
配置場所は以下のようにして変更することができます。
android {
...
testOptions {
reportDir = "$project.buildDir/foo/report"
}
}
レポートは異なる端末で実行された複数のテストを集計します。
複数のアプリケーションとライブラリのプロジェクトを伴う複数プロジェクトのセットアップは、同時に全てのテストが実行される時に、全ての instrumentation テストを単一の結果として生成するのに便利です。
これを実施するために、同じ生成物の中で、異なるプラグインを使用できるようにします。それは以下のようにして適用します：
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.3'
}
}
apply plugin: 'android-reporting'
これは settings.gradle の次の build.gradle の中でなど、ルートプロジェクトで適用すべきです。この時、ルートフォルダーから、以下のコマンドラインで全てのテストを実行し、結果を集計します：
gradle deviceCheck mergeAndroidReports --continue
注意： --continue オプションは全てのテストを保証し、例えば一部のテストが失敗しても全てのサブプロジェクトは実行されます。このオプションがなければ、最初のテストの失敗時にテストの実行は中断され、全てのテストは実行されません。
まだサポートしていません。しばし待たれよ。
新しいビルドシステムのゴールのひとつは、同じアプリケーションの異なるバージョンの生成を有効にすることです。大きく２つのユースケースがあります：
ゴールは、単一のライブラリプロジェクトと2つ以上のアプリケーションプロジェクトを使用することとは対照的に、同じプロジェクトからこれらの異なるAPKを生成することです。
プロダクトフレーバーは、プロジェクトによりビルドするカスタマイズされたアプリケーションのバージョンを定義します。単一のプロジェクトは、生成されたアプリケーションを変える異なるフレーバーを持つことができます。
この新しいコンセプトとは、変更がとても小さい時に便利なように設計されています。「これは同じアプリケーションか？」という問いに対して答えがYesの時、これはおそらくライブラリプロジェクトに関する方法です。
プロダクトフレーバーは、productFravors DSLコンテナを使用して宣言します：
android {
....
productFlavors {
flavor1 {
...
}
flavor2 {
...
}
}
}
これは、flavor1 と flavor2 の2つのフレーバーを生成します。
注意：フレーバーの名前は、既に存在するビルドタイプや instrumentTest ソースセットの名前を衝突してはいけません。
前説で確認したように、それぞれのビルドタイプは新しいAPKを生成します。
プロダクトフレーバーも同じように機能します：プロジェクトの出力は、ビルドタイプと適用可能であればプロダクトフレーバーの両者の全ての可能な組み合わせとなります。
それぞれ（ビルドタイプ、プロダクトフレーバー）の組み合わせは、ビルド変数と呼ばれます。
デフォルトの debug と release ビルドタイプの例では、4つのビルド変数を生成します：
フレーバーのないプロジェクトもまたビルド変数を有します。しかし、単一のデフォルトフレーバー／設定が無名で使用され、ビルドタイプのリストに似た変数のリストを作成します。
各フレーバーはクロージャで設定されます：
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
productFlavors {
flavor1 {
packageName "com.example.flavor1"
versionCode 20
}
flavor2 {
packageName "com.example.flavor2"
minSdkVersion 14
}
}
}
android.productFlavors.* オブジェクトは、android.defaultConfigオブジェクトと同じタイプのプロダクトフレーバータイプのオブジェクトです。これは、同じプロパティを共有することを意味します。
defaultConfig は全てのフレーバーと各フレーバーが任意の値でオーバーライド可能な、基準の設定を提供します。以下の例では次のように解釈されます：
たいていの場合、ビルドタイプ設定は他の設定の上にオーバーレイされます。例えば、ビルドタイプの packageNameSuffix はプロダクトフレーバーの packageName に追加されます。ビルドタイプとプロダクトフレーバーの両方が設定可能なケースがあります。このケースの場合、基本ケースの上にケースが乗っています。例えば、signingConfig はこれらの属性の一つです。
これは、全てのリリースパッケージが android.buildTypes.release.signingConfig によって同じ SigningConfig を共有するか、あるいは、それぞれのリリースパッケージが、android.productFavors.*.signingConfig オブジェクトを個別に設定することで、自身の SigningConfig を使用することを有効にします。
ビルドタイプと同様にプロダクトフレーバーもまた、自身の sourceSets を通じてコードとリソースを提供します。
上記の例は、4つの sourceSets を生成します：
これらの sourceSets は android.sourceSets.main と ビルドタイプの sourceSet と並んで、APK のビルドで使用されます。
以下のルールは、単一の APK をビルドするために全てのソースセットを取り扱う際に使用されます：
最後に、ビルドタイプのようにプロダクトフレーバーは自身の依存関係を持つことができます。例えば、フレーバーが広告ベースのアプリと支払いベースのアプリを生成するために使用される場合、フレーバーの一つは広告SDKに依存し、他はそうしないようにできます。
dependencies {
flavor1Compile "..."
}
特にこの場合は、src/flavor1/AndroidManifest.xml ファイルがインターネット権限を含む必要が、おそらくあるでしょう。
前にそれぞれのビルドタイプは自身の assemble<name> タスクを生成することをみましたが、しかし、そのビルド変数はビルドタイプとプロダクトフレーバーのコンビネーションです。
プロダクトフレーバーの使用時、assemble タイプのタスクが生成されます。これらは以下のようなものがあります。
1は単一の変数を直接ビルドすることを許します。例えば、assembleFlavor1Debug.
2は指定のビルドタイプで全てのAPKをビルドすることを許します。たとえば、assembleDebug は Flavor1Debug と Flavor2Debug の両方の変数をビルドします。
3は指定のフレーバーで全てのAPKをビルドすることを許します。例えば、assembleFlavor1 は Flavor1Debug と Flavor1Release の両方の変数をビルドします。
assemble タスクは、もちろん、全ての使用可能な変数をビルドします。
マルチフレーバープロジェクトのテストは、単純なプロジェクトに非常に似ています。
instrumenTest ソースセットは全てのフレーバーに渡る共通のテストとして使用され、それぞれのフレーバーはまた、自身のテストを持つことが可能です。
上記のように、各フレーバーをテストするためのソースセットは生成されます：
同様に、これらは自身の依存性を持つことができます：
dependencies {
instrumentTestFlavor1Compile "..."
}
テストの実行は、メインの deviceCheck アンカータスクを通じて実施することができます。あるいは、フレーバーが使用される時、アンカータスクとして動作するメインの instrumentTest タスクを通じて実施することができます。
各フレーバーはテストを実行するために自身のタスクを持ちます：instrumentTest<変数名>
例えば、
同様に、テストAPKはタスクをビルドし、変数ごとにインストール/アンインストールタスクがあります。
...
最後に、HTMLレポートの生成は、フレーバーの集まりをサポートします。
テスト結果とレポートの場所は以下の通りです。最初はフレーバーのバージョンごとで、その後一つにまとめられます。
それぞれのパスの変更は、ルートのフォルダーを変更するのみです。フレーバーごとのサブフォルダーは生成されたままで、結果やレポートはそこに集められます。
ある場合では、一つ以上の基準で、同じアプリの異なるバージョンを作りたいかもしれません。
例えば、Google PlayがサポートするマルチAPKは4つの異なるフィルターがサポートされています。それぞれのフィルターにあわせて異なるAPKを分けて生成するには、1つ以上のプロダクトフレーバーが使用できることが求められます。
デモ版と有料版のゲームで、マルチAPKサポートでABIフィルターを利用したい場合の例を考えてください。3つのABIと2つのアプリケーションのバージョンがあると、APKは6つ生成しなければなりません（異なるビルドタイプによる変数はカウントしていません）。
しかし、有料版は3つのABIが同一なので、単純に6つのフレーバーを作成することはしません。その代わり2次元のフレーバーと変数で、可能な限りの組み合わせを自動的に利用すべきです。この機能はフレーバーグループで実装されています。それぞれのグループは次元を表現し、フレーバーは特別なグループに対してアサインされます。
android {
...
flavorGroups "abi", "version"
productFlavors {
freeapp {
flavorGroup "version"
...
}
x86 {
flavorGroup "abi"
...
}
}
}
android.flavorGroups の配列は順序と共に使用可能なグループを定義します。それぞれはグループにアサインされたプロダクトフレーバーを定義します。
プロダクトフレーバー[freeapp,paidapp]と[x86,arm,mips]、ビルドタイプ[debug,release]でグループ化されて、以下のビルド変数が生成されます：
android.flavorGroups で定義されたグループの順番は非常に重要です。
それぞれの変数はいくつかのプロダクトフレーバーで設定されます：
フレーバーの値が、優先順位の低いフレーバーの値を上書きする時、グループの順番はその他でオーバーライドされたフレーバーを操作しますが、これはリソース面で非常に重要です。
フレーバーグループは優先順位の高く定義されます。以下のようなケースが成り立ちます：
abi > version > defaultConfig
android {
compileOptions {
sourceCompatibility = "1.6"
targetCompatibility = "1.6"
}
}
デフォルト値は “1.6” です。Java ソースコードをコンパイルする全てのタスクに影響します。
android {
aaptOptions {
noCompress 'foo', 'bar'
ignoreAssetsPattern "!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~"
}
}
これは aapt を使用する全てのタスクに影響します。
android {
dexOptions {
incremental false
}
}
これは dex を使用する全てのタスクに影響します。デフォルトは true。
基本的な Java プロジェクトは有限のタスクセットを保持しており、出力を生成するように動作します。Java ソースコードをコンパイルする classes タスクもその一つです。
スクリプト中で classes を単に使用して、build.gradle からアクセスするのは容易です。これは project.tasks.classes のショートカットです。
Android プロジェクトでは、同じタスクや Build Typesand Project Flavorsに基づいて生成される名前が数多くあることから、もう少し複雑になっています。これを確定するために、android オブジェクトは以下のプロパティを持っています：
それぞれ、ApplicationVariant, LibraryVariant, TestVariant オブジェクトの DomainObjectCollection を戻します。
各々のコレクションへのアクセスは、全てのタスクの生成のトリガとなることに注意してください。これは、コレクションのアクセス後に（再）設定すべきではないことを意味します。
DomainObjectCollection は、全てのオブジェクトに直接 または 便利なフィルタを通じてアクセスする方法を付与します。
android.buildVariants.each { variant ->
....
}
3つ全てで共有するプロパティは以下の通り：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| name | String | 変数名。ユニークであることが保証されます。 |
| description | String | 人間が読むことができる変数の説明。 |
| dirName | String | 変数名のサブフォルダ。ユニークであることが保証されます。'debug/flavor1'のように1つ以上になる可能性 |
| baseName | String | 変数の出力の基本名。ユニークであることが保証されます。 |
| outputFile | File | 変数出力。これは読み込み／書き込みプロパティです。 |
| processManifest | ProcessManifest | マニフェストを処理するタスク |
| aidlCompile | AidlCompile | AIDLファイルをコンパイルするタスク |
| renderscriptCompile | RenderscriptCompile | レンダースクリプトファイルをコンパイルするタスク |
| mergeResources | MergeResources | リソースをマージするタスク |
| mergeAssets | MergeAssets | アセットをマージするタスク |
| processResources | ProcessAndroidResources | 処理とリソースのコンパイルをするタスク |
| generateBuildConfig | GenerateBuildConfig | ビルドコンフィグクラスを生成するタスク |
| javaCompile | JavaCompile | Javaのコードをコンパイルするタスク |
| processJavaResources | Copy | Javaのリソースを処理するタスク |
| assemble | DefaultTask | この変数のアセンブルアンカータスク。 |
ApplicationVariant クラスは下記を追加します：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| buildType | BuildType | 変数のビルドタイプ |
| productFlavors | List<ProductFlavor> | 変数のプロダクトフレーバー。常にNullは許容されないが、空は許容される。 |
| mergedFlavor | ProductFlavor | android.defaultConfig と variant.productFlavors をマージしたもの。 |
| signingConfig | SigningConfig | 変数によって使用される SigningConfig オブジェクト |
| isSigningReady | boolean | 変数が署名のための必要な情報を全て有しているとき true |
| testVariant | BuildVariant | 変数によってテストされるビルド変数 |
| dex | Dex | dexコードのタスク。変数がライブラリならnullにできる。 |
| packageApplication | PackageApplication | 最終APKを生成する。変数がライブラリならnullにできる。 |
| zipAlign | ZipAlign | zipalignsのAPKのタスク変数がライブラリまたはAPKに署名されていない場合はnullにできる。 |
| install | DefaultTask | インストールタスク。null可。 |
| Uninstall | DefaultTask | アンインストールタスク |
LibraryVariant クラスは下記を追加します：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| buildType | BuildType | 変数のビルドタイプ |
| config | ProductFlavor | defaultConfigの値 |
| testVariant | BuildVariant | 変数によってテストされるビルド変数 |
| packageLibrary | Zip | AARアーカイブライブラリのパッケージのタスク。ライブラリでない場合はnull。 |
TestVariant クラスは下記を追加します：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| buildType | BuildType | 変数のビルドタイプ |
| productFlavors | List<ProductFlavor> | 変数のプロダクトフレーバー。常にNullは許容されないが、空は許容される。 |
| mergedFlavor | ProductFlavor | android.defaultConfig と variant.productFlavors をマージしたもの。 |
| signingConfig | SigningConfig | 変数によって使用される SigningConfig オブジェクト |
| isSigningReady | boolean | 変数が署名のための必要な情報を全て有しているとき true |
| testVariant | BuildVariant | 変数によってテストされるビルド変数 |
| dex | Dex | dexコードのタスク。変数がライブラリならnullにできる。 |
| packageApplication | PackageApplication | 最終APKを生成する。変数がライブラリならnullにできる。 |
| zipAlign | ZipAlign | zipalignsのAPKのタスク変数がライブラリまたはAPKに署名されていない場合はnullにできる。 |
| install | DefaultTask | インストールタスク。null可。 |
| Uninstall | DefaultTask | アンインストールタスク |
| connectedInstrumentTest | DefaultTask | 接続されたデバイス上のinstrumentationテストを実行するタスク |
| providerInstrumentTest | DefaultTask | 拡張APIを使用するinstrumentation テストを実行するタスク |
Android 専用タスクタイプのAPIは次の通り。
それぞれのタスクタイプ用APIは、Gradle の振る舞いと Android プラグインをセットアップの振る舞いの両方に限定されます。
最初に、Gradleは入出力の位置と使用可能なフラグのみを設定するタスクを持つことが目的です。そのため、タスクは（いくつかの）入出力のみを定義します。
2番目に、これらのタスクの多くの入力は自明ではなく、sourceSets やビルドタイプ、プロダクトフレーバーから値をミックスしたものになります。読んだり理解するためにシンプルなビルドファイルを維持するため、開発者がDSLを通じてこれらのオブジェクトを操作しビルドを編集させることが目的です。
加えて、ZipAlign タスクタイプを除いて、全てのタイプはこれら作業のためのプライベートなデータをセットアップすることを要求します。
このAPIは変更の対象です。一般的に現在のAPIは、出力と、追加で他の処理が必要なタスクの入力（可能なら）にアクセスする権利を与えます。特に予期しなかったもので必要に応じて、フィードバックは評価されます。
Gradleタスク（DefaultTask, JavaCompile, Copy, Zip) については、Gradleのドキュメントを参照ください。
乞うご期待。
文責：株式会社ブリリアントサービス 品川事業所 八木俊広、瀬戸直喜(@Lionas)
Android Studioのビルドシステムを説明しているAndroid Tools Project SiteのNew Build Systemを翻訳しました。
新しいビルドシステムのゴールは以下の通りです。
(訳注: Google I/O 2013でGradleとの統合環境としてAndroidStudioが発表されました)
Gradleは高度なビルドシステムで、プラグインを通してカスタムしたビルドロジックの構築を可能とします。
我々がGradleを選んだ理由となる特徴を以下に示します。
Gradleのプロジェクトはプロジェクトのルートフォルダにあるとbuild.gradle呼ばれるファイルでそのビルドを定義しています。
殆どのシンプルなjavaのみのプロジェクトは以下の様なbuild.gradleとなります
apply plugin: 'java'
これはGradleに同梱されているJavaプラグインを適用します。このプラグインはjavaアプリケーションをビルドしたりテストする為の全ての機能を提供します。殆どのシンプルなAndroidプロジェクトは以下の様なbuild.gradleとなります：
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.3'
}
}
apply plugin: 'android'
android {
compileSdkVersion 17
}
この Android ビルドファイルには、3つの主なエリアがあります：
buildscript { ... } はビルドを走らせるコードを設定します。このケースでは、この定義は Mavenセントラルリポジトリを使用することを宣言し、Mavenアーティファクトに依存するクラスパスがあります。このアーティファクトは Android プラグイン for Gradle バージョン0.4.2 に含まれているライブラリです。
注意：これはビルドの実行コードに影響を及ぼすのみで、プロジェクトではありません。このプロジェクトは自身に、自身のリポジトリ及び依存性を宣言する必要があります。これは後で補足します。その後、Javaプラグインのように 'android' プラグインが先に適用されます。
最後に、android { ... } は、androidビルド向けの全てのパラメータを設定します。これはAndroid DSL のエントリポイントです。デフォルトでは、コンパイルターゲットのみが必要で、compileSdkVersion プロパティによって行われます。このプロパティは、旧ビルドシステムで project.properties がターゲットプロパティを設定しているのと同じです。新しいプロパティは、int型（APIレベル）または、以前のtargetプロパティと同じ値の文字列のいずれかを割り当てることができます。
重要：android プラグインのみ割り当てるべきです。javaプラグインを適用するとビルドエラーが発生します。
注意：sdk.dir プロパティを使用して、既存の SDK が要求するのと全く同じ方法でSDKの位置を設定するために local.properties ファイルが必要となります。あるいは、ANDROID_HOME と呼ばれる環境変数を設定することができます。
基本のビルドファイルは上記のデフォルトのフォルダ構造を期待します。Gradle は設定の慣習の概念に従い、可能な時はデフォルトのオプションの値を知覚可能なものとして提供します。
基本プロジェクトは、"ソースセット"と呼ばれる2つのコンポーネントから開始します。メインソースコードとテストコードです。これらはそれぞれ以下に存在します：
これらのフォルダの中にそれぞれのソースコンポーネントが存在します。JavaとAndroidプラグインの両方に、JavaのソースコードとJavaのリソースがあります：
Androidプラグインには、Android向けの追加のファイルやフォルダがあります：
注意：src/instrumentTest/AndroidManifest.xml は自動的に生成されるため特に必要としません。
デフォルトのプロジェクトが適切でない時は変更することができます。Gradleのドキュメントによると、Javaプロジェクトのソースセットの変更は以下のように実行できます：
sourceSets {
main {
java {
srcDir 'src/java'
}
resources {
srcDir 'src/resources'
}
}
}
注意：srcDir は既存のソースフォルダリストにフォルダーを実際に追加します（これはGradleのドキュメントでは明示されていませんが、実際の挙動です。）
デフォルトソースフォルダをリプレースするには、パスの配列の代わりにsrcDirsを使用します。これはまた関係のあるオブジェクトの使い方で別の方法を示します：
sourceSets {
main.java.srcDirs = ['src/java']
main.resources.srcDirs = ['src/resources']
}
さらなる情報については、Java plugin の Gradle ドキュメントをご覧ください。
Android プラグインは同様のシンタックスを使用しますが、自身のsourceSetsを使用するため android のオブジェクト内で実施します。メインコードの古いプロジェクト構造を使用して、instrumentTest sourceSet をテストフォルダに再マッピングする例を示します：
android {
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
instrumentTest.setRoot('tests')
}
}
注意：古い構造は全てのソースファイル（Java, AIDL, レンダースクリプト, Javaのリソース）を同じフォルダに格納するため、これら全てをsourceSetの新しいコンポーネントとして同じsrcフォルダに再マップしなければなりません。
注意：setRoot() は全体の sourceSet(とサブフォルダ）を新しいフォルダーに移動します。これは src/instrumentTest/* から tests/* に移動します。これは Android 特有のもので Java の sourceSetsでは動作しません。
ビルドファイルにプラグインを適用すると、ビルドタスクのセットを自動的に生成します。JavaプラグインとAndroidプラグインの両方で実施します。
タスクの慣習は以下の通り：
タスクのアセンブル、チェック、ビルドでは、実際には何もしません。これらはプラグインのためのアンカータスクで、実際に仕事をするタスクを追加するためのものです。
これは、プロジェクトのタイプが何であっても、あるいは、どのプラグインが適用されていても関係なく、同じタスクを常に呼び出すことを可能にします。例えば、checkタスクが呼ばれていても、findbugsプラグインが適用すると新しいタスクを生成し、依存関係をチェックし、呼び出されます。
コマンドラインから以下を実行することで、高レベルタスクの実行を取得できます：
gradle tasks
タスク実行中に全てのリストと依存性を見るには：
gradle tasks --all
注意：Gradleはタスクの入出力の宣言を自動的にモニタします。
変更なしにビルドが2回実行すると全てのタスクが最新であると Gradle はレポートしますが、これは要求される動作がないことを意味します。これは、余計なビルドの操作を必要とせずに、タスクがお互いに依存することを許します。
Java プラグインは2つの主なタスクを生成します。これはメインアンカータスクに依存します：
jarタスク自身は、直接的あるいは間接的に他のタスクに依存します：インスタンスのクラスは Javaのコードをコンパイルします。
テストはテストクラスでコンパイルされますが、テストが（クラスと同様に）自身に依存するため、これを呼び出すことは有用ではありません。
一般的に、assemble と check のみ呼び出し、その他のタスクは無視されるでしょう。
全てのタスクセットとJava プラグインの説明はこちらを御覧ください。
Androidプラグインは他のプラグインと互換性を保つため、同じルールを使用し、アンカータスクを追加します：
デバイスに接続することを必要としない一般的なチェックを実行するために、新しいアンカータスクは必要とされています。
ビルドが deviceCheck または connectedCheck に依存しないことに注意してください。
Androidプロジェクトは少なくとも2つの出力を保持します：デバッグAPKとリリースAPKです。
明確に分けてビルドするために、それぞれは自身のアンカータスクを持っています：
これらは両方とも、タスクがAPKをビルドするために複数のステップを実行する他のタスクに依存しています。
assemble タスクは両方に依存していており、両方のAPKをビルドします。
Tip: Gradleは コマンドライン上でタスク名としてキャメルケースをサポートします。例えば：
gradle aR
これは、'aR’にマッチするタスクが他になければ、次のようにタイプすることと同じです
gradle assembleRelease
check アンカータスクは自身の依存性を有しています：
最後に、プラグインはインストール可能な限り（署名を要求します）、全てのビルドタイプ（debug, release, test）のインストール／アンインストールタスクを生成します。
Android プラグインは、ビルドシステムから直接的に多くのものをカスタマイズするために、広域のDSLの提供します。
DSLを通じて、以下のマニフェストのエントリを変更することができます：
例：
android {
compileSdkVersion 15
defaultConfig {
versionCode 12
versionName "2.0"
minSdkVersion 16
targetSdkVersion 16
}
}
defaultConfig要素は、android要素の中にあり、全ての設定が定義されます。動的にビルドファイルに記述することができます。
例えば、どこかのファイルからバージョン名読み出したり、カスタムのロジックを使用することができます：
def getVersionName() {
...
}
android {
compileSdkVersion 15
defaultConfig {
versionCode 12
versionName getVersionName()
minSdkVersion 16
targetSdkVersion 16
}
}
DSLを通じてプロパティをセットしていない場合、デフォルト値が使用されます。以下はこれがどのように処理されるかを示す表です。
| プロパティ名 | DSLオブジェクトのデフォルト値 | デフォルト値 |
|---|---|---|
| versionCode | -1 | 存在する場合はマニフェストの値 |
| versionName | null | 存在する場合はマニフェストの値 |
| minSdkVersion | -1 | 存在する場合はマニフェストの値 |
| targetSdkVersion | -1 | 存在する場合はマニフェストの値 |
| packageName | null | 存在する場合はマニフェストの値 |
| testPackageName | null | アプリのパッケージ名 + “.test” |
| testInstrumentationRunner | null | android.test.InstrumentationTestRunner |
| signingConfig | null | null |
| proguardFile | N/A (設定のみ) | N/A (設定のみ) |
| proguardFiles | N/A (設定のみ) | N/A (設定のみ) |
これらのプロパティを実行するビルドスクリプトでロジックをカスタムする場合、2つ目のカラムの値は重要です。
例えば、次のように書くことができます：
if (android.defaultConfig.testInstrumentationRunner == null) {
// assign a better default...
}
値が null のままの場合、ビルド時にカラム3から実際のデフォルト値でリプレースされますが、DSL要素がこのデフォルト値を有していないので再び実行することはできません。これは実際に必要のないマニフェストがパースされることを防ぎます。
アプリのデバッグとリリースの両方のバージョンをビルドするために、デフォルトではAndroidプラグインは自動的にプロジェクトをセットアップします。これらは大抵セキュア（devでない）デバイス上で、アプリをデバッグする能力やAPKの署名方法で違いがあります。
キーまたは証明書によって署名されたデバッグバージョンは、よく知られた名前／パスワードで自動的に生成されます（ビルド中にプロンプトを要求されることを防ぐため）。リリースはビルド中では署名を行わず、後で必要になります。
この設定は、ビルドタイプと呼ばれるオブジェクトを通じて実行されます。デフォルトでは、デバッグとリリースの2つのインスタンスが生成されます。
Androidのプラグインはその他のビルドタイプの生成と同様に2つのインスタンスをカスタマイズすることを許します。これは、ビルドタイプのDSLコンテナで実行します：
android {
buildTypes {
debug {
packageNameSuffix ".debug"
}
jnidebug.initWith(buildTypes.debug)
jnidebug {
packageNameSuffix ".jnidebug"
jnidebugBuild true
}
}
}
上記スニペットは以下をアーカイブします：
新しいビルドタイプの生成は新しい要素を使用することと同じぐらい簡単で、ビルドタイプコンテナ下で initWith() を呼び出すかクロージャで設定します。
可能なプロパティとデフォルト値は：
| プロパティ名 | デバッグ用のデフォルト値 | リリース／その他のデフォルト値 |
|---|---|---|
| debuggable | true | false |
| jniDebugBuild | false | false |
| renderscriptDebugBuild | false | false |
| renderscriptOptimLevel | 3 | 3 |
| packageNameSuffix | null | null |
| versionNameSuffix | null | null |
| signingConfig | android.signingConfigs.debug | null |
| zipAlign | false | true |
| runProguard | false | false |
| proguardFile | N/A (設定のみ) | N/A (設定のみ) |
| proguardFiles | N/A (設定のみ) | N/A (設定のみ) |
これらのプロパティに加えて、ビルドタイプはコードとリソースをビルドするのに役立てることができます。
それぞれのビルドタイプのために、新しくマッチした sourceSet がデフォルトの位置と共に生成されます
src/<buildtypename>/
これはビルドタイプ名が main または instrumentTest ではなく（これはプラグインによって強いられます）、お互いにユニークである必要があることを意味します。
その他のソースセットのように、ビルドタイプソースセットの位置は再配置可能です：
android {
sourceSets.jnidebug.setRoot('foo/jnidebug')
}
加えて、それぞれのビルドタイプは 新しい <BuildTypeName> アセンブルタスクを生成します。
assembleDebug と assembleRelease タスクは、既に言及されています。debug と release ビルドタイプは予め作成された時、同様にタスクも自動的に作成されます。
上記のbuild.gradleスニペットはさらに assembleJnidebug タスクを生成し、assembleDebug と assembleRelease タスクに依存するように、同じ方法に依存する形でアセンブルされるでしょう。
Tip: gradle aJ で assembleJnidebug タスクが実行できることを覚えておいてください。
使用可能なユースケース：
ビルドタイプのコード／リソースは以下の方法で使用されます：
アプリケーションの署名に必要なものは以下の通り：
キーネームと同じように位置は、パスワードとストアタイプによって署名設定を形成します（SigningConfigタイプ）
デフォルトでは、デバッグ設定はよく知られたパスワードと良く知られたパスワードを用いたデフォルトのキーによる、デバッグキーストアでセットアップされています。
デバッグキーストアは、$HOME/.android/debug.keystore に格納されており、なければ生成されます。
デバッグビルドタイプは、この debug SigningConfig を自動的に使用します。
その他の設定を作成したり、デフォルトで内蔵されているものをカスタマイズすることが可能です。これは、signingConfigs DSL コンテナを通じて行います。
android {
signingConfigs {
debug {
storeFile file("debug.keystore")
}
myConfig {
storeFile file("other.keystore")
storePassword "android"
keyAlias "androiddebugkey"
keyPassword "android"
}
}
buildTypes {
foo {
debuggable true
jniDebugBuild true
signingConfig signingConfigs.myConfig
}
}
}
上記のスニペットは、デバッグキーストアの位置をプロジェクトのルートに変更するものです。自動的にこれを使用するビルドタイプに影響を与えます。このケースの場合、 debug Build タイプです。
また、新しい Signing Config と 新しいビルドタイプを生成し、新しい設定を利用します。
注意：デフォルトの場所のデバッグキーストアだけが自動的に生成されます。デバッグキーストアの位置を変更すると、オンデマンドで生成されんくなります。違う名前でSigningConfigを生成すると自動的にデフォルトのデバッグキーストアを使用します。
言い換えると、キーストアの位置が強く結びついており、設定名ではありません。
注意：キーストアの位置は大抵はプロジェクトのルートから相対的なもので、絶対パスはオススメできません。（自動的に生成される debugキーストアを除く）。
バージョン0.4から、ProGuardはProGuardバージョン4.9向けGradleプラグインを通じてサポートされています。
ビルドタイプが runProguard プロパティを通じてProGuardが設定されている場合、ProGuardプラグインは自動的に適用され、タスクは自動的に生成されます。
android {
buildTypes {
release {
runProguard true
proguardFile getDefaultProguardFile('proguard-android.txt')
}
}
productFlavors {
flavor1 {
}
flavor2 {
proguardFile 'some-other-rules.txt'
}
}
}
変数はこれらのビルドタイプとプロダクトフレーバーに定義されている全てのルールファイルを使用します。
2つのデフォルトルートファイルがあります。
これらは SDK に格納されています。getDefaultProguardFile() を使用して、ファイルのフルパスを返します。これらは最適化が有効になることを除いて全く同一です。
Gradleプロジェクトは他のコンポーネントへの依存性を持つことができます。これらコンポーネントは外部のバイナリパッケージや他のGradleプロジェクトです。
外部ライブラリのjarに依存する設定のため、コンパイル設定上の依存性を追記する必要があります。
dependencies {
compile file('libs/foo.jar')
}
android {
...
}
注意：DSL要素は標準 Gradle API の一部で、android の要素中には属しません。
コンパイルの設定は、メインアプリケーションをコンパイルするために使用されます。全てコンパイルのクラスパスとして追加され、APKにも含まれます。
これらは依存性を追加する他の使用可能な設定です：
関連するビルド・タイプがないAPKを構築することが不可能なため、APKは常に2つ（以上）の設定を有します：
compile and <buildtype>Compile.
新しいビルドタイプを生成すると、自動的に名前をベースとした新しい設定を生成します。
これはデバッグバージョンが（インスタンスのクラッシュを報告するなどで）カスタムライブラリが必要である一方、リリースでは必要がない時や同じライブラリの異なるバージョンに依存する場合に使用するのに便利です。
Gradle は Maven と Ivy リポジトリからアーティファクトをpullすることをサポートしています。
最初にリポジトリはリストに追加しなければなりません。その後、依存性は Maven または Ivy が宣言するアーティファクトに従って宣言される必要があります。
repositories {
mavenCentral()
}
dependencies {
compile 'com.google.guava:guava:11.0.2'
}
android {
...
}
注意：mavenCentral はリポジトリのURLを特定するためのショートカットです。Gradle はリモート及びローカルリポジトリの両方をサポートします。
注意：Gradle は全ての依存性において他動的に従うでしょう。これは、依存性が自身の依存性を有する場合、同様にpullされることを意味します。
依存性のセットアップに関するさらなる情報は、Gradleユーザーガイド、および、 DSLドキュメントを参照してください。
Gradleプロジェクトは、複数プロジェクトのセットアップを使用することにより、他のGradleプロジェクトに依存することもできます。
複数プロジェクトのセットアップは、ルートプロジェクトのサブフォルダとして全てのプロジェクトを有することにより、大抵は動作します
例えば、以下のような構造を与えます：
MyProject/
+ app/
+ libraries/
+ lib1/
+ lib2/
3つのプロジェクトを識別することができます。Gradle は以下の名前を参照します：
それぞれのプロジェクトは、自身の build.gradle を持ち、どのようにビルドするかを宣言します。
加えて、settings.gradleと呼ばれるファイルをプロジェクトのルートに宣言します。
これは以下のような構造を与えます：
MyProject/
| settings.gradle
+ app/
| build.gradle
+ libraries/
+ lib1/
| build.gradle
+ lib2/
| build.gradle
settings.gradle のコンテンツは非常にシンプルです：
include ':app', ':libraries:lib1', ':libraries:lib2'
これは、どのフォルダが実際のGradleプロジェクトかを定義します。
:app プロジェクトはライブラリに依存し、以下の依存性を宣言することで実行されます：
dependencies {
compile project(':libraries:lib1')
}
さらなる情報については、複数プロジェクトのセットアップを参照してください。
上記の複数プロジェクトのセットアップで、:libraries:lib1 と :libraries:lib2 は Javaプロジェクト、:app は Android プロジェクトで、jarの出力を使用します。
しかし、Android API または Android スタイルのリソースへのアクセスをするコードをシェアしたい場合、Androidライブラリプロジェクトでなければなりません。
ライブラリプロジェクトは、一般的な Android プロジェクトが若干の違いを持っていることに似ています。
ライブラリのビルドはアプリケーションのビルドとは異なるため、異なるプラグインが使用されます。
内部的には、両方のプラグインが同じコードの大部分を共有し、これらは同じ com.android.tools.build.gradle jar を提供します。
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.4.2'
}
}
apply plugin: 'android-library'
android {
compileSdkVersion 15
}
これは コンパイルのために API 15 を使用するライブラリプロジェクトを生成します。
ソースセットと依存性は、アプリケーションプロジェクトと同じように、同じ方法でカスタマイズすることができます。
ライブラリプロジェクトは APKを生成せず、（Androidアーカイブを表す）.aar パッケージを生成します。同一のアンカータスクはこれ（assembleDebug, assembleRelease）のために使用されます。そのため、そのようなプロジェクトを構築するコマンドに違いはありません。
ライブラリプロジェクトはまた、テスト APK を（テストの章をご覧ください）生成します。しかし、これはスコープとビルドタイプの使い方はさらに制限されています。これらのプロジェクトは２つのビルドタイプ、debug と release にのみアクセスします。デバッグタイプはテストアプリによって使用されます。リリースタイプはライブラリを使用するプロジェクトによって利用されます。
さらに、APKが生成されるのは一つだけなので、唯一の SigningConfig オブジェクトが存在します。これはテストAPKの署名で使用されます。DSLライブラリプロジェクトは次のようになります：
android {
debug {
...
}
release {
...
}
debugSigningConfig {
storeFile file("debug.keystore")
}
}
ビルドタイプの主な設定は、ライブラリプロジェクトには適用されないことに注意してください。
しかしながら、プロジェクトによって使用されているか、テストされているかによって、ライブラリの内容を変更するカスタムソースセットを使用することができます。
ライブラリの参照は、参照された他のプロジェクト同じように実行することができます：
dependencies {
compile project(':libraries:lib1')
compile project(':libraries:lib2')
}
注意：一つ以上のライブラリを有する場合、順序は重要です。これは、project.properties ファイルの依存性の順序が重要な旧ビルドシステムと同様です。
テストアプリケーションのビルドは、アプリケーションプロジェクトに統合されています。テストプロジェクトを分ける必要はありません。
前節で示したように、mainのソースセットの次はinstrumentTestソースセットで、デフォルトでは src/instrumentTest/ に配置されています。このソースセットから、Android instrumentation フレームワークを使用して、アプリケーションをテストするためにデバイスにデプロイされる、テストAPKがビルドされます。ソースセットには AndroidManifest.xml を含めるべきではありません。なぜなら、自動的に生成されるためです。
テストアプリ用に設定可能ないくつかの値があります。
前に示した通り、これらは defaultConfig オブジェクトで設定されます：
android {
defaultConfig {
testPackage "com.test.foo"
testInstrumentationRunner "android.test.InstrumentationTestRunner"
}
}
defaultConfig および/または ビルドタイプオブジェクトの設定に関わらず、テストアプリケーションマニフェスト中の、instrumentation ノードの targetPackage の属性値は、テストされるアプリのパッケージ名で自動的に埋められます。これは自動的にマニフェストが自動的に生成される理由の一つとなっています。
加えて、ソースセットは依存性を持つように設定することができます。デフォルトでは、アプリケーションとその依存性はテストアプリのクラスパスに追加されますが、これは以下の方法で拡張することができます。
dependencies {
instrumentTestCompile 'com.google.guava:guava:11.0.2'
}
テストアプリは assembleTest タスクによってビルドされます。これは メインの assemble タスクには依存せず、代わりにテストが実行される際に自動的に呼び出されます。
現在は1つのビルドタイプのみテストされます。デフォルトでは、debug ビルドタイプのみですが、これは以下のように再設定することができます。
android {
...
testBuildType "staging"
}
前に示したように、deviceCheck と呼ばれる一番最後のタスクによって起動された接続済み端末を要求することをチェックします。これは instrumentTest タスクに依存しており、これにより実行されます。このタスクは次のことを実行します：
もし、1つ以上の端末が接続されている場合、全てのテストは並列に全て接続済み端末上で実行されます。いずれかの端末上でテストが失敗したら、ビルドは失敗します。
全てのテスト結果は build/instrumentTest-results 下の XML ファイルに格納されます。（これは、build/test-results 下に格納される一般的な jUnit の結果と似ています。）
これは以下のように設定することができます。
android {
...
testOptions {
resultsDir = "$project.buildDir/foo/results"
}
}
android.testOptions.resultsDir の値は Project.file(String) で評価されます。
Android のライブラリプロジェクトのテストは、アプリのプロジェクトと全く同一の方法で行います。
唯一の違いは、全体のライブラリ（とその依存性）が、テストアプリに対してライブラリの依存性として自動的に付加されることです。
結果は、テストAPK自身コードではなく、ライブラリとその全ての依存性を含んでいる、テストAPKです。ライブラリのマニフェストは、テストアプリのマニフェストにマージされています（このライブラリを参照するプロジェクトのケースとして）。
instrumentTest タスクはテストAPKのインストール（とアンインストール）時のみ変更されます（インストールする他のAPKがないため）。
その他は全て同一です。
ユニットテストの実行時、Gradle は 結果が容易に分かるように HTMLのレポートを出力します。Android のプラグインは これをビルドし、全ての接続済み端末の結果を集計するために HTML のレポートを拡張します。
プロジェクトはテストの実行で自動的に生成されます。デフォルトの配置場所は build/reports/instrumentTests です。これは build/reports/tests にある jUnit のレポート の配置場所、あるいは、 build/reports/<plugin>/ の中によくある、他のレポートの配置場所に似ています。
配置場所は以下のようにして変更することができます。
android {
...
testOptions {
reportDir = "$project.buildDir/foo/report"
}
}
レポートは異なる端末で実行された複数のテストを集計します。
複数のアプリケーションとライブラリのプロジェクトを伴う複数プロジェクトのセットアップは、同時に全てのテストが実行される時に、全ての instrumentation テストを単一の結果として生成するのに便利です。
これを実施するために、同じ生成物の中で、異なるプラグインを使用できるようにします。それは以下のようにして適用します：
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.3'
}
}
apply plugin: 'android-reporting'
これは settings.gradle の次の build.gradle の中でなど、ルートプロジェクトで適用すべきです。この時、ルートフォルダーから、以下のコマンドラインで全てのテストを実行し、結果を集計します：
gradle deviceCheck mergeAndroidReports --continue
注意： --continue オプションは全てのテストを保証し、例えば一部のテストが失敗しても全てのサブプロジェクトは実行されます。このオプションがなければ、最初のテストの失敗時にテストの実行は中断され、全てのテストは実行されません。
まだサポートしていません。しばし待たれよ。
新しいビルドシステムのゴールのひとつは、同じアプリケーションの異なるバージョンの生成を有効にすることです。大きく２つのユースケースがあります：
ゴールは、単一のライブラリプロジェクトと2つ以上のアプリケーションプロジェクトを使用することとは対照的に、同じプロジェクトからこれらの異なるAPKを生成することです。
プロダクトフレーバーは、プロジェクトによりビルドするカスタマイズされたアプリケーションのバージョンを定義します。単一のプロジェクトは、生成されたアプリケーションを変える異なるフレーバーを持つことができます。
この新しいコンセプトとは、変更がとても小さい時に便利なように設計されています。「これは同じアプリケーションか？」という問いに対して答えがYesの時、これはおそらくライブラリプロジェクトに関する方法です。
プロダクトフレーバーは、productFravors DSLコンテナを使用して宣言します：
android {
....
productFlavors {
flavor1 {
...
}
flavor2 {
...
}
}
}
これは、flavor1 と flavor2 の2つのフレーバーを生成します。
注意：フレーバーの名前は、既に存在するビルドタイプや instrumentTest ソースセットの名前を衝突してはいけません。
前説で確認したように、それぞれのビルドタイプは新しいAPKを生成します。
プロダクトフレーバーも同じように機能します：プロジェクトの出力は、ビルドタイプと適用可能であればプロダクトフレーバーの両者の全ての可能な組み合わせとなります。
それぞれ（ビルドタイプ、プロダクトフレーバー）の組み合わせは、ビルド変数と呼ばれます。
デフォルトの debug と release ビルドタイプの例では、4つのビルド変数を生成します：
フレーバーのないプロジェクトもまたビルド変数を有します。しかし、単一のデフォルトフレーバー／設定が無名で使用され、ビルドタイプのリストに似た変数のリストを作成します。
各フレーバーはクロージャで設定されます：
android {
...
defaultConfig {
minSdkVersion 8
versionCode 10
}
productFlavors {
flavor1 {
packageName "com.example.flavor1"
versionCode 20
}
flavor2 {
packageName "com.example.flavor2"
minSdkVersion 14
}
}
}
android.productFlavors.* オブジェクトは、android.defaultConfigオブジェクトと同じタイプのプロダクトフレーバータイプのオブジェクトです。これは、同じプロパティを共有することを意味します。
defaultConfig は全てのフレーバーと各フレーバーが任意の値でオーバーライド可能な、基準の設定を提供します。以下の例では次のように解釈されます：
たいていの場合、ビルドタイプ設定は他の設定の上にオーバーレイされます。例えば、ビルドタイプの packageNameSuffix はプロダクトフレーバーの packageName に追加されます。ビルドタイプとプロダクトフレーバーの両方が設定可能なケースがあります。このケースの場合、基本ケースの上にケースが乗っています。例えば、signingConfig はこれらの属性の一つです。
これは、全てのリリースパッケージが android.buildTypes.release.signingConfig によって同じ SigningConfig を共有するか、あるいは、それぞれのリリースパッケージが、android.productFavors.*.signingConfig オブジェクトを個別に設定することで、自身の SigningConfig を使用することを有効にします。
ビルドタイプと同様にプロダクトフレーバーもまた、自身の sourceSets を通じてコードとリソースを提供します。
上記の例は、4つの sourceSets を生成します：
これらの sourceSets は android.sourceSets.main と ビルドタイプの sourceSet と並んで、APK のビルドで使用されます。
以下のルールは、単一の APK をビルドするために全てのソースセットを取り扱う際に使用されます：
最後に、ビルドタイプのようにプロダクトフレーバーは自身の依存関係を持つことができます。例えば、フレーバーが広告ベースのアプリと支払いベースのアプリを生成するために使用される場合、フレーバーの一つは広告SDKに依存し、他はそうしないようにできます。
dependencies {
flavor1Compile "..."
}
特にこの場合は、src/flavor1/AndroidManifest.xml ファイルがインターネット権限を含む必要が、おそらくあるでしょう。
前にそれぞれのビルドタイプは自身の assemble<name> タスクを生成することをみましたが、しかし、そのビルド変数はビルドタイプとプロダクトフレーバーのコンビネーションです。
プロダクトフレーバーの使用時、assemble タイプのタスクが生成されます。これらは以下のようなものがあります。
1は単一の変数を直接ビルドすることを許します。例えば、assembleFlavor1Debug.
2は指定のビルドタイプで全てのAPKをビルドすることを許します。たとえば、assembleDebug は Flavor1Debug と Flavor2Debug の両方の変数をビルドします。
3は指定のフレーバーで全てのAPKをビルドすることを許します。例えば、assembleFlavor1 は Flavor1Debug と Flavor1Release の両方の変数をビルドします。
assemble タスクは、もちろん、全ての使用可能な変数をビルドします。
マルチフレーバープロジェクトのテストは、単純なプロジェクトに非常に似ています。
instrumenTest ソースセットは全てのフレーバーに渡る共通のテストとして使用され、それぞれのフレーバーはまた、自身のテストを持つことが可能です。
上記のように、各フレーバーをテストするためのソースセットは生成されます：
同様に、これらは自身の依存性を持つことができます：
dependencies {
instrumentTestFlavor1Compile "..."
}
テストの実行は、メインの deviceCheck アンカータスクを通じて実施することができます。あるいは、フレーバーが使用される時、アンカータスクとして動作するメインの instrumentTest タスクを通じて実施することができます。
各フレーバーはテストを実行するために自身のタスクを持ちます：instrumentTest<変数名>
例えば、
同様に、テストAPKはタスクをビルドし、変数ごとにインストール/アンインストールタスクがあります。
...
最後に、HTMLレポートの生成は、フレーバーの集まりをサポートします。
テスト結果とレポートの場所は以下の通りです。最初はフレーバーのバージョンごとで、その後一つにまとめられます。
それぞれのパスの変更は、ルートのフォルダーを変更するのみです。フレーバーごとのサブフォルダーは生成されたままで、結果やレポートはそこに集められます。
ある場合では、一つ以上の基準で、同じアプリの異なるバージョンを作りたいかもしれません。
例えば、Google PlayがサポートするマルチAPKは4つの異なるフィルターがサポートされています。それぞれのフィルターにあわせて異なるAPKを分けて生成するには、1つ以上のプロダクトフレーバーが使用できることが求められます。
デモ版と有料版のゲームで、マルチAPKサポートでABIフィルターを利用したい場合の例を考えてください。3つのABIと2つのアプリケーションのバージョンがあると、APKは6つ生成しなければなりません（異なるビルドタイプによる変数はカウントしていません）。
しかし、有料版は3つのABIが同一なので、単純に6つのフレーバーを作成することはしません。その代わり2次元のフレーバーと変数で、可能な限りの組み合わせを自動的に利用すべきです。この機能はフレーバーグループで実装されています。それぞれのグループは次元を表現し、フレーバーは特別なグループに対してアサインされます。
android {
...
flavorGroups "abi", "version"
productFlavors {
freeapp {
flavorGroup "version"
...
}
x86 {
flavorGroup "abi"
...
}
}
}
android.flavorGroups の配列は順序と共に使用可能なグループを定義します。それぞれはグループにアサインされたプロダクトフレーバーを定義します。
プロダクトフレーバー[freeapp,paidapp]と[x86,arm,mips]、ビルドタイプ[debug,release]でグループ化されて、以下のビルド変数が生成されます：
android.flavorGroups で定義されたグループの順番は非常に重要です。
それぞれの変数はいくつかのプロダクトフレーバーで設定されます：
フレーバーの値が、優先順位の低いフレーバーの値を上書きする時、グループの順番はその他でオーバーライドされたフレーバーを操作しますが、これはリソース面で非常に重要です。
フレーバーグループは優先順位の高く定義されます。以下のようなケースが成り立ちます：
abi > version > defaultConfig
android {
compileOptions {
sourceCompatibility = "1.6"
targetCompatibility = "1.6"
}
}
デフォルト値は “1.6” です。Java ソースコードをコンパイルする全てのタスクに影響します。
android {
aaptOptions {
noCompress 'foo', 'bar'
ignoreAssetsPattern "!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~"
}
}
これは aapt を使用する全てのタスクに影響します。
android {
dexOptions {
incremental false
}
}
これは dex を使用する全てのタスクに影響します。デフォルトは true。
基本的な Java プロジェクトは有限のタスクセットを保持しており、出力を生成するように動作します。Java ソースコードをコンパイルする classes タスクもその一つです。
スクリプト中で classes を単に使用して、build.gradle からアクセスするのは容易です。これは project.tasks.classes のショートカットです。
Android プロジェクトでは、同じタスクや Build Typesand Project Flavorsに基づいて生成される名前が数多くあることから、もう少し複雑になっています。これを確定するために、android オブジェクトは以下のプロパティを持っています：
それぞれ、ApplicationVariant, LibraryVariant, TestVariant オブジェクトの DomainObjectCollection を戻します。
各々のコレクションへのアクセスは、全てのタスクの生成のトリガとなることに注意してください。これは、コレクションのアクセス後に（再）設定すべきではないことを意味します。
DomainObjectCollection は、全てのオブジェクトに直接 または 便利なフィルタを通じてアクセスする方法を付与します。
android.buildVariants.each { variant ->
....
}
3つ全てで共有するプロパティは以下の通り：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| name | String | 変数名。ユニークであることが保証されます。 |
| description | String | 人間が読むことができる変数の説明。 |
| dirName | String | 変数名のサブフォルダ。ユニークであることが保証されます。'debug/flavor1'のように1つ以上になる可能性 |
| baseName | String | 変数の出力の基本名。ユニークであることが保証されます。 |
| outputFile | File | 変数出力。これは読み込み／書き込みプロパティです。 |
| processManifest | ProcessManifest | マニフェストを処理するタスク |
| aidlCompile | AidlCompile | AIDLファイルをコンパイルするタスク |
| renderscriptCompile | RenderscriptCompile | レンダースクリプトファイルをコンパイルするタスク |
| mergeResources | MergeResources | リソースをマージするタスク |
| mergeAssets | MergeAssets | アセットをマージするタスク |
| processResources | ProcessAndroidResources | 処理とリソースのコンパイルをするタスク |
| generateBuildConfig | GenerateBuildConfig | ビルドコンフィグクラスを生成するタスク |
| javaCompile | JavaCompile | Javaのコードをコンパイルするタスク |
| processJavaResources | Copy | Javaのリソースを処理するタスク |
| assemble | DefaultTask | この変数のアセンブルアンカータスク。 |
ApplicationVariant クラスは下記を追加します：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| buildType | BuildType | 変数のビルドタイプ |
| productFlavors | List<ProductFlavor> | 変数のプロダクトフレーバー。常にNullは許容されないが、空は許容される。 |
| mergedFlavor | ProductFlavor | android.defaultConfig と variant.productFlavors をマージしたもの。 |
| signingConfig | SigningConfig | 変数によって使用される SigningConfig オブジェクト |
| isSigningReady | boolean | 変数が署名のための必要な情報を全て有しているとき true |
| testVariant | BuildVariant | 変数によってテストされるビルド変数 |
| dex | Dex | dexコードのタスク。変数がライブラリならnullにできる。 |
| packageApplication | PackageApplication | 最終APKを生成する。変数がライブラリならnullにできる。 |
| zipAlign | ZipAlign | zipalignsのAPKのタスク変数がライブラリまたはAPKに署名されていない場合はnullにできる。 |
| install | DefaultTask | インストールタスク。null可。 |
| Uninstall | DefaultTask | アンインストールタスク |
LibraryVariant クラスは下記を追加します：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| buildType | BuildType | 変数のビルドタイプ |
| config | ProductFlavor | defaultConfigの値 |
| testVariant | BuildVariant | 変数によってテストされるビルド変数 |
| packageLibrary | Zip | AARアーカイブライブラリのパッケージのタスク。ライブラリでない場合はnull。 |
TestVariant クラスは下記を追加します：
| プロパティ名 | プロパティタイプ | 説明 |
|---|---|---|
| buildType | BuildType | 変数のビルドタイプ |
| productFlavors | List<ProductFlavor> | 変数のプロダクトフレーバー。常にNullは許容されないが、空は許容される。 |
| mergedFlavor | ProductFlavor | android.defaultConfig と variant.productFlavors をマージしたもの。 |
| signingConfig | SigningConfig | 変数によって使用される SigningConfig オブジェクト |
| isSigningReady | boolean | 変数が署名のための必要な情報を全て有しているとき true |
| testVariant | BuildVariant | 変数によってテストされるビルド変数 |
| dex | Dex | dexコードのタスク。変数がライブラリならnullにできる。 |
| packageApplication | PackageApplication | 最終APKを生成する。変数がライブラリならnullにできる。 |
| zipAlign | ZipAlign | zipalignsのAPKのタスク変数がライブラリまたはAPKに署名されていない場合はnullにできる。 |
| install | DefaultTask | インストールタスク。null可。 |
| Uninstall | DefaultTask | アンインストールタスク |
| connectedInstrumentTest | DefaultTask | 接続されたデバイス上のinstrumentationテストを実行するタスク |
| providerInstrumentTest | DefaultTask | 拡張APIを使用するinstrumentation テストを実行するタスク |
Android 専用タスクタイプのAPIは次の通り。
それぞれのタスクタイプ用APIは、Gradle の振る舞いと Android プラグインをセットアップの振る舞いの両方に限定されます。
最初に、Gradleは入出力の位置と使用可能なフラグのみを設定するタスクを持つことが目的です。そのため、タスクは（いくつかの）入出力のみを定義します。
2番目に、これらのタスクの多くの入力は自明ではなく、sourceSets やビルドタイプ、プロダクトフレーバーから値をミックスしたものになります。読んだり理解するためにシンプルなビルドファイルを維持するため、開発者がDSLを通じてこれらのオブジェクトを操作しビルドを編集させることが目的です。
加えて、ZipAlign タスクタイプを除いて、全てのタイプはこれら作業のためのプライベートなデータをセットアップすることを要求します。
このAPIは変更の対象です。一般的に現在のAPIは、出力と、追加で他の処理が必要なタスクの入力（可能なら）にアクセスする権利を与えます。特に予期しなかったもので必要に応じて、フィードバックは評価されます。
Gradleタスク（DefaultTask, JavaCompile, Copy, Zip) については、Gradleのドキュメントを参照ください。
乞うご期待。
文責：株式会社ブリリアントサービス 品川事業所 八木俊広、瀬戸直喜(@Lionas)
Android KitKat Hacks プロが教えるテクニック & ツール
株式会社ブリリアントサービス 著
NFC Hacks プロが教えるテクニック＆ツール
株式会社ブリリアントサービス 著
Androidプログラミングの教科書
藤田 竜史、要 徳幸、住友 孝郎、日高 正博、小林 慎治、木村 尭海 著
入門Androidアプリケーションテスト
瀬戸 直喜／株式会社ブリリアントサービス 著
実践スマートフォンアプリケーション開発
株式会社ブリリアントサービス、八木 俊広、原 昇平、かわかみ ひろき 著
ジオモバイルプログラミング
郷田まり子／宅間俊志／近藤昭雄 著
ANDROID HACKS プロが教えるテクニック＆ツール
株式会社ブリリアントサービス 著
