TesterZone Testing Never Dies

Practical self-developed tools

Android App Testing Tools

Explore self-developed and practical Android app testing tools for QA engineers, covering performance, automation, stability, memory, network, and screenshot evidence.

9 tools
Performance 路 EXE
Real-time performance collection for focused mobile app testing
Performance Monitoring Tool
Multi-metric Sampling ADB/HDC Data Paths xls Export
Multi-metric Sampling Continuously samples selected metrics including CPU, FPS frame timing, memory, traffic, battery, temperature, total resources, and current page.
ADB/HDC Data Paths Checks adb devices and hdc list targets before startup and selects the available collection implementation.
xls Export Exports headered xls files after sampling stops for test records.
Overview

The Performance Monitoring Tool collects runtime data through ADB/HDC system commands. It supports CPU, FPS frame timing, memory, network traffic, battery level, temperature, total memory, total CPU, and current foreground page metrics. Testers enter a package name to start continuous sampling and can export the results as an xls file. The tool is designed for focused observation on a connected or specified device, with results derived from system shell output; it does not implement automated diagnosis or server-side reporting.

Environment
Platform
Windows desktop; test targets include Android devices connected through ADB and HarmonyOS/OpenHarmony-style devices connected through HDC.
Access Path
Users enter the app package name and optional device serial in a PyQt5 GUI. The tool auto-detects adb devices or hdc list targets before sampling.
Package
performance.exe 路 50.5 MB
  • package.py explicitly supports the performance packaging entry, mapped to performanceGui.py.
  • performanceGui.py exposes CPU, FPS, memory, network, battery, temperature, total memory, and total CPU options.
  • The ADB path uses dumpsys battery, dumpsys meminfo, dumpsys gfxinfo, top, /proc/net/dev, and dumpsys activity.
  • Observe app CPU, memory, frame timing, and network changes during manual or focused testing.
  • Compare performance changes before and after a page or operation while recording the current Activity.
  • Inspect app traffic, app network speed, and total network speed under Wi-Fi or cellular scenarios.
  • Users enter the app package name and optional device serial in a PyQt5 GUI. The tool auto-detects adb devices or hdc list targets before sampling.
  • The PC side requires Python/PyQt5, tablib, and a usable adb or hdc command-line tool.
  • The device must allow debugging connections and ADB/HDC shell commands.
  • App-level metrics require the package name to match a running process.
+Metrics can be selected on demand, avoiding unrelated data collection in each test.
+A single entry point can automatically choose ADB or HDC data paths for Android and HarmonyOS/OpenHarmony-style devices.
+The sampling table marks foreground pages outside the target package, helping identify app-switching during tests.
Automation 路 APK
Record, organize, and run reusable UI test scripts directly on Android devices
DiandianTong
Local Recording and Script Composition Hybrid Targeting and Validation Local Reports and Asset Packaging
Local Recording and Script Composition Use floating recording windows on real devices to pick nodes, configure actions, and save scripts, then combine them into tasks with pre-flow, main-flow, and auto-trigger logic.
Hybrid Targeting and Validation A single execution flow can combine accessibility XPath, image template matching, and OCR text recognition, while validating element state, toast text, wait results, and search results at the step level.
Local Reports and Asset Packaging After task execution, you can review task results, script-step status, running logs, and screenshots; scripts and tasks can be packaged with associated image assets as ZIP files and accessed or converted through local HTTP endpoints.
Overview

DiandianTong is a local UI automation testing tool that runs directly on Android devices. It uses AccessibilityService to read the current window and UI tree, MediaProjection to capture screen images, and OpenCV image matching together with ML Kit / Paddle OCR for targeting and interaction. The code explicitly implements actions such as click, double click, long press, swipe, scroll, input, search, wait, condition checks, validations, toast verification, OCR-triggered clicks, foreach traversal, app launch/restart, and screen capture. After execution, it stores task results, script and step status, running logs, and optional screenshots in local storage and a local database. It also supports packaging scripts or tasks together with associated image assets into ZIP files for import, export, and sharing. For failure detection, the code clearly shows expectation-based step and task evaluation, such as missing elements, state mismatches, wait timeouts, search failures, toast mismatches, or step execution failures; the code does not clearly show dedicated target-app crash, ANR, performance, or network analysis.

Environment
Platform
A native Android app for automating the UI of installed Android apps.
Access Path
It is primarily accessed through the in-app UI, floating recording windows, and Android accessibility service; it also includes a local HTTP service on port 8399 with static pages and `/api` endpoints.
Package
script_v1.6.8.apk 路 74.7 MB
  • This is an Android APK project with package name `com.test4399.script` and app name `DiandianTong`.
  • The code is configured with `minSdk=23`, `targetSdk=35`, and native libraries for `armeabi-v7a` and `arm64-v8a`.
  • Its core execution stack explicitly depends on AccessibilityService, MediaProjection, Room, local file storage, OpenCV, ML Kit OCR, and Paddle OCR.
  • Record and replay repetitive Android UI flows on real devices, such as login, navigation, form entry, and settings changes.
  • Automate screens with unstable resource IDs or hard-to-target UI structures by combining XPath, image template matching, and OCR.
  • Run expectation-based smoke or regression checks such as element presence, element state, toast text, wait results, and search results.
  • It is primarily accessed through the in-app UI, floating recording windows, and Android accessibility service; it also includes a local HTTP service on port 8399 with static pages and `/api` endpoints.
  • Required: Accessibility service, used to read the UI tree, receive events, and perform clicks, swipes, input, and similar actions.
  • Required: Overlay permission, used for the recorder window, node picker, and running-status windows.
  • Required: MediaProjection screen-capture authorization, used for OCR, image matching, step screenshots, and explicit screen-capture actions.
+Its execution flow runs entirely on the Android device, centered on accessibility, screen capture, Room storage, and local files rather than an external test server.
+Its targeting approach is hybrid, combining accessibility-tree XPath with OpenCV-based image template matching and ML Kit / Paddle OCR text recognition.
+It includes recording, editing, task orchestration, scheduled execution, ZIP import/export, and local API capabilities, making it better suited to maintaining reusable Android automation assets than serving as a general cross-platform testing platform.
Stability 路 APK
Real-time anomaly monitoring for Android apps, mini-games, and hybrid flows. Capture crashes, ANRs, and JS errors faster with clearer log-based triage.
Anomaly Monitoring
Automatic Anomaly Detection Page-Level Context Reports Ready After Testing
Automatic Anomaly Detection Detect crashes, ANRs, JNI issues, Java exceptions, and JS runtime anomalies without manually combing through logs.
Page-Level Context Link anomalies to the tested app, launched packages, and page context for more direct triage.
Reports Ready After Testing Turn a test session into a report with anomaly export and full-log export for easier handoff and debugging.
Overview

Anomaly Monitoring is a device-side Android testing tool built for smoke, regression, and exploratory workflows. It captures logcat in real time through local ADB, automatically links logs to the app under test and related launched packages, and detects crashes, ANRs, JNI issues, Java exceptions, and H5/JS anomalies during the session. With page-level context, report generation, and log export built in, it helps testers move from raw logs to actionable findings with less manual effort.

Environment
Platform
Android-only in the current implementation, running as a standalone tool app on the test device.
Access Path
Works through local ADB connectivity, and the code explicitly prompts users to enable adb tcpip 5555.
Package
crash_monitor_1.1.8.apk 路 6.7 MB
  • Android tool app form factor, foreground service, overlay, and accessibility service
  • Local ADB connectivity and explicit dependency on adb tcpip 5555
  • Real-time capture of logcat -v uid -v epoch
  • Smoke and regression testing for Android apps, with less manual log inspection during issue triage.
  • Hybrid app and H5 validation, where both native and JS-side anomalies matter.
  • Mini-game, container-based, or plugin-driven flows with cross-package launches and multi-module paths.
  • Works through local ADB connectivity, and the code explicitly prompts users to enable adb tcpip 5555.
  • Relies on logcat as the core log source
  • Requires overlay permission
  • Requires accessibility service for page context capture
+Captures and detects anomalies in real time during testing instead of relying on post-run log hunting.
+Covers multiple implemented anomaly classes, including crashes, ANRs, JNI issues, Java exceptions, and H5/JS anomalies.
+Follows packages and pages launched by the app under test instead of staying limited to one package.
Memory 路 APK
Bring Android memory observation, suspicious Activity leak signals, and HPROF evidence into one device-side testing flow.
Android Memory Monitor
Real-time ADB Sampling Debug-Build HPROF Evidence Local Reports and Evidence Export
Real-time ADB Sampling Periodically runs dumpsys meminfo and dumpsys activity activities through ADB shell to refresh PSS, Private Dirty, Activities in memory, and Activities in the stack.
Debug-Build HPROF Evidence For debuggable targets, the tool can trigger GC, capture an HPROF file, and analyze destroyed Activities plus removed or detached Fragments with custom Shark and LeakCanary leak filters.
Local Reports and Evidence Export Test sessions, per-sample leak details, and HPROF paths are stored locally, and the report detail screen supports browsing, sharing, or exporting HPROF files.
Overview

This tool is aimed at Android testers. After a user selects an installed app on the device, it continuously collects process-memory and Activity information through ADB shell commands such as pidof, ps, dumpsys meminfo, and dumpsys activity activities, then shows live PSS, Private Dirty, Activity-in-memory, and Activity-in-stack values in a floating window. Once recording starts, the tool writes a session summary and per-sample details into a local database. If the target app is debuggable, the tool can also trigger GC before the session ends, run am dumpheap -g to capture an HPROF file, and use Shark plus LeakCanary to analyze destroyed Activities and removed or detached Fragments in the heap. Outputs include a local report list, per-sample leak details, shareable or exportable HPROF files, and the tool's own log files. The code does not show cloud sync, automated fixes, or cross-platform support, so this is better suited to Android-focused manual testing, regression checks, and reproduction work than to a general APM platform.

Environment
Platform
A standalone APK for Android devices, used to monitor a target Android app installed on the same device.
Access Path
After installing and launching the tool on a device, the user selects one installed target app. The tool uses a local ADB connection, defaulting to localhost:5555, and displays live metrics through a floating foreground service.
Package
memory_check_v1.1.8.apk 路 7.2 MB
  • The project is an Android app, with build configuration explicitly set to minSdkVersion 21 and targetSdkVersion 35.
  • The main workflow requires selecting one installed target app and uses a floating foreground service to show live metrics.
  • The code directly invokes dumpsys meminfo, dumpsys activity activities, pidof or ps, run-as kill -10, and am dumpheap -g.
  • Watch PSS, Private Dirty, and Activity count changes for an Android app during manual regression testing to catch sustained memory growth early.
  • Investigate repeated page navigation, Activity transitions, or back-stack flows by comparing the number of Activities in memory with the number found in the Activity stack.
  • Capture an HPROF file at the end of a test session on a debuggable build and use Shark plus LeakCanary to provide heap-analysis evidence for Activity or Fragment leaks.
  • After installing and launching the tool on a device, the user selects one installed target app. The tool uses a local ADB connection, defaulting to localhost:5555, and displays live metrics through a floating foreground service.
  • The tool requires permissions for overlay windows, all-files access, notifications, and battery-optimization exemption, and the manifest also declares foreground service, external storage, phone state, and system alert related permissions.
  • The device must have ADB debugging enabled and must allow the tool to establish an ADB connection to localhost:5555.
  • Automatic HPROF capture and analysis depend on the target app being debuggable. Non-debuggable builds still record memory metrics and Activity count differences.
+Combines live memory sampling, Activity-difference detection, debuggable-build HPROF capture, and local report management in one on-device workflow.
+Uses ADB shell commands such as dumpsys meminfo, dumpsys activity activities, pidof or ps, and am dumpheap, making the results easy to map back to system-level signals.
+Shows the target app name, PSS, Private Dirty, and Activity counters in a floating foreground-service window, which fits exploratory and hands-on testing.
Network 路 APK
Clear, direct single-session traffic measurement for Android manual testing.
NetTest
App and device dual-view measurement Floating overlay session control Local report retention
App and device dual-view measurement The same session can calculate target-app traffic as well as device-wide upload, download, Wi-Fi, and mobile usage.
Floating overlay session control Once the test starts, the app moves to the background and the user controls start/stop from an overlay while viewing a live speed text indicator.
Local report retention Each test generates a local report stored in SQLite, and the report list keeps the latest 20 records for on-device review.
Overview

This tool uses Android's NetworkStatsManager to measure both target-app and device-wide traffic within a test session, with a floating overlay used to start and stop collection. After the session ends, it creates a local report containing timestamps, app information, selected metrics, and measured values. It fits real-device functional checks, regression passes, and abnormal-traffic reproduction scenarios. The current implementation is centered on manual measurement and local review rather than automated platform-style management.

Environment
Platform
A native Android application operated through an in-app UI and a floating overlay window.
Access Path
After installation, the user selects a target app, chooses metrics, and manually starts and stops a traffic test from a floating overlay.
Package
nettest_v1.1.0.apk 路 6.5 MB
  • The code explicitly implements installed-app selection, metric selection, floating-overlay start/stop control, report detail, and report list screens.
  • The code explicitly calculates app-level and device-level total, upload, download, Wi-Fi, mobile, and average traffic metrics.
  • Reports are explicitly written to the local SQLite database test.db in the report table, and the list reads the latest 20 records.
  • Manually validate total, upload, download, Wi-Fi, and mobile-data usage for an installed app during a specific user flow on a real device.
  • Compare target-app traffic with device-wide traffic to see whether the tested flow is primarily driven by the selected app.
  • Record average throughput and total consumption for a single test run during functional or regression testing to help spot abnormal spikes.
  • After installation, the user selects a target app, chooses metrics, and manually starts and stops a traffic test from a floating overlay.
  • Requires Android Usage Access permission (PACKAGE_USAGE_STATS) to read app network usage data.
  • Requires overlay permission (SYSTEM_ALERT_WINDOW) to show the floating test controller.
  • The code requests battery-optimization exemption to reduce the chance of the background flow being interrupted.
+Designed around single test sessions: select an app, start and stop the test, and tie the result directly to timestamps and the app package name.
+Captures both app-level and device-level statistics, helping separate target-app traffic from overall device traffic.
+Stores results as local SQLite reports and provides in-app browsing for the latest 20 records.
Screenshot 路 RAR
Connect an Android device, capture millisecond-stamped screenshots, calculate start-to-end timing, and automatically aggregate results into CSV.
ScreenshotNg
Run-Isolated Capture Timeline Visual Key-Frame Timing CSV Summary Save Session
Run-Isolated Capture Timeline Each run creates an isolated folder by device serial and run timestamp, with a default 80 ms continuous capture interval and a required interval above 40 ms when continuous capture is enabled.
Visual Key-Frame Timing Supports image selection, previous/next navigation, thumbnail preview, enlarged viewing, and elapsed-time calculation from millisecond timestamps in start/end image filenames.
CSV Summary Save Session A save session controlled by Start Saving Data and Stop Saving appends multiple timing results to one timestamp-named CSV file.
Overview

ScreenshotNg is a Windows desktop testing utility built around a customized scrcpy and adb workflow. It reads Android SDK configuration, scans connected devices, saves screenshots under a local screenshot directory by device serial and run timestamp, and calculates elapsed time from millisecond timestamps in image filenames. The code explicitly implements continuous capture, extra point-shot capture, a lower-bound check for continuous capture intervals, run duration and end-buffer settings, automatic device refresh, image folder selection, bad-image filtering, thumbnail preview, enlarged browsing, keyboard navigation, timing display, CSV save sessions, and Windows app-image packaging. CSV files are stored under screenshot/summary, named with the time when data saving starts, and written with a UTF-8 BOM for easier Excel opening. Its data sources are local adb/scrcpy output, local screenshot files, and user-selected start/end images; the code does not explicitly implement automated business anomaly detection, cloud access, multi-user collaboration, or cross-platform desktop runtime support.

Environment
Platform
Windows desktop environment; the target device is an Android device reachable through adb.
Access Path
Primarily launched as a Windows GUI executable, with a Java command-line entry point that accepts a device serial and capture interval.
Package
ScreenshotNg.rar 路 56.2 MB
  • The code explicitly implements a Swing GUI, Java command-line entry point, adb devices listing, and device serial selection.
  • The code explicitly implements capture interval, extra point-shot count, extra point-shot interval, startup preparation, run duration, and end-buffer parameters; the GUI default continuous capture interval is 80 ms, and enabled continuous capture requires an interval above 40 ms.
  • The code explicitly writes screenshots to screenshot/<device-serial>/<run-timestamp>/ under the application root and prefers screenshot/<device-serial>/<run-timestamp>/continual/ for continuous captures.
  • Capture a traceable screenshot timeline from an Android workflow at a fixed millisecond interval, stored in an isolated folder for each run.
  • Select a start frame and an end frame from a screenshot sequence to calculate timing for transitions, animations, or operation completion.
  • Persist multiple timing measurements during one test session into a timestamp-named CSV summary file.
  • Primarily launched as a Windows GUI executable, with a Java command-line entry point that accepts a device serial and capture interval.
  • The Android device must have USB debugging enabled and be authorized for adb.
  • Accessible adb is required; the application first tries the adb bundled with scrcpy-win64 and also checks the Android SDK path.
  • A valid Android SDK path is required; the application reads ANROID_SDK_ROOT, ANDROID_SDK_ROOT, or ANDROID_HOME.
+It has a clear scope: Android screenshot evidence capture, key-frame selection, elapsed-time calculation, and local CSV recording, rather than a generic testing platform.
+Each run creates an isolated timestamped folder, with continuous screenshots stored under its continual subdirectory for easier run-level traceability.
+Screenshot filenames use millisecond timestamps as the timing source, and image selection avoids zero-byte files, non-timestamp filenames, and unreadable default key-frame candidates.
Performance 路 EXE
Android app battery consumption sampling powered by batterystats
Battery Consumption Test Tool
batterystats Attribution Context Metrics Session Total
batterystats Attribution Parses total usage and CPU, Wi-Fi, sensor, and related categories by UID through dumpsys batterystats.
Context Metrics Displays battery level, temperature, CPU usage, and Activity together to connect power changes with test actions.
Session Total Tracks the difference between initial and final consumption and exports -battery.xls files.
Overview

The Battery Consumption Test Tool is built for Android app power testing workflows. After startup, it resets batterystats and reads the consumption attribution data for the app UID by package name, while also collecting battery level, temperature, CPU usage, and current Activity. The UI displays total consumption and CPU, Wi-Fi, sensor, and other categories, calculates the session total after stopping, and supports xls export. The tool depends on Android batterystats output, does not implement HDC/HarmonyOS collection, and does not provide automated test orchestration.

Environment
Platform
Windows desktop; test targets are Android devices connected through ADB.
Access Path
Users enter the app package name in a PyQt5 GUI to start sampling; the device serial is obtained automatically from adb devices.
Package
battery.exe 路 50.5 MB
  • package.py explicitly supports the battery packaging entry, mapped to batteryGui.py.
  • batteryGui.py displays total consumption, CPU consumption, Wi-Fi consumption, sensor consumption, other consumption, CPU usage, battery level, temperature, and Activity.
  • The Worker calls resetBattery at startup, which runs dumpsys batterystats --reset.
  • Observe battery consumption during a specific app workflow and record changes in total and categorized usage.
  • Inspect the breakdown of CPU, Wi-Fi, sensor, and other power consumption for an app.
  • Record battery level, temperature, CPU usage, and current Activity together to help locate high-consumption scenarios.
  • Users enter the app package name in a PyQt5 GUI to start sampling; the device serial is obtained automatically from adb devices.
  • The PC side requires Python/PyQt5, tablib, and a usable adb command-line tool.
  • The device must enable USB debugging or ADB over network and allow shell commands such as dumpsys, top, and ps.
  • Sampling starts by running dumpsys batterystats --reset.
+Uses Android batterystats as the core data source and reads system-side power attribution results directly.
+Uses a fixed table covering total power, categorized power, battery level, temperature, CPU usage, and current page.
+Calculates total consumption for the session after stopping and exports the test record.
Performance 路 RAR
Identify mobile page GPU overdraw risk in real time
GPU Overdraw Test Tool
Overdraw Percentage Live Frame and Activity Threshold Snapshots
Overdraw Percentage Calls a DLL on local screenshots to calculate color ratio and display overdraw as a percentage.
Live Frame and Activity Captures the current device frame and records foreground Activity, with optional package-based filtering.
Threshold Snapshots Automatically copies screenshots to the overdraw directory when the configured threshold is reached.
Overview

The GPU Overdraw Test Tool builds a device screen-capture path through ADB or HDC, saves the current frame locally, and calls the bundled DLL to calculate the ratio of specific color regions as the GPU overdraw percentage. The UI supports 0.5s/1s refresh, threshold configuration, optional package filtering, live image preview, and Activity recording; when the percentage reaches the threshold, the tool saves a screenshot to the overdraw directory. It depends on the device-side GPU overdraw developer option, is not a low-level GPU profiler, and does not implement root-cause performance diagnosis.

Environment
Platform
Windows desktop; test targets include Android devices connected through ADB and HarmonyOS/OpenHarmony-style devices connected through HDC.
Access Path
Started from a PyQt5 GUI; users can set refresh frequency, overdraw threshold, and optionally provide a target app package name.
Package
GpuTool.rar 路 83.0 MB
  • package.py explicitly supports the gpu packaging entry, mapped to GPUGui.py.
  • GPUGui.py requires developer mode and the GPU overdraw display option.
  • GPUGui.py supports 0.5s and 1s refresh intervals, an overdraw threshold, optional package filtering, and live image display.
  • Observe overdraw percentage during page walkthroughs to find screens with higher rendering load.
  • Monitor foreground pages for a specified package at 0.5s or 1s refresh intervals.
  • Set an overdraw threshold and automatically save screenshots that meet or exceed it to the overdraw directory.
  • Started from a PyQt5 GUI; users can set refresh frequency, overdraw threshold, and optionally provide a target app package name.
  • The PC side requires Python/PyQt5, adb or hdc, bundled scrcpy/harmonyscrcpy resources, and the image-analysis DLLs under lib/dll.
  • Android devices must allow ADB debugging, file push, port forwarding, and starting the app_process scrcpy service.
  • HDC devices must allow hdc file send, fport, uitest start-daemon, and related shell commands.
+Uses live screenshots and color-ratio analysis to present overdraw percentage, directly tied to the device developer-option overdraw visualization.
+Supports both Android ADB/scrcpy and HDC/harmonyscrcpy capture paths.
+Screenshots above the threshold are retained automatically for later review of the exact page state.
Stability 路 APK
Launch Android Monkey tests on-device, capture crash and ANR evidence, and review recent reports directly.
Silly Monkey
Parameterized launches for installed apps Wireless ADB session guardrails On-device exception report handling
Parameterized launches for installed apps It enumerates installed apps on the current device and, after a single target package is selected, lets the tester configure event ratios, random seed, fixed delay, and count-based or duration-based execution.
Wireless ADB session guardrails Wireless mode uses a localhost:5555 ADB socket, executes Monkey in batches, keeps checking the foreground window, and tries to navigate back to or relaunch the target app when needed.
On-device exception report handling After a test run, it parses crash and ANR signals from logcat, builds a detail view, and supports sharing or exporting exception text.
Overview

Silly Monkey is focused on single-device, single-app Android Monkey stability testing. Testers can choose an installed app on the device, set the mix of touch, motion, trackball, app-switch, system-key, and other events, configure a fixed delay and random seed, and run by event count or by duration. In wireless mode, the app sends `monkey` and `logcat` commands through a local ADB socket and generates crash/ANR logs plus a session summary when the run finishes. In the current codebase, reporting is centered on AndroidRuntime crashes, ActivityManager ANRs, and parameterized session records rather than broader performance analysis, packet capture, or multi-device orchestration.

Environment
Platform
An Android app intended for Monkey stability testing of apps installed on the same Android device.
Access Path
The tester selects an installed app in the UI and configures event ratios, fixed delay, random seed, and either count-based or time-based execution. Wireless mode runs shell monkey and logcat through a local localhost:5555 ADB socket; the code also keeps a USB-debug workflow entry point.
Package
shahou_v1.4.7.apk 路 5.9 MB
  • The project is an Android app with a splash screen, test screen, report screen, help screen, and a foreground service.
  • It can select one installed app and build a `monkey -p <pkg>` command with event ratios, fixed delay, random seed, and count-based or duration-based control.
  • Wireless mode opens a local TCP ADB connection to `localhost:5555`, and the UI explicitly instructs the user to run `adb tcpip 5555` first.
  • Run configurable Monkey stability smoke tests against a single installed Android app.
  • Execute random-event regression runs over wireless ADB by total event count or total duration while trying to bring testing back to the target app.
  • Collect AndroidRuntime crash and ActivityManager ANR evidence on-device and review recent session summaries and details.
  • The tester selects an installed app in the UI and configures event ratios, fixed delay, random seed, and either count-based or time-based execution. Wireless mode runs shell monkey and logcat through a local localhost:5555 ADB socket; the code also keeps a USB-debug workflow entry point.
  • On first launch, it requests all-files access, overlay, notification, and battery-optimization exemption permissions, and it uses a foreground service during testing.
  • Wireless mode depends on ADB debugging being enabled on the device and, as prompted in the UI, an initial `adb tcpip 5555` authorization step from a PC.
  • The target must be an installed and launchable app on the current device; packages without usable activities do not enter a valid test flow.
+Wireless Monkey execution is issued in batches of 100 events, reducing the risk of a long uncontrolled background run.
+A background service monitors the current foreground window and, if Monkey navigates away from the target app, tries to send Back and relaunch the target.
+Reports record device model, OS version, run mode, event parameters, crash/ANR counts, and log paths, while keeping the latest 10 summary entries.
No tools match your search. Try a different keyword or category.