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 コードまたはペア設定コードを使用して、デバイスをワークステーションとペア設定する必要があります。ワークステーションとデバイスは同じワイヤレス ネットワークに接続する必要があります。デバイスに接続する手順は次のとおりです。
-
デバイスの開発者向けオプションを有効にします。
-
Android Studio を開き、実行構成メニューから [Pair Devices Using Wi-Fi] を選択します。
図 1. 実行構成メニュー。図 2 のように、[Pair devices over Wi-Fi] ウィンドウが表示されます。
図 2. QR コードまたはペア設定コードを使用してデバイスをペア設定するためのポップアップ ウィンドウ -
デバイスで [ワイヤレス デバッグ] をタップして、デバイスをペア設定します。
図 3. Google Pixel の [ワイヤレス デバッグ] 設定のスクリーンショット。-
デバイスを QR コードでペア設定するには、[QR コードによるデバイスのペア設定] を選択し、図 2 のように [Pair devices over Wi-Fi] ポップアップで取得した QR コードをスキャンします。
-
デバイスをペア設定コードでペア設定するには、前述の [Pair devices over Wi-Fi] ポップアップで [Pair device with pairing code] を選択します。デバイスで [ペア設定コードによるデバイスのペア設定] を選択し、表示された 6 桁のコードをメモします。デバイスが [Pair devices over Wi-Fi] ウィンドウに表示されたら、[Pair] を選択して、デバイスに表示された 6 桁のコードを入力します。
図 4. 6 桁のコード入力の例。
-
-
ペア設定が完了すると、アプリをデバイスにデプロイできるようになります。
別のデバイスをペア設定する場合、またはワークステーションからこのデバイスを削除する場合は、デバイスで [ワイヤレス デバッグ] に移動して、[ペア設定済みのデバイス] からワークステーション名を選んでタップし、[削除] を選択します。
-
ワイヤレス デバッグのオンとオフをすばやく切り替えるには、ワイヤレス デバッグにクイック設定開発者用タイルを利用します([開発者向けオプション] > [クイック設定開発者用タイル])。
図 5. [クイック設定開発者用タイル] 設定を使用すると、ワイヤレス デバッグのオンとオフをすばやく切り替えられます。
コマンドラインを使用した Wi-Fi 接続
または、Android Studio を使用せずにコマンドラインからデバイスに接続するには、次の手順を実施します。
-
前述のとおり、デバイスで開発者向けオプションを有効にします。
-
前述のとおり、デバイスで [ワイヤレス デバッグ] を有効にします。
-
ワークステーションでターミナル ウィンドウを開いて、
android_sdk/platform-tools
に移動します。 -
[ペア設定コードによるデバイスのペア設定] を選択して、IP アドレス、ポート番号、ペア設定コードを確認します。デバイスに表示された IP アドレス、ポート番号、ペア設定コードをメモしておきます。
-
ワークステーションのターミナルで
adb pair ipaddr:port
を実行します。前述の IP アドレスとポート番号を使用します。 -
メッセージが表示されたら、下図のようにペア設定コードを入力します。
図 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 経由で接続するには、これらの初期手順に沿って行ってください。
-
Android デバイスと
adb
ホスト コンピュータを、共通の Wi-Fi ネットワークに接続します。 - USB ケーブル経由で、デバイスとホスト コンピュータを接続します。
-
ポート 5555 で TCP/IP 接続をリッスンするように対象デバイスを設定します。
adb tcpip 5555
- 対象デバイスから USB ケーブルを切り離します。
- Android デバイスの IP アドレスを確認します。たとえば、Nexus デバイスの場合、[設定] > [タブレット情報](または、[デバイス情報])> [デバイスの状態] > [IP アドレス] で、IP アドレスを確認できます。
-
IP アドレスを使用してデバイスに接続します。
adb connect device_ip_address:5555
-
ホスト コンピュータが対象デバイスに接続されていることを確認します。
$ adb devices List of devices attached device_ip_address:5555 device
注: 必ずしもすべてのアクセス ポイントが適切であるとは限りません。場合によって、adb
を適切にサポートするようファイアウォールが設定されているアクセス ポイントを使用する必要があります。
デバイスが 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
コマンドを発行するとき。
ターゲットを指定する手順は次のとおりです。
-
devices
コマンドを使用して、対象のシリアル番号を取得します。 - シリアル番号を取得したら、
adb
コマンドで-s
オプションを使用して、シリアル番号を指定します。- 多くの
adb
コマンドを発行する場合は、代わりに$ANDROID_SERIAL
環境変数を設定してシリアル番号を指定できます。 -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 を起動します。インテント引数の指定をご覧ください。 以下のオプションがあります。
|
startservice [options] intent
|
intent で指定した Service を起動します。インテント引数の指定をご覧ください。 以下のオプションがあります。
|
force-stop package
|
package に関連付けられているすべてのものを強制停止します。
|
kill [options] package
|
package に関連付けられているすべてのプロセスを強制終了します。このコマンドが強制終了するのは、強制終了しても安全でユーザー エクスペリエンスに影響を及ぼさないプロセスだけに限られます。
以下のオプションがあります。
|
kill-all
|
すべてのバックグラウンド プロセスを強制終了します。 |
broadcast [options] intent
|
ブロードキャスト インテントを発行します。 インテント引数の指定をご覧ください。 以下のオプションがあります。
|
instrument [options] component
|
Instrumentation インスタンスでモニタリングを開始します。通常、対象の component の形式は test_package/runner_class です。以下のオプションがあります。
|
profile start process file
|
process でプロファイラを起動し、結果を file に書き込みます。
|
profile stop process
|
process でプロファイラを停止します。
|
dumpheap [options] process file
|
process のヒープをダンプし、file に書き込みます。以下のオプションがあります。
|
set-debug-app [options] package
|
アプリの package をデバッグするように設定します。以下のオプションがあります。
|
clear-debug-app
|
以前 set-debug-app でデバッグするように設定されていたパッケージをクリアします。
|
monitor [options]
|
クラッシュまたは ANR のモニタリングを開始します。 以下のオプションがあります。
|
screen-compat {on | off} package
|
package の画面互換モードを制御します。
|
display-size [reset | widthxheight]
|
デバイスの表示サイズをオーバーライドします。このコマンドは、大きな画面のデバイスで低い画面解像度を再現したり、逆に、小さな画面のデバイスで高い画面解像度を再現したりして、さまざまな画面サイズでアプリをテストする場合に使用します。
例: |
display-density dpi
|
デバイスの表示密度をオーバーライドします。このコマンドは、低密度画面で高密度画面の環境を再現したり、逆に、高密度画面で低密度画面の環境を再現したりして、さまざまな画面密度でアプリをテストする場合に使用します。
例: |
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 のテキストをパッケージ名に含むパッケージだけを出力することもできます。以下のオプションがあります。
|
list permission-groups
|
既知のすべての権限グループを出力します。 |
list permissions [options] group
|
既知のすべての権限を出力します。必要に応じて、group 内の権限だけを出力することもできます。以下のオプションがあります。
|
list instrumentation [options]
|
すべてのテスト パッケージをリストに表示します。 以下のオプションがあります。
|
list features
|
システムのすべての機能を出力します。 |
list libraries
|
現在のデバイスがサポートしているすべてのライブラリを出力します。 |
list users
|
システム上のすべてのユーザーを出力します。 |
path package
|
指定した package の APK へのパスを出力します。
|
install [options] path
|
path で指定されたパッケージをシステムにインストールします。以下のオプションがあります。
|
uninstall [options] package
|
システムからパッケージを削除します。 以下のオプションがあります。
|
clear package
|
パッケージに関連付けられているすべてのデータを削除します。 |
enable package_or_component
|
特定のパッケージまたはコンポーネント(「package/class」と記述)を有効にします。 |
disable package_or_component
|
特定のパッケージまたはコンポーネント(「package/class」と記述)を無効にします。 |
disable-user [options] package_or_component
|
以下のオプションがあります。
|
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
|
デフォルトのインストール場所を変更します。有効な場所の値は次のとおりです。
注: このコマンドは、デバッグ専用です。インストール場所を変更すると、アプリが破損したり、想定外の動作が発生したりする可能性があります。 |
get-install-location
|
現在のインストール場所を返します。戻り値は次のとおりです。
|
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(指定されていない場合はすべてのパッケージ)のドメインの所有権の証明状態を出力します。状態コードは次のように定義されます。
以下のオプションがあります。
|
reset-app-links [options] [package]
|
指定されたパッケージ(指定されていない場合はすべてのパッケージ)のドメインの所有権の証明状態をリセットします。
以下のオプションがあります。
|
verify-app-links [--re-verify] [package]
|
指定された package(指定されていない場合はすべてのパッケージ)の証明リクエストをブロードキャストします。パッケージが以前にレスポンスを記録していない場合にのみ送信します。
|
set-app-links [--package package] state domains
|
パッケージのドメインの状態を手動で設定します。このためには、パッケージでドメインを autoVerify として宣言する必要があります。このコマンドは、適用できなかったドメインについてはエラーを報告しません。
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
パッケージのホストユーザー選択の状態を手動で設定します。このためには、パッケージでドメインを宣言する必要があります。このコマンドは、適用できなかったドメインについてはエラーを報告しません。
|
set-app-links-user-selection --user user_id [--package package]
enabled domains
|
パッケージのホストユーザー選択の状態を手動で設定します。このためには、パッケージでドメインを宣言する必要があります。このコマンドは、適用できなかったドメインについてはエラーを報告しません。
|
set-app-links-allowed --user user_id [--package package] allowed
|
パッケージの自動証明済みリンク処理の設定を切り替えます。
|
get-app-link-owners --user user_id [--package package] 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 をアクティブな管理者として設定します。
以下のオプションがあります。
|
set-profile-owner [options] component
|
component をアクティブな管理者として設定し、そのパッケージを既存ユーザーのプロファイル オーナーとして設定します。
以下のオプションがあります。
|
set-device-owner [options] component
|
component をアクティブな管理者として設定し、そのパッケージをデバイス オーナーとして設定します。
以下のオプションがあります。
|
remove-active-admin [options] component
|
アクティブな管理者を無効にします。アプリは、マニフェスト内で android:testOnly を宣言する必要があります。このコマンドは、デバイス オーナーとプロファイル オーナーも削除します。
以下のオプションがあります。
|
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 環境変数の詳細をご覧ください。
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 のマニュアル ページをご覧ください。