adb-enhanced (adbe): a Python wrapper that turns long adb incantations into named subcommands
🔪Swiss-army knife for Android testing and development 🔪 ⛺
At a glance
- What is it?
- adb-enhanced wraps the Android Debug Bridge so that doze mode, battery saver, mobile data, screen recording and permission changes become short adbe subcommands. It is a convenience layer for engineers who already have adb working, not a replacement for it.
- Who is it for?
- Adopt adb-enhanced if you already drive physical devices or emulators from a shell and keep retyping the same adb settings commands; the README's examples (adbe doze on, adbe mobile-data off, adbe battery saver on, adbe screenshot) are the whole pitch. Skip it if you need a programmatic client inside a test process, since this is a CLI wrapper around the adb binary and the README states it is not a replacement for adb.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The commands adb makes you look up every time
Most Android settings changes are one-line adb invocations, but the line is never the one you remember. Doze mode, battery saver, data saver, mobile data, background activity limits and navigation mode each map to a different service call or settings key, and the exact form drifts between Android versions. The README frames the project as a command-line interface to trigger scenarios such as screen rotation, battery saver mode, data saver mode, doze mode, and permission grant or revocation. That list is the product. It is aimed at developers and testers who already have adb on PATH and a device or emulator connected, and who want the scenario named rather than spelled out. If you work on an app that behaves differently under doze or under a data saver, being able to type adbe doze on instead of reconstructing the device-idle command is the entire value proposition.
A wrapper, not a reimplementation: what sits between you and the device
The README is explicit that adb-enhanced is a wrapper around adb and not a replacement. That single sentence defines the architecture. adbe does not speak the ADB wire protocol, does not manage the adb server, and does not ship its own device transport. It is a Python program that composes and invokes adb commands on your behalf, which means every precondition adb has still applies: the platform-tools binary must be installed, the device must be authorised for USB debugging, and wireless debugging must already be reachable before adbe enable wireless debugging is useful. The upside of that design is that adbe inherits adb's device compatibility instead of maintaining its own. The downside is that when adb fails, adbe fails with it, and the error you see may come from the layer below. The README also documents bash and zsh auto-completion through infi.docopt-completion, which tells you the CLI parses its arguments with docopt; the subcommand grammar is declared in the program rather than discovered at runtime.
Installing adbe and getting it onto PATH
The README gives two installation routes. The recommended one is sudo pip3 install adb-enhanced. On macOS there is also brew install adb-enhanced. Two constraints come straight from the README's note section. First, Python 2 is no longer supported; the pip install works only for Python 3. Second, if you install without sudo, adbe might not be configured correctly in the path, so the command may simply not resolve after a successful install. That is a packaging detail rather than a bug, but it is the first thing to check when nothing happens. Shell completion is a separate step: sudo pip3 install infi.docopt-completion followed by docopt-completion $(which adbe). The README's examples use plain adbe for everything, so once the binary resolves there is no further configuration to write.
What the documented subcommands actually cover
The examples in the README cluster into three groups. Device state: adbe doze on, adbe mobile-data off, adbe battery saver on, adbe dont-keep-activities on. Capture: adbe screenshot ~/Downloads/screenshot1.png, and adbe screenrecord video.mp4, which the README annotates with a note to press Ctrl-C when finished, meaning the recording runs until you interrupt it rather than stopping on its own. Connectivity and input mode: adbe enable wireless debugging, and adbe navigation, which the README describes as switching between gesture and button navigation on Android 10 and above. The README also names screen rotation and permission grant or revocation in its opening description. The API-level note on navigation is the kind of boundary worth reading twice: where the README states a minimum version, treat older devices as untested rather than supported.
Where the wrapper model breaks down
Because adbe shells out to adb, it cannot do anything adb cannot do, and it cannot make adb faster or more reliable. If the adb server is stuck, adbe is stuck. If a device drops off USB mid-run, adbe reports what adb reports. The wrapper also adds a dependency the raw tool does not have: a Python 3 interpreter and a pip or Homebrew install that has to be repeated per machine and kept in step with whatever adb version you run. For scripted CI, that is an extra install step in every image. The README does not document an exit-code contract, machine-readable output, or a library API, so anything that needs to branch on the result of a settings change is better served by calling adb directly and parsing its output yourself. The wrong tool is also any workflow already standardised on a higher-level harness: if your team drives devices through a test framework that owns device setup, adding a second CLI that mutates the same global device state invites conflicts over who last touched battery saver or mobile data.
Alternatives and the difference in approach
The obvious alternative is adb itself, and the difference is purely one of ergonomics. adb is the transport and the command surface; adb-enhanced is a vocabulary of named scenarios layered on top. Choosing raw adb costs you the memorisation and buys you nothing between you and the device, no extra install, no Python. Choosing adbe costs an install and buys you the names. The other alternative is a device automation library such as an Appium or UiAutomator-based harness, which is a different kind of tool: it drives the UI from inside a test process and can assert on what the app renders. adbe does not do that. It flips device-level switches, captures the screen, and stops. If your question is does the app survive doze, adbe is the shorter path. If your question is does the app render the right thing after doze, you need the harness, and adbe at most sets the precondition before it runs.
Maintenance cost and licence
The repository is not archived and the last push recorded is 2026-09-10, so the project is still being touched. No releases were retrieved in the material supplied here, which means version pinning advice cannot be given from this source; check PyPI and the Homebrew formula for the current version before you freeze anything. The licence is Apache-2.0, a permissive licence that allows commercial use and modification provided the licence and notices are preserved, but this is a description of the identifier and not legal advice; read the LICENSE file and your own policy if you plan to redistribute a modified copy. The practical maintenance burden is low, because the surface area is a set of adb invocations and the upstream dependency is adb, not a runtime you have to host. The recurring cost is the install step on each developer machine and each CI image, plus the risk that an Android release changes a settings key underneath a subcommand.
A short list of things to confirm before you rely on it
Confirm that adbe resolves on PATH after your chosen install route, since the README calls out the no-sudo case as a known source of path trouble. Confirm that the specific subcommand you care about behaves on your target API level; the README's own version caveat on adbe navigation shows the project documents at least one such boundary. Confirm that your team is not already mutating the same device state through another tool, because doze, battery saver and mobile data are global switches on the device, not per-app settings. And confirm that a CLI is the right shape for your use case at all: adbe is built for a human at a shell, and nothing in the README suggests it was designed for programmatic consumption.
Editorial conclusion
Adopt adb-enhanced if you already drive physical devices or emulators from a shell and keep retyping the same adb settings commands; the README's examples (adbe doze on, adbe mobile-data off, adbe battery saver on, adbe screenshot) are the whole pitch. Skip it if you need a programmatic client inside a test process, since this is a CLI wrapper around the adb binary and the README states it is not a replacement for adb. Before committing, verify on your own device that the subcommand you depend on matches your Android API level, and check whether your install path puts adbe on PATH, because the README warns that installing without sudo can leave adbe unconfigured.
Community notes