はじめに

第3回でさっと説明したままずーっと放置してきたプロジェクトの実行方法について説明します。肝心のこの方法を38回目になるまでほとんど説明せずに進めてきたなと我ながら感心します。

実行構成について

Android Studioのプロジェクトの実行方法は「Run/Debug Configuration」という機能を用いて行います。ちょっと名称が長いので本連載では「実行構成」と呼びます。

ツールバーのちょうど真ん中当たりにあるドロップダウンリストが実行構成です。

常時ツールバーに表示されている実行構成がカレントの実行構成です。隣にある2つのアイコンで、それぞれ通常の実行（"Run"⁠）⁠、デバッグ実行（"Debug"）を行うことができます。デバッグ実行については、次回改めて説明するので今回は割愛します（その隣にある3つ目のアイコンも次回へ⁠）⁠。メニューバーから実行する場合は、Runメニューの"Run"を選択します。

Android Studioでプロジェクトを作成すると、初めから1つ実行構成が作成済みなので、あまり意識したことは無いかと思いますが、ツールバーのドロップダウンリストか、メニューバーのRunメニューから "Edit Configurations..." を選ぶと実行構成の編集画面が表示されます。

この実行構成については、Eclipseにも似たような機能があるので、Eclipseからの移行組には違和感が無いのでは？と思います。

実行構成の編集

「Run/Debug Configurations」ダイアログの使い方について説明します。左側にはカテゴリ別に利用可能な実行構成がリストアップしてあります。初期状態では、図3のような状態になっています。

「Android Application」カテゴリの実行構成「app」が設定済みです。この実行構成は「モジュールappのデフォルトAPKをデプロイして、デフォルトのアクティビティを実行する」という設定になっています。Android Studioでは、この実行構成を目的・用途別に複数用意しておくことができます。

実行構成は「永続的な実行構成」と「一時的な実行構成」の2種類あります。この違いは実行構成の作り方によって決まります。

永続的な実行構成

「Run/Debug Configurations」で明示的に作成した実行構成のことを指します（エディタ上のコンテキストメニューから「Create 」を実行しても同じです⁠）⁠。

一時的な実行構成

Android Studioでは、プロジェクトの実行指示をとてもカジュアルに行うことができます。アクティビティやテストケースなど、実行可能なソースコードをエディタ上で編集している際にコンテキストメニューから「Run 」や「Debug 」を選択するだけで対象を実行することができます。

この方法で作られた実行構成を「一時的な実行構成」と呼びます。「⁠永続的な実行構成」と比べると実行構成のアイコンが薄くなっているのが特徴です。

「一時的な実行構成」はその数の上限が決まっており、一定数を超えると古い実行構成から消えていきます。これは、JUnitなどのテストケースを特定のクラスだけ／特定のメソッドだけ、などのようにカジュアルに実行していくことを想定しての機能なのですが、Android開発でこの機能が有意義に活用されるのか？というと疑問が残ります。

なお「一時的な実行構成」の上限は「Run/Debug Configurations」ダイアログの左側にある「Defaults」を選択したときに右側の下部に表示される「Temporary configurations limit」で設定できます。

さらに「一時的な実行構成」は以下の手順で「永続的な実行構成」に格上げすることができます。

1. ツールバーのドロップダウンリストから「Save Configuration」を選択する

もしくは、

1. 「Run/Debug Configurations」ダイアログから該当する実行構成を選択する
2. 左側上部のツールバーに「 Save Configuration」が現れるので、これをクリックする

です。でも、こんな手順、ふつう気がつきませんよね……。

永続的な実行構成の作り方（指定可能なカテゴリについて）

一時的な実行構成の作成はコンテキスト依存であるため、そのカテゴリは自動的に設定されます。永続的な実行構成の場合は「Run/Debug Configurations」ダイアログからカテゴリを指定して作成します。

「Run/Debug Configurations」ダイアログの左側上部にある「＋」アイコンをクリックすると選択可能なカテゴリがポップアップするので、そこから任意のカテゴリを選択して実行構成を作成します。

選択可能なカテゴリは数多くありますが、Android Studioで意味があるカテゴリは「Android Application」と「Android Test」の2種類のみです（あと「Gradle」くらい⁠）⁠。他のカテゴリはほぼ無意味と思って良いです。

Android Application

Androidアプリケーションの実行構成に用います。「⁠Module」に実行したいAndroidモジュールを指定します。元々、独自にAndroid開発をサポートしていたIntelliJが用意していたカテゴリです。そのためか「Package」にデプロイするAPKを指定できそうなのですが、Android Studioでは「Project Structure」で任意の「Artifact（成果物⁠）⁠」を定義できないため、実質「Deploy custom artifact」は意味を成しません。

Android Tests

後述するAndroidテストの実行構成に用います。「⁠Module」にAndroidテストが含まれるモジュールを指定し、「⁠Test」にテストケースの種別（すべて／特定のパッケージ配下／特定のクラス／特定のメソッド）を指定します。

「Android Tests」の実行構成は「Run/Debug Configurations」ダイアログで作成するより、テストディレクトリやテストケースから直接作成する事のほうが多いでしょう。その手順についても後述します。

JUnitやTestNGなど、その他のカテゴリ

Android ApplicationやAndroid Tests以外にも数多くのカテゴリがあります。どれも利用可能かと期待に胸を膨らませがちですが、ほとんどがIntelliJの名残で残っているものばかりで、実行するには「それなりの」知恵と工夫が必要です。

この、その他大勢のカテゴリに興味があり使ってみたいのであれば、Android Studio上であれこれ知恵を絞るより、素直にIntelliJを使った方が良いでしょう。

Defaultsについて

「Run/Debug Configurations」ダイアログに現在有効な実行構成と一緒に並んでいる「Defaults」ですが、これらは各実行構成のカテゴリの デフォルト値 を設定するために存在しています。辺鄙なところに唐突に「Defaults」とあって「なんだこれ？」と思いがちですが、他に適した置き場がなかったのでしょう。

実行構成を作成するたび、毎回設定しなおすのが面倒な項目があれば、こちらにあらかじめ設定しておくと良いです。ただ、これがまた悲しいことに「Defaults」で設定した内容は .idea/workspace.xml に保存されます。つまり、いくらマメにデフォルト設定を行っても、その内容は他のプロジェクトや他の環境に引き継がれることはありません。

Androidアプリケーションの実行

実行構成の使い方はAndroid Studioの初期バージョンの頃から何も変わっていないので、第3回で紹介した方法が今も通用します。ツールバーの「 Run」アイコンを押すだけです。

いちいちマウスを使うのが面倒な方はメニューバーの「Run → Run 」を、実行構成を選択してから実行したい場合は「Run → Run...」を選択してください。どちらもショートカットキーが割り当てられています。

Androidアプリケーションの実行環境はエミュレータと実機の2つが選択可能ですが、正直エミュレータは遅くて使い物になりません。可能ならば実機を用いることをオススメします（筆者は、この記事のために安い中華Padを購入しました⁠）⁠。

エミュレータが遅いのはAndroid Studioのせいというより、Android SDKのせいみたいです。どうやらこうゆうものらしいですね。

Androidツールウィンドウの使い方

Androidアプリケーションを実行すると「Androidツールウィンドウ」がアクティブになります。このツールウィンドウ、中身はまんまDDMS（Dalvik Debug Monitor Service）です。Android StudioはEclipseのような「パースペクティブ」という概念を持ちません。Eclipse ADTのDDMSパースペクティブに相当するのが「Androidツールウィンドウ」だと理解してください。

この「Androidツールウィンドウ」ですが、初期状態は図17のようなレイアウトになっていると思います。

タブが2つあり、ひとつはLogcatを表示し、もう一方がADB（Android Device Bridge）のログを表示しています。Logcatのタブは、さらにDevicesタブとLogcatタブに分かれおり、全部で3つのタブから成り立っています。

このツールウィンドウのタブは実に特殊で、よーくみるとタブの右端に「隠す（Hide⁠）⁠」アイコンが付いています。これをクリックすると、そのタブは上部ツールバーの右側にアイコン化されます。

「使用頻度の低いタブは畳んでおけ」という配慮なのでしょうか？正直どうでもいい機能だなと思っています。

それより注目なのは、個々のタブはドラッグ＆ドロップで自由にレイアウトを変えられるという事です。そもそも何人がこの機能に気付いていたのか？というところから気になるのですが「Androidツールウィンドウ」に限ってはかなり自由にレイアウトを変えることができます。

たとえば、すべてのタブをひとまとめにしたり、

それぞれ独立させてみたり、

さらにはフローティングすることも可能です。

この手のログ参照用ウィンドウは縦に長ければ長いほど使いやすいので、デュアル以上のマルチモニタ環境を使っている場合などは「Androidツールウィンドウ」そのものをフローティング化して別モニタに表示させておくと便利です。

Androidツールウィンドウでできること

主な用途はLogcatの参照です。「⁠Devicesタブ」の上部ツールバーからログレベルの変更、検索、フィルタリングを行うことができます（検索フィールドは簡易的なフィルタ機能を兼ねます⁠）⁠。

ツールバーの「 Only Show logcat from selected process」をONにした状態で「Devicesタブ」からプロセスを選択すると、Logcatにそのプロセスのログだけが表示されます。 特定のプロセスのログだけ見たい場合は、フィルタを作成するより手軽にできます。

「Androidツールウィンドウ」のツールバー（左端）の各種アイコンからいろいろな操作を行うことができます。基本的にDDMSと同じ事ができますが、完璧にDDMSのまったく同じというわけではありません。

アイコン	機能
Screen Capture	Androidのスクリーンショット（静止画）を撮ります。
Screen Record	Androidのスクリーンキャスト（動画）を録ります。要Android4.4以上。
System Information	Android端末やエミュレータのシステム情報を取得します。
Terminate Application	「Devicesタブ」で選択したプロセスを強制終了します。
Initiate GC	「Devicesタブ」で選択したプロセスにGCを起こします。
Dump Java Heap	「Devicesタブ」で選択したプロセスのメモリダンプをHPROF形式で取得します。
Start Method Tracing	「Devicesタブ」で選択したプロセスのメソッドトレースの取得を開始します（実行すると停止アイコンに変わる⁠）⁠。

実際に試してみると「System Information」はガッカリしますが、「⁠Start Method Tracing」は意外な結果にちょっとビックリします。

なお、ツールバーもしくはメニューバーの「Tools → Android」から「 Monitor (DDMS included)」を実行すると、Android SDKのAndroid Device Monitorが立ち上がります。Android StudioのDDMSで物足りない場合は、こちらを直接利用しましょう。

Androidテストの作成と実行

初期のAndroid Studioでは未サポートでしたが、最近のAndroid StudioではAndroidテストを実行できるようになりました。

作り方

Android Studioでプロジェクトを作成した時点からAndroidテストの準備はできているのですが、初期状態のプロジェクトにはテストコードを格納するディレクトリが作られていません。GradleのAndroidプラグインではテストディレクトリは src/instrumentTest/java にデフォルト値が定められているので、その通りにまずディレクトリを作成します。

第5回で紹介したとおり、内部的にはsrc/instrumentTest/javaディレクトリはテストディレクトリとして認識されているので、ディレクトリさえ作成すれば準備は完了です。

あとはテストディレクトリ内にAndroidテストのテストコードを作成するだけです。本稿ではAndroidテストそのものについては割愛しますが、テストディレクトリ下にある実行可能なテストコードは図25のようにアイコンが変わります。

ちょっとだけ寄り道にそれますが、Android Studio v0.4.0あたりから「Project Structure / Modules / Dependencies」でテスト用のライブラリを指定できるようになりました。

この「Dependenciesタブ」上での「Test compile」スコープは、build.gradleではinstrucmentTestCompileに対応します。すでにGradleに慣れ親しんでいる人は testCompile を想像しがちですが、そもそもGradle Androidプラグインには testCompile というスコープは存在しません。

参考までに、Gradle Androidプラグインに定義されていないスコープをbuild.gradleに定義すると「Project Structure / Modules / Dependencies」に図27のように表示されます。どことなくあやしげです……。

実行方法

Androidテストが含まれるテストディレクトリの任意の場所（テストコードのファイルも含む）を選択し、コンテキストメニューから「Run」を実行します。場合によっては、さらにサブメニューが表示されAndroidテストとして実行するか、JUnitとして実行するか選択可能になりますが、必ず Androidテスト を選択するようにしてください。

Androidテストとして実行可能な選択箇所は以下のとおりです。いずれの場合もコンテキストメニューに、何か実行対象になっているか表示されるので、そう迷うことはありません。

テストディレクトリやその配下のパッケージ

テストディレクトリのルートディレクトリを指定した場合は全てのテストを実行。パッケージを指定した場合はそのパッケージ配下のテストを実行します。

テストクラスを選択した場合

そのテストクラスのみを実行します。テストクラスをテキストエディタで開いている場合は、メソッドの外にカーソルがあれば、そのテストクラスを選択した事になります。

テストメソッドを選択した場合

そのテストメソッドのみを実行します。テストクラスをテキストエディタで開いている場合は、テストメソッド内にカーソルがあれば、そのテストメソッドを選択した事になります。

テストが開始すると「Runツールウィンドウ」に図29のようなテストランナーが表示されます。

すでにIntelliJ IDEAを使っていたという奇特な人たちに向けて補足します。この「Runツールウィンドウ」に表示されるテストランナーは実行構成で「JUnit」や「TestNG」を指定したときのものとよく似ています。同じ感覚で操作できるものと思ってしまいますが、Androidテストの場合、以下の操作ができません。

• テストケースから
• 失敗したテストケースのみを再実行できない

どちらも地味に不便なので、いずれ改善することを願っています。

普通のJUnitを使ったユニットテスト

Android SDK標準のAndroidテストはJUnit3ベースであったり、実行するたびエミュレータか実機を必要とするため、純粋なロジック寄りのテストをするにはあまり使い勝手が良いとは言えません。

できることならGradleのJavaプラグインのように素のJUnit4を使いたいのですが、一筋縄ではいきません。stackoverflow.comや海外のブログにいくつかチャレンジした結果が報告されています。

• junit testing with gradle for an android project - Stack Overflow
• Android Testing with Robolectric - Peter Friese

どれも「よくぞがんばった」的な内容で、筆者の感覚では「現状ではできない」と考えてます。そう思い至った理由は以下の通りです。

• Androidテストとは別目的のテストディレクトリを認識できない
• 複数のテストフォルダを複数の用途に使い分けできない

Android Studioが「テストディレクトリ」として認識できるのは、Androidテスト用に設定したディレクトリのみです。リスト1のように instrumentTestを設定して src/instrumentTest/java 以外のディレクトリをテストディレクトリに追加することはできますが、あくまでAndroidテスト用のディレクトリが増えるだけでしかありません。

sourceSets {
  instrumentTest {
    java.srcDir 'src/test/java'
  }
}

以前のAndroid Studioより遙かに build.gradle との連係が密になったのは喜ばしいのですが、不便な点もあります。AndroidモジュールはAndroidプラグインをベースにしているため、リスト2のようにbuild.gradleに、mainやinstrumentTestとは別のソースセットを定義しても、それをソースディレクトリと認識することはありません。

sourceSets {
  unitTest {
    java.srcDir 'foobar'
  }
}

仮に instrumentTest とは別のテストディレクトリを認識できたとしても、Android Studioはテストディレクトリを用途別に区別することはできません。たとえば「ディレクトリAはAndroidテスト用、ディレクトリBはJUnit用」のようにはできず、ディレクトリAもBも1種類のテスト――つまりAndroidテスト用に設定されます。

いまのところ、Androidテスト以外のテストを行うには、Android StudioやGradleの仕組みを知った上であらゆる工夫をして、どうにか実行させる事ができる程度でしかありません。ただし「Androidテストを捨て、Robolectricのみに切り替える」といった割り切りをすれば、現状でもAndroidテスト以外のテストを行うことはできます。

• JavaモジュールからAndroidモジュールを参照できない

比較的現実的な解では？と思って検証してみたのが、プロジェクトに別途Javaモジュールを作成し、そのモジュール内のテストでAndroidモジュールを参照するというケースです。

JavaモジュールはGradleのJavaプラグインに対応しているため、普通にJUnitのテストが可能です。図31のようにJavaモジュールからAndroidモジュールを参照するテストを作り、実験してみました。

結果は惨敗でした。Android Studio上では、一見するとコンパイルは通るのですが実行時にテストケースを見つけられず失敗します。また、Gradleから直接テストを実行すると、そもそもコンパイルに失敗します。どうもGradle上ではJavaプラグインからAndroidプラグインを参照できていないようです。

これは蛇足ですが、Androidモジュールを参照していない普通のJavaモジュールであれば、Android StudioからもJUnitテストを実行することができます。Androidのテストとは、だいぶ関わりが薄いので、だからどうした的な話ですが……。

Gradleのタスクの実行

最後にGradleタスクの実行方法について紹介します。通常は「Gradleツールウィンドウ」から任意のタスクをダブルクリックして実行します。

「Gradleツールウィンドウ」から実行したタスクは、一時的な実行構成として登録されます。

Android StudioはビルドシステムにGradleを使っているので、「⁠Build」メニューの"Make Project"や"Clean Project"などは内部的にGradleのタスクを実行しています。そのため独自タスクを定義した、などでは無い限り「Gradleツールウィンドウ」を使う機会もそう多くはありません。

仮にGradleタスクを実行する機会があったとしても「Terminalツールウィンドウ」から直接実行したほうが便利だと思います。

余談ですが、Android StudioではGradleの実行に用いるJVMは、そのプロジェクトで使っているJVM（Android SDKに割り当てているJVM）になります。これを任意のJVMに変更することはできません。「⁠Run/Debug Configurations」ダイアログのGradleの実行構成の設定画面をみるとわかりますが、Gradleタスクを実行するときのJVMを指定する項目がありません。

今回のまとめと次回の予告

実行構成はIntelliJの時の仕組みを色濃く残しており、Gradleとどう連携させているのか正直ちょっと危うい感じを受けます。たとえば、AndroidアプリケーションでのAPKの指定でデフォルト以外のAPKをどうやって指定するのかなど、分からない点がいくつかあります。

デフォルトではうまくいくので、しばらくはPublic Previewだと大目にみて、追って整備されるのを勝手に期待しています。何かしらの方向性が提示されると良いですね。

次回は、今回保留にしていたデバッガの話です。