The Problem
Android developers and QA engineers often need to interact with devices via ADB for testing—running shell commands, sending text input, capturing screenshots, or managing virtual displays. Doing this from a terminal is workable but slow and error-prone, especially when commands are repeated across sessions or shared with less technical team members. A GUI wrapper around ADB reduces friction but must stay lightweight and cross-platform.
What This Does
AdbPad is a Kotlin desktop application (Compose Multiplatform) that provides a graphical interface for common ADB workflows. The codebase is cleanly layered: core/domain holds models and use cases, core/data handles persistence and repository implementations, core/mvi provides an MVI state management base, and core/view contains reusable UI components. The main UI lives in main/kotlin/jp/kaleidot725/adbpad/ui/ with screens for commands, device settings, and device management.
Key features map to specific files: command execution is handled through ExecuteCommandUseCase.kt and CommandScreen.kt, screenshots via TakeScreenshotUseCase.kt, text input via ExecuteTextCommandUseCase.kt, and scrcpy virtual display support through LaunchScrcpyUseCase.kt and related files. The app supports multiple languages (English, Japanese, Chinese, Turkish) and persists settings like SDK path and appearance.
How To Use It
Setup: The project uses Gradle with Kotlin DSL. Build from source with ./gradlew build (or gradlew.bat on Windows). Prebuilt installers are available via Homebrew for macOS: brew tap kaleidot725/app && brew install --cask adbpad, or from the GitHub Releases page.
Configuration: The app requires the Android SDK path, configured in-app via Settings. No environment variables or external config files are needed. Settings are persisted locally through SettingRepositoryImpl.kt and related repository classes.
Running it: The entry point is main/kotlin/jp/kaleidot725/adbpad/Main.kt. After launching, connect a device via USB or emulator, then use the UI to run commands, capture screenshots, or manage scrcpy profiles. The app detects connected devices via DeviceRepositoryImpl.kt.
Build from source
./gradlew build
Run locally
./gradlew run
Real-World Use
A QA engineer testing a large-screen Android app can use AdbPad to: connect a physical device, launch a scrcpy virtual display with custom resolution via LaunchScrcpyNewDisplayUseCase.kt, send test input text through ExecuteTextCommandUseCase.kt, and capture screenshots at each step with TakeScreenshotUseCase.kt. Saved command favorites and text snippets reduce repetitive typing across test cycles.
Code Health & Issues
Med - Single test file in the repo - Testing is minimal relative to the codebase size. Core logic like ExecuteCommandUseCase and repository implementations appear untested. CI exists (pullrequestcheck.yaml) but test coverage is thin. Low - macOS unsigned binary - The README explicitly warns about unsigned app warnings on macOS. This is a distribution limitation, not a code defect. Low - Fork with no active maintenance signal - This is a fork of kaleidot725/adbpad (406 stars) with zero stars and no visible activity. The original project is more established; consider using that directly unless specific changes exist here. Low - No obvious error handling in process execution - ScrcpyProcessRepositoryImpl.kt and DeviceControlCommandRepositoryImpl.kt spawn external processes; the codebase doesn't show explicit handling for process failures or timeouts.
The project is well-structured with clear separation of concerns, a proper MVI pattern, and organized repository interfaces. CI workflows for Windows and macOS builds are present. No secrets or obvious config leaks found.
The Bottom Line
AdbPad is a well-architected desktop tool that genuinely improves ADB workflows for Android testing. The code is clean and modular, but the fork offers no clear advantage over the original 406-star project. Use the upstream kaleidot725/adbpad unless this fork has specific fixes you need. For teams that prefer GUI over terminal ADB, it's a solid option—just verify the fork's maintenance status before adopting it.