OpenMobile: Open Mobile-Agent Framework

• OpenMobile is an open-source framework that generates training data for mobile agents by synthesizing diverse task instructions and recovery trajectories from real app interactions.
• It employs a global memory task-synthesis pipeline to aggregate screen functionalities and context, producing grounded multi-step instructions for improved task diversity.
• Its policy-switching approach, featuring error-intervention strategies, enhances agent recovery behavior and significantly boosts performance across dynamic mobile benchmarks.

Searching arXiv for papers on “OpenMobile” and closely related mobile-agent work to ground the article in the literature. OpenMobile is an open-source framework and dataset for training mobile agents through the synthesis of both task instructions and execution trajectories. It is designed to address a specific bottleneck in open mobile-agent research: the strongest systems have depended on closed training corpora and undisclosed synthesis procedures, whereas public datasets have been described as noisy and limited in coverage. OpenMobile therefore combines a scalable task-synthesis pipeline, built around a global memory of app functionality, with a policy-switching trajectory rollout strategy intended to capture error-recovery behavior that standard expert-only imitation learning often misses (Cheng et al., 16 Apr 2026).

1. Definition, motivation, and problem setting

OpenMobile is positioned as an architectural and data-generation response to the gap between closed and open mobile-agent systems. The paper identifies two missing ingredients for strong mobile agents: high-quality, diverse task instructions at scale, and training trajectories that include recovery from mistakes. Prior interaction-driven methods often generate each instruction from a single exploration trajectory, which tightly couples exploration and synthesis and biases instructions toward local behavior. Standard expert distillation, meanwhile, yields mostly ideal demonstrations even though deployed agents fail and must recover in dynamic environments (Cheng et al., 16 Apr 2026).

The framework is explicitly motivated by open-source reproducibility. Its stated purpose is to release data and code openly, make the synthesis process transparent, improve reproducibility, and provide a foundation for broader mobile-agent research. The paper also emphasizes that dynamic benchmarks are essential because static datasets cannot properly test error recovery. This places OpenMobile within the literature on mobile GUI agents, but with a stronger emphasis on openly released synthesis pipelines than on agent prompting alone (Cheng et al., 16 Apr 2026).

A plausible implication is that OpenMobile treats data construction, rather than only model architecture, as the central locus of capability. The paper’s overall thesis is that broad functionality coverage and recovery-oriented supervision are decisive for dynamic mobile control.

2. Global-memory task synthesis

The first major component of OpenMobile is a decoupled task-synthesis pipeline. Rather than generating an instruction from one local trajectory, the framework explores the app environment, organizes the results into a global environment memory, and then uses that memory to synthesize diverse, grounded tasks. The memory is defined as

$$\mathcal{M} = \big(\,\mathcal{S},\;\mathcal{N},\;\{\mathcal{F}(s_i)\}_{i=1}^{N}\,\big)$$

where $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$ is the set of unique screens, $\mathcal{N}(s_i)$ is the neighborhood of screen $s_i$, and $\mathcal{F}(s_i)$ is the set of functionality descriptions for that screen (Cheng et al., 16 Apr 2026).

The exploration stage is intentionally simple. OpenMobile is agnostic to exploration strategy, but the paper uses a random walk to show that the method does not depend on sophisticated exploration heuristics. Each session executes 10 steps; at each step it randomly selects an interactable element from the current screen’s accessibility tree, performs a click or type action, and uses a blacklist to avoid redundant interactions (Cheng et al., 16 Apr 2026).

Memory construction proceeds in several stages. First, screenshots are deduplicated by computing perceptual hashes and greedily clustering visually similar screens if pHash similarity exceeds $\tau = 0.95$, keeping one representative screen per cluster. Second, OpenMobile constructs neighborhoods by aggregating transitions across exploration traces. Third, a strong VLM, Gemini-3.1-Pro-Preview, extracts functionality descriptions for each unique screen using the preceding screen and the action that led to the current screen as context. Each element is categorized as either "functionality" or "data", and each description is emitted as a dictionary with fields "type", "label", and "description"; the description is required to include hierarchical location in the app and device-level behavior of the element (Cheng et al., 16 Apr 2026).

To support long-range composition, all functionality descriptions within an app are embedded using openai/text-embedding-3-large, and OpenMobile builds a per-app retrieval index for nearest-neighbor search. Retrieved functionalities are filtered so that pairwise cosine similarity is below 0.8 to keep them diverse. Task synthesis then combines three sources of context: the current screen, short-term memory consisting of the 1 predecessor screen and up to 3 successor screens, and long-term memory consisting of 30 semantically related functionalities from other screens in the same app. The synthesis context is written as

$$\mathcal{C}(s_i) = \big(s_i,\;\mathcal{M_S}(s_i),\;\mathcal{M_L}(s_i)\big)$$

and is fed to a VLM to produce grounded, multi-step instructions (Cheng et al., 16 Apr 2026).

The generated instructions are further filtered in three stages. Each instruction is scored from 1 to 5 on complexity, clarity, and reasonableness; instructions are discarded if clarity < 4 or reasonableness < 4. A second stage performs embedding-based deduplication with cosine similarity threshold 0.8, retaining the highest-rated instruction in each semantic cluster. A third stage caps instruction counts per app to keep training balanced (Cheng et al., 16 Apr 2026).

3. Policy-switching trajectory synthesis

The second major component of OpenMobile is trajectory synthesis via policy switching. Its stated rationale is that expert distillation gives clean demonstrations but omits recovery behavior, whereas self-evolution exposes the learner to failure states but is slow and limited by the learner’s current capability. OpenMobile therefore alternates between an expert policy $\pi_e$ and a learner policy $\pi_l$ (Cheng et al., 16 Apr 2026).

Given task instruction $I$, current observation $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$0, and history $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$1, the action is sampled as

$\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$2

where $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$3. This allows a trajectory to contain learner mistakes, expert interventions, and recovery segments (Cheng et al., 16 Apr 2026).

The paper compares four rollout strategies:

Strategy	Definition	Reported role
Expert distillation	Only the expert executes the task	Clean demonstrations
Self-evolution	Learner executes; expert judges success; only successful trajectories retained; repeated for 3 rounds	Recovery exposure, but slow and capacity-limited
Random switching	Learner may take over with fixed probability when expert and learner disagree; learner cannot execute terminal actions like “complete” or “answer”	Noisy in multi-solution tasks
Error-intervention switching	Learner begins; a monitor detects deviation; expert intervenes and corrects	Preferred strategy

The preferred strategy is error-intervention switching. The rollout starts with the learner, and a monitor $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$4 watches the learner’s execution. If the monitor detects deviation from productive progress, it triggers expert intervention. Appendix details state that the monitor is also Gemini-3.1-Pro-Preview, that it observes recent action history and the last two screenshots, that it can trigger expert intervention at most twice, and that after each intervention the expert performs at least 3 steps before control returns to the learner (Cheng et al., 16 Apr 2026).

A central implementation detail is that, during supervised training, OpenMobile keeps only expert steps from policy-switching trajectories but preserves the full interaction history, including learner errors, as context. This means the model imitates corrected expert actions while still conditioning on error-prone histories (Cheng et al., 16 Apr 2026).

4. Dataset, training configuration, and evaluation setting

The resulting OpenMobile dataset contains about 2.8K instructions and 34K action steps across 20 Android apps. The reported averages are 12.2 steps per trajectory and 129 words of chain-of-thought reasoning per step. The data is generated using the Android emulator infrastructure from AndroidWorld, but benchmark test instructions are not used during synthesis (Cheng et al., 16 Apr 2026).

For rollout, the learner $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$5 is an early-stage fine-tuned checkpoint, the expert $\mathcal{S} = \{s_1, s_2, \ldots, s_N\}$6 is Gemini-3.1-Pro-Preview, and the action space and response format are adapted to Qwen3-VL. The expert also rewrites each step’s chain-of-thought reasoning for higher-quality supervision. OpenMobile fine-tunes Qwen2.5-VL-7B and Qwen3-VL-8B using LLaMA-Factory with standard supervised fine-tuning, batch size 32, learning rate 1e-5, and 3 epochs (Cheng et al., 16 Apr 2026).

The paper also reports reinforcement-learning experiments. It tries step-level RL using GRPO with format/action-type/grounding rewards, and trajectory-level agentic RL via OS-Themis. RL does not clearly outperform SFT on dynamic benchmarks; the paper attributes this to mismatch between step-level rewards and long-horizon execution, limited diversity of the current setup, and RL stability issues (Cheng et al., 16 Apr 2026).

OpenMobile is evaluated on three dynamic mobile-agent benchmarks:

Benchmark	Tasks	Apps
AndroidWorld	116	20
AndroidLab	138	9
MobileWorld	201	20

AndroidWorld is described as a reproducible Android emulator environment with parameterized task templates and random seeds; AndroidLab as reproducible virtual devices supporting language-only and multimodal agents; and MobileWorld as more difficult, with long-horizon and cross-app workflows, evaluated on the GUI-only subset (Cheng et al., 16 Apr 2026).

5. Reported results and empirical analyses

The main reported results indicate that OpenMobile-trained models substantially improve open-data mobile-agent performance on dynamic benchmarks. On AndroidWorld Pass@1, Qwen2.5-VL-7B + OpenMobile reaches 51.7 ± 1.7, and Qwen3-VL-8B + OpenMobile reaches 64.7 ± 3.2. On AndroidLab Pass@1, the reported scores are 22.7 ± 0.4 for the 7B model and 51.5 ± 0.7 for the 8B model. On MobileWorld Pass@1, the reported scores are 14.8 ± 1.3 and 17.7 ± 2.2, respectively (Cheng et al., 16 Apr 2026).

The paper also reports scaling to Qwen2.5-VL-72B-Instruct, where the AndroidWorld score rises from a 27.6 baseline to 59.3 ± 0.9 after training with OpenMobile data. This suggests that the synthesized data scales with stronger base models (Cheng et al., 16 Apr 2026).

Ablation studies are central to the paper’s argument. For task synthesis, OpenMobile is compared against OS-Genesis and a coupled pipeline using the same prompt but a single trajectory context. Human evaluation over 50 paired comparisons reports complexity win/tie/loss of 0.68 / 0.22 / 0.10 versus OS-Genesis and 0.26 / 0.62 / 0.12 versus the coupled pipeline, while soundness remains comparable. With 1.5K trajectories, downstream AndroidWorld success is 34.1 ± 1.7 for OS-Genesis, 45.3 ± 2.2 for the coupled pipeline, and 48.3 ± 1.3 for OpenMobile (Cheng et al., 16 Apr 2026).

For rollout, the paper compares expert distillation, self-evolution, random switch, and error-intervention switch. Average error-recovery instances per trajectory are reported as 0.42, 0.10, 0.64, and 1.56, respectively. The corresponding AndroidWorld Pass@1 scores are 44.8 ± 1.7, 33.8 ± 0.9, 45.1 ± 0.9, and 48.3 ± 1.3. This is presented as evidence that monitor-based switching yields the richest recovery signal and the best performance (Cheng et al., 16 Apr 2026).

The paper also addresses benchmark-overfitting concerns directly. Overlap is measured by pairwise cosine similarities between synthetic instructions and AndroidWorld test instructions using openai/text-embedding-3-large. Only 3.5% of OpenMobile instructions exceed similarity 0.7. A removal study reports that removing a small fraction, such as 10%, causes only a marginal performance drop, whereas removing too much, such as 40%, hurts performance substantially more than random removal. The paper interprets this as evidence that the gains come from broad functionality coverage rather than from a few near-duplicate test-like instructions (Cheng et al., 16 Apr 2026).

A further analysis decomposes test tasks into atomic functionalities and reports that coverage increases steadily with instruction count, that OpenMobile consistently covers more functionality than the coupled pipeline, that tasks with more atomic functionalities are harder, and that tasks with higher functionality coverage get better success rates. This suggests that OpenMobile’s main effect is to expand the functional span of the training distribution (Cheng et al., 16 Apr 2026).

6. Disambiguation and relation to adjacent mobile research

The term OpenMobile is not unique in the arXiv literature. An earlier paper titled "An Interface between Legacy and Modern Mobile Devices for Digital Identity" uses OpenMobile to denote a lightweight bridge between legacy feature phones and modern QR-based digital identity systems. In that work, a feature phone with a WAP microbrowser fetches and displays a standard QR code that a nearby verifier scans; the system is intended for contexts such as identity/status verification and food subsidy distribution, and it has been released under open source licensing (Mavroudis et al., 2021). This is a distinct system from the 2026 mobile-agent framework.

OpenMobile also sits within a rapidly developing line of mobile-agent research. "MobileAgent: enhancing mobile control via human-machine interaction and SOP integration" introduces an LLM-based mobile-control method that combines human-machine interaction for privacy and personalization with SOP information in the prompt, reporting an overall action success rate of 66.92% on AitW (Ding, 2024). "AppAgent v2: Advanced Agent for Flexible Mobile Interactions" introduces a two-phase multimodal agent with exploration, deployment, a flexible action space, and a customized structured knowledge base accessed through RAG during deployment; it reports 77.8% on DroidTask and 93.3% with manual exploration on the AppAgent benchmark (Li et al., 2024). Relative to these systems, OpenMobile is distinguished by its emphasis on open data synthesis, global environment memory for task generation, and policy-switched rollout for recovery-oriented supervision (Cheng et al., 16 Apr 2026).

This suggests that the name now designates two substantially different open mobile systems: a legacy-device identity bridge in the digital identity literature and a task-and-trajectory synthesis framework in the mobile-agent literature. In current mobile-agent usage, however, OpenMobile most directly refers to the latter.