The Problem

ADB's command-line interface is functional but hostile for file management tasks. Browsing device storage, transferring files, and editing remote files requires memorizing shell commands and juggling multiple terminal sessions. ADB-Explorer replaces that workflow with a WPF desktop application that presents the device filesystem in a familiar Explorer-style UI.

What This Does

ADB-Explorer is a Windows desktop application built in C#/WPF that provides a graphical interface to the Android Debug Bridge. It lets you browse device folders, push/pull files, install/uninstall APKs, view device logs, and run a terminal session—all through a Fluent-designed UI. The project is a fork of Alex4SSB/ADB-Explorer (954 stars) and is available on the Microsoft Store.

The codebase is organized into clear functional areas: Controls/ contains the UI elements (icons, pages, dialogs), Helpers/ holds the business logic (file operations, ADB wrappers, archive handling), and Models/ defines the data structures. The ADB_Test/ directory contains test files, though the main project has none.

How It Is Wired

The application entry point is ADB Explorer/App.xaml.cs, which initializes the WPF application and sets up the main window. From there, control flows through the page headers in Controls/Pages/ (e.g., ExplorerPageHeader.xaml.cs, DevicesPageHeader.xaml.cs) which coordinate the main views. The core ADB interaction happens in Services/ADB/ADBService.cs—this is where commands are constructed and executed against the connected device.

The file operations logic lives in Helpers/File/ (e.g., FileHelper.cs, ArchiveHelper.cs, TrashHelper.cs) and Services/AppInfra/FileAction/FileActionLogic.cs. These modules handle the actual file transfers, archive extraction, and conflict resolution. The Controls/Icons/ folder contains 40+ XAML-based icon definitions used throughout the UI.

The app persists user settings to settings.json in %LocalAppData%\AdbExplorer (or a package-private folder for the Store version). The Helpers/AppInfra/SettingsHelper.cs manages this file. The FaroCollector.url.example file suggests optional telemetry integration.

How To Use It

Setup: Clone and build:

git clone https://github.com/moses-y/ADB-Explorer
cd ADB-Explorer
# Open ADB Explorer.slnx in Visual Studio and build, or use:
dotnet build "ADB Explorer/ADB Explorer.csproj"

Configuration: No environment variables required. The app needs adb (Android platform-tools) available on the system PATH. Settings are stored in settings.json and can be edited manually, though the format must be preserved.

Running it: Launch the built executable. The app will detect connected devices via ADB and present them in the devices page. From there you can browse the device filesystem, transfer files, and run terminal commands.

Real-World Use

A developer testing an Android app on a physical device uses ADB-Explorer to:

  1. Browse /sdcard/Android/data/ to inspect app-specific storage.
  2. Pull a crash log file to the desktop for analysis.
  3. Push a new APK build and install it with a single click.

The UI removes the need to remember adb pull, adb push, and adb install command syntax.

Code Health & Issues

Static analysis (not opinion) found 100 issues across 3 categories:

  • High - Deep nesting: 55 occurrences, max indentation depth 9. Files like App.xaml.cs, AssemblyInfo.cs, and DetailsPane.xaml.cs have control flow that is hard to follow. Fix: extract inner blocks or use guard clauses.
  • High - Duplicated code blocks: 65 repeated 6-line blocks across 25 files, including PullIcon.xaml.cs, PushIcon.xaml.cs, and ExplorerPageHeader.xaml.cs. Fix: extract shared helpers.
  • High - Oversized files: 4 files exceed reasonable size, with ExplorerPageHeader.xaml.cs at 1714 lines. Fix: split by responsibility.

Additional health findings:

  • High - No test suite: 287 source files, 0 test files. Any change ships with no regression signal. Fix: add one test per public entry point plus a CI step.
  • Low - Missing CI timeouts: .github/workflows/verify-release-visibility.yml has no timeout-minutes set. A wedged job runs to the 6-hour platform default. Fix: add a realistic bound.

The Bottom Line

A functional WPF ADB GUI with a clean UI and sensible module layout. The codebase is maintainable but needs test coverage and refactoring of the oversized files before it should be extended. Suitable for developers who want a visual ADB tool without building their own.