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

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

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

基本的なビルドと実行

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

  1. ツールバーで、実行構成のプルダウン メニューからアプリを選択します。
  2. ターゲット デバイスのプルダウン メニューから、アプリを実行するデバイスを選択します。

    ターゲット デバイスのプルダウン メニュー

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

  3. 実行アイコン をクリックします。

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

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

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

図 1. Android Studio のビルド出力ウィンドウ

  1. [Build] タブ: Gradle が実行するタスクがツリー形式で表示されます。各ノードは、ビルドフェーズまたはタスクの依存関係のグループを表します。ビルド時またはコンパイル時のエラーが発生した場合は、図 2 に示すように、ツリーを調べて要素を選択し、エラー出力を確認します。

    図 2. エラー メッセージ用ビルド出力ウィンドウを調べる

  2. [Sync] タブ: プロジェクト ファイルと同期するために Gradle が実行するタスクが表示されます。[Build] タブと同様に、同期エラーが発生した場合は、ツリー内の要素を選択して、エラーに関する詳細情報を確認します。
  3. 再スタート: プロジェクト内の全モジュールの中間ビルドファイルが生成されます。[Build] >[Make Project] を選択した場合と同じアクションが実行されます。
  4. ビュー切り替え: タスクの実行をグラフィカル ツリーとして表示するか、Gradle からの詳細なテキスト出力を表示するかを切り替えます。テキスト出力は、Android Studio 3.0 以前の Gradle Console ウィンドウ に表示される出力と同じです。

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

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

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

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

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

前のセクションで説明した、Android Studio でアプリをデプロイするデフォルトの方法は、シンプルなアプリをテストするには十分ですが、より高度なユースケースについては、アプリのビルドと実行のさまざまな要素を切り替えることができます。

  • [Debug] をクリックすると、デバッグモードでアプリをデプロイできます。デバッグモードでアプリを実行すると、コード上でのブレーク ポイントの設定、実行時の変数や数式の値の確認、デバッグツールの実行が可能になります。詳細については、アプリをデバッグするをご覧ください。

  • 大規模で複雑なアプリの場合、[Run] をクリックする代わりに Apply Changes を使用すると、時間を短縮できます。これは、変更をデプロイするたびにアプリを再起動しなくても済むためです。Apply Changes の詳細については、このページの Apply Changes を使用して段階的にデプロイするをご覧ください。

  • Compose を使用している場合、ライブ編集を使用すると、[Run] を再度クリックしなくてもコンポーザブルをリアルタイムで更新できるため、中断を最小限に抑えて UI コードの作成に集中できます。詳細については、このページのライブ編集をご覧ください。

  • アプリに複数のビルド バリアント(バージョン)がある場合は、[Build Variants] ツール ウィンドウを使用して、デプロイするビルド バリアントを選択できます。特定のビルド バリアントを実行する方法については、このページのビルド バリアントの変更をご覧ください。

  • アプリのインストール、起動、テストのオプションを調整するには、実行 / デバッグ構成を変更します。実行 / デバッグ構成では、アプリを APK または Android App Bundle のどちらからデプロイするかに加え、実行するモジュール、デプロイするパッケージ、開始するアクティビティ、対象デバイス、エミュレータ設定、logcat オプションなどを指定します。カスタムの実行 / デバッグ構成を作成する方法については、実行 / デバッグ構成を作成するをご覧ください。

  • 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 の使用

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

変更を適用してアクティビティを再スタート 「変更を適用してアクティビティを再スタート」アイコン

アプリを再起動せずにアクティビティを再起動して、リソースとコードの両方の変更を適用することを試みます。一般に、メソッドの本体のコードを変更したり、既存のリソースを変更したりした場合にこのオプションを使用できます。

このアクションは、Ctrl+Alt+F10(macOS では Control+Shift+Command+R)を押して実行することもできます。

コードの変更を適用 「コードの変更を適用」アイコン

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

このアクションは、Ctrl+F10(macOS では Control+Command+R)を押して実行することもできます。

実行 実行アイコン

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

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

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

この動作を有効にする手順は次のとおりです。

  1. [Settings] ダイアログまたは [Preferences] ダイアログを開きます。

    • Windows または Linux の場合、メニューバーから [File] > [Settings] を選択します。
    • macOS の場合、メニューバーから [Android Studio] > [Preferences] を選択します。
  2. [Build, Execution, Deployment] > [Deployment] に移動します。

  3. チェックボックスをオンにして、Apply Changes アクションのいずれかの自動代替実行を有効にします。

  4. [OK] をクリックします。

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

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

変更タイプ プラットフォームの最小バージョン
メソッドの追加 Android 11

Apply Changes の制限

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

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

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

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

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

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

debug ビルド バリアントのすべての自動更新を無効にすることで、これらの制限を回避できます。

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

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

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

ライブ編集(試験運用版)

ライブ編集は Android Studio Flamingo カナリア リリースに含まれる試験運用版の機能であり、エミュレータと実機でコンポーザブルをリアルタイムに更新できるようにします。この機能を使用すれば、アプリの作成環境とビルド環境の切り替えを少なく抑えられるため、コードの作成により長く集中できるようになります。ライブ編集には、手動と自動の 2 つのモードがあります。手動モードでは、Ctrl + S(macOS の場合は Command + S)を使用して手動で保存すると、コードの変更が適用されます。自動モードでは、コンポーズ可能な関数を更新すると、その変更は更新後すぐに、デバイスまたはエミュレータに反映されます。

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

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

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

  1. アプリケーションをセットアップして実行可能にします。
  2. ライブ編集でサポートされない変更(アプリ実行中の新しいメソッドの追加など)を行う必要性が生じるまで、可能な限りの変更をライブ編集で行います。
  3. ライブ編集でサポートされない変更を加えたら、アプリを実行してライブ編集を再開します。

デバイスでのライブ編集使用例の GIF

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

ライブ編集を使ってみる

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

新しいプロジェクトをセットアップする
  1. 始める前に、Android Studio Electric Eel の最新の Canary バージョンがインストールされていることと、実機またはエミュレータの API レベルが 30 以降であることを確認します。

  2. Android Studio を開き、[Welcome to Android Studio] ポップアップで [New Project] を選択します。すでにプロジェクトが開いている場合は、[File] > [New] > [New Project] に移動することで新しいプロジェクトを作成できます。

  3. [Phone and Tablet] の [Empty Compose Activity] テンプレートを選択し、[Next] をクリックします。

    Android Studio でのテンプレートの選択 図 4. 選択できるテンプレート。ライブ編集用に [Empty Compose Activity] を選択します。

  4. 次のように入力して [Finish] をクリックします。

    • Name: HelloWorld
    • Package name: com.example.helloworld
    • Save location: デフォルト
    • Language: Kotlin
    • Minimum SDK: デフォルト

    Android Studio に入力されたステップ 4 のプロジェクト設定の例 図 5. プロジェクト設定の例。

ライブ編集を有効にする
  1. IDE で設定に移動してライブ編集を有効にします。

    • Windows または Linux の場合、[File] > [Settings] > [Editor] > [Live Edit] に移動します。
    • macOS の場合、[Android Studio] > [Preferences] > [Editor] > [Live Edit] に移動します。
  2. [Live Edit] オプションと、実行するモードを設定から選択します。手動モードでは、Ctrl + S(macOS の場合は Command + S)を使用して手動で保存するたびにコードの変更が適用されます。自動モードでは、変更するごとにデバイスまたはエミュレータでコードの変更が適用されます。

    Android Studio 設定のライブ編集チェックボックス UI 図 6. 設定の [Live Edit] オプション。

  3. エディタで、アプリのエントリ ポイントである MainActivity ファイルを開きます。

  4. 実行ボタン UI ボタン をクリックしてアプリをデプロイし、エディタの右上にある [Split] をクリックしてプレビューを開きます。

  5. ライブ編集を有効にすると、エディタの右上に緑色のライブ編集チェックマークが表示されます。

    ライブ編集の緑色のチェックマークの UI

変更を加えて確認する

エディタで、MainActivity の既存の Greeting メソッドを次のように変更します。図 7 に示すように、変更は瞬時に表示されます。

@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)
    )
}

デバイスで適用される Greeting メソッドの変更

図 7. 上記の Greeting メソッドに対するライブ編集の変更はすぐに表示される。

トラブルシューティング

プレビュー ペインに編集内容が表示されない場合、Android Studio が編集内容の更新に失敗している可能性があります。ライブ編集の UI インジケーターに、コンパイル エラーを示す一時停止アイコンが表示されているかどうかを確認します。

ライブ編集ステータス UI

図 8. エラーの詳細と解決方法の提案を表示するには、UI の [Live Edit: ON] にカーソルを合わせる。

制限事項

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

  • Compose 1.2.0 以前では、ライブ編集でエラー処理とレポート作成を行うことはできません。最適な動作を実現するために、Compose 1.3.0 以降を使用することを強くおすすめします。
  • ライブ編集には、API レベル 30 以降を搭載している実機またはエミュレータが必要です。
  • ライブ編集は関数本体の編集のみをサポートします。関数名やシグネチャの変更、関数の追加または削除、関数以外のフィールドの変更はできません。
  • ライブ編集で変更したクラスは、パフォーマンスが低下することがあります。パフォーマンスを評価する場合は、アプリを実行し、クリーンなリリースビルドを使用することをおすすめします。
  • ライブ編集で変更したクラスでデバッガを機能させるには、完全な実行を行う必要があります。
  • 実行中のアプリをライブ編集で編集すると、クラッシュする可能性があります。その場合、実行ボタン UI ボタン でアプリを再デプロイできます。
  • ライブ編集では、プロジェクトのビルドファイルで定義されているバイトコード操作は実行されません。たとえば、[Build] メニューのオプションを使用して、または [Build] ボタンや実行ボタンをクリックしてプロジェクトをビルドしたときに適用されるバイトコード操作は実行されません。
  • コンポーズ可能な関数以外の関数は、デバイスまたはエミュレータでリアルタイムに更新され、完全な再コンポーズがトリガーされます。完全な再コンポーズでは、更新された関数が呼び出されない場合があります。コンポーズ可能な関数以外の関数については、新しく更新された関数をトリガーするか、アプリを再度実行する必要があります。
  • アプリを再起動してもライブ編集は再開されません。アプリを再度実行する必要があります。
  • プロジェクトで Compose バージョン 1.2 以降を使用している場合は、所定のファイルに対して最初に行われたコード変更のみによってコンポジションがリセットされます。対象のファイルにその後編集を行ってもコンポジションはリセットされません。

よくある質問

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

ビルド バリアントの変更

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

Android Studio が使用するビルド バリアントを変更するには、[Build] > [Select Build Variant] を選択します。

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

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

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

ネイティブ / C++ コードを使用するプロジェクトの場合、[Build Variants] パネルには、[Module]、[Active Build Variant]、[Active ABI] の 3 つの列が表示されます。モジュールの [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 でのみ利用可能なクラス Foo に依存しているとします。v2 が選択されると、そのクラスは IDE によって認識されないため解決されず、M1 のコードにエラーが表示されます。

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

実行 / デバッグ構成の変更

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

デフォルトの実行 / デバッグ構成では、APK をビルドしてデフォルトのプロジェクト アクティビティを起動し、[Select Deployment Target] ダイアログでターゲットとするデバイスを選択できます。このデフォルトの設定が自身のプロジェクトやモジュールに合わない場合は、実行またはデバッグ用の構成をカスタマイズする、あるいはプロジェクト、デフォルト、モジュール レベルで新規に作成することも可能です。実行またはデバッグ用の構成を編集するには、[Run] > [Edit Configurations] を選択します。詳細については、実行 / デバッグ構成の作成と編集をご覧ください。