drozer: an Android security testing framework that runs as an app on the device

What drozer is for, and who ends up using it

drozer exists for the moment in an Android assessment when you stop reading a manifest and start asking the device what it will actually let you do. The README describes the model directly: drozer assumes the role of an app and interacts with the Android Runtime, other apps' IPC endpoints, and the underlying OS. That framing matters, because it means the tool is not a scanner that reports findings from the outside. It runs code in the context of its own agent process on the device, then exposes what it finds through a console on your workstation.

The audience is narrow and specific. Mobile penetration testers assessing an app or a device build, and developers who want to confirm how their own app's exported components behave once installed, are the two groups the workflow suits. The README also states that drozer provides tools to help use, share and understand public Android exploits, which points at a research use case rather than a CI gate. If your goal is a pass or fail check inside a build pipeline, the console model and the on-device agent are more machinery than that task needs.

The agent, the console, and the port 31415 channel

The architecture is a two-part split. A Python package installs the console on your machine, and a separate agent APK runs on the Android device or emulator. The agent embeds a server. The README instructs you to launch the agent, pick the Embedded Server option, and tap Enable, after which a notification confirms the server has started. That server listens for incoming TCP connections on all interfaces on port 31415 by default.

The console then connects to that listener. Everything you type at the dz> prompt is a command executed through the agent, not locally. The command reference lists the surface: run executes a module, list shows the modules available in the current session while hiding ones you lack permission to run, shell opens an interactive Linux shell in the context of the agent process, cd mounts a namespace as the session root so you stop typing full module names, and load executes a file of drozer commands in sequence. The permissions command reports which permissions the agent itself holds, which is a useful sanity check before you trust a module's output.

Two details in that design are worth flagging. First, the agent's reach is bounded by its own granted permissions, so a module that cannot see something may be blocked by the agent's manifest rather than by the target app. Second, because the server binds on all interfaces, the network path is only appropriate on a test network you control; the README offers the adb port-forward path precisely for scenarios where network connection is not viable.

Installing drozer with pipx and connecting over USB

The README recommends pipx over plain pip for the console. The Python prerequisite is 3.8, and pyproject.toml pins requires-python to >=3.8 with dependencies on protobuf, pyopenssl, twisted, service-identity, distro, pyyaml, requests and prompt_toolkit.

pipx install drozer
pipx ensurepath

After the second command the drozer executable should be on your PATH. If you prefer a pinned artifact, the README also supports installing a downloaded wheel directly with pipx install ./drozer-*.whl.

On the device side, the agent is installed over adb. The README points at the drozer-agent releases page for the APK.

adb install drozer-agent.apk

Start the agent on the phone, enable the Embedded Server, then set up the USB path. This is the option the README gives for cases where connecting over the network is not viable, and it uses port 31415 on both ends.

adb forward tcp:31415 tcp:31415
drozer console connect

With no --server argument the console targets localhost, which the forward maps to the agent. A successful connection prints the device's Android ID plus manufacturer, model and Android version, followed by an ASCII banner and the dz> prompt. If you would rather go over the network, the equivalent is drozer console connect --server <phone's IP address>, and the Docker variant is docker run --net host -it drozerdocker/drozer console connect --server <phone's IP address>.

The beta label is not decoration

The README states plainly that this is a beta release of a rewritten drozer, updated for Python 3, and then lists a known issue: building custom agents functionality will crash the drozer client. It goes further and says that functionality is considered out of scope for the beta release of the revived project. Anyone whose workflow depends on compiling a bespoke agent should treat that as a hard stop rather than a bug to work around.

The build path has its own friction. Building from source means cloning the repository and running pip install . in the checkout, and the native Android components compile against an SDK you point at with the ANDROID_SDK environment variable, which the README shows set to a specific android.jar such as platforms/android-34/android.jar. The d8 tool location is overridable through D8, and setup.py raises an error if javac is not on the PATH. So a source build needs a JDK 11 or greater in addition to the Python prerequisites, which is a heavier requirement than the pipx route.

The third constraint is version alignment between the two halves. The console and the agent are separate artifacts with separate release streams, and the README does not document a compatibility matrix between them. That silence is the practical risk: a console from one release talking to an agent from another is an untested combination as far as the documentation goes.

drozer, MobSF and Frida solve different problems

The comparison people reach for is drozer versus MobSF, and the difference is where the analysis happens. MobSF is a static and dynamic analysis platform that takes an APK or source tree and produces a report; its unit of work is an artifact and its output is a findings document. drozer's unit of work is a live session against an installed agent, and its output is whatever you ask for at the console. If you need a repeatable report on an APK you were handed, MobSF's model fits better. If you need to interrogate a device's IPC surface interactively, drozer's does.

The Frida comparison is about depth. Frida hooks into running processes at the native level, letting you intercept function calls inside an app. drozer operates at the level of Android's app-facing interfaces: the runtime, IPC endpoints, and the OS as seen from an app's position. That means drozer is the better starting point when the question is what an app exposes, and Frida is the better tool when the question is what a specific function does with the data it receives. They are complementary rather than competing, and a device assessment can reasonably use both.

Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push to the develop branch was on 2026-04-08. The most recent release listed is 3.1.0 from 2024-08-01, preceded by 3.0.3 in June 2024 and 3.0.2 in April 2024. The gap between the latest release and the latest commit activity is the thing to plan around: commits land on develop, but a tagged release is a separate event, so a fix you are waiting for may sit unreleased for a while.

Licensing is stated inconsistently across the files. pyproject.toml declares license = { file = "LICENSE" }, which defers to the repository's LICENSE file, and its classifier says License :: OSI Approved :: BSD License. The repository metadata reports the licence as NOASSERTION, meaning GitHub could not map the file to a known identifier. Since the dependency set includes pyopenssl, twisted and protobuf, an organisation that reviews licences will want to read the LICENSE file directly rather than trust the classifier. This is not legal advice, just a note that the machine-readable fields disagree.

Upgrade cost is dominated by the console and agent pairing described above. Because the README does not publish a compatibility matrix, the safe upgrade unit is both artifacts together: bump the pipx-installed console and the agent APK in the same change, and re-run a known module against a known device to confirm the session still behaves. Keeping the old wheel around makes rollback a matter of reinstalling it.

Editorial conclusion

drozer fits Android testers who want a console-driven view of IPC endpoints and device configuration on a rooted or debuggable test device, and who can live with the beta caveats the README states. It is the wrong tool if you need to instrument a running process at the native level, which is Frida's job, or if you need static source scanning, which is MobSF's. Before adopting it, verify two things on your own setup: that your agent APK version matches your console release, and that custom agent building is not part of your workflow, because the README lists it as crashing the client and out of scope for the beta.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ReversecLabs/drozer on GitHub