Add OpenHarmony/HarmonyOS build infrastructure

[springmin]

Summary

First PR of the OpenHarmony (HarmonyOS) port series (tracking issue: #132866). This PR adds the build infrastructure for the openharmony target so the runtime can be cross-built with the HarmonyOS NDK. It is a no-op on all existing platforms: every change is guarded by TargetsOpenHarmony (only set when the build targets openharmony), and the standard platform CI matrix stays green.

Changes

File	Change
eng/build.sh	Accept --os openharmony; skip the rootfs requirement (NDK-based toolchain)
eng/RuntimeIdentifier.props	TargetsOpenHarmony property; openharmony keeps the Linux family flags (TargetsLinux) but is excluded from TargetsLinuxGlibc
eng/Subsets.props	DefaultSubsets for OpenHarmony (CoreCLR + NativeAOT, no Mono dependency); UseNativeAotForComponents exclusion (mirrors linux-bionic)
eng/native/build-commons.sh	OHOS NDK toolchain branch (OHOS_NDK_HOME, ohos.toolchain.cmake, OHOS_ARCH); rootfs bypass
eng/native/configureplatform.cmake	Map CMAKE_SYSTEM_NAME=OHOS to linux/musl; CLR_CMAKE_HOST_OPENHARMONY / CLR_CMAKE_TARGET_OPENHARMONY
eng/native/configurecompiler.cmake	OHOS compile flags (-Qunused-arguments, -fno-emulated-tls); TARGET_OPENHARMONY define (mirrors TARGET_ANDROID)
eng/native/configuretools.cmake	Hint find_program at the NDK compiler directory (empty hint on other platforms)
eng/native/gen-buildsys.sh	Rootfs bypass for the OHOS cross-build (the NDK toolchain is injected by build-commons.sh)
src/libraries/Microsoft.NETCore.Platforms/src/PortableRuntimeIdentifierGraph.json	Add the openharmony + arch RIDs to the portable graph (openharmony imports any, the arch RIDs import openharmony); the frozen runtime.json is untouched
src/native/libs/System.Native/CMakeLists.txt	Include OHOS in the "no robust mutexes" platform set
src/native/libs/build-native.sh	Treat openharmony like linux-bionic for cross-build detection

Impact on existing platforms

None. TargetsOpenHarmony is only defined when PortableOS == openharmony (i.e., when --os openharmony is passed). Every guarded condition either adds a new branch or excludes OpenHarmony from an existing condition in a way that is logically equivalent for all other platforms.

Validation

• Full clr.native+libs+host+packs --os openharmony -arch arm64 --cross cross-build succeeds: 0 Warning(s) 0 Error(s).
• The OpenHarmony RIDs live only in the portable RID graph; the frozen runtime.json is not modified.
• The eng/common additions for OpenHarmony hosts are intentionally not part of this PR: they are sent to dotnet/arcade as Add OpenHarmony support to eng/common arcade#17608 (init-os-and-arch.sh, init-distro-rid.sh, cross/toolchain.cmake) and sync back from there.
• Standard platform CI matrix must pass (no-op guarantee).
• Note: HarmonyOS CI legs are not part of this PR; the follow-up PRs add sysroot compile fixes, NativeAOT support, and RID/packs (see Add OpenHarmony (HarmonyOS) support to the .NET runtime #132866 for the full series).

Note

This PR was authored with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[jkotas]

This needs updates discussed and applied in #132827

[am11]

• Android is linux kernel + bionic libc (well bionic is more than a libc, it's a subsystem; but for our purposes when we say bionic to mean its libc part)
• linux-musl is for muscle libc based distros
• linux is for any libc (all that derive from linux). There is no linux-glibc, so when we combine linux-{arch} without specifying the libc slug, that implies linux glibc.

Now, saying OpenHarmony is uniquer than those would be an understatement:

• First it has Kernel Abstraction Layer (KAL): liteos, linux, hongmeng, bringYourOwn..
• They intended platforms to not target KAL directly, but rather treat each kernel separately.
  • clang/rust use linux-ohos, liteos-ohos etc.
  • rely on libc surface to avoid probing the underlying kernel
  • basically not getting any help from KAL but asking people to use libc abstraction (it's like saying POSIX libc is "neutral", which in practice, is only used by SunOS family and everyone else has their own libc..)
• Their libc is a "customized musllibc" and they have a "libc->bionic" bridge

I am not sure, given all that, how to fit into current RID structure: {baseOS}-{libcFlavor:optional}-{arch}.

Treating openharmony NOT as linux but its own thing maybe better but I'm not sure if we can avoid breaking our "libcFlavor" slot and still accommodate a generic "flavor" slot to fit in "kernelFlavor"? Perhaps:

"runtimes": {
    "openharmony": {
      "#import": ["unix"]
    },
    "openharmony-linux": {
      "#import": [ "openharmony", "linux" ]
    },
    "openharmony-hongmeng": {
      "#import": [ "openharmony" ]
    },
    "openharmony-liteos": {
      "#import": [ "openharmony" ]
    }
}

[jkotas]

openharmony-linux/openharmony-hongmeng/openharmony-liteos would make sense only if it is common for openharmony apps to violate the kernel abstraction and have different binaries depending on the underlying kernel.

[springmin]

@jkotas

Done — the updates discussed in #132827 have been applied to this branch: TargetOpenHarmony is now TargetsOpenHarmony (matching the TargetsAndroid/TargetsLinux naming pattern) across all 15 files, and the naming is consistent with #132827 (TargetsOpenHarmony / TARGET_OPENHARMONY / IsOpenHarmony). The branch was updated after your comment, so the description above reflects the current head.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

@jkotas @am11 — thanks for the detailed analysis, this is very helpful.

On @jkotas's question: OpenHarmony applications (HAP packages) are built against the SDK and libc abstraction, not against the kernel. A single application binary runs across the supported kernels, and producing kernel-specific binaries is not the common case. So I agree that kernel-flavored RIDs (openharmony-linux / openharmony-hongmeng / openharmony-liteos) are not needed — a single RID is the right call.

The liteos flavors in particular have no near-term .NET consumer: LiteOS-M (hundreds of KB of memory) is far too small to run CoreCLR at all, and LiteOS-A (MB-class memory) could support NativeAOT but would require significant rework to run CoreCLR. This port's target today is CoreCLR on OpenHarmony/HarmonyOS PC (Linux kernel, i.e. openharmony-linux / openharmony-hongmeng), also covering mobile devices — with the longer-term goal of full-stack .NET (desktop/mobile/etc.) application development on OpenHarmony PC. So the liteos RIDs would have no consumers for the foreseeable future.

For the single RID, I'd recommend keeping linux-ohos:

• Both OpenHarmony and HarmonyOS currently ship Linux-kernel-based releases, which is what this port targets today.
• It matches the naming already used by other language toolchains — as you noted, clang/rust target linux-ohos — so .NET stays consistent with the ecosystem and with the NDK's own toolchain conventions (ohos.toolchain.cmake targets linux-ohos).
• It fits the existing {baseOS}-{flavor} RID structure without introducing a new slot or KAL abstraction into the RID graph.

Whichever way the maintainers decide (linux-ohos, ohos, or openharmony), the rename cost is controllable: the RID strings are confined to the infrastructure files (eng/native/*, eng/RuntimeIdentifier.props, build-native.*, corehost.proj, the RID graph) and both the runtime and SDK repos change together, so we'll follow the final decision and update both PRs accordingly.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

@am11 @jkotas

Updating this thread with the RID decision and verification results.

RID decision: @jkoritzinsky has decided on ohos for OpenHarmony (see #132827). That supersedes my earlier linux-ohos recommendation — I'll implement the rename (linux-ohos → ohos) across the runtime and SDK repos once the name here is confirmed. One thing to settle: given your openharmony proposal in this thread, is ohos acceptable, or would you prefer openharmony as the base name? Both are kernel-agnostic.

Worth noting that the ecosystem itself is split on naming: the Node.js community uses openharmony, while the Rust and Ruby communities use linux-ohos (e.g. Rust's aarch64-unknown-linux-ohos targets). So there is no single established convention to follow — which makes the maintainers' choice here the deciding factor, and either way the rename cost stays controllable (RID strings are confined to the infrastructure files; runtime and SDK change together).

The kernel-flavored variants (openharmony-linux / openharmony-hongmeng / openharmony-liteos) remain unnecessary — on-device testing confirms HAP-style apps don't produce kernel-specific binaries, and the liteos flavors have no near-term .NET consumer (LiteOS-M cannot run CoreCLR; LiteOS-A would need significant rework).

On-device verification (HarmonyOS hardware, HongMeng Kernel 1.13.0, aarch64): the ported runtime runs natively on a real HarmonyOS device (RID linux-ohos-arm64, full CoreCLR+JIT: LINQ/generics/threads/GC all pass), and get_mempolicy → SIGSYS is confirmed on-device, validating the NUMA fix. Full details are in #132827. This gives the infrastructure PR real-hardware validation before CI legs exist.

Status of review items here: the TargetsOpenHarmony rename (per @jkotas) is applied across all 15 files and pushed; the PR description is updated. The remaining work is the RID string rename once the base name is confirmed, followed by a full cross-build re-verification.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

@jkotas

@jkotas — thanks for the review.

Terminology: fixed in d6dfed1d4bd — all comments now refer to OpenHarmony only (build-commons.sh and the other infra files).

On "pretending to be Linux": agreed, and this is exactly the kind of inconsistency the RID rename was meant to fix. Here's the refactor I'd like to apply, split into three explicit layers so nothing is inherited implicitly anymore:

1. CMake OS identity: CLR_CMAKE_HOST_OS stays ohos (no remap to linux). The OHOS branch explicitly declares what it inherits: CLR_CMAKE_HOST_UNIX, CLR_CMAKE_HOST_LINUX (the Linux system model the PAL is built around), and CLR_CMAKE_HOST_LINUX_MUSL — the latter because the OpenHarmony libc is genuinely musl-based, which I'd like to keep as an explicit fact rather than an implicit side effect. The architecture-detection branches apply to OHOS explicitly as well.
2. Compile-time macros: TARGET_LINUX remains defined for OHOS builds — the codebase is Linux-centric (hundreds of TARGET_LINUX guards across PAL/GC/VM), so dropping it would be a tree-wide refactor well beyond this port's scope. I'd treat it as explicit, documented inheritance, with TARGET_OPENHARMONY added alongside for OpenHarmony-specific behavior.
3. Audit: the 8 CLR_CMAKE_HOST_LINUX and 11 TARGET_LINUX_MUSL consumption points get verified one by one so nothing relies on the old implicit remap.

Two questions before I push this to the PR:

1. Is keeping TARGET_LINUX as an explicit compile-time inheritance acceptable, or do you want the deeper split (no TARGET_LINUX for OHOS, with TARGET_OPENHARMONY guards everywhere)? The latter is a much larger change.
2. Is keeping the musl semantics (TARGET_LINUX_MUSL / CLR_CMAKE_HOST_LINUX_MUSL) as an explicit fact acceptable, given the OpenHarmony libc is musl-based?

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[jkotas]

the codebase is Linux-centric (hundreds of TARGET_LINUX guards across PAL/GC/VM),

Have you done analysis of how many TARGET_LINUX guards are correct for OpenHarmony? For example, there are Linux syscall numbers hardcoded under Linux guards:

runtime/src/native/libs/System.Native/pal_process.c

Lines 26 to 38 in 04a9b1a

	#if defined(__linux__)
	#if !defined(HAVE_CLOSE_RANGE)
	#include <sys/syscall.h>
	#if !defined(__NR_close_range)
	// close_range was added in Linux 5.9. The syscall number is 436 for all
	// architectures using the generic syscall table (asm-generic/unistd.h),
	// which covers aarch64, riscv, s390x, ppc64le, and others. The exception
	// is alpha, which has its own syscall table and uses 546 instead.
	# if defined(__alpha__)
	# define __NR_close_range 546
	# else
	# define __NR_close_range 436
	# endif

. I assume that hardcoding Linux syscall numbers in OpenHarmony apps is abstraction violation and unsupported. It may happen to work currently, but it is not correct.

[am11]

Have you done analysis of how many TARGET_LINUX guards are correct for OpenHarmony?

Not that many:

$ git grep -E '(HOST|TARGET)_LINUX' | wc -l
     193

For a port to new platform, <200 lines is pretty trivial.

[springmin]

@jkotas — you're right, I hadn't done that analysis. I've now run it: code inventory + on-device verification (HarmonyOS, HongMeng Kernel 1.13.0, aarch64, with the ported runtime running).

Syscall numbers: they match the Linux generic table on the tested kernel (memfd_create=279, copy_file_range=285, membarrier=283, close_range=436 all reach the kernel with Linux numbers) — so the hardcodes "work" empirically. Agreed that's not a contract.

Seccomp audit (on-device, SIGSYS-trapped syscalls the runtime uses):

syscall	on-device	runtime handling
get_mempolicy	SIGSYS	already fixed via TARGET_OPENHARMONY (numasupport.cpp)
close_range	SIGSYS (all arg combos)	unhandled — crash risk
rseq	SIGSYS	degrades gracefully (apps run fine)
clone3	SIGSYS	musl falls back to clone (threads fine)

This is a version-dependent policy, not a permanent kernel limitation. When porting the Bun runtime to OpenHarmony I went through the same seccomp whitelist with the HarmonyOS team: they have agreed to relax the policy in HarmonyOS 7.1 to allow clone3, get_mempolicy, and close_range — only rseq stays blocked. So the degradation handling for the non-rseq syscalls can be temporary, while the rseq fallback is a permanent requirement. The bun port already proved these degradation patterns in practice (rseq → TLS fallback, clone3 → clone fallback), and .NET's runtime exhibits the same graceful behavior on-device (threads and apps run fine).

Your exact example is confirmed broken on the current policy: pal_process.c hardcodes __NR_close_range 436 in RestrictHandleInheritance (fork/exec path); the runtime has no SIGSYS handler, so reaching it kills the process. It's masked today because Process.Start uses posix_spawn. Fix: TARGET_OPENHARMONY guard — skip close_range and use SetCloexecForAllFdsFallback() — written so it can be revisited when 7.1 lands.

Full audit (in progress, will publish on this PR):

• A. Hardcoded __NR_* (15 files): close_range (fix above), get_mempolicy (fixed), memfd_create/copy_file_range/membarrier (verified working), riscv-only and hppa/ia64 libunwind entries (N/A for arm64).
• B. Linux-specific /proc//sys paths: all verified present on-device — low risk.
• C. Plain POSIX/musl guards: fine (OpenHarmony libc is musl-based).
• D. Seccomp-sensitive syscalls: table above; the 7.1 relaxation covers 3 of 4, rseq keeps its fallback permanently.

So: audit-driven, not blanket inheritance. The CMake identity refactor (OHOS as its own OS, no CLR_CMAKE_HOST_OS=linux remap) is independent of this and ready to push once you're OK with the musl fact inheritance.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

TARGET_LINUX / syscall audit — full report (as promised)

OHOS TARGET_LINUX / Syscall Audit Report

Date: 2026-09-01 · Device: HarmonyOS, HongMeng Kernel 1.13.0 (aarch64) · Runtime: .NET 11.0.0-rc.1.26451.1-ohos (running on device)

Purpose: Answer jkotas's review question — how many TARGET_LINUX guards are correct for OpenHarmony? Audit-driven, not blanket inheritance.

---

A. Hardcoded syscall numbers (__NR_*) — 15 files

#	File	Syscall	Number	On-device (HongMeng 1.13.0)	Verdict
1	System.Native/pal_process.c:303	close_range	436 (fallback hardcode)	SIGSYS (all args)	🔴 FIX NEEDED
2	System.Native/pal_io.c:1423	copy_file_range	285 (aarch64 fallback)	allowed (EINVAL → reaches kernel)	✅ OK
3	System.Native/pal_io.c:429/449	memfd_create	header	✅ works	✅ OK
4	minipal/memorybarrierprocesswide.c + pal/src/thread/process.cpp:69	membarrier	header	allowed (ret=25)	✅ OK
5	gc/unix/numasupport.cpp:60/89	get_mempolicy/mbind	header	SIGSYS / ENOSYS	✅ already fixed (TARGET_OPENHARMONY)
6	coreclr/minipal/Unix/doublemapping.cpp	memfd_create	header	✅ works	✅ OK
7	eventpipe/ds-ipc.c	memfd_create	header	✅ works	✅ OK
8	minipal/cpufeatures.c	riscv_hwprobe	—	N/A (riscv only)	N/A
9	pal/src/thread/context.cpp:2204	riscv_flush_icache	259	N/A (riscv only)	N/A
10-12	libunwind hppa/ia64	rt_sigreturn/sigreturn/getunwind	—	N/A (hppa/ia64)	N/A

Syscall numbers match the Linux generic table on the tested kernel (verified empirically) — but this is not a contract (openharmony-linux / harmony-ohos / liteos kernels may differ).

B. Linux-specific paths (/proc, /sys, /etc) — 10 distinct paths

Path	On-device	Used for
/proc/self/mountinfo, /proc/self/cgroup, /proc/self/statm	✅	cgroup/limits detection
/proc/mounts, /proc/self/stat	✅	mount/stat
/proc/meminfo	✅	memory info
/proc/self/maps (assumed), /proc/self/exe	✅	—
/sys/fs/cgroup	✅	cgroup v1 (freezer/pids, sandbox paths)
/sys/devices/system/node	—	NUMA (already skipped on OHOS)
/system/usr/icu/	—	ICU (OHOS has its own ICU)
/etc/os-release	❌ MISSING	distro detection — runtime falls back (RID comes from the graph, unaffected)

Verdict: low risk — all runtime-critical proc/sys paths verified present.

C. TARGET_LINUX guard surface — 48 files total, 23 C/C++/H source files

Area	Files with TARGET_LINUX
src/native/libs	7
src/coreclr/pal	1 (plus build files)
src/coreclr/gc	3
src/coreclr/vm	2
src/native/minipal, corehost, eventpipe	1 each
build/config (cmake/props, not counted above)	rest of 48

Classification by content (sampled): most guards are plain POSIX/musl behavior (libc-level, valid on OHOS since its libc is musl-based — factual inheritance), not Linux-syscall or Linux-path specific. Deep per-guard review continues for the remaining files (will publish as follow-up).

D. Seccomp whitelist audit — 7 syscalls trapped (SIGSYS) on-device

Syscall	Runtime usage	On-device	Handling	7.1 policy*
get_mempolicy (237)	GC NUMA probe	SIGSYS	✅ fixed (numasupport.cpp)	relaxed
close_range (436)	fork/exec cloexec sweep (pal_process.c)	SIGSYS	🔴 crash if reached (masked by posix_spawn today)	relaxed
inotify_init1 (294)	FileSystemWatcher backend (pal_io.c:1602)	SIGSYS	🔴 crash when used	not in bun's list — needs request or fallback
rseq (293)	TLS acceleration	SIGSYS	✅ graceful (apps run)	stays blocked
clone3 (435)	thread creation	SIGSYS	✅ musl falls back to clone	relaxed
openat2 (437)	not used by runtime	SIGSYS	✅ harmless	—
signalfd4 (289)	not used by runtime	SIGSYS	✅ harmless	—

* HarmonyOS 7.1 relaxation agreed with the HarmonyOS team during the Bun port covers clone3, get_mempolicy, close_range (everything except rseq). inotify_init1 is a .NET-specific gap — Bun doesn't use inotify, so it wasn't in the 7.1 list.

Other syscalls verified allowed (not SIGSYS): statx, pidfd_open, timerfd_create, eventfd2, getdents64, readlinkat, renameat2, epoll_create1, pipe2, dup3, gettid, set_robust_list, madvise, clock_gettime, nanosleep, wait4, rt_sigaction, ioctl, fcntl, socket, connect, accept4, recvmsg, sendmsg, mmap, munmap, openat, read, write, close, dup, rt_sigprocmask, memfd_create, copy_file_range, membarrier, futex, prctl, tgkill, epoll_pwait, ptrace, mprotect, mremap.

Required fixes (runtime)

1. close_range (pal_process.c): add TARGET_OPENHARMONY guard → skip syscall, use SetCloexecForAllFdsFallback(). Revisit after 7.1.
2. inotify_init1 (pal_io.c): TARGET_OPENHARMONY guard → return ENOTSUP (managed FileSystemWatcher reports unsupported; polling fallback can be added later). Also request inotify_init1 addition to the HarmonyOS whitelist.
3. rseq: keep the graceful-degradation path permanently (7.1 keeps it blocked).
4. No other changes required from this audit; remaining C-category guard review is informational.

Conclusion

• Syscall numbers match Linux today (empirical, not contractual).
• 7 syscalls trapped by seccomp; 2 are real crash risks (close_range, inotify_init1) → both get TARGET_OPENHARMONY guards.
• /proc//sys surface verified usable; /etc/os-release absent (handled).
• Approach: audit-driven, targeted TARGET_OPENHARMONY handling (same pattern as the NUMA fix), not blanket TARGET_LINUX inheritance.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[springmin]

@jkotas — one more result from the audit, now implemented in the runtime (commit 70ba6f54f25 on the feature branch; it will flow into the infra PR once we align on the earlier items).

A general SIGSYS recovery mechanism — the same idea the Bun runtime uses on OpenHarmony, and what Android's bionic does internally: the PAL installs a SIGSYS handler under TARGET_OPENHARMONY that converts seccomp traps into a recoverable -ENOSYS, so any whitelist-blocked syscall fails gracefully through the caller's existing fallback paths instead of killing the process. Verified on-device (HongMeng Kernel 1.13.0, aarch64): close_range, inotify_init1, get_mempolicy, and rseq all now return -ENOSYS (errno=38); an allowed syscall (memfd_create) is unaffected.

Design detail: the handler sets only the return register and leaves the instruction pointer untouched. That matches the standard Linux seccomp TRAP contract (unchanged PC → the kernel returns -ENOSYS itself), and on the HarmonyOS kernel the trapped syscall returns the value written to the return register — so the same handler is portable across kernels.

The per-syscall guards (close_range, inotify_init1) stay as compile-time defense-in-depth; the SIGSYS handler is the general safety net, so future whitelist changes or a newly-trapped syscall degrade to ENOSYS instead of a startup crash.

Note

This comment was drafted with AI assistance (Copilot/agent tooling) under the repository owner's direction.

[jkotas]

The CMake identity refactor (OHOS as its own OS, no CLR_CMAKE_HOST_OS=linux remap)

I guess we can pretend that ohos is linux flavor when compiling C/C++ code, Unlike the RID graph shape, this is a local decision that can be revisited later.

the PAL installs a SIGSYS handler under TARGET_OPENHARMONY that converts seccomp traps into a recoverable -ENOSYS

We are interested in hacks that are trying to leverage holes in seccomp enforcement. This should be done properly.

[springmin]

Friendly ping — is there anything else you'd like from my side before this can merge?

Current state on head cece42439a:

• Approved by @jkotas (2026-09-10); the remaining review request is with @am11.
• All build/test legs are green. The only red checks are the known infrastructure ones
  (Monitor Helix Jobs, plus the Build Analysis / Build Insights summaries it feeds),
  unrelated to these changes.
• Earlier review rounds are addressed; the remaining threads are outdated (the code has
  since changed).

Context: the follow-up OpenHarmony runtime-port PRs are prepared and ready to submit.
Knowing whether this infrastructure PR (and #132827) can land first — or whether you'd
prefer the follow-ups in a different order — would help me sequence them. Happy to
adjust to whatever is easiest on your side.

[am11]

eng/common/native and eng/common/cross changes are missing. I pushed them in the same PR and opened a parallel one in arcade during OpenBSD port. You can only push them to https://github.com/dotnet/arcade repo. Just search git grep -li openbsd and update those files in arcade. It will sync back to runtime in few days (or push eng/common changes here if you want to speed up the clock like we did for OpenBSD).

[jkotas]

This should import any like other top-level OSes

[springmin]

Fixed — openharmony now imports any, like the other non-unix top-level OS RIDs (win/browser/wasi), so the chain is openharmony-arm64 → openharmony → any → base:

"openharmony": {
  "#import": [
    "any"
  ]
},

be8e6f6988d; the arch RIDs keep the parent-only shape (win-x64, browser-wasm).

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

[springmin]

@am11 — the eng/common side is now sent to dotnet/arcade: dotnet/arcade#17608

• native/init-os-and-arch.sh — detect OpenHarmony/HarmonyOS hosts via the OHOS parameter service (param get const.ohos.fullname; devices report HarmonyOS or Linux from uname), mapped to the openharmony RID
• native/init-distro-rid.sh — non-portable RID openharmony.<api>-<arch> from param get const.ohos.apiversion (mirrors android.<sdk>-<arch>); the musl check is now scoped to linux targets so a musl build host cannot clobber __PortableTargetOS for another target OS
• cross/toolchain.cmake — include the NDK's ohos.toolchain.cmake, mirroring the Android NDK branch

No build-rootfs.sh counterpart: the OHOS NDK ships the sysroot, so there is no package rootfs to assemble (the cross flow skips ROOTFS_DIR, like Android/Darwin). Verified on a device: before, init-os-and-arch.sh exits with "Unsupported OS harmonyos detected!"; after, os=openharmony arch=arm64 and openharmony.26-arm64 / __PortableTargetOS=openharmony.

If you prefer, I can also drop the same hunks into this PR to speed up the sync (like OpenBSD did) — otherwise waiting for the arcade sync is fine.

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.