The Security Debt a New Operating System Can Inherit
OpenHarmony is the primary subject here: an independently implemented mobile operating system whose security design can still be compared with Android's. This series asks a deceptively simple question: if engineers replace the code, can they also leave behind the old system's design vulnerabilities? The answer matters because readers need more than a list of flaws. They need a way to tell whether a new operating system has genuinely changed its security assumptions, and whether the evidence supports confidence in the result.
The question has become more important as mobile platforms fragment and then begin to split away from Android. Android has been customized by many vendors, while Huawei's HarmonyOS evolved from an Android-based system toward an independent platform. OpenHarmony is the open-source project associated with that trajectory. The study examined it because it is a large, consequential mobile-OS reimplementation, not because it is a convenient stand-in for every emerging operating system. The paper reports that HarmonyOS has been deployed on more than one billion devices and argues that this expanding ecosystem has received far less security research than Android.
That imbalance creates a practical risk. An attacker who knows how an old mobile platform resolves an inter-app request, exposes a sensor, or shares system state may not need the same source code on a new platform. They may only need the same trust decision. OpenHarmony gives us a concrete case for examining that possibility.
From Android's dominance to OpenHarmony's independence
Android's scale made its weaknesses unusually visible. The paper describes Android as having more than three billion active devices and about 72 percent worldwide market share, with years of research into both coding mistakes and flaws in the way the system was designed. Vendors changed components for their own purposes, creating fragmentation. More recently, some vendors have begun replacing Android components with systems of their own. That transition changes the engineering problem: a team is no longer only maintaining a customized parent system, but it is also rebuilding the assumptions that make applications and system components work together.
OpenHarmony is a useful subject precisely because the study does not treat it as a simple Android fork. The researchers compared large AOSP and OpenHarmony snapshots and found no shared file paths, only a small number of shared directory paths, and very high code-distance measurements in sampled modules. Their core frameworks also use different dominant implementation languages. On that evidence, they describe OpenHarmony as an independent reimplementation rather than a copied codebase or a function-by-function rewrite.
But code independence does not settle the security question. Two systems can use different languages and internal structures while offering analogous roles to developers and users. Android has Activities, Broadcast Receivers, Content Providers, Intents, and Zygote. OpenHarmony has Abilities, Common Events, DataAbility, Wants, and appspawn. The names and implementations differ, but the security questions can rhyme: who may invoke a component, who may receive a message, which app may observe another app's state, and what happens when no trusted recipient is specified?
This matters because an operating system is also a contract between applications, system services, hardware, and the person holding the device. The contract includes visible rules—such as which permission an app must request—but also defaults and invisible assumptions. If an app can reach the same data through a system file, or if a component can accept a request without checking who sent it, the effective contract is wider than the documented one. A reimplementation may deliberately change its internals while preserving that contract for compatibility, developer familiarity, or convenience. In that situation, the security property that survives is not a class name or a copied function. It is the answer to a design question: which actor is trusted at this boundary?
That distinction keeps OpenHarmony at the center of the story. Android is not being used as a generic source of examples; it is the older design environment whose documented failures provide hypotheses about the newer system. The relevant relationship is between Android's historical design choices and OpenHarmony's corresponding security boundaries.
A design flaw is not the same as a broken line of code
The paper calls these failures Design-Level Vulnerabilities, or DLVs. A DLV is a weakness in the intended logic of a complex system. The system may be behaving exactly as its designers specified, yet that behavior creates an insecure or unintended outcome. An implementation bug, by contrast, is a mistake in realizing a design. A configuration error is a failure to set up an otherwise adequate design. Those categories can overlap in their consequences, but they do not transfer in the same way.
The distinction is easiest to see as a review of a rule rather than a review of a line. If a service accidentally skips an authorization check, fixing that check may remove the vulnerability without changing what the service is supposed to do. If the service is designed to accept a request from whichever component claims a certain action, then a perfectly faithful implementation can preserve the weakness. The design review must ask whether the rule itself identifies the right principal, limits the right capability, and remains safe when several components interact. It must also ask what happens at the edges: when a permission is absent, when a user is not looking at the screen, when data outlives an app, or when a developer uses a convenience path instead of the documented one. Those edge conditions are often where the system's real policy becomes visible.
Consider Android's implicit Intent mechanism. It was designed to let an app describe an action without naming one exact receiving component. The system then searches for a matching receiver. That flexibility reduces coupling: the sender does not need to know every possible component that can perform the action. But if any app can register a matching filter, a malicious component can intercept or spoof a request. The insecurity is in the trust rule used during resolution. Rewriting the resolver in another language would not remove the problem if the new system retained the same rule.
OpenHarmony's Want mechanism provides the study with a concrete comparison. A Want can likewise express an action without specifying the target Ability. The paper reports that a malicious app can register a sensitive Settings action and be launched instead of the intended system component, because critical system actions are not sufficiently protected. This is not evidence that OpenHarmony copied Android's resolver. It is evidence that a similar design choice can recreate a similar endpoint problem.
The same reasoning applies beyond inter-app messages. A permission can protect one API while a system file exposes equivalent information. A privacy indicator can tell users that a microphone is active while background recording remains possible. A performance optimization can make process layouts predictable even though each process still has its own nominal identity. In each case, the useful question is not simply “Is there a permission?” or “Is the code new?” It is “Where is the effective boundary, and does every route enforce it?”
A design vulnerability therefore requires a different kind of audit. Fuzzing and static analysis can find many implementation failures, but they may not reveal that the system has authorized the wrong recipient, exposed a globally observable counter, or made a high-fidelity sensor available at an unsafe rate. Those problems require an understanding of what the interface is meant to protect and which actors the design actually lets control or observe it.
The dotted connection in this model is the important one. Different implementation can interrupt code lineage without interrupting a shared trust decision. That is why the claim must remain conditional: a historical weakness transfers only when the newer system has an analogous feature or component and testing shows that the insecure behavior remains possible.
What the study can—and cannot—tell us
To test that conditional claim, the researchers reviewed 450 Android-related publications from major security conferences and selected 116 studies focused on design-level vulnerabilities, including technically substantial industry briefings. They extracted 56 distinct DLVs, examined how Android had mitigated them, and turned each into an implementation-independent audit method. They then checked whether the corresponding feature existed in OpenHarmony, located its relevant interfaces or system resources, and used proof-of-concept applications to test the design assumption.
The selection process matters as much as the final count. The researchers excluded work focused only on app vulnerabilities, malware, defenses without a new attack, and ordinary implementation defects such as memory corruption. Their 56 cases therefore represent a particular question: which weaknesses arise from the design of an Android-like mobile platform and can be expressed as a repeatable audit? The method does not measure the total number of bugs in either operating system. It also does not assume that a matching name proves a matching risk. A feature first has to exist in the newer system, and the relevant trust relationship then has to be examined in that system's own terms.
The resulting numbers are a ladder, not a single verdict. Of the 56 Android DLVs, 46 were applicable to OpenHarmony. Twenty-four of those applicable cases remained vulnerable: 17 fully and seven partially. The findings included privacy leakage, side channels that could help recover secrets, Bluetooth manipulation, permission-control bypasses, and a system-reliability risk. “Partially vulnerable” means that some attack paths were blocked or their impact reduced while the underlying exposure remained; it does not mean the same thing as fixed.
The study also found two cases where Android was vulnerable but OpenHarmony was not, including one involving volume-setting covert channels that third-party OpenHarmony apps could not use. That asymmetry matters. The argument is not that every Android weakness inevitably reappears, or that OpenHarmony is simply less secure. The stronger and more useful conclusion is that independent implementation does not guarantee that old design lessons have been learned.
The results are also bounded. The tests used stock OpenHarmony 4.1 and 5.1 on an OHarmPi phone. The authors later checked the 24 findings on a commercial HarmonyOS NEXT device and confirmed 20, while filesystem hardening or debugging restrictions prevented evaluation of four. OpenHarmony and HarmonyOS NEXT should therefore not be treated as interchangeable products, and the reported behavior should not be generalized to every release.
There is a time dimension as well. A design flaw may be fixed in one branch while remaining in another, and a new release may close one interface while opening a different route to the same state. The paper's comparison is consequently best read as a snapshot plus a method for repetition. It tells us what the researchers could reproduce in the tested versions; it does not certify that an untested version has the same exposure or that a later patch has solved the underlying design problem everywhere. This is especially important for a platform that is still replacing components and for vendors that may ship related but distinct products.
Finally, the research was disclosed to OpenHarmony maintainers; the authors report that six findings had been confirmed before submission, with the others under review, and that they received bug bounties totaling 25,000 CNY. That context reinforces the right use of the evidence: it is a defensive warning and a reusable way to audit design boundaries, not a universal ranking or an invitation to reproduce attacks against deployed devices. The next question is how a design assumption travels from an apparently convenient interface to a concrete security failure even when the underlying code is new.