Pith. sign in

REVIEW 5 major objections 6 minor 52 references

GAPS: Targeted Execution of Android Apps via Static Path Reconstruction

T0 review · 5 major / 6 minor · reviewed 2026-08-03 · deepseek-v4-flash

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

Pith's one-line read Static backward call-graph traversal can steer an Android app to execute a target method, and GAPS reaches 57.44% of targets where prior GUI testers stayed under 18%.

desk verdict GAPS is a genuinely useful hybrid for method-level Android reachability, but the head-to-head numbers are not apples-to-apples and the abstract/body mismatch needs fixing before the quantitative claims can be trusted. read the letter →

arxiv 2511.23213 v3 pith:OIFZ5UTM submitted 2025-11-28 cs.SE

Samuele Doria , Alexander Pilgun , Jordan Samhi , Jacques Klein , Eleonora Losiouk This is my paper · ORCID
classification cs.SE
keywords targetedexecutionAndroidapptestingstaticpathreconstructionbackwardcallgraphtraversaldata-flowanalysisGUI-guideddynamicmethodreachabilitysecurity
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that targeted method-level execution in Android apps—long stuck because GUI testers explore breadth-first and whole-program call graphs are expensive—becomes practical if you reverse the direction of analysis. Instead of building a full call graph, GAPS starts from the target method and walks backward through callers, enriching the partial graph with data-flow facts about conditions, inter-component intents, and GUI element bindings. Those facts are compiled into concrete interaction plans—send a broadcast, click these buttons—that the dynamic phase executes, with an LLM-driven fallback when the UI is unpredictable. On 56 AndroTest apps this reaches 57.44% of randomly selected targets at runtime, versus 9.69–17.12% for existing GUI testers; on the 50 most-downloaded Play Store apps it still reaches about 55–60% within a five-minute budget. The claim matters because vulnerability and malware analyses routinely identify methods that are believed to be runnable but that no dynamic tool can actually be forced to execute.

What carries the argument

The central mechanism is a context-sensitive backward traversal that builds a partial call graph slice ending at the target method, using Androguard's method and basic-block representation for smali-level inspection and networkx for path enumeration. Points-to analysis and constant propagation resolve conditional statements by linking guard operands to the constant assignments—including assignments made through broadcast receivers—that make the condition true; ICC mapping resolves intent senders and receivers into entry points; and GUI event retrieval maps listener registrations back to resource IDs via findViewById traces. The output is a JSON execution plan: entry-point intents plus ordere

What would settle it

Construct a small app whose target method is guarded by a boolean set inside a dynamically registered broadcast receiver with an action absent from GAPS's callback mappings, then run GAPS: if it fails to produce a static path for that target while the method is genuinely reachable at runtime, that app is a counterexample to the completeness of the path-reconstruction claim. More directly, re-instrument the same AndroTest apps with exhaustive runtime method logging and recompute the 57.44% figure; a large drop would show the result depends on the specific sample or instrumentation rather than o

Watch

Extended reading notes

Core claim

The core discovery is that a demand-driven, backward partial call graph—built only from the target method upward to entry points—is not just faster than whole-program call graph construction but also provides the exact routing information that a GUI driver lacks: which intents trigger which components, how to satisfy a guard condition by setting a static field through a broadcast receiver, and which view IDs to click. GAPS demonstrates this on AndroTest: static paths for 88.24% of target methods in 4.27 seconds average, with 57.44% dynamically executed, compared with 58.81% static reachability for FlowDroid and 12.82% dynamic reachability for APE, 9.69% for GoalExplorer, and 17.12% for Guard

Load-bearing premise

GAPS's backward search finds a real path only if the static graph already contains the framework edge—lifecycle callback, broadcast, or listener—that actually fires at runtime; if those callback mappings miss an implicit flow, the reconstructed path does not correspond to any feasible execution and the reachability numbers overstate what a real run will do.

Editorial extensions

If this is right

  • If GAPS's numbers hold, vulnerability triage can move from 'is the method present?' to 'can we actually reach it dynamically?'—for 62% of flagged suspicious methods in popular apps, a concrete execution plan exists.
  • Dynamic reachability of about 57% within a five-minute cap makes targeted execution a feasible oracle for confirming whether a reported bug or leak is triggerable, not just statically plausible.
  • The static phase's average of 4.27 seconds on benchmark apps suggests path reconstruction can be embedded in continuous-integration pipelines without blowing up the analysis budget.
  • GAPS's conditional-path linking turns inter-component dependencies (e.g., broadcast must arrive before click) into enforced orderings in the interaction plan, enabling test generation that respects Android's event-driven semantics.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural extension is to transport the backward-slice recipe to other event-driven platforms (web, iOS, desktop) where the bottleneck is the framework's implicit callback edges; the paper itself flags Flutter and React Native as needing a different bytecode front-end.
  • The drop from 88.24% static path coverage to 57.44% dynamic execution can be decomposed into missing framework edges versus difficulty in reconstructing runtime state; if missing edges dominate, investing in richer callback maps (e.g., Jetpack Compose support) would directly raise dynamic reach.
  • Because GAPS emits explicit high-level plans, those plans are themselves artifacts that could seed regression tests, replay scripts, or mutation targets without requiring the dynamic module at all.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 6 minor

Summary. GAPS is a hybrid Android analysis system that, given a target method, performs a lightweight context-sensitive backward traversal of a statically constructed call graph enriched with data-flow analysis (points-to, constant propagation) to reconstruct feasible execution paths from entry points to the target, resolve conditional statements, and detect GUI elements. These paths are compiled into high-level interaction plans executed dynamically via adb, AndroidViewClient, and an optional Guardian-based fallback, with Frida hooks or AndroLogs used to confirm method execution. The paper reports evaluations on the 56-app AndroTest benchmark and 50 real-world Play Store apps, claiming large improvements over APE, GoalExplorer, Guardian (dynamic) and FlowDroid, DroidReach (static).

Significance. If the results are valid, GAPS would be a valuable first step toward practical method-level reachability, with clear downstream applications in vulnerability triage and targeted dynamic analysis. Strengths of the paper include the open-source release of source code and evaluation data, use of the standard AndroTest benchmark, instrumentation-based measurement rather than simulation, and a candid discussion of limitations. However, the central empirical claims are currently undermined by internal numerical inconsistencies and by a baseline setup that may be fundamentally unfair. These issues must be resolved before the contribution can be considered established.

major comments (5)
  1. [Abstract vs. §4.2, §7.1, §7.2] The headline numbers disagree between the abstract and the full text. The abstract reports Guardian 34%, GoalExplorer 4.75%, APE 11.12%, GAPS AndroTest dynamic 56.93%, real-world dynamic 54.80%, and a static analysis time of 12.67 s; the full text reports Guardian 17.12%, GoalExplorer 9.69%, APE 12.82%, GAPS dynamic 57.44%, real-world dynamic 59.86%, and 4.27 s. Since these values are the paper's central quantitative claims, the authors must identify which set is correct and ensure all versions (abstract, introduction, conclusions) are consistent.
  2. [§4.2, §7.1] The head-to-head comparison is not apples-to-apples. APE and GoalExplorer were run as coverage/exploration tools without target specification; GoalExplorer's target-flagging mode was unusable due to broken Maven dependencies. Guardian was prompted to 'interact with the application to maximize exploration' rather than to reach a specific method. GAPS receives each target method plus a statically reconstructed path. Moreover, only 34.39% of the targets are inside an Activity (§4.1); the other ~65% live in components that GUI testers are not designed to reach, as the authors themselves note in §2.1. The large gap (57.44% vs ≤17.12%) may therefore reflect task setup rather than technical superiority. Please provide target-aware baselines (e.g., a Guardian prompt that includes the target method's class/signature) or explicitly frame the comparison as 'unrestricted exploration vs. targeted gui
  3. [§6.3, §7.1] GAPS's dynamic module incorporates Guardian as an optional fallback when a widget/activity cannot be found, and §7.1 states Guardian was invoked on average four times per app, 'contributing to reaching 9.3% of the methods.' If the 57.44% figure includes these contributions, GAPS's reported success partly depends on the same LLM-based tool it is compared against. Please ablate the Guardian fallback and report GAPS's reachability with and without it. If the fallback is essential, the claim of outperforming Guardian must be reinterpreted.
  4. [§7.1] Despite 'three runs', no measure of dispersion is reported: no standard deviations, confidence intervals, per-app results, or random seeds for target selection. The reader cannot assess whether the 57.44% vs 17.12% difference is stable or driven by a few outlier apps. Please report per-tool and per-app summary statistics, and if appropriate a paired significance test (e.g., Wilcoxon). Also state the target-selection seed and whether the three runs used identical or different target sets.
  5. [§7.1, §7.2] Dynamic reachability is measured by logging every method execution via AndroLogs (AndroTest) or Frida hooks (real-world apps). This counts any execution during the run, including executions that may happen at app startup or via background components independently of GAPS's guidance. The paper should demonstrate that the target methods are executed after executing the statically reconstructed plan, not merely at any point during the dynamic run. This concern is acute in the real-world set, where reaching 59.86% of targets when static paths exist for only 62.03% (i.e., ~96.5% of statically reachable targets) suggests that some executions may be incidental rather than caused by the GAPS-directed plan.
minor comments (6)
  1. [Listing 1] The code contains artifacts such as 'Ap pCo mp at tiv it y' and the line numbers are misaligned. Please proofread the listings.
  2. [Table 1] The average GAPS dynamic time is reported as '00:03:15', inconsistent with other time formats. Include standard deviation or per-app variability in the table.
  3. [§4.2] State clearly whether the three runs use the same set of 50 target methods or a different random sample per run; this is needed to interpret the reported averages.
  4. [§4.3] The phrase 'we improved DroidReach by restricting entry points to only exported components' modifies the baseline. This should be labeled as a modified DroidReach variant in Table 1 and the text, since results may differ from the original tool.
  5. [§5.5, Algorithm 3] The predicate 'verify_condition' is used without a detailed definition. Please describe how non-constant operands (e.g., method return values) are evaluated and how satisfiability is decided.
  6. [References] Reference [47] appears to duplicate [24] in intent (Stoat); check for duplicate or unintended entries and ensure all citations in the text match the bibliography.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: GAPS's reachability numbers are empirical measurements, not derived-by-construction or fitted predictions.

full rationale

GAPS's central quantitative claims are empirical, not derivational. The static module performs a backward traversal from each target method and reports whether a path to an entry point is found; this is an algorithmic capability measurement, not a quantity defined in terms of its own output. Dynamic reachability is measured independently with AndroLogs/Frida instrumentation, so the success signal does not come from the static path reconstruction itself. No fitted parameter is hidden in the pipeline: the callback mappings are imported from external artifacts (EdgeMiner, Soot virtual edges, FlowDroid), and the paper explicitly acknowledges their potential unsoundness in §7.3. The few self-citations that appear ([38] for a timeout choice, [41] for instrumentation, [45] for the SPECK tool, and [39] for call-graph unsoundness) are used as supporting tools or contextual evidence, not as the proof of GAPS's core claim. The comparison against GUI baselines may be unfair because those tools were not given target methods and 65% of targets lie outside Activities, but this is a threat to experimental validity, not a circular reduction. The paper's honest limitation statements about implicit flows, Flutter/React Native, and Jetpack Compose further indicate that the results are empirical findings rather than tautologies forced by construction. Therefore no load-bearing step reduces a prediction or derived result to its own input.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claim rests on the completeness of implicit-callback mappings, accurate instrumentation, representative target sampling, and Dalvik-bytecode applicability. None of these are validated independently by the paper beyond acknowledging unsoundness and framework limitations.

assumptions (5)
  • domain assumption The callback/event mappings from EdgeMiner, Soot virtual edges, and FlowDroid are complete enough to recover the implicit framework edges needed to reach targets.
    GAPS's backward traversal depends on these mappings to resolve implicit flows such as lifecycle and callback invocations; §7.3 concedes remaining unsoundness could cause missed paths.
  • domain assumption The instrumentation used to measure dynamic reachability (AndroLogs on AndroTest, Frida hooks on Play Store apps) does not materially alter app behavior and logs every target execution.
    §4.1/§7.2; if hooks miss or are stripped by obfuscation, the dynamic reach rate is under- or over-stated.
  • domain assumption The 50 randomly selected target methods per app are representative of the methods a user would want to reach for vulnerability detection or comprehension.
    §4.1; random selection includes methods in libraries and non-Activity components; changing the sampling distribution would change all reachability numbers.
  • domain assumption The evaluated apps expose their logic in Dalvik bytecode readable by Androguard/Apktool; Flutter/React Native/Jetpack Compose apps are outside the central claim.
    §7.3 states these frameworks are not supported, bounding the claim to traditional Dalvik apps.
  • domain assumption The emulator environment (Android 13, x86-64; Pixel 2/Android 11 for ARM) reproduces the behavior of the real devices on which these apps run.
    §4.1; GUI timing, resource loading, and system broadcasts can differ on emulators, potentially affecting dynamic reach.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GAPS: Targeted Execution of Android Apps via Static Path Reconstruction." pith.science (2026). https://pith.science/paper/OIFZ5UTM

@misc{pith2026251123213,
  author       = {Pith},
  title        = {Pith review of: GAPS: Targeted Execution of Android Apps via Static Path Reconstruction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OIFZ5UTM}},
  note         = {Machine review of arXiv:2511.23213}
}
read the original abstract

Targeted execution of Android applications (apps) remains a longstanding challenge for software testing and analysis. Although recent advances in GUI testing have substantially improved app exploration, existing approaches remain largely coverage-driven and struggle to steer execution reliably toward specific methods of interest. This limitation hinders important downstream tasks, such as vulnerability detection, program comprehension, and dynamic analysis. We present GAPS (Graph-based Automated Path Synthesizer), the first approach to bridge static program analysis and dynamic GUI exploration, enabling targeted execution in Android apps. Given a target method, GAPS performs a lightweight static backward traversal of the call graph, enriched with data-flow reasoning, to identify feasible execution paths that lead to the target. It then translates these paths into actionable execution strategies that guide dynamic interactions with the app. We evaluate GAPS on the AndroTest benchmark and show that it reconstructs paths toward 88.24% of the target methods, requiring only 12.67 seconds per app on average. During dynamic execution, GAPS reaches 56.93% of the target methods, outperforming state-of-the-art alternatives. In comparison, the model-based GUI testing tool APE reaches only 11.12%, the hybrid exploration framework GoalExplorer reaches 4.75%, and the recent LLM-driven approach Guardian reaches 34%. To assess scalability in real-world settings, we further evaluate GAPS across the 50 most-downloaded apps on the Google Play Store. GAPS reconstructs execution paths toward 62.03% of the target methods, averaging 278.9 seconds per app, and dynamically reaches 54.80% of them. These results show that combining static path synthesis with guided dynamic exploration provides an effective and scalable solution for targeted method execution in Android apps.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 3 canonical work pages

  1. [1]

    Faridah Akinotcho, Lili Wei, and Julia Rubin. 2025. Mobile Application Coverage: The 30% Curse and Ways Forward. In2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE Computer Society, 679–679

    2025

  2. [2]

    Androguard. 2025. Androguard. https://github.com/androguard/androguard. Accessed: 2026-01-21

    2025

  3. [3]

    Androguard. 2025. Androguard - AnalyzeAPK function. https://androguard.readthedocs.io/en/latest/intro/ gettingstarted.html?highlight=AnalyzeAPK#using-androlyze-and-the-python-api. Accessed: 2026-01-21

    2025

  4. [4]

    Androguard. 2025. Call-graph generation with Androguard. https://androguard.readthedocs.io/en/latest/tools/androcg. html. Accessed: 2026-01-21

    2025

  5. [5]

    APKTool. 2025. APKTool. https://apktool.org/. Accessed: 2026-01-21

    2025

  6. [6]

    Steven Arzt, Siegfried Rasthofer, Christian Fritz, Eric Bodden, Alexandre Bartel, Jacques Klein, Yves Le Traon, Damien Octeau, and Patrick McDaniel. 2014. FlowDroid: Precise Context, Flow, Field, Object-Sensitive and Lifecycle-Aware Taint Analysis for Android Apps.AMC SIGPLAN Notices49, 6 (jun 2014), 259–269. doi:10.1145/2666356.2594299

    arXiv 2014

  7. [7]

    Vitalii Avdiienko, Konstantin Kuznetsov, Alessandra Gorla, Andreas Zeller, Steven Arzt, Siegfried Rasthofer, and Eric Bodden. 2015. Mining Apps for Abnormal Usage of Sensitive Data. 1 (2015), 426–436. doi:10.1109/ICSE.2015.61

    work page doi:10.1109/icse.2015.61 2015

  8. [8]

    Luca Borzacchiello, Emilio Coppa, Davide Maiorca, Andrea Columbu, Camil Demetrescu, and Giorgio Giacinto. 2022. Reach Me if You Can: On Native Vulnerability Reachability in Android Apps. (2022), 701–722

    2022

Show all 52 references
  1. [9]

    Priyanka Bose, Dipanjan Das, Saastha Vasan, Sebastiano Mariani, Ilya Grishchenko, Andrea Continella, Antonio Bianchi, Christopher Kruegel, and Giovanni Vigna. 2023. Columbus: Android App Testing Through Systematic Callback Exploration. (2023), 1381–1392. doi:10.1109/ICSE48619....

    2023

  2. [10]

    Yinzhi Cao, Yanick Fratantonio, Antonio Bianchi, Manuel Egele, Christopher Kruegel, Giovanni Vigna, and Yan Chen. 2015. EdgeMiner: Automatically Detecting Implicit Control Flow Transitions through the Android Framework. (February 2015)

    2015

  3. [11]

    Shauvik Roy Choudhary, Alessandra Gorla, and Alessandro Orso. 2015. Automated Test Input Generation for Android: Are We There Yet? (2015), 429–440. doi:10.1109/ASE.2015.89

    2015 doi

  4. [12]

    Zhen Dong, Marcel Böhme, Lucia Cojocaru, and Abhik Roychoudhury. 2020. Time-Travel Testing of Android Apps. (2020), 481–492. doi:10.1145/3377811.3380402

    2020

  5. [13]

    dtmilano. 2025. AndroidViewClient. https://github.com/dtmilano/AndroidViewClient. Accessed: 2026-01-21

    2025

  6. [14]

    findViewById

    dtmilano. 2025. "findViewById" method in the AndroidViewClient library. https://dtmilano.github.io/ AndroidViewClient/index.html#com.dtmilano.android.viewclient.ViewClient.findViewById. Accessed: 2026-01-21

    2025

  7. [15]

    dtmilano. 2025. "touch" method in the AndroidViewClient library. https://dtmilano.github.io/AndroidViewClient/ index.html#com.dtmilano.android.viewclient.View.touch. Accessed: 2026-01-21

    2025

  8. [16]

    Dmitry Duplyakin, Robert Ricci, Aleksander Maricq, Gary Wong, Jonathon Duerig, Eric Eide, Leigh Stoller, Mike Hibler, David Johnson, Kirk Webb, Aditya Akella, Kuangching Wang, Glenn Ricart, Larry Landweber, Chip Elliott, Michael Zink, Emmanuel Cecchet, Snigdhaswin Kar, and Pra...

    2019

  9. [17]

    Eclipse. 2025. MoDisco. https://eclipse.dev/MoDisco/. Accessed: 2026-01-21

    2025

  10. [18]

    Frida. 2025. Frida. https://frida.re/. Accessed: 2026-01-21

    2025

  11. [19]

    Joshua Garcia, Mahmoud Hammad, Negar Ghorbani, and Sam Malek. 2017. Automatic generation of inter-component communication exploits for android applications. InProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering. 661–671

    2017

  12. [20]

    Google. 2025. Monkey. https://developer.android.com/studio/test/other-testing-tools/monkey. Accessed: 2026-01-21

    2025

  13. [21]

    Tianxiao Gu, Chengnian Sun, Xiaoxing Ma, Chun Cao, Chang Xu, Yuan Yao, Qirun Zhang, Jian Lu, and Zhendong Su. 2019. Practical GUI Testing of Android Applications Via Model Abstraction and Refinement. (2019), 269–280. doi:10.1109/ICSE.2019.00042

    2019

  14. [22]

    LV Haoyin. 2017. Automatic android application GUI testing—A random walk approach. (2017), 72–76

    2017

  15. [23]

    Konstantin Kuznetsov, Vitalii Avdiienko, Alessandra Gorla, and Andreas Zeller. 2018. Analyzing the user interface of android apps. InProceedings of the 5th International Conference on Mobile Software Engineering and Systems. 84–87. 4https://github.com/samudoria/GAPS/ , Vol. 1,...

    2018

  16. [24]

    Duling Lai and Julia Rubin. 2019. Goal-driven exploration for android applications. In2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 115–127

    2019

  17. [25]

    Bissyandé, Jacques Klein, Yves Le Traon, Steven Arzt, Siegfried Rasthofer, Eric Bodden, Damien Octeau, and Patrick McDaniel

    Li Li, Alexandre Bartel, Tegawendé F. Bissyandé, Jacques Klein, Yves Le Traon, Steven Arzt, Siegfried Rasthofer, Eric Bodden, Damien Octeau, and Patrick McDaniel. 2015. IccTA: Detecting Inter-Component Privacy Leaks in Android Apps. 1 (2015), 280–291. doi:10.1109/ICSE.2015.48

    2015 doi

  18. [26]

    Martina Lindorfer, Matthias Neugschwandtner, Lukas Weichselbaum, Yanick Fratantonio, Victor Van Der Veen, and Christian Platzer. 2014. Andrubis–1,000,000 apps later: A view on current Android malware behaviors. (2014), 3–17

    2014

  19. [27]

    Zhe Liu, Chunyang Chen, Junjie Wang, Mengzhuo Chen, Boyu Wu, Xing Che, Dandan Wang, and Qing Wang. 2024. Make LLM a Testing Expert: Bringing Human-like Interaction to Mobile GUI Testing via Functionality-aware Decisions. , Article 100 (2024), 13 pages. doi:10.1145/3597503.3639180

    2024

  20. [28]

    Aravind Machiry, Rohan Tahiliani, and Mayur Naik. 2013. Dynodroid: An Input Generation System for Android Apps. (2013), 224–234. doi:10.1145/2491411.2491450

    2013

  21. [29]

    Riyadh Mahmood, Nariman Mirzaei, and Sam Malek. 2014. Evodroid: Segmented evolutionary testing of android apps. (2014), 599–609

    2014

  22. [30]

    Ke Mao, Mark Harman, and Yue Jia. 2016. Sapienz: Multi-Objective Automated Testing for Android Applications. (2016), 94–105. doi:10.1145/2931037.2931054

    2016

  23. [31]

    Alejandro Martín, Raúl Lara-Cabrera, and David Camacho. 2018. A new tool for static and dynamic Android malware analysis. (2018), 509–516

    2018

  24. [32]

    all_shortest_paths

    NetworkX. 2025. "all_shortest_paths" method in networkx documentation. https://networkx.org/documentation/ stable/reference/algorithms/generated/networkx.algorithms.shortest_paths.generic.all_shortest_paths.html. Accessed: 2026-01-21

    2025

  25. [33]

    NetworkX. 2025. networkx. https://networkx.org/. Accessed: 2026-01-21

    2025

  26. [34]

    Minxue Pan, An Huang, Guoxin Wang, Tian Zhang, and Xuandong Li. 2020. Reinforcement learning based curiosity- driven testing of android applications. (2020), 153–164

    2020

  27. [35]

    Amogh Pradeep, Álvaro Feal, Julien Gamba, Ashwin Rao, Martina Lindorfer, Narseo Vallina-Rodriguez, and David Choffnes. 2022. Not Your Average App: A Large-scale Privacy Analysis of Android Browsers. (2022). arXiv:2212.03615 [cs.CR] doi:10.56553/popets-2023-0003

    2022 arXiv

  28. [37]

    Andrea Romdhana, Alessio Merlo, Mariano Ceccato, and Paolo Tonella. 2022. Deep Reinforcement Learning for Black-Box Testing of Android Apps.ACM Transactions on Software Engineering and Methodology31, 4, Article 65 (jul 2022), 29 pages. doi:10.1145/3502868

    2022 doi

  29. [38]

    Antonio Ruggia, Eleonora Losiouk, Luca Verderame, Mauro Conti, and Alessio Merlo. 2021. Repack me if you can: An anti-repackaging solution based on android virtualization. InProceedings of the 37th Annual Computer Security Applications Conference. 970–981

    2021

  30. [39]

    Bissyandé, Michael D

    Jordan Samhi, René Just, Tegawendé F. Bissyandé, Michael D. Ernst, and Jacques Klein. 2024. Call Graph Soundness in Android Static Analysis. (2024), 945–957. doi:10.1145/3650212.3680333

    2024

  31. [40]

    Jordan Samhi, Marc Miltenberger, Marco Alecci, Steven Arzt, Tegawendé Bissyandé, and Jacques Klein. 2025. Do you have 5 min? Improving Call Graph Analysis with Runtime Information. InProceedings of the 33rd ACM International Conference on the Foundations of Software Engineerin...

    2025

  32. [41]

    Jordan Samhi and Andreas Zeller. 2024. AndroLog: Android Instrumentation and Code Coverage Analysis. (2024), 597–601

    2024

  33. [42]

    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. , Article 49 (2024), 17 pages. doi:10.1145/3654777.3676386

    2024

  34. [43]

    Soot. 2025. Soot. https://soot-oss.github.io/soot/. Accessed: 2026-01-21

    2025

  35. [44]

    Soot. 2025. Soot virtual edges. https://github.com/soot-oss/soot/blob/cbea60f0d2a8562f37a34906fa9e3ff7363b5f8d/src/ main/resources/virtualedges.xml. Accessed: 2026-01-21

    2025

  36. [45]

    SPRITZ. 2025. SPECK. https://github.com/SPRITZ-Research-Group/SPECK. Accessed: 2026-01-21

    2025

  37. [46]

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

  38. [47]

    Ting Su, Guozhu Meng, Yuting Chen, Ke Wu, Weiming Yang, Yao Yao, Geguang Pu, Yang Liu, and Zhendong Su. 2017. Guided, stochastic model-based GUI testing of Android apps. (2017), 245–256. doi:10.1145/3106237.3106298

    2017

  39. [48]

    Ting Su, Jue Wang, and Zhendong Su. 2021. Benchmarking automated gui testing for android against real-world bugs. (2021), 119–130

    2021

  40. [49]

    Wenyu Wang, Wing Lam, and Tao Xie. 2021. An infrastructure approach to improving effectiveness of Android UI testing tools. (2021), 165–176. , Vol. 1, No. 1, Article . Publication date: January 2026. Mind the GAPS: Bridging the GAPS between Targeted Dynamic Analysis and Static...

    2021

  41. [50]

    Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. 2018. Amandroid: A Precise and General Inter-Component Data Flow Analysis Framework for Security Vetting of Android Apps.ACM Transactions On Privacy and Security21, 3, Article 14 (apr 2018), 32 pages. doi:10.1145/3183575

    2018 doi

  42. [51]

    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. (2024), 543–557. doi:10.1145/3636534.3649379

    2024

  43. [52]

    Xia Zeng, Dengfeng Li, Wujie Zheng, Fan Xia, Yuetang Deng, Wing Lam, Wei Yang, and Tao Xie. 2016. Automated Test Input Generation for Android: Are We Really There yet in an Industrial Case? (2016), 987–992. doi:10.1145/2950290. 2983958 , Vol. 1, No. 1, Article . Publication da...

    2016 doi

  44. [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

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.