Android Debug Bridge（adb）

Android Debug Bridge（adb）は、デバイスと通信するための多用途のコマンドライン ツールです。adb コマンドを使用すると、アプリのインストールやデバッグなど、さまざまなデバイス操作を実行できます。adb を使用すると、デバイスでさまざまなコマンドを実行する際に使用する Unix シェルにアクセスできるようになります。adb は、以下の 3 つのコンポーネントで構成されるクライアント サーバー プログラムです。

  • クライアント: コマンドを送信します。クライアントは開発マシンで稼働します。adb コマンドを発行することにより、コマンドライン ターミナルからクライアントを呼び出すことができます。
  • デーモン（adbd）: デバイスでコマンドを実行します。デーモンは、各デバイスでバックグラウンド プロセスとして稼働します。
  • サーバー: クライアントとデーモン間の通信を管理します。サーバーは、開発マシンでバックグラウンド プロセスとして稼働します。

adb は、Android SDK Platform-Tools パッケージに含まれています。このパッケージは SDK Manager を使ってダウンロードします。SDK Manager はこのパッケージを android_sdk/platform-tools/ にインストールします。スタンドアロンの Android SDK Platform Tools パッケージが必要な場合は、こちらからダウンロードします。

Connection Assistant を使用して一般的な問題のトラブルシューティングを行う方法など、adb 経由で使用するためにデバイスを接続する方法については、ハードウェア デバイス上でのアプリの実行をご覧ください。

adb の仕組み

adb クライアントを起動すると、まず稼働中の adb サーバー プロセスがすでに存在していないかどうかがチェックされます。サーバー プロセスが存在しない場合は、クライアントによりサーバー プロセスが起動します。 起動したサーバーは、ローカル TCP ポート 5037 にバインドされ、adb クライアントから送信されるコマンドをリッスンします。

注: adb クライアントはすべて、ポート 5037 を使用して adb サーバーと通信します。

その後、サーバーは稼働中のすべてのデバイスへの接続を確立します。次にエミュレータを検出するため、最初の 16 台のエミュレータが使用する 5555～5585 の範囲で奇数番号のポートをスキャンします。サーバーが adb デーモン（adbd）を検出すると、そのポートへの接続を確立します。

各エミュレータは、連続したポートのペアを使用します（コンソール接続用の偶数番号のポートと adb 接続用の奇数番号のポート）。次に例を示します。

エミュレータ 1、コンソール: 5554
エミュレータ 1、adb: 5555
エミュレータ 2、コンソール: 5556
エミュレータ 2、adb: 5557
など。

上記のように、ポート 5555 で adb に接続しているエミュレータは、ポート 5554 でコンソールがリッスンするエミュレータと同一になります。

サーバーがすべてのデバイスへの接続を確立すると、adb コマンドを使用して各デバイスにアクセスできるようになります。デバイスへの接続を管理し、複数の adb クライアントから送信されるコマンドを処理するのはサーバーであるため、どのクライアント（またはスクリプト）からでもあらゆるデバイスを制御できます。

デバイスで adb デバッグを有効にする

USB 接続したデバイスで adb を使用するには、デバイスのシステム設定で、[開発者向けオプション] の [USB デバッグ] を有効にする必要があります。Android 4.2（API レベル 17）以降では、[開発者向けオプション] 画面はデフォルトで非表示となっています。これを表示するには、開発者向けオプションを有効にします。

これで、デバイスと USB を接続できるようになります。デバイスが接続されていることを確認するには、android_sdk/platform-tools/ ディレクトリから adb devices を実行します。接続されていれば、デバイス名が「device」のリストに表示されます。

注: Android 4.2.2（API レベル 17）以上を搭載するデバイスを接続すると、このパソコン経由のデバッグを許可する RSA キーを受け入れるかどうかを尋ねるダイアログが表示されます。RSA キーは、ユーザー デバイスのセキュリティを保護するための仕組みです。デバイスのロックを解除してこのダイアログで了承しない限り、USB デバッグや他の adb コマンドは実行できません。

USB 経由でデバイスに接続する方法について詳しくは、ハードウェア デバイス上でのアプリの実行をご覧ください。

Wi-Fi 経由でデバイスに接続する

注: 下記の手順は、Android 11（API レベル 30）を搭載した Wear デバイスには適用されません。詳細については、Wear OS アプリのデバッグに関するガイドをご覧ください。

Android 11（API レベル 30）以降では、Android Debug Bridge（adb）を使用して、ワークステーションからアプリをワイヤレスでデプロイおよびデバッグできます。たとえば、デバッグ可能なコンテナを アプリを複数のリモート デバイスに接続できます。デバイスの接続に USB。これにより、ドライバ インストールできます。

ワイヤレス デバッグの利用を開始するには、まず次の手順を行ってください。

  • ワークステーションとデバイスが同じワイヤレス ネットワークに接続されていることを確認します。

  • スマートフォンの場合は、デバイスに Android 11（API レベル 30）以上が搭載されていること、テレビと WearOS の場合は、Android 13（API レベル 33）以上が搭載されていることを確認します。詳しくは、Android のバージョンを確認して更新するをご覧ください。

  • IDE を使用している場合は、Android Studio の最新バージョンがインストールされていることを確認してください。Android Studio Bumblebee はこちらからダウンロードできます。

  • ワークステーションで SDK Platform-Tools を最新バージョンに更新します。

ワイヤレス デバッグを使用するには、QR コードまたはペア設定コードを使用して、デバイスをワークステーションとペア設定する必要があります。ワークステーションとデバイスは同じワイヤレス ネットワークに接続する必要があります。デバイスに接続する手順は次のとおりです。

  1. デバイスの開発者向けオプションを有効にします。

  2. Android Studio を開き、実行構成メニューから [Pair Devices Using Wi-Fi] を選択します。

    実行構成のプルダウン メニュー
    図 1. 実行構成メニュー。

    図 2 のように、[Pair devices over Wi-Fi] ウィンドウが表示されます。

    [Pair devices over Wi-Fi] ポップアップ ウィンドウのスクリーンショット
    図 2. QR コードまたはペア設定コードを使用してデバイスをペア設定するためのポップアップ ウィンドウ

  3. デバイスで [ワイヤレス デバッグ] をタップして、デバイスをペア設定します。

    ワイヤレス デバッグ システムの設定を表示している Google Pixel のスクリーンショット。
    図 3. Google Pixel の [ワイヤレス デバッグ] 設定のスクリーンショット。

    1. デバイスを QR コードでペア設定するには、[QR コードによるデバイスのペア設定] を選択し、図 2 のように [Pair devices over Wi-Fi] ポップアップで取得した QR コードをスキャンします。

    2. デバイスをペア設定コードでペア設定するには、前述の [Pair devices over Wi-Fi] ポップアップで [Pair device with pairing code] を選択します。デバイスで [ペア設定コードによるデバイスのペア設定] を選択し、表示された 6 桁のコードをメモします。デバイスが [Pair devices over Wi-Fi] ウィンドウに表示されたら、[Pair] を選択して、デバイスに表示された 6 桁のコードを入力します。

      PIN コード入力の例のスクリーンショット
      図 4. 6 桁のコード入力の例。

  4. ペア設定が完了すると、アプリをデバイスにデプロイできるようになります。

    別のデバイスをペア設定する場合、またはワークステーションからこのデバイスを削除する場合は、デバイスで [ワイヤレス デバッグ] に移動して、[ペア設定済みのデバイス] からワークステーション名を選んでタップし、[削除] を選択します。

  5. ワイヤレス デバッグのオンとオフをすばやく切り替えるには、ワイヤレス デバッグにクイック設定開発者用タイルを利用します（[開発者向けオプション] > [クイック設定開発者用タイル]）。

    Google Pixel のクイック設定開発者用タイルのスクリーンショット。
    図 5. [クイック設定開発者用タイル] 設定を使用すると、ワイヤレス デバッグのオンとオフをすばやく切り替えられます。

コマンドラインを使用した Wi-Fi 接続

または、Android Studio を使用せずにコマンドラインからデバイスに接続するには、次の手順を実施します。

  1. 前述のとおり、デバイスで開発者向けオプションを有効にします。

  2. 前述のとおり、デバイスで [ワイヤレス デバッグ] を有効にします。

  3. ワークステーションでターミナル ウィンドウを開いて、android_sdk/platform-tools に移動します。

  4. [ペア設定コードによるデバイスのペア設定] を選択して、IP アドレス、ポート番号、ペア設定コードを確認します。デバイスに表示された IP アドレス、ポート番号、ペア設定コードをメモしておきます。

  5. ワークステーションのターミナルで adb pair ipaddr:port を実行します。前述の IP アドレスとポート番号を使用します。

  6. メッセージが表示されたら、下図のようにペア設定コードを入力します。

    コマンドラインでのペア設定のスクリーンショット。
    図 6. デバイスが正常にペア設定されたことを示すメッセージ。

ワイヤレス接続の問題を解決する

デバイスへのワイヤレス接続で問題が発生した場合は、次のトラブルシューティング手順に沿って、問題の解決をお試しください。

ワークステーションとデバイスが前提条件を満たしているかどうかを確認する

ワークステーションとデバイスが、このセクションの冒頭に記載されている前提条件を満たしていることを確認します。

その他の既知の問題を確認する

ワイヤレス デバッグ（adb または Android）を使用した既知の問題のリストは次のとおりです。 およびその解決方法を確認します。

  • Wi-Fi に接続できない: 企業の Wi-Fi ネットワークなどの安全な Wi-Fi ネットワーク により P2P 接続がブロックされ、Wi-Fi 経由で接続できない場合があります。ケーブルまたは 別の（会社外の）Wi-Fi ネットワーク。以下を使用したワイヤレス接続: TCP/IP 経由の adb connect ip:port（最初の USB 接続後）を使用する方法もあります。 という選択肢もあります

  • Wi-Fi 経由の adb が自動的にオフになることがある: デバイスが Wi-Fi ネットワークを切り替えた場合、またはネットワークから切断された場合に発生することがあります。解決するには、ネットワークに再接続します。

  • ペア設定後にデバイスが接続されない: adb は mDNS を使用して接続しています ペア設定されたデバイスを検出して自動的に接続します。ご利用のネットワークやデバイスが 設定で mDNS がサポートされていないか、mDNS が無効になっている場合は、手動で adb connect ip:port を使用してデバイスに接続します。

最初の USB 接続後にデバイスとワイヤレスで接続する（Android 10 以前でのみ利用可能）

注: このワークフローは、Android 11（および それよりも高い場合）は、物理的な USB 経由での「初期」接続も必要になることに注意してください。

注: 次の手順は、Android 10（API レベル 29）以前を搭載した Wear デバイスには適用されません。詳細については、Wear OS アプリのデバッグについてのガイドをご覧ください。

adb は通常 USB 経由でデバイスと通信しますが、Wi-Fi 経由で adb を使用することもできます。Android 10（API レベル 29）以前を搭載しているデバイスを USB 経由で接続するには、これらの初期手順に沿って行ってください。

  1. Android デバイスと adb ホスト コンピュータを、共通の Wi-Fi ネットワークに接続します。

    2. 注: 必ずしもすべてのアクセス ポイントが適切であるとは限りません。場合によって、adb を適切にサポートするようファイアウォールが設定されているアクセス ポイントを使用する必要があります。

  2. USB ケーブル経由で、デバイスとホスト コンピュータを接続します。
  3. ポート 5555 で TCP/IP 接続をリッスンするように対象デバイスを設定します。 
    adb tcpip 5555
  4. 対象デバイスから USB ケーブルを切り離します。
  5. Android デバイスの IP アドレスを確認します。たとえば、Nexus デバイスの場合、[設定] > [タブレット情報]（または、[デバイス情報]）> [デバイスの状態] > [IP アドレス] で、IP アドレスを確認できます。
  6. 確認した IP アドレスを使用して、デバイスに接続します。 
    adb connect device_ip_address:5555
  7. ホスト コンピュータが対象デバイスに接続していることを確認します。 
    $ adb devices
List of devices attached
device_ip_address:5555 device

デバイスが adb に接続されました。

デバイスへの adb 接続が失われた場合は以下の手順を行います。

  • Android デバイスと同じ Wi-Fi ネットワークにホストが接続したままかどうか確認します。
  • adb connect のステップを再度実行して再接続します。
  • それでも問題が解決しない場合は、adb ホストをリセットします。
    adb kill-server

    その後、最初からやり直します。

デバイスのクエリを行う

adb コマンドを発行する前に、どのデバイス インスタンスが adb サーバーに接続しているのか把握しておくと便利です。devices コマンドを使用すると、接続済みデバイスのリストが生成されます。

  adb devices -l

このコマンドのレスポンスとして、adb は、各デバイスに関する以下のステータス情報を出力します。

  • シリアル番号: adb は、ポート番号でデバイスを一意に識別する文字列を作成します。 シリアル番号の例: emulator-5554
  • 状態: デバイスの接続状態を示します。次のいずれかになります。
    • offline: デバイスが adb に接続していないか、応答していません。
    • device: デバイスが adb サーバーに接続されています。この状態は、Android システムが完全に起動して動作中であることを示しているわけではありません。デバイスは Android システムの起動中に adb に接続します。システムの起動が完了した後、デバイスは通常、この動作状態になります。
    • no device: 接続されているデバイスがありません。
  • 説明: devices コマンドに -l オプションを追加すると、デバイスの説明が表示されます。この情報から、複数のデバイスを接続している場合に、デバイスを区別できます。

devices コマンドとその出力の例を以下に示します。ここでは、稼働中のデバイスが 3 つあります。リストの最初の 2 行はエミュレータを示し、3 行目はコンピュータに接続されたハードウェア デバイスを示します。

$ adb devices
List of devices attached
emulator-5556 device product:sdk_google_phone_x86_64 model:Android_SDK_built_for_x86_64 device:generic_x86_64
emulator-5554 device product:sdk_google_phone_x86 model:Android_SDK_built_for_x86 device:generic_x86
0a388e93      device usb:1-1 product:razor model:Nexus_7 device:flo

エミュレータがリスト内に表示されないケース

adb devices コマンドのコマンド シーケンスによっては、まれに、実行中のエミュレータがパソコン上には表示されていても adb devices 出力内には表示されないというケースが発生することがあります。この状況が発生するのは、以下のすべての条件を満たす場合です。

  • adb サーバーが実行されていない。
  • emulator コマンドを使用する際、-port オプションまたは -ports オプションを追加し、5554～5584 の範囲内の奇数番号ポート値を指定した。
  • 選択した奇数番号ポートがビジー状態でなく、指定のポート番号でポート接続を確立できたか、あるいは、選択した奇数番号ポートがビジー状態で、「条件 2」を満たすポートにエミュレータが切り替えた。
  • エミュレータを起動した後に、adb サーバーを起動した。

この状況を回避する方法の一つとして、エミュレータに独自のポートを選択させ、一度に 16 台を超えるエミュレータを稼働しないようにする、という方法があります。他にも、以下の例に示すように、emulator コマンドを使用する前に常に adb サーバーを起動しておく、という方法があります。

例 1: 次のコマンド シーケンスの場合、adb devices コマンドは adb サーバーを起動しますが、デバイスのリストは表示しません。

adb サーバーを停止して、以下のコマンドを、記載の順に入力します。AVD 名には、ご利用のシステムに応じて有効な AVD 名を入力してください。AVD 名のリストを取得するには、emulator -list-avds と入力します。emulator コマンドは android_sdk/tools ディレクトリにあります。 

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5555
$ adb devices

List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *

例 2: 次のコマンド シーケンスの場合、adb サーバーが先に起動してから、adb devices によってデバイスのリストが表示されます。

adb devices の出力でエミュレータを確認するには、次のように、adb サーバーを停止してから、emulator コマンドを使用した後、adb サーバーを再起動して、adb devices コマンドを使用します。 

$ adb kill-server
$ emulator -avd Nexus_6_API_25 -port 5557
$ adb start-server
$ adb devices

List of devices attached
emulator-5557 device

エミュレータのコマンドライン オプションについて詳しくは、コマンドライン起動オプションをご覧ください。

特定のデバイスにコマンドを送信する

複数のデバイスを実行している場合は、対象デバイスを指定する必要があります。 adb コマンドを発行するとき。 ターゲットを指定する手順は次のとおりです。

  1. devices コマンドを使用して、対象のシリアル番号を取得します。
  2. シリアル番号を取得したら、adb コマンドで -s オプションを使用して、シリアル番号を指定します。
    1. 多くの adb コマンドを発行する場合は、代わりに $ANDROID_SERIAL 環境変数を設定してシリアル番号を指定できます。
    2. -s と $ANDROID_SERIAL を両方使用した場合、-s が $ANDROID_SERIAL より優先されます。

次の例では、接続されているデバイスのリストを取得し、該当デバイスのシリアル番号を使用してデバイスに helloWorld.apk をインストールします。 

$ adb devices
List of devices attached
emulator-5554 device
emulator-5555 device
0.0.0.0:6520  device

# To install on emulator-5555
$ adb -s emulator-5555 install helloWorld.apk
# To install on 0.0.0.0:6520
$ adb -s 0.0.0.0:6520 install helloWorld.apk

注: 対象デバイスを指定せずにコマンドを発行した場合 複数のデバイスを使用できる場合、adb にエラーが表示される 「adb: more device/emulator」

複数のデバイスが利用できるときに、その中にエミュレータが 1 つしかない場合は、-e オプションを使用することで、そのエミュレータにコマンドを送信できます。複数のデバイスが存在するときに、その中にハードウェア デバイスが 1 つしかない場合は、-d オプションを使用することで、そのハードウェア デバイスにコマンドを送信できます。

アプリをインストールする

install で adb コマンドを使用して、エミュレータまたは接続されたデバイスに APK をインストールできます。

adb install path_to_apk

テスト APK をインストールする場合は、install コマンドで -t オプションを使用する必要があります。詳細については -t をご覧ください。

複数の APK をインストールするには、install-multiple を使用します。これは、すべてのファイルを 特定のデバイス用の APK を Google Play Console からダウンロードし、 エミュレータまたは実機で接続します

エミュレータまたはデバイスのインスタンス上にインストール可能な APK ファイルを作成する方法については、アプリをビルドして実行するをご覧ください。

注: Android Studio を使用する場合は、エミュレータまたはデバイス上にアプリをインストールするのに adb を直接使用する必要はありません。代わりに、Android Studio がアプリのパッケージ化とインストールを処理します。

ポート転送をセットアップする

forward コマンドを使用して任意のポート転送をセットアップし、特定のホストポート上のリクエストを別のポートに転送できます。ホストポート 6100 からデバイスポート 7100 へのポート転送をセットアップする例を以下に示します。 

adb forward tcp:6100 tcp:7100

ホストポート 6100 から local:logd へのポート転送をセットアップする例を以下に示します。 

adb forward tcp:6100 local:logd

これは、デバイスの特定のポートに送信されるものを判断しようとする場合に使用できます。受信したデータはすべてシステム ロギング デーモンに書き込まれ、デバイスのログに表示されます。

デバイスにファイルをコピーする、デバイスからファイルをコピーする

pull コマンドと push コマンドを使用して、デバイスから、またはデバイスにファイルをコピーします。特定の場所に APK ファイルをコピーするだけの install コマンドとは異なり、pull コマンドと push コマンドを使用すると、デバイス内の任意の場所に任意のディレクトリやファイルをコピーできます。

デバイスからファイルやディレクトリ（およびそのサブディレクトリ）をコピーするには、次のコマンドを使用します。 

adb pull remote local

デバイスにファイルやディレクトリ（およびそのサブディレクトリ）をコピーするには、次のコマンドを使用します。 

adb push local remote

local と remote は、ご利用の開発マシン（ローカル）とデバイス（リモート）の対象ファイル / ディレクトリのパスに置き換えてください。次に例を示します。

adb push myfile.txt /sdcard/myfile.txt

adb サーバーを停止する

問題を解決するために、adb サーバー プロセスを終了して再起動する措置が必要になることがあります。たとえば、コマンドに adb が応答しない場合に、この問題が起こる可能性があります。

adb kill-server サーバーを停止するには、adb コマンドを使用します。その後、別の adb コマンドを発行すると、サーバーを再起動できます。

adb コマンドを発行する

adb コマンドは、開発マシンのコマンドラインまたはスクリプトから発行できます。

adb [-d | -e | -s serial_number] command

稼働中のエミュレータが 1 つだけの場合や、接続されているデバイスが 1 つだけの場合は、デフォルトでそのエミュレータ / デバイスに adb コマンドが送信されます。複数のエミュレータが動作している場合や、複数のデバイスが接続されている場合は、-d、-e、-s のいずれかのオプションを使用して、コマンドの対象デバイスを指定します。

サポートされているすべての adb コマンドの詳細なリストは、次のコマンドを使用して確認できます。

adb --help

シェルコマンドを発行する

shell コマンドを使用して、adb を介してデバイス コマンドを発行したり、対話型シェルを起動したりできます。単一のコマンドを発行するには、次のように shell コマンドを使用します。

adb [-d |-e | -s serial_number] shell shell_command

デバイスで対話型シェルを起動するには、次のように shell コマンドを使用します。

adb [-d | -e | -s serial_number] shell

対話型シェルを終了するには、Control+D キーを押すか、「exit」と入力します。

Android は、通常の Unix コマンドライン ツールのほとんどを提供しています。使用可能なツールのリストを確認するには、次のコマンドを使用します。

adb shell ls /system/bin

--help 引数を指定すると、ほとんどのコマンドについてヘルプを参照できます。シェルコマンドの多くは、toybox によって提供されます。 toybox --help を指定すると、すべての toybox コマンドに関する一般的なヘルプを参照できます。

Android Platform Tools 23 以降では、adb は ssh(1) コマンドと同じ方法で引数を処理するようになりました。この変更により、コマンド インジェクションに関するさまざまな問題が修正され、シェルのメタ文字（adb install Let\'sGo.apk など）を含むコマンドを安全に実行できるようになります。この変更により、シェルのメタ文字を含むコマンドの解釈も変更されています。

たとえば adb shell setprop key 'value' は、一重引用符（'）がローカルシェルによって消去され、デバイスで adb shell setprop key value として認識されるので、エラーになります。このコマンドを機能させるには、ssh(1) の場合のように、ローカルシェル用とリモートシェル用として引用符を 2 回付けます（例: adb shell setprop key 'value' ）。

また、システムログのモニタリング方法については、logcat コマンドライン ツールもご覧ください。

アクティビティ マネージャーを呼び出す

adb シェル内でアクティビティ マネージャー（am）ツールを使用してコマンドを発行することにより、アクティビティの起動、プロセスの強制停止、インテントのブロードキャスト、デバイス画面プロパティの変更など、さまざまなシステム アクションを実行できます。

シェル内での am 構文は次のようになります。

am command

リモートシェルに入らずに直接 adb からアクティビティ マネージャー コマンドを発行することもできます。次に例を示します。

adb shell am start -a android.intent.action.VIEW

表 1. 利用可能なアクティビティ マネージャー コマンド

コマンド 説明
start [options] intent intent で指定した Activity を起動します。

インテント引数の指定をご覧ください。

以下のオプションがあります。

  • -D: デバッグを有効にします。
  • -W: 起動が完了するまで待ちます。
  • --start-profiler file: プロファイラを起動し、結果を file に送信します。
  • -P file: --start-profiler と同様ですが、アプリがアイドル状態になるとプロファイリングが停止します。
  • -R count: アクティビティの起動を count 回繰り返します。各繰り返しの前に、トップレベルのアクティビティが完了します。
  • -S: アクティビティを起動する前に、ターゲット アプリを強制停止します。
  • --opengl-trace: OpenGL 関数のトレースを有効にします。
  • --user user_id | current: 実行するユーザーを指定します。指定しなかった場合、現在のユーザーとして実行します。
startservice [options] intent intent で指定した Service を起動します。

インテント引数の指定をご覧ください。

以下のオプションがあります。

  • --user user_id | current: 実行するユーザーを指定します。指定しなかった場合、現在のユーザーとして実行します。
force-stop package package に関連付けられているすべてのものを強制停止します。
kill [options] package package に関連付けられているすべてのプロセスを強制終了します。このコマンドが強制終了するのは、強制終了しても安全でユーザー エクスペリエンスに影響を及ぼさないプロセスだけに限られます。

以下のオプションがあります。

  • --user user_id | all | current: 強制終了するユーザーのプロセスを指定します。 指定しない場合は、すべてのユーザーのプロセスを強制終了します。
kill-all すべてのバックグラウンド プロセスを強制終了します。
broadcast [options] intent ブロードキャスト インテントを発行します。

インテント引数の指定をご覧ください。

以下のオプションがあります。

  • [--user user_id | all | current]: 送信先のユーザーを指定します。指定しなかった場合、すべてのユーザーに送信されます。
instrument [options] component Instrumentation インスタンスでモニタリングを開始します。通常、対象の component の形式は test_package/runner_class です。

以下のオプションがあります。

  • -r: 未加工の結果を出力します（この指定がないと report_key_streamresult をデコードします）。パフォーマンス測定値の未加工出力を生成するには、[-e perf true] と併用します。
  • -e name value: 引数 name を value に設定します。テストランナーの場合、一般的な形式は -e testrunner_flag value[,value...] です。
  • -p file: プロファイリング データを file に書き込みます。
  • -w: インストルメンテーションが完了するのを待ってから、結果を返します。テストランナーの場合、必須です。
  • --no-window-animation: 実行中に、ウィンドウのアニメーションをオフにします。
  • --user user_id | current: インストルメンテーションを実行するユーザーを指定します。 指定しなかった場合、現在のユーザーが対象になります。
profile start process file process でプロファイラを起動し、結果を file に書き込みます。
profile stop process process でプロファイラを停止します。
dumpheap [options] process file process のヒープをダンプし、file に書き込みます。

以下のオプションがあります。

  • --user [user_id | current]: プロセス名を指定するときに、ダンプするプロセスのユーザーを指定します。指定しなかった場合、現在のユーザーが対象になります。
  • -b [| png | jpg | webp]: グラフィック メモリからビットマップをダンプします。 必要に応じて、ダンプ形式を指定します（デフォルトは PNG）。
  • -n: マネージヒープではなく、ネイティブ ヒープをダンプします。
set-debug-app [options] package アプリの package をデバッグするように設定します。

以下のオプションがあります。

  • -w: アプリが起動する際、デバッガを待ちます。
  • --persistent: この値を保持します。
clear-debug-app 以前 set-debug-app でデバッグするように設定されていたパッケージをクリアします。
monitor [options] クラッシュまたは ANR のモニタリングを開始します。

以下のオプションがあります。

  • --gdb: クラッシュまたは ANR が発生したら、指定ポートで gdbserv を起動します。
screen-compat {on | off} package package の画面互換モードを制御します。
display-size [reset | widthxheight] デバイスの表示サイズをオーバーライドします。このコマンドは、大きな画面のデバイスで低い画面解像度を再現したり、逆に、小さな画面のデバイスで高い画面解像度を再現したりして、さまざまな画面サイズでアプリをテストする場合に使用します。

例:
am display-size 1280x800

display-density dpi デバイスの表示密度をオーバーライドします。このコマンドは、低密度画面で高密度画面の環境を再現したり、逆に、高密度画面で低密度画面の環境を再現したりして、さまざまな画面密度でアプリをテストする場合に使用します。

例:
am display-density 480

to-uri intent 特定のインテント指定を URI として出力します。

インテント引数の指定をご覧ください。

to-intent-uri intent 特定のインテント指定を intent: URI として出力します。

インテント引数の指定をご覧ください。

インテント引数の指定

intent 引数を受け取るアクティビティ マネージャー コマンドの場合、以下のオプションを使用してインテントを指定できます。

Package Manager を呼び出す（pm）

adbシェル内で Package Manager（pm）ツールを使用してコマンドを発行することにより、デバイスにインストールされているアプリ パッケージに対してアクションやクエリを実行できます。

シェル内での pm 構文は次のようになります。

pm command

リモートシェルに入らずに直接 adb から Package Manager コマンドを発行することもできます。次に例を示します。

adb shell pm uninstall com.example.MyApp

表 2. 利用可能な Package Manager コマンド

コマンド 説明
list packages [options] filter すべてのパッケージを出力します。必要に応じて、filter のテキストをパッケージ名に含むパッケージだけを出力することもできます。

以下のオプションがあります。

  • -f: 関連ファイルを表示します。
  • -d: 無効なパッケージだけを表示するようにフィルタします。
  • -e: 有効なパッケージだけを表示するようにフィルタします。
  • -s: システム パッケージだけを表示するようにフィルタします。
  • -3: サードパーティ パッケージだけを表示するようにフィルタします。
  • -i: パッケージのインストーラを表示します。
  • -u: アンインストールしたパッケージを含めます。
  • --user user_id: クエリ対象のユーザー空間。
list permission-groups 既知のすべての権限グループを出力します。
list permissions [options] group 既知のすべての権限を出力します。必要に応じて、group 内の権限だけを出力することもできます。

以下のオプションがあります。

  • -g: グループ別に整理します。
  • -f: すべての情報を出力します。
  • -s: 概要。
  • -d: 危険な権限のみをリストに表示します。
  • -u: ユーザーに表示される権限のみをリストに表示します。
list instrumentation [options] すべてのテスト パッケージをリストに表示します。

以下のオプションがあります。

  • -f: テスト パッケージ用の APK ファイルをリストに表示します。
  • target_package: このアプリ専用のテスト パッケージをリストに表示します。
list features システムのすべての機能を出力します。
list libraries 現在のデバイスがサポートしているすべてのライブラリを出力します。
list users システム上のすべてのユーザーを出力します。
path package 指定した package の APK へのパスを出力します。
install [options] path path で指定されたパッケージをシステムにインストールします。

以下のオプションがあります。

  • -r: データを保持したまま、既存のアプリを再インストールします。
  • -t: テスト APK のインストールを許可します。Gradle によってテスト APK が生成されるのは、アプリの実行やデバッグを完了している場合や、Android Studio の [Build] > [Build APK] コマンドを使用した場合に限られます。APK のビルドに Developer Preview SDK を使用した場合、install コマンドで -t オプションを指定してテスト APK をインストールする必要があります。
  • -i installer_package_name: インストーラ パッケージ名を指定します。
  • --install-location location: 次のいずれかの値を使用して、インストール場所を設定します。
    • 0: デフォルトのインストール場所を使用します。
    • 1: 内部デバイス ストレージにインストールします。
    • 2: 外部メディアにインストールします。
  • -f: 内部システムメモリにパッケージをインストールします。
  • -d: バージョン コードのダウングレードを許可します。
  • -g: アプリ マニフェストに記載されている権限をすべて付与します。
  • --fastdeploy: APK のうち、変更された部分だけを更新することで、インストール済みパッケージの更新を迅速化します。
  • --incremental: APK のうち、アプリの起動に必要な部分だけをインストールし、残りのデータをバックグラウンドでストリーミングします。この機能を使用するには、APK に署名し、APK 署名スキーム v4 ファイルを作成して、このファイルを APK と同じディレクトリに配置する必要があります。この機能をサポートしていないデバイスもあります。このオプションを有効にすると、adb は自動的にこの機能を使用するようになり、この機能がサポートされていない場合は失敗します（失敗した理由に関する詳細情報が表示されます）。--wait オプションを追加すると、APK が完全にインストールされるまで待ってから、APK へのアクセスを許可するように指定できます。

    --no-incremental を指定すると、この機能を adb が使用しないように設定できます。

uninstall [options] package システムからパッケージを削除します。

以下のオプションがあります。

  • -k: パッケージの削除後も、データとキャッシュのディレクトリを保持します。
  • --user user_id: パッケージを削除するユーザーを指定します。
  • --versionCode version_code: 指定したバージョン コードを持つアプリのみをアンインストールします。
clear package パッケージに関連付けられているすべてのデータを削除します。
enable package_or_component 特定のパッケージまたはコンポーネント（「package/class」と記述）を有効にします。
disable package_or_component 特定のパッケージまたはコンポーネント（「package/class」と記述）を無効にします。
disable-user [options] package_or_component

以下のオプションがあります。

  • --user user_id: 無効にするユーザー。
grant package_name permission アプリに権限を付与します。Android 6.0（API レベル 23）以上を搭載するデバイスの場合、アプリ マニフェスト内で宣言されている権限が対象になります。Android 5.1（API レベル 22）以下を搭載するデバイスの場合、アプリによって定義されているオプションの権限が対象になります。
revoke package_name permission アプリに付与した権限を取り消します。Android 6.0（API レベル 23）以上を搭載するデバイスの場合、アプリ マニフェスト内で宣言されている権限が対象になります。Android 5.1（API レベル 22）以下を搭載するデバイスの場合、アプリによって定義されているオプションの権限が対象になります。
set-install-location location デフォルトのインストール場所を変更します。有効な場所の値は次のとおりです。
  • 0: 自動 - システムが最適な場所を決定します。
  • 1: 内部 - 内部デバイス ストレージにインストールします。
  • 2: 外部 - 外部メディアにインストールします。

注: このコマンドは、デバッグ専用です。インストール場所を変更すると、アプリが破損したり、想定外の動作が発生したりする可能性があります。
get-install-location 現在のインストール場所を返します。戻り値は次のとおりです。
  • 0 [auto]: システムが最適な場所を決定します。
  • 1 [internal]: 内部デバイス ストレージにインストールします。
  • 2 [external]: 外部メディアにインストールします。
set-permission-enforced permission [true | false] 特定の権限を強制適用するかどうかを指定します。
trim-caches desired_free_space キャッシュ ファイルを削減して、指定した空き領域を確保します。
create-user user_name 指定した user_name を持つ新しいユーザーを作成し、そのユーザーの新しいユーザー ID を出力します。
remove-user user_id 指定した user_id を持つユーザーを削除し、そのユーザーに関連付けられているすべてのデータを削除します。
get-max-users デバイスがサポートする最大ユーザー数を出力します。
get-app-links [options] [package]

指定された package（指定されていない場合はすべてのパッケージ）のドメインの所有権の証明状態を出力します。状態コードは次のように定義されます。

  • none: このドメインについては何も記録されていません。
  • verified: ドメインの所有権の証明は完了しています。
  • approved: 通常はシェルで、強制的に承認されています。
  • denied: 通常はシェルで、強制的に拒否されています。
  • migrated: 以前のレスポンスからの所有権の証明が保存されています。
  • restored: ユーザーデータの復元からの所有権の証明が保存されています。
  • legacy_failure: 以前の検証ツールにより承認されませんでした（不明な理由）。
  • system_configured: デバイス設定により自動的に承認されています。
  • >= 1024: デバイスの検証ツールに固有のカスタムのエラーコードです。

以下のオプションがあります。

  • --user user_id: ユーザーの選択を含めます。すべてのドメインを含める autoVerify だけでなく
reset-app-links [options] [package]

指定されたパッケージ（指定されていない場合はすべてのパッケージ）のドメインの所有権の証明状態をリセットします。

  • package: リセットするパッケージを指定します（すべてのパッケージをリセットする場合は「all」を指定します）。

以下のオプションがあります。

  • --user user_id: ユーザーの選択を含めます。すべてのドメインを含める autoVerify だけでなく
verify-app-links [--re-verify] [package]

指定された package（指定されていない場合はすべてのパッケージ）の証明リクエストをブロードキャストします。パッケージが以前にレスポンスを記録していない場合にのみ送信します。

  • --re-verify: パッケージがレスポンスを記録している場合でも送信します。
set-app-links [--package package] state domains

パッケージのドメインの状態を手動で設定します。このためには、パッケージでドメインを autoVerify として宣言する必要があります。このコマンドは、適用できなかったドメインについてはエラーを報告しません。

  • --package package: 設定するパッケージを指定します（すべてのパッケージを設定する場合は「all」を指定します）。
  • state: ドメインに対して設定するコードを指定します。有効な値は次のとおりです。
    • STATE_NO_RESPONSE (0): レスポンスがまったく記録されていない場合と同じようにリセットします。
    • STATE_SUCCESS (1): ドメインの所有権の証明はドメインの所有権の証明エージェントによって完了したものと見なします。この証明は、ドメインの所有権の証明エージェントによってオーバーライドされる可能性があります。
    • STATE_APPROVED (2): ドメインを常に承認済みと見なし、ドメインの所有権の証明エージェントによって変更されないようにします。
    • STATE_DENIED (3): ドメインを常に否承認と見なし、ドメインの所有権の証明エージェントによって変更されないようにします。
  • domains: 変更するドメインのスペース区切りリストを指定します（すべてのドメインを変更する場合は「all」を指定します）。
set-app-links-user-selection --user user_id [--package package] enabled domains

パッケージのホストユーザー選択の状態を手動で設定します。このためには、パッケージでドメインを宣言する必要があります。このコマンドは、適用できなかったドメインについてはエラーを報告しません。

  • --user user_id: 選択を変更するユーザーを指定します。
  • --package package: 設定するパッケージを指定します。
  • enabled: ドメインを承認するかどうかを指定します。
  • domains: 変更するドメインのスペース区切りリストを指定します（すべてのドメインを変更する場合は「all」を指定します）。
set-app-links-user-selection --user user_id [--package package] enabled domains

パッケージのホストユーザー選択の状態を手動で設定します。このためには、パッケージでドメインを宣言する必要があります。このコマンドは、適用できなかったドメインについてはエラーを報告しません。

  • --user user_id: 選択を変更するユーザーを指定します。
  • --package package: 設定するパッケージを指定します。
  • enabled: ドメインを承認するかどうかを指定します。
  • domains: 変更するドメインのスペース区切りリストを指定します（すべてのドメインを変更する場合は「all」を指定します）。
set-app-links-allowed --user user_id [--package package] allowed

パッケージの自動証明済みリンク処理の設定を切り替えます。

  • --user user_id: 選択を変更するユーザーを指定します。
  • --package package: 設定するパッケージを指定します（すべてのパッケージを設定する場合は「all」を指定します）。パッケージを指定しなかった場合、パッケージはリセットされます。
  • allowed: 自動証明済みリンクをパッケージが開くことを許可する場合は true、無効にする場合は false を指定します。
get-app-link-owners --user user_id [--package package] domains

指定したユーザーの特定のドメインに対する所有者を優先度の低いものから順に出力します。

  • --user user_id: クエリ対象のユーザーを指定します。
  • --package package: 省略可。パッケージで宣言されたすべてのウェブドメインも出力します（すべてのパッケージを出力する場合は「all」を指定します）。
  • domains: クエリ対象のドメインのスペース区切りリストを指定します。

Device Policy Manager を呼び出す（dpm）

Device Policy Manager（dpm）ツールにコマンドを発行することにより、デバイス管理アプリの開発やテストを促進できます。このツールを使用することで、アクティブな管理アプリを制御したり、デバイス上のポリシー ステータス データを変更したりできます。

シェル内での dpm 構文は次のようになります。

dpm command

リモートシェルに入らずに直接 adb から Device Policy Manager コマンドを発行することもできます。

adb shell dpm command

表 3: 利用可能な Device Policy Manager コマンド

コマンド 説明
set-active-admin [options] component component をアクティブな管理者として設定します。

以下のオプションがあります。

  • --user user_id: 対象ユーザーを指定します。--user current を渡して、現在のユーザーを選択することもできます。
set-profile-owner [options] component component をアクティブな管理者として設定し、そのパッケージを既存ユーザーのプロファイル オーナーとして設定します。

以下のオプションがあります。

  • --user user_id: 対象ユーザーを指定します。--user current を渡して、現在のユーザーを選択することもできます。
  • --name name: 人間が読める形式で組織名を指定します。
set-device-owner [options] component component をアクティブな管理者として設定し、そのパッケージをデバイス オーナーとして設定します。

以下のオプションがあります。

  • --user user_id: 対象ユーザーを指定します。--user current を渡して、現在のユーザーを選択することもできます。
  • --name name: 人間が読める形式で組織名を指定します。
remove-active-admin [options] component アクティブな管理者を無効にします。アプリは、マニフェスト内で android:testOnly を宣言する必要があります。このコマンドは、デバイス オーナーとプロファイル オーナーも削除します。

以下のオプションがあります。

  • --user user_id: 対象ユーザーを指定します。--user current を渡して、現在のユーザーを選択することもできます。
clear-freeze-period-record 以前に設定したシステム OTA 更新凍結期間のデバイスの記録をクリアします。この機能により、凍結期間を管理するアプリを開発する際、スケジュール設定に関するデバイス制限を回避することができます。システム アップデートを管理するをご覧ください。

Android 9.0（API レベル 28）以降を搭載しているデバイスでサポートされます。
force-network-logs 既存のネットワーク ログを DPC によって取得できるように、システムを強制設定します。利用可能な接続ログや DNS ログがある場合、DPC は onNetworkLogsAvailable() コールバックを受信します。ネットワーク アクティビティ ログをご覧ください。

このコマンドにはレート制限があります。Android 9.0（API レベル 28）以降を搭載しているデバイスでサポートされます。
force-security-logs 既存のセキュリティ ログを DPC によって取得できるように、システムを強制設定します。利用可能なログがある場合、DPC は onSecurityLogsAvailable() コールバックを受信します。エンタープライズ デバイス アクティビティのログを記録するをご覧ください。

このコマンドにはレート制限があります。Android 9.0（API レベル 28）以降を搭載しているデバイスでサポートされます。

スクリーンショットを撮る

screencap コマンドは、デバイス画面のスクリーンショットを撮影するためのシェル ユーティリティです。

シェル内での screencap 構文は次のようになります。 

screencap filename

コマンドラインから screencap を使用するには、次のように入力します。 

adb shell screencap /sdcard/screen.png

スクリーンショット セッションの例を次に示します。ここでは、adb シェルを使用してスクリーンショットを取得し、pull コマンドを使用してデバイスからファイルをダウンロードしています。

$ adb shell
shell@ $ screencap /sdcard/screen.png
shell@ $ exit
$ adb pull /sdcard/screen.png

動画を撮影する

screenrecord コマンドは、Android 4.4（API レベル 19）以上を搭載したデバイスの画面を録画するためのシェル ユーティリティです。このユーティリティは、画面上のアクティビティを MPEG-4 ファイルに記録します。このファイルを使用して、宣伝やトレーニング用の動画、デバッグやテスト用の動画を作成できます。

シェル内での構文は次のようになります。

screenrecord [options] filename

コマンドラインから screenrecord を使用するには、次のように入力します。 

adb shell screenrecord /sdcard/demo.mp4

Ctrl+C キーを押して画面の録画を停止します。それ以外の場合、 3 分、または --time-limit で設定された制限時間に自動的に停止します。

デバイス画面の録画を開始するには、screenrecord コマンドを実行して動画を録画します。その後、pull コマンドを実行して、動画をデバイスからホスト コンピュータにダウンロードできます。録画セッションの例を次に示します。

$ adb shell
shell@ $ screenrecord --verbose /sdcard/demo.mp4
(press Control + C to stop)
shell@ $ exit
$ adb pull /sdcard/demo.mp4

screenrecord ユーティリティを使用すると、デバイス画面のアスペクト比を維持した状態で、サポートされている任意の解像度とリクエストしたビットレートで録画できます。このユーティリティは、デフォルトではネイティブの画面解像度と画面方向で、最大 3 分間録画できます。

screenrecord ユーティリティに関する制限事項:

  • 動画ファイルに音声は記録されません。
  • Wear OS を搭載したデバイスの場合、画面の録画は行えません。
  • デバイスによっては、ネイティブ画面解像度で録画できないことがあります。 画面の録画中に問題が発生した場合は、画面解像度を下げてみてください。
  • 録画中の画面回転はサポートされていません。録画中に画面を回転すると、録画中の画面の一部がカットされます。

表 4. screenrecord オプション

オプション 説明
--help コマンドの構文とオプションを表示します。
--size widthxheight 動画のサイズを 1280x720 に設定します。デフォルト値は、デバイスのネイティブ画面解像度です（サポートされている場合）。サポートされていない場合、1280x720 になります。最適な結果を得るには、デバイスの Advanced Video Coding（AVC）エンコーダがサポートしているサイズを使用してください。
--bit-rate rate 動画のビットレートを Mbps 単位で設定します。デフォルト値は 20 Mbps です。 ビットレートを増大すると、動画の品質を改善できますが、その分、動画ファイルのサイズも大きくなります。録画ビットレートを 6 Mbps に設定する例を次に示します。 
screenrecord --bit-rate 6000000 /sdcard/demo.mp4
--time-limit time 最大録画時間を秒単位で設定します。デフォルト値および最大値は 180 秒（3 分）です。
--rotate 出力を 90 度回転します。この機能は試験運用版です。
--verbose ログ情報をコマンドライン画面に表示します。このオプションを設定しなかった場合、ユーティリティは実行中に情報を表示しません。

アプリの ART プロファイルを読み込む

Android 7.0（API レベル 24）以降、Android ランタイム（ART）が、インストール済みのアプリの実行プロファイルを収集するようになりました。この実行プロファイルは、アプリのパフォーマンスの最適化に使用できます。収集されたプロファイルを調べて、頻繁に実行されるメソッドや、アプリの起動中に使用されるクラスについて把握しておきます。

注: 実行プロファイルのファイル名を取得できるのは、ファイル システム（エミュレータなどにある）への root アクセス権がある場合だけです。

プロファイル情報をテキスト形式で生成するには、次のコマンドを使用します。

adb shell cmd package dump-profiles package

生成されたファイルを取得するには、次のコマンドを使用します。

adb pull /data/misc/profman/package.prof.txt

テストデバイスをリセットする

複数のテストデバイスでアプリをテストする場合、テストの間にデバイスをリセットすると役に立つことがあります。たとえば、ユーザーデータを削除してテスト環境をリセットします。Android 10（API レベル 29）以上を搭載したテストデバイスは、次のように testharness adb シェルコマンドを使用して出荷時設定にリセットできます。 

adb shell cmd testharness enable

testharness を使用してデバイスを復元すると、デバイスが自動的に RSA 鍵をバックアップします。これにより、現在のワークステーションを使用して、同じ場所でデバッグを行えるようになります。つまり、デバイスがリセットされた後もワークステーションはデバッグを継続でき、新しい鍵を手動で登録せずにデバイスに adb コマンドを発行できます。

また、testharness を使用してデバイスを復元すると、以下のデバイスの設定も変更され、アプリのテストをより簡単かつ安全に継続できるようになります。

  • デバイスは、最初のデバイス設定ウィザードが表示されないよう、特定のシステム設定を行います。 つまり、デバイスがアプリのインストール、デバッグ、テストをすぐに行える状態になります。
  • 設定:
    • ロック画面を無効にする
    • 緊急アラートを無効にする
    • アカウントの自動同期を無効にする
    • 自動システム アップデートを無効にする
  • その他:
    • プリインストールされているセキュリティ アプリを無効にする

testharness コマンドのデフォルト設定を検出してそれに合わせる必要があるアプリの場合、ActivityManager.isRunningInUserTestHarness() を使用します。

sqlite

sqlite3 は SQLite データベースを調べる sqlite コマンドライン プログラムを起動します。 これには、テーブルの内容を出力する .dump や、既存のテーブルに対する SQL CREATE ステートメントを出力する .schema などのコマンドがあります。次のように、SQLite コマンドをコマンドラインから実行することもできます。

$ adb -s emulator-5554 shell
$ sqlite3 /data/data/com.example.app/databases/rssitems.db
SQLite version 3.3.12
Enter ".help" for instructions

注: SQLite データベースにアクセスできるのは、ファイル システム（エミュレータなどにある）への root アクセス権がある場合だけです。

詳細については、sqlite3 コマンドラインのドキュメントをご覧ください。

adb USB バックエンド

adb サーバーは 2 つのバックエンドを介して USB スタックとやり取りできます。ネイティブの OS のバックエンド（Windows、Linux、macOS など）を使用するか、libusb バックエンドを使用できます。 attach、detach、USB 速度検出などの一部の機能は次のとおりです。 libusb バックエンドを使用している場合のみ使用できます。

バックエンドは、ADB_LIBUSB 環境変数を使用して選択できます。 設定されていない場合、adb はデフォルトのバックエンドを使用します。デフォルトの動作は OS によって異なります。開始中 ADB v34 の場合、 すべての OS ではデフォルトで liubusb バックエンドが使用されます。ただし、Windows ではネイティブ バックエンドが 使用されます。ADB_LIBUSB が ネイティブ バックエンドと libusb のどちらを使用するかを決定します。詳しくは、 adb のマニュアル ページ adb 環境変数の詳細をご覧ください。

<ph type="x-smartling-placeholder">

adb mDNS バックエンド

ADB は、マルチキャスト DNS プロトコルを使用して、サーバーとデバイスを自動的に接続できます。 ADB サーバーには、Bonjour（Apple の mdnsResponder）と Openscreen という 2 つのバックエンドが搭載されています。

Bonjour バックエンドには、ホストマシン上でデーモンが実行されている必要があります。 macOS では、Apple の組み込みデーモンが常に実行されますが、Windows と Linux では、mdnsd デーモンが実行中であることを確認する必要があります。 コマンド adb mdns check でエラーが返された場合、ADB は Bonjour バックエンドを使用していますが、Bonjour デーモンが実行されていない可能性があります。

Openscreen のバックエンドをマシン上で動作させる必要はありません。macOS の Openscreen バックエンドのサポートは ADB v35 から開始されます。ADB v34 では Windows と Linux がサポートされています。

デフォルトでは、ADB は Bonjour バックエンドを使用します。この動作は、環境変数 ADB_MDNS_OPENSCREEN を使用して変更できます。 （1 または 0 に設定）。 詳しくは、ADB のマニュアル ページをご覧ください。