iQIYI One‑Click Android App Health Check: Architecture, Implementation and Key Technologies

Background: Android app automated testing involves many specialties such as functional, stability and performance testing. Traditional stability testing (Monkey) suffers from low coverage and low efficiency, performance testing is limited to fixed scenarios, and compatibility testing still relies heavily on manual effort across many device models.

Problem: Fast‑iteration teams face high maintenance costs for functional automation scripts, and limited resources make it difficult to achieve ideal ROI even with configuration‑based or AI‑assisted approaches.

Solution Overview: iQIYI’s testing team proposes a lightweight, simple and universal “one‑click app health check” that, with a single app URL, performs multi‑dimensional inspection covering APP security verification, UI anomaly detection, performance data analysis, and Crash/ANR detection.

System Architecture: The solution consists of four modules – mobile cloud backend service, scene service, worker service, and analysis‑monitoring service. After leasing real devices from a pool, the worker receives tasks, installs the target app, executes traversal, captures logs, screenshots, videos, and uploads structured data to a log‑service platform.

Driver Kernel: The core traversal engine is built on the open‑source ATX framework. Instead of installing a dedicated driver app on each device, actions are sent to the device via HTTP, eliminating the need for per‑device driver installation. ATX‑agent (a Go ARM binary) receives HTTP commands, while uiautomator2 provides UI interaction capabilities. Minicap and Minitouch are used for real‑time screen capture and touch events.

Device Resource Pool: An Open‑STF based device farm of ~100 Android devices is maintained. Devices are leased, mounted to workers, and can be expanded automatically when demand rises. USB connections are removed; devices are accessed wirelessly via adb‑connect after ATX‑agent is started.

Universal Installation via OCR: Installation dialogs differ across manufacturers (e.g., Vivo, OPPO). The system captures screenshots, sends them to an OCR service, matches keywords such as “Install”, “Next”, “Confirm”, and clicks the corresponding coordinates. For devices that block screenshots during password entry, a fallback uses predefined key events (Tab/Enter) after device type detection.

App Launch Time Measurement: Installation time is recorded, and app launch is captured via screen recording. A backend video‑analysis service extracts frame‑by‑frame RGB change rates to generate waveforms, identifying start (st) and end (ed) points to calculate launch latency. MediaRecorder is integrated for devices that do not support adb‑shell screenrecord (e.g., Huawei).

UI Anomaly Detection: Leveraging a previously published deep‑learning model, the system captures screenshots every 1‑3 seconds during traversal, runs anomaly detection, and reports UI issues within the health‑check time window.

Security Verification: Two static analysis engines are employed – a smali‑based rule matcher for obvious API misuse and a FlowDroid‑based taint analysis for deeper data‑leak and permission‑leak detection. Detailed vulnerability reports include code locations and data‑flow paths.

Event‑Driven Traversal: Traversal events are divided into basic random events (click, long‑press, swipe) and scenario‑specific events (combo clicks, directed swipes, text input). The system parses the UI hierarchy XML, selects target coordinates, and executes actions while respecting activity whitelist constraints to avoid out‑of‑scope navigation.

Custom Scenario Support: Users can define pre‑execution scripts for login, specific business flows, or mini‑program entry points. After the universal installation phase, these scripts run automatically before the main traversal.

Bug Reporting: During traversal, logcat is continuously monitored. When Crash or ANR keywords appear, the system captures recent screenshots, overlays interaction trajectories, and bundles logs, mapping files, and the problematic APK into a bug report. Duplicate bugs are filtered by comparing signatures against existing records.

Log Analysis Service: The health‑check runs on ~15 devices for ~30 minutes per task, generating massive amounts of performance, image, and log data. The backend pipeline ingests raw data, stores it in structured form, performs calculations (e.g., performance metrics, crash statistics), and exposes APIs for front‑end dashboards.

Outcome: The one‑click health check is already used internally for many iQIYI apps, enabling early detection of issues, reducing manual effort, and integrating smoothly with CI pipelines. Future work includes expanding coverage metrics, adding more specialized indicators, and diversifying traversal scenarios.