Pith. sign in

REVIEW 4 major objections 7 minor 48 references

FuncDroid tests mobile apps by modeling flows between features, and finds 107% more bugs than prior tools.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-02 23:39 UTC pith:U2FX3OPH

load-bearing objection Promising inter-functional flow model for Android GUI testing, but headline bug counts lean on an unvalidated MLLM oracle and best-of-three reporting; worth refereeing, not yet convincing. the 4 major comments →

arxiv 2602.12834 v2 pith:U2FX3OPH submitted 2026-02-13 cs.SE

FuncDroid: Towards Inter-Functional Flows for Comprehensive Mobile App GUI Testing

Jinlong He , Changwei Xia , Binru Huang , Jiwei Yan , Jun Yan , Jian Zhang This is my paper
classification cs.SE
keywords Android GUI testingfunctional flow graphinter-functional flowsLLM-based testingnon-crash functional bugsmetamorphic testingstate condition refinementmobile app testing
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that mobile GUI testing fails to find deep bugs because it tests functionalities in isolation, missing bugs that arise from interactions between features. To fix this, it introduces a Functional Flow Graph (FFG) that represents each meaningful user-facing functionality as a node and each inter-functional flow as an edge annotated with the state condition that enables it. On top of this graph, FuncDroid runs an iterative loop: a long-term view generates tests that refine the graph's functional boundaries and flow conditions, while a short-term view generates metamorphic variations that probe the state subspaces defined by each flow. The paper reports that this approach outperforms five state-of-the-art baselines on a 50-crash-bug benchmark, achieving 28% higher activity coverage and 107% more bugs detected, and discovers 18 previously unknown non-crash functional bugs in 52 commercial apps.

Core claim

The central claim is that explicitly modeling inter-functional flows—not just individual functionalities—substantially improves deep bug detection in mobile apps. FuncDroid treats a 'meaningful functionality' as a triple of goal, state variables, and execution traces, and a flow between functionalities as a relation annotated with a state precondition phi. By iteratively refining these preconditions through completeness and independence validation, and by exploring state subspaces with single-flow and cross-flow metamorphic relations, the tool covers interaction paths that single-functionality testers miss. The reported experiments show that this flow-aware testing yields 62 bugs on the open

What carries the argument

The Functional Flow Graph (FFG) is the structural backbone: nodes are meaningful functionalities (goal, vars, traces), edges are flows annotated with a triple (pi, phi, pi') meaning that after executing trace pi of the source functionality, if the condition phi holds in the app state, then trace pi' of the target functionality becomes executable. The testing loop is driven by two complementary views: the Long-Term View refines the FFG by challenging completeness and independence of functionalities and by applying condition partition, minimal-violation, and invariant strategies to sharpen flow preconditions; the Short-Term View applies metamorphic relations—widget-level variations like hide/s

Load-bearing premise

The whole pipeline assumes that the multimodal language model's semantic goal inference and similarity threshold correctly partition GUI pages into meaningful functionalities, and that the state conditions it identifies from screenshots and traces are accurate representations of the app's actual state; if these semantic inferences are noisy, the FFG becomes a restyled trace summarizer and the claimed advantage over single-functionality testers evaporates.

What would settle it

Run FuncDroid and the best baseline (VisionDroid with MemoDroid) on a fresh set of 50 open-source app versions with known inter-functional bugs, but replace the MLLM backend with a weaker one or with randomly generated page-goal embeddings. If bug detection drops to baseline levels while the FFG's flow count remains similar, that would show the gains come from the specific semantic model rather than from the flow-based exploration structure. Alternatively, instrument an app to log the true state variables (e.g., alarm_list, BMI value) and compare them against the phi conditions FuncDroid infer

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • If the FFG model is accurate, the same inter-functional-flow framework could be extended beyond Android to iOS and HarmonyOS apps, where similar cross-feature interaction bugs exist.
  • The flow conditions phi provide a structured partition of the app state space, which could be reused for regression testing: after an app update, only flows whose conditions changed need re-testing.
  • The metamorphic relations for cross-flow data dependencies suggest a general template for generating inter-feature test cases in any GUI-driven system, not just mobile apps.
  • The paper's non-crash bug detection oracle, combining MLLM reasoning with a knowledge base of bug patterns, could be made more precise by formalizing condition updates as executable state invariants.
  • The +107% bug detection gain, if reproducible, indicates that existing LLM-based testers are leaving a large class of interaction bugs on the table, motivating a shift in how functionality-oriented testing is evaluated.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A natural extension the authors leave implicit is that the FFG could be used to generate user-level documentation or a feature-interaction map, since it already labels each node with a semantic goal and each edge with a state condition.
  • The approach's reliance on a multimodal LLM for goal inference and condition extraction suggests a testable hypothesis: performance should degrade gracefully as the underlying model's visual or semantic reasoning weakens, which could be probed by swapping the backend model.
  • The cross-flow metamorphic relations essentially implement a form of inter-procedural dataflow testing at the GUI level; adapting these relations to web applications or desktop software may reveal whether the FFG concept generalizes beyond mobile.
  • One could test whether the FFG's flow conditions correspond to actual executable state predicates by instrumenting the app to dump its internal state at flow boundaries; if the conditions do not match, the model is a symbolic overlay rather than a behavioral model.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper proposes FuncDroid, an Android GUI testing approach built around a Functional Flow Graph (FFG) that models meaningful functionalities and the inter-functional flows between them. The approach iterates between long-term-view test generation to refine functionality boundaries and flow conditions, short-term-view metamorphic testing to explore single-flow and cross-flow variations, and FFG updating based on execution traces. The evaluation on the Themis benchmark (50 app versions) reports higher activity coverage and more detected bugs (62 total: 49 crash + 13 non-crash) than five baselines, with the best baseline finding 30. An ablation study attributes the gains to both LTV and STV components. A practicality study on 52 commercial apps reports 18 previously unknown non-crash functional bugs, with 2 fixed and 2 confirmed by developers.

Significance. If the reported results hold, the paper makes a notable contribution: it is among the first to explicitly model inter-functional interactions for mobile GUI testing, and the reported bug counts (+107% total bugs over the best baseline) are substantial. The FFG abstraction and the iterative refinement loop are interesting and well-motivated by the two motivating bugs. The artifact is promised to be public. The evaluation is broad (two benchmarks, five baselines). However, the central empirical claim depends heavily on the credibility of the non-crash bug oracle and on the consistency of the reported numbers; as written, those weaknesses prevent full confidence in the headline gain.

major comments (4)
  1. [§3.2.2(3), §4.2, §4.4] The MLLM-based non-crash bug oracle is the linchpin of the headline results, but no precision or false-positive evaluation is given. The 13 non-crash bugs in Themis are asserted without independent confirmation, and of the 18 commercial non-crash bugs only 4 are developer-validated (2 fixed, 2 confirmed); 11 are 'waiting' and 3 'unreportable'. Because the oracle infers expected behavior from an MLLM knowledge base, an unmeasured false-positive rate would directly deflate the +107% total-bug advantage and the '18 previously unknown bugs' claim. I ask for: (a) a manual/independent review of all non-crash reports by at least one expert labeler (ideally a developer or a second author not involved in the oracle design), with agreement; (b) false-positive analysis on a labeled set of benign traces; and (c) disclosure of the prompts and knowledge-base entries used for the non-crash oracle, so t
  2. [Table 1 vs. §4.2] There is an internal inconsistency that obscures the baseline results: Figure 7 and Table 1 report #Bug_crash for VD+MD as 25, but the text says 'exceeding 24 (96%) crash bugs found by the best baseline (VD+MD)'. Also Figure 7's overlap counts are not reconcilable from the paper. The reported total of 30 for VD+MD equals 25 crash + 5 non-crash, so the '24' in the text appears to be an error. Please correct the prose and ensure all counts in Table 1, Figure 7, and the prose are consistent.
  3. [§4.1, Table 1] The evaluation reports 'best of three' runs without variance or per-run distributions. Because the core claim (+107%) is a difference in bug counts, it is important to know whether the 62 vs 30 result is stable across runs or an artifact of a single best run. I request the per-run counts (or at least mean±min/max) for total bugs and coverage for the six configurations, and an appropriate statistical test (e.g., Wilcoxon or bootstrap) across apps or runs. Without this, the claimed significance in the abstract is not supported.
  4. [§3.2.1, §3.2.2, §3.2.3] The FFG construction and the LTV flow-condition refinement operations depend on several implicit semantic judgments that are not evaluated: the page-goal similarity threshold, the trace-goal clustering threshold for independence validation, and the MLLM's ability to identify correct state conditions φ (including the DNF representation and entailment checks in §3.2.3 such as 'φ |= φ_cur'). The paper states that the FFG becomes 'precise' and 'accurate', but no end-to-end assessment of FFG quality is provided beyond the downstream bug counts. Since the central claim is that inter-functional flows drive the improvement, I ask for a small-scale human oracles evaluation of (a) whether the inferred page goals are correct, (b) whether the functionality partitions match a human annotator's notion of meaningful functionality, and (c) whether the flow conditions φ are judged correct with respect to
minor comments (7)
  1. [Abstract vs. §4.2] The abstract says '+107% bug detection number', which the text of §4.2 states as 'at least 107% increase' (30 to 62). This is arithmetically not 107%: 62/30 = 2.07, i.e., +107% relative to the best baseline. The phrasing is acceptable but should be clarified as a relative increase over the best baseline, and not over a single baseline.
  2. [Table 3] The table lists 18 bugs, but the 'Status' column shows 2 fixed, 2 confirmed, 3 unreportable, and 11 waiting. For reproducibility and credibility, please add a column with the issue tracker/feedback channel the authors used (where applicable) and, for the 'waiting' entries, a date or a 'no response by [date]' annotation. Also note that the video playlist link is not accessible in the text (only footnote); include a stable link.
  3. [Figure 7] The simplified UpSet plot is difficult to interpret because the overlap counts are not labeled with the sets explicitly. Consider a conventional UpSet plot with a main bar chart and set membership matrix, or a table of overlap sizes, so the claim that 'only FuncDroid uncovered all bugs' and '21 bugs uniquely detected by it' can be verified.
  4. [§4.1] The filtering of Themis from 72 to 50 versions is reported, but not the list of excluded apps/versions or the reasons. Since this affects the denominator and the comparability with prior Themis-based evaluations, please include the filtered list in the artifact or appendix.
  5. [§3.2.2(1)] The Completeness Validation Strategy states that it infers 'potential widget actions that are semantically essential ... but are absent'. This requires a definition of what counts as a semantically essential action and how it is inferred. Please provide a concrete algorithm or an MLLM prompt template in the appendix.
  6. [§3.2.3] The flow condition update logic relies on logical entailment (φ |= φ_cur). Since φ is extracted by an MLLM into DNF, please clarify whether entailment is computed symbolically (and how) or by LLM judgment. This is not merely presentation: the correctness of the 'weakening/strengthening/merging' operations depends on it.
  7. [§4.2] Figure 9's bug-count curves appear to be cumulative, but the y-axis label says 'Number of detected bugs' and the values reach ~60. The figure caption should state that these are cumulative over the test budget.

Circularity Check

0 steps flagged

No significant circularity: FuncDroid's central claims rest on external benchmark comparisons, not on self-referential derivations.

full rationale

I walked the paper's claimed derivation chain: the FFG is defined in §3.1 as a directed graph over semantically inferred functionalities, initialized from a collected trace via MLLM goal embeddings (§3.2.1), refined by LTV/STV test scenarios (§3.2.2), and updated by trace/condition analysis (§3.2.3). The paper's headline results — +28% activity coverage, +107% total bug detections, and 18 previously unknown non-crash bugs — are empirical outcomes measured against the Themis benchmark and 52 commercial apps, not quantities derived from the FFG's definition. No equation or construction equates a predicted result with an input parameter: the semantic-similarity threshold is a heuristic, not fitted to the bug counts; the flows are hypotheses tested by execution; and the bug-detection oracle is explicitly borrowed from prior independent work ([24], VisionDroid) rather than from FuncDroid's own model. The authors do cite their own prior work ([17], [18]) in the related-work enumeration of model-based testing methods, but those citations are not load-bearing for FuncDroid's central claim. The main validity concern is the MLLM-based non-crash oracle: the paper itself discloses in Table 3 that only 2 of 18 commercial bugs are fixed and 2 confirmed, with 11 still waiting and 3 unreportable, and no false-positive precision of the oracle is reported. This is an important evaluation/confirmation gap and a potential confound, since the same MLLM family used for exploration also labels expected behavior; however, it is not circularity in the derivation sense — the bug counts are not constructed from the FFG's own outputs, and the FFG's behavioral model does not presuppose the oracle's labels. The derivation chain is therefore self-contained with respect to its empirical benchmarks, and the appropriate circularity score is 0.

Axiom & Free-Parameter Ledger

3 free parameters · 6 axioms · 1 invented entities

The central claims rest on several unverified semantic-inference assumptions about the MLLM, on similarity thresholds that are never quantified, and on an unvalidated non-crash bug oracle. The FFG itself is an invented abstraction whose value is the paper's main empirical hypothesis rather than an established result.

free parameters (3)
  • Semantic similarity threshold for functionality partitioning
    In §3.2.1, pages are merged into a functionality when goal-embedding similarity exceeds 'a predefined threshold'; no value or sensitivity analysis is given. All FFG boundaries, flows, and downstream results depend on it.
  • Trace-goal clustering threshold for independence validation
    In §3.2.2 LTV Independence Validation, trace-level goals are clustered to split functionalities; the clustering algorithm and similarity cutoffs are unspecified.
  • Best-of-three run selection = best run
    §4.1 reports 'execute each tool three times and report the best performance'; this removes variance information and inflates point estimates. It is a protocol choice rather than a fitted value, but it materially affects reported numbers.
axioms (6)
  • domain assumption GPT-4o (or another MLLM) can reliably infer page goals, trace goals, state variables, and flow conditions from screenshots and widget hierarchies.
    Used throughout §3.2.1-§3.2.3; no accuracy measurement or error analysis is reported.
  • domain assumption Semantic-embedding similarity is a valid proxy for functional identity.
    FFG initialization and updating merge/split functionalities based on embedding similarity thresholds.
  • domain assumption The non-crash bug oracle inherited from VisionDroid [24] has acceptable precision.
    Non-crash findings are declared bugs by MLLM pattern matching; only 4 of 18 commercial bugs have developer confirmation/fix.
  • domain assumption Metamorphic transformations (Hide/Show, Change, Toggle, Create/Delete, etc.) adequately sample the state subspace relevant to each flow condition.
    STV relies on these MRs to expose deep bugs; no formal or empirical justification of their coverage is given.
  • domain assumption Themis benchmark app versions and 52 commercial apps are representative.
    Filtering from 72 to 50 Themis versions and app inclusion criteria (§4.1) may select for apps amenable to the tool.
  • domain assumption Android emulator executions reflect real device behavior.
    All experiments run on emulators; no real-device validation is reported.
invented entities (1)
  • Functional Flow Graph (FFG) no independent evidence
    purpose: A directed graph whose nodes are 'meaningful functionalities' and whose edges are inter-functional flows annotated with (pi, phi, pi') conditions; used to partition app state space and guide test generation.
    It is the paper's central modeling construct. Its utility is only demonstrated through the authors' own experiments; no external validation or formal semantics are provided.

pith-pipeline@v1.3.0-alltime-deepseek · 18066 in / 11231 out tokens · 97576 ms · 2026-08-02T23:39:57.753561+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of FuncDroid: Towards Inter-Functional Flows for Comprehensive Mobile App GUI Testing." pith.science (2026). https://pith.science/paper/U2FX3OPH

@misc{pith2026260212834,
  author       = {Pith},
  title        = {Pith review of: FuncDroid: Towards Inter-Functional Flows for Comprehensive Mobile App GUI Testing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/U2FX3OPH}},
  note         = {Machine review of arXiv:2602.12834}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

As mobile application (app) functionalities grow increasingly complex and their iterations accelerate, ensuring high reliability presents significant challenges. While functionality-oriented GUI testing has attracted growing research attention, existing approaches largely overlook interactions across functionalities, making them ineffective at uncovering deep bugs hidden in inter-functional behaviors. To fill this gap, we first design a Functional Flow Graph (FFG), a behavioral model that explicitly captures an app's functional units and their inter-functional interactions. Based on the FFG, we further introduce an inter-functional-flow-oriented GUI testing approach with the dual goals of precise model construction and deep bug detection. This approach is realized through a long-short-term-view-guided testing process. By combining two complementary test-generation views, it can adaptively refine functional boundaries and systematically explore inter-functional flows under diverse triggering conditions. We implement our approach in a tool called FuncDroid, and evaluate it on two benchmarks: (1) a widely-used open-source benchmark with 50 reproducible crash bugs and (2) a diverse set of 52 popular commercial apps. Experimental results demonstrate that FuncDroid significantly outperforms state-of-the-art baselines in both coverage (+28%) and bug detection number (+107%). Moreover, FuncDroid successfully uncovers 18 previously unknown non-crash functional bugs in commercial apps, confirming its practical effectiveness.

Figures

Figures reproduced from arXiv: 2602.12834 by Binru Huang, Changwei Xia, Jian Zhang, Jinlong He, Jiwei Yan, Jun Yan.

Figure 1
Figure 1. Figure 1: Two Functional Bugs in the Motivating App [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of FuncDroid (1) Long-Short-Term View Exploration (Section 3.2.2). It is composed of three coordinated phases: (a) Long-Term View (LTV) test Scenario Generation generates tests that target refining the FFG model; (b) Short-Term View (STV) Test Scenario Generation generates tests aimed at intensive exploration of current flow hypotheses; and (c) Scenario-driven Bug Detection performs both test exec… view at source ↗
Figure 3
Figure 3. Figure 3: FFG Initialization of the Blood Pressure App. , Vol. 1, No. 1, Article . Publication date: February 2018 [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Example of LTV Test Scenario for Refining Functionality Definitions. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Example of LTV Test Scenario for Refining Flow Conditions. [PITH_FULL_IMAGE:figures/full_fig_p010_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Example of STV Test Scenario for Cross-Flow Metamorphic Relations. [PITH_FULL_IMAGE:figures/full_fig_p011_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Detected Bug Overlap across Different Tool Combi [PITH_FULL_IMAGE:figures/full_fig_p015_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Performance of Coverage and Bug Detection Ability with Varying Time. [PITH_FULL_IMAGE:figures/full_fig_p015_9.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

48 extracted references · 5 linked inside Pith

  1. [1]

    2026. Claude. https://claude.com/

    2026

  2. [2]

    DeepSeek

    2026. DeepSeek. https://www.deepseek.com/

    2026

  3. [3]

    2026. F-Droid. https://f-droid.org/

    2026

  4. [4]

    Google Play

    2026. Google Play. https://play.google.com/

    2026

  5. [5]

    2026. GPT-4o. https://openai.com/index/gpt-4o/

    2026

  6. [6]

    HUAWEI AppGallery

    2026. HUAWEI AppGallery. https://consumer.huawei.com/en/mobileservices/appgallery/

    2026

  7. [7]

    2026. Llama. https://github.com/meta-llama/llama3

    2026

  8. [8]

    2026. Qwen. https://qwen.ai/home

    2026

  9. [9]

    Michael Auer, Andreas Stahlbauer, and Gordon Fraser. 2023. Android Fuzzing: Balancing User-Inputs and Intents. In 2023 IEEE Conference on Software Testing, Verification and Validation (ICST). 37–48

    2023

  10. [10]

    Tanzirul Azim and Iulian Neamtiu. 2013. Targeted and depth-first exploration for systematic testing of android apps (OOPSLA ’13). 641–660

    2013

  11. [11]

    Tianqin Cai, Zhao Zhang, and Ping Yang. 2020. Fastbot: A Multi-Agent Model-Based Test Generation System. In2020 IEEE/ACM 15th International Conference on Automation of Software Test (AST). 93–96

    2020

  12. [12]

    Mengzhuo Chen, Zhe Liu, Chunyang Chen, Junjie Wang, Yangguang Xue, Boyu Wu, Yuekai Huang, and Qing Wu, Libinand Wang. 2025. Beyond Static GUI Agent: Evolving LLM-based GUI Testing via Dynamic Memory(ASE 2025). Accepted for publication

    2025

  13. [13]

    Android Developers. 2012. UI/application exerciser monkey

    2012

  14. [14]

    Zhen Dong, Marcel Böhme, Lucia Cojocaru, and Abhik Roychoudhury. 2020. Time-travel testing of Android apps. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering (ICSE ’20). 481–492

    2020

  15. [15]

    Jordan Doyle, Takfarinas Saber, Paolo Arcaini, and Anthony Ventresque. 2021. Improving Mobile User Interface Testing with Model Driven Monkey Search. In2021 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW). 138–145

    2021

  16. [16]

    Tianxiao Gu, Chengnian Sun, Xiaoxing Ma, Chun Cao, Chang Xu, Yuan Yao, Qirun Zhang, Jian Lu, and Zhendong Su

  17. [17]

    Jinlong He, Binru Huang, Changwei Xia, Hengqin Yang, Jiwei Yan, and Jun Yan. 2026. HACMony: Automatically Detecting Hopping-related Audiostream Conflict Issues on HarmonyOS.Frontiers of Computer Science(2026). Accepted for publication

    2026

  18. [18]

    Jinlong He, Zhilin Wu, and Taolue Chen. 2025. Formalization of Android Activity-Fragment Multitasking Mechanism and Static Analysis of Mobile Apps. 37, 2, Article 17 (April 2025), 86 pages

    2025

  19. [19]

    Gennaro Imparato. 2015. A Combined Technique of GUI Ripping and Input Perturbation Testing for Android Apps. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Vol. 2. 760–762

    2015

  20. [20]

    Yuanhong Lan, Yifei Lu, Zhong Li, Minxue Pan, Wenhua Yang, Tian Zhang, and Xuandong Li. 2024. Deeply Reinforcing Android GUI Testing with Deep Reinforcement Learning. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE). 1–13

    2024

  21. [21]

    Yuanchun Li, Ziyue Yang, Yao Guo, and Xiangqun Chen. 2017. DroidBot: a lightweight UI-Guided test input generator for android. In2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C). 23–26

    2017

  22. [22]

    Yuanchun Li, Ziyue Yang, Yao Guo, and Xiangqun Chen. 2019. Humanoid: A Deep Learning-Based Approach to Automated Black-box Android App Testing. In2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). 1070–1073

    2019

  23. [23]

    Zhe Liu, Chunyang Chen, Junjie Wang, Mengzhuo Chen, Boyu Wu, Xing Che, Dandan Wang, and Qing Wang

  24. [24]

    Zhe Liu, Cheng Li, Chunyang Chen, Junjie Wang, Mengzhuo Chen, Boyu Wu, Yawen Wang, Jun Hu, and Qing Wang

  25. [25]

    Ke Mao, Mark Harman, and Yue Jia. 2016. Sapienz: multi-objective automated testing for Android applications. In Proceedings of the 25th International Symposium on Software Testing and Analysis. 94–105

    2016

  26. [26]

    Nariman Mirzaei, Joshua Garcia, Hamid Bagheri, Alireza Sadeghi, and Sam Malek. 2016. Reducing combinatorics in GUI testing of android applications. InProceedings of the 38th International Conference on Software Engineering. 559–570

    2016

  27. [27]

    Minxue Pan, An Huang, Guoxin Wang, Tian Zhang, and Xuandong Li. 2020. Reinforcement learning based curiosity- driven testing of Android applications. InProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis. 153–164

    2020

  28. [28]

    Yunpeng Song, Yiheng Bian, Yongtao Tang, Guiyu Ma, and Zhongmin Cai. 2024. VisionTasker: Mobile Task Automation Using Vision Based UI Understanding and LLM Task Planning. InProceedings of the 37th Annual ACM Symposium on User Interface Software and Technology. ACM, 1–17

    2024

  29. [29]

    Ting Su, Guozhu Meng, Yuting Chen, Ke Wu, Weiming Yang, Yao Yao, Geguang Pu, Yang Liu, and Zhendong Su

  30. [30]

    Ting Su, Jue Wang, and Zhendong Su. 2021. Benchmarking automated GUI testing for Android against real-world bugs. InProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2021). 119–130

    2021

  31. [31]

    Ting Su, Yichen Yan, Jue Wang, Jingling Sun, Yiheng Xiong, Geguang Pu, Ke Wang, and Zhendong Su. 2021. Fully automated functional fuzzing of Android apps for detecting non-crashing logic bugs.Proc. ACM Program. Lang.5, OOPSLA, Article 156 (Oct. 2021), 31 pages

    2021

  32. [32]

    Tuyet Vuong and Shingo Takada. 2019. Semantic analysis for deep Q-network in android GUI testing. InProceedings - SEKE 2019. 123–128

    2019

  33. [33]

    Chenxu Wang, Tianming Liu, Yanjie Zhao, Minghui Yang, and Haoyu Wang. 2025. LLMDroid: Enhancing Automated Mobile App GUI Testing Coverage with Large Language Model Guidance.Proceedings of the ACM on Software Engineering2, FSE (2025), 1001–1022

    2025

  34. [34]

    Jue Wang, Yanyan Jiang, Ting Su, Shaohua Li, Chang Xu, Jian Lu, and Zhendong Su. 2022. Detecting non-crashing functional bugs in Android apps via deep-state differential analysis. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2022). Association for Computing ...

    2022

  35. [35]

    Jue Wang, Yanyan Jiang, Chang Xu, Chun Cao, Xiaoxing Ma, and Jian Lu. 2020. ComboDroid: Generating High-Quality Test Inputs for Android Apps via Use Case Combinations. In2020 IEEE/ACM 42nd International Conference on Software Engineering (ICSE). 469–480

    2020

  36. [36]

    Junyang Wang, Haiyang Xu, Jiabo Ye, Ming Yan, Weizhou Shen, Ji Zhang, Fei Huang, and Jitao Sang. 2024. Mobile-Agent: Autonomous Multi-Modal Mobile Device Agent with Visual Perception. arXiv:2401.16158

    Pith/arXiv arXiv 2024

  37. [37]

    Hao Wen, Yuanchun Li, Guohong Liu, Shanhui Zhao, Tao Yu, Toby Jia-Jun Li, Shiqi Jiang, Yunhao Liu, Yaqin Zhang, and Yunxin Liu. 2024. AutoDroid: LLM-powered Task Automation in Android. arXiv:2308.15272

    Pith/arXiv arXiv 2024

  38. [38]

    Hao Wen, Hongming Wang, Jiaxuan Liu, and Yuanchun Li. 2024. DroidBot-GPT: GPT-powered UI Automation for Android. arXiv:2304.07061

    Pith/arXiv arXiv 2024

  39. [39]

    Yiheng Xiong, Ting Su, Jue Wang, Jingling Sun, Geguang Pu, and Zhendong Su. 2024. General and Practical Property- based Testing for Android Apps. In2024 39th IEEE/ACM International Conference on Automated Software Engineering (ASE). 53–64

    2024

  40. [40]

    Shengqian Yang, Hailong Zhang, Haowei Wu, Yan Wang, Dacong Yan, and Atanas Rountev. 2015. Static Window Transition Graphs for Android (T). In2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE). 658–668

    2015

  41. [41]

    Prasad, and Tao Xie

    Wei Yang, Mukul R. Prasad, and Tao Xie. 2013. A grey-box approach for automated GUI-model generation of mobile applications. Springer-Verlag, 250–265

    2013

  42. [42]

    Hui Ye, Shaoyin Cheng, Lanbo Zhang, and Fan Jiang. 2013. DroidFuzzer: Fuzzing the Android Apps with Intent-Filter Tag(MoMM ’13). 68–74

    2013

  43. [43]

    Chi Zhang, Zhao Yang, Jiaxuan Liu, Yucheng Han, Xin Chen, Zebiao Huang, Bin Fu, and Gang Yu. 2023. AppAgent: Multimodal Agents as Smartphone Users. arXiv:2312.13771

    Pith/arXiv arXiv 2023

  44. [44]

    Jiayi Zhang, Chuang Zhao, Yihan Zhao, Zhaoyang Yu, Ming He, and Jianping Fan. 2024. MobileExperts: A Dynamic Tool-Enabled Agent Team in Mobile Devices. arXiv:2407.03913 Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009 , Vol. 1, No. 1, Article . Publication date: February 2018

    Pith/arXiv arXiv 2024

  45. [2017]

    InProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering

    Guided, stochastic model-based GUI testing of Android apps. InProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering. 245–256

    2017

  46. [2019]

    In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)

    Practical GUI Testing of Android Applications Via Model Abstraction and Refinement. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). 269–280

  47. [2023]

    Make LLM a Testing Expert: Bringing Human-Like Interaction to Mobile GUI Testing via Functionality-Aware Decisions.2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE)(2023), 1222–1234

    2024

  48. [2025]

    Seeing is Believing: Vision-driven Non-crash Functional Bug Detection for Mobile Apps.IEEE Transactions on Software Engineering(2025), 1–14. , Vol. 1, No. 1, Article . Publication date: February 2018. 20 Trovato et al

    2025