Improve HarmonyOS Detection Code #2162

cyberMilosz · 2026-01-20T01:46:04Z

Summary

Current HarmonyOS detection code assumes that uname will accurately identify the OS. However, this is not the case on more recent emulators (as they seem to just use the Linux kernel):

# uname -a
Linux localhost 5.10.210 #1 SMP Tue Nov 11 15:26:56 CST 2025 x86_64

Real hardware still identifies itself correctly:

$ uname -a
HarmonyOS localhost HongMeng Kernel 1.10.5 #1 SMP Wed Dec 24 05:34:51 UTC 2025 aarch64

Instead of uname, we should rely on param output - we can get the OS name, version, API version, and security patch like so:

Emulator:

# param get const.product.os.dist.name
HarmonyOS
# param get const.product.os.dist.version
6.0.0
# param get const.product.incremental.version
6.0.1.112
# param get const.ohos.apiversion
21
# param get const.product.software.version.name
HarmonyOS NEXT Developer Beta1
# param get const.product.software.version
emulator 6.0.0.112(SP3DEVC00E112R4P11)
# param get const.ohos.version.security_patch
2025/11/01

Real hardware (note param get const.product.software.version.name appears to be a recent addition, so it's missing here):

$ param get const.product.os.dist.name
HarmonyOS
$ param get const.product.os.dist.version
5.1.0
$ param get const.product.incremental.version
5.1.1.208
$ param get const.ohos.apiversion
19
$ param get const.product.software.version.name
Get parameter "const.product.software.version.name" fail! errNum is:106!
$ param get const.product.software.version
TXZ-W10M 5.1.0.151(C00E151R4P1)
$ param get const.ohos.version.security_patch
2026/01/01

Tested on multiple Huawei emulators [6.0.1(21), 5.1.1(19), 5.1.0(18)] and a Huawei MatePad 11.5 running HarmonyOS 5.1.0.151

Example output from a current emulator:

Changes

Introduce HarmonyOS detection logic based on param output, falling back to existing uname logic as a last resort.

Checklist

I have tested my changes locally.

Existing code relied on `uname` accurately identifying itself as HarmonyOS, but Huawei's official emulators are still running the Linux kernel (unlike physical devices). This change adds support for identifying HarmonyOS 5+ and retrieving system parameters including version, build ID, and security patch date.

Copilot

Pull request overview

Improves HarmonyOS detection on Linux by using param get system parameters (with fallback to existing uname/sysinfo-based logic) to handle newer HarmonyOS emulators that report uname as Linux.

Changes:

Added detectHarmonyOS() that queries HarmonyOS identity/version details via param get.
Wired HarmonyOS detection earlier in the Linux OS detection flow (before parsing os-release).
Clarified the existing HarmonyOS fallback comment for older versions.

Copilot · 2026-01-20T01:52:41Z

src/detection/os/os_linux.c

+    ffStrbufSetS(&os->id, "harmonyos");
+    ffStrbufSetS(&os->idLike, "harmonyos");
+    ffStrbufSetS(&os->name, "HarmonyOS");


ffStrbufSetS copies these constant literals into heap-allocated buffers. In this file (e.g., other distro detections above), constant identifiers/names are typically set with ffStrbufSetStatic to avoid unnecessary allocations. Consider using ffStrbufSetStatic for "harmonyos" / "HarmonyOS" here as well.

Suggested change

ffStrbufSetS(&os->id, "harmonyos");

ffStrbufSetS(&os->idLike, "harmonyos");

ffStrbufSetS(&os->name, "HarmonyOS");

ffStrbufSetStatic(&os->id, "harmonyos");

ffStrbufSetStatic(&os->idLike, "harmonyos");

ffStrbufSetStatic(&os->name, "HarmonyOS");

Copilot · 2026-01-20T01:52:41Z

src/detection/os/os_linux.c

+    // Read base version (e.g., 6.0.0)
+    FF_STRBUF_AUTO_DESTROY baseVersion = ffStrbufCreate();
+    if (ffProcessAppendStdOut(&baseVersion, (char* const[]) {
+        "param", "get", "const.product.os.dist.version",
+        NULL,
+    }) == NULL)
+    {
+        ffStrbufTrimRightSpace(&baseVersion);
+        if (baseVersion.length > 0)
+            ffStrbufSet(&os->version, &baseVersion);
+    }


param get appears to print failures to stdout (e.g., Get parameter "..." fail! errNum is:106! per the PR description), and ffProcessAppendStdOut does not treat non-zero exit codes as errors on Linux. That means this code can end up setting os->version to an error string. Please add output validation (e.g., detect the "Get parameter"/"fail!" pattern) and treat it as “missing value” before populating OS fields.

Copilot · 2026-01-20T01:52:42Z

src/detection/os/os_linux.c

+            // Append versionID if available
+            if (os->versionID.length > 0)
+            {
+                ffStrbufAppendC(&prettyName, ' ');
+                ffStrbufAppend(&prettyName, &os->versionID);
+            }
+            // Append API level (variant) if available
+            if (os->variant.length > 0)
+            {
+                ffStrbufAppendS(&prettyName, " (API ");
+                ffStrbufAppend(&prettyName, &os->variant);
+                ffStrbufAppendC(&prettyName, ')');
+            }
+            ffStrbufSet(&os->prettyName, &prettyName);


Same issue as above for const.product.software.version.name: on real devices where this key is missing, stdout contains a "Get parameter ... fail" message, which will currently be accepted as a valid pretty name and then augmented with version/API. Please filter out that failure output (and ideally any similar failure output) so os->prettyName isn’t set to an error string.

Suggested change

// Append versionID if available

if (os->versionID.length > 0)

{

ffStrbufAppendC(&prettyName, ' ');

ffStrbufAppend(&prettyName, &os->versionID);

}

// Append API level (variant) if available

if (os->variant.length > 0)

{

ffStrbufAppendS(&prettyName, " (API ");

ffStrbufAppend(&prettyName, &os->variant);

ffStrbufAppendC(&prettyName, ')');

}

ffStrbufSet(&os->prettyName, &prettyName);

/* Filter out obvious error outputs like "Get parameter ... fail" */

const char* prettyChars = prettyName.chars;

if (strstr(prettyChars, "Get parameter") == NULL &&

strstr(prettyChars, "get parameter") == NULL &&

strstr(prettyChars, "fail") == NULL &&

strstr(prettyChars, "not exist") == NULL)

{

// Append versionID if available

if (os->versionID.length > 0)

{

ffStrbufAppendC(&prettyName, ' ');

ffStrbufAppend(&prettyName, &os->versionID);

}

// Append API level (variant) if available

if (os->variant.length > 0)

{

ffStrbufAppendS(&prettyName, " (API ");

ffStrbufAppend(&prettyName, &os->variant);

ffStrbufAppendC(&prettyName, ')');

}

ffStrbufSet(&os->prettyName, &prettyName);

}

Copilot · 2026-01-20T01:52:42Z

src/detection/os/os_linux.c

+    // Read API version - store in variant field
+    FF_STRBUF_AUTO_DESTROY apiVersion = ffStrbufCreate();
+    if (ffProcessAppendStdOut(&apiVersion, (char* const[]) {
+        "param", "get", "const.ohos.apiversion",
+        NULL,
+    }) == NULL)
+    {
+        ffStrbufTrimRightSpace(&apiVersion);
+        if (apiVersion.length > 0)
+        {
+            ffStrbufSet(&os->variant, &apiVersion);
+        }


os->variant is used elsewhere as the OS “variant” (from os-release) and is displayed as (<variant>) in default output / JSON. Storing the raw API level number here (e.g., "21") makes the field ambiguous and will render as (21) in some output modes. Consider storing a descriptive value (e.g., prefixing with "API ") or using a different field/approach for API level.

Copilot · 2026-01-20T01:52:42Z

src/detection/os/os_linux.c

+    {
+        ffStrbufTrimRightSpace(&securityPatch);
+        if (securityPatch.length > 0)
+            ffStrbufSet(&os->codename, &securityPatch);


os->codename is exposed to users as the OS codename (see OS module output + JSON field codename). Setting it to the security patch date changes the meaning of that field and will be misleading for consumers expecting a codename. Consider either incorporating the security patch into prettyName/variant (as display-only info) or adding a dedicated field for security patch in FFOSResult and plumbing it through output/JSON.

Suggested change

ffStrbufSet(&os->codename, &securityPatch);

{

// Do not overwrite os->codename (exposed as OS codename).

// Instead, incorporate the security patch into prettyName as display-only info.

if (os->prettyName.length == 0)

{

ffStrbufSet(&os->prettyName, &securityPatch);

}

else

{

ffStrbufAppendS(&os->prettyName, " (");

ffStrbufAppendS(&os->prettyName, "Security patch: ");

ffStrbufAppend(&os->prettyName, &securityPatch);

ffStrbufAppendC(&os->prettyName, ')');

}

}

CarterLi · 2026-01-20T02:25:14Z

I assume the HarmonyOS command param is a variant of the Android command getprop. Is there an API like __system_property_get in Android? You spawn 8 processes in one module which is not acceptable to me.

In addition, please move HarmonyOS detection code after the standard os-release code, so it don't affect performance of major Linux distros.

cyberMilosz added 2 commits January 20, 2026 01:32

Merge branch 'fastfetch-cli:dev' into dev

d1934fb

Copilot AI review requested due to automatic review settings January 20, 2026 01:46

Copilot started reviewing on behalf of cyberMilosz January 20, 2026 01:48 View session

Copilot AI reviewed Jan 20, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Improve HarmonyOS Detection Code #2162

Improve HarmonyOS Detection Code #2162

cyberMilosz commented Jan 20, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

Copilot AI Jan 20, 2026

Uh oh!

CarterLi commented Jan 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-            ffStrbufSet(&os->codename, &securityPatch);
+        {
+            // Do not overwrite os->codename (exposed as OS codename).
+            // Instead, incorporate the security patch into prettyName as display-only info.
+            if (os->prettyName.length == 0)
+            {
+                ffStrbufSet(&os->prettyName, &securityPatch);
+            }
+            else
+            {
+                ffStrbufAppendS(&os->prettyName, " (");
+                ffStrbufAppendS(&os->prettyName, "Security patch: ");
+                ffStrbufAppend(&os->prettyName, &securityPatch);
+                ffStrbufAppendC(&os->prettyName, ')');
+            }
+        }

Uh oh!

Improve HarmonyOS Detection Code #2162

Are you sure you want to change the base?

Improve HarmonyOS Detection Code #2162

Conversation

cyberMilosz commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

CarterLi commented Jan 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

cyberMilosz commented Jan 20, 2026 •

edited

Loading