Using Android Monkey for Automated Testing: Parameters, Commands, and Practical Guidelines
This article explains how the Android Monkey tool can be used to perform automated stress testing on fragmented Android devices, covering its purpose, installation locations, key command‑line parameters, a complete example command, and practical steps for integrating Monkey into a mobile testing workflow.
Background – Android device fragmentation makes it difficult to test every model manually; the Monkey tool helps increase coverage, detect stability, compatibility, and memory‑leak issues early in the development cycle.
What is Monkey – Monkey is a command‑line utility provided by the Android SDK that generates a pseudo‑random stream of user events (touches, trackball motions, key presses, etc.) to stress‑test applications on emulators or real devices.
Location – The Monkey implementation consists of /system/framework/monkey.jar (Java code) and a shell script /system/bin/monkey that launches it.
Common parameters
-p <package_name> : specify the target app package.
-s <seed> : set the random‑number generator seed so that runs are repeatable.
--throttle <time> : fixed delay in milliseconds between events.
--pct-touch <percent> : percentage of touch (down‑up) events.
--pct-motion <percent> : percentage of motion events.
--pct-syskeys <percent> : percentage of system‑key events (HOME, BACK, etc.).
--pct-anyevent <percent> : percentage of all other event types.
-v (repeatable): increase log verbosity (Level 0‑2).
--ignore-crashes and --ignore-timeouts : continue execution after crashes or ANRs.
Full command example
adb -s device_id shell monkey -p com.wuba.zhuanzhuan -s monkey_time_stamp --ignore-crashes --ignore-timeouts --throttle 500 --pct-touch 70 --pct-motion 20 --pct-syskeys 10 -v -v -v 100 > file_path
From 0 to 1 – Practical setup
Handle permission dialogs and environment switches after installing a new app (using ADB or UIAutomator, or existing Appium UI cases).
Use a timestamp as the seed to vary event sequences across runs.
Collect performance data such as memory usage; establish a baseline after the first launch and capture heap snapshots (.hprof) when leaks are detected.
Reproduce issues by inspecting Monkey logs for the event sequence before a failure, then replaying the same seed or manually executing the actions.
Record the entire test session using adb shell screenrecord (max 180 s) or Appium/airtest recording methods that stitch multiple clips together for longer videos.
Monitor prohibited click areas by spawning a thread that checks the current activity (e.g., detecting when the app leaves the target package after a share intent).
After each run, archive the Monkey log, video, and any .hprof files; delete them if no issues were found.
Automatically classify failures by scanning the log for keywords such as CRASH , NOT RESPONDING , or ERROR .
Support parameterized execution to adjust event percentages for different apps and integrate with CI pipelines (Jenkins, test platforms).
Send summary emails containing logs, videos, and analysis files, using cloud storage links for large attachments.
Future plans
Automated analysis of .hprof files with full reports.
Integration with a test platform to select APKs and devices on demand.
Triggering tests via Jenkins jobs immediately after builds.
Embedding Monkey runs into the release pipeline for large‑scale stability testing.
Extending the approach to other Android apps and investigating iOS equivalents.
转转QA
In the era of knowledge sharing, discover 转转QA from a new perspective.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.