アプリをビルドして実行する

デバイスでアプリの外観や動作を確認するには、アプリをビルドして実行する必要があります。Android Studio で新しいプロジェクトを設定すると、わずか数クリックでアプリを仮想デバイスまたは実機にデプロイできます。

この概要では、テストとデバッグのために Android Studio を使用してアプリをビルドおよび実行する方法について説明します。Android Studio を使用してアプリをビルドし、ユーザーにリリースできるようにする方法については、ユーザー向けにリリースするアプリをビルドするをご覧ください。Android Studio の有無にかかわらず、ビルドの管理とカスタマイズについて詳しくは、ビルドを設定するをご覧ください。

基本的なビルドと実行

アプリをビルドして実行する手順は次のとおりです。

ツールバーで、実行構成メニューからアプリを選択します。
対象デバイスのメニューで、アプリを実行するデバイスを選択します。

構成済みのデバイスがない場合は、Android Emulator を使用するために Android Virtual Device を作成するか、実機を接続します。
実行アイコンをクリックします。

エラーまたは警告があるデバイスでプロジェクトを起動しようとすると、Android Studio から警告が表示されます。アイコンとスタイルの変更により、エラー（構成を破綻させるデバイス選択）と警告（予期しない動作が発生する可能性があるが、実行は可能なデバイス選択）を区別できます。

ビルドプロセスのモニタリング

ビルドプロセスの詳細を表示するには、[View] > [Tool Windows] > [Build] を選択するか、ツールウィンドウバーでビルド アイコンをクリックします。図 1 に示すように、[Build] ツールウィンドウには、アプリをビルドするために Gradle が実行するタスクが表示されます。

**図 1.** Android Studio の [**Build**] ツールウィンドウ

[Sync] タブ: プロジェクトファイルと同期するために Gradle が実行するタスクが表示されます。[Build Output] タブと同様に、同期エラーが発生した場合は、ツリー内の要素を選択して、エラーに関する詳細情報を確認します。また、ダウンロードの影響の概要が表示され、依存関係のダウンロードがビルドに悪影響を与えているかどうかを判断できます。
[Build Output] タブ: Gradle が実行するタスクがツリー形式で表示されます。各ノードは、ビルドフェーズまたはタスクの依存関係のグループを表します。ビルド時またはコンパイル時のエラーが発生した場合は、図 2 に示すように、ツリーを調べて要素を選択し、エラー出力を確認します。

図 2. エラーメッセージがないか [Build Output] タブを調べます。
[Build Analyzer] タブ: ビルドに関するビルドパフォーマンスの分析情報が表示されます。詳細については、Build Analyzer でビルドパフォーマンスをトラブルシューティングするをご覧ください。
Restart: 最後のビルドアクションを再度実行します。最後に実行したのが [Build] > [Make Selected Module] の場合は、現在のモジュールがビルドされます。最後に実行したのが [Build] > [Make Project] の場合は、プロジェクト内のすべてのモジュールの中間ビルドファイルが生成されます。
フィルタ: 正常に完了した警告、タスク、またはその両方を除外します。これにより、出力から問題を見つけやすくなります。

ビルドバリアントでプロダクトフレーバーを使用している場合、Gradle はそのプロダクトフレーバーをビルドするためのタスクも起動します。使用可能なすべてのビルドタスクのリストを表示するには、[View] > [Tool Windows] > [Gradle] をクリックするか、ツールウィンドウバーの Gradle アイコンをクリックします。

ビルドプロセス中にエラーが発生した場合、Gradle は --stacktrace、--debug など、問題の解決に役立つコマンドラインオプションを推奨する場合があります。ビルドプロセスにコマンドラインオプションを使用する方法は以下のとおりです。

[Settings] または [Preferences] ダイアログを開きます。
- Windows または Linux では、メニューバーから [File] > [Settings] を選択します。
- macOS では、メニューバーから [Android Studio] > [Preferences] を選択します。
[Build, Execution, Deployment] > [Compiler] に移動します。
[Command-line Options] の隣にあるテキストフィールドに、コマンドラインオプションを入力します。
[OK] をクリックして保存し、終了します。

Gradle は、次回アプリをビルドするときにこれらのコマンドラインオプションを適用します。

ビルドと実行の高度な機能

シンプルなアプリをテストするには、Android Studio でアプリのビルドと実行を行うデフォルトの方法で十分です。ただし、さらに高度なユースケースには、以下のビルドと実行の機能を使用できます。

デバッグモードでアプリをデプロイするには、デバッグ アイコンをクリックします。デバッグモードでアプリを実行すると、コード上でのブレークポイントの設定、実行時の変数や数式の値の確認、デバッグツールの実行が可能になります。詳細については、アプリをデバッグするをご覧ください。
大規模で複雑なアプリの場合、実行アイコンをクリックするのではなく Apply Changes を使用します。変更をデプロイするたびにアプリを再起動する必要がなくなるため、時間を節約できます。Apply Changes の詳細については、Apply Changes を使用して段階的にデプロイするのセクションをご覧ください。
Jetpack Compose を使用している場合、ライブ編集という試験運用版の機能により、実行アイコンを再度クリックせずにコンポーザブルをリアルタイムで更新できます。このため、中断を最小限に抑えて UI コードの作成に集中できます。詳細については、ライブ編集（試験運用版）のセクションをご覧ください。
アプリに複数のビルドバリアント（バージョン）がある場合は、[Build Variants] ツールウィンドウを使用して、デプロイするビルドバリアントを選択できます。特定のビルドバリアントを実行する方法については、ビルドバリアントを変更するのセクションをご覧ください。
アプリのインストール、起動、テストのオプションを調整するには、実行 / デバッグ構成を変更します。カスタムの実行 / デバッグ構成を作成する方法については、実行 / デバッグ構成を作成するのセクションをご覧ください。
開発のニーズに合わせて Android Studio を使用することをおすすめしますが、コマンドラインから仮想デバイスまたは実機にアプリをデプロイすることもできます。詳しくは、コマンドラインからアプリをビルドするをご覧ください。

Apply Changes を使用して段階的にデプロイする

Android Studio 3.5 以降で Apply Changes を使用すると、アプリを再起動せずに、場合によっては現在のアクティビティを再起動せずに、コードとリソースの変更を実行中のアプリにプッシュできます。この優れた適応性により、小さな追加変更のデプロイとテストのために何度もアプリを再起動する必要がなくなり、その時点でのデバイスの状態に影響を及ぼすこともなくなります。

Apply Changes では、Android 8.0（API レベル 26）以降を搭載しているデバイスでサポートされる Android JVMTI 実装の機能を使用します。Apply Changes の動作の詳細については、Android Studio Project Marble: Apply Changes をご覧ください。

要件

Apply Changes のアクションは、次の条件を満たす場合にのみ使用できます。

debug ビルドバリアントを使用して、アプリの APK をビルドする。
Android 8.0（API レベル 26）以降を搭載するターゲットデバイスまたはエミュレータにアプリをデプロイする。

Apply Changes の使用

互換性のあるデバイスに変更をデプロイする場合は、次のオプションを使用します。

変更を適用してアクティビティを再スタート : アプリを再起動せずにアクティビティを再起動して、リソースとコードの両方の変更を適用しようとします。通常、メソッドの本体のコードや既存のリソースを変更する場合に、このオプションを使用できます。

このアクションは Control+Alt+F10（mac OS では Control+Command+Shift+R）キーを押すことでも実施できます。

コードの変更を適用 : 何も再起動せずにコードの変更のみを適用しようとします。一般に、メソッドの本体のコードを変更したが、リソースを変更していない場合に、このオプションを使用できます。コードとリソースの両方を変更した場合は、代わりに変更を適用してアクティビティを再スタート アイコンを使用します。

このアクションは Ctrl+F10（macOS では Ctrl+Command+R）キーを押すことでも実施できます。

実行 : すべての変更をデプロイし、アプリを再起動します。いずれの Apply Changes オプションを使用しても変更を適用できない場合に、このオプションを使用します。アプリの再起動が必要な変更の種類について詳しくは、Apply Changes の制限のセクションをご覧ください。

Apply Changes に対する代替実行を有効にする

変更を適用してアクティビティを再スタート アイコンまたはコードの変更を適用アイコンをクリックすると、Android Studio は新しい APK をビルドし、変更を適用できるかどうかを判断します。変更を適用できず、Apply Changes が失敗する可能性がある場合は、代わりに実行ボタンをクリックしてアプリをもう一度実行するよう求めるメッセージが表示されます。

この状況が発生してもメッセージが表示されないようにするには、変更を適用できないときは自動的にアプリを再実行するよう Android Studio を構成します。この動作を有効にする手順は次のとおりです。

[Settings] ダイアログまたは [Preferences] ダイアログを開きます。
- Windows または Linux では、メニューから [File] > [Settings] を選択します。
- macOS では、メニューから [Android Studio] > [Preferences] を選択します。
[Build, Execution, Deployment] > [Deployment] に移動します。
チェックボックスをオンにして、Apply Changes アクションのいずれかまたは両方の自動代替実行を有効にします。
[OK] をクリックします。

プラットフォームに依存する変更

Apply Changes の一部の機能は、Android プラットフォームのバージョンによって異なります。このような変更を適用するには、そのバージョン以降の Android を搭載したデバイスにアプリをデプロイする必要があります。たとえば、メソッドを追加するには Android 11 以降が必要です。

Apply Changes の制限

Apply Changes は、アプリのデプロイ過程を迅速化するように設計されています。ただし、使用できる場合にはいくつかの制限があります。

アプリの再起動が必要なコードの変更

次のような一部のコードとリソースの変更は、アプリを再起動するまで適用できません。

フィールドの追加や削除
メソッドの削除
メソッドシグネチャの変更
メソッドやクラスの修飾子の変更
クラス継承の変更
列挙型内の値の変更
リソースの追加や削除
アプリマニフェストの変更
ネイティブライブラリ（SO ファイル）の変更

ライブラリとプラグイン

一部のライブラリとプラグインは、アプリのマニフェストファイルまたはマニフェストで参照されているリソースを自動的に変更します。これらの自動更新は、次のように Apply Changes に干渉する可能性があります。

ライブラリまたはプラグインがアプリのマニフェストに変更を加えた場合、Apply Changes は使用できません。変更を反映するには、アプリを再起動する必要があります。
ライブラリまたはプラグインがアプリのリソースファイルに変更を加えた場合、コードの変更を適用アイコンは使用できません。変更を反映するには、変更を適用してアクティビティを再スタート アイコンを使用するか、アプリを再起動する必要があります。

この制限を回避するには、デバッグビルドバリアントのすべての自動更新を無効にします。

たとえば Firebase Crashlytics は、ビルドごとにアプリリソースを一意のビルド ID で更新します。これにより、コードの変更を適用アイコンを使用できなくなるため、変更を反映するにはアプリのアクティビティを再起動する必要があります。この動作を無効にして、デバッグビルドで Crashlytics とともにコードの変更を適用アイコンを使用します。

インストールされた APK のコンテンツを直接参照するコード

デバイスにインストールされているアプリの APK のコンテンツをコードが直接参照している場合、コードの変更を適用アイコンをクリックするとそのコードがクラッシュまたは誤動作を引き起こす可能性があります。この現象は、コードの変更を適用アイコンをクリックすると、参照されているコンテンツを含むデバイス上の APK がインストール中に置き換えられるために発生します。このような場合は、代わりに変更を適用してアクティビティを再スタートアイコンまたは実行アイコンをクリックします。

Apply Changes の使用中に他の問題が発生した場合は、バグとして報告してください。

ライブ編集

ライブ編集は Android Studio の試験運用版の機能であり、エミュレータと実機でコンポーザブルをリアルタイムに更新できるようにします。アプリの作成環境とビルド環境の切り替えが最小限に抑えられるため、コードの作成により長く集中できるようになります。

ライブ編集の詳細

ビルドバリアントを変更する

実行アイコン UI ボタンをクリックすると、Android Studio はデフォルトでデバッグ版のアプリをビルドして実行します。これは開発中にのみ使用するためのバージョンです。

Android Studio が使用するビルドバリアントを変更するには、次のいずれかを行います。

メニューで [Build] > [Select Build Variant] を選択します。
メニューで [View] > [Tool Windows] > [Build Variants] を選択します。
ツールウィンドウバーの [Build Variants] タブをクリックします。

ネイティブ / C++ コードを含まないプロジェクトの場合、[Build Variants] パネルには、[Module] と [Active Build Variant] という 2 つの列が表示されます。モジュールの [Active Build Variant] 値により、IDE で接続済みのデバイスにデプロイされ、エディタで表示されるビルドバリアントが決定されます。

図 9. ネイティブ / C++ コードを含まないプロジェクトの場合、[Build Variants] パネルには 2 つの列が表示されます。

バリアントを切り替えるには、モジュールの [Active Build Variant] セルをクリックし、リストから目的のバリアントを選択します。

ネイティブ / C++ コードを含むプロジェクトの場合、[Build Variants] パネルには次の 3 つの列が表示されます。

Module
Active Build Variant
Active ABI

モジュールの [Active Build Variant] 値により、IDE でデバイスにデプロイされ、エディタで表示されるビルドバリアントが決定されます。ネイティブモジュールの場合は、[Active ABI] 値によってエディタが使用する ABI が決定されますが、デプロイされるものには影響しません。

図 10. ネイティブ / C++ コードを含むプロジェクトの場合、[Build Variants] パネルに [Active ABI] 列が追加されます。

ビルドバリアントまたは ABI を変更するには、[Active Build Variant] または [Active ABI] 列のセルをクリックし、リストから目的のバリアントまたは ABI を選択します。値を変更すると、IDE によりプロジェクトが自動的に同期されます。アプリまたはライブラリモジュールのいずれかの列を変更すると、すべての依存行に変更が適用されます。

新規プロジェクトにはデフォルトで、debug と release の 2 つのビルドバリアントがセットアップされます。アプリの公式リリースを準備する際には、リリースバリアントをビルドする必要があります。追加のビルドバリアントを定義することで、さまざまな機能やデバイス要件を持つアプリの他のバリエーションを定義できます。

Android Studio の [Build Variants] ダイアログでの競合

Android Studio の [Build Variants] ダイアログに、次のようなビルドバリアント間の競合を示すエラーメッセージが表示されることがあります。

バリアント競合のエラーを表示しているビルドバリアントのウィンドウ

このエラーは、Gradle でのビルドの問題を示しているわけではありません。選択されたモジュールのバリアント間で Android Studio IDE がシンボルを解決できないことを示しています。

たとえば、モジュール M1 がモジュール M2 のバリアント v1 に依存する一方で、M2 に IDE で選択されたバリアント v2 がある場合、IDE には未解決のシンボルがあります。M1 が、v1 でのみ利用可能なクラスに依存しているとします。v2 が選択されると、そのクラスは IDE によって認識されません。そのため、クラス名が解決されず、M1 モジュールのコードにエラーが表示されます。

これらのエラーメッセージは、IDE で複数のバリアントのコードを同時に読み込めないために表示されます。ただし、アプリのビルドについては、このダイアログで選択されたバリアントによる影響はありません。Gradle は、IDE で現在読み込まれているものではなく、Gradle ビルドレシピで指定されたソースコードを使用してアプリをビルドするためです。

実行 / デバッグ構成を変更する

アプリを初めて実行する場合、Android Studio はデフォルトの実行構成を使用します。実行構成では、アプリを APK または Android App Bundle のどちらからデプロイするかに加え、実行するモジュール、デプロイするパッケージ、開始するアクティビティ、対象デバイス、エミュレータ設定、Logcat オプションなどを指定します。

デフォルトの実行 / デバッグ構成では、APK をビルドしてデフォルトのプロジェクトアクティビティを起動し、[Select Deployment Target] ダイアログでターゲットとするデバイスを選択できます。このデフォルトの設定が自身のプロジェクトやモジュールに合わない場合は、実行 / デバッグ構成をカスタマイズしたり、プロジェクト、デフォルト、モジュールレベルで新規作成したりできます。

実行 / デバッグ構成を編集するには、[Run] > [Edit Configurations] を選択します。詳細については、実行 / デバッグ構成の作成と編集をご覧ください。