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

デバイスでアプリの外観や動作を確認するには、アプリをビルドして実行する必要があります。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 でビルドパフォーマンスをトラブルシューティングするをご覧ください。
再スタート: [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 Giraffe Canary リリースに含まれる試験運用版の機能です。この機能を使用すると、エミュレータと実機でコンポーザブルをリアルタイムに更新できます。アプリの作成環境とビルド環境の切り替えが最小限に抑えられるため、コードの作成により長く集中できるようになります。

ライブ編集には 2 つのモードがあります。

手動: Ctrl+S（macOS では Command+S）キーを使用して手動で保存すると、コードの変更が適用されます。
自動: コンポーズ可能な関数を更新すると、デバイスまたはエミュレータに変更が適用されます。

ライブ編集は、UI および UX 関連のコード変更に重点を置いています。メソッドシグネチャの更新、新しいメソッドの追加、クラス階層の変更などの変更はサポートしていません。詳しくは、ライブ編集の制限事項のリストをご覧ください。

この機能は、アプリの作成と実行や Apply Changes の代替ではなく、Compose UI の開発におけるビルド、デプロイ、反復のワークフローを最適化するためのものです。

ベストプラクティスのワークフローは次のとおりです。

アプリをセットアップして実行できるようにします。
ライブ編集でサポートされない変更（アプリ実行中の新しいメソッドの追加など）を行う必要性が生じるまで、可能な限りの変更をライブ編集で行います。
ライブ編集ではサポートされていない変更が済んだら、実行アイコンをクリックしてアプリを再起動し、ライブ編集を再開します。

図 3. 自動モードでは、ライブ編集でサポートされる編集が行われるたびに、デバイスまたはエミュレータ上で実行中のアプリがリアルタイムで更新されます。

ライブ編集を使ってみる

まず、次の手順で空の Compose アクティビティを作成し、プロジェクトでライブ編集を有効にして、ライブ編集で変更を加えます。

新しいプロジェクトをセットアップする

始める前に、Android Studio Giraffe の最新の Canary バージョンがインストールされていることと、実機またはエミュレータの API レベルが 30 以降であることを確認します。
Android Studio を開き、[Welcome to Android Studio] ダイアログで [New Project] を選択します。すでにプロジェクトが開いている場合は、[File] > [New] > [New Project] に移動することで新しいプロジェクトを作成できます。
[Phone and Tablet] の [Empty Compose Activity] テンプレートを選択し、[Next] をクリックします。

図 4. 選択できるテンプレート。ライブ編集用に [Empty Compose Activity] を選択します。
[New Project] ダイアログで必要な情報をすべて入力します。具体的には、名前、パッケージ名、保存場所、最小 SDK、ビルド構成の言語です。

図 5. プロジェクト設定の例。
[Finish] をクリックします。

ライブ編集を有効にする

設定に移動してライブ編集を有効にします。
- Windows または Linux の場合、[File] > [Settings] > [Editor] > [Live Edit] に移動します。
- macOS の場合、[Android Studio] > [Settings] > [Editor] > [Live Edit] に移動します。
設定で [Live Edit] オプションを選択し、実行するモードを選びます。

手動モードでは、Ctrl+S（macOS では Command+S）キーを押して手動で保存するたびに、コードの変更が適用されます。自動モードでは、変更するごとにデバイスまたはエミュレータでコードの変更が適用されます。

図 6. [Live Edit] 設定。
エディタで、アプリのエントリポイントである MainActivity ファイルを開きます。
実行アイコンをクリックしてアプリをデプロイします。
ライブ編集を有効にすると、[Running Devices] ツールウィンドウの右上に「Up-to-date」（最新）という緑色のチェックマークが表示されます。

変更を加えて確認する

エディタでサポートされている変更を行うと、仮想テストデバイスまたは物理的なテストデバイスが自動的に更新されます。

たとえば、MainActivity の既存の Greeting メソッドを次のように編集します。

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!",
        Modifier.padding(80.dp) // Outer padding; outside background
            .background(color = Color.Cyan) // Solid element background color
            .padding(16.dp) // Inner padding; inside background, around text)
    )
}

図 7 に示すように、変更は瞬時にテストデバイスに表示されます。

デバイスで Greeting メソッドの変更内容が適用されている

図 7. ライブ編集により Greeting メソッドに加えた変更が表示されているテストデバイス。

ライブ編集のトラブルシューティング

編集した内容がテストデバイスで表示されない場合は、Android Studio での編集内容の更新が失敗している可能性があります。ライブ編集のインジケーターで、図 8 のようにコンパイルエラーを示す「Out Of Date」（要更新）が表示されているかどうかを確認します。エラーの詳細と解決方法の提案については、このインジケーターをクリックしてください。

ライブ編集の「Out Of Date」（要更新）アイコン

図 8. ライブ編集ステータスインジケーター。

ライブ編集の制限事項

現在の制限事項は次のとおりです。

ライブ編集には Compose 1.3.0 以降が必要です。プロジェクトでそれより前のバージョンの Compose を使用している場合、ライブ編集は無効になります。
ライブ編集には AGP 8.1 以降が必要です。プロジェクトでそれより前のバージョンの AGP を使用している場合、ライブ編集は無効になります。
ライブ編集には、API レベル 30 以降を搭載している実機またはエミュレータが必要です。
ライブ編集は関数本体の編集のみをサポートします。関数名やシグネチャの変更、関数の追加または削除、関数以外のフィールドの変更はできません。
ライブ編集で変更したクラスは、パフォーマンスが低下することがあります。パフォーマンスを評価する場合は、アプリを実行し、クリーンなリリースビルドを使用します。
ライブ編集で変更したクラスでデバッガを機能させるには、完全な実行を行う必要があります。
実行中のアプリをライブ編集で編集すると、クラッシュする可能性があります。その場合、実行ボタンでアプリを再デプロイできます。
ライブ編集では、プロジェクトのビルドファイルで定義されているバイトコード操作は実行されません。たとえば、[Build] メニューのオプションを使用して、またはビルドボタンや実行ボタンをクリックしてプロジェクトをビルドしたときに適用されるバイトコード操作は実行されません。
コンポーズ可能な関数以外の関数は、デバイスまたはエミュレータでリアルタイムに更新され、完全な再コンポーズがトリガーされます。完全な再コンポーズでは、更新された関数が呼び出されない場合があります。コンポーズ可能な関数以外の関数については、新しく更新された関数をトリガーするか、アプリを再度実行する必要があります。
アプリを再起動してもライブ編集は再開されません。アプリを再度実行する必要があります。
ライブ編集はデバッグ可能なプロセスにのみ対応しています。
ライブ編集はビルド構成で kotlinOptions の moduleName にカスタム値を使用しているプロジェクトはサポートしていません。
マルチデプロイの導入では、ライブ編集は機能しません。つまり、あるデバイスにデプロイ後、別のデバイスにデプロイすることはできません。ライブ編集はアプリがデプロイされた最後のデバイスセットのみで有効となります。
ライブ編集は、マルチデバイスデプロイ（対象デバイスのプルダウンの [Select Multiple Devices] から作成された複数デバイスへのデプロイ）で機能します。ただし、公式にはサポートされておらず、問題が発生する可能性があります。問題が発生した場合は、ご報告ください。

ライブ編集に関するよくある質問

ライブ編集の現在のステータスを教えてください。
- ライブ編集は、Android Studio Giraffe Canary チャネルで試験運用版の機能としてご利用いただけます。オンとオフを切り替えるには、[File] > [Settings] > [Editor] > [Live Edit]（mac OS では [Android Studio] > [Preferences] > [Editor] > [Live Edit]）に移動します。
ライブ編集を使うのはどのような場合ですか？
- UX 要素（修飾子の更新やアニメーションなど）の変更がアプリエクスペリエンス全体に与える影響をすぐに確認したい場合に、ライブ編集を使用します。
ライブ編集を使わない方がよいのはどのような場合ですか？
- ライブ編集は現在、UI および UX 関連のコード変更に重点を置いています。メソッドシグネチャの更新、新しいメソッドの追加、クラス階層の変更などの変更はサポートしていません。詳しくは、ライブ編集の制限事項をご覧ください。
Compose プレビューを使うのはどのような場合ですか？
- 個々のコンポーザブルを開発する場合に、Compose プレビューを使用します。Compose プレビューは、Compose 要素を視覚化し、コードの変更を反映するように自動的に更新します。さらに、さまざまな構成や状態（ダークモード、ロケール、フォントスケールなど）での UI 要素の表示もサポートしています。

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

実行アイコン 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 によりプロジェクトが自動的に同期されます。アプリまたはライブラリモジュールのいずれかの列を変更すると、すべての依存行に変更が適用されます。

デフォルトでは、新規プロジェクトは 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] を選択します。詳細については、実行 / デバッグ構成の作成と編集をご覧ください。