dotnet / dotnet/runtime

Add OpenHarmony (HarmonyOS) support to the .NET runtime

Open
#132,866 6 comments 1 reaction 0 assignees View on GitHub
area-Infrastructure untriaged
Dominant language
C#
Stars
18.3k
Forks
5.6k
PR merge metrics
PR metrics pending

Description

## Summary

.NET currently supports Android (`linux-bionic`) and the Apple mobile platforms (`ios-*`, `tvos-*`, `maccatalyst-*`), but not OpenHarmony / HarmonyOS. OpenHarmony is an open-source operating system for phones, tablets, and IoT devices, and HarmonyOS NEXT is the commercial distribution built on it. Adding .NET support would allow C#/.NET applications and libraries to run on this platform.

This issue tracks the overall porting effort. The work is split into a series of PRs so each piece can be reviewed independently.

## Scope

1. **Runtime sandbox fixes** — OpenHarmony app sandboxes differ from a plain Linux environment in ways that break .NET at startup or at runtime:
- `/tmp` is mounted read-only; shared-memory files must honor `TMPDIR`.
- The `get_mempolicy`/`mbind` syscalls are blocked by the sandbox's seccomp policy, so the GC NUMA probe SIGSYS-crashes the process at startup.
- The sysroot's pthread lacks robust-mutex support, so `NamedMutex` must use the shared-memory-file implementation.
- Tracked by: https://github.com/dotnet/runtime/pull/132827 (first PR of the series, currently ready for review).
2. **Build infrastructure** — `-os linux-ohos` support: RID graph entry, NDK/sysroot toolchain plumbing, and CI cross-build legs mirroring `linux-bionic`.
3. **Runtime (CoreCLR/Mono) enablement** — platform-level bring-up, PAL adjustments, and validation on OpenHarmony devices/emulators.
4. **Tests & validation** — targeted test legs for the `linux-ohos` RID.

## Approach

- Follow the existing `linux-bionic` (Android) and `linux-musl` patterns for cross-compilation and RID plumbing.
- Keep every PR independently reviewable and a no-op on existing platforms: new behavior is guarded by `TARGET_OHOS`, which is only defined when the new target is selected.

## Open questions

- Which HarmonyOS API level and NDK version to target.
- Whether to support both OpenHarmony (open source) and HarmonyOS NEXT (commercial) from the start.
- Mono vs CoreCLR prioritization for the first milestone.

> [!NOTE]
> This issue was authored with AI assistance (Copilot/agent tooling) under the repository owner's direction.

Contributor guide

Open the contributing guide

Research direction

Start by reading PR 132827, then compare the existing linux-bionic and linux-musl approaches mentioned in the issue. Choose one independently reviewable area—RID and toolchain plumbing, TARGET_OHOS runtime enablement, or targeted validation—and confirm that the corresponding linux-ohos build or test path works without changing existing platforms.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, linux
Domain
build-system, mobile-dev, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.