What Actually Transfers Across Operating Systems?
At this point, three facts about OpenHarmony need to be held together rather than reduced to one slogan: its implementation is substantially independent of Android's, its component roles are comparable to Android's, and a significant subset of historical Android design-level vulnerabilities was reproduced in those comparable surfaces. This checkpoint connects those facts so the reader can judge what the study's transfer claim means. The useful conclusion is not that OpenHarmony is “Android underneath,” nor that a new codebase is automatically secure, but that security assumptions can be compared at the level where systems assign authority, expose state, and route actions.
Different code, comparable responsibilities
The researchers' code comparison is unusually important because it removes the easiest explanation for the findings. If OpenHarmony had reused Android source code, discovering similar vulnerabilities would be unsurprising. The study instead compared large snapshots of AOSP and OpenHarmony and found no shared file paths and only five shared directory paths. AOSP was reported to contain about 1.54 million files and OpenHarmony about 1.15 million; the sampled non-core modules had Normalized Compression Distances between 0.9887 and 0.9994, where values close to one indicate distinct code. The core frameworks also differ in their dominant implementation languages: Android is largely Java and Kotlin, while OpenHarmony is primarily C and C++.
The researchers looked beyond raw text comparison because different code can still be a function-by-function translation. They extracted function, variable, and interface names from randomly selected core-framework modules and compared them after accounting for exact and tokenized similarity. Exact-name similarities were close to zero, and tokenized similarities remained modest. From these measurements, they concluded that OpenHarmony is not a direct Android fork or a function-by-function reimplementation.
That conclusion removes code lineage as the necessary bridge between the systems. It does not remove design comparability. An operating system is experienced through responsibilities: a component displays a screen, a message invokes a service, a capability grants access, a store shares data, or a process is created. The internal route to that responsibility can change while the responsibility and its trust assumptions remain recognizable.
The study's terminology mapping is therefore a translation device, not an identity claim. Android's Intent and OpenHarmony's Want occupy comparable inter-component-communication roles. Activity and Ability are comparable UI-component roles. Broadcast Receiver and Common Event are comparable event-delivery roles. Content Provider and DataAbility are comparable data-sharing roles. Zygote and appspawn are comparable process-creation roles. Even where the comparison is useful, the systems may differ in lifecycle, enforcement, and defaults. The mapping tells an auditor where to ask a question; it does not answer the question in advance.
The diagram's relationship is deliberately asymmetric. It says that Android and OpenHarmony offer roles that can be compared, not that one platform is a superclass of the other or that one implements the other. This distinction is what makes the historical literature useful to an independent system.