Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

アプリのビルドと実行

Android Studio では、Android Emulator や接続されたデバイスへデプロイするための新規プロジェクトの設定が、わずか数回クリックするだけで完了します。アプリのインストール後は、Apply Changes を使用して、新しい APK を作成せずに特定のコードとリソースの変更をデプロイできます。

アプリをビルドして実行するには、次の手順を実行します。

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

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

    構成済みのデバイスがない場合は、USB 経由でデバイスを接続するか、AVD を作成して Android Emulator を使用する必要があります。

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

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

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

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

ビルド バリアントの変更

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

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

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

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

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

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

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

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

新規プロジェクトにはデフォルトで、debug と release の 2 つのビルド バリアントがセットアップされます。アプリの公式リリースを準備する際には、リリース バリアントをビルドする必要があります。

追加のビルド バリアントを定義して、それぞれ異なる機能またはデバイス要件を持つアプリの他のバリエーションをビルドできます。

プロジェクトのビルド

実行ボタン を押すことにより、アプリのビルドとデバイスへのデプロイが実行されます。ただし、共有または Google Play へアップロードするアプリをビルドする場合、[Build] メニューのオプションのいずれかを使用して、プロジェクトの一部または全部をコンパイルする必要があります。 最初に使用するビルド バリアントを選択してから、表 1 にリストされているビルド オプションのいずれかを選択してください。

表 1. [Build] メニューのビルド オプション。

メニュー項目 説明
Make Module 最後のビルド以降に変更された、選択したモジュール内のすべてのソースファイル、および選択したモジュールが再帰的に依存するすべてのモジュールをコンパイルします。コンパイルには、依存ソースファイルと、関連するビルドタスクが含まれます。[Project] ウィンドウでモジュール名またはそのファイルのいずれかを選択することにより、ビルドするモジュールを選択できます。 このコマンドは APK を生成しません。
Make Project すべてのモジュールを make します。
Clean Project すべての中間ビルドファイルおよびキャッシュ ビルドファイルを削除します。
Rebuild Project 選択したビルド バリアントに対して Clean Project を実行し、APK を生成します。
Build Bundle(s) / APK(s) > Build APK(s)

現在のプロジェクトに含まれるすべてのモジュールにつき、選択したバリアントの APK をビルドします。ビルドが完了すると、確認通知が表示され、APK ファイルへのリンクと APK Analyzer で分析するためのリンクが提供されます。

選択したビルド バリアントが debug ビルドタイプである場合、生成された APK はデバッグキーで署名され、インストールの準備ができています。release バリアントを選択した場合、デフォルトでは APK は署名されていないため、APK に手動で署名する必要があります。メニューバーから [Build] > [Generate Signed Bundle / APK] を選択して、署名済みの APK を生成することも可能です。

Android Studio は、ビルドした APK を project-name/module-name/build/outputs/apk/ に保存します。

Build Bundle(s) / APK(s) > Build Bundle(s)

現在のプロジェクトに含まれるすべてのモジュールにつき、選択したバリアントの Android App Bundle をビルドします。ビルドが完了すると、確認通知が表示され、アプリバンドルへのリンクと APK Analyzer で分析するためのリンクが提供されます。

選択したビルド バリアントが debug ビルドタイプである場合、生成された App Bundle はデバッグキーで署名され、bundletool を使用して App Bundle からアプリを接続されたデバイスにデプロイできます。release バリアントを選択した場合、App Bundle はデフォルトで署名されていないため、jarsigner を使用して手動で署名する必要があります。 メニューバーから [Build] > [Generate Signed Bundle / APK] を選択して、署名済みの App Bundle を生成することも可能です。

Android Studio は、ビルドした App Bundle を project-name/module-name/build/outputs/bundle/ に保存します。

Generate Signed Bundle / APK ウィザードのダイアログを表示して、新しい署名構成をセットアップし、署名済みの App Bundle または APK をビルドします。Play Console にアップロードする前に、リリースキーでアプリに署名する必要があります。 アプリ署名の詳細については、アプリの署名をご覧ください。

注: 実行ボタン は、testOnly="true" で APK をビルドします。これは、APK を Android Studio が使用する adb を介してのみインストールできることを意味します。ユーザーが adb なしでインストールできるデバッグ可能な APK が必要な場合は、debug バリアントを選択し、[Build Bundle(s) / APK(s)] > [Build APK(s)] をクリックします。

Gradle が各コマンドに対して実行するタスクの詳細を知るには、次のセクションの説明に従って [Build] ウィンドウを開きます。Gradle とビルドプロセスの詳細については、ビルドを設定するをご覧ください。

ビルド処理のモニタリング

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

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

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

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

  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 は、次回アプリをビルドするときにこれらのコマンドライン オプションを適用します。

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 は代わりにアプリに対してもう一度実行ボタン 実行アイコン をクリックするようプロンプトを表示します。ただし、これが発生するたびにプロンプトを表示したくない場合は、変更を適用できない場合にアプリを自動的に再実行するように 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 の制限

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

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

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

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

ライブラリとプラグイン

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

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

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

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

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

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

既知の問題

現在、次の問題が Apply Changes で発生することがわかっています。

Android ランタイムの問題によりエラーが生じる

Android 8.0 または 8.1 を搭載したデバイスを使用している場合、特定の種類の変更を適用しようとすると「VERIFICATION_ERROR」メッセージが表示されることがあります(特に Kotlin を使用している場合)。このメッセージが表示されるのは、Android ランタイムの問題が原因ですが、Android 9.0 以降では修正されています。この問題により Apply Changes は失敗しますが、再度実行アイコン 実行アイコン をクリックすることで変更を反映できます。ただし、デバイスを Android 9.0 以降へアップグレードすることをおすすめします。

android:sharedUserId の使用時に変更を適用できない

アプリが次のいずれかの方法で構成されている場合、実行中のアプリにまだデプロイされていないクラスを変更しようとすると Apply Changes が失敗します。

この問題が原因で Apply Changes に失敗すると、Android Studio は次のメッセージを表示します。

Changes were not applied. JVMTI error: UNKNOWN_JVMTI_ERROR
    

この問題(#135172147)は、Android Studio 3.6 Canary 6 以降で修正されています。Android Studio 3.5 でこの問題を回避するには、実行アイコン 実行アイコン をクリックし、アプリを再デプロイして、変更を反映します。