DEIA: Evidence-Grounded Crash Repair with Change-Aware Test Design for HarmonyOS ArkTS

arXiv:2611.14064v1 [cs.SE] 10 Nov 2026

DEIA: Evidence-Grounded Crash Repair with Change-Aware Test Design for HarmonyOS ArkTS XUHUI LU, Beihang University, China ZHIHAO LIU, Beihang University, China XIAOKE FANG, Beihang University, China YUHUAN FAN, Beihang University, China YANZHE TANG, Beihang University, China XIAOHUI WAN, Suzhou Aerospace Information Research Institute, China XIAOYU WU, Huawei Technologies Co., Ltd., China ZHENG ZHENG∗ , Beihang University, China Mobile crash repair requires more than identifying a source edit. Developers must establish how the edit relates to the reported failure and whether the modified application can be built, launched, and exercised without disrupting valid behavior. In HarmonyOS applications, this assessment also depends on platform-specific packaging and runtime execution. To address this need, we present DEIA, an evidence-grounded workflow for HarmonyOS crash repair. DEIA constructs a bounded source-evidence package, uses a large language model to propose content-anchored edits, and relies on a deterministic writer to materialize and check the patch. It derives fail-to-pass (F2P) obligations from the reported fault and pass-to-pass (P2P) obligations from the potential impact of the patch. A stage-level ledger links the patch, test obligations, runtime observations, and candidate-generation cost. We evaluate DEIA on 30 repair tasks from 24 HarmonyOS applications and compare it with an OpenHands-based workflow on 29 matched tasks. DEIA’s first-added-line location exactly matches the curated reference in 25/29 tasks (86.2%), compared with 19/29 (65.5%) for OpenHands, a difference of 20.7 percentage points. DEIA also uses 81.5% fewer tokens, makes 60.8% fewer model calls, and takes 34.9% less candidate-generation time on average. Only two of the 58 behavior-specific P2P obligations were executed, both for one repair pattern; comprehensive behavior preservation therefore remains unestablished. CCS Concepts: • Software and its engineering → Software testing and debugging; Software maintenance; Software notations and tools. Additional Key Words and Phrases: automated program repair, large language models, mobile applications, HarmonyOS, ArkTS, behavioral validation, crash reports, empirical study

1

Introduction

Crash repair requires developers to interpret a failure report, locate the responsible code, modify it, and assess the resulting behavior. Coding agents such as OpenHands and SWE-agent can inspect repositories and edit source files [26, 32]. Agentless organizes repair around a more constrained sequence of steps [27]. Once a patch has been generated, ∗ Corresponding author.

Authors’ Contact Information: Xuhui Lu, Beihang University, Beijing, China, luxuhui@buaa.edu.cn; Zhihao Liu, Beihang University, Beijing, China, lzh123698745@buaa.edu.cn; Xiaoke Fang, Beihang University, Beijing, China, zy2403505@buaa.edu.cn; Yuhuan Fan, Beihang University, Beijing, China, zb2606301@buaa.edu.cn; Yanzhe Tang, Beihang University, Beijing, China, zy2503117@buaa.edu.cn; Xiaohui Wan, Suzhou Aerospace Information Research Institute, Suzhou, China, wanxh@aircas.ac.cn; Xiaoyu Wu, Huawei Technologies Co., Ltd., Shenzhen, China, wuxiaoyu7@huawei.com; Zheng Zheng, Beihang University, Beijing, China, zhengz@buaa.edu.cn.

1

2

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

developers still need to trace it back to the crash evidence that motivated the edit and forward to the package and replay used to evaluate it. Each stage also incurs costs that must be measured separately. In HarmonyOS applications written in ArkTS, a crash report typically provides an exception and a stack trace. However, it may not identify the complete source context needed for repair. It may also lack a reliable reproduction sequence or a description of the valid behaviors that should remain unchanged. Moreover, an ArkTS source modification must pass the platform build and signing process to produce a HarmonyOS Ability Package (HAP). The package must then be installed and exercised in a target runtime. These stages produce different kinds of evidence. A patch may be applicable but still fail to build. A package may build but fail to reach the reported trigger. A replay may reach the trigger without showing that other valid behavior has been preserved. Treating these outcomes as one repair-success signal obscures what has actually been demonstrated. These requirements expose three connected challenges for an integrated crash-repair workflow. Challenge 1: Tracing Evidence Across Repair Stages. A failed replay can have several causes. The patch may still contain the fault, the package may have failed to install, or the replay may never have reached the trigger. Distinguishing these cases requires a record of which source revision and patch produced the package, together with the outcome of each stage from patch construction through replay. Challenge 2: Grounding Behavioral Test Obligations. Removing the reported crash does not by itself show that the patch preserves the application’s valid behavior. A patch may suppress an exception while also disabling a legitimate operation, changing a displayed value, or altering a side effect. This concern is well recognized in automated program repair, where a patch can satisfy available tests without implementing the intended behavior [23, 35]. A repair workflow therefore needs two complementary kinds of test obligations: fail-to-pass (F2P) obligations that target the reported fault, and pass-to-pass (P2P) obligations that target valid behavior potentially affected by the patch. Each obligation needs an expected result supported by an oracle, prerequisites for reaching the relevant action, and an observable signal for judging the outcome. If the expected behavior or observation method is unsupported, the obligation should remain pending rather than be counted as a pass. Designed obligations must also be distinguished from checks that have actually been executed. Challenge 3: Measuring Stage-Specific Costs. A repair workflow consumes resources at several stages. These include model interaction, patch construction, package building, and device replay. Model calls, provider-reported tokens, and generation time characterize candidate generation. Build and replay time require separate measurements and instrumentation. Combining these quantities into one undifferentiated cost can hide which stages were measured and which were not. A meaningful comparison therefore needs a stage-level ledger that records model-resource use within a defined boundary and keeps build and runtime evidence separate when comparable timing is unavailable. Missing measurements must remain unknown rather than being treated as zero. These challenges motivate a common question. How can a HarmonyOS repair workflow link each patch to the evidence for its runtime behavior and account for the resources used to generate it? DEIA addresses the three challenges through three coordinated mechanisms. The first mechanism establishes evidence provenance across repair stages. The second grounds behavioral test obligations in supporting evidence. The third records resource use within an explicit measurement boundary. To address Challenge 1, DEIA separates source-context construction, LLM-based diagnosis and edit planning, and deterministic patch materialization. The evidence package is tied to an immutable source revision. The model proposes

Evidence-Grounded Crash Repair for ArkTS

3

content-anchored edits, while a deterministic writer applies those edits to the original source and checks their anchors and scope. The resulting patch is recorded with its provenance and carried forward to package construction and device replay. This creates an auditable link from the reported failure to the exact patch and package under assessment. It also keeps patch applicability, build success, trigger reachability, and runtime observations as distinct outcomes. To address Challenge 2, DEIA derives F2P obligations from the reported fault and P2P obligations from the potential impact of the proposed change. Each obligation records an expected property, its supporting oracle evidence, the prerequisites for reaching the relevant action, and the observable signal used to judge the result. An obligation is eligible for replay only when its expected property is supported and its outcome can be observed. Otherwise, it remains pending. Eligible obligations receive a fixed replay priority, beginning with the original trigger and then considering high-impact valid behavior and adjacent or smoke checks. The evaluation reports designed obligations separately from executed checks. This distinction is important because an obligation specification does not by itself demonstrate that the corresponding behavior was tested. To address Challenge 3, DEIA records model calls, provider-reported input and output tokens, and elapsed time through candidate-patch materialization at 𝐿3 . Build and signing outcomes at 𝐿4 and installation and replay outcomes at 𝐿5 are retained as separate evidence. Comparable matched timing for these later stages is unavailable in the current study, so the ledger does not treat missing measurements as zero or use them to claim a reduction in end-to-end repair time. The evaluation covers 30 repair tasks from 24 HarmonyOS applications. One crash report describes a different defect from its reference patch, leaving 29 matched tasks for comparison. Section 4.1 describes the collection, cohort construction, and public data release. On those tasks, DEIA’s first added line exactly matched a reference edit location in 25 cases, compared with 19 for the OpenHands-based workflow. DEIA also used fewer tokens and model calls and took less time to generate a patch. The device records distinguish outcomes for the reported failure from checks of other behaviors that the patch could affect. Section 5.2 reports which checks were executed. The three contributions are summarized below. • An evidence-grounded workflow connects crash reports, LLM-proposed edits, deterministic patch construction, and device assessment. Its stage-level records link each outcome to the patch under test. The implementation and replication materials are available in the project repository.1 • A fault- and change-aware test-design protocol records the oracle, prerequisites, and observation method for each F2P or P2P obligation. It identifies checks with sufficient evidence for replay and records what is missing for those that remain pending. • An empirical evaluation measures reference-location agreement, patch applicability, device outcomes, and candidategeneration cost. It reports the execution coverage of the designed behavioral checks. 2 2.1

Problem Formulation HarmonyOS Crash-Repair Task

A HarmonyOS crash-repair workflow takes a faulty application revision and a crash report as input, produces a candidate patch, and collects evidence about patch applicability and application behavior. A repair task is represented as 𝑥 = (𝑆, ℓ, 𝑑, 𝜏), 1 https://gitcode.com/harmony-dfx-detection/answer_B/tree/DEIA.

(1)

4

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

Here, 𝑆 denotes the immutable application source revision. The variable ℓ represents the crash report, including the exception and stack trace. The variable 𝑑 identifies the target runtime. The optional sequence 𝜏 contains actions for reproducing the fault. Given 𝑥, the repair workflow produces a candidate source patch 𝑃. Patch generation and repair validation are distinct objectives. A candidate patch must first be applicable to the original source revision. The modified application must then satisfy the platform-specific build and signing requirements before it can be installed and exercised in the target runtime. These stages provide different levels of evidence. Patch applicability establishes only that the modification can be materialized, while successful building establishes that a deployable package can be produced. Neither demonstrates that the reported fault has been removed or that existing behavior has been preserved. Repair assessment therefore distinguishes patch applicability, buildability, and runtime behavior. Runtime evidence must also separate patched-side observations from paired fail-to-pass observations under comparable conditions. Similarly, a successful replay of one interaction path does not establish the preservation of other valid behaviors. The objective is consequently to maintain traceable evidence across these stages rather than reduce repair success to a single binary outcome. 2.2

Behavioral Test-Obligation Formulation

For a repair task 𝑥 and candidate patch 𝑃, two sets of behavioral test obligations address complementary questions. The fail-to-pass (F2P) set O 𝐹 targets the reported failure (Eq. (2a)). The pass-to-pass (P2P) set O 𝑃 targets valid behavior the patch may affect (Eq. (2b)). Their union O is the full set of obligations for the patch (Eq. (2c)). O 𝐹 = FaultObligations(ℓ, 𝑆, 𝜏),

(2a)

O 𝑃 = ImpactObligations(𝑆, 𝑃, 𝐾),

(2b)

𝐹

𝑃

O =O ∪O .

(2c)

The crash report ℓ, source revision 𝑆, and any available reproduction steps 𝜏 ground the F2P obligations in the reported trigger. For P2P obligations, the patch identifies potentially affected behavior. The patch 𝑃 is interpreted against its original revision 𝑆. The available behavior knowledge 𝐾 supplies evidence of its expected outcome from application requirements, validated successful traces, or reviewed specifications. Both sets use the same tuple for an individual obligation 𝑜 = (𝑢, 𝜙, 𝜋, 𝜅, 𝜔),

(3)

Here 𝑢 is the action to exercise and 𝜙 the property it should satisfy. The oracle evidence 𝜋 supports that expectation independently of the generated patch. The prerequisites 𝜅 describe how to reach the action, and 𝜔 specifies how to observe the property once reached. A subscript 𝑜 selects a field of the current obligation. In Eq. (4), Supported tests whether 𝜋𝑜 supports the property 𝜙𝑜 . The predicate Observable tests whether the method 𝜔𝑜 can detect that property. Equation (5) collects the obligations that fail either condition. 𝐸 = {𝑜 ∈ O | Supported(𝜙𝑜 , 𝜋𝑜 ) ∧ Observable(𝜔𝑜 )},

(4)

𝑈 = O \ 𝐸,

(5)

Evidence-Grounded Crash Repair for ArkTS

5

The eligible set 𝐸 contains the obligations satisfying both predicates. The pending set 𝑈 contains all remaining obligations. The design record retains the missing evidence or observation method for each pending item. Execution still requires reaching the prerequisites 𝜅. The test-design record 𝜌𝑇 pairs each obligation 𝑜 with its design status 𝑠𝑜 . The subscript 𝑇 identifies test design. An item in 𝐸 has status Eligible and an item in 𝑈 has status Pending (Eq. (6)). 𝜌𝑇 = {(𝑜, 𝑠𝑜 ) | 𝑜 ∈ O},

𝑠𝑜 ∈ {Eligible, Pending}.

(6)

For eligible obligations, ordinal priorities P1–P3 determine their replay order. These priorities do not introduce an adaptive test-selection policy or a separate test-count budget. Importantly, obligation design and eligibility are distinct from execution: an obligation can only provide behavioral evidence after its prerequisites are reached and its expected property is actually assessed. Unreached triggers and unavailable observations remain inconclusive rather than being counted as successful checks. 2.3

Cost Model

Source preparation, model interaction, and device replay consume different resources. To attribute a cost to a particular repair, the ledger links each measurement to the source revision and the patch produced from it. The generation interval ends when the candidate patch is materialized. Build and device replay have separate records. For each repair task 𝑖, the generation cost record contains three quantities (Eq. (7)):   gen 𝐶𝑖 = 𝑁𝑖calls, 𝑁𝑖tokens,𝑇𝑖,0:3 ,

(7)

The index 𝑖 identifies the task, and gen denotes candidate generation. 𝑁𝑖calls counts model calls made for that task. The quantity 𝑁𝑖tokens counts the total provider-reported input and output tokens. The entry 𝑇𝑖,0:3 is elapsed time in seconds from the start of 𝐿0 through the end of 𝐿3 . These stages cover evidence preparation, diagnosis, edit proposal, and patch materialization, respectively. The later build/sign and device-replay stages correspond to 𝑇𝑖,4 and 𝑇𝑖,5 . These quantities are maintained separately and are included in end-to-end cost only when comparable measurements are available. A gen

missing measurement is treated as unknown rather than zero. Consequently, 𝐶𝑖

characterizes candidate-generation

cost and does not represent the complete cost of repair and runtime validation. 3

Approach

Figure 1 organizes DEIA into four components. Patch generation (A) supplies the candidate patch and fault evidence. Behavioral test design (B), expanded in Figure 2, specifies what to check. Runtime checks (C) build the candidate and replay selected actions. The ledger (D) links the artifacts and measurements from these components. 3.1

Patch Generation

𝐿0 : Source Evidence. Figure 1A begins with the crash report. DEIA parses the report into stack frames and separates application frames from framework frames. Source paths are resolved using progressively longer suffix matches rather than only filenames. The resulting code set is bounded. Optional static probes flag calls, identifier differences, and possible dereferences. For cross-file producer–consumer faults, DEIA follows a deterministic expression chain from the crash frame to related field references. It then checks whether the bounded candidate set covers both the suspected producer and consumer sides. This is a heuristic retrieval and coverage gate, not a complete data-flow analysis. The evidence package has a nominal 10,000-token context limit estimated from character counts. Code near the crash frames

6

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

A Patch generation Crash report Immutable source revision

L0-L3

Evidence diagnose & pack plan edits

normalize & probe

Normalized trace Bounded source Targeted probes

L0 Program

L1-L2 LLM

Anchored materialize edit plan & check

Root-cause diagnosis Content anchors

L3 Program

derive test inputs

C Runtime checks

Fault trigger

Signed application

Change impact

F2P obligations

Patched source L5 · install & replay

P2P obligations derive

Requirements Successful traces Reviewed specs

justify

Replay evidence

Test specifications

dispatch

Expected result · provenance Prerequisites · observability Priority · status

if eligible

record

adjudicate Pass / Fail / Inconclusive

record

record

D Cost and evidence ledger

Calls · I/O tokens · time

WorkBuddy + CLI HarmonyOS emulator

Outcomes

Pending: missing oracle / unobservable

Generation cost

Applied edits Applicability gates Audit record

L4 · build & sign

B Behavioral test design

Oracle evidence

Candidate patch

L0-L3 measured; L4-L5 no matched timing

Patch provenance

Revision · hash · audit

Test ledger

Obligations · oracle · status

Runtime evidence

Build · replay · verdicts

Fig. 1. Overview of DEIA. (A) Patch generation constructs a candidate patch from bounded source evidence and content-anchored edits. (B) Behavioral test design derives F2P/P2P obligations and specifies oracle-backed observations. (C) Runtime checks build, sign, install, and replay the candidate package. (D) The ledger links generation cost, patch provenance, test status, and runtime evidence. This study measures generation timing for 𝐿0 –𝐿3 . Comparable matched timing for 𝐿4 –𝐿5 is unavailable.

has priority. The log records omitted files and the difference between estimated and actual tokens. Better path resolution increased the number of cases containing a reference-edited file from 25/30 to 29/30. This measures evidence coverage, not a proven increase in repair success. 𝐿1 –𝐿2 : Diagnosis and Edit Proposal. The model proposes a cause and ranks possible edit locations. It returns edits as (file, old_string, new_string) triples. DEIA records the diagnosed location separately from the modified location. The model decides what code to change. It does not write unified-diff headers or line counts. Each old_string must match exactly one location in the original source. Section 5.1.3 evaluates this edit format for mechanical applicability, not semantic correctness. 𝐿3 : Deterministic Materialization. A deterministic program applies the edits to the original source bytes and constructs unified-diff patches. It checks that each edit anchor is unique and each file path is allowed. The patch files are written as bytes to preserve their line endings. The current generated patches pass git apply –check in all 30 tasks. The delivered patch artifacts are byte-identical to the generated patches, as verified by SHA-256, and all 30 delivered artifacts pass the same check.

Evidence-Grounded Crash Repair for ArkTS 3.2

7

Behavioral Test Design

Figure 2 provides the operational detail for the behavioral test-design component in Figure 1B. The following paragraphs describe its three steps in order. Test authors may supply or review expected properties and prerequisites.

A Obligation generation Fault evidence Crash signature Trigger prerequisites

derive

B Oracle and observability Oracle evidence

F2P obligations Original trigger Nearby variants

Requirements, reviewed specifications Validated successful baseline traces

Test specification

Change-impact P2P obligations evidence identify Guards, writes, control flow Conversions and side effects

ground

specify

Expected property and oracle provenance Action, prerequisites and observation method

Valid behaviors at risk from edits

Eligible Supported and observable Pending Unsupported or unobservable

C Priority for eligible specifications 1 Original trigger

2 High-impact valid behavior

3 Adjacent / smoke

dispatch

L5 replay Fig. 1C

Fig. 2. Detail of the behavioral test-design component in Figure 1B. (A) Fault and change-impact evidence derive F2P and P2P obligations. (B) Oracle evidence grounds each expected property, while the specification records the action, prerequisites, and observation method. Supported and observable specifications are eligible. Unsupported or unobservable specifications remain pending. (C) Eligible specifications receive an ordinal replay priority and are dispatched to 𝐿5 in Figure 1C.

A. Derive fault and change-impact obligations. F2P checks start from the reported crash. The design records its exception, likely trigger, and required device or UI state. It may also cover nearby cases, such as invalid indices or missing values, when the fault evidence supports them. The report states whether the original faulty version was replayed under comparable conditions. A historical crash log is not such a replay. If the device cannot reach the trigger, the result is inconclusive. P2P checks focus on valid behavior that a patch might change. A new guard or return statement may affect normal execution. A default value or data conversion can also change valid behavior. The designer considers how an overly broad fix could remove a crash but break a valid path. Each expected result must be supported independently of the patch. A requirement or a verified earlier trace can provide that support. For example, an index-guard modification can motivate an invalid-index F2P replay and a valid reorder or selection P2P check. The expected behavior must be grounded in the valid-input and list-order contract, not inferred from the patch itself. This is a design example, not evidence that either check was executed. B. Specify the oracle and observation method. The protocol records five fields for each obligation: its action, prerequisites, expected property, oracle provenance, and observation method. An obligation is eligible only when its expected property has supporting evidence and its effect can be observed. Otherwise, it remains pending, with the missing support or observation requirement retained in the design record. Reaching a screen establishes reachability. It does not establish that a state update, value, or side effect was preserved.

8

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

Algorithm 1 Procedure for deriving and recording F2P/P2P test obligations. Require: task 𝑥 = (𝑆, ℓ, 𝑑, 𝜏), candidate patch 𝑃, behavior knowledge 𝐾 1: initialize 𝐸, 𝑈 , and 𝜌𝑇 as empty sets 2: O 𝐹 ← FaultObligations(ℓ, 𝑆, 𝜏) 3: O 𝑃 ← ImpactObligations(𝑆, 𝑃, 𝐾) 4: for all 𝑜 ∈ O 𝐹 ∪ O 𝑃 do 5: record obligation type, action 𝑢𝑜 , prerequisites 𝜅𝑜 , and observation method 𝜔𝑜 6: record expected property and supporting oracle source, if available 7: if Supported(𝜙𝑜 , 𝜋𝑜 ) ∧ Observable(𝜔𝑜 ) then 8: set 𝑠𝑜 ← Eligible 9: assign ordinal replay priority and add 𝑜 to 𝐸 10: else 11: set 𝑠𝑜 ← Pending 12: record missing evidence and add 𝑜 to 𝑈 13: end if 14: add (𝑜, 𝑠𝑜 ) to 𝜌𝑇 15: end for 16: return (𝐸, 𝑈 , 𝜌𝑇 ) C. Assign replay priority. Among eligible specifications, the original crash trigger is the mandatory P1 design target and receives first replay priority. P2 covers high-impact valid behaviors that may be affected by the patch. P3 covers adjacent paths and smoke checks. These labels express an ordinal replay order, not a learned risk score, a test-count budget, or an adaptive allocation algorithm. The released suite uses a fixed eight assertions per task (two F2P and six P2P), for 240 design slots across 30 tasks. The ordinal labels guide replay planning without changing that fixed suite. Algorithm 1 retains the missing evidence for each pending decision. Some expected properties in this study drew on curated reference repairs and human judgment. The specification records that provenance so that a reviewer can assess the independence of the oracle. 3.3

Runtime Checks

The runtime checks in Figure 1C take the patch from A and the selected checks from B. At 𝐿4 , the patch is applied to a clean source tree. HarmonyOS tools then build and sign a HAP. Build and dependency failures are recorded separately. At 𝐿5 , the replay harness uses the HarmonyOS command-line and emulator interfaces to install and launch the package. It performs UI actions, replays triggers, and collects logs and process/UI signals. For each check, the record identifies the requested action and whether it was reached. It then records the observed result. If execution is blocked, the record states why. Interpreting the observations. The result record links each observation to its stage. A build establishes that the toolchain can produce a package. A paired F2P result requires a failure on the original version and a successful replay under comparable conditions on the patched version. A P2P observation applies to the input and property that the check actually reached. Unreached triggers remain inconclusive, and infrastructure failures retain their stage-specific cause. Section 4.5 defines the measures and Section 5.2 reports their coverage. The feedback policy identifies nine failure types. These include missing or ambiguous edit anchors and edits outside the approved scope. Other categories cover patch failures and compilation problems. The policy also records signing or installation rejection, unreached triggers, and infrastructure problems. The model can use feedback about fixable edits

Evidence-Grounded Crash Repair for ArkTS

9

and compilation errors. Setup failures or unobservable device behavior should not be treated as errors in the patch itself. This policy describes control flow. The study does not measure a retry improvement from it. 3.4

Cost and Evidence Ledger

Figure 1D organizes the ledger into four linked record groups. They form a provenance chain from candidate generation to device assessment. The ledger is not a single success flag. It preserves the evidence and status associated with each stage. For each repair, the patch record ties the source revision to the model’s edit anchors and the hash of the patch actually built. The associated cost record measures model calls, input and output tokens, and elapsed time up to patch materialization at 𝐿3 . Later build and replay records retain their outcomes. Comparable timing for those stages was unavailable. The test ledger links each expected property to its evidence, prerequisites, and observation method. It distinguishes checks ready for replay from pending checks and records any human contribution to their specification. The runtime record then identifies the tested package, the action reached, and the observed outcome. Together these records let a reader distinguish a failure to install the package from a recurrence of the target crash or a change in the behavior being checked. 4

Experimental Design

4.1

Dataset Construction

The tasks come from a HarmonyOS crash-repair collection released for a software-defect challenge. The collection and its metadata are publicly available at https://gitcode.com/dfx-contest-2026/data. The collection contains 70 reported crashes. Grouping the reports by crash signature and top application stack frame produced 33 candidate fault instances. We excluded three instances because their reported defects were absent from the supplied source revisions. This left a generation cohort of 30 tasks from 24 applications. One task has a crash report that does not describe the defect addressed by its curated reference repair. This task contributes to the 30-task generation and cost statistics. The primary localization and device comparisons exclude it. The resulting adjudicable cohort contains 29 tasks. We identified this mismatch during analysis and made the exclusion decision post hoc. Reporting both cohorts makes the post-hoc exclusion visible and keeps generation statistics separate from matched comparisons. Table 1 describes the 30 tasks retained for generation. Device-execution accommodations are described in Section 4.4. Data leakage and workspace isolation. The model-visible crash reports were stripped of embedded text that could disclose root-cause explanations. For DEIA, the intended model input was the generated evidence package and permitted source excerpts. Reference fixes, task answers, and test scripts were not intended to be model-visible. The OpenHands baseline configuration excluded the testcases/ and reports/ directories. Strict workspace isolation was not enabled for the full DEIA batch: the –isolated mode was validated on one case but not used for all 30 tasks. A post-run audit covered 175 model sessions containing about 25.7 million characters. The audit found no matches for the recorded answer-leak markers. This audit reduces, but does not eliminate, the risk of unintended exposure. Earlier development also involved prompt changes on overlapping cases. The 30 cases are therefore a study of the developed workflow, not a held-out estimate of generalization. A future evaluation needs untouched cases.

10

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng Table 1. Composition of the 30 repair tasks from 24 HarmonyOS applications.

4.2

Characteristic

Category

Tasks

Share (%)

Data batch

B1 B2 B3

12 8 10

40.0 26.7 33.3

Exception type

TypeError RangeError SyntaxError

16 9 5

53.3 30.0 16.7

Log source

Device-origin Augmented

24 6

80.0 20.0

Reference patch

Single-file Multi-file

27 3

90.0 10.0

Research Questions

• RQ1. Candidate generation. How often does each workflow edit a reference location and produce a patch that applies to the original source? • RQ2. Device validation. What do build and replay records show about removal of the reported failure and preservation of affected behavior? • RQ3. Generation cost. How do the workflows compare in model calls, token use, and elapsed time through patch materialization? 4.3

Baselines

The primary external baseline is an OpenHands-based repair workflow. The team’s earlier plugin-based workflow provides an additional workflow-level reference. These comparisons do not isolate individual components unless a metric is explicitly tied to a common procedure. OpenHands-Based Autonomous Repair. The OpenHands baseline follows a sandboxed autonomous-agent loop based on the OpenHands framework [26]. Given the crash report and application source tree, the agent explores the repository and edits source files through Bash. Its available actions are Bash and task completion. After the agent finishes, git diff extracts the resulting patch from the sandbox working tree. The current comparison uses the same 30-task generation cohort as DEIA: the 30 eligible tasks remaining after excluding the three reports whose alleged defects were absent from the supplied source revisions. The crash-report bytes and source revisions are matched at the task level. Reference patches, test scripts, and evaluation reports are excluded from the agent workspace. The baseline implementation was maintained in a separate dfx-patch-agent/ workspace. The available design record describes 12 modules, but the workspace was not version-controlled and is not included in the public DEIA release. The released materials do not pin an exact upstream OpenHands version or commit. The term OpenHands-based identifies the implementation evaluated here. Archived per-task records and patches provide the evidence for this comparison. The public artifact does not currently support an independent rerun of this baseline. Previous Plugin-Based Repair Workflow. The second comparator is the team’s earlier plugin-based repair pipeline. It asks the model to produce a diagnosis and a unified-diff patch, which is then checked by surrounding scripts. It

Evidence-Grounded Crash Repair for ArkTS

11

shares evidence construction, the fault-mode knowledge base, and some function-level replay utilities with DEIA. However, the workflows differ in four ways. The model writes a unified diff directly instead of returning structured edit operations. The tool surface includes Bash. The interaction and retry strategy uses multiple rounds. Stack-frame paths are handled differently from DEIA’s path-suffix matching. Because several factors change together, this is a workflow-level comparison rather than an isolated ablation of patch representation, evidence construction, or tool restriction. Role of Curated Reference Patches. The reference patches were manually prepared during dataset curation and refined as the cases became better understood. They are not necessarily fixes committed by upstream developers. Both workflows excluded the reference patches from their declared generation inputs. They were also excluded from DEIA’s bounded evidence package. Workspace isolation and the limits of the post-run exposure audit are reported in Section 4.1. The evaluation uses these patches to score edit-location agreement offline. Some behavioral expectations also drew on reference repairs, as discussed in the construct-validity analysis. A short upstream change may differ substantially from a more defensive reference patch. Reference-line coverage must therefore not be treated as correctness. Device validation uses packages built from each method’s own generated patch: DEIA packages come from patches/deia/, and OpenHands packages come from the OpenHands working-tree diffs. No gold-reference package is counted as a DEIA result. The curated reference patch is not treated as a fully independent behavioral oracle. Its provenance and possible defects are discussed in the validity analysis. 4.4

Experimental Settings

Both workflows ran GPT-6.1-Sol through DeepSeek Harness (DSH). For a given task they received the same crash report and source revision. DEIA supplied bounded source evidence and accepted structured edits. The OpenHands-based workflow used Bash to explore and modify its sandbox. Token counts come from the usage reported by DSH. Package construction and validation use the HarmonyOS command-line toolchain. Its components include ohpm, hvigorw, signing utilities, and hdc. Device checks use an API-26 HarmonyOS x86_64 emulator with a 12-second observation window. Both comparison arms use the same replay harness and platform interfaces. On November 6, 2026, packages from both workflows ran sequentially on the same emulator instance. They used a byte-identical harness and the same scenario definitions. Most DEIA packages had been built before the matched replay. One package required an unavailable platform dependency and was rebuilt with the same local compatibility stub in both arms. Six tasks required native libraries. Both arms received the same x86_64 library injection and re-signing adjustment. These adjustments address emulator compatibility and do not modify the source lines changed by either repair patch. 4.5

Evaluation Metrics

The generation cohort supplies 30 tasks for artifact checks. The matched comparison uses 29 tasks to assess edit locations, device observations, behavioral coverage, and generation cost. The following metrics specify the evidence used for each outcome. 4.5.1 Source-Level Localization. File-level hit measures whether a generated patch modifies a file also modified by the curated reference patch. The first-added-line metric compares the first added line in the generated patch with added-line locations in the reference patch, using the new-file line number. The comparison measures exact agreement and agreement within two and five lines. These are reference-alignment measures, not semantic correctness metrics. An additional any-changed-line analysis is reported separately where relevant.

12

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

4.5.2 Patch Applicability. Patch applicability is determined by running strict git apply –check against the original source revision. For DEIA, the check is applied to the current generated patches and repeated on the delivered patch artifacts. SHA-256 comparison verifies byte identity between the generated and delivered files for all 30 tasks. Applicability establishes whether a patch can be applied. It does not establish that the resulting program is correct. 4.5.3 Device and Test-Obligation Coverage. Each task has two F2P assertions and six P2P assertions. This gives 240 assertions for the 30-task generation cohort and 232 for the 29 matched tasks. Each matched task contributes one F2P check on the original trigger and one on a nearby trigger. Its six P2P checks cover a precondition, two specific behaviors, an adjacent path, and two smoke checks. Figure 4 gives the denominator for each category. Device adjudication, runtime fault confirmation, paired F2P outcomes, and reached P2P-derived checks are reported separately. A compile-gate outcome is not counted as a reproduced runtime crash. A patched-side observation is not treated as complete pass-to-pass evidence unless the corresponding unpatched behavior and expected property are established. Designed, executed, and adjudicated counts therefore retain separate denominators. Coverage counts are not behavioral pass rates. 4.5.4 Candidate-Generation Cost. Generation cost comprises model-call counts, token use, and elapsed time through candidate patch materialization at 𝐿3 . Token use is recorded as input, output, and total tokens. The cost boundary excludes package building, signing, installation, and device replay. The DEIA-only stage-time decomposition uses the 30-task generation cohort. The DEIA–OpenHands cost comparison uses the 29-task matched cohort. Values are point estimates from the recorded runs. No repeated-run variance is available. 4.6

Execution Protocol

Each workflow generated one candidate per task from the same crash report and source revision in its own workspace. For static evaluation, we compared each candidate’s edit locations with the curated reference and checked its applicability against the original source. For DEIA, the check covered all 30 current generated patches and their corresponding delivered artifacts. SHA-256 comparison verified that each delivered artifact was byte-identical to its generated patch. The same applicability check was applied to the OpenHands working-tree diff on the matched tasks. For the 29 matched tasks, the replay harness tested packages built from each workflow’s own patch. Both sets ran sequentially on the same API-26 emulator using repro_all_cases.py and the same 12-second observation window. The harness recorded the installed package, the action reached, and the observed fault or behavior. Pairing these records by task allowed the comparison to use a common baseline for each reported failure. Reproduction Scope. The DEIA GitCode branch provides the implementation and prompts alongside the task metadata, patches, offline metrics, and replay records. The original application archives are not included in the paper package. Reproduction requires the archived source revision and the recorded runtime configuration, including DSH 0.1.5-rc.2, the HarmonyOS toolchain, and the emulator. The OpenHands-based results rely on archived outputs because its workspace was not released and its upstream commit was not pinned.

Evidence-Grounded Crash Repair for ArkTS 5

13

Results

5.1

RQ1: Candidate-Generation Reliability

RQ1 examines reference-aligned localization and mechanical patch applicability. These measures describe where a workflow edits and whether its patch can be applied to the original source. Neither measure alone establishes that the resulting application behaves correctly. 5.1.1 Reference-Aligned Localization. Figure 3 compares the two workflows on the 29 matched tasks. For line-level agreement, the first added line of each generated patch is compared with the added lines in the curated reference using new-file line numbers. OpenHands-based

DEIA 19

Exact line

25 22

Within 2 lines

29 24

Within 5 lines

29 28

Reference-modified file 0

5

10

15

20

25

29

30

Matched tasks with an edit-location hit (out of 29) Fig. 3. Agreement with reference edit locations on 29 matched tasks. Each pair of bars compares OpenHands-based and DEIA counts. The first three rows assess the first added line at increasing tolerances. The last row counts edits to any file changed by the reference patch.

OpenHands modified a reference-edited file in 28 of 29 tasks. DEIA did so in all 29. Exact first-added-line matches occurred in 19 OpenHands patches and 25 DEIA patches. This corresponds to 65.5% and 86.2%, respectively, or a 31.6% relative increase for DEIA. At a two-line tolerance, DEIA matches 29 tasks and OpenHands matches 22. The line-level metric is sensitive to the selected patch anchor. Under an any changed line definition, exact overlap is 23/29 for OpenHands and 26/29 for DEIA. Within two lines, the results are 25/29 and 29/29. The main comparison retains the first-added-line metric specified in the evaluation protocol. Several misses arise from different edit boundaries within the same code block rather than a different function. The metric therefore captures agreement about where to edit. Assessing the diagnosis itself would require evidence about the fault’s cause. The DEIA evidence package contains a reference-edited file for 29/30 tasks after path-suffix matching, compared with 25/30 before that correction. This is evidence-package coverage and is separate from generated-patch localization. 5.1.2

Cross-File Identifier Mismatch. Two reports in the cohort illustrate why a crash frame does not always identify

the source location that should be edited. Both reports point to an undefined authorNickName dereference in the ArticleFeedDetails.ets file, at line 111. The underlying cause is upstream: MockArticle.ets assigns Author_2,

14

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

whereas the available mock user is keyed by author_2. A strict equality lookup in AuthorServiceMock.ets therefore returns no author. The data service leaves the author field unset. The view later dereferences that field. For these cases, DEIA starts from this and follows newsFeedVM to articleDetails. It then traces the author field to authorNickName. The three-hop search checks producer/consumer coverage. The resulting 15-file focus set places the crash file first and MockArticle.ets second. The generated patch changes the producer-side identifier at MockArticle.ets:50 from ’Author_2’ to ’author_2’. It does not suppress the view-side exception with a null fallback. The replay reaches the trigger and removes the target crash. The device showed the expected author name, and the replay recorded no new fault. An earlier view-only fallback patch either left the target failure or hid the author value. This illustrates the difference between removing a symptom and repairing the producer–consumer mismatch. The two reports share the same patch bytes and each has one recorded repeat. The two observations therefore cover one repair pattern. 5.1.3 Mechanical Patch Applicability. Table 2 reports strict git apply –check results for the generated and delivered artifacts. Table 2. Mechanical patch applicability by workflow and artifact.

Workflow

Patch artifact

Plugin-based DEIA OpenHands-based

Generated diff Generated and delivered patch Working-tree diff

Tested

Passed

Rate (%)

30 30 29

14 30 29

46.7 100.0 100.0

Note. Passed counts patches accepted by git apply –check against the corresponding original HEAD. The DEIA row covers all 30 generated tasks, including the 29-task matched subset. DEIA’s generated and delivered patches are byte-identical in all 30 tasks (SHA-256). On the matched subset, both DEIA and OpenHands pass 29/29. Applicability does not establish buildability or behavioral correctness.

DEIA generates diff headers and line counts programmatically rather than asking the model to write them. The current generated patches pass strict applicability checks in all 30 tasks. The delivered patch artifacts are byte-identical to the generated patches in all 30 tasks, as verified by SHA-256, and all 30 delivered artifacts also pass the check. On the same 29-task adjudicable subset, both DEIA and OpenHands pass 29/29. The results therefore support reliable patch materialization and delivery, not an applicability advantage over OpenHands. The previous plugin-based workflow differs from DEIA in tool access, source-path handling, and retry policy as well as patch representation. Its 14/30 result is therefore a workflow-level comparison, not an isolated ablation of structured edits. Answer to RQ1. On the 29 adjudicable cases, DEIA has higher reference-aligned file and first-added-line scores than the OpenHandsbased workflow. Both methods’ patches pass strict applicability checks on this matched subset. All 30 current DEIA generated patches and their byte-identical delivered artifacts also pass. These results support a difference in reference-location agreement, not a claim of superior semantic correctness or greater patch applicability than OpenHands.

Evidence-Grounded Crash Repair for ArkTS

15

Implication. Patch applicability, source-location agreement, and repair behavior are separate properties. Deterministic materialization and byte-verified delivery make the current patch artifacts reproducibly applicable. Reference alignment and applicability alone do not establish semantic correctness. 5.2

RQ2: Device Validation Outcomes

The matched device comparison uses packages generated by the two methods: DEIA packages are built from its method-generated patch set, and OpenHands packages are extracted from the OpenHands-based agent’s working trees. Curated reference patches supply the offline localization targets. Each device outcome is attributed to the workflow that generated the tested patch. 5.2.1 Device Outcomes. On November 6, 2026, both workflows’ patched packages ran on the same API-26 emulator with a 12-second observation window. The DEIA manifest links every tested package to its generated patch. All 29 generated patches differ from their curated references. In both arms the replay reached the patched target path in every task. Processes survived the observation window, cleanup succeeded, and the harness recorded no new faults or navigation errors. Interpreting these outcomes requires the baseline for each task. The unpatched application reproduced a runtime fault in 28 cases. In the remaining case the original version failed to build, so its outcome records a transition from build failure to build success. One of the 28 runtime cases required a local compatibility stub on the emulator. Both method packages used the same stub, which left the edited source line untouched. The other 27 cases supplied patched-side runtime observations. The target-path judge paired each method’s patched outcome with the baseline for the same source revision and trigger. This yielded 29 target adjudications per workflow, including the build-gate case. The alternative trigger was never replayed for any of the 29 tasks, so its outcome remains unknown. 5.2.2 P2P-Derived Checks. Each method’s patched packages produced 87 observations across three phases: reaching the precondition, cold-start rendering, and return navigation. The two methods had the same outcomes on these checks. The original behavior was not established for every corresponding input, so these observations support reachability and smoke behavior on the patched paths. 5.2.3 Obligation Coverage. The matched cohort contains 232 designed assertions across 29 tasks. Figure 4 compares the phases with recorded checks in the original DEIA assessment or the November 6 replay. The original assessment recorded 60 executions. The matched replay recorded 116 adjudications per workflow. The matched replay did not separately run the behavior-specific checks. The two smoke phases were outside the original assessment. Across the 58 designed behavior-specific P2P obligations, only two have been executed. Both observations come from reports that share the same producer–consumer identifier-mismatch repair pattern. They use equivalent UI-text observations. They do not establish a general functional-correctness rate or constitute independent replications. All 29 adjacent-path P2P obligations and all 29 near-path F2P obligations remain unexecuted. The judge was also applied to pre-ABI-fix installation-failure records. It returned 75 PASS, 8 FAIL, and 7 INCONCLUSIVE. The judge can therefore distinguish some blocked setup records. The failures in this control arise from installation and navigation blockage, not controlled semantic regressions. This validates some infrastructure sensitivity. It does not establish broad behavioral-regression sensitivity.

16

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng Original DEIA assessment

Nov. 6 matched replay

Target-path F2P

29/29 29/29

P2P precondition

29/29 29/29 2/58

P2P behavior-specific P2P smoke 1

29/29

P2P smoke 2

29/29

0

25

50

75

100

Executed / designed obligations (%) Recorded totals: 60 original executions; 116 matched adjudications per workflow Fig. 4. Recorded executions of selected F2P and P2P-derived obligations on the 29-task adjudicable cohort. The figure includes only phases with recorded executions. The original DEIA assessment contains 60 records. The November 6 matched replay contains 116 adjudications per workflow.

A controlled negative-patch dry run illustrates the distinction between F2P and P2P. The negative patch widens an index guard by one position. The target crash remains absent. A valid drag to the final position should change the list order, but the recorded order stays the same. The corresponding P2P check therefore fails while F2P remains pass. This single dry-run example is not a broad sensitivity estimate. Its driver has not completed device execution. Answer to RQ2. Both methods receive 29/29 device-adjudication outcomes on their own packages under the same-day API-26 replay. Each arm also receives 29/29 target-obligation adjudications and 87/87 P2P-derived reachability and smoke checks. The 29 adjudications include 28 runtime fault cases and one compile-gate case. One task uses the same compatibility stub in both arms. The 87 checks are patched-side observations, not complete pass-to-pass tests. The original DEIA assessment executed two of the 58 behavior-specific P2P obligations. Near-path F2P and adjacent-path P2P remain unexecuted. The evidence supports comparable outcomes on checked paths, not comprehensive functional correctness, formal equivalence, or universal repair superiority. Implication. Device validation should report package provenance and distinguish trigger reachability from preservation of other valid behavior. Patched-side reachability and smoke observations provide evidence about selected execution paths, but they do not replace independently oracled P2P regression tests.

Evidence-Grounded Crash Repair for ArkTS 5.3

17

RQ3: Candidate-Generation Cost

On the 29 matched tasks, Figure 5 compares resource use for generating a candidate patch. The separate timing breakdown uses all 30 DEIA tasks to identify where generation time was spent. Both analyses end at patch materialization,

Mean relative to OpenHands (%)

before build and replay.

100

Total tokens

Model calls

Generation time (s)

81.5% lower

60.8% lower

34.9% lower

199,437

7.48

39.82

75

25.92

50

2.93 36,846

25 0

OpenHands

DEIA

OpenHands

DEIA

OpenHands

DEIA

Fig. 5. Candidate-generation cost on 29 matched tasks. Each panel normalizes the OpenHands-based mean to 100. Labels above the bars show absolute means, while the percentage above each panel reports DEIA’s reduction relative to OpenHands. Each workflow ran once per task.

Most of the token difference comes from input: DEIA averaged 36,183 input tokens per task, compared with 198,819 for OpenHands (81.8% fewer). Mean output tokens rose from 618 to 663 (7.3% more). Median generation time fell from 35.15 to 22.93 seconds (34.8%). These workflow-level measurements do not isolate the effect of any one design choice. The previous plugin-based workflow is a secondary workflow-level reference. It uses 101,882 tokens, 7.10 model calls, and 102.47 seconds per task in its recorded 30-task run. Its tool access, path handling, and retry policy differ from DEIA, so these values are descriptive context rather than a controlled ablation. Generation-time breakdown. Figure 6 summarizes DEIA’s 30-task generation-time record. The mean is 25.61 seconds: 0.26 seconds for local evidence construction (𝐿0 ) and 25.35 seconds for model interaction, edit materialization, and checks (𝐿1 –𝐿3 ). This figure uses the 30-task DEIA generation cohort. The 29-task comparison in Figure 5 excludes the mismatched crash-report/reference-repair task. The stage breakdown is not directly comparable with OpenHands’ internal timing categories. OpenHands’ localization interval includes model-driven repository exploration. DEIA’s 𝐿0 interval is a deterministic program step. Total candidate-generation time is the common timing measure across the two workflows. The values are point estimates from one run per task. There are no repeated runs from which to estimate run-to-run variance. Model scheduling, caching, and service latency may affect elapsed time. The results support lower measured resource use for DEIA on this cohort, not a universal latency guarantee or a reduction in total device-validated repair time. Answer to RQ3. On the 29-task cohort, DEIA averages 36,846 tokens, 2.93 model calls, and 25.92 seconds per candidate-generation task. OpenHands averages 199,437 tokens, 7.48 calls, and 39.82 seconds. The difference is primarily in input-token consumption. These are single-run, generation-stage measurements and do not include device validation.

18

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng (a) Mean time by stage

(b) Total-time summary 22.62 s

Median

L0: 0.26 s

25.61 s

Mean

L1–L3: 25.35 s

Mean / task

25.61 s

39.72 s

P90

46.07 s

Maximum 0

10 20 Generation time (s)

30

0

20 40 Generation time (s)

60

Fig. 6. Candidate-generation time for DEIA on the 30-task generation cohort. (a) Mean time for local evidence construction (𝐿0 ) and model interaction, editing, and checks (𝐿1 –𝐿3 ). (b) Median, mean, P90, and maximum generation time. Both panels exclude package building and device replay.

Implication. Bounded source evidence is associated with lower model input consumption in this comparison, but the workflow-level results do not isolate the contribution of individual design choices. Component ablations are needed to assess those contributions. Repeated runs are also needed to estimate run-to-run variation. 6 6.1

Threats to Validity Construct Validity

Reference-based localization measures agreement with curated patches, not semantic correctness or the only valid repair. Behavioral evidence remains incomplete: the 29 adjudications include one compile-gate case and one stub-assisted replay. The matched replay recorded 87 patched-side reachability and smoke checks per workflow. The original DEIA assessment executed two of the 58 behavior-specific P2P obligations, both for the same repair pattern. Comprehensive behavior preservation is therefore unestablished. Some expected outcomes rely on curated references or researcher judgment, creating possible oracle bias. 6.2

Internal Validity

OpenHands lacked a pinned upstream commit, limiting reproduction. Sequential replay and package adjustments may affect outcomes despite the shared emulator and harness. Each task had one generation run, and prompt development overlapped with evaluated or related cases. One mismatched crash-report task was excluded from matched adjudication but retained in generation statistics. 6.3

External Validity

The evaluation covers 30 ArkTS repair tasks from 24 HarmonyOS applications. Six reports are synthetic or augmented. All runs used GPT-6.1-Sol and validation used the HarmonyOS toolchain with an API-26 emulator. Generalization to other platforms, languages, model providers, and runtime configurations remains untested.

Evidence-Grounded Crash Repair for ArkTS 7

19

Related Work

7.1

Automated Program Repair

Automated program repair (APR) investigates how to generate source-code modifications that address software defects while satisfying specified correctness criteria. Existing approaches differ in how they identify faults, construct candidate patches, and assess repair outcomes. Research has progressed from search-based and pattern-based transformations to neural repair techniques, with increasing attention to the reliability of generated patches. General Program Repair. Traditional APR techniques employ different strategies for constructing candidate patches. GenProg searches program variants through automated transformations, while PAR learns repair patterns from humanwritten patches and TBar applies predefined repair templates [7, 14, 18]. Surveys organize these techniques around fault localization, candidate generation, and patch validation [6]. Neural approaches further extend repair capabilities across programming languages. For example, RING combines fault localization, program transformation, and candidate ranking to support multilingual program repair [12]. Defects4J provides a widely adopted benchmark for evaluating APR techniques on real-world Java defects [13]. Together, these approaches establish the foundations of automated patch generation and evaluation across different repair strategies. Mobile applications introduce additional execution requirements because a source-level modification must ultimately be assessed within the target application runtime. Successful patch application alone does not establish that an application can launch, reach the relevant interaction, or preserve its existing behavior on a device. Platform-specific repair also has to account for build, signing, and runtime constraints. Mobile Crash Repair. Existing research addresses these requirements through crash reproduction, GUI exploration, and application-level repair. CrashScope automatically discovers, reports, and reproduces crashes in Android applications [21]. DroidBot generates UI-guided test inputs based on application states [16]. Stoat uses guided stochastic model-based exploration to exercise GUI behaviors [24]. Sapienz formulates Android application testing as a multiobjective search problem to expose crashes and other failures [20]. Beyond crash discovery, Droix repairs Android crashes with reusable transformation operators derived from failing executions [25]. LLM-CompDroid combines language models with dynamic analysis to address configuration-compatibility defects in Android applications [19]. These approaches demonstrate the importance of connecting source-code modifications with application execution and runtime observations. HarmonyOS Repair. Platform-specific repair has also received increasing attention in the HarmonyOS ecosystem. Huawei provides official documentation covering ArkTS language features, static checks, and runtime crash diagnostics [9, 10]. ArkEval introduces a benchmark of 502 reproducible ArkTS repair issues and distinguishes build validity from behavioral repair [30]. AppEval further proposes a unified mobile application repair benchmark spanning ArkTS, Swift, and Kotlin. Its evaluation contract distinguishes target-program assertions from infrastructure failures. However, its reported quantitative audit is Android-specific [29]. These resources establish that ArkTS repair benchmarks and platform-oriented evaluation are already active research topics. They also highlight the need to distinguish successful patch construction and build execution from evidence of actual behavioral repair on the target platform. Against this background, DEIA focuses on maintaining traceable links among the crash report, source revision, patch artifact, and device assessment in HarmonyOS crash repair.

20

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

7.2

LLM-Based Repair Agents

Large language models have extended automated program repair from individual patch-generation techniques toward interactive workflows involving repository exploration, tool execution, and iterative feedback. Existing systems differ in their degree of agent autonomy, the program information available during repair, and the way execution feedback is incorporated into subsequent actions. In parallel, repository-level benchmarks provide increasingly realistic settings for evaluating these workflows. Agent-Based Repair. Recent surveys classify LLM-based APR systems according to their model-use patterns, interaction strategies, and repair workflows [31]. ChatRepair employs conversational interaction to refine candidate patches, while self-debugging methods use model feedback and execution results to improve generated programs [4, 28]. More autonomous systems integrate planning and tool execution into the repair process. RepairAgent coordinates information gathering, patch generation, and validation through an LLM-based agent [2]. AutoCodeRover combines program-structure information, search, and fault localization to support repository-level program improvement [37]. SWE-agent studies agent–computer interaction for software engineering [32]. OpenHands provides a general-purpose platform for tool-using software agents [26]. Agentless explores a more constrained repair workflow that organizes software-engineering actions without relying on an unrestricted autonomous-agent loop [27]. These systems demonstrate that repository exploration, tool use, and iterative validation can be organized through different agent architectures and levels of autonomy. Repository-Level Benchmarks. The evaluation of LLM-based repair agents has increasingly moved beyond isolated code snippets toward tasks involving real software repositories. SWE-bench evaluates whether language models can resolve issues collected from real-world GitHub repositories [11]. Subsequent benchmarks extend the task scope to visual software domains and longer-horizon engineering activities. SWE-bench Multimodal incorporates visual and user-facing JavaScript tasks, while SWE-Bench Pro targets longer-horizon, enterprise-oriented repository work [5, 33]. SWE-Gym provides executable environments for training software-engineering agents and verifiers [22]. SWE-smith focuses on scaling the construction of software-engineering training tasks [34]. DeepSWE further studies long-horizon engineering tasks with program-based verifiers [8]. Beyond task completion, studies of agent trajectories and code-execution cost examine the interactions between model reasoning, tool invocation, and execution resources [3, 17]. DEIA uses bounded source evidence and content-anchored edits, followed by deterministic patch materialization and stage-level records linking generation to validation. 7.3

Behavioral Validation

Generating an applicable patch or removing an observed failure does not necessarily establish that the modified program behaves correctly. Behavioral validation requires determining which properties should hold after a modification and whether the available execution evidence is sufficient to assess them. Existing research addresses this problem through test-oracle construction, patch assessment, and test generation. Test Oracles. The oracle problem in software testing concerns how to determine whether an observed execution result is correct when an executable test does not provide an expected answer [1]. This problem is particularly important in automated repair, where a candidate patch may satisfy the available test suite without preserving the intended program semantics. Prior studies investigate patch overfitting and develop techniques for assessing patch correctness beyond test-suite acceptance [15, 23, 35]. Test-generation research further examines how additional inputs and assertions can

Evidence-Grounded Crash Repair for ArkTS

21

improve fault detection and support program repair [36]. However, increasing test coverage or the number of assertions does not automatically establish a trustworthy semantic oracle. The expected behavior against which an execution is judged remains a separate requirement. F2P/P2P Validation. A complementary distinction in repair evaluation concerns the different behavioral objectives of fail-to-pass (F2P) and pass-to-pass (P2P) checks. F2P checks target the removal of an existing failure, whereas P2P checks examine whether previously valid behavior is preserved after a modification. These distinctions already appear in repository-level repair benchmarks and platform-oriented evaluation protocols [11, 29]. The categories themselves are not novel. Their effectiveness nevertheless depends on the quality of the expected-behavior specifications and the reliability of the corresponding execution oracles. A test that can be executed but lacks a supported expected outcome cannot provide sufficient evidence of behavioral correctness. Similarly, a test whose required interaction or observable signal is unavailable cannot be treated as a completed validation. Building on established F2P/P2P and test-oracle concepts, DEIA represents each fault- or change-derived check as an obligation with an expected property, evidence source, prerequisites, and observable signal. Checks lacking sufficient support or observability remain pending. 8

Conclusion and Future Work

DEIA links each candidate patch to the crash report that motivated it, the source it changes, and the build and replay records used to assess it. It specifies which behaviors need checking and which observations would support each judgment. Across 30 tasks, DEIA produced 30 candidate patches. All 30 generated patches passed the applicability check. The 30 delivered patches were byte-identical to the generated artifacts and also passed the check. On 29 matched tasks, the first added line exactly matched a reference edit location in 25 DEIA patches and 19 OpenHands patches. With one run per workflow and task, DEIA used 81.5% fewer tokens, made 60.8 measurements end at patch materialization. Device assessment covered 28 runtime fault cases and one build-gate case. Each workflow also had 87 patched-side reachability and smoke observations. The original DEIA assessment executed two of the 58 behavior-specific P2P checks, both for the same repair pattern. The remaining checks and untested paths leave the broader behavioral effects of these patches open. Future work will focus on verifying behavior that the current replay leaves unresolved. One priority is to run the same valid interaction on the original and patched applications and check both outcomes against an independently reviewed expectation. A regression control would then introduce a patch that removes the crash while breaking that interaction. For example, a list might stop crashing at its boundary but silently ignore a valid reorder. Detecting that change on the emulator would test whether the P2P check can expose a regression even when the F2P check passes. Repeated runs on fresh crash cases with a pinned baseline would separately quantify variation in repair outcomes and generation cost. References [1] Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz, and Shin Yoo. 2015. The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering 41, 5 (2015), 507–525. https://doi.org/10.1109/TSE.2014.2372785 [2] Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2025. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. In Proceedings of the 47th IEEE/ACM International Conference on Software Engineering (ICSE). IEEE, Ottawa, Canada, 2188–2200. https://doi.org/10.1109/ICSE55347. 2025.00157

22

Xuhui Lu, Zhihao Liu, Xiaoke Fang, Yuhuan Fan, Yanzhe Tang, Xiaohui Wan, Xiaoyu Wu, and Zheng Zheng

[3] Islem Bouzenia and Michael Pradel. 2025. Understanding Software Engineering Agents: A Study of Thought-Action-Result Trajectories. In Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, Seoul, Korea. https://doi.org/10.1109/ ASE63991.2025.00234 [4] Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. 2024. Teaching Large Language Models to Self-Debug. In International Conference on Learning Representations (ICLR). OpenReview.net, Vienna, Austria. [5] Xiang Deng, Jeff Da, Edwin Pan, Yannis Yiming He, Charles Ide, Kanak Garg, Niklas Lauffer, Andrew Park, Nitin Pasari, Chetan Rane, Karmini Sampath, Maya Krishnan, Srivatsa Kundurthy, Sean Hendryx, Zifan Wang, Chen Bo Calvin Zhang, Noah Jacobson, Bing Liu, and Brad Kenstler. 2025. SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? arXiv:2509.16941 [cs.SE] https://arxiv.org/abs/2509.16941 [6] Luca Gazzola, Daniela Micucci, and Leonardo Mariani. 2019. Automatic Software Repair: A Survey. IEEE Transactions on Software Engineering 45, 1 (2019), 34–67. https://doi.org/10.1109/TSE.2017.2755013 [7] Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2012. GenProg: A Generic Method for Automatic Software Repair. IEEE Transactions on Software Engineering 38, 1 (2012), 54–72. https://doi.org/10.1109/TSE.2011.104 [8] Wenqi Huang, Charley Lee, Leonard Tng, and Serena Ge. 2026. DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks. arXiv:2607.07946 [cs.SE] https://arxiv.org/abs/2607.07946 [9] Huawei. 2026. ArkTS: Introduction. https://developer.huawei.com/consumer/en/arkts/ Official HarmonyOS developer documentation; accessed 2026-11-07. [10] Huawei. 2026. JS Crash (Process Crash) Detection. https://developer.huawei.com/consumer/en/doc/harmonyos-guides/jscrash-guidelines/ Official HarmonyOS developer documentation; accessed 2026-11-07. [11] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. In International Conference on Learning Representations (ICLR). OpenReview.net, Vienna, Austria. [12] Harshit Joshi, José Cambronero, Sumit Gulwani, Vu Le, Ivan Radicek, and Gust Verbruggen. 2023. Repair Is Nearly Generation: Multilingual Program Repair with LLMs. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 37. AAAI Press, Washington, DC, USA, 5131–5140. https://doi.org/10.1609/aaai.v37i4.25642 [13] René Just, Darioush Jalali, and Michael D. Ernst. 2014. Defects4J: A Database of Existing Faults to Enable Controlled Testing Studies for Java Programs. In Proceedings of the 23rd International Symposium on Software Testing and Analysis (ISSTA). ACM, San Jose, CA, USA, 437–440. https://doi.org/10.1145/2610384.2628055 [14] Dongsun Kim, Jaechang Nam, Jaewoo Song, and Sunghun Kim. 2013. Automatic Patch Generation Learned from Human-Written Patches. In Proceedings of the 35th International Conference on Software Engineering (ICSE). IEEE, San Francisco, CA, USA, 802–811. https://doi.org/10.1109/ ICSE.2013.6606626 [15] Thanh Le-Cong, Duc-Minh Luong, Xuan Bach D. Le, David Lo, Nhat-Hoa Tran, and Quyet-Thang Huynh. 2023. Invalidator: Automated Patch Correctness Assessment via Semantic and Syntactic Reasoning. arXiv:2301.01113 [16] Yuanchun Li, Ziyue Yang, Yao Guo, and Xiangqun Chen. 2017. DroidBot: A Lightweight UI-Guided Test Input Generator for Android. In 2017 IEEE/ACM 39th IEEE International Conference on Software Engineering Companion (ICSE-C). IEEE, Buenos Aires, Argentina, 23–26. https: //doi.org/10.1109/ICSE-C.2017.8 [17] Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, and Li Li. 2026. To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair. arXiv:2606.26978 [cs.SE] https://arxiv.org/abs/2606.26978 [18] Kui Liu, Anil Koyuncu, Dongsun Kim, and Tegawendé F. Bissyandé. 2019. TBar: Revisiting Template-Based Automated Program Repair. In Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, Beijing, China, 31–41. https: //doi.org/10.1145/3293882.3330577 [19] Zhijie Liu, Yutian Tang, Meiyun Li, Xin Jin, Yunfei Long, Liang Feng Zhang, and Xiapu Luo. 2026. LLM-CompDroid: Repairing Configuration Compatibility Bugs in Android Apps with Pre-trained Large Language Models. ACM Transactions on Software Engineering and Methodology 35, 3 (2026), 63. https://doi.org/10.1145/3736406 [20] Ke Mao, Mark Harman, and Yue Jia. 2016. Sapienz: Multi-Objective Automated Testing for Android Applications. In Proceedings of the 25th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, Saarbrücken, Germany, 94–105. https://doi.org/10.1145/2931037. 2931054 [21] Kevin Moran, Mario Linares-Vásquez, Carlos Bernal-Cárdenas, Christopher Vendome, and Denys Poshyvanyk. 2016. Automatically Discovering, Reporting and Reproducing Android Application Crashes. In 2016 IEEE International Conference on Software Testing, Verification and Validation (ICST). IEEE, Chicago, IL, USA, 33–44. https://doi.org/10.1109/ICST.2016.34 [22] Jiayi Pan, Xingyao Wang, Graham Neubig, Navdeep Jaitly, Heng Ji, Alane Suhr, and Yizhe Zhang. 2025. Training Software Engineering Agents and Verifiers with SWE-Gym. In Proceedings of the 42nd International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 267). PMLR, Vancouver, Canada, 47717–47737. https://proceedings.mlr.press/v267/pan25g.html [23] Edward K. Smith, Earl T. Barr, Claire Le Goues, and Yuriy Brun. 2015. Is the Cure Worse Than the Disease? Overfitting in Automated Program Repair. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE). ACM, Bergamo, Italy, 532–543. [24] Ting Su, Guozhu Meng, Yuting Chen, Ke Wu, Weiming Yang, Yao Yao, Geguang Pu, Yang Liu, and Zhendong Su. 2017. Guided, Stochastic Model-Based GUI Testing of Android Apps. In Proceedings of the 2017 ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, Paderborn, Germany, 245–256. https://doi.org/10.1145/3106237.3106298

Evidence-Grounded Crash Repair for ArkTS

23

[25] Shin Hwei Tan, Zhen Dong, Xiang Gao, and Abhik Roychoudhury. 2018. Repairing Crashes in Android Apps. In Proceedings of the 40th International Conference on Software Engineering (ICSE). ACM, Gothenburg, Sweden, 187–198. https://doi.org/10.1145/3180155.3180243 [26] Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Daniel Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. 2025. OpenHands: An Open Platform for AI Software Developers as Generalist Agents. In International Conference on Learning Representations (ICLR). OpenReview.net, Singapore. https://arxiv.org/abs/2407.16741 [27] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2024. Agentless: Demystifying LLM-based Software Engineering Agents. arXiv:2407.01489 [28] Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2024. Automated Program Repair via Conversation: Fixing 162 out of 337 Bugs for $0.42 Each Using ChatGPT. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, Vienna, Austria, 819–831. https://doi.org/10.1145/3650212.3680323 [29] Bang Xie, Hao Liu, Zhenyu Shi, Yonghao Zhang, Senjian Zhang, Zhiyuan Peng, Xin Yin, Chenhao Ying, Yuan Luo, Wei Chen, Haiming Jin, Shaocong Long, Xu Liu, and Zhe Peng. 2026. AppEval: A Unified Benchmark for LLM-Based Mobile Application Repair in ArkTS, Swift, and Kotlin. arXiv:2608.18588 https://arxiv.org/abs/2608.18588 [30] Bang Xie, Senjian Zhang, Zhiyuan Peng, Wei Chen, Xin Yin, Chenhao Ying, and Yuan Luo. 2026. ArkEval: Benchmarking and Evaluating Automated Code Repair for ArkTS. In Proceedings of the 41st IEEE/ACM International Conference on Automated Software Engineering (ASE). ACM, Munich, Germany. https://doi.org/10.1145/3832783.3837514 [31] Boyang Yang, Zijian Cai, Fengling Liu, Bach Le, Lingming Zhang, Tegawendé F. Bissyandé, Yang Liu, and Haoye Tian. 2025. A Survey of LLM-Based Automated Program Repair: Taxonomies, Design Paradigms, and Applications. arXiv:2506.23749 [32] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: Agent–Computer Interfaces Enable Automated Software Engineering. In Advances in Neural Information Processing Systems (NeurIPS). Curran Associates, Inc., Vancouver, Canada. https://doi.org/10.52202/079017-1601 [33] John Yang, Carlos E. Jimenez, Alex L. Zhang, Kilian Lieret, Joyce Yang, Xindi Wu, Ori Press, Niklas Muennighoff, Gabriel Synnaeve, Karthik R. Narasimhan, Diyi Yang, Sida I. Wang, and Ofir Press. 2025. SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains?. In International Conference on Learning Representations (ICLR). OpenReview.net, Singapore. https://openreview.net/forum?id=riTiq3i21b [34] John Yang, Kilian Lieret, Carlos E. Jimenez, Alexander Wettig, Kabir Khandpur, Yanzhe Zhang, Binyuan Hui, Ofir Press, Ludwig Schmidt, and Diyi Yang. 2025. SWE-smith: Scaling Data for Software Engineering Agents. In Advances in Neural Information Processing Systems (NeurIPS) Datasets and Benchmarks. Curran Associates, Inc., San Diego, CA, USA. arXiv:2504.21798 https://arxiv.org/abs/2504.21798 [35] He Ye, Matias Martinez, and Martin Monperrus. 2021. Automated Patch Assessment for Program Repair at Scale. Empirical Software Engineering 26, 2 (2021), 20. https://doi.org/10.1007/s10664-020-09920-w [36] Zhongxing Yu, Matias Martinez, Benjamin Danglot, Thomas Durieux, and Martin Monperrus. 2017. Test Case Generation for Program Repair: A Study of Feasibility and Effectiveness. arXiv:1703.00198 [37] Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. AutoCodeRover: Autonomous Program Improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, Vienna, Austria, 1592–1604. https://doi.org/10. 1145/3650212.3680384

Related documents

• CVE-2026-99204#1493760
• CVE-2026-104427 — HIGH 8.2#1175931
• Beyond Crash-to-Patch: Patch Evolution for Linux Kernel Repair#1613390
• CVE-2026-96423 — MEDIUM 5.5#1147429
• CVE-2026-112170 — MEDIUM 6.3#1627177