このページは Cloud Translation API によって翻訳されました。

アプリをデバッグする

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. 対象デバイスのメニュー

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

プロジェクトに C / C++ コードを追加した場合は、ネイティブコードのデバッグのために、[Debug] ウィンドウ内に LLDB デバッガも実行されます。
[Debug] ウィンドウが開かない場合は、[View] > [Tool Windows] > [Debug] を選択するか、ツールウィンドウバーで [Debug] をクリックします。

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

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

[Attach debugger to Android process] ボタンをクリックします。
[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++）に応じて最適なデバッガオプションを選択します。
[OK] をクリックします。
[Debug] ウィンドウが表示されます。

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

デバッグウィンドウ

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

実行ツールバーとナビゲーションツールバー。ブレークポイントの操作をご覧ください。
スレッドセレクタ
評価と監視式のエントリ。変数を検証するをご覧ください。
スタックディスプレイ
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] タブを選択します。

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

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

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

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

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

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

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

ブレークポイントを設定すると行の横に赤い丸が表示されます（図 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 を参照）。

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

LLDB セッションビューでは [Threads] ペインは利用できませんが、[Frames] ペインのリストを使用することで、アプリプロセスにアクセスできます。これらのペインについて詳しくは、ウィンドウフレームのデバッグと変数の検査の方法に関するセクションをご覧ください。
注: ネイティブコード内のブレークポイントを検査している間、アプリの Java バイトコードを実行する仮想マシンは一時停止状態になります。そのため、ネイティブコード内のブレークポイントを検証している間は、Java デバッガを操作することや、Java デバッガセッションから状態情報を取得することができません。
Java デバッガが Java または Kotlin コード内のブレークポイントに到達すると、Android Studio の表示は自動的に [<your-module>-java] タブに切り替わります。
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] ウィンドウのオブジェクトツリーと式のエントリボックス。

監視または表示する式を入力する
[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 リリースで修正される予定です。

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

ブレークポイントでアプリが一時停止しているときに、LLDB セッションビューの [Variables] ペインに移動します。
トラッキングするメモリブロックを占有している変数を右クリックして、[Add Watchpoint] を選択します。

図 9. メモリの変数にウォッチポイントを追加する
ウォッチポイントを設定するためのダイアログが表示されます（図 9 を参照）。

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

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

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

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

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

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

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

[Variables] リストで、リソース行の任意の場所を右クリックして、リストを表示します。
リストから [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 型の数値を表示します。

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

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

アプリをデバッグする

デバッグを有効にする

Groovy

Kotlin

デバッグを開始する

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

デバッグ ウィンドウ

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

システムログを使用する

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

Kotlin

Java

Kotlin

Java

システムログを表示する

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

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

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

変数を検査する

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

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

デバッグウィンドウ

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