ディスク上に新しいAndroidビルドが待っています。ブラウザ版は問題ありません。実機にインストールしたいです。内部テストアップロードではなく、Android Studioのインデックス作成が終わった後ではなく、今すぐ。
その時は ADB Capacitorは、実際の電話と組み立て済みAPKの間の最短のパスになる。CapacitorまたはIonicと一緒に働いている場合、このコマンドは便利なコマンドから正常なフィードバックループの一部になる。実際の電話で動作するネイティブプラグイン、パーミッション、スプラッシュビハビア、ディープリンク、ウェブビューの奇妙さ、ブラウザが知らないその他のすべてのものを検証する方法です。
目次
- ADB インストールは、テストするための最も直接的なパスです。
- ADB インストールの環境を準備する
- ADB インストール APK ワークフローの核心
- ADB インストールのフラグをマスターすることで、ワークフローを高速化する
- インストールの一般的なエラーのトラブルシューティング
- 完全な例 ( Capacitor 開発者向け)
ADB インストールは、テストに最も直接的なパスです
Android アプリを長く作成するうちに、Play Store を主なテストパスとして扱うことがなくなります。ルーチン イテレーションでは、特に許可ダイアログ、プラグイン ブリッジの問題、あるいは一台のデバイスでしか表示されないレイアウトのバグのチェックには、遅すぎます。
ADB Android 1.0 から 2008 年, そして、デバイスにAPKを直接展開する標準的な方法はまだあります。 2024年には、Androidの世界市場シェアは70%を超えましたこれは、幅広いデバイスをカバーするモバイルチームにとって、このワークフローが中心的な理由の1つです。公式のAndroid Debug Bridgeドキュメントで言及されています。 実用的な開発の価値は簡単です:.
ストアの摩擦を回避します:
- レビューのキューなし、テストトラックの遅延なし。 実際のビルドをテストします:
- デバッグ、リリース候補、またはワンオフブランチビルド。 即時フィードバックを受けます:
- インストール、起動、ログの検査、繰り返し。 実用的なルール:
__CAPGO_KEEP_0__ このAPKは物理Androidデバイスで動作するかどうかという質問の場合、通常は最初の答えになります。
adb installこれは、__CAPGO_KEEP_0__ と Ionic の場合に特に重要です。
This matters even more in Capacitor and Ionic work. A browser run tells you whether your web layer renders. It doesn’t tell you whether Android permission handling works, whether a plugin initializes cleanly, or whether your app updates over an existing install without breaking stored data.
コマンド自体は小さくて簡単です。
adb install path/to/app.apk
コマンドの有用性は、シンタックスではなくコントロールにあるのです。 直接インストール、既存のアプリに上書きインストール、古いビルドをテスト、パッケージレベルでのエラーを診断することができます。 そのため、「ADBインストールAPK」は、チームワークフローで「はじめに」フェーズが終わった後も頻繁に出てきます。
ADB環境のセットアップ
ADBの問題の多くは、インストールの問題ではなくセットアップの問題です。 adb機械がデバイスを見つけることができない、デバイスが認証されていない、OEMが追加した設定が存在するなど、セットアップの問題が発生します。
マシンにプラットフォームツールをインストールする
Android Studioのフルインストールが必要なくてもADBを実行できます。 SDK プラットフォーム ツールが必要です。次に、ターミナルがその場所を知る必要があります。
Windows、macOS、Linuxのいずれの場合も、最も綺麗な設定は同じです:
- Googleからプラットフォーム ツールをダウンロードしてください。 アーカイブを解凍して
- 安定した場所に保存してください。 フォルダをPATHに追加してください。
- すると どのターミナルウィンドウでも
adb動作します。
最初からCapacitorマシンを設定する場合、この Android用Capacitorアプリのセットアップガイド より広いツールチェーンの便利なパートナーです。
ターミナルを使用して、コマンドが利用可能であることを確認します:
adb version
「コマンドが見つかりません」という文字列が返されない場合は、問題ありません。
いくつかのプラットフォーム固有の慣習が役立ちます:
- Windows: Platform Toolsを変更されないパスに置き、環境変数にそのフォルダを追加します。
- macOS: シェルプロファイルにフォルダパスを追加します。
.zshrc. - Linux: シェル設定ファイルに同じパスを追加し、シェルを再読み込みします。
デバイスで設定を有効にします
デバイス側も同等に重要です。重要な前提条件は、USBデバッグを有効にすることです。 __CAPGO_KEEP_0__ を通して __CAPGO_KEEP_1__, これは、 __CAPGO_KEEP_2__を7回タップすることで有効化できます。 Xiaomiデバイスの場合、MIUIを搭載している場合、ADBセットアップの参考資料に記載されているように__CAPGO_KEEP_3__ も有効にする必要があります。.
残るのは短いチェックリストです。
- __CAPGO_KEEP_4__ 7回 Build Number をタップします。
- USB デバッグを有効にする: ADB が必要な設定です。
- OEM の追加機能を監視する: Xiaomi はクラシックの例です。
- 信頼できるケーブルで接続する: 充電専用ケーブルは時間を浪費します。
電話の画面の表示もケーブルと同じくらい重要です。 “USB デバッグを許可する?” を見逃すと、コンピューターはデバイスを認識するかもしれませんが、ADB はまだ使用できません。
最初に接続すると、Android はコンピューターを信頼するかどうかを尋ねます。開発用マシンである場合は、常に許可するようにしてください。そうしないと、後でワークフローが失敗し、実際よりも複雑に見えます。
ADB Core インストール APK ワークフロー
設定が完了したら、インストールパスは短くなります。よくある間違いは、次のコマンドが成功する可能性があるかどうかを判断するためのチェックをスキップすることです。
デバイスを確認してください
最初に実行してください
adb devices
接続されたシリアル番号と健常なデバイス状態を確認したいです。デバイスが未承認の状態で表示される場合は、そこで停止し、認証を修正してからインストールを試みること。
チームがデバッグ、QA、リリース候補の出力を管理している場合、どのようなビルドをプッシュしているか明確にすることも役立ちます。この モバイルアプリビルドの種類 は、同名のAPKが大量に保存されているフォルダの場合、参考になる情報です。
インストールコマンドを実行してください
基本的なコマンドは簡単です:
adb install path/to/your-app.apk
パスが空白を含む場合は、シェルで引用符で囲みます。APKが同じフォルダ内にある場合は、コマンドがさらに短くなるでしょう:
adb install app-debug.apk
正常な実行では、インストールメッセージがストリーミングされ、次に成功メッセージがターミナルに表示されます。その出力が望ましいのは、パッケージマネージャーがAPKを受け入れ、インストールを完了したことを確認するためです。
ここでは、実行の流れを確認したい場合は、以下の手順を参照してください:
ストリーミングインストールは、手動プッシュとPmインストールを上回る理由があります
内部では、 adb install にAPKをプッシュし、 /data/local/tmpを呼び出し、 pm installを削除します。ストリーミング ワークフローは、 “Performing Streamed Install” followed by の実装詳細は、のセットアップ リファレンスでまとまっています。
これは重要です。古い2ステップの習慣である adb push を実行し、
- を呼び出す必要があります。これは、ストリーミング インストールの利点です。 少ない手動作業:「
- デバイスの汚れを減らす: 自動で一時的なアーティファクトを消去する。
- 誤りを減らす: 間違えて1つのファイルをプッシュし、別のファイルをインストールすることはありません。
Capacitorを使用できる場合は使用してください。
adb install手動のプッシュとシェルインストールはエッジケースに役立ちますが、通常のアプリケーションテストのデフォルトパスではありません。
ADBインストールAPKワークフローでは、次のループが中心です:
デバイスを検証する、インストールを実行する、成功を確認する、アプリケーションを起動する、ビルドの次に繰り返す。
ADBインストールフラグのマスター
ADBインストールフラグの基本コマンドは、APKを電話に取得します。フラグは、そのプロセスが実際の開発に適合するか、開発者に戦うようにするかを決定します。
| ADBインストールフラグの共通用途と使用方法 | フラグ名(Flag Name)、説明(Description) | 一般的な使用例 |
|---|---|---|
-r |
既存アプリを再インストールして、可能な限りアプリデータを保持する | 毎日デバッグビルドを繰り返す |
-d |
バージョンを下げることを許可する | ロールバックシナリオや古いビルドをテストする |
-g |
インストール時点で実行時許可を付与する | カメラ、ストレージ、位置情報などの機能のテストを高速化する |
通常の開発では最も重要なフラグは -r.
なければ、既にインストールされているパッケージを更新することが多々失敗する。Androidは、新しいAPKを置き換えるものとしてではなく、競合するインストール試行として扱うからである。そのため、多くの開発者は adb install -r app-debug.apk デフォルトの筋肉記憶としている。
どのフラグが日常開発で重要か
-r is the one you’ll use constantly. If you’re testing a Capacitor app and rebuilding several times an hour, uninstalling the app on every cycle is slow and wipes useful local state. Reinstall lets you keep moving.
-d は状況によって異なるが、必要なときに本当に必要なときに役立ちます。レグレッションテスト、ロールバックドリル、または古いビルドがレガシーデータベースを正しく開くかどうかを確認するのに役立ちます。
-g は品質の向上の旗です。アプリが早期にパーミッションに触れる場合、自動的な許可がデバイス設定の繰り返しタップを削減します。正しいパーミッションのテストを置き換えるものではありませんが、インストールと起動を迅速に進める必要があるときに便利です。
しばしば出現する組み合わせは次の通りです:
adb install -r app-debug.apk
adb install -r -g app-debug.apk
adb install -r -d older-build.apk
すべての旗にはトレードオフがあります。便利さが実際のユーザー条件を隠す可能性があります。自動的に許可をすべて毎回与えると、実行時パーミッションのエッジケースを逃す可能性があります。常に古いデータを上書きしてインストールすると、初回起動の問題を逃す可能性があります。
経験豊富なチームは通常、習慣を分割します:
- 高速ループビルド: 使用する場合、
-r時々-g. - クリーンステートチェック: 最初にアンインストールし、次に新しいインストールを実行します。
- ロールバックテスト: 使用する場合
-dバージョン移動がテスト対象の場合のみ。
CLI側のCapacitor開発のより広範なリフレッシュを望む場合は、このCapacitorと__CAPGO_KEEP_1__のコマンドと修正のガイドが適しています。 CapacitorとCLIのコマンドと修正の一般的なガイド ADBに焦点を当てたワークフローとよく相性が良い。
一般的なインストールエラーのトラブルシューティング
ADBは信頼できるので、繰り返し失敗は特定の問題に寄与することが多い。インストールエラーをランダムなものとして扱うのではなく、特定の問題に焦点を当てる必要がある。
デバイスが未承認の場合
症状:
adb devices未承認unauthorized
原因:電話がコンピューターを信頼していない、またはプロンプトがキャンセルされた。
次の順序で修正する
- デバイスを再接続し、ロック画面を閉じてください。 電話でRSA認証のプロンプトを探してください。
- プロンプトを承認してください。 開発用マシンで「常に許可」を選択することをお勧めします。
- まだ回復しない場合、ADBサーバーを再起動してください:端末は問題を技術的なもののように見せますが、実際の解決策は電話自体にあります。
- パッケージがすでに存在する場合
adb kill-server
adb start-server
症状:
これは、replaceフラグを使用せずにすでに存在するパッケージにインストールしようとしていることを意味します。この一般的な誤りは、この
ADBインストールの失敗に関するStack Overflowの議論で説明されています。
INSTALL_FAILED_ALREADY_EXISTS
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__.
最速の修正方法は:
adb install -r app-debug.apk
アップグレードの代わりにクリーンインストールが必要な場合は、まずアンインストールしてください:
adb uninstall your.package.name
再インストールパスを使用して、定期的な反復を実行します。アンインストールを使用するのは、ローカルアプリの状態をクリアしたいときまたは初回起動の動作を検証したいときのみです。
署名と古いパッケージ状態が衝突する場合
APKファイルそのものではなく、パッケージに関するAndroidの記憶が原因の失敗もあります。
よく見られる2つのパターンがあります:
- 署名が一致しない: インストール済みのアプリが、APKをインストールしようとしているものとは異なる署名で署名されていた場合です。
- パッケージ状態の重複: アンインストールしてもパッケージの残骸が残り、次のインストールをブロックすることがあります。
特に2番目のパターンは、成功したアンインストールの後に生じる可能性があり、非常に面倒なことです。新しいAndroidバージョンでは、古いアンインストールの動作が残ったパッケージ状態が、 INSTALL_FAILED_DUPLICATE_PACKAGE、ソース上記に記載されているように、起動をトリガーすることがあります。
実用的な診断フローは次のようになります。
- 最初にパッケージの正当性を確認してください。 __CAPGO_KEEP_0__を確認してください。
- 次に署名の一貫性を確認してください。 デバッグ署名とリリース署名のビルドは互いに置き換えることができません。
- 次にインストールされているパッケージを削除してください。 __CAPGO_KEEP_0__の通常のアンインストールパスを使用してください。
- エラーが続きます。 それを古いパッケージの状態として扱ってください。ADBのランダムなエラーではありません。
デバッグAPKが通常の開発ツール以外で配布される場合、もう一つの問題が生じます。あるチームは、ADBを通じて同じビルドをインストールすることができますが、メッセージングまたはメールから手動でサイドロードすると失敗することがあります。そのような動作は、Androidのデバッグ署名アプリのコンテキスト認識によるものであり、この Android上のアプリインストールエラーを解決するためのガイド実際には、QAチームは内部デバッグ配布にADBを使用するのではなく、適時な手動サイドロードに頼るのではなく、内部デバッグ配布にADBを使用することをお勧めします。
Field note: ADBを介してインストールされる場合でも、手動でタップしてインストールできない場合、APKが破損しているのではなく、署名コンテキストとインストールパスを確認してください。
For Capacitor projects that keep throwing build and deploy issues across native and web layers, this troubleshooting guide for resolving Android build errors in Capacitor を参考にしてください。
A Complete Example for Capacitor Developers
In a Capacitor project, the terminal loop is usually short. You sync native files, build the Android app, and push the resulting APK to a connected device without opening Android Studio unless you need native debugging.
例えば、以下のようなシンプルな例があります。
npx cap sync android
通常のAndroidビルドステップからデバッグAPKをビルドし、置き換えを有効にした状態でインストールしてください。
adb install -r android/app/build/outputs/apk/debug/app-debug.apk
このワークフローは、フィードバックループを短く保つため、多くのチームが採用しています。CapacitorJSアプリケーションでは、差分アップデートを配信するチームが多いからです。 Cloudflare Capacitor adb install は特に重要です。IBMの研究では、 Androidベースのモバイルチームの 78%がPlay StoreのサブミッションよりもリアルタイムのJavaScriptとCSS修正のために この.
ADBベースのAPKインストールをカバーするビデオリファレンス Capacitor CLI installation guide プロジェクト側のセットアップをまだ行っている場合、この
Capacitor __CAPGO_KEEP_1__ Capgo は堅実なスタートポイントです。
