QA エンジニア向け: モバイル アプリケーションのテストで Android Debug Bridge を使用する方法

こんにちは、ハッカーヌーン！私の名前は Alexander Karpenko です。inDriveで QA エンジニアとして働いています。この記事は、初心者の QA スペシャリスト向けに作成しました。以下では、モバイル アプリケーションのテストでAndroid Debug Bridge (ADB) を使用する方法と、そもそもそれが必要な理由について説明します。

テストの基礎に関する基本的な知識はすでにあると思いますので、プロジェクトの準備とセットアップのプロセスは省略します。

ADB の機能は常に拡張されていますが、日々のワークフローを改善するための貴重なテクニックを紹介します。私の話はモバイル アプリのテストに関するものなので、一般的なすべてのモバイル プラットフォームで効果的に作業できる macOS に焦点を当てます。他のオペレーティング システムの場合、例は少し異なる可能性がありますが、Windows ユーザーがこれに反対しないことを願っています。

まず、最も基本的なコマンドに触れて、後のポイントが論理的な順序で表示されるようにします。

接続機器一覧を表示して接続する

通常は 1 つのデバイスで作業しますが、TCP/IP などを介して複数のデバイスが接続されることもあります。この場合、コマンドを実行するデバイスを手動で指定する必要があります。

接続されているすべてのデバイスのリストを表示して、識別子を取得します

adb devices — 接続されているデバイスのリストを表示します ( -lスイッチを使用すると、プロパティの拡張リストが表示されます)。これは、複数のデバイスが接続されていて、必要なデバイスがすぐにわからない場合に便利です。

どのデバイスをターゲットにするかを ADB に伝えるには、デバイスのシリアル番号を-sスイッチの後に指定する必要があります。

adb -s <serial_number> <command> 、 <serial_number>はリストからのデバイスのシリアル番号、 <command>はデバイスで実行するコマンドです。

たとえば、リストから特定のデバイスにアプリケーションをインストールするには:

adb -s 32312b96 install user/download/app.apk

別のよくあるシナリオは、たとえば実行者/発信者のさまざまな役割のために、操作に実際のデバイスとエミュレーターが同時に関与する場合です。この場合、デバイスはシリアル番号ではなく、adb コマンドの後の—d —eスイッチに基づいて簡単に区別できます。例：

adb —d install user/download/app.apk — エミュレーターの—еスイッチを使用して、コマンドが実際のデバイスで実行されます。

同じ Wi-Fi ネットワークを使用している場合は、TCP/IP 経由でデバイスに接続することもできます。これを行うには、デバイスをケーブルで PC に接続し、次のコマンドを使用してデバイスの動作モードを USB から TCP/IP に変更します。

adb tcpip 5555

利用可能な任意の方法でデバイスの IP アドレスを特定します

たとえば、一般情報の電話設定または次のコマンドを使用します。

adb shell ifconfig wlan0

この時点でデバイスがすでに PC から切断されている場合は、デバイスの S/N を追加で指定してください。次に、それに接続します。

adb connect ip_address:5555

次のコマンドでデバイスを無効にすることができます。

adb disconnect ip_address:5555

adb disconnect — すべての TCP/IP デバイスを無効にします。

USB モードに戻るには、次のコマンドを使用します。

adb usb (小文字が重要です)。

アプリケーションのインストールとアンインストール、およびデバイス上のパッケージの検索

アプリケーションは、次のコマンドを使用してインストールされます。

adb install <apk_path> 。 <apk_path>は APK アプリケーション ファイルへの絶対パスです。

install コマンドの後によく使用される便利なスイッチを次に示します。

—d — ダウングレードされたバージョンで再インストールします。そうしないと、失敗 (エラー) [INSTALL_FAILED_VERSION_DOWNGRADE] ) が発生します。

—r — データを保存してアプリケーションを再インストールします。

—g — インストール プロセス中にアプリケーション マニフェストで指定されたすべてのアクセス許可を付与します。

たとえば、このスイッチを使用してインストールされたアプリは、写真をダウンロードするための位置情報やストレージ スペースへのアクセスを許可するよう求めません。

アプリケーションは、パッケージの名前に基づいてアンインストールされます。これを行うには、アプリケーションがシステムにどのように登録されているかを知る必要があります。シェルとパッケージ マネージャー (pm) を使用します。

次のコマンドを実行して、インストールされているすべてのアプリケーションのリストを表示します。

adb shell pm list packages

リストは、アプリケーション名でフィルタリングできます。リストが非常に大きい場合はこれが必要になりますが、パッケージの名前にどの単語が含まれているかはわかっています。

adb shell pm list packages | grep com.myApp

別のファイルに出力して、そこで必要なパッケージを見つけることもできます。

adb shell pm list packages > /Users/username/packages.txt

アプリケーション パッケージの名前を特定する方法がわかったので、デバイスからパッケージを削除する方法に戻りましょう。これは、次のコマンドを使用して実行できます。

adb uninstall com.myApp

adb uninstall -k com.myApp — アプリケーションを削除しますが、データとキャッシュ ファイルは保存します。

しばしば役立つと思われるコマンドを個別に提示します。

adb shell pm clear com.myApp — アプリのキャッシュとデータをクリーンアップします。

デバイスから APK ファイルをダウンロードする

これはめったに見られない状況だと思います。しかし、かつて私がそうであったように、これは誰かにとって便利になるかもしれません.インストールされているすべてのアプリケーションは、APK ファイルを /data/app フォルダーに保存します。パッケージの名前がわかっているので、アプリケーションがインストールされている場所を見つけて、そこから APK をダウンロードできます。これを行うには、次のコマンドを実行します。

adb shell pm path com.myApp — アプリケーションのインストール ディレクトリを表示します。

これは見栄えがよくないかもしれません：

package:/data/app/~~YcTsnr19yQR6ENa0q2EMag==/com.myApp—IHasf91SDB0erQLagc8j0Q==/base.apk

しかし、これはまさに、このパスをどのように見せる必要があるかです。少し先にスキップして、必要なファイルを電話から PC にコピーする方法を見てみましょう。これは、次のコマンドを使用して実行できます。

adb pull <crazyPath> /Users/username/ 、ここで<crazyPath>は前のコマンドの出力、 /Users/username/はファイルをコピーする PC 上のパスです。

テキストフィールド

テキストフィールドのチェックについて簡単に説明しましょう。たとえば、テキスト フィールドに入力できる最大文字数の制限を確認する必要があります。単一のデバイスを使用する場合、転送されたデータのさまざまなセットを電話またはクラウドに保存できます。ただし、テストを別のデバイスで実行する必要がある場合は、テスト データを PC に保存し、次のコマンドを使用してデバイスに転送できます。

adb shell input text <text>

例：

adb shell input text test%stest — 文字列「test test」が入力されます。スペースを特殊文字%sに置き換えます。そうしないと、スペースの前の部分のみがデバイスに送信されます。送信されるテキストで!@#のような特殊文字を使用する場合は、それらの前にバックスラッシュ ( \ ) を挿入してマークする必要があります。

たとえば、次のコマンド:

adb shell input text test\!\@\#\$%stestは、画面に“test!@#$ test”と表示します

(ADB はキリル文字を処理せず、NullPointerException エラーを生成します)。

クリップボードの内容は、次の方法で転送できます。

adb shell input text $(pbpaste)

一部の文字は、PC に表示されるとおりに送信されない場合があることに注意してください。この問題は、ストリーミング テキスト エディター (sed) を使用して解決できます。以下は、テキストが正しい方法でデバイスに転送されることを確認するために必要な、バッファー内のすべてのスペースを特殊文字に置き換える拡張コマンドの例です。

adb shell input text $(pbpaste | sed -e 's/ /\%s/g')

pbpasteは、バッファーに含まれるテキストです。

”—e”スイッチ—を使用すると、テキストの編集に必要なコマンドを実行できます。

“s/take this/change_it_to/option”は使用するテンプレート（パターン）です。

/gは、例外なく、特定のテンプレートのすべての一致を置き換えるフラグです。

ディープリンク

できるだけ実生活に近い環境でテストを行うのが最善ですが、このオプションも利用できることを知っておくと役に立ちます。

この戦略は、必要な画面へのディープ リンクを確認するのに役立ちます。複数の画面が使用されている場合、またはインフラストラクチャに問題がありプッシュ通知が届かない場合、またはいずれもまだ到着していないが、アプリケーションが動作します。

また、プッシュ通知アラートに無効なディープ リンクが表示された場合に、アプリケーションが正しく動作し、クラッシュしないかどうかを確認することもできます。あるいは、もはや存在しない、またはステータスが変更された画面へのディープ リンクをたどる状況に対処する場合、またはプッシュ アラートが久しぶりのお知らせ。このような状況が多いかもしれません。

Shell ADB では、Activity Manager (AM) を使用してコマンドを実行できます。

アクティビティを開始し、確認したいディープ リンクを送信します。ディープリンクには通常、画面を区切る文字「&」が含まれています。したがって、端末から開く場合は、その前にバックスラッシュ (\) を挿入する必要があります。

adb shell am start -W -a android.intent.action.VIEW -d “myApp://open/client/trip\&last_trip=test” com.myApp

am — アクティビティ マネージャーを呼び出します。

W — コマンドを実行する前にダウンロードを待機しています。

a — 実行するアクションを決定します。この場合はaction.Viewです。

d — 実行に必要なデータ。この場合、ディープ リンク自体と、それを開くために使用するアプリケーションについて話しています。

コマンドを端末に転送するときに、引用符を手動で再挿入するか、一重引用符に置き換える必要がある場合があります。構文エラーがある場合は、適切なメッセージが表示されることがあります。

デバイス画面からのスクリーンショットの作成とビデオの録画

スクリーンショットを撮るには、次のコマンドを使用します。

adb shell screencap -p <device_path/screenshot_name.png>

例：

adb shell screencap -p /sdcard/screencap.png — スクリーンショットを撮り、デバイスのscreencap.pngという名前のファイルを/sdcard/screencap.pngフォルダーに保存します。

次のようにして、スクリーンショットをコンピュータに保存できます。

adb pull /sdcard/screencap.png — デフォルトでは、ファイルは現在のユーザーのディレクトリ、つまり/Users/username/screencap.pngにコピーされます。

または、コマンド全体を一度に実行できます。

adb shell screencap -p /sdcard/screencap.png && adb pull /sdcard/screencap.png

ADB の最新バージョンでは、次のコマンドを使用してスクリーンショットを取得できます。

adb exec—out screencap —p > screen.png — スクリーンショット ファイルは、PC 上の現在のユーザーのディレクトリにも表示されます。

デフォルトのパスは、コマンドの最後に追加することで手動で変更できます。

adb exec—out screencap -p > downloads/test/screen.png — スクリーンショットが/Users/username/downloads/test/screen.pngフォルダーに表示されます。

興味がある場合は、エイリアスをbash_profileに追加して、このプロセスを少し自動化することもできます。 macOS では、Automator Service を使用してホットキーを作成および設定できます。

ビデオを録画するには、次のコマンドを使用します。

adb shell screenrecord device_path .

例：

adb shell screenrecord /sdcard/screenrecord.mp4 — このコマンドを使用して、デフォルト設定に基づいてデバイス画面の記録を 3 分間開始し、結果をデバイスのファイル/sdcard/screenrecord.mp4に保存します。

—time—limit timeスイッチを使用して手動で記録時間を指定できます (秒単位ですが、記録の長さは 180 秒に制限されています)。

CTRL + Cを押すと、事前に記録を停止できます

スクリーンショットの手順と同様に、pull コマンドを使用してファイルをコピーすることもできます。

--helpスイッチを使用して、このユーティリティの追加機能を確認することもできます。ちなみに、録画解像度やビットレートを変更したり、バグレポート用にデータを追加したりできます。

-bugreportスイッチを使用すると便利です。これにより、ビデオの最初のフレームとして記録に使用されたシステムに関する情報が追加されます。

デバイスからコンテンツをダウンロードする方法について説明したので、デバイスに何かをアップロードする方法に少し焦点を当てましょう。

私たちはそれを PC で開き、フォーマットとコンテンツを調整し、携帯電話にダウンロードして、不明なフォーマットとサイズ制限にアプリケーションが正しく応答することを確認しました。 PC から電話にファイルをアップロードするには、次のコマンドを使用できます。

adb push /Users/username/file <device_path>

コマンドを実行しましょう:

adb push /Users/username/screen.png sdcard — これにより、 screen.pngファイルが電話の SD カードにコピーされます。

システムによってアプリが削除された後、アプリの状態が復元されたかどうかを確認する

経験からの別の例は、システムによって削除された後にアプリの状態が復元されたかどうかを確認することに関するものです。アプリケーションを折りたたみ、プロセスを強制終了します。このアクションは、使用可能なメモリが不足しているためにシステムがプロセスを停止する状況をシミュレートします。

adb shell am kill com.myApp

もう一度実行して、すべてが正常に機能しているかどうかを確認します。

ユーザーが特定の画面でアプリケーションを最小化するというシナリオに遭遇しました。しばらくすると、システムはプロセスを遅くし、その状態をキャッシュします。ユーザーがアプリケーションを展開しようとすると、クラッシュします。これは、フラグメントがスタックと状態を復元しているため、キャッシュからのデータがアクセスされたときに発生しますが、キャッシュはすでに空です。残念ながら、このバグはテスト段階で見落とされていました。これまで遭遇したことがなかったため、最終的に本番環境に移行しました。それが可能であることがわかったので、私たちの過ちを繰り返さないようにすることができます.

ログ

アプリケーションがクラッシュした原因を突き止めようとするときは、ログを確認することをお勧めします。現在のログ バッファーの内容を保存する場合は、次のコマンドを使用して実行できます。

adb logcat — ログをリアルタイムで表示します。

adb logcat —d — デバイスに実際のイベントを追加せずに、コマンドが実行された時点でログ情報を表示します。次のコマンドを使用して、ログを別のファイルに出力することもできます: adb logcat —d > file.log (ファイルは現在のユーザーのディレクトリに作成されます)。

コマンドadb logcat >> file.logは、ログをファイルに直接書き込み、デバイス上のすべての実際のイベントを追加します。

優先度の昇順でいくつかのレベルがあります: V — 詳細、D — デバッグ、I — 情報、W — 警告、E — エラー、F — 致命的、S — サイレント、たとえば:

adb logcat '*:E' — エラーとそれ以上のレベルのログを出力します。

ここで、出力の書式設定とフィルターについて簡単に説明しましょう。 -v スイッチを使用して、コンソールへの出力の形式を変更できます。次に例を示します。

adb logcat -v time — 時点を記録してログを順次出力します。

adb logcat -v color — ログの各レベルを異なる色で表示します (これは読むときに役立ちます)。

adb logcat -v brief — プロセスの優先度、タグ、および PID を表示します。

各ログ メッセージには、タグとそれに関連する優先度があります。それらを使用して、コンソールへの出力量を減らすことができます。

adb logcat SwrveSDK:I '*:S' — swrve サービス経由で送信された分析イベントを表示します。 *:S (-s)パラメーターは、ログ出力が明示的に指定したフィルター式に限定されることを示します。

いつものように、grep ユーティリティを使用して出力をフィルタリングできます。

adb logcat '*:E' —v color | grep com.myApp

従来、詳細については、いつでもアシスタントadb logcat --helpを参照できます。

それでは使い方を見ていきましょう

たとえば、デバイスが接続されていないときにバグが再現された場合は、すぐに接続してログをファイルにリダイレクトできます。

さらにデバッグするには、ログを収集する前に、バグを再現する前にログ バッファを事前にクリアして、余分なデータを削除します。これは、次のコマンドで実行できます。

adb logcat —c 、次にバグを再現してadb logcat —dを実行します

ログの山を掘り下げるのが好きな人には、考慮すべき別のツールがあります — ADB バグレポート.このツールを使用すると、完全なデバッグ情報を含む zip アーカイブをプレーン テキスト形式 ( .txt ) で作成できます。

adb bugreport /Users/username — 指定したディレクトリに zip アーカイブを作成します。

dumpstate、dumpsys、logcat データなど、デバイスに関するすべての情報を指定したフォルダーにコピーします。デフォルトでは、エラー レポートは /bugreports に保存され、次の方法で表示できます。

adb shell ls /bugreports/

私たちにとって最も重要な情報は、 bugreport-BUILD_ID-DATE.txt保存されています。

Crash Monitoring と ANR (Application Not Responding) は、クラッシュに対処するためのもう 1 つの興味深いツールです。次のコマンドを使用して実行します。

adb shell am monitorで、クラッシュを再現します。コンソールには、冗長な詳細を除いたクラッシュに関する情報と、監視作業を継続するための 3 つのオプションが表示され(c)ontinue: show crash dialog, (k)ill: immediately kill app, (q)uit: finish monitoring 。

エミュレーター

構成されたエミュレーターのリストを表示します。

emulator -list-avds

必要なエミュレーターを実行します。

emulator @avdname

エミュレーターを使用する場合、サービスを再起動する必要がある場合があり、エミュレーターの起動後にサーバーをリセットする必要がありますが、ほとんどの場合、1 つのコマンドで十分です: adb kill-server .これで問題が解決しない場合は、スクリプト全体を実行します。

emulator -list-avds — 構成されたエミュレーターのリストを表示します。

adb kill-server — サーバーを停止します。

emulator -avd avdname (またはemulator @avdname )— avdnameはエミュレータの名前です。

adb start—server — サーバーを再起動します。

adb devices — 紛失したエミュレーターが表示される接続済みデバイスのリストを表示します。

あなたの中で最も怠惰な人のために、コマンドラインからエミュレーターを作成できます。たとえば、次のコマンドは、API 25 の x86 システム イメージを使用して「test」という名前のエミュレータを作成します:):

avdmanager create avd —n test —k "system—images;android—25;google_apis;x86"

目的のイメージが利用できない場合は、次のコマンドでプレインストールできます。

sdkmanager --install "system—images;android—25;google_apis;x86"

sdkmanager --list | grep system—images — ダウンロード可能なイメージのリストを表示します

エミュレーターでは、操作中に「ファントム」問題が発生することもあります。ここで役立つよく使用されるコマンドの 1 つは、自動スナップショットをプルアップせずにエミュレーターを「コールド ブート」することです。出力で作成されるスナップショットは次のようになります。

emulator @avdname —no—snapshot—load

エミュレーターを起動するときに考慮すべきいくつかの便利なスイッチを次に示します。

-no-snapshot-save — 自動スナップショットは保存されません

-no-snapshot — スナップショットはダウンロードまたは保存されません

それでもエミュレーターが正しく機能しない場合は、エミュレーターを元の状態に戻すスイッチを使用してクリアできます: -wipe-data

スナップショットの作成は、デバイスのさまざまな状態を保存するための非常に便利な機能です。手動では、これはエミュレーターの設定を使用するか、次のコマンドを実行して行うことができます。

adb emu avd snapshot save test — エミュレーターの状態を保存します。ここで、 testはデバイスに保存されるスナップショットの名前です。

emulator @avdname —snapshot—list — @avd という名前のエミュレータを実行し、コンソールにスナップショット リストを表示します。

次に、次のコマンドを使用して、以前に保存したスナップショットをロードできます。

adb emu avd snapshot load test — testは以前に保存したスナップショットの名前です

adb emu avd snapshot delete test — testという名前のスナップショットを削除します

必要なスナップショットを使用してエミュレーターをすぐに実行することもできます。

emulator @avdname -snapshot test

pullコマンドを使用して、デバイスからスナップショットを取得することもできます。

adb emu avd snapshot pull test /Users/username/

エミュレータはtelnetコンソールから操作できます。ただし、最初にインストールする必要があります。これを行う最も簡単な方法は、 brewパッケージ マネージャーを使用することです (持っている場合)。そうでない場合は、それが何であり、どのように使用するかを調べる時が来ました。したがって、次のコマンドを使用してtelnetをインストールします: brew install telnet.

次に、エミュレーターを実行し、ターミナルの別のタブで、次のコマンドを使用してエミュレーターに接続します: telnet localhost port,例:

telnet localhost 5554 — ポート 5554 を使用するエミュレータに接続します

コマンドを完了すると、geo (たとえば、コマンドgeo fix 40.748840 -73.984279は、指定された座標で目的の場所を設定します)、ネットワーク、またはバッテリーの操作を含む、エミュレーターであらゆる種類の便利なことを実行できます。いつものようにコマンドの完全なリストはヘルプから見つけることができます。

たとえば、スナップショットの同じ手順はいくらか単純化されていますが、前のセクションで概説したコマンドはavd snapshot <command>に縮小されています。

デバイスの解像度を変更する

ウィンドウ マネージャー (wm) には、デバイスの画面上の要素が正しく表示されるようにするための便利なコマンドがいくつかあります。ピクセル密度の解像度を調整できるため、適切な数のデバイスを手元に用意しなくても、画面サイズに必要なすべてのオプションを調べて、アプリがそれらにどのように適応するかを確認できます。

adb shell wm size 1080x1920 — 幅 1080、高さ 1920 のカスタム画面解像度を設定します。

adb shell wm size reset — 変更したすべての設定をリセットします。

adb shell wm density X — ピクセル密度を変更します。最小値は 72 です。値が大きいほど、画面上の要素が大きくなります。

adb shell wm density reset — 変更したすべての設定をリセットします。

引数なしでコマンドを実行すると、接続されているデバイス/エミュレーターの現在の画面解像度とピクセル密度が返されます。

猿

これとは別に、Monkey について言及できます。Monkey は、クリック、タップ、ジェスチャなどのランダムなユーザー イベントをエミュレーターまたはデバイス上で生成するツールであり、愚かなサルの動きに似た多数のシステム レベルのイベントも生成します。 Monkey は、ストレス テストに使用できます。

adb shell monkey — すべての Monkey パラメーターを表示します。

完全なシナリオの例:

adb shell monkey ——throttle 100 ——pct—syskeys 0 —p com.myApp —v 10

--throttleキー — アクション間の遅延をミリ秒単位で設定します。 Monkey はすべてのアクションを迅速に実行するため、このスイッチ (キー) は通常、画面上で何が起こっているかを視覚的に制御したい場合に使用されます。

--pct-syskeysキー — シナリオ中に押されるシステム ボタンの割合を定義します。この例では、0 に設定されています。これは、システム ボタンが押されないことを意味します。

-pスイッチ — 送信されるパケットの名前

-vスイッチ — 実行するアクションの数

アプリケーションの権限

通常、ここに含まれる操作は、アプリのアクセス許可を取り消すことを意味します。アクセス許可は通常、アプリの要求を介して付与されるためです。アクセス許可の取り消しは、システム設定を介して行われますが、これは迅速かつ簡単に行うことができます。

adb shell dumpsys package com.MyApp | grep permission — 使用可能なアプリケーション パーミッションのリストを表示します。たとえば、 install permissions — アプリケーションのインストール時に付与される必須のパーミッション、 runtime permissions — ファイル ストレージへのアクセス時など、特定の瞬間に要求されるパーミッションです。要求された権限リストに権限がない場合、その権限へのアクセスを許可できないことに注意してください。

したがって、次のコマンドを実行して、アプリケーションの許可を取り消す必要があります。

adb shell pm revoke packageName permissionName 、例:

adb shell pm revoke com.MyApp android.permission.CAMERA — com.myAppのカメラへのアクセスを取り消します。アプリケーションに戻ってカメラを使用しようとすると、新しい許可要求が表示されます。

grant コマンドは、アプリケーションに許可を与えます。次に例を示します。

adb shell pm grant com.myApp android.permission.CAMERA — アプリケーションに電話のカメラへのアクセスを許可します。

バッテリー

ここで、バッテリーとスタンバイモードについて簡単に見てみましょう。

adb shell dumpsys battery — バッテリー情報を表示します。

adb shell dumpsys battery set level X — バッテリーの充電レベルを設定します。X は充電のパーセンテージです。

adb shell dumpsys battery unplug — バッテリーの取り外しをシミュレートします。

adb shell dumpsys battery reset — 変更したすべての設定をリセットします。

次に、スタンバイモードを見てみましょう。 Android 6 以降では Doze Mode と呼ばれる機能があり、ユーザーがデバイスをしばらく操作しなかった後やデバイスが充電されていないときにアプリのアクティビティを制限することで、バッテリーの電力を節約し、バッテリーの寿命を延ばします。

システムは Doze モードを定期的に終了して、保留中のバックグラウンド タスクを完了します。アプリ スタンバイは、もう 1 つの同様の Android 機能です。 Doze モードとは異なり、一定時間アイドル状態だった特定のアプリの状態を追跡し、スタンバイ モードをアクティブにします。私たちの仕事は、これら 2 つの省電力モードを終了した後にアプリが正常に回復すること、アプリがクラッシュしないこと、通知が引き続き送信されることなどを確認することです。

デバイスを Doze モードに切り替えるには、次のコマンドを実行します。

adb shell dumpsys battery unplug — バッテリーを取り外します。

adb shell dumpsys deviceidle step — が表示されるまで、コマンドを数回実行する必要がある場合があります: Stepped to deep: IDLE 。

バッテリーですべてのルーチンを完了したら、次のコマンドを実行するのが最善です。

adb shell dumpsys battery reset — 元の状態に戻します。

このコマンドを使用して、デバイスを強制的に Doze モードにすることもできます。

adb shell dumpsys deviceidle force—idle — 場合によっては、この前に次のコマンドを実行する必要があります: adb shell dumpsys deviceidle enable.

次のコマンドを使用して、Doze モードから再アクティブ化できます。

adb shell dumpsys deviceidle unforce — バッテリーの状態をリセットすることを忘れないでください:

adb shell dumpsys battery reset .

次に、アプリ スタンバイについて少し説明します。このモードでアプリケーションをデプロイするには、次のコマンドを実行する必要があります。

adb shell dumpsys battery unplug — 前のケースと同様にバッテリーを取り外します。

adb shell am set—inactive com.myApp true — アプリケーションをアプリ スタンバイ モードでデプロイします。

次に、次のコマンドを使用して、アプリケーションをアプリ スタンバイ モードから切り替えます。

adb shell am set—inactive com.myApp false .

次のコマンドを実行して、アプリのステータスを確認できます。

adb shell am get—inactive com.myApp

考慮すべきいくつかの便利なコマンド

adb reboot — デバイスを再起動します (実際のデバイスにも関連します)。

adb shell dumpsys package com.myApp — 特定のアプリケーションに関する完全な情報を表示します。

adb shell dumpsys meminfo com.myApp — デバイス上のアプリケーションのメモリ使用量を確認します。これには、占有スペースから、このアプリで使用されるデータベースの表示、およびそれらへのパスまでが含まれます。

adb shell getprop — 利用可能なデバイス プロパティ (メーカー、デバイス モデル、ハードウェア仕様など) のリストを表示します。

アプリケーションがアクセスできるアクティビティのリストを表示します。

adb shell dumpsys package com.myApp | grep —i Activity .

実行中のアクティビティの名前を表示します。

adb shell dumpsys window | grep Focused .

選択したアプリ アクティビティを実行します。

adb shell am start —n com.myApp/.ActivityClass — この方法で、システム アプリケーションを含む、インストール済みのアプリケーションを実行できます。例: adb shell am start -n com.android.settings/.Settings は、電話の設定を表示します。

指定された電話番号に電話をかけます。

adb shell am start —a android.intent.action.CALL tel:+790900000XX .

Web ブラウザーでページを開きます。

adb shell am start —a android.intent.action.VIEW 'https://indriver.com'

最終的な考え

Android Debug Bridge のすべての機能を 1 つの記事に詰め込んだり、それらを徹底的に調査したりすることは不可能であることを指摘しておきます。変化は絶え間なく起こっています。今日機能しているものは、明日は突然機能しなくなる可能性があり、特定の問題の解決策を探す際に、特定のツールの知識が必要になる場合があります。しかし、今日取り上げた資料は、あなたが始めてしばらく続けるには十分であると自信を持って言えます.

ソフトウェア テストのエキサイティングな世界への飛び込みを楽しんでいただければ幸いです。