アプリをデバッグする

Android Studio はデバッガを備えており、以下の処理などが行えます。

  • デバイスを選択して、アプリをデバッグする。
  • Java、Kotlin、C / C++ のコード内にブレークポイントを設定する。
  • 実行時に変数や式を検証する。

このページでは、デバッガ操作の基本的な手順について説明します。詳細については、IntelliJ IDEA デバッグ ドキュメントをご覧ください。

デバッグを有効にする

デバッグを開始する前に、以下の準備をします。

使用しているデバイスでデバッグを有効にします。
エミュレータを使用している場合、デバッグはデフォルトで有効になっています。ただし、接続されているデバイスについては、デバイスの開発者向けオプションでデバッグを有効化する必要があります。
デバッグ可能なビルド バリアントを実行します。

ビルド構成内に debuggable true（Kotlin スクリプトでは isDebuggable = true）を含むビルド バリアントを使用します。

通常は、各 Android Studio プロジェクトに含まれているデフォルトの「debug」バリアントを選択します（ただし、build.gradle ファイル内には表示されません）。新しいデバッグ可能なビルドタイプを定義する場合は、ビルドタイプに debuggable true を追加する必要があります。

Groovy

android {
    buildTypes {
        customDebugType {
            debuggable true
            ...
        }
    }
}

Kotlin

android {
    buildTypes {
        create("customDebugType") {
            isDebuggable = true
            ...
        }
    }
}

このプロパティは、C / C++ コードを含むモジュールにも適用されます。

注: jniDebuggable プロパティは使用されなくなりました。

アプリが依存しているライブラリ モジュールについてもデバッグを行う場合は、デバッグ シンボルを維持するため、そのライブラリも debuggable true を指定してパッケージ化する必要があります。アプリ プロジェクトのデバッグ可能バリアントでライブラリ モジュールのデバッグ可能バリアントを確実に受け取れるようにするには、ライブラリの非デフォルト バージョンを公開してください。

デバッグを開始する

デバッグ セッションを開始する手順は次のとおりです。

  1. アプリのコードにブレークポイントを設定します。
  2. ツールバーで、対象デバイスのメニューからアプリをデバッグするデバイスを選択します。
    対象デバイスのメニュー。
    図 1. 対象デバイスのメニュー

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

  3. ツールバーの [Debug] ボタン をクリックします。

    アプリがすでにデバイスで実行されている場合は、[Run] から [Debug] に切り替えるかどうかを尋ねるダイアログが表示されます。デバッグを開始するためにデバイスを再起動する必要があります。アプリの同じインスタンスを実行し続けるには、[Cancel Debug] をクリックして、実行中のアプリにデバッガをアタッチします。それ以外の場合は、Android Studio が APK をビルドし、デバッグキーで署名して、選択したデバイスにインストールし、実行します。

    プロジェクトに C / C++ コードを追加した場合は、ネイティブ コードのデバッグのために、[Debug] ウィンドウ内に LLDB デバッガも実行されます。

  4. [Debug] ウィンドウが開かない場合は、[View] > [Tool Windows] > [Debug] を選択するか、ツール ウィンドウ バーで [Debug] をクリックします。

実行中のアプリにデバッガをアタッチする

アプリがすでにデバイス上で稼働している場合は、以下の手順により、アプリを再起動せずにデバッグを開始できます。

  1. [Attach debugger to Android process] ボタン をクリックします。
  2. [Choose Process] ダイアログで、デバッガをアタッチするプロセスを選択します。
    1. エミュレータや、ユーザーに root 権限のあるデバイスを使用している場合は、[Show all processes] をオンにすると、すべてのプロセスが表示されます。ユーザーに root 権限のあるデバイスでは、デバイスで実行されているプロセスがすべて表示されます。ユーザーに root 権限がないデバイスでは、デバッグ可能なプロセスのみが表示されます。
    2. [Use Android Debugger Settings] メニューから、既存の実行 / デバッグ構成を選択できます。C、C++ コードの場合、これにより、LLDB スタートアップ コマンド、LLDB ポストアタッチ コマンド、既存の構成のシンボル ディレクトリを再利用できるようになります。
    3. 既存の実行 / デバッグ構成がない場合は、[Create New] を選択します。これを選択すると、[Debug Type] メニューが使用可能になり、別のデバッグタイプを選択できます。デフォルトでは、Android Studio は Detect Automatically デバッグタイプを使用して、プロジェクトに含まれているコードの種類（Java または C / C++）に応じて最適なデバッガ オプションを選択します。
  3. [OK] をクリックします。

    [Debug] ウィンドウが表示されます。

Device Explorer の [Processes] タブ（[View] > [Tool Windows] > [Device Explorer]）にも、デバッグ可能なプロセスのリストがあります。そこからプロセスを選択して、強制終了 や強制停止 を行ったり、特定のプロセスにデバッガをアタッチ したりできます。

デバッグ ウィンドウ

図 2. デバッグ ウィンドウ

デバッグ ウィンドウは、次の各部分に分かれます。

  1. 実行ツールバーとナビゲーション ツールバー。ブレークポイントの操作をご覧ください。
  2. スレッド セレクタ
  3. 評価と監視式のエントリ。変数を検証するをご覧ください。
  4. スタック ディスプレイ
  5. Variables ペイン。変数を検証するをご覧ください。

注: Android Studio のデバッガとガベージ コレクタは緩く統合されています。Android 仮想マシンでは、デバッガが切断されるまで、デバッガが認識しているオブジェクトに対してガベージ コレクションは行われません。これにより、デバッガが接続されている間、オブジェクトが蓄積される可能性があります。たとえば、実行中のスレッドがデバッガに認識されている場合、それに関連付けられた Thread オブジェクトは、スレッドが終了してもデバッガが切断されるまでガベージ コレクションの対象になりません。

デバッガタイプを変更する

Java / Kotlin コードをデバッグする場合と C / C++ コードをデバッグする場合では、異なるデバッガツールが必要となるため、Android Studio デバッガでは、使用するデバッガタイプを選択できるようになっています。デフォルトでは、Android Studio はプロジェクト内で検出された言語に基づき、Detect Automatically デバッガタイプを使用して利用するデバッガを決定します。

デバッグ設定でデバッガを手動で選択するには、[Run] > [Edit Configurations] をクリックします。[Run] > [Attach debugger to Android process] をクリックして表示されるダイアログでも選択できます。

利用できる主なデバッグタイプは次のとおりです。

Detect Automatically
デバッグするコードに最適なオプションが Android Studio により自動的に選択されるようにする場合に、このデバッグタイプを指定します。たとえば、プロジェクトに C / C++ コードが含まれている場合は、自動的に Dual デバッグタイプが使用されます。それ以外の場合は、Java-Only デバッグタイプが使用されます。
Java Only
Java または Kotlin で記述されたコードのみをデバッグする場合にこのデバッグタイプを指定します。Java-Only デバッガでは、ネイティブ コード内に設定したブレークポイントやウォッチは無視されます。
Native Only（C / C++ コードが含まれている場合のみ）
LLDB のみを使用してコードをデバッグする場合に、このデバッグタイプを指定します。このデバッグタイプを使用した場合、Java デバッガのセッション ビューは利用できません。デフォルトでは、LLDB はネイティブ コードだけを検証し、Java コード内のブレークポイントを無視します。Java コードもデバッグする場合は、Detect Automatically または Dual デバッグタイプに切り替えます。

ネイティブ デバッグは、次の要件を満たすデバイスでのみ動作します。

  • デバイスが run-as をサポートしている。

    デバイスが run-as をサポートしているかどうかを確認するには、デバイスに接続されている ADB シェルで次のコマンドを実行します。

    run-as your-package-name pwd

    your-package-name はアプリのパッケージ名に置き換えてください。デバイスが run-as をサポートしていれば、コマンドはエラーなしで返されます。

  • デバイスで ptrace が有効になっている。

    ptrace が有効になっているかどうかを確認するには、デバイスに接続されている ADB シェルで次のコマンドを実行します。

    sysctl kernel.yama.ptrace_scope

    ptrace が有効な場合、コマンドは値 0 または unknown key エラーを出力します。ptraceが有効でない場合は、0 以外の値を出力します。

Dual（Java + ネイティブ）- C / C++ コードでのみ利用可能
Java とネイティブ コードの両方のデバッグを切り替えながら行う場合にこのデバッグタイプを指定します。Java デバッガと LLDB の両方がアプリプロセスにアタッチされます。そのため、アプリの再起動やデバッグ構成の変更を必要とすることなく、Java コードとネイティブ コードの両方のブレークポイントを検査できます。

図 2 のように、[Debug] ウィンドウのタイトルの右側に、2 つのタブが表示されます。 タブが 2 つあるのは、アプリに Java コードと C++ コードの両方が含まれているためであり、1 つのタブはネイティブ コードのデバッグ用で、もう 1 つのタブ（「-java」付き）は Java コードのデバッグ用になります。

図 3. ネイティブ コードをデバッグするためのタブと Java コードをデバッグするためのタブ

注: コンパイラによって最適化されたネイティブ コードをデバッグしていると、次のような警告メッセージが表示される場合があります。
「This function was compiled with optimizations enabled. Some debugger features may not be available.」最適化フラグを使用した場合、コンパイラは、効率的な実行のためコンパイル済みコードに変更を加えます。最適化されたコンパイル結果のコードは元のソースコードにマッピングするのが困難なため、デバッガから想定外の情報や誤った情報が返される可能性があります。 そのため、ネイティブ コードをデバッグする際は、コンパイラの最適化を無効にする必要があります。

システムログを使用する

アプリのデバッグ中は、システムログにシステム メッセージが表示されます。このメッセージには、デバイス上で実行されているアプリの情報が含まれています。システムログを使用してアプリをデバッグする場合は、アプリの開発段階で、確実にコードからログメッセージが書き込まれ、例外のスタック トレースが出力されるようにしてください。

コードを使用してログメッセージを書き込む

コードを使用してログメッセージを書き込むには、 Log クラスを使用します。ログメッセージを活用すると、アプリを操作しているときのシステム デバッグ出力を収集して、実行フローを把握できます。ログメッセージから、アプリ内のエラーを発見することもできます。ログについて詳しくは、logcat を使用してログを書き込み、表示するをご覧ください。

アクティビティを開始する際に以前の状態情報が利用できるかどうかを判定するために、ログメッセージを追加する方法を、次のサンプルコードに示します。

Kotlin

import android.util.Log
...
class MyActivity : Activity() {
    ...
    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        if (savedInstanceState != null) {
            Log.d(TAG, "onCreate() Restoring previous state")
            /* restore state */
        } else {
            Log.d(TAG, "onCreate() No saved state available")
            /* initialize app */
        }
        ...
    }
  ...
  companion object {
    private val TAG: String = MyActivity::class.java.simpleName
    ...
  }
}

Java

import android.util.Log;
...
public class MyActivity extends Activity {
    private static final String TAG = MyActivity.class.getSimpleName();
    ...
    @Override
    public void onCreate(Bundle savedInstanceState) {
       ...
       if (savedInstanceState != null) {
            Log.d(TAG, "onCreate() Restoring previous state");
            /* restore state */
        } else {
            Log.d(TAG, "onCreate() No saved state available");
            /* initialize app */
        }
        ...
    }
}

開発中に、コードを使用して例外を検出し、スタック トレースをシステムログに書き込むことができます。

Kotlin

fun someOtherMethod() {
    try {
        ...
    } catch (e : SomeException) {
        Log.d(TAG, "someOtherMethod()", e)
    }
}

Java

void someOtherMethod() {
    try {
        ...
    } catch (SomeException e) {
        Log.d(TAG, "someOtherMethod()", e);
    }
}

注: アプリを公開する準備ができたら、デバッグ ログメッセージとスタック トレース出力の呼び出しをコードから削除します。そのためには、DEBUG フラグをセットして、条件ステートメント内にデバッグ ログメッセージを配置します。

システムログを表示する

[Logcat] ウィンドウで、デバッグ メッセージや各種システム メッセージの表示やフィルタを行えます（図 4 を参照）。たとえば、ガベージ コレクションが発生したときのメッセージや、Log クラスを使用してアプリに追加したメッセージを表示できます。

Logcat を使用するには、デバッグを開始し、[Logcat] タブを選択します。

図 4. [Logcat] ウィンドウとフィルタ設定

Logcat とフィルタ オプションの詳細については、Logcat を使用したログの出力と確認をご覧ください。

ブレークポイントを利用する

Android Studio は、さまざまなデバッグ アクションをトリガーするブレークポイントをサポートしています。ブレークポイントにはいくつかの種類があります。

行ブレークポイント
最も一般的なタイプは、コード内の指定行でアプリの実行を一時停止する行ブレークポイントです。実行が一時停止しているときに、変数や式を検証し、1 行ずつ実行を続けることで、ランタイム エラーの原因を特定することができます。
メソッド ブレークポイント
メソッド ブレークポイントは、特定のメソッドの開始時または終了時にアプリの実行を一時停止します。実行が一時停止しているときに、変数や式を検証し、1 行ずつ実行を続けることで、ランタイム エラーの原因を特定することができます。コンポーズ可能な関数にブレークポイントを設定すると、デバッガはコンポーズ可能なパラメータとその状態を一覧表示し、再コンポーズを引き起こした可能性のある変更を特定できるようにします。
フィールド ブレークポイント
フィールド ブレークポイントは、特定のフィールドに対する読み書きが行われたときに、アプリの実行を一時停止します。
例外ブレークポイント
例外ブレークポイントは、例外がスローされたときにアプリの実行を一時停止します。

条件付きブレークポイントを設定すると、特定の条件が満たされた場合にのみ実行を一時停止することができます。ロギング ブレークポイントを設定すると、実行を一時停止せずに Logcat に書き込むことができます。これにより、ログ ステートメントでコードを簡潔にすることができます。

行ブレークポイントを追加するには:

  1. 実行を一時停止するコード行を特定します。
  2. その行の左側の余白をクリックするか、その行にキャレットを置いて Ctrl+F8（macOS では Command+F8）キーを押します。
  3. アプリがすでに実行されている場合は、[Attach debugger to Android process] アイコン（）をクリックします。それ以外の場合は、[Debug] アイコン（）をクリックしてデバッグを開始します。

ブレークポイントを設定すると行の横に赤い丸が表示されます（図 5 を参照）。

図 5. ブレークポイントを設定すると行の横に赤い丸が表示される

コード実行がブレークポイントの位置に到達すると、アプリの実行が一時停止されます。

アプリの状態を特定するには、[Debugger] タブのツールを使用します。

  • 変数のオブジェクト ツリーを検証するには、[Variables] ビューで、そのツリーを展開します。[Variables] ビューが表示されていない場合は、[Layout Settings] をクリックして [variables] がオンになっていることを確認します。

  • メソッドには入らずに次のコード行に進むには、[Step Over]（）をクリックします。

  • メソッド呼び出しの 1 行目に進むには、[Step Into]（）をクリックします。

  • 現在のメソッドを抜けて次の行に進むには、[Step Out]（）をクリックします。

  • アプリの通常の実行を続けるには、[Resume Program]（）をクリックします。

プロジェクトでネイティブ コードを使用している場合は、デフォルトで Detect Automatically デバッグタイプが選択され、Java デバッガと LLDB の両方が 2 つの異なるプロセスとしてアプリにアタッチされます。アプリの再起動や設定の変更を行うことなく、Java と C / C++ のブレークポイントの検査を切り替えることができます。

注: Android Studio で C / C++ コード内のブレークポイントを検出するには、Detect Automatically、Native、Dual など、LLDB をサポートするデバッグタイプを使用する必要があります。デバッグ構成を編集することにより、Android Studio で使用するデバッグタイプを変更できます。各デバッグタイプの詳細については、他のデバッグタイプを使用するのセクションをご覧ください。

Android Studio がターゲット デバイスにアプリをデプロイすると、デバッガ プロセスごとのタブやデバッグ セッション ビューを備えた [Debug] ウィンドウが開きます（図 6 を参照）。

図 6. LLDB を使用してネイティブ コードをデバッグする
  1. LLDB デバッガが C / C++ コード内のブレークポイントに到達すると、Android Studio によって自動的に [<your-module>] タブに切り替わります。[Frames] ペイン、[Variables] ペイン、[Watches] ペインも利用できます。各パネルは、Java コードをデバッグする場合と同じように機能します。

    LLDB セッション ビューでは [Threads] ペインは利用できませんが、[Frames] ペインのリストを使用することで、アプリプロセスにアクセスできます。これらのペインについて詳しくは、ウィンドウ フレームのデバッグと変数の検査の方法に関するセクションをご覧ください。

    注: ネイティブ コード内のブレークポイントを検査している間、アプリの Java バイトコードを実行する仮想マシンは一時停止状態になります。そのため、ネイティブ コード内のブレークポイントを検証している間は、Java デバッガを操作することや、Java デバッガ セッションから状態情報を取得することができません。

  2. Java デバッガが Java または Kotlin コード内のブレークポイントに到達すると、Android Studio の表示は自動的に [<your-module>-java] タブに切り替わります。
  3. LLDB を使用してデバッグしているときに LLDB セッション ビュー内で LLDB ターミナルを使用すると、コマンドライン オプションを LLDB に渡すことができます。アプリの毎回のデバッグで（アプリプロセスにデバッガをアタッチする直前または直後に）LLDB に実行させたい特定のコマンドがある場合は、そのコマンドをデバッグ設定に追加しておくと便利です。

C / C++ コードをデバッグする際、「ウォッチポイント」と呼ばれる特別なタイプのブレークポイントを設定できます。ウォッチポイントを使用すると、アプリで特定のメモリブロックを操作したときに、アプリプロセスを一時停止させることができます。詳細については、ウォッチポイントを追加する方法についてのセクションをご覧ください。

ブレークポイントを表示、設定する

すべてのブレークポイントを表示してブレークポイント設定を指定するには、[Debug] ウィンドウにある [View Breakpoints]（）をクリックします。[Breakpoints] ウィンドウが表示されます（図 7 を参照）。

図 7. 現在のすべてのブレークポイントをリスト表示し、各ブレークポイントの動作設定を表示する [Breakpoints] ウィンドウ

[Breakpoints] ウィンドウのペインのリストから各ブレークポイントの有効 / 無効を切り替えることができます。ブレークポイントを無効にすると、そのブレークポイントにヒットしても、アプリは一時停止されません。

リストからブレークポイントを選択すると、その設定を行えます。一度ブレークポイントを無効にしておいて、別のブレークポイントにヒットした後に最初のブレークポイントを有効化するように設定することもできます。また、ヒット後にブレークポイントを無効にするかどうかも設定できます。例外用のブレークポイントを設定するには、ブレークポイント リストで [Exception Breakpoints] を選択します。

すべてのブレークポイントを一時的に無効にするには、[Debug] ウィンドウにある [Mute Breakpoints]（）をクリックします。もう一度クリックすると、有効になります。

ウィンドウ フレームをデバッグする

[Debugger] ウィンドウの [Frames] ペインで、現在のブレークポイントにヒットした原因となったスタック フレームを検査できます。このパネルでは、スタック フレームに移動して調査したり、Android アプリ内のスレッドリストを検証したりすることができます。

スレッドを選択するには、スレッド セレクタのメニューを使用して、そのスタック フレームを表示します。フレーム内の要素をクリックすると、エディタでソースが開きます。また、スレッド表示方法のカスタマイズや、スタック フレームのエクスポートも可能です。詳細については、フレームの確認に関するガイドをご覧ください。

変数を検査する

[Debugger] ウィンドウの [Variables] ペインでは、アプリがブレークポイントで停止したとき、[Frames] ペインでフレームを選択して変数を検査できます。[Variables] ペインでは、静的な方法で、または選択したフレーム内で利用可能な変数を使用してその時点の式を評価することもできます。

（アプリのデバッグ中に）オブジェクト ツリーに式を追加するには:

図 8. [Debug] ウィンドウのオブジェクト ツリーと式のエントリ ボックス。
  1. 監視または表示する式を入力する
  2. [Add to watches] をクリックするか、Enter キーを押して式を 1 回評価します。

また、監視する式がオブジェクト ツリーに含まれている場合は、式をツリーの最上部にドラッグして監視対象の式として追加できます。

ブレークポイントに達したとき、またはコードをステップ実行したときに、監視対象の式が更新されます。

評価された式は、別の式を手動で評価するか、コードをステップ実行するまで、オブジェクト ツリーの上部に表示されます。

オブジェクト ツリーから監視対象の式を削除するには、式を右クリックして [Remove Watch] をクリックします。

ウォッチポイントを追加する

C / C++ コードをデバッグする際、「ウォッチポイント」と呼ばれる特別なタイプのブレークポイントを設定できます。ウォッチポイントを使用すると、アプリで特定のメモリブロックを操作したときに、アプリプロセスを一時停止させることができます。たとえば、あるメモリブロックに 2 つのポインタを設定し、そのメモリブロックにウォッチポイントを割り当てた場合、いずれかのポインタを使用してそのメモリブロックにアクセスすると、ウォッチポイントがトリガーされます。

Android Studio では、ランタイムに特定の変数を選択してウォッチポイントを作成できますが、LLDB でのウォッチポイントの割り当ては、変数そのものに対してではなく、その変数に割り当てられたメモリブロックに対して行われます。これは、変数を [Watches] ペインに追加することとは異なります。変数をこのペインに追加した場合は、変数の値をモニタリングすることはできますが、メモリ内の値が読み取られた場合や、変更された場合にアプリプロセスを一時停止させることはできません。

注: アプリプロセスで関数が終了し、ローカル変数に割り当てられていたメモリが解放されたら、その変数に対するウォッチポイントを再度割り当てる必要があります。

ウォッチポイントを設定するには、次の要件を満たす必要があります。

  • ターゲットの実機またはエミュレータの CPU が x86 または x86_64 であること。デバイスの CPU が ARM の場合は、メモリ内の変数のアドレス境界を、32 ビット プロセッサでは 4 バイトの倍数、64 ビット プロセッサでは 8 バイトの倍数にそろえること。ネイティブ コード内で変数のアライメントを行うには、次に示すように、変数宣言で __attribute__((aligned(num_bytes))) を指定します。
    // For a 64-bit ARM processor
int my_counter __attribute__((aligned(8)));
  • すでに割り当て済みのウォッチポイントが 3 つ以下である必要があります。x86 または x86_64 のターゲット デバイスの場合、Android Studio がサポートするウォッチポイントの数は最大で 4 つです。他のデバイスの場合は、サポートされるウォッチポイントの数がそれよりも少ない可能性があります。

注: 32 ビット ARM ABI を使用してアプリをデバッグする場合、ウォッチポイントを追加したり、コード内の変数にカーソルを合わせて値を調べたりとすると、クラッシュすることがあります。回避策としては、64 ビット ARM、x86、または x86_64 のバイナリを使用してデバッグします。この問題は、今後の Android Studio リリースで修正される予定です。

要件を満たしている場合は、次の手順でウォッチポイントを追加できます。

  1. ブレークポイントでアプリが一時停止しているときに、LLDB セッション ビューの [Variables] ペインに移動します。

  2. トラッキングするメモリブロックを占有している変数を右クリックして、[Add Watchpoint] を選択します。

    図 9. メモリの変数にウォッチポイントを追加する

  3. ウォッチポイントを設定するためのダイアログが表示されます（図 9 を参照）。

    以下のオプションを使用して、ウォッチポイントを設定します。

    • Enabled: 設定を変更するまでこのウォッチポイントを無視するように Android Studio に指示する場合は、このオプションのチェックボックスをオフにします。後でアクセスできるように、Android Studio によりウォッチポイントが保存されます。
    • Suspend: デフォルトでは、ウォッチポイントに割り当てられたメモリブロックがアクセスされると、アプリプロセスは一時停止します。 この動作を望まない場合は、このオプションの選択を解除します。すると、システムがウォッチポイントとやり取りする際の動作をカスタマイズするために使用できる追加のオプション（[Log message to console]、[Remove when hit]）が表示されます。
    • Access Type: 変数に割り当てられたメモリブロックに対してアプリから [Read] または [Write] を試行したときに、ウォッチポイントをトリガーするかどうかを選択します。読み取りと書き込みのいずれでもウォッチポイントをトリガーするには、[Any] を選択します。
  4. [Done] をクリックします。

すべてのウォッチポイントを表示し、ウォッチポイント設定を指定するには、[Debug] ウィンドウにある [View Breakpoints]（）をクリックします。[Breakpoints] ダイアログが表示されます（図 10 を参照）。

図 10. 現在のすべてのウォッチポイントをリスト表示し、各ウォッチポイントの動作設定を表示する [Breakpoints] ダイアログ

ウォッチポイントを追加した後、[Debug] ウィンドウにある [Resume Program]（）をクリックすると、アプリプロセスを再開できます。デフォルトでは、ウォッチポイントを設定したメモリブロックに対してアプリからアクセスしようとすると、アプリプロセスが一時停止状態になり、アプリで最後に実行されたコード行の横にウォッチポイント アイコン が表示されます（図 11 を参照）。

図 11. ウォッチポイントがトリガーされる直前にアプリで実行されたコード行が表示される

リソース値の表示と表示形式の変更

デバッグモードでは、Java または Kotlin コード内の変数について、リソース値の表示と別の表示形式の選択を行うことができます。[Variables] タブを表示してフレームを選択し、次の手順を行います。

  1. [Variables] リストで、リソース行の任意の場所を右クリックして、リストを表示します。
  2. リストから [View as] を選択して、使用する形式を選択します。

    使用できる形式は、選択したリソースのデータタイプによって異なります。 以下のようなオプションが 1 つまたは複数表示されます。

    • Class: クラスの定義を表示します。
    • toString: 文字列形式を表示します。
    • Object: オブジェクト（クラスのインスタンス）の定義を表示します。
    • Array: 配列形式で表示します。
    • Timestamp: yyyy-mm-dd hh:mm:ss 形式で日時を表示します。
    • Auto: データタイプに基づいて Android Studio が最適な形式を選択します。
    • Binary: 0 と 1 を使用して 2 進値を表示します。
    • MeasureSpec: 親から、選択された子に渡された値です （MeasureSpec. を参照）。
    • Hex: 16 進値として表示します。
    • Primitive: プリミティブ型を使用して数値として表示します。
    • Integer: Integer 型の数値を表示します。

カスタム フォーマットを作成する手順は次のとおりです。

  1. リソース値を右クリックします。
  2. [View as] を選択します。
  3. [作成] を選択します。
  4. [Java Data Type Renderers] ダイアログが表示されます。Java Data Type Renderers の手順に沿って設定します。