AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
翻譯準備中
AI 驅動的 Android 應用程式爬蟲,使用 Google Gemini 智能探索行動應用程式,透過視覺與結構分析,實現高效自動化測試、覆蓋率與應用程式發現
AI 翻譯
AI-powered Android app crawler using Google Gemini to intelligently explore mobile applications through visual and structural analysis, enabling efficient automated testing, coverage, and app discover
開發工具Python · JinjaGitHub @ganainy自行安裝營運者未確認
試用過了嗎? 點一下就好,不需要登入。
尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
安裝型專案無需部署網域也可驗證。個人儲存庫可透過 GitHub 登入驗證,組織儲存庫可使用上方的儲存庫驗證檔案。
使用 Google Gemini 的 AI 驅動 Android 應用程式爬蟲,透過視覺與結構分析智慧探索行動應用程式,實現高效的自動化測試、覆蓋率提升與應用程式發現。
AI 翻譯
AI-powered Android app crawler using Google Gemini to intelligently explore mobile applications through visual and structural analysis, enabling efficient automated testing, coverage, and app discovery.
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
Mobile Crawler is a developer tool for running AI-assisted exploration of Android apps. The application owns the UI, CLI, run/session persistence, settings, logs, and reporting infrastructure; the active exploration runtime is driven by the internalized crawler_agent package under src/mobile_crawler/domain/crawler_agent.
Mobile Crawler runs directly through the internalized agent runtime.檢視完整 README ↗Mobile Crawler is a developer tool for running AI-assisted exploration of Android apps. The application owns the UI, CLI, run/session persistence, settings, logs, and reporting infrastructure; the active exploration runtime is driven by the internalized crawler_agent package under src/mobile_crawler/domain/crawler_agent.
Mobile Crawler runs directly through the internalized agent runtime.
git clone <repository-url>
cd mobile-crawler
python -m venv .venv312
.\.venv312\Scripts\Activate.ps1
# Install Mobile Crawler and all its internalized crawler_agent dependencies
pip install -e .
For development tools:
pip install -e ".[dev]"
Run the GUI:
mobile-crawler-gui
When "Enable MobSF Analysis" is turned on in Settings, the GUI automatically starts the managed MobSF Docker container on launch (and warns if Docker or MobSF is unavailable). Otherwise it runs without MobSF.
When tracing is on with the phoenix provider and a localhost Phoenix URL, the GUI and CLI start the managed Phoenix container (arizephoenix/phoenix:version-20.3.0, traces kept in ~/.phoenix) the same way; there is no need to run phoenix serve. See "Tracing (Phoenix)" in docs/cli.md.
Run a crawl from the CLI:
mobile-crawler-cli crawl --device emulator-5554 --package com.example.app --provider gemini --model gemini-3.8-flash --steps 15
https://github.com/ganainy/ai-mobile-ui-crawler.docs/ARCHITECTURE.md.docs/ARCHITECTURE.md, active specs/* documents, and .codex/project-memory/CHANGELOG.md.AGENTS.md is currently absent from the workspace. If project-wide agent instructions are recreated, keep them concise and aligned with .codex/project-memory/CHANGELOG.md.pyproject.toml currently requires >=3.12,<3.13.CrawlerAgentService.Optional integrations:
boost. See docs/architecture/readmes/local-omniparser-setup.md for local setup notes.Mobile Crawler needs the target device or emulator to be visible through ADB before you start the GUI or CLI crawl.
Install Android SDK Platform Tools first if adb is not already available in PowerShell:
adb version
On the Android device:
For USB debugging:
adb devices
Accept the authorization prompt on the device. The device should appear as device, not unauthorized.
For wireless debugging on Android 11 or newer, keep the device and PC on the same network, open Wireless debugging on the device, and use the IP address and port shown there:
adb pair 172.20.10.4:<pairing-port>
adb connect 172.20.10.4:5555
adb devices
Use the connected device ID in crawl commands. For example:
mobile-crawler-cli crawl --device 172.20.10.4:5555 --package com.example.app --provider gemini --model gemini-3.8-flash --steps 15
For older Android versions or USB-first wireless setup, connect over USB once, then run:
adb tcpip 5555
adb shell ip addr show wlan0
adb connect 172.20.10.4:5555
adb devices
Replace 172.20.10.4 with the device IP address reported by Android or adb shell ip addr show wlan0.
The GUI entry point is the mobile-crawler-gui console script (mobile_crawler.ui.main_window:run). On launch it starts the managed MobSF Docker container when MobSF analysis is enabled. MainWindow builds the PySide6 interface, creates services and repositories, bridges Python logging into the log panel, creates run records, and launches crawl execution on a worker thread.
The UI exposes device selection, app selection, AI model/provider selection, crawl controls, settings, logs, run history, statistics, and AI monitoring. Settings are persisted through UserConfigStore and copied into a ConfigManager when a crawl starts.
The CLI entry point is mobile-crawler-cli (a console script installed into the venv by pip install -e .), which calls mobile_crawler.cli.main.run(). Commands: crawl, list, stats, report, mobsf-scan, delete, scenarios, a11y-portal, config.
Full reference with every command and flag: docs/cli.md.
mobile-crawler-cli crawl --device emulator-5554 --package com.example.app `
--provider gemini --model gemini-3.8-flash --steps 15
# Crawl several apps one after another, 10 minutes each; every app gets its own run
mobile-crawler-cli crawl --device emulator-5554 --package com.a.app --package com.b.app `
--provider gemini --model gemini-3.8-flash --duration 600 --no-human-fallback
Command-line settings apply to that invocation only; they are never saved to the settings store.
Mobile Crawler can run MobSF static APK analysis after a successful crawl or manually from the Run MobSF button in Run History. MobSF itself must be running separately; the app connects to its REST API, pulls the target APK from the selected device, uploads it, starts a static scan, and saves the JSON/PDF reports in the run session.
The analysis supports regular APKs and split APK installs. Split APKs are pulled from the device, packaged into a .apks archive, and uploaded to MobSF.
Artifacts are saved under the run folder:
output_data/
└── run_{ID}_{YYYYMMDD_HHMMSS}/
├── apks/
│ ├── com.example.app.apk
│ └── com.example.app.apks
└── reports/
└── mobsf/
├── {mobsf_hash}_report.json
└── {mobsf_hash}_report.pdf
Mobile Crawler can start PCAPdroid before Crawler begins crawling, request TLS decryption, stop capture during crawl cleanup, and save the resulting .pcap file in the run session.
Phone setup:
CLI users can pass --enable-traffic-capture. The PCAPdroid API key can come from persisted config or CRAWLER_PCAPDROID_API_KEY; without it, PCAPdroid may require on-device consent.
Capture results are saved under:
output_data/run_{ID}_{YYYYMMDD_HHMMSS}/pcap/
TLS decryption is best effort. QUIC, certificate pinning, apps that do not trust user CAs, and apps with custom encryption may still produce traffic that does not decrypt cleanly.
docker --version
docker info
If docker info fails, open Docker Desktop once and let it finish initializing. On some Windows systems, you may also need to enable WSL 2 and virtualization in BIOS/UEFI.
Pull the MobSF image:
docker pull opensecurity/mobile-security-framework-mobsf
Run MobSF manually on http://localhost:8000:
docker run --rm -it --name mobile-crawler-mobsf -p 8000:8000 opensecurity/mobile-security-framework-mobsf
Keep this PowerShell window open while using MobSF analysis. To stop MobSF, press Ctrl+C in that window.
Alternatively, run the GUI normally; when "Enable MobSF Analysis" is on, it starts the managed container automatically (with the expected container name), saves the API key to .mobsf_api_key when it can extract it from the container logs, and on close offers to stop the container it started.
MobSF requires an API key for REST calls. Mobile Crawler resolves the key automatically in this order:
.mobsf_api_key in the repository root or a parent directory.mobile-crawler-mobsf container.CRAWLER_MOBSF_API_KEY / mobsf_api_key sources for backward compatibility.To create the key file manually, copy the REST API key printed in the MobSF Docker logs and write it to .mobsf_api_key:
Set-Content -Path .mobsf_api_key -Value "<your_mobsf_api_key>"
The default MobSF URL is http://localhost:8000. Change the MobSF API URL in the GUI settings only if you run MobSF elsewhere.
Automatic after crawl:
mobile-crawler-cli crawl --device emulator-5554 --package com.example.app --provider gemini --model gemini-3.8-flash --enable-mobsf-analysis
In the GUI, enable MobSF analysis in Settings before starting a crawl. To run MobSF automatically after each successful, non-cancelled crawl, also enable the "Automatically run after each successful crawl" checkbox; otherwise MobSF stays available for manual runs only. If MobSF fails, the crawl remains completed and the failure is written to logs.
Manual from history:
Run MobSF.The manual button uses the run's stored device ID and package name, so the same device or emulator should still be available through ADB.
The current crawl flow is:
mobile-crawler-cli starts the CLI, or mobile-crawler-gui starts the GUI.crawl command or GUI MainWindow creates a run record, prepares ConfigManager, repositories, and SessionFolderManager, then runs CrawlerLoop.CrawlerLoop creates a timestamped session folder, stores the session path on the run, emits lifecycle events, attaches crawler-agent logging, and calls CrawlerAgentService.execute_exploration_task().CrawlerAgentService translates Mobile Crawler settings into the internal runtime's CrawlerConfig, ensures the target package is active through ADB preflight checks, creates a CrawlerAgent, and runs the crawler-agent workflow.CrawlerLoop updates final run stats and emits completion or error events.CrawlerLoop runs MobSF static analysis and logs the generated report paths.CrawlerLoop is intentionally thin. It manages Mobile Crawler run state, session folders, event forwarding, cancellation, logging, cleanup, and final stats; it does not own the exploration loop.
The agent runtime is fully internalized within the mobile_crawler package at src/mobile_crawler/domain/crawler_agent/.
Imports from the agent runtime resolve directly under the mobile_crawler.domain.crawler_agent namespace (e.g., from mobile_crawler.domain.crawler_agent import CrawlerConfig, CrawlerAgent, ToolExecutionEvent). The dynamic runtime injection that inserted the external path into sys.path has been completely removed.
Mobile Crawler does not own the agent runtime's core exploration loop. The internalized crawler_agent package owns screenshot and UI-state capture, LLM planning and execution, agent workflows, and ADB-backed device actions.
Mobile Crawler wraps the internalized crawler_agent with:
For a detailed explanation of the Manager/Executor decision loop, FastAgent mode, timing costs, and speed/quality tuning options, see docs/architecture/readmes/crawler-agent-decision-loop.md.
crawler_agent mainly uses Android Accessibility APIs, not pure screenshot vision first. Mobile Crawler passes parser settings into the agent through CrawlerAgentService, and the agent runtime owns active screenshot capture, UI parsing, formatted state text, indexed element lookup, and ADB-backed action execution during the crawl.
In the default boost mode, the agent uses the accessibility tree first and falls back to OmniParser only when accessibility metadata is unavailable or insufficient.
The ui_parser_mode setting controls which UI source the agent uses:
omniparser: always parse screenshots with OmniParser.boost (default): use accessibility data first, otherwise fall back to OmniParser.accessibility: use accessibility data only.When OmniParser is used, the agent converts OmniParser bounding boxes into indexed UI elements with tap-ready bounds before presenting them to the LLM agent. Local OmniParser parses use /parse/ by default, fall back to /parse only when needed, and honor omniparser_local_parse_timeout_seconds (120 seconds by default for slower CPU inference).
For the Replicate backend, the Settings panel includes a Warm Up Remote OmniParser button in the UI Parser section. It sends a mock screenshot to the same Replicate OmniParser model used by crawls, runs in the background, and reports completion or failure in the UI.
Mobile Crawler owns:
The internalized crawler_agent owns:
CrawlerAgent and active UI-agent execution.Default values live in src/mobile_crawler/config/defaults.py. Notable defaults include:
max_crawl_steps: 15max_crawl_duration_seconds: 600use_crawler_agent: Truecrawler_reasoning_mode: Truecrawler_streaming: Falsecrawler_telemetry_enabled: Falseui_parser_mode: boostomniparser_backend: replicateAPI keys can come from persisted secrets/settings or environment variables. CrawlerAgentService resolves provider keys and passes them into crawler-agent LLM profiles.
Telemetry key configuration:
CRAWLER_POSTHOG_PROJECT_API_KEY: PostHog project key used by crawler-agent telemetry.DROIDRUN_POSTHOG_PROJECT_API_KEY: legacy fallback key name retained for compatibility.DROIDRUN_TELEMETRY_ENABLED: telemetry on/off switch (true by default when key is present).SessionFolderManager creates per-run folders under the app data directory's output_data folder by default:
Every report of a run is in its reports/ folder; raw artifacts stay in their own folders:
output_data/
└── run_{ID}_{YYYYMMDD_HHMMSS}/
├── reports/
│ ├── run_report.html # Run Report, human-readable half
│ ├── analysis/ # Analysis Bundle: analysis.md, steps.jsonl, run.json
│ ├── mobsf/ # MobSF JSON/PDF
│ ├── config_snapshot.json
│ └── crawler_trace.jsonl
├── screenshots/
├── pcap/
├── videos/
└── apks/
The paths are defined in one place, domain/run_folder_layout.py. Older run folders (with analysis/, data/, logs/ and reports/report_run_<id>.html) are moved to this layout by scripts/migrate_run_folders.py (--dry-run to preview).
The session path is stored on the run record so the UI can resolve artifacts later.
CrawlerLoop methods emit debug messages for those controls and do not pause the agent workflow.use_crawler_agent setting remains in the UI/config, but the current CrawlerLoop implementation delegates traversal to the internalized crawler_agent.pytest
ruff check .
black .
pytest --cov=mobile_crawler --cov-report=html
Documentation-only README edits do not require code tests. For runtime changes, prefer targeted tests around the modified module and a smoke run through the CLI or GUI path.
Use .codex/project-memory/CHANGELOG.md as the compact project-state memory for future Codex sessions. Completed planning docs should not be recreated just for history; preserve implemented decisions in docs/ARCHITECTURE.md, active specs, this README, and the changelog.
Other README-style documents are grouped under docs/architecture/readmes/ so the root stays focused as the main project entry point.
MIT