
Master Android’s adb shell monkey to Stress-Test Android Apps Like a Pro
Table of Contents
TL;DR
- I can launch an app instantly with adb shell monkey -p com.example -v 1 and then throw thousands of random events into it.
- A deterministic run with -s 12345 lets me reproduce crashes in minutes instead of days.
- By piping adb logcat into a file and pulling an adb bugreport afterward, I get a 60 MB ZIP that contains stack traces, memory usage, and system state.
- I keep the device safe by using –throttle 300 to avoid overheating and by stopping the test with adb shell kill
. - My chaos test can generate 50,000 mixed user actions in under 3 minutes, giving me a high-coverage crash hunting session.
Why this matters
I used to sit in a dark room, stare at my laptop, and wait for a flaky app to crash after hours of manual testing. Every crash meant a new log, a new bug report, a new guess. The real pain was that I had no way to rapidly launch the app, send a flood of random touches, and capture everything that happened—without losing my sanity or the device.
With the adb shell monkey tool, that chaos becomes a controlled experiment. It is the single command that can stress-test the entire device, from the UI to the framework, while keeping logs, memory metrics, and system state in a single artifact. For Android developers, QA engineers, and security researchers, the monkey is a must-have weapon.
Core concepts
The Monkey command is a program that runs on your emulator or device and generates pseudo-random streams of user events such as clicks, touches, or gestures, as well as a number of system-level events ADB Shell Monkey — Android Application Testing Tool (2024). It runs from a regular adb shell prompt, so you can embed it in scripts or CI pipelines. The most useful options are:
| Parameter | Use Case | Limitation |
|---|---|---|
| -P | Target a single app for all events | Cannot test multiple apps in one run |
| -s | Deterministic, repeatable chaos | Same seed can miss rare bugs |
| –throttle | Slow down events to avoid lockouts | Too low a delay can make the test feel sluggish |
The default behavior is to send any event to any package, which can cause a PIN prompt or even lock the device. By restricting the test to your package (-P) and using a throttle, you keep the test safe and reproducible.
What can you tell the Monkey to do?
- Event count (
): how many events to generate. A full-device stress test can hit 50 000 mixed user actions in just a few minutes. - Verbosity (-v): more -v levels give you more real-time feedback.
- Seed (-s): repeat the exact same sequence of events every time.
- Throttle (–throttle): add a delay between events, e.g. 300 ms, to keep the device from overheating or getting locked.
How to apply it
Below is my personal recipe that I use every time I want to run a quick chaos test on a new build.
Set up the environment
- Install the latest Android SDK Platform Tools.
- Connect a test device or start an emulator.
- Enable Developer options on the device; if you are a security researcher, install Magisk to intercept events.
Start logging
adb logcat --format=brief > logcat.txt &This writes all device logs to logcat.txt. If you prefer colored output, pipe the logcat into pidcat or logcat-color – both are free and work on Linux StackOverflow — Color the lines of logcat on Linux (2012).
Launch the Monkey
adb shell monkey -P com.example.app -s 987654321 -v 3 --throttle 300 50000- -P com.example.app limits the test to your app.
- -s 987654321 seeds the random generator so you can replay the test later.
- -v 3 gives you a good amount of feedback.
- –throttle 300 slows each event by 300 ms.
- 50000 is the number of events.
If you want a quick sanity check, use just -v 1 1000.
Watch the output The Monkey prints a line for each event it sends. You’ll see things like Event #123: Touch at (345, 678) and Event #124: KEYCODE_ENTER. If the app crashes, Monkey will stop automatically and report the error.
Stop the test gracefully If you need to halt the Monkey before it finishes, grab the Monkey PID and kill it:
adb shell ps | grep com.android.commands.monkey | awk '{print $2}' | xargs -I{} adb shell kill {}(I learned this trick from a StackOverflow answer that explains how to stop a running monkey StackOverflow — How to use Monkey and Monkeyrunner tools for Android testing (2023).)
Pull a bug report
adb bugreport > bugreport.zipThe resulting ZIP is about 60 MB and contains logs, stack traces, and the device’s state at the moment of the crash ADB Bugreport — Bug Report Capture (2024).
Analyze the logs Open logcat.txt in your favorite editor or pipe it into grep to find stack traces or OutOfMemoryErrors. The bug report ZIP is a goldmine if you want to dig deeper.
Pitfalls & edge cases
| Problem | Why it happens | How to mitigate |
|---|---|---|
| Device locks or requires PIN | Random navigation events can hit the lock screen | Use -P to stay inside your app and –throttle to slow down |
| Device overheats | 50 000 events in seconds raise CPU usage | Add –throttle 300 or limit events to 10 000 |
| Data loss or corruption | Random swipes can trigger app flows that delete data | Run tests on a dedicated test device or an emulator with a fresh image |
| Unreliable crash reproduction | Random sequences differ each run | Use the same seed with -s to replay the exact same event stream |
| Inconsistent bug reports | Logging may miss some events if you kill the Monkey too early | Wait for the Monkey to finish naturally or send a signal to flush logs before pulling the bug report |
The Monkey is powerful, but with great power comes responsibility. Always use a device that you can afford to lose a few minutes of uptime, and keep a backup of your data before running a large test.
Quick FAQ
Can I run the Monkey inside a CI pipeline? Yes. The command is just a shell script; add it to your Android test stage and parse the output in your build report.
What is the difference between Monkey and MonkeyRunner? Monkey generates pseudo-random events directly on the device, while MonkeyRunner is an API that lets you script specific actions from a host machine.
How many events are safe to run on a physical device? Around 10 000–20 000 for a single test. Anything higher can heat the device and risk a lockout.
Can I target a specific activity instead of the whole app? Yes, use adb shell monkey -p com.example.app -c android.intent.category.LAUNCHER.
Is the Monkey still supported in Android 14? Yes, it is part of the Android SDK Platform Tools and works unchanged.
What if the Monkey crashes the device? The device will reboot automatically. Pull a bug report immediately after it restarts.
Conclusion
adb shell monkey is a simple, free, and battle-tested tool that lets you turn random user input into a structured test. By combining it with deterministic seeds, throttling, and live log capture, you can uncover hidden crashes, memory leaks, and framework bugs in minutes. If you are a developer, QA engineer, or security researcher, make Monkey a core part of your daily workflow. Start with a handful of events, watch the logs, pull a bug report, and iterate. If you keep the device safe with throttling and targeted packages, you’ll find that even the most elusive bugs will surface.
References
- ADB Shell Monkey — Android Application Testing Tool (2024) – https://developer.android.com/studio/test/other-testing-tools/monkey
- ADB Bugreport — Bug Report Capture (2024) – https://developer.android.com/studio/debug/bug-report
- Logcat — Android Logging Tool (2024) – https://developer.android.com/tools/logcat
- StackOverflow — How to use Monkey and Monkeyrunner tools for Android testing (2023) – https://stackoverflow.com/questions/12294780/how-to-use-monkey-and-monkeyrunner-tools-for-android-testing
- StackOverflow — Color the lines of logcat on Linux (2012) – https://stackoverflow.com/questions/3360985/color-the-lines-of-logcat-on-linux-android



