PaperlayerView exact revision on arXiv

Source-linked AI summary

RotDroid: Cross-Orientation State Equivalence Testing for Detecting GUI Rotation Bugs in Android Apps

Mengdi Qin, Bo Jiang

arXiv:2608.25425v1cs.SEcs.AI

TL;DR

GUI rotation bugs are difficult to detect because cross-orientation state equivalence lacks effective oracles and bugs may emerge only amid user interactions. RotDroid addresses this with state-preserving action-sequence generation, RotBench, and RotVL, reporting 94 previously unknown bugs across open-source and commercial apps.

  • Problem

    Effective oracles for cross-orientation state equivalence are difficult to design, while naive orientation switching may miss bugs that emerge amid user interactions.

  • Method

    RotDroid generates and mutates state-preserving action sequences to construct paired GUI states, then uses RotVL, trained on RotBench, to check equivalence.

  • Results

    Across model and app evaluations, RotVL-8B achieves an F1-score of 85.29%, while RotDroid reports 94 previously unknown bugs across open-source and commercial apps.

  • Takeaways & Limitations

    RotDroid demonstrates practical effectiveness for detecting real-world GUI rotation issues in Android applications.

  • Takeaways & Limitations

    State-preserving action sequences cannot guarantee preservation of hidden server-side state, caches, or external side effects.

Abstract

from arXiv · show

Screen rotation is a fundamental interaction in Android applications, but it often introduces non-crashing functional failures (NCFs), such as layout inconsistencies and state loss, which are difficult to detect automatically. A key challenge is the lack of effective test oracles for checking cross-orientation state equivalence between portrait and landscape views. We propose RotDroid, a testing framework for detecting GUI rotation bugs via cross-orientation state equivalence. RotDroid generates and mutates State-Preserving action Sequences (SPS) to construct semantically equivalent GUI states across orientations. To support reliable oracle checking, we build RotBench, a dataset of paired portrait-landscape GUI states, and develop RotVL, a vision-language model fine-tuned for equivalence checking. Experiments on both synthetic and real-world datasets show that RotVL outperforms state-of-the-art models, and RotDroid detects more rotation-induced failures than existing techniques under equal budgets. In large-scale studies on open- and closed-source apps, RotDroid reports 94 previously unknown bugs, with 47 confirmed or fixed by developers, demonstrating its practical effectiveness.

I. INTRODUCTION · II. EMPIRICAL STUDY

RotDroid addresses rotation-induced Android GUI failures by constructing semantically equivalent portrait–landscape states and checking their equivalence with RotVL. An empirical study of real-world issue reports derives a symptom-oriented taxonomy that guides RotBench and focuses testing on dominant, systematically generatable defect types.

  • I. INTRODUCTION: Orientation changes trigger Android activity destruction and recreation, making transient-state preservation and seamless portrait–landscape adaptation difficult.This lifecycle behavior contributes to non-crashing failures such as layout inconsistencies and state loss.
  • I. INTRODUCTION: Existing testing approaches miss cross-orientation GUI inconsistencies because they prioritize crashes, inspect static views, compare structurally different layouts, or overlook intermediate states and layout-related defects.These limitations leave cross-orientation state equivalence without an effective automated oracle.
  • I. INTRODUCTION: Cross-orientation testing requires an oracle for semantic state equivalence and interaction-aware sequences, because naive orientation switching may not expose rotation bugs.Failures can emerge only when orientation changes are interleaved with user interactions.
  • I. INTRODUCTION: RotBench contains equivalent and non-equivalent portrait–landscape GUI pairs, while RotVL performs cross-orientation state equivalence checking.The empirical study informs RotBench construction, and RotVL serves as the vision-language oracle for RotDroid.
  • I. INTRODUCTION: RotVL-8B outperforms Qwen3-VL-235B-A22B-Instruct and GPT-5.2 on cross-orientation bug detection tasks.RotDroid was evaluated on 300 open-source and 103 commercial Android applications, reporting 72 previously unknown open-source bugs and 22 commercial bugs.
  • I. INTRODUCTION: RotDroid generates and mutates state-preserving action sequences to construct semantically equivalent GUI states across orientations and detect rotation-induced inconsistencies.The framework combines systematic sequence generation with cross-orientation consistency checking.
  • II. EMPIRICAL STUDY: 6,031 unique closed GitHub reports were mined using orientation-related keywords, and manual inspection reduced them to 898 confirmed rotation-induced GUI issues.The reports were limited to closed issues from the past five years, with disagreements resolved through discussion.
  • II. EMPIRICAL STUDY: The taxonomy comprises Rotation Execution Failures, Layout Failures, State Restoration Failures, and Other, with Layout Failures at 35%, Rotation Execution Failures at 34%, State Restoration Failures at 23%, and Other at 8%.RotBench focuses on the five dominant defect types that can be systematically generated and validated.

III. THE ROTVL MODEL … 2) Automated Generation of Defective Pairs:

RotVL is a rotation-aware vision-language model supported by RotBench, which combines automatically collected non-defective portrait-landscape GUI pairs with synthesized defective pairs. The defective-pair pipeline validates cross-orientation widgets, applies targeted mutations, and produces labeled samples across five defect categories.

  • III. THE ROTVL MODEL: RotVL is fine-tuned to detect cross-orientation GUI inconsistencies because existing vision-language models are ineffective for paired portrait-landscape state-equivalence checking.Its methodology rests on constructing RotBench and training the rotation-aware model.
  • A. RotBench: Pairwise Rotation-related GUI Defect Dataset: RotBench combines non-defective pairs collected through an automated equivalent-GUI-state pipeline with augmented defective pairs.The dataset is designed for cross-orientation GUI equivalence checking.
  • 1) Automated Collection of Non-defective Pairs:: 851 candidate applications from F-Droid were used to construct the non-defective pairs dataset through an automated pipeline.The candidates served as input to the collection process illustrated in Figure 1.
  • 1) Automated Collection of Non-defective Pairs:: The collection pipeline captures each target activity’s view hierarchy and snapshot in both portrait and landscape orientations after preparing modified APKs for deployment.Preparation includes manifest modification, rebuilding, alignment, signing, installation, and systematic activity launches.
  • 2) Automated Generation of Defective Pairs:: Defective-pair generation takes paired portrait-landscape screenshots and XML view hierarchies, injecting an orientation-specific defect and recording its category, orientation, and bounding box.The resulting labels precisely identify the anomaly location and affected orientation.
  • 2) Automated Generation of Defective Pairs:: Candidate widgets are verified as visible and persistent across orientations before mutation operators reproduce five representative defect types.Coordinate mapping and content matching ensure that selected regions correspond across orientation states.
  • 2) Automated Generation of Defective Pairs:: 11,233 paired samples were constructed: 2,950 Component Absence, 2,852 Component Overlap, 2,783 Content Clipping, 2,024 Orientation Mismatch, and 624 State Loss.The pipeline also validates generated pairs by quantifying visual discrepancy between original and mutated states.

3) Data Balancing and Partitioning Strategy:

RotBench is partitioned by unique project identifiers to test generalization across unseen applications, using an 8:1:1 training-validation-testing split. A two-stage stratified undersampling process then balances defect types and orientations for task-specific datasets.

  • Project-Wise Partitioning: 8:1:1 splits training, validation, and testing subsets by unique project identifiers, preventing project-specific visual patterns or defect characteristics from crossing evaluation boundaries.The partitioning operates at the project level rather than the sample level to support generalization over unseen applications.
  • Class Balancing: State Loss is the minority defect category because it depends on specific EditText-based mutations, unlike layout-based defects.This imbalance motivates fine-grained stratified under-sampling across defect types and screen orientations.
  • Class Balancing: Majority subgroups are randomly undersampled to the minority subgroup threshold κ after grouping defective samples by the Cartesian product of defect type and orientation.The cross-attribute normalization stage is designed to balance defect variety and device rotation robustness.
  • Task-Specific Construction: Bug detection uses equal numbers of defective and non-defective screens, forming balanced positive and negative sets.The 1:1 ratio is intended to prevent bias toward the majority non-defective class.
  • Task-Specific Construction: Bug classification and localization use only defective samples while maintaining equal representation across all five defect classes.This preserves the equilibrium established during cross-attribute normalization.

B. Fine-tuning Strategy · 1) Task-Aware Instruction Design:

RotDroid’s LoRA fine-tuning uses a structured, two-stage coarse-to-fine instruction strategy for GUI defect detection and diagnosis. The design decomposes detection from positive-sample classification/localization, injects defect semantics, and constrains outputs for downstream evaluation.

  • B. Fine-tuning Strategy: The two-stage coarse-to-fine instruction template guides LoRA fine-tuning for effective GUI bug detection and diagnosis while reducing hallucinations on non-defective samples.The strategy is designed to mimic human testers’ cognitive process.
  • 1) Task-Aware Instruction Design:: The model is explicitly assigned the role “Expert GUI defect detector” to prime domain-specific behavior.This role definition is part of the instruction template’s task decomposition.
  • 1) Task-Aware Instruction Design:: Bug detection is formulated as a binary classification sub-task determining whether defects are present.This is the coarse-grained stage of the decomposed objective.
  • 1) Task-Aware Instruction Design:: Bug classification and localization is learned exclusively from positive samples as a dense prediction sub-task.The model predicts defect attributes only after defect presence is established.
  • 1) Task-Aware Instruction Design:: Detailed semantic definitions for all five defect categories help distinguish visually similar defects such as layout-clipping and layout-absence.The prompt includes explanations such as layout-overlap meaning UI components masking each other.
  • 1) Task-Aware Instruction Design:: A strict JSON schema constrains detection to a boolean bug indicator and localization to type, image orientation, and bbox_2d fields.These constraints make outputs parsing-friendly for downstream evaluation.
  • 1) Task-Aware Instruction Design:: During training, ground-truth examples are formatted conversationally, with user instructions masked and loss computed only on model JSON responses.This focuses optimization on producing the required structured answers.

2) Training Strategy and Optimization: … B. Mutated SPS Generation and Execution

RotDroid combines structure-aware GUI modeling, mutated state-preserving action sequences, and RotVL-based analysis to detect and diagnose Android GUI rotation bugs. Its SPS-based testing constructs portrait–landscape state pairs by inserting rotations into action sequences and checks the intermediate landscape state against both portrait targets.

  • 2) Training Strategy and Optimization:: Qwen3-VL is adapted with LoRA and jointly fine-tuned on RotBench for bug detection, classification, and localization.The tasks are formulated as next-token prediction under a standardized instruction-following format.
  • IV. ROTDROID: RotDroid comprises UI Transition Graph Modeling, Mutated SPS Generation and Execution, and RotVL-based Bug Detection.The modules respectively model GUI transitions, synthesize state-equivalent portrait–landscape pairs, and detect and diagnose rotation bugs.
  • 1) Robust State Abstraction:: Interactive widgets are extracted from the view hierarchy while disabled or non-visible nodes are excluded, and composite semantics are recursively aggregated.Each action also receives a robust locator, such as XPath, together with semantic and structural descriptions.
  • 2) UI Transition Graph Construction:: The UI Transition Graph represents each GUI state through widget states and hierarchical relationships, with edges denoting actions that transition between states.The graph models the application’s execution behavior and supports systematic exploration.
  • B. Mutated SPS Generation and Execution: An SPS transforms an initial portrait state into a semantically and operationally equivalent portrait state through a sequence of actions.Equivalence concerns observable GUI functionality and user-visible semantics rather than every hidden application state.
  • B. Mutated SPS Generation and Execution: RotDroid inserts a rotation into an SPS to reach a landscape target, then rotates back to obtain a second portrait target and forms two portrait–landscape pairs.The construction uses the mutated sequence A′ and produces targets Sp1, Sl, and Sp2 for differential testing.
  • B. Mutated SPS Generation and Execution: Unlike DOC-style checking, RotDroid interleaves rotation with user actions and explicitly compares the intermediate landscape state against both portrait target states.DOC-based methods perform consecutive portrait–landscape–portrait rotations without interleaved user actions and compare only the initial and final portrait states.

1) State-preserving Action Sequence Extraction: · 2) State-preserving Action Sequence Mutation:

RotDroid extracts executable state-preserving action sequences from closed-loop UTG trajectories and mutates them by inserting rotation actions. These mutations create portrait–landscape test pairs for cross-orientation consistency checking.

  • 1) State-preserving Action Sequence Extraction:: An SPS is a closed-loop execution trajectory that starts at a specific state Sstart and returns to it through interactions.This defines the state-preserving property used for sequence acquisition.
  • 1) State-preserving Action Sequence Extraction:: When a new UTG transition edge enew is added, DFS identifies all simple cycles containing that edge.The extraction process is triggered by each newly added transition edge.
  • 1) State-preserving Action Sequence Extraction:: Reachability analysis makes each abstract cycle executable from the application entry point by computing the shortest path Pinit from Sroot to Sstart.The resulting executable sequence combines the entry path with the identified cycle, although the supplied passage is truncated before its full construction.
  • 2) State-preserving Action Sequence Mutation:: The mutation operator inserts a screen-orientation change, arot, into an acquired SPS to reconstruct the UI layout under a different configuration.This produces the portrait–landscape pairs needed for cross-orientation consistency testing.
  • 2) State-preserving Action Sequence Mutation:: For base sequence A = ⟨a1, . . . , an⟩, random sampling without replacement selects unique insertion indices from [0, n), generating variant sequences Ω.At each sampled index k, the process injects a rotation action arot and transforms recovery into cross-orientation consistency checks.
  • 2) State-preserving Action Sequence Mutation:: The landscape target state Sltarget is expected to be semantically equivalent to the original portrait target state Sp1target and the rotated-back portrait target state Sp2target.These three target states define the equivalence relationship used by the mutation-based checks.

3) Mutated State-preserving Action Sequence Execution: · C. VLM-based Bug Detection · V. EVALUATION

RotDroid executes mutated state-preserving action sequences through adaptive widget matching and uses RotVL to detect, classify, and localize cross-orientation GUI defects. Its evaluation examines RotVL’s detection capability, comparisons with existing tools, and unknown-bug discovery in open- and closed-source applications.

  • 3) Mutated State-preserving Action Sequence Execution:: Adaptive Action Execution addresses runtime differences between Android GUIs and static UTG snapshots using hierarchical spatial matching.Runtime widget attributes such as list contents or memory addresses may differ from recorded snapshots.
  • 3) Mutated State-preserving Action Sequence Execution:: Before each planned action, RotDroid binds the recorded widget to a current runtime element through cascading matching priorities.The system captures the current runtime hierarchy before attempting the binding.
  • 3) Mutated State-preserving Action Sequence Execution:: Matching prioritizes invariant resource IDs, then semantic attributes, and finally stable XPath suffixes for structural approximation under orientation changes.Semantic matching uses class names and aggregated attributes, while structural matching preserves local context near the root hierarchy.
  • C. VLM-based Bug Detection: RotVL receives portrait–landscape state pairs and outputs a boolean verdict for bug presence during the Bug Detection phase.This component is RotDroid’s downstream defect-detection module.
  • C. VLM-based Bug Detection: When a defect is identified, RotDroid performs secondary bug classification and localization using dedicated prompts.The provided execution trace from SPS execution ensures that the issue is reproducible.
  • V. EVALUATION: The evaluation defines five research questions covering RotVL effectiveness, comparisons with data-loss and orientation-failure tools, and unknown-bug discovery.RQ1 targets cross-orientation bug detection, classification, and localization; RQ2–RQ5 address tool comparisons and open- or closed-source applications.
  • V. EVALUATION: RQ2 evaluates RotDroid against representative data-loss detection tools for rotation-induced state-restoration failures.RQ3 compares RotDroid with prior DOC same-orientation checking based on initial and final portrait-state consistency.
  • V. EVALUATION: RQ4 and RQ5 assess whether RotDroid can detect unknown rotation bugs in real-world open-source and closed-source applications.These questions separately examine open-source and closed-source application settings.

A. Implementation · B. Evaluation Setup · 1) Datasets:

RotDroid’s implementation combines APK instrumentation and UI data acquisition with RotVL fine-tuning across three model scales. Evaluation uses dedicated datasets for model generalization, baseline comparisons, natural bugs, and large-scale open- and closed-source app studies under controlled testing budgets.

  • A. Implementation: Apktool extracts resources, while zipalign and apksigner repackage instrumented applications; uiautomator2 captures synchronized screenshots and view hierarchies.These components support both application instrumentation and dynamic GUI data acquisition.
  • A. Implementation: RotVL-2B, RotVL-4B, and RotVL-8B were fine-tuned from the corresponding official Qwen3-VL-Instruct checkpoints using LLaMA-Factory on NVIDIA V100 GPUs.The three variants provide different parameter scales for evaluating scalability.
  • 1) Datasets:: Six datasets were constructed to address the study’s research questions, including benchmarks for RotVL evaluation, baseline comparisons, competing approaches, and broader app studies.The datasets cover both synthetic and real-world evaluation settings.
  • 1) Datasets:: The RotBench testing split prevents project-specific data leakage, while the Natural Bug Set contains 100 screenshot pairs from 44 real-world apps with developer-confirmed rotation bugs.The natural-bug pairs were manually annotated for bug detection.
  • 1) Datasets:: The RQ2 comparison benchmark contains 48 Android applications from the intersection of the published datasets for iFixDataloss and DLD.RotDroid is compared against these two representative state-loss detection tools.
  • 1) Datasets:: For RQ3, the DOC-based detection module was reproduced and evaluated on open-source apps matching the versions reported in the original study.RotDroid’s exploration module generated the initial test cases for the reproduced approach.
  • 1) Datasets:: The F-Droid dataset contains 300 randomly selected open-source applications, while the Google Play dataset contains 103 filtered closed-source applications.Apps lacking ADB launchability or rotation support were excluded from the respective collections.

2) Evaluation Metrics: · C. RQ1: Effectiveness of RotVL

The evaluation defines task-specific metrics for RotVL and shows that RotVL-8B achieves leading performance across detection, classification, and localization, including statistically significant gains and real-world generalization.

  • 2) Evaluation Metrics:: RotVL is evaluated on Bug Detection, Bug Classification, and Bug Localization, with localization split into Orientation and Coordinate subtasks.The Coordinate subtask identifies the spatial bug region after the target image is identified.
  • 2) Evaluation Metrics:: Accuracy, Precision, Recall, and F1-score measure detection, classification, and orientation-localization performance.
  • 2) Evaluation Metrics:: Coordinate localization uses Center Point Distance and Area Ratio to assess spatial accuracy and predicted bounding-box size.Center Point Distance is measured in pixels, while Area Ratio compares predicted and ground-truth bounding-box areas.
  • 2) Evaluation Metrics:: For RQ2–RQ5, evaluation reports detected bugs, true positives, false positives, submitted issues, and developer verification status.Verification status records whether issues were confirmed, fixed, pending, or rejected.
  • C. RQ1: Effectiveness of RotVL: 85.29% F1-score makes RotVL-8B state-of-the-art for bug detection, exceeding Qwen3-VL-32B, Qwen3-VL-235B, and GPT-5.2.The reported baselines achieve 57.84%, 59.32%, and 70.84% F1, respectively; RotVL-2B and RotVL-4B also surpass all listed baselines across the reported detection metrics.
  • C. RQ1: Effectiveness of RotVL: 62.68% F1-score gives RotVL-8B the strongest bug-classification result, surpassing Qwen3-VL-32B, Qwen3-VL-235B, and GPT-5.2.RotVL-2B improves from 9.56% to 42.97% F1 after fine-tuning and surpasses Qwen3-VL-235B.
  • C. RQ1: Effectiveness of RotVL: 79.97% orientation-localization F1, 198px Center Point Distance, and 3.17 Area Ratio make RotVL-8B best on both localization subtasks.For comparison, GPT-5.2 records 68.13% orientation F1 and 276px Center Point Distance, while Qwen3-VL-235B records 46.10% and 459px, respectively.
  • C. RQ1: Effectiveness of RotVL: p < 0.001 establishes statistically significant RotVL-8B improvements across all evaluated detection, classification, and localization dimensions.McNemar’s test is used for discrete metrics and the Wilcoxon signed-rank test for continuous metrics.

D. RQ2: Comparison with Data Loss Detection Tools · E. RQ3: Comparison with a Rotation-based GUI Failure Detection Method

RotDroid outperforms data-loss and rotation-based GUI failure detection tools in true-bug detection, while directly checking cross-orientation state equivalence. Its advantage comes with false positives from dynamic, transient, and responsive UI content.

  • D. RQ2: Comparison with Data Loss Detection Tools: RotDroid captures user-visible cross-orientation state inconsistencies beyond state-variable loss by mutating state-preserving sequences around rotation.This design exposes restoration failures that occur only when rotation is interleaved with normal GUI interactions.
  • D. RQ2: Comparison with Data Loss Detection Tools: False positives mainly arise from dynamic or transient content, including clocks, changing game states, blinking cursors, and temporary Autofill/Paste menus.Some landscape views also contain extra icons or layout elements caused by normal responsive adaptation.
  • E. RQ3: Comparison with a Rotation-based GUI Failure Detection Method: 268 true bugs were detected by RotDroid, compared with 139 for DOC, while precision was 84.28% for RotDroid and 86.34% for DOC.Although DOC has slightly higher precision, RotDroid detects nearly twice as many true bugs.
  • E. RQ3: Comparison with a Rotation-based GUI Failure Detection Method: DOC compares initial and final portrait states after a portrait→landscape→portrait sequence, omitting SPS mutation and cross-orientation consistency checking.This same-orientation validation detects failures that persist after the second rotation.
  • E. RQ3: Comparison with a Rotation-based GUI Failure Detection Method: DOC may miss failures appearing only in the intermediate landscape state and disappearing after rotating back.RotDroid avoids this limitation by comparing portrait–landscape state-equivalent pairs through RotVL.

F. RQ4: Effectiveness on Real-world Open-source Apps … A. Layout Failures in Florae

RotDroid found and validated GUI rotation issues across open-source and closed-source Android apps, with developer engagement and practical impact. A Florae case study illustrates how cross-orientation state comparison exposes layout failures that conventional checks can miss.

  • F. RQ4: Effectiveness on Real-world Open-source Apps: 78 GUI rotation issues were identified in open-source Android apps, with 72 submitted to developers and 6 already fixed in newer releases.RotDroid was evaluated on a diverse set of open-source applications.
  • F. RQ4: Effectiveness on Real-world Open-source Apps: 47 issues were confirmed, including 29 fixed, 12 confirmed but not fixed, and 6 fixed in newer versions; 30 remained pending and 1 was rejected.Among confirmed issues, 21 were layout failures, 25 involved state restoration, and 1 involved rotation execution.
  • F. RQ4: Effectiveness on Real-world Open-source Apps: RotDroid uncovered bugs in widely used open-source apps, including DuckDuckGo with 50M+ installs and smaller projects with 100k+ installs.The reported applications demonstrate impact beyond small or toy projects.
  • F. RQ4: Effectiveness on Real-world Open-source Apps: 41 confirmed issues among 72 submitted GUI rotation issues supported RotDroid’s effectiveness on real-world open-source applications.Developer feedback included fixes and constructive discussions, such as resolving missing-button access in Infomaniak kMeet.
  • G. RQ5: Effectiveness on Real-world Closed-source Apps: 22 GUI rotation issues were identified in 20 representative closed-source commercial applications, with 6 confirmed across 15 diverse categories.The evaluated applications included widely used commercial apps and showed generalizability beyond open-source repositories.
  • A. Layout Failures in Florae: In Florae, the portrait “Select hours” dialog is correctly rendered, whereas the corresponding landscape view fails to reposition its internal components.The portrait view shows the input value, unit label, reset icon, and “OK” button visibly and spatially separated.
  • A. Layout Failures in Florae: The landscape view occludes the “hours” label with the “OK” button and overlaps the reset icon with the dialog boundary.RotDroid detects this failure by comparing portrait and landscape states generated through a mutated state-preserving action sequence, unlike checks limited to consecutive portrait states.

B. DuckDuckGo Welcome Flow Reset on Rotation … IX. CONCLUSION AND FUTURE WORK

The paper illustrates RotDroid’s ability to detect a DuckDuckGo onboarding reset caused by rotation, while acknowledging validity limitations and distinguishing its approach from prior GUI-testing methods. It concludes with reported bug detections and future plans for videocentric, orientation-sensitive applications.

  • B. DuckDuckGo Welcome Flow Reset on Rotation: RotDroid detected a DuckDuckGo onboarding bug in which rotating from the “Choose Your Browser” page to landscape reset the flow to its start page.The failure resulted from insufficient preservation of the current onboarding step during Android configuration changes.
  • VII. THREATS TO VALIDITY: The study’s internal validity may be affected by inaccuracies in synthesized defective data and reproduction bias from the partially unavailable DOC implementation.The authors manually audit generated samples and reuse corresponding-version APKs when available.
  • VII. THREATS TO VALIDITY: SPS preserves observable GUI state and interaction context but cannot guarantee preservation of hidden server-side state, caches, or external side effects.This limitation constrains what cross-orientation equivalence testing can establish.
  • VIII. RELATED WORK: Earlier mobile GUI-testing methods emphasized code coverage and crash detection, while newer approaches use reinforcement learning and visual methods to address non-crash functional defects.The related work traces a progression from script-based and stochastic/model-based testing toward intelligent exploration and computer vision.
  • VIII. RELATED WORK: Large Language Models and vision-language models support semantic input generation, task automation, grounded UI understanding, consistency checking, and bug detection, but general-purpose VLMs struggle with complex mobile interfaces.This motivates domain-specific modeling for the paper’s testing task.
  • VIII. RELATED WORK: Prior configuration-testing research mainly targets persistence, device-fragmentation, or screen-scaling issues and compares static portrait states rather than cross-orientation behavior.The paper positions RotDroid as addressing rotation-induced state-management and GUI failures beyond these settings.
  • IX. CONCLUSION AND FUTURE WORK: RotDroid combines UI Transition Graph modeling, SPS mutation, and RotVL-based cross-orientation checking, with RotBench supporting domain-specific RotVL fine-tuning.The framework detected 78 bugs in open-source apps and 22 in commercial apps.
  • IX. CONCLUSION AND FUTURE WORK: Future work will extend RotDroid to videocentric applications containing dynamic and orientation-sensitive content.This targets application types whose visual content changes with both time and device orientation.
Loading 2608.25425v1…