ArkAnalyzer Pointer Analysis Kit (APAK)

• APAK is a context-sensitive pointer analysis framework for ArkTS that uses a novel heap abstraction and plugin-based design to accurately model closures and storage APIs.
• It improves recall by 34.2% over RTA and reduces false positives to around 2%, addressing key challenges in closure tracking and API integration.
• The framework demonstrates scalability and efficiency on large OpenHarmony applications, enabling advanced program analyses such as taint tracking and security vetting.

The ArkAnalyzer Pointer Analysis Kit (APAK) is a context-sensitive pointer analysis framework engineered specifically for ArkTS, the TypeScript-based language underpinning OpenHarmony. APAK addresses the unique semantic and technical demands of ArkTS—particularly in closure analysis, context sensitivity, and deep integration with ArkUI and storage APIs—through a novel heap abstraction and a plugin-based architecture. It has been incorporated into the ArkAnalyzer static analysis framework and evaluated at scale across a substantial corpus of OpenHarmony applications, yielding demonstrably higher recall and lower false positive rates than established approaches such as Class Hierarchy Analysis (CHA) and Rapid Type Analysis (RTA) (Yang et al., 31 Jan 2026).

1. Motivation and Problem Landscape

Static call graph generation in ArkTS presents challenges not encountered in classic JavaScript or TypeScript contexts due to ArkTS’s first-class closures and the ArkUI component model, which is tightly integrated with OpenHarmony’s lifecycle and storage mechanisms. Existing static analysis tools, including CHA and RTA, exhibit two dominant limitations when applied to ArkTS:

• Closure Tracking: CHA and RTA either merge all anonymous functions at a single node or fail to distinguish dynamically created closures, leading to imprecise tracking of function-valued fields.
• Framework API Interactions: ArkTS programs frequently transfer objects (notably closures) into global stores such as AppStorage. CHA and RTA do not model the semantics of these storage APIs, resulting in topological fractures in the call graph and underapproximation of reachability.

These issues translate directly into reduced valid-edge coverage and increased false-positive rates in call graphs, impeding downstream analyses such as data flow and vulnerability detection. APAK is designed to:

1. Maximize recall (valid-edge coverage) while maintaining manageable over-approximation.
2. Minimize false positive rate (≤2%).
3. Support the full breadth of ArkTS features, including closures, decorators, and storage APIs.
4. Ensure context sensitivity to distinguish multiple instances of code execution.
5. Provide a plugin interface for supporting evolving ArkUI or SDK APIs without core modifications (Yang et al., 31 Jan 2026).

2. ArkTS Heap Object Model

APAK introduces a heap object model that abstractly represents every runtime object or closure as a unique abstract object. The formal components are:

• O: Set of abstract objects, each associated with allocation sites or lambda definitions.
• F: Set of field names.
• C: Set of analysis contexts (as defined by recent call-site sequences).

Pointers are defined as $P = V \cup (O \times F)$, where $V$ represents program variables (locals, globals, parameters), and each pointer $p \in P$ maps to a points-to set $\mathrm{pts}(p) \subseteq O$.

Key properties enforced:

• Field Sensitivity: For every abstract object $o$ and field $f$, a distinct pointer $(o,f)$ is introduced.
• Closure Environment: A closure object $o_\text{closure}$ maintains an environment mapping—$$\mathrm{env}(o_\text{closure}) : \text{Var}_\text{free} \rightarrow O$$—recording captured free variables during closure creation.

Hence, the heap model is summarized as the triple $(O, F, \mathrm{env})$, extending field sensitivity to closure captures (Yang et al., 31 Jan 2026).

3. Context-Sensitive Pointer Analysis and Constraints

APAK instantiates a $k$-call-site-sensitive Andersen-style pointer analysis. Context abstraction is formalized as:

• Sites: Set of call-site identifiers (e.g., line numbers).
• C: Sequence of up to $k$ recent call sites, $c = [s_1, ..., s_m]$, $m \leq k$.
• Context Extension: On call at site $s$, $c' = \operatorname{extend}(c, s)$, achieved by appending $s$ or sliding the window when $|c| = k$.

The analysis generates a Points-to Assignment Graph (PAG) where each node is a pointer under context, and edges encode inclusion constraints. Transfer rules include:

1. Allocation: Links allocation sites to fresh abstract objects.
2. Assignment: Propagates points-to information through assignments.
3. Store/Load: Models field accesses with field sensitivity.
4. Call: Handles static, virtual, and function-pointer invocations with proper context extension.

Convergence to a least fixpoint is guaranteed by the monotonicity of points-to set inclusion. The solution is sound, over-approximating concrete object reference flows. The worst-case computational complexity is $$|\text{contexts}| \times |\text{variables}| \times |O|$$, but empirical analysis with $k=2$ or $3$ shows practical scalability (Yang et al., 31 Jan 2026).

4. Plugin Architecture and Extensibility

APAK achieves extensibility via a plugin manager that mediates all ArkTS/OpenHarmony-specific pointer operations. For each dynamic call or framework API, the engine dispatches to registered plugins implementing the ICallPlugin interface, allowing for specialized modeling without changes to the analysis core.

• Registration: Plugins register via pattern-based API signatures.
• Execution: For each matched API call, the plugin modifies the PAG and (optionally) the call graph as appropriate.
• Examples:
  • ArkUI Components: Plugins allocate component objects, wire lifecycle methods, and simulate decorator-generated invocations.
  • Storage APIs: The storage plugin models AppStorage’s set/get semantics, allocating pseudo-fields in storage objects and introducing backflow edges for bidirectional synchronization.

Built-in plugins (e.g., StoragePlugin, SDKPlugin, ArkUIComponentPlugin) are registered by default. Developers can introduce new plugins by implementing the interface and adding them to the system registry, ensuring adaptability to evolving APIs (Yang et al., 31 Jan 2026).

5. Empirical Evaluation

APAK was evaluated on a comprehensive dataset of 1,663 real-world OpenHarmony ArkTS applications (API levels 9–12). Key results include:

• Call-Graph Scale:
  • CHA: ≈ 260,000 edges
  • RTA: ≈ 190,000 edges
  • APAK: ≈ 240,000 edges
• Accuracy:
  • APAK recall is 34.2% higher than RTA and 7.1% lower than CHA (implying superior pruning of false positives).
  • Precision/falsity table from evaluation (extract):

Application	APAK Precision	APAK Recall	CHA Precision	CHA Recall	RTA Precision	RTA Recall
AACommandpackage	100.0%	78.5%	100.0%	70.8%	100.0%	52.3%
ActsRegisterJsErrorRely	100.0%	85.9%	89.3%	51.0%	93.0%	42.1%
AdaptiveServiceWidget	100.0%	84.9%	75.2%	75.2%	75.3%	56.5%

• False Positive Rate: CHA/RTA yield ~20% FPR; APAK achieves ~2%.
• Efficiency (on 1,663 apps, $k=2$):
  • Success rate: 99.4%
  • Median analysis time: 53 ms (IQR 33–160 ms)
  • 95th-percentile memory: 285 MB
  • Large apps (<10K LOC): analysis <200 ms
  • On a commercial 1.2M LOC app: 370–720 s, 5.4–6.9 GB memory.

This suggests that analysis cost is dominated by call chain depth rather than program size per se. APAK consistently completes on large applications, demonstrating industrial feasibility (Yang et al., 31 Jan 2026). Higher recall and reduced false positives directly enable higher-precision downstream analyses, such as crypto misuse detection and security vetting.

6. Implementation and Integration

APAK is implemented in Kotlin and Java, comprising approximately 5,000 lines of new code within the ArkAnalyzer codebase. It operates on the ArkIR intermediate representation—desugared TypeScript AST. Plugins are packaged as Java ServiceLoader modules under analyzer/plugins/.

Integration requires:

1. Invoking APAK within the ArkAnalyzer pipeline (supplanting CHA/RTA).
2. Registering built-in plugins.
3. Optional developer extension via the plugin API.

APAK is merged in ArkAnalyzer v1.3 and distributed as part of the open-source repository at https://gitee.com/openharmony/arkanalyzer.

7. Impact and Future Directions

APAK is the first context-sensitive, plugin-based pointer analysis framework for ArkTS, offering a hybrid heap object model and deep framework modeling that significantly increases call-graph coverage while reducing false positives compared to CHA and RTA. Its extensible architecture enables rapid adaptation to new ArkUI and SDK APIs as the OpenHarmony platform evolves. The higher recall and precision of APAK’s output directly benefit advanced program analysis such as taint tracking, type inference, and security vetting, establishing a robust foundation for further research and tool development in the OpenHarmony ecosystem (Yang et al., 31 Jan 2026).