エミュレータが開かれていますが、アプリは黒い画面に止まっていて、GUI コントロールが役に立ちません。あるいは、CI ジョブが表示されず、ただのターミナル プロンプトと仮想デバイスだけが残っていて、毎回同じように動作する必要があります。その時点で、Android エミュレータ ターミナルは便利なツールからコントロール プレーンに変わります。
重要なシフトは単純です。ターミナルは単に同じボタンをクリックする別の方法ではありません。Google のエミュレータ ツールは、起動、シェル作業、コンソール制御の別々の層を提供し、それぞれの層は異なるクラスの問題を解決します。彼らを 1 つのものとして扱うと、スクリプトが不安定になり、古いフラグがワークフローに混入し、CI がランダムに破棄されるように見えるが実際にはそうではないようになります。
目次
- Android エミュレータ ターミナルを使用する必要性
- コマンドラインからエミュレータを起動する
- adb シェルでエミュレータを制御する
- adb を超えるエミュレータコンソールの使用
- エミュレータ内でターミナルアプリとルートアクセス
- ネットワーキング、ポートフォワーディング、キーボードショートカット
- トラブルシューティングと2026年のターミナルワークフロー
Androidエミュレータターミナルが必要な理由
GUIが凍結した場合、明らかなケースです。エミュレータのウィンドウはまだ開いていますが、信頼できません。クリックすることもできず、そのワークフローはビルドサーバーにスケールしません。ターミナルはウィンドウが扱うことができない部分を処理します。再現性。Googleのエミュレータドキュメントでは、コマンドラインとコンソールを自動化とリモートコントロールのツールとして説明し、起動シンタックスは emulator -avd avd_name または emulator @avd_name、利用可能なオプションの完全なリストを通じて emulator -help Android エミュレータのコマンドラインリファレンス.
ターミナル制御の標準化するチームの理由
最初にこのことが重要になるのは、通常、魅力的なものではありません。QA スクリプトはクリーンなデバイス状態が必要で、開発者は Linux と macOS で同じ AVD を起動したい、または CI ランナーはテスト対象を起動する必要がありますが、誰もがウィンドウを観察していない場合に。 その時点で、エミュレータはデスクトップアプリのように振る舞うのではなく、インフラストラクチャのように振る舞うようになります。
実用的なルール: タスクが繰り返される、ログされる、または失敗後に回復される場合、ターミナルパスを最初に使用すること。
Google もエミュレータを公式のコマンドラインツールセットに並べ、重要な理由は Android の自動化はインターフェイスのスタックであるため、1 つのインターフェイスがすべてを実行しようとしているのではなく Android の adb とエミュレータのツール デバイスの検査とシェルへのアクセス用に を使用し、ライフサイクル制御とエミュレータ固有のコマンドのためにエミュレータコンソールを使用します。 それらの役割を混ぜると、スクリプトは脆弱になります。Android adb and emulator tools adb for device inspection and shell access, then use the emulator console for lifecycle control and emulator-specific commands. Mixing those roles is how scripts become brittle.
他の誤解を捨てるべきことは、エミュレータ用のターミナルがGUIのラッパーであるということです。そうではありません。コンソールは認証済みで、localhostポートにバインドされ、GUIと同様のコマンドをサポートしています。 avd start, avd stop, avd status, ping、 rotate Androidエミュレータコンソールの参照. そのため、プロダクション用のコントロールプレーンのように振る舞いますが、初心者用のサンドボックスではありません。
ハイブリッドとCapacitorワークフローでは、インストールやデバッグを開始する前に同じ規律が必要です。Capacitorアプリ用のAndroidのセットアップを参照してください。 Android setup for Capacitor apps 最初の重要なコマンドは、すでに利用可能なものを表示するものです。
、
選択したAVDを選択し、 emulator -list-avdsまたは emulator -avd <name> を実行してください。 emulator @<name>. If the path to the binary isn’t on your shell PATH, find it inside the Android SDK’s emulator directory on Windows, macOS, or Linux, then run it directly from there.
The launch flags that still matter
A clean start is the difference between a sane run and a debugging session that eats your morning. In day-to-day work, the useful terminal flags are the ones that make boot behavior predictable, especially for CI and headless hosts. -no-window はヘッドレスパス -no-snapshot はクリーンな状態を強制する -no-audio そして -no-boot-anim は不要なノイズを削除する -gpu swiftshader_indirect はハードウェアアクセラレーションが利用できない場合の実用的なフォールバックです。
その組み合わせは、「エミュレータが起動しました」と「エミュレータが起動しましたが、パイプラインが信頼できるように起動しました」という差です。起動コマンドは、テスト契約の一部になり、単なる便利なラッパーではありません。Capacitor またはハイブリッドアプリワークフローでデバイスを起動する場合、デバッグまたはインストールステップが始まる前に同じ起動規範が適用されます。Capacitor 開発者向けの実用的なAndroid設定ガイドは はエミュレータコマンドの横に保管しておく価値があります.
デバイスリストから始めて、メモリから始めないでください
最もよく見る間違いは、機械が持っているものを事前に固定することです。AVDの一覧を表示することで、必要なイメージが存在し、シェルが見ることができるかどうかを確認できます。次に、1つの知っているデバイスを起動し、起動パスを観察し、最後にフラグを調整します。
有効な習慣: ローカル開発とCI用のLaunchコマンドを分けておく習慣が役に立つ。パイプラインがコンソールのすべての便利なフラグを継承しないようにする。
ローカルデバッグがフレンドリーなまま、自動化が汚くならないようにするため、その区別が重要だ。Launchが安定したら、残りのターミナルワークフローが信頼できるものにアタッチできるようになる。
エミュレータをADBシェルで動かす
エミュレータが起動したら ADB よく使うコントロールサーフェイスになる。 adb devices ADB adb -s emulator-5554 shell どのデバイスが接続されているかを表示し、特定のポートで特定のインスタンスをターゲットにすることができる。複数の仮想デバイスが存在するマシンでは、一般的なコマンドが間違ったターゲットに当たる可能性があるため、シリアル番号は自動化を目的のエミュレータに指向させる。
接続し、シェルが必要かどうかを判断する
一時的なコマンドとインタラクティブシェルの区別は、初めて見る人にとっては思わぬほど重要だ。設定を確認したりファイルを収集したりする必要がある場合、単一の adb shell コマンドは綺麗です。アプリの動作をステップごとに追跡している場合、対話型シェルにドロップし、作業が完了するまでそこに留まります。
adb push ページ adb pull ファイルの移動を処理する adb install -r 繰り返しローカルテストの実践的なパスであり、 adb exec-out screencap 信頼できるスクリーンショットキャプチャルートを提供します。スクリーンレコーディングも必要なときに、 adb shell screenrecord パッケージインストーラーとローカルサイドロードワークフローの場合、このインストールガイドは便利な相棒となります。 ADBをアプリワークに使用せず、エミュレータライフサイクルワークに使用しない.
コマンドがAndroid自体内で実行される場合、適切なレイヤーです。共有ストレージに保存されているスクリプトがある場合、
adb 実際の自動化スタックに適合します。アプリプライベートファイルを取得するのに役立ち、rootを強制する必要はありません。 adb shell sh /sdcard/run.sh 制限は明確です。 run-as <package> becomes useful for debug builds, since it gives you app-private files without forcing root.
The limit is straightforward. adb エミュレータのコンソールを置き換えず、デプサーキュールのエミュレータライフサイクル制御やコンソールのみのアクションには適していない。ファイル転送、パッケージ管理、コマンド実行、クイックな調査に使用し、そこで止めればよい。
実用的なルール: アクションがAndroidに属する場合は、
adb shellアクションがエミュレータ自身に属する場合は、コンソールを使用する。
プラグイン層、プラットフォーム固有の動作、デバイス状態に関する質問を含むチームは、より広範なデバッグツールキットを使用して、ターミナル作業が推測作業に変わるのを防ぐ。 このデバッグリソース adbワークフローとよく合致する。
エミュレータコンソールの使用
エミュレータコンソールは別の制御平面であり、その区別は重要である。Googleは、コマンドが受け入れられる前に認証が必要であり、コマンドが 5554から5585までのlocalhostポートのみにリスニングしていることをドキュメントしている。5554から5585までのlocalhostポートのみにリスニングしていることをドキュメントしている。 avd start, avd stop, avd status, ping、コマンドが rotate 利用可能になります。 そのため、エミュレータのレベルで実行するアクションに適したツールです。 adb 表現できない場合もあります。
有効な認証を行う前に、有用な情報を送信しません。
Google のドキュメントでは、以下の手順で接続することを推奨しています。 telnet localhost console-port待ちます。 OK次に、以下のコマンドを実行します。 auth auth_token Capacitor の設定ファイルに保存されているトークンを使用します。 ~/.emulator_console_auth_tokenトークンファイルが存在しない場合、telnet 接続はランダムなトークンでファイルを作成します。 これは、CI 環境が一時的な場合、ファイルを意図的に保存するか、または意図的にリセットする必要があります。 そうしないと、突然の認証エラーはほとんどの場合、状態管理のエラーです。
コンソールは見つけることができます。 help, help command、そして help-verbose は理由があり、時間を節約するのに役立ちます。 これは、エミュレータが受け入れるコマンドを確認する場合に、推奨される習慣です。 それに頼るのではなく、推測して期待するのではなく、 adb 後でカバーすることができます。
コンソール内のどの情報が含まれるかを知っておく
ライフサイクルやエミュレータ側の状態に関するコンソールコマンドは avd start そして avd stop 明らかな例ではありますが rotate そして ping レスポンシビティの確認やデバイスの変更のシミュレーションなど、他の状況でも有用です。エミュレータはインフラストラクチャと同じように動作し、起動、準備、シャットダウンを同じ場所でスクリプトすることができます。
エミュレータのコンソールとAndroidシェルの混同はよくある間違いです。距離から見ると似ているかもしれませんが、プロトコルは異なります。コンソールは認証済みでポートバウンドです。一方、シェルへのアクセスは通常 adb shell、スクリプトには異なるタイムアウトと異なるエラー処理が必要です。プラットフォーム固有のワークフローにおけるターミナルの信頼性のために このデバッグリソース コンソールの準備チェックと組み合わせると、信頼性の高いターミナルを実現できます。
良い自動化ゲート: プロセス起動のみでテストを開始しないでください。コンソールハンドシェイクが成功し、仮想デバイスが期待どおりの状態を報告するまで、テストを開始しないでください。
その一つの決定により、テストスイートに到達する前に、
起動したが準備ができていない
のフラッキーフェイルが多く削減されます。
ターミナルアプリとエミュレータ内でのrootアクセス
時々、作業はVM内にありますが、ホストにありません。そういう場合は、エミュレータ内に実際のターミナルアプリをインストールするのが最も簡単な方法です。Termuxは標準的な選択であり、デバイス上のシェル環境を提供し、Unixワークフローに近い環境を提供します。 adb root rootアクセスはイメージ依存であり、魔法ではありません。システムイメージが許可する場合、 adb shell su と
BusyBox is still useful in this layer because it fills in gaps in the command set you’d otherwise miss. If you’re doing file inspection, device-side scripting, or quick diagnostics inside the emulator, a fuller Unix toolkit makes the machine feel much less constrained. The related root checks for Capacitor projects are discussed in BusyBoxはこの層でまだ有用です。コマンドセットの欠陥を埋めることで、欠けているコマンドを補完します。デバイス側のスクリプティング、ファイルの検査、エミュレータ内での診断など、エミュレータ内で行う作業では、Unixツールキットを使用すると、機械がより制限されないように感じます。このプラグインガイドでは、__CAPGO_KEEP_0__ プロジェクトの関連rootチェックについて説明しています。.
このプラグインガイド
rootアクセスを昇格する前に、プライベートアクセスを使用してください。 adb shell run-as <package> アプリプライベートディレクトリをインスペクトするには、爆発半径を広げる必要はありません。 それは、最小限の権限で作業を実行できるツールとワークフローを整合させるクリーンな習慣です。
システムの書き込みが必要な場合は、システムパーティションが書き込み可能でなければなりません。それは、まったく別のセットアップのクラスです。 日常のエミュレーターワークの場合、ホスト側が adb shell エミュレーターワークフローは、ホスト境界を越えてトラフィックが必要になる時点で、実際に実行されます。
ネットワーク、ポートフォワーディング、キーボードショートカット
エミュレータをマシン上のローカル開発サーバーに指すには、ターミナルを使用するのが一番簡単です。特に、ホストサービスに呼び戻すことを想定しているアプリが存在する場合です。 adb reverse tcp:8080 tcp:8080 ホストリスナーに到達する必要がある場合、デバイスからのトラフィックを処理します。 adb forward デバッグの間違いを避ける前に、方向性を選択する
ネットワーキング問題をすべて「エミュレータの問題」と呼ぶことは、多くの時間を浪費することです。実際、ポート方向がよくありません。
エミュレータがホストサービスに到達できるようにします。 adb reverse デバイスのトラフィックをホストポートに向けます。接続パスはどちらのコマンドを適用するかを決定します。 adb forward 接続性がまだ不明瞭な場合は、VM内にルートテーブルを確認してください。
ホストサービスに到達できるようにします。 adb shell ip route そしてインターフェイスを検査する ifconfig.ルーティングが正常に見えますが、サービスが接続を拒否している場合、通常はホストリスナーまたは転送設定に問題があります。Android自体には問題ありません。 ローカルトラフィックの遅延がデバッグ中に表示されるものにどのように影響するかについてのより広い視点を得るには、このネットワークレイテンシーの解説 は便利な読み物です。
キーボード操作はターミナルの物語の一部です
Googleのキーボードマッピングにより、エミュレータはより良いデスクトップターゲットになります。 F2 メニューを開く ESC バック F7 パワー Alt-Enter フルスクリーンを切り替えます。カメラ、音量、オリエンテーションコントロールもカバーされるため、デバイスの多くの動作はキーボード上に残り、ツールバーに埋もれない。
ノートブックや大型モニターでは重要です。コントロール面がキーボードに住むと、エミュレータは全日使用できるツールとして振舞い始め、鼠から窓を押す必要がなくなります。
| 廃止フラグ | それがどのように機能していたか | 現代の置き換え |
|---|---|---|
-audio-in |
有効なオーディオ入力コントロール | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
-audio-out |
有効なオーディオ出力コントロール | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
-enable-kvm |
仮想化パスを要求 | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
-gps |
制御されたGPSの動作 | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
-skin |
デバイスのスキンを設定 | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
-skindir |
スキンディレクトリへの参照 | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
-useaudio |
オーディオ使用を有効にします | 起動スクリプトから削除してください。現在のドキュメントでは機能しません。 |
Googleは現在のエミュレータドキュメントでは機能しないとリストしています。したがって、古いスニペットは新しいスクリプトにコピーされるとすぐに古くなります。 現在のエミュレータのコマンドラインノート. まだ共有シェルスクリプトに残っている場合は、起動をテストして削除してください。
トラブルシューティングと2026年ターミナルワークフロー
ブラックスクリーン、ポートの競合、古いスナップショットが通常の障害のクラスタです。症状と原因をマップすることで、修正は簡単です。ハングアップしたブートは通常、スナップショットの状態を指し、コンソールの認証失敗は通常、トークンファイルまたはハンドシェイクが同期していないことを意味します。 offline, unauthorized, KO: missing authhttps://__CAPGO_KEEP_0__.app
エミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。
または adb エミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。 offline エミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。 unauthorizedエミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。 KO: missing authエミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。
エミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。
エミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。
エミュレータがブラックスクリーンに永遠に突入しない場合は、クリーンな起動パスで再起動し、古い状態を破棄してください。 adb shell アプリレベルの作業と、状態がずれていく場合のロールバックパス。これが、高速モバイルの反復の背後にある Discipline です。nativeアプリをテストするか、制御されたリリースパイプラインを通じて Capacitor アプリにアップデートを配信する場合でも。
信頼性が得られる。エミュレーターテルミナルがコントロールプレーンとして接続されたら、ウィンドウがレスポンシブかどうかを尋ねるのではなく、デバイスの状態がテストで期待しているものと正確に一致しているかどうかを尋ねるようになります。
Capgo を使用することで、エミュレータ駆動テストに伴う、信頼性の高いリリースとリカバリパスの両方が必要なモバイルアプリを開発するチームは、JavaScript、CSS、config、assetの修正をストアレビューの待たなくても高速に配信できます。Visit Capgo __CAPGO_KEEP_0__ にプルリクエストを提出する
