Beyond Code Translation: Agentic Android-to-HarmonyOS Migration

Beyond Code Translation: Agentic Android-to-HarmonyOS Migration Yinghang Ma∗ , Wuyang Dai∗ , Song Wang∗ , Filipe Cogo† , Zhen Ming (Jack) Jiang∗ ∗ York University, Toronto, Canada

arXiv:2611.11192v1 [cs.SE] 8 Nov 2026

{coppelia,ddai2002,wangsong,zmjiang}@yorku.ca † Queen’s University, Kingston, Canada filipe.cogo@queensu.ca

Abstract—Migrating Android applications to HarmonyOS is an important yet challenging software engineering task. Existing large language model (LLM)-based migration approaches primarily translate code at the method or file level, overlooking project-wide dependencies and workflow coordination. Moreover, ArkTS, the primary language for HarmonyOS, is relatively lowresource, and migrated applications often lack sufficient tests for reliable verification, making end-to-end migration errorprone. We present A2HTrans, an agentic framework for endto-end Android-to-HarmonyOS application migration. Rather than performing isolated code translation, A2HTrans decomposes applications into functionality-aware migration tasks, prioritizes them through dependency analysis, and orchestrates translation, validation, and iterative repair within a unified execution workflow. To improve migration reliability, A2HTrans employs a tool-augmented verification strategy that combines compilerbased syntax checking with LLM-based semantic validation and automated repair. We evaluate A2HTrans on 14 Android applications spanning diverse sizes and domains using Claude-Sonnet4.6 as the underlying migration model. Compared with Claude Code, A2HTrans preserves 8.3% more functional completeness, improves behavioral correctness by 8.0%, and reduces migration time by 28.8%. These results demonstrate that structured agentic execution substantially improves the reliability and efficiency of project-level cross-platform software migration.

I. I NTRODUCTION Mobile software ecosystems evolve rapidly, frequently requiring developers to migrate existing applications across platforms [1]. Since 2021, Huawei has begun manufacturing HarmonyOS-based phones instead of Android-based phones. To ensure a vibrant application ecosystem for users, it is therefore vital to migrate existing Android apps to HarmonyOS1 . Although Android and HarmonyOS share certain architectural concepts, they differ substantially in programming languages (i.e., Java/Kotlin vs. ArkTS), UI frameworks, permission models, application lifecycle management, APIs, and other features. Currently, migrating real-world Android applications to HarmonyOS is a challenging and labor-intensive engineering task, as developers must rely on a combination of manual interpretation of platform documentation, extensive code modifications, and only partially automated migration tools. Existing LLM-based code translation (e.g., TRANSAGENT [2], AlphaTrans [3], and Repoagent [4]) Yinghang Ma and Wuyang Dai contributed equally to this work. 1 https://appinchina.co/the-complete-guide-to-harmonyos-next/

primarily focuses on method-level code-to-code transformations, leaving higher-level application logic largely unaddressed. Building on this, Zeng et al. [5] recently analyzed translation bugs in LLM-based automatic migration from Android to iOS, highlighting the challenges of cross-platform application translation but focusing mainly on syntax errors in the translated code. In contrast, end-to-end translation of real-world mobile applications introduces additional challenges, including cross-platform semantic mismatches, UI layout differences, resource-handling conventions, and platform-specific configurations, making it a substantially more complex problem that remains largely unexplored. Motivated by these challenges, in this paper, we report on our experience building an LLM-based framework, called A2HTrans, that combines an agentic translation pipeline with model adaptation via fine-tuning, enabling end-to-end crossplatform migration of real-world mobile applications. Given an Android application, A2HTrans adopts an agentic translation workflow that iteratively performs planning, action, and verification across multiple stages. First, the framework analyzes the application structure to identify components and their dependencies, and plans the migration by decomposing the codebase into feature-oriented clusters of related components, classes, and methods. Based on this plan, A2HTrans uses a general-purpose LLM (e.g., Claude-Sonnet-4.5) to infer highlevel application features from each cluster and to guide feature-aware translation. The agent then executes translation actions and generates a valid ArkTS project scaffold and configuration. During this process, A2HTrans invokes the ArkTS compiler to detect syntax errors and iteratively corrects ArkTS-specific issues using a fine-tuned, domain-specific lightweight LLM (e.g., DeepSeek-16B). Finally, A2HTrans leverages the general-purpose LLM to verify the translated features by inspecting their implementations and checking alignment between the original Android application and the translated HarmonyOS application. When misalignments are detected, A2HTrans iteratively refines the translation. To finetune a domain-specific lightweight LLM, we construct a dataset comprising 1.7K ArkTS specification–code pairs derived from official HarmonyOS examples. This dataset enables the LLM to understand ArkTS-specific syntax, APIs, and coding conventions, enabling it to automatically detect and

correct ArkTS-specific syntax errors during the translation process. We evaluated A2HTrans on 14 real-world Android applications of varying size and complexity. To assess its effectiveness, we conducted a manual UI/behavior review using five 0–100 metrics: functional completeness, functional correctness, functional appropriateness, operability, and UI alignment with the original Android application. Scores were assigned by two reviewers and averaged to mitigate individual bias. In addition, we report translation time as a proxy for effort and use pre-repair build-error counts to characterize syntactic deployability prior to repair. We compare A2HTrans against two baselines: a basic LLM-based prompting approach and the Claude Code CLI [6]. The results show that A2HTrans improves migration quality while reducing translation time. Compared with Claude Code, A2HTrans increases functional completeness by 8.3%, functional correctness by 8.0%, functional appropriateness by 3.0%, UI operability by 5.3%, and UI alignment by 5.5%. It also reduces average translation time by 28.8%. We do not use token count as a primary efficiency metric because Claude Code and A2HTrans rely on different context-management and caching behaviors, making raw token counts not directly comparable. Overall, these results indicate that A2HTrans better preserves task-level functionality and behavior while requiring less translation time. This paper makes the following contributions: • We address ArkTS’s low-resource challenge by curating training data from official documentation, in the form of 1.7K ArkTS specification–code pairs. We demonstrate the usage of this data by fine-tuning LLMs to correct compiler-detected ArkTS syntax and API errors within our agentic migration workflow. • We propose A2HTrans, the first agentic framework for end-to-end migration of Android applications to HarmonyOS. We also demonstrate the superior performance of our approach, which performs feature-guided, dependency-aware translation across components and project configurations rather than method-level code-tocode translations. • We design a tool-augmented validation strategy for A2HTrans, i.e., compiler-based syntax checking with LLM-based semantic validation, showing that it significantly improves the correctness of translated ArkTS applications. • We conduct an empirical evaluation on 14 real-world Android projects. The results show that A2HTrans outperforms the Claude Code CLI baseline, achieving better preservation of application functionality, task-level behavior, and interface consistency in Android-to-HarmonyOS migration. The rest of this paper is organized as follows: Section II introduces the background of this work, Section III presents our multi-agent pipeline for Android-to-HarmonyOS migration, Section IV shows the settings of our case study, Section V presents the results, Section VI discusses the lessons learned

from translation issues, Section VII presents the threats to validity of this work, and Section VIII concludes this work. II. BACKGROUND AND R ELATED W ORK A. HarmonyOS and ArkTS HarmonyOS is a distributed operating system designed to run across smartphones, wearables, smart home devices, and in-vehicle platforms, supporting seamless cross-device collaboration [7]. Application development on HarmonyOS primarily relies on ArkTS, the platform’s official programming language. ArkTS builds upon TypeScript while introducing platform-specific extensions and language features specifically designed for cross-device and multi-platform application development [8]. A notable example is ArkUI, a declarative user interface framework that enables developers to define UI components through reactive data bindings, thereby simplifying interface construction and state management. Despite these benefits, ArkTS is a recently introduced language, with very limited publicly available data (e.g., code examples, documentation, and tutorials), posing challenges for developers and limiting the effectiveness of existing LLMs for code generation and translation. Recently, Wang et al. [9] proposed leveraging LLMs to automatically translate Android XML layouts into HarmonyOS ArkUI code, showing promising results for UI-level migration. However, their approach addresses only isolated aspects of migration, and UI translation alone is insufficient for real-world applications, where overall correctness depends on multiple platform-specific behaviors. B. Code Translation Code translation aims to convert source code from one programming language to another while preserving the original program’s functionality [10]. Traditional code translation approaches [11]–[14] primarily rely on rule-based techniques and syntax-directed transformation schemes [15]. While effective in limited settings, these methods often struggle to scale to complex software systems or to capture higher-level program semantics. More recently, LLMs have demonstrated strong capabilities in code translation. However, prior studies show that LLMs may introduce subtle semantic bugs due to incomplete contextual understanding or misinterpretation of languagespecific constructs [16]. These findings highlight the need for more advanced translation approaches that operate at the project level, incorporating contextual and structural information to reduce translation errors. Jana et al. [17] propose finetuning LLMs using compiler and symbolic-execution-based feedback to support translation across multiple programming languages, demonstrating the potential of feedback-driven LLM adaptation for improving translation correctness. Bairi et al. [18] introduce CodePlan, a task-agnostic framework for inter-repository coding tasks. Ibrahimzada et al. [19] proposed AlphaTrans, a neuro-symbolic approach to automate repository-level code translation. Additionally, systems such as RepoAgent [4], CodePlan [20], and TRANSAGENT [2]

Syntax Validation leverages fine-tuned LLMs to detect and correct ArkTS-specific syntax errors, and Step 6 : Semantic Validation further refines the translated code by aligning it with extracted features and validating semantic consistency. Stage3: Manual Verification. Finally, the translation results produced by A2HTrans are presented to developers, who can review, modify, and update the translated code. All developer actions during this process are recorded and can be leveraged to further fine-tune the LLMs, improving their ability to generate correct ArkTS code. A. Stage1: Fine-tuning LLMs Fig. 1: Overview of the proposed A2HTrans framework

explore repository-level code translation by integrating planning and multi-agent strategies to manage the complexities of larger codebases. These approaches, however, generally target mainstream programming languages such as Rust, C, and C++, and few have been applied to low-resource languages like ArkTS. Recently, Zeng et al. [5] manually analyzed the translation bugs in LLM-based automatic migration from Android to iOS, highlighting the challenges of cross-platform application translation for low-resource languages. Despite these advancements, the effectiveness and applicability of LLM-based approaches for mobile application migration, particularly across different platforms such as Android and HarmonyOS, remain largely unexplored. In this work, we investigate the capabilities and limitations of LLM-based agentic migration for mobile applications, using Androidto-HarmonyOS migration as a representative and practically significant case study. III. A PPROACH Figure 1 illustrates the architecture of A2HTrans, which consists of two main stages: LLM fine-tuning and Androidto-HarmonyOS migration. Stage1: LLM fine-tuning. This stage focuses on resolving syntax errors in ArkTS code generated by LLMs through finetuning a domain-specialized language model. This is motivated by our observation that general-purpose LLMs are ineffective at producing syntactically correct ArkTS code without targeted adaptation. Stage2: Agentic Android-to-HarmonyOS Migration. This stage is further decomposed into six steps. Step 1 : Project Structure Analysis examines the overall architecture of an Android project, collects its components, and identifies dependencies at the component, class, and method levels through static analysis. Step 2 : Feature Extraction summarizes highlevel application features by inferring the functionalities of these clusters using LLMs. Step 3 : Feature-Guided Code Translation prioritizes and translates code units while respecting dependencies based on the extracted features and their dependencies. Step 4 : ArkTS App Wrapper automatically generates a valid ArkTS project by creating the required configurations and scaffolding. After translation, Step 5 :

We fine-tune relatively lightweight LLMs (e.g., 7B-16B parameters) to enable efficient local deployment for improved speed and practicality, following prior industry practices [21]. Our goal is to develop specialized models to detect and correct syntax errors in LLM-generated ArkTS code. Due to the limited availability of high-quality ArkTS training data, we construct a carefully curated dataset of 1.7K specification–code pairs, extracted from the official ArkTS documentation and examples, to support fine-tuning. We adopt an instruction fine-tuning paradigm to train the specialized ArkTS-aware models. Each training instance is formulated as an instruction–response pair consisting of (i) a specification describing the intended functionality and (ii) the corresponding ArkTS code example, both of which are directly extracted from official ArkTS documents (e.g., ArkTS Cookbook, ArkTS Standard Library, ArkTS Specification, and ArkTS Tutorial). All of these documents are publicly available.2 During fine-tuning, the model learns to follow taskoriented instructions and internalize ArkTS-specific syntax rules and language constructs, rather than relying on explicit syntactic error signals. The models are fine-tuned using supervised learning, optimizing the likelihood of the reference ArkTS code conditioned on the specification. This instruction fine-tuning process enables the model to acquire domainspecific knowledge and serve as a lightweight validator and corrector when applied in tandem with other LLMs in the translation pipeline. Note that, in this paper, we currently rely solely on specification-code pairs extracted from the official ArkTS website for fine-tuning. In the future, user modifications and corrections made during the revision of translated code could also be collected and incorporated into the fine-tuning dataset, further improving the fine-tuned LLMs’ ability to detect and correct ArkTS syntax errors. B. Stage2: Agentic Android-to-HarmonyOS Migration 1) Project Structure Analysis: The first step in the Androidto-HarmonyOS migration is to analyze the Android project to be translated, creating a comprehensive code structure map that captures its architectural organization. It systematically decomposes the project into smaller, manageable units, i.e., components, classes, and methods, with static analysis. This 2 https://gitee.com/openharmony/arkcompiler runtime core/releases/tag/ ArkTS-spec-1.2.0-alpha-20250307

step also collects detailed dependency information at the component level, class level, and method level, with static dependency analysis, identifying how different parts of the system interact and depend on one another. These analyses provide the foundation for subsequent translation tasks, enabling A2HTrans to intelligently prioritize translation tasks. 2) Feature Extraction: This step uses a general-purpose LLM (e.g., Claude-Sonnet-4.5) to perform a bottom-up summarization of the source code to identify and describe the system’s functional features. It begins at the method level, where the intent of each function is inferred, capturing what a single method is designed to accomplish. These method-level summaries are then aggregated to the class level, providing a holistic understanding of what functionality each class delivers. Finally, the process extends to the component level, where multiple classes are integrated to represent higher-level subsystem responsibilities. For each level-up summarization step, we concatenate the summaries from the immediate lower level into a single prompt and ask the LLM to synthesize a higher-level summary. This hierarchical semantic summarization enables the system to map low-level implementation details to high-level functionalities, which serve as essential guidance for feature-aligned translation and validation in subsequent stages. Beyond code analysis, the module examines available project documentation (e.g., READMEs, release notes, and manual pages) to extract feature-related information from natural language descriptions, thereby improving the accuracy of feature understanding inferred from code. 3) Feature-Guided Code Translation: This step employs a feature-guided, dependency-prioritized approach to code translation. Features with low dependency are translated first, as translating dependent features too early can cause the LLM to hallucinate, leading to missing interfaces or misbehaviours. The prioritization algorithm is presented in Algorithm 1. Specifically, it begins by prioritizing features that involve the smallest number of components, as these are simpler and more self-contained. Within each feature, components with fewer classes are translated first to minimize interdependence. When a component contains multiple classes, the algorithm selects classes with the fewest dependencies, measured as the total number of other classes they depend on and the number of classes that depend on them. Here, a “dependency” is defined as an edge in the call graph. This ensures that classes with minimal interactions are processed first, reducing the risk of cascading errors during translation. Finally, within each class, method-level translations are ordered by their dependency levels. Once the translation order is determined, A2HTrans uses LLMs to translate the least dependent components, classes, or methods first to reduce the risk of cascading issues during translation. This hierarchical approach, from features to components, to classes, to methods, systematically reduces complexity and dependency propagation, enabling an incremental translation process.

Algorithm 1 Translation prioritization algorithm Require: Features, Dependencies Ensure: tor //TraversalOrder 1: F ← S ORT (F eatures, numberOf Components) ▷ Sort features by number of components (ascending) 2: tor ← [ ] 3: for all f eature ∈ F do 4: C ← G ET C OMPONENTS(f eature) 5: C ′ ← S ORT(C, numberOf Classes) ▷ Sort components by number of classes (ascending) 6: for all component ∈ C ′ do 7: K ← G ET C LASSES(component) 8: K ′ ← S ORT(K, classDependencyScore) ▷ Sort classes by dependency score (ascending) 9: for all class ∈ K ′ do 10: M ← G ET M ETHODS(class) 11: M ′ ← S ORT(M, methodDependencyScore) ▷ Sort methods by dependency score (ascending) 12: for all method ∈ M ′ do 13: A PPEND(tor, (f eature, component, class, method)) 14: end for 15: end for 16: end for 17: end for 18: return tor

4) ArkTS App Wrapper: This step leverages LLMs to integrate the translated code from the previous step into a complete ArkTS project scaffold. Specifically, it uses a predefined structural template representing a typical ArkTS application layout as a one-shot prompt for the LLM. The template provides organized placeholders for key components, including the UI layout, component lifecycle hooks, permission handlers, and event bindings, ensuring a consistent and modular framework. During the LLM-based code update phase, the model takes the wrapper template, translated code, and manifest files as input, analyzes each logical unit, such as UI definitions, event handlers, and business logic, and maps them to their corresponding placeholders. This process lets the LLM automatically fill in and update the necessary sections, producing a cohesive, runnable ArkTS application that follows its architecture and coding conventions. 5) Syntax Validation: In this step, the generated ArkTS code is systematically parsed and compiled using the official ArkTS compiler,3 which serves as an authoritative oracle for syntactic and semantic compliance. The compiler detects a wide range of syntax-related issues, such as incorrect or missing type annotations, absent semicolons, undeclared or improperly scoped variables, and incorrect usage of ArkTSspecific language constructs. When syntax errors are identified, the compiler-generated diagnostics are collected and paired with the corresponding code snippets that triggered the errors. This information is then fed back into the fine-tuned LLM described in Section III-A within a feedback-driven refinement loop. By explicitly grounding the model’s revision process in concrete compiler feedback, the LLM is guided to generate targeted fixes. This iterative validation-and-correction mechanism continues until the code successfully passes syntax checking or reaches a predefined iteration limit. In this study, we conducted 3 https://developer.huawei.com/consumer/en/arkcompiler/

up to three rounds of iterative refinement for each compilerdetected issue. If the errors could not be resolved, A2HTrans leaves them for human intervention. The maximum number of fix attempts was empirically determined to balance translation quality and generation overhead. 6) Semantic Validation and Refinement: This step focuses on ensuring that the generated ArkTS implementation faithfully preserves the original functionality of the source Android application. Rather than relying solely on syntactic validation, this stage explicitly targets semantic and behavioral equivalence between the original Android application and its ArkTS counterpart. To achieve this, we employ an LLM-based alignment checker, referred to as the LLM-as-a-Judge, to evaluate the consistency between the original Android application and its ArkTS counterpart. The LLM-as-a-Judge is provided with artifacts from both implementations, including natural language feature specifications extracted and relevant code structure. Based on these inputs, the model performs a comparative analysis to determine whether the translated ArkTS code faithfully realizes the original feature requirements. During evaluation, the LLM-as-a-Judge identifies potential discrepancies such as deviations in logic, missing or incorrectly mapped event bindings, altered permission behaviors, or incomplete UI state transitions. It produces structured feedback that highlights both the nature and location of detected inconsistencies, and may optionally assign a confidence or alignment score reflecting the degree of equivalence. This feedback is then used to guide subsequent translation refinements in an iterative loop. In this paper, if the alignment score falls below 80%, the generated code is refined using the LLM-as-a-Judge feedback until the threshold is met or a predefined iteration limit is reached, i.e., up to three rounds. C. Stage3: Manual Verification Finally, the translation results produced by A2HTrans are presented to developers for human-in-the-loop validation. Developers can inspect, execute, and test the generated ArkTS code, and perform necessary modifications, refinements, or completions to ensure correctness, functionality, and adherence to best practices. This stage serves as a quality assurance step to catch subtle issues that may not be resolved automatically. Importantly, all developer interactions, such as edits, corrections, feedback, and acceptance decisions, are systematically logged. These interaction traces are then curated into highquality supervision signals and can be leveraged to iteratively fine-tune the underlying LLMs in the future. IV. C ASE S TUDY E VALUATION A. Research Questions To systematically evaluate the capabilities and effectiveness of our approach, we focus on two key aspects of Android-toHarmonyOS migration. RQ1: How does fine-tuning on ArkTS specification-code pairs improve translation accuracy?

RQ2: How effectively does A2HTrans migrate Android projects to HarmonyOS? In RQ1, we focus on the impact of fine-tuned LLMs with a relatively small number of parameters (e.g., 7B–16B) on ArkTS code generation, examining improvements in translation accuracy and reductions in syntax errors. In RQ2, we evaluate the overall effectiveness of A2HTrans in migrating Android projects to HarmonyOS, compared to two baselines. B. Experiment Data 1) Data For Fine-Tuning: All fine-tuning data used in this study were sourced exclusively from official HarmonyOS ArkTS documentation. We aggregated materials from four canonical sources: ArkTS Cookbook, ArkTS Standard Library, ArkTS Specification, and ArkTS Tutorial. All of these documents are publicly available online (as discussed in Section III-A). These sources constitute the most authoritative references provided by the platform vendor and comprehensively cover standard library definitions, core language semantics, idiomatic usage patterns, and pedagogical examples. To convert these documents into a supervised fine-tuning dataset, we first develop an automated script to extract example code embedded in the official materials and align each code snippet with its corresponding natural-language explanation provided in the documents. For each documented API, language construct, or usage scenario, the associated textual description typically specifies the function purpose, expected behavior, parameter semantics, and usage constraints, and is treated as the model input, while the authoritative ArkTS implementation provided in the documentation is used as the output. This process yields structured input–output pairs that map natural-language described functionalities directly to their canonical ArkTS reference implementations, enabling the model to learn how formal semantic descriptions translate into executable ArkTS code. To ensure the quality and correctness of the automatically extracted data, three of the authors collaboratively reviewed every data instance to verify semantic alignment between descriptions and code and to remove noisy, incomplete, or ambiguous examples. The final dataset consists of 1,752 high-quality pairs. 2) Testing Data For Fine-Tuning: To evaluate the performance of our fine-tuned LLMs, we manually curate a dataset consisting of 200 standalone functions sourced from the AVATAR dataset [22], which has been widely adopted for benchmarking function-level program translation between Java and Python [3], [16], [23], [24]. AVATAR is a largescale collection of 9,515 programming problems along with their solutions in both Java and Python. The dataset is compiled from competitive programming platforms, online coding platforms, and open-source repositories, and includes unit tests for 250 examples, enabling systematic evaluation of functional correctness. For our experiments, we select these Java programs that include unit tests and convert them into ArkTS translation tasks, preserving and adapting the unit tests to verify correctness.

TABLE I: Overview of the Android projects used in our study. Android Project

Description

Camera-picker Network-performance-timing Video-play To Do List Materialistic LeafPic AndOTP Zxing Omni-Notes Osmand OpenTracks Etar-Calendar AntennaPod Open-keychain

Camera management Network performance Video playback To-do list News reader Photo gallery OTP manager Barcode scanner Note manager Offline navigation Activity tracking Calendar manager Podcast manager Key management

3) Android Projects for Translation: To evaluate the effectiveness of our approach for translating Android applications to HarmonyOS, we curate a diverse set of ten Android applications across multiple domains and usage scenarios. These projects were selected to reflect a broad range of real-world mobile applications while remaining tractable for detailed manual inspection and analysis. Specifically, we prioritized repositories covering different application domains, such as todo list applications, media players, and utility apps, to ensure that our evaluation captures a diverse set of functionalities and interaction patterns common in Android apps. Importantly, we excluded projects that heavily depend on platform-specific third-party libraries, such as Google Play Services, to minimize external confounding factors and focus the evaluation on core application logic and platform-dependent code. This selection strategy enables a more accurate assessment of the capabilities and limitations of A2HTrans in handling essential mobile development tasks. In addition, we excluded projects implemented in Kotlin, as our current approach targets Javabased Android applications. Table I summarizes the key characteristics of the selected Android applications.

#Java

#Classes

#Packages

#Methods

#LOCs

5 6 13 13 131 139 71 517 204 172 276 147 609 525

5 6 11 13 131 137 70 509 200 353 276 141 593 521

2 1 4 1 8 25 12 48 32 17 31 17 106 61

6 34 123 113 1,686 1,705 930 5,764 1,695 4,297 2,979 5,531 6,494 6,623

405 506 1,278 2,005 28,303 32,342 41,761 48,525 49,728 60,227 64,412 97,435 114,012 130,947

2) LLMs for Running A2HTrans: We experiment with four LLMs, i.e., GPT-4.1, Claude-Sonnet-4.5, Qwen3-VL-235BA22B-Instruct, and Gemini-2.5-Flash, provided by OpenRouter7 , to drive our agentic Android-to-ArkTS migration pipeline. Note that we do not compare these models using the full end-to-end translation workflow. This decision is primarily motivated by practical considerations: the complete pipeline requires a large number of LLM API calls and substantial human effort to validate and manually refine the final translated applications, making it difficult to conduct fair and reproducible comparisons across models. Instead, we adopt a simplified end-to-end evaluation setting, focusing on direct Java-to-ArkTS translation on the curated test dataset (See Section IV-B3). This controlled setup allows us to compare models under identical conditions while minimizing external variability introduced by iterative refinement and human intervention. The results of this comparison are then used to select the most suitable model to drive our agentic translation approach. For all the models, we set the temperature set to zero to ensure a more deterministic and reliable response [25]. D. Evaluation Metrics

C. Base LLMs 1) LLMs for Fine-tuning: To fine-tune models for automated syntax error correction, we select three instructiontuned large language models specialized for code understanding and generation, i.e., Qwen2.5-Coder-7B-Instruct4 , DeepSeek-Coder-V2-Lite-16B-Instruct5 , and CodeLLaMA13B-Instruct6 . These models were chosen to represent diverse architectural designs and parameter scales, allowing us to examine the effectiveness of syntax repair across different model capacities. All three models are fine-tuned using the same dataset and training protocol to ensure fair comparisons across models. 4 https://huggingface.co/Qwen/Qwen2.5-Coder-7B-Instruct

To evaluate the performance of fine-tuned LLMs, we follow prior work and adopt the P ass@1 metric [26]. Pass@1 quantifies function-level translation accuracy as the proportion of generated translations that pass all unit tests on the first attempt, thereby capturing the model’s precision and reliability in direct Java-to-ArkTS code translation. To comprehensively assess the agentic translation framework, we employ a human-in-the-loop evaluation protocol. In this process, developers manually inspect the translated applications and assess the quality of their user interfaces and behavioral correctness across the following dimensions: • F unctionality Completeness: This metric measures the extent to which application features are migrated from the Android project to the ArkTS project, regardless of whether they are fully or partially functional. It evaluates feature-level coverage from a user perspective, focusing

5 https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct 6 https://huggingface.co/codellama/CodeLlama-13b-Instruct-hf

7 https://openrouter.ai/

All metrics except T ime Cost are scored on a scale ranging from 0 to 100, where a higher score indicates better performance with respect to the evaluated dimension. We incorporate manual UI and behavior review because automated metrics alone cannot capture the true quality of migrated applications. Many failures are semantic rather than syntactic: apps may compile and appear complete, yet fail to support core user tasks due to broken navigation, missing functionality, or inconsistent behavior. Automated metrics (e.g., file counts or compile success) may overestimate the prevalence of such cases. Manual inspection allows us to assess end-toend usability, including workflow coherence and meaningful interaction, complementing automated measures. E. Baseline Approach In this paper, we use a basic LLM-based prompting approach and the Claude Code CLI [6] as the baselines to evaluate the performance of A2HTrans. To ensure a fair comparison,

Lightweight Models (Base vs FT) 0.8 Pass@1

on whether key features are present in the migrated application. A feature receives a high score if its primary entry points and essential interaction flows are implemented; it receives a low score if it is missing, only stubbed, or significantly reduced in scope. • F unctionality Correctness: This metric evaluates whether the migrated functionality is correctly implemented. It assesses whether a feature, once triggered, produces the expected outcomes, state transitions, and outputs, consistent with the original Android behavior when an equivalent or appropriately adapted ArkTS implementation is feasible. • U I Operability: This metric evaluates how easily users can discover, navigate, and operate the migrated application. Reviewers assess factors such as UI responsiveness, clarity of navigation, consistency of controls, backnavigation behavior, and whether the interaction flow is intuitive without inspecting the underlying code. A high score indicates a smooth, coherent, and user-friendly experience with well-integrated features, while a low score reflects issues such as confusing navigation, unresponsive elements, dead-end pages, or broken interactions. • U I Alignment: This metric measures how closely the migrated ArkTS application’s UI aligns with the original Android application’s user-visible interface design. It compares layout structure, information hierarchy, visual organization, interaction style, and overall presentation. A high score indicates that the migrated UI preserves the original screen organization and provides a similar user experience; a low score indicates significant visual divergence, missing interface regions, inconsistent layout behavior, or a substantially different interaction experience. • T ime Cost: We also record the time required by each approach to translate an Android project into ArkTS, measured from the start of translation to the generation of a deployable project.

0.67

0.7

0.68

0.6 0.36

0.4 0.2

0.21

0

0.25

0.39

0.32

0.3

0.22

B .1 3B 2.5 4.5 en3 16B .5-7 T-4 deiniQw A-1 ekGP lau em aM pSe C G L e e eL D Cod Base Fine-Tuned

en2

Qw

Fig. 2: Performance of Base and Fine-Tuned Models on Javato-ArkTS Translation. we use the same underlying large language model, ClaudeSonnet-4.5, to drive A2HTrans, the prompt-based approach, and Claude Code CLI. For the prompting baseline, we design structured prompts that explicitly describe the Android-to-ArkTS migration task. The prompts guide the model to understand the source Android application, including its features, user interfaces, components, classes, and functionalities, and then generate the corresponding ArkTS implementation. They also instruct the model to preserve the original application functionality and UI behavior during migration. To ensure comparability with A2HTrans, we further adopt a similar verification and refinement loop, in which the generated ArkTS code is compiled, compiler errors are collected, and the model is prompted to iteratively revise the implementation until the code passes compilation. For the Claude Code CLI baseline, we implement a taskspecific skill that performs agentic Android-to-ArkTS migration using its built-in tools. The skill analyzes the Android project structure and incrementally translates it into ArkTS components and HarmonyOS APIs. It also adopts a verification–refinement loop, where generated ArkTS code is compiled, errors are collected, and the model iteratively revises the code until successful compilation. V. R ESULT A NALYSIS A. RQ1: Effectiveness of Fine-Tuned LLMs Approach: We adopt a parameter-efficient LoRA-based strategy to fine-tune the three selected models for syntax error correction (Section IV-C1). LoRA (Low-Rank Adaptation) updates only a subset of model parameters while keeping the majority of the pretrained weights frozen. This approach significantly reduces GPU memory usage and training time while enabling the model to learn task-specific behaviors. Following existing work [27], in our experiments, we adopt low-rank adaptation matrices with a rank of 16 (r = 16) and a scaling factor of 32 (lora alpha = 32). To prevent overfitting and improve generalization, a dropout rate of 0.05 (lora dropout = 0.05) is applied to the adaptation weights. All fine-tuning experiments are conducted on a single NVIDIA A100 SXM4 GPU. We fine-tune the models using the dataset described in Section IV-B1, and subsequently evaluate their

performance on the Java-to-ArkTS translation dataset introduced in Section IV-B2. To assess translation effectiveness, we adopt the pass@1 metric. Results: The detailed pass@1 of the base models and the fine-tuned models are shown in Fig. 2. As we can see, fine-tuning on this specific translation task significantly boosts performance: Qwen2.5-7B-FT, CodeLLaMA-13B-FT, and DeepSeek-16B-FT achieve pass@1 scores of 0.67, 0.68, and 0.70, respectively, representing roughly a threefold improvement over their base counterparts. In addition, the finetuned models substantially outperform the LLMs with a larger parameter size, i.e., GPT-4.1 (0.36), Claude-Sonnet-4.5 (0.33), Qwen-3 (0.32), and Gemini-2.5 (0.30), demonstrating the critical importance of fine-tuning for low-resource programming language translation tasks. Answer to RQ1: Experimental results indicate that, for Java-to-ArkTS translation, careful task-specific fine-tuning can significantly improve LLM performance in generating correct and syntactically valid ArkTS code.

B. RQ2: Effectiveness of A2HTrans Approach: Based on our preliminary experimental results in RQ1 (see Section V-A), we select the fine-tuned DeepSeek16B-Instruct (DeepSeek-16B-FT) model for the syntax validation stage, as it achieves the highest pass@1 performance and demonstrates strong robustness in generating syntactically correct ArkTS code. In this stage, DeepSeek-16B-FT primarily detects and corrects syntax errors in the translated ArkTS programs. For the agentic migration process from Android applications to their ArkTS counterparts, we used Claude-Sonnet-4.5 as the driving model of A2HTrans for the Android-to-ArkTS Migration. Claude-Sonnet-4.5 is chosen for its strong general reasoning and planning capabilities, which are essential for coordinating multi-step translation actions, such as analyzing Android project structures, mapping application components, and orchestrating iterative interactions among translation, validation, and refinement modules. It also outperforms GPT-4.1, Qwen-3, and Gemini-2.5 in the Javato-ArkTs translation task, as shown in Figure 2. For a fair comparison, we also use Claude Sonnet 4.5 for both baselines, i.e., the prompt-based approach and the Claude Code CLI. We experiment with the 14 projects using the metrics F unctionality Completeness, F unctionality Correctness, U I Operability, and U I Alignment to measure the effectiveness of A2HTrans. To obtain reliable evaluations, two authors manually reviewed the translations generated by A2HTrans and two baseline approaches. Each participant independently examines the translated results and assigns scores for all four metrics based on predefined criteria. The final score for each metric is computed by averaging the ratings across the three participants, thereby reducing individual bias and improving evaluation robustness.

Results: Table II presents a comparison of A2HTrans with the prompt-based approach and Claude Code across functionality, UI quality, and time cost. Overall, A2HTrans consistently achieves the best performance across all metrics. First, regarding functionality, A2HTrans achieves the highest average scores across all three functionality-oriented metrics: functional completeness, functional correctness, and functional appropriateness, with scores of 83.9%, 80.0%, and 85.9%, respectively. In comparison, the prompt-based approach achieves 68.2%, 74.8%, and 73.2%, while Claude Code achieves 77.5%, 74.1%, and 83.4%. These results indicate that A2HTrans not only preserves a larger portion of the expected functionality, but also better maintains correct behavior and task-level appropriateness in the migrated HarmonyOS applications. Second, regarding UI quality, A2HTrans achieves the highest average scores on both UI-related metrics, with 88.2% in operability and 88.9% in UI alignment. In comparison, the prompt-based approach achieves 78.8% and 77.3%, while Claude Code achieves 83.8% and 84.3%. These results show that A2HTrans better preserves user interaction quality and interface consistency with the original Android applications. Third, regarding time cost, A2HTrans is the most efficient method, with an average runtime of 11.06 minutes. In comparison, the promptbased approach requires 125.49 minutes, while Claude Code requires 15.53 minutes. This indicates that A2HTrans improves migration quality while also reducing translation time. Figure 3 presents a case study illustrating UI-level differences between A2HTrans and the two baselines. In the original Android app, the startup flow exposes several key actions on the empty-token screen, including a sorting menu and three add-token options: scanning a QR code, importing a QR image, and manual entry. The prompt-based approach reproduces the token list UI but fails to capture these essential interaction structures. Claude Code reconstructs the overall token-list interface and includes a sorting menu; however, it compresses the add-token workflow into a limited manual-entry option, failing to fully recover the original entry actions. In contrast, A2HTrans preserves the empty-state structure while exposing all three token-entry options in a manner closely aligned with the original Android design. This case highlights the importance of manual, behavior-level evaluation: although all generated apps present a plausible empty token list, they differ substantially in whether the startup screen supports the full range of task-level interactions expected by the original application. We provide a comparison of the UIs of applications translated by A2HTrans and the two baselines for each of the 14 projects in our replication package8 .

8 https://anonymous.4open.science/r/A2HTrans-9F33/README.md

TABLE II: Comparison of A2HTrans with the two baselines. Comp, Corr, Appr, Oper, and Align denote functional completeness, functional correctness, functional appropriateness, operability, and UI alignment, respectively. ‘T’ is the time cost. Project

Prompt-based Comp

Claude Code

Corr Appr Oper Align T(min) Comp

camera-picker-master 100.0 100.0 100.0 100.0 100.0 NetworkPerformanceTiming 100.0 100.0 100.0 100.0 100.0 videoplayback 82.5 77.5 82.5 92.5 92.5 To Do List-master 97.5 97.5 95.0 95.0 92.5 materialistic 87.5 90.0 90.0 92.5 90.0 LeafPic 45.0 62.5 62.5 60.0 62.5 andOTP 50.0 70.0 55.0 80.0 55.0 zxing 57.5 67.5 55.0 67.5 67.5 Omni-Notes 70.0 70.0 77.5 75.0 77.5 Osmand 50.0 55.0 50.0 60.0 62.5 OpenTracks 52.5 60.0 65.0 75.0 75.0 Etar-Calendar 70.0 72.5 85.0 85.0 90.0 AntennaPod 40.0 70.0 50.0 57.5 47.5 open-keychain 52.5 55.0 57.5 62.5 70.0 Avg.

68.2

74.8

73.2

78.8

A2HTrans

Corr Appr Oper Align T(min) Comp

3.95 100.0 100.0 100.0 100.0 100.0 6.23 100.0 100.0 100.0 100.0 100.0 16.31 87.5 82.5 85.0 90.0 92.5 18.09 87.5 82.5 90.0 92.5 90.0 148.62 47.5 45.0 57.5 50.0 62.5 150.88 75.0 72.5 82.5 75.0 72.5 89.29 72.5 67.5 87.5 90.0 82.5 169.13 65.0 67.5 82.5 87.5 85.0 171.24 80.0 65.0 82.5 80.0 80.0 264.75 82.5 77.5 85.0 80.0 85.0 182.90 70.0 72.5 70.0 87.5 80.0 128.74 70.0 47.5 72.5 72.5 80.0 192.12 65.0 72.5 82.5 80.0 75.0 214.65 82.5 85.0 90.0 87.5 95.0

77.3 125.49

77.5

74.1

83.4

83.8

84.3

Corr Appr Oper Align T(min)

7.27 100.0 100.0 100.0 100.0 100.0 7.91 100.0 100.0 100.0 100.0 100.0 12.03 87.5 82.5 85.0 95.0 92.5 6.69 92.5 95.0 95.0 97.5 97.5 16.42 92.5 95.0 92.5 95.0 92.5 16.71 82.5 75.0 80.0 77.5 87.5 24.96 85.0 77.5 87.5 92.5 82.5 16.26 75.0 65.0 82.5 82.5 85.0 14.57 80.0 67.5 80.0 80.0 87.5 20.13 72.5 70.0 77.5 77.5 80.0 17.03 80.0 77.5 75.0 87.5 92.5 17.30 75.0 62.5 85.0 80.0 90.0 16.49 72.5 72.5 82.5 85.0 70.0 23.69 80.0 80.0 80.0 85.0 87.5 15.53

83.9

80.0

85.9

88.2

88.9

3.00 3.21 4.22 4.89 10.09 10.01 12.36 11.86 11.46 20.27 11.79 19.87 18.43 13.41 11.06

Fig. 3: Case study on migrating the AND OTP application. From left to right: the original Android app, a prompt-based baseline, Claude Code, and A2HTrans. The prompt-based baseline misses key interactions, and Claude Code restores the UI only partially while failing to preserve essential workflows. A2HTrans best preserves both the interface structure and user interactions, resulting in higher behavioral fidelity.

Answer to RQ2: A2HTrans outperforms both baselines across all metrics, achieving higher functionality completeness and correctness, superior UI operability and alignment, and the lowest time cost. It produces more accurate and consistent translations while being significantly more efficient than the prompt-based approach and Claude Code, demonstrating overall effectiveness and practicality. VI. L ESSON L EARNED FROM T RANSLATION I SSUES To better understand why feature preservation remains challenging and what we can learn from these issues for future cross-platform translation techniques and tool design, we analyzed translation issues in the generated ArkTS projects using an open-coding procedure. Two authors independently

inspected each A2HTrans output across multiple evidence sources, including the generated ArkTS source code, runtime application behavior, and repair records (e.g., documented build failures). Disagreements were discussed and resolved through consensus. The authors first assigned descriptive labels to observed issues and iteratively consolidated recurring labels into a fixed taxonomy. The final taxonomy captures failures at different layers of the translation process: scope contraction refers to reduced feature coverage in the migrated app; build scaffold constraint captures incomplete or incorrect project configuration, metadata, or dependency structure; platform API gap includes unsupported Android-specific mechanisms (e.g., intents, services, widgets, lifecycle handling); data persistence gap reflects missing storage components such as databases,

TABLE III: Overall quality-issue categories in agent-based Android-to-ArkTS migration. Quality-Issue Category

Count

Share

Scope contraction Complex Android UI pattern Other feature omission Media/hardware/external I/O Android ecosystem dependency Security/crypto/trust layer Data sync/persistence Build scaffold constraint Unknown or unclear Platform API gap Data persistence gap Hardware/sensor/external I/O gap Shallow UI shell Third-party dependency gap Routing/startup gap

194 69 37 26 18 14 11 166 89 76 71 60 38 36 18

25.9% 35.6% 19.1% 13.4% 9.3% 7.2% 5.7% 22.2% 11.9% 10.2% 9.5% 8.0% 5.1% 4.8% 2.4%

Total

748

100.0%

repositories, caches, preferences, or synchronization logic; hardware/sensor gap involves incomplete integrations with components like camera, GPS, media store, file pickers, or NFC; shallow UI shell denotes UI elements that exist structurally but lack meaningful or correct behavior; third-party dependency gap refers to missing or incompatible external libraries; and routing/startup gap captures issues in entry points, page registration, or navigation flows. After establishing the taxonomy, each identified issue was assigned a single primary category to enable consistent analysis. Table III reports the resulting quality-issue distribution by issue count. In total, 748 translation issues were observed and analyzed across the migrated projects. The most prevalent category is scope contraction (194 issues, 25.9%), indicating that many translated apps lose important functionality, particularly complex UI patterns and feature completeness. This is followed by build scaffold constraint (166 issues, 22.2%), highlighting difficulties in reconstructing correct project configurations and dependencies. platform API gap (76 issues, 10.2%) and data persistence gap (71 issues, 9.5%) further show challenges in handling Android-specific mechanisms and maintaining application state. Issues related to hardware/sensor/external I/O (60 issues, 8.0%) also remain significant. At the UI level, shallow UI shell (38 issues, 5.1%) suggests that interfaces are often superficially generated without full functionality. Third-party dependency gap (36 issues, 4.8%) and routing/startup gap (18 issues, 2.4%) are less frequent but still impactful, affecting app completeness and usability. Implications: These quality issues suggest that Androidto-ArkTS migration cannot be treated as a direct code translation problem. Many failures arise because Android/Java and HarmonyOS/ArkTS differ fundamentally in application architecture, not just syntax. Android applications distribute behavior across UI components, lifecycle callbacks, platform services, build configurations, resources, persistence layers, hardware interfaces, and third-party libraries. In contrast, HarmonyOS relies on a different project model, ArkUI’s

declarative component hierarchy, JSON5-based configuration, and distinct routing and lifecycle mechanisms. As a result, direct translation may preserve code fragments or surface-level UI, yet still lose feature scope, structural integrity, platform integration, or complex runtime behavior. This explains why migrated applications may appear plausible but fail to support complete task-level functionality. To improve migration quality, future systems should treat migration as an architectural adaptation problem rather than a file-level translation task. A practical workflow should first recover the source application’s feature intent and dependency structure, then map each feature to an appropriate HarmonyOS design before generating ArkTS code. Platform-knowledge retrieval can help identify equivalent HarmonyOS APIs or determine when no direct replacement exists, while dependency feasibility checks can prevent hallucinated libraries or unsupported Android components. Also, the lack of automated approaches for evaluating applications across different versions calls for more robust and standardized evaluation frameworks. In practice, it remains difficult to systematically compare multiple translated versions of an app in terms of functionality, behavior, and UI consistency without relying on manual inspection. This limits scalability and reproducibility. Future work should explore automated testing, interactionbased evaluation, and benchmark suites that can capture tasklevel behavior, state transitions, and user workflows across versions, enabling more consistent and scalable assessment of migration quality. VII. T HREATS TO VALIDITY We evaluate 14 real-world Android applications spanning different domains, sizes, and architectural patterns, which improves diversity. However, this sample may still not fully represent the broader Android app ecosystem, particularly large-scale industrial systems, highly specialized domains, or apps with complex backend integrations. In addition, our results depend on the specific LLMs and tool configurations used in this study. Different base models, future model updates, or alternative prompting, translation, and repair strategies may yield different outcomes. Therefore, while our findings indicate strong performance, they may not generalize uniformly across all settings. The fine-tuning dataset consists exclusively of publicly available ArkTS examples from official documentation. Although these sources are authoritative, they may not capture the full diversity and complexity of real-world ArkTS development, potentially limiting the representativeness of the learned semantics. Furthermore, our evaluation relies on manual assessments conducted by three developers with experience in both Android and ArkTS. While we mitigate individual bias through multiple reviewers and score averaging, some degree of subjectivity remains. VIII. C ONCLUSION In this paper, we presented A2HTrans, an agentic framework for migrating Android applications to HarmonyOS/ArkTS

through feature-guided analysis, project-level reconstruction, and ArkTS-specific repair. Evaluation on 14 real-world Android applications shows that A2HTrans effectively supports the automatic migration of Android applications to HarmonyOS. Compared to Claude Code, A2HTrans preserves 8.3% more functional completeness and improves behavioral correctness by 8.0%, while reducing translation time by 28.8%. Our analysis of quality issues shows that the primary challenge lies not in isolated syntax translation, but in the architectural mismatch between Android and HarmonyOS. This suggests that effective mobile application migration requires platform-aware reconstruction and validation, rather than relying solely on LLM-based code generation. R EFERENCES [1] A. Ribeiro and A. R. Da Silva, “Survey on cross-platforms and languages for mobile apps,” in 2012 Eighth International Conference on the Quality of Information and Communications Technology, pp. 255–260, Ieee, 2012. [2] X. Liang and P. Wang, “Transagent: An llm-based multi-agent system for code translation,” in Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP), pp. 456–467, Association for Computational Linguistics, 2023. [3] A. R. Ibrahimzada, K. Ke, M. Pawagi, M. S. Abid, R. Pan, S. Sinha, and R. Jabbarvand, “Alphatrans: A neuro-symbolic compositional approach for repository-level code translation and validation,” Proceedings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 2454–2476, 2025. [4] Q. Luo, Y. Ye, S. Liang, Z. Zhang, Y. Qin, Y. Lu, Y. Wu, X. Cong, Y. Lin, Y. Zhang, et al., “Repoagent: An llm-powered open-source framework for repository-level code documentation generation,” arXiv preprint arXiv:2402.16667, 2024. [5] Z. Zeng, K. K. Shahandashti, A. B. Belle, S. Wang, Z. Ming, et al., “A pilot study on llm-based agentic translation from android to ios: Pitfalls and insights,” arXiv preprint arXiv:2507.16037, 2025. [6] “Claude code.” https://www.claude.com/product/claude-code, 2025. Accessed: 2025-12-12. [7] L. Li, X. Gao, H. Sun, C. Hu, C. Sun, H. Wang, H. Cai, T. Su, X. Luo, T. Bissyande, et al., “Software engineering for openharmony: A research roadmap,” ACM Computing Surveys, vol. 58, no. 2, pp. 1–36, 2025. [8] M. C. Aytekin, F. G. Yılmaz, and M. U. Demirezen, “Automating code generation for a new ecosystem: establishing baselines with large language model based code generation for arkts and harmonyos,” Automated Software Engineering, vol. 33, no. 2, p. 59, 2026. [9] C. Wang, L. Gong, Y. Huang, D. Cui, and M. Wei, “A2h: A ui converter from android to harmonyos platform,” arXiv e-prints, pp. arXiv–2412, 2024. [10] L. Xia, B. Hua, and Z. Peng, “An empirical study of c to rust transpilers,” School of Software Engineering, University of Science and Technology of China, and Suzhou Institute for Advanced Research, University of Science and Technology of China-04/27, 2023. [11] “C2rust,” 2018. [12] “Sharpen - automated java-¿c# coversion,” 2023.

[13] H. D. Phan, A. T. Nguyen, T. D. Nguyen, and T. N. Nguyen, “Statistical migration of api usages,” in 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C), pp. 47–50, IEEE, 2017. [14] R. Pawlak, M. Monperrus, N. Petitprez, C. Noguera, and L. Seinturier, “Spoon: A library for implementing analyses and transformations of java source code,” Software: Practice and Experience, vol. 46, no. 9, pp. 1155–1179, 2016. [15] J. Hong, “Improving automatic c-to-rust translation with static analysis,” in 2023 IEEE/ACM 45th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion), pp. 273–277, IEEE, 2023. [16] R. Pan, A. R. Ibrahimzada, R. Krishna, D. Sankar, L. P. Wassi, M. Merler, B. Sobolev, R. Pavuluri, S. Sinha, and R. Jabbarvand, “Lost in translation: A study of bugs introduced by large language models while translating code,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pp. 1–13, 2024. [17] P. Jana, P. Jha, H. Ju, G. Kishore, A. Mahajan, and V. Ganesh, “Cotran: An llm-based code translator using reinforcement learning with feedback from compiler and symbolic execution,” in ECAI 2024, pp. 4011–4018, IOS Press, 2024. [18] R. Bairi, A. Sonwane, A. Kanade, A. Iyer, S. Parthasarathy, S. Rajamani, B. Ashok, and S. Shet, “Codeplan: Repository-level coding using llms and planning,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 675–698, 2024. [19] A. R. Ibrahimzada, K. Ke, M. Pawagi, M. S. Abid, R. Pan, S. Sinha, and R. Jabbarvand, “Alphatrans: A neuro-symbolic compositional approach for repository-level code translation and validation,” arXiv preprint arXiv:2410.24117, 2024. [20] A. Jain, Y. Hu, D. Zhang, P. Xu, and D. Lin, “Codeplan: Repositorylevel coding using llms and planning,” arXiv preprint arXiv:2307.23456, 2023. [21] V. Murali, C. Maddila, I. Ahmad, M. Bolin, D. Cheng, N. Ghorbani, R. Fernandez, N. Nagappan, and P. C. Rigby, “Ai-assisted code authoring at scale: Fine-tuning, deploying, and mixed methods evaluation,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 1066–1085, 2024. [22] W. Ahmad, M. G. R. Tushar, S. Chakraborty, and K.-W. Chang, “Avatar: A parallel corpus for java-python program translation,” in Findings of the Association for Computational Linguistics: ACL 2023, pp. 2268–2281, 2023. [23] Z. Yuan, W. Chen, H. Wang, K. Yu, X. Peng, and Y. Lou, “Transagent: An llm-based multi-agent system for code translation,” arXiv preprint arXiv:2409.19894, 2024. [24] F. Rabbi, S. K. Saha, T. M. T. Pham, S. Wang, and J. Yang, “Babelcoder: Agentic code translation with specification alignment,” arXiv preprint arXiv:2512.06902, 2025. [25] J. Shin, N. S. Harzevili, R. Aleithan, H. Hemmati, and S. Wang, “Retrieval-augmented test generation: How far are we?,” arXiv preprint arXiv:2409.12682, 2024. [26] M. Chen, J. Tworek, H. Jun, Q. Yuan, et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021. [27] M. Weyssow, X. Zhou, K. Kim, D. Lo, and H. Sahraoui, “Exploring parameter-efficient fine-tuning techniques for code generation with large language models,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 7, pp. 1–25, 2025.

Related documents

• Porting Declarative UI to HarmonyOS: A Heuristic-guided Approach for lightweight LLMs#1342518
• Scoped Verification for Reliable Long-Horizon Agentic Context Evolution under Distribution Shift#1049916
• VeriGRAG: Enhancing LLM-Based Verilog Code Generation with Structure-Aware Soft Prompts#1388305
• Software Engineering LLMs: Why We Need Them and How Software Engineering Helps Build Them#1456674
• OpenPhone: Mobile Agentic Foundation Models#1200806