ASHWIN990/ADB-Toolkit

Project Overview

ADB-Toolkit is a Shell script that wraps Android Debug Bridge (ADB) commands into a menu-driven interface. Instead of memorizing dozens of ADB flags and syntax, you get a numbered menu that lets you run common Android device operations — app management, screen capture, file transfer, device info, and more — by selecting options rather than typing raw commands.

The project targets developers and enthusiasts who work with Android devices regularly but find raw ADB syntax tedious to recall mid-session. V2 adds more operations and a cleaner menu structure compared to the original release.

One thing to know upfront: this is a personal convenience script by a single contributor with no formal release process, no changelog, and no test suite. Factor that into any decision to depend on it in a shared or repeatable workflow.

Key Challenges Addressed

Raw ADB has a steep recall curve. The same developer who can write complex build scripts will blank on whether it is adb shell pm list packages -3 or adb shell pm list packages -f when needed in a hurry. ADB-Toolkit targets three specific friction points:

• Command recall overhead: the menu maps readable descriptions to correct ADB invocations so you do not need the man page open.

• Multi-step operations: some useful workflows (like wireless debugging setup) require several sequential ADB commands in the right order. The toolkit chains these so you do not skip a step.

• Shell environment friction: on Windows especially, running raw ADB in a consistent bash environment is awkward. The script gives you a predictable execution layer.

Getting Started

Clone the repository and make the script executable:

git clone https://github.com/ASHWIN990/ADB-Toolkit.git
cd ADB-Toolkit
chmod +x ADB-Toolkit.sh
./ADB-Toolkit.sh

Prerequisites you must satisfy first:

• ADB must be installed and on your PATH. On macOS: brew install android-platform-tools. On Linux: sudo apt install adb. The script does not check for this — you will get confusing errors from ADB itself if adb is not found.

• A device must be connected via USB with USB debugging enabled, or already paired via adb pair for wireless. Running the toolkit without a recognized device produces error: no devices/emulators found from ADB, which the script does not catch or explain.

• Run inside a bash shell. Zsh compatibility is not tested and some menu inputs may behave differently.

Sharp edges you will hit immediately:

• If you have multiple devices connected, ADB will error unless a specific device is targeted via -s. ADB-Toolkit has no device selector — disconnect extra devices before using it or operations will fail.

• Some adb shell commands differ between Android versions. A command that works on Android 12 may fail silently on Android 8. The toolkit documents no per-command API-level requirements.

Features and Use Cases

The toolkit organizes operations into a numbered top-level menu. Typical use cases:

App management: install, uninstall, list installed packages, clear app data, force-stop apps. Useful during development when you are repeatedly cycling through fresh installs without opening Android Studio.

Device information: dump build props, check battery status, retrieve device identifiers. Handy for quick device profiling before running device-specific tests.

File operations: push and pull files between your host and the device /sdcard/ tree. If you do a lot of manual file testing, this saves typing the full adb push /path/to/local /sdcard/target form repeatedly.

Screen capture and recording: take screenshots and screen recordings and pull them to the local machine automatically. Faster than navigating the device manually for capturing test evidence.

Networking and wireless ADB: automates the adb tcpip and adb connect sequence for Wi-Fi debugging. This is where the toolkit saves the most practical time — the two-command sequence has to happen in the right order every session, and a missed step means starting over.

System and shell access: quick entry into adb shell, reboot to recovery or bootloader, and a handful of root-oriented commands for rooted devices.

Ecosystem and Dependencies

ADB-Toolkit has no dependencies beyond ADB itself and bash. It does not wrap any higher-level Android tooling.

If you need screen mirroring and remote control on top of ADB operations, scrcpy is actively maintained and explicitly supports multi-device selection via -s — a gap ADB-Toolkit does not fill.

For colorized logcat filtering during debugging, pidcat pairs well with this toolkit. It handles log presentation while ADB-Toolkit handles device control. Note that pidcat's commit activity has slowed in recent years; check its issue tracker for current Android API-level compatibility before adopting it.

If you already use Android Studio, its built-in Device Manager and Logcat cover most of the same operations with better error handling and a GUI. ADB-Toolkit's value is specifically on the command line without an IDE open.

Architectural Overview

The entire project is a single bash script (ADB-Toolkit.sh) with nested case statements driving menu navigation. Each menu selection executes one or more adb subprocess calls, then returns to the menu on completion.

This design is easy to read and modify. Adding a new operation means adding one menu entry and one case branch. There is no state management, no configuration file, and no plugin layer.

The flat-script design also means there is no separation between UI and logic. If you want to automate a specific operation non-interactively — for example, in a CI step — you cannot call it by function name or flag. You will need to invoke the raw ADB command directly or modify the script to accept arguments.

Pros and Cons

Pros:

• Zero setup beyond ADB itself. Clone and run immediately.

• Useful for developers who use ADB sporadically and do not retain full command syntax between sessions.

• Readable bash source — you can see exactly what ADB command each menu item runs, which builds your own ADB knowledge over time.

• The wireless debugging setup sequence is the biggest practical time-saver: two commands that have to run in the right order, automated into one menu selection.

Cons:

• Single-maintainer project with no formal release process, no changelog, and no semantic versioning.

• No multi-device support. With more than one device connected, most operations fail or target the wrong device.

• Interactive-only design. You cannot use this in CI pipelines, automation scripts, or any headless context.

• No error handling for common failures: ADB not found, no device connected, insufficient permissions. Errors pass through from ADB directly with no actionable guidance.

• Android API-level compatibility is undocumented per command.

Comparison and Alternatives

scrcpy covers the same ADB convenience space with far stronger maintenance signals: it is actively developed by Genymobile, has thorough official documentation, handles multi-device selection explicitly via -s, and adds screen mirroring and remote control on top of a full ADB operation set.

pidcat covers a narrower scope — colorized logcat filtering — but does it precisely. It is written by Jake Wharton and is widely used in Android development. Commit activity has slowed, so verify current Android API-level support before adopting it.

The best overall alternative is scrcpy. It has the strongest maintenance signals of the two, explicit multi-device support, richer documentation, and a significantly wider feature set while remaining command-line-first.

Conclusion

ADB-Toolkit is the right pick for solo Android developers who want a fast command-line menu for routine device tasks without memorizing ADB flag syntax. Start with the official repository and you are running in under a minute.

Do not use ADB-Toolkit with multiple devices connected — it has no -s device selector, so operations will fail or silently target the wrong device. Before your first session, run adb devices and confirm exactly one entry appears.